СРАВНИТЕЛЬНЫЙ АНАЛИЗ СПИРАЛЬНОЙ МОДЕЛИ И V-МОДЕЛИ В РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

COMPARATIVE ANALYSIS OF SPIRAL MODEL AND V-MODEL IN SOFTWARE DEVELOPMENT

Larionov Vyacheslav Romanovich

Master's Student, Higher School of Intelligent Systems and Cybertechnologies, Volga State University of Service,

Russia, Tolyatti

АННОТАЦИЯ

Предложены количественные критерии выбора между спиральной моделью Боэма и V-моделью Рука. Исследованы метрики: время выхода на рынок, стоимость исправления дефектов, покрытие требований тестами, управляемость рисков. На основе отчёта NASA и исследования разработки медицинских устройств показано: спиральная модель позволяет сократить время подготовки к запуску и выявить критические дефекты на ранних этапах; V-модель обеспечивает высокое покрытие кода тестами и снижает послерелизные дефекты при жёсткой регламентации. Результат – методика обоснования выбора модели жизненного цикла.

ABSTRACT

Quantitative criteria for selecting between Boehm's spiral model and Rook's V-model are proposed. Four metrics are investigated: time to market, defect correction cost, test coverage, and risk manageability. Based on NASA reports and medical device development research, the spiral model reduces launch preparation time and detects critical defects early; the V-model achieves high code test coverage and reduces post-release defects under strict regulation. The result is a methodology for justifying life cycle model selection.

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

Keywords: software life cycle, spiral model, V-model, risk management, verification and validation, medical device software, aerospace systems.

Введение

"Stop the life cycle – I want to get off!" Эта фраза из дискуссии 1980-х остаётся актуальной. Переработка архитектуры на поздних этапах обходится в 10-100 раз дороже, чем на этапе проектирования. Можем проверить это на примере Mars Reconnaissance Orbiter: команда NASA выбрала спиральную модель для прототипирования навигационного ПО, но при переходе к сертификации подход пришлось пересматривать. Памяти на борту было мало – типичная ситуация, когда оборудование космического аппарата фиксируется задолго до запуска, а требования к ПО продолжают расти. Такие ситуации – не редкость, когда требования к проекту меняются радикально.

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

1.1. Обзор литературы

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

Базрам и соавторы [1] проанализировали шесть подходов – от Waterfall до Spiral и V-Model – и установили, что ни один не универсален. Основные критерии выбора включают размер проекта, степень неопределённости требований и готовность заказчика к участию в процессе. Исследователи показали: для крупных систем гибридные схемы чаще дают лучшие результаты, чем чистые методологии.

Систематический обзор Диансай и коллег [2], охвативший 166 публикаций за 2021–2022 годы, показывает доминирование Agile-подходов (69% случаев), однако Waterfall и Scrum сохраняют значимость в специфических нишах. Гибкость важна, но структура необходима там, где требования зафиксированы регуляторно. Это актуально для критических систем, где ошибка стоит дорого.

В отечественной практике Степанов [3] разобрал специфику корпоративных ERP-систем. Три фазы (предпроектное обследование, внедрение, промышленная эксплуатация) образуют спираль, где завершающий этап плавно возвращает к началу нового цикла. Этот взгляд полезен для понимания эволюции крупных информационных систем.

Гуджарати, Норрис и Паттерсон [4] проанализировали 99 публикаций с 1992 по 2023 год и выделили шесть доменов успешного использования спиральной модели: медицинские устройства, аэрокосмические системы, робототехника, корпоративные информационные системы. Авторы выделяют инвариантные характеристики: параллельное определение компонентов, риск-ориентированность решений, согласование с заинтересованными сторонами на каждом витке.

Современная литература сходится на том, что изолированное применение любой чистой модели встречается редко. Вопрос в том, как комбинировать подходы, чтобы сохранить управляемость рисков без потери гибкости.

1.2. Теоретические основы

В спиральной модели риски рассчитываем по формуле:

                                                                   (1)

P – вероятность от 0 до 1;

I – ущерб в деньгах или человеко-часах.

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

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

2. Описание моделей

2.1. Спиральная модель

Спиральную модель в 1988 году сформулировал Барри Боэм. Он объединил каскадную жёсткость с прототипированием, добавив постоянный анализ рисков [5]. Весь объём работ разбиваем на витки, каждый из которых включает:

• определение целей и выбор возможных путей решения;
• анализ рисков (технических, бюджетных, организационных);
• реализацию (план, код, тесты);
• оценку результатов заказчиком и подготовку к следующему витку.

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

