Автор: Пользователь скрыл имя, 12 Ноября 2011 в 20:46, реферат
В 1993 году, стремясь достичь максимальной отдачи от IT-проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия.
Методология
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;
-отчеты;
-портал
проекта (шаблон сайта
MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях использования.
Инструментальная поддержка MSF 4.0
У MSF 4.0 в отличие от предыдущих редакций появилась инструментальная поддержка в среде разработки Microsoft Visual Studio 2005 Team System. Фактически среда Visual Studio 2005 может выступать теперь в качестве интегрирующего средства, из которого можно работать со всеми инструментами, обеспечивающими стадии процесса разработки от создания планов проекта до проведения различных видов тестирования, включая создание и выполнение тестовых сценариев.
Основные концепции методологии MSF
MSF – методология разработки
MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых “белых книгах” (“whitepapers”), каждый из которых охватывает определенную дисциплину или модель MSF:
Модель процессов MSF
Модель проектной группы MSF
Дисциплина управления проектами MSF
Дисциплина управления рисками MSF
Дисциплина управления подготовкой MSF
Модель процессов MSF предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом - как для проектной команды, так и для заказчика и других, заинтересованных в проекте сторон.
Структура процессов MSF
Говоря о моделях процессов жизненного цикла проектов разработки ПО, в первую очередь нужно упомянуть о двух основных схемах: водопадной и спиральной (рис. 2), которые отражают два разных подхода к организации этих работ.
Рис. 2. Водопадная и спиральная модели разработки |
|
Водопадная модель предусматривает четкий переход от этапа к этапу: работы следующего этапа начинаются только после выполнения всех задач предыдущего. Такой стиль подходит для проектов, в которых проектные требования четко определяются заранее и с большой вероятностью не будут корректироваться потом. Данная схема организации разработки очень удобна с точки зрения управления проектом, так как позволяет четко сформулировать состав и обязанности его участников и контролировать графики выполнения проекта.
Спиральная модель обычно ориентируется на крайний случай, когда требования и параметры проекта непрерывно корректируются, а новые требования формулируются лишь по мере необходимости выполнения конкретных работ. Такая схема часто ассоциируется с понятием "экстремальной разработки"; при этом исполнитель и заказчик работают в постоянном тесном сотрудничестве, клиент привлекается на каждом этапе, формулируя свои соображения по поводу созданных компонентов. Однако при такой организации очень велик риск, что процесс разработки выйдет из-под контроля, поэтому реально данная модель используется лишь в относительно небольших проектах.
Однако
проблема заключается в том, что
чаще всего все требования на задание
действительно практически
|
Рис. 3-Этапы и контрольные точки модели MSF
В
этом случае планирование на основе промежуточных
контрольных точек и
Создание общей картины приложения
На этом этапе решаются следующие основные задачи:
определение состава команды;
определение структуры проекта;
определение бизнес -целей;
оценка существующей ситуации;
создание документа общей картины и области действия проекта;
определение требований и профилей пользователей;
разработка концепции решения;
оценка риска;
закрытие этапа.
На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".
Организован костяк команды. Здесь не обязательно нужен полный поименный список команды, но в документе структуры проекта должны быть определены роли и обязанности каждого члена команды, а также описана иерархия отчетности и ответственности в группе, каналы взаимодействия с заказчиком и общая структура команды.
Создана общая картина решения. Речь идет о разработке концепции решения, которым должна руководствоваться команда для достижения долгосрочных бизнес - целей проекта. Область действия проекта определяет, что включается в контекст проекта, а что выходит за его рамки. На этой временной точке речь идет о создании первой версии документа, который находится в стадии рецензирования участниками команды и согласования заказчиком.
Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".
Планирование
На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовится функциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроков получения результатов.
На этом этапе проводится анализ требований, которые делятся на бизнес – требования, пользовательские, функциональные и системные требования. После сбора и анализа требований команды разрабатывается проект решения, определяются профили пользователей, после чего формируются сценарии применения решения, выполняемые пользователями одного типа, а затем определяются варианты использования системы.
Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес – требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и программные интерфейсы.
В ходе данного этапа решаются такие задачи:
разработка проекта и архитектуры решения;
создание функциональной спецификации;
разработка планов проекта;
разработка календарного графика;
создание среды разработки, тестирования и плотной эксплуатации;
закрытие этапа.
Контрольные
точки этапа планирования связаны
с достижением следующих
Информация о работе Методология Microsoft Solutions Framework