Модель прототипирования жизненного цикла разработки ПО
Ставшее классикой произведение Фреда Брукса (Fred Brook) под названием "Легендарный человек-месяц" (The Mythical Man-Month) сегодня столь же актуально, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал:
"В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы...
В случае, когда в проекте используется новая системная концепция или новая технология, разработчик вынужден построить систему, которой впоследствии не воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть достижение нужного результата.
Следовательно, вопрос менеджмента заключается не в том, создавать или нет экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и сделаете. Единственный вопрос в том, нужно ли планировать создание продукта одноразового использования заранее или обещать поставить его заказчикам..."
Именно эта концепция построения экспериментальной, или прототипной системы привела к возникновению "структурной", "эволюционной" модели быстрого прототипирования (RAD), и спиральной модели. В своей боле поздней, в равной степени полной плодотворных идей работе под названием "No Silver Bullet, the Essence and Accidents of Programming" Брукс считает, что большинство ошибок, возникающих при разработке ПО, все же связаны с неправильным пониманием концепции системы, а не с синтаксисом или логикой. Разработка ПО всегда будет трудной задачей, и мы никогда не найдем чудодейственную панацею или "серебряную пулю". Он подчеркивает положительный момент в применении методов быстрого прототипирования:
"Самой тяжелой составляющей процесса построения программной системы является принятие однозначного решения о том, что именно необходимо построить. Ни одна из остальных составляющих работы над концепцией не представляет собой такую трудность, как определение детальных технических требований, включая все аспекты соприкосновения продукта с людьми, машинами и другими программными системами. Ни одна другая составляющая работы в такой степени не наносит ущерб полученной в результате системе, если она выполнена неправильно. Именно эту составляющую процесса разработки тяжелее всего исправить на более поздних этапах.
Следовательно, самая важная функция, которую выполняет разработчик клиентских программ, заключается в итеративном извлечении и уточнении требований к продукту. Ведь на самом деле клиент не имеет представления о том, что именно он хочет получить.
На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы разработки ПО, является разработка методов и средств для ускоренного прототипиро-вания систем как составляющей итеративной спецификации требований".
Уотте Хэмфри (Watts Humphrey), который известен как вдохновитель создания модели СММ, разработанной Институтом SEI, поддерживает Брукса в его подходе к важности требований и их разработки:
"В большинстве систем заключен основной принцип, который включает в себя больше, чем незначительное эволюционное изменение. Система может изменить само эксплуатационное окружение. Поскольку пользователи могут рассуждать о том или ином явлении только в рамках известного им окружения, требования к таким системам всегда формулируются в рамках текущего окружения. Следовательно, эти требования непременно будут неполными, неточными и обманчивыми. Главной задачей для системного разработчика является изобретение процесса разработки, с помощью которого можно будет обнаружить, определить и разработать реальные требования. Этого можно достичь только при максимальном включении пользователя в процесс разработки и зачастую с помощью периодического тестирования прототипов или версий, полученных на ранних этапах разработки. Оказывается, что такие процессы всегда занимают больше времени, но неизменно в конце приводят к разработке лучшей системы намного быстрее, чем при использовании какой-либо другой стратегии".
Определения прототипирования
Согласно Джону Коннэллу (Connell) и Линде Шафер (Shafer), эволюционным ускоренным прототипом является "легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного приложения получают физическое представление о ключевых частях системы до ее непосредственной реализации; это — легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы" .
Бернард Боар (Bernard Boar) определил прототип как "метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конечной системы — быстро и в требуемом контексте".
Описание структурной модели эволюционного прототипирования
Прототипирование — это процесс построения рабочей модели системы. Прототип — это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.
Выполнение эволюционных программ происходит в рамках контекста плана, направленного на достижение предельно высокой производительности. Этот метод также предполагает, что разработка инкрементов программы очевидна для пользователя, который принимает участие в течение всего процесса разработки.
Рис. 5. Структурная эволюционная модель быстрого прототипирования
"Быстрая" частичная реализация системы создается перед этапом определения требований или на его протяжении. Конечные пользователи системы используют ускоренный прототип, а затем путем обратной связи сообщают о своем достижении команде, работающей над проектом, для дальнейшего уточнения требований к системе. Процесс уточнения продолжается до тех пор, пока пользователь не получит то, что ему требуется. После завершения процесса определения требований путем разработки ускоренных прототипов, получают детальный проект системы, а ускоренный прототип регулируется при использовании кода или внешних утилит, в результате чего получают конечный рабочий продукт. В идеале можно вывести, при чем без излишних затрат, модель прототипирования высокого качества, не экономя на документации, анализе, проектировании, тестировании и т.д. Следовательно, она получила название "структурной модели быстрого прототипирования", как показано на рис. 5.
Начало жизненного цикла разработки помещено в центре эллипса. Пользователь и программист разрабатывают предварительный план проекта, руководствуясь при этом предварительными требованиями. Используя методы ускоренного анализа, пользователь и программист совместно работают над определением требований и спецификаций для важнейших частей воображаемой системы. Планирование проекта — это первое действие на этапе быстрого анализа, с помощью которого получают документ, описывающий в общих чертах примерные графики и результативные данные.
Таким образом, создается план проекта, а затем выполняется быстрый анализ, после чего проектируется база данных, пользовательский интерфейс и разработка функций. Второе действие — это быстрый анализ, на протяжении которого предварительные опросы пользователей используются для разработки умышленно неполной высокоуровневой модели системы на уровне документации. В результате выполнения этой задачи получают документ, содержащий частичную спецификацию требований, который используется для построения исходного прототипа, создаваемого на последующих трех этапах. Дизайнер конструирует модель (используя для этого инструментальные средства), то есть частичное представление системы, которое включает в себя только те базовые свойства, которые необходимы для удовлетворения требований заказчика. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер. Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования. Команда разработчиков проекта продолжает выполнять этот процесс до тех пор, пока пользователь не согласится, что быстрый прототип в точности отображает системные требования. Создание базы данных представляет собой первую из этих двух фаз. После создания исходной базы данных можно начать разработку меню, после чего следует разработка функций, то есть создается рабочая модель. Затем модель демонстрируют пользователю с целью получения предложений по ее усовершенствованию, которые объединяются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. Затем получают официальное одобрение пользователем функциональных возможностей прототипа. После этого создается документ предварительного проекта системы. Основным компонентом является фаза итерации прототипа, на протяжении которого при использовании сценариев, предоставленных рабочей моделью, пользователь может разыграть роли и потребовать, чтобы последовательное уточнение модели продолжалось до тех пор, пока не будут удовлетворены все функциональных требования. Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования.
Детализированный проект можно также получить на основе прототипов. В этом случае настройка прототипа выполняется при использовании кода или внешних утилит. Дизайнер использует утвержденные требования в качестве основы для проектирования производственного ПО.
При разработке производственной версии программы, может возникнуть необходимость в дополнительной работе. Может понадобиться более высокий уровень функциональных возможностей, различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени. После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.
Заключительная фаза представляет собой функционирование и сопровождение, отображают действия, направленные на перемещение системы в стадию производственного процесса.
Не существует "правильного" способа использования метода прототипирования. Полученный результат может не пригодиться, может быть использован в качестве основания для последующей модернизации или превращен в продукт, используемого процесса и желаемого качества в зависимости от исходных целей. Понятно, что при использовании эволюционного прототипирования снижаются затраты и оптимизируется соблюдение графиков, поскольку каждый из его компонентов находит свое применение.
Преимущества структурной эволюционной модели быстрого прототипирования
При использовании структурной эволюционной модели быстрого прототипирования для приемлемого проекта проявляются следующие преимущества:
конечный пользователь может "увидеть" системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки;
исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчики получают сведения об одном или нескольких аспектах поведения системы, благодаря чему сводится к минимуму количество неточностей в требованиях;
снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приводит к созданию более качественного конечного продукта;
в процесс разработки можно внести новые или неожиданные требования пользователя, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности;
модель представляет собой формальную спецификацию, воплощенную в рабочую модель;
модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла;
при использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно;
возможность возникновения разногласий при общении заказчиков с разработчиками минимизирована;
ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки;
возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей;
благодаря меньшему объему доработок уменьшаются затраты на разработку;
благодаря тому что проблема выявляется до привлечения дополнительных ресурсов сокращаются общие затраты;
обеспечивается управление рисками;
документация сконцентрирована на конечном продукте, а не на его разработке;
принимая участие в процессе разработки на протяжении всего жизненного цикла, пользователи в большей степени будут довольны полученными результатами.
Недостатки структурной эволюционной модели быстрого прототипирования:
модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе;
разработанные "на скорую руку" прототипы, в отличие от эволюционных ускоренных прототипов, страдают от неадекватной или недостающей документации;
если цели прототипирования не согласованы заранее, процесс может превратиться в упражнение по созданию хакерского кода;
с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания.
иногда в результате использования модели получают систему с низкой рабочей характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
при использовании модели решение трудных проблем может отодвигаться на будущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип;
если пользователи не могут участвовать в проекте на итерационной фазе быстрого прототипирования жизненного цикла, на конечном продукте могут отразиться неблагоприятные воздействия, включая проблемы, связанные с его качественной характеристикой;
на итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система;
несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса;
заказчик может предпочесть получить прототип, вместо того, чтобы ждать появления полной, хорошо продуманной версии;
если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;
прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл "кодирование — устранение ошибок" (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипирования;
разработчики и пользователи не всегда понимают, что когда прототип превращается в конечный продукт, все еще существует необходимость в традиционной Документации. Если она отсутствует, модифицировать модель на более поздних этапах может оказаться более дорогостоящим занятием, чем просто не воспользоваться созданным прототипом;
когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу;
на заказчиков могут неблагоприятно повлиять сведения об отличии между прототипом и полностью разработанной системой, готовой к реализации;
на заказчиков может оказать негативное влияние тот факт, что они не располагают информацией о точном количестве итераций, которые будут необходимы;
на разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом. У пользователей может возникнуть стремление пополнять список элементов, предназначенных для прототипирования, до тех пор, пока проект ни достигнет масштаба, значительно превышающего рамки, определенные анализом осуществимости проектного решения;
при выборе инструментальных средств прототипирования (операционные системы, языки и малопродуктивные алгоритмы) разработчики могут остановить свой выбор на менее подходящем решении, только чтобы продемонстрировать свои способности;
структурные методы не используются, чтобы не помешать выполнению анализа. При прототипировании необходимо провести "реальный" анализ требований, осуществить проектирование и обратить внимание на качество с целью создания программы, допускающей сопровождение, точно так же, как и в любой другой модели жизненного цикла (хотя на эти действия может понадобиться меньше времени и ресурсов).
Область применения структурной эволюционной модели быстрого прототипирования
Менеджер проекта может быть уверен в необходимости применения структурной эволюционной модели быстрого прототипирования, если:
требования не известны заранее;
требования не постоянны или могут быть неверно истолкованы или неудачно сформулированы;
следует уточнить требования;
существует потребность в разработке пользовательских интерфейсов;
нужна проверка концепции;
осуществляются временные демонстрации;
построенное по принципу структурной модели, эволюционное быстрое прототипирование можно успешно использовать в больших системах, в которых некоторые модели подвергаются прототипированию, а некоторые— разрабатываются более традиционным образом;
выполняется новая, не имеющая аналогов разработка (в отличие от эксплуатации продукта на уже существующей системе);
требуется уменьшить неточности в определении требований; т.е. уменьшается риск создания системы, которая не имеет никакой ценности для заказчика;
требования подвержены быстрым изменениям, когда заказчик неохотно соглашается на фиксированный набор требований или если о прикладной программе отсутствует четкое представление;
разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять;
алгоритмы или системные интерфейсы усложнены;
требуется продемонстрировать техническую осуществимость, когда технический риск высок;
задействованы высокотехнологические системы с интенсивным применением ПО, где можно лишь обобщенно, но не точно сформулировать требования, лежащие за пределами главной характеристики;
разрабатывается ПО, особенно в случае программ, когда проявляется средняя и высокая степень риска;
осуществляется применение в комбинации с каскадной моделью: на начальном этапе проекта используется прототипирование, а на последнем — фазы каскадной модели с целью обеспечения функциональной эффективности системы и качества;
прототипирование всегда следует использовать вместе с элементами анализа и проектирования, применяемыми при объектно-ориентированной разработке. Быстрое прототипирование особенно хорошо подходит для разработки интенсивно используемых систем пользовательского интерфейса, таких как индикаторные панели для контрольных приборов, интерактивные системы, новые в своем роде продукты, а также системы обеспечения принятия решений, среди которых можно назвать подачу команд, управление или медицинскую диагностику.
|
