论软件质量管理

本科毕业论文

(科研训练、毕业设计)

题 目：论软件质量管理

姓 名：陈** 学 院：

系：

专 业：项目管理 年 级：R2008秋季 学 号： 指导教师（校内）：

指导教师（校外）： 2010年 9月 10日

职称：讲师职称：

论软件质量管理

摘要 软件产品是软件项目的最终结果，其功能度和复杂性要比制造业的产品高得多，而且

在投入使用后，软件发挥的功效也是其它任何形式的硬件产品所无法比拟的。为了保证软件产品在交付后能够按照用户的需求发挥正常的功效，因此在项目实施过程中进行有效的质量管理是很有必要的。本文结合作者的经历就软件项目中的质量管理做了一些探讨，对软件项目全过程的质量管理作了详细论述：在需求分析阶段通过结对分析与需求评审来保证需求分析的质量；在设计与开发阶段，制订相应的软件开发规范，并严格执行，保证实现代码的质量；在测试环节上，强调测试与软件实现同步，强化Bug管理,以进一步提高软件质量。软件开发全程要做到“有法可依，有法必依”。以上措施是开发出高质量软件系统的重要保证。

关键字 软件 质量 管理

Discuss the software quality management

Summary Software products are software projects the end result, its function and the degree of

product complexity is much higher than the manufacturing sector, but also put into use, the software is, the effectiveness of any other form of hardware can not match. To ensure the software product after delivery to the needs of users play in accordance with the normal effect, so the process of effective implementation of the project quality management is necessary. In this paper, the author's experience on software project quality management to do some research on the quality of the whole process of software project management are discussed in detail: requirements analysis stage, through the end of the analysis and needs assessment of the quality assurance requirements; In the design and development stage, the formulation of the corresponding software development standards and strictly enforced, to ensure the quality of the implementation code;In the test session, the stress test and software synchronization, enhanced Bug management, to further improve software quality. To do the whole software development, \"according to the law, must follow the law.\" The above measures is to develop an important guarantee for high-quality software systems.

Keyword Software Quality Management

目录

第一章 项目概况及背景 ......................................................................................................................................... 5 第二章 项目质量管理问题及须注意环节 ............................................................................................................. 5 第三章 具体应对策略及做法 ................................................................................................................................. 6

引言

软件产品是软件项目的最终结果与其相关的质量问题主要来自项目开发过程。但软件是一个纯智力的特殊产品描述软件质量的定义则比描述实际物品质量定义面临着更多的潜在因素。所以保证软件质量比保证设备质量更具挑战性和不确定性。

国际化标准组织ISO在ISOPIEC9126中将软件质量定义为:“反映软件产品满足规定需求和潜在需求能力的特征和特征的总和”。而M .J .Fisher将软件质量定义为:“所有描述计算机软件优秀程度的特性的组合”。目前对软件质量的研究主要从两方面展开:一是软件开发过程的质量保证以过程文档化和管理科学化为内容:二是软件过程和产品的质量评估包括中间产品和最终产品采用软件度量技术作为软件质量特性量化的主要技术。本文将就第一个方面展开讨论通过给出或设计一些符合文档化开发标准的管理规范和文档模板以达到使软件质量满足之前用户对各项功能或性能的精确定义的目的。

第一章 项目概况及背景

2009年，对某海运有限公司的信息系统组织了开发与实施。在项目团队中，本人承担了系统分析与项目负责人的职责。本系统的主要目的是为了加快船务代理信息化建设步伐，提高船务代理信息化管理的水平，增强整体竞争能力，本着“操作本地化，数据网络化”之指导思想，使之具有本地化操作功能之船务代理信息系统，实现整个公司层面上的业务、财务信息共享，为在公司整体范围内的资金管理和预算管理提供有效的工具。船务代理信息系统对质量要求较高，自交付运行以来，用户反馈表明，质量特性上较好地满足了生产需要。在软件开发过程中，为提高软件质量，本人认为要在软件开发项目过程中引入完善的质量管理，并针对船代项目特点，结合实际情况重点覆盖需求、编码、测试三个阶段。

第二章 项目质量管理问题及须注意环节

第一节 需求分析阶段问题

需求分析阶段，对于任何软件项目过程而言，需求不仅是一个不可避免的环节，也是软件开发的基础。往往用户需求明确变更少的项目的成功率就高而那些用户需求混乱变更频繁的项目几乎从一开始就注定了失败的命运。但是，在现实生活中，用户需求总是在开发进入中后期时，因为各种不同的原因而发生变化。这就给软件项目过程实施带来不确定因素。在项目中，由于前期需求不明确以及随意变更需求，导致项目组在开发阶段不停的返工，进而造成代码质量低下，测试拖期等一系列问题。 需求分析的质量是否优良，决定着后继各工作环节能否按既定方向进行。由于客户方生产较为繁忙，计算机应用水平不高等因素，与中层管理人员、基层操作人员的交流有很大困难，参与项目的时间与精力得不到保障，此问题使项目组相当困扰，是项目组急需解决的问

