内容：对应于相应的活动、方法和产出选择一个合适的生命周期模型。
活动需求：
目标：根据软件工作定义，文档化软件团队将使用的技术方法。
从简单和熟悉性排列，共有5个生命周期模型：
1． 瀑布模型
2． 递增模型
3． 进化模型
4． 基于包模型
5． 遗产系统维护模型
瀑布模型摘要
优点：
良好的研究、理解、良好定义
容易模型化和理解
容易规划和监控
有很多管理工具来支持该模型
缺点：
大部分情况下，不能预先知道所有的需求
跟不上需求的变化
直到项目差不多结束，产品才能有一个完整的概貌
该模型适应性：
该项目以前有类似项目的成功经验
需求稳定并容易理解
有经过证明的成熟的设计和技术
项目持续期应该比较短，小于1年
客户不需要任何中间的发布
产出和里程碑评审
阶段
主产出
里程碑评审
项目规划
软件规划
无
需求定义和分析
软件需求规范
软件需求评审
体系结构设计
软件概要设计规范
合格性测试规范
基本用户手册
概要设计评审
详细设计
软件详细设计规范
关键设计评审
开发和测试
单元级设计
实现的被测试过的软件
合格性测试程序
用户手册草稿
合格性测试启用前评审
合格性测试
经过合格性测试的软件
合格性测试报告
最终用户手册
as-built软件描述
验收测试启用前评审
递增模型：
决定用户需求，定义系统需求子集，以顺序构建方式实施开发。首先构建规划设计的一部分，下一个构建再增加设计的一部分，如此下去，直到系统完成。
优点：
减少进度偏离目标、需求变化、验收问题的风险
增强可操作性
在下一个构建中，产品的间歇性构建方便了变化的反馈
中间的构建在最终版本完成前可以提交，允许最终用户识别必须的变化
对于长研制期的项目可以间断开发
允许用户在开发中确认产品
允许研发团队对不明确的需求延迟开发，问题被解决后再发布
允许对中间产品就进行操作培训
允许可以提早验证操作过程
通过评审，客户和用户可以定义良好检查点
缺点：
需求不能完全预先识别
怎样选择构建
如果需求不稳定，变化控制过程可能提高费用
使用场合：
有类似的以前的项目的成功经验
大部分需求是稳定的，良好理解，但某些TBDs存在
有经过证明的成熟的设计和技术
项目的持续期超过一年，客户需要间歇性发布
产出和里程碑评审
阶段
主产出
里程碑评审
项目规划
软件规划
无
需求定义和分析
软件需求规范
软件需求评审
体系结构设计
软件概要设计规范
合格性测试规范
基本用户手册
概要设计评审
详细设计
软件详细设计规范,至少要通过下一个构建点
关键设计评审
构建设计评审
开发和测试
单元级设计
实现的被测试过的软件
合格性测试程序
用户手册草稿
合格性测试启用前评审
合格性测试
经过合格性测试的软件
合格性测试报告
最终用户手册
as-built软件描述
验收测试启用前评审
进化模型：
和递增模型类似，不同的是，用户需要和系统需求只能部分被预先定义，然后在每一个构建中再被精炼，当用户需求被理解，问题被解决，系统将进化。生命期中使用原型。
优点：
不是所有的需求能被预先获取
强调高风险（例如，新技术，需求不明）
产品的间歇性构建方便反馈变化
用户参与定义和评估系统
原型技术使开发者很容易向可和演示功能
时间和资金用完，也能得到一些可使用的功能
缺点：
很难被早期评估，只能准确评估下一个周期。
缺乏如何管理的经验（过程很难被度量）
永无休止的演进的风险
如果成本和交付期确定，很难管理
没有用户的参与不可能成功
使用场合：
需求和设计不能被良好定义，良好理解，可能经历显著变化
引入了新的或未经证明的技术方法
系统功能可以向用户演示以便于演进
有多种用户组，可能需求冲突
产出和里程碑评审
阶段
主产出
里程碑评审
概念定义
初始系统开发规划，再下阶段被更新
系统概念评审
需求定义和体系结构分析
基本需求文档
体系结构设计文档包含基本框架和每阶段的构架
需求跟踪图
系统设计评审
组合系统需求评审
体系结构设计
软件概要设计规范
合格性测试规范
基本用户手册
概要设计评审
实施
演进性的实施规划
时间盒规划
组合新的，可重用的，和现成的产品，产生软件产品基线
更新需求跟踪图
用户文档草稿
时间盒评估
在所有时间盒完成后的合格性测试
集成和测试
系统测试程序
集成的测试过的软件
合格性测试报告
最终用户文档
验收测试启用前评审
安装和验收
操作和维护
基于包的生命模型：
基于现有的商业性和政府现有的产品进行系统开发，以及可重用包。典型的，某些定制软件开发被要求在NDI之间提供接口。
优点：
成本比重新开发相同功能成本低
生命周期也比重新开发相同功能的低
对最终产品的质量有信心
缺点：
可能需要在需求的功能性和现有定义接口提供的功能性之间进行折中
维护性可能有问题，因为现有定义接口的资源可能和组织要求的不一样，比如可能需要第三方的make工具，现有定义接口的开发商的更新也是个问题
适应性：
系统的主要功能已经被其他开发商开发
产出和里程碑评审
阶段
主产出
里程碑评审
需求分析和包定义
系统开发规划
需求
高层体系结构
候选包
系统需求评审
体系结构定义
包选择
修改需求
系统体系结构
最终包
系统设计评审
系统集成和测试
可交付的系统
用户认证
可操作的启用前评审
技术更新和系统维护
强化的系统
用户认证
遗产系统模型：
主要应用于正运作系统的维护和强化。它的维护和开发和瀑布及递增模型有关系，但系统体系结构已经被定义
适用范围：
维护发布包括修复和轻微增强功能
产出和里程碑评审
阶段
主产出
里程碑评审
发布规划
发布内容协定
发布内容评审
需求定义和分析
发行需求规范
发行需求评审
设计
发行设计规范
发行设计评审
实施和测试
单元级测试
被测试过的软件
合格性测试规划和程序
用户更新指南草稿
发行合格测试启用前评审
合格性测试
经过合格性测试的软件
合格性测试报告
最终用户手册
软件描述更新
验收测试启用前评审
选择合适的活动、方法和产品
选择一个合适的生命模型后，需要用软件工程活动、方法，技术和产品填充，以便于达到项目的目标。
活动可被逻辑的分成两个组：
1、 生产一个具体的软件产品
软件CI需求定义和分析
软件CI设计
软件CI实施和测试
软件CI合格性测试
准备软件交付
基本软件工程活动
2、 每个活动的支持
软件验证和效验
软件配置管理
软家质量保证
里程碑评审
软件工程支持活动
1、 软家需求定义和分析
活动需求：
目标：软件需求形成所有下一步设计和实施活动的基础，也形成客户可接受标准的根本。软件需求质量直接影响项目的成功。活动的目标确保高质量的软件需求规范。
当没有需求可利用的时候，需求分析员必须从客户，用户和其它任何合适的地方获取；
当有高层需求时，（例如系统级别的需求），分析员检查需求的完全性，一致性和可理解性，然后再提炼软件需求；
当详细需求可利用的时候，分析员检查需求的完全性，一致性和可理解性；
需求分析员记录那些适合每个软件CI的需求，确保每个需求被迎合，跟踪软件CI需求和高级需求。结果包括所有的可应用的项目，它们包含再软件CI需求惯犯文档标准中。
主要产出：
软件CI需求规范
产品验证和效验记录
软件需求的里程碑评审
结构化分析与设计方法：略
面向对象的分析和设计方法：略
原型技术：略
JAD工作间技术：
2、 软件CI设计：
目标：将软件需求形成可实施的软件形式
关键元素：系统结构和高级设计，详细设计
结构化分析与设计方法：略
面向对象的分析和设计方法：略
3、 软件实施和测试：
目标：
软件实施和单元测试
集成测试
软件实施和单元测试：
目标：将软件设计转变为计算机程序和计算机数据库；单元级别的测试（单元包括屏幕，文件格式，报告，源代码和定义接口的组件）
软件集成和测试：
目标：集成软件组件，它已经经过低级测试，验证和效验
集成方法：自底向商，自顶向下，功能路径方法
软件合格性测试：
目标：独立效验软件需求，软件的功能
4、准备软件交付：
目标：软件包和文档交付给客户
5、软件效验和验证：
目标：独立评估软件，确保所有的需求
软件产品
评估
方法
软件需求规范
软件需求
走查，文档评审；审查
软件设计规范
软件设计
走查，文档评审；审查
单元级设计和规范
详细设计
审查（每单元设计标准）
单元级代码
单元级设计规范
审查；单元测试
单元集成集合
详细设计
集成测试（模块，主线，线程测试）
软件构造
初始：软件设计规范：
演进：软件需求规范
构建性合格性测试
软件发布
初始：软件设计规范：
演进：软件需求规范
正式合格性测试
软件交付
系统需求
验收测试
审查方法：
审查是定义良好的同行评审，用来验证准确性、质量和针对需求及标准的一致性。
两种类型：一对一，小组审查。推荐是多人审查。
主要目的是发现缺陷，其次是向小组成员揭示系统某些部分的细节，说明创建产品时细节的重要性，帮助新手识别细微的缺陷，提高新手的技巧。
优点：比较彻底
缺点：可能被烂用，比如集中在细微末节，例如格式问题。可以在同行评审做了以后，或自我觉得缺陷无法发现。
适用于：
总开发时间比较紧，高级测试时间紧张，产品质量目标比较高
走查方法：
走查是团队成员沟通信息的主要方法，走查不是故意用来发现缺陷的工具，但有时我们经常用它。
优点：快速，有效同行成员共享信息的非正式的方法
缺点：有时被用来替代审查，可能会流过缺陷
适应性：成员之间需要沟通信息
文档评审方法：
被用来验证完整性，准确性，一致性，质量，遵从标准
优点：互相评审文档的所有内容
缺点：文档完成后，评审才能进行
适应性：必须要评审完全的文档
演示方法：
原型方法普遍使用的方法。从另一组征求反馈。
优点：评估产品的特性，通过看和感觉，鼓励客户和最终用户参与
缺点：需要仔细准备，可能使客户和用户认为产品已经完成了，评估可能在阶段后发生而不是使用其它的方法，可能导致唯美性的需求增长。
适应性：有可选的方法，需要评估（例如，用户接口技术）
功能测试方法：
有时指黑盒测试，效验功能盒改正软件组件的接口。测试者不需要理解软件组件的内部测试，也不需要知道它怎样被执行。
优点：不十分耗时，确保功能需求被测试，不许要知道软件的设计细节
缺点：很难检测软件中不经常执行到的部分，识别缺陷的征兆而不是缺陷的原因，不能简历软件的健壮性
使用性：统计需求，组件接口的准确性
结构性和覆盖率测试：
结构测试，有时指白盒测试，验证软件设计的准确执行，测试者必须理解软件的内部设计
覆盖率测试：结构测试的具体形式，确保每条语句或者逻辑路径，或者软件组件至少被执行一遍。
优点：提高自信，最可能识别问题的原因
缺点：非常耗时，可能错过功能性方面，需要深深理解软件内部，迫于某种条件，有时非常困难。
适应性：软件设计的正确性，所有软件路径的执行，低级别的组件测试，面向控制或者安全性组件
统计测试方法：
对客户特别重要的软件特性的使用配置的细节评估， 例如统计某个软件组件执行的经常性，如果有缺陷，哪个组件会崩溃，统计测试通常基于可操作性的特定场景。
优点：测试集中于对于客户来说最重要的软件的部分
缺点：需要深深的理解软件怎样被使用，在软件很少执行的部分，缺陷可能不被发现
适应性：测试效率需要最高，测试期最短
回归测试方法：
在软件被某种程度变化后，变化可能是软件自身，也可能是其它软件或硬件引起。验证变化是否影响以前测试过的软件。回归测试通常不会执行所有的用例，而是一个预定义的子集，基于团队或客户的标准。
优点：提高演进性产品的自信，确保明显的缺陷不会被引入
缺点：需要仔细选择回归测试集合，测试过于彻底会需要相当大的努力，缺陷有可能被遗漏
适应性：已经经历了更高级别的测试，软件引入的一定的变化
静室方法：
阻止软件错误发生，而不是测试错误。依赖于人的纪律，智力控制构建质量到最终的产品而不是计算机辅助跟踪来检测和排除错误。
优点：成功应用静室可以显著改善软件质量和可靠性，降低测试和debug时间，最小化再工作时间
缺点：大项目可能很难被应用
