Модель хаоса
В вычислительной технике модель хаоса представляет собой структуру разработки программного обеспечения . Его создатель, использовавший псевдоним LBS Raccoon, [1] отметил, что модели управления проектами, такие как спиральная модель и водопадная модель , хотя и хороши для управления графиками и персоналом, не предоставляют методов исправления ошибок или решения других технических проблем. В то же время методологии программирования, хотя и эффективны при исправлении ошибок и решении технических проблем, не помогают управлять сроками или реагировать на запросы клиентов. Структура пытается восполнить этот пробел. Теория хаоса использовалась как инструмент, помогающий понять эти проблемы. [2]
Жизненный цикл разработки программного обеспечения
[ редактировать ]Модель хаоса отмечает, что фазы жизненного цикла применимы ко всем уровням проектов, от всего проекта до отдельных строк кода.
- Весь проект должен быть определен, реализован и интегрирован.
- Системы должны быть определены, внедрены и интегрированы.
- Модули должны быть определены, реализованы и интегрированы.
- Функции должны быть определены, реализованы и интегрированы.
- Строки кода определены, реализованы и интегрированы.
Одним из важных изменений в перспективе является то, можно ли рассматривать проекты как целые единицы или их следует рассматривать по частям. Никто не пишет десятки тысяч строк кода за один присест. Они пишут небольшие фрагменты, по одной строке за раз, проверяя, работают ли эти небольшие фрагменты. Затем они накапливаются оттуда. Поведение сложной системы складывается из совместного поведения более мелких строительных блоков.
Стратегия хаоса
[ редактировать ]Стратегия хаоса — это стратегия разработки программного обеспечения, основанная на модели хаоса. Главное правило – всегда сначала решайте самый важный вопрос .
- Проблема заключается в незавершенной задаче программирования.
- Самый важный вопрос – это сочетание больших , неотложных и надежных задач .
- Большие проблемы представляют ценность для пользователей в качестве рабочей функциональности.
- Срочные вопросы являются своевременными, поскольку в противном случае они задержали бы другую работу.
- Надежным проблемам доверяют и проверяют, когда они решены. Тогда разработчики смогут безопасно сосредоточить свое внимание на чем-то другом.
- Решить – значит привести его к точке стабильности.
Стратегия хаоса напоминает то, как программисты работают ближе к концу проекта, когда у них есть список ошибок, которые нужно исправить, и функций, которые нужно создать. Обычно кто-то расставляет приоритеты оставшимся задачам, и программисты исправляют их по одной. Стратегия хаоса утверждает, что это единственно верный путь. способ выполнения работы.
Стратегия хаоса была вдохновлена стратегией Го . [ нужна ссылка ]
Связи с теорией хаоса
[ редактировать ]Есть несколько связей с теорией хаоса .
- Модель хаоса может помочь объяснить, почему программное обеспечение имеет тенденцию быть настолько непредсказуемым.
- Это объясняет, почему концепции высокого уровня, такие как архитектура, не могут рассматриваться независимо от строк кода низкого уровня.
- Это дает возможность объяснить, что делать дальше с точки зрения стратегии хаоса.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Scrumdevelopment: Сообщение: Re: [scrumdevelopment] Re: Agile триангуляция» . Архивировано из оригинала 12 апреля 2013 г. Проверено 8 февраля 2013 г.
- ^ Цифровая библиотека ACM, Модель хаоса и цикл хаоса , Заметки по разработке программного обеспечения ACM SIGSOFT, Том 20, выпуск 1, январь 1995 г.
Дальнейшее чтение
[ редактировать ]- Роджер Прессман (1997) Программная инженерия: практический подход, 4-е издание, страницы 29–30, McGraw Hill.
- Енот (1995) Модель хаоса и жизненный цикл хаоса , в заметках по разработке программного обеспечения ACM, том 20, номер 1, страницы с 55 по 66, январь 1995 г., ACM Press.