Фазы жизненного цикла, их цели и контрольные точки (вехи)

Фазы жизненного цикла, их цели и контрольные точки (вехи)
Фазы
Фаза имеет внутри себя несколько итераций (возможно, одну). На каждой итерации могут
выполняться различные виды работ — рабочих и поддерживающих процессов.
Рабочие процессы связаны непосредственно с созданием продукта, поддерживающие —
помогают в этом (управление проектом, багтрекер, контроль версий, …).
Для чего выполняются итерации? Чтобы достигнуть целей каждой фазы.
Каждая фаза заканчивается контрольной точкой, подтверждающей выполнение целей (см.
раздел «Контрольные точки» ниже). А вовсе не созданием правильного набора красивых и
бесполезных артефактов: документов, диаграмм UML, …
Если контрольная точка еще не пройдена — нужно добавить итераций (вроде как) и чесать
репу, типа чо не так?.
Начало/Начальная фаза (Inception)
Идея: понять проект, получить как можно больше информации для обоснования, что он крут и
нужен (или что наоборот).
Цели:
1. Понять, что создавать
 Создать высокоуровневое Видение (Концепцию, Vision) — чудо-документ,
содержащий понимание, для чего вообще нужен проект и что он вообще будет
делать.
 Сформировать широкое, но неглубокое описание системы
i. Выделить хоть сколько-нибудь актеров. Актер — это человек или другая
система, взаимодействующая с нашей.
ii. Выделить прецеденты использования (юзкейсы, use cases) с их участием.
Кратко описать взаимодействие актеров с системой.
iii. Для каждого прецедента определить, требуется ли при его исполнении
взаимодействие с другими пользователями или системами. Если да — мы
нашли новых актеров, ура!
iv. Для каждого прецедента и актера описать (пару абзацев), про что они.
Главное, чтобы описанием занимался не один человек, а несколько, тогда
можно взглянуть на юзкейсы с разных сторон и понять, что упущено или
недопонято!
Чтобы выявить как можно больше валидных юзкейсов, мозговые штурмы!
v. Глоссарий, чтобы все говорили на одном языке.
vi. Выделить критичные/существенные (1..2) юзкейсов, без которых система
существовать не может или не имеет смысла. Они будут полезны при
реализации следующей цели.
2. Определить ключевую с точки зрения архитектуры функциональность (юзкейсы). Такая
функциональность:
 является ключевой для приложения или использует ключевые интерфейсы
системы;
 обязательно должна быть реализована (без нее выпуск приложения является
бессмысленным);
 охватывает область архитектуры, не охваченную иными, уже найденными
