Эволюционная модель

Разрабатывается первоначальная версия ПС, которая затем сразу же передается на испытание пользователю, затем она дорабатывается с учетом мнения пользователя. Удобно применять, когда заказчик четко не может сформулировать свои требования или меняет их в процессе создания ПС. Достоинство: спецификация может разрабатываться постепенно, по мере того, как заказчик осознает, что ему нужно. Недостатки: плохая документированность и структурируемость ПС; перепрограммирование кода ПС. Используется при разработке небольших ПС.

Модель пошаговой разработки ПС - занимает промежуточное положение между каскадной и эволюционной моделями. В её рамках разработчик вначале определяет функции ПС в самых общих чертах, устанавливаются приоритеты и определяется количество этапов (очередей или версий). Каждый этап должен быть результирующим.

Достоинства: заказчику не нужно ждать полного завершения разработки; заказчик может использовать компоненты системы, которые получены на первых шагах как прототипы; уменьшение риска общих системных ошибок; наиболее важные подсистемы подвергаются более тщательному тестированию и проверке.

Недостатки: сложности отображения системных требований и компонентов больших размеров и распределения общих системных функций по компонентам.

Спиральная модель -устраняет недостатки каскадных моделей. На каждом витке этапы модели могут уточняться или дополняться новыми работами.

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

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

Спиральная модель с ограничением версий - аналогична пре­ды­­дущей, но число версий ограничивается. Таким образом, если разработчик находит кардинально лучшее решение, приводящие к нарушению совместимости с предыдущими версиями, и/или предполагаемая новая версия практически существенно не улучшает ПС, то принимается решение о прекращении дальнейшей разработки. Таким образом, последний недостаток предыдущий модели устраняется на некоторой версии ПС.

Методология быстрой разработки приложений (RAD - Rapid Appli­ca­tion Development) - один из подходов к разработке ПС в рамках спиральной и эволюционной моделей ЖЦ. Для ее реализации требуются три составляющие:

· небольшая команда программистов (от 2 до 10 чел.);

· короткий (от 2 до 6 мес.), но тщательно проработанный произ­водст­вен­ный гра­фик;

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

Команда разработчиков должна представлять собой группу профес­си­оналов, имеющих опыт в анализе, проектировании, ге­нерации кода и тестировании ПС с использованием CASE–средств, способных хорошо взаимодействовать с конечными пользовате­лями и трансформировать их предложения в рабочие прототипы.

Жизненный цикл ПС по методологии RAD состоит из четырех фаз: анализ и планирование требований, проектирование, построение, внедрение.

Анализ и планирования требований: пользователями определяются функции, которые система должна выполнять, выделяются приоритетные и описываются информационные потреб­ности. Формулируются требования к сис­теме в основном силами поль­зователей под руковод­ст­вом спе­циалистов–разработчиков. Ограни­чивается масштаб проекта, уста­навливаются временные рамки для каждой последую­щей фазы. Определяется сама возможность реали­зации проекта в заданных размерах финансирования, на име­ющихся аппаратных средствах и т.п. Результатом долж­ны быть список расстав­ленных по приоритету функ­ций будущей ИС, предварительные функциональные и информа­ционные модели ИС.

Проектирование - часть пользователей принимает учас­тие в техническом проектировании системы под руководством спе­циалистов–разработчиков. CASE–средства используются для быс­трого получения работающих прототипов приложений. Пользо­ватели, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, ко­то­рые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Если требуется, то для каждого элементарного процесса создает­ся частичный прототип: экран, диалог, отчет, устраняющий неяс­ности или неоднозначности. Устанавливаются требования разграничения доступа к данным. Определяется перечень необходимой докумен­тации. После детального определения состава процессов оценивается ко­личество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающи­еся реализации одной командой разработчиков за приемлемое для RAD–проектов время (60–90 дней). С использованием CASE–средств проект распределяется между различными командами (делится фун­кциональная модель). В результате на данной фазе формируются:

· общая информационная модель системы;

· функциональные модели системы в целом и подсистем, реали­зуемых отдельными командами разработчиков;

· точно определенные с помощью CASE–средств интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

Построение (физическое проектирование) - непосредственно происходит быст­рая раз­работка приложения:

· определяется необходимость распределения данных;

· осуществляется анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

Внедрение - производятся обучение пользователей, орга­низационные изменения и параллельно с внедрением новой сис­темы осуществляется работа с существующей системой (до пол­ного внедрения новой). Так как фаза построения достаточно не­продолжительна, планиро­вание и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования систе­мы.