1、第18章 项目管理概念,主要内容,管理涉及的范围 人员 产品 过程 项目 W5HH原则 关键实践 小结,软件项目管理 (Software Project Management),软件（项目）经理管什么？,计 划,预算,组 织,进 度,标 准,1. 成本估计(Cost Estimation), 静态：Effort = f (length of code) 代码行技术：每行代码的平均成本 源代码行数 任务分解技术：人力 工资, 标准值法(Expert Judgment),请多位专家估算程序的最小规模 a ，最可能的规模 m，和最大规模 b 。以三组平均值估算程序规模：,1. 成本估计,1. 成本估
2、计,然后根据标准生产率(standard productivity)，即每人每日可开发程序长度，来估算工作量：,这里C为修正系数，反映其它因素对开发工作量的影响： C = 1 + 0.1 n, COCOMO (Constructive Cost Model): Boehm (V2.0, 1995),MM = C K L O C a ,Man-Month,Size = kilo-code,Cost driverinfo,V2.0中已改为,(5) 经验公式,1. 成本估计,2、效益估计(Benefit Estimation) 例：假设某软件生命周期为5年。现在投资20万元，平均年利率3%。从第一年
3、起，每年年底收入4.2万元，问该项目是否值得投资？,2 成本/效益分析(Cost/Benefit),2 成本/效益分析,到第5年底结算时： 投资额 = 200000(1+3%)5 231855(元) 收入 = 42000 (1+3%)4+ (1+3%)3+ (1+3%)2+ (1+3%)+1 222984(元),不合算！,2 成本/效益分析,衡量工程价值的经济指标有： 纯收入= 折合现价的总收入 - 当前投资额=, 投资回收期 例：第6年底可收回, 投资回收率：设为j,2 成本/效益分析,3. 进度计划 (Software Plan),1、Gantt Chart（横道图）,优点：简单，能动态地
4、反映开发进展。,缺点：难以反映多个任务间的逻辑关系。,2. 进度计划,2、PERT (Program Evaluation & Review Technique )和CPM (Critical Path Method),例：开发三个模块A、B、C。A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。,(1) 标出 Lasting Time,(2) 标出 EST: = 从起点始，所有进入事件的 EST+LT 中最大的,(3) 标
5、出 LST: = 从终点(EST = LST)始，所有离开事件的 LSTLT 中最小的,(4) 标出 ST: = 终点LST 起点EST LT,(5) 标出Critical Path: 即EST = LST的所有事件组成的路径,2. 进度计划,4. 人员组织 (Personnel),1、程序设计小组：2 8人的非正式组织优点：规模小，交流方便。缺点：没有明确的权威负责人，组员间缺乏必要的协调。,全面负责设计、编码、测试和安装,主要负责 测试，必要时 替代 CP.,负责和 项目有关 的全部 事务性 工作,行政、后勤 管理,文档、工具 管理,提出具体测试方案，编写Driver 和 Stub, 进行
6、测试.,后备编程 力量,2、主程序员组(Chief Programmer Team)：Baker IBM , 1972,Understandability Maintainability Flexibility Testability,Portability Reusability Interoperability,5. 质量保证 (Quality Assurance),1、软件质量的定义：McCalls quality model (1977),4. 质量保证,2、质量保证的措施：, 审查：由组长、作者、2位评审员（与评审结果有利害关系的）组成审查小组，进行发现、记录错误的工作，并复查返工结
7、果。, 复查和管理复审：从技术、管理两方面进行的复查工作。, 测试：产生测试计划，测试过程，测试结果三 个基本文档,6. 项目计划 (Project Plan),1、内容：,5. 项目计划,内容 (续),5. 项目计划,2、项目报告, 确定里程碑(milestones)注意：每个milestones 的位置应能明确判定，不要太多。例如：以阶段性文档的提交作为其标志。反例：将“完成了80%编码”作为其标志。, 报告内容： 在本阶段已完成的工作 下阶段计划要完成的工作 问题范围 目前已用成本 项目预算执行情况, 建立月报制度 项目报告的另一种形式,3、变动控制,5. 项目计划, 改错控制：若发现前
8、阶段的错误，则必须记入文档，以保证所有受这个变动影响的部分都做相应的修改。,加 删功能：须经审批，因涉及费用问题。例：Lucent 公司的“Change Management Board ”和“Change Defense”。,7. 管理工具,1、计划工具：提供和以前完成的工程项目有关的信息，完成诸如成本计算和关键路径分析等工作。,2、报告生成工具：自动产生标准形式的报告。,8. 风险管理 (Risk Management),风险具有两个特性： uncertainty The even that characterizes the risk may or may not happen; los
9、s If the risk becomes a reality, unwanted losses will occur.,If you dont actively attack the risks, they will actively attack you. Tom Gilb (1988),Steps in risk management (Rook 1993),7. 风险管理,2、 风险管理,Microsofts integration strategy is market-driven, based on the need to have a working product as qui
10、ckly as possible (Cusumano and Selby 1995, 1997). It uses many small, parallel teams (three to eight developers each) implementing a “synch-and-stabilize” approach. The process iterates among designing, building, and testing components while involving customers in the testing process. All parts of a
11、 product are integrated frequently to determine what does and does not work. The Microsoft approach allows the team to change the specification of features as the developers learn more about what the product can and should do. Sometimes the feature set changes as much as 30% or more. The product and
12、 project are divided into parts, based on features, and different teams are responsible for different features.,BUILDS AT MICROSOFT,Then, milestones are defined, determined by a partitioning of features into most critical, desirable and least critical. The feature teams synchronize their work by bui
13、lding the product and by finding and fixing faults on a daily basis, as shown in the figure. Thus, the most important features are developed and integrated first, and each milestone includes “buffer time” to handle unexpected complications or delays. If the schedule must be shortened, the least impo
14、rtant features are cut from the product.,Milestone 1: Most critical features and shared components,Design, code, prototype Usability testing Daily builds Feature integration Eliminate severe faults,Milestone 2: Desirable features,Design, code, prototype Usability testing Daily builds Feature integra
15、tion,Milestone 3: Least critical features,Design, code, prototype Usability testing Daily builds Feature integration and completion Release to manufacturing,Figure: Microsoft synch-and-stabilize approach,项目管理,项目管理涉及对人员、过程和在软件从初始的概念演化为可运行的实现的过程中发生的事件的计划和监控。 在软件项目中，每个人或多或少都做着“管理”的工作。但是，管理活动的范围各不相同。软件工
16、程师管理他的日常活动，计划和监控技术任务。项目经理计划和监控软件工程师团队的工作。高级管理者协调业务和软件专业人员之间的关系。,项目管理,理解4P人员、产品、过程和项目。必须将人员组织起来以有效地完成软件工作。必须和客户及其他共利益者很好地沟通，以便了解产品的范围和需求；必须选择适合于人员和产品的过程；必须估算完成工作任务的工作量和工作时间，从而制定项目计划，包括：定义工作产品、建立质量检查点以及确定一些机制监控计划所规定的工作。,项目管理,在管理活动开始时，必须首先制定项目计划。该计划定义将要进行的过程和任务，安排工作人员，确定评估风险、控制变更和评价质量的机制。 在按时并在预算内交付高质量
17、的产品之前，你不可能完全肯定项目计划是正确的。不过，作为项目经理，鼓励软件人员协同工作形成一支高效的团队，并将他们的注意力集中到客户需求和产品质量上，这肯定是正确的。,项目管理,我拜访了很多商业公司好的和不好的，我又观察了很多数据处理管理者的业绩好的和不好的，我又观察了很多数据处理管理者的业绩好的和不好的。我常常恐惧地看到，这些管理者徒劳地与恶梦般的项目斗争着，在根本不可能完成的最后期限的压力下苦苦挣扎，或者是在交付了用户极为不满意的系统之后，又继续花费大量的时间去维护它。PAG85,管理涉及的范围,有效的软件项目管理集中于4个P上，即人员、产品、过程和项目。它们的顺序不是任意的，任何管理者如
18、果忘记了软件工程工作是人的智力密集的劳动，他就永远不可能在项目管理上取得成功；任何管理者如果在项目开发早期没有鼓励共利益者之间的广泛交流，他就冒着为错误的问题构造了“良好的”解决方案的风险；对过程不在意的管理者可能冒着把有效的技术方法和工具插入到真空中的风险；没有建立可靠的项目计划就开始工作的管理者将危及产品的成功。,人员,SEI专门开发了一个人员管理能力成熟度模型(PM-CMM)，旨在“通过吸引、培养、激励、部署和聘用那些改进软件组织软件开发能力所需要的人才，提高软件组织承担日益复杂的应用问题的能力”。 人员管理成熟度模型中针对软件人员定义了以下的关键实践区域：招募、选择、业绩管理、培训、报
19、酬、个人事业发展、组织和工作设计以及团队精神或企业文化培养。在人员管理上达到较高成熟度的组织，更有可能完成有效的软件工程实践。,产品,在制定项目计划之前，应该首先确定产品的目标和范围，考虑可选的解决方案，识别技术和管理上的限制。如果没有这些信息，就不可能进行合理的成本估算，也不可能进行有效的风险评估和适当的项目任务划分，更不可能制定可管理的项目进度计划来给出意义明确的项目进展标志。,产品,软件开发者和客户必须一同定义产品的目标和范围。在很多情况下，这项活动是作为系统工程或业务过程工程的一部分开始的，并一直持续到作为软件需求工程的第一步。确定产品的目标只是标识出产品的总体目标，而不用考虑这些目标
20、如何实现。而确定产品的范围，要标识出产品的主要数据、功能和行为特性，而且更为重要的是，应以量化的方式界定这些特性。,产品,了解了产品的目标和范围之后，就要开始考虑备选的解决方案了。虽然这一步并不讨论细节，但可以使管理者和参与开发的人员根据给定的约束条件选择“最好”的方案，其中，约束条件包括产品交付的期限、预算的限制、可用的人员、技术接口以及其他各种因素。,过程,软件过程提供了一个框架，在该框架下可以制定软件开发的综合计划。一小部分框架活动适用于所有软件项目，不用考虑其规模和复杂性。多种不同的任务集合每一种集合都由任务、里程碑、工作产品以及质量保证点组成使得框架活动适合于不同软件项目的特性和项目
21、团队的需求。最后是普适性活动如软件质量保证、软件配置管理和测量，这些活动覆盖了过程模型。普适性活动独立于任何一个框架活动，且贯穿于整个过程之中。,项目,实施有计划的、可控制的软件项目的主要理由是：这是我们知道的管理复杂事物的唯一方法。产业数据表明26%的软件项目彻底失败，46%的项目成本和进度超出预定。虽然软件项目的成功率已有所提高，但项目的失败率仍然高于它的应有值。 为了避免项目失败，软件项目经理和开发产品的软件工程师必须留意一些常见的警告信号，了解实施成功的项目管理的关键因素，还要确定计划和监控项目的一目了然的方法。,人员,所有的人，从高级工程副总裁到最低层的开发人员，常常认为人员是不成问
22、题的。虽然管理者常常表态说人员是最重要的，但有时他们言行并不一致。 以下将分析参与软件过程的人员，并且研究组织人员的方式，以实现有效的软件工程。,利益相关者,参与软件过程的利益相关者可以分为以下5类： 1高级管理者负责定义业务问题，这些问题往往对项目产生很大影响。 2项目（技术）管理者必须计划、激励、组织和控制软件开发人员。 3开发人员拥有开发产品或应用软件所需技能的人员。 4客户详细描述待开发软件需求的人员以及关心项目成败的其他共利益者。 5最终用户一旦软件发布成为产品，最终用户就是直接与软件进行交互的人。 项目团队必须以能够最大限度地发挥每个人的技术和能力的方式进行组织，这是团队负责人的任
23、务。,团队负责人,项目管理是人员密集型的活动，胜任开发的人却常常有可能是拙劣的团队负责人，他们完全不具备管理人员的技能。 WEI86提出了领导能力的MOI模型： 激励：鼓励技术人员发挥其最大才能的一种能力。 组织：形成能够将最初概念转换成最终产品的现有过程（或创造新的过程）的能力。 思想或创新：即使必须在特定软件产品或应用的约束下工作，也能鼓励人们去创造并让人感到有创造性的一种能力。 成功的项目负责人应采用一种解决问题的管理风格。即，软件项目经理应该注重理解要解决的问题、把握住涌现的各种意见、同时让项目团队的每一个人知道质量很重要，不能妥协。,团队负责人,关于一个具有实战能力的项目经理应该具有
24、什么特点，另一种观点则强调了以下4种关键品质： 解决问题。具有实战能力的软件项目经理能够准确地诊断出最为密切相关的技术问题和组织问题；能够系统地制定解决方案，适当地激励其他开发人员来实现该方案；有把在过去项目中学到的经验应用到新环境中；如果最初的解决方案没有结果，能够灵活地改变方向。 管理者的特性。优秀的项目经理必须能够掌管整个项目。必要的时候要有信心进行项目控制，同时还要允许优秀的技术人员能够按照他们的本意行事。 成就。为了优化项目团队的生产效率，项目经理必须奖励那些工作积极主动并且做出成绩的人，并通过自己的行为表明出现可控风险并不会受到惩罚。 影响和队伍建设。具有实战能力的项目经理必须能够
25、“理解”人。他必须能理解语言和非语言的信号，并对发出这些信号的人的要求做出反应。项目经理必须能在高压力的环境下保持良好的控制能力。,软件团队,几乎可以说有多少开发软件的组织，就有多少种软件开发人员组织结构。组织结构不能轻易改变。至于组织改变所产生的实际和行政上的影响，并不在软件项目经理的责任范围内。但是，软件项目中所直接涉及的人员的组织，则是项目经理的职责。,软件团队,MAN81提出了规划软件工程团队结构时应考虑的7个项目因素： 待解决问题的难度。 开发程序的规模，以代码行或者功能点来度量。 团队成员需要共同工作的时间。 能够对问题做模块化划分的程度。 待开发系统的质量要求和可靠性要求。 交付
26、日期的严格程度。 项目所需要的友好交流的程度。,软件团队,CON93提出了软件工程团队的4种“组织范型”： 封闭式范型。按照传统的权利层次来组织团队。 随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。 开放式范型。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。 同步式范型。依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。,软件团队,从历史的角度看，最早的软件团队组织是封闭式范型结构，最初称之为主程序员团队。团队的核心成员包括：一个高级工程师（“主程序员”），负责计划、协调和评审团队的所有技术活动；技术人员，进行
27、分析和开发活动；一个后备工程师，支持高级工程师的活动，并可以在项目进行过程中以最小的代价接替高级工程师的工作。 主程序员可以有多人配合他的工作，包括一个或多个专家、支持人员和软件资料员。,软件团队,CON93提出的随机式范型是主程序员团队结构的一个变种，主张建立具有独立创新性的团队，其工作方式可恰当地称为创新的无政府状态。尽管自由的软件工作方式是有吸引力的，但在绩效良好的团队中必须将创新能力作为软件工程组织的中心目标。,软件团队,为了建成一支绩效良好的团队： 团队成员必须相互信任。 团队成员的技能分布必须适合于要解决的问题。 如果要保持团队的凝聚力，必须将坚持个人己见的人员排除于团队之外。 无
28、论什么类型的团队，每一个项目经理的目标都是帮助建立一支有凝聚力的团队。 同一般的团队相比，有凝聚力的团队成员具有更高的生产率和更大的动力。他们拥有共同的目标和共同的文化，而且在很多情况下，“精英意识”使得他们独一无二。,软件团队,但是，并非所有的团队都具有凝聚力。事实上，很多团队都受害于JAC98称之为“团队毒性”的东西。JAC98定义了5个“培育潜在含毒团队环境”的因素：(1)狂乱的工作氛围；(2)引起团队成员间产生磨擦的重大挫折；(3)“碎片式的或协调很差”的软件过程；(4)在软件团队中没有清晰的角色定义；(5)“接连不断地重蹈覆辙”。,软件团队,为了避免狂乱的工作环境，项目经理应该确保团
29、队可以获取完成工作所需的所有信息；而且，主要目标一旦确定下来，除非绝对必要，否则不应该修改。如果给予软件团队尽可能多的决策权，就能使团队避免挫败和压力。通过理解将要开发的产品和完成工作的人员，以及允许团队选择自己的过程模型，可以避免选择不适当的软件过程。团队本身应该建立自己的责任机制，并规定一系列当团队成员未能完成任务时的纠正方法。最后，避免失败的关键是建立基于团队的信息反馈方法和解决问题的技术。,敏捷团队,小型的充满活力的团队，也称为敏捷团队，采纳了很多成功的软件项目团队的特性，同时又避免了很多产生问题的毒素。同时，敏捷方法学强调团队成员的个人能力与团队协作精神相结合，这是团队成功的关键因素
30、。 在软件项目中，为了充分发挥每个成员的能力，并培养有效的合作，敏捷团队是自组织的。自组织团队不必保持单一的团队结构，而是采用随机、开放、同步式的范型。,敏捷团队,很多敏捷过程模型给予敏捷团队相当大的自主权进行项目管理，可以因工作需要做出技术决定。将计划制定工作压缩到最低程度，并且允许团队选择自己适用的手段，只受业务需求和组织标准的限制。在项目进行过程中，自组织团队关注的是在特定的时间点使项目获益最大的个人能力。为了做到这一点，敏捷团队可以召开简短的日常团队会对当天必须完成的工作进行调整以使其同步进行。 基于在团队会中取得的信息，团队能使他们所采用的手段不断适应持续增加的工作。当每一天过去的时
31、候，连续的自组织和协作使团队朝着软件逐步增长的完工的方向发展。,协调和通信问题,使软件项目陷入困境的原因很多。许多开发项目规模很大，导致复杂性高、混乱、难以协调团队成员间的关系。不确定性是经常存在的，它会引起困扰项目团队的一连串的变更。互操作性已经成为许多系统的关键特性。新的软件必须与已有的软件通信，并遵从系统或产品所施加的预定义约束。,协调和通信问题,现代软件的这些特征规模、不确定性和互操作性确实都是存在的。为了有效地处理这些问题，软件工程团队必须建立切实可行的方法来协调工作人员之间的关系。为了做到这一点，需要建立团队成员之间以及多个团队之间的正式的和非正式的交流机制。,产品,从软件工程项目
32、一开始，软件项目经理就面临着进退两难的局面。需要定量地估算成本和有组织地计划项目的进展，但却没有可靠的信息可以使用。虽然对软件需求的详细分析可以提供必要的估算信息，但需求分析常常需要数周甚至数月的时间才能完成。更糟糕的是，需求可能是不固定的，随着项目的进展经常发生变化。不过，无论如何计划总是“眼前”就需要的！ 因此，从软件工程项目一开始，就要研究应该开发哪些产品以及要解决哪些问题。至少，要建立和界定项目的范围。,软件范围,软件项目管理的第一项活动是确定软件范围。软件范围是通过回答下列问题来定义的： 项目环境。要开发的软件如何适应于大型的系统、产品或业务环境，该环境要施加什么约束？ 信息目标。软
33、件要产生哪些客户可见的数据对象来作为输出？需要什么数据对象作为输入？ 功能和性能。软件要执行什么功能才能将输入数据变换成输出数据？软件需要满足什么特殊的性能要求吗？,软件范围,软件项目范围在管理层和技术层都必须是无歧义的和可理解的。对软件范围的描述必须是界定的。即，要明确给出定量的数据；说明约束和限制，并且描述其他的缓解因素。,问题分解,问题分解，有时称为问题划分或问题细化，它是软件需求分析的核心活动。在确定软件范围的活动中，并不试图去完全分解问题，只分解其中的两个主要方面：(1)必须交付的功能；(2)所使用的过程。 在面对复杂问题时，常常采用分而治之的策略。就是将一个复杂的问题划分成若干较易
34、处理的小问题。这是项目计划开始时所采用的策略。在开始估算前，必须对软件范围中所描述的软件功能进行评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以对功能进行某种程度的分解是很有益处的。,过程,刻画软件过程的框架活动适用于所有软件项目。问题是项目团队要选择一个适合于待开发软件的过程模型。 项目经理必须决定哪一个过程模型最适合于：(1)需要该产品的客户和从事开发工作的人员；(2)产品本身的特性；(3)软件项目团队工作的项目环境； 当选择一个过程模型后，项目团队可以基于一系列过程框架活动来制定一个初步的项目计划。一旦确定了初步计划，过程分解就开始了。也就是说，必须制定一个完整的计划
35、，来反映框架活动中所需要的工作任务。,合并产品和过程,项目计划开始于产品和过程的合并。软件项目团队要完成的每一项功能都必须通过针对软件组织而定义的一系列框架活动来完成。 完成任何一项功能的项目团队成员都要将各个框架活动应用于该功能的实现上。实质上，产生了一个类似于图18-1所示的矩阵。每个主要的产品功能显示在第一列，框架活动显示在第一行。软件工程工作任务列在紧接下来的行中。项目经理（和其他团队成员）的工作是估算每一个矩阵单元的资源需求，与每个单元相关的任务的开始和结束日期，以及每项任务所产生的工作产品。,合并产品和过程,图18-1 合并产品和过程,过程分解,软件团队在选择最适合项目的软件过程模
36、型时，应该具有很大的灵活性。一旦选定了过程模型，项目团队可以根据需要灵活地确定过程模型中应包含的软件工程任务。较小的项目如果与以前已开发过的项目相似，可以采用线性顺序模型。如果时间要求很紧，而且问题能够被很好地划分，RAD模型可能是正确的选择。如果时间要求太紧，不可能完成所有功能时，增量模型可能是最合适的。同样，如果项目具有其他特性，可能会选择其他的过程模型。,过程分解,一旦选定了过程模型，就要根据所选的过程模型对过程框架做适应性修改。但在所有情况下，前面讨论过的通用框架活动（沟通、策划、建模、构建和部署）都可以使用。过程框架既适用于线性模型，也适用于迭代和增量模型、演化模型、甚至是并发模型或
37、构件组装模型。过程框架是不变的，是软件组织所进行的所有软件工作的基础。,过程分解,但实际的工作任务是不同的。例如，一个小型的比较简单的项目在沟通活动中可能需要完成下列工作任务： 1、列出需澄清的问题清单。 2、与客户见面说明需澄清的问题。 3、共同给出范围陈述。 4、和所有相关人员一起评审范围陈述。 5、根据需要修改范围陈述。,过程分解,考虑一个比较复杂的项目，它具有更广的范围和更重要的商业影响。这样一个项目在沟通活动中可能需要完成下列工作任务：,项目,为了成功地管理软件项目，必须了解可能会出现什么问题。在一篇关于软件项目的优秀论文中，REE99定义了10个表示信息系统项目正处于危险状态的信号
38、： 1软件人员不了解其客户的要求。 2产品范围定义得很糟糕。 3没有很好地管理变更。 4选择的技术发生了变化。 5业务需求发生变化。 6最后期限是不切实际的。 7客户抵制。 8失去赞助。 9项目团队缺乏具有合适技能的人员。 10管理者没有很好地利用已学到的最佳实践和教训。,项目,针对软件项目提出易于理解的方法(5个) 1在正确的基础上开始工作。通过以下两点来完成：首先努力地正确理解要解决的问题，然后为每个参与项目的人员设置现实的目标和期望。这一点又通过组建合适的开发团队以及给予团队完成工作所需的自由、权力和技术而得到加强。,项目,2保持动力。很多项目的启动都有一个良好的开端，但是，后来慢慢地开
39、始瓦解。为了维持动力，项目经理必须采取激励措施使人员变动量保持绝对最小，项目团队应该强调完成的每个任务的质量，而高层的管理应该尽可能不干涉团队的工作。,项目,3跟踪进展。对于一个软件项目，当工作产品被生产出来和被批准时，跟踪项目进展要作为质量保证活动的一部分。此外，可以收集软件过程和项目测量数据，然后对照软件开发组织的平均数据来评估项目的进展。,项目,4做出聪明的决策。总体上，项目经理和软件团队的决策应该“保持项目的简单性”。只要有可能，就使用商用成品软件或现有的软件构件，在可以采用标准的方法时就避免定制接口，识别并避免显而易见的风险，以及分配比你认为的时间更多的时间来完成复杂或有风险的任务。
40、,项目,5进行事后分析。建立统一的机制，从每个完成的项目中获取可学习的经验。评估计划的进度和实际的进度，收集和分析软件项目度量数据，从项目团队成员和客户处获取反馈，并记录下所有的发现。,W5HH原则,Boehm提出了一种方法，该方法强调项目目标、里程碑和进度、责任、管理和技术方法以及需要的资源。称之为W5HH原则。这种方法通过提出一系列问题，来导出对关键项目特性以及项目计划的定义。 为什么（Why）要开发这个系统？对这个问题的回答，可以使所有参与者评估软件工作的商业理由的有效性。即，该系统的商业目的值得花费这些人员、时间和金钱吗？,W5HH原则,将要做什么（What）？对这个问题的回答将制定完
41、成项目所需的任务清单。 什么时候（When）做？就是标识出何时开展项目任务和何时达到里程碑，对这个问题的回答能够帮助团队安排好项目进度。 某功能由谁（Who）负责？必须规定软件团队的每个成员的角色和责任。对这个问题的回答将帮助完成该项规定。,W5HH原则,他们的机构组织位于何处(Where)？并非所有角色和责任均属于软件团队，客户、用户和其他共利益者也有责任。 如何(How)完成技术工作和管理工作？一旦确定了产品范围，必须定义项目的管理策略和技术策略。 每种资源需要多少(How much)？对这个问题的回答，是在对前面问题回答的基础上，通过估算而得到的。,关键实践,Airlie Council提出了一组“基于性能管理的关键软件实践”。这些实践“被高度成功的软件项目和组织一致地使用，并被认为的确是关键的。 关键实践包括：1基于度量的项目管理2成本和进度的经验估计3获得价值跟踪4根据质量目标跟踪缺陷5人员计划管理,小结,P331,作业,P332 18.7页,