题。

第二节 设计、分析阶段问题

设计与编码阶段问题，是由于项目组成员的编程能力、习惯、风格、对需求的理解和个性的不同所开发的代码质量也不尽相同。再加上一些难以预测的人为因素由此带来的隐患将严重影响代码质量最终造成软件质量低下，使得用户无法正常使用并为以后的维护带来更大的工作量和难度等一系列问题急需改进。此外，强调纪律和规范是不容忽视的。

第三节 测试阶段问题

测试阶段问题，包括测试活动未能覆盖整个项目过程，未指定详细的测试计划和编写相应的文档，如测试用例文档、测试计划文档等。未能遵守按照用户需求进行测试的原则，只求速度而缩短了测试规模，忽视了用户需求，导致很多程序BUG未能在此阶段中发掘出来。

第四节 文档管理环节

项目文档管理是一个相当重要的环节，往往会被人忽视。其重要性体现为，日后项目上

线，需要提交给客户相关的交付物，这就包含了相当多的文档，比如项目计划、需求规格说明书、系统概要设计说明书、系统详细设计说明书、用户操作手册等一系列文档。除了上线客户要求外，我们整个软件过程中也需要这些文档，这才能使整个项目周期全过程比较有保证，输出产品的质量比较有保障。

第三章 具体应对策略及做法

第一节 需求分析阶段

在项目实施过程中，为了保证软件开发的顺利进行和最后交付的产品质量，应该对项目需求变更进行管理。

1、 需求说明书要描述明确详尽。由于与用户沟通的需求人员并不是最后的开发人员，所以有可能导致开发人员对需求说明书的理解与用户真正的意图会产生一定的偏差。另外，当项目在进行到开发(编码)阶段时，由于记忆的缺失，对当初所作的需求说明书的理解也会产生偏差。

2、 要对需求变更进行管理。通常需求分析完成后项目就进入开发阶段，用户可能会因为市场或策略的变化而提出需求变更的要求。此时，若是合理变更则有利于项目实施，但有时所作的变更可能会影响项目整体的设计和开发，造成项目进度的延期。对于这一情况，项目组应该积极与用户沟通，制订需求变更说明书，在双方都认可的情况下方可实施。

3、 在项目开发过程中要尽早明确用户需求，有些内容一时无法确定则应该暂缓该部分的开发，尽量降低因需求变更而带来的风险。

需求分析的质量是否优良，决定着后继各工作环节能否按既定方向进行。针对客户方种

种问题，本人制订了结对分析的策略，以提高需求分析的效率与质量。

结对是敏捷软件开发一个最佳编程实践，本人创造性地将其引入到需求分析阶段。需求分析各个环节(包括需求获取、分析，与用户沟通)均由两个开发人员来共同完成，能取得较高的需求分析质量。例如，这一策略在箱管这一关键环节的需求分析上发挥了重要作用。箱管人员年纪较长，对计算机概念模糊，沟通上存在很大障碍，通过两个需求分析人员共同来完成该项工作，做到了分析人员的优势互补。通过结对分析不仅得到较高的需求分析质量，并且节省了用户的时间，对用户也有一定的推动。只有两个分析人员达成一致，才将相应需求嵌入基线库中，保证了需求的科学性。这样做虽然增加了人力成本，但提高了需求分析效率。

强化需求评审。需求评审分为三个层次：1、全局评审。参与人员主要是用户方核心管理层，业务领域专家，开发方分析人员。主要任务是评审需求与公司目标、高层想法是否一致。这一评审至关重要，它把握了软件系统实施方向的正确性。2、局部评审。参与人员主要是用户方业务中层及一线操作人员，开发方业务领域开发工程师。主要任务是就业务层相关业务流程进行再次确认。因为需求过程中相应部门的业务人员站在自己的角度看待问题，对于整个流程关心不够，需要纠正各部门用户需求不一致的问题。3、内部评审。全体开发人员、分析人员参与。分析人员建立初步的UML用例图，工作流程图，活动图等供全体讨论。任务是澄清一部分模糊的需求。

在需求阶段，还采取了其它措施来保证需求分析的质量，如强调需求分析工具的使用等。

第二节 设计、编码阶段

设计阶段，优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢?

对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式(除用户指定开发设计方式外)可以减少项目承担的技术风险。用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。 针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。 除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。

设计与编程质量对于软件产品的质量有着直接的作用。在这一阶段，我们的主要措施是强调纪律与规范，制订相应的约束规范文件，要求设计有可追溯性，强调设计、开发过程标准化。另一主要措施选择适合的工具。我们选择的开发平台为.NET，开发工具为Visual Sutdio 2003(简称VS2003)，后台开发平台选择Java，后台数据库为Oracle。本人制订了.NET和Java编码规范，目的是保证不同开发人员的代码风格基本一致，降低开发人员流动可能导致的项目风险；强调代码的可理解性与“设计先行与强化注释”；制订了SQL书写规范。这一系列规范标准的制订从源头上保证了软件设计的质量。

编码人员分成二类角色：业务领域工程师和核心代码工程师。业务领域工程师针对具体的业务功能进行编码。在设计时我们要求业务领域工程师要有这样的意识：变更不可避免，在设计尽可能考虑到将来变更的可能性，尽可能做到模块之间的松耦合，模块内部的高内聚。核心代码工程师完成公共代码的实现与维护。核心代码质量在系统中至关重要。对核心代码工程师加以分组，每组两位工程师实行结对编程。以克服思维局限，共同完成设计、UML图、实现，保证代码质量。实践证明，采取这些办法后，在用户提出相应功能变更时，软件修改相对较轻松，能较好地适应业务变化。

软件质量在很大程度上依赖于代码质量。考虑到项目进度以及实际情况，要进行完整的代码评审不太现实，因此在软件开发过程中项目组制定了代码走查制度。每周在规定的时间内，轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量，另一方面在走查过程中可以获得他人的意见进一步改善代码效率，使开发成员共享项目实施过程中问题解决的思路和方法同时还可以促进项目组成员之间的交流并加深对需求的理解关注软件开发过程中的各个环节并进行过程改善的讨论，使得软件质量更有保障。

第三节 测试阶段

测试是保证软件质量较为重要的一个环节。针对开发团队部分成员测试意识不强，项目部有针对性地进行培训；强调测试与设计同步，测试用例与功能代码的编制同步；及时进行单元测试，统一用VS2003 for Tester作为测试工具；Bug使用TD管理统一存放在服务器中，严格控制Bug的开启与关闭，并把Bug数据作为工程师考核依据之一，指派专门的测试人员进行Bug管理。

所有测试中出现的问题，经整理后在项目团队例会上进行总结；在团队内部交流并在平台WBS中建立一个专门的开发常见问题指南，发布已经暴露的Bug解决方案，让项目团队共享，避免问题重复出现；构建项目团队自有知识库，作为公司设计重用的一个重要资源。

测试就是对软件产品的检验。软件测试的目的是根据用户需求检查系统是否符合项目合同与任务书规定的要求。项目测试分集成测试和系统测试，主要进行功能测试、健壮性测试性能一效率测试用户界面测试、安全性测试、压力测试可靠性测试安装/反安装测试等活动。测试过程通常在模拟环境中进行。只有通过了上述全部测试的软件，才可以称之为符合用户质量要求的合格的软件。

测试活动要尽可能覆盖整改项目过程，从最初的需求到部署阶段，都应该制订详细的计划并编制相应的文档，如测试计划测试用例文档测试报告等。通过测试活动尽可能早得发现每个阶段中软件存在的缺陷，以方便后续阶段的实施。在这测试活动过程中，我们应该遵守一条基本原则—按照用户需求进行测试。我们即不能为求速度而缩短测试规模，也不能忽视用户需求而提高测试要求。总之一切测试应该符合用户需求。

除了高度重视实现阶段的测试，同时也积极主动地去发现质量问题。团队使用VS2003自带工具进行性能优化分析，找出使用频度高与关键代码进行性能优化。利用LoadRunner压力

测试工具，找出性能瓶颈，制订相应策略进行优化。

第四节 文档管理

文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。 内部文档包括： 项目开发计划、需求分析、概要设计说明、详细设计说明、构件索引、构件成分说明、件接口及调用说明、组件索引、组件接口及调用说明、类索引、类属性及方法说明、测试报告、测试统计报告、质量监督报告、源代码、文档分类版本索引、软件安装打包文件。

外部文档主要包括： 软件安装手册、软件操作手册、在线帮助、系统性能指标报告、系统操作索引。

如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个“度”的问题。在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下“填空”的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。

配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。

从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。

结论

软件自交付以来，用户反馈系统运行稳定。实践证明，我们的一系列质量保证策略与实践取得了很大成功。只有在需求分析、设计、开发、测试、文档管理等各个环节实施质量保证措施，才能保证软件产品的质量。软件项目要做到“有法可依，执法必严”，并要高度重视各个环节辅助工具的使用，这样才能较好地保证最终软件产品的质量。

致谢语

在本次论文设计过程中，周红刚老师对该论文从选题，构思到最后定稿的各个环节给予细心指引与教导,使我得以最终完成毕业论文设计。在学习中,老师严谨的治学态度、丰富渊博的知识、敏锐的学术思维、精益求精的工作态度以及侮人不倦的师者风范是我终生学习的楷模，导师们的高深精湛的造诣与严谨求实的治学精神，将永远激励着我。这三年中还得到众多老师的关心支持和帮助。在此，谨向老师们致以衷心的感谢和崇高的敬意！

最后，我要向百忙之中抽时间对本文进行审阅，评议和参与本人论文答辩的各位老师表示感谢。

参考文献 附录