И. Соммервилл - Инженерия программного обеспечения (1133538), страница 152
Текст из файла (страница 152)
рыс изл<снсния, исправляются ошибки предьщущих версий; кроме того, версии могут адаптироваться к новым аппаратным средствам и операционным системам. При этом в разработке и эксплуатации мо<уг одновременно находиться сразу несколько версий. Поэтому нужно четко отслеживать все вносимые в систему изменения.
Процедуры управления конфигурацией регулируют процессы регистрации и внесения измснсний в систему с указанисм измененных компонентов, а также способы идентификации различных версий системы. Средства управления конфигурацией применяют для хранения всех версий системных компонентов, для компоновки из этих компонентов системы и для отслеживания поставки заказчикам разных всрсий системы. Как указывалось в главе 24, управление конфигурацией нередко рассматривается как часть общего процесса управления качеством.
Поэтому иногда одно н то же лицо может отвечать как за управление качеством. так и за управление конфигурацией. Но обычно разрабатываемая программная система сначала контролирустся командой по управлению качеством, которал проверяет ПО на соответствие опрсделенным стандартам качества. Далее ПО персдастся команде по управлению конфигурацией, которая контролирует измснснил, вносимые в систему. Существует много причин, объясняющих наличие разных конфигураций одной и той жс системы. Различные версии создаются для разных компьютеров или операционных систем, включающих специальные функции, нужные заказчикам. и т.д. (рис, 29.1).
Менеджеры по управлению конфигурацией обязаны следить за различиями между разными версиями. чтобы обеспечить возможность выпуска следующих вариантов системы и своевремсин)ю поставку нужных версий соответствующим заказчикам. <-ис 29 Е Ссисйсэмо версий <исимии Процесс управления конфи<урацисй и связанная с ним документация должны подчинлться определенным стандартам. В качестве примера можно привести сгандарт1ЕЕЕ 828- 1983.
определяющий составление планов управления конфигурацией. Каждая организация должна иметь справочник, в котором указаны эти стандарты, либо они должны входить в общий справочник стандартов качества. Общенациональные или международные стандарты мо<уг быть также использованы как основа для разработки детализированных специальных норм и стандартов для конкретных организаций. За основу можно взять любой тпп стандарта, поскольку все они содержат описания однотипных процессов. Для сертификации качества своих программных продуктов организация должна придержи. 29.
Управление конфигурациями 887 ваться официальных стандартов управления конфигурацией, которые приведены в стандартах 15О '.!000 [178) н в модели оценки уровня развития 5Е! (278). При традиционной разработке ПО в соответствии с каскадной моделью (см. главу 8) разрабатываемая система попадает в группу по управлению конфилурацией уже после полного завершения разработки и тестирования ПО. Имешю такой подход лежит в основе ставщартов управленил конфигурацией, которые, в свою очередь, обусловливают необходимость использованил для разработки систем моделей, подобных каскадной (88). По. этому упомянугые стандарты не в полной мере подходят при использовании таких методов разработки ПО, как эволюционное прототипирование н пошаговая разработка. В этой ситуации нскоторыс организации нзлгснили полход к управлению конфигурацией.
сделав возможным параллельную разработку и тестирование системы. Такой подход основан на регулярной (иногда ежедневной) сборке системы из ес компонентов. 1. Устанавливается время, к которому должна быть завершена поставка компонентов системы (например, к 14.00). Программисты, работающие нзд новыми версиями компонентов, должны предоставить их к указанному времени. Работу над компо. нентами пе обязательно завершать, достаточно представить основныс рабочие функции для проведения тестирования.
2. Создаетсл новая версил системы с новыми компонентамн, которые компилируются и связываются в единую систему. 3. После этого система попадает к группе тестирования. В то же время разработчики продолжают работу над компонентами. добавлля новые функции и исправляя ошибки, обнаруженные в ходе предыдущего тестирования. 4. Дефекты, замеченные прн тестировании, регистрируются, соответствующий доку мент пересылается раэработчикаль В следующей версии колшонента зти дефекты будут учтены и исправлены. Основным преимуществом ежедневной сборки системы является возможность выявления ошибок во взаимодействиях между компонентами, которые в противнолл случае могуг налвпливаться.
Более того, ежедневная сборка системы поощряет тшательнчо проверку компонентов. Разработчики работают под давлением: нельзя прерывать сборку систем и п<ктавлять неисправные версии компонентов. Поэтому программисты неохотно посгавллют новые версии компонентов, если они нс были предварительно тщательно проверены. Таким образом, на тестированиее и исправление ошибок ПО уходит меньше времени. Для ежедневных сборок системы требуется достаточно строгое управление процессом изменений, позволяющее отслеживать проблемы, которые выявляются и исправляются в ходе тестирования.
Кроме того, в результате возникает ллножсство версий компонентов системы, для управления которыми необходимы средства управления конфигурацией. 29.1. Планирование управления конфигурацией В плане управлении конфигурацией представлены стандарты. процедуры н мероприятия, необхолимые для управления.
Отправной точкой создания такого плана является на. бор общих стандартов по управлению конфигурацией, применлемых в организации- разработчике ПО, которые адаптируются к каждому отдельному проекту. Обычно план управления конфигурацией имеет несколько разделов. 588 'Часть угП. Эволюция программного обеспечения 1. Определение контролируемых объектов, подпадающих под управление конфигурацией, а также формальная схема определения этих объектов. 2. Перечень лиц, ответственных за управление конфигурацией и за поставку контролируемых объектов в команду по управлению конфигурацией. Полигика ведения управления конфигурацией, т.е.
процедуры управления изменениями и версиячн. 4. Описание форм записей о самом процессе управления конфигурацией. 5. Описание средств поддержки процесса управления конфигурацией и способов их использования. 6. Определение базы данных конфигураций, применяемой для хранения всей информации о конфигурациях системы. Распределение обязанностей по конкретным исполнителям является важной частью плана.
1|еобходимо четко определить ответственных за поставку каждого документа или компонента ПО для команд по управлению качеством и конфигурацией. Лицо, отвечаю. щее за поставку какого. либо документа или компонента, должно отвечать и за их разработку. Для упрощения процедур согласования удобно назначать менеджеров проекта или ведущих специалистов команды разработчиков ответственными за все документы, созданные под их руководством. 29.1.1. Определение конфигурационных объектов В процессе разработки больших систем создаются тысячи различных документов. Большинство из них — это текущие рабочие документы, связанные с различными этапами разработки ПО. Есть также внутренние записки, протоколы заседания рабочих групп, проекты планов и предложениИ и т.п.
Такие документы представляют разве что исторический интерес и не нужны для дальнейшего сопровождения системы. Для планирования процесса управления конфигурацией необходимо точно определить, какие проектные элементы (или классы элементов) будут объектами управления. Такие элементы называются конфигурационными ыечеявани. Как правило, они представляют собой официальные документы. Конфигурационными элементами обычно являются планы проектов, спецификации, схемы системной архитектуры, программы и наборы тестовых данных.
Кроме того, управлению подлежат все документы, необходимые для будущего сопровождения системы. В процессе управления конфигурацией каждому документу необходимо присвоить уникальное имя, причем отображающее связи с другими документами. Для этого исполь зустся исрархическая система имен, где они имеют, например, такой внд: РЪС.ТОО|5/ПРАВКА/ФОРМЪ|/ОТОБРАЖЕНИЕ/ИНТЕРфЕйСЫ/КОД Р!.С-ТОО|5/ПРАВКА/СПРАВКА/ЗАПРОС/ОКНО СПРАВКИ/Гй-1 Начальная часть имени — это название проекта РЪС-ТОО|.8. В проекте разрабатываются четыре отдельных средства (рис. 29.2). Имя средства используется в следующей час.
ти имени. Каждое средство создается из именованных модулей. Такое разбиение продол. жается до тех пор, пока не появится ссылка на официальный документ базового уровня. Листья дерева иерархии документов являются официальными документами проекта На рис. 29.2 показано, что для каждого объекта требуется три формальных документа.
Это описание объектов (документ ОБЪЕКТЫ), код компонента (документ КОД) и набор тес. тов для этого кода (документ ТЕСТЪ|). 29. Управление конфигурациями 589 Риг. 29.2. Иерархия конфигурации Подобные схемы имен основаны на структуре проекта, когда имена соотносятсл с соответствующими проектными компонентами Такой подход к именованию документов порождает определенные проблемы. Наприлзер, снижается возможность повторного использования компонентов. Обычно в таких случаах из схемы берутся копии компонентов, которые можно повторно использовать, и переименовываются в соответствии с новой областью применения.
Другие проблемы могут появиться, если эта схема именования документов используется как основа структуры храпения компонентов. Тогда пользователь должен знать названия документов, чтобы найти нужные компоненты, при этом нс все документы одного типа (например, по проскгированию) хранятся в одном месте. Также могут встретиться трудности при установлении соответствия между схемой имси и схемой идентификации, используемой в системе управления версиями. 29.1.2. База данных конфигураций Такая база данных исгюльзуется для хранения всей информации о системных конфигурациях. Основными функциями базы данных конфигураций являются полдсржка оцепивания влияния планируемых изменений в системс и предоставление информации о процессе управления конфигурацией.
Задание структуры базы данных коифи~урацнй. определение процедур записи и поиска информации в этой базе лаппых — все это лвлястсл частью процесса планирования управления конфигурацией. Информация, заключенная в базе данных конфигураций, должна помочь ответить па ряд вопросов, среди которых основными и часто запрашиваемыми будут следующие. ° Каким заказчикам поставлена определениал версия системы? ° Какие аппаратныс средства и какая операционная система необходимы для работы данной версии систсл~ы? э Сколько было выпущено версий данной системы п когда? ° !!а какие версии с~ктемы повлияют изменения, вносимые в определенный компонент? ° Сколько запросов на измеиепил было реализовано в данной версии? ° Какое количество ошибок было зарегистрировано в данной версии системы? 590 з1асть 711. Эволюция программного обеспечения В идеале база данных конфигураций должна быть объединена с системой управления версиями, которая создается для хранения и управления формальными проектными до.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
