И. Соммервилл - Инженерия программного обеспечения (1133538), страница 155
Текст из файла (страница 155)
бенно это касается рынка массовых программных продуктов. Если выпуски выходных вер. сий осуществляются слишком часто, пользователи не успеют осознать потребность в расширенных возможностях новых версий, а если выходные версии создаются редко, существует вероятность потери рынка сбыта, поскольку пользователи переходят к альтернативным системам. Это не относится к программным продуктам, созданным под заказ для определенной организации. Однако и туг редкие выходные версии могут привести к расхождению программной системы и тех бизнес-процессов, для поддержки которых система была разработана.
Принятие решения о том, когда именно должна выйти следующая выходная версия системы, существенно зависит от технических и общих организационных факторов, которые описаны в табл. 29.1. 29. Управление конфигурациями $97 в электронном виде. Должны быть написаны сценарии для инсталляционной программы. В завершение создается инсталляционный диск, на котором будет распространяться система. В настоящее время в качестве носителей дистрибугивов наиболее широко распро.
странены компакт-диски емкостью до 600 Мбайт. Докумеитироваиие выходной версии Процесс создания выходной версии должен быть зздокументирован, чтобы была возможность восстановить ее в будущем. Зто особенно важно для больших систем с длинным жизненным цикэом, разрабатываемых под заказ. Заказчики обычно используют одну версию системы на протяжении многих лет, и все необходимые изменения вносятся именно в эту версию через много лет после ее поставки. Для документирования выходной версии прежде всего необходимо записать версии исходного кода компонентов, которые использованы для создания исполняемого кода. Также гледует собрать и сохранить все копии исходных и исполняемых кодов, системных данных и конфи~урагщонных файлов.
Кроме того, должны быль записаны версии операционной системы, биб. лиотеки, компиляторы и другие средства, прииеняемые для сборки системы. 29.4. Сборка системы Сборкой системы называют процесс компиляции и связывания программных компо. нентов в единую исполняемую программу. Пород сборкой системы полезно ответить на следующие вопросы. К Все ли компоненты, составллющие систему, вкэючены в инструкцию по сборке? 2.
Каковы версии компонента, перечисленные в инсгрукции по сборке? 3. Доступны ли все необходимые файлы данных? 4. Если на файлы данных используются ссылки внутри компонентов. то каковы имена этих файлов в выходной версии? 5. Доступны ли нужные версии компилятора и других необходимых средств? Дейсгвующие версии программных средсгв могуг быть несовместимы с более старыми версиями, которые применялись при разработке системы.
В настоящее время существует много средств управления конфигурациеИ, автоматизирующих процесс сборки системы. Команда управления конфигурацией пишет сценариИ, в котором определены зависимости между различными колгпонентами системы. В нем также указаны средства компилирования и связывания компонентов системы. Средства ком. поповки интерпретируют сценарий сборки системы и вызывают программы, необходимые для сборки исполняемой системы. Процесс сборки системы представлен на рис. 29.4. Рис 29.4. Сйфкл сисяенм 508 Часть ин. Эволюция программного обеспечения В сценарии сборки указаны зависимости между компонентами, поэтому компоновщик сисгемы сам принимает решение, когда перекомпилировать компоненты, а когда можно многократно использовать существующий объектный код. Зависимости в сценарии сборки указаны в основном как зависимости между файлаии, содержащими исходный код компонентов.
Однако, если файлов с исходным кодом разных версий много, возникает про. блема выбора нужных файлов. Проблема усугубляется, если файлы исходного и объектно. го кода имеют одинаковые имена (но, конечно, с разными расширениями). Чтобы избежать трудностей, связанных с зависимостью физических файлов, было разработано несколько экспериментальных систем, основанных на языках описания модулей [$20], В них используется описание логической структуры ПО и схемы зависимостей между файлами, содержащими компоненты исходного кода. Такой подход снижает количество ошибок и приводит к более понятным описаниям процесса сборки системы. 29.5. САЯЕ-средства для управления конфигурацией Процесс управления конфигурацией обычно стандартнзирован и включает выполнение заранес определенных процедур. Они требуют детализированного контроля за очень большим количеством данных.
При сборке системы единственная ошибка в управлении может привести к некорректной работе системы. Поэтому очень важна поддержка про. месса управления конфигурацией соответствующими САБЕ-средствами. Нани!!ая с 70-х го. дов было разработано большое количество программных средств поддержки разных аспектов процесса управления конфигурацией. Примераии первого поколения средств управления конфи!урацисй могут служить сис. темы БССБ [297] и КСБ [Збб], предназначенные для управления версиями и сборкой систем [114). Это автономии!е средства, которые поддерживали отдельные действия в процессе управления конфигурацией. Средства второго поколения, например $Лсорап [342) и )УБЕЕ [212), обеспечивают интегрированную поддержку процесса управления конфигурацией, однако некоторые этапы управления они не обеспечивали.
Во время написанил данной книги были доступны интегрированные пакеты САБЕ-средств, поддерживающие планирование управления, процессы управления изменеиилми, версиями и сборкой системы [211]. Однако эти пакеты достаточно сложные, требуют усилий для изучения и освоения, поэтому мнопсе организации-разработчики продолжают использовать средства поддержки первого и второго поколений'. 29.5.1. Средства поддержки управления изменениями Процесс управления изменениями заключается в заполнении форм запросов на изменения, проведении анализа изменений и передаче этих форм и соответствующих конфигурационных элементов команде управления качеством и команде по управлению конфигурацией.
Этот алгоритмический по своей природе процесс позволяет сравнительно легко интегрировать его с системой управления версиями, поскольку, упрощая, можно сказать, что задача управления изменениями заюпочается в передаче нужных документов нужным людяи в нужное время. Лромс пс)ичнсхснных свуЖсредств поддсрхгкт нроумсл уг!Раввины конфпсрлунп1, насосом смс Ли!!овса! сссагсдт опг Лпцона! Бо/гнат н ссчмсство продуктов Р1гбу Рт/ессгопа! н Р1гГ5 Хо!гуу от фир ног Мгганг, кото )гыс мотка вгт!и титв у многнх Рососдгкн» Ргсг)тдоогч иков г!О.
— Прим, рсл. 29. Управление конфигурациями 599 Поэтому для поддержки процесса управления изменениями достаточно следующих средств. 1. Редактор ферм, позволяющий создавать и заполнять формы запросов па изменения. 2. Система автаиатизации дтгумеиэювбврвта, которая позволяет фиксировать закрепление обработки форм запросов на изменения за членами команды по управлению конфигурацией и определяет порядок этой обработки. Эта система может также автоматизировать процесс передачи заполненных форм "нужным людям в нужное время" и информировать о состоянии процесса внесения изменений.
)ьак правило, эта система использует электронную почту для пересылки сообщений. 3. База данных измеиекий, которая используется для хранения всех предложенных из- менений и может быть связана с системой управления версиями. 29.5.2. Средства поддержки управления версиями Управление версиями предполагает обработку больших массивов информации для ре. гистрации изменений, вносимых в систему, и контроля та ними.
Средства управления версиями обязателыю включают репозитарий конфигурационных элементов, которые в дальнейшем не изменяются. Если необходимо изменить какой-либо конфигурационный элемент, находящийся в репозитарии, его копия помещается в рабочий каталог. После изменений новая версия элемента также помещается в репозитарий. Системы управления версиями могут отличаться друг от друга, но все они имеют базовый набор средств. 1.
Средство идеитигвикации версий. Системы управления версиями могут поддерживать различные подходы к идентификации версий (сы. раздел 29З.1). 2. Средевме уяраатяия хранением версий Чтобы уменьшить пространство, необходимое для хранения различных версий системы, которые могут быть значительных размеров, системы управления версиями используют специальные средства управления хранением, когда хранятся ие сами версии, а их отличия от некоторой базовой версии. Различия между версиями представляются в виде дельвгы где собраны инструкции, необходимые для воссоздания соответствующей версии системы. На рис. 29.5 показано, как из последней версии можно восстановить более раннюю версию системы. Время создание версий рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
