软件工程第13章软件项目管理

2/97 罗伯特罗伯特.J.格雷厄姆格雷厄姆(美国著名学者美国著名学者)：因为项目是适应环境变化的普遍方式，故因为项目是适应环境变化的普遍方式，故而一个组织的成功与否将取决于其管理项而一个组织的成功与否将取决于其管理项目的水平目的水平 项目管理权威机构项目管理权威机构PMI：项目管理协会：项目管理协会Project Management Institute 项目的定义项目的定义(PMI)：一种被承办的旨在创：一种被承办的旨在创造某种独特产品或服务的暂时性努力造某种独特产品或服务的暂时性努力3/97 软件危机后的普遍性结论：软件项目成功软件危机后的普遍性结论：软件项目成功率非常低的原因可能是项目管理能力太弱率非常低的原因可能是项目管理能力太弱 软件项目管理是指软件生存周期中软件管软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一理者所进行的一系列活动，其目的是在一定的时间和预设范围内，有效地利用人力、定的时间和预设范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成品按原定计划和质量要求如期完成 4/97 软件项目管理概述软件项目管理概述 软件项目估算软件项目估算 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结5/97 软件项目估算软件项目估算 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结6/97 项目管理是通过项目经理和项目组织的努项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系项目的特定目标的管理方法体系(软件软件)项目管理的基本内容：项目管理的基本内容：项目定义、项目计划、项目执行、项目控项目定义、项目计划、项目执行、项目控制、项目结束制、项目结束7/97 人员人员(People)人员是软件工程项目的基本要素和关键因素在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)的人员类型 产品产品(Product,Problem)定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等 过程过程(Process)通常将项目分解为任务子任务等，其分解准则是基于软件工程的过程 项目项目(Project)采用科学的方法及工具对项目基本内容进行管理 8/97 项目管理人员项目管理人员 负责软件项目的管理工作，其负责人通常称为项目经理 高级管理人员高级管理人员 可以是领域专家，负责提出项目的目标并对业务问题进行定义 开发人员开发人员 掌握了开发一个产品或应用所需的专门技术，可胜任包括需求分析、设计、编码、测试、发布等各种相关的开发岗位 客户客户 一组可说明待开发软件的需求的人，也包括与项目目标有关的其它风险承担者 最终用户最终用户 产品或应用提交后与产品/应用进行交互的9/97 定义项目范围，其中包括建立产品的目的和范定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束围、可选的解决方案、技术或管理的约束 目的：从客户的角度定义该产品的总体目标，目的：从客户的角度定义该产品的总体目标，但不必考虑这些目标如何实现但不必考虑这些目标如何实现 软件范围定义了与软件产品相关的数据、功能软件范围定义了与软件产品相关的数据、功能和行为，及其相关的约束：和行为，及其相关的约束：语境(context)：说明待建造的软件与其它相关系统、产品或环境的关系，以及相关的约束条件信息目标：说明目标系统所需要的输入数据及应产生的输出数据功能和性能：说明软件应提供的功能来完成输入数据到输出数据的变换以及给出对目标软件的性能要求10/97 对项目进行有计划和可控制的管理对项目进行有计划和可控制的管理 明确目标及过程：充分理解被解决的问题，明确定义项目目标及软件范围，为项目小组及活动设置明确、现实的目标，并充分发挥相关小组的自主性 保持动力：提供激励措施使人员变动最小 跟踪进展：对每个任务的进展进行跟踪，并对其软件过程和质量进行度量 做出聪明的决策：项目管理者和软件小组的决策应该“保持其简单”项目总结：从每个完成的项目中获取可学习的经验11/97选择项目标识项目的范围和目的标识项目基础设施分析项目的特征选择软件过程模型标识项目的产品和活动估计活动的资源评审较低层次的细节标识活动的风险分配资源较低层次的策划评审发布计划执行计划对于每个活动启动软件项目建立项目组织12/97 在软件项目启动前对项目进行可行性分析，以在软件项目启动前对项目进行可行性分析，以明确项目的目标和范围，从而确定：合理精确明确项目的目标和范围，从而确定：合理精确的成本分析；实际可行的任务分解；可管理的的成本分析；实际可行的任务分解；可管理的进度安排进度安排 在多个项目方案中选择一个相对完善的方案在多个项目方案中选择一个相对完善的方案 考虑交付期限、预算、个人能力、技术界面等限制条件 在正式启动软件项目前组成项目组，并召开项在正式启动软件项目前组成项目组，并召开项目启动会议，内容包括：项目组的初步交流；目启动会议，内容包括：项目组的初步交流；进一步对项目目标理解；对组织形式、管理方进一步对项目目标理解；对组织形式、管理方式、方针的一致认识；明确岗位职责式、方针的一致认识；明确岗位职责13/97 在项目经理领导下，组织不同类型的项目组成在项目经理领导下，组织不同类型的项目组成员共同协作完成软件项目员共同协作完成软件项目 存在多种可选的项目组织结构，组织结构的选存在多种可选的项目组织结构，组织结构的选择对项目的成败具有很大影响择对项目的成败具有很大影响 规划软件工程项目组织结构时考虑如下因素：规划软件工程项目组织结构时考虑如下因素：待解决问题的困难程度 目标系统的规模，可用代码行或功能点来度量 项目组的生存期，即项目小组需要共同工作的时间 问题可被分解的程度 对目标系统要求的质量和可靠性 可供开发时间的紧迫性，即交付时间的严格程度 项目组内部的通信的复杂性，即成员(小组)之间正式或非正式通信的机制14/97 项目计划是项目组织根据软件项目的目标及项目计划是项目组织根据软件项目的目标及范围，对项目实施中进行的各项活动进行周范围，对项目实施中进行的各项活动进行周密的计划密的计划 项目计划根据项目目标确定项目的各项任务、项目计划根据项目目标确定项目的各项任务、安排任务进度、编制完成任务所需的资源预安排任务进度、编制完成任务所需的资源预算等算等 项目计划包括：工作计划、人员组织计划、项目计划包括：工作计划、人员组织计划、设备采购计划、变更控制计划、进度控制计设备采购计划、变更控制计划、进度控制计划、财务计划、文件控制计划、应急计划等划、财务计划、文件控制计划、应急计划等15/97 项目估算是制定项目计划的基础项目估算是制定项目计划的基础 项目所需的人力(以人月为单位)、项目持续时间(以年份或月份为单位)、成本(以元为单位)等 参照以前类似项目中的相关数据进行估算参照以前类似项目中的相关数据进行估算 若存在类似历史项目则可进行类比估算 若缺少可类比的项目数据则采用特定的估算技术(例如功能点估算方法等)通常采用多种估算技术进行交叉检查通常采用多种估算技术进行交叉检查16/97 进度安排进度安排 将项目划分成可管理的子项目、任务和活动 确定任务之间的依赖关系，找出影响项目按期完成的关键任务 为每个任务分配时间、工作量以及指定责任人，定义每个任务的输出结果及其关联的里程碑 在项目实施过程中将在进度计划基础上跟在项目实施过程中将在进度计划基础上跟踪实际执行情况，从而及时发现偏差并采踪实际执行情况，从而及时发现偏差并采取措施加以调整以确保项目按期完成取措施加以调整以确保项目按期完成17/97 跟踪是控制的前提，它实际上是在项目实跟踪是控制的前提，它实际上是在项目实施过程中对影响项目进展的内外部因素进施过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的行及时的、连续的、系统的记录和报告的活动，其核心在于反映项目变化、提供相活动，其核心在于反映项目变化、提供相关信息的报告关信息的报告 控制是通过工具和技术对项目计划与实际控制是通过工具和技术对项目计划与实际执行进行对比，并对项目的未来走向进行执行进行对比，并对项目的未来走向进行预测，再此基础上进行项目的各种调整预测，再此基础上进行项目的各种调整18/97 Software Confignation Management(SCM)任务：标识和确定系统中的配置项，在系任务：标识和确定系统中的配置项，在系统整个生命期内控制这些项的发布和变更，统整个生命期内控制这些项的发布和变更，记录并报告配置的状态和变更要求，验证记录并报告配置的状态和变更要求，验证配置项的完整性和正确性配置项的完整性和正确性 SCM存在于整个软件过程中，是一种保存在于整个软件过程中，是一种保护性活动护性活动19/97 软件项目管理概述软件项目管理概述 软件项目估算软件项目估算 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结20/97 软件项目管理概述软件项目管理概述 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结21/97 估算软件规模 代码行技术代码行技术(KLOC)功能点技术功能点技术(FP)工作量估算(E 人月)各种经验公式各种经验公式 静态单变量模型静态单变量模型:E=f(FP),E=f(KLOC),动态多变量模型动态多变量模型:E=(LOC X B0.333/P)3X(1/T)4 COCOMO2模型模型 E=a x KLOCb xfi 22/97 常用的估算方法：常用的估算方法：基于已经完成的类似项目进行估算，这是一种常用的也是有效的估算方法 基于分解技术进行估算 问题分解是将一个复杂问题分解成若干个小问题，通过对问题分解是将一个复杂问题分解成若干个小问题，通过对小问题的估算得到复杂问题的估算小问题的估算得到复杂问题的估算 过程分解指先根据软件开发过程中的活动过程分解指先根据软件开发过程中的活动(分析、设计、编分析、设计、编码、测试等码、测试等)进行估算，然后得到整个项目的估算值。进行估算，然后得到整个项目的估算值。基于经验估算模型的估算。典型的经验估算模型有CoCoMo模型和Putnam模型。上述方法可以组合使用以提高估算的精度上述方法可以组合使用以提高估算的精度23/97 软件规模通常是指软件的大小软件规模通常是指软件的大小(size)，一，一般用代码行度量般用代码行度量 优点：方便、直观 缺点：很大程度上取决于程序设计语言以及软件设计的质量 测量出软件规模后可方便地度量其它软测量出软件规模后可方便地度量其它软件属性，包括：件属性，包括：度量名度量名含义及表示含义及表示LOC或KLOC代码行数或千行代码数生产率PP=LOC/E，E为开发的工作量(常用人月数表示)每行代码平均成本CC=S/LOC，S为总成本文档代码比DD=Pe/KLOC，其中Pe为文档页数代码错误率EQREQR=N/KLOC，其中N为代码中错误数24/97 一种针对软件的功能特性进行度量的方法一种针对软件的功能特性进行度量的方法 主要考虑软件系统的主要考虑软件系统的“功能性功能性”和和“实用实用性性”功能点度量：基于软件信息域的特征功能点度量：基于软件信息域的特征(可可直接测量直接测量)和软件复杂性进行规模度量和软件复杂性进行规模度量 功能点度量方法步骤：功能点度量方法步骤：计算信息域特征的值CT 计算复杂度调整值 计算功能点FP25/97对五个信息域特征及其含义对五个信息域特征及其含义(上表上表)统计相应的特征值，然后根据信息域特征统计相应的特征值，然后根据信息域特征的复杂程度选择适当的加权因子进行计算的复杂程度选择适当的加权因子进行计算(下表下表)，得到总计的，得到总计的CT值值测量参数用户输入数用户输出数用户查询数文件数外部接口数总计CT特征值加权因子简单中间复杂结果（=特征值加权因子）34645764375101571026/97复杂度调整值复杂度调整值Fi(i=1到到14)是基于对左表中问题的回答而得是基于对左表中问题的回答而得到的值，对每个问题回答的取值范围是到的值，对每个问题回答的取值范围是0到到5，见右表，见右表问题1234567891011121314总计系统需要可靠的备份和恢复吗？需要数据通信吗？有分布处理功能吗？性能很关键吗？系统是否在一个现存的、重负的操作环境中运行？系统需要联机数据登录？联机数据登录是是否需要在多屏幕或多操作之间切换以完成输入？需要联机更新文件吗？输入、输出、文件或查询很复杂吗？内部处理复杂吗？代码需要被设计成可复用的吗？设计中需要包括转换及安装吗？系统的设计支持不同组织的多次安装吗？应用的设计方便用户修改和使用吗？Fi（0-5）值值定义定义0没有影响没有影响1偶然的偶然的2适中的适中的3普通的普通的4重要的重要的5极重要的极重要的27/97 功能点计算公式功能点计算公式FP=CT*(0.65+0.01*F)其中：CT是步骤1得到的“总计数值”，F是步骤2得到的Fi之和 一旦计算出功能点，则用类似代码行的方法来一旦计算出功能点，则用类似代码行的方法来计算软件生产率、质量及其他属性计算软件生产率、质量及其他属性度量名含义表示生产率PP=FP/E，E为开发的工作量（常用人月数表示）每个功能点成本CC=S/FP，S为总成本每个功能点文档数DD=Pe/FP，其中Pe为文档页数功能点错误率EQREQR=N/FP，其中N为错误数28/97 1.请若干名有经验的技术人员或管理人员，采请若干名有经验的技术人员或管理人员，采用上述估算办法的一种或多种，分别估算出代用上述估算办法的一种或多种，分别估算出代码行码行LOC或功能点或功能点FP的乐观值的乐观值ai，悲观值，悲观值bi及及最有可能的值最有可能的值mi 2.计算出平均值计算出平均值a，b，m 3.LOC或或FP的规模估算值：的规模估算值：e(a4mb)/6 4.根据以前该组织软件开发的平均生产率根据以前该组织软件开发的平均生产率(规模规模/人月数人月数)和平均成本和平均成本(资金资金/规模规模)计算工作量估计算工作量估算值和成本估算值算值和成本估算值 工作量估算值工作量估算值e/平均生产率平均生产率 成本估算值成本估算值e*平均成本平均成本29/97 Boehm提出的提出的“构造性成本模型构造性成本模型”Constructive Cost Model,CoCoMo30/97 一种软件项目工作量估算的动态多变量模型一种软件项目工作量估算的动态多变量模型他根据一些大型软件项目(30人年以上)的工作量分布情况，推导出软件项目在软件生存周期各阶段的工作量分布，如图所示图中的工作量分布曲线与著名的Reyleigh-norden曲线相似系统定义系统定义功能设计规格说明功能设计/规格说明测试与确认设计与编码安装总工作量系统开发运行与维护开发工作=总工作量的40%修正与提高性能工作总工作量的60人工（人年）31/97 软件项目管理概述软件项目管理概述 软件项目估算软件项目估算 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结32/97 目标：确保软件项目在规定的时间内按期完成目标：确保软件项目在规定的时间内按期完成 项目进度管理任务项目进度管理任务定义所有的项目任务以及它们之间的依赖关系制订项目的进度安排规划每个任务所需的工作量和持续时间在项目开发过程中不断跟踪项目的执行情况，发现那些未按计划进度完成的任务对整个项目工期的影响，并及时进行调整 制定进度计划的两种情况制定进度计划的两种情况客户方都规定了明确的交付日期，此时进度安排必须在此约束下进行只规定了大致的时间界限，最终的交付日期由开发组织确定，此时的进度安排可以比较灵活，工作量的分布可考虑对资源的充分利用33/97 划分：项目必须被划分成若干可以管理的活动划分：项目必须被划分成若干可以管理的活动和任务，为了实现项目的划分，对产品和过程和任务，为了实现项目的划分，对产品和过程都需要进行分解都需要进行分解 相互依赖性：确定各个被划分的活动或任务之相互依赖性：确定各个被划分的活动或任务之间的相互关系，有些任务必须是串行的，有些间的相互关系，有些任务必须是串行的，有些可能是并行的可能是并行的 时间分配：必须为每个被调度的任务分配一定时间分配：必须为每个被调度的任务分配一定数量的工作单位此外还必须为每个任务制定开数量的工作单位此外还必须为每个任务制定开始和结束日期，这些日期是相互依赖的始和结束日期，这些日期是相互依赖的 工作量确认：确保在任意时段中分配给任务的工作量确认：确保在任意时段中分配给任务的人员数量不会超过项目组中的人员数量人员数量不会超过项目组中的人员数量34/97 定义责任：每个被调度的任务都应该指定定义责任：每个被调度的任务都应该指定某个特定的小组成员来负责某个特定的小组成员来负责 定义结果：每个被调度的任务都应该有一定义结果：每个被调度的任务都应该有一个确定的输出结果个确定的输出结果 定义里程碑：每个任务或任务组都应该与定义里程碑：每个任务或任务组都应该与一个项目里程碑相关联一个项目里程碑相关联(当一个或多个工当一个或多个工作产品经过质量评审并且得到认可时，标作产品经过质量评审并且得到认可时，标志着一个里程碑的完成志着一个里程碑的完成)35/97 人员之间的交流开销：一个由人员之间的交流开销：一个由n个人组成个人组成的项目组内共存在的项目组内共存在n(n1)/2条通信路径条通信路径 对于生产率的影响：对于生产率的影响：增加一个人并不等于净增了一个人的工作量，应扣除相应的通信代价每个开发小组的成员不宜太多，通过合理的组织形式减少组内的通信路径数在开发过程中尽量不要中途加人，避免太多的生产率损失 参与项目的人员数与整体生产率之间的关参与项目的人员数与整体生产率之间的关系并非是线性的系并非是线性的（a）四人之间所有通信路径（b）六人之间所有通信路径36/97 为了缩短开发进度，应该根据不同的软件为了缩短开发进度，应该根据不同的软件项目性质，选择合适的软件工程过程项目性质，选择合适的软件工程过程 对软件项目的任务进行分解，并从中找出对软件项目的任务进行分解，并从中找出其串行成分及并行成分其串行成分及并行成分 由于并行任务是同时发生的，因而在制订由于并行任务是同时发生的，因而在制订进度计划表时必须确定任务之间的从属关进度计划表时必须确定任务之间的从属关系，即确定各个任务的先后次序和衔接关系，即确定各个任务的先后次序和衔接关系，确定各个任务完成的持续时间系，确定各个任务完成的持续时间37/97需求分析需求评审概要设计详细设计*设计走查编码编码走查单元测试测试过程测试评审集成测试确认测试*测试计划38/97 根据软件工程过程的不同，可确定其相应根据软件工程过程的不同，可确定其相应的任务的工程量分配的任务的工程量分配 常用的有40-20-40规则：在整个软件开发过程中，编码工作量仅占20%，编码前工作量占40%，编码后工作量占40%CoCoMo模型按目标程序规模对不同任务工作量分配的比例：在实际应用时，按此比例确定各个阶段工作量的分配，从而进一步确定每一阶段所需的开发时间，然后在每个阶段，进行任务分解，对各个任务再进行工作量和开发时间的分配39/97 通用的项目进度安排工具和技术可以直接应用于通用的项目进度安排工具和技术可以直接应用于软件项目软件项目 为监控软件项目的进度计划和工作的实际进展情为监控软件项目的进度计划和工作的实际进展情况，表现各项任务之间进度的相互依赖关系，需况，表现各项任务之间进度的相互依赖关系，需要采用图示的方法明确标识：要采用图示的方法明确标识：各个任务的计划开始时间和完成时间 各个任务的完成标志 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况 完成各个任务所需的物理资源和数据资源 甘特图和网络图是两种常用的图示方法甘特图和网络图是两种常用的图示方法40/97 也称时间表也称时间表(Timeline chart)，用来建立，用来建立项目进度表项目进度表 在甘特图中，每项任务的完成以必须交付在甘特图中，每项任务的完成以必须交付的文档和通过评审为标准的文档和通过评审为标准 因此在甘特图中，文档编制与评审是软件因此在甘特图中，文档编制与评审是软件开发进度的里程碑开发进度的里程碑 41/97工作任务第一周第二周第三周第四周第五周I.1.1识别需要和效益会见客户识别需要和项目约束建立产品陈述里程碑：定义的产品陈述I.1.2定义希望的输入/控制/输入（OCI）确定键盘功能确定语音输入功能确定交互模式确定文档诊断确定其他WP功能将OCI做成文档FTR：与客户一起评审OCI必要时修改OCI里程碑：定义的OCII.1.3定义功能/行为定义键盘功能定义语音输入性能描述交互模式描述拼写/语法检查描述其他WP功能FTR：与客户一起评审OCI定义里程碑：完成的OCI定义I.1.4分离软件要素里程碑：定义的软件要素I.1.5研究现有软件的可用性研究文本编辑构件研究语音输入构件研究文件管理构件研究拼写/语法检查构件里程碑：识别的可复用构件I.1.6定义技术可行性评估语音输入评估文法检查里程碑：评估的技术可行性I.1.7快速估算规模I.1.8创建范围定义与客户一起评审范围文档必要时修改文档里程碑：完成的范围文档42/97 计划评审技术计划评审技术(PERT)program evaluation and review technique 关键路径方法关键路径方法(CPM)critical path method 安排开发进度、制定软件开发计划的常用方法安排开发进度、制定软件开发计划的常用方法 原理：采用网络图描述一个项目的任务网络，原理：采用网络图描述一个项目的任务网络，把应当完成的任务用图或表的形式表示出来把应当完成的任务用图或表的形式表示出来43/97 PERT图是一种有向图图是一种有向图图中的箭头表示任务(或作业)，箭头上可标上完成该任务所需的时间图中的结点(事件)表示流入该结点的任务已完成，可以开始流出该结点的任务仅当所有流入结点的任务都完成时，流出该结点的任务才同时开始事件本身不消耗时间和资源，它仅代表某个时间点一个任务可由事件之间的箭头来表示，二个事件之间仅可存在一条箭头为了表示任务之间的关系，可以引入空任务，空任务完成的时间为0事件号最早时刻最迟时刻完成任务所需的时间（机动时间）44/97 每个事件用一个事件号进行标记，每个事件用一个事件号进行标记，对每个事件定义：对每个事件定义：最早时刻：表示所有到达该事件的任务最早在此时刻时完成，或从该事件出发的任务最早在此时刻时才可开始 最迟时刻：最迟时刻表示所有到达该事件的任务最迟必须在此时刻完成，或从该事件出发的任务最迟必须在此时刻时开始，否则整个工程就无法按期完成45/97 机动时间：在不影响整个工期的情况下，机动时间：在不影响整个工期的情况下，当前任务允许延迟的最长时间当前任务允许延迟的最长时间 通过计算每个任务的机动时间来求项目的通过计算每个任务的机动时间来求项目的关键路径关键路径 方法步骤：方法步骤：计算最早时刻EFT 计算最迟时刻LET 计算机动时间 得出关键路径：由机动时间为0的任务组成的项目路径46/97设：设：(i，j)为联结事件为联结事件i，j的任务、的任务、t(i，j)为为任务任务(i，j)的持续时间、的持续时间、I为所有任务的集合、为所有任务的集合、tE(j)为事件为事件j的最早时刻的最早时刻设：起始事件为设：起始事件为0号事件，号事件，n为结束事件为结束事件规定规定tE(0)0，从左到右按事件发生的顺序，从左到右按事件发生的顺序计算每个事件的最早时刻，那么就有事件计算每个事件的最早时刻，那么就有事件j的最早时刻为：的最早时刻为：()max()(,)(,)EEtjtit i ji jI47/97 下图中下图中()max(),(),()EEEEtdtata tbtb tctcabcdtatbtc()Eta()Etb()Etc()Etd48/97012346272352604034101234627235260403404613155411049/97以以tL(i)表示事件表示事件i的最迟时刻，设的最迟时刻，设n为最后一为最后一个事件，则有：个事件，则有：从右到左按事件发生的逆序计算每个事件从右到左按事件发生的逆序计算每个事件的最迟时刻，事件的最迟时刻，事件i的最迟时刻为：的最迟时刻为：()()LEtntn()min()(,)LLt itjt i j(,)i jI01234627235260403404613155411004913151141050/97 对事件对事件i和事件和事件j之间的任务之间的任务(i，j)其机动时其机动时间为：间为：机动时间为机动时间为0的任务的任务(作业流作业流)组成整个工组成整个工程的关键路径程的关键路径()()(,)LEtjtit i j01234627235260434046131554110049131511410012346272352604034046131554110049131511410（0）（3）（3）（4）（0）（0）（6）（6）（1）（0）（0）51/97 根据项目进度表，跟踪和控制各任务的实际执根据项目进度表，跟踪和控制各任务的实际执行情况行情况 一旦发现某个任务一旦发现某个任务(特别是关键路径上的任务特别是关键路径上的任务)未在计划进度规定的时间范围内完成，那么就未在计划进度规定的时间范围内完成，那么就要采取措施进行调整要采取措施进行调整增加额外的资源、增加新的员工或调整项目进度表 可以通过以下方式来实现项目跟踪：可以通过以下方式来实现项目跟踪：定期举行项目状态会议，由项目组中的各个成员分别报告进度和问题评价在软件工程过程中产生的所有评审结果确定正式的项目里程碑是否在预定日期内完成比较项目表中列出的各项任务的实际开始日期与计划开始日期非正式与开发人员进行会谈，获取他们对项目进展及可能出现的问题的客观评价52/97 软件项目管理概述软件项目管理概述 软件项目估算软件项目估算 项目进度管理项目进度管理 软件质量管理软件质量管理 软件配置管理软件配置管理 小结小结53/97 项目组织形式不仅要考虑软件项目的特点，项目组织形式不仅要考虑软件项目的特点，还需要考虑参与人员的素质还需要考虑参与人员的素质 在软件项目的组织原则：在软件项目的组织原则：尽早落实责任：在软件项目开始组织时，要尽早指定专人负责，使他有权进行管理，并对任务的完成负全责 减少接口：一个组织的生产率随完成任务中存在通信路径数目的增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失 责权均衡：软件经理人员所负的责任不应比委任给他的权力还大54/97 按项目划分的模式：按项目将开发人员组织成按项目划分的模式：按项目将开发人员组织成项目组，项目组的成员共同完成该项目的所有项目组，项目组的成员共同完成该项目的所有开发任务，包括项目的定义、需求分析、设计、开发任务，包括项目的定义、需求分析、设计、编码、测试、评审以及所有的文档编制，甚至编码、测试、评审以及所有的文档编制，甚至包括该项目的维护包括该项目的维护 按职能划分的模式：按软件过程中所反映的各按职能划分的模式：按软件过程中所反映的各种职能将项目的参与者组织成相应的专业组，种职能将项目的参与者组织成相应的专业组，如开发组、测试组、质量保证组、维护组等如开发组、测试组、质量保证组、维护组等 矩阵形模式：上述两种模式的复合，每个软件矩阵形模式：上述两种模式的复合，每个软件人员既属于某个专业组，又属于某个项目组人员既属于某个专业组，又属于某个项目组55/97总经理计划开发测试产品经理1子项目1产品经理2子项目2产品经理3子项目3子项目1子项目1子项目1子项目1子项目2子项目3子项目3质量保证子项目2子项目2运行维护56/97 程序设计小组主要是指从事软件开发程序设计小组主要是指从事软件开发活动的小组活动的小组 三种常见的程序设计小组的组织形式三种常见的程序设计小组的组织形式(具有不同的通信路径数具有不同的通信路径数)主程序员制小组(Chief programmer team)民主制小组(Democratic team)层次式小组(Hierarchical team)57/97主程序员后援程序员若干程序员资料员(a)主程序员制小组(b)民主制小组组长高级程序员程序员(c)层次式小组58/97 合理地配备人员包括：对不同的开发活动指派不合理地配备人员包括：对不同的开发活动指派不同的人员，并明确指出对种类人员的要求同的人员，并明确指出对种类人员的要求通常在项目初期需要的人员并不太多，但其业务和技术水平要高在项目的中后期需要较多的人参与，其中大多是一些有专门技术(如编程、测试)的人在项目临近结束(试运行)时，只需少量人员参与即可 如果一个软件项目从开始到结束都保持一个恒定如果一个软件项目从开始到结束都保持一个恒定的人员配备，那么就会出现下图中的情况的人员配备，那么就会出现下图中的情况浪费掉的工作量人力需要而缺少的工作量因人力配备不当，要求增加的额外工作量时间59/97 重质量：软件项目组不仅需要足够的人，重质量：软件项目组不仅需要足够的人，更需要业务和技术水平高的人更需要业务和技术水平高的人 重培训：培养所需技术人员和管理人员是重培训：培养所需技术人员和管理人员是有效解决人员问题的好方法有效解决人员问题的好方法 双阶梯提升：人员提升应分别按技术职务双阶梯提升：人员提升应分别按技术职务和管理职务进行，不能混在一起和管理职务进行，不能混在一起60/97 项目经理是项目的组织者，关系到项目的成败项目经理是项目的组织者，关系到项目的成败 一个称职的项目经理应具备如下能力：一个称职的项目经理应具备如下能力：获得充分资源的能力 组建团队的能力 分解工作的能力 为项目组织提供良好环境的能力 权衡项目目标的能力 应付危机，解决冲突的能力 谈判及广泛沟通的能力 技术综合能力 领导才能61/97 牢固掌握计算机软件的基本知识和技能牢固掌握计算机软件的基本知识和技能 善于分析和综合问题，具有严密的逻辑思维能力善于分析和综合问题，具有严密的逻辑思维能力 工作踏实、细致、不靠碰运气，遵循标准和规范，工作踏实、细致、不靠碰运气，遵循标准和规范，具有严格的科学作风具有严格的科学作风 工作中表现出有耐心、有毅力、有责任心工作中表现出有耐心、有毅力、有责任心 善于听取别人的意见，善于与周围人员团结协作，善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系建立良好的人际关系 具有良好的书面和口头表达能力具有良好的书面和口头表达能力62/97 软件项目管理概述软件项目管理概述 软件度量软件度量 软件项目估算软件项目估算 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件配置管理软件配置管理 小结小结63/97 高质量的软件应该具备以下条件：高质量的软件应该具备以下条件：满足软件需求定义的功能和性能 文档符合事先确定的软件开发标准 软件的特点和属性遵循软件工程的目标和原则 还应该考虑在预算和进度范围内交付，因还应该考虑在预算和进度范围内交付，因此在项目进行过程中要对偏差进行控制此在项目进行过程中要对偏差进行控制64/97 软件质量定义软件质量定义 ISO/IEC 9126：与软件产品满足明确或隐含需求的能力有关的特征和特性的总和 GB/T 13423：软件产品中能满足给定需求的性质和特性的总和，例如符合规格说明的程度；软件具有所期望的各种属性的组合程度；客户或用户觉得软件满足其综合期望的程度；软件的综合特性，它确定软件在使用中将满足客户预期要求的程度 典型的软件质量模型：典型的软件质量模型：McCall模型、模型、Boehm模型和模型和ISO/IEC9126质量模型质量模型65/97 软件产品的运行、修改和迁移三个方面软件产品的运行、修改和迁移三个方面 11个软件质量要素个软件质量要素(书上书上13条条)软件修正性软件转移性软件运行性可维护性灵活性可测试性可移植性可复用性可互操作性正确性完整性可靠性可用性效率66/97其中其中表示正相关，表示正相关，表示负相关表示负相关 67/97 软件质量保证活动 评审评审(走查走查/审查审查)/测试测试/程序正确性证明程序正确性证明 软件质量保证活动由两类不同的角色承担软件质量保证活动由两类不同的角色承担 负责技术工作的软件工程师：通过采用可靠的技术方法和措施、进行正式的技术评审、计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动 负责质量保证工作的SQA(Software Quality Assurance)小组：辅助软件工程小组得到高质量的最终产品 SQA:通过确保软件过程的质量来保证软件产品的质量68/97 为项目准备为项目准备SQA计划计划 参与开发该项目的软件过程描述参与开发该项目的软件过程描述 评审各项软件工程活动、对其是否符合定义好评审各项软件工程活动、对其是否符合定义好的软件过程中的相应部分进行核实的软件过程中的相应部分进行核实 审计指定的软件工作产品、对其是否符合定义审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分好的软件过程中的相应部分 确保软件工程及工作产品中的偏差已被记录在确保软件工程及工作产品中的偏差已被记录在案，并根据预定规程进行处理案，并根据预定规程进行处理 记录所有不符合的部分并报告给高级管理者。记录所有不符合的部分并报告给高级管理者。此外，此外，SQA小组还需要协调变化的控制和管理，小组还需要协调变化的控制和管理，并帮助收集和分析软件度量信息并帮助收集和分析软件度量信息69/97 软件评审是软件质量保证的重要手段软件评审是软件质量保证的重要手段 通常在软件工程过程的每个活动通常在软件工程过程的每个活动(如需求如需求分析、设计、编码分析、设计、编码)的后期进行正式的软的后期进行正式的软件评审件评审 两种主要评审活动：两种主要评审活动：项目管理评审和技术项目管理评审和技术评审评审(ISO/IEC 12207信息技术信息技术 软件软件生存周期过程生存周期过程中的联合评审过程定义中的联合评审过程定义)70/97 项目管理评审的任务是针对适用的项目计项目管理评审的任务是针对适用的项目计划、进度安排、标准和指南进行项目状态划、进度安排、标准和指南进行项目状态的评价的评价 评审的结果应做出下列规定：评审的结果应做出下列规定：基于对活动或软件产品状态的评价，按照计划进行改进活动 通过配备必要的资源维持项目的总体控制 改变项目的方向或决定是否需要另外计划 评价和管理可能危及项目成功的风险问题71/97 技术评审的任务是举行技术评审以评价正在考技术评审的任务是举行技术评审以评价正在考虑中的软件产品或服务，并提供下列证据：虑中的软件产品或服务，并提供下列证据：它们是完整的 它们符合标准和规范 对它们的更改是正确地实施的，并且仅仅影响配置管理过程所标明的区域 它们遵循适用的规程 它们已为下一个活动做好准备 根据项目的计划、进度安排、标准和指南正在进行开发、动作或维护72/97 正式评审正式评审(formal reviews)通常在软件工通常在软件工程过程的每个活动的后期进行，采用正式程过程的每个活动的后期进行，采用正式的会议评审方式，通过正式评审的活动标的会议评审方式，通过正式评审的活动标志着该活动到达了一个里程碑，该活动的志着该活动到达了一个里程碑，该活动的制品也就成为一个基线制品也就成为一个基线 非正式评审非正式评审(informal reviews)通常是一通常是一种由同事参加的即兴聚会，大多采用种由同事参加的即兴聚会，大多采用“走走查查”(walkthrough)的方式的方式73/97 评审会议评审会议 由评审会主席和若干名评审员组成，参加者大多是与评审内容相关的技术专家，参加人员不宜太多，通常为35人 必要时(如需求评审)可请用户代表参加 评审记录评审记录 指派专人记录会上提出的所有问题 会议结束后将其整理成一份“评审问题列表”并存档 评审报告评审报告 评审会结束时应形成评审总结报告，总结报告应指明被评审的制品，参加评审的人员，评审中发现的问题以及评审的结论 评审总结报告不必很长(通常一页纸就够了)，而“评审问题列表”可作为评审总结报告的附件。74/97 软件项目管理概述软件项目管理概述 软件度量软件度量 软件项目估算软件项目估算 项目进度管理项目进度管理 风险管理风险管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 小结小结75/97软件配置管理是在软件的生命期内软件配置管理是在软件的生命期内管理变化管理变化的一组活动的一组活动 标识变化 控制变化 确保适当地实现了变化 想需要知道这类信息的人报告变化76/97 软件配置项软件配置项(Software Configuration item，SCI)：为配置管理设计的软件的集合，它在配置管理过程中作为配置管理设计的软件的集合，它在配置管理过程中作为单个实体对待为单个实体对待 计算机程序(源代码和可执行程序)文档 数据 软件配置软件配置(Software configuration)：软件产品在不同：软件产品在不同时期的组合。该组合随着开发工作的进展而不断变化时期的组合。该组合随着开发工作的进展而不断变化 配置管理配置管理(Configuration management)：应用技术的：应用技术的和管理的指导和监控方法以标识和说明配置项的功能和和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性和实现状态并验证与规定的需求的遵循性77/97 基线基线(baseline)：已经过：已经过正式评审正式评审的规格的规格说明或中间产品，可用作下一步开发的基说明或中间产品，可用作下一步开发的基础，并且只有础，并且只有通过正式的变更控制过程通过正式的变更控制过程才才能能改变改变.发布发布(Release)：一项配置管理行为，它：一项配置管理行为，它说明某配置项的一个特定版本已准备好用说明某配置项的一个特定版本已准备好用于特定的目的于特定的目的(例如发布测试产品例如发布测试产品)变更控制变更控制(change control)：变更控制是：变更控制是指提议作一项变更并对其进行评估、同意指提议作一项变更并对其进行评估、同意或拒绝、调度和跟踪的过程。或拒绝、调度和跟踪的过程。78/97 对系统不同版本进行标识和跟踪的过程对系统不同版本进行标识和跟踪的过程 演化图：描述对象的变更历史演化图：描述对象的变更历史 在一个配置项被确定为基线前，它可能会变更很多次，甚至在建立基线后，变更也可能经常发生对象对象对象对象对象对象对象对象对象1.01.11.21.41.31.1.21.1.12.02.179/97 变更控制结合人的规程和自动化工具以提变更控制结合人的规程和自动化工具以提供一个管理变更的机制供一个管理变更的机制 主要过程主要过程变更请求提交后的评估，评估对象包括技术指标、潜在副作用、对其他配置对象和系统功能的影响以及变更的成本等评估的结果以变更报告的形式给出，该报告由变更授权人(change control authority，CCA)审核批准对被批准的变更生成工程变更工单(描述了将要进行的变更、必须注意的约束以及评审和审计的标准)将被修改的对象检出(check out)并通过合适的SQA活动进行修改修改完成后对象检入，并使用版本控制机制建立软件的下一个版本80/97 通过检出通过检出(check out)和检入和检入(check in)实现配实现配置项的访问控制和同步控制置项的访问控制和同步控制 在配置项变成基线之前，开发者可以进行非正式的变更控制 一旦配置项已经经过正式的技术审评并创建了配置项的基线，则要实施项目级的变更控制 为了对其进行修改，开发者必须获得项目管理者的批准为了对其进行修改，开发者必须获得项目管理者的批准(如果变更如果变更是是“局部的局部的”)或此配置项的变更授权人的批准或此配置项的变更授权人的批准(如果该变更影响如果该变更影响到其他配置项到其他配置项)配置对象（修改后版本）审计信息配置对象（提取版本）配置对象（基线版本）所有权信息配置对象（基线版本）软件工程师提交解锁加锁访问控制提取项目数据库81/97 审计：通过调查研究确定已制定的过程、指令、审计：通过调查研究确定已制定的过程、指令、规格说明、基线及其他特殊要求是否恰当和被规格说明、基线及其他特殊要求是否恰当和被遵守、以及实现是否有效遵守、以及实现是否有效 通过正式技术评审或软件配置审计来保证变更通过正式技术评审或软件配置审计来保证变更的有效性的有效性 正式评审关注已经被修改的配置项的技术正确性 评审者评估评审者评估SCI以确定它与其他以确定它与其他SCI的一致性、遗漏、及潜在的副作用的一致性、遗漏、及潜在的副作用 原则上应该对所有变更进行正式评审原则上应该对所有变更进行正式评审 软件配置审计通过评估配置项未在正式技术评审中考虑的特征，形成对正式评审的补充82/97 在工程变更工单中说明的变更已经完成了吗？是在工程变更工单中说明的变更已经完成了吗？是否有副作用否有副作用 是否已经进行了正式的技术评审以评估技术正确是否已经进行了正式的技术评审以评估技术正确性性 软件过程是否遵循了软件工程标准软件过程是否遵循了软件工程标准 变更在配置项中被变更在配置项中被“显著地强调显著地强调”了吗了吗 是否指出了变更的日期和变更的作者是否指出了变更的日期和变更的作者 配置对象的属性反映了该变更吗配置对象的属性反映了该变更吗 是否遵循了标注变更、记录变更并报告变更的软是否遵循了标注变更、记录变更并报告变更的软件配置管理规程件配置管理规程 所有相关的配置项被适当更新了吗所有相关的配置项被适当更新了吗83/97 配置状态报告，也称为状态记录配置状态报告，也称为状态记录(status accounting)软件配置管理的任务之一，它回答下列问题：发生了什软件配置管理的任务之一，它回答下列问题：发生了什么事；谁做的此事；此事是什么时候发生的；将影响别么事；谁做的此事；此事是什么时候发生的；将影响别的什么的什么 每次当一个SCI被赋上新的或修改后的标识时，则一个状态报告条目被创建 每次当一个变更被变更授权人批准(即一个工程变更工单产生)时，一个CSR条目被创建 每次当配置审计进行时，其结果作为CSR任务的一部分被报告 CSR的输出可以放置到一个联机数据库中，使得软件开发者或维护者可以通过关键词分类访问变更信息 此外，CSR报告被定期地生成，并允许管理者和开发者评估重要的变更84/97 软件项目管理概述软件项目管理概述 软件项目估算软件项目估算 项目进度管理项目进度管理 软件项目的组织软件项目的组织 软件质量管理软件质量管理 软件配置管理软件配置管理 CMM/CMMI85/9786/97 87/97 1组织 CMM/CMMI中的中的“组织组织”或或“软件组软件组织织”，是指软件企业（或软件公司）自，是指软件企业（或软件公司）自己，或者企业内部的一个软件研发部门。己，或者企业内部的一个软件研发部门。CMM/CMMI的实施和评估，不在整个的实施和评估，不在整个软件企业的所有部门进行，而只需在软软件企业的所有部门进行，而只需在软件企业中的某个软件组织范围内进行。件企业中的某个软件组织范围内进行。88/972软件过程软件过程一个软件过程是指人们开发和维护软件及其相关一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。产品所采取的一系列活动。既指软件开发过程，又指软既指软件开发过程，又指软件管理过程。其中，软件相关产品包括项目计划、设计文件管理过程。其中，软件相关产品包括项目计划、设计文档、源代码、测试报告和用户指南等。档、源代码、测试报告和用户指南等。规程与方法规程与方法工具和设备工具和设备有技能经过培有技能经过培训的开发人员训的开发人员89/972软件过程 软件产品的质量主要取决于产品开发和维护的软件过程质量。一个有效的、可视的软件过程能够将人力资源、物理设备和实施方法结合成一个有机的整体，并为软件工程师和高级管理者提供实际项目的可视状态和可控性能，从而可以监督和控制软件过程的进行。90/973.软件过程能力与性能 软件过程能力，是软件过程本身具有的按预定计划生产产品的固有能力。一个组织的软件过程能力，为组织提供了预测软件项目开发的数据基础。软件过程性能，是软件过程执行的实际结果。一个项目的软件过程性能，决定于它内部的子过程执行状态，只有每个子过程的性能得到改善，相应的成本、进度、功能和质量等性能目标才能得到控制。由于特定项目的属性和环境限制，项目的实际性能并不能充分反映组织的软件过程与能力。但是，成熟的软件过程，可弱化和预见不可控制的过程因素.91/97 组织标准软件过程，是组织中所有软件开发和维护项目共用的软件过程，是项目定义软件过程的基础。它保证组织过程活动的连续性，是组织软件过程的测量和长期改进的依据。裁剪指南则用来指导项目对组织标准软件过程进行裁剪，以形成适合项目特征的定义软件过程。92/97 1软件过程成熟度及其五个等级 软件过程成熟度，是指一个软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程，成熟度代表软件过程能力改善的潜力。过程的改善不能跳跃式进行。成熟度等级用来描述某一成熟度等级上的组织特征，每一等级都为下一等级奠定基础，过程的潜力只有在一定的基础之上，才能够被充分发挥。成熟度等级是软件过程改善中妥善定义的平台。5个成熟度等级提供了SW-CMM的顶层结构。每个成熟度等级都表明软件组织过程能力的一个等级。93/97CMM将软件过程的成熟度分为将软件过程的成熟度分为5个级别个级别,如图所示，如图所示，5个等级分别是：个等级分别是：初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级成熟度等级94/97初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级初始级（初始级（InitialInitial）在初始级，企业一般不具备稳在初始级，企业一般不具备稳定的软件开发与维护环境。项定的软件开发与维护环境。项目成功与否在很大程度上取决目成功与否在很大程度上取决于是否有杰出的项目经理和经于是否有杰出的项目经理和经验丰富的开发团队。此时，项验丰富的开发团队。此时，项目经常超出预算和不能按期完目经常超出预算和不能按期完成，组织的软件过程能力不可成，组织的软件过程能力不可预测。预测。初始级95/97初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级可重复级可重复级(Repeatable):(Repeatable):在可重复级，组织建立了管在可重复级，组织建立了管理软件项目的方针以及为贯彻执理软件项目的方针以及为贯彻执行这些方针的措施。组织基于在行这些方针的措施。组织基于在类似项目上的经验对新项目进行类似项目上的经验对新项目进行策划和管理。组织的软件过程能策划和管理。组织的软件过程能力可描述为有纪律的，并且项目力可描述为有纪律的，并且项目过程处于项目管理系统的有效控过程处于项目管理系统的有效控制之下。制之下。可重复级96/97初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级已定义级（已定义级（DefinedDefined）：）：在已定义级，组织形成了管理软件在已定义级，组织形成了管理软件开发和维护活动的组织标准软件过开发和维护活动的组织标准软件过程