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