Как отмечалось в главе 2, решение достаточно редко выполняется за один подход (см. рис. 6.1).

На каждом этапе разработки вначале проводится моделирование и анализ, что, вопервых, улучшает понимание входящих требований, а, во-вторых, обеспечивает надежную базу для последующей разработки производных требований для следующих уровней (этапов). Количество уровней зависят от характера и природы создаваемой системы, а также от степени новизны предлагаемых проектных решений. И совершенно неважно, какое количество уровней вам придется создать, - значение имеет лишь степень детализации решений на каждом из уровней.

На каждом из уровней разработки требований в области решений инженеры вынуждены принимать мини-решения, которые шаг за шагом продвигают их вперед к общей намеченной цели. Каждое из таких мини-решений, по сути своей природы, завоевывает собственное жизненное пространство на поле общего дизайна, т. е. каждое из решений ограничивает возможности других. Но общее развитие прогресса невозможно при отсутствии таких решений (шагов). А поскольку некоторые инженеры и разработчики зачастую сразу же начинают вдаваться в излишнюю детализацию даже на самых ранних этапах (т. е. захватывать большие куски пространства на поле общего дизайна), то надо постараться исключить такую тенденцию или, как минимум, всячески ее ограничивать с той целью, чтобы дать возможность работать всей команде, чтобы использовать способности и таланты других специалистов, чтобы стимулировать творческий подход к совместному решению проблем на всех этапах, и, в итоге, получить по-настоящему инновационное решение. Ведь ясно же, что такое инновационное решение не может быть получено, если на самых первых шагах проекта создавать ограничения (жизненного пространства), связанные с принятием преждевременных излишне детализированных решений.

Первым этапом в системных разработках в области решений обычно является преобразование пользовательских требований в системные. Системные требования как раз и будут определять, что именно система должна выполнять для того, чтобы решать проблемы, поставленные в пользовательских требованиях. На рис. 6.1 схематически проиллюстрировано вышесказанное - приведена ориентировочная последовательность шагов (сверху вниз) универсального процесса разработки системных требований.

Рис. 6.1 Возможная последовательность шагов процесса разработки системных требований.

Появление излишней детализации проектных решений особенно проблематично на первом шаге. Во избежание этого, модель системы на этом этапе (см. рис.6.1) должна быть достаточно абстрактной, позволяя лишь определять необходимую системе функциональность, но не углубляться в ее излишнюю детализацию.

Следующим шагом разработки системных требований является создание архитектуры системы. На рис. 6.1 это обозначено в виде второго (сверху) уровня основного процесса. Архитектура должна быть представлена в виде набора компонентов системы, которые, взаимодействуя, и порождают системные свойства, определенные в системных требованиях.

На следующем шаге производные требования, вытекающие из процесса разработки архитектурного дизайна (см. нижний уровень на рис. 6.1), определяют те требования, которым должны удовлетворять компоненты системы.

Такой процесс разработки требований должен проходить с постепенным углублением в детали реализации.

В данной главе мы уделим особое внимание процессу преобразования пользовательских требований в системные, поскольку это самый сложный этап для большинства проектов.

Именно на этом этапе, как показывает практика, преждевременные решения появляются слишком быстро.

6.2 Получение системных требований из пользовательских.

На рис. 6.2 приведен пример универсальной схемы преобразования пользовательских требований в системные.

Рис. 6.2 Универсальная схема процесса для получения системных требований.

Как и на любом другом этапе, процесс начинается с согласования входящих требований, которыми, в данном примере, являются пользовательские требования.

Но, согласовывая входящие требования, вы должны отдавать себе отчет в том, что те люди, которые разрабатывали пользовательские требования, отнюдь не следовали рекомендациям, изложенным ранее в этой книге, а может даже и не читали ее вовсе. Поэтому напротив, необходимо достаточно серьезно и строго подойти к оценке пользовательских требований и связанной с ними стратегии проверки на соответствие критериям «правильности» требований (о чем вы уже прекрасно осведомлены, если добрались до этой главы).

6.2.1 Разработка системной модели.

Во избежание опасной тенденции углубиться во множественные детали реализации, инженеры всегда должны работать в рамках контекста конкретной модели (см. рис. 6.1), уже достаточно детализированной, чтобы получать требования, которые следует формулировать, исходя из того, что система должна делать, а не то, как она должна это выполнять. Степень детализации вытекающих требований, конечно, зависит от этапа (уровня) разработки, на котором в данный момент находятся инженеры, однако, чтобы не ошибиться, лучше всегда руководствоваться простым правилом «не вносить подробностей больше, чем это необходимо».

Тенденция «сваливания» в преждевременное углубление в детали реализации наиболее ярко проявляется на начальном этапе (верхнем уровне) разработки, когда пользовательские требования, сформулированные в терминах области проблем, могут сразу переводиться в форму системных требований высокого уровня, обозначающих, что система должна делать, чтобы решить проблемы, сформулированные заинтересованными сторонами.

Эти проблемы возникают потому, что достаточно сложно (но надо!), работая, удержаться на определенном уровне абстракции. Но это характерное явление - создание абстрактной системной модели, из которой потом рождаются системные требования, всегда происходит в муках.

На любых уровнях ниже такие проблемы возникают реже. Разработка тут проводиться уже в контексте конкретных архитектурных решений, где проектировщики и разработчики чувствуют себя достаточно комфортно, поскольку вовлекаются в процесс определения, как именно система будет работать. Но даже на любом из этих уровней необходимо уделять должное внимание тому, чтобы степень детализации соответствовала именно этому уровню разработки. Соответственно, и в отношении архитектурных моделей, представленных в виде набора компонентов системы, функционирующих вместе, необходимо внимательно следить за тем, чтобы эти компоненты определялись в терминах того, какие функции они должны выполнять, без подробностей относительно того, каким образом они должны это делать. Иными словами, необходимо следить за тем, чтобы компоненты представляли собой «черные ящики», выполняющие сформулированные в требованиях задачи, при отсутствии описания их внутренней реализации.

Следующие разделы этой главы посвящены методам разработки системных моделей для получения на их основе системных требований. В развитие этой темы, описывается, как данный подход может использоваться на более низких (более детализированных) уровнях разработки требований.

6.2.2 Разработка системных моделей для получения системных требований.

Системная модель должна разрабатываться с определенным уровнем абстрактности, который подразумевает описание:.

