增量模型的困难
• 需要一个开放的结构，方便构件的加入 • 增量模型本身就是一个矛盾的名词
软件过程：增量模型
风险更大的增量模型
System/information engineering Analysis Design
Increment 1
Code
Test
Delivery of 1 st increment
• 用户需求描述用户使用系统而要完成的各种任务，
由用例（use case）文档或方案脚本说明
• 功能需求定义开发人员必须实现的软件功能，它源
于用户需求，是软件需求说明书中重要的组成部分
软件需求的层次（2）
简单性描述
需求层次之间的关系
不同层次成果
需求开发(1)
• 需求获取：通过各种途径获取用
户的需求信息， 经过“定义问题 分析问题根本原因分析涉众定义 系统边界确定约束条件”
4. 总体设计（概要设计） “概括地说，应该怎样实现目标系统?” 设计出实现目标系统的几种可能的方案。推荐一 个最佳方案。 5. 详细设计 “应该怎样具体地实现这个系统呢?” 设计出程序的详细规格说明。
6. 编码和单元测试 写出正确的容易理解、容易维护的程序模块 仔细测试编写出的每一个模块。
1 2 3
软件维护：使软件持久地满足用户的需要。 4.总体设计、5.详 细设计、6.编码和 单元测试、7.综合 测试
8.软件维护
• 软件产品或系统一系列相关活动的全周期
软件定义 软件开发 软件维护
问 题 定 义
可 行 性 分 析
需 求 分 析
总 体 设 计
详 细 设 计
编 码
测 试
软 件 发 布
软 件 运 行
书写可行性报告等文挡，提交审查
n
什么是需求工程？
• 需求工程提供了一个比较完善的流程和方法来 解决如何定义一个待开发的软件系统
需求工程的内容
• 需求工程过程可以被描述为6个部分： 需求获取、需求分 析、需求传递、需求建模、需求确认和需求管理
需求工程的目标
• 开发出符合客户要求的系统需求，包括符合客户要求 的界面 • 提供有效的解决方案以便确定软件系统中的主要元素 • 将定义的需求分配给系统中的每个元素，了解软件需 求受系统的制约、对操作环境的影响 • 制定合适的软件版本发布策略，以确定系统或软件需 求实现的优先级 • 确定软件需求，并根据客户需求变化进行必要的更新
软 件 维 护
系统设计
系统实现
1. 问题定义
“要解决的问题是什么?” 确定用户要求解决的性质、工程的目标和规模。
2. 可行性研究
“对于上一个阶段所确定的问题有行得通的解决办法吗?” 经济可行性、技术可行性、法律可行性、不同的方案
3. 需求分析
“为了解决这个问题，目标系统必须做什么” 确定系统必须具有的功能和性能，系统要求的运行环境，并 且预测系统发展的前景。 规格说明书(specification)
螺旋模型
结合上述所有模型的特性
只能用于大型的内部软件产品 ，开发者必须精通风险分析和 风险排除
不知山林、险阻、沮泽之形者， 不能行军。
可行性研究 这个项目是做 还是不做呢？
一旦软件范围已经被标识出来，们自然会 问：“我们能够开放软件以满足改范围吗？ 项目是可行的吗？”在软件危机时期人们 通常会跳过这个阶段，往往陷入从开始就 注定失败的项目泥潭中。 可行性分析的目的是为了用最小的代价在 尽可能短的时间内确定问题是否能够解决。 必须记住：可行性分析不是要求解问题本 身，而是要确定问题是否有解。
软件设计的目标
高可靠性
• • • • • •
高可维护性 软件 设计 软件设计的目标 高可理解性
可靠性 高效率 性能和安全性 可扩展性 可定制性或可移植性 可维护性 可重用性
体系结构设计任务
• 设计软件系统结构，如系统层次结构的划分、分 布式结构的布局。 • 确定设计元素，为设计元素分配特定功能。 • 确定设计元素之间的关系，完成相应的通讯、同 步与数据存取的协议和接口的设计。 • 分析系统的规模和负载等，使系统满足性能、安 全性等要求。 • 对不同的设计方案进行比较和分析，选择最优的 解决方案。 • 编写设计文档。 • 设计文档评审
风险分析
•
每个阶段之后

