项目控制

项目控制1.为什么要控制?事情不按计划进行：-范围改变-活动的估计值不同于实际值-实际问题：*硬件不工作*通讯连接-资源*辞职*突然离去/意外事故/生病-未预计的附加活动变化“管理的中心问题是更好地理解变化，并从变化中抽出有用信息。”跟踪的数据要分析，要用策划和控制策划建立目标，控制跟踪现实跟踪时将实际值与计划值相比较如果现实与计划不一致，现实必须优先控制要求不断的修定开发计划监督与控制的目的是保证在即使偏离计划时仍能实现项目的目标测量的重要性测量是控制的载体没有控制软件工程就不是有效的工程学科仍然是手工劳作（艺术品）从数据中学习·控制：搜集数据分析数据解决问题•P：计划将要作什么，并预计效果D：作；执行计划C：检查；评估结果，并从结果中学习---控制A：行动；真正着手去作•“PDCA是管理的核心，即确保今日的工作并开发明日更好的工作方法。”•检查的重要性：“把已有的决策当作是从中吸取经验教训的实验，那就把PDCA的所有步骤落实。”2.一般如何跟踪跟踪的四个问题跟踪中要解决以下四个问题：·确定跟踪对象·采集信息·分析信息·报告信息（1）测量量的确定要采集的度量包括与技术有关的和与管理有关的在确定要采集的度量时可参照HP的经验：-从工程实际出发，管理人员和工程人员总结自己工作中实际需要的度量-采用目标/提问/度量（G/Q/M）的框架：*分析目标*提出要解决的问题*从问题中提出度量HP的经验尽早确定所要采取的度量，如FURPS采取目标—提问—度量G1G2Q1Q2Q3Q4M1M2M3M4M5例子目标：减少工作量和缩短进度其中一个问题是：当要求更改代码时，何时作更改，何时不作更改？他们分析得出的度量是：M1:问题发生率M2:缺陷密度M3:代码稳定性M4:复杂性M5:要更改的模块数起步核心测量SEI建议DOD的软件组织采用四个起步核心测量-软件规模-工作量-进度-缺陷监控什么在项目中受监控的典型方面：-进度-工作量-总成本-质量-范围(scope)-风险-职员流动-项目的其它被标识的主要目标*技能水平改变过程度量过程度量量化过程或开发环境例子：-生产率-质量-资源度量-缺陷插入率-缺陷及其消除率产品度量产品度量独立于其过程例子：-规模-可靠性-质量（也是过程度量）-代码的复杂性-功能性过程方法作工作的规程检查工作的规程返工输出产品测量过程测量标准工具输入过程的测量与分析为什么要采集过程性能数据？要管理过程就需要：能预测过程的未来性能减小过程结果的偏差人们不能控制哪些未测量和理解的东西这是连续过程改进的基础（2）定义度量的原则通过G/Q/M方法能确定出与经营目标密切相关的测量和度量。在定义这些度量时，必须考虑以下原则：·可重复性：其它人能重复测量，得到同样的结果；·利于交流：对记录的测量结果，其它人能精确地知道它包含什么，不包含什么。测量的单位是什么。数据数据是控制的核心。管理改进必须基于测量结果为使数据分析有用，必须了解数据的含义及如何对它作有意义的分析开始时仅采集一小组有用的数据管理者需要保证注意力明显地集中在项目所有的关键方面，包括那些难于测量的，不能只关注那些易于测量和跟踪的方面（3）测量量的采集任何等级都必须采集度量多数度量存在于开发工作中，必须人人动手采集过程度量等有瞬时的特点，如不及时采集，无法补救要预先确定需采集的最小集合，再不断补充与谁有关？监控要求群组所有成员参加从每个群组成员的个人计划开始在高层次上，处理经过整理的/更为一般的问题如何能采集到正确的数据？对事不对人采用工具（4）项目报告项目受监控、控制的等级依赖于管理层次-项目经理要求每日更新-其它开发经理（例如技术管理者）可能满足于月更新采集的数据要及时、正确、详细3.有关SPTO基本的监控监控活动是否按计划进行监控缺陷是否均已解决监控问题是否均已处理L2:基本的监控L3:建立监控的门槛值，监控风险……L4:定量监控跟踪基线SPTO针对项目计划进行跟踪项目计划中列出了跟踪要求，包括被跟踪的主要工作产品、跟踪频度、跟踪机制、跟踪内容-其跟踪内容除了规模、成本和工作量、进度外，还有风险、资源（包括关键计算机资源），技术活动和纠正措施计划中列出了被跟踪量的估计值或预测值，它们作为跟踪的基础跟踪时，将采集的实际值与计划中的估计值相比较，来确定进展。它们有时被称为跟踪基线对软件工程技术活动的跟踪活动9中提出对软件工程技术活动进行跟踪，这是等级2中唯一与工程技术活动有关的实践。-要求软件工程组的成员定期向其直接领导报告技术状态，包括活动的进展和问题；-将其交付的供后续工作用的工作产品的内容与计划做比较；-报告任何工作产品中的问题，并建立文档；-跟踪问题到问题结束。纠正措施如果计划和实际进展间存在明显偏差，就要采取纠正措施。这首先要做评价和判断。评价：评价项目性能和项目相对计划的状态，决定偏差是否明显，是否需要采取行动。要分析产生偏差的原因。当然首先必须明确定义“明显”的含义。判断：采取哪种行动。措施项有两种可能：-改变正在进行工作的方式；-调整计划；跟踪方式跟踪软件工程技术活动，必要时采取纠正措施（如定期报告机制）软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进度、计划、性能和问题按照文档化规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果（如同行评审）各种报告和表格跟踪和监控方式填写数据采集表格项目人员定期向其直接领导报告,其主要方式是填写数据采集表格（如周报，周状态报告）它们既包括相对计划的进展（管理方面），又包括技术进展和技术问题（技术方面）一般SPTO需设计和提供适用的对各类人员的跟踪表格。内部评审内部评审:软件项目组内部定期进行的评审目的是跟踪技术进展、计划完成情况、当前状态和问题一般一线软件经理和软件作业领导参加评审，需要时，和软件经理和其他软件经理一起评审正式评审里程碑处的正式评审。目的是评价跟踪的结果，进行监控而不是跟踪评价时使用的材料必须经过有关软件经理的评审和批准-分析软件活动的约定、计划和状态；-识别出重大问题、相应的措施和做出决策，并建立文档；-分析软件项目风险；-必要时，做出修订软件开发计划的决定。4.跟踪表格项目报告—进度表周工时表在项目进度上，作状态标记(PERT/CPM)周状态报告进度指示器—全面监控活动层监控的甘特图周工时表WEEKLYTIMESHEETName:HAROONRASHIDWeek:19-May-1997to25-May-1997Hoursworked--------------ProjectActivityMonTueWedThuFriSatSunTotNormalHoursPR032CDM1P1-Coding88824PR032CDM1P1-Review44PR032CDM1P1-UTP481200SubTotalNormalHours888880040OvertimeHours0PR032CDM1P1-UTP212500000SubTotalOvertimeHours000212050TotalHours8881092045个人周状态报告WEEKLYPROGRESSREPORTName:Week:ActivityStatusActivityPlannedDateforCompletionActualDateofCompletionStatusExpectedDateofCompletionExpectedRemainingEffortPerson-hoursCommentsPlanforNextWeekAnyProblemsExpectedSuggestionsforImprovement进度监控-甘特图Days-----------------------------CodeActivity/ItemEffortResPDaysDDM1P1P1DetailedDesignPlan5PRAct6PRCDM1P1P1CodePlan12SPAct11SPUTM1P1P1UnitTestPlan6SPAct3+SPDDM1P2P2DetailedDesignPlan3PRAct3PRCDM1P2P2CodePlan4PRAct4PRUTM1P2P2UnitTestPlan2PRAct进度指示器—全面监控到该日止已完成所计划的活动数进度指示器1=—————————————到该日止计划要完成的活动数到该日止已完成的在关键路径上所计划的活动数进度指示器2=———————————————到该日止计划的要完成的在关键路径上的活动数项目报告—工作量周工时表进入实际时间，预计遗留工作量周状态报告工作量指示器-用于全面监控工作量表活动层监控工作量表（活动层监控）OverallEffortMonitoringTableProject:StatusasOn:______________12345=3+4(5-2)/2ActivityPlannedActualExpectedTotalVarianceEffortEffortRemainingAct+Exp%P-DaysP-DaysP-DaysP-DaysTOTAL:工作量指示器-用于全面监控到该日为止总的实际人-小时工作量指示器1=——————————总的所计划的完成活动的人-小时总的所预期的（遗留）+实际的人天工作量指示器2=——————————总的所计划的人天项目报告—成本成本报告类似于工作量成本分量：-工作量（可能分别计算正常的和加班的）-出差-硬件-软件-通讯项目报告—质量缺陷日志/测试日志ItemWise质量记录缺陷陷漏矩阵质量指示器ItemWise质量记录OverallQualityTableProject:StatusasOn:______________123456ItemQCTypeTotalTotalVarianceNumberExpectedActual%ofDefectsDefectsCyclesTOTAL:缺陷泄漏矩阵DEFECTLEAKAGEMATRIXProject:AsOn:PhaseOriginRADesCodeSysAccpWarrTotalPhaseFoundV&UTTestTestAnalysisDesignCode+UTSysTestAccTestWarrantyTotal评审的重要性（泄漏缺陷）需求评审设计评审功能测试静态分析结构测试251510需求缺陷设计缺陷编码缺陷返工的费用呈指数式增长质量指示器—全面监控质量指示器1=对已完成的QC作业，总的实际缺陷数------------------------------------------------------------------------对已完成的QC作业，总的预期缺陷数质量指示器2=阶段内发现的总缺陷数------------------------------------------所发现的总缺陷数项目报告—范围更改请求范围变化指示器范围变化指示器由于更改请求所造成的总的工作量(全部经批准的更改请求)范围指示器1=-------------------------------------------到该日为止总的实际工作量对已批准的，更改请求的总的花费范围指示器2=----------------------------所收到的总的更改请求所收到的更改请求数范围指示器3=---------------------------------时间(所完成的期间或总的计划的期间)缺陷与发现阶段发现的阶段缺陷的例子需求规格说明评审-不正确的或太强的假定-不完全的外部界面说明-过程流不清晰-需求不可跟踪-含糊性-不完全性项目计划评审-不恰当的工作量或进度估计-风险评估有问题-不恰当的人力安排-计划不完全…………缺陷类别缺陷类别例子逻辑标准多余的代码用户界面性能重用性设计问题存贮管理缺陷文档缺陷不一致性跟踪性可移植性缺