第19-章软件项目管理与计划(课堂PPT).ppt

2北1第第19章章 软件项目管理与计划软件项目管理与计划o软件工程中程序出错、成本超支和没完成要求等都软件工程中程序出错、成本超支和没完成要求等都可以归结到软件项目管理太弱。因此，工程中要进可以归结到软件项目管理太弱。因此，工程中要进行管理与计划行管理与计划o本章内容：本章内容：o 19.1 软件项目管理概述软件项目管理概述o19.2 项目管理过程项目管理过程o19.3 软件开发成本估算软件开发成本估算o19.4 风险分析风险分析o19.5 进度安排进度安排o19.6 软件项目的组织软件项目的组织2北219.1 软件项目管理概述软件项目管理概述o19.1.1 软件管理的对象软件管理的对象o在软件项目管理中，重要的是人、问题和过程三者。在软件项目管理中，重要的是人、问题和过程三者。其中人是最重要的管理对象。其中人是最重要的管理对象。o组成一个软件工程的开发项目的人员有以下几类：组成一个软件工程的开发项目的人员有以下几类：o（1）高级管理者：负责确定软件的问题。）高级管理者：负责确定软件的问题。o（2）项目技术管理者：管理软件开发人员。）项目技术管理者：管理软件开发人员。o（3）开发人员：软件开发的专门的技术人员。）开发人员：软件开发的专门的技术人员。o（4）客户：负责说明软件需求的人员。）客户：负责说明软件需求的人员。o（5）最终用户：最终使用软件的人员。）最终用户：最终使用软件的人员。2北319.1.2 软件开发中的资源软件开发中的资源o软件项目计划的第二个任务是对完成该软件项目所软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。需的资源进行估算。图图19-1 软件开发所需的资源软件开发所需的资源2北41.人力资源是最重要的资源人力资源是最重要的资源o在安排开发活动时必须考虑人员的技术水平、专业、在安排开发活动时必须考虑人员的技术水平、专业、人数以及在开发过程各阶段中对各种人员的需要。人数以及在开发过程各阶段中对各种人员的需要。o对一些规模较大的项目，在整个软件生存期中，各对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。如图种人员的参与情况是不一样的。如图19-2所示所示 2北5o图19-2 管理人员与技术人员的参与情况2北62.硬件硬件/软件资源软件资源 o硬件是作为软件开发项目的一种工具而投入的。在硬件是作为软件开发项目的一种工具而投入的。在软件项目计划期间，考虑三种硬件资源：软件项目计划期间，考虑三种硬件资源：o（1）宿主机（）宿主机（Host machine）软件开发软件开发时使用的计算机及外围设备。时使用的计算机及外围设备。o（2）目标机（）目标机（Target machine）运行已运行已开发成功软件的计算机及外围设备。开发成功软件的计算机及外围设备。o（3）其他硬件设备）其他硬件设备专用软件开发时需要的特专用软件开发时需要的特殊硬件资源。殊硬件资源。2北7o宿主机连同必要的软件工具构成软件开发系统。宿主机连同必要的软件工具构成软件开发系统。o软件资源包括用于开发的运行平台、各种软件资源包括用于开发的运行平台、各种CASE工工具可以帮助分析和设计软件、开发程序所有的编程具可以帮助分析和设计软件、开发程序所有的编程语言等。语言等。2北83.可复用构件资源可复用构件资源o为了促成软件的复用，以提高软件的生产率和软件为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部件库。根据需产品的质量，可建立可复用的软件部件库。根据需要，对软件部件稍做加工，就可以构成一些大的软要，对软件部件稍做加工，就可以构成一些大的软件包。这要求这些软件部件应加以编目，以利于引件包。这要求这些软件部件应加以编目，以利于引用，并进行标准化和确认，以利于应用和集成。用，并进行标准化和确认，以利于应用和集成。o遗憾的是，在计划阶段，人们往往忽视软件资源。遗憾的是，在计划阶段，人们往往忽视软件资源。直到软件工程过程的开发阶段，软件资源成为一个直到软件工程过程的开发阶段，软件资源成为一个重大问题时才引起人们的重视。最好是尽早确定软重大问题时才引起人们的重视。最好是尽早确定软件资源的需求，这样可以对各种候选方案进行技术件资源的需求，这样可以对各种候选方案进行技术评价，并及时地获取这些软件。评价，并及时地获取这些软件。2北919.1.3 分解技术分解技术 o当一个待解决的问题过于复杂时，可以把它进一步当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止。然分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。答综合起来，从而得到原问题的解答。2北1019.2 项目管理过程项目管理过程o软件项目管理的对象是软件工程项目。它所涉及的软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。范围覆盖了整个软件工程过程。o1.启动一个软件项目启动一个软件项目o2.成本估算成本估算o3.风险分析风险分析o4.进度安排进度安排o5.追踪和控制追踪和控制2北1119.3 软件开发成本估算软件开发成本估算19.3.1 软件开发成本估算方法软件开发成本估算方法 o1.自顶向下的估算方法自顶向下的估算方法o这种方法的想法是从项目的整体出发，进行类推。这种方法的想法是从项目的整体出发，进行类推。表19-1 软件开发各阶段工作量的分配 软件库存情况更新 开发者W.Ward 日期2/8/82阶段项目任务工作量分布（1/53）小计（1/53）计划和需求划内软件需求定义56开发计划1产品设计产品设计610初步的用户手册3测试计划1详细设计详细PDL描述412数据定义4测试数据及过程设计2正式的用户手册2编码与单元测试编码616单元测试结果10组装与联合测试按实际情况编写文档49组装与测试5总计532北12o2.自底向上的估算法自底向上的估算法 这种方法的想法是把待开发的软件细分，直到每这种方法的想法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、项目管理）的系统级工作量（配置管理、质量管理、项目管理）。所以往往估算值偏低，必须用其他方法进行检验。所以往往估算值偏低，必须用其他方法进行检验和校正。和校正。2北13o3.差别估算法差别估算法 这种方法综合了上述两种方法的优点，其想法是这种方法综合了上述两种方法的优点，其想法是把待开发的软件项目与过去已完成的软件项目进行把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确度，缺点是不容易明确优点是可以提高估算的准确度，缺点是不容易明确“类似类似”的界限。的界限。2北1419.3.2 软件开发成本估算的经验模型软件开发成本估算的经验模型o1.IBM模型模型o1977年，年，Walston（沃尔斯顿（沃尔斯顿）和）和Felix（菲（菲力克斯力克斯）总结了）总结了IBM联合系统分部（联合系统分部（FSD）负责）负责的的60个项目的数据。其中各项目的源代码行数从个项目的数据。其中各项目的源代码行数从400行到行到467000行，开发工作量从行，开发工作量从12PM到到11758PM，共使用，共使用29种不同语言和种不同语言和66种计算机。种计算机。利用最小二乘法拟合，得到如下估算公式：利用最小二乘法拟合，得到如下估算公式：oE=5.2L0.19 D=4.1L0.36=17.47E0.35oS=0.54E0.6 DOC=49L1.012北15o其中，其中，L是源代码行数（以是源代码行数（以KLOC计），计），E是工作是工作量（以量（以PM计），计），D是项目持续时间（以月计），是项目持续时间（以月计），S是人员需要量（以人计），是人员需要量（以人计），DOC是文档数量（以是文档数量（以页计）。因此估算出了源代码的数量，就可以对工页计）。因此估算出了源代码的数量，就可以对工作量、文档数量等进行估算了。作量、文档数量等进行估算了。oIBM模型是一个静态单变量模型，它利用已估算的模型是一个静态单变量模型，它利用已估算的特性，例如源代码行数，来估算各种资源的需要量。特性，例如源代码行数，来估算各种资源的需要量。IBM模型是一个静态单变量模型，但不是一个通用模型是一个静态单变量模型，但不是一个通用公式。在应用中有时要根据具体实际情况，对公式公式。在应用中有时要根据具体实际情况，对公式中的参数进行修改。中的参数进行修改。2北162.Putnam（普特莱姆（普特莱姆）模型）模型o这是这是1978年年Putnam提出的模型，是一种动态多变量模提出的模型，是一种动态多变量模型。该模型的基础是假定在软件开发的整个生存期中工作型。该模型的基础是假定在软件开发的整个生存期中工作量有特定的分布。它把项目的资源需求当做时间的函数。量有特定的分布。它把项目的资源需求当做时间的函数。根据对一些大型项目的统计分析，软件开发工作量分布可根据对一些大型项目的统计分析，软件开发工作量分布可用如图用如图19-3所示的曲线表示。所示的曲线表示。2北17o图图19-3 大型项目的工作量分布情况大型项目的工作量分布情况2北18o如图如图19-3所示中的曲线被称为所示中的曲线被称为Rayleigh-Norden（雷利（雷利-诺登诺登）曲线。利用该曲线得到）曲线。利用该曲线得到如下的经验公式：如下的经验公式：L=CkK1/3td4/3 其中，其中，td是开发持续时间（以年计），是开发持续时间（以年计），K是软件开是软件开发与维护在内的整个生存期所花费的工作量（以人发与维护在内的整个生存期所花费的工作量（以人年计），年计），L是源代码行数（以是源代码行数（以LOC计），计），Ck是技术是技术状态常数，它反映出状态常数，它反映出“妨碍程序员进展的限制妨碍程序员进展的限制”，并因开发环境而异。并因开发环境而异。2北193.COCOMO模型（模型（Constructive Cost Model）oBarry Boehm（巴里巴里.贝姆贝姆）提出的一种软件估算模型）提出的一种软件估算模型的层次体系，称为结构型成本估算模型。是一种比较精确、的层次体系，称为结构型成本估算模型。是一种比较精确、易于使用的综合成本估算方法。易于使用的综合成本估算方法。o该模型分为三个层次：该模型分为三个层次：o基本的基本的COCOMO模型：只是将工作量（成本）作为程序规模型：只是将工作量（成本）作为程序规模的函数进行计算。模的函数进行计算。o中级的中级的COCOMO模型：除了工作量以外，还将对产品、硬模型：除了工作量以外，还将对产品、硬件、人员及项目属性的主观评价作为件、人员及项目属性的主观评价作为“成本驱动因子成本驱动因子”加加入估算模型中。入估算模型中。o高级的高级的COCOMO模型：除了中级模型的因素外，还加入了模型：除了中级模型的因素外，还加入了成本驱动因子对软件开发的每一个过程的影响的评估。成本驱动因子对软件开发的每一个过程的影响的评估。2北20COCOMO规定了三种项目属性：规定了三种项目属性：o（1）组织型（）组织型（Organic）：较小、较简单的软件）：较小、较简单的软件项目。项目组人员经验丰富，对软件的使用环境很项目。项目组人员经验丰富，对软件的使用环境很熟悉，受硬件的约束较少，程序的规模不是很大熟悉，受硬件的约束较少，程序的规模不是很大（5万行）。万行）。o（2）嵌入型（）嵌入型（Embadded）：此种软件要求在）：此种软件要求在紧密联系的硬件、软件和操作的限制条件下运行的紧密联系的硬件、软件和操作的限制条件下运行的软件。比如航天用控制系统属此种类型。软件。比如航天用控制系统属此种类型。o（3）半独立型（）半独立型（Semidetached）：对此种软）：对此种软件的要求介于上述两种软件之间，但软件规模和复件的要求介于上述两种软件之间，但软件规模和复杂性都属于中等以上，最大可达杂性都属于中等以上，最大可达30万行。例如，万行。例如，大多数事务处理系统属此种类型。大多数事务处理系统属此种类型。2北21基本的基本的COCOMO模型的估计方式模型的估计方式 oE=a*KLOCb oD=c*EdoE是以人月为单位的工作量，是以人月为单位的工作量，D是以月表示的开发时间，是以月表示的开发时间，KLOC是项目的代码行（以千行为单位），是项目的代码行（以千行为单位），a、b、c、d是系数，如表是系数，如表19-2所示。所示。软件项目abcd组织型2.41.052.50.38半独立型3.01.122.50.35嵌入型3.61.202.50.322北2219.4 风险分析风险分析o风险含义风险含义o在软件工程的环境中考虑时，风险的含义一是关心在软件工程的环境中考虑时，风险的含义一是关心未来，风险是否会导致软件项目失败；二是关心变未来，风险是否会导致软件项目失败；二是关心变化，在用户需求、开发技术、目标机器，以及所有化，在用户需求、开发技术、目标机器，以及所有其他与项目有关的实体中会发生的变化？三是必须其他与项目有关的实体中会发生的变化？三是必须解决选择问题：应当采用什么方法和工具，应当配解决选择问题：应当采用什么方法和工具，应当配备多少人力，在质量上强调到什么程度才满足要求备多少人力，在质量上强调到什么程度才满足要求？o风险分析实际上是风险分析实际上是4个不同的活动：风险识别、风个不同的活动：风险识别、风险估算、风险评价和风险驾驭。险估算、风险评价和风险驾驭。2北2319.4.1 风险识别风险识别o可用不同的方法对风险进行分类。可用不同的方法对风险进行分类。o从宏观上来看，可将风险分为项目风险、技术风险从宏观上来看，可将风险分为项目风险、技术风险和商业风险。项目风险包括潜在的预算、进度、个和商业风险。项目风险包括潜在的预算、进度、个人（包括人员和组织）、资源用户和需求方面的问人（包括人员和组织）、资源用户和需求方面的问题，以及它们对软件项目的影响。技术风险包括潜题，以及它们对软件项目的影响。技术风险包括潜在的设计、实现、接口、检验和维护方面的问题。在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。术陈旧、最新技术（不成熟）也是风险因素。2北24商业风险主要有以下几种：商业风险主要有以下几种：o（1）建立的软件虽然很优秀但不是真正所想要的）建立的软件虽然很优秀但不是真正所想要的（市场风险）。（市场风险）。o（2）建立的软件不适用整个软件产品战略。）建立的软件不适用整个软件产品战略。o（3）销售部门不清楚如何推销这种软件。）销售部门不清楚如何推销这种软件。o（4）失去上级管理部门的支持。）失去上级管理部门的支持。o（5）失去预算或人员的承诺（预算风险）。）失去预算或人员的承诺（预算风险）。o（6）最终用户的水平。）最终用户的水平。o风险识别就是要识别属于上述类型中某些特定项目风险识别就是要识别属于上述类型中某些特定项目的风险。的风险。2北25oBoehm建议的方法是使用一个建议的方法是使用一个“风险项目检查表风险项目检查表”，列出所有可能的与每一个风险因素有关的提问。，列出所有可能的与每一个风险因素有关的提问。o对于这些提问，通过判定分析或假设分析，给出确对于这些提问，通过判定分析或假设分析，给出确定的回答，就可以帮助管理计划人员估算风险的影定的回答，就可以帮助管理计划人员估算风险的影响。响。2北2619.4.2 风险估算风险估算 o风险估算，又叫风险预测。通常进行风险估算，又叫风险预测。通常进行4种风险估算种风险估算活动：活动：o（1）建立一个尺度或标准来表示一个风险的可能）建立一个尺度或标准来表示一个风险的可能性。性。o（2）描述风险的结果。）描述风险的结果。o（3）估计风险对项目和产品的影响。）估计风险对项目和产品的影响。o（4）确定风险估计的正确性。）确定风险估计的正确性。o可以通过检查风险表来度量各种风险。尺度可以用可以通过检查风险表来度量各种风险。尺度可以用布尔值、定性的、或定量的方式定义。布尔值、定性的、或定量的方式定义。o最后，根据已掌握的风险对项目的影响，可以最后，根据已掌握的风险对项目的影响，可以给给风风险加权，并把它们安排到一个优先队列中。险加权，并把它们安排到一个优先队列中。2北27o如图如图19-4所示，风险影响和出现概率对驾驭参与有不同的所示，风险影响和出现概率对驾驭参与有不同的影响。影响。图19-4 风险与驾驭参与2北2819.4.3 风险评价风险评价o在风险分析过程中进行风险评价的时候，应当建立在风险分析过程中进行风险评价的时候，应当建立一个三元组：一个三元组：ori，li，xio其中，其中，ri是风险，是风险，li是风险出现的可能性（概率），是风险出现的可能性（概率），而而xi是风险的影响。在做风险评价时，应当进一步是风险的影响。在做风险评价时，应当进一步检验在风险估计时所得到的估计的准确性，尝试对检验在风险估计时所得到的估计的准确性，尝试对已暴露的风险进行优先排队，并着手考虑控制和已暴露的风险进行优先排队，并着手考虑控制和（或）消除可能出现风险的方法。（或）消除可能出现风险的方法。2北29风险参照水准风险参照水准o一个对风险评价很有用的技术就是定义风险参照水准。一个对风险评价很有用的技术就是定义风险参照水准。o如果因为风险的一个组合引出造成项目成本和进度超出的问题，将有一如果因为风险的一个组合引出造成项目成本和进度超出的问题，将有一个水准（在图中用曲线表示），当超出时，将导致项目终止（图中封闭个水准（在图中用曲线表示），当超出时，将导致项目终止（图中封闭区域）。区域）。图19-5 风险参照水准2北30风险评价的步骤风险评价的步骤o多数情况中，参照点不是一条平滑的曲线，而是一多数情况中，参照点不是一条平滑的曲线，而是一个区域，这个区域可能是易变动的区域，在这些区个区域，这个区域可能是易变动的区域，在这些区域内想要作出基于参照值组合的管理判断往往是不域内想要作出基于参照值组合的管理判断往往是不准确的。因此，在做风险评价时，按以下步骤执行：准确的。因此，在做风险评价时，按以下步骤执行：o（1）为项目定义风险参照水准。）为项目定义风险参照水准。o（2）尝试找出在每个）尝试找出在每个ri，li，xi和每个参照水和每个参照水准之间的关系。准之间的关系。o（3）预测参照点，定义一个终止区域，用一条曲）预测参照点，定义一个终止区域，用一条曲线或一些易变动区域来界定。线或一些易变动区域来界定。o（4）努力预测复合的风险组合将如何形成一个参）努力预测复合的风险组合将如何形成一个参照水准。照水准。2北3119.4.4 风险驾驭和监控风险驾驭和监控o风险驾驭步骤：风险驾驭步骤：o（1）与现在在职的人员协商，确定人员流动的原）与现在在职的人员协商，确定人员流动的原因（如工作条件差、收入低、人才市场竞争等）。因（如工作条件差、收入低、人才市场竞争等）。o（2）在项目开始之前，把缓解这些原因（避开风）在项目开始之前，把缓解这些原因（避开风险）的工作列入已拟定的驾驭计划中。险）的工作列入已拟定的驾驭计划中。o（3）当项目启动时，做好人员流动会出现的准备。）当项目启动时，做好人员流动会出现的准备。采取一些办法以确保人员一旦离开时项目仍能继续采取一些办法以确保人员一旦离开时项目仍能继续（削弱风险）。（削弱风险）。o（4）建立项目组，以使大家都了解有关开发活动）建立项目组，以使大家都了解有关开发活动的信息。的信息。2北32o（5）制定文档标准，并建立一种机制以保证文档）制定文档标准，并建立一种机制以保证文档能够及时产生。能够及时产生。o（6）对所有工作组织细致的评审（以使更多的人）对所有工作组织细致的评审（以使更多的人能够按计划进度来完成自己的工作）。能够按计划进度来完成自己的工作）。o（7）对每一个关键性的技术人员，要培养后备人）对每一个关键性的技术人员，要培养后备人员。员。2北33o图图19-6表示风险驾驭步骤要写进风险驾驭与监控计划表示风险驾驭步骤要写进风险驾驭与监控计划RMMP（Risk Management and Monitoring Plan）。）。RMMP记叙了风险分记叙了风险分析的全部工作。析的全部工作。图19-6 风险驾驭与监控2北34RMMP的主要内容的主要内容 图19-7风险驾驭与监控计划概要2北35风险监控的三个主要目标风险监控的三个主要目标o（1）判断一个预测的风险事实上是否发生了。）判断一个预测的风险事实上是否发生了。o（2）确保针对某个风险而制定的风险消除步骤正）确保针对某个风险而制定的风险消除步骤正在合理地实施。在合理地实施。o（3）收集可用于将来的风险分析的信息。）收集可用于将来的风险分析的信息。o实际上，项目中发生的问题总能追踪到许多风险。实际上，项目中发生的问题总能追踪到许多风险。风险监控的另一项工作就是要把风险监控的另一项工作就是要把“责任责任”（什么风（什么风险导致问题发生）分配到项目中去。虽然风险分析险导致问题发生）分配到项目中去。虽然风险分析会增大成本，但是相对于因为严重的风险发生而没会增大成本，但是相对于因为严重的风险发生而没有采取有效的措施造成的项目损失来说，这些工作有采取有效的措施造成的项目损失来说，这些工作量花得值得。量花得值得。2北3619.5 进度安排进度安排o软件开发项目的进度安排有两种考虑方式：软件开发项目的进度安排有两种考虑方式：o（1）系统最终交付日期已经确定，软件开发部门）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成。必须在规定期限内完成。o（2）系统最终交付日期只确定了大致的年限，最）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。后交付日期由软件开发部门确定。2北3719.5.1 软件开发小组人数与软件生产率软件开发小组人数与软件生产率o在软件开发中，生产率和人数往往是成反比的。在在软件开发中，生产率和人数往往是成反比的。在通常情况下，一个人的开发小组效率是最高的。主通常情况下，一个人的开发小组效率是最高的。主要的原因是减少了人员之间的通信和理解工作量。要的原因是减少了人员之间的通信和理解工作量。但是，不可能让一个人工作但是，不可能让一个人工作10年，而是让年，而是让10个人个人工作工作1年去进行软件开发。因此，需要多人组成开年去进行软件开发。因此，需要多人组成开发小组共同参加一个项目的开发。多个人开发同一发小组共同参加一个项目的开发。多个人开发同一个项目会产生通信问题，对接口、设计的理解。通个项目会产生通信问题，对接口、设计的理解。通信需花费时间和代价，降低软件生产率。信需花费时间和代价，降低软件生产率。o但是小组这种软件开发形式便于开展质量保证活动，但是小组这种软件开发形式便于开展质量保证活动，可以获得更完善的软件分析与设计，从而减少因为可以获得更完善的软件分析与设计，从而减少因为软件分析引起的错误数，从而降低测试工作量。软件分析引起的错误数，从而降低测试工作量。2北3819.5.2 任务的确定与并行性任务的确定与并行性o当参加同一个软件工程项目的人数不止一人的时候，开发工当参加同一个软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。作就会出现并行情形。图19-8 软件项目的并行性2北3919.5.3 制定开发进度计划制定开发进度计划表表19-3 进度分配百分比表进度分配百分比表表表19-4 更精确的进度分配表更精确的进度分配表 阶段需求分析设计编码与单元测试组装与测试占开发时间的百分比1030172725601628总体类型阶段分配规模（KDSI）微型2小型8中型32大型128特大型512组织型计划与需求设计编码与单元测试组装与测试10111217191919196359555118222630半独立型计划与需求设计编码与单元测试组装与测试1618202224242526272856524844402023262932嵌入型计划与需求设计编码与单元测试组装与测试24283236403032343638484440363222242628302北4019.5.4 进度安排的图形方法进度安排的图形方法o甘特图（甘特图（Gantt Chart）是常用的多任务安排工）是常用的多任务安排工具。用水平线段表示任务的工作阶段，用垂直线表具。用水平线段表示任务的工作阶段，用垂直线表示当前的执行情况；线段的起点和终点分别对应着示当前的执行情况；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务的开工时间和完成时间；线段的长度表示完成任务所需的时间。任务所需的时间。o在甘特图中，任务完成的标准是以应交付的文档与在甘特图中，任务完成的标准是以应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图的优点是标明审是软件开发进度的里程碑。甘特图的优点是标明了各任务的计划进度和当前进度，能动态地反映软了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。缺点是难以反映多个任务之间存件开发进展情况。缺点是难以反映多个任务之间存在的复杂的逻辑关系。在的复杂的逻辑关系。2北41o如图如图19-9所示给出一个具有所示给出一个具有5个任务的甘特图（任务名分个任务的甘特图（任务名分别为别为A、B、C、D、E）。从甘特图上可以很清楚地看出各）。从甘特图上可以很清楚地看出各子任务在时间上的对比关系。子任务在时间上的对比关系。图图19-9 甘特图甘特图 2北4219.5.5 项目的追踪和控制项目的追踪和控制o一件事情，无论计划做得多完美，如果没有严格的过程管理，一件事情，无论计划做得多完美，如果没有严格的过程管理，执行不力，失败的可能性非常大。软件项目管理的一项重执行不力，失败的可能性非常大。软件项目管理的一项重要工作就是在项目实施过程中进行追踪，对过程进行严格要工作就是在项目实施过程中进行追踪，对过程进行严格的控制。可以用以下不同的方式进行追踪：的控制。可以用以下不同的方式进行追踪：o（1）定期举行项目状态会议。在会上，每一位项目成员报）定期举行项目状态会议。在会上，每一位项目成员报告他的进展和遇到的问题。告他的进展和遇到的问题。o（2）评价在软件工程中所产生的所有评审的结果。）评价在软件工程中所产生的所有评审的结果。o（3）确定由项目的计划进度所安排的可能选择的正式的里）确定由项目的计划进度所安排的可能选择的正式的里程碑。程碑。o（4）比较在项目资源表中所列出的每一个项目任务的实际）比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。开始时间和计划开始时间。o（5）非正式地与开发人员交谈，以得到他们对开发进展和）非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。刚冒头的问题的客观评价。2北4319.6 软件项目的组织软件项目的组织19.6.1 软件项目管理的特点软件项目管理的特点1.软件项目的特点软件项目的特点o1）智力密集，可见性差o2）单件生产o3）劳动密集，自动化程度低o4）软件工作渗透了人的因素2北442.软件管理的主要职能软件管理的主要职能o软件管理的主要职能包括：软件管理的主要职能包括：o（1）制定计划：规定待完成的任务、要求、资源、）制定计划：规定待完成的任务、要求、资源、人力和进度等。人力和进度等。o（2）建立组织：为实施计划，保证任务的完成，）建立组织：为实施计划，保证任务的完成，需要建立分工明确的责任制机构。需要建立分工明确的责任制机构。o（3）配备人员：任用各种层次的技术人员和管理）配备人员：任用各种层次的技术人员和管理人员。人员。o（4）指导：鼓励和动员软件人员完成所分配的工）指导：鼓励和动员软件人员完成所分配的工作。作。o（5）检验：对照计划或标准，监督和检查实施的）检验：对照计划或标准，监督和检查实施的情况。情况。2北4519.6.2 软件项目组织的建立软件项目组织的建立o建立一个好的组织来进行软件开发，是一切软件项建立一个好的组织来进行软件开发，是一切软件项目开发能够顺利进行的必要条件之一。目开发能够顺利进行的必要条件之一。o在建立软件开发的组织时，要注意：在建立软件开发的组织时，要注意：o（1）尽早落实责任：在软件项目工作的开始，就）尽早落实责任：在软件项目工作的开始，就要指定专人负责。使他有权进行管理，并对任务的要指定专人负责。使他有权进行管理，并对任务的完成负全责。完成负全责。o（2）减少接口：在开发过程中，人与人之间的联）减少接口：在开发过程中，人与人之间的联系是必不可少的，组织应该有合理的分工、好的组系是必不可少的，组织应该有合理的分工、好的组织结构，以减少不必要通信。织结构，以减少不必要通信。o（3）责权均衡：软件经理人员所负的责任不应比）责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。委任给他的权力还大。2北46软件开发组织建立的三种模式软件开发组织建立的三种模式o1.按课题划分的模式（按课题划分的模式（Project Format）o2.按职能划分的模式（按职能划分的模式（Functional Format）o3.矩阵形模式（矩阵形模式（Matrix Format）图19-10软件开发组织的矩阵形模式2北47程序设计小组的组织形式：程序设计小组的组织形式：o在程序设计小组中典型的有三种组织形式。如图在程序设计小组中典型的有三种组织形式。如图19-11所示，上排的三种为结构形式，下排的三所示，上排的三种为结构形式，下排的三种为通信路径种为通信路径 图19-11三种不同的小组结构 2北48（1）主程序员制小组（）主程序员制小组（Chief Programmer Team）o小组的核心由小组的核心由1位主程序员（高级工程师）、位主程序员（高级工程师）、2至至5位技术位技术员、员、1位后援工程师组成，另外还可以有部分辅助人员（资位后援工程师组成，另外还可以有部分辅助人员（资料员）。料员）。图图19-12 主程序员小组的组织主程序员小组的组织o主程序员制的开发小组强调主程序员与其他技术人员的直接主程序员制的开发小组强调主程序员与其他技术人员的直接联系，简化了技术人员之间的横向通信，如图联系，简化了技术人员之间的横向通信，如图19-11（a）所示。这种组织制度的工作效果的好坏很大程度）所示。这种组织制度的工作效果的好坏很大程度上取决于主程序员的技术水平和管理才能。上取决于主程序员的技术水平和管理才能。2北49（2）民主制小组（）民主制小组（Democratic Team）o在民主制小组中也设置一位组长，但是每当遇到问在民主制小组中也设置一位组长，但是每当遇到问题，组内成员之间可以平等地交换意见，如图题，组内成员之间可以平等地交换意见，如图19-11（b）所示。）所示。o工作目标的制定及做出决定都由全体成员参加。这工作目标的制定及做出决定都由全体成员参加。这种组织形式强调发挥小组每个成员的积极性、主动种组织形式强调发挥小组每个成员的积极性、主动精神和协作精神。缺点是会削弱了个人责任心和必精神和协作精神。缺点是会削弱了个人责任心和必要的权威作用。这种组织形式适合于研制时间长、要的权威作用。这种组织形式适合于研制时间长、开发难度大的项目。开发难度大的项目。2北50（3）层次式小组（）层次式小组（Hierarchical Team）o如图如图19-11（c）所示，在层次式小组中，组内人）所示，在层次式小组中，组内人员分为三级：组长（项目负责人）员分为三级：组长（项目负责人）1人负责全组工人负责全组工作。他直接领导作。他直接领导23名高级程序员，每位高级程名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种组织序员通过基层小组，管理若干位程序员。这种组织结构特点比较适合的项目就是层次结构状的课题，结构特点比较适合的项目就是层次结构状的课题，可以按组织形式划分课题，然后把子项目分配给基可以按组织形式划分课题，然后把子项目分配给基层小组，由基层小组完成。对于大型项目，可以通层小组，由基层小组完成。对于大型项目，可以通过层次式划分将项目需要划分成若干层，因此，大过层次式划分将项目需要划分成若干层，因此，大型软件项目的开发比较适合于这种组织方式。型软件项目的开发比较适合于这种组织方式。2北51o在实际应用中，组织形式并不是一成不变的，可以在实际应用中，组织形式并不是一成不变的，可以根据问题的特点调整。但是调整的幅度过大，会造根据问题的特点调整。但是调整的幅度过大，会造成成员之间的交流不顺。成成员之间的交流不顺。o总之，软件开发小组的主要目的是发挥集体的力量总之，软件开发小组的主要目的是发挥集体的力量进行软件研制。因此，小组培养从进行软件研制。因此，小组培养从“全局全局”的观点的观点出发进行程序设计，消除软件的出发进行程序设计，消除软件的“个人个人”性质，并性质，并促进更充分的复审，小组提倡在共同工作中互相学促进更充分的复审，小组提倡在共同工作中互相学习从而改善软件的质量。习从而改善软件的质量。2北5219.6.3 人员配备人员配备图19-13 软件项目人力配备情况 2北53配备人员时应该遵循如下的原则配备人员时应该遵循如下的原则o根据软件开发各阶段对人力的需求情况，配备人员根据软件开发各阶段对人力的需求情况，配备人员时应该遵循如下的原则：时应该遵循如下的原则：o（1）重质量：软件项目是技术性很强的工作，任）重质量：软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用较多的经验不足的人员要更有任务，常常要比使用较多的经验不足的人员要更有效。效。o（2）重培训：花力气培养所需的技术人员和管理）重培训：花力气培养所需的技术人员和管理人员是有效解决人员问题的好方法。人员是有效解决人员问题的好方法。o（3）双阶段提升：人员的提升应分别按技术职务）双阶段提升：人员的提升应分别按技术职务和管理职务进行，不能混在一起。和管理职务进行，不能混在一起。2北541.对项目经理人员的要求对项目经理人员的要求o软件经理人员是工作的组织者，他的管理能力的强软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。除去一般的管理要求外，他弱是项目成败的关键。除去一般的管理要求外，他应具有以下能力：应具有以下能力：o（1）把用户提出的非技术性要求加以整理提炼，）把用户提出的非技术性要求加以整理提炼，以技术说明书形式转告给分析员和测试员。以技术说明书形式转告给分析员和测试员。o（2）能说服用户放弃一些不切实际的要求，以便）能说服用户放弃一些不切实际的要求，以便保证合理的要求得以满足。保证合理的要求得以满足。o（3）能够综合用户的需求，归结为）能够综合用户的需求，归结为“需要什么需要什么”，“要解决什么问题要解决什么问题”。o（4）同用户和上级有很强的沟通能力，能清晰明）同用户和上级有很强的沟通能力，能清晰明白地了解对方的思想和表达自己的思想。白地了解对方的思想和表达自己的思想。2北552.评价人员的条件评价人员的条件o（1）牢固掌握计算机软件的基本知识和技能。）牢固掌握计算机