exam05 1
Реферат к лекции 5 (21). Проектирование конфигурационного управления
Выполнил: Светличный Егор, ИДБ-18-06
Проверил: Косилов Глеб, ИДБ-18-06
В 1950-х годах Министерство обороны США разработало техническую управленческую дисциплину для отслеживания изменений при разработке сложных систем. У этой системы и ее итераций были сугубо технические названия, но в 2001 году Министерство опубликовало сводное руководство, в котором закрепило понятие системы технического управления. Сегодня это называется «управление конфигурацией». В настоящее время управление конфигурацией используется не только в министерстве обороны, но и при разработке программного обеспечения, управлении ИТ-услугами, в гражданском строительстве, промышленном машиностроении и многих других отраслях.
В каждой ИТ-организации имеется информация об ИТ-инфраструктуре. Она чаще всего появляется после реализации крупных проектов, которые обычно завершаются проведением аудита и анализом результатов. Главным в работе с такой информацией является поддержание ее в актуальном состоянии. Процесс Управления Конфигурациями помогает получать достоверную и актуальную информацию об ИТ-инфраструктуре. Важным в этой информации является то, что в нее входят данные не только о конкретных единицах конфигурации, но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами, и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц.
Конфигурация– это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов». В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта. Далее, каждый продукт изменяется во времени, и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.
Версия– это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.
Управление конфигурациями — процесс, отвечающий за управление информацией о конфигурационных единицах (включая их взаимоотношения), необходимой для предоставления ИТ-услуг. Этот процесс и есть область действия CM. В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM.
Цель процесса управления конфигурациями — сбор и актуализация информации о составляющих частях IT-инфраструктуры, обеспечение данной информацией прочих процессов Управления услугами.
Конфигурационная единица (сonfiguration item или CI) — элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса управления конфигурациями. Конфигурационными единицами могут являться любые элементы, которыми необходимо управлять с точки зрения жизненного цикла ИТ-услуги. Точных рекомендаций по тому, что считать конфигурационной единицей, не существует. Однако различные источники (в том числе ITIL) дают подсказки: это может быть аппаратное и программное обеспечение, документация и даже персонал. То есть любой ИТ-актив, сервисный компонент или любой другой элемент, который задействован на протяжении жизненного цикла ИТ-услуги.
Рис. 1. Элементы, их версии и срезы-конфигурации.
CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.
Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. На втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.
Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM.
Задачи управления конфигурацией
- идентификация рабочих продуктов;
- стабилизация результатов работы и определение базы для дальнейшей работы;
- отслеживание запросов на изменение;
- контроль версий;
- обеспечение параллельности разработки;
- сбор метрик и формализация применяемых методов.
Изначально управление конфигурацией применялось не в программировании. Под конфигурацией понимался состав деталей конечного продукта и «взаимное расположение частей» физического изделия. Таким образом, конфигурацией можно управлять, контролируя документы, описывающие конечный продукт, требования к нему, всю его проектную и технологическую документацию. В связи с высокой динамичностью сферы разработки ПО, в ней конфигурационное управление особенно полезно. К процедурам можно отнести создание резервных копий, контроль исходного кода, требований проекта, документации и т. д. Степень формальности выполнения данных процедур зависит от размеров проекта, и при правильной её оценке данная концепция может быть очень полезна.
Список литературы: