一、实验目的
了解软件过程，了解软件过程的质量度量方法，掌握软件过程不同阶段中度量的侧重点及其各自的度量方法。
二、实验时间
2学时
三、实验内容
1.依据网络资源，了解软件过程度量中的相关内容，了解不同的软件过程阶段中度量
的侧重点及其各自的度量方法。
2.重点了解软件需求过程、软件测试过程及软件维护过程的质量度量方法。
3.以需求过程为主要内容，展开对软件需求过程的质量度量方法的综述。
四、实验要求
实验报告内容至少3000字。
不得抄袭。
五、实验总结
1、软件过程度量的过程是企业的整个软件过程的一部分，它与软件过程的其他部分
（其他子过程）想好联系又想好影响，软件过程中不同角色和组织对度量需求和应
用各不相同。
第一是在项目组内的各个层次的项目管理可根据度量信息对软件项目
的成本投入、进度、质量、风险和资源进行计划和控制。
而且度量信息还是项目状
态信息交流的基础。
第二是过程组可通过度量信息确定过程和产品的质量以订制过
程改善计划，并掌握过程改善的效果。
第三是高层项目管理关系的是在其管理下的
项目在成本投入、进度、质量、风险、资源和过程改善的整天信息而不是具体的细
节。
并关心项目组和整个企业的生产能力。
软件过程度量在对过程和产品的具体特
性进行分析和总结的基础为其提供决策信息。
第四是客户及最终用户可通过产品或
过程的度量信息来对软件开发状态进行跟踪和监督以降低客户方承担软件开发风
险。
最后项目外部的其他研究实体也可通过积累的大量度量新消息来分析研究软件
过程技术。
在软件过程度量中分四个阶段。
第一阶段工作主要分两部分：首先，接受度量请求后，应明确标识度量设计的组织单位，如一个项目、一个功能领域、整个企业；
建立度量的管理和软院委托事项（责任义务）；还要通过声明或是新闻知晓组织单位。
其次，分配资源和人员，并明确度量的使用者、分析者、度量库管理员的责任和义
务，以保证资源的提供和度量的实施。
第二阶段度量过程计划的主要工作就是为度
量实施开发一个详细的计划，内容包括：明确描述作为度量环境的组织单位的相关
特征；标识信息需求，明确所需信息的各种目的或用途、重要程度，选择最后信息
内容，并形成文档；选择满足信息需求的度量；定义数据收集、分析和报告过程；
定义评估信息产品好度量过程的标准；最后，评审、批准度量任务，并提供度量所
需资源。
第三阶段度量过程的执行活动包括：整合度量具体过程、手机数据、分析
数据、形成文档。
第四极端评价度量的活动包括：评估度量和度量过程；标识潜在
的度量过程改善。
2、软件需求过程度量
软件需求是软件开发的依据，软件学期管理是软件生产与质量管理中最重要的一个环节，需求管理从用户需求获取开始，贯穿于整个软件的生命周期，其目的是保证用户的需求得到完善、一致的理解；所有的需求都被标识出来；所以需求的实现过程都得到跟踪、监督与验证；所有需求的变化都得到控制、理解和处理。
软件需求包括三个不同层次:业务需求、用户需求和功能需求
业务需求：反映了组织机构或客户对系统、产品的高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求：描述的是用户的目标或用户要求对系统必须完成的任务。
需求功能：定义了开发人员必须实现的软件功能，用户能使用这些功能完成他们的任务，从而满足业务需要。
需求获取是需求过程的主体，是客户和开发者两个团体互相沟通、识别需求的过程。
在这一过程中，客户和开发者通过提取、定义稀奇来相互约束。
收集需求不是一个简单的工作。
获取需求的范围应比较宽广，以满足目标系统设定的边界。
在需求获取中，应专注与需求而不是设计。
专注于设计就会强调开发问题而忽略用户的需求，导致需求获取的失败。
需求中掺杂了设计，会使用户难以验证需求，同时用户可能无法理解设计方面的语言。
软件测试过程
软件测试过程主要分为五个阶段：需求分析阶段：只要就是对业务的学习，分析需求点。
测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
《测试方案》编写完成后也需要进行评审。
测试方案阶段：主要是对测试用例和规程的设计。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
其中操作步骤和预期结果需要编写详细和明确。
测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
同样，测试用例也需要评审。
测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
软件维护过程
运行中的软件都包含有错误，有些在测试过程中没有发现需要修改，还有一些需要适应新的软件硬件环境以及增加新的功能以及把今天的技术用于明天的系统。
改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷；因在软件使用过程中数据环境发生变化(例如一个事务处理代码发生改变)或处理环境发生变化(例如安装了新的硬件或操作系统)，需要修改软件以适应这种变化。
用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，就需要修改软件把这些要求纳入到软件之中。
应确定维护的类型。
用户常常把一项要求看作是改正性维护，而维护人员可能把同一项要求看作是适应性或完善性维护，所以确认维护类型需要维护人员和用户反复协商，弄清楚错误情况
和用户裕要做的修改类型。
3、软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种
可能的解法，并且分配给各个软件元素。
需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
定对系统的综合要求。
分析系统的数据要求，导出系统的逻辑模型，修正系统的开发计划。
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
进行需求分析时，应注意一切信息与需求都是站在用户的角度上。
尽量避免分析员的主观想象，并尽量将分析进度提交给用户。
在不进行直接指导的前提下，让用户进行检查与评价。
从而达到需求分析的准确性。
分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。
在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。
发软件系统最为困难的部分就是要准确说明开发什么。
最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。
如果做错，这将是会最终给系统带来极大损害的一部分，并且以后再对它进行修改也极为困难。
目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间的接口是系统开发人员最头痛的问题。
对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。
在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。
软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。
作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制。
质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。
多角度描述产品对用户和开发人员都极为重要。