Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 44
Текст из файла (страница 44)
Бавьжсе становится врагом доста точнова Лучшее — враг хорошего! Если бы мы работали в той сфере деятельности, где физика процесса лучше определена, а отрасль илвеет несколько столетий опыта в поставке надежных товаров, ситуация была бы иной. ~о мы имеем дело с миром программирования; физика не определена, процесс еще не устоялся, а технологии меняются с каждым новым приложением. Первым делом остановимся иа том, как добиться удовлетворительного выполнения задания: в уопаоовлепнов еркия всредсхпюоить достаточно функциональных ошможпоспсей длл удоавп гпоорвпил реольвсой пошрвбпости хлиеппва Позднее мы можем соответствующим образом настроить наш процесс, чтобы увидеть, можем ли мы превысить ожидания клиента, но на данном этапе давайте скоицситрируем внимание только на их достижении! Для этого необходимо научиться управлять базовым уровнем. 212 Часть 4.
Управление масштабом После того как базовый уровень задан, оп представляет собой центр, вокруг которого концентрируется множество разнообразных видов деятельности. Функции базового уровня могут использоваться для того, чтобы реалистически оценить прогресс в развитии проекта. Исходя иэ достигнутого по отношению к базовому уровню, можно манипу. лировать ресурсами. Базовые функции можно разрабатывать более детально, тем самым подготавливая их к разработке кода.
Можно применять трассировку требований от потребностей пользователя к функциям базового уровня. Трассировку можно затем про. должить от функций к дополнительным спецификациям и реализации. Возможно, наиболее важным является то, что высокоуровневый базовый уровень можно использовать для успешного управления изменениями. Изменения являются неотъемлемой частью любой разработки. Управление изменениями настолько важно, что мы посвятили этой теме отдельную главу 34. На данном этапе мы рассмотрим только то, как для этих целей можно испольювать базовый уровень функций. Официальное изменение Базовый уровень функций обеспечивает удобный механизм управления высокоуровневыми изменениями.
Рассмотрим официальное изменение, когда заказчик запрашивает новую возможность системы, которая не является частью базового уровня. Прежде чем включить эту новую функцию в базовый уровень, следует оценить воздействие этого изменения. Если команда проекта изначально тщательно определила базовый уровень, то следует исходить из предположения, что любве изменение в бязевая уровне новлияею на ро сурен, график али набор функций, которые должны быть представлены в данной версии. Если ресурсы фиксированы и график изменить нельзя, команда проекта должна при. влечь заказчика к процессу принятия решения о приоритете новой функции по отноше нию к другим функциям, определенным для реализации в данной версии.
Если новая функция является критической, она, по определению, должна быть включена в реализацию. Заказчик совместно с кол~аидой проекта должен определить, какие функции следует исключить из реэлизации или, по крайней леере, как понизить их приоритеты с соотвег ствующим уменьшением ожиданий. Но если функция является важной, а не критической, команда может исходить из того, что в процессе разработки будет ясно, можно лн данную функцию реализовать в этой версии. Неофициальное изменение Парадоксально, но изменение по инициативе заказчика может оказаться одной из са. л~ых простых проблел» управления ыасштаболк с которыми приходится сталкиваться. Опа ставится извне; мы можем предпринять некие меры предосторожности; воздействие изменения можно оценить и объяснить заказчику. Однако опыт свидетельствует, что существует еще„один тнп изменений, который является более опасным для процесса разработки.
В главе 34 мы будем обсуждать опасность неявных изменений и опишем дополнительные методы решения проблемы управления масштабом. Глава 22 Управление масштабом и модели процесса разработки программного обеспечения Основные положении ° Процесс разработки определяет кжо. что, когда и хах делает. ° В модели водопада деятельность по разработке программного обеспечения осут>сествляется с помощью последовательности шагов, причем каждый шаг основывается на результатах деятельности на предыдущем п>аге.
° Спиральная модель начинается с создания набора основанных на рисках прототипов, после чего выполняется структурированный процесс, аналогичный модели водопада. ° Итсративный подход сочетает в себе свойства модели водопада и спиральн<>й модели, а фазы жизненного цикла в нем отделяются от производимых в прелелах каждой фазы действий по разработке. ° Независимо от используемой модели, необходимо разработать, как минимум, одни ранний прототип, чтобы выяснить реакцию клиента.
До сих пор мы не обсуждали подробно процесс программной разработки в целом; в частности, не рассматривали, как сам процесс разработки влияет на способность коман. ды достичь желаемых результатов. Однако понятно, что эффективное управление требованиями не может существовать беэ хорошо организованного процесса разработки, который полностью определяет множество действий, выполняемых командой при работе над программным прод>эстом. Некоторые процессы разработки программного обеспечения достаточно формальны, другие — неформальны, по процесс существует всегда, даже если он строго не определен и не докумснтпрован. Процесс разработки нрограмлсного обеспечения ояределяем, хто (кокон члек каашндм), чню (хакие дейснин>я), когда (да>сные дейсимия то ожнои>ению к дРутп>м де>ссн>э>сям) и хак (деэ>али и этапы эни>х деисн>эий) делаена для дос>яи>кения цели.
Процессы разработки программного обеспечения оказывая>т заметное воздействие па способность команды разработать программу в срок и в пределах бюджета. В данной главе мы рассмотрим некоторые высокоуровневые аспекты различных процессов разработки программного обеспечения, в том числе временные фазы н основные типы деятельности во время этих фаз, а затем проанализируем, как сказывается на задаче управления масштабом проекта то, какой модели процесса следует команпа. 214 Часть 4.
Управление масштабом "Модель водопада" Бом (ВоеЬш) (1988, а) отмечал, что еще в начале 1950-х, когда в программной отрасли осознали стоимость обнаружения программных дефектов на поздних этапах жизненного цикла, была принята логическал пошаговая модель процесса — от фазы разработки требований к фазе проектирования, кодирования и т.д. Это было значительным усовер. шенствованием по сравнению с существовавшей ранее диухфазной моделью "кодирования и исправления", согласно которой программисты сначала писали код, а затем поправляли его до тех пор, пока уже нечего было поправлять. В 1970-х Уинстон Ройс (Ъйпзгоп Коусе), работавший в компании ТКЪУ, предложил модель разработки программного обеспечения, известную как "модель водопада".
В ней содержались следующие усовершенствования строго пошаговой модели. ° Появились петли обратной связи между стадиями; это отражает тот факт, что проектирование воздействует на разработку требований, а написание кода системы будет вызывать повторные обращения к проектированию и т. д. ° Параллельно с анализом требований и проектированием предлагалось разрабо- тать систему.
прототип. Как показано на рис. 22.1, в модели водопада разработка программного обеспечения осуществляется посредством последовательности шагов. Каждый шаг основывается на действиях предыдущего шага. Проектирование логически следует за разработкой требований, кодирование — эа проектированием и т.д. Модель водопада широко использовж лась в последующие два десятилетия и успешно служила в качестве модели процесса для различных средних и больших проектов. гис. 22 1.
"Модель аадаиада" иракесса (иь4эабажки ираэраммиага абесиаиеиил Глава 22. Управление масштабом н модели процесса разработки... 215 Заметим, что в рис. 22.1 не указывается на необходимость создания прототипа (как, к сожалению, и было принято при применении данной модели). Это прискорбная ошибка, к которой мы еще вернемся.
В модели водопада возросла роль требований. Их разработка стала необходимым первым шагом при создании программного обеспечения, а также являлась основой проектирования и написания програимного кода. Однако это же стало источником трудностей, так как в данной модели полная тщательная разработка требований и документов проектирования была обязательным условием окончания каждой из этих фаз.
Кроме тсн го, возможно, из-за неправильного применения слишком рьяными командами разработчиков, эта модель стала иенце«мерять застивший косный подход к Разработке. когда требкь ванин "заморожены" на время жизни проел«ик изменения запрещены, а процесс разугабо«ти "лсивет" своей собственной жизнью.
В таком случае со временем команда может оказаться совершенно оторванной от реальности, на которой изначально основывался проект. Дополнительные проблемы возникают, когда приходится решать задачу управления масштабом (рис. 22.2). Если же пытаться применять модель водопада к проекту, который изначально имеет масштаб 200%, результаты могут быть катастрофическими. К сроку сдачи ничто не работает, тестирование компонентов и сборка системы искусственно ус.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
