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

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

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

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

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

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

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

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

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

В 2003 году американский Институт программной инженерии (SEI) опубликовал новую комплексную модель CMMI, уточняющую и совершенствующую предшествовавшие модели CMM, а также частично учитывающую основные требования существующих международных стандартов в области менеджмента программных средств. Внедрение этой модели акцентировано на улучшении процессов управления проектами ПС, обеспечении их высокого качества и конкурентоспособности, с основной целью – сделать процессы проектов управляемыми, а результаты – предсказуемыми. Значительное внимание в CMMIуделяется процессам разработки и учету итераций при изменении требований заказчиков, их прослеживанию к функциям, компонентам, тестам и документам проекта. Концепцию, определяющую функциональную пригодность и качество продукта, рекомендуется сопровождать проверками возможных сценариев событий при его применении.

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

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

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

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

1. введение;

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

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

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

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

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

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

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

* поддержка;

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

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

Первый вариант (непрерывной) модели отражает документ: Capability Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Continuous) – Интегрированная модель оценивания зрелости инженерии систем / программной инженерии / интегрированных продуктов и процессов разработки – непрерывное представление. В этой модели седьмой раздел составляют процессы:

- менеджмент процессов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- поддержка:

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

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

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

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

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

* анализ причин и разрешение проблем (устранение дефектов).

В пяти приложениях приводятся:

А – состав использованных литературных источников и документов, в котором, однако, не упоминаются стандарты ISO;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй вариант CMMIпредставлен документом: Capability Maturity Model Integration for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, Staged) – Интегрированная модель оценивания зрелости инженерии сложных систем / программной инженерии / интегрированных продуктов и процессов разработки – поэтапное представление. Модель базируется на сохранении концепции пяти уровней зрелости CMM. Состав процессов практически повторяет приведенный выше для первого варианта модели, в несколько иной последовательности и с относительно небольшими дополнениями. Первый уровень отличается значительной неопределенностью состава и содержания процессов в различных относительно простых проектах, поэтому он в документе не описан и не комментируется. Поэтому при уточнении и детализации содержания процессов в поэтапном варианте CMMI рекомендуется ограничиваться четырьмя (2-й – 5-й) основными уровнями:

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

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

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

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

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

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

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

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

- третий уровень – содержит стандартизацию основных процессов:

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

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

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

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

* валидация (аттестация);

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

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

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

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

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

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

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

* анализ и разрешение проблем (устранение дефектов);

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

- четвертый уровень – определяет количественное управление:

* организация представления качества процессов;

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

- пятый уровень – оптимизационный, непрерывное совершенствование:* организация, инновации, количественное управление процессами и обеспечением ресурсами;

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

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

- общие цели процесса, которые должны быть достигнуты;

- вводные замечания и общее описание функций процесса;

- специфические цели процесса;

- менеджмент процесса;

- разработка требований к процессу;

- взаимодействие и интерфейсы с другими процессами;

- практические цели – требуемые результаты действий процесса;

- планирование действий в определенном процессе;

- анализ и валидация (утверждение) результатов реализации процесса;

- мониторинг и контроль выполнения процесса.

Эти рекомендации по объему, содержанию и полноте описаний базовых процессов подобны ряду стандартов профиля ЖЦ ПС. Упорядочение и оценка полноты используемых процессов в соответствии с уровнями зрелости, позволяет устанавливать производственный потенциал предприятий – разработчиков программных продуктов по прогнозируемому качеству процессов и результатов их деятельности и готовности к сертификации на соответствие определенному уровню зрелости модели CMMI – 1.1.

Особое внимание в моделях CMMIуделяется процессам менеджмента проекта ПС. Эти требования и процессы моделей практически соответствуют, регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000, ISO 12207 и в основных компонентах профиля стандартов жизненного цикла сложных ПС. Требованиям к процессам в функциональных разделах 4 – 8 стандартов ISO 9001, ISO 9004, ISO 90003 может быть сопоставлен адекватный по содержанию ряд разделов в моделях CMMI– рис. 3.2. Общность процессов и требований состоит в подобии: состава, терминологии, структуры, перечня основных рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов программной инженерии, оценивания и организации специалистов.

С точки зрения поддержки и регламентирования полного жизненного цикла крупных проектов программных средств к недостаткам моделей CMMI относительно профиля существующих стандартов ISOможно отнести следующие:

- не все процессы предусмотрены в составе процессов моделей CMMI– 1.1, которые развиваются и детально комментируются для их реализации в стандартах ISO 9004:2000 и ISO 90003:2004, а также в профиле стандартов ISO;

