软件测试过程管理

软件测试过程管理（共12篇）

软件测试过程管理 篇1

1 概述

软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。

软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。

2 问题描述

缺陷度量的技术的一个重要的指标和重要的作用就是对于软件系统中存在的问题的显示, 也就是对具体问题的描述。一般情况下, 软件的缺陷会分为大致的几种常见类型, 我们也可以根据这些类型, 做出不同的缺陷显示方法。正交分类方法ODC (Orthogonal Defects Classification) 作为一种常见的问题显示方法, 能够准确的显示问题, 一直被业内广泛的使用, 但是它也存在着技术上的缺陷, 就是解读方式比较复杂。另一种常见的方式是Thayer, 有点是比上一种方式的结果更精确, 但是解读起来也更加复杂。这两种方式的共同点在于都忽略了对于软件的过程的监控和分析, 这是一个非常严重的技术问题, 因为软件的研发过程才是质量问题的形成的重要阶段, 要控制质量问题, 就必须控制软件的研发过程, 所以, 我们想要找出新的监管和缺陷度量方法, 就要从控制过程的角度来分析。现在市场上的已经开发了几种缺陷管理系统工具, 例如Mercury公司的Quality Center, IBM公司的Rational系列管理工具, 微软公司的VSTS等。上述的几种技术都没有解决缺陷的分类问题, 导致了在软件过程的管理中的缺陷分类的薄弱。也直接导致了现有的缺陷管理工具在实用性和综合性方面的不完善, 上述的两种管理工具只是提供一些缺陷属性数量的简单统计结果, 要想得到一些更精确和更综合全面的分析结果, 用户不得不借助其他的统计方式。基于该目前市面上的工具的这样一种缺陷, 和软件过程管理的实际需要的不协调, 笔者制定了一种新的管理模型, 如图1。该模型可根据需要设计缺陷属性度量分类标准。在软件开发过程中通过缺陷管理系统采集缺陷数据, 运用缺陷分析方法实施缺陷分析, 把握缺陷发展趋势, 对软件项目开发过程进行综合评价。实施缺陷预防方案, 提高软件产品的开发质量。通过缺陷分析结果的反馈, 改进缺陷度量分类标准和分析目标, 提高缺陷分析结果的准确性。本文重点研究了缺陷分类方法和缺陷数据的分析方法, 并结合某项目中的缺陷数据实例进行了分析。

3 缺陷分类方法研究

3.1 缺陷分类的目的和原则

将软件的缺陷问题分类, 可以更好的管理和击破软件的缺陷问题。并且有益于分析缺陷产生的原因, 可以早到有计划的预防。缺陷分类方法应满足以下要求:准确地对发现的缺陷类型进行分类;缺陷分类类型之间应无重叠, 并尽可能多的覆盖开发过程中出现的分类;分类要与软件生命周期有机结合, 从软件过程的角度对软件缺陷进行分类。

3.2 缺陷度量属性分类

实施度量分析的最终目的是为了服务软件的研发和试验的各个阶段的顺利进行, 一旦发现问题可以及时纠正, 以免影响软件的研发和生产。在引言中曾提到, 软件缺陷的范围很广, 它贯穿于整个软件研发和生产试验的各个阶段, 是一种伴随着软件的整个过程的始终的应用, 所以它的重要程度也可想而知。一个缺陷需要记录许多相关的度量属性, 如何划分这些度量属性也是缺陷分类研究领域的一个热点。传统的分类方法主要目标是消除软件缺陷, 而不是对缺陷出现的原因进行一个正确的评估和解决方案的分析, 这样的分类方法是不利于软件的完善和发展的。所以, 一个全方位多角度的缺陷度量方式就应运而生。下面本文中将从缺陷度量属性设计的三个方面, 即描述属性、统计属性和控制属性来进行具体阐述。a.缺陷描述属性。缺陷描述属性是指:缺陷信息描述, 对于缺陷的各个方面和各个角度的描述, 既包括缺陷的时间, 产生原因也包括具体的解决方案的策划。b.缺陷统计属性。缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。c.缺陷控制属性缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。

4 缺陷度量过程管理

4.1 处理缺陷的角色

在软件开发过程中处理缺陷的四个负责人和所负责的任务的具体情况:报告人:将发现的缺陷登录到缺陷管理系统, 描述缺陷的表现形式和再现方法, 对缺陷进行简单分类, 由项目经理、组长对缺陷进行再分配, 缺陷修正完成后, 对其进行回归测试审核。负责人:负责缺陷的调查和修正工作, 分析缺陷引入的原因。组长:分配缺陷到负责人, 并对负责人已修正缺陷进行复查, 确保不会因为修正而引入新的缺陷产生, 分析缺陷流出原因。项目经理:分配缺陷到项目组, 定期总结缺陷分析报告, 把握缺陷发展趋势, 采取应对措施保证项目的进度及开发质量, 根据缺陷分析结果改进缺陷度量属性分类。

4.2 缺陷生命周期

缺陷生命周期是指缺陷从被报出之后, 到开始修正, 再测试直到该缺陷被完全消除的时间段。缺陷生命周期是影响软件研发的一个重要的指标和因素, 定期对缺陷各种状态信息的变化趋势进行总结, 是项目经理计划开发周期, 调整开发进度的重要依据。

4.3 缺陷分配管理流程

整个的缺陷的周期主要是指从发现到完全消灭的时间, 在这个时间内, 缺陷的分配管理流程主要包括:a.报告人登陆缺陷;b.管理人员分配缺陷给相关责任人;c.责任人调查并修正缺陷, 分析缺陷引入的原因;d.管理人员对修正结果进行复查, 分析缺陷流出的原因;e.报告人验证缺陷是否被正确。

结束语

软件的研发是一项非常复杂和严谨的工程, 所以在这个阶段要对软件的质量作出各个方面的监测和试验, 这样才能最大程度上减少软件的质量问题的发生概率, 而软件缺陷度量作为软件质量监测的一个重要方式, 应该引起我们有关的工程人员的足够重视, 不断在缺陷度量的技术上提升, 这样才更好的服务于我们的软件研发工作。

参考文献

[1]何荣勤.CRM原理.设计.实践[M].北京:电子工业出版社, 2006.

[2]肖阳春.计算机网络与多媒体技术[M].北京:中国铁道工业出版社, 2008 (6) :81-82.

软件测试过程管理 篇2

班级：——

学号：——

姓名：——

软件项目管理是为了使软件项目能够按照预定的成本，进度，质量顺利完成，而对人员，产品，过程和项目进行分析和管理的活动。根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析，设计，编码到测试，维护全过程）都能在管理者的控制之下，以预定成本按期，按质完成软件交付用户使用。

——序

当今世界，IT技术对于一个企业的重要性是毋庸置疑的。在很多领域，计算机技术都得到了非常广泛的应用，IT技术已经普遍地服务于社会的各行各业，在很多的领域都形成了推动力。但同时我们也看到一个非常严重的问题，那就是软件危机。为什么会发生“软件危机”。据总结，主要产生的原因是：（1）由于缺乏软件开发的经验和有关软件开发数据的积累，以致经常出现超出经费预算，无法遵循进度计划。（2）软件需求在开发的初期阶段不够明确，或是未能得到确切的表达。开发工作开始后，软件人员和用户又未能及时交换意见，造成矛盾在开发期几种暴露。（3）未能在测试阶段做好充分的检测工作，提交至用户的软件质量差，在运行过程中暴露出大量的问题。归结起来，我们说的软件危机是一种矛盾，就是弱的软件生产力能力与强的业务发展需求之间的矛盾。要能够迎接业务发展所带来的挑战，从事软件生产的组织迫在眉睫要去做的一件事就是软件生产力的改造。在“应用就是业务”的今天，软件生产力的改造是决定企业能否获得并长久保持竞争优势的一个决定性因素，所以，关注并启动软件生产力的提升是一项战略性的决策，是一个系统工程，它将决定企业能否获得并长久保持竞争优势。而项目管理则是提升生产力的一项重要任务。

然而，项目管理在我们的软件生产中的应用是那么的重要。那么我们应该怎么样才能更好的掌握项目管理，我们的项目流程是怎么样的。

首先，项目管理的第一流程是项目的启动。

项目的启动就是确定项目的目标范围，它主要包括开发和被开发双方的合同（或是协议），软件要完成的主要功能以及这些功能的量化范围，项目开发的阶段周期等。尤其是启动信息技术（IT）的项目，我们做软件的必须了解企业组织内部在目前和未来主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境是什么。启动信息技术（IT）的项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。在项目启动的过程中，我们还要注意将项目的范围进行明确定义才能进行很好的项目规划。项目目标必须是可实现可度量的。如果这一步管理得不好或是做得不好，直接导致的是项目的最终失败。

其实，第二就是项目的规划

项目的规划其实就与项目的计划意义差不多。它是一项复杂的，自始至终不断迭代的一个过程。而且为项目的运作提供可靠的实施基础。在整个项目中，项目规划是指项目的估算，风险的分析，进度的规划，人员的选择与配置，产品质量的规划等。然而，在项目管理的过程中，计划的编制是整个项目规划中最为复杂的阶段。项目计划工作涉及九个项目管理知识领域。也就是说我们要知道九个项目管理知识领域中哪些是重要的，哪些是必要的和熟悉它们之间的关系。而且在计划编制的过程中，我们还可看到后面各阶段的输出文件。所以说它是指导项目的进程发展。规划建立软件项目的预算，提供一个控制项目成本的尺度，也为将来的评估提供参考，它是项目进度安排的依据。最后，形成的项目计划书将作为跟踪控制的依据。

第三：项目的实施及控制

一旦建立起基准计划就必须按照计划执行，这包括按计划执行项目和控制项目，以使项目在预算内，按进度，使顾客满意的完成。在这个阶段，项目管理过程包括：测量实际的进程，并与计划进程相比较。同时，发现计划的不当之处。为了测量实际的进程，掌握实际上已经开始或结束的是哪些任务，已经花了多少钱，这些都是很重要的。如果实际进程与计划进程的比较显示出现项目落后于计划，超出预算或是没有达到技术要求，就必须立即采取纠正措施，以使项目能恢复正常轨道，或是更正计划的不合理之处。然而，项目的监控，也是为项目能正常回到轨道上的一个重要步骤。俗话说：“没有跟踪就不算完成”，在软件项目中，有太多的工作需要我们去完成，如果有时计划做得不够周密，或是计划赶不上变化。我们怎么办，置之不理？还是去跟踪监控一下，然后及时改正错误。为什么我们用的那么多的软件是要不定时的安装补丁，原因也就是因为这个。在跟踪监控中我们发现问题，然后去修补它，使得软件的性能，功能更好。总得来说。项目的实施及监控最终的目的就是保证项目能够安装预先设定的计划轨道上行驶，使得项目不要偏离预定的发展进程，尽快完成软件项目。

最后就是软件的项目结束

项目管理的最后环节就是软件项目的结束过程。因为项目的特征之一就是它的一次性。有起点也有终点，进入项目结束期的主要工作是适当地做出项目终止的决策，确认项目实施的各项成果，进行项目的交接和清算等，同时对项目进行最后评审，并对项目进行总结。这个也代表着项目将进入后续的维护期。项目最后执行的结果是有两种状态，要不就是成功要不就是失败。然而，一旦我们决定终止一个项目，项目就要有计划，有序的分阶段停止。当然，这个过程可以简单地执行也可以详细认真的执行。在这里项目总结是项目结束中的最后一个环节也是一个我们不能忽视的一个环节。很多项目没有能进行很好的总结，比如说项目总结时项目人员已经不全了，有新的项目要做，没有时间去写等等的理由让项目的总结没做好。所以，这也是软件项目那么多漏洞的原因之一。所以，项目的结束之前的工作我们也要好好认真的完成。

软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）。另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述的特点，软件项目管理与其他项目管理相比，有很大的独特性。所以，软件项目开发管理过程中，不仅要努力实现项目的范围、时间、成本和质量等目标，还必须协调整个项目过程，以满足项目参与者及其他利益相关者的需要和期望；随着软件规模和所涉及的领域不断地扩大，软件项目的管理越来越困难。纵观所有失败的软件项目，基本原因是不能管理其软件过程，在无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差，识别软件项目的风险甚至果断中止项目，而且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制，必须明确软件项目管理流程。

最后，总结一下项目管理过程。软件项目管理不同于其他的项目管理，它有很多的特殊性。软件是一个特殊的领域，远远没有建筑工程等领域那么规范化、软件目前有很大的发展空间，经验在项目管理中发挥着很重要的作用，理论和标准还在发展中，它体现软件的“软”的特殊。合同启动了一个软件项目，同时贯穿项目的始终；根据合同进行软件的需求分析，获得需求规格；根据需求规格进行任务分解，任何分解的目的是可以很好得规划和管理项目；根据任何分解的结果，给出项目需要的资源，以便于估计活动的历时，最终编制项目计划以及项目的预算等。这样便可以形成项目的三个核心的基准计划：项目范围基准，成本基准，时间基准计划等。

软件测试过程管理 篇3

关键词：软件项目；设计与开发；过程管理；有效性

中图分类号：TP311.52 文献标识码：A 文章编号：1674-7712 （2012） 14-0057-01

对软件项目设计与开发的全过程进行有效的管理，不仅是要为了顺利实现软件的特定功能与性能，还要确保能够保质、保量、低成本的完成软件开发的任务，使软件在投入使用后也能够保持稳定性、可靠性、实用性和经济性。简单的说，软件设计与开发的过程就是要将需求转变为软件表达的过程，要想切实提高软件项目设计与开发过程管理的有效性，不仅要坚持正确的软件项目设计原则，还要明确软件的设计流程，在设计与开发的各个过程都采取行之有效的管理对策。

一、软件项目设计与开发的基本原则

（一）实用性

实用性指的是软件项目的设计与开发一定要能够满足现代企业经营管理的需求，能够促进企业的不断发展，要避免“形式主义”、“中看不中用”等问题，否则有可能导致企业软件开发资金的浪费，难以取得良好的投资回报效果。因此，在选择软件设计与开发技术时，不能过度追求先进性和高投入，而是应当在充分了解企业实际需求的基础上，结合企业的发展方向，充分满足企业在不同层次和环节上的管理需求，这也是决定软件开发项目成败的关键因素。

（二）先进性

毋庸置疑，在信息技术不断变化发展的时代背景下，先进性是软件项目设计开发过程中必须充分考虑的问题，这可以有效降低企业在未来的投入，避免未来在软件项目开发中的重复建设和系统升级等问题。因此，企业在进行软件项目的开发设计时，一定要面向社会经济的未来发展方向和人民生活需求的变化趋势，紧跟社会步发展的步伐，与信息技术、计算机技术、通信技术以及相关学科的发展方向保持一致，这样才能不断推动社会的进步。

（三）经济性

任何一个软件项目的设计与开发，都必须充分考虑到投入产出比的问题，力争用最小的经济投入获取最大的投资回报，实现最好的软件开发设计效果和更高的经济效益，这也是软件开发企业的主要目标。因此，在保证软件开发质量的前提下，软件的开发费用需要控制在合理的预算范围之一，并尽量压缩，在设计开发过程中必须要考虑到软件在后期运行维护过程中的费用投入，实现软件项目设计与开发全过程费用的节约。

（四）系统性

在软件项目的开发设计中，一定保证其整体功能的完整性，既能满足企业在整体上的管理需要，设计与开发的系统必须能够全面、完整覆盖企业管理的软件信息系统，又要能够满足采购、生产、销售等个别部门的管理需求，便于各个部门之间信息数据的传递和衔接。此外，还应当制定系统的软件项目设计与开发的管理规范，如开发文档的管理规范、报表文件规范、数据格式规范等，这是确保软件系统开发和操作水平的重要条件。

（五）可靠性

为了充分保证软件项目系统运行的高效、平稳和准确，不仅要保证软件系统在正常运行状况下数据传递的准确性和系统运行的可靠性，还需要确保软件系统项目在非正常状态下的可靠运行，因此在软件项目的开发设计过程中要提前针对一些紧急情况制定相应的应对策略。一个优秀、可靠的软件系统，必然是一个灵活的系统，即使在软、硬件环境发生故障时，仍旧能够保持部分使用或正常运行。

二、软件项目设计与开发的全过程管理

（一）软件项目设计与开发的启动

在软件项目的设计与开发过程中，实施全过程管理的第一个阶段就是项目的启动。在软件项目的启动阶段，首先，要明确软件项目设计与开发的目的，并在软件开发与软件使用的双方协议或者合同中进行约束，并对软件设计的主题、工程量进行量化，合理确定软件项目开发和设计的阶段目标和周期。其次，要加强同软件用户的充分沟通，了解用户的软件使用需求，理清软件记录的关键点，制定出完整的软件设计与开发流程；再次，对于在调研过程中所获取的原始资料，一定要进行加工处理，理清相关的约束条件和非功能性的客户需求，确保软件开发与建设项目具有很强的可实现性。

（二）软件项目设计与开发的规划

软件项目的规划，是软件设计与开发过程中比较复杂的阶段，也是决定软件开发质量和开发水平的关键，做好软件项目的整体规划将会为整个软件项目的运行奠定良好的基础。具体说来，软件项目规划主要包括项目预算、风险分析与预测、进度管理、质量控制等内容，在编制软件项目的开发计划时，一定要理清各个开发环节之间的关系，并制定出完整、科学的项目计划书，以期为软件项目设计与开发的全过程管理提供相应的参考依据。

（三）软件项目设计与开发的实施

软件项目实施阶段的有效管理，其目的就是要保证软件项目安装在预先设置的计划上正常运行，确保项目不要偏离预定的开发进程和设计目标。在软件项目的实施阶段，一定要按照软件项目的初步规划进行，并在实施过程中，增强对软件项目开发的有效控制，确保成本支出控制在相应的预算定额之内。同时，要对软件项目开发的成果进行动态的监控，随时与原先的计划过程进行比较，对于出现的偏差或缺陷要及时进行调整，确保各项软件开发指标和系统功能的顺利实现。

（四）软件项目设计与开发的结束

一个完善的软件项目管理过程，必然离不开软件项目的结束，这时相关人员要进一步确认软件项目在设计与开发过程中取得的成就，做好软件项目的交接、评审等工作。

三、结语

总之，为了提高软件项目设计与开发的质量和水平，软件设计人员需要首先认识到软件质量的重要性，树立应有的软件项目质量管理意识，要坚持正确的软件设计与开发原则，懂得加强过程管理与控制，同时还要对风险控制、配置管理等环节给予足够的重视，采用科学的技术方法和先进的管理技术来提高软件项目质量管理的有效性。

参考文献：

[1]李勇华，骆启武，付春燕.基于问题管理提升软件项目过程质量的实践[J].计算机与现代化，2007，4.

[2]商惠华.基于过程改进的软件质量管理模型[J].计算机工程与设计，2011，5.

软件测试过程管理 篇4

1 中小软件企业软件过程管理概述

1.1 中小软件企业特点分析

在我国软件产业中, 中小软件企业占据着较大的比例, 其主要特点是熟悉行业需求, 能够对优势业务领域加以有效把握, 执行力高, 管理快捷清晰, 组织结构简洁, 响应速度快等。但是中小软件企业也存在一定的劣势, 其具有较高的维护成本, 总收入中软件销售收入占据的比例低, 经验到制度的转化程度不高, 依赖性强, 制度约束力不高, 人员流动性高以及人力资源不足等。

1.2 软件过程概念

软件过程主要指的是软件开发人员在对软件以及相关的产品进行开发与维护时, 其形成的方法、实践、行为以及变化过程。一般在对软件过程进行管理时, 必须要确保软件产品的质量, 加强其开发与维护过程的质量, 将方法, 工具以及人员进行有机结合, 从而确保软件产品的质量, 提高管理的水平。

2 中下软件企业软件过程管理的改进方法

2.1 加强质量保证与配置管理

一个软件项目的配置项包括该项目的所有相关资料, 如安装程序、工具、代码以及文档等, 配置管理良好是保证软件一致性的重要前提。因此对配置管理进行合理计划, 并对配置管理软件进行恰当选择, 统一管理软件版本, 制定基线配置项变更控制流程, 能够确保软件开发与管理过程的合理性, 提高软件过程管理以及软件产品的质量。在改进软件过程时, 中小软件企业可以从以下几个方面进行考虑:一是在对软件进行测试时, 侧重于控制和检查软件产品的质量, 并且在保证质量的同时, 严格检查和控制软件过程。二是质量保证由专人进行, 从项目计划以及阶段成果等方面进行检测, 对质量问题进行跟踪和记录, 从而有效提高软件产品的质量, 确保产品质量的维护性以及延续性。

2.2 选择重点, 优先突破

在对软件过程进行改进时, 必须要对其重点领域进行选择, 循序渐进。由于软件过程改进是对现有的软件开发与管理过程进行改善, 这对于企业管理人员以及开发人员而言, 具有较大的难度。因此在软件过程改进过程中, 企业可以有针对性地选择改进重点, 逐渐突破, 从而确保软件改进过程的合理性以及科学性。此外, 从软件开发过程而言, 软件企业不同, 使得软件项目开发的过程也不尽相同, 在软件开发过程中, 其编码、设计以及需求等阶段受企业开发人员的综合能力、知识经验以及企业自身的技术水平的影响, 因此必须要对软件过程的相关部分进行重点选择, 有效突破。

2.3 加强自评估

中小软件企业为了保证软件过程的完整性以及规范性, 往往会对软件过程进行盲目改进, 无法对自身软件过程的阶段和水平进行全面清晰的分析, 导致实施的效果低下。因此, 中小软件企业在对自身的软件过程进行改进时, 必须要加强自评估, 有效采用某磐软件度量方法, 利用定量和定性相结合的方式, 提高软件过程状态的评价。此外, 中小软件企业可以在组织内部对岗位的人员进行不同选择, 确保全体人员能够参与到软件的评估过程中, 从而保证软件过程的合理性和准确性。

2.4 重视个体软件过程改进

开发人员作为软件企业中的主体, 其工作计划的恰当性、缺陷率、时间利用率和编码质量的高低等都会影响组织软件过程和软件质量。因此为了提高开发人员的工作效率, 确保软件过程的管理质量, 必须要重视个体软件过程的改进工作。一般个体软件过程具有完整的规程、表格以及方法, 其能够对软件开发人员的工作方式进行改进、管理和控制, 对开发人员计划、管理和度量自身的工作具有指导作用。个体软件过程改进能够对时间利用的情况进行记录, 从而有效掌握时间利用率以及工作的效率;同时能够利用管理缺陷, 有效控制软件缺陷, 并提高相关人员的工作能力。

2.5 合理利用辅助工具

一般而言, 软件过程管理及其改进在很大程度上属于管理的过程, 需要遵守一定的规则, 充分合理利辅助工具, 能够有效提高软件过程管理的水平和质量。就目前而言, 软件企业常用的软件类别包括缺陷管理工具、软件测试工具、配置管理工具以及项目管理工具等, 这些工具具有完善和强大的功能。因此企业能够从自身的实际情况出发, 对这些软件工具进行合理选择与利用, 从而提高软件过程管理的水平, 增强企业的综合竞争实力, 实现企业的可持续发展。

3 结束语

一般来说, 软件过程改进是一个循序渐进的过程, 中小软件企业必须要不断积累和丰富自身的经验, 对软件过程管理进行持续改进。同时, 中小软件企业在对软件过程进行管理和改进时, 必须要加强质量保证与配置管理, 选择重点, 优先突破, 加强自评估, 重视个体软件过程改进, 合理利用辅助工具, 从而提高软件过程管理的水平, 实现自身的可持续发展。

参考文献

[1]楚书来, 于文新.小规模软件企业软件过程管理与改进策略研究[J].黑龙江科技信息, 2012, 02:199-200.

[2]田丽从, 李铁牛, 彭宏.中小型企业软件过程改进方法研究[J].计算机应用与软件, 2011, 04:208-211.

[3]李楠.我国中小软件企业实施CMM改进软件过程的研究[J].中国城市经济, 2011, 26:129-130.

软件过程改进 篇5

过程改进的实施保证了一个项目软件研发能够达到较高水平，其意义不仅仅是对软件开发的过程进行管理，同时也最大程度地降低了企业的成本，产品质量和用户满意度也有所提高，是一种高效的管理方法。

介绍了软件过程改进的基本理念，对sPI中的CMM和CMMI进行了阐述，同时作了简单的对比。

关键词：软件过程;过程改进;CMM;CMMI

1、过程概念

要想开发出客户需要的产品，就必须使用合适的方法、技术以及工具。

过程即是人、方法、技术和工具这4项关键因素的集合。

过程它不单单是一堆文档，有效的过程环境还包括了过程的定义、过程的培训、过程的监控与强制三个方面。

人们用以开发和维护软件及其相关产品的一组活动、方法、实践和变换被定义为软件过程。

过程改进(Process Improvement)：是指根据企业的现状及发展需求，优化流程制度，努力提高人们在过程中的工作能力，最终“提升产品质量、生产率并降低成本”。

过程改进是企业谋求进步的需要。

软件过程改进(SPI)是一个长期的投资。

定义清晰的、可测量的目标，对提供指导和帮助改进开发的策略来讲是必要的，也为改进结果的客观测量提供了可能。

SPI的基本理念是质量形成于过程。

过程改进能够带来效益。

节省资金和商业改善措施可以将软件过程改进和商业结果联系起来，这些改进又可以融合到软件过程改进中。

这些因素包括：产品质量的提高、上市时间的缩短和生产率的提高。

从改进后的过程对软件质量的影响可以看到软件质量的提高，从而导致使用该软件的产品或服务质量的提高。

产品质量的提高最终可以减少产品的缺陷、提高满意度、减少退货以及避免媒体舆论的压力等。

成熟的过程有助于采用有效的方式引进新技术，利用这种方式可以更快地把新技术引入到产品中，从而获得竞争上的优势。

2、核心原则

软件过程可以定义为对整个软件生命周期的管理与工程化过程及支持进程的规范说明。

过程的使用者为软件工程师和项目经理，过程的结果则是软件程序、系统以及文档。

软件过程改进的要求导致了软件过程重要性的提高，从而产生过程分析和评估的方法。

注重问题、强调知识创新、鼓励参与、领导层的统一和计划不断地改进是SPI的5条核心原则，是从实践中发展而来、相互关联的SPI哲学，对SPI工作具有非常重要的指导作用。

软件过程改进成功的关键因素在于我们应当像对待真正的“项目”一样去看待软件过程改进计划，也就是说，我们要为其分配资源、进行管理、编写阶段性的计划、制定质量以及配置管理计划等。

过程改进的核心是解决问题，它为过程改进人员指明了目标、明确了方法。

“改进是一种知识的创新，而SPI是受知识驱动的”。

它强调了知识创新在SPI中的重要性，同时也指出注重知识创新的同时对知识的传播和扩散也不容忽视。

改进活动可以用作一个模型和一个机制，用来试验所期望的各种不同的过程和行为。

一个典型的原则是运用改进尘埃来试验修订的管理过程，如新版的计划、跟踪等等。

新的方法可能因为影响太小而“失败”。

这种意义上的失败意味着新的过程不如预期的那样好，这是第一次试验一个新的或修订的过程时一个共同缺点。

任何这样的指导原则应该被文档化，以改进活动战略行动计划中的指导部分。

3、软件能力成熟度模型(CMM)

CMM——能力成熟度模型，最早的前身是1986年由美国卡内基一梅隆大学的软件工程研究所(Software En-gineering Institute，SEI)受美国国防部委托研制的一种评估软件承包商能力的办法。

在SEI中，CMM被定义为：对于软件组织在定义、实现、度量、控制和改善其软件过程中各个发展阶段的描述。

它的意义不仅仅是对软件开发的过程进行管理，更重要的是它还是一种高效的管理方法，有助于组织最大程度地管理和降低开发成本，提高软件质量和用户满意度。

软件过程的不断改进是基于许许多多小的、不断进化的步骤，并不是一次革命性的创新且能在较短时间内实现的。

CMM主要用于软件过程的改进(SPI)、软件过程的评估(SPA)和软件能力评估(SCE)。

CMM组织如图1所示，有5个等级，旨在增加软件过程成熟度行动按优先级排序。

CMM由低到高分为5个级别，分别是初始级、可重复级、定义级、管理级和优化级。

成熟度等级是向成熟软件组织前进途中的阶梯，每一个成熟度等级都为过程继续改进提供一个基石。

在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。

每一较低级别是达到较高级别的基础。

每个成熟度等级都刻画了不同软件组织所处特定过程的本质或关键属性。

4、能力成熟度模型集成(CMMI)

CMMI是CMM模型的最新版本。

1981年，美国卡内基一梅隆大学软件工程研究所(SEI)，应美国联邦政府的要求开发一种用于评价软件承包商能力并帮助其改善质量的方法。

浅谈软件过程的改进 篇6

关键词：软件工程；SEI能力成熟模型

中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)12-21705-01

Discuss the Improvement of the Software Course Simply

WANG Wen-li

(Guangdong Lingnan Institute of Technology,Guangzhou 510663,China)

Abstract:Improvement of soft project in a problem land that is explored constantly soft project researcher in whole world. First of description of this text are organized unripely and a ripe difference while organizing, key definition and describe SEI ability ripe 5 ripe grade of model, propose one common system improvement model to develop course.

Key words:Soft project;Ripe model of SEI ability

1 引言

信息系統生命期(SDLC)由活动、产品和资源组成。活动是在一个SDLC中进行的动作，并且可以是高层分析至程序的编译或者测试之类的任何工作。产品是在SDLC期间产生的文档和程序。资源由人员、时间、金钱和设备等组成。在一个SDLC期间要使用它们，SDLC在某些文献以及讨论开发的研究中也看成是一个软件的过程。

全世界的软件工程研究人员都致力于改进软件过程。SEI（Software Engineering Institute）的能力成熟模型是一种软件过程改进的途径。本文基于这一框架来讨论软件过程的改进。在世界范围内有许多其他实践着的软件过程改进。本文选择这一途径进行讨论，是因为大量的出版物上有有关的文章、讨论及批评，并且在美国和许多其他地区普遍接受了它。在1986年，CMU软件工程研究所（SEI）在Mitre公司的帮助下，开始发展一种有助于开发人员改进他们的开发过程的系统开发过程成熟度框架。最初称为软件过程成熟度模型。

2 不成熟和成熟的系统开发组织

一个组织希望建立起改进信息系统开发过程的实用的目标时，首先必须理解不成熟系统开发组织和成熟的系统开发组织之间的差异。在一个不成熟的系统开发组织中，通常开发人员即兴提出系统开发过程。即使详细说明了一个特定的开发过程，也很少会坚持或强化这一开发过程。

描述不成熟系统开发组织的最好词语是“反应”。通常管理人员关注解决危机和“救火”上。经常性地超支，因为从来没有真正地估计过进度和预算。当人为的期限迫近时，软件产品功能、性能和质量往往受损。

最后，一个不成熟系统开发组织缺乏有目的的办法来评估软件产品质量、或解决发生的产品问题或过程问题。为保持或接近进度，经常减少取消试图提高软件产品质量的活动，例如用户介入，设计评审和测试。

成熟的系统开发组织可能在全机构范围内管理系统的开发和维护。管理人员可以准确地把系统开发过程传达给开发人员，开发人员根据计划的过程实施相应的活动。规定的开发过程是可用的，并和进行工作的实际途径相一致。通过受控的试验性测试和效益分析，确定必须改进过程时，就更新规定的开发过程。在项目范围内和贯通组织范围中都理解开发人员的作用和责任。

成熟系统开发组织的管理人员不断地监视系统产品的质量个制造产品的过程。坚持一个目标明确的、定量的方法来评估系统产品质量和分析产品的问题和过程的问题。基于历史上的行为制定进度和预算，因此是现实的，通常可以达到。

最后，一个成熟的系统开发组织使用一个纪律严明的系统开发过程，因为全体参与人员理解如此做的价值，企业的基础结构设施支持他们达到这一点。

过程改进（例如SEI的CMM）的目的是支持软件开发管理人员，开发人员和业务工作。而不是去责备和羞辱他们。软件过程改进的组织软件开发组织的管理人员之所以失败，常常就是因为害怕承认了软件开发过程真实情况所带来的后果。

3 SEI能力成熟模型的5个成熟阶段

一个系统开发过程是开发人员用来开发和维持信息系统的活动、方法、实践和变换的集合。如果一个软件的开发组织是成熟的，在其组织内具有较好的定义，并一贯地使用于开发过程。通过政策、标准和组织结构体现的系统开发过程是这种成熟性的自然产物。不要将成熟度和多年处于的状态等同。对于现在的讨论中，把成熟度等同于智慧的成熟和在应用知识上的智慧。所以一个软件开发组织成熟就相当于该组织能把通常认可的有关软件开发过程的知识应用于自己的软件开发工作中。

坚持连续地改进过程的思想，CMM为软件为软件组织的演进步伐提供有五个成熟度的框架，如图1所示。当软件组织达到一个成熟度级的框架时，每一个成熟度级为连续的过程改进中转向下一个成熟级打下基础。每一级都假定软件组织已经达到了在CMM指南规定的所有较低级别的要求。图2总结由CMM描述的关键过程区域。

