Стандартизация и информатизация

После начала процесса сертификации исправления к программному обеспечению и/или документации не принимаются.

5. Результаты сертификации.

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

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

Программное обеспечение, прошедшее сертификацию,  маркируется знаком соответствия.

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

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

6. Срок действия сертификата.

Прекращение действия сертификатов определяется на основании соответствующего решения совета директоров  о внесении изменений и дополнений в "Требования к программному обеспечению".

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

5.Основы    обеспечения качества сложных программных средств.

Планирование и управление качеством программных средств. Три источника и три составные части процесса создания качественного ПО.

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

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

Однако время не стоит на месте, и методики, положенные в основу стандартов серии ISO 9000, постепенно устаревают. Выделим наиболее существенные недостатки:

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

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

 отсутствие в стандарте механизмов, способствующих улучшению существующих процессов.

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

Подчеркнем сходства и различия между  двумя рассматриваемыми стандартами и ISO 9001.

Capability Maturity Model

Официальная история CMM (Capability Maturity Model, что обычно переводят как "модель зрелости процесса разработки ПО", хотя более верным по смыслу был бы перевод "модель совершенствования возможностей") начинается в 1991 году, когда американский институт SEI (Software Engineering Institute – Институт системного программирования при университете Карнеги-Меллон) опубликовал первую версию этого стандарта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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