njtynhj

在计算机界，混沌模型是一种软件开发的结构。其创始者曾使用 L.B.S.Raccoon 的笔名在这里（请帮助修正死链）指出，诸如螺旋模型和瀑布模型的项目管理模型虽然擅长于管理日程表和员工，但并未提供如何修复缺陷等解决其它技术问题的方法；与此同时，程序设计方法学虽然对修复缺陷及解决其它技术问题有效，但在管理截止日期或响应客户请求的方面并无帮助。此种模型试图桥接此一沟壑。混沌理论被用来帮助理解这里所出现的问题。^[1]

软件开发生命周期

混沌模型指出，生命周期的每个阶段都应被套用到项目的所有层次上，从整个项目到单独的代码行。

• 整个项目必须被定义好、实现好、整合好。


• （项目的）各个系统必须被定义好、实现好、整合好。


• （系统的）各个模块必须被定义好、实现好、整合好。


• （模块的）各个功能必须被定义好、实现好、整合好。


• （功能的）各行代码必须被定义好、实现好、整合好。

在观念上的一个重大变革是关于项目是能被看成一个整体、还是必须被看成一些零部件的组合。没人能一次写出数千行代码，人们只能每次写几行代码的小片段、并测试这些小片段是否能正常工作，依此来一点一点搭建整个项目。一个复杂系统的行为发端于这些小建筑块的行为的组合。

混沌策略

混沌策略是基于混沌模型的软件开发策略，其主要规则是永远先解决最重要的问题。

• 
  问题是未完成的编程任务。


• 
  最重要的问题包括大、急以及壮这三个方面。
  
  • 
    大问题向用户提供功能点。
  
  
  • 
    急问题亟需解决，否则可能会耽误其它工作。
  
  
  • 
    壮问题在解决并测试之后就被认为是可信任的，这样开发人员可以安全地着眼于其它地方。
  
  


• 
  解决问题意味着拿出一个稳定的方案。

混沌策略描述了程序员如何在有一份“待修复缺陷及待实现功能”列表的情况下完成某个项目的。通常，有专人为剩余的任务指定优先级，程序员们再一个一个解决它们。混沌策略认为这才是唯一行之有效的完成工作的方法。

混沌策略受到了围棋战术的启发。

与混沌理论的联系

两者之间有许多联系：

• 混沌模型有助于解释为何软件经常无法预测。


• 揭示了为何诸如计算机架构这样的高级概念不可以在底层代码中单独考虑。


• 以混沌策略的形式提供了揭示下一步做什么的提示。

参见

• V 模型

参考文献

延伸阅读

• 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–66, January 1995, ACM Press.

此條目需要更多頁面分類。請協助為此條目補上適當的頁面分類。參見頁面分類入門。（2014年9月17日）