Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оглавление

1. Описание конфигурационного управления

2. Цели и задачи

3. Процедуры управления конфигурацией

4. Описание плана управления конфигурацией

4.1 Кто пишет план?

4.2 Когда готовят план управления конфигурацией?

4.3 Поддержка плана в актуальном состоянии

4.4 План управления конфигурацией в стандартах

4.5 Факторы, влияющие на структуру плана управления конфигурацией и его детализацию

Глоссарий

Список литературы

1. Описание конфигурационного управления

Конфигурационное управление (англ. software configuration management, SCM) в программной инженерии -- комплекс методов, направленных на систематический учёт изменений, вносимых разработчиками в программный продукт в процессе его разработки и сопровождения, сохранение целостности системы после изменений, предотвращение нежелательных и непредсказуемых эффектов, формализацию процесса внесения изменений.

Изначально управление конфигурацией применялось не в программировании. Под конфигурацией понимался состав деталей конечного продукта и «взаимное расположение частей» физического изделия. Таким образом, конфигурацией можно управлять, контролируя документы, описывающие конечный продукт, требования к нему, всю его проектную и технологическую документацию.

В связи с высокой динамичностью сферы разработки ПО, в ней конфигурационное управление особенно полезно. К процедурам можно отнести создание резервных копий, контроль исходного кода, требований проекта, документации и т. д. Степень формальности выполнения данных процедур зависит от размеров проекта, и при правильной её оценке данная концепция может быть очень полезна

2. Цели и задачи

Цели конфигурационного управления:

· Контроль: SCM позволяет отслеживать изменения в контролируемых объектах, обеспечивает соблюдение процесса разработки

· Управление: SCM диктует процесс автоматической идентификации в ходе всего жизненного цикла ПО, обеспечивает простоту модификации и сопровождения ПО

· Экономия средств: снижается риск потерь от ротации кадров в организации, предоставить возможность сменить организацию-разработчика без перепроектирования

· Качество

Задачи конфигурационного управления:

· Идентификация конфигурации

· Контроль конфигурации: контроль над изменениями материалов

· Учёт текущего состояния: состояние документов, состояние кода, состояние отдельных задач и всего проекта в целом

· Управление процессом разработки

· Управление сборкой

· Управление окружением

· Отслеживание задач и проблем (в частности, отслеживание ошибок)

3. Процедуры управления конфигурацией

Ревизия конфигурации -- процесс проверки того, что документ нижнего уровня соответствует всем требованиям документа верхнего уровня.

Аудит конфигурации -- процесс проверки того, что готовый продукт или его часть соответствуют документации.

Контроль конфигурации -- процесс, при котором все предлагаемые изменения продукта проходят одобрение специальной группы (или отдельного человека). Одна из функций такой группы -- контроль актуальности всех имеющихся документов, а также контроль того что все изменения сначала вносятся в документацию, а уже затем в объект изменения.

Учет состояния конфигурации -- процесс подготовки отчетов о текущем состоянии продукта и состоянии утвержденных изменений.

4. Описание плана управления конфигурацией

Многие компании при попытке поставить любой процесс (не важно какой, но в данном случае - Управления Конфигурациями(УК)) ограничиваются только инсталляцией программных средств с минимальными затратами в дальнейшей работе. Так был загублен не один проект. Во-первых, всегда должна быть планомерная работа. А во-вторых, сначала внедряется процесс, а потом инсталлируются средства автоматизации (уж никак не наоборот). Соответственно, если есть процесс, то должен быть документ, описывающий его. Таким документом для процесса УК является «План управления конфигурациями», где излагается концепция процесса и имплементация средств автоматизации. В нем же расписываются все роли, и, что особенно важно, деятельности в зависимости от стадии жизненного цикла разработки ПО.

Данный план является основным документом, регламентирующим все дальнейшие проектные действия, связанные с конфигурационным управлением. В плане необходимо отмечать то, каким образом будет достигаться та или иная цель: ведь одну и ту же задачу можно решать различными способами, но, однажды выбрав определенное решение, не рекомендуется изменять его в процессе работы.

План должен быть документально оформлен и выполнен (план может быть частью плана управления конфигурацией системы).

План на высоком уровне определяет процесс разработки ПО. План также содержит в себе много административных моментов, которые необходимо реализовать в настройках инструментальных средств УК, чтобы они соответствовали плану.

4.1 Кто пишет план?

По большому счету написание плана - коллективная работа. Здесь задействованы все участники проекта, так как на основе их информации и рождается план УК.

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана - Менеджер УК.

Менеджер Управления Конфигурациями - ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

Очень часто пытаются либо вообще обойтись без такой роли, либо «спихивают» ее на разработчиков. Естественно, это неправильно, так как разработчик не видит всей картины процесса разработки, может не понимать структурных взаимодействий между отделами… и т.д. Перечень непониманий можно продолжать далее. На первых порах, на порах становления роль менеджера берет на себя человек, который имеет представление о процессе разработки. Такой человек всегда есть в коллективе, как правило, это лидер разработчиков или руководитель отдела разработки.

