Методология Microsoft Solutions Framework

  Методология  
Microsoft Solutions Framework.  

   Историческая  справка

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

   Вторая  версия методологии датируется 1998 годом. Версия MSF 3.0 была представлена в 2001 году, а последняя – MSF 4.0 в 2005.

   Конечно, MSF не единственная методология разработки программных продуктов. Широко известна, например, технология Rational Unified Process (RUP), например, имеющая инструментальную поддержку в виде различных программных систем, наиболее известная из которых – Rational Rose и предлагающая весьма сильно формализованный подход к процессу разработки. До версии 3.0 включительно MSF существенно отличалась от RUP – во-первых, намного меньшей формализованностью, во-вторых, не просто отсутствием инструментов, а скорее отсутствием необходимости в таких инструментах. Идеология MSF предполагала, что концепции, которые MSF предлагает разработчикам, могут и должны быть адаптированы к требованиям конкретного проекта. В последней версии (4.0) идеология MSF претерпела некоторые изменения.

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

   Прежде  всего, в новой редакции методологии  делается упор на то, что MSF – это не просто набор рекомендаций, MSF – это образ мыслей (mindsets)!

   Рис. 1-  “Образ мыслей” MSF 4.0. 

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

   Важное  нововведение состоит в том, что  в MSF 4.0 произошло разделение методологии  на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.

     Если говорить кратко, MSF for CMMI Process Improvement – это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д.

   Основные положения MSF for Agile Software Development

   MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. Одним из примеров подобных методологий является Extreme Programming (XP).

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

   Методология MSF содержит весьма много элементов, в частности:

-рекомендованные процессы создания IT-проектов;

-структуру  итераций;

-роли  членов команды;

-шаблоны  документов (Excel, Word);

-шаблоны  Microsoft Project;

-отчеты;

-портал  проекта (шаблон сайта SharePoint).

   MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях использования.

   Инструментальная  поддержка MSF 4.0

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

   Основные  концепции методологии MSF

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

   MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых “белых книгах” (“whitepapers”), каждый из которых охватывает определенную дисциплину или модель MSF:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

определение состава команды;

определение структуры проекта;

определение бизнес -целей;

оценка  существующей ситуации;

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

определение требований и профилей пользователей;

разработка  концепции решения;

оценка  риска;

закрытие  этапа.

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

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

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

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

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

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

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

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

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

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

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

разработка  планов проекта;

разработка  календарного графика;

создание  среды разработки, тестирования и  плотной эксплуатации;

закрытие  этапа.

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

-функциональная спецификация;

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

-определение среды разработки и тестирования;

-генеральный план и календарный график проекта.

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

   Разработка 

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

-создание прототипа приложения;

-разработка программных компонентов приложения;

-создание решения (последовательность ежедневных или более частых сборок приложения);

-закрытие разработки (реализация всех функций, поставка кода и документации).

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

-исходный текст кода и исполняемые файлы;

-сценарии установки и конфигурации для развертывания;

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

-элементы поддержки решения;

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

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

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

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

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

-тестирование компонентов;

-тестирование баз данных;

-тестирование инфраструктуры;

-тестирование защиты;

-тестирование интеграции;

-анализ удобства работы с продуктом;

-нагрузочное тестирование (включая анализ ресурсоемкости и производительности);

-регрессивное тестирование;

-ведение отчетности по тестированию.

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

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

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

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

-развернуты основные компоненты;

-развернуто решение в целом;

-развернутое решение стабилизировано;

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

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

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

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

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

   Defining (определение требований);

   Designing (анализ и проектирование);

   Developing (разработка);

   Testing (тестирование);

   Deploying (развертывание).

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

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

   Формирование  команды. Модель проектной  группы MSF for Agile Software Development

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

   Основные  принципы построения команды

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

   К самоочевидным можно отнести:

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

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

   Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Она означает, что цель команды – выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. В успешной команде каждый сотрудник чувствует ответственность за качество продукта. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.

   Концепции, которые в определенном смысле можно  отнести к “ноу-хау” методологии MSF:

   “Проектная  группа – команда равных” (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи. В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.

   Стремление  к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

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

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

   Ролевые группы и роли

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

   MSF for Agile Software Development выделяет 7 ролевых групп (рис.4):

1) Управление программой (program management)

2)Архитектура продукта (architecture)

3)Разработка (development)

4)Тестирование (test)

5)Управление выпуском (release operations)

6)Удовлетворение потребителя (user experience)

7)Управление продуктом (product management)

   Рис.4-Модель команды в MSF 4.0 – ролевые группы 
И 6 ролей (рис.5):

   -менеджер проекта (project manager) – ролевая группа Управление программой

   -архитектор (archrect) – ролевая группа Архитектура

   -разработчик (developer) – ролевая группа Разработка

   -тестер (tester) – ролевая группа Тестирование

   -релиз-менеджер (release manager) – ролевая группа Управление выпуском

   -бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя