Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

Фаза Задачи Вехи Результат

Разработка (Developing)

Создание компонентов решения*

(включая код и документацию)

Разработка инфраструктуры

Анализ и оценивание решения всеми

заинтересованными лицами, выявле-

ние оставшихся проблем и неурегули-

рованных вопросов, которые должны

быть улажены до выпуска решения

*) Выполняется параллельная разра-

ботка компонентов решения. Проме-

жуточные сборки - это единая мера

общего прогресса, наличие которой

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

синхронизировать различные состав-

ляющие на уровне решения в целом

Промежуточные вехи:

Концепция подтвер-

ждена

Сборка n завершена

Сборка n+1 завершена

…

Главная веха:

Разработка завершена

• Исходный и исполнимый код приложений

• Скрипты установки и конфигурирования

• Окончательная функциональная спецификация

• Материалы поддержки решения

• Спецификации и сценарии тестов

Ключевые элементы решения проверены в моделируемой

среде (копии реально существующей среды)

Проведена верификация сформулированных требований

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

и группе сопровождения

Синхронизированная параллельная разработка компонен-

тов решения завершена

Стабилизация (Stabilizing)

Тестирование решения*

Приоритезация и устранение дефектов

Пилотное внедрение после стабилиза-

ции (в часть целевой среды)

*) Точка конвергенции – момент, когда

скорость устранения дефектов начи-

нает превосходить скорость их обна-

ружения (тестирование близится к

концу)

Точка достижения нуля – момент,

когда впервые все выявленные дефек-

ты оказываются устраненными (бли-

зится стабилизация версии, которая

будет зафиксирована как версия-

кандидат на выпуск)

Промежуточные вехи:

Точка конвергенции

Точка достижения ну-

ля

Версии-кандидаты1…n

Контрольное тестиро-

вание завершено

Тестирование прием-

лемости для пользова-

телей завершено

Пилотное внедрение

завершено

Главная веха:

Готовность решения

утверждена

• Окончательный продукт.

• Документация выпуска (релиза)

• Материалы поддержки решения

• Результаты и инструментарий тестирования.

• Исходный и исполнимый код приложений.

• Проектная документация

• Анализ пройденной фазы

Результаты тестирования оценены в соответствии с уста-

новленными критериями успешности

Среда внедрения подготовлена

Созданы нужные процедуры, скрипты и массивы данных

Готовы учебные материалы

Обеспечены условия для сопровождения решения

Создан и протестирован план “отката”

Фаза Задачи Вехи Результат

Внедрение (Deploying)

Внедрение технологии и ключевых

компонентов решения (если они не

были внедрены ранее)

Перенос решения в среду эксплуата-

ции (на все рабочие места) и его ста-

билизация

Передача работы персоналу поддерж-

ки и сопровождения

Получение со стороны заказчика

окончательного одобрения результа-

тов проекта

Анализ выполненной работы и удов-

летворенности заказчика тем, что его

цели достигнуты (по завершению

внедрения)

Передача функций эксплуатации и

сопровождения постоянному персо-

налу

Сворачивание проекта

*) Ключевые компоненты - компонен-

ты инфраструктуры (контроллеры

доменов, маршрутизаторы, почтовые

серверы, удаленные серверы доступа,

серверы баз данных и др.)

Промежуточные вехи:

Ключевые элементы

развернуты

Внедрение на местах

завершено

Внедрение решения

стабилизировано

«Период затишья»

Главная веха:

Внедрение завершено

• Информационные системы эксплуатации и поддержки

• Процедуры и процессы

• Базы знаний, отчеты, журналы протоколов.

• Версии проектных документов, массивы данных и про-

граммный код, разработанные во время проекта

• Отчет о завершении проекта

• Окончательные версии всех проектных документов

• Показатели удовлетворенности заказчика и потреби-

телей

• Описание последующих шагов

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

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

ционных характеристик решения и др.)

526 Глава 11

Последовательность фаз в витке является логической в смысле зависимости

последующих фаз от предыдущих. Это не означает, что фазы выполняются во вре-

мени строго одна за другой и следующая фаза может начаться только по окончании

предыдущей. Фазы могут выполняться параллельно и быть частично или полно-

стью совмещенными по времени. Фазы проекта носят итеративный характер. По

достижении очередной вехи полученные материалы немедленно подвергаются

проверке и оценке, результаты вызывают очередную итерацию уже проделанных

работ, что не мешает начинать и продолжать работу в остальной части проекта.

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

проектных требований. Она исходит из того, что разработка проектного решения

должна состоять из коротких циклов, обеспечивая поступательное движение от

