Модель хаоса

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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