图1 SEI能力成熟模型 图2 在能力成熟模型中的关键过程区域

第1级，初始级软件组织的一般特征是没有开发和维持系统的稳定的环境。这种组织极少能做到使软件开发按一个有序的开发过程进行。结果是发生一系列开发危机，一遇到问题，开发组成员放弃计划好的过程，并回到反复编码和测试。

第2级，可重复级软件组织的一般特征是有食用的政策和过程，并在系统开发中坚持使用。新项目的计划和承诺是基于相似的项目的经验。基本的管理控制是属于每个开发项目的一部分，管理人员跟踪费用、进度和识别问题。

用户需求和开发出来满足要求的工作产品是按基线进行，并控制其完整性，项目遵循标准；然而在第2级的组织中项目之间的过程可能不同。因为可以重复过去的成功经验，所以其项目计划和控制是稳定的。这些组织的过程能力是有规律的。

第3级，定义级按软件组织在相继项目上的稳定性和可重复性，所代表的全组织的标准和一致的系统开发过程来标志。这个过程的编写成文档，包括一个开发人员的过程部件和一个管理过程的部件。由于标准化，组织作为一个整体应当能够进行有效的系统开发时间。

因为在这一级的开发组织有一个很好的定义过程，管理人员对每个项目的技术过程有良好的洞察力。除此以外，在组织的标准化系统开发过程中包括了以下各方面的指南：(1)标准；(2)建立可读性准则；(3)开发输入；(4)完成工作的步骤；(5)工作验证步骤，例如同事评估；(6)开发输出；(7)决定完成准则。

第4级，管理级是建立了系统开发产品和系统开发过程的定量质量目标的几个为特征的组织，对于遍及所有项目的重要的系统开发过程都度量生产率和质量作为自制的度量程序的一部分。

整个组织维护一个过程数据库以收集和分析来自各项目确定过程的数据，这些组织的范围的度量建立了一个定量的基础，用于评估任一项目的过程和产品。每个项目通过在他们行为中减少与组织的可接受数量界限的差别来控制他们的过程和产品。在一个项目过程实施中有实质性的变动和随机变动加以区别，当已知的过程界限超出后，管理可以采取行动来纠正这种情况。第4级允许一个组织在确定的定量范围内对系统开发过程和产品质量具有预测趋势的能力。

第5级，优化级通过整个系统开发组织致力于连续的过程改进为标志。组织有适当的途径识别开发过程弱点和产品弱点，并用零缺陷目标化它们。过程数据库（来自第4级）用来对新技术和系统开发过程的变动进行费用—利益分析。探索最佳系统开发实践的革新在整个组织内部识别并传播。

项目小组分析缺陷以决定原因，对过程进行评估以避免已知类型的错误重现，并传播其他项目的经验。因为系统开发中低效益的主要原因是重复工作，所以减少重复工作可以说是每一级的目标。但是在第5级，它成为一个主要的关注点。

4 一个基本的系统开发过程改进模型

通过遵循这个简单的系统开发过程改进模型——ICASE，一个系统开发组织可以来达到其希望提高CMM的级别的目的。

I=调查，调查组织的系统开发过程的现有状态。在我们可以确定移向下一个级别之前，我们需要知道我们处于哪里。

C=建立，在组织内部建立一种意想。使开发人员和管理人员进入改进系统开发过程的概念中去。

A=行動，在组织中对必须要求的过程改进行动建立一张清单。

S=选择，选择一个计划以达到要求的行动。

E=执行，提交执行计划必须的资源。

最后，当开始并不断在CMM级进行改进时，反复这一过程。

5 小结

本文给出了对软件过程改进的概述。由于许多因素使软件创建的过程需要不断的改进。软件过程改进就是试图这样做的活动。按SEI能力成熟模型——给出软件开发成熟度的五个级别，给出了不成熟和成熟软件开发环境。在这之后，一个一般的系统开发过程改进模型，用ICASE缩写表示。本文简短地讨论ISO 9000过程改进标准作为结束。

如前所述，SEI的CMM不是仅有的系统开发度量模型。还有ISO 9000系列标准，以及可以通过全世界的咨询组织获得几个专利的方案。然而，CMM可能是所有系统开发度量模型当中编写最流行的文档方法。

参考文献：

[1]国刚.UML与Rational Rose 2003软件工程统一建模原理与实践教程[M].电子工业出版社,2006.

[2]符长青.信息系统工程监理[M].机械工业出版社,2006.

[3]周爱民.大道至简——软件工程实践者的思想[M].电子工业出版社,2007.

[4]赵池龙.软件工程实践教程[M].电子工业出版社,2005.

软件测试过程管理 篇7

“精简并行过程” (Simplified Parallel Process, SPP) 是基于CMM以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”, 它由众多的过程规范和文档模板组成。SPP主要用于指导国内IT企业持续地改进其软件过程能力。

此处“精简并行”的含义是:

(1) 对CMMI 3级以内各过程域的内容和要求作了“精简”处理。

(2) 在产品生命周期之内, 项目管理过程、项目研发过程和机构支撑过程“并行”开展。

SPP模型把产品生命周期划分为6个阶段, 分别为:产品概念阶段, 记为PH0;产品定义阶段, 记为PH1;产品开发阶段, 记为PH2;产品测试阶段, 记为PH3;用户验收阶段, 记为PH4;产品维护阶段, 记为PH5。

在SPP模型中, 软件项目的过程有3大类:项目管理过程、项目研发过程和机构支持过程。上述3类过程可以细分为19个主要过程域, 分布在PH0到PH5的各个阶段。

项目管理过程包含6个过程域, 分别为:立项管理、结项管理、项目规划、项目监控、风险管理、需求管理。

项目研发过程包含8个过程域, 分别为:需求开发、技术预研、系统设计、实现与测试、系统测试、Beta测试、客户验收、技术评审。

机构支撑过程包含5个过程域, 分别为:配置管理、质量保证、培训管理、外包与采购管、服务与维护。

2 基于SPP的软件过程管理实践

2.1 项目案例

项目名称:云南某糖业集团综合管理信息系统。

项目概况:本项目主要内容为在充分分析用户实际需求基础上, 采用面向构件的设计方法, 基于J2EE系统架构, 开发并实施“云南某糖业集团综合管理信息系统”, 实现该糖业集团从甘蔗原料的种植、运输、生产到成品糖的销售全面的信息化管理。包括以下子系统:财务管理、农务管理、OA系统、生产管理、采购管理、库存管理、供应商管理、销售管理、人力资源管理。

2.2 过程模型定义

SPP模型的3类过程贯穿了产品的整个生命周期, 19个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特征, 适当地裁剪或扩充SPP的过程域, 很容易制定出最适合于本产品的过程模型。

我们根据项目系统功能较多, 涉及面较广、项目开发时间较紧等特点, 对SPP进行裁剪, 定义了如表1所示的过程模型。

2.3 软件项目过程管理实施过程

2.3.1 项目计划

(1) 由项目经理组织项目计划讨论会, 在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估, 根据工作量和工程需求初步确定总体开发计划和发布时间;

(2) 写完成后发送给项目经理、相关的开发人员和测试人员;

(3) PPQA确认所有相关文档经过了评审并都已经commi到CVS。

2.3.2 需求开发与管理

(1) 由需求分析负责人统一接收糖业集团客户的相关规范和新需求, 需求分析负责人将规范和新需求转发给项目经理、相关的开发人员和测试人员, 同时commit到CVS;

(2) 需求分析负责人、项目经理仔细阅读规范与需求后, 对规范和新需求进行研究, 并就难点和疑点进行讨论, 整理出重点内容, 并将重点内容发给项目经理、相关的开发人员和测试人员, 同时commit到CVS;

(3) 项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论, 确定需求的具体含义以及最终实现的需求和功能点;

(4) 项目经理根据规范、需求和开会讨论结果编写出《需求规格说明书》与《功能列表》, 测试负责人 (或专门的需求分析负责人) 对文档进行检查并修改完善, 然后commit到CVS;

(5) PPQA (文档管理专员) 确认所有相关文档经过了评审并都已经commit到CVS。

2.3.3 设计与实现阶段

(1) 技术经理构思系统设计, 项目组开发成员一起讨论系统的设计, 对设计形成较为清晰的思路;

(2) 技术经理负责编写概要设计文档, 与开发团队成员与测试负责人一起讨论概要设计;

(3) 概要设计完成后, 技术经理编写详细设计文档、数据库设计文档和编码规范, 各模块负责人负责编写所负责的模块进行详细设计;

(4) 设计文档编写完成后, 发邮件通知项目经理、测试负责人、相关开发人员和测试人员;

(5) 技术经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查, 将建议和意见以邮件的形式反馈给模块负责人;

(6) 模块负责人收集邮件中的修改建议并对设计文档进行修改, 同时回复邮件说明详细设计修改情况, 修改后的详细设计commit到CVS;

(7) 对设计存在争议或出现明显不合理的设计, 召开一个小型会议对异议进行讨论, 有效解决设计所出现的分歧;

(8) PPQA对开发最终修改的详细设计计划进行检查, 并确认所有文档都已经commit到CVS。

2.3.4 系统测试阶段

(1) 在项目的设计阶段, 测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案;

(2) 测试方案编写完成后, 发邮件通知技术经理、项目经理、相关开发人员和测试人员;

(3) 技术经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查, 技术经理和项目经理对测试方案进行总体性的审查, 而各模块负责人则负责相关模块或功能的测试方案的审查, 将建议和意见以邮件的形式反馈给测试负责人;

(4) 测试负责人收集邮件中的修改建议并对测试方案进行修改, 同时回复邮件说明测试方案修改情况, 修改后的测试方案commit到CVS;

(5) PPQA对最终修改的测试方案进行检查, 并确认所有文档都已经commit到CVS。

2.3.5 系统部署及试运行阶段

(1) 编制计划。与用户方项目实施负责人商议具体测试及试运行时间, 地点, 人员等安排, 项目组编制《测试及试运行计划》。

(2) 签署计划。用户签署《测试及试运行计划》, 进一步确认测试及试运行安排。

(3) 发测试及试运行通知。在测试及试运行开始前2天, 按照签署的《测试及试运行计划》, 将时间, 地点, 人员等信息通知用户实施负责人。

(4) 搭建环境及数据准备。在试运行开始前搭建好软件环境、硬件环境、网络环境、调通线路;检查软件、硬件、网络、线路等各个环节是否有问题;

(5) 组织测试及试运行。用户相关各级领导给予全面配合, 组织相关人员进行测试及试运行。

(6) 测试及试运行总结。测试及试运行完成, 总结试运行中设备、软件的运行情况, 总结试运行中业务流程和操作环节的情况, 以书面总结形式将测试及试运行结果通知相关负责人。

2.3.6 系统培训阶段

系统使用人员计算机应用水平较低, 有部份人员还不会使用电脑, 系统培训阶段工作是整个项目实施工作中比较重要的工作, 此阶段的培训工作中将用户参加产品培训的人员划分为3个层次:决策层、技术层、操作层。

3 结束语

