4.7. Управление требованиями
Требования к крупномасштабным системам постоянно меняются. Для этого есть много причин. Во-первых, когда система знаний о внешнем мире практически никогда не бывают исчерпывающей, во-вторых, со временем меняется сама окружающая среда, в третьих, заказчики (покупатели) системы – это не одни и те же люди. Как правила закупками занимаются менеджеры, конечные пользователи – это специалисты в предметной области, и их понимание требований могу отличаться.
Процесс управления требованиями можно определить как процесс отслеживания изменений требований к системе. Организация этого процесса состоит в том, чтобы организовать поток запросов на изменения требования от всех заинтересованных сторон. Этот процесс может стартовать после появления первого варианта списка требований. Процесс управления требованиями включает 3 фазы: анализ проблемы и изменение спецификации, анализ предлагаемых изменений, включая оценку стоимости изменений, реализация изменений. При этом в обсуждении должны принимать участие заинтересованные стороны, которые являлись инциаторами процесса изменений требований. Фаза анализ предлагаемых изменений – это, прежде всего, оценка стоимости изменений в денежном и временном исчислении. Содержание фазы реализация изменений зависит от того, на какой стадии жизненного цикла находится система. В простейшем случае, если команда не приступила к проектированию – это может быть переделка спецификации требований. Если система уже спроектирована и находится в эксплуатации, то может потребоваться модификации системы. В этом случае разрабатывается план перехода на новую версию системы.
4.8. Инструментальные средства поддержки процесса разработки требований
На современном уровне развития ИС аналитикам и системным архитекторам необходимо иметь эффективные средства управления требованиями для выработки архитектурных решений. Управление требованиями – это процесс, в рамках которого осуществляется первичное накопление, формирование, анализ и последующий контроль за реализацией потребностей заинтересованных сторон, а также дальнейшее управление изменениями информации на протяжении всего жизненного цикла проекта.
Структурирование требований является наилучшим способом их организации, позволяя более эффективно управлять ими во избежание дублирований или пропусков. При работе с требованиями следует иметь в виду, что процесс управление требованиями, с одной стороны, - это процесс обмена информацией между заинтересованными сторонами, а, с другой стороны, требования – это язык общения между заинтересованными сторонами. Поэтому важно, чтобы требования корректно передавали смысл и правильно связывались между собой. Процесс работы с требованиями – крайне ответственный и слабо формализуемый процесс. Над формированием требований должна работать команда, которая включает все категории заинтересованных лиц, в состав которых входят аналитики, архитекторы, конечные пользователи, менеджеры разного уровня, эксперты и т.д. Для поддержки процесса работы с требованиями уже создано и продолжают создаваться инструментальные средства. В разные годы были популярны такие пакеты коммерческие пакеты как: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, имелись также и бесплатные системы, такие как OSRMT — Open Source Requirements Management Tool. Эти инструменты имели разные функциональные возможности и, соответственно, существенно разную стоимость.
В основу функционирования инструментальных средств, поддерживающих работу с требованиями, положена объектная модель представления требований. Требования представляются в виде совокупности объектов, имеющих атрибуты.
В качестве атрибутов требований могут выступать такие параметры как: приоритет (priority), состояние (status), стоимость (cost), трудность при реализации (difficulty), стабильность (stability), назначенный (assigned to), источник (origin). Могут существовать иерархии требований. Можно описать взаимозависимости между требованиями. Между требованиями могут существовать связи типа связи родитель-потомок, может быть реализован механизм наследования. Иерархические связи позволяют представить общие требования как совокупность частных требований. Общепринятой объектно-ориентированной модели работы с требованиями нет. Объектные модели, реализованные в разных системах работы с требованиями отличаться.
На момент написания данного учебника одной из наиболее мощных и популярных систем управления требования была система DOORS (Dynamic Object Oriented Requirements System) - динамическая объектно-ориентированная система для работы с требованиями. Первоначально продукт был разработан компанией QSS Ltd (Оксфорд), затем был приобретен, компанией Telelogic, затем был приобретен фирмой IBM и включен в состав группы продуктов IBM Rational под названием Rational DOORS. На момент написания учебника последней была версия версии 9.5.
Rational DOORS -инструментальное средство управления требованиями. DOORS является многоплатформенной системой управления и анализа требований, которая предназначена для хранения и управления информационными объектами различных типов, для создания связей между ними. DOORS обладает мощным, интуитивно-понятным навигационным механизмом, обеспечивающим удобство работы с требованиями.
Архитектура DOORS. В DOORS все требования и связанная с ними информация хранятся в центральном репозидарии (БД), который, в идеале, поддерживаться в актуальном состоянии на протяжении всего жизненного цикла приложения.
В DOORS репозитарий организован в виде дерева, для построения которого используются 3 типа элементов (рис. 4.3): папки (folder), проекты (project) и модули (module). Собственно информация хранится в модулях. Проекты и папки используются в качестве контейнеров. Проект – это папка, предназначенная для хранения информации, относящейся к данному проекту или подпроекту.
Рис. 4.3. Структура базы данных DOORS
Папки напоминают каталоги файловой системы. Они могут содержать другие папки, проекты и модули. Каждая папка имеет собственное имя и описание (характеристику). Доступ к каждой папке может быть ограничен для каждого пользователя и регулируется правами доступа. Проекты используются группами специалистов для организации данных, относящихся к их совместной работе. В них хранится вся информация по конкретному проекту, касающаяся требований, спецификаций, разработки, тестирования, выпуска и поддержки приложения. В рамках проекта имеется возможность назначать права доступа ко всей информации, содержащейся в данном проекте, делать резервные копии данных, а также экспортировать блоки данных в другие базы данных DOORS. Собственно данные в DOORS хранятся в модулях, при этом определяются 3 типа модулей:
формальные (formal), предназначенные для хранения структурированных наборов данных;
описательные (descriptive), предназначенные для хранения неструктурированной первичной информации, такой как заметки сделанные в ходе интервью, переписка и т. п.;
линки (link), предназначенные для хранения информации о связях между требованиями.
Пользовательский интерфейс DOORS очень похож на интерфейс Windows Explorer и позволяет легко и удобно просматривать содержимое модулей по схеме Папка Проект Модуль. В окне DOORS подобно тому, как это делается в Windows Explorer, пользователь может управлять структурой БД. Можно создавать, перемещать, переименовывать, удалять и просматривать содержимое папок, проектов, модулей. Пользователь может просматривать содержимое БД различным способов, для этого используется система видов (View): стандартный вид (Standard View), оглавление (Outline View) и иерархическое представление (Explorer View). В первом случае содержимое БД отображается как текстовый документ, во втором – отображаются только заголовки, а в третьем отображается в виде иерархической структуры. Кроме того, имеется возможность работы с графикой и таблицами.
В DOORS поддерживается механизм работы с версиями, которые называются baseline. Версии создаются обычно по завершению определенных стадий проекта. Каждой зафиксированной версии модуля присваивается номер и название. Версии модуля нельзя редактировать.
Каждый модуль имеет атрибуты. Существуют 2 типа атрибутов: системные атрибуты и атрибуты, определяемые пользователем. Системные атрибуты автоматически создаются системой для хранения важной системной информации (дата, временя создания модуля или объекта, автор, автор вносимого изменения и т. д). Атрибуты, определяемые пользователем, предназначены для поддержания собственного уникального процесса управления требованиями. В DOORS имеются атрибуты по умолчанию, пользователь может добавлять к ним собственные атрибуты.
Информацию, содержащуюся в атрибутах, можно просматривать и редактировать на экране, а также выводить на печать, при этом имеется возможность выводить на экран только интересные пользователю в данный момент атрибуты. Используя механизмы работы с видами и фильтры можно анализировать требования. Например, если требуется уменьшить стоимость разработки, то можно легко найти объекты модуля, у которых атрибут «Приоритет» имеет значение «Низкий» с целью исключения проекта отдельных функций.
В DOORS пользователь может устанавливать связи между объектами, и предоставляются средства трассировки. Связи всегда направлены от источника к цели, что позволяет представлять структуру связей как в виде иерархической (древовидной) структуры, так и в виде сетевой структуры. Следует заметить, что пользователь может переходить по связям между объектами в обоих направлениях, что позволяет легко выполнить анализ влияния изменения, вносимого в один документ, на связанные объекты во всех других документах, а также предоставляет возможность разыскать ту информацию, которая послужила причиной для принятия того или иного решения.
DOORS позволяет создавать отчеты, отражающие связи между объектами с помощью анализатора связей (Traceability Explorer), который позволяет пользователю в одном окне видеть связи сразу между многими документами.
В DOORS имеется встроенный предназначенный для расширения функций и управления ими, который называется Rational DOORS eXtension Language (DXL). DXL - это простой язык сценариев, который предназначен для автоматизация рутинных и сложных задач, таких как вычисление значений атрибутов, обработки событий путем активации пользовательских программ и добавления в меню собственных пунктов. Синтаксис DXL близок к синтаксису таких языков как C и C++.
DOORS предоставляет широкие возможности импорта и экспорта информации из документов, таблиц и баз данных, включая RTF, Word, Excel, Access, Plain Text, HTML, PowerPoint, MS Project и многих других.
Для моделирования на UML с помощью можно использовать приложение DOORS/Analyst, которое является результатом интеграции DOORS с продуктом IBM Rational Tau, что позволяет создавать UML модели и диаграммы непосредственно в формальных модулях DOORS, размещая их внутри объектов.
В заключение следует заметить, что система DOORS является одной из мощных и дорогих систем работы с требованиями и ориентирована, прежде всего, на проектирование крупномасштабных систем [60, 61,62, 65].