Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 76
Текст из файла (страница 76)
Чтобы ослабить возмущающий эффект изменений требований, необходимо выпол. нять их в иерархии нисходящим образом (рис. 34.3). Как мы уже отмечали, изменения базового уровня документа-концепции можно отражать в отдельном документе Вайа ЧР ноп, который, как правило, является совсем небольшим подмножеством исходного документа. Но так как изменение документа-концепции может заключатыя в у)оленки функций, нам может понадобиться создать совершенно новый исходный набор требований к программному обеспечению, а зто может привести к соответствующим изменениям проектирования, кода и планов тестирования. Если следовать предложенному в данной книге процессу и воспользоваться поддержкой автоматических средств, нисходящее распространение возму»пения будет отражено механизмом трассировки, который используется при построении пирамиды требований. Это позволит пам работать с пирамидой сверху вниз, внося дальнейшие изменения там, где необходимо.
Каждое последующее изменение обнаруживает дополнительные "подозрительные связи" нли точки более нижнего уровня пирамиды, где необходимо провести дополнительный анализ. Таким образом, изменение распространяется по иерархии логичным и контролируемым образом. Кроме того, если мы правильно провели инкапсуляцию систем и подсистем и испольэовали хороню структурированную стратегию задания требований, иэл»енения будут ограничены областями, непосредственно связанными с измененными требованиями. ЗБО Часть 6. Построенне правильной снстемы Управление измвнвниям и Фтнпжи Документ-концепция Спвцифиьэ ции Проект Реализация 7всты Докумвпация пользоватвв Рис..44З.
ИеРаРкмчеотий епРелямРРаетРветпфанениа вазмуитения Например, на рнс. З4,4 представлен отчет о трассировке, полученный после внесения некоего ттзлтенення в НОЫЬ. Автоматизированное средство отметило трасснровочные связи двух функций, ЕЕАЗ н РЕАЛ, как подоэрнтельные. Это явилось результатом предложенных изменений указанных двух футтктптй. Необходнлто проверить возможное воздействие результатов ттзлтененнй РЕАЗ н РЕАЗ на БКЗ н БК4. В свою очередь, возможные поправления ЗКЗ н ЗК4 ктотут распространиться вннз к реализации н т.д.
Мы вернемся к рассмотрению этого явления далее в этой главе. Управление конфигурацией требований процесс рассмотренпя н прнпятня нзмененнй в некоторых организациях носит названне "контроль нзмененнй", "контроль версий", нлн управление кояртигуроттией <соттЯиготтотт тткттюделити, СМ). Интересно, что большинство организаций имеет достаточно строгий процесс управленца конфигурацией походного кода, производимого на стадии реализации жизненного цикла проекта, но не имеет соответствующего процесса для требований к проекту.
Даже если в организации имеется формальный процесс создання документа-концепцпц ц трсбованнй к программному обеспечению, он зачастую нг норнрует многне затрагивающие требовання нэменення, которые закрадываются в проект настаднн коднровапня. Рмс. у4.4. Ана пнз еоздейонемя изменений с номеедею связей трассировки При наличии современных инструментальных сред достаточно несложно контролировать все элементы иерархии требований посредством управления конфигурацией (рис. 34.5). Документ.концмтции Команда заказчика Команда разработчика Процедуры тестировании Модель ФиФ нрсекнтрованиа Рис..рр.э. СквнаунРаютсння конфигурацией юРсбоееняй $ я й ть 3 3 Глава 34. Управление изменениями 351 352 Часть б. Построение правильной системы Преимушества основанного на СМ процесса управления требованиями очевидны, но мы все жс кратко перечислим их. ° ! 1рсдотврашшотся недозволенные и потенциально деструктивные изменения треоовапнй.
° Предотвращаются исправления документов требований. ° Упрогпается получение и/или восстановление предыдущих версий документов. ° Осушсствлястся полдержка реаяизационной стратегии, основанной на задании базового уровня и инкрементных улу ппениях и обновлениях системы. ° Предотвращается одновременное обновление документов (т.е, некоординированпое обновление различных документов в одно и то же время). Управление изменениями при поддержке программных средств Итак, мы предлагаем практический подход к управлению изменениями, прслполагая, что у вес исееешся набз!з авяоматичесхих с(зедсзпв нвдде)гхсхи данных дейсжвий Если вы захотите использовать собственные методы, реализуемые вручную, часть данного раздела вам пе пригодится, но общие идеи все равно заслуживают внимания. Здесь будут рассмотрены следующие важные вопросы.
° Если предлагается изменить отдельную функцию продукта, какими будут последствия данного изменспияз другими словами, управление изменениями поможет определить, какое количество переделок потребуется. Это может оказать существенное влияние па планирование ресурсов проекта и распределение нагрузки. ° Если предлагается изменить некий элемент, какие другие элементы системы может затро~йть данное изменение) Это имеет первостепенную важность как для планирования разработки, так и для клиента. ° В ходе разработки неизбежны неверпыс "повороты".
В такой ситуации нужно иметь возможность совершить "откат" требования и исследовать предыдущую его версию. Кроме того, полезно помнить, как и почему было изменено требов.шпс. Другими словами, полезно иметь контрольный журнал для каждого треоовання (это может даже прелписываться ре~улирующиззи органами как часть процесса проектирования). Элементы, на которые воздействует изменение После зад.пшя отношений трассировки трассировочныс связи можно использовать для упраплспия нзмснспнямп. Прслположим, что в системс НО1.1$ необходимо изменить формулировку ЕЕЛб ("Установка режима на время отпуска"), чтобы отразить пересмотренное определение функции продукта (рис. 34.6).
Обратите внимание па диагональные линии па трассировочпых стрелках в строке для ЕЕА5. Этн лпнпп, "подозрптсльпыс связи", предназначены для того, чтобы предупредить о том, что изменение данной функции может повлиять на БК1 и ЬКЗ, и поэтому следует произвести нх ревизию. Глава з4. Управление изменениями ЗБЗ Рис.
34.6. Фрагмеит мажривм жрассироеки весле измюиииа гол По мере развития проекта неизбежно будут предлагаться изменения различных его элементов: от высокоуровневого документа-концепции до спецификации, реализации и тестов. Повсюду при возникновении изменения следует испольэовать "подозритсльныс связи", чтобы отметить отношения, на которые могло повлиять данное изменение. Действия по управлению изменениями обычно заключаются в одном из следующих двух шагов.
1. Если изменение функции нс влияет на требование,необходимо только очистить "подозрительную связь". Заметим, что если позднее данная функция вновь будет меняться, связь снова будет отмечена как подозрительная. 2. Если функция действительно влияст иа требованис, можст понадобиться переделать подвергшийся воздействию элемент. Например, предлагаемое изменение функции может потребовать изменения спецификации требования.
После сто редактирования обнаружится, что дополнительные "подозрительныс связи" теперь предупреждают о возможном воздействии уже этого изменения. Значит, необходимо будст исследовать на предмет нзмспспий эти связи и т.д. Возможность управления изменениями должна существовать на различных уровнях отношсний трассировки. Так, изменение функции документа-концепции может затронуть несколько требований к программному обеспечению в БКЬ и/или некоторые прсцс. дспты, которые могут, в свою очередь, воздействовать на несколько колшонеитов реализации, а тс — на один или несколько планов тестирования.
Необходимо отслеживать трассировочиыс связи в двух направлениях. Например, изменение спецификации плана тестирования может заставить рассматривать возможное влияние на компоненты реализации. В свою очередь, изменение компонента реализации может потребовать повторной проверки затронутых програмлгных требований и даже функций верхнего уровня, которые связаны с этим компонснтом посрсдством трассировочиых отношсний. 354 Часть б. Построение правильной системы Контрольный журнал изменений Полезно вести контрольный журнал изменений, где, в частности, фиксируются изменения отдельных требований. При поддержке вспомогатсльной программы это позволит работап с каждым трсбовапием отдельно, нсзависимо от того, частью какого документа плн модели оно является.
Все нзмепсиня требования автоматичсски фиксируются (образуя исторшо пзмспспий данного требования), и их можно впоследствии проверять ы ысрссматрнвать. В истории изменений указывается текущая формулировка требования, в том числе тску<цис значения всех его атрибутов (т.с. краткое описание данного требования). Кроме того, в истории нзмсысыий в хронологическом порядке представлена последовательность всех предшествую<пнх изменений данного требования и его атрибутов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
