Методология быстрой разработки приложений

Одним из возможных подходов к разработке ПО в рамках спи­ральной модели жизненного цикла является получившая в послед­нее время широкое распространение методология быстрой разра­ботки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержа­щий три элемента:

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

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

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

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

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

1) анализа и планирования требований;

2) проектирования;

3) построения;

4) внедрения.

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

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

86

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

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

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

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

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

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

Все модели и прототипы должны быть получены с применени­ем тех CASE-средств, которые будут использоваться в дальней­шем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения инфор­мации о проекте позволяет избежать этой опасности.

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

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

87

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

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

• проводится анализ использования данных;

• проводится физическое проектирование БД;

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

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

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

всем согласованным требованиям.

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

Следует, однако, отметить, что методология RAD, как и лю­бая другая, не может претендовать на универсальность. Она хоро­ша в первую очередь для относительно небольших проектов, раз­рабатываемых для конкретного заказчика. Если же разрабатывает­ся типовая система, которая не является законченным продук­том, а представляет собой комплекс типовых компонентов, цен­трализованно сопровождаемых, адаптируемых к программно-тех­ническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедре­ния и интегрируемых с существующими разработками, на пер­вый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интер­фейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных рас­четных программ, ОС или программ управления космическими

38

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

Основными принципами методологии RAD являются:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждом из этапов жизненного цикла;

• обязательное вовлечение пользователей в процесс разработ­ки АИС;

• необходимое применение CASE-средств, обеспечивающих це­лостность проекта;

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

• необходимое использование генераторов кода;

• использование прототипирования, позволяющее полнее вы­яснить и удовлетворить потребности конечного пользователя;

• тестирование и развитие проекта, осуществляемые одновре­менно с разработкой;

• ведение разработки немногочисленной хорошо управляемой командой профессионалов;

• грамотное руководство разработкой системы, четкое плани­рование и контроль за выполнением работ.

Указанные принципы помогают существенно ускорить разра­ботку требуемых приложений RAD.

⇐ Предыдущая12131415161718192021Следующая ⇒

Поделиться: