11. Управление требованиями к информационной системе. ГосТы и методология rup

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

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

3. Документированное представление условий или возможностей для пунктов 1 и 2.

В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества) Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге. Требование должно обладать следующими характеристиками:

1. Единичность — требование описывает одну и только одну вещь.

2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

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

5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.

6. Актуальность — требование не стало устаревшим с течением времени.

7. Выполнимость — требование может быть реализовано в рамках проекта.

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

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

10. Проверяемость — реализованность требования может быть проверена.

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

1. Функциональные (Functional) — реализуют саму бизнес-функцию.

2. Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.

3. Эргономические (Usability) — к удобству работы конечных пользователей.

4. Архитектурные (Architectural) — требования к архитектуре системы.

5. Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.

6. Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

7. Существуют различные подходы к созданию информационных систем, основанные на определенной модели их жизненного цикла (каскадной, поэтапной с промежуточным контролем, спиральной). Но все эти походы предусматривают обязательное построение бизнес-модели организации, которое выполняется на одном из начальных этапов проекта по созданию или внедрению КИС. Например, канонический подход, рекомендуемый ГОСТ 34.601-90, предусматривает следующие стадии создания КИС: формирование требований к системе; разработка ее концепции; разработка и утверждение технического задания; эскизное проектирование; техническое проектирование; разработка технической документации; ввод в действие; сопровождение системы.

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

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

10. Одним из подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является методология быстрой разработки RAD (Rapid Application Development). Создание системы по методологии RAD включает четыре фазы: анализ и планирование требований; проектирование; построение; внедрение.

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

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

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