软件工程与计算II重点整理(第1-5章)

第一、二章软件工程概论

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个小时内完成一个销售处理的所有操作。（超出了软件所能影响的问题域范围）

R14：如果一个销售处理任务在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）数据需求：
功能需求的补充，如果在功能需求部分明确定义了相关的数据结构，那么就不需要再行定义数据需求

数据需求是需要在数据库、文件或者其他介质中存储的数据描述，通常包括下列内容：

各个功能使用的数据信息；