Модели оценки зрелости организаций разработчиков программных систем. Программные продукты. Базовые документы системы качества предприятия и жизненного цикла программного средства

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

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

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

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

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

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

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

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

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

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

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

При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

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

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

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

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

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

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

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

В настоящее время сложилось два почти независимых направления стандартизации в программной инженерии и обеспечении качества программных продуктов, которые условно можно назвать профилями стандартов ISO (Международной организации стандартизации) и моделями зрелости SEI (Института программной инженерии США). Первые достаточно полно представлены в [ , ], а вторые - в [ , ]. Именно моделям зрелости посвящено основное содержание статьи.

Для обеспечения конкурентоспособности в мире сложных программных продуктов и возможности их успешного экспорта они должны быть разработаны и сертифицированы в соответствии с требованиями профилей международных стандартов на базе ISO 9000:2000 или моделей зрелости - CMMI:2003 (Capability Maturity Model Integration - Интегрированная модель оценивания зрелости программной инженерии). Эти два направления методологически очень близки и частично пересекаются посредством взаимных ссылок.

Совершенствование технико-экономических показателей и качества программных продуктов, а также предотвращение ошибок и дефектов обеспечивается применением современных технологий программной инженерии и систем автоматизированного проектирования. Это высокопроизводительные, ресурсосберегающие технологии создания комплексов программ высокого качества, надежности и безопасности, имеющие своей целью сокращение общих затрат ресурсов на проектирование, реализацию и сопровождение программных средств (ПС). Для этого, прежде всего, необходимо применять методы и средства анализа и проектирования, обеспечивающие конкретизацию и максимально точное представление целей, назначения и функций с начала жизненного цикла (ЖЦ) ПС и предотвращающие распространение возможных системных дефектов на последующие этапы разработки. Такие технологии программной инженерии позволяют исключать или значительно снижать уровень системных, алгоритмических и программных ошибок в программных продуктах, передаваемых для эксплуатации. Кроме того, они эффективны при модификации и сопровождении ПС, а также при изменениях внешней среды.

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

Основой сертификации должны быть детальные и эффективные программы и методики испытаний комплексов программ на соответствие стандартизированным требованиям заказчиков, специально разработанные тестовые задачи и генераторы для их формирования, а также высокая квалификация и авторитет испытателей. Применение на предприятиях-разработчиках программных продуктов, сертифицированных систем качества обеспечения ЖЦ ПС на базе требований ISO 9000:2000 или CMMI:2003 , гарантирует высокое, устойчивое управление качеством процессов и продуктов их жизненного цикла, а также позволяет во многих случаях облегчать сертификацию конечного программного продукта. Поэтому заказчики сложных программных проектов стремятся выбирать подрядчиков-исполнителей, имеющих сертификаты, удостоверяющие применение ими систем гарантирования качества на основе адаптированных профилей международных стандартов или моделей зрелости.

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

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

Модель зрелости CMMI - 1.1 , уточняет и совершенствует предшествовавшие модели CMM (см. ), а также частично учитывает основные требования существующих международных стандартов в области менеджмента программных средств. Значительное внимание в CMMI уделяется процессам разработки и учету итераций при изменении требований заказчиков, их прослеживанию к функциям, компонентам, тестам и документам проекта. В последнее время появилась информация о модернизации институтом SEI версии 2003-го года CMMI - 1.1 на основе накопленного опыта и отзывов предприятий. Предполагается выпустить в 2006 году новую, существенно модернизированную, версию модели CMMI - 1.2 , после чего постепенно должно прекратиться применение версии 1.1. До конца 2007 года должен проводиться переход пользователей на версию CMMI - 1.2 , а в дальнейшем она станет обязательной для формализованной оценки качества (сертификации) технологии предприятий в области программной инженерии. При этом срок действия сертификата будет ограничен тремя годами. К этим изменениям следует готовиться заказчикам и разработчикам крупных ПС до официальной публикации институтом SEI версии 1.2.

Два варианта модели CMMI - 1.1 созданы для обеспечения непрерывного оценивания комплекса процессов в определенной области создания программных средств или для поэтапного оценивания и совершенствования зрелости предприятия, а также для организации ЖЦ комплексов программ в целом. Модели CMMI представляют помощь специалистам при организации и совершенствовании их продуктов, а также по упорядочению и обслуживанию процессов разработки и сопровождения ПС. Концепция этих моделей охватывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также процессов создания интегрированных программных продуктов и совершенствования их разработки. Компоненты непрерывной и поэтапной моделей в значительной степени подобны, могут выбираться и применяться в разном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов.

Варианты описания моделей построены по единой схеме, которая включает общие разделы:

• предисловие;
• 1 раздел - введение;
• 2 раздел - модель компонентов;
• 3 раздел - терминология;
• 4 раздел - содержание уровней и главные компоненты каждого варианта модели (разработка целей и процедур);
• 5 раздел - структура взаимодействия процессов; аннотированы четыре категории процессов раздела 7, их общий обзор и схемы взаимодействия CMMI процессов:
  • менеджмент процессов;
  • менеджмент - управление проектом;
  • инжиниринг (технология);
  • поддержка;
• 6 раздел - использование модели CMMI - краткие рекомендации для пользователей по применению модели и обучению; отмечается совместимость и соответствие процессов модели, с регламентированными процессами предыдущей модели СММ в части 2 и 3 стандарта ISO 15504 .
• 7 раздел - последний, самый большой в каждом стандарте, он занимает около 500 страниц из полного объема документа, который составляет свыше 700 страниц. В этом разделе представлены подробные рекомендации для реализации каждого из перечисленных в нем процессов, которые учитывают особенности конкретной модели.

Первый вариант (непрерывной) модели отражает документ: Capability Maturity Model Integration (CMMI) for Systems Engineering/ Software Engineering/Integrated Prod-uct and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Continuous ). Интегрированная модель оценивания зрелости инженерии систем/программной инженерии/интегрированных продуктов и процессов разработки - непрерывное представление . В этой модели седьмой раздел составляют процессы:

• менеджмент процессов:
  • организация обучения;
  • организация преобразования (изменений) процессов;
  • организация инноваций и расширений;
• управление проектом:
  • планирование проекта;
  • мониторинг и контроль процессов проекта;
  • управление рисками;
  • количественное управление проектом;
• инженерия (технология):
  • управление требованиями;
  • разработка требований;
  • технические решения;
  • интеграция продукта;
  • верификация;
  • валидация (аттестация, утверждение);
• поддержка:
  • управление конфигурацией;
  • анализ и принятие решений на изменения;
  • анализ причин и разрешение проблем (устранение дефектов).

В пяти приложениях приводятся:

А - состав использованных литературных источников и документов, в котором, однако, не упоминаются стандарты ISO ;

В - сокращения;

С - глоссарий на основе терминологии ISO , применяемой только в четырех стандартах ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288 ;

D - описания требований и предложений для формирования компонентов модели по уровням зрелости;

Е - список участников разработки CMMI - проекта.

В этой модели внимание акцентировано на организационных процессах, на планировании, управлении и контроле процессов реализации проектов программных средств, на разработке и управлении требованиями к программным продуктам. Ниже представлены примеры детализации в CMMI некоторых из них .

Планирование проекта в этой также как и во второй модели включает:

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

Процессы разработки требований к программному продукту аналогичны процессам в обеих моделях и включают:

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

Управление требованиями в обеих моделях включает:

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

Второй вариант представляет документ: Capability Maturity Model Integration (CMMI) for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, Staged ). Интегрированная модель оценивания зрелости инженерии сложных систем/программной инженерии/интегрированных продуктов и процессов разработки - поэтапное представление . Модель базируется на сохранении концепции пяти уровней зрелости CMM [ , ]. Состав процессов практически повторяет приведенный выше для первого варианта модели, но в несколько иной последовательности и с относительно небольшими дополнениями.

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

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

Приложения во втором варианте модели подобны по составу приведенным выше приложениям для первой модели. Рекомендуется на каждом более высоком уровне зрелости применять все процессы предыдущих нижних уровней. В обоих вариантах модели каждый, выделенный выше, базовый процесс комментируется подробными рекомендациями для его практической реализации, которые содержат унифицированные по структуре описания объемом около 20 - 30 страниц:

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