простейших версий решения к его окончательному виду.

11.6.2. Модель проектной группы MSF

Модель проектной группы MSF представлена в документе Модель проектной

группы MSF, версия 3.1. Эта модель отражает подход Microsoft к организации труда

исполнителей, обеспечивающий успешное выполнение проекта. В модели опреде-

ляются роли исполнителей, функции, области ответственности и принципы управ-

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

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

Модель проектной группы в MSF – это результат осмысления недостатков

пирамидальной, иерархической структуры традиционных проектных групп. Она

основывается на утверждении о равноправии ролей в команде, где каждый ролевой

кластер (группа специалистов с одинаковой ролью) представляет уникальную точ-

ку зрения на проект. Такая модель проектной группы MSF гарантирует присутствие

всех командных ролей и их участие в процессах принятия решений от начала и до

завершения проекта, что обеспечивает учетом полного спектра точек зрений при

рассмотрении вопросов. Единый принцип для всех ролей в команде – нацеленность

каждого на общий результат – создание качественного конечного продукта, единая

начальная установка – отсутствие в нем дефектов, единое средство достижения це-

ли – накопление опыта и обмен знаниями.

Каждый ролевой кластер имеет иерархическую структуру, что обеспечивает

управление трудовыми ресурсами одной специализации. Руководители ролевых

кластеров ответственны за организацию работы, координацию действий команды, в

то время как ее члены имеют возможность сосредоточиться на своих индивидуаль-

ных задачах.

В MSF выделено шесть ролевых кластеров модели проектной группы:

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

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

Разработка,

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

Удовлетворение потребителя,

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

Цели деятельности, области компетенции и функции специалистов по ролям

указаны в таблице 11.4, а в таблице 11.5 вкратце охарактеризованы ролевые функ-

ции специалистов в разрезе фаз проекта. В небольших проектах допускается со-

вмещение нескольких ролей одним исполнителем (таблица 11.6).

Глава 11 527

Таблица 11.4. Ролевые кластеры в MSF

Роль Цель Компетенция Функции

Управление про-

дуктом

Удовлетво-

ренные за-

казчики

Маркетинг

Бизнес-отдача

(бизнес-

приоритеты)

Представление

интересов за-

казчика

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

продукта

Выступает в роли представителя заказчика

Формирует общее видение/рамки проекта

Организует работу с требованиями заказчика

Развивает сферы применения в бизнесе

Формирует ожидания заказчика

Определяет компромиссы (по треугольнику)

Организует маркетинг и PR

Разрабатывает, поддерживает и исполняет план

коммуникаций

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

мой

Достиже-

ние резуль-

тата в рам-

ках проект-

ных огра-

ничений

Управление

проектом

Выработка ар-

хитектуры ре-

шения

Контроль про-

изводственного

процесса

Администра-

тивные службы

Управляет процессом разработки

Создает спецификацию и архитектуру

Регулирует взаимоотношения и коммуникацию

внутри проектной группы

Следит за временным графиком проекта и го-

товит отчетность о его состоянии

Проводит в жизнь компромиссные решения

Разрабатывает, поддерживает и исполняет

сводный план и календарный график проекта

Организует управление рисками

Разработка

Создание

продукта в

соответст-

вии со спе-

цификаци-

ей

Технологиче-

ское консульти-

рование

Проектирова-

ние, разработка

приложений и

инфраструкту-

ры

Определяет детали физического дизайна

Оценивает необходимые время и ресурсы на

реализацию каждого элемента дизайна

Разрабатывает или контролирует разработку

элементов

Подготавливает продукт к внедрению

Консультирует команду по технологическим

вопросам

Тести-

рова-

ние

Дефекты

выявлены и

улажены

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

разработка тес-

тов.

Отчетность

Обеспечивает обнаружение всех дефектов

Разрабатывает стратегию и планы тестирова-

ния

Осуществляет тестирование

Удовлетворение

потребителя

Повышение

эффектив-

ности, уве-

личение

потреби-

тельской

ценности

продукта

Техническая

поддержка

Обучение

Эргономика

Графический

дизайн

Интернациона-

лизация

Представляет интересы потребителя в команде

Организует работу с требованиями

Проектирует и разрабатывает системы под-

держки производительности

Определяет компромиссы по качеству

Определяет требования к системе помощи

Разрабатывает учебные материалы и осуществ-

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

Управление вы-

пуском

Беспро-

блемное

внедрение и

сопровож-

дение про-

дукта

Инфраструкту-

ра

Сопровождение

Бизнес-

процессы

Управление

выпуском гото-

вого продукта

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

обслуживания продукта

