第1个回答 2014-05-05
在项目进度被延滞或质量保证小组认为某阶段开发质
量有问题时，提请项目经理、项目负责人等必要的相关
人员举行质量会议。解决当前存在的和潜在的问题。质
量保证是建立在文档的复审基础之上，
因而文档版本的
控制，特别是软件配置管理，直接影响软件质量保证的
影响力和力度。质量保证小组的检测范围包括：系统分
析人员是否正确的反映了用户的需求；
软件执行体是
否正确的实现了分析人员的设计思想；
测试人员是否
进行了较为彻底的和全面的测试；
配置管理员是否对
文档的规范化进行的比较彻底，版本控制是否有效。
3.2
质量管理实施
有了良好的资源配备，
又如何在项目全生命周期内实施
质量保证，
让我们从以下几个方面来看质量保证的实施
过程：
3.2.1
项目进度的质量保证
项目进度是项目进行是否顺利的最直观表现。
显然在项
目开始之前，项目开发计划是必须的。如果项目开发计
划的制定的是完全合理的，
那项目进度也就真正表达了
项目与最终的交付使用之间的距离，
然而要制定完全合
理的项目开发计划几乎不太可能。可见要保证项目进
度，首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模
和类似业务的项目的经验有直接关系，
通过经验往往能
够预见潜在的阻碍，
这样要求项目计划制定者需要集众
人之力来完善计划。
当项目计划制定初期，
由质量保证小组组织召开的项目
计划评审会，邀请公司技术专家、用户以及项目组小组
成员一起讨论项目计划的可行性，
会议通常采用头脑风
暴法，各抒己见，会后由指定的记录员形成质量记录，
发送给相关人员，
对其计划中不合理的地方进行修改完
善，并由质量保证人员对其结果跟踪，以确保项目计划
完整性、可行性，完善后的计划交由配置管理人员进行
版本控制。
然而在计划实施过程中，计划不是“固定化”。常有人
道，“计划赶不上变化”，但“要跟上变化”。项目计
划以里程碑为界限，将整个开发周期划分为若干阶段。
根据里程碑的完成情况，
适当的调整每一个较小的阶段
的任务量和完成的任务时间，
这种方式非常有利于整个
项目计划的动态调整。也利于项目质量保证的实施。
实际运作中，当质保小组发现计划实施的差异后，报告
项目经理，由项目经理组织负责对计划进行周期性维
护，
对于已经变动的计划由质保小组协助配置管理小组
完成版本控制。
项目开发各阶段的质量保证
a
、需求分析
需求分析是开发人员对系统需要做什么和如何做的定
义过程。从系统分析的经验来看，这个过程往往是个循
序渐进的过程，一次性对系统形成完整的认识是困难
的。只有不断地和客户领域专家进行交流确认，方能逐
步明了用户的需求。从系统开发的过程得知，系统分析
时犯下的错误，会在接下来的阶段被成倍的放大，越是
在开发的后期，
纠正分析时犯下的错误所花费的代价越
是昂贵，也越发影响系统的工期和系统的质量。
解决系统分析错误的方法。
TAJ Technologies
公司通常
采用邀请用户参与进行需求评定，
然后对其用户的意见
由质保成员跟踪检测是否纳入需求规格说明书，
同时与
用户签字确认形成需求基线，
交由配置管理员放入配置
管理库。
虽然尽早的邀请用户参与，
仍然避免不了项目进行中用
户的需求变更请求。对于开发过程存在的需求变动，我
们要求用户填写变更申请单发送给项目配置管理员，
在
通过配置配置员转交质保小组，
负责组织专家小组和项
目组成员一起讨论实施变更的可行性及实施后所带来
的影响，
小的变更则直接记录入变更记录原因分析项和
风险项栏，大的变更则需要形成正式的变更报告，无论
那种变更都需要对相应的文档实施同步变更
（包括需求
规格说明书、详细设计文、安装手册、操作手册等）。
但是对于无法实现或是变更会带来巨大的影响而将导
致进度的延期，这时，我们将变更报告提交给用户或邀
请用户进行协调会议，
讨论变更取舍问题或是项目进度
变更问题。
作者：
麦秸杆儿
2006-5-29 16:51
回复此发言
6
软件项目质量管理经验谈
决定变更之后，由项目经理组织实施变更，测试人员检
测变更结果，
而质保小组成员监督变更实施过程并协助
配置管理员对变更后的成果物进行版本控制。
变更实施
完后，
上线前还需要指定人员协助用户一同测试并由用
户签字后同意方可上线。
b
、系统设计
优良的体系结构应当具备可扩展性和可配置性，
而好的
体系结构则需要好的设计方法，
自然设计选型成为了系
统设计首要的工作，究竟是采用哪种设计方法好呢？
对于设计选型不能一概而论，需要针对项目的结构、项
目的特征和用户的需求来分析，
同样也要考虑到参与项
目小组成员的素质，
如果其中大部分都没有从事过面向
对象的设计且项目进对紧迫，
这样没有多余的时间来培
训小组成员来掌握面向对象的设计方法，
尽管众所周知
面向对象设计方法的优势，
我们还是不如采用面向过程
的方式（除用户指定开发设计方式外）可以减少项目承
担的技术风险。
TAJ Technologies
公司有过一个项目，
用户指定需要采
用面向对象分析、设计和开发，且开发周期短，在无赖
的情况下，项目小组只能选用面向对象的软件开发过
程，由于项目小组很少从事过面向对象的开发，经验缺
乏，导致项目上马后项目进度延误，项目没有达到预期
的效果。
针对此次开发，我们分析其原因，发现小组成员在开发
过程中对于新技术互相交流少，
各自有各自的理解和想
法，造成理解上的不一致性，导致工作重复性高，滞后
项目进度。建议解决方法是项目组成员采用集中办公，
分块学习，学习的成果马上向项目相关人员发布，再由
配置管理员对其发布的文档进行整理、
规类放入配置库
以供大家共享。这样方便大家的互相学习，减少重复的
工作。在这次开发中我们公司从管理人员、设计人员到
开发人员都汲取了很多教训，同时经过此次项目的开
发，小组成员也积累了丰富的面向对象的开发经验。
除设计选型，还有一个容易被忽视的问题，就是公共类
开发。公共类开发可以减少工作中的重复工作，降低开
发成本。
这要求我们再设计阶段通过对用户需求的仔细
研究，尽可能的识别出公共类，并进行定义指定专人负
责设计通知其它设计人员，以减少重复工作。对于项目
组提供的设计文档，由质保小组组织技术专家、项目组
设计人员、开发人员和测试人员对其设计文档的评审，
检测设计文档对其下一阶段工作的可行性，
及时发现设
计中可能存在的错误，降低项目开发风险，同时确保设
计文档能为开发人员、测试人员提供切实的指导。对于
可复用的设计进行提取作为公共库设计和开发，
提供项
目组或整个公司重用。
最后交由配置管理员进行设计文
档的版本控制。
c
、实现
实现也就是代码的生产过程。这里不仅包括代码的产
生，同时也包括测试用例的产生。针对上一阶段提供详
细设计，程序员开始编码并且调试程序，测试人员则根
据设计进行测试用例的设计，
设计出来的用例需要得到
项目组成员认可由项目经理审核通过才能进入配置库。
同时程序员调试完程序提交测试人员进行程序正确性
检测。
d
、文档管理
文档维护主要是配置管理小组的工作。
文档从用途上分
主要分为内部文档和外部文档。
内部文档包括：
项目开发计划；
需求分析；
体系结
构设计说明；
详细设计说明；
构件索引；
构件成分
说明；
构件接口及调用说明；
组件索引；
组件接口
及调用说明；
类索引；
类属性及方法说明；
测试报
告；
测试统计报告；
质量监督报告；
源代码；
文档
分类版本索引；
软件安装打包文件。
外部文档主要包括：
软件安装手册；
软件操作手
册；
在线帮助；
系统性能指标报告；
系统操作索引。
如何保证文档的全面性，
使其真正为项目的进度提供保
证，又不因为文档的写作而耽误项目的进度，这仍然是
一个比较难解决的问题。解决此问题，其核心仍然是个
"
度
"
的问题。
在本项目的开发中，配置管理小
组的一个非常重要的任务还是书写文档规范和文档模
板。
当有文档模板后需要书写文档的人员只剩下
"
填空
"
的工作，从某种意义上讲，书写文档的速度会加快。如
果书写文档的人员认为文档的更细致的部分可以由他
人帮助完成，则该文档即交由他人完成，但此时文档并
不算被正式提交，当他人书写完毕之后，必须由文档的
初写者进行复审，复审通过后方可以正式提交，进入软
件配置管理的循环中。
配置管理小组真正核心的工作是对文档的组织管理。
根
据文档的不同，文档的来源也不同，有些是通过质量保
证小组经过复审之后转交给配置管理小组，
有些则会直
接从文档的出处到达配置管理小组。
文档的管理是一个
非常烦琐的工作，
但是长远来看它不仅使项目的开发对
单个主要人员的依赖减少，
从而减少人员流动给项目的
带来的风险，
更重要的是在项目进行到后百分之十的时
候起到拉动项目的作用。
从以往做大项目的经验来看，
写作文档在项目开发的早
期可能会使项目的进度比起不写文档要稍慢，
但随着项
目的进展，各个部门需要配合越来越多，开发者越来越
需要知道其他人员的开发思路和开发过程，
才能使自己
的开发向前推进。一个明显的例子就是系统整合，或者
某些环节是建立在其他环节完成的基础之上时，
就更显
现出文档交流的准确性和高效性。
3.2.2
系统维护质量保证
在
TAJ Technologies
公司，维护小组的任务一方面是
保证对项目客户的跟踪服务，
另一方面是确保该项目其
它的开发人员从项目中尽快的解脱出来以便投入到下
一个项目的开发中。
所以通常项目维护小组成员主要由
项目组的少部分开发人员承担完成。
他们不仅了解软件
的核心内容，而且与客户也不陌生，以便能够以最快的
速度修正错误。对于一般性的错误，如操作不当等引起
的问题，全部由维护小组执行完成，但需要用户测试确
认上线。如果较大的修改则需要走变更控制流程，用户
或者维护人员填写变更申请，
经专家会议讨论分析可行
方案在由维护小组实施，通过测试后方可提交用户。
维护小组的人员基本上是按项目跟进的。
当一个项目刚
刚交付用户时，在维护小组有较多的人员进行跟进，随
软件的稳定，跟进的人逐步减少，并转移到其它项目中
去。