软件工程概论考试复习提纲

第一章 软件工程介绍

• 软件
  
  • 软件是产品。
  • 软件显示了由计算机硬件体现的计算能力。
  • 软件是指令、数据结构、软件描述信息（文档）的集合
• 软件特性
  
  • 软件不会磨损
  • 软件是开发（develop）的
  • 软件是根据需求定制的
  • 软件是复杂的
• 软件退化
  软件面临变更，每次变更都可能引入新的错误，使得软件失效率陡然上升。不断地变更就是软件退化的原因。
• 软件危机
  
  • 第一次软件危机（1945-1968）
    表现：软件生产效率低下，成本高，质量差，难以维护
    原因：手工作坊模式code and fix，软件理论体系和开发管理不完善。
    结果：软件工程理论体系形成
  • 第二次软件危机（1968-2001）
    表现：产品有错，低质量，延迟，效率低，违约现象严重
    原因：认为需求可以在软件编写前充分了解，软件开发黑盒模式
    结果：软件开发白盒模式出现，允许项目变更
  • 第三次软件危机（2001-now）
    表现：变更/演化/重用。知识产权问题。软件安全问题。
    根源：遗产系统的重用。开源软件/代码的使用。动态的需求。
    结果：软件智能化。自主软件（浑源/开源/闭源）标准。

第二章 过程综述

• 软件工程
  
  • （1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护；
  • （2）对（1）中所述方法的研究。
  • 四个层次：质量关注点->过程->方法->工具
• 软件过程
  
  • 软件过程是软件工程的基础
  • 定义:软件过程是一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤。包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
• 软件过程模型
  
  • 通用框架活动(fragment activities)
    
    1. 沟通
    2. 策划
    3. 建模
    4. 构建
    5. 部署
  • 普适性活动(unbrella activities)
    
    1. 软件项目跟踪
    2. 风险管理
    3. 软件质量保证
    4. 技术评审
    5. 测量
    6. 软件配置管理
    7. 复用管理
    8. 工作产品的准备和生产

第三章 过程模型

• 软件生命周期
  是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段
• 软件过程模型
  
  • 瀑布模型——线性模型
    
    1. 会造成阻塞
    2. 假定：软件开发前就已经了解了需求，需求不会经常变更，没有可能的较大风险，需求符合所有共同利益者的要求，架构被充分理解，时间充足。
  • V模型——线性模型
    依赖于测试
  • 增量模型——非线性
    
    1. 假设有充足的人力资源
    2. 以模块化为先决条件
    3. 全局的改变是不可能的
  • 演化模型——非线性,包括原型模型和螺旋模型
  • 原型模型：客户不能清楚地了解需求，工程师对于技术的不了解。可以用来作为一种识别需求的方法。但是容易让客户以为很快就能拿到工作产品。
  • 螺旋模型：风险驱动型。结合了原型模型和瀑布模型。适合大型的复杂软件系统。射线方向：成本。螺旋方向：过程。
    步骤：
    
    1. 尽可能详细地定义系统需求
    2. 初步设计
    3. 第一次原型——小尺寸模型
    4. 第二次原型——评估第一次模型的优势、劣势、风险后，重新需求，设计，开发和测试的一个模型
    5. 如果开发风险过大，就舍弃这个系统。如果风险可控，继续开发原型，不断精化，直到客户认为原型可以代表最终产品。
    6. 在最终精化的原型的基础上开发最终产品。并通过系统的测试来降低风险。
  • UP(统一过程)模型：
    用例驱动，架构中心，迭代增量。与UML高度统一。
    起始->细化->构造->交付->起始->...
  • 喷泉模型是一种以用户需求为动力，以对象为驱动的模型。认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
    

第四章 敏捷

• 敏捷开发宣言：
  个体和交互 胜过 过程和工具
  可以工作的软件 胜过 面面俱到的文档
  客户合作 胜过 合同谈判
  响应变化 胜过 遵循计划
  虽然右项也有价值，但是我们认为左项具有更大的价值
• 敏捷
  适应变更、交流通畅、客户参与、有效控制。
• 极限编程
  
  • 极限是敏捷过程中最常见的模型
  • 极限过程：
    策划 策划产生一系列"用户故事"(user stories),XP团队成员评估每一个故事并给出成本。故事被分组为许多可交付的增量。按交货日期分配任务。
    设计 设计严格遵守KIP原则(keep it simple) CRC卡作为XP过程的唯一工作产品，建立spike sulutions，鼓励重构
    编码 先开发一系列用于检测本次增量发布实验的所有故事的单元测试，再针对单元测试进行编码，鼓励结对编程。
    测试 单元测试纳入日常活动，推行客户验收测试。
    
  • 重构：
    重构是指不改变代码外部行为而改进其内部结构的过程

第六章 系统工程

• 概念：
  
  • 以计算机为基础的系统要素
    软件、硬件、人员、数据库、文档、规程等等组成计算机系统的要素
  • 系统
    宏要素的层次。
  • 业务过程建模(BPE)
    BPE的目标是定义一个能有效利用信息进行业务活动的体系
  • 系统架构:数据架构、应用架构、技术基础设施
• 系统建模
  
  • 定义在所考虑视图中满足需要的过程
  • 描述过程行为和该行为所依据的假设
  • 明确定义模型的内部和外部输出
  • 描述有助于工程师理解视图的全部联系（包括输出）
• 系统模型分类
  
  • Hatley-Pirbhai建模
    输入、处理、输出、用户界面处理、自检处理
  • UML建模

第七章 需求工程

• 需求工程的任务
  
  • 起始
    建立对需求的基本理解
  • 导出
    导出需求信息，包括范围问题，理解问题，易变问题
  • 精化
    建立分析模型来表示信息、功能和行为
  • 协商
    让开发者与客户在一个可交付的系统上达成共识（主要是让客户理解到有些功能不切实际）
  • 规格说明
    正式或非正式地描述需求（不是任选，而是根据实际情况选择），例如对于大型系统建立文档，小型系统说明使用场景
  • 确认
    评审需求工程的工作产品。
  • 管理
    管理可能变更的需求
• 需求工程的工作产品(working product)
  
  • 必要性和可行性陈述
  • 系统或产品范围的界限说明
  • 参与需求导出的客户、用户和其他共同利益者的列表
  • 系统技术环境的说明
  • 需求列表以及每个需求适用的领域限制
  • 使用场景列表
  • 任何能够更好定义需求的原型
• 需求开发的方法
  
  • CRG Meeing 协同的需求收集会议
  • Quality Function Deployment QFD 质量功能部署
    将客户需求转化为技术需求. QFD的目的是最大限度地让客户从软件工程过程中感到满意. 为此, QFD强调理解“什么是对客户有价值的”.
  • 导出工作产品

第八章 构建分析模型

• 分析模型的作用，可以让软件工程师：
  
  • 详细描述基础需求
  • 对使用场景、功能活动等等建模
• 分析模型的构建原则
  
  • 目标原则
    
    1. 描述客户需要什么
    2. 为软件设计奠定基础
    3. 定于在软件完成后可以被确认的一组需求
  • 经验原则
    
    1. 模型应该关注可见的需求，在相对高的抽象层次，不关心具体实现
    2. 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解
    3. 技术基础结构和其他非功能的模型在这个阶段不考虑
    4. 最小化系统内部的关联（低耦合）
    5. 确认分析模型对所有共同利益者都有价值
    6. KIS（keep it simple），尽可能简洁
• 分析模型的构建方法
  
  • 场景建模
    用例图、部署图
  • 类建模
    类图、协作图
  • 行为建模
    状态图、活动图、顺序图

第九章 设计工程

• 抽象abstraction
  
  • 过程抽象 具有明确和有限功能的指令序列.
  • 数据抽象 描述数据对象的冠名数据集合.
• 架构architecture
  
  • 软件的整体结构和这种结构为系统提供概念上完整性的方式
  • 程序构件的结构或组织+和构件的交互形式+构件所用的数据结构
• 模式patterns
  已证实的解决方案集
• 逐步求精refinement
  
  • 自顶向下的设计策略
  • 通过连续精化层次结构的程序细节来实现程序的开发
• 模块化modularity
  
  • 将软件划分为独立命名的、可寻址的构件，被称为模块，把这些模块集成到一起满足问题的需求
  • 避免过低或过高的模块化，应该遵循以下原则：
    
    1. 使软件开发更容易；
    2. 可以定义和交付软件增量；
    3. 更容易实施变更；
    4. 能够更有效地开展测试和调试
• 信息隐藏information hiding
  每个模块对其他所有模块都隐藏自己的设计决策。
• 功能独立functional independence
  
  • 是模块化、抽象概念和信息隐藏的直接结果。
  • 开发具有专一功能且避免与其他模块过多交互的模块实现功能独立
  • 高内聚、低耦合
• 重构refactoring
  不改变代码的外部行为的情况下改进其内部结构的过程。

第十章 体系结构(架构)设计

• 为何进行体系结构设计？，可以让软件工程师：
  
  • 分析设计在满足需求方面的有效性
  • 有机会在设计变更成本还很小时考虑架构的替换
  • 减少软件构建的风险
• 体系结构风格(style)
  
  • 以数据为中心的体系结构
  • 数据流体系结构
  • 调用和返回体系结构
  • 面向对象的体系结构
  • 层次体系结构

第十一章 构件级建模

• 什么是构件？
  一个模组化的，可部署和可替换的系统组成，封装了内部实现，并公开了一系列接口。
• 构件的设计原则
  
  • 开关原则(OCP)
    模块应该对扩展具有开放性，对修改有封闭性。
  • 李氏替换原则(LSP)
    子类应该可以替代他们的基类的
  • 依赖倒置原则(DIP)
    构件应该依赖于抽象，而非具体实现
  • 接口分离原则(ISP)
    多个用户专用接口比一个通用接口好
  • 发布复用等价性原则(REP)
    复用的粒度就是发布的粒度
  • 共同封装原则(CPP)
    一同变更的类应该合在一起(类应该根据其内聚性进行打包)
  • 共同复用原则(CRP)
    不能一起复用的类不能被分到一组。
• 内聚性
  构件或者类只封装哪些相互关联密切，以及与构件或类自身有密切关系的属性和操作
  
  • 功能内聚 应用于操作(方法、函数)。模块内所有元素共同完成一个功能。
  • 分层内聚 应用于包。高层可以访问低层，但低层不可以。
  • 通信内聚 所有需要相同数据的操作都在一个类里定义。
• 耦合性
  类之间彼此联系程度的一种定性度量
  
  • Content coupling 内容耦合——避免
    一个构件可以偷偷地修改另一个构件的内部数据
  • Common coupling 共用耦合——警告
    很多组件共用相同的全局变量
  • Routine coupling 常规耦合——小心
    import,typeuse,routine call..
• 构件设计方法
  
  • 程序设计语言（PDL）：伪代码
  • 程序流程图
  • 决策表

第十三章 第十四章 测试

• 测试策略
  
  • 单元测试
    测试单独的软件构件。接口、数据结构、边界情况、独立路径，错误处理路径。需要驱动。
  • 集成测试
  • 一步到位big bang
  • 自顶向下top down-增量集成
    集成步骤：
    
    1. 主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模块；
    2. 根据集成的方式（深度或广度），每次用一个替换从属的桩模块；
    3. 在每个模块被集成时，都必须已经进行了单元测试；
    4. 进行回归测试以确定集成新模块后没有引入错误
    5. 重复2-4，直到集成完成
  • 自底向上bottom up-增量集成
  • 确认测试
    测试应用作为一个整体能够完成用户需求
  • 系统测试
    在整个系统的上下文(context)中测试应用
  • 回归测试
    选择性地对已变更系统的重新测试，检测有没有新的错误被引入
• 测试用例
  测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
• 测试技术
  
  • 白盒测试
    了解产品的内部运行情况，对所有内部构件进行充分测试
    测试用例满足：
    
    1. 保证每一个模块的所有独立路径至少被执行一次;
    2. 对所有的逻辑值均测试true和false
    3. 在上下边界以及可操作的范围内执行所有的循环;
    4. 检验内部数据结构以保证其有效性
       技巧：基本路径测试：流图、环复杂度、独立路径
  • 黑盒测试
    在软件的接口处执行测试。不关心软件的内部结构
    技巧：基于图的测试方法、等价划分、边界值分析、正交数组测试
  • 手工测试与自动化测试

第二十一章 项目管理

• 4P's
  
  • People 人 成功项目最重要的元素
    
    1. 利益相关者
    2. 领导者 MOI模型=motivation+organization+ideas
    3. 软件团队 封闭式、随机式、开放式、同步式
    4. 团队合作与交流 正式/非正式？个人的/非个人的？
  • Product 产品 软件本身
    
    1. 软件范围：上下文(context) 信息目标 功能和执行
    2. 问题分解
  • Process 达成目标设置的框架活动和软件工程任务集
    任务集=
    
    1. 软件工程任务
    2. 工作产品
    3. 质量关注点
    4. 里程碑
  • Project 所有的工作的集合
• W5HH
  why what when whi where how howmuch

第十五章 第二十二章 度量

• McCall的软件质量因素
  
  • 
• measure,metrics&indicators
  
  • measure 测度——为产品或过程的某些属性的程度、数量、维数、容量或大小提供量化的指示
  • metrics 度量——度量是一个系统、构件或者过程具有给定属性的量化测量程度。
  • 当收集了一个数据点，就是建立了一个测度。收集了多个数据点产生测量。
  • indicators 指标——一个或多个度量的组合。提供了对过程、项目或产品本身的深入理解。
• 度量的作用
  
  • 产品度量有助于软件工程师对其设计和狗啊哦的软件获得深层次的了解。
  • 产品度量为分析、设计、编码和测试能更客观地执行和更定量的评估提供基础
  • 过程度量的收集涉及所有项目，要经历相当长的时间。目的是提供能够引导长期的软件过程改进的一组过程指标。
  • 项目度量使得软件项目管理者能够:(1)评估正在进行中的项目的状态(2)跟踪潜在的风险(3)在问题造成不良影响之前发现他们(4)调整工作流程或任务(5)评估项目管理团队控制软件工作产品质量的能力

第二十三章 估算

• 项目策划任务
  
  • 确定项目范围
  • 确定可行性
  • 分析风险
  • 确定需要的资源
    人力资源
    可复用的软件资源
    环境资源
  • 估算成本与工作量
    问题分解
    使用规模、功能点、过程任务集、用例方法建立两套或更多估算方案
    使多种估算方法结果一致
  • 确定项目进度计划
    建立有意义的任务集
    定义任务网络
    使用日程计划工具
    定义计划跟踪机制
• LOC&FP
  
  • 都是软件规模估算的方法
  • 直接方法：LOC(代码行)
  • 间接方法：FP(功能点)

第二十四章 进度

• 任务网络与关键路径
  
• 里程碑管理

第二十五章 风险管理

• 被动和主动风险管理
• Risk Management Paradigm( 风险管理范例）
  识别->分析->计划->追踪->控制
• RMMM风险缓解、监测和管理计划
  
  • RMMM计划将所有的风险分析工作文档化
  • 建立风险信息表单(risk information sheet, RIS)
  • 三个主要目的：
    
    1. 评估所预测的风险是否真的发生了
    2. 保证正确地实施了各风险的环节步骤
    3. 收集能够用于今后风险分析的信息
       ##第二十六章 质量管理
• 软件质量因素：
  
  • McCall
  • 设计质量
  • 一致性质量
• 软件质量评审活动(SQA活动)
  
  • 为项目准备SQA计划
  • 参与开发 项目的软件过程描述
  • 评审软件工程活动，以验证其是否符合定义的软件过程
  • 审核指定的软件工作产品，以验证其是否符合定义的软件过程中的相应部分
  • 确保软件工作以及工作产品中出现的偏差已经文档化
  • 记录所有不符合的部分，并报告给高层管理者
• 正式技术评审(FTR)一种SQA方法
  
  • 目标：
    
    1. 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误
    2. 验证评审中的软件是否满足需求
    3. 保证软件的表示符合预先定义的标准
    4. 得到以统一方式开发的软件
    5. 使项目更加易于管理
  • 评审会议
  • 评审报告以及记录保存
  • 评审指导原则：
    
    1. 评审工作产品，而不是生产者
    2. 制定并且遵守日程表
    3. 限制争论和辩驳
    4. 不试图解决所有记录的问题
    5. 做笔记
    6. 限制参与者人数，并坚持事先准备
    7. 为每个工作产品建立检查表
    8. 为FTR分配专门的时间
    9. 对评审者进行有意义的培训
    10. 评审以前的评审
  • 样本驱动
• 软件质量的成本
  
  • 预防成本：质量计划、正式技术评审、测试设备、培训
  • 鉴定成本-深入了解“首次通过”各个过程时的产品状态而开展的活动：
    过程内和过程间的审查，设备校准和维护，测试
  • 失效成本-如果在产品交付给客户之前没有缺陷就不会存在的成本，分为内部和外部：
    内部：返工、修复、失效模式分析
    外部：解决客户抱怨、退换产品、求助电话支持、保修工作

第二十七章 变更

• 软件配置项：
  在软件过程中产生的信息项，包括程序、文档、数据等。
• 基线：
  已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，只有通过正式的变更控制才能修改他
• 版本控制
  结合了规程和工具，用来管理在软件过程中所创建的配置对象的不同版本。
• 软件配置管理(SCM)过程
  
  • 目标：
    
    1. 统一标识软件配置项
    2. 管理一个或多个软件配置项的变更
    3. 便于构造应用的不同版本
    4. 在配置随时间演化时，确保能够保持软件质量
  • 活动：
    
    1. 标识软件配置
    2. 版本控制
    3. 变更控制
    4. 配置审核
    5. 状态报告