Реферат: Методология CCM (Capability Maturity Model for Software) – модель развития способности организации разрабатывать и сопровождать программные продукты) в менеджменте качества проектов

Рекомендуется использовать данную ОКП наряду с методологией PSP (PersonalSoftwareProcess — прог­раммное обеспечение ПК) [7], где львиная доля работ по контролю качества ПО возлагается на разработчика. По данным SEI [8] разработчик находит ошибки в 10 раз быстрее и в десять раз больше, чем тестировщик. Если выполняются действия по определению требова­ний к ПО и по оценке критериев качества ПО, то рабо­ты по автономному тестированию (т.е. тестированию отдельных кусков ПО) считаются экономически невы­годными. Тестировщики осуществляют тестирование системы по принципу «черного ящика», т. е. осуществ­ляют общесистемное тестирование.

Данная ОКП определяет следующие цели:

1) деятельность по обеспечению качества ПО должна планироваться;

2) должен обеспечиваться объективный контроль за строгим соответствием ПО и процессов принятым стандартам, процедурам и требованиям;

3) задействованные группы и конкретные работни­ки должны информироваться о действиях по обеспе­чению качества и об их результатах;

4) вопросы несоответствия требованиям, которые невозможно разрешить в рамках проекта, должны ре­шаться на высшем уровне компании.

УИ в начале внедрения СММ находилось выше нулевого уровня оценки зрелости данной ОКП (10%). В 1999 г. в УИ попытались внедрить учет дефектов с назначением ответственных за дефект. В реальной ра­боте учет дефектов не использовался. Сейчас уровень обеспечения качества ПО снизился до 5%.

CIT в 1999 г. находилась на уровне 10% зрелости по данной ОКП. С вводом в повседневную практику

Уровень зрелости,

Рис. 5. 1" УИ; 2 - CIT

учета дефектов с помощью Prose уровень оценива­ется в 30%. На­блюдается тенден­ция к его повышению (рис. 5, табл. 7).

Таблица 7 - Качественная характеристика уровня зрелости контроля качества

Качественная характеристика уровня зрелости	%
0. Контроля качества ПО нет, есть повседневная практика — «лучшим контролером ПО является пользователь»	0
1. Существует практика «полицейского контроля», с определением виновного и его «материальным наказанием»	20
2. Существует практика тотального учета дефектов в разрезе выполненных работ и исполнителей; за выявленный дефект исполнитель не наказывается, идет стимулирование раннего обнаружения дефектов	40
3. Существует практика регулярного измерения уровня качества ПО и планирование повышения качества	60
4. Накапливаются формализованные знания (метрики) по причинам, вызывающим дефекты, что позволяет исполнителям самостоятельно и своевременно выявлять и исправлять дефекты	80
5. СУЗ позволяет планировать предупреждающие действия по исключению дефектов.	100

7.5.5. Консервация продукции — управление конфигурацией

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

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

В ОКП «Управление конфигурацией» входят про­цессы, связанные с подготовкой и отсылкой версий конечным пользователям. Если последних рассматри­вать как партнеров, участвующих в разработке ПО и вносящих свои замечания, то обновления версий мо­гут быть достаточно частыми. В данном случае систе­ма «Управление конфигурациями» должна стоять у конечного пользователя и быть связана с системой учета требований (схема 3).

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

Схема 3 - систе­ма «Управление конфигурациями»

Уровень зрелости, %

Данная ОКП ставит следующие цели:

1) деятельность по управлению конфигурациями должна планироваться;

2) находящиеся в работе ПО должны быть иденти­фицируемы, управляемы и доступны;

3) изменения в ПО, находящихся в работе, долж­ны контролироваться;

4) задействованные группы и конкретные работни­ки должны информироваться о статусе и содержании основных направлений разработки ПО.

Уровни оценки зрелости ОКП «Управление конфигурацией» даны в табл. 8.

УИ находилось на уровне 10%. В начале 1999 г. в УИ было внедрено поддержание эталонной версии, в конце 1999 г. — среда коллективной разработки «Roundtable». Но данная система не охватывала всех автономных задач, т.е. часть исполнителей в УИ нахо­дится на уровне зрелости ОКП, равном 60%, а другая — 0%. Интегральный показатель уровня зрелости ОКП - 30%.

CIT в 1999 г. находилась на уровне 20%. С вводом в повседневную практику среды коллективной разра­ботки «Roundtable» и интеграции ее с Prose уровень зрелости оценивается в 70% (рис. 6).