Реферат: Методология 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).