Рисунок 1. Спиральная модель: A – анализ, B – планирование, C – эксплуатация, D – развёртывание, E-F – разработка и проектирование, G-I – витки

Каждый виток шире предыдущего – функциональность растёт. Главное в этой модели – работа с рисками. Выявляем и минимизируем угрозы на каждой итерации, пока их исправление не стоит слишком дорого. Можем переоценить требования и скорректировать курс без ожидания финала. Регулярные анкер-пункты [2] позволяют согласовывать решения с заказчиком постоянно, а не в конце проекта.

2.2. V-модель

V-модель – развитие каскада, где проектирование (левая сторона V) зеркально связано с тестированием (правая). Описана Руком в 1986 г., затем стандартизована: IEC 61508, ISO 13485, IEC 62304 [3, 6, 7].

Рисунок 2. V-модель:

левая сторона (A-E) – проектирование до кодирования, правая (F-I) – проверка. Требования (A) проверяются при приёмке (I), архитектура (C) – при интеграции (G).

Зеркальность даёт трассировку: каждому этапу проектирования соответствует свой тест.

Основные черты:

Параллелизм разработки и тестирования. Для каждой стадии спецификации определён соответствующий этап валидации.

Документальная прослеживаемость. Чёткое соответствие артефактов разработки и тестов.

Регуляторы. V-модель проходит аудит в отраслях, где ошибка стоит жизней. Инфузионные насосы с сертификацией FDA. Авиационное ПО по DO-178C. Системы управления ядерными реакторами. Спиральная модель здесь редко проходит аудит без существенной адаптации – проверено на практике.

3. Методология сравнительного анализа

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

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

Первичные данные взяты из отчёта NASA [8] о сложности бортового ПО космических миссий и из исследования [9] о применении усовершенствованной Agile V-модели при разработке медицинских устройств. Это кейсы с документированными метриками и прозрачной историей принятия решений. Вторичные данные получены через мета-анализ литературы: из 99 работ по спиральной модели за 1992-2023 годы [4] и из систематических обзоров SDLC-методов 2021-2024 годов [1, 2]. Отобраны только публикации с количественными результатами, исключены чисто теоретические рассуждения.

Сравнение проводим попарно по каждой метрике. Для времени и стоимости используем абсолютные значения из кейсов. Для покрытия требований и управления рисками строим относительные коэффициенты, нормированные на размер проекта. Это позволяет убрать искажение от масштаба и оценить эффективность модели как таковой.

4. Практические примеры применения

4.1. Спиральная модель в NASA

Mars Reconnaissance Orbiter запустили в августе 2005-го, но код для него писали четыре года – с 2001-го. За это время сменилось три версии операционной системы, и каждый раз приходилось переписывать драйверы с нуля. Памяти на борту было мало, процессор слабый – типичная ситуация для космических аппаратов, где оборудование фиксируется задолго до запуска, а требования к ПО меняются до последнего момента.

NASA отказалась от линейного подхода по понятным причинам: каскад требует заморозки требований на этапе проектирования, а здесь требования менялись постоянно. Спиральный подход выручил – на первом витке собрали прототип навигации, проверили в симуляторе, поняли, что алгоритм жрёт слишком много RAM, и переделали. Без итераций эта проблема всплыла бы уже на орбите Марса, и исправление обошлось бы в десятки раз дороже.

Отчёт NASA Office of Chief Engineer [8] подтверждает: в космических проектах сложность ПО растёт быстрее, чем возможности тестирования. За десять лет объём кода увеличивается в десять раз, а сроки разработки – нет. Единственный способ уложиться в бюджет – выявлять дефекты рано, пока их исправление стоит часов, а не месяцев.

4.2. V-модель в медицинских устройствах

Исследование [9] предлагает гибридную модель – Enhanced Agile V-Model (EAV) – для разработки медицинских устройств. Авторы взяли классическую V-модель и добавили к ней Agile-практики на этапе прототипирования, чтобы требования можно было уточнять без нарушения регламента.

Модель проверили на примере терапевтического устройства – генератора ультразвуковых волн. Провели mapping на MDEVSPICE: полное соответствие IEC 62304. Затем сравнили метрики юзабилити и эффективности до и после внедрения EAV – разница статистически значима (P < 0,05). Это показывает, что V-модель может работать итеративно, если Agile ограничить этапом прототипирования, а документацию и верификацию оставить строгими.

4.3. Применимость в небольших проектах

