Глава 1. Управление конфигурацией в жизненном цикле программных средств

Техническое задание на курсовой проект

1. Процессы управления конфигурацией программных средств.

Составление отчетов о состоянии конфигурации.

Курсовой проект оформляется в виде пояснительной записки, содержание которой должно включать:

· введение, где раскрываются: актуальность, цель и задачи проекта;

· содержание основной части пояснительной записки курсового проекта, которое включает решения и ответы на вопросы соответствующего задания, выданного студенту научным руководителем курсового проекта.

Объем пояснительной записки курсового проекта должен быть 20-30 страниц печатного текста.

ОФОРМЛЕНИЕ КУРСОВОГО ПРОЕКТА

Пояснительная записка к курсовому проекту должна содержать:

1. титульный лист;

2. техническое задание на курсовой проект;

3. реферат;

4. содержание (оглавление);

5. введение (актуальность, цель, задачи);

6. основная часть;

7. заключение (выводы);

8. перечень принятых сокращений и терминов (при наличии);

9. список использованных источников;

10. приложения.

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

В приложения выносятся:

1) диаграммы - графическая часть проекта;

2) другие материалы, размещение которых в основной части затрудня­ет чтение пояснительной записки.

Оглавление

Техническое задание на курсовой проект.. 2

Введение. 4

Глава 1. Управление конфигурацией в жизненном цикле программных средств. 5

1. Процессы управления конфигурацией программных средств. 5

2. Составление отчетов о состоянии конфигурации. 22

Список использованных источников. 27

Приложение 1. 28

Введение

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

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

Глава 1. Управление конфигурацией в жизненном цикле программных средств

1. Процессы управления конфигурацией программных средств

Цель управления конфигурацией при разработке и сопровождении сложных программных средств и систем, состоящих из многих компонентов (единиц конфигурации), каждый из которых может иметь разновидности или версии, - обеспечить управ­ляемое и контролируемое развитие их структуры, состава компонен­тов и функций, а также сокращение дефектов в течение всего жизненного цикла программного средства. В процессе организации конфигурационного управления необходимо построить и использовать компактные и наглядные схемы однозначной иерархической идентификации и изменения взаимодействия компонентов программных средств:

· объектов - модулей и компонентов программных средств, разного уровня интеграции, подвергающихся корректировкам (систему идентификации и адресации изменений в комплексе программ и в документах);

· корректировок содержания и взаимодействия проводимых изменений, которая должна обеспечивать возможность однозначного контроля, истории развития модификаций компонентов любого уровня, во времени и в пространстве элементов версий комплекса программ (типы, содержание и взаимосвязь корректировок);

· специалистов, участвующих в конфигурационном управлении и сокращении дефектов, их права на доступ к определенным компонентам программных средств и документам на конкретных стадиях сопровождения, реализации и утверждения изменений.

Процесс управления конфигурацией, (стандарт ISO 12207п.6.2), является процессом применения административных и технических процедур на всем протяжении жизненного цикла программных средств для: обозначения, определения и установления состояния базовой версии программных продуктов в системе; управления изменениями и выпуском объектов; описания и сообщения о состояниях объектов и заявок на внесение изменений в них; обеспечения полноты, совместимости и правильности объектов; управления хранением, обращением и поставкой объектов. Этот процесс включает в себя: подготовку процесса; определение конфигурации; контроль конфигурации; учет состояний конфигурации; оценку конфигурации; управление выпуском и поставку программного продукта. Все основные и вспомогательные процессы подлежат адаптации и конкретизации применительно к характеристикам определенного проекта

Стандарт ISO 15846обобщает, детализирует и развивает основные концептуальные положения, представленные в стандарте ISO 12207. Шесть разделов (6-ой – 11-ый) начинаются с цитирования соответствующих шести базовых требований раздела 6.2 стандарта ISO 12207. В каждом из них излагаются подробные рекомендации по реализации его базовых требований по управлению конфигурацией программных средств. Существенным достоинством стандарта ISO 15846 является подробное и систематичное изложение практических рекомендаций по управлению конфигурацией сложных комплексов программ, которые целесообразно использовать в крупных современных реальных проектах систем.

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

· ожидаемую длительность поддержки развития и модификации конкретного проек­та программных средств;

· масштаб и уровень предполагаемых изменений и модификаций;

· возможное число и периодичность выпуска базовых версий программного продукта;

· организационные основы процессов сопровождения и конфигурационного управления программным средством;

· требования к документированию изменений и базовых версий ПС;

· кто будет осуществлять управление конфигурацией - покупатель, разработчик или специальный персонал поддержки ЖЦ ПС.

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

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

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

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

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

· обеспечить возможность оценки соответствия требованиям заказчика результатов жизненного цикла программного средства;

· обеспечить определяемую и управляемую конфигурацию ПС на протяжении всего жизненного цикла;

· обеспечить управление входными и выходными данными процесса в течение всего жизненного цикла, что гарантирует непротиворечивость и повторяемость работ в процессах;

· обеспечить контрольные точки для проверки, оценки состояния и контроля изменений посредством управления элементами конфигурации и определения базовой версии программного продукта;

· обеспечить контроль над тем, чтобы фиксировались дефекты и ошибки, а изменения регистрировались, утверждались и реализовались;

· гарантировать надежное физическое архивирование, восстановление и сопровождение единиц конфигурации и документов программного продукта.

Изменения конфигурации ПС и его компонентов должны планироваться и предусматривать в плане управления проектом действия с четкими разделами:

· почемуи с какой целью производится корректировка программ или данных;

· ктовыполняет, и кто санкционирует проведение изменений комплекса программ или компонентов;

· какие действия и процедуры должны быть выполнены для реализации изменений единиц конфигурации;

· когда по срокам и в координации, с какими другими процедурами следует реализовать определенную модификацию компонентов и конфигурацию ПС;

· каки с использованием, каких средств и ресурсов должны быть выполнены запланированные изменения ПС и компонентов.

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

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

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

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

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

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

· установить базис для управления и ссылок на единицы конфигурации;

· выполнить идентификацию для каждой единицы конфигурации, для каждой отдельно управляемого компонента конфигурации и для комбинаций единиц конфигурации, которые составляют ПС;

· провести идентификация единиц конфигурации до начала реализации контроля изменений и прослеживаемости документов;

· обеспечить идентификацию конфигурации для документов жизненного цикла ПС;

· выполнить идентификацию единицы конфигурации прежде, чем она будет использоваться другими процессами жизненного цикла ПС, для производства и для загрузки;

· исполняемый объектный код содержал идентификацию конфигурации, которая должна быть доступна для других компонентов системы.

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

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

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

· иерархическими отношениями или отношениями подчинениямежду объектами конфигурации в рамках структуры ПС;

· иерархическими отношениями или отношениями подчинения меж­ду компонентами в каждом объекте конфигурации;

· отношениями между объектами и документами;

· отношениями между документами и изменениями.

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

· воспроизводимости– возможности вернуться назад во времени и повторить определенный выпуск ранее существовавшего компонента, программной системы или среды разработки;

· контролируемости–объединения требований к системе, проектных планов, результатов тестирования и объектов разработки, для учета версий не только системных компонентов, но и объектов проектирования и планирования;

· отчетов, которыепозволяют получать сведения о любой версии системы, сравнивать различные версии, находить ошибки и составлять документацию.

Управление запросами на изменения включает регистрацию, отслеживание и анализ запросов на модификацию ПС, компонентов и данных от субъектов, взаимодействующих с системой. Оно включает процессы принятия решений для планирования необходимых изменений и процессы их реализации. Управление запросами на изменения представляет собой центральную часть Концепции управления конфигурацией. Незарегистрированные запросы на изменения могут быть потеряны или останутся без реакции.

Запрос на доработкуопределяет новое свойство ПС или изменение реализации его функций. Дефектом может быть любая обнаруживаемая проблема, которую следует взять под контроль и разрешить. Хотя с запросами на доработку и дефектами связана достаточно похожая информация, в процессах УК они часто обрабатываются совершенно по-разному. Реализация изменений требует принятия ряда решений. Обычно в определении этого процесса участвуют различные подразделения (руководители проектов, разработчики, специалисты по тестированию). Внешний запрос способен в свою очередь породить несколько внутренних технических запросов на доработку.

Следующий шаг после установления типов контролируемых запросов,
состоит в уточнении объема информации, фиксируемой в ходе жизненного цикла запроса. Наиболее важным и часто наиболее сложным шагом является определение процесса, который используется для контроля каждого запроса на изменение. Типы запросов на изменения, модели переходов и состояний, варьируются достаточно широко и обычно включают:

· представление и регистрация запроса на изменение;

· оценка запроса его категории и приоритета;

· решение о порядке выполнения запроса;

· реализация корректировок - компоненты системы и программная документация создаются или модифицируются с целью реализации запроса;

