Анализ требований Copyright © Мухортов В. В., Няньчук-Татарский Н. А., 2001-2005 Copyright © ООО «Интекс», 2003-2005. - презентация

1 Анализ требований Copyright © Мухортов В. В., Няньчук-Татарский Н. А., Copyright © ООО «Интекс»,

2 Процесс разработки ПО Анализ требований и предметной области Системный анализ Проектирование и реализация Сопровождение и развитие

3 О важности анализа требований 31% проектов – остановлены до завершения 53% проектов стоили 189% от первоначальной оценки В крупных компаниях 9% проектов выполнено в срок и без превышения бюджетов. В мелких компаниях 16% проектов выполнено в срок и без превышения бюджетов. - Отчет Standish Group, 1994, (проанализировано 8000 проектов)

4 Источники ошибок Недостаточное количество информации от пользователей- 12,8% Неполные спецификации- 12,3% Изменения требований % Отчет Standish Group, 1994, (проанализировано 8000 проектов)

5 Проекты US Air Force Источники ошибок Требования- 41% Проектирование - 28% Данные- 6% Интерфейс- 6% Окружение- 5% Человеческий фактор- 5% Документация- 2% Остальные- 7% Sheldon F., Reliability Measurement from Theory to Practice, 1992

6 Стоимость ошибок в требованиях Относительная стоимость исправления ошибок (по фазам) Инициирование проекта- 0,1 – 0,2 Проектирование - 0,5 Кодирование- 1 Компонентное тестирование- 2 Тестирование в момент приемки- 5 Использование и поддержка Davis A., Software Requirements – Objects, Functions and States, 1993

7 Документирование требований Основным средством документирования требований является текст на естественном языке. Проблемы: Неоднозначность интерпретации Слабое структурирование информации Сложность оценки полноты, непротиворечивости и трудозатрат

8 Варианты использования (use cases) Вариант использования (use-case) есть средство структурирования требований, Вариант использования описывает соглашение между заинтересованными сторонами (stakeholders) о поведении системы. ( По Alistair Cockburn, Writing the effective Use-Cases)

9 Заинтересованные стороны Заинтересованные стороны: Пользователи системы Другие системы Заинтересованные стороны называются актерами или актантами (Actor) Актер не является конкретным человеком, а определяет набор ролей в системе.

10 Варианты использования Actor – внешнее по отношению к системе действующее лицо, некто (или нечто), взаимодействующее с системой. Use case – некая последовательность действий системы, представляющая ценность для Actor-а, вариант использования системы (Ivar Jacobson). Use- case описывает, что делает система, но не указывает как.

11 Актер Имеет имя (наименование роли) Находится вне системы Заинтересован в функционировании системы По отношению к use-case может быть: активным – инициирует выполнение UC пассивным – так или иначе участвует в выполнение UC

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

13 Документирование use-cases Имя Основная цель (Goal in context) Основной(-ые) актер(-ы) (Primary actor(s)) Предусловие (Precondition) Постусловие (Postcondition) Условие начала действия (Trigger condition) Точки расширения (Extension points) Сценарии достижения цели Основной сценарий (main success scenario) Альтернативный сценарий 1 (alternative scenario) …

14 Диаграммы вариантов использования Варианты использования Актеры Отношения между актерами и вариантами использования

15 Пример: Экзамен Teacher принимает экзамен у Student.

16 Генерализация actor-ов Различные actors могут играть одну и ту же общую роль в некотором use-case

17 Включаемые use-cases Stereotype: > Различные use-cases могут иметь общие части Абстрактный use-case не имеет непосредственной ценности для актера

18 Семантика отношения включения

19 Расширение use-cases Stereotype: > Некоторые use-cases могут вызываться в контексте других только при некоторых условиях

20 Семантика отношения расширения

21 Генерализация вариантов использования Иногда два use-case-а могут иметь некоторую общую последовательность действий. Для того, чтобы показать эту общность используется генерализация use-case-ов.

22 Семантика генерализации вариантов использования

23 Замечания Use-case должен описывать ЧТО делает система, но НЕ КАК => Глубокие иерархии use-cases чаще всего бесполезны и ведут к функциональной декомпозиции => Большое количество мелких use-case не прибавят понимания того, что делает система

24 Типичные ошибки документирования Большое количество информации о пользовательском интерфейсе Отсутствует основной actor Слишком высокая детализация Не описаны действия системы

25 Диаграммы состояний Описывают состояния объекта и переходы между состояниями State – некое состояние объекта Event – событие, вызывающее переход Transition – переход в новое состояние Condition – условие перехода (true|false) Action – мгновенное непрерываемое действие, сопровождающее переход Activity – деятельность, связанная с состоянием

26 Пример: сдача экзамена

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

28 Пример: состояния с историей Н – недавнее историческое состояние Н* - глубокое историческое состояние

29 Диаграммы деятельностей Описывают последовательности действий используются для описания операций и вариантов использования Activity - деятельность Transition – переходы между деятельностями Guard condition – условие перехода Decision – блок принятия решения Concurrent threads – параллельные деятельности Synchronization bar – линейка синхронизации параллельных деятельностей

30 Пример: банкомат