Microsoft solutions framework что это

Обновлено: 04.07.2024

Продолжаю публиковать конспекты семинаров по методологиям управления проектами.

Этот посвящен MSF. Автором семинара является мой коллега Антон Сальник. Конспект опубликован с его согласия.

Модель проектной группы

Масштабирование модели проектной группы

Фазы и вехи модели процессов MSF

Фаза выработки концепци (Envisioning)

Фаза планирования (Planning)

Фаза разработки (Development)

Фаза стабилизации (Stabilizing)

О чем еще рассказывается в модели процессов

Дисциплина управления проектами

Дисциплина управления рисками

Дисциплина управления подготовкой

Новые версии MSF

Масштабирование проектных групп

Таблица совместимости ролей

Microsoft Solutions Framework , далее MSF , представляет собой подход компании Microsoft к управлению IT -проектами. В данном обзоре будет рассмотрена версия 3.0 данной методологии, опубликованная в июне 2002 года.

Технология MSF состоит из двух моделей:

Модель проектной группы;

И трех дисциплин:

Дисциплина управления проектами;

Дисциплина управления рисками;

Дисциплина управления подготовкой.

Все они довольно подробно описаны в 5 whitepapers [1]. Рассмотрим все эти части более детально.

Модель проектной группы

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

К основным принципам и ключевым концепциям, определяющих проектную группу MSF относятся:

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

Единое видение проекта. А именно единое четкое понимание целей и задач проекта.

Распределение ответственности при фиксации отчетности.

Нацеленность на необходимый заказчику конечный результат;

Наличие у сотрудников необходимых полномочий;

Открытое общение;

Установка на отсутствие дефектов;

Стремление к совершенствованию;

Гибкость и готовность к переменам;

Заинтересованность и энтузиазм.

Ролевые кластеры

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

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

Управление продуктом

Цель: Удовлетворенные заказчики.

Область компетенций:

Представление интересов заказчика;

Управление программой

Цель: Достижение результата в рамках проектных ограничений.

Область компетенций:

Выработка архитектуры решения;

Контроль производственного процесса;

Цель: Создание продукта в соответствии со спецификацией.

Область компетенций:

Проектирование и осуществление реализации;

Тестирование

Цель: Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены.

Область компетенций:

Отчетность по тестам.

Удовлетворение потребителя

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

Область компетенций:

Обеспечение технической поддержки;

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

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

Цель: Беспроблемное внедрение и сопровождение продукта.

Область компетенций:

Управление выпуском готового продукта.

Принципы MSF формируют такой подход к управлению проектами , при котором:

Масштабирование модели проектной группы

В одном ролевом кластере может быть много людей;

Один человек может взять на себя несколько ролей;

создаем группы направлений;

создаем функциональные группы;

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

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

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

Тремя особенностями модели процессов MSF являются:

Подход, основанный на фазах и вехах.

Вехи и фазы

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

MSF вводит два типа вех: главные (major) и промежуточные (interim). Они имеют следующие особенности:

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

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

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

Итеративный подход

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

Фазы и вехи модели процессов MSF

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

Для каждой фазы модели процессов MSF определяет:

Что (какие артефакты) является результатом этой фазы;

Над чем работает каждый из ролевых кластеров на этой фазе;

Фаза выработки концепци (Envisioning)

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

Веха: Концепция утверждена.

Общее описание и рамки проекта (vision/scope document).

Документ оценки рисков (risk assessment document).

Описание структуры проекта (project structure document).

Рекомендуемые промежуточные вехи:

Ядро проектной группы сформировано

Черновой вариант концепции проекта составлен

Фаза планирования (Planning)

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

Веха: Планы проекта утверждены.

План управления рисками;

Сводный план и сводный календарный график проекта.

Рекомендуемые промежуточные вехи:

Базовая версия функциональной спецификации создана;

Базовая версия сводного плана проекта создана;

Базовая версия сводного календарного графика проекта создана;

Среды разработки и тестирования развернуты.

Фаза разработки (Development)

Веха: Разработка завершена.

Исходный и исполнимый код приложений;

Скрипты установки и конфигурирования;

Окончательная функциональная спецификация;

Материалы поддержки решения;

Спецификации и сценарии тестов.

Рекомендуемые промежуточные вехи:

Билд 1 завершен;

Билд 2 завершен;

Билд n завершен.

Фаза стабилизации (Stabilizing)

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