должна быть описана в терминах того, что система должна выполнять, а не как это делать;.

• функциональности, необходимой для взаимодействия системы со своим окружением (с внешними системами);.

• функциональности, позволяющей людям взаимодействовать с системой;.

• функциональности, которая предохраняет систему от «ложного срабатывания», что может быть вызвано вредным (опасным) воздействием со стороны других систем из ее окружения. (Отметим, что это воздействие не всегда является сознательно угрожающим; например, электромагнитное излучение другого оборудования.) При этом «защитная» функциональность также должна «работать» и в обратном направлении предотвращать вредное воздействие системы на окружающую среду.

На рис. 6.3 проиллюстрировано взаимодействие перечисленных функциональностей между.

собой и с элементами внешнего окружения.

Рис. 6.3 Контекст системы и типы функциональности.

Очевидно, что состояние системы по отношению к ее окружению должно характеризоваться:.

существующими системами, с которыми разрабатываемая система должна взаимодействовать;.

• типами пользователей, которые будут взаимодействовать с системой;.

• опасными событиями, от которых система должна быть защищена;.

• негативными последствиями, которые должны быть предотвращены.

Функциональность может быть смоделирована несколькими различными способами:.

• операции или методы классов на диаграммах классов;.

• диаграммы сообщений (MSC);.

• диаграммы переходов состояний;.

• блок-диаграммы функциональных потоков;.

• процессы на диаграммах потоков данных.

На практике приходится использовать несколько различных типов моделей для описания всех требуемых аспектов функциональности системы. А поскольку каждая модель содержит информацию определенного типа, а каждая технология моделирования использует свою собственную семантику, то информация в одной модели может быть «отделена» от информации в другой модели. Но с другой стороны, одна и та же информация может появляться в нескольких моделях. В последнем случае очень важно быть уверенным, что если информации меняется в одной из моделей, то это изменение отражается и во всех остальных моделях, в которых эта информация встречается. В идеальном варианте это может происходить автоматически с помощью сопряжения (интеграции) моделирующих инструментов. Если же это по каким-то причинам не может быть организовано, то необходимо проявлять исключительную педантичность и аккуратность, чтобы удостовериться в том, что любое изменение информации в одном месте идентично отражается в других связанных моделях. Диаграмма Венна (рис. 6.4) иллюстрирует, что некоторые модели могут быть представлены в виде отдельных островков информации, в то время как другие модели могут иметь общую информацию, возможно представленную в разных формах. Диаграмма также демонстрирует тот факт, что часть информации о системе не отражена ни в одной из моделей.

Рис. 6.4 Границы системных моделей.

Внутренняя функциональность.

Внутренняя функциональность является исходным элементом для разработки системных требований, потому что определяет то, что система должна делать. Для того чтобы получить системные требования, необходимо разработать функциональную структуру или модель системы, которые будут являться основой для дальнейшей работы. Такая модель должна предполагать возможности декомпозиции системы и позволять выделение модулей или высокоуровневых компонентов, например, подсистем. Конечно, термины «модуль» или «подсистема» провоцируют проектировщиков и разработчиков мыслить больше в категориях реализации, нежели чем в направлении конкретизации и спецификации, поэтому употребление этих терминов является не очень хорошей практикой (особенно в области разработки программного обеспечения). В большинстве систем, «сползание» в область физических моделей не рассматривается, как некая чрезвычайная ситуация, поскольку сама по себе область применения систем может иметь физическую природу.

Как альтернатива этой терминологии, стимулирующей появление преждевременных решений, существует тенденция (можно даже сказать «мода») употреблять термин «объект», говоря о декомпозиции. Особенно это популярно в области разработки ПО, поскольку объект, в этом случае, может описывать реальный предмет из области проблем. Такой подход помогает предотвратить попытки мышления проектировщиков в терминах решений. В соответствии с этим подходом функциональность системы может быть представлена как совокупность методов и операций над объектами, а также в виде описания взаимодействия объектов между собой.

Использование такого объектно-ориентированного подхода позволяет также упростить задачу установления связей от системных требований к пользовательским, поскольку зачастую некоторые объекты проявляют тенденцию «просматриваться», как в области проблем, так и в области решений.

Помимо описания того, что система должна делать, от системной модели требуется также обозначить подразумеваемое поведение системы. Эта информация может быть представлена разными способами. Достаточно вспомнить, что модели в этой области обычно отражают тот факт, как несколько ролей (актеров) могут одновременно взаимодействовать друг с другом.

В качестве примера таких нотаций можно вспомнить диаграммы последовательности сообщений (Message Sequence Diagrams = MSC) и диаграммы поведения (Behaviour Diagrams). MSC-диаграммы на протяжении уже достаточно долгого времени и с большим успехом используются в телекоммуникационной отрасли. А диаграммы поведения впервые начали использоваться в 70х годах прошлого века в США при разработке системы BMEWS (Ballistic Missile Early Warning System) раннего оповещения о возможном ударе баллистических ракет, а позже были включены в средства моделирования RDD-100 (Ascent Logic Corporation) и CORE (Vitech Corporation).

Поведение можно моделирование также с помощью диаграмм переходов состояний (State Transition Diagrams) и диаграмм состояний (State Charts). Диаграммы переходов состояний имеют свои ограничения. С их помощью можно отобразить только последовательность состояний; причем так, что в каждый конкретный момент времени моделируемый объект может находиться только в одном из этих возможных состояний. Этот тип диаграмм не может отобразить иерархию состояний моделируемого объекта напрямую. Поэтому для того, чтобы смоделировать иерархию состояний приходится разрабатывать диаграммы переходов состояний для каждого уровня иерархии. В некоторых случаях это может привести к тому, что в некоторые моменты времени разные наборы диаграмм могут пребывать в активном состоянии. Такое сложное поведение бывает трудно осмыслить и понять. Для преодоления подобных трудностей рекомендуется использовать диаграммы состояний, поскольку они изначально разрабатывались для моделирования иерархий состояний в целом, а также для моделирования параллельных состояний.

Для любой системы необходимо также определить то, какую именно информацию и как необходимо обрабатывать и хранить.

В некоторых системах, например, в системах учета страховых компаний, необходимо, чтобы информация собиралась и хранилась в течение многих лет. В других системах, например, в системе обработки данных, полученных с помощью радара, для обеспечения управления воздушным движением, часть информации должна храниться достаточно долго, например, планы полетов, а другая информация, например, текущее положение самолета, не актуальна уже в следующую секунду, поскольку самолет переместился.

Следовательно, необходимо определить следующие параметры, касающиеся хранения информации, относящейся к разрабатываемой системе:.

• срок жизни информации, т.е. какое время эта информация является достоверной, и какое время она должна храниться;.

• частота обновления информации, т.е. насколько часто информация должна обновляться (секунды, минуты или часы).

Очень важно также знать и объем информации, который будет обрабатываться системой. Этот показатель может оказать существенное влияние на архитектуру системы.

Интерфейсная функциональность.

Здесь необходимо определить характер будущего взаимодействия системы с любыми другими внешними системами.

Это взаимодействие может быть связано и с передачей информации, и с перемещением вещественного материала между системами. Эта передача может носить только однонаправленный характер или же «функционировать» в обоих направлениях; причем при наличии или отсутствии ограничений, налагаемых на такую передачу. В некоторых случаях необходимо даже организовать временное хранение передаваемыхпринимаемых объемов информации или материалов (например, буфер, или склад), если они не могут быть обработаны сразу. Могут существовать и определенные требования относительно времени реакции системы на внешние воздействия со стороны других систем.

Природа самих интерфейсов также может существенно варьироваться. Однако всегда должен существовать некий базовый документ, который бы четко характеризовал, за что именно отвечает и что именно обеспечивает каждая часть (уровень) интерфейса, как составляющая общего целого. Эти обязательства обычно документируются в виде специального документа ICD (Interface Control Document), описывающего интерфейс. В тех случаях, где взаимодействия между системами обеспечиваются с соблюдением национальных или международных стандартов, такой стандарт автоматически становится документом ICD, руководствуясь которым могут функционировать все составляющие части. В тех случаях, когда интерфейс не так четко определен, требования к интерфейсу, все же, должны быть согласованы и зафиксированы в письменном виде. Контроль за выполнением требований такого рода практически всегда сопряжен с проблемами, поскольку не существует одной общепризнанной организации, которой делегировано право контроля за интерфейсами. Это зачастую приводит к тому, что каждая из сторон, использующих интерфейс, может иметь собственные версии такого ICD документа, или, что еще хуже, - на свое усмотрение интерпретировать один и тот же документ.

Обычно выполнение рекомендаций документов, описывающий интерфейс, контролируются той организацией, которая отвечает за разработку системы, предполагающей взаимодействие с другими системами. Однако в том случае, когда разрабатывается совершенно новая система, найти организацию, которая взяла бы на себя ответственность за контроль такого рода, является большой проблемой.

Очень часто бывает так, что для ранее разработанных систем документации, описывающей интерфейс нет или она очень плохая. Более того, возможно, что разработчик системы уже и не поддерживает ее или передал ее на обслуживание своему клиенту или другой организации. Это порождает свои трудности при определении интерфейсов.

Необходимо уделять большое внимание тому, чтобы у вас была полная уверенность, что все обязательства по соблюдению интерфейсов отражены в производных требованиях на всех соответствующих уровнях, и что четко, насколько это возможно, определена организация, которая будет осуществлять контроль за соблюдением интерфейса.

Функциональность, обеспечивающая взаимодействие с человеком.

Основным вопросом в области общения системы с человеком является определение того, какое именно взаимодействие им может потребоваться. Здесь не следует забывать про условия, в которых человек взаимодействует с системой, поскольку они оказывают влияние на то, как именно человек будет работать с системой.

Например, человек, работающий в кабинетных условиях, находится в тепле и может работать с данной системой без перчаток; а вот другие люди вынуждены работать с этой системой в экстремальных условиях, скажем, при низких температурах или других вредных условиях, поэтому им может потребоваться защитная одежда. Тогда конструкция, например, дисплея и клавиатуры должна учитывать и эти факторы.

Защитная функциональность.

Внешняя среда, в которой должна функционировать система, существенным образом влияет на требования по безопасности и защите системы.

Например, для банковских систем необходимо обеспечить защиту информации и финансов от доступа к ним неавторизированных лиц. В автомобиле необходимо гарантированно обеспечить остановку автомобиля при нажатии человеком на педаль тормоза.

Возможно, следует принимать во внимание и другие - особенно конкурирующие, системы, которые функционируют в окружении разрабатываемой системы. Такого рода конкуренция может оказывать разное влияние на систему. Например, если ведется разработка системы для on-line предоставления клиентам банковских услуг, то присутствие или возможное появление на рынке конкурирующих банковских систем, может существенным образом влиять на сроки разработки вашей системы.

В других случаях, «конкуренция» может выражаться в непосредственном влиянии одной системы на другую, например, радиоизлучение одной системы, может перегружать чувствительные приемники другой системы. Примером этого является запрет на пользование мобильными телефонами на борту самолета, поскольку они могут отрицательно влиять на системы навигации самолета.

Системные транзакции.

Разрабатывая систему, бывает очень полезно еще раз пересмотреть и проанализировать существующие сценарии использования, полученные от заинтересованных лиц, или, - если таковые отсутствуют, - самим создать соответствующие наборы сценариев. Тогда на системную модель вы сможете «смотреть» сквозь призму этих сценариев, убеждаясь, что они функционируют надлежащим образом в рамках создаваемой системы (см. рис. 6.3). Такая проверка осуществляется при помощи, так называемых, «системных транзакций». Этот подход позволит вам еще раз убедиться, что на этапе объектной или функциональной декомпозиции системы не был упущен ни один из элементов ее функциональности.

Рис. 6.5 Системные транзакции.

Системные транзакции, которые на рис. 6.5 помечены, как «пользовательские системные транзакции», получены из сценариев использования. Вместе с тем, рисунок демонстрирует, что могут быть и другие транзакции, являющиеся производными от способа, которым разрабатываемая система должна взаимодействовать с внешними системами, - «внешние системные транзакции».

Использование системных транзакций поощряет проектировщиков, как бы, приподняться над системой и окинуть ее «глобальным» взглядом, потому что всегда существует опасность «за деревьями забыть о лесе». Другими словами, концентрируясь на работе с мелкими деталями, можно забыть про всю картину в целом, т.е. упустить из виду, как отдельные части системы, взаимодействуя друг с другом, должны обеспечивать достижение глобальной цели.

Режимы функционирования системы.

При разных обстоятельствах от системы может требоваться различная функциональность (поведение).

