基于风险管理的软件生命周期模型研究

第２７卷第５期　通信学报　Ｖ０１．２７　Ｎｏ．５　２００６年５月　Ｊｏｕｒｎａｌ　Ｏｉｌ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｍａｖ　２００６　基于风险管理的软件生命周期模型研究　钱鸿生　，黄立平　（１．国信朗讯科技网络技术有限公司，上海２００１２７　２同济大学经济与管理学院，上海２０００９２）　摘要：针‘对现有软件项目风险管理中存在的问题，通过对几种常见软件生命周期模型的分析，探讨了将改进的　瀑布型模型的每一阶段与风险管理相结合的风险识别法，提出了基于风险管理的软件生命周期模型的研究，使项　目管理人员能将风险模板作为一种工具，对可能发生的风险进行有效的控制和管理，并对软件风险的关联和转移　有新的认识。　关键词：风险管理：软件生命周期：模型研究　中图分类号：ＴＰ３　ｌ１．５　文献标识码：Ａ　文章编号：１０００—４３６Ｘ（２００６）０５－０１３５，０６　Ｒｅｓｅａｒｃｈ　ｏｎ　ｓｏｆｔｗａｒｅ　ｌｉｆｅｃｙｃｌｅ　ｍｏｄｅｌ　ｂａｓｅｄ　ｏｎ　ｒｉｓｋ　ｍａｎａｇｅｍｅｎｔ　ＱＩＡＮ　Ｈｏｎｇ．ｓｈｅｎｇ　，ＨＵＡＮＧ　Ｌｉ　ｐｉｎｇ　（１．Ｇｕｏｘｉｎ　ＬｕｃｅｎｔＴｅｃｈｎｏｌｏｇｉｅｓ　ＮｅｔｗｏｒｋＴｅｃｈｎｏｌｏｇｉｅｓ　Ｃｏ．，Ｌｔｄ，Ｓｈａｎｇｈａｉ　２００１２７，Ｃｈｉｎａ　２．Ｅｃｏｎｏｍｙ　ａｎｄ　Ｍａｎａｇｅｍｅｎｔ　Ｉｎｓｔｉｔｕｔｅ，Ｔｏｎｇｊｉ　Ｕｎｉｖｅｒｓｉｔｙ，Ｓｈａｎｇｈａｉ　２０００９２，Ｃｈｉｎａ）　Ａｂｓｔｒａｃｔ：Ｔｏ　ｔｈｅ　ｐｒｏｂｌｅｍｓ　ｅｘｉｔｉｎｇ　ｉｎ　ｓｏｆｔｗａｒｅ　ｒｉｓｋ　ｍａｎａｇｅｍｅｎｔ，ａｎａｌｙｚｅｄ　ｓｏｍｅ　ｆａｍｉｌｉａｒ　ｓｏｆｔｗａｒｅ　ｌｉｆｅｃｙｃｌｅｓ，ｄｉｓｃｕｓｓｅｄ　ｔｈｅ　ｗａｙ　ｏｆ　ｒｉｓｋ　ｉｄｅｎｔｉｆｙｉｎｇ　ｃｏｍｂｉｎｇ　ｅｖｅｒｙ　ｐｈａｓｅ　ｏｆ　ｕｐｇｒａｄｅｄ　ｗａｔｅｒｆａｌｌ　ｍｏｄｅｌ　ｗｉｔｈ　ｒｉｓｋ　ｍａｎａｇｅｍｅｎｔ，ｅｌｉｃｉｔｄｅ　ｓｏｆｔｗａｒｅ　ｌｉｆｅｃｙｃｌｅ　ｍｏｄｅｌ　ｂａｓｅｄ　ｏｎ　ｒｉｓｋ　ｍａｎａｇｅｍｅｎｔ．Ｈｅｒｅｂｙ　ｐｒｏｊｅｃｔ　ｍａｎａｇｅｒｓ　ｃａｎ　ｕｓｅ　ｒｉｓｋ　ｐａｔｔｅｒｎ　ａｓ　ａ　ｔｏｏｌ　ｉｎ　ｃｏｎｔｒｏｌｌｉｎｇ　ａｎｄ　ｍａｎａｇｉｎｇ　ｐｏｔｅｎｔｉａｌ　ｒｉｓｋ　ｅｆｆｅｃｔｉｖｅｌｙ，ｇｅｔ　ａ　ｎｅｗ　ｃｏｎｃｅｐｔ　ｏｎ　ｒｉｓｋ　ａｓｓｏｃｉａｔｉｏｎ　ａｎｄ　ｔｒａｎｓｆｅｒ．　Ｋｅｙ　ｗｏｒｄｓ：ｒｉｓｋ　ｍａｎａｇｅｍｅｎｔ；ｓｏｆｔｗａｒｅ　ｌｉｆｅｃｙｃｔｅ；ｍｏｄｕｌｅ　ｒｅｓｅａｒｃｈ　１引言　技术要求也越来越高，软件开发的风险也越来越　大。因此，如何加强软件项目管理技术的研究，也　随着世界进入了信息时代，信息化在促进了软　引起了全世界各国理论工作者和项目管理人员的　件系统规模发展的同时也增加了软件开发的复杂　普遍关注，特别是在软件项目管理中引入了风险管　程度和风险性。项目管理技术是２０世纪５０年代以　理的概念之后，人们对于软件开发开始有了危机　后发展起来的一种工程管理方法，它的出现马上引　感，正是由于有了这种危机感，才使得软件项目管　起了人们的广泛关注，并立刻被应用到了设备制造　理技术的研究也进入了一个新的发展时期。　和航天科技的项目管理之中，并从根本上改变了人　对于任何软件项目而言，风险是客观存在的，　ｆｆ］的思维方法、工作程序，提高了工作效率，降低　你不可能视而不见，它真实地存在人们所寄希望成　了项目的风险程度。　功的软件项目的每一个环节之中，必需去正视它，　软件项目管理是一种特殊的项目管理，它既有　研究它的发生和发展，探索它产生的各种原因，掌　一般项目管理的普遍性，又具有其特殊性。随着社　握它的变化规律。这样对风险进行有效的管理才是　会信息化应用的发展，软件系统的规模越来越大，　一种科学的方法。任何回避风险、视而不见、任其　收稿日期：２００６—０３—１３；修回日期：２００６—０４—０１　维普资讯 http://www.cqvip.com

通信学报　第２７卷　发展而不采取有效的措施的态度都会使得风险最　终将变成灾难。　在研究软件项目管理的过程中，人们发现软件　如同任何事物一样，都有一个孕育、诞生、成长、　衰亡的过程，把这种过程称之为软件生命周期　（ｓｏｆｔｗａｒｅ　ｌｉｆｅ　ｃｙｃｌｅ）　各国学者纷纷从不同的技术　发展途径和软件项目管理的理念出发，提出了适合　不同软件开发环境的软件生命周期模型［　１。　本文主要研究风险管理在软件生命周期模型　中的应用，并在改进型的瀑布模型的不同阶段引入　核心风险模板和过程风险模板作为一种风险识别　的工具，这对于提高我国大型软件系统开发的风险　管理能力具有重要的现实意义。　２软件生命周期模型的分类　目前，国际上一般把软件生命周期分为以下几　个大类：　第一类：瀑布型模型（ｗａｔｅｒｆａｌｌ　ｍｏｄｅ１）［　８】　这是一种较为典型的软件生命周期模型，是　Ｗ　Ｒｏｙｃｅ于１９７０年提出的模型，该模型要求软件　系统应采用自上而下分阶段开发的方式。　第二类：原型生存型模型（ｐｒｏｔｏｔｙｐｉｎｇ　ｍｏｄｅ１）［９　０］　该模型是在用户需求确认后快速生成一个原　型系统，通过用户对该系统的主要功能和用户界面　生成的确认来明确软件开发范围的一种方法。　第三类：快速开发模型（ｒａｐｉｄ　ａｐｐｌｉｃａｔｉｏｎ　ｄｅ．　ｖｅｌｏｐｍｅｎｔ　ｍｏｄｅ１）［¨　】　该模型是为了减少与用户需求确认的不确定　因素，将很少的时间用于需求确认，而是采用请最　终用户直接加入到开发团队，开发人员利用专用的　技术工具进行系统规划设计和代码生成，快速搭建　一个系统的开发模型。　第四类：渐进式软件开发模型（ｅｖｏｌｕｔｉｏｎａｒｙ　ｓｏｆｔｗａｒｅ　ｐｒｏｃｅｓｓ　ｍｏｄｅ１）［　】　该模型又可细分为“增量型模型”（ｉｎｃｒｅｍｅｎｔａｌ　ｍｏｄｅ１）、螺旋型模￣ｄ（ｓｐｉｒａｌ　ｍｏｄｅ１）、单元组装模型　（ｃｏｍｐｏｎｅｎｔ　ａｓｓｅｍｂｌｙ　ｍｏｄｅ１）和多点开发模式　（ｃｏｎｃｕｒｒｅｎｔ　ｄｅｖｅｌｏｐｍｅｎｔ　ｍｏｄｅ１）。采用渐进式的开发　模式，逐步逼近软件系统的最终设计目标。　第五类：智能模型（ｉｎｔｅｌｌｉｇｅｎｔ　ｍｏｄｅ１）［　’】　该模型主要是在软件开发中引入专家组或专　家系统的概念，采用一定的专家评审机制，规范和　帮助软件开发人员去完成目标系统的开发工作。　第六类：基于柔性的软件开发模型（ｌｆｅｘｉｂｌｅ　ｓｏｆｔｗａｒｅ　ｓｙｓｔｅｍ）ｔｌｓ，１９￣　柔性软件系统是指在一定范围内满足和适应用　户需求不断发生变化的应用软件系统，这样的软　件系统在使用环境和用户需求发生变化时，不要　修改或者稍加修改就能满足用户的需求，柔性软　件系统又可细分为面向用户需求的柔性、面向系　统的柔性、面向环境的柔性以及面向数据流程和　操作的柔性。　第七类：第四代自动代码生成模型（ｆｏｕｒｔｈ　ｇｅｎｅｒａｔｉｏｎ　ｔｅｃｈｎｉｑｕｅｓ）　该模型简称４ＧＴ，要求软件开发人员只对系统的　高层进行说明，将用户需要解决的问题采用标准化的　语言和图形与用户进行沟通，并经过特殊的软件工具　自动生成代码和操作界面，将复杂的软件开发变成一　种标准化定制工序，降低了用户需求确认过程中的不　确定因素，快速地生成应用系统软件［２０－２２１。　现有软件开发的风险管理理论缺乏与软件生　命周期模型的关联性分析，风险识别的工具和方法　难以满足我国软件系统开发中风险控制和风险管　理的需要，造成目前软件系统开发的成功率较低。　本文提出的基于风险管理的软件生命周期模型将　风险管理与软件生命周期模型每一个阶段的风险　识别结合了起来，便于项目管理人员能较早地发现　可能存在的潜在风险，从而提高软件系统开发的风　险防范能力。　３基于风险管理的软件生命周期模型的提出　本文的主要内容是研究基于风险管理的软件　生命周期模型，该模型的研究主要从以下几个方面　进行：　１）依据瀑布型模型的基本特点和理论框架，在　深入研究纯瀑布模型可能存在的缺陷和在我国大　型软件开发这一特殊环境下应用可能会发生的问　题，提出一套基于风险管理的软件生命周期模型的　理论。　２）在软件生命周期模型中首次引入核心风　险的观点，将每一个过程中可能发生的风险进行　归类分析。更重要的是提出了一种风险预测的方　法，使软件开发项目管理人员能较早地注意到某　一阶段可能会发生的风险，为风险的管理创造有　利条件。　３）在一般风险管理研究的基础之上，对影响到　维普资讯 http://www.cqvip.com

