Подходы к оценке качества программных систем, страница 5

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

Валидация данных. Все собранные данные, необходимые для охвата сферы оценивания, проверяются и утверждаются.

Определение рейтинга процесса. На основании утвержденных данных каж­дому атрибуту процесса присваивается оцененный рейтинг. Множество рейтингов атрибута процесса протоколируется как профиль мощности процесса для опреде­лённого организационного подразделения (см. рисунок 10.4).

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

Для того чтобы оценить расхождения по каждому атрибуту и по совокупно­сти атрибутов, составляющих мощность процесса в целом, стандарт ISO/IEC 15504-3 предлагает соответствующие таблицы (таблица 10.3 и таблица 10.4).

Чем выше расхождение в целевой и оцененной мощности, тем больше веро­ятность того, что процесс неустойчив и может не соответствовать тем целям, для которых его хотят применить.

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

Как видно на рисунке 10.6, если оцениваемый процесс находится на высоком уровне мощности (первая строка матрицы), небольшие отклонения в мощности не так уж страшны, риск невелик.

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

10.3. Оценивание зрелости организаций-разработчиков

10.3.1. Модели зрелости

Наряду с моделью оценивания и усовершенствования процессов разработки программных систем, предлагаемой стандартом ISO/IEC 15504, существует множе­ство других моделей, совсем новых и относительно старых (начала 90-х годов), стандартизованных и не стандартизованных. Они разработаны в разных странах и в разной степени распространены. Степень их распространения (или предпочтения) можно определять по территориальному, ведомственному и другим признакам. Многие сайты в Интернете предлагают свои путеводители по моделям. Один такой путеводитель представлен на рисунке 10.7. Это страничка «The Frameworks Quag-mire.htm», разработанная фирмой Software Productivity Consortium (www.software.org/quagmire/), на которой можно «по щелчку» получить справку о любой из указанных на схеме моделей.

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

Наиболее известным (и широко используемым не только в Америке, но и на других континентах) является семейство моделей зрелости CMMs (Capability Ma­turity Models).

В этом разделе мы рассматриваем только первую (исторически) модель - мо­дель SW-CMM (Capability Maturity Model for Software), опубликованую SEI в 1993 году [18].

Эта модель уже была кратко описана в главе 1 (п. 1.2.5). Напомним, ее ос­новные отличия от модели SPICE, предложенной в стандарте ISO/IEC 15504.

Модель SPICE может использоваться для оценивания уровня мощности и со­вершенствования любого одного или совокупности процессов ЖЦ, выбираемых для оценивания с определенной целью. Фактически оцениваются базовые практиче­ские приемы процесса (характеристика их выполнения), рабочие продукты процес­са (их наличие), характеристики рабочих продуктов (их наличие), а также приемы руководства (характеристика их выполнения) и характеристики ресурсов и ин­фраструктуры (их наличие). Результат оценивания - вектор - профиль мощности процесса (уровень мощности (от 0 до 5) и рейтинги атрибутов мощности на дан­ном уровне мощности).

Модель СММ может использоваться для оценивания и совершенствования процесса программной инженерии (в целом) в организации (поэтому ее обычно и называют моделью зрелости (совершенства) организации, а не отдельных процес­сов ЖЦ).

Модель выделяет и дает строгое описание 18 ключевых направлений (облас­тей, участков) процесса КРА (KeyProcessAreas) программной инженерии (схожих по назначению с поддерживающими и организационными процессами ЖЦ в ISO/IEC 15504), которые «распределены» по уровням зрелости (от 2 до 5). Для того чтобы организация достигла определенного уровня зрелости, она должна внедрить (институциализировать) соответствующее множество КРА и предоставить экспер­там (имеющим права оценивания и владеющим методами экспертного оценивания) документальное подтверждение внедрения КРА в процесс программной инжене­рии. Результат оценивания - сертификат уровня зрелости и/или рекомендации по дальнейшему совершенствованию процесса.

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