《软件质量管理制度》

《软件质量管理制度》

一、管理组织

本公司的软件质量保证活动统一由质量管-理•员进行管理、检查

与汇报，公司相关部门经理及项目中的项目经理、程序经理、开发经

理、测试经理、产品经理、测试经理、用户教育经理是质量保证活动

中的第一责任人。

二、软件开发过程

本公司的软件开发过程分为以下8个阶段：项目策划阶段、需求

分析阶段、设计阶段、开发阶段、测试阶段、实施阶段、验收阶段、

维护阶段，每个阶段的主要活动分别为：业务启动和项目规划、需求

分析、逻辑设计和物理设计、软件开发、软件测试、系统实施及用户

培训、用户试用及验收、维护，里程碑分别为：策划完成、需求明确、

设计完成、开发完成、测试通过、系统上线、验收通过、合同结束。

每阶段结束后，必须对相应的里程碑进行检查，方式为评审或批准。

三、项目文档项目文档分为两种：管理类文档与技术类文档，所

有文档必须保存于知识库及相应的vss库中。文档共有三种状态：编

制完成、审核通过、批准通过。其中管理类文档只有编制和批准两种

状态，技术类文档拥有所有三种状态。所有文档必须明确说明当前文

档版本号。

管理类文档包含以下类型：计戈I」、总结、报告、会议纪要、备忘

录、申请等。技术类文档包含：设计文档、需求文档、测试设计文档、

界面原型软件、使用手册、安装手册、技术白・皮■书、培训资料、源

代码、软件产品等。除VSS库中的文档以外，放入知识库中的文档由

部门助理统一放入，文档必须批准通过。

文档的编制、审核、批准可在文档中直接写明，也可使用单独的

审批文档进行说明。

每个项目在不同阶段必须产生的文档如下，但不限于此：

1、项目开始前：

合同、技术方案、市场立项表。以上文档存放于知识库。

2、项目策划阶段:

业务启动表（excel格式）、项目规划（word格式）、项目进度

（project格式）等。必须使用规定模板编写。以上文档存放于知识库。

3、需求分析阶段：

需求模型（ea格式）、软件需求规格说明书（word格式）、单据

报表格式（excel格式）、需求分析评审表（word格式）、需求分析计

划（word格式和project两种格式）。必须使用规定模板编写。以上

文档存放于知识库。

4、设计阶段

软件开发计划（project格式）、逻辑设计（ea格式）、物理设计

（vs.格式）、设计评审表（word格式），必须使用规定模板编写。物

理设计存放于vss库，其它文档存放于知识库。

5、开发阶段

源代码、可安装的软件、安装手册、评审表（word格式）。源代

码、可安装的软件存放于vss库，其它文档存放于知识库。

6、测试阶段

测试用例设计、软件bug、测试计划（word格式和project两种

格式）、测试报告（word格式）、开发的测试工具源代码及软件、测

试通过的软件产品、软件评审表（word格式）。开发的测试工具源代

码及软件、测试通过的软件产品存放于vss库，其它文档存放于知识

库。软件bug存于td中。

7、实施阶段实施计划（word格式和project两种格式）、实施报

告（word格式）、用户使用手册、用户培训资料、用户培训记录、软

件问题反馈表（excel格式）、上线报告（书面、电子扫描件）等。必

须使用规定模板编写。以上文档存放于知识库。

8、验收阶段

验收材料、验收报告（书面、电子扫描件）。以上文档存放于知

识库。

9、维护阶段

维护报告（word格式），以上文档存放于知识库。

四、检查和审查

本公司的项目关键检查点有以下8个，采取评审和批准的方式，

由质量管•理•员进行跟踪C

1、策划完成里程碑

以总经理批准通过业务启动表为标志，质量管•理•员检查业务启

动表、项目规划、项目风验控制计划、项目进度、技术方案文档是否

进入知识库。负责人为项目经理。

审表是否进入知识库。负责人为测试经理。

6、系统上线里程碑

以用户签署通过上线报告为标志，评审参与人员必须包括。用户

代表、公司代表、项目经理。质量管■理■员检查上线报告、实施计划、

培训材料等文档是否进入知识库。如上线报告为纸质文档，则扫描后

入库。负责人为实施经理。

7、验收通过里程碑

以用户签署通过验收报告为准，评审参与人员必须包括。用户代

表、公司代表、项目经理。质量管■理-员检查验收报告文档是否进入

知识库，如上线报告为纸质文档，则扫描后入库。负责人为项目经理。

8、合同结束里程碑

合同结束，项目跟踪完成。负责人为软件业务部技术服务组长。

五、测试本公司的软件必须通过测试。测试工作由开发部测试组

