Методология разработки программного обеспечения — это система построения плана работы над созданием программного продукта, определяющего порядок выполнения стадий разработки, методы оценки и контроля. Приверженность какой-либо методологии разработки позволяет грамотно структурировать работу, а также на начальном этапе производить предварительную оценку сроков разработки и ее стоимости.
На данный момент существует большое множество различных методологий, каждая из которых может оказаться наилучшей для какого-либо конкретного программного продукта. Сейчас методологии разработки программного обеспечения принято делить на классические и гибкие. В основе классических моделей лежит строгая последовательность этапов жизненного цикла разработки программного обеспечения, что дает возможность оценить срок разработки и ее стоимость, однако требует наличия конечных требований к продукту еще до начала разработки. Гибкие методологии разбивают цикл разработки на множество коротких итераций, что дает возможность корректировать требования к продукту постоянно и не требует на это больших финансовых затрат.
Самой простой и самой распространенной классической методологией разработки программного обеспечения является каскадная (или «водопадная») модель. Ее суть заключается в том, что все стадии жизненного цикла разработки программного обеспечения следуют последовательно: начинается процесс с разработки требований к программному обеспечению, далее следует проектирование программного продукта, затем идет непосредственно разработка, далее — тестирование, а последней ступенью является эксплуатация и поддержка (рис. 1). Некоторые из вышеназванных ступеней могут разбиваться на более мелкие ступени.
Рис. 1. Каскадная методология разработки программного обеспечения
В каскадной модели ключевым фактором является строгая последовательность выполнения стадий. Сначала определяются требования к разрабатываемому программному продукту. Только когда требования полностью определены, начинается этап проектирования продукта. На этапе проектирования создается документация, подробно описывающая план разработки приложения на основе ранее разработанных требований к данному продукту. Когда этап проектирования завершится и вся документация для программистов будет готова, программный продукт переходит в стадию разработки. На этой стадии происходит непосредственно реализация ранее спроектированного функционала или частей функционала, которые на этом же этапе интегрируются в общую систему.
Подготовка к тестированию, включающая в себя составление тестовой документации, может начинаться и до окончания стадии разработки, поскольку требования к приложению, на основе которых эта документация составляется, уже разработаны, однако в фазу непосредственного тестирования программный продукт вступает все равно после окончания стадии разработки. На этапе тестирования проверяется весь разработанный функционал программы, находятся всевозможные дефекты, чтобы свести к минимуму возможность возникновения ошибок после вывода программного продукта в эксплуатацию. Только после того, как команда тестирования принимает решение о нецелесообразности дальнейшего тестирования, программный продукт переходит на стадию выпуска в эксплуатацию и дальнейшей поддержки.
V-образная модель разработки является модернизацией каскадной модели. Ее смысл заключаются в установке соответствия определенного уровня тестирования каждому этапу проектировки. Тестирование (в первую очередь создание тестовой документации) в такой модели начинается еще на этапе написания требований.
Для каждого уровня тестирования создается отдельный план тестирования. Создание таких планов для каждого уровня определяет критерии перехода к каждому следующему уровню проектирования.
На визуальном представлении V-образной модели (рис. 2) стадии проектирования расположены в нисходящей последовательности в левой части импровизированной буквы V, внизу находится стадия кодирования, а правой части буквы находится восходящая последовательность тестирования.
V-образная методология реализует нисходящий подход к проектированию приложения: сначала определяются общие требования к продукту, далее производится проектирование архитектуры на высшем уровне, после чего уже производится детальное проектирование. После окончания проектирование производится кодирование спроектированных функций. По окончании стадии кодирования начинается восходящий процесс тестирования. В качестве первого этапа тестирования производится модульное тестирование, то есть тестирование каждого из разработанных на стадии детального проектирования модулей в отдельности. Когда все модули протестированы, следующим этапом следует интеграционное тестирование — тестирования правильности взаимодействия и интеграции модулей друг с другом. Требования к интеграции и, соответственно, тестовая документация для этого уровня были разработаны на стадии проектирования архитектуры на высшем уровне. Далее следует системное и приемочное тестирование, которое позволяет убедиться в правильности работы всего приложения и соответствие его исходным требованиям к программному продукту, определенных еще на этапе разработки требований.
Рис. 2. V-образная модель разработки программного обеспечения
Среди общих достоинств каскадной и V-образной моделей разработки выделяют простоту планирования сроков и расходов на разработку. Среди недостатков — невозможность внесения изменений в середине процесса разработки и общая высокая стоимость, а также большая продолжительность процесса.
Еще одним важным недостатком каскадной модели является тот факт, что тестирование начинается только после завершения стадий проектирования и кодирования. Этот недостаток приобретает большой вес в контексте того, что тестирование является наиболее дорогим и продолжительным этапом разработки среди стадий, осуществляемых до выхода программного продукта в эксплуатацию. В V-образной модели этот недостаток частично компенсируется тем, что планирование тестирования происходит одновременно с проектированием приложения, что значительно сокращает время, затрачиваемое на основных стадиях тестирования, а также защищает приложение от дефектов спецификации, что значительно сокращает стоимость их устранения в контексте того, что стоимость исправления ошибки сильно зависит от стадии ее обнаружения.
В свою очередь, V-образная модель требует более высокого уровня подготовки сотрудников. Еще одним недостатком относительно каскадной модели является стоимость внесения изменений в ходе разработки. Несмотря на то, что стоимость внесения изменений является общим недостатком классических методологий разработки, в V-образной модели она приобретает дополнительный вес за счет того, что на ранних стадиях разработки осуществляется гораздо больший объем работы, и внесенные изменения будут требовать не только внесения изменений в программу, но и внесения изменений в тестовую документацию.
Подводя итог проведенного анализа, можно прийти к выводу, что V-образная методология требует больших ресурсов, однако дает значительное преимущество на различных стадиях тестирования, что в целом сказывается на качестве тестирования и полученного программного продукта. V-образная методология имеет преимущества в проектах, когда требования к программному продукту жестко установлены, риск их изменений минимален. V-образная методология делает упор на максимальное качество тестирования продукта на каждой стадии, детальную разработку планов тестирования, поэтому наиболее весомым аспектом, указывающим на то, что среди существующих классических методологий оптимальной окажется V-образная методология разработки, является стоимость ошибки, найденной после выхода программного продукта в эксплуатацию. Например, такая методология может использоваться для программных продуктов в медицинской и космической отраслях.
