实验室工作总结和安排上海交通大学

项目管理内容有效的项目管理集中于四个P上，人员产品过程项目2025/1/121软件项目管理软件项目的度量软件项目计划软件项目的风险管理进度安排及跟踪软件配置管理项目经理的工作2025/1/122软件项目的度量2025/1/123测度、度量和指标软件度量是计算机软件中范围广泛的测度。是在一个连续的基础上改进软件过程辅助估算、质量控制、生产率评估及项目控制在软件项目管理中，主要关心生产率和质量的度量过去的项目中软件开发生产率如何生产的软件质量如何2025/1/124测度、度量和指标项目指标可使我们：1）评估正在进行的项目的状态2）跟踪潜在的风险3）在问题造成不良影响之前发现问题4）调整工作流程或任务5）评估项目组控制软件工程工作质量的能力2025/1/125过程度量和过程改进改进过程的唯一合理的方法是测量过程的特定属性，基于这些属性开发一组有意义的度量，进而使用这组度量来提供引导改进战略的指标。软件过程度量对于一个组织提高其总体的过程成熟度，能够提供很大的帮助。但注意不要误用。2025/1/126“软件度量规则”Grady提出了一组“软件度量规则”如下：解释度量数据时使用通用的观念，并考虑组织的感受性对收集测量和度量的个人及小组提供定期的反馈不要使用度量来评价个人与开发者和小组一起设定清晰的目标及达到这些目标的度量不要用度量威胁个人或小组指出某个问题的度量数据不应该被看成是“否定的”含义。这些数据仅仅是过程改进的指标。不要被某个与其他重要度量不符合的度量迷惑。Grady提出一种鱼骨图2025/1/127项目度量软件过程度量主要是用于战略目的。软件项目度量则是战术性目的。

项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。2025/1/128软件测量产品的直接测量，包括产生的代码行（lineofcodeLOC)、执行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性等。2025/1/129面向规模的度量每千行代码（KLOC）的错误数每千行代码（KLOC）的缺陷数每行代码（LOC）的成本每千行代码（KLOC）的文档页数每人月错误数每人月代码行（LOC）每页文档的成本2025/1/1210面向功能的度量

加权因子测量参数 计数 简单 平均 复杂用户输入数 □ * 3 4 5 =用户输出数 □ * 4 5 7 =用户查询数 □ * 3 4 6 =文件数 □ * 7 10 15 =外部界面数 □ * 5 7 10 =总计数值

FP=总计数值*（0.65+0.01*∑Fi)

