瀑布模型(SDLC)：需求明确的项目
软件计划→ 需求分析→ 软件设计→程序编码→软件测试→运行维护(→循环自己)
其他经典模型：
原型：构造一个简易的模型，对应需求不明确的情况
增量模型(引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发)
螺旋模型(加入了风险分析)：
V模型(测试更加细化;在需求分析的时候写验收测试和系统测试，可以提早发现问题;在概要设计的时候，写集成测试的测试计划;在详细设计的时候，写单元测试的测试计划;
强调测试贯穿于开发的始终)
喷泉模型(面向对象的模型;迭代，无间隙)
RAD(快速开发模型,快速构建应用系统)
构件组装模型(CBSD，极大地提高了软件开发的复用性;可靠性强)：
需求分析和定义→软件架构设计→构件库的建立→应用软件构建→测试和发布
敏捷开发方法(适用于小型项目)：
信息系统开发方法：
结构化法
原型法
面向对象方法
面向服务方法
| 方法 | 特点 |
| 结构化法 |
用户至上 严格区分工作阶段，每阶段有任务和成果 强调系统开发过程的整体性和全局性 系统开发过程工程化，文档资料标准化 自顶向下，逐步分解(求精) |
| 原型法 |
适用于需求不明确的开发 包括抛弃式原型和演示化原型 |
| 面向对象方法 |
更好的复用性 关键在与建立一个全面、合理、统一的模型 分析、设计、实现三个阶段，界限不明确 |
| 面向服务方法 |
SO方法有三个主要的抽象级别：操作、服务、业务流程 SOAD分为三个层次：基础设计层(底层服务构件)、应用结构层(服务之间的 接口和服务级协定)和业务组织层(业务流程建模和服务流程编排) 服务建模：分为服务发现、服务规约和服务实现三个阶段 |
需求开发：
软件需求分类：
业务需求，用户需求，系统需求→功能需求，性能需求，设计约束
QFD：基本需求，期望需求，兴奋需求(不该做)
获取方法：收集资料，联合需求计划，用户访谈，书面调查，情节串联板，现场观摩，参加业务实践，阅读历史文档，抽样调查
结构化设计：
(概要设计，详细设计)→(自顶向下、逐步求精;信息隐蔽;模块独立[高内聚，低耦合，复杂度])
保持模块的大小适中
尽可能减少调用的深度
多扇入，少扇出
单入口，单出口
模块的作用域应该在模块之内
功能应该是可预测的
内聚与耦合
| 内聚类型 | 描述 |
| 功能内聚 | 完成一个单一功能，各个部件协同工作，缺一不可 |
| 顺序内聚 | 处理元素相关，而且必须顺序执行 |
| 通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
| 过程内聚 | 处理元素相关，而且必须按特定的次序执行 |
| 瞬时内聚(时间内聚) | 所包含的任务必须在同一时间间隔内执行 |
| 逻辑内聚 | 完成逻辑上相关的一组任务 |
| 偶然内聚(巧合内聚) | 完成一组没有关系或松散关系的任务 |
| 耦合类型 | 描述 |
| 非直接耦合 | 两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的 |
| 数据耦合 | 一组模块借助参数表传递简单数据 |
| 标记耦合 | 一组模块通过参数表传递记录信息(数据结构) |
| 控制耦合 | 模块之间传递的信息中包含用于控制模块内部逻辑的信息 |
| 外部耦合 | 一组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息 |
| 公共耦合 | 多个模块都访问同一个公共数据环境 |
| 内容耦合 |
一个模块直接访问另一个模块的内部数据;一个模块不 通过正常入口转到另一个模块的内部; 两个模块有一部分程序代码重叠;一个模块有多个入口 |
系统结构/模块结构
(b)需要掌握
测试原则与类型：
尽早、不断的进行测试
程序员避免测试自己的程序
既要选择有效、合理的数据，也要选择无效、不合理的数据
修改后应进行回归测试
尚未发现的错误数量与该程序已发现错误数成正比
动态测试(利用到计算机)→黑盒测试法，白盒测试法，灰盒测试法
静态测试(纯人工)→桌前检查，代码走查，代码审查
黑盒测试→等价类划分，边界值分析，错误推测，因果图
白盒测试→基本路径测试，循环覆盖测试，逻辑覆盖测试[语句覆盖(最低级别)，判定覆盖，条件覆盖，条件判定覆盖，修正的条件判断覆盖，条件组合覆盖，点覆盖，边覆盖，路径覆盖(最高级别)]
测试阶段
McCabe复杂度
计算有向图G的环路复杂度公式为：V(G)=m-n+2.
其中V(G)是有向图G中的环路个数，m是G中的有向弧数，n是G中的节点数。
系统运行与维护
软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前完成的活动，以及交付后完成的活动。交付前完成的活动包括交付后运行的计划和维护计划等;交付后的活动包括软件修改、培训、帮助资料等。
可维护性(易分析性，易改变性，稳定性，易测试性)
维护类型(改正性维护(用户找到Bug，去修复，25%)，适应性维护(操作系统的环境，数据环境20%)，完善性维护(改善性能50%)，预防性维护(5%))
软件过程改进-CMMI
阶段式→组织能力成熟度
| 成熟度等级 | 过程域 |
| 已管理级 |
需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、 度量和分析、过程和产品质量保证 |
| 已定义级 |
需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、 组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、 决策分析和解决方案、组织级集成环境 |
| 定量管理级 | 组织级过程性能、定量项目管理 |
| 优化级 | 组织级改革与实施、因果分析和解决方案 |
连续式→软件过程能力
| 连续式分组 | 过程域 |
| 过程管理 | 组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施 |
| 项目管理 |
项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、 定量项目管理 |
| 工程 | 需求管理、需求开发、技术解决方案、产品集成、验证、确认 |
| 支持 |
配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、 因果分析和解决方案 |
项目管理
九大知识邻域
范围管理
时间管理(考)
成本管理
质量管理
人力资源管理
沟通管理
风险管理(考)
采购管理
整体管理
例：
风险是指"损失或伤害的可能性" 关心未来、关心变化、关心选择
分类：
项目风险
技术风险
商业风险
风险曝光度(Risk Exprosure):计算方法是风险出现的概率乘以风险可能造成的损失。
假设正在开发的软件项目可能存在一个未被发现的错误，而这个错误出现的概率是0.5%，给公司造成的损失将是1000000元，那么这个错误的风险曝光度就应为1000000*0.5%=5000元