CMM软件开发项目管理

91,单击此处编辑母版文本样式,第二级,第三级,单击此处编辑母版标题样式,初始级,已管理级,已定义级,定量管理级,优化级,初始级,可重复级,已定义级,已管理级,优化级,CMM L2,软件项目管理,目 录,项目管理概述,软件生命周期,软件度量,软件项目估算,风险管理,软件项目计划,V,小 结,参考资料,I 软件项目管理概述,1.1 软件项目管理的目的,1.2 软件项目管理的重要性,1.3 软件项目管理的对象,1.4 软件项目管理的主要任务,1,.,1 软件项目管理的目的,为了生产产品能做到:,按时交付,在预算内,合格的质量,按计划做事,1.2 软件项目管理的重要性,软件工程管理引起广泛注意源于20世纪70年代中期，当时发现不成功的项目70%是因为管理不善而引起,20世纪90年代中期，美国的软件开发仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付,1.3 软件项目管理的对象,任务,成本,工作量,效率,人员,资源,风险,1.4 项目管理的主要任务,定义软件生命周期,进行软件规模估算,进行软件风险分析,制定软件开发计划,进行软件项目跟踪与监控,进行软件度量,2 软件生命周期,2.1 软件过程的三个主要阶段,2.2 什么是软件生命周期,2.3 软件生命周期模型,2.4 瀑布模型,2.5 进化模型,2.6 螺旋模型,2.7,Rational,软件开发过程框架,2.8 软件生命周期的选取评价准则,2.1 软件过程的三个主要阶段,2.1.1 定义阶段,2.1.2 开发阶段,2.1.3 维护阶段,定义阶段,定义阶段要明确“做什么”,定义系统和软件的关键需求：,在此阶段，开发人员试图搞清要处理什么信息,预期完成什么样的功能和性能,达到什么样的系统行为,建立什么样的界面,有什么样的约束,设计需求跟踪矩阵和系统测试用例,定义一个成功系统的确认标准是什么,定义阶段三个主要任务：系统工程分析；软件项目计划；软件需求分析,开发阶段,开发阶段要明确“如何做”,设计软件：,功能如何转换为构架,细化需求跟踪矩阵和设计集成测试用例,试图定义数据如何结构化,界面如何表示,设计如何转换成程序,测试如何进行,定义一个成功系统的设计的确认标准是什么,开发阶段三个主要任务：软件设计；代码生成；软件测试,维护阶段,维护阶段要明确“改变什么”,改正性维护：约占20%左右。主要是改正处理方面、性能方面以及编程方面的错误,适应性维护：约占25%左右。主要用于适应数据环境（外部环境）、硬件及操作系统（内部环境）和移植工作,改进性维护：约占50%左右。主要用于提高处理效率、提高性能、使之使用方便、增加及改进输出信息，以达到便于维护的目的。这包括改进易读性和注释等,2.2 什么是软件生命周期,软件生命周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程,在计算机技术发展的初期，人们把软件开发简单地理解为编写程序,随着软件复杂性的增长，人们认识到软件开发活动应划分为需求分析、设计、实现、测试等若干个活动，并将这些活动以适当的方式分配到不同的阶段中去完成,通常把软件生命周期分为5个阶段：,需求,设计,编码,测试,维护,2.3 软件生命周期模型,软件生命周期模型是描述软件开发全部过程、活动和任务的结构框架,软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础,瀑布模型 (,Waterfall Model),进化模型（,Evolutionary Model）,螺旋模型（,Spiral Model）,统一软件开发过程（,Unified Software Development Process）,2.4 瀑布模型(1),1970年,W.Royce,提出了最早的软件开发模型 - 瀑布模型。该模型给出了固定的顺序，将软件生命周期各阶段的活动从上一阶段向下一阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品,这一模型规定了开发各阶段的活动为：提出系统需求，提出软件需求，需求分析，设计，编码，测试和运作。并且还规定了自上而下相互衔接的固定顺序，构成了熟知的瀑布模型,实践表明，各个阶段间的关系并非如此简单。由于阶段评审可能出现向前阶段的反馈，致使在各阶段间产生环路，瀑布流水出现上流。,W.Royce,在提出瀑布模型时，就对此提出了如何进行的建议,分析,设计,编码,测试,瀑布模型(2),每个开发阶段均应具有以下特征,从上一阶段接受本阶段工作的对象，作为输入,对上述输入实施本阶段的活动,给出本阶段的工作成果，作为输出传入下一阶段,对本阶段工作进行评审，若本阶段工作得到确认，则继续下阶段工作，否则返回前一阶段，甚至更前的阶段,系统需求,软件需求,分析,设计,编码,测试,运作,瀑布模型,瀑布模型(3),系统需求,软件需求,分析,设计,编码,测试,运作,瀑布模型,瀑布模型(4),瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量,优点：近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的开发复杂度、促进软件开发工程化方面起着显著作用,缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。这些问题可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉,2.5 进化模型(1),进化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现,软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之, 完成他们的工作, 并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程,每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。如果在一次迭代中，有的需求不能满足用户的要求，可在下一次迭代中予以修正，从而在一定程度上减少了软件开发的盲目性,进化模型(2) - 原型模型,建造/修改,原型,听取用户,意见,用户测试,运行原型,进化模型(3),进化模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。软件系统的原型有多种形式：,丢弃型：原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃,演示型：开发原型仅以演示为目标,样品型：原型规模与最终产品相同，只是原型仅供研究用,增长式演示型：原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，可增加需求，实现后再交付使用,粗陋型：用较短时间开发的简易原型,2.6 螺旋模型(1),将瀑布模型与进化模型相结合，并且增加了两者所忽略的风险分析。它将软件项目开发分别划分为四类活动, 沿着螺线旋转，在笛卡儿坐标的四个象限上分别表达了四个方面的活动，即：,制订计划：确定软件目标，选定实施方案，弄清项目开发的限制条件,风险分析：分析所选方案，考虑如何识别和消除风险；,工程实施：实施软件开发；,客户评估：评价开发工作，提出修正建议。,沿螺线自内向外，每旋转一圈，便可开发出更为完善的一个新的软件版本,螺旋模型(2),原型1,原型2,原型3,可运行,原型,需求计划,生存期,计划,开,发,计,划,集,成,与,测,试,软件,需求,需求,确认,设计确认,与验证,软件,产品,设计,详细设计,风,险,分,析,风,险,分,析,风,险,分,析,验收,测试,实现,集成,与,测试,单元,测试,编码,工程实施,开发、验证,下一产品,提交线,评审,累计,成本,风险分析,评价方案，识别,风险、消除风险,制订计划,决定目标,方案和限制,螺旋模型,客户评估,螺旋模型(3),螺旋模型通常用以指导大型软件项目的开发，如果开发风险过大，开发者和客户无法承受，项目有可能因此终止。多数情况下会沿着螺线继续下去，自内向外逐步延伸，最终得到满意的软件。,如果对所开发项目的需求已有了较好的理解或较大的把握，无需开发原型，便可采用普通的瀑布模型。这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目的需求理解较差，需要开发原型，甚至需要不止一个原型的帮助，那就要经历多圈螺线。在这种情况下，外圈的开发包含了更多的活动。也可能某些开发采用了不同的模型。,和其它模型相比螺旋模型的优越性较为明显，但要求许多客户接受和相信进化方法并不容易。本模型的使用需要具有相当丰富的风险评估经验和专门知识。如果项目风险较大，又未能及时发现，势必造成重大损失。,2.7 统一软件开发过程(USDP)框架,USDP概述,USDP术语,USDP的高层视图,USDP的特点,USDP概述,软件开发涉及多种因素，很难定义一种通用的过程。任何软件项目都可选用适合自身的任何过程,UML是一种通用的建模语言，不是一种方法，适用于任何开发过程,UML设计者推荐使用的USDP是一个过程框架，倡导采用UML来记录、分析和设计的结果,软件过程基础,Rational,软件开发过程,USDP术语,活动：有明确输入条件、资源需求和控制约束并产生一定输出的工作单元，可用一个五元素集,F(A，I, R, C, O),来描述,过程：活动的偏序集。适合软件开发的过程叫软件开发过程；适合企事业事务的过程叫企事业过程；等等,角色：执行活动的人力资源、使用系统的用户或与系统交互的外部系统,人员：过程中执行某一活动的人力资源(个体或群组),用例：系统中能满足某一需求的一组活动序列。一个用例应能返回一定的可见结果给执行该用例的角色,构造：在迭代增量式开发过程中的每一步所产生的结果，是系统某一特定部分的一个可执行版本,软件过程基础,Rational,软件开发过程,USDP的高层视图,USDP,包含四个阶段：初始阶段、细化阶段、构造阶段和移交阶段,在初始阶段，需要考虑项目的效益，并确定项目的适用范围，这一阶段需要与客户进行讨论,在细化阶段，收集详细的需求，进行高层分析和设计，并为构造阶段制定计划：选择一些功能点，完成这些功能；再选择别的功能点，再完成这些功能；如此循环往复,移交阶段,初始阶段,细化阶段,2,3,1,构造阶段,软件过程基础,Rational,软件开发过程,USDP的高层视图(续),构造阶段由多次迭代组成，每一次迭代都包含整个软件生命周期：捕获用例、分析、设计、实现和测试阶段。每一次迭代所得到的产品应满足项目需求的某一个子集，提交给早期用户或是内部提交,移交阶段，也包含1个或多个迭代，将软件给用户安装、试用和维护,这是一个迭代增量式的开发过程，即不是在项目结束时一次性提交软件，而是分块逐次开发和提交,软件过程基础,Rational,软件开发过程,USDP的高层视图(增量模型),增量1,增量2,增量3,第一个增量发布,第二个增量发布,第三个增量发布,开发进度,软件过程基础,Rational,软件开发过程,USDP的特点,基于,UML、,以构架为中心、用例驱动与风险驱动相结合的迭代增量式软件开发过程,USDP,包含初始、细化、构造和移交等四个阶段，其中构造阶段由多次迭代所组成,每次迭代中的软件开发工作都围绕需求捕获用例、分析、设计、实现和测试等五个核心工作流来组织,职责明确：每个人都明白自己的职责；开发者能更好理解其他开发者的职责；管理人员能了解开发者的职责,过程规范：单位对自身员工的培训标准化；开发人员和管理人员不需要学习新的过程就能在小组间调动工作,软件开发过程可重复使用：开发技术和管理技术可以重用；项目计划更准确，成本估算与实际更吻合，开发周期更短,软件过程基础,Rational,软件开发过程,2.8 软件生命周期的选取评价准则(1),资源的可用性,项目的复杂度,应用的费用,未来升级的费用,使用的容易度,应用的功能需求,渐进的需求变更,软件过程基础,软件生命周期模型,软件生命周期的选取评价准则(2),应用的寿命,产品的技术,应用的生产力,产品的质量,需求的易变性,产品的重用和文档的可交付,风险管理,未知需求,软件过程基础,软件生命周期模型,3 软件度量,3.1 软件度量的基本概念,3.2 软件度量的意义,3.3 度量元,3.4 度量过程,3.1 软件度量的基本概念,在现实世界中，对用数字或符号指定给实体的某些属性进行度量，以便根据已明确的规则来描述它们,软件度量就是在软件开发过程中，把软件开发过程和软件产品的各种属性，例如软件开发成本、花费时间、开发效率、产品规模、软件质量的各种数据，度量、记录、统计并进行必要的分析,3.1 软件度量的基本概念(续),软件度量: 指计算机软件中范围广泛的度量。度量可应用于软件过程，也可用于整个软件项目,软件产品的度量：用定量的方法表达和分析软件产品质量特性，如功能度和可靠性等。通过辅助估算、质量控制、生产率评估以及项目控制评估工作产品的质量。,软件过程的度量: 用定量的方法表达和分析软件过程的特性，如软件开发效率、开发成本、质量保证措施的有效性等。目的是为了在一个连续的基础上进行改进,软件过程的两类度量,直接度量:,LOC，,执行速度，内存大小，某阶段缺陷数等,间接度量（导出度量）：功能，质量，复杂性，有效性，可靠性，可维护性等,3.2 软件度量的意义,如果你不能度量它，就不能用数字表达它，那么你对它的了解就很贫乏、很不令人满意：它可能是知识的开始，在思想上还远没有进入科学的阶段。（Lord Kelivin）,任何工程如果不能用数字来描述，这说明它仍处在摇篮时期,3.2 软件度量的意义(续）,从软件特性看度量的意义,抽象性：软件没有形体，自然没有一般制造业产品所具有的几何尺寸、物理性质（如重量、体积等）以及化学性质等,复杂性：软件内部结构复杂，可以认为，软件是人类创造的最为复杂的实体，而且由于人们尚未掌握其研制规律，因而这个实体显得更加难以捉摸,多样性：即使需求以及所用的平台和编程语言相同，不同的软件开发人员或同一个开发人员在不同的年月，也不可能开发出完全相同的软件,易变性：在软件的开发过程和使用过程中，常常由于各种原因需要对软件而进行各种修改,3.2 软件度量的意义(续),有效地、定量地进行管理，是进行计划、估算、风险分析、过程监控、质量监控、评价等活动的基础，是改进过程与提高软件质量的重要手段,3.3 度量元,什么是度量元,资源和成本的度量,项目进度与进展状态的度量,增长和稳定性度量,产品质量的度量,软件质量的度量,软件程序的度量,(1)什么是度量元,能用于定量地描述实体的属性，如软件的规模、缺陷的数目、工作量的人天数等,(2)资源和成本的度量,人员,工作量,人员的经验,人员的周转,财务性能,获得的价值,成本,开发环境,资源的可用性,资源利用情况,例：人员配置情况,(3)项目进度与进展状态的度量,里程碑性能,里程碑日期,工作单元进展情况,部件状态,需求状态,测试用例状态,问题报告状态,评审完成情况,变更请求状态,增量的能力,构造块内容 - 部件,构造块内容 - 功能,工作单元完成状态,测试用例完成状态,(4)增长和稳定性度量,产品规模和稳定性,代码行,部件,存储的词汇量,数据库规模,功能的规模和稳定性,需求,功能点,用例(,Use Case),变更请求工作量,例：需求变化的度量,(5)产品质量的度量,缺陷,问题报告,缺陷密度,复杂度,返工,返工规模,返工工作量,例：问题报告状态,例：软件问题数的功能域分布图,(6)软件质量度量,程序质量度量,文档质量度量,软件质量度量准则,(7)软件程序度量,面向规模的度量,面向功能点的度量,软件缺陷排除率的度量,软件测试的度量,面向规模的度量,工作产品标识：项目、模块,代码行数：千行语句数、字符数、字节数,注释率：注释语句数/代码行数,错误数KLOC,文档页数KLOC,成本KLOC,KLOC数人月,面向规模的度量(续）,面向规模的度量特点：,代码行是开发项目的生成品，容易计算；,依赖于程序设计语言；,必须在项目完成后才能得到数据。,4 工作分解结构( WBS),4.1 WBS,4.2 WBS,中的层次结构,4.3 产品层次结构,4.4 活动层次结构,4.5 构造,WBS,4.1 WBS,WBS(Work Breakdown Structure)以层次结构组织项目活动元素，它是根据自顶向下的方法，按照模块化的思想将项目分解成易于管理的活动,每项活动可以被分配、执行和跟踪。WBS的分解粒度要达到可管理的级别，即每项活动能够细分到个人，而且最好能在一周内（5个工作日）完成,WBS是项目计划的“基础构架”，它是估计、计划、跟踪和监控的主要依据。在整个项目生命周期中，WBS必须用适当的细节等级封装变更和进化。构造好WBS，将会给项目的计划和实施带来极大的便利,4.2 WBS中的层次结构,两种类型:,产品,活动,或两者的混合,4.3 产品层次结构,指明各种软件分量如何安置在软件系统中,反映软件产品的基本结构，由软件设计者确定,分量有：程序(routine)、模块、子系统等,4.4 活动层次结构,指明处理一个软件分量的各种方法,合适时，活动层次的一部分可以运用到产品的任何一个层次,4.5 构造 WBS,迭代式构造,构造有意义的逐步细分(roll-up)的层次结构,向下细分到能实际作出策划和控制的层次（不要太碎）,综合自顶向下/由底向上的方法,采用混合的产品/活动层次结构,WBS例子,ACTIVITY Break-up,Product,Break-up,5 风险管理,5.1 风险策略,5.2 风险特性,5.3 风险管理活动,5.1 风险策略,被动式：风险发生后才采取措施，是“救火模式”,主动式：在项目开发前就标识出潜在的风险，有计划地管理风险。主要目标是预防风险。必要时加以控制，减轻影响,5.2 风险特性,不确定性：刻划风险的事件可能发生也可能不发生；即，没有100发生的风险（100发生的风险是加在项目上的约束）,损失：如果风险变成了现实，就会产生恶性后果或损失。,5.3 风险管理活动,5.3.1 风险识别,5.3.2 风险估计,5.3.3 风险评估,5.3.4 风险驾驭和监控,5.3.1 风险识别,风险识别概述,项目风险识别,技术风险识别,商业风险识别,人员风险识别,开发环境风险识别,风险识别概述,风险识别就是根据历史数据及经验，标识相关的风险，列出全部风险项,S1，S2 ，Sn 。,包括：,项目风险识别,技术风险识别,商业风险,人员风险识别,开发环境风险识别,项目风险识别,项目风险识别是要找出潜在的预算、进度、个人（包括人员和组织）、资源、用户和需要方面的问题，以及它们对软件项目的影响,如项目复杂性、规模和结构等都可构成风险因素,技术风险识别,技术风险识别是要找出潜在设计、实现、接口、检验和维护方面的问题,规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素,商业风险识别,商业风险有：,建立的软件不是真正所想要的,建立的软件不适合整个软件产品战略,销售部门不清楚如何推销这种软件,失去上级管理部门的支持,失去预算或人员的承诺（预算风险）,人员风险识别,人员风险有：,缺乏优秀人才,缺乏配套人才,人员不够,人员对分配工作缺乏兴趣,人员流动过快,人员意外缺勤（因病、因事）,人员缺乏足够培训,开发环境风险识别,开发环境风险有：,是否有可用的软件支持工具（项目管理工具、配置管理工具、测试工具、）,设备是否陈旧，设备意外损坏,是否发生病毒，使开发环境瘫痪,5.3.2 风险估计,估计风险发生的可能性。估计风险可能产生的结果,建立一个尺度或标准来表示一个风险的可能性；可以使用概率尺度表，其值分为：极罕见的、罕见的、普通的、可能的、极可能的,描述风险的结果，分出影响的类别：性能、支持、成本、进度,估计风险对项目和产品的影响；影响可分为4级：,灾难性的,严重性的,轻微的,可忽略的,5.3.3 风险评价,在项目进行中，进一步检验在风险估计时所得到的估计的准确性，对已暴露的风险进行优先排队，考虑控制和/或消除可能出现风险的方法,定义风险参考水平值,对前述风险影响类别：性能、支持、成本、进度分别（或组合）制定一个参考水平，即性能下降，支持困难、成本增加、进度延迟到某个程度（水平）项目被迫中止,5.3.4 风险驾驭和监控,风险驾驭是指利用某些技术以及某些项目管理方法等设法避开或转移风险,风险监控：,做风险因素跟踪,进行风险再估计,收集可用于将来的风险分析的信息,6 项目计划,6.1 项目计划的重要性,6.2 项目计划的动态性,6.3 项目计划的三个前提,6.4 软件项目计划的套件,6.5 软件项目(开发)计划的内容,6.6 进度安排和监控的图形工具 甘特图,6.7 进度安排和监控的图形工具 ,PERT,和,CPM,技术,6.1 项目计划的重要性,对任何软件项目来讲，其任务均是按期、按预算开发满足用户需求的、高可靠、高性能的软件产品,要作到这点项目计划是基础,项目计划是为实现预定目标而作的科学预测，以它为基准跟踪和控制项目,项目计划确定未来的行动方案和资源分配，引导项目的实施,项目计划的质量是决定项目成败、优劣的关键因素之一,6.2 项目计划的动态性（1）,项目计划是指导项目的纲，要尽早制定,在项目定义阶段，只要明确了软件项目的目标和软件要实现的基本功能；只要项目人员明白用户的意图就应制定,通过初始计划的制定，项目经理能熟悉项目工作的基本方面：范围、需求、总的时间和里程碑、组织机构、人员要求等。它确定了生存周期，管理过程、技术过程等等。这些在项目过程中，变化不会太大,有时也称初始计划为基础计划,6.2 项目计划的动态性（2）,众所周知，项目计划是基于当前已有的信息（包括过去的经验，当前项目的目标、范围、组织结构、资源等），安排工作和进度，预测结果,随着项目的进展、信息的增多和理解的深入，预测会逐渐地接近实际，所以对任何类型的项目来说，项目计划的修订不可避免,项目计划将不断修订，贯穿全生存周期,6.3 项目计划的三个前提,生命周期,WBS,估计,6.4 软件项目计划的套件,软件项目计划应可以从多个方面去制定,文档可以分为：,软件开发计划,软件质量保证计划,软件配制管理计划,风险管理计划,软件测试计划,项目培训计划,这些文档可以合成为一个文档,6.5 软件项目(开发)计划的内容,一个软件开发计划要包括以下大部分或全部条目：,项目选定的软件生命周期,将要开发的各种软件产品,项目进度,估算软件工作产品的规模及所需的资源和费用,设施、支持工具以及硬件,标识和评估软件风险并与委托进行商议,有必要反复进行这些步骤以建立软件项目的计划,6.6 甘特图,6.7 PERT和CPM技术（1）,PERT,和,CPM,技术是安排开发进度，制定软件计划的最常用的方法。两种技术都是由较早的项目计划活动中已经产生的信息来驱动。,程序评价和评审技术（,Program Evaluation &Review Technique- PERT）,关键路径（,Critical Path Method CPM）,信息包括：,工作量估算,产品功能的分解,适当的模型选择,项目类型和任务集合的选择,PERT技术和CPM（2）,任务网络图,描述任务之间的依赖关系,WBS,工作分解结构,两种方法都提供项目工作定量划分的工具，支持：,确定关键路径，决定项目持续时间的任务链,通过统计模型为单个任务建立最有可能的时间估算,计算为特定任务定义其时间“窗口”的边界时间。,PERT技术和CPM（3）,重要的边界时间,某个任务的最早开始时间是当其所有前驱任务在最短的可能时间中完成时,某个任务的最晚开始时间是在不延迟项目最小完成时间的前提下，最晚启动该任务的时间,最早结束时间是最早开始时间加上任务持续时间,最晚结束时间是最晚开始时间加上任务持续时间,总浮动量是在保证进度的前提下，调度任务时所允许的富裕时间或回旋时间总和,PERT技术和CPM（4）示例,A：,公共模块,B：,新编模块，依赖,A,的完成,C：,已有模块，修复缺陷。依赖,A,的完成,0,4,1,2,3,6,5,7,8,起点,A,编码,B,编码,A,测试,A,调试,C,理解,C,修改,B,测试,B,调试,C,测试,C,调试,BC,组装测试,PERT技术和CPM（5）分层任务网络图,0,4,1,2,3,6,5,7,8,参考资料,Watts S. Humphrey. Managing the Software Process. 1989 by Addison-Wesley. (,有中译本, 2003 清华大学出版社),Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley. 1998. (,有中译本, 机械工业出版社, 2002),Bob Hughes & Mike Cotterell, Software Project management (third edition). McGraw-Hill International (UK) Limited. 2002. (,将有中译本, 机械工业出版社, 估计于2003.9出版),Barry Boehm，“Software engineering economics”，1981,.,(,有中译本, 电子工业出版社, 1988),谢 谢!,