Стандарты, поддерживающие управление версиями в жизненном цикле сложных программных средств
Эти стандарты являются фрагментами базовых стандартов, призванные обеспечить управляемое и контролируемое развитие структуры, состава компонентов и функций сложных высококачественных информационных систем в течение всего их жизненного цикла. Они позволяют упорядочить поток изменений в программах, тем самым резко повысить качество ПС, а также сократить затраты ресурсов и длительность реализации предложений по их улучшению. Для этого необходима точная и достоверная информация о состояниях системы и ее компонентов, всех предполагаемых и выполненных изменениях. Регламентируют сопровождение и конфигурационное управление стандарты:
  1. ISO 12207:1995 — Процессы жизненного цикла программного обеспечения.
  2. ISO 12207-2 — Процессы жизненного цикла программного обеспечения. Часть 2. Процессы конфигурационного управления (проект)
  3. ISO 9000-3:1991 — Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
  4. ISO 687:1983. ИТ. Управление конфигурацией программного обеспечения.
  5. ANSI/IEEE 828 — 1990. Планирование управления конфигурацией программного обеспечения.
  6. ANSI/IEEE 1042 — 1987 (ред. 1993). Руководство по планированию управления конфигурацией программного обеспечения.
  7. ANSI/IEEE 1219 — 1992. Сопровождение программного обеспечения.
