实验室工作总结和安排课件

实验室工作总结和安排实验室工作总结和安排实验室工作总结和安排工程管理内容有效的工程管理集中于四个P上，人员产品过程工程2021/11/252实验室工作总结和安排实验室工作总结和安排实验室工作总结和安排1工程管理内容有效的工程管理集中于四个P上，人员产品过程工程2022/12/122工程管理内容有效的工程管理集中于四个P上，2022/12/1软件工程管理软件工程的度量软件工程方案软件工程的风险管理进度安排及跟踪软件配置管理工程经理的工作2022/12/123软件工程管理软件工程的度量2022/12/103软件工程的度量2022/12/124软件工程的度量2022/12/104测度、度量和指标软件度量是计算机软件中范围广泛的测度。是在一个连续的根底上改进软件过程辅助估算、质量控制、生产率评估及工程控制在软件工程管理中，主要关心生产率和质量的度量过去的工程中软件开发生产率如何生产的软件质量如何2022/12/125测度、度量和指标软件度量是计算机软件中范围广泛的测度。202测度、度量和指标工程指标可使我们：1〕评估正在进展的工程的状态2〕跟踪潜在的风险3〕在问题造成不良影响之前发现问题4〕调整工作流程或任务5〕评估工程组控制软件工程工作质量的能力2022/12/126测度、度量和指标工程指标可使我们：2022/12/106过程度量和过程改进改进过程的唯一合理的方法是测量过程的特定属性，基于这些属性开发一组有意义的度量，进而使用这组度量来提供引导改进战略的指标。软件过程度量对于一个组织提高其总体的过程成熟度，能够提供很大的帮助。但注意不要误用。2022/12/127过程度量和过程改进改进过程的唯一合理的方法是测量过程的特定属“软件度量规那么〞Grady提出了一组“软件度量规那么〞如下：解释度量数据时使用通用的观念，并考虑组织的感受性对收集测量和度量的个人及小组提供定期的反响不要使用度量来评价个人与开发者和小组一起设定清晰的目标及到达这些目标的度量不要用度量威胁个人或小组指出某个问题的度量数据不应该被看成是“否认的〞含义。这些数据仅仅是过程改进的指标。不要被某个与其他重要度量不符合的度量迷惑。Grady提出一种鱼骨图2022/12/128“软件度量规那么〞Grady提出了一组“软件度量规那么〞如下工程度量软件过程度量主要是用于战略目的。软件工程度量那么是战术性目的。工程度量的目的是双重的。首先，这些度量能够指导进展一些必要的调整以防止延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，工程度量可在工程进展的根底上评估产品质量，并且可在必要时修改技术方法以改进质量。2022/12/129工程度量软件过程度量主要是用于战略目的。软件工程度量那么是战软件测量产品的直接测量，包括产生的代码行〔lineofcodeLOC)、执行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性等。2022/12/1210软件测量产品的直接测量，包括产生的代码行〔lineofc面向规模的度量每千行代码〔KLOC〕的错误数每千行代码〔KLOC〕的缺陷数每行代码〔LOC〕的本钱每千行代码〔KLOC〕的文档页数每人月错误数每人月代码行〔LOC〕每页文档的本钱2022/12/1211面向规模的度量每千行代码〔KLOC〕的错误数2022/12/面向功能的度量 加权因子测量参数 计数 简单 平均 复杂用户输入数 □ * 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-52022/12/1212面向功能的度量 加权因子2022/12/1012面向功能的度量Fi:1.系统需要可靠的备份和复原吗?2.需要数据通信吗?3.有分布处理功能吗?4.性能很关键吗?5.系统是否在一个已有的、很实用的操作环境中运行?6.系统需要联机数据项吗?7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入?8.需要联机更新主文件吗?9.输入、输入、文件或查询很复杂吗？10.内部处理复杂吗?11.代码需要被设计成可复用的吗?12.设计中需要包括转换及安装吗?13.系统的设计支持不同组织的屡次安装吗?14.应用的设计方便用户修改和使用吗?2022/12/1213面向功能的度量Fi:2022/12/1013面向功能的度量每个功能点〔FP〕的错误数每个功能点〔FP〕的缺陷数每个功能点〔FP〕的本钱每个功能点〔FP〕的文档页数每个人月完成的功能点〔FP〕数2022/12/1214面向功能的度量每个功能点〔FP〕的错误数2022/12/10扩展的功能点度量 复杂度加权因子测量元素 低 平均高 内部数据构造 □*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函数点指数2022/12/1215扩展的功能点度量 复杂度加权因子2022/12/10软件工程方案2022/12/1216软件工程方案2022/12/1016工程估算估算是一门科学，也是一门艺术估算软件开发工作的资源、本钱及进度需要：经历以前完成工程中有用的信息当仅存在定性的数据时进展定量测量的勇气2022/12/1217工程估算估算是一门科学，也是一门艺术2022/12/1017工程的不确定性对工程方案中的不确定性产生重大影响的因素复杂性工程的规模构造不确定性的程度历史信息的可用程度2022/12/1218工程的不确定性对工程方案中的不确定性产生重大影响的因素202工程方案的目标工程方案的目标是提供一个框架，使得管理者能够对资源、本钱及进度进展合理的估算，并随着工程的进展不断更新工程方案的目标是通过一个信息发现的过程实现的2022/12/1219工程方案的目标工程方案的目标是提供一个框架，使得管理者能够对软件的范围软件工程方案的第一个活动是确定软件范围软件范围包括：功能、性能、约束条件、接口及可靠性2022/12/1220软件的范围软件工程方案的第一个活动是确定软件范围2022/1资源软件方案的第二个任务是估算完成软件开发工作所需的资源：开发环境：硬件及软件工具可复用构件人员2022/12/1221资源软件方案的第二个任务是估算完成软件开发工作所需的资源：2软件工程估算软件本钱及工作量的估算永远不会是一门准确的科学。人员、技术、环境、策略等是影响软件最终本钱及开发所需工作量的主要因素。为了可靠地估算本钱及工作量：将估算拖延到工程的最后阶段。基于已经完成的类似的工程进展估算。使用简单的“分解技术〞来进展工程本钱及工作量的估算。使用一个或多个经历模型进展软件本钱及工作量的估算。2022/12/1222软件工程估算软件本钱及工作量的估算永远不会是一门准确的科学。软件工程估算软件工程估算的准确性取决于以下因素：方案者是否适当地估算待建造产品规模的程度。把规模估算转换成人的工作量、时间及本钱的能力工程方案反映软件工程组能力的程度产品需求的稳定性及支持软件工程工作的环境2022/12/1223软件工程估算软件工程估算的准确性取决于以下因素：2022/1软件规模估算四种估算问题规模的方法〔由PutnamtMyers92年提出)：“模糊逻辑〞法功能点法标准构件法修改法2022/12/1224软件规模估算四种估算问题规模的方法〔由PutnamtMye“模糊逻辑〞法要点：方案者必须说明应用软件的类型建立其定性的规模估算在最初的范围内精化该估算利用个人的经历和工程历史数据库功能点法：2022/12/1225“模糊逻辑〞法要点：2022/12/1025标准构件法与修改法标准构件法要点：软件由假设干不同的“标准构件〞组成估算出每个标准构件的出现次数使用历史数据来确定每个标准构件交付时的大小修改法要点：工程中包含对已有软件的使用，但该软件必须做某种程度的修改。估算必须完成的修改数目及类型。2022/12/1226标准构件法与修改法标准构件法要点：2022/12/1026估算误差的原因有时各种估算之间存在着巨大的差异，原因是工程的范围未能被充分理解，或被方案者误解。基于问题的估算技术中所使用的生产率数据对于该应用是不适宜的，或是太陈旧了，或是被误用。解决方案：确定引起差异的原因，重新估算，并调和各种估算的结果。2022/12/1227估算误差的原因有时各种估算之间存在着巨大的差异，原因是202基于过程的估算估算一个工程的最常用的技术是基于使用的过程进展估算，即，将过程分解为相对较小的活动或任务，再估算完成每个任务所需的工作量。要点：建立问题功能及相关的过程活动2022/12/1228基于过程的估算估算一个工程的最常用的技术是基于使用的过程进展经历估算模型计算机软件的估算模型使用由经历导出的公式来预测工作量，工作量是LOC或FP的函数。支持大多数估算模型的经历数据是来源于一个有限的工程样品集。没有任何估算模型能够适用于所有类型的软件及所有的开发环境。这种模型得出的结果必须慎重使用。2022/12/1229经历估算模型计算机软件的估算模型使用由经历导出的公式来预测工估算模型的构造典型的估算模型是通过对以前的软件工程中收集到的数据进展回归分析而导出的。这种模型的总体构造具有如下形式：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&Mellichamp2022/12/1230估算模型的构造典型的估算模型是通过对以前的软件工程中收集到的COCOMO模型由Boehm81年在其经典著作“软件工程经济学〞中提出的，称为：构造性本钱模型。Boehm的模型层次具有以下形式：模型1：根本COCOMO模型，将软件开发工作量〔及本钱〕作为程序规模的函数进展计算，程序规模以估算的代码行来表示。E=abKLOCbbD=cbEdb模型2：中级COCOMO模型，将软件开发工作量〔及本钱〕作为程序规模及一组“本钱驱动因子〞的函数来进展计算。E=aiKLOCbi*EAF模型3：高级COCOMO模型，包含了中级模型的所有特性，并结合了本钱驱动因子对软件工程过程中每一步骤的影响的评估。2022/12/1231COCOMO模型由Boehm81年在其经典著作“软件工程经济软件方程式软件方程式是一个多变量模型，它假设在软件开发工程的整个生命周期中的一个特定的工作量分布。E=[LOC*B0.333/P]3*(1/t4)2022/12/1232软件方程式软件方程式是一个多变量模型，它假设在软件开发工程的小结软件工程的估算包括：需要多长时间需要多少工作量需要多少人员需要多少资源〔硬件及软件〕包含的风险2022/12/1233小结软件工程的估算包括：2022/12/1033小结范围说明能够帮助方案者使用一种或多种技术进展估算，这些技术主要分为两大类：分解和经历建模。分解技术需要划分出主要的软件功能，接着估算实现每一功能所需的程序规模或人月数。经历技术使用根据经历导出的公式来预测工作量和时间。软件工程估算永远不会是一门准确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的准确度。2022/12/1234小结范围说明能够帮助方案者使用一种或多种技术进展估算，这些技风险管理2022/12/1235风险管理2022/12/1035被动和主动的风险策略风险:没有方法消除的不确定性。被动的风险策略：最多是针对可能发生的风险来监视工程，直到它们变成真正的问题时，才会拨出资源来处理它们。主动的风险策略：早在技术工作开场之前就已经启动风险管理。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后软件工程组建立一个方案来管理风险。风险的特征：不确定性、损失2022/12/1236被动和主动的风险策略风险:没有方法消除的不确定性。2022/风险分类工程风险：指潜在的预算、进度、人力〔工作人员及组织〕、资源、客户及需求等方面的问题以及它们对软件工程的影响。技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题。规约的二义性、技术的不确定性、陈旧的技术及〞先进的〞技术。商业风险：开发了一个没有人真正需要的优秀产品或系统〔市场风险〕开发的产品不再符合公司的整体商业策略〔策略风险〕建造了一个销售部门不知道如何去卖的产品由于重点的转移或人员的变动而失去了高级管理层的支持〔管理风险〕没有得到预算或人力上的保证〔预算风险〕某些风险根本无法事先预测2022/12/1237风险分类工程风险：2022/12/1037风险管理的七个原那么保持全面的观点采用长远的观点鼓励广泛交流结合软件强调持续的过程开发共享的产品鼓励协同工作2022/12/1238风险管理的七个原那么保持全面的观点2022/12/1038识别风险识别风险是试图系统化地确定对工程方案〔估算、进度、资源分配〕的威胁。标识风险的一个方法是建立风险条目检查表：产品规模—与要建造或要修改的软件的总体规模相关的风险商业影响—与管理或市场所加诸的约束相关的风险客户特性—与客户的素质以及开发者和客户定期通信的能力相关的风险过程定义—与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险开发环境—与用以建造产品的工具的可用性及质量相关的风险建造的技术—与参与工作的软件工程师的总体技术水平及工程经历相关的风险2022/12/1239识别风险识别风险是试图系统化地确定对工程方案〔估算、进度、资建立风险表

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

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

