目录
参考：南软考研大书
这位大佬：
Blog of Samperson (samperson1997.github.io)
还有这位大佬：SpriCoder的博客
第一、二章 软件工程概论
1.软件工程（名词解释）
(1)应用系统的、规范的、可量化的方法，来开发、运行和维护软件，即将工程应用到软件。
(2)对(1)中各种方法的研究。
2.从1950s—2000s之间的特点（简答）
-
1950s：科学计算；以机器为中心进行编程；像生产硬件一样生产软件。
-
1960s：业务应用（批量数据处理和事物计算）；软件不同于硬件；用软件工艺的方式生产软件。
-
1970s：结构化方法；瀑布模型；强调规则和纪律。它们奠定了软件工程的基础，是后续年代软件工程发展的支撑。
-
1980s：追求生产力最大化；现代结构化方法/面向对象编程广泛应用；重视过程的作用。
-
1990s：企业为中心的大规模软件系统开发；追求快速开发、可变更性和用户价值；web应用出现
-
2000s：大规模web应用；大量面向大众的web产品；追求快速开发、可变更性、用户价值和创新。
第三、四章 项目启动
1.团队结构：主程序员团队；民主团队；开放团队
如何管理团队：建立团队章程；持续成功；和谐沟通；避免团队杀手
2.质量保障有哪些措施？结合实验进行说明
(1)需求开发——需求评审和需求度量；
(2)体系结构——体系结构评审和集成测试(持续集成)；
(3)详细设计——详细设计评审、设计度量和集成测试(持续集成)；
(4)构造阶段——代码评审、代码度量、测试（测试驱动和持续集成）；
(5)测试阶段——测试、测试度量。
要及时的根据保障计划进行质量验证，质量验证的方法主要有评审、测试和质量度量三种。
3.配置管理有哪些活动？实验中是如何进行配置管理的
（1）标识配置项版本管理
（2）变更控制
（3）配置审计
（4）状态报告
（5）软件发布管理
在项目实践中，使用配置管理工具对项目进行配置管理，如SVN。
第五章 软件需求基础
1.需求（名词解释）
(1)用户为了解决问题或达到某些目标所需要的条件或能力；
(2)系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；
(3)对(1)或(2)中的一个条件或一种能力的一种文档化表述。
2.区分需求的三个层次：业务需求，用户需求，系统级需求
【题型】给出一个实例，给出三个层次的例子；对给定的需求示例，判断其层次
【业务需求】——来自现实：系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 ，为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
【用户需求】——来自现实：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。对所有的用户需求，都应该有充分的问题域知识作为背景支持
特性：模糊、不清晰 ；多特性混杂 ；多逻辑混杂
【系统级需求】——来自软件：用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节。描述了开发人员需要实现什么
将用户需求转化为系统需求的过程是一个复杂的过程：首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
【示例】
R1：在系统使用3个月后，销售额度应该提高20%（业务需求－为何开发系统）
R2：系统要帮助收银员完成销售处理；（用户需求－帮助用户做什么）
系统特性SF1：管理VIP顾客信息，针对每一个系统特性，都可以建立一组用户需求。例如对SF1，每一条都是用户完成具体任务所需要的功能：
UR1.1：客户经理可以使用系统添加、修改或者删除会员个人信息。（用户需求）
UR1.2：收银员使用系统进行销售时会记录会员的购买信息。 （用户需求）
UR1.3：客户经理可以使用系统查看会员的个人信息和购买信息。（用户需求）
UR1.4：客户经理可以使用系统查看所有会员的统计信息。 （用户需求）
R3：收银员输入购买的商品时，系统要显示该商品的描述、单价、数量和总价（系统级需求－系统怎么与外界交互）
对用户需求UR1.3，可以依据任务中的交互细节将之转化为系统级需求SR1.3.1～SR1.3.4。
SR1.3.1在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。（系统级需求）
SR1.3.2在客户经理输入会员的客户编号时，系统要提供该会员的个人信息。（系统级需求）
SR1.3.3在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史购买记录。
SR1.3.4经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号。（系统级需求）
ATM机：问题：营业厅人力成本过高，不吸引客户（业务需求）
问题域：存钱、取钱、转账（用户需求）
3.掌握需求的类型
【题型】对给定实例，给出不同类型的需求例子；对给定的需求示例，判定需求类型
【需求】项目需求、过程需求、系统需求（软件需求、硬件需求、其他需求）、不切实际的期望
（1）项目需求（人的数量，计划书成本、时间）
R5：项目的成本要控制在60万元人民币以下。
R6：项目要在6个月内完成。
（2）过程需求（人的分工、合作、方法、工具）
R7：在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告。
R8：项目要使用持续集成方法进行开发。
（3）其他需求
R9：系统要购买专用服务器，其规格不低于……
R10：系统投入使用时，需要对用户进行1个星期的集中培训。
（4）不切实际的期望
R11：系统要分析会员的购买记录，预测该会员将来一周和一个月内会购买的商品；（技术上不可行）
R12：系统要能够对每月的出入库以及销售行为进行标准的财务分析；（在有限的资源条件下不可行）
R13：在使用系统时，收银员必须要在2个小时内完成一个销售处理的所有操作。（超出了软件所能影响的问题域范围）
【软件需求分类】功能需求、性能需求、质量属性、对外接口、约束、数据需求
（1）功能需求：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
最常见、最主要和最重要的需求；能够为用户带来业务价值的系统行为；最需要按照三个抽象层次进行展开；软件产品产生价值的基础
（2）性能需求：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。需要进行专门模拟和测试
速度，系统完成任务的时间，例如PR1。PR1：所有的用户查询都必须在10秒内完成。
容量，系统所能存储的数据量，例如PR2。PR2：系统应该能够存储至少100万个销售信息。
吞吐量，系统在连续的时间内完成的事务数量，例如PR3。PR3：解释器每分钟应该至少解析5000条没有错误的语句。
负载，系统可以承载的并发工作量，例如PR4。PR4：系统应该允许50个营业服务器同时从集中服务器上进行数据的上传或下载。
实时性，严格的实时要求，例如PR5。PR5：监测到病人异常后，监控器必须在0.5秒内发出警报。
PR6：98％的查询不能超过10秒。
PR7：（最低标准）在200个用户并发时，系统不能崩溃；
（一般标准）在200个用户并发时，系统应该在80％的时间内能正常工作；
（理想标准）在200个用户并发时，系统应该能保持正常的工作状态。
（3）质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，
可靠性：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。
QA1：在进行数据的下载和上传中，如果网络故障，系统不能出现故障。
可用性：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率。
QA2：系统的可用性要达到98%。
安全性：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的。
QA3：VIP顾客只能查看自己的个人信息和购买记录；收银员只能查看，不能修改、删除VIP顾客的信息。
可维护性：软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性和可扩展性。
QA4：如果系统要增加新的特价类型，要能够在2个人月内完成。
可移植性：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
QA5：集中服务器要能够在1人月内从Window 7操作系统更换到Solaris 10操作系统。
易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性。
QA6：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟。
（4）对外接口：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等
解系统和其他系统之间的软硬件接口
接口的用途，接口的输入输出，数据格式，命令格式，异常处理要求；用户界面
（5）约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等，总体上限制了开发人员设计和构建系统时的选择范围
系统开发及运行的环境，包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等
C1：系统要使用Java语言进行开发。
问题域内的相关标准，包括法律法规、行业协定、企业规章等。
商业规则，用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围
R1：已过保质期的食品不能销售
R2：顾客可以使用美元付款
（6）数据需求：
功能需求的补充，如果在功能需求部分明确定义了相关的数据结构，那么就不需要再行定义数据需求
数据需求是需要在数据库、文件或者其他介质中存储的数据描述，通常包括下列内容：
各个功能使用的数据信息；
-
使用频率；
-
可访问性要求；
-
数据实体及其关系；
-
完整性约束；
-
数据保持要求。
例如，连锁超市销售系统可以使用数据需求DR1和DR2。
DR1：系统需要存储的数据实体及其关系为图6-14的内容。
DR2：系统需要存储1年内的销售记录和退货记录。
第六章 需求分析方法
1.建立用例图
参与者是与开发的系统进行交互的用户或其他系统等角色
用例图中一个单一的参与者可以代表多个用户（或系统）
一个单一的用户（或系统）可能扮演多种角色
参与者不一定是人，例如，需要从当前系统获取信息的外部系统也是参与者
步骤：1）目标分析与解决方向确定 2）寻找参与者 3）寻找用例 4）细化用例
【示例1】
×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。
首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
BR2：在系统使用3个月后，销售人员工作效率提高50%
BR3：在系统使用6个月后，运营成本要降低15%
范围：人力成本和库存成本，度量：检查平均员工数量和平均每10,000元销售额的库存成本
BR4：在系统使用6个月后，销售额度要提高20%，最好情况：40%，最可能情况：20%，最坏情况：10%SF1：分析商品库存，发现可能的商品积压、缺货和报废现象
SF2：根据市场变化调整销售的商品
SF3：制定促销手段，处理积压商品
SF4：与生产厂家联合进行商品促销
SF5：制定促销手段进行销售竞争
SF6：掌握员工变动和授权情况
SF7：处理商品入库与出库
SF8：发展会员，提高顾客回头率
SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度
SF10：帮助收银员处理销售与退货任务从上述特性可以发现涉及的用户类别：总经理，客户经理，收银员，管理员
总经理的目标有：产品调整（增删改产品信息），特价策略制定（增删改特价策略），赠送策略制定（增删改赠送策略），库存分析；（分析可能的商品积压）
客户经理的目标有：会员管理；（会员发展、礼品赠送），库存管理；（商品入库、出库和库存分析）
收银员的目标有：销售处理（销售），退货；（退货）
管理员的目标有：用户管理（增删改用户信息）
如果用例的粒度不合适就需要进行细化和调整。判断标准是：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。
不要将没有业务价值（而是技术实现需要）的事件作为用例（例如，登录（安全性需求）、输入/输入数据检查（数据需求或者业务规则）、连接数据库、网络传输等等）
不要将没有独立业务价值的单个操作（仅仅是技术实现上独立）作为用例，例如删除、增加、修改、保存
总经理的目标有：特价策略制定、赠送策略制定两个用例的业务目的、发起源和过程基本相同，仅仅是业务数据不同，所以可以合并为一个用例销售策略制定。
客户经理的目标有：会员管理用例有两个明显不同的业务事件，可以被细化为发展会员和礼品赠送2个更细粒度的用例。
客户经理的库存管理用例也有三个不同的业务目标：出库、入库和库存分析，所以也应该细化为三个用例商品出库、商品入库和库存分析，其中库存分析用例与总经理的库存分析用例相同。
【常见错误】
不要将用例细化为单个操作
不要将单个步骤细化为用例
不要将片面的一个方面细化为用例
不要将“登录”、“数据验证”、“连接数据库”等没有业务价值的内容作为用例
【示例2】
网上书店系统（OBS）是一个基于web的应用程序，允许用户浏览和购买网上产品。该应用程序支持网上购物车的概念，类似于其他网上零售商，如Amazon.com,。该系统的结账功能将集成信用卡交易处理以及内部计费系统。该系统还提供管理员视图，允许授权的员工查看和管理产品、用户和订单。
用户：购买、浏览
员工：查看用户、订单、产品管理
管理员：授权
信用卡：结账
内部计费：结账
注意：内部计费指的是单位内部，而不是系统内部
2.建立分析类图（概念类图／领域模型）
注意：与设计类图有所不同，分析类图关注现实世界问题域，而不是软件系统的内部构造机制；
类型、方法、可见性等复杂的软件构造细节不会在概念类图中，不允许出现与现实无关的内容
对象：标识（对象自治、对象请求协作）、状态（存储数据，如密码、名称……）、行为（利用数据做什么）
链接：对象间交互的路径（a拥有b的引用——a拥有b的可见性——a可以导航到b）
类：对象的集合
关联：潜在的链接抽象
要写出分析的步骤：
1）识别候选类（名词分析法）
2）确定概念类 （看是否满足既有状态又有行为）
既需要维持一定的状态，又需要依据状态表现一定的行为——确定为一个概念类
如只需要维护状态，不需要表现行为——其他概念类的属性
不需要维护状态，却需要表现行为——首先重新审视需求是否有遗漏，因为没有状态支持的对象无法表现行为；如果确定没有需求的遗漏，就需要剔除该候选类，并将行为转交给具备状态支持能力的其他概念类
既不需要维护状态，又不需要表现行为——应该被完全剔除
3）识别关联（文本中提取出“名词＋动词＋名词”的结构）
第一标准是满足需求的要求，第二标准是现实状况
4）识别重要属性
概念类图只需要用到四种关系线：
聚合关系不必可以使用，但是组合关系要适当的使用
继承关系、组合关系、聚合关系、普通关联
【示例1】
1、如果是会员，收银员输入客户编号（属性、无行为）
2、系统显示会员信息（就是会员），包括姓名（属性、无行为）与积分（属性、无行为）
3、收银员输入商品标识（商品属性、无行为）
4、系统记录并显示商品信息（有状态、有行为），商品信息包括商品标识、描述、数量、价格、特价（如果有商品特价策略的话）和本项商品总价（商品属性）
5、系统显示已购入的商品清单（有状态、有行为），商品清单包括商品标识、描述、数量、价格、特价、各项商品总价和所有品总价（商品属性）
收银员重复3-5步，直到完成所有商品的输入
6、收银员结束输入，系统计算并显示总价（存储在账单中，有行为），计算根据总额特价策略（有状态、有行为）进行
7、系统根据商品赠送策略和总额赠送策略计算并显示赠品清单（要），赠品清单包括各项赠品的标识、描述与数量（不要）
8、收银员请顾客（就是会员）支付账单（有状态、有行为）
9、顾客支付，收银员输入收取的现金数额（有属性、无行为、不要）
10、系统给出应找的余额（有属性、无行为、不要），收银员找零
11、收银员结束销售，系统记录销售信息（有状态、有行为）、商品清单、赠品清单和账单信息，并更新库存（有状态、有行为）
12、系统打印收据（根据需求，如果是一次性就无状态无行为，如果是丢了还可以打印就有状态有行为）注意：一切看需求。
（1）若商品ID必须符合标准，则ID有状态、有行为
（2）若商品数量单位不同，则单位换算的职责交给数量，有状态、有行为
（3）若商品价格按照国际汇率有不同定位，则价格有状态、有行为【示例2】
ATM系统通过显示屏，输入键盘（有数字和特殊输入按键），银行卡读卡器，存款插槽，收据打印机等与用户交互。客户使用ATM机存款，取款，余额查询，对账户的更新交由账户系统的一个接口来处理。安全系统将为每个客户分配一个PIN码和安全级别。每次事物执行之前都需要验证PIN码。将来，银行计划使用ATM机支持一些常规操作，例如使用地址和电话号码修改。
分析：显示器、按键、读卡器、存款插槽、收据打印机 不属于现实世界
客户：属性：PIN、地址、电话号码、安全级别
账户：余额
交易【示例3】
- 顾客向系统提起查询请求
- 系统根据请求为顾客提供一个CD的推荐列表
- 顾客在推荐列表中选定一个CD，然后要求查看更详细的信息
- 系统为顾客提供选定CD的详细信息
- 顾客购买选定CD.
- 顾客离开
分析：
查询请求：有状态、有行为
顾客和CD：看戏球，不确定是否存储详细信息
推荐列表：有状态、有行为（增删改）
3.建立系统顺序图（交互图）
步骤：1）确定上下文环境 2）根据用例描述找到交互对象 3）按照用例描述中的流程顺序逐步添加消息
同步消息、异步消息、返回消息
注意：
（1）异步消息的箭头无论是从用户到系统还是从系统到用户都是一样的
（2）opt标签表示可选；loop标签表示循环，要在旁边用［］内写循环条件；alt标签表示候选（基本上只会放一次返回消息），每一种可选分支之间要用虚线分割，而且在表示执行态的圆柱上面要写监护条件，放在［］里面。
4.建立状态图
状态: 一组观察到的情况，在一个给定的时间描述系统行为
状态转换: 从一个状态到另一个状态的转移
事件: 导致系统表现出可预测行为的事件
活动: 作为产生转换的结果而发生的过程
步骤：1）确定上下文环境 2）识别状态 3）建立状态转换 4）补充详细信息，完善状态图
注意：并不是所有的状态图都有开始态和结束态，开始态通常只有一个，结束态可以有多个
【示例】明确状态图的主体：用例UC1销售处理。
空闲状态（开始状态）：收银员已经登录和获得授权，但并没有请求开始销售工作的状态；
销售开始状态：开始一个新销售事务，系统开始执行一个销售任务的状态；
会员信息显示状态：输入了客户编号，系统显示该会员信息的状态；
商品信息显示状态：刚刚输入了一个物品项，显示该物品（和赠品）描述信息的状态；
列表显示状态：以列表方式显示所有已输入物品项（和赠品）信息的状态；
错误提示状态：输入信息错误的状态；
账单处理状态：输入结束，系统显示账单信息，收银员进行结帐处理的状态。
销售结束状态：更新信息，打印收据的状态。
第七章 需求文档化与验证
1.为什么建立需求规格说明？结合试验说明
（1）软件开发过程中，子任务与人员之间存在错综复杂的关系，存在大量的沟通和交流，所以要编写软件开发中要编写不同类型的文档，每种文档都是针对项目中需要广泛交流的内容。因为软件需求需要进行广泛交流，所以要把需求文档化。
（2）需求规格说明是在软件产品的角度以系统级需求列表的方式描述软件系统解决方案
用例侧重于交互流程，规格（解决方案）侧重于独立需求
用例以一次交互为基础，规格需求以一次交互中的软件系统处理细节为基础
2.对给定的需求规格说明示例，判定并修正其错误。
首先了解需求文档化要点：
1）技术文档写作要点（简洁，精确，易读，易修改）；
2）需求书写要点（使用用户术语，可验证，可行性）；
3）需求规格说明文档书写要点（充分利用标准的文档模板，保持所以内容位置得当；保持文档内的需求集具有完备性和一致性；为需求划分优先级）
【错误示例】
- “After the payment process is complete, the relevant information should be appended to a log file.”(b)
- a. This requirement should be rewritten; it is incorrect. 不正确
- b. This requirement should be rewritten; it is ambiguous or inconsistent. 模糊的
- c. This requirement should be rewritten; it is unrealistic. 不现实的
- d. This requirement should be rewritten; it is unverifiable. 不可验证的
- e. This requirement is fine. 好的
- “The system should be constructed so that it will be easy to add new functionality in the future.”(b)
- a. This requirement should be rewritten; it is incorrect.
- b. This requirement should be rewritten; it is ambiguous or inconsistent.
- c. This requirement should be rewritten; it is unrealistic.
- d. This requirement should be rewritten; it is unverifiable.
- e. This requirement is fine.
- “The price of a gasoline purchase is computed as the price per gallon for the type of gas purchased, multiplied by the number of gallons purchased (use two decimal points for representing fractions of gallons).”(e)
- a. This requirement should be rewritten; it is incorrect.
- b. This requirement should be rewritten; it is ambiguous or inconsistent.
- c. This requirement should be rewritten; it is unrealistic.
- d. This requirement should be rewritten; it is unverifiable.
- e. This requirement is fine.
- "The system should be available 24 hours a day, 7 days a week.©
- a. This requirement should be rewritten; it is incorrect.
- b. This requirement should be rewritten; it is ambiguous or inconsistent.
- c. This requirement should be rewritten; it is unrealistic.
- d. This requirement should be rewritten; it is unverifiable.
- e. This requirement is fine.
3.给定的需求示例，设计功能测试用例
结合测试方法