6-software_engineering_configuration_manag ement (1133546), страница 4
Текст из файла (страница 4)
IEEE 610.12-90,Standard Glossary for Software Engineering Terminology). Программная конфигурация можетрассматриваться как составная часть общей системной конфигурации.2.1.2 Элемент конфигурации (Software configuration item)Элемент программной конфигурации (software configuration item, SCI) – фрагмент программногообеспечения, вовлеченный в процесс конфигурационного управления (и, возможно, помещенный подуправление SCM-системы) и рассматриваемый как одна (атомарная) сущность в рамках SCMпроцесса (см.
IEEE 610.12-90). SCM контролирует множество различных элементов, включая нетолько программный код. Программные элементы, потенциально полезные в качестве элементовпрограммной конфигурации (SCI), включают планы, спецификации и документы (например,полученные в результате моделирования и проектирования), программные инструменты, исходный иисполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке,сопровождению, эксплуатации и использованию программного обеспечения.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.Выбор SCI является важным процессом, в рамках которого необходимо достигать баланса междуобеспечением адекватного уровня прозрачности представления (дословно – “видимости”, visibility) вконтексте контроля проекта.
Правильный выбор элементов конфигурации важен для обеспеченияуправляемого набора контролируемых элементов. SWEBOK дает ссылку на источник, описывающийсписок критериев по выбору элементов конфигураций.2.1.3 Связи между элементами конфигурации (Software configuration item relationships)Структурные связи между выбранными элементами конфигурации (и их составляющими) влияют надругие SCM работы и задачи, например, сборку программного обеспечения или анализ влияний(impact analysis) предлагаемых изменений.
Надлежащее отслеживание этих связей является важнымдля поддержания актуальной трассировки (traceability) между активами проекта. Разработка схемыидентификации элементов конфигураций (SCI) должна учитывать отображение междуидентифицируемыми элементами и структурой программного обеспечения, а также потребность вподдержке эволюционирования программных элементов и их связей по мере развития системы.2.1.4 Версия программного обеспечения (Software version)Программные элементы развиваются по мере выполнения проекта.
Версия (version) программногоэлемента – конкретно идентифицированный и специфицированный элемент. Версия элементаможет также рассматриваться в качестве определенного состояния (state) эволюционирующегоэлемента. Обновление (revision) – новая версия элемента, предназначенная для замены его старойверсии. Вариант (variant) – новая версия элемента, добавляемая в конфигурацию без заменыстарой версии (то есть сосуществующая с другой версией того же элемента).2.1.5 Базовая линия, срез (Baseline)Базовая линия или <фиксированный> срез (baseline) программного обеспечения –набор элементовпрограммной конфигурации, формально определенный и зафиксированный по времени в процессежизненного цикла программного обеспечения. Этот термин также иногда используется для указанияконкретной версии элемента конфигурации, если это согласовано заранее.
В определенных случаях,базовая линия может изменяться только через формальную процедуру контроля изменений.Фиксированный срез в сочетании со всеми утвержденными изменениями в отношении егопредставляет собой текущую утвержденную конфигурацию.Хотя, упоминаемая в SWEBOK классификация базовых линий в определенной степени являетсяумозрительной и, безусловно, не единственно возможной, она полезна для адаптации и выработкивнутрикорпоративных стандартов, на основе которых, в дальнейшем строятся соответствующиепланы конфигурационного управления (SCMP). Приведенную ниже классификацию, соответственно,стоит рассматривать лишь как пример, но пример достаточно полезный для данного контекстаобсуждения.В общем случае, используются следующие типы базовых линий – функциональные, утвержденные,эволюционные или промежуточные, а также, базовые линии продукта.
Функциональный срезсоответствует принятым программным требованиям. Утвержденный срез соответствует принятымпрограммным требованиям и требованиям в отношении интерфейсов. Базовая линия продуктапредставляет собой срез активов, относящихся к продукту, на заданный момент времени (при этом,базовая линия продукта не всегда является его версией, готовой к выпуску, т.е. к передаче вэксплуатацию). Полномочия по изменению заданной базовой линии обычно находятся в веденииорганизационной структуры, отвечающей за разработку программного обеспечения, но могут такжеразделяться и с другими организационными структурами (например, отвечающей законфигурационное управление или тестирование). Базовая линия продукта соответствуетзавершенному программному продукту, готовому для проведения работ по интеграции в рамкахцелевой системы (system integration). Базовые линии, используемые для данного проекта, вместе сассоциированным уровнем полномочий, необходимым для утверждения изменений, обычноидентифицируется в конфигурационном плане – SCMP.Здесь уместно провести параллель между вехами (milestone) проекта и базовыми линиями.Выглядит вполне обоснованным отображение вех проекта на базовые линии, как “выходы”Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия.
Конфигурационное управление.(результаты) выполнения процессов проекта к моменту достижения соответствующей проектнойвехи.2.1.6 Включение элементов в программную конфигурацию (Acquiring software configuration items)Различные элементы программной конфигурации передаются под управление SCM-процесса вразличные моменты времени и включаются в базовые линии в определенных точках жизненногоцикла.
Инициирующим событием является завершение определенных форм формальногоутверждения задач, таких как формальная оценка (review). Рисунок 4 характеризует развитиебазовой линии в процессе жизненного цикла. Этот рисунок базируется на каскадной (waterfall)модели только в целях иллюстрации; нижние индексы используются для обозначения версийэволюционирующих элементов. Запросы на изменения (software change requests, SCR),присутствующие на рисунке, описываются в теме 3.1 “Requesting, Evaluating, and Approving SoftwareChanges”.Рисунок 4.
Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]После включения элемента в конфигурацию в качестве SCI, изменения элементов должныутверждаться формально, как связанные с соответствующими элементами (SCI) и базовымилиниями, следуя плану конфигурационного управления (SCMP). После утверждения <запроса наизменение и проведения работ по изменению>, <измененный> элемент включается в конфигурацию,в соответствии с заданной процедурой утверждения.2.2 Программная библиотека (Software Library)Программная библиотека – контролируемая коллекция программных приложений и связанной с нимидокументации, предназначенная для использования в процессе разработки, эксплуатации исопровождения программного обеспечения (см.
IEEE 610.12-90). В качестве <элемента>программной библиотеки, также, может рассматриваться инструментарий, используемый в работахпо выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции). Напрактике могут использоваться различные типы библиотек, каждая из которых соответствуетопределенному уровню зрелости элементов программного обеспечения. Например, “рабочаябиблиотека” (working library) может поддерживать работы по кодированию, “библиотека поддержкипроекта” (project support library) может поддерживать тестирование, “мастер-библиотека” (masterlibrary) может использоваться для завершенных продуктов (например, как вся совокупность средств,используемых для разработки и/или выпуска продукта).
С каждой библиотекой ассоциировансоответствующий уровень контроля конфигурационного управления, также ассоциированный сCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru12Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.базовой линией и уровнем полномочий по внесению изменений. Безопасность (в терминах контролядоступа и средств резервного копирования) является одним из ключевых аспектов управлениябиблиотеками.
SWEBOK отмечает, что существуют различные модели программных библиотек, атакже приводит соответствующие первоисточники по этой теме.Используемые для каждой библиотеки инструменты должны поддерживать контроль SCM,необходимый для данной библиотеки, как в терминах управления элементами конфигурации (SCI),так и с точки зрения контроля доступа к библиотеке. На уровне рабочей библиотеки – это средствауправления кодом, обслуживающие разработчиков, специалистов по сопровождению и SCMпроцесс/инструментарий (например, среда разработки должна обеспечивать интеграцию с SCMсистемой). В данном контексте, рабочая библиотека фокусируется на управлении версиямипрограммных элементов (к которым, безусловно, относится не только код, но и запросы наизменения, включая сообщения об обнаруженных дефектах, и т.п.) в многопользовательской среде.На более высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система)является основным пользователем <библиотеки> (например, для осуществления автоматическойсборки продукта по расписанию).Все эти библиотеки также являются важным источником информации для количественной оценкиработ, их результата и прогресса <в развитии программных элементов>.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
