6-software_engineering_configuration_manag ement (1133546), страница 3
Текст из файла (страница 3)
Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]В этом примере система управления кодом поддерживает программные библиотеки контролируядоступ к элементам библиотек, координирует действия множества пользователей и помогает впроведении рабочих процедур. Другие инструменты поддерживают процесс сборки и выпускапрограммного обеспечения и документации на основе программных элементов, содержащихся вбиблиотеках. Инструменты для управления запросами на изменения программного обеспеченияиспользуются для контролируемых <системой конфигурационного управления> программныхэлементов. Другие инструменты могут обеспечивать управление базой данных и необходимымименеджменту отчетными средствами, а также деятельностью по разработке и обеспечениюкачества. Как уже упоминалось выше, в рамках SCM-системы может быть объединен целый рядCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия.
Конфигурационное управление.инструментов различных типов. При этом сама система конфигурационного управления может бытьтесно связана и поддерживать другие виды работ, касающиеся не только SCM.В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решениястоящих перед ними задач.Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в отношениииспользуемых процессов программной инженерии и уровня зрелости этих процессов. Кроме того,необходимо учитывать и вопросы унификации программных средств, используемых для поддержкиинфраструктуры разработки и сопровождения всего портфеля программных проектов, выполняемыхв организации.
В силу фундаментальной значимости SCM-системы для обеспечения базовыхпроцессов программной инженерии и управления всеми проектными активами, принимать решениеоб использовании той или иной SCM-системы для каждого отдельно взятого проекта выглядитнеобоснованным. SCM-система, система управления требованиями (более чем желательно,связанная с SCM), средства бизнес-моделирования и проектирования, среды разработки – все этодолжно быть стандартизировано в рамках организации, за исключением тех случаев, когдатребования в отношении тех или иных инструментальных средств сформулированы со сторонызаказчика и являются составной частью требований, предъявляемых к проекту. Возвращаясь квопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, однако,сложившиеся привычки не должны “перевешивать” функциональность предлагаемых к унификацииSCM-средств, обеспечиваемую ими доступность и прозрачность информации о состоянии проекта влюбой момент времени и, конечно, возможность эффективного администрирования активов проекта,в том числе, в контексте необходимых для этого трудозатрат.В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения(и, даже, на этапе эксплуатации) выбираемой системы конфигурационного управления.
В частности,обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зренияпоставленных целей – проекта и/или совершенствования процессов). Дополнительная информация,затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK “SoftwareEngineering 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)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.Результаты SCM-планирования для заданного проекта определяются в плане конфигурационногоуправления (Software Configuration Management Plan, SCMP), который является документом,используемом в качестве описание SCM-процесса.
Он всегда поддерживается в актуальномсостоянии (обновляясь и утверждаясь по мере внесения в него необходимых изменений) напротяжении всего жизненного цикла. При описании SCM-плана обычно необходимо разработать ряддетальных процедур, определяющих как конкретные требования будут выполняться в повседневнойдеятельности.Создание и сопровождение плана конфигурационного управления основывается на информации,получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождениюSCMP можно найти, например, в одном из ключевых SCM-стандартов IEEE 828-98 “Standard forSoftware 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-процесса (наравне с проектной информацией иCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.данными, необходимыми для принятия тех или иных управленческих решений).
Например,информация о времени, необходимом для выполнения различных типов изменений, может бытьполезна для оценки критериев того, какой уровень полномочий оптимален для утвержденияопределенных типов изменений.Необходимо сохранять фокус на проведении анализа измерений и формировании соответствующихвыводов, вместо проведения “измерений ради измерений” (к сожалению, последнее встречаетсяслишком часто, чтобы не отметить этот факт). Обсуждение количественных оценок в отношениипроцесса и продукта представлено в области знаний “Процесс программной инженерии”. Программапроведения количественных оценок обсуждается в области знаний “Управление программнойинженерией”.1.5.2 Аудит в рамках SCM (In-process* audits of SCM)Аудит может проводится на протяжении всего процесса программной инженерии для определениятекущего статуса заданных элементов конфигураций или оценки реализации процессаконфигурационного управления.
SCM-аудит предоставляет более формальный механизммониторинга выбранных аспектов процесса и может координироваться с работами в областиобеспечения качества (SQA; см. секцию “5. Software Configuration Auditing”).* “in-process” подчеркивает непрерывность/периодичность аудита и его позиционирование какнеотъемлемой составной части конфигурационного управления.2. Идентификация программных конфигураций (Software Configuration Identification)Работы по идентификации конфигураций программного обеспечения определяют контролируемыеэлементы (items), устанавливают схемы идентификации для элементов и их версий, а также задаютинструменты и описывают техники, используемые для управления этими элементами (включая ихпередачу под управление SCM-процесса и системы).
Данная деятельность является основой длявсех других работ по конфигурационному управлению.2.1 Идентификация элементов, требующих контроля (Identifying Items to Be Controlled)Первый шаг в организации контроля изменений состоит в идентификации программных элементов,которые необходимо контролировать в рамках SCM-процесса. Это предполагает пониманиепрограммной конфигурации в контексте системной конфигурации, выбор элементов программнойконфигурации, разработку стратегии отметки (labeling) программных элементов и описание связимежду ними, а также идентификацию базовых линий (baselines, это понятие будет обсуждатьсяпозднее в этой теме) вместе с процедурами включения элементов в базовую линию.2.1.1 Программная конфигурация (Software configuration)Программная конфигурация – набор функциональных и физических характеристик программногообеспечения, сформулированная в документации или воплощенная в продукте (см.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
