Идентификация программной конфигурации

Идентификация программной конфигурации

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

Идентификация элементов, требующих контроля

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

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

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

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

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

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

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

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

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

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

Программная библиотека

Программная библиотека – контролируемая коллекция программных приложений и связанной с ними документации, предназначенная для использования в процессе разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE 610.12-90). В качестве программной библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции).

На практике могут использоваться различные типы библиотек, каждая из которых соответствует определенному уровню зрелости элементов программного обеспечения. Например, “рабочая библиотека” может поддерживать работы по кодированию, “библиотека поддержки проекта” может поддерживать тестирование, “мастер-библиотека” может использоваться для завершенных продуктов

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

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

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

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

На более высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система) является основным пользователем .

Контроль программных конфигураций

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

Предложение, оценка и утверждение изменений

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

Эффективный процесс обработки запросов на изменения требует использования соответствующих средств поддержки и процедур для данного вида деятельности, от “бумажных” форм и документированных процедур (как последовательности действий или сценариев) до программных инструментов, позволяющих отсылать запросы на изменения, выполнять процесс обработки таких запросов (изменять их статус, комментировать, детализировать и т.п.), фиксировать решения, принятые CCB, а также генерировать отчетную информацию по процессу обработки запросов на изменения. Связь между этими средствами и инструментами обработки отчетов об ошибках может существенно облегчить определение решений для обнаруженных проблем.

Реализация изменений

Принятые (утвержденные) запросы на изменения (SCR) реализуются используя определенные процедуры, в соответствии с подходящими требованиями в отношении расписания. Если набор утвержденных запросов на изменения может выполняться одновременно, необходимо обеспечить отслеживание того, какие именно SCR реализованы в конкретной версии программного продукта и базовой линии конфигурации. Составной частью процесса “закрытия” изменения, является аудит конфигурации и верификация качества программного обеспечения. Это обеспечивает гарантию того, что были внесены только утвержденные изменения. Описанный выше процесс обработки запросов на изменения обычно включает документирование всей информации, связанной с принятым изменением

Фактическая реализация изменений поддерживается инструментальными средствами соответствующей программной библиотеки, обеспечивающей управление версиями и поддержку единого репозитория кода. Как минимум, эти инструменты должны поддерживать операции помещение в репозиторий/ получение из репозитория и ассоциированные возможности по контролю версий (например, отметка версии, сравнение, слияние и т.п.). Более мощные инструменты могут поддерживать параллельную разработку и среду географически распределенной. Эти инструменты могут объявляться (в рамках организации) как отдельные специализированные приложения, целиком находящиеся под контролем независимой SCM-группы (как самостоятельной/выделенной организационной сущности). Наконец, они могут быть столь элементарными, что включают только упрощенный контроль версий, например, на уровне файловой системы операционной среды.

Отклонения и отказ от изменений

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

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

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

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

Отчетность по статусу конфигураций

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

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

Аудит конфигураций

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

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

Существует два типа  формального аудита: функциональный аудит конфигураций и физический аудит конфигураций. Успешное завершение этих аудитов  может быть обязательным требованиям для фиксирования базовой линии продукта. Перед их выполнением необходимо четко оценивать реальные потребности в таких видах аудита.

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

Цель физического аудита – проверка того, что дизайн и документация точно согласуются с самим программным продуктом.

Внутренние аудиты базовых линий

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

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

Термин “ релиз ” ( release, выпуск ) подразумевает распространение и использование элементов конфигураций за рамками работ по разработке программного обеспечения. Это может включать как внутренние релизы, так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда доступны для поставки различные версии программных элементов (в частности, различные версии для разных платформ) часто бывает необходимо создавать специализированные версии и пакеты соответствующих материалов для выпуска в качестве  самостоятельной версии. Программная библиотека играет ключевую роль в выполнении таких работ.

Сборка программного обеспечения

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

Управление выпуском программного обеспечения

Управление выпуском (release management) программного обеспечения охватывает идентификацию, упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации, аннотацию релиза (release note) и конфигурационные данные. Так как изменения в продукте происходят постоянно, одной из задач управления выпуском продукта является определение момента времени, когда именно выпускать продукт. На это решение также влияет серьезность проблем, решению которых адресуется выпуск, и количественная оценка плотности сбоев в предыдущих выпусках. Задача упаковки состоит в идентификации того, какие элементы продукта должны быть выпущены.

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

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