Модель быстрой разработки приложений. Быстрая разработка программного обеспечения. Case — комплект инструментов и методов для проектирования ПО для обеспечения высокого качества программ, отсутствия ошибок и простоты в обслуживании программных продуктов

Выбор методик разработки приложений становится задачей № 1 в условиях стремительного роста рынка. Согласно исследованию на программное обеспечение для предприятий в 2015 году по миру было затрачено 310 млрд. долларов США. Разработка концепции RAD (Rapid Application Development) стало основой для создания гибкой, адаптивной системы разработки приложений, которая была бы противовесом жёсткой «водопадной» модели.

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

Появление RAD

За появление быстрой разработки приложения стоит благодарить неидеальность модели семейства Waterfall при создании ПО. Всё дело в том, что изначально водопадная система разработки была основана на традиционной инженерной модели, используемой для проектирования и возведения зданий и мостов.

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

Первую версию RAD создал Барри Боэм в 1986 году, который назвал её «спиральная модель». Каждый виток спирали разбит на 4 сектора и соответствует разработке фрагмента или версии ПО. С каждым новым витком идёт углубление и уточнение целей, спецификаций проекта. В результате появляется возможность выбрать обоснованный вариант.

Использовав идеи Барри, британец Джеймс Мартин разработал свою систему RAD на протяжении работы в 80-ых в IBM, и окончательно сформулировал их в «Быстрая разработка приложений» в 1991 г.

Правда не обошлось без путаницы в значении слова «RAD» даже среди IT-специалистов. Ведь речь шла о двух концепциях: RAD как эффективной альтернативе Waterfall и RAD как специфическому методу, разработанному Мартином. Последний был адаптирован к бизнес-системам с интенсивным использованием UI.

В дальнейшем идеи были развиты и улучшены пионерами RAD Джеймсом Керром и Ричардом Хантером в совместной «Внутри RAD», которая описывала путешествие проектного менеджера в процессе изучения и внедрения методологии быстрой разработки приложений в реальной жизни для реального проекта.

Спиральная модель — процесс разработки ПО, комбинирующий проектирование и постадийное прототипирование.

Основы (принципы) быстрой разработки приложений

Принципы RAD сосредоточены на том, чтобы обеспечить основные преимущества методики быстрой разработки приложений:

• повышенная скорость разработки
• низкая стоимость
• высокое качество.

С последним пунктом возникает больше всего проблем, потому что разработчик и заказчик видят предмет разработки по-разному.

Для устранения этой и других проблем Джеймсом Мартином и его последователями были выделены следующие принципы RAD:

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

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

Жизненный цикл программного обеспечения по RAD

В процессе RAD приложение проходит четыре фазы.

Фаза анализа и планирования требований

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

Фаза проектирования

Часть пользователей участвует в техническом проектировании системы под руководством разработчиков. Группы или подгруппы RAD на этой фазе обычно используют комбинацию техник с овместной разработки приложений (JAD) и CASE-инструменты для воплощения потребностей пользователей в рабочих моделях.

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

Case — комплект инструментов и методов для проектирования ПО для обеспечения высокого качества программ, отсутствия ошибок и простоты в обслуживании программных продуктов.

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

В результате фазы создаются:

• общая информационная модель приложения
• функциональные модели системы и подсистем
• рабочие прототипы экранов, отчётов и диалогов.

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

Так, в приложении «Beverly Flowers» пользователи должны иметь доступ к возможностям: «Домашняя страница», «Поиск цветов», «Посмотреть список цветов».

В качестве платформы разработки выбрали freeware SpringToolSuite, для которой доступно большое количество сэмплов — прописанных кусочков кода.
В роли сервера — Apache Tomcat 6.0.

Фаза построения

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

Приложение «Beverly Flowers» собирается из трёх функциональных компонентов — перехода пользователя на «Домашнюю страницу», «Поиск цветов» и «Просмотреть список цветов».
Для разработки рабочей модели понадобился 1 специалист и 8 дней.

Фаза внедрения

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

Ранее компания «Beverly Flowers» принимала заказы непосредственно в точках сбыта и по телефону.

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

При этом доля заказов по телефону пропорционально снизилась, а значит удалось сократить штат менеджеров по работе с клиентами.

Стоит отметить, что в отличии от Waterfall, жизненный цикл проекта по методологии RAD не является жёстким. Зависимо от стартовых условий, количество фаз может уменьшаться, как и их наполнение.

Плюсы и минусы быстрой разработки приложений в вашей компании

Использовать Rapid Application Development или нет, во многом зависит от стартовых условий, требований заказчика и вида приложения.

К однозначным преимуществам RAD относятся:

1. высокое качество. Взаимодействие пользователей с прототипами повышает функциональность проектов, выполненных в рамках быстрой разработки приложений. Такое программное обеспечение может больше отвечать потребностям заказчика (конечного пользователя), чем при использовании методик Agile/Waterfall.
2. контроль рисков — несмотря на то, что львиная часть материалов о RAD фокусируется на скорости и вовлечении пользователей как ключевым особенностям модели, нельзя исключать третье важное преимущество — снижение рисков . Интересно, но Боэм, создавший первую версию RAD, охарактеризовал спиральную модель как основанную на риске.
   Использование rapid application development позволяет уже на ранних стадиях сосредоточиться на главных факторах риска и приспособиться к ним.
3. за единицу времени выполняется больше проектов в рамках бюджета — так как RAD подразумевает инкрементную модель разработки , шансы на критические ошибки, которые часто случаются в больших проектах по системе Waterfall, снижены.
   Если в проектах по водопадной системе реализация проекта была возможна после шести и более месяцев анализа и разработки, то в RAD вся необходима информация открывается раньше, во время самого процесса создания приложения.

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

Не обошлось и без недостатков.

К минусам rapid application development можно отнести:

1. риск «новизны» — для большинства IT-компаний RAD было новинкой, требующей переосмысления привычных методик работы. Сопротивление новому, необходимость изучения с нуля инструментов и техник приводят к ошибкам во время первых внедрений rapid application development.
2. если пользователи не могут постоянно брать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно повлиять на конечный продукт — особенностью RAD является увеличенное взаимодействие пользователей и разработчиков в отличии от моделей Waterfall, в которых роль пользователей сводится к определению требований. Далее разработчики сами создают систему.
3. уменьшенный контроль — гибкость, адаптивность процесса как одно из преимуществ RAD в идеале означает возможность быстро адаптироваться как к проблемам, так и возможностям.
   К сожалению, придётся отдать предпочтение чему-то одному — гибкости или контролю. В последнем случае методика быстрой разработки приложений не будет жизнеспособной.
4. скудный дизайн — фокусирование на прототипах в некоторых случаях приводит к методике «взлом и тестирование», по которой разработчики постоянно вносят мелкие изменения в отдельные элементы и игнорируют проблемы системной архитектуры.
5. отсутствие масштабируемости — преимущественно RAD используется маленькими и средними проектными командами. Недостатки методологии rapid application development особенно ярко проявляются при использовании быстрой разработки приложений в работе над крупными проектами.

Методология RAD подойдет вашему проекту, если:

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

Методология rapid application development не подойдёт вашему проекту, если:

• для него важно качество и контроль
• идет речь о создании крупномасштабного проекта — предполагаемое максимальное время разработки приложения составляет 60-90 дней, а при написании сотни тысяч строк программного кода соблюсти такое ограничение практически невозможно
• критически важным для реализации является высокий уровень планирования и жесткая дисциплина проектирования , строгое следование заранее разработанным протоколам и интерфейсам
• от приложения в определенной степени зависит безопасность людей.

Вердикт

Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.

Ключевые параметры, которыми оперирует RAD —
скорость и удобство программирования.

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

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

Основные особенности методологии RAD

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

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

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

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

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

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

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

Основные принципы методологии RAD можно свести к следующему:

используется итерационная (спиральная) модель разработки;

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

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

необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

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

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

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

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

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

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

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

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

При разработке приложений с помощью инструментов RAD используется множе­ство готовых объектов, сохраняемых в общедоступном хранилище. Однако обес­печивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля».

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

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

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

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

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

Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных - с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разраба­тываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как исполь­зованием драйверов ODBC или OLE DB, так и применением специализирован­ных средств (компонентов).

Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определен­ным системам управления базами данных. В качестве примера таких систем мож­но привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.

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

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

Логика приложения, построенного с помощью RAD, является событийно-ориен­тированной . Это означает следующее: каждый объект, входящий в состав прило­жения, может генерировать события и реагировать на события, генерируемые дру­гими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение дан­ных в базе данных и т. п.

Разработчик реализует логику приложения путем определения обработчика каж­дого события - процедуры, выполняемой объектом при наступлении соответству­ющего события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помо­щью событий.

Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы дан­ных при операциях удаления, вставки и обновления, а также автоматическую ге­нерацию первичных ключей.

При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз :

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

фаза проектирования;

фаза построения;

фаза внедрения.

На фазе анализа и планирования требований выполняются следующие работы:

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

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

проводится описание информационных потребностей;

ограничивается масштаб проекта;

определяются временные рамки для каждой из последующих фаз;

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

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

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

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

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

После детального рассмотрения процессов определяется количество функциональ­ных элементов разрабатываемой системы. Это позволяет разделить информаци­онную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора меся­цев). С использованием CASE-средств проект распределяется между различными командами - делится функциональная модель.

На этой же фазе происходит определение набора необходимой документации.

Результатами данной фазы являются:

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

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

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

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

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

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

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

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

Завершается физическое проектирование системы, а именно:

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

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

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

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

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

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

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

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

Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.

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

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

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

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

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

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

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

Модель быстрой разработки приложений (Rapid Application Development) - второй пример применения инкрементной стратегии конструирования (рис. 1.5).

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD - высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

q бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

q моделирование данных . Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;

q моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;

q генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;

q тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

Рис. 1.5. Модель быстрой разработки приложений

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

Применение RAD имеет- и свои недостатки, и ограничения.

1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).

2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

Спиральная модель

Спиральная модель - классический пример применения эволюционной стратегии конструирования.

Рис. 1.6. Спиральная модель: 1 - начальный сбор требований и планирование проекта;

начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход

к комплексной системе; 6 - начальный макет системы; 7 - следующий уровень макета;

8 - сконструированная система; 9 - оценивание заказчиком

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование - определение целей, вариантов и ограничений.

2. Анализ риска - анализ вариантов и распознавание/выбор риска.

3. Конструирование - разработка продукта следующего уровня.

4. Оценивание - оценка заказчиком текущих результатов конструирования.

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

В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

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

Достоинства спиральной модели:

1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

2) позволяет явно учитывать риск на каждом витке эволюции разработки;

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

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

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

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

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

Рассмотрим данную модель более подробно. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл ПО по методологии RAD состоит из четырёх фаз (рисунок 21):

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

2. Проектирования;

3. Построения;

4. Внедрения.

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

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

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

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

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

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

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

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

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

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

В заключение перечислим основные принципы технологии RAD:

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

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

Ø обязательное вовлечение пользователей на этапе разработки;

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

Ø тестирование и развитие проекта одновременно с разработкой;

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

Контрольные вопросы к главе 3:

1. Что такое стандартизация и сертификация программного продукта?

2. Какие существуют типы стандартов?

3. Перечислите наиболее известные стандарты жизненного цикла, которые использовались для разработки программного обеспечения?

4. Что такое жизненный цикл ПО?

5. Перечислите основные этапы жизненного цикла ПО. Что такое процесс, действие, задача?

6. Какие типы процессов и конкретные процессы вы запомнили?

7. Расскажите об основных инженерных процессах жизненного цикла ПО.

8. Что такое модель жизненного цикла ПО? Дайте определения основных понятий, связанные с понятием «модель».

9. Какие типы моделей вы знаете? В чем их преимущества, недостатки, область применимости?

10.Что вы можете сказать об особенностях каскадной модели жизненного цикла?

11.В чем отличие обобщенной каскадной модели от базовой?

12.Что вы можете сказать об особенностях спиральной модели жизненного цикла?

13.Перечислите составляющие технологии RAD. Для разработки каких типов ПО можно применять технологию RAD?

14.Опишите основные фазы жизненного цикла по технологии RAD.

15.Перечислите основные принципы технологии RAD.

СПИСОК ЛИТЕРАТУРЫ

1. Аптекарь М. Д., Рамазанов С. К., Фрегер Г. Е. История инженерной деятельности. – Киев, 2003. – 204 с. : ил.

2. Арчибальд Р. Модели жизненного цикла высокотехнологичных проектов. http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб. : Символ-плюс, 1999. – 321 с. : ил.

4. Буч Г. Объектно-ориентированное проектирование с примерами применения. – М.: Конкорд, 1992. – 586с. : ил.

5. Буч Г. Объектно-ориентированный анализ и объектно-ориентированное проектирование на С++. – М. : Бином, – 2001. – 558 с. : ил.

6. Вендров А. М. CASE-технологии. Современные методы и средств проектирования информационных систем. – М. : Финансы и статистика, – 1999. – 256 с. : ил.

7. Вирт Н. Алгоритмы + структуры данных = программы: Пер. с англ. – М. : Мир, 1985. – 406 с.: ил.

8. Дал О., Дейкстра Э., Хоор К. Структурное программирование: Пер. с англ. – М.: Мир, 1975. – 247 с. : ил.

9. Дзержинский Ф. Я., Калиниченко И.М. Дисциплина программирования: концепция и опыт реализации методических средств программной инженерии. – М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. – 245 с. : ил.

10. Жоголев Е. А. Технологии программирования. – М. : Научный мир, 2004. – 216 с. : ил.

11. Закон РФ № 149-ФЗ от 29.07.2006. «Об информации, информационных технологиях и защите информации»// Российская газета, № 165 от 27.07.2006 г.

12. Иванова Г. С. Технология программирования: Учебник для вузов. – 2-е изд., стереотип. – М. : Изд-во МГТУ им. Н.Э.Баумана, 2003. – 320 с.: ил.

13. Калянов Г. Н. CASE: Структурный системный анализ (автоматизация и применение). – М. : «Лори», 1996. – 356 с. : ил.

14. Кораблин М. А. Программирование, ориентированное на объекты: Учебное пособие. – Самара: изд-во СГАУ, 1994. – 94 с.

15. Леоненков А. В. Самоучитель UML. – СПб: ВХВ Петербург, – 2001. – 304 с. : ил.

16. Липаев В. В. Качество программного обеспечения. – М.: Финансы и статистика, 1983. – 263 с. : ил.

17. Липаев В. В. Отладка сложных программ: Методы, средства, технология. –М. : Энергоатомиздат, 1993. – 384 с. : ил.

18. Липаев В. В., Филиппов Е. Н. Мобильность программ и данных в открытых информационных системах. – М. : Научная книга, 1997. – 297 с. : ил.

20. Ожегов С. И. Словарь русского языка. – М. : Мир и образование, 2006. – 1328 с.

21. Технология проектирования комплексов программ АСУ/ В. В. Липаев, Л. А. Серебровский, П. Г. Гаганов и др.; Под ред. Ю. В. Афанасьева, В. В. Липаева. – М. : Радио и связь, 1983. – 256 с. : ил.

22. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.1: Введение в язык Лисп и функциональное программирование.– М. : Мир, 1990. – 447 с. : ил.

23. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.2: Методы и системы программирования.– М. : Мир, 1990. – 319 с. : ил.

24. Boehm B.«A Spiral Model of Software Development and Enhancement», IEEE Computer, Vol. 21, No. 5, pp. 61–72, 1988.

25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.

26. Criteria for Evaluation of Software. ISO TC97/SC7 #383.

27. Dijktra E. 1979. Programming Considered as a Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Microsoft Corporation. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2000. –608 с. : ил.

31. Parnas D., Clements P., Weiss D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

32. Rechtin E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29 (10), p.66.

33. Royce W.W. Managing the Development of Large Software Systems. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1 (4).

35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press. – p.218.

36. Sommerville I. Software engineering. – Addison-Wesley Publishing Company, 1992. p.87.

37. Tesler L. August 1981. The Smalltalk Environment. Byte vol.6(8), p.142.

38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: The MIT Press.

список терминов

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

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

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

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

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

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

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

фаза проектирования;

фаза построения;

фаза внедрения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве итога перечислим основные принципы методологии RAD:

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

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

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

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

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

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

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

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

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

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