第二章_软件项目管理基础

第二章软件项目管理基础软件项目的成功和失败软件开发的困惑为什么我们不能开发出高质量的软件？为什么人类无法定义它、解释它，深刻地了解它？为什么一些天才的科学家穷其一生的精力也不能把这些迷惑归纳成一种科学工程学科或行业标准？软件工程方法不堪一击，人们无法使用它们。软件项目失败原因客户需求不确定最终产品的设计和特色只有在过程中才能变得清晰，而不是开始时很难制定准确的计划估计不够，低估时间和成本来自营销、客户和管理者的压力沟通失败是项目失败的最大的威胁软件过程不可见软件开发的探索技术CASE,UMLOO过程控制ISO9001,ISO9000-3,ISO15504,ISO12207CMM,TickIT以上措施并没有真正解决软件危机“质量是制造出来的，不是检验出来”，在制造业适用，在软件行业作用并不大(软件过程不可见)项目失败率还是很高软件项目失败深层次原因对软件的误解是问题的根源。现有的方法是由那些有良好愿望但忘记了软件中的“软”的那些聪明人所创建的。他们假定开发软件就象造桥。方法不正确。没有人打算失败，具有讽刺意味的是为使失败最小化而创建的方法是失败的。开发人员士气不高，没有创造性。管理人员、开发人员能力不够。只重过程，不重人。没有良好的沟通。项目管理概述软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的根本目的是为了让软件项目，尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本，按期、按质的完成软件，然后交付用户使用。这种管理在技术工作开始之前就应开始，在软件从概念到实现的过程中继续进行，当软件工程过程最后结束时才终止。软件项目管理的特殊性软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。其中时间，质量和成本管理构成了三角形项目管理三角形时间质量成本中间是范围管理，也就是项目范围项目管理包括5种基本活动启动：相关人员提出对项目的要求，项目开始。计划：计划涉及详细规定出要取得的结果；产生这些结果所需要的活动和任务；决定时间表和估计所需的资源，例如人力和资金。组织：组织规定了项目的组织和角色、责任的定义。在计划活动中，角色被映射成确定的工作。控制：控制确定正在进行的活动何时偏离了计划。收尾：终止是结束项目。项目生命期和阶段划分项目可以分成几个阶段项目概念：关于项目的想法开始出现，通常伴随着成本效益分析和技术可行性研究。项目定义：包括以下活动问题定义：客户和项目经理按照功能，限制条件和交付产品定义系统的规模。客户和项目经理也在协议标准和目标日期上达成一致。初始的软件项目管理计划（SPMP）：项目经理提供对项目总的看法、项目结果的描述、工作分解结构、角色和责任、项目时间表、所需资源的预算和怎样定义和处理风险的描述。初始的软件体系结构:它关注于软件体系结构，特别是把系统分解成子系统。项目协议定义：在项目协议文档中，用户和项目经理对作为基线的系统规模和交付日期正式达成一致。项目开始：项目经理设置了项目的基础设施，雇用参与者，把他们组成团队，并总结项目。项目开始包括以下活动基础设施设立：项目经理必需为项目的基础设施制定需求。这些需求描述了项目参与者之间的交流渠道，比如公告牌、网站和会议管理程序等。技能定义：项目经理定义开发者的技能和兴趣，并在技能矩阵中记录它。团队集合：项目经理分配团队参与者，定义团队功能且选择团队领导。项目经理也为团队成员定义所需的额外培训和课程。最后，项目经理为团队分配工作包。项目总结：项目经理，团队领导和客户正式开始启动项目。项目稳定状态：团队领导要负责跟踪团队状态和在团队会议上提出问题。包括以下活动项目规模定义控制：团队领导和项目经理每周将项目状况和SPMP中计划的时间表进行比较。团队领导负责收集状况信息和向项目经理报告情况。风险管理：项目经理和团队领导定义、分析、设定风险的优先级，并准备对意外事故的计划。项目重计划：当项目偏离了时间表或发生意外事故，项目经理需要修改时间表，并且重新分配资源来。项目终止：提交项目结果并收集项目历史。主要活动有交付：由客户验收测试和系统安装2个子活动组成。客户验收测试：软件系统由客户按照项目协议中制定的验收准则进行评价。安装：系统被配置在目标环境中，并且交付文档。安装可能包括用户培训和实施阶段。事后分析：项目经理和团队领导收集项目历史资料以获得经验。定义工作分解结构项目计划的基本假设是项目结果不能在一个大型活动中被完成，我们必须用各个击破的方法来把工作分解成更小的、更容易做的小块。因此，在项目计划中一个主要的任务是把整个工作包分解成更小的任务。这包括2件事：定义合适的任务和定义任务间的依赖关系。任务和活动任务是一项已经定义得很好的工作，该工作可分配给一个项目参与者或分配给一个团队。任务是管理有关项目工作的最小的单元。任务包括对任务和持续时间的描述，还包括分配给所扮演角色的参与者。工作产品，工作包和角色工作包描述了要生产的工作产品，要完成工作所需要的资源，所希望的持续时间，输入之间的相互依赖，也详细说明了验收规则和相关的个体或组织的单元的名字。工作包是重要的管理产物，我们把它们分配给参与者去做。在任务定义之后可以定义工作包。任何交付给用户的工作产品叫交付品，例如用户手册。工作分解结构在一个项目中，全体任务的层次描述叫工作分解结构（WBS）。工作分解结构是一个要做工作的非常简单的模型。注意:工作分解结构不表示活动的顺序。项目范围阶段工作单元任务牛仔靴数据库项目数据库的生成应用的生成Web接口的生成故障解决和执行项目不要划分得太细，最小单元可为工作日。进度安排软件开发项目的进度安排有两种方式：（1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；（2）系统最终交付日期只确定了大致的年限，最後交付日期由软件开发部门确定。进度安排的方法可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。在图示方法中，必须明确标明：各个任务的计划开始时间，完成时间；各个任务完成标志（即○文档编写和△评审）；各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；完成各个任务所需的物理资源和数据资源。甘特图也叫做线条图或横道图。它是以横线来表示每项活动的起止时间。甘特图的优点是简单、明了、直观，易于编制，因此到目前为止仍然是小型项目中常用的工具。即使在大型工程项目中，它也是高级管理层了解全局、基层安排进度时有用的工具。在甘特图上，可以看出各项活动的开始和终了时间。在绘制各项活动的起止时间时，也考虑它们的先后顺序。但各项活动上间的关系却没有表示出来，同时也没有指出影响项目寿命周期的关键所在。因此，对于复杂的项目来说，甘特图就显得不足以适应。在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图要点：以图形或表格的形式显示活动现在是一种通用的显示进度的方法构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内甘特图是做项目进度计划方法的重要方法，其他方法有：关键日期表：这是最简单的一种进度计划表，它只列出一些关键活动和进行的日期。关键路线法计划评审技术（ProgramEvaluationandReviewTechnique，简称PERT）。Gantt图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间，因此是进度计划和进度管理的有力工具。它具有直观简明和容易掌握、容易绘制的优点。Gantt图的3个主要缺点：(1)不能显式地描绘各项作业彼此间的依赖关系；(2)进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；(3)计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。任务通过暂时的依赖关系联系起来。例如建屋顶的任务不能在建墙任务结束前开始。任务及其依赖关系的集合叫任务模型或者网络图。完成任务有一个持续时间，由项目经理在项目开始前估算。一旦知道了任务间依赖关系和任务的持续时间，项目经理能计算出项目能被完成的最短可能时间。该时间在任务模型中表现为最长路径，即关键路径。关键路径经过项目的第一项任务到最后一项任务，其长度由任务的持续时间相加计算出来。在关键路径上的任务延迟会导致整个项目的延迟，从而使项目延期。任务的最迟完成时间是在不耽误项目的其他要完成的任务时，任务能被推迟的最大时间。关键路线法F1周开始0周A1周D2周C1周B1周E1周结束0周关键路决定项目的最短完成时间关键路分析(CriticalPath)关键路径的计算与调整优化关键路径是网络图中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于那些优先等级最高的任务，确保它们准时完成，关键路径上的任何活动的推迟将使整个项目推迟。向关键路要时间，向非关键路要资源。调整进度，平衡资源任务的确定与并行性当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。里程碑：一个具有特定重要性的事件，通常代表项目工作中一个重要阶段的完成。在里程碑处，通常要计划进行检查。软件工程项目的并行性提出了一系列的进度要求。40－20－40规则在整个软件开发过程中，编码工作量仅占20％，编码前工作量占40％，编码后工作量占40％。40－20－40规则只应用来做为一个指南。实际的工作量分配比例必须按照各项目的特点来决定。技能矩阵技能矩阵是在项目中关于要完成任务的人的技能、知识和兴趣的一张简单表。技能矩阵的一行表示来自工作分解结构的工作单元——任务、活动和项目功能。一列表示项目参与者。矩阵中的一项为任务，定义了特定参与者的技能和知识层次。我们把3种项目区分开：主要技能、次要技能和兴趣。主要技能使一个人能胜任领导一个工作单元。次要技能使一个人能参与任务。兴趣表示在任务中一个人感兴趣但不具备该技能。2.2.6组织组织由组织单元及其交互组成。最小组织单元是一个参与者（也叫个人或成员）。一组参与者能组成部门、处或小组。呈现组织结构组织的表现及其信息结构通常叫组织图。人员组织除了追求更好的组织方式之外，每个管理者的目标都是建立有凝聚力的项目组。现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。民主制程序员组民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n(n-1)/2条。民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。主要优点是，组员们对发现程序错误持积极的态度。小组有高度凝聚力，有利于攻克技术难关。主程序员组美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑：(1)软件开发人员多数比较缺乏经验；(2)程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；(3)多渠道通信很费时间，将降低程序员的生产率。典型的主程序员组的组织形式主程序员组用经验多、技术好、能力强的程序员作为主程序员。该组由主程序员、后备程序员、编程秘书