1. Начальная стадия (Inception)

В фазе начальной стадии:

• Формируются видение и границы проекта.

• Создается экономическое обоснование (business case).

• Определяются основные требования, ограничения и ключевая функциональность продукта.

• Создается базовая версия модели прецедентов.

• Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

• Документирование требований (включая детальное описание для большинства прецедентов).

• Спроектированную, реализованную и оттестированную исполняемую архитектуру.

• Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

• Сниженные основные риски.

Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (Lifecycle Architecture Milestone).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

7. Методологии Microsoft Solutions Framework + Microsoft Operations Framework и Microsoft Dynamics Sure Step. 

Очень важно, что для каждой роли четко определены: задачи, обязанности (ответственность) и требуемые профессиональные качества.

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

Преимущества модели команды MSF

• Высокая производительность, поскольку непроизводительные трудозатраты на поддержание формальных и субординационных связей сведены к минимуму.

• Сравнительно легкая масштабируемость. Каждый элемент в схеме команды может быть в свою очередь циклом.

• Сильная положительная мотивация труда и равно высокая заинтересованность всех участников в конечном успехе.

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

• Envisioning (предвидим идею, какая задача будет решаться)

• Planning (планирование)

• Developing (разработка, проектирование)

• Stabilizing (стабилизация)

• Deploying (размещение решение, обучение, сопровождение)

Цикл (виток спирали) разработки включает четыре фазы и завершается выпуском версии продукта. Каждая фаза представляет собой определенную последовательность действий и завершается вехой (milestone).

• Первая фаза — Анализ (Envisioning). На данном этапе формируется представление о продукте на данном витке спирали. Это гарантирует, что разрабатываемый продукт будет соответствовать как текущим, так и перспективным целям компании, а также поможет скорректировать направление развития компании. Данная стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт получает одобрение, то составляется группа разработки проекта, задача которой — выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же устанавливаются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях. Вехой данной фазы является утверждение представления.

• Вторая фаза — Планирование (Planning). С точки зрения Microsoft, планирование — это процесс согласования требований потребителей и группы проекта, касающихся конечного продукта и направления разработки продукта. Это метод прогнозирования рисков, выработки приоритетов и оценки графика работ и необходимых ресурсов. Фаза планирования завершается одобрением плана проекта, который включает функциональную спецификацию — комбинированные планы для каждого члена группы в соответствии с требованиями модели команды и график работ. Функциональная спецификация достаточно детализирована, чтобы позволить группе проекта определить потребности в ресурсах и ее обязательства. Вехой данной фазы является утверждение плана проекта.

• Третья фаза — Разработка (Developing). Стадия разработки завершается реализацией возможностей продукта и проверкой их на практике. Группа разработки определяет промежуточные этапы выпуска продукта, каждый из которых включает полный цикл тестирования, отладки и внесения исправлений. На этом этапе потребители и группа разработки оценивают функциональные возможности продукта и проверяют оптимальность планов развертывания и поддержки. Разработка в целом завершается, а все нереализованные возможности документируются для включения в следующие версии. Вехой данной фазы является завершение разработки, альфа-версия (передается тестерам, пользователям, начинается устранение ошибок).

• Четвертая фаза — Стабилизация (Stabilizing). На этой стадии акцент переносится с разработки решения на проверку его работоспособности в реальных условиях и на полномасштабное тестирование. Стадия стабилизации завершается выпуском продукта, который передается группам развертывания и сопровождения. Группе проекта поручают создание следующей версии либо подключают к работе над другими проектам. Вехой данной фазы является релиз продукта.

Статья про MSF:

http://www.studfiles.ru/preview/5611891/page:23/

https://msdn.microsoft.com/ru-ru/library/jj161047.aspx

Контрольными точками процесса являются вехи (milestones).

Microsoft Operations Framework (MOF) — это набор рекомендаций, на основе которого можно разрабатывать процедуры, элементы управления и роли, необходимые для эффективной работы ИТ-инфраструктуры. MOF основан на стандарте ITIL (IT Infrastructure Library) и учитывает специфику платформы Майкрософт.