Эти рекомендации по объему, содержанию и полноте описаний базовых процессов подобны ряду стандартов профиля ЖЦ ПС, представленного в . Упорядочение и оценка полноты используемых процессов в соответствии с уровнями зрелости, позволяет устанавливать производственный потенциал предприятий - разработчиков программных продуктов по прогнозируемому качеству процессов и результатов их деятельности и готовности к сертификации на соответствие определенному уровню зрелости модели CMMI - 1.1.

Особое внимание в моделях CMMI уделяется процессам менеджмента проекта ПС. Эти требования и процессы моделей практически соответствуют регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000 и основных компонентах профиля стандартов жизненного цикла сложных ПС [ , ]. Требованиям к процессам в функциональных разделах 4-8 стандартов ISO 9001, ISO 9004, ISO 90003 может быть сопоставлен адекватный по содержанию ряд разделов в модели CMMI (на Рис. 1 зона перекрытия содержания). Общность процессов и требований состоит в подобии: состава, терминологии, структуры, перечня рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов программной инженерии, оценивания и организации специалистов.

Рисунок 1. Общность процессов и требований стандартов и моделей зрелости

С точки зрения поддержки и регламентирования полного жизненного цикла крупных проектов программных средств к недостаткам моделей CMMI относительно профиля существующих стандартов ISO можно отнести следующие:

Для определения представленных выше уровней зрелости процессов обеспечения жизненного цикла ПС разработан и первоначально утвержден в 1998 году обширный технический отчет ISO 15504 , состоящий из девяти частей и множества приложений. В нем изложены модель зрелости CMM и восемь базовых принципов программной инженерии на основе стандарта ISO 9000:2000 . Затем в ISO этот документ претерпел коренную переработку, сокращение, упрощение структуры и содержания, при полном сохранении целей и концепции, и утвержден как стандарт в составе пяти частей.

Стандарт ISO 15504:1-5:2003-2006 регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями:

• для установления состояния собственных технологических процессов и их совершенствования;
• для определения пригодности собственных процессов для выполнения определенных требований или классов требований заказчиков;
• с целью его пригодности для выполнения определенных договоров с заказчиками ПС и систем.

Стандарт способствует: самоаттестации зрелости предприятий, обеспечению адекватного управления аттестуемыми процессами, определению профиля рейтингов процессов, а также подходит к любым сферам применения и размерам ПС и систем. Применение стандарта направлено на выработку предприятиями и специалистами культуры постоянного совершенствования зрелости технологий обеспечения ЖЦ ПС, отвечающих бизнес-целям проектов и оптимизации использования доступных ресурсов. Аттестация зрелости процессов предприятий обеспечивает возможность их сопоставления и выбора, предпочтительных для определенных проектов:

• для заказчиков, покупателей, пользователей программных продуктов и систем: способность определять текущую и потенциальную зрелость процессов жизненного цикла у поставщика;
• для поставщиков и разработчиков: способность определять текущую и потенциальную зрелость собственных процессов жизненного цикла ПС и систем, области и приоритеты усовершенствования процессов;
• для аттестаторов зрелости: основу для проведения и совершенствования процессов аттестации.

Аттестация в стандарте рассматривается в двух аспектах : для усовершенствования процессов ЖЦ ПС и систем конкретного предприятия и для определения соответствия декларированной зрелости процессов обеспечения проекта или предприятия реальным используемым процессам. Это отражено в следующих пяти частях стандарта ISO 15504:1-5:2003-2006 .

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

Часть 2 - Выполнение (производство) аттестации. Включает детальные требования к проведению процессов аттестации как основы для совершенствования и определения уровня зрелости технологических процессов обеспечения ЖЦ ПС и систем. Документ определяет процессы выполнения аттестации, модели рекомендуемых процессов аттестации и верификации процессов, с тем чтобы они были объективными, содержательными и репрезентативными.

Часть 3 - Руководство по производству аттестации. Содержит обзор технологии выполнения процессов аттестации зрелости и интерпретации реализации требований. В нем отражено: исполнение аттестации; измерительные средства для определения процессов зрелости; выбор и применение средств аттестации; оценка компетентности аттестаторов; верификация соответствия аттестации декларированным требованиям. Средства аттестации могут использоваться предприятиями при планировании, менеджменте, мониторинге, контроле и усовершенствовании программных продуктов и систем, при их приобретении, разработке, применении и сопровождении.

Часть 4 - Руководство пользователей для процессов усовершенствования и определения зрелости процессов по этим двум аспектам. Рекомендуется ряд шагов, которые включают: применение результатов процессов аттестации; постановка целей аттестации зрелости; определение исходных данных для аттестации; оценка возможного снижения результирующих рисков; шаги по усовершенствованию процессов; шаги по определению уровня зрелости; сравнение результатов анализа аттестации с требованиями.

Часть 5 - Образец модели процессов аттестации на соответствие требованиям, представленным в части 2. Обширный документ (162 стр.) содержит примеры практического применения предыдущих частей стандарта для организации, оценивания и совершенствования аттестации зрелости процессов жизненного цикла для различных областей использования, проектов программных средств и предприятий.

При практической реализации проектов и обеспечении жизненного цикла сложных ПС разработчикам и поставщикам иногда трудно определить и выделить для применения преимущества моделей CMMI . В зависимости от традиций предприятия и особенностей крупного проекта ПС зачастую целесообразно использовать как основной полный профиль стандартов ISO , а для оценивания заказчиками уровня зрелости менеджмента, организационного и технологического обеспечения проектов ПС применять конкретные рекомендации CMMI . Эти рекомендации могут эффективно использоваться при сертификации качества процессов на предприятиях, обеспечивающих ЖЦ ПС, как альтернатива или наряду с сертификацией по комплексу стандартов менеджмента ISO 9000 , в зависимости от особенностей проекта и требований заявителя на сертификацию программного продукта или технологии обеспечения его жизненного цикла.

Сертификация состоит из ряда организационных процессов, составляющих систему сертификации , эти процессы поддерживаются регламентированными процедурами и документами и должны выполняться квалифицированными, аттестованными экспертами - инспекторами. Для сертификации предприятия-разработчика и результатов его деятельности - программных продуктов, моделями CMMI или профилями стандартов ISO [ , ] рекомендуется определенная дисциплина, которая должна быть адаптирована к конкретным характеристикам объектов и внешней среды жизненного цикла ПС. Перечисленные ниже процессы и документы ориентированы на крупные проекты, и их состав может сокращаться по согласованию между разработчиками, заказчиками и сертификаторами в более простых случаях.

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

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

