（企业管理专业论文）软件过程与软件过程改进.pdf

软件过程与软件过程改进 软件过程与软件过程改进 摘要 在信息技术快速发展的同时，软件行业却日益显得困难重重，甚至出现了“软 件危机”。随着对软件产品的要求日益提高，软件产品的规模日益扩大，软件开 发却经常陷于进度极度延迟，成本不断超出预算，软件的质量难以保证的困境。 如何提高软件产品的生产率和质量成了迫切需要解决的问题。 过去，软件开发完全依赖于个人或者一个优秀的团体，但仅仅建立在可得到 特定人员上的成功不能为组织软件产品的生产率和质量的长期提高打下基础。软 件开发中的问题需要从软件过程中寻找答案。软件组织需要建立有效的软件工程 和管理实践等过程基础设施，通过组织的软件过程，来实现软件产品开发的可重 复，不断提高软件开发的能力。卜 软件过程是软件组织进行软件开发所遵循的标准和规程。它既包括需求管 理、项目计划、项目控制、质量保证和配置管理等一些管理活动，也包括了分析、 设计、编码和测试等的工程活动。这些标准和规程保证了软件开发能够以一种一 致的可重复性的模式进行，奠定了随后的定量化软件过程改进的基础。本文的第 一部分详细介绍了一个理想的软件过程所需要实现的活动、规程和工作产品。 软件过程测量、分析和改进是基于定性化软件过程建立基础上的定量化软件 过程改进手段。软件过程测量可以获得对软件过程运行的详细信息；性能分析可 以更好地认识软件过程能力，更好地计划和控制软件项目；稳定性分析能够发现 和消除过程中的异常因素，从而提高过程的可预测性。测量、分析和改进提供了 一条不断提高软件过程能力的道路。在第二部分中，本文给出了如何进行测量、 分析和改进，并结合具体的实践演示了软件过程改进的道路。 关键词 软件过程，软件过程改进，软件过程测量 软件过程与软件过程改进 s o f t w a r ep r o c e s sa n di t si m p r o v e m e n t a b s t r a c t w h i1 ei n f o r m a t i o nt e c h n o l o g yis b o o m i n gs p e e d i1 y ，s o f t w a r ei n d u s t r y h o w e v e rf i n d si t s e i ff a c i n gm a n yd i f f i c u l t i e s ，e v e n “s o f t w a r ec r i s i s ” i nt h eo n eh a n d ，t h e r ee x i s th i g hr e q u i r e m e n t sf o rs o f t w a r ep r o d u c t so f h i g hq u a l i t ya n dp o w e r f u lf u n c t i o n s i nt h eo t h e rh a n d t h ed e v e l o p m e n t o fs o f t w a r ep r o d u c t so f t e nh a st o s t r u g g l ew i t hp r o b l e m s l i k e l a go f p r o g r e s s ，c o s to v e rb u d g e ta n dl o wq u a i t y s oh o wt oi m p r o v ep r o d u c t i v i t y a n dq u a lit yo fs o f t w a r ep r o d u c t sisat o pis s u et oa d d r e s s b e f o r e ，s o f t w a r ed e v e l o p m e n th a dd e p e n d e dc o m p l e t e yo ne x c e l l e n t i n d i v i d u a l so rt e a m s b u ts u c hs u c c e s s e sb a s e do np e o p l ec a n n o tg u a r a n t e e t h ec e n t i n u o u s i m p r o v e m e n t o fs o f t w a r ep r o d u c t i v i t ya n dq u a l i t y t h e a n s w e ro ft h ep r o b l e m se x i s t i n g i ns o f t w a r ei n d u s t r yc a n n o th ef o u n d e x c e p tf r o ms o f t w a r ep r o c e s s s o f t w a r eo r g a n i z a t i o i i sh a v et oe s t a b li s h e f f e c t i v ea n de f f i c i e n ti n f r a s t r u c t u r e so fs o f t w a r e e n g i n e e r i n ga n d m a n a g e m e n tp r a c t i c e s t h e yn e e dt or e a i z er e p e a t a b l es o f t w a r ep r o c e s s e s a n dt h e n c e n t i n u o u s l yi m p r o v et h e i rc a p a b i l i t i e s t od e v e l o ps o f t w a r e p r o d u c t s s o f t w a r ep r o c e s sist h es e to fs t a n d a r d sa n dp r o c e d u r e sf o ll o w e db y t h es o f t w a r ed e v e l o p m e n t n o to n yd o e si ti n c l u d er e q u i r e m e n tm a n a g e m e n t p r o j e c tp l a n n i n g ，p r o j e c tc o n t r o l l i n g ，q u a i t y a s s u r a n c ea n d c o n f i g u r a t i o nm a n a g e m e n t ， b u ta l s oi n c l u d e ss o f t w a r e e n g i n e e r i n g p r a c t i c e ss u c ha sa n a l y s i s ，d e s i g n ，c o d i n ga n dt e s t t h e s es t a n d a r d sa n d p r o c e d u r e sp r o v i d es o f t w a r ed e v e l o p m e n tw i t ht h ea b i l i t yt o r u no na r e p e a t a b l ep a t t e r n ，a n dt h eb a s i so fq u a n t i t a t i v es o f t w a r ei m p r o v e m e n t t h ef i r s t p a r to f t h et h e s i s d e t a i l st h e a c t i v i t i e s ，p r o c e d u r e s a n d w o r k i n gp r o d u c t so fa ni d e a ls o f t w a r ep r o c e s s t h e p a t ho fs o f t w a r em e a s u r i n g ，a n a l y z i n g a n d i m p r o v i n g i st h e q u a n t i t a t i v e s o f t w a r e i m p r o v e m e n t m e t h o db a s e do nt h e q u a l i t a t i v e e s t a blis h m e n to fs o f t w a r e p r o c e s s s o f t w a r em e a s u r e m e n t c a np r o v id e d e t a i l e di n f o r m a t i o no fs o f t w a r e p r o c e s sp e r f o r m a n c e ：p e r f o r m a n c e a n a l y s i sc a bh e i pt og e tab e t t e ru n d e r s t a n d i n go f t h ec a p a b i l i t yo f 软件过程与软件过程改进 s o f t w a r ep r o c e s sa n dh e l pt ob e t t e rp l a na n dc o n t r o ls o f t w a r ep r o j e c t s ： a n ds t a b i l i t ya n a l y s i sh e i p st ojd e n t j f ya n de l i m i n a t ea s s i g n a b l ec a u s e s i ns o f t w a r ep r o c e s sa n dh e p st os e tu pap r e d i c a b l ep r o c e s s t h ec i r c l e o fs o f t w a r em e a s u r e m e n t ，a n a l y s isa n di m p r o v e m e n t1 e a d st oac o n t i n u o u s s o f t w a r ep r o c e s si m p r o v e m e n tr o a d t h es e c o n dp a r tp r e s e n t st h es t u d yo n m e a s u r e m e n t ，a n a l y s i sa n di m p r o v e m e n t ，a n dd e m o n s t r a t e st h ep r a c t i c e so f s o f t w a r ei m b r o v e m e n t k e yw o r d s s o f t w a r ep r o c e s s ，s o f t w a r ep r o c e s s i m p r o v e m e n t ，s o f t w a r ep r o c e s s m e a s u r e m e n t 第一章软件开发与软件过程 自二战以来，由软硬件代表的信启、技术获得了高速的发展，日益成为人们日常生活和企 业运作所不可欠缺的部分。通过企业在信息技术上的巨大投资带来的资本深化，信息技术行 业内部的生产率飞速提高，以及信息技术对其它行业生产率提高的外溢作用，信息技术对全 行业的生产率提高做出了巨大的贡献，成为支持经济发展的重要力量。 但是在信息技术快速发展的同时，软件行业却日益显得困难重重，甚至出现了“软件危 机”。方面硬件技术按照摩尔定律以指数方式不断快速发展，硬件产品的功能和容量获得 了上亿倍的提高，另一方面，软件产品的生产率却显得相当低下。随着对软件产品的要求日 益提高，软件产品的规模日益扩大，软件开发却经常陷于进度极度延迟，成本不断超出预算， 软件的质量难以保证的困境。如何提高软件产品的生产率和质量成了迫切需要解决的问题。 第一节软件过程 虽然人们希望通过应用新的软件方法和技术，如结构化编程，面向对象的开发，和客户 机服务器等，来提高生产率和质量的希望。但经过了几十年，软件行业发现新的软件方法 和技术并不能解决软件开发所面临的所有问题。而且随着软件产品复杂度的提高，软件开发 在功能、成本、时间和质量上的问题越来越严重。 于是软件组织开始意识到，在无纪律混乱的软件开发状态下，组织不可能从较好的方法 和工具中获益。软件组织的基本问题是不能够管理其软件过程，软件开发中的问题需要从软 件过程中寻找答案。在过去，软件开发完全依赖于个人或者一个优秀的团体。而随着项目规 模的扩大，个人的因素已经不能保证整个项目获得良好的交流、协调和一致。没有一个组织 范围的软件过程定义，也使得能否重复一个成功的案例完全取决于是否由同样的人进行同样 的项目。仅仅建立在可得到特定人员上的成功不能为组织软件产品的生产率和质量的长期提 高打下基础。软件组织需要建立有效的软件工程和管理实践等过程基础设施，通过组织的软 件过程定义，来实现软件产品开发的可重复，不断提高软件开发的能力。 过程就是为获得某一结果而进行的一系列活动、变化或操作。戴明认为为了保持竞争力， 提高质量和生产率，则需要集中于生产产品和提供服务的过程来提高质量和生产率。生产产 品和提供服务活动是一系列相互联系，不可分割的过程集合，需要充分地对这些过程提供支 持，并通过改进过程来提高过程性能。戴明的p d c a 循环体现了过程思考的方法，通过计划、 执行、检查和改进来不断地提高过程的能力。 w a t t ss h u m p h r e y 首先将过程思考的方法纳入到软件开发中，在他1 9 8 9 年出版的管 理软件过程一书中，构造了一个软件过程成熟度的框架模型来实现一个受控的软件过程， 指导软件过程持续改进。在其之后，出现了很多的软件过程改进的方法和标准，如 i s 0 9 0 0 0 3 ，t i c k i t ，软件能力成熟度模型( c m m ) ，和i s o i e c1 5 5 0 4 等。这些方法和标准 都集中于改进软件过程来提高软件开发的质量和生产率。 】 软件过程与软件过程改进 在成熟的软件过程中，管理者跟踪软件产品的质量和顾客的满意程度。通过客观的定量 的方法来判断软件产品质量，分析软件产品及软件过程问题。软件过程一致地遵循一个软件 过程标准，并存在支持该过程的必要基础。进度和成本预算是基于以往的过程性能数据，通 常都能达到在功能、成本、时间和质量上的预期结果。组织具有管理软件开发过程的能力， 软件过程计划、规程和标准被准确地通知到所有的软件过程人员，工作活动均按照定义的过 程计划进行。组织和项目中，所有的岗位及其职责都是清晰的。在成熟的软件组织中，存在 着一个清晰的软件过程改进框架，通过规定的步骤和手段改进组织软件过程和提高组织软件 过程能力。 提高组织的软件过程能力，组织需要建立一个软件过程改进的框架模型。这个框架模型 定义了一个成熟的软件过程在软件开发过程中所需要实现的各项规程和标准，包括软件过程 的工程活动( 需求分析、设计、编码、测试、文档和维护等) 和管理活动( 计划、控制和质 量保证等) 。这个框架模型还需要包括组织软件过程改进的指导，也就是如何评价组织自身 的软件过程，如何针对问题提出过程改进建议，和任何有步骤地进行组织的软件过程改进。 第二节软件过程改进相关实践 对于软件过程评价和软件过程改进，国际上存在着两个通用的标准，一个是卡耐基梅 隆大学的软件工程研究所的软件能力成熟度模型( c 删) v i 1 ，另一个是i s o 和1 e c ( 国际 电子技术委员会) 共同制定的i s o i e c1 5 5 0 4 国际标准。c m m 与1 5 5 0 4 两者都定义了软件过 程所覆盖的范围，不同能力等级的软件过程所需要满足的条件，以及进行软件过程评价的方 法和过程。同时，c 删与1 5 5 0 4 的等级体制，为组织的软件过程改进提供了“路标”，组织 可以沿着标准所设定的方向而不断地改进软件过程，提高软件过程能力。 一软件能力成熟度模型 软件能力成熟度模型( c m m ) 是卡耐基梅隆大学的软件工程研究所( s e i ) 应联邦政府 的要求开发的，帮助软件企业改善其软件过程的一个标准。自9 3 年m a r kp a u l k 等编写了软 件能力成熟度模型( c 删) 1 1 版后，该标准事实上就成为软件行业对软件过程能力评价的 行业标准。截止到2 0 0 1 年2 月底，全球共有5 7 家公司通过了最高的c 姗5 级认证，6 6 家 通过了c m m4 级认证。在中国，摩托罗拉中国软件中心和摩托罗拉t c s g 开发中心分别于2 0 0 0 年9 月和2 0 0 0 年1 2 月通过了c m m5 级认证。 c m m 的基本思想是软件产品是软件过程的结果，软件产品的质量是由软件过程的能力所 决定的。软件过程能力代表了通过遵循软件过程而能够实现预期结果的程度。软件过程成熟 度则是一个特定过程被明确地定义、管理、测量、控制和有效的程度，它意味着能力上的增 长潜力。具有高成熟度的软件组织能够在预期的时间内开发出高质量的目标软件产品，并能 够获得更高的生产率。 c m m 将企业的软件过程能力从低到高分为初始级、可重复级、已定义级、已管理级和优 化级等5 个等级。它提供了一个进化性的，而不是创新性的过程能力不断改进的框架。在每 2 软件过程与软件过程改进 一等级中部包含一组过程目标，当这些目标满足时，就意味着软件过程能力达到了某个稳定 的成熟状态，也就是某个特定的成熟度等级。随着成熟度等级的不断提高，企业的软件过程 能力能够相应地不断增长。下表中列入了能力成熟度5 个等级的特征描述和相应的关键过程 区域。 表卜lc m m 成熟度等级描述 成熟度等级成熟度等级描述关键过程区域 等级1 一初始级软件过程的特点是无秩序的，偶尔甚 至是混乱的。几乎没有什么过程是经 过定义的，成功依赖于个人的努力。 等级2 一可重复级企业已建立基本的项目管理过程去跟需求管理 踪成本，进度和功能。必要的过程原软件项目计划 则已经就位，使具有类似应用的项目软件项目跟踪和监督 能重复以往的成功。软件子合同管理 软件质量保证 软件配置管理 等级3 一己定义级管理活动和工程活动两方面的软件过组织过程聚焦 程均已文档化，标准化，并集成到组组织过程定义 织的标准软件过程中。全部项目均采培训大纲 用企业内供开发和维护软件用的标准集成软件管理 软件过程的一个经批准的剪裁版本。软件产品工程 组内协调 同行评审 等级4 一已管理级 已采集详细的有关软件过程和产品质定量过程管理 量的数据。无论软件过程还是产品均软件质量管理 得到定量的了解和控制。 等级5 一优化级 利用来自过程和来自新思想，新技术缺陷预防 的前瞻性试验的定量反馈信息，使持技术改革管理 续过程改进成为可能。过程改造管理 除了等级l 以外，每个成熟度等级被分解成几个关键过程区域( k p a ) ，指明为了改进软 件过程能力，组织必须关注解决的问题。每一个关键过程区域包括一组目标，当实现这组目 标后，组织就拥有了该关键过程区域所描述的过程能力。 关键实践则描述了对关键过程区域的有效实施和制度化贡献最大的政策、过程和活动。 每个关键实践能够对该关键过程区域的一个或数个目标的实现做出贡献。关键实践描述了应 做“什么”，而不是应“如何”实现目标，其他的替代实践也可能实现该关键过程区域的目 标。在能力成熟度模型的关键实践11 版中详细列出了每个关键过程区域上的所有关键 实践。 每个关键过程区域中的关键实践按一组共同特点加以组织。共同特点是表明一个关键过 程区域的实施和制度化是否有效，是否可重复持久的一些属性。同时共同特点也将关键实践 分组和排成序列，方便企业使用它们。一共有五个共同特点，分别是： 执行约定描述组织为保证过程得以建立和继续起作用所必须采取的行动。 执行能力描述为了能实施软件过程，项目或组织中必须存在的先决条件。 执行的活动描述为实现一个关键过程区域所必须的任务和过程。 测量和分析描述对过程进行测量和对测量结果进行分析的需要。 验证实施描述那些能保证实施的活动与己建立的过程标准相一致的措施。 二i s o i e c1 5 5 0 4 i s o i e c1 5 5 0 4 ( 以下简称1 5 5 0 4 ) 系列标准是1 5 0 和i e c ( 国际电子技术委员会) 共同 制定的关于软件过程评价框架的国际标准，共分为9 个部分。这个框架包括了软件过程的计 划、管理、监督、控制和改进，这些过程涉及软件的获取、供应、开发、操作、发展和支持 等。它提供了一个结构化的过程来进行软件过程的评价。在该标准的第二部分，1 5 5 0 4 2 中， 定义了一个用于过程评价的两维的参考模型，该模型按照作用和结果的不同定义了一系列的 过程，并建立了一个用于评价过程能力的分级评价体系。在1 5 5 0 4 - 5 中则给出了一个与 1 5 5 0 4 2 相兼容的评价模型例子。 这是一个两维模型，由过程维和过程能力维两个部分组成： 过程维包括基本生命周期过程( 顾客一供应商过程类和工程过程类) ，支持生命周期过程 ( 支持过程类) 和组织生命周期过程( 管理过程类和组织过程类) ，其中： 顾客一供应商过程类( c u s ) 包括：获取过程，供应过程，需求启发过程和操作过程。 工程过程类( e n g ) 包括：开发过程和系统和软件维护过程。 支持过程类( s u p ) 包括：文档过程，配置管理过程，质量保证过程，验证过程， 确认过程同评审过程，审计过程和问题再解决过程。 管理过程类0 4 a n ) 包括：管理过程，项目管理过程，质量管理和风险管理。 组织过程类( o r g ) 包括：组织调整过程，改进过程，人力资源管理过程，基础结 构过程，评价过程和再使用过程。 过程能力维包括一组按能力等级( 共分为6 级) 而组织的过程属性。这些属性分别描述 了组织在管理和改进某个过程时某一个方面的能力。结合在一起，这些属性表明了组织执行 某个过程的能力。 表卜2i s o i e c1 5 5 0 4 能力等级描述 能力等级能力等级描述过程属性 等级0 一未完成通常不能实现过程的目标。过程很少有工作产 品和结果，或者这些产品和结果很难确认。 等级1 一已执行过程的目标往往能实现。实现过程可能没有被 过程性能属性 严格地计划和跟踪。组织中的个人认识到某项 活动必须被执行，也存在着对何时并如何完成 活动的一致看法。过程有可确认的产品，这些 产品证明了目标的实现。 等级2 一己管理过程按照给定的规程生产出工作产品，生产是性能管理属性 有计划并被跟踪的。工作产品符合给定的标准工作产品管理属性 和要求。 等级3 一己制定过程的执行和管理建立在基于良好的软件工过程定义属性 程原理基础上的已定义的过程。单个过程的执过程资源属性 行使用已被批准的文档化的标准过程库的一 个剪裁后的版本。建立过程定义所必需的资源 也都已经到位。 等级4 一可预测定义的过程在定义的控制区间内为达到定义过程测量属性 的目标而一致地进行。对于性能的具体的指标过程控制属性 进行了收集和分析。这带来了对过程能力的定 量了解和在预测和管理能力上的提高。性能已 经被定量化管理，工作产品的质量也已经定量 化。 等级5 一优化级过程的性能己被优化来满足当前和未来的业过程变化属性 务需要，过程能够重复地满足确定的业务目持续改进属性 标。建立了基于组织业务目标的性能的定量化 过程效率目标。通过获得定量化的反馈可以持 续地按照目标监控过程，并通过对结果的分析 来实现改进。优化一个过程包括指引创新性的 想法和技术，改造低效率的过程来满足确定的 目标。 除了等级0 以外，每个等级上的过程属性衡量过程能力的一个方面，确定是否一个过程 达到了给定的能力。过程属性按照百分数( o 一1 0 0 ) 评价，共分为4 个类别：未达到( 1 一1 5 ) ， 部分达到( 1 6 一5 0 ) ，大部分达到( 5 1 一8 5 ) 和完全达到( 8 6 一1 0 0 ) 。为了达到某个能 力等级，该过程必须“大部分达到”或“完全达到”该等级上的所有过程属性，并且“完全 达到”该等级以下各等级的所有过程属性。 过程维和过程能力维在一起构成了一个矩阵，共同对软件组织的过程能力进行评价。过 程维中定义了每个过程的作用，过程能力维中则定义了每一个等级的过程属性。通过评价每 一个过程的各个过程属性的实现程度，可以了解组织在管理和执行该过程时的能力，综合过 0 软件过程与软件过程改进 程维中所有过程的评价就能够获得关于组织整体软件能力的信息。 三c 与1 5 5 0 4 的比较 c m m 与1 5 5 0 4 两者都采取了分级形式的评价体系，体现了一种持续改进的思想。软件组 织可以按照标准所设定的台阶，一步一步地改进其软件过程，达到过程能力的不断提高的目 标。两者分级的标准也具有一定的可比性，按照两者的指引，组织的过程能力改进将沿着相 似的平行道路而前进。通过对照可以看出，c 吼的关键过程区域和1 5 5 0 4 的过程维覆盖的范 围大部分上是一致的。大多数c m m 的关键过程区域都可以在1 5 5 0 4 过程维中找到对应的过程， 反过来也是一样。 但c 删与1 5 5 0 4 之间也存在着不同： c m m 所覆盖的范围主要集中于软件开发的内部过程。而1 5 5 0 4 则将范围扩大到了外 部，将对顾客的服务过程( 包括顾客需求启发，安装和操作支持，维护等) 也纳入 到了评价体系中来，弥补了c 删在高能力成熟度等级上的不足。 c 删的对象是整个组织的过程能力，目标是提高整个组织的过程能力。隐藏在c m m 背后的假设是组织的过程能力是软件产品质量的基础。而1 5 5 0 4 则集中于每一个过 程，目标是提高每一个过程的能力。在1 5 5 0 4 的框架里，每一个过程是相对独立的， 相互间是松散地联系在一起。 c 删集中于指导如何进行过程能力改进，它使用了4 0 0 多页的篇幅来描述关键过程 区域和相关的关键实践，指导组织的过程能力改进。1 5 5 0 4 则主要提供了一个对过 程能力进行评价的方法，而不是具体的指导。它所给出的1 5 5 0 4 2 是一个抽象的参 考模型，只是定义了一组过程的作用和期望结果，以及一组用于能力评价的过程属 性，而没有描述达到某个能力等级对过程的具体要求。 c m m 是基于项目的基础上对性能指标进行数据采集和分析来评价组织的软件过程 能力，采用的是两级的评价标准( 达到和未达到) ，评价的是软件过程的成熟度等 级。1 5 5 0 4 的数据采集和分析则是基于每一个过程的基础上，是对每一个特定过程 的过程能力属性的评价，采用的是四级的评价标准( 完全达到，大部分达到，部分 达到和未达到) 。 c 州是一个阶段性的模型。每一个关键过程区域都是与一个特定的成熟度等级相联 系的，同时每一个成熟度等级也都有其不同的关注重心一关键过程区域。成熟度等 级评价的是整个组织的软件过程能力，每一个等级上的关键过程区域都是下一个等 级的基础，因此不可能跨越某一个或多个等级，也不能忽略这些关键过程区域。 1 5 5 0 4 则是一个连续性的模型。它分别定义了过程维和过程能力维，模型评价的是 单个过程的能力而不是整个组织的能力，每一个过程可以随着不断地改进而不断提 高能力等级。 6 第三节软件过程改进的途径 虽然通过提高软件过程能力来提高组织软件产品的生产率和质量已成为共识，但如何改 进软件过程，提高软件过程能力还是一个有待研究的领域。现实中的困难存在于两方面，软 件行业本身和软件过程改进的方法。 软件行业是一个相对较新的行业，从第一台计算机的出现到现在也不过5 0 多年的时间。 如果从8 0 年代开始的软件行业的飞速发展开始计算，那么这个行业则更加显得年轻。但另 一方面，软件行业的发展却是有史以来最为迅速的。i n t e r n e t 和多媒体的加入更促进了这 个行业的发展。短暂的历史和快速的发展相结合，结果是在软件开发中更多地强调个人的因 素，强调技术的创造性和市场的敏感性。这种对个人英雄主义的推崇带来的就是软件开发过 程中缺乏对过程的重视和积累。往往软件组织没有明确定义的软件过程，完全依靠项目经理 和项目成员的个人经验和技能。 在软件过程改进方法这一方面，软件组织更多地是从软件开发技术的角度来提高软件开 发的效率和软件产品的质量。于是各种测试方法和测试技术纷纷被发明和使用。虽然这些测 试方法和技术在一定程度上保证了软件产品的质量，但由于它们并没有能够提高软件开发过 程活动的效率，因此往往是以时间为代价来换取质量的保证。另外随着软件系统规模和复杂 程度的不断扩大，已经难以对整个软件系统进行穷举或近似穷举的测试，因此仅仅依靠测试 也难以保证软件产品质量的提高。 对软件过程改进中的问题，解决的方法是采取一条有效的软件过程改进的途径。也就是 通过设计、实施、分析和改进的循环来不断地提高组织的软件过程能力。 在这个循环中，对于年轻的软件行业来说尤其重要的有两个方面：一个是认识和理解软 件过程，另一个是分析和改进软件过程。 提高软件产品的质量和生产率，首先需要认识软件过程，了解软件过程所包含的内容。 软件开发过程包含了从需求分析，软件设计，软件编码和软件测试的全过程。软件过程建立 和实施的基础就是组织分析组织内部特点和行业最佳实践而设计出来的软件过程框架模型。 软件过程框架定义不仅能够帮助设计一个高效且能够不断改进的软件过程，它还有助于建设 面向过程的组织文化。 第二个问题是如何不断地通过改进组织的软件过程来提高组织软件产品的质量和生产 率。除了定性化的手段，数据测量、过程分析和改进这一在其它行业已取得成功的过程改进 途径同样能够应用于软件过程。通过进行软件过程关键性能数据的测量和分析，从而了解软 件过程中所存在的问题，然后沿着稳定软件过程的性能和提高软件过程能力的道路不断地改 进软件过程，从而获得组织在软件产品质量和生产率上的提高。 7 软件过程与软件过程改进 第二章基本软件过程 从软件开发过程的角度来看，软件开发包含了一系列工程和管理的活动，这些活动最终 的结果是软件产品。软件产品经过了软件开发过程各个环节而最终完成的，因此软件产品的 性能、质量和开发效率直接受到软件过程的影响。事实上一个软件产品开发的成功有两个主 要的决定因素，一个是组织的创新能力，另一个就是组织的过程能力。软件过程的能力就是 一个组织或者项目在开发软件产品活动中对包括成本，时间和质量等属性的预期结果。具有 高软件过程能力的组织能够在较低成本，较短的时间里开发出满足顾客功能要求和质量目标 的产品；相反低过程能力的组织往往存在成本不断超出，工期不断拖延，产品中存在较多错 误等问题。软件过程能力是组织以往开发经验和管理能力的体现，在某种程度上它反应了组 织重复以往成功的能力，高软件过程能力能够保证组织有效地利用过去的经验来取得同样或 者相似的成功。 软件过程包括了软件开发的整个生命周期，它不仅包括软件开发的工程活动，如分析， 设计，编码，测试和维护等。还包括了软件开发的管理活动，如项目计划，项目控制，质量 保证和配置管理等。这些活动的综合构成了一个完整的软件过程，也就是软件产品的生产过 程。在定义软件过程的覆盖范围时，可以有很多自由的选择。但是与软件开发直接相关的活 动，如软件需求管理，项目计划，项目控制，软件质量保证，软件工程管理，和软件配置管 理，是一个完整的软件过程所必不可少的，必须被列入软件过程中。这些活动也可以称为基 本软件过程。软件过程的组成决定了组织如何开展软件开发活动，和组织如何系统地积累和 使用历史经验。 基本软件过程包括： 软件需求管理 软件项目计划 软件项目控制 软件工程管理 软件质量保证 软件配置管理 优良的软件产品是基于软件过程的良好性能。而软件过程的良好性能则来自于完善的软 件过程定义和软件过程执行。软件过程的定义和遵照执行可以带来以下的好处： 消除软件开发活动的混乱和无序，提高软件过程和软件产品的预测能力。 保证组织系统地积累和使用历史经验，比如识别某个问题发生的方法可以被纳入软 件过程中来防止同样的错误出现在将来的软件项目中。 通过将软件过程分解，可以方便地定位问题，发现问题的原因。 完善的软件过程定义需要涵盖多个方面的内容，规定每一项过程的输入，必须完成的活 动和需要产生的产品和中间产品。由于各个组织的文化，环境和应用领域不同，不可能对所 r 软件过程与软件过程改进 有的组织定义一个通用的“怎么做”的具体步骤，但是软件开发的内在一致性使得我们可以 从小同的软件开发实践中抽象出“做f t 么”行动指导。“做什么”也就是只规定需要完成的 任务和期望结果，而如何完成任务，选择什么样的工作模型，不同的组织可以根据自身的情 况制定自己的具体程序。 第一节软件需求管理 软件项目源自与对软件的需求，软件需求可能是直接的( 来自对软件产品的直接需要) ， 也可能是间接的( 来自系统产品对软件部分的需要) ；可能来自于组织外部的顾客，也可能 来自于组织内部。软件需求产生了软件项目，从而有了软件计划、开发和维护等活动，软件 需求是检验项目开发活动有效性和最终软件产品是否符合顾客要求的标准。偏离需求的活动 是无效的活动，会带来成本、时间和顾客满意度等指标的恶化。因此需要保持软件开发活动 与顾客需求之间的一致性，使得所有的努力都能够创造顾客的满意。 为了能够开发出顾客所需要的产品和满足顾客的需要，软件项目组必须全面准确地理解 顾客的需求。这种需求包括了顾客直接表达的和内在需要的，需要以适当的形式在顾客与项 目组之间建立对需求的一致理解，并在项目组内同样保持对需求理解的一致性，建立起与软 件需求相一致的软件开发计划、活动和工作产品。当顾客的需求发生变化时，所发生的变化 需要正式地记载下来，并按照一定的方式通知到所有受影响的小组，按照一定的方式修改计 划、活动和工作产品，使得软件开发按照变化后的需求为指导而进行。 需求管理主要包括以下几个活动： 建立软件需求 评审软件需求 控制软件需求变化 同步软件需求 一建立软件需求 软件项目组需要在分析来自顾客的要求的基础上，建立项目的软件需求。软件需求文档 是软件项目组对顾客需求理解的正式结果，经过双方共同同意的软件需求代表了软件项目组 和顾客之间达成的一致。它提供了一个指导和检验的共同标准，指导着软件项目组内各小组 的计划、活动和工作产品，建立了对最终产品的检验准则。 软件需求文档一般需要包括技术性和非技术性两方面的内容，以及相关的验收准则。 技术性的内容包括： 产品的功能要求。 产品的性能要求。 产品运行的环境和其它约束条件。 产品质量要求，包括可靠性，可维护性，用户友好性等要求。 t i e 技术性的内容包括： 9 软件过程与软件过程改进 需要交付的产品和产品的形式，如源代码，文档和测试报告等。 产品交付的日期。 产品的里程碑和各个里程碑要求。 软件产品质量保证的要求。 二评审软件需求 为了保证软件需求的正确性和一致性，在建立正式软件需求并纳入软件项目前需要对相 应的需求内容进行评审。评审的目的是检验软件需求的： 完整性。所有相关的项目都已经被写到文档中。 可行性。软件需求在技术性和非技术性问题上能够获得可行的解决方案。 一致性。需求中的各个项目间是一致的，不存在矛盾的地方。新加入的需求能够与 先前的需求相一致。 明确性。软件需求中不存在含糊，二义性的表达。 可测试性。可以按照软件需求所定义验收准则对最终产品进行客观的检验。 在需求评审中发现的问题需要由软件需求制定人员做进一步分析，并做出必要的修改来 符合要求。 根据评审的内容和层次不同，评审参加的对象也可能不同，如顾客或顾客代表，软件经 理，开发和测试组，质量保证组，软件配置组，和文档支持组等。软件需求评审需要将软件 需求制定和评审过程中所产生的责任安排在有关小组间进行协商，并将最终结果以书面的方 式记录下来。形成的责任安排是软件项目对各小组的要求，各小组需要在该责任安排的基础 上制订各自的计划、活动和工作产品。 三控制软件需求变化 在软件开发领域，项目进行中顾客的需求往往会发生变化。为了保证软件需求与软件开 发计划、活动和工作产品的一致性。需要通过正式的方法将新的或者变化的需求纳入到软件 项目中。 软件需求的变化需要在顾客和项目组，项目内相关的小组之间进行评审。各小组按照自 己的责任和工作特点对需求的变化进行讨论，分析需求变化的范围和对需求其他部分的影 响，评审新需求的完整性、可行性和一致性，评估新需求所带来的技术、成本、时间和质量 风险，协商并记录新需求对于相互间的责任分配的影响。 在对新的需求取得一致后，新的需求按照规定的方式记载入软件需求文档。所有受影响 的小组获得最新的软件需求文档，并收回旧的需求文档。新的软件需求纳入以后，旧软件需 求不再有效，只是作为追溯的需要存在于软件项目内。 软件需求应受到管理和控制，具有追溯性，也就是获得过去各个时间的软件需求版本和 相应的修改信息。 1 0 四同步软件需求 同步软件需求建立起软件需求内部不同层次，以及软件需求与软件开发计划和工作产品 问的双向联系。这种双向联系保证了软件需求变化控制，以及软件项目计划和工作产品与软 件需求保持一致的要求。 软件需求同步需要从高层次的软件需求跟踪到细化后的低层次软件需求，并从低层次的 软件需求回溯到高层次的软件需求。软件需求同步还需要建立软件需求与软件工作产品、软 件设计、软件代码、软件测试计划和相应的活动间的联系。通过软件需求同步可以衡量软件 需求变化对软件开发计划、活动和工作产品的影响。 当需求变化后，项目组内各小组根据变化后的需求对各自相应的计划、活动和工作产品 做出修改，使其与新的需求保持一致。由于需求变化而引起的进度、人员和资源安排需要满 足项目新的里程碑、成本和时间的约束要求。 第二节软件项目计划 软件项目计划是对将要进行的软件开发活动和管理活动做出具体的合理的安排。软件开 发活动包括工程活动和管理活动，工程活动如需求分析，概念设计，详细设计，编码，测试 和维护等；管理活动如项目控制和监督，质量保证，配置管理等。为了项目开发的有效性和 高效率，需要统筹兼顾所有的活动，根据每一项活动的工作量，人员和资源需要，以及各项 活动间的依赖关系对这些活动的时间、人员和资源使用做出合理的安排。 软件开发计划的内容包括以下几个部分： 软件项目的工作陈述，包括软件项目的目的、范围、目标、和对象。 软件项目的生命周期模型。 开发和维护软件的规程和标准，包括软件开发和测试，软件质量保证，软件配置管 理和软件测量等活动的规程和标准。 软件工作产品的定义，包括最终交付的产品，软件项目组内部使用的工作产品和提 供给其他外部项目使用的工作产品等。 软件项目估计，包括产品规模，工作量和成本，人员和其它资源和项目进度的估计。 软件项目风险的识别和评估。 软件项目测量计划。 软件项目人员和资源计划。 软件项目培训计划。 软件项目计划首先需要明确所需要进行的任务和实现的目标，以及所受的条件约束。然 后在对产品和产品生产活动分解的基础上，对产品规模、工作量、时间做出合理的估计，并 按照估计对人员，资源和开发进度做出具体的安排。制定软件开发计划需要考虑技术、成本、 时问和产品质量的要求对于软件项目的影响。 软件开发计划是软件项目控制和监督的基础，是项目经理的一项主要工作职责。能够制 1 】 订一个完善而合理的计划是成熟软件过程的表现，它需要对软件过程能力的准确预测和剥项 目性能的完整把握。 软件项目计划主要包括以下几个活动： 建立工作陈述 选择软件生命周期模型 进行项目估计 安排工作进度 评估项目风险 制定辅助计划 评审软件开发计划 一建立工作陈述 软件项目计划的第一步是确定软件项目的工作范围，建立正式的工作陈述文档。工作陈 述是对软件项目的概括，它规定了软件项目的技术和非技术目标，约束条件和所需要承担的 责任。建立工作陈述是为了了解将来的软件开发所需要进行活动以及需要达到的标准。 为了建立工作陈述，需要首先对软件需求进行分析，获得对最终产品和产品运行环境的 了解。对软件需求的分析不仅仅包括技术性问题的分析，还需要包括非技术性问题如约束条 件，实现标准和责任安排等的分析。 一个完整的工作陈述包括： 工作产品的定义。 工作的范围，包括项目的输入，中间处理和输出结果。 按照产品结构对开发活动的划分。 产品的技术目标。 顾客和最终用户的识别。 产品和过程需要达到的标准。 成本、人员、资源和时间约束。 软件项目组与其他内部和外部小组之间的依赖关系和责任分配。 二选择软件生命周期模型 软件生命周期模型决定了软件的开发过程，以及由此而产生的工程活动和管理活动。可 供选择的软件生命周期模型包括：瀑布模型，重叠瀑布模型，螺旋模型，原型模型，增量模 型等。不同的软件生命周期模型决定了所需要进行的开发活动和各项活动间的顺序安排。因 此软件生命周期模型的选择会直接影响项目阶段的划分，项目估计的计算，以及项目进度的 安排。因此需要在软件项目计划的早期明确所选用的软件生命周期模型。 软件项目需要按照项目的实际特点，资源的情况和过去的历史经验选择一个合适的软件 生命周期模型。选择模型时需要考虑： 】2 需求的稳定性和变化速度。 选用的软件开发工具。 项目和人员的经验技能。 顾客对里程碑的要求。 三进行项目估计 软件项目计划需要进行进度安排，分配人员和其它资源，因此需要对产品规模、工作量， 时间以及资源耗费做出合理的估计。项目估计建立在产品规模、工作量、时间、资源以及进 度问存在着内在的联系，比如产品规模是需求的函数，工作量、时间和资源耗费是产品规模 的函数。这种内在的联系使得可以通过某种方式对产品和项目做出预测。 产品规模估计的对象包括运行软件和支持软件，交付的和不交付的产品，以及软件和非 软件产品( 如文档) 。规模估计可以通过功能点数、代码行数、对象和类的数量、或者需求 数量等指标来计算。 工作量往往软件产品的规模有着内在的关联，可