《CMM与项目管理.ppt》由会员分享，可在线阅读，更多相关《CMM与项目管理.ppt（89页珍藏版）》请在三一办公上搜索。
1、CMM与项目管理-CMM与项目管理研讨会心得交流,第二事业部寇东,概要,CMM简介项目管理简介软件项目管理软件工程需求工程软件测试,问题,主管在项目在进行过程中询问项目的进展情况，你挠挠头皮：设计做的差不多了，一部分已经开始编码了。主管不满意了：什么时候能交活？你有些底气不足：至少还得一个多月的时间。主管着急了：就剩两周的时间了，你要花一个月，上一周你还答应可以在三周内完成。六周过去了，你的项目组还在测试，还在修改代码。两个月过去了，项目终于完成了。尽管客户有不少抱怨，但总算做了验收。下一个项目会怎样？,SEI 的解决方案,设定目标,度量与跟踪,预测与纠正,计划与评审,理性管理,4,3,1,2
2、,理性管理,度量与跟踪,要求有纪律的工作,要求具体的计划,计划评审和协商,设定具有短期目标和目的,目标的评审和跟踪,预测并纠正问题,监督经营业绩,SEI 的解决方案,软件项目管理的重要原则：重视软件质量 始终如一地强调有纪律的工程工作理性管理的四要素CMM/CMMI/PSP（Personal Software Process）/TSP（Team Software Process）,软件流程,A software process can be defined as a set of activities，methods，practices，and transformations that peo
3、ple use to develop and maintain software and the associated products（e.g.，project plans，design documents，codes，test cases，and user manuals）。如何工作（软件开发和维护）,软件流程能力software process capability,遵循这样的软件流程，有多大可能可以达到预计的结果。软件流程能力提供了一种有效的手段，可以预计软件组织承担某个项目最有可能的结果是什么样的。,软件流程性能software process performance,代表了遵循这样
4、的软件流程，真正达到的结果是怎样的。软件流程能力表述的是期望的结果，而软件流程性能表述的是实际的结果。,软件组织成熟度,不成熟的组织最大的特征就是“救火”，只顾、也只能忙于解决眼前的问题，而眼前的问题又往往一个接一个。成熟的组织要有序得多，力图预防问题，而非应付问题，虽然也可能出现意外情况，但对此是早有防范的，是有准备的。成熟与否导致的最终结果就是客户对其能否胜任软件项目的信心有所不同不同。,软件流程成熟度software process maturity,一个特定的流程在多大程度上被明白无误的定义、管理、衡量和控制，以及有多有效。软件组织的软件流程成熟度预示着它的软件流程能力有多大的发展潜力
5、，这不仅指它的软件流程有多丰富，多完备，而且指这些软件流程在最大程度上是一致的，在整个组织范围内，在任何一个项目中，都是被很好的了解和贯彻。,CMM概貌,CMM 是一个阶梯式的模型它根据软件组织的流程成熟度高低分成了5 个级别（level），从第一级的初始级一直到第五级的优化级,初始级,可重复级,已定义级,可管理级,优化级,纪律化,标准化,可预测,持续改进,指导软件组织逐步成熟的框架,任何一个软件组织，在某个时刻，都可以依据一定的标准来被划定处于哪个级别。这个组织就可以知道，它下一步要争取的级别是哪一级。CMM可以说是一个指导软件组织如何一步一步的走向成熟的框架。每一个低的级别都是向更高级别迈
6、进的基础。,KPA（Key Process Area)划定组织流程成熟度级别的依据,除了初始级外，每个级别都包括若干个KPA，每个KPA 又设定了2 至4 个目标。当某个KPA 的所有目标达到时，就可以说该KPA 被满足了；当某个级别的所有KPA（除了极个别KPA 不是必须的）都被满足时，我们就可以说，已经达到该级别了。,KPA 归类,CMM KPA应用,既要利用KPA 有重点、有次序的指导流程改进，也不要眼里只有KPA，忘记了现实的状况。有关键流程区，当然还有非关键流程区；所以，千万不要以为，处于某个级别的组织，所要面对的流程只是那几个KPA；要做的流程，其实远远不止这些。可重复级只有6 个
7、KPA，没有涉及基本的软件工程活动（如系统设计、软件测试），也没有涉及项目资源（如必须的软硬件和其他设备）采购、客户交流等等，而这些对于做好项目（更不要说要可重复了）也是非常重要的。CMM 没有涉及这些流程，是因为它把这些流程归结为“非关键”的，但“非关键”并不等同于可忽略的。,CMM内部结构,关键过程区表明关键过程的实施和制度化,共有特性（common feature）与关键实践（key practice）,每个KPA 都包含了相关的一系列KP，这些KP 提供了达到KPA 目标的一个指导。是指导，而非必须。正所谓“条条大路通罗马”，我们完全可以采取其他的做法（Practice）来满足目标，甚
8、至可以是CMM 没有提到的Practice。每个KPA 的所有KP 都按照共有特性（common feature）归类将KPA 的KP 按照共有特性组织起来，完全是为了方便,KP 共有特性（common feature）,实施承诺（commitment to perform）实施承诺通常包括是否建立了相关的制度，管理层是否支持等等。实施能力（ability to perform）包括诸如是否有足够的人力资源、培训等等实施活动（activities performed）度量和分析（measurement and analysis）实施验证（verifying implementation）,CM
9、M 强调,KPA 达成目标的一贯性和有效性，而不是今天能达到，明天就很难说。,CMM第一级：初始级,特点：项目的成功与否不是靠合理有效的软件流程来保证的，而是靠个人能力来保证的。无论组织内部的管理高层，还是外部的客户，都无法预见其项目的前景和结果，更不要说将结果控制在预算和进度之内。要求：初始级没有任何KPA，这一点与其他各级不同。在CMM中，只要从事软件生产和维护，该软件组织就自动达到第一级。而再往上就要经过CMM 评估了。注意：不要把未经CMM 评估与处于初始级两者混淆，有些软件组织虽然没有经过CMM 评估，但以CMM的要求看，也许远远超出初始级的标准。,CMM第二级：可重复级,软件组织能
10、力不再受制于个人，但是也非组织拥有，而是依赖于项目组。项目组从以往的类似项目中归纳成功经验和失败教训，并以此作为指导新项目开展的依据，从而在很大程度上，可以保证类似项目的再次成功。用一个词来概括，那就是“有纪律的”。项目组在其范围内，实施基本的项目管理，并对进度、预算和产品功能进行计划和跟踪，这样，项目的进展处于一种基本可控的状态。一个软件项目不再是一个“魔术般”的黑箱子，而是一些连续的黑箱子。,实施CMM2,管理层的表率作用。管理层人员必须首先注重自身流程的纪律化。有些项目经理或者质量管理人员，往往首先看到的是“程序员”的自由散漫，一要流程改进，就要求“程序员”遵循这个规矩那个条例，就要写文
11、档，开大会；这不仅违背了CMM 的初衷，更败坏了流程改进的名声缺乏群众基础的流程改进，无法取得实效,CMM2 KPA,需求管理（Requirement Management）软件项目计划（Software Project Planning）软件项目跟踪和监控（Software Project Tracking and Oversight）软件转包合同管理（Software Subcontrack Management）软件质量保障（Software Quality Assurance）软件配置管理（Software Configuration Management）。,CMM第三级：已定义级,
12、是在整个组织范围内，开发和维护软件的流程，包括管理的和工程的，以及这些流程的集成，已被明确地书面定义。各个项目就可以依据这一流程标准进行裁剪，明确其中每一项具体任务和工作的输入、输出、开始和完成的判断标准和条件、操作过程、以及验证措施等等。已定义级不再是一些连续的黑盒；由于每一项具体任务和工作都是可见的，因此外部人员可以随时深入到“黑盒”中，了解项目内部的进展情况，从而也使项目的及时调整和降低风险成为可能。,CMM3特点,不同项目和历史项目的成功经验和失败教训可以相互比较已定义级组织的能力是属于组织的，而不是项目团队的，更不是成员个人的。为了保证整个组织流程的标准和一致性，通常会有一个跨项目的
13、团队，比如SEPG（Software Engineering Process Group）负责整个组织的流程活动。为了使组织内每一个人明确自己的角色和权责，并能有效实施，整个组织范围内的培训是必不可少的。要建立起这样的流程，对个人的工作要授权，不要过分刻板。常有人把CMM 解释为刻板的文档和僵硬的工作规范，这样的理解至少是极端化的。刻板僵硬，以及随之而来的官僚作风，并不是CMM天生使然，而是对CMM的曲解和误用。,CMM3 KPA,组织过程焦点（Organization Process Focus)组织过程定义(Organization Process Definition)培训大纲（Trai
14、ning Program)集成软件管理（Integrated Software Management)软件产品工程（Software Product Engineering)组间协调（Intergroup Coordination)同级评审（Peer Reviews),CMM第四级：受管理级,定性的比较发展为定量的比较，从而使得人们（无论是内部的，还是外部的）可以更加科学、客观的预测软件项目的进度、预算和质量。定量是指在一定的概率内使结果误差控制在一定的范围内。如：存在90%的可能，进度误差不超过20%。处于受管理级的组织能及时采取纠正和弥补措施。确定要度量些什么。依靠收集和挖掘自身历史数据进
15、行软件度量。,CMM4 KPA,量化过程管理（Quantitative Process Management)软件质量管理（Software Quality Management),CMM第五级：优化级,重点从“建立”进一步转移到“优化”上。优化靠自己的积累、尝试和总结经验教训。具备了自我改进的基础架构和实现系统。尽管组织的内部情况会变化，外部环境和要求也会不同，但组织都可以在原有的基础上进行可控可测的流程优化，因为流程的每一个环节都是可见的、可客观评价的,CMM5 KPA,缺陷预防（Defect Prevention)技术更新管理（Technology Change Management)过
16、程变更管理（Process Change Management),CMM各级别关系,CMM高级别和低级别之间是存在很强的依赖性的，这样的依赖性不是强加的，而是自然的，符合逻辑和实践检验的。跳跃式前进的结果只能是拔苗助长，导致生产率和质量的下降。不仅成熟度级别之间存在严格的先后关系，在各个KPA 之间，即使在同一级别内，也存在严格的先后关系。例如，需求管理是项目计划的基础，而项目计划又是项目跟踪与监控的前提。,项目的基本概念,项目是一个组织为实现自己既定的目标，在一定的时间、人员和资源约束条件下，所开展的一种具有一定独特性的一次性工作。PMI的定义:A temporary endeavor un
17、dertaken to create a unique product or service.在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。,现代项目管理知识体系,1项目集成管理 确保各种项目工作和项目的成功要素能够很好的协调与配合，以及相应的管理理论、方法、工具。2项目范围管理 计划和界定一个项目或项目阶段需要完成的工作和必须要完成的工作的管理工作的理论、方法、工具。3项目时间管理 又叫项目工期进度管理，是有关如何按时完成项目工作的理论、方法、工具。4项目成本管理 又叫项目选价管理，是如何在不超出项目预算的情况下完成整个项目工作，所需的管理理论、方法、工具。5项目质量管理
18、 如何确保项目质量，以及保证项目质量所需的管理理论、方法、工具。,现代项目管理知识体系,6 项目人力资源管理 如何更有效地利用项目所涉及的人力资源，以及在项目人力资源管理方面所需的管理理论、方法、工具。7项目沟通管理 如何有效、及时地生成、收集、储存、处理和最有效的使用项目信息，以及在项目信息和沟通管理方面所需的管理理论、方法、工具。8项目风险管理 如何识别项目风险、分析项目风险和应对项目风险，以及项目风险管理所需的管理理论方法、工具。9项目采购管理 也叫做项目获得管理，是有关从项目组织外部寻求和获得各种商品与劳务的管理，以及这一管理所需的理论、方法、工具。许多项目涉及到承包商为购买方工作的情
19、况。在这种情况下，购买方提供最初的产品描述，也成为工作说明（SOW）,项目管理的过程,现代项目管理理论认为任何项目都是由两个过程构成：其一是项目的实现过程 其二是项目的管理过程现代项目管理将整个项目的全部工作看成是由一系列项目阶段构成的一个完整的项目生命周期。,项目工作阶段,项目的定义与决策阶段项目的计划和设计阶段工期计划、成本计划、质量计划、资源计划和集成计划项目的实施与控制阶段项目的完工与交付阶段,项目管理过程,一个项目的全过程或项目阶段都需要有一个相对应的项目管理过程。这种项目管理过程一般由五个不同的管理具体工作过程构成。起始过程计划过程实施过程控制过程收尾过程,管理过程间相互关系,管理
20、过程间交叉重叠关系,项目阶段间管理过程关系,如何执行项目,必须遵循那些经试验证明效果良好的方法谨慎地执行每个工程任务必须用文档正确地记录工作产品，以便其他人员能够查阅它们。项目任务必须经过仔细规划，并将它们分配给执行项目的人员，然后在项目执行的同时对它们进行跟踪。换句话说，要成功地执行较大规模的项目，必须在软件工程和项目管理这两方面增强正规程度和严格程度。,软件项目的管理过程,软件项目主要涉及两方面的任务：软件工程和项目管理。软件工程方面涉及系统的建立，并重点关注如何分析需求、设计、测试、编码等问题。项目管理方面涉及如何设置里程碑、组织全体人员、管理风险、监督进展等规划和控制软件工程的行为，以
21、满足项目在成本、进度和质量方面的目标。,过程的定义,从技术上讲，对于某个任务的一个过程，它由执行该任务时应当遵循的一个步骤序列组成。对一个组织而言，它建议其工程师和项目经理使用的过程就远非一个步骤序列了；它们涵盖了工程师们和项目经理所掌握的成功地执行项目的实践。通过过程就可能将好的经验同所有人共享，包括公司中新来的员工。这些过程有助于管理人员和工程师借鉴过去的成功经验，从而避开导致失败的陷阱。,为什么必须遵循过程,过程代表着集体的智慧，使用它们可以增加成功的机会。过程可能会包含一些多余的步骤，但是你事先不可能完全知道哪些步骤是不必要的，因些捷径可能会增加风险。如果没有采用过程，你就不能很好好预
22、测项目的结果。如果没有定义过程，你和组织就不能进行有效地学习。而学习和提高是当今知识世界必有可少的事情。过程减少了你须考虑的问题。检查表（checklist）必须会涵盖80%要做的事情，大大地减少了你的任务，因而你只须完成剩下的20%。,项目管理与CMM,有效的过程有助于成功地执行一个项目软件CMM提出了有效过程特征的框架。CMM是目前使用最为普遍的软件过程改进框架之一（现在其他常用框架有ISO9001）。,项目管理与CMM2 KPA,第2级（可重复等级）KPA的目标明确地表明第2级的重点几乎全部在项目管理上。在这些目标指导下，你建立一个项目计划并用文档记录它，根据计划评估正在进行的项目的绩效
23、，并在实际绩效明显地偏离计划时采取相应的措施。需求用文档正确地记录下来，并对需求的变更进行正确的管理。所有工作产品都在控制之中，并根据一个事先制定好的配置管理计划正确地管理对产品的变列。执行评审与审计。确保遵循计划的过程和标们标准。如果项目的某些部分被转包给其他软件开发商，则也要对被转包的工作进行正确地监督。,项目管理与CMM3 KPA,第3级（已定义级）中3个KPA的目标 重点强调组织管理和过程管理问题。对于达到第3级能力成熟度的组织中的项目，它使用专用型的标准过程，并重用以往项目的资源、数据和经验进行规划。执行项目的各小组通过良好定义的接口和机制进行愉快地合作。正确地执行评审以标识出工作产
24、品中存在的缺陷，并为执行评审和随后的任务提供充分的支持。,项目管理与CMM4 KPA,第4级（已管理级）上KPA的目标 在第4级上，组织的过程能力用量化术语表示，过程能力用于设定一个项目的量化目标。有关项目绩效方面的数据在当前的基础之上进行收集并与以往的绩效进行比较；如果觉察到明显的偏差，则采取正确的行动恢复对项目的控制。第4级的一个关键特点是在当前基础上使用统计过程控制技术，以便在需要时可以评估每种任务并采取正确的行动。,项目管理与CMM5 KPA,第5级上的3个KPA重点强调过程能力的改进。在这3个KPA中，故障预防KPA对项目管理影响最大。这个KPA要求通过系统地分析故障的原因，然后消除
25、那原因，从而前瞻性地预防故障。如果能够预防故障进入软件，则可以减去排除它们的工作量，从而提高质量和生产率。,软件项目管理建议,执行一个项目的全部责任由项目经理负责。他必须确保项目团队在规定的成本内按时将高质量的软件交付给客户。为了帮助项目经理实现这一责任，必须得到组织的支持(权力下放）。,Software Engineering Process Group,软件企业应该设立质量部门，其下辖一个软件工程过程小组（software engineering process group,简称SEPG）。SEPG负责协调所有过程任务，包括过程定义、过程改进以及过程部署。它还管理所有与过程使用相关的信息和
26、数据（诸如过程数据库和过程能力基准）提交产品的全部责任（包括质量）属于项目团队，但是SEPG使得项目团队能够轻松地遵循正确的过程。,SEPG对项目的支持,SEPG还形成了一个独立地监督过程问题和质量问题的渠道，并通过这个渠道向高级管理层报告这些问题。因为“过程不能依靠过程本身得到坚持”，所以SEPG有助于确保已义的过程得以实现并成为标准的实践。SPEG要制定定期独立审计的计划，并对它们进行管理，以确保已定义的过程和标准得以遵守。,Software Quality Advisor,SEPG除了提供过程培训外，还提供了一个与项目相关的成员，称为软件质量顾问（software quality adv
27、isor）。质量顾问帮助定义过程和遵循过程，确保过程得以遵守，帮助分析数据，并提供任何需的过程培训。因为顾问非常精通于项目过程、指南等等，所以顾问的主要帮助在对项目规划的过程中。顾问还评审目计划，以确保它包含了全部的关键要素。,软件项目管理过程,项目经理执行的一系列任务可以在项目管理（project management）过程中加以规定。这是一个非常标准化的过程，有五个主要阶段：项目启动项目规划项目执行项目监控项目收尾,项目启动和规划阶段,执行项目启动和管理任务 制定一个包含进度的项目计划 执行项目计划和进度计划的评审 获得高级管理人员的授权 定义和评审配置管理计划 使项目团队适应项目管理计划
28、 牵涉到客户、一个SEPG代表以及项目的业务经理 开始的标志是签定了项目合同或者得到了项目授权。而收尾的标志是已经用文档记录了项目计划，并且小组对它们进行了评审,项目执行，监控阶段,在这一阶段团阶的其他成员也要参与。开始的标志是项目计划已经完成并得到了批准，而结尾的标志是所有交付的工和产品为客户所接受。,项目收尾阶段,主要是在客户接受工作产品之后对项目进行系统的总结。这里的主要目标是从经验中进行学习，以便能够改进过程，项目完成后的数据分析构成了这一阶段的主要任务；对度量标准进行了分析，过程资源（诸如模板和指南等材料可用于帮助管理过程本身）被收集起来供以后使用，并记录有关的经验教训。,软件项目管
29、理,公共知识库软件配置管理工作量与进度估算质量规划风险控制项目启动项目计划项目评审项目监控项目收尾,问题,每个项目经理都在他自己的领域内努力工作，力争建立最优的项目过程来执行其项目和产生他能够实现的估计尽管其他团队在早些时候已经执行过类似的项目，并且他们的经验和数据能够极大地减轻项目经理的痛苦。但项目经理们不仅从头开始重新投资他们的规划工作，而且他们“计划”重蹈他们之前的项目经理犯过的同样的错误,解决方案,建立一个所有项目的管理人员都能够访问的公共知识库（institutional memory）过程数据库（process database,PDB）保存已完成项目的绩效数据。过程能力基准（pr
30、ocess capability baseline，PCB）概括各个项目的绩效，定量地规定遵循过程所能达到的结果范围。如果遵循相同的过程，就可以预测出项目的结果范围。过程资源（process asset）文档，诸如检查表、模板、方法以及所吸取的经验教训即总结以往经验的材料，它们能帮助项目经理和工程师有效地使用过程,PDB中保存的数据,项目特征名称、项目经理、业务部门、遵循的过程应用领域、平台、编程语言、DBMS目标、风险、团队规模项目进度和工作量项目规模代码行数(Line Of Code,LOC)；复杂度（简单/中等/复杂）；功能点（Function Point）故障在各种故障检测任务中发现的
31、故障数量在不同阶段增加的故障数从需求评审、设计评审、代码评审到单元测试及其他阶段中发现的故障数备注关于估计的备注（如：将程序分类成简单/中等/复杂三类的指标）关于风险管理的备注（如：风险认识在项目执行过程中的变化）,过程能力基准（PCB),过程的能力是指在遵循过程的情况下可对项目期望的结果范围；一个稳定的过程的能力可以由过程以往的绩效所决定。过程能力基准表示在某些时间点上过程能力的量化瞬态图软件质量；生产率；进度计划；工作量分布；故障引入率/排除率；质量成本,过程资源,指南、检查表和模板简化过程使用，减少工作量，提高生产率知识库项目管理计划,配置管理计划,进度计划,培训材料等需求设计编码规范评
32、审、检查和测试质量保证和生产率,软件配置管理（CM),对变更进行系统地控制管理计算机软件产品的进化的纪律给出程序的状态：何时开始测试或发行？处理并发变更；取消变更；防止未授权变更或删除提供需求变更申请和程序变更之间的可跟踪性取消需求变更；显示相关变更收集当前系统的所有源代码、文档和其他信息,配置管理机制,文件命名约定版本控制变更申请跟踪访问控制变更协调变更登记,配置管理过程,配置管理规划状态转移管理变更申请管理状态监督配置审计,配置项,需求规范、设计文档、源代码、测试计划、测试脚本、测试程序、测试数据、项目使用的标准（诸如编码标准和设计标准）、验收计划CM计划和项目计划等文档用户手册等用户文档
33、培训材料等文档合同文件（包括支持工具，诸如编译器或者内部工具）质量记录（评审记录、测试记录）CM记录（版本记录、状态跟踪记录）客户提供的任何产品或者购买的任何东西(如果将要成为发布的软件的一部分）,配置管理规划,确定配置项和规定用来控制和实现其变更的程序定义命名机制和编码机制，目录结构，访问限制，变更控制过程定义CC或CCB的责任和权限，配置项状态的跟踪方法，将配置项移入基准库的时机,状态转移管理,正在开发-正在评审-基线状态在状态变更时将配置从一个目录移到另一个目录，然后在完成变更后建立新版本。,变更申请管理,接受变更申请（影响分析之后）建立一种跟踪机制 检查需要进行变更的配置项 执行变更
34、注册配置项在项目的整个生命期内维护该项目,状态监督与配置审计,状态监督除了检查配置项的状态外，项目还必须检查变更申请的状态。配置审计的目的是确保项目执行确实遵循CM过程。,工作量与进度估算,项目工作分解结构(WBS)工作量估计进度估计进度计划,项目工作分解结构(WBS),将项目及其主要交付结果层层分解，划分成一些较小、更容易安排时间与费用等单元活动，这种方法称之为项目工作分解结构。项目工作分解结构有两种表达方式：图形式和清单式。,项目工作分解结构的方法,按项目的主要交付结果分；按产品本身的结构分；按实施项目的时间顺序分；按组织的职责分；,工作量估计,用多种方法进行估计，验证主要估计方法的正确性
35、，减少风险自底向上估计方法自顶向下估计方法用例点方法,自底向上估计方法,找出程序，并将程序分为简单(S)、中等复杂(M)和复杂程序(C)根据PCB求得S/M/C程序的构建工作量。用PDB中类似项目的数据定主S/M/C程序的构建工作量。用PCB中S/M/C程序的平均构建工作量。用项目特有因素优化S/M/C程序的构建工作量。用S/M/C程序的工作量及其程序数求得总的构建工作量。用PCB给定的工作量分布情况或者PCB中给定的类似项目，估计其他任务工作量和总工作量。基于项目特有的因素优化估计。,自顶向下估计方法,求以功能点为单位的软件的总规模。用项目专用能力基准、基本过程能力基准或同类项目的生产率数据
36、，确定项目的生产率水平。根据生产率和规模估计求总工作量估计。使用过程能力基准或者同类项目中的工作量分布数据估计各阶段的工作量。考虑项目特有的因素，优化工作量估计。,用例点方法,事务定义为任务的原子集，要么全部执行，要么不个都不执行。根据包含事务数将用例分为简单用例(1-3)、中等复杂用例(4-7)和复杂用例(7+)。简单用例分配因子为5，中等复杂用例分配因子为10。而复杂用例分配因子为15。根据应用中用例因子的加权和求得总的未经调整的用例点（unadjusted use case point,简称UUCP）,用例点方法,根据技术因素及其权重表调整原始UUP以反映项目的复杂性和项目工作人员的经验
37、（技术复杂性因子TCF）。根据团队的环境因素及其权重表，并用05评定每个因素，计算出环境因子（EF)最终的用例点（use case point，简称UCP）：UCP=UUCPTCFEF,技术因素及其权重表,TCF=0.6+(0.01TFactor),环境因素及其权重表,EF=1.4+(-0.03EFactor),环境因素及其权重,对于经验有关的因素，0表示没有该主题的经验，5表示专家水平，而3则表示平均水平。对于积极性，0表示没有项目积极性，5表示积极性高。而3则表示平均水平。对于需求的稳定性，0表示非常不稳定的需求，5表示不变的需求，而3则表示中等稳定程序。对于兼职型工作人员，0表示兼职型技
38、术人员，5表示全职工作人员，而3则表示平均值。对于编程语言的难度，0表示易掌握的编程语言，5表示非常难的编程语言，而3则表示一般难度的编程语言。,用例点方法,进行工作量估计时，一般在整个生命期中为每个UCP分配20人时，由此得出的估计是很粗的。需要对它按如下步骤做进一步精化。计算有多少个因素的值小于3，有多少个因素的值大于3。如果值小于3的因素总数很少，则每个UCP分配20人时是合适的。如果有很多，则每个UCP分配28人时。换句话说，每个UCP分配2028人时，而项目经理可以根据各种因素决定使用哪个值。,进度估计,即估算完成各个活动所需的时间。影响活动工期的因素有：意外事件小组成员的工作熟练程
39、度与工作效率资源供应情况活动历时估算方法类比法专家判断法资料统计法资料严重不足时，可用经验公式估算大概的工期：（乐观的估计+4*最有可能的估计+最悲观的估计）/6,绘制优先网络图,召集项目组的主要成员参加，集体绘制；确保每一个活动都有前任活动与后续活动；暂时不要考虑活动需要多长时间；用及时贴、胶带纸或磁铁卡片等既可固定又可方便移动的道具。,关键路径,在项目网络图中，从左到右把时间相加，时间最长的那条路径就是关键路径，它表明了完成项目所需的最短时间关键路径在实施项目的不同线路上通过顺推（左到右）和逆推（右到左）两种方式来确定在非关键路径上的活动，在其最晚的完成时间，也就是及时贴右下角的数字大，它
40、们之间的差即为浮动时间。关键路径上的任务分配给最能干、最负责任的人员；有浮动时间的活动，训练新人，运用新技术在项目进行过程中，关键路径有可能由于活动的推迟而发生变化,进度计划,建议的进度应当在以人月为单位的总工作量的平方根左右；例如，如果估计的工作量为50人月，则一个由78个专职工作78个月的进度计划比较合适。一般来说，设计大概占进度的40%（20%用于概要设计，20%用于详细设计），构建占40%，而集成和系统测度占20%。设计、构建、集成和测试阶段的人力分配分别是1：2：1（因此这些阶段的工作量分配为1：2：1）。,质量规划,软件质量：已交付软件中每个单位规模的故障数。软件故障：某种使软件表现出与客户的要求或者需要不一致的方式进行运转的问题故障可以在软件过程的任何阶段引入；故障排除成本与故障潜伏时间成正比；在每个可引入故障的阶段之后执行质量控制故障排除任务包括需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试,质量管理的量化,故障排除效率（defect removal officiency，简称DRE）：QC任务检测到的故障数占现有总故障数的百分比。故障预测（defect predition）。这种方法根据已交付软件的故障密度设定质量目标。,
