Один из подходов к разработке ПО в рамках спиральной модели ЖЦ – получившая широкое распространение методология (технология) быстрой разработки приложений RAD (Rapid Application Development) . Данная модель очень хорошо подходит к разработке учебных программ, т.к. включает в себя три составляющие:
Ø небольшую команду программистов (от 2 до 10 человек);
Ø короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
Ø повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Рассмотрим данную модель более подробно. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл ПО по методологии RAD состоит из четырёх фаз (рисунок 21):
1. Анализа и планирования требований;
2. Проектирования;
3. Построения;
4. Внедрения.
На первой фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности (связи). Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, устанавливаются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.п.
Результатом фазы должны быть: список расставленных по приоритету функций будущей ПС; предварительная функциональная модель ПС; предварительная информационная модель ПС.
На второй фазе проектирования часть пользователей принимают участие в техническом проектировании системы под руководством специалистов-разработчиков и, взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы . При необходимости корректируется функциональная модель, создаются частичные прототипы: экранов, отчетов, устраняющие неясности или неоднозначности. Устанавливаются требования разграничения доступа к данным . На этой же фазе происходит определение необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении системы на подсистемы.
Результатом данной фазы должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем; точно определенные интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы . Таким образом, на следующую фазу передается более полная и полезная информация.
На третьей фазе построения выполняется непосредственно сама быстрая разработка приложения (реализация подсистем). На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.
После окончания разработки подсистем производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование системы в целом. Завершается физическое проектирование системы: определяется необходимость распределения данных; осуществляется анализ использования данных; производится физическое проектирование базы данных; определяются требования к аппаратным ресурсам; определяются способы увеличения производительности; завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На четвертой фазе внедрения производятся обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы.
Технология RAD (как и любая другая) не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Она неприменима для разработки операционных систем; сложных расчетных программ с большим объемом программного кода и сложными уникальными алгоритмами управления; приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (приложения реального времени), так как итерационный подход предполагает, что несколько первых версий не будут полностью соответствовать требованиям.
В заключение перечислим основные принципы технологии RAD:
Ø разработка приложений итерациями;
Ø необязательность полного завершения работ на каждом этапе ЖЦ;
Ø обязательное вовлечение пользователей на этапе разработки;
Ø использование прототипирования, позволяющего выяснить и удовлетворить все требования конечного пользователя;
Ø тестирование и развитие проекта одновременно с разработкой;
Ø грамотное руководство разработкой, четкое планирование и контроль выполнения работ.
Контрольные вопросы к главе 3:
1. Что такое стандартизация и сертификация программного продукта?
2. Какие существуют типы стандартов?
3. Перечислите наиболее известные стандарты жизненного цикла, которые использовались для разработки программного обеспечения?
4. Что такое жизненный цикл ПО?
5. Перечислите основные этапы жизненного цикла ПО. Что такое процесс, действие, задача?
6. Какие типы процессов и конкретные процессы вы запомнили?
7. Расскажите об основных инженерных процессах жизненного цикла ПО.
8. Что такое модель жизненного цикла ПО? Дайте определения основных понятий, связанные с понятием «модель».
9. Какие типы моделей вы знаете? В чем их преимущества, недостатки, область применимости?
10.Что вы можете сказать об особенностях каскадной модели жизненного цикла?
11.В чем отличие обобщенной каскадной модели от базовой?
12.Что вы можете сказать об особенностях спиральной модели жизненного цикла?
13.Перечислите составляющие технологии RAD. Для разработки каких типов ПО можно применять технологию RAD?
14.Опишите основные фазы жизненного цикла по технологии RAD.
15.Перечислите основные принципы технологии RAD.
СПИСОК ЛИТЕРАТУРЫ
1. Аптекарь М. Д., Рамазанов С. К., Фрегер Г. Е. История инженерной деятельности. – Киев, 2003. – 204 с. : ил.
2. Арчибальд Р. Модели жизненного цикла высокотехнологичных проектов. http://www.pmprofy.ru/content/rus/107/1073-article.html
3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб. : Символ-плюс, 1999. – 321 с. : ил.
4. Буч Г. Объектно-ориентированное проектирование с примерами применения. – М.: Конкорд, 1992. – 586с. : ил.
5. Буч Г. Объектно-ориентированный анализ и объектно-ориентированное проектирование на С++. – М. : Бином, – 2001. – 558 с. : ил.
6. Вендров А. М. CASE-технологии. Современные методы и средств проектирования информационных систем. – М. : Финансы и статистика, – 1999. – 256 с. : ил.
7. Вирт Н. Алгоритмы + структуры данных = программы: Пер. с англ. – М. : Мир, 1985. – 406 с.: ил.
8. Дал О., Дейкстра Э., Хоор К. Структурное программирование: Пер. с англ. – М.: Мир, 1975. – 247 с. : ил.
9. Дзержинский Ф. Я., Калиниченко И.М. Дисциплина программирования: концепция и опыт реализации методических средств программной инженерии. – М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. – 245 с. : ил.
10. Жоголев Е. А. Технологии программирования. – М. : Научный мир, 2004. – 216 с. : ил.
11. Закон РФ № 149-ФЗ от 29.07.2006. «Об информации, информационных технологиях и защите информации»// Российская газета, № 165 от 27.07.2006 г.
12. Иванова Г. С. Технология программирования: Учебник для вузов. – 2-е изд., стереотип. – М. : Изд-во МГТУ им. Н.Э.Баумана, 2003. – 320 с.: ил.
13. Калянов Г. Н. CASE: Структурный системный анализ (автоматизация и применение). – М. : «Лори», 1996. – 356 с. : ил.
14. Кораблин М. А. Программирование, ориентированное на объекты: Учебное пособие. – Самара: изд-во СГАУ, 1994. – 94 с.
15. Леоненков А. В. Самоучитель UML. – СПб: ВХВ Петербург, – 2001. – 304 с. : ил.
16. Липаев В. В. Качество программного обеспечения. – М.: Финансы и статистика, 1983. – 263 с. : ил.
17. Липаев В. В. Отладка сложных программ: Методы, средства, технология. –М. : Энергоатомиздат, 1993. – 384 с. : ил.
18. Липаев В. В., Филиппов Е. Н. Мобильность программ и данных в открытых информационных системах. – М. : Научная книга, 1997. – 297 с. : ил.
20. Ожегов С. И. Словарь русского языка. – М. : Мир и образование, 2006. – 1328 с.
21. Технология проектирования комплексов программ АСУ/ В. В. Липаев, Л. А. Серебровский, П. Г. Гаганов и др.; Под ред. Ю. В. Афанасьева, В. В. Липаева. – М. : Радио и связь, 1983. – 256 с. : ил.
22. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.1: Введение в язык Лисп и функциональное программирование.– М. : Мир, 1990. – 447 с. : ил.
23. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.2: Методы и системы программирования.– М. : Мир, 1990. – 319 с. : ил.
24. Boehm B.«A Spiral Model of Software Development and Enhancement», IEEE Computer, Vol. 21, No. 5, pp. 61–72, 1988.
25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.
26. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
27. Dijktra E. 1979. Programming Considered as a Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press.
28. http://www.pmi.ru/glossary/.
29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.
30. Microsoft Corporation. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2000. –608 с. : ил.
31. Parnas D., Clements P., Weiss D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.
32. Rechtin E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29 (10), p.66.
33. Royce W.W. Managing the Development of Large Software Systems. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.
34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1 (4).
35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press. – p.218.
36. Sommerville I. Software engineering. – Addison-Wesley Publishing Company, 1992. p.87.
37. Tesler L. August 1981. The Smalltalk Environment. Byte vol.6(8), p.142.
38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: The MIT Press.
список терминов
В конце 2002 года московское издательство "Лори" выпустило книгу Алистера Коберна (Alistair Cockburn) "Быстрая разработка программного обеспечения". Русское название книги немного удивляет, потому что в оригинале она называется "Agile Software Development" и более правильный перевод звучал бы как "Гибкая разработка ПО". Впрочем, не будем придираться к переводчику, потому что подобных книг на русском языке еще не издавалось.
Отрасль разработки ПО достаточно молодая и активно развивающаяся. Еще формируются основные принципы разработки программ, постоянно появляются новые методологии, практики, языки программирования, новые технологии и инструменты. Все меняется очень динамично, поэтому практически невозможно создать единую правильную методологию разработки ПО. Однако до сих пор не прекращаются попытки изобрести "серебряную пулю", которая смогла бы решить все проблемы разработчиков. Возможно, к этому подталкивает наличие подобных процессов в других областях.
Возьмем, к примеру, строительство здания. В наше время строительство дома - совершенно простая задача. Все знают, какие действия надо предпринять, чтобы в итоге получился нужный дом. Процесс предсказуем. Роли четко определены. Технологии отлично известны. При разработке ПО возникают совершенно уникальные проблемы: пользователи зачастую просто не могут сказать, что же им в действительности нужно, пока не попробуют продукт в действии; требования постоянно меняются, поэтому создание солидного плана на весь проект лишено смысла; квалифицированных кадров не хватает; используемые технологии часто "сырые", а инструменты несовершенны. В таких условиях традиционные подходы к управлению проектами очень часто терпят поражение.
Периодически находились люди, которые начинали понимать проблемы создания ПО, но настоящий прорыв происходит именно теперь, после появления экстремального программирования (eXtreme Programming, www.extremeprogramming.com) и создания альянса гибкой разработки ПО (Agile Alliance, www.agilealliance.org). Гибкие методологии ломают стереотипы и полностью изменяют процесс разработки программ. Они изменяют сами принципы организации процесса.
Чем же отличаются гибкие методологии от традиционных? Можно выделить несколько основных отличий:
- Частые поставки работающего ПО (с интервалами от двух недель до двух месяцев).
- Приспособленность к изменениям требований, что особенно сложно сделать при традиционных способах разработки.
- Тесное взаимодействие с представителями заказчика на протяжении всего цикла разработки.
- Понимание важности хороших коммуникаций внутри команды, тогда как традиционные методологии редко придают коммуникациям серьезное значение.
- Понимание и использование индивидуальных черт членов команды, в то время как традиционные методологии вообще не учитывают индивидуумов.
- Постоянное повышение эффективности работы команды на основе регулярных оценок.
- Стремление к простоте, что редко можно встретить в традиционных методологиях.
Многие гибкие методологии позволяют использовать сильные черты отдельно взятой команды разработчиков, потому что их можно подстроить под команду. Традиционные методологии заставляют команду подстроиться под себя.
Алистер Коберн - отличный разработчик и великолепный писатель. Он умеет ясно и последовательно излагать мысли и увлекать за собой. Так все-таки, о чем же книга? Она рассказывает о том, что каждый человек индивидуален и как использовать индивидуальность для пользы проекта. Что создание ПО представляет собой кооперативную игру изобретения и коммуникаций. Что коммуникации внутри команды крайне важны и зачастую определяют успех или неудачу проекта.
Какие бывают методологии, как они влияют на процесс разработки ПО и зачем они вообще нужны? В книгу включены крайне интересные приложения: программирование как построение теорий, применение языковых игр Витгенштейна к разработке ПО, применение методов Мусаши (самурай, живший в 17 веке и написавший книгу "Книга пяти колец") к разработке ПО.
Кроме того, в книге множество реальных примеров и диалогов, которые помогают лучше понять суть проблем разработки ПО. Существует множество мнений о вреде и пользе методологий. Книга "Быстрая разработка программного обеспечения" поможет вам найти ответы на многие вопросы.
Что действительно подкупает, так это исключительная рассудительность автора. Он никогда не заявляет, что его мнение единственно правильное, он всегда аргументирует свою точку зрения и делает это убедительно. Если вы до сих пор не особенно интересовались методологиями при разработке программного обеспечения, то после прочтения книги обязательно заинтересуетесь. Если активно интересовались, но не особенно применяли, то начнете применять.
Для управляющих проектами (Project Manager) и лидеров групп (Team Leader) книга из категории must read. Ваша эффективность, как руководителя, заметно возрастет.
Если говорить о качестве издания, то перевод достаточно хорош, за исключением термина agile. Единственный минус книги - плохая полиграфия, что не редкость для компьютерной литературы. Что удивительно, цена книги при таком качестве тоже не маленькая.
Книгу Алистера Коберна "Быстрая разработка программного обеспечения" можно приобрести в интернет-магазине www.rodina.by (www.rodina.by/book/info/go/6047.html).
Михаил ДУБАКОВ
Выбор методик разработки приложений становится задачей № 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 относятся:
- высокое качество. Взаимодействие пользователей с прототипами повышает функциональность проектов, выполненных в рамках быстрой разработки приложений. Такое программное обеспечение может больше отвечать потребностям заказчика (конечного пользователя), чем при использовании методик Agile/Waterfall.
- контроль рисков
— несмотря на то, что львиная часть
материалов о RAD фокусируется на скорости
и вовлечении
пользователей как ключевым особенностям модели, нельзя исключать третье важное преимущество
— снижение рисков
.
Интересно, но Боэм, создавший первую версию RAD, охарактеризовал спиральную модель как основанную на риске.
Использование rapid application development позволяет уже на ранних стадиях сосредоточиться на главных факторах риска и приспособиться к ним. - за единицу времени выполняется больше проектов в рамках бюджета
— так как RAD подразумевает инкрементную модель разработки
, шансы на критические ошибки, которые часто случаются в больших проектах по системе Waterfall, снижены.
Если в проектах по водопадной системе реализация проекта была возможна после шести и более месяцев анализа и разработки, то в RAD вся необходима информация открывается раньше, во время самого процесса создания приложения.
Инкрементная модель разработки — формат разработки программного обеспечения, которая предусматривает деление продукта на относительно независимые компоненты. Последние разрабатываются и вводятся в эксплуатацию по отдельности.
Не обошлось и без недостатков.
К минусам rapid application development можно отнести:
- риск «новизны» — для большинства IT-компаний RAD было новинкой, требующей переосмысления привычных методик работы. Сопротивление новому, необходимость изучения с нуля инструментов и техник приводят к ошибкам во время первых внедрений rapid application development.
- если пользователи не могут постоянно брать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно повлиять на конечный продукт — особенностью RAD является увеличенное взаимодействие пользователей и разработчиков в отличии от моделей Waterfall, в которых роль пользователей сводится к определению требований. Далее разработчики сами создают систему.
- уменьшенный контроль
— гибкость, адаптивность процесса как одно из преимуществ RAD в идеале означает возможность быстро адаптироваться как к проблемам, так и возможностям.
К сожалению, придётся отдать предпочтение чему-то одному — гибкости или контролю. В последнем случае методика быстрой разработки приложений не будет жизнеспособной. - скудный дизайн — фокусирование на прототипах в некоторых случаях приводит к методике «взлом и тестирование», по которой разработчики постоянно вносят мелкие изменения в отдельные элементы и игнорируют проблемы системной архитектуры.
- отсутствие масштабируемости — преимущественно RAD используется маленькими и средними проектными командами. Недостатки методологии rapid application development особенно ярко проявляются при использовании быстрой разработки приложений в работе над крупными проектами.
Методология RAD подойдет вашему проекту, если:
- для него важна скорость и простота разработки
- четко определены приоритетные направления разработки проекта
- разработать приложение нужно в сжатые сроки
- проект выполняется в условиях ограниченного бюджета
- главный критерий — интерфейс пользователя
- есть возможность разбить проект на функциональные компоненты.
Методология rapid application development не подойдёт вашему проекту, если:
- для него важно качество и контроль
- идет речь о создании крупномасштабного проекта — предполагаемое максимальное время разработки приложения составляет 60-90 дней, а при написании сотни тысяч строк программного кода соблюсти такое ограничение практически невозможно
- критически важным для реализации является высокий уровень планирования и жесткая дисциплина проектирования , строгое следование заранее разработанным протоколам и интерфейсам
- от приложения в определенной степени зависит безопасность людей.
Вердикт
Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.
Ключевые параметры, которыми оперирует RAD —
скорость и удобство программирования.
Методология станет отличным выбором для реализации небольших проектов с ограниченным бюджетом , разработать которые нужно в сжатые сроки . Для масштабных же систем, с высокими требованиями по контролю и планированию лучше выбрать другие модели разработки программного обеспечения.
Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - рентгеновский микротомограф , мелкий - автообновление службы Windows на AWS .
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии - мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры - центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
- Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
- Требуется ранний вывод продукта на рынок.
- Есть несколько рисковых фич или целей.
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель - разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
- отчёт о проделанной работе с момента последнего Scrum’a;
- список задач, которые сотрудник должен выполнить до следующего собрания;
- затруднения, возникшие в ходе работы.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия - работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй - появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале - в мыслях, затем - на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
О технологиях разработки:
Ещё раз про семь основных методологий разработки .
10 главных ошибок масштабирования систем .
8 принципов планирования разработки, упрощающих жизнь .
5 главных рисков при заказной разработке ПО .
Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.