欢迎来到三一办公! | 帮助中心 三一办公31ppt.com(应用文档模板下载平台)
三一办公
全部分类
  • 办公文档>
  • PPT模板>
  • 建筑/施工/环境>
  • 毕业设计>
  • 工程图纸>
  • 教育教学>
  • 素材源码>
  • 生活休闲>
  • 临时分类>
  • ImageVerifierCode 换一换
    首页 三一办公 > 资源分类 > PPT文档下载  

    软件质量管理第三章ppt课件.ppt

    • 资源ID:1421368       资源大小:649KB        全文页数:57页
    • 资源格式: PPT        下载积分:16金币
    快捷下载 游客一键下载
    会员登录下载
    三方登录下载: 微信开放平台登录 QQ登录  
    下载资源需要16金币
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    软件质量管理第三章ppt课件.ppt

    第三章 软件评审,目录一、评审的基础知识评审的定义评审目的评审的必要性评审的分类评审方式评审结果评审中存在的误区二、研究室的评审过程评审计划评审准备评审会议及纪律评审需要注意的问题评审结论,评审表格介绍评审的验证三、评审结项后新闻稿的撰写四、案例分析,一、评审的基础知识,问题一:什么是评审?,评审的定义,Review(IEEEStd1028-1988)isanevaluationofsoftwareelementorprojectstatustoascertaindiscrepanciesfromplannedresultsandtorecommendimprovement. 评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents检验工作产品是否正确的满足了以往的工作产品中建立的规范,如需求或设计文档。,评审是指进行软件产品验证的活动,其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。评审会议重点在于确定产品的缺陷而不是如何解决问题。在会议结束之后,软件产品的生产者依据同行评审记录修正软件产品缺陷,然后由同行评审负责人确认缺陷的修正。通过评审,可以将问题记录下来,使得具有历史可追溯性。,评审目的,评审的必要性,从技术角度进行的审查是保证软件质量的重要措施,由于人的认识不可能百分之百地符合客观实际,因此生命周期每个阶段的工作中都可能发生错误。由于前一阶段的成果是后一阶段工作的基础,前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误,而且错误会积累起来,如下图所示。,原始要求,正确的规格说明,错误的规格说明,需求分析,设计,正确的设计,错误的设计,对错误说明的设计,编码,正确编码,错误编码,对错误设计的编码,对错误说明的编码,测试,正确功能,可改正的错误,不可改正的错误,潜伏的错误,不完善的软件产品,问题二:我们所描述的评审与技术评审一样吗?如果不一样,有什么区别?,与技术评审不同,评审的对象一般是部分软件工作产品,其重点在于发现软件工作产品中的缺陷。参会者为和生产者在被评审的软件工作产品上有相同的开发经验和知识的人员。一般来讲,不建议管理者作为同行参与同行评审,也不应使用同行评审的结果去评价产品生产者。,与技术评审的区别,评审的分类,一般来说,评审(PeerReview)包括下面几种: 检视(Inspection)团队评审(TeamReview/TechnicalReview)走查(WalkThrough)结对编程(PairProgramming)同行检查(PeerDeskCheck)特别检查(AdhocReview),评审方法间的区别各种评审的正式程度,最正式,最随意,检视,团队评审,走查,结对编程,同行检查,特别检查,评审方法间的区别,所有的评审活动都是下列活动的组合:计划研究评审对象举行评审会议修正错误确认修正,评审方式,会议评审与邮件评审会议评审就是组织内外的专家召开评审会议,根据评审的内容和要求进行讨论、分析并就最终结果达成一致的评审方式 。软件需求、软件设计、测试大纲需要进行会议评审。邮件评审是通过发送邮件给项目相关人员进行的评审方式。项目开发计划等需要邮件评审,评审的结果,评审结果一般有条件通过、通过、不通过这几种,如果是不通过,还要再次评审,如果是有条件通过,则需要说明什么条件(比如修改某某东西),下次就不用再开评审会了,作者修改完成后,发邮件给相关人员,多长时间内评审员要使用邮件回复评审意见,由组织者负责收集。,选择正确的评审方法选择评审方法最有效的标准是:对于最可能产生风险的工作成果,要采用最正式的评审方法。对于需求分析报告,因为它的不准确和不完善会给软件的后期开发带来极大的风险,所以必须要采用最正式的评审方法,如检视或者团队评审。又如,核心代码的失效也会带来很严重的后果,所以也应该采用检视或者团队评审的方法进行评审,而一般的代码,采用同行检查或者特别检查就可以满足要求了。,误区一:评审参与者不了解评审过程 如果评审参与者不了解整个的评审过程,就会有一种自然的抗拒情绪,因为大家看不到做这件事情的效果,感觉到很迷茫,这样会严重的影响大家参与评审的积极性。,评审中的误区,误区二:评审人员评论开发人员,而不是产品 评审的主要目的是发现产品中的问题,而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情,于是评审变了“味”,变成了“批斗大会”,极大的打击了开发人员的自尊心,以至严重的影响了评审的效果。,误区三:评审没有被安排进入项目计划 参与评审需要投入大量的时间和精力,应该被安排进入项目计划中。但是现实的情况往往是,评审变成了“义务工”,参与评审的人员必须加班加点才能完成评审任务。如此一来,出现评审人员对评审对象不了解的情况也就不足为奇了。,误区四:评审会议变成了问题解决方案讨论会 评审会议主要的目的是发现问题,而不是解决问题,问题的解决是评审会议之后需要做的事情。但是,由于开发人员对技术的追求,评审会议往往变成了问题研讨会,大量的占用了评审会议的时间,导致大量评审内容被忽略,留下无数的隐患。,误区五:评审人员事先对评审材料没有足够了解 任何一份评审材料都是他人智慧和心血的结晶,需要花足够的时间去了解、熟悉和思考。只有这样,才能在评审会议上发现有价值的深层次问题。在很多的评审中,评审人员因为各种的原因,在评审会议之前对评审材料没有足够的了解,于是出现了评审会议变成了技术报告的怪现象。,二、研究室的评审过程,岗位及职责,项目组负责人:提交项目开发计划,计划各个阶段进行评审的时间、评审方式、评审组成员,组织项目组成员解决评审提出的问题。被评审产品作者:提交被评审产品,负责对评审意见表中提出的问题进行反馈,在评审会上进行项目陈述,解决评审提出的问题。评审组成员:提交评审意见表,在评审会上发表意见。评审组长:负责评审策划、评审准备、主持评审以及评审后续工作。会议记录者:负责记录、整理并提交会议记录。SQA:主要职责为审核整个评审活动。,评审计划,项目负责人在提交的项目开发计划中,要指明项目各个阶段的评审计划。具体内容包括:各个阶段评审时间、评审方式、评审组成员等。SQA在其提交的质量保证计划中,应根据项目开发计划中描述的各个阶段评审计划,制定相应的评审检查点。,评审准备,1、组建评审组项目组提出评审组长和评审组成员名单的建议,质量组根据项目组的建议,与相关部门或人员(如外项负责人)进行协商确定。评审组成员一般包括:室主任、被评审产品项目组负责人(项目组负责人非被评审产品作者的情况)、与该项目有关的研究室成员、质量保证人员、测试人员、前一阶段技术骨干、后一阶段技术骨干等。,2、提交评审材料被评审产品作者需要准备好待评审的产品、评审意见表和检查表。待评审的产品可以是需求规格说明书、设计说明书、代码、测试大纲等。评审意见表。检查表随评审对象的不同而不同,分为:需求规格说明书检查表、设计说明书检查表、代码检查表、测试大纲检查表四种。被评审产品作者将待评审产品以邮件的方式发送给评审组长,评审组长将收到的待评审产品附上评审意见表和检查表,以邮件方式发送给所有评审组成员。,3、评审意见的处理评审组成员收到评审材料后,审查待评审产品,填写评审意见表。并在2工作日内,将评审意见表以邮件的方式发送给被评审产品作者。被评审产品作者解决评审提出的问题,修改被评审产品并填写评审意见表的“处理办法”一栏,在2工作日内以邮件的方式回复给相应的评审组成员。评审组成员根据修改后的被评审产品和项目组填写的“处理办法”进行反馈,填写“是否已改正”一栏,在1工作日内以邮件的方式将反馈后的评审意见表发送给被评审产品作者、评审组长、SQA人员。,评审组长对评审意见表进行汇总,并分析各评审组成员的意见,可能有如下几种情况:如果意见基本一致,或问题比较明确并已得到解决时,可与质量组协商决定采用会签评审方式,直接形成评审结论;如果存在一些需要会议讨论的问题,则采用会议评审方式;如果存在的问题数目很多达不到会议评审的条件,则评审组长需督促被评审产品作者进一步修改评审材料,直到符合上述两种情况为止。对于直接形成评审结论的情况,应将评审结论以邮件方式通知所有的评审组成员以及被评审产品作者;对于采用会议评审的情况,需要继续下面的过程。,4、指派会议记录者项目组负责人指派会议记录者,会议记录者一般由项目组成员担当。会议记录内容应该包括:被评审的软件工作产品的标识;软件工作产品的规模;评审组的规模和组成;每个评审员的准备时间;评审会议的时间长短;发现和改正的缺陷的种类和数目;返工工作量等。会议议程以时间的先后顺序,将整个会议分为多个阶段。需要记录会议各个阶段的主要议题、发言人、使用的主要文档、阶段起止时间。,会议总结要包含两点主要内容:首先是会议各主要成员所达成一致的结论和决议,其次是议而未决的事项。会议总结同时要明确出待解决问题的提出者和指派的主要负责人,便于日后进行问题追踪。最后要指出本次会议的缺陷和限制,作为今后会议改进的参考,使会议过程朝着更高效、更有意义和更规范的方向改进。参见会议记录编写指南。,注意: 1.要记录围绕中心议题展开的有关活动,会议讨论、争论的焦点及其各方的主要见解,权威人士或代表人物的言论,会议开始时的定调性言论和结束前的总结性言论,对会议产生较大影响的其他言论或活动等。 2.对于会议的一般性内容,可以有重点地、扼要地记录,不必“有闻必录”。所谓重点、要点,是指发言人的基本观点和主要事实、结论。对于特别重要的内容或者特别重要的发言,一定要作详细记录。,5、评审组长发出评审会议通知评审组长与参加评审会的人员商定评审会议时间,通知综合部预订会议室。在评审会时间地点确定后,评审组长要以邮件的方式向所有参加评审会的人员发出评审会议通知。,6、参加评审会人员确认参加评审会人员在接收到评审组长发出的评审会议通知后,需要向评审组长进行确认。可以采用邮件、BQQ或口头确认等方式。,召开评审会议,评审组长宣布评审会议开始。评审会议由评审组长主持,首先要说明评审的目的、要求和评审过程。被评审产品作者陈述被评审产品内容。在陈述过程中可以穿插提问。评审组成员和项目组成员就发现的问题展开讨论。评审组长对会议进行总结。,评审组长总结评审发现的问题,并将这些问题汇总到新的评审意见表中去。评审会后由被评审产品作者、项目组负责人指定的其他相关人员对评审意见表中的问题进行适当处理。产生评审结果。评审组成员以投票的方式,产生评审结果。评审结果由评审组长宣布,分为:通过、修改后通过、不通过三种。对于不通过的情况,还需要在日后重新召开评审会议。会议记录者要对整个会议过程进行详细的记录,可以参见会议记录编写指南。,会议纪律,1、不要迟到,到场人员都需要在签到表上进行签字。如有特殊原因不能参加会议需要事先向组长请假。2、不能无故不出席会议。3、开会时,不能喧哗,有意见者逐一提出,保证会议进行畅通。4、不要在会议室接听电话。5、不要在会议期间吃东西 。6、不要在会议期间闲聊。7、不要看与会议无关的资料。,评审时还需要注意以下几个问题,人员方面可以少而精,一般是3-7人。人员的选择上,尽可能找到合适的评审人员。评审会是为了发现被评审产品的问题,要始终围绕着存在什么问题,而不是去追究责任人。评审工作只对事,不对人。评审会议上不应讨论发现的问题如何解决,以提高评审会的工作效率。发现的问题如何解决是评审会后的事。评审组成员会前多做准备,多熟悉材料,可以减少陈述的时间。评审组长要维持会议程序,尽可能不要离题、转移话题。会议尽量要提高效率,一般不超过两个小时。,评审结论,对于评审会议结论为修改后通过的情况,被评审产品作者在评审会后进行修改,修改期限为35个工作日。修改完成后,被评审产品作者将修改后的被评审产品、评审意见表以邮件的方式发送给所有的评审组成员。评审组对修改后的被评审产品进行确认,在2个工作日内提出反馈意见。如有反馈意见,被评审产品作者应立即修改并重新发给评审组。评审组长应做好评审会后的问题跟踪工作,检查评审意见表中的问题是否最终被全部解决。如全部解决,则认为可以结束此次评审过程;如仍有未解决的问题,则评审组长应督促被评审产品作者尽快处理。在满足结束此次评审过程的条件后,评审组长要以邮件方式将评审报告发给所有的评审组成员、被评审产品作者、SQA人员。评审报告是评审会结束标志。对于评审会议结论为不通过的情况,需要在被评审产品作者处理完本次评审的问题后,重新召开评审会议。,质量记录,会议通知会议记录评审意见表需求规格说明书检查表设计说明书检查表代码检查表测试大纲检查表评审报告,验证,SQA审核是否按照项目开发计划中的评审计划按时进行了评审活动。SQA审核评审会议是否按照本文规定的评审流程进行,过程文档评审意见表、评审会议记录内容是否全面、完整、属实。,三、评审结项后新闻稿的撰写,在项目评审通过顺利结项后,需要撰写新闻稿。新闻稿是宣传项目成就的重要手段,通过新闻稿,大家可以得到相关项目信息,能够更加了解研发项目的进展。通过新闻稿,可以鼓舞研发人员的士气,激发他们的积极性,激励他们全力投入以后的工作中。,新闻稿,评审结束后需要写新闻稿 科学数据网格数据访问服务系统(DAS 2.0)、 科学数据网格信息服务系统(IMS 2.0)顺利结项 数据访问服务系统(Data Access Service,DAS)和信息服务系统(Information Metadata Service,IMS)是科学数据网格中间件的重要组成部分。DAS连接中国科学院分布在四十多个研究所的海量科学数据资源,利用先进的数据网格技术,提供面向大规模分布式异构自治数据资源的统一访问平台和应用环境。2004年11月发布了DAS1.0版,2005年7月发布了DAS2.0版,并已在23科学数据库建库单位中进行了推广部署,使用情况良好。信息服务系统的主要功能包括:资源信息的注册;资源信息的存储与维护;资源发现,即告诉用户目前系统中有哪些数据资源和服务;提供数据资源和服务的详细信息。自2004年以来,已发布IMS V1.0和IMS V2.0两个版本。IMS V1.0在MDS2的基础上增加了数据存储功能。IMS V2.0则在OpenLDAP的基础上开发完成,具有资源信息的注册、资源信息的存储和维护、资源信息的查询三大功能。,数据访问服务系统和网格信息服务系统的研发任务由数据网格中间件组承担,杨德婷、马永征分别担任该项目的负责人,中间件组孙鹏、周维、赵洪东、王庆阳、常丰峰、杨辉、杨建国、王军团等人参与了研发工作。质量组负责这两个系统的测试和质量管理工作。2005年11月15日,我室召开了数据访问服务系统(DAS 2.0)和网格信息服务系统(IMS 2.0)项目总结会。杨德婷和马永征分别对两个系统的研发情况作了总结,质量组张乐和李华飚就项目的测试与质量管理工作情况作了汇报。研究室领导对数据访问服务系统和网格信息服务系统的研发工作给予了充分的肯定,并提出了改进意见。 随后,我们将从以下几个方面改进DAS系统:字符集编码的自动提取、异常提示信息的完善、内存管理的优化、网格服务接口的完善、缩小三类数据库系统的差异和软件性能的提高等。IMS 系统将从服务易用性、定期备份、增加管理控制面板、LOGO改进等方面进行完善。 网络技术与应用研究室 质量组 供稿 2005-11-16,如何写新闻稿,需要标明题目,说明主题.新闻稿需要描述清晰,语言简洁,能充分表达主要内容.新闻稿内容描述需要实事求是,不要刻意夸大,也不要忽略了取得的成就.新闻稿需要介绍相关项目背景、开发时间、开发人员、结项时间等,要突出取得的成就,和提出对不足的改进建议。要描述对项目未来发展的建议与改进措施。落款需要标明撰稿人和撰稿时间。,四、案例分析,案例,某软件公司召开某项目的需求评审会议,会议开始之前只是邮件通知了参会人员,并没有把评审材料发给大家。会议邀请了一位技术负责人,其他人员都是对技术不是很了解且不了解评审过程与意义的管理人员。会议没有安排人员做会议记录。会议上,大多数管理人员按照个人的喜好与想法来评价软件的优缺点,并且对此软件的开发人员进行评论,提出了偏离评审会议主题的各种意见,为了答复各位管理人员提出的异议,只好在会议上尽量针对他们提出的问题进行解决,使得原本安排2个小时的评审会议时间延长到了4个小时。软件中存在的问题给予了很少的关注,评审会议以没有评审结果而宣告结束。会议中没有任何表格填写。,以上评审会议是否可以通过邮件进行评审?以上案例中存在哪些与评审过程不符合的地方?以上案例应该围绕什么主题进行讨论?和以上案例有关的表格有哪些?你应该如何制定此次评审过程?,讨论:简单描述一下评审过程,谢 谢!,

    注意事项

    本文(软件质量管理第三章ppt课件.ppt)为本站会员(小飞机)主动上传,三一办公仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三一办公(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    备案号:宁ICP备20000045号-2

    经营许可证:宁B2-20210002

    宁公网安备 64010402000987号

    三一办公
    收起
    展开