软件项目开发 ppt课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 描述需求的标准
• 是完整的、正确的、必要的、无歧义的、可行 的、可验证的以及被设置了优先级别的。
25
2.4 需求分析活动
• Why
– 需求不一致、模糊、矛盾 – 需求变更 – 客户忽略领域常识/知识/术语 – 客户集中于现有系统的不足之处，而忽略
了系统要实现的关键功能 – 零碎、无组织、不明确、表达不清 – 不分轻重缓急
• 根据软件需求规约文档，确定一个合理的软件 体系结构。这个体系结构包括合理地划分组成 系统的模块、模块间的调用关系以及模块间的 接口关系。软件体系结构还从总体方面决定了 系统的可扩充性、可维护性，以及系统的性能 等。总体设计的设计粒度较大，有时也被称为 概要设计、架构设计。
31
2.5 设计活动
– 详细设计
资源
人员,工具
14
2.1 软件过程的概念
What
Change
How
15
2.1 软件过程的概念
16
2.1 软件过程的概念
• Basic Activities(基础活动)
– 问题定义，需求，设计，实b现， 软件验证，集成，软件演进/维护，退役
• Umbrella Activities (辅助性活动)
23
2.4 需求分析活动
• What
– 需求：主要是在产品构建之前确定的系统 必须符合的条件或具备的功能，它们是关 于系统将要完成什么工作的一段描述语句， 它们必须经过所有相关人员的认可，其目 的是彻底地解决客户的问题。
– 需求文档
• 一组需求的集合 • 用户需求文档、系统需求文档和软件规约文档
24
12
2.1 软件过程的概念
• 软件过程的定义
– 软件过程由开发或维护软件及其相关产品 的一系列活动构成，这些活动从不同的方 面定义了软件开发中的步骤、交付物、涉 众及其职责等流程要素
13
2.1 软件过程的概念
控制/约束
输入
Process
输出
资源
输入 需求
控制 预算,计划表,标准
Build the 输出 System 代码,文档
26
2.4 需求分析活动
• When
– 项目的早期阶段？
贯穿于整个软件开发过程的需求活动
27
2.4 需求分析活动
• Who
– 系统分析师、需求阐释者、客户代表、用户代表、 开发方领导、项目经理、架构设计师、领域专家、 财务人员、市场人员、软件质量保证（SQA， Software Quality Assure）人员、程序员、测试 人员、部署人员、技术文档编写人员、培训人员 等。
– 软件项目跟踪和控制，正式的技术复审， 软件质量保证，软件配置管理，文档编制， 复用管理，度量，风险管理，…
Something that covers or protects. 保护物覆盖或保护的事物17
2.2 问题定义活动
• What
– 问题定义是软件开发过程当中的一个定义 要解决的问题并确定系统范围的活动。
– (2)研究(1)中的方法 – 特点：粗糙
8
1.3 什么是软件工程
• Definition
– 软件工程是以质量为核心，为了经济地开 发满足客户需求的软件而研究、建立和应 用的系统化的、有规则的、可度量的和可 控制的工程原则、方法，涉及到软件过程、 项目管理、开发方法、软件复用、软件度 量、开发工具，甚至企业文化等各个方面。
[ 通过复审 ]
[ 未通过复审 ]
需求变更实现
do/ 修改需求文档 do/ 修改设计文档 do/ 修改测试用例 do/ 修改程序 exit/ 评估变更结果 who/系统分析师、需求阐释者、项目 经理、架构设计师、软件设计员、测试 人员、实施员、SQA人员、用户代表、 客户代表、财务人员、部署人员等
29
6
1.2 为什么要软件工程
• 采用什么方法缓解危机
– 硬件 ? – 建筑学? – 拍电影? – …… – 软件工程！
7
1.3 什么是软件工程
• Fritz Bauer:
– “建立和应用完善的工程原理以便经济地得 到在真实机器上可靠和有效运行的软件。
– 特点：重原理、轻技术、无度量
• IEEE：
– (1)应用系统的有规则的定量的方法开发、 使用和维护软件；即应用工程于软件。
• Why
– 形成一个早期判断，达成一个最初共识
• When
– 项目日程表的最前端 – 占整个软件开发时间中的比例很小
18
2.2 问题定义活动
• Who
– 系统分析师、出资方领导、出资方技术人 员、开发方领导和项目经理
• Where
– 客户现场
19
2.2 问题定义活动
• How
20
2.3 可行性研究活动
[ 更多迭代 ]
[ 需求定义完成 ]
需求变更请求
do/ 问题分析和变更描述 exit/ 提交需求变更申请 who/用户代表、客户代表、 系统分析员、需求阐释者等
需求变更处理
do/ 评估变更影响 do/ 预算变更成本 do/ 制定变更计划 do/ 审查 exit/ 发布审查结论 who/用户代表、客户代表、项目经理 、系统分析师、架构设计师、软件设 计员、开发方领导、财务人员等
• Where
– 建议在软件企业内部进行设计
35
2.5 设计活动
• How
架构设计早期
定义架构草案
entry/ 软件需求规约文档 do/ 定义多个备选架构草案 do/ 选择最优架构草案 exit/ 审查架构草案 who/架构设计师、软件设计员、项 目 经 理 、 SQA 人 员 、 财 务 人 员 等
• 详细设计地任务是在总体设计的基础上进一步 确定如何实现目标系统，包括系统的数据对象 的设计、人机接口的设计以及模块逻辑的详细 设计。
– 设计部件的粒度
• 系统、子系统、框架、构件、组件、模块、类、 方法等
32
2.5 设计活动
• Why
– 软件架构是软件系统的核心 – 应对复杂多变的情况，同时保持完整性 – 应对系统在扩展功能当中出现的问题 – 大规模复用的有效基础 – 项目管理的基础
项目模拟/实战训练 第一部分 软件工程
1
本讲内容
• 1 软件工程概述 • 2 软件工程过程和活动 • 3 软件过程模型 • 4 软件过程成熟度模型CMM
2
1 软件工程概述
• 1.1 软件的概念 • 1.2 为什么要软件工程 • 1.3 什么是软件工程 • 1.4 参考书目
3
1.1 软件的概念
• 定义
未通过审查
通过审查
[ 新的迭代或需求变更 ]
改进架构
do/ 考虑设计原则和架构模式 do/ 分析设计元素 do/ 分析元素间的关系和接口 exit/ 修改设计模型 who/架构设计师、复用工程师
选择可复用的框架或构件
entry/ 软件可复用资产库 do/ 查找符合条件的的框架和构件 do/ 选择适合的框架或构件 who/架构设计师、复用工程师、软件设计员
33
2.5 设计活动
• When
– 项目的中、早期阶段？
工作量
大
小 早期
中期
后期
贯穿于整个软件开发过程的设计活动
项目 时间
34
2.5 设计活动
• Who
– 主要包括架构设计师、软件设计员、复用 工程师、设计复审员、项目经理、财务人 员、软件质量保证（SQA，Software Quality Assure）人员和需求变更者等
2.5 设计活动
• What
– 设计：
• 是在系统的约束条件下（如预算、时间、人力 资源、用户软、硬件环境和用户对系统的操作 能力等），为了实现系统的功能性需求和非功 能性需求，而找到并描述的一种遵循高质量的 通用原则的方法，其交付文档能够指导开发人 员实现系统。
30
2.5 设计活动
– 总体设计
复审
do/ 审查需求文档 exit/ 发布审查结论 who/系统分析师、项目经理、客户代表、 用户代表、领域专家、SQA人员等
[ 未通过复审 ]
[ 通过复审 ]
管理系统规模
do/ 分析需求优先级、工作量和风险等属性 exit/ 修订系统开发计划 who/系统分析师、项目经理、领域专家、 SQA人员等
[ 找到合适的框架或构件 ]
[ 需要设计数据库 ]
[ 需要设计新的可 复用框架或构件 ]
设计可复用的 框架或构件
who/复用工程师、 软件设计员
[ 开发专 用构件 ] 设计专 用构件
who/ 构 件 设 计员
设计数 据库
who/ 数 据 库 设计员
修订设计说明书
do/ 修订设计说明书 exit/ 复审设计说明书 who/架构设计师、复用工程师、软件设计 员 、 项 目 经 理 、 SQA 人 员 、 财 务 人 员 等
[ 通过复审 ]
[ 未通过复审 ]
36
2.6 实施活动
• What
– 编码：是将软件设计结果转换成用某种程 序设计语言书写的程序。
– 单元测试：是把一个模块作为独立的程序 单元进行测试，以保证它能够正确执行规 定的功能。
– 集成：是指将单独的软件构件合并成一个 整体的软件系统。集成分为集成子系统和 集成系统两个级别：
– Program + Data Structure + Documents
• 软件的性质
– 复杂性 – 难以描述性 – 不可见性 – 变化性
– 易于副本的大批量生产 – 强合作性
4
1.2 为什么要软件工程
• 软件危机
Crisis！
– 爆发时间
• 1967年NATO的研究组首次提出
• 1968年NATO软件工程会议首次提出软件工程 概念
37
2.6 实施活动
• Why
– 以实施为中心的软件开发
• 弱化的需求 • 弱化的设计 • 对实施人员的过度依赖
38
2.6 实施活动
• Why
– 将单元测试作为实施的一部分
• When
– 项目的中、后期阶段
工作量
大
小 早期
中期
后期
贯穿于整个软件开发过程的实施活动
项目 时间
39
ቤተ መጻሕፍቲ ባይዱ
2.6 实施活动
• Who
9
1.3 什么是软件工程
CASE Tools Methods Process
A Quality Focus
10
1.4 软件工程参考书目
11
2 过程和活动
• 2.1 软件过程的概念 • 2.2 问题定义活动 • 2.3 可行性研究活动 • 2.4 需求分析活动 • 2.5 设计活动 • 2.6 实施活动 • 2.7 测试活动 • 2.8 部署活动
2.4 需求分析活动
• What
– 功能性需求和非功能性需求
• 功能性需求：描述了系统应该做什么，即具备 的功能或服务。（输入、输出和计算等）
• 非功能性需求：描述了系统必须遵守的约束条 件。（响应时间、吞吐量 、可靠性、可移植性、 可扩展性、易用性、安全性、资源要求、可复 用性、技术要求、文化和政策需求、法律需求、 道德要求、隐私要求，等等）
• How
网罗需求
entry/ 工作上下文范围 entry/ 领域知识和可重用的需求 do/ 获取涉众的原始需求 exit/ 建立原始需求记录 who/系统分析师、需求阐释者、 客户代表、用户等
定义系统
do/ 分析系统需求 exit/ 制定软件需求文档 exit/ 改进业务词汇表 who/系统分析师、需求阐释者等
• What
– 可行性研究是以相对短的时间和相对低的 成本来确定给定的问题在其约束条件内是 否有解、有几种解以及哪个是最佳解。
• Why
– 必须要先确立满足约束条件的方案是否存 在、是否可行、是否最优，然后再在最优 方案的基础上进行开发
21
2.3 可行性研究活动
• When
– 项目的早期阶段 – 占整个软件开发时间中的比例较小，但比问题定
• Where
– 调研时，在客户现场 – 编写软件需求规约文档时，可以在开发单位 – 复审相关的需求文档时，根据需要来安排
28
2.4
需求分析活动 启动需求
do/ 确定需求的涉众、范围、目标和限制条件 do/ 估算项目费用 exit/ 达成一致意见 who/系统分析师、项目经理、客户代表、开发方领 导、财务人员等
义活动所消耗的时间长
• Who
– 系统分析师、出资方领导、出资方技术人员、用 户代表、开发方领导、项目经理、架构设计师、 领域专家、财务人员、市场人员、软件质量保证 （SQA，Software Quality Assure）人员等
• Where
– 客户现场。 22
2.3 可行性研究活动
• How
• How
• 1968-2013, 近40多年
– “危机”一词
– 软件危机依然存在
5
1.2 为什么要软件工程
• 软件危机面对的问题
– 艺术 vs. 标准化 – 错误的发现 – 软件需求获取 – 软件支持和维护 – 开发速度 vs. 市场需求 – 开发周期过长、开发成本过高 – 研发风险 – 软件开发中的复杂的协作(人员,问题,过程) – 不同角色的软件神话(管理者,用户,开发者,大众)
• 是完整的、正确的、必要的、无歧义的、可行 的、可验证的以及被设置了优先级别的。
25
2.4 需求分析活动
• Why
– 需求不一致、模糊、矛盾 – 需求变更 – 客户忽略领域常识/知识/术语 – 客户集中于现有系统的不足之处，而忽略
了系统要实现的关键功能 – 零碎、无组织、不明确、表达不清 – 不分轻重缓急
• 根据软件需求规约文档，确定一个合理的软件 体系结构。这个体系结构包括合理地划分组成 系统的模块、模块间的调用关系以及模块间的 接口关系。软件体系结构还从总体方面决定了 系统的可扩充性、可维护性，以及系统的性能 等。总体设计的设计粒度较大，有时也被称为 概要设计、架构设计。
31
2.5 设计活动
– 详细设计
资源
人员,工具
14
2.1 软件过程的概念
What
Change
How
15
2.1 软件过程的概念
16
2.1 软件过程的概念
• Basic Activities(基础活动)
– 问题定义，需求，设计，实b现， 软件验证，集成，软件演进/维护，退役
• Umbrella Activities (辅助性活动)
23
2.4 需求分析活动
• What
– 需求：主要是在产品构建之前确定的系统 必须符合的条件或具备的功能，它们是关 于系统将要完成什么工作的一段描述语句， 它们必须经过所有相关人员的认可，其目 的是彻底地解决客户的问题。
– 需求文档
• 一组需求的集合 • 用户需求文档、系统需求文档和软件规约文档
24
12
2.1 软件过程的概念
• 软件过程的定义
– 软件过程由开发或维护软件及其相关产品 的一系列活动构成，这些活动从不同的方 面定义了软件开发中的步骤、交付物、涉 众及其职责等流程要素
13
2.1 软件过程的概念
控制/约束
输入
Process
输出
资源
输入 需求
控制 预算,计划表,标准
Build the 输出 System 代码,文档
26
2.4 需求分析活动
• When
– 项目的早期阶段？
贯穿于整个软件开发过程的需求活动
27
2.4 需求分析活动
• Who
– 系统分析师、需求阐释者、客户代表、用户代表、 开发方领导、项目经理、架构设计师、领域专家、 财务人员、市场人员、软件质量保证（SQA， Software Quality Assure）人员、程序员、测试 人员、部署人员、技术文档编写人员、培训人员 等。
– 软件项目跟踪和控制，正式的技术复审， 软件质量保证，软件配置管理，文档编制， 复用管理，度量，风险管理，…
Something that covers or protects. 保护物覆盖或保护的事物17
2.2 问题定义活动
• What
– 问题定义是软件开发过程当中的一个定义 要解决的问题并确定系统范围的活动。
– (2)研究(1)中的方法 – 特点：粗糙
8
1.3 什么是软件工程
• Definition
– 软件工程是以质量为核心，为了经济地开 发满足客户需求的软件而研究、建立和应 用的系统化的、有规则的、可度量的和可 控制的工程原则、方法，涉及到软件过程、 项目管理、开发方法、软件复用、软件度 量、开发工具，甚至企业文化等各个方面。
[ 通过复审 ]
[ 未通过复审 ]
需求变更实现
do/ 修改需求文档 do/ 修改设计文档 do/ 修改测试用例 do/ 修改程序 exit/ 评估变更结果 who/系统分析师、需求阐释者、项目 经理、架构设计师、软件设计员、测试 人员、实施员、SQA人员、用户代表、 客户代表、财务人员、部署人员等
29
6
1.2 为什么要软件工程
• 采用什么方法缓解危机
– 硬件 ? – 建筑学? – 拍电影? – …… – 软件工程！
7
1.3 什么是软件工程
• Fritz Bauer:
– “建立和应用完善的工程原理以便经济地得 到在真实机器上可靠和有效运行的软件。
– 特点：重原理、轻技术、无度量
• IEEE：
– (1)应用系统的有规则的定量的方法开发、 使用和维护软件；即应用工程于软件。
• Why
– 形成一个早期判断，达成一个最初共识
• When
– 项目日程表的最前端 – 占整个软件开发时间中的比例很小
18
2.2 问题定义活动
• Who
– 系统分析师、出资方领导、出资方技术人 员、开发方领导和项目经理
• Where
– 客户现场
19
2.2 问题定义活动
• How
20
2.3 可行性研究活动
[ 更多迭代 ]
[ 需求定义完成 ]
需求变更请求
do/ 问题分析和变更描述 exit/ 提交需求变更申请 who/用户代表、客户代表、 系统分析员、需求阐释者等
需求变更处理
do/ 评估变更影响 do/ 预算变更成本 do/ 制定变更计划 do/ 审查 exit/ 发布审查结论 who/用户代表、客户代表、项目经理 、系统分析师、架构设计师、软件设 计员、开发方领导、财务人员等
• Where
– 建议在软件企业内部进行设计
35
2.5 设计活动
• How
架构设计早期
定义架构草案
entry/ 软件需求规约文档 do/ 定义多个备选架构草案 do/ 选择最优架构草案 exit/ 审查架构草案 who/架构设计师、软件设计员、项 目 经 理 、 SQA 人 员 、 财 务 人 员 等
• 详细设计地任务是在总体设计的基础上进一步 确定如何实现目标系统，包括系统的数据对象 的设计、人机接口的设计以及模块逻辑的详细 设计。
– 设计部件的粒度
• 系统、子系统、框架、构件、组件、模块、类、 方法等
32
2.5 设计活动
• Why
– 软件架构是软件系统的核心 – 应对复杂多变的情况，同时保持完整性 – 应对系统在扩展功能当中出现的问题 – 大规模复用的有效基础 – 项目管理的基础
项目模拟/实战训练 第一部分 软件工程
1
本讲内容
• 1 软件工程概述 • 2 软件工程过程和活动 • 3 软件过程模型 • 4 软件过程成熟度模型CMM
2
1 软件工程概述
• 1.1 软件的概念 • 1.2 为什么要软件工程 • 1.3 什么是软件工程 • 1.4 参考书目
3
1.1 软件的概念
• 定义
未通过审查
通过审查
[ 新的迭代或需求变更 ]
改进架构
do/ 考虑设计原则和架构模式 do/ 分析设计元素 do/ 分析元素间的关系和接口 exit/ 修改设计模型 who/架构设计师、复用工程师
选择可复用的框架或构件
entry/ 软件可复用资产库 do/ 查找符合条件的的框架和构件 do/ 选择适合的框架或构件 who/架构设计师、复用工程师、软件设计员
33
2.5 设计活动
• When
– 项目的中、早期阶段？
工作量
大
小 早期
中期
后期
贯穿于整个软件开发过程的设计活动
项目 时间
34
2.5 设计活动
• Who
– 主要包括架构设计师、软件设计员、复用 工程师、设计复审员、项目经理、财务人 员、软件质量保证（SQA，Software Quality Assure）人员和需求变更者等
2.5 设计活动
• What
– 设计：
• 是在系统的约束条件下（如预算、时间、人力 资源、用户软、硬件环境和用户对系统的操作 能力等），为了实现系统的功能性需求和非功 能性需求，而找到并描述的一种遵循高质量的 通用原则的方法，其交付文档能够指导开发人 员实现系统。
30
2.5 设计活动
– 总体设计
复审
do/ 审查需求文档 exit/ 发布审查结论 who/系统分析师、项目经理、客户代表、 用户代表、领域专家、SQA人员等
[ 未通过复审 ]
[ 通过复审 ]
管理系统规模
do/ 分析需求优先级、工作量和风险等属性 exit/ 修订系统开发计划 who/系统分析师、项目经理、领域专家、 SQA人员等
[ 找到合适的框架或构件 ]
[ 需要设计数据库 ]
[ 需要设计新的可 复用框架或构件 ]
设计可复用的 框架或构件
who/复用工程师、 软件设计员
[ 开发专 用构件 ] 设计专 用构件
who/ 构 件 设 计员
设计数 据库
who/ 数 据 库 设计员
修订设计说明书
do/ 修订设计说明书 exit/ 复审设计说明书 who/架构设计师、复用工程师、软件设计 员 、 项 目 经 理 、 SQA 人 员 、 财 务 人 员 等
[ 通过复审 ]
[ 未通过复审 ]
36
2.6 实施活动
• What
– 编码：是将软件设计结果转换成用某种程 序设计语言书写的程序。
– 单元测试：是把一个模块作为独立的程序 单元进行测试，以保证它能够正确执行规 定的功能。
– 集成：是指将单独的软件构件合并成一个 整体的软件系统。集成分为集成子系统和 集成系统两个级别：
– Program + Data Structure + Documents
• 软件的性质
– 复杂性 – 难以描述性 – 不可见性 – 变化性
– 易于副本的大批量生产 – 强合作性
4
1.2 为什么要软件工程
• 软件危机
Crisis！
– 爆发时间
• 1967年NATO的研究组首次提出
• 1968年NATO软件工程会议首次提出软件工程 概念
37
2.6 实施活动
• Why
– 以实施为中心的软件开发
• 弱化的需求 • 弱化的设计 • 对实施人员的过度依赖
38
2.6 实施活动
• Why
– 将单元测试作为实施的一部分
• When
– 项目的中、后期阶段
工作量
大
小 早期
中期
后期
贯穿于整个软件开发过程的实施活动
项目 时间
39
ቤተ መጻሕፍቲ ባይዱ
2.6 实施活动
• Who
9
1.3 什么是软件工程
CASE Tools Methods Process
A Quality Focus
10
1.4 软件工程参考书目
11
2 过程和活动
• 2.1 软件过程的概念 • 2.2 问题定义活动 • 2.3 可行性研究活动 • 2.4 需求分析活动 • 2.5 设计活动 • 2.6 实施活动 • 2.7 测试活动 • 2.8 部署活动
2.4 需求分析活动
• What
– 功能性需求和非功能性需求
• 功能性需求：描述了系统应该做什么，即具备 的功能或服务。（输入、输出和计算等）
• 非功能性需求：描述了系统必须遵守的约束条 件。（响应时间、吞吐量 、可靠性、可移植性、 可扩展性、易用性、安全性、资源要求、可复 用性、技术要求、文化和政策需求、法律需求、 道德要求、隐私要求，等等）
• How
网罗需求
entry/ 工作上下文范围 entry/ 领域知识和可重用的需求 do/ 获取涉众的原始需求 exit/ 建立原始需求记录 who/系统分析师、需求阐释者、 客户代表、用户等
定义系统
do/ 分析系统需求 exit/ 制定软件需求文档 exit/ 改进业务词汇表 who/系统分析师、需求阐释者等
• What
– 可行性研究是以相对短的时间和相对低的 成本来确定给定的问题在其约束条件内是 否有解、有几种解以及哪个是最佳解。
• Why
– 必须要先确立满足约束条件的方案是否存 在、是否可行、是否最优，然后再在最优 方案的基础上进行开发
21
2.3 可行性研究活动
• When
– 项目的早期阶段 – 占整个软件开发时间中的比例较小，但比问题定
• Where
– 调研时，在客户现场 – 编写软件需求规约文档时，可以在开发单位 – 复审相关的需求文档时，根据需要来安排
28
2.4
需求分析活动 启动需求
do/ 确定需求的涉众、范围、目标和限制条件 do/ 估算项目费用 exit/ 达成一致意见 who/系统分析师、项目经理、客户代表、开发方领 导、财务人员等
义活动所消耗的时间长
• Who
– 系统分析师、出资方领导、出资方技术人员、用 户代表、开发方领导、项目经理、架构设计师、 领域专家、财务人员、市场人员、软件质量保证 （SQA，Software Quality Assure）人员等
• Where
– 客户现场。 22
2.3 可行性研究活动
• How
• How
• 1968-2013, 近40多年
– “危机”一词
– 软件危机依然存在
5
1.2 为什么要软件工程
• 软件危机面对的问题
– 艺术 vs. 标准化 – 错误的发现 – 软件需求获取 – 软件支持和维护 – 开发速度 vs. 市场需求 – 开发周期过长、开发成本过高 – 研发风险 – 软件开发中的复杂的协作(人员,问题,过程) – 不同角色的软件神话(管理者,用户,开发者,大众)