Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе (см. рисунок 3).
Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.
Работы по сопровождению в стандарте 14764 разбиты на задачи:
• Process Implementation - реализация процесса
• Problem and Modification Analysis - анализ проблем и <необходимых> модификаций
• Maintenance Review/Acceptance - оценка и принятие <проведенных работ> при сопровождении
• Migration - миграция (на модифицированную или новую версию программного обеспечения)
• Software Retirement - вывод из эксплуатации (прекращение эксплуатации программного обеспечения)
В представленных в SWEBOK источниках можно найти описание истории эволюции соответствующих процессных моделей упоминаемых стандартов ISO/IEC и IEEE. Кроме того, существует и общая (обобщенная) модель процессов сопровождения. Agile-методологии, активно развивающиеся в последние годы, предлагают “облегченные” (light или lightweight) процессы, в том числе, и для организации деятельности по сопровождению, например, Extreme maintenance (см. соответствующие источники, указанные в SWEBOK).
3.2 Работы по сопровождению (Maintenance Activities)
Как уже отмечалось, многие работы по сопровождению похожи на аспекты деятельности по разработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и документирование. Специалисты по сопровождению должны отслеживать требования так же, как и инженеры-разработчики и обновлять документацию по мере разработки и/или выпуска обновленных или новых релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или организации, отвечающие за сопровождение, в случае использования элементов процессов разработки в своей деятельности, адаптировали эти процессы <целиком> в соответствии со своими потребностями. В то же время, деятельность по сопровождению обладает и определенными уникальными чертами, что приводит к необходимости использования специализированных процессов.
3.2.1 Уникальные работы (Unique activities)
Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению. SWEBOK приводит следующие примеры такого рода уникальных характеристик:
за дальнейшую поддержку;
• Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection): запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по различным обоснованным причинам - объему и/или сложности требуемых изменений, а также необходимых для этого усилий. Соответствующие решения могут также приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе, отсутствия возможности привлечения разработчиков к решению задач по модификации, при реальном наличии такой потребности), утвержденной запланированности к реализации в следующем релизе и т.п..
• Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk): функция поддержки конечных пользователей, инициирующая работы по оценке (assessment, подразумевая в том числе оценку необходимости), анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.
• Анализ влияния (Impact Analysis): анализ возможных последствий изменений, вносимых в существующую систему - рассматривался выше в теме 2.1.3.
• Поддержка программного обеспечения (Software Support): работы по консультированию пользователей, проводимые в ответ на их информационные запросы (request for information), например, касающиеся соответствующих бизнес-правил (см. область знаний “Требования к программному обеспечению”), проверки, содержания данных и специфических (ad hoc) вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, непониманию аспектов работы с системой и т.п.).
• Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса - Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.
На практике сложно провести грань между разделяемыми в SWEBOK функциями Help Desk и Software Support -эти функции, обычно, совмещены с процессной точки зрения.
3.2.2 Дополнительные работы, поддерживающие процесс сопровождения (Support activities)
Столь длинный перевод названия данной темы связан с содержанием соответствующих работ, описываемых SWEBOK, как работы персонала сопровождения, не включающие явного взаимодействия с пользователями, но необходимые для осуществления соответствующей деятельности. К таким работам относятся: планирование сопровождения. Конфигурационное управление (software configuration management), проверка и аттестация (V&V - verification and validation), оценка качества программного обеспечения (software quality assessment), различные аспекты обзора, анализа и оценки (reviews), аудит (audit) и обучение (training) пользователей.
Также, к таким специальным (внутренним) работам относится обучение персонала сопровождения.
В силу особой значимости (с точки зрения автора - обязательности) ряда упомянутых работ, им посвящены следующие под-темы данной секции области знаний по сопровождению программного обеспечения.
3.2.3 Работы по планированию сопровождения (Maintenance planning activity)
Планирование является более чем необходимым для адекватного проведения работ по сопровождению и должно касаться связанных с этим вопросов с нескольких точек зрения:
• Бизнес-планирование (организационный уровень)
• Планирование непосредственных работ по сопровождению (уровень передачи программного обеспечения - см. выше 3.2.1)
• Планирование релизов/версий (уровень программного обеспечения)
• Планирование обработки конкретных запросов на изменение (уровень запроса)
На уровне индивидуального запроса, работы по планированию проводятся вместе с проведением анализа влияния (см. 2.1.3). В свою очередь, планирование релизов/версий требует от персонала сопровождения выполнения задач:
• Получения и сбора информации о датах размещения индивидуальных запросов и отчетов
• Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих релизов/версий программного обеспечения
• Идентификации потенциальных конфликтов и возможных альтернатив <реализации необходимых запросов>
• Оценки рисков для <функционирования> текущего релиза и разработки плана “отката” на немодифицированный (текущий, до внесения изменений, касающихся рассматриваемого запроса) вариант системы, в случае возникновения проблем, связанных с модификацией
• Информирования всех заинтересованных лиц
Несмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (что более типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) и активная эксплуатация систем занимает несколько лет, а то и более* (5-10-...). Проведение оценки ресурсов - неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics Methodology).
* эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он принимал непосредственное участие в проектировании и разработке системы автоматизации добровольного медицинского страхования (в одной из крупнейших российских страховых компаний), выведенной, в дальнейшем, из эксплуатации на рубеже 2000 года, то есть система функционировала около 7 лет, а некоторые ее фрагменты как самостоятельные приложения и того дольше. Многие банковские приложения, особенно, на западе, в первых своих версиях были разработаны еще в середине 80 -х, а некоторые ИТ-системы в мире были созданы (в своем изначальном варианте) и в 70-е годы, что, в частности, привело к усиленному вниманию к проблеме 2000 года (Y2K problem).
Вначале необходимо определить концепцию сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) должен касаться следующих вопросов:
• Содержания деятельности по сопровождению
• Адаптации процесса сопровождения
• Идентификации организации, которая будет заниматься сопровождением
• Оценки стоимости сопровождения
После разработки концепции деятельности по сопровождению должен быть сформирован соответствующий план сопровождения. Этот план должен подготавливаться одновременно с разработкой программной системы. План должен определять как пользователи будут размещать свои запросы на модификацию (изменения) или сообщать об ошибках, сбоях и проблемах. Вопросам планирования уделяют специальное внимание уже упоминавшиеся стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance). Стандарт ISO/IEC 14764 предоставляет специальные рекомендации (guidelines) по организации плана сопровождения.
Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе, профильное, если речь идет о потребителях ИТ) подразделение организации/компании. Необходимые знание в области управления также затрагиваются в области знаний SWEBOK “Связанные дисциплины”.
3.2.4 Конфигурационное управление (Software configuration management)
Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения, определяет конфигурационное управление как критически важный элемент процесса
сопровождения. Процедуры конфигурационного управления должны обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для идентификации, авторизации, реализации и выпуска программного продукта.
Более того, недостаточно просто отслеживать запросы на изменения и сообщения о проблемах (modification requests, problem reports). Должны быть контролируемы и сам программный продукт, и любые изменения (не только в коде, но документации, спецификациях и т.п., то есть любых активах продукта и проекта, прим. автора). Такой контроль устанавливается реализацией и строгим следованием утвержденным процессам конфигурационного управления (software configuration management, SCM). Область знаний “Конфигурационное управление” подробно описывает и обсуждает процессы, в соответствии с которыми, размещаются, оцениваются и утверждаются запросы на изменения. В ряде отдельных аспектов и характеристик, конфигурационное управление при сопровождении и разработке несколько отличается, что должно контролироваться уже на операционном уровне. Реализация SCM-процесса обеспечивается разработкой и следованием плану конфигурационного управления и соответствующим процедурам (operating procedures). Организация, подразделение или группа сопровождения (в лице представителей) участвует в работе часто формируемого органа Configuration Control Board, отвечающего за рассмотрение и принятие в работу запросов на изменения. Основной целью такого участия является, по мнению SWEBOK, определение содержания следующих релизов/версий.
3.2.5 Качество программного обеспечения (Software quality)
Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, качество программного обеспечения будет повышаться. Для поддержки процесса сопровождения должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а также аудиту, должны отбираться в контексте взаимодействия и согласования со всеми другими процессами, направленными на достижение желаемого уровня качества. SWEBOK, основываясь на стандарте ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance), рекомендует адаптировать соответствующие процессы, техники и активы, относящиеся к разработке программного обеспечения. К ним, например, относятся документация по тестированию и результаты тестов. Дополнительные подробности можно найти в соответствующей области знаний “Качество программного обеспечения” (Software Quality).
4. Техники сопровождения (Techniques for Maintenance)
Данная секция вводит некоторые общепринятые техники, используемые в процессе сопровождения программных систем.
4.1 Понимание программных систем (Program Comprehension)
Для реализации изменений программисты тратят значительную часть времени на чтение и формирование понимания программного продукта. Средства работы с кодом являются ключевым инструментом для решения этой задачи. Четкая, однозначная и лаконичная документация обеспечивает адекватное понимание программных систем.
4.2 Реинжиниринг* (Reengineering)
Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в новой форме (например, с использованием новых технологий и платформ, при сохранении существующей и расширением и облегчением возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют различные позиции в отношении реинжиниринга - одни считают, что реинжиниринг является наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры). Реинжиниринг, обычно, провидится не столько для улучшения возможностей сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK, формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами.
Необходимо отметить, что реализация продукта в новом качестве (форме) при сохранении основной функциональности оригинального продукта, является неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегося важной составной частью реинжиниринга.
4.3 Обратный инжиниринг[5] (Reverse engineering)
“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов (call graphs) и потоков управления (control flow graphs) на основе исходного кода системы. Один из типов обратного инжиниринга - создание новой документации на существующую систему (redocumentation). Другой из распространенных типов - восстановление дизайна системы (design recovery).
К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу (см. работы Мартина Фаулера, впервые систематизировавшего и описавшего рефакторинг). Рефакторинг - трансформация программного обеспечения, в процессе которой программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения поведения. Сохранение “формы” (платформы, архитектурных и технологических решений) существующей программной системы позволяет рассматривать рефакторинг как один из вариантов обратного инжиниринга.
* для обеих тем - 4.2 и 4.3 возможно применение слова реконструкция, в зависимости от контекста, означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/или доступным внешним признакам, где восстановление может подразумевать опять -таки создание нового образца или представления об оригинальной сущности.
В принципе, возможно объединение тем данной секции, включая реинжиниринг и обратный инжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной области знаний “Сопровождение”, с дальнейшей детализаций в виде “под-тем” 4.1.x. Такой подход соответствует структуре SWEBOK. При этом, соответствующая структура может быть организована, например, следующим образом:
• 4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе: включает восстановление, в первую очередь, бизнес- и функциональных требований к системе;
• 4.1.2 Восстановление детального дизайна системы: включает идентификацию всех компонентов системы и создание модели вызовов и других связей между компонентами;
• 4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, в частности для улучшения возможностей по ее дальнейшему сопровождению (включая модификацию, связанную с расширением функциональности);
• 4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме
(например, с использованием той же технологической платформы), что и текущая (эксплуатируемая) версия;
Лекция 7. Программная инженерия
Конфигурационное управление (Software Configuration Management)
Лекция базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK®, 2004. Содержит перевод описания области знаний SWEBOK® “Software Configuration Management”, с комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Oopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
Программная инженерия
Конфигурационное управление (Software Configuration Management)
5.3 Внутренние аудиты базовых линий (In-process Audits of Software Baseline)....................... 17
6. Управление выпуском и поставкой (Software Release Management and Delivery)................... 18
6.1 Сборка программного обеспечения (Software Building)..................................................... 18
6.2 Управление выпуском программного обеспечения (Software Release Management)........... 18
Система может быть определена как коллекция компонент, организованных для выполнения заданных функций или реализации комплекса функциональности (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology). Конфигурация системы - функциональные и/или физические характеристики аппаратного, программно-аппаратного, программного обеспечения или их комбинации, сформулированные в технической документации и реализованные в продукте. Конфигурация также может восприниматься как сочетание конкретных версий аппаратных, программно-аппаратных или программных элементов, объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих определенному назначению. Конфигурационное управление (CM - Configuration Management), в свою очередь, дисциплина идентификации конфигурации системы в определенные (заданные) моменты времени, с целью систематического контроля изменений конфигурации, а также поддержки и сопровождения целостной и отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла системы.
Конфигурационное управление формально определяется глоссарием IEEE 610 как “дисциплина приложения технических и административных указаний (инструкций) и контроля (надзора) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций, контроля (управления) изменений этих характеристик, записи (сохранения) и ведения отчетности по обработке изменений и статусу их реализации, а также проверки (верификации) соответствия заданным требованиям.”
В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное управление в области программного обеспечения (“6.2 Управление конфигурацией” по ГОСТ) - Software Configuration Management (SCM*) - один из вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих проектный менеджмент, деятельность по разработке и сопровождению, обеспечению качества, а также, заказчиков и пользователей конечного продукта.
* в ряде источников можно увидеть аббревиатуру SCCM - Software Configuration and Change Management. При том, что в понимании SWEBOK и соответствующих стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется для того, чтобы подчеркнуть принципиальную значимость управления изменениями как составной части конфигурационного управления.
Концепции конфигурационного управления применяются в отношении всех элементов, которые необходимо контролировать (несмотря на то, что существуют определенные отличия между конфигурационным управлением в приложении к аппаратному и программному обеспечению).
SCM-деятельность тесно связана с работами по обеспечению качества программного обеспечения (Software Quality Assurance - SQA). В соответствии с определением области знаний SWEBOK “Качество программного обеспечения” (Software Quality), SQA-процессы обеспечивают гарантию того, что программные продукты и процессы жизненного цикла в проекте соответствуют заданным требованиям, за счет планирования и выполнения работ, направленных на достижение определенного (приемлемого, прим. автора) уровня качества создаваемого программного продукта. SCM-деятельность помогает в достижении этих SQA-целей. В контексте некоторых проектов, определенные работы по конфигурационному управлению задаются требованиями SQA (например, в IEEE 730-02 “Standard for Software Quality Assurance Plans”).
Работы по конфигурационному управлению <программного обеспечения> включают: управление и планирование SCM-процессов, идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery).
На рисунке 1 изображено стилизованное представление этих работ.
Рисунок 1. Работы по конфигурационному управлению (SCM Activities) [SWEBOK, 2004, с.7-1, рис. 1]
Данная область знаний связана со всеми другими областями знаний и дисциплинами программной инженерии, так как объектами приложения SCM являются все артефакты, создаваемые и используемые в процессах программной инженерии.
К сожалению, SCM-деятельность во многих проектных командах сводится лишь к контролю версий (version control) исходных текстов и, в лучшем случае, документации (причем не проектной документации, в целом, а документации на создаваемое программное обеспечение). Попытка ограничить конфигурационное управление только вопросами контроля версий, в какой-то степени, является результатом непонимания того, что результаты проекта - это не только исходный код, исполняемые модули и пользовательская документация, но и все то, что создавалось (пусть и для решения тактических задач, как это часто бывает с некоторыми моделями и результатами пилотных работ по созданию прототипов) на протяжении всего проекта. Активами проекта (результатами, артефактами) являются и описания бизнес-процессов и бизнес-сущностей, и архитектурные модели, и требования, и план проекта/проектные задачи (как комплекс параметров, связанных с распределением ресурсов), и запросы на изменения (включая информацию о дефектах) и многое другое. Безусловно, упрощение вопросов конфигурационного управления до уровня управления версиями, с коньюктурной точки зрения, выгодно многим поставщикам соответствующих инструментальных средств. В определенных случаях, особенно, для малых проектов или временно используемых/”одноразовых” систем (например, по односторонней, “one-way” миграции данных из унаследованной системы в новую), упрощенный взгляд на конфигурационное управление может быть вполне обоснован. Однако, как это ни прискорбно, часто приходится наблюдать позиционирование такой, с позволения сказать, “практики”, как некоего “стиля гибкой работы”, подменяющей реальную динамику и гибкость agile-подходов (например, XP) отсутствием управления (важно понимать и помнить, что управление далеко не всегда является директивным), как такового (например, по определению содержания проекта на основе консенсуса проектной команды и вовлеченных в проектные работы представителей заказчика). В свою очередь, даже когда все активы проекта находятся под контролем соответствующих SCM-систем, необходимо осознавать, что конфигурационное управление предполагает постоянно действующий процесс, а не просто комплекс определенных периодически выполняемых операций. Только восприятие SCM- деятельности в качестве инфраструктурной основы процессов жизненного цикла может обеспечить эффективность управления программными проектами, то есть - достижение поставленных целей и создание результатов, удовлетворяющих заданным критериям. В то же время, конфигурационное управление - необходимое, но не достаточное условие, так как только совокупность процессов жизненного цикла, включая управление требованиями, проектирование и другие, не менее важные аспекты, определяют весь комплекс работ по созданию программных систем.
Рисунок 2. Область знаний “Конфигурационное управление” [SWEBOK, 2004, с.7-3, рис. 2] 1. Управление SCM-процессом (Management of SCM Process)
SCM-деятельность контролирует эволюцию и целостность продукта, идентифицируя его элементы, управляя и контролируя изменения, а также, проверяя, записывая и обеспечивая отчетность по конфигурационной информации. С инженерной точки зрения, SCM способствует разработке и реализации изменений. Успешное внедрение SCM требует точного планирования и управления. Это,
в свою очередь, предполагает понимание организационного контекста и тех ограничений, которые связаны с проектированием и реализацией процесса конфигурационного управления.
Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.
Рисунок 1. Работы по конфигурационному управлению (SCM Activities) [SWEBOK, 2004, с.7-1, рис. 1]
Рисунок 2. Область знаний “Конфигурационное управление” [SWEBOK, 2004, с.7-3, рис. 2] 1. Управление SCM-процессом (Management of SCM Process)