Microsoft solutions framework представляет следующие фазы проекта укажите лишнее в перечислении

Обновлено: 06.07.2024

Шаблон:Нет сносок Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

MSF представляет собой согласованный набор концепций, моделей и правил.

Содержание

Введение [ ]

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

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

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

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.

MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды:

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):

Команда соратников
Сфокусированность на нуждах заказчика
Нацеленность на конечный результат
Установка на отсутствие дефектов
Стремление к самосовершенствованию
Заинтересованные команды работают эффективно

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

В проектную группу входят такие ролевые кластеры:

управление программой
управление продуктом
разработка
тестирование
управление релизом
удовлетворение потребителя

Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

Роль команды разработчиков не может быть объединена ни с какой другой ролью.
Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

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

MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:

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

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

Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.

Модель процессов MSF [ ]

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь Управление рисками [ ]

Как уже говорилось выше, в MSF нет роли «менеджер проекта». Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером «Управление программой».

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ ( Управление подготовкой [ ]

Следует отметить, что Microsoft. Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Версии [ ]

Описание слайда:

Microsoft Solutions Framework
Модель процессов MSF

Описание слайда:

Microsoft Solutions Framework (MSF)
Методология разработки программного обеспечения от Microsoft.
MSF описывает управление людьми и рабочими процессами в процессе разработки решения.
MSF состоит из двух моделей и трех дисциплин.
модели:
модель проектной группы
модель процессов
дисциплины:
дисциплина управление проектами
дисциплина управление рисками
дисциплина управление подготовкой

Описание слайда:

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

Описание слайда:

Модель проектной группы
Бизнес-приоритеты
Маркетинг
Представление интересов заказчика
Планирование продукта
Управление проектом
Выработка архитектуры решения
Контроль производственного процесса
Административные службы
Технологическое консультирование Проектирование и осуществление реализации
Разработка приложений
Разработка инфраструктуры
Планирование тестов
Разработка тестов
Отчетность по тестам
Инфраструктура
Сопровождение
Бизнес-процессы
Управление выпуском готового продукта
Обучение
Эргономика
Графический дизайн
Интернационализация
Обеспечение технической поддержки
Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)
Разработка
Тестирование
Управление
выпуском
Удовлетворение
потребителя
Управление
продуктом
Управление
программой

Описание слайда:

Модель процессов MSF
Модель процессов (process model) представляет общую методологию разработки и внедрения IT‑решений.
Особенности модели:
может быть применена при разработке широкого круга IT‑проектов
модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral)
процесс ориентирован на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата
модель процессов MSF учитывает постоянные изменения проектных требований

Описание слайда:

Базовые принципы MSF
Единое видение проекта
для этой цели специальная фаза (“Выработка концепции”), которая заканчивается вехой
Проявляйте гибкость – будьте готовы к переменам
принцип непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности
Концентрируйтесь на бизнес-приоритетах
модель процессов включает в свой жизненный цикл не только разработку продукта, но и его внедрение
Поощряйте свободное общение
модель процессов предлагает проведение анализа хода работы над проектом в определенных точках

Описание слайда:

Ключевые термины модели процессов MSF
“заказчик" (customer) и “потребитель” (пользователь, user) продукта
заинтересованные стороны (stakeholders)
“решение” (solution)
базовая версия (baseline)
рамки (scope)
рамки решения
рамки проекта

Описание слайда:

Что есть решение?
“Решение” (solution) - скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение и сопровождение), необходимых для удовлетворения некоторой бизнес‑потребности конкретного заказчика

Решение может включать в себя один или несколько программных продуктов, тем не менее, нужно четко разграничивать продукты и решения

Описание слайда:

Продукты и решения
Продукты
Разрабатываются для нужд массового рынка.
Поставляются в качестве дистрибутивных пакетов или загружаемых файлов.
Решения MSF
Разрабатываются или привязываются к нуждам определенного заказчика.
Поставляются путем внедрения проекта.