“云南某糖业集团综合管理系统”应用范围包括集团总部、8个分公司和子公司, 具有系统功能较多, 涉及面较广、项目开发时间较紧等特点, 严格、合理的项目过程管理将是项目成功的关键, 我们采用了上述基于SPP的软件项目过程模型, 结合该项目特点进行适当裁剪, 并创建了一套符合实际情况的实施方法, 有效地对软件项目过程进行了管理, 确保项目质量及进度, 成功开发出一套糖业集团综合管理系统。

摘要：对CMM及CMM精简并行过程进行了分析, 结合具体的项目案例, 在基于CMM精简并行过程模型基础上进行裁剪, 建立了符合项目实际情况的过程管理模型, 提出了一套符合项目实际情况的软件过程管理实施方法, 有效地对软件项目过程进行了管理, 保证了项目的质量及进度。

关键词：CMM,SPP,软件过程管理

参考文献

[1]RUZHI.http://www.mypm.net/blog/user1/runzhi/archives/2006/1256.html, 2006.

[2]霍英.面向小型软件企业/小型软件项目的CMM应用研究[J].计算机应用研究, 2007 (2) .

[3]林锐.软件项目管理与精简并行过程[J].计算机系统应用, 2004 (8) .

[4]SELIYA, N1, KHOSHGOFTAAR, T1M1, ZHONG, S1Analyzing soft-ware quality with limited fault-p roneness defect data[C].1Ninth IEEE International Symposium on High-Assurance Systems Engi-neering, 2005.

软件测试过程管理 篇8

1 软件测试与软件测试管理

1.1 软件测试的现状

通常,软件测试是针对软件编码进行的,没有把软件测试活动贯穿到软件项目开发过程的各个阶段。而实际上,在软件开发的每个阶段都有可能发生缺陷,如果前一阶段的缺陷没有及时地检查出来并得到很好的解决,那么,这个缺陷很自然地会导致下一阶段的工作出现偏差和错误。所以软件测试不应仅局限于代码的测试,应贯穿于软件的整个生命周期过程之中。

1.2 前置测试

前置测试是一个将测试和开发紧密结合的模型[1]。它的基本思想包括:

1)对开发过程中每一个可交付的产品进行测试;

可行性研究报告、需求说明书、设计说明书、源程序代码等都是测试的对象。

2)验收测试和技术测试相互独立;

前置测试将技术测试和验收测试分开进行,从不同的角度分别验证系统是否能够按预期所设想的那样正常工作,这样可以更有效的保证产品的质量。

3)测试和开发紧密结合;

前置测试将测试执行和开发结合在一起,并以编码—测试—编码—测试的方式重复进行。

4)在设计阶段进行测试计划制定和测试方案的设计。

1.3 软件测试管理

软件测试管理是一种活动,可以对各阶段的测试计划、测试用例、测试流程进行管理、跟踪、记录其结果,并将其结果反馈给系统的开发者和管理者,同时将测试人员发现的缺陷记录下来,生成缺陷报告并对之进行管理[2]。

2 基于过程的软件测试管理系统(P-TMS)的研究

本文主要借鉴前置测试的思想,将软件测试融入软件开发的各个阶段,提出了基于过程的软件测试管理系统(P-TMS)的工作模型。并针对该工作模型对系统的功能结构进行了详细的设计。在该模型基础上构建的软件测试管理系统使得开发工作中每一环节都有测试工作做保障,并使得测试人员在开发初期就可尽早的投入到软件测试工作中,尽可能少的将开发初期的的缺陷带到后继的开发工作中,对整个软件的开发及后期维护工作起到至关重要的作用。

王立娟:基于过程的软件测试管理系统的研究与应用

2.1 P-TMS的工作模型

P-TMS的工作流程模型如图1所示。

图1所示的工作流程描述如下:首先,系统分析员将某一需求项提交到需求库,并指定需求审核员;审核员接到系统自动发出的通知后,对提交的需求进行审核,审核通过后应改变该需求的状态,同时发送通知给测试设计人员;测试设计人员参照需求项描述和验收标准,设计测试用例。当所有的需求审核完毕后,即可形成需求规格说明书,同时测试设计人员也就完成了测试用例的设计。此时,软件设计人员可根据需求规格说明书进行系统功能的分解,确定功能项并最终形成设计说明书。测试设计人员再根据所分解的功能项并参照设计说明书进行测试用例的设计。同时,程序员根据设计说明书或测试用例进行代码编写。当产品编码完成后,由测试设计人员根据编写好的测试用例对源程序代码进行测试。当测试中发现缺陷时,则将缺陷提交给测试主管,测试主管对缺陷予以确认并分类后,再分别转交给对应人员进行修改,即完成了P-TMS的整个工作流程。

通过上述分析可以看出,与传统的根据设计规格说明书进行编写测试用例的设计思想相比,P-TMS工作模型的优点主要表现在如下几个方面:

1)测试用例的设计工作被提前进行,可以根据所识别的需求项动态地、逐步进行测试用例的设计,这样不但能较早地发现需求项中可能存在的缺陷,而且可以充分利用测试设计人员这一资源,为设计测试用例节省时间,从而提高项目开发的效率。

2)软件设计人员所进行的功能项分解活动和测试设计人员所进行的依据功能项设计测试用例的活动是同步、交替进行的。这一方面可以节省设计时间,另一方面也能够尽早地发现软件设计中的缺陷,从而降低软件开发过程中所产生的缺陷对软件项目开发的影响。

3)该工作模型支持了测试驱动开发的工作模式。开发过程中的每个功能都有相应的测试做保障,这样可以减少后期维护工作的工作量,降低了软件开发与运行的成本。

2.2 P-TMS的功能

P-TMS主要包括项目规模跟踪管理、测试计划管理、需求跟踪管理、测试用例管理、缺陷管理、报表做成及系统管理等功能。

3 P-TMS实现中应用的关键技术

3.1 跟踪矩阵

跟踪矩阵提供了跟踪能力链,使得被跟踪的信息在使用全过程中得到充分地控制与应用。P-TMS分别提供需求项和功能项与测试用例集(TCS)间的跟踪管理,跟踪管理通过跟踪矩阵技术加以实现。

本系统在需求阶段采用需求跟踪矩阵,在设计阶段采用功能跟踪矩阵,分别对需求项(Requirement Item,RI)和功能项(Function Item,FI)进行跟踪管理。需求跟踪矩阵和功能跟踪矩阵如表1和2所示。

由于功能跟踪的作用和需求跟踪矩阵相似,所以对功能项的跟踪矩阵,在此不再赘述。

这两种跟踪矩阵之间的关系:测试用例主要来源于需求和设计阶段,需求项的变更及设计的修改常常都会引起测试用例的变更,所以对用例的跟踪实际上就是对需求和设计的跟踪。采用将需求项和功能项分别编号并建立相应的跟踪矩阵的方法,使跟踪矩阵中需求项和功能项与相应的测试用例集之间建立联系。这样,当需求项发生变更时,可查看需求跟踪矩阵,修改对应的测试用例集。同时,由于需求的变更往往会引起功能的变更,因此还要对与需求项对应的功能项(需求项与功能项的对应关系通过功能项表中的需求项编号加以实现)及其相关联的测试用例集进行修改。当设计发生变化时,只要跟踪功能项是否发生了变化,是否增加了新的功能项,根据功能项的变化,修改功能跟踪矩阵中对应的测试用例集,即可实现对功能项的跟踪。

4 结束语

基于过程的软件测试管理系统的设计工作已全部完成,目前正处于实现的后期阶段,并准备与本项目组开发的软件项目管理的其它模块,如需求管理、风险管理、进度管理、成本管理、质量管理、配置管理集成在一起,搭建成一个实用型的项目管理平台,使用户可以方便的使用。

参考文献

[1]黄龙水,黄诚学.软件测试模型介绍[J].舰船电子工程,2004(3).

[2]陈文海,秦晓.软件测试管理工具的研究与实现[D].北京:中国科学院研究生院,2003.

[3]吾守尔,斯拉木,荣涛,等.软件错误生命周期的研究及其应用[J].计算机与现代化,2003(2).

高校软件项目开发过程管理 篇9

进入21世纪, 随着软件工程学科的发展, 人们对软件开发过程管理的认识越来越深刻。管理是影响软件开发项目全局的因素, 而技术只影响局部, 许多问题不是出在不懂怎么做, 而是没有安排好, 做的次序不对, 或不知道如何做得更好。有效的软件过程管理, 有助提高软件的开发效率和生产质量, 降低生产成本。

目前软件开发深入各个领域, 高校作为国家重要的科研基地, 承担了大量的软件开发任务。高校软件开发组织不同于常规意义上的软件开发组织, 在软件开发过程上有其自身的特点和要求, 企业中已应用成熟的软件开发管理方法并不完全适用。为了适应这种特点, 必须结合高校实际, 对企业中软件开发过程管理方法做出适当的更改和调整。

1、高校软件项目开发的特点

高校软件项目开发多由教师和学生组织成临时团队协作完成, 其主要特点如下:

1.1 创新性强、研究性强, 项目难度大。

高校所涉及的软件项目, 和一般企业不同, 多属于前沿性的研究课题, 探索成分较多, 软件开发过程中, 需要查阅大量文献, 即时关注国内外研究动态, 软件需求经常变化, 修改较多。

1.2 开发团队成员新手多、人员流动大、管理经验欠缺。

教师和学生是高校软件项目开发的主力, 他们虽然有较好理论水平, 但实践经验非常不足, 对软件整个生存周期的管理体会不深, 管理意识薄弱。

1.3

高校软件开发项目和企业相比, 对于开发成本、用户意见、进度等方面的控制不如企业那样严格。

1.4 高校软件项目开发过程中, 经常会忽略测试阶段的工作。

开发人员的兴趣多集中在功能的实现上, 而对软件运行的性能关注不多, 预先测试工作很少, 这就造成事后不得不耗费大量力气去弥补。

2、高校软件项目开发的过程管理改进

基于上述特点, 笔者结合实际, 根据自己的实践工作经验, 对于高校软件项目开发过程的管理, 提出如下改进措施:

2.1 团队管理

团队管理要有纪律性, 分工明确, 责任清晰。可基于项目开展工作, 尽量采用扁平化的组织结构, 角色简洁, 不必要的角色设置及时删除并做优化调整。

2.2 文档管理

高校软件项目开发团队往往是基于某个课题成立的临时组织, 流动性大, 文档管理的不完善非常不利于知识的流动和传播。CMM作为软件过程管理的工业标准, 它的各个关键过程域对于文档的要求都严格细致, 高校软件项目开发过程中, 引入C M M过程规范可以有效保证文档管理的完整规范性, 但CMM管理复杂, 实际应用中, 需适当裁剪, 具体来说, 可以在开发的各个阶段设置几个结束点, 在这几个结束点上, 编写严格的规范的文档书写标准, 在结束点之前, 流水帐一样记录下所做所想, 将有关信息用更自由方式记录保存, 在某个阶段结束之后, 花一定时间来创建和对文档格式化, 只保留关键节点的文档, 从而有效节省文档开发工作量, 提高工作效率。

2.3 计划管理

