• 软件过程

  • 能力成熟度模型 CMM

  • 五个成熟度级别：

    1. 初始级，杂乱无章，混乱，靠英雄式核心人物

    2.可重复级，基本项目管理过程和实践跟踪，有必要的过程准则
    3.已定义级，软件过程文档化、标准化，标准软件过程
    4.已管理级，软件过程的产品质量被理解和控制
    5.优化级，加强定量分析，通过过程质量反馈、新观念、新技术持续改进

  • 能力成熟度模型集成 CMMI

  • 阶段式模型，类似 CMM

  • 连续式模型，有六个等级，0-5

    1. CL0，未完成的，未执行或未得到

  • 已执行的，共性目标：可标识输入转换可标识输出工作产品
    logseq.order-list-type:: number

  • 已管理的，共性目标：已管理过程的制度化
    logseq.order-list-type:: number

  • 已定义级的，共性目标：已定义过程的制度化
    logseq.order-list-type:: number

  • 定量管理的，共性目标：可定量管理的制度化
    logseq.order-list-type:: number

  • 优化的，使用量化手段改变和优化过程域
    logseq.order-list-type:: number

  • 软件过程模型

  • 瀑布模型

  • 包括需求分析、设计、编码、测试、运行与维护

  • 以项目阶段评审和文档控制为手段有效地对整个开发过程进行指导，文档驱动，适用于软件需求很明确的软件项目模型

  • 优点，容易理解，管理成本低

  • 缺点，客户要完整清晰地表达需要；开始的两个或三个阶段，很难评估真正的进度状态；错误往往后期才能发现，项目风险控制能力弱

  • image.png

  • V模型

  • 瀑布模型变体，基本作为干扰项出现，看到基本可选瀑布模型

  • 就是用一系列测试（质量保证活动）

  • 增量模型

  • 将需求分段为一系列增量产品，客户对每个增量的使用和评估作为下个增量开发

  • 第一个增量往往是核心产品

  • image.png

  • 优点：瀑布模型所有优点，第一个可交付版本需要成本和时间很少，风险不大，减少用户需求变更

  • 不足，若没有对用户变更需求进行规划，初始增量可能要重新开发、发布，成本、进度和复杂度失控。

  • 演化模型

  • 是迭代的过程模型，使用户对软件需求缺乏准确认识的情况

  • 典型的有原型模型和螺旋模型

  • 原型模型（快速原型）

  • 适用于用户需求不清、经常变化的情况；系统规模不是很大，也不太复杂
    image.png{:height 289, :width 344}

  • 快速低成本构建原型（易于理解的框架），可有效捕获系统需求

  • 注意，该模式使不断改进后才部署使用，演化（迭代）模型则是投入使用后，再迭代

  • 螺旋模型

  • 瀑布模型和演化模型结合，并加入风险分析，特别适合庞大、复杂且有高风险的系统，风险驱动
    image.png

  • 相比瀑布模型，优点：能适应需求动态变化，提高软件适应能力；

  • 缺点：但需求开发人员有丰富的风险评估经验和专门知识，过多迭代次数会增加开发成本、延迟交付时间

  • 喷泉模型

  • 用户需求为动力，以对象作为驱动的模型，适用面向对象开发方法
    image.png

  • 克服瀑布模型不支持软件重用和多项开发活动集成的局限性。无间隙，允许各开发活动交叉、迭代进行（无明显界限）

  • 优点：提高开发效率

  • 缺点，需要大量开发人员，要求严格管理文档，审核难度加大

  • 统一过程（UP）模型

  • 用例和风险驱动，以架构为中心，迭代且增量的开发过程

  • 起始阶段，项目初始活动，目标

  • 精化阶段，需求分析和架构演进

  • 构建阶段，系统构建，产生实现模型，功能

  • 移交阶段，软件移交，产品发布

  • 典型代表是 RUP，是 UP 更完整更详细

  • 基于构件的开发模型

  • 用预先打包好的软件构件（内部开发或商品化的成本软件构件）来开发系统，有螺旋模型的优点，本质上是演化模型，不要求面向对象方法

  • 敏捷方法

  • 尽可能早、持续地对有价值的软件交付

  • 每个方法基于一套原则，实现了敏捷宣言（敏捷方法的理念）

  • 极限编程 XP

  • 4个价值观：沟通、简单性、反馈和勇气

  • 5个原则

  • 12个最佳实践：计划游戏（快速制定计划）、小型发布（尽快交付系统设计）、隐喻（用合适比喻传达信息）、简单设计（只处理当前请求，使设计保持简单）、测试先行（先写测试再写程序）、重构（重新审视需求和设计，重新描述以满足需求）、结对编程（相当于两个人，一个人写一个人看着写，可轮流）、集体代码所有制、持续集成（按日甚至按小时为客户提供可运行的版本）、每周工作40小时、现场客户和编码标准

  • 水晶法

  • 认为不同项目需要一套不同的策略、约定、方法论

  • 并列争求法

  • 迭代，30天一次迭代叫冲刺

  • 自适应软件开发 ASD

  • 有6个基本原则，暂时懒得背

  • 敏捷统一过程 AUP

  • 采用在大型连续，在小型迭代的原理构建，采用经典的 UP 阶段性活动

  • 软件需求

  • 功能需求，考虑系统做什么，何时做，如何升级等

  • 性能需求，考虑系统技术性指标，储存容量限制、执行速度、响应时间及吞吐量

  • 数据需求，考虑输入输出数据格式，发送数据频率、数据流量等

  • 共十二需求，其余几乎不考

  • 概要设计-设计软件系统总体结构

  • 把复杂系统按功能分成模块，确定模块功能、模块间调用关系、接口、传递信息

  • 是概要设计关键一步，直接影响到详细设计和编码的工作

  • 编写概要设计文档

  • 概要设计说明书、数据库设计说明书、用户手册及修订计划

  • 详细设计

  • 对每个模块算法设计
    logseq.order-list-type:: number

  • 对模块内数据结构设计
    logseq.order-list-type:: number

  • 数据库物理设计
    logseq.order-list-type:: number

  • 其他设计
    logseq.order-list-type:: number

  • 编写详细设计说明书
    logseq.order-list-type:: number

  • 评审
    logseq.order-list-type:: number

  • 设计结果是一系列文档，是实现一个信息系统的重要基础

  • 系统测试

  • 意义，为发现错误而执行程序

  • 目的，尽可能少的人力和时间找出错误

  • 八个基本原则

  • 应尽早不断测试
    logseq.order-list-type:: number

  • 测试避免由开发人员承担
    logseq.order-list-type:: number

  • 要比对预期结果和实际输出结果
    logseq.order-list-type:: number

  • 要包含不合理、异常的情况的测试用例
    logseq.order-list-type:: number

  • 检验程序是否做了不该做的事
    logseq.order-list-type:: number

  • 严格按照测试计划进行
    logseq.order-list-type:: number

  • 妥善保存设计计划、用例
    logseq.order-list-type:: number

  • 测试例子是精心设计的，在系统完善后，重新测试时，可复用以前的测试用例
    logseq.order-list-type:: number

  • 系统测试阶段的测试目标来自于需求分析阶段
    logseq.order-list-type:: number

  • 单元测试

  • 模块编写完成无编译错误就可以进行，一般用白盒测试法

  • 过程：有个驱动模块（主程序），和桩模块（存根模块）检验入口、输出调用和返回的信息

  • 提高模块内聚度有助于单元测试

  • 集成测试

  • 自顶向下集成测试

  • 以DFS或BFS把从属于主控模块的模块集成结构中

  • 不用编写驱动模块，要编写桩模块

  • 自底向上集成测试

  • 从原子模块（最底层）开始构造测试

  • 不用编写桩模块，要编写驱动模块

  • 回归测试

  • 重新测试已测试过的某些子集，保证变更没有传播不期望、引入无意识行为或额外的错误

  • 冒烟测试

  • 频繁评估

  • 测试方法

  • 分静态测试（人工检测和计算机辅助静态分析，没考过）和动态分析（通过运行程序发现错误，重点）

  • 测试用例由测试输入数据和对应的预期输出结果组成，测试用例应包含合理和不合理的输入条件

  • 黑盒测试（把程序当黑盒）

  • 等价类划分，把输入划分法若干等价类，从每个等价类选取代表性测试用例，等价类分有效等价类（符合规则）和无效等价类（不同角度违反规则）

  • 边界值分析，既注重输入条件边界，又适用于输出域测试用例

  • 错误推测，用经验和直觉推测程序中所有可能存在各种错误

  • 因果图，找因（输入）和果（输出）画图

  • McCabe度量法

  • 计算图 G 的环路复杂性, V(G)=m-n+2，m是有向弧个数，n是节点个数

  • （或是闭合区域个数+1）

  • 注意每个边都应有两节点，像下面这样的线要么不算，要么补一个点
    image.png

  • 白盒测试

  • 根据程序的内部结构设计

  • 逻辑覆盖(重要)

  • 语句覆盖，被测试语句每条程序至少执行一次，
    logseq.order-list-type:: number

  • 判定覆盖（分支覆盖），每个判定表达式的真和假至少通过一次
    logseq.order-list-type:: number

  • 条件覆盖，使每个逻辑条件的各种可能的值至少满足一次
    logseq.order-list-type:: number
    image.png

  • 判定/条件覆盖：判定覆盖+条件覆盖
    logseq.order-list-type:: number

  • 条件组合覆盖，使每个判定中条件的各种组合都至少出现一次
    logseq.order-list-type:: number
    image.png

  • 路径覆盖，覆盖被测试程序中的所有路径
    logseq.order-list-type:: number

  • 循环覆盖

  • 执行足够测试用例

  • 基本路径测试

  • 分析环路复杂性，从可执行路径测试

  • 系统维护

  • 系统可维护性评价指标

  • 可理解性、可测试性、可修改性

  • 软件维护

  • 文档是软件可维护性的决定因素，文档十分重要，分用户文档、系统文档

  • 软件工程每个阶段都应考虑软件维护性

  • 软件文档

  • 高质量文档能提高软件开发的质量

  • 文档是软件产品的一部分没有文档的软件不能称为软件

  • 几乎只好不坏

  • 软件维护内容

  • 正确性维护，改开发阶段发生而系统测试阶段尚未发生的错误，占17-21%，有的错误非常重要
    logseq.order-list-type:: number

  • 适应性维护，使软件适应信息技术变化和管理需求变化的修改
    logseq.order-list-type:: number

  • 完善性维护，扩充功能和改善性能，50%-60%，比重较大
    logseq.order-list-type:: number

  • 预防性维护，主动增加预防性新功能，占4%左右
    logseq.order-list-type:: number

  • 软件质量属性

  • 可靠性、可用性、可维护性，用0-1的数字度量

  • 可靠性 系统无失效运行概率 MTTF/(1+MTTF) MTTF 平均无故障时间

  • 可用性 系统正确运行概率 MTBF/(1+MTBF) MTBF 平均失效间隔时间

  • 可维护性 完成维护的概率 1/(1+MTTR) MTTR平均修复时间

  • mean time to failure
    mean time between failures
    mean time to repair

  • 沟通路径

  • n个人，若两两连接，则有 n*(n-1)/2 条沟通路径；若有一个主程序员，则 n-1 条沟通路径

  • 软件项目估算

  • COCOMO 估算模型

  • 基本 COCOMO 模型，静态单变量模型

  • 中级 COCOMO 模型，静态多变量模型

  • 详细 COCOMO 模型，分三个模块

  • COCOMO|| 模型

  • 分为三个阶段性模型，应用组装模型、早期设计阶段模型、体系结构阶段模型，对应三种规模估算选择：对象点、功能点、代码行（功能点可以转为代码行）

  • 进度管理

  • 项目活动图很可能考，其它几个近几年不考

  • Gantt 图 （甘特图）

  • 描述任务何时开始、结束、进展情况和并行性，但不能描述任务之间的依赖关系
    image.png

  • PERT图

  • 箭头是任务，可标上任务所需时间，但不能反应任务的并行关系
    image.png

  • 项目活动图

  • 顶点是项目里程碑，边是活动，值为完成活动所需时间
    image.png

  • 缩短关键路径上活动才能缩短整体工期

  • 记住！！！算关键路径长度别忘了结束的一段

  • 软件配置管理

  • 主要目标（活动），变更标识、变更控制、版本控制、确保变更正确实现，变更报告

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

  • 风险管理

  • 软件风险特性，不确定性（风险可能发生也可能不发生）和损失（风险发生的后果）

  • 风险优先级通常由风险暴露设定（风险影响*风险概率）

  • 项目风险，可能拖延项目进度，增加项目成本（项目复杂度、规模和结构的不确定性也算因素）

  • 技术风险，威胁发开软件质量以及交付时间（问题比设想更难解决）

  • 商业风险，威胁开发软件生存能力

  • 风险识别

  • 风险不能全部避免，可以尽可能干预。一种方法是简历风险条目检查表

  • 风险预测（风险估计）

  • 风险评估

  • 一种方法是定义风险参照水准

  • 风险控制

  • 风险避免，在风险发生前，分析并采取措施
    logseq.order-list-type:: number

  • 风险监管
    logseq.order-list-type:: number

  • RMMM 计划（风险环节、监控和管理计划）
    logseq.order-list-type:: number

  • 软件质量

  • ISO/IEC9126 软件质量模型

  • 虽然必考，但要背的太多，这一分不值
    image.png

  • Me Call 软件质量模型

  • 三个方面确认十一个质量特性，同上不值得
    image.png{:height 390, :width 544}

  • 软件工具

  • 软件维护工具

  • 版本更新工具
    logseq.order-list-type:: number

  • 文档分析工具
    logseq.order-list-type:: number

  • 开发信息库工具
    logseq.order-list-type:: number

  • 逆向工程工具
    logseq.order-list-type:: number

  • 再工程工具
    logseq.order-list-type:: number

  • 项目估算

  • 主要因素，规模、工作量、成本