GB T 18905.4-2002 软件工程 产品评价 第4部分;需方用的过程.pdf

《GB T 18905.4-2002 软件工程 产品评价 第4部分;需方用的过程.pdf》由会员分享，可在线阅读，更多相关《GB T 18905.4-2002 软件工程 产品评价 第4部分;需方用的过程.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.080 L77 人民共和国国标GB/T 18905. 4-2002/ISO/IEC 14598-4: 1999 软件工程产品评价第4部分:需方用的过程Software engineering Product evaluation Part 4: Process for acquirers (lSO/IEC 14598-4: 1999 , Information technology Software product evaluation Part 4: Process for acquirers , IDT) 2002-12-04发布2003-05-01实施中华人民共和国国家质量

2、监督检验检瘦总局发布421 GB/T 18905_ 4-2002/ISO/IEC 14598-4,1999 前吉同GB/T 18905-20026个月平均时间2功能性适用性与强制性需求总数对照的在软件需求规格说明中满足强制性需求的数量100% 且可维护性可变性为确定的类似改变而需要改动的模1 块数高在最差的操作条件下CPU加载超过规4效率资源利用80% 定的操作周期的百分比5易用性可理解性特定用户学会如何使用软件生成指定:型及其他产品评价方洼的基础上评价辙件产品选择产品和供方，提出告同执行嘘收回试，接受或拒绝产品执行任何附加的评估圄C.l现货产晶的评价/获取过程的例子443 GB/T 1890

3、5. 4-2002/ISO/IEC 14598-4: 1999 | 发布信息要求图C.2定制软件或对现有软件进行修改的评价/获取过程的例子444 GB/T 18905. 4-2002/ISO/IEC 14598-4,1999 附录D(资料性附录)评价方法D. 1 对用户和产晶技术文档(包括联机文挡)的评审产品文档可以在对功能性和易用性需求以及可移植性和可维护性等方面进行评价时提供所有必要的信息。通过借阅文档或购买文档集能得到对相关软件产品文档的访问，并不需要实际购买该软件产品。虽然阅读软件产品文档可能不如参加课程或进行培训更有效，但可以证明是最经济的方法，尤其是对于评价者具有相关专业知识的情况

4、。D.2 基于供方课程和培训的评价可以通过供方或第二方为众多的软件产品提供产品课程。在没有软件产品课程的情况下，可能会安排有经验的用户或软件产品的开发者开展专门的培训。提供产品课程或培训的好处在于能使评价者把精力集中在特定范围，并且在较短时间内获得有关产品功能初易用性方面的特定信息。通过阅读软件产品的文档也可能得到相同的信息，但要花费更多的时间。课程或培训的附加成本需要根据获取信息的效率和课程资料的普遍性两方面来衡量。D.3 对软件工程过程的评估对软件工程过程的评估是通过检查过程的中间产品，如z产品质量计划、需求规格说明、体系结构描述、详细设计描述、代码清单、验证和确认记录、代码检查和测试记录

5、等来决定软件产品的质量。要达到这一目标，必须定义什么是构成个可接受的软件工程过程的文档编制基线，该过程将为最终得到的软件产品提供充足的质量保证p针对目标完整性级别剪裁GB!T8566的需求可以定义一个可接受的基线，以便规定必要的开发和相关的支持活动。该基线包括确定下列内容:a) 必需的过程;bl 必需的过程输出文档(注:GB/T18905.5也在附录中列出了能用于评价软件工程过程的产品文件集hc) 对过程和过程输出文档的需求。评估可以与ISO/IEC15504-8中定义的供方过程能力级别的确定联系起来。例如，对有中级到高级完整性需求的产品可能要求表D.1中定义的软件过程文档编制基线表D.1 软

6、件过程文档编制基线GB/T 8566-2001过程输出Gll/T 8566二2001要求(条目计划编制软件质量/开发计划和支持过程7. 1. 2 系统需求分析系统需求规格说明5. 3. 2 系统需求验证验证记录6.4.2.3 系统结构设计系统设计描述5. 3._3 系统设计验证验证记录6.4.2.4 软件需求分析软件需求规格说明5. 3. 4 软件需求验证验证记录6.4.2.3 445 GB/T 18905. 4-2002/1S0/1EC 14598-4: 1999 表D.1C续)GB/T 8566 -2001过程输出GB/T 8566-2001要求(条目)软件结构设计软件结构描述5. 3.

7、5 软件详细设计软件设计描述5.3.6 软件设讨验证验证记录6. 4. 2. 4 软件编码代码5. 3. 7 代码验证验证记录6.4.2.5 软件单元测试测试记录5. 3. 7 软件集成测试记录5.3.8,6.4.2.6 软件确认测试记录5.3.9,6.5 系统集成测试记录5.3.10 系统确认测试记录5. 3. 11.6. 5 配置管理计划、状态报告、发布、变更请求6. 2 培训培训记录7.4 对于有高完整性需求的系统，可以通过部门标准，如:IEC 880 , Draft IEC 1508 , DOA-167A和MOD-55等来提出附加过程和产品需求。供方的质量/开发计划及相关的方法学规程能

