Обзор моделей жизненного цикла разработки программного обеспечения

    Графически  модель зачастую изображается (как показано на рис. 4) без указания интегральных задач. Этот вопрос достаточно легко решается, он здесь упоминается только для того, чтобы напомнить читателю о том, что интегральные задачи имеют место при использовании всех моделей жизненного цикла.

    С целью преодоления этих недостатков V-образную модель можно модифицировать, включив в нее итерационные циклы, предназначенные для разрешения изменений в требованиях за рамками фазы анализа.

    Область применения V-образной модели

    Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее. Общераспространенная модификация V-образной модели, направленная на преодоление ее недостатков, включает в себя внесение итерационных циклов для разрешения изменения в требованиях за рамками фазы анализа.

    Использование модели эффективно в том случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями и опытом в работе с данной технологией.

    V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность, таких как прикладные программы для наблюдения за пациентами в клиниках, а также встроенное ПО для устройств управления аварийными подушками безопасности в автомобилях.

Модель  прототипирования жизненного цикла разработки ПО

    Ставшее классикой произведение Фреда Брукса (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.

    Начало  жизненного цикла разработки помещено в центре эллипса. Пользователь и программист разрабатывают предварительный план проекта, руководствуясь при этом предварительными требованиями. Используя методы ускоренного анализа, пользователь и программист совместно работают над определением требований и спецификаций для важнейших частей воображаемой системы. Планирование проекта — это первое действие на этапе быстрого анализа, с помощью которого получают документ, описывающий в общих чертах примерные графики и результативные данные.

    Таким образом, создается план проекта, а затем выполняется быстрый анализ, после чего проектируется база данных, пользовательский интерфейс и разработка функций. Второе действие — это быстрый анализ, на протяжении которого предварительные опросы пользователей используются для разработки умышленно неполной высокоуровневой модели системы на уровне документации. В результате выполнения этой задачи получают документ, содержащий частичную спецификацию требований, который используется для построения исходного прототипа, создаваемого на последующих трех этапах. Дизайнер конструирует модель (используя для этого инструментальные средства), то есть частичное представление системы, которое включает в себя только те базовые свойства, которые необходимы для удовлетворения требований заказчика. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер. Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования. Команда разработчиков проекта продолжает выполнять этот процесс до тех пор, пока пользователь не согласится, что быстрый прототип в точности отображает системные требования. Создание базы данных представляет собой первую из этих двух фаз. После создания исходной базы данных можно начать разработку меню, после чего следует разработка функций, то есть создается рабочая модель. Затем модель демонстрируют пользователю с целью получения предложений по ее усовершенствованию, которые объединяются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. Затем получают официальное одобрение пользователем функциональных возможностей прототипа. После этого создается документ предварительного проекта системы. Основным компонентом является фаза итерации прототипа, на протяжении которого при использовании сценариев, предоставленных рабочей моделью, пользователь может разыграть роли и потребовать, чтобы последовательное уточнение модели продолжалось до тех пор, пока не будут удовлетворены все функциональных требования. Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования.

    Детализированный  проект можно также получить на основе прототипов. В этом случае настройка  прототипа выполняется при использовании  кода или внешних утилит. Дизайнер использует утвержденные требования в качестве основы для проектирования производственного ПО.

    При разработке производственной версии программы, может возникнуть необходимость в дополнительной работе. Может понадобиться более высокий уровень функциональных возможностей, различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени. После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.

    Заключительная  фаза представляет собой функционирование и сопровождение, отображают действия, направленные на перемещение системы в стадию производственного процесса.

    Не  существует "правильного" способа  использования метода прототипирования. Полученный результат может не пригодиться, может быть использован в качестве основания для последующей модернизации или превращен в продукт, используемого процесса и желаемого качества в зависимости от исходных целей. Понятно, что при использовании эволюционного прототипирования снижаются затраты и оптимизируется соблюдение графиков, поскольку каждый из его компонентов находит свое применение.

    Преимущества  структурной эволюционной модели быстрого прототипирования

    При использовании структурной эволюционной модели быстрого прототипирования для приемлемого проекта проявляются следующие преимущества:

• конечный пользователь может "увидеть" системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки;
• исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчики получают сведения об одном или нескольких аспектах поведения системы, благодаря чему сводится к минимуму количество неточностей в требованиях;
• снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приводит к созданию более качественного конечного продукта;
• в процесс разработки можно внести новые или неожиданные требования пользователя, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности;
• модель представляет собой формальную спецификацию, воплощенную в рабочую модель;
• модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла;
• при использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно;
• возможность возникновения разногласий при общении заказчиков с разработчиками минимизирована;
• ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки;
• возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей;
• благодаря меньшему объему доработок уменьшаются затраты на разработку;
• благодаря тому что проблема выявляется до привлечения дополнительных ресурсов сокращаются общие затраты;
• обеспечивается управление рисками;
• документация сконцентрирована на конечном продукте, а не на его разработке;
• принимая участие в процессе разработки на протяжении всего жизненного цикла, пользователи в большей степени будут довольны полученными результатами.