📄 iso 9001在软件开发、供应和维护中的使用指南.htm
字号:
开发计划应包括下列各项：<BR>
a.项目定义，包括项目目标的陈述及参照的需方或供方的有关项目；<BR>
b.项目资源的组织管理，包括项目组人员构成、职责、分供方的作用和使用的资源；<BR>
c.开发阶段（如5.4.2.1所定义）；<BR>
d.项目进度，其中要确定需执行的任务，各项任务所需要的资源和时间及各任务之间的相互关系；<BR>
e.确定有关的计划，诸如：<BR>
------质量计划；<BR>
------配置管理计划；<BR>
------集成计划；<BR>
------测试计划。<BR>
随着开发的进展应及时更新开发计划，在开始某一阶段工作以前应按5.4.2.1条确定该阶段的工作计划。并应经过审查和批准之后执行。<BR>5.4.2开发计划<BR>5.4.2.1阶段<BR>
开发计划应严格规定将需方需求规格说明转换为软件产品的过程或方法，这可能包括把工作划分为几个阶段，并且确定下列各项：<BR>
a.要执行的开发阶段；<BR>
b.每一阶段所需的输入；<BR>
c.每一阶段应产生的输出；<BR>
d.每一阶段要执行的验证步骤；<BR>
e.分析与各开发阶段达到规定需求相关的潜在问题。<BR>5.4.2.2管理<BR>
开发计划应规定如何对项目进行管理，包括确定下列各项：<BR>
a.开发、实现及交付的时间安排；<BR>
b.进度控制；<BR>
c.组织职责、资源和工作的分配；<BR>
d.不同工作组之间的组织协调和技术接口。<BR>5.4.2.3开发方法和工具<BR>
开发计划应确定保证所有活动正确实施的方法，可能包括下列各项：<BR>
a.开发的规则、惯例和约定；<BR>
b.开发的工具和技术；<BR>
c.配置管理。<BR>5.4.3进度控制<BR>
应制定进度评审计划，将其纳入文档并组织实施，以确保突出的资源配给问题得到解决，整个开发计划得以贯彻。<BR>5.4.4开发阶段的输入<BR>
应规定每一开发阶段所需的输入并纳入文档，每一项需求均应明确定义，以使它的完成情况可以验证，在起草过程中应解决不完整、模棱两可或相互矛盾的需求。<BR>5.4.5开发阶段的输出<BR>
应规定每一开发阶段所要求的输出并纳入文档。应对每一开发阶段的输出进行验证并做到下列几点：<BR>
a.满足相应的需求；<BR>
b.包含或引用进入后续工作阶段的验收准则；<BR>
c.不论在输入信息中是否已经规定，输出均应符合有关的开发惯例和约定；<BR>
d.标识出对产品安全和正常工作至关重要的产品特性；<BR>
e.符合有关法规的要求。<BR>5.4.6各阶段的验证<BR>
供方应制定在每个开发阶段结束时对该阶段的输出进行验证的计划。<BR>
应通过采用下列开发控制措施证实开发阶段的输出满足了输入的要求：<BR>
a.在开发阶段的适当时机进行开发评审；<BR>
b.在可能情况下，将新设计与已被证明是正确的类似设计进行比较；<BR>
c.进行测试和演示。<BR>
应记录验证结果及为确保满足给定需求所需进一步采取的措施，并在措施完成以后进行检查，只有经过验证的开发输出才能提交配置管理并被验收，供后续阶段使用。<BR><A
name=5．5质量策划>5.5质量策划</A><BR>5.5.1总则<BR>
供方应制定质量计划，作为开发策划的一部分。<BR>
质量计划应随开发的进展而及时更新，各阶段有关的软件项应在该阶段开始时完全确定.<BR>
质量计划应经正式评审井得到所有与该计划的执行有关的组织的同意。<BR> 描述质量计划的文档（见
5.5.2）可以是一个独立的文档（称作“质量计划”），也可以是其他文档的一部分，还可以由多个文档组成，其中包括开发计划。<BR>5.5.2质量计划内容<BR>
质量计划应规定或引用下列条款：<BR>
a.质量目标，尽可能以定量形式给出；<BR>
b.定义每一开发阶段的输入、输出准则；<BR>
c.确定要进行的测试、验证和确认活动的类型；<BR>
d.要执行的详细的测试、验证和确认活动计划，包括时间进度、资源和批准权力等；<BR>
e.对质量活动的具体职责。诸如：<BR> —
—评审和测试；<BR> —
—配置管理和更改控制；<BR> — —对缺陷的控制及纠正措施。<BR><A
name=5.6设计和实现>5.6设计和实现</A><BR>5.6.1总则<BR>
设计和实现活动是指将需求规格说明转换为软件产品的过程。由于软件产品的复杂性，这些活动必须以严格规定的方法进行，以使按照规格说明生产产品，而不是靠测试和确认活动来保证质量。<BR>
<STRONG>注.7由于设计和实现过程常常是供方的专利，因此双方应就向需方提供信息的程度达成协议。</STRONG><BR>5.6.2设计<BR>
除了对所有开发阶段共同的要求之外，对设计活动还应考虑下列因素：<BR>
a.确定设计依据——除了输入和输出规格说明以外，还应检查设计规则和内部接口定义等方面；<BR>
b.设计方法——应使用适合所开发软件产品类型的系统化设计方法；<BR>
c.惜鉴以往的设计经验——供方应吸取以往设计的经验教训，避免重新出现同样或类似的问题；<BR>d.对后续工作的考虑——产品的设计应便于测试、维护和使用。<BR>5.6、3实现<BR>
除了对所有开发活动共同的需求以外，在每一实现活动中还应考虑：<BR> a.规则
—应规定编程规则、编程语言、命名约定、编码和注释规则等并遵守之；<BR>
b.实现方法——供方应采用合适的实现方法和工具以满足需求。<BR>5.6.4评审<BR>
供方应进行评审以确保满足需求及正确使用上述方法。只有在所有已发现的缺陷的影响均被消除，或缺陷的影响虽来消除，但已弄清带着缺陷进一步工作的风险之后，方可进行下一步的设计或实现工作。<BIG><BR></BIG>
这些评审的记录应予保存。<BR><A
name=5．7测试和确认>5.7测试和确认</A><BR>5.7.1总则<BR>
从单个软件项到一个完整的软件产品可能需要进行不同层次的测试，有一些不同的测试与集成方法。<BR>
在某些情况下，可以将确认、现场测试和验收测试合为一个活动。<BR>
描述测试计划的文档可以是一个独立的文档，或是其他文档的一部分，也可以由几个文档组成。<BR>5.7、2测试策划<BR>
供方应在测试之前制定和评审测试计划、规格说明和规程，应考虑给出下列内容；<BR>
a.软件项测试计划、集成测试计划、系统测试计划和验收测试计划；<BR>
b.测试用例、测试数据和预期的结果；<BR>
c.要进行的测试类型：例如功能测试、边界测试、性能测试、可用性测试；<BR>
d.测试环境、工具和测试软件；<BR>
e.测试是否完成的判断准则；<BR>
f.用户文档；<BR>
g.所需人员及相应培训要求。<BR>5.7.3测试<BR>
应对测试中的下列方面给予特别注意：<BR>
a.应按有关规格说明记录测试结果；<BR>
b.应记录发现的问题，指出其可能对软件其他部分带来的影响，并且通知对
此负责的人员，以便能对间题进行追踪直至问题解决；<BR>
c.应确定受更改影响的部分，并对它们重新进行测试；<BR>
d.应评价测试是否适度和适当；<BR>
e.应考虑软硬件配置并纳入文档。<BR>5.7.4确认<BR>
在产品交付和需方验收之前，供方应尽可能在类似于合同规定的使用环境下对
整个产品的运行进行确认。<BR>5.7.5现场测试<BR>
在要求进行现场测试的情况下，应指明下列事项：<BR>
a.需在现场环境中进行测试的特性；<BR> b.
在进行和评价测试方面，供方和需方的具体职责；<BR> c.恢复用户环境（测试之后）。<BR><A
name="5． 8验收">5.8验收</A><BR>5.8.1 总则
<P>
当供方准备好交付经确认的产品时，需方应根据合同中的规定准则和方式判断产品是否已经可以验收。<BR>
对验收过程中发现的问题的处理方法以及对它们的处置应该由需方和供方商定并纳入文档。<BR>5.8.2制定验收测试计划<BR>
在进行验收活动之前，供方应协助需方确定下列内容：<BR>
a.时间进度；<BR> b.评估规程；<BR>
c.软件／硬件环境和资源；<BR> d.验收准则。<BR><A
name=5．9复制、交付和安装>5.9复制、交付和安装</A><BR>5.9.1复制<BR>
复制是交付前应实施的一个步骤，在准备复制过程中应考虑：<BR>
a.每个该交付的软件项的拷贝数量；<BR>
b.便于人阅读的每个软件项的介质类型，包括格式和版本；<BR>
c.该交付的文档的条款（手册、用户指南等）；<BR>
d.协商一致的版权和许可证协议；<BR>
e.必要时主拷贝和备份拷贝的保管，包括灾难性故障的恢复方案；<BR>
f. 供方提供拷贝的责任期限。<BR>5.9.2交付<BR>
应规定对所交付的软件产品的正确性和完整性进行验证的措施。<BR>5.9.3 安装<BR>
应就下列方面明确规定供方和需方的作用、职责和义务。<BR>
a.时间进度，包括非正常工作时间和周末；<BR> b
提供出入需方的便利条件（密钥、通行证或口令、防护用具等）；<BR>
c.熟练人员的配备；<BR> d.使用需方的系统和设备3<BR>
e.对每次安装的确认要求应通过合同加以规定；<BR> f.
对每次安装完成进行认可的正式规程。<BR><A name="5．10 维护">5.10 维护</A><BR>5.10.1
总则<BR>
当需方要求在软件产品初次交付和安装后供方负责进行维护时，应在合同中规定。供方应建立并遵守实施维护活动及验证其满足特定维护需求的规程。<BR>对软件产品的维护活动一般分为：<BR>
a.问题的解决；<BR> b.接口的调整；<BR>
c.功能扩充或性能改进。<BR>
在合同中应规定维护项及维护期，诸如：<BR> a.程序；<BR>
b.数据及其结构；<BR> c.
规格说明；<BR> d.提供给需方或用户的文档；<BR>
e. 提供给供方使用的文档。<BR>5.10.2维护计划
所有维护活动都应按供方和需方事先商定的维护计划进行和管理。该计划应包括下列方面；<BR>
a.维护范围；<BR> b.产品初始状态标识；<BR>
c.支持机构；<BR> d.维护活动；<BR>
e.维护记录和报告。<BR>5.10.3 产品初始状态标识<BR>
应规定需维护的产品的初始状态，纳入文档，并经供需双方同意。<BR>5.10.4 支持机构<BR>
为了支持维护活动，可能需要建立一个由供需双方的代表组成的机构。由于维护阶段的活动并不能总是按照预订的安排进行，因此这个机构应能灵活应付意外问题的发生。用于维护活动的设施和资源可能也是由它确定。<BR>5.10.5
维护活动的类型<BR>
在维护中对软件实施的所有更改（为了解决问题、调整接口、扩充功能或改进性能）均应尽可能按照同于软件产品开发时采用的规程进行。所有这些更改还应按文档控制和配置管理规程纳入文档。<BR>
a.解决问题<BR>
解决间题包括对引起操作问题的软件故障进行检测、分析和纠正。在解决间题时，可以先作些临时调整，以便减少停机时间，以后再进行永久性修改。<BR>
b.调整接口<BR>
对由软件控制的硬件系统或部件进行扩充和更改时，可能需要对接口进行调整。<BR>
c.扩充功能或改进性能<BR>
在维护阶段，需方可能会提出对现有功能和性能进行扩充和改进的要求。<BR>5.10.6
维护记录和报告<BR>
所有维护活动都应按预先规定的格式进行记录并保存，供需双方应商定维护报告的提交规则。对于每一被维护的软件项，维护记录应包括下列条款：<BR>
a.收到的维护申请或问题报告清单及目前的状态；<BR>
b.负责受理维护申请或实施适当的纠正措施的机构；<BR>
c.纠正措施的安排次序；<BR>
d.纠正措施的结果；<BR> e.
失效发生和维护活动的统计数据。<BR>
维护活动记录可用于评价和改进软件产品，以及完善质量体系。<BR>5.10.7 释放规程<BR>
为了维护性能，供需双方应商定将更改纳入软件产品的规程，并写入文档。<BR>这些规程应包括；<BR>
a.确定何处可以进行局部“修补”或必须释放完全更新了的软件产品拷贝的基本原则；<BR>
b.根据释放的频度和（或）对需方使用的影响以及及时实施更改的能力，对释放类型（或类别）进行描述；<BR>
c.将当前或计划进行的更改通知需方的方法；<BR>
d.确认所实现的更改不会导致其他问题的方法；<BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -