Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 45
Текст из файла (страница 45)
коревы или пе выполнены вообще, значительные средства затрачены на спецификацию, проектирование и написание кода тех функций системы, которые никогда не будуг предоставлены. В результате нет ничего, что можно представить клиенту. Срок сдачи гчис. 33.3. 11рииенение модели водо«ада к яр«яану с 300% ним мапатабом В основном, именно эти причины привели к тому, что со временем модель водопада стала менее популярной. В результате вновь возникла тенденция переходить непосредственно к кодированию, не имея адекватного представления о требованиях к системе, что и было одной из основных проблем, которую пыталась решить модель водопада! 216 Часть 4. Управление масштабом Спиральная модель В своей работе Барри Бом (Вапу ВоеЬш) (1988, а) рекомендует другую схему процес.
са разработки программного обеспечения. Его "спиральной моделью" программной раз. работки руководствуются те, кто верит, что путь к успеху состоит из инкрементных раз. работок на основе рисков (рис. 22.3). Рис. ЗЗЗ. Свирельная модель разработки При использовании спиральной модели сначала создаются серии основанных на рисках прототипов, а затем проводится структурированный процесс построения конечной системы (аналогичный модели водопада). Конечно, при неправильном использовании спиральной модели могут возникать те же проблемы, что и в модели водопада. Проекты иногда сводятся к методу проб и ошибок; производятся отдельные составные части, которые необходимо наращивать и скреплять с помощью жевательной резинки нли прово. Глава 22. Управление масштабом и модели процесса разработки...
217 аоки, что иногда еще называют процессом создания постоянно переделываемого кода. Преимушество заключается только в способности создавать необслуживаемый и непонимаемый код в два-три раза быстрее, чем нри использовании более ранней технологии. Однако если посмотреть на спиральную модель более внимательно, она может помочь в решении некоторых задач управления требованиями, рассматриваемых в данной книге.
В частности, спиральная модель начинается с планирования требований и проверки правильности концепции, затем следует создание одного или нескольких прототи. пов, призванных на ранних этапах подтвердить наше понимание требований к системе. Положительной особенностью этого процесса является множество возможностей получения реакции пользователей и клиентов, что направлено на более раннее выявление синдрома "да, но...". Оппоненты этого строгого подхода отмечают, что в современных условиях непозволительной роскошью является тратить время на полную проверку концепции, два-три прототипа, а также па строгое следование модели водопада. Рассмотрим, что произойдет, если спиральную модель применить к проекту с 200%- ным масштабом.
Результат представлен на рис. 22.4. Приходится согласиться, что он ненамного лучше, чеч при использовании модели водопада; с другой стороны, можно отметить, что к моменту сдачи, по крайней мере, один или два прототипа работоспособны и получены отзывы заказчика. (Конечно, значительная часть этих отзывов будет касаться отсутствия готового к тиражированию программного обеспечения!) нне компонентов Рттс. 33.4.
Применение сниральноймодели и нропоиу с 300%.нмм мапиишбом Итеративный подход В 1990-е годы многие команды пере~или к использованию нового подхода, который сочетает лучшие качества модели водопада и спиральной ьшделн. Кроме того, оп также содержит некоторые дополнительные коттстр)хини из новой дисциплины инженерии программных процессов. Впервые предложенный Крачтеном (КгнсЫеп, 1999), "итеративный подход" к настоящему времени хорошо описан в ряде книг, в том числе в 218 Часть 4. Управление масштабом работах Крачтена (КгмсЬгеп, 1999) и Ройса (Коусе, 1998). Этот подход доказал свою зф.
фективность для широкого спектра проектов и имеет ряд преимуществ по сравнению с водопадной и спиральной моделями разработки. В традиционных моделях процесса разработки развитие проекта осуществляется пу. тем последовательного выполнения определенных действий, когда разработка требований предшествует проектированию, проектирование — реализации и т.д. Это достаточно разумно.
В итеративном процессе фазы жизненного цикла отделяются от логической деятельности по разработке программного обеспечения, проводимой в каждой фазе, что позволяет повторно возвращаться к деятельности по разработке требований, проектиро. ванию и реализации на различных итерациях проекта. Кролге того, как и в спиральной модели, каждая итерация проектируется так, чтобы уменьшить всевозможные риски иа данной стадии разработки. Фазы жизненного цикла Итеративный подход состоит из четырех фаз жизненного цикла: начало, иссгедоегпггге, яасягроеггие и внедрение, что соответствует естественным состояниям проекта в указанные периоды времени (рис.
22.5). Начало исолгдОВВдд6:*,'.', чгг'угг' бремя Рис. 33.5. Фагм жизненного цикла в итгротмгнкм яодкоде 1. Начало. На данной стадии команда уделяет основное внимание пониманию бизнес- варианта проекта, определению его масштаба, достижимости реализации. Производится анализ проблемы, создается документ-концепция (Уыоп йосмгпеш), предварительно оцениваются график, бюджет, а также факторы риска проекта. 2.
Исследование. Уточняются требования к системе, задается исходная выполняемад архитектура и, как правило, разрабатывается и демонстрируется ранний прототип достнжимости. 3. Посггг)доение. Главное внимание уделяется реализации. На этой стадии пишется большая часть программного кода, завершается проектирование и доработка арки. тектуры. 4.
Внедрение. Производится бета-тестирование; пользователи и команда сопровождения системы получают опыт работы с приложением. Протестированная базовая версия приложения передается сообществу пользователей и разворачивается для использования. Итерации В каждой фазе проект, как правило, проходит множество итераций (рнс. 22.6). Итг)Зацял- зто приводящая к появлению некой выполняемой программы последователь. ность действий, для которой заданы план и критерий оценки.
Калгдая итерация основы- Глава 22. Управление масштабом и модели процесса разработки... 219 вается па функциональных возможностях предыдущей итерации; таким образом, проект разрабатывается "итеративным инкрементным" методом. Начало Исследсепниа '":.,'ч..;3ч 1 1 1 3 1 1 3 1 1 1 1 3 1 1 1 1 1 1 Предпари-,, Аркитек., 1 1 1 тельная 1 1 УурНая 1 1 Итерация, Итерация,, Итерация итерация 1 1итерация1 . 1разрпбсгки1разработки, пнедзенип', А А А А А А 1 Выпуск Выпуск Выпуск Выпуск Выпуск Выпуск Выпуск веРсии веРсии версии еарсии версии веРсии версии Рис.
22.б. Фазы и итерации, ириеодясцие к иолаееиию заивисиособнмк персий Выпуск персии Рабочие процессы В итеративном подходе деятельности, связанные с разработкой программного обеспечения, организованы в рабочие гсроцессм. Каждый рабочий процесс состоит из логически связанного множества деятельностей и определяет, в каком порядке их следует проводить, чтобы создать жизнеспособный раба шй продукт или "артефакт". Хотя количество (и качество) рабочих процессов может варьироваться в зависимости от конкретной компании и проекта, обычно имеется, как минилкум, шесть рабочих процессов (рис. 22.7).
Па каждой итерации команда уделяет каждому рабочему процессу столько времени, сколько считает нужным. Такгкм образом, итерация может рассматриваться как мини. водопад, где представлены действия по разработке требований, анализу и проектированию и т. д., по каждый мини-водопад "настраивается" на специфические потребности данной итерации. Размеры "холмов" на рнс. 22.7 отражают относительные трудозатраты на соответствующие рабочие процессы. Например, в фазе исследования значптсльнос время уделяется уточнению требований и определению архитектуры, которая будет поддерживать функциоцальныс возможности. Деятельности могут осуществляться последовательно (истинный мини-водопад) нли параллельно, в зависимости от нужд конкретного проекта. С точки зрения управления требованиями, итеративный подход имсет два существенных преимущества.
1. Раннее получение "да, ио... ". В рсзультате каждой итерации пол) ~ается выполняемая версия; так что уже на самых ранних этапах проекта клиснты имеют возможность видеть рабочий продукт. Конечно жс, их реакцией будет "да, но...", по на этой ранней стадии были затрачсны только минимальные средства. При каждой последующей итерации размеры этих "но..." буус)т уменьшаться.
и вы и ваш клиент постепенно подойдстс к удовлетворительной системе. Существует ряд критериев отбора итераций. Ранние итерации следует разрабатывать для оценки жизнеспособности выбранной архитектуры, для некоторых самых важных прецедентов и прецедентов с высоким риском. 220 Часть 4. Управление масштабом Рабочие працассы Улрзеление требоввиив лизлиз и цзонти/мэзин Ревлимцн Твпираезнн Рмвергнвнв Вслаыагмелвныа процасе Улрзвление кснфицРзцивс и иавноыни Улрвнвенне лраеккоч и процессе Рыс.
22.7. Рабочие нйокессм нтерапаиоиосо кодиок?а 2. Легкке укфааллкиьмаскпнабом. Если в первой итерации процент невыполнения составил 30% и более, это свидетельствует о том, что лкасквтаб проекта, возможно, закан неправильно и сто нсобхолимо сократить. Однако лаже с неверно заданным масштабом к сроку сдачи букет разработано несколько выполняемых итераций, а послслняя может лаже быть развернута. Даже если некоторых функциональных возможностей нс хватает, версия букет представлять опрелслезкпузо ценность ллл пользователя.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