Описание слайда:

Элементы успешного решения

Описание слайда:

Рамки проекта и рамки решения
Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению).

Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения.

Описание слайда:

Ключевые концепции модели процессов MSF
Создание базовых версий
версия (baseline) – это известное и зафиксированное состояние чего-либо, используемое для последующего сравнения
Управление компромиссами

Описание слайда:

Треугольник компромиссов
После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.

Описание слайда:

Матрица компромиссов проекта

Описание слайда:

Характеристики модели процессов MSF
Подход, основанный на фазах и вехах.
Итеративный подход.
Интегрированный подход к созданию и внедрению решений.

Описание слайда:

Подход, основанный на вехах
вехи - опорные точки для планирования и мониторинга хода проекта:
главные (major) - точки перехода от одной фазы к другой
промежуточные (interim) - показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки
Вехи - точки синхронизации
Вехи - ориентиры производственной ответственности

Описание слайда:

Ведущие роли различных фаз

Описание слайда:

Характеристики итеративного подхода
Выпуск версий
Создание “живой” документации
Ранние базовые версии, отложенные итоговые версии
Ежедневные билды
Управление конфигурациями проекта

Описание слайда:

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

Описание слайда:

Интегрированный подход к созданию и внедрению решений
Фазы и вехи модели процессов MSF

Описание слайда:

Фаза выработки концепции (envisioning )
создание и сплочение проектной группы на основе выработки единого видения.
основными задачами фазы являются:
создание ядра проектной группы
подготовка документа общего описания и рамок проекта (vision/scope document).
проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта
производится выявление и анализ бизнес‑требований.

Описание слайда:

Вехи фазы выработки концепции и результаты
главная веха:
Веха “Концепция утверждена”
рекомендуемые промежуточные вехи:
Ядро проектной группы сформировано
Черновой вариант концепции проекта составлен
Результаты:
Общее описание и рамки проекта (vision/scope document).
Документ оценки рисков (risk assessment document).

Описание слайда:

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

Описание слайда:

Вехи фазы планирования и результаты
главная веха:
Веха “Планы проекта утверждены”
рекомендуемые промежуточные вехи:
Верификация технологий
Базовая версия функциональной спецификации создана
Базовая версия сводного плана проекта создана
Базовая версия сводного календарного графика проекта создана
Среды разработки и тестирования развернуты
Результаты:
Функциональная спецификация.
План управления рисками.
Сводный план и сводный календарный график проекта

Описание слайда:

Фаза разработки
(developing)
Задачи:
создание компонент решения (включая как документацию, так и программный код).
разработка инфраструктуры.

Описание слайда:

Вехи фазы разработки и результаты
главная веха:
Веха “Разработка завершена”
рекомендуемые промежуточные вехи:
Концепция подтверждена
Билд n завершен, билд n+1 завершен.
Результаты:
Исходный и исполнимый код приложений.
Скрипты установки и конфигурирования.
Окончательная функциональная спецификация.
Материалы поддержки решения.
Спецификации и сценарии тестов.

Описание слайда:

Фаза стабилизации
(stabilizing)
Производятся работы:
тестирование разработанного решения
устранение ошибок
подготовка решения к выпуску

Описание слайда:

Вехи фазы стабилизации
главная веха:
Веха “Готовность решения утверждена”
рекомендуемые промежуточные вехи:
Точка конвергенции
Точка достижения нуля
Версии-кандидаты
Контрольное тестирование завершено
Тестирование приемлемости для потребителей завершено
Пилотное внедрение завершено

Описание слайда:

Результаты фазы стабилизации

Окончательный продукт (golden release).
Документация выпуска (release notes).
Материалы поддержки решения.
Результаты и инструментарий тестирования.
Исходный и исполнимый код приложений.
Проектная документация.
Анализ пройденной фазы (milestone review).

Описание слайда:

Точка достижения нуля

Описание слайда:

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