Модель процессов MOF

MOF предоставляет рекомендации по планированию, развертыванию и обслуживанию ИТ-процессов для поддержки решений, критически важных для организации. MOF является общей моделью, поэтому многие рекомендации необходимо адаптировать для конкретной организации. При упоминании «ролей» в модели MOF необходимо понимать, что одному лицу можно назначить несколько ролей, особенно в небольших организациях. Но даже если весь ИТ-отдел представлен одним человеком, процедуры и рекомендации этой модели по-прежнему применимы.

Модель процессов MOF состоит из квадрантов, анализов управления операциями и анализов управления службами, таких как изменение, функционирование, поддержка, оптимизация.

Изменение. На этапе изменения происходит планирование и тестирование изменений. После анализа готовности выпуска изменение развертывается в производственной среде и переходит на этап функционирования. Анализ готовности выпуска не должен быть первой оценкой выпуска; он должен быть последним контрольным анализом перед фактическим развертыванием. Использование функций управления службами определяет схему выполнения процессов и задач и гарантирует успешное развертывание и развертывание управляемых выпусков.

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

Поддержка. Этап поддержки представляет собой процесс обслуживания системы с помощью соответствующих средств и процедур. Этот квадрант содержит функции управления службами, необходимые для обеспечения постоянной поддержки пользователей ИТ-решений. Как и для любого процесса, системы, приложения или службы проблемы могут возникнуть одновременно с началом работы. Персонал службы технической поддержки должен быстро определять проблемы, назначать лиц, ответственных за решение, и устранять их, чтобы соответствовать требованиям соглашений об условиях обслуживания. Анализ соглашений об условиях обслуживания определяет эффективность работы системы. Проблемы, обнаруженные при анализе соглашений об условиях обслуживания, могут указывать на области, нуждающиеся в улучшении.

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

Статьи про MOF:

http://unifiedpeople.ru/exchhelp.ru/html/5428d2e4-a2ec-430e-9520-0a88bff6d782.htm

https://technet.microsoft.com/ru-ru/library/cc543224.aspx

Структура MOF формально описывает действия, выполняемые в рамках данного цикла операций по улучшению, определяя ответственных за каждое действие и позволяя управлять процессом в целом. В конце каждого этапа существует контрольная точка. При наличии крупного ИТ-отдела она чаще всего представляет собой собрание людей или групп, ответственных, например, за управление выпуском, операции и безопасность. В небольшой организации контрольная точка может просто указывать на то, что работу можно продолжить.

Microsoft Dynamics Sure Step

Методология Microsoft Dynamics Sure Step представляет собой комплексную методологию внедрения, содержащую в себе рекомендации, стратегии управления проектами, инструменты и шаблоны, которую партнеры корпорации Майкрософт могут использовать для внедрения продуктов Microsoft Dynamics для своих клиентов. Методология Sure Step определяет стандартизованный поэтапный подход к проектам внедрения. Она призвана помочь партнерам Майкрософт внедрять решения Microsoft Dynamics в последовательной и повторяемой форме. Модель методологии Sure Step разделяет проект внедрения Microsoft Dynamics на шесть основных: диагностика, анализ, проектирование, разработка, развертывание, эксплуатация и два дополнительных этапа, которые можно реализовать после запуска решения Microsoft Dynamics в производственной среде клиента: оптимизация и обновление. Каждый этап методологии Sure Step включает набор определенных операций и задач. Результат выполненной работы в рамках операции, как правило, отражается в конечных результатах с рекомендациями и указаниями по дальнейшим шагам процесса внедрения.

