开发软件所需要经历的阶段要谈“快速开发”我们就需要先来了解一下软件项目所需要经历的过程：软件的开发过程并不仅是一个编写、实现代码的简单过程，软件的开发需要经历许多的步骤。

因此在开始时我们先用一个相对简单的方式了解一下软件开发的常见过程：从上图可以直观的看出，一个软件的开发至少是包含了上图的三个阶段、七个步骤。

而这个过程中又可能涉及到下列各种参与软件开发的角色：［并不是任何项目中都会出现所有角色，角色同实际的参与人员也并不一定一一对应］我们在此所探讨的软件“快速开发”为的是在软件目标、外部资源相同的情况下（如：同一团队，同一项目）可以缩减整个开发周期的各种方式，使软件项目最终能在一个更短时间内完成。

能缩短软件开发周期的三种方式缩短软件开发周期其实一直是全世界软件开发团队所长期关注的话题，把现在已被广泛认可的有效缩短周期的方式归类一下可划分为三大类：1.工具快速2.模式快速3.经验快速其分别代表着实现软件项目“快速开发”的“天时、地利、人和”，同时也蕴藏着“天时不如地利，地利不如人和”的真谛。

天时——工具快速在一个软件项目所经历的各阶段中（如：⑴需求分析、⑵原型开发、⑶实现、⑷测试、⑸完成、⑹需求变更、⑺后期维护），不同阶段选用适当的工具能非常直接的相应参与人员的工作效率、沟通效率，缩短单个步骤所需要的时间，从而在整体上缩短软件项目的开发周期。

值得注意的一点是，工具并不仅限于软件形态的工具。

⑴需求分析：是软件项目开发第一个也是很重要的一个阶段，需求分析的基本任务是要准确地定义新系统的目标，为了满足用户需要，回答系统必须“做什么”的问题。

在这个阶段中包含需要获取需求、分析需求、编写规格说明和需求验证。

从获取需求到需求验证的这个过程需要编写文档、绘制图形、创建需求模型等，像文档之类的工具可以使用word、绘制图形可以使用visio、建模可以使用rational rose等工具软件，有了这些工具的辅助，可提高编写文档的速度，缩短分析阶段的周期。

除了以上这些软件形态的工具外还可为更快的项目参与人员之间的想法沟通，借助一些实体类工具，如纸制卡片，黑板或一些已经成型的系统。

⑵原型开发：在软件需求分析阶段，需要搞清楚的是软件要“做什么”的问题，并把这些需求通过文档的形式描述出来，这也是目标系统的逻辑模型。

进入设计阶段，则要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求，并将设计的结果反映在“设计规格说明”文档中，接下来开始设计。

设计的基本任务包括：软件结构、数据结构及数据库设计、概要设计文档。

开发一个大而复杂的软件系统，我们可以将它进行适当的分解来降低其复杂性，还可减少开发工作量，你也可以使用一些能够提高设计速的软件来帮助你进行设计，从而提高软件生产率，降低开发成本。

所用的工具比如使用UML绘制类图的工具。

⑶实现：设计完成之后进入编码实现阶段，为了提高整个项目的开发速度，编写代码我们可以借助一些有力的开发工具来加快速度，例如，如果是用JAVA语言开做开发的话，可以使用eclipse、JCreater，如果是用C#、VB你可以用Visual ；如果是开发网站之类的可以用Dreamweaver。

美工可以使用photoshop或是FireWork之类的工具。

节省项目的开发时间。

另外一方面由于软件技术的快速发展带来了各种平台和引擎，选用适当的平台技术与引擎能更大程度的缩短周期。

⑷测试：软件的测试也是一个非常重要的阶段，大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的在本专题开始时我们所示范的开发流程，实际就是一种典型的瀑布模型（又称线形模型）：瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)，集成，和维护坚定地顺畅地进行。

在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式。

但是，大多数人并不知道这一点，一些人也不相信它能够作为一种真实世界的过程使用。

在实践中，过程很少能够以纯线性的方式进行。

