大三-软件工程复习-自我理解后制作

《软件工程》复习大纲

第1章：软件工程的范畴

重点掌握如下的内容：

1掌握软件工程、软件危机、生命周期的概念 1%

软件工程: 为了解决软件危机出现的问题
软件危机: 
        软件质量低
        软件超出预算
        软件开发超时

生命周期: 软件概念开发, 到最终退役, 的一些列实际步骤

2掌握维护的3种分类并能够结合具体例子进行判断 1%

1.纠错性维护(不修改文档, 去除软件中的错误)
增强型维护:(修改文档, 并且实现这些修改)
    2.完善性维护: 增加功能, 减少响应时间(满足当前的需求, 但是想增加满足程度)
    3.适应性维护: 修改程序--> 适应环境的变化(输入输出, 数据结构, 不能适应需求的变化)

3掌握为什么没有计划、文档和测试阶段 1%

没有计划阶段: 无法一开始就能制定一个一定不会变的计划, 计划不一定完美, 需求可能会变

没有测试阶段: 测试贯穿全程, 错误需要测试来发现, 找出问题, 问题发现越早, 花费越低

没有文档阶段: 文档会不断的更新, 而且必须是最新的, 正确的, 完整的

4掌握软件工程的传统生命周期模型（瀑布模型）的阶段划分和各阶段的主要任务1%

瀑布模型:

阶段	任务	目的
需求阶段	对概念进行研究, 提取客户的需求	提取需求
分析(规格说明)阶段	分析客户需求, 并以规格说明文档的形式给出 结束时,完成<<如啊年项目管理计划>>	给出规格说明文档(要做什么)
设计阶段	1.结构设计(整体, 分成模块) 2.详细设计(设计模块) 3.得到两个设计文档, 描述怎么做	架构设计, 模块设计, 文档(解释怎么做)
实现阶段	独立部分的代码编写和测试(单元测试), 集成测试, 验收测试	实现产品
交付后维护	纠错性维护, 增强性维护(包括: 完善, 适应)	延续软件的寿命

5掌握传统的维护观念与现代的维护观念之间的区别1%

传统的开发方法可以描述成: 开发-维护模型
    就是说: 开发和维护是有先后顺序的
    安装前修正错误: 属于开发
    安装后修正错误: 属于维护

现代:
    只要是修复错误, 或者需求, 代码, 增加新功能(修正,与规格说明不一致的, 改进规格说明的文档), 都属于维护

了解如下内容：

1了解纠错与成本之间的关系

纠错 需要 成本来 支撑

2了解面向对象范型与传统范型在生命周期模型方面的比较

阶段	传统	面向对象
分析	确定要做什么	确定要做什么,提取类
设计	1.结构设计(提取模块) 2. 详细设计	详细设计(设计类的细节)
实现	1.用恰当的编程语言编写模块 2.集成	1. 面向对象的语言 编写 类 2.集成

3了解如下术语的区别：客户、开发者和用户；内部软件、合同软件、商用现货软件（即COTS软件）和开源软件；过错、差错和故障

内部软件: 开发人员,面对的客户, 就是自己的公司
开发者: 小组的成员, 负责建造该产品
合同软件: 客户和开发者, 不是同一个公司的, 是完全独立的组织成员
开源软件: 一组自愿者开发 和 维护, 任何人都可以下载 和 免费使用, 同时也可以成为开发中的一员, 一般都是高手
商用现货软件: 用于低价出售卖给有需要的买者的, 软件的副本,
过错的结果 ---> 差错的结果 ---> 产生故障

第2章：软件生命周期模型

重点掌握如下的内容：

1掌握编码-修补模型、瀑布模型、快速原型开发模型、开源模型、敏捷过程模型、同步-稳定模型、螺旋模型等这些模型的模型图（如果有图的话）以及优缺点和适用场合，并能绘制。5-10%

type	特点	优点	缺点	适用场景
编码-修补模型		简单,上手快	代价最大的方式 2.没有需求 3.没有设计 4.没有规格说明	非常小型的项目
瀑布模型	1），阶段间具有顺序性和依赖性 2）， 推迟实现的观点 3），质量保证的观点	文档驱动,每个阶段都有文档,且需要SQA检查 2.维护容易	1.客户不懂文档, 不能理解真正的产品是什么样的, 产品最后容易偏离客户的需求 2.），“瀑布模型是由文档驱动的”在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样子的。但是通过写在纸上静态的规格说明，很难全面正确的认识动态的软件产品。	需求明确，小规模软件开发。
快速原型模型		1.一开始就建造快速原型, 客户对此确认, 就可以出比较准确的规格说明文档 2.原型推进了进度, 可以用于接下来开发的参考, 但是需要丢弃	必须迅速地构建原型然后根据用户意见循序的修改原型	用户需求不明确，需要通过构建原型来清楚的了解用户的真实需求。
迭代递增模型		为检验产品的正确性提供了很多机会 2.相对早期就可以确定结构的健壮性 3.较早的减轻风险 4. 一开始就有一个软件产品的工作版本, 客户和用户以此来决定做什么, 改变什么	1.缺少用户参与 2缺少高级执行主管人员的支持	大型的项目
开源模型	1.测试成本低, 为广大的用户 2.初始阶段: 1.快速原型() 2.编码-修补模型 3.开源生命周期模型 3.原型不会被丢弃 4.没有规格说明和设计文档	1.开发者都是最好的软件专家 2. 测试人员是广大用户, 容易发现错误, 以及完善	很难起步 2.很难有人看上	被很多人所需求, 能够吸引广大软件专家的兴趣
同步稳定模型	每天同步, 构建冻结
敏捷过程	极限编程(基于迭代,递增) 1.测试驱动 2.结对编程	适应需求变化能力强 2.时光盒	大块时间少 2.害羞和专横性格不合适 3.不强调分析和设计	小型项目
螺旋周期模型

---

---

生命周期模型	长处	短处
进化树模型	与现实世界软件开发最接近的模型, 与迭代-递增模型等价
迭代递增模型	与现实世界软件开发最接近的模型, 蕴藏统一过程方法
编码-修补模型	适用于不需要任何维护的小程序	总的来说不适合重要的程序
瀑布生命周期模型	纪律性强制的方法, 文档驱动	交互的产品可能不符合客户的要求
快速原型开发生命周期模型	确保交付的产品符合客户的要求	还没有证明无懈可击
开源生命周期模型	少量实例中工作得相当的好	实用性有限, 通常不太起作用
敏捷过程	客户的需求模糊时能够很好的工作	似乎只适合小规模的项目
同步-稳定生命周期模型	能够满足未来用户的要求, 确保各个组件能够成功的集成	除了在Microsoft工资, 还没有被广泛使用
螺旋生命周期模型	风险驱动	只能用于大型的内部软件产品, 开发者必须精通风险分析和风险排除

了解如下内容：

1了解Winburg小型实例研究以及进化树生命周期模型图，并理解基线的概念

基线的详解

基线: 为后续开发铺路的稳定版本, 所有的工作都以他为中心
      一旦基线更新, 变更, 需要及时通知所有人员, 以新的基线工作
      是一个稳定工作版本的快照

2了解迭代和递增的区别，掌握米勒法则和逐步求精法这两个概念，了解迭代递增模型的五个核心工作流以及它们何时在迭代递增模型的生命周期中占据主导地位

迭代: 每次迭代都是一个新的版本(模块的版本, 集成的版本)

递增: 在原有的开发基础上, 开发其他功能

注意: 并不是所有的增量,都包括完整的五个工作流
      迭代,包括

第3章：软件过程

重点掌握如下的内容：

1掌握每个工作流（包括需求流、分析流、设计流、实现流、测试流）的目标 2%

type	目标
需求流	开发组织, 确定客户的需求。
分析	明确要做什么
设计	明确， 每个细节怎么做
实现和集成	编码，测试
交付后维护	维护产品，维持其生命
退役	放弃治疗， 结束周期

2掌握需求流的每个步骤（了解应用领域、建立业务模型、找出限制条件），了解主要限制条件（包括最终期限、可靠性、成本），掌握以下观点：开发者能够给予客户的应该是客户需要的而不是客户想要的 1%

步骤： 
1.了解应用领域。要运行软件的特定领域，汽车，飞机，银行，手机
2.建立业务模型。UML描述业务的过程
3.找出限制条件。（客户的描述是模糊的，不可信的，不合理的，于是有了限制条件）
    Deadline最后期限
    Parallel Running 并行运行
    Portability 便携性
    Rapid Response time 响应时间
    COst 成本

需要是软件需要实现的功能的核心功能，想要是 核心功能之外的附加要求，或者提升需求

3掌握设计流的两个步骤：结构设计和详细设计的设计内容2%

结构设计：将产品分成诺干个模块，--》 架构的设计
详细设计：将每个模块经行更为详细的设计， UI，算法与数据结构，模块，数据库

4掌握统一过程的四个阶段以及每个阶段的目标 1%

阶段	目的	流	制品
Inception 开始阶段	明确提出的软件产品是否经济上可行	需求流
Elaborate 细化阶段	细化最初的需求	完善需求流,执行整个分析流, 开始结构设计	需求,分析制品
Construction 构建阶段	生产产品的第一个可工作的版本	设计流, 实现流(单元,集成,系统)	全部制品
Translation 转换阶段	确保客户的需求切实得到满足		所有最终版本的制品

5掌握规格说明文档中可能出现的问题（包括模糊、不完备和矛盾），掌握软件项目管理计划的组成部分（包括可交付的东西、里程碑和预算）1%

可能出现的问题: 
    Contradiction 矛盾
    Omissions 遗漏
    Incomplete 不完备 (自然语言描述模糊导致)

计划管理组成部分:
    Cost estimate成本估计
    duration estimate 持续估计
    deliveralbes 可交付的东西
    milestones 里程碑  (客户可以得到他们的当前进度, 以及总的进度)
    budget 预计需要花费的成本

    里程碑的重要性:(里程碑的本质, 就是规划接下来要做的事)
        1.清晰知道当前项目的进度, 有利于时间的把控
        2.有利于开发人员,掌握开发节奏, 不至于加班
        3.减少返工的现象
        4.减少突然加班的情况

6.掌握回归测试概念及方法。1%

概念: 回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试是软件测试中的一个十分重要且成本昂贵的过程。针对如何减少回归测试成本，提高回归测试效率的研究将具有十分重要的意义。回归测试选择技术已经成为国际上研究的热点。


方法:
    全部用例测试
    选择性重复测试
        基于风险选择测试
        基于操作剖面测试

了解如下内容：

1了解以下概念：软件过程、软件过程的五个工作流、统一过程、统一建模语言UML

统一过程详细解析

软件过程:
         也称为软件生存周期过程，是指软件生存周期中的一系列相关过程。
         将用户需求转化为软件系统所需要的活动的集合。
         为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

五个工作流: 需求, 分析, 设计, 实现与集成, 测试
统一过程: 
统一建模语言UML: 

2了解测试流在各种制品中的体现形式，了解以下概念：可追踪性、评审、走查、审查、单元测试、集成测试、产品测试、验收测试、对COTS软件产品进行测试的特点

可追踪性: 
    开发过程中, 点点滴滴的记录。
    对象：设计文档， 代码， 需求文档等制品， 以及他们之间的联系
    优点： 1.利于回归测试 2.节约维护成本 3.容易修复问题 4.容易找出问题 5.利于分析

评审：顾名思义就是关于审查和批准项目计划，项目变更和工作进展评价的一个步骤

走查: 非正式
审查: 正式
SQA：保证软件过程高质量的开发，和正确性

以下测试数据，为编造的数据
        单元测试：微小的功能模块或者代码块或部件，进行测试
        集成测试（全部部件和代码都编写完毕）：系统各个部件的联合测试，确保组合在一起也能**正常的工作**
        产品测试：SQA根据规格说明测试，不仅验证正确性，还要验证健壮性

验收测试: 客户使用**真实的数据**进行测试

3了解交付后维护阶段中出现的问题，了解回归测试

问题:
    1.文档缺乏,导致追踪性差,不容易维护
    2.没几个人喜欢维护,但维护需要各个方面都很强的人员来
    3.维护阶段, 需要做整个软件过程的所有工作流, 但是却要维护人员单独完成, 而正常的开发阶段, 每个阶段都是请相应的专家来完成

回归测试:
    增加了新的代码,或者改正了一个错误, 需要用之前的用例来测试, 其他原先没有问题的部分是否仍然是正确的运行

    测试的类型:
        所有用例测试
        选择性的用例测试

4了解一维和二维生命周期模型

一维: 传统的软件开发过程
      特点: 环环相扣, 必须顺序执行每个工作流

二维: 统一软件开发过程
      特点: 迭代和递增的方式开发, 分为四个阶段
      四个阶段, 包含所有的工作流, 但是不是严格的要求, 每个阶段的下一步, 必须完成上一个工作流

      迭代: 所有工作流经历一次
      递增: 增加新的功能

5了解能力成熟度模型（即CMM）的五种分类

SW(software capacity model)
P(people)
SE(system engineering)
IPD(integrated product development}
SA (软件获取)

7了解用于软件的CMM（即SW-CMM）的五个级别

(1)初始级(initial)。
工作无序，项目进行过程中常放弃当初的计划。
管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

(2)可重复级(Repeatable)。(借鉴了其他过去的项目经验)
管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 
初步实现标准化，开发工作比较好地按标准实施。
变更依法进行，做到基线化，稳定可跟踪，新项目计划和管理基于过去实践经验，具有重复以前成功项目的环境和条件。
        核心：建立基本的项目管理和实践来跟踪项目费用、进度和功能特性

(3)已定义级(Defined)。
许多组织追求的目标
开发过程，包括技术工作和管理工作，均已实现标准化、文档化。
建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
        核心：使用标准开发过程(或方法论)构建(或集成)系统

(4)已管理级(Managed)。
产品和过程已建立了定量的质量目标。
开发活动中的生产率和质量是可量度的。
已建立过程数据库。
已实现项目产品和过程的控制。
可预测过程和产品质量趋势，如预测偏差，实现及时纠正。
        核心：管理层寻求更主动地应对系统的开发问题

(5)优化级(Optimizing)。
可集中精力改进过程，采用新技术、新方法。
拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。
可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。

第4章：软件小组

重点掌握如下的内容：

1掌握民主小组、传统的主程序员小组、现代分级编程小组、同步稳定小组、敏捷过程小组以及开源编程小组这些小组组织方式的优缺点以及适用场合 2%

小组类型	组织方式	优点	缺点	适用场景
民主小组	多达十个的无我编程, 程序员	1.找错的积极性高 2.代码质量高 3. 错误早发现	1.老手不愿意给新手自己的代码	研究环境下, 很难的问题需要解决
传统主程序员小组	主程序员 + 编程秘书 + 备程序员 + (1`3)程序员	纽约时报成功	成功与否, 非常依赖于主程序员
现代分级编程小组	小组经理(管理)+小组领导(技术)+三个程序员	比找主程序员容易2. 每个员工只对一个经理负责——明确划分了责任范围。3.领导负责技术方面的事务	领导和经理的决策冲突
同步稳定

---

---

小组类型	优点	缺点
民主小组	质量高, 错误查找积极性高	老手反感新手(代码)
传统的主程序小组	纽约时报	不实用
修改的主程序小组	有许多成功的范例	没有与 纽约 可比的项目
现代分级编程小组	经理/领导避免对主程序员的高要求,可拓展, 必要时支持分散决策	除非明确,经理和领导的责任范围, 否则容易产生问题
同步-稳定	鼓励创新, 确保大量开发者为共同目标工作	Microsoft
敏捷过程	程序员不测试自己的代码, 应变人员变化强, 利于相互学习, 代码具有小组所有权	还没有更多的实例证明有效
开源小组	少数成功	应用面狭窄, 需要有号召力 的领导, 需要顶尖高手参与

2掌握如下概念：无我编程、结对编程的概念及特点 1%

无我编程: 钟爱自己的代码, 不喜欢发现自己代码的错误
结对编程: 大块时间, 交替进行, 一个编程, 一个看,, 相互学习

3掌握传统的主程序员小组中主程序员、后备程序员、编程秘书、程序员、小组领导、小组经理等各个角色负责的任务 2%

角色	任务
主程序员小组中主程序员	1. 成功管理和高技术 2.架构设计 3.分配团队间的编码 4.写核心部分的代码 5.处理所有接口问题 6.审查其他小组成员的工作 7.对每行代码负责
后备程序员	和主成员一样优秀2. 深入了解项目 3. 黑盒测试的用例规划 4设计过程独立的任务
编程秘书	1.维护项目产品库, 即文档 2. 将源码, 编译, 链接, 装载, 执行并且测试用例
程序员	编码
小组领导	高技术
小组经理	高管理

4掌握布鲁克斯法则1%

已经超期的项目, 增加新成员, 会导致进度更慢

了解如下内容：

1了解组织开发小组时可能出现的问题，了解组织开发小组的两种极端方法

问题: 接口问题, 管理问题, 人员变化问题, 沟通问题, 
民主小组 和 主程序员

2了解现代分级编程小组中小组领导和小组经理负责的区域

第5章：软件工程工具

重点掌握如下的内容：

1掌握逐步求精法，了解逐步求精法小型实例研究中出现的每一次求精，了解前瞻技术，掌握逐步求精法的难点1-5%

逐步求精: 尽可能将细节的定义推迟到最后, 以便集中精力在重要的事情上.

2掌握软件度量的两种分类（即产品度量和过程度量）以及度量时用到的具体指标（例如：代码行、每千行代码检测出的错误数、平均故障间隔时间等等），掌握五种基本度量（即规模、成本、持续时间、工作量、质量）1%

产品度量(规模, 可靠性) 和 过程度量(推断有关软件开发过程的信息)(例如: 错误检测的有效性, 开发过程的错误数量/ 整个生命周期错误数量)

规模: 代码行
成本: 美元
持续时间: 月计
工作量: 人月
质量: 错误数计

3掌握CASE工具的概念以及分类（即高端与低端，工具与工作平台与环境）1%

CASE: 计算机辅助工程软件

高端case: 帮助 需求 分析 设计 的工具
低端case: 帮助 实现 交付后维护流的工具

工具: 提高生产效率
工作平台: 工具的集合
环境: 工具运行的支撑

4掌握软件版本的两种分类（即修订版和变种版）以及这两种分类的区别 1%

修订版: 软件的正常更新的新版本, 新版替代旧版，version   

变种版: 为了共存, 适应多种系统, 比如安卓版, 苹果版, window, Linux 的同一个QQ软件

了解如下内容：

1了解两种类型的软件工程工具（即理论分析工具和软件工具）

数据字典：产品中定义的所有数据的计算机化列表（将计算机中的数据，按照含义给标签，也就是给数据一个描述，它代表什么含义）

2了解成本效益分析法以及使用时的难点

成本效益：对比估计未来的收益和预测的未来成本

3了解具体的CASE工具

提高开发效率的软件：高端，低端，建造工具，版本控制，版本管理

4了解版本控制过程中出现的问题和用到的技术

版本混乱，制品多，不容易哪个制品具有什么样的特性，或者说能做什么，只有单纯的一个版本号

解决：（贴标签，分类）文件名+版本号 --进--》 文件名+ 版本号+变种名

5了解配置控制工具以及基准和冻结这两个概念，了解建造工具

配置控制工具: 自动管理多个变种版本???
基准: 是产品中所有制品的配置(版本集)。其实就是（模范版，地基版本）
    
    一旦决定要改动，基准 版， 就要 **冻结** 基准版，其他人无法修改，直到发布了新的版本，修改完成，其他人，再去下载新的基准版改动

建造工具：（构建工具）选择要链接的每个编译代码制品的**正确版本**，从而形成该版本的一个特定的版本。（理解： 每个制品都有很多版本，同时也有很多的正确的版本，不同的制品之间的各个正确版本，组合构建成一个，特定的版本，例如：A1.3.1+B1.0.0 与 A2.3.1+B1.0.0就是两个特定的版本）

第6章：测试

软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

重点掌握如下的内容：

1掌握质量的定义以及软件质量保证小组（即SQA小组）的责任 2%

质量: The extend to which software satisfies its specificaions;
SQA的责任: 
1. 保证开发过程的正确性(保证质量)
2. 保证开发人员高质量的工作(保证正确)

2掌握走查时小组成员的构成、走查清单的构成、走查的两个步骤、走查的两种方式以及这两种方式之间的区别 2%

走查小组构成: 
1.A behalf who can write specifications
2.The representative of client 
3.A manager who is responsible for analyzing flow
4.A deputy of SQA
全程: 文档, 用户, SQA
非全程: 下一个流的代表

走查两清单: 不懂 , 认为不正确
1.Items not understood(评审者不明白的事项)
2.Items that appear to be incorrect;(评审者认为不正确的)

走查的两个步骤:
1.Preparation
2.Analysis

走查两种方式:

1.participant-driven:   被动, 给人检错, 参与者是上帝
    参加者列出不清楚的事项和认为不对的*事项清单*,分析小组的*代表*必须回答每个问题, 要么解释清楚, 要么承认错误, 要么解释为什么错了。

2.document-driven:   主动, 你们来和我一起看看文档 , 有没有什么问题, 可以随时提问, 来的人是给你工作的
    负责该文档的人带领参与者阅读文档, 评审者事先准备意见或者引发的意见, 随时打断并且提问。

3掌握审查时小组成员的构成、审查的五个步骤 2%

审查小组成员:   主持人, 带着, 当前, 下一个, 和全程的SQA代表
1.Moderator(主持者)
2.A member of the team performing the current flow
3.A member of the team performing the next flow
4.A member of SQA

五 步骤:   概要所有内容, 准备, 开始审查啦, 修订, 跟踪
1.Overview
2.Preparation
3.Inspection
4.Rework(=revise 修订)
5.Follow-up(跟踪)

4掌握走查与审查之间的区别 2%

区别: 
1.审查使用询问一览表来帮助找到错误. 
2.5步与2步
3.审查比较正式, 每一步都是形式化, 走查非正式
4.审查比较费时间
代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。

5掌握需要测试的五个行为特性（即实用性、可靠性、健壮性、性能和正确性）的定义以及相关度量指标（如平均故障间隔时间、平均修复时间）1%

行为	定义	相关度量指标
Utility	规格说明允许的条件下使用正确产品时, 满足用户需求的程度	易用性,执行有用功能的能力,与竞争产品比较成本是否划算
Reliability	对产品故障的出现频率和严重性进行测量	平均故障间隔时间,平均修复时间
Robustness	对异常的处理程度	报错的处理
Performance	时间和空间上的程度,内存大小,响应速度	避免卡顿,导致的不可恢复的数据丢失
Correctness	符合规格说明书,即为正确

6掌握测试的两种分类 1%

执行测试: 推断某产品的特定行为特征的过程, 基于全部或者部分在已知环境下用经过选择的输入执行产品得到的结果.
下面有五个需要测试的: 实用性, 可靠性, 健壮性, 性能, 正确性

基于非执行测试: 测试软件而不运行测试用例.
测试对象: 代码和文档
测试方法: 评审软件文档或者代码, 或者用数学方法分析软件
评审方法: 走查和审查

了解如下内容：

1了解验证和确认的区别

验证和确认 verification ，validation，比较靠谱的2个解释是：

1. 验证是检查软件是否满足需求文档的要求。确认就是检查最终产品是否达到顾客使用要求。
2. 验证注重“过程”，确认注重“结果”

2了解开发小组与SQA小组之间应该保持管理独立的重要性

在快要交付的时候发现错误, 容易决策

3了解非执行测试的定义和方法

定义: 测试软件而不运行测试用例, 走查和审查

4了解审查时的度量指标

错误统计记录

5了解正确性与产品的可用性之间的关系

正确性只是符合了规格标准, 可用性, 符合了标准, 是否还好用

6了解执行测试应该由谁来完成，了解测试何时应该停止

独立的测试SQA小组来进行

退役, 不在使用时, 停止

第7章：从模块到对象

重点掌握如下的内容：

1掌握以下概念的定义：模块、模块内聚、模块耦合 1%

模块:
    一个或多个邻接的程序语句的集合, 它有一个名称以方便系统其他的部分去调用它, 并且最好具有自己专用的变量名集.
    module_name{ type name; type2 name2;  语句1; 语句2; }

模块内聚:
    模块内的交互程度

模块耦合:
    模块间的交互程度

2掌握内聚的七个等级分类（即偶然性、逻辑性、时间性、过程性、通信性、功能性以及信息性）以及每个等级的定义，并能够结合具体例子判断内聚等级 1-5%

3掌握耦合的五个等级分类（即内容、共用、控制、印记以及数据）以及每个等级的定义，并能够结合具体例子判断耦合等级 1-5%

内容耦合: 一个模块的内部数据, 可以被其他模块直接操作
公用: 多个模块, 引用了相同的全局变量
控制: 一个模块给另外一个模块传递, 控制变量参数
印记: 传递的参数是一个数据结构, 接收方只使用部分
数据: 传的全部都使用

4掌握UML图标：注释、继承、聚合、关联 1-2%

了解如下内容：

1了解以下概念：模块操作、模块逻辑、模块背景。

2了解时间性、过程性、通信性内聚之间的共同点，了解逻辑性内聚和控制耦合之间的联系

共同点: 都是多个操作集中在一个模块中

控制耦合的模块中, 必然有一个逻辑内聚的模块

3了解以下概念：抽象、封装、信息隐藏、抽象数据类型、数据封装、类、对象、多态、动态绑定

抽象: 通过抑制不必要的细节并强调相关的细节达到逐步求精的一种方法(忽略次要,关注主要,然后具体化主要的相关细节)

抽象数据类型: 一个数据类型连同对该数据类型的实例进行的操作。(结构体, 类),比基本数据类型, 拥有更多的操作方法, 并且是基于基本数据类型

封装: 把实际中的实体的各个方面(细节)集中在一个对该实体建模的单元(隐藏细节)中。

信息隐藏: 
数据封装: 一个数据结构连同对该数据结构进行的操作
        

4了解面向对象范型的缺点（包括脆弱的基类问题、继承树中低层对象的数据存储问题、多态和动态绑定在维护时带来的负面问题）

第8章：可重用性和可移植性

重点掌握如下的内容：

1掌握可移植和重用的定义 1%

编程语言的可移植性意味着，用一种编程语言在一个系统上编写的程序经过很少改动或者不经修改就可以在其他系统平台上运行。

所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。

了解如下内容：

1了解重用的两种类型（偶然重用和有意重用）以及重用时出现的障碍，了解不在此开发综合症

2了解设计时重用的四种类型（库或工具包、框架、设计模式、软件体系结构）

3了解不兼容性的四个方面（硬件、操作系统、数值计算软件、编译器）

第11章：需求

重点掌握如下的内容：

1掌握需求流的步骤（包括理解应用域、建立业务模型、找出限制条件），掌握需要的技术（包括构建术语表、访谈、发放调查问卷、检查业务表格、直接观察用户、绘制用例图）2%

理解应用域: 需要应用在什么场景
建立业务模型: 将需求具体化, 可视化, 让客户更容易确认需求, 同时让开发人员更容易了解, 业务的流程, 让需求更为准确
找出限制条件: 期限, 成本, 花费, 等等约束条件, 可以控制好进度和方向

2掌握用例图的四个基本组成部分的绘制过程，例如：图书循环问题和ATM问题等课后题的用例图的绘制。5-10%

3掌握需求的两种类型（功能性需求和非功能性需求）1%

功能性需求: 与业务直接相关的功能需求, 也就是必需要有的, (查询图书, 删除, 上架)
非功能性需求: 目标软件的性质(可靠性, 可维护性, 运行的环境)

了解如下内容：

1了解在确定客户需求时出现的三种问题（客户不知道需求、客户不知道如何表达需求、客户弄错了需求）

2了解访谈的两种类型（即程式化的访谈和非程式化的访谈）以及它们之间的区别

程式化: 受限问题, 需要特定的回答
非程式化: 根据回答提出的问题, 自由回答(废话多)

3了解传统需求阶段中建立快速原型的好处，了解在建立快速原型时需要考虑的要求（包括用户友好、图形用户界面、人的因素、外观一致性）

4了解快速原型发挥作用之后被丢弃的原因，了解确保丢弃快速原型的方法

原因: 只有外观, 交互, 内部没有实质上的业务逻辑

6了解需求流中用到的CASE工具、度量指标和面临的挑战

第12章：传统的分析

重点掌握如下的内容：

1掌握按照形式化的程度对已知的编写规格说明文档的技术（自然语言、实体-关系模型、结构化系统分析、有穷状态机、Petri网）进行的三种分类（非形式化、半形式化以及形式化）1-5%

非形式化: 自然语言
半形式化:  ER模型, 结构化系统分析
形式化: 有穷状态机, Petri网

2掌握使用非形式化技术编写规格说明文档时出现的三种问题 1%

模糊
矛盾
不完整

3掌握数据流图的四种基本要素（源或者目的地、流、处理、存储）的图形和含义，掌握数据流图顶层图的绘制。例如：图书循环问题和ATM问题的绘制。5-10%

P220

4掌握判决树的绘制4-6%

P223

5掌握实体关系模型中出现的关系的三种种类（一对一、一对多、多对多）1%

6掌握有穷状态机的五个基本组成部分（状态集、输入集、转换函数、初始状态和最终状态集）的图形和含义2%

7掌握三种编写规格说明文档的技术的优缺点 1%

类型	优点	缺点
非形式化	1.易于学习 2.易于使用 3. 客户易于理解	1.不精确 2. 规格说明可能是 模糊矛盾不完整的
半形式化	1.可以为客户所理解 2.比非形式化方法更精确	1.不如形式化方法精确 2.通常不能处理定时问题
形式化	非常精确 2.可以减少分析错误 3.可以减少开发成本 和 工作量 4.可以支持正确性的证明	1.开发小组难于学习 2.难于使用 3.多数客户几乎不可能理解

了解如下内容：

1了解规格说明文档必须满足的两个相互矛盾的要求（既是非技术性的又是技术性的）

2了解结构化系统分析技术的九个步骤以及某些步骤所需要的图形或者表格（包括数据流图、数据字典、判决树、数据实时访问图）

3了解令牌的作用，了解禁止弧和常规弧的区别，掌握在简单的Petri网上激发转换时令牌的变化情况

4了解在传统的分析阶段用到的测试技术、CASE工具、度量指标和面临的挑战

5掌握Petri网的四个基本组成部分（位置集、转换集、输入函数和输出函数）的图形和含义

第13章：面向对象分析

重点掌握如下的内容：

1掌握面向对象分析技术的形式化程度 1%

2掌握统一过程中需要抽取出的三种类（实体类、边界类和控制类）的定义 1%

实体类: 长期存在的信息建模
边界类: 产品和参与者之间的交互建模(通常和输入和输出有关)
控制类: 复杂的计算和算法建模

3掌握抽取实体类的三个步骤（功能建模、实体类建模、动态建模）2%

功能建模: 提取所有用例的场景(场景是用例的一个实例)

实体类建模: 确定实体类 和 它的属性 --> 确定类间 交互关系 和 交互行为 ---> 类图提供

动态建模: 确定每个实体类 或者 子类执行的 操作 或 对它们的操作, 状态表的形式提供信息

4能用名词提取法绘制类图。例如：电梯问题和图书循环问题的绘制。5-10%

所有名词 ---> 去掉边界外的  ---> 去掉抽象的(通常是类的属性)(没有物理存在) ---> 建立实体类图(光系 , 属性)

了解如下内容：

1了解正常场景与异常场景的区别

2了解实体类建模的两种技术（名词提取法、CRC卡片法）

3了解CRC卡片法的名称含义

4了解动态建模时绘制的状态图

5了解边界类和控制类的抽取方法

6了解在传统的分析阶段用到的CASE工具和面临的挑战

第14章：设计

重点掌握如下的内容：

1掌握数据流分析这种面向操作设计技术的使用过程，掌握在简单的数据流图中寻找输入的最高抽象点与输出的最高抽象点的方法1-5%

P 284

2掌握面向对象分析技术（OOD技术）的两个关键步骤 2%

完成类图: (遵循: 职责驱动设计原则)
进行详细设计: 求精

3掌握传统的设计阶段中的三个活动（结构设计、详细设计、设计测试）

测试设计: 验证规格说明书, 同时 确保设计的正确性

了解如下内容：

1了解设计的三种类别（面向操作设计、面向数据设计、面向对象设计）

2了解依据抽象点将产品划分成的三个模块（输入、转换、输出）

3了解伪代码（即程序描述语言PDL）的用处

4了解事物分析这种面向操作设计技术中的两个概念：分析器与分配器

5了解在设计阶段用到的测试技术、CASE工具、度量指标和面临的挑战

第15章：实现

重点掌握如下的内容：

1掌握编程语言发展历程中出现的四代，并能够结合具体编程语言判断出属于哪一代 1%

2掌握良好的编程习惯（包括在命名变量、编写注释、使用常量、代码编排、嵌套语句方面的习惯）1%

3掌握三种集成方式（自顶向下、自底向上、三明治）的步骤、优缺点，并能够结合具体的集成顺序判断出是哪一种集成方式 2%

4掌握单元测试的两种基本方法（黑盒测试与玻璃盒测试）的定义，了解不能彻底地进行这两种测试的原因 2%

5掌握选择测试用例的两个原则 1%

6掌握使用等价测试技术、边界值分析技术、功能测试技术设计简单题目的测试用例的过程5-10%

7掌握使用语句覆盖、分支覆盖、路径覆盖技术设计简单题目的测试用例的过程 5-10%

了解如下内容：

1了解在确定编程语言时需要考虑的情况

2了解三条通常的编码标准

3了解重用不仅仅是代码的重用

4在集成步骤中，了解以下概念：存根和驱动、逻辑代码制品和操作代码制品

5了解完全定义-使用路径覆盖技术

6了解在测试对象时出现的潜在问题

7了解测试与调试的区别，掌握发现新错误的可能性与已检测出的旧错误数之间的关系

8了解产品测试与验收测试包含的相同的四个测试方面，掌握产品测试与验收测试的本质区别

9了解在实现阶段用到的CASE工具、度量指标和面临的挑战

第16章：交付后维护

1掌握逆向工程、正向工程、再工程、重构的定义 1%

2掌握三种维护的概念并能根据案例做出维护类型的正确判断。1%

第17章：UML的进一步讨论

1掌握UML的定义 1%

UML 是一种 统一建模  **语言**

2掌握在UML中出现的图标（包括类图、聚合、多重性、组合、泛化、继承、关联、注释、用例图、交互图、顺序图、协作图、状态图、活动图、包、）及其含义 1-2%

P 345
类图
聚合: 空 菱形
多重性: 一辆车 4~5 个轮子
泛化: 继承是泛化的 一个 特例
继承: 
关联: 实心 三角形, (可能会有关联类)
拓展: