Сравнительный анализ каскадной и V-образной методологий разработки программного обеспечения | Статья в журнале «Молодой ученый»

Отправьте статью сегодня! Журнал выйдет 18 июля, печатный экземпляр отправим 22 июля.

Опубликовать статью в журнале

Автор:

Рубрика: Информационные технологии

Опубликовано в Молодой учёный №22 (312) май 2020 г.

Дата публикации: 01.06.2020

Статья просмотрена: 10 раз

Библиографическое описание:

Филатов, В. А. Сравнительный анализ каскадной и V-образной методологий разработки программного обеспечения / В. А. Филатов. — Текст : непосредственный // Молодой ученый. — 2020. — № 22 (312). — С. 48-51. — URL: https://moluch.ru/archive/312/70923/ (дата обращения: 10.07.2020).



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

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

Самой простой и самой распространенной классической методологией разработки программного обеспечения является каскадная (или «водопадная») модель. Ее суть заключается в том, что все стадии жизненного цикла разработки программного обеспечения следуют последовательно: начинается процесс с разработки требований к программному обеспечению, далее следует проектирование программного продукта, затем идет непосредственно разработка, далее — тестирование, а последней ступенью является эксплуатация и поддержка (рис. 1). Некоторые из вышеназванных ступеней могут разбиваться на более мелкие ступени.

Рис. 1. Каскадная методология разработки программного обеспечения

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

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

V-образная модель разработки является модернизацией каскадной модели. Ее смысл заключаются в установке соответствия определенного уровня тестирования каждому этапу проектировки. Тестирование (в первую очередь создание тестовой документации) в такой модели начинается еще на этапе написания требований.

Для каждого уровня тестирования создается отдельный план тестирования. Создание таких планов для каждого уровня определяет критерии перехода к каждому следующему уровню проектирования.

На визуальном представлении V-образной модели (рис. 2) стадии проектирования расположены в нисходящей последовательности в левой части импровизированной буквы V, внизу находится стадия кодирования, а правой части буквы находится восходящая последовательность тестирования.

V-образная методология реализует нисходящий подход к проектированию приложения: сначала определяются общие требования к продукту, далее производится проектирование архитектуры на высшем уровне, после чего уже производится детальное проектирование. После окончания проектирование производится кодирование спроектированных функций. По окончании стадии кодирования начинается восходящий процесс тестирования. В качестве первого этапа тестирования производится модульное тестирование, то есть тестирование каждого из разработанных на стадии детального проектирования модулей в отдельности. Когда все модули протестированы, следующим этапом следует интеграционное тестирование — тестирования правильности взаимодействия и интеграции модулей друг с другом. Требования к интеграции и, соответственно, тестовая документация для этого уровня были разработаны на стадии проектирования архитектуры на высшем уровне. Далее следует системное и приемочное тестирование, которое позволяет убедиться в правильности работы всего приложения и соответствие его исходным требованиям к программному продукту, определенных еще на этапе разработки требований.

Рис. 2. V-образная модель разработки программного обеспечения

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

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

В свою очередь, V-образная модель требует более высокого уровня подготовки сотрудников. Еще одним недостатком относительно каскадной модели является стоимость внесения изменений в ходе разработки. Несмотря на то, что стоимость внесения изменений является общим недостатком классических методологий разработки, в V-образной модели она приобретает дополнительный вес за счет того, что на ранних стадиях разработки осуществляется гораздо больший объем работы, и внесенные изменения будут требовать не только внесения изменений в программу, но и внесения изменений в тестовую документацию.

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

Основные термины (генерируются автоматически): программный продукт, программное обеспечение, v-образная методология, каскадная модель, тестовая документация, методология разработки, V-образной модель, требование, высший уровень, v-образная модель разработки.


Похожие статьи

Сравнение процессов разработки программного обеспечения...

Цель данной статьи — сравнить общий набор процессов управления проектами, как это определено в своде знаний Management Body of Knowledge (PMBOK) и в методологиях гибкой разработки Agile.

Определение условий для применения каскадной и гибкой...

Ключевые слова: управление проектами, каскадная модель, гибкая модель, Waterfall, Agile. В настоящее время вопрос сравнения каскадной и гибкой моделей управления проектами является достаточно актуальным, т. к. успешный проект от неудачного отличает грамотно...

Разработка объектно-ориентированной модели процесса...

Разработка объектно-ориентированной модели процесса разработки программного проекта АСУ ТП.

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

Технология конструирования программного обеспечения

Каскадная модель модель, при которой все разработки ведутся последующий этап после полного предыдущего.

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

Разработка концептуально-абстрактной модели.

Разработка физической модели и программного обеспечения ИС.

Наиболее критичным этапом создания ИС является этап разработки концептуальной модели. До появления формализованных методов проектирования процесс разработки часто основывался на...

Оценка качества при разработке программных продуктов для...

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

ASPICE описывает жизненный цикл программных продуктов с тремя различными областями процесса

Рис. 2. Модель уровня оценки процессов согласно ASPICE.

Методология объектно-ориентированного программирования на...

В современной IT отрасли стандартом разработки подавляющего большинства промышленных проектов прикладного уровня стало использование модели объектно-ориентированного проектирования (ООП).

Применение концепции модельно-ориентированного...

Иными словами, сформировать модель, которая была бы интуитивно понятна всем.

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

Принципы МОП существенно отличаются от традиционной методологии проектирования.

Статистические методы в моделировании надежности...

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

Похожие статьи

Сравнение процессов разработки программного обеспечения...

Цель данной статьи — сравнить общий набор процессов управления проектами, как это определено в своде знаний Management Body of Knowledge (PMBOK) и в методологиях гибкой разработки Agile.

Определение условий для применения каскадной и гибкой...

Ключевые слова: управление проектами, каскадная модель, гибкая модель, Waterfall, Agile. В настоящее время вопрос сравнения каскадной и гибкой моделей управления проектами является достаточно актуальным, т. к. успешный проект от неудачного отличает грамотно...

Разработка объектно-ориентированной модели процесса...

Разработка объектно-ориентированной модели процесса разработки программного проекта АСУ ТП.

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

Технология конструирования программного обеспечения

Каскадная модель модель, при которой все разработки ведутся последующий этап после полного предыдущего.

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

Разработка концептуально-абстрактной модели.

Разработка физической модели и программного обеспечения ИС.

Наиболее критичным этапом создания ИС является этап разработки концептуальной модели. До появления формализованных методов проектирования процесс разработки часто основывался на...

Оценка качества при разработке программных продуктов для...

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

ASPICE описывает жизненный цикл программных продуктов с тремя различными областями процесса

Рис. 2. Модель уровня оценки процессов согласно ASPICE.

Методология объектно-ориентированного программирования на...

В современной IT отрасли стандартом разработки подавляющего большинства промышленных проектов прикладного уровня стало использование модели объектно-ориентированного проектирования (ООП).

Применение концепции модельно-ориентированного...

Иными словами, сформировать модель, которая была бы интуитивно понятна всем.

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

Принципы МОП существенно отличаются от традиционной методологии проектирования.

Статистические методы в моделировании надежности...

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

Задать вопрос