项目度量与分析指南-V

项目度量与分析指南修改说修改说明版本号修改人核准人 6.1度量目的 86.2度量内容和方法 86.3分析指南 8 8.1度量目的 118.2度量内容和方法 118.3分析指南 11 9.1度量目的 149.2度量内容和方法 14 14 169.3分析指南 16 SQA度量 21 3.1质量成本分析 213.2缺陷分布分析 22 项目度量与分析指南软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。此指南详细描述软件过程相关的度量内容，包括度量项的本文适用于本公司所有软件项目。术语、缩写词Project的一次性活动。Project的一次性活动。Measure，对一个产品过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。Meatric，对一个系统、构件或过程具有的某个给定属性的度的度量度量项对项目的规模、进度、工作量等度量项进行估算，并记载于项对项目的规模、进度、工作量等度量项进行估算，并记载于项在项目计划中制定度量数据收集和量化分析与控制的策略；比较和分析项目级的度量数据，在必要时采取纠正措施；保证项目组依照本指南中的要求，正确记录各项度量数据。协助项目经理制定度量数据收集和量化分析与控制的策略；收集项目执行数据，填写项目度量表；进行统计分析，提供决策支持。始填写时间记录表，执行评审和测试工作，追踪软件产品缺定期发布公司级软件项目生产率、工作量分布、各度量指标上下控制界限等数据，供项目组参考；在项目结束时收集各个项目的汇总数据，丰富并修正公司级过程财富库。项目经理项目管理员项目组成员5过5SEPG从公司质量方针和质量目标出发，根据本公司现阶段软件项目和软件开发的特点，以及软件过程改进的目标，经过权衡，决定选择需求、规模、进度、工作量和质量作为公司软件项目度90%；3、合同履行率三年内达到80%。软件项目的实施，要确保实现上述质量目标，同时也要保证公司产值的增长和盈利目标的实现。SEPG需求、限定规模、保证进度、合理分配工作量、保持优良质量等方面还存在一些缺陷，所以需要通过这些项目属性的度量、分析和监控，有效改进软件过程，达成公司的上述质量目标和盈利目标。需求的稳定度在极大程度上影响项目的规模、工作量和进度。目前本公司软件项目对需求的分析和控制比较薄弱，开发人员付出了加倍的努力，用户满意度仍不理想。因此有必要对项目需求进行有效的度量和管理，使得开发人员和用户对需求保持一致的认识，并控制需求的变化。项目的规模是决定软件项目成本的最基本因素，是估算工作量和进度、计算生产率、缺陷密度及其它项目评估指标的基础。对规模的有效估算、跟踪和控制，一方面使得项目得以按照预定计划顺利开展，另一方面也保证公司盈利目标的实现。保证软件项目的进度是控制项目成本，赢得用户满意的关键。同软件行业的普遍现象相一致，本公司软件项目容易在进度上发生问题，一些项目久拖不决，引起项目成本攀升，影响款项回收，并造成用户信任度下降。所以，需要使用MSPROJECT等管理工具，对项目的进度进行定对工作量的正确估计和控制，有利于为项目配置合适的人力资源，也便于控制项目成本。本公司软件开发的生命周期以瀑布模型为基础，在实际执行中存在明显的重视编码、比较忽视设计、严重忽视需求分析及软件测试的问题。预先针对需求分析、设计、编码和测试等开发活动，合理分配工作量比例，能够校正这一偏颇。统计汇总各个阶段、各项活动工作量在总工作量中所占比例，并与计划比例相对照，可以发现项目执行上的偏差，总结经验教训，有利于逐步形成适合公司开发团队特点的最佳工作量组合。软件工程的最高目标就是产生高质量的软件产品。项目级的质量度量主要是对于缺陷或错误的测量，通过观察各个阶段引入缺陷和消除缺陷的数量分布，可以发现本公司开发过程的薄弱环节；通过统计各个阶段花费在消除缺陷上的工作量，可以将各个阶段的质量成本投入调整到最合理的状态；通过对软件质量保证(SQA)过程中不合格项的统计，可以发现项目组对ZDSSP的遵从程度，预防缺陷。本公司软件项目普遍存在以下两种现象：1、需求和设计工作草率，匆忙开始编码；2、评审过程缺乏，或者不够高效和正规。这些现象使得项目早期发现的问题不够多，大量的缺陷是在编码、测试阶段甚至在发布后发现的，相应地修正缺陷所花地代价很高。因此，项目组应测量在评审和测试上所花费的工作量以及相应的缺陷数量，以及对这些缺陷进行修正的返工工作量，通过对比来判定需求和设计工作是否草率，并决定合适的评审力在项目启动会议之后，项目度量工作就正式展开，项目组成员开始针对该项目填写时间记录项目经理在项目计划阶段要针对项目的特点制订相应的度量计划，制定度量数据收集和量化分析与控制的策略，包括：根据项目的特点决定是否需要对公司规定的标准度量项进行裁剪；根据项目的特点决定是否需要增加特别的度量项或对标准度量项的收集分析周期进行变设定的各度量项偏离值的上下限，设定适合项目自身的偏离值上下限；预先设计度量项超出控制范围时要采取的措施。项目度量计划作为软件项目度量表的一个单独的工作表，由项目经理填写。在项目实施的过程中，项目管理员按照预先设定的周期收集各项度量数据，进行初步的统计分析，填写软件项目度量表。项目经理根据项目度量表比较和分析项目级的度量数据，在必要时采取纠正措施，如修正项目计划、进行相关培训等。项目结束时，项目经理汇总项目的各项度量数据，将过程数据库中的内容集成到项目结案报项目结束之后即进入维护阶段，技术支持人员随时将软件缺陷提交到公司缺陷跟踪系统，软件开发人员针对缺陷进行定位、修改和测试，将工作量记录在时间记录表之中并最终关闭缺陷。项目管理员收集缺陷数据和返工工作量，修改软件项目度量表。收收集规模及计划变更数据项目管理员收集需求数据项目管理员收集EV数据项目管理员收集进度数据项目管理员收集工作量数量项目管理员收集产品缺陷数据项目管理员收集SQA数据项目管理员项目管理计划需求跟踪矩阵项目EV报告项目进度计划时间记录表产品缺陷记录表SQA不合格记录表项目启动制定度量计划PM度量计划度量分析项目管理员,PM软件项目度量表数据收集项目度量与分析6需求度量跟踪分析需求的稳定性能够体现项目组管理和控制软件需求的能力。不稳定的需求将带来负面影响，例如软件产品质量下降、项目成本增高、项目进度延迟等。人频度数据来源新增需求的数目项目管理员每周/每月变更请求本周期新增需求的数目删除需求的数目项目管理员每周/每月变更请求本周期删除需求的数目修改需求的数目项目管理员每周/每月变更请求本周期修改需求的数目需求变更数目项目管理员每周/每月本周期新增、删除、修改需求的数需求总数目项目管理员每周/每月用户需求文档变更请求初始建立作为基线的需求的数目，或者：前一周期需求的总数＋本周期新增需求数目－本周期删除需求的数目需求变更成本(人项目管理员每周/每月变更请求本周期需求变更需要耗费的工作量需求变更成本汇总(人时)项目管理员每周/每月项目自启动以来在需求变更上耗费和需求变更可能直接导致规模的增长、进度的延迟、成本的增加以及返工。项目组应周期性地度量需求变更(包括新增、修改和删除需求)和需求总数的变化，来控制需求变更并采取相应地2008004000123456789101112需求总数需求变更数上图表现了需求的稳定度，两条线分别表示每周需求总数的变化以及需求变更数目的变化。假6周需求变更数都有明显增长，在第7周后需求趋于稳定。说明在需求基线化评审结束之后相当一段时间需求仍然不稳定。更成本12001000800变更成本600变更成本汇总4002000123456789101112上图表现了变更成本的变化，该图显示变更成本在第3周之后迅速攀升，在第9周后趋于稳定。比照需求变化趋势曲线，发现在第7周后需求变化较少，但变更成本仍然攀升，说明在这段时间引入了影响较大的需求变更。大量的需求变更是可能导致项目失败的潜在风险。对于频繁变更的需求，项目组可能要采取诸如重新分配资源及重新估算规模、工作量和进度等措施。并且项目组可能要分析需求变更的具体原因(如：误解、歧义、不完整、不正确)，需求变更的类型(如：功能方面、性能方面或界面方面等)，通过详细的分析，判定需求频繁变更的根本原因，并采取具体的行动。7规模度量规模是项目的基本度量项。它用于估算工作量和进度，计算生产率、缺陷密度及其它项目评估频频度数据来源说明在里程碑处，或合同或建议书，估算或测量软件的规模者需求变更导致SRS,历史数据规模发生重要变化时在里程碑处，或自动计算者需求变更导致规模发生重要变化时内容责任人(用例点UCP)规模变化率项目管理员阶段变化率：(本期软件规模－上期软件规模)/上期软件规模基准变化率：(本期软件规模－SRS完成时的估算规模)/SRS完成时的估算规模监控有效规模与估算规模间的偏差。如果需要，重新估算工作量和进度。规模规模控制图2345规模变化率(相对于上阶段)控制下限控制上限规模变化率(相对5.00%0.00%-5.00%-10.00%在里程碑处(如需求阶段、设计阶段)以及大的需求变更发生时，或进行项目情况汇总时，项目经理使用规模控制图来分析规模偏差并监控产品有效规模的偏差。。如果规模偏差超出上下控制限范围，则分析原因并采取相应措施偏差超过控制限的可能原因和措施如下:如如果规模偏差超出了上限可能的原因新增了太多的需求.采取的措施重新估算并做计划如果规模偏差低于下限如果规模偏差低于下限可能的原因删除了太多的需求采取的措施重新估算并做计划8进度度量进度度量监控项目是否正常进行，使用挣值分析法测量项目绩效，判定各个重要活动的开始、结束日期和持续时间是否正常。在MSPROJECT中进行挣值分析，将结果(计划值PV、挣值BAC、完工估算EAC、进度指数SPI、成本指数CPI)复制到项目度量表收集重要活动的进展情况，并对后期的进展作出估计。将结果填入项目度量表数据来源项目计划时，以项目进展周报及每周挣值分析重要活动的规划人项目管理员项目管理员频度每周/每月挣值分析是综合范围、计划、资源，测量项目绩效的一种方法，它比较了计划工作量、实际挣得多少与实际花费成本，以决定成本和进度绩效是否符合原定计划。14,000,00012,000,00010,000,0008,000,0006,000,0004,000,0002,000,0000123456789101112计划值(PV)挣值(EV)实际成本(AC)完工预算(BAC)完工估算(EAC)上图显示，在第4周，项目的挣值明显超过计划，进度加快。但是从第2周开始项目实际成本增长很快，在第4周成本跳升。项目的完工估算也因此超过预算。总体看来，进度的提高以成本增加为代价，项目经理可能要对两种因素进行适当权衡。效指数2.502.001.501.000.500.00123456789101112进度指数(SPI)成本指数(CPI)上图显示项目的进度指数和成本指数的变化，进度指数到达2.0的高度，显示进度很快；成本指数也稳步上升，接近1.0，显示虽然实际成本超过了挣值，但尚未偏离过多，并且仍呈上升之势，总体看绩效状况令人满意。挣值分析对项目进度的表征是宏观的，它将所有活动的地位等同看待。实际上项目中有些重要活动(特别是关键路径上的活动)的进展将最终决定项目是否能如期完成。所以有必要对重要活动进行跟踪，定量监控实际进度与规划进度间的偏差。如果必要，重新估算并调整计划。使用MSPROJECT绘制的甘特图可以直观地表达这些活动的进度。项目经理使用甘特图比较每项活动的实际开始/结束日期及计划开始/结束日期，并判定每项活动的当前状态，以便监控项同时，利用软件项目度量表中记载的重要活动的计划持续时间和实际持续时间，也可以观察到进度跟踪进度跟踪图30252050重要活动日日完常完常完成数成数完成需主据主据成第求完文输完完文输完完首二收成件入成成件入成成次次完完成成最初估算最近估算天作工上图显示了每一项活动的持续时间是否与计划相符。如果偏差超出控制界限，则分析原因，采取措施，跟踪进度，直至进度得到控制。关于偏差的可能原因和采取的措施，参见下表。采取的措采取的措施安排培训重新派人重新估算或申请资源与客户磋商发布日期标识需要额外工作量的主模块并重新估算随后的活动与相关人员磋商降低项目目标再次规划和排列任务并删去保留的时间说明问题启用后备资源重新规划并保证关键资源可以获得标识原由并作修改改变项目进度安排采用的措施重新估算重新分配资源评审完成的任务，规划剩余任务的进度如果进度偏差超出了上限可能的原因人员缺乏应用领域知识或软件开发经验新的技术领域低估资源优化不充分关键资源缺少早期阶段的输出不合格导致返工如果进度偏差小于下限可能的原因项目组富于经验任务尚未完成系系统测试设计系统设计修改系统测试9工作量度量追踪工作量的目的是评估项目人力是否充分以及分配给每个阶段的工作量是否合适。工作量度量通过活动和阶段两个维度收集当前所耗费的工作量。工作量数据统计的主要来源是时间记录表，如果开发人员使用MSEXCEL填写时间记录表，则L内容(依活动划分)责任人需求工作量项目管理员概要设计工作量项目管理员详细设计工作量项目管理员编码及单元测试工作项目管理员量集成测试工作量项目管理员系统测试工作量项目管理员度每周每周每周每周每周每周数据来源时间记录表时间记录表时间记录表时间记录表时间记录表时间记录表1.修改需求分析报告2.更新需求跟踪矩阵1.撰写概要设计报告2.更新需求跟踪矩阵1.修改概要设计报告2.更新需求跟踪矩阵1.撰写详细设计报告2.更新需求跟踪矩阵1.修改详细设计报告2.更新需求跟踪矩阵2.更新需求跟踪矩阵改概要设计开发概要设计修改详细设计开发详细设计修改单元测试及单元测执行单元测试及其回归测试试的回归测试代码修改集成测试设计集成测试设计修改集成测试2.更新需求跟踪矩阵1.修改集成测试设计2.更新需求跟踪矩阵执行集成测试集成测试的回归测执行集成测试的回归测试试执行系统测试系统测试的回归测执行系统测试的回归测试试时间记录表时间记录表验收测试设计验收测试设计修改验收测试工作量项目管理工作量发布后维护工作量软件配置管理工作量用户文档工作量培训工作量软件质量保证工作量审工作量项目管理员项目管理员项目管理员项目管理员项目管理员项目管理员项目管理员项目管理员每周每周每周每周每周每周每周每周验收测试执行验收测试验收测试的回归测执行验收测试的回归测试试产品交付软件部署、培训和试运行时间记录表项目启动项目结案计划撰写计划评审计划修改项目跟踪撰写软件开发计划修改软件开发计划度、风险、需求、组间协调和关键事项部署软件度量数据，执行定量分析和控制活动写项目周报、里程碑和项目总结报告，小组成议，项目每周例会，部门每周例会，里程碑评时间记录表错误(BUG)分时间记录表维护专题开发错误修正试撰写配置管理计划实现配置管理发布软件产品撰写用户文档修改用户文档时间记录表配置计划配置实现产品发布用户文档撰写用户文档修改课堂学习时间记录表时间记录表审计软件工作产品并评审软件过程SQA时间记录QA计划表QA实现同行评审记录需求评审设计评审代码评审代码评审测试计划评审测试用例评审用户文档评审客户电话讨论答疑客户问题解决技术交流,技术支持与项目有关的活动与项目无关的活动1.外部同行评审(应包含在2.外部组间协调3.对项目的其它支持(技术支持、培训等)2.空闲时间活动已经耗费的工作量/该活动估算工作量技术支持工作量其它计划外工作量工作量耗费比例时间记录表时间记录表项目中工作量包括正常工作和加班。目前本公司所有软件项目的生命周期均以瀑布模型为基础，开发过程可以划分为需求开发、概考察各个阶段所耗费的工作量对于本公司软件项目开发计划的制订和软件过程改进具有重要意义。所以公司开发人员时间记录表中对每一项任务，要求在填写活动类型之外同时指明它所属开发人员填写时间记录表时要注意阶段和活动划分的区别。例如，在需求开发阶段，可能从事行评审、项目计划、项目管理、配置管理、培训、软件质量保证等。工作量的分析主要包含两个方面的内容：按照活动和阶段，周期性地监控实际耗费的工作量，并与计划投入的工作量相比较，及时分析项目中不同活动和不同阶段的计划工作量分布和实际工作量分布。工作量跟踪(按阶段工作量跟踪(按阶段)0PIRAHLDLLDCUTITSTDELCLSMT估计值实际值上图是在集成测试完成之后对工作量的统计分析，数据表明：1、详细设计的实际工作量大大小于计划工作量，可能的原因包括：高估了详细设计的复杂度、详细设计评审工作减少、详细阶段配置管理工作减少、SQA工作减少等；2、除了编码阶段的工作量略有超出(可能与详细设计的工作不充分有关)之外，其它阶段的工作量都不大于预期，表明团队工作效率较高。工工作量跟踪(按活动)5004003002000RAHLDLLDCUTITSTDELPRPMSUPMTUDSCMSQATRNMISC估计值实际值上图是同一时间按照活动分类对工作量的统计分析，数据表明详细活动工作量的偏差在允许范围之内，同行评审和配置管理的工作量耗费相对于目前而言比较正常，软件质量保证活动工作配在作项目计划时，项目经理应该参考公司SEPG定期发布的软件项目工作量分布状况，结合项147431199540190152108164工作量分布计划(按活动)49621397287433235工作量分布计划(按阶段工作量分布计划(按阶段)9555340PIRAHLDLLDCUTITSTDELCLSMT50224125530739514740在项目结束时，项目经理按活动和阶段总结实际的工作量分配，判定估算的工作量是否合理。如下图所示。这些数据可以为将来的项目提供参考。工工作量实际分布(按照活动)3.80%0.00%7.01%17.82%0.00%实实际工作量分布(按照阶段)26.29%20.56%RAHLDLLDCUTITSTDELCLSMT10质量度量质量度量的目的在于为产品质量提供具备适当可见性的管理，质量度量覆盖评审和测试过程，以及软件质量保证(SQA)过程。数据来源数据来源人频度据工作量各阶段评审发现项目管理员的不同严重程度缺陷的数目项目管理员各阶段测试返工项目管理员工作量每周每周每周每周每周评审表单时间记录表评审表单时间记录表时间记录表相关阶段包括需求开发、概要设计、详细设计和编码及单元测试。评审总工作量包括准备评审材料、进行评审和问题确认的相关阶段包括需求开发、概要设计、详细及单元测试。相关阶段包括需求开发、概要设计、详细及单元测试。相关阶段包括集成测试、系统测试和验收测试。测试总工作量包括测试计划和测试用例准备、执行测试及撰写测试报告的时间相关阶段包括集成测试、系统测试和验收各阶段测试发现项目管理员的不同严重程度缺陷的数目发布发布后维护阶段项目管理员据发布后维护阶段项目管理员作量每周每周每周软件问题汇总相关阶段包括集成测试、系统测试和验收报告测试。软件问题汇总报告软件问题汇总包括重现、分析定位、修正的总时间报告COQ(质量成本，人项目管理员COPQ(不合格质量成项目管理员每周每周各阶段评审或测试总工作量与问题返工工作量之和收集各阶段问题返工的总工作量收集相对于引入或发现阶段的缺陷数据，得到缺陷分布状况。内容责任人频度数据来源每个阶段引入缺陷和消项目管理员除缺陷的数目各阶段发现的不同严重项目管理员程度缺陷的数目各阶段发现的不同类型项目管理员缺陷的数目评审表单收集每个阶段引入和消除的缺陷数目，填软件问题汇总写在以阶段为维度的二维表格之中报告评审表单收集每个阶段引入的各种严重程度的缺陷软件问题汇总的数目，填入度量表报告评审表单收集每个阶段引入的各种类型的缺陷的数软件问题汇总目，填入度量表报告每周每周每周质量质量成本内容责任人频度数据来源描述新增不符合项数目项目管理员每周SQA周报包括与过程和工件相关的不符合项已解决不符合项数目项目管理员每周SQA周报收集本周期已解决的不符合项的数目当前未解决不符合项数项目管理员每周自动计算上周期不符合项数目＋新增不符合项数目－已解决不符合项数目质量成本分析通过对评审、测试和维护阶段的缺陷数目及相关工作量的跟踪，达成以下效果：跟踪缺陷的识别和解决并用以进行日常管理；监控同行评审和测试的成效，保证同行评审和测试的效果；跟踪质量成本以及不合格质量成本，掌握在评审和测试工作量投入上的平衡。同同行评审阶段评审总工作量一级缺陷数目二级缺陷数目三级缺陷数目四级缺陷数目返工工作量RA1950005203529合计3 (包含2个一级缺陷)，返工工作量却高达85.5，这种情况表明问题发现得越早，付出的代价就越小。数据表明，前期的评审工作还应该加强，以发现更多的缺陷，特别是尽早发现严重缺8OPQ00STDELMT4339.511RAHLDLLD0CUTIT0如上图所示，项目在进行系统测试之前，质量成本一直在100以下的较低水平，在系统测试阶段，质量成本突然跳升。这种状况可能的原因是：1.省略了集成测试阶段，导致缺陷发现较晚；2.前期的评审工作投入不足，未能发现解决较多问题，导致后期工作量加大。数据显示，质量成本在整个周期中未能保持平衡，如果早期对评审多投入一些工作量，项目总体质量缺缺陷分布(各阶段引入缺陷总数)HLDLLDCUTITSTDELMT在项目进行过程中，项目经理周期性地考察每一阶段引入的缺陷占缺陷总数的比例，以了解整个软件开发过程中缺陷的分布状况。上图显示，编码阶段的缺陷占了60％，说明前期需求开发