〔RMMM方案〕III.风险缓解、监控和管理N.风险#N2022/12/1242风险缓解、监控和管理方案

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

1~工程进度表如:MSProject。使用最多，最容易用和沟通，但不完美。2022/12/1273工程经理的常用的实施方法和工具

1~工程进度表如:MSPr工程经理的常用的实施方法和工具

2~工程章程项目图表项目名称项目支持人起始日期项目目标项目范围关键日期：计划期结束项目计划与说明完成开发期结束：测试期结束推行期结束主要交付件例外（如不能按某标准等）主要项目实施方法（可选）风险与假设验收标准预算和资源项目小组成员1、成员2成员3、成员4项目经理2022/12/1274工程经理的常用的实施方法和工具

2~工程章程项目图表项目名称工程经理的常用的实施方法和工具

3~工程变更申请2022/12/1275工程经理的常用的实施方法和工具

3~工程变更申请2022/1工程经理的常用的实施方法和工具

4~工程财务控制表包括：工程财务预算表工程财务实际发生表将要发生预测表准备金申请表等等2022/12/1276工程经理的常用的实施方法和工具

4~工程财务控制表包括：20工程经理的常用的实施方法和工具

5~工程控制书〔PCB〕包括：工程任务分配方案工程进程控制方案风险管理方案客户沟通方案客户会议记要工程变更申请记录每月工作报告工程人员情况质量保证方案工程财务报表突发事件管理方案2022/12/1277工程经理的常用的实施方法和工具

