В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 10

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 10)

Он должен включать как управленческие, так итехнические подпроцессы, а также обучение сотрудников работе с ним.ƒ Уровень 4, управляемый (manageable).В этих организациях, помимо установленного и описанного процесса, используютсяизмеримые показатели качества продуктов и результативности процессов, которыепозволяют достаточно точно предсказывать объем ресурсов (времени, денег,персонала), необходимый для разработки продукта с определенным качеством.ƒ Уровень 5, совершенствующийся (optimizing).В таких организациях, помимо процессов и методов их оценки, имеются методыопределения слабых мест, определены процедуры поиска и оценки новых методов и26техник разработки, обучения персонала работе с ними и их включения в общийпроцесс организации в случае повышения эффективности производства.o Ключевые области процесса.Согласно CMM, уровни зрелости организации можно определять по использованиючетко определенных техник и процедур, относящихся к различным ключевым областямпроцесса.

Каждая такая область представляет собой набор связанных видовдеятельности, которые нацелены на достижение целей, существенных для общейоценки результативности технологического процесса. Всего выделяется 18 областей.Множество областей, которые должны поддерживаться организацией, расширяется припереходе к более высоким уровням зрелости.ƒ К первому уровню не предъявляется никаких требований.ƒ Организации второго уровня зрелости должны поддерживать управлениетребованиями, планирование проектов, надзор за ходом проекта, управлениеподрядчиками, обеспечение качества ПО, управление конфигурацией.ƒ Организации третьего уровня должны, помимо деятельностей второго уровня,поддерживать проведение экспертиз, координацию деятельности отдельных групп,разработку программного продукта, интегрированное управление разработкой исопровождением, обучение персонала, выработку и поддержку технологическогопроцесса организации, контроль соблюдения технологического процессаорганизации.ƒ К деятельностям организаций четвертого уровня добавляются: управлениекачеством ПО и управление процессом, основанное на измеримых показателях.ƒ Организации пятого уровня зрелости должны дополнительно поддерживатьуправление изменениями процесса, управление изменениями используемыхтехнологий и предотвращение дефектов.o Ключевые практики.Ключевые области процесса описываются с помощью наборов ключевых практик.Ключевые практики классифицированы на несколько видов: обязательства(commitments to perform), возможности (abilities to perform), деятельности (activitiesperformed), измерения (measurements and analysis) и проверки (verifyingimplementations).Например, управление требованиями связано со следующими практиками.ƒ Обязательство.Проекты должны следовать определенной политике организации по управлениютребованиями.ƒ Возможности.В каждом проекте должен определяться ответственный за анализ системныхтребований и привязку их к аппаратному, программному обеспечению и другимкомпонентам системы.Требования должны быть документированы.Для управления требованиями должны быть выделены адекватные ресурсы ибюджет.Персонал должен проходить обучение в области управления требованиями.ƒ Деятельности.Прежде чем быть включенными в проект, требования подвергаются анализу наполноту, адекватность, непротиворечивость и пр.Выделенные требования используются в качестве основы для планирования ивыполнения других работ.Изменения в требованиях анализируются и включаются в проект.27ƒИзмерение.Производится периодическое определение статуса требований и статусадеятельности по управлению ими.ƒ Проверки.Деятельность по управлению требованиями периодически анализируется старшимименеджерами.Деятельность по управлению требованиями периодически и на основании значимыхсобытий анализируется менеджером проекта.Группа обеспечения качества проводит анализ и аудит деятельности по управлениютребованиями и отчитывается по результатам этого анализа.Таблица 4 суммирует информацию о количестве практик различных видов,приписанных к разным ключевым областям процесса.Уровни2345Область процессаОбязательства Возможности Деятельности Измерения ПроверкиУправление требованиями14313Планирование проектов241513Надзор за ходом проекта251313Управление подрядчиками231313Обеспечение качества ПО14813Управлениеконфигурацией151014Контроль соблюдениятехнологическогопроцесса34711Выработка и поддержкатехнологическогопроцесса12611Обучение персонала14623Интегрированноеуправление131113Разработка программногопродукта141023Координациядеятельности групп15713Проведение экспертиз13311Управление процессом наоснове метрик25713Управление качеством ПО13513Предотвращение дефектов24813Управление изменениямитехнологий35812Управление изменениямипроцесса241012Таблица 4.

Количество ключевых практик в разных областях процесса по CMM версии 1.1.•Интегрированная модель зрелости возможностей CMMI (Capability Maturity ModelIntegration) [11,12].Эта модель представляет собой результат интеграции моделей CMM для продуктов ипроцессов, а также для разработки ПО и разработки программно-аппаратных систем.Основные изменения по сравнению с CMM следующие.o Созданы два несколько отличающихся изложения модели — непрерывное и поэтапное.Первое предназначено для облегчения миграции от поддержки американскогоотраслевого стандарта EIA/AIS 713 и постепенного усовершенствования процессов за28счет внедрения различных практик.

