《软件工程 度量开发人员课件》由会员分享，可在线阅读，更多相关《软件工程 度量开发人员课件（19页珍藏版）》请在金锄头文库上搜索。
1、调整视角和其他的最佳做法 报告人：蔡华雨,度量开发人员,本文作者,Forrest Shull 是高级研究员并且是马里兰州的弗劳恩霍夫中心实验软件工程测量与知识管理部门的主任 可以通过fshullfc-md.umd.edu联系他,Medha Umarji 是 Maryland Baltimore County大学的信息系统专业的在读博士生 可以通过联系她,Introduction,本文背景及相关知识 文章提出的问题和相关的解决办法 总结 参考文献,本文背景及相关知识,软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程。 软件度量的目的在于对此加以理解、预测、评估、
2、控制和改善。 通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品1。,软件度量程序,软件度量程序可能跻身于软件开发过程中最敏感项目的行列。 做得好的话，一个度量程序可以被证明是保持高效研发计划的一个有效工具特别是对大的分布式的项目。它可以帮助开发者感觉他们有一个交流进步和得到最需要的资源的公平分配的积极的方式。 但是，做得不好的话，度量程序会变成相互指责以及铸造指责的契机一个指责实际工作中的开发工作没有实践理想程序的借口。,软件度量程序,一个有效的度量程序必须同时满足产品和过程2。 软件产品度量用于对软件产品进行评价 并在此基础之上推进产品设计、产品制造和产品服务优化。软件产
3、品的度量实质上是软件质量的度量，而软件的质量度量与其质量的周期密切相关。 过程度量是对软件开发过程的各个方面进行度量 目的在于预测过程的未来性能，减少过程结果的偏差以及对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。,软件度量,但是制定过程度量的过程可能比较困难，因为这些度量表现了软件开发中技术因素与人工因素对抗区域。 软件度量的支持者经常觉得开发者和经理对于收集到的东西过于敏感，这也阻碍了正真的制定有意义的程序的机会。 度量的反对者认为度量可能被用作对抗“在战壕”里的人们方式，却不会为他们提供对他们工作的正真的评价。,一些挑战,过程度量很难与努力一一对应起来。 例如
4、，过程控制盘可能会报告已经改正了多少错误，但是改正不同类型的错误的努力是很广泛。 组织者可能使用度量去监控个人表现。 开发者经常感觉过程度量是一个威胁，它将失败的商业目标承诺与开发者受阻的工程生涯进步联系起来的。 普遍的度量引起不公平的不同项目之间的对比。 激励适得其反也就是说人们可能会以“使数据看上去很好”结束从而获得奖励。,本文目标,为了找到克服这些挑战的最佳做法，作者查找了一些研究文献。他们对定义一个框架需要选取哪些指标从而满足商业目标不感兴趣，相反对那些涉及建立有效程序的个人和组织因素更感兴趣。 研究方法 在作者的个人经验和文献调研的基础上，作者分析了三个比较好的实践方案，他们在这用收
5、集到的公司项目经理的观点来描述它们。 Medha Umarji最近进行了详细的项目研究，积累了丰富的经验。 与六个项目经理的半结构化的面试提供了丰富素材。,最佳实践一,定义一个适合所有的项目的过程度量程序 实践里的问题 同时收集核心和项目特殊度量是费时的。“我们需要和手上项目最相关的度量，而不是仅仅只有与商业目标相关的度量，”一个项目经理解释道，“但是到时候问题就来了.如果我们同时为了这个组织和我们的项目收集度量，那我们到时会感到工作非常的超负荷。” 另外，被采访者也强调了只收集一个度量集的风险也就是说，数据分析可能太泛化了从而对于一个特殊的项目没有太大的意义，或者太特殊了从而放弃了对于决策组
6、织有用的信息。,最佳实践一,解决方法 避免度量程序的过度集中，每一个利益相关者需要全心参与到设定度量收集目标中来。项目经理，客户以及高级管理层需要一起协同讨论怎样分享控制而不是被动接受它3。 组织应该平衡质量审计过程（如果存在）以及鼓励合格的审计人员使用它，不仅只为了指出哪个组做错了同时也要为了与经理协商并建议他们怎样改善过程。 接着一个结构化的，目标驱动的度量框架，例如GQM+策略4可以分析不同的利益相关者和他们的需求。,最佳实践二,建立在从现有程序中自然得到的措施的基础上 对于度量采用来说，在过程中逐步的分阶段改变相比激进的改变来说是更好的策略，这是很明确的。 一个被推荐的方法是重新调整奖
7、励结构从而为达到度量目标提供奖励。 另外一个方法是使数据收集依赖于现存的项目时间表，并且把它当作一个项目的可交付成果。,最佳实践二,实践二带来的问题 调整时间表来适应度量相关的的任务是最主要的问题，因为让客户同意一个度量程序所必需的花费以及时间表上的调整是很困难的。 一个普遍的争论是拨出的时间不包含无形的例如开发者和度量小组的随访。 重新调整激励机制让管理者感到了需要让他们的数字看起来很好的巨大的压力。这是基于最终的数字而不是基于他们如何很好的遵守计划的真正的精神的奖励机制所固有的一个缺陷。,最佳实践二,作者提出的解决建议 研究显示花费时间去填写度量表的人可能更多关注让数字更好看而不是关注数字
8、对于项目更精确的反映。这是一个普遍的困境，一般建议项目组考虑怎样让度量符合正常工作活动，而不是把它当作附加的东西。 作者认为一般来说避免抵抗和过程改变需要被实施是与所有的度量使用者一起磋商而不是采取自顶向下的方式。一个选择是创立一个假象的度量程序使用它来给使用者一个参考点来考虑可能的围绕标准实施进度改变的可能途径。,最佳实践三,透明，透明，透明 人们对于关于项目度量都很热情。 所以对于所有相关的小组来说，相信数据反映了真实，是客观的可证实的，且只会被用作改进步骤的有效性以及产品的质量是很重要的。 一个为了创造透明的度量收集系统的建议是需要给开发者和基层管理者完全的访问收集数据的权利。 实践中的
9、问题 给报告度量创造一个安全的始终如一的环境可能是所有的最佳实践实施的最大挑战。 研究发现项目经理和开发者都不相信度量程序。开发者害怕他们的行为会被监控，同时经理会害怕错过奖励。 另外一个开发人员的阻力是他们怀疑经理没有报告准确的数据。,最佳实践三,作者提出的解决建议 创造一个报告度量时的随意的环境，而不是一个正式的步骤。 项目开发者看起来好像宁愿选择一个走廊上的会谈或者在喝咖啡的时候谈论度量而不喜欢在召开会议时讨论度量。 这个范例的巨大成功的原因是因为任意形式的项目跟踪和控制对于所有的项目成员不是立即可见的。 所以，即使一个简单的白色书写版可以成为一个项目成员信任和可用的工具。 建立一个更有
10、文化的信任度量的形式是长期的挑战，这是需要由测量小组内部抓住的从小的地方着手例如，确保所有的分析和结果能在团体或项目的级别上得到报告是没有错误的且可以充分的反映真实项目数据。,总结,实现这些最佳实践的主要策略是认识不同参与者的角度并且力图匹配它们。 一个度量生态系统可以包含不等的从开发者到经理到更高层次的管理者和客户。调整角度对于所有的小组来说都是洽谈优先和领会到其他人的压力的第一步。Nathan Baddoo和Tracy Hall报告说经理没有很好的理解对于开发者的激励因素，例如激励自主和工作升迁，也低估了开发者对于改善行动程序的热情。 不能打发走或驳回利益相关者，必须保持交流线路的开放，从
11、而建立可以同时被度量人员可以接受的并且能够精确反映实际的度量程序。 允许利益相关者之间的妥协发生，但需要在公开的环境下，这样可以帮助所有人理解其他人的关注点，同时每个人都必须为组织的利益妥协。 同样，透明也很重要，它可以消除那些造成各方面的人尝试用偷偷摸摸的小动作与度量程序对抗的诱因。,参考文献,1 软件度量_百度百科 2 软件度量-zsc521521的日志-网易博客 3 T. DeMarco and D. Hall, “Software Engineering: An Idea Whose Time Has Come and Gone?” IEEE Software, vol. 26, no. 4, 2009, pp. 96, 95. 4 V. Basili et al., “GQM+Strategies: Aligning Business Strategies with Software Measurement,” Proc. 1st Intl Symp. Empirical Software Eng. and Measurement (ESEM 07), IEEE CS Press, 2007, pp. 488490. 等,谢谢,
