Модель быстрой разработки приложения
Модель быстрой разработки приложений (Rapid Application Development – RAD) приведена на Рис. 8, где по трудоемкости и по времени разработки сравниваются два варианта жизненного цикла: обычный и для модели RAD, в которой существенную роль отведена пользовательскому сообществу.
Рис. 8. Модель быстрой разработки приложения
Как видим, в начале работы в этой модели значительно больше времени уделяется работе с пользователями и с заказчиком. Практически не тратится время на собственно разработку. Вместо разработки (кодирование и тестирование) поставлена фаза "построение системы", на которой, как правило, система собирается из уже готовых блоков COTS (Commercial Off The Shelf) с большой долей генерации рабочего кода из высокоуровневых описаний.
Таким образом, роль пользователей в модели RAP критична. Если в обычном ЖЦ большая часть работы – это программирование и тестирование, то в RAP благодаря кодогенерации и использованию COTS большая часть работы – планирование требований и разработка документации для пользователей, выполняемые при активном вовлечении будущих пользователей и заказчика.
Модель RAD нацелена на получение быстрого результата, хотя этот результат – работающее приложение – может оказаться громоздким как программный продукт, с завышенными требованиями по памяти и другим ресурсам. Зато приложение получается быстро и с учетом многих требований пользователей, которые сами принимают участие в их определении и оценивании.
V-образная модель
V-образная (V-shaped) модель (Рис. 9) так названа по форме латинской буквы V, поскольку расположение этапов ЖЦ напоминает эту букву. Сначала идет как бы «спуск», который начинается с разработки спецификаций и планирования проекта, после чего выполняется анализ требований и спецификаций, на котором предложенные требования анализируются и по-разному проверяются и изучаются. Если эти фазы пройдены успешно, то процесс переходит в фазу высокоуровневого проектирования системы на основе требований и спецификаций, которые к этому моменту уже проверены и утверждены, а затем на основе высокоуровневого проекта переходим к детальному или низкоуровневому проектированию, после чего к кодированию.
Рис. 9. V-образная модель
После фазы кодирования начинается «подъем». Фаза модульного тестирования проверяет корректность реализации закодированных модулей, их соответствие низкоуровневому проекту. Если здесь обнаруживаются ошибки в детальном проекте, то происходит возврат к фазе детального проектирования, где эти ошибки исправляются, после чего повторяется кодирование и модульное тестирование, пока все найденные отклонения от детального проекта или ошибки в нем не будут устранены. Таким образом, фазе модульного тестирования на «подъеме» соответствует фаза детального проектирования на «спуске».
Следующей фазой на «подъеме» является фаза сборки и интеграционного тестирования. Поскольку все модули, из которых собирается система, теперь уже оттестированы, то интеграционное тестирование на этой фазе проверяет корректность реализации интерфейсов между ними и соответствие сборки высокоуровневому проекту. Таким образом, парной фазой на «спуске» для сборки и тестирования является высокоуровневое проектирование. При обнаружении каких-либо несоответствий, процесс возвращается к фазе высокоуровневого проектирования, в высокоуровневый проект вносятся соответствующие исправления и процесс повторяется от этой фазы.
После успешного прохождения фазы сборки и тестирования «подъем» продолжается далее, на фазу системного тестирования. Поскольку до этого уже проверены функции модулей, их интерфейсы и соответствие реализации модулей и всей системы детальным и высокоуровневым проектам, то системное тестирование проверяет, насколько собранная система удовлетворяет исходным спецификациям. Параллельная для данной фазы деятельность на «спуске» – это анализ требований и спецификаций, как они были заданы заказчиком, а затем доработаны и согласованы с ним. Как и на предыдущих фазах «подъема», если обнаруживается расхождение со спецификациями, то определяются их причины и процесс возвращается на фазу анализа требований и спецификаций с внесением соответствующих изменений в спецификацию и повторением «спуска» и последующего «подъема».
Если, наконец, и фаза системного тестирования завершена успешно, то процесс переходит на заключительную фазу – запуск продукта в серийное производство и эксплуатацию данной системы, в результате чего с течением времени у заказчика могут возникнуть новые требования, подлежащие реализации в новом продукте или новой версии данного продукта. Тогда исходя из этих новых требований может быть начат новый программный проект.
Таким образом, V-образная модель подчеркивает важность тестирования продукта на соответствие документам, разработанным на всех предшествующих фазах, и является вариантом водопадной модели с усилением ее фазы верификации и валидации, но при этом напрямую не включает управление проектом и другие поддерживающие процессы.