Тема13: Современные методы совершенствования процессов работы с требованиями

1) Требования в гибких методологиях

С точки зрения современных терминов все рассмотренные выше методологи, включающие работы по построению, сопровождению и модификации требований с упором на их моделирование и анализ носят название «прогнозирующие».

Качество и надежность таких методологий достигается достаточно большим объемом трудозатрат.

В противовес прогнозирующим методологиям создания программного обеспечения, относительно недавно сформировалась парадигма гибких (agile) методологий.

В феврале 2001 г. инициативная группа из 17 специалистов объединилась в Альянс гибкой разработки программного обеспечения.

Эта группа разработала и приняла Манифест гибкой разработки, включая 12 пунктов.

Среди них имеются:

-Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов

- Работающее программное обеспечение ВЫШЕ всесторонней документации

- Сотрудничество с клиентами ВЫШЕ переговоров по контракту

- Реакция на изменения ВЫШЕ следования плану и тд.

В определенной степени члены Альянса ставят под сомнение необходимость всестороннего моделирования и документирования требований и даже посягают на святое святых - планы и контракты.

На сегодня "быть гибким" стало модным.

Т.о. и методологии, изложенные выше, включая RUP, переходят на «гибкие рельсы».

Так, например

-опубликованы как минимум два варианта гибкой трансформации для RUP;

- MSF опубликовало нотацию agile MSF.

Возникли и чисто гибкие методологии, например, методология XP.

2) Артефакты для работы с требованиями в гибких методологиях

С позиций работы с требованиями основными средствами, которыми оперируют гибкие методологии, являются:

-карты представления системы,

-истории пользователей,

-приемочные тесты,

-CRC-карты.

Поясним их детальнее.

Карта представления в определенной степени напоминает документы "видения". Это текст размером в 20-30 слов, умещающийся на небольшой (размером с визитную) карточке.

Истории пользователей (user story) очень сильно напоминают краткие описания вариантов использования. Особенности историй пользователя - в том, что они

- во-первых, должны быть действительно краткими (также умещаться на карточке),

- во-вторых - в том, что это - действительно истории пользователей, т.е. рассказы о том, как они планируют использовать систему.

Использование историй пользователя исключает ситуацию, когда аналитик что-то придумал (домыслил) за пользователя, т.к. эти артефакты создают сами пользователи.

Истории пользователя должны иметь осмысленные наименования и номера.

Приемочные тесты обычно пишут на обратной стороне карты с соответствующей историей пользователя. Шаблон, используемый в методологии XP, содержит 3 предложения:

- Установка (контекст; инициирующее событие),

- Операция (функция с количественными характеристиками),

- Подтверждение (результаты исполнения функции).

CRC-карты (Класс-Ответственность-Кооперация) можно было бы назвать аналогом прототипа.

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

В левой колонке перечислены ответственности (т.е. высокоуровневый взгляд на его методы) класса.

В правой - классы, состоящие в кооперации с рассматриваемым классом.