ключевыми юзкейсами.
3. Выявить хотя бы одно возможное решение
Понять, какую архитектуру, компоненты и технологии можно использовать для
создания приложения, как их необходимо развить (необходимо ли?). Грубо
оценить стоимость реализации и риски (типа «много-мало»).
Может потребоваться (в нашем случае — требуется) реализовать некоторые
ключевые элементы архитектуры (тот же контейнер-сетри Петри (тм), например),
чтобы оценить риск, возможные альтернативы и т.п. Да, на это йдет какое-то
время, зато будет показано, что в Видении были написаны не пустые слова, что
проект осуществим.
4. Выяснить стоимость, сроки, риски
Выявить затраты на реализацию проекта, установить сроки и четко прописать
основные риски проекта. Это все пишется в бизнес-кейс (business case) —
экономическое обоснование. Для нас достаточно записки + плана в прожекте
(наверное…)
5. Решить, какому процессу следовать и какие средства использовать
Задать Development Case (прецедент разработки) — чудесный документ,
определяющий какие собственно части RUP будут использованы (какие артефакты
создаем и фиксируем, какие похерили) и кто будет этим заниматься
(распределение ролей и времени участников проекта).
Умные аффторы рекомендуют периодически пересматривать прецедент
разработки, и вообще хранить его на видном месте, доступном для детей ,
например, на внутреннем веб-сайте проекта.
Итераций для мелких проектов: 1
Контрольная точка: веха целей жизненного цикла
Проектирование/Уточнение (Elaboration)
Идея: создать архитектурную основу («кости»), на которую в следующей фазе можно будет
нарастить конкретный функционал приложения («мясо»). Архитектура должна быть
исполняемой!!! Архитектурная основа — это основные подсистемы, их интерфейсы, ключевые
компоненты и механизмы, такие как межпроцессные коммуникации и хранение данных
(сериализация).
Цели:
1. Более глубоко понять требования. Убедиться в правильности понимания юзкейсов,
частично реализовав критичные юзкейсы. Получить информацию о
правильности/неправильности юзкейсов со стороны заинтересованных лиц. Результат —
уточнены все юзкейсы, реализованы самые главные, но частично.
2. Спроектировать, реализовать и протестировать базовую архитектуру («исполняемую
архитектуру») с помощью развития начального функционального прототипа с фазы
«Начало». Прогнать на ней основные юнит-тесты внешних интерфейсов (тесты API), тесты
нефункциональных требований (обработка ошибок, переконфигурирование,
востановление) и тесты под нагрузкой (на масштабируемость, производительность).
Архитектура, сцуко, должна быть масштабируемой и быстрой, иначе на ней можно
построить только дом из конопли, как в сказке «три поросенка и менеджер проекта».
Здесь, при реализации, принимаются решения типа «купим компонент или сделаем
сами», и в целом выбираются технологии, компоненты и их интерфейсы.
3. Снизить существенные риски и уточнить оценки сроков и стоимости. (Вследствие
детализации требований, теперь более понятно, сколько это будет стоить и сколько
займет времени). Составить план разработки оставшейся части системы в фазе
Построение.
4. Уточнить прецедент разработки (список используемых артефактов и ролей RUP) и
установить среду разработки (набор используемых для разработки инструментов).
Итераций для мелких проектов: 1
Контрольная точка: веха архитектуры жизненного цикла
Построение (Construction)
Идея: реализовать полноценную систему на базе того архитектурного каркаса, который создан в
фазе «Проектирование». Реализованная система может быть (и скорее всего, будет)
неоптимальной — недотестированной, не оптимизированной по производительности и т.д.
(Доводка — цель следующей фазы).
Цели:
I. Снижение стоимости разработки и повышение параллелизма
1. организация вокруг архитектуры (которая уже есть и работает! ура!). Каждый может
сконцентрироваться на своей подсистеме, но есть группа архитекторов, через которых
разные команды разработчиков могут связаться друг с другом (к нам это почти не
относится, нас слишком мало, чтобы сложность непосредственного общения была
высока).
2. укрепление архитектуры. существуют готовые архитектурные решения часто
встречающихся проблем, и используются только они, а не самопридуманные варианты,
которые наверняка меньше тестируются. поощряйте их использование.
3. непрерывный процесс разработки.
a. одна команда — одна задача! нет отдельно тестировщиков, отдельно аналитиков
— каждый участвует в общем деле, все многофункциональны
b. четкие, достижимые цели — каждый разработчик знает, что он должен сделать, и
согласен, что результаты достижимы
c. постоянная демонстрация и тестирование кода — покрыть всё юнит-тестами!
демо-запуски! публичная порка!
d. непрерывная интеграция — по возможности, ежедневные билды системы, чтобы
сломанные компоненты и/или связи между ними обнаруживались и фиксились
быстро
II. Разработка окончательного продукта, готового к показу конечным пользователям,
итеративным методом
1. Завершить описание оставшихся юзкейсов и прочих (в т.ч. нефункциональных) требований
2. Завершить проектирование верхних слоев архитектуры (низ, «фундамент», был завершен
на предыдущей фазе).
3. Спроектировать (откорректировать) базу данных по сравнению с черновой версией
предыдущей фазы: мелкие изменения, типа добавления представлений (views), индексов
и т.п.
4. Реализовать код и провести юнит-тестирование.
5. Провести интеграцию компонентов и системное тестирование (вся сборка в целом)
6. Раннее внедрение и обратная связь от юзеров-камикадзе (альфа-версии,
демонстрируемые пользователям).
7. Подготовиться к выпуску бета-версии: много тестирования и предварительного просмотра
релиза. Учитывать пожелания камикадзе из альфа-версии.
8. Подготовка к окончательному развертыванию: материалы для обучения (электронные и
печатные) [это нам не грозит], площадка (сайт) для развертывания [это нам не грозит],
подготовка к запуску (упаковка, тиражирование), обучение юзеров. Начинать с момента
выпуска бета-версии, а то и раньше. Заказчик должен видеть, что он покупает!
Итераций для мелких проектов: 3-4 (в книжке не написано, или я не нашел)
Контрольная точка: веха начальной функциональной готовности
Внедрение (Transition)
Идея: настроить (довести) продукт под конкретных потребителей: всесторонне протестировать и
обеспечить оптимальную производительность, а затем выпустить релиз. В процессе могут
вноситься мелкие изменения по просьбе пользователей, участвующих в бета-тестировании.
В отличие от модели типа «водопад» (она же «всёподряд» (с)) – мы приходим сюда с почти
готовой системой, которая (в идеале) постоянно интегрируется (каждодневный билд).
Цели:
I. Бета-тест
1. На предыдущей фазе была развернута бета-версия. Теперь выполняется бетатестирование, обеспечивающее обратную связь с пользователями. Информация от юзеров
анализируется, рецензируются запросы от пользователей на изменения, составляется
список необходимых изменений. Обычно такие запросы касаются мелких улучшений и
багфиксов. (Новые свойства на такой стадии добавлять допустимо, но только в крупных
проектах и с большой осторожностью. Нам — нельзя).
2. Полномасштабное регрессионное тестирование по мере доводки системы и реализации
последних нереализованных юзкейсов.
II. Обучение пользователей (мануалы, курсы (сначала обучаем инструкторов, затем они —
юзеров) и т.п.)
III. Подготовка площадки (сайта) для развертывания, конвертация рабочих баз данных (если
была пред. версия софта) — хитровымученные проблемы развертывания при работе
одновременно старой и новой системы и последовательного перехода к новой — к нам не
относится, пропускаем
IV. Подготовка упаковки, тиражирования, рекламных материалов, выпуск в дистрибуцию и
продажу — тоже почти ничего к нам не относится. Может быть, инсталлятор сделать и на сайт
выложить 
V. Достижение соглашения с заинтересованными лицами о том, что развертывание завершено
VI. Повышение производительности в будущем на основе полученного опыта («что было
хорошо, что было плохо, как нельзя делать?»)
Итераций для мелких проектов: 1
Контрольная точка: веха готового продукта
Контрольные точки
Ниже приводятся условия прохождения контрольных точек каждой из фаз.
Если эти условия не выполнены, либо новая итерация, либо проект закрывается, либо какие-то
иные крайние меры (зависит от того, насколько мы опаздываем).
Контрольная точка целей жизненного цикла (фаза Начало)
Если проект дошел досюда и не удовлетворяет критериям контрольной точки, его надо отменить
или серьезно пересмотреть.
- Заинтересованные стороны согласовали границы проекта, его стоимость и сроки.
- Есть согласие в том, что оценка стоимости и сроков, приоритеты задач, риски и
выбранный процесс разработки приемлемы.
- Есть согласие в том, что первоначальные риски выявлены и предъявлена стратегия
борьбы с каждым из них.
- Есть согласие в том, что зафиксирован верный набор требований и существует общая
точка зрения на эти требования.
- Показано, что проект выполним:
- выявлено хотя бы одно возможное решение (хотя бы одна возможная
архитектура);
- такое решение демонстрируется в виде функционального прототипа
(практически обязательно);
- Показано, что проект является выгодным с экономической точки зрения. Возможно, но
не обязательно, составлено формальное экономическое обоснование (business case).
Контрольная точка архитектуры жизненного цикла (фаза
Проектирование)
Если проект дошел досюда и не удовлетворяет критериям контрольной точки, его надо отменить
или серьезно пересмотреть.
- Является ли Видение (Концепция) и требования проекта стабильными?
- Является ли стабильной архитектура?
- Проверены ли основные подходы, которые будут использоваться при тестировании и
оценке системы?
- Показало ли тестирование и оценка исполняемых прототипов, что борьба с основными
рисками (ненадежности/немасштабируемости/и т.д…) привела к их устранению?
- Являются ли планы итераций на фазу Построение достаточно подробными и точными,
чтобы можно было продолжать работу?
- Согласны ли все заинтересованные лица с тем, что текущее Видение (как оно
определено в соотв. документе) м.б. реализовано, если для разработки всей системы
применяется текущий план фазы Построения и текущая архитектура?
- Приемлема ли разница запланированных и реальных расходов?
Контрольная точка начальной функциональной готовности (бетаверсии) (фаза Построение)
-
Является ли созданный релиз стабильным и зрелым настолько, что его можно
предъявить сообществу пользователей (бета, а не альфа- версия)?
- Готовы ли все заинтересованные лица к передаче продука в сообщество
пользователей?
- Приемлемо ли все еще соотношение реальных и запланированных расходов?
Если проект не смог достигнуть указанных целей, может потребоваться отложить фазу
Внедрение и добавить еще одну итерацию на Построение.
Контрольная точка готового продукта (фаза Внедрение)
-
Удовлетворены ли пользователи?
Приемлемо ли соотношение запланированных и реальных затрат, и если нет, что
можно сделать, чтобы избежать излишних затрат в будущем?
После прохода этой вехи продукт находится в состоянии эксплуатации, обслуживания и
поддержки. Может начаться новый цикл разработки для создания новой его версии.
Деятельность на каждой из фаз
Ахтунг! Ахтунг! Ахтунг! Смотрим картинку и вкуриваем, что на
каждой итерации каждой фазы RUP делается не одно дело, а
несколько, возможно параллельно!
(Начало) (Проектирование)
(Построение)
Рис., который прочищает мозги