- не отражены особенности системной инженерии и международные стандарты, регламентирующие процессы жизненного цикла сложных систем ISO 15288:2002 и ISO 19760:2003;

- при анализе процессов обеспечения качества используется ряд традиционных характеристик систем и программных продуктов, которые применяются в сложных проектах, однако не описаны и не комментируются базовые международные стандарты, систематизирующие и регламентирующие качество программных средств - ISO 9126:1-4, ISO 14598:1-6, ISO 15939;

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

- не отражены регламентированные интерфейсы Открытых систем на взаимодействие программных компонентов, а также с операционной и внешней средой, в соответствии со стандартами - ISO 9945:1-4;

- документирование процессов и продуктов ЖЦ ПС комментируется только, по мере их реализации, и не представлены обобщенные требования к технологической и эксплуатационной документации на программный продукт в соответствии со стандартами - ISO 9294, ISO 15910, ISO 18019.

Для определения, представленных выше уровней зрелости процессов обеспечения жизненного цикла ПС, разработан и первоначально утвержден в 1998 году обширный технический отчет ISO 15504– Оценка и аттестация зрелости процессов создания и сопровождения ПС и систем, состоящий из девяти частей и множества приложений. В нем изложена модель зрелости CMMи восемь базовых принципов программной инженерии на основе стандарта ISO 9000:2000 (см. лекцию 1). Затем в ISOэтот документ претерпел коренную переработку, сокращение, упрощение структуры и содержания, при полном сохранении целей и концепции, и утвержден как стандарт в составе пяти частей (см. Приложение 1). Стандарт ISO 15504:1-5:2003-2006регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями:

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

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

- с целью его пригодности для выполнения определенных договоров с заказчиками ПС и систем.

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

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

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

- для аттестаторов зрелости – основу для проведения и совершенствования процессов аттестации.

Аттестация в стандарте рассматривается в двух аспектах: для усовершенствования процессов ЖЦ ПС и систем конкретного предприятия, и для определения соответствия декларированной зрелости процессов обеспечения проекта или предприятия, реальным используемым процессам. Это отражено в следующих пяти частях стандарта ISO 15504:1-5:2003-2006.

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

Часть 2 – Выполнение (производство) аттестации – включает детальные требования к проведению процессов аттестации, как основы для совершенствования и определения уровня зрелости технологических процессов обеспечения ЖЦ ПС и систем. Документ определяет процессы выполнения аттестации, модели рекомендуемых процессов аттестации и верификации процессов, с тем, чтобы они были объективными, содержательными и репрезентативными.

Часть 3 – Руководство по производству аттестации – содержит обзор технологии выполнения процессов аттестации зрелости, и интерпретации реализации требований. В нем отражено: исполнение аттестации; измерительные средства для определения процессов зрелости; выбор и применение средств аттестации; оценка компетентности аттестаторов; верификация соответствия аттестации декларированным требованиям. Средства аттестации могут использоваться предприятиями при планировании, менеджменте, мониторинге, контроле и усовершенствовании программных продуктов и систем, при их приобретении, разработке, применении и сопровождении.

Часть 4 – Руководство пользователей для процессов усовершенствования и определения зрелости процессов по этим двум аспекта. Рекомендуется ряд шагов, которые включают: применение результатов процессов аттестации; постановка целей аттестации зрелости; определение исходных данных для аттестации; оценка возможного снижения результирующих рисков; шаги по усовершенствованию процессов; шаги по определению уровня зрелости; сравнение результатов анализа аттестации с требованиями.

Часть 5 – Образец модели процессов аттестации на соответствие требованиям, представленным в части 2. Обширный документ (162 стр.) содержит примеры практического применения предыдущих частей стандарта для организации, оценивания и совершенствования аттестации зрелости процессов жизненного цикла для различных областей использования, проектов программных средств и предприятий.

При практической реализации проектов и обеспечении жизненного цикла сложных ПС разработчикам и поставщикам может быть трудно определить, и выделить для применения преимущества моделей CMMI. В зависимости от традиций предприятия и особенностей крупного проекта ПС зачастую целесообразно использовать как основной полный профиль стандартов ISO, а для оценивания заказчиками уровня зрелости менеджмента, организационного и технологического обеспечения проектов ПС применять конкретные рекомендации CMMI. Эти рекомендации могут эффективно использоваться при сертификации качества процессов на предприятиях, обеспечивающих ЖЦ ПС, как альтернатива или наряду с сертификацией по комплексу стандартов менеджмента ISO 9000, в зависимости от особенностей проекта и требований заявителя на сертификацию программного продукта или технологии обеспечения его жизненного цикла.