优点:
1.降低软件开发的复杂程度,提高软件开发过程的透明性,提高软件开发过程的可管理性
2.推迟软件实现,强调在软件实现前必须进行分析和设计工作
3.以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,保证了阶段之间的正确衔接,能够及时发现并纠正开 发过程中存在的缺陷,使产品达到预期的质量要求
缺点:
1.强调过程活动的线性顺序
2.缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题
3.风险控制能力较弱
4.瀑布模型中的软件活动是文档驱动的,当阶段之间规定过多的文档时,会极大地增加系统的工作量
5.管理人员如果仅仅以文档的完成情况来评估项目完成进度,往 往会产生错误的结论
优点:
1.增强客户对系统的信心
2.降低系统失败风险
3.提高系统可靠性
4.提高系统的稳定性和可维护性
缺点:
1.增量粒度难以选择
2.确定所有的基本业务服务比较困难
优点:
1.设计灵活,可以在项目的各个阶段进行变更
2.以小的分段来构建大型系统,使成本计算变得简单容易
3.客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
4.随着项目推进,客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互
缺点:
1.需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,会造成重大损失
2.过多的迭代次数会增加开发成本,延迟提交时间
优点:
1.有助于增进软件人员和用户对系统服务需求的理解,减少两者之间的误解
2.易于确定系统的性能,确认各项主要系统服务的可应用性,确认系统设计的可行性,确认系统作为产品的结果
3.软件原型版本有的可以原封不动地成为产品,有的略加修改就可以成为最终系统的一个组成部分,有利于最终系统的建成
缺点:
1.大型系统难以进行直接的原型模拟,只能经过系统分析得到系统的整体结构
2.原型方法难以构造处理大量运算、逻辑性较强的程序模块的原型
3.原有应用的业务流程、信息流程混乱的情况下,原型构造与使用有一定的困难
4.批处理系统的大部分活动是内部处理的,应用原型方法会有一 定的困难
5.此外原型方法还存在容易忽略文档工作、建立原型带来的资源浪费、项目规划和管理困难等问题
一、用例驱动
(1)采用用例来捕获对目标系统的功能需求
(2)采用用例来驱动软件的整个开发过程,保证需求的可跟踪性,确保系统所有功能均被实现
(3)将用户关心的软件系统的业务功能实体功能模型和开发人员结合起来,提供一种贯穿整体软件生存周期的开发方式,使得软件开发的各个阶段的工作自然、一致地协调起来
二、以架构为中心的
(1)强调在开发过程的早期,识别出软件与软件的体系结构紧密相关的用例,并通过对这些用例的分析、设计、实现和测试,形成体系结构框架
(2)在后续阶段中对已形成的体系结构框架进行不断细化,最终实现整体系统
(3)在开发过程中的早期形成良好的软件体系结构,有利于对系统的理解、支持重用和有效的组织软件开发
三、受控的迭代式增量开发
(1)将软件开发分为一系列小的迭代过程,在每个得带过程中逐步增加信息、进行细化
(2)根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流
(3)每次迭代都选择目前对风险影响最大的用例进行,以分解和降低风险
用例驱动和受控的迭代式增量开发体现用户驱动开发,以架构为中心体现风险驱动开发。
每个阶段结束于一个主要的里程碑(Major Milestone),并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
初始阶段里程碑:生命周期目标里程碑,包括一些重要的文档,如:项目构想、原始用例模型、原始业务 风险评估、一个或者多个原型、原始业务案例等。需要对这些文档进行评审,以确定正确理解用例需求、项目风险评估合理、 阶段计划可行等。
精化阶段里程碑:生命周期体系结构里程碑,包括风险分析文档、软件体系结构基线、项目计划、可执行的进 化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项 目计划可行等。
构建阶段里程碑:初始运行能力标里程碑,包括可以运行的软件产品、用户手册等,它决定了产品是否可 以在测试环境中进行部署。此刻,要确定软件、环境、用户是 否可以开始系统的运行。
移交阶段里程碑:产品发布里程碑。确定最终目标是否实现,是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。
工期和质量均已由甲方乙方在合同中确定,只有范围/内容是可变的,由团队控制的。
因为迭代式增量开发过程中,每次迭代都是有过程可循的,只是在上一轮迭代的基础上添加内容。有序生产的企业的迭代的周期是基本确定的。