软件工程课程-记背

教材参考的是 杭州电子科技大学信息工程学院《软件工程》

1.1 git命令

1.2 第一章当中的生命周期一共是几个阶段，每个阶段什么内容，做什么事情？

（图中是在瀑布模型的基础上增加了项目管理的相关过程和实践）
在典型的瀑布型生命周期模型中有如下六个阶段。P28
①　问题的定义及其描述
②　需求分析
③　软件设计
④　程序编写
⑤　软件测试
⑥　运行维护

1.3 什么是软件工程，什么是软件？与硬件之间的区别？P25

软件：是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。
软件特征：
①　只能开发:软件是开发产生的，而不是用传统方法制造出来的
②　无磨损:软件不会像硬件一样有磨损；软件只会过时，不会磨损。
③　不能组装:很多软件不能通过已有构件组装，只能自己定义开发。
④　软件具有复杂性、一致性、可变性和不可见性等固有的内在特性
软件工程：软件工程是用工程科学和数学的原则与方法来定义、开发、维护计算机软件的有关技术和管理方法。
他们有什么区别：
① 软件是逻辑产品而不是实物产品
② 软件的功能依赖于硬件和软件的运行环境，以及人们对它的操作
③ 软件设计的复杂性
④ 智力密集及知识产权保护
⑤ 硬件是看的见摸得着的物理设备或部件。

1.4 什么是CMMI？把中文英文的都写出来。P22

CMMI：软件能力成熟度模型（Capability Maturity Model Integration)

1.5 CMMI的五个级别？12345哪五个级别，里面的内容是什么？P25

第0级--不完整：无计划则未知，可能可以或无法完成工作；
第1级--初步：不可预测且被动，完成工作，但通常会延期且超预算；
第2级--管理级：实施项目管理，项目得到规划、执行、度量和控制；
第3级--定义级：主动而不是被动，组织标准为项目、计划和投资组合提供了指导；
第4级--量化管理级：可衡量且可控制，组织以数据为导向提出量化的性能改进目标，这些目标是可预测且一致的，可以满足内部和外部利益相关方的需求；
第5级--优化级：稳定且灵活，组织专注于持续改进，并致力于转变和应对机遇与变化，组织的稳定性为敏捷和创新提供了一个平台。

1.6 什么是瀑布模型？

1.7 敏捷开发Scrum的标准框架是什么，图再仔细看一下。P37

Scrum标准框架

1.8 Scrum、CMMI、DevOps、agile分别代表什么意思？（这个简单意思，全称写出来就好了）

Scrum：敏捷开发的方式
CMMI：软件能力成熟度模型
Devops：Development、Operrations是一组过程、方法与系统的统称。
Agile：敏捷开发管理

1.9 立项启动阶段基本需要提交什么材料？P49 P81

《立项报告》、 《立项可行性分析报告》、BRD（商业需求文档）、《项目任务书》

1.10 Scrum模型当中有几个角色？每个角色的职责是什么，做什么事情？P60

–产品负责人（PO），职责是将开发团队开发的产品价值最大化，负责管理产品待办列表，并对其清晰地表达、对其进行排序，确保团队对产品待办列表项有足够深的了解。
– Scrum Master，对团队而言是一位服务型领导，保证大家能顺利进行冲刺，实现价值的最大化，并与其他Scrum Master一起工作。
– 开发团队，负责在每个Sprint结束时交付潜在可发布并且“完成”产品的增量；是自组织的，是跨职能的，每个成员可以有特长和专注的领域。

1.11 什么是积压项？

积压项：是可以在单个冲刺中交付的东西。

1.12 什么是冲刺Sprint？

冲刺：选定的需求被添加到迭代积压中，称为一个冲刺。

1.13 Scrum构架（框架）当中有几个比较重要的活动，敏捷开发的活动是哪些，一是角色，有什么样的活动，有五个事件，分别是哪几个事件，角色是什么，角色的职责是什么，角色是完成哪些事情的。P37

一个是哪些关键角色，一个是哪五个事件？关键角色见1.22
事件：冲刺计划会议、每日Scrum站会、冲刺评审会议、冲刺回顾会议、冲刺

1.14 需求的获取有哪几种方式？P94

技术演示、临时项目评审
问卷调查、访谈、场景（操作、维护和开发）
演练、与利益相关方进行质量属性抽取研究会
原型和模型、头脑风暴
市场调查、Beta测试
从文档、标准或规范等来源中提取
观察现在的解决方案、环境和工作流模式
用例、业务案例分析、用户的招标文件
逆向工程（针对旧的解决方案）
客户满意度调查、观点分析

1.15 在Scrum模型当中，对需求的层次划分是怎么样的？P97

长篇故事、特性、产品积压项（-》需求 cmmi）

1.16 Scrum开发团队有哪些特点，相比于以前的开发团队他有哪些特点？特点是什么？我们现在的Scrum团队的特点是什么？追求的是什么样的目标？P60 P38 P64

Scrum团队是跨职能的自组织团队，团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。
目标：在短时间内创造高价值的产品

1.17 在我们这个Scrum当中，这个层次是怎么样的？从最早开始是长篇故事。

– 在采用三级进行需求层次划分的产品里，通常是把长篇故事和特性放在组织级的积压层次，这两类工作项可以划分到不同的冲刺、团队来完成。
– 最后一级的产品积压工作项/用户情景/需求（后续统一称之为产品积压工作项或待办事项）则只能放在一个团队的某一个冲刺里来完成。

1.18 有几种估算的方法？估算的内容有哪些，需要对哪些内容进行估算？P133

估算方法

• 常用的估算方法：
  ①　Delphi、PERT（任务单元工期估计）
  ②　- 工作量估算模型：COCOMOII
  ③　- 基于类比的估算：借鉴历史项目数据
  ④　- 规模估算方法：LOC（代码行）、FPA（功能点）、UCP（用例点）
  估算的内容：软件工作产品的规模，软件项目的工作量，软件项目的成本，软件项目的进度，以及项目所需要的人员、计算机、工具、设备等资源。

1.19 对积压项进行梳理，主要是什么样的作用？P103

– 细化产品待办事项列表项 (Product Backlog Items)需求；
– 估算产品待办事项列表项；
– 对产品待办事项列表项进行优先级排序；
– 干系人提问和讨论。

1.21 冲刺积压项和积压项有什么区别？和产品积压项之间有什么区别？

冲刺积压项：由团队创建，持续时间为1个sprint，每天更新。
产品积压项：有产品所有者进行管理，持续时间为整个项目，每周更新

1.22 冲刺过程中有一个每日站会、一个是冲刺的评审、冲刺的最后回顾这三个事件发生的时候，一般用时需要多少时间。整个冲刺一般多少时间之内，为什么？每个事件参加的角色是哪些？每日站会、评审、冲刺回顾、计划会议的目的分别是什么？P159 P170

①　每日站会：
时间：每天一次，每次15分钟，每次都在同一事件、同一地点。
角色：Scrum Master确保开发团队每日站会如期举办，但开发团队自己负责召开会议。Scrum Master控制时间，并保证会议不被他人打扰。
目的：开发团队为接下来的24小时的工作制定计划，通过检视上次每日Scrum 站会以来的工作和预期即将到来的Sprint工作来优化团队协作和效能。
②　冲刺评审会议：
时间：在冲刺的最后一天召开的会议，该会议时间一般不超过4小时。
角色：由产品负责人、开发团队参加，Scrum Master及用户代表可选参加。
目的：检视完成的产品增量是否符合用户的预期，收集反馈以便后续的词。
③　冲刺回顾会议：
时间：通常在冲刺评审会议之后召开，时间一般不超过4小时。
角色：由Scrum Master组织召开，开发团队成员必须参加，产品负责人可选参加。
目的：Scrum团队检视自身并创建下一个冲刺改进计划的机会。

1.23 （18）估算方法，dev，敏捷估算法，三角估算法，他们都是什么意思，他们是怎么样的估算过程，给你一些数据之后你能不能估算出来，一个是估算优先级（有个表格哪两个东西）、一个是估算工作量，分别是怎么估算的。

扑克估算法：

估算优先级：

延迟成本 1级最严重 1最优先
延迟成本/工作规模=wsjf（加权短作业优先）

1.24 三角估算法，给你一个数字，你要把最后的冲刺时间估算出来。

1.25 什么是配置管理？P178

配置管理及版本控制是指通过技术及管理手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施和过程，它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理。

1.26什么是scm？

软件配置管理（Soft Configuration Management）:指通过执行版本控制，变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性与可跟踪性。

1.27 配置管理中包含两个，一个是代码管理，一个是需求项管理（积压项管理），代码管理（有几种类型的工具，基于中心的，分布式的），分布式有哪些（git），基于中心的有哪些（sbm、cbm、微软的bss）什么是基于分布式的，什么是基于中心的，他们之间有什么区别？P179

当前配置管理系统或工具从管理模式上来分主要是分为两大类：
一类是中央总控模式，SVN、TFVC、VSS等，在服务器端保留一份拷贝。
适用于：大型项目代码库；权限管控比较严格，可以到文件级别；比较难于合并的文件类型，比如：二进制文件等。
另一类是分布式模式，微软GIt’GitHub、GitLab等，每个开发人员在本地克隆的一个完整的拷贝。
适用于：小型或模块级的项目；基于开源代码的；分布式团队；跨平台工作的团队；新领域的代码库等。

1.28 git

①Apush一个代码上去，B修改代码，push上去，C这个人比较AB版本之间的差距（命令）

②怎么建立分支

③怎么把代码从分支上下载到本地的分支上

④在分支上的代码比较，两个分支的代码比较

1.29 git当中有几个库（ppt上面图）？开发过程有几个角色，他们之间是怎么协作的，到时候要画出来（图）。软件测试工程师，cm工程师，开发技术人员，和项目经理，他们之间有几个库，他们之间怎么协作的。

1.30 在估算时，有一个容量，什么是容量？

工作容量：在一个冲刺内，开发团队所有成员可供用来工作的时间总和称为工作容量

1.31 什么是燃尽图？燃尽图的目的是什么？为什么要燃尽图？主要干什么用？P148p157

燃尽图：通过显示随着迭代的进行而减少的剩余工作量，用图形化的方式来显示团队是如何工作的。
目的：通过燃尽图，为团队提供了一个即时的视觉效果，可以预期何时完成所有任务。必须正确设置该Sprint中所有团队成员的能力（容量），以确认剩余的总工作时间是正确的。

1.32在我们设计过程中，uml设计图静态视图有哪些，动态视图有哪些。给定需求，画出他的用例图和活动图。

动态模型（活动图、顺序图、状态图）
静态模型（用例图、类图、组件图、部署图）

1.33 有哪几种测试方法？根据测试什么来分，有好几种测试？有好几种分类方法？P247

④　软件测试特性：白盒测试、灰盒测试、黑盒测试
⑤　软件开发过程：单元测试、集成测试、系统测试、用户验收测试及回归测试
⑥　软件测试要求：基本功能测试、全面测试、基准测试
⑦　软件特性：功能测试、非功能测试

1.34 测试过程当中的基本准则。P245

①　完全测试程序是不可能的，不可能找出软件的所有缺陷。
②　软件测试是有风险的行为，如果决定不去测试所有的情况，那就是选择了风险。
③　测试无法显示潜伏的软件缺陷，软件测试工作与防疫的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷，更不可能保证找到全部缺陷。
④　生活中的寄生虫与软件缺陷几乎完全一样，两者都是成群出现
⑤　软件开发中的“杀虫剂”怪事，需要测试人员设计新的测试方法
⑥　并非所有软件缺陷都能修复
⑦　软件测试人员在小组中不受欢迎，控制情绪，不要总给程序员坏消息。

1.35 什么是软件缺陷？软件缺陷产生的原因？P243

软件缺陷：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
产生缺陷的原因：
①　产品规格说明本身不明确或错误，或者对产品规格说明的理解有误。
②　代码编写错误
③　软件变更会引入新的缺陷，除了变更部分产生缺陷，个别功能的修改会影响其他部门。
④　与软件对接的第三方本身存在问题。
⑤　从软件开发管理角度来看，失控的项目管理、紧迫的项目工期、人力资源配备不足、沟通不充分等会导致大量缺陷，并且导致质量失控。

1.36 测试版本，什么是alpha版本，什么是Beta版本？P247

Alpha版——公司内部测试的版本：
①　软件的所有功能都实现了
②　所有功能都测试通过
③　严重级别的缺陷已修正并通过复测
④　软件性能测试可提供基本数据
Beta版——对外发布公测：
①　次严重缺陷基本完成修正并通过复测
②　完成测试计划中每一项具体测试
③　一段时间内的缺点的发现率低于修正率
④　所有相关文件（用户指南、软件说明、版本说明等）得到最后修正。

1.37 什么是自动化测试？什么是持续测试？P252

自动化测试：把人为驱动测试行为转化为机器执行的一种过程。
持续测试：敏捷测试的进阶版，意味着持续不断的测试，贯穿了整个软件交付周期，包括从需求分析到产品部署的各种测试阶段；持续测试提倡尽早测试、频繁测试和自动化测试。

1.38 持续测试与以前传统的测试有什么区别？P251

传统测试以手工测试为主，对代码级别的测试投入较少，整体呈倒三角模式，侧重于发现缺陷并修复；敏捷的出现增大了自动化测试的比例，以底层运行速度快、消耗小的单元测试为主，整体呈正三角模式，相比传统测试反馈更及时，修复缺陷的成本低；持续测试在敏捷测试的基础上，强调测试持续进行，通过各部门的协同工作，持续发现缺陷并迅速修复。

1.39 什么是QA？

Quality assurance 质量保证

1.40 现在的敏捷开发中的测试与以前瀑布模型的测试区别在哪里？P252

传统测试以手工测试为主，对代码级别的测试投入较少，整体呈倒三角模式，侧重于发现缺陷并修复；敏捷的出现增大了自动化测试的比例，以底层运行速度快、消耗小的单元测试为主，整体呈正三角模式，相比传统测试反馈更及时，修复缺陷的成本低，强调测试持续进行，通过各部门的协同工作，持续发现缺陷并迅速修复。

1.41 什么是冲刺的速度？怎么样计算这个冲刺的速度？

冲刺速度：衡量团队进展速度
在计算团队冲刺速度之前，需要计算开发人员的可用时间及并设置在冲刺期间的可用工作容量。可以按如下方法来计划可用时间：
– 明确一个冲刺多长时间，建议按两周来确定；
– 计算一个冲刺有多少工作日，企业里通常是按冲刺周数*5来计算，使用996的公司则按6天每周来算；
– 每个团队成员在冲刺期间可工作多少时间，要除去员工成员的假期或其他休息日，计划参加的会议等时间。
• 考虑到团队是新的，肯定会有浪费时间或未知活动导致的一些拖延，如果没有历史数据则
建议分配25%的拖延时间。这样计算下来，如果每天是8小时，则团队能力为每天6小时；
这个时间里还包含有10%的时间用于参加积压产品待办事项（需求项）精炼。