1.1 Организационный контекст SCM (Organizational Context for SCM)
Для планирования SCM-процесса необходимо понимать организационный контекст и связи между организационными элементами. SCM-работы предполагают взаимодействие с другими аспектами проектной деятельности (не путайте с управлением проектами - это, при всей своей значимости, лишь один из видов проектной деятельности и организационными элементами.
Организационные элементы, отвечающие за процессы поддержки программной инженерии, могут быть структурированы несколькими способами. Несмотря на то, что ответственность за выполнение определенных SCM-задач может быть назначена (принята или ассоциирована, в зависимости от управленческих принципов и установок, т.е. общего менеджмента - general management) различным частям (лицам, группам, подразделениям и т.п.) организации, например, структуре, отвечающей за разработку программного обеспечения, общая ответственность за конфигурационное управление часто возлагается на отдельный (специализированный) организационный элемент или назначенную персону.
Программное обеспечение часто разрабатывается как составная часть большей системы, содержащей аппаратные и программно-аппаратные/встраиваемые элементы. В этом случае, SCM- деятельность ведется параллельно с работами по конфигурационному управлению (CM) в отношении аппаратной или программно-аппаратной части, строго согласуясь с общим конфигурационным управлением на уровне системы, в целом. Ряд источников (см. библиографию SWEBOK, связанную с данной областью знаний) описывает SCM в сочетании с контекстом, в рамках которого проводится такая деятельность.
SCM может играть роль интерфейса к работам, направленным на обеспечение качества (quality assurance), вытекающим, например, из отслеживания записей <по изменениям> и несогласующихся элементов (например, выявленным в процессе сборки очередной версии системы, прим. автора). С точки зрения составителей <данной области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM <процесса>, могут также служить объектами рассмотрения в рамках организационных программ по обеспечению качества. Управление несогласующемися элементами обычно относится к работам по управлению качеством. Однако, SCM может обеспечить существенную помощь в отслеживании (трассировке) и создании отчетности по элементам программных конфигураций, попадающих в такую <проблемную> категорию.
SWEBOK отмечает, что возможно тесное взаимодействие между организационными структурами, отвечающими за разработку и сопровождение (и SCM играет роль инфраструктуры, обеспечивающей такую связь).
В зависимости от контекста, существует множество подходов и практик в части выполнения задач конфигурационного управления в приложении к программному обеспечению. Часто, одни и те же инструменты поддерживают и разработку, и сопровождение, обеспечивая достижение целей и содержания SCM.
1.2 Ограничения и правила SCM (Constraints and Guidance for the SCM Process)
Ограничения и правила в отношении процесса конфигурационного управления порождаются различными источниками. Политики и процедуры, формулируемые на корпоративном или другом организационном уровне, могут влиять или предписывать структуру и реализацию SCM-процесса для заданного проекта. Кроме того, контракт между заказчиком и поставщиком может содержать положения, затрагивающие процесс конфигурационного управления. Например, может требоваться проведение определенных процедур проверки (аудита) или специфицирован набор элементов (активов, артефактов), передаваемых под управление <процедур и системы> конфигурационного управления (или в части формализации обработки и контроля реализации запросов на изменения, поступающих от заинтересованных лиц). Когда разрабатываемый программный продукт потенциально затрагивает аспекты публичной безопасности, могут налагаться определенные ограничения со стороны соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear
Power Plants”, U.S. Nuclear Regulatory Commission, 1997). Наконец, на структуру и реализацию SCM- процесса в проекта влияют выбранные (с точки зрения модели и адаптированных характеристик) процессы жизненного цикла и инструменты, применяемые для реализации программной системы.
Рекомендации по структуре и реализации SCM-процесса могут быть также результатом применения лучших практик (best practices), представленных в стандартах, выпущенных соответствующими стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и оценки процессов, например, в CMMI - Capability Maturity Model Integration Института программной инженерии (SEI - Software Engineering Institute) университета Карнеги- Меллон (Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering - Process Assessment”.
1.3 Планирование в SCM (Planning for SCM)
Планирование процесса конфигурационного управления для заданного проекта должно согласовываться с организационным контекстом, соответствующими ограничениями, общепринятыми рекомендациями, а также характеристиками и природой самого проекта (например, его размером или значимостью). Основные работы, проводимые при планировании SCM- деятельности включают:
• Управление выпуском и поставкой (Software Release Management and Delivery)
Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA - Software Quality Assurance).
1.3.1 Организация и обязанности (SCM organization and responsibilities)
Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества.
1.3.2 Ресурсы и расписание (SCM resources and schedules)
В процессе планирования конфигурационного управления идентифицируется персонал и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM. Планирование касается вопросов определения расписания, устанавливая последовательность задач конфигурационного управления и идентифицируя их связь с расписанием проекта и его вехами, определенными на стадии планирования проекта. Также должны быть специфицированы требования по обучению персонала, необходимые для реализации планов.
1.3.3 Выбор инструментов и реализация (Tool selection and implementation)
SCM-деятельность поддерживается различными типами инструментальных средства и процедур по их использованию. В зависимости от ситуации, эти инструменты могут включать комбинацию различных возможностей - автоматизированные средства могут решать отдельные задачи SCM, интегрированные средства могут обслуживать потребности многих участников процесса программной инженерии (например, SCM, разработку, проверку и аттестацию и т.п.). Значимость инструментальной поддержки конфигурационного управления (как и других аспектов деятельности в области программной инженерии) растет с каждым днем вместе со сложностью внедрения, ростом
размера проектов и сложности проектного окружения. Возможности инструментальных средств развиваются для обеспечения поддержки:
• Запросов на изменения (software change request - SCR) и процедур утверждения (approval)
• Управления кодом (и связанных рабочих продуктов) и изменениями
• Отчетности по статусу конфигураций и сбору соответствующих метрических показателей
• Аудиту конфигураций
• Управлению и отслеживанию <состояния и полноты> программной документации
• Выполнению задач по сборке программных продуктов и их модулей
• Управлению, контролю и поставке выпусков (релизов) программных продуктов
Инструменты, используемые для обеспечения конфигурационного управления, могут также предоставлять метрики, необходимые для совершенствования процессов. SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and Progress) и индикаторы качества - поток изменений (Change Traffic), стабильность <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF - Mean Time Between Failures), зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может быть организована различным образом, например, по элементам конфигураций или по типу запросов на изменения.
Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на работы по конфигурационному управлению.
Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]
В этом примере система управления кодом поддерживает программные библиотеки контролируя доступ к элементам библиотек, координирует действия множества пользователей и помогает в проведении рабочих процедур. Другие инструменты поддерживают процесс сборки и выпуска программного обеспечения и документации на основе программных элементов, содержащихся в библиотеках. Инструменты для управления запросами на изменения программного обеспечения используются для контролируемых <системой конфигурационного управления> программных элементов. Другие инструменты могут обеспечивать управление базой данных и необходимыми менеджменту отчетными средствами, а также деятельностью по разработке и обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть объединен целый ряд
инструментов различных типов. При этом сама система конфигурационного управления может быть тесно связана и поддерживать другие виды работ, касающиеся не только SCM.
В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решения стоящих перед ними задач.
Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в отношении используемых процессов программной инженерии и уровня зрелости этих процессов. Кроме того, необходимо учитывать и вопросы унификации программных средств, используемых для поддержки инфраструктуры разработки и сопровождения всего портфеля программных проектов, выполняемых в организации. В силу фундаментальной значимости SCM-системы для обеспечения базовых процессов программной инженерии и управления всеми проектными активами, принимать решение об использовании той или иной SCM-системы для каждого отдельно взятого проекта выглядит необоснованным. SCM-система, система управления требованиями (более чем желательно, связанная с SCM), средства бизнес-моделирования и проектирования, среды разработки - все это должно быть стандартизировано в рамках организации, за исключением тех случаев, когда требования в отношении тех или иных инструментальных средств сформулированы со стороны заказчика и являются составной частью требований, предъявляемых к проекту. Возвращаясь к вопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, однако, сложившиеся привычки не должны “перевешивать” функциональность предлагаемых к унификации SCM-средств, обеспечиваемую ими доступность и прозрачность информации о состоянии проекта в любой момент времени и, конечно, возможность эффективного администрирования активов проекта, в том числе, в контексте необходимых для этого трудозатрат.
В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и, даже, на этапе эксплуатации) выбираемой системы конфигурационного управления. В частности, обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зрения поставленных целей - проекта и/или совершенствования процессов). Дополнительная информация, затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK “Software Engineering Tools and Methods”.
1.3.4 Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control)
Программные проекты могут требовать необходимости приобретать или использовать уже приобретенное программное обеспечение - компиляторы и другие инструменты (среды разработки, библиотеки компонент). Планирование должно касаться вопросов - надо и, если надо, то как помещать эти инструменты (например, интегрируя в программные библиотеки проекта) под управление SCM-системы и как их изменения и обновления будут оцениваться и управляться.
Аналогичные соображения существуют и в отношении программного обеспечения, создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика предъявляются специальные требования со стороны заказчика и они вносятся в контракт, предполагая не только возможность мониторинга, но и соответствие его возможностей заданным требованиям. В последнее время все чаще отмечается важность доступности SCM-информации для эффективного мониторинга соответствия (compliance monitoring).
1.3.5 Контроль интерфейсов (Interface Control)
Когда программные элементы должны связываться с другими программными или аппаратными элементами, изменения в одних элементах могут влиять на другие элементы. Планирование SCM- процесса рассматривает, в частности, как будут идентифицироваться связанные элементы и как будут управляться и сообщаться их изменения. Конфигурационное управление может быть частью более масштабного процесса системного уровня (т.е. в рамках всей системы, к которой относятся соответствующие программные элементы) по определению и контролю интерфейсов, включая описание в соответствующих спецификациях интерфейсов, планах контроля интерфейсов и других документах. В этом случае, SCM-планирование контроля интерфейсов проводится в контексте процесса системного уровня.
1.4 План конфигурационного управления (SCM Plan)
Результаты SCM-планирования для заданного проекта определяются в плане конфигурационного управления (Software Configuration Management Plan, SCMP), который является документом, используемом в качестве описание SCM-процесса. Он всегда поддерживается в актуальном состоянии (обновляясь и утверждаясь по мере внесения в него необходимых изменений) на протяжении всего жизненного цикла. При описании SCM-плана обычно необходимо разработать ряд детальных процедур, определяющих как конкретные требования будут выполняться в повседневной деятельности.
Создание и сопровождение плана конфигурационного управления основывается на информации, получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождению SCMP можно найти, например, в одном из ключевых SCM-стандартов IEEE 828-98 “Standard for Software Configuration Management Plans”. Этот стандарт описывает требования к информации, содержащейся в плане конфигурационного управления, а также определяет шесть категорий SCM- информации, содержащейся в плане (обычно, представленных в виде соответствующих разделов, прим. автора):
• Введение (Introduction) - описывает цели, содержание и используемые термины.
• Управление (SCM Management) - описывает структуру, обязанности, полномочия, политики, директивы (указания, обязательные для исполнения) и процедуры.
• Работы (SCM Activities) - определяет идентификацию конфигураций, их контроль и т.п.
• Расписание (SCM Schedule) - определяет связь работ по конфигурационному управлению с другими аспектами и процессами проектной деятельности
• Ресурсы (SCM Resources) - описывает инструменты, физические ресурсы, персонал и т.п.
• Сопровождение плана (SCMP Maintenance) - определяет правила, по которым в план вносятся изменения и описывает как эти изменения внедряются в повседневный SCM- процесс.
1.5 Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management)
После того, как внедрен процесс конфигурационного управления, может быть необходимо контролировать (проводить надзор) над SCM-процессом для обеспечения того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются конкретные требования по обеспечению качества (SQA), контролирующие исполнение процессов и процедур конфигурационного управления. Для этого может быть необходимо введение соответствующих полномочий и назначение обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору над SCM-процессом могут существовать в контексте SQA- деятельности.
Использование интегрированных SCM-инструментов с возможностью контроля процесса может сделать процедуру надзора более легкой и прозрачной. Некоторые инструменты предоставляют высокий уровень настраиваемости для обеспечения гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя те или иные процессы и их характеристики. Требования контроля (надзора), с одной стороны, и уровень гибкости и адпатируемости, с другой, являются определяющими критериями выбора того или иного инструмента.
1.5.1 Метрики и процесс количественной оценки в SCM (SCM measures and measurement)
Количественные показатели (метрики) могут определяться для обеспечения информации о разрабатываемом продукте или для оценки исполнения самого процесса конфигурационного управления. Связанной целью SCM-мониторинга может быть и раскрытие возможностей по совершенствованию процесса (не только SCM-процесса, но и других процессов программной инженерии). Количественная оценка SCM-процессов предоставляет хорошие средства для мониторинга эффективности деятельности по конфигурационному управлению на постоянной основе. Эти измерения полезны для оценки текущего состояния процесса и проведения сравнений во времени (как прогресса в отношении развития продукта, так и качества выполнения процесса, как такового). Анализ измерений позволяет понять причины изменения процесса и внести соответствующие коррективы в план конфигурационного управления (SCMP).
Программные библиотеки и различные возможности SCM-средств предоставляют источники для получения информации о характеристиках SCM-процесса (наравне с проектной информацией и данными, необходимыми для принятия тех или иных управленческих решений). Например, информация о времени, необходимом для выполнения различных типов изменений, может быть полезна для оценки критериев того, какой уровень полномочий оптимален для утверждения определенных типов изменений.
Необходимо сохранять фокус на проведении анализа измерений и формировании соответствующих выводов, вместо проведения “измерений ради измерений” (к сожалению, последнее встречается слишком часто, чтобы не отметить этот факт). Обсуждение количественных оценок в отношении процесса и продукта представлено в области знаний “Процесс программной инженерии”. Программа проведения количественных оценок обсуждается в области знаний “Управление программной инженерией”.
1.5.2 Аудит в рамках SCM (In-process* audits of SCM)
Аудит может проводится на протяжении всего процесса программной инженерии для определения текущего статуса заданных элементов конфигураций или оценки реализации процесса конфигурационного управления. SCM-аудит предоставляет более формальный механизм мониторинга выбранных аспектов процесса и может координироваться с работами в области обеспечения качества (SQA; см. секцию “5. Software Configuration Auditing”).
* “in-process” подчеркивает непрерывность/периодичность аудита и его позиционирование как неотъемлемой составной части конфигурационного управления.
Работы по идентификации конфигураций программного обеспечения определяют контролируемые элементы (items), устанавливают схемы идентификации для элементов и их версий, а также задают инструменты и описывают техники, используемые для управления этими элементами (включая их передачу под управление SCM-процесса и системы). Данная деятельность является основой для всех других работ по конфигурационному управлению.
2.1 Идентификация элементов, требующих контроля (Identifying Items to Be Controlled)
Первый шаг в организации контроля изменений состоит в идентификации программных элементов, которые необходимо контролировать в рамках SCM-процесса. Это предполагает понимание программной конфигурации в контексте системной конфигурации, выбор элементов программной конфигурации, разработку стратегии отметки (labeling) программных элементов и описание связи между ними, а также идентификацию базовых линий (baselines, это понятие будет обсуждаться позднее в этой теме) вместе с процедурами включения элементов в базовую линию.
Программная конфигурация - набор функциональных и физических характеристик программного обеспечения, сформулированная в документации или воплощенная в продукте (см. 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), включают планы, спецификации и документы (например, полученные в результате моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и использованию программного обеспечения.
Выбор 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) проекта и базовыми линиями.
Выглядит вполне обоснованным отображение вех проекта на базовые линии, как “выходы”
(результаты) выполнения процессов проекта к моменту достижения соответствующей проектной вехи.
2.1.6 Включение элементов в программную конфигурацию (Acquiring software configuration items)
Различные элементы программной конфигурации передаются под управление SCM-процесса в различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла. Инициирующим событием является завершение определенных форм формального утверждения задач, таких как формальная оценка (review). Рисунок 4 характеризует развитие базовой линии в процессе жизненного цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях иллюстрации; нижние индексы используются для обозначения версий эволюционирующих элементов. Запросы на изменения (software change requests, SCR), присутствующие на рисунке, описываются в теме 3.1 “Requesting, Evaluating, and Approving Software Changes”.
Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]
После включения элемента в конфигурацию в качестве SCI, изменения элементов должны утверждаться формально, как связанные с соответствующими элементами (SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP). После утверждения <запроса на изменение и проведения работ по изменению>, <измененный> элемент включается в конфигурацию, в соответствии с заданной процедурой утверждения.
2.2 Программная библиотека (Software Library)
Программная библиотека - контролируемая коллекция программных приложений и связанной с ними документации, предназначенная для использования в процессе разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE 610.12-90). В качестве <элемента> программной библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике могут использоваться различные типы библиотек, каждая из которых соответствует определенному уровню зрелости элементов программного обеспечения. Например, “рабочая библиотека” (working library) может поддерживать работы по кодированию, “библиотека поддержки проекта” (project support library) может поддерживать тестирование, “мастер-библиотека” (master library) может использоваться для завершенных продуктов (например, как вся совокупность средств, используемых для разработки и/или выпуска продукта). С каждой библиотекой ассоциирован соответствующий уровень контроля конфигурационного управления, также ассоциированный с базовой линией и уровнем полномочий по внесению изменений. Безопасность (в терминах контроля доступа и средств резервного копирования) является одним из ключевых аспектов управления библиотеками. SWEBOK отмечает, что существуют различные модели программных библиотек, а также приводит соответствующие первоисточники по этой теме.
Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]
Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]