Главная › Срок годности › Методологии компании Microsoft. Каскадно-спиральная модель процессов MSF

Методологии компании Microsoft. Каскадно-спиральная модель процессов MSF

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

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

v “Модель процессов MSF”;

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

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

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

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

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

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

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

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

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

методологий других разработчиков ALM-продуктов.

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

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

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

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

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

· Разработка

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

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

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

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

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

· Наделение соответствующими полномочиями ролевых кластеров.

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

Введение

В 1994 году , стремясь достичь максимальной отдачи от IT -проектов, Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF ) и Microsoft Operations Framework (MOF ).

Следует отметить, что Microsoft разработала на базе общих методов MSF методики для прикладного и специализированного применения. Причем Microsoft стратифицирует экспертов именно по прикладным знаниям в применении MSF (например, сертификация MCTS 74-131 по экспертизе в методике управления проектами). Перед тем как изучать методы MSF, следует сначала определить, какой прикладной вариант MSF имеется ввиду.

Наиболее популярные прикладные варианты MSF разработанные Microsoft:

Методика внедрения решений в области Управления проектами

Методика управления IT-проектами на базе методологий MSF и Agile

Важность прикладных вариантов MSF подчеркивает тот факт, что в «чистом варианте» саму методику MSF в своих IT-проектах компания Microsoft не использует. В проектах Microsoft Consulting Services используется гибридная методология MSF и Agile. Несмотря на внешние существенные различия прикладных вариантов MSF разработанных экспертами Microsoft, общая база методов MSF для них остается общая и отражает общие методологические подходы к итеративному ведению проектов.

MOF призван обеспечить организации, создающие критически важные (mission-critical) IT решения на базе продуктов и технологий Майкрософт , техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL ), составленной Central Computer and Telecommunications Agency - Агентством правительства Великобритании. Информация по MOF доступна в Internet по адресу.

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

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.

MSF содержит:

модели :
- модель проектной группы
- модель процессов
дисциплины :
- дисциплина управление проектами
- дисциплина управление рисками
- дисциплина управление подготовкой

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

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

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

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

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

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

Распределение ответственности при фиксации отчетности
Наделяйте членов команды полномочиями
Концентрируйтесь на бизнес-приоритетах
Единое видение проекта
Проявляйте гибкость - будьте готовы к переменам
Поощряйте свободное общение

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

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

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

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

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

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

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