评估 计划下一阶段
简化的螺旋模型
完
整
的 螺 旋 模
型பைடு நூலகம்
软件过程：螺旋模型（续2）
螺旋模型的优点
– 容易确定什么时候已经对某一阶段的产品充分测试完毕 – 维护和开发之间没有什么本质上的差别
螺旋模型的缺点
– 仅适合于大型软件
风险驱动既是优点也是缺点
软件过程：建造—修补模型
可行性研究的任务
技术可行性
使用现有的 技术能实现 这个系统吗？
经济可行性
这个系统的经 济效益能超过 它的开发成本 吗？
操作可行性
系统的操作 方式在这个 组织内行得 通吗？
技术可行性
度量一个特定技术信息系统解决方案的实用性及 技术资源的可用性
考虑的问题 (1)开发风险分析 (2)资源分析 (3)相关技术的发展（现有技术能 否实现新系统，技术难点、建议
瀑布模型
理想的瀑布模型
实际的瀑布模型
软件过程：瀑布模型（续1）
瀑布模型的特点
1. 阶段间具有顺序性和依赖性 2. 推迟实现的观点
• 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理 实现。 每个阶段都必须完成规定的文档 每个阶段结束前都要对所完成的文档进行评审
3. 质量保证的观点(文档驱动)
• •
软件过程：瀑布模型（续2）
瀑布模型的缺点
• 开发过程一般不能逆转，否则代价太大 • 规格说明很难理解：“我知道这是按我的要求做的， 但不是我想要的样子。” • 软件的实际情况必须到项目开发的后期客户才能看到 。（文档驱动的两面性）
快速原型模型
听取用 户意见
建造/修改 原型
用户测试 运行原型
软件过程：快速原型模型
采用技术的先进性）
可行性研究报告
• • 包括总体方案和可行性论证两个方面 内容：
– 引言 – 系统建设的背景、必要性和意义 – 拟建系统的候选方案 – 可行性论证 – 方案的比较 – 结论
• 可行性分析报告要尽量取得有关管理人员的一致认识
经济可行性
度量系统解决方案的性能价格比。 考虑的问题： 成本/效益分析（开发、运行的成本/效益） –有形成本、效益 –无形成本、效益 价值和成本的关系 –质量与价值、成本的关系 –价值/成本的均衡
需求定义 需求确认
需求管理
• 需求管理是针对不断变化的客户需求加以收集、处理 和跟踪，并建立软件需求的基准线，以作为项目中软 件开发活动过程和产品度量和变更管理的基础。 • 需求管理可以分为需求评审、需求跟踪和需求变更控 制 • 需求变更控制是需求管理中最主要的工作
软件设计
系统架构设计 详细设计

原型模型的特点
• • • • • • 快速原型的本质是“快速” 快速原型可以取代规格说明阶段，但不是设计阶段，容易适应需求的变化 有利于开发与培训的同步
原型模型的应用范围
对所开发的领域比较熟悉而且有快速的原型开发工具 项目招投标时，可以以原型模型作为软件的开发模型 进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非 常适合的
软件过程：快速原型模型
比较
• 瀑布模型—试图一次就获得正确的产品 • 快速原型—频繁变化，然后废弃
软件过程：增量模型（续1）
增量模型的优点
• • • •
每个阶段交付一个可用的产品 减少一个全新产品给客户带来的心理上的影响 分阶段地交付产品不需要大的资金支出 需求经常变化，增量模型的灵活性使其具有更 加优越的适用性
Software Development Process
jzwsc@
软件开发流程
软件生命周期：软件生命周期是软件产品或系统一系列相关活动的全周 期。
1.问题定义、2.可 行性研究、3.需求 软件定义：确定软件开发总目标；确定工程 分析 的可行性；导出实现策略及系统功能；估计 资源和成本，并且制定工程进度表。 软件开发：具体设计和实现在前一个时期定 义的软件
什么是软件需求
（1）用户解决问题或达到目标所需的条件或性能 （2）系统或系统部件要满足合同、标准、规范或其它正 式规定文档条件或性能 （3）一种反映上面（1）或（2）所描述的条件或性能的 文档说明。
软件需求的层次（1）
• 业务需求反映组织机构或客户对系统、产品的概括
性要求，包括所要达到的业务目标，由项目视图与范围 文档说明
可行性研究的任务
• 最根本的任务是对以后的行动方针提出建议 • 如果问题没有可行的解，应该建议停止这项开发 工程，以避免时间、资源、人力和金钱的浪费 • 如果问题值得解，应该推荐一个较好的解决方案 ，并且为工程制定一个初步的计划
可行性研究的内容
(1) 技术可行性 (2) 经济可行性 (3) 操作可行性 (4) 社会可行性(法律可行性) (5) 抉择
举例
成本-效益(万元) 该系统节省经费 60 40 盈亏平衡点 该系统成本
20
0 1 2 3 4 5 年 投资回收期
---------成本及效益分析图
操作可行性
• 用户使用可能性 • 时间进度可行性 • 组织和文化上的可行性
复查系统规模和目标 研究目前正在使用的系统 导出新系统的逻辑模型
符合要求吗？ y 评价可能解法，推荐行动方案， 草拟开发计划
7. 综合测试 集成测试和验收测试，现场测试或平行运行
8. 软件维护 使系统持久地满足用户的需要。 改正性维护，适应性维护，完善性维护，预防性 维护。