Технологический опыт

Главной задачей на данной стадии является достижение согласованности по целям проекта между всеми заинтересованными сторонами. Данная стадия, в основном, важна для новых проектов, когда главные риски должны быть рассмотрены до того, как начнется работа над проектом. Для проектов, сфокусированных на улучшении существующей системы, данная стадия является более короткой и фокусируется на выявлении полезности проекта и возможности его осуществления.
Основные цели:

1. Установить области применения и границы проекта, включая рабочее представление, критерий приемки;
2. Определение критических вариантов использования, основных сценариев работы;
3. Представление и демонстрация, по крайней мере, одного варианта архитектуры, основанного на сценариях;
4. Общая оценка стоимости и расписания для всего проекта (и более детальная оценка для предстоящей фазы уточнения);
5. Оценка возможных рисков;
6. Подготовка поддерживающей среды для проекта.

Основные операции:

1. Сформулировать контекст для проекта (включая наиболее важные требования и ограничения, необходимые для выведения критерия приемки);
2. Спланировать и подготовить бизнес-факты;
3. Синтезировать вариант архитектуры, учитывающий компромиссы в дизайне таким образом, чтобы стоимость, расписание и ресурсы могли быть оценены. Главная цель — доказать осуществимость проекта.  Доказательством может послужить построенная модель, воспроизводящая необходимые функции, или первоначальный прототип, по которому можно рассчитать области высокого риска. Усилия на создание прототипа ограничиваются целью доказать возможность решения задач проекта, непосредственное решение  задач осуществляется на стадиях уточнения и конструирования;
4. Подготовить среду для проекта (оценив проект и саму организацию, выбрав инструменты, решая какую часть процесса улучшить).

Основной задачей фазы является установление рабочей (baseline) архитектуры системы, чтобы предоставить стабильную основу для большей части работ по дизайну и реализации на фазе конструирования. Архитектура развивается из анализа наиболее существенных требований и из оценок рисков. Прочность архитектуры оценивается через построение одного или нескольких архитектурных прототипов.
Основные цели:

1. Убедиться, что архитектура, требования и планы достаточно устойчивы и что риски достаточно смягчены, чтобы можно было предсказать стоимость и график работ, необходимые для завершения разработки. Для большинства проектов прохождение этой стадии связано с переходом от простых операций с низким риском к высокозатратным операциям с высоким риском, что неминуемо влечет за собой организационные трудности;
2. Разрешить все риски проекта, связанные с архитектурой;
3. Установить рабочую архитектуру, выведенную из рассмотрения наиболее существенных для архитектуры сценариев (которые обычно выявляют наивысшие технические риски проекта);
4. Создать эволюционный  прототип компонентов, возможно даже один или несколько исследовательских черновых прототипов, чтобы уменьшить такие специфические риски, как:
5.  
   1. уступки в дизайне/требованиях;
   2. переиспользование кода;
   3. осуществимость проекта или демонстрация инвесторам, заказчикам или конечным потребителям.
6. Продемонстрировать, что рабочая архитектура будет поддерживать требования к системе, оставаясь в рамках разумной стоимости и времени.

Основные операции:

1. Определение, обоснование и утверждение (base lining) архитектуры;
2. Уточнение представление (vision), основанное на новых данных, полученных на данной фазе, установление цельности понимания наиболее критичных вариантов использования, которые вызывают принятие решений, связанных с планированием и архитектурой;
3. Создание и установление дательных планов итераций для фазы конструирования;
4. Уточнение процесса разработки и установление среды разработки, включая процесс, инструменты и поддержку автоматизации, необходимые проектной команде;
5. Уточнение архитектуры и выбранных компонентов. Потенциальные компоненты оцениваются, и принимается решение по их написанию/покупке/переиспользованию, чтобы достоверно определить стоимость и график работ на фазе конструирования. Выбранные компоненты интегрируются и оцениваются в соответствии с основными сценариями.  Новые сведения, полученные во время этих операций, могут привести к перепроектированию  архитектуры, рассмотрению альтернативных моделей и пересмотру требований.

Основная задача — выяснение оставшихся требований и завершение разработки, основанной на рабочей архитектуре. Эта фаза является  промышленной, где упор делается на управление ресурсами и проверку действий, чтобы оптимизировать стоимость, расписание и качество.
Основные цели:

1. Минимизация стоимости разработки посредством оптимизации использования ресурсов и избежания недоработок;
2. Достижение соответствующего качества;
3. Получение версий, пригодных к использованию (Alfa, beta, etc.);
4. Завершение анализа, дизайна, разработки и тестирования всех требуемых характеристик;
5. Итеративно с нарастанием возможностей разработать законченный продукт, готовый к использованию пользователями. Это включает описание оставшихся вариантов использования и других требований, конкретизацию дизайна, завершение реализации и тестирования продукта;
6. Решить, готовы ли к размещению: продукт, места его размещения и пользователи;
7. Достичь некоторой степени параллельности в работе команд разработчиков. Даже в маленьких проектах есть типовые компоненты, которые могут быть разработаны независимо друг от друга, допускаю, таким образом,  естественную параллельность работы между командами. Такая параллельность работы может значительно ускорить прогресс разработки проекта, однако она зачастую приводит к усложнению управления ресурсами и затруднению согласованности действий. Создание прочной, стабильной архитектуры обязательно, если предполагается использование параллельной работы.

Основные операции:

1. Управление ресурсами, проверка и оптимизация процессов;
2. Завершить разработку компонентов и их тестирование в соответствии с определенным критерием оценки;
3. Оценить готовый продукт в соответствии с критерием приемки для данного представления.

Данная фаза фокусируется на проверке, что продукт доступен для конечного пользователя. Фаза может состоять из нескольких итераций и включает тестирование продукта в процессе подготовки к выпуску, а также внесения небольших изменений, основанных на отзывах пользователей.
На этой стадии отзывы должны, в основном, концентрироваться  на вопросах настройки, конфигурации, установки и удобства использования, все крупные структурные вопросы должны быть решены ранее.
В конце данной фазы проект должен считаться закрытым, хотя в некоторых случаях данная фаза может совпадать с началом следующего цикла жизни того же проекта, создающего новую версию продукта.
Сложность данной фазы может варьироваться от предельно простой и прямолинейной до крайне сложной, в зависимости от вида продукта. Новый релиз существующего приложения домашнего использования может быть очень простым, тогда как  замена национальной системы воздушной диспетчеризации окажется чрезвычайно сложным процессом.
Началом фазы считается момент, когда рабочие продукты достаточно развились, чтобы их можно было предоставить конечному пользователю. Обычно это подразумевает, что некоторое полезное подмножество системы было завершено в соответствии с уровнем качества и пользовательской документацией, так чтобы перенос системы к пользователю предоставил положительные результаты для обеих сторон.
Основные цели:

1. Осуществление бета-тестирования, чтобы убедиться в соответствии системы ожиданиям пользователя;
2. Бета-тестирование и параллельная работа, чтобы убедиться в совместимости новой системы с заменяемой;
3. Преобразование рабочих баз данных;
4. Обучение пользователей и сопровождающего персонала;
5. Адаптация продукта под схему маркетинга, распространения и продажи;
6. Деятельность по развертыванию продукта — коммерческое производство, упаковка, обучение торгового персонала;
7. Работы по регулировке (исправление ошибок, улучшение производительности и удобства);
8. Оценка распространяемых рабочих продуктов в сравнении с полным представлением о системе и критерием приемки продукта;
9. Обеспечение возможности само-поддержки клиента, без обращения в службу технической поддержки;
10. Достижение согласованности заинтересованных сторон в том, что распространяемый продукт завершен;
11. Достижение согласованности заинтересованных сторон в том, что распространяемый продукт не противоречит критерию оценки представление (vision).

Основные действия:

1. Выполнение планов по размещению продукта;
2. Завершение материалов для поддержки конечного пользователя;
3. Тестирование поставляемого продукта;
4. Создание релиза продукта;
5. Получение отзывов пользователя;
6. Корректировка продукта на основе отзывов;
7. Поставка продукта пользователям.

Цели бизнес-моделирования:

1. Понять структуру и динамику организации, в которой система будет установлена (целевая организация);
2. Понять существующие проблемы в целевой организации и выявить области возможного улучшения;
3. Убедиться, что заказчики, конечные пользователи и разработчики имеют одинаковое понимание целевой организации;
4. Вывести требования к системе, необходимые для поддержки целевой организации.