Веха: Готовность решения утверждена

Окончательный продукт (golden release);

Документация выпуска (release notes);

Материалы поддержки решения;

Результаты и инструментарий тестирования;

Исходный и исполнимый код приложений;

Анализ пройденной фазы (milestone review).

Рекомендуемые промежуточные вехи:

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

Контрольное тестирование завершено

Тестирование приемлемости для потребителей завершено

Пилотное внедрение завершено

Фаза внедрения(Deploying)

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

Веха: Внедрение завершено.

Информационные системы эксплуатации и поддержки;

Процедуры и процессы;

Базы знаний, отчеты, журналы протоколов (logbooks);

Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта;

Отчет о завершении проекта (project close-out report);

Окончательные версии всех проектных документов;

Показатели удовлетворенности заказчика и потребителей;

Описание последующих шагов.

Рекомендуемые промежуточные вехи:

Ключевые компоненты развернуты;

Внедрение на местах завершено;

Внедренное решение стабилизировано.

О чем еще рассказывается в модели процессов

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

Дается множество определений.

Дисциплина управления проектами

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

Ответственность за управление проектом распределена среди лидеров ролевых кластеров внутри команды.

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

Распределение ответственности по управлению проектом среди лидеров групп

Дисциплина управления рисками

Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI). При этом интерпретация этой модели дается в контексте опыта Microsoft. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя:

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

Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов.

Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения.

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

Дисциплина управления по дготовкой

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

Определение

Проектные сценарии ( s cenarios).

Квалификационные требования (competencies) .

Профессиональные навыки (proficiencies) .

Измерение знаний, умений, способностей ( m easure knowledge, skills, abilities).

Анализ несоответствий ( a nalyze gaps).

Создание учебных планов ( c reate learning plans).

Корректировка

Мониторинг прогресса (track progress) .

Анализ результатов (review results) .

Управление знаниями (manage knowledge) .

Новая версия MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д. Данная версия выглядит, как облегченный вариант 3.0 и ориентирована на продукты Microsoft , а именно Visual Studio 2005 Team System и MS Project .

В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи от реализации заказных IT-решений и в целях улучшения работы с субподрядчиками обобщила свой опыт по разработке, внедрению, сопровождению и консалтингу ПО , создав методологию MSF . В 2002 году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:

модель процессов ( process model ),
модель команды ( team model ),
модель управления проектами ( project management ),
дисциплина управления рисками ( risk management ),
управление подготовкой ( readiness management ).

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

Основными новшествами MSF является следующее.

Акцент на внедрении IT-решения.
Модель процесса , объединяющая спиральную и водопадную модели.
Особая организация команды – не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников.
Техника управления компромиссами .

Ниже мы рассмотрим эти положения более детально.

В 2005 году MSF претерпело значительные изменения. Верcия MSF 4.0. стала составной часть продукта Visual Studio Team System (VSTS) и разделилась на две ветки – MSF for Agile и MSF for CMMI . При этом, если версии до 3.х были именно методологиями (там были изложены принципы, MSF свободно распространялась в виде Word-документов, которые были также переведены на русский язык), то теперь MSF превратилась в шаблоны процесса для VSTS. Эти шаблоны имеют описание в виде html -документов (Word-документов уже нет) и определяют типы ролей, их ответственности, действия в рамках этих ответственностей, а также все входные и выходные артефакты этих деятельностей и другие формализованные атрибуты процесса разработки. Кроме этого "человеческого" описания MSF for Agile и MSF for CMMI имеют XML -настройки, которые позволяют в точности следовать предложенным выше описаниям, используя VSTS. При этом на процесс накладываются достаточно жесткие ограничения, деятельность разработчиков сопровождается набором автоматических действий – все это задано в шаблонах. Данные шаблоны можно частично использовать (например, без некоторых ролей), а также изменять (VSTS предоставляет обширные средства настройки шаблонов). Версия MSF 4.2 продолжила направление версии MSF 4.0.

Можно считать, что фактически, версии MSF 4.x являются продуктами другого класса, чем MSF 3.x. MSF 3.х были нацелены на разработку заказных IT-решений, MSF 4.0 – на разработку произвольного ПО . Формально, документация этих версий не сильно пересекается и содержит для 3.х в большей степени общие принципы, а для 4.х – формальные атрибуты в терминах VSTS. В некотором смысле можно сказать, что MSF 4.х является реализацией MSF 3.х для продукта VSTS. В этой лекции мы рассмотрим основные принципы MSF . то есть, фактически, MSF 3.1, а в лекциях, посвященных VSTS будут рассмотрены MSF for Agile и MSF for CMMI .

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

