Методологические основы

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

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

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

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

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