5~工程控制书〔PCB〕包括工程经理的常用的实施方法和工具

6~知识仓库MethodBluePMICMPMIGSMethodIndustryspecificICMMentorProgram2022/12/1278工程经理的常用的实施方法和工具

6~知识仓库MethodB优秀的工程经理的培养几乎所有IBM的优秀工程经理都是来自有问题的或失败的工程实践经历最重要2022/12/1279优秀的工程经理的培养几乎所有IBM的优秀工程经理都是来自有问工程失败的三个根本原因缺乏：纪律责任制技能QA是挽救的方法论2022/12/1280工程失败的三个根本原因缺乏：2022/12/1080谢谢！2022/12/1281谢谢！2022/12/1081ThankYou世界触手可及携手共进，齐创精品工程ThankYou世界触手可及携手共进，齐创精品工程82实验室工作总结和安排实验室工作总结和安排实验室工作总结和安排工程管理内容有效的工程管理集中于四个P上，人员产品过程工程2021/11/252实验室工作总结和安排实验室工作总结和安排实验室工作总结和安排83工程管理内容有效的工程管理集中于四个P上，人员产品过程工程2022/12/1284工程管理内容有效的工程管理集中于四个P上，2022/12/1软件工程管理软件工程的度量软件工程方案软件工程的风险管理进度安排及跟踪软件配置管理工程经理的工作2022/12/1285软件工程管理软件工程的度量2022/12/103软件工程的度量2022/12/1286软件工程的度量2022/12/104测度、度量和指标软件度量是计算机软件中范围广泛的测度。是在一个连续的根底上改进软件过程辅助估算、质量控制、生产率评估及工程控制在软件工程管理中，主要关心生产率和质量的度量过去的工程中软件开发生产率如何生产的软件质量如何2022/12/1287测度、度量和指标软件度量是计算机软件中范围广泛的测度。202测度、度量和指标工程指标可使我们：1〕评估正在进展的工程的状态2〕跟踪潜在的风险3〕在问题造成不良影响之前发现问题4〕调整工作流程或任务5〕评估工程组控制软件工程工作质量的能力2022/12/1288测度、度量和指标工程指标可使我们：2022/12/106过程度量和过程改进改进过程的唯一合理的方法是测量过程的特定属性，基于这些属性开发一组有意义的度量，进而使用这组度量来提供引导改进战略的指标。软件过程度量对于一个组织提高其总体的过程成熟度，能够提供很大的帮助。但注意不要误用。2022/12/1289过程度量和过程改进改进过程的唯一合理的方法是测量过程的特定属“软件度量规那么〞Grady提出了一组“软件度量规那么〞如下：解释度量数据时使用通用的观念，并考虑组织的感受性对收集测量和度量的个人及小组提供定期的反响不要使用度量来评价个人与开发者和小组一起设定清晰的目标及到达这些目标的度量不要用度量威胁个人或小组指出某个问题的度量数据不应该被看成是“否认的〞含义。这些数据仅仅是过程改进的指标。不要被某个与其他重要度量不符合的度量迷惑。Grady提出一种鱼骨图2022/12/1290“软件度量规那么〞Grady提出了一组“软件度量规那么〞如下工程度量软件过程度量主要是用于战略目的。软件工程度量那么是战术性目的。工程度量的目的是双重的。首先，这些度量能够指导进展一些必要的调整以防止延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，工程度量可在工程进展的根底上评估产品质量，并且可在必要时修改技术方法以改进质量。2022/12/1291工程度量软件过程度量主要是用于战略目的。软件工程度量那么是战软件测量产品的直接测量，包括产生的代码行〔lineofcodeLOC)、执行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性等。2022/12/1292软件测量产品的直接测量，包括产生的代码行〔lineofc面向规模的度量每千行代码〔KLOC〕的错误数每千行代码〔KLOC〕的缺陷数每行代码〔LOC〕的本钱每千行代码〔KLOC〕的文档页数每人月错误数每人月代码行〔LOC〕每页文档的本钱2022/12/1293面向规模的度量每千行代码〔KLOC〕的错误数2022/12/面向功能的度量 加权因子测量参数 计数 简单 平均 复杂用户输入数 □ * 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-52022/12/1294面向功能的度量 加权因子2022/12/1012面向功能的度量Fi:1.系统需要可靠的备份和复原吗?2.需要数据通信吗?3.有分布处理功能吗?4.性能很关键吗?5.系统是否在一个已有的、很实用的操作环境中运行?6.系统需要联机数据项吗?7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入?8.需要联机更新主文件吗?9.输入、输入、文件或查询很复杂吗？10.内部处理复杂吗?11.代码需要被设计成可复用的吗?12.设计中需要包括转换及安装吗?13.系统的设计支持不同组织的屡次安装吗?14.应用的设计方便用户修改和使用吗?2022/12/1295面向功能的度量Fi:2022/12/1013面向功能的度量每个功能点〔FP〕的错误数每个功能点〔FP〕的缺陷数每个功能点〔FP〕的本钱每个功能点〔FP〕的文档页数每个人月完成的功能点〔FP〕数2022/12/1296面向功能的度量每个功能点〔FP〕的错误数2022/12/10扩展的功能点度量 复杂度加权因子测量元素 低 平均高 内部数据构造 □*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函数点指数2022/12/1297扩展的功能点度量 复杂度加权因子2022/12/10软件工程方案2022/12/1298软件工程方案2022/12/1016工程估算估算是一门科学，也是一门艺术估算软件开发工作的资源、本钱及进度需要：经历以前完成工程中有用的信息当仅存在定性的数据时进展定量测量的勇气2022/12/1299工程估算估算是一门科学，也是一门艺术2022/12/1017工程的不确定性对工程方案中的不确定性产生重大影响的因素复杂性工程的规模构造不确定性的程度历史信息的可用程度2022/12/12100工程的不确定性对工程方案中的不确定性产生重大影响的因素202工程方案的目标工程方案的目标是提供一个框架，使得管理者能够对资源、本钱及进度进展合理的估算，并随着工程的进展不断更新工程方案的目标是通过一个信息发现的过程实现的2022/12/12101工程方案的目标工程方案的目标是提供一个框架，使得管理者能够对软件的范围软件工程方案的第一个活动是确定软件范围软件范围包括：功能、性能、约束条件、接口及可靠性2022/12/12102软件的范围软件工程方案的第一个活动是确定软件范围2022/1资源软件方案的第二个任务是估算完成软件开发工作所需的资源：开发环境：硬件及软件工具可复用构件人员2022/12/12103资源软件方案的第二个任务是估算完成软件开发工作所需的资源：2软件工程估算软件本钱及工作量的估算永远不会是一门准确的科学。人员、技术、环境、策略等是影响软件最终本钱及开发所需工作量的主要因素。为了可靠地估算本钱及工作量：将估算拖延到工程的最后阶段。基于已经完成的类似的工程进展估算。使用简单的“分解技术〞来进展工程本钱及工作量的估算。使用一个或多个经历模型进展软件本钱及工作量的估算。2022/12/12104软件工程估算软件本钱及工作量的估算永远不会是一门准确的科学。软件工程估算软件工程估算的准确性取决于以下因素：方案者是否适当地估算待建造产品规模的程度。把规模估算转换成人的工作量、时间及本钱的能力工程方案反映软件工程组能力的程度产品需求的稳定性及支持软件工程工作的环境2022/12/12105软件工程估算软件工程估算的准确性取决于以下因素：2022/1软件规模估算四种估算问题规模的方法〔由PutnamtMyers92年提出)：“模糊逻辑〞法功能点法标准构件法修改法2022/12/12106软件规模估算四种估算问题规模的方法〔由PutnamtMye“模糊逻辑〞法要点：方案者必须说明应用软件的类型建立其定性的规模估算在最初的范围内精化该估算利用个人的经历和工程历史数据库功能点法：2022/12/12107“模糊逻辑〞法要点：2022/12/1025标准构件法与修改法标准构件法要点：软件由假设干不同的“标准构件〞组成估算出每个标准构件的出现次数使用历史数据来确定每个标准构件交付时的大小修改法要点：工程中包含对已有软件的使用，但该软件必须做某种程度的修改。估算必须完成的修改数目及类型。2022/12/12108标准构件法与修改法标准构件法要点：2022/12/1026估算误差的原因有时各种估算之间存在着巨大的差异，原因是工程的范围未能被充分理解，或被方案者误解。基于问题的估算技术中所使用的生产率数据对于该应用是不适宜的，或是太陈旧了，或是被误用。解决方案：确定引起差异的原因，重新估算，并调和各种估算的结果。2022/12/12109估算误差的原因有时各种估算之间存在着巨大的差异，原因是202基于过程的估算估算一个工程的最常用的技术是基于使用的过程进展估算，即，将过程分解为相对较小的活动或任务，再估算完成每个任务所需的工作量。要点：建立问题功能及相关的过程活动2022/12/12110基于过程的估算估算一个工程的最常用的技术是基于使用的过程进展经历估算模型计算机软件的估算模型使用由经历导出的公式来预测工作量，工作量是LOC或FP的函数。支持大多数估算模型的经历数据是来源于一个有限的工程样品集。没有任何估算模型能够适用于所有类型的软件及所有的开发环境。这种模型得出的结果必须慎重使用。2022/12/12111经历估算模型计算机软件的估算模型使用由经历导出的公式来预测工估算模型的构造典型的估算模型是通过对以前的软件工程中收集到的数据进展回归分析而导出的。这种模型的总体构造具有如下形式：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&Mellichamp2022/12/12112估算模型的构造典型的估算模型是通过对以前的软件工程中收集到的COCOMO模型由Boehm81年在其经典著作“软件工程经济学〞中提出的，称为：构造性本钱模型。Boehm的模型层次具有以下形式：模型1：根本COCOMO模型，将软件开发工作量〔及本钱〕作为程序规模的函数进展计算，程序规模以估算的代码行来表示。E=abKLOCbbD=cbEdb模型2：中级COCOMO模型，将软件开发工作量〔及本钱〕作为程序规模及一组“本钱驱动因子〞的函数来进展计算。E=aiKLOCbi*EAF模型3：高级COCOMO模型，包含了中级模型的所有特性，并结合了本钱驱动因子对软件工程过程中每一步骤的影响的评估。2022/12/12113COCOMO模型由Boehm81年在其经典著作“软件工程经济软件方程式软件方程式是一个多变量模型，它假设在软件开发工程的整个生命周期中的一个特定的工作量分布。E=[LOC*B0.333/P]3*(1/t4)2022/12/12114软件方程式软件方程式是一个多变量模型，它假设在软件开发工程的小结软件工程的估算包括：需要多长时间需要多少工作量需要多少人员需要多少资源〔硬件及软件〕包含的风险2022/12/12115小结软件工程的估算包括：2022/12/1033小结范围说明能够帮助方案者使用一种或多种技术进展估算，这些技术主要分为两大类：分解和经历建模。分解技术需要划分出主要的软件功能，接着估算实现每一功能所需的程序规模或人月数。经历技术使用根据经历导出的公式来预测工作量和时间。软件工程估算永远不会是一门准确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的准确度。2022/12/12116小结范围说明能够帮助方案者使用一种或多种技术进展估算，这些技风险管理2022/12/12117风险管理2022/12/1035被动和主动的风险策略风险:没有方法消除的不确定性。被动的风险策略：最多是针对可能发生的风险来监视工程，直到它们变成真正的问题时，才会拨出资源来处理它们。主动的风险策略：早在技术工作开场之前就已经启动风险管理。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后软件工程组建立一个方案来管理风险。风险的特征：不确定性、损失2022/12/12118被动和主动的风险策略风险:没有方法消除的不确定性。2022/风险分类工程风险：指潜在的预算、进度、人力〔工作人员及组织〕、资源、客户及需求等方面的问题以及它们对软件工程的影响。技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题。规约的二义性、技术的不确定性、陈旧的技术及〞先进的〞技术。商业风险：开发了一个没有人真正需要的优秀产品或系统〔市场风险〕开发的产品不再符合公司的整体商业策略〔策略风险〕建造了一个销售部门不知道如何去卖的产品由于重点的转移或人员的变动而失去了高级管理层的支持〔管理风险〕没有得到预算或人力上的保证〔预算风险〕某些风险根本无法事先预测2022/12/12119风险分类工程风险：2022/12/1037风险管理的七个原那么保持全面的观点采用长远的观点鼓励广泛交流结合软件强调持续的过程开发共享的产品鼓励协同工作2022/12/12120风险管理的七个原那么保持全面的观点2022/12/1038识别风险识别风险是试图系统化地确定对工程方案〔估算、进度、资源分配〕的威胁。标识风险的一个方法是建立风险条目检查表：产品规模—与要建造或要修改的软件的总体规模相关的风险商业影响—与管理或市场所加诸的约束相关的风险客户特性—与客户的素质以及开发者和客户定期通信的能力相关的风险过程定义—与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险开发环境—与用以建造产品的工具的可用性及质量相关的风险建造的技术—与参与工作的软件工程师的总体技术水平及工程经历相关的风险2022/12/12121识别风险识别风险是试图系统化地确定对工程方案〔估算、进度、资建立风险表

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

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

