5.1 Модель кодирования и устранения ошибок
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, например, лабораторные работы. Данная модель имеет следующий алгоритм:
Постановка задачи.
Выполнение.
Проверка результата.
При необходимости переход к первому пункту.
Модель является сильно устаревшей (характерна для 1960-1970 гг.). Преимуществ перед другими моделями практически не имеет, а недостатки очевидны.
5.2 Каскадная модель
Раньше, когда существовали только однородные информационные системы (ИС), каждое приложение представляло собой единое целое. Для их разработки применялся каскадный способ. В его основе лежит разбиение всей процесса разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Один из возможных вариантов структуры каскадной модели включает в себя шесть основных этапов, показанных на рисунке 5.1.
Рисунок 5.1 — Каскадная модель жизненного цикла ПО
При использовании каскадной модели, процесс разработки строго последовательно переходит от одного этапа к другому. Сначала полностью завершается этап «Определение требований», в результате чего получается список требований к ПО. Затем выполняется проектирование, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований (информационная модель). Далее программистами выполняется реализация полученного проекта. После того как реализация завершена, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. Затем происходит внедрение программного продукта и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
Каскадная модель подразумевает, что переход от одного этапа разработки к другому происходит только после полного и успешного завершения предыдущего этапа, и что переходов назад либо вперёд или перекрытия этапов не происходит.
Достоинства каскадной модели:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных, прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал вид, показанный на рисунке 5.2.
Рисунок 5.2 — Реальный вид каскадной модели жизненного цикла ПО
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
5.3 V-образная модель
Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы «V». Схема этой модели изображена на рисунке 5.3.
Эта модель является вариацией каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы «V», а задачи тестирования — вверх по правой стороне буквы «V». Внутри проводятся горизонтальные линии, показывающие, как результаты каждого этапа разработки влияют на развитие системы тестирования на каждом из этапов тестирования.
Рисунок 5.3 — V-образная модель
Эта модель, как и каскадная модель жизненного цикла ПО, также имеет свои достоинства и недостатки.
Преимущества:
Особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Этап модульного тестирования подтверждает правильность детализированного проектирования. Этапы интеграции и тестирования реализуют архитектурное проектирование или проектирование на высшем уровне. Этап тестирования системы подтверждает правильность выполнения этапа требований к продукту и его спецификации.
Предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта.
В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов.
Модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию.
Благодаря модели менеджеры проекта могут отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой.
Недостатки:
Модель не предусматривает работу с параллельными событиями.
В модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла.
Тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта.
В модель не входят действия, направленные на анализ рисков.
Некоторый результат можно посмотреть только при достижении низа буквы «V».