· проверка на соответствие требованиям или на отсутствие исправленного дефекта.

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

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

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

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

Систему корректирующих действий следует реализовать для обработки каждого дефекта, обнаруженного в ПС или модификации, находящихся под контролем конфигурации на уровне проекта:

· входная информация системы должна состоять из сообщений о дефектах и модификациях;

· необходимо гарантировать, что все обнаруженные дефекты немедленно регистрируются и вводятся в систему УК, необходимые действия инициируются, принятые решения осуществляются, состояние корректирующих действий прослеживается, и сообщения о дефектах и модификациях сопровождаются в течение всего срока действия контракта;

· каждый дефект и модификация должны быть классифицированы по категориям и приоритетам;

· должен выполняться анализ для выявления возможных тенденций в зарегистрированных дефектах;

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

Решение о корректировке конфигурации ПС состоит в выборе: выполнить запрос на изменения, отложить реализацию или отклонить запрос. Для запроса на доработку решение обычно выносит руководитель проекта или аналитик. Затем относительно каждого из них принимается решение о реализации в данной версии продукта, отсрочке или отклонении. Процесс принятия решения для дефектов отличается и зависит от двух факторов: текущей фазы цикла разработки и необходимых для реализации усилий. Обычно дефект закрепляется за определенным специалистом; если ошибку удается легко воспроизвести, в новой версии продукта она будет исправлена. Ненужные модификации могут нарушать работоспособность и снижать качество системы, способствуя отставанию от графика и увеличению издержек. На заключительных стадиях проекта целесообразно вводить формальный процесс рассмотрения и внесения исправлений, он должен быть направлен на ограничение изменений и допуск только самых критических исправлений на стадиях стабилизации кода и квалификационного тестирования.

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

Редакциям ЕК присваиваются определенные статусы, определяющие их качество и пригодность для различных операций. В каждом проекте один из статусов является рекомендуемым, базовым. Последняя редакция ЕК в интеграционном потоке проекта, получившая такой статус, по умолчанию предлагается разработчикам при выполнении операций – обновить. Интегратор может стразу присвоить рекомендуемый статус всем последним редакциям ЕК в интеграционном потоке проекта. Интегратор также вправе присвоить нужный статус нескольким отобранным редакциям. Статус редакций, в которых обнаружены проблемы, допустимо понизить. Если редакция ЕК вызывает ошибки при сборке, ей необходимо присвоить статус – отклонена, что позволит избежать использования данной редакции в дальнейшей работе.

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

· положения, касающиеся организации, состава и срока полномочий совета по конфигурации и его связей с аналогичными со­ветами;

· рассмотрение реализации изменений, начиная с заявки и кончая утверждением модификации после внесения в объект конфигурации, обоснование и оценивание последствий внесения и корректности изменения;

· утверждение или не утверждение изменения;

· обработка и анализ отклонений от требований и подготовка разрешений на отклонения при реализации модификаций;

· сбор, регистрация, обработка и сохранение дан­ных, необходимых для составления отчетов о мониторинге, состоянии и статусе конфигу­рации ПС.

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

Цель контроля изменений - обеспечить регистрацию, оценку, рассмотрение и утверждение корректировок на протяжении всего жизненного цикла ПС:

· контроль изменений должен обеспечить целостность единиц конфигурации и базовых версий программного продукта и защиту их от некорректных модификаций;

· контроль изменений должен гарантировать, что каждое изменение единицы конфигурации учтено в изменении идентификации конфигурации ПС;

· изменения в базовых версиях и единицах конфигурации, находящихся под контролем, должны регистрироваться, утверждаться и прослеживаться, ранняя реализация контроля изменений помогает управлению и организации работ в процессах жизненного цикла ПС;

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

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

Работы по просмотру и прослеживанию корректности изменений должны сопровождать реализацию и контроль изменений ЕК. Целью является оценка дефектов и модификаций, их утверждения, реализации утвержденных изменений и обратной связи к процессам, на которые изменение воздействует, путем использования методов контроля изменений. Последние определяются в процессах планирования проекта ПС и системы и должны включать:

· подтверждение того, что затронутые изменениями единицы конфигурации идентифицированы;

· оценку воздействия изменений на требования безопасности и обеспечение обратной связи к процессу оценки безопасности системы;

· анализ дефектов или изменений и решений о действиях, которые следует предпринять для их коррекции;

· обеспечение обратной связи от сообщений о дефектах, контроля изменений и корректирующих действий к задействованным модификациями процессам.

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

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

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

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