Структурирование точек зрения

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

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

Документирование и отображение системы точек зрения

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

Пример 3.4.

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

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

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

Рис. 3.3

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

Рис. 3.4

Этнографический подход

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

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

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

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

· Для сбора начальных требований к системе используется этнографический подход.

· Начальные требования обсуждаются и уточняются на совместных семинарах.

· Для дальнейшей работы по выявлению и уточнению требований строится прототип системы.

Рис. 3.5

Вопросы для самоконтроля

1. Каковы источники возникновения требований?

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

3. В чем достоинства и недостатки разделения требований на пользовательские и системные требования?

4. В чем основные отличия в проведении интервью и совместных семинаров?

5. Как определяются роли во время сеансов ”мозговой штурма”?

6. Что такое вариант использования?

7. Как определить иерархию различных точек зрения?

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

4. Разработка системных требований

4.1. Детализация требований пользователей

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

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

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

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

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

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

· выбор метода и типов моделей зависит от решаемой задачи и достаточно ответственен (и сложен).

Системные модели

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

Модели системного окружения

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

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

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

Поведенческие модели

При разработке требований к программной системе часто проще ответить на вопрос “как работает система?”, чем “что делает система?”. Ответ на этот вопрос дает модель поведения. (Заметим, что поведение реальной программной системы определяется кодом ее программы, таким образом, модель поведения – это описание алгоритма работы системы). Требования, предъявляемые к модели поведения, используемой на этапе разработки требований можно сформулировать следующим образом:

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

2. Средства моделирования поведения должны быть знакомы и привычны для большинства заинтересованных лиц.

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

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

Рассмотрим основные модели, используемые для описания общего поведения системы.

Модели потоков данных

Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты [5]:

· процесс (трансформационный процесс, системная функция, обрабатывающая единица) – механизм, описывающий способ получения выходных данных из входных данных;

· поток данных – определяющий перемещение данных (материалов) между процессами;

· хранилище – места хранения данных (базы данных, например);

· внешние сущности – объекты внешнего (по отношению к системе) мира.

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

Ценность моделей потоков данных в том, что они позволяют:

· представить бизнес-процесс или операцию, выполняемую системой, в виде совокупности этапов;

· проследить и документировать перемещение данных по системе, помогая понять этот процесс;

· учитывая их простоту и понятность, использовать модели для общения с пользователями, занятыми в разработке требований;

· описывать (при проектировании) принятые решения.

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

Пример 4.1.

На рис. 4.1 приведена контекстная диаграмма информационной системы архива, которая позволяет:

· записывать в архив подлинники программ;

· вносить в программы изменения;

· выполнять тиражирование программ.

Рис. 4.1

С системой общаются:

· разработчики, выдающие запросы на тиражирование программ и получающие копии программ;

· сотрудники архива, выполняющие прием и регистрацию подлинников программ, и внесение в них изменений (ИИ – извещение об изменении);

· магнитотека (хранилище) программ.

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

 

Рис. 4.2

При разработке диаграмм потоков данных следует придерживаться следующих общих правил:

· размещать на диаграмме не более 7 – 10 процессов;

· не загромождать диаграммы несущественными на данном уровне деталями;

· декомпозицию потоков данных выполнять параллельно с декомпозицией процессов;

· однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.

Модели конечных автоматов

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

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

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

Пример 4.2.

На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».

Рис. 4.3

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

Модели данных

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

ER-диаграммы

Наиболее широко используется моделирование данных типа “сущность – связь – атрибут”, определяющее структуру данных, их атрибуты и отношения между ними [9].

Для разработки моделей данных, обеспечивающих стандартный способ определения данных и отношений между ними, служат диаграммы “сущность-связь” (Entity-Relationship Diagrams, ER-диаграммы). ER-диаграммы позволяют идентифицировать сущности (объекты, важные для предметной области), свойства сущностей – атрибуты – и связи (отношения) между сущностями.

Под сущностью (entity) в ER-диаграммах понимается множество экземпляров реальных или абстрактных объектов (людей, предметов, событий и т.д.). Любой объект системы может быть представлен только одной уникально идентифицированной сущностью, имя которой должно отражать тип (класс) объектов, а не его конкретный экземпляр. Связь (relation) – это именованное отношение между двумя и более сущностями, а атрибут (attribute) – любая характеристика сущности, причем множество значений всех атрибутов должно однозначно идентифицировать экземпляр сущности. Более подробно описание ER-диаграмм и методика их использования для моделирования структур данных приведены в [9], а мы ограничимся примером.

Пример 4.3.

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

 

Рис. 4.4

Словарь данных

Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.

Словарь данных позволяет:

· определить механизм управления именами, позволяющий избежать дублирования;

· связать различные этапы проектирования системы.

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

Прототипы

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

4.3.1. Роль прототипов при разработке требований

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

Прототип полезен в решения следующих задач:

1. Разработка требований.

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

2. Проверка требований.

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

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

Прототип позволяет реализовать различные варианты взаимодействия, исследовать альтернативные решения и выбрать оптимальный вариант.

4. Спецификация системных требований.

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

Виды прототипов

Горизонтальные прототипы

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

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

Вертикальные прототипы

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

Разработка прототипов

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