通过回到前面的阶段或改便前一阶段的结果的迭代是非常RUP处理过程为软件开发提供了规定性的指南、模板和范例。

它可以通过提供一个应用于整个软件开发周期的、可定制的最佳开发方案架构，RUP可以对整个开发小组的工作进行指导和安排。

RUP将项目管理、商业建模、需求管理、分析和设计、测试以及变更控制等，统一到了一个一致的、贯穿整个开发周期的处理过程。

RUP正如其名，它使团队中每个开发人员的见解和思想得到统一，使开发小组成员的沟通更为容易，而这正是任何项目要取得成功的关键因素；它增强了开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间，全面提高了开发速度。

RUP是严格按照行业标准UML开发的，它的特点主要表现为如下六个方面：•开发复用。

减少开发人员的工作量，并保证软件质量，在项目初期可降低风险。

•对需求进行有效管理。

•可视化建模。

•使用组件体系结构，使软件体系架构更具弹性。

•贯穿整个开发周期的质量核查。

•对软件开发的变更控制。

RUP可以缩短软件项目的开发周期，实现大型项目的快速开发，对于中小型项目RUP就显的过于庞大，其需要投入的成本也很非常观。

3.敏捷开发，极限编程2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。

敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。

极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益。

XP在很多方面都和传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。

这些方法在软件工程和其他管理活动中都有借鉴意义。

XP具有12个过程，只有完全使用12个过程才是真正使用了XP，只是简单使用了其中一个方法并不代表使用了XP。

•现场客户（On-site Customer）•计划博弈（Planning Game）•系统隐喻（System Design）•简化设计（Simple Design）•集体拥有代码（Collective Code Ownership）•结对编程（Pair Programming）•测试驱动（Test-driver）•小型发布（Small Release）•重构（Refactoring）•持续集成（Continous integration）•每周40小时工作制（40-hour Weeks）•代码规范（Coding Standards）下面是极限编程的有效实践：1.完整团队 XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。

这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2.计划游戏计划是持续的、循序渐进的。

每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

3.客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4.简单设计团队保持设计恰好和当前的系统功能相匹配。

它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

5.结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

6.测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。

同样，它更是一种编写文档的行为。

编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。

程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7.改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

8.持续集成团队总是使系统完整地被集成。

一个人拆入（Check in）后，其它所有人责任代码集成。

9.集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。

没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

10.编码标准系统中所有的代码看起来就好像是被单独一人编写的。

11.隐喻将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。

如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

12.可持续的速度团队只有持久才有获胜的希望。

他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。

极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

4.NoahWeb"增量迭代"模式以RUP和极限编程中的增量所不同的的是NoahWeb“增量迭代”模式仅适用于B/S软件项目。

考虑B/S项目中的人员配置、工作重心与C/S项目截然不同的特殊性，因此该模式专门针对B/S项目而提出。

从以往的很多B/S应用开发案例来看，用户的需求并不会在需求分析阶段和原型开发阶段就可以准确获得，往往在应用系统接近发布时，用户才会提出各种各样具体的需求。

[B/S应用开发过程中各阶段中用户需求变化图]导致这样的原因很简单：在需求分析阶段，最终用户不可能通过开发文档就能想象出应用系统运行时的实际情况，而系统接近成型时，用户通过真实使用会感觉到系统存在的问题和设计缺陷。

由于用户需求在发布前频繁变更这一特性，使用传统B/S解决方案的设计人员和开发人员将会此阶段面临需求变更的各种考验，项目周期和开发成本也会在发布阶段由于需求变更急剧扩大，有时甚至可能之前工作推倒从来。

•考虑B/S项目的特殊性B/S项目以往一直采用同C/S软件项目一样的开发模式和流程管理。

但由于B/S项目同C/S项目太多的不同之处，使得B/S项目开发周期很难控制。

B/S一方面要面临着需要短时间获取需求，需求不明确。

另一方面B/S开发中美工和界面设计美化的重要性也不同于C/S。