Типичным примером, поясняющим вышесказанное, может служить режим, предназначенный для обучения пользователей информационных систем, при котором система должна - даже при самых нерадивых студентах - обеспечивать целостность промышленных данных. В качестве другого примера можно привести аварийный режим работы системы, когда она функционирует по особому сценарию, или - как это обеспечивают военные системы - в зависимости от уровня тревоги могут быть предусмотрены различные режимы функционирования.

Все это, так или иначе, может быть связано со специальными сценариями использования, которые диктует заинтересованная сторона.

Дополнительные ограничения.

В дополнение к уже упомянутым, существуют и другие ограничения, которые необходимо учитывать. Возможно наиболее важные из них - это те, которые обеспечивают безопасность применения системы и ее готовность к сертификации. Для обеспечения этих условий и разрабатываются дополнительные требования, которые, несомненно, могут оказывать значительное влияние не только на саму разработку системы, но и даже на выбор тех средств, с помощью которых она будет разрабатываться. Представители уполномоченных органов должны иметь возможность убедиться в том, что разработанная система удовлетворяет действующим нормам и безопасна для установки и использования. Каждому самолету, например, выдается специальный сертификат, подтверждающий его пригодность к полетам.

Другой набор ограничений может быть обусловлен возможностями производства системы. Например, возможно существуют определенные производственные мощности, которые могут быть использованы для производства системы, или проект системы должен быть таким, чтобы максимально снизить затраты на производство.

6.2.3 Абстрактная модель банка.

Приводя пример банковской системы, авторы хотели бы, в первую очередь, отразить модель информационных потоков, хотя совершенно ясно, что существует масса и других аспектов поведения системы, которые могут быть описаны схожими моделями.

Рис. 6.6 Абстрактная модель банка.

В конечном итоге, желательно иметь несколько разных системных моделей, каждая из которых отражают различные аспекты функционирования, например, информационные модели, модели потоков данных, модели обеспечения защиты информации.

На рис. 6.6 изображена абстрактная модель банка, описывающая различные типы мест размещения оборудования, из которых могут быть инициированы транзакции.

Внутренняя функциональность.

Естественно, что основная внутренняя функциональность банковской системы связана с предоставлением банковских услуг своим клиентам: текущий расчетный счет, сберегательный счет, кредиты, инвестиционные портфели. Для обеспечения этих услуг система должна иметь возможность собирать, обрабатывать и хранить информацию. Здесь очень важно дифференцировать типы (или классы) хранимой информации (напр., счета, клиенты); связи, существующие между ними (напр., сколько счетов в банке может иметь клиент); а также дополнительные характеристики для каждого типа хранимой информации (напр., время хранения, частота обновления, объем).

Необходимо также определить и то, каким образом эта информация собирается, распределяется и обрабатывается.

Следующей важной характеристикой банковской системы является количество и дислокация источников информации и/или источников транзакций. Этот список может включать офисы и филиалы банка, банкоматы, карточные терминалы в торговых точках и т.д.

С точки зрения производительности, необходимо определить вероятную нагрузку на систему, выраженную в количестве транзакций определенных (и смешанных) типов в единицу времени, с которой система должна справляться. Разумеется, в реальной жизни эта нагрузка не будет равномерной, а будет сильно варьироваться в зависимости от времени суток, дня недели и месяца года. Здесь не следует забывать об ограничениях, которые могут быть связаны с пропускной способностью существующих линий и каналов связи, а также других средств (оборудования) коммуникации.

Интерфейсная функциональность.

Основными интерфейсами для банковских систем такого типа являются интерфейсы для взаимодействия с системами других банков, обеспечивающими перевод денежных средств, и интерфейсы для взаимодействия с их банкоматами.

При этом также необходимо иметь в виду, что несколько банков могут использовать и другие интерфейсы, поскольку могут быть объединены в собственную систему для обслуживания, например, банковских чеков или аналогичных платежных средств.

С большой долей вероятности можно предположить и наличие другого типа интерфейса наверняка банки пользуются телекоммуникационными услугами, которые предоставляются им независимыми провайдерами.

Функциональность, обеспечивающая взаимодействие с человеком.

Обычно информационные системы предусматривают взаимодействие с широким спектром различного типа пользователей. Для примера с банком можно предложить следующий список, в котором перечислена большая часть типов пользователей:.

• Клиенты и пользователи - должны иметь возможность пользоваться банкоматами и online доступом к web-ресурсам банка без какого-либо предварительного обучения; интерфейсы пользователя должны быть интуитивно понятными.

• Сотрудники банка, работающие с клиентами - должны иметь возможность оперативно управляться с системой, чтобы обеспечивать быстрое и эффективное обслуживание клиентов из очереди. Эти сотрудники должны быть хорошо обучены и подготовлены. Важная характеристика интерфейса - он должен быть «заточен» под то, чтобы обученные работники банка могли выполнять операции максимально быстро и эффективно.

• Руководители различных уровней - некоторые руководители могут не иметь компьютерных навыков, чтобы «справляться» с системой (за исключением случаев, когда руководители назначаются из числа сотрудников, кто ранее работал с системой). Возможности, которые система предоставляет руководству, могут быть теми же, что и для сотрудников обслуживающих клиентов; однако, наряду с этими возможностями руководству необходимо получать и более широкий спектр данных, чтобы видеть общую картину деятельности банка. К таким данным можно отнести консолидированную информацию о работе филиала или суммарные данные по одному из направлений работы банка. Необходимо отметить, что получение такой консолидированной информации требует сбора и хранения информации в течение определенного периода времени, чтобы позволить анализировать тенденции и проводить исторический анализ работы банка.

• Сотрудники маркетинговой службы и отдела регламента — для этого типа пользователей могут потребоваться самые различные возможности, например, доступ к полной функциональности системы для начала работ над новым продуктом или проектом.

• Обслуживающий персонал системы — должен иметь возможность проводить обновления и модернизацию системы. В идеальном случае должна иметься возможность делать это в любой момент, в том числе, и во время нормального функционирования системы. Но на практике, обновления системы обычно проводят в нерабочее время (ночью), для того, чтобы не мешать работать банку и обеспечить целостность данных.

Защитная функциональность.

Защищенность от несанкционированного доступа является суперважной характеристикой банковских систем. Ключевым элементом является сохранение неприкосновенности информации, поскольку она является сердцем бизнеса.

Для обеспечения безопасного доступа к данным и деньгам через банкоматы используются PIN-коды (Personal Identification Number) пластиковых карт. Для обеспечения безопасной передачи данных между банком, его офисами и банкоматами используется шифрование данных.

Другая ситуация, которую необходимо также принимать во внимание, - это обеспечение функционирования системы в аварийных ситуация при сбоях компьютерного оборудования, программного обеспечения, отключения электропитания или обрывах в сетях передачи данных или линиях связи. Эти категории функциональности тесно связаны с оценкой риска. Степень защиты, которую можно себе позволить, чтобы смягчить последствия рисков, серьезно зависит от вероятности их появления.

В заключении - и как самое важное - следует отметить функциональность по защите информационной системы от преднамеренного несанкционированного доступа, проще говоря, от хакеров, расхитителей и других мошенников. Программное обеспечение должно обеспечивать адекватную защиту банка и его клиентов от подобных «неприятностей».

Системные транзакции.

Для банковской системы каждый из типов пользователей будет являться заинтересованной стороной. Следовательно, для каждого типа пользователей будет разработан свой набор сценариев использования. Для клиентов банка набор сценариев будет отражать регулярно используемые услуги банка - снятие денег со счета, зачисление денег на счет, переводы средств, сделанные самим клиентом или автоматически в случае, например, зачисления на счет заработной платы, регулярные выплат по кредиту. Очевидно, что будут существовать и не так часто выполняемые транзакции, например, получение ссуды или ипотечного кредита.

Для каждого типа пользователя следует оценить предполагаемую нагрузку, им создаваемую, для того, чтобы оценить время отклика системы на воздействие с его стороны. Разумеется, это не будет фиксированный параметр, поскольку на этот показатель влияет общая загрузка системы, которая, в свою очередь, неравномерна в течение суток, а также в разные дни недели и т. д.

Возрастающая популярность web-сервисов также должна быть принята во внимание при расчете показателей загрузки системы.

Режимы функционирования системы.

Доминирующим режимом функционирования системы должен быть нормальный режим. Однако необходимо предусмотреть и другие режимы, которые предусматривали бы следующие возможности - обучение пользователей, резервное копирование данных системы, аварийное восстановление системы и данных, обновление и модернизация системы.

6.2.4 Абстрактная модель автомобиля.

Второй пример связан с более «физической» по своей природе системой, но, тем не менее, интересно отметить, что и тут присутствуют те же самые категории информации, хотя и в совершенно другой форме.

Самый сложный вопрос этого примера - будет ли системная модель оставаться физической моделью, и в какой все-таки степени эта модель может быть абстрактной. Маловероятно, что новый автомобиль будет радикально отличаться от своих предшественников - те же четыре колеса будут располагаться по углам корпуса, будут присутствовать двигатель, коробка передач, подвеска, лобовое стекло и т.д.

По этой причине системная модель автомобиля наверняка будет напрямую ссылаться на физические элементы его конструкции, как показано на рис. 6.7. Направление стрелки показывает направление «влияния» одного элемента на другой. Например, водитель нажимает на педаль тормоза, которая задействует тормоза. Стрелки между кузовом автомобиля и другими его частями, которые закреплены на нем, изображены двунаправленными, чтобы продемонстрировать зависимость в обоих направлениях, т. е. двигатель закреплен на кузове автомобиля, а кузов выполнен таким образом, чтобы на нем можно было закрепить двигатель.

Рис. 6.7 Абстрактная модель автомобиля, базирующаяся на физических элементах.

Однако там, где составляющие нового автомобиля предполагают коренным образом отличаться от традиционного взгляда, например, электронная система управления, которая будет разрабатываться заново, имеется возможность сохранить более абстрактный подход к моделированию, что позволит обнаружить значительные преимущества при поисках наилучшего решения.

Для того чтобы стало ясно, что все вовлеченные в проект специалисты однозначно понимают функциональность автомобиля, необходимо определить качественные характеристики этого термина. Например, понятно, что автомобиль должен перевозить из одного места в другое людей и их багаж, поэтому ключевые вопросы, которые необходимо задавать, чтобы сформировать пользовательского требования, могут выглядеть следующим образом:.

• Какая развлекательная техника должна быть в автомобиле?.

• Какими устройствами безопасности должны быть оборудован автомобиль?.

• В каких условиях будет эксплуатироваться автомобиль?.

Внутренняя функциональность.

Ключевые параметры, которыми должен характеризоваться автомобиль на функциональном уровне, включают следующее:.

• Показатель ускорения автомобиля. Это требует сохранения определенного баланса между мощностью двигателя, суммарным весом автомобиля, коэффициентом обтекаемости кузова, но с учетом параметров колес как ограничений.

• Класс автомобиля. Это требует соблюдения баланса между расходом горючего на 100 км, объемом двигателя, типом коробки передач (автоматическая или механическая) и т.д.

• Уровень комфортабельности автомобиля. Уровень комфортабельности влияет на стоимость и вес автомобиля; к тому же разные люди могут по разному относиться к оценке различного рода удобств.

Необходимо сразу отметить, что все перечисленные ключевые характеристики не являются независимыми. И это достаточно типичная ситуация для инженерных систем. Наличие взаимосвязей такого рода порождает большое желание «переместить» модель в более абстрактную область.

Например, все перечисленные выше факторы, будут разниться в зависимости от типа двигателя и типа используемого горючего. Для каждого из типов горючего - бензин, дизельное топливо, газ, - такие параметры типа двигателя, как расход топлива, вес двигателя, объем топливного бака, будут иметь разное значение, а значит, будет необходимо решать задачу:.

• стоит ли делать окончательный выбор всех параметров сейчас;.

• стоит ли оставить этот вопрос открытым на будущее;.

• стоит ли предоставить заказчику (покупателю) возможность выбора одного, двух или трех возможных вариантов.

От принятого решения будет в значительной степени зависеть ход дальнейших работ по проектированию автомобиля. Вполне возможно, что придется проектировать, испытывать и оценивать все три возможных варианта, причем даже более детально, нежели общую модель. Хотя возможен и другой вариант, например, выбор газа в качестве топлива будет исключен с самого начала.

Интерфейсная функциональность.

Некоторые наверняка подумают, что автомобиль является достаточно независимым устройством с точки зрения его взаимодействия с внешними системами. И совершенно напрасно! Вспомните самый простой пример - в автомобиле есть радиоприемник, который должен удовлетворять определенным стандартам (иметь интерфейс), чтобы взаимодействовать с внешними системами - принимать и декодировать радиосигналы.

