Требования в гибких методологиях
В противовес прогнозирующим методологиям создания программного обеспечения, относительно недавно сформировалась парадигма гибких (Agile) методологий. В феврале 2001 г. инициативная группа из 17 специалистов объединилась в Альянс гибкой разработки программного обеспечения. Эта группа разработала и приняла Манифест гибкой разработки:
· Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов
· Работающее программное обеспечение ВЫШЕ всесторонней документации
· Сотрудничество с клиентами ВЫШЕ переговоров по контракту
· Реакция на изменения ВЫШЕ следования плану и 12 приложений (в столь же лаконичной форме) к нему 1.
В определенной степени в противовес всему тому, что было сказано в предыдущих лекциях, члены Альянса ставят под сомнение необходимость всестороннего моделирования и документирования требований и даже посягают на святое святых - планы и контракты.
На сегодня "быть гибким" стало модным. Апологеты методологий, заклейменных членами Альянса, как "прогнозирующие" и даже "тяжеловесные" вступают в дискуссии - можно ли считать адаптированной ту или иную методологию на "гибкие рельсы". Так, опубликованы как минимум два варианта гибкой трансформации для RUP; MSF опубликовало нотацию Agile MSF.
Артефакты для работы с требованиями в гибких методологиях
С позиций работы с требованиями основными средствами, которыми оперируют гибкие методологии, являются карты представления системы, истории пользователей, приемочные тесты и CRC-карты [15.3-15.4].
|
|
|
Карта представления в определенной степени заменяет документ "концепция", принятый в прогнозирующих методологиях. В отличие от концепции, представление - это текст размером в 20-30 слов, умещающийся на небольшой (размером с визитную) карточке.
Истории пользователей (user story) очень сильно напоминают краткие описания вариантов использования. Особенности историй пользователя - в том, что они, во-первых, должны быть действительно краткими (также умещаться на карточке), во-вторых - в том, что это - действительно истории пользователей, т.е. рассказы о том, как они планируют использовать систему. Использование историй пользователя исключает ситуацию, когда аналитик что-то придумал (домыслил) за пользователя - отнюдь, эти артефакты создают сами пользователи. Истории пользователя должны иметь осмысленные наименования и номера.
Истории пользователя, помимо базового функционала, могут содержать декорации, очень напоминающие ориентиры RUP (см. "Расширенный анализ требований. Иллюстрированные сценарии и прототипы" ).
Приемочные тесты обычно пишут на обратной стороне карты с соответствующей историей пользователя. Шаблон, используемый в методологии XP, содержит 3 предложения:
|
|
|
· Установка (контекст; инициирующее событие),
· Операция (функция с количественными характеристиками),
· Подтверждение (результаты исполнения функции).
CRC-карты (Класс-Ответственность-Кооперация), как и предыдущие 3 артефакта, представляют собой небольшие карточки, в заголовке которых представлено название класса, а ниже - таблица в две колонки. В левой колонке перечислены ответственности (т.е. высокоуровневый взгляд на его методы) класса, в правой - классы, состоящие в кооперации с рассматриваемым классом.
Планирование на основе требований на примере XP
Планирование включает следующие работы:
· оценивание,
· планирование версий и итераций.
Оценивание представляет собой определение объема работ в разрезе историй пользователя. Каждая история оценивается в пунктах. Один пункт равен "идеальной" (сорокачасовой) неделе, целиком посвященной программированию. Если оценка лежит в пределах от 1 до 3 пунктов - то он ставится на карточке истории. Если оценка менее 1 - на карточке ставится 0. Это - так называемый "песок". Если оценка превышает 3 пункта - мы имеем дело с "эпопеей". В этом случае карточка помечается, как "split" и подлежит процедуре разделения. Другая стратегия работы с такой карточкой -попытаться вместить ее в оптимальный срок путем исключения декораций. В случае, если история пользователя сложна для экспресс-оценки - необходимо провести исследование или "гвоздь" планирования.
|
|
|
Планирование версий и итераций
Планирование в XP базируется на следующих основных понятиях: производительность, приоритеты, стоимость версии, составление плана версий, составление плана итераций.
Производительность или быстродействие команды базируется на оценках пунктов истории. Однако необходимо учитывать, что пункты представляют идеальные оценки, кроме того существенную роль имеет опыт команды в оценивании (для начинающих команд возможна значительная погрешность).
Ключевую роль в назначении приоритетов играет, безусловно, заказчик. Однако и Разработчик имеет право голоса при отборе историй, которые должны попасть в версию (вопросы архитектуры, ключевой функциональности и т.п.).
Стоимость версии определяется, базируясь на производительности, приоритетах и сроках.
План версий дает Заказчику начальное понимание стоимости проекта. Эта оценка дает ему возможность отказаться от проекта в начальной его стадии, если сроки и (или) цена являются неприемлемыми.
В случае, если план версий принят - составляется план итераций, отражающий шаги (итерации), которые необходимо проделать, чтобы добиться требуемой функциональности продукта.
Дата добавления: 2021-03-18; просмотров: 78; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!