Создание версии и инсталляции программного продукта

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

В процессе инсталляции ПП могут проявиться различные про­блемы. Наиболее часто встречаются следующие.

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

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

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

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

Выходная версия (release), или поставка ПП, — это та версия, которая поставляется заказчику. В каждой выходной версии либо обязательно присутствуют новые функциональные возможности, либо она разработана под новую платформу. Число версий обычно намного превышает число поставок, поскольку версии создаются в основном для внутреннего пользования и не поставляются за­казчику.

В настоящее время для поддержки управления версиями разра­ботано много разнообразных CASE-средств, с помощью которых осуществляются управление хранением каждой версии и конт­роль за допуском к компонентам ПП. Компоненты могут извле­каться из ПП для внесения в них изменений. После введения в ПП измененных компонентов получается новая версия, для кото­рой с помощью системы управления версиями создается новое имя.

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

1. Нумерация версий. Каждый компонент имеет уникальный и явный номер версии. Этот способ идентификации используется наиболее широко.

2. Идентификация, основанная на значениях атрибутов. Каж­дый компонент идентифицируется именем, которое не является уникальным для разных версий, и набором значений атрибутов, разных для каждой версии компонента. Другими словами, версия компонента идентифицируется комбинацией имени и набора зна­чений атрибутов.

3. Идентификация на основе изменений. Каждая версия ПП именуется так же, как в предыдущем способе, плюс даются ссыл­ки на запросы на изменения, которые реализованы в данной вер­сии ПП. Таким образом, версия ПП идентифицируется именем и теми изменениями, которые реализованы в компонентах.

Нумерация версий. По самой простой схеме нумерации версий к имени компонента или ПП добавляется номер версии. Напри­мер, обозначение MASM TPU 4.3 означает: версия 4.3 ассемблера TPU. Первая версия обычно получает номер 1.0, последующие ее варианты — 1.1, 1.2 и т.д. На каком-то этапе создается новая по­ставка — версия 2.0; нумерация вариантов этой версии начинает­ся заново: 2.1, 2.2 и т.д. Такая линейная схема нумерации основа­на на предположении о последовательности создания версий. По­добный подход к идентификации версий поддерживается многи­ми программными средствами управления версиями.

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

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

Если каждая версия определяется единым набором атрибутов, то нетрудно добавить новые версии, основанные на любой из су­ществующих версий, поскольку они будут идентифицироваться единым набором значений атрибутов. При этом значения многих атрибутов новой версии будут совпадать со значениями атрибутов исходной версии; таким образом можно прослеживать взаимоот­ношения между версиями. Поиск версий осуществляется на осно­ве значений атрибутов. При этом возможны такие запросы, как «самая последняя версия», «версия, созданная между определен­ными датами» и т. п. Например, обозначение версии MASM TPU, разработанной на языке C++ для использования под управлением Windows 95 в апреле 1996 г., будет выглядеть следующим образом: MASM TPU (язык = C++, платформа = Windows 95, дата = апрель 1996).

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

Идентификация на основе изменений. Идентификация, осно­ванная на значениях атрибутов, устраняет проблему поиска вер­сий, свойственную простым способом нумерации, когда для по­иска версии требуется знание ее атрибутов. Но в этом случае для регистрации взаимосвязей между версиями и изменениями необ­ходимо использование отдельной системы управления изменени­ями.

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

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