Стандарты ISO для разработки программного обеспечения

1) Процесс управления. Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.

2) Процесс создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

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

4) Процесс обучения. Определяет работы по соответствующему обучению персонала.

 

 

 

6. Управление конфигурацией в  стандартах CMM и ISO 12207

Определение конфигурации

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

Контроль  конфигурации

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

Учет  состояний конфигурации

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

Оценка  конфигурации

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

 

Управление  выпуском и поставка

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

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

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

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

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

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

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

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

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

(4) Управляемый уровень (managed level). Уровень, при котором устанавливаются количественные показатели качества.

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

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

Пока в России знают только аббревиатуру СММ, но не представляют себе, каким  образом можно добиться качественного  скачка. И дело не только в том, что  неизвестно направление этого скачка, а в том, что каждой отдельно взятой компании довольно трудно выстроить  свои процессы под требования CMM самостоятельно, без внешнего вмешательства. А зачем изобретать велосипед? Не проще ли взять готовый набор решений оптимизации (например, Rational Unified Process), внедрить его (здесь уже можно и своими силами обойтись), получив готовый набор решений для качественного построения ПО, а уж затем приглашать специалистов и аттестоваться на определенный уровень? Как мы уже не раз упоминали в данной статье, Rational гарантирует получение 3-го уровня СММ.

На Западе сегодня уже широко используют для оптимизации процесса выпуска ПО технологии компании Rational Software. Причин тому несколько: во-первых, Rational Software — практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (Rational Unified Process), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта. Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения качественных процессов варьируется от 5:1 до 8:1.

Configuration and Change Management с точки зрения CMM и RUP Итак, мы уже коснулись требований к качественности процессов, а сейчас рассмотрим, как RUP регламентирует достижение необходимого качества. Поговорим о той части RUP, которая описывает конфигурационное управление.

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

Конфигурационное управление участвует  в идентификации конфигурации выпускаемого ПО (то есть в выборе программного продукта и в его описании) в срок. SCM (Source Configuration Management) обеспечивает систематизированное управление изменениями конфигурации, поддержание их целостности и актуальности на протяжении всего жизненного цикла проекта. Результаты разработки, которые поставляются клиенту, находятся под управлением конфигурационной системы. Также под ее управлением находятся все документы и результаты компиляции (документы требований, отчеты, исходные данные на любом языке программирования).

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

Все данные из ключевых областей процесса (Key Process Area) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.

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

Ниже приведены требования CMM к  процессу конфигурационного управления. Это требования 2 и 3 уровней. Хочется отметить, что внедрение СС в соответствии с RUP автоматически дает уровень 3 качества процесса.

Цели процесса УК:

1. Управление конфигурацией происходит  на плановой основе;

2. Все изменения происходят  управляемо.

Обязательства по выполнению:

1. Проект следует документированной  организационной политике 

1.1. Есть ответственные за выполнение проекта

1.2. УК реализуется на протяжении  всего жизненного цикла 

1.3. УК реализуется для конечных  продуктов, промежуточных, экспериментальных  и перспективных 

1.4. Все проекты имеют собственный  репозиторий

1.5. На регулярной основе проводится  аудит базовых линий 

1.6. На регулярной основе проводится  аудит работ по управлению  УК 

2. Должна существовать комиссия  по управлению БЛ 

2.1. (задача 1) Санкционированное создание  БЛ 

2.2. (задача 2) Представлять интересы  менеджера проекта и групп   

2.3. (задача 3) Ревизия и изменение  БЛ 

2.4. (задача 4) Создание продуктов  из БЛ 

3. Необходима группа, отвечающая  за координацию и реализацию  УК 

3.1. Создание библиотеки БЛ и  управление ей 

3.2. Разработка, сопровождение и  распространение планов и стандартов  УК 

3.3. Идентификация набора продукта (под контролем)

3.4. Управление доступом к элементам 

3.5. Обновление БЛ 

3.6. Создание продуктов из БЛ 

3.7. Запись действий по УК 

3.8. Создание отчетов 

4. Работы по УК должны быть  обеспечены ресурсами 

4.1. Назначение менеджера УК 

4.2. Назначение администратора УК 

4.3. Работы обеспечены инстр. Средствами и аппаратурой 

5. Участники УК должны пройти  обучение целям, процедурам и  методам выполнения работ по  УК 

6. Члены группы разработки ПО  должны пройти обучение по выполнению своих задач

Операции:

1. Для каждого проекта готовится  план УК 

1.1. План разрабатывается на ранних  стадиях общего планирования  проекта 

1.2. План рассматривается задействованными  группами и рецензируется ими 

1.3. План должен быть доступен, управляем и конфигурируем

2. Документированный и утвержденный  план УК используется в качестве  основы для всех действий (охватывает  следующие вопросы) 

2.1. Выполняемые работы по УК

2.2. График работ 

2.3. Сферы ответственности 

2.4. Ресурсы