Документ обсуждает современные модели качества программного обеспечения, выделяя значимость улучшения процессов разработки для повышения производительности и качества. Рассматриваются два ключевых стандарта: Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE), подчеркивающие важные аспекты оценки и усовершенствования процессов. Статья также рассматривает недостатки существующих стандартов и взаимодействие между различными моделями качества.

1. Современные модели качества программного обеспечения

2. Современная индустрия программного обеспечения (ПО) характеризуется очень высокой степенью конкуренции. Для успешной работы на этом рынке компания должна разрабатывать, внедрять и сопровождать программное обеспечение быстро, в срок и с удовлетворительным качеством. Поэтому многие компании вкладывают деньги в улучшение качества процесса, памятуя о том, что подобное вложение денег обязательно окупается – изучение документированных случаев улучшения процессов разработки ПО показывает, что в успешных случаях наблюдается существенное улучшение производительности и качества со средним уровнем возврата вложений от 5:1 до 8:1 [1].

3. Существуют десятки различных подходов к обеспечению качества ПО, и у всех есть свои преимущества. Одной из первых моделей качества стал стандарт ISO (Международной организации по стандартизации) серии 9000, первая версия которого была выпущена в 1987 году. С тех пор сертификаты ISO серии 9000 сохраняют неизменную популярность и признаются во всем мире. Однако время не стоит на месте, и методики, положенные в основу стандартов серии ISO 9000, постепенно устаревают. Выделим наиболее существенные недостатки: недостаточная подробность стандарта, возможность самых различных его толкований в зависимости от представлений аудитора; неточность оценки качества процессов, задействованных при создании и внедрении программного обеспечения; отсутствие в стандарте механизмов, способствующих улучшению существующих процессов.

4. Перечисленные проблемы заставили экспертов разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и методологий. В данной статье мы опишем два наиболее удачных и содержательных стандарта – Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE). Существуют и другие достаточно развитые методологии, но, к сожалению, невозможно осветить все перспективные направления данной области в рамках одной статьи. Поэтому мы ограничимся упоминанием того, что за рамками данного обзора остались такие стандарты, как Bootstrap, во многом схожий с рассматриваемыми станадртами CMM и SPICE, Trillium, ориентированный на разработку продуктов в области телекоммуникаций и ISO 12207, посвященный жизненному циклу программного обеспечения. На протяжении всей статьи мы будем проводить параллели между двумя рассматриваемыми стандартами и ISO 9001, чтобы подчеркнуть сходства и различия между ними.

5. Capability Maturity Model Официальная история CMM ( C apability M aturity M odel, что обычно переводят как "модель зрелости процесса разработки ПО", хотя более верным по смыслу был бы перевод "модель совершенствования возможностей") начинается в 1991 году, когда американский институт SEI (Software Engineering Institute – Институт системного программирования при университете Карнеги-Меллон) опубликовал первую версию этого стандарта. Изначальной целью разработки стандарта было создание методики, позволяющей крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В результате, авторам удалось добиться такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, желающих улучшить существующие процессы. Главным понятием стандарта является зрелость организации . Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются "на ходу". В этом случае велика вероятность превышения бюджета или заваливания сроков сдачи проекта, и потому менеджеры вынуждены заниматься только разрешением ближайших проблем.

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

7. Таковы базовые посылки стандарта CMM. Можно сказать, что стандарт в целом состоит из критериев оценки зрелости организации и рецептов улучшения существующих процессов. В этом наблюдается принципиальное различие с моделью, принятой в ISO 9001, так как в ISO 9001 сформулированы только необходимые условия для достижения некоторого минимального уровня организованности процесса, и не дается никаких рекомендаций по дальнейшему совершенствованию процессов. В модели CMM определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически) понижаться. На рисунке 1 показаны перечислены некоторые технологии, внедрение которых необходимо для достижения различных уровней зрелости организации. Отметим, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих.

8. Рисунок 1. Пять уровней зрелости в модели CMM.

9. Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

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

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

12. На управляемом уровне (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

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

14. При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям: Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.). Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение). Успешность использования данной области на практике (например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации).

15. В принципе, можно сертифицировать только один процесс или подразделение организации, например, подразделение разработки программного обеспечения компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем немного компаний, которые могут похвастаться наличием у них пятого уровня CMM хотя бы в одном из подразделений – таких всего около 50. С другой стороны, насчитывается несколько тысяч компаний, сертифицированных по 3 или 4 уровню, то есть существует колоссальный разрыв между оптимизированным уровнем зрелости и предыдущими уровнями. Однако еще больший разрыв наблюдается между количеством организаций начального уровня и числом их более продвинутых собратьев – по некоторым оценкам, свыше 70% всех компаний-разработчиков находится на первом уровне CMM [2].

16. Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком уровне CMM должна находиться организация, чтобы получить сертификат соответствия ISO 9001? На первый взгляд, для этого необходимо иметь как минимум 3 или 4 уровень CMM. Тем не менее, существуют примеры организаций 1-го уровня, имеющих сертификат ISO 9001. Одной из причин для возникновения подобных несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода его интерпретации аудитором. Иногда, как это ни странно, аудиторам не хватает элементарного знакомства с реальной практикой разработки программ.

17. Некоторые важные вопросы, например, отбор, повышение квалификации и сохранение компетентных сотрудников, остались за рамками CMM. Тем не менее, эти вопросы исключительно важны, ибо как замечено в статье [4] "и 20-30 лет назад было известно, что два программиста, сидящих за соседними столами и получающих примерно одинаковую зарплату, могут писать программы, отличающиеся по скорости счета, скажем, в 10 раз". Кстати, ситуация в России еще сложнее по сравнению с западными странами – российские программисты могут не только перейти на другую работу, но и переехать в другую страну с более высоким уровнем зарплаты!

18. Естественно, особенно важен подбор сотрудников для организаций первого уровня, так как сотрудники для них являются единственной гарантией качества. Но и на более высоких уровнях зрелости "человеческий фактор" сохраняет свою значимость. Поэтому в 1995 году был опубликован стандарт People CMM, являющийся дополнением к Software CMM и имеющий, в целом, похожую структуру. Внедрение этого стандарта параллельно с обычным CMM обеспечивает организацию целым набором процедур по оценке и развитию всей системы найма, обучения и сохранения квалифицированных сотрудников.

19. Кроме People CMM, возникло еще несколько моделей, дополняющих CMM, например, в приобретении ПО или разработке крупных систем. В целях полной интеграции этих моделей и снижения общих затрат по их внедрению, был предпринят проект CMM Integration (ради его выполнения в 1998 году был даже отменен выпуск CMM версии 2.0). К сожалению, использование CMM затрудняют следующие проблемы: стандарт CMM является собственностью Software Engineering Institute и не является общедоступным (в частности, дальнейшая разработка стандарта ведется самим институтом, без заметного влияния остальной части программистского сообщества); оценка качества процессов организаций может проводиться только специалистами, прошедшими специальное обучение и аккредитованными SEI; стандарт ориентирован на применение в относительно крупных компаниях;

20. SPICE В 1991 году Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов. Стандарт получил имя SPICE (сокращение от S oftware P rocess I mprovement and C apability d E termination, определение возможностей и улучшение процесса создания программного обеспечения). Официально стандарт называется "ISO/IEC 15504: Information Technology - Software Process Assessment" и на данный момент существует в качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года. Задачей SPICE является создание международного стандарта, в котором был бы учтен весь накопленный опыт в области разработки ПО. На рисунке 2 показаны наиболее значительные стандарты, идеи которых были использованы при создании SPICE:

21. Рисунок 2. Предшественники стандарта SPICE.

22. Итак, стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и уже упоминавшихся ISO 9001 и CMM. Для этого пришлось прибегнуть к повышению уровня детализации стандарта. Следствием такого основательного подхода является большой объем стандарта: документация к нему содержит около 500 страниц!

23. Больше всего SPICE напоминает CMM. Точно так же, как и в CMM, основной задачей организации является постоянное улучшение процесса разработки ПО. Кроме того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам. В таблице 1, заимствованной из статьи [6], приведен список уровней способностей модели SPICE и характерные для них процедуры управления. Отметим, что на данный момент не существует русского перевода стандарта SPICE, поэтому использованные термины не являются общепринятыми или официально зарегистрированными

24. Таблица 1. Уровни способностей процесса в стандарте SPICE Постоянное совершенствование 5.2 Изменение процесса 5.1 Оптимизирующий процесс Уровень 5 Управление процессом 4.2 Измерение процесса 4.1 Предсказуемый процесс Уровень 4 Отслеживание ресурсов процесса 3.2 Документирование процесса 3.1 Установленный процесс Уровень 3 Управление созданием продуктов 2.2 Управление производительностью 2.1 Управляемый процесс Уровень 2 Измерение производительности процесса 1.1 Выполняемый процесс Уровень 1 Процесс не выполняется Уровень 0 Название Уровни

25. Таким образом, процессы в модели SPICE могут быть представлены следующим образом: Рисунок 3. Упрощенная модель оценки процессов в стандарте SPICE. Здесь Pn обозначает процессы, а CL (Capability Levels) обозначает уровни способностей этих процессов.

26. Поэтому иногда говорят, что модель SPICE является двумерной – на одной оси откладываются процессы, а на другой оси – достигнутый уровень возможностей для этих процессов.

27. Во время оценки и улучшения качества процессов выполняются следующие задачи (см. рисунок 4): Рисунок 4. Основные элементы стандарта SPICE.

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

29. Скажем несколько слов о структуре документации по стандарту SPICE. Набор документов по SPICE состоит из 9 частей. Первая часть "Введение и основные концепции" и девятая часть "Словарь" носят чисто информативный характер. Самым важным элементом SPICE является оценка процессов, поэтому ей посвящена наибольшая часть документов, а именно части со второй по шестую. Например, вторая часть стандарта содержит так называемую "эталонную модель" (reference model), которая описывает процессы. Практически, это модель процессов из ISO 12297, хотя, к сожалению, эти модели не полностью идентичны. Результаты оценки процессов с помощью SPICE выглядят достаточно сложно и потому требуют некоторого упрощения для понимания неподготовленным человеком (например, такое упрощение было проделано при создании рисунка 3).

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

31. В таблице 2 кратко сформулированы преимущества SPICE по сравнению с ISO 9001. Может быть детализирован с помощью SPICE Дополняет ISO 9001 Только модель Требования к оценке процесса, руководство по применению Сертификация/отказ Шесть уровней возможностей процессов Только сертификация Улучшение процесса и определение возможностей Абстрактная модель Детальная модель Краткий документ Объемный и подробный документ ISO 9001 SPICE

32. SPICE предоставляет более полный набор средств по обеспечению качества и улучшению процессов, чем ISO 9001. Поэтому для обеспечения качества процессов разработки ПО мы рекомендуем использовать именно SPICE. Это поможет организации заметно улучшить существующие процессы, а затем при необходимости получить и сертификат ISO 9001. Накопленный опыт решения проблемы качества по такой схеме отражен в статье [7] (в частности, в ней сформулирован набор минимальных требований к различным процессам в организации согласно модели SPICE, достаточный для получения сертификата ISO 9001). Использовать SPICE можно и в небольших компаниях – об этом свидетельствуют результаты работы проекта SPIRE, в рамках которого проводилось внедрение процессов улучшения качества в малых (менее 50 человек) компаниях из различных стран Европы. Как показал этот опыт, и при небольших денежных вложениях в маленьких компаниях можно добиться существенного увеличения производительности труда и улучшения качества произведенных продуктов.

33. В связи со своей открытостью, стандарт SPICE популярен и по нему существует много свободно доступных материалов. Например, на официальном сайте SPICE любая организация может зарегистрироваться для участия в SPICE Trials (пробных применениях). В России стандарт SPICE пока еще делает только самые первые шаги. В октябре 1997 года в Санкт-Петербурге состоялся первый семинар, посвященный SPICE. Его организатором выступили финские компании SEC Oy и STTF Oy. С тех пор семинары по SPICE в Санкт-Петербурге проводятся этими компаниями не реже двух раз в год.

34. Заключение И CMM, и SPICE начинались как средства решения одной частной задачи – выбора наилучшего поставщика ПО. Однако эти модели переросли свои исходные предпосылки и успешно прошли путь от исследовательских разработок до мировых стандартов. На сегодняшний день они представляют наиболее развитые модели качества, прошедшие применение на практике. Описанные стандарты уже сегодня являются серьезной альтернативой для ISO 9000-9004, привлекая своими возможностями усовершенствования сертифицируемых процессов все новых и новых сторонников. Таким образом, соответствие стандарту перестает быть простым свидетельством достижения некоторого уровня качества и становится способом реального улучшения существующих на предприятии процессов.