Руководство по качеству содержит изложение принципов, описание методов и процедур, связанных с выполнением основных функций и задач органа по сертификации или лаборатории, обеспечивающих качество проводимых испытаний и доверие к результатам оценок, испытаний и экспертиз. Руководство по качеству, как правило, включает разделы [ TWLSC$

• политика в области обеспечения качества проведения испытаний и экспертиз;
• оснащение центра актуальными методологическими материалами и программно-инструментальными средствами испытаний;
• формализация требований к объектам испытаний;
• политика в области технической оснащенности центра и повышения квалификации персонала;
• архивация и контроль сохранности документации результатов сертификации.

Заявитель для оценивания продукции или процесса, подлежащих сертификации, направляет в орган по сертификации заявку по форме, принятой в системе сертификации. Орган по сертификации проводит работу по подготовке и организации сертификации продукции по заявке. Эта работа включает в себя:

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

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

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

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

Процесс сертификации программных продуктов и систем качества предприятия включает:

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

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

• наличия и полноты технологической документации и соблюдения её требований на практике;
• состояния средств технологического оснащения и наличия системы их технического обслуживания;
• наличия и эффективности системы контроля и испытаний;
• состояния средств измерений и испытаний;
• наличие системы выявления и устранения выявленных недостатков продукции или технологии.

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

После получения и проверки комплектности и качества документации специалистами испытательной лаборатории следует провести экспертизу степени реального применения системы качества на предприятии. Испытания начинаются с составления программы проверки системы качества, которая должна служить рабочим планом проведения последующих работ. Программа является внутренним рабочим документом испытательной лаборатории и должна содержать перечень работ, детализируемый в соответствии со спецификой предприятия-разработчика и включающий в себя анализ полноты и качества представленных исходных документов и степени их практического применения при проектировании, разработке и поставке ПС. Экспертиза применения процедур системы качества осуществляется испытательной лабораторией на рабочих местах предприятия, обеспечивающего ЖЦ ПС. Проверки проводятся по наличию на рабочих местах специалистов-разработчиков соответствующих документов и по полноте использования их положений и рекомендаций. Анализы состояния проекта и внутренние проверки системы качества, процессов и/или продукции должны проводиться персоналом, независимым от лиц, непосредственно ответственных за выполнение этих работ.

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

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

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

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

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

За сертифицированными программными продуктами в процессе их эксплуатации в течение всего срока действия сертификата соответствия должен осуществляться инспекционный контроль . Инспекционный контроль проводится в форме периодических и внеплановых проверок соблюдения требований к качеству технологии и сертифицированной продукции. Объектами контроля, в зависимости от схемы сертификации, является сертифицированная продукция, система качества или стабильность производства предприятия-разработчика. При определении периодичности и объема инспекционной проверки учитываются следующие факторы: степень потенциальной опасности программного продукта, стабильность производства, объем выпуска, наличие и применение системы качества при разработке, информация о результатах испытаний продукта и его производства, проведенных изготовителем, органами государственного контроля и надзора.

Результаты инспекционного контроля оформляются актом , в котором дается оценка результатов испытаний образцов и других проверок, делается общее заключение о состоянии производства сертифицированной продукции и возможности сохранения действия выданного сертификата. Акт хранится в органе по сертификации, а его копии направляются разработчику и в организации, принимавшие участие в инспекционном контроле. По результатам инспекционного контроля орган по сертификации может приостановить или отменить действие сертификата и аннулировать лицензию на право применения знака соответствия в случае несоответствия продукции требованиям нормативных документов, контролируемых при сертификации, а также в случаях:

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

Решение о приостановлении действия сертификата и лицензии на право применения знака соответствия не принимается в том случае, если путем корректирующих мероприятий, согласованных с органом по сертификации, его выдавшим, заявитель может устранить обнаруженные причины несоответствия и подтвердить без повторных испытаний в аккредитованной лаборатории, соответствие продукта или процессов нормативным документам. Если этого сделать нельзя, то действие сертификата отменяется, и лицензия на право применения знака соответствия аннулируется. Информация о приостановлении или отмене действия сертификата доводится органом по сертификации, его выдавшим, до сведения заявителя, потребителей и других заинтересованных организаций. Действие сертификата и право маркирования продукции знаком соответствия могут быть возобновлены при выполнении предприятием-разработчиком следующих условий:

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

Состав и содержание документации для сертификации системы качества предприятия зависят от характеристик проектирования, разработки и модификации программных средств, а также от требований к их качеству и особенностей технологической среды. Поэтому необходимый комплект документов для каждого предприятия или проекта следует выбирать и адаптировать применительно к этим характеристикам. Оцениваемыми при сертификации показателями системы качества являются наличие соответствующих документов и практическое выполнение требований определенного уровня модели зрелости СММI или адаптированного профиля стандартов на базе ISO 9000:2000 , а также, созданных на их основе, должностных инструкций специалистами предприятия-разработчика. Заявитель должен подготовить и предъявить испытательной лаборатории согласованный между заказчиком и разработчиком и утвержденный комплект документов для проверки их достоверности, достаточности состава и качества изготовления в соответствии с нормативными документами.

Ориентировочный комплект основных документов при сертификации состоит из трех групп:

• базовые нормативные документы систем качества в соответствии с номенклатурой и содержанием профиля стандартов на базе ISO 9000:2000 или модели зрелости СММI , а также подготовленные разработчиками на их основе программа, руководство и инструкции, предъявляемые испытателям (экспертам) системы качества или продукции проверяемого предприятия;
• исходные документы, характеризующие конкретное предприятие или проект, а также жизненный цикл программного средства, подготавливаемые руководством проекта для сертификации его качества;
• отчетные документы испытателей, отражающие результаты проверки (сертификации) системы качества предприятия и/или программного продукта, представляемые органу сертификации, заявителю и руководству проверяемого предприятия.

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

В.В. Липаев -- Профили стандартов жизненного цикла программных средств. -- Jet Info, Информационный бюллетень , N 12 , 2005

К. Мильман, С. Мильман -- СММI - шаг в будущее. -- Открытые системы. , N 5-6.(2005), N2.(2006) , 2005, 2006

Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем ISO IEC TR 15504-CMMI. Пер. с англ -- М.: Книга и бизнес , 2001

В.В. Липаев -- Процессы и стандарты жизненного цикла сложных программных средств. Справочник. -- М.: СИНТЕГ , 2006

В.В. Липаев -- Методы обеспечения качества крупномасштабных программных средств. -- М.: РФФИ. СИНТЕГ , 2003

"; antisource: "Программные продукты сейчас применяются для решения задач управления практически во всех сферах деятельности человека: в экономике, социальной, военной и других областях. Обеспечение высокого качества отечественных программных продуктов при их массовой разработке и поставке для различных сфер применения в стране и на мировом рынке стало стратегической задачей."; condition: 1]$

В 1982 году Министерство обороны США образовало комиссию, основной задачей которой стало исследование проблем, возникающих при разработке программных продуктов в организациях министерства. В результате деятельности комиссии в декабре 1984 году был создан Институт инженеров-разработчиков программного обеспечения ( Software Engineering Institute, SEI ) на базе Университета Карнеги-Меллона в Питсбурге.

1987 г. SEI публикует: краткое описание структуры CMM ; методы оценки процессов разработки ПО ; методы оценки зрелости процессов производства ПО ; анкету для выявления степени зрелости процессов (для проведения самостоятельного, внутреннего аудита и внешнего аудита).

1991 г. Выпуск версии CMM v1.0.

1992 г. Выпуск версии CMM v1.1.

1997 г. Выпуск очередной (усовершенствованной) версии CMM .

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. Для этого предполагалось создать критерии оценки зрелости ключевых процессов компании-разработчика и определить набор действий, необходимых для их дальнейшего совершенствования. В итоге методология оказалась чрезвычайно полезной для большинства компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования программных средств и свести управление ими к понятным и легко реализуемым алгоритмам и технологиям, описанным в едином стандарте.

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

Для оценки степени готовности предприятия разрабатывать качественный программный продукт СММ вводит ключевое понятие зрелость организации ( Maturity ). Незрелой считается организация, в которой:

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

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

Основные признаки зрелой организации:

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

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

Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process

Эволюцию моделей обеспечения качества рассмотрим на основе "модели зрелости процесса", или "модели совершенствования возможностей" СММ (Capability Maturity Model). Несмотря на то что модель СММ направлена на обеспечение качества программного обеспечения, ее методологические аспекты применимы к моделям обеспечения качества любой продукции (товаров, работ, услуг).

Главным в модели СММ является понятие зрелости организации.

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

Зрелой считается организация, в которой выполняются следующие условия:

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

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

Рис. 5.3. Пять уровней зрелости модели СММ

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

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

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

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

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

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

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

Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.

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

Оценка технологической зрелости компаний может использоваться:

· заказчиком при отборе лучших исполнителей (например, в тендере);

· компаниями-производителями ПО для систематической оценки состояния своих технологических процессов и выбора направлений их совершенствования;

· компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;

· аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;

· консалтинговыми фирмами, занимающимися реструктуризацией компаний и служб поставщиков информационных технологий и связанных с ними услуг.

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

Зрелость процессов (software process maturity) - это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.

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

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

Начиная с 1990 г. SEI при поддержке правительственных структур США и организаций-разработчиков ПО постоянно развивает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.

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

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

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

Рис. 1.7. Пять уровней технологической зрелости СММ

Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.

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

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

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

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

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

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

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas - КРА). Модель СММ содержит 18 таких групп, последняя версия модели CMMI - 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

· управление требованиями;

· управление конфигурацией;

· планирование проекта;

· мониторинг и контроль проекта;

· управление контрактами;

· измерения и анализ;

· обеспечение качества процесса и продукта.

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

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

На данном уровне к процессам уровня 2 добавляются следующие процессы:

· спецификация требований;

· интеграция продукта;

· верификация;

· аттестация;

· стандартизация процессов организации;

· обучение;

· интегрированное управление проектом;

· управление рисками;

· анализ и принятие решений.

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, - группа по разработке процессов создания ПО (software engineering process group - SEPG).

На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО» (project"s defined software process).

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

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

На уровне 4 добавляются следующие процессы:

· управление производительностью и продуктивностью;

· количественное управление проектом.

На этом уровне на практике применяется детальная оценка качества как процессов создания, так и самого создаваемого программного продукта. При этом применяются количественные критерии оценки.

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

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

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

На уровне 5 добавляются следующие процессы:

· внедрение технологических и организационных инноваций;

· причинно-следственный анализ и разрешение проблем. Процессы создания и сопровождения ПО характеризуются

как последовательно совершенствуемые, поскольку организация прилагает постоянные усилия по их модернизации. Это совершенствование распространяется как на выявление дополнительных возможностей используемых процессов, так и на создание новых оптимальных процессов и использование новых технологий.

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

Каждый последующий уровень дополнительно обеспечивает более полную обозримость самих процессов создания и сопровождения ПО.

На первом уровне процессы являются аморфными («черными ящиками»), и их обозримость весьма ограничена. С самого начала состав и назначение операций практически не определены, что порождает значительные трудности в определении состояния проекта и его продвижения. Требования по выполнению процессов задаются бесконтрольно. Разработка ПО в глазах менеджеров (особенно тех, кто сам не является программистом) иногда выглядит как черная магия.

На втором уровне выполнение требований пользователя и создание ПО контролируемы, поскольку определена база для процессов управления проектом. Процесс создания ПО может рассматриваться как последовательность «черных ящиков», которые можно контролировать в точках перехода из одного «ящика» в другой - зафиксированных этапах. Даже если руководитель не знает, что делается «внутри ящика», точно установлено, что должно получиться в результате выполнения процесса, и определены контрольные точки его начала и завершения. Поэтому управление может распознавать проблемы в точках взаимодействия «черных ящиков» и своевременно на них реагировать.

На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкретных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стандартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведения о его текущем состоянии.

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

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

Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого - 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.

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

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

С 2002 г. официально распространяется специальная интеграционная версия CMMI. Это новая разработка SEI, охватывающая все аспекты деятельности компании: от разработки и выбора подрядчика до обучения, внедрения и сопровождения. Кроме того, модель CMMI расширена подходами из системной инженерии. В эту модель вошли наработки, сделанные в ходе проектирования версии СММ 2.0 (она не была закончена), основные изменения в которой были направлены на уточнение процессов для компаний четвертого и пятого уровней, что наиболее актуально для крупномасштабных американских проектов.

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

К недостаткам СММ относятся следующие:

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

2. В модели отсутствует анализ рисков и решений, что не позволяет обнаруживать проблемы прежде, чем они окажут воздействие на процесс разработки.

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

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

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

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

2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними.

3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).

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