Второе предназначено для облегчения миграции отподдержки CMM и поуровневого рассмотрения вводимых практик.o Элементы модели получили четкие пометки о том, являются ли они обязательными(required), рекомендуемыми (expected) или информативными (informative).o Используемые практики разделяются на общие (generic) и специфические (specific).Они дополняются набором общих и специфических целей, которые необходимы длядостижения определенного уровня зрелости в определенных областях процесса.o Некоторые уровни зрелости получили другие названия. Второй уровень названуправляемым (managed), а четвертый — управляемым на основе метрик (quantitativelymanaged).o Набор выделяемых областей процесса и практик значительно изменился.Все области процесса делятся на 4 категории.

В приводимом ниже списке областипроцесса помечены номером уровня, начиная с которого они должны поддерживатьсясогласно CMMI.ƒ Управление процессом.Включает выработку и поддержку процесса (3), контроль соблюдения процесса (3),обучение (3), измерение показателей процесса (4), внедрение инноваций (5).ƒ Управление проектом.Включает планирование проектов (2), контроль хода проекта (2), управлениесоглашениями с поставщиками (2), интегрированное управление проектами (3),управление рисками (3), построение команд (3), управление поставщиками (3) иизмерение показателей результативности и хода проекта (4).ƒ Технические.Включают выработку требований (3), управление требованиями (2), выработкутехнических решений (3), интеграцию продуктов (3), верификацию (3) ивалидацию (3).ƒ Поддерживающие.Включают управление конфигурацией (2), обеспечение качества продуктов ипроцессов (2), проведение измерений и анализ их результатов (2), управлениеокружением (3), анализ и принятие решений (3), анализ, разрешение ипредотвращение проблем (5).В целом перечисленные стандарты связаны так, как показано на Рис.

2 (сплошные стрелкиуказывают направления исторического развития, жирная стрелка обозначает идентичность,пунктирные стрелки показывают влияние одних стандартов на другие).MIL-STD-498(не действует)Стандарты министерстваобороны и промышленностиСШАJ-Std-016-1995(не действует)IEEE 1074IEEE/EIA 12207ISO/IEC 12207CMMISO/IEC 15504 (SPICE)CMMIСтандарты IEEEСтандарты ISOСтандарты SEI, принятыеминистерством обороныСША в настоящее времяРисунок 2. Стандарты, описывающие структуру жизненного цикла ПО.Стандарты являются суммой опыта, который был накоплен экспертами в инженерии ПО наоснове огромного количества проектов, проводившихся в рамках коммерческих структур США и29Европы и в рамках военных контрактов. Большая часть стандартов создавалась как наборкритериев отбора поставщиков программного обеспечения для министерства обороны США, и этузадачу они решают достаточно успешно.Все рассмотренные стандарты определяют некоторый набор видов деятельности, из которыхдолжен состоять процесс разработки, и задают ту или иную структуру на этих видах деятельности,выделяя их элементы.

Вместе с тем, как можно заметить, они не могут быть сведены безсущественных изменений в единую модель жизненного цикла ПО. В целом имеющиеся стандартыслабо согласованы между собой. Так что на сегодняшний день (2005 год) нет согласованногокомплекта стандартов, покрывающего всю данную область, и в ближайшие несколько лет он врядли появится, хотя работа по согласованию различных стандартов ведется.Кроме того, данные стандарты не предписывают четких и однозначных схем построенияжизненного цикла ПО, в частности, связей между отдельными деятельностями.

Это сделанонамеренно, поскольку ранее действовавшие стандарты типа DoD-Std-2167, были достаточножестко привязаны к каскадной модели жизненного цикла (см. ниже) и тем самым препятствовалииспользованию более прогрессивных технологий разработки. Современные стандарты стараютсямаксимально общим образом определить набор видов деятельности, которые должны бытьпредставлены в рамках жизненного цикла (с учетом целей отдельных проектов — т.е. проект, нестремящийся достичь каких-то целей, может не включать деятельностей, связанных с ихдостижением), и описать их при помощи наборов входных документов и результатов.Стоит заметить, что стандарты могут достаточно сильно разойтись с реальной разработкой,если в ней используются новейшие методы автоматизации разработки и сопровождения ПО.Стандарты организаций ISO и IEEE построены на основе имеющегося эмпирического опытаразработки, полученного в рамках распространенных некоторое время назад парадигм иинструментальных средств.

Характеристики

Список файлов книги