〔RMMM方案〕III.风险缓解、监控和管理N.风险#N2022/12/12124风险缓解、监控和管理方案

〔RMMM方案〕2022/12/1工程进度安排及跟踪2022/12/12125工程进度安排及跟踪2022/12/1043工程延迟的原因一个不现实的截止期限客户需求发生变化对工件量估计缺乏未将风险考虑到工程方案事先无法预计的技术困难事先无法预计的人力困难由于工程组成员间的交流不畅面导致的延期工程管理者未发现进度拖后，未能采取适当的措施2022/12/12126工程延迟的原因一个不现实的截止期限2022/12/1044工程管理者的目标一个大型工程可以分解成许多小的活动。工程管理者的目标是定义所有工程任务，识别关键任务，然后跟踪关键任务的进展以保证“一天一次〞的发现进度拖延情况。管理者必须建立一个具有一定详细程度的进度表，使得工程管理者能够监视进度，并控制整个工程。2022/12/12127工程管理者的目标一个大型工程可以分解成许多小的活动。2022工程进度安排的两种视角基于计算机系统的最终发布日期已确定，在此约束下将工作量分布在预先确定的时间框架内假定大致的时间界限已讨论过，但是最终发布日期是由工程开发组设定，且在对软件进展仔细分析之后定义最终发布日期2022/12/12128工程进度安排的两种视角基于计算机系统的最终发布日期已确定，在工程进度安排的原那么阶段划分相互依赖性时间分配工作量确认定义责任定义结果定义里程碑2022/12/12129工程进度安排的原那么阶段划分2022/12/1047人员与工作量间的关系随着工程规模的增加，必然涉及到更多的人员参与随着工程人员的增加生产率呈下降的趋势原因是人与人之间通讯2022/12/12130人员与工作量间的关系随着工程规模的增加，必然涉及到更多的人员为工程定义任务集合过程模型都是由一个任务集合组成的，它使得工程组可以定义、开发和维护计算机软件。一个任务集合包括一组软件任务、里程碑和产品没有一个普遍适用于所有软件工程的任务集合2022/12/12131为工程定义任务集合过程模型都是由一个任务集合组成的，它使得工主要任务求精首先，为主要任务定义工程宏观进度表然后，将宏观进度表精化来创立一个详细的工程进度表2022/12/12132主要任务求精首先，为主要任务定义工程宏观进度表2022/12定义任务网络“任务网络〞是一个工程的任务流程的图形表示确定概念范围技术风险评估概念证明概念实现集成A,B,C技术风险评估技术风险评估概念实现概念实现2022/12/12133定义任务网络“任务网络〞是一个工程的任务流程的图形表示确定概进度安排两种可以用于软件开发的工程进度安排方法：程序评估和复审技术〔RERT〕关键路径方法〔CPM〕两种方法利用以下信息驱动工作量的估算产品功能的分解适当的过程模型的选择工程类型和任务集合的选择2022/12/12134进度安排两种可以用于软件开发的工程进度安排方法：2022/1进度安排两种方法都提供工程工作量划分的工具能够支持：确定关键路径通过使用统计模型为单个任务建立最有可能的时间估算计算为特定任务定义其时间“窗口〞的边界时间2022/12/12135进度安排两种方法都提供工程工作量划分的工具2022/12/1时间表和进度跟踪时间表：输出结果为甘特图〔GanttChart)进度跟踪和控制：定期举行工程状态会议评估所有在软件工程过程中所进展的复审的结果确定正式的工程里程碑是否在预定日期内完成比较工程表中列出的各项任务的实际开场日期与方案开场日期与开发者进展非正式会谈，获取他们对工程进展及可能出现的问题的客观评估使用获得值分析来定量地评估进展2022/12/12136时间表和进度跟踪时间表：2022/12/1054甘特图2022/12/12137甘特图2022/12/1055工程方案软件工程过程中的每一步骤都应该产生可以被复审，并能作为后续步骤的根底工作产品软件工程方案是一种面向广阔读者的简短文档在软件管理者、技术人员和客户间传达工程范围和资源信息定义风险并提出有关风险管理技术的建议定义管理复审的本钱和进度为与工程相关的所有人员提供软件开发的整体方法概述如何保证质量及变化的管理软件工程方案大纲2022/12/12138工程方案软件工程过程中的每一步骤都应该产生可以被复审，并能作软件工程方案大纲C.工作量、本钱和持续时间的估算3.风险管理(意外事件方案)C.时间表(甘特图)A.工程组构造(如果需要)2022/12/12139软件工程方案大纲3.风险管理(意外事件方案)2022/12/软件配置管理2022/12/12140软件配置管理2022/12/1058配置管理协调软件开发以减少不理解性到最小程度的技术称为配置管理软件配置管理〔SCM〕是贯穿于整个软件过程中的保护性活动。标识变化控制变化保证变化被适当地实现2022/12/12141配置管理协调软件开发以减少不理解性到最小程度的技术称为配置管软件配置软件过程的输出信息可分为以下类别：计算机程序〔源代码和可执行程序〕描述计算机程序的文档〔针对技术开发者和用户〕数据〔包含在程序程序内部或在程序外部〕2022/12/12142软件配置软件过程的输出信息可分为以下类别：2022/12/1变化的起源新的商业或市场条件，引起产品需求或业务规那么的变化新的客户需求，要求修改信息系统产生的数据、产品提供的功能或基于计算机的系统提供的效劳改组或企业规模减小，导致工程的优先级或软件工程队伍构造的变化预算或进度的限制，导致系统或产品的重定义2022/12/12143变化的起源新的商业或市场条件，引起产品需求或业务规那么的变化基线已经通过正式复审和批准的某规约或产品，它作为进一步开发的根底，并且只能通过正式的变化控制过程的改变。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且这些配置项已经经过正式技术复审而获得认可。2022/12/12144基线已经通过正式复审和批准的某规约或产品，它作为进一步开发的软件配置项〔SCI〕局部软件工程过程中创立的信息一个文档一个全套的测试用例一个已命名的程序构件。。。在现实中SCI被组织成配置对象，并被归类到工程数据库中2022/12/12145软件配置项〔SCI〕局部软件工程过程中创立的信息2022