Организует снабжение проектной группы

Организует внедрение продукта

Вырабатывает компромиссы в управляемости и

удобстве сопровождения продукта

Организует сопровождение и инфраструктуру

поставки

Таблица 11.5. Роли специалистов в разрезе фаз проекта

Роли Фаза выработки

концепции

Фаза

планирования

Фаза

разработки

Фаза

стабилизации

Фаза

внедрения

Управление

продуктом

Определение общих

целей проекта; выявле-

ние нужд и требований

заказчика; подготовка

документа общего опи-

сания и рамок проекта

Мониторинг концеп-

туального проекта;

анализ деловых требо-

ваний; разработка

коммуникационного

плана

Мониторинг ожи-

даний заказчика

Исполнение коммуни-

кационного плана;

планирование пре-

мьерного показа про-

дукта

Получение отзывов и

оценок заказчика; со-

ставление акта о прие-

ме выполненной рабо-

ты.

Управление про-

граммой

Мониторинг целей от-

носительно дизайна,

концепции решения,

структуры проекта

Мониторинг концеп-

туального и логиче-

ского проекта; функ-

циональной специфи-

кации; сводного плана

и сводного календар-

ного графика проекта;

бюджета

Управление

функциональной

спецификацией;

мониторинг про-

екта; доработка

планов

Мониторинг проекта;

приоритезация дефек-

тов

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

проекта с поставлен-

ным решением; управ-

ление стабилизацией

Разработ-

ка

Прототипирование;

анализ технологиче-

ских возможностей;

анализ осуществимости

Оценка технологий;

логическое и физиче-

ское проектирование;

планирование, состав-

ление графика и сметы

Разработка про-

граммного кода и

инфраструктуры;

документирование

конфигураций.

Устранение дефектов;

оптимизация про-

граммного кода.

Разрешение проблем;

поддержка эскалации

Удовлетворение по-

требителя

Необходимые эксплуа-

тационные характери-

стики решения и их

влияние на его разра-

ботку.

Разработка сценариев

использования, поль-

зовательских требова-

ний, требований лока-

лизации; пользова-

тельской документа-

ции/плана обучения/

графика тестирования

удобства эксплуата-

ции; обучение

Обучение; дора-

ботка плана обу-

чения; тестирова-

ние удобства экс-

плуатации; гра-

фический дизайн.

Доработка эксплуата-

ционных руководств;

учебных материалов

Обучение; управление

календарным графиком

обучения

Роли Фаза выработки

концепции

Фаза

планирования

Фаза

разработки

Фаза

стабилизации

Фаза

внедрения

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

Стратегии тестирова-

ния; критерии приемле-

мости, их влияние на

разработку решения

Оценка дизайна; раз-

работка требований к

тестированию; плана

и календарного гра-

фика тестирования

Функциональное

тестирование; вы-

явление проблем;

тестирование до-

кументации; до-

работка плана

тестирования

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

щение об ошибках и

их статусе; тестирова-

ние конфигурации

Тестирование произво-

дительности

Управление

выпуском

Требования внедрения и

их влияние на разработ-

ку решения; требования

сопровождения

Оценка дизайна; оп-

ределение эксплуата-

ционных требований;

плана и календарного

графика пилотного и

окончательного вне-

дрения

Разработка кон-

трольных вопрос-

ников для развер-

тывания; дора-

ботка планов вне-

дрения (включая

пилотное)

Развертывание и под-

держка пилотного

внедрения; планиро-

вание внедрения; обу-

чение персонала со-

провождения

Управление внедрени-

ем; одобрение измене-

ний

Таблица 11.6. Варианты совмещения ролей специалистами

Управление

продуктом

Управление

программной

Разра-

ботка

Тестиро-

вание

Удовлетворение

потребителя

Управление

выпуском

Управление про-

дуктом

- - + + ~

Обозначения:

Управление про-

граммной

- ~ ~ +

+ допустимо

Разработка

- -

- - -

~ не желательно

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

+ ~ -

+ +

Удовлетворение

потребителя

+ ~ - +

- нельзя

Управление вы-

пуском

~ + - + ~

530 Глава 11

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

Управление рисками – это одна из основных дисциплин в MSF. В ее основе

лежит подход, предложенный SEI (глава 10). Принципы управления рисками в MSF

изложены в документе Дисциплина управления рисками MSF, версия 1.1. C самого

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

вносит дополнительную неопределенность. MSF предлагает упреждающий подход

к управлению рисками, их постоянную оценку и учет при принятии решений. До-

кумент содержит рекомендации по выполнению 6-шагового процесса управления

