软件过程

1. 软件描述->软件开发->软件有效性验证->软件进化
2. 基本要素：方法、工具、过程

正式技术评审的目标：发现软件中的错误

模块类型

1. 传入：下属模块数据传给上级模块
2. 传出：上级模块数据传给下属模块
3. 变换：上级模块的数据转换形式后再传回给上级模块
4. 协调：对所有下属模块协调和管理

注意区分上级模块和下属模块

成熟度

CMM 5个：

1. 初始：制度缺乏，无序
2. 可重复：基本管理制度，可跟踪，可重复同类项目
3. 已定义：文档化、标准化、可按需改进
4. 已管理：详细度量标准，有定量的理解和控制
5. 优化：持续改进

CMMI 6个：（0-5）

　　0.未完成：未执行

　　1.已执行：可标识的输入输出，关注于过程域的特定目标

　　2.已管理：过程制度化，监控，控制，评审

　　3.已定义：关注过程的组织和部署

　　4.量化：定量管理

　　5.优化：优化，持续得到改进

软件过程模型

1. 瀑布：
   1. 优点：易理解，管理成本低　　
   2. 缺点：必须需求明确，不适合大型软件，风控弱，已延期和超出预算
2. 增量：瀑布+原型，优先满足核心需求及功能，再在基本需求上不断优化、完善及补充，确定性比原型高
3. 演化：（迭代，需求缺乏准确认知）
   1. 原型：(规模不大，不太复杂）
      1. 快速构造部分需求
      2. 水平：导航，主要用在界面上
      3. 垂直：主要用在算法上
      4. 抛弃式：解决需求不确定、不完整
      5. 演化式：增量式，易于升级和优化，适合Web
   螺旋
   ：（规模庞大，复杂，高风险）
   1. 瀑布+演化
   2. 制定计划+风险分析+实施工程+客户评估
   3. 强调风险分析
4. 喷泉：
   1. 迭代+无间隙
   2. 不利于项目管理和审核
5. UP模型（统一过程）

1. 1. 用例和风险驱动，架构为中心
   2. 迭代+增量
   3. 4个阶段：起始、精华、构建、移交
   4. 5个工作流：需求、分析、设计、实现、测试

敏捷方法

1. 极限编程：
   1. 轻量、高效、低风险、柔性、可预测、科学
   2. 4大价值观+5个原则+12个最佳实践+行为
      1. 4大价值观：沟通、简单、反馈、勇气
      2. 5个原则：快速反馈、简单假设、逐步修改、提倡更改、优质工作
      3. 12个最佳实践：计划游戏、小型发布、隐喻、简单设计、重构、结队编程、集体代码所有制、持续集成、每周40小时、现场客户、编码标准
2. 水晶法：不同项目不同策略、约定和方法论
3. 并列争球法：迭代+冲刺
4. 自适应软件开发：猜测+合作+学习
5. 开放式：虚拟团队，开发不在同一处
6. FDD驱动：开发人员分类。指挥者+类程序员

需求分析->系统设计->系统测试->运行和维护

需求分析

1. 获取
2. 分析与协商：超纲、优先级、冲突
3. 系统建模：结构化分析（SA）：数据流图(DFD)、数据字典(DD)，面向对象分析（OOA）
4. 规约：分析任务的最终产物
   1. 引言
   2. 信息描述
   3. 功能描述
   4. 行为描述
   5. 检验标准
   6. 参考书目
   7. 附录
5. 验证：
   1. 复查：正确性+完整性+清晰性
   2. 评审：目标一致、资料齐全、数据重组、主要功能在范围内、符合约束条件、技术风险、检验标准
6. 管理：
   1. 建立跟踪：正向+逆向
   2. 确保用户需求

系统设计

1. 设计方法：结构化设计（SD）面向对象设计（OOD）
2. 概要设计：
   1. 总体结构
   2. 数据结构与数据库：概念->逻辑->物理
   3. 编写设计文档
   4. 评审
3. 详细设计：
   1. 模块和算法
   2. 模块内数据结构
   3. 代码+输入输出格式+界面
   4. 详细设计说明书
   5. 评审　　　　　　

数据库设计过程

1. 需求分析：数据+功能+性能
2. 概念结构设计：ER图
3. 逻辑结构设计：ER图转换成表
4. 物理设计：存储结构+存取路径
5. 实施：编程+测试+试运行
6. 运行与维护：运行+日常维护

系统测试

原则：

1. 尽早开始
2. 避免开发或小组承担（单元测试除外）
3. 不能穷举
4. 重视群集
5. 严格按计划，避免随意

对象：程序+文档+数据，不包括开发人员

过程：计划->大纲->用例+说明文档->实施->报告

策略：单元测试->集成测试->确认测试->系统测试

单元测试

1. 模块接口
2. 局部数据结构
3. 模块内路劲
4. 边界条件
5. 错误处理

集成测试

把所有模块组装成一个系统测试

1. 非渐增式：先单元，再完整
2. 渐增式
   1. 自顶向下：先上层模块，再下层模块，需要桩模块，不需要驱动模块
   2. 自底向上：先下层模块，再上层模块，需要驱动模块，不需要桩模块
   3. 驱动模块：主程序，装模块：模拟需要调用的模块
3. 回归测试：重新执行已测试过的子集，只包括主要程序功能
4. 冒烟测试：暴露影响构建的错误　　　　

确认测试

1. 进一步检查软件功能和性能
2. Alphea测试(开发者场所)和Beta测试（用户场所）
3. 退化测试是用来防止改动产生的新错误

系统测试

1. 恢复
2. 安全
3. 压力
4. 性能
5. 部署

白盒测试

1. 语句覆盖：每个语句至少执行1次
2. 判定覆盖：每种结果（分支）至少1次
3. 条件覆盖：每个条件至少一次（不同的条件可能出相同的分支结果）
4. 判定/条件覆盖：同时满足判定覆盖和条件覆盖
5. 路径覆盖：每条执行到的路径至少1次

使用判定表看出条件取值的组合

调试

1. 测试之后，开发人员进行
2. 方法：试探、回溯、对分查找、归纳、演绎

运行和维护(生命周期最长）

新旧转换

1. 直接转换
2. 并行准换
3. 分段转换
4. 运行新系统过程：初始->推广->控制->集成->管理

维护

1. 指标：可理解、可测试、可修改
2. 文档：用户文档、系统文档
3. 类型：硬件、软件
4. 内容：
   1. 软件：正确性、适应性、完善性(在使用或运行中添加的需求)、预防性
   2. 数据：安全性、完整性、并发性
   3. 代码
5. 管理：提出修改->领导审查答复->领导分配任务->验收+登记
6. 工具：
   
   1. 版本控制
   2. 文档分析
   3. 开发信息库
   4. 逆向工程
   5. 再工程

评价

1. 立项：规划阶段
2. 中期：实施过程中，里程碑式
3. 结项：正式运行后
4. 内容：
   1. 需求：目标
   2. 规格说明：所有分析和测量，表示软件部件
   3. 记录：执行计划时详细记载
   4. 报告：执行测量和分析的结果，能重复及重新评价

项目管理

范围（4P）

1. 人员：项目管理、高级管理、开发、客户、用户
2. 产品：环境、目标、功能+性能
3. 过程
4. 项目
5. 输入：
   1. 项目章程
   2. 项目范围管理计划
   3. 组织过程资产
   4. 批准的变更申请

估算模型

COCOMO（静态）

1. 基本：静态单变量，只有LOC（源代码行数）
2. 中级：基本+产品、硬件、人员项目等因素
3. 详细：中级+分析、设计各步骤的影响
4. COCOMO II：对象点、功能点、代码行 

Putnam（动态）

进度

1. 基本原则：划分、相互依赖、实践分配、工作量确认、确定责任、明确输出、里程碑
2. 安排：Gantt图、Pert图
   1. Pert图不能描述并行关系
   2. Gant图不能描述依赖关系

组织

1. 基本原则：尽早落实、减少交流接口、责权均衡
2. 模式：项目划分、职能划分（专项组）、矩阵（项目+职能）

配置管理（SCM）

基线、配置项、版本控制、变更控制

配置项

1. 产品组成部分的工作成果：需求文档、设计文档、源码、测试用例
2. 项目管理和机构支撑过程产生的文档：工作计划、项目质量报告、项目跟踪报告

设备清单不属于配置项

 风险管理

1. 识别：性能、成本、支持、进度
2. 预测：建立标准->描述后果->估算影响->标注精度
3. 评估：RE=P x C，P：发生概率，C：成本
4. 控制：避免、监控、RMMM计划

软件质量

1. 内部、外部、使用
2. 满足规定或潜在用户需求的能力

   

工具

特征：

1. 覆盖整个软件周期
2. 为项目调度提供多种手段
3. 估算模型进行估算
4. 支持多项目和子项目管理
5. 确定关键路径、松弛时间、超前实践、滞后时间
6. 成语与任务间的通信辅助
7. 资源平衡
8. 跟踪资源使用
9. 生成固定格式的报表和报告

不具备指导性作用　

补充

冗余附加技术：

1. 备份程序的存储及调用（不是关键程序）
2. 纠错检测及恢复
3. 容错固化　　

环路复杂性（McCabe）

　　V(G)=E-N+2，E:边数，N:节点数

开发方法

1. 原型法：需求不清晰+多变
2. 结构化法：规模不大+不复杂+不多变
3. Jackson法：以数据结构驱动+规模小

------------------------------------------------------------------------------------------

模块划分原则：

1. 大小适中
2. 扇入扇出合理
   1. 扇出大=复杂度高，扇入大=复用度高
   2. 顶层扇出大，中间删除较少，底层扇入大
   3. 一般扇入扇出系数在3或4，不超过7
3. 深度宽度合理　　

完善模块不能改进设计质量

体系结构风格

1. 仓库风格：
   1. 优点：多方法、可更改、可维护、可重用、支持容错和健壮
   2. 缺点：测试困难、选择太多、效率低、成本高、缺少并行支持
   3. 包括：数据库系统、黑板系统、超文本系统

数据仓库

1. OLAP：针对联机数据访问与分析，通过多维的方式对数据进行分析、查询和报表

UML图

1. 用例图：描述参与者必须要完成的任务
2. 类图：类名、接口、属性、操作、关系：依赖，泛化，关联
3. 对象图：对象:类型
4. 状态图：状态词（动名词）+动作
5. 包图：文件夹
6. 活动图：有开始有结束
7. 构件图：接口+依赖
8. 制品图：系统的物理结构，常与部署图一起使用
9. 组合结构图：描述类的内部结构
10. 部署图：立方体+<<artifact>>
11. 交互图：
    1. 序列图：生命线+控制焦点（像川字）
    2. 通信图：路劲+顺序号
    3. 交互概览图：活动图+顺序图
    4. 计时图：任务对象的生命线，强调消息实际时间以及相对顺序