Возрастание сложности окружающих нас технологий увеличивает и число стандартов, которым должно удовлетворять создаваемое устройство.

Например, если автомобиль имеет встроенную систему глобального позиционирования (GPS), то появляется необходимость, чтобы этот прибор правильно принимал и декодировал сигналы тех спутников, от которых зависит его работа. Если же на автомобиле установлена система, информирующая водителя о ситуации на дорогах, то эта система должна «уметь» получать информацию от внешних систем, обеспечивающих доставку такой информации. Отсюда вполне можно предположить, что в скором будущем эти системы будут взаимодействовать друг с другом, а, следовательно, будет необходимо поддерживать еще один межсистемный (внутренний) интерфейс.

Для современных автомобилей большую роль играет техническое обслуживание. Очень важно, чтобы автомобиль умел «возвращать» информацию обо всех событиях, которые происходят внутри него во время эксплуатации, чтобы автомеханики могли провести диагностику и обнаружить те части автомобиля, которые функционируют неправильно или срок эксплуатации которых подходит к концу. Это пример системы диагностики, которая частично установлена на функционирующей системе (автомобиле), а частично в сервисном центре, где осуществляется обслуживание автомобиля, и тут важно, чтобы обе составляющие понимали друг друга.

Функциональность, обеспечивающая взаимодействие с человеком.

Многие характеристики «пользовательского интерфейса» автомобиля формировались исторически в течение долгих лет. Например, традиционное расположение педалей управления одинаково во всем мире (педаль газа - справа, педаль тормоза - слева, если есть педаль сцепления, то она располагается еще левее).

Другие характеристики, такие, как правое или левое расположение руля, расположение приборов на передней панели или щеток стеклоочистителя (дворников), зависят от местных «традиций» и страны.

С другой стороны, пока не существует общепринятых стандартов и соглашений для систем, предназначенных для развлечения, навигационных устройств и других не очень широко распространенных систем. Следовательно, проектировщики имеют полную свободу при разработке пользовательских интерфейсов для этих систем. Но, как и для большинства электронных систем, пользовательские интерфейсы этих устройств должны быть просты и интуитивно понятны любому человеку, который захочет ими воспользоваться. Это сама по себе достаточно непростая задача, поскольку единственный способ объяснить человеку, как общаться с системой, - это снабдить его инструкцией или руководством пользователя. Совершенно понятно, что невозможно отправить всех водителей или пассажиров на обучающие курсы, так же как совершенно невозможно даже примерно оценить среднестатистический образовательный уровень или опыт человека, желающего воспользоваться системой.

Защитная функциональность.

Основной задачей защитной функциональности является обеспечение безопасности автомобиля, водителя и пассажиров. Другой важной задачей является обеспечение защиты автомобиля от грабежа и угона.

В общем и целом, защитная функциональность начинается с тормозной системы. Поэтому очень важно в любой момент времени обеспечить водителю гарантированную возможность воспользоваться эффективной системой торможения. Одним из возможных вариантов обеспечения этого требования является установка на автомобиль тормозной системы с двумя независимыми гидравлическими контурами, которая обеспечивает торможение даже в том случае, когда выходит из строя один из ее элементов.

Системная модель может либо достаточно подробно описывать такую тормозную систему, либо описывать только сам факт наличия у автомобиля тормозной системы. В дальнейших проработках модели даже требование того, что тормозная система должна оставаться работоспособной в случае выхода из строя одного из гидравлических контуров, следует рассматривать вне рамок модели.

Попутно заметим, что это обсуждение автоматически подразумевает тот факт, что используется именно гидравлическая тормозная система! Таким образом, некоторые технические решения могут появляться на самых ранних этапах, если существует хорошо наработанная практика или если решение принимается исходя из поставленных бизнесцелей, которые заранее определены во входящих требованиях.

Другие аспекты обеспечения защиты включают антиблокировочную систему торможения ABS и подушки безопасности, смягчающие удар при столкновении. Опять же, данные функции могут быть либо сразу внесены в системную модель, либо этот вопрос может быть отдан на откуп дизайнеру с тем, чтобы создать нечто принципиально новое.

Для обеспечения защиты автомобиля от грабежа и угона необходимо, как минимум, предусмотреть замки на дверях. В дополнение к этому автомобиль может быть оборудован противоугонной сигнализацией и иммобилайзером двигателя. Ограничивающим фактором для такой дополнительной функциональности является лишь ее стоимость (сколько покупатель готов платить за нее). Однако, существуют и стимулирующие факторы, например, - наличие аналогичной функциональности в автомобилях-конкурентах, положительное отношение к этой функциональности со стороны страховых компаний и т.п. Все эти факторы оказывают исключительное влияние не только на то, будет ли присутствовать данная функциональность в автомобиле, но и насколько оправдано наличие такой функциональности.

Системные транзакции.

Существует достаточно большое количество возможных транзакций в отношении автомобиля. В основе всех их лежат поездки и путешествия, но каждая со специфическими целями и характерными особенностями, например:.

• Владелец - купить, период старения/удешевления автомобиля, продать/подарить.

• Продавец - периодически пытаться продать, продать, гарантийный период.

Каждая из этих транзакций может формировать новые требования, такие как объем багажника или средства для технического обслуживания. Следовательно, важно рассмотреть все транзакции и понять, какие требования вытекают из каждой. Конечно, это вовсе не означает, что все эти требования будут удовлетворены. Возможно, что некоторые из них будут отклонены по причине высокой стоимости их реализации или потому, что они не востребованы рынком, для которого предназначен автомобиль. Как возможная альтернатива может быть принят промежуточный вариант, при котором для различных географических рынков будут создаваться различные модели автомобиля.

Режимы функционирования системы.

Нетрудно себе представить, что характеристики местности, в которой предполагается эксплуатировать автомобиль, могут влиять на его конструкцию. Например, в горной местности коробка передач могла бы автоматически выбирать пониженные передачи, а система управления двигателем могла бы учитывать пониженное содержание кислорода в атмосфере для подготовки смеси, впрыскиваемой в цилиндры двигателя.

Такие возможности можно или с самого начала предусмотреть в базовом варианте поставки и тогда водитель мог бы использовать этот режим вождения по мере необходимости, или же, совершая покупку, водитель должен будет отдельно оговаривать наличие этой опции. Другой важный режим функционирования - это возможность диагностики. Система контроля за работой двигателя должна «уметь» передать накопленные данные системе диагностики сервисного центра для последующего анализа.