Перечислим основные принципы MSF .

Единое видение проекта. Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения ( shared vision ), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта . Как проектная группа, так и заказчик изначально имеют собственные предположения о том, что должно быть достигнуто в ходе работы над проектом. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели. Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу – "Выработка концепции", которая заканчивается соответствующей вехой.
Гибкость – готовность к переменам. Традиционная дисциплина управления проектами и каскадная модель исходят из того, что все требования могут быть четко сформулированы в начале работы над проектом, и далее они не будут существенно изменяться. В противоположность этому MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности.
Концентрация на бизнес-приоритетах. Независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен удовлетворить определенные нужды потребителей и принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр. Что же касается организаций, то неизменным целевым фактором продукта является бизнес-отдача ( business value). Обычно продукт не может приносить отдачу до того, как он полностью внедрен. Поэтому модель процессов MSF включает в свой жизненный цикл не только разработку продукта, но и его внедрение.
Поощрение свободного общения. Исторически многие организации строили свою деятельность на основе сведения информированности сотрудников к минимуму, необходимому для исполнения работы (need-to-know). Зачастую такой подход приводит к недоразумениям и снижает шансы команды на достижение успеха. Модель процессов MSF предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат , но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом - как для проектной команды, так и для заказчика и других заинтересованных в проекте сторон.

Модель команды

Основные принципы. Главная особенность модели команды в MSF является то, что она "плоская", то есть не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные. Конечно, далеко не каждая команда способна так работать – собственно, начальники для того и нужны, чтобы нести основной груз ответственности за проект и, во многом, освободить от него других. Демократия в команде возможна при высоком уровне осознанности и заинтересованности каждого, а также в ситуации равности в профессиональном уровне (пусть и в разных областях – см. различные ролевые кластеры в команде, о которых речь пойдет ниже). С другой стороны, в реальном проекте, в рамках данной модели команды, можно варьировать степень ответственности, в том числе вплоть до выделения, при необходимости, лидера.

Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств:

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

Ролевые кластеры. MSF основан на постулате о семи качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы и образуют ролевые кластеры (или просто роли ) в проекте. В каждом ролевом кластере может присутствовать по одному или несколько специалистов, некоторые роли можно соединять одному участнику проекта. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников ( команда равных, team of peers ), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами ( stakeholders ) при распределенной ответственности за достижение общего успеха. В MSF следующие ролевые кластеры (часто их называют ролями) – см. рис. 9.1.

