常用软件开发流程分析

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

敏捷开发：
核心是迭代。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划


简单设计，重复迭代。减少不必要的文档。
客户最关心的功能最先完成。
要求客户有时间对每次迭代的成果进行确认，提出改进意见。


沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。


开发团队有两个队伍，业务团队和技术团队。如果任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，项目会议上就会不断的要求功能和交付日，而不太担心开发人员是否能够全部完成或开发人员是否明白他们的真正要求；如果开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。


PMBOK的项目管理是自上而下的命令式管理，而敏捷的管理是团队的自我管理和项目经理的服务式管理
敏捷开发不能在一开始就给出项目的成本计划。
在有技术问题还没有解决的情况下不适合展开迭代。


1、瀑布模型(Waterfall Model) 

所有过程模型的鼻祖。---- Royce,1970

瀑布模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。在软件生存期的每个阶段都采用科学的管理技术和良好的方法与技术，而且每个阶段结束之前，都从技术和管理两个角度进行严格的审查，经确认之后才开始下一阶段的工作。----项目是按照一定的顺序执行。
瀑布模型是文档驱动的，各个阶段不连续也不交叉。
特点：
阶段间具有顺序性和依赖性。
推迟程序的物理实现。
质量保证：每个阶段必须完成规定的文档；每个阶段结束前完成文档审查,及早改正错误。
易于组织，易于管理：因为你可以预先完成所有计划。
是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式）
适用场合：
当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适。
当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。
对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。
在质量需求高于成本需求和进度需求的时候，它尤为出色。         当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。
缺陷：
在项目开始的时候，用户常常难以清楚地给出所有需求；用户与开发人员对需求理解存在差异。
实际的项目很少按照顺序模型进行。
缺乏灵活性：因为瀑布模型确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的，导致“阻塞状态”。反馈信息慢，开发周期长。 
虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧式的”，但是在需求被很好地理解的情况下，仍然是一种合理的方法。
增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子


2、快速原型模型（Rapid Prototype Model）
  
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

3、增量模型（Incremental Model）
 
又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。


在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。


4、螺旋模型（Spiral Model）
1988年，BarryBoehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
 
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：
（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

5、迭代模型
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
什么是迭代式开发？
每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 


在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。
每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
再通过客户的反馈来细化需求，并开始新一轮的迭代。


迭代式开发的优点：
1、降低风险
2、得到早期用户反馈
3、持续的测试和集成
4、使用变更

5、提高复用性

6、边做边改模型（Build-and-Fix Model）


国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
 


各种模型的优点和缺点
瀑布模型 文档驱动 系统可能不满足客户的需求
快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护
增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低
螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练