软件全生命周期质量管理探讨

…………………………．　术室蕴一　Ｉ　软件全生命周期质量管理探讨　

【摘要】软件生命周期是软件的产生直到报废的生命周期，包括软件的定义及规划、　段都会涉及质量问题，通常来说软件设计缺陷发现得越晚，所需付出的代价就越高，　【关键词】软件生命周期；质量管理；软件测试　

１．引言　软件质量是指与软件产品满足明确或隐含　需求的能力有关的特性，由于软件产品是逻辑　体，不具有实体的可见性，因而其质量也就更　加难以把握。软件产品的质量是通过软件开发　活动和软件开发过程构造入软件的，所以软件　开发管理者和软件开发者必须了解每一个开发　活动对软件产品质量可能产生的影响，及时掌　握每一个开发活动对软件质量所产生的影响，　并且对在开发过程中可能产生的或已经产生的　质量问题，能够及时发现并加以控制。要做到　这些必须实现软件开发的工程化。软件全生命　周期质量管理实际上就是工程化管理。它的主　要任务就是使软件开发活动规范化、程序化、　标准化。软件质量管理的基本方法就是根据软　件开发活动的各阶段，将质量管理目标分解为　若干可实现并可管理的部分，并采用相应的技　术和方法进行管理，并对其阶段性产品的质量　进行验证，确保最终软件产品质量满足用户的　要求。下图是一个软件开发过程的主要阶段分　解图。　－　一　１　Ｌ＿　ｊ　Ｌ－ｃ！一ｊ　Ｌ＿　…｝Ｌ＿　．ｊ　Ｌ１　ｊ　Ｌ－　ｊ　图１软件开发过程的阶段分解　２．需求分析阶段　２．１任务及目标　软件需求分析阶段的任务是确定所开发软　件的运行环境、功能和性能要求，编写开发计　划。软件需求分析是由软件开发方根据委托方　提出的软件任务书以及其它文件，详细确定软　件需求并编制出一个需求完整、详细的软件需　求规格说明。　２．２实施步骤　１）分析和确定软件开发和运行的环境；　２）明确操作者的要求，经分析后将任务书中的　技术指标条文拟定成相应的软件需求规格说明　的条文；３）确定人机界面；４）编制项目开发计　划，确定项目质量要求，并将它分解为对软件开　发各阶段的质量要求，给出检查准则；５）确定本　项目的质量保证、配置管理工作，并写入项目　开发计划；６）编写软件需求规格说明；７）初步　编写软件测试工作计划，明确计划安排。软件　测试工作计划一般由软件项目组编写。如要求　中国船舶重工集团公司第七一０研究所　陆晓明　需求分析、软件设计、编码、软件测试和运行维护六个阶段。软件生命周期的各个阶　因此有必要通过采用合理的管理手段来提高软件产品的质量。　独立测试，则测试计划应由独立测试单位在本　阶段评审通过后根据需求规格说明另行编写；　８）开始编写软件使用说明；９）评审；１０）安排　测试工作。若需要开发专门的测试软件或研制　专门的软件测试设备，则应在本阶段评审通过　后与软件开发并行地进行此项工作，以保证软　件测试工作按时顺利进行。软件测试的测试软　件开发和测试设备的研制工作按计划由软件项　目组或独立测试单位承担。　２．３阶段产品　１）项目开发计划；２）软件需求规格说明；　３）软件测试工作计划；４）软件项目计划数据　表。　２．４技术要求　Ｉ）软件需求规格说明应对软件的主要功　能、性能、技术指标进行定义，其内容应全　面、可检查；２）项目开发计划中应给出阶段评　审及配置管理计划，并明确人员。　２．５配置管理要求　软件任务书、开发计划、软件需求规格说　明、软件项目计划数据表、软件需求分析阶段　评审表、软件测试工作计划进入受控库。　２．６评审要求　在软件需求分析阶段，必须进行软件需求　评审，以保证软件需求的完整性、一致性和准　确性。提交软件任务书、项目开发计划、软件　需求规格说明、软件项目计划数据等，针对项　目开发计划及软件需求规格说明，对任务和需　求分析、可行性分析、质量保证、标准化、配　置管理等进行评审，以决定是否开展下阶段工　作。　３．软件设计阶段　３．１任务　软件设计阶段的任务是根据软件需求规　格说明进行软件的总体结构和功能模块间的设　计，初步编制软件集成测试计划。定义各功能　模块的接口并设计数据结构，对功能模块进行　过程描述设计，设计功能模块的内部细节，包　括算法和数据结构，为编写源代码提供必要的　说明。　３．２实施步骤　Ｉ）总体结构设计；２）设计该软件系统的数　据结构，给出所需的模型及所采用的算法原理：　３）设计高层模块的数据流和控制关系；４）给出　各个功能模块的功能描述、数据接口描述及全　局数据定义；５）根据软件可靠性要求，对各功　能模块进行可靠性指标的分配和相应的可靠性　设计；６）进行安全性分析，使安全性关键的软　件设计符合安全性要求；７）初步编制软件集成　测试计划；８）确定所有模块的功能及详细的接　口信息：９）对构成软件系统的各功能模块逐步　细化，形成若干个可编码的程序模块或程序单　

兀。　３．３阶段产品　１）软件设计说明；２）软件集成测试计划　（初步）。　３．４技术要求　１）各功能模块间应具有低耦合度及高内　聚度，功能模块的作用范围应在其控制范围　之内；２）各模块功能单一，模块接口的复杂度　低；３）软件设计说明和软件需求规格说明要　保持一致，并具有良好的可追踪性：４）各子项　目、模块的功能和接口要求必须完整、正确。　３．５配置管理要求　集成测试计划（初步）、软件设计说明进入　受控库。　３．６评审要求　评审软件设计是否实现了软件需求规格　说明的要求；评审设计方案与主要算法的可行　性和先进性；并针对集成的单元之间的信息流　和控制流的可追溯性、数据加工处理与数据结　构的一致性、并发性信息处理的正确性、可靠　性和安全性技术应用的程度及正确性等进行评　审，并最终做出本阶段工作是否完成、是否转　入下阶段工作的评审结论。　４．代码开发阶段　４．１任务　根据软件设计说明对各程序单元进行编　码、调试、静态分析和单元测试，验证程序单　元与设计说明的一致性，并将经过单元测试的　模块逐步集成和调试，完成软件系统集成，　４．２实施步骤　１）对每个程序单元用指定的程序设计语言　进行编码和测试；２）对完成编码的源程序进行　静态分析；３）补充和完善单元测试用例并依此　产生测试输入数据，开发单元测试程序；４）进　行程序单元测试；５）将经过单元测试和调试的　程序逐步集成和调试，直至集成为相对独立的　软件功能模块；６）及时清除程序中用于调试等　项工作的多余语句和程序“垃圾”；７）在集成　

当Ｄ取值为ｏ．２８ｍ时，对应的参数ｄ＝０．ｉｍ，　ｔ＝０．１ｍ，ｐ＝１％，求出此时的共振频率为ｆｏ＝３６ＨＺ，　不在要求频率范围。　参数穿孔率、空腔深度同时变化时，空腔　深度对吸声系数的影响规律是一定的，都是在　空腔深度取值为０．１４ｍ是吸声系数达到第一个　极大值。令空腔深度Ｄ＝Ｏ．１４，穿孔率对吸声系　数影响较大，讨论穿孔率的吸声系数的影响。　观测数据，只有穿孔直径ｄ＝Ｏ．１ｍｍ时，才能更　好的满足吸声系数大于０．６，故令ｄ＝Ｏ．１ｍ。如　图３所示。　４．结论　吸声系数随穿孔率与板厚的共同影响关　系如图，板厚增大时，最大吸声系数对应的穿　孔率也相应变大。板厚在０．３－０．４范围内时，　吸声系数曲线相对平滑，对应的穿孔率也相对　合理。板厚增大到Ｏ．５时，保证吸声系数大于　ｏ．６，则会导致穿孔率范围变窄。　根据以上分析，取穿孔直径为ｏ．Ｉｍｍ，空　腔深度为０．１４ｍ，当板厚取０．３时，穿孔率在　２％一４％范围内的，吸声系数曲线图，如图４所　示；当板厚取０．４，穿孔率在３％－５％范围时的吸　声系数曲线图如图５所示。　仿真曲线结果表明，以上的取值都满足设　计要求，即在ＩＯＯＢＺ－ＩＯＯＯＨＺ频率范围内，微穿孔　板吸声系数能达到Ｏ．６以上。板厚靠近ｏ．４ｒａｍ，平　均相对系数较大。　

参考文献　［１］赵松龄．噪声的降低与隔离　．同济大学出版社，１９８５．　［２］马大猷．微穿孔板声阻抗的直接准确测量Ⅱ］．声学学　报，１９８３８④：２５７　２６２．　嘲马大猷．现代声学理论基础　．科学出版社，２００４．　

基金项目：质检公益性行业科研专项项目（项目编　号：２０１３１０００４）；重点科技攻关项目《新型光通讯核　心模块快速故障诊断与质量评价研究》（项目编号：　２０１２１Ｏ１Ｏ１０２５）。　

作者简介：熊洁（１９８９一），女，湖北天门人，硕士　研究生，研究方向：测试计量技术与仪器。　

电早世鼻一１７７—　Ｉ　一一　交　…………………………一　调试后，对经过修改的模块应进行单元回归测　试：８）编写软件使用说明初稿；９）评审　４．３阶段产品　１）修改了的软件设计文档及相应的修改报　告单；２）程序单元的编码；３）程序单元的测试　结果、测试用数据及测试辅助程序；４）软件使　用说明初稿。　４．４技术要求　１）用指定的编程语言进行编码；２）编码符　合规定语言的编码格式约定；３）每个程序单元实　现的功能、性能和接口应该满足设计说明的要　求；４）必须进行程序静态分析；５）按要求应分别　采用自检、互检、专检等方式检测软件，以提　高软件质量和可靠性；６）被测试单元中的每项　软件特性和功能都必须被至少一个测试用例所　覆盖；７）采用必要的安全性设计措施，保证安　全性设计需求的实现；８）对在单元测试中发现　错误的程序应进行修改，修改后的程序单元必　须进行回归测试；９）不仅要考虑对合法的输入　产生测试用例，而且要对非法的、非预期的输　入产生测试用例，既要对正常的处理路径进行　测试，也要考虑对出错的处理路径进行测试；　ｌＯ）程序单元的测试用例需加明确的注释，并和　试集，存档保留。　４．５配置管理要求　修改的文档和相应的修改报告单、软件使　用说明、程序单元的代码、单元测试数据和测　试程序、软件实现阶段评审表进入受控库。　４．６评审要求　评审编码、单元测试的正确性和完整性，　在完成文档、程序编码、程序单元调试及单元　测试的前提下，提供程序单元的编码、程序单　元测试的结果和测试用例、程序开发卷宗等，　对程序代码与详细设计的一致性、代码格式与　规定要求的一致性、程序代码调试结果的正确　性、静态分析过程的正确性和合理性、单元测　试用例的充分性和合理性、单元测试数据的产　生和测试过程的正确性、合理性和完整性、软　件实现过程中若修改了软件详细设计或概要设　计，则应多途径审查从被修改阶段开始到软件　实现阶段为止所有改动部分的正确性等进行审　查，做出软件实现阶段是否完成、是否将程序　和文档提交，以便进行软件集成测试的结论。　５．集成测试阶段　５．１任务　根据集成测试计划，在将底层程序单元逐　步集成到子项目、直至整个开发项目的过程中　对软件进行测试。在进入集成测试前，各程序　单元必须完成代码静态分析和逐步审查、无错　误地通过编译或汇编、完成单元测试、满足软　件质量要求、程序单元已置于软件配置管理之　下等。　５．２实施步骤　１）补充、修改和完善软件集成测试计划：　２）校订集成顺序，编制软件集成测试程序并核　对其正确性；３）建立软件集成测试环境；４）对　集成软件功能模块进行测试；５）对集成软件子　项目进行测试；６）对集成软件产品总体进行测　试；７）分析测试结果，找出产生错误的原因；　８）提交软件集成测试分析报告，以便尽快修改　错误：９）完成软件使用说明的编写工作：１Ｏ）评　审。　５．３阶段产品　１）修改后的软件集成测试计划；２）修改后　的软件设计文档及相应的修改报告单；３）软件　集成测试分析报告：４）通过集成测试的代码；　５）集成测试用例集和集成测试辅助程序；６）软　件使用说明。　５．４技术要求　一１７８一电早世界　１）软件集成测试应保证模块间无错误地连　接；２）应测试软件系统或子系统对数据的正确　处理能力和经受错误的能力；３）在软件集成测　试中，在找出错误后，程序应送回编码者进行　修改、调试和单元测试，然后再重新进行软件　集成测试；４）通过软件集成测试的软件应满足　各模块无错误地连接、满足各项设计要求、对　错误输入有正确的处理能力、人机界面正确无　误、满足全部操作要求等。　５．５配置管理要求　软件集成测试计划、修改的软件设计文　档及相应的修改报告单、软件集成测试分析报　告、最后集成完成的程序代码、集成测试用例　集和集成测试辅助程序、软件使用说明、软件　集成测试的评审报告进入受控库。　５．６评审要求　评审集成测试结果的有效性、软件的结　构和接口间的协调性；评审在软件集成测试中　对所发现的问题进行软件设计修改、程序代码　修改的正确性。在完成测试、测试分析和文档　提供软件集成测试计划、软件集成测试分析报　告、软件问题报告单的前提下，对软件集成测　试的恰当性、测试用例集的完整性和恰当性、　测试结果和测试用例集的一致性、测试环境和　正式运行环境的相容性、测试分析过程和结论　的正确性等进行评审。　６．确认测试阶段　确认测试主要是针对软件的全部功能和性　能要求的黑盒测试。软件项目开发单位的质量　管理部门的测试人员负责测试过程的实施和测　试结果的确认，技术管理部门的有关人员与业　务部门及项目组成员共同组成确认测试小组，　完成确认测试任务。　６．１任务　１）根据软件需求规格说明中定义的全部　功能和性能要求及确认测试计划，测试整个　软件，确认其是否符合软件需求规格说明的要　求；２）软件确认的依据是软件需求规格说明、　概要设计说明及详细设计说明等，测试对象为　通过了软件集成测试的源程序代码；３）软件确　认测试工作包括测试环境的建立和测试计划的　编制两项，此两项工作在软件需求分析阶段就　应开始。　６．２实施步骤　１）组织和确定软件确认测试组成员；２）修　订确认测试计划，对确认测试计划进行评审，　经批准后实施；３）建立和确认软件测试环境；　４）接口测试；５）根据软件需求规格说明中规定　的功能对软件逐项进行测试；６）根据软件需求　规格说明中规定的性能要求，如精度、速度、　适应性等，对软件逐项进行测试；７）逐条运用　软件使用说明进行测试，以进一步证实该说明　的适应性和有效性，并改正其中的错误；８）分　析测试结果，找出产生错误的原因；９）编写确　认测试报告；１Ｏ）评审。　６．３阶段产品　１）确认测试计划；２）确认测试分析报告；　３）确认测试用例集及有关测试辅助程序；４）通　过确认测试的程序代码。　６．４技术要求　１）关键软件部件或测试项目的确认测试应　由与该软件项目组无关的技术人员进行，以保　证测试的客观性；２）应在正常输入数据和合理　的异常输入数据的条件下，考查被测软件功能和　性能的完备性；３）确认测试的测试环境必须与软　件真实运行环境一致或相容；４）全部测试结果、　预期结果及测试数据应当存档保留：５）个别功能　和接口要求只能在系统联试后才能确认的，必须　在确认测试分析报告中写明；６）软件项目组应　积极配合确认测试组的测试工作。　６．５配置管理要求　确认测试计划、确认测试分析报告、确认　测试用例集及有关测试辅助程序、通过确认测　试的程序代码、确认测试计划评审表和确认测　试阶段评审表进入受控库。　６．６评审要求　在本阶段应进行两次评审，软件确认测试　计划评审和软件确认测试阶段评审。　１）确认测试计划评审　评审确认测试计划的合理性、完备性以及　与软件需求规格说明的一致性。提供软件确认　测试计划，确认测试计划安排的合理性；确认　测试环境选择的合适性；确认测试计划中功能　测试的合理性、齐全性；确认测试计划中性能　测试的合理性、齐全性；确认测试用例、测试　数据、测试方案的合理性、正确性和全面性：　确认测试结果分析的合适性；确认测试组人员　组成和安排的恰当性。该评审应得出的结论是　该确认测试计划是否可行，是否批准实施。　２）确认测试阶段评审　评审确认测试结果的有效性；评审软件　功能、性能与软件需求规格说明的相容性；评　审确认测试分析结果的正确性。完成确认测试　后提供软件确认测试分析报告、确认测试用例　集，对确认测试用例集的完备性和恰当性、确　认测试用例集和确认测试结果的一致性、确认　测试环境和运行环境的相容性、确认测试分析　过程和结论的正确性进行评审，最终确认该软　件是否实现了软件需求规格说明所要求的技术　指标，对确认测试过程不正确或不完整，需　改进测试过程后重做或另外组织确认测试组重　做。　７．系统联试阶段　７．１任务　系统联试是大系统开发的一个重要阶段。　系统联试应由大系统的开发部门主持，软件项　目组参加，以保证软件与大系统的对接。　７．２技术要求　１）软件与所属大系统的接口应重点测试，　不允许有不协调之处；２）对软件向所属大系统　输出的信息以及从所属大系统向软件输入的　信息，都应仔细归类进行测试，并注意边缘测　试；３）测试应在软件和大系统的正式工作环境　下进行；４）对存在的问题应分析其产生的原因　并给出修改意见；５）全部预期结果、测试结果　及测试数据应存档保留。　８．总结　软件生命周期质量管理就是使软件开发过　程规范化、程序化和标准化。它通过将复杂的　问题分解为若干可实现并可管理的部分，对软　件生命周期的各阶段采取相应有效的方法，对　其阶段性产品的质量进行验证，以保证软件的　质量。