Более экстремальным режимом функционирования является автопоезд. В этом случае вся сцепка будет управляться с головного автомобиля, а средства управления во всех остальных будут отключены.

6.2.5 Получение требований из системной модели Создание структуры документа для требований.

Как отмечалось ранее, системная модель может состоять из нескольких независимых и потенциально перекрывающихся моделей. Можно начинать формирование требований из любой из разработанных моделей, как это пояснялось в предыдущих разделах на примерах модели банка и автомобиля. Однако проблема состоит в том, что достаточно сложно сразу получить хорошую структуру для требований, в которой каждое требование однозначно занимало бы свое исконное место. И при этом каждое свободное место в этой структуре означало бы некое поле для маневра дизайнерской мысли, а не присутствовало потому, что что-то упущено. Разработка структуры документа уже рассматривалась нами в главе 4.

Рекомендуется выбрать в качестве базовой одну из моделей для последующей разработки структуры документа. Выбранная модель должна быть максимально общей, поскольку системные требования должны описывать всю систему целиком, а не только какую-нибудь ее маленькую часть. На практике такой выбор достаточно очевиден и не вызывает больших проблем. Для систем обработки информации, как приведенная банковская система, модель данных зачастую является наилучшим выбором, потому что покрывает большую часть общей функциональности системы, в той или иной степени, отражая сбор данных, их распространение, обновление и обеспечение безопасности. Для систем более «физических» по своей природе, например, для примера с автомобилем, обычно лучше всего использовать модель, отражающую физическую структуру системы (если она существует), поскольку большинство требований будут относиться к тому или иному физическому элементу системы.

Получение и распределение требований.

Как только разработана и согласована структура требований, начинается процесс сбора производных требований и размещения их в полученной структуре. Вполне возможно, что некоторые входящие требования могут быть сразу и без изменений помещены в структуру документа. Если это происходит, то обычно свидетельствует о том, что входящие требования весьма детализированы, т.е. очень близки к реализации.

Если же вы только начинаете формулировать требования, то самое лучшее - это руководствоваться всеми правилами для «написания хороших требований», приведенными в главе 4. Всегда помните и соблюдайте «золотое правило» - каждое требование должно представлять собой единственное утверждение, реализацию которого можно проверить (т.е. каждое единичное требование должно быть пригодно для тестирования). Как только производное требование сформулировано, необходимо установить связь, идущую от него обратно к одному или более входящим требованиям, которые данное (только что сформулированное) требование удовлетворяет полностью или частично.

Когда мы рассматриваем пригодность требования для тестирования, имеет смысл сразу задуматься о критериях, которые будут характеризовать пройден тест успешно или нет. Эти критерии приемки должны быть зафиксированы для каждого требования. В некоторых случаях такой критерий может включаться непосредственно в текст требования, как, например, характеристика производительности. Но в основном рекомендуется отражать приемочный критерий в отдельном атрибуте конкретного требования.

После определения критериев приемки (и производительности) необходимо рассмотреть способы, с помощью которых будет демонстрироваться тот факт, что система удовлетворяет этим приемочным критериям. Иными словами, необходимо определить критерии приемки, стратегию проверки, разработать необходимые программы испытаний и инспекций.

На том этапе необходимо также оценить степень трудоемкости тестирования и определить, какое тестовое оборудование потребуется для испытаний. Может вполне оказаться, что организация тестирования потребует отдельных разработок, а в некоторых случаях, даже запуска отдельных (дополнительных) проектов.

Дальнейшее пристальное внимание к этому вопросу может привести вас к идее встроить в систему тестовую функциональность и организовать контрольные точки для мониторинга. Встроенная тестовая функциональность имеет очень большое значение особенно в тех областях, которые связаны с обеспечением безопасности. Например, в случае с автомобилем, - сразу после запуска двигателя электронные системы автомобиля тут же выполняют диагностику двигателя и всех вспомогательных подсистем. Контрольные точки встраиваются в систему так, чтобы ранее недоступная важная информация о системе, стала доступной и возможной для обработки. Простой пример - наличие в автомобиле прибора для измерения давления топлива. Если обратить внимание на информационные системы, вспомним пример банка - то можно говорить о специальном дисплее, на котором отображалась бы консолидирующая информация о количестве транзакций в единицу времени для всей сети банка.

Заключительным набором требований, который также следует рассмотреть, являются ограничения, которые не добавляют дополнительной функциональности, но ограничивают способ, которым может быть реализована необходимая функциональность. На уровне системных требований часть ограничений может без изменений переноситься из пользовательских требований. Например, геометрические параметры системы могут быть жестко заданы заинтересованными сторонами, или заказчики настаивают на том, что одна из существующих систем должна входить в виде подсистемы в новую систему.

Могут существовать также и некоторые другие источники ограничений:.

• Архитектурные решения - например, решение о том, что на автомобиле должна быть установлена гидравлическая тормозная система с двумя независимыми контурами.

• Область применения - например, все оборудование, установленное на автомобиле, должно работать в условиях вибрации, которая присутствует при движении автомобиля.

• Безопасность - например, каким образом разработчики могут убедить компетентные органы в том, что данный автомобиль не представляет угрозы для других участников движения?.

• Производство - например, может ли создаваемый автомобиль производиться на имеющихся производственных мощностях и с приемлемыми затратами?.

6.2.6 Согласование системных требований с проектировщиками.

Заключительным шагом разработки системных требований является согласование их с командой проектировщиков, которые будут отвечать за дальнейшее проектирование.

Так как эта тема уже рассматривалась в главе 2, то нет никакой необходимости в дополнительных подробных объяснениях.

6.3 Получение требований для подсистем из системных требований.

Следующим логическим шагом, который необходимо выполнить после разработки системных требований, является разработка архитектуры системы, чьими компонентами являются крупные подсистемы (см. рис. 6.8).

