软件度量总结(精)
软件项目工作经验总结(9篇)
软件项目工作经验总结（9篇）不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。
更何况估算的太精确，反而会失去灵活机动的空间。
不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。
正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。
不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。
这是一种不负责任的做法，如果要削减一定要有理由。
客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。
贪多必然导致会浪费，偷减必然导致不足。
这两个结果恐怕都不是一个合格的项目经理的作为。
客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。
在使用经验时，要注意现在和参考经验之间的差异。
不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。
项目管理培训软件项目工作经验总结篇620__年7月23日，我有幸成为公司一员。
我进入公司也快6个月，回首过去的几个月中我也感受到不少的喜悦，尤其在公司度过的时间让我难忘。
因为在领导的指导下，同事大力的帮助下，客服了不少困难，因此我也成长了不少。
可以说是虚心学习，努力工作，以团队的利益和进度为中心是我一直坚守的原则。
虽然说在这短短的几个月中没有辉煌的成果，也算是经历了一段不平凡的考验。
因为我在公司感受到了团队的力量，同时也让自己更适合团队工作，尤其是我在技术方面更是突破不少，从以前的认识与了解到今天的熟练，想到此内心无比高兴。
尤其是刚进公司的两个月，想想当时的我是多么的笨拙和弱小，因为进入公司以后对于公司需求和业务流程不是很熟悉。
在同事不断帮助和指导下让我迅速提升起来以适应公司需求，以至于后来的工作做得非常舒心愉快。
20__年度个人主要工作内容和任务的完成情况20__年度，我的主要工作集中在产品研发及优化领域，现将参与的主要工作内容和任务的完成情况总结如下：一、新人学习对公司的整体状况和运营模式进行了解，重点针对合同管理系统的适用领域、场景以及客户群体、一般性需求进行学习。
软件项目工作总结(10篇)
软件项目工作总结(10篇)软件项目工作总结1软件项目管理已经到了学期的最后，我们seed小组的软件项目也已完工，这一个学期真的是获益匪浅！礼平老师曾经说我既可以走技术路线也可以走管理路线，一切都看我自己。
真的很是佩服老师的看人眼光，很犀利。
我知道，现在的我不是没有能力去做好，只是自己没有去做，一直在殿外徘徊，不肯付出努力向前迈进。
从大一到现在，我的专业技术一直都是我的短板，理由么，很简单，就是因为自己懒，不肯花时间去做。
从以前不知道自己想做什么，到现在明确目标，可以说，软件项目管理课程给了我很多灵感，让我从自己纷乱的思绪中看清楚了自己最想要的东西。
一直自己很喜欢管理，我会花费很多时间在这上面，从大一到现在一直都是，一直没有改变过。
在技术上，我总是给自己找借口，总是偷懒，但我现在明确了一点，没有技术，就没有管理！脱离技术的管理是不可能的，也是不现实的。
在这个行业里，技术是一切的基本，想作工程师也好，想作管理者也好，技术都是起步的根基。
而我这次所经历的项目更让我明确了这一点。
在这个小项目里，虽然我们两个星期就开发完成了这个软件，并交付使用，但是问题还是很多的。
在这么一个小项目里，由于需求、设计、代码、文档产生的问题，每一个看似容易，却都需要实实在在的经验在里面，都需要对业务的熟悉，有语言功底作根基。
在这个项目里，我负责软件配置管理工作，在文档的整理过程中，我仔细看了他们的需求分析，概要设计，数据库设计，模块设计等文档，也参与了风险分析文档的编写，承担了用户手册和项目成本估算的编写。
在这个过程中，我明确了技术的实在意义，明确了技术对我的指导作用，同时也明确了自己的学习道路应该怎么走下去！整个项目进行的过程中，我一直在努力从中学习，我旁听开发组的会议，为组长提供管理意见，为会议、文档制定标准，整个过程我收获了很多。
1、软件项目小组中的人员安排要职责明确，并有配套的管理记录，整理每个人的工作进度，随时更新，以方便开发人员、测试人员之间的沟通。
软件测试中的质量度量与评估方法
软件测试中的质量度量与评估方法软件测试是保证软件质量的重要环节之一。
在软件开发过程中，通过合理的质量度量和评估方法可以有效地评估软件的可靠性和可用性，提高软件的质量水平。
本文将介绍软件测试中常用的质量度量和评估方法。
一、质量度量方法1.代码覆盖率代码覆盖率是衡量测试覆盖的度量方法之一。
它通过检测测试用例是否覆盖软件中的每一行代码来评估测试的全面性。
常见的代码覆盖率指标包括语句覆盖率、分支覆盖率和路径覆盖率等。
2.缺陷密度缺陷密度是指在单位代码行数或功能点数中存在的缺陷数。
缺陷密度越低，表示软件质量越高。
通过统计缺陷密度可以了解缺陷数量的变化趋势，及时发现和解决问题，提高软件质量。
3.可靠性度量可靠性是评估软件稳定性和可用性的重要指标。
常用的可靠性度量方法包括平均无故障时间（MTBF）和平均修复时间（MTTR）。
MTBF指软件在使用过程中平均无故障的时间，MTTR指软件在出现故障后平均修复的时间。
通过这两个指标可以评估软件的可靠性水平。
4.性能度量在软件测试中，性能度量是评估软件性能表现的一种方法。
常用的性能度量指标包括响应时间、吞吐量和并发性等。
通过对性能指标的度量可以了解软件在不同负载下的性能表现，从而为性能优化提供参考。
二、质量评估方法1.功能验证功能验证是评估软件功能是否符合需求规格的方法之一。
通过测试验证软件是否正确实现了需求规格中的功能点，包括功能的正确性、完整性、兼容性等。
2.易用性评估易用性评估是评估软件用户界面是否友好、易于操作的方法。
常见的易用性评估方法包括用户调查、专家评审和用户体验测试等。
通过这些方法可以了解用户对软件界面的满意度和使用体验，进而改进软件的用户界面设计。
3.安全性评估安全性评估是评估软件安全性的方法。
常见的安全性评估方法包括安全漏洞扫描、安全性测试和安全代码审查等。
通过这些方法可以发现软件中存在的安全漏洞和潜在风险，并提出相应的解决方案。
4.可维护性评估可维护性评估是评估软件在后续维护过程中的可操作性的方法。
第7章 软件测试度量与评价
ISO-9126质量模型
• 使用质量： 在规定的使用环境下软件产品使特定用户在达到规定目标方 面的能力。 它是从用户观点出发，来看待软件产品用于特定环境和条件 下的质量，反映的是从用户角度看到的软件产品在适当系统 环境下满足其需求的程度。
可移植性的 依从性
ISO-9126质量模型
• 内部质量： 是从内部观点出发的软件产品特性的总体，是针对 内部质量需求被测量和评价的质量。
• 内部质量特征： 可维护性、灵活性、可移植性、可重用性、可读性、 可测试性、可理解性等。
ISO-9126质量模型
• 外部质量： 软件产品在规定条件下使用时满足需求的程度。 它是从外部观点出发的软件产品特性的总体，当软件执行时，更 典型地是使用外部度量在模拟环境中，用模拟数据测试时，所被 测量和评价的质量，即在预定的系统环境中运行时可能达到的质 量水平。
软件度量
• 软件的度量取向一般包括项目规模、项目成本、项目进度 、顾客满意度、质量等度量，以及品牌资产度量、知识产 权价值度量等。
• 度量取向要依靠事实、数据、原理、法则；其方法是测试 、审核、调查；其工具是统计、图表、数字、模型；其标 准是量化的指标。
软件质量及度量
软件质量需要 度量
质量包括哪些 方面？
• (415+230)/[(69+129+500+393)-(35+68+100)] *100%=73%
• 3．缺陷密度
• 软件缺陷密度是一种以平均值估算法来计算出软件缺 陷分布的密度值。程序代码通常是以千行为单位的， 软件缺陷密度是用下面公式计算的：
McCall质量模型 *
软工常用公式总结
软工常用公式总结在软件工程领域，公式是解决问题和优化代码的重要工具。
它们可以帮助开发人员优化性能、预测系统行为和评估开发过程。
本文将总结一些软工常用公式，以帮助读者更好地理解和应用于实际开发中。
1. 软件质量模型公式软件质量模型可以用于评估软件的质量特性，如可靠性、可用性、可维护性等。
常用的软件质量模型包括ISO 9126标准和IEEE 1061标准。
其中，ISO 9126标准公式如下：软件质量 = 功能性质量 + 可靠性质量 + 易用性质量 + 效率质量 + 可维护性质量 + 移植性质量2. 软件估算公式软件估算是开发过程中的关键任务之一，它可以帮助确定项目的预算、进度和资源需求。
下面是常用的几种软件估算公式：- 功能点估算公式：FP = UFP × [TDI × (UFP/UCP)]其中，FP表示功能点数，UFP表示未调整的功能点数，TDI表示技术复杂度乘数，UCP表示用户复杂度乘数。
- COCOMO模型：effort = a × (KLOC)b其中，effort表示人力投入，a和b是可调整的系数，KLOC表示以千行代码为单位的软件规模。
3. 软件度量公式软件度量是衡量软件产品和开发过程特性的一种方法。
以下是几个常用的软件度量公式：- 代码覆盖率：Coverage = (被测试代码覆盖的行数 / 总代码行数) ×100%- Cyclomatic复杂度：V(G) = E - N + 2P其中，E表示程序中边的数量，N表示程序中节点的数量，P表示程序中连接的组件数量。
4. 软件质量指标公式软件质量指标可以帮助评估软件产品的质量水平和开发过程的有效性。
以下是几个常用的软件质量指标公式：- 代码复杂度：Complexity = Cyclomatic Complexity + LOC / Methods - 代码重复率：Duplication Rate = (重复代码行数 / 总代码行数) ×100%- 代码规范违规率：规范违规率 = (违规代码行数 / 总代码行数) ×100%以上仅是软工领域常用公式的一小部分，不同的问题和场景可能需要使用其他特定的公式和指标。
软件开发度量及考核方法
软件开发度量及考核方法一、引言如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。
虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。
所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。
该考核方法是技术支持部软件开发人员和测试人员的试行版本。
二、目的对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。
三、考核实施办法1、定义1.1 、软件项包括1）、技术文档："软件工程产品集"所确定的配置项。
主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。
2）、计算机程序。
1.2 、度量数据的来源1）、项目计划：过程度量中及时度考核数据的主要依据。
2）、测试文档：计算机程序质量考核数据主要依据。
3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量2.1度量指标主要根据各类软件项检查表的检查指标来确定。
例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。
（本文末尾附了各工作阶段的考核检查指标表）2.2质量等级1）软件项的质量等级的确定根据度量综合指标进行。
2）度量综合指标计算公式为：Total =刀QiMi。
3）其中i=1,2,...n 代表指标数量；4）Q代表度量的指标；5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
2.3度量指标计算方法2.3.1、度量指标评分标准：根据软件项的各检查指标的缺陷率来确定，既为每232、缺陷率来源：主要是各软件项检查、评审、测试的过程所产生的缺陷跟踪表，缺陷跟踪表中的缺陷类别对应检查表中的检查指标。
软件质量管理实践总结
第一章：缺陷综述1.软件缺陷的立义：软件产品在某种程度上不能满足用户的需求。
2.软件缺陷的生命周期：从一个软件缺陷被发现、报告到这个缺陷被修复、验证，最后关闭的过程。
3.缺陷产生的原因：原因很多，例如重技术不重管理、项目监控和讣划做得不够好、不扎实等等。
4.缺陷是谁产生的：任何人都有可能产生缺陷。
5.缺陷发现的手段：同行评审、测试、管理评审、QA发现、项目组内部发现、客户反馈。
第二章：需求开发与管理1.需求的概念和层次①概念：需求就是以一种淸晰、简洁、一致且无二性的方式，对待开发的各个有意义方面的陈述的集合。
②层次：从应用角度看软件需求。
A.业务需求：反映组织机构/客户对系统产品高层次的目标要求B.用户需求：用户使用产品必须完成的任务C.功能需求：开发人员实现软件功能，使得用户能够完成的任务，从而满足业务需求2.需求管理：控制和维持需求的约定：需求追踪是双向的，正向由PM主导，其他人辅助，逆向由测试主导。
3.需求验证：评审为主，一般参与人员为各个技术的专家。
第三章：配置与变更管理1.槪念：一门用来记录并且控制软件产品数据的管理学科，是对各类工作产品的内容、版本、变更和发布进行控制。
①忽视软件配宜管理会导致如下现象：A.已经排除的bug,反复出现B.找不到最新修改的源代码C.找不到原来的编程人员D.发行的版本错误E.软件正常安装后不能工作F.异地不能正常工作2.配置控制委员会CCB：一般项目经理会根拯配置控制委员会的建议和批准管理各项活动并且控制它们的进程，一般组成人员：髙层经理、项目经理、关键的RD、关键的QA、PPQA 代表、CM代表、PM, CCB的组长不能是项目经理。
3.配置项：一般包含：计算机程序、开发者和用户的文档、数据等，每一个配置项需表明：作者、时间、原因、当前状态、版本号。
4.配置管理活动：①内容A.制左配置管理计划B.建立三库（开发库、受控库、发行库）C.确左配置标识规则D.进行版本管理和发行管理E.实施变更控制F.进行配麗审计G.报告配苣状态5.变更管理活动①发生在开发过程的所有阶段，从需求分析到产品开发再到维护。
软件测试中的质量度量与评估
软件测试中的质量度量与评估在软件开发的过程中，软件测试起着至关重要的作用。
软件测试的目标是验证和验证软件的正确性、可靠性和性能等方面。
而质量度量和评估是软件测试过程中必不可少的一部分。
本文将介绍软件测试中的质量度量与评估，并探讨一些常用的度量指标。
一、质量度量的概念质量度量是指通过一系列的度量指标来衡量软件的质量。
它可以帮助软件测试人员了解测试过程中存在的问题和潜在的风险，从而采取相应的措施进行优化和改进。
二、质量度量的分类1. 功能测试度量：通过度量软件功能的完整性、正确性和可用性等指标来评估软件的质量。
2. 性能测试度量：通过度量软件的响应时间、吞吐率和资源利用率等指标来评估软件的性能。
3. 可靠性测试度量：通过度量软件的容错性、可恢复性和可靠性等指标来评估软件的可靠性。
4. 安全性测试度量：通过度量软件的安全性和防护能力等指标来评估软件的安全性。
5. 易用性测试度量：通过度量软件的用户界面、用户体验和易于理解程度等指标来评估软件的易用性。
三、常用的度量指标1. 缺陷密度：指在软件测试过程中发现的缺陷数量与代码量的比例。
2. 测试覆盖率：指测试用例中所覆盖的代码百分比。
3. 平均修复时间：指发现缺陷后修复的平均时间。
4. 平均回归测试时间：指在软件开发过程中每次修改后执行回归测试的平均时间。
5. 可靠性指标：如MTBF（均值故障时间）、MTTF（平均无故障时间）等。
6. 用户满意度评估结果：通过用户反馈和调查问卷等方式来评估软件的用户满意度。
四、质量评估的方法1. 代码静态分析：通过对代码进行静态分析，评估代码的质量和可维护性。
2. 黑盒测试和白盒测试：通过黑盒测试和白盒测试的结果来评估软件的质量。
3. 自动化测试：通过自动化测试工具来执行测试用例，评估软件的质量。
4. 用户反馈：通过用户的反馈和评价来评估软件的质量。
五、质量度量与评估的重要性1. 提高软件质量：通过对软件质量进行度量和评估，可以及早发现和解决问题，从而提高软件的质量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件度量总结这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。
一.软件度量的应用范围。
经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。
度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。
由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。
其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度量,但人很难度量。
软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。
定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很可能成为无目之本,出现错误。
软件度量的方法体系主要包括 5个方面:1. 项目度量,目的在于度量项目规模、成本、进度、顾客满意度等,辅助项目管理进行项目控制; 2. 规模度量,主要依靠经验和经验的模型,是决定项目成败的重要原因之一,是估算工作量、成本预算及策划项目进度的基础; 3. 成本度量, 4。
产品度量,实质上是软件质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是McCabe 复杂性度量法; 5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属性,减少结果的偏差,主要包括成熟度度量(例如 CMMI,GJB5000A、管理度量(主要包括里程碑管理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配置管理度量、生命周期度量三个大的方面。
不同层次的人员对软件度量有不同的需求。
高级管理人员,如 CEO 、 COO ,关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产力、成本控制、效率等,他们更多的是着眼于总体的性能,交付情况以及产品的运行状态等,而不是项目每天完成的情况;项目管理层对度量的需求则是准确估计和控制软件产品,主要考虑通过每周的对比评测、研究进展,以确保项目开发方向的正确性,或者主动捕捉测量点,由度量分析师发展成一种模型,预测项目未来的结果。
二.软件测量基础。
软件测量是经典测量科学基础上的具体应用,为了使软件度量真正发挥作用,必须掌握测量的基础知识。
软件度量不能用现成的公式进行计算,需要根据自己的实际情况建立模型,并通过历史数据来定义参数。
首先,测量的表示理论。
人们一般习惯从比较中获得对事物的理解,例如二元关系、三元关系中谁比谁大等,而这种关系可以映射到数学世界中,由此可以把测量定义为从经验世界到关系世界的一种映射,把度量定义为为了描述实体的某种属性,而为这个实体赋予的数字或者符号。
比如为了描述人的年龄,将这个人从出生到现在的所经历的年数作为年龄属性赋予这个人。
第二,测量和模型。
模型是对显示的抽象,除去了实现的细枝末节,使我们可以我们从特定的角度看待实体和概念。
测量可以分为直接测量和间接测量两种,而一个预测系统通常由一个数学模型和一组预测规程组成,其中,预测规程的作用是确定预测参数并对结果进行解释。
第三,测量数据收集与分析。
良好的数据应该具有正确性、准确性、一致性的特点,并要具有合适的精度,能与特定活动或持续时间相关联,且能够重复出现。
就数据的收集而言,第一步要制订数据收集计划,然后决定测量项,根据需要选取合适的测试粒度,并确保产品处于配置控制之下,必须了解对产品的哪些版本进行测量;三.软件规模的估算与度量。
软件规模的估算与度量部分,我主要想写一下我理解的功能点估算及用例点估算的主要流程及估算过程中需要注意的问题。
在此之前先简单地描述一下传统的代码行度量,一般认为空白行和注释行不应该计算在代码行中,并把不带注释的行数缩写为 NCLOC(又称为有效代码行 ELOC, 并将注释行定义为 CLOC, 则总长度为LOC=NCLOC+ELOC,注释行的密度用 CLOC/LOC表示。
但由于所用的语言不同导致代码行不同等原因,代码行不适于作估算,更适合用作完成之后的测量。
接下来是功能点估算。
功能点估算提出的目的是使得不同国家,不同人对同样的需求估算得到的规模大小基本相同;其缺点是对需求描述的要求比较高。
在这个方法中,功能点是一个度量单元,度量所得到的值和软件的代码量没有关系,也就不再依赖于选择的编程语言。
至于功能点估算的过程,最简单地来说包括 4个步骤:①估算数据功能规模,②估算事务处理规模,③计算调整因子,④根据公式计算功能点数。
数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响,可以分为内部逻辑文件和外部接口文件两种。
事务处理规模则可以分为三种形式,即外部输入、外部输出、外部查询。
首先要对上述概念进行识别,内部逻辑文件可以描述为一个基本处理在应用程序内部维护逻辑上相关的数据块或者控制信息,其中, “ 维护” 指增删改查等操作, “ 逻辑上相关” 指仅考虑用到的或者逻辑上有关系的数据;外部接口文件可以理解为系统不进行维护的逻辑文件。
这两种文件的复杂贡献度可以分别通过数据元素类型(字段个数和记录元素类型(数据表的数目两个纬度来考虑,每个具体文件所对应的加权系数可以查询对应的复杂型矩阵来得到,最后把加权系数相加即得到这两种文件的总功能点数,即数据功能的功能点数。
这个过程中,难点在于对每个文件进行数据元素类型和记录元素类型的识别,有一系列的注意事项。
接下来是对外部输入、外部输出和外部查询的识别,外部输入可以简单地理解为用户通过系统所进行地增、删、改,其结果可以是维护了内部的数据文件,也可以是改变了系统地行为状态;外部输出可以理解为系统所作出的反映,例如显示屏上显示某些结果,或者系统行为发生某些改变;外部查询没有对数据的处理,仅仅是对已有信息的抓取。
这一部分相对容易理解,识别起来也比上面那部分容易一些,其加权系数由数据元素类型 DET (与内部逻辑文件和外部接口文件中的 DET 基本相同和参考文件类型 FTR (被事务处理的文件总数两个维度考虑,具体数值也是可以通过查询矩阵表来获得,分别得到后相加即可以得到事务处理的功能点数。
接下来需要计算值调整因子 VAF , VAF 根据非功能需求获得,不同的项目可能会根据实际情况有一些调整,然后根据公式求得 VAF 的具体值。
最后一步就是将前面两步所得的功能点相加, 再乘以调整因子,得到最终的功能点数。
由于软件工程不断向着面向对象甚至面向过程方向发展,而功能点估算仍然是结构化的估算方法, 所以出现了用例点估算。
用例点估算的方法和功能点估算原理相似,都是讲系统先按照一定的原则分割成数个部分,分别得到估算结果之后再相加得到总的结果。
用例点估算首先要明确什么是用例,我认为用例描述了一个动作序列,这些动作是系统为了响应事件而做的,其结果是产生了对发起事件的角色有价值的可见的结果。
用例点估算必须具备的基础是良好的用例图和场景描述,有了这两个基础,估算过程相对来说就很简单,也可以分为 4个基本步骤:①确定未调整功能点数,②计算复杂因子,③计算软件规模,④估算工作量。
第①个过程主要是用例角色复杂度和用例事务数的识别,角色可以是人,计算机或者组织, 关键是分清它用什么方式与系统交互,查到对应的权重,从而计算获得未平衡角色数;事物是指从用户到系统再到用户的一个“回路”,根据场景描述确定每个用例的事物数,同样查询其对应的权值之后计算得到未平衡用例数,最后这两个数值相加得到未调整功能点数。
第②步中复杂度因子的计算主要分为技术复杂度因子 TCF 和环境复杂度因子 ECF 两类,与功能点估算中调整因子的计算方法相同,对各个项目分别打分后得出两个复杂因子。
第③步,软件规模 UCP 即为技术复杂度因子 TCF ×环境复杂度因子 ECF ×软件规模UCP 。
最后根据历史数据确定每个 UCP 完成的工作量(通常为 16人时 ~30人时,与计算所得的 UCP 相乘即为开发工作量,在此之外,用例点模型将项目管理、质量保证等时间作为补充效果 SE 计算, 补充效果 SE+开发工作量就是最终的估算结果。
四.过程规划、预测与监控中的度量。
这一章主要简单地说一下对项目评估预评审技术(PERT 、原始的 CoCoMo 模型、诤值分析以及项目监控中数据分析的理解。
由于理解不是特别深刻,所以只能简单的描述一下现有的了解。
关于 PERT , 我认为最主要的就是对三个数据的评估,即乐观的 OD (不考虑效率和中断,完成任务的最小时间量、悲观的 PD (考虑各种培训、生病以及工作时间做与工作无关的事情等各种延误情况和最有可能的 ED (不是 OD 和 PD 的中间值,而是根据经验估算认为的最可能的情况。
根据这三个值得出项目的 beta 分布及其图像(使用 beta 分布而不是用正态分布的原因是人们的评估往往偏向于乐观,图中使得左右两侧面积近似相等的分割线所对应的时间即为最可能的工作量。
这种估算方法需要策划小组人员分别进行估算得到结果后,再对结果按照一定的策略进行对比分析,得到最终的估计值。
原始的 CoCoMo 模型是用于软件开发不同阶段的三个模型的集合。
基本、中间、详细这三个层次的模型分别用于对项目了解很少、明确需求、完成设计以后三个阶段,但都具有相同的形式,即 E=aSb F 。
E 是按人月计算的工作量, S 是按千行交付的原指令数目的测量规模, F 是调整因子(不同层次的模型中取不同值, a 和 b 又根据软件的三种类别(有机式、半分离式和嵌入式分别取不同的数值。
诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一起来。
这个方法的核心是比较准确的估算出工作完成的百分比。
计划的费用 PV 是一条表示期望值的基线,代表着截止到某一时刻计划完成的工作,可以用计划消耗的费用来表示;实际的费用 AC 表示截止到某一时刻实际的成本;诤值 EV 表示截止某一时刻,实际完成的工作应该消耗的成本。
同一时刻的 EV 与 PV 的单一变量是工作量,分别是实际的工作量和计划的工作量,所以这两个值可以得出进度的偏差; AC 与 EV 的单一变量是实际的费用,分别是实际消耗的费用和计划消耗的费用,所以这两个值可以得出成本的偏差。
这是两个最重要的偏差。
五.产品设计质量度量与控制。
我认为非功能性需求是软件度量中最容易被忽略的,也最不容易被清晰掌握的部分。
在需求分析中, 常见的非功能性需求虽然都能设计感官需求、易使用性、安全性、可靠性、可维护性等方面,但对其要求的描述都只停留在定性的描述上,没有明确的度量标准。