第５期　钱鸿生等：基于风险管理的软件生命周期模型研究　图１基于风险管理的软件生命周期模型体系结构图　整个软件项目开发过程的风险表现进行归纳，提出　很大的风险，特别是在大型软件系统的开发中，作　了过程风险的概念。　为软件生命周期模型的应用成功率较低。　３．１基于风险管理的软件生命周期模型的体系结构　本文根据国际上对与纯瀑布型软件生命周期　提出的基于风险管理的软件生命周期模型体　模型的最新研究成果，结合作者在实证研究中的结　系结构如图ｌ所示。　论，对该模型提出了以下几点改进措施：　３．２体系的主要特征　１）提出现场改进盒的观点：由于在分析纯瀑布　本文提出的基于风险管理的软件生命周期模　型模型的缺陷时已经认识到了该模型缺乏与现场　型是基于纯瀑布模型的一种改进模型，其主要特点　的沟通这一事实，为了增强与软件最终用户的交　是在软件生命周期的每一个阶段引入了核心风险　流，本研究引入了现场改进盒的观点，将软件发布　模板，并对整个软件开发过程提出了ＣＯＳＴ过程风　现场的用户意见反馈作为了整个软件生命周期模　险的观点，该体系的建立基于以下一些基本思路。　型中不可缺少的一个环节。　３．２．１　纯瀑布型模型的改进的几个原则　２）建立了闭环的信息反馈结构：已经知道纯瀑　根据对传统纯瀑布型模型软件生命周期模型　布模型的软件生命周期模型是一个自上而下的开　的分析，我们认为该模型的主要问题是在软件生命　放型结构模型，本研究在分析了该模型的这一问题　周期不同的阶段没有任何信息反馈的渠道。软件开　后认为：为了降低软件开发的风险，在纯瀑布型模　发自上而下顺序进行，因此要求整个软件开发要有　型的改进中必须在合适的地点引入信息反馈渠道。　很强的计划性，一旦计划发生变更，就会造成软件　３）以需求分析为中心的原则：本研究认为对纯　开发成本的迅速上升，甚至导致整个软件开发项目　瀑布型模型改进的另一个原则应该是以用户需求　的失败。这些缺陷使得纯瀑布型模型在使用中存在　确认为中心的原则。在纯瀑布型模型的一般讨论　维普资讯 http://www.cqvip.com

通信学报　第２７卷　中，我们并没有对这个问题予以充分的认识，本研　究认为从改进纯瀑布型模型的结构性能、提高该模　型风险控制的观点出发，必须强调对于用户需求分　析这一重要环节的研究。加强该环节的研究是降低　整个软件项目开发风险的重要举措。　４）在每一个阶段引入风险模板：对纯瀑布型模　型深入研究后发现，软件工程学在研究软件生命周　期模型的一般情况下是不考虑风险管理的作用的。　软件工程学认为软件生命周期模型是研究软件项　目开发的一般过程，而风险管理是一种应用技术和　项目管理的技术，两者是独立的。本研究认为这两　者是有着紧密的相关性，因此，在软件生命周期模　型的每一个阶段都定义了风险模板，并将风险模板　作为软件项目风险管理的识别工具。这将大大有利　于在软件生命周期模型的不同阶段，加强对于风险　的识别和风险的控制作用。　３．２．２基于风险管理的软件生命周期模型的特点　在基于风险管理的软件生命周期模型中，对于　风险的研究是该模型的一个重要研究内容。从整个　模型架构体系的框架中，将风险管理融入到了软件　生命周期的每一个阶段。在该模型中，基于风险的　管理主要有以下几个考虑：　１）在软件项目开发核心风险的基础上引入风　险模板：使风险模板不但成为一种快速的风险识别　工具，同时也能加强对风险的预测和动态管理机　制，保证在软件项目开发的过程中不断对可能发生　的风险进行管理，并能不断总结经验，完善原有的　风险模板，提出适应软件项目长期发展的新的模板　内容。　２）加强过程风险的归纳和检验；本课题研究一　方面注重软件生命周期的每一个阶段的风险问题；　另一方面将与软件生命周期阶段无关而与整个软　件开发执行的过程有关的风险作为基于风险管理　的软件生命周期模型的一个重要内容来加以研究。　同时，将过程风险归纳为ＣＯＳＴ分析法，即过程风　险重点在于研究成本风险（ｃｏｓｔ　ｒｉｓｋ）、组织风险　（ｏｒｇａｎｉｚａｔｉｏｎ　ｒｉｓｋ）、系统风险（ｓｙｓｔｅｍ　ｒｉｓｋ）和计　划风险（ｔｉｍｅ　ｓｃｈｅｄｕｌｅ　ｉｒｓｋ）。　３）风险模板与过程风险的关联分析：在基于风　险管理的软件生命周期模型的研究中，将核心风险　与过程风险进行了相关性分析。这一分析不但揭示　了核心风险与过程风险的相关性，更重要的是发现　了风险逆向变化的特性。　３．２．３核心风险与过程风险的关联分析　在图１中，基于风险管理的软件生命周期模型　体系结构图中，模型的右面是一组带数字的小圆　圈，该数字由２位数组成，前一位数字代表软件生　命周期的第几个阶段，后一位数字代表在这一阶段　核心风险中的风险因素的编号。在纵向的项目风险　中的成本风险将上面的几个小圆联系在了一起，这　就表明在过程风险中的成本风险是与软件生命周　期模型中的核心风险有关联的，其关联关系可用图　２表示。　图２是把过程风险中与成本风险有关的一列核　心风险列出，在图２中点划线以上是核心风险，点　划线以下是过程风险。核心风险中实线箭头表示正　常的风险发生顺序，而虚线部分则暗示了后续的风　险对前面的风险关联和影响。这一事实已经在实践　中得到了证实，称之为“风险的前后关联”。　图２核心风险与过程风险的关联图　风险的前后关联表明：在软件生命周期模型　中，前一阶段风险排除或消失后，后面阶段出现新　的风险可能会触发出前面已经发生过的风险，例如：　编号为①的关联。是当软件系统正式投入使用　以后，对于现场的支持中可能发生的风险，如支持　内容、响应时间、支持人员以及与用户配合方面出　现的问题会反作用于利益风险；而利益风险就是项　目的总支出、总收入和企业效益有关的风险；即当　支持风险发生时，公司的利益风险就会发生增加的　可能性。　编号为②的关联。同样，当功能风险发生在　项目验收阶段以后，如用户对于软件系统的功能、　界面显示的内容以及可操作性发生了变化，或对　软件开发商的解决方案不满意时，则在功能风险　发生的同时就可能会引起前面计划风险的增加，　维普资讯 http://www.cqvip.com

第５期　钱鸿生等：基于风险管理的软件生命周期模型研究　即计划执行、计划变更和计划管理的风险会随之　增加。　编号为③的关联。质量风险是指质量体系、质　量控制而引起的风险。一旦发生质量风险就需要投　入人力进行质量评审和质量改进工作，这将会使整　个计划发生变更，为了达到一定的质量目标就必需　有充足的时间予以保证。　编号为④的关联。当系统已经进入到维护使用　阶段后，由于维护人员的变更和培训难度的增加，　并在维护中发现一些系统的缺陷性问题，就会造成　维护风险；同时，由于需要重新投入研发人员进行　故障排除与系统软件的改进，因此，整个研发风险　将增加，原来预留的售后服务人员不够用，只能重　新投入研发力量，从而造成其他研发软件项目的人　员紧缺，形成研发风险。　编号为⑤的关联。在项目验收阶段，发现大量　功能性问题，造成项目验收无法完成，即引起了功　能风险。该风险将导致研发人员必须配合现场验收　在原来的软件系统上进行大量的补丁修改，补丁修　改增加以后会引起软件系统的不稳定，即由于补丁　增加会引起系统稳定性的问题。　通过以上一些风险的前后关联分析，可以看　出：由于这种风险前后的关联性特性，促使我们不　得不更加重视软件风险管理的监控和管理工作，自　始自终加强软件开发项目的风险管理，以确保项目　的顺利实施。　４风险积累与风险转移问题的研究　在应用基于风险管理的软件生命周期模型的　过程中可发现：不同软件生命周期阶段的风险有一　个积累和转移的过程。所谓的风险转移是指某一种　风险可能在某一阶段出现，但其同样的表现会在另　一阶段重复发生，这种现象在在用户需求风险或系　统架构的风险方面表现尤甚。风险的积累与转移有　一定内在的联系【２　２４】。　作者认为风险的积累与风险的转移是在软件开发　项目中，风险的特殊的表现形式。风险的积累是指软　件开发中的风险有时候会随着对外界的情况发生变化　后逐步积累，达到一定程度后对项目开发造成一定影　响的现象。风险的转移则是一种风险自动或在被人工　干预后暂时消失后，在另外的地方再次发生的现象。　需求风险的积累和转移在整个软件生命周期　中的分布如图３所示。　图３风险积累与风险转移图　从图３中可以看出，用户需求风险在分析阶段　会出现一个峰值，该峰值表明在用户需求阶段的主　要风险是用户需求的确认。在项目确认阶段，用户　需求从零开始，一旦项目确认以后即进入需求分　析，该阶段用户正式提出软件系统的开发要求，但　是双方有一个较长时间的谈判和妥协的过程，这一　过程逐步把双方的分歧点缩小，趋向于形成一个系　统软件功能的轮廓。从理论上讲，该阶段完成以后　用户需求就应该确认完毕，需求风险就回逐步降　低，但是实际情况往往是用户在双方确定的用户确　认书上完成签字，也不能说明用户需求已经全部确　定。需求风险在较长一段时间内仍然会存在。　在图３中，看到实线部分是理想的用户需求风　险影响的分布图。在需求分析阶段完成以后并不是　所有的需求风险都解决了，而是必须保持与用户的　沟通渠道，逐渐地缩小与用户需求之间的差距。当　项目进入验收阶段或维护使用阶段以后，用户需求　已经转化成实际的软件应用系统，用户需求发生的　概率为零，风险的影响程度也降低为零。　但是实证研究表明：用户需求会随着项目开发　进程的发展出现风险的转移。即用户需求风险不是　在需求确认阶段结束以后马上降低为零，而是有一　个在其他阶段继续发生的可能性。甚至会出现在该　图中的验收测试阶段突然又发生一个较高的需求风　险的影响的现象。该需求风险转移的虚线部分即可　以被视作是前几个阶段需求风险的积累，又可以被　视为需求风险在经历了一段时间以后又转移到了验　收测试阶段。这就从另一个侧面较好地解释了风险　积累和风险转移的关系，即风险转移的基础是该风　险还有残留存在，积累到了一定程度以后会有一个　总的爆发，这就形成了表面上风险转移这个事实。　风险转移的事实告诉我们：在整个软件的开发过　程中，我们用风险模板只能确定该风险在某一阶段可　维普资讯 http://www.cqvip.com

－１４０－　通信学报　第２７卷　能会发生的概率很大。这对于我们集中精力处理这一　阶段可能发生的风险是有积极意义的。但是，这并不　是说过了该阶段以后该风险就不存在了，或者在以后　阶段再也不会发生同样的风险了，实践证明只要有风　险残留的存在，风险的危害就在积累。等累积达到一　定程度以后，如果项目管理人员轻视了该风险的管　理，在未来的某一个时刻该风险就会再次光顾，并造　成一定的影响。这就要求我们的风险管理应该是可连　续的，对于根据风险模板识别到的风险，在项目还未　终止前始终不能放松对其的监控和管理。　５结束语　本文提出了基于风险管理的软件生命周期模型　的框架体系，以及风险的关联性研究的问题，结合大　型软件项目风险管理实证案例的研究，阐述了核心风　险模板和过程风险的概念，对于提高我国大型软件系　统开发和风险管理的水平具有一定的积极意义。　参考文献：　【１］ＬＩＥＮＴＺ　Ｂ，ＳＷＡＮＳＯＮ　Ｅ．Ｓｏｆｔｗａｒｅ　Ｍａｉｎｔｅｎａｎｃｅ　Ｍａｎａｇｅｍｅｎｔ［Ｍ］．　Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ．ＵＳＡ，１９８０．　［２】ＴＲＡＣＺ　ｗ　Ｓｏｆｔｗａｒｅ　Ｒｅｕｓｅ：Ｅｍｅｒｇｉｎｇ　Ｔｅｃｈｎｏｌｏｇｙ［Ｍ］．ＩＥＥＥ　Ｃｏｍ－　ｐｕｍｒ　Ｓｏｃｉｅｔｙ　Ｐｒｅｓｓ，１９８８．　ＮＡＵＲ　ＲＡＮＤＡＬＬ　Ｂ．Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ［Ｍ］．Ａ　Ｒｅｐｏｒｔ　ｏｎ　ａ　Ｃｎｆｅｒｅｎｃｅ　Ｓｐｏｎｓｏｒｅｄ　ｂｙ　ｔｈｅ　ＮＡＴＯ　Ｓｃｉｅｎｃｅ　Ｃｏｍｍｉｔｔｅｅ，ＮＡＴＯ，１９６９．　ＩＥＥＥ　Ｓｔａｎｄａｒｄｓ　Ｃｏｌｌｅｃｔｉｏｎ：Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ［Ｓ］．ＩＥＥＥ　Ｓｔａｎｄａｒｄ　６１０．１２－１９９０．１９９３．　ＰＡＵＬＫ　Ｍ．Ｃａｐａｂｉｌｉｔｙ　Ｍａｔｕｒｉｔｙ　Ｍｏｄｅｌ　ｆｏｒ　Ｓｏｆｔｗａｒｅ［Ｄ］．Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｉｎｓｉｔｔｕｔｅ，Ｃａｒｎｅｇｉｅ　Ｍｅｌｌｏｎ　Ｕｎｉｖｅｒｓｉｔｙ，Ｐｉｔｔｓｂｕｒｇｈ　ＰＡ，１９９３．　ＡＲＣＣＯＯＮ　Ｌ．Ｔｈｅ　Ｃｈａｏｓ　ｍｏｄｅｌ　ａｎｄ　ｔｈｅ　ｃｈａｏｓ　ｌｉｆｅ　ｃｙｃｌｅ［Ｊ］．ＡＣＭ　Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｎｏｔｅｓ，１９９５，２０（１）：５５，５６．　ＲＯＹＣＥ　Ｗ　Ｍａｎａｇｉｎｇ　ｈｔｅ　ｄｅｖｅｌｏｐｍｅｎｔ　ｏｆ　ｌｒａｇｅ　ｓｏｆｔｗａｒｅ　ｓｙｓｔｅｍｓ：ｓｏｎ．　ｃｅｐｔｓ　ｎａｄ　ｔｃｅｈｎｉｑｕｅｓ［Ａ】．Ｐｒｏｃ　ＷＥＳＣＯＮ，Ｌｏｓ　Ａｎｇｅｌｅｓ［Ｃ］．ＵＳＡ，１９７０．　ＨＡＮＮＡ　Ｍ．Ｆａｒｅｗｅｌｌ　ｔｏ　ｗａｔｅｒｆａｌｌｓ［ＪＪ．Ｓｏｆｔｗａｒｅ　Ｍａｇａｚｉｎｅ，１９９５，１５（５）：３８－４６．　ＰＥＲＲＺ　Ｂ，ＰＲＯＴＯＴＹＰＩＮＧ　Ｌ．Ａ　ｐｒｏｃｅｓｓ　ｍｏｎｉｔｏｒｉｎｇ　ｅｘｐｅｒｉｍｅｎｔ［Ｊ］．　ＩＥＥＥ　Ｔｒａｎｓ　Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ，１９９４，２０（１０）：７７４－７８４．　ＢＲＯＯＫＳ　Ｅ　Ｔｈｅ　Ｍｙｔｈｉｃａｌ　Ｍａｎ－Ｍｏｎｔｈ［Ｍ］．Ａｄｄｉｓｏｎ．Ｗｅｓｌｅｙ，ＵＳＡ，　１９７５．　ＭＡＲＴＩＮ　Ｊ．Ｒａｐｉｄ　Ａｐｐｌｉｃａｔｉｏｎ　Ｄｅｖｅｌｏｐｍｅｎｔ［Ｍ］．ＵＳＡ：Ｐｒｅｎｔｉｃｅ－Ｈａｌｌ，　ｌ９９１．　ＮＩＥＲＳＴＲＡＳ　Ｚ．Ｃｏｍｐｏｎｅｎｔ－ｏｒｉｅｎｔｅｄ　ｓｏｆｔｗａｒｅ　ｄｅｖｅｌｏｐｍｅｎｔ［Ｊ］．　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ｏｆｔｈｅＡＣＭ。１９９２，３５（９）：１６０—１６５．　ＤＥＩＬＬＹ　Ｊ．Ｄｏｅｓ　ＲＡＤ　ｌｉｖｅ　ｕｐ　ｔｏ　ｔｈｅ　ｈｙｐｅ［Ｊ］．Ｔｈｅ　ＩＥＥＥ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｓｏｆｔｗａｒｅ，１９９５，１２（５）：２４．２６．　［１４】ＧＩＬＢ　Ｐｒｉｎｃｉｐｌｅｓ　ｏｆ　Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｍａｎａｇｅｍｅｎｔ［Ｍ］．ＵＳＡ：　Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ，１９８８．　［１５】ＳＡＨＡＹ　Ｂ，ＫＲＩＳＨＮＡ　Ｓ．Ｗｏｒｋ　ｐｒａｃｔｉｃｅｓ　ａｎｄ　ｌｏｃａｌ　ｉｍｐｒｏｖｉｓａｔｉｏｎｓ　ｗｉｔｈｉｎ　ｇｌｏｂａｌ　ｓｏｆｔｗａｒｅ　ｔｅａｍｓ：ａ　ｃａｓｅ　ｏｆ　ａ　ＵＫ　ｓｕｂｓｉｄｉｒａｙ　ｉｎ　Ｉｎｄｉａ［Ａ］．　Ｐｒｏｃ　ＩＦＩＰ　ＷＧ９．４　Ｉｎｆｏｒｍａｔｉｏｎ　Ｆｌｏｗｓ。Ｌｏｃａｌ　Ｉｍｐｒｏｖｉｓａｔｉｏｎｓ　ａｎｄ　Ｗｏｒｋ　Ｐｒａｃｔｉｃｅｓ’Ｃｏｎｆ，ＩＦＩＰ　ＷＧ９．４［Ｃ】．Ｃａｐｅ　Ｔｏｗｎ，Ｓｏｕｔｈ　Ａｆｒｉｃａ，　２０００．　［１６】ＡＮＤＲＥＳ　Ｈ．ＺＭＵＤ　Ｒ．Ａ　ｃｏｎｔｉｎｇｅｎｃｙ　ａｐｐｒｏａｃｈ　ｔＯ　ｓｏｆｔｗａｒｅ　ｐｒｏｊｅｃｔ　ｃｏｏｒｄｉｎａｔｉｏｎ［Ｊ］．Ｊｏｕｒｎａｌ　ｏｆ　Ｍａｎａｇｅｍｅｎｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍｓ，２００２，　ｌ８（３）：４１－７２．　［１７】ＣＡＲＭＥＬＥ，ＡＧＡＲＷＡＬＲＴａｃｔｉｃａｌ　ａｐｐｒｏａｃｈｅｓｆｏｒａｌｌｅｖｉａｔｉｎｇｄｉｓｔａｎｃｅｉｎ　ｇｌｏｂａｌ　ｓｏｆｔｗａｒｅ　ｄｅｖｅｌｏｐｍｅｎｔ［Ｊ］．ＩＥＥＥ　Ｓｏｆｔｗａｒｅ，２００１，１８（２）：２２－２９．　【ｌ８］ＳＩＮＤＲＥ　Ｇ，ＯＰＤＡＨＬ　Ａ．Ｅｌｉｃｉｔｉｎｇ　ｓｅｃｕｒｉｔｙ　ｒｅｑｕｉｒｅｍｅｎｔｓ　ｂｙ　ｍｉｓｕｓｅ　ｃａｓｅｓ［Ａ］．Ｉｎｔ’ｌ　Ｃｏｎｆ　ｏｎ　Ｔｅｃｈｎｏｌｏｇｙ　ｏｆ　Ｏｂｊｅｃｔ－Ｏｒｉｅｎｔｅｄ　Ｌａｎｇｕａｇｅｓ　ａｎｄ　Ｓｙｓｔｅｍｓ　ＴＯＯＬＳ－Ｐａｃｉｆｉｃ　２０００［Ｃ１．Ｓｙｄｎｅｙ．Ａｕｓｔｒａｌｉａ．２０００．２Ｏ－２３．　【１９】ＫＥＬＬＮＥＲ　Ｈ．Ｓｏｆｔｗａｒｅ　ｐｒｏｃｅｓｓ　ｍｏｄｄｉｎｇ：ｐｒｉｎｃｉｐｌｅｓ　ｏｆ　ｅｎｔｉｔｙ　ｐｒｏｃｅｓｓ　ｍｏｄｅｌｓ［Ａ］．Ｐｒｏｃ　ｌ　ｌｔｈ　Ｉｎｔｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ［Ｃ］．　Ｋａｉｓｅｒｓｌａｕｔｅｒｎ，Ｇｅｒｍａｎｙ，ｌ９９９．１６・１９．　［２０】ＩＥＥＥ　Ｓｔｄ　１５４０－２００１：ＩＥＥＥ　Ｓｔａｎｄａｒｄ　ｆｏｒ　Ｓｏｆｔｗａｒｅ　Ｌｉｏｆ　Ｃｙｃｌｅ　Ｐｒｃｏ－　ｅｓｓｅｓ－Ｒｉｓｋ　Ｍａｎａｇｅｍｅｎｔ［Ｓ］．ＩＥＥＥ　Ｉｎｃ，Ｎｅｗ　Ｙｏｒｋ，２００１．　［２１】ＩＳＯ／ＩＥＣ　ｌ５９３９：Ｉｎｆｏｒｍａｎｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ　Ｓｏｆｔｗａｒｅ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｐｒｏｃｅｓｓ［Ｓ］．ＩＳＯ／ＩＥＣ，２００１．　［２２】ＮＯＲＭＡＮ　Ｆ．Ｓｃｈｎｅｉｄｅｗｉｎｄ．Ｓｏｆｔｗａｒｅ　Ａｃｑｕｉｓｉｉｔｏｎ　Ｌｉｆｅ　Ｃｙｃｌｅ　Ｍｅａｓｕｒｅ　Ｐｌａｎ　ｂａｓｅｄ　ｏｎ　ｔｈｅ　Ｒｅｖｉｓｅｄ［Ｒ］．ＩＥＥＥ　Ｐ１６３３ｋＡＩＡＡ　Ｉ　ｌ３Ａ．２ｏｏ６．　【２３１　ＬＡＩＮＧ　Ｖ．Ｐｒｉｎｃｉｐａｌ　Ｃｏｍｐｏｎｅｎｔｓ　ｏｆ　Ｏｒｔｈｏｇｏｎａｌ　Ｏｂｊｅｃｔ－Ｏｒｉｅｎｔｅｄ　Ｍｅｔｒｉｃｓ［Ｒ］．Ｗｈｉｔｅ　Ｐａｐｅｒ。Ａｎａｌｙｚｉｎｇ　Ｒｅｓｕｌｔｓ　ｏｆＮＡＳＡ，２００６．　［２４】ＳｃＨＮＥＩＤＥＷＩＮＤ　Ｎ．Ｒｅｑｕｉｅｒｍｅｎｔ　ｉｒｓｋ　ｒｅｌｉａｂｉｌｉｔｙ［Ａ］．Ｓｕｐｐｌｅｍｅｎｔａｒｙ　ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　１３ｔｈ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｓｏ，ｗａｒｅ　Ｒｅｌｉ－　ａｂｉｌｉｔｙ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ａｎｎａｐｏｌｉｓ［Ｃ］．Ｍａｒｙｌａｎｄ．２ｏｏ２．１２－ｌ５．　作者简介：　钱鸿生（１９５５．），男，上海人，同济　大学博士生，国信朗讯科技网络技术有限　公司副总经理、高级工程师，主要研究方　向为通信７号信令系统、现代通信网络管　理技术的研究、现代数据库系统及应用研　究、软件项目管理技术。　黄立平（１９４３．），男，江西石城人。　同济大学教授、博士生导师，主要研究方　向为现代信息技术与信息系统应用研究、　客户智能的理论与方法研究、现代数据库　系统及应用研究、数据挖掘技术研究、物　流管理及信息系统、电子商务系统与应用　研究。