项目启动之前, 应有大致实施计划。项目实施过程中, 项目负责人要不断对照原有计划进行工作调整。高校软件项目开发需求变更频繁, 同时, 软件开发自身的难度大复杂性大等特点也要求计划制订时不能跨越太长时间段, 要立足当前, 逐步推进, 逐步细化。高校软件项目开发在时间性上的要求要比企业弱一点, 要保证有充足时间完成研究过程, 但这并不是说高校软件项目开发就无时间限制, 在开发过程中, 可每隔两周进行一次小会讨论, 制订未来两周内详细的研究开发计划, 并对未来三个月内的工作做粗略规划, 下次计划的制订要紧密结合上次计划完成情况, 及时调整。

2.4 开发过程管理

在开发工作具体开始之前, 要制定详细的开发工作流程, 高校软件项目开发流程主要包括下面几个阶段:需求分析、系统设计、编码测试、收尾四个阶段。

2.4.1 需求分析阶段管理

和企业不同, 高校软件项目开发的需求除部分来源于客户需求, 更多的, 则来源于一些研究性课题研究的需要。这也导致高校软件项目开发的需求分析管理和企业有很大不同。高校软件项目开发的需求包括问题求解和需求确定两个部分。问题求解部分主要的工作是构思的形成、构思的筛选和概念的形成与评估, 其中, 牵涉大量国内外文献的研究和综述, 在构想确立的过程中要经常开会讨论, 由专家对构想进行初步评估, 全部审核通过后, 需由负责人撰写详细的问题求解报告, 在此过程中搜集整理的资料随同报告分类保存。需求确定阶段则针对问题求解报告, 编写详细的需求计划书, 有条件的情况下, 可采用一些快速开发工具针对需求设计开发原型, 开发原型应包括核心功能和关键难点的实现, 设计尽量的简单, 不求完善, 软件原型的设计可帮助预测需求的合理性, 以最快的速度得到需求反馈。需求分析书在最初设计时并不要求过分细致, 要抓住重点, 力求简单易懂, 在最终文档交付之前, 可进行多次迭代开发以尽可能的减少实际开发中的更改。

2.4.2 系统设计阶段管理

通用的建模工具如U M L可帮助进行系统整体设计。系统的分析报告应包括以下几个要点:系统整体的功能模块框架体系, 系统中的用户权限分析、系统整体运行流程和系统的数据结构构建体系, 此外, 还应包括关键难点的技术实现可行性。良好的系统设计可有效降低编码过程中的返工问题。

2.4.3 编码和测试阶段管理

高校软件项目开发中编码阶段, 最大不足是代码编写不规范, 变量函数的命名各成体系, 没有正式标准, 注释部分描写不清, 这就造成代码可读性差, 严重降低代码重用性。高校软件项目开发的另一大不足是对测试重视不够, 这就很难保证软件产品的质量和性能。结对编码对改善上述不足有很好效果, 由两人结对进行代码开发, 一人负责代码功能的实现, 另一人负责代码的可读性和运行的正确性和完善性。这样可有效提高代码编写速度, 使编写者更有信心, 同时可保证未来代码运行的正确性, 发现问题及时修改, 避免把所有问题积累到最后再做处理。在此阶段, 文档书写可以少一些, 关键部分有记录即可, 但代码要书写规范, 语句尽可能的精简清晰, 可读性可理解性要强。源代码的管理也是该阶段的一个重要工作, 常用的配置管理软件, 如CVS等可有效控制和管理版本的更改变动, 全过程配置管理, 有利于项目内统一的编码、测试, 保持一致性。

2.4.4 收尾阶段管理

在团队解散前, 收尾工作要做好, 整个过程中的文档和最终软件成果指定专人整理归类, 为后续开发和维护打下良好的基础。

2.5 跟踪管理

在软件项目开发过程中, 项目负责人的角色很重要, 要及时跟踪团队资源变更情况, 跟踪项目执行的范围和进展情况, 确定未做的有多少, 已完成的有多少。

2.6 培训管理

高校软件项目开发中, 可依据实际采用内外部培训、自我培训、专家指导等多种形式。培训内容要按具体情况展开, 一般来说, 新人培训应该包括组织内部已经形成的制度和纪律, 软件文档编写约定, 软件开发流程中的各项验收和管理标准, 团队的组织结构角色分工, 除此外, 可结合具体项目制订项目入门的快速指南。通过共同分析项目的目标和管理规范的必要性, 使分配的任务得到新加入的开发人员的认可, 有利于工作积极性的调动。

2.7 支持开发全过程的网络管理平台的构建

在有条件的情况下, 建立基于网络的软件开发全过程的协同工作平台可有效帮助提高软件开发过程的管理, 特别是对高校软件项目开发来说, 可在一定程度上解决开发团队缺少固定时间地点所造成的沟通缺失, 更好的保管归类开发过程的文档, 方便查询, 同时使团队成员对开发过程中的规范性有更深刻的理解。

3、结语

总之, 高校软件项目开发过程管理, 需从自身固有的特性出发, 一方面, 要逐步建立和完善规范化的管理模型, 另一方面, 在实际操作上, 要从现有环境和条件出发, 在项目不同阶段、不同团队和不同模块采用灵活多样的方法, 以期获得最佳的实践效果。

摘要：高校软件项目开发具有创新性强、变更频繁, 开发人员新手多、管理经验欠缺、流动性大等特点。其过程管理, 既要参照软件企业常用管理方式保证规范性, 同时又需结合自身特性赋予更多灵活性, 在开发的各个阶段, 需采取多种方式综合管理, 以平衡各方效益。

关键词：软件开发管理,敏捷管理,软件过程改进

参考文献

[1]张海藩.软件工程导论 (第五版) [M].北京:清华大学出版社, 2008

[2]萨默维尔, 程成, 陈霞.软件工程 (原书第8版) [M].北京:机械工业出版社, 2007

[3]唐俐威.软件开发的敏捷管理方法研究[D].哈尔滨:哈尔滨工业大学, 2006

软件测试过程管理 篇10

软件管理工程的发展, 经历了从20世纪70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代, 到20世纪90年代中期, 以CMM模型的成熟和日益为市场接受为标志, 已经进入以过程成熟度模型CMM、个体软件过程PSP和团队软件过程TSP为标志的以过程为中心的时代, 而软件发展第三个时代, 即软件工业化生产时代, 以20世纪90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础, 已经渐露端倪。

1 小规模企业软件过程管理现状

1.1 小规模软件企业特点。

小规模的软件企业或软件开发机构的数量在我国软件产业中占据很大的比重, 其突出的特点主要表现在具有灵活机动、响应速度快, 组织结构简洁、管理清晰快捷、执行力高, 把握优势业务领域、熟悉行业需求等方面。但具备这些优势的同时, 兼具有人力资源不足、人员流动性高, 规范程度不高、制度约束度低, 对于人的依赖性较高, 经验到制度的转化程度较低, 软件销售收入占总收入的比重较低、维护成本较高等缺点, 这也是小规模软件企业在管理过程中不容忽视的重要问题。

1.2 小规模软件企业应对策略。

如何最大限度地避免这些问题的产生呢, 除了一些不能改变的客观因素外, 软件过程管理与改进策略研究在其中占得分量也越来越重, 也越来被人重视和研究。提升软件过程的管理水平日益成为工业界和学术界共同的关注点, 软件过程管理是提高生产效率和保证软件质量的一个重要方法。在产品开发的整个生命周期中包括一系列复杂的活动, 和其他管理过程类似, 现代软件过程管理工作也逐渐趋向复杂。根据企业的实际情况和发展需求, 优化流程, 努力提升人们在过程中的工作能力, 从而提升产品质量、提高生产率并降低成本, 这是软件过程改进的目的。

具体到软件过程来讲, 软件开发组织经常会遇到诸如项目经常会延期, 任务完成进度难以控制、开发人员不会编写和利用软件文档、需求难以控制, 疲于应付需求的变更、软件质量难以保证、软件版本混乱、没有有效的项目管理方法和实践指导等问题, 从而影响软件质量与交付, 引发客户抱怨, 满意度降低。针对普遍存在的这些管理与技术问题, 大多数软件开发组织已意识到应当在软件过程规范、管理、改进方面采取一系列改进措施和辅助手段, 如当前业界比较流行的建立质量管理体系、进行CMM/CMMI认证等。

1.3 我国小规模软件企业的现状。

目前国内专门从事软件开发的企业有数千家, 而这些软件企业主要以中小规模为主。根据有关统计数据结果分析, 主要组成结构为:50人以下的企业占55%;50~200人的企业占42%;1000人以上的企业为数不到3%。这些中小软件企业一般具有一些共同的特点, 这些特点将直接影响中小软件企业采取什么样的方式来实施软件过程改进活动。软件过程是指软件开发人员开发和维护软件以及相关产品 (如项目计划、设计文档、代码、测试用例和顾客手册) 的一套行为、方法、实践以及变化过程软件过程管理的重要前提是:软件产品质量的好坏主要取决于开发和维护该产品所使用的软件过程质量。有效的软件过程可将人员、工具和方法进行有机结合。作用对象:软件及其相关产品包括:活动、方法实践和革新。

2 软件过程管理及其改进策略

2.1 选择重点, 优先突破。

软件过程改进应选择重点领域, 循序渐进。因为软件过程改进是要在一定程度上颠覆软件企业现有的软件开发和管理过程, 因此对于已经习惯了固有的工作模式的项目经理、开发人员甚至是企业管理者来说, 大规模的改动相反会起到适得其反的效果。因此应该从企业的软肋出发, 逐渐突破, 在一些重点领域, 让企业尝到过程改进的“甜头”, 从而更好的推进组织级的软件过程改进。

从软件开发过程的角度来讲, 不同的软件企业都有不同的开发过程, 而且不同的软件项目也会采用不同的开发过程, 而开发过程中的需求、设计、编码等阶段, 较大程度上依赖于企业自身的技术实力和开发人员的知识、经验及综合能力。而软件过程改进的核心和重点在于管理, 因此本文建议将以下几个方面作为软件过程改进的重点领域。

2.1.1 注重项目计划与软件测试工作。

项目计划是项目成功的关键, 许多项目的失败都是由于计划制定得不合理或者计划执行不到位而引起的。项目计划应对项目进行合理的规模、成本、工作量等方面的估算, 正确的估算是制定项目计划的前提;根据项目自身特点与项目组人力资源状况进行一定粒度的分解。确保每项分解后的任务均可对应到相对比较适合完成这项任务的项目成员;项目任务要充分并行, 提高人力资源的利用率;计划安排应留有一定余地, 避免出现前松后紧的情况;面对项目计划变更应进行合理评估, 考虑到所有可能会受到影响的因素。

软件质量是软件企业核心竞争力的首要体现, 而软件测试则是软件质量的重要控制措施。规范软件测试过程, 将对软件质量的提高起到重要作用。软件测试应由独立的软件测试团队执行, 只有这样才能保证软件测试的公正与客观;软件测试计划应尽早制定, 软件测试应尽早进行, 软件需求确定之后, 就应该开始制定软件测试计划;软件缺陷应规范管理, 确保所有缺陷都分配到人;结合使用各种软件测试方法;不应忽视软件性能方面的测试与调优。

