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