Стандарт ISO 12207 — является основным международным нормативным документом, регламентирующим жизненный цикл и, в частности, сопровождение и конфигурационное управление программными средствами. В стандарте эти процессы детализированы соответствующими действиями — процедурами, для которых определены основные работы и их результаты. В этом стандарте непосредственно к задачам сопровождения относятся три процесса:
5.5. Процесс сопровождения в составе основных процессов;
6.8. Процесс решения проблем — устранения дефектов
6.2. Процесс конфигурационного управления в составе Вспомогательных процессов.
Ниже эти разделы изложены подробно в полном соответствии с текстом стандарта. Работы, обеспечивающие сопровождение ПС представлены в разделе 5.5 стандарта (24 работы). Предполагается, что работы по сопровождению и развитию версий ПС могут выполняться специалистами, которые не вели разработку ПС на предыдущих этапах.
5.5. Содержание процессов и действий по сопровождению.
5.5.1. Реализация процесса. Эти действия состоят из следующих задач:
5.5.1.1. Персонал сопровождения должен разработать, документировать и выполнить планы и процедуры для задач Процесса сопровождения.
5.5.1.2. Персонал сопровождения должен устанавливать процедуры для получения, записи и сообщений о трекинговых дефектах и модификационных запросах от пользователей и обеспечение обратной связи пользователям. Всякий раз, когда проблемы возникают, они должны быть записаны и введены в Процесс Решения Проблем (6.8).
5.5.1.3. Персонал сопровождения должен выполнять или устанавливать функциональную связь с Процессом Управления Конфигурацией (6.2) для руководства модификацией существующей системы.
5.5.2. Анализ дефектов и модификаций. Эта деятельность включает в себя следующие задачи:
5.5.2.1.Персонал сопровождения должен анализировать проблемное сообщение или модификационный запрос для их воздействия на организацию, существующую систему и интерфейсные системы для оценки:
5.5.2.2. Персонал сопровождения должен повторять или проверять дефект.
5.5.2.3. Базируясь на анализе, персонал обслуживания должен разрабатывать примеры для выполнения модификаций.
5.5.2.4. Персонал сопровождения должен документировать проблемный или модификационный запрос, результаты анализа и примеры реализации.
5.5.2.5.Персонал сопровождения должен получить утверждение на отобранный пример модификации согласно контракту.
5.5.3. Реализация модификации. Эта деятельность состоит из следующих задач:
5.5.3.1. Персонал сопровождения должен проводить анализ и определять, какие: документация, единицы программного обеспечения и версии должны измениться. Это должно быть документировано.
5.5.3.2. Персонал сопровождения должен войти в Процесс Разработки (5.3), чтобы выполнить модификации. Требования Процесса Разработки должны быть дополнены следующим образом:
а) Испытание и критерий оценки для тестирования и оценивания модифицированных и немодифицированных частей (единиц программного обеспечения, компонентов и единиц конфигурации) системы должны быть определены и документированы.
б) Полная и правильная реализация новых и модифицированных требований должна быть гарантирована. Также должно быть гарантировано, что первоначальные немодифицированные требования были не эффективными. Результаты испытаний должны быть документированы.
5.5.4. Оценка и принятие результатов сопровождения. Эти действия состоят из следующих задач:
5.5.4.1. Персонал сопровождения должен проводить оценки изменений совместно с организацией, разрешающей модификацию, чтобы определить целостность модифицированной системы.
5.5.4.2. Персонал сопровождения должен получить утверждение на удовлетворительное завершение модификации, как определено в контракте.
5.5.5. Перенос на иную платформу. Эта деятельность состоит из следующих задач:
5.5.5.1. Если система или программы (включая данные) перемещаются из старой в новую операционную среду, должно быть гарантировано, что любой программный продукт или данные, произведенные или измененные в течение миграции, согласуются с этим Международным Стандартом.
5.5.5.2. Миграционный план должен быть разработан, документирован и выполнен. Действия планирования должны включать участие пользователей. Пункты в плане должны включать следующее:
а) Анализ требований и определение характеристик переноса — миграции;
б) Разработка миграционных инструментальных средств;
в) Изменение программного продукта и данных;
г) Выполнение переноса;
д) Проверка переноса;
е) Поддержка для старой окружающей среды в будущем.
5.5.5.3. Пользователям должно быть дано уведомление о планах и действиях по переносу. Уведомления должны включать следующее:
а) Заявление, почему старая среда не может больше поддерживаться;
б) Описание новой среды с ее датой доступности;
в) Описание других имеющихся в распоряжении примеров поддержки, если только поддержка для старой среды ликвидирована.
5.5.5.4. Параллельные операции старой и новой окружающих сред могут проводиться для гладкого перехода к новой среде. В течение этого периода должно быть обеспечено необходимое обучение как определено в контракте.
5.5.5.5. Когда запланированный перенос завершается, уведомление должно быть послано всем заинтересованным лицам. Вся связанная со старой окружающей средой документация, файлы, журналы регистрации и коды должны быть помещены в архивы.
5.5.5.6. Послеоперационный обзор должен быть выполнен для оценки влияния изменений в окружающей среде. Результаты обзора должны быть посланы соответствующим уполномоченным властям и специалистам для информации, руководства и действия.
5.5.5.7. Данные, используемые и связанные со старой окружающей средой должны быть доступны согласно требованиям контракта для защиты данных и ревизии, применимой к данным.
5.5.6. Ликвидация сопровождения программного средства. Эти действия состоят из следующих задач:
Примечание: программный продукт может быть ликвидирован (снят с сопровождения) только по запросу владельца.
5.5.6.1. План для прекращения активной поддержки эксплуатирующими и сопровождающими организациями должен быть разработан и документирован. Действия планирования должны учитывать пользователей. План должен обращаться к пунктам, опубликованным ниже. План должен быть выполнен.
а) Прекращение полной или частичной поддержки после определенного периода времени;
б) Архивирование программного продукта и связанной с ним документации;
в) Определение ответственности за любые будущие остаточные результаты поддержки;
г) Переход к новому программному продукту, если применим;
д) Определение доступности архивных копий данных.
5.5.6.2. Пользователь должен получить уведомление о планах и действиях прекращения сопровождения. Уведомления должны включать следующее:
а) Описание замены или расширения (модернизации) с датой ее доступности;
б) Заявление, почему программный продукт не может больше поддерживаться;
в) Описание других имеющихся в распоряжении вариантов обеспечения, раз сопровождение ликвидировано.
5.5.6.3. Параллельные действия ликвидации старого и введения нового программного продукта должны быть проведены для плавного перехода к новой системе. В течение этого периода должно быть обеспечено обучение пользователя как определено в контракте.
5.5.6.4. Когда наступает запланированное прекращение сопровождения, должно быть послано уведомление всем заинтересованным лицам. Вся связанная с разработкой документация, файлы, журналы регистрации и коды должны быть размещены в архивах.
5.5.6.5. Данные, используемые и связанные с прекращенным сопровождением программным продуктом должны быть доступны согласно требованиям контракта для защиты данных и ревизии, применимой к данным.
Раздел 6 стандарта — Конфигурационное управление (п.6.2) включает план, как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации версий ПС.
6.2. Процесс управления конфигурацией.
6.2.1. Реализация процесса. Эта деятельность решает следующую задачу:
6.2.1.1. План управления конфигурацией должен быть разработан. План должен описывать: деятельность по управлению конфигурацией; процедуры и программы (планы, графики) выполнения этой деятельности; организацию (организации), ответственную за выполнение этой деятельности и их связь с другими организациями, такими как разработчики программного обеспечения или сопровождения. План должен быть документирован и выполнен.
Примечание: — План может быть частью плана управления конфигурацией системы.
6.2.2. Идентификация конфигурации. Эта деятельность решает следующую задачу:
6.2.2.1. Схема должна быть установлена для идентификации единиц программного обеспечения и их версий, которые контролируются (управляются) в проекте. Для каждой единицы программного обеспечения и ее версий должно быть определено следующее:
— документация, которая устанавливает нижнюю базовую линию;
— справки, ссылки версии;
— другие детали идентификации.
6.2.3. Управление конфигурацией. Эти действия решают следующую задачу:
6.2.3.1. Должно быть выполнено следующее:
— идентификация и запись запросов изменения;
— анализ о оценка изменений;
— утверждение или неутверждение запроса;
— реализация, верификация и выпуск модифицированной единицы программного обеспечения.
Контрольный след должен существовать, посредством чего каждая модификация, причина для модификации и разрешение модификации может быть прослежена.
Должна быть выполнена проверка всех документов к управляемым единицам программного обеспечения, которые обеспечивают надежность или критические функции защиты.
6.2.4. Отчеты соответствия конфигурации. Эта деятельность решает следующую задачу:
6.2.4.1. Протоколы управления и отчеты о состоянии, которые демонстрируют состояние и историю управляемых единиц программного обеспечения, включая базовые, должны быть приготовлены. Отчеты о состоянии должны включать число изменений для проекта, последние версии единицы программного обеспечения, выпуск идентификаторов, количество версий и сравнения версий.
6.2.5. Оценка конфигурации. Эта деятельность решает следующую задачу:
6.2.5.1. Должно быть определено и гарантировано следующее: функциональная законченность каждой единицы программного обеспечения в соответствии с их требованиями и физическая завершенность единиц программного обеспечения (отражает ли их проект и код программ новейшее техническое описание).
6.2.6. Управление выпуском и поставкой. Эта деятельность решает следующую задачу:
6.2.6.1. Выпуск и поставка программных продуктов и документации должна (официально, формально, соответственно правилам) управляться. Мастер-копии кода и документации должны быть сохранены в течение жизни программного продукта. Коды и документация, которые обеспечивают надежность или критические функции защиты должны обрабатываться, сохраняться, упаковываться и поставляться согласно политике включенных организаций.
6.8. Решения проблем — ликвидации дефектов в программах.
6.8.1. Реализация процесса. Эта деятельность решает следующие задачи:
6.8.1.1. Процесс решения проблем должен быть проведен для обработки всех дефектов (включая несоответствия), обнаруженных в программных продуктах и действиях. Процесс должен выполнять следующие требования:
а) процесс должен быть замкнутым циклом, гарантирующим, что все обнаруженные дефекты быстро сообщены и введены в Процесс Решения Проблем, воздействие инициализировано на них, релевантные стороны извещены о существующих дефектах, причины идентифицированы, проанализированы и, где возможно, устранены, решение и диспозиция достигнуты, состояние отслежено и сообщено, и проблемные отчеты сохранены как предусмотрено в контракте;
б) процесс должен содержать схему для классификации и определения приоритетов проблем. Каждая проблема должна быть классифицирована категорией и приоритетом, чтобы облегчить анализ тенденции и решение проблемы;
в) анализ должен быть выполнен для обнаружения тенденций в сообщенных дефектах;
г) проблемные решения и диспозиции должны быть оценены по критериям: какие проблемы решены, неблагоприятные тенденции изменены и изменения выполнены правильно в соответствующих программных продуктах и действиях, и определить введены ли дополнительные дефекты.
6.8.2. Решение проблем. Эта деятельность решает следующую задачу:
6.8.2.1. Когда дефекты (включая несоответствия) определены в программном продукте или деятельности, проблемное сообщение должно быть приготовлено для описания каждого обнаруженного дефекта. Проблемное сообщение должно использоваться как часть процесса замкнутого цикла, описанного выше: от определения дефекта, через исследование, анализ и решение проблемы и ее причины и до определения тенденции через проблемы.
Стандарт ISO 12207-2 — Процессы жизненного цикла программного обеспечения. Часть 2. Процессы конфигурационного управления (проект) — полностью посвящен сопровождению и конфигурационному управлению сложных ПС. В стандарте развиваются и детализируются процессы представленные в первой части стандарта, изложенные выше. Его основные положения использованы в п.3.4.
Стандарт ISO 9000-3:1991 — Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. Эта часть 3 базового стандарта по качеству ISO 9000 призвана оказать методическую помощь в случаях, когда по контракту требуется, чтобы поставщик мог продемонстрировать реальную возможность создания ПС с заданным качеством. Непосредственно к задачам сопровождения и конфигурационного управления относится раздел 6.1.
6.1. Общее руководство конфигурацией.
6.1.1 Общие положения
Общее руководство конфигурацией обеспечивает механизм идентификации, управления и слежения за версиями каждого изделия программного обеспечения. Во многих случаях предшествующие версии, которые все еще используются, должны также содержаться в рабочем состоянии и управляться. Система общего руководства конфигурацией должна:
a) однозначно идентифицировать версии каждого изделия программного обеспечения;
b) идентифицировать версии каждого элемента программного обеспечения, которые в совокупности составляют конкретную версию законченной продукции;
c) идентифицировать конструкционно-монтажный статус продукции программного обеспечения, находящейся на этапах разработки или поставки и монтажа;
d) осуществлять управление одновременной актуализацией данного изделия программного обеспечения двумя и более программистами;
e) обеспечивать координацию актуализации сложной продукции на одном или нескольких участках, в зависимости от потребности;
f) идентифицировать и прослеживать все действия и изменения, вытекающие из запроса на изменение, начиная с внесения предложения и кончая выпуском продукции.
6.1.2. План общего руководства конфигурацией. Поставщик должен разработать и осуществить план общего руководства конфигурацией, включающий следующее:
a) организации, участвующие в общем руководстве конфигурацией и обязанности, вложенные на каждую из них;
b) предстоящая деятельность по общему руководству конфигурацией;
c) средства, методы и методологии, которые будут использоваться при общем руководстве конфигурацией,
d) этапы, на которых изделия должны подпадать под управление конфигурацией.
6.1.3. Деятельность по общему руководству конфигурацией
6.1.3.1. Идентификацию конфигурации и ее прослеживаемость должен Поставщик установить и поддерживать в рабочем состоянии процедуры идентификации изделий программного обеспечения на протяжении всех этапов, начиная с технических условий и кончая разработкой, копированием и поставкой; В случаях, предусмотренных контрактом, эти процедуры могут также применяться после поставки продукции. Каждое отдельное изделие программного обеспечения должно иметь свою собственную идентификацию.
Процедуры должны применяться для обеспечения того, чтобы приведенные ниже пункты могли быть идентифицированы для каждой версии изделия программного обеспечения:
а) функциональные и технические характеристики;
b) все средства разработки, влияющие на функциональные и технические характеристики;
c) все интерфейсы к другим изделиям программного обеспечения и оборудованию;
d) все документы и массивы данных ЭВМ, относящиеся к изделию программного обеспечения. Идентификация изделия программного обеспечения должна осуществляться таким образом, чтобы можно было продемонстрировать взаимосвязь между этим изделием и конкретными требованиями.
Для выпущенной продукции следует установить процедуры, облегчающие прослеживаемость изделия программного обеспечения или продукты программного обеспечения.
6.1.3.2. Управление изменениями
Поставщик должен установить и поддерживать в рабочем состоянии процедуры идентификации, документации, анализа и утверждения любых изменений, относящихся к изделиям программного обеспечения в рамках общего руководства конфигурацией. Все изменения, вносимые в изделия программного обеспечения, следует осуществлять в соответствии с этими процедурами.
До принятия изменения его законная сила должна быть подтверждена, а воздействия на другие изделия — идентифицированы и исследованы.
Следует предусмотреть методы уведомления об изменениях заинтересованных лиц и обеспечить демонстрацию прослеживаемости между изменениями и модифицированными частями изделий программного обеспечения.
6.1.3.3. Отчет о статусе конфигурации
Поставщик должен установить и поддерживать в рабочем состоянии процедуры регистрации данных, управления и сообщения о статусе изделий программного обеспечения, запросах об изменениях и регистрации одобренных изменений.