Описание слайда:

Вехи фазы внедрения
главная веха:
Веха “Внедрение завершено”
рекомендуемые промежуточные вехи:
Ключевые компоненты развернуты
Внедрение на местах завершено
Внедренное решение стабилизировано

Описание слайда:

Результаты фазы внедрения
Информационные системы эксплуатации и поддержки.
Процедуры и процессы.
Базы знаний, отчеты, журналы протоколов (logbooks).
Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта.
Отчет о завершении проекта (project close-out report).
Окончательные версии всех проектных документов.
Показатели удовлетворенности заказчика и потребителей.
Описание последующих шагов.

Описание слайда:

Рекомендуемые методики модели процессов MSF
Стимулируйте изобретательность расширяя функциональность и ограничивая ресурсы
Фиксируйте календарный график
Календарное планирование на неопределенное будущее
Используйте параллельно работающие компактные команды
Разбивайте большие проекты на осуществимые части
Извлекайте уроки из пройденных вех
Используйте прототипирование
Используйте частые билды и быстрые тесты
Частые итерации разработки и внедрения
Избегайте расползания рамок проекта
Оценка снизу вверх
Интегрирование представленных проектной группой оценок

Описание слайда:

MSF 4.0
Версия MSF 4.0 была представлена в 2005 году.
Произошло разделение методологии на два направления:
MSF for Agile Software Development - ориентируется на небольшие команды (5-6 человек), предполагает, что информация о разрабатываемом продукте не просто выясняется в процессе разработки, а может и будет изменяться по ходу.
MSF for CMMI Process Improvement - строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д.

Описание слайда:

Основные положения MSF for Agile Software Development
Первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.
Методология MSF содержит ряд элементов, в частности:
рекомендованные процессы создания IT-проектов;
структуру итераций;
роли членов команды;
шаблоны документов (Excel, Word);
шаблоны Microsoft Project;
отчеты;
портал проекта (шаблон сайта SharePoint).
MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки

Описание слайда:

Модель проектной группы MSF for Agile Software Development
Основные принципы построения команды
Концентрация на нуждах заказчика
Нацеленность на конечный результат
Установка на отсутствие дефектов
Проектная группа - команда равных
Стремление к самосовершенствованию

Описание слайда:

MSF 5.0 для гибкой разработки ПО
Scrum. Scrum — платформа для управления разработкой сложных продуктов и систем, характеризующаяся гибкими принципами и характеристиками.
Рекомендации по проектированию. Эти рекомендации помогают увеличить скорость, с которой команда предоставляет желаемые результаты клиентам.
Артефакты. Каждый артефакт служит для реализации определенной функции и предоставляет возможности для уточнения процессов с течением временем.
Роли. В процессе Scrum определены три роли.
Scrum Master – мастер, координатор,
Product Owner – владелец продукта
Team – команда
Собрания. Проводится ряд собраний. Каждое собрание имеет конкретную цель, проводится с определенной периодичностью и ограничено по времени.

Описание слайда:

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

В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории: бизнес-требования ( business requirements ), потребительские требования ( user requirements ), эксплуатационные требования ( operational requirements ) и системные требования, относящиеся к решению в целом ( system requirements ). В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием ( traceability ) между имеющимися требованиями и проектируемой функциональностью. Это соответствие не обязательно будет взаимооднозначным. Оно служит одним из способов контроля корректности дизайна и его пригодности для достижения поставленных перед решением целей.

Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей ( user profiles , иногда называемых "персонажами" - " personas "), которые описывают различные типы пользователей (включая персонал сопровождения) и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования ( usage scenarios ), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя (например, регистрация посетителей в отеле или администрирование паролей пользователей в компьютерной системе). В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции. Этот процесс анализа действий пользователей называется стори-боардинг (" story boarding ").

Существует три уровня процесса проектирования: концептуальный дизайн ( conceptual design ), логический дизайн ( logical design ) и физический дизайн ( physical design ). Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.

