《软件工程》整理

目录

Scrum开发

概念

---

scrum开发流程

Scrum开发

• 需求获取（拆分）

1. DevOps Server的CMMI模型对需求的层级划分，Epic（长篇故事）、Feature（特性）、Requirement（需求）
2. 其中：长篇故事和特性放在组织积压层级，可以划分到不同的冲刺、团队来完成；需求只能放在一个团队的某一个冲刺中来完成；Bug可以通过配置，以确定其为冲刺的积压工作项还是任务

• 根据产品的复杂度、规模，可以使用三级方式来管理需求，也可以使用二级来管理需求；通常不建议只有列表不分级进行管理

• 积压项梳理

Backlog梳理：是在下个冲刺开始前，对可能要纳入到冲刺中的故事 / 需求进行细化、估算和优先级排序

• PO主导，团队以及任何相关利益相关者或专家都参与其中
• 可以让团队成员了解即将到来的特性、用户故事 / 需求，并提供反馈、建议、想法
• PBI梳理

优点：如果没有Backlog梳理，Sprint计划会议往往严重超时，引入Backlog梳理活动，Sprint计划会议往往能够控制在预计的时间内结束

---

PBI梳理过程：

1. PO和开发团队一起讨论 Product Backlog Item(PBI) 的 背景、业务目标、用户角色、用户场景、业务流程、业务规则，保 证团队理解充分并且PO和开发团队一起讨论界面和交互流程
2. PO和开发团队讨论 PBI 的测试要点、技术实现方案、可 能存在的技术风险，必须输出测试要点 
3. 开发团队估算规模，对于过大的 PBI 要拆分成小的 
4. PO对PBI排优先级

特点：这是一个持续进行的过程、PO可以随时更新PBI

• 规模估算

Scrum估算是由一组类似斐波纳契数列的数字组成，0、0.5、1、2、3、5、8、20、40、？、∞，可以使用估算扑克或类似的小工具来支持完成估算

扑克使用斐波那契数列的原因：便于大的任务向小的任务拆分

估算的是大小，而不是时间，使用相对估算，而不是绝对估算

记录每个Sprint的团队速度，为以后计划做参考（借鉴历史数据）

• 冲刺速度

时间：sprint开始前

步骤：

1. 计算开发人员的可用时间（一周几个工作日），设置在冲刺期间的可用容量中
2. 详细估计第一个用户故事
3. 分解团队需要做什么来发布该用户故事
4. 估计每项活动的时间并总结
5. 从团队在冲刺中的可用时间中扣除总结
6. 还有时间吗？
   有，就获取一个新的用户故事，重复该过程，直到没有剩余时间
7. 总结sprint中包含的故事的故事点数

• 发布预测

将这次sprint预测的规模、速度、目标进行统一发布

• 冲刺计划会议

时间：Sprint的第一天

目的：计划当前Sprint要做的工作

时长：2小时 × Sprint周数（1-4周）

与会人员：PO（必须）、开发团队（必须）、SM（可选）——建议参加

会议议程：

1. 确定当前Sprint要完成哪些功能（做什么）
2. 确定如何完成这些功能（怎么做）

会议结果：Sprint目标确立，Sprint Backlog产生，团队承诺完成Sprint目标

• 冲刺评审会议

目的：检视完成完成的产品增量是否符合用户的预期，收集反馈以便调整

时间： Sprint的最后一天

时长：一般不超过4小时

与会人员： PO（必须），开发团队（必须），SM（可选），用户（可选）

会议议程：

1. PO总结当前Sprint的完成情况，即说明哪些产品待办列表项已经“完成”和哪些没有“完成”
2. 团队演示已“完成”的功能并解答用户提出的问题
3. 用户提出反馈，并和PO讨论对Product Backlog的调整

会议结果： 修订后的Product Backlog，并阐明可能进入下个Sprint的功能

---

标题 - 填写是哪个评审，比如：立项评审、代码评审、冲刺评审等

指派 - 这个评审是由谁来牵头负责，就指派给谁

组员认真阅读评审资料后，在相关工作中，添加链接类型为“相关”、工作项类型为“问题” ，进行问题的反映

• 冲刺回顾会议

目的：Scrum团队检视自身并创建下一个Sprint改进计划的机会。

时间： Sprint评审会之后

时长：一般不超过4小时

与会人员： PO（可选），开发团队（必须），SM（可选）

会议议程：

1. 团队回顾Sprint的过程，找出做的好的方面和需要改进的方面。
2. 对需要改进的方面进行优先级排序。
3. 选择优先级高的事项，制定改进计划。

会议结果： 改进计划

• 设计编码

编写《系统设计说明书》，统一编码风格

• 测试

使用DevOps Server进行测试的时候，主要分3大块，即：测试用例、测试套件、测试计划

三者的关系为：测试计划 > 测试套件 > 测试用例

1. 测试用例：这是测试的最小单位，包括测试的具体内容、步骤、测试结果
2. 测试套件：使用测试套件对测试用例进行分组，一般一个需求会有很多个测试用例，因为测试用例包含了正向测试、逆向测试、边界测试等
3. 测试计划：测试也是需要有计划，可以一个测试计划对应一个冲刺

例如：第二个冲刺，需要测试22个套件，里面包含了127条测试用例

• 配置管理

Azure DevOps支持两种版本控制模式，一种是中央控制系统TFVC；另一种是分布式控制系统，即Git模式

支持从GitHub导入一个Git库到Azure DevOps Server，导入过程异步，在完成之后会邮件给通知

• git命令分类

1. git库创建
2. 增加、删除文件：add、rm
3. 代码提交：commit
4. 分支：branch
5. 状态
6. 标签（较少使用）
7. 同步：拉取、推送
8. 其他

• git操作具体示例

本地库与远端相连接：

第一种：新建git库，连接远端的一个git库

git init//初始化本地仓库
git remote add [name] [url]//可以为你的url取一个名字，后面的[remote]都可以用这个名字

第二种：如果远端已有仓库

git clone [url]//第一次拉取用clone，以后都用pull，克隆版本库的时候，所使用的远程主机自动被Git命名为origin。如果想用其他的主机名，可以用git clone命令的-o选项指定

---

 拉取文件 -> 本地修改文件后commit -> 把文件放入暂存区 -> （显示修改信息） -> 推送

git pull [remote] [branch]//拉取远程仓库的变化并和本地分支合并
git add <file>//先把文件放到暂存区，使用git add . 是提交当前文件夹下的全部
git commit -v//显示所有信息
git commit -m "info"//提交，但文件还没推送到远端
git push [remote] [branch]//推送到远端

---

创建分支：1.平台创建 2.本地创建

本地创建分支 -> 切换工作区 -> 分支推送远端

git branch [branch]//本地创建分支，但仍停留在原分支
git checkout [branch]//切换工作区
git branch -a//显示所有远程和本地的分支
git push [remote] [branch]//分支推送远端

---

分支合并：

 切换回主分支 -> 拉取最新的主分支 -> 分支合并 -> 推送

git checkout master//切换到主分支
git pull [remote] master//拉取最新的主分支，由于协同工作，主分支内容可能会被团队他人修改
git merge [branch]
git push [remote] master

概念

• 什么是软件工程?什么是软件，它的特点是什么，跟硬件有何差别?软件工程方法有哪些？

软件工程是用工程科学的方法来定义、开发、维护计算机软件的有关技术和管理方法

软件包含计算机程序、规程、文档和软件系统运行所必需的数据四个部分

软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等

• 什么是需求分析？需求分析有哪几种方法？

经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程

三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法

• 三个时期，九个阶段

软件定义、软件开发、软件运行维护

问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试、软件维护、退役

• 生存周期模型有哪几个，特点及差异

瀑布模型：理想化、只有到最后才能看到开发成果（风险大）、不适应用户需求的变化

增量模型

演化模型：需求不清晰，很难一次开发成果

快速原型模型

• 研发团队包含哪些角色，做什么事情?

• 需求分析：需求规格说明书，怎么样去做需求，用哪些方法?

需求分析步骤：

获取用户需求 -> 分析用户需求 -> 编写需求文档SRS -> 评审需求文档 -> 管理需求变更

方法：获取用户需求（有功能性、非功能性）：与用户交流；大规模市场调查；聘请行业专家；借助网络等。

需求分析方法：

1.面向结构分析法 2.面向对象分析法 3.快速原型分析法。

• SRS是什么

软件需求规格说明书

• 什么是uml,uml九张图

uml是一种通用可视化建模语言，用来对软件密集型系统可视化、详述、构造和文档化 

九张图：用例图，类图，对象图，活动图，顺序图，协作图，状态图，构建图，实施图

• 什么是静态图，动态图，怎么区分

静态图：描述系统的元素及元素间的关系。类图，对象图，构建图，实施图

动态图：描述系统随时间发展的行为。活动图，顺序图，协作图，状态图

• uml图放到软工设计中如何规划？

需求分析：用例图表示客户的需求

分析：考虑所要解决的问题，类图描述系统的静态结构，动态图描述系统的动态特征

设计：把分析阶段的结果扩展成技术解决方案

构造：把设计阶段的类转换成代码

测试：不同的测试小组使用不同的UML图作为他们工作的基础。 单元测试使用类图和类的规格说明，集成测试使用组件图和协作图，而系统测试使用用例图来确认系统的行为是否符合这些图中的定义

• Scm软件配置管理

Scm：软件配置管理，是一种标识、 组织和控制修改的技术

目标：为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更，使错误降为最小并最有效地提高生产效率

包含哪几部分：配置管理计划制定，版本管理，确定配置项标识规则，变更管理，发布管理，工作空间管理，报告配置状态 

• 什么是cmmi，五个等级是什么，从最低级到最高级，字与顺序不可错

软件能力成熟度模型

第1级：初始级
第2级：可重复级
第3级：已定义级
第4级：已管理级
第5级：优化级

• 什么是SPI

英文Software Process Improvement的缩写，中文意思是软件过程的改进

• 概要设计包含哪些内容，完成什么内容

系统构架、模块划分、系统接口、数据设计4个主要方面的内容

• 软件测试，白盒和黑盒方法，什么作用

黑盒测试：不深入代码细节的测试方法称为黑盒测试，软件测试员充当客户来使用它

白盒测试：已知程序的内部工作过程，对它的每种内部操作进行测试，看是否符合设计要求，称为白盒测试

黑盒测试和白盒测试的区别：前者基于功能，后者基于结构

黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试

白盒测试是根据程序内部逻辑结构进行测试

• 单元测试系统测试几个环节，有什么区别

• 软件测试用到了哪些基本准则，依据什么

1. 所有的测试都应追溯用户需求；
2. 尽早并不断进行测试；
3. 穷举测试是不可能的；
4. 由独立的第三方来构造测试。(开发和测试队伍分别建立)
5. 兼顾合理的输入和不合理的输入数据。
6. 程序修改后要回归测试。
7. 应长期保留测试用例，直至系统废弃。

• 如何写测试用例，包含哪些内容

测试用的一组数据（内容、步骤、测试结果）

• 常用估算方法，主要估算什么东西，包含哪些内容

三点统计方法：产生一个三点或期望值估算，建立关于 规模的乐观值、可能值、悲观值。EV=(Sopt+4Sm +Spess)/6 ，Sopt 乐观值； Sm 可能值； Spess 悲观值； EV(expected value) 期望值。

面向规模的估算法（LOC法）

类比法

面向功能的估算法（FP法）

面向用例的估算法（ucp法）

基于过程的估算——自顶向下法

基于过程的估算——自底向上法

• Delphi估算法和UCP估算法是什么，有什么区别

Deliphi估算

UCP：面向用例， UCP = 交易的UCP数 + Actor的UCP数

• 给一个用例，进行估算

书P140

• 维保包含哪些工作