Методология разработки

программного обеспечения Microsoft

Андрей А. Терехов
Московское представительство Microsoft
e-mail: andreyte@microsoft.com
 Успешные проекты нечасты в ИТ

Проваленные Проблемные Успешные

2000 23% 49% 28%

1998 28% 46% 26%

1995 40% 33% 27%

1994 31% 53% 16%

Статистика по 30,000 проектам по разработке ПО в американских компаниях.

Источник: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000
Успешные проекты – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ.
Проблемные – не уложились в сроки, перерасходовали бюджет и/или сделали не все, что требовалось.
Проваленные – не были доведены до конца.
 Microsoft Solutions Framework (MSF)
• Причиной появления MSF стало
осознание в Microsoft проблем в
собственном процессе разработки ПО
• Первоначальная версия MSF увидела
свет в 1994 г.
• В 2002 г. была опубликована последняя
версия MSF (v3.0)

• MSF является частью более широкого

набора методологий от Microsoft
 MSF и MOF
• MSF = Microsoft Solutions Framework
– Подход Microsoft к управлению
ИТ-проектами:
• Проекты разработки ПО
• Проекты развертывания инфраструктуры

• MOF = Microsoft Operations Framework

– Подход Microsoft к управлению
ИТ-процессами (операциями) на
предприятии
 MSF и MOF
Microsoft Solutions Framework

у ем
н ир
Пла
Экс
плу
ати
руе
м

Соз
дае
м
ем
др я
Вне

Microsoft Operations Framework

 Структура MSF
ДВЕ МОДЕЛИ

Модель Модель
Проектной Процессов
Группы

ТРИ ДИСЦИПЛИНЫ

Дисциплина Дисциплина Дисциплина

управления управления управления
Проектами Рисками Подготовкой
 Модель проектной группы
Управление проектом
Выработка архитектуры решения
Контроль производственного процесса
Административные службы
Бизнес-приоритеты
Маркетинг Управление Технологическое консультирование
Представление
интересов заказчика
программой Проектирование и осуществление реализации
Разработка приложений
Планирование продукта Разработка инфраструктуры

Управление
продуктом Разработка

Удовлетворение
потребителя Тестирование
Обучение Планирование тестов
Эргономика Разработка тестов
Графический дизайн Управление Отчетность по тестам
Интернационализация
Обеспечение технической
выпуском
поддержки Инфраструктура
Общедоступность (обеспечение Сопровождение
возможности работы для Бизнес-процессы
пользователей с ограниченными Управление
физическими возможностями) выпуском готового
продукта
 В MSF нет роли
“менеджер проекта”
Деятельность по управлению
проектом распределяется
между лидерами групп
и ролевым кластером
“Управление
программой”

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

на уровне всего проекта на уровне подгрупп

Характеристики проектной группы MSF

• Команда соратников (команда равных)

• Наличие единого видения проекта (shared vision)
• Распределение ответственности при
одновременной фиксации отчетности
• Нацеленность на необходимый заказчику
конечный результат
• Наличие у сотрудников необходимых полномочий
• Открытое общение
• Установка на отсутствие дефектов
• Стремление к самосовершенствованию
• Гибкость и готовность к переменам
• Заинтересованность и энтузиазм
Внешние связи проектной группы
Бизнес-цели
Пользоват
ели

Пользовате Удовл.
потребителя
Менеджер
Заказчик
продукта
ли

Проектная Тестер
группа

Разработчик

Планиров
Управл. Менеджер
Группы выпуском программы ание
эксплуатаци бизнеса
и
и
Технологическая
Технологически
сопровожде
архитектура
ния
е цели Стратегическое
планирование
 Замечание по терминологии

• Заинтересованные стороны (stakeholders)

– лица либо организации, чьи интересы
затрагиваются результатами проекта

• Спонсоры проекта (project sponsors)

– лица либо организации, которые
инициировали проект, выделяют для
проекта ресурсы и утверждают его
результаты. Иногда “project sponsor”
переводится как “куратор проекта”
Масштабирование модели проектной
группы

• В одном ролевом кластере может быть

много людей
• Один человек может взять на себя
несколько ролей
• Большие коллективы:
– Создаем группы направлений
– Создаем функциональные группы
• Малые коллективы:
– Используем таблицу совместимости ролей
 Большой коллектив
Руководящая
Управление
группа
программой

Управление
продуктом Разработка

Лидер Удовлетворение
группы потребителя Тестирование

Управление
Управление
Управление Управление
Управление
программой
программой выпуском программой
программой
Удовлетворение
потребителя Разработка
Разработка Разработка
Разработка
(функциональная группа)
Удовлетворение
Удовлетворение Удовлетворение
Удовлетворение
потребителя
потребителя Тестирование
Тестирование потребителя Тестирование
Тестирование
потребителя
Управление
Управление
программой
программой
Разработка Разработка средств
клиентских компонент Разработка
Разработка обмена сообщениями
(группа направления) (группа направления)
Удовлетворение
Удовлетворение Тестирование
Тестирование
потребителя
потребителя

Разработка
средств печати
(группа направления)
 Таблица совместимости ролей

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

- - + + ±
Управление
Управление
продуктом
продуктом

- - ± ± +
Управление
Управление
программой
программой

Разработка
Разработка - - - - -
Тестирование
Тестирование + ± - + +
+ ± - + ±
Удовлетворение
Удовлетворение
потребителя
потребителя

± + - + ±
Управление
Управление
выпуском
выпуском

+ Допустимо ± Нежелательно -
Нельзя
 Минимальный коллектив

Удовлетворение Управление
потребителя программой Разработка

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

Тестирование
 Модель процесса разработки
Внедрение Вы
завершено ко ра

ие
нц бо

ен
е п тк

р
ци а

ед
и
Вн

Готовность решения Концепция проекта

утверждена утверждена

ие
Ста

ван
би

иро
лиза

н
Пла
ция

Разработка Планы проекта

завершена утверждены

Разработка
 Итеративный подход
Минимизируем риски, разбивая большие проекты на
несколько версий
Функциональность

Версия 3

Версия 2

Версия 1
Время
 Промежуточные вехи
Внедрение
завершено
Внедренное решение стабилизировано
Ядро проектной группы сформировано
Внедрение на местах завершено
Черновой вариант концепции
Ключевые компоненты развернуты проекта составлен

Готовность решения Концепция проекта

утверждена утверждена
Пилотное внедрение завершено Верификация технологий
осуществлена
Контрольное тестирование завершено
Базовая версия функциональной
спецификации создана
Версии-кандидаты
Базовая версия сводного плана
Тестирование приемлемости для проекта создана
потребителей завершено
Базовая версия сводного календарного
Точка достижения нуля графика проекта создана
Среды разработки и тестирования
Точка конвергенции
развернуты

Разработка Планы проекта

завершена утверждены
Концепция подтверждена
Промежуточная версия 1 завершена
Промежуточная версия 2 завершена
Промежуточная версия N завершена
 Конвейер cборки программы

• Задача:
– Необходимость обеспечить параллельную работу
многих разработчиков
• Проблемы:
– Изменения разрушают сделанное ранее
– Множественность и подвижность участников
разработки => отсутствие цельного видения у
отдельных разработчиков
– Изменчивость платформ, средств разработки и
смежных программ в процессе разработки
 Технологические принципы

• Поддержание целостности сборки

(build)
• Авто-тестирование сборки (automation)
• Линейная последовательность
внесения изменений
 Как это происходит

• Основа – система управления версиями

(source code control)
• Подготовка изменения: check-out, кодировка,
отладка, проверка, структурный просмотр
• Постановка изменения в очередь – вход в
конвейер
• Принятие изменения: компиляция,
функциональная проверка, проверка
производительности, занесение в базу или
отвержение, оповещение
 Структура конвейера

• Классический конвейер:

• Конвейер программной сборки:

 Конвейер программной сборки

• Огромные аппаратные затраты – до 1,000

компьютеров на небольшую команду (30 чел.)
• Построение программы:
– 2 (2+) супермашины – debug & retail builds
• Функциональная проверка:
– 100-200 машин – параллельный прогон функциональных
авто-тестов
• Проверка производительности:
– 200-300 машин – параллельные группы тестов
производительности
• Приемка в главную базу данных
 Обслуживание конвейера
• Клиент on-line монитора:
– Текущий статус очереди
– Изменение приоритетов, досрочное снятие
– Ход исполнения построения и сборки
• Супервизор очереди:
– Раннее обнаружение конфликтов
– Слияние изменений
• Сервер авто-тестирования:
– Освобождение клиентского ресурса
– Сертификация изменения для ввода в конвейер
 Результат конвейера

• Постоянное поддержание действующей

сборки:
– за счет незначительного усложнения
индивидуальных изменений
– группа никогда не заблокирована в
дальнейшей разработке
– при постоянном гарантированном контроле
качества сборки
 Типичный сценарий выпуска ПО
Beta
Bug Convergence

Zero-Bug Release

Release Candidate
Active Golden Release
Bugs

Time
0

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

• Итеративный процесс
• Осуществляется на протяжении
всего проекта
• Базируется на посылке о присутствии
рисков в любом проекте
• Нацелена на проведение
профилактических мероприятий

Мы не боремся с рисками – мы ими управляем

 Процесс управления рисками

2
Анализ
1 Формулиро и
вка риска приори
тезация
Выявление Список
5 рисков 3
Гла Планиров
Коррекция вны ание
е
рис
6 ки
Извлеч
ение Монито
База знаний уроков ринг
о рисках 4
 Дисциплина управления
