Editing Chaos model

In [[computing]], the '''chaos model''' is a structure of [[software development]]. Its creator, who used the pseudonym L.B.S. Raccoon,<ref>{{cite web |url=http://tech.dir.groups.yahoo.com/group/scrumdevelopment/message/33620 |title=Scrumdevelopment : Message: Re: &#91;scrumdevelopment&#93; Re: Agile triangulation |accessdate=2013-02-08 |url-status=dead |archiveurl=https://archive.today/20130412054525/http://tech.dir.groups.yahoo.com/group/scrumdevelopment/message/33620 |archivedate=2013-04-12 }}</ref> noted that project management models such as the [[spiral model]] and [[waterfall model]], while good at managing schedules and staff, didn't provide methods to fix bugs or solve other technical problems. At the same time, programming methodologies, while effective at fixing bugs and solving technical problems, do not help in managing deadlines or responding to customer requests. The structure attempts to bridge this gap. [[Chaos theory]] was used as a tool to help understand these issues.<ref>ACM Digital Library, [http://portal.acm.org/citation.cfm?id=225914 The chaos model and the chaos cycle], ACM SIGSOFT Software Engineering Notes, Volume 20 Issue 1, Jan. 1995</ref>

==Software development life cycle==
The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code.

* The whole project must be defined, implemented, and integrated.
* Systems must be defined, implemented, and integrated.
* Modules must be defined, implemented, and integrated.
* Functions must be defined, implemented, and integrated.
* Lines of code are defined, implemented and integrated.

One important change in perspective is whether projects can be thought of as whole units, or must be thought of in pieces. Nobody writes tens of thousands of lines of code in one sitting. They write small pieces, one line at a time, verifying that the small pieces work. Then they build up from there. The behavior of a complex system emerges from the combined behavior of the smaller building blocks.

==Chaos strategy==
The chaos strategy is a strategy of software development based on the chaos model. The main rule is ''always resolve the most important issue first''.

* An ''issue'' is an incomplete programming task.
* The ''most important'' issue is a combination of ''big'', ''urgent'',  and ''robust''.
** ''Big'' issues provide value to users as working functionality.
** ''Urgent'' issues are timely in that they would otherwise hold up other work.
** ''Robust'' issues are trusted and tested when resolved. Developers can then safely focus their attention elsewhere.
* To ''resolve'' means to bring it to a point of stability.

The chaos strategy resembles the way that programmers work toward the end of a project, when they have a list of bugs to fix and features to create. Usually someone prioritizes the remaining tasks, and the programmers fix them one at a time. The chaos strategy states that this is the only valid
way to do the work.

The chaos strategy was inspired by [[Go (board game)|Go]] strategy.{{Citation needed|date=October 2020}}

==Connections with chaos theory==
There are several tie-ins with [[chaos theory]].

* The chaos model may help explain why software tends to be so unpredictable.
* It explains why high-level concepts like [[software architecture|architecture]] cannot be treated independently of low-level lines of code.
* It provides a hook for explaining what to do next, in terms of the chaos strategy.

==See also==

*[[V-Model (software development)|V-model]]

==References==
{{reflist}}

==Further reading==
* Roger Pressman (1997) Software Engineering: A Practitioner's Approach 4th edition, pages 29–30, McGraw Hill.
* Raccoon (1995) [http://www.swcp.com/raccoon/papers/chaos93.wpd 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.

{{DEFAULTSORT:Chaos Model}}
[[Category:Software development process]]