В последнее время в прессе все чаще появляется аббревиатура RAD. В большинстве статей этот термин связывается с инструментами быстрой разработки приложений, такими, как 4GL, генераторы приложений и т. д., в то время как RAD (Rapid Application Development) охватывает гораздо более широкий круг вопросов и, скорее, является методологией организации процесса разработки приложений в области информационных систем. В этой статье сделана попытка дать объяснение, почему появился RAD, что это такое и каким образом можно разработать достаточно серьезную систему в срок от трех до шести месяцев.
История развития методов разработки приложений начинается где-то в 60-х годах с началом массового распространения вычислительной техники и появлением необходимости в соответствующем прикладном программном обеспечении. Первый подход специалисты на Западе в шутку называют JDI - Just Do It (просто делай это). Во времена, когда программирование считалось высоким искусством, все отдавалось на откуп разработчику.
К концу 70-х годов были задокументированы и рекомендованы для общего применения наиболее удачные подходы к ведению проектов, получившие название - каскадный метод (Waterfall). Этот метод продолжает широко использоваться и сейчас, так что подробно его описывать нет необходимости. Для каскадного метода характерно разбиение разработки на этапы: техническое обоснование, анализ предметной области, проектирование, построение системы, интеграция и тестирование, внедрение. Согласно каскадной модели, переход на следующий этап возможен только после того, как на предыдущем работа будет полностью завершена, возвратов на пройденные этапы не предусматривается. Определенные на этапе анализа требования к разрабатываемой системе строго документируются и фиксируются на все время разработки проекта. Пользователи, как правило, после подписания спецификации требований в дальнейшей разработке не участвуют и приглашаются вновь уже на этапе тестирования.
Переход с этапа на этап сопровождается выпуском полного комплекта документов на разрабатываемую систему, так что на каждом этапе работа может полностью выполняться другой командой специалистов. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания на разработку, а внимание разработчиков сосредоточивается, в основном, на технических вопросах построения приложения.
Подобный подход хорошо себя зарекомендовал при построении приложений, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные пакеты, системы управления, работающие в реальном времени и многие другие задачи.
Но есть другой класс задач, который не укладывается в схему каскадного подхода. К таким задачам можно отнести приложения из области автоматизации делопроизводства. Как правило, заказчики не в состоянии четко и полно определить все требования к разрабатываемой системе, глядя на чистый лист бумаги перед собой. При попытке составить подробную спецификацию результат обычно бывает следующим: не в силах обозреть все необходимые функции будущей системы, пользователи упускают какие-то важные требования. Кроме того, не имея достаточно четкого представления о том, что они хотят получить от разрабатываемой системы в будущем, пользователи для перестраховки предъявляют требования, без реализации которых вполне можно было бы обойтись.
Если учесть, что при передаче разработки с этапа на этап интерпретация документов принимающей командой может несколько отличаться от того, что имели в виду составители документации, то можно представить, что скажут заказчики, когда их наконец пригласят оценить результаты разработки: "Мы совсем не это имели в виду тогда". Таким образом, прекрасно спроектированная, обладающая потрясающим быстродействием и надежностью система, на разработку которой затрачено полтора года напряженного труда, может оказаться совершенно непригодной для выполнения тех деловых задач, для которых она разрабатывалась. В случае возникновения подобной ситуации возможны два варианта: либо отказаться от внедрения системы, либо проводить достаточно длительные и дорогостоящие работы по доработке и адаптации системы, что влечет превышение сроков разработки и бюджета проекта.
Итак, очевидным недостатком каскадного подхода в его классическом виде является исключение пользователей из процесса разработки и, следовательно, невозможность выявить и устранить вероятные логические ошибки на ранних стадиях проекта. Стоимость же более позднего исправления ошибок многократно возрастает.
Привлечение же пользователей на этапах разработки системы требует иной организации самого процесса ее создания. Приглашенные для участия и наблюдения за правильностью хода работ, будущие пользователи системы не в состоянии оперировать информацией, привычной для специалистов ИТ: схемы таблиц, первичные и заимствованные ключи, блок-схемы алгоритмов. Реальные комментарии появятся только тогда, когда пользователю будет дана возможность поработать с действующим макетом (прототипом) создаваемой системы. При этом весьма желательно, чтобы реакция на замечания, полученные в ходе такой "опытной эксплуатации", была незамедлительной. То есть разработчики должны быть в состоянии представить новый вариант прототипа, учитывающий комментарии пользователя, достаточно быстро.
В середине 80-х годов на фирме DuPont был формализован подход к разработке информационных систем, использующий последовательный выпуск прототипов системы, жесткие ограничения по времени и вовлечение конечных пользователей системы в ее разработку. Он получил название RIPP (Rapid Iterative Production Prototyping - быстрое итеративное прототипирование). После публикации в 1991 году книги Джеймса Мартина (James Martin) Rapid Application Development (быстрая разработка приложений), этот подход получил широкую известность как RAD.
Для разработки каких приложений наиболее подходит RAD? Прежде всего это интерактивные приложения, в которых функциональные возможности ясно просматриваются на уровне пользовательского интерфейса. Должна быть четко определена группа пользователей такого приложения. Большие приложения должны поддаваться разбиению на более мелкие функциональные компоненты. Приложения, которые должны быть реализованы к заранее определенной дате, - прямые кандидаты на разработку в соответствии с методом RAD.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от работы которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход к разработке приложений предполагает, что первые несколько версий наверняка не будут полностью работоспособны, а что это означает в случае управления ядерным реактором, думаю, всем понятно.
В основе подхода RAD к разработке приложений лежат следующие положения.
Пользователи активно участвуют в разработке системы, от начала обследования предметной области до внедрения приложения. Несколько представителей пользователей включаются непосредственно в команду разработчиков, представители остальных периодически участвуют в сессиях по пересмотру результатов работы, что позволяет устранить недопонимание между разработчиками и будущими пользователями системы.
В отличие от каскадного подхода в начале работ RAD не требует полного определения требований к системе, детали могут быть добавлены в ходе разработки. Это позволяет, с одной стороны, сократить длительность этапа анализа по сравнению с каскадным подходом, а с другой - дает разработчикам определенную свободу в определении требований низкого уровня в ходе построения прототипов системы и их обсуждения с ее конечными пользователями.
Выявленные требования должны быть приоритезированы по важности, так как в силу жестких ограничений по времени, которые накладываются на RAD-проекты, может сложиться ситуация, когда придется пожертвовать некоторыми менее важными требованиями к системе, чтобы уложиться в установленные сроки. Другой причиной, по которой следует определять приоритеты для требований, является вполне естественная забывчивость заказчиков, которые в ходе разработки могут вспомнить, что изначально кое-что было упущено. В этом случае следует точно определить важность нового требования, и, если его реализация действительно необходима, возможно, придется пожертвовать некоторыми требованиями, стоящими в списке в категории менее важных. Заказчики должны это четко осознавать.
Как правило, система разрабатывается небольшой командой из четырех-шести человек, включающей одного-двух представителей пользователей. Малый размер гарантирует управляемость команды и тесное взаимодействие между ее членами, а вовлечение нескольких пользователей непосредственно в группу разработки позволяет избежать задержек при принятии решений в ходе работ. Естественно, члены команды разработки должны быть уполномочены принимать необходимые решения.
Во время проекта состав команды практически не меняется, таким образом, по сравнению с каскадным подходом существенно уменьшается необходимость в промежуточной документации.
Разработка ведется итерациями при тесном вовлечении пользователей на протяжении всего жизненного цикла разработки системы. Основную роль здесь играет правило 80/20, которое гласит, что 80% работы может быть выполнено за 20% времени, затрачиваемого на всю работу. Нет смысла затрачивать усилия на тонкую настройку системы, когда еще не до конца определены основные требования к ней. Каждый шаг должен быть закончен настолько, насколько это необходимо для того, чтобы сделать следующий.
На срок выпуска каждого прототипа системы накладываются жесткие ограничения по времени, превышать которые не разрешается. По истечении операционного интервала времени, отведенного на разработку данного прототипа, он представляется заказчикам для обсуждения, с тем чтобы удостовериться, что разработка идет в правильном направлении, или, в противном случае, вовремя исправить допущенные ошибки. Здесь важно обеспечить, чтобы при оценке результатов разработки были представлены все группы будущих пользователей.
Тестирование системы должно производиться постепенно на протяжении всего жизненного цикла системы и не является теперь отдельной стадией, хотя в некоторых случаях эта фаза может быть введена.
Жесткие сроки разработки и небольшой размер команды, естественно, накладывают ограничения на размер приложения, которое может быть выполнено одной группой разработчиков за отведенное на RAD-проект время: три-шесть месяцев. Средний размер такого приложения на сегодня составляет около двух тысяч функциональных точек. В случае, если размер предполагаемой системы превышает эту цифру, требуется разбиение приложения на части, приемлемые для разработки одной командой в соответствии с методологией RAD. Далее, при наличии нескольких команд возможна параллельная разработка системы. В такой ситуации стадия анализа должна быть выполнена более тщательно, с тем чтобы определить возможные области пересечения при работе нескольких команд разработки и подробно описать эти области, используя CASE-средства. В соответствующей литературе [1, 2] приводятся достаточно подробные рекомендации по разделению крупных систем на подсистемы для обеспечения их разработки по методологии RAD и, естественно, последующей сборки системы в целом.
Одним из самых важных положений является необходимость сотрудничества между всеми участвующими в проекте сторонами. Заказчики должны понимать, что тесные временные рамки проекта могут не позволить разработчикам реализовать абсолютно все требования, которые предъявят пользователи к разрабатываемой системе, и что-то может быть перенесено на следующий проект.
Таким образом, сильная сторона подхода RAD состоит в том, что он позволяет непосредственно в ходе разработки быстро выявить и уточнить, а затем реализовать необходимый набор функциональных возможностей и поставить систему, которая действительно удовлетворяет бизнес-требованиям, актуальным на момент внедрения системы.
Естественно, новый подход требует соответствующего инструментария. И, как правило, одним инструментом здесь не обойтись. Ниже кратко перечислен основной набор инструментов, необходимых для ведения проектов в соответствии с методологией RAD.
CASE-средства. Быстрая разработка не предполагает полного отсутствия проекта будущей системы. Для того чтобы система была пригодной для дальнейшего сопровождения, она должна быть снабжена всей необходимой информацией о процессах делопроизводства, лежащих в ее основе, о моделях процессов и данных самой системы, об ее архитектуре. Универсальная электронная документация на проект должна пополняться по мере выявления новых деталей и в идеале может быть использована для генерации всех документов, необходимых для сопровождения системы. Роль CASE-средств существенно возрастает при проведении больших проектов, включающих несколько команд разработки, где на CASE возлагается контроль за целостностью и непротиворечивостью общего проекта системы. Весьма желательно наличие общего репозитория информации о проекте, позволяющего командам повторно использовать уже разработанные части приложения.
4GL либо генератор приложений. Необходимость частого представления пользователям работающих прототипов не оставляет времени для ручного кодирования. Следует четко представлять, что результатом разработки должна быть высокопроизводительная и надежная система, а не частично пригодный прототип, поэтому к выбору инструментария реализации надо подходить особенно осторожно.
Средства управления конфигурациями. Итеративный характер разработки предполагает наличие множества версий системы. Разработчики должны иметь возможность вернуться к любой из предыдущих версий, если работа на данной итерации зашла в тупик. Кроме того, хотя размеры команды и невелики, работа носит коллективный характер, таким образом, следует исключить возможность одновременного доступа нескольких разработчиков к одному источнику для его модификации. Под контроль менеджера конфигураций желательно завести всю информацию о проекте: файлы, экраны, отчеты, информацию из CASE-средств.
Внесение изменений в ходе работы не должно быть осложнено дополнительными бюрократическими процедурами.
Средства автоматизированного тестирования. В связи с тем что система находится в состоянии постоянного развития, настоятельно рекомендуется использовать средства автоматизированного тестирования, для того чтобы, раз сформулировав критерии правильной работоспособности уже разработанных частей приложения, избавиться от необходимости ручного ввода данных для проверки того, как изменения в данной части приложения скажутся на других.
Не последнюю роль играет планировщик проекта. На сегодняшний день существует достаточно много программ, позволяющих определить состав и последовательность работ, оценить трудозатраты, распределить нагрузку на участников проекта и затем вести контроль за ходом работы.
Общим требованием к инструментам является необходимость хорошей интеграции между ними, чтобы информация передавалась от одного инструмента к другому непосредственно, минуя ручной ввод - источник ошибок и замедления работы.
Желательно, чтобы средства разработки обеспечивали возможность переноса разработанного приложения с одной платформы на другую. Особенно актуально это для сторонних разработчиков, ведущих разработку на своей технической базе, а затем устанавливающих систему на платформе заказчика. Совершенно невозможно иметь специальный инструментарий под каждую из возможных платформ и их сочетаний.
Вероятно, есть еще масса полезных инструментов, но это уже детали, касающиеся конкретной среды разработки и, скорее всего, связанные с техническими вопросами реализации приложения.
Кроме инструментария разработки и методик его использования в методологии RAD большое внимание уделяется людям, участвующим в разработке. Это касается и подбора членов команд разработки, и выбора представителей заказчика, участвующих в периодической оценке прототипов системы. К каждому участнику разработки предъявляются достаточно серьезные требования, связанные с интенсивным характером работ, необходимостью тесного взаимодействия разработчиков с пользователями и между собой.
Несмотря на то что общие положения RAD достаточно прозрачны, на сегодняшний день общее представление о RAD, по-видимому, не определено.
С целью обобщения удачного опыта при проведении RAD-проектов и для создания международного стандарта на RAD в январе 1994 года группой ведущих предприятий Великобритании был создан консорциум DSDM (Dynamic Systems Development Method - метод разработки динамических систем). Версия 1 руководства DSDM вышла в феврале 1995 года. В декабре 1995 года была опубликована Версия 2, в которой был учтен опыт проектов, реализованных с применением Версии 1.
Сейчас консорциум насчитывает более 90 постоянных членов (или около 400 вместе со свободными подписчиками). Среди постоянных членов консорциума такие компании, как: British Airways, Computer Associates, IBM, Magic Software, Oracle, Software AG, British Rail, British Telecom, SAS Software, Texas Instruments Information Engineering, Barclays Bank, Ford Motor Company, James Martin & Co, LBMS, Olivetti, Symantec. На сегодняшний день единственной российской компанией, входящей в состав консорциума и представляющей его на территории России, является "Аргуссофт Компани". Готовится к публикации Версия 2 руководства DSDM на русском языке, которая будет доступна для заинтересованных организаций, вступивших в состав консорциума.
Следуя одному из своих главных принципов - итеративному развитию, RAD не стоит на месте. Методология постоянно развивается за счет обобщения удачного опыта проведения RAD-проектов и анализа неудач. Созданный в Великобритании, консорциум DSDM становится международной организацией, приглашая к сотрудничеству разработчиков разных стран. Консорциум, несомненно, заинтересован в изучении специфики, характерной для разработки информационных систем в России.
Как представитель DSDM на территории России Аргуссофт Компани приглашает организации, проявляющие интерес к рассматриваемым вопросам, вступить в члены консорциума.
Литература
1. James Martin. Rapid Application Development.
2. DSDM Consortium. Dynamic Systems Development Method. Version 2.
Евгений Фоминский
Для разработки каких приложений наиболее подходит RAD? Прежде всего там, где функциональные возможности ясно просматриваются на уровне пользовательского интерфейса
