Реализация стандарта ГОСТ Р ИСО/МЭК 14764-2002 «Сопровождение программных средств» на основе технологии RUP

Галахов И.В., Лапыгин Д.В., Позин Б.А., Шкляева Н.А.
rational@sibintek.ru
www.sibintek.ru

Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем"
www.osp.ru
www.fostas.ru

Введение

Стандарт ГОСТ Р ИСО/МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12207» стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения « D » к ГОСТ Р ИСО/МЭК ТО 15271-2002 - «Пример сопровождения».

В последнее время все большим интересом у наших заказчиков пользуется процесс сопровождения ПС. До недавнего времени при его внедрении на основе стандарта ГОСТ Р ИСО/МЭК 12207 детализацию основных положений процесса сопровождения приходилось выполнять на основе различных международных источников и собственного опыта. Новый СТАНДАРТ детализирует процесс сопровождения, установленный в ГОСТ Р ИСО/МЭК 12207, и содержит рекомендации по планированию и выполнению процесса сопровождения, контролю и надзору за ним, его оценке и завершению. СТАНДАРТ устанавливает основную структуру процесса сопровождения ПС, но не определяет подробности реализации или выполнения работ и задач, входящих в данный процесс.

СТАНДАРТ предназначен для организаций, сопровождающих ПС или отвечающих за разработку и качество ПС, и детализирует требования к:

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

СТАНДАРТ не предназначен для готовых программных продуктов, если они не входят в состав ПС в качестве его элементов. Далее будет представлена методика постановки процесса сопровождения на основе СТАНДАРТА и технологии RUP , используемой для адаптации процесса сопровождения к потребностям конкретной организации.

Ключевые особенности Rational Unified Process (RUP)

Выбор технологии RUP для реализации СТАНДАРТА и его адаптации к нуждам конкретной организации обусловлен тем, что RUP:

1. основан на ГОСТ Р ИСО/МЭК 12207
2. структурные элементы RUP соответствуют основным структурным элементам СТАНДАРТА, таким как:
   • Процесс;
   • Работа;
   • Задача;
   • Входные/выходные артефакты RUP , которые соответствуют входным/выходным документам СТАНДАРТА;
   • Ролевые функции.
3. Взаимосвязи между структурными элементами соответствуют их взаимосвязям в СТАНДАРТЕ;
4. Удобство RUP при адаптации процессов к потребностям заказчика:
   • добавление, изменение или удаление любых структурных элементов;
   • наличие дополнительных структурных элементов, таких как шаблоны артефактов, облегчающих детализацию процессов и их адаптацию;
   • наличие инструментальных средств, позволяющих автоматически создавать веб-сайты с подробным описанием адаптированных процессов, которые удобно использовать в качестве справочно-методического пособия.

Технология адаптации

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

Основное правило, используемое при адаптации СТАНДАРТА для внедрения процесса сопровождения у заказчика - все положения стандарта используются без изменений. Они могут быть дополнены, детализированы или просто могут не использоваться, но если используются, то в том виде, как это определено в стандарте.

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

• Определение положений СТАНДАРТА, на основе которых будет строиться процесс сопровождения;
• Детализация положений СТАНДАРТА до уровня последовательности выполнения работ и задач процесса сопровождения с указанием входных и выходных артефактов для каждой задачи.
• Определение взаимодействия процесса сопровождения с другими процессами ЖЦ ПС, используемыми в организации (если в организации определены другие процессы ЖЦ ПС);
• Определение ролевой структуры ответственности за выполнение работ;
• Разработка шаблонов артефактов;
• Привязка ролевой структуры к организационной структуре организации;
• Выбор инструментальных средств и разработка процедур автоматизации процесса сопровождения;
• Ввод в действие процесса сопровождения.

Взаимодействие с другими процессами ЖЦ ПС

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

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

Рисунок 1 - Использование задачи процесса разработки в процессе сопровождения.

Ролевые функции и организационная структура

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

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

Рисунок 2 - Привязка организационной структуры к ролевым функциям процесса.

В СТАНДАРТЕ ролевые функции в явном виде не вводятся, хотя в тексте использованы термины «заказчик», «разработчик», «сопроводитель», «поставщик», к которым относятся требования по сопровождению ПС. Поэтому при адаптации СТАНДАРТА рекомендуется использовать за основу ролевую структуру, существующую в RUP, дополнив ее функциональными требованиями к ролям из СТАНДАРТА. Например, требования к «сопроводителю» обычно распределяются между такими ролями как «менеджер по сопровождению», «менеджер по управлению требованиями» и «менеджер по конфигурационному управлению».

Роль артефактов в процессе адаптации

В СТАНДАРТЕ представлены два вида артефактов, используемых в задачах процесса сопровождения - входные и выходные. На основании СТАНДАРТА можно выделить ряд документов(артефактов), рекомендуемых к использованию в процессе сопровождения, например, «концепция сопровождения», «программное средство», «исходные программы», «уведомление о завершении переноса» и т.п.

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

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

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

Использование инструментальных средств при адаптации и реализации процесса сопровождения

Использование инструментальных средств при адаптации и реализации СТАНДАРТА преследует следующие цели:

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

В проектах внедрения процесса сопровождения ЖЦ ПС целесообразно использовать инструментальные средства фирмы Rational/IBM, представленные в Таблице 1.

Таблица 1. Использование инструментальных средств при адаптации и реализации СТАНДАРТА

Инструментальное средство	Адаптация процесса	Реализация процесса
Rational Process Workbench	Автоматическая генерация контента веб-сайта
Rational Rose	Разработка модели процесса сопровождения	Выполнение задач проектирования в процессе сопровождения
Rational SoDA	Создание отчетов на основании данных, содержащихся в репозиториях инструментальных средств Rational	Создание отчетов на основании данных, содержащихся в репозиториях инструментальных средств Rational
Rational ClearCase	Выполнение задач конфигурационного управления при адаптации	Выполнение задач конфигурационного управления в процессе сопровождения
Rational ClearQuest	Выполнение задач управления изменениями при адаптации	Выполнение задач управления изменениями в процессе сопровождения
Rational RequisitePro	Выполнение задач управления требованиями при адаптации	Выполнение задач управления требованиями в процессе сопровождения
Rational TeamTest		Выполнение задач тестирования в процессе сопровождения

Оформление разработанных материалов в виде веб-сайта

Описание разработанного процесса сопровождения оформляется в виде веб-сайта, доступного в качестве справочно-методического материала для всех участников процесса сопровождения. Сайт вводится в действие до начала внедрения процесса сопровождения.

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

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

Сведения об авторах:

Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК в г. Москва.

• Галахов И.В. - начальник управления;
• Лапыгин Д.В. - главный специалист;
• Позин Б.А. - директор по консалтингу и методологии;
• Шкляева Н.А. - старший специалист.

rational@sibintek.ru
www.sibintek.ru

Другие статьи авторов:

1. Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational
2. Автоматизированное тестирование при разработке ПО