其中Fi(i=1到14）取值0-52025/1/1211面向功能的度量Fi:1.系统需要可靠的备份和复原吗?2.需要数据通信吗?3.有分布处理功能吗?4.性能很关键吗?5.系统是否在一个已有的、很实用的操作环境中运行?6.系统需要联机数据项吗?7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入?8.需要联机更新主文件吗?9.输入、输入、文件或查询很复杂吗？10.内部处理复杂吗?11.代码需要被设计成可复用的吗?12.设计中需要包括转换及安装吗?13.系统的设计支持不同组织的多次安装吗?14.应用的设计方便用户修改和使用吗?2025/1/1212面向功能的度量每个功能点（FP）的错误数每个功能点（FP）的缺陷数每个功能点（FP）的成本每个功能点（FP）的文档页数每个人月完成的功能点（FP）数2025/1/1213扩展的功能点度量

复杂度加权因子测量元素 低 平均高 内部数据结构 □*7 +□*10+□*15 =外部数据 □*5 +□*7+□*10 =用户输入数 □*3 +□*4+□*6 =用户输出数 □*4 +□*5+□*7 =用户查询数 □*7 +□*4+□*6 =变换 □*3 +□*10+□*15 =变迁 □*n/a+□*n/a+□*n/a=3D函数点指数2025/1/1214软件项目计划2025/1/1215项目估算估算是一门科学，也是一门艺术估算软件开发工作的资源、成本及进度需要：经验以前完成项目中有用的信息当仅存在定性的数据时进行定量测量的勇气2025/1/1216项目的不确定性对项目计划中的不确定性产生重大影响的因素复杂性项目的规模结构不确定性的程度历史信息的可用程度2025/1/1217项目计划的目标项目计划的目标是提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算，并随着项目的进展不断更新项目计划的目标是通过一个信息发现的过程实现的2025/1/1218软件的范围软件项目计划的第一个活动是确定软件范围软件范围包括：功能、性能、约束条件、接口及可靠性2025/1/1219资源软件计划的第二个任务是估算完成软件开发工作所需的资源：开发环境：硬件及软件工具可复用构件人员2025/1/1220软件项目估算软件成本及工作量的估算永远不会是一门精确的科学。人员、技术、环境、策略等是影响软件最终成本及开发所需工作量的主要因素。为了可靠地估算成本及工作量：将估算拖延到项目的最后阶段。基于已经完成的类似的项目进行估算。使用简单的“分解技术”来进行项目成本及工作量的估算。使用一个或多个经验模型进行软件成本及工作量的估算。2025/1/1221软件项目估算软件项目估算的准确性取决于以下因素：计划者是否适当地估算待建造产品规模的程度。把规模估算转换成人的工作量、时间及成本的能力项目计划反映软件项目组能力的程度产品需求的稳定性及支持软件工程工作的环境2025/1/1222软件规模估算四种估算问题规模的方法（由PutnamtMyers92年提出)：“模糊逻辑”法功能点法标准构件法修改法2025/1/1223“模糊逻辑”法要点：计划者必须说明应用软件的类型建立其定性的规模估算在最初的范围内精化该估算利用个人的经验和项目历史数据库功能点法：2025/1/1224标准构件法与修改法标准构件法要点：软件由若干不同的“标准构件”组成估算出每个标准构件的出现次数使用历史数据来确定每个标准构件交付时的大小修改法要点：项目中包含对已有软件的使用，但该软件必须做某种程度的修改。估算必须完成的修改数目及类型。2025/1/1225估算误差的原因有时各种估算之间存在着巨大的差别，原因是项目的范围未能被充分理解，或被计划者误解。基于问题的估算技术中所使用的生产率数据对于该应用是不合适的，或是太陈旧了，或是被误用。解决方案：确定引起差别的原因，重新估算，并调和各种估算的结果。2025/1/1226基于过程的估算估算一个项目的最常用的技术是基于使用的过程进行估算，即，将过程分解为相对较小的活动或任务，再估算完成每个任务所需的工作量。要点：建立问题功能及相关的过程活动2025/1/1227经验估算模型计算机软件的估算模型使用由经验导出的公式来预测工作量，工作量是LOC或FP的函数。支持大多数估算模型的经验数据是来源于一个有限的项目样品集。没有任何估算模型能够适用于所有类型的软件及所有的开发环境。这种模型得出的结果必须谨慎使用。2025/1/1228估算模型的结构典型的估算模型是通过对以前的软件项目中收集到的数据进行回归分析而导出的。这种模型的总体结构具有如下形式：

E=A+B*（ev)C文献中提出了许多面向LOC的估算模型：E=5.2*(KLOC)0.91Walston-Felix模型E=5.5+0.73*(KLOC)1.16Bailey-Basili模型E=3.2*(KLOC)1.05Boehm的简单模型E=5.288*(KLOC)1.047Doty模型，在KLOC>9E=-13.39+0.0545FPAlbrecht&Gaffney模型E=60.62*7.728*10-8FPKemerer模型E=585.7+5.12FPMaston、Barnett&Mellichamp2025/1/1229COCOMO模型由Boehm81年在其经典著作“软件工程经济学”中提出的，称为：构造性成本模型。Boehm的模型层次具有以下形式：模型1：基本COCOMO模型，将软件开发工作量（及成本）作为程序规模的函数进行计算，程序规模以估算的代码行来表示。

E=abKLOCbbD=cbEdb模型2：中级COCOMO模型，将软件开发工作量（及成本）作为程序规模及一组“成本驱动因子”的函数来进行计算。

E=aiKLOCbi*EAF模型3：高级COCOMO模型，包含了中级模型的所有特性，并结合了成本驱动因子对软件工程过程中每一步骤的影响的评估。2025/1/1230软件方程式软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。

E=[LOC*B0.333/P]3*(1/t4)2025/1/1231小结软件项目的估算包括：需要多长时间需要多少工作量需要多少人员需要多少资源（硬件及软件）包含的风险2025/1/1232小结范围说明能够帮助计划者使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一功能所需的程序规模或人月数。经验技术使用根据经验导出的公式来预测工作量和时间。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。2025/1/1233风险管理2025/1/1234被动和主动的风险策略风险:没有办法消除的不确定性。被动的风险策略：最多是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。主动的风险策略：早在技术工作开始之前就已经启动风险管理。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后软件项目组建立一个计划来管理风险。风险的特征：不确定性、损失2025/1/1235风险分类项目风险：指潜在的预算、进度、人力（工作人员及组织）、资源、客户及需求等方面的问题以及它们对软件项目的影响。技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题。规约的二义性、技术的不确定性、陈旧的技术及”先进的”技术。商业风险：开发了一个没有人真正需要的优秀产品或系统（市场风险）开发的产品不再符合公司的整体商业策略（策略风险）建造了一个销售部门不知道如何去卖的产品由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）没有得到预算或人力上的保证（预算风险）某些风险根本无法事先预测2025/1/1236风险管理的七个原则保持全面的观点采用长远的观点鼓励广泛交流结合软件强调持续的过程开发共享的产品鼓励协同工作2025/1/1237识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。标识风险的一个方法是建立风险条目检查表：产品规模—与要建造或要修改的软件的总体规模相关的风险商业影响—与管理或市场所加诸的约束相关的风险客户特性—与客户的素质以及开发者和客户定期通信的能力相关的风险过程定义—与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险开发环境—与用以建造产品的工具的可用性及质量相关的风险建造的技术—与参与工作的软件工程师的总体技术水平及项目经验相关的风险2025/1/1238建立风险表