Управление продуктом ( product management ). Основная задача этого ролевого кластера – обеспечить, чтобы заказчик остался довольным в результате выполнения проекта. Этот ролевой кластер действует по отношению к проектной группе как представитель заказчика и зачастую формируется из сотрудников организации-заказчика. Он представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. В него же входит контроль за полным пониманием интересов бизнеса при принятии ключевых проектных решений.
Управление программой ( program management ) обеспечивает управленческие функции – отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта , разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград.
Разработка ( development ). Этот ролевой кластер занимается, собственно, программированием ПО.
Тестирование ( test ) – отвечает за тестирование ПО.
Удовлетворение потребителя ( user experience ). Дизайн удобного пользовательского интерфейса и обеспечение удобства эксплуатации ПО (эргономики), обучение пользователей работе с ПО, создание пользовательской документации.
Управление выпуском ( release management ). Непосредственно ответственен за беспрепятственное внедрение проекта и его функционирование, берет на себя связь между разработкой решения, его внедрением и последующим сопровождением, обеспечивая информированность членов проектной группы о последствиях их решений.
Архитектура (Architecture) 1 Этот ролевой кластер появился в версиях MSF 4.х. До этого данная ответственность входила в ролевой кластер "Управление программой". . Организация и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.

Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять строго из 7 человек. Один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице ниже представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. "+" означает, что совмещение возможно, "+-" - что совмещение возможно, но нежелательно, "-" означает, что совмещение не рекомендуется.

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

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений ( feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия, каждая из которых устроена на основе модели кластеров. Это компактные мини-команды, образующие матричную организационную структуру. В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика . Например, может быть сформирована специальная группа проектирования и разработки сервисов печати.

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы ( functional teams), которые затем объединяются в ролевые кластеры . Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.

Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft Visual Basic .

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

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

Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.

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

В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.

MSF состоит из двух моделей:

модель проектной группы ;
модель процессов,

и трех дисциплин:

управление проектами;
управление рисками;
управление подготовкой.

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

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

Жизненный цикл процессов в MSF сочетает водопадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (Рис. 1.4).

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

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

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

Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF - Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.

В состав Visual Studio Team Edition входит специальная редакция для тестировщиков - Team Edition for Software Testers (Рис. 1.6). Материалы семинарских занятий по данному курсу ориентированы на эту среду разработки, в то время как лекционные материалы ориентированы на изложение общих принципов и методик тестирования.

увеличить изображение
Рис. 1.6. Структура Microsoft Visual Studio 2005 Team System

1.4.2. Rational Unified Process

Rational Unified Process - это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования и процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.

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

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

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

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

итерационной разработке ПО;
управлении требованиями;
использовании компонентной архитектуры ;
визуальном моделировании;
тестировании качества ПО;
контроле за изменениями в ПО.

RUP организует работу над проектом в терминах последовательности действий ( workflows ), продуктов деятельности, исполнителей и других статических аспектов процесса, с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО ( milestones ), т.е. в терминах динамических аспектов процесса - с другой. [29]

1.4.3. eXtreme Programming

Экстремальное программирование [36] - сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями. По своей сути экстремальное программирование (XP) - это одна из, так называемых, "гибких" методологий разработки ПО, которая представляет собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.

XP ориентирована на:

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

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

Основными практиками XP являются:

Планирование процесса
Частые релизы
Метафора системы
Простая архитектура
Тестирование
Рефакторинг
Парное программирование
Коллективное владение кодом
Частая интеграция
40-часовая рабочая неделя
Стандарты кодирования
Тесное взаимодействие с заказчиком

1.4.4. Сравнение технологий MSF, RUP и XP

Основные особенности MSF, RUP и XP сведены в таблицу 1.2 [1]. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.

Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.

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

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

Содержание

История

MSF была впервые представлена Microsoft как версия 1.0 в 1993 году, а версия 2.0 была выпущена в 1997 году.

В 2002 году была выпущена версия 3.0 MSF. Он модифицировал версию 2.0 следующим образом:

Объединение ранее отдельных моделей в унифицированные модели группы и процесса, предназначенные для применения в различных типах проектов, включая развертывание, интеграцию корпоративного программного обеспечения и проекты разработки.
Сложил модели разработки приложений и развертывания инфраструктуры в единую модель процесса, состоящую из пяти этапов.
Добавлены дисциплины управления проектами и готовности.
Внесены изменения в Дисциплину управления рисками.
Добавлены ссылки между MSF и Microsoft Operations Framework (MOF).
Добавлена программа MSF для практиков, предназначенная для обучения людей руководству проектами MSF или участию в них.

Версия MSF 4.0 была выпущена в 2005 году. Этот выпуск был крупным обновлением модели процесса (теперь называемой моделью управления) и модели группы. MSF 4.0 включала методы для двух отдельных методологий: MSF для гибкой разработки программного обеспечения (MSF Agile) и MSF для улучшения процесса CMMI (MSF4CMMI).

Компоненты

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

MSF 4.0 предоставляет высокоуровневую структуру руководств и принципов, которую можно сопоставить с различными шаблонами предписывающих процессов. Он имеет как описательную, так и предписывающую методологию . Описательный компонент называется MSF 4.0 метамодели , которая является теоретическим описанием SDLC передового опыта для создания методологии SDLC. Microsoft считает, что в процессе разработки программного обеспечения организации имеют разную динамику и противоположные приоритеты ; некоторым организациям нужна гибкая и адаптируемая среда разработки программного обеспечения, в то время как другим нужна стандартизированная, воспроизводимая и более контролируемая среда. Чтобы удовлетворить эти потребности, Microsoft представляет метамодель MSF 4.0 в двух шаблонах предписывающих методологий, которые предоставляют конкретные инструкции по процессам, для гибкой разработки программного обеспечения (MSF4ASD) и для модели зрелости возможностей (MSF4CMMI). Эти процессы разработки программного обеспечения можно изменять и настраивать в соответствии с предпочтениями организации, клиента и проектной группы.

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

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

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