软件过程改进.docx
《软件过程改进.docx》由会员分享，可在线阅读，更多相关《软件过程改进.docx（27页珍藏版）》请在冰点文库上搜索。
软件过程改进
第1章软件过程改进
软件过程是人们建立、维护和演化软件产品整个过程中所有技术活动和管理活动的集合。
目前，软件过程技术是一个非常活跃的研究领域，吸引了大批来自学术界和工业界的专家和学者。
目前，每个国家几乎都有自己的软件过程改进网络和组织。
软件过程技术的研究和实践主要有三个方向：
（1）软件过程分析和建模。
软件过程建模方法是软件过程技术的起点，其中形式化半形式化建模方法有基于规则的，基于过程程序的等等。
过程分析和过程建模对于保证过程定义的质量、建立全面和灵活的过程体系具有重要的作用。
对软件过程的建模主要是使用过程建模语言（ProcessModelingLanguages，PML）。
PML最基本的功能是用于描述和定义过程，建立过程模型。
PML的能力和表达方式直接影响着过程模型的质量和建模效率。
所以，选择合适的PMLs，成为过程分析、过程建模和选择建模工具的关键。
（2）软件过程支持。
软件过程支持主要是指研究和开发支持软件过程活动的计算机辅助软件工程（Computer-AidedSoftwareEngineering，CASE）工具，过程支撑工具作为一种技术基础设施，能够很好地支持、管理并规范化软件过程。
它的使用将使得软件过程的透明度好，为项目的软件过程提供指导，使得开发者和管理者都有据可依，便于更有效地管理软件过程。
软件过程支持工具主要包括软件过程流程工具、过程文档工具、评审工具和人员管理工具。
（3）软件过程评估和改进。
软件过程评估和改进是指根据某种模型对现有软件过程进行考核和评价，找出其中的不足之处，然后加以改进。
改进对生产高质量软件产品和提高软件生产率的重要性已被越来越多的软件开发组织所认同。
由美国卡耐基·梅隆大学软件工程研究所（CMU/SEI）提出的软件能力成熟度模型除了用于软件过程评估外，还向软件组织提供了指导其进行软件过程管理和软件过程改进的框架。
软件过程改进的基本原则是采用过去项目中成功的实践经验。
因此，理解、记录和重用部分软件过程是软件过程改进研究的一个重要方向。
1.1CMM综述
软件能力成熟度模型（SoftwareCapacityMaturityModel，SW-CMM）是CMU/SEI为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了SW-CMM1.0版。
希赛教育专家提示：
目前，有很多能力成熟度模型，例如，安全能力成熟度模型（SE-CMM）、人力资源能力成熟度模型（P-CMM）等。
在不造成混淆的情况下，本书把SW-CMM简称为CMM。
也就是说，除非特别说明，否则，CMM就是指SW-CMM。
CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量组织软件开发和管理水平的重要参考因素，以及软件过程改进事实上的工业标准。
1992年4月，CMU/SEI举行了一个CMM的研讨会，CMU/SEI在广泛听取与会专家的意见之后，于1993年推出CMM1.1版，这也是目前世界上比较流行和通用的CMM版本。
按照CMU/SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0的实践反馈意见之后，在1999年完成准CMM2.0版本。
但是，美国国防部办公室要求CMU/SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI。
有关CMMI的知识，将在1.5节进行介绍。
1.1.1CMM的基本概念
为了行文方便，在本节介绍CMM中用到的有关概念和术语。
（1）过程（process）：
为实现既定目标的一系列操作步骤。
（2）软件过程（SoftwareProcess，SP）：
指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。
其中相关产品是指项目计划、设计文档、编码、测试和用户手册。
当一个组织逐步走向成熟，软件过程的定义也会日趋完善，其内部的过程实施将更具有一致性。
（3）软件过程能力（SoftwareProcessCapability，SPC）：
描述了在遵循一个软件过程后能够得到的预期结果的界限范围。
该指标是对能力的一种衡量，用它可以预测一个组织在承接下一个软件项目时，所能期望得到的最可能的结果。
（4）软件过程性能（SoftwareProcessPerformance，SPP）：
表示遵循一个软件过程后所得到的实际结果。
软件过程性能与软件过程能力有区别，软件过程性能关注的是实际得到的结果，而软件过程能力关注的是期望得到的结果。
由于项目要求和客观环境的差异，软件过程性能不可能充分反应软件过程整体能力，即软件过程性能受限于它的环境。
（5）软件过程成熟度（SoftwareProcessMaturity，SPM）：
一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。
所谓成熟度包含着能力的一种增长潜力，同时也表明了组织实施软件过程的实际水平。
随着组织软件过程成熟度能力的不断提高，组织内部通过对过程的规范化和对成员的技术培训，软件过程也将会被它的使用者关注和不断修改完善。
从而使软件的质量、生产率和生产周期得到改善。
（6）关键过程（区）域（KeyProcessArea，KPA）：
一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时所必须满足的条件。
也就是说，关键过程域标识了达到某个成熟程度级别时所必须满足的条件。
在CMM模型中，一共有18个关键过程域，分布在第二级至第五级中。
（7）关键实践（KeyPractices，KP）：
关键过程域中的一些主要实践活动。
每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。
一般情况下，关键实践描述了该“做什么”，但没有规定“如何”去达到这些目标。
（8）软件过程评估（SoftwareProcessAssessment，SPA）：
用来判断一个组织当前所涉及的软件过程的能力状态，判断组织所面向的下一个更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对软件过程进行有效的改进。
（9）软件能力评价（SoftwareCapabilityAppraisal，SCA）：
用来判断有意承担某个软件项目的组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确（或是否正常）。
（10）软件工程组（SoftwareEngineeringGroup，SEG）：
负责一个项目的软件开发和维护活动的团体。
活动包括需求分析、设计、编码和测试等。
（11）软件相关组（SoftwareRelatedGroups，SRG）：
代表一种软件工程项目的团体，它支持但不直接负责软件开发或维护工作，如软件质量保证组、软件配置管理组和软件工程过程组等。
在CMM的关键实践中，软件相关组通常应该根据关键过程域和组织的上下文来理解。
（12）软件工程过程组（SoftwareEngineeringProcessGroup，SEPG）：
由专家组成的组，他们推进组织采用的软件过程的定义、维护和改进工作。
在关键实践中，这个组织通常指“负责组织软件过程活动的组”。
（13）系统工程组（SystemEngineeringGroup，SEG）：
负责下列工作的个人或团体：
分析系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。
（14）系统测试组（SystemTestGroup，STG）：
一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了确定软件产品是否满足对它的需求。
（15）软件质量保证组（SoftwareQualityAssuranceGroup，SQAG）：
一些计划和实施项目的质量保证的团体，其工作目的是保证软件过程的步骤和标准是否得到遵守。
（16）软件配置管理组（SoftwareConfigurationManagementGroup，SCMG）：
一些负责策划、协调和实施软件项目的正式配置活动的团体。
（17）培训组（TrainingGroup，TG）：
一些负责协调和安排组织培训活动的团体。
通常这个组织负责准备和讲授大多数培训课程并协调其他培训方式的使用。
1.1.2CMM的基本框架
CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准，如图1-1所示。
（1）初始级：
软件过程的特点是无秩序的，有时甚至是混乱的。
软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇。
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。
也许，有些组织制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。
图1-1软件过程成熟度的级别
（2）可重复级：
已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。
对类似的应用项目，有章可循并能重复以往所取得的成功。
焦点集中在软件管理过程上。
一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。
从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
（3）已定义级：
用于管理的和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。
全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
要求制定组织范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到组织软件开发标准过程中去。
所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。
过程的剪裁不是随意的，在使用前需经过组织有关人员的批准。
（4）已管理级：
软件过程和产品质量有详细的度量标准。
软件过程和产品质量得到了定量的认识和控制。
已管理级的管理是量化的管理。
所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。
这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。
（5）优化级：
通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。
如果一个组织达到了这一级，表明该组织能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。
除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向上一级别迈进。
因为从第二级开始，每一个低级别的实现均是高级别实现的基础，所以CMM体系不主张跨级别的演化。
SEI建议，从低一级别向高一级别演化的时间需要在12～30个月之间。
CMM分级标准有两个方面的用途。
一方面，软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。
另一方面，该标准也可以作为用户对软件组织的一种评价标准，使之在选择软件开发商时不再是盲目的和无把握的。
1.1.3CMM的主要内容
CMM为软件组织的过程能力提供了一个阶梯式的演化框架，它采用分层的方式来解释其组成部分。
在第二至第五个成熟等级中，每个等级包含一个内部结构的概念。
每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如图1-2所示。
图1-2不断改进的过程
（1）初始级的改进方向：
建立项目过程管理，实施规范化管理，保障项目的承诺；进行需求管理方面的工作，建立用户与软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目计划，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划等；积极开展软件质量保证活动（SoftwareQualityAssurance，SQA）。
（2）可重复级的改进方向：
不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程，也可以作为软件过程剪裁的基础；建立SEPG，长期承担评估与调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。
（3）已定义级的改进方向：
着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。
（4）已管理级的改进方向：
防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，使有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。
（5）优化级的改进方向：
保持持续不断的软件过程改进。
1.1.4CMM的内部结构
CMM的5个成熟度等级中，除第一级外，每一级按完全相同的内部结构构成，如图1-3所示。
图1-3CMM的内部结构图
成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。
在CMM中，每个成熟度等级（第一级除外）规定了不同的KPA，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足KPA所规定的要求，即满足KPA的目标。
每个级别对应的KPA如表1-1所示。
公共特性是把每个KPA的所有关键实践按照它们的属性进行分组。
无论哪个KPA，它们的关键实施都统一按5个公共属性进行组织，分别是执行约定、执行能力、实施活动、度量和分析、验证实施。
（1）执行约定（CommitmentToPerform，CTP）：
也称为实施保证，是组织为了建立和实施相应KPA所必须采取的行动，这些行动主要牵涉到组织范围的政策和高层管理的责任。
执行约定一般与组织的方针政策和管理方式有关。
表1-1关键过程域的分类
过程分类
等级
管理方面
组织方面
工程方面
优化级
技术改进管理
过程改进管理
缺陷预防
可管理级
定量管理过程
软件质量管理
已定义级
集成软件管理
组间协调
组织过程焦点
组织过程定义
培训程序
软件产品工程
同级评审
可重复级
需求管理
软件项目计划
软件项目跟踪与监控
软件子合同管理
软件质量保证
软件配置管理
（2）执行能力（AbilityToPerform，ATP）：
也称为实施能力，描述为了使某软件过程得以始终如一地执行，必须在项目或组织中存在的先决条件，是组织实施KPA的前提条件。
组织必须采取措施，在满足了这些条件后，才有可能执行KPA的实践活动。
执行能力关注于项目计划的实践、资源的配置、责任的布置与授权，以及各种有关的培训等。
（3）实施活动（ActivitiesPerform，AP）：
描述执行KPA所需的必要行动、任务和步骤。
在5个公共属性中，实施活动是唯一与项目执行相关的属性，其余4个属性则涉及组织CMM能力基础设施的建立。
实施活动一般包括计划、执行的任务、任务执行的跟踪等。
（4）度量和分析（MeasurementAndAnalysis，MAA）：
关注KPA的活动需要做的度量和度量分析要求。
典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。
度量与分析一般包括一些度量的例子，通过这些例子可以知道如何确定操作活动的状态和效果。
（5）实施验证（VerifyingImplementation，VI）：
实施验证是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。
验证实施涉及到管理的评审和审计以及质量保证活动，包括过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。
1.1.5SPA和SCA的比较分析
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进方向。
评估组以CMM模型为指引调查、鉴别软件过程中的问题，反过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。
软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。
评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。
通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。
也可以用来判断承包者的工作进程，推动他们改进软件过程。
CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的步骤，如图1-4所示。
图1-4软件过程评估和软件能力评价的步骤
具体来说，评估过程是：
选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据KPA的基本情况列出评估提纲。
尽管SPA和SCA有很多相似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如：
（1）SPA和SCA在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。
尤其在一些细节规范方面，SPA和SCA的方法有很大差异。
（2）SPA和SCA的结果和结果所起的作用不同。
因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。
（3）被评估和评价单位的态度对SPA和SCA活动的影响。
SPA在某种意义上被评估单位的态度较积极，而SCA在某种意义上被评价单位的态度可能比较慎重。
SPA是在一个开放的、互相协作的环境中进行的，而SCA往往是在有较大的阻力的环境中进行的。
1.2组织如何实施CMM
近年来，随着国民经济持续增长，作为高新技术的软件产业虽然发展很快，但和国外同行业相比仍存在很大的差距。
究其原因，投资环境、人才和技术固然是制约因素，但希赛教育专家认为，管理和政策显得更为关键。
随着电子信息产业的发展，人们已经逐步认识到，软件是促进我国电子信息产业发展的关键技术。
而要发展我国的软件产业，在战略上，必须将软件产业作为我国高新技术产业的龙头和国民经济发展的新增长点，在策略上，必须走软件过程管理专业化的道路。
1．提高思想认识
实施CMM对软件组织的发展起着至关重要的作用，这种作用并不是取决于CMM评估的结果。
CMM过程本身就是对软件组织发展历程的一个完整而准确的描述，组织通过实施CMM，可以更好地规范软件生产和管理流程，使组织的管理更加规范化。
而且，只有在国际市场取得成功的产品和组织才具有长久的竞争力和生命力，由于CMM已获得国际组织和用户的广泛认可，因此很有必要在软件组织中实施CMM。
2．进行CMM培训和咨询工作
任何一个组织要想实施先进的管理措施，首先应该做的就是理论基础的建设，作为一个过程式管理方法的CMM，同样也不例外。
根据CMM模型的要求，一个项目的开发一定要有章可循，而且要做到有章必循，这两点都离不开培训。
培训工作需要投入很大的人力、物力和财力，只有组织的管理人员和软件开发人员对CMM真正了解和认识了，自觉地按CMM的方法去进行工作，才能真正实施CMM，而不是一时应付，做表面文章。
培训的内容需要精心地准备，主要有两个方面，第一，对所有员工包括经理在内的最基本的软件工程和CMM培训知识；第二，对各个工作组的有关人员提供专业领域知识等方面的培训；此外，在每次开发过程中，还要对普通人员进行软件过程方面的培训。
培训的方式有很多，可以向有关专业培训咨询机构进行咨询；可以利用互联网资源进行咨询和培训；可以聘请有关CMM专家到组织实地指导CMM的实施。
希赛教育专家提示：
组织可以在最开始阶段聘请一位经验丰富的CMM专家，但以后一定要培养自己的专家，这样不仅能节约开支，还能使组织自己具有一个对CMM深刻理解的、有实践经验的专家，为组织今后的继续升级打下一个良好的基础。
3．确定合理的目标
CMM模型划分为5个级别，共计18个关键过程域，52个目标，316个关键实践。
每一个CMM等级的评估周期（从准备到完成）约需12～30个月。
无论一个组织的软件过程处于什么样的水平，都可以在CMM框架的5个级别中找到自己的位置。
CMM框架的不同级别是针对处于不同管理水平的组织制定的，组织实施CMM，首先必须了解自己的管理现状，对照CMM的级别，找到自己在CMM中所处的位置，然后有针对性采取与自己所处级别相适应的措施，使组织尽早纳入CMM的演化阶段，使软件过程管理早日得到改善，最终达到提高软件质量，获取经济效益的目的。
因此，要实施CMM，首先应该对本组织的现状有一个准确的评估。
组织目前处于什么水平，组织发展的问题是什么，借助CMM要达到的目的是什么。
然后再结合组织的实际情况选择CMM的切入点，确定总体目标。
这个目标包括在多长时间之内，需要投入多少人力、物力和财力，要达到哪一级。
由于软件过程的建立和改进是一个渐进的、分轻重缓急的、逐步完善的过程。
所以，在总体目标已经确定的前提下，还要制订近期目标和长期目标。
4．成立工作组
组织针对CMM的实施，应成立专门的CMM实施领导小组或专门的机构。
CMM的实施需要有强有力的组织保证，领导层必须真正学习理解软件过程管理和改进的重要性，亲自领导和参与，要保证过程管理的人员配备，抽调组织中有管理能力、组织能力和软件开发能力的骨干人员，确实把此项工作当作组织生存和发展的大事来抓。
在CMM的实施过程中，工作组的成立是CMM的一个关键步骤。
有几个重要的组织是必不可少的，这些组织包括软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。
在CMM的实施中组织机构的设置必须完善，但不等于说每一个机构必须是独立的。
有些组织很小时，机构可以适当合并，成员可以身兼数职。
但对那些关键实践要求独立性时，组织必须十分小心。
例如，软件质量保证组的独立性就是必须考虑的，否则在技术上或机构上出现的偏差，会无目的地影响到软件过程、项目质量和风险决策的正确性。
在这里还要提到一点，那就是物理组和逻辑组。
在CMM中有两种组织，一种叫物理组织，它是客观存在的，例如项目组、技术部等，有众多专职人员；另一种叫逻辑组织，就是说它的人员可以是兼职的，在用不到的时候，成员有自己的工作，而且很多逻辑组只需一两个人就可以了。
5．制定和完善软件过程
CMM模型强调软件过程的改进，如果组织还没有一个文档形式的软件过程，则首要任务是对当前的工作流程进行分析、整理及文档化，从而制定出一个具有本组织风格的软件过程，并用该文档化的过程指导软件项目的开发。
如果已经具备了软件过程，则要对这个过程做内部评估，对照CMM的要求，找出问题，然后对这个过程进行补充修改。
在具体实施的过程中，可以选择有一定代表性和完善性的项目组或项目进行试点，跟踪、监督改进后的软件过程的实施情况，执行改进活动的状态。
同时，过程小组的成员还应该维护过程中的数据库，定期统计各个过程中的产品和规模、开发周期、修改次数及评估周期。
这些数据库可用来分析项目的效率以及存在的问题，以便今后进一步的改进，同时还可以为项目开发过程提供咨询。
总结这些项目组或项目以前成功的经验，从中规划出一个具有实际意义的软件过程，按照CMM规范评估这个过程，找出其中的优缺点。
对不满足CMM要求的地方加以完善，使其成为一个完美的实施CMM的软件过程方案；然后将这个软件过程应用到当前正在承接的或即将承接的项目上，在实际使用过程中进一步发现其中的不足和错误之处，加以改进，最后将试点的结果推广到整个组织。
6．内部评审
CMM每一级别的评估都由CMU/SEI授权的主任评估师领导一个评审小组进行，相对来说，评审费用比较高。
因此，希赛教育专家建议，组织在进行
升级会员 