Лекция 3. Процесс управления требованиями.

 

Таким образом,  с точки зрения системной инженерии, ЖЦ систем и программной инженерии, ЖЦ ПО согласно ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» ЖЦ ПО определяет структуру из процессов, действий и задач. Процессы состоят из набора действий, действия – из набора задач. Причём выполняются и инициируются другим процессом по необходимости, и не существует заранее определённых последовательностей выполнения. Связи по входным данным при этом сохраняются.

 

Процессы разделяются на три основных группы:

· Основные

· Вспомогательные

· Организационные

 

Процессы состоят из действий, действия из задач.

 

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

Это означает, что некоторые процессы выполняются постоянно, всё время (а не в ходе отдельных стадий ЖЦ).

 

Такие процессы выделены отдельно.

· Процесс управления конфигурацией

o Документация, модели, НСИ, и прочие артефакты из ЕИП/ЕИМ должны находиться в управляемых условиях и изменяться согласно описанным процессам

o Должна быть определена базовая конфигурация

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

o Изменения должны утверждаться в ходе другого процесса

 

· Процесс оценки и контроля качества ( Q & A ) и решения проблем

o Сборка комплексировка продукта собранной конфигурации

o Тестирование

o Решение проблем

 

· Процесс планирования выпусков (релизов)

o по результатам процесса Q&A принимается решение о готовности функций продукта и выпуска

o функции сортируются по приоритетам

o составляются контрольные списки для оценки готовности к релизу

o используется adaptive case management и issue tracker , bug tracker для отслеживания прогресса согласно ЖЦ ошибки (ЖЦ заявки, issue)

 

· Процесс управления требованиями

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

o Анализ и оценка требований на противоречивость, техническую реализуемость, трудоёмкость, желательность

o Выработка приоритетов для сортировки требований

o Определение контекста проекта, области действия системы, требований к квалификации, технологии, команде

Существуют системы управления требованиями (СУТ, RM: Requirements Management), такие как Rational/IBM DOORS, 3GS Cradle, CaliberRM, RequestTracker, ClearCase и т.п.

 

Это CASE-системы, представляющие из себя поддержку процесса управления требованиями и обеспечивающими:

· Совместную, групповую работу

· Захват требований из внешней документации (в формате Word,  PDF, XML и проч.)

o Определена и унифицирована структура разделов документации

· Моделирование требований

· Сортировку приоритетов

· Создание матриц трассировки (прослеживаемости) требований по релизам, архитектуры по требованиям, реализации (кода) по требованиям

· Возможность определения собственных метаданных, файлов-вложений, структуры базы данных, показателей

· Экспорт требований в виде Word и т.п. документации

o Генерацию документов определённой структуры разделов

o Наполнение по шаблону из базы данных

o Содержание из матриц трассировки

o Контроль ссылочной целостности

· Экспорт состояния проекта, матриц прослеживаемости

· Веб-интерфейс, тонкий или толстый клиент для групповой работы

· Интеграцию с внешними BPM, СЭД системами

 

Терминология СУТ:

· SR – Source Requirements, исходные требования заказчика к системе

· FR – Functional Requirements , функциональные требования (что должна делать система)

· NFR – Non - Functional Requirements , нефункциональные требования (к быстродействию, удобству использования, эргономичности, понятности, а также: цели и назначение системы, цели заинтересованных лиц, ограничения, контекст и условия выполнения конкретных функций, действий, процессов, прецеденты и use cases разрабатываемой системы)

· SBS – System Breakdown Structure (структура декомпозиции системы на компоненты, размещения, роли (тип связей))

 

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

 

· Управлять проектом – определять приоритеты, оценивать неопределённость, оценивать ход работ, определять объём работ, корректировать план проекта, управлять ресурсами

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

· Анализировать исходные требования, проводить декомпозицию составных непонятных на элементарные понятные, проводить декомпозицию SR на FR и NFR, сортировать по приоритетам и проектировать систему (SBS)

· Тестировать проектные решения (SBS) – проверяя решения и требования на конфликты в требованиях, проверка на тех. реализуемость, противоречивость, полноту

· Выпускать техническое задание

 

Процесс управления ТР:

Системный аналитик фиксирует SR, анализирует и оценивает их, расставляет приоритеты и оценивает объём работ, проводит декомпозицию SR на FR и NFR до тех пор, пока не соберёт данных требований достаточно для понимания структуры SBS и тестирования её на полноту и непротиворечивость, безконфликтность, понятность, реализуемость и достаточность FR и NFR, после чего выпускает техническое задание (ТЗ).

 

Примером CASE-системы для RM (СУТ) является 3SL Cradle.

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

Позволяет проектировать систему, управлять изменениями и выпускать ТЗ в результате работы аналитика.

Поддерживает процессы:

· Управление требованиями

· Системное проектирование, включая проектирование архитектуры

· Управление рисками и задачами проекта

· Управление тестами

· Аудит проектных решений и оценка влияния изменений

· Оценка состояния, хода выполнения и других показателей проекта (включая KPI)

· Управление конфигурацией, процедуры согласования, история изменений

· Публикация исходящих документов

 

Поддерживает API для программирования и интеграции с внешними системами (СЭД, BPM, MS Project).

 

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

Архитектурные:

• Architecture Interconnect Diagram (AID),

• Physical Architecture Diagram (PAD);

Функциональные и процессные:

• Data Flow Diagram (DFD),

• Entity Relationship Diagram (ERD),

• State Transition Diagram (STD),

• Data Structure Diagram (DSD),

• IDEF0 (IDF),

• Behaviour Diagram (eFFBD),

• Process Flow Diagram (PFD);

UML:

• Use Case Diagram (UCD),

• Package Diagram (PD),

• Sequence Diagram (SQD),

• Collaboration Diagram (COD),

• Class Diagram (CD),

• Statechart Diagram (SCD),

• Activity Diagram (ACD),

• Component Diagram (CPD),

• Deployment Diagram (DPD)

а также Structure Chart (STC),

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

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

 

Из OpenSource систем существуют, например шаблоны для заполнения проектных документов, такие, как ReadySET templates в виде XML-документов из проекта CollabNet tigris.com (автора Subversion). Позволяют в краткой форме ответить на вопрос о целях и задачах проекта, зафиксировать проектные требования, задать контрольные списки (checklist).

 

Основная ценность RM (СУТ) систем – в поддержке в среде CASE-систем процесса RM (управления требованиями) обеспечивая трассируемость (прослеживаемость), и целостность процесса управления конфигурацией, а также системное проектирование SBS и FR, NFR из SR, с учётом гибких связей, ролей, аннотаций, шаблонов документов и моделей.