Результаты процесса проектирования документируются в функциональных спецификациях (functional specifications). Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.

Функциональная спецификация служит многим целям:

Инструкции команде разработчиков о том, что они должны будут создать.
Основа для оценивания объема работы.
Четкое соглашение с заказчиком о том, что должно быть сделано.
Синхронизация работы всей проектной команды.

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

Затем проектная группа коллективно анализирует планы и выявляет взаимозависимости между ними. Все планы синхронизируются и представляются вместе в виде сводного плана проекта. В зависимости от проекта, число планов, образующих сводный план, может меняться.

Члены проектной группы, представляющие каждый из ролевых кластеров , оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).

Кульминацией фазы планирования является веха "Планы проекта утверждены" ( project plans approved). Она знаменует собой достижение детального соглашения между заказчиком и проектной группой о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.

Фаза разработки

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

Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.

Фаза стабилизации

Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.

Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции ( bug convergence ) и точка достижения нуля ошибок (zero bug bounce ). Они описываются ниже.

MSF не использует для описания состояния проекта термины "альфа" и "бета". Хотя эти понятия применяются довольно часто, их интерпретация далеко не однозначна. При желании проектная группа может их использовать, но при этом они должны быть четко определены и понятны как членам проектной группы, так и заказчику и другим заинтересованным сторонам.

Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.

Фаза стабилизации завершается вехой "Готовность решения утверждена" (Release Readiness Approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.

Фаза внедрения

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

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

Модель команды Microsoft Solutions Framework

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

Шесть ролевых кластеров модели проектной группы – это "Управление продуктом" ( product management ), "Управление программой" ( program management ), "Разработка" ( development ), "Тестирование" (test), "Удовлетворение потребителя" ( user experience ) и "Управление выпуском" ( release management ). Они ответственны за различные области компетенции ( functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер ) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

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

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

Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.

Структура процессов MSF

Говоря о моделях процессов жизненного цикла проектов разработки ПО, в первую очередь нужно упомянуть о двух основных схемах: водопадной и спиральной (рис. 1), которые отражают два разных подхода к организации этих работ.

Рис. 1. Водопадная и спиральная модели разработки.

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

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

Однако проблема заключается в том, что чаще всего все требования на задание действительно практически невозможно определить заранее, к тому же даже сформулированные требования подвергаются коррекции. Но тогда требуется повысить уровень управляемости проектом, без чего создание сложного ПО просто невозможно. Компромисс между этими противоречивыми требованиями и предоставляет модель процессов MSF, в которой сочетаются водопадная и спиральная модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (рис. 2).

Рис. 2. Этапы и контрольные точки модели MSF.

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

Создание общей картины приложения

На этом этапе решаются следующие основные задачи:

определение состава команды;
определение структуры проекта;
определение бизнес-целей;
оценка существующей ситуации;
создание документа общей картины и области действия проекта;
определение требований и профилей пользователей;
разработка концепции решения;
оценка риска;
закрытие этапа.

На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".

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

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

Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".

Планирование

На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовится функциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроков получения результатов.

На этом этапе проводится анализ требований, которые делятся на бизнес-требования, пользовательские, функциональные и системные требования. После сбора и анализа требований команды разрабатывается проект решения, определяются профили пользователей, после чего формируются сценарии применения решения, выполняемые пользователями одного типа, а затем определяются варианты использования системы.

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

В ходе данного этапа решаются такие задачи:

разработка проекта и архитектуры решения;
создание функциональной спецификации;
разработка планов проекта;
разработка календарного графика;
создание среды разработки, тестирования и пилотной эксплуатации;
закрытие этапа.

Контрольные точки этапа планирования связаны с достижением следующих результатов:

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

Разработка

На этапе разработки создается решение, в том числе пишется и документируется код. В начале этого этапа команда проверяет выполнение всех задач, характерных для предыдущих этапов, а затем приступает к решению следующих задач:

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

Результаты этапа предполагают следующие элементы:

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

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

Стабилизация

Данный этап - подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), а также проверяется сценарий развертывания продукта и проводится пилотная эксплуатация.

