图书--质量保证计划.doc_第1页
图书--质量保证计划.doc_第2页
图书--质量保证计划.doc_第3页
图书--质量保证计划.doc_第4页
图书--质量保证计划.doc_第5页
免费预览已结束,剩余12页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

编号 03622GDOC5版本 1.0 软件质量计划(标准:GB/12504-90)项目名称 图书馆管理系统项目负责人 编写/校对见03622G0DOC1 审核 2003.12.16标审 2002.12.16批准 2002.12.16单位 软件项目管理第3小组项目小组成员: 目录1.1 引言 31.1.1目的 31.1.2定义 31.1.3参考资料 31.2管理 31.2.1机构 31.2.2任务 41.2.3职责 41.3.文档 41.3.1基本文档 41.3.2其他文档 51.3.3文档质量的度量准则 61.4 标准、条例和约定 61.5 评审和检查 61.5.1评审内容 61.5.2评审原则 71.6 软件配置管理91.7.工具和方法 91.8 媒体控制 91.9 对供货单位的控制 101.10 记录收集、维护和保存101.11.附各种评审和管理表格 111.1 引言 1.1.1目的本计划的目的在于为使软件开发产品满足用户的需求而制订的各种质量保障措施.并且为项目组积累质量意识和经验.1.1.2定义SQA:软件质量保证的英文缩写. 软件质量保证是建立一套有计划,有系统的方法,来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。1.1.3参考资料GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 12504 计算机软件质量保证计划规范 清华版 1997年2月第一版 郑人杰 机械出版社1.2管理项目组1.2.1机构软件配置管理小组软件质量保障小组质量总结版本控制过程控制功能变更功能验证设计审核需求审核1.2.2任务软件质量保证工作涉及到软件开发中的所有过程,质量管理工作要常抓不懈,质量管理要做到天天有文档记录和跟踪检查.软件质量保证小组的成员要根据自己分配的各个功能模块尽早地检查项目计划各项工作是否按时保质完成,不能的等到开发人员功能模块做好后再进行检查,要做到勤检查,勤沟通.1.2.3职责a.项目组长统一管理软件质量保障工作,负责协调项目组中的问题和成员间的关系.b.各模块的质量保障成员认真负责各模块的质量检查和评审工作.并对质量检查情况进行记录.c.客户方的质量检验人员配合软件质量保证人员的工作,保证项目按计划完成.需求审核:郭清华, 韦潜设计审核: 曹玉林, 李超,文档管理及配置管理: 张曙丽, 潘晓雁功能验证确认: 王振辉, 王振铎注:以上人员要 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。及时将软件质量保证工作及结果通知给相关组别和个人。 1.3.文档以下是图书借阅系统软件开发过程各阶段需要编制的文档名称及其要求,并且规定了评审文档质量的通用的度量准则。1.3.1基本文档为了确保软件的实现满足需求规格说明书中规定的各项需求,项目组至少应该 编写以下五个方面内容的文档: a.软件需求规格说明书b.软件概要设计说明书c.详细设计说明书d.项目进度计划 e.软件测试计划 1.3.2其他文档 除了基本文档之外,还应该包括以下五个方面的文档:a.软件质量保证计划b.风险分析计划c.软件配置管理计划 d.各阶段评审文档 注:软件质量保证计划,风险分析计划,软件配置管理计划由项目组开会讨论制定,各阶段的评审文档由各专人负责撰写,评审内容和报告也由小组评审会产生.1.3.3文档质量的度量准则文档是软件的重要组成部分,是软件生存周期各个不同阶段的产品描述。确认就是要检查各阶段文档的合适性。评审文档质量的度量准则是有以下六条: a. 完备性:所有承担软件开发任务的单位,都城必须按照GB 8567的规定编制相应的文档,以保证在开发阶段结束时其文档是齐全的。 b. 正确性:在软件开发各个阶段所编写的文档的内容,必须真实的反映阶段的工作且与该阶段的需求相一致。 c. 简明性:在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简炼,适合各种文档的特定读者。 d. 可追踪性:在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性和横向可追踪性两个方面。前者是指在不同的文档的相关内容之间相互检索的难易程序;后者是指确定同一文档某一内容在本文档中的范围的难易程度。 e. 自说明性:在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。 f. 规范性:在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。 1.4 标准、条例和约定 在图书借阅系统的开发过程中,还必须遵守下列标准、条例和约定:软件配置管理计划,图书借阅系统小组编 项目计划,图书借阅系统小组编1.5 评审和检查根据我们项目小组书写的文档内容分为项目计划评审、需求评审、概要设计评审、详细设计评审、软件验证和确认评审下面给出每次评审应该进行的工作。1.5.1评审内容A 项目计划的评审主要是关注的核心在于估计是否准确;人员安排是否合理;以上两个方面如果合理,项目的进度就不会出很大的问题。B 需求的评审主要关注需求来源、需求的准确性、需求的完整性,避免产生二义性;最好让测试人员和客户参加,以便让各角色达成共识。C 设计的评审(包括概要设计和详细)在总体设计评审中,最好将已经评审通过的需求文档从配置管理库中提出,对照总体设计是否和需求一致;另外,技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。D 管理性的评审管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结,是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等。1.5.2评审原则评审对于软件质量来说是很有效的一种方式,但是在实施的过程中效果不是很理想,常常会出现走形式,使评审会议变成了讨论会议,对具体的问题争论不休,经常跑题,使评审的效果大大的降低。我们在项目开始前制定评审原则,供项目小组评审人员遵守.评审的目的是及早高效的发现并消除开发过程中出现的缺陷。项目评审计划有,但是在具体的实践中把握不好一些细节的东西,这些主要的问题大多数发生在评审会议的组织上,而这些细小的环节才是评审是否成果的关键。只有评审会议比较完满了。其他修改Bug、消除缺陷都比较容易完成。我们在这里规定一下评审会议的组织。评审会议流程一般采取以下几个步骤:评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。一、 评审会议的准备二、 会议的发起人召集会议,发出评审通知(评审内容、会议时间、会议地点、参加人员等),并且将相关待评审的相关资料也发送给参加会议的评委;主要的目的有两个:第一、 让参加会议的人员对会议的内容有一定的了解,在会议前做好准备,避免盲目的参加会议而浪费自己和其他人的时间;第二、 如果该评委在会议时间有其他紧急的事情,可以及早反馈给会议召集人,必便召集人重新确定评委或者评审会议改期召开。三、 评审会议的召开四、 一般情况下,确定一个会议主持人;其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。对于待评审的工作产品由其生产者采用“走读”的形式进行讲解,在讲解的过程中回答评委提出的问题。会议记录人主要是记录会议中发现的所有问题,方便会后的修改完善。QA人员参加会议主要的关注点在于对照SQA的检查表Checklist检查评审的流程是否符合规范。三、 评审会议的跟踪将记录的问题汇总到评审记录表,由项目组进行修改、完善;SQA监督所有问题是否封闭。评审中应当把握的几个原则:A 评审工作产品,而不是评审开发者评审涉及到别人和自我。如果进行的恰当,可以使所有参与者体会到温暖的成就感。如果不恰当,则可能陷入审问的气氛之中。应当温和的指出错误,会议的气氛应当是轻松和建设性的;不要试图贬低或者羞愧别人。主持人应当加以引导,以保证会议始终处于恰当的气氛和态度中,如果失去控制应立即休会。B 制定日程,并且遵守日程各中会议都有一个主要的缺点:放任自流。评审会议必须保证不要离题和按照计划进行。主持人要有维持会议的程序的责任,有人在转移话题的时候应当提醒。C 限制争论和辩驳评委提出问题时,未必所有人都能认同该问题的严重性或者能马上打成一直的意见。不要花费时间争论这一问题,应当记录在案,留会后讨论。D 对各个问题发表见解,但是不要试图解决所有记录的问题评审会议不是解决问题的会议。问题的解决由生产者自己或者其他人的帮助下完成。问题的解决方案应当在会后进行。E 作书面笔记有时候让记录员在黑板上作笔记是个好主意,在记录的时候,评委可以推敲措词,确定问题的优先次序。F 限制参与人数,并且坚持事先做准备俩个人的脑袋好过一个,但是14个脑袋未必就好过4个。将评审涉及的人员数量保证保持在最小的值上。所有参与会议的人员要事先作好准备。G 为每个可能要评审的工作产品建立一个检查表检查表能帮助评审主持人组织会议,并帮助每个与会人员将注意力集中在重要问题上。H 为评审分配资源和时间评审要占项目组的资源和时间。所以,评审会议一定要作为软件工作活动的任务加以调度。可以在综合计划中考虑进去。I 对所有的评审者进行有意义的培训为了提高效率,所有参与评审会议的人都应当接受正式的培训。J 会议时间的控制为了提高效率,每次评审会议只评审一个工作产品,并且时间最长不能超过2个小时。所以要求,在评审准备时候各位评委事先作好准备。1.6 软件配置管理对图书借阅软件系统的各项配置进行及时、合同的管理,是确保软件的配置管理工作,可按 图书借阅软件工程小组编写的软件配置管理计划。在特别注意规定对软件问题报告、追踪和解决的步骤,并指出实现报告、追踪和解决软件问题的机构及其职责。1.7.工具和方法在图书借阅管理系统开发过程中借用某些标准工具辅助开发和管理,例如在数据库设计阶段借助POWER DESIGNER 自动生成数据表,以及在软件配置管理计划中涉及到的配置管理工具.1.8 媒体控制图书借阅系统软件的各项文档及源程序代码均按权限访问,并不准私自拷贝.1.9 对供货单位的控制略(没有采购需求)1.10 记录收集、维护和保存在图书借阅系统及其所属的各个子系统的研制与开发期间,要进行各种软件质量保证活动,准确记录、及时分析并妥善保存有关这些活动的记录,是确保软件质量的重要条件。在软件质量保证小组中,设有专门人员负责收集、汇总与保存有关软件质量保证活动的记录。要收集、汇总与保存的记录名字及其保存期限见表. 记录名称及其保存的期限记录的名称与分类要保存的期限阶段阶段评审总结整个软件开发周期评审阶段评审问题记录整个软件开发周期记录阶段评审主要问题整个软件开发周期阶段评审成员整个软件开发周期日常软件阶段进度整个软件开发周期检查软件阶段产品完成情况整个软件开发周期记录软件开发费用统计表整个软件开发周期修改软件问题报告单整个软件开发周期记录软件问题修改单整个软件开发周期组织软件质量保证小组保证小组成员记录整个软件开发周期1.11.附各种评审和管理表格软件阶段进度表子系统名称模块名称填表人填表日期年 月 日项目组长开发单位或人员计划名称计划进度调整进度实际进度备注开工日期结束日期开工日期结束日期开工日期结束日期SA&SDRAPDDDCD&UTIT&STIS&ACTSSD注:SA&SD(system analysis & software definition phase):系统分析与软件业务领域定义阶段。RA(requirements analysis phase):需求分析阶段。PD(preliminary design phase):概要设计阶段。DD(detailed design phase):详细设计阶段。CD&UT(coding &unit testing phase):编码与单元测试阶段。IT&ST(integrating & system testing phase):组装与系统测试阶段。IS&AC(installation & acceptance phase):安装与验收阶段。TSSD(total software system development phase):整个软件系统的开发阶段。软件阶段产品完成情况计划进度调整日期实际日期文档名称开始日期完成日期开始日期完成日期开始日期完成日期页数备注1 项目实施计划2需求规格说明书3概要设计说明书4详细设计说明书5 测试计划6 测试报告7 用户手册8 项目开发总结9 源代码清单10 质量保证计划11 配置管理计划 软件开发费用统计表 人工费用(人月)机时小时其他(元)阶段名称项目管理系统分析软件设计编程设计数据录入其它人工终端小时主机小时外存空间其它费用出差资料其他费用SA&SDRAPDDDCD&UTIT&STIS&ACTSSD 评审问题记录登记号RPL评 审 问 题 记 录评审日期年 月 日评审性质评审 复审项目名子项目名代号编号问题摘要问题类型是否解决1234n 评审总结报告登记号RPL评 审 总 结 报 告评审日期年 月 日评审性质评审 复审项目名子项目名代号阶段名软件定义需求分析概要设计详细测试编码测试

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论