软件功能模型范文（精选9篇）
软件功能模型 第1篇
关键词：软件功能点,通信行业,需求,自动化,模型
1 软件功能点技术
(1) 总体说明。由IFPUG即国际功能点用户组基于软件功能点分析研究, 通过一致的标准来规范软件功能点数, 使得基于功能点的软件需求功能量的标准统一。功能点分析技术是从用户角度度量软件开发的一种标准方法。功能点分析基于用户的逻辑功能需求, 而不用考虑应用的物理实现。 (2) 功能点技术-业务功能需求计数。把用户的业务功能需求分为数据功能需求和处理数据的事务功能需求;数据功能指提供给用户的以满足内部和外部数据需求的功能性, 分为内部逻辑文件 (ILLF) 和外部接口文件 (EIF) 。复杂性有数据元素类型 (DET) 和记录元素类型 (RET) 。 (3) 功能点技术-事务功能计数。数据分为应用内部逻辑数据和应用外部的接口数据, 事务分为对数据的外部输入、输出和查询。事务功能指提供给用户的以满足应用数据处理需求的功能性, 分为外部输入 (EI) 、外部输出 (EO) 、外部查询 (EQ) 。复杂性由数据元素类型 (DET) 和文件引用类型 (FTR) 决定。
2 基于软件功能点的通信行业软件需求自动化分析模型
该论文的根本目的是在系统需求分解的过程中, 可按照描述的方法和流程进行自动分解, 保证每个用户需求分解粒度的准确性和一致性, 以便达到量化项目管理。该方案可以明确需求分解的数据实体及元素属性, 同时也可以将需求数据处理分解成相应的基本处理过程。从而围绕两者进行由顶至下需求横纵分解的过程。
该方法适用一切企业管理系统, 包含单一系统、升级系统、融合系统。
2.1 获取用户原始需求信息
通过现在已有的需求信息搜集工具 (TFS等) 进行初步搜集用户信息, 该信息拆分出需求标识、需求名称、需求内容描述、应用人员。将TFS系统功能搜集的用户数据保存在数据Ur集中。进行分层描述到具体的需求信息。
2.2 构建系统边界集
根据需求实际存在情况划分系统边界域, 就目前实用情况, 划分成若干类型:人与机器、系统与系统、接口连接、模块间。
该系统边界域的建立规则为树形结构。
识别出的信息, 保存在边界域中, D{dij, i=0n, j=0m}。例如识别出系统1, 系统2.接口1等, 再识别出系统1下的模块1、模块2、模块3等, 如此建立整个融合系统的边界域。
按照该方法, 识别出的边界域可明确具体需求工作明确数据的访问和维护边界, 为数据识别和划分提供标准。边界类型可根据需求分析要求, 增加界面类别。
2.3 构建系统使用对象数据信息
建立系统使用人员信息集, 根据用户需求信息采集系统的信息, 建立系统使用对象类别。按实际系统主要业务的使用人员构建基础信息Pepole List列表中。
2.4 构建系统操作属性信息
根据系统数据处理过程, 需求分析的操作分析粒度要达到五个操作, 即单数据查询、新增、修改、删除、报表查询。
2.5 对Ur集数据逐条分析分解, 维护系统分析分解L域中
(1) 获取用户初步需求的基础信息。拆分获取的信息得到需求标识、需求名称、需求内容描述、应用人员信息保存在临时内存中。当触发进行需求分析分解时, 逐条提取内存中的用户需求信息进行分解。 (2) 对应系统域D, 根据树形结构遍历树的末端子节点。该步骤的约束条件按照树形结构遍历到最末端子节点, 将该条需求分配到相应的系统域内。如此, 需求可能涉及多个系统的维护, 将所有匹配信息归入到最终需求分解域L域中。待需求分解后, 可按照系统域遍历关系划分出所有数据访问维护边界信息。 (3) 分解L域的每一条操作项的数据属性元素。针对每一个功能首先识别出系统范围内所有逻辑相关且用户可识别的数据信息, 即数据实体信息。判断操作项的实体属性在系统域内本系统度量维护的实体属性和本系统引用其他系统维护的实体属性。对每条操作箱的属性元素循环识别, L域中元素实体集单独分配内存进行记录。最终并入L集中。 (4) 合并功能相同需求分解项。每一条数据的唯一标识包含需求编码、系统、用户、操作项、数据实体、数据元素属性。L域中每新增数据都要与已有数据比对, 如果与其他数据相同, 则剔除。保留L域的唯一性。
2.6 量化需求分解L域
需求分解结构完成后, 可以达到量化数据的目标。可按照每条数据进行量化, 操作功能计数=系统内部访问维护的实体元素属性个数 (系统边界) +访问系统边界外的实体元素个数
获得的数据可累积、叠加, 根据具体的需求功能建设情况自动计算。
3 基于软件功能点的通信行业软件需求自动化分析系统功能模块
(1) 分为数据新增功能和数据处理新增功能。 (2) 数据新增功能分析过程:对已有的数据元素属性进行对比, 对于新增字段的要按照新增后的数据实体元素个数进行计算。 (3) 数据处理功能新增分析过程:对已有的功能模块, 新增功能, 新的流程或者新的功能, 则先把该功能和操作类、查询类、统计类映射关系。分别计算该基本过程的穿越定义界面的元素个数, 进行计数, 维护了基本元素数据表的个数和访问接口的个数。 (4) 作为升级项目, 如果没有新增数据元素, 则无数据新增, 反之, 按照新建项目规则进行需求数据功能分析。事务新增按修改后维护的数据元素与原有功能进行对比。
4 总结
将软件功能点的进入通信行业软件的需求管理, 提供给用户评估需求规模的统一计算标准, 使得在项目初期、需求分析、项目验收等各阶段的工作量评估有依据。该模型的应用也提升需求分析的效果, 保证了需求分析分解的充分性、有效性、全面性。经过实验, 验证了该需求自动化分析系统及模型的有效性。
参考文献
[1]曹济等编著.软件项目功能点度量方法与应用[M].清华大学出版社, 2008.
[2]GB/T18491.6-2010信息技术软件测量功能规模测量第6部分:GB/T18491系列标准和相关标准的使用指南[A].2005.
软件质量保证模型探析 第2篇
软件质量保证模型探析
【摘要】本论文针对软件质量体系及保证模型中的相关问题进行一些有益的探索，力图通过对相关模型的比较研究，寻求到能够全面反映和保证软件质量的保证模型。在软件组织中，可以将ISO和CMM结合起来应用，即：把ISO作为软件质量管理的指导性框架，把CMM作为具体实施层的应用，这样就可以充分利用二者的优势来共同完成对软件开发过程的质量控制，从而达到既提高软件开发效率又保证所开发的软件具有较高的质量。 【关键词】能力成熟度模型;软件生命周期;软件质量保证 目前，软件企业面临的最大的问题是顾客对产品不满意，究其原因，软件质量保证技术的不完善是主要原因之一。就整体而言，我国的软件质量管理和质量保证工作仍处于创建阶段，国外的软件质量管理和质量保证工作也不尽完善，现有的软件质量保证是在软件开发过程中的每一步都进行“保护性活动”。主要内容包括对方法和工具应用的规程、技术复审、测试策略、保证与标准符合的规程，以及度量和报告机制。在技术上的主要手段是测试和复审，在管理上的主要手段是ISO9001的认证[1]。ISO9001是一种“静态”的质量保证标准，只规范了质量体系的最低可接受水平，并不描述一个组织如何实现这些系统质量要素来满足顾客的需求;CMM是一个致力于组织过程改进的框架，问题是并未提供有关实现关键过程域所需要的具体知识和技能[2]，在一定程度上造成了开发过程的僵化，对于当前软件业来说也是很难实现的。 一、ISO9001与CMM的联系 CMM和ISO9001都涉及质量管理和过程管理，并且都受到类似的利害关系驱动，两者之间的相似之处总结为以下四点： (1)它们的`精神一致，都有一个基本思想：“言所行，行所言”; (2)二者都强调管理、过程、规范化和文档化; (3)ISO9001与CMM的出发点都是通过对生产过程进行管理来确保产品的质量; (4)都源自以戴明为首的管理专家的制度管理思想。 首先，不管是CMM还是ISO9001都强调对产生应用软件之过程的管理，提高软件产品的生产效率和软件的质量，同时，软件工程理论的广泛运用也推动了软件产业由小规模生产到集成自动化生产迈进。这也充分说明，软件产品的质量不仅表现在最终产品的质量，还应该包含软件产生过程的质量，只有这样，才能使软件组织连续不断地生产出高质量的软件产品。 此外，CMM和ISO9001并不是孤立或彼此矛盾的。它们的核心思想都来源于埃华茨・丹明和约瑟夫・佐兰提出的全面质量管理思想，这种质量管理思想强调预防，而不是检修缺陷与错误改正。因此，它们之间的结合在理论上是可能的。ISO9001的每一个质量要素都可以对应到CMM2―3级中关键过程区域的特征上。而CMM在生产过程中的管理重点，又弥补了ISO9001在微观管理上的不足。另外ISO9001：版中增加的度量正好是CMM第四级强调的重点。 二、ISO9001与CMM的区别 (一)保证质量的方式不同 ISO9001作为质量保证标准，只论述了质量体系的最小需求，即合格质量体系的最低可接受水平。它是一种“静态”标准，企业只要符合它要求的条件并通过权威机构的审核，就可以通过认证，证明企业的内部管理已经达到一定水平，符合该标准规范的要求。而CMM则强调过程控制、过程管理、持续的过程改进。CMM不仅仅是对产品质量的认证，更是一种改善软件过程的模型，它以一种结构化的成熟度框架描述了软件管理和工程实践，指出了软件过程不断改进的科学途径[3]。它所定义的5个级别就像5个台阶，企业必须一步一步地“攀登”。每一个成熟度级别，既是企业发展的阶段性目标，又是评价企业能力水平的一个标准。当通过某一级CMM评估后，企业还必须持续不断地改进过程，其目标是要达到可持续发展、可优化的程度，以此来实现高质量、高效率、低成本的生产软件。因此，可以认为CMM是一个“动态”模型。 需要强调的是，ISO9001着重于考核产品的质量和产品过程的受控状态，给企业提供一种PASS/FAIL的检查体系，即企业的过程能力只有两种状态，虽然在缺陷预防和内审管理中涉及到了过程改进，但是并没有对改进的目标和方法进行指导和控制。CMM则重点考核软件组织的工程能力，而且突出不断改进、升级的要求。显然过程不断的改进、能力不断的增强，新技术的应用就会收到更好与更快的成效，产品的质量就会不断的得到提高和保障。 (二)认证审核过程不同 ISO的认证过程分为两个情况――机构或者通过了ISO认证，或者没有。如果机构通过了ISO认证，其过程已满足ISO9000的标准要求。与此不同的是，CMM给出的是过程改进的体系。CMM将软件过程划分成5个成熟度级别――从原始级(第一级)到优化级(第五级)。软件机构可处在其中的任何一个级别，它的每一级对所要实现的关键过程域都有详细的要求，并且强制企业能自我更新和持续改进，以实现缺陷预防[4]。这对于提高软件企业自身质量管理素质是非常有利的。 但CMM毕竟是一个在学术报告基础上建立起来的一套评估体系，它的认证结果是由SEI授权的首席评估员寄一封带有本人签名的信给被评估者，并在SEI备案，没有任何证书，终生受用，中间不再审查。而通过ISO9000认证的企业，要在中国技术监督局备案，并且发证给企业，并要求每年审查，所有参加多边认可协议的国家必须认可，适用性强。 (三)适用范围不同 ISO9001标准是一个适用于提供各种产品/服务企业的通用型的企业标准，而且主要是针对制造业制定的[5]。正是由于ISO9001的通用性，使得它无法满足软件企业更深层次的专业化管理需求。而CMM是专门针对软件开发企业设计的，可以帮助软件企业有效地管理软件过程。 ISO是通用的，并且是从客户和外部审计者的角度来写的，它提出的是最基本的要求，所以不是十分具体。而CMM是面向软件的，即面向软件开发人员的，它提供了机构内部过程改进的指南，而且CMM对每个级别的关键过程域都有很详细的说明，光CMM的关键实现的说明就有500页之多。 (四)管理层次不同 从管理层次上看，ISO要比CMM所处的级别高，ISO只是提出了一个质量管理框架，是属于指导性的框架，而CMM提出的框架是一个操作性很强的框架，其KPA过程非常明确地提出了过程目标和过程注意事项。 三、相关建议 在软件组织中，可以将ISO和CMM结合起来应用，即：把ISO作为软件质量管理的指导性框架，把CMM作为具体实施层的应用，这样就可以充分利用二者的优势来共同完成对软件开发过程的质量控制，从而达到既提高软件开发效率又保证所开发的软件具有较高的质量。我国中小软件企业在建立软件质量保证模型时，应该考虑以下几个方面的因素： (1)某种程度上市场目标决定质量目标，只有能满足客户需求的软件才可以称为好的软件。 (2)在考虑最终软件成品的同时，要考虑软件过程的质量保证。 (3)全面质量管理及CMM思想的集成，要关注软件过程控制能力以及过程持续改进能力。 参考文献 [1]李娟.基于QFD的软件质量保证模型研究[D].西北工业大学，. [2]李娟.CMM实施过程模型及实例化方法研究[D].中国科学院软件研究所，. [3]叶俊勇，汪同庆等.软件开发的质量保证体系[J].计算机与现代化，，6：27-32.
软件质量保证模型探析 第3篇
【关键词】能力成熟度模型;软件生命周期;软件质量保证
目前，软件企业面临的最大的问题是顾客对产品不满意，究其原因，软件质量保证技术的不完善是主要原因之一。就整体而言，我国的软件质量管理和质量保证工作仍处于创建阶段，国外的软件质量管理和质量保证工作也不尽完善，现有的软件质量保证是在软件开发过程中的每一步都进行“保护性活动”。主要内容包括对方法和工具应用的规程、技术复审、测试策略、保证与标准符合的规程，以及度量和报告机制。在技术上的主要手段是测试和复审，在管理上的主要手段是ISO9001的认证[1]。ISO9001是一种“静态”的质量保证标准，只规范了质量体系的最低可接受水平，并不描述一个组织如何实现这些系统质量要素来满足顾客的需求;CMM是一个致力于组织过程改进的框架，问题是并未提供有关实现关键过程域所需要的具体知识和技能[2]，在一定程度上造成了开发过程的僵化，对于当前软件业来说也是很难实现的。
一、ISO9001与CMM的联系
CMM和ISO9001都涉及质量管理和过程管理，并且都受到类似的利害关系驱动，两者之间的相似之处总结为以下四点：
（1）它们的精神一致，都有一个基本思想：“言所行，行所言”;
（2）二者都强调管理、过程、規范化和文档化;
（3）ISO9001与CMM的出发点都是通过对生产过程进行管理来确保产品的质量;
（4）都源自以戴明为首的管理专家的制度管理思想。
首先，不管是CMM还是ISO9001都强调对产生应用软件之过程的管理，提高软件产品的生产效率和软件的质量，同时，软件工程理论的广泛运用也推动了软件产业由小规模生产到集成自动化生产迈进。这也充分说明，软件产品的质量不仅表现在最终产品的质量，还应该包含软件产生过程的质量，只有这样，才能使软件组织连续不断地生产出高质量的软件产品。
此外，CMM和ISO9001并不是孤立或彼此矛盾的。它们的核心思想都来源于埃华茨·丹明和约瑟夫·佐兰提出的全面质量管理思想，这种质量管理思想强调预防，而不是检修缺陷与错误改正。因此，它们之间的结合在理论上是可能的。ISO9001的每一个质量要素都可以对应到CMM2-3级中关键过程区域的特征上。而CMM在生产过程中的管理重点，又弥补了ISO9001在微观管理上的不足。另外ISO9001：2000版中增加的度量正好是CMM第四级强调的重点。
二、ISO9001与CMM的区别
（一）保证质量的方式不同
ISO9001作为质量保证标准，只论述了质量体系的最小需求，即合格质量体系的最低可接受水平。它是一种“静态”标准，企业只要符合它要求的条件并通过权威机构的审核，就可以通过认证，证明企业的内部管理已经达到一定水平，符合该标准规范的要求。而CMM则强调过程控制、过程管理、持续的过程改进。CMM不仅仅是对产品质量的认证，更是一种改善软件过程的模型，它以一种结构化的成熟度框架描述了软件管理和工程实践，指出了软件过程不断改进的科学途径[3]。它所定义的5个级别就像5个台阶，企业必须一步一步地“攀登”。每一个成熟度级别，既是企业发展的阶段性目标，又是评价企业能力水平的一个标准。当通过某一级CMM评估后，企业还必须持续不断地改进过程，其目标是要达到可持续发展、可优化的程度，以此来实现高质量、高效率、低成本的生产软件。因此，可以认为CMM是一个“动态”模型。
需要强调的是，ISO9001着重于考核产品的质量和产品过程的受控状态，给企业提供一种PASS/FAIL的检查体系，即企业的过程能力只有两种状态，虽然在缺陷预防和内审管理中涉及到了过程改进，但是并没有对改进的目标和方法进行指导和控制。CMM则重点考核软件组织的工程能力，而且突出不断改进、升级的要求。显然过程不断的改进、能力不断的增强，新技术的应用就会收到更好与更快的成效，产品的质量就会不断的得到提高和保障。
（二）认证审核过程不同
ISO的认证过程分为两个情况——机构或者通过了ISO认证，或者没有。如果机构通过了ISO认证，其过程已满足ISO9000的标准要求。与此不同的是，CMM给出的是过程改进的体系。CMM将软件过程划分成5个成熟度级别——从原始级（第一级）到优化级（第五级）。软件机构可处在其中的任何一个级别，它的每一级对所要实现的关键过程域都有详细的要求，并且强制企业能自我更新和持续改进，以实现缺陷预防[4]。这对于提高软件企业自身质量管理素质是非常有利的。
但CMM毕竟是一个在学术报告基础上建立起来的一套评估体系，它的认证结果是由SEI授权的首席评估员寄一封带有本人签名的信给被评估者，并在SEI备案，没有任何证书，终生受用，中间不再审查。而通过ISO9000认证的企业，要在中国技术监督局备案，并且发证给企业，并要求每年审查，所有参加多边认可协议的国家必须认可，适用性强。
（三）适用范围不同
ISO9001标准是一个适用于提供各种产品/服务企业的通用型的企业标准，而且主要是针对制造业制定的[5]。正是由于ISO9001的通用性，使得它无法满足软件企业更深层次的专业化管理需求。而CMM是专门针对软件开发企业设计的，可以帮助软件企业有效地管理软件过程。
ISO是通用的，并且是从客户和外部审计者的角度来写的，它提出的是最基本的要求，所以不是十分具体。而CMM是面向软件的，即面向软件开发人员的，它提供了机构内部过程改进的指南，而且CMM对每个级别的关键过程域都有很详细的说明，光CMM的关键实现的说明就有500页之多。
（四）管理层次不同
从管理层次上看，ISO要比CMM所处的级别高，ISO只是提出了一个质量管理框架，是属于指导性的框架，而CMM提出的框架是一个操作性很强的框架，其KPA过程非常明确地提出了过程目标和过程注意事项。
三、相关建议
在软件组织中，可以将ISO和CMM结合起来应用，即：把ISO作为软件质量管理的指导性框架，把CMM作为具体实施层的应用，这样就可以充分利用二者的优势来共同完成对软件开发过程的质量控制，从而达到既提高软件开发效率又保证所开发的软件具有较高的质量。我国中小软件企业在建立软件质量保证模型时，应该考虑以下几个方面的因素：
（1）某种程度上市场目标决定质量目标，只有能满足客户需求的软件才可以称为好的软件。
（2）在考虑最终软件成品的同时，要考虑软件过程的质量保证。
（3）全面质量管理及CMM思想的集成，要关注软件过程控制能力以及过程持续改进能力。
参考文献
[1]李娟.基于QFD的软件质量保证模型研究[D].西北工业大学，2006.
[2]李娟.CMM实施过程模型及实例化方法研究[D].中国科学院软件研究所，2005.
软件功能模型 第4篇
可信软件基础研究是国家重大研究计划。可信软件是指能充分证明或者认证该系统提供服务时能满足可靠、安全、保密、容错、生存和实时等一个或多个高可信性质的软件系统[1]。由于可信软件所涉组织和人员越来越多, 需求越来越复杂, 需求分析面临前所未有的挑战。
需求分为非功能需求 (Non-Functional Requirement, NFR) 和功能需求 (FR) 。在维基百科中, NFR定义为能够详述系统运行的评价标准而不是具体行为的一种需求, 即“to be”而不是“to do”。 维基把NFR按执行质量和演化质量分类:前者包括安全性和可用性等, 它们可在系统执行时加以观测;后者包括可测试性、可维护性、可扩展性、可量度性等, 它们已经嵌到软件系统的静态结构中。
可以用“质量属性”“约束”“质量目标”“质量服务需求”等近似概念来理解NFR, 其区别是, 质量等概念更广泛一点, 它也包括功能需求。在ISO/IEC9126标准中, 指出了软件的5个NFR:可靠性、可用性、有效性、可维护性和可移植性。
随着NFR的研究不断深入, IEEE在软件工程领域标准ANSI830-1993中把NFR拓展到13种:性能、接口、操作性、资源、验证性、可接受性、文档编制、保密性、可移植性、质量、可靠性、可维护性、安全性。
本文把可信软件中NFR界定为软件产品必须符合的具体标准, 如质量属性、设计约束、合约、规范等;它描述的不是软件所做内容, 而是可信性质。
因此, NFR与可信软件密切相关。NFR的关系较为复杂, 经常互相冲突, 例如:可用性与性能。多维异质NFR的相互依赖性、优先性、冲突消解、权衡分析与完整性表述方式已经成为可信软件需求分析领域的研究热点[2]。
已经有很多学者对NFR进行了有代表性的研究。Myloplulos[3]、Chung和Nixon[4]提出了NFR框架。它能捕获早期NFR, 然而它是一种定性的方法, 不易对“满意”等进行精确描述。Bachmann等描述了把特征属性进行模块化而自动转化成体系的“ADD”框架[5,6]。但其指定NFR时进行了不必要地严格限制。Xu等为可信系统提出了架构模式, 研究如何把可靠性需求转换成相应的软件体系结构, 并对一个NFR是否履行进行验证[7]。不过, 这种方法难以实现这些NFR。此外, 它并没有对NFR之间的冲突进行处理和解决。Zayara等提出了一个软件体系评价定量模型, 它关注NFR之间的优先性、NFR的子集[8]。不过他们的方法更多地关注整个体系而不是特定的某个备选设计。Sadana等提出了一种利用FR和NFR的集成来对NFR之间的冲突进行分析的方法, 它不仅考虑NFR之间的冲突同时也考虑功能需求之上的NFR[9]。然而, 此研究限于非常高级别和定性的需求。
2 FO-QSIG图
2.1 Q-SIG图
Chung提出SIG图 (Softgoal Interdependency Graphs, 软目标相互依存图或称为软目标耦合图) [10], 常被用于表达品质属性 (Cysneiros[11]) 和架构决策 (Cooper[12]) 。SIG图是一种软目标耦合图, 用于NFR的分解, 并在此基础上进行冲突的权衡分析。然而, SIGs图只是进行定性分析并产生庞大的设计图, 这阻碍它的广泛使用。
Marew等提出了QSIG图[13]。QSIG图是一个定量化的SIG图, 而不再仅仅赋予一些定性的描述, 像:“不行的、满意的”。而是把满意表示为一个连续的变化值, 并用代数方法来描述分析。一个典型的QSIG图显示在图1中。相比普通SIG图, 它增强的地方主要有:无论是结点还是连接都是定量标记。向下的箭头表示分解, 向上箭头是表示一个子结点对父母的贡献。
2.2 QSIG图的不足
QSIG图虽然在SIG图定性分析的基础上进行了定量分析的补充, 不过也有一些不足。①它在分解NFR时只是把简单地遵循“与或”两种关系, 整个系统不够严密。另外, 由于它对相互关系并没有阐述清楚, 而且随着NFR数量增加, 相互之间的正负影响复杂化, 会导致QSIG图无法描述。所以有必要对其进行补充。②只能表示负面影响。
2.3 特征模型
特征概念来自于卡耐基梅隆大学软件工程研究所Kang等所提出一种面向特征的领域工程方法 (Feature-Oriented Domain Analysis) [14]。特征是直接影响终端用户的系统属性和实现属性的策略。用户和开发者等涉众必须通过考虑特征在系统中的重要性和优先程度来做出相应的决策。例如图2中, 特征传输就有两个子特征自动和手动, 用户购买汽车时, 就必须在两个子特征中做出一个决策[15]。
2.4 QSIG与FODA比较
2.5 FO-QSIG图的提出
从表1发现QSIG与FODA互补, 因此把面向特征的思想引入到QSIG图和NFR建模的研究中, 把特征模型与Q-SIG图进行整合, 提出面向特征的定量软目标耦合图 (Feature Oriented Quantitative Softgoal Interdependency Graphs, FO-QSIG) 。
FO-QSIG图主要由多层结构构成。从根结点 (NoteRoot) 到子结点的分解沿袭着系统分解或精化 (Refine) 成属性 (Attribute) 再分解成子属性, 最后分解成为用叶子结点 (NoteLeaf) 所表示的用来实现某种属性的具体策略 (Tactic) , 因为有些属性分解较细, 可能产生有子属性层或子策略层, 从而形成了N层结构。为了节省篇幅和叙述方便, 仅示范三层主要结构, 并把属性和策略统一称为特征。实际应用中, 要注意到每个特征都必须有自己唯一名字而且在软件文档说明SRS中应该包含其定义。
本文用FO-QSIG图把可信系统的NFR分解成特征和子特征树图, 从而对NFR进行逐层细分。与QSIG图中“属性”不同, 在FO-QSIG图中, 我们了FODA模型和QSIG图两者的优点, 对“特征”构建了严密的分类体系并对特征进行了定量分析。
3 FO-QSIG模型
我们基于严密的面向特征分类体系, 利用FO-QSIG图构建一个能完整表述并逐层细分NFR, 从而用定量分析方法来进行冲突消解的一种FO-QSIG权衡分析模型。
3.1 特征分类
为捕捉领域中应用系统的共性和变化性, 汲取FODA模型中的特征体系, 把特征分为必选特征、可选特征和多选一特征三类:①必选特征:指NFR必须秉含的特征, 是一种必选特征, 用单弧标识, 同一个父结点用单弧标识的子结点的值之和必小于或等于1。②多选一特征:指NFR有且只能有一个的特征, 是非此即彼的关系, 用双弧标识, 同一个父结点用双弧标识的子结点最后保留且只保留一个。③可选特征:指NFR可有可无的特征, 用箭尾上加圆圈标识。它和多选一特征不同, 一个系统中可选特征可保留多个, 也可一个不留。
之所以对三类特征进行标识, 是为了便于用户识别以及选择, 还要对特征进行权重设置和定量分析, 计算特征的FC值并进行选择, 从而构建NFR的定量分析权衡的FO-QSIG模型。
3.1 NFR的FO-QSIG图表述
FO-QSIG图能对NFR进行系统定量表述:①云图表示系统的NFR的分解过程中的根、父和子结点。②结点间的关系必遵循必选、多选一和可选三种关系中某一种, 用单弧、双弧和圆圈加以标识。③单线表示父结点分解为子结点 (向下) 或者子结点对父结点的贡献 (向上) , 权值∈ (0, 1) 。④虚线表示某子结点对其它NFR的负影响, 权值∈[-1, 0) 。⑤双线表示某子结点对其它NFR的正影响, 双线权值∈ (0, 1) 。
3.2 权重分配
FO-QSIG图中分配的权重是进行优先排序的一个结果, SIG图不能表达这种信息。易学习 (0.5) 和易操作 (0.5) 对于可用性同样重要, RSA加密 (0.9) 比Caesar加密 (0.2) 安全级别高很多, 因为Caesar加密只简单地换位, 数据包被截获后易破解;而RSA采用公钥算法极难破译。但是RSA计算时空代价昂贵, 对性能有很强负影响 (-0.8) ;而实现Caesar加密容易, 性能影响小 (-0.5) 。这种判断是完全主观的, 依赖于专家和开发者的有关知识, 权值可以由AHP或其它定量方法决定, 对此本文不重点讨论。
3.3 FC值计算
在FO-QSIG模型中, 把NFR某特征的 “特征贡献值 (Feature Contribution, FC) ”定义为受此特征影响 (正/负影响) 的父结点们对系统根结点的所有贡献值之和。规定所有叶子值为1并从叶子结点开始向上递归计算。实际上FC值反映的是该特征的正负影响, 并最后汇总到系统的根结点, 以便于比较权衡对整个系统贡献大小。
例如图3中, 如果选择RSA加密:FC (RSA) =0.3 (0.5+0.5-0.8) +0.40.9=0.42;要注意计算中加了两个0.5却没有加0.2, 是因为前者是必选关系, 后者是多选一特征。这意味着如果选择RSA加密, 系统有42%的贡献来自于此特征。同理可得FC (Caesar) =0.3 (0.5+0.5-0.5) +0.40.2=0.23。
3.4 NFR权衡分析
利用FC值可以对NFR进行冲突消解和权衡。在FO-QSIG图的三种特征中, 必选特征不用权衡, 另外两种特征是不稳定的, 要进行权衡消除其不确定性。
①首先对多选一特征 (图中用“双弧”表示的部分) 进行权衡, 只保留其中FC值最大的一个, 其余的特征去除。保留下的那一个特征用普通箭头表示。例如当Caesar加密和RSA加密二选一时, 比较FC值就知道, 核电系统42%的“贡献”来自RSA加密, Caesar加密只有23%, 所以应当选择前者。此“贡献”已经包含了负影响的分析, 是一个基于系统视角的一个综合考虑。二选一是多选一的一种简化形式, 实际上, 如果扩充“身份认证”或者“DEA加密”等其它方式就会构成多选一, 分析原理相同。
②再对可选特征 (图中用“圆圈”所表示部分) 进行权衡。保留它还是放弃它的决策依据是FC值是否大于0, 即它对系统是否有正的贡献。例如图3中, “美观”是可选项, 考虑保留它时带来的其正负影响, FC (美观) =0.1 (0.5+0.5) -0.50.4-0.50.3+0.40.3=-0.13, 表明选择“美观”的NFR最终还是会给系统带来负的影响, 所以放弃此项。
值得注意的是, 如果FC大于0而需要保留此特征时, 则首先换用普通箭头表示此特征, 另外针对现系统根结点出现权值和大于1的情况, 进行归一化处理使得权值和等于1。
权衡过程其实是一个消除不确定性过程。它从系统视角对NFR的特征的正/负影响进行权衡比较并最终确认和放弃某些特征, 从而对NFR进行精化的一个过程, 因此, 权衡后的结果只有确定特征 (包含必选特征和另外两种特征的筛选结果) 的FO-QSIG简化图, 此图不再包含双弧和圆圈, 它是一个特征明确图。
4 可信性证明
FO-QSIG图的一个不足之处就是其主观数值是由专家给出。为了缓减这方面的批评, AHP等方法都增加鲁棒性或灵敏度[14,16]分析。文献14中的检验模型中犯了一个错误 (详见文献[14]P.9) , 只简单地假设一个特征权重发生变化, 而假设另个一个特征权重不变, 这种分析方法尽管因分析方便大量采用, 但存在错误。本文将会对此错误加以修正, 如果一个特征权重增加, 另外一个 (或一组) 特征的权重 (或权重和) 就必减少相应量, 从而保证系统权值的和必为1, 这样建立两个权重都是动态变化的可信分析模型。
发现图3中安全性权重最大 (0.4) , 这是否左右了作出哪种加密方式的选择?如果此权重减少是否能改变决定, 即不选择RSA加密?
假设1:安全性权重稍微减少一点就会改变加密方式的决策结果。如果假设1成立, 则说明这个模型是不稳定的, 可信度不高, 是关于权重灵敏的或者十分依赖于权重设置的。
用Wp和Ws分别代表性能权重和安全性权重, 用α和β分别表示RSA加密和Caesar对安全性的正影响, 用η和ξ分别表示RSA加密和Caesar对性能的负影响 (见图5) 。
那么, 应当选择RSA加密的式子为:
应当选择Caesar加密的式子为:
权衡式 (1) 和式 (2) 式, 如果式 (1) 大于式 (2) , 则选择RSA接密, 即:
代入Wp=0.3, Ws=0.4, η=0.8, ξ=0.5, α=0.9, β=0.2等数值时, 式 (3) 成立, 则应当选择RSA加密, 这与前面的计算是一致的。
另外, 假设安全性的权值减少Δ, 而相应的性能的权值增加Δ (注意一方减少, 必须有另一方增加, 保持权重和为1) , 使得式 (1) 和式 (2) 相等。即:
化简即:
式 (5) 计算出来的Δ值是一个变化量的临界值如果安全性的权重减少量少于Δ, 则选择RSA;超过Δ值, 则选择Caesar;正好等于Δ值, 则达到均衡状态。由图5, 式 (5) 可用文字表述为:
用ζ表示安全权值要减少的百分比, 则
因此如果安全权重Ws改变地足够多, 达到了式 (7) 所计算出的值, 那么我们才能做出判断, 不再需要加密。经过计算, Δ=0.19, ζ=63.3%。即安全权值要减少约63%, 因为63%是一个大的改变, 除非用户或者专家的判断犯了一个巨大错误, 否则会选择RSA加密。所以得出结论:假设1不成立, FO-QSIG模型是可信的。
5 结论
我们对NFR及其冲突的权衡进行了研究。有三个主要的贡献:第一, 提出了面向特征定量软目标耦合图FO-QSIG图。第二, 考虑了NFR之间的优先排序和NFR策略的正负影响, 提出了NFR权衡的FO-QSIG模型, 通过结合FODA模型与QSIG模型的优点, 建立严格特征分类体系, 用FC值描述NFR特征的贡献值, 从而达到用定量方法来比较NFR的特征, 从而消解冲突和NFR不确定性。第三, 对模型的可信性进行了数理证明。本文为可信软件的非需求获取和精化提供了分析工具。
基于构件的软件生产模型 第5篇
当前社会的信息化过程对软件需求的增长非常迅速, 但目前软件的开发与生产能力却相对不足, 这不仅造成许多急需的软件迟迟不能被开发出来, 而且形成了软件脱节现象。自20世纪60年代人们认识到软件危机并提出软件工程以来, 已经对软件开发问题进行了不懈的研究。近年来人们认识到, 要真正解决软件危机, 实现软件的工业化生产是惟一可行的途径[1]。
从软件工程的角度来看, 基于构件的软件工程CBSE (Component-BasedSoftware Engineering) 正能满足当前软件生产的这种需求。构件是软件系统的一个有用片段, 它可以与其它片段组装在一起形成一个更大的片段, 或是整个的解决方案。构件是可复用的软件组成成分, 可被用来构造其它软件。基于构件的软件工程的基本思想是:将软件分解为各个独立的构件, 这些构件与外部仅通过预先定义的接口进行通信, 这样把应用程序解决方案的很多部分的实现外包出去, 使软件的创建主要是通过构件的选择、评价和组装过程来取得。进而, 软件项目可以从一个以代码编写和错误修正为中心的过程转变为一个更为受控的组装过程[2]。本文以基于构件的软件工程理论为基础, 引入了可复用的软件构件模型, 在将该模型应用于上海市教委机关办公自动化系统的开发中取得了成功。为实现软件工业化生产、软件再工程进行了有益的探索。
1 构件技术
1.1 构 件
对于构件的定义, 目前没有确切统一的定义, 笔者倾向于采用在文献[3]中对构件的描述:构件可以简单地定义为构造块, 不同的软件系统能够由它们组装而成。它们经常设计为插接兼容的, 并且能够以尽可能多的方式进行组合, 使开发者获得最小的代码复制并最大化重用。
由此可见, 一般构件均包括对构件接口和构件实现两方面的描述, 即构件::=<构件接口, 构件实现>[4]。构件强调接口和实现的分离。其实现具有不透明性, 仅仅通过接口见之于其它构件。作为一个可独立发布的软件实体, 构件应具有复用的价值, 这样构件才能成为第三方部署和使用的单元。构件具有独立于第三方应用系统的生命周期, 其自身的演化不应影响使用它的第三方应用系统。最后, 构件模型负责构件之间的交互方式以及全局的或体系结构上的限制[5]。
构件的概念和面向对象中的对象概念有很多相似之处。对象通过将数据和在其上执行的操作进行封装, 以达到一定程度上的复用, 但对象在复用的过程中存在很多问题, 具体体现在:
(1) 由于对象对数据和操作进行了封装, 要对其进行复用, 就必须了解该对象的实现细节。这给对象的复用造成了很大障碍。
(2) 对象之间的集成是通过消息通信。在这种集成方式中, 对象之间的关系分散并固定在对象的实现中, 对象的组装缺乏灵活性。
(3) 由于对象继承关系和行为的重叠, 使得对象的替代性较差。用一个新的对象替代原有对象时可能会影响所有与其有继承关系的对象[6,6]。
而构件可以认为是一种包装对象实现的简便方法, 并且可以使它们组装成一个更大的软件系统。总的来说, 构件和对象的区别主要在于以下三个方面:
(1) 构件担当一个部署单元的作用, 它是基于构件模型的, 这种模型定义了符合这种模型的构件所要遵循的规则。
(2) 构件提供了对一个或多个对象实现的包装。
(3) 构件是一个组装单元, 它用于从很多独立创建的功能部分设计和构建系统, 每一个部分都潜在地使用一种面向对象语言或某种其它技术创建。
1.2 系统构件模型
按照分布计算体系结构的思想, 任何一个应用软件的构架均可划分为三种构造逻辑:一是界面表示逻辑, 用于覆盖与用户直接关联的前端应用;二是事务处理逻辑, 体现软件的核心处理功能;三是数据管理逻辑, 用于解决用户事务的数据交换和后端服务问题。每一种逻辑部件都可用特定功能的物理构件来实现。在系统设计中, 根据软件系统的层次性和功能性, 可以把系统垂直分割为多个子系统, 把每个子系统看作是一个复合构件。这些复合构件负责特定的事务处理, 提供高层次和大粒度的重用支持。每个复合构件由多个具有不同功能和不同抽象水平的构件构成。最终将这些复合构件按照功能层次细化为粒度更小、功能正交的原子构件, 对原子构件进行单独开发。待开发完毕, 将原子构件按照功能组装成需要的复合构件, 进而完成系统的开发。既降低了构件的设计难度和实现代价, 又提高了构件的重用性能和管理水平。
在办公自动化系统中, 根据功能将整个系统划分为收文管理、发文管理、督办管理、公共信息管理、会务管理和日程管理等六个子系统。各个子系统再细分成粒度更小的复合构件。各个复合构件可能由复合构件或位于各层的不同功能的原子构件组装而成。基于上述想法, 可以对复合构件做下面的描述:
Complex Component:=<Specification, Interface Mapping, Component SA>
其中, Specification为构件规范, 是对外可见的部分, 由构件接口描述, 包括构件提供的接口和所需的接口两个方面。Interface mapping为接口映射, 表示复合构件的构件规范, 即接口定义向组成该复合构件的成员构件的接口定义的映射。Component SA即为复合构件的软件体系结构, 表示该复合构件中的成员构件及成员构件间的交互。根据上述描述及D. Garlan和M. Shaw对软件体系结构的定义, 将现有的构件抽象为构件模型, 描述为:
其中, Specification是构件的对外可见的部分, 由构件接口 (Interface) 描述, 包括构件提供的接口 (IP) 和需要的接口 (IR) 两个方面。Interface Mapping表示接口为成员构件的接口定义的映射, 这些成员构件组成该复合构件 (Complex Component) 。连接件 (Connector) 可以看作是一种特殊的构件, 它可以使接口不匹配的两个构件进行连接操作。Component SA表示该复合构件中的成员构件及成员构件间的交互。
2 系统实现
2.1 构件接口的实现
根据构件模型, 构件由构件规范和构件实现两部分组成。构件规范由构件接口描述, 而构件接口包括构件对外提供的接口和构件需要的外部接口。面向对象技术为构件的对外接口提供了很好的支持, 但构件所需的外部接口部分却隐藏在实现细节中, 难以根据接口处的信息定义构件的实现。为了解决构件所需外部接口对外不可见的问题, 采用依赖注入技术。依赖注入技术起源于轻量级构件容器提供的控制反转机制IoC (Inversion of Control) , 即由容器定位插件的具体实现。依赖注入技术用部署描述文件描述构件之间的依赖关系, 在运行时由容器按部署描述文件动态地将被调用构件注入到调用构件之中[7]。所以, 可以利用依赖注入技术在部署描述文件中对构件所需外部接口进行描述, 使其对外可见并与构件实现细节分离, 进一步降低构件之间的耦合性。
2.2 构件模型的应用
在描述构件模型的基础上, 采用JDev框架, 结合J2EE技术实现了一个办公自动化OA系统 (如前文所述) 。下面以其中的领导日程管理模块为例, 介绍构件模型在软件开发中的应用。
可以把整个领导日程管理模块视为一个复合构件。将该复合构件分为表示层、控制层、业务逻辑层和数据访问层。每一层均为其上一层提供服务并作为其下一层的客户端。表示层包括原子构件LeaderSchedulePage, 控制层包括原子构件LeaderScheduleAction, 业务层包括原子构件LeaderScheduleBean, 数据访问层包括原子构件LeaderScheduleDAO。于是可以用复合构件模型对领导日程管理模块进行描述。其中一部分描述如下:
由此可见, 每个原子构件都为其它原子构件提供接口, 而领导日程管理复合构件对外提供了管理领导日程的接口。
2.3 构件模型的实现
下面基于JDev框架给出上面描述的用户登录模块的实现。其中每一个原子构件均要实现其对外提供的接口并利用IoC模式在配置描述文件中描述其所需的外部接口。以原子构件LeaderScheduleDAO为例。LeaderScheduleDAO的接口如下:
其中:原子构件LeaderScheduleDao所需的外部接口, 即构件SqlMapProgramDao对外提供的接口, 可以在需要时利用IoC模式由容器插入到LeaderScheduleDao中。
在原子构件均已得到实现的条件下, 同样可以利用IoC模式对原子构件进行组装, 组装过程可以在配置描述文件中进行描述如下:
(1) 组装LeaderSchedulePage构件和LeaderScheduleAction构件:
这样, 复合构件LeaderSchedule就组装好了, 只要LeaderSchedule所需的外部接口得到提供, 复合构件LeaderSchedule的功能就可以利用JDev框架实现。
3 结 论
提出了基于可复用软构件的软件生产模型。针对OA系统的软件体系结构, 采用自顶向下的软件设计方法, 将整个软件系统的每个子系统看作是一个复合构件, 该复合构件又由其它的复合构件和原子构件组装而成。进而将软件系统逐步分解, 递归地对其进行描述、开发。采用自底向上的构件组装技术[8], 首先对所有的原子构件进行描述, 之后在软件体系结构的层次上对它们进行组装, 最后构成一个完整的软件系统。构件在接口处进行集成, 并在其内部实现细节不被了解的条件下得到复用, 大大提高了构件的复用程度。为降低软件系统开发的复杂性, 进行并行和分布式开发, 减少维护费用等奠定了技术上的基础。
参考文献
[1]唐勇敏.以构件为核心的软件工业化的生产方式[J].计算机应用, 2006, 26 (8) :225.
[2]ALAN W B.Large-scale, component-based development[M].USA:Prentice Hall PTR, 2000:59。
[3]Krzyszof Czameck, Ulrich Eisenecker.Generative programming:meth-ods, tools, and applications[M].Boston, USA:Addison Wesley, 2000:141。
[6]张世琨, 张文娟, 常欣, 等.基于软件体系结构的可复用构件制作和组装[J].软件学报, 2001, 12 (9) :1351-1359.
[5]宋旭东, 王毅, 刘晓冰, 等.基于构件技术的综合决策支持系统[J].计算机工程, 2008, 34 (14) :269.
[6]吕明琪, 薛锦云, 胡启敏.基于软件体系结构的可复用构件模型[J].计算机应用研究, 2008, 25 (1) :120.
[7]Johnson R, Hoeller J, Arendsen A.Spring:java/j2ee Appli-cationFramework[EB/OL]. (2004) .http://www.springframework.org/.
软件功能模型 第6篇
CMMI是一套融合多学科的、可扩充的产品集合, 其英文全称为Capability Maturity Model Integration。该模型包含了从软件需求提出、软件设计、开发、编码、测试、交付运行到软件退役的整个生存周期里各个过程的各项基本要素;是软件过程的有机汇集, 旨在为软件组织改进其过程和提高其对软件产品或服务的开发、采购以及维护的能力中提供指导。
CMMI起源于三个模型 (源模型) , 分别是:软件能力成熟度模型 (SW-CMM) 2.0版, C稿, 电子行业协会临时标准 (EIA/IS731) , 集成产品开发能力成熟度模型 (IPD-CMM) v0.98。CMMI模型涵盖了四个学科:软件工程 (SW) 、系统工程 (SW) 、集成过程和产品开发 (IPPD) 、供应商管理 (SS) , 为跨部门、学科的过程改进带来更多的交流, 从而利于组织进行全局的过程改进。同时, 统一模型的过程改进 (不仅仅是软件过程能力) 提供更大的适应性和扩充性, 减少冲突和冗余。CMMI模型分为五个等级, 分别是:初始级、受管理级、已定义级、定量管理级、持续优化级, 目前多数企业推行的都是已定义级, 即CMMI3级。
2 CMMI与ISO9000的兼容性
长期的实践表明, 很多软件企业实施CMMI体系之前都建立了ISO9000质量管理体系标准, 在推行CMMI过程中许多企业会担心CMMI与ISO9000之间有冲突。其实不然, ISO9000和CMMI是当前两个最流行的质量保证体系, 它们同是适用于软件和集成产品质量保证能力评价的两个方法, 只是两者考虑的角度不同。虽然ISO 9000和CMMI有差异, 但两者的互补性很强, 它们在管理思想和管理意图上是基本一致的, 在建立和改进质量管理体系的时候, ISO9000和CMMI可以同时作为依据和指南。
(1) 在管理思想上, ISO9000和CMMI同样强调管理体系和过程的管理, 并在过程管理中, 强调接口管理。ISO9000和CMMI同样强调沟通, 强调全员参与, 应赋予各部门、各岗位人员应有的职责和权限, 激励他们的创造性和积极性, 通过教育和培训, 增长他们的才干和能力, 发挥员工的革新和创新精神, 共享知识和经验, 为员工的成长和发展创造良好的条件。
(2) 在满足客户需求上, ISO9000和CMMI同样重视顾客的需求, 它们强调, 体系的结构总是相对保守和稳定的因素, 而市场和顾客的需求则是相对活跃和变化的因素。为了使体系能适应于市场和顾客的不断变化的需求, 必须要求一个组织不仅应当满足顾客当前的需求, 而且应当理解顾客未来的需求和争取超越顾客的期望。
(3) 在持续改进上, ISO9000和CMMI同样强调有效的持续改进, 特别是在正常情况下, 也要加强持续改进, 以保证体系的有效性和效率。ISO9000和CMMI同样允许对组织的过程、产品进行裁剪, 强调了适宜性和有效性。
(4) 在测量与分析上, ISO9000和CMMI同样明确地提出收集和分析数据是为了识别组织可以实施的改进。而且还指出资料分析可以提供顾客满意度、过程和产品的特性及其趋势, 以及供方提供产品/服务的信息。充分地体现信息和数据是组织进行管理的基础思想。
从上面的比较可以看出, ISO9000和CMMI的思想是一致的, 所以对做过ISO9000认证的企业来说, 其体系的融合就是理顺两者关系, 建立相互补充的唯一的质量体系描述。
3 CMMI对软件企业的主要作用
IT企业在软件能力评价、软件过程评估和过程改进三大方面实施CMMI, 可以对其软开发过程进行管理和改进, 监督、检查正处于制作过程中的软件状况, 增强开发与改进能力, 了解自己的强项和弱项, 找出自己在软件开发过程中急需解决的所有问题, 从而能按时、不超预算地开发出高质量的软件和系统集成项目, 帮助软件企业不断完善和改进软件开发过程, 确保软件质量, 提高软件开发效率。增强企业的国际竞争能力。具体表现在以下几个方面:
(1) 能保证软件开发的质量与进度, 能对“杂乱无章、无序管理”的项目开发过程进行规范。
(2) 有利于成本控制。因为质量有所保证, 浪费在减少、解决客户的抱怨方面的成本会降低很多。现在绝大多数情况是缺少规范制度, 只是求快。项目完成后, 要花很多时间修修补补, 费用很容易失控。
(3) 有助于提高软件开发者的职业素养。每一个具体参与其中的员工, 无论是项目经理, 还是工程师, 甚至一些高层管理人的做事方法逐渐变得标准化、规范化。
(4) 能够解决人员流动所带来的问题。公司通过过程改进, 建立了财富库以共享经验, 而不是单纯依靠某些人员。
(5) 有利于提升公司和员工绩效管理水平, 以持续改进效益。通过度量和分析开发过程和产品, 建立公司的效率指标。
4 软件企业如何实施CMMI
4.1 实施规划
(1) 确立实施原则。CMMI的实施过程, 切记不能以通过评估为唯一目的, 必须以注重实效和循序渐进为原则。一是要结合企业实际情况, 优化项目管理流程, 起到实在的效果。二是要按照先试点再推广的实施策略, 先选择基础好、有代表性的项目进行试点, 在试点成功的基础上进行全面推广。
(2) 开展差异分析。项目开始时需诊断企业当前软件开发过程, 了解企业产品及项目的开发过程和特点;找出与CMMI要求的差距, 建立当前过程的基线, 识别过程改善风险, 验证企业现有的管理制度与作业标准文件, 选择过程改善模式, 制定出符合企业实际的过程改进行动计划。
(3) 制定实施方案。完成差异分析后, 企业还需针对自身的情况制定具体的CMMI实施方案, 包括组织架构、推进步骤、任务分解、工作计划、提交文件、沟通机制等, 并对实施方案进行论证和评审, 确保实施方案合理、可行。
(4) 强调全员参与。CMMI实施的过程是一个企业全员参与的过程, 要提高整个企业员工和项目实施人员对CMMI的认识, 企业内部需采用相关手段进行一定的介绍和宣传, 比如有企业内部开设一些CMMI文化长廊、工作论坛等途径宣传普及CMMI知识, 还可以举办了一系列的CMMI座谈会, 让全企业的人员参与到CMMI的建设过程中来。
(5) 建立实施工作组。CMMI的实施需要有强有力的组织保障, 因此需要成立领导小组和专业的工作小组推进相关工作, 这是一个关键步骤。企业需成立CMMI推广实施领导小组、EPG (工程过程组) 和QAG (质量保障组) 。CMMI推广实施领导小组由企业高层组成, 组长是企业主要负责人。领导小组负责协调资源, 全面推进CMMI实施推广的各项工作。EPG由企业各部门和开发团队的主管组成, 主要负责企业标准过程体系的建立和维护、制定和跟踪实施计划、组织相关培训、审批过程改进建议等。QAG由企业项目管理及质量管理部门人员组成, 负责对试点项目组进行体系实施释疑、定期检查项目过程的执行情况、对不符合项提出改进建议、收集过程改进建议等。
4.2 过程定义
过程定义就是将组织对软件项目实施过程的要求及经验、建议等进行收集并文档化, 最终形成组织的标准过程体系文件。
一个企业的过程定义工作主要是对原有的标准过程体系进行优化调整。标准过程体系优化是指以CMMI所有过程域的目标及实践为指导, 融合相关制度对项目实施流程、管理要求、软件项目的任务流程、执行角色、工作产品 (含模板) 进行完整的定义, 可以采用信息化的形式展现, 便于项目实施团队学习和浏览。标准过程体系是项目过程实施的依据, 为确保其合理、可行, 在定义完成后, 需在企业内部进行广泛的意见征集并做好深入的评审。
4.3 试点实施
根据循序渐进的原则, 企业应在适当的时期选择在业务领域、技术先进性和生命周期模型方面具有代表性的三个项目进行试点。试点期间主要工作包括以下几个方面。
(1) 明确岗位和职责。明确项目经理为实施CMMI的第一责任人, 确保试点项目按照企业标准过程体系的要求实施;每个项目设立质量经理, 作为试点项目CMMI实施工作的接口人, 负责与EPG和QAG沟通协调, 并负责检查本项目实施过程与产品的符合情况。
(2) 加强实施培训。在试点前, 需让参与三个项目实施的所有人员都参加CMMI的实施培训, 最好让EPG负责培训的实施。培训内容包括CMMI基础知识、标准过程体系、每个项目的经验分享、目前实施情况分析及问题解决等。
(3) 定期开展项目体检。根据体系相关要求, QAG制定了项目体检表, 每周对三个试点项目进行过程和产品检查, 发现项目实施过程与体系的不符合项, 并跟踪改进情况。
(4) 定期召开CMMI推进例会。由企业主要负责人主持, EPG、QAG和试点项目组成员参加, 分别汇报本阶段工作情况及下阶段计划, 提出实施过程中遇到的问题, 明确解决方案。
(5) 搭建实践经验分享平台。由QAG收集各项目的实践经验, 定期召集各项目QAG进行讨论, 分享最佳实践。
4.4 认证评估
在正式评估之前, 企业需对自己CMMI实施的过程进行一次预评估, 这是企业发现实施过程中存在的不足和感受正式评估过程的宝贵机会, 针对在预评估中发现的弱项和改进项, 及时采取积极的改进措施, 包括制定改进计划、加强体系培训、进行QAG工作辅导、加强项目组之间经验交流等, 为正式评估做好准备。
正式评估是依据CMMI框架进行, 由SEI授权的主任评估师为评估小组的组长, 对公司试点实施的相关情况进行审查, 并对参与实施的相关人员进行访谈。时间为7天左右。若评估通过, 主任评估师将会现场提交评估结果, 提出企业后续工作方向的意见建议等。
4.5 持续改进
CMMI的实施过程是一项长期细致的工作, EPG组织的工作模式和个人技能的好坏, 对公司日后软件过程实质性的改进影响很大。因此, EPG应长期存在, 并积极了解本行业标准和模型的最新资讯。评估活动结束后, 企业应严格按照CMMI的文件体系和标准流程执行, 企业也应该制定更高级别的改进行动计划。
5 在软件企业实施CMMI的主要体会
通过对几十家软件企业的咨询实践, 深深感到, 软件企业要想有效推行软件能力成熟度模型, 必须做到以下几点:
5.1 领导重视
领导的重视是实施CMMI的关键。实施CMMI是一个破旧立新的过程, 会改变现有的做法和原有的习惯, 这必然会遇到一定的阻力。只有企业的最高领导对CMMI知识及其价值有明确认识, 有实施CMMI的决心和信心, 才能排除阻力, 协调各方面资源, 制定有力的措施保障实施工作的正常推进。而各部门、开发团队主管、项目经理只有在清楚认识到实施CMMI是企业的意志、并不是个别部门的想法的情况下才会密切配合CMMI实施的相关工作, 这样试点及实施的各项工作措施才能得以顺利落实。
5.2 系统培训
培训工作很重要, 从实施前的宣传、全员的基本知识普及, 到对试点项目组成员的体系强化、模拟演练、QAG工作辅导、合作公司的经验交流等, 企业一定要将培训作为重要的工作来抓。通过对不同对象进行不同内容、不同形式的培训, 使企业和合作公司的每一个人都接受一次以上的培训, 从而使标准过程体系在企业得到广泛理解和使用, 提高项目实施人员对CMMI的认识, 形成了企业统一的质量文化。
5.3 紧密合作
各团队的密切协作不可缺失, CMMI实施不是一个项目管理部门的事情, 它需要全企业各部门的密切协作。其中, 推广实施领导小组对整体实施工作负责, EPG负责企业体系的建设、实施、过程改进, QAG负责过程实施辅导和过程及产品检查, 各项目组按相关工作要求落实各项工作。只有各团队各司其职、密切配合, 才能保障CMMI实施工作的顺利推进。
当然, 实施CMMI没有一套固定的模式和方法, 不同的软件组织应该根据自身的实际情况和具体要求, 采用不同的形式来实现CMMI的目标。CMMI实施和过程改进是一个持续而长期的过程。软件企业的项目实施过程也将一直正处于不断改进过程之中, 同时要不断完善CMMI的过程体系, 使软件过程符合更高的标准, 切实提高软件企业项目实施和项目管理的水平。
摘要：近年来, 我国资讯科技发展迅速, 特别是软件产业在政府的大力推动下快速发展, 随着软件企业数量的不断增多, 行业竞争越来越激烈, 为了提高软件开发效率、规范软件开发管理, 许多企业纷纷导入CMMI (Capability Maturity Model Integration) 作为软件质量流程评估标准来提升产品质量。本文结合软件研发组织贯彻CMMI的实际, 就如何抓住CMMI的精髓, 有效推行CMMI的软件项目过程管理, 切实提高软件开发能力和项目管理水平进行了阐述。
软件功能模型 第7篇
一、GIS软件的概念
GIS软件全称地理信息系统 (Geographic Information System) , 它是一款能提供存储、显示、分析地理数据功能的软件, 主要包括数据管理、数据操作[1]。
从应用角度来说, GIS软件主要由硬件、数据、软件、人员和方法五部分组成, 其中影响GIS软件正常运转的因素是软件, 不同的软件系统对应不同的GIS软件。
二、软件工程常见模型
影响人们生活的软件工程模型主要有六种:瀑布模型、螺旋模型、增量模型、快速原型模型、迭代模型、V模型。
瀑布模型是一个软件开发构架, 其核心思想是按工序将问题化简, 便于软件在运转时分工协作, 是最早的软件工程模型, 应用范围广;而螺旋模型是一种演化软件开发过程模型, 它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控, 较瀑布模型的应用范围更窄;增量模型是一款融合了瀑布模型的基本成分和原型实现的迭代特征的模型, 它能评估软件的新特征和功能;快速原型模型能很快开发出软件系统的原型, 展现软件特定功能;而其他两种软件工程应用范围较小, 所以在GIS软件的过程模型选择中不予考虑。
三、软件工程下GIS软件的过程模型选择方法
3.1 增加开发过程的敏捷性
在软件工程开发中, 要发挥软件自身特点, 增加软件运行的灵活性。软件工程开发出来的目的就是为了更好地方便学习生活, 所以在研究过程中, 要注意“以人为本”, 从自身的实际需要出发。如学校举办职业技能大赛时, 要求确定一处食堂选址, 在参赛的时候, 我们就要结合软件工程和GIS技术, 用软件工程强大的计算功能, 计算出食堂占地面积, 用GIS软件确定在学校范围内最佳食堂位置, 在这个选址过程中, 就要结合自己学校的实际情况, 如果软件工程和GIS软件确定的最佳区域是教学楼区域, 就要更换食堂选址, 选择比较宽阔的其他位置, 在新确定的位置区域在用两种软件相结合计算出最佳位置。
增加开发过程的敏捷性, 大学生要发挥主观能动性, 根据学习实际需要调整软件工程的具体程序, 在研发过程中, 要发挥想象, 致力于创新型软件工程的开发, 用新颖的软件产品去影响GIS软件系统, 与生活有机结合。
3.2 传统软件模型在GIS软件中的应用
传统软件模型在GIS软件中的应用, 主要是指瀑布模型、螺旋模型和快速原型模型。因为瀑布模型要求GIS软件性能稳定、功能完整, 相对其他两种传统模型来说, 它对GIS软件的要求较高, 所以它在GIS软件过程模型选择中的应用范围较小, 瀑布模型的工作量巨大, 在运行过程中要求“零失误”, 一旦出现偏差, 就会使得软件工程整个系统瘫痪。 螺旋模型是最近几年才被开发出来的新模型, 适用于高风险的GIS软件过程模型。螺旋模型的开发成本较高, 对研究团队也有一定的要求。快速原型模型与螺旋模型正好相反, 它适用于低风险的GIS软件, 能很好地帮助开发团队节约资金, 能够改进GIS软件中不合理的系统, 能够实时掌控整个软件工程模式和GIS技术。传统软件工程模式都能较好的与GIS软件融合, 形成一种新的GIS技术过程模型, 只有根据自己实际的需要, 选择合适的过程模型, 才能更好地利用各项软件技术, 方便生活。
3.3 利用GIS过程软件建立对象模型
GIS软件收集空间数据的前提下, 利用软件工程, 对数据进行统一记录, 在软件结构中建立对象模型。在这种模型中, 要不断填充数据资料, 使GIS软件能具有各项清晰的服务功能, 如定位、计算等。如在学校教学楼发生了火灾, 需要立即救援, 如何安排最佳的人员撤离路线、配备合理的运输和灭火设施?在这个过程中, 需要我们马上建立软件工程中的对象模型, 计算教学楼火灾最严重的区域, 建立救灾模型, 用GIS软件进行定位, 安排最恰当的施救人员和救火方案, 确保老师和学生生命财产安全。从这个实例中我们可以看出, 利用GIS软件建立对象模型的重要性。
对象模型非常适合GIS软件过程系统的开发, 加强对软件运行的控制, 增加项目开发结构, 加大对象模型在GIS软件中身亡应用程度。
结束语:随着我国经济不断发展, 软件工程开发与GIS软件过程模型相互融合交错, 慢慢建立起一种新的软件体系, 基于这种现状, 在学习生活中加强GIS软件过程模型的选择也越来越重要。不断完善软件工程与GIS软件的各项开发, 还需要大学生和软件工作者共同努力。
摘要：当代大学生要合理利用软件工程结合GIS软件, 创造出多层次的过程模型, 方便自己学习生活。本文通过介绍GIS软件的基本概念和软件工程的常见模型, 进而结合各类模型特点探讨了在软件工程的环境下的GIS软件具体选择方法。
关键词：软件工程,GIS软件,过程模型,方法
参考文献
[1]周艳萍, 张淑娟.云计算技术的GIS软件工程模式研究[J].电脑知识与技术, 2014, 01:207-208+218.
软件开发项目风险模型分析 第8篇
1.1 软件项目风险定义
软件开发项目的风险为软件项目在整个生命周期内,由于受各种环境的不确定性因素的影响,实际发生的成本、进度、质量等与预期结果的不利偏差。软件项目的风险具有以下的几个特点:第一,对于项目各组成部分之间的复杂关系,任何个人都不可能彻底地了解。第二,项目各个组成部分之间不是简单的线性关系。第三,项目时刻处于动态变化之中,平衡状态即使出现也只能是短暂的。第四,项目管理者不仅要面对技术和经济问题,还要面临一些非常复杂、非线性和不确定性极高的问题。
1.2 软件项目风险管理
软件项目风险管理是对有关软件项目、软件开发过程和软件产品损失的可能性,它涉及操作过程、组织过程和合同等相关参数主要包括资源制约、外界因素、供应商关系或合同制约的管理。
Boehom认为软件风险管理指的是“试图以一种可行的原则和实践,规范化地控制影响项目成功的风险,其目的是辨识、描述和消除风险因素,以免它们威胁软件的成功运作。”Hall认为软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程,该实践围绕目标设定、项目计划、执行、度量、改进和发现新信息六大科目展开。SEI在软件工程体系中提出软件风险管理是有关管理威胁开发软件产品计划风险的概念、方法和技术,包括风险辨识、分析、监控、减轻和计划。具体分成三个知识单元:风险分析、风险管理计划和风险监控。通过以上软件风险项目管理的不同观点,可以归纳出软件风险管理是一个为了避免和减小软件项目失败的风险,对软件风险进行识别、分析、计划、监控的管理过程。
2 经典软件项目风险管理模型
2.1 Boehm体系
Boehm于1991年详细描述了他的思想体系,其中把风险管理活动分成两大阶段,每一阶段含有三个步骤:第一阶段,风险估计阶段。此阶段可分为:风险辨识、风险分析,风险排序三个步骤。第二,风险控制阶段。此阶段可分为:编制风险管理计划,风险解决,风险监督三个步骤。
每一步骤都备有不少的相关实现技术,例如,风险辨识中给出了10大软件风险因素清单。同时还推荐了各个因素的相关处理意见及方法。从该清单出发,经理和工程师们能够进一步细化风险因素,并加以评估和化解。
2.2 Charette体系
1989年Charette设计了称为风险分析和管理的体系,两大阶段分别为分析阶段和管理阶段,每个阶段都内含三个过程,风险分析阶段分为:辨识、估计、评价;风险管理阶段分为:计划、控制、监督。每个阶段内的过程活动并不能完全分离,有相互重叠甚至交错反复的现象。Charette同时为各个过程提供了相应的战略思路、方法模型和技术手段,特别在风险的辨识和估计过程中,其中大多数是运筹学、系统科学中的模型应用。
2.3 SEI体系
SEI在软件风险管理方面作了大量的工作,1999年前后分别以技术报告和手册等形式公布了基于分类的风险辨识(TBQ)、连续风险管理(CRM)、软件风险评估(SRE)、软件采购风险管理成熟度模型(RM-CMM)和团队风险管理(TRM)。完整思想是想以TRM为框架,贯穿CRM思想,依托SRE过程,以TBQ等为基本手段,配合软件能力成熟度模型(SW-CMM)和(SA-CMM)完成软件的风险管理。
其中CRM思想如上图1所示,SRE过程分为合同签订、风险辨识和分析(RI&A)、中间报告、缓和战略计划(MSP)和最终报告5个阶段。SA-CMM与SW-CMM类似,前者是对获取软件产品或服务一方组织管理能力的描述,后者是对开发组织过程能力的描述。RM-CMM配合SA-CMM模型的5个成熟度等级和关键过程域(KPA),也提出了风险管理关键过程域(RM-KPA)的概念。RM-KPA的结构包括目标、为达成目标的活动和支持活动顺利开展的制度化特征。其中目标有3个:1)鼓励项目全体人员参与到所遇风险的辨识和缓和中来;2)在所有的项目职责中明确项目团队软件采购过程的风险辨识、分析和缓和;3)项目评审已识别出风险的状态。
2.4 Hall体系
Hall女士受SEI连续过程改进和PDCA质量管理方法的启发,提出了“6-学科模型”(Six-Discipline,6-D),如图2。图中E代表预想(Envision),这是把思想转换为目标和目的的学科,用于研究软件产品的远期规划;P代表计划(Plan),是要为软件目标分配资源的学科;W代表工作(Work),指生产产品计划的执行,工作的伴生产品是状态和不确定性;M代表度量(Measurement),指比较期望值和实际值的学科,两个值的差异用于调整项目计划;I代表改进(Improve)是指从过去的经验中学习的学科,它通过分析基准和项目度量结果,找出改进的方向;D表示发现(Discover),是指要预知未来的学科,是通过对工作中不确定性的评价和困惑的思考,思考机会和风险的均衡,预先指导计划和规划的改变。
3 软件项目风险管理模型分析
以上4种典型的软件项目风险管理体系各有特色,较早出现的两套体系(Boehm和Charette体系)偏重于理论结构的完善,不妨称为理论体系,后两套体系则偏重于实践应用,不妨称为实践体系。总体来说,理论体系结构完整,内容完善,并附带有与结构和内容相配套的不少方法和技术。体系构建者旁征博引,着重说明了为什么要这样做的道理,阐明了如何从其它学科,如运筹学、决策理论等中借用思想、方法和工具。但研究范围局限于软件项目的核心风险管理,研究对象主要是开发技术风险,很少论及实现体系思想所需要的保障措施,基本上只站在开发商一方讨论风险管理问题,操作性也显得不足,整体上看思想性大于技术性,对实施过程中人所发挥的作用估计不足,从一定程度上说有理想化的成份。
Boehm先生一直关注软件项目的风险管理问题,曾提出了围绕风险管理开展软件开发的方法,即螺旋模型,还从经济学角度论证了软件开发问题,并引入了构造型成本模型(COCOMO)。他最突出的贡献之一是建立了软件风险管理研究领域,提出了头10大风险清单的风险辨识思想,尽管有缺乏动态性的不足,但确实对后续研究产生了很大的影响,只是他的体系在计算风险当量时没有考虑效用因素。
Charette先生的体系从结构上看与Boehm体系只在用词不同,本质上区别不大(两者同在1989年独立提出软件风险管理体系)。Charette的体系中认识到了风险的投机性,也从步骤上强调了对组合风险的评价。但就如何获取单一风险估计值和组合风险分析效果,还缺乏可行的手段和措施,在风险的效用问题上只考虑了目标效用,而没有考虑到不同项目参与人的效用。另外,与Boehm一样,也没有考虑点概率值在实践应用中的不足。
两套实践体系最明显的特点是考虑到了体系的可操作性,体系中的理性思考以指导实践步骤为主要目的,基本上摒弃了复杂的数学运算,强调与软件开发过程的紧密结合,强调把划分好的任务落实到人的重要性,还绘制出了关键的风险管理实用表格,注意到了风险管理数据的形成和利用问题。但为保证复杂体系的一致实施,需要对实施人员进行专业化培训。SEI体系明确提出了软件采购方在项目风险管理中的地位和作用,注重发挥和要求采购方参与到风险管理中来。该体系基于风险分类结构辨识风险,组织了194个揭示风险的问题,设计了各项实施措施的场景,有些活动甚至详细规定到了需要在多少分钟内完成。为了简化风险管理的实施成本和实施难度,该体系将风险发生的可能性定义为非常可能、可能和不可能3种,把风险后果定义为灾难性的、严重的、次要的和可以忽略的4级,两项因素组合成的风险当量简化为高、中和低3档结果,不过这种做法在降低管理成本的同时也降低了管理精度。SEI体系的管理步骤多于技术、方法和工具,没有涉及到组合风险的处理,可以看出其主体思想是以简单的学术背景要求、方便的日常事务应用,再加上严格的管理规定达成IT项目风险管理效果。所以尽管技术要求不高,但实施成本不低,因此更适合于大型公司或开发大型项目时采用。但不足的是对如何取得预想方案中风险和机会的均衡重视不够,基本思路是改进项目管理,带动风险管理,管理范围仍以核心软件风险管理为主。也可以认为上述4套体系归属两个风险管理层次,一个是研究如何辨识、处理和消除风险的学科,一个是试图辨识并采取规避措施的行为或过程。照此理解前两套体系属学科层,后两套体系属过程层。以上4套体系总体都偏重解决开发活动内部的技术风险,在风险控制手段上也往往着眼于降低风险发生的可能性,而对如何规避风险后果措施不多。
参考文献
[1]黄梯云.管理信息系统[M].2版.北京:高等教育出版社,1999.
[2]薛华成.管理信息系统[M].3版.北京:清华大学出版社,1999.
[3]郑人杰.软件工程(高级)[M].北京:清华大学出版社,1999.
面向对象软件测试模型研究 第9篇
1 面向对象软件开发过程
面向对象的开发模型突破了传统的瀑布模型,将开发分为面向对象分析(OOA)、面向对象设计(OOD)和面向对象编程(OOP)3个阶段[1]。面向对象的软件完整开发过程可用下图表示:
面向对象分析(OOA)全面地将问题空间中实现的功能进行现实抽象化,将问题空间中的实例抽象为对象,用对象的结构反映问题空间的复杂关系,用属性和服务表示实例的特殊性和行为[1]。OOA的结果是为后面阶段类的选定和实现、类层次结构的组织和实现提供平台。分析模型标识了所要研究的真实世界系统的相关对象及其相互关系,是与计算机无关的。
面向对象设计(OOD)建立类结构或进一步构造类库,实现分析结果对问题空间的抽象。OOD确定类和类结构不仅能够满足当前需求分析的要求,更主要的是通过重新组合或加以适当的补充,方便实现功能的重用和扩增。设计阶段是对分析模型进一步细化,构造实现中所涉及的新对象。
面向对象编程(OOP)是软件的计算机实现,是指用一种面向对象的程序设计语言实现设计模型,编写出源程序。面向对象的程序设计的主要活动集中在建立对象和对象之间的联系(或通信)上,从而完成所需功能。由于现实世界可以抽象为对象和对象联系的集合,所以面向对象的程序设计方法是一种更接近现实的、更自然的程序设计方法。用面向对象语言所编写的源代码至少从原理上讲是与设计模型紧密联系且彼此一致的[4]。
2 面向对象软件测试模型
面向对象程序的结构不再是传统的功能模块结构,因此面向过程软件测试和软件度量方法不适合面向对象软件测试和软件度量,已经不能用功能细化的观点来检测面向对象分析和设计的结果。对面向对象软件的测试策略和方法需要作出相应的变革或更新。
在许多情况下,初始的软件需求有明确的定义,但是整个开发过程却不宜单纯运用线性模型。同时,可能迫切需要为用户迅速提供一套功能有限的软件产品,然后在后续版本中再细化和扩展功能,在这种条件下,需要选用一种演进式的软件过程模型,如图2的内层所示。针对这种开发模型,结合传统的测试步骤的划分,提出一种在整个软件开发过程中不断测试的测试模型,使开发阶段的测试与编码完成后的单元测试、集成测试、系统测试成为一个整体,测试模型如图2所示。
此模型不仅是一种演进式的软件过程与测试模型,还强调测试伴随着整个软件开发过程,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。
同时这种新的软件测试模型伴随着软件开发的一系列演进版本,如图2所示,每个框架活动代表演进中的一个片断,随着演进过程的开始而顺时针旋转,软件团队执行螺旋上的一圈表示的活动,进行开发与相应的测试,并在每次选代中逐步完善,开发出不同的软件版本,且在每次演进过程中,各个阶段的测试重点各不相同。
OOA的测试重点在于完整性和冗余性,包括对认定对象的测试、对认定结构的测试、对认定主题的测试、对定义的属性和实例关联的测试、对定义的服务和消息关联的测试。
对OOD的测试,针对功能的实现和重用以及对OOA结果的拓展,从如下3方面考虑:对认定的类的测试;对构造的类层次结构的测试;对类库的支持的测试[2]。
OOP测试的重点集中在类功能的实现和相应的面向对象程序风格即数据成员的封装性测试和类的功能性测试上。其测试内容在面向对象单元测试和面向对象集成测试中体现。
单元测试针对面向对象软件的基本组成单元类,重点测试类的属性、方法、事件、状态和相应状态等内容。它是进行面向对象集成测试的基础。
集成测试是在单元测试的基础上将所有的模块按照软件设计要求组装成为子系统或者系统,进行测试,它测试的对象是模块间的接口;关注的重点是各个模块接口和整体体系结构。
系统测试时在系统被部署到了实际的运行环境之后,根据软件的需求和设计说明对其进行功能、性能、安全性等测试;它测试的对象是整个系统以及与系统交互的硬件与软件平台[3]。验证软件系统的正确性和性能指标是否满足需求规格说明和开发任务书的要求,包括软件功能测试、强度测试、性能测试、安全测试、恢复测试和可用性测试等。其测试的重点是性能测试,目的是测试软件是否能满足用户的需求,并得到实际测试数据,分析比较后可以更好的改善软件的实际性能,使其更能满足用户的需求。
3 结论
该测试模型对面向对象软件工程管理具有相当的借鉴价值,不足之处在于它将一体的软件测试生硬地划分为一些不同的阶段,这就意味着对每个阶段的变更相对比较困难,但是该模型将对面向对象软件测试具有一定的理论导向作用,对模型中涉及的测试技术还有待于进一步的研究和探索,仍有很多困难需要克服,如怎样在软件中内置测试,其模式是什么,怎样才能提高可测试性,如何组织测试等。
参考文献
[1]陈文宇.面向对象软件的测试[J].电子科技大学学报[J].2002(6).
[2]袁海根.面向对象软件的测试模型[J].软件导刊,2007(5).
[3]张朔.软件测试方法及在综合网管系统测试中的应用与研究(D).
[4]魏武华.浅议面向对象的软件开发过程[J].陕西省行政学院、陕西省经济管理干部学院学报,2001(3).
