В конце 2002 года московское издательство "Лори" выпустило книгу Алистера Коберна (Alistair Cockburn) "Быстрая разработка программного обеспечения". Русское название книги немного удивляет, потому что в оригинале она называется "Agile Software Development" и более правильный перевод звучал бы как "Гибкая разработка ПО". Впрочем, не будем придираться к переводчику, потому что подобных книг на русском языке еще не издавалось.

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

Возьмем, к примеру, строительство здания. В наше время строительство дома - совершенно простая задача. Все знают, какие действия надо предпринять, чтобы в итоге получился нужный дом. Процесс предсказуем. Роли четко определены. Технологии отлично известны. При разработке ПО возникают совершенно уникальные проблемы: пользователи зачастую просто не могут сказать, что же им в действительности нужно, пока не попробуют продукт в действии; требования постоянно меняются, поэтому создание солидного плана на весь проект лишено смысла; квалифицированных кадров не хватает; используемые технологии часто "сырые", а инструменты несовершенны. В таких условиях традиционные подходы к управлению проектами очень часто терпят поражение.

Периодически находились люди, которые начинали понимать проблемы создания ПО, но настоящий прорыв происходит именно теперь, после появления экстремального программирования (eXtreme Programming, www.extremeprogramming.com) и создания альянса гибкой разработки ПО (Agile Alliance, www.agilealliance.org). Гибкие методологии ломают стереотипы и полностью изменяют процесс разработки программ. Они изменяют сами принципы организации процесса.

Чем же отличаются гибкие методологии от традиционных? Можно выделить несколько основных отличий:

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

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

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

Какие бывают методологии, как они влияют на процесс разработки ПО и зачем они вообще нужны? В книгу включены крайне интересные приложения: программирование как построение теорий, применение языковых игр Витгенштейна к разработке ПО, применение методов Мусаши (самурай, живший в 17 веке и написавший книгу "Книга пяти колец") к разработке ПО.

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

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

Для управляющих проектами (Project Manager) и лидеров групп (Team Leader) книга из категории must read. Ваша эффективность, как руководителя, заметно возрастет.

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

Книгу Алистера Коберна "Быстрая разработка программного обеспечения" можно приобрести в интернет-магазине www.rodina.by (www.rodina.by/book/info/go/6047.html).

Михаил ДУБАКОВ

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

Модель быстрой разработки приложений (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

Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки прило­жений - 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, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений 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-средств, обеспечивающих целостность проекта;

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

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

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

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

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

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

Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Концепция RAD стала ответом на методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада». Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Методология RAD является одним из подходов к разработке ПО в рамках спиральной модели ЖЦ.

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

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

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

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

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

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

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

выделение наиболее приоритетных функций, требующих проработки в первую очередь;

описание информационных потребностей.

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

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

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

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

список расположенных по приоритету функций будущего ПО ИС;

предварительные модели ПО.

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

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

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

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

определяется состав необходимой документации.

Далее проект распределяется между различными командами разработчиков. В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированного подхода). Результатом данной стадии должны быть:

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

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

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

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

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

На стадии реализации выполняется быстрая разработка приложения:

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

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

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

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

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

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

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

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

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

Применение технологии RAD целесообразно, когда:

требуется выполнение проекта в сжатые сроки (90 дней);

нечетко определены требования к ПО;

проект выполняется в условиях ограниченности бюджета;

интерфейс пользователя (GUI) есть главный фактор;

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

ПО не обладает большой вычислительной сложностью.

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

Рисунок 1 - Сравнение RAD и Каскадного метода