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

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх - считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

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

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

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

Появление RAD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, компании «Beverly Flowers» нужно приложение для онлайн-заказа цветов на дом. На создание отводится 50 дней, бюджет — 3 000 долларов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Вердикт

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

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

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

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