рисками, который включает выявление и анализ рисков; планирование и реализа-

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

живание состояния рисков и извлечение уроков из приобретенного опыта.

11.6.4. Дисциплина управления проектами

Дисциплина управления проектами в MSF описана в документе Дисциплина

управления проектами MSF, версия 1.1

. В

MSF предполагается распределение ра-

боты по управлению проектами между членами команды.

Особенность MSF - отсутствие должности менеджера проекта. Организато-

ром работы команды является ролевой кластер «Управление программой». Типо-

вые управленческие обязанности распределяются среди лидеров всех ролевых кла-

стеров. Это повышает ответственность сотрудников и позволяет применить мето-

дологию MSF к широкому спектру различных по масштабам и сложности проектов.

При таком подходе профессиональные менеджеры выступают в качестве консуль-

тантов и наставников команды, а не выполняют функции контроля над ней.

MSF выделяет несколько областей ответственности, навыков и деятельности

по управлению проектами (таблица 11.7).

Таблица 11.7. Области ответственности по управлению проектами в MSF

Область управле-

ния проектом

Описание

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

екта и контроль за

изменениями

Интеграция и синхронизация планов проекта; организация проце-

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

Управление рам-

ками проекта

Определение и распределение объема работы (рамок проекта);

управление компромиссными решениями в проекте

Управление кален-

дарным графиком

проекта

Составление и ведение календарного графика исходя из оценок

трудозатрат, упорядочивание задач и их соотнесение с доступны-

ми ресурсами

Управление стои-

мостью

Оценки стоимости исходя из оценок затрат времени; отчетность о

ходе проекта; анализ хода проекта и затратных рисков; функцио-

нально-стоимостной анализ

Управление персо-

налом

Планирование ресурсов; формирование проектной команды; раз-

решение конфликтов; планирование и управление подготовкой

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

муникацией

Коммуникационное планирование (между проектной группой,

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

ми); отчетность о ходе проекта

Управление рис-

ками

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

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

Глава 11 531

Область управле-

ния проектом

Описание

Управление снаб-

жением

Анализ цен поставщиков услуг и/или аппаратного/программного

обеспечения; подготовка тендерных документов, выбор постав-

щиков и субподрядчиков; составление контрактов, ведение пере-

говоров и заключение договоров на поставку

Управление каче-

ством

Планирование качества, определение применяемых стандартов,

документирование критериев качества и процессов его измерения

В документе описаны основные принципы и избранные методики по каждой

из перечисленных в таблице областей управление проектами MSF во взаимосвязи с

моделью проектной группы MSF.

11.6.5. Дисциплина управления профессиональной подготовкой

Эта дисциплина посвящена управлению знаниями и профессиональными на-

выками, необходимыми для планирования, создания и сопровождения успешных

решений. Дисциплина описана в документе Дисциплина управления подготовкой

MSF, версия 1.1.

Степень подготовленности сотрудников для выполнения своей профессио-

нальной роли в проекте определяется как отношение имеющегося у них уровня

знаний, умений и способностей к желаемому их уровню (коэффициент KSA, от

knowledge, skills and abilities). Эта мера показывает видимый (реально наблюдае-

мый) профессиональный потенциал специалистов в любой момент работы над соз-

данием решения.

Подготовленность организации рассматривается как оценка общей подготов-

ленности всех составляющих и используется при стратегическом планировании и

анализе возможностей эффективного внедрения технологических инноваций. Од-

нако, такие аспекты подготовленности организации, как совершенствование про-

цессов и управление организационными изменениями в данной дисциплине MSF не

рассматриваются.

Ключевые концепции управления подготовкой таковы:

• Учет имеющегося багажа знаний и его оценка. Управление знаниями.

• Стремление к самосовершенствованию.

• Перманентное управление подготовкой. Превращение работы над повы-

шением квалификации в явную, планируемую деятельность.

Документ дает рекомендации по применению превентивного подхода к

управлению знаниями на протяжении всего жизненного цикла решения, сравнивая

его с реактивным подходом (таблица 11.8).

Таблица 11.8. Сравнение превентивного и реактивного подходов к подготовке

Превентивный подход Реактивный подход

Позитивное отношение к планиро-

ванию подготовки

Реакция на проявившуюся нехватку знаний, уме-

ний, способностей

Использование структурированно-

го процесса подготовки

Использование ситуационных процессов или всякое

их отсутствие

Прогнозирование и планирование

нужд подготовки

Проведение обучения (исправление несоответствий)

после проявления изъянов в подготовке

Разработка и использование систе-

мы управления знаниями

Неосведомленность о существующем потенциале

знаний