《软件工程实践12项目跟踪.ppt》由会员分享，可在线阅读，更多相关《软件工程实践12项目跟踪.ppt（64页珍藏版）》请在三一办公上搜索。
1、北京理工大学软件工程实践,汤铭端中国航天科工集团公司204所,第十二讲,软件估计软件项目跟踪与控制,内容和目的,了解软件估计的概念掌握基本的软件估计方法掌握软件项目追踪与控制的原理了解软件项目追踪与控制的过程,软件估计方法,经验方法类比方法三点法Delphi技术分解法宽带Delphi技术,功能点方法生产率因子方法COCOMO方法IBM模型,经验方法,根据估计者自己的经验进行估计根据大家的共同经验进行估计标准工法标准工时根据项目和项目组的具体情况进行调整,类比方法,使用过去类似项目的确切数字，考虑与当前项目的差异程度，来估计当前项目的相应数据。当前项目估计=参考项目数据（1+差异百分比）差异百分
2、比当前项目比参考项目多（正）或少（负）的百分比。规模估计可以选取功能、输入输出等作为比较的参考依据。如当前项目系统与系统XYZ类似，XYZ系统的规模是10K代码行，当前系统比XYZ系统增加了约10%的功能。对当前系统的规模估计是：10K（1+10%）=11K。,三点法（Putnam模型）,通过估计最大值、最可能值、最小值，并加权平均的估计方法。估计期望值=（最大值+4最可能值+最小值）/6例如，若你认为软件规模的最大值是100K代码行，最小值是50K代行，而最可能值是60K代码行，则加权平均所获得的规模估计初始期望值为：（50+460+100）/6=65K代码行。,分解方法,进行整体估计感觉困
3、难的时候，可以采用分解方法。软件的功能结构、物理结构、软件项目的WBS等都为分解估计方法提供了参考框架。如根据软件的功能结构（逻辑结构）和/或软件（可能）的物理结构，将软件进行逐步分解，直至分解到能够对最小块进行较准确的估计。分别采用基于经验的方法和/或某种估计方法，对分解得到的各块进行估计。将这些子块的估计加在一起，获得对项目软件的整体估计。,各阶段工作量分布,德尔菲(Delphi)方法,在难以获得经验、历史数据及专家时，可考虑采用德尔菲方法作为一种有效的替代估计方法。德尔菲方法通过群体的智慧和交流分析来获得不断趋向准确和一致的估计结果。过程：成立估计小组，首先介绍项目和产品情况，而后让估计
4、小组成员分别进行估计，结果（第一轮）以列表和（或）直方图形式反馈给小组成员。在此基础上，估计值比平均值相差大的人各自讲述自己的理由，然后再分别进行下一次估计，得到新的估计结果（第二轮）。再次让小组讨论后进行新的估计（第三轮）。在第三轮结果的基础上进行最后的调整，得到的平均值就是估计结果。通过上述估计和反馈过程，人们的估计会越来越接近，意见更为统一，也就能得到综合各方面意见更为准确的结果。,宽带德尔菲(Wide Band Delphi),选择3至10名具有管理和估计经验的人员作为估计员共同讨论和了解软件项目的目标、范围、需求、资源分别按照各自的方法，对软件规模进行估计，并记录分别分析项目估计的意
5、外与风险，并确定估计风险与意外调整百分比分别根据其初始估计和估计风险与意外调整百分比，确定各自的最后估计或最后估计范围。计算公式为：最后估计=初始估计（1+意外调整百分比）最后估计范围=（1+减少调整百分比，增加调整百分比）初始估计必要时，安排进行讨论和再评估，以便进一步取得一致估计负责人对所有的最后估计进行平均，获得规模估计,生产率因子方法,假设在同等条件下开发速度（生产率）是一个常数。各机构可以根据以前的工作经验和历史数据，获得生产率因子。再根据估计的软件产品规模，估计项目的工作量和持续时间。确定项目产品的功能点估计项目工作量和持续时间5 功能点/人月 生产率因子9 功能点/人月生产率因子
6、平均值=8 功能点/人月工作量（人月）=功能点数/生产率因子持续月数=2.5（工作量人月数）0.38各阶段工作量划分,功能点方法,代码行数与编程语言相关的，不具可比性功能度量是一致的、可比的先进行核心计算获得未调整功能点（UFP），然后用调整因子获得值调整因子（VAF），将UFP乘以VAF，就达到了调整功能点（AFP）。AFP=UFPVAFUFP的计算：考虑五个功能分量：外部输入EI，外部输出EO，外部查询EQ，文件EIF，外部接口ILF。UFP=IEIEI+IEOEO+IEQEQ+IEIFEIF+ILIFLIFVAF根据软件项目和软件产品的14个相关属性计算获得。,未调整功能点UFP计算公式
7、,五个功能分量,用户输入数：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。用户输出数：计算每个用户输出，它们向用户提供面向应用的数据。这里输出是指报表、屏幕、出错信息等。一个报表中的单个数据项不单独计算。用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。文件数：计算每个逻辑的主文件（如数据的一个逻辑组合。它可能是某个大型数据库的一部分或一个独立的文件。）外部接口数：计算所有机器可读的接口（如磁带或磁盘上的数据文件），利用这些接口可以将信息从一个系统传送到另一个系统。,调整功能点AFP计算公式,AFP
8、=UFP0.65+0.01Fi，I=1-14Fi是对影响产品规模的14个因素进行分析确定的“复杂度调整值”，取值范围是0-5Fi通过回答后面的问题后参照以下标尺得到,Fi,系统需要可靠的备份和复原吗？需要数据通信吗？有分布处理功能吗？性能关键吗？系统是否在一个已有的、很实用的操作环境中运行？系统需要联机数据项吗？联机数据项是否需要在多屏幕或多操作之间切换以完成输入？需要联机更新主文件吗？输入、输出、文件或查询很复杂吗？内容处理复杂吗？代码需要被设计成可重用吗？设计中需要包括转换及安装吗？系统的设计支持不同组织的多次安装吗？应用的设计方便用户修改和使用吗？,COCOMO方法,构造性成本模型（CO
9、nstructive COst MOdel）Barry Boehm 提出当前使用最为广泛和最有效的估计软件项目开发成本和工作量的方法两个核心方程：用规模估计工作量；用工作量估计项目持续时间Effort=a(Size)bTdev=c(Effort)dEffort(人月)，Size(KLOC)，Tdev(月),COCOMO的层次,基本COCOMO模型：将软件开发工作量（或成本）作为程序规模的函数进行计算，程序规模以估算的代码行表示中级COCOMO模型：将软件开发工作量（或成本）作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、项目属性的主观评估高级CO
10、COMO模型：包含了中级模型的所有特征，并结合了“成本驱动因子”对软件工程过程中每一个步骤（分析、设计等）的影响的评估,COCOMO针对的软件项目类型,有机方式（Organic），主要关注数据处理、事务和数据检索较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严肃的需求开展工作嵌入式方式（Embedded），基于硬件系统的集成部件必须在一组严格的硬件、软件及操作约束下开发的软件项目半分离方式（Semi-Detached），介于有机方式和嵌入式方式之间一个中等的软件项目，具有不同经验水平的项目组必须满足严格的及不严格的需求,基本COCOMO的参数,中级COCOMO的公式和参数,
11、Effort=a(Size)bEAF,EAF=(I=1-15),产品属性RELY：所需的软件可靠性DATA：数据库的大小CPLX：产品复杂性计算机属性TIME：执行时间方面的约束STOR：主存限制VIRT：虚拟机的易变性TURN：计算机周转时间,人员属性ACAP：分析员能力AEXP：应用领域中的实际经验PCAP：程序员能力VEXP：虚拟机使用经验LEXP：程序语言使用经验项目属性MODP：现代程序设计方法TOOL：软件工具的使用SCED：所需的开发进度,表示15个成本属性的取值连乘，从产品、计算机、人员、项目等方面考虑,每个成本属性取值在0.9至1.4。平均情况下取1.0；如果对成本的影响较大
12、取大于1.0；否则取小于1.0,高级模型,高级模型进一步对中级模型进行了两方面的改进：a.提出了针对不同开发阶段的成本属性因子b.提出了成本属性因子按照模块级、子系统级、系统级等三级产品层次结构变化和确定,COCOMO2.0,1995年形成适用面更宽、更为精确的改进模型COCOMO2.0COCOMO2.0的核心公式与COCOMO一致，但系数不同a取常参数2.5，b变参数，由五个属性共同确定：PERC：开发先例FLEX：开发灵活性RESL：体系结构/风险解决方案TEAM：小组凝聚力PMAT：过程成熟度分别在1.0周围取值W1，W2，W3，W4，W5b=1.01+0.01 Wi,功能点和各种语言代
13、码行对比,IBM模型,总结IBM的60个项目数据，其中源代码从400到467000，开发工作量从12人月到11578人月，使用了29种编程语言和66中不同的计算机。E=5.2 L 0.91D=4.1 L 0.36=2.47 E 0.36S=0.54 E 0.6DOC=49 L 1.01其中，E为开发工作量，单位为人月；D为项目持续时间，单位为月；DOC为文档页数；L为源代码行数；S为所需的开发人员数。,项目的追踪和控制,项目管理,制定计划按计划去做执行计划检查计划的执行情况控制对计划的偏差,对比,项目管理计划执行追踪控制,PDCA环计划执行检查处理,项目的追踪和控制,计划、追踪、控制是项目管理
14、不可分割的三个环节控制的基础是信息，信息的获得靠追踪计划-追踪-控制是一个封闭循环，一个系统过程，一个以信息为共同核心的相互依赖、相互制约的互动过程。计划-追踪-控制的主要对象是进度、成本、质量,什么是项目追踪,项目追踪是指项目各级管理人员根据项目的规划和目标等，在项目实施的整个过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的下列活动过程。,项目追踪系统的设计,项目追踪对象范围变更关键假设资源供给非项目时间主要里程碑进度工作时间及任务完成情况项目总结报告,收集信息范围投入活动信息采购活动信息实施活动信息项目产出信息,项目追踪系统的设计,项目追踪过程观察测量分析报告,什么是
15、项目控制,项目控制是指在项目按事先制定的计划朝最终目标挺进的过程中，由于前期工作的不确定性和实施过程中多种因素的干扰，实施进展必然会偏离轨道，为此，项目管理者根据项目追踪提供的信息，对比原计划（即定目标），找出偏差，分析成因，研究纠偏对策，实施纠偏措施的全过程。项目控制的目的是使项目按预定的轨迹运行和实现。,项目控制原理,控制：为了改善某个或某些对象的功能和发展，需要获得并使用信息，并以这种信息为基础，加于该对象上的作用。系统原理、反馈原理、封闭原理。项目控制的三步曲原理：寻找偏差原因于趋势分析采取纠偏行动,项目控制方法,传统项目控制以各种文件、报表、图表为主要工具，以定期、不定期会议为主要方
16、法。项目控制文件：合同、工作范围细则、职责划分细则、项目程序细则、技术范围文件、计划文件项目控制会议：检查分析里程碑完成情况、计划未实现的影响、工作何时能完成、是否采取纠偏措施、何时才能回到计划轨道、下一步活动里程碑计划,控制过程,自动控制通过/通不过控制采取检测方式看特定的先决条件是否被满足项目用得最多的控制方式在基本控制检查点进行后控制为改善未来项目实现目标的机会而设立,项目控制系统的设计,项目控制系统的组成建立系统（目标）标准获得最新信息偏差分析、评价采取纠偏措施通知所有有关部门,项目控制分析工具偏差分析趋势分析关键比值因果分析,项目的三大控制权衡,质量控制进度控制控制权衡在质量、成本、
17、进度过程的约束三角形内完成项目是科学、艺术、意志的完美结合。如果项目超出了控制范围，想不牺牲范围、预算、计划进度或质量就实现项目目标是困难的。,对软件的特别建议,对10%或以上的进度偏移的纠正，如果没有对软件功能的10%或更多的减少，或者成本、风险10%或以上的增加，则是不可期望的。对延误的软件项目增加更多的人手通常使其延误更多。在选取供应商之前允许需方和客户利用演示体验软件产品的能力，可以缓解风险。用原型开发软件功能的一部分来演示功能的适当执行。关键的系统工程工作的实施不能没有足够的软件工程专门知识。,对软件的特别建议,与投资方合作，在项目过程中定期评审软件需求基线，以调整目标（成本，进度，
18、绩效）。项目成员和小组的数目应当与预算和进度相联系，正常的控制间距不应当被跨越。由于软件的结果的显现是困难的，评估进展存在许多困难。管理者必须定义和推敲确定进展的技术，以在早期发现成本或进度的超越，或绩效的不足。由于软件开发和维护活动通常依赖个人的技巧和经验，管理者应当努力防止在工作进行中不必要地替换职员。,项目追踪和监督CMM的要求,活动1 将已文档化的软件开发计划用于跟踪软件活动和传送状态。活动2 按照已文档化的规程修订项目的软件开发计划。活动3 高级管理者参与按照已文档化的规程评审那些对组织外部的个人和组所作的软件项目约定和约定的更改。活动4 将经批准的、影响软件项目约定的更改传达给软件
19、工程组和其它软件有关组的成员。活动5 跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施。活动6 跟踪项目的软件工作量和成本，必要时采取纠正措施。,项目追踪和监督CMM的要求,活动7 跟踪项目的关键计算机资源，必要时采取纠正措施。活动8 跟踪项目的软件进度，必要时采取纠正措施。活动9 跟踪软件工程技术活动，必要时采取纠正措施。活动10 跟踪与项目的成本、资源、进度及技术方面有关的软件风险。活动11 记录软件项目的实际测量数据和重新策划的数据。活动12 软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进展、计划、性能和问题。活动13 按照已文档化的规程在所选择的项目
20、里程碑处进行正式评审以评价软件项目的完成情况和结果。,软件项目的追踪与控制,追踪了解项目的进展情况采集项目进展数据统计分析与计划对比发现与计划的偏差,控制分析偏差决策是否调整计划按规程调整计划评审、实施、管理,项目追踪的方式,定期会议报告项目组成员定期报告里程碑检查评审记录审查软件质量保证人员报告统计分析与计划对比,软件项目追踪与控制过程,确定追踪元素工作量、成本、进度、资源、风险追踪个人工作周记项目工作月报阶段总结报告分析决策计划,规模、工作量、成本和进度跟踪表,关键资源跟踪表,风险跟踪表,个人工作周报,文档编制完成百分比计算方法,短期工作完成百分比计算方法,需求分析完成百分比计算方法,设计
21、工作完成百分比计算方法,程序开发完成百分比计算方法,测试设计完成百分比计算方法,课题工作月报,阶段总结报告,分析决策,根据偏差确定是否需要修改计划：项目工作产品的规模的实际值与项目计划中的预计值相差15%以上？项目工作产品的完成工期的实际值与项目计划中的预计值相差15%以上？项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差15%以上？项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的10%？,更改项目计划,明确修改内容外部约定的更改与批准受影响的组和个人参与和认可对约定的更改按照软件项目策划过程修订项目计划，并形成文档。必要时重新估计项目的规模、工作量、成本、进度、关键资源，重新分析软件风险对配置管理计划和质量保证计划进行相应修改评审项目计划更改审查和批准对项目计划的修改生成项目计划新版本并实施配置管理将约定和计划的更改传达到相关组和个人,谢谢！,68389085（O）68389504（H）,Boehm(1991)Top Ten Risk Item,人力不足不切实际的进度和预算开发错误的软件功能开发错误的用户界面镀金连续不断的需求变更外部执行任务的短缺外部供应部件的短缺实时性能的短缺紧张的计算机科学能力,
