Оценка качества процессов разработки ПО

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

• международные стандарты серии ISO 9000 (ISO 9000 - ISO 9004);

• СММ - Capability Maturity Model - модель зрелости (совершенствова­ния) процессов создания программного обеспечения, предложенная SEI (Software Engineering Institute - институт программирования при универси­тете Карнеги-Меллон);

• рабочая версия международного стандарта ISO/IEC 15504: Informa­tion Technology - Software Process Assessment; эта версия более известна под названием SPICE - (Software Process Improvement and Capability dEtermination - определение возможностей и улучшение процесса создания про­граммного обеспечения).

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

СММ. СММ представляет собой совокупность критериев оценки зрело­сти организации-разработчика и рецептов улучшения существующих про­цессов.

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

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

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

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

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

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

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

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

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

• насколько широко данная область применяется в организации, например, оценке в 4 балла соответствует фрагментарное применение;

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

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

SPICE. Стандарт SPICE унаследовал многие черты более ранних стан­дартов, в том числе и уже упоминавшихся ISO 9001 и СММ. Больше всего SPICE напоминает СММ. Точно так же, как и в СММ, основной задачей ор­ганизации является постоянное улучшение процесса разработки программ­ного обеспечения. Кроме того, в SPICE тоже используется схема с различны­ми уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.

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

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

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

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

Дата добавления: 2014-01-07