2.1.2 注重配置管理与质量保证。

一个软件项目的所有相关资料, 如文档、代码、工具、安装程序等均可作为该项目的配置项。良好的配置管理可以确保软件的一致性。而对于规模较大的并行开发项目来讲, 配置管理尤为重要。应做好配置管理计划, 选择合适的配置管理软件;对于软件版本进行统一管理, 确保多个开发人员协同开发不发生冲突;对于基线配置项的变更应制定变更控制流程, 使整个开发与管理过程可追溯可跟踪。

软件测试侧重于对软件产品的质量检查和控制, 质量保证则侧重于对软件过程进行质量检查和控制。产品和过程是一个软件项目成功的必不可少的两个重要因素, 其中产品质量是短期、项目级的影响因素, 而过程质量是长期、组织级的影响因素。质量保证也应由专门的人员进行;主要对项目计划、项目里程碑、阶段成果等进行质量检查, 记录和跟踪质量问题;质量保证人员可以由软件测试人员兼任, 以平衡人力资源的使用;质量保证人员应客观、公正的进行工作。对于以上四个过程领域的改进方法, 本文建议首先从建立规范人手, 然后在规范的实施过程中, 逐步进行修订和完善。一个规范通常由角色职责、工作流程、文档模板、工具支持等四部分组成:具有不同职责、权限的执行人员, 按照既定的工作流程进行相关的工作活动, 并将T作过程记录以文档的形式保存下来, 辅以一定的管理工具, 方可保证其工作产品的质量并使其具有延续性和可维护性, 这也正是建立规范的主要目标。同时, 在规范的范畴内, 所有人员遵循同样的行为准则, 能够更好的进行沟通。

2.2 结合优秀的软件过程元素。

CMM/CMMI是目前业界进行软件过程改进的首选模型, 其实CMM/CMMI已成为事实上的标准。世界各国的软件企业纷纷遵循CMM/CM-MI建立起软件过程规范, 积极进行CMM/CMMI的认证。然而如前文所述, 我国的中小软件企业未必适合完全按照CMM/CMMI来进行软件过程改进, 反而可以结合众多软件过程模型, 从自身的实践中总结出一套适合自己的软件过程改进模式。RUP (Rational Unified Process, 统一过程) 的迭代思想和XP (eXtreme Programming, 极限编程) 的测试驱动开发方法即可以尝试引用到企业当前的软件过程中来。

2.3 重视个体软件过程改进。

开发人员是一个软件企业组中最小的开发主体, 开发人员编码质量的高低、工作计划是否恰当、时间利用率的高低、缺陷率的高低等均会对软件质量以及组织的软件过程产生重要影响。因此, 个体软件过程 (PSP, Personal Software Process) 的概念被提了出来, 相应的也出现了个体软件过程改进这一概念。

PSP是一种用于控制、管理和改进软件开发人员的个人工作方式的过程, 它包含一套完整的方法、表格和规程, 用来指导开发人员如何计划、度量和管理自己的工作。个体软件过程改进可以首先从计划管理、缺陷管理、时间管理等几个方面入手, 同时可以配合任务检查单等工具。通过锻炼个人工作估算和计划能力, 提高对工作任务的驾驭程度;通过管理缺陷, 提高个人以及整个项目对于软件缺陷的控制程度;通过记录和分析时间利用情况, 来掌握工作效率以及时间利用率等方面的一些基础指标;任务检查单, 则可以与计划管理和缺陷管理搭配使用, 有利于个人工作任务的管理。

2.4 重视自评估。

软件企业经常会盲目地进行软件过程改进, 在没有明确自身软件过程处于何种阶段、何种水平的情况下, 贪大求全地建立了一整套软件过程规范, 而实施效果却差强人意。因此, 在进行软件过程改进之前, 以及在进行持续改进的过程中, 对自身软件过程进行自评估是非常必要的。软件过程自评估主要采用调查问卷的方式, 另外可以结合某磐软件度量的方法, 通过定性和定量相结合的方式, 形成当前软件过程状态的评价。调查问卷方式, 需要设计关于软件过程现状的调查问卷, 这些问卷可以是针对某个过程领域的, 也可以是针对整个软件过程的。然后在组织内部选择不同岗位的人员参与一次评估, 根据问卷调查结果, 得出相应的结论。

2.5 适当利用辅助工具。

软件过程管理与改进的本质是一个管理的过程, 管理就需要遵守规则。利用软件工具进行软件过程管理是软件企业普遍采用的方式。目前在软件企业应用较多的软件类别有项目管理工具、配置管理工具、软件测试工具、缺陷管理工具等, 这些工具一般都是针对某一个过程领域, 具有强大、完善的功能, 企业可以根据自身需要选择相应的工具进行辅助管理。但美中不足的在于, 适合于中小软件企业进行整个软件过程管理的轻量管理工具还不多见, 有些厂商的工具配置复杂、价格高昂, 令中小企业望而却步。

结语

软件过程改进不是一蹴而就的过程, 软件企业需要在不断的积累中持续改进。通过实践总结, 本文提出了几点通用的软件过程管理与改进策略, 旨在为我国中小软件企业的软件过程改进工作提供参考。当然, 对于每种策略的具体实施, 本文并未提出深入的方法, 如基于RUP、XP、CMMI等软件过程模型相结合的软件项目实践、PSP中的软件度量方法、软件过程管理与评估系统的试用与持续完善等, 均是我们下一阶段的重点研究和实践方向。

参考文献

[1]郭莹, 杨美红, 杨萍, 等.中小软件企业软件过程管理与改进策略[J].计算机与数字工程, 2009 (2) .

[2]刚家林, 崔巍.中小软件过程管理模型的研究[J].中国科技博览, 2010 (31) .

[3]闫振兴, 郑骏.软件缺陷度量与软件过程管理方法研究[J].计算机与数字工程, 2010 (8) .

[4]王海阳.软件过程管理及其成本的平衡[J].计算机系统应用, 2005 (3) .

[5]钱懿, 庄长远.软件企业过程管理支持系统的研究[J].电脑知识与技术, 2010 (1) .

软件开发方法的创新发展过程研究 篇11

【关键词】软件开发；方法；创新发展过程

一、前言

我们知道，在软件工程和软件更新的过程之中软件开发方式占据了至关重要的作用，我们必须清楚的知道软件的功能才能使软件开发的方法产生效果，并且我们必须明确软件的功能和目的才能进行下一步的方案设计，软件的需求也不尽相同，所以我们必须对开发方法进行创新，使开发方法能够适应不同的软件需求，只有不断的创新软件的开发方法，才能使软件的质量越来越高，保证这个行业的快速发展。

二、简要概括软件开发的方法

软件开发方法是软件工程的理论基础和关键，在进行软件开发方法的研究前必须了解相关软件的功能以及制定详细的方案来研究如何进行这项功能，软件需求也会随着时代的发展而产生变化，所以软件开发方法必须进行创新和改革，并且要具有多种表现形式，我们从两种常用的方法发展历程可知软件开发方法实在不断创新中才能使软件工程获得更大的进步。

三、简要描述面向对象和结构化这两种软件开发

方法的创新发展过程

1、结构化开发方法的创新发展过程

结构化开发方法的关键就是结构化设计以及相关的方法，如果要想实现结构化开发方法，就必须在结构化设计的前提下才能进行下一步工作，大致可以分为结构化设计、设计和软件开发的实现这三个阶段，我们可以了解到，在刚刚进行软件开发时，很多专业人员单纯的追求相关的技巧而忽略了软件的简洁性，这就导致在维护时会造成极大得困难，后来人人逐渐意识到软件在开发初期时不要仅仅注意编写程序是否简单还要考虑后期维护的相关成本，通过大家的研究和分析，研究出了结构化软件开发方法，因为这种方法功能清洗、可理解性高并且后期维护比较容易，并且发现了如果程序具有顺序、选择、循环这三种结构就能很好的解决问题，这一方法是软件工程的一大历史进步，后来不仅发明了C语言等，还出现了程序设计的相关工具N-S图，使软件工程取得了长足发展。

2、面向对象软件开发方法的创新发展过程

所谓计算机，就是将现实社会中的事物反映在计算机之中，我们知道，陈旧的一些软件开发方法都只注重过程，这就使现实世界与计算机之间不能很好的相融，但是自从面向对象这个开发方法的研发成功，弥补了上述的缺憾，C++和JAVA就是我们所说的面向对象方法，这就能使计算机产生对象和类这两种概念，并且将信息和相关的操作有机结合起来，并且专家对面向对象原有的基础上进行了一定的改革，以至于产生了生命周期的概念，并且可以大致分为面向对象分析和面向对象设计这两种方法。

四、针对上述两种方法的创新发展过程进行相关分析

通过上述对创新发展过程的简要概括，我们可以大致得出两种开发方法在创新发展过程中具有4个十分关键的步骤，。

1、结构化开发方法创新发展过程中的4个关键步骤

（一）、在这种方法没有出现之前，软件工程上的专业人员比较随意，都只追求相关的技巧，没有一定的标准和制度来进行参考，使软件开发过程中出现许多问题，并且应及时发现。

（二）、我们必须掘弃传统落后的理念，专业人员必须具有一定的创新理念，并且不能只注重技巧，还要考虑软件的可理解性和后期的维护成本等问题，并且要选用拥有顺序、选择和循环三种组合的程序。

（三）、在对结构化软件进行开发时，我们要运用创新的理念对核心的部分进行开发，我们可知核心是结构化程序设计的方法，所以需要我们在开发的过程中将pascal和C语言以及N-S图和PAD图这几种方法有机的结合起来。

（四）、我们必须在完善结构化方法时寻求创新，在结构化设计方法的相关前提下，使结构化分析技术得到长足的发展，才能将这两种方法有机的结合起来。

2、面向对象开发方法创新发展过程中的4个关键步骤

（一）、以前，我们总习惯将数据和操作进行切割，由于一些问题不能在计算机中进行呈现，并且系统的分析和设计没有形成有效的连接，并且很多模块都不能重复使用，这严重阻碍了软件开发方法的前景。

（二）、对理念进行必要的创新，我们必须将数据和操作紧紧联系在一起，并且衍生出对象和类的概念，我们通过类之间的层级关系使对象之间能够进行有效的信息传递。

（三）、C++和JAVA工具和Small talk语言的出现，导致我们能够利用创新的理念来对面向对象软件的开发时对核心部分进行有效的开发。

（四）、如结构化开发方法一样，我们必须运用创新的理念运用在面向对象开发方法的最后完善的过程之中，并且如今面向对象分析和设计的相关方法的研发，使得该开发方法更加科学以及成熟。

五、结束语

通过上述我们队两种开发方法的创新发展过程的分析我们可以发现4个相似的地方就是我们首先必须发现问题并且在解决问题时要对理念进行一定的创新，并且在软件开发的关键部分和完善阶段时都要运用到相关的创新农历年，由于软件开发方法在软件工程中至关重要的地位，所以这就要求我们的技术人员不断地更新自己的理念并且运用于软件开发之中，才能不断地解决出现的问题，使软件开发能够获得更大的成就。

参考文献

[1]兴达.软件开发方法演变的几个主要因素[J].自然辯证法通讯，2011（05）

