软件验证与确认(Verification and Validation)简述
核电厂DCS软件验证与确认标准体系分析
核电厂DCS软件验证与确认标准体系分析郑骈垚;钟柏;马象睿【摘要】Through introducing the activities of software V&V and dividing the life cycle of software for nuclear power plant,the object of digital control system software V&V for the nuclear power plant is dearly defined;that is the verification activities are to judge whether the system meets the design requirements or not;and the validation activities are to judge whether the system design is correct or bining with the supervision and management practice of the software V&V activities of the safety grade digital instrument control systems in NPP,the regulations and the standard system used for digital control system V&V activities in USA,Europe and China are summarized.Aiming at the problem of inadequate regulations and standard system in our country,the differences from such topics in USA and Europe are compared,and it is clarified that our regulations and standard system has deficiencies in threeaspects,i.e.,lag in upgrade,the standard route is not unified,and lack of systematic for transformation of the standards.From the long-term goal to see that we should consummate the V&V regulations and standard system,from the regulatory requirements to the execution of standards,to gradually refine a hierarchy of requirements;while from the short-term view,the requirements of V&V activities should be carried out from stage division of software development,formation and implementation of various developing plans,the independence of V&V activities,anddocuments and records.%通过对软件V&V活动的介绍以及核电厂软件生命周期的划分,明确了核电厂数字化仪控系统软件V&V的目的,即通过验证活动判断系统是否满足设计需求,通过确认活动判断系统设计是否正确.结合核电厂安全级数字化仪控系统软件V&V活动的监督管理实践,总结了美国、欧洲和我国数字化仪控系统软件V&V活动所采用的法规和标准体系.针对我国软件V&V法规和标准体系不健全的问题,通过对比我国与欧洲、美国法规标准体系的差别,明确了我国软件V&V 法规和标准体系存在标准体系升版相对滞后、标准路线不统一及欠缺标准转化的系统性等三方面的不足.从长远目标看,我国应完善V&V法规标准体系,使之有层次地逐步细化从法规要求到执行标准要求;从短期要求看,可从软件开发的阶段划分、各项开发计划的形成和实施、V&V活动的独立性和文件记录等方面落实V&V活动要求.【期刊名称】《自动化仪表》【年(卷),期】2017(038)003【总页数】5页(P13-17)【关键词】核电厂;数字化仪控系统;DCS;软件V&V;标准体系【作者】郑骈垚;钟柏;马象睿【作者单位】中国核电工程有限公司采购部,北京100840;中国核电工程有限公司采购部,北京100840;环境保护部华北核与辐射安全监督站,北京100029;环境保护部华北核与辐射安全监督站,北京100029【正文语种】中文【中图分类】TH86;TP273随着计算机技术的不断发展和广泛应用，核电厂仪控系统逐渐从采用模拟技术转向数字技术。
(六)确认与验证
(六)确认与验证在软件开发的过程中，确认与验证是非常重要的环节。
通过确认与验证，我们可以确信软件的效果符合需求，而且符合用户的期望。
本文将讨论软件开发过程中的确认与验证，以及如何执行这些任务。
确认与验证的定义在软件开发中，确认与验证可以定义为对软件产品进行测试的过程。
通常，确认与验证有两个主要目的：测试软件的功能、确定软件是否符合规格。
通过这些测试，我们可以确定软件是否符合预期。
测试的类型确认与验证可分为两种测试类型：黑盒测试黑盒测试是针对软件的外部表现进行测试的。
测试员不关心软件内部是如何工作的，而是关心它是否符合规格要求。
在黑盒测试中，测试软件的输入和输出，比较它们是否符合预期的规格要求。
白盒测试白盒测试是针对软件的内部进行测试的。
测试时需要知道软件的内部工作，以便确定如何测试软件内部的各个功能。
在白盒测试中，测试员需要考虑软件的内部代码和数据结构。
以下是一些常见的白盒测试方法：•代码覆盖率测试：测试覆盖软件的所有代码路径；•程序流量分析：通过分析软件中不同的程序流程路径来确定软件的执行效率；•程序耗时测试：测试软件的执行时间，以便确定软件是否符合性能要求。
确认和验证的执行步骤确认和验证中，我们可以采用如下步骤来进行测试：1.规格分析规格分析是确认和验证中的第一步。
在这一步中，我们需要检查软件规格书，确保弄清了软件的需求。
通常，这个步骤需要涉及到客户、开发人员以及测试人员的合作。
开发人员应该了解客户的需求，并准确地将其转换为软件规格书。
测试人员需要检查规格书是否满足其测试需求。
一旦规格书被制成，测试人员就可以使用它来制定测试计划。
2.测试计划测试计划是确认和验证的第二步。
在这一步中，我们需要考虑软件的测试目标以及测试资源的使用。
测试人员需要确定需要进行的测试的种类以及测试的优先级。
测试计划通常包括以下内容：•测试的目标和目标；•测试方法和工具；•测试资源的分配；•测试进度的计划。
3.测试用例测试用例是确认和验证的第三步。
软件工程中的软件测试与验证
软件工程中的软件测试与验证在软件工程中，软件测试与验证是确保软件质量和功能完整性的重要环节。
通过对软件系统的测试和验证，可以发现和解决潜在的错误或问题，从而提高软件的可靠性和稳定性。
本文将探讨软件测试与验证的基本概念、分类、方法和重要性。
一、软件测试与验证的基本概念软件测试是指通过运行软件系统并与预期结果进行比较来评估系统的特性和性能。
验证是指确认软件系统是否满足了所期望的需求和规范。
二、软件测试与验证的分类1. 功能测试：验证软件的功能是否按照要求正确运行。
例如，对于一个计算器应用程序，验证加减乘除功能是否正常。
2. 性能测试：测试软件在不同负载和压力下的性能表现。
例如，测试一个电商网站在同时访问人数增加时的响应时间和吞吐量。
3. 安全测试：测试软件系统的安全性，发现和修复潜在的安全漏洞和隐患。
例如，测试一个银行应用程序的防火墙和身份验证系统。
4. 兼容性测试：测试软件在不同操作系统、浏览器或设备上的兼容性。
例如，测试一个网站在不同浏览器中的显示效果是否一致。
5. 冒烟测试：测试软件系统的基本功能，以确定软件是否可以进行更详细的测试。
例如，对于一个新开发的游戏软件，验证游戏的基本操作是否可用。
三、软件测试与验证的方法1. 黑盒测试：测试者只关注软件的输入和输出，不了解内部实现细节。
通过输入不同的数据和条件，验证软件是否按照规范输出正确的结果。
2. 白盒测试：测试者了解软件的内部结构和逻辑，并基于此设计测试用例。
通过检查程序的数据结构、路径和边界条件，发现并修复潜在的错误。
3. 灰盒测试：结合黑盒测试和白盒测试的特点，既关注软件的功能，又关注其内部实现。
通过分析代码和使用不同的数据进行测试，评估软件的可用性和稳定性。
四、软件测试与验证的重要性1. 提高软件质量：通过测试和验证，可以发现和解决软件中的错误和问题，确保软件的质量和正确性，减少用户的使用问题和投诉。
2. 减少开发成本：在软件开发的早期阶段，发现和修复错误的成本相对较低。
第六章 建模与仿真的校核、验证与确认
第六章建模与仿真的校核、验证与确认由于仿真技术具有的优越性——可操纵性、可重复性、灵活性、安全性、经济性，且又不受环境条件和空域场地的限制，其应用越来越广泛，同时它本身的准确性和置信度也愈来愈引起人们的广泛重视。
建模与仿真的校核、验证与确认（Verification，Validation and Accreditation，VV A）技术正是在这种背景下被提出的。
VV A技术的应用能提高和保证仿真置信度，降低由于仿真系统在实际应用中的模型不准确和仿真置信度水平低所引起的风险。
本章介绍VV A的基本概念和方法以及对仿真结果的统计分析方法。
6.1 VV A技术建模与仿真的正确性和置信度是仿真的生命线，没有一定置信度的仿真和仿真系统，其结果是毫无意义的，甚至可能造成错误的决策。
建模与仿真的校核、验证和确认技术的应用是保证和提高仿真置信度的有效途径。
校核的目的和任务是证实模型从一种形式转换成另一种形式的过程具有足够的精确度；验证是从预期应用的角度来确定模型表达实际系统的准确程度，其目的和任务是根据建模和仿真的目的和目标，考察模型在其作用域内是否准确地代表了实际系统；确认是一项相信并接受某一模型的权威性决定，它表明决策部门已确认该模型适用于某一特定的目的。
国外早在20世纪60年代开始对模型的有效性问题进行研究，并在概念和方法性研究方面取得了许多重要成果。
以美国为例：例如美国国防部成功地对“爱国者”导弹半实物仿真模型进行了确认，还有BGS（Battle Group Simulation）、LDWSS（Laser Designator/Weapon System Simulation）等武器仿真系统都经过了确认和验证；美国宇航局（NASA）对TCV（Terminal Configured Vehicle）仿真系统进行了专门的确认；美国国防部对“星球大战”计划及其后续的“战区导弹防御计划”中的仿真项目都拟订并实施了相应的VV A计划。
验证（Verification）与确认（Validation）的区别
验证（Verification）与确认（Validation）的区别今天在⼀位朋友的提醒下，发现ITIL V3术语表⾥有⼀处错误：Verification和Validation都翻译成了“验证”，这是⼀个很⼤疏忽和错误。
其实这两个词是⾮常近似的，到底怎么翻译好呢？Validation是否应该翻译为"检验"⽽不是“验证”？在征求了很多⼈，尤其是⼀些做过测试的朋友的意见，CMMI中也是专门有验证(Verification)与确认(Validation)两个PA来描述这两⽅⾯的要求的。
验证(Verification)，是通过提供客观证据证明规定的要求是否得到满⾜,也就是说,输⼊与输出⽐较。
确认(Validation)，是在验证好的基础上,对预期的使⽤和应⽤要求是否得到满⾜,也就是说,在确认时,应考虑使⽤和应⽤的条件范围要远远⼤于输⼊时确定的范围.⼀般是由客户或代表客户的⼈执⾏。
找了个有意思的解释，以下为转贴：Verification and ValidationVerification也就是说要做正确、⽽Validation是看经过Verification是否是我们想要的。
Verificaiton是我们可以预见的，在测试以前就知道我们期望⼀个什么结果。
例如我要找GF，⾸先对⽅要是个⼥的，if（Person.gender!=female) return false；做IC的，读卡器芯⽚，必须能够读相应的数码卡；做sales的，评价Performance的标准每个⽉的销售额就是Verification的标准，Verification是否可以说是理性思维⼤于感性。
1是1，2是2。
⽽Validation⾸先前提是经过Verification，重要的是做的是否是customer需要的。
拿刚才三个例⼦，我相信任何⼀个⼈找对象，不会只需要⼀个异性。
验证Validation，还要看是否是⾃⼰喜欢的; IC做出来了，是否市场真的需要。
软件开发过程_验证和确认过程
验证和确认过程Verification & Validation Process【目录】1概述 (3)1.1 编写目的 (3)1.2 适用范围 (3)1.3 术语和缩写 (3)1.4 参考资料 (3)2输入 (3)3输出 (4)4角色和职责 (4)5验证和确认概述 (5)6过程定义 (5)6.1 入口条件 (5)6.2 出口条件 (5)6.3 过程流程图 (5)6.4 过程活动描述 (5)6.4.1建立验证和确认计划 (5)6.4.2建立验证和确认环境 (6)6.4.3建立详细的验证和确认计划 (7)6.4.4执行同行评审 (7)6.4.5进行验证和确认 (7)6.4.6分析验证和确认的结果 (8)7验证和确认的工作产品 (9)8过程度量 (14)9过程剪裁准则 (14)1概述1.1 编写目的定义和建立公司对项目验证和确认的规范和责任。
定义及规范软件产品的验证和确认过程，以保证工作产品在软件开发的整个生命周期中能满足其规定的要求，同时证明，产品或产品构件当被置于其预定环境中时，适合于其预定用途。
通过该规范来提高公司的验证和确认的能力。
1.2 适用范围本过程适用于公司内所有软件开发项目的验证和确认活动。
1.3 术语和缩写1.4 参考资料2输入3输出（具体输出制品请参阅7.验证和确认的工作产品的验证和确认记录）4角色和职责5验证和确认概述验证的目的是为了确保产品符合其指定的需求，包括指定用户需求、产品需求、工作产品组件的需求。
从需求开始验证直到最终产品完成的验证，该过程贯穿于整个软件生产过程中，是渐进式的过程；确认的目的是为了确保产品和产品组件在预期的使用环境中能够满足产品的使用需求。
确认和验证经常同时执行，确认一般会包括使用者。
“验证”过程方面与“确认”过程方面看起来类似，但是它们处理的问题不同。
“确认”是要证明所提供的（或将要提供的）产品适合其预计的用途，而“验证”则是要查明工作产品是否恰当地反映了规定的要求。
第12章 软件验证和确认
6
验证与确认的活动模型（补充）
2013-04-02 7
12.1 验证和确认
验证和确认是两个相互独立但却相辅相成的活 动，二者很容易混淆 验证（Verification）
"Are we building the product right“（我们是否在正确地制造产 品？） 软件验证试图证明在软件生存周期的各个阶段，软件产品或 中间产品是否能够满足客户需求，包括逻辑协调性、完备性 和正确性 。
23
4. 5. 6.
7.
8.
软件测试文档-测试用例(补充)
Test Case: 一组数据输入和所期望结果
“输入”是对被测软件接收外界数据的描述 “期望结果”是对于相应输入软件应该出现的输出 结果的描述
测试用例还应明确指出使用具体测试案例产 生的测试程序的任何限制。 测试用例可以被组织成一个测试系列，即为 实现某个特定的测试目的而设计的一组测试 用例。
16
12.2.1 程序审查
软件审查涉及文档和程序的审查
程序审查即对所实现的程序源代码审查，其审 查的目标是评审和检出程序中的错误和缺陷，
可能是逻辑上的错误 也可能是错误的条件设置或是与机构和项目定义的 标准不相符。
17
12.2.1 程序审查
程序审查的过程是一个正式的过程，由至少4 个人组成的一个小组来实行，包括程序作者、 代码阅读者、测试者仲裁者。 审查小组应系统地分析代码并指出可能的缺陷 审查过程如图12.2所示。
2013-04-02 10
验证与确认的技术
分类方法：
静态技术和动态技术 软件审查和软件测试
软件验证与确认(Verification and Validation)简述
软件验证与确认（Verification and Validation）简述张艾森1，2（上海工业自动化仪表研究院1，国家能源核电站仪表研发（实验）中心2，上海，200233）摘要：计算机设备和信息处理技术正迅速进入仪表和过程控制工程之中，由于其方便的操作和其他诸多优点，更多用户乐于去使用它们。
在起初用于基本功能控制后，在更多的安全关键控制中，计算机设备和信息处理技术得到了更多的应用，此时，软件的质量被人们日益重视起来，其好坏如何评判，其质量如何保证是人们最关心的问题。
软件的验证与确认技术正是达到质量保证的重要环节。
关键词：软件验证与确认（V&V）；独立性；管理；文档1软件V&V的准则软件的验证与确认是数字化仪控系统的关键技术之一，其质量的评估难以量化的给出。
从相关标准条款中，可以得到软件V&V的准则如下：⑴计划先于行动，没有计划和大纲无法开展工作。
⑵对所有软件开发步骤的验证和确认方案，没有完全可信的东西，没有“免检产品”。
⑶所有结果和过程都应详细的记录并保存，确保可追溯性。
2评估独立性的要求通常对于软件质量的评估其出发点来自于对软件开发过程的评估，辅以对软件成品的一系列测试。
从验证和确认的角度来说，对过程的逐一评估是软件的验证阶段，而对软件成品的测试归结为软件的确认。
在IEC60880中提及，额外的验证活动由第三方来进行。
第三方的介入对软件质量而言是提升了信心。
在IEEE1012中，V&V团队的独立形式和独立程度被分成了四个等级。
IEC60880针对核电站A类软件，其独立性要求应参照IEEE1012中最高级别来制定。
但有一点要指出，60880中对于独立评审的要求规定似乎没有IEEE1012中给的具体。
在标准中没有给出经济独立性的要求，也没有明确给出第三方是指不同组织间的，还是同一公司的不同部门。
在其中只是指出，V&V团队的独立程度应在国家相关规定条款中给出，而国内还没有哪一个具体标准给出了关于团队独立性的明确指导，多数还是遵循IEEE1012中的相关规定。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件验证与确认（Verification and Validation）简述张艾森1，2（上海工业自动化仪表研究院1，国家能源核电站仪表研发（实验）中心2，上海，200233）摘要：计算机设备和信息处理技术正迅速进入仪表和过程控制工程之中，由于其方便的操作和其他诸多优点，更多用户乐于去使用它们。
在起初用于基本功能控制后，在更多的安全关键控制中，计算机设备和信息处理技术得到了更多的应用，此时，软件的质量被人们日益重视起来，其好坏如何评判，其质量如何保证是人们最关心的问题。
软件的验证与确认技术正是达到质量保证的重要环节。
关键词：软件验证与确认（V&V）；独立性；管理；文档1软件V&V的准则软件的验证与确认是数字化仪控系统的关键技术之一，其质量的评估难以量化的给出。
从相关标准条款中，可以得到软件V&V的准则如下：⑴计划先于行动，没有计划和大纲无法开展工作。
⑵对所有软件开发步骤的验证和确认方案，没有完全可信的东西，没有“免检产品”。
⑶所有结果和过程都应详细的记录并保存，确保可追溯性。
2评估独立性的要求通常对于软件质量的评估其出发点来自于对软件开发过程的评估，辅以对软件成品的一系列测试。
从验证和确认的角度来说，对过程的逐一评估是软件的验证阶段，而对软件成品的测试归结为软件的确认。
在IEC60880中提及，额外的验证活动由第三方来进行。
第三方的介入对软件质量而言是提升了信心。
在IEEE1012中，V&V团队的独立形式和独立程度被分成了四个等级。
IEC60880针对核电站A类软件，其独立性要求应参照IEEE1012中最高级别来制定。
但有一点要指出，60880中对于独立评审的要求规定似乎没有IEEE1012中给的具体。
在标准中没有给出经济独立性的要求，也没有明确给出第三方是指不同组织间的，还是同一公司的不同部门。
在其中只是指出，V&V团队的独立程度应在国家相关规定条款中给出，而国内还没有哪一个具体标准给出了关于团队独立性的明确指导，多数还是遵循IEEE1012中的相关规定。
3软件评估的初始管理从对IEC60880整篇标准的理解中不难看出，软件质量的获得最重要的并不是某几位专家的评估，而是整个开发过程的有序管理。
有序管理的几个重要目标应该是：⑴足够的人员配置以及人员对应职责的明确无误。
这点可以在第8章中看出，其明确要求了构成人员的能力以及其目标职责的明晰。
⑵文档的正确管理。
在IEC60880中，无论在软件开发的任何阶段，都会在某一结点明确的要求相应的输出文档。
这些文档的存在最大程度的保证了整个过程的可追溯性。
针对文档的管理及要求在第7.4条中给出。
对于一个V&V团队来说，首先应该建立的是质量保证计划，该质量保证计划中明确给出的是：⑴人员配置结构及人员职责分配。
⑵操作流程的规定包括方法的描述。
工具的配置情况，采用标准的情况，管理。
⑶文档管理计划，包括文档管理，文档统一格式。
⑷通讯记录归档管理。
⑸安全性管理，涉及保密性的管理条约。
4文档管理的要求在整个软件评估过程中，对于文档的评估和审查占据了非常重要的角色。
因此，建立完整的，可追溯的文档系统是非常必要的。
文档建立的几个关键注意点在于：⑴要求的记录内容详尽（项目，目标，准则，使用设备，方法，流程，结果等）；⑵为了方便查阅而做的标记；⑶完成时间和参与人员可查（人员包括完成人员和审核人员）；⑷管理制度的建立。
后续文档，例如软件验证计划，软件确认计划等，都需要遵照质量保证计划中的相关内容建立。
5软件设计验证软件的设计验证应在软件的初始设计介入。
从设计概念上来说：保证软件安全的关键在于尽可能减少软件的功能，并且简化必要的功能。
软件验证工作首先要解决的问题是依照从系统要求中得到的软件要求规范对照设计大纲。
软件的正确与否在软件设计之初就已经决定了。
其目标内容为：⑴概念设计大纲中是否将目标功能全部包含在内。
⑵设计大纲中的功能设计要求是否相关要求。
这些要求的内容应在是响应时间，动作时间等一系列系统要求中给出的参数。
这些参数是否正确也应参照相关核电站安全设计要求。
⑶详细设计大纲中提及的设计方法是否可行。
最安全的软件应该是最简单的软件，最新的编成方法与技术应当在核电站软件设计结束中慎重使用。
在完成对概念设计和详细设计两个部分的审核后，开发团队应提交相应的代码。
对于V&V团队来说，代码的测试应该以功能块为基础进行。
代码测试的主要方法是静态测试和动态测试。
从IEC60880的角度来说，它推荐使用自动化测试工具（测试工具及平台的质量管理在后面给出）。
静态测试的关注目标主要是测试覆盖率，其面向的是软件设计的规范化和一些可能出现的系统错误。
好的自动化测试工具可以帮助测试人员更好的完成任务。
动态测试的目标应当是检验软件模块是否正确执行了目标功能，并且没有执行非预期的功能。
测试目标功能相对来说简单。
由其规定输入得到期望输出进行比较即可。
难点应该在于检验非预期功能。
个人认为顺序执行功能是不太会带来问题的，因为软件不存在随机误差，所有的故障皆为系统误差。
非预期功能的出现主要来自于非预期模块间的相互调用或者来自数据超出设计范围后的非预期影响。
因此，在模块测试间进行排列组合进行测试是动态测试的一个重要部分。
在验证阶段所找出的故障需要进行一项额外的分析。
就是为什么该错误在软件早期设计没有被发现。
如果分析结果显示该错误在早期可以被发现并改正，则这一错误所涉及的相关设计都需要被重新评估，避免整个软件系统出现致命的设计错误。
验证测试主要方法在IEC60880中有明确的要求，其主要方法如下：⑴测试过程的监督管理。
该方法的好处是不需要额外的准备工作，并且不需要具备详细的相关知识基础。
缺点就是，无法得到详细的流程框图，无法对整个软件进行详细的评，只有比较粗矿的理论基础，不够深入。
⑵根据需求进行静态分析。
好处是可以给出可靠性框图或类似流程图之类的框图，而不必详细阅读代码。
可以作为对其他程序分析的辅助方法。
这类方法在对自动代码生成的软件时会显得有效，可以在早期发现设计上的缺陷。
⑶根据正确性进行静态分析，好处和缺点同上。
⑷编程检验。
好处是可以得到软件正确性的详细评估报告。
缺点是无法辨别软件中的循环的相关内容。
⑸编程分析。
主要可以分为人工的方法和自动化工具的方法。
标准中强烈推荐自动化工具的方法，尽可能多的使用。
⑹利用测试用例分析软件性能。
⑺崩溃测试。
⑻连接外部硬件进行的测试。
⑼静态测试用例和动态路径来测试软件方法流程。
⑽开关附加软件或外部设备后是否能获得正确的操作。
⑾路径测试：每种状态至少运行一次。
每种输出至少执行一次。
每种循环在最高最低值时分别至少执行一次。
每条路径至少执行一次。
⑿数据移动测试。
每种内存排列至少执行一次。
每个内存地址标记至少执行一次。
每个输入到输出的绘制至少执行一次。
⒀时间测试。
测试所有时间约束条件。
所有可能的中断顺序组合测试。
所有重要中断顺序的组合测试。
⒁其他测试。
例如：每一个模块接口测试至少一次。
每个模块至少调用一次。
高负荷情况下运行。
数学运算的精度测试。
输入数据边界值检查等。
在软件验证测试中，IEC60880明确了需要进行基于统计方法的测试。
对应不同的PFD 要求明确了试验次数。
应用统计测试的方法有如下几个特点需要注意：⑴试验是基于系统要求而独立设计的测试用例。
⑵测试的顺序和数量不影响每一次单独运行的程序结果。
⑶出现的每一个失效都要被检测到；⑷测试数量通常来说都会很庞大；⑸失效次数应该是很少的。
在IEC60880中并没有对测试用例给出明确的要求。
从事物的两面性来考虑的话，我觉得为了保证试验的有效性，统计测试是否应该也从两个方面来进行。
在60880中明确指出，软件应准确完成预期的功能，同时，不应该完成非预期的功能。
因此，应设计测试用例对于预期功能应进行规定次数的统计测试，同时，设计另一个测试用例对于非法和非预期的功能也进行相同次数的统计测试。
6软件修改要求软件的修改在设计过程中通常也是不可避免的，在IEC60880总对于修改有非常严格的规定，在流程需要遵循以下三个顺序：⑴生成修改请求；⑵分析和评估修改请求；⑶商议决定修改请求。
以上所有内容都应以正式文档进行归档。
7工具从开发角度来说，IEC60880中明确给出了软件开发和验证中所使用的软件类型，其具体如下：⑴结构工具。
用于支持完成软件规范，设计，开发执行等工作。
⑵测试编辑工具。
⑶图形界面工具。
⑷自动代码生成工具。
⑸语法分析工具。
⑹语义分析工具。
⑺形式化证明工具。
⑻比较工具。
工具的管理依照质量保证计划中的相关要求进行。
对于在软件开发中所使用的所有工具都应有相应的质量评估。
这些评估结果和建议应详细的记录和归档。
对于这些工具的评估主要面向几个方面：⑴适应性的评估。
目标工具本身是否适合进行类似的开发工作，包括其功能、精度等。
⑵质量评估。
质量的评估可以从两个方面着手进行。
首先如果工具本身能提供权威第三方的认证信息及相关评估资料，则可以相信工具本身的质量有相应的保证。
其次由V&V 小组对工具进行必要的测试和评估。
平贵的对象内容应包括：工具开发过程与环境。
工具功能准确性的测试。
使用经验的反馈和外界评价。
如果目标工具无法提供完备的资料说明和可测试功能的相关说明的话，对于工具的使用就应有相应的限制措施。
⑶工具本身也应有配置管理的相关要求。
该配置管理的设立意在加强软件设计的可追溯性。
其对应的关注点在于工具的名称，型号/版本，配置构成，错误记录，修改记录和评估报告等。
8软件相关资料评估对于提供资料的评估应遵循以下的几条内容：⑴数据资料的来源应尽可能来自用户和在役设备。
（安装在不同设备上，运行一定的时间，无重大修改或重大错误记录）⑵数据资料是遵循良好管理流程得来的。
⑶数据资料应提供证明，证明其可信度。
⑷数据资料的来源要与预期使用的环境相似。
⑸数据资料的来源版本应与目标相同。
⑹不同的版本出现的问题也应分析评估。
9软件安全管理软件的安全性设计应从两个方面来考虑：⑴软件的授权使用，应保证授权人员可以顺利进入软件系统，非授权人员无法进入系统。
授权人员进入系统的方法应考虑多样性。
仅仅使用密码的方法是不够的，还应考虑类似通行证，指纹，身份卡等其他物理方法。
非授权人员无法进入系统应考虑在多次无效输入后的系统保护模式以防止进一步的攻击。
⑵授权进入系统之后的安全防护。
在开发阶段应避免软件后门，隐藏功能的出现。
设计完成后重要的系统参数不允许操作人员的修改后者需要修改时的严格程序控制。
该程序从进入修改到修改完成后可追溯性都需要加以考虑。
传输数据应是系统中安全系数较低的数据。
在设计文档中明示重要的安全功能。
验证和确认软件功能时，应专门有针对安全功能的相关测试：⑴限制可访问功能的能力。