软件工程

• CMM(能力成熟模型)

  • 五个级别
    • 初始级(杂乱无章很混乱，没有明确定义的步骤，完成依赖英雄式核心人物的作用)
    • 可重复级(建立基本的项目管理过程和实践来跟踪项目费用、进度和功能特性)
    • 已定义级(管理和工程两方面的软件过程已经文档化、标准化，综合成标准软件过程)
    • 已管理级(软件过程的产品质量被开发组织成员所理解和控制)
    • 优化级(接受了过程质量的反馈、新观念、新技术，不断持续改进)

• CMMI(能力成熟模型集合)

  • 阶段式模型
    • 初始的 过程不可预测且缺乏控制
    • 已管理的 过程为项目服务
    • 已定义的 过程为组织服务
    • 定量管理的 过程已度量和控制
    • 优化的 集中于过程改进
  • 连续式模型
    • 未完成的 过程域未执行或者未得到
    • 已执行的 可标识的输入工作产品转换成输出
    • 已管理的 集中已管理的过程的制度化
    • 已定义级的 集中已定义的过程制度化
    • 定量管理的 可定量管理的过程的制度化
    • 优化的 使用量化手段改变和优化过程域

• 软件过程模型

  • 软件开发全部过程、活动和任务的结构框架
  • 瀑布模型
    • 需求分析、设计、编码、测试、运行与维护
    • 由前至后相互衔接的固定次序，到是某个阶段可以不需要关心前面的阶段，必须要就需要回朔成本很大
    • 优点:容易理解、管理成本低，强调开发的阶段性早期计划及需求调查和产品测试
    • 缺点:客户必须完整清晰表达需求，需要到项目结束之前才可以演示，前期的问题到后面才可以发现问题，风险控制能力较弱
  • V模型 是瀑布模型的变体，描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系
    • 提供了一种将验证确认活动应用于早期软件工程工作中的方法。有一系列测试
  • 增量模式
    • 将需求分段为一系列增量产品，每一个增量可以分别开发
    • 第一个增量往往是核心的产品1.0，往后都是增加新的功能2.0 3.0
    • 优点:有瀑布模型的所有优点，第一个可交付版本所需要的成本和时间很少；风险较小；减少用户需求的变更
    • 缺点:没有对用户的变更要求进行规划，会对后来的增量的不稳定；不像早期思考的稳定，一些增量可能需要重新开发；可能会超出组织的能力
  • 演化模型(原型模型和螺旋模型)
    • 是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。适用于对软件需求缺乏准确认识的情况
    • 原型模型
      • 比较适合于用户需求不清、需求经常需要变化的情况 不适于大规模软件
      • 目的是快速低成本地构建原型，迅速给用户看到一个系统框架，在提出需求
      • 交流=》快速计划=》快速设计方式建模=》构建原型=》部署交付和反馈
    • 螺旋模型 加入风险分析
      • 适用于庞大、复杂化并且有高风险的系统；支持用户需求的动态变化
      • 需要开发人员丰富的评估经验和专门知识，过多的迭代次数增加成本，延迟提交时间
      • 螺旋周期的四个步骤
        • 制定计划：确定软件的目标，选定实施方案，明确项目开发的限制条件
        • 风险分析：分析所选的方案，识别风险，消除风险
        • 实施工程：实施软件开发，验证阶段性产品
        • 用户评估：评价开发工作，提出修改建议，建立下一个周期的开发计划
    • 喷泉模型
      • 以用户需求为动力，以对象作为驱动的模型，适用于面向对象的开发方法
      • 开发过程具有迭代性(常常需要重复多次)和无间隙性(没有明显的边界)
      • 允许各开发活动交叉、迭代地进行
      • 优点:提高软件项目的开发效率节省开发时间，缺点是:需要大量人员，不利于项目的管理，要求严格管理文档，使得审核的难度加大

• 统一过程(UP)模型

  • 用例和风险额驱动、以架构为中心，迭代(5个核心工作流)并且增量的开发过程，由UML方法和工具支持
  • 袖珍项目:计划、分析和设计、构造、集成和测试，以及内部和外部发布
  • 4个技术阶段
    • 起始阶段：生命周期目标
    • 精化阶段：生命周期架构
    • 构造阶段：初始运作功能
    • 移交阶段：产品发布
  • 统一过程的典型代表是RUP。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细

• 敏捷方法

  • 尽可能早地、持续地对有价值的软件的交付使客户满意 每一种方法基于一套原则(敏捷宣言)

  • 极限编程XP

    • 价值观、原则、实践和行为4个部分
      

  • 水晶法Crystal

    • 水晶法人为每一个不同的项目都需要一套不同的策略、约定和方法论

  • 并列争求法Scrum

    • 把每30天一次的迭代称为一个冲刺

  • 自适应软件开发ASD
    

  • 敏捷统一过程AUP

    • 采用大型上连续，小型上迭代的原理来构建软件系统
    • 迭代执行活动:建模、实现、测试、部署、配置及项目管理、环境管理

• 软件需求
  

• 系统设计

  • 系统设计的结果是一系列的系统设计文件，是实现信息系统的重要基础
  • 概要设计阶段
    • 设计软件系统结构:将一个复杂的系统按功能划分成模块:确定每个模块的功能；调用模块之间的调用关系；确定模块之间的接口既模块之间传递的信息；评价模块结构的质量。是概要设计关键一步，直接影响下一阶段详细设计与编码的工作
    • 数据结构与数据库设计 数据库设计:概念、逻辑、物理设计
    • 编写概要设计文档:文档有概要设计说明书、数据库设计书、用户手册以及修改测试计划
    • 评审:实现了需求规定的功能、性能，设计方法的可行性，内外接口定义的正确性进行评审
  • 详细设计
    • 对每个模块进行详细的算法设计
    • 对模块内的数据结构设计
    • 对数据库进行物理设计，既确定数据库的物理结构
    • 其他设计:代码设计 输入/输出格式设计 用户界面设计
    • 编写详细设计说明书
    • 评审:对处理过程的算法和数据库的物理结构都要评审

• 系统测试

  • 意义:为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误
  • 目的:希望以最少的人力和时间发现潜在的各种错误与缺陷 一般都是软件测试
  • 保证系统质量和可靠性的关键步骤，系统分析系统设计的最后复查 遵循以下原则
    • 尽早并不断地进行测试
    • 测试工作应由专门人员来进行，这样会更客观、更有效
    • 设计测试方案时，将实际输出结果与预期结果相比较就能发现测试对象是否正确
    • 设计测试用例时，合理的、不合理的都要输入测试
    • 测试程序时，检查有没有多余的工作
    • 严格按照测试计划来进行
    • 妥善保存测试计划测试用例，作为软件文档的组成部分，为维护提供方便
    • 测试用例都是精心设计出来的，可以为重新测试或者追加测试提供方便
    • 系统测试阶段的测试目标来自于需求分析阶段

• 软件测试

  • 单元测试(模块测试)
    • 在模块编写完成且无编译错误后就可以进行 白盒测试
    • 测试内容:单元测试主要检查模块以下的五个特征

      • 模块接口:保证测试模块的数据流正确的流入流出
        

      • 局部数据结构

        • 变量的说明是否合适
        • 是否使用未赋值或为初始化的变量
        • 变量的初始值或默认值是否正确
        • 变量名是否有错

      • 重要的执行路径

      • 出错处理

      • 边界条件

    • 单元测试过程
      • 模块不是独立运行的，各模块之间存在调用被调用的关系，对模块测试时，需要开发两种模块
        • 驱动模块:接收测试例子的数据，送到测试模块，输出测试结果
        • 桩模块:内部可以进行少量数据处理，目的是为了检验入口，输出调用和返回的信息
  • 集成测试
    • 自顶向下集成测试
      • 一种构造软件体系结构的增量方法；最上面是驱动模块(主控模块)，后面替换成桩模块(抽象到具体)，以深度或广度优先方式逐步向下。
      • 不用编写驱动模块，需要编写桩模块
    • 自底向上集成测试
      • 不需要编写桩模块，需要编写驱动模块
      • 连接底层的桩模块变成簇；编写驱动模块；测试簇；去掉驱动模块，继续向上连接簇
    • 回归测试
      • 重新执行已执行过的某些子集，已确保变更没有传播不期望的副作用
      • 保证变更不引入无意识行为或额外的错误
    • 冒烟测试
  • 确认测试
  • 系统测试

• 测试方法

  • 静态测试:不在机器上运行
    • 人工检测
    • 计算机辅助静态分析
  • 动态测试
    • 黑盒测试
      • 等价类划分：有效等价类50和无效等价类101 0-100
      • 边界值分析：0-100 输入0 -1 100 101
      • 错误推测：凭感觉
      • 因果图 转换为判定表
      • ps:两个输入都是不合理的时候那它就是不合理的测试用例
      • McCabe度量法
        • 环路的个数公式:V(g)=m-n+2 m是G中的有向弧 n是节点数 或者 闭合区域+1
    • 白盒测试
      • 原则：所有独立路径至少执行一次；取真或假的两种情况至少都能执行一次；循环在边界跟一般条件个执行一次；测试程序内部数据结构的有效性
      • 逻辑覆盖
        • 语句覆盖
          • 选择足够的测试数据，使被测试程序中的每条语句至少执行一次，是很弱的逻辑覆盖
        • 判定覆盖(分支覆盖)
          • 真分支、假分支都要执行一次
        • 条件覆盖
          • 每一语句中的每个逻辑条件的各种可能的值至少满足一次(判断语句里面每一个条件的真假值都要)
        • 判定/条件覆盖
          • 上面两种的结合
        • 条件组合覆盖
          • 判定条件的各种可能值的组合都至少出现一次
        • 路径覆盖
          • 覆盖被测试程序中所有可能的路径 强的逻辑覆盖
      • 循环覆盖：执行足够的测试用例，使得循环中的每个条件都得到验证
      • 基本路径测试

• 系统维护概述

  • 软件维护是软件生命周期的最后一个阶段，不属于系统开发过程

  • 系统可维护概念

    • 维护人员理解、改正、改动和改进这个软件的难易程度。
    • 可维护性的评价指标
      • 可理解性、可测试性、可修改性
    • 硬件维护、软件维护、数据维护

  • 软件维护

    • 文档是软件可维护性的决定因素，很重要的
    • 维护期通常比开发长的多，投入也多
    • 可维护性是每个软件都应具有的特点，必须在开发阶段保证软件具有可维护性，每一阶段都应该考虑提高可维护性
    • 进行质量保证审查可以提高软件产品的可维护性，可维护性是衡量软件质量的一个重要特性
    • 维护内容
      • 正确性维护：改正错误 17-21%
      • 适应性维护：适应信息技术变化和管理需求变化而进行的修改 18-25%
      • 完善性维护：扩充功能和改善性能而进行修改 比重较大50-60%
      • 预防性维护：主动增加预防性的新的功能 4%

  • 软件文档

    • 文档也是软件产品的一部分，没有文档的软件就不能称之为软件
    • 编写高质量文档可以提高软件开发的质量
    • 软件文档的编制在软件开发工作中占比突出的地址和相当大的工作量
    • 高质量文档对于软件产品的效益有着重要的意义
    • 总的来说，软件文档只好不坏，选项中说软件文档不好就是错的

  • 软件的质量属性
    

  • 沟通路径

    • 有主程序员:n-1 无主程序员:n(n-1)/2

• 软件项目估算

  • COCOMO模型：是一种精确的、易于使用的成本估算模型
    • 基本COCOMO模型是静态单变量模型
    • 中级COCOMO模型是静态多变量模型，分为系统和部件
    • 详细COCOMO模型，分为系统、子系统和模块
  • COCOMOII模型(规模估算选择)
    • 应用组装模型(对象点)
    • 早期设计阶段模型(功能点)
    • 体系结构阶段模型(代码行)

• 进度管理

  • Gantt图(甘特图)
    • 清晰地描述每个任务从何时开始到何处结束，任务的进展情况以及各个任务之间的并行性
    • 不能清晰地反应各个任务之间的依赖关系，难以确定项目的关键所在，不能反应计划中有潜力的部分
  • PERT图(项目计划评审技术图)
    • 有向图，箭头表示任务，可以标上该任务需要的时间；不能反应任务的并行关系，可以依赖
    • 流入结点的任务就为结束，流出结点的为开始，结点为事件；都结束了才出现才可以开始
    • 开始结点:没有指向它的任务，最早时刻是0，可以有多个，
    • 结束结点：没有指向出去的任务，最迟时刻跟最早时刻同一天，只有一个
    • 最早时刻：在此时刻之前该时间出发任务不可能开始，前面那个的最早时刻加任务时间就是自己的最早时刻，如果多个就取最大值的最早时间
    • 最迟时刻：出发的任务最迟在此时刻开始，不然工程不能如期完成；前面的最迟时刻减去任务时刻，遇到多个取最小值时刻
    • 松弛时间=最迟时刻-最早时刻 多条也要单独算出来
    • 关键路径:松弛时间都是为0的路径
  • 项目活动图
    • 顶点是项目里程碑，连接顶点的边表示活动，边上的值表示完成活动所需要的时间
    • 关键路径的长度等于结束顶点的最迟时刻

• 软件配置管理

  • 配置数据库：开发库、受控库、产品库
    

• 软件风险管理

  • 不确定性和损失

    • 项目风险：威胁到项目计划，项目复杂度、规模及结构不确定也属于
    • 技术风险：威胁到开发软件的质量跟交付时间。原因是问题比我们所想的更加难以解决
    • 商业风险：威胁到开发软件的生存能力，且常常危害到项目或产品；五个项目风险:市场、策略、销售、管理、预算

  • 风险识别

    • 系统化的指出项目计划(估算、进度、资源分配等)的威胁，识别后尽可能的回避，控制风险，不可能完全避免的，能避免就避免，实在不行只能干预降低风险

    • 风险条目检查表识别以下几种类型的风险
      

    • 风险因素包括性能、成本、支持和进度
      

  • 风险预测(风险估计)：从两个风险概率和后果方面评估风险；建立风险表 严重程度高到低1 2 3 4
    

    • 评估风险影响:风险的本质、范围、时间会影响风险所产生的后果
    • 风险暴露RE=P*C P发生的概率 C后果

  • 风险评估

    • 对风险评估很有用的技术定义风险参照水准(成本、进度、性能是典型的风险参照水准)三元组(风险、概率、后果)

  • 风险控制

    • 辅助项目组建立处理风险的策略；
    • 应对风险最好就是主动避免风险；
    • 风险监控：项目管理者监控某些因素
    • RMMM计划(风险管理策略)：可以包含在软件项目计划中 ；试图找到起源

• 软件质量

  • ISO/IEC9126软件模型:第一层质量特性，第二层质量子特性，第三层度量指标
    

• Mc Call软件质量模型:

• 软件评审

  • 设计的规格说明书符合用户的要求称为设计质量
    • 评价软件的规格说明是否合乎用户的要求
    • 可靠性:是否能避免输入异常、一间失效及软件失效所产生的失效
    • 评审软件是否有复用性、可测试性、可修改性、可扩充性、可互换性、可移植性
    • 评审性能，保密措施、操作特性实现情况
  • 程序按照设计规格说明所规定的情况正确执行称为程序质量
    • 软件本身的结构、运行环境的接口以及变更带来的影响而进行的评审活动
    • 结构：功能结构、功能的通用性、模块的层次(静态)、模块结构、处理过程的结构
      • 模块结构：控制类结构、数据流结构、模块结构与功能结构直接的对应消息
    • 与运行环境的结构
      • 与硬件的接口、与用户的接口
    • 正式技术评审的目标发现软件中的错误

• 软件容错技术

  • 实现容错的主要手段是冗余:结构冗余(静态动态冗余、混合冗余)、信息冗余、时间冗余、冗余附加技术
    

• 软件工具

  • 用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件
  • 软件开发工具
    • 需求分析工具、设计工具、编码与排错工具、测试工具
  • 软件维护工具
    • 版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具

• 拓展

  • 面向对象方法有：Booch方法、Coad方法、OMT方法
  • 软件复杂性度量：规模、结构、难度、智能度
  • 软件工程基本要素:方法、工具、过程