1、定义
软件过程也称为软件生存周期过程，是指软件生存周期中的一系列相关过程。 为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
2、软件过程的七大元素
活动：开发、维护、管理等；
任务：活动的细分，确定、安排任务等；
工件：软件过程的工作产品，分输入与输出工件；
角色：定义了软件过程中的个人或小组的行为与职责；
资源：最佳实践、工具、技术、机器、场地等；
目标：每个过程有明确的目标；
度量指标：目标的具体度量与分析，如进度、成本、质量、返工率。
3、软件生存周期模型
又称软件开发模型，是软件生命周期的一个框架，规定了软件开发、运作和维护等所需的过程、活动和任务。
4、软件生存周期模型分类
线性顺序模型 Waterfall Model
增量式模型 Incremental Model
演化模型 Evolutionary Model
5、线性顺序模型
瀑布模型，又称线性顺序模型
需求分析->设计->实现->测试->交付->使用和维护
特点：
强调阶段的划分顺序与依赖；
强调各阶段工作文档的完备性，即文档驱动静态描述；
每个阶段从技术和管理进行严格的审查，即质量保证的观点；
是一种线性的、顺序的、逐步细化的开发模式；
推迟实现的观点；
适用时机：
所有功能、性能等要求能一次理解和描述时
所有的系统功能一次交付时
必须同时淘汰全部老系统时
实际的瀑布模型特点：
具有反馈环
价值：
风险和缺点：
获得完善的需求规约是非常困难的；
难以适应快速变化需求；
系统太大时,难以一次做完；
反馈信息慢；
极可能引起开发后期的大量返工，如返工到需求、设计等早期活动；
建议不要使用该模型的几种情况：
需求未被充分理解系统太大而不能一次开发完成事先打算采用的技术迅速发生变化需求迅速发生变化资源有限，如现有的工作人员/资金不足。无法利用某一中间产品6、增量模型
软件被分解成许多增量构件，逐个提交。
构造一系列可执行的中间版本(Version by Version)
适用时机
需要早期获得功能；
中间产品可以提供使用；
系统被自然地分割成增量；
工作人员/资金可以逐步增加。
需考虑的风险
需求未被很好地理解
一次要求所有功能
需求迅速发生变化
事先打算采用的技术迅速发生变化
长时期内仅有有限的资源（人员/资金）
7、演化模型
只要核心需求能够被很好地理解，就可以进行渐进式开发，其余需求可以在后续的迭代中进一步定义和实现。这种过程模型称为演化模型，它能很好地适应随时间演化的产品的开发。
特点：
迭代的开发方法，渐进地开发各个可执行版本，逐步完善软件产品。每个版本在开发时，开发过程中的活动和任务顺序地或部分重叠平行地被采用。
与增量模型的区别：
需求在开发早期不能被完全了解和确定，在一部分被定义后开发就开始了，然后在每个相继的版本中逐步完善。
演化模型在理解了核心需求就可以进行渐进开发，首先执行风险最大的任务，渐进迭代开发各个可执行的版本，允许需求变更。
现代软件过程都采用演化模型：
统一软件过程RUP
敏捷过程 （SCRUM、XP等）
净室（Cleanroom）软件过程
演化模型的“子类”
原型 Prototyping
螺旋模型 Spiral Model
并发开发模型 Concurrent Development Model
（1）迭代化开发
特点：尽可能降低风险，适用处理不确定的复杂系统。
原则:
1、每次迭代产生一个可执行的版本；
2、要求有计划地迭代。
选择功能，上一个迭代的结果，新的风险评估结果，模型、代码和测试的受控库->迭代规划->需求获取->分析与设计->实现->测试->准备发布->发布，更新的风险评估，受控库
（2）快速原型模型
特点：
定义出总体目标或初步需求就开发原型，通过原型与用户交互识别进一步的需求.
（1）抛弃式原型
（2）演化式原型
需求分析->原型开发->原型评价->最终系统设计->最终系统实现。
（3）螺旋模型
8、RUP（Rational Unified Process）统一软件过程
RUP蕴涵了最佳实践准则
（1）迭代式开发
（2）管理需求
（3）使用基于构件的体系结构
（4）可视化建模
（5）贯穿于开发过程的软件质量验证
（6）控制软件变更
RUP是一个风险驱动的、基于UML和构件式架构的迭代、递增型开发过程 。
Inception(初始)
目的:在所有项目干系人之间就项目目标达成共识
Elaboration(精化)
目的:建立架构基线,解决技术风险,为设计与实现奠定基础
Construction(构建)
目的:完成系统开发
Transition(产品化)
目的:确保最终用户可以使用
6个核心规范和3个支持规范、
核心规范:
业务建模(系统目标达成共识)
需求(系统范围达成共识)
设计
实现
测试
部署
支持规范:
配置与变更管理
项目管理(风险,计划,进度等)
环境
9、敏捷过程
敏捷过程：具有高效、快速响应变化的开发过程。
层次：
动机->价值->原则->实践做法
动机：
快速的市场进入时间、快速变化的需求、快速发展的技术。
价值-敏捷宣言：
（1）个体和交互胜过过程和工具；
（2）可以工作的软件胜过面面俱到的文档；
（3）客户合作胜过合同谈判；
（4）响应变化胜过遵循计划。
敏捷过程的原则：
优先目标是尽早持续交付高价值的软件来满足客户需求；
通过驾驭变化帮助客户赢得竞争；
经常交付可用软件；
业务员和开发人员必须每天一起工作；
以积极主动地人为核心建立项目团队；
可用软件是最主要的项目进展目标；
团队内外最有效的交流是面对面交流；
提倡可持续开发，保持稳定的工作步调；
用精益求精和优良设计增强敏捷性；
简约—工作最小化；
最优的架构、需求和设计来自自组织的团队；
团队不断开展工作反思，校正自身行为。
适用于敏捷过程的情况：
需求不确定、易挥发
有责任感和积极向上的开发人员
用户容易沟通并能参与
小于10个人的项目团队
10、极限编程
极限编程是敏捷过程中最著名的一种，指把好的开发实践运用到极致，多应用于软件需求模糊的场合。
价值观：
沟通、反馈、简化、勇气
特点：
测试成为开发的核心;
纪律性与灵活性巧妙结合.
XP关键做法：
现场客户（On-site Customer）
计划博弈（Planning Game）
系统隐喻（System Metaphor）
简化设计（Simple Design）
集体拥有代码（Collective Code Ownership）
结对编程（Pair Programming）
测试驱动（Test-driven）
小型发布（Small Releases）
重构（Refactoring）
持续集成（Continuous integration）
每周40小时工作制（40-hour Weeks）
代码规范（Coding Standards）
11、RUP与XP的共性
基础都是面向对象方法（取代传统的结构化方法）
都重视代码、文档的最小化和设计的简化
采用动态适应变化的演进式迭代周期（取代传统的瀑布型生命周期）
需求和测试驱动
鼓励用户积极参与
12、RUP与XP的区别
XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念。
RUP过程通常以架构为中心，细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。
XP不包含业务建模、部署、过程管理等概念。
RUP适合各种规模的项目，XP只适用于小团队。
13、微软解决方案框架结构MSF
微软过程准则：
项目计划应该兼顾未来的不确定因素;
用有效的风险管理来减少不确定因素的影响;
经常生成并快速的地测试软件的过渡版本，提高稳定性和可预测性;
采用快速循环，递进的开发过程;
用创造性的工作来平衡产品特性和产品成本;
项目进度表应该具有较高稳定性和权威性;
使用小型项目组并发的完成开发工作;
在项目早期把软件配置项基线化，项目后期则冻结产品;
使用原型验证概念，对项目进行早期论证;
把零缺陷作为追求的目标;
里程碑评审会的目的是改进工作，切忌相互指责.
14、Scrum过程
强调经验性过程而不是确定性过程
演化型的迭代开发过程
15、软件过程的选择与裁剪
每种过程都有其价值，分别具有一些最佳实践，适合于某类软件的开发。
软件过程的选择：
（1）产品/项目自身的特点
（2）团队的实际情况和企业文化
（3）客户的影响
软件过程进行裁剪
（1）流程归并与裁剪
（2）角色的筛选与定制
（3）工件的裁剪和定制
16、软件过程的评估与改进
参考模型：
（1）CMM/CMMI
过程能力成熟度模型（Capability Maturity Model，CMM）
CMMI是一个标准簇（Capability Maturity Model Integration，CMMI）
CMMI for Development（CMMI-DEV）：开发模型
CMMI for Service（CMMI-SVC）：服务模型
CMMI for Acquisition（CMMI-ACQ）：采购模型
CMMI模型不同的改进方法：
组织成熟度方法（阶梯式模型）
过程能力方法（连续式模型）
CMMI阶梯式模型
初始级->已管理级->已定义级->定量管理级->持续优化级
CMMI的连续性模型
过程管理
项目管理
工程
支持
ISO/IEC 15504
信息技术——软件过程评价标准，又称为SPICE
ISO/IEC 20000
用于评估和认证IT运维服务管理过程的能力
敏捷过程的原则：
优先目标是尽早持续交付高价值的软件来满足客户需求；
通过驾驭变化帮助客户赢得竞争；
经常交付可用软件；
业务员和开发人员必须每天一起工作；
以积极主动地人为核心建立项目团队；
可用软件是最主要的项目进展目标；
团队内外最有效的交流是面对面交流；
提倡可持续开发，保持稳定的工作步调；
用精益求精和优良设计增强敏捷性；
简约—工作最小化；
最优的架构、需求和设计来自自组织的团队；
团队不断开展工作反思，校正自身行为。
适用于敏捷过程的情况：
需求不确定、易挥发
有责任感和积极向上的开发人员
用户容易沟通并能参与
小于10个人的项目团队
10、极限编程
极限编程是敏捷过程中最著名的一种，指把好的开发实践运用到极致，多应用于软件需求模糊的场合。
价值观：
沟通、反馈、简化、勇气
特点：
测试成为开发的核心;
纪律性与灵活性巧妙结合.
XP关键做法：
现场客户（On-site Customer）
计划博弈（Planning Game）
系统隐喻（System Metaphor）
简化设计（Simple Design）
集体拥有代码（Collective Code Ownership）
结对编程（Pair Programming）
测试驱动（Test-driven）
小型发布（Small Releases）
重构（Refactoring）
持续集成（Continuous integration）
每周40小时工作制（40-hour Weeks）
代码规范（Coding Standards）
11、RUP与XP的共性
基础都是面向对象方法（取代传统的结构化方法）
都重视代码、文档的最小化和设计的简化
采用动态适应变化的演进式迭代周期（取代传统的瀑布型生命周期）
需求和测试驱动
鼓励用户积极参与
12、RUP与XP的区别
XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念。
RUP过程通常以架构为中心，细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。
XP不包含业务建模、部署、过程管理等概念。
RUP适合各种规模的项目，XP只适用于小团队。
13、微软解决方案框架结构MSF
微软过程准则：
项目计划应该兼顾未来的不确定因素;
用有效的风险管理来减少不确定因素的影响;
经常生成并快速的地测试软件的过渡版本，提高稳定性和可预测性;
采用快速循环，递进的开发过程;
用创造性的工作来平衡产品特性和产品成本;
项目进度表应该具有较高稳定性和权威性;
使用小型项目组并发的完成开发工作;
在项目早期把软件配置项基线化，项目后期则冻结产品;
使用原型验证概念，对项目进行早期论证;
把零缺陷作为追求的目标;
里程碑评审会的目的是改进工作，切忌相互指责.
14、Scrum过程
强调经验性过程而不是确定性过程
演化型的迭代开发过程
15、软件过程的选择与裁剪
每种过程都有其价值，分别具有一些最佳实践，适合于某类软件的开发。
软件过程的选择：
（1）产品/项目自身的特点
（2）团队的实际情况和企业文化
（3）客户的影响
软件过程进行裁剪
（1）流程归并与裁剪
（2）角色的筛选与定制
（3）工件的裁剪和定制
16、软件过程的评估与改进
参考模型：
（1）CMM/CMMI
过程能力成熟度模型（Capability Maturity Model，CMM）
CMMI是一个标准簇（Capability Maturity Model Integration，CMMI）
CMMI for Development（CMMI-DEV）：开发模型
CMMI for Service（CMMI-SVC）：服务模型
CMMI for Acquisition（CMMI-ACQ）：采购模型
CMMI模型不同的改进方法：
组织成熟度方法（阶梯式模型）
过程能力方法（连续式模型）
CMMI阶梯式模型
初始级->已管理级->已定义级->定量管理级->持续优化级
CMMI的连续性模型
过程管理
项目管理
工程
支持
ISO/IEC 15504
信息技术——软件过程评价标准，又称为SPICE
ISO/IEC 20000
用于评估和认证IT运维服务管理过程的能力