Технология RAD. Ещё раз про семь основных методологий разработки
Методология разработки софта - организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:
- Waterfall - традиционный подход.
- RUP (Rational Unified Process) - рациональный.
- Agile - общая методология гибкой разработки.
- Crystal Clear - подход с уравниванием разработчиков в коллективе.
- Spiral - спиральный метод.
- DSDM (Dynamic Systems Development Model) - динамическая модель.
- FDD (Feature Driven Development) - методология, рассматривающая будущие изменения.
- JAD (Joint Application Development) - ориентированный на пользователя подход.
- RAD (Rapid Application Development) - модель быстрой разработки.
- Scrum - концепция работы в условиях сорванных сроков и идеологического кризиса.
- XP (Extreme Programming) - экстремальная разработка в динамической среде.
- LD (Lean Development) - метод, предполагающий бережное отношение ко всем участникам процесса.
Давайте попробуем разобраться, что скрывается за этими английскими названиями.
Waterfall
Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии - децентрализация и строгий контроль над сроками и качеством исполнения.
На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе - это дорогостоящие исправления.
RUP
RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:
- Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
- Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
- Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает «мясом».
- Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
- Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
- Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.
Agile
Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:
- Неформальные отношения важнее задокументированных. То есть устные договоренности между сотрудниками, между заказчиком и исполнителем важнее всего, что отражено в планах, договорах и техническом задании. Иначе говоря, клиент всегда прав.
- Работающий продукт - главная оценка прогресса. Важны не инструменты, решения, производительность и изящество, а тот факт, что все запланированные возможности реализованы.
Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.
Crystal Clear
Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии - каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.
Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.
Spiral
Модель спирального жизненного цикла - это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи - следующий виток спирали.
Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.
DSDM
Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.
В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.
FDD
FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:
- Разработка каждого крупного проекта должна иметь системность.
- Процессы должны быть простыми и проработанными.
- Ценность и логичность процесса должна быть ясна каждому члену команды.
- Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.
FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.
JAD
JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.
В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.
RAD
RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:
- Использование фокус-групп для сбора требований.
- Прототипирование и пользовательское тестирование конструкций.
- Повторное использование программных компонентов.
- Использование плана, не включающего переработку, или дизайн следующей версии продукта.
- Проведение неформальных совещаний по запросу одной из сторон.
RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.
Scrum
Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).
Благодаря этому контроль за выполнением становится более гибким, а разработчики быстрее реагируют на возникающие проблемы. Традиционное планирование отходит на второй план, его место занимает журнал спринтов.
XP
Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:
- Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
- Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
- Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
- Рефакторинг. Улучшение качества кода без уменьшения функциональности.
- Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
- Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.
LD
Бережливая разработка ПО - ещё одно ответвление гибкой методологии, предполагающее сохранение высокого морально-функционального состояния разработчиков. Это выражается в:
- Поощрении сотрудников за успешную работу.
- Изменении текущих задач только по мере необходимости или по запросу заказчика.
- Строгом выполнении плана: всё, что сверх - считается потерями времени и ресурсов.
- Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».
В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.
Быстрая разработка приложений
Модель быстрой разработки приложений (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) трудности контроля и управления временем разработки.
Быстрая разработка программ
Быстрая разработка программ - технология программирования, обеспечивающая ускоренную разработку и модификацию приложений за счет использования объектно-ориентированного и визуального программирования.
По-английски: Rapid Application Development
Синонимы английские: RAD
См. также: Автоматизированное программирование
- - - установление соответствия содержания образовательных программ требованиям нормативных документов, являющихся составной частью государственного стандарта в соответствующей области образования...
Педагогический терминологический словарь
- - Быстрорастущая сельскохозяйственная культура, высаживаемая на земле, доступной только в течение короткого периода времени, например между посадками основной культуры, или – иногда – культура, высаживаемая между...
Словарь бизнес терминов
- - выработка стратегического замыла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, состояние, обсуждение, принятие плановых, проектных,...
Большой бухгалтерский словарь
- - ".....
Официальная терминология
- - 1) река в Земле Войска Донского, левый приток Донца. Берет начало во 2-м Донском округе, пересекает юго-восточный угол Донецкого и в 1-м Донском округе впадает в Донец, выше Усть-Быстрянской станицы...
- - Иркутской губернии и уезда, правый приток реки Иркут, берет начало в хребте Хамар-Дабан, двумя истоками, вершины которых находятся в гранитных ущельях...
Энциклопедический словарь Брокгауза и Евфрона
- - река в Ростовской области РСФСР, левый приток Северского Донца. Длина 218 км, площадь бассейна 4180 км2. Течёт по равнине. Питание преимущественно снеговое. В верховьях Б. и её притоки летом пересыхают...
Большая Советская энциклопедия
- - См. forme allegro...
Пятиязычный словарь лингвистических терминов
- - См. СТРОГОСТЬ -...
- - См....
В.И. Даль. Пословицы русского народа
- - См. ПОРА - МЕРА -...
В.И. Даль. Пословицы русского народа
-
Словарь синонимов
- - сущ., кол-во синонимов: 2 фаст-фуд фастфуд...
Словарь синонимов
- - сущ., кол-во синонимов: 1 чес...
Словарь синонимов
- - сущ., кол-во синонимов: 1 игра...
Словарь синонимов
- - сущ., кол-во синонимов: 1 река...
Словарь синонимов
"Быстрая разработка программ" в книгах
РАЗРАБОТКА ПРОГРАММ
Из книги Практика управления человеческими ресурсами автора Армстронг МайклРАЗРАБОТКА ПРОГРАММ 6. Для каждого аспекта электронного научения уточните следующее:? потребность в научении;? то, каким образом электронное научение удовлетворит эту потребность;? систему научения, которая будет использоваться;? содержание (в широком смысле), которое
Путь 2. Быстрая разработка приложений
автора Джестон ДжонПуть 2. Быстрая разработка приложений Большинство автоматизированных решений BPM дает возможность интерактивно конфигурировать процессы между персоналом бизнеса и техническими специалистами, когда специалисты по процессам и/или хозяева процессов садятся за стол
Шаг 9. Разработка и запуск маркетинговых программ
Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон ДжонШаг 9. Разработка и запуск маркетинговых программ Подумайте над целесообразностью запуска формальных маркетинговых кампаний на рынке, конкретно нацеленных на внешние заинтересованные стороны. Организация даже, возможно, сочтет необходимым опубликовать свою программу
3. Разработка и совершенствование общественных программ и услуг
Из книги Маркетинг для государственных и общественных организаций автора Котлер Филип3. Разработка и совершенствование общественных программ и услуг «Как вам, возможно, уже известно, мы получили отличную новость после того, как я направил петицию по адресу Даунинг-стрит, 10. Теперь они обещают потратить $280 млн на улучшение обедов в школьных столовых
Создание устноисторических проектов и разработка научно-исследовательских программ по устной истории
Из книги Устная история автора Щеглова Татьяна КирилловнаСоздание устноисторических проектов и разработка научно-исследовательских программ по устной истории Специфика деятельности в области устной истории. Разработка концепции исследования. Постановка целей. Определение задач. Направления и формы устноисторической
Из книги Гражданский кодекс РФ автора ГАРАНТГлава 8 Разработка программ
Из книги UNIX - универсальная среда программирования автора Пайк РобГлава 8 Разработка программ Первоначально системе UNIX предназначалась роль среды для разработки программ. В настоящей главе мы обсудим некоторые применяемые с этой целью программные средства на примере солидной программы - интерпретатора языка программирования,
10. Классы памяти и разработка программ
Из книги Язык Си - руководство для начинающих автора Прата Стивен10. Классы памяти и разработка программ ЛОКАЛЬНЫЕ И ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕКЛАССЫ ПАМЯТИФУНКЦИЯ ПОЛУЧЕНИЯ СЛУЧАЙНЫХ ЧИСЕЛПРОВЕРКА ОШИБОКМОДУЛЬНОЕ
Глава 3 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual Basic 3.0
автора Волков Владимир БорисовичГлава 3 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual Basic
Глава 4 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual C++ 3.0
Из книги Программирование для карманных компьютеров автора Волков Владимир БорисовичГлава 4 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual C++ 3.0 По сравнению с eVB язык C++, безусловно, предоставляет разработчику больше возможностей. Несмотря на то что в eVB можно было сделать почти все, что можно сделать в eVC (так в этой главе будет называться eMbedded Visual C++
Глава 5 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual С++ 4.0
Из книги Программирование для карманных компьютеров автора Волков Владимир БорисовичГлава 5 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual С++ 4.0 Поскольку все сказанное о среде VC 3.0 относится в полной мере и к eVC 4.0, да и сами среды похожи друг на друга как близнецы, нет нужды снова описывать среду разработки. Использовать eVC 4.0 необходимо, если
Глава 6 NET Compact Framework и разработка программ для Pocket PC в Microsoft Visual Studio.NET 2003
Из книги Программирование для карманных компьютеров автора Волков Владимир БорисовичГлава 6 NET Compact Framework и разработка программ для Pocket PC в Microsoft Visual Studio.NET 2003 Не покривлю душой, если скажу, что мы переходим к одной из самых интересных частей книги. На самом деле, еще совсем недавно технология. NET вызывала у меня вполне законные опасения. Уж очень это все было
Глава 12 Разработка ценовых стратегий и программ
Из книги Маркетинг менеджмент. Экспресс-курс автора Котлер ФилипГлава 12 Разработка ценовых стратегий и программ В этой главе вы найдете ответы на следующие вопросы:1. Как потребители воспринимают и сравнивают цены?2. Как происходит первоначальное установление цены?3. Как происходит адаптация цен к различным рыночным ситуациям и
8.6. Разработка программ стимулирования труда
Из книги Управление персоналом автора Шевчук Денис Александрович8.6. Разработка программ стимулирования труда Стимулирование труда – способ вознаграждения работников за участие в производстве, основанный на сопоставлении эффек-тивности труда и требований технологии.Существенная проблема в области управления производством –
Глава 5. Разработка и виды туристических программ
Из книги Организация туристического бизнеса: технология создания турпродукта автора Мишина Лариса АлександровнаГлава 5. Разработка и виды туристических программ Изначальной функцией туристических фирм является планирование туров. В процессе выполнения этой функции создается конкурентоспособный и привлекательный туристский продукт.Для того чтобы его создать, необходимо
Срочная разработка программного обеспечения - это суровая необходимость современного ИТ-рынка. Положение индустрии таково, что приходится реагировать достаточно эффективно на любые условия, которые меняются часто. Быстро, срочно - эти слова не исчезают из лексикона успешных разработчиков. Приложения должны удовлетворять текущий запрос, предоставляя тот функционал, о котором вчера лишь догадывались, а сегодня он уже необходим именно это и есть и срочная разработка программного обеспечения. Разработка программ сегодня проникла буквально во все сферы жизни и новые требования могут появится с любой стороны. Программное обеспечение сегодня это:
- Современное управление
- Контроль
- Мониторинг
Срочно - не значит некачественно?
Разработка программ - это трудоёмкий процесс, который требователен к уровню и знаниям исполнителя. Традиционно считается, что качество подразумевает долгий цикл. Но так ли это на самом деле? Возможна ли быстро и срочно разработать ПО?
- Чтобы продукт получался быстро - необходима либо слаженная команда профессионалов, либо отдельный исполнитель-универсал. Разумеется, это не подходит ко всем программам.
- Контроль качества - обязательная процедура. Контроль качества и отлов «багов» в таком процессе как создание программного обеспечения не может быть исключён из производственного процесса, даже для ускорения. Это необходимое условие для профессионально сделанной программы.
- Чтобы срочность не вредила итоговому продукту, нужны исполнители, которые давно освоили и создали свой производственный процесс. Скорее всего разработка ПО у таких специалистов пройдёт действительно качественно и быстро.
Заказать срочные услуги разработки сегодня может любой, кому исполнение необходимо быстро, срочно и профессионально. Остаётся открытым вопрос, где найти грамотных специалистов под срочное создание программ?
Поиск исполнителей.
Много специалистов, вольнонаёмных и объединённых в организации оказывают подобные услуги. Заказать у них можно всё что угодно, естественно что цены будут зависеть от уровня специалиста, его востребованности и сложности задачи. Есть три основных пути, которыми пользуется большинство заказчиков.
- Студийная разработка. Студии предполагают хорошее качество исполнения, но за срочность берут очень и очень солидные надбавки. Заказать у них программу можно, если заказчик готов оплатить эти расходы.
- Фрилансеры. Спорный вопрос. Можно сэкономить, а можно получить сорванные сроки и очень посредственное качество.
Специализированные платформы, которые предлагают удобную площадку для размещения заказа и конкуренции вольнонаёмных специалистов. Отличаются от предыдущего варианта быстротой, безопасностью и возможность выбрать наиболее конкурентное предложение. Лучший из сервисов - Юду, который даёт возможность изучить правдивое портфолио каждого специалиста и выбрать наиболее подходящий вариант.
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей (чему в значительной степени способствовал прогресс в области вычислительной техники, а также появление удобного графического интерфейса пользователя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения - инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем.
Основные особенности методологии 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, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.