丹东思凯电子发展有限责任公司 关嘉旺
摘要：本文通过对《IC卡水表管理系统》各阶段的发展过程，阐述质量管理在项目开发的各阶段的实现过程。
关键字：需求分析、开发设计、文档管理、配置管理、测试
引言
《IC卡水表管理系统》是为吉林自来水公司建立的一套针对用户的数据采集和统计分析系统。通过这套系统可以对这些数据的分析，便于及时发现可能发生的隐患，提高计量设备管理水平，减少供销差率都具有重要的意义。同时极大的提升自来水公司的服务水平和企业形象。
本人通过项目的开发深刻感受到认真细致的项目管理，对保证项目周期和项目质量的重要性。项目的质量高低取决于其是否符合包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面的要求。而要达到这六个方面质量要求，就必须对软件开发过程中各个环节进行全过程的质量管理，从需求分析、设计、编码、测试等各个方面和环节进行控制。
一、需求分析
需求分析是开发人员对系统需要做什么和如何做的定义过程，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户、领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。
吉林自来水公司与我单位有长期的合作关系，我单位数据集统计分析领域的优势和长年积累的经验，客户的需求非常明确，同时在本项目中，请领域专家参与到系统开发的早期阶段;开发系统原型，原型包括功能性的原型和用户界面性的原型，用这些原型确认用户的需求。让领域专家参与开发的早期阶段，保证分析人员有充足的时间和领域专家进行充分的交流和确认。在这个阶段，原型在提交到用户之前，首先被领域专家确认，这样保证了原型被认可的程度和认可过程耗费的时间，从而在提高效率的同时保证了质量。
在开发方内部还有三项保证措施:系统分析委员会保证系统分析集思广益;质量监督组对分析工作的监督;技术支持人员参与需求调研。
分析委员会负责分析人员在提交其所分析部分的分析说明书前，必须通过委员会的共同审议，委员会的成员根据各自的分析经验和自身所分析的部分对他人的分析报告提出质疑。如此审议过后保证了各部分间相互关联的部分被明确定义，避免了由于“疏忽”造成系统在后期进行整合时出现较严重的系统鸿沟或系统重叠。
质量监督组在项目的任何阶段都提出监督计划。按照监督计划分配相应的资源来保证某阶段的开发质量。分析阶段的监督计划会在分析任务之前被项目经理、项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时分析工作又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，并在认为确实有必要的情况下才召开质量复审会议。质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。会议的主要议题是提出质量质疑，给出改进建议即可。具体是否存在质量问题，是否需要改进，不在会议中进行讨论，以此保证了会议参与的人数较少，会议的时间尽可能的短。
二、开发设计
开发设计是产品质量形成的最为关键的阶段。设计一旦完成，产品的固有质量也就随之确定。搞好产品开发设计阶段的质量管理，确保开发设计的质量，是企业至关重要的环节。
（1）搞好设计策划 在项目开发设计初期，根椐实际情况和产品的特点，确定产品开发的工作程序和设计进度，明确划分研制阶段，在每阶段建立评审点，实施分阶段质量控制。同时，确定各有关部门和人员的职责、权限、组织和技术接口以及所需的各种资源。 针对每项开发和设计活动单独编制质量计划。产品质量计划应针对具体产品的特殊要求，以及应重点控制的项目 ，编制各阶段的质量控制方案，规定各阶段主要质量活动的内容，提出专题试验研究项目或技术攻关课题。
（2）进行早期预防 为确保开发设计质量，防止和识别设计工作中的偏差和错误，使用以下方法进行预防报警。
设计评审 ：及早发现、防止和弥补设计本身的缺陷，在产品开发设计过程各阶段决策点上，组织与产品形成过程有关、但不直接参与或对产品开发设计不负直接责任的专家，对产品设计及可能出现的缺陷进行评审。可达到以下目的： 及早发现和补救设计中的问题。 防止设计缺陷带到生产中去，影响制造成本、产品性能等。
设计验证： 在设计的适当阶段，应开展设计验证活动。可根据具体情况灵活运用以下方法：变换方法计算；将设计与已证实的类似设计进行比较；对发放前的设计阶段文件进行评审；进行试验和验证。一般同时采取两种或两种以上方法进行验证。其目的是：确保设计输出满足输入的要求。
故障分析 ：为了防止产生影响产品可靠性和安全性的故障，在开发设计过程中，对可能产生的故障及其潜在原因进行系统的研究。
（3）广泛使用质量工程技术 质量工程技术为产品研制设计、技术改进提供了合理而高效的技术方法。
（4）确立基准 把世界上同类产品公认的领先的名牌产品作为自已产品的基准。通过与基准产品在性能、成本、款式、交货期、生产过程、质量和服务水平等到全方位的比较，确定自已所处的地位和努力方向。通过模仿和不断的改进，达到超越竞争对手的目的。 基准化过程一般要遵循下述步骤：
a、确定基准化的对象，确认竞争对手或本领域的领先者。
b、建立信息系统，收集数据资料。
c、归纳并分析数据：分析的目的是针对所有有关项目制定最佳的实践目标。
d、通过对比，制定和实施行动计划，最终达到或超过竞争对手的标准。
（5）、设计人员要面向市场调查，新产品设计动机来自于顾客的期望和思想。因此，开发设计人员一定要从办公室里走出来，面向市场和顾客，从事产品销售和服务维修工作，真诚地倾听顾客的声音。
三、文档管理
为了控制系统开发过程中的往复，不至于产生重大过失和往复的泛滥，文档组和质量监督组协同完成软件开发的配置管理。同时为了使软件文档能起到多种桥梁作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件开发，有助于用户了解软件的工作和应做的操作，有助于维护人员进行有效 的修改和扩充，文档的编制必须保证一定的质量。质量差的软件文档不仅使读者难于理解，给使用者造成许多不便，而且会削弱对 软件的管理(管理人员难以确认和评价开发工作的进展)，增高软件的成本(一些工作可能被迫返工)，甚至造成更加有害的后果 (如误操作等)。造成软件文档质量不高的原因可能是：
l缺乏实践经验，缺乏评价文档质量的标准。
l不重视文档编写工作或是对文档编写工作的安排不恰当。
最常见到的情况是，软件开发过程中不能按给出的进度， 分阶段及时完成文档的编制工作，而是在开发工作接近完成时集中人力和时间专门编写文档。另一方面，和程序工作相比，许多 人对编制文档不感兴趣。于是在程序工作完成以后，不得不应付一下，把要求提供的文档赶写出来。这样的做法不可能得到高质量的文档。实际上，要得到真正高质量的文档并不容易，除去应在认识上对文档工作给予足够的重视外，常常需要经过编写初稿，听取意见进行修改，甚至要经过重新改写的过程。
高质量的文档应当体现在以下一些方面：
l 针对性
文档编制以前应分清读者对象，按不同的类型、不同层次的读者，决定怎样适应他们的需要。例如，管理文档主要是面 向管理人员的，用户文档主要是面向用户的，这两类文档不应像开发 文档(面向软件开发人员)那样过多地使用软件的专业术语。
l 精确性
文档的行文应当十分确切，不能出现多义性的描 述。同一课题若干文档内容应该协调一致，应是没矛盾的。
l 清晰性
文档编写应力求简明，如有可能，配以适当的图 表，以增强其清晰性。
l 完整性
任何一个文档都应当是完整的、独立的，它应自成体系 。
l 灵活性
各个不同的软件项目，其规模和复杂程度有着许 多实际差别，不能一律看待。对于较小的或比较简单的项目，可做适当调整或合 并。比如，可将用户手册和操作手册合并成用户操作手册；软件需求说明书可包括对数据的要求，从而去掉数据要求说明书；概要设 计说明书与详细设计说明书合并成软件设计说明书等。
l 可追溯性
由于各开发阶段编制的文档与各阶段完成的工作有着紧密的关系，前后两个阶段生成的文档，随着开发工作的逐步 扩展，具有一定的继承关系。在一个项目各开发阶段之间提供文档 必定存在着可追溯的关系。例如，某一项软件需求，必定在设计说明书，测试计划以至用户手册中有所体现。必要时应能做到跟踪追查。
四、配置管理
“配置管理”过程的目的在于运用配置标识、配置控制、配置状态统计和配置审核，建立和维护工作产品的完整性。软件配置管理的目的在于控制软件开发过程中的“变化”，这种变化可能是外部引起的，如需求的变化。也可能是来自于内部的变化，如早期设计的某个部件不够完备，需要修改等。为了控制这些变化，把变化引起的波动尽可能的控制在有限的范围内。
配置项是指需要进行控制的任何文档单元，它可能是需求说明报告，也可能是需求说明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及相关构件。
本系统通过配置管理，确定所选工作产品的配置；这些工作产品构成给定时间点的基线；控制对配置项的变更；为构造配置管理系统的工作产品建立或提供规范；维护基线的完整性；向开发者、最终用户和顾客提供准确的状态和现行配置管理数据。
五、测试
软件测试的定义：根据软件的规格说明及程序结构，设计一批测试用例，运行程序查找程序错误。
软件测试的目的：是要发现程序的错误。一个好的测试用例，就是能发现程序中至今未发现的错误。一个成功的测试就是发现了程序中至今未发现的错误。可以看出，测试的目的是证明程序有错误，而不是为了证明程序是正确的。
软件测试的原则：
1. 要把“尽早地不断地测试”作为座右铭。
2. 测试用例应该同时包括测试输入数据和预期的输出结果。
3. 程序员应避免测试自己的程序。
4. 设计的测试用例应包括合理、有效、可验证程序正确的那些数据，以及不合理的、无效的、证明程序做了不该做的事情的数据。
5. 如果程序中查出的错误越多，则未查出的错误也越多。
6. 仔细检验测试结果
7. 严格执行测试计划
8. 妥善保管测试计划、测试用例和结果，供维护时使用。
一般把测试方法分为两类：白盒法是着眼于逻辑结构，主要是进行结构测试；黑盒法主要着眼于功能。我们的测试人员对应用软件的测试，主要采用的就是黑盒法。在黑盒测试中，边值分析法和因果图法是常用的两种方法。边值分析法是对程序输入输出的边界情况进行测试。具体设计原则是：
1. 如果输入条件规定了取值的范围，应选择正好等于边界的值，略小于最小值和/或略大于最大值的值作为测试数据。
2. 如果输入条件规定了值的个数，应选择最小的个数、最大的个数、略小于最小和略大于最大的个数作为测试数据。
3. 对于输出条件，若规定了取值范围，则可以用类似1中的方法。
4. 对于输出条件，若规定了值的个数，可以使用类似2中的方法。
5. 输入、输出项若是一个有序的集合，则选择第一个元素和最末元素作为测试数据。
因果图法适用于输入条件之间关系比较复杂，不同的条件组合会产生若干动作的情况。通过判定表的形式，可以很好地表达多种条件组合产生不止一个动作，其中输入条件就是因，输出条件就是果。通过对《IC卡水表管理系统》的测试，测试情况分析如下：
1、 手工过多，缺少测试工具，自动化测试方式缺失。传统的项目测试还是以手工为主，测试人员根据需求规格说明书的要求，与测试对象进行“人机对话”。这种测试的弊端为：
l 大量的手工使项目人力成本、沟通成本居高不下；
l 人工操作的低效率使项目耗时增加，带来进度风险；
l 人员素质及其他不确定因素会影响手工测试的结果，导致差错率的增加。
2、 缺乏文档测试、检查
文档是项目的重要产品之一，产品需求、功能分析、架构设计、详细设计、用户手册、维护手册等等，对于项目的测试、上线、维护等过程起到至关重要的参考、指导作用，所以它们的质量应该是项目重点关注点之一。令人遗憾的是，许多软件项目对于文档的重视只停留在口头随着需求不断变更、补充，业务、技术人员忙于应付，无法腾出精力来进行文档内容的修改及完善，往往是将包含需求变更内容的工作联系单往需求文档后一附了事，而不去更新需求与其他相关文档；另一方面，项目变更管理还不够完善，管理重点往往集中于开发，而轻视文档质量管理，未留出充分的文档更新时间，导致文档更新严重滞后于编码进度。为保证文档质量，必须定期进行文档测试，但测试要花成本，项目高层不愿意付此代价。
文档若可读性低，便会影响用户的理解；若与编码不一致，便起不到参考作用，编码测试就没有可靠的测试依据。路都看不清楚，怎么往前走呀？所以，强烈建议进行文档测试，并将其置于测试管理的首位。
当前文档测试的方法没有什么特别的形式，还缺乏测试工具支持，通常是通过静态审查方式“走查”来进行的，主要查看文档的可读性，内容真实性、可靠性、全面性。另外，在项目里程碑时期召集相关领域专家对重要文档进行集中审核，也是一种检查方式。
3、 单元测试引入交叉测试方法
单元测试是对软件基本组成单元进行的测试，测试对象是软件模块。通常，单元测试是由开发人员来完成，而且往往是各人测各人的。这样就存在问题隐患，技术人员是软件模块的制造者，自己来测自己的软件，角色便从制造者变成了审查者，而前一个角色的目的是为了保证软件正确，后一个角色的目的是为了发现更多的缺陷，让一个人同时来扮演两种目的不同的角色，好比让他既当裁判员又当运动员。
解决方法通常有两种，一种是：由测试人员来进行单元测试，这种方式要求测试人员要有较高的软件技术知识；另一种是：将软件人员分组，在模块开发告一段落时进行交叉测试，这种方法只需要测试者了解被测方的软件需求，不需要另外的知识培训，而且测试出发点较为客观。
六、结束语
项目管理是一个系统工程，主要目标是保证项目在规定时间内高质量地完成。软件过程是一个组织实现其软件能力改进的杠杆支点。本文通过对软件过程的质量管理，旨在提高其对软件产品或服务的开发。
参考文献
1、《软件配置管理策略与IBM Rational ClearCase》 作者：[美]David E.Bellagio,
Tom J.Milligan 著， 王海鹏译，人民邮电出版社
2、《软件开发管理的实践》 作者：张少仲，李远明等编著，清华大学出版社
3、《IT项目管理实践》 作者：刘慧，陈虔等编著，电子工业出版社出版
4、《IT项目管理》 作者：（美）凯西.施瓦尔贝著，邓世忠等译,机械工业出版社出版
