6-software_engineering_configuration_manag ement (1133546), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Управление SCM-процессом (Management of SCM Process)SCM-деятельность контролирует эволюцию и целостность продукта, идентифицируя его элементы,управляя и контролируя изменения, а также, проверяя, записывая и обеспечивая отчетность поконфигурационной информации. С инженерной точки зрения, SCM способствует разработке иреализации изменений. Успешное внедрение SCM требует точного планирования и управления. Это,Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru4Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.в свою очередь, предполагает понимание организационного контекста и тех ограничений, которыесвязаны с проектированием и реализацией процесса конфигурационного управления.1.1 Организационный контекст SCM (Organizational Context for SCM)Для планирования SCM-процесса необходимо понимать организационный контекст и связи междуорганизационными элементами.

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

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

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

Сточки зрения составителей <данной области знаний SWEBOK>, некоторые элементы, находящиесяпод управлением SCM <процесса>, могут также служить объектами рассмотрения в рамкахорганизационных программ по обеспечению качества. Управление несогласующемися элементамиобычно относится к работам по управлению качеством. Однако, SCM может обеспечитьсущественную помощь в отслеживании (трассировке) и создании отчетности по элементампрограммных конфигураций, попадающих в такую <проблемную> категорию.SWEBOK отмечает, что возможно тесное взаимодействие между организационными структурами,отвечающими за разработку и сопровождение (и SCM играет роль инфраструктуры,обеспечивающей такую связь).В зависимости от контекста, существует множество подходов и практик в части выполнения задачконфигурационного управления в приложении к программному обеспечению.

Часто, одни и те жеинструменты поддерживают и разработку, и сопровождение, обеспечивая достижение целей исодержания SCM.1.2 Ограничения и правила SCM (Constraints and Guidance for the SCM Process)Ограничения и правила в отношении процесса конфигурационного управления порождаютсяразличными источниками. Политики и процедуры, формулируемые на корпоративном или другоморганизационном уровне, могут влиять или предписывать структуру и реализацию SCM-процессадля заданного проекта. Кроме того, контракт между заказчиком и поставщиком может содержатьположения, затрагивающие процесс конфигурационного управления.

Например, может требоватьсяпроведение определенных процедур проверки (аудита) или специфицирован набор элементов(активов, артефактов), передаваемых под управление <процедур и системы> конфигурационногоуправления (или в части формализации обработки и контроля реализации запросов на изменения,поступающих от заинтересованных лиц). Когда разрабатываемый программный продуктпотенциально затрагивает аспекты публичной безопасности, могут налагаться определенныеограничения со стороны соответствующих регулирующих органов (например, USNRC Regulatory Guide1.169, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of NuclearCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru5Основы программной инженерии (по SWEBOK)Программная инженерия.

Конфигурационное управление.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 – ProcessAssessment”.1.3 Планирование в SCM (Planning for SCM)Планирование процесса конфигурационного управления для заданного проекта должносогласовываться с организационным контекстом, соответствующими ограничениями,общепринятыми рекомендациями, а также характеристиками и природой самого проекта (например,его размером или значимостью). Основные работы, проводимые при планировании SCMдеятельности включают: Идентификацию программных конфигураций (Software Configuration Identification) Контроль конфигураций (Software Configuration Control) Учет статусов конфигураций (Software Configuration Status Accounting) Аудит конфигураций (Software Configuration Auditing) Управление выпуском и поставкой (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, разработку, проверку и аттестацию и т.п.). Значимостьинструментальной поддержки конфигурационного управления (как и других аспектов деятельности вобласти программной инженерии) растет с каждым днем вместе со сложностью внедрения, ростомCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия.

Конфигурационное управление.размера проектов и сложности проектного окружения. Возможности инструментальных средствразвиваются для обеспечения поддержки: 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.

Характеристики

Список файлов книги