软件工程第三章课件

4. 分组制定小型规格说明
与会者分成更小的小组，为每张列表中的项目制定 小型规格说明。每个小组都向全体与会者展示他们 制定的小型规格说明，供大家讨论。
5. 制定确认标准，起草需求规格说明书
每个与会者都制定出产品的一整套确认标准，并提 交会议讨论，以创建出意见一致的确认标准。
最后，起草完整的软件需求规格说明书。
情景分析技术的用处：
能在某种程度上演示目标系统的行为，从而便 于用户理解，而且还可能进一步揭示出一些分 析员目前还不知道的需求。
能保证用户在需求分析过程中始终扮演一个积 极主动的角色。让用户起积极主动的作用对需 求分析工作获得成功是至关重要的。
3.2.2 面向数据流自顶向下求精
1. 分析追踪数据流图 需求分析的目标之一就是把数据流和数据存储定义到
注重需求实现与维 护过程，处理不断 变更的系统需求
理
需求管理存在的问题：
范围问题：系统目标、边界未被良好定义，用 户和开发团队理解不一致。
理解问题：用户不能完全了解自己需要什么， 对系统能力、局限更加不清楚；工程师不理解 用户的问题域和应用环境。
易变问题：需求随时间发生变化。
需求工程：
20世纪80年代中期，形成了软件工程的子领 域——需求工程。
元素级，通常从数据流图的输出端着手分析。 2. 用户复查 必须请用户对上述分析过程中得出的结果仔细地复查。
复查过程验证了已知的元素，补充了未知的元素，填 补了文档中的空白。
随着分析过程的进展，经过问题和解答的反复循环， 分析员越来越深入具体地定义了目标系统，最终得到 对系统数据和功能要求的满意了解。
然后开发者和用户分别写出“产品需求”。选 定会议的时间和地点，并选举协调人。
2. 会前审查需求，确定列表

–多个来回
6
软件需求分析的通信途径
7
分析建模
结构化分析模型 面向对象分析模型 分析模型描述工具

DFD、DD和PSPEC（加工规约）
CFD、CSPEC（控制规约）和STD E-R图 用例图，对象-关系图，对象-行为图
8
结构化分析模型
数据对象 说明 E-R图 加工说明 DFD图
44
数据流图
数据流图(DFD)是一种图形化技术，它描绘信息
流和数据从输入移动到输出的过程中所经受的变换 。 在数据流图中没有任何具体的物理部件，它只是 描绘数据在软件中流动和被处理的逻辑过程。 数据流图是系统逻辑功能的图形表示，即使不是 专业的计算机技术人员也容易理解它，因此是分析 员与用户之间极好的通信工具。 此外，设计数据流图时只需考虑系统必须完成的 基本逻辑功能，完全不需要考虑怎样具体地实现这 些功能。
2
需求分析的结构化分析方法准则
(1) 必须理解并描述问题的信息域，根 据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条 准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件 行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模 型进行分解，用层次的方式展示细节。
40
分析模型的元素
数据字典(DD)：模型核心(中心库) E-R图(ERD)： 数据流图(DFD)
指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;
DFD中每个功能的描述包含在加工规约 (小说明)。
状态变迁图(STD)
指明作为外部事件的结果,系统将如何 动作。
41
3.4.2 数据建模
4
需求分析的任务和步骤

S
1 2 3 4 5
软件设计概述 软件体系结构设计
模块化设计 界面设计
软件设计评审
➢软件体系结构为系统设计提供了一套关于数据、行为、结 构的指导性框架，该框架提供了描述系统数据、数据间关系 的静态特征，也对数据的操作、系统控制和通信等活动提供 了具有动态特征的描述过程。 ➢系统的静态特征体现了系统的组织结构，系统的动态特征 体现系统操作流程的拓扑结构，共同构成设计决策的基本指 导方针。
设
计 内
界面设计
容
数据设计
过程设计
➢概要设计也称总体设计，主要任务是基于数据流 图和数据字典，确定系统整体软件结构，划分软件 体系结构的各子系统或模块，确定它们之间的关系。
➢体系结构设计：确定各子系统模块间的数据传递、 调用关系。在结构化设计中，体现为模块划分，并 通过数据流图和数据字典进行转换。在面向对象设 计中，体现为主题划分，主要确定类及类间关系。
➢详细设计是在概要设计的基础上，具体实现各部分的细节， 直至系统的所有内容都有足够详细的过程描述。 ➢过程设计包括确定软件各模块的具体实现过程及局部数据 结构。在结构化设计中，模块独立性约束了数据结构与算法 相分离的情况，使得两者在设计时务必有局部性，减少外部 对两者的影响。在面向对象设计中，类的封装较好地体现了 算法和数据结构的内部性。类的继承性提供了多个类（类家 族）共同实现过程设计的机制。
➢缺点： 随着网络技术的发展，数据共享带来的访问控制的复杂性、
安全性、效率、备份、存储、恢复策略等一系列问题，影响 了仓库模型的有效利用。
➢集中式数据仓库模型在带来数据一致性访问优势 的同时，也造成网络环境下难以分布应用的缺陷。 ➢分布式结构模型是充分利用、整合网络中计算机 各自的计算能力，从而提高整个网络系统运行的能 力和效率。

3.1.3 导出系统的逻辑模型
包括完善的数据流图、实体－联系图、状态转换图、 数据字典、主要的处理算法（IPO图）等。
3.1.4 修正系统开发计划
修订前期制定的开发进度计划、等。
3.2 与用户沟通获取需求的方法
3.2.1 访谈
正式访谈：系统分析员提出事先准备好的问题。 非正式访谈：提出一些用户可以自由回答的开放性问
题，鼓励被访者说出自己的想法。 需要访问大量人员时，利用调查表访问较佳。 情景分析技术：对用户将来使用目标系统解决某个具
体问题的方法和结果进行分析。
3.2.2 面向数据流自顶向下求精
借助数据流图、数据字典、IPO图等，细化、完善详
细的数据流图，等到各处理环节对应的功能。
需要分解
有补充修正
分析追踪数 据流图
3.6.2 事件
事件是某个特定时刻发生的事情，它是引起系
统做动作或状态转换的控制信息。 3.6.3 符号 初态：实心圆 终态：同心圆（内圆为实心园） 中间态：圆角矩形，分为上、中、下三部分
状态名称 状态变量 活动表
状态变量的名字和值 事件名（参数表）/动作表达式 标准事件：entry, exit, do
1.引言
1.1 目的 1.2 文档的约定 1.3 预期的读者和阅读建议 1.4 产品的范围 1.5 参考文献
2. 综合描述
2.1 产品的远景 2.2 产品的功能 2.3 用户类和特性 2.4 运行环境 2.5 设计和实现的限制
需求规格说明书
3. 外部接口
3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通信接口
用户接口、硬件接口、软件接口、通信接口、等。 6. 约束
精度、工具和语言、设计约束、硬件约束、标准，等。 7. 逆向需求 ：软件系统不应该做什么 8. 将来可能提出的要求 ：为将来的修改和扩充做准备。

购 书 申 学 请 书 购 单 开发票 发 票 领 书 单 发书
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)

性能需求
软件开发的技术性指标：

存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求

第3章 敏捷开发
2021/4/8
1
主要内容
❖敏捷是什么 ❖敏捷及变更的成本费用 ❖敏捷过程 ❖极限编程 ❖其他敏捷过程模型
❖ 自适应软件开发 ❖ Scrum ❖ 动态系统开发方法 ❖ Cryst捷过程工具集 ❖小结
2021/4/8
2
敏捷软件工程
2021/4/8
11
敏捷及变更的成本费用
❖软件开发的传统方法中变化的成本费用随 着计划的进展成非线性增长。这种方法在 软件开发团队收集需求时相对容易适应变 化。但是假设如果在进行确认测试的过程 中变更一个主要的功能。这一变更需要对 软件的体系结构设计进行修改，包括设计 和构建三个新组件，修改另外五个组件， 设计新的测试等，则费用会迅速上升。
2021/4/8
14
敏捷联盟定义的12条原则
1、我们最优先要做的是通过尽早、持续 交付有价值的软件来使客户满意。
2、即使在开发的后期，也欢迎需求变更。 敏捷过程利用变更为客户创造竞争优势。
3、经常交付可工作软件，交付的间隔可 以从几个星期到几个月，交付的时间间隔 越短越好。
4、在整个项目开发期间，业务人员和开 发人员必须天天都在一起工作。
2021/4/8
6
敏捷软件开发宣言
❖个人和这些个人之间的交流胜过开发过程 和工具
❖可运行的软件胜过宽泛的文档
❖客户合作胜过合同谈判
❖对变更的良好响应胜过了按部就班地遵循 计划
❖亦即，虽说上述右边的各项很有价值，但 我们认为左边的各项具有更大的价值
2021/4/8
7
敏捷方法
❖ 本质上讲，敏捷方法是为了克服传 统软件工程中认识和实践的弱点开 发而成的。敏捷开发可以带来多方 面的好处，但它并不完全对立于传 统软件工程实践，也不能作为超越 一切的哲学理念而用于所有软件工 作。

精品课件
19
敏捷宣言
我们正在通过亲身实践以及帮助他人实践，揭示
更好的软件开发方法。通过这项工作，我们认为
（形成如下价值观）：
注重个体和交互 胜过 过程和工具
注重可用的软件 胜过 面面俱到的文档
注重客户合作 胜过 合同谈判
注重响应变化 胜过 恪守计划
也就是说，虽然右边的条目有价值，但我们更
看重左边的条目。 ——
客户合作胜过合同谈判
➢ 指明了需求、进度以及项目成本的合同 存在根本上的缺陷。
➢ 成功的项目需要频繁有序的客户反馈。 为开发团队和客户的协同工作方式提供 指导的合同才是最好的合同。
精品课件Biblioteka 23如何理解敏捷宣言？（续）
响应变化胜过遵循计划
➢ 计划赶不上变化。响应变化的能力决定 一个项目的成败。
➢ 较好的做计划策略是：为下两周做详细 的计划，为下三个月做粗略的计划，再 以后就做极为粗糙的计划。
精品课件
2
瀑布模型的特点
➢ 强调阶段的严格性:严格按照生存周期各个阶段的目 标、任务、文档和要求来进行开发。
➢ 强调阶段复审与确认:通过严格的阶段性复审与确认， 得到该阶段的一致、 完整、准确和无二义性的良好 文档。
➢ 以文档形式驱动:以文档形式驱动的，为合同双方最 终确认产品规定了蓝本， 为管理者进行项目开发管 理提供了基础，为开发过程施加了“政策”或纪律 限制， 约束了开发过程中的活动。
精品课件
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。
➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保