Модель хаоса

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

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