软件生命周期
问题定义：要示系统分析员与用户进行交流，弄清”用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认
可行性研究：一方面在于把待开发的系统的目标以明确的语言描述出来，另一方面从经济、技术、法律等多方面进行可行性研究
需求分析：确定软件系统的功能需求和非功能需求；分析软件系统的数据要求；导出系统的逻辑模型；修正项目开发计划；如有必要可以开发一个原型系统
开发阶段：设计->实现->测试
维护：
- 改正性维护：在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。
- 适应性维护：是为适应环境的变化而修改软件的活动。
- 完善性维护：是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
- 预防性维护：是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。
统一过程（UP）
初启阶段：生命周期目标
精华阶段：生命周期架构
构建阶段：初始动作功能
移交阶段：产品发布
CMM（软件能力成熟度模型）
初始级：软件工程管理制度缺乏，过程缺乏定义、混乱无序
可重复级：建立了基本的项目管理过程和实践来追踪项目费用、进度和功能特性
已定义级：所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件
已管理级：收集对软件过程和产品质量的详细度量，对软件过程和产品都有度量的理解与控制
优化级：过程的量化反馈和先进的新思想，新技术促使过程不断改进
CMMI（软件能力成熟度集成模型）
未完成级：表明过程域的一个或多个特定目标没有被满足
已执行级：过程通过转化可识别输入工作产品，产生可识别的输出工作产品，关注于过程域的特定目标的完成
已管理级：过程作为已管理的过程制度化，针对单个过程的实例的能力
已定义级：过程作为已定义的过程制度化，关注过程的组织级标准化和部署
量化管理级：过程作为定量管理的过程制度化
优化级：过程作为优化的过程制度化，表明过程得到很好的执行且持续得到改进
COCOMO
基本COCOMO模型：静态单变量模型，用于对整个软件系统进行估算
中级COCOMO模型：静态多变量模型，将软件系统模型分为系统和部件两个层次
详细COMO模型：将软件系统分为系统、子系统、模块三个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响
COCOMOII
应用组装模型：在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的
早期设计阶段模型：在需求已经稳定并且基本的软件体系结构已经建立时使用
体系结构阶段模型：在软件的构造过程中使用
Putnam估算模型：动态多变量，它是假设在软件开发的整个生存周期中工作量有特定的分布
ISO/IEC 9126(软件质量模型)：
由3个层次组成：第一层是质量特性，第二层是质量子特性
特性含义：
其中各六个质量特性与二十七个质量子特性的关系如下表：
| 质量特性 | 功能性 | 可靠性 | 易使用性 | 效率 | 可维护性 | 可移植性 |
| 质量子特性 | 适合性 | 成熟性 | 易理解性 | 时间特性 | 易分析性 | 适应性 |
| 准确性 | 容错性 | 易学性 | 资源特性 | 易改变性 | 易安装性 | |
| 互用性 | 易恢复性 | 易操作性 | 稳定性 | 一致性 | ||
| 依从性 | 易测试性 | 易替换性 |
耦合
无直接耦合（最低耦合）：两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。因此，模块间的耦合性最弱，模块独立性最高
数据耦合：两个模块之间有调用关系，传递的是简单的数据值
标记耦合：两个模块之间传递的是数据结构，如果高级语言的数组名，记录名，文件名等这些名字即为标记，其实传递的是这个数据结构的地址
内容耦合（最高耦合）：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部
控制耦合：模块间传递的信息不但有数据，还包括控制信息
外部耦合：模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)
公共耦合：通过一个公共数据环境相互作用的那些模块间的耦合
内聚
功能内聚：完成一个单一功能，各个部分协同工作，缺一不可(最高)
顺序内聚：处理元素相关，而且必须顺序执行
通信内聚：所有处理元素集中在一个数据结构的区域上
过程内聚：处理元素相关，而且必须按特定的次序执行
瞬时内聚：所包含的任务必须在同一时间间隔执行
逻辑内聚：完成逻辑上相关的一组任务
偶然内聚：完成一组没有关系或松散关系的任务（最低）
软件开发模型
瀑布模型
给出了软件生存周期中制定开发计划、需求分析、软件设计、编码、测试和维护等阶段以及各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个过程如同瀑布流水。该模型为软件的开发和维护提供了一种有效的管理模式，但在大量的实践中暴露出其缺点，其中最为突出的是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题有可能造成开发出的软件并不是用户真正需要的，并且这一点只有在开发过程完成后才能发现。所以瀑布模型适用于需求明确，且很少发生较大变化的项目。
演化模型（快速原型模型）
允许在获取了一组基本需求后，通过快速分析构造出软件的一个初始可运行版本(称作原型)，然后根据用户在适用原型的过程中提出的意见对原型进行改进，从而获得原型的新版本。这一过程重复进行，直到得到令用户满意的软件。该模型主要用于对软件需求缺乏准确认识的情况。
螺旋模型
将瀑布模型和演化模型进行结合，在保持二者优点的同时，增加了风险分析，从而弥补了二者的不足。该模型沿着螺线旋转，并通过笛卡尔坐标的四个象限分别表示四个方面的活动：制定计划、风险分析、实施工程和客户评估。螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。
喷泉模型
以面向对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型。该模型主要用于描述面向对象的开发过程，体现了面向对象开发过程的迭代和无间隙特性。迭代指模型中的活动通常需要重复多次，相关功能在每次迭代中被加入新的系统。无间隙是指在各开发活动(如分析、设计、编码)之间没有明显边界。
软件开发方法
结构化方法
面向数据流、自顶向下、适合数据处理领域的问题、不适合大规模、复杂的项目、难以适应需求的变化
Jackson方法
面向数据结构、适合小规模项目、当输入数据结构与输出数据结构没有对应关系时，难以应用此方法
原型化方法
适合需求不清、业务理论不确定、需求经常变化的情况
Booch方法
面向数据结构
冗余附加技术
屏蔽硬件错误的容错技术：
- 键程序和数据的冗余及调用；
- 检测、表决、切换、重构和复算的实现。
屏蔽软件错误的容错技术：
- 冗余备份程序的存储及调用；
- 实现错误检测和错误恢复的程序；
- 实现容错软件所需的固化程序。
软件风险
项目风险：项目风险威胁到项目计划，若发生项目风险，就有可能拖延项目的进度和增加项目的成本。项目复杂度、规模及结构不确定性也属于项目风险因素
技术风险：技术风险威胁到开发软件的交付时间。若发生技术风险，开发工作就可能变得很困难或根本不可能。规格说明的歧义性、技术的不确定性、技术陈旧以及前沿技术也是技术风险因素
商业风险：商业风险威胁到开发软件的生存能力
市场风险：开发了一个没有人真正需要的优良产品或系统
策略风险：开发的产品不再符合公司的整体商业策略
销售风险：开发了一个销售部们不知道如何去销售的产品
管理风险：由于重点的转移或人员的变动而失去了高级管理层的支持
预算风险：没有得到预算或人员的保证
Gantt
无法描述任务之间的依赖关系，也无法确定影响进度的关键任务
Pert和CPM
Pert无法描述任务之间的并行关系
