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

Виды оценки:

- оценка размера;

- оценка структуры;

- оценка качества и т.д.

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

2.5 Модели зрелости процессов

2.5.1 Что такое модель зрелости процессов?

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

В 1986 году SEI и корпорация Mitre под руководством Уоттса Хамфри (Watts Humphrey) приступили к разработке критериев оценки зрелости технологических процессов – Capability Maturity Model (CMM) [ссылка].

Далее события развивались в следующем порядке.

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

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

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

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

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

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

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

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

2.5.2 Что такое зрелость организации?

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

- отсутствует долговременное и проектное планирование;

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

- методы и процедуры не стандартизированы и не документированы;

- результат не предопределен реальными критериями, вытекающими из запланированных показателей, применения стандартных технологий и разработанных метрик;

- процесс выработки решения происходит стихийно, на грани искусства.

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

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

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

- эти процедуры постоянно уточняются и совершенствуются;

- оценки времени, сложности и стоимости работ основываются на накопленном опыте, разработанных метриках и количественных показателях, что делает их достаточно точными;

- актуализированы внешние и созданы внутренние стандарты на ключевые процессы и процедуры;

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

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

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

- активно апробируются и внедряются новые технологии, производится оценка их эффективности.

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

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

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

2.5.3 Пять уровней зрелости процессов

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

Рисунок 2.5 – 5 уровней зрелости организаций-разработчиков

Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process Area), содержащих цели (Goal), обязательства по выполнению (Commitment to Perform), осуществимость выполнения (Ability to Perform), выполняемые действия (Activity Performed), их измерение и анализ (Measurement and Analysis) и проверку внедрения (Verifying Implementation). Таким образом, СММ фактически является комплексом требований к ключевым параметрам эффективного стандартного процесса разработки ПО и способам его постоянного улучшения. Выполнение этих требований, в конечном счете, увеличивает вероятность достижения предприятием поставленных целей в области качества.