Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
131
4.4. Эволюционная модель
быстрого прототипирования
Полное название модели — эволюционная модель быстрого прототипирования. Эта модель основана на следующей идее:
1) максимально быстро проводится системный анализ;
2) на его основе создается первичный вариант системы
(прототип);
3) он эксплуатируется пользователями, которые в процес-
се эксплуатации формулируют претензии к прототипу;
4) эти претензии устраняются разработчиками;
5) этапы 3 и 4 чередуются до тех пор, пока заказчик не со-
чтет, что последний вариант его устраивает;
6) на базе прототипа пишется конечная ИС. Прокоммен-
тируем изложенное.
Целью быстрого системного анализа не является составление как можно более исчерпывающей спецификации требований и их всесторонний анализ. Учитываются только первичные,
лежащие на поверхности, вытекающие из самой цели создания
ИС требования. Планирование проекта — это первое действие
на этапе быстрого анализа, с помощью которого получают документ, описывающий в общих чертах примерные графики и
результативные данные. Второе действие — это быстрый анализ, во время которого на основе опросов пользователей создается частичная спецификация требований, содержащая только те
базовые свойства, которые необходимы для удовлетворения основных требований заказчика, и создается прототип.
Прототип создается с использованием CASE средств, при
этом не принимается во внимание качество прототипа. При выборе языка программирования предпочтение отдается хорошо
знакомому разработчикам, так как основное требование —
быстрота создания какого-нибудь прототипа.
Затем начинается итерационный цикл быстрого прототипирования. Демонстрируется прототип, а пользователь оценивает его функционирование, определяются проблемы, которые
устраняются и пользователь опять оценивает, и т. д.
Прототип, таким образом. поэтапно усовершенствуется.
От версии к версии требования пользователей конкретизируют-
132
ся, их состав пополняется, они учитываются все более полно.
При этом состав проектной документации минимален. Промежуточные версии продукта создаются до тех пор, пока пользователь не согласится, что быстрый прототип в полной мере его
устраивает.
Отличительной чертой данной модели является то, что
процессы специфицирования, разработки и аттестации ПО выполняются параллельно при постоянном обмене информацией
между ними.
Модель эволюционной разработки представлена на
рис. 4.2. Начало жизненного цикла разработки помещено в центре эллипса. Пользователь и программист разрабатывают предварительный план проекта, на основе предварительных требований. Используя методы ускоренного анализа, пользователь и
программист совместно работают над определением требований
и спецификаций для важнейших частей воображаемой системы.
Рис. 4.2. Эволюционная модель быстрого прототипирования
Получив одобрение пользователя, пишется ИС. Поскольку
требования к ней максимально определены, а способы их реализации апробированы на прототипе, написание окончательного
133
варианта не занимает много времени. И он заменяет частичную
систему, полученную в итерационном цикле прототипирования.
4.4.1. Преимущества эволюционной модели
При использовании эволюционной модели для приемлемого проекта проявляются преимущества:
– взаимодействие заказчика с системой начинается на раннем этапе разработки;
– поскольку заказчик воочию видит, что представляют собой его требования, воплощенные в системе, он может их вовремя скорректировать и дополнить, снижается возможность
недопонимания между ним и разработчиком;
– заказчик видит постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему он чувствуют себя
уверенно и в большей степени будет доволен полученными результатами;
– благодаря меньшему объему доработок уменьшаются затраты на разработку;
– документация сконцентрирована на конечном продукте,
а не на его разработке.
4.4.2. Недостатки эволюционной модели
Эволюционный подход эффективнее, чем подход каскадной модели, особенно если требования заказчика могут меняться
в процессе разработки системы. Но ему присущи следующие
недостатки:
– система часто получается плохо структурированной, постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ИС. Со временем внесение изменений в систему становится все более сложным и затратным;
– с учетом создания рабочего прототипа, качеству всего
ПО или долгосрочной эксплуатационной надежности может
быть уделено недостаточно внимания;
– при использовании модели решение трудных проблем
может отодвигаться на будущее. В результате это приводит к
134
тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип;
– если пользователи не могут участвовать в проекте на
итерационной фазе быстрого прототипирования, это плохо отразится на конечном продукте;
– быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно (а заказчик может предпочесть выбрать прототип, а не ждать появления
хорошо продуманной версии), у него останется только лишь частичная система;
– прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование — устранение
ошибок», что приводит к дорогостоящим незапланированным
итерациям прототипирования;
– разработанные «на скорую руку» прототипы страдают от
неадекватной или недостающей документации;
– есть большой соблазн отказаться от традиционной документации. Но если она отсутствует, модифицировать впоследствии систему будет сложно и дорого.
4.4.3. Область применения эволюционной модели
Эволюционный подход наиболее приемлем для разработки
небольших ИС (до 100 000 строк кода) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком
жизни. На больших долгоживущих системах слишком заметно
проявляются недостатки этого подхода. Для них лучше применять смешанный подход, который вобрал бы в себя лучшие черты каскадной и эволюционной моделей разработки. Эту модель
рекомендуется применять, если:
– требования не известны заранее, или не постоянны, или
могут быть неверно истолкованы или неудачно сформулированы, когда заказчик не соглашается на фиксированный набор
требований;
– существует потребность в разработке пользовательских
интерфейсов;
135
– нужна проверка концепции или требуется продемонстрировать техническую осуществимость, когда технический
риск высок;
– выполняется новая, не имеющая аналогов разработка (в
отличие от продукта на базе уже существующей системы);
– осуществляются временные демонстрации;
– можно успешно использовать в больших системах, в которых некоторые модели подвергаются прототипированию, а
некоторые разрабатываются более традиционным образом;
– требуется уменьшить РИСК создания системы, которая
не имеет никакой ценности для заказчика и вообще, когда проявляется средняя и высокая степень риска;
– разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять или алгоритмы,
или системные интерфейсы усложнены;
– задействованы высокотехнологические системы с интенсивным применением, где можно лишь обобщенно, но не точно
сформулировать требования, лежащие за пределами главной характеристики;
– осуществляется применение в комбинации с каскадной
моделью: на начальном этапе проекта используется прототипирование, а на последнем фазы каскадной модели с целью обеспечения функциональной эффективности системы и качества;
– прототипирование всегда следует использовать вместе с
элементами анализа и проектирования, применяемыми при объектно-ориентированной разработке.
Модель особенно хорошо подходит для разработки интенсивно используемых систем пользовательского интерфейса, таких, как индикаторные панели для контрольных приборов, интерактивные системы, новые в своем роде, а также системы
обеспечения принятия решений, среди которых можно выбрать
подачу команд, управление или медицинскую диагностику.
4.5. Модель быстрой разработки приложений (RAD)
В 1980-х годах XX века в ответ на ограничивающий ха-
рактер формальных методов, как каскадная модель, компания
IBM предложила метод быстрой разработки приложений (Rapid
136
Application Development, RAD). Эта модель основана на «трех
китах»:
1) участии пользователя в процессе разработки;
2) широком применении CASE-средств и реинжениринга;
3) временных блоках.
Благодаря методу RAD пользователь задействован на всех
фазах жизненного цикла разработки проекта не только при
определении требований, но и при проектировании, разработке,
тестировании, а также конечной поставке программного продукта. Активное участие пользователя возможно благодаря использованию современных CASE-cредств, наглядно демонстрирующих продукт на всех стадиях его разработки. Это, например, к
Oracle Designer / 2000, Java Jbuilder 3, Linex, Visual C++, Visual
Basic 6, SAS, и др.
Для RAD характерно короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций прототипов, критический анализ которых обсуждается с заказчиком, при этом формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом, который, как правило, составляет 60 дней и называется
временным блоком.
Факторы, позволяющие создать систему за 60 дней, причем без ущерба качеству, включают в себя использование мощных CASE-cредств (см. Приложение), высокий уровень фактора
повторного использования (реинжениринг).
Участие конечного пользователя в этой модели является
решающим. Это возможно потому, что место программирования
и тестирования в данной модели занимают планирование и конструирование (рис. 4.3).
Пользователям приходится справляться с большим объемом работы в начале жизненного цикла, но в награду они получают систему, построенную за короткий промежуток времени.
На этапе планирования требований сбор требований выполня-
ется при использовании рабочего метода, называемого совмест-
ным планированием требований, который представляет собой
структурный анализ и обсуждение имеющихся коммерческих
задач.
137
Совместное проектирование используется с целью привлечения пользователей. Команда разработчиков использует в
качестве прототипа либо готовые модули из базы готовых программных компонентов, либо прототип, полученный с использованием CASE-средств. А прототип обеспечивает возможность
пользователям составить свое видение ИС. Пользователи составляют пользовательское описание системы.
Рис. 4.3. Модель RAD
Фаза конструирования («до полного завершения») — эта
фаза объединяет в себе детализированное проектирование, построение ИС и ее тестирование, а также поставку программного
продукта заказчику за определенное время. Особенностью этого
этапа, которая нашла отражение в его названии, является то, что
новая ИС строится не путем создания нового кода, а путем конструирования ИС из уже готовых модулей. При этом учитываются, какие модули отобраны, и структура ИС строится в соответствии с их функциональными возможностями. Если некоторые готовые программные компоненты недоступны, то для них
пишется новый код. Для ускорения этого процесса используются
генераторы кода. Сроки исполнения этой фазы в значительной
мере зависит от использования CASE-средств и квалификации
разработчиков, их умения ориентироваться и грамотно использовать CASE-средства.
138
Перевод на новую систему эксплуатации — эта фаза
включает проведение пользователями приемочных испытаний,
установку системы и обучение пользователей.
4.5.1. Преимущества модели RAD
Если модель RAD приемлема для проекта, то проявляются
преимущества:
– время цикла разработки для всего проекта можно сократить благодаря использованию мощных CASEсредств;
– требуется меньше специалистов, поскольку команда разработчиков осведомлена в предметной области;
– можно изначально ознакомиться с продуктом;
– благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков уменьшаются затраты;
– благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;
– привлечение заказчика на постоянной основе сводит до
минимума риск того, что он не будет удовлетворен разработанным продуктом и гарантирует, что система будет соответствовать коммерческим потребностям;
– в состав каждого временного блока входят анализ, проектирование и внедрение (фазы отделены от действий);
– основное внимание переносится с документации на код,
причем при этом справедлив принцип «получаете то, что видите»;
– в модели повторно используются компоненты уже существующих программ.
4.5.2. Недостатки модели RAD
Чтобы применение модели дало положительный эффект, а
именно, быструю и недорогую разработку проекта, нужно
непременное соблюдение следующих факторов:
– пользователи должны иметь возможность принимать
участие в процессе разработки на протяжении всего жизненного
цикла;
139
– разработчики должны быть высококвалифицированными
и уметь пользоваться выбранными CASE –средствами;
– должны иметься компоненты для повторного использования;
– как разработчики, так и заказчики должны быть готовы к
быстрому выполнению действий ввиду жестких временных
ограничений, чему должна способствовать система материальной заинтересованности.
4.5.3. Область применения модели RAD
Кроме вышеперечисленных факторов руководитель проекта, выбирая модель RAD, должен проверить наличие приведенных ниже условий (причин):
– проект должен быть основан на использовании компонентных объектов;
– требования в достаточной мере хорошо известны;
– сроки разработки проекта сокращены (60 дней и менее);
– в проекте можно обеспечить функциональные возможности последовательно;
– пригодные к повторному использованию части можно
получить из автоматических хранилищ программных продуктов;
– проект или предназначен для концептуальной проверки,
или не критичен, или небольшой по размеру;
– затраты и соблюдение графика не являются самым важным вопросом (например, при разработке внутренних инструментальных средств);
– проект не требует достижения высокой производительности;
– невысока степень технических рисков;
– в информационных системах;
– команда, работающая над проектом, знакома с предметной областью и используемыми CASE-средствами и имеет высокую степень мотивации.
140
4.6. Спиральная модель
Модель была предложена Барри Боэмом в 1988 году. Спиральная модель сочетает упорядоченную последовательность
каскадной модели и прототипирование.
Модель представляет процесс работы над проектом как
спираль (рис. 4.4), каждый виток которой содержит четыре сектора, приблизительно соответствующие этапам каскадной модели. Каждый виток спирали начинается сектором анализа, где
акцент делается на анализ рисков, анализ и оценку альтернативных вариантов (проектирование, реинжениринг, покупка, субдоговор), а также оценку необходимости проведения данного витка спирали.
Рис. 4.4. Спиральная модель
Завершается виток разработкой прототипа или очередной
версией продукта.
4.6.1. Преимущества спиральной модели
С помощью спиральной модели:
– пользователи «видят» систему на ранних этапах, поскольку уже на начальных витках спирали ускоренными методами создается прототип;
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]