Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 75
Текст из файла (страница 75)
С точки зрения как пользователей, так и разработчиков жизнь будет гораздо проще, если удастся создать набор стабильных корректных требований. Даже при достаточно хорошо организованном процессе управления изменениями существуют ограничения па количество изменений, которые разработчик сможет учесть, особенно на стадиях проектирования и реализации. Как правило, коэффициент изменения требований во время разработки составляет 1 — 4% в месяц. Но если его величина превышает 2% в месяц, проект подвергается высокому риску "перемешивания" требований.
346 Часть 6. Построение правильной системы Шаг 3. Задание единого канала контроля изменений Изменения могут быть коварными. Хотя очевидно, что появление новой функции может оказать существенное влияние на требования к программному обеспечению, системную архитектуру, планы тестов и т.д., вес мы оказывались в ситуации, когда "простое изменение" кода вызывало пспрсдвидснныс последствия, иногда далзе катастрофические.
Кроме того, предлагаемая новая ф>нкция может >странять важную будущую функцию системы нли затруднять сс реализацию (т.с. воздействие распространяется не толь. ко иа тскузцую версию). Есть также трудности, свяэанныс с графиком и бюджетом проекта, за которые отвечает руководство. Пожелания заказчиков о внесении изменений не предполагают официального изменения графика и бюджета, и следует инициировать процесс переговоров до того, как изменение будет принято. Пожелании заказчиков о внесении изменений не предполагают офици.
ального изменения графика и бюджета. Таким образом, очень важно, чтобы все изменения поступали по одному каналу, чтобы определить нх воздействие на систему и принять официальное рс~вение, стоит ли вносить это изменение в систему вообще. В небольшом проекте этим официальным каналом может быть лидер проекта, менеджер или кто-нибудь другой, ато "владеет" документомконцспцнсй и др>тими артсфактами трсгюваний, а также имеет полное представление о требованиях к системс и сс проекте. В более крупных системах или в системах, где затрагиваются интересы множества заинтересованных лиц, такой официальный канал может состоять из нескольких человек (образуюгних Совет по контролю за изменениями — С(гапке Сопгго! Воагз(, ССВ), козз» рые совместно несут ответственность за принимаемые ревзения и обладают знаниями и полномочиями, необходимыми для официального принятия запроса об изменении.
(Мы кратко описали ССВ в главе 18.) В любом случае изменение системы нельзя инициировать до тех пор, пока лзеханиэм контроля за изменениями нс признает его "официальным". Шаг 4. Использование системы контроля изменений для их фиксации Проще всего дело обстоит с внешними изменениями, которые производятся по запросу клиента. Их легко выявлять, и они будут естественным образом включены в проект руководством илн органола осуществляющим контроль за изменениями.
Но во время разработки возникает огромное множество иных изменений системы. Многие предлагаемые изменения, воз никиощис во время проектирования, кодирования и тестирования системы, мог>т казаться нс связанньпш с требованиями (например, исправление ошибок кода или просатирования).
Тем нс менее необходимо оценить их воздействие. А если подходит срок сдачи, следует даже принять сознательное решение о том, какие ошибки осташггь в системс (иэ-эа того, что их исправление люжет дестабилизировать систему в целом и тем самым поставить под угрозу дату сдачи), а какие — устршппь. 11омимо этого, многие ошибки могут влиять на требования, вызывать необходимость их согласования или устранения неоднозначности отдельного известного требования. Глава 34. Управление изменениями 347 Нам придется принять сознательное решение о том, какие недостатки оставить в системе. Иногда даже непонятно, какой тип изменений запрашивается. Это особенно часто происходит, когда конечные пользователи жалуются на проблемы после окончания раз.
работки или когда члены службы оперативной поддержки передают результаты анализа жалоб пользователя техническим разработчикам. Например, конечный пользователь обращается к службе поддержки с жалобой: "Я пытаюсь ввести данные о новом служащем в мою систему начисления зарплаты, по так как число букв в его фамилии больше 16, программа аварийно завершается". То, что программа прекращает работать, предположительно, является недостатком на уровне кода или проекта. (Возможно, неправильно производится вызов операционной системы нли СУБД.) Но даже если программа выдает для таких фамилий нормальное сообщение об ошибке.
может существовать ошибка в требованиях; возможно, их необходимо изменить, чтобы фамилии могли содержать до 256 символов. Иногда это может даже затронуть "функцию", так как отдел маркетинга может посчитать большим плюсом то, что их система начисления зарплаты, единствен. ная из предлагаемых, способна работать с фамилиями, содержащими до 256 символов. Команде следует разработать некую систему для фиксации всех запро- сов на изменения. В любом случае необходимо проанализировать ситуацию, а также принять решение о том, еде изменение будет реализовано в иерархии документов.
Следовательно, команде необходимо разработать формальный метод фиксации всех запрашиваемых изменений системы (рис. 34.1). Это может осуществляться с помощью системы отслеживания изменений и неполадок, которая обеспечивает создание централизованного архива запросов, меЬ.ввод элементов иэ любого физического местоположения, автоматическое отслеживание состояния, автоматичес«ую отметку затрагиваемых частей, а также механизм передачи запросов изменений в систему управления требованиями, если это необходимо, (Мы использовали в рис.
34.1 метафору "огнеупорная стена", чтобы подчеркнуть, что процесс контролируется с целью предотвратить неконтролируемое распространение "пожара" изменений по системе.) Эту систему следует использовать, чтобы фиксировать все предложения и передавать их руководству Совета по контролю эа изменениями (ССВ) для принятия решения. Совет играет ключевую роль в успехе проекта. Он должен состоять из трех-пяти человек, представляющих интересы основных участников проекта: заказчиков, представителей маркетинга и руководства проекта. Когда решается вопрос, принять ли запрос об изменении, ССВ должен учитывать следующие факторы. ° Влияние изменения на стоимость и функциональные возможности системы.
° Воздействие изменения па заказчиков и внешних участников, не представленных в ССВ (других подрядчиков проекта, поставщиков компонентов и т.д.). ° Возможность того, что изменение дестабилизирует систему. 848 Часть б. Построение правильной системы Предпожеиия Концепция Заказчик и конечный Требования и прецеденты Проект Разработчики Код Тестово ш Тесты Рис. 34.1. Фиксации изменений При принятии решения ССВ также несет ответственность за то, чтобы отметить все, па что повлияет изменение, даже если оно не принимается. После принятия изменения необходимо решить, куда его вставить.
(Например, нужно определить, предлагается ли излзенить требование или тест.) Последующие измененияя будут распространяться по иерархии так, как показано на рис. 84.2. Предложения Заказчик и конечный Разработчики Твстопоти Дру ие еЪе. 34.2. Движение запроса аб изменении Шаг 5. Иерархическое управление изменениями То, что все вокруг заинтересованы во внесении изменений, не так уж плохо. Можно даже предположить, что все этн излтенения, за исключением сюрпризов, полезны.
Проблемой является то, что изменения могут не документироваться и не анализироваться. Глава 34. Управление изменениями 343 Если их тщательным образом ие обрабатывать, зто может привести к неприятным последствиям. Изменение одного требования может оказать возмущающее воздействие на связанные с ним требования, проектирование или другие подсистемы. К сожалению, это пе учитывают представители маркетинга, которые часто просят программиста "быстро и просто" изменить систему. Проблема осложняется тем. что при отсутствии явно заданного процесса изл»специя обычно производятся "восходящим" образом.
Это означает, что если изменение появляется во время написания кода новой системы, оно, как правило, вносится иепосредсг вепно в программный код. Если разработчики предельно дисциплинированы, они могуо» затем задумано: "Не вызовут ли изменения, которые мы вносим в код, изменений в проекте» А повлияют ли изменения на уровне проектирования на требования» Окажут ли изменения требований к программе воздействие на документ-концепцию»" (Тем ие менее никто не всполгиит о том, что надо хоть что-нибудь сказать об этом изменении группе тестирования, члены которой полыают, что им нужно создавать планы тестирования, ориентируясь на исходные программные требования!) Программист не имеет права от имени пользователя вводи~ь новые функции и требования непосредственно в код.
Теоретически можно справиться с этим явлением "обратного" возмущения, если все соответствующие документы контролируются сложными автоматическими средствами. Но даже если все документы синхрониэируются, обсуждаемые восходящие изменения требований нежелательны. »Уу»оеРаммисгл не имееж»»Раза от имени паюьзоеажеля еяосоть новые функции и требоеаяил неносредстееяно е ход, незоеисимо ож его благих хаме)зелий. Аналогично представитель маркетинга, который обращается к программисту с просьбой осуществить такое изменение, когда они потягивают вдвоем пиво в ближайшем пабе, не имеет оу»икиалькых полномочий. Каждая новая функция/требование оказывает влияние на стоимость, график, надежность и риск, связанные с проектом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
