Mетодология Microsoft Solutions Framework (MSF) компании Microsoft. Модель проектной группы MSF. Модель команды msf

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 7.20.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 7.12

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

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

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

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

Таблица 7.13

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

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

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

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

Таблица 7.14

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

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

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

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

Рис. 7.21.

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

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

Рис. 7.22.

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

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

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

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

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

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

(Microsoft Solutions Framework)

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT‑решений. Сочетает в себе свойства двух стандартных производственных моделей: каскадной и спиральной. Она может быть применена при разработке весьма широкого круга программных проектов.

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

Являясь гибридом каскадной и спиральной моделей, модель жизненного цикла MSF сочетает простоту управления каскадной модели с гибкостью спиральной (см. рис. 6.10).

Рис. 6.10 . Построение модели жизненного цикла MSF на базе каскадной и спиральной моделей.

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

Базовыепринципы MSF:

Единое видение проекта - четкое и одинаковое понимание целей и задач проекта членами проектной группы и заказчиком.

Гибкость - непрерывная изменяемость условий проекта при неизменной эффективности управленческой деятельности.

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

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

Основными фазами модели MSF являются:

1. Создание общей картины приложения (Envisioning ) .На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».

2. Планирование (Panning). Этап состоит из трех стадий:

Концептуальное проектирование - определение набора сценариев использования системы,

Логическое проектирование - решение представляется в виде набора сервисов

Физическое проектирование - уточняются используемые технологии и интерфейсы.

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

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

5. Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.

ТЕМА 4: ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ: ИНИЦИАЦИЯ, ПЛАНИРОВАНИЕ, ИСПОЛНЕНИЕ, КОНТРОЛЬ, ЗАВЕРШЕНИЕ.

Процессы инициации

2. Процессы планирования

Процессы исполнения

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

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

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

MSF содержит следующие модели:

Team Model (Модель команды) описывает коллектив, в котором работа одного сотрудника зависит от другого;

Proccess Model (Модель процесса) позволяет определить принципы планирования и контроля проектов;

Application Model (Модель приложения) помогает создавать приложения, максимально используя готовые компоненты;

Enterprise Architecture Model (Модель архитектуры корпорации) - обеспечивает принятие решения по технологиям; она очень важна для эффективного использования новых технологий;

Solution Desing Model (Модель проектирования решений) - показывает, каким должно быть приложение с точки зрения пользователя. Эта модель связывает приложение, команду разработчиков и процесс разработки;

Infrastructure Model (Модель управления инфраструктурой) - определяет принципы управления пользователями в больших сетях;

Total Cost of Ownership Model (Модель стоимости владения продуктом) - позволяет оценивать расходы на информационные технологии.

Базовыми компонентами методологии являются:

Solution Development Discipline (SDD) дисциплина разработки решений. Содержание этой дисциплины связано с уникальными моделями: моделью команды и моделью процесса, которые рекомендуется использовать для организации эффективных команд проектов и управления жизненным циклом проекта. SDD включает три фундаментальные модели MSF:

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

Итеративная модель процесса разработки - описывает, как должен быть организован процесс,

Сетевая трехслойная модель приложения - описывает, какой должна быть структура приложения, удовлетворяющего современным требованиям;

Designing Component Solutions (DCS) проектирование компонентного ПО. Эта дисциплина направлена на поддержку процесса проектирования сложных моделей распределенных вычислений;

Enterprise Architecture Planning планирование архитектуры предприятия. С точки зрения Microsoft, это итеративный процесс, сосредоточенный на долгосрочном планировании, но при этом направленный на достижение результатов в максимально сжатые сроки;

Infrastructure Deployment and Management управление технологической инфраструктурой. Эта дисциплина содержит подход к процессу внедрения в масштабах предприятия как новых информационных технологий, так и отдельных программных продуктов и приложений.

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

Процесс MSF

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

Цикл (виток спирали) разработки включает четыре фазы и завершается выпуском версии продукта. Каждая фаза представляет собой определенную последовательность действий и завершается вехой (milestone).

Первая фаза Анализ (Envisioning). На данном этапе формируется представление о продукте на данном витке спирали. Это гарантирует, что разрабатываемый продукт будет соответствовать как текущим, так и перспективным целям компании, а также поможет скорректировать направление развития компании. Данная стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт получает одобрение, то составляется группа разработки проекта, задача которой - выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же устанавливаются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях. Вехой данной фазы является утверждение представления.

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

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

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

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

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

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

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

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

Разработка;

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

Обучение пользователей;

Сопровождение (логистика).

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

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

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

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

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

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

Модель приложения

Модель приложения MSF основана на трех основных понятиях.

Многослойное (Multi-tier) приложение - позволяет адекватным образом описать различные аспекты распределенных приложений. Модель приложения MSF выделяет три основных слоя:

Пользовательский интерфейс;

Бизнес-правила;

Управление данными.

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

Информационные службы;

Бизнес-службы;

Пользовательские службы.

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

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

Проектирование компонентного ПО

Процесс проектирования MSF состоит из трех стадий.

Первая стадия концептуальное проектирование это описание точки зрения пользователя на проект. На этом этапе происходит следующее:

Определение существа проблемы, подлежащей решению, установление цели разработки;

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

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

Составление сценариев «Как есть» и «Как должно быть». Сценарии являются основным выходом стадии концептуального проектирования;

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

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

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

Планирование архитектуры предприятия

Цель планирования архитектуры предприятия (Enterprise architecture planning) - показать менеджерам предприятия, занимающимся планированием бизнеса, как связаны между собой бизнес-цели и информационные технологии, направленные на поддержку этого бизнеса, а кроме того, как можно использовать фундаментальные модели для планирования развития бизнеса. Без подобного документа, ориентированного на менеджеров высшего уровня, обосновать и утвердить финансовый план внедрения новых информационных технологий весьма и весьма сложно, так как специалисты в области информационных технологий и бизнес-менеджеры «разговаривают на разных языках». Цель данного компонента методологии - нахождение общего языка. В рамках данного обзора мы не предполагаем давать стилевые рекомендации о том, как создавать такого рода документ или иной артефакт, на основании которого менеджмент будет принимать решение, а лишь укажем набор необходимых аспектов, которые рекомендуется включить в документы.

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

Модель архитектуры предприятия предполагает наличие архитектуры бизнеса и архитектуры приложений:

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

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

Информационная архитектура - определяет:

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

Концептуальную модель данных для объектов и их связей,

Текущую информационную топологию (распределение данных по подразделениям или серверам),

Целевую топологию для будущей бизнес-архитектуры;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вспоминая предыдущую лекцию… Наша предыдущая лекция была посвящена визуальному моделированию в процессе анализа и проектирования и основам языка UML. При этом сначала в качестве введения мы кратко повторили: –типовую схему решения задач с использованием вычислительной техники; –основные положения алгоритмической и объектной декомпозиции; –принципы объектного подхода к анализу и проектированию. Далее мы обсудили, чем вызвана необходимость в визуальном моделировании программных систем и рассмотрели историю языка UML.

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

Введение в методологию MSF и историческая справка… Что такое методология? Методология – принципы и способы организации теоретической и практической деятельности. Совокупность методов, применяемых в какой-либо науке. Для SE сформулируем так: Методология есть принципы и способы организации деятельности проектной группы для создания программного продукта. Программный продукт – решение. Проектная группа – команда.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF 1: MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. 2: MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых «белых книгах» («whitepapers»), каждый из которых охватывает определенную дисциплину или модель MSF.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF Дисциплины и модели MSF: –Модель процессов MSF. –Модель проектной группы MSF. –Дисциплина управления проектами MSF. –Дисциплина управления рисками MSF. –Дисциплина управления подготовкой MSF. 3: MSF предлагает несколько оригинальных идей, с которыми мы подробно будем знакомиться далее, а пока просто перечислим их: –Единое видение проекта –Треугольник и матрица компромиссов –Проектная группа – команда равных –Управление рисками –…

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

Введение в методологию MSF и историческая справка Источники информации –Основным источником, безусловно, являются белые книги (в настоящий момент доступные для версии MSF 3.0). –Немало сведений можно найти на сайте компании Microsoft, включая разделы портала TechNet (–Кроме того, желающие могут прослушать авторизованные курсы, связанные с MSF. –Информация по последней версии MSF 4.0:

Нововведения версии MSF 4.0… Два направления в MSF 4.0 –MSF for Agile Software Development –MSF for CMMI Process Improvement Мы рассматриваем MSF for Agile Software Development CMMI (Capability Maturity Model Integration) – существенно более формализованная методология, чем Agile development, ориентированная на разработку ПО в больших коллективах.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Предлагает максимально облегченный и гибкий подход к процессу разработки. Другой пример подобных методологий - Extreme Programming (XP). Agile направление в MSF ориентируется на небольшие команды (5-6 человек). Предполагает, что информация о разрабатываемом продукте не просто выясняется в процессе разработки, а может и будет изменяться по ходу. Таким образом, первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Элементы методологии: –рекомендованные процессы создания 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 for Agile Software Development… Основные принципы построения команды Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп. Построение команды в MSF соответствует ряду ключевых концепций, часть которых кажутся очевидными, другие сродни «ноу-хау».

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

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (2): –Нацеленность на конечный результат (product mindset) – каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. –Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. –Из этого не следует, что сам процесс может быть плох или непродуман – просто он существует для получения конечной цели, а не ради себя самого.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (3): –Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Цель команды – выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. –В успешной команде каждый сотрудник чувствует ответственность за качество продукта. –Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (1): –«Проектная группа – команда равных» (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. –Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи. –В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. –Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (2): –Стремление к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. –Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. –По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

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

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Ролевые группы (кластеры) –Управление программой (program management) –Архитектура продукта (architecture) –Разработка (development) –Тестирование (test) –Управление выпуском (release operations) –Удовлетворение потребителя (user experience) –Управление продуктом (product management)

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Роли: –менеджер проекта (project manager) – ролевая группа Управление программой –архитектор (archrect) – ролевая группа Архитектура –разработчик (developer) – ролевая группа Разработка –тестер (tester) – ролевая группа Тестирование –релиз-менеджер (release manager) – ролевая группа Управление выпуском –бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя