Ведение требований на несколько версий продукта

All you need is www.uml2.ru

Ведение требований на несколько версий

Ирина Сурова

Летний Аналитический Фестиваль 2010

План

1. Организация требований в пределах 1 версии

2. Варианты ветвления версий

3. Схема работы при хранении требований в виде документов

4. Схема работы при хранении требований в виде модели


Ограничения

Для каждого проекта и продукта свои:

• Объем и степень детализации требований

• Роли – потребители требований

• форма представления требований


Разработка одной версии

Объем требований большой,

над требованиями работают несколько аналитиков:

Делим на области:

• Малосвязанные,

• С интуитивно понятными границами

• Полностью покрывающие функционал продукта


Разработка одной версии

Риски:

Мнения, на какие области надо делить, могут разойтись у разных ролей (аналитики, тестировщики, разработчики).

Что же делать?

Договариваться или делать трассировки


Последовательная итеративная разработка версий

Возникают вопросы:

• Какой функционал входил в версию Х?

• Когда появился функционал Z?

Появляются базовые линии (Base Line)


Почкование параллельных версий

1. Развилку отмечаем base-line’ом

2. Копируем требования для каждой версии

3. Каждая версия разрабатывается отдельно


Почкование параллельных версий

Риски:

Изменения, которые надо реализовывать в обоих версиях.

Что делать:

Дублировать изменения или вводить «прозрачную ветку» (держать в ветке только изменения)


Слияние и поглощение

Если версии планируется через какое-то время слить:

Ищем возможность реализовать compare&merge


Итого у нас такие варианты:

• Последовательность

• Ветки

• «Прозрачные» ветки

• Сливающиеся ветки


Главные вопросы

• Как увидеть требования на версию Х?

• Какие изменения входят в состав текущего проекта?

Еще возникающие вопросы:

• Чем версия Х отличается от версии Х+1

• Чем версия Х отличается от версии N

• Входило ли требование У в версию Х


Организация набора хранилищ

• Хранилище изменений требований для каждой разрабатываемой версии (изменения только в границах проекта)

• Полный набор требований на каждую разработанную версию


Word, и ничего кроме Word!

• Деление на документы по конкретным областям

• Хранение документов в системе версионного контроля (baseline)

• Режим сохранения изменений («прозрачные» ветки)

• Стандартный механизм рецензирования (compare & merge)


Модели – это наше все!

• Деление модели на пакеты по областям

• Механизм base-line средствами СУТ или СВК

• Изменения храним в виде отдельных элементов, копируя от базовой версии только диаграммы, трассируя изменяемые и удаляемые элементы

• Compare & merge средствами СУТ

А как это делаете

вы?

Ирина СуроваСистемный аналитикЛаборатория КасперскогоSkype: [email protected]

Ведение требований на несколько версий продукта

Technology

base line