风险因素性能支持成本进度影响类别

灾难性的1无法满足需求而导致任务失败失误将导致进度延迟和成本增加，预计超支严重2严重退化使得根本无法达到要求的技术性能无法做出响应或无法支持的软件资金严重短缺，很可能超出预算无法在交付日期内完成严重的1无法满足需求而导致系统性能下降，使得任务能否成功受到质疑失误将导致系统运行的延迟交使成本增加，预计超支严重2技术性能有些降低在软件修改中有少量的延迟资金不足，可能会超支交付日期可能延迟轻微的1无法满足需求而导致次要任务的降级成本、影响及可以补救的进度上的小问题，预计超支较少2技术性能有些降低较好的软件支持有充足的资金来源现实的、可完成的进度计划可忽略的1无法满足需求而导致使用不方便或不易操作失误对进度及成本的影响很小，预计超支很少2技术性能没有降低易于进行软件支持可能低于预算交付日期将会提前2025/1/1239风险预测评估风险影响制定风险缓解计划2025/1/1240风险缓解、监控和管理计划

（RMMM计划）I.引言1.文档的范围和目的2.主要风险综述3.责任A.管理者B.技术人员II.项目风险表1.中止线上的所有风险的描述2.影响概率及影响的因素III.风险缓解、监控和管理N.风险#NA.缓解I.一般策略II.缓解风险的特定步骤B.监控I.被监控的因素II.监控方法C.管理I.意外事件计划II.特殊的考虑IV.RMMM计划的迭代时间安排表V.总结2025/1/1241项目进度安排及跟踪2025/1/1242项目延迟的原因一个不现实的截止期限客户需求发生变化对工件量估计不足未将风险考虑到项目计划事先无法预计的技术困难事先无法预计的人力困难由于项目组成员间的交流不畅面导致的延期项目管理者未发现进度拖后，未能采取适当的措施2025/1/1243项目管理者的目标一个大型项目可以分解成许多小的活动。项目管理者的目标是定义所有项目任务，识别关键任务，然后跟踪关键任务的进展以保证“一天一次”的发现进度拖延情况。管理者必须建立一个具有一定详细程度的进度表，使得项目管理者能够监督进度，并控制整个项目。2025/1/1244项目进度安排的两种视角基于计算机系统的最终发布日期已确定，在此约束下将工作量分布在预先确定的时间框架内假定大致的时间界限已讨论过，但是最终发布日期是由项目开发组设定，且在对软件进行仔细分析之后定义最终发布日期2025/1/1245项目进度安排的原则阶段划分相互依赖性时间分配工作量确认定义责任定义结果定义里程碑2025/1/1246人员与工作量间的关系随着项目规模的增加，必然涉及到更多的人员参与随着项目人员的增加生产率呈下降的趋势原因是人与人之间通讯2025/1/1247为项目定义任务集合过程模型都是由一个任务集合组成的，它使得项目组可以定义、开发和维护计算机软件。一个任务集合包括一组软件任务、里程碑和产品没有一个普遍适用于所有软件项目的任务集合2025/1/1248主要任务求精首先，为主要任务定义项目宏观进度表然后，将宏观进度表精化来创建一个详细的项目进度表2025/1/1249定义任务网络“任务网络”是一个项目的任务流程的图形表示I.1确定概念范围I.2概念计划I.3B技术风险评估I.4概念证明I.5B概念实现集成A,B,CI.3A技术风险评估I.3C技术风险评估I.5A概念实现I.5C概念实现2025/1/1250进度安排两种可以用于软件开发的项目进度安排方法：程序评估和复审技术（RERT）关键路径方法（CPM）两种方法利用以下信息驱动工作量的估算产品功能的分解适当的过程模型的选择项目类型和任务集合的选择2025/1/1251进度安排两种方法都提供项目工作量划分的工具能够支持：确定关键路径通过使用统计模型为单个任务建立最有可能的时间估算计算为特定任务定义其时间“窗口”的边界时间2025/1/1252时间表和进度跟踪时间表：输出结果为甘特图（GanttChart)进度跟踪和控制：定期举行项目状态会议评估所有在软件工程过程中所进行的复审的结果确定正式的项目里程碑是否在预定日期内完成比较项目表中列出的各项任务的实际开始日期与计划开始日期与开发者进行非正式会谈，获取他们对项目进展及可能出现的问题的客观评估使用获得值分析来定量地评估进展2025/1/1253甘特图2025/1/1254项目计划软件工程过程中的每一步骤都应该产生可以被复审，并能作为后续步骤的基础工作产品软件项目计划是一种面向广大读者的简短文档在软件管理者、技术人员和客户间传达项目范围和资源信息定义风险并提出有关风险管理技术的建议定义管理复审的成本和进度为与项目相关的所有人员提供软件开发的整体方法概述如何保证质量及变化的管理软件项目计划大纲2025/1/1255软件项目计划大纲I.引言A.计划的目的B.项目的范围和目标1.范围说明2.主要功能3.性能问题4.管理及技术约束II.项目估算A.用于估算的历史数据B.估算技术C.工作量、成本和持续时间的估算III.风险管理策略A.风险表B.对需管理的风险的讨论C.每个风险的RMMM计划1.风险缓解2.风险监控3.风险管理(意外事件计划)IV.进度A.项目工作细分结构B.任务网络C.时间表(甘特图)D.资源表V.项目资源A.人员B.硬件和软件资源C.特殊资源VI.人员组织A.项目组结构(如果需要)B.管理报告VII.跟踪及控制机制A.质量保证和控制B.变化管理和控制VIII.附录2025/1/1256软件配置管理2025/1/1257配置管理协调软件开发以减少不理解性到最小程度的技术称为配置管理软件配置管理（SCM）是贯穿于整个软件过程中的保护性活动。标识变化控制变化保证变化被适当地实现2025/1/1258软件配置软件过程的输出信息可分为以下类别：计算机程序（源代码和可执行程序）描述计算机程序的文档（针对技术开发者和用户）数据（包含在程序程序内部或在程序外部）2025/1/1259变化的起源新的商业或市场条件，引起产品需求或业务规则的变化新的客户需求，要求修改信息系统产生的数据、产品提供的功能或基于计算机的系统提供的服务改组或企业规模减小，导致项目的优先级或软件工程队伍结构的变化预算或进度的限制，导致系统或产品的重定义2025/1/1260基线已经通过正式复审和批准的某规约或产品，它作为进一步开发的基础，并且只能通过正式的变化控制过程的改变。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且这些配置项已经经过正式技术复审而获得认可。2025/1/1261软件配置项（SCI）部分软件工程过程中创建的信息一个文档一个全套的测试用例一个已命名的程序构件。。。在现实中SCI被组织成配置对象，并被归类到项目数据库中2025/1/1262SCM过程一个组织如何标识和管理程序（及文档）的很多现存版本，以使得变化可以高效地进行？一个组织如何在软件被发布给客户前和之后控制变化？谁负责批准变化，并给变化确定优先级？如何保证变化已经被恰当地进行？采用什么机制告知其他人员已经实行的变化？SCM的基本任务：标识、版本控制、变化控制、配置审计和报告2025/1/1263配置项的标识Obj1.0Obj1.1Obj1.3Obj1.2Obj1.4Obj2.0Obj2.1Obj1.1.2Obj1.1.12025/1/1264版本控制版本管理使得用户能够通过对适当版本的选择来指定可选的软件系统的配置。软件的完整版本是由一组SCI（源代码、文档、数据）组成的每个版本可能由多种不同的变体组成。2025/1/1265变化控制对于大型的软件开发项目，无控制的变化将迅速导致混乱一个变化请求被提交和评估，以评价技术指标、潜在的副作用、对其他配置对象和系统功能的整体影响以及变化的成本预测。变化控制分：正式和非正式两种2025/1/1266配置审计在工程变化指令中说明的变化已经完成了吗？加入了任意附加的修改吗？是否已经进行了正式的技术复审、以评估技术的正确性？是否适当地遵循了软件工程标准？变化在SCI中被“显著地强调”了吗？是否指出了变化的日期和变化的作者？配置对象的属性反应了变化吗？是否遵循了标注变化、记录变化并报告变化的SCM规程？所有相关的SCI被适当修改了吗？2025/1/1267状态报告发生了什么事谁做的此事此事是什么时候发生的将影响别的什么吗每一个SCI被赋上新的或修改后的标识时，则一个CSR条目被创建每一个变化被批准时，一个CSR条目被创建每次配置审计进行时，其结果被放置在一个联机数据库中2025/1/1268项目经理的工作2025/1/1269什么是成功的项目管理圆满完成工作说明书中所述的任务，并且达到验收标准。