51Testing软件测试论坛

标题: 软件项目管理的质量保证 [打印本页]

作者: 刘洪鹏 时间: 2007-12-21 12:00
标题: 软件项目管理的质量保证
软件项目管理的质量保证

作者：匡红庆　

　　【导读】项目开发根据进度分为需求、设计、开发、测试等各个阶段，质量保证工作始终贯穿各阶段，同时又必须根据每个阶段特点采取相应的措施。

　　软件工程项目管理是一个系统工程，软件工程项目管理的主要目标是保证项目在规定时间内高质量地完成。项目管理包括了项目组开发各阶段的人员结构的配置，质量控制的实施方略，内部文档和产品文档的组织编写等多项工作，其中质量控制方法具有软件开发的特点。
　　项目开发根据进度分为需求、设计、开发、测试等各个阶段，质量保证工作始终贯穿各阶段，同时又必须根据每个阶段特点采取相应的措施。
　　需求分析
　　需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。。
　　在具体项目中，一般的做法有两种:一是请领域专家参与到系统开发的早期阶段;二是开发系统原型，原型包括功能性的原型和用户界面性的原型，也可以是二者混合的原型，用这些原型确认用户的需求。让领域专家参与开发的早期阶段，是保证分析人员有充足的时间和领域专家进行充分的交流和确认。在这个阶段，原型可能在提交到用户之前，首先被领域专家确认，这样保证了原型被认可的程度和认可过程耗费的时间尽可能的短，从而在提高效率的同时保证了质量。
　　在开发方内部还有三项保证措施:系统分析委员会保证系统分析集思广益;质量监督组对分析工作的监督;技术支持人员参与需求调研。
　　分析委员会的意义在于任何分析人员在提交其所分析部分的分析说明书前，必须通过委员会的共同审议，委员会的成员根据各自的分析经验和自身所分析的部分对他人的分析报告提出质疑。如此审议过后保证了各部分间相互关联的部分被明确定义，避免了由于“疏忽”造成系统在后期进行整合时出现较严重的系统鸿沟或系统重叠。
　　质量监督组在项目的任何阶段都要提出监督计划。按照监督计划分配相应的资源来保证某阶段的开发质量。分析阶段的监督计划会在分析任务之前被项目经理、项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时分析工作又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，并在认为确实有必要的情况下才召开质量复审会议。质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。会议的主要议题是提出质量质疑，给出改进建议即可。具体是否存在质量问题，是否需要改进，不在会议中进行讨论，以此保证了会议参与的人数较少，会议的时间尽可能的短。
　　系统实现
　　实现也就是代码的生产过程。生产的类别有类的生产，组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，我们将生产的程序人员按职能分成两组，测试用例的生产和测试用例生产，也就是说如果某个程序员生产了某个组件，则其测试用例不能再由该程序员来生产，但他可以生产其他组件的测试用例。这样交叉生产更容易发现组件的存在的问题。测试人员按照测试用例来测试组件的各项指标提出测试报告。
　　为了控制系统开发过程中的往复，不至于产生重大过失和往复的泛滥，文档组和质量监督组协同完成软件开发的配置管理。
　　软件配置管理的目的在于控制软件开发过程中的“变化”，这种变化可能是外部引起的，如需求的变化。也可能是来自于内部的变化，如早期设计的某个部件不够完备，需要修改等。为了控制这些变化，把变化引起的波动尽可能的控制在有限的范围内。
　　配置项是指需要进行控制的任何文档单元，它可能是需求说明报告，也可能是需求说明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及相关构件。
　　测试
　　测试组的工作被分成若干阶段，不同阶段的划分是以保证软件质量的不同指标为目标的。
　　测试的软件指标分别包括如下几点:
　　软件的正确性:正确性测试主要是测试软件的功能是否被正确的实现。测试的方式主要是按照功能的要求按照给定的输入，看是否有给定的输出，在非标称输入时，输出是否异常等。同时也可以测试软件的功能是否实现或完整实现。
　　性能指标:该项目对性能的要求非同一般的软件项目。性能测试往往包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来将软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。
　　易用性:软件的使用界面在设计实现的时候应当设法使之与功能的实现相脱离。脱离的原因在于易用性是通过友好的界面实现的。然而让开发人员以使用者的角度来确定软件是否易用是件非常困难的事情，在确定使用界面时往往需要多次的反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。
　　鉴于这种特点，软件在开发的不同阶段都作了相应的保证措施，比如在软件需求界定的时候请领域专家参与，在软件设计阶段，让功能的实现尽可能地包含在软件的组件之中，也就是没有界面要求的底层实现。界面的实现仅仅依赖于一个数据接口，界面仅仅负责将用户输入的数据送到指定的数据块中，用于显示的数据也在指定的数据块中提取，只要保证数据块被互斥的访问就可以了。有了这样的设计结构，软件的易用性也就相当容易保证了。当测试中发现易用性的问题时，软件不会伤到筋骨，皮毛的修改总是非常容易的。
　　只有在项目每个阶段不断实施质量管理措施，才能尽早发现问题，确保项目成功。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)