Опубликовано от

Проектирование RUP/ICONIX. Третий этап

Содержание других частей.

Третьим этапом завершается первая веха проектирования — рецензирование требований. В ICONIX этих вех всего 4

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

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

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

В модели требований необходимо решить несколько задач.

  1. Собрать всё что говорит заказчик, со слов, с документов, с писем и т.п.. Все материалы важны со ссылками на источники.
  2. Внести (1) в структуру требований модели. Между элементами структуры имеются отношения, которые хорошо отображать как при помощи матрицы отношений, диаграммы требований и самой спецификации требований.
  3. Согласовать (2) с заказчиком.
  4. Задокументировать (3) и при необходимости экспортировать в документ, годный для заказчика (например выполнив по ГОСТ, применив или разработав подходящий шаблон отчёта Sparx EA).
  5. Утвердить подписями при необходимости. Требования можно превратить в формальный документ, по которому можно сверяться, трассируя выполнение обязательств на него и фиксируя это, например в ПМИ (в программе и методике испытаний).

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

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

В ходе этого этапа избегайте следующих ошибок.

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

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

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