负责，所有测试出来的bug必须统一存放，由测试组负责管理。在测

试活动进行前必须有测试计划，测试完成后必须编写测试报告。测试

报告由测试经理负责编写，测试组长批准。

六、配置管理

软件开发过程中的配置管理工作由配置管•理•员负责，配置管理

工作详细要求依据《配置管理规范》进行。

七、媒体控制

在软件开发过程中产生的正式文档必须存入于知识库中或vss库

中，由公司系统管-理-员负责每天进行物理备份。在项目进行过程中

的备份采用移动硬盘进行，已结项的项目使用刻录光盘存档备份。

八、质量记录

质量记录主要包括各种评审记录和审批记录，形式有评审表、签

名文件、会议纪要、质量报告等。所有的质量记录由质量管■理■员统

一管理，纸质的保存在指定的文件柜中，电子的保存在知识库中。质

量记录的保存期限是3年。

九、风险和应急公司所有的项目必须有独立的风险控制计划，风

险控制计划由项目经理负责编写并跟踪，风险控制计划由项目管理部

门批准。风险计划中必须包括风险列表、风险度、应急方案、缓解方

案、责任人、风险状态。风险度由风险发生可能性和风险造成的危害

程度相乘得到。

十、质量报告

项目的质量管■理■员必须在每周五12:00以前制作当前的项目质

量报告，报告公司当前正在进行的项目的质量状态。主要包括：项目

文档的审核情况、存放情况、完备情况;各里程碑的评审执行情况;各

种计划的跟踪情况，责任人是否及时更新计划;各项规范的符合程度;

等等。质量报告属于项目状态报告的一部分，与其一同填写。具体格

式参见《项目状态报告》。

十一、质量会议

质量会议与公司的项目月例会合并召开，开会时必须提交质量报

告。参会人员必须包括软件业务部部门经理、产品组组长、实施组组

长和开发部部门经理、开发组组长、技术支持组组长、测试组组长、

各项目经理。如遇特殊情况，质量管-理•员可临时针对某类问题发起

会议，会议结束时必须有会议纪要并存档。

十二、工具及技术在进行质量保证活动中，主要使用两种工具软

件：知识管理系统和msvisualsourcesafeo前者用来存放项目产生的各

种文档，后者主要用于存放源码。公司在所有正式场合中所使用的项

目文档均以这两个系统中的数据为准。在使用工具软件的过程中，各

项目成员的权限统一由公司文档管■理■员进行分配。

十三、变更控制委员会

公司所有在建项目必须成立变更控制委员会，该委员会最小要包

括以下人员：用户代表、市场代表、软件业务代表、开发代表、项目

经理，但不限于此。一般情况下，产品经理、程序经理、开发经理、

测试经理、实施经理、用户教育经理也可包括在该组织中。对于维护

性项目，变更控制委员会由营销中心主任、软件业务部经理、开发部

经理组成。

第二篇：软件质量保证管理1、v模型：v模型是在rad模型的基

础上演变而来的，由于开发过程构造成一个v字形而得名。v模型强

调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保

证较高的软件质量情况下缩短开发周期。v模型具有面向客户、效率

高、质量防范意识等特点。

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保

证活动一审核过程，也就是静态的测试过程；右边是对左边结果的验

证，是动态的过程，即对设计和分析的结果进行测试，以确认是否满

足用户的需求。V模型避免了瀑布模型所带来的误区--软件测试是

在代码完成之后进行的。p30

2、什么是变更控制。(pill)

软件开发过程中都会产生许多变更，如配置项，配置，基线，构

建的版本，发布的版本的变更，对于这些变更，都要有一个控制机构,

以保证所有的变更都是可控的，可跟踪的，可重现的。这样的一类机

构对变更的管理，就是变更控制。

3、软件可靠性概念。(pl76)

软件可靠性是指在给定时间内，特定环境下软件无错运行的概

率，软件可靠性包含了以下三个要素：规定的时间，规定的环境条件,

规定的功能。

4、cmm(pl95)

cmm：能力成熟度模型，用来衡量组织软件过程成熟度和评价其

软件过程能力。能力成熟度是指一个特定过程被明确定义，管理，测

量，控制并且是有效的程度。分为五个等级：初始级软件过程的特点

是无序的，甚至是混乱的。几乎没有什么过程是进过定义的。可重复

级关键过程区域集中关注软件项目所关心的，与建立基本项目管理控

制有关的事情。

已定义级将软件生命周期的各个阶段严格的划分出来，从组织这

个层次来保证过程质量该进

已管理级软件产品的质量目标被量化管理，它遵循了全面质量管

理活动的科学程序，关键过程域的关注焦点是建立起对软件过程和正

在构造的软件工作产品的定量了解。

优化级关键过程域包括那些为了实施连续不断的和可测的软件

过程改进，组织和项目都必须解决的问题。

5、tqm的实施步骤（p265）

（1）建立质量小组，负责过程改进，流程完善，不断发现质量

问题提出并实施解决方案。

（2）进行tqm思想的教育，通过教育，要让每个员工深刻认识

到“满足顾客的需求是第一的”的思想，理解“什么是顾客需求”，

如何让顾客满意等内容。

（3）了解市场，明确顾客需求，了解目前研发的软件产品的市

场，包括竞争对手，客户群等，让员工明白什么是质量好的软件产品

或软件服务，认真对待质量要求，开发出合格的产品。

（4）建立明确的质量基准和质量评估机制，以便和实际质量水

平进行对比，识别质量的目标和工作的重点区域，采取相应措施。

（5）建立相对完善的奖励机制，在认可和给予奖励的过程中，

应力求公正，真实，选择恰当的时间，恰当的场合，恰当的方式。

2、版本控制的目的。是在于对软件开发过程中文件或目录的发

展过程提供有效的追踪手段，保证在需要时找到旧的版本，避免文件

的丢失，修改文件的丢失和相互覆盖，通过对版本库的访问控制避免

未经授权访问和修改。另外软件的控制是实现团队开发，提高效率的

基础。

3、pdca包括4个部分：计划、执行、检查、行动描述总结

（1）计划计划：就是分析当前状况，发现问题，找出原因和主

要原因，制定质量方针、质量

目标、质量计划书和管理原则。管理原则有。过程方法、管理的

系统方法、持续改进

（2）执行：执行时计划的履行和实现，主要按计划实施地去做,

去落实具体对策，并实施过

程的监控，使活动按预期设想前进，最终达到计划设定的目标。

（3）检查。是对执行后效果的评估。检查是伴随着实施过程自

始至终的，不断收集数据、信

息获取的过程，并通过数据分析、结果度量来完成检查。

行动。重点在于检查完结果，要采取措施，即息结成功的经验，

吸取失败的教训，实施标准化，以后依据标准执行。

4、阶段性开发模型：增量模型和迭代模型

（1）增量模型描述软件产品的不同阶段是按产品所具有的功能

进行划分的，先开发主要

功能或用户最需要的功能，然后随着时间的推进，不断增加新的

辅助功能或次要功能，最终开发出一个功能完善的，稳定的产品。

（2）迭代模型描述软件产品的不同阶段是按产品深度或细化程

度来划分，先将产品的整个框架都建立起来，在系统的初期，已经具

有用户所需要的全部功能。然后随着时间推进，不断细化已具有的功

能或完善已具有的功能，这个过程是一个迭代的过程

6、零缺陷质量管理的实施步骤：（p268）

（1）建立推行零缺陷质量管理的组织事情的推行都需要组织的

保证，通过建立组织，可以动员和组织全体职工积极的投入零缺陷管

理，提高他们参与管理的自觉性也可以对每个人的合理化建议进行统

计分析，不断进行经验交流，公司的最高管理者要亲自参加，表明决

心，做出表率，要任命相应的领导人，建立相应的制度，要教育和训

练员工

（2）确定零缺陷管理的目标，确定零缺陷小组在一定时期内所

要达到的具体要求，包括确定目标项目，评价标准和目标值

（3）进行绩效评价，

（4）建立相应的提案机制

（5）建立表彰制度

sqa组织的责任是审计软件经理和软件工程组的质量活动中出现

的偏差。

7、sqa计划（p283）

sqa在项目早期要根据项目计划制定与其相应的sqa计划，定义

各阶段的检查点。标识出检查审计的工作产品对象，以及在每个阶段

sqa的输出产品。具体实施步骤如下：

（1）了解项目的需求，明确项目sqa计划的要求和范围

（2）选择sqa任务

（3）估计sqa的工作量和资源

（4）安排sqa任务和日程

（5）形成sqa计划

（6）协商，评审sqa计划

（7）批准sqa计划

（8）执行sqa计划

sqa计划包含以下内容：

（1）目的，sqa计划的目的和范围（2）参考文件，该sqa计划

参考的文件列表（3）管理，组织，任务，责任（4）文档，列出所有

的相关文档，如程序员手册，测试计划，配置管理计划等（5）标准

定义，文档标准，逻辑结构标准，代码编写标准，注释标准等（6）

评审/审核（7）配置管理，配置定义，配置控制，配置评审（8）问

题报告和处理（9）工具，技术，方法（10）代码控制（11）事故/

灾难控制，包括火灾，水灾，紧急情况等。

8、评审和审核的区别。（p285）

评审：过程进行时，sqa对过程的检查，sqa的角色在于确保当

执行工程活动时，各项计划所规定的过程得到遵循，评审通常通过评

委会的的方式进行，是对工作流程的评审

审核。在软件工作产品生成时，sqa对工作产品进行的检查，sqa

的角色在于确保开发工作产品中各项计划所规定的过程得到遵循，审

核通常通过对工作产品的审查来执行。侧重于产品本身。

sqa报告应遵循三条原则sqa和高级管理者之间应有的沟通渠

道，sqa报告必须发布给软件工程组织但不必发布给项目管理人员，

在可能的情况下向关心软件质量的人发布。

sqa度量是记录花费在sqa活动时间人力数据。涉及以下三方面:

软件产品评估度量、软件产品质量度量、软件过程审核度量。

sqa的评估任务是软件开发前期对目标的软件和硬件资源进行评

估，以确保其充分性和适合性。

9、白盒测试、黑盒测试(p390)

白盒测试将被测试程序看做一个盒子，测试者能够看到被测程

序，可以分析被测程序的内部结构。

白盒测试可以用来对代码结构进行全面测试，常用的有语句覆

盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆

盖，循环测试

黑盒测试常用来验证软件或模块功能是否得到实现，主要运用单

元的性能和功能方面的测试除了测试其功能外，还需确保代码在结构

上可靠，健全并能够有良好的响应。黑盒测试主要运用于单元的功能

和性能方面的测试。功能测试包括用户界面测试各种操作的测试不同

的数据输入逻辑思路，数据输出和存储的测试。

区别：关键区别应该就是测试对象不一样，白盒测试主要针对的

是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，

简单的说就是前者测试后台程序后者测试前台展示功能

10、测试的原则概括为10项：

(1)所有测试的标准都是建立在用户需求之上2软件测试必须

基于“质量第一”的思想去开展各项工作3实现定义好产品的质量标

准4软件项目一启动。软件测试也就是开始5穷举测试是不可能的6

第三方进行测试会更客观，更有效7软件测试计划是做好软件测试工

作的前提8测试用例的设计出来的，不是写出来的9不可将测试用例

置之度外，排除随意性10对发现错误较多的程序段，应进行更深入

的测试

39、功能测试的概念。是基于产品功能说明书，是在已知产品所

应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能

正常使用、是否实现了产品规格说明书要求、是否能适当地接收输入

数据而产生正确的输出结果等。

5、风险管理法：sei（软件工程研究所）风险控制一般分5个步

骤：p80

（1）风险识别：试图系统化的方法来确定威胁项目计划的因素。

识别方法包括：风险检

测表、头脑风暴会议、流程图分析、与项目人员面谈。

（2）风险分析。可以分为定性风险分析和定量风险分析。定性

风险分析是评估已经识别

风险的影响和可能性的过程。定量风险分析是量化分析每一风险

的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程

度。

（3）风险计划：制定风险行动计划，应考虑以下部分：责任、

资源、时间、活动、应对

措施、结果、负责人。

（4）风险控制：方法：风险避免、风险弱化、风险承担、风险

转移。

（5）风险跟踪：监视风险的状况，检查风险的对策是否有效、

跟踪机制是否在运行，不

断识别新的风险并制定对策。

6、评审的内容：分为管理评审、技术评审、文档评审、过程评

审（p217简答）

（1）管理评审是以实施质量方针和目标的质量体系的适应性和

有效性为评论基准，对体系文

件的适应性和质量活动的有效性进行评价。目标：按规定的时间

间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标

准要求和提供的质量方针和目标。输入：体系审核的结果。输出：《管

理评审报表》

（2）技术评审是对产品以及各阶段的输出内容进行评估。目的:

确保需求说明、设计说明书

与最初的说明书保持一致，并按照计划对软件进行了正确的开

发。输入：需求文档、源代码、测试用例、评审检查单、其它文档。

输出：技术评审报告

（3）文档评审分为格式评审和内容评审。

（4）过程评审是对软件开发过程的评审，其主要任务是通过对

流程的监控，保证sqa组织

定义的软件过程在项目中得到了遵循，同时保证质量方针能得到

更快更好的执行。

40.朱兰三部曲:

质量策划：

为建立有能力满足质量标准化的工作程序，质量策划是必要的

质量控制：

为了掌握何时采取必要措施纠正质量问题就必须实施质量控制

质量改进：质量改进有助于发现更好的管理工作方式

40、从软件开发的各阶段论述如何提高软件产品的质量。

1、需求

我们知道人与人的交流总是会存在一些误会，同样一句话，心情

不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之

间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧

义的产生。如果对uml比较熟悉的话，需求分析可以利用uml工具进

行，这样可以减少一些自然语言引起的歧义，但是uml可能与用户沟

通起来有一些障碍，因为并不是所有的用户都了解uml各种图形的意

思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

1、看句子和段落是否简短，一个很长的句子，看起来会非常困

难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视

一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分

成多个小句子。

2、句子是否有语法错误，还要注意标点符号，有时，标点符号

点错了，就完全成了另外一个意思了。

3、是否存在模糊不清的需求，出现类似于可能，大概，或者等

词汇表述的需求。

4、另外注意引用的术语和词汇是否前后一致。

5、是否存在一些形容词、比较性词语，比如。容易的、快速的、

方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，

减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具

体值或者范围，要不然不同的人根据不同的理解就会得出不同的结

果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不

可避免地会发生。

另外保证需求质量的一个很重要的因素就是需求是否细化，如果

需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员

尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样

才能判断需求细化的程度呢。需求细化程度确实很难把握，什么样的

需求可以算是比较细了，不用再进行细化了呢。哪些需求又太粗了呢。

答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需

求还不是很细，还需要再进行细化。

2、设计

软件架构设计在软件产品开发周期中占有很重要的位置，我们开

发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，

例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同

的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我

们的设计对需求的覆盖率是多少。对于程序员来说模块是否清晰，类

的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。

对于维护人员来讲系统的扩展性、可维护性如何。一个高质量的软件

架构，应该最大限度的考虑并满足不同角色的不同要求。正

是因为有这些要求，我们在进行软件设计的时候，应该进行全面

的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考

虑：

1）、功能性。包括完全性、正确性、安全性、兼容性、互用性。

完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正

确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要

求。

2）、效率。包括产品运行的时间效率和利用的硬件资源两方面来

考虑。

3）维护性。包括架构的可改正性，可扩充性以及可测试性。如

果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样

的架构设计的可改正性和可扩充性就比较差。

4）可移植性。包括硬件的独立性、软件独立性、可安装性、可

重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考

虑的因素。

5）可靠性。包括缺陷数量、容错性、可用性。

6）使用性。包括可理解性、易学习性、可操作性、易沟通性。

我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性

不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非

常重要的。

3、编码

代码质量的一个很重要的标准就是代码的可读性及规范性，可读

性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码

难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代

码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码

维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易

出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关

联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从

导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个

导入类发生变化都会影响到该类本身，另外如果该类的public方法太

多也会导致类之间的高耦合性增加。

也许有的程序员会认为写出可读、规范的代码会影响工作进度。

的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，

但如今软件开发是多人协作

周期很长的过程，写过程序的人都知道，如果自己写了不规范的

代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的

模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长

时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的

程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码

还比重新写出一段代码花费的时间还长，严重影响工作效率（有些时

候还影响维护人员的心情），反过来，如果大家都讲究把代码写成规

范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。

代码质量另一个非常重要的衡量手段就是测试，通过统计测试代

码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一

个方面来简单地评估代码质量。

4、测试

测试人员在测试过程中，需要站在不同的利益相关者的角度，对

测试对象的质量进行检查和验证，例如：测试人员除了关注需求文档

中明确描述的需求条目之外，还应该关注隐现的需求，比如：竞争对

手的产品特征、用户的群体特征和使用习惯等。因此，在测试过程中,

测试人员除了关注测试对象的功能测试之外，还需要针对其他非功能

特性进行测试。

为了在测试过程中尽量多的覆盖质量特性，测试人员需要清楚的

了解产品有哪些质量特性是客户最关注的因此，测试人员在进行具体

的测试用例设计和执行之前，需要定义该产品应该满足的质量特性

集。

第三篇：有效的软件质量管理有效的软件质量管理（上）

一、引言

随着社会信息化水平的不断提高，信息行业急速膨胀，信息企业

快速成长，随之带来的信息市场竞争激烈，企业为了求生存，满足客

户要求则成为各行各业的首要责任。依赖于质量、成本和进度的客户

满意度，质量则是重点支撑之一，这样要求我们对质量管理需要加强

认识。我们都知道pmbok把项目管理划分为9个知识领域，即范围

管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、

采购管理、风险管理和综合管理。质量管理作为9大知识领域之一,

可见其重要性。

质量管理包括。质量计划编制、质量保证和质量控制三个过程域。

质量计划是质量管理的第一过程域，它主要结合各个公司的质量方

针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等

工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成

员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项

目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保

障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划

和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评

估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项

目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证,

为质量保证提供参考依据，它是一个pdca循环过程。

二质量管理责任分配

我们公司在开发项目上按照规范化软件的生产方式进行生产，在

生产流程上采用iso9000的标准进行。每个项目除配备了项目开发所

需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确

保质量管理的实施，下面针对这三种角色进行说明：

1、配置管理小组职责

配置管理小组是保证项目开发完毕的同时，内部文档和外部文档

都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能

够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不

被某个关键路径所阻塞而延滞的前提。如上所述，配置管理小组还是

保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包

括：完善各个部门发送需要存档和进行版本控制的代码、文档（包括

外来文件）和阶段性成果；对代码、文档等进行单向出入的控制；对

所有存档的文档进行版本控制；提供文档规范，并传达到开发组中。

2、测试小组职责

测试小组作为质量控制的主要手段，负责软件的测试设计和执行

工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划

和测试策略的设计，通常情况下测试可以分为如下几种类型，如：正

确性测试、功能性测试、性能测试、安全测试和系统测试等。而这些

测试均需要在测试计划和测试策略中进行描述用以指导测试小组成

员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行

过一定的单元测试，确保程序编译、运行正确。测试人员根据详细设

计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的

实现设计要求，在此也只证明了软件正确的反映了设计思想，但是否

真正反映了用户的需求仍需要进一步的功能性测试。

测试人员只有根据软件需求规格说明书所提及的功能进行检测，

才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之

后，需要测试的是软件的性能，软件的性能在本

项目中占有重要的地位，性能要求有可能改变软件的设计，为避

免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要

的话，测试小组还需要做安全测试，以确保系统使用安全可靠。

3、质量保证小组职责

质量保证小组作为质量保证的实施小组，主要职责是保证软件透

明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保

证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发

时的差异报告，提出差异原因和改进方法。

在项目进度被延滞或质量保证小组认为某阶段开发质量有问题

时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解

决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之

上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量

保证的影响力和力度。质量保证小组的检测范围包括：系统分析人员

是否正确的反映了用户的需求；软件执行体是否正确的实现了分析人

员的设计思想；测试人员是否进行了较为彻底的和全面的测试；配置

管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。

三质量管理实施

有了良好的资源配备，又如何在项目全生命周期内实施质量保

证，让我们从以下几个方面来看质量保证的实施过程：

1、项目进度的质量保证

项目进度是项目进行是否顺利的最直观表现。显然在项目开始之

前，项目开发计划是必须的。如果项目开发计划的制定的是完全合理

的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，

然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目

进度，首先要保证项目开发计划尽可能合理。

项目计划的合理程度与项目计划制定者从事类似规模和类似业

务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，这

样要求项目计划制定者需要集众人之力来完善计划。当项目计划制定

初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专

家、用户以及项目组小组成员一起讨论项目计划的可行性，会议通常

采用头脑风暴法，各抒己见，会后由指定的记录员形成质量记录，发

送给相关人员，对其计划中不合理的地方进行修改完善，并由质量保

证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计

划交由配置管理人员进行版本控制。

然而在计划实施过程中，计划不是“固定化二常有人道，“计划

赶不上变化”，但“要跟上变化”。项目计划以里程碑为界限，将整个

开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一

个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个

项目计划的动态调整。也利于项目质量保证的实施。

实际运作中，当质保小组发现计划实施的差异后，报告项目经理,

由项目经理组织负责对计划进行周期性维护，对于已经变动的计划由

质保小组协助配置管理小组完成版本控制。本公司已经开发湖南移动

的集中客服系统，开发中的子项目多达六个，历时十个月，目前多数

项目已经开发完毕，系统正在试运行阶段，项目金额数千万元。在这

样的项目中，从管理者到开发人员到测试人员都积累了较为丰富的经

验，特别是项目开发计划的制定，和项目进度的控制。

有效的软件质量管理（下）

2、项目开发各阶段的质量保证

a、需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。从

系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对

系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流

确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析

时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期,

纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工

期和系统的质量。

解决系统分析错误的方法我们公司通常采用邀请用户参与进行

需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规

格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入

配置管理库。

虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求

变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申

请单发送给项目配置管理员，在通过配置配置员转交质保小组，负责

组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所

带来的影响，小的变更则直接记录入变更记录原因分析项和风险项

栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相

应的文档实施同步变更（包括需求规格说明书、详细设计文、安装手

册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而

将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进

行协调会议，讨论变更取舍问题或是项目进度变更问题。

决定变更之后，由项目经理组织实施变更，测试人员检测变更结

果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的

成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用

户一同测试并由用户签字后同意方可上线。

b、系统设计

优良的体系结构应当具备可扩展性和可配置性，而好的体系结构

则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究

竟是采用哪种设计方法好呢。

对于设计选型不能一概而论，需要针对项目的结构、项目的特征

和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如

果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没

有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所

周知面向对象设计方法的优势，我们还是不如采用面向过程的方式

（除用户指定开发设计方式外）可以减少项目承担的技术风险。

我们公司有过一个项目，用户指定需要采用面向对象分析、设计

和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对

象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验

缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。针

对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技

术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，

导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用

集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配

置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。

这样方便大家的互相学习，减少重复的工作。在这次开发中我们公司

从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次

项目的开发，小组成员也积累了丰富的面向对象的开发经验。除设计

选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可

以减少工作中

的重复工作，降低开发成本。这要求我们再设计阶段通过对用户

需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责

设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文

档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人

员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，

及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计

文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进

行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交

由配置管理员进行设计文档的版本控制。

C、实现

实现也就是代码的生产过程。这里不仅包括代码的产生，同时也

包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码

并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来

的用例需要得到项目组成员认可由项目经理审核通过才能进入配置

库。同时程序员调试完程序提交测试人员进行程序正确性检测。

d、文档管理

文档维护主要是配置管理小组的工作。文档从用途上分主要分为

内部文档和外部文档。内部文档包括：项目开发计划；需求分析；体

系结构设计说明；详细设计说明；构件索引；构件成分说明；构件接

口及调用说明；组件索引；组件接口及调用说明；类索引；类属性及

方法说明；测试报告；测试统计报告；质量监督报告；源代码；文档

分类版本索引；软件安装打包文件。

外部文档主要包括。软件安装手册；软件操作手册；在线帮助；

系统性能指标报告；系统操作索引。

如何保证文档的全面性，使其真正为项目的进度提供保证，又不

因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问

题。解决此问题，其核心仍然是个“度”的问题。在本项目的开发中，

配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。

当有文档模板后需要书写文档的人员只剩下“填空”的工作，从某种意

义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更

细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时

文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者

进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。

配置管理小组真正核心的工作是对文档的组织管理。根据文档的

不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转

交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。

文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开

发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风

险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作

用。

从以往做大项目的经验来看，写作文档在项目开发的早期可能会

使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需

要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发

过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，

或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档

交流的准确性和高效性。

3、系统维护质量保证

在我们公司，维护小组的任务一方面是保证对项目客户的跟踪服

务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来

以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由

项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，

而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性

的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需

要用户测试确认上线。如果较大的修改则需要走

变更控制流程，用户或者维护人员填写变更申请，经专家会议讨

论分析可行方案在由维护小组实施，通过测试后方可提交用户。

维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用

户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人

逐步减少，并转移到其它项目中去。

第四篇：正版软件管理制度正版软件管理制度

为切实增强广大干部职工尊重和保护知识产权的意识，加强镇政

府的软件正版化管理，建立长效管理机制，特制订本管理制度。

第一条适用范围

本制度适用于妙峰山镇全体干部职工。第二条职责部门

镇政府成立软件正版化领导小组（设在办公室），负责全面管理

和监督本制度的贯彻和落实情况。具体负责软件正版化工作的组织和

日常维护。

第三条软件正版化工作重点范围操作系统、办公软件、安全软件

等。

第四条各科室负责人作为第一责任人，保证本科室软件使用正版

化。

第五条领导小组办公室制定软件资产管理制度。指定人员担任正

版软件资产管理员岗位，负责正版软件的登记造册等工作。

第六条根据需求制定正版软件采购计划，并将软件采购费用纳入

年度预算，确保软件正版化工作资金到位、措施到位、管理到位。

第七条加强软件资产管理。规范正版软件采购，购买计算机办公

设备必须符合预装正版操作系统软件的要求，更新计算机操作系统软

件必须使用正版产品。

第八条要建立规范的正版软件管理台账，对各类正版软件进行登

记。内容包括：软件名称、版本、授权、安装与使用情况。同时对有

关的资料（如软件介质、说明书等）进行妥善保存。

第九条要加强软件正版化培训工作，进一步提高工作人员操作、

使用软件的能力和水平，提高工作人员的法律意识，使用正版软件更

好地服务于机关各项工作。

第十条防止任何可能侵犯软件知识产权的风险应注意：

1.电脑内已安装未授权的软件，应立即移除。

2.对以团体身份获得使用权的软件，需确保已安装的软件数目没

有超过已购置的软件许可数RO

3,购买新的电脑时，已预装相关软件的，要核对该软件是否已获

得适当的授权。

4.加强版权意识，不准向其他单位或个人提供任何正版软件。因

向其他单位或个人提供正版软件而造成版权纠纷者，由软件提供人承

担一切后果，未取得版权拥有人的明确批准，不得复制及更改软件。

第十一条镇机关职工不得从事下列行为：

1.擅自复制和销售计算机软件产品的复制品。

2.在购买计算机等设备时，要求或允许销售商安装非正版软件。

3.超越授权使用许可的要求扩大安装范围。

4.未经授权把计算机软件放在网上供他人下载。

5.明知未经授权的计算机软件而从网上下载。

6.故意规避或破坏软件著作权人为保护其著作权而采用的技术

措施。

7.故意删除或改变计算机软件权力管理信息。

第十二条对于使用非法软件给镇机关形象造成重大影响的，一经

查出，除追究相关责任人的责任外，还将追究相关科室负责人的行政

责任。

第十三条本管理制度由镇软件正版化领导小组办公室负责解释

说明。

第十四条本管理制度自印发之日起施行。

第五篇：软件部门管理制度软件部门管理制度

第一章、工作

第1条员工应遵守本公司一切规章、通告及公告。

第2条员工应遵守下列工作事项：

1）在每工作日9。10前明确（制定）当天的工作计划。

2）在每工作日17。50前必须将代码在不报错的形式下签入指定

的源代码管理器中，并且做好自己的本地备份，并且在工作计划系统

里提交当天的工作总结。项目主管每周五负责对源代码管理器进行本

地备份及错误的修复。

3）员工在每月的10号前对本月的工作大概做出计划，并且对上

月的工作计划做出总结，以书面形式交由部门经理。

4）对公司产品软件的任何修改都需要业务部门及信息中心相关

领导的审批，并且修改之后的效果也必须经由相关领导认可，及时将

所更改的功能对相关培训人员进行讲解。

5）严格遵守以下的软件开发流程：

①.签定《系统开发需求申请单》；

②,进行需求调查，填写《需求说明书》；

③制定相应的《项目开发计划》；

④,填写《项目估计表》，进入需求封闭期；

⑤.在规定的时间内向业务部门提交《需求设计报告》（注：此项

流程不计入开发周期）；

⑥.严格控制需求变更，如果实在需要变更需求，需要填写《需

求变更报告》，并且及时更新相应的文档；

⑦.在开发周期内根据《项目开发计划》进行软件项目的开发；

⑧.在开发周期内开发人员每天需要向上级提交电子档的《开发

进度报告》，总结每天的编程心得；

⑨.在开发周期内至少每周制定一次《技术评审计划》并且填写

《技术评审报告》；

⑩.对系统进行测试时需要制定《系统测试计划》、设计《测试用

例》，最终填写《测试报告》；

⑪.测试完毕，在实际系统中上版，并对相关操作人员进行培训

6）在开发的过程中必须严格遵守公司颁布的最新的《编码规范》

和《数据库设计

规范》。

7）在每周一部门经理应对本周工作做出计划及安排，并在周五

进行一次工作总结。

8）在工作时间里不得怠慢拖延，不得干与本职工作无关的事情。

9）在工作时间里不得中途任意离开岗位，如需离开应向主管人

员请示并获批准后

方可离开。

10）未经许可不得私自将公司资料携带出公司。

11）任何人未经允许，不得擅自将自己的电脑配件安装在工作电

脑上。

12）未经机主本人允许，不得擅自使用、移动或拆装他人的计算

机。

13）员工对自己的工作电脑既有使用的权利又有保护的义务。任

何的硬件损坏必须

给出损坏报告，说明损坏原因。

14）不得安装有可能危及公司计算机网络的任何软件，如果确实

有需要进行软件测

试的，必须将计算机脱离公司计算机网络进行单机操作。任何对

公司内部计算机网络的黑客行为是绝对禁止的，一经查实将按公司有

关规定严肃处理。

15）公司提供的互联网访问服务只能被使用在与公司业务有关的

方面，否则一经查

实将按公司有关规定严肃处理

第二章、培训

第3条为提高员工的知识技能及发挥其潜在智能，使公司人力资

源能适应本

公司日益迅速发展的需要，公司将举行各种教育培训活动，被指

定员工，不得无故缺席，确有特殊原因，应按有关请假制度执行。

第4条新员工进入公司后，须接受公司的岗前专业培训，培训时

间应不少于

20小时，新员工培训由公司根据人员录用的情况安排，在新进

公司的前三个月内进行，培训不合格者不再继续留用。

第5条员工培训期间，针对每次培训I,都需要有培训记录及总结。

第6条培训的主要内容：

1）本职位的任务、责任和权限；

2）代码规范及其它相关开发规定；

3）专业技术的提高；

4）需求分析能力；

5）产品意识；