управление программой (program manager) - разработку архитектуры решения, административные службы;
разработку (developer) - разработку приложений и инфраструктуры, технологические консультации;
тестирование (QAE) - планирование, разработку тестов и отчетность по тестам;
управление выпуском (release manager) - инфраструктуру, сопровождение, бизнесы-процессы, выпуск готового продукта;
удовлетворение заказчика (user experіence) - обучение, эргономику, графический дизайн, техническую поддержку;
управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс MSF ориентирован на «вехи » (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.

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

Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:

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

Модель процессов включает такие основные фазы процесса разработки:

Выработка концепции (Envisioning)
Планирование (Planning)
Разработка (Developing)
Стабилизация (Stabilizing)
Внедрение (Deploying)

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

что (какие артефакты) является результатом этой фазы
над чем работает каждый из ролевых кластеров на этой фазе

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

Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

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

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

Управление рисками (risk management) - это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF - мы не боремся с рисками - мы ими управляем .

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

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

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

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

Для иллюстрации использования матрицы компромиссов Майкрософт предлагает использовать следующее предложение (вместо пропущенных слов могут быть вставлены «календарный график», «ресурсы» и «функциональность»): «Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________».

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

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS . Иерархическая структура работ (Work Breakdown Structure - WBS ) - это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

Управление подготовкой

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

Cледует отметить, что MSF не навязывает использование других продуктов Microsoft . Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland , хотя будущая версия MSF 4.0 будет жестко привязана к Microsoft Team System - новому инструментальному средству Майкрософт для поддержки командной работы над проектом.

Версии MSF

Первая версия MSF появилась в 1994 году . Текущая версия - MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.

Кроме этого, появилась роль архитектора и поддержка методологии в инструменте - Microsoft Visual Studio Team System .

Андрей Колесов

Обзор подготовлен на базе материалов, представленных в учебном курсе для подготовки к экзамену по программе сертификации Microsoft Certified Solution Developer N 70-300: Analyzing Requirements and Defining Microsoft .NET Solution Architectures. Русский перевод этого курса выпущен в 2004 г. издательством "Русская Редакция" под названием "Анализ требований и создание архитектуры решений на основе Microsoft .NET".

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft (http://www.microsoft.com) пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении (об этом свидетельствуют последние новости с конференции TechEd"2004, см. врезку), и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft для разработчиков - новости с TechEd"2004

На проходившей в конце мая в Сан-Диего (шт. Калифорния, США) конференции Microsoft TechEd"2004 был сделан целый ряд важных объявлений относительно развития средств разработки, новых инициатив в области безопасности информационных систем и поддержки жизненного цикла продуктов Microsoft.

На конференции были представлены два новых инструмента, предназначенных для интеграции с текущей версией Visual Studio .NET 2003. Первый из них, Web Services Enhancements 2.0 (WSE 2.0), позволяет повысить уровень безопасности создаваемых Web-сервисов за счет использования самых последних спецификаций протоколов WS-Security (на базе утвержденных в 2004 г. стандартов OASIS), в том числе WS-Policy, WS-Security Policy, WS-Trust и WS-SecurityConversation. Версия WSE 2.0 для VS.NET доступна уже сейчас. Кроме того, Microsoft планирует использовать эту технологию для решения задач интеграции данных и приложений: специальный модуль BizTalk Server Adapter for WSE 2.0 представлен пока лишь в виде предварительной технической версии.

Второй инструмент - Microsoft Office Information Bridge Framework (IBF), реализованный сейчас в виде бета-версии, - дает возможность использовать Microsoft Office в качестве интеллектуальных клиентских приложений при работе с Web-сервисами, созданными с помощью WSE 2.0. IBF представляет собой набор из нескольких компонентов, предназначенных для разработчиков и пользователей. Один из них устанавливается со стороны Office 2003 Pro и обеспечивает взаимодействие с IBF-приложениями прямо из офисных документов через смарт-теги. Второй компонент IBF - конструктор Information Bridge Metadata Designer, подключаемый к среде VS.NET и обеспечивающий визуальную разработку Web-сервисов с использованием модели безопасности WSE 2.0. В состав IBF входит также Information Bridge Metadata Service - серверный программный модуль, позволяющий передавать на клиентское ПО данные от запущенных на выполнение бизнес-приложений через Web-сервисы.

Однако для разработчиков, пожалуй, наиболее интересна информация о намерении существенно расширить в VS.NET возможности управления всем жизненным циклом приложений. Представленная на TechEd"2004 версия Visual Studio 2005 (кодовое имя Whidbey) Enterprise Edition получила название Visual Studio Team System (VSTS). Предполагается, что эта система будет поставляться в трех основных вариантах: Team Architect, Team Developer и Team Test.

Предназначенный для архитекторов программных решений инструмент Team Architect включает три конструктора для проектирования распределенных приложений, моделирования логической инфраструктуры и автоматической генерации кода. Последний из них (class designer) выполняет двухстороннюю синхронизацию между визуальной моделью проекта и программным кодом. Примечательно, что в нем используется не классический UML, а собственная нотификация языка моделирования Microsoft. Для поддержки UML в Visual Studio будет по-прежнему использоваться Visio, но встроенные средства самого VS развиваются в несколько ином направлении.

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

Следует отметить, что Team Architect представляет собой развитие средств, уже имеющихся в текущей версии VS 2003. Функциональность же Team Developer лишь в незначительной степени покрывается текущей версией VS.NET 2003, для эффективного решения подобных задач сегодня требуется подключать соответствующие расширения для VS от третьих фирм. Но в VS 2005 разработчики смогут применять встроенные средства самой Microsoft.

Что же касается третьей составляющей VSTS - Team Test, предназначенной для нагрузочного тестирования приложений, то данная функциональность ранее была доступна лишь в автономных продуктах других поставщиков. Теперь же она появилась непосредственно в среде VS 2005, причем в исполнении Microsoft. При этом особое внимание будет уделено задачам тестирования Web-сервисов, в том числе с использованием скриптов, работающих с различными транспортными протоколами, и режимов удаленного мониторинга.

Из всей этой информации следует, что Microsoft наращивает возможности своего инструментария в направлении создания комплексных систем масштаба предприятия, включая в него средства автоматизированной поддержки всех этапов жизненного цикла приложений и постепенно вытесняя соответствующие расширения от третьих фирм. Тем не менее многие независимые поставщики одобрительно восприняли сделанные объявления, так как новшества VSTS позволят поднять на качественно новый уровень сотрудничество в рамках "партнерской экосистемы VS", охватывающей несколько десятков компаний-разработчиков. В частности, о своей поддержке будущего продукта на TechEd"2004 уже заявили Borland, Compuware, Telelogic AB и Unisys.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Русская версия Visual Basic .NET

В отличие от продуктов Microsoft массового спроса (Windows, Office), которые переведены на несколько десятков национальных языков, средства разработки Visual Studio .NET представлены сейчас лишь восемью локализованными версиями (французская, немецкая, испанская, итальянская, японская, корейская и два варианта китайских). Освоение русского языка началось лишь в этом году с одного инструмента, но зато самого массового, Visual Basic .NET Standard Edition (поставки его начались в мае 2004 г.). Чтобы представить себе значимость этого проекта, нужно иметь в виду, что полный объем локализации VS.NET 2003 составляет около 20 млн слов (включая всю справочную систему), что существенно превышает аналогичные показатели всего пакета Microsoft Office 2003. VB.NET Standard - это подмножество VS.NET, объем его локализации - 5,6 млн слов.

Нужно отметить, что редакция Standard не пользовалась до сих пор большим спросом со стороны профессиональных разработчиков. Тем не менее, по мнению сотрудников московского представительства Microsoft, наличие русской документации непременно повысит интерес разработчиков к VB.NET Standard, тем более что, несмотря на усеченные функции по сравнению с версией VS.NET Pro, с помощью этого инструмента можно создавать весьма широкий круг приложений, компонентов и Web-сервисов промышленного уровня. В отличие от VS.NET Pro, VB.NET Standard не может создавать элементы управления для Windows и Web, мобильные приложения, а также мощные серверные решения. Конечно же, в VB.NET не входят другие языки программирования - VC++, VC# и VJ#. Но подчеркнем, что VS.NET Pro стоит более 1000 долл. (вариант Upgrade - 550 долл.), а VB.NET Standard - всего 100 долл.

И все же появление русского VB.NET в основном связано с намерением Microsoft активно продвигать свои инструментальные средства в более широкие круги программистов, в первую очередь - в сферу образования, в частности, подготовки разработчиков.

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

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

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

дисциплины:

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

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

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

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

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

Наделение членов команды полномочиями

Концентрация на бизнес-приоритетах

Единое видение проекта

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

Поощрение свободного общения

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

Команда соратников

Сфокусированность на нуждах заказчика

Нацеленность на конечный результат

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

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

Заинтересованные команды работают эффективно

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

управление программой (program manager) - разработка архитектуры решения, административные службы;

разработка (developer) - разработка приложений и инфраструктуры, технологические консультации;

тестирование (QAE) - планирование, разработка тестов и отчетность по тестам;

управление выпуском/логистикой (release manager) - инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта;

удовлетворение заказчика (user experience) - обучение, эргономика, графический дизайн, техническая поддержка;

управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

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

Роль команды разработчиков не может быть объединена ни с какой другой ролью.

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

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

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

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

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

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

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

Компания Microsoft подготовила и применяет несколько методик для покрытия не только ЖЦИС, но и технологической инфраструктуры, их поддерживающей.

В контексте рассмотрения ЖЦПО нас интересует именно методология разработки: как являющийся одним из основных аспект управления и взаимодействия участников процесса, так и другие области знаний (управление рисками, планирование). В целом охватываемые MSF дисциплины описаны в пяти частях (так называемых белых книгах), однако интересно, что командами консультантов Microsoft применяется на практике не этот ресурс, а методика MSF for Agile Software Development, которая является прикладным вариантом MSF и отражает общий методологический подход к итеративной разработке.

Если обратиться непосредственно к процессу разработки и внедрения, то его характеризуют:

итеративность;
формирование в качестве результата ИТ-решения.

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

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

Основной состав MSF - это две модели и три дисциплины, которые подробно рассматриваются в пяти белых книгах. В состав MSF входят:

модели:
- - модель группы,
- - модель процессов;
дисциплины:
- дисциплина «Управление проектами»,
- Дисциплина «Управление рисками»,
- Дисциплина «Управление готовностью».

Модель процессов. Модель процессов - это «основа основ» методологии MSF. Модель процессов MSF основана на сочетании водопадной и спиральной моделей жизненного цикла ИС. Таким образом, в методологии MSF проект реализуется поэтапно, все этапы могут повторяться «по спирали», а между этапами существуют заранее определенные контрольные точки (рис. 7.20).

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

Создание общей картины ИТ-решения. Первый этап модели MSF - это Создание общей картины ИТ-решения. Задачи этапа таковы:

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

Рис. 7.20.

Этап содержит в себе две контрольные точки: «Костяк команды сформирован» и «Общая картина ИТ-решения создана».

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

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

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

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

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

Задачи Планирования могут быть сформулированы следующим образом:

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

Планирование - достаточно сложный и обширный этап, который насчитывает пять контрольных точек:

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

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

Разработка. Этап Разработки подразумевает непосредственное создание ИТ-решения, т.е. написание и документацию программного кода. Убедившись, что задачи предыдущих этапов выполнены, проектная команда приступает к реализации задач, характерных для этапа разработки:

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

В методологии MSF выделяют следующие результаты разработки:

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

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

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

Тестирование включает следующие виды активности:

тестирование компонентов;
тестирование БД;
тестирование ИТ-инфраструктуры;
тестирование безопасности;
тестирование интеграции;
тестирование эргономичности;
нагрузочное тестирование;
регрессивное тестирование;
ведение отчетности по тестированию.

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

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

Развертывание. Этап Развертывания включает установку ИТ-решения, промышленную стабилизацию и окончательную передачу заказчику и группе сопровождения. Основные контрольные точки этапа:

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

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

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

Таблица 7.12

Роли, цели и функциональные области MSF

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

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

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

Таблица 7.13

Варианты совмещения ролей в MSF

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

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

On Target. Методология внедрения решений On Target была разработана компанией Navision для внедрения своих программных продуктов. После приобретения Navision корпорацией Microsoft было принято решение доработать On Target, к тому моменту содержавшую шаблоны описаний бизнес-процессов, документации, организационных структур ИТ и квалификационных требований к специалистам (табл. 7.14).

Таблица 7.14

Этапы в методологии On Target

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

В силу того что к моменту приобретения Navision у Microsoft уже применялись свои проверенные корпоративные методологии MSF и MOF, в дальнейшем On Target была дополнена и к моменту выведения на рынок Microsoft Dynamics превратилась в результате доработок в MS Dynamics Sure Step/Microsoft Business Solutions Partner Methodology.

Microsoft Business Solutions Partner Methodology. MBS Partner Methodology - это дальнейшее развитие On Target. Эта методология ставит своей целью не просто создание ИС, но также максимальное удовлетворение потребностей заказчика.

Рис. 7.21.

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

Роли в проекте приведены на рис. 7.22.

Рис. 7.22.

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

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

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

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

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

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