Этап проекта	Цели этапа	Выполняемые работы (пакеты работ)
Диагностика	Анализ и описание бизнес-процессов. Выявление основных потребностей бизнеса. Оценка функциональной применимости базового программного продукта. Определение ожидаемых результатов, сроков, границ и бюджета проекта	Организация рабочей группы сотрудников Заказчика для проведения диагностики. Сбор предварительной информации. Обследование и описание структуры предприятия, бизнес-процессов, основных целей, потребностей и ожиданий Заказчика. Согласование результатов обследования, установка критериев оценки результатов проекта. Подготовка отчета о Диагностике. Предложения по разработке и внедрению решения
Анализ	Организация проекта. Детальное обследование и описание предприятия Заказчика. Изучение требований к внедряемому решению. Документирование функциональных требований, создание полного перечня требуемых модификаций и доработок функциональности	Открытие проекта, формирование Управляющего комитета и проектной группы. Подготовка плана проекта, Устава проекта, порядка отчетности, управления изменениями и рисками, сдачи-приемки проекта. Проведение тренинга для сотрудников клиента по базовой функциональности продукта. Уточнение и детализация требований к решению бизнес-процессов Заказчика. Выработка решений относительно изменения существующих бизнес-процессов, модификации функциональности продукта, построения интерфейсов с внешними системами. Подготовка Спецификации функциональных требований. Согласование и утверждение функциональных требований, уточнение параметров проекта
Дизайн	Описание создаваемого решения, детальное проектирование модификаций и доработок функциональности. Планирование изменений бизнес-процессов. Уточнение подходов к разработке и испытаниям проектируемого решения	Разработка Концептуального дизайна (Технического задания), описывающего в терминах предметной области концепцию реализации решения, изменения функциональности и бизнес-процессов, требования к отчетности. Согласование и утверждение Концептуального дизайна Заказчиком проекта. Разработка Детального дизайна (Программного дизайна), описывающего в терминах системы предполагаемые модификации функциональности, интерфейсы с внешними системами, порядок тестирования разработки, порядок приемки работ. Согласование и утверждение Детального дизайна. Планирование порядка, сроков и ресурсов для разработки и контроля качества. Уточнение параметров последующих стадий
Разработка и тестирование	Реализация и первичное тестирование модификаций и доработок функциональности. Установка и настройка системы. Планирование и проведение испытаний. Доработка решения по результатам испытаний	Настройка среды для разработки, среды для тестирования, рабочей среды для интеграции результатов в рабочую систему. Реализация модификаций и интерфейсов, первоначальное тестирование разработчиками. Передача результатов разработки Заказчику для тестирования, исправление обнаруженных ошибок, корректировка требований, повторная реализация и тестирование. Комплексное тестирование Заказчиком, исправление ошибок и корректировка требований. Установка результатов разработки в рабочую среду, настройка системы, перенос основных справочников и сальдо. Проведение финальных испытаний и подготовка к сдаче-приемке
Развертывание	Подготовка и настройка рабочей системы. Разработка пользовательской документации. Тренинг конечных пользователей. Планирование и запуск в рабочую эксплуатацию. Сдача-приемка проекта	Проведение официальной сдачи проекта Заказчику. Оценка достижения целей проекта и критериев успеха. Планирование запуска в промышленную эксплуатацию. Подготовка системы к запуску, контроль готовности, заведение актуальных данных. Организация и проведение тренинга для конечных пользователей. Запуск ежедневной обработки в новой системе операций. Осуществление первоначальной поддержки специалистами партнера промышленной эксплуатации системы. Официальное завершение проекта, оценка проекта Заказчиком
Начальное сопровождение	Сопровождение функционирования системы в режиме рабочей эксплуатации. Устранение выявленных несоответствий. Переход к режиму работы Заказчика в рамках контракта на регулярное сопровождение	Осуществление ежедневной поддержки работы Заказчика с системой (по телефону, электронной почте, с выездом специалистов на место). Периодические обновления системы, связанные с выходом новых версий, изменениями законодательства, развитием технологий. Проведение периодической оценки соответствия решения требованиям Заказчика, наличия потребностей в изменении и развитии решения. Планирование и организация новых проектов