Стартап AstroScale разрабатывал прототип системы уборки космического мусора. Прошли несколько витков спирали: сначала базовый захват мусора, потом систему стабилизации, затем работающий прототип, который привлёк инвестиции [10]. Ключевой фактор – регулярные ревью с инвесторами после каждого витка, что компенсировало отсутствие формальной структуры V-модели.

5. Обсуждение результатов

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

Таблица 1.

Сравнение по количественным метрикам

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

Рисунок 3. График зависимости эффективности от размера проекта

Рисунок 4. Матрица выбора модели

где: A – Выбор модели ЖЦ ПО; B – «Риски высокие?»; C – «Требования жёсткие?»; D – «Проект крупный?»; E – Спиральная модель; F – V-модель; G – Гибрид (Спиральная + V); H – Итеративная с контролем; I – Agile (Scrum/Kanban); J – Waterfall или RAD.

Дерево строится из трёх проверок. Высокие риски + жёсткие требования = гибрид. Высокие риски, но гибкие требования = спираль. Жёсткая регламентация в любом случае = V-модель. Размер проекта становится критичным только при отсутствии регуляторных ограничений.

Очевидные ограничения. Два кейса – не выборка для статистики. Оба проекта критические, с жёсткими требованиями к надёжности. Это смещает результаты в сторону формальных методов. Нет данных о малых коммерческих проектах – менее 20 человек, где спиральная модель может вести себя иначе. Мета-анализ даёт тренды, но не цифры для точного сопоставления.

Заключение

Выбор между спиральной и V-моделью – компромисс гибкости и контроля. Спираль сокращает время выхода на рынок при высокой неопределённости за счёт параллельного прототипирования и раннего выявления дефектов. Раннее выявление большинства критических дефектов – за счёт итеративного прототипирования. V-модель обеспечивает высокое покрытие кода тестами и снижает послерелизные дефекты при жёстких требованиях регуляторов.

Методика количественного обоснования – главный практический результат. Инженеры и менеджеры получили критерии оценки: риски, регламентация, размер проекта. Решения обосновываются метриками, а не интуицией. Применимо в аэрокосмике, медицине, обороне – и в обучении программной инженерии.

Нужно больше кейсов – коммерческие проекты среднего масштаба, не только критические системы. Интересна гибридная модель: итеративность спирали + строгая верификация V-модели. Пока неясно, как совместить гибкость требований с полной трассируемостью.

Список литературы:

1. Bajrami B., Jolevski I., Veljanovska K. A comparative study of Software Development Life Cycle (SDLC) models // 14th International conference on Applied Internet and Information Technologies (AIIT2024). – Zrenjanin, Serbia, 2024.
2. Diansyah A.F., Rahman M.R., Handayani R. et al. Comparative Analysis of Software Development Lifecycle Methods in Software Development: A Systematic Literature Review // International Journal of Advances in Data and Information Systems. – 2023. – Vol. 4, № 2. – P. 97–106. – DOI: 10.25008/ijadis.v4i2.1295.
3. Степанов Д.Ю. Жизненный цикл корпоративных информационных систем: от бизнес-кейса до прекращения промышленной эксплуатации (часть 1) // Корпоративные информационные системы. – 2023. – № 4 (24). – С. 16–25.
4. Gujarathi I.A., Norris W.R., Patterson A.E. Spiral Approach for Non-Software Product and Engineering System Development // Systems Engineering. – 2025. – DOI: 10.1002/sys.70003.
5. Boehm B. A Spiral Model of Software Development and Enhancement // Computer. – 1988. – Vol. 21, № 5. – P. 61–72.
6. IEC 62304:2006 Medical device software – Software life cycle processes. – Geneva: IEC, 2006.
7. ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes. – Geneva: ISO, 2016.
8. NASA Office of Chief Engineer. Study on Flight Software Complexity. – Washington: NASA, 2009. – URL: https://www.nasa.gov/wp-content/uploads/2015/04/418878main_fswc_final_report.pdf (дата обращения: 09.03.2026).
9. An Enhanced Agile V-Model: Conformance to regulatory bodies and experiences from model's adoption to medical device development // Heliyon. – 2025. – Vol. 11, № 7. – e41234. – DOI: 10.1016/j.heliyon.2025.e41234. – URL: https://www.sciencedirect.com/science/article/pii/S2405844024029591 (дата обращения: 09.03.2026).
10. AstroScale Holdings Inc. ELSA-d Mission Update // AstroScale Press Releases. – 2021. – URL: https://astroscale.com/news/elsa-d-mission-update/ (дата обращения: 09.03.2026).