Модели жизненного цикла программных средств. Требования к ПО, страница 7

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

1.  V 1.0- ветвь соответствующая релизу. Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.

2.  FIX_V 1.0.1- ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Такие ветви ответвляются от исходной версии и замораживаются сразу после выхода с пакета исправлений.

3.  Upcoming (V 1.1) - ветвь соответствующая релизу, готовящемуся к выпуску и находящимся в стадии стабилизации. Для таких ветвей действуют более строгие правила и работа в них ведется более формально

4.  Mainline- ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся к релизу.

5.  WCF Experiment- ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви делаются доступными только для определенного круга разработчиков и убиваются после завершения работ или после интеграции с основной ветви.

Задача

20% txt P=H*j H-глубина j–твердость пород Исходные данные 2 тхт 4ехе Визуализация 2 давление и объемная

Управление сборками

Рассмотрим почему-же процедура компиляции и создания exe и dll файлов по исходникам проекта является наиболее важной, потому- что она многократно в день выполняется каждым разработчиком на собственном пк с его собственной версией проекта, при этом отличается:

1.  Набор подпроектов собираемых разработчиком т.к. он может собирать не весь проект, а некоторую его часть

2.  Отличаются параметры компиляции, при этом если не собирать регулярно итоговую версию проекта, то общая интеграция может выявить много разных проблем:

1.  Несоответствие друг другу различных частей проекта

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

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

Тестировщики должны тестировать по возможности итоговую и целостную версию продукта так что результаты регулярной сборки должны быть востребованы, кроме того наличие базовой, актуальной, целостной версии продукта позволяет организовать разработку итеративно-инкрементальном стиле, т.е. на основе внесения изменений. Такой стиль разработки называется baselane- метод

UML

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

Нахождение ошибок                                                                             исправление ошибок

Управление ходом проекта

Чтобы справится с этим потоком информации и обеспечить в работе необходимые удобные сервисы существует специальный класс программных средств «средства контроля ошибок». Как правило описание ошибки в системе контроля имеет следующие основные атрибуты: