软件项目开发全系列规范及约束文件(软件项目测试文档开发)

必须掌握正确的开发手段，了解软件开发的主要过程，这样心中对软件项目才有清醒的认

识，才能达到事半功倍的效果。
本文就软件开发过程中的一些方法，结合本人开发过的一

些软件项目做一些详细论述。

1 开发前的准备工作

一般软件项目在开发前都有系统任务书，主要规定软件的开发目标、主要任务、功能

、性能指标及研制人员和经费、进度等安排，作为系统设计开发和检验的基本依据。

系统任务书的基本框架如下：

（1）引言

包括编写目的，背景，参考资料。

（2）系统的目标及任务

包括系统建设目标，系统的主要任务，系统性能指标，系统标准化要求。

（3）系统的结构及功能

包括系统应用组成及结构，系统主要功能。

（4）系统的规模及进度要求

包括系统规模，系统研制进度，人员计划。

但是系统任务书只是这个软件项目的一个基本要求，针对具体情况，软件开发人员和

需求分析人员就要联合对软件项目的细节进行具体分析，必要时还要进行实地调研，然后

共同商讨写出系统的需求分析，需求分析的编写目的在于：

a.

说明系统在军事方面、技术方面、经济方面和社会条件方面实现的可行性和必要性；

b.

分析原系统（工作环境）现状,描述待开发系统的详细需求，提供用户和开发人员之间沟通

的基础，提供项目设计的基本信息。

需求分析报告的基本框架如下：

（1） 概述

包括 编写目的，背景，参考资料，术语及缩写词。

（2） 对现有系统的分析

（3）待开发系统的详细需求

包括 功能需求，使用范围，业务流程，用户界面，输出要求，故障处理。

（4）使用环境

包括 网络环境，硬件环境，软件环境，与其他系统的关系，安全与保密。

（5） 可行性分析

包括可行性分析，经济可行性分析，人员可行性分析，影响待开发系统的主要因素。

（6）结论意见

2 软件开发过程

有了系统任务书和需求分析报告，软件设计人员就要对软件项目的实现进行系统分析，系统分析包括系统的总体方案，系统的设计说明，作为软件设计的依据。
具体说明如下

2.1 系统总体方案

在系统开发单位和用户充分交互、理解的基础上，提出系统的技术构架，对系统功能

、性能等主要指标作描述，对实现方法和要求作规定，是系统进行详细设计的依据。

系统总体方案基本框架包括：

（1）引言

包括 ：编写目的，背景，参考资料，术语及定义。

（2）项目概述

包括 ：

--项目的主要内容

--系统需求分析：①用户需求调查分析②现行系统的现状调查分析。

--系统功能：①系统的功能要求②系统主要技术性能。

--系统的数据要求：①基础数据②业务数据③交换数据④其它数据。

--系统的设计要求：①技术结构要求②系统划分及其接口要求③系统运行环境要求④

系统标准化综合要求。

（3）实施总计划

包括 ：进度，预算，问题和措施。

2.2 系统设计说明

根据《系统总体方案》提出的系统构架、功能、性能及数据要求，确定系统的物理结

构，说明系统主要技术方面的设计和采用的技术方法以及系统的标准化约束等，是系统实

施的基本依据。
就本人曾经开发过的一个软件项目，说明其基本框架：

（1） 引言

包括 ：编写目的；背景；条件和限制；参考资料；术语及定义。

（2） 系统总体技术方案

包括：

--概述：①系统目标②基本要求。

--系统设计：

①系统结构

a、 应用结构。

b、 功能结构。

c、 技术结构。

② 系统功能设计：根据以上的分析，功能设计自然

包括业务管理功能设计、综合查询功能设计、邮件收发功能设计、数据库接口设计、

文电接口设计。
在对这些功能进行综合分析的基础上，开始进行数据库表的设计。
在对表

的设计过程中，既要考虑到关系数据库冗余字段的处理，又要考虑到系统运行的速度和实

现的方便性等综合因素，笔者在实际开发后认为这两种考虑比例可以为7：3。

③系统安全设计：可以考虑以下一些安全设计思想，例如系统的数据传输通过电子邮件实现

，要求电子邮件内部只传代码，不传涉密数据；系统的数据库操作需要充分利用Oracle数

据库的事务提交和回滚机制，确保业务处理的完整性和一致性；系统的数据结构应充分利

用存储空间，在不同的用户之间通过数据冗余提高整个系统的数据安全性；系统中存贮的

用户口令、备份口令、数据库连接信息等重要数据，必需经过安全加密。

④Oracle数据库自动优化设计：对于Oracle数据库可以进行数据库配置，可以大大提高大数

据量查询速度，笔者已经做过尝试，并已经成功应用。

⑤ 友好界面设计：对于一个良好的应用系统当然需要设计良好的使用界面。

2.3 软件开发

对于开发语言的选择因人而易，开发数据库系统我比较倾向于DELPHI，因为它对于数

据库开发的支持是很完善的。
在软件实现方面，上面已经说明了一种客户/服务器结构，但

是这种结构本身也包含了一些问题，例如客户/服务器结构经常把应用系统的企业逻辑编写

在客户端的应用程序中，因此当应用系统需要改变时，所有在客户端的应用系统都必须改

变，这对于MIS系统的维护来说成本太高了；为了解决这些重复开发应用系统的成本以及为

了增加应用系统的重复使用性发挥面向对象分析/面向对象设计的功能，就必须导入所谓的

应用程序服务器，软件开发人员以一种特定的组件形式，例如Microsoft的COM/DCOM，CORB

A对象，或是Enterprise Java

Bean等，组装企业的逻辑程序代码。
这种经过组装，能够执行特定企业功能的对象便称为\"

企业对象\"，然后把这些企业对象分发到此应用程序服务器。
由于本文不是专门讨论多层系

统的文章，所以只是简单提一下，不再赘述。

程序设计中要注意合理的程序设计结构，可以将所有的公用组件放在一起。
例如Delph

i语言中可以新建一个单元，将所有编写的函数放在这个单元里，其他单元均可以调用，还

可以新建一个数据模块（Datamodule）,将所有的公共数据库控件放在这里，可以减少系统

资源浪费，优化数据库程序设计。

关于程序设计中的技巧很多，这里也不再赘述。

3 软件开发后的工作

软件项目在开发完成后还要进行系统测试，以测试开发出的软件的功能和性能是否达

到预定要求。
项目成功九要素

一般来说，项目完成了既定目标，满足了项目三要素：时间进度、成本控制、质量要求，

就可以认为项目是成功的。
但有时候项目的成果被顾客接受就可以认为成功。
比如在 IT行

业里，产品研发突破原定时间、成本要求的情况非常普遍，但是如果最终项目得以技术实现，

而且被顾客接受，也算做成功。
不过，企业还是应该根据自己的实际情况制定有利于企业发

展的项目成败标准，比如项目延期不超过 30%进度算达标这样的指标。

对于投资类项目，所谓\"项目成功\"具有不同的判别标准，项目本身实现只是一个方面，

项目产生的经济收益，社会影响，环境影响等都会成为评价项目成功程度的指标。
研发类项

目通常已通过项目的客户验收为成功的标志点，投资类则不限于此，可能会在项目完工并运

行一段时间（比如 2年）后进行项目后评价环节，在项目的后评价中最后给出项目成败的最

终评判。

达到项目成功的方法

项目的成败受到四个方面的影响，即项目组内环境、项目所处的组织环境、客户环境、

自然社会环境。
从可控角度，通常需着重考虑前三个方面。
把前三个方面放在整个项目生命

周期进行考察，可以得到影响项目成败的因素。

以下从项目运行环境、项目计划、项目监控及项目沟通、过程改进和技术革新、项目经

理素质等几个方面总结获得项目成功的方法。

要素一、良好的项目运行环境

1） 流程：

最迟在项目启动的前期，应该定义一套适合于具体项目的流程体系，这是项目成功的制

度化保证。
使流程得到不断优化，使用最简的优化流程。

2） 组织机构：

选择合适的项目管理组织架构，以及团队成员选择，建立激励考评机制。
在同一个管理

平台上并行运作多个项目的组织，倾向于选择矩阵式结构；对于项目期限特别长的专项投资

项目也可能选用纯粹项目管理模式；项目存在多个子项目组的复杂协调，且项目存在比较大

的技术瓶颈的项目宜选择强矩阵式，就是有一个全职的项目经理承担管理性工作，以使技术

经理把大部分经理花在攻克技术难关上。

\"人\"是项目成功的最关键因素，选用具备必要技能、能与小组很好融合、具有强的责

任心和事业心的成员进入小组，将极大的促进项目的成功。

把责任、绩效与奖励捆绑在一起，实施目标管理，采取必要的激励措施。
一套行之有效

的激励考评体系将极大调动团队成员的积极性。

3） 内部支持环境

多数情况下，项目组织并不作为一个单独的经济实体存在，它依托于特定的管理平台。

相对于外部客户来说，这属于内部支持环境。
理顺项目运行内环境的内容包括，汇报渠道、

财务联系、人力资源以及公司内部其它职能管理机构的联系。

要素二、强将手下无弱兵

项目经理是项目的灵魂人物，项目经理的素质包括在业务和技术和管理三个方面不断提

升自己、领导能力、市场与客户意识、还要特别关注团队文化的建设。

一个成功的项目经理应该倡导有魅力的团队文化。
现代社会，人们对工作赋予了更多的

精神需求。
一个有魅力的团队文化应该包括认可和尊重、自信和信任、分工协作的良好平衡、

愉快和上进的气氛、遵守共同规范、多层次交流和沟通等。
好的团队文化最终达到吸引人才、

留住人才、激励人才的作用。

要素三、计划先行

\"凡事预则立，不预则?quot;讲的就是项目策划的重要性。
项目策划的结果是形成文档

化的项目计划。
策划阶段是很容易被忽视的阶段，任务书下达后，匆匆忙忙投入到项目中

往往为项目的挫折甚至失败埋下了伏笔。
项目计划应该包括项目内容、时间进度、预算、需

要的各方面支持性条件，项目风险预测等。

需要特别强调的是计划是个动态过程，一定要进行维护，否则计划就名存实亡了。
对于

不确定性很大的活动可以把计划制订的粗一点，然后随着项目的推移周期性的滚动细化，这

就是所谓的\"滚动式计划方法\"，应用此法，可有效的减少计划的维护量。
总之，即使\"计划

赶不上变化\"，但一定要\"跟上变化\"。

仔细鉴别获取的项目基本数据，尽可能进行量化估计将使得计划更加客观科学。
项目基

本数据可能包括以往进行类似项目的工作量数据、效率数据、WBS（工作分解结构）等。

要素四、对控制点进行有力度的管理

使目标管理和过程管理相结合。
过程管理要求有适当的方法提供项目的透明度，消除\"

项目黑箱\"。
所谓\"项目黑箱\"就是管理者只关心和只能了解到项目的输入和输出，项目的运

作过程不了解，项目缺乏控制。
这种状况会带来很大的风险，一旦项目运行存在偏差，只能

在项目完成后被发现，大大增加了纠偏的难度，甚至已无法纠正。
项目的监控大致按照如下

的四个步骤执行：获取项目过程信息、分析判断、采取纠偏措施、验证。

要素五、交流通畅

项目计划、进度和项目范围必须能够被项目成员方便的得到，以确保大家是在统一的平

台上朝者同一个目标前进。
为此，需要建立必要的内部邮件系统或采用适当的图表和模版以

增强沟通效果。

要素六、实事求是的决策

项目运作的过程时刻要记的不要脱离实际，包括各级计划的制定和决策过程中，\"头脑

发热\"或\"市场压力\"形成的不切实际的项目计划往往从计划那一刻就注定要失败的。

此外还应该注意，并不是好的东西就一定适合于自己的项目。
时髦的理念、新颖的方法、

流行的工具并不一定会对项目的成功起促进作用。
项目经理一定要对项目所处的内外环境有

冷静的认识。

要素七、确保项目平稳运作

虽然存在不同项目管理者的管理风格差异，但是总体来说，在项目中引入大的变革尽量

要采取渐进的方式。
这包括过程的改进、新技术的引进和组织架构调整等。
类似的变革应该

进行足够的影响分析。
必要时，可以进行试点和评估，然后再大面积引进。

要素八、项目管理人员责权对等

责权对等是管理学的基本原则。
之所以会出现责权不匹配的情况，多数是因为，上级管

理者不能信任下属的能力和做到有效授权。
项目出现问题进行检讨时，往往才发现项目经理

并不能对所出现的问题负责，问题的根源往往是高层经理在信息不完整的情况下做出的决策

造成的。

要素九、项目委托方的密切配合

项目委托方显然对项目的成功负有一定的责任，特别是项目需求分析阶段。
多数项目都

应该任命委托方项目经理，明确合同双方的责任，对于项目前期的工作给予密切的协作。

那些到了项目验收时才关注项目的业主态度是危险的。

项目成功的 12个关键原则

1、项目经理必须关注项目成功的三个标准

简单地说，一是准时；二是预算控制在既定的范围内；三是质量得到经理和用户们的赞

许。
项目经理必须保证项目小组的每一位成员都能对照上面三个标准来进行工作。

2、任何事都应当先规划再执行

就项目管理而言，很多专家和实践人员都同意这样一个观点：需要项目经理投入的最重

要的一件事就是规划。
只有详细而系统的由项目小组成员参与的规划才是项目成功的唯一基

础。
当现实的世界出现了一种不适于计划生存的环境时，项目经理应制定一个新的计划来反

映环境的变化。
规划、规划、再规划就是项目经理的一种生活方式。

3、项目经理必须以自己的实际行动向项目小组成员传递一种紧迫感

由于项目在时间、资源和经费上都是有限的，项目最终必须完成。
但项目小组成员大多

有自己的爱好，项目经理应让项目小组成员始终关注项目的目标和截止期限。
例如，可以定

期检查，可以召开例会，可以制作一些提醒的标志置于项目的场所。

4、成功的项目应使用一种可以度量且被证实的项目生命周期

标准的信息系统开发模型可以保证专业标准和成功的经验能够融入项目计划。
这类

模型不仅可以保证质量，还可以使重复劳动降到最低程度。
因此，当遇到时间和预算压力需

要削减项目时，项目经理应确定一种最佳的项目生命周期。

5、所有项目目标和项目活动必须生动形象地得以交流和沟通

项目经理和项目小组在项目开始时就应当形象化地描述项目的最终目标，以确保与

项目有关的每一个人都能记住。
项目成本的各个细节都应当清楚、明确、毫不含糊，并确保

每个人对此都达成了一致的意见。

6、采用渐进的方式逐步实现目标

如果试图同时完成所有的项目目标，只会造成重复劳动，既浪费时间又浪费钱。
俗

话说，一口吃不成个胖子。
项目目标只能一点一点地去实现，并且每实现一个目标就进行一

次评估，确保整个项目能得以控制。

7、项目应得到明确的许可，并由投资方签字实施

在实现项目目标的过程中获得明确的许可是非常重要的。
应将投资方的签字批准视

为项目的一个出发点。
道理很简单：任何有权拒绝或有权修改项目目标的人都应当在项目启

动时审查和批准这些项目目标。

8、要想获得项目成功必须对项目目标进行透彻的分析

研究表明，如果按照众所周知记录在案的业务需求来设计项目的目标，则该项目多

半会成功。
所以，项目经理应当坚持这样一个原则，即在组织机构启动项目之前，就应当为

该项目在业务需求中找到充分的依据。

9、项目经理应当责权对等

项目经理应当对项目的结果负责，这一点并不过分。
但与此相对应，项目经理也应

被授予足够的权利以承担相应的责任。
在某些时候，权利显得特别重要，如获取或协调资源，

要求得到有关的中小企业的配合，做相应的对项目成功有价值的决策等等。

10、项目投资方和用户应当主动介入，不能被动地坐享其成

多数项目投资方和用户都能正确地要求和行使批准（全部或部分）项目目标的权力。

但伴随这个权力的是相应的责任——主动地介入项目的各个阶段。
例如，在项目早期要帮助

确定项目目标；在项目进行中，要对完成的阶段性目标进行评估，以确保项目能顺利进行。

项目投资方应帮助项目经理去访问有关的中小企业和目标顾客的成员，并帮助项目经理获得

必要的文件资料。

11、项目的实施应当采用市场运作机制

在多数情况下，项目经理应将自己看成是卖主，以督促自己完成投资方和用户交付

的任务。
项目计划一旦批准项目经理应当定期提醒项目小组成员该项目必须满足的业务需求

是什么，以及该怎样工作才能满足这些业务需求。

12、项目经理应当获得项目小组成员的最佳人选

最佳人选是指受过相应的技能培训，有经验，素质高。
对于项目来说，获得最佳人

选往往能弥补时间、经费或其它方面的不足。
项目经理应当为这些最佳的项目成员创造良好

的工作环境，如帮助他们免受外部干扰，帮助他们获得必要的工具和条件以发挥他们的才能。

1、用分阶段的生命周期计划严格管理

有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把建

立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。

在软件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作。
这条基本原理

意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严

格按照计划对软件的开发与维护工作进行管理。
Boehm 认为，在软件的整个生命周期中应该

制定并严格执行六类计划，它们是项目概要计划，里程碑计划，项目控制计划，产品控制计

划，验证计划，运行维护计划。
不同层次的管理人员都必须严格按照计划各尽其职地管理

软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。

2、坚持进行阶段评审

当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。
这样说至少

有两个理由：第一，大部分错误是在编码之前造成的，例如，根据 Boehm 等人的统计，设

计错误占软件错误的 63%，编码仅占 37%；第二，错误发现与改正得越晚，所需付出的代价

也越高。
因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，

是一条必须遵循的重要原则。

3、实行严格的产品控制

在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价，但

是，在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是

一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技

术来顺应这种要求。
也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须

实行严格的产品控制，其中主要 是实行基准配置管理。
所谓基准配置又称基线配置，它们

是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。
基准配置管理也称

为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照

严格的规程进行评审，获得批准以后才能实施修改。
绝对不能谁想修改软件（包括尚在开发

过程中的软件），就随意进行修改。

4、采用现代程序设计技术

从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。
60

年代末提出的结构程序设计技术，已经成为绝大多数人公认的先进的程序设计技术。
以后又

进一步发展出各种结构分析（SA）与结构设计（SD）技术。
实践表明，采用先进的技术既可

提高软件开发的效率，又可提高软件维护的效率。

5、结果应能清楚地审查

软件产品不同于一般的物理产品，它是看不峥摸不着的逻辑产品。
软件开发人员（或开

发小组）的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产

品的开发过程更难于评价和管理。
为了提高软件开发过程的可见性，更好地进行管理，应该

根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到

的结果能够清楚地审查。

6、开发小组的人员应该少而精

这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。

开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。
素质高的人员的开

发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中

的错误明显少于素质低的人员所开发的软件中的错误。
此外，随着开发小组人员数目的增加，

因为交流情况讨论问题而造成的通信开销也急剧增加。
当开发小组人员数为 N时，可能的通

信路径有 N（N?/FONT>1）/2条，可见随着人数 N的增大，通信开销将急剧增加。
因此，组

成少而精的开发小组是软件工程的一条基本原理。

7、承认不断改进软件工程实践的必要性

遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但

是，仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技

术的不断进步。
l因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程

的第七条基本原理。
按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断

总结经验，例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等等。
这些数据

不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该

优先研究的技术

软件工程控制的重要性

软件开发过程问题多多，且并不因软件开发工具的完善而有大的改善，软件工程控制的

重要性越来越被重视。
软件开发过程的问题常有如下几种：

（1）对软件开发成本和进度的估计常常很不准确。
实际成本比估计成本有可能高出一

个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。
这种现象降低了软件

开发组织的信誉。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的

质量，从而不可避免地会引起用户的不满。

（2）用户对\"已完成的\"软件系统不满意的现象经常发生。
软件开发人员常常在对用

户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就仓促上阵匆忙

着手编写程序。
软件开发人员和用户之间的信息交流往往很不充分，\"闭门造车\"必然导致

最终的产品不符合用户的实际需要。

（3）软件产品的质量往往靠不住。
软件可靠性和质量保证的确切的定量概念刚刚出现

不久，软件质量保证技术（审查、复审和测试）还没有坚持不懈地应用到软件开发的全过程

中，这些都导致软件产品发生质量问题。

（4）软件常常是不可维护的。
很多程序中的错误是非常难改正垢，实际上不可能使这

些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。
\"可重

用的软件\"还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或

基本类似的软件。

（5）软件通常没有适当的文档资料。
计算机软件不仅仅是程序，还应该有一整套文档

资料。
这些文档资料应该是在软件开发过程中产生出来的，而且应该是\"最新式的\"（即和

程序代码完全一致的）。
软件开发组织的管理人员可以使用这些文档资料作为\"里程碑\"，

来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件

开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是至关重要必不可少

的。
缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难

和问题。

（6）软件成本在计算机系统总成本中所占的比例逐年上升。
由于微电子学技术的

进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成

本随着通货膨胀以及软件规模和数量的不断扩大而持续上升。
美国在 1985年软件成本大约

已占计算机系统总成本的 90%。

（6）软件成本在计算机系统总成本中所占的比例逐年上升。
由于微电子学技术的进步

和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随

着通货膨胀以及软件规模和数量的不断扩大而持续上升。
美国在 1985年软件成本大约已占

计算机系统总成本的 90%。

（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
软件

产品\"供不应求\"的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

软件文档的作用和分类

软件文档(document)也称文件，通常指的是一些记录的数据 和数据媒体，它具有固定

不变的形式，可被人和计算机阅读。
它和 计算机程序共同构成了能完成特定功能的计算机

软件(有人把源 程序也当作文档的一部分)。
我们知道，硬件产品和产品资料在整 个生产过

程中都是有形可见的，软件生产则有很大不同，文档本 身就是软件产品。
没有文档的软件，

不成其为软件，更谈不到软件 产品。
软件文档的编制(documentation)在软件开发工作中占

有突 出的地位和相当的工作量。
高效率、高质量地开发、分发、管理和维 护文档对于转让、

变更、修正、扩充和使用文档，对于充分发挥软 件产品的效益有着重要意义。

然而，在实际工作中，文档在编制和使用中存在着许多问 题，有待于解决。
软件开发

人员中较普遍地存在着对编制文档不感 兴趣的现象。
从用户方面看，他们又常常抱怨：文

档售价太高、文 档不够完整、文档编写得不好、文档已经陈旧或是文档太多，难于 使用等

等。
究竟应该怎样要求它，文档应该写哪些，说明什么问 题，起什么作用?这里将给出简要

的介绍。

图 文档桥梁作用

文档在软件开发人员、软件管理人员、维护人员、用户以及计 算机之间的多种桥梁作，软件开发人员在各 个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依 据，这个作用是显而易见的。
软件开发过程中软件开发人员需制定 一些工作计划或工作报告，这些计划和报告都要提供给管理人员， 并得到必要的支持。

管理人员则可通过这些文档了解软件开发项 目安排、进度、资源使用和成果等。
软件开发人员需为用

户了解软 件的使用、操作和维护提供详细的资料，我们称此为用户文档。
以 上三种文档构

成了软件文档的主要部分。
我们把这三种文档所包 括的内容列在图 6中。
其中列举了十三

个文档，这里对它们作 一些简要说明：

可行性研究报告：说明该软件开发项目的实现在技术上、经 济上和社会因素上的可行

性，评述为了合理地达到开发目标可供 选择的各种可能实施的方案，说明并论证所选

定实施方案的理 由。

项目开发计划：为软件项目实施方案制定出具体计划，应 该包括各部分工作的负责人

员、开发的进度、开发经费的预算、所 需的硬件及软件资源等。
项目开发计划应提供

给管理部门，并作 为开发阶段评审的参考。

软件需求说明书：也称软件规格说明书，其中对所开发软 件的功能、性能、用户界面

及运行环境等作出详细的说明。
它是用 户与开发人员双方对软件需求取得共同理解基

础上达成的协议， 也是实施开发工作的基础。

数据要求说明书：该说明书应给出数据逻辑描述和数据采 集的各项要求，为生成和维

护 系统数据文卷作好准备。

概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块

划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处

理 设计等，为详细设计奠定基 础。

详细设计说明书：着重 描述每一模块是怎样实现的， 包括实现算法、逻辑流程等。

用户手册：本手册详细 描述软件的功能、性能和用户 界面，使用户了解如何使用该软件。

文档编制的质量要求

为了使软件文档能起到前节所提到的多种桥梁作用，使它有 助于程序员编制程序，有

助于管理人员监督和管理软件开发，有助 于用户了解软件的工作和应做的操作，有助于维

护人员进行有效 的修改和扩充，文档的编制必须保证一定的质量。
质量差的软件文 档不仅

使读者难于理解，给使用者造成许多不便，而且会削弱对 软件的管理(管理人员难以确认和

评价开发工作的进展)，增高软 件的成本(一些工作可能被迫返工)，甚至造成更加有害的后

果(如误操作等)。

造成软件文档质量不高的原因可能是：

缺乏实践经验，缺乏评价文档质量的标准。

不重视文档编写工作或是对文档编写工作的安排不恰当。

最常见到的情况是，软件开发过程中不能按表 5给出的进度， 分阶段及时完成文档的

编制工作，而是在开发工作接近完成时集 中人力和时间专门编写文档。
另一方面，和程序

工作相比，许多 人对编制文档不感兴趣。
于是在程序工作完成以后，不得不应付 一下，把

要求提供的文档赶写出来。
这样的做法不可能得到高质 量的文档。
实际上，要得到真正高

质量的文档并不容易，除去应在 认识上对文档工作给予足够的重视外，常常需要经过编写

初稿， 听取意见进行修改，甚至要经过重新改写的过程。

高质量的文档应当体现在以下一些方面：

①针对性；文档编制以前应分清读者对象，按不同的类型、不 同层次的读者，决定怎

样适应他们的需要。
例如，管理文档主要是 面向管理人员的，用户文档主要是面向用户的，

这两类文档不应 像开发文档(面向软件开发人员)那样过多地使用软件的专业术语。

②精确性：文档的行文应当十分确切，不能出现多义性的描 述。
同一课题若干文档内

容应该协调一致，应是没矛盾的。

⑧清晰性：文档编写应力求简明，如有可能，配以适当的图 表，以增强其清晰性。

④完整性：任何一个文档都应当是完整的、独立的，它应自成 体系。
例如，前言部分

应作一般性介绍，正文给出中心内容，必要 时还有附录，列出参考资料等。
同一课题的几

个文档之间可能有些 部分相同，这些重复是必要的。
例如，同一项目的用户手册和操作 手

册中关于本项目功能、性能、实现环境等方面的描述是没有差别 的。
特别要避免在文档中

出现转引其它文档内容的情况。
比如，一 些段落并未具体描述，而用\"见××文档××节\"

的方式，这将给 读者带来许多不便。

⑤灵活性：各个不同的软件项目，其规模和复杂程度有着许 多实际差别，不能一律看

待。
图 6所列文档是针对中等规模 的软件而言的。
对于较小的或比较简单的项目，可做适

当调整或合 并。
比如，可将用户手册和操作手册合并成用户操作手册；软件需 求说明书可

包括对数据的要求，从而去掉数据要求说明书；概要设 计说明书与详细设计说明书合并成

软件设计说明书等。

文档的管理和维护

在整个软件生存期中，各种文档作为半成品或是最终成品， 会不断地生成、修改或补

充。
为了最终得到高质量的产品，达到上 节提出的质量要求，必须加强对文档的管理。
以

下几个方面是应注意做到的：

①软件开发小组应设一位文档保管人员，负责集中保管本 项目已有文档的两套主文本。

两套文本内容完全一致。
其中的一套可按一定手续，办理借阅。

②软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。
这些一般都应是

主文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。

③开发人员个人只保存着主文本中与他工作相关的部分文档。

④在新文档取代了旧文档时，管理人员应及时注销旧文档。
在文档内容有更动时，管

理人员应随时修订主文本，使其及时反映更新了的内容。

⑤项目开发结束时，文档管理人员应收回开发人员的个人文档。
发现个人文档与主文本

有差别时，应立即着手解决。
这常常是未及时修订主文本造成的。

⑥在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文

本的修改必须特别谨慎。
修改以前要充分估计修改可能带来的影响，并且要按照：提议、评

议、审核、批准和实施等步骤加以严格的控制。

程序文档合一与动态文档

很多企业已经建立了许多庞大的计算机管理系统，而且将不断地推出新的系统。
满足经

营的需求须不断维护、改造计算机系统，但同时又要不影响现行生产，所以必须建立一整套

机制来评价、控制和完成对系统的维护。
在软件维护过程中，提出程序与文档合一的概念在

软件开发的同时建立动态文档。

程序与文档合一概念的提出

一、目前软件的状况

程序与文档的形式分离，不仅是用各自独立的形式存放，而且使用不同的工具在不同的

时间里书写和检索。
维护程序时不能方便地得到文档的帮助，不能同步修改文档。

程序与文档的内容分离，由于程序与文档采用不同的描述，既有计算机语言也有自然语

言。
维护过程中不能及时、一致地更新文档或程序，使文档不能准确地描述程序而几乎成为

废纸甚至带来负面价值。

软件开发与维护的分离，绝大多数软件在设计、开发时不太考虑以后可能的修改，加大

了软件维护的难度，而且使维护容易引入新的错误。

这些分离也表现在设计、开发的不同阶段的文档之间的不相容性，例如：需求分析说明

书是纸上的东西，在概要设计阶段不能很好地继承、利用需求分析说明书，设计、编制概要

设计时必须从零开始，需要重新分析、理解需求分析，这种思维上的脱节，不仅延缓开发进

度、加重设计人员的负担，而且由于理解上的不同导致不同阶段描述的对象有许多不相容情

况。
这些分离使得文档在系统的设计、开发、维护中的作用下降，这也是很多软件人员不愿

意编写文档的主要原因。

怎样才是好的文档系统呢？应当具备以下属性：

1. 能够准确地描述软件、并且简单易懂；

2. 能够迅速错误定位、影响分析、修正设计；

3. 能够提高软件维护质量；

4. 能够方便程序修改时理解程序。

为此提出了程序与文档合一的概念。
这概念使软件成为真正意义上的软件：程序+文档，

程序就是文档，文档集成在程序中。
它要求在选择开发环境时不仅要考虑环境对设计、开发

的完美支持，而且要考虑对维护、文档的支持；它要求软件人员在设计、开发过程中要考虑

维护问题、文档问题；它要求程序与文档存储在同一位置、同一系统中；它要求使用相同工

具进行程序与文档的书写、检索；它要求在编写和维护程序的同时形成文档，在书写文档时

编写、维护程序。
程序与文档合一的概念不仅存在于系统的设计、开发阶段而且存在于系统

的维护阶段，它贯穿软件的生命周期。

动态文档系统是建立在程序与文档合一的概念基础上的、文档与程序一致的、简单易懂

的联机文档系统。
它包括构件说明与数据描述、对构件与构件之间、构件与数据之间的关系

进行的描述。
动态文档系统是提高了文档的可用性、易用性和连贯性，使文档更加有效，是

解决维护问题的有效途径。

动态文档系统问题分析

需要解决的问题是：软件文档的内容划分与获取、文档的存储与维护、文档的检索、软

件文档的生成打印。

一、软件文档的内容划分成：语义文档、结构文档、过程文档

语义文档是对软件的功能、概念、总体设计、流程、规约等用自然语言的描述，是软件

人员根据规范在使用 CASE工具编写并填入程序的文档，它也是为更全面的解释文档而灵活

加入的额外信息。

结构文档是在软件设计工具、开发环境中对象的属性、构件间接口、构件间引用关系、

软件的结构等的描述。
利用词法、语法分析程序对整个系统的对象、构件进行识别、分析，

获取上述描述并形成表格文件。

过程文档是对软件的设计、编码、维护过程中形成的过程描述和程序注释，如设计目的、

设计人、时间等说明，利用开发环境对软件人员在设计、开发、维护过程中操作的记录形成

操作跟踪。

根据程序与文档合一的概念和文档从程序中提取的要求，文档必须存放在程序中，甚至

文档固有的源代码中。
结构如此的程序源代码的存储必须采用一种新技术—对象仓储

（Repository）技术，而不能采用流式文件，这样才能使程序与文档既结合又分离。
程序与

文档结合在一个对象仓储中，结合在统一的开发环境中；结合在修改代码时可以同时修改文

档、修改文档时可以同时人工检查和修改程序，并在多次文档生成而不会丢失手工输入的文

档。
程序与文档应当分别存放在对象仓储中的不同表或不同的字段中，在编译与运行时分离。

三、文档的检索

对单个对象、构件文档的检索方式是若于文档存放在一个对象仓储中，它可以随源代码

一起检索和维护。
这种检索给分析和维护单个构件、对象提供文档支持。
建立多种视图、编

写程序对整个系统进行文档的检索和获取，完成对整个系统的分析，对整个系统进行实时文

档支持。
这将在例子中较详细的描述。

四、软件文档的生成打印

编写程序检索和获取整个系统的文档，按照国家软件标准的文档式样建立文档模板并将

按模板生成文档和利用文字处理软件强大的功能进行创建、编辑文档并打印。

根据上述分析，文档分布和获取对开发环境提出了要求：开发环境应该是设计工具、开

发工具的集成，应该基于 CASE技术、对象仓储技术、构件技术、OLE技术。
基于 CASE技术

的开发环境；设计、开发、维护过程中形成的文档并植入程序代码中，使文档成为程序的一

部分。
基于对象仓储技术的开发环境，将文档与程序统一存储在对象仓储中方便检索。
基于

构件技术的开发环境，便于识别、获取构件，分析、形成结构文档和过程文档。
基于 OLE

等技术使文档可以很好地利用 Word等文档处理软件。

动态文档系统的一个应用实例

广州电信科技开发有限公司自行设计、开发的名为九七系统的庞大的电信管理计算机系

统自 1997年投产验收后，将长期用于生产，维护工作非常重要和紧迫。
这为动态文档系统

提供了需求和试验场所。
在长期维护的过程中，体会到好文档的重要性并提出了程序文档合

一的概念，这为动态文档系统提供了理论基础。
九七系统是使用 Uniface开发环境。
这种开

发环境采用了 CASE技术、对象仓储技术、构件技术，这为动态文档系统提供了技术支撑。

一、广州电信动态文档系统的建立步骤

1. 理解 Uniface、Oracle工具的开发环境，规划语义文档在各级对象中存放的表与字

段，并根据工具的特性制定填写的规则。

2. 寻找结构文档、过程文档在 Uniface、Oracle工具中存放的表与字段。

3. 在设计、开发和维护软件的过程中对这些表或字段按照规则进行填写。

4. 建立一整套模板使文档结构与信息源建立映像，包括：数据字典模板、设计文档模

板、结构文档模板、开发过程文档模板等。

5. 将这些模板组装成文档系统，并使它独立于开发目标系统。

广州电信动态文档系统的组成可以分为文档查询、维护记录查询、文档生成。

文档查询不仅包括构件说明与数据描述，而且包括对构件与数据之间的关系的描述，是

实时的联机文档查询系统。
维护记录查询是对软件维护过程中的各个环节进程进行记录与追

踪，用于规范维护工作。
它包括问题报告、问题分析、错误定位、维护设计、维护执行、确

认测试、维护评审、维护提交、问题跟踪等。
文档生成则是根据需要实时生成软件设计说明

书。

二、程序与文档合一概念与动态文档系统的意义

广州电信动态文档系统的基本任务是辅助错误定位、维护影响分析、记录维护进程、生

成文档。
使用 Uniface的开发环境开发的，可以安装在用 Uniface开发的不同的应用系统中。

该系统已经在九七计费系统的维护中发挥重要作用。

它推崇的程序与文档合一的概念，提出文档就是程序，程序就是文档的思路，文档融合

在程序中的构思并已实现，这一概念指导了软件人员进行有效地工作。
合一的概念贯穿了设

计、开发、维护整个软件周期，保证了文档之间的继承性和一致性，在设计、开发每一阶段

是继承前阶段的程序和文档的结果。
这样极大地消除了程序与文档、文档与文档之间的不一

致性，加快了软件设计进度，提高了软件开发、维护的质量。
它是软件工程在具体应用中的

一种尝试，它从程序文档合一的角度出发，进一步规范软件设计、开发、维护。
程序文档合

一的概念为软件开发环境发展提供了一种思路；设计更好的对象仓储来满足开发、维护人员

对程序文档合一的概念的需求。

动态文档系统的局限与发展

广州电信动态文档系统有很大的局限性，只能用于 Uniface或 Oracle开发的系统中。

目前的广州电信动态文档系统的构件的识别与获取主要依赖开发工具提供的构件和构件的

特征进行识别的。
这种动态文档系统难以在一些 3GL工具—未使用对象仓储技术、构件技术

开发的软件—中实现程序与文档的合一与分离。
大型软件系统的环境是复杂的，往往采用了

多种开发环境，如何对其他开发环境进行支持还要进行技术探讨和实践上的摸索。

另一个局限问题是目前的动态文档系统描述的是程序文档，其主要在编码、维护的过程

中进行建设，系统进入维护阶段使用。
如何使动态文档系统不仅对软件维护阶段进行支持，

而且对软件的设计、开发阶段进行更多的支持？一种可能的解决途径是将软件复用技术拓宽

到包括文档复用，包括程序复用、程序文档复用和设计文档复用，而且将动态文档系统建立

在基于这种软件复用系统之上。

我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的三种不同倾向

或观点。
这三种倾向是：产品运行、产品修改和产品转移。
信息系统作为一个产品，也可以

参照这三种倾向来定义。

我们可以采取以下步骤实施全面质量控制：

1．实行工程化开发

\"信息系统开发方法\"一词的广义理解是\"探索复杂系统开发过程的秩序\"；狭义理解

是\"一组为信息系统开发起工具作用的规程\"，按这些规程工作，可以较合理地达到目标。

规程由一系列活动组成，形成方法体系。
信息系统是一项系统工程，必须建立严格的工程控

制方法，要求开发组的每一个人都要遵守工程规范。

2．实行阶段性冻结与改动控制

信息系统具有生命周期，这就为我们划分项目阶段提供了参考。
一个大项目可分成若干

阶段，每个阶段有自已的任务和成果。
这样一方面便于管理和控制工程进度，另一方面可以

增强开发人员和用户的信心。

在每个阶段末要\"冻结\"部分成果，作为下一阶段开发的基础。
冻结之后不是不能修改，

而是其修改要经过一定的审批程序，并且涉及到项目计划的调整。

3．实行里程碑式的审查与版本控制

里程碑式审查就是在信息系统生命周期每个阶段结束之前，都正式使用结束标准对该阶

段的冻结成果进行严格的技术审查，如果发现问题，就可以及时在阶段内解决。

版本控制是保证项目小组顺利工作的重要技术。
版本控制的含义是通过给文档和程序文

件编上版本号，记录每次的修改信息，使项目组的所有成员都了解文档和程序的修改过程。

广义的版本控制技术称为软件配制管理，并已有功能完善的软件工具支持，如 PVCS和

Microsoft Visual SourceSafe。

4．实行面向用户参与的原型演化

在每个阶段的后期，快速建立反映该阶段成果的原型系统，通过原型系统与用户交互，

及时得到反馈信息，验证该阶段的成果并及时纠正错误，这一技术被称为\"原型演化\"。
原

型演化技术需要先进的 CASE工具的支持。

5． 尽量采用面向对象和基于构件的方法

面向对象的方法强调类、封装和继承，能提高软件的可重用性，将错误和缺憾局部化，

同时还有利于用户的参与，这些对提高信息系统的质量都大有好处。

基于构件的开发又被称为\"即插即用编程\"方法，是从计算机硬件设计中吸收过来的优

秀方法。
这种编程方法是将编制好的\"构件\"插入已做好的框架中，从而形成一个大型软件。

构件是可重用的软件部分，构件既可以自己开发，也可以使用其他项目的开发成果，或者直

接向软件供应商购买。
当我们发现某个构件不符合要求时，可对其进行修改而不会影响其他

构件，也不会影响系统功能的实现和测试，就好像整修一座大楼中的某个房间，不会影响其

他房间的使用。

6．全面测试

要采用适当的手段，对系统调查、系统分析、系统设计、实现和文档进行全面测试。

7．引入外部监理与审计

要重视信息系统的项目管理，特别是项目人力资源的管理，因为项目成员的素质和能力

以及积极性是项目成败的关键。
同时还要重视第三方的监理和审计的引入，通过第三方的审

查和监督来确保项目质量。

我们常说某某软件好用，某软件功能全、结构合理、层次分明。
这些表述很含糊，用来

评价软件质量不够确切，不能作为企业选购软件的依据。
对于企业来说，开发单位按照企业

的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅

仅满足这些是远远不够的。
因为企业在引进一套软件过程中，常常会出现如下问题：

• 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加；

• 企业对外购的软件质量存在怀疑，企业评价软件质量没有恰当的指标，对软件可靠

性和功能性指标了解不足；

• 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。
因为

没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开

发商的工作质量。

为此，有必要先了解软件的质量评价体系。
美国的 B.W.Ｂoehm和 R.Brown 先后提出了

三层次的评价度量模型：软件质量要素、准则、度量。
随后 G.Mruine提出了自己的软件质

量度量 SQM技术，波音公司在软件开发过程中采用了 SQM技术，日本的 NEC公司也提出了自

己的 SQM工具，即 SQMAT，并且在成本控制和进度安排方面取得了良好的效果。

第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征：

1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足

用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。

2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。
可靠性对某些

软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发

生时能继续运行的程度。

3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的

程度。
易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。

4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有

效程度。
效率反映了在完成功能要求时，有没有浪费资源，此外＂资?quot;这个术语有比较

广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。

5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，

进行相应修改所做的努力程度。
可维修性反映了在用户需求改变或软件环境发生变更时，对

软件系统进行相应修改的容易程度。
一个易于维护的软件系统也是一个易理解、易测试和易

修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。

6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。

运用全面质量管理提高软件质量

当前软件产品开发过程中出现的质量问题，可以认为是由以下原因导致的：

1、管理者缺乏质量观念，没有保证质量的全面计划、有效措施，未将质量放在足够重

要的地位，未从一开始就强调质量。

2、开发者未将保证质量作为他们的重要而且是必须完成的任务，把保证产品质量看成

是质量检测人员的责任。
缺乏全面质量管理、人人都是质量保证者和责任人的观念。

3、大家都缺乏这种观念：在每个产品开发阶段都不做出不合格工作，决不把不合格的

中间产品带到下一阶段，而不是到产品最后阶段才由专门的质量检测人员检查并保证产品质

量。
这就需要明确制定每一阶段工作的检测标准，让大家知道什么才是合格的工作。

4、没有良好的激励机制。
没有将个人的所得（物质和心理两方面）与其工作绩效直接

联系起来。
也没有好的个人绩效评价机制。
做不好是大家整体的责任，自己的利益不受影响。

做好了也没有及时明显的奖励。
总之，做好做不好差不多，大家没有积极性，没有人会拼命

高质量地完成自己的工作。

5、大家看不到提高质量对公司的生存发展有多重要，普遍缺乏主人翁责任感。

6、显然，不单单是质量问题。
还有管理者和开发者的关系问题。
例如因为管理者的指

示未得到切实地执行，才导致版本不一致等问题。
又比如管理者强调质量和维护质量的措施

会引起开发者的反感。
如果大家能很好地交流和合作，此类问题会大大减少。

7、大家对顾客的质量要求不了解，不理解顾客的心理，缺乏使顾客满意的思想。

什么是 TQM？

TQM是一种思想观念，一套方法、手段和技巧，通过全体员工的参与、改进流程、产品、

服务和公司文化，达到在百分之百时间内生产百分之百的合格产品，以便满足顾客需求

（CustomerSatisfaction,CS），从而获取竞争优势和长期成功。

TQM的要点是什么？

1、客户满意

顾客包括两种：外部顾客和内部顾客。
外部顾客指公司产品的最终用户。
内部顾客指在

公司内部和自己的工作有联系的那些人。

2、全员参与

质量不仅仅是 QA,Tester,LanguageConsultant的事，每一个员工都有维护质量的责任。

每个员工都有责任、也有权利提出改进建议，并将合理的建议付诸实施。

3、团队精神

TQM要求全体成员之间的有效交流，紧密合作。
管理者要改变发号施令的角色，变成教

练、协调人、组织者。

4、百分之百的优质

任何一个小错误都可能造成大的损失。
只有消除侥幸心理，时刻追求百分之百的优质，

才能实现 TQM，充分满足顾客需求。

5、贯彻始终

在产品开发的每一个阶段都应实行全面的质量管理，而不是仅在某一阶段。

6、事前主动

防患于未然。
经常组织讨论，主动寻找出可能发生的问题，并及时加以解决。

7、持续改进

实施 TQM不可能毕其功于一役。
必须坚持持续改进，将 TQM融入日常的工作和管理。

TQM实施的步骤有哪些？

1、进行全面质量管理思想的教育

对全体员工进行全面质量管理思想的教育，以达到以下目的：

1）将满足顾客的需求放在首位

要让每个人深刻理解\"顾客满意\"的思想。
为了理解并实行\"顾客满意\"的思想，可以

将员工分组进行\"换位思维\"，并讨论清楚如下问题：

所有参与产品开发的人员：如果自己是个顾客，对产品的质量是怎么要求的？希望自己

得到什么样的服务？

管理人员：如果自己是个开发者，对开发过程中遇到的问题会有何想法？希望得到什么

样的帮助和理解？希望管理者如何对待自己？

开发者：假如自己是个管理者，会如何管理整个开发过程？对开发中出现的问题怎么

看？知道它们的起源和解决方法么？

要鼓励大家以自己希望得到的那种服务方式去为自己的顾客服务，要将每个人都作为自

己的一个重要顾客，想方设法是其满意。
比如，CourseDesigner要提供足够清晰的 Script

及必要解释，使 GraphicDesigner清楚该画什么样的图，让他们满意，让他们愉快地进行下

一步的工作。

2）明白提高质量与降低成本的关系

质量提高，不仅不会提高成本，反而会降低成本。
这是因为：质量高了，会减少反复修

改的时间，缩短开发周期，降低人力资本。
还会提高士气，提高工作效率。

3）树立百分之百合格产品的责任感

使百分之百的员工成为抓质量的主人。
要达到此种境界：当问一个员工\"谁负责产品的

质量？\"时，得到的回答是\"我！
\"，而不是\"Tester\"或\"QA\"或其它。
让大家明白：如果

存在任何问题，都会最终出现并影响产品质量和公司形象。
在开始阶段的问题不解决，只能

在最后的阶段以更高的代价解决。
教育员工树立百分之百合格产品的责任感，消除侥幸心理。

2、明确顾客需求

搞清楚什么样的产品是让用户满意的产品。

3、了解市场

经常将别的厂商的产品向大家展示，并进行研究，让大家明白别人是怎么做得，我们有

何差距。

4、让员工明白什么是好的产品

给出样板，进行足够的培训，让大家都真正明白什么是好的合格的产品。

5、建立明确的质量基准和质量测评制度

产品好坏一定要有一个明确公开的标准来衡量。
每个人都可以把自己的工作结果与之对

照，从而知道自己做得是好是坏。
而且这种标准要以一种制度的形式切实付诸实施，才能增

加可信度。

6、建立相对完善的激励机制

如果检测的结果对个人的利益无任何影响，则员工没有尽力提高质量的动力。
要在物质

和精神方面对员工根据他们的绩效进行不同的激励。

7。
帮助质量检测部门变成提高质量的催化剂

改变质检人员\"挑问题者\"的角色，消除 Tester,QA同开发者之间的隔阂和对立。
可以

采取三种措施：

让质检人员与开发者一起参加有关培训，使他们彼此更好地理解对方的工作。

让质检人员成为开发小组的一部分，让小组成员有更多的了解。

提高质检人员与开发者的沟通技巧。

8、建立一套明确一致的解决问题的方法

一旦出现问题，大家能够按照此方法去解决问题，而不是互相埋怨或手足无措。

解决问题常用的 6步法：

讨论并确定问题

找出问题的根源

提出可能的解决方法

选择最佳办法

建议、批准和实施

测试、评估、调整和庆贺

9、在全体员工中培育主人翁意识和敬业精神

如果大家都抱着\"公司不是我的，我是来打工的，公司效益好坏、能够存活发展与我无

关\"，产品质量如何提高，公司如何搞好？

10、让员工有一定的自由和权利

有了权利，才会有主动性。
允许员工提出问题，解决问题，并将解决方案付诸实施。
如

果什么问题都要 Leader来决定，大家只有消极工作和等待。

11、建立质量小组

质量小组由不同角色的人员组成，负责发现质量问题，讨论解决方法，提出并实施解决

方案。

12、加强 Teamwork的培训

培训员工，尤其是 Leader如何有效地制定 Team'sgoal，如何不断增强这个 goal，如何

始终围绕这个 goal工作。
教给大家如何更好地交流，如何更好地合作，如何在解决问题时

对事不对人。

八项质量管理原则

为了成功地领导和运作一个组织，需要采用一种系统和透明的方式进行管理。
针对所有

相关方的需求，实施并保持持续改进其业绩的管理体系，使组织获得成功。
组织为实现质量

目标，应遵循以下八项质量管理原则。

原则 1： 以顾客为中心

组织依存于其顾客。
因此，组织应理解顾客当前的和未来的需求，满足顾客要求并争取

超越顾客期望。

1、 组织实施本原则的主要利益

2、 组织实施本原则时一般要采取的主要措施

3、 本原则在标准中的体现

原则 2： 领导作用

领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参与实现组织

目标的环境。

1、 组织实施本原则的主要利益

2、 组织实施本原则时一般要采取的主要措施

3、 本原则在标准中的体现

原则 3： 全员参与

各级人员是组织之本。
只有他们的充分参与，才能使他们的才干为组织带来最大的收益。

1、 织实施本原则的主要利益

2、 组织实施本原则时一般要采取的主要措施

3、 本原则在标准中的体现

原则 4： 过程方法

将相关的资源和活动作为过程进行管理，可以更高效地得到期望的结果。

过程方法的原则不仅适用于某些较简单的过程，也适用于由许多过程构成的过程网络。

在应用于质量管理体系时，2000版 ISO9000族标准建立了一个过程模式。
此模式把管理职

责、资源管理、产品实现、测量、分析与改进作为体系的四大主要过程，描述其相互关系，

并以顾客要求为输入，提供给顾客的产品为输出，通过信息反馈来测定的顾客满意度，评价

质量管理体系的业绩。

1、 实施本原则的主要利益

2、 组织实施本原则时一般要采取的主要措施

3、 本原则在标准中的体现

原则 5： 管理的系统方法

针对设定的目标，识别、理解并管理一个由相互关连的过程所组成的体系，有助于提高

组织的有效性和效率。

ISO/DIS9000的 3.3列出了建立和实施质量管理体系的十三个步骤：

1、 实施本原则的主要利益

2、 组织实施本原则时一般要采取的主要措施

3、 本原则在标准中的体现

人们社会生活离不开交往。
在交往中最先遇到和首先要解决 的是通讯工具——语言文

字问题，计算机问世以后，同样是语言 问题。
人要和计算机打交道，需要程序设计语言，

这种语言不仅应 让计算机理解，而且还应让别人看懂，使其成为人际交往的工具。
程序设

计语言的标准化最早提到日程上来。
60年代程序设计语言 蓬勃发展，出现了名目繁多的语

言，这对于推动计算机语言的发 展无疑有着重要作用。
但同时也带来许多麻烦。
即使同一

种语言， 由于在不同型号的计算机上实现时，作了不同程度的修改和变 动，形成了这一语

言的种种\"方言\"，为编写出程序的交流设置了障 碍。
制定标准化程序设计语言，为某一

程序设计语言规定若干个标 准子集，对于语言的实现者和用户都带来了很大方便。

随着软件工程学科的发展，人们对计算机软件的认识逐渐深 入。
软件工作的范围从只

是使用程序设计语言编写程序，扩展到 整个软件生存期。
诸如，软件概念的形成、需求分

析、设计、实现、测 试、制造、安装和检验、运行和维护直到软件引退(为新的软件所代 替)。

同时还有许多技术管理工作(如过程管理、产品管理、资源管 理)以及确认与验证工作(如评

审与审计、产品分析、测试等)常常 是跨越软件生存期各个阶段的专门工作。
所有这些方面

都应逐步 建立起标准或规范来。

另一方面，软件工程标准的类型也是多方面的。
它可能包括 过程标准(如方法、技术、

度量等)、产品标准(如需求、设计、部件、 描述、计划、报告等)、专业标准(如职别、道

德准则、认证、特许、课 程等)以及记法标准(如术语、表示法、语言等)。

为什么要积极推行软件工程标准化工作，其道理是显而易见 的。
仅就一个软件开发项

目来说，有多个层次、不同分工的人员相 互配合，在开发项目的各个部分以及各开发阶段

之间也都存在着 许多联系和衔接问题。
如何把这些错综复杂的关系协调好，需要 有一系列

统一的约束和规定。
在软件开发项目取得阶段成果或最 后完成时，需要进行阶段评审和验

收测试。
投入运行的软件，其维 护工作中遇到的问题又与开发工作有着密切的关系。
软件

的管理 工作则渗透到软件生存期的每一个环节。
所有这些都要求提供统 一的行动规范和衡

量准则，使得各种工作都能有章可循。

1983年 5月我国国家标准总局和原电子工业部主持成立了 \"计算机与信息处理标准化

技术委员会\"，下设十三个分技术委员 会。
和软件相关的是程序设计语言分技术委员会和

软件工程技术 委员会。
我国制定和推行标准化工作的总原则是向国际标准靠拢， 对于能够

在我国适用的标准一律按等同采用的方法，以促进国际 交流。

信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人

们共同关注的焦点。
不论软件的生产者还是软件的使用者，均生存在竞争的环境中，软件开

发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被淘汰

出局。
用户为了保证自己业务的顺利完成，当然希望选用优质的软件。
质量不佳的软件产品

不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成

公司信誉下降，继而冲击股票市场。
在一些关键应用 (如民航订票系统、银行结算系统、证

券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 中使用质量有问题的

软件，还可能造成灾难性的后果。

软件危机曾经是软件界甚至整个计算机界最热门的话题。
为了解决这场危机，软件从业

人员、专家和学者做出了大量的努力。
现在人们已经逐步认识到所谓的软件危机实际上仅是

一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失

控。
有错是软件的属性，而且是无法改变的，因为软件是由人来完成的，所有由人做的工作

都不会是完美无缺的。
问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序

中的错误密度达到尽可能低的程度。

给软件带来错误的原因很多，具体地说，主要有如下几点：

①、交流不够、交流上有误解或者根本不进行交流

在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。

②、软件复杂性

图形用户界面(GUI)，客户/服务器结构，分布式应用，数据通信，超大型关系型数据库

以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很

难理解它。

③、程序设计错误

象所有的人一样，程序员也会出错。

④、需求变化

需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但又不

得不那么做。
需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已

经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，

等等。
如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会

相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参

与者的积极性。

⑤、时间压力

软件项目的日程表很难做到准确，很多时候需要预计和猜测。
当最终期限迫近和关键时

刻到来之际，错误也就跟着来了。

⑥、自负人更喜欢说:

'没问题'

'这事情很容易'

'几个小时我就能拿出来'

太多不切实际的'没问题'，结果只能是引入错误。

⑦、代码文档贫乏

贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。
事实

上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易

理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(\"写

得艰难必定读的痛苦\")。

⑧、软件开发工具

可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带到应用软件

中。
就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得

更复杂。
为了更好地解决这些问题，软件界做出了各种各样的努力。

人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序设计语言的发

展，更多的语言开始流行，为了使程序更易于理解开发了结构化程序设计语言，如

PL/1,PASCAL等；为了解决实时多任务需求开发了结构化多任务程序设计语言，如 Modula，

Ada等；为了提高重用性开发了面向对象的程序设计语言，如 Simlasa等；为了避免产生不

正确的需求理解，开发形式化描述语言，如 HAL/S等，这使得建立基于自然语言的描述成为

可能，人们以形式化语言来描述需求；为了支持大型数据库应用，开发了可视化工具，如

Visual Studio、Power Builder等。
程序语言对提高软件生产效率起到了一定的积极作用，

但它对整个软件质量尤其是可靠性的影响，与其他因素相比作用较小。

可能是因为程序语言基于严格的语法和语义规则，人们企图用形式化证明方法来证明程

序的正确性。
将程序当作数学对象来看待，从数学意义上证明程序是正确的是可能的。
数学

家对形式化证明方法最有兴趣，在论文上谈起来非常吸引人，但实际价值却非常有限，因为

形式化证明方法只有在代码写出来之后才能使用，这显然太迟了，而且对于大的程序证明起

来非常困难。
受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项

工程，以工程化的方法来进行规划和管理软件的开发。

针对需求不确定的应用，可以使用渐进和迭代类的开发模型。
还可以采用快速应用程序

开发(RAD)和协同应用程序开发（JAD）技术，由软件开发者和用户代表共同参与开发软件规

范。
RAD和 JAD的基本思路是开发者和用户共同设计系统中的屏幕，开发者迅速地把实现这

些屏幕的最基本功能编写好，然后把它们交给用户看，然后用户和开发者回顾这些屏幕以确

认它们达到了用户的要求，这个周期一直持续到系统的基本部分定义完毕。
一旦设计被用户

接受，开发者将完成完全实现屏幕需要的代码。
RAD和传统软件开发项目之间的一个基本区

别是：应用程序 RAD系统是按阶段发布的。
传统项目一般一次发布，也叫\"big bang\"。
RAD

方法使用高效开发工具，开发者能够非常迅速地设计出系统的基本屏幕，允许用户在开发周

期中很早就能见识到系统将来看起来怎么样，避免了在传统开发项目中长篇大论并且枯燥难

懂的说明。

IBM的 Dr.Harlan Mills提出了净室过程。
净室过程组合了形式化程序验证和统计过程

控制(SPC)。
在这种方法中，首先用正确性数学证明预防缺陷发生，然后用 MTBF度量软件质

量。
净室过程是一种相当新的软件开发方法，它要求软件开发在管理方式和技术方法上作重

大改变，特别是要求 SPC应用到软件的知识，这影响了其被广泛的接受。

硬件成本持续降低，可支持 CASE工具运行的新的强大的工作站和网络已经成为软件工

程使用的工作平台，CASE工具可完成一些特定的软件开发过程。
这些工具提供给软件设计

者以图形方式描述软件设计的能力，这样就易于维护、易于交叉检查、易于理解。
许多人（尤

其是 CASE工具供货商）相信 CASE工具扮演了解决软件危机和拯救软件工业的角色，但事实

上我们看到的情形却是许多公司花了大量的金钱买回的 CASE工具但很少使用，原因在于这

些工具执行的过程与机构的软件设计过程不相适用。

在可以借助许多新的技术和工具进行软件开发的今天，软件开发过程的成熟性问题开始

引起人们的重视。
这种产品一致性问题的主要症结在于管理，因此人们将目标转向了管理的

改善，一些以改进软件开发过程为目标的活动已经展示出积极的结果。

以下是一些比较典型的文本。

SEI SW-CMM

ISO SPICE(Software Process Improvement and Capability dEtermination)

Bootstrap

ISO-9000-3

TickIT

Trillium

事实上，对于软件来讲，还没有象银弹那样的东西。
不论采用什么技术和什么方法，软

件中仍然会有错。
采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，

但是不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也

需要测试来进行估计。
测试是所有工程学科的基本组成单元，是软件开发的重要部分。
自

有程序设计的那天起测试就一直伴随着。
统计表明，在典型的软件开发项目中，软件测试工

作量往往占软件开发总工作量的 40％以上。
而在软件开发的总成本中，用在测试上的开销

要占 30％到 50％。
如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例

也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许

多测试工作。
因此，测试对于软件生产来说是必需的，问题是我们应该思考\"采用什么方法、

如何安排测试?\"

软件测试的目的决定了如何去组织测试。
如果测试的目的是为了尽可能多地找出错误，

那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。
如果测试目的是

为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会

经常用到的商业假设。

不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同

区域或是对同一区域的不同层次的测试。

在谈到软件测试时，许多人都引用 Grenford J. Myers在《The Art of Software Testing》

一书中的观点：

①、软件测试是为了发现错误而执行程序的过程；

②、测试是为了证明程序有错，而不是证明程序无错误。

③、一个好的测试用例是在于它能发现至今未发现的错误；

④、一个成功的测试是发现了至今未发现的错误的测试。

这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。
但

是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不

出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。
通过分析错误产生的原因和错误的分布特征，

可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。
同时，这种分析也能帮

助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。
详

细而严谨的可靠性增长模型可以证明这一点。
例如 Bev Littlewood发现一个经过测试而正

常运行了 n小时的系统有继续正常运行 n小时的概率。

软件测试的基本方法

软件测试的方法和技术是多种多样的。

对于软件测试技术，可以从不同的角度加以分类：

从是否需要执行被测软件的角度，可分为静态测试和动态测试。

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测

试；

1、黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来

检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不

考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是

否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出

信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、

边值分析、因—果图、错误推测等，主要用于软件确认测试。
\"黑盒\"法着眼于程序外部

结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
\"黑盒\"法是穷举输入测

试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是

可能的输入进行测试。

2、白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检

测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验

程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法

有逻辑驱动、基路测试等，主要用于软件验证。

\"白盒\"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
\"白盒\"法是穷举

路径测试。
在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，

得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错

误。
第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
第

二，穷举路径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了

一些与数据相关的错误。

3．ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。
ALAC测试是基于复杂

的软件产品有许多错误的原则。
最大的受益者是用户，缺陷查找和改正将针对哪些客户最容

易遇到的错误。

作为软件开发的重要环节，软件测试越来越受到人们的重视。
随着软件开发规模的增大、

复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。
然而，为了尽可

能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得

尤为重要。

从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试

的可操作性相对较强。
但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果

设计有错误，测试的质量就难以保证。
即使测试后发现是设计的错误，这时，修改的代价是

相当昂贵的。
因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，

分别进行严格的审查。
软件的生命周期可用图 1的流程表示。

为了确保软件的质量，对图 1的过程应进行严格的管理。
虽然测试是在实现且经验证后

进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

1．测试的过程及组织

当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设

计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试

用例，以便系统实现后进行全面测试。

在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可

按下列方式组织：

(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在

设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，

设计测试用例，作好测试前的准备工作。

(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成

测试和验收测试。

(3)代码会审：

代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。
会审小组由组

长，2～3名程序设计和测试人员及程序员组成。
会审小组在充分阅读待审程序文本、控制

流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并

展开热烈的讨论甚至争议，以揭示错误的关键所在。
实践表明，程序员在讲解过程中能发现

许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。
例如，对某个局

部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接

口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。

(4)单元测试：

单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功

能与定义该模块的功能说明不符合的情况，以及编码的错误。
由于模块规模小、功能单一、

逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的 I/O条件和模块

的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试

（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。
高可靠性的模块是组

成可靠系统的坚实基础。

(5)集成测试：

集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的

问题。
如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有

害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积

累到不能接受的程度；全程数据结构可能有错误等。

(6)验收测试：

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后，已

经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就

应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合

理期待的那样。

经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经

验收后，将软件提交用户。

2．测试方法的应用

集成测试及其后的测试阶段，一般采用黑盒方法。
其策略包括?/p>

(1)用边值分析法和（或）等价分类法提出基本的测试用例；

(2)用猜测法补充新的测试用例；

(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再

按以上（1）、（2）两步进行。

单元测试的设计策略稍有不同。
因为在为模块设计程序用例时，可以直接参考模块的源

程序。
所以单元测试的策略，总是把白盒法和黑盒法结合运用。
具体做法有两种：

a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。
如果发

现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足

它们。
覆盖的标准应该根据模块的具体情况确定。
对可靠性要求较高的模块，通常要满足条

件组合覆盖或路径覆盖标准。

b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒

法进行补充。

3．测试的人员组织

为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。
因此，对分

析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进

行软件测试。
基于此，测试人员的组织也应是分阶段的。

(1)软件的设计和实现都是基于需求分析规格说明进行的。

需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。
为了保证需求定义的

质量，应对其进行严格的审查。
审查小组由下列人员组成：

组长：1人

成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户

(2)设计评审：

软件设计是将软件需求转换成软件表示的过程。
主要描绘出系统结构、详细的处理过程

和数据库模式。
按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同

时利用关系数据库的规范化理论对数据库模式进行审查。
评审小组由下列人员组成：

组长：1人

成员：包括系统分析员、软件设计人员、测试负责人员各一人。

(3)程序的测试：

软件测试。
是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。

软件测试在软件生存周期中横跨两个阶段：通常在编写出每一个模块之后，就对它进行必要

的测试（称为单元测试）。
编码与单元测试属于软件生存周期中的同一阶段。
该阶段的测试

工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。
这一阶段结束后，

进入软件生存周期的测试阶段，对软件系统进行各种综合测试。
测试工作由专门的测试组完

成，测试组设组长一名，负责整个测试的计划、组织工作。
测试组的其他成员由具有一定的

分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般 3～5人为宜。

4．软件测试文件

软件测试文件描述要执行的软件测试及测试的结果。
由于软件测试是一个很复杂的过

程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要

意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。
测试文件的编写是测

试工作规范化的一个组成部分。

测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试

文件与用户有着密切的关系。
在设计阶段的一些设计方案也应在测试文件中得到反映，以利

于设计的检验。
测试文件对于测试阶段工作的指导与评价作用更是非常明显的。
需要特别指

出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须

用到测试文件。

(1)测试文件的类型

根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。

测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。

由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写

工作。
不应在着手测试时，才开始考虑测试计划。
通常，测试计划的编写从需求分析阶段开

始，到软件设计阶段结束时完成。
测试报告用来对测试结果的分析说明，经过测试后，证实

了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件

质量的评价，又是决定该软件能否交付用户使用的依据。
由于要反映测试工作的情况，自然

要在测试阶段内编写。

(2)测试文件的使用

测试文件的重要性表现在以下几个方面：

a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测

试条件对弄清用户需求的意图是十分有益的，

b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试

工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。
如果某个测试

计划已经编写出来，但所需资源仍未落实，那就必须及早解决。

c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。
了

解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。

d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作

好测试工作的关键。
在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。

e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。

完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试

时，是非常有用的。

g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，

甚至整个软件的可用性提供了依据。
同时还可以证实有关方面的结论。

(3)测试文件的编制

在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的

格式进行。

软件项目风险管理

1 前言

一般来说，软件工程师总是非常乐观。
当他们在计划软件项目时，经常认为每件事情都会像计划那样

运行，或者，又会走向另外一个极端。
软件开发的创造性本质意味着我们不能完全预测会发生的事情，因

此制定一个详细计划的关键点很难确定。
当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都

会导致软件项目的失败。

目前，风险管理被认为是 IT软件项目中减少失败的一种重要手段。
当不能很确定地预测将来事情的时

候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。

风险管理意味着危机还没有发生之前就对它进行处理。
这就提高了项目成功的机会和减少了不可避免风险

所产生的后果。

2 什么是风险

所谓\"风险\"，归纳起来主要有两种意见，主观说认为，风险是损失的不确定性；客观学认为，风险

是给定情况下一定时期可能发生的各种结果间的差异。
它的两个基本特征是不确定性和损失。
IT行业中的

软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。
项目开发的

方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。
在进行项目风险分

析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题：

要考虑未来，什么样的风险会导致软件项目失败？

要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和

系统成功产生什么影响？

必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？

要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？

这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。

风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

3 风险管理

项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、

风险管理策略、风险解决和风险监控。
它能让风险管理者主动\"攻击\"风险，进行有效的风险管理。

在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括

四个相关阶段：

风险识别 识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现

场观察法、相关部门配合法和环境分析法等。

风险评估 对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风

险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法

等。

风险处理 一般而言，风险处理有三种方法，①风险控制法，即主动采取措施避免风险，消灭风险，中

和风险或采用紧急方案降低风险。
②风险自留，当风险量不大时可以余留风险。
③风险转移。

风险监控 包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后

者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。

在 IT软件项目管理中，应该任命一名风险管理者，该管理者的主要职责是在制订与评估规划时，从风

险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个

风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。

4 风险识别

风险识别就是企图采用系统化的方法，识别某特定项目已知的和可预测的风险。
常用方法是建立\"风

险条目检查表\"，利用一组提问来帮助项目风险管理者了解在项目和技术方面有些风险。
在\"风险条目检

查表\"中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的

和可预测的风险，如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。
\"风险条目检查表\"

可以以不同的方式组织，通过判定分析或假设分析，给出这些提问确定的回答，就可以帮助管理或计划人

员估算风险的影响。
软件项目一般有如下五类风险：

4.1 产品规模风险

有经验的项目经理都知道：项目的风险是直接与产品的规模成正比的。
与软件规模相关的常见风险因

素有：

估算产品的规模的方法（LOC或代码行，FP或功能点，程序或文件的数目）。

产品规模估算的信任度

产品规模与以前产品规模平均值的偏差

产品的用户数

复用的软件有多少

产品的需求改变多少

4.2 需求风险

很多项目在确定需求时都面临着一些不确定性和混乱。
当在项目早期容忍了这些不确定性，并且在项

目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。
如果不控制与需求相关的风险因

素，那么就很有可能产生错误的产品或者拙劣地建造正确的产品。
每一种情况都会导致使人不愉快。

与客户相关的风险因素有：

对产品缺少清晰的认识

对产品需求缺少认同

在做需求中客户参与不够

没有优先需求

由于不确定的需要导致新的市场

不断变化需求

缺少有效的需求变化管理过程

对需求的变化缺少相关分析

4.3 相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。
经常我们不能很好地控制外部的相关性，

因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜

在的问题。
与外部环境相关的因素有：

客户供应条目或信息

内部或外部转包商的关系

交互成员或交互团体依赖性

经验丰富人员的可得性

项目的复用性

4.4 管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊

奇。
在大部分项目里，项目经理经常是写项目风险管理计划的人，并且大部分人都不希望在公共场合暴露

自己的弱点。
然而，像这些问题可能会使项目的成功变得更加困难。
如果不正视这些棘手的问题，它们就

很有可能在项目进行的某个阶段影响项目。
当我们定义了项目追踪过程并且明晰项目角色和责任，就能处

理这些风险因素：

计划和任务定义不够充分

实际项目状态

项目所有者和决策者分不清

不切实际的承诺

员工之间的冲突

4.5 技术风险

软件技术的飞速发展和经历丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。

在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、雇佣顾问以及为项

目团队招聘合适的人才等。
主要有下面这些风险因素：

缺乏培训

对方法、工具和技术理解的不够

应用领域的经验不够

新的技术和开发方法

不能正确工作的方法

5 风险估计

风险估计，又称风险预测，常采用两种方法估价每种风险。
一种是估计风险发生的可能性或概率，另

一种是估计如果风险发生时所产生的后果。
一般来讲，风险管理者要与项目计划人员、技术人员及其他管

理人员一起执行四种风险活动：

（1）建立一个标准（尺度），以反映风险发生的可能性。

（2）描述风险的后果。

（3）估计风险对项目和产品的影响。

（4）确定风险的精确度，以免产生误解。

另外，要对每个风险的表现、范围、时间做出尽量准确的判断。
对不同类型的风险采取不同的分析办

法。

1．确定型风险估计

（a）盈亏平衡分析

盈亏平衡分析（Break-Even Analysis）通常又称为量本利分析或损益平衡分析。
它是根据软件项目在

正常生产年份的产品产量或销售量、成本费用、产品销售单价和销售税金等数据，计算和分析产量、成本

和盈利这三者之间的关系，从中找出它们的规律，并确定项目成本和收益相等时的盈亏平衡点的一种分析

方法。
在盈亏平衡点上，软件项目既无盈利，也无亏损。
通过盈亏平衡分析可以看出软件项目对市场需求

变化的适应能力。

（b）敏感性分析

敏感性分析（Sensitivity Analysis）的目的，是考察与软件项目有关的一个或多个主要因素发生变

化时对该项目投资价值指标的影响程度。
通过敏感性分析，使我们可以了解和掌握在软件项目经济分析中

由于某些参数估算的错误或是使用的数据不太可靠而可能造成的对投资价值指标的影响程度，有助于我们

确定在项目投资决策过程中需要重点调查研究和分析测算的因素。

（c）概率分析

它是运用概率论及数理统计方法，来预测和研究各种不确定因素对软件项目投资价值指标影响的一种

定量分析。
通过概率分析可以对项目的风险情况做出比较准确的判断。
主要包括解析法和模拟法（蒙特卡

罗 Monte Carlo技术）两种。

2．不确定型风险估计

主要有小中取大原则、大中取小原则、遗憾原则、最大数学期望原则、最大可能原则。

3．随机型风险估计

主要有最大可能原则、最大数学期望原则、最大效用数学期望原则、贝叶斯后验概率法等。

5.1 建立风险清单

风险清单是关键的风险预测管理工具，清单上列出了在任何时候碰到的风险名称、类别、概率及该风

险所产生的影响。
其中整体影响值可对四个风险因素（性能、支持、成本及进度）的影响类别求平均值（有

时也采用加权平均值）。

一旦完成了风险表的内容，就可以根据概率及影响来进行综合考虑，风险影响和出现概率从风险管理的角

度来看，它们各自起着不同的作用（见图 1）。
一个具有高影响但低概率的风险因素不应当占用太多的风

险管理时间 ，而具有中到高概率、高影响的风险和具有高概率及低影响的风险，就应该进行风险分析。

5.2 风险评估

在风险分析过程中，我们对风险进行评估时可以建立一个如下的四元数组：

[ri , li, xi，yi]

其中，ri是风险，li 为风险出现的概率，xi 则表示风险损失大小，yi 则表示期望风险。

一种对风险评估的常用技术是定义风险的参照水准，对绝大多数软件项目来讲，风险因素——成本、

性能、支持和进度就是典型的风险参照系。
也就是说对成本超支、性能下降、支持困难、进度延迟都有一

个导致项目终止的水平值。
如果风险的组合所产生的问题超出了一个或多个参照水平值时，就终止该项目

的工作，在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。

如果某风险落在临界点上，可以利用性能分析、成本分析、质量分析等来判断该项目是否继续工作。
图 2 表

示了这种情况。

但在实际工作中，参照点很少能构成一条光滑的曲线，大多数情况下，它是一个区域，而且是个易变

的区域。
因而在做风险评估时，尽量按以下步骤执行：

（1）定义项目的水平参照值

（2）找出每组[ri , li, xi，yi]与每个水平参照值间的关系

（3）估计一组临界点以定义项目的终止区域

（4）估计风险组合将如何影响风险水平参照值

5.3 估计损失的大小

表 1是风险分析表的一个例子，可以建立一个用风险、损失概率、损失大小和期望风险这样的风险评

估表。

在表 1所示的风险估价的例子中，一个理论项目已经识别了从 1到 20周期间的潜在的几个风险，风险

发生的概率范围在 5%到 50%之间。
在现实的项目中，可能会识别出比此表要多得多的风险。

损失的大小常常比概率更容易受到控制。
在以上的例子中，可以很精确地估计出完全支持自动从主机

更新数据的时间是 20个月。
根据管理层将在何时讨论项目建议书,可以知道项目不是在 2月 1日就是 3月

1日会被批准。
如果假定会在 2月 1日批准，项目被批准的风险大小会比期望的长一些，也就是 1个月时

间。

如果损失的大小不容易直接估计出来，可以将损失分解为更小的部分，再对其进行评估，然后将各部

分评估结果累加，形成一个合计评估值。
例如，如果使用 3种新编程工具，可以单独评估每种工具未达到

预期效果的损失，然后再把损失加到一起，这要比总体评估容易多了。

5.4 评估损失的概率

评估损失的概率要比评估损失大小更具有主观性。
这里有许多实践方法可以提高主观评估的准确度。

有以下方法：

由最熟悉系统的人评估每个风险的发生概率，然后保留一份风险评估审核文件。

使用 Delphi法或少数服从多数的方法。
使用 Delphi法，必须要求每个人对每个风险进行独立地评估，

然后讨论（口头或纸上）每个评估的合理性，特别是最高和最低的那个。
一轮轮讨论，直到达成共识。
? 使

用\"形容词标准\"。
首先让每个人用表示可能性的形容词短语选择风险的级别，如非常可能、很可能、可

能、或许、不太可能、不可能、和根本不可能。
然后把可能性的评估转换为数量化的评估（Boehm1989）。

5.5 整个项目超限和缓冲

实际上，表 1中表示的期望风险的计算数值来源于一个被称为\"期望值\"的统计术语。
设计欠佳引起

的风险如果真正发生将花费 15周的时间。
既然它不是 100%地会发生，当然不能预计损失 15周时间。
但它

也不是没有可能发生，所以也不应指望不会发生损失。
统计学认为，预计损失的数量是概率乘以损失大小，

即 15%乘以 15周。
因此，在这个例子中，预计的是损失 2.25周。
由于只是谈论计划风险，可以累加所有

的风险暴露量来得到项目的全部可预料超标值。
这个项目可预料的超标值是 12.8到 13.2周，这就是如果

不做任何风险管理的话有可能超过计划的周数。

超出预期值的大小为整个项目风险控制级别的确定提供了依据。
如果例子中的项目是个 25周的项目，

超出预期值的 12.8到 13.2周就很明显需要进行风险管理了。

6 风险管理策略

风险管理策略就是辅助项目组建立处理项目风险的策略。
项目开发是一个高风险的活动，如果项目采

取积极的风险管理策略，就可以避免或降低许多风险，反之，就有可能使项目处于瘫痪状态。
一般来讲，

一个较好的风险管理策略应满足以下要求：

（1）在项目开发中规划风险管理，尽量避免风险

（2）指定风险管理者，监控风险因素

（3）建立风险清单及风险管理计划

（4）建立风险反馈渠道

7 风险驾驭和监控

风险的驾驭与监控主要靠管理者的经验来实施，它是利用项目管理方法及其它某些技术，如原型法、

软件心理学、可靠性等来设法避免或转移风险。
风险的驾驭和监控活动可用图 3 来表示。

7.1 建立风险驾驭与监控计划

从图 3中可以看出，风险的驾驭与监控活动要写入 RMMP（Risk Monitoring and Management Plan风

险驾驭与监控计划）。
RMMP记述了风险分析的全部工作，并且作为整个项目计划的一部分为项目管理人员

所使用。

风险管理策略可以包含在软件项目计划中，也可以组织成一个独立的风险缓解、监控和管理计划（RMMP

计划）。
RMMP计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。
一

旦建立了 RMMP计划，且项目开始启动，则风险缓解及驾驭及监控步骤也开始了。
正如前面讨论的，风险缓

解是一种问题避免活动。
风险驾驭及监控则是一种项目跟踪活动，它有三个主要目标： ? 判断一个预测的

风险是否事实、是否发生。

进行风险再估计，确保针对某个风险而制定的风险消除活动正在使用。

收集可用于将来进行风险分析的信息。

风险驾驭及监控的策略如下：

与在职人员协商，确定人员流动原因。

在项目开始前，把缓解这些流动原因的工作列入风险驾驭计划。

项目开始时，要作好人员流动的思想准备，并采取一些措施确保人员一旦离开时，项目仍能继续。

制定文档标准，并建立一种机制，保证文档及时产生。

对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。

对每个关键性技术人员培养后备人员。

在考虑风险成本之后，决定是否采用上述策略。

7.2 软件项目风险追踪工具

追踪风险的一个办法是将风险输入缺陷追踪系统中，缺陷追踪系统能将风险项目标示为已解决或尚未

处理等状态，也能指定解决问题的项目团队成员，并安排处理顺序。
可将软件风险项目依序排列出来，按

照缺陷存在的时间与负责者等资料排列。
这样，缺陷追踪系统就是追踪风险的工作能更好执行并且不那么

单调。

8 结束语

软件项目风险管理是一种特殊的规划方式，当对软件项目有较高的期望值时，一般都要进行风险分析。

进行过大中型项目开发的人都亲身体验到许多事情可能出错，最成功的项目就是采取积极的步骤对要发生

或即将发生的风险进行管理。
对任何一个软件项目，可以有最佳的期望值，但更应该要有最坏的准备，\"最

坏的准备\"在项目管理中就是进行项目的风险分析。

项目管理学科发展的特点和趋势

管理是无边界的大概念，任何事物都需要管理。
管理是使事物的发展从混乱、无序走向

有序、有效发展的唯一方法。
管理与人类发展并存，人类从原始走向现代，管理也从低级走

向高级，从自发走向自觉，从分散孤立的思想和方法，走向综合统一的学科体系。
这种学科

体系的建立是不断探索、逐渐完善的过程。
项目管理学科的发展也正在经历着这样一条发展

的道路。

一、项目管理专业化发展是现代项目管理发展的三大特点之一

尽管人类的项目实践可以追溯到几千年前，但是将项目管理作为一门科学来进行分析研

究，其历史并不长。
从世界第一个专业性国际组织 IPMA 1965年成立至今不过 30多年的时

间。
经过这 30多年的努力，目前国际专业人士对项目管理重要性及基本概念已有了初步共

识。
分析当前国际项目管理的发展，有三个特点即：全球化的发展、多元化的发展和专业化

的发展。
专业化的发展即为三大特点之一。

项目管理的全球化发展

知识经济时代的一个重要特点是知识与经济发展的全球化，因为竞争的需要和信息技术

的支撑，促使了项目管理的全球化发展。
主要表现在国际间的项目合作日益增多、国际化的

专业活动日益频繁、项目管理专业信息的国际共享等等。
项目管理的全球化发展既为我们创

造了学习的机遇，也给我们提出了高水平国际化发展的要求。

项目管理的多元化发展

由于人类社会的大部分活动都可以按项目来运作，因此当代的项目管理已深入到各行各

业，以不同的类型，不同的规模而出现，这种行业领域及项目类型的多样性，导致了各种各

样项目管理理论和方法的出现，从而促进了项目管理的多元化发展。

项目管理的专业化发展

项目管理的广泛应用促进了项目管理向专业化方向的发展，突出表现在项目管理知识体

系（PMBOK）的不断发展和完善、学历教育和非学历教育竞相发展、各种项目管理软件开发

及研究咨询机构的出现等等。
应该说这些专业化的探索与发展，也正是项目管理学科逐渐走

向成熟的标志。

二、项目管理学科在双向探索中发展

自 50年代末，60年代初以来，学术界与各有关专业人士对项目管理的研究基本上在两

个方向努力。
一方面是各领域的专家们在探讨本学科在项目管理中有无用武之地，如何将本

学科领域的专业理论、方法应用于项目管理。
例如：计算机、控制论、模糊数学等等。
另一

方面则是各行各业的专家们在探讨如何把项目管理的理论、方法应用到本行业中去。
如建筑

业、农业、军事工业以及近几年呼声很高的 IT行业等等（见图一）。

这种双向探索尽管均出自于外界的需求，但却极大地促进了项目管理自身的发展。
使得

项目管理也在向两个方向发展：一是向学科化方向发展。
项目管理在吸收各学科的有用部分，

逐渐形成一些自己独立的内容体系。
例如：美国 PMI于 1986年提出的项目管理知识体系

（PMBOK），国内外大学所建立的学士、硕士、博士学历教育体系、成人教育的课程体系等

等。
另一方面，为了适应各行业发展的需要，项目管理学科也正在向实用化方向发展，包括

各种方法、工具、标准、法规等等。
如 1992年我国的 GB/T 13400.1～13400.3-92,\"网络

计划技术\"，国际标准化组织于 1997年推出的 ISO 10006\"质量管理—项目管理质量指导\"

以及各种计算机应用软件系统等等。
这种跨行业、跨专业、有理论、有实践的学科发展，进

一步促进了项目管理专业学科—\"项目学\"的建立和发展。

三、 关于项目学发展的几个趋势

关于项目学的体系结构，在\"时代的呼唤——论项目学的建立\"一文中曾有论述。
项目

学学科的发展像任何其他学科的发展一样，其成长和发展需要有一个漫长的过程，而且是永

无止尽的。

其近期的发展趋势是：

1． 项目学的主体是应用项目学，应用项目学的主体是微观项目管理

任何学科的发展都离不开时代背景，都有客观环境的制约。
当今时代尽管有各种各样的

项目，对项目的管理也有各种层次，但最基本的是单一项目的管理，也就是我们所说的微观

项目管理。
这种单个项目是国民经济发展的细胞。
它们的数量、类别、复杂程度，规模大小、

周期长短，综合反映了一个国家的经济发展程度和科技发展水平。
因此微观项目管理从大的

方面说，是关系到国民经济发展的重要的因素，从小的方面来说，是各个项目相关单位兴衰、

存亡的关键，这也是为什么微观项目管理在国内外项目管理专业领域受到特别重视的原因。

2． 世界各国研究的 PMBOK是当前项目管理学科发展的重要内容

从 80年代以来，世界各国专业人员与组织，纷纷提出了项目管理知识体系（PMBOK）的

问题，PMBOK之所以受到专业学术领域的如此重视，有以下几方面的原因：

其最主要的原因，在于它跨越了行业的界限。
它归纳出的项目管理体系，是各行业的项

目管理人员所必需的基本知识。
就像网络计划技术可以适用于各行各业的计划管理一样，

PMBOK总结归纳出的知识体系，也可以适用于各行各业。

有了这一知识体系，对提高项目管理专业人员的水平有极大的促进作用。
知识体系与专

业资格认证的结合从某种意义上说也反映了知识经济时代的特点。

3． 项目学是知识创新与市场相结合的综合化发展

随着世界经济由工业经济向知识经济的转变，人们对劳动价值的衡量与评价也发生了变

化。
在知识经济时代，人们将知识通过创新劳动，转化为产品，投向市场，从而产生经济效

益。
其中极其重要的实现方式就是各种各样的项目。
因此项目学的研究也将在知识、创新和

市场的综合发展中而逐步发展成熟。

4. 项目学是科学、技术和艺术相结合的综合

有越来越多的迹象表明，项目管理专家们正以极大的兴趣关注着所谓项目的\"软\"问

题，诸如项目过程中的思维、行为、情感、适应性、项目管理中的交叉文化问题、项目经理

的领导艺术等等。
因此有人说，项目管理是将思想转化为现实，将抽象转化为具体的科学和

艺术。

项目管理学科的发展，不管在国内还是国外，都进入了一个超乎寻常的发展速度，她对

于中国经济的发展，对于西部大开发也必将发挥越来越大的作用，衷心希望国内同行们团结

一致，为提高我国项目管理水平，为促进国内外项目管理的接轨而共同努力。

西边人西说测试，

头条号(软件测试资源站)作者，程序爬虫获取国内外测试资源分享给自学爱好者。

今日头条关注后，私信回复如下关键词获取大量打包资料下载。

测试资料、工具、Python、自动化测试报告、梯子 等

如果需要pdf文档，私信回复关键词 文档即可