35. Глоссарий :

36. Возможность процесса разработки ПО (software process capability) описывает ожидаемый результат, который можно достигнуть, следуя процессу разработки . Зрелость процесса разработки ПО (software process maturity) – это степень определенности, управляемости, измеряемости и эффективности процесса разработки ПО. Качество (quality) – степень соответствия системы, компоненты, процесса или службы потребностям и ожиданиям клиента или пользователя. Количественное управление процессом (quantitative process management) заключается в выявлении причин для особых отклонений процесса от планируемого и подобающего исправления этих причин (таким образом, качество процесса измеряется не в количестве написанных строк кода или найденных ошибок, а в соответствии процесса исходному плану). Обеспечение качества ПО (software quality assurance) предназначено для информирования руководства об успешности и зрелости процесса разработки ПО и конечных продуктах

37. Определение процесса (process definition) - это рабочее определение набора мер, необходимых для достижения намеченных целей. Характеризуется стандартами, процедурами, обучением, средствами и методами. Планирование проекта (software project planning) устанавливает разумные планы для разработки ПО, на основе которых производится управление программным проектом. Постоянное улучшение процессов (continuous process improvement) обеспечивает повышение производительности, качества продуктов и уменьшение цикла разработки ПО. Предотвращение дефектов (defect prevention) заключается в определении причин возникновения дефектов и в принятии мер по предотвращению их дальнейшего возникновения. Программный процесс (software process) – набор технологических процедур, используемых организацией для планирования, управления, выполнения, контроля и улучшения работ по созданию ПО.

38. Программный процесс (software process) – набор технологических процедур, используемых организацией для планирования, управления, выполнения, контроля и улучшения работ по созданию ПО. Производительность программного процесса (software process performance) представляет собой реальные результаты венедрения программного процесса. Управление качеством (software quality management) – это процесс, состоящий из численного измерения качества процесса разработки ПО, формулирования определенных целей по улучшению качества и их достижению. Управление конфигурацией ПО (software configuration management) создает и поддерживает целостность продуктов программного проекта в течение всего жизненного цикла ПО.

39. Управление изменениями технологий (technology change management) помогает определить и организованно внедрить на предприятии потенциально выгодные новые технологии (т.е. средства, методы и процессы). Управление программным проектом (software project tracking and oversight) состоит в отслеживании степени успешности и продвижении программного проекта и в принятии соответствующих мер при возникновении существенных отклонений проекта от плана. Управление субподрядчиками (software subcontract management) заключается в выборе квалифицированных субподрядчиков и эффективном управлении ими. Управление требованиями (requirements management) – это процесс приведения в соответствие представлений пользователя о желаемых результатах и формулируемых требований к разработчику программного проекта. Экспертная оценка программ (peer review) предназначена для эффективного и раннего обнаружения дефектов в ПО и может быть реализована с помощью просмотра исходных текстов, сквозного структурного контроля или иных методов коллективного изучения.

40. ISO 9000-9004

41. Стандарты серии ISO 9000 разработаны Международной Организацией по Стандартизации (ISO) и состоят из следующих частей: ISO 9000 "Общее руководство качеством и стандарты по обеспечению качества"; ISO 9001 "Система Обеспечения Качества: Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании"; ISO 9002 "Система Обеспечения Качества: Модель обеспечения качества при производстве, монтаже и обслуживании" ISO 9003 "Система Обеспечения Качества: Модель обеспечения качества при окончательном контроле и испытаниях"; ISO 9004 "Общее руководство качеством и элементы системы качества". Стандарты ISO 9000 и ISO 9004 – не более чем справочники. Стандартами соответствия являются только ISO 9001, 9002 и 9003. Таким образом, бессмысленно говорить о сертификации или регистрации по ISO 9000 или ISO 9004. Предприятие может получить только сертификаты на соответствие ISO 9001, 9002 или 9003.

42. Для организаций, занимающихся изготовлением программных продуктов, соответствующими стандартами являются ISO 9001 и ISO 9000-3 "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения". Стандарты ISO – дорогое удовольствие. Платным в этой системе является все: от самих стандартов до аудита и собственно сертификации.