Модель процессов Microsoft Solutions Framework
Модель процессов MSF представляет собой общую методологию разработки и внедрения IT-решений. Благодаря своей гибкости данная модель может использоваться для разработки широкого круга IT-решений, она охватывает весь жизненный цикл создания решения, с самых ранних этапов до внедрения. Модель процессов MSF сочетает в себе качества двух классических моделей: каскадной и спиральной.
Процесс MSF ориентирован на "вехи" (milestones). Вехи – ключевые точки процесса разработки, которые характеризуют достижение какого–либо существенного результата.
Модель процессов MSF учитывает постоянные изменения требований к конечному продукту, процесс разработки состоит из коротких циклов и представляет собой поступательное движение от простейших ранних версий продукта к его окончательному виду.
Каскадная и спиральная модели процессов
Модель процессов описывает последовательность действий при реализации проекта, по сути, модель процессов определяет жизненный цикл проекта.
В настоящее время существует множество различных моделей. Рассмотрим подробнее каскадную и спиральную модели, положения которых легли в основу модели процессов MSF.
Каскадная модель (waterfall)
(рис 5.1)
Как правило, данная модель применяется в случаях, когда требования к конечному продукту определены на ранних этапах и остаются неизменными, на протяжении всего процесса разработки. Каждый этап разработки заканчивается "вехой" - точкой оценки и перехода к следующему этапу. Каждый следующий этап может начаться только после завершения предыдущего. Фиксированные точки перехода между этапами облегчают распределение ответственности, создание отчетности и следование календарному графику.
На рисунке: Ромбы соответствуют вехам, стрелки – фазам.
Спиральная модель.
(рис 5.2)
Данная модель предпочтительна для быстрой разработки небольших решений. В ней учитываются постоянные изменения и пересмотр проектных требований к конечному продукту. Имеет место постоянное и тесное взаимодействие разработчиков с заказчиком, который оценивает ход и результаты работы на протяжении всего процесса работы над проектом. К недостаткам спиральной модели можно отнести низкую степень формализации, порой тяжело понять на какой конкретной стадии (планирование, разработка т пр.) находится проект.
Модель процессов MSF
Модель процессов MSF объединяет в себе упорядоченность каскадной модели с гибкостью спиральной.
(рис 5.3)
Базовые принципы:
Единое видение проекта. Изначально и у заказчика и у проектной группы имеется свое понимание целей и задач проекта, а также того, что должно быть достигнуто в ходе работы над проектом. Успех проекта невозможен без наличия единого видения и понимания проекта у заказчика и проектной группы, поскольку отсутствие ясности делает невозможным цели.Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки – "Выработка концепции".
Проявляйте гибкость – будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.
Концентрируйтесь на бизнес - приоритетах. Разрабатываемый продукт должен приносить определенную выгоду или отдачу конечным пользователям. В случае организаций – бизнес – отдачу.Поскольку программный продукт способен привнести отдачу только после своего внедрения в среду организации, MSF включает в жизненный цикл создания решения фазу внедрения.
Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.
Модель процессов MSF предлагает свободный и открытый обмен информацией между всеми участниками проекта, как внутри команды разработчиков, так и с ключевыми заинтересованными лицами. Это должно служить средством снижения недопонимания, неопределенности и необоснованных затрат.
Поэтому, MSF предлагает проводить анализ хода работ в определенных временных точках. Обязательное документирование результатов иллюстрирует прогресс работы над проектом, как для разработчиков, так и для заказчика.
Фазы модели процессов MSF
MSF версии 3.0 интегрирует в себе две ранние модели процессов: модель разработки приложений (application development - AD) и модель внедрения инфраструктуры (infrastructure deployment - ID). Новая единая модель покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Таким образом, использовавшаяся ранее четырехфазная схема расширена до пяти фаз. Каждая фаза заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.
(рис 5.4)
Фаза выработки концепции
На фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.
Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок (Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение; Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений).
Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта.
Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".
Фаза планирования
На фазе планирования (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.
В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории: бизнес-требования (business requirements), потребительские требования (user requirements), эксплуатационные требования (operational requirements) и системные требования, относящиеся к решению в целом (system requirements). В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием (traceability) между имеющимися требованиями и проектируемой функциональностью. Это соответствие не обязательно будет взаимооднозначным. Оно служит одним из способов контроля корректности дизайна и его пригодности для достижения поставленных перед решением целей.
Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей (user profiles, иногда называемых "персонажами" - "personas"), которые описывают различные типы пользователей (включая персонал сопровождения) и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя (например, регистрация посетителей в отеле или администрирование паролей пользователей в компьютерной системе). В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции. Этот процесс анализа действий пользователей называется стори-боардинг
("story boarding").
Существует три уровня процесса проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.
Результаты процесса проектирования документируются в функциональных спецификациях (functional specifications). Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.
Функциональная спецификация служит многим целям:
Инструкции команде разработчиков о том, что они должны будут создать.
Основа для оценивания объема работы.
Четкое соглашение с заказчиком о том, что должно быть сделано.
Синхронизация работы всей проектной команды.
Как только создана базовая версия функциональной спецификации, может быть начато детальное планирование. Каждый из руководителей ролевых кластеров проектной группы подготавливает план или планы, относящиеся к его роли, и принимает участие в командных сессиях планирования. Примеры планов включают в себя план внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения.
Затем проектная группа коллективно анализирует планы и выявляет взаимозависимости между ними. Все планы синхронизируются и представляются вместе в виде сводного плана проекта. В зависимости от проекта, число планов, образующих сводный план, может меняться.
Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).
Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между заказчиком и проектной группой о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.
Фаза разработки
На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Однако некоторая часть этой работы может продолжаться также на фазе стабилизации, если такая необходимость выявлена в процессе тестирования. Данная фаза также включает в себя разработку инфраструктуры.
Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.
Фаза стабилизации
Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence) и точка достижения нуля ошибок (zero bug bounce). Они описываются ниже.
MSF не использует для описания состояния проекта термины "альфа" и "бета". Хотя эти понятия применяются довольно часто, их интерпретация далеко не однозначна. При желании проектная группа может их использовать, но при этом они должны быть четко определены и понятны как членам проектной группы, так и заказчику и другим заинтересованным сторонам.
Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.
Фаза стабилизации завершается вехой "Готовность решения утверждена" (Release Readiness Approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.
Фаза внедрения
Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения.
Модель команды Microsoft Solutions Framework
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
Шесть ролевых кластеров модели проектной группы – это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.
Модель проектной группы MSF подчеркивает важность построения ролевых кластеров в соответствии с нуждами бизнеса. Группировка связанных областей компетенции, каждая из которых имеет свою специфику, обеспечивает хорошую сбалансированность команды. Четкое определение целей повышает уровень ответственности и способствует лучшему их восприятию проектной командой, что незамедлительно сказывается наилучшим образом на качестве выпускаемого продукта. Поскольку каждая из целей одинаково необходима для успешности проекта, все роли находятся в равноправных партнерских взаимоотношениях с равной значимостью при принятии решений.
Заметим, что использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Области компетенции и функции ролевых кластеров MSF
|
Цель |
Область компетенции |
Функции |
|---|
| Управление продуктом |
Удовлетворенные заказчики |
Маркетинг
Бизнес-отдача (бизнес-приоритеты)
Представление интересов заказчика
Планирование продукта
|
Выступает в роли представителя заказчика
Формирует общее видение/рамки проекта
Организует работу с требованиями заказчика
Развивает сферы применения в бизнесе
Формирует ожидания заказчика
Определяет компромиссы между параметрами "возможности продукта / время / ресурсы"
Организует маркетинг, PR и евангелизацию
Разрабатывает, поддерживает и исполняет план коммуникаций
|
| Управление программой |
Достижение результата в рамках проектных ограничений |
Управление проектом
Выработка архитектуры решения
Контроль производственного процесса
Административные службы
|
Управляет процессом разработки с целью получения готового продукта в отведенные сроки
Формулирует спецификацию продукта и разрабатывает его архитектуру
Регулирует взаимоотношения и коммуникацию внутри проектной группы
Следит за временным графиком проекта и готовит отчетность о его состоянии
Проводит в жизнь важные компромиссные решения
Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта
Организует управление рисками
|
| Разработка |
Создание продукта в соответствии со спецификацией |
Технологическое консультирование
Проектирование и осуществление реализации
Разработка приложений
Разработка инфраструктуры
|
Определяет детали физического дизайна
Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна
Разрабатывает или контролирует разработку элементов
Подготавливает продукт к внедрению
Консультирует команду по технологическим вопросам
|
| Тестирование |
Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены |
Планирование тестов
Разработка тестов
Отчетность по тестам
|
Обеспечивает обнаружение всех дефектов
Разрабатывает стратегию и планы тестирования
Осуществляет тестирование
|
| Удовлетворение потребителя |
Повышение эффективности пользователя, увеличение потребительской ценности продукта |
Обеспечение технической поддержки
Обучение
Эргономика
Графический дизайн
Интернационализация
Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)
|
Представляет интересы потребителя в команде
Организует работу с требованиями пользователя
Проектирует и разрабатывает системы поддержки производительности
Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта
Определяет требования к системе помощи и ее содержание
Разрабатывает учебные материалы и осуществляет обучение пользователей
|
| Управление выпуском |
Беспроблемное внедрение и сопровождение продукта |
Инфраструктура
Сопровождение
Бизнес-процессы
Управление выпуском готового продукта
|
Представляет интересы отделов поставки и обслуживания продукта
Организует снабжение проектной группы
Организует внедрение продукта
Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта
Организует сопровождение и инфраструктуру поставки
Организует логистическое обеспечение проектной группы
|
Ролевые кластеры модели проектной группы
(рис 5.5)
Ролевой кластер "Управление продуктом"
Ключевая цель ролевого кластера "Управление продуктом" (product management) – довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика. Однако, прежде всего, заказчик должен быть идентифицирован и понят! В некоторых случаях заказчиком может являться не та сторона, которая спонсирует проект (т.е. поддерживает затраченные на него усилия и покрывает расходы). Следовательно, должно быть сделано четкое различие между этими сторонами и произведен анализ требований каждой из них в целях успешного взаимодействия с ними обеими. Лишь после этого может быть сформулирован набор требований и ожиданий, которым должны следовать соответствующие проектные роли. Возможна ситуация, когда проектная группа уложилась в бюджет и сроки, но успех все же не достигнут, так как не удовлетворены бизнес-нужды заказчика.
Модель проектной группы MSF разделяет области компетенции каждого ролевого кластера, чтобы четче определить набор входящих в них зон ответственности, образующих в совокупности общий потенциал команды.
Для достижения своей цели ролевой кластер "Управление продуктом" должен содержать в себе следующие области компетенции: планирование продукта (product planning), бизнес-отдача (business value), представление интересов заказчика (customer advocacy) и маркетинг (marketing).
Области компетенции
Маркетинг
Проведение маркетинговых и PR акций, нацеленных на (потенциальных) клиентов.
Демонстрация своих конкурентных преимуществ.
Обеспечение попадания продукта в соответствующие каналы дистрибуции, гарантирующие его максимальную доступность для потребителя.
Консультирование потребителя для создания у него позитивного впечатления от покупки и использования продукта.
Бизнес-отдача
Определение и контроль обусловленности работы над проектом с точки зрения бизнеса.
Контроль (в т.ч. количественный) получения заказчиком бизнес-отдачи от проекта.
Представление интересов заказчика
Выработка общего видения проекта и решения.
Обмен информацией с заказчиком и формирование его ожиданий.
Планирование продукта
Сбор, анализ и приоритезация требований заказчика и бизнеса.
Проведение исследования рынка и имеющегося спроса; анализ и изучение конкурентов.
Определение критериев бизнес-успешности проекта.
Разработка плана выпуска серии версий продукта.
Ролевой кластер "Управление программой"
Основная задача этого ролевого кластера – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований спонсора проекта к его результату. Для этого "Управление программой" контролирует календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта. Ниже описываются области компетенции ролевого кластера "Управление программой".
Управление проектом
Мониторинг и управление бюджетом.
Составление сводного плана и сводного календарного графика проекта.
Организация управления рисками.
Содействие обмену информацией и достижению договоренностей внутри проектной группы.
Мониторинг прогресса и отчетность о состоянии проекта.
Управление выделением ресурсов.
Выработка архитектуры решения
Организация высокоуровневого проектирования решения.
Управление функциональной спецификацией.
Определение рамок проекта и ключевых компромиссных решений.
Контроль производственного процесса
Организация контроля производственного процесса.
Выработка рекомендаций по его совершенствованию.
Административные службы
Организация процессов управления проектом и помощь лидерам команд (team leads) в их использовании.
Организация ряда административных служб, необходимых для поддержки эффективной работы команды.
Ролевой кластер "Разработка"
Первостепенной задачей ролевого кластера "Разработка" является построение решения в соответствии со спецификацией. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер "Разработка" создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.
В качестве создателей решения разработчики осуществляют низкоуровневое проектирование решения и его элементов, оценивают трудозатраты на реализацию и затем осуществляют построение самого решения. Разработчики сами оценивают собственные затраты и отслеживают расписание, поскольку их повседневная деятельность сопряжена с различными нештатными ситуациями. Эта концепция называется оцениванием снизу вверх (bottom-up estimation) и является фундаментальной частью философии MSF. Цель данной концепции состоит в достижении большей обоснованности календарного плана и увеличении чувства ответственности тех, кто определяет сроки этого плана, и от чьей производительности зависит его выполнение.
Технологическое консультирование
Выполнение функций технологических консультантов.
Оценивание и верификация технологий.
Активное участие в создании и обсуждении функциональной спецификации.
Вклад в создание корпоративных стандартов разработки программного обеспечения.
Проектирование и осуществление реализации
Соотнесение архитектуры решения с архитектурой предприятия.
Создание и реализация логического и физического дизайна решения.
Разработка приложений
Программирование составляющих решения в соответствии с проектной документацией.
Анализ и обсуждение программного кода (code reviews) с целью обмена знаниями и опытом.
Осуществление тестирования модулей (unit testing) в соответствии с планом и в координации с ролевым кластером "Тестирование".
Разработка инфраструктуры
Создание составляющих решения в соответствии с проектной документацией.
Анализ и обсуждение программного кода с целью обмена знаниями и опытом.
Осуществление тестирования модулей в соответствии с планом и в координации с ролевым кластером "Тестирование".
Разработка скриптов автоматизации.
Создание внедренческой документации.
Ролевой кластер "Тестирование"
Задача ролевого кластера "Тестирование" (test) – одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить (address) все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом – как для проектной команды, так и для заказчика.
Чтобы достичь успеха, команда тестировщиков должна фокусироваться на определенных ключевых задачах. Они структурируются в виде трех областей компетенции.
Планирование тестов
Разработка методологии и плана тестирования.
Участие в установлении стандарта качества (quality bar).
Разработка спецификаций тестов.
Разработка тестов
Разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов.
Проведение тестов с целью определения состояния проекта.
Управление билдами (manage the build process).
Отчетность о тестах
Доведение до сведения проектной группы информации о качестве продукта.
Мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.
Ролевой кластер "Удовлетворение потребителя"
Цель этого ролевого кластера (удовлетворение потребителя - user experience) – повышение эффективности использования продукта. Кластер состоит из шести областей компетенции: общедоступность (accessibility), интернационализация (internationalization), обеспечение технической поддержки (technical communications), обучение пользователей (training), удобство эксплуатации (usability) и графический дизайн (graphic design). В рамках каждой из своих областей компетенции ролевой кластер "Удовлетворение потребителя" имеет несколько зон ответственности, необходимых для потребительского успеха решения. Ниже следует их перечисление.
Общедоступность
Учет требований общедоступности (доступности для людей с недостатками зрения, слуха и т.п.) в дизайне решения.
Интернационализация
Улучшение качества и удобства эксплуатации решения в иноязычных средах.
Обеспечение технической поддержки
Проектирование и разработка документации для служб поддержки (настольные руководства сотрудников служб поддержки, базы знаний и т.д.)
Наполнение системы помощи.
Обучение пользователей
Выработка и реализация стратегии обучения пользователей.
Удобство эксплуатации (эргономика)
Сбор, анализ и приоритезация требований пользователей (user requirements).
Анализ и обсуждение дизайна продукта.
Разработка сценариев и примеров использования (usage scenarios and use cases).
Представление интересов потребителя в проектной группе.
Графический дизайн
Дизайн пользовательского интерфейса.
Ролевой кластер "Управление выпуском".
Цель этого ролевого кластера – беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения. Данный ролевой кластер включает в себя следующие области компетенции:
Инфраструктура (infrastructure)
Сопровождение (support)
Бизнес-процессы (operations)
Управление выпуском готового продукта (commercial release management).
"Управление выпуском":
выполняет посреднические функции между группами разработки и сопровождения;
выбирает инструментарий внедрения и способствует его автоматизации и оптимизации;
устанавливает операционные критерии готовности продукта к выпуску;
участвует в разработке дизайна, отвечая за управляемость (manageability), удобство сопровождения (supportability) и удобство внедрения (deployability) конечного продукта;
организует обучение персонала сопровождения;
подготавливает и создает систему сопровождения опытного внедрения (pilot deployment);
планирует и обеспечивает поточный выпуск продукта (deployment into production);
контролирует соответствие результатов стабилизации продукта критериям приемлемости.
Инфраструктура
Планирование инфраструктуры предприятия.
Координация использования помещений и кросс-географическое планирование (центры данных, лаборатории, филиалы и периферийные офисы).
Разработка правил и инструкций для согласованного управления инфраструктурой.
Обеспечение инфраструктурного обслуживания проектной группы (серверы, стандартные образы дисков для рабочих станций, установка программного обеспечения).
Организация снабжения проектной группы аппаратным и программным обеспечением.
Создание тестовых и испытательных сред (test and staging environments), воспроизводящих рабочую среду (production environment).
Сопровождение
Обеспечение связи и обслуживания заказчиков и потребителей.
Управление соглашениями об уровне услуг (SLA – service level agreement) и обеспечение их надлежащего исполнения.
Организация оперативного разрешения пользовательских проблем и нештатных ситуаций.
Предоставление команде разработчиков обратной связи.
Разработка процедур действия в нештатных ситуациях.
Бизнес-процессы
Управление учетными записями.
Поддержка средств обмена сообщениями, баз данных, телекоммуникаций и сетей.
Системное администрирование.
Управление брандмауэром (firewall); администрирование системы безопасности.
Обслуживание приложений.
Интеграция серверов.
Поддержка служб каталогов.
Управление выпуском готового продукта
Регистрационные коды продукта; процесс верификации регистрации.
Управление лицензиями.
Подготовка дистрибутивных комплектов.
Управление каналами дистрибуции продукта.
Печатные и электронные публикации.
Модель процессов Microsoft Solutions Framework
Модель процессов MSF представляет собой общую методологию разработки и внедрения IT-решений. Благодаря своей гибкости данная модель может использоваться для разработки широкого круга IT-решений, она охватывает весь жизненный цикл создания решения, с самых ранних этапов до внедрения. Модель процессов MSF сочетает в себе качества двух классических моделей: каскадной и спиральной.
Процесс MSF ориентирован на "вехи" (milestones). Вехи – ключевые точки процесса разработки, которые характеризуют достижение какого–либо существенного результата.
Модель процессов MSF учитывает постоянные изменения требований к конечному продукту, процесс разработки состоит из коротких циклов и представляет собой поступательное движение от простейших ранних версий продукта к его окончательному виду.
Каскадная и спиральная модели процессов
Модель процессов описывает последовательность действий при реализации проекта, по сути, модель процессов определяет жизненный цикл проекта.
В настоящее время существует множество различных моделей. Рассмотрим подробнее каскадную и спиральную модели, положения которых легли в основу модели процессов MSF.
Каскадная модель (waterfall)
(рис 5.1)
Как правило, данная модель применяется в случаях, когда требования к конечному продукту определены на ранних этапах и остаются неизменными, на протяжении всего процесса разработки. Каждый этап разработки заканчивается "вехой" - точкой оценки и перехода к следующему этапу. Каждый следующий этап может начаться только после завершения предыдущего. Фиксированные точки перехода между этапами облегчают распределение ответственности, создание отчетности и следование календарному графику.
На рисунке: Ромбы соответствуют вехам, стрелки – фазам.
Спиральная модель.
(рис 5.2)
Данная модель предпочтительна для быстрой разработки небольших решений. В ней учитываются постоянные изменения и пересмотр проектных требований к конечному продукту. Имеет место постоянное и тесное взаимодействие разработчиков с заказчиком, который оценивает ход и результаты работы на протяжении всего процесса работы над проектом. К недостаткам спиральной модели можно отнести низкую степень формализации, порой тяжело понять на какой конкретной стадии (планирование, разработка т пр.) находится проект.
Модель процессов MSF
Модель процессов MSF объединяет в себе упорядоченность каскадной модели с гибкостью спиральной.
(рис 5.3)
Базовые принципы:
Единое видение проекта. Изначально и у заказчика и у проектной группы имеется свое понимание целей и задач проекта, а также того, что должно быть достигнуто в ходе работы над проектом. Успех проекта невозможен без наличия единого видения и понимания проекта у заказчика и проектной группы, поскольку отсутствие ясности делает невозможным цели.Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки – "Выработка концепции".
Проявляйте гибкость – будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.
Концентрируйтесь на бизнес - приоритетах. Разрабатываемый продукт должен приносить определенную выгоду или отдачу конечным пользователям. В случае организаций – бизнес – отдачу.Поскольку программный продукт способен привнести отдачу только после своего внедрения в среду организации, MSF включает в жизненный цикл создания решения фазу внедрения.
Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.
Модель процессов MSF предлагает свободный и открытый обмен информацией между всеми участниками проекта, как внутри команды разработчиков, так и с ключевыми заинтересованными лицами. Это должно служить средством снижения недопонимания, неопределенности и необоснованных затрат.
Поэтому, MSF предлагает проводить анализ хода работ в определенных временных точках. Обязательное документирование результатов иллюстрирует прогресс работы над проектом, как для разработчиков, так и для заказчика.
Фазы модели процессов MSF
MSF версии 3.0 интегрирует в себе две ранние модели процессов: модель разработки приложений (application development - AD) и модель внедрения инфраструктуры (infrastructure deployment - ID). Новая единая модель покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Таким образом, использовавшаяся ранее четырехфазная схема расширена до пяти фаз. Каждая фаза заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.
(рис 5.4)
Фаза выработки концепции
На фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.
Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок (Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение; Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений).
Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта.
Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".
Фаза планирования
На фазе планирования (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.
В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории: бизнес-требования (business requirements), потребительские требования (user requirements), эксплуатационные требования (operational requirements) и системные требования, относящиеся к решению в целом (system requirements). В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием (traceability) между имеющимися требованиями и проектируемой функциональностью. Это соответствие не обязательно будет взаимооднозначным. Оно служит одним из способов контроля корректности дизайна и его пригодности для достижения поставленных перед решением целей.
Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей (user profiles, иногда называемых "персонажами" - "personas"), которые описывают различные типы пользователей (включая персонал сопровождения) и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя (например, регистрация посетителей в отеле или администрирование паролей пользователей в компьютерной системе). В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции. Этот процесс анализа действий пользователей называется стори-боардинг
("story boarding").
Существует три уровня процесса проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.
Результаты процесса проектирования документируются в функциональных спецификациях (functional specifications). Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.
Функциональная спецификация служит многим целям:
Инструкции команде разработчиков о том, что они должны будут создать.
Основа для оценивания объема работы.
Четкое соглашение с заказчиком о том, что должно быть сделано.
Синхронизация работы всей проектной команды.
Как только создана базовая версия функциональной спецификации, может быть начато детальное планирование. Каждый из руководителей ролевых кластеров проектной группы подготавливает план или планы, относящиеся к его роли, и принимает участие в командных сессиях планирования. Примеры планов включают в себя план внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения.
Затем проектная группа коллективно анализирует планы и выявляет взаимозависимости между ними. Все планы синхронизируются и представляются вместе в виде сводного плана проекта. В зависимости от проекта, число планов, образующих сводный план, может меняться.
Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).
Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между заказчиком и проектной группой о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.
Фаза разработки
На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Однако некоторая часть этой работы может продолжаться также на фазе стабилизации, если такая необходимость выявлена в процессе тестирования. Данная фаза также включает в себя разработку инфраструктуры.
Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.
Фаза стабилизации
Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence) и точка достижения нуля ошибок (zero bug bounce). Они описываются ниже.
MSF не использует для описания состояния проекта термины "альфа" и "бета". Хотя эти понятия применяются довольно часто, их интерпретация далеко не однозначна. При желании проектная группа может их использовать, но при этом они должны быть четко определены и понятны как членам проектной группы, так и заказчику и другим заинтересованным сторонам.
Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.
Фаза стабилизации завершается вехой "Готовность решения утверждена" (Release Readiness Approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.
Фаза внедрения
Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения.
Модель команды Microsoft Solutions Framework
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
Шесть ролевых кластеров модели проектной группы – это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.
Модель проектной группы MSF подчеркивает важность построения ролевых кластеров в соответствии с нуждами бизнеса. Группировка связанных областей компетенции, каждая из которых имеет свою специфику, обеспечивает хорошую сбалансированность команды. Четкое определение целей повышает уровень ответственности и способствует лучшему их восприятию проектной командой, что незамедлительно сказывается наилучшим образом на качестве выпускаемого продукта. Поскольку каждая из целей одинаково необходима для успешности проекта, все роли находятся в равноправных партнерских взаимоотношениях с равной значимостью при принятии решений.
Заметим, что использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Области компетенции и функции ролевых кластеров MSF
|
Цель |
Область компетенции |
Функции |
|---|
| Управление продуктом |
Удовлетворенные заказчики |
Маркетинг
Бизнес-отдача (бизнес-приоритеты)
Представление интересов заказчика
Планирование продукта
|
Выступает в роли представителя заказчика
Формирует общее видение/рамки проекта
Организует работу с требованиями заказчика
Развивает сферы применения в бизнесе
Формирует ожидания заказчика
Определяет компромиссы между параметрами "возможности продукта / время / ресурсы"
Организует маркетинг, PR и евангелизацию
Разрабатывает, поддерживает и исполняет план коммуникаций
|
| Управление программой |
Достижение результата в рамках проектных ограничений |
Управление проектом
Выработка архитектуры решения
Контроль производственного процесса
Административные службы
|
Управляет процессом разработки с целью получения готового продукта в отведенные сроки
Формулирует спецификацию продукта и разрабатывает его архитектуру
Регулирует взаимоотношения и коммуникацию внутри проектной группы
Следит за временным графиком проекта и готовит отчетность о его состоянии
Проводит в жизнь важные компромиссные решения
Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта
Организует управление рисками
|
| Разработка |
Создание продукта в соответствии со спецификацией |
Технологическое консультирование
Проектирование и осуществление реализации
Разработка приложений
Разработка инфраструктуры
|
Определяет детали физического дизайна
Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна
Разрабатывает или контролирует разработку элементов
Подготавливает продукт к внедрению
Консультирует команду по технологическим вопросам
|
| Тестирование |
Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены |
Планирование тестов
Разработка тестов
Отчетность по тестам
|
Обеспечивает обнаружение всех дефектов
Разрабатывает стратегию и планы тестирования
Осуществляет тестирование
|
| Удовлетворение потребителя |
Повышение эффективности пользователя, увеличение потребительской ценности продукта |
Обеспечение технической поддержки
Обучение
Эргономика
Графический дизайн
Интернационализация
Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)
|
Представляет интересы потребителя в команде
Организует работу с требованиями пользователя
Проектирует и разрабатывает системы поддержки производительности
Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта
Определяет требования к системе помощи и ее содержание
Разрабатывает учебные материалы и осуществляет обучение пользователей
|
| Управление выпуском |
Беспроблемное внедрение и сопровождение продукта |
Инфраструктура
Сопровождение
Бизнес-процессы
Управление выпуском готового продукта
|
Представляет интересы отделов поставки и обслуживания продукта
Организует снабжение проектной группы
Организует внедрение продукта
Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта
Организует сопровождение и инфраструктуру поставки
Организует логистическое обеспечение проектной группы
|
Ролевые кластеры модели проектной группы
(рис 5.5)
Ролевой кластер "Управление продуктом"
Ключевая цель ролевого кластера "Управление продуктом" (product management) – довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика. Однако, прежде всего, заказчик должен быть идентифицирован и понят! В некоторых случаях заказчиком может являться не та сторона, которая спонсирует проект (т.е. поддерживает затраченные на него усилия и покрывает расходы). Следовательно, должно быть сделано четкое различие между этими сторонами и произведен анализ требований каждой из них в целях успешного взаимодействия с ними обеими. Лишь после этого может быть сформулирован набор требований и ожиданий, которым должны следовать соответствующие проектные роли. Возможна ситуация, когда проектная группа уложилась в бюджет и сроки, но успех все же не достигнут, так как не удовлетворены бизнес-нужды заказчика.
Модель проектной группы MSF разделяет области компетенции каждого ролевого кластера, чтобы четче определить набор входящих в них зон ответственности, образующих в совокупности общий потенциал команды.
Для достижения своей цели ролевой кластер "Управление продуктом" должен содержать в себе следующие области компетенции: планирование продукта (product planning), бизнес-отдача (business value), представление интересов заказчика (customer advocacy) и маркетинг (marketing).
Области компетенции
Маркетинг
Проведение маркетинговых и PR акций, нацеленных на (потенциальных) клиентов.
Демонстрация своих конкурентных преимуществ.
Обеспечение попадания продукта в соответствующие каналы дистрибуции, гарантирующие его максимальную доступность для потребителя.
Консультирование потребителя для создания у него позитивного впечатления от покупки и использования продукта.
Бизнес-отдача
Определение и контроль обусловленности работы над проектом с точки зрения бизнеса.
Контроль (в т.ч. количественный) получения заказчиком бизнес-отдачи от проекта.
Представление интересов заказчика
Выработка общего видения проекта и решения.
Обмен информацией с заказчиком и формирование его ожиданий.
Планирование продукта
Сбор, анализ и приоритезация требований заказчика и бизнеса.
Проведение исследования рынка и имеющегося спроса; анализ и изучение конкурентов.
Определение критериев бизнес-успешности проекта.
Разработка плана выпуска серии версий продукта.
Ролевой кластер "Управление программой"
Основная задача этого ролевого кластера – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований спонсора проекта к его результату. Для этого "Управление программой" контролирует календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта. Ниже описываются области компетенции ролевого кластера "Управление программой".
Управление проектом
Мониторинг и управление бюджетом.
Составление сводного плана и сводного календарного графика проекта.
Организация управления рисками.
Содействие обмену информацией и достижению договоренностей внутри проектной группы.
Мониторинг прогресса и отчетность о состоянии проекта.
Управление выделением ресурсов.
Выработка архитектуры решения
Организация высокоуровневого проектирования решения.
Управление функциональной спецификацией.
Определение рамок проекта и ключевых компромиссных решений.
Контроль производственного процесса
Организация контроля производственного процесса.
Выработка рекомендаций по его совершенствованию.
Административные службы
Организация процессов управления проектом и помощь лидерам команд (team leads) в их использовании.
Организация ряда административных служб, необходимых для поддержки эффективной работы команды.
Ролевой кластер "Разработка"
Первостепенной задачей ролевого кластера "Разработка" является построение решения в соответствии со спецификацией. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер "Разработка" создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.
В качестве создателей решения разработчики осуществляют низкоуровневое проектирование решения и его элементов, оценивают трудозатраты на реализацию и затем осуществляют построение самого решения. Разработчики сами оценивают собственные затраты и отслеживают расписание, поскольку их повседневная деятельность сопряжена с различными нештатными ситуациями. Эта концепция называется оцениванием снизу вверх (bottom-up estimation) и является фундаментальной частью философии MSF. Цель данной концепции состоит в достижении большей обоснованности календарного плана и увеличении чувства ответственности тех, кто определяет сроки этого плана, и от чьей производительности зависит его выполнение.
Технологическое консультирование
Выполнение функций технологических консультантов.
Оценивание и верификация технологий.
Активное участие в создании и обсуждении функциональной спецификации.
Вклад в создание корпоративных стандартов разработки программного обеспечения.
Проектирование и осуществление реализации
Соотнесение архитектуры решения с архитектурой предприятия.
Создание и реализация логического и физического дизайна решения.
Разработка приложений
Программирование составляющих решения в соответствии с проектной документацией.
Анализ и обсуждение программного кода (code reviews) с целью обмена знаниями и опытом.
Осуществление тестирования модулей (unit testing) в соответствии с планом и в координации с ролевым кластером "Тестирование".
Разработка инфраструктуры
Создание составляющих решения в соответствии с проектной документацией.
Анализ и обсуждение программного кода с целью обмена знаниями и опытом.
Осуществление тестирования модулей в соответствии с планом и в координации с ролевым кластером "Тестирование".
Разработка скриптов автоматизации.
Создание внедренческой документации.
Ролевой кластер "Тестирование"
Задача ролевого кластера "Тестирование" (test) – одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить (address) все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом – как для проектной команды, так и для заказчика.
Чтобы достичь успеха, команда тестировщиков должна фокусироваться на определенных ключевых задачах. Они структурируются в виде трех областей компетенции.
Планирование тестов
Разработка методологии и плана тестирования.
Участие в установлении стандарта качества (quality bar).
Разработка спецификаций тестов.
Разработка тестов
Разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов.
Проведение тестов с целью определения состояния проекта.
Управление билдами (manage the build process).
Отчетность о тестах
Доведение до сведения проектной группы информации о качестве продукта.
Мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.
Ролевой кластер "Удовлетворение потребителя"
Цель этого ролевого кластера (удовлетворение потребителя - user experience) – повышение эффективности использования продукта. Кластер состоит из шести областей компетенции: общедоступность (accessibility), интернационализация (internationalization), обеспечение технической поддержки (technical communications), обучение пользователей (training), удобство эксплуатации (usability) и графический дизайн (graphic design). В рамках каждой из своих областей компетенции ролевой кластер "Удовлетворение потребителя" имеет несколько зон ответственности, необходимых для потребительского успеха решения. Ниже следует их перечисление.
Общедоступность
Учет требований общедоступности (доступности для людей с недостатками зрения, слуха и т.п.) в дизайне решения.
Интернационализация
Улучшение качества и удобства эксплуатации решения в иноязычных средах.
Обеспечение технической поддержки
Проектирование и разработка документации для служб поддержки (настольные руководства сотрудников служб поддержки, базы знаний и т.д.)
Наполнение системы помощи.
Обучение пользователей
Выработка и реализация стратегии обучения пользователей.
Удобство эксплуатации (эргономика)
Сбор, анализ и приоритезация требований пользователей (user requirements).
Анализ и обсуждение дизайна продукта.
Разработка сценариев и примеров использования (usage scenarios and use cases).
Представление интересов потребителя в проектной группе.
Графический дизайн
Дизайн пользовательского интерфейса.
Ролевой кластер "Управление выпуском".
Цель этого ролевого кластера – беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения. Данный ролевой кластер включает в себя следующие области компетенции:
Инфраструктура (infrastructure)
Сопровождение (support)
Бизнес-процессы (operations)
Управление выпуском готового продукта (commercial release management).
"Управление выпуском":
выполняет посреднические функции между группами разработки и сопровождения;
выбирает инструментарий внедрения и способствует его автоматизации и оптимизации;
устанавливает операционные критерии готовности продукта к выпуску;
участвует в разработке дизайна, отвечая за управляемость (manageability), удобство сопровождения (supportability) и удобство внедрения (deployability) конечного продукта;
организует обучение персонала сопровождения;
подготавливает и создает систему сопровождения опытного внедрения (pilot deployment);
планирует и обеспечивает поточный выпуск продукта (deployment into production);
контролирует соответствие результатов стабилизации продукта критериям приемлемости.
Инфраструктура
Планирование инфраструктуры предприятия.
Координация использования помещений и кросс-географическое планирование (центры данных, лаборатории, филиалы и периферийные офисы).
Разработка правил и инструкций для согласованного управления инфраструктурой.
Обеспечение инфраструктурного обслуживания проектной группы (серверы, стандартные образы дисков для рабочих станций, установка программного обеспечения).
Организация снабжения проектной группы аппаратным и программным обеспечением.
Создание тестовых и испытательных сред (test and staging environments), воспроизводящих рабочую среду (production environment).
Сопровождение
Обеспечение связи и обслуживания заказчиков и потребителей.
Управление соглашениями об уровне услуг (SLA – service level agreement) и обеспечение их надлежащего исполнения.
Организация оперативного разрешения пользовательских проблем и нештатных ситуаций.
Предоставление команде разработчиков обратной связи.
Разработка процедур действия в нештатных ситуациях.
Бизнес-процессы
Управление учетными записями.
Поддержка средств обмена сообщениями, баз данных, телекоммуникаций и сетей.
Системное администрирование.
Управление брандмауэром (firewall); администрирование системы безопасности.
Обслуживание приложений.
Интеграция серверов.
Поддержка служб каталогов.
Управление выпуском готового продукта
Регистрационные коды продукта; процесс верификации регистрации.
Управление лицензиями.
Подготовка дистрибутивных комплектов.
Управление каналами дистрибуции продукта.
Печатные и электронные публикации.
