最新CMMI3同行评审详细过程定义.docx
- 文档编号:9532017
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:20
- 大小:106.89KB
最新CMMI3同行评审详细过程定义.docx
《最新CMMI3同行评审详细过程定义.docx》由会员分享,可在线阅读,更多相关《最新CMMI3同行评审详细过程定义.docx(20页珍藏版)》请在冰豆网上搜索。
最新CMMI3同行评审详细过程定义
CMMI3同行评审详细过程定义
同行评审
4.1同行评审与测试的关系发现缺陷的手段为什么要引入同行评审而不是继续完全使用测试呢?
有些工作产品在早期阶段就可以进行同行评审去发现缺陷,但无法对其进行测试;即使到了编码阶段,测试活动也不能发现某些特定类型的缺陷(例如违反编程规范)。
从图4-1(开发各阶段缺陷放大图)可以看出,随着开发的不断开展,缺陷不断泄漏和放大,最终形成的产品是一个灰色的距离用户真正需求很远的一个"东西"。
这就需要在开发的过程中不断进行同行评审,减少泄漏到下一个阶段的缺陷。
成功的同行评审是提高质量和生产率的重要因素,不管人们喜欢与否,审查过程会迫使每个人在一种开放式的环境中工作。
一旦人们懂得了他们的工作都要接受同行评审,他们就会越早地将他们的工作公之于众,以待监督。
在同级评审上的投入把组织的一些质量成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。
更重要的是,工作产品的作者学到了如何将工作做得更好,从而避免了缺陷。
固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量,但这些可以在测试中节省更多。
从经济角度考虑,许多缺陷是在早期阶段注入的,越早消除缺陷就越能降低开发成本。
据统计,对于保存精确记录的大系统,一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。
这样一来,即使在综合考虑了同行评审活动成本的情况下,同行评审活动也会使测试成本下降50%~80%。
同时,通过同行评审,开发人员能够及时地得到专家的帮助和指导,加深对工作成果的理解,更好地预防缺陷,在一定程度上提高了开发生产率。
再者,消除工作成果的缺陷,可以提高产品质量,提高客户满意度。
(点击查看大图)图4-1 开发各阶段缺陷放大图
总之,同行评审有助于"提高质量、提高生产率、降低成本"。
但是要注意,同行评审不可能代替测试,正如测试不可能替代同行评审一样。
那么,工作产品通过了什么样的评审才算合格呢?
同行评审本身的要求有没有在质量目标里?
评审的工作量和参加人员的资格、评审时间是否有要求呢?
4.2 同行评审的种类和对象同行评审活动的关注点应该是工作产品中的缺陷,而不应该是工作产品的作者或者生产者,管理者也不应使用同行评审的结果去评价个人的行为。
同行评审的分类有很多种,自从IBM的Fagan发明了同行评审之后,软件行业提出了很多同行评审模型,比较著名的有IEEE 1028评审、微软的技术评审、Gill Graham审查、Van Emden审查、Yourdon结构化走查等。
4.2.1 同行评审的种类本书中按照CMMI模型的提法,将同行评审分为3类。
(1)正式评审(Inspection),通常是由经过同行评审培训的项目经理或PPQA主持,规模在3~7人之间为宜,一般在完成了一个工作产品后对其进行的评审。
正式评审的目的在于定位并除去工作产品中的缺陷。
(2)技术审查(Technical Reviews),或称内部评审,通常由技术负责人或项目经理召集,三人以上参加。
技术审查一般是在工作产品的中期进行或完成了某部分独立的工作产品时进行,也可在书写草案遇到问题时就其中专门的一两项问题讨论和审查。
也可以是检查工作产品与规程、模板、计划、标准的符合性或者变更是否被正确地执行。
技术审查的目的在于通过对开发人员的工作产品的技术审查,提出改进意见。
(3)走查(Walkthrough),又叫代码走查或代码走读,审查的范围根据需求的优先级通常由管理人员来确定,主要是静态质量分析和编程规则检查。
通常是小型讨论会,一般是在工作产品形成的早期进行,作者有一定的想法时,希望从中获得一些帮助或补充一些想法。
当然也可以在编制工作产品的任何阶段进行,两三个人参加,由作者主持,主要是评估和提高工作产品的质量或教育参加者。
其中,"正式评审"是正式的,"技术审查"和"走查"是常用的非正式同行评审方法。
4.2.2 同行评审的对象同行评审的对象包括所有软件开发的中间和最终工作产品,例如包括:
(1)产品需求规格说明书;
(2)用户界面规范及设计;
(3)架构设计、概要设计、详细设计及模型;
(4)源代码;
(5)测试计划、设计、用例及步骤;
(6)项目计划,包括开发计划、配置管理计划和质量保证计划等。
所有这些会涉及的评审内容,应该在编制的项目计划或者小的开发计划中体现,不应该也不能是临时性的安排。
4.3 同行评审过程根据同行评审的重要程度,正式评审、技术审查和走查三种形式的流程和成果物的使用力度不尽相同,但其主要的步骤和内容大体一致,参见如图4-2所示的同行评审流程图。
(点击查看大图)图4-2 同行评审流程图
4.3.1 正式评审流程正式评审包括下述6个基本步骤。
(1)预备:
为保证评审的质量,可以先进行一个预备会议。
会议上,由作者花几分钟的时间向评审组概要介绍评审材料,例如讲解一下本工作产品的目标是什么,其他相关的实现细节、开发标准等。
应该允许甚至鼓励评审组成员动手查看工作产品,或者查看开发过程中所用到的检查单等。
这个讲解的过程从某种角度上来说,也保证了作者提交工作产品的质量。
会议结束时把文档分发给每位与会者,下发的材料应该控制在2小时之内审核完成为宜。
这些文档可以包括:
要审查的工作产品;参考文档;工作产品评审检查表;工作产品审阅情况记录表。
评审主持人负责根据具体情况确定什么时间开始真正的评审会议。
(2)审查:
在预备会和正式评审会之间,评审小组成员会对工作产品进行彻底检查,并依据相关标准和准则评审工作产品,记录发现的缺陷、问题种类与严重程度、所用的时间等。
(3)评审:
在预定的正式评审时间内(会议时间建议控制在2小时),评审小组成员以会议形式聚在一起,依次对产品进行检查。
每个评审员花一定的时间(一般为十几分钟)指出问题,并和作者确定问题和定义问题的严重程度。
注意,评审过程中是发现错误,而不是现场改正它们。
会议中,记录员详细记录每一个已达成共识的缺陷,包括缺陷的位置、简短描述缺陷、缺陷类别、该缺陷的发现者等。
未达成共识的缺陷也将记录下来,加入"待处理"或者TBD标识,评审主持人将指派作者和评审员在会后处理评审会议中未能解决的问题。
(4)书写评审报告:
评审主持人根据记录员的记录和自己的总结,在一天内写出评审报告,内容包括:
根据评审专家个人的输入创建总的问题清单;加入会议中发现的问题;剔除经确认属于重复或者无效的问题;共同确定需要修改的问题及修改的程度。
(5)返工:
作者根据评审报告的决议,负责解决确定的所有缺陷和问题。
(6)跟踪:
评审组长必须确保所提出的每个问题都得到了圆满解决。
必须仔细检查对文档的每个修正,以确保没有注入新的错误。
4.3.2 技术审查流程技术审查通常包括下述3个基本步骤。
(1)准备:
评审组长(通常是项目经理)要求项目组成员提供需要考虑的特定问题并分发评审材料。
评审组长确定评审重点:
需要注意的特定问题;需要满足的特殊标准或规格说明;需要审查的接口或依赖关系。
(2)评审:
评审人各自审查评审材料,目的是发现错误,而不是改正它们(通常每次评审会不超过1小时)。
评审组组长应在一天内写出评审报告。
评审会议内容包括:
汇总个人发现的问题;加入会议中发现的问题。
(3)跟踪:
作者负责解决评审报告中的所有错误及问题。
评审组长检查所提出的每个问题都得到了解决。
组长起草评审发现报告:
问题或弱项清单;小组对如何解决这些问题或弱项清单的建议;行动事项。
4.3.3 走查流程走查对形式的要求更为简单,主要有下述两种方式。
(1)参与者驱动法:
参与者按照事先准备好的列表,提出他们不理解的术语和认为不正确的术语。
作者必须回答每个质疑,要么承认确实有错误,要么对质疑做出解释。
(2)文档驱动法:
作者向评审人仔细解释文档(或代码)。
在此过程中,可以将评审的内容(如关键代码、架构图、业务逻辑图等)用投影仪投射到屏幕上,作者对工作产品进行讲解,评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。
它比参与者驱动法可能更有效,往往能检查出更多错误。
经验表明,使用文档驱动法时许多错误是由文档讲解者自己发现的。
在走查过程中,每个评审人都要记录错误或建议,会后要整理会议记录,作为走查报告。
工作产品的作者可以根据自己的思路对走查报告质疑。
注:
对代码的同行评审其实就是代码走查,可以使用投影仪打出关键代码位置与参与人员一起读,也可以几个开发人员一起进行交叉走查。
选定的进行代码走查的范围根据需求的优先级来具体确定。
4.4 同行评审方式的选择对于同一个工作产品,根据所处于的阶段可以使用不同的评审方式。
如对于工作产品刚刚勾画、起草时,可以采用走查方式;对于完成了某一个单独的章节,可以采用技术审查方式;待整个产品完成,使用正式评审全面考察。
4.4.1 三种同行评审方式的比较对不同的工作产品,可以根据表4-1建议结合项目情况进行调整和裁剪。
表4-1 三种同行评审方式的比较种类正式评审、技术审查、走查,目的以比较详细的粒度,定位并去除工作产品中的缺陷表明工作产品与规约、计划、标准的符合性或者变更被正确地执行了评估、提高工作产品,教育参加者入口准则工作产品符合已建立的准备准则发布了评审目的,工作产品就绪,作者准备好工作产品计划中标识时机工作产品全部完成完成独立的章节架构、蓝图、草稿规模3~8人3~5人2~3人评审材料相对较少中等或较多,需要根据评审的目的确定中等准备时间3~5天准备2天准备 主持人专职主持人小组长/组长作者变更验证主持人验证返工组长验证,作为评审报告的一部分由其他的项目控制手段执行成果物缺陷清单和度量元总结技术评审报告,包括缺陷清单以及行动计划走查报告,缺陷记录以及改进建议
4.4.2 同行评审的结果同行评审的结果通常有3种:
(1)正常:
评审专家做好了评审准备,会议正常,结果明确,不需要再次评审;
(2)延期:
30%以上评审专家没有做好准备,会议无法正常进行,需要确定再次评审时间;
(3)取消:
在初审阶段就发现很多问题,需要作者进行修正,然后再进行第二次同行评审。
4.4.3 正式评审的特征相对于走查和技术评审,正式评审具有一些明显的特征。
(1)评审以一种正式的形式进行,如有正式的、事先定义好的有关职责的各种角色,并遵循组织规定的标准流程。
(2)对于任何工作产品的评审,都会组建与之对应的专门评审组,包括作者、主持人、记录员以及评审员若干。
评审组成员也可以包括项目经理、PPQA,但是不能有作者的直接领导或者管理者。
(3)评审小组先召开一个预备会议,作者会针对工作产品向大家做一个总体的介绍,例如讲解一下本工作产品的目标是什么,其他相关的实现细节、开发标准等。
应该允许甚至鼓励评审组成员动手查看工作产品,或者查看开发过程中所用到的检查单等。
(4)评审小组的主持人负责确定什么时间开始真正的评审会议,在预备会和正式评审会之间,评审小组成员会对工作产品进行彻底检查,并依据相关标准和准则评审工作产品。
(5)在预定时间,评审小组成员以会议形式聚在一起,依次对产品进行检查,主持人负责对整个会议的进展进行控制,而记录员则负责记录下整个过程。
(6)在工作产品中发现的每一个缺陷都会被认真记录下来,并被适当分类。
(7)会议结束后,负责人需要分析有关缺陷,找出产生此缺陷的原因并加以修正。
(8)主持人应确保所有的缺陷都会得到解决和修正。
如果过程需要加以变更的话,应将相关问题移交相关的过程质量组。
正式评审的正规性特征还体现在按发生频率和严重程度,仔细划分缺陷的类型,并且把这些信息运用到缺陷预防阶段以及未来产品的同行评审过程中。
4.4.4 工作产品的同行评审方式对开发过程中产生的主要工作产品所采用的同行评审方式以及参加评审人员,可以参考表4-2确定。
表4-2 常见工作产品的同行评审方式和参加评审人员
工作产品同行评审方式参与评审人员项目总体计划走查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者和过程管理者用户需求说明书走查需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家和技术支持代表产品需求规格说明书正式评审需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家和技术支持代表项目已定义过程正式审查过程改进组负责人、过程改进工作组成员、管理级的过程拥有者和使用过程的实践者的代表开发计划技术审查创建者、项目经理、维护者和程序员系统测试计划技术审查测试工程师、程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试)和质量保证代表系统测试用例走查测试工程师、程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试)、质量保证代表概要设计说明书正式评审架构师、需求分析师、设计师、项目经理和集成测试工程师集成测试计划技术审查测试工程师、程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试)和质量保证代表详细设计说明书正式评审设计师、架构师、程序员和集成测试工程师单元测试计划走查测试工程师、程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试)和质量保证代表代码走查程序员、设计师、单元测试工程师、维护者、需求分析师和编码标准专家集成/验收测试记录和报告走查测试工程师、程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试)和质量保证代表用户使用手册走查文档编写者、需求分析师、用户或市场代表、系统测试工程师、维护人员、设计师、用户教育设计师、培训师和技术支持代表用户界面设计技术审查用户界面设计师、需求分析师、用户、应用领域专家、可用性或人体专家和系统测试工程师项目总结报告技术审查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者和过程管理者
4.5 迭代生命周期的审查审查是提高瀑布模型项目质量的好方法。
但对于迭代项目来说,如何在短的周期来做该工作呢?
需要考虑迭代开发生命周期中审查的角色。
在瀑布型过程中,审查对成功是至关重要的,因为团队不看重较早开发的代码,也就是说,他们不会回到前面的"阶段"。
同时,由于瀑布周期时段很长,以至于到下游阶段发现错误时,原作者常常已经帮不上忙,即使可以,他们也已经忘记了工作的内容。
使用瀑布方法时,审查是对抗糟糕质量的唯一安全措施。
相反,迭代开发周期短(平均3~9周),每个团队成员都是确保迭代成功的关键,即当下游人员发现错误时,这些成员不仅可用,而且他们已经准备好并期望在生命周期中尽早开始修复工作。
通常在进行工作产品审查时,大家倾向于无论看到的问题对于迭代成功的重要性如何,都会猛扑向任何发现的错误(甚至是极其微小、无足轻重的)。
尽管审查似乎要求成员尽量争取完美,然而在短的迭代周期中,更应该关注的是完成工作。
一定要记住迭代方法的原则是"让迭代自己证明自己",允许质量可疑的事情进行。
当实际使用时,我们将认识到它是否足够好。
无论何种开发生命周期,审查中的主要反馈来自下游的使用者,因为他们将不得不使用系统。
对于迭代开发过程,唯一不同的是与其在交付到下一道"工序"前审查工作产品,不如把工作产品实际地立即投入使用,在实践中进行检验,这是它最重要的改进。
那么这意味着在迭代生命周期中不应该有任何审查吗?
不是的,但确实进行的次数比大部分项目团队少得多,特别是如果团队一开始就采用瀑布型的方法。
如果真的接受迭代方法,那么审查的数量应该被自动地减少。
举例来说,如果迭代项目的生命周期是六周,则应该考虑进行多少审查工作,而不影响完成迭代的工作。
在迭代开发中,创建计划证明迭代过程的正确性是非常必要的。
对于重视审查的项目团队,在初始阶段还有一个额外的步骤。
就是要将需审查的每个工作产品映射到迭代中。
假设限制每个迭代过程中最多三个工作产品,那么对于六周的迭代过程,三个审查会显得很繁重,唯一的办法就是减少审查的数量,因而需要为审查计划提供许多提示,并且确保正确的人参与。
,避免落入频繁审查的圈套。
4.6 同行评审的注意事项为了有效地提高同行评审过程的质量,经常需要对过程数据进行度量(关于软件度量的专题,见本书第7章中相关内容),作为进一步提高过程的依据。
公司有一次组织产品需求的同行评审,会议定在5号上午9:
00~11:
00进行。
开始之前采用邮件形式通知了参会人员,并没有把评审材料发给大家。
会议邀请了两位技术负责人,其他人员都是对技术不是很了解,且不了解评审过程与意义的管理人员,没有安排专门的人员做会议记录。
会议上,大多数管理人员按照个人的喜好与想法来评价软件的优缺点,并且对此软件的开发人员进行评论,提出了偏离评审会议主题的各种意见,使得原本安排2个小时的评审会议时间延长到了4个小时。
软件中存在的问题给予了很少的关注。
主持人宣布了会议的主题。
作者开始简述自己的产品需求,接下来评审提出自己的意见。
评审员小李说:
"关于查询结果排序:
查询后的表格应该是动态的,现在FW是固定的,这个需要改进。
"其他人也参与该问题的讨论。
"如果继续使用FW提供排序功能,那么需要FW项目组进行修改,FW的负责人小张说说是否可行,打算怎么修改。
"小张开始提出自己的想法以及如何改进,几个同行也都说出自己的想法,有时会遇到不统一的现象,开始解释和说明,等这个问题讨论完了,才发现时间已经过去40分钟。
大家继续后边的问题,2个小时过去后,需求评审只进行了一半,会议以没有评审结果而宣告结束,只能下次继续进行,会议中没有任何表格填写。
通过上边的例子,我们看到在评审中发生了5个违反规则的做法:
(1)采用邮件方式通知大家,没有专门通知到个人。
(2)没有预先下发被评审的工作产品和检查单。
(3)会议的焦点不是在确定问题上,而是转到了如何解决问题。
针对问题的解决,讨论很多,同行评审会议最主要的是找到和确定哪些是问题,至于如何解决问题,可以在评审会后相关人员继续讨论。
(4)主持人没有经验,没有很好地主持和控制会场局面,当遇到会议跑题的时候,一定要记住会议主题,将讨论的焦点带回来,不然容易越走越远。
(5)没有作缺陷的记录和发现工作量的记录。
同行评审时,需要注意以下几点事项。
4.6.1 同行评审遵循的原则同行评审有所谓的"123准则":
同行评审准备时间大于开会时间,同行评审期间发现的缺陷数量应该是同行评审准备期间发现的缺陷数量2倍以上,同行评审发现缺陷的效率是测试发现缺陷的3倍。
(1)同行评审需要管理层的支持,如果没有,即使是目标明确的开发组成员也会抵制进行评审。
管理层的支持包括建立评审策略和目标,提供资源、时间、培训和激励,并遵守评审小组的决定等。
(2)同行评审是结构化的过程,涉及许多参与人员的角色,在评审专家的选择性上,一定要注意其中的互补性。
经验表明,同行评审的参加人员在他相关的技术领域与方向发现缺陷的效率较高,需要为参加人员分配职责,会议参加人员要从不同的技术角度发现缺陷。
(3)对于每种类型的同行评审,应制定通用的工作产品评审检查表,必要时可以进行裁剪以适应特定项目的要求。
工作产品评审检查表应涵盖审查计划、准备、实施、结束和报告准则。
(4)评审开始前,评审人应提前准备好自己所关注和将要提出的问题。
(5)评审的重点在于发现问题,而非解决问题,再加上认真细致的准备工作,可以最大程度避免在评审中浪费时间。
(6)对于技术人员工作的审查,应由技术人员进行,管理人员不要参与。
但应将评审结果和解决所发现问题的日期通知管理人员。
(7)评审的过程是对事不对人的,例如用"这个假设是错误的"来表述,而不是尖刻地说"你的假设根本不对"。
(8)成功的审查要求所有参与人员精力高度集中,可能会使参与人员十分疲惫。
因此,每个审查阶段最好不要超过2小时。
对每个人来说,一天最好只参加一个阶段审查。
(9)将评审数据输入到组织度量库中,用于监测评审效果,并管理和跟踪产品质量。
相关的度量数据示例有:
在全过程使用同行评审,要占10%的开发工作量;每20页叙述性文档,需要40人时;每12页概要设计,需要30人时;每1000行代码,需要55人时;使用一段时间后,评价一个项目或一个组织的审查结果需要1人月。
4.6.2 同行评审关注的问题
(1)有同行评审计划,并在每次评审前进行详细安排,如邀请合格的专家参加评审,邀请被评审产品的作者参加评审,明确定义应该评审哪些内容,评审人员要有明确的分工。
(2)对同行评审中发现的缺陷进行详细记录,如缺陷所属模块、缺陷严重程度、解决期限等,并安排相关人员对缺陷进行跟踪直至解决。
(3)对评审的过程进行度量,如评审准备时间和评审时间以及这两个时间之比,评审准备期间发现的缺陷数和评审期间发现的缺陷数以及这两个数值之比,评审工作产品的规模和评审效率等。
(4)为保证同行评审的独立性、公正性,需要有经验的组外同行参加,需要对评审人员的能力定期衡量,及时更新保证其有效。
(5)对类似的软件进行评审和测试。
有句话说得很好"你想不到的你的敌人会告诉你",通过对竞争对手产品研究,可以很好地提高工作效率。
4.6.3 同行评审通过的准则同行评审通过需要满足以下的准则。
1.最小准则
(1)工作产品已经返工和确认;
(2)主持人已经发布审查报告。
2.基于组织的度量元或早期的审查,可以为这类工作产品设置出口准则
(1)剩余主要缺陷数的估计是否在限定范围内;
(2)剩余次要缺陷数的估计是否在限定范围内;(3)变更数量在限制范围内(例如:
IBM一个部门的指南规定,变更代码应少于评审代码的5%。
Ebenau,1994,p.58)。
4.6.4 同行评审的经验共享只有软件的生产者是唯一可能做到生产出无缺陷程序的人,其他任何人都对此无能为力。
(1)所有的缺陷最终都应追溯到需求,因为最严重的错误是"导致程序无法满足需求"的错误。
(2)软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动(如需求和设计阶段同行评审和走查等)。
(3)软件开发人员应避免检查自己的程序,利用同行评审的方式对代码进行审查(因为自己检查容易依照原有的程序设计思路进行,往往查不出问题)。
(4)在进行各种分析和修复工作中,要充分注意修复工作所产生的影响效果和波及效果。
(5)统计表明大约有60%的错误是在设计阶段之前注入的,并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。
错误发现得越晚,修复它的费用就越高,而且呈指数增长的趋势(见附录中1:
10:
100公理)。
(6)程序中的大部分错误往往是在一小部分模块中发现的,遵循普遍适用的"二八定理"(即80%的错误往往是由20%的模块所造成的)。
(7)缺陷会掩盖或加重其他缺陷。
也就是说,当一个程序有许多缺陷时,由于缺陷相互作用,使得发现和修复缺陷的过程更加复杂。
这使得一些缺陷很难查找和修复。
一个缺陷可能掩盖其他缺陷,使得这些被掩盖的缺陷难以发现,增加了它们逃过测试的可能性。
(8)遵照规范化的方法,仔细复查和测试每个小程序模块,这比让任何测试组在你的程序中发现缺陷的效果要好。
也就是说,尽早地将缺陷排除掉。
测试不能避免缺陷的发生,只能是一种补救。
4.6.5 文档审查重点文档审查要对文档的完整性、一致性和正确性进行审查。
1.文档的完整性审查
(1)用人工审查的方法,验证所提交软件文档是否齐全;
(2)文档中是否包含对软件接收输入数据类型和边界值的描述或说明,包括最大值、最小值、键长、文件记录的最大长度、搜索准则最大值、最小样本尺寸;(3)对不可能提供固定的边界值(例如,某些边界值依赖于应用类型或输入数据)的情况,是否说明极值;(4)是否包含与保密信息有关的信息,应包括防止非法授权访问的措施说明。
2.文档的一致性审查
(1)用人工审查的方法,审查文档内容和术语的含义前后是否一致,有没有自相矛盾的地方;
(2)检查文档与程序的一致性;(3)检查书面文档与联机帮助文档的一致性。
3.文档的正确性审查
(1)用人工审查的方法,审查文档内容是否正确和准确;
(2)是否有错别字;(3)是否有二义性的定义、术语或内容。
4
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 最新 CMMI3 同行 评审 详细 过程 定义
![提示](https://static.bdocx.com/images/bang_tan.gif)