Спиральный фрактал разработки ПО

В теории программной инженерии есть разные модели жизненного цикла ПО. Обычно их делят на жёсткие и гибкие. Основные жёсткие — водопадная, водопадная с промежуточным контролем (водоворот), V-образная. Основные гибкие — инкрементальная, итеративная, итеративно-инкрементальная, спиральная. Гибкие модели более эффективны при должном уровне подготовки персонала и зрелости процессов разработки. Однако, этапы тестирования в них идут в конце циклов разработки: после добавления инкремента, в конце итерации, после создания прототипа. В современной эффективной практике разработки эти модели в чистом виде используются мало. Проверки всё чаще внедряют после каждой активности создания продукта, снижая риск появления и размножения багов. Это называется тестированием со сдвигом влево (shift-left testing) или непрерывным тестированием. Такая практика соответствует принципу раннего тестирования, соблюдение которого позволяет минимизировать затраты ресурсов на исправление дефектов ПО в конце разработки.

В гибких методологиях вроде Scrum и инженерных практиках DevOps / DevSecOps часто используют итеративно-инкрементальную модель в сочетании с непрерывным тестированием. Применяется концепция вложенных Agile циклов — это архитектурный паттерн, описывающий разработку ПО как систему из множества взаимосвязанных петель обратной связи (feedback loops), которые вложены друг в друга.  Для упорядочения разработки и удобства используют CI/CD конвейеры (pipelines). Для автоматизации рутины всё больше используют ИИ-агентов, работающих в Agile петлях разных уровней. Попробуем описать модель жизненного цикла ПО, включающую эти прогрессивные практики.

Описание SFM модели

Представим спираль в виде цепочки инкрементально-итеративных циклов разработки, нарастающей от центра (ядра) к периферии. Добавление звеньев итерации в ней происходит с уменьшением важности (критичности) доработок. Изредка, при исправлении некоторых дефектов или избыточном функционале звенья спирали могут пойти ближе к центру, с удалением лишнего кода. Таких итерационных спиралей может быть много, т. к. доработки проводятся похожим образом на разных уровнях и стадиях разрабатываемого продукта. Спирали более высокого уровня порождают множества вложенных спиралей нижних уровней. Получается спиральный фрактал. Одно звено каждой спирали по сути является классическим циклом PDCA (Plan-Do-Check-Act), развёрнутым по времени. Вход в спиральные узлы фрактала происходит в центре, выход — с их периферии, при достижении принятых уровней качества (критерии Definition of Done). Нарастание спиралей разработки происходит от идеи продукта к его детальной реализации. Можно выделить 5 уровней спирального фрактала разработки — см. таблицу ниже.

Уровни спирального фрактала разработки ПО

Разберём эти уровни подробнее:

1. Разработка начинается с идеи и формулирования концепта продукта. На этом уровне тестирование не проводится (нет ожидаемого результата), и узел фрактала один. Спираль узла состоит из PDCA звеньев: подготовка → генерация идей/концепта → критика → отправка на уточнение/принятие. Критика может проводиться независимым экспертом.

2. После принятия концепта продукта ответвляется спираль требований: сочиняются требования, пишется техническое задание, проводится анализ требований группой разработки и их тестирование (на полноту, непротиворечивость, однозначность, тестируемость). По достижении принятого уровня качества (с нарастанием ≥1 PDCA звеньев) спираль фиксируется и порождает спирали 3-го уровня. При этом формируются критерии приёмки. После выполнения разработки на нижних уровнях происходит возврат к спирали требований, и проводится приёмочное тестирование. Если оно успешно проходит, разработка версии ПО завершается (выход на 1-й уровень). Если нет — спираль требований наращивается, и отрастают новые версии спиралей-потомков с устранением замечаний и добавлением функционала. Спиралей требований (видов ПО) может быть несколько — если в процессе разработки появляются другие наборы требований в рамках того же концепта (ядра). 

3. По готовности набора требований системный архитектор проводит анализ контекста, выявляет ограничения, проектирует верхний уровень системы, инфраструктуру и конвейеры разработки. Дизайнер проектирует GUI, набрасывает макеты. Артефакты архитектора и дизайнера проходят независимую проверку со стороны команды (ревью, статическое тестирование QA) и стейкхолдеров. Формируются замечания для доработки с отпочкованием следующего PDCA звена спирали. При достижении приемлемого качества происходит утверждение архитектуры (ADR) и общего дизайна ПО. Это порождает спирали 4-го уровня. После выполнения разработки на нижних уровнях происходит возврат к спирали 3-го уровня. Проводится интеграционное и системное (e2e) тестирование. Могут проводиться не функциональные тесты (производительности, безопасности, GUI и др.). Если тесты проходят, разработка подверсии ПО завершается (выход на 2-й уровень). Если нет — спираль 3-го уровня наращивается, и отрастают новые подверсии спиралей-потомков. Вариантов архитектуры и дизайна ПО по одному ТЗ может быть несколько. Поэтому спиралей 3-го уровня часто бывает больше одной — обычно когда разработка переходит на новый стек технологий.

4. По готовности архитектуры и дизайна проектируются компоненты системы — модули, фичи, микросервисы. Уточняется GUI. Затем проводится статическое тестирование логики, интерфейсов и макетов компонентов по спецификациям. При достижении приемлемого качества архитектуры и дизайна компонента производится их утверждение. Это порождает спирали 5-го уровня. После наполнения кодом компонента происходит возврат на 4-й уровень, к его спирали. Проводится code review и компонентное тестирование. Если ревью и тесты прошли, разработка компонента ПО завершается (фича заливается в общую ветку). Если нет — спираль компонента наращивается, и отрастают новые подверсии юнитов. Компонентов ПО обычно много. Переход к тестированию на 3-м уровне может происходить как после реализации всех компонент, так и их части (инкремента).

5. По готовности структуры и макета компонента проводится его кодирование — наполнение функциями, методами и др. юнитами. Все сложные и критичные юниты покрываются модульными тестами, которые прогоняются после написания юнитов. Если тест проходит, юнит добавляется к коду компонента. Если нет — юнит корректируется (присоединяется звено PDCA). Формируется большое количество микроспиралей кодирования.

Правила от заторов

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

1. Малый квант разработки (анти-багаж): Разработчику запрещено копить код. Написал логический кусок на 30 строк — пуш в узел компонента. В мелких спиралях легче исправляются ошибки.

2. «Живой» тестовый стенд: Тестировщик не ждет пятницы, а проверяет фичу прямо в процессе её создания на динамическом стенде. Его задача — не «поймать» разработчика на ошибке в конце, а помочь ему завершить спираль как можно быстрее.

3. Автоматический откат: Если узел на 4-м или 5-м уровне ломает автоматические проверки (quality gates), конвейер блокирует дальнейшее продвижение кода и «кричит» в рабочий чат. Починка конвейера — наивысший приоритет для разработчиков (энергия направляется на стабилизацию спирального фрактала).

4. Автоматизированный регресс: Регрессионные тесты на системном уровне автоматизируются. После исправления багов и мелких доработок прогоняются вручную только smoke и sanity тесты.

5. Заказчик «в доску»: Налажена коммуникация, процессы передачи требований/замечаний и приёмки с компетентными представителями заказчика.

Визуализация

Вариантов спиральных фракталов разработки может быть много. Их вид зависит от специфики компании, персонала, разрабатываемого продукта и внешних условий. Спиральные фракталы можно визуализировать — на плоскости или в пространстве. В первом приближении, для визуализации на плоскости годится ус множества Мандельброта (см. рис. 1). При его раскручивании укрупняются и уточняются вложенные спирали, формируя последовательность похожих структур разработки (версий ПО). На рисунке показаны два архитектурных типа ПО (A и B), с последовательно идущими версиями (начиная с X). Версии разделены PDCA циклами доработки требований. В каждую спираль архитектуры вложены спирали компонентов и модулей. Изображение неточно, но суть передаёт.

^{*Исходное изображение: Wolfgang Beyer, создано в программе Ultra Fractal 3 (собственная работа, CC BY-SA 3.0).}

Природные аналоги

В природе существует множество фрактальных объектов со вложенными вихрями/спиралями.

Вот ряд примеров:

1. Дробление вихрей в газах и жидкостях. Наблюдается в циклонах, смерчах, торнадо, водоворотах, рингах и проч. Каскад энергии Ричардсона-Колмогорова описывает последовательную передачу кинетической энергии от крупных вихрей к всё меньшим до тех пор, пока вязкие эффекты не приведут к её диссипации. Явление возникает, когда есть внешнее воздействие, и силы инерции в потоке значительно превосходят силы вязкого трения.

2. Дробление космических вихрей. В звёздном (солнечном) ветре потоки плазмы турбулентные. Крупные возмущения в них дробятся на всё более мелкие магнитные и плотностные структуры. Внутри межзвёздных туманностей (например, в Столпах Творения) гравитация и взрывы сверхновых порождают колоссальные вихри межзвёздного газа. Они дробятся миллиарды лет, способствуя перемешиванию вещества и запуская процессы рождения новых звёзд. 

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

4. Спирально-фрактальные наноструктуры. Некоторые описаны здесь.

5. Сложный спиральный филотаксис в ботанике. В цветной капусте, брокколи и их гибриде (романеско) имеется множество вложенных конических спиралей соцветий и бутонов (до 5 уровней вложенности у романеско). Похожие структуры наблюдаются у сложных зонтичных и астровых цветков: борщевик, подсолнух и др. (до 2-х уровней вложенности). У листьев папоротника в процессе раскрытия (вайи) есть 3 уровня вложенности.

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

7. В анатомии наблюдаются на разных уровнях: в хроматине, жгутиках сперматозоидов, сердце, крупных артериях, улитке внутреннего уха, нейронах ГМ.

8. В психологии это спиральная модель сознания Клэра Грейвза, фрактальная рекурсия процесса извлечения воспоминаний.

Изображения некоторых природных структур с пояснением их математики (золотое сечение, числа Фиббоначи) можно посмотреть, например, здесь. Ниже спирально-фрактальная модель разработки проиллюстрирована на примере кочана капусты романеско.

^{**Исходное фото здесь: beart.org.uk.}

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

Заключение

Представленная спирально-фрактальная модель разработки ПО (SFM - Spiral Fractal Model) является формализацией концепции вложенных циклов Agile и описывает эффективные практики непрерывной эволюции программных систем (software evolution). Концепция эволюции является основой современной программной инженерии. Согласно ей крупное программное обеспечение никогда не может быть окончательно «завершено». Чтобы оставаться полезной и работоспособной, система должна постоянно и непрерывно изменяться, адаптируясь к новым требованиям пользователей, технологиям, бизнес-моделям и угрозам безопасности. Концепция эволюции стала развитием законов Лемана (Lehman's Laws) и лежит в основе современных подходов автоматизации (DevOps / DevSecOps).

SFM может применяться не только для производства ПО, но и другой сложной продукции. При наличии подготовленного персонала, отлаженных процессах в компании и благоприятных условиях труда эта модель может быть оптимальной.

P.S. Статья написана в соавторстве с Gemini. Благодарен разработчикам.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.