6-software_engineering_configuration_manag ement (1133546), страница 5
Текст из файла (страница 5)
Контроль программных конфигураций (Software Configuration Control)Контроль программных конфигураций касается вопросов управления изменениями в течениежизненного цикла программного обеспечения. Он включает процесс определения того, какие именноизменения должны быть сделаны, какие полномочия необходимы для утверждения определенных<типов> изменений, в чем состоит поддержка реализации этих изменений, а также концепциюформального утверждения отклонений от проектных требований, также как и отказа от внесенияизменений. Получаемая в результате этого информация полезна для количественной оценки потокаизменений, нарушения целостности <системы> и аспектов “переработки” в проекте (в большинствеслучаев, по времени, стоимости и усилиям - трудозатратам).3.1 Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving SoftwareChanges)Первый шаг по управлению изменениями контролируемых элементов состоит в определении того,какие именно изменения надо производить.
Процесс обработки запросов на изменения (softwarechange request process), представленный на рисунке 5, включает формальные процедуры попредложению (submitting) и записи (recording) запросов на изменения, оценки потенциальнойстоимости и влияния предлагаемых изменений, а также принятию, модификации или отказу отвнесенных предложений по изменениям. Запросы на изменения элементов программныхконфигураций могут вноситься любым лицом в любой точке жизненного цикла и может включатьпредлагаемые решения и соответствующий уровень приоритетности.
Один из источников запросовна изменения состоит в инициировании корректирующих действий в ответ на сообщения опроблемах (problem reports). Вне зависимости от источника запроса, в самом запросе на изменение(software change request, SCR) обычно записывается информация о его типе (например, “дефект”или “заявка на расширение функциональных возможностей”/”пожелание” – enchancement/suggestion).Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru13Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.Рисунок 5.
Поток процесса контроля изменений. [SWEBOK, 2004, с.7-7, рис. 5]Такой подход обеспечивает возможность отслеживания дефектов и сбора метрических показателейо деятельности по обработке и внесению изменений, с группировкой по типу изменений. Как толькополучен запрос на изменение (SCR), производится техническая оценка (включающая, а иногда иназываемая анализом влияний – impact analysis) запрашиваемых изменений для определениямасштабов модификаций, необходимых для удовлетворения параметров запрашиваемых изменений(достаточно часто, в результате такого анализа формулируются соответствующие требования,определяющие содержание необходимых работ).
Четкое понимание связей между программными (и,возможно, аппаратными) элементами системы является важной составной частью данной задачи.Наконец, органы, обладающие полномочиями, соответствующими затрагиваемой базовой линии,элементам программной конфигурации и природе изменений, должны оценить технические иуправленческие (организационные) аспекты внесения запрашиваемых изменений, а также принять,модифицировать, отклонить или отложить предлагаемые изменения.3.1.1 Совет по конфигурационному контролю (Software Configuration Control Board)Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются на<организационную> сущность, называемую совет по конфигурационному контролю - ConfigurationControl Board (чаще звучит как совет по координации изменений - Change Control Board, CCB).
Внебольших проектах такие полномочия могут, в действительности, принадлежать лидеру или одномуназначенному лицу из числа членов проектной команды. В общем случае может существоватьнесколько уровней полномочий в части принятия решений в отношении изменений, в зависимости отразличных критериев, таких как критичность предлагаемых изменений, их приоритет, природаизменений (например, параметры бюджета или расписания) или текущая точка жизненного цикла.Решения о том, кто именно будет включен в CCB для данной системы (проекта) могутварьироваться, в зависимости от данных критериев.
Однако, в CCB всегда должно присутствоватьлицо, вовлеченное в организацию конфигурационного управления. В CCB входят всезаинтересованные лица, чья роль соответствует уровню CCB. Когда содержание полномочий CCBохватывает только аспекты программного обеспечения, такой совет называется SoftwareConfiguration (Change) Control Board – SCCB. Деятельность CCB обычно является объектом аудитакачества или оценки.Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB,более обоснованным выглядит использование именно названия Change Coordination & Control Board– в общем случае звучащий как совет по координации и контролю изменений.3.1.2 Процесс обработки запросов на изменения (Software change request process)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru14Основы программной инженерии (по SWEBOK)Программная инженерия.
Конфигурационное управление.Эффективный процесс <обработки> запросов на изменения (SCR process) требует использованиясоответствующих средств поддержки и процедур <для данного вида деятельности>, от “бумажных”форм и документированных процедур (как последовательности действий или сценариев) допрограммных инструментов, позволяющих отсылать запросы на изменения, выполнять процессобработки таких запросов (изменять их статус, комментировать, детализировать и т.п.), фиксироватьрешения, принятые CCB, а также генерировать отчетную информацию по процессу обработкизапросов на изменения.
Связь между этими средствами и инструментами обработки отчетов обошибках может существенно облегчить определение решений для обнаруженных проблем.Обработка различных типов запросов на изменения в отношении разрабатываемых илимодифицируемых программных систем, будь то сообщения о проблемах (defect report) или запросына расширение функциональности (enchancement request), даже при разных процессах принятиярешений в отношении их, должны быть объединены в единую систему (в единой базой данных),являющуюся составной и неотъемлемой частью единой среды конфигурационного управления.Только в этом случае можно обеспечить однозначную и актуальную связь между запросамиразличных типов и другими активами проекта (кодом, документацией, проектными моделями,задачами, ресурсами и т.п.), что позволяет не только получать актуальную информацию в любоймомент времени, но и оперативно принимать те или иные (в том числе, управленческие) решения вотношении проекта, основываясь на максимально полном и корректном объеме информации.SWEBOK отмечает, что описания процессов и соответствующих форм (например, формы сообщенияо проблеме) можно найти в большом количестве внешних источников, в частности, указанныхнепосредственно в библиографии SWEBOK.3.2 Реализация изменений (Implementing Software Changes)Принятые (утвержденные) запросы на изменения (SCR) реализуются используя определенныепроцедуры, в соответствии с подходящими требованиями в отношении расписания.
Если наборутвержденных запросов на изменения может выполняться одновременно, необходимо обеспечитьотслеживание того, какие именно SCR реализованы в конкретной версии программного продукта ибазовой линии <конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии сclosure - “закрытием”, то есть завершением проекта), является аудит(ы) конфигурации(й) иверификация качества программного обеспечения. Это обеспечивает гарантию того, что быливнесены только утвержденные изменения.
Описанный выше процесс обработки запросов наизменения обычно включает документирование всей информации, связанной с принятымизменением.Фактическая реализация изменений поддерживается инструментальными средствамисоответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”),обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как минимум,эти инструменты должны поддерживать операции chek-in/check-out (помещение в репозиторий/получение из репозитория) и ассоциированные возможности по контролю версий (например, отметкаверсии – labeling, сравнение – compare/diff, слияние – merge и т.п.). Более мощные инструментымогут поддерживать параллельную разработку (parallel development) и среду географическираспределенной разработки (geographically distributed environment).
Эти инструменты могутобъявляться (в рамках организации) как отдельные специализированные приложения, целикомнаходящиеся под контролем независимой SCM-группы (как самостоятельной/выделеннойорганизационной сущности). Наконец, они могут быть столь элементарными, что включают толькоупрощенный контроль версий, например, на уровне файловой системы операционной среды.Безусловно, существует широкий спектр, обоснованных функциональных возможностейинструментальных средств, используемых для решения различных задач конфигурационногоуправления. При этом, при выборе соответствующего инструмента или комплекса инструментов,необходимо точно понимать их функциональную нагрузку, уровень интегрируемости, возможности поадаптации с учетом конкретных процессов жизненного цикла в проектной команде или организации,в целом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