Эту классификацию не назовешь четкой и исчерпывающей - некоторые процессы могут одновременно относиться к нескольким типам. Например, неформальность процесса является выбором команды разработчиков. Эта же команда может выбрать определенную методику разработки, имея при этом все возможности непосредственного совершенствования процесса. Такой процесс подпадает под классификацию неформальный, методически обоснованный, непосредственного совершенствования.

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

Рис. 1.8. Применимость процессов совершенствования

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

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

Модель СММ не уникальна. Почти каждая крупная компания развивает собственные технологии создания ПО, иногда эти технологии становятся общедоступными и очень популярными. Широкая известность модели СММ связана с ее государственной поддержкой, но реальная эффективность СММ критикуется многими ведущими экспертами. Один из основных недостатков СММ связан с излишне жестким требованием не отклоняться от принципов данной модели, даже если здравый смысл подсказывает обратное. Подобные претензии на владение абсолютной истиной не могут не вызвать настороженности, поэтому в среде малых и средних компаний более популярны подходы, оставляющие гораздо больше свободы для индивидуального и коллективного творчества. Рассматриваемая далее методика SPMN занимает промежуточное место между жесткими, «тяжелыми», эффективными для крупных организаций решениями типа СММ и максимально гибкими технологиями. Она представляется оптимальным вариантом для фирм, которые, с одной стороны, хотят как можно быстрее упорядочить свою управленческую деятельность, а с другой стороны, планируют в перспективе выйти на международный уровень, где сертификация по СММ крайне желательна.