И. Соммервилл - Инженерия программного обеспечения (1133538), страница 153
Текст из файла (страница 153)
кументами, Такой подход, к тому же поддерживаемый некоторыми интегрированными САЗЕ. средствами, предоставляет возможность связать изменения, вносимые в систему, и с документами, и с теми компонентами, которые подверглись изменениям, В этом случае упрощается поиск измененных компонентов, поскольку установлены связи между документами (например, между документами по системной архитектуре и кодом программ) и этими связями можно управлять. Однако многие организации вместо использования интегрированных САВЕ. средств для управления конфиг)рацией рассматривают базу данных конфигураций как отдельную систему.
Конфигурационные элементы могут храниться в отдельных файлах или в системе управления всрсилми, например КСЗ (известнал система управления версиями для Ппгх (Ззб) ). В этом случае в базе данных конфи~ураний хранигсл информация о конфигурационных элементах и ссылки на имена соответствующих файлов в системе управленил версиями. Несмотря на отно. сительную дешевизну и гибкость такого подхода, основным недостатком его является то, что конфшурационпыс элементы могут быть изменены беэ внесения пеобхолнмых записей в базу дшнн ~х. Поэтому нельзя гарантировать, что в базе данных конфи1ураций содержится обновленная и корректная информация о состоянии системы.
29.2. Управление изменениями Изменения в больших программных системах неизбежны. Как отмечалось в предыдущих главах, в течение жизненного цикла системы изменяются пользовательские и сис. темные требования. а также приоритеты и запросы организаций. Процесс управления изменениями и соответствующие САБЕсредства предназначены для того, чтобы зарегистрировать изменения и внести их в систему наиболее эффективным способом. Процесс управления изменениями (листинг29.1) начинается после того, как программное обеспечение нли соответствующая документация передается команде по управ.
лепню конфигурацией. Он может начаться во времл тестирования системы нли даже после ее поставки закаэчику. Процедуры управления изменениями создаются для обеспечения корректного анализа необходимости изменений и их стоимости, а также для контроля эа вносимыми изменения. Листинг 29.1.
Процесс управления изменениями Запрос на изменение, заполнение формы запроса Анализ запроса дх изменение допустимо Вйвп Оценка способа внесения изменения Оценка стоимости изменения Запись запроса в базу данных Передача запроса группе контроля за изменениями дд запрос принят Язеп гвревк внесение изменений в ПО регистрация изменений передача измененного ПО группе управления качеством ипв11 качество ПО соответствует нормам создание ионой версии системы в1вв запрос на изменение отвергнут в1вв запрос на изменение отвергнут 29. Управление конфигурациями 891 Первым этапом в процессе управления изменениями является заполнение формы запроса на изменения, в которой указываются те изменения, которые планируется внести в систему.
В форме запроса также приводятся рекомендации относительно изменений, предварительная оценка затрат н даты запроса, его утвержденна, внедрения н проверки. Также форма может включать раздел, в котором указывается способ выполнения измене ння. Запросы на изменения регистрируются в базе данных конфигураций. Таким образом, команда управления конфнгурацнямн может следить за выполнением изменений, а также контролировать изменения определенных программных компонентов.
но врезке 29.1 прнведен пример заполненной формы запроса на изменения. Такая форма обычно определяется на этапе планнровання управления конфигурацией. По уело. виям некоторых контрактов (например„в контрактах с правительственными органами), такая форма должна соответствовать стандартам заказчика. ь ВРЕЗКа 29.1.
ГВОВМа ЗаПРОоа На ИЗМЕНЕНИПГ Г'-"'.-'-:: з."""' "" " '::: "' ' ' ' " "'Ь1 . Проект. Ргоипз/РС1:Тай, ';;.,:: '.::", ".::; Номер, 23/94,г. ч,:,, ' Лицо, заполнмощве запрос. Соммерзнль . Дзта. 1/12/98: -": ! 'Требуемые изменения, После выбора компонента структурах' необходимо отобрмкение'именй 'файла, в' 1 котором он хреннтсв. Лицо,осуществлямщееанализзапроса.Г;Дгш '",',,' ',:,' ' ',,', ", ' ',' ', ' „1 ! Дата анализа.
1%12/98 ИэиаияЕМЫЕ КОМПОНЕитЫ. 0щлау-)СОПсВЕИСГ, 01эр1ау 1СОП.рйрру , Связэннме комполакты. Неуаойг Оценка изменения. Изменение лопаточке легко выполнить нз.за наличия таблицы имен файлов: Тре-: ~ буется вставить соответствующее поле. Изменений связанных компонентов не требуется, Уроввнь прноритетв, Низ огй Выполнение изменения, ' ...: . "-"Псэзь т/:..: сс,, л:.':;,' Оцанкв затрат, 0,8 дня Дата первдачи в группу контроля эа изменениями. 15/12/98 Дата принятия решения группой контроля эа изменениями.
1/2/99 ' Решение группы контроля за изменениями, Принять изменение. Будет реализовано з версии 2.1. ~ Кто вносит изменения. Дата передачи запроса в группу управления качеством. ' ' ' ' Равенне группы управления качеством. ' Дата передачи запроса в группу по,управлению конфигурацией. Примечание. Сразу после представления заполненной формы запроса проводится проверка необходимости н допустимости изменения.
Это объясняется тем, что некоторыс пзменення вызва. ны нс оншбкамн в программе, а неправильным пониманием требований, друпге мопт дублнровать исправление ранее обнаруженных ошибок. Если в процессе проверки выявлястсл, что изменение недопустимо, повторяется нлн у~ко было рассмотрено, то изменение откло. нлется. Лицу, представившему запрос на изменение, объясняется причина отказа. Для принятых изменений начинается вторал стадия — оценка пзмепспнй н предварительное определение стоимости.
Сначала следует проверить влияние изменения на всю систему. Длл этого делается технический анализ способа внессшгл изменения. Затем определяется стоимость внесения изменения в определенные компоненты, что рсгнстрнру. 892 Часть уП. Эволюция программного обеспечения ется в форме запроса. В процессе оценивання полезна база данных конфигураций с информацией о взаимосвязях между компонентами, благодаря чему есть воэможность оце. нить влияние изменений на другие компоненты системы.
Все изменения, кроме тех, которые относятся к исправлению мелких недоработок, должны быть переданы в группу контроля за изменениями. где принимается решение о принятии изменения либо отказе. Эта группа оценивает воздействие изменения не с технической, а скорее с организационной или стратегической точек зрения. Во внимание принимаются такие соображения, как экономическая выгодность изменения и организационные факторы.
которые оправдывают необходимость изменения. Группа контроля за изменениями состоит из лиц, на которых возлагается ответственность за решения о внесении изменений. Такие группы со структурой, включающей старшего менеджера коьвгапии-заказчика и сотрудников фирмы-разработчика, обязательны при выполнении военных проектов. Для небольших или среднего размера проектов в эту группу может входип, только менеджер проекта и один-два инженера, которые не занимались разработкой данного ПО. В отдельных случаях допускается участие аналитика по изменениям, который дает реко.
мендэции относи гельно того, оправданы ати изменения либо нет. После принятия решения о внесении изменений программная система для внесения изменений передается разработчикам или команде по сопровождению системы. По окончании этой процедуры система обязательно должна пройти проверку на правильность внесения изменений. После этого именно команда по управлению конфигурацией, а не разработчики, займется выпуском новой версии.
Изменение каждого компонента системы должно регистрироваться. Таким образом создается история компонента. Самый лучший способ для этого — создавать сганлартизированные комментарии в начале кода компонента (листинг 29.2), где содержатся ссылки на запросы изменений данного компонента.
Для составления отчетов об изменениях компонента и обработки их историй используются специальные средства. Листинг 39.2. Заголовок компонента // Проект РЕОТЕ08 (ЕЯРК1Т 6087) // // РСЬ"ТООЬВ/ПРАВКА/ФОРИН/ОТОБРАЖЕНИЕ/ИНТЕРФЕЙСЫ // // Объект: РСЬ-Тоо1-Оеэс // Автор: Г.Дин // Дата создания: 10 ноября 1998 г. // // О Ьапсаэгег ОпдчегэЬГу 1998 // // История изменений // Версия Кто внес изменениядвта Изменение Причина // 1.0.
Дж. Джонс 1/12/1998 Добавление Предложена // заголовка группой по // управлению // конфигурацией // 1.1. Г. Дин 9/4/1999 Новое поле Запрос Е07/99 29.3. Управление версиями и выпусками Управление версиями и выпусками ПО нсобходимо для идентификации и слежении за всеми всрсиямн и выпусками системы. Менеджеры, отвечающие за управление версиямн и выпусками ПО, разрабатывают процедуры поиска нужных версий системы и следят за 29. Управление конфигурациями 593 тем, чтобы изменения нс осуществлялись произвольно. Онн также работают с заказчиками и планируют врсия выпуска следующих версий системы.
Над новыми версиями системы должна работать команда по управлению конфигурацией, а не разработчики, даже если новые версии предназначены только для внутреннего использования. Только в том случае, если информация об изменсниях в версиях вносится исключительно командой по управлению конфигурацией, можно гарантировать согласованность версий. Ве)!сией системы называют экземпляр системы, имеющий определенные отличия от других экземпляров этой жс системы. Новыс версии мокнут отличаться функциональными возможностями, эффективностью или исправлениями ошибок. Некоторые версии имеют одинаковую функциональность, однако разработаны под различные конфигурации аппаратного или программного обеспечения. Если отличия между версиями незначительны, они называются вп[еипнтаии одной всрсии.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
