软件开发过程基础知识
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 扇出
– 指该模块（函数）直接调用的下级模块（函数）的个数。 – 扇出越大，代表模块的复杂度越高。 – 设计良好的系统平均扇出是3或4，上限不应超过7。
软件设计样例——概要设计
• 大学教务管理系统结构图
软件设计样例——详细设计
• 使用流程图描述的详设样例
编码——传统模式
• 传统瀑布模型或V模型中，软件编码阶段活动如下：
• 这种按时间分段的思想方法是软件工程的一个基 本原则，即按部就班、逐步推进。
软件生命周期模型——瀑布模型
• 特点：划分为明确的阶段，每个阶段工作全部完成后才能进入下一阶段。
需求分析 概要设计 详细设计 编码 单元测试 集成测试 系统测试
软件生命周期模型——V模型
• 特点：瀑布模型的变种，将测试计划和用例准备工作提前，可在早期 保证需求、设计的可测试性，促使分析、设计输出更清晰。
件中可以指一个窗口或一个菜单等。
• “驱动”模块（driver）和“桩”模块（stub）
– 驱动：进行环境的初始化，并调用被测函数 – 桩：模拟被测函数调用的其它函数
驱动
被测 函数
桩
桩
桩
单元测试——用例设计思路
• 黑盒法
– 根据函数的功能，对输入参数划分等价类来设计用例 – 例如Trim函数，功能是去掉字符串前后的空格，测试用例可以设计4
软件开发过程 基础知识
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
软件开发的发展历程
20世纪60年代 软件作坊
软件规模小，以个人、作坊式开发为主；
70年代
软件危机
硬件飞速发展，C、Pascal等高级编程语言
出现，软件规模和复杂度激增，引发软件 危机；
80年代
软件工程
按照详细 设计完成
编码
编译链接、 消除错误
及告警
静态检查， 消除错误
及告警
代码 review
• 代码评审的方式
– 正规检视（Formal Inspection）：对过程和参与角色有严格要求，包括 准备、预审、评审会议、第三小时会议、问题跟踪等阶段。适用于对代 码质量要求非常高的场景，如航空航天、国防领域。
软件需求描述方式（Use Case）
Use Case方式： 1. 描述：用一句话简要描述需求 2. 角色（Actor）：列出该条需求涉及 的角色（人、外部系统） 3. 前置条件：为保证该功能能正常执 行，需要的条件和假设 4. 触发因素：触发该功能的输入 5. 处理流程
5.1 基本事件流 步骤1： 步骤2：
个：前面有空格、后面有空格、前后均有空格、前后均无空格
• 白盒法
– 是对黑盒法设计的用例的补充，目的是保证测试对代码的覆盖程度 – 常用的覆盖要求
• 语句覆盖：所有语句都被执行到。参考目标：85%以上。 • 分支覆盖：又称为判定覆盖，使得程序中每个判断的取真分支和取假分
支至少经历一次。参考目标：100%。 • 路径覆盖：使程序的每条可能路径都至少执行一次。一般不做强制要求。
……
5.2 可选流程（正常情况下的分支） 3a. 步骤3的可选流程1 3a1.可选流程1步骤1 3a2.可选流程1步骤2 3b. 步骤3的可选流程2 3b1. 可选流程2步骤1 3b2. 可选流程2步骤2
5.3 异常事件流 4a. 步骤4 xx条件下异常流程 4a1. 异常流程步骤1 ……
6. 特殊要求 7. 后置条件 8. 备注
好需求的标准
软件设计
• 需求描述“做什么”，设计则是描述“怎么做”
• 软件设计包括概要设计、详细设计两个阶段，也可以将 这两个阶段合并为一个阶段。
– 概要设计：将完整的软件划分为模块，并确定模块间接口。常用 的方法有层次图、结构图等。
– 详细设计：定义函数/方法，并描述函数/方法的实现逻辑。常用 的方法有流程图、伪代码等。
软件需求分析
• 什么是需求？
需求 = 客户问题（Why） + 解决方案（What）
• 软件需求
需求：用户解决问题或达到目标所需的条件或能力 软件需求：软件系统或软件部件要满足合同、标准、规范或其它
正式规定文档所需具有的条件或能力 包括功能性需求与非功能性需求
• 软件需求描述方式
DFD数据流图、IPO、Use Case
可选事件流： 4A：
4a1．在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容 都不会影响网站首页的公告。
异常事件流： 4b：按“提交”按钮后网络通信错误；
4b1．提示通信故障，负责人确认； 4b2．返回到管理系统主页面，公告信息没有变动；
后置条件： 网站首页的公告信息被修改
需求描述样例—DFD
• SourceMonitor——圈复杂度、嵌套深度（衡量可维护性、 可测试性）
• Simian——重复代码（可维护性） • Coverity——静态分析+动态分析，安全性检查
• 推荐读物：马丁·福勒《重构---改善既有代码的设计》
代码圈复杂度
• 圈复杂度(Cyclomatic complexity)用来衡量一个模块判定结构的复杂程 度，数量上表现为线性无关的路径条数
障继续运行。常用的方法是软件故障注入测试（SFIT）。 – 易用性测试：检验用户在理解和使用系统方面是否方便。 – 兼容性测试：检验被测的应用系统对其他系统的兼容性。如操作系统、
浏览器等。
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
敏捷开发典型场景
① PO和开发团队对产品业务目标形成共识
90年代 软件过程控制
2001至今 敏捷开始流行
引入成熟工程管理理念与方法，提出“软 件工程”，分阶段来控制软件开发，一定 程度上缓解了软件危机；
软件市场日益扩大，失败的经验促使过程 持续优化与完善，CMM等过程模型广泛应 用；
随着互联网时代到来，“长尾效应”使得 需求的不确定性更强，短周期、轻量级的， 更能适应变化的敏捷软件开发方法被普遍 认可并迅速流行。
持续集成 单元测试
结对编程
对客户需求的反馈 对团队运作的反馈 对系统功能的反馈 对单元功能的反馈 对代码质量的反馈
需求描述样例—Use Case
用例名称： 网站公告发布
角色：
网站管理员
简要说明： 管理员用来填写和修改网站首页的公告，公告最终显示在网站的首页上。
前置条件： 管理员已经登录网站管理系统
基本事件流： 1． 负责人鼠标点击“修改公告”按钮； 2． 系统出现一个文本框，显示着原来的公告内容； 3． 负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告； 4． 负责人编辑完文本框，按“提交”按钮，首页公告被修改； 5． 用例终止；
⑤ 开发团队每日站立会议、特性开发、持 续集成，使开发进度真正透明
⑥ PO对每轮迭代（2－4周）交付的可工作 软件进行现场验收和反馈
⑦ 回到第3步，开始下一轮迭代
敏捷开发中的反馈及控制机制
• 敏捷开发的质量管控和反馈机制与V模型的思路其实是有 相似之处的，都是建立一个多层次的全面的质量防护网。
客户验收 站立会议/回顾会议
• 经验表明，程序的出错概率和圈复杂度有着很大关系。 • 建议标准：平均圈复杂度<5，最大圈复杂度<8 • 简单计算方法：平面被流程图划分成的区域数。如下图的例子，圈复
杂度为5。
编码——持续集成模式
• 持续集成模式下，软件编码活动与单元测试是穿插进行的：
本地 构建
建立本地 分支，完
成编码
编译、消 除错误及
项目计划
开工会
软件需求 分析
系统测 试计划
概要设计
集成测 试计划
详细设计
单元测 试计划
编码
发布 系统测试 集成测试 单元测试
软件生命模型——迭代模型
• 目的
– 更早地交付可工作的软件，适应变化
• 迭代开发模式的前提：架构有良好的可扩充性；测试自动化；
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
• 设计单元测试时，应先用黑盒法覆盖功能，再用白盒法补 充用例提升覆盖率
• 注意：覆盖率是手段不是目的！不要以追求覆盖率为目标。
集成测试
• 单元测试的对象是“单元”，集成测试的对象是单元之间 的“接口”，是一种“灰盒”测试
• 集成测试的策略
– Big Bang：不推荐 – 自顶向下：
• 从主控模块（主程序）开始，逐步往下集成 • 下层函数先用桩代替，然后逐步用实际函数替换
软件开发顺应时代变化，软件开发过程从无到有逐步完善，并不断优化
软件生命周期
• 软件生命周期（Software Life Cycle）又称为软件生 存周期，是软件从产生直到报废的整个过程。
• 完整的生命周期通常分为问题定义（需求分析）、 可行性分析、系统设计、编码、测试、验收与运 行、维护升级、废弃等多个阶段。
Story 开发
每日工作
⑤
② PO建立和维护产品需求列表（需求会不 断新增和改变）,并进行优先级排序
迭代计划
迭代
③ PO每轮迭代前，Review需求列表，并筛
迭代验收
⑥
选高优先级需求进入本轮迭代开发
④
确定一个迭代 的工作内容
③
回顾⑦
②ห้องสมุดไป่ตู้
产品和利
益相关人
①
④ 开发团队细化本轮迭代需求，并按照需 求的优先级，依次在本轮迭代完成
软件设计——基本原则
高内聚、低耦合 • 内聚：
– 模块内部各个元素彼此结合的紧密程度的度量。 – 高内聚是指一个软件模块是由相关性很强的代码组成，只负责一
项任务，也就是常说的单一责任原则。 – 内聚度由高到低：功能内聚、顺序内聚、信息内聚、通信内聚、
时间内聚、逻辑内聚、偶然内聚
• 耦合
– 指软件系统结构中各模块间相互联系紧密程度的一种度量。 – 低耦合：每个模块应尽可能的独立完成某个特定的子功能。模块
– 代码走读（Walkthrough）：过程相对简单，评审人员线下评审代码，再 集中确认问题；也可以采用结对交叉方式来评审；
敏捷开发中有没有代码评审？
常用代码分析检查工具
• inFusion、Structure101——分析代码结构，实际上是对设 计进行分析，可识别代码的坏味道（设计缺陷）
• PC-Lint、FindBugs、CheckStyle——代码静态检查，更严格 的语法扫描
告警
静态检查， 消除错误
及告警
自测（UT 及基本功 能测试）
检视通过的代码当 天提交到主线
代码检视 （可采用 结对方式）
版本 构建
从主线获 取代码
编译、静 态检查
自动化测 试
发送构建 报告
单元测试
• “单元”的定义：
– 人为规定的最小的被测功能模块。 – 通常C语言中单元指一个函数，Java里单元指一个类，图形化的软
与模块之间的接口尽量少而简单。 – 耦合度由低到高：非直接耦合、数据耦合、标记耦合、控制耦合、
外部耦合、公共耦合、内容耦合
软件设计——基本原则
• 高扇入、低扇出
– 扇入扇出体现了模块的复用程度和复杂度
• 扇入
– 指直接调用该模块（函数）的上级模块（函数）的个数 – 扇入越大，代表模块的复用程度越高。
• 系统测试方法
– 功能测试：根据产品的需求规格说明和测试需求列表，验证产品是否符 合需求规格说明。
– 性能测试：量度系统的性能是否达到预先定义的目标。 – 压力测试：是在各种超负荷的情况下观察系统的运行情况的测试。 – 容量测试：在系统正常运行的范围内测试并确定系统能够处理的数据容
量。 – 安全性测试：验证系统的保护机制是否抵御入侵者的攻击。 – 健壮性测试：用于测试系统在出故障时，是否能够自动恢复或者忽略故
– 自底向上
• 从最底层函数开始，逐步往上集成 • 上层函数先用驱动代替，然后逐步用实际函数替换
• 在对代码可靠性要求不是很高的情况下，单元测试可以和 集成测试结合起来，可以减少驱动和桩的开发工作量
系统测试
• 定义
– 顾名思义，是对整个系统的测试。系统测试是一种黑盒测试。 – 系统测试的目的是验证最终软件系统是否满足用户规定的需求。
– 指该模块（函数）直接调用的下级模块（函数）的个数。 – 扇出越大，代表模块的复杂度越高。 – 设计良好的系统平均扇出是3或4，上限不应超过7。
软件设计样例——概要设计
• 大学教务管理系统结构图
软件设计样例——详细设计
• 使用流程图描述的详设样例
编码——传统模式
• 传统瀑布模型或V模型中，软件编码阶段活动如下：
• 这种按时间分段的思想方法是软件工程的一个基 本原则，即按部就班、逐步推进。
软件生命周期模型——瀑布模型
• 特点：划分为明确的阶段，每个阶段工作全部完成后才能进入下一阶段。
需求分析 概要设计 详细设计 编码 单元测试 集成测试 系统测试
软件生命周期模型——V模型
• 特点：瀑布模型的变种，将测试计划和用例准备工作提前，可在早期 保证需求、设计的可测试性，促使分析、设计输出更清晰。
件中可以指一个窗口或一个菜单等。
• “驱动”模块（driver）和“桩”模块（stub）
– 驱动：进行环境的初始化，并调用被测函数 – 桩：模拟被测函数调用的其它函数
驱动
被测 函数
桩
桩
桩
单元测试——用例设计思路
• 黑盒法
– 根据函数的功能，对输入参数划分等价类来设计用例 – 例如Trim函数，功能是去掉字符串前后的空格，测试用例可以设计4
软件开发过程 基础知识
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
软件开发的发展历程
20世纪60年代 软件作坊
软件规模小，以个人、作坊式开发为主；
70年代
软件危机
硬件飞速发展，C、Pascal等高级编程语言
出现，软件规模和复杂度激增，引发软件 危机；
80年代
软件工程
按照详细 设计完成
编码
编译链接、 消除错误
及告警
静态检查， 消除错误
及告警
代码 review
• 代码评审的方式
– 正规检视（Formal Inspection）：对过程和参与角色有严格要求，包括 准备、预审、评审会议、第三小时会议、问题跟踪等阶段。适用于对代 码质量要求非常高的场景，如航空航天、国防领域。
软件需求描述方式（Use Case）
Use Case方式： 1. 描述：用一句话简要描述需求 2. 角色（Actor）：列出该条需求涉及 的角色（人、外部系统） 3. 前置条件：为保证该功能能正常执 行，需要的条件和假设 4. 触发因素：触发该功能的输入 5. 处理流程
5.1 基本事件流 步骤1： 步骤2：
个：前面有空格、后面有空格、前后均有空格、前后均无空格
• 白盒法
– 是对黑盒法设计的用例的补充，目的是保证测试对代码的覆盖程度 – 常用的覆盖要求
• 语句覆盖：所有语句都被执行到。参考目标：85%以上。 • 分支覆盖：又称为判定覆盖，使得程序中每个判断的取真分支和取假分
支至少经历一次。参考目标：100%。 • 路径覆盖：使程序的每条可能路径都至少执行一次。一般不做强制要求。
……
5.2 可选流程（正常情况下的分支） 3a. 步骤3的可选流程1 3a1.可选流程1步骤1 3a2.可选流程1步骤2 3b. 步骤3的可选流程2 3b1. 可选流程2步骤1 3b2. 可选流程2步骤2
5.3 异常事件流 4a. 步骤4 xx条件下异常流程 4a1. 异常流程步骤1 ……
6. 特殊要求 7. 后置条件 8. 备注
好需求的标准
软件设计
• 需求描述“做什么”，设计则是描述“怎么做”
• 软件设计包括概要设计、详细设计两个阶段，也可以将 这两个阶段合并为一个阶段。
– 概要设计：将完整的软件划分为模块，并确定模块间接口。常用 的方法有层次图、结构图等。
– 详细设计：定义函数/方法，并描述函数/方法的实现逻辑。常用 的方法有流程图、伪代码等。
软件需求分析
• 什么是需求？
需求 = 客户问题（Why） + 解决方案（What）
• 软件需求
需求：用户解决问题或达到目标所需的条件或能力 软件需求：软件系统或软件部件要满足合同、标准、规范或其它
正式规定文档所需具有的条件或能力 包括功能性需求与非功能性需求
• 软件需求描述方式
DFD数据流图、IPO、Use Case
可选事件流： 4A：
4a1．在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容 都不会影响网站首页的公告。
异常事件流： 4b：按“提交”按钮后网络通信错误；
4b1．提示通信故障，负责人确认； 4b2．返回到管理系统主页面，公告信息没有变动；
后置条件： 网站首页的公告信息被修改
需求描述样例—DFD
• SourceMonitor——圈复杂度、嵌套深度（衡量可维护性、 可测试性）
• Simian——重复代码（可维护性） • Coverity——静态分析+动态分析，安全性检查
• 推荐读物：马丁·福勒《重构---改善既有代码的设计》
代码圈复杂度
• 圈复杂度(Cyclomatic complexity)用来衡量一个模块判定结构的复杂程 度，数量上表现为线性无关的路径条数
障继续运行。常用的方法是软件故障注入测试（SFIT）。 – 易用性测试：检验用户在理解和使用系统方面是否方便。 – 兼容性测试：检验被测的应用系统对其他系统的兼容性。如操作系统、
浏览器等。
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
敏捷开发典型场景
① PO和开发团队对产品业务目标形成共识
90年代 软件过程控制
2001至今 敏捷开始流行
引入成熟工程管理理念与方法，提出“软 件工程”，分阶段来控制软件开发，一定 程度上缓解了软件危机；
软件市场日益扩大，失败的经验促使过程 持续优化与完善，CMM等过程模型广泛应 用；
随着互联网时代到来，“长尾效应”使得 需求的不确定性更强，短周期、轻量级的， 更能适应变化的敏捷软件开发方法被普遍 认可并迅速流行。
持续集成 单元测试
结对编程
对客户需求的反馈 对团队运作的反馈 对系统功能的反馈 对单元功能的反馈 对代码质量的反馈
需求描述样例—Use Case
用例名称： 网站公告发布
角色：
网站管理员
简要说明： 管理员用来填写和修改网站首页的公告，公告最终显示在网站的首页上。
前置条件： 管理员已经登录网站管理系统
基本事件流： 1． 负责人鼠标点击“修改公告”按钮； 2． 系统出现一个文本框，显示着原来的公告内容； 3． 负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告； 4． 负责人编辑完文本框，按“提交”按钮，首页公告被修改； 5． 用例终止；
⑤ 开发团队每日站立会议、特性开发、持 续集成，使开发进度真正透明
⑥ PO对每轮迭代（2－4周）交付的可工作 软件进行现场验收和反馈
⑦ 回到第3步，开始下一轮迭代
敏捷开发中的反馈及控制机制
• 敏捷开发的质量管控和反馈机制与V模型的思路其实是有 相似之处的，都是建立一个多层次的全面的质量防护网。
客户验收 站立会议/回顾会议
• 经验表明，程序的出错概率和圈复杂度有着很大关系。 • 建议标准：平均圈复杂度<5，最大圈复杂度<8 • 简单计算方法：平面被流程图划分成的区域数。如下图的例子，圈复
杂度为5。
编码——持续集成模式
• 持续集成模式下，软件编码活动与单元测试是穿插进行的：
本地 构建
建立本地 分支，完
成编码
编译、消 除错误及
项目计划
开工会
软件需求 分析
系统测 试计划
概要设计
集成测 试计划
详细设计
单元测 试计划
编码
发布 系统测试 集成测试 单元测试
软件生命模型——迭代模型
• 目的
– 更早地交付可工作的软件，适应变化
• 迭代开发模式的前提：架构有良好的可扩充性；测试自动化；
目录
• 软件开发生命周期介绍 • 软件开发各阶段简介 • 敏捷开发模式简介
• 设计单元测试时，应先用黑盒法覆盖功能，再用白盒法补 充用例提升覆盖率
• 注意：覆盖率是手段不是目的！不要以追求覆盖率为目标。
集成测试
• 单元测试的对象是“单元”，集成测试的对象是单元之间 的“接口”，是一种“灰盒”测试
• 集成测试的策略
– Big Bang：不推荐 – 自顶向下：
• 从主控模块（主程序）开始，逐步往下集成 • 下层函数先用桩代替，然后逐步用实际函数替换
软件开发顺应时代变化，软件开发过程从无到有逐步完善，并不断优化
软件生命周期
• 软件生命周期（Software Life Cycle）又称为软件生 存周期，是软件从产生直到报废的整个过程。
• 完整的生命周期通常分为问题定义（需求分析）、 可行性分析、系统设计、编码、测试、验收与运 行、维护升级、废弃等多个阶段。
Story 开发
每日工作
⑤
② PO建立和维护产品需求列表（需求会不 断新增和改变）,并进行优先级排序
迭代计划
迭代
③ PO每轮迭代前，Review需求列表，并筛
迭代验收
⑥
选高优先级需求进入本轮迭代开发
④
确定一个迭代 的工作内容
③
回顾⑦
②ห้องสมุดไป่ตู้
产品和利
益相关人
①
④ 开发团队细化本轮迭代需求，并按照需 求的优先级，依次在本轮迭代完成
软件设计——基本原则
高内聚、低耦合 • 内聚：
– 模块内部各个元素彼此结合的紧密程度的度量。 – 高内聚是指一个软件模块是由相关性很强的代码组成，只负责一
项任务，也就是常说的单一责任原则。 – 内聚度由高到低：功能内聚、顺序内聚、信息内聚、通信内聚、
时间内聚、逻辑内聚、偶然内聚
• 耦合
– 指软件系统结构中各模块间相互联系紧密程度的一种度量。 – 低耦合：每个模块应尽可能的独立完成某个特定的子功能。模块
– 代码走读（Walkthrough）：过程相对简单，评审人员线下评审代码，再 集中确认问题；也可以采用结对交叉方式来评审；
敏捷开发中有没有代码评审？
常用代码分析检查工具
• inFusion、Structure101——分析代码结构，实际上是对设 计进行分析，可识别代码的坏味道（设计缺陷）
• PC-Lint、FindBugs、CheckStyle——代码静态检查，更严格 的语法扫描
告警
静态检查， 消除错误
及告警
自测（UT 及基本功 能测试）
检视通过的代码当 天提交到主线
代码检视 （可采用 结对方式）
版本 构建
从主线获 取代码
编译、静 态检查
自动化测 试
发送构建 报告
单元测试
• “单元”的定义：
– 人为规定的最小的被测功能模块。 – 通常C语言中单元指一个函数，Java里单元指一个类，图形化的软
与模块之间的接口尽量少而简单。 – 耦合度由低到高：非直接耦合、数据耦合、标记耦合、控制耦合、
外部耦合、公共耦合、内容耦合
软件设计——基本原则
• 高扇入、低扇出
– 扇入扇出体现了模块的复用程度和复杂度
• 扇入
– 指直接调用该模块（函数）的上级模块（函数）的个数 – 扇入越大，代表模块的复用程度越高。
• 系统测试方法
– 功能测试：根据产品的需求规格说明和测试需求列表，验证产品是否符 合需求规格说明。
– 性能测试：量度系统的性能是否达到预先定义的目标。 – 压力测试：是在各种超负荷的情况下观察系统的运行情况的测试。 – 容量测试：在系统正常运行的范围内测试并确定系统能够处理的数据容
量。 – 安全性测试：验证系统的保护机制是否抵御入侵者的攻击。 – 健壮性测试：用于测试系统在出故障时，是否能够自动恢复或者忽略故
– 自底向上
• 从最底层函数开始，逐步往上集成 • 上层函数先用驱动代替，然后逐步用实际函数替换
• 在对代码可靠性要求不是很高的情况下，单元测试可以和 集成测试结合起来，可以减少驱动和桩的开发工作量
系统测试
• 定义
– 顾名思义，是对整个系统的测试。系统测试是一种黑盒测试。 – 系统测试的目的是验证最终软件系统是否满足用户规定的需求。