Техническое применение плана (реализация плана в средствах поддержки УК)

Как мы уже говорили выше - план содержит высокоуровневое описание процесса, но чтобы инструментальные средства поддержки УК начали следовать плану, необходимо выполнить их физическую настройку:

· Установить средства;

· Разработать экранные формы запросов на изменение;

· Установить политику доступа;

· Определить жизненный цикл запросов на изменение;

· Поставить данные под УК в соответствии с планом;

· И т.д.

Физическую настройку обычно проводит администратор, который на основании имеющегося плана проводит физические настройки инструментальных средств УК.

4.2 Когда готовят план управления конфигурацией?

конфигурационный управление программирование

План разрабатывается на ранних стадиях общего планирования проекта. План должен быть подготовлен на самых ранних стадиях, еще до того, как разработчики включили компьютеры - момент проработки технического задания уже нужно писать план УК. Это в идеале. На практике, как правило, процесс уже сложился и его требуется сначала описать, а потом, по потребностям модифицировать, улучшить.

Что хорошо в плане УК, так это то, что он долго пишется всего один раз. Далее для каждого проекта пишется новый план, на основе существующего, так как способы и методы в новом проекте могут отличаться, то и план описывает все особенности данного проекта. Иногда применяется практика выделения общих частей плана УК и утверждение их как составная часть стандарта на разработку в компании. После чего каждый проект использует общий план + выпускает к нему набор дополнений для конкретного проекта. Впрочем, набор дополнений не может противоречить основному плану.

4.3 Поддержка плана в актуальном состоянии

4.5 Факторы, влияющие на структуру плана управления конфигурацией и его детализацию

На сам план при его разработке влияют множество факторов. Структура плана УК, и его содержание, зависит от таких факторов, как тип проекта и его длительность, уровень формализации процессов, размер команды (наличие регионально распределенных групп), количество субподрядчиков, и многих других. Это означает, что структура плана, состав приложений могут в достаточно больших пределах варьироваться, сохраняя при этом единый «дух».

Глоссарий

1.Конфигурационное управление (англ. software configuration management, SCM) в программной инженерии -- комплекс методов, направленных на систематический учёт изменений, вносимых разработчиками в программный продукт в процессе его разработки и сопровождения, сохранение целостности системы после изменений, предотвращение нежелательных и непредсказуемых эффектов, формализацию процесса внесения изменений.

2. План управления конфигурацией - основной документ, регламентирующий все проектные действия, связанные с конфигурационным управлением.

3. Программное средство - набор компьютерных программ, процедур и связанных с ними документации и данных.

4. Инструментальное программное обеспечение -- программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ.

5. Конфигурационный файл - особым образом форматированный текстовый файл, используемый для хранения настроек.

6. Техническая документация -- набор документов, используемых при проектировании (конструировании), изготовлении и эксплуатации каких-либо технических объектов.

7. Ревизия конфигурации -- процесс проверки того, что документ нижнего уровня соответствует всем требованиям документа верхнего уровня.

8. Аудит конфигурации -- процесс проверки того, что готовый продукт или его часть соответствуют документации.

9. Контроль конфигурации -- процесс, при котором все предлагаемые изменения продукта проходят одобрение специальной группы (или отдельного человека). Одна из функций такой группы -- контроль актуальности всех имеющихся документов, а также контроль того что все изменения сначала вносятся в документацию, а уже затем в объект изменения.

10. Учет состояния конфигурации -- процесс подготовки отчетов о текущем состоянии продукта и состоянии утвержденных изменений.

Список литературы

1. Липаев В.В. «Документирование и управление конфигурацией программных средств», М., «Синтег», 1998.-203с.

2. Липаев В.В. « Документирование сложных программных средств», М.,» Синтег».2005-200 с.

3. http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5 Википедия “Конфигурационное управление”

4. http://cmcons.com/articles/CC_CQ/paln_cm/ Описание плана управления конфигурацией

5. http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%98%D1%81%D1%82%D0%BE%D1%87%D0%BD%D0%B8%D0%BA%D0%B8_%D0%BA%D0%BD%D0%B8%D0%B3/0321685865 Aiello, R. (2010). Configuration Management Best Practices: Practical Methods that Work in the Real World (1st ed.). Addison-Wesley. ISBN 0-321-68586-5.

6. http://www.sorlik.ru/swebok/3-6-software_engineering_configuration_management.pdf Сергей Орлик. Программная инженерия. Конфигурационное управление

7. http://citforum.ru/SE/quality/configuration_management/ Дмитрий Лапыгин, Александр Новичков. Конфигурационное управление проектами разработки программного обеспечения (2004).

8. http://cmcons.com/articles/CC_CQ/paln_cm/ Александр Новичков, Дмитрий Лапыгин. Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа

9. http://experience.openquality.ru/software-configuration-management/ Юрий Удовиченко. Управление конфигурациями или кессонная болезнь проектов

10. http://scm-notes.blogspot.ru/ Записки отставного сиэмщика: блог, статьи и книги по Software Configuration Management

Размещено на Allbest.ru