Когда люди говорят про хаос в разработке, обычно имеют в виду плохо налаженные процессы и другие проблемы. Но есть "научная" хаотическая модель разработки, про неё даже в Википедии написано.

Описана она в статье Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1, и не все считывают иронию (инициалы автора L.B.S. — это сокращение от Laughing But Serious, по-русски что-то вроде "смех смехом, но серьезно". Raccoon, я думаю, понятно).

Вот что пишет этот енот: каждая строка кода соответствует всему проекту. Поэтому методика скорее не про хаос, а про фракталы, т.к. на каждом уровне повторяется один и тот же цикл работ. Впрочем, фракталы и хаос обычно связаны.

У нас есть 4 уровня: * вся система, * отдельный компонент архитектуры, * отдельная функция * отдельная строка кода.

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

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

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

Разработчик при этом находится между двух огней, они как раз видны на картинке: внешние требования к системе (требования пользователей и ограничения) сверху и возможности архитектуры/инструментов снизу. И вот где-то между ними, в попытке придумать решение с учетом и того, и другого, и находится большая часть работы.

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