рефераты по менеджменту

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

Страница
5

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

Рис. 4. 1 - УИ; 2 - CIT

CIT в 1999 г. находилась на уровне 20% зрело­сти ОКП. С вво­дом в повседнев­ную практику формирования заявок к субпод­рядчикам, а также

учета выполненных работ на базе E-mail, уровень зре­лости данной ОКП оценивается в 30% (рис. 4).

Идентификация и прослеживаемость — обеспечение качества

Рекомендуется использовать данную ОКП наряду с методологией PSP (Personal Software Process — прог­раммное обеспечение ПК) [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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качественная характеристика уровня зрелости

%

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

0

1. Существует практика эталонной версии, с ответственным за сборку исходных файлов от всех исполнителей

20

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

40

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

60

4. Накапливаются формализованные знания (метрики) по стилю и методам разработки, формируются шаблоны и сценарии тестирования, проводится регрессивное тестирование

80

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

100

Перейти на страницу номер:
 1  2  3  4  5  6  7 

© 2010-2024 рефераты по менеджменту