Чтобы достичь этих целей, процесс бизнес-моделирования описывает, как разработать представление (vision) о целевой организации, и, основываясь на этом представлении, определить процессы, роли и ответственности в этой организации в виде вариантов бизнес-использования и объектной бизнес-модели. Кроме этих моделей разрабатываются следующие артефакты: дополнительные бизнес-спецификации, глоссарий.

Цели:

1. Установить и поддерживать соглашение с заказчиками и другими заинтересованными лицами относительно того, что будет выполнять система;
2. Дать разработчикам лучшее понимание системных требований;
3. Определить границы применения системы;
4. Предоставить основу для планирования технического содержания итераций;
5. Предоставить базис для оценки стоимости и времени разработки системы;
6. Определить пользовательский интерфейс системы, фокусируясь на нуждах и задачах пользователей.

Чтобы достичь этих целей важно, прежде всего, понять определение и рамки проблемы, которую будет решать система. Для этого используются:

1. Бизнес-правила,
2. Бизнес-варианты использования,
3. Объектная бизнес-модель,

разработанные в процессе бизнес-моделирования. Чтобы полнее описать систему, разрабатываются:

1. Представление о системе;
2. Модель вариантов использования;
3. Варианты использования;
4. Дополнительные спецификации (дополнение к use-case model, вместе они охватывают все требования, как функциональные, так и нефункциональные — Software Requirements Specification).

Кроме того, разрабатываются артефакты:

1. Глоссарий;
2. Use-case storyboard (связь интерфейса с вариантами использования);
3. Прототип пользовательского интерфейса.

Цели:

1. Преобразовать требования к системе в дизайн системы;
2. Вывести устойчивую архитектуру системы;
3. Адаптировать дизайн к среде реализации, делая упор на производительности.

Цели:

1. Определить организацию кода в терминах реализации подсистем, организованных в уровнях;
2. Реализовать классы и объекты в терминах компонентов (исходные файлы, объектные файлы, exe и др.);
3. Протестировать разработанные компоненты и модули;
4. Объединить результаты работы разработчиков и команд в исполняемую систему.

Процесс: испытание

Цели:

1. Проверить взаимодействие между объектами;
2. Проверить корректность интеграции всех компонентов;
3. Проверить, что все требования были корректно реализованы;
4. Выявить и исправить дефекты перед поставкой продукта заказчику.

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

Данный процесс включает:

1. Выявление элементов конфигурации;
2. Ограничение изменений в этих элементах;
3. Аудит изменений, сделанных в этих элементах;
4. Определение и управление конфигурацией этих элементов.

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

1. Одновременное исправление;
2. Ограниченное уведомление (когда ошибка в артефакте была исправлена, но не всем разработчикам, использующим его, было сообщено об исправлении);
3. Множественные версии.

Project management — это искусство балансирования конкурирующих целей, управления рисками и преодоления ограничений, чтобы успешно выполнить поставку продукта, и отвечающего нуждам заказчиков и пользователей.

Цели:

1. Предоставить каркас (framework) для управления проектами;
2. Предоставить практические руководства для планирования, набора кадров, исполнения и наблюдения проектов;
3. Предоставить каркас для управления рисками.

Данный процесс фокусируется на важных аспектах процесса итеративной разработки:

1. Управление рисками;
2. Планирование итеративного проекта как на протяжении всей его жизни, так и для конкретной итерации;
3. Наблюдение за ходом выполнения итеративного проекта, выполнение измерений.

Данный процесс фокусирует внимание на действиях, необходимых, чтобы сконфигурировать процесс для проекта. Он описывает действия, необходимые для разработки руководств по поддержке проекта. Цель данного процесса — предоставить среду для разработки — инструменты и процессы.Основные концепции:

• Конфигурация процесса (как сконфигурировать RUP);
• Реализация процессов в организации (пошаговые процедуры по реализации процесса в организации; однако, эти процедуры не используют термины «работник», «действие» и «артефакт»);
• Реализация процессов в проекте (объясняет, как реализовать процесс, используя инструменты в программном проекте).