Методология 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 позволяет создавать и развертывать решения уровня предприятия, обеспечивая прогнозируемость хода проектов и учитывая реальные условия их выполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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