软件开发模型——瀑布模型（SDLC）
流程：
- 软件计划
- 需求分析
- 软件设计
- 程序编码
- 软件测试
- 运行维护
（每个阶段结束都会有个评审工作）
缺陷：研究表明，最后会项目超时，项目超预算，导致项目无法继续。
主要是软件需求是无法明确的，在初期是更不可能确定。
适用场景：两种情况，
一是二次开发
二是需求明确的项目
原型：可以是一个简单的界面，也可以是一个简易系统给客户看，让客户提出需求。
增量模型：用开发总周期的百分之二十左右的时间，做出系统的核心模块，然后不断同客户方沟通需求，得到最终的版本。
软件开发模型——增量模型与螺旋模型
增量模型
螺旋模型（具备多个模型的特点）
针对需求不明确的情况下，优先选择原型！！！！再是螺旋模型
软件开发模型——其他经典模型（V模型，喷泉模型）
V模型（强调及早的进行测试，测试要贯穿开法始终，而不是压在最尾端）
在需求分析阶段就写好系统测试的测试计划
概要设计阶段会写集成测试阶段的测试计划
详细设计阶段会写单元测试阶段的测试计划
喷泉模型（是面向对象的模型）
RAD（快速开发模型，由喷泉模型和构件化开发结合的模型）
软件开发模型——构建组装模型（CBSD）
基本思路：将软件中的各个模块，做成标准的构件，然后将构件进行组装。极大的提高了软件的复用性！！！
- 需求分析和定义
- 软件架构设计
- 构件库的建立
- 应用如那件构建
- 测试与发布
软件开发模型——敏捷开发方法
敏捷开发模型
- 自适应开发
- 水晶方法
- 特征驱动开发
- SCRUM
- 极限编程
基本原则：短平快的会议，小型版本发布，较少的文档，合作为重，客户直接参与，自动化测试，适应性计划调整，结对编程，测试驱动开发，持续集成，重构
四大价值观：沟通，简单，反馈，勇气
五大原则：快速反馈，简单性假设，逐步修改，提倡修改，提倡更改，优质工作
12个最佳实践：计划游戏，小型分布，隐喻，简单设计，测试先行，重构，结队编程，集体代码所有制，持续集成，每周工作40小时，现场客户，编码标准
适用范围：小项目，不适用于太大的项目
信息系统开发方法
- 结构化法（相比面向对象方法，不灵活）
- 用户至上
- 严格区分工作阶段，每阶段有任务与成果
- 强调系统开发过程的整体性和全局性
- 系统开发过程工程化，文档资料标准化
- 自顶向下，逐步分解（求精）
结构化法最大的弊端：改一模块，需求要变，设计要变，编码要变，还得重新做测试。
- 原型法（主要用于需求阶段）
- 适用于需求不明确的开发
- 包括抛弃式原型和演化式原型
- 面向对象方法（使用较为广泛）
- 更好的复用性
- 关键在于建立一个全面，合理，统一的模型
- 分析，设计，实现三个阶段，界限不明确
- 面向服务方法（还处于了解阶段，不需要做深究）
- SO方法有三个主要的抽象级别：操作，服务，业务流程
- SOAD分为三个层次：基础设计层（底层服务构件），应用结构层(服务之间的接口和服务级协定)和业务组织层(业务流程建模和服务流程编排)
- 服务建模：分为服务发现，服务规约和服务实现三个阶段。
需求开发——需求分类与需求获取
软件需求分类
- 业务需求，用户需求，系统需求（——业务层次需求）
- 功能需求，性能需求，设计约束（——系统层次需求）
- 基本需求，期望需求，兴奋需求（——QFD质量改善模型的角度）
（目前在项目中需要尽量杜绝实现兴奋需求，会占用消耗项目资源，加大项目成本，不利于实现利润最大化）
结构化设计——基本原则
- 概要设计
- 详细设计
设计原则：
- 自顶向下，逐步求精
- 信息隐蔽
- 模块独立(高内聚，低耦合，复杂度)
扩展原则： - 保持模块的大小适中
- 尽可能减少调用的深度
- 多扇入，少扇出
- 单入口，单出口
- 模块的作用域应该在模块之内
- 功能应该是可预测的
内聚的类型分类：
- 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可。（功能最高）
- 顺序内聚：处理元素相关，而且必须顺序执行。
- 通信内聚：所有处理元素几种在一个数据结构的区域上。
- 过程内聚：处理元素相关，而且必须按特定的次序执行。
- 瞬时内聚（时间内聚）：所包含的任务必须在同一时间间隔内执行。
- 逻辑内聚：完成逻辑上相关的一组任务。
- 偶然内聚（巧合内聚）：完成一组没有关系或松散关系的任务。（功能最低）
耦合的类型分类
- 非直接耦合：两个模块之间没有直接关系，他们之间的联系完全是通过主模块的控制和调用来实现的。
- 数据耦合：一组模块借助参数表传递简单数据。
- 标记耦合：一组模块通过参数表传递记录信息（数据结构）。
- 控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息。
- 外部耦合：一组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息。
- 公共耦合：多个模块都访问同一个公共数据环境。
- 内容耦合：一个模块直接访问另一个模块的内部数据，一个模块不通过正常入口转到另一个模块的内部，两个模块有一部分程序代码重叠，一个模块有多个入口。（耦合程度最高）
软件测试——测试原则与类型
测试原则：
- 尽早，不断地进行测试
- 程序员避免测试自己设计的程序
- 既要选择有效，合理的数据，也要选择无效，不合理的数据
- 修改后应进行回归测试
- 尚未发现的错误数量与该程序已发现错误数成正比
动态测试（用到计算机）分为三类：黑盒测试法，白盒测试法，灰盒测试法（灰盒为结合黑盒和白盒）
静态测试（纯手工）分为三类：桌前检查，代码走查，代码审查
软件测试——测试用例设计
分为两种
1.黑盒测试（只需要知道输入和输出是什么，过程不考虑）
- 等价类划分（把所有等价值进行测试，比如，>90 为优，>80为良）
- 边界值分析（针对边界值进行测试）
- 错误推测（强调的是一种经验，经常出现的错误）
- 因果图
2.白盒测试（根据程序结构模块进行测试） - 基本路径测试
- 循环覆盖测试
- 逻辑覆盖测试（语句覆盖，判定覆盖，条件覆盖，条件判定覆盖，修正的条件判断覆盖，条件组合覆盖，点覆盖，边覆盖，路径覆盖（路劲覆盖最为全面））
软件测试——测试阶段
- 单元测试（测局部的功能，局部的数据结构，功能模块相关接口）
- 集成测试（测模块间的衔接）
- 集成测试中的组装分为两种
- 一次性组装 和 增量式组装
- 确认测试
- 内部测试确认
- Alpha测试
- Beta测试
- 验收测试 （用户参与，用户决定产品是否满意）
- 系统测试（主要涉及到压力，性能，可靠性等的测试）
- 在性能测试中设计到以下三个方面
- 负载测试
- 强度测试
- 容量测试
单元测试和集成测试的先后关系可以确定，先做单元测试再做集成测试，但确认测试和系统测试在不同资料上有不同的讲法，一般的软件项目而言，只用做到确认测试就结束了。而又有有的情况，系统测试在确认测试之前进行。
软件测试——McCabe复杂度
计算有向图G的环路复杂度公式为：V（G）= m - n + 2
其中V（G）是有向图G中的环路个数，m是G中的有向弧数，n是G中的节点数。
例如： A ->B -> C 的复杂度为 1
系统运行与维护
软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前完成的活动，以及交付后完成的活动。交付钱完成的活动包括交付后运行的计划和维护计划等，交付后的活动包括软件修改，培训，帮助资料等。
可维护性包括四个特征：
1.易分析性
2.易改变性 (松耦合的结构)
3.稳定性
4.易测试性
维护类型也分为四类：
1.改正性维护
2.适应性维护（运行环境的适应，例如操作环境，数据环境）
3.完善性维护
4.预防性维护
项目管理
九大知识领域——只需要了解其中的时间管理和风险管理
时间管理
甘特（Gantt）图 能明显的显示出进度的安排，从何时开始，从何时结束，但是不能明确的表现任务之间的逻辑关系。
PERT图 能清楚的表明任务执行所需的时间，以及任务之间的关系。（最晚开始时间可以用逆推得到）
风险管理
风险是指"损失或伤害的可能性"。
风险管理分为项目风险，技术风险，商业风险。
特点：关心未来，关心变化，关心选择。
风险曝光度（Risk Exposure）：计算方法是风险出现的概率乘以风险可能造成的损失。
例：假设正在开发的软件项目可能存在一个未被发现的错误，而这个错误出现的概率是0.5%，给公司造成的损失将是1000000元，那么这个错误的风险曝光度就应为1000000x0.5% =5000元。