Управление конфигурации программного обеспечения, страница 5

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

Эти упомянутые "признаки" могут быть столь же просты ,как определенное число версии, которые приложены к каждому объекту или столь же сложны как список Boolean переменных (выключатели), которые указывают определенные типы функциональных изменений, которые применялись к системе.

Одно представление различных версий системы - графа развития, представленная в Части 8.3. Каждый узел на графе - совокупный объект, то есть полная версия программного обеспечения. Каждая версия программного обеспечения - собрание SCIs (исходный кодекс, документы, данные), и каждая версия может быть составлена из различных вариантов. Чтобы иллюстрировать эту концепцию, рассмотрите версию простой программы, которая составлена из объектов 1,2, 3, 4, и 5. Сущность 4- использование только, когда программное обеспечение осуществлено, используя цветные показы. Сущность 5 -осуществлено, когда одноцветные показы доступны. Поэтому, два варианта версии могут быть определены: (1) объекты 1, 2, 3, и 4; (2) объекты 1, 2, 3, и 5.

Часть 8.4. Представление объединения Объекта компонентов, вариантов, и версий

Чтобы строить соответствующий вариант данной версии программы, каждому предмету может быть присвоено "признак-tuple" - список особенностей, которые определяют, должно ли он использоваться, когда специфический вариант версии программного обеспечения должен быть построен. Один или более признаков предназначен для каждого варианта. Например, цветной признак мог использоваться, чтобы определить, что должно быть включено, когда цветные показы должны быть поддержаны.

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

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

8.5 КОНТРОЛЬ ИЗМЕНЕНИЯ

Действительность контроля изменения в современном техническом контексте программного обеспечения была хорошо суммирована Джеймсом Бачом:

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

Бач признает, что мы сталкиваемся с актом балансирования. Слишком много изменений контролируем, и мы создаем проблемы. Слишком мало, и мы создаем другие проблемы.