软件开发方法

1：瀑布方法
所有软件方法的祖先是瀑布方法（waterfall methodology）。它之所以被称为瀑布方法是因为开发模块相互之间的依次流动，瀑布方法通过控制阀门的一系列活动组成。这些控制阀门决定一个给定的活动是否已经完成并且可以进入下一个活动。需求阶段处理决定了所有的软件需求。设计阶段决定整个系统的设计。代码在代码阶段编写。代码然后被测试。最后产品被发布。
对瀑布方法模型最基本的批评就是瀑布方法对于反馈事物发展状况耗时太长。软件的一些内容那个很容易被理解，而另一些内容则相反。因此，当用户对于手边出现的问题都没有很好理解的时候，开发人员试图先完成所有的需求（也就是说，将需求量化到实际的规格说明当中）是非常空难的。更进一步来说，如果在需求中出现一个错误，它将传播到设计阶段，传播到代码中等。同时一般不存在过程中返回的真正能力。因此，如果进入测试并且发现设计的一部分是无法工作的，那么就会进行修改并修补问题而交差，但是这种方法将会失去设计活动的所有上下文环境——你只是有目的地对系统权宜行事！
认识到这个问题后瀑布方法已经被修改成几种形式。例如螺旋式瀑布方法它继承并使用了多个瀑布模型。这种方法缩短了生命周期向下的时间；也就是说，为解决为题提供了迭代方案。
最终，大家无法脱离瀑布方法是因为它确实是合乎常规的方法。首先，这种方法可以决定将要构建的内容。接着，决定将要如何构建这些，下一步，世界构建这些内容。可以确保自己确实构建自己所需的东西（并且可以成功运行）。
2：统一过程
统一过程应用了基于处理系统首先考虑的最重要方面而实施的短期迭代开发。
开发一个寡欲各种用列（use case）的调查文档（也就是说，对用户与系统交互的简短描述），并且开始排除那些可能对整个系统成功造成风险的用列。只要适合，就可以在开发过程中添加或者删除用列。
统一过程的4个阶段定义如下：
初始(inception)：系统仍然处于决定系统内容的阶段——系统将要完成什么以及系统的边界是什么。如果系统能够很好的理解，那么这个阶段就非常短。
细化(Elaboration)：正在将体系结构的风险移至系统。一种表述该阶段的说法是，“你是否已经解决了所有难题？”或者“你知道如何完成你将要去完成的事情吗？”
构造（Construction）正在完成所有相关的用列来使系统为移交做好准备，也就是说，进入Beta版本。
移交（Transition）使系统通过它的最后发布阶段以及Beta版本。它可能包括软件的操作及维护。
这是一个关注于维护要素的敏捷过程，但是仍然采用了大量用例开发，间模等方面的传统实践。
3：极限编程：
极限编程的开发过程就是以代码为中心的方法。
让用户告知你一些有关系统是如何如用转的故事描述，基于故事相互之间的重要性来定制这些系统这样就可以为自己的团队提供一个故事集合，可以在一个给定的迭代中完成他们，大约两周时间——每周工作40个小时，你将团队划分，双人应付没一个故事，在代码被编写时提供确定数量的内建对等评审。你和你的同伴在编写自己代码的同时编写单元测试。在完成自己负责的那段代码后，将其拿到集成的机器上，放入代码基线，运行从所有人的代码中积累而成的单元测试。在完成iji负责的那段代码后，将会提供一个运行系统使用户可以评审来确保自己的工作满足他们的需要。
注意极限编程并没有将软件的设计设置成一个高级阶段。相反它认为那些最前端的设计对于整个系统开发不是很有帮助，并且随着实际开发的进行它最终还是被修改。
极限编程对于需要持续提供运行系统的软件卡发来说非常适用。当缺少用户介入或者项目规模很大时极限编程方法将会不好用，因为这时协调和设计活动实际上变得更重要了。
极限编程合理地考虑开发团体的能力，这样可以有效计划。