软件项目需求优先级评价体系研究.doc

软件项目需求优先级评价体系研究学生姓名： 霍伟华学 号： 060112200373学 院： 管理科学与工程学院专 业： 项目管理指导教师： 宿洁论文成绩： 内 容 摘 要科技，如果在过去只是一个遥远的书本上的概念，那么在当今时代，已经贯穿于人们日常生活的衣食住行。越来越便捷的网络，层出不穷的手机应用，在科技生活化的今天，也使得软件技术这一产业得到前所未有的蓬勃发展。众多软件从业人员开始关注如何更好的将项目管理的理念与实际工作相结合。但是，自20世纪60年代美国软件危机之后，软件项目管理中的问题一直没有得到根本解决。而在Standish集团的多项研究中也表明，需求工程方面的问题是项目失败最重要的原因。被广泛引用的1995年Standish集团年度报告Stand Group 1995中提到，在所分析的项目中仅有52.7%是完成的，而且这些项目的预算超支达到了189%。相关研究报告同时分析了造成这些问题的原因。明显与不充分或拙劣的需求工程相关的问题占到了48%。因此，研究软件项目管理问题，需求工程成为不得不考虑的重要因素。在以项目化管理的企业中，由于资源的限制，不能将所有的项目需求同时实现，对项目需求的优先级排序，成为软件开发工作中的重要部分。在实际的工作中，由于时间、人员的限制，通常由产品经理根据经验进行排期，主观性较强。本文以解决需求管理中需求优先级确定问题为核心内容，结合项目管理相关理论，以实用性为目标，采取定性分析与定量分析相结合的项目管理评价技术，以作者所在项目真实案例为研究,进一步阐述软件需求优先级确定方法的应用。关键词:需求管理 优先级 评价体系ABSTRACT翻译部分初稿审核后补充。KEYWORDS: 目 录软件项目需求优先级评价体系研究1一、绪论41.问题提出52.本文的理论基础63.本文结构及主要工作6二、软件项目管理相关理论概述71.项目72.项目管理83.需求管理104.项目时间管理125.项目组织管理126.项目成本管理147.项目风险管理15三、软件项目前期成本估算171.运用WBS工作法估算工作范围172.工作量的估算18四、软件项目需求优先级影响因素分析201.软件项目风险估算212.软件项目进度估算213.软件项目收益分析224.需求紧急性评价表22五、软件需求优先级评价方法应用231.需求评价体系设计原则232.团队架构243.需求优先级评价体系流程253.1需求干系人评价253.2需求紧急度评价253.3需求成本评价263.4需求周期评价273.5需求风险评价273.6需求时间评价27六、总结28软件开发项目需求优先级评价方法一、 绪论问题的背景及意义目前，中国的软件行业正处于高速发展的时期，日前中国电子商务研究中心发布了2014年上半年中国电子商务市场数据监测报告,截止到2014年6月，全国电子商务交易额达5.85万亿元，同比增长34.5%。其中，B2B交易额达4.5万亿元，同比增长32.4%。网络零售市场交易规模达1.08万亿元，同比增长43.9%。随着信息技术的高速发展，软件产品的规模也越来越庞大，随着项目管理技术在中国日益重视，各软件企业都在积极将软件项目管理引开发活动中，对开发实行专业化的管理。从概念上来看，软件项目管理是为了使软件项目能够按照预定的时间、成本、质量顺利完成，而对人力资源、项目成本、进度、质量、风险等进行分析与管理的活动。软件开发是一项复杂的系统工程，受到各个方面的因素影响。实际工作中，面临道的问题也是方方面面的，而其中一半以上问题都是因为在最初的需求分析工作中的失误引起的。软件需求工作是一个软件项目的开端，也是项目建设的基石。在以往失败的项目中，80%是由需求分析不明确而造成的。美国Standing Group公司于1994年的研究报告表指出了三种最经常使项目“遇到困难的因素。（1） 缺乏用户介入：占所有项目的13%。（2） 不完整的需求和规格说明：占所有项目的12%。（3） 不断改变的需求和规格说明：占所有项目的12%同时，项目最主要的“成功因素”如下所示：（1） 用户介入：占所有成功项目的16%。（2） 高层管理的支持：占所有成功项目的14%（3） 需求陈述清晰：占所有成功项目的12%。从以上正反两方面不难得出结论，需求问题是人们在软件开发过程中面临的主要问题之一。因此，一个项目成功的关键因素之一就是对需求分析的把握程度，这需要能够合理划分项目的需求优先级顺序，使得各个项目的开发资源能够相互协调，高效利用资源完成项目任务。同时，项目需求优先级的及时有效划分还可以解决项目资源不足的情况下，集中有限资源开发关键项目。因此，软件项目需求优先级的确定问题研究有着极大的实用价值。需求分析是软件项目过程的最初阶段，以软件需求规格说明书作为客户和软件开发者双方对该软件的约定，是项目验收及整个软件开发工作的基础。研究表明在项目的软件维护阶段发现错误地成本与需求分析阶段发现错误的成本比例达到200:1。因此，针对在需求分析阶段形成的软件需求规格说明书进行质量评价，寻找合理有效的评价方法，构件评价系统，对及时评审软件需求规格说明书中的问题，降低项目成本提高产品质量具有重要意义。1. 问题提出建议改为“”根据Standish Group,CHAOS,2000统计报告，世界上仅有26%的软件项目开发成功，也就是说有高达74%的软件项目都是失败的。而国内的中国计算机报曾经报道过，在为企业和政府实施的应用软件成功率低于30%。在需求工程中，当客户期望很高、开发时间短，再加上资金等资源限制，就必须尽早确定出所交付产品应具有的最重要的功能，分清楚提供辅助或增强等次要功能的需求，分步实施。这个分析过程就是软件项目需求优先级确定过程。只有对于用户及开发人员提出的需求或变更建议及项目进行需求优先级分析，才能使有限资源达到较优的配置，防止项目无边界扩大，拒绝出现项目管理者再开打，节约预算或调度中丧失控制自由度的局面。当前，我们见到的软件项目需求优先级确定的方法有很多，但是并没有比较规范统一的方法，IEEE关于软件需求的推荐标准中将需求的需求优先级分为基本的（essential）、条件的（conditional）、可选的（optional）三类。这一设定标准比较模糊，是对需求集的粗粒度划分，对于项目团队来说，主观因素较强。对于项目团队资源有限，而需求源源不断的出现，就要借助工程化的教学工具，快速对需求进行优先级的划分，主要从需求的价值、风险、费用三方面对需求进行度量，做出合理的需求优先级决策。本文主要是解决在经过一定的需求分析之后，在需求管理阶段，考虑项目成本、收益等多个因素来量化解决各个软件项目的开发顺序。本文的以下内容都是在软件项目周期的需求管理阶段进行的，在文章最后一章结合现实开发案例，对软件项目需求优先级确定方法进行了实证研究。2. 2.本文的主要工作3. 本文的理论基础本文主要是解决在经过一定的需求分析之后，在需求管理阶段，考虑项目成本、收益等多个因素来量化解决各个软件项目的开发顺序。本文的以下内容都是在软件项目周期的需求管理阶段进行的，在文章最后一章结合现实开发案例，对软件项目需求优先级确定方法进行了实证研究。本文会涉及到项目管理学科多方面理论，其中主要以软件项目管理理论和决策方法与理论等为主。而在项目管理方面，本文主要介绍了需求管理、时间管理、风险管理、成本管理、进度控制等理论。项目管理理论主要是从国外发展起来的，早在七十年代中后期就已经有不少的文章开始探讨项目管理。而这段时期的特点只是偏向于探讨软件项目管理某个环节中的技术问题，例如McMall和Cavano在1975年定义了一组质量因素，这其实是走向软件质量度量开发的第一步。4. 本文论文的基本结构及主要工作本文内容主要分为三大部分，第一部分关于本文的写作背景、意义及相关理论的概述，主要在本文的第一章和第二章；第二部分简单分析了软件项目前期成本、风险、进度、相关性、效益的详细估算方法，为本文的下一部分软件项目需求优先级奠定基础；内容主要为第三章；第三部分介绍需求优先级评价影响因素，内容主要是第四章；最后，以实际项目为案例，对需求优先级应用进行分析。本文详细结构如下：第一章：论文写作背景介绍、提出所研究的课题、介绍本文的理论基础及主要内容。第二章：论文相关项目管理理论介绍，包括：项目管理基本理论、项目需求管理、项目组织管理、项目成本管理、项目进度控制、项目风险管理等内容。第三章：软件项目需求优先级确定相关影响因素分析，包括项目风险、进度、收益、项目间相关性的估算。第四章：需求优先级评价影响因素。第五章：案例引用分析，制定软件需求优先级评价体系。第六章：结论与展望。4. 论文的主要创新点本文的主要工作及创新点：1 提出软件项目需求优先级确定的意义及需求工程的含义；2 比较目前通用的需求优先级评价方法，找出一种适用于实际项目的较为方便的评价体系。3 软件项目需求优先级的确定在软件开发需求管理实践中占有重要地位，特别是在资源有限的情况下。而这方面的研究资料较少，至今没有对此进行的系统研究，而在现实的项目中，往往项目时间有限，很难使用复杂的估算方法进行估算。如何用科学而实用的方式进行软件需求优先级的评定，是本文想要探讨的问题。本文借鉴项目管理理论，结合相关资料，进行定性与定量相结合的估算方法，从实用性的角度出发，确定软件项目需求优先级。二、 软件项目需求管理相关理论概述此章只需要介绍项目需求管理的理论就行，不需要对项目管理就行介绍，建议形式：1. 项目需求管理2. 软件项目需求管理的国内研究现状（这一部分要有几篇文献）3. 其他与需求管理相关的理论（可以包括风险、进度、收益等）1.2. 项目中文中项目的文字释义，“项”和“目”是指人的“颈上”部分；而项目新华字典中的解释是“事物分成的门类”，拼音xiang mu。项目是指一系列独特的、复杂的并相互联系的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。事实上，在古代的中国就已经有了以项目为模式的工作，比如著名的万里长城、比如震撼世界的秦始皇兵马俑。这些工作都具有现代项目管理中项目的显著特征：一次性。那么，在一次性之外，项目区别于一般的劳作所具有的特征如下：1.1 目的性任何项目都是由特定的人或者组织提出，为了实现一个特定的目标。项目的目的性使项目涉及两个方面的目标或指标，一个是有关项目产出物的目标；另一个是有关项目工作的目标。前者通过组织的既定目标分解得到，后一个是根据项目产出物要求得到。1.2 独特性独特性是指项目目标、项目产出物、项目工作等与其他项目或项目产品与服务相比独特的地方，每个项目都有其特有的的地方，可以是不同的设计、不同的实现方法、不同的客户。1.3 制约性制约性是指每个项目都会或多或少的受到项目所处环境和项目资源的限制。通常制约项目的因素可能是人力、时间、成本、技术实现性、法律规定等等。1.4 风险性风险是无处不在的。作为项目来说，由于项目通常都是独特的，每个项目都有不同的环境因素、资源因素，这样就很可能出现非预期的损失或收益的可能性。项目的风险性是项目不同于日常运营活动的最重要特性之一，也是项目管理不同于日常运营管理的关键所在。美国的项目管理协会（project management institute,PMI）认为，项目是一种被承办的旨在创造某种独特产品或服务的临时性努力。一般来说项目具有明确的目标和独特的性质：每个项目都是唯一的、不可重复的，具有不确定性、资源成本的约束性等特点。3. 项目管理项目管理（project management）是第二次世界大战后期发展起来的重大新管理技术之一。20世纪60年代，项目管理的应用范围也还只是局限于建筑、国防和航天等少数领域，但因为项目管理在美国的阿波罗登月项目中取得巨大成功，由此风靡全球。项目管理发展史研究专家以20世纪80年代为界把项目管理划分为两个阶段。项目管理是美国最早的曼哈顿计划开始的名称，后由华罗庚教授50年代引进（由于历项目管理相关书籍史原因叫统筹法和优选法），台湾省叫项目专案。项目管理是“管理科学与工程”学科的一个分支，是介于自然科学和社会科学之间的一门边缘学科。项目管理定义：项目管理是基于被接受的管理原则的一套技术方法，这些技术或方法用于计划、评估、控制工作活动，以按时、按预算、依据规范达到理想的最终效果。美国项目管理知识体系指南（Project Management Body of Knowledge），将项目管理分为九个知识领域，即：项目的时间管理、项目成本管理、项目时间管理、项目质量管理、项目风险管理、项目范围管理、人力资源管理、沟通管理、采购管理、综合管理。可以看出来，项目管理从时间上可以划分为四个阶段：概念、开发、实施、结束，从运作上分可以划分为计划、组织、控制三个基本的过程，从层次上可以分为战术、战略、综合三个方面，从内容上又分为质量管理、成本管理等九个方面。软件项目管理概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义“在项目活动中运用一系列的指标、技能、工具和技术，以满足或超过相关利益者对项目的要求”，从中可以得出软件项目管理的一种定义：在软件项目管理活动中运用一系列指标、技能、工具和技术，以满足软件需求方的具体要求。3.1. 项目管理的相关理论体系 IOS 9000质量体系为了适应国际经济合作与贸易的往来需要，总部位于日内瓦的国际标准化组织（IOS）在1987年发不了ISO 9000质量管理和质量保证系列标准。ISO 9000系列标准，是在总结工业发达国家质量管理经验的基础上，为发展国际贸易的需要，于1987年3月正式发布的一整套国际质量标准系列，具有较强的指导性和实用性。IOS 9000系列共分5个组成部分，即ISO 9000、ISO 9001、ISO 9002、ISO 9003、ISO 9004。ISO 9000是该系列标准的选用指南，并为ISO 9001、ISO 9002、ISO 9003、ISO 9004的应用建立的准则。它主要阐述了几个质量术语基本概念之间的关系、质量体系环境的特点、质量体系国际标准的分类，以及在质量管理与合同环境中质量体系国际标准的应用。ISO 9001是开发、设计、生产、安装和服务的质量保证模式标准，它包括了企业全部活动总的标准。ISO 9002是生产和安装的质量保证模式标准。ISO 9003是最终检验和试验的质量保证模式标准。ISO 9004是质量管理和质量体系要素的指南，是非合同环境中用于指导企业管理的标准。对于企业内部质量管理来说，ISO 9004是ISO 9000系列中最适用的一个标准。 SW-CMM软件过程改进SW-CMM（Software Capability Maturity Model）是美国软件工程研究所SEI（Software Engineering Institution）从1986年开始研究并完成的，它侧重于对软件开发过程和开发方法论的考察。SW-CMM包括五级：等级1-初始级。软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人的努力。等级2-可重复级。建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复最早先类似应用项目取得的成功。等级3-已定义级。已将软件管理的工程活动方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。等级4-已管理级。收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制。等级5-优化级。过程量化反馈和先进思想、新技术促使过程不断改进。 PMI的项目管理知识体系成立于1969年的美国项目管理协会（PMI）（Project Management Institute）是全球最大的由研究人员、学者、咨询和管理人员组成的项目管理专业组织。由其编写了项目管理知识体系（PMBOK）在项目管理领域具有重要的理论意义。在项目管理知识体系（PMBOK）中，把项目管理划分为9个只是领域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和整体管理。该体系中各体系的相关知识在后文进行阐述。4. 需求管理Frederick Brooks在他1987年的经典文章“NO Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么，最困难的概念性工作就是编写出详细的需求，包括所有面向用户、面向机器和其他软件系统的接口。这项工作一旦做错，将会给系统带来极大的损害，并且后期对此的修复也会花费更多的资源并且极为困难。3.1. 我们可以根据不同的维度，对需求进行相应的分类： 根据KANO模型，即用户满意度的角度，需求分为基本需求：解决用户问题的产品或服务期望需求：用户期望获得的产品或服务兴奋需求：超出用户期望的产品或服务 按照用户能否表达的角度，需求分为：有声需求、无声需求有声需求：用户能准确或相对准确地表达出的自己的需求无声需求：用户习惯性的默认需求，和由于认知能力或表达能力局限表达不出来的需求 按照需求的层次，需求分为:业务需求、用户需求、功能需求（以及非功能需求）。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求。业务需求通常来自于项目的投资人、购买产品的客户、实际使用的客户、市场营销部门或产品策划部门。用户需求（user requirement）描述了较为明确用户目标，或者系统必须实现的任务。场景、流程描述都是表达用户需求的有效方式。功能需求（functional requirement）规定了开发人员必须实现的软件功能，实现功能需求是系统验收的重要依据。这些软件功能首先表现为系统特性。功能需求连同非功能需求，在软件需求规格说明（software requirements specification SRS）中说明。非功能性的需求（non-functional requirement）描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。如下图所示：3.2. 需求工程的含义及内容需求工程是随着计算机技术的发展而发展起来的，在计算机发展的初期，软件规模比较小，软件开发更多关注代码的质量，需求分析并不被重视。后来随着软件项目规模越来越大，项目管理概念的引入，需求分析成为第一个阶段。80年代中期，形成了软件工程的子领域需求工程（requirement engineering，RE）。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会（ISRE）,自1994年起每两年举办一次需求工程国际会议（ICRE）,在1996年Springer-Verlag发行了新的刊物Requirement Engineering.一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(Requirements Engineering Network of International Cooperation Research Group)，并开始开展工作。需求工程到目前并没有一个统一的标准概念。通常的一种解释是：需求工程是指应用已证实有效的技术、方法进行需求分析、确定客户需求，帮助分析人员理解问题并确定目标系统的所有外部特征的一门学科；它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档；并对用户不断变化的需求演进给予支持。需求工程是一个不断反复的需求定义、文档记录、需求演示的过程，并最终在验证的基础上冻结需求。80年代，Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。近来，Matthias Jarke和Klaus Pohl提出了更为简洁的三阶段周期的说法：获取、表示和验证。5. 项目时间管理项目时间管理是指在项目的实施过程中，为了确保项目能够在计划的时间内实现项目的目标，对项目活动的进度及日程安排所进行的管理，在项目的三要素中，时间是醒目考虑的首要目标，其次是质量，最后是成本。项目时间管理的主要过程如下图：项目时间管理活动定义活动排序活动历时估算进度计划编制进度控制活动定义，识别和定义为完成项目各种可交付物所必须进行的各项具体活动。活动排序，识别和定义各活动之间的逻辑关系或依赖关系，并形成现行的文档。活动持续时间估算，估算完成每项活动所需要的时间长度及所需资源。进度计划编制，在分析活动逻辑关系、活动持续时间和资源需求的基础上，编制项目进度计划。进度计划控制，检测项目进度计划的实际实施情况，控制和调整项目进度计划的偏差，以保证项目的按时完成。项目时间管理的过程虽然看起来界限分明，但是在实际项目应用中，他们通常是相互影响，相互制约的，甚至有时也无法区分和互相重叠。6. 项目组织管理项目人员的组成结构方式有很多种，它与项目的核算方式、组织的管理模式等方面相关。比较常见的有以下三种：6.1 主程序员制。主程序员制最早是在IBM公司得到应用，IBM公司采用的这种组织方式在开发纽约日报的信息系统时获得了成功。这种组织方式是把项目的工作分成若干个部分，每个部分分别由一个小组负责，每个小组由一个经验丰富，技术过硬的人担任组长，称为主程序员，他手下带几个助手（通常不超过4个）。主程序员一般负责分析设计，但也要参与和指导编码测试工作。采用这种组织方式需要两个前提，一个是项目工作的分工非常明确；另一个是主程序员的素质较高。如下图：主程序员人员组织结构6.2 功能项目组织工程项目组织结构是根据软件工程对项目生命周期阶段继续拧划分的，把一个活多个阶段的工作分配给一个功能小组。项目的完成是通过把工作产品从一种功能小组交付到另一功能小组。这种项目组织结构适合管理规范、软件过程比较成熟的公司。如下图：功能项目组织结构6.3 矩阵项目组织矩阵项目组织是前两种组织的组合。整个项目的工作是按照模块划分为不同的开发小组，但各个开发小组的分析设计可能是同一些人完成的。对一个软件项目来说，分析员和程序员所需人数是不同的，而系统分析师的使用成本较高，这种组织结构有利于充分利用人力资源，而且可以在一定程度上降低项目的工作产品从一个阶段进入下一个阶段存在的风险。如下图：矩阵型项目组织结构7. 项目成本管理软件项目成本是在整个软件项目生命周期中，所有开发成本和维护成本的综合。考虑开发成本时要考虑到直接人资资源成本、硬件和软件费用、其他直接间接费用。另外，对于系统维护期内可能发生的各种费用也应该在考虑项目成本时予以考虑。对于项目成本的估算方法主要有几种。6.1 SLOC法SLOC法是软件度量最重要的概念之一，指所有可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型生命、等价生命、输入/输出格式声明等，组织通常根据对历史项目的审计来核算组织的单行编码价值。6.2 经验类比法经验类比法适合评估一些与历史项目在应用领域、环境和复杂度相似的项目，通过新项目与历史项目数据的完整性和准确度。因此，用好经验类比法的前提条件之一是组织建立起较好的项目后评价分析机制，对历史项目的数据分析是可信赖的。6.3 WBS法在真正理解所要估算项目包含的工作量后，使用标准工作分解结构（work breakdown structure）来估算工作量，员工根据需求分析文档说明及WBS等资料估计自己需要完成任务的工作量。项目的全部工作量将是单个人估算的总和。6.4 Delphi法专家估算模型就是由多位专家进行成本估算。一种简单的方法是求个估算值的平均值，此方法简单，但可能因为个别的极端估算值的影响产生偏差。另一种方法是召开小组会，使各专家统一或至少同意某一个估算值，其优点避免了一些错误估算值的影响，到那时可能会产生因权威等因素产生的影响。为避免这些缺点，有Rand公司提出的Delphi技术，又称为专家估算模型，是由n位专家进行成本估算。每位专家根据系统规格说明书，反复讨论给出相关值，根据公式得出软件的成本估算值。6.5 COCOMOII模型cocomo是COnstructive COst MOdel(建设性成本估算模型)的缩写.最早是由Dr. Barry Boehm在1981年提出.是一种精确的、易于使用的成本估算方法.COCOMO模型中用到以下变量：DSI-源指令条数。不包括注释。1KDSI = 1000DSI。MM-开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年TDEV-开发进度。(以月计)8. 项目风险管理风险，是未来可能会发生，并且一旦发生会带来损失的事项。风险由三个要素构成：一个事件、该事件发生的可能性、该事件发生会产生不良后果。项目风险管理是对项目全生命周期中遭遇到的可能导致项目不良后果的风险进行管理，从而保证项目目标的实现。风险管理问题起源于第一次世界大战的德国。第一次世界大战后战败的德国发生了严重的通货膨胀，引起经济衰竭，也因此提出了风险管理在内的管理问题。风险的种类包括：自然风险、社会风险、经济风险、技术风险、管理风险。大型项目主要风险有管理风险、技术风险、人力风险、费用风险、进度风险、质量风险、时间风险、安全风险等。按照项目阶段可将项目风险进行阶段划分，如概念阶段的项目风险、开发阶段的项目风险、实施阶段的项目风险、收尾阶段的项目风险。有些风险贯穿于项目的全寿命周期，有些风险只属于某些阶段。项目风险管理的主体是项目管理人员，客体是项目中的不确定性。项目风险管理是由项目风险的预测、识别、分析评估和处置等环节组成，通过计划、组织和控制等过程来保障实施。在项目的早期阶段就开始进行风险管理效果最好，一般是越早越好软件项目风险管理生命周期一般分为风险识别、风险分析、风险规划、风险跟踪、风险控制五个阶段。6.1 风险识别风险识别就是采用系统化的方法分析影响软件项目成功的各种因素。一般的风险识别结果应包括风险的分类、来源、表现极其后果以及引发的相关项目管理要求。通常识别项目风险，需要了解项目的实施阶段，然后分析每个阶段可能发生的风险。6.2 风险分析风险分析是对已经识别出来的风险事件进行分析预测。主要因素包括风险事件、破坏因素、风险概率、风险事件发生的可能性。通过分析风险极其相互作用估算可能影响的范围，进行而成本、进度、性能方面对风险评价。确定哪些风险事件或来源可以规避，哪些是可以承受的可以忽略不考虑，以及哪些需要制定应对措施。6.3 风险规划风险规划是针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，风险规划市规划和设计如何进行风险管理活动的过程，包括界定项目组织及成员风险管理的行动方案，选择合适的风险管理方法，确定风险判断的依据。6.4 风险跟踪及驾驭对识别后的风险进行跟踪管理，观察是否还有会变化，以便及时作出对策。做到在真正的风险发生时，按照事先制定的计划执行管理措施，有效的控制风险事件对项目的影响。6.5 风险控制风险控制通常有几个策略：规避风险、减轻风险、接受风险、转移风险。三、 软件项目前期成本估算这一章整体作为第四章的一个方面，不需要单独成章对于大部分软件项目来说，最主要的成本就是直接人力成本，而其他费用相对较少。所以，估算人力成本就成为软件项目前期成本估算的主要任务，而人力成本的大小又是由工作量的大小来确定的。所以，本章讨论几种工作量评估的方法。1. 运用WBS工作法估算工作范围项目工作分解结构（WBS）就是要让项目组成员明白项目的工作量，它是项目组成员在项目实施期间要完成的工作或者要展开的活动的一种层次鲜明的项目描述。在项目工作分解的基础上，通过运用项目活动分解结构，将一个项目的工作分解成更小、更容易控制的许多部分和具体活动，以便对其进行更好的管理。对软件项目来说，项目的工作和活动包括以下几个方面：（1）指明各种软件分量如何安置在软件系统中。（2）反应软件产品的基本结构，由软件设计者确定。（3）分量由程序、模块、子系统等。软件项目的工作分解根据分解的形式可以分为纵向分解和横向分解两种。纵向分解方法是按照软件工程的阶段划分工作任务，然后在每个阶段中对工作进行细化，可以按照软件功能模块进行细化，也可以按照工作性质进行细化，还可以两者结合。下图是一个软件项目工作纵向分解的简单样例，其中编码和单元测试是按照功能模块进行细化的，而发布和安装则是按照工作性质进行细化的。项目纵向工作分解图横向分解方法是根据软件系统的功能模块组成来分解工作任务。首先确定软件系统的第一层大的模块，在大的模块下面可以分为一些小模块。在项目评估阶段，模块的划分不宜过细，最多三层。把模块划分以后再针对每个模块按照软件工程的方法开展一些其他工作。下图是卡片库存管理系统横向工作分解的示意图。项目横向工作分解图在项目活动界定中，所依据的项目工作分解结构的详细程度和分解层次取决于两个主要因素，其一是分配给每个项目成员的工作责任与其承接能力；其二是项目的管理与预算控制水平较高，工作分解结构可以详细一些、层次多一些。反之，就要粗略一些，层次少一些。对于软件项目，通常是根据项目所选择的软件生命周期类型，从软件工程的角度进行划分的。2. 工作量的估算（1）类比。使用一个和多个类似项目的实际工作量来对本项目进行估算。（2）经验方法。使用组织上的或个人（专家）方面的经验为指导，以组织内的大量项目作为基础，到处本项目的预算，如：德尔菲法。（3）参数模型。使用产品的一些性质如代码行数，做为模型的参数（或输入），预测该产品所需的工作量。这些模型是由许多组织根据多个项目的经验得出的，并经过使用的调整。在实践中，由于项目的经费相对确定，项目经理通常使用德尔菲估算法进行估算。德尔菲估算法是典型的经验估计法，它是由专家小组中的成员独立估算项目各个项目的工作量，然后根据一定策略进行汇总，从而得出该项目的工作量估算。德尔菲估算法的主要流程如下：德尔菲法估算流程四、 软件项目需求优先级影响因素分析软件项目需求优先级确定的根本原因就是要在资金、时间、开发人员等有限的情况下，能够合理安排各个项目开发的顺序，保证不耽误项目开发工作，并且尽可能多的实现客户的需求，同时尽量降低在项目开发和上线运行中的风险。本章中，对软件项目风险、进度和收益分析等估算是在需求管理阶段，以需求分析等资料为基础进行定量的估算，并不是对整个项目的进度控制、风险管理。本章对进度控制及收益分析方法进行了简要阐述，着重对需求分析后软件项目风险估算及项目间相关性进行探讨。3.1 软件项目需求优先级影响因素选择思路Karl E.Wiegers 所编写的软件需求书中从风险、价值、成本三个因素来评价需求优先级顺序。AHP方法在确定软件优先级中的应用一文中以价值、费用、风险三个因素作为软甲项目需求优先级确定的评价准则。而在现实的软件项目中这三个因素也是用户和项目方都比较关注的，几乎在所有的软件项目需求优先级评价文章中都会考虑，但是书中的评价方法并没有考虑项目间相关性的影响，事实上项目间的相关性，有的时候会对项目的进度起着关键的制约作用。如果没有分析清楚项目间的数据关系，很可能会在开发中因为某个项目没有完成开发，不能提供有关数据，结果导致需要这部分数据的项目不能如期开发，成为制约整个项目进度的瓶颈，造成整个项目的延期，增加了需求变更的可能性，同时项目成本和风险也大大提高。层次分析法在ERP需求分析中的应用一文通过分析，得出需求影响因素的重要性从大到小分别是功能需求、易用性、界面需求、安全性、可维护性。这也是一种影响因素的划分角度，缺点是没有从需求可行性及产生的效益等方面加以考虑，而且对于各个项目与上述五个因素对应难以量化分析，而只能依靠专家简历判断矩阵来解决，主观随意性太大，对项目需求优先级划分指导意义不大。本文借鉴以上文章中专家观点，同时结合本人参与的项目经验，选取项目收益、成本、开发风险、开发进度和项目间相关性五个因素来评价软件项目需求优先级。实践证明，这几个因素也是软件开发项目中客户方和项目方最关注的几个方面。采用这五个影响因素一方面比Karl E.Wiegers用的评价因素更加全面，多考虑了项目间相关性及项目成本等重要方面，这样思考更加全面，可以更加科学地反应项目间的合理开发顺序，另外与层次分析法在ERP需求分析中的应用中选择的影响因素相比，本文中的五个影响因素也便于量化计算，许多相关数据不需要专门计算，都可以在需求分析之后从行管部门的工作计划、进度计划、风险控制等资料中直接取得，节约了工作成本。总之，经过多次比较分析本文最终选定项目成本、收益、开发风险、开发进度和项目间相关性五个因素来评价软件项目需求优先级。1.软件项目成本估算1. 2.软件项目风险估算软件项目风险是指在软件开发的过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险真的出现，就极有可能会影响项目的进度，增加项目的成本，项目出现项目失败的情况。因此，软件项目风险的大小直接关系到项目是否有必要开发以及开发优先级等重要问题。所以，本文将软件项目风险大小作为评价项目需求优先级确定的重要因素之一。项目风险有两个基本的特征，风险事件发生的可能性、风险发生后所造成的损失。因此Boehm讲风险影响水平定义为这两个部分的函数：风险当量（RE）=PC其中，P：是出现不如人意的结果的可能性。C：是与风险相关的损失程度。进行风险分析时，重要的是量化不确定的程度以及每个风险可能带来损失的严重程度。风险评级概率P概率权重说明极高0.81-0.995超出目前水平，极有可能出现技术问题很高0.61-0.804超过目前水平，很有可能出现技术问题高0.50-0.603最新技术，但未充分考验，有可能出技术问题一般0.25-0.492最好的技术，不会出大技术问题低0.10-0.241实用技术，不会出技术问题很低0.01-0.090正在使用的系统表3-1风险定量评级参照以上标准尺度表采用Deilhi法，估算风险发生的概率。具体是采用少数服从多数，要求每个专家结合风险发生可能性标准尺度表，对每个风险进行独立的评分，然后讨论每个评估的合理性，进行循环讨论，直到达成共识。2. 3.软件项目进度估算本文中对项目进度的估算并不是整个项目周期的进度控制，只是在需求分析后，为了确定软件项目需求优先及顺序，对各个软件项目开发完成所需要时间的估算，因为项目进度也是评价项目需求优先级的一项重要指标。否则，项目可能因为耗时过多、成本增加，同时制约其他相关项目的开发进展，最终导致项目不能及时完工。在项目前期，资料相对缺乏的情况下，对项目进度的估算多采用专家判断、类比估算、三个时间估计法等定性分析。如果在此之前已经运用WBS对工作结构进行了详细分解，也可按照分解的工作要求，结合以往类似项目经验估算项目进度，COCOMOII模型中项目进度的估算是一种定量与定性结合的估算方法。3. 4.软件项目收益分析在项目实施之前，已经对整个项目进行了可行性分析，其中的一个重要方面就是项目成本收益分析，来判断此项目的开发是否合算。本文是用来解决软件项目需求优先级的问题，是在项目分步实施的情况下，有限资源优化配置问题。因此在项目前期可行性分析论证及较为详细的需求分析的基础上，分开单独考虑项目成本和收益，以便更加清楚地反应项目占用资金情况及收益率等重要指标，为软件项目需求优先级的合理确定提供重要的支撑。考虑到软件项目有很多难以量化、估算的潜在收益等，所以通常来说项目收益会考虑以下几点：直接收益，这些收益直接由计划的系统的运行产生，此部分收益可以按照计划的运行情况直接计算。例如，因为引进了更加先进的设备而导致的人力资本的减少。可估算的非直接收益，通过采用更加有好的用户界面增加准确性和减少出错的次数而降低成本等。无形收益，这种收益常常是存在于一个较长的时间段，并且性质上难以量化。在需要估算个项目收益时，直接计算可估算的直接收益部分和可估算非直接收益部分；其次估算无形收益部分，可通过建立判断矩阵，将各个项目进行两两比较，区相对收益值；然后由专家小组估算整个项目无形收益总值；最后估算各个项目无形收益具体值。再加上第一步可估算收益值可得软件项目总收益，作为软件项目需求优先级确定的一项重要依据。4. 5.需求紧急性评价表五、 软件需求优先级评价方法应用前文中提到的软件需求优先级评价方法采用定量分析的方法，对软件需求优先级进行较为准确地评价。但是，在实际的项目中往往时间、资源有限，很难对需求优先级进行细致的评价。最常见的评定需求优先级的方法，依赖于评价人员的经验，以及同类项目的历史数据。一般也只是大概确定，每项需求的工作量等级。如：高、中、低。本章节以作者所在的项目团队为示例，描述在实际项目中常用的需求优先级确定方法，并结合前文中需求优先级影响因素、需求优先级确定方法，以实用性的目标，制定一套定性与定量评价相结合的评价体系。1. 需求评价体系设计原则在项目前期阶段中，建立实用的需求优先级评价体系是科学、合理地评价需求由县级的重要保证，也是准确地对项目进行管理的有效方法。因此，在设置评价体系时，应该遵循一些基本的原则。1.1 科学性指评价体系的设计无论是在理论还是在视线中都可以科学地反应需求优先级的影响因素，在评价时做到使用科学的方法，抓住项目管理的理念，使指标体系在基本概念和逻辑结构上合理、严谨，符合客观事实。1.2 全面性由于项目需求来自业务的各个方面，五花八门，那么所选取的评价指标也应该全面，涵盖到社会生活的各个方面，在考虑项目收益之余也要考虑项目风险。1.3 可行性虽然现