8、用于评估供方对目标萎线的符合情况。那么，一致性级别可以通过标识主要缺陷和评估其对软件产品质量的潜在影响来确定。附加的评价或变通的工作能说明缺陷的影响。可以认为，有多种软件工程过程对特殊组织或不同种类的软件产品是有效的。评价过程宜具有灵活性，以便适应多种多样合理的软件工程过程和方法。建议软件工程评审按附录E所示的例子分阶段进行。当认为软件的完整性级别不要求对软件工程过程进行全面评价时，评审可以在第I阶段或第H阶段之后停止。D.4 对供方操作历史的评审对供方操作历史的评审能够提供-种非常有效的表明软件产品质量的方法。这可以通过评审软件产品的销售图表和使用该产品的行业及应用程序的详细资料来实现。这种

9、评审也说明了软件版本的修订历史、维护修订的方法、解决顾客反映的缺陷的方法，以及己知缺陷的详细内容。执行评审最便利的方法是与供方的工程人员、销售人员和顾客支持人员进行沟通，以及检查所有的支持记录。D. 4. 1 掘作历史的帽求a) 销售图表宜至少有六个月的时间;即用在评价中的销售数字应只包括在评价前六个月以上的销售额。这J准则基于的事实是g软件产品从交付、安装、委托代理直至服务到位可能需要花费多达六个月的时间;b) 软件产品宜至少经历一个主要的修订，并且宜有该修订中可实行的操作历史数锯。这是基于这样一个假设:软件产品的质量依赖于它所经历的改进的数量;c) 软件产品的用户有向供方反馈缺陷报告的手段

10、，而且也存在缺陷发生和处理缺陷的证据eD. 4. 2 操作历史的评审对产品操作历史的评审宜确定:a) 软件是否是通过修改另一产品而产生的，能否使用该产品的操作历史。在对该软件产品的改动次数和改动程度方面这可能是附带的;b) 软件产品运行的单元年数。由下列步骤算出:446 GB/T 18905. 4-2002/1S0/1EC 14598-4 ,1999 1) 计算年销售额=(初始销售额【第一年的总销售额十从现在起六个月累计的最终总额假设一个单元投入运行前通常要延迟6个月)X (软件产品投放市场的年数)/2;2) 计算运行单元年数=(年销售额X责任周期软件投人运行的时间百分比X单元实际运行的百分比

11、这与固件有关，因为固件中的若干主机硬件单元可留作备件J), c) 操作经验是否提供了与应用所要求的功能有关的证据。例如，它是否被其他顾客用在类似的应用中?d) 操作经验是否提供了已经充分运用了软件产品的功能的证据，例如，它是否已被用在广泛的应用和行业中?时软件的每个修订版和软件产品的每个特定选项的运行单元年数号。每种修订之间的区别，改动的程度以及每次改动是否是孤立的:g) 是否存在文挡化的证据支持操作历史数据:h) 如何控制和跟踪软件产品的修订和相关硬件的修订;) 是否有可能定制软件产品的某个特定修订版，并暗示定制不是当前的修订版;j) 接受和处理顾客提出的缺陷报告的供方过程zk) 顾客是否保

12、持最新的缺陷报告;1) 软件的任何明显缺陷及其影响。D.5 对顾客操作历史的评审对那些正在使用或曾在某个应用中使用该软件产品的实际顾客的操作历史的评审，能使评价者在实际的工作条件下不带偏见地回答一些具体的问题。根据顾客的应用和所要求的应用之间的相似程度，从整体质量或特定功能中得到的质量保证可能与从原型或者甚至从扩展的实验用途中所得到的保证一样有用。进行评审最方便的办法是通过在工作现场与顾客进行沟通，甚至可能通过观看演示或查阅支持记录的方式。评价者进行对顾客操作历史的评审宜za) 建立与要求的应用的相似的等级;b) 试图观察工作中的软件产品或取得其他支持的证据;c) 询问顾客有关供方提供的支持形

13、式和支持质量的问题gd) 确定免错操作的总数。D.6 对供方的能力、支持和质量体系的评审对供方的支持能力级别和维护软件的能力的评价宜说明za) 财政的稳定性、经验和能力;b) 产品开发环境的支持，包括集成工具、所用的操作系统、对其它部件/库对象的维护和使用gd 产品与其他产品或产品组的接口，包括接口标准;d) 涉及第三方的可能性pe) 充分的提供产品支持的资源承诺$0 充分的证明持续支籍的顾客基础;g) 充分的用于纠正错误及环境支持的维护服务zu 充足的对已经安装的平台的引用si) 形式化的和充分的发行、修订控制规程和实践证据;j) 形式化的囚归测试和设计改动的正式评价多kl 文档化和形成惯例

