Липаев В.В. Программная инженерия

Л Е К Ц И Я 3

МОДЕЛИ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ ПРОГРАММНЫХ СРЕДСТВ

3.1.Управление проектами программных средств

всистеме — CMMI

Назначение методологии CMM/CMMI — системы и модели оцен­ ки зрелости — состоит в предоставлении необходимых общих рекомен­ даций и инструкций предприятиям, производящим ПС, по выбору страте­ гии совершенствования качества процессов и продуктов, путем анализа степени их производственной зрелости и оценивания факторов, в наиболь­ шей степени влияющих на качество ЖЦ ПС, а также посредством выделе­ ния процессов, требующих модернизации. Для достижения устойчивых результатов программной ин:нсенерии в процессе развития технологии и организации управления жизненным циклом ПС в стандарте ISO 15504:1-9 рекомендуется использовать эволюционный путь, который позволяет со­ вершенствовать и постепенно повышать качество процессов и продуктов, вскрывать преимущества и недостатки предприятия. В методологии СММ выделены пять уровней зрелости, раскрываемые в этом стандарте дефакто (рис. 3.1). Виды деятельности для высоких уровней зрелости в соот­ ветствии с СММ в стандарте делятся на базовые и общие. Базовые виды деятельности являются обязательными и сгруппированы в пять категорий: контрактная; инженерная; управленческая; вспомогательная; организаци­ онная. Уровни зрелости характеризуются степенью формализации, адек­ ватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств авто­ матизации работ, наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов.

60

3.1. Управление проектами программных средств в системе — CMMI

Уровень 5 — Оптимизационный — непрерывное улучшение:

управление изменением и качеством процессов и продукта; инновации, количественное управление процессами и обеспече­ нием ресурсами; совершенствование качества и управления процессами и продуктами;

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

Уровень 4 — Предсказуемый — количественное управление:

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

количественный контроль и управление рисками процессов, ресурсов и качества; контроль и управление поставкой продуктов

Уровень 3 — Определенный — стандартизация процессов:

определение стандартного процесса; интегрированное управление проектом; компонентами и продуктами; верификация, валидация, контроль качества процессов и продуктов; управление ресурсами, рисками и контроль их;

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

Уровень 2 — Управляемый — базовое управление:

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

Уровень 1 — Начальный:

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

Рис. 3.1

Описание процессов ЖЦ ПС в СММ сфокусировано на поэтапном определении реально достигаемых результатов и на оценивании качества

61

Лекция 3. Модели и процессы управления проектами программных средств

ИХ выполнения. Качество процессов зависит от технологической среды, в которой они выполняются. Зрелость процессов — это степень их управ­ ляемости, возможность поэтапной количественной оценки качества, конт­ ролируемости и эффективности результатов (см. рис. 3.1). Модель зрелос­ ти предприятия представляет собой методический нормативный материал, определяющий правила создания и функционирования системы управле­ ния жизненным циклом ПС, методы и стандарты систематического повы­ шения культуры и качества производства. Рост зрелости обеспечивает потенциальную возможность возрастания эффективности и согласованно­ сти использования процессов создания, сопровождения и оценивания ка­ чества компонентов и ПС в целом. Реальное использование регламентиро­ ванных процессов предполагает поэтапный контроль и документирование их характеристик качества. На предприятиях, достигших высокого уровня зрелости, формализованные процессы ЖЦ ПС должны принимать статус стандарта, фиксироваться в организационных структурах и определять производственную тактику и стратегию корпоративной культуры произ­ водства и системы обеспечения качества ПС.

Уровень 1 — Начальный. Массовые разработки проектов ПС харак­ теризуются относительно небольшими размерами программ в несколько тысяч строк, создаваемых несколькими специалистами. Они применяют простейшие неформализованные технологии с использованием типовых инструментальных компонентов операционных систем. Основные процес­ сы ЖЦ ПС на этом уровне не регламентированы, выполняются не совсем упорядоченно и зависят от некоординированных индивидуальных усилий и свойств отдельных специалистов. Успех проекта, как правило, зависит от энергичности, таланта и опыта нескольких руководителей и исполните­ лей. Процессы на первом уровне характеризуются своей непредсказуемос­ тью по трудоемкости и срокам в связи с тем, что их состав, назначение и последовательность выполнения могут меняться случайным образом в за­ висимости от текущей ситуации.

Уровень 2 — Управляемый — базовое управление. Для сложных проектов ПС объемом в десятки и сотни тысяч строк, в которых участву­ ют десятки специалистов разной квалификации, необходимы организация, регламентирование технологии и унификация процессов деятельности каж­ дого из них. Процессы на этом уровне заранее планируются, их выполне-

62

3.1. Управление проектами программных средств в системе — CMMI

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

Уровень 3 — Определенный — стандартизация процессов. При высоких требованиях заказчика и пользователей к конкретным характери­ стикам качества сложного ПС и к выполнению ограничений по использо­ ванию ресурсов необходимо дальнейшее совершенствование и повыше­ ние уровня зрелости процессов ЖЦ ПС. Процессы ЖЦ ПС на этом уровне должны быть стандартизированы и представлять собой целостную техно­ логическую систему, обязательную для всех подразделений. На основе единой технологии поддержки и обеспечения качества ЖЦ ПС для каж­ дого проекта могут разрабатываться дополнительные процессы последо­ вательного оценивания качества продуктов с учетом их особенностей. Описание каждого процесса должно включать условия его выполнения, входные данные, рекомендации стандартов и процедуры выполнения, ме­ ханизмы проверки качества результатов, выходные данные, условия и до­ кументы завершения процессов. В описания процессов включаются сведе­ ния об инструментальных средствах, необходимых для их выполнения, роль, ответственность и квалификация специалистов.

Уровень 4 — Предсказуемый — количественное управление. Для реализации проектов крупных, особенно сложных ПС, в жестко ограни­ ченные сроки и с высоким гарантированным качеством, необходимы ак­ тивные меры для предотврапдения и выявления дефектов и ошибок на всех этапах ЖЦ ПС. Управление должно обеспечивать выполнение процессов в соответствии с текуш[ими требованиями к характеристикам качества ком­ понентов и ПС в целом. На этом уровне должна применяться система детального поэтапного оценивания характеристик качества как технологи­ ческих процессов ЖЦ, так и самого создаваемого программного продукта

63

Лекция 3. Модели и процессы управления проектами программных средств

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

Уровень 5 — Оптимизационный — непрерывное совершенствова­ ние и улучшение. Дальнейшее последовательное совершенствование и модернизация технологических процессов ЖЦ ПС для повышения каче­ ства их выполнения и расширение глубины контроля за их реализацией. Одна из основных целей этого уровня — сокращение проявлений и потерь от случайных дефектов и ошибок путем выявления сильных и слабых сторон используемых процессов. При этом приоритетным является анализ рисков, дефектов и отклонений от заданных требований заказчика. Эти данные также используются для снижения себестоимости ЖЦ особо слож­ ных ПС в результате внедрения новых технологий и инструментария, а также для планирования и осуществления модернизации всех видов про­ цессов. Технологические нововведения, которые могут принести наиболь­ шую выгоду, должны стандартизироваться и адаптироваться в комплекс­ ную технологию обеспечения и оценивания системы качества предприя­ тия и его продукции.

В 2003 году американский Институт программной инженерии (SEI)

опубликовал новую комплексную модель CMMI, уточняющую и совер­ шенствующую предшествовавшие модели СММ, а также частично учи­ тывающую основные требования суи^ествуюи^их международных стан­ дартов в области менеджмента программных средств. Внедрение этой модели акцентировано на улучшении процессов управления проектами ПС, обеспечении их высокого качества и конкурентоспособности, с ос­ новной целью — сделать процессы що^ктоъ управляемыми, а результаты

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

64

3.1. Управление проектами программных средств в системе — CMMI

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

В последнее время появилась информация о модернизации американ­ ским Институтом программной инженерии SEI версии CMMI-SE/SW/ IPPD, VI.1 на основе накопленного опыта и отзывов предприятий. Пред­ полагается выпустить в 2006 году новую, существенно модернизирован­ ную, версию модели CMMI-V1.2, после чего постепенно должно прекра­ титься применение версии 1.1. До конца 2007 года должен проводиться переход пользователей на версию CMMI-V1.2, а в дальнейшем она станет обязательной для формализованной оценки качества (сертификации) тех­ нологии предприятий в области программной инженерии. При этом срок действия сертификата будет ограничен тремя годами. К этим изменениям следует готовиться после официальной публикации Институтом SEI вер­ сии 1.2.

Два варианта модели CMMI — 1.1 созданы для обеспечения непре­ рывного оценивания комплекса процессов в определенной области созда­ ния программных средств или для поэтапного оценивания и совершен­ ствования зрелости предприятия, а также для организации ЖЦ комплек­ сов программ в целом. Модели CMMI представляют помощь специалистам при организации технологии и совершенствовании их продуктов, а также для упорядочения и обслуживания процессов разработки и сопровожде­ ния ПС. Концепция этих моделей покрывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также про­ цессов создания интегрированных программных продуктов и совершен­ ствования их разработки. Компоненты непрерывной и поэтапной моделей в значительной степени подобны, могут выбираться и применяться в раз­ ном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов.

Варианты описания моделей построены по единой схеме, которая содержит общие разделы:

предисловие;

1)введение;

2)модель компонентов;

3)терминология;

4)содержание уровней и главные компоненты каждого варианта мо­ дели (разработка целей и процедур);

65

Лекция 3. Модели и процессы управления проектами программных средств

5 раздел — структура взаимодействия процессов. Аннотированы че­ тыре категории процессов раздела 7, их общий обзор и схемы взаимодей­ ствия CMMI процессов:

•менеджмент процессов;

•менеджмент — управление проектом;

•инжиниринг (технология);

•поддержка;

6 раздел — использование модели CMMI — краткие рекомендации для пользователей по применению модели и обучению; отмечается совме­ стимость и соответствие процессов модели с регламентированными про­ цессами предыдущей модели СММ в части 2 и 3 стандарта ISO 15504.

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

Первый вариант (непрерывной) модели отражает документ: Capability

Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Product and Process Development^ Version LI, Continuous Representation (CMMI-SE/SW/IPPD, VI. 1, Continuous) — Ин­ тегрированная модель оценивания зрелости инженерии систем / программ­ ной инженерии / интегрированных продуктов и процессов разработки —

непрерывное представление. В этой модели седьмой раздел составля­

ют процессы:

— менедлсмент процессов:

•содержание организационных процессов;

•определение организационных процессов;

•организация обучения;

•организация преобразования (изменений) процессов;

•организация инноваций и расширений;

— управление проектом:

•планирование проекта;

•мониторинг и контроль процессов проекта;

•управление соглашениями с поставщиками;

•интегрированное управление процессами и продуктами проекта;

66

3.1.Управление проектами программных средств в системе — CMMI

•управление рисками;

•интеграция команды разработчиков;

•интегрированное управление поставщиками;

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

— инженерия (технология):

•управление требованиями;

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

•технические решения;

•интеграция продукта;

•верификация;

•валидация (аттестация, утверждение);

— поддержка:

•управление конфигурацией;

•обеспечение качества процессов и продуктов;

•измерение и анализ процессов и продуктов;

•анализ и принятие решений на изменения;

•организация окружения для интеграции;

•анализ причин и разрешение проблем (устранение дефектов). В пяти приложениях приводятся:

А — состав использованных литературных источников и документов,

вкотором, однако, не упоминаются стандарты ISO;

В — сокращения;

С — глоссарий на основе терминологии ISO, применяемой только в четырех стандартах ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D — описания требований и предложений для формирования компо­ нентов модели по уровням зрелости;

Е — список участников разработки CMMI — проекта.

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

Планирование проекта в этой, так же как и во второй, модели вклю­ чает:

— оценку возможного размера — масштаба программного продукта;

67

Лекция 3. Модели и процессы управления проектами программных средств

—оценку сложности функций и характеристик проекта ПС;

—определение модели и этапов жизненного цикла комплекса про­

грамм;

—технико-экономическое обоснование проекта — определение сто­ имости, трудоемкости и длительности ЖЦ ПС;

—разработка поэтапного графика работ и бюджета проекта;

—анализ, идентификация и оценка проектных рисков;

—планирование и управление документированием процессов и про­ дуктов в ЖЦ проекта ПС;

—планирование и распределение технических и людских ресурсов по этапам ЖЦ ПС;

—планирование обеспечения знаний и квалификации коллектива спе­ циалистов для реализации проекта;

—обобщение и анализ совокупности планов проекта ПС;

—согласование работ и ресурсов по этапам ЖЦ разработчиком с заказчиком проекта ПС;

—документирование плана работ и утверждение его менеджером разработчиков проекта.

Процессы разработки требований к программному продукту анало­ гичны процессам в обеих моделях и включают:

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

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

—определение доступных ресурсов и ограничений проекта комплек­ са программ;

—декомпозицию базовых исходных требований к функциям ПС в набор требований к компонентам и тестам комплекса программ;

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

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

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

68

3.1. Управление проектами программных средств в системе — CMMI

Управление требованиями в обеих моделях включает:

—достижение однозначного понимания требований к проекту ПС заказчиком и разработчиками;

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

—согласованное между заказчиком и разработчиком управление из­ менениями требований к проекту ПС;

—обеспечение прослеживания корректности изменений от общих требований к проекту ПС до требований к компонентам и частным про­ цессам;

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

Второй вариант CMMI представлен документом: Capability Maturity

Model Integrationfor Systems Engineering/Software Engineering /Integrated Product and Process Development, Version LI, Staged Representation

(CMMI-SE/SW/IPPD, VI. 1, Staged) — Интегрированная модель оценива­ ния зрелости инженерии сложных систем / программной инженерии / ин­ тегрированных продуктов и процессов разработки — поэтапное пред­ ставление. Модель базируется на сохранении концепции пяти уровней зрелости СММ. Состав процессов практически повторяет приведенный выше для первого варианта модели, в несколько иной последовательности

ис относительно небольшими дополнениями. Первый уровень отличается значительной неопределенностью состава и содержания процессов в раз­ личных относительно простых проектах, поэтому он в документе не опи­ сан и не комментируется. Поэтому при уточнении и детализации содержа­ ния процессов в поэтапном варианте CMMI рекомендуется ограничивать­ ся четырьмя (2-й — 5-й) основными уровнями:

—второй уровень — формализует базовое управление проектами:

•управление требованиями;

•планирование проекта;

•мониторинг и контроль проекта;

•управление соглашениями с поставщиками;

•измерение и анализ процессов и продуктов;

•обеспечение качества процессов и продуктов;

•управление конфигурацией;

69