实现有价值的IT服务
全部博文(709)
分类: IT职场
2006-08-16 11:31:38
|
|||
| |||
第一章 引言 软件项目质量管理包括:质量计划编制、质量保证和质量控制三个过程域。质量计划是质量管理的第一过程域,它主要结合各个公司的质量方针,产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略,其内容全面反应用户的要求,为质量小组成员有效工作提供了指南,为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据,为确保项目质量得到保障提供坚实的基础。 质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动,经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作,向管理者、顾客或其他方提供信任,确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证,为质量保证提供参考依据,它是一个PD循环过程。
质量计划确定后,按照其建立的质量管理体系,各责任单位就必须按照PDCA质量环的要求,实施有效的质量控制。质量控制应贯穿于项目的整个过程,它可分为监测和控制两个阶段:监测的目的就是收集、记录和汇报有关项目质量的数据信息;控制就是使用质量监测提供的数据,进行控制,确保项目质量与计划保持一致。 对质量监测的结果应采用相应的统计方法进行分析,如帕累托图法(按发生频率排序的直方图,它显示了可识别原因的种类和所造成的结果的数量)等。通过统计分析对人员、设备、参考资料、方法、环境等影响项目质量的因素进行监控,确定项目实施过程是否在控制之中,同时进行趋势分析,对一些偏向于不合格的趋势及早进行控制。 质量控制阶段应根据验收数据做出验收决定,确定是否进入下一步工序。对于质量监测中发现的不合格,应及时利用“因果分析图”等方法分析原因,并进行适宜的处置,保证不合格得到识别和有效的控制。不合格处置包括返工、返修、降级、让步放行、报废等形式。 2.3 对软件质量保证的认识 (1)质量重要 这是 CMM产生的原因。它引入了“全面质量管理”的思想,尤其侧重了“全面质量管理”中的“过程方法”,并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。上面这些内容形成了我们对软件过程地位、价值的基本理解;在这个基础上我们可以引申讨论 SQA。 2.3.2 生产线的隐喻 如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程,产品按照生产线的规定过程进行生产。 SQA的职责就是保证过程的执行,也就是保证生产线的正常执行。 抽象出管理体系模型的如下,这个模型说明了一个过程体系至少应当包含 “决策、执行、反馈”三个重要方面。 QA的职责就是确保过程的有效执行,监督项目按照过程进行项目活动;它不负责监管产品的质量,不负责向管理层提供项目的情况,不负责代表管理层进行管理,只是代表管理层来保证过程的执行。 2.3.3 SQA和其他工作的组合 在很多企业中,将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了,有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。 国内现在基本有三种QA(按照工作重点不同来分):一是过程改进型,一是配置管理型,一是测试型。个人认为是因为SQA工作和其他不同工作组合在一起形成的。下面根据经验对它们之间的关系进行一个说明。 QA和QC ,两者基本职责; 2.3.4 QA和组织级的监督管理 有的企业为了更好的监督管理项目,建立了一个角色,我取名为 “组织级的监督管理者”,他们的职责是对所有项目进行统一的跟踪、监督、适当的管理,来保证管理层对所有项目的可视性、可管理性。为了有效管理项目, “组织级的监督管理者”必须分析项目的数据。 他们的职责对照上图的模型,就是执行 “反馈”职能。 QA本身不进行反馈工作,最多对过程执行情况的信息进行反馈。SQA职责最好不要和“组织级的项目管理者”的职责混合在一起,否则容易出现SQA困境:一方面SQA不能准确定位自己的工作,另一方面过程执行者对SQA人员抱有较大戒心。 如果建立了较好的管理过程,那么就会增强项目的可视性,从而保证企业对所有项目的较好管理;而 QA来确保这个管理过程的运行。 2.3.5 SQA的工作内容和工作方法 2.3.5.1 计划 针对具体项目制定 SQA计划,确保项目组正确执行过程。制定SQA计划应当注意如下几点: 第三章 软件项目质量管理在实际中的具体做法 3.1.1 配置管理小组职责 配置管理小组是保证项目开发完毕的同时,内部文档和外部文档都同时完成。内部文档的及时产生和规范,是保证项目开发各小组能够更好的接口和沟通的重要前提,从另一个方面讲,也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述,配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括: 完善各个部门发送需要存档和进行版本控制的代码、文档(包括外来文件)和阶段性成果; 对代码、文档等进行单向出入的控制; 对所有存档的文档进行版本控制; 提供文档规范,并传达到开发组中。 3.1.2 测试小组职责 测试人员根据详细设计的文档对软件要实现的功能进行一一测试,保证软件的执行正确的实现设计要求,在此也只证明了软件正确的反映了设计思想,但是否真正反映了用户的需求仍需要进一步的功能性测试。 测试人员只有根据软件需求规格说明书所提及的功能进行检测,才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后,需要测试的是软件的性能,软件的性能在本项目中占有重要的地位,性能要求有可能改变软件的设计,为避免造成软件的后期返工,测试在性能上需要较大的侧重。如果有必要的话,测试小组还需要做安全测试,以确保系统使用安全可靠。 3.1.3 质量保证小组职责 在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时,提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上,因而文档版本的控制,特别是软件配置管理,直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括:系统分析人员是否正确的反映了用户的需求; 软件执行体是否正确的实现了分析人员的设计思想; 测试人员是否进行了较为彻底的和全面的测试; 配置管理员是否对文档的规范化进行的比较彻底,版本控制是否有效。 3.2 质量管理实施 项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系,通过经验往往能够预见潜在的阻碍,这样要求项目计划制定者需要集众人之力来完善计划。 当项目计划制定初期,由质量保证小组组织召开的项目计划评审会,邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性,会议通常采用头脑风暴法,各抒己见,会后由指定的记录员形成质量记录,发送给相关人员,对其计划中不合理的地方进行修改完善,并由质量保证人员对其结果跟踪,以确保项目计划完整性、可行性,完善后的计划交由配置管理人员进行版本控制。 然而在计划实施过程中,计划不是“固定化”。常有人道,“计划赶不上变化”,但“要跟上变化”。项目计划以里程碑为界限,将整个开发周期划分为若干阶段。根据里程碑的完成情况,适当的调整每一个较小的阶段的任务量和完成的任务时间,这种方式非常有利于整个项目计划的动态调整。也利于项目质量保证的实施。 实际运作中,当质保小组发现计划实施的差异后,报告项目经理,由项目经理组织负责对计划进行周期性维护,对于已经变动的计划由质保小组协助配置管理小组完成版本控制。 a、需求分析 需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看,这个过程往往是个循序渐进的过程,一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认,方能逐步明了用户的需求。从系统开发的过程得知,系统分析时犯下的错误,会在接下来的阶段被成倍的放大,越是在开发的后期,纠正分析时犯下的错误所花费的代价越是昂贵,也越发影响系统的工期和系统的质量。 解决系统分析错误的方法。TAJ Technologies公司通常采用邀请用户参与进行需求评定,然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书,同时与用户签字确认形成需求基线,交由配置管理员放入配置管理库。 虽然尽早的邀请用户参与,仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动,我们要求用户填写变更申请单发送给项目配置管理员,在通过配置配置员转交质保小组,负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响,小的变更则直接记录入变更记录原因分析项和风险项栏,大的变更则需要形成正式的变更报告,无论那种变更都需要对相应的文档实施同步变更(包括需求规格说明书、详细设计文、安装手册、操作手册等)。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期,这时,我们将变更报告提交给用户或邀请用户进行协调会议,讨论变更取舍问题或是项目进度变更问题。 决定变更之后,由项目经理组织实施变更,测试人员检测变更结果,而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后,上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。 b、系统设计 对于设计选型不能一概而论,需要针对项目的结构、项目的特征和用户的需求来分析,同样也要考虑到参与项目小组成员的素质,如果其中大部分都没有从事过面向对象的设计且项目进对紧迫,这样没有多余的时间来培训小组成员来掌握面向对象的设计方法,尽管众所周知面向对象设计方法的优势,我们还是不如采用面向过程的方式(除用户指定开发设计方式外)可以减少项目承担的技术风险。 TAJ Technologies公司有过一个项目,用户指定需要采用面向对象分析、设计和开发,且开发周期短,在无赖的情况下,项目小组只能选用面向对象的软件开发过程,由于项目小组很少从事过面向对象的开发,经验缺乏,导致项目上马后项目进度延误,项目没有达到预期的效果。 针对此次开发,我们分析其原因,发现小组成员在开发过程中对于新技术互相交流少,各自有各自的理解和想法,造成理解上的不一致性,导致工作重复性高,滞后项目进度。建议解决方法是项目组成员采用集中办公,分块学习,学习的成果马上向项目相关人员发布,再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学习,减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训,同时经过此次项目的开发,小组成员也积累了丰富的面向对象的开发经验。 除设计选型,还有一个容易被忽视的问题,就是公共类开发。公共类开发可以减少工作中的重复工作,降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究,尽可能的识别出公共类,并进行定义指定专人负责设计通知其它设计人员,以减少重复工作。对于项目组提供的设计文档,由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审,检测设计文档对其下一阶段工作的可行性,及时发现设计中可能存在的错误,降低项目开发风险,同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发,提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。 c、实现 实现也就是代码的生产过程。这里不仅包括代码的产生,同时也包括测试用例的产生。针对上一阶段提供详细设计,程序员开始编码并且调试程序,测试人员则根据设计进行测试用例的设计,设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。 d、文档管理 内部文档包括: 项目开发计划; 需求分析; 体系结构设计说明; 详细设计说明; 构件索引; 构件成分说明; 构件接口及调用说明; 组件索引; 组件接口及调用说明; 类索引; 类属性及方法说明; 测试报告; 测试统计报告; 质量监督报告; 源代码; 文档分类版本索引; 软件安装打包文件。 外部文档主要包括: 软件安装手册; 软件操作手册; 在线帮助; 系统性能指标报告; 系统操作索引。 如何保证文档的全面性,使其真正为项目的进度提供保证,又不因为文档的写作而耽误项目的进度,这仍然是一个比较难解决的问题。解决此问题,其核心仍然是个"度"的问题。 在本项目的开发中,配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下"填空"的工作,从某种意义上讲,书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成,则该文档即交由他人完成,但此时文档并不算被正式提交,当他人书写完毕之后,必须由文档的初写者进行复审,复审通过后方可以正式提交,进入软件配置管理的循环中。 配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同,文档的来源也不同,有些是通过质量保证小组经过复审之后转交给配置管理小组,有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作,但是长远来看它不仅使项目的开发对单个主要人员的依赖减少,从而减少人员流动给项目的带来的风险,更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。 从以往做大项目的经验来看,写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢,但随着项目的进展,各个部门需要配合越来越多,开发者越来越需要知道其他人员的开发思路和开发过程,才能使自己的开发向前推进。一个明显的例子就是系统整合,或者某些环节是建立在其他环节完成的基础之上时,就更显现出文档交流的准确性和高效性。 在TAJ Technologies公司,维护小组的任务一方面是保证对项目客户的跟踪服务,另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容,而且与客户也不陌生,以便能够以最快的速度修正错误。对于一般性的错误,如操作不当等引起的问题,全部由维护小组执行完成,但需要用户测试确认上线。如果较大的修改则需要走变更控制流程,用户或者维护人员填写变更申请,经专家会议讨论分析可行方案在由维护小组实施,通过测试后方可提交用户。 维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时,在维护小组有较多的人员进行跟进,随软件的稳定,跟进的人逐步减少,并转移到其它项目中去。 来源:项目管理者联盟 |