Как обычно, данный процесс начинается с согласования с заказчиком входящих требований. В качестве основы для процесса согласования системных требований должны применяться те же критерии оценки, которые уже были описаны в главах 2 и 4. Требования не должны «скатываться» в область детальных технических решений, если только нет специфической необходимости каким-то образом ограничить дизайн. Да и в этом случае, такие требования должны быть явным образом сформулированы как ограничения. Зачастую единственным оправданием существования ограничения является фраза «потому что на этом настаивал заказчик». Поэтому хорошей практикой является пересмотр ограничений («подвергать сомнению»), особенно если ограничение в большей степени подразумевается, нежели напрямую и явно сформулировано. Порой требования для подсистем могут быть выражены в терминах определенных технических решений, что, в какой-то мере, демонстрирует лень разработчиков, которые склонны к преждевременной детализации.

Рис. 6.8 Основной процесс разработки требований для получения требований для подсистем из.

системных требований.

Аналитическая работа, необходимая для поддержания процесса согласования требований, помогает проектировщикам лучше понять, для чего предназначена система и подсистемы, и начинать задумываться о возможных реализациях.

6.3.1 Разработка архитектурной модели системы.

Архитектурная модель системы идентифицирует компоненты системы и то, как они между собой взаимодействуют. Проектировщик системы должен хорошо понимать, как взаимодействие компонентов (подсистем) приводит к появлению требуемых системных свойств, т.е. каким образом они удовлетворяют входящим требованиям.

Проектировщики должны быть способны прогнозировать появление свойств, которые, может быть, и не требовались по определению, например, возможные вредные воздействия, влияющие на безопасность и окружающую среду. Однако вполне возможно появление и таких «побочных» системных свойств, которые - хоть и не требовались, - могли бы быть приемлемы для дальнейшего использования. Такие свойства следует обсудить с заказчиком. На усмотрение заказчика эти дополнительные возможности могут быть либо прописаны во входящих требованиях (т.е. «задним числом» востребована их реализация), либо, наоборот, заказчик может настаивать на их исключении (запрет на проявление таких свойств).

Вполне возможен и такой случай, когда проектировщики выяснят, что не существует способа удовлетворить требования вообще или же в рамках определенного бюджета проекта.

После того, как разработана и проанализирована архитектура системы, появляется свет в конце туннеля. Наличие такого дизайна дает теперь возможность с намного большей степенью точности и аккуратности оценить затраты и время, которые потребуются на реализацию системы. А это, в свою очередь, дает возможность провести раунд переговоров с заказчиком с целью уточнения тех входящих требований, реализация которых в отведенное время или за отпущенные деньги может вести к проблемам.

Во многих случаях имеет смысл разработать несколько вариантов реализации с тем, чтобы затем проанализировать и оценить преимущества каждого из них. Это также может привести к очередному этапу переговоров с заказчиком для определения наиболее подходящего варианта реализации с точки зрения достижения лучшего соотношения «получаемые преимущества затраты на реализацию».

После согласования архитектуры каждый компонент должен быть описан в терминах его внутренней функциональности и его «обязанностей» взаимодействовать с другими компонентами и внешними системами.

6.3.2 Получение требований из архитектурной модели системы.

Требования для компонентов (подсистем) могут быть получены из их описания, которое было разработано на этапе моделирования системной архитектуры. Требования должны описывать функциональность, обеспечиваемую компонентом, интерфейсы, которые он должен использовать или поддерживать, а также ограничения, налагаемые на него. Ограничения на компонент могут накладываться общими системными ограничениями (например, для всех электронных компонентов системы должна использоваться одна и та же определенная технология), или же ограничения для компонента могут «вытекать» из системных ограничений (например, допустимый общий вес системы должен быть строго распределен между ее компонентами). Требования, которые предъявляются к компоненту (или подсистеме), являются, по сути, системными требованиями компонента, если рассматривать этот компонент, как независимую систему со своим собственными правами.

Для каждого производного требования (компонента) необходимо установить связь, ведущую обратно к входящему требованию (системному), которое оно (производное требование) частично или полностью удовлетворяет.

Для каждого компонента необходимо также разработать свою стратегию проверки. Так же, как и для других уровней, здесь важно, чтобы требование было пригодно для проверки. Контролепригодность это один из важнейших аспектов разработки требований, и поэтому стратегия проверки должна разрабатываться по мере окончания разработки дизайна.

6.4 Другие преобразования с использованием архитектуры системы.

Поскольку процесс разработки последовательно «спускается» все ниже и ниже от одного уровня к другому, то на каждом из этих уровней (этапов) создается, по сути, собственная архитектурная модель (см. рис. 6.1). На каждом этапе процесс проходит точно так же, как это описано в предыдущих разделах. Другими словами, после разработки требований для подсистем более высокого уровня, начинают разрабатываться требования для компонентов этих подсистем, которые, на следующем шаге, рассматриваются уже как независимые подсистемы со своими компонентами, и так далее.

Однако существуют особый случай (использования архитектурной модели системы), который может считаться исключением из этого правила. Это отражено на рис. 6.9, который показывает, что архитектура системы и последующие требования для подсистем могут быть получены непосредственно из пользовательских требований.

Рис. 6.9 Преобразование пользовательских требований в требования для подсистем.

Такой вариант возможен в том случае, когда архитектурная модель системы известна заранее (вспомните, например, уже ранее рассмотренные «физические» системы автомобиль или самолет).

Здесь уместно также привести пример из телекоммуникационной индустрии, где применяемые стандарты зачастую предписывают архитектуру решения. Опять же встает чисто теоретический вопрос, являются ли требования, предъявляемые к системе, на самом деле пользовательскими или они, по сути своей, являются уже системными требованиями. Какой бы ответ ни был бы получен, это вполне обычная практика - транслировать входящие требования на уровень производных (требований к подсистемам). Получается это благодаря тому, что стандарты, сами по себе, достаточно детализированы.

6.5 Заключение.

В данной главе были рассмотрены общие свойства области решений и охарактеризован процесс разработки требований, используемый в этой области.

Было дано описание процесса преобразования пользовательских требований в системные и последующий процесс преобразования системных требований в требования для подсистем.

Были рассмотрены два различных примера, которые помогли раскрыть типы функциональностей, используемых для описания требований в области решений.

Было продемонстрировано, что помимо внутренней функциональности необходимо рассматривать также и интерфейсную функциональность; функциональность для обеспечения взаимодействия с людьми; а также защитную функциональность, обеспечивающую как защиту системы от внешних воздействий, так и безопасность ее эксплуатации по отношению к людям и окружающей среде.

Было упомянуто, что на более поздних этапах возможно появление дополнительных ограничений, в том числе, для соблюдения требований применяемого законодательства и для прохождения системой необходимой сертификации.