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

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

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

• Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов
• Работающее программное обеспечение ВЫШЕ всесторонней документации
• Сотрудничество с клиентами ВЫШЕ переговоров по контракту
• Реакция на изменения ВЫШЕ следования плану и 12 приложений (в столь же лаконичной форме) к нему ¹⁾.

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

На сегодня "быть гибким" стало модным. Апологеты методологий, заклейменных членами Альянса, как "прогнозирующие" и даже "тяжеловесные" вступают в дискуссии - можно ли считать адаптировать ту или иную методологию на "гибкие рельсы". Так, опубликованы как минимум два варианта гибкой трансформации для RUP; MSF опубликовало нотацию agile MSF.

С позиций работы с требованиями основными средствами, которыми оперируют гибкие методологии, являются карты представления системы, истории пользователей, приемочные тесты и CRC-карты [15.3-15.4].

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

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

Истории пользователя, помимо базового функционала, могут содержать декорации, очень напоминающие ориентиры RUP (см. лекцию 10).

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

• Установка (контекст; инициирующее событие),
• Операция (функция с количественными характеристиками),
• Подтверждение (результаты исполнения функции).

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

Дата добавления: 2014-11-29