CapabilityMaturity Моdеl

Первоначальная версия модели выпущена в конце 1987 г. После этого модель несколько раз перерабатывалась. Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. В итоге методология оказалась чрезвычайно полезной для компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования ПО, свести управление ими к понятным алгоритмам и технологиям, описанным в едином стандарте.СММ де-факто стал именно таким стандартом. Его применение позволяет поставить разработку ПО на промышленную основу.

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

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

 

цели	Goal
обязательства по выполнению	CommitmenttoPerform
осуществимость выполнения	AbilitytoPerform
выполняемые действия	ActivityPerformed
измерениеианализ	Measurement and Analysis
проверку внедрения	VerifyingImplementation

 

1) Начальный уровень (InitialLevel – Level 1).

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

2) Повторяемыйуровень (Repeatable Level – Level 2).

Этому уровню соответствуют предприятия, обладающие определенными технологиями управления и разработки,управление требованиями и планирование основываются на разработанной документированной политике и накопленном опыте. Установлены и введены в практику базовые показатели для оценки параметров проект а. Отслеживается выполнение работ и производственные затраты. Изменения версий конечного программного продукта и созданных промежуточных программных средств отслеживаются в системе управления конфигурацией. Ключевые области процесса разработки ПО этого уровня:

· Управление требованиями (Requirementsmanagement).

· Планирование проекта разработки ПО (Softwareprojectplanning).

· Отслеживание хода проекта и контроль (Softwareprojecttrackingandoversight).

· Управление субподрядчиками разработки ПО (Softwaresubcontractmanagement).

· Обеспечение уверенности в качестве разработки ПО (Softwarequalityassurance).

· Управление конфигурацией продукта (Softwareconfigurationmanagement).

3) Определенный уровень (DefinedLevel – Level 3).

Уровень характеризуется детализированным методологическим подходом к управлению (то есть описаны и закреплены в документированной политике типичные действия, необходимые для многократного повторения: роли и ответственность участников, стандартные процедуры и операции, порядок действий, количественные показатели и метрики процессов, форматы документов и пр.).

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

· Определение (стандартного) процесса организации (OrganizationProcessDefinition).

· Программа обучения (TrainingProgram).

· Интегрированное управление разработкой ПО (IntegratedSoftwareManagement).

· Технология разработки программных продуктов (SoftwareProductEngineering).

· Межгрупповая координация (IntergroupCoordination).

· Экспертные (совместные) оценки коллег (PeerReviews).

4) Управляемый уровень (ManagedLevel – Level 4).

Более высокий уровень управления проектами достигается за счет уменьшения отклонений различных показателей проекта от запланированных. У организаций этого уровня имеются способы детального измерения качества процесса и разрабатываемого ПО. Количественные характеристики процесса разработки и разрабатываемых ПО хорошо изучены и управляемы, процесс предсказуем.

Ключевые области процесса разработкиПОэтогоуровня:

· Количественное управление процессом (QuantitativeProcessManagement).

· Управление качеством ПО (SoftwareQualityManagement).

5) Оптимизирующийуровень (OptimizingLevel – Level 5).

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

Ключевые области этого уровня:

· Предотвращение дефектов (DefectPrevention).

· Управление изменением технологий (TechnologyChangeManagement).

· Управление изменением процесса (ProcessChangeManagement).

 

Любой уровень подразумевает выполнение организацией некоторого набора ключевых действий для достижения определенных целей. Выполнение или невыполнение различных ключевых действий является своеобразным показателем, по которому можно судить об уровне зрелости организации. Для определения этого уровняв модели СММ предусмотрен целый перечень вопросов, которые могут быть заданы сотрудникам организации. Анализ ответов на эти вопросы позволяет сделать вывод о достигнутом уровне зрелости

К преимуществам модели SEI SW-CMM относится то, что она ориентирована на организации, занимающиеся разработкой программного обеспечения. В данной модели удалось более детально проработать требования, специфичные для процессов, связанных с разработкой ПО. По этой причине в SEI SW-CMM приведены не только требования к процессам организации, но и примеры реализации таких требований.

Основной же недостаток SW-CMM заключается в том, что модель не авторизована в качестве стандарта ни международными, ни национальными органами по стандартизации. Впрочем, CMM давно уже стала промышленным стандартом де-факто.

 

К недостаткам данной модели необходимо отнести также большие внешние накладные расходы на приведение процессов компании в соответствие модели СММ, нежели к моделям ISO 9000. Это связано с меньшей распространенностью модели в мире, меньшим количеством консалтинговых органов и экспертов и, в результате, с гораздо большими внешними затратами на консалтинг и на подтверждение соответствия процессов независимой третьей стороной. Тем не менее, CMM, несомненно, полезнее ISO 9000.

Замечание: Стандарты ISO 9000 содержат минимальные требова­ния, которым должна соответствовать организация работ по обеспечению гарантии качества независимо от того, какую именно продукцию выпускает предприятие или какие услуги оно оказывает. Если система управления ка­чеством, в рамках которой реализуются процессы управ­ления в данной организации, соответствует требованиям стандартов ISO, то это воспринимается потребителями как убедительное доказательство способности фирмы обеспечить выпуск продукции, выполнение работ или оказание услуг требуемого уровня качества.

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

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

 

 

Рассмотрим основные методы обеспечения надежности на разных этапах жизненного цикла ИС, которые могут быть включены в комплекс мер по обеспечению надежности.

1. Этап составления технического задания. На этом этапе необходимо собрать все имеющиеся данные

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

· об условиях применения подобных систем,

· о требованиях, предъявляемых к ним (функциям, выполняемым рассматриваемой системой).

 

2. Этап эскизного проектирования. На этапе эскизного проектирования

· выбирается элементная база, структура и организация разрабатываемой системы,

· проводится предварительный расчет надежности,

· проводится предварительный расчет надежности,

· принимается решение о резервировании наименее надежных подсистем,

· принимается решения о способах и организации технического обслуживания (профилактических и ремонтных работ),

· исследуется вопрос о целесообразности и способах реализации методов автоматического восстановления и отказоустойчивости в системе.

 

3. Этапы технического и рабочего проектирования. На этих этапах проверяются и уточняются приняты е технические решения. Основой для этого служат данные о надежности, полученные на основании расчетов и результаты экспериментов над моделями, макетами, опытными и промышленными образцами. Разрабатывается программное обеспечение системы и проводится проверка по тестам (путем имитационного моделирования на модели разрабатываемой ИС).

4. Этап производства. Здесь основным является технический контроль, охватывающий все стадии производственного процесса (входной контроль качества комплектующих изделий, соответствия печатных плат, блоков, устройств, схемных соединений и т.д.технической документациям) и устранение недостатков в разработке системы.

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