проектами
• Проект (project) – ограниченная временными
рамками деятельность, цель которой состоит
в создании уникального продукта или услуги
• Управление проектами (project management) –
это область знаний, навыков, инструментария
и приемов, используемых
для достижения целей
проектов в рамках

ы
Вр
рс
согласованных параметров

ем
су

я
Ре
качества, бюджета, сроков
Возможности
и прочих ограничений
 Управление изменениями

• Мы не можем
избежать изменений Согла
в проекте Фикси
совыв
Прини
руется мается
ается

• Но мы можем заранее Ресурсы

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

• Для этого
используется матрица
компромиссов
Дисциплина управления подготовкой

Определе
ние

Знания,
умения,
способнос
ти Оцениван
ие

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

• Например, для организации процесса

производства ПО можно использовать MSF
и при этом применять инструменты Borland
• Более того, MSF не навязывает даже
конкретную методологию разработки
программного обеспечения (как, например,
RUP)
• MSF – это концепция (framework),
применимая в самом широком наборе
случаев
Доступность стандартов, знание которых
требуется от ИТ-менеджера

Бесплатный Платный
доступ доступ

Есть MSF некоторые

русский стандарты ISO,
перевод PMBOK**, ITIL***

Только MOF, CMMI, RUP***,

английский SWEBOK*, стандарты IEEE,
вариант стандарты OMG стандарты ISO
 MSF и ...
• PMI PMBOK
– Whitepaper “MSF and the Project Management Body of Knowledge”
– http://www.webster.edu/~dlorenc/PMPStudy/Library/MSFandthePMBOK.doc

• RUP
– Whitepaper “Microsoft Solutions Framework and The Rational
Process”
– http://www.rational.com/media/whitepapers/msfratprcs.rtf

• CMM
– Whitepaper “Microsoft Solutions Framework and the Capability
Maturity Model”
– http://www.aurelian.ro/MSF/RESOURCE_KIT-PAD/papers/MSFAndTheCapMaturityModel.doc

Перечисленные документы ссылаются на предыдущие версии

MSF, однако общую картину этот факт не меняет
 Сравнение RUP, MSF и CDM

Производ Продукт Цена Допустимые Маркетинг

итель технологии и
инструменты
IBM Rational Unified ~ $700 Любые, но Ведется
Process акцент на активно
Rational Suite

Microsoft Microsoft $0 Любые Практически

Solutions не ведется 
Framework

Oracle Custom ~ $ 1500* Oracle Практически

Development ~ $ 2500** не ведется
Method
 Материалы по MSF
• На английском языке
– http://www.microsoft.com/msf
– http://www.microsoft.com/traincert/mcp/msf
• MCT могут получить доступ к учебникам и
презентациям курсов 1846 и 2710 через
MCT Download Center:
https://partnering.one.microsoft.com/mct
• Не MCT могут прослушать эти курсы в СТЕС.
В стоимость курса входит комплект материалов

• На русском языке
– http://www.microsoft.com/rus/msf
 Шаблоны и примеры документов

• Есть только на английском языке

• Шаблоны доступны бесплатно на
http://download.microsoft.com
– Нужно сделать поиск
по ключевому слову MSF
• Детальные примеры входят в
студенческий комплект материалов
курса 2710
– В т.ч. UML диаграммы (промежуточные
и окончательные версии)
 Курс 1846

• Microsoft Solutions Framework Essentials

• 3 дня, компьютеры не используются
• Изучаются все элементы MSF
• Великолепные деловые игры
• http://www.microsoft.com/traincert/syllabi/1846Afinal.asp
 Курс 2710

• Analyzing Requirements and Defining

Microsoft .NET Solution Architectures
• 5 дней, компьютеры используются
• Подробно изучается фаза планирования
для проектов разработки ПО (application
development)
• http://www.microsoft.com/traincert/syllabi/2710bfinal.asp
 Экзамен 74-100
• Microsoft Solutions Framework Practitioner
Endorsement Exam
– 70 вопросов
– 90 минут
– Проходной балл – 70% (49 вопросов)
– Язык - английский
• Не является частью программы MCP
• Можно сдавать только через Prometric
– http://www.2test.com
• В СНГ стоимость экзамена - $50, в США - $125
• В мире сегодня – 266 MSF Practitioners
– В России – 4
– На Украине – 2
• http://www.microsoft.com/technet/itsolutions/tandp/innsol/banmsfpro/default.asp
 Заключение
• MSF представляет собой обобщение опыта
управления ИТ-проектами, накопленного в
Microsoft
• MSF состоит из двух моделей и трех
дисциплин, описание которых доступно на
русском языке на сайте
http://www.microsoft.com/rus/msf
• MSF – это набор рекомендаций, которые
можно применять выборочным образом
• Наиболее революционная часть MSF – это
модель команды равных