Модель хаоса

В вычислительной технике модель хаоса представляет собой структуру разработки программного обеспечения . Ее создатель, использовавший псевдоним LBS Raccoon, ^[1] отметил, что модели управления проектами, такие как спиральная модель и каскадная модель , хотя и хороши для управления графиками и персоналом, не предоставляют методов исправления ошибок или решения других технических проблем. В то же время методологии программирования, хотя и эффективны для исправления ошибок и решения технических проблем, не помогают в управлении сроками или реагировании на запросы клиентов. Структура пытается преодолеть этот разрыв. Теория хаоса использовалась в качестве инструмента, помогающего понять эти проблемы. ^[2]

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

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

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

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

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

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

Стратегия хаоса была вдохновлена ​​стратегией Го . ^{[ необходима цитата ]}

Существует несколько связей с теорией хаоса .

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

• V-модель

• Роджер Прессман (1997) Программная инженерия: подход практика, 4-е издание, страницы 29–30, McGraw Hill.
• Raccoon (1995) Модель хаоса и жизненный цикл хаоса, в ACM Software Engineering Notes, том 20, номер 1, страницы 55–66, январь 1995 г., ACM Press.