14、的问题报告和解决规程;) 质量体系己就位;447 GB/T 18905. 4-2002/ISO/IEC 14598-4: 1999 m)用于软件和硬件的标准;n) 未来的开发计划;即与当前市场定位相关的策略己就位事。)产品质量保证书。D.7 原型和其他评价方法D. 7. 1 原型原型是一种评价力法，用于分析或微调需求，以确定使用软件产品的技术可行性，或排除与特定的功能性或易用性需求及与实现有关的未知风险或技术风险。原型可能或可能不利用全部软件产品功能，或者说明整个应用的需求。应注意:原型常常要求供方提供对特别指明的设备、人员和文档的访问。对这些和其他因素，比如特定环境条件或服务所隐含的成本和进

15、度问题，宜在确定软件产品原型的可行性时考虑。除了通常的评价需求之外，原型宜za) 使用足以表明需求已被评估的例子，并实际提供对关键操作参数的重新构造和模拟;b) 尽量整理文档以便能被第二方重复使用;c) 利用与提议的应用相关的历史数据。D.7.2 其他评价方法GB/T 18905. 5在附录中列出了与评价等级和软件质量特性相连的评价技术的清单。评价等级应该与评价的完整性级别相对应。其它的评价方法包括:a) 对软件结构设计的分析(可维护性); b) 软件的故障树分析(安全性、可靠性); c) 基于软件产品测试的随机统计应用(可靠性hd) 检测语法和语义的正确性的代码动态分析(可靠性he) 软件设

16、计的危险分析(安全性、可靠性h。对软件需求规格说明的评审(功能性hg) 代码检查(功能性); h) 软件的黑盒测试(功能性): 0 基准测试(效率); j) 需求的可追踪性分析可维护性hk) 在部件间接口的模拟故障(坚固性)。对具有高完整性级别的复杂软件，故障树分析或软件设计的危险分析能用来为进行评价而孤立关键的软件模块。这可以排除对不影响应用完整性的软件进行严格评价的必要。448 G/T 18905. 4-2002/ISO/IEC 14598-4: 1999 附录E资料性附录)分阶段评价过程的例子下列描述的是分阶段评价的例子，展示了在各个阶段对三个目标领域所要求的相关工作。E. l 阶段1计

17、划IJ-需求阶段E. 1. 1 产晶的文档编制、进程和培训本领域的某些评审最初几乎都是为了证实和确定软件产品的基本功能。这种初始的评审可由其他方来进行。根据完整性级别，宜考虑将这种非正式或初步的评价编成文档。E. 1.2 软件工程过程在此开始对软件产品的软件工程过程进行评价是非常有利的，通常通过评审软件产品的质量/开发计划来进行。这一评价工作将指明该软件工程过程是否有可能产生满足文档集所要求的一般特性的文档租规程，而文档集是针对相关完整性级别的。适当的时候，对其他过程评价的评审可以认为是对这项工作的补充。在此宜考虑一般特性和非特定需求，同时也要注意下列几点:a) 将供方的文挡与规定的文档集进行

18、准确匹配是不可能或不必要的;b) 在评估软件工程过程时，注意在整个过程中该过程的前后关系、导致该过程的前面几步的重要性，以及该过程的输入质量。E. 1. 3 燥作历史对供方和适当顾客的操作历史的初始评审能够较早地提供是否需要进一步评价的指示。例如，操作历史较短和/或适当的顾客较少可能导致要考虑原型、对外部评价的评审，或提高软件工程过程评价的精确度等。E.2 阶段2:设计-我取阶段E. 2. 1 产晶的文档编制、进程和培训在本阶段，需要对软件产品所需的功能进行更全面的评审。如果产品的进程或文档都不能证实所需的功能，那么，宜执行比适当的顾客操作历史更严格的评审。E. 2. 2 软件工程过程在本阶段

19、评估质量计划的实际实施情况。这将涉及对实际产生的中间产品的评审，以确保它们与那些已确定的产品的一般特性保持一致。如果本阶段与投标过程重合，时间要素可能限制只对关键文档检查的评审。标书宜总是包含一个允许在合同裁定之前对在软件产品质量计划中寻|用的任何文档进行检测的阶段e由于软件工程过程评审的成本较高，一般不考虑为较低完整性级别的软件产品进行软件工程过程的评审，除非觉得它的操作历史不足以提供产品的可靠性保证。E. 2. 3 操作历史本阶段宜集中在对现有软件产品的特殊版本和所需功能进行更广泛的操作历史的评审。如果对产品进程、文档及对适当的顾客的操作历史评价的评审不能为产品的可靠性和功能性提供足够的信

20、任度，宜考虑使用原型。449 GB/T 18905. 4-2002/ISO/IEC 14598-4: 1999 E. 3 阶段3:全面评价阶段E. 3. 1 产晶的文档编制、进程和培训如果前面的阶段没有完成产品的功能性评价，那么在本阶段宜通过评审产品的文档或进程的参与者来完成产品的功能性评价。E. 3. 2 软件工程过程本阶段需要在把每个过程/产品的特定需求与供方的特定需求相比较的地方，对软件工程过程进行全面的评价。要考虑的补充点包括:a) 宜说明每-项需求，以确定供方的软件工程过程是否遵守需求的目标。通过与供方的软件工程人员进行交流来做到这一点往往最容易g因此，在投标过程期间来确定它是不可行

21、的或不够有效的pb) 也可要求供方成员展示其产品有充分质量保证的证据。这可能为没有专门被基线软件过程覆盖的领域提供了前景。它也有助于促成基线软件过程中的特定领域与部分不能对评价者直接展示证据的过程之间建立联系;。一些需求有主观因素，需要评价者的解释。因此，可能存在各种各样的满足需求目标的方法。 评审宜建立软件产品的修订历史，同时也宜确定每个修订版之间的改动程度。这包括对报告的缺陷的检查e宜考虑下列情况z1 ) 所有已知缺陷的状态:2) 对修复缺陷的所有改动所傲的评审、评价和测试的等级，3) 当前设计修订的稳定性;。从最近发布之日起所经过的时间;5) 改动的次数和这些改动的规模或幅度p如存在缺陷

22、或不可以进行详细评审的地方，宜考虑如原型或黑盒测试这样的附加评价方法。E. 3. 3 操你历史如果在前面的阶段没有实施对操作历史的评价，那么，本阶段宜完成此项工作。450 GB/T 18905. 4-2002/1SO/IEC 14598-4: 1999 参考文献标准IJ ISO/IEC指南2:1991关于标准化和相关活动的通用术语和定义2J GB/T 5271. 1-2000信息技术词汇第1部分s基本术语3J GB/T 52 71. 20-1994信息技术词汇20部分z系统开发4J GB!T 6583-1994 质量管理和质量保证词汇5J GB/T 19001一1994质量体系6J GB/T

23、17544-1998 信息技术7J GB/T 18234-2000 信息技术设计、开友、生产、安装和服务的质量保证模式软件包质量要求和测试CASE 工具的评价和选择指南8J Radio Technical Commission for Aeronautics (RTCAl DO -178B!ED -12B，航空系统和没备认证中的软件考虑9J Ministry of Defence (UK) (MODl , Interim Defence Standard, 00-55 (Parts 1 , 2) IIssue 1. The Procurement of Safety Critical Soft

24、ware in Defence Equipment. 1OJ IEC 880-1986 核电站安全系统中的计算机软件l1J IEEE Std 1062-1993 软件获取的建议实践其他参考文献12J Tremaine, DR. and de Grosbo阻，JFP.Guideline for the Quali日cation1) Predeveloped Soft ware. 907-C-H-6999002一0201,Ontario Hydro/ AECL, April 22咱199313JFerguson,R. and DeRiso，如1E.Software Acquisition: A C

25、omparison of DoD and Commercial Practices. CSU/SEI-94-SR-9 Software Engineering Institute, October. 1994. 14J Baker; ER. , Cooper, L. .Corson , BA. and Stevens , AE. Software Acquisition Management Maturity Model (SAM). Program Manager. July-August 1994 , pp. 43-49. 15J Scott , JA. , Preckshot, GG.

26、and Gallagher, JM. Using Commercial ff-the Shelf (COTS) Software in High Consequence Safety Systems (Draft Preprintl. Lawrence Livermore Na tional Laboratory, November , 1995. 16J Cochrane, GaiI. Use of COTS/NDl in Safety-Critical Systems. (based on original Repon pre pared for the Federal Aviation

27、Authority) , TRW , 1996. 口7JBrown, A W. and Wallnau , KC. Eng,neer,ng of Component-Based Systems. Procecdings Scc 。ndIEEE International Conference on Engineering 01 Complex Computcr Systems. October, 1996. 18J Bevan , N. and Azuma , M. Quality in Use:Incorporating human facto, into the software cn gineering lifecycle. Proceedings 01 the Third Internat,onal Symposium on Software Engineer ing Standards. May, 1997. 19J Voas , J. and Miller, K. Interface Robustness for COT8-Based Systems. IEE Symposium on COTS and Safety-Crtlcal Systems. Savoy Place, London,January, 1997. 451