Модель хаоса

Эта статья находится на начальном уровне проработки, в одной из её версий выборочно используется текст из источника, распространяемого под свободной лицензией
Материал из энциклопедии Руниверсалис

В компьютерных вычислениях модель хаоса — это способ разработки программного обеспечения. Её создатель Л.Б.С.Ракун отмечает, что такие модели управления проектами, как спиральная модель и каскадная модель, хотя и хороши в управлении расписаниями и персоналом, не обеспечивают методами устранения ошибок и решениями других технических задач, не помогают ни в управлении конечными сроками, ни в реагировании на запросы клиентов. Модель хаоса — это инструмент пытающийся помочь понять эти ограничения и восполнить пробелы.[1]

Жизненный цикл программного обеспечения

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

  • Проект в целом должен быть определен, реализован и интегрирован.
  • Системы должны быть определены, реализованы и интегрированы.
  • Модули должны быть определены, реализованы и интегрированы.
  • Функции должны быть определены, реализованы и интегрированы.
  • Строки кода должны быть определены, реализованы и интегрированы.

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

Стратегия хаоса

Стратегия хаоса — это стратегия разработки программного обеспечения, основанная на модели хаоса. Главное правило — это всегда решать наиболее важную задачу первой.

  • Задача — это незавершенная частная задача программирования.
  • Наиболее важная задача — это комбинация большого размера, срочности и устойчивости.
    • Задачи большого размера ценны для пользователей настолько, насколько они функциональны.
    • Срочные задачи своевременны настолько, насколько должны быть, иначе задерживается остальная работа.
    • Устойчивые задачи проверены и испытаны. Разработчики могут благополучно сфокусироваться на другом.
  • Решить означает привести в состояние стабильности.

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

Стратегия хаоса навеяна стратегией игры Го.

Связь с теорией Хаоса

Есть несколько состыковок с теорией Хаоса.

  • Модель хаоса может помочь объяснить, почему программное обеспечение имеет тенденцию быть настолько непредсказуемым.
  • Она объясняет почему такие высокоуровневые концепции, как архитектура ЭВМ не могут рассматриваться независимо от низкоуровневых строк кода.
  • Она снабжает уловкой для объяснения, что делать следующим, в условиях стратегии хаоса.

См. также

Примечания

Литература

  • Roger Pressman (1997) Software Engineering: A Practitioner's Approach 4th edition, pages 29–30, McGraw Hill.
  • Raccoon (1995) The Chaos Model and the Chaos Life Cycle, in ACM Software Engineering Notes, Volume 20, Number 1, Pages 55 to 66, January 1995, ACM Press.