Тестирование подразумевает следующие основные виды работ:

тестирование компонентов;
тестирование баз данных;
тестирование инфраструктуры;
тестирование защиты;
тестирование интеграции;
анализ удобства работы с продуктом;
нагрузочное тестирование (включая анализ ресурсоемкости и производительности);
регрессивное тестирование;
ведение отчетности по тестированию.

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

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

Развертывание

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

развернуты основные компоненты;
развернуто решение в целом;
развернутое решение стабилизировано;
решение развернуто и передано в эксплуатацию заказчику.

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

Комментарии по поводу этапов работ

Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению различных этапов разработки и зачастую используется собственная терминология, что усложняет проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской терминологии.

Общепринятый на сегодня список ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:

Defining (определение требований);
Designing (анализ и проектирование);
Developing (разработка);
Testing (тестирование);
Deploying (развертывание).

Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы и их наименование. Хотелось бы обратить внимание читателей, что речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы.

Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.

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

Формирование проектных команд

Один из ключевых элементов реализации проекта - задача управления коллективом его участников. Поэтому наряду с моделью процессов в MSF детально проработана модель команд (MSF Team Model), которая исходит из важности четкого понимания ролей, обязанностей и задач отдельных ее членов, а также их повышенной ответственности за реализацию проекта в целом. Она может применяться в соответствии с потребностями и контекстом проекта, размером коллектива и опытом участников команды. Ниже коротко охарактеризованы роли, используемые в модели команд MSF.

Менеджер продукта (product manager) отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и ведет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействия с клиентом в ходе реализации проекта, в том числе организует встречи с клиентом, демонстрации продукта и другие маркетинговые акции.

Менеджер программы (program manager) управляет собственно разработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.

Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.

Тестировщик (tester) выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он также оценивает соответствие набора реализованных в продукте функций общей концепции и области действия проекта.

Менеджер по выпуску (release manager) отвечает за развертывание и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.

Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения соответствия их потребностям.

Конечно, в небольшом проекте отдельным членам команды приходится совмещать несколько ролей. Тут возможны разные варианты в зависимости от квалификации и опыта сотрудников, а также специфики проекта, но все же нужно придерживаться определенных правил относительно "совместимости" ролей (см. таблицу). Например, обратите внимание, что разработчику не рекомендуется выполнять какие-то еще роли.

Возможное совмещение ролей в проектной команде

Менеджер продукта	Менеджер программы	Разработчик	Тестиров-щик	Менеджер по выпуску	Специа-лист по удобству исполь-зования
Менеджер продукта	-	-	+	-+	-+
Менеджер программы	-	-	-+	+	-+
Разработчик	-	-	-	-	-
Тестиров-щик	+	-+	-	+	+
Менеджер по выпуску	-+	+	-	+	-+
Специалист по удобству исполь-зования	+	-+	-	+	-+
Примечание: " - " - совмещение не рекомендуется, " -+ " - нежелательно, " + " - возможно.

Кроме собственно исполнителей проекта, в команду могут входить и другие лица:

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

Управление компромиссами

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

определить ограничения, накладываемые на проект;
организовать управление компромиссами;
организовать управление изменениями;
обеспечить мониторинг проекта.

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

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

Рис. 3. Треугольник компромиссов.

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

Учитывая, что зафиксировано ____________, мы определим _____________
и в случае необходимости скорректируем ____________________.

Вставляя переменные из определенной заранее матрицы компромиссов, можно получить формулировку, соответствующую целевой задаче проекта, например:

Учитывая, что зафиксированы РЕСУРСЫ, мы определим ГРАФИК
и в случае необходимости скорректируем ФУНКЦИОНАЛЬНОСТЬ.

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

Читайте также: