CMMI组织标准生命周期.docx
《CMMI组织标准生命周期.docx》由会员分享，可在线阅读，更多相关《CMMI组织标准生命周期.docx（13页珍藏版）》请在冰豆网上搜索。
CMMI组织标准生命周期
组织标准生命周期
（OrganizationalStandardLife-Cycle）
编号：
OSSP/PRM-OPD-LC
版本：
v2.0
发布时间：
2008-10-10
变更记录（RECORDOFCHANGES）
版本号
生效日期
变更理由/变更内容
编制人
审批人
目录
1介绍（Introduction）3
1.1目的（Purpose）3
2瀑布模型（WaterfallModel）4
2.1模型描述（DescriptionoftheModel）4
2.2模型分析（TheanalysisofModel）4
2.2.1优点4
2.2.2缺点4
2.2.3补救措施5
3迭代模型（IterativeModel）5
3.1模型描述（DescriptionoftheModel）5
3.2模型分析（TheanalysisofModel）5
3.2.1优点5
3.2.2缺点6
3.2.3补救措施6
4原型法（Prototyping）6
4.1模型描述（DescriptionoftheModel）6
4.2模型分析（TheanalysisofModel）7
4.1.1优点7
4.1.2缺点7
4.1.3补救措施7
5喷泉模型（FountainModel）7
5.1模型描述（DescriptionoftheModel）7
5.2模型分析（TheanalysisofModel）8
5.2.1优点8
5.2.2缺点8
5.2.3补救措施8
6增量模型（IncrementalModel）9
6.1模型描述（DescriptionoftheModel）9
6.2模型分析（TheanalysisofModel）9
6.2.1优点9
6.2.2缺点9
6.2.3补救措施10
7螺旋模型（SpiralModel）10
7.1模型描述（DescriptionoftheModel）10
7.2模型分析（TheanalysisofModel）10
7.2.1优点11
7.2.2缺点11
7.2.3补救措施11
8演化模型（incrementalmodel）11
8.1模型描述（DescriptionoftheModel）11
8.2模型分析（TheanalysisofModel）12
8.2.1优点12
8.2.2缺点12
8.2.3补救措施12
9.智能模型（四代技术（4GL））13
9.1模型描述（DescriptionoftheModel）13
9.2模型分析（TheanalysisofModel）13
8.2.1优点13
2.2.2缺点14
2.2.3补救措施14
10.混合模型（hybridmodel）14
1介绍（Introduction）
1.1目的（Purpose）
描述适合公司目前现状，可供项目选择的标准生命周期模型。
2瀑布模型（WaterfallModel）
2.1模型描述（DescriptionoftheModel）
对于需求非常明确（通常需求的规模比较小，或者用户所需的系统是在已熟悉的某个系统上进行简单的改动）的项目，可以采用瀑布模型进行开发。
每一个工程阶段的输入都严格依赖于前一个工程阶段的输出，并且每一个工程阶段内都应该完成与最终交付产品相关的该工程阶段内的所有工作。
2.2模型分析（TheanalysisofModel）
2.2.1优点
Ø为开发和维护提供了一种有效的管理图式，易于使用；
Ø在消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起着显著作用；
Ø在业界，有30多年的经验积累，是以往软件项目的主要标准；
Ø公司也有很多实例可以参考。
2.2.2缺点
Ø缺乏灵活性，特别是无法解决需求不明确或不准确的问题；
Ø软件与用户见面时间晚，增加了项目风险。
2.2.3补救措施
在需求或设计阶段，平行地进行几次快速原型，来消除风险和不确定性。
3迭代模型（IterativeModel）
3.1模型描述（DescriptionoftheModel）
很多项目的需求往往不能在软件研发的初期就明确下来，对于这样项目，应该先尽可能明确需求的范围，并将最熟悉的或者最重要的需求分析出来。
在这部分的需求明确之后就可以着手对这部分的系统设计、编码和测试了，在后续的过程中可以根据需要安排多次迭代过程。
每次迭代具体什么时候开始，包含哪些过程可以根据项目需要进行定制。
Rational统一过程（RUP）模型和极限编程（XP）方法中使用的软件生命周期模型都属于迭代模型的范畴。
3.2模型分析（TheanalysisofModel）
3.2.1优点
Ø相比于瀑布模型，项目开始和过程中更容易发现项目中的风险和问题。
每次迭代完成后，软件产品都处于可执行、可检验的状态，项目组能够经常性地识别和管理风险，因此，迭代模型中的风险在项目早期就会快速降低；
Ø活动安排比较灵活，几乎总是可以在规定的时间里获得稳定的、已经集成和经过测试的软件临时版本。
3.2.2缺点
Ø如果迭代过程划分不合理，后续的迭代过程比较艰难，存在大量的返工。
3.2.3补救措施
初步的需求开发和第一次迭代过程中的设计工作中，尽可能多的进行同行评审，使最初的
迭代结果具备较好的可扩展性。
4原型法（Prototyping）
4.1模型描述（DescriptionoftheModel）
┌→需求分析←┐
│↓|
│快速设计|
│↓|
│构造原型─┘
│↓
└─评审和修改需求
↓
建立产品
↓
运行维护
原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、歧义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。
原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系统逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。
4.2模型分析（TheanalysisofModel）
4.1.1优点
Ø可以很大程度上消除需求沟通方面的风险。
4.1.2缺点
Ø由于原型并非最终产品，如果原型不能利用，可能导致成本的增加。
Ø原型可能会引起客户的误解，以为产品即将完成。
4.1.3补救措施
对于抛弃型的原形，在不影响与客户交流的情况下尽可能简化实现，节约开发成本。
5喷泉模型（FountainModel）
5.1模型描述（DescriptionoftheModel）
喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。
就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。
随着面向对象系统分析及设计方法的普及，出现了喷泉模型。
喷泉模型认为软件自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去可以落下来，既可以落在中间，也可以落在最底部，类似一个喷泉。
各个开发阶段是没有特定的次序要求的，并且是可以交互进行的，可以在某个开发阶段中随时补充其它任何开发阶段中的遗漏。
喷泉模型的图示如下：
/\
/\
/\
/集成\
←─\/─→
\/
\/\/
/\/\
/\
/测试\
←─\/─→
\/
\/\/
/\/\
/\
/编程
←─\/─→
\/
\/\/
/\/\
/\
/设计\
←─\/─→
\/
\/\/
/\/\
/\
/分析\
←─\/─→
\/
\/
\/
5.2模型分析（TheanalysisofModel）
5.2.1优点
喷泉模型的最大特点是可以从任何一个开发阶段（泡泡）转到其它任一个开发阶段，各个阶段之间没有明显的界限。
也就是，在整个过程中补漏、拾遗、纠错的切入点大大增多，不受开发阶段的限制。
5.2.2缺点
喷泉模型的缺点是要求对文档的管理较为严格，审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料。
5.2.3补救措施
成立专门的审核组，由专人定期对资料统计、审核。
6增量模型（IncrementalModel）
6.1模型描述（DescriptionoftheModel）
与建造大厦相同，软件也是一步一步建造起来的。
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。
核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。
这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
使用增量模型开发字处理软件。
可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
6.2模型分析（TheanalysisofModel）
6.2.1优点
Ø它非常灵活，可以在开发过程中响应重大的规范变化。
另一个明显的优点是分析员和开发人员可以处理不太复杂的问题。
6.2.2缺点
Ø其风险是学习的欲望超过了对生产率的追求，开发项目有可能会变成一个研究项目，超出了时间和预算，甚至根本就做不出产品。
Ø由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
Ø在开发过程中，需求的变化是不可避免的。
增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
6.2.3补救措施
如果开发团队认识到这个风险，把注意力集中在顾客需求上，学习的欲望就不会超过对生产率的追求。
7螺旋模型（SpiralModel）
7.1模型描述（DescriptionoftheModel）
螺旋模型由TRW的BarryBoehm博士提出，是对瀑布/快速原型模型的改进，它在瀑布的每个阶段之前都增加了风险分析。
它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
可以把快速原型模型以螺旋的形式画出来，这个模型已成功应用于大型系统的内部开发，当目标是软件重用，且有特殊的质量目标时，这个模型尤其适用。
它依赖对开发过程中的风险进行精确的评估。
这需要控制所有的因素，消除外部影响，至少要将外部影响降到最低。
与对瀑布模型的其他扩展和改进一样，它在早期的阶段中增加了反馈。
这个模型已在重要编程项目的开发中服务多年。
螺旋模型沿着螺线进行若干次迭代，
（1）制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：
分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：
实施软件开发和验证；
（4）客户评估：
评价开发工作，提出修正建议，制定下一步计划。
7.2模型分析（TheanalysisofModel）
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
但是，螺旋模型也有一定的限制条件，具体如下：
（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。
如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。
最后，评价该阶段的结果，并设计下一个阶段。
7.2.1优点
Ø在瀑布的每个阶段之前都增加了风险分析。
可以把快速原型模型以螺旋的形式画出来。
Ø这个模型已成功应用于大型系统的内部开发，当目标是软件重用，且有特殊的质量目标时，这个模型尤其适用。
7.2.2缺点
Ø它依赖对开发过程中的风险进行精确的评估。
这需要控制所有的因素，消除外部影响，至少要将外部影响降到最低。
7.2.3补救措施
与对瀑布模型的其他扩展和改进一样，它在早期的阶段中增加了反馈。
8演化模型（incrementalmodel）
8.1模型描述（DescriptionoftheModel）
演化模型主要针对事先不能完整定义需求的软件开发。
用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。
软件开发人员根据用户的需求，首先开发核心系统。
当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。
软件开发人员根据用户的反馈，实施开发的迭代过程。
第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。
于是，设计就不断地演化出新的系统。
实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。
这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。
有经验指出，每个开发循环以六周到八周为适当的长度。
8.2模型分析（TheanalysisofModel）
8.2.1优点
Ø任何功能一经开发就能进入测试以便验证是否符合产品需求。
Ø帮助导引出高质量的产品要求。
如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。
而对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改。
Ø风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估算。
提供机会去采取早期预防措施，增加项目成功的机率。
Ø大大有助于早期建立产品开发的配置管理，产品构建（build），自动化测试，缺陷跟踪，文档管理。
均衡整个开发过程的负荷。
Ø开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。
Ø如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。
Ø心理上，开发人员早日见到产品的雏型，是一种鼓舞。
Ø使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
Ø可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
8.2.2缺点
Ø如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性。
Ø如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。
Ø心理上，可能产生一种影响尽最大努力的想法，认为虽然不能完成全部功能，但还是造出了一个有部分功能的产品。
Ø如果不加控制地让用户接触开发中尚未测试稳定的功能，可能对开发人员及用户都产生负面的影响。
8.2.3补救措施
在需求或设计阶段，平行地进行几次快速原型，来消除风险和不确定性。
9.智能模型（四代技术（4GL））
9.1模型描述（DescriptionoftheModel）
智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。
该模型应用基于规则的系统，采用归纳和推理机制，使维护在系统规格说明一级进行。
这种模型在实施过程中以软件工程知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。
采用智能模型的软件过程如下图所示：
智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。
这种方法需要四代语言（4GL）的支持。
4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。
4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。
目前市场上流行的4GL（如Foxpro等）都不同程度地具有上述特征。
但4GL目前主要限于事务信息系统的中、小型应用程序的开发。
9.2模型分析（TheanalysisofModel）
8.2.1优点
Ø智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。
因此，采用原型实现模型需要通过多次迭代来精化软件需求。
Ø智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。
该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。
2.2.2缺点
Ø智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。
在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。
将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。
2.2.3补救措施
它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发
10.混合模型（hybridmodel）
过程开发模型又叫混合模型（hybridmodel），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。
实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。
升级会员 