[2]韩东.关于软件开发方法的创新发展过程研究[J]，福建农业大学，2014.02.15

[3]李晓文.软件开发方法的创新发展过程研究[J].软件开发，2012.03.25

[4]邓同辉.对于软件开发方法的创新发展过程进行研究[J].科技直窗，2013.06.24

软件配置管理过程控制方法研究 篇12

随着计算机技术的飞速发展, 大量应用软件在各种系统或设备中被安装使用, 为提高各种作业流程的自动化水平发挥了重要作用, 可以说, 没有应用软件支撑, 许多系统都无法运行。在实际应用中, 往往需要针对特殊业务需求或作业流程, 定制或开发专用应用软件, 并根据业务需求变化进行适应性改造与完善。该软件一般需要自行研制开发, 由于应用软件开发涉及到规模大小不同、软件关键性等级不同、软件开发运行环境不同、软件开发人员分工和开发能力等多种因素, 在软件开发和应用管理过程中存在问题较多, 有些问题甚至直接影响到业务运转或作业流程的成败。

(1) 软件工程化规范问题。软件项目实施中, 参加软件开发的人员一般由负责设备管理或具体专业的人员参加, 对软件工程化缺乏深入全面的掌握, 只能边学习、边设计、边实现、边修改, 容易产生软件开发阶段划分不准确、文档拟制不规范、软件文档与实际产品不相符、软件测试不周全等问题。

(2) 软件版本控制问题。自研应用软件开发与应用中, 开发者一般同时也是使用者, 开发环境也是运行环境, 开发人员对负责的设备和业务比较熟悉, 对自己开发的软件也比较熟悉, 在使用过程中更容易发现软件存在的问题和缺陷, 因此往往会随意改动软件, 而不提交软件问题申报单和软件更动报告单, 不进行相应的影响域分析, 更动之后也仅仅只做调试, 不经过严格正规的测试, 会造成潜在的软件危险, 甚至可能直接影响到设备安全。

(3) 软件使用管理问题。不按照软件配置管理和使用规定, 从软件配置管理库中提取正确的软件版本, 或者仅办理软件使用审批手续, 但不清理软件运行环境, 不检查软件版本和运行状态, 仍然会出现实际运行软件不是正确版本、不能掌握软件运行环境和运行状态等问题, 最终可能导致软件配置管理的失控。

1 软件配置管理关键环节

软件配置管理的任务是制定软件配置管理计划, 确定配置标识规则, 实施变更控制, 报告配置状态, 进行配置审核, 进行版本管理和发行管理。

软件配置管理是从软件项目开始直至软件退出运行, 贯穿整个软件生命周期的一组跟踪与控制活动, 本质是标识、组织和控制对正在开发的软件修改更动的技术, 以减少软件更动所需的工作量。其重要性在于:“你不控制变更, 变更就会控制你。”而变更是软件开发过程中不可避免的活动。

熟悉并恰当应用软件配置管理工具, 可以很好地管理软件项目, 但在实施中要真正管理好软件项目, 除了技术手段, 如何对过程进行管理更加重要, 需要把握好几个环节, 一是软件生命周期的合理划分, 二是软件更动控制的管理方法, 三是软件运行版本的管理。

1.1 软件生命周期划分与裁剪

完整的软件生命周期包括系统分析与设计、需求分析、概要设计、详细设计、编码与单元测试、部件测试、配置项测试、系统测试、验收移交与保障、软件维护、软件报废。

对具体的软件项目, 不一定包括生命周期的所有阶段, 要根据软件规模、运行环境、开发环境、安全级别等因素综合考虑, 对具体软件项目进行合理的阶段划分和裁剪。

(1) 仅有一个配置项的小规模软件, 如运行在一台设备中的应用软件, 软件设计不需要划分概要设计和详细设计阶段, 软件部件测试阶段也不需要, 但如果软件关键性等级高, 则需要详细划分各个阶段。

(2) 基于集成可视化的组态软件的设备监控软件开发, 不需要考虑软件单元测试和部件测试阶段, 甚至可以将配置项测试与系统测试合并。

(3) 对于大规模和包含多个配置项的软件, 要划分完整的生命周期阶段, 每个阶段都要提供完整的文档和产品。

(4) 对于软件开发的每一个阶段, 都要进行阶段评审, 软件编码与单元测试、部件测试阶段一般只需要内部评审, 其它阶段需要专业机构或专家组织进行评审。软件配置项和系统测试需要第三方测试。对于软件关键性等级高的软件, 各个阶段都要组织专家评审, 必须经过第三方测试。

(5) 各个阶段都要提交相应的产品和文档, 并严格按照软件配置管理要求进行管理。

1.2 软件更动控制

软件配置管理的根本任务就是有效控制软件更动及其产生的影响, 软件更动产生的影响往往是不可估量的, 因为软件代码中一个极小的Bug可能就会造成设备极大的故障甚至灾难。因此, 必须要严格控制软件更动过程, 防止严重故障或灾难性问题的发生。

(1) 软件问题报告。软件开发人员或使用人员通过填写软件问题报告单向主管机构报告发现的问题, 软件问题报告单要准确描述软件问题名称、软件版本信息、提交问题的人员及时间等, 对软件问题来源 (程序、文档、数据库、设备更新等) 、问题现象和原因也要进行详细描述, 并提出修改要求和修改内容。

(2) 软件更动审批。软件开发人员根据软件问题报告单填写软件更动报告单, 说明软件更动类型 (纠错、改进、扩充等) 和更动项目 (程序、文档、数据库等) , 要详细描述软件更动的具体内容, 进行影响域分析, 说明软件更动对设备、其它软件模块或作业流程的影响, 确保软件更动的正确性, 防止产生负面影响。软件更动报告单要经过软件配置管理机构的审查和批准, 方能实施更动, 如果需要, 还应当进行评审, 以确定是否可以更动, 以及更动的内容和方法是否合适。

(3) 回归测试。软件更动后要进行测试, 编写完整的测试用例来测试更动后的软件。通过测试后, 要按照软件配置管理程序履行软件入库、出库与安装运行手续, 以正确使用更动后的软件。

软件更动本身可能比较简单, 比如只修改一条语句甚至一个字符, 但软件更动的管理过程很复杂, 从提交软件问题、更动、测试到运行需要履行多道手续, 有可能还要经过评审。这一过程的工作量远远比修改软件本身的工作量繁重得多, 因此可以有效防止开发人员随意更动软件行为的发生。

1.3 软件使用过程管理

软件使用过程管理, 既要保障操作人员从配置管理库提取正确的软件版本, 还要检查使用人员是否正确使用软件和使用正确的软件版本, 特别是在自研软件较多的情况下, 必须检查软件使用状态。

(1) 软件使用申请。软件使用人员根据设备运行或作业流程, 在一个特定的阶段开始前, 比如每年或每个季度, 或在设备投入使用前进行设备状态检查时, 填写软件出库申请单来申请使用软件, 说明申请使用的理由和需要使用的软件版本, 经过审批后从软件配置管理库提取软件。

(2) 软件安装使用。软件安装前, 要对软件运行环境进行清理, 包括重新安装操作系统、查杀病毒、删除原来运行的软件版本 (或进行备份) , 重新配置软件运行环境, 以保障软件环境的干净和安全。然后根据软件安装运行的操作规程安装使用软件。

(3) 软件版本比对与检查。软件配置管理机构必须要对操作人员安装的软件进行检查, 以确认是否为申请的软件版本, 这个过程非常重要, 防止使用人员只履行手续而不安装软件, 而是继续运行原来的软件, 对于自研软件, 如果不检查, 可能会出现配置管理库与运行版本不一致而最终导致软件版本混乱的问题。对于固化在PLC中且没有更动的软件, 一般不需要重新安装或固化, 但需要进行软件版本的比对检查, 防止意外情况的发生。

2 软件配置管理过程控制措施

软件配置管理本身是一项保障软件完整性和正确性的技术, 通过管理手段进行软件配置管理过程控制, 则是保障软件开发质量, 保证正确和规范使用软件的基础。

2.1 充分发挥软件配置管理机构的职能作用

按照软件工程规范, 成立软件配置管理机构, 设立软件配置控制委员会, 并下设软件配置管理小组, 明确并履行管理职责。

(1) 软件配置控制委员会负责受控库和产品库中各软件项目配置管理组的成立、配置管理计划、基线设置、配置管理项设置、更动申请、产品出入库等工作的审批, 审查各种表单和提交产品的完整性、一致性和完备性, 核实配置管理落实情况, 确保软件与产品库的一致。

(2) 软件配置管理小组在软件配置控制委员会的领导下, 负责软件配置管理的组织计划与协调, 管理软件配置管理专用系统设备工具, 检查软件配置管理履行手续, 对软件配置管理项及其存储介质进行日常维护管理。

2.2 定期清理软件技术状态

(1) 依据软件配置管理库, 建立软件配套表, 清理软件文档和软件版本, 以保证软件文档齐全规范, 软件版本和文档控制号正确。

(2) 通过代码清查分析等方式, 确认和熟悉软件版本、编程结构及编程方法。

(3) 对软件运行环境进行清理, 对具备病毒查杀条件的计算机进行病毒查杀, 检查机器硬件、操作系统和相关系统软件的工作状态、磁盘存储容量、余量, 清理多余文件和数据。

2.3 检查软件配置管理状态

(1) 检查软件配置管理库中的软件状态, 重点清查应用软件的版本号、文档控制号等, 对软件版本的一致性进行检查, 确保软件源程序和执行代码的一致性, 避免入库源代码与执行代码不对应。

(2) 清理系统应用软件更动情况, 检查软件问题报告、更动报告、回归测试报告等入库情况和软件配置库的完备性。

(3) 对配置管理库中软件配置管理情况进行审计, 保证程序与文档、文档与文档及产品与要求的一致性符合软件工程化技术标准要求。

2.4 软件出库安装和运行检查

(1) 检查应用环境中所安装的操作系统、参数设置与软件用户手册要求是否一致。

(2) 检查应用环境中各系统软件安装、参数设置与软件用户手册的要求是否一致。

(3) 对所有纳入配置管理的软件进行出库安装和运行检查, 逐个安装应用软件并运行检查, 检查各软件功能和性能, 考察软件的正确性和稳定性。

2.5 对嵌入式软件进行比对分析

针对嵌入式软件随设备固化、运行状态隐蔽等特点, 进行出库比对, 重点从运行版本与出库版本的一致性、参数设置的一致性等方面进行比对分析, 确保软件运行稳定可靠。

3 结语

本文针对自研应用软件开发与使用管理中存在的问题, 分析讨论了软件配置管理过程中需要注意的几个环节, 总结了软件配置管理的过程控制方法和有效措施, 以保证软件工作规范有序、软件版本正确、性能稳定、软件开发符合规范要求、软件使用和更动过程受控, 从而有效保障了软件在生命周期内状态的完整性、一致性和可追踪性。

参考文献

[1]邓成飞, 李洁.软件工程管理[M].北京:国防工业出版社, 2000.

[2][美]ROGER S PRESSMAN.软件工程:实践者的研究方法[M].梅宏, 译.北京:机械工业出版社, 2002.