Методология управления проектами msf реферат

Обновлено: 02.07.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа содержит 1 файл

MSF.doc

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

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

Вторая версия методологии датируется 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), которые отражают два разных подхода к организации этих работ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методология RUP

Разрабатывайте программное обеспечение итеративно;
Управляйте требованиями;
Используйте компонентную архитектуру;
Визуализируйте модель программы;
Проверяйте качество программы;
Контролируйте изменения программы.

Рис 1. Рабочие процессы RUP

Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 1., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:

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

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

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

+ Сравнительная легкость описания и наглядность моделей

+ Возможность адаптирования методологии UML собственным элементам и видам диаграмм

+ Возможность автоматической генерации кода на основе построенных моделей при проектировании с использованием case средств, поддерживающих методологию

– Невозможность проведения детального анализа процессов

– Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации

Методология MSF

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

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

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

+ снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

+ непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

+ раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

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

- при итерациях приходится отбрасывать часть сделанной ранее работы.

Сравнительный анализ методологии RUP и MSF

Сравним две крупные методологии, предназначенные специально для создания корпоративных систем - Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF).

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
RUP	10-40 чел	Стандарты Rational	UML и продукты Rational	Удобно
MSF	3-20 чел	Адаптируемая	Любые	Удобно

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

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

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

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

MSF. Методология MSF основана на гибкой процессной модели и включает в себя командную разработку. Масштабирование, команды команд – это достаточно важные составляющие MSF. Нужно сказать, что MSF поддерживает полный жизненный цикл разработки, т.е. он включает в себя как MSF (Microsoft Solutions Framework), так и MOF (Microsoft Operations Framework), которые объединяют процессы концептуализации, создания, внедрения, сопровождения, расширения, развития программных продуктов.

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

Заключение

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

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

Приведен обзор предсказуемых методологий на примере Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF). Были обсуждены характерные черты этих методологий. Наряду с общими деталями были выявлены также и некоторые сложные моменты процесса разработки, связанные с управлением командой, планированием, стратегией менеджмента, взаимодействием с заказчиком, жизненным циклом программного продукта, внедрением и реализацией выбранной методологии.

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

Список источников

1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (№ 2), 1959, С. 10.

2. A.A. Ермолаев, В. М. Дёмкин. Управление проектами по разработке программных продуктов.

4. Уокер Ройс. Управление проектами по созданию программного обеспечения. Издательство "Лори", 2002 г. 424 с.

Опубликован: 12.03.2009 | Доступ: свободный | Студентов: 5139 / 1490 | Оценка: 4.44 / 4.12 | Длительность: 11:27:00

Аннотация: IT решение. Основные принципы MSF. Модель команды: основные принципы, ролевые кластеры. Масштабирование команды MSF. Модель процесса. Управление компромиссами.

История и текущий статус

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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