个人软件过程PSP19页word资料.docx

上传人:b****7 文档编号:23466617 上传时间:2023-05-17 格式:DOCX 页数:15 大小:147.54KB
下载 相关 举报
个人软件过程PSP19页word资料.docx_第1页
第1页 / 共15页
个人软件过程PSP19页word资料.docx_第2页
第2页 / 共15页
个人软件过程PSP19页word资料.docx_第3页
第3页 / 共15页
个人软件过程PSP19页word资料.docx_第4页
第4页 / 共15页
个人软件过程PSP19页word资料.docx_第5页
第5页 / 共15页
点击查看更多>>
下载资源
资源描述

个人软件过程PSP19页word资料.docx

《个人软件过程PSP19页word资料.docx》由会员分享,可在线阅读,更多相关《个人软件过程PSP19页word资料.docx(15页珍藏版)》请在冰豆网上搜索。

个人软件过程PSP19页word资料.docx

个人软件过程PSP19页word资料

个人软件过程

语文课本中的文章都是精选的比较优秀的文章,还有不少名家名篇。

如果有选择循序渐进地让学生背诵一些优秀篇目、精彩段落,对提高学生的水平会大有裨益。

现在,不少语文教师在分析课文时,把文章解体的支离破碎,总在文章的技巧方面下功夫。

结果教师费劲,学生头疼。

分析完之后,学生收效甚微,没过几天便忘的一干二净。

造成这种事倍功半的尴尬局面的关键就是对文章读的不熟。

常言道“书读百遍,其义自见”,如果有目的、有计划地引导学生反复阅读课文,或细读、默读、跳读,或听读、范读、轮读、分角色朗读,学生便可以在读中自然领悟文章的思想内容和写作技巧,可以在读中自然加强语感,增强语言的感受力。

久而久之,这种思想内容、写作技巧和语感就会自然渗透到学生的语言意识之中,就会在写作中自觉不自觉地加以运用、创造和发展。

个人软件过程(PSP)是一种可用于控制、管理和改进个人工作方式的自我持续改进过程,是一个包括软件开发表格、指南和规程的结构化框架。

PSP与具体的技术(程序设计语言、工具或者设计方法)相对独立,但其原则能够应用到几乎任何的软件工程任务之中。

它能够说明个体软件过程的原则、帮助软件工程师作出准确的计划、确定软件工程师为改善产品质量要采取的步骤、建立度量个体软件过程改善的基准、确定过程的改变对软件工程师的能力的影响。

●教师范读的是阅读教学中不可缺少的部分,我常采用范读,让幼儿学习、模仿。

如领读,我读一句,让幼儿读一句,边读边记;第二通读,我大声读,我大声读,幼儿小声读,边学边仿;第三赏读,我借用录好配朗读磁带,一边放录音,一边幼儿反复倾听,在反复倾听中体验、品味。

概述

死记硬背是一种传统的教学方式,在我国有悠久的历史。

但随着素质教育的开展,死记硬背被作为一种僵化的、阻碍学生能力发展的教学方式,渐渐为人们所摒弃;而另一方面,老师们又为提高学生的语文素养煞费苦心。

其实,只要应用得当,“死记硬背”与提高学生素质并不矛盾。

相反,它恰是提高学生语文水平的重要前提和基础。

随着软件工程知识的普及,要开发高质量的软件,必须改进软件生产的过程。

目前,业界公认由CMU/SEI开发的软件能力成熟度模型SW-CMM是当前最好的软件过程,并且CMM已经成为事实上的软件过程工业标准。

但是CMM虽然提供了一个有力的软件过程改进框架,却只告诉我们"应该做什么",而没有告诉我们"应该怎样做",并未提供有关实现关键过程域所需要的具体知识和技能。

为了弥补这个欠缺,Humphrey又主持开发了个体软件过程(PersonalSoftwareProcess,PSP)。

  在CMM1.1版本的18个关键过程域中有12个与PSP有关,据统计,软件项目开发成本的70%取决于软件开发人员个人的技能、经验和工作习惯。

因此,一个单位的软件开发人员如能接受PSP培训,对该单位软件能力成熟度的升级是一个有力的保证。

CMM侧重于软件企业中有关软件过程的宏观管理,面向软件开发单位,PSP则侧重于企业中有关软件过程的微观优化,面向软件开发人员。

二者互相支持,互相补充,缺一不可。

  按照PSP规程,改进软件过程的步骤首先需要明确质量目标,也就是软件将要在功能和性能上满足的要求和用户潜在的需求。

接着就是度量产品质量,有了目标还不行,目标只是一个原则性的东西,还不便于实际操作和判断,因此,必须对目标进行分解和度量,使软件质量能够"测量"。

然后就是理解当前过程,查找问题,并对过程进行调整。

最后应用调整后的过程,度量实践结果,将结果与目标做比较,找出差距,分析原因,对软件过程进行持续改进。

  就像CMM为软件企业的能力提供一个阶梯式的进化框架一样,PSP为个体的能力也提供了一个阶梯式的进化框架。

以循序渐进的方法介绍过程的概念,每一级别都包含了更低一级别中的所有元素,并增加了新的元素。

这个进化框架是学习PSP过程基本概念的好方法,它赋予软件人员度量和分析工具,使其清楚地认识到自己的表现和潜力,从而可以提高自己的技能和水平。

●个体度量过程(PSP0和PSP0.1)

  PSP0的目的是建立个体过程基线,通过这一步,学会使用PSP的各种表格采集过程的有关数据,此时执行的是该软件开发单位的当前过程,通常包括计划、开发(包括设计、编码、编译和测试)以及后置处理三个阶段,并要作一些必要的试题,如测定软件开发时间,按照选定的缺陷类型标准、度量引入的缺陷个数和排除的缺陷个数等,用作为测量在PSP的过程中进步的基准。

  PSP0.1增加了编码标准、程序规模度量和过程改善建议等三个关键过程域,其中,过程改善建议表格用于随时记录过程中存在的问题、解决问题的措施以及改进过程的方法,以提高软件开发人员的质量意识和过程意识。

  应该强调指出,在PSP0阶段必须理解和学会使用表格进行规划和度量的技术和经验,以准确地满足期望的需求,其中最重要的是要保持数据的一致性、有用性和简洁性。

●个体规划过程(PSP1和PSP1.1)

  PSP1的重点是个体计划,引入了基于估计的计划方法PROBE,用自己的历史数据来预测新程序的大小和需要的开发时间,并使用线性回归方法计算估计参数,确定置信区间以评价预测的可信程度。

PSP1.1增加了对任务和进度的规划。

  在PSP1阶段应该学会编制项目开发计划,这不仅对承担大型软件的开发十分重要,即使是开发小型软件也必不可少。

因为,只有对自己的能力有客观的评价,才能做出更加准确的计划,才能实事求是地接受和完成客户委托的任务。

●个体质量管理过程(PSP2和PSP2.1)

  PSP2的重点是个体质量管理,根据程序的缺陷来建立检测表,按照检测表进行设计复查和代码复查(有时也称"代码走查"),以便及早发现缺陷,使修复缺陷的代价最小。

随着个人经验和技术的积累,还应学会怎样改进检测表以适应自己的要求。

PSP2.1则论述设计过程和设计模板,介绍设计方法,并提供了设计模板、但PSP并不强调选用什么设计方法,而强调设计完备性准则和设计验证技术。

  实施PSP的一个重要目标就是学会在开发软件的早期实际地、客观地处理由于人们的疏忽所造成的程序缺陷问题。

人们都期盼获得高质量的软件,但是只有高素质的软件开发人员并遵循合适的软件过程,才能开发出高质量的软件,因此,PSP2引入并着重强调设计复查和代码复查技术,一个合格的软件开发人员必须掌握这两项基本技术。

●个体循环过程(PSP3)

  PSP3的目标是把个体开发小程序所能达到的生产效率和生产质量,延伸到大型程序。

其方法是采用螺旋式上升过程,即迭代增量式开发方法:

首先把大型程序分解成小的模块,然后对每个模块按照PSP2.1所描述的过程进行开发,最后把这些模块逐步集成为完整的软件产品。

 应用PSP3开发大型软件系统,必须采用增量式开发方法,并要求每一个增量都具有很高的质量。

在这样的前提下,在新一轮开发循环中,可以采用回归测试的方法,集中力量考察新增加的这个(这些)增量是否符合要求。

因此,要求在PSP2中进行严格的设计复查和代码复查,并在PSP2.1中努力遵循设计结束准则。

 从对个体软件过程框架的概要描述中,可以清楚地看到,如何作好项目规划和如何保证产品质量,是任何软件开发过程中最基本的问题。

  PSP可以帮助软件工程师在个人的基础上运用过程的原则,借助于PSP提供的一些度量和分析工具,了解自己的技能水平,控制和管理自己的工作方式,使自己日常工作的评估、计划和预测更加准确、更加有效,进而改进个人的工作表现,提高个人的工作质量和产量,积极而有效地参与高级管理人员和过程人员推动的组织范围的软件工程过程改进。

  PSP软件工程规程为软件工程是提供了发展个人技能的结构化框架和必须掌握的方法。

在软件行业,开发人员如果不经过PSP培训,就只能靠在开发中通过实践逐步掌握这些技能和方法,这不仅周期很长,要付出很大的代价,而且有越来越大的风险。

培训的方式有很多,既可以到专门的学校进修,也可以进行自学和参加培训班,例如:

CMM网校中就有个体软件过程的课程。

●过程改进

  PSP是一个需要逐步改进的过程。

首先,要通过测量来诊断一个问题。

然后,必须客观的分析测量的数据,最后,也是最重要的,就是自身的变化。

  定义测量方法不是件容易的事情,但它总是可能的。

首先定义测量方法。

规定了测量方法后,就必须收集和分析数据。

如果需要作些改进,接下来就要分析工作过程,看看什么地方需要改进。

最后要想真正的改进,必须切实做出改进。

  仅仅进行测量并不会产生什么提高,仅仅靠努力也不会有什么提高。

在很大程度上工作方式决定了所得到的结果。

如果还是按照老办法工作,得到的结果还会是老样子。

●时间管理

  人们很可能像上星期那样安排这星期的时间。

当然,随着工作的不同,也有很多例外的情况。

  为了制定切实可行的计划,必须对所用的时间进行跟踪。

如果问上周的时间是怎么利用的,一般人都认为很容易所出每项工作花了多少时间,但是当看到实际的数据时,很可能感到十分惊讶:

花在编程上的时间比估计的少得多,花在消遣的时间比预期的多得多;乐意做的事情做的特别快,用的时间也似乎特别少,令人头疼的事情占用的时间似乎比实际花费的时间多得多。

要搞清楚时间都用在什么地方,必须对时间进行跟踪,保留一份准确的记录。

  为了检查时间估计和计划的准确性,必须把它们写成文档并在今后与实际情况进行比较。

做计划是一种技能,学习制定好的计划,第一步就是要先做计划,然后把该计划写下来,以便今后与实际数据相比较。

  为了制定出更准确的计划,需要知道以前的计划中存在哪些错误,哪些地方可以进行改进。

当按照计划进行工作时,记录下所花费的时间。

通过比较文档化的计划和实际的结果,就可以发现计划中存在哪些错误以及如何改进制作计划的过程。

制定准确计划的关键就是比较,然后就会知道如何才能制定出更好的计划。

  为了管理好时间,首先制定时间分配计划,然后按照计划去做。

制作计划容易,但真正实施计划是困难的。

特别开始的时候,按照计划进行工作可能比较困难,你可能会有很多借口,最常见的就是这份计划制作的不好。

但只有按照计划去做,你才能知道它的优劣。

  按照计划进行工作有三点好处:

第一,了解计划存在哪些问题,有助于更好的计划下一个项目。

第二,按照好的计划完成工作。

这看起来不重要,但是事实上软件工程中的许多错误都是由于考虑不周、粗心大意或是不注意的小细节而造成的,按照好的计划工作是避免这些错误的最好途径。

另一个更加微妙的好处就是它实际上在改变你的工作方式,有了计划就不用浪费时间去考虑下一步要干什么,它会帮助你把精力集中在所中的事情上,很少分心,从而提高了工作效率。

Ø了解时间的使用情况

  将主要活动分类。

在开始分配时间时,你会发现大部分时间都用在相对很少的几个活动上。

  记录每项主要活动所花费的时间。

坚持记录时间需要很强的自我约束能力,要想进行精确的记录,必须记录下每件主要工作开始和结束的时间。

除非你知道自己实际上用了多少时间,否则就不可能管理好使用时间的方式。

用标准的方法记录时间必须使用标准的时间日志。

因为需要采集的时间数据的数量增加得很快,如果不认真记录和存储这些数据,它们很可能丢失或变得混乱,这样很不利于查找或对它们进行解释。

如果不打算对这些数据进行适当的整理、归纳,就根本不必要去收集数据。

  以分钟为测量单位。

工程是在完成任务中不间断工作的时间一般都少于1小时,因此以小时为单位对工作时间进行测量不能提供用以计划和管理工作所需要的详细数据,而用分钟跟踪时间容易得多。

一旦

决定进行时间跟踪,用分钟作为测量单位将比用小时更恰当。

  处理中断时间。

采用表2.1跟踪时间时,一个常见的问题就是中断。

电话、聊天、偶尔的烦恼以及必要的休息打断的次数多得令人吃惊。

中断的时间不是有效的工作时间,并且变化幅度很大,如果不对它进行测量,实际上就在时间记录中加入了一个随机数,也就很难使用时间数据来计划和管理时间了。

事件日志中的数据能帮助你了解工作被打断的频率。

多数中断不仅浪费时间,还会打断你的思路,导致效率降低和错误的产生,因此了解被打断的频率有助于提高工作的质量和效率。

  将时间数据保存在合适的地方。

记录时间花费情况值得推荐的方法就是用工程记事本来记录时间以及其他的事情。

对一个软件专业人员,工程记事本用途很多,可以记录时间日志、程序设计方案以及运算结果,可以作为你所遵循正确的工程实施方案的凭证,可以记录下脑子里面一闪而过的想法。

推荐的方法是从工程记事本的第一页开始向后记录主要活动及其所花费的时间,最后一页开始向前记录时间日志。

记录主要活动及其所花费的时间,最后一页开始向前记录时间日志。

  周活动总结表。

通过采用时间日志收集时间数据后,你就能渐渐明白自己是如何支配时间的。

但是时间日志中的数据过于详细,需要用一种更有用的表格来总结这些数据,周活动总结表能够很好的完成这个任务。

当然我们关心的时间不会只有一周这么短,还需要一段时间内在各类任务上花费的平均时间、最大时间和最小时间。

因此采用表2.2所示格式。

周活动总结表中的数据可以帮助你了解时间都用在那些地方,还可以使用这些书对以后的几周进行计划。

例如,有了这些数据就能判断出一个大的任务所需要的时间可能接近总结表中的最长时间,而一个简单的任务需要的时间可能接近最短时间。

  记录时间的提示。

随时准备好工程记事本;当偶尔忘了记录开始时间、结束事件或中断时间,凭记忆尽早做出估计;及时总结记录的时间数据。

Ø制订计划

这里介绍两种计划:

阶段计划和产品计划。

如何制定阶段计划

阶段计划是关于这段时间内对时间的安排。

为了制定阶段计划,必须清楚时间的使用情况。

根据上一章介绍的周活动总结表,我们就可以跟踪记录自己是如何支配时间的。

在制订下一周的计划时,就可以参考最近的周活动总结表。

根据以前各个任务花费的时间,就能判断出下一周将在这些任务上花费多少时间。

制定这种计划最简单的方法就是假设将要使用的时间与过去平均使用的时间相同。

一种

如何制定产品计划

产品计划是关于制作产品活动期间的时间安排

  当工程师在项目小组中工作时,就需要计划个人的工作。

计划是按期完成承诺的任务的可靠基础,可以在工程师合作开发产品过程中协调他们的工作,可以帮助工程师了解项目的状态。

做计划是软件工程师工作的一个重要部分,要成为一个有才干的工程师,就必须知道如何制订准确的计划,也需要知道如何将这些计划与实际结果相比较,从而学会制定更好的计划。

制定产品计划是可以通过事

较为精确的方法就是首先考虑下周将要做的工作内容,然后根据以前的最长和最短时间来估计出一个合适的时间。

件加以提高的一种技能。

从现在开始对每个产品制订计划,产品可以是一个可制定的程序、一个程序设计方案或是一个测试计划,并在以后的项目中继续这样做下去。

   设定时间分配的优先级。

有些时间是固定不点的,如每周例会,可以把这些时间称为固定时间。

进行其他活动的时间就是可变动的时间,只要有时间就可以去做这些活动。

可变时间又分成需要完成的任务和自行斟酌的任务。

需要的活动如编程、读书,虽然是需要的活动,但它们的时间是可变动的,因为无论如何找出时间都可做这些事情,并且每周在这些活动上所用的时间是不同的。

自行斟酌的活动就是要做的所有其他的事情:

吃饭、睡觉、社交、观看电视及其其他的娱乐活动。

  当作出全面的时间安排时,固定时间的安排是没有什么问题,最常见的问题是分配可变动的时间。

列出需要尽快做的事情,首先努力完成最重要的任务。

重要的任务推此时,你会不自觉的为这些任务担心,立刻处理这些事情常常是更有效的,并且也将给人们带来一种完成任务的成就感。

此外,记住一旦开始了一项令人生畏的任务,就很少会感到象你想象中的那么困难。

  可以考虑从自行斟酌的活动中抽出那些额外的时间,但是这需要合理的安排,对个人是否真愿意按照这时间安排来执行。

没有休息的时间会导致人们将管理好时间的想法推翻。

做时间安排以及跟踪时间是重要的,但是时间安排一定要是自己实际愿意接受的。

  执行时间安排表。

按照时间安排表工作的能力很大程度上取决于个人的自觉性,但是它还取决于要做的工作的数量和它们的优先次序。

预料不到的时间是生活中很自然并且是很正常的一部分,特别是在软件工程中。

危机常常会打破人们的计划,因此不得不作出调整。

  在第一次使用时间安排表时,可能会感到它不是很有用,这是正常的,不要因为第一次没有起作用就放弃对时间安排的过程,而是要考虑所发生的事情,看看是否存在一些不可能再发生的反常时间、或者存在对有正常事件引起人而意外花费了很多时间?

如果是紧急的情况,不必对时间安排做大的调整,下一周再试着用它,然后复查结果。

如果一些经常发生的事情扰乱了安排,应考虑对安排进行改动,为以后类似事情提前做好准备。

  最后,按照时间安排表跟踪实施的性能,要继续收集时间数据。

根据经验复查时间安排表,在根据需要和经验修改安排,要逐步的作出改变。

在改变时间安排表时,要保存以前的版本。

Ø时间管理的目标

收集时间是为了帮助自己管理时间。

如果收集的数据被证明是没有用的,就需要重新考虑自己收集时间数据的方法。

但是,只有在已经实践了安排的时间之后再这样做。

记事作了时间安排表,如果由于一些原因对时间安排变化很大,那么也应该收集更多的数据,知道自己明白当前是如何使用时间为止。

●缺陷管理

Ø什么是缺陷

   缺陷是指程序中存在的错误,例如语法错误、标点符号错误或者是一个不正确的程序语句,是任何影响程序完整而有效的满足用户要求的东西,是可以表示、描述和统计的客观事物。

有人把缺陷称为Bug,这是不正确的。

当成为Bug时,令人想到的是那些令人讨厌的小虫子,应该把它们拍死或者不予理睬。

这会使一些重要的问题被视为琐碎小事,会养成一种错误的态度。

缺陷并不像无足轻重的Bug,更像是定时炸弹。

大家可能会觉得有些夸大其词,绝大部分细小的缺陷没有引起严重后果。

然而不幸的是,很小一部分看起来无关紧要的缺陷却能引起严重问题。

虽然现在缺陷对你来说还不是一个严重问题,但很快就会成为一个重要的问题。

  设计错误的复杂性和所导致的缺陷的影响没有之间关系,一些微小的编码错误却可能引起严重的系统问题。

事实上,绝大多数软件缺陷都源于程序员的疏忽大意。

  为了减小缺陷,就必须进行缺陷管理,研究已经引入的缺陷,确定引起这些缺陷的原因,并学会在将来如何避免重复同样的错误。

  缺陷分类。

在分析缺陷时,将缺陷进行分类是有帮助的。

通过缺陷分类,可以迅速找出哪一类缺陷的问题最大,然后集中精力预防和排除这一类缺陷,这就是缺陷管理的关键

把精力集中到最容易引起问题的几类缺陷上,一旦这几类缺陷得到控制,在进一步找到新的容易引起问题的几类缺陷上。

  不要急于把10种类型的每一类细分出若干子类,直到你已经搜集到大量程序的缺陷数据。

那时,才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。

  统计缺陷个数。

采用缺陷记录日志,记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。

人们很容易对缺陷辩解,但是要管理好缺陷,就必须收集有关缺陷的准确数据。

如果原谅缺陷,那只会自欺欺人。

如果你这样做的话,就别指望有所提高。

Ø缺陷查找技术

   为什么要尽早发现缺陷。

不要期望一个简单拼凑出来的满是缺陷的程序,经过修改可以成为一个合格的产品。

一旦生产出一个有缺陷的程序,它将永远是有缺陷的。

虽然你可以修复所有已知的问题,并且让它通过所有的测试,但它还是一个有许多不定的有缺陷的程序。

如果工程师能宽容有缺陷的工作,他将生产出低质量的产品。

“我们忙,以后在修补吧”,这样的态度不可能出产出优质产品。

  发现和修复缺陷的费用。

在典型项目中,产品被分成很多小的模块,由不通的工程师负责开发。

在模块设计、实现、编译后,工程师作初始的单元测试;单元测试后,多个模块组成一些大组件进行集成测试;经过各种级别的组件测试后,这些组件集成为产品进行产品设计;最后,将产品集成到系统中进行系统测试。

随着系统的规模和复杂程度不同,单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同,但几乎所有规模的软件产品,都需要这个过程。

  研究证明,开发过程每前进一步,发现和修复缺陷的平均代价要增长10倍。

尽管缺陷的修复时间变化很大,但平均时间总是遵循这样的规律,而与缺陷的类型无关。

  发现和修复缺陷的方法。

尽管没有办法不引入缺陷,但是在开发过程中尽早发现和修复缺陷还是可能的。

有多种发现程序中的缺陷的方法,基本上都包括以下步骤:

表示缺陷征兆;从征兆中推断出缺陷的位置;确定程序中的错误;决定如修复缺陷;修复缺陷;验证这个修复是否已经解决了这个问题。

  有多种工具和辅助手段来帮助完成这些步骤,工程师最常用的工具是编译器,它能够表示出大部分语法缺陷。

但是编译器最基本的任务是生成目标代码,并且可能会在源程序有缺陷的情况下生成代码。

因此,不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。

一般编译器仅提供了缺陷的征兆,你必须自己对问题定位,并确定是什么问题,通常很快能够做到这一点,但偶尔也需要较长的时间

  另外一种常用方法就是上面讲述的测试。

测试的质量是由测试用例覆盖所有程序功能的程度决定的。

测试可以用来验证程序几乎所有的功能,但有自己的缺点:

同编译器一样只能满足缺陷派出的第一个步骤,你仍必须从缺陷征兆找出问题的根源,然后才能修复;随着项目规模的扩大,全面的测试会花费大量的时间,要进行完全测试几乎不可能的。

  最有效的发现和修复缺陷的方法是个人复查源程序清单。

这种方法是负很难彻底清除程序中的缺陷,但事实证明,这是最快而且最有效的方法。

●代码复查

   代码复查就是研究源代码,并从中发现错误。

代码复查更有效的原因是:

在复查时看到的是问题本身而不是征兆。

从头到尾复查代码时,考虑的是程序应该做什么。

因此,当看到某些地方不正确时,就可以看到可能的问题是什么,并立即去验证代码。

复查的缺点是:

非常耗时,而且很难恰当的进行;复查时一种技能,当然可以通过学习和实践来提高。

  代码复查的第一步是了解自己引入的缺陷的种类,这是收集缺陷数据的主要原因。

因为在下一个程序中引入的缺陷种类一般会与前面的基本类似,只要采用同样的软件开发方法,情况会一直如此。

另一方面来说,当你有了技能和经验或改变了过程,缺陷的类型和数目会随之变化。

但是到了一定程度后,改进就变得非常困难了。

这是,就必须研究缺陷,这可以帮助你找到更好的发现和修复缺陷的方法。

  如何进行代码复查。

代码复查的目标是在软件过程中尽可能早和

尽可能多的发现缺陷,缺陷发现时间越少越好。

采用表4.3描述的一个有序的检查方法,在编译之前进行代码复查,是完成目标最好的方法。

  编译之前进行复查。

有几个原因说明应在编译之前进行代码复查:

不论编译前或编译后,进行完整的代码复查的时间大约相同;不论编译前或编译后,对检查语法有效性的效果是一样的;先做复查将节省大量编译时间,若不做代码复查,一般要花12%~15%的开发时间进行编译,一旦使用代码复查后,编译时间可以缩短至3%或更少;编译程序后,代码一般复查很难彻底的进行;经验证明,在编译阶段有大量的缺陷时,一般在测试阶段也有许多缺陷。

  建立个人代码复查检查表。

如果想发现和改正程序中的每一个缺陷,就必须遵照一个精确的规程。

检查表可以确保遵循这个规程,它包括一系列程式的步骤。

按照检查表去作时,就知道如何进行代码复查。

  如果能够正确使用检查表,还能知道每个步骤发现了多少缺陷。

这样就能测量出复查过程的效率,并进一步改进检查表。

检查表包括了个人的经验。

通过不断的使用和改进个人检查表,就可以帮助你用较少的时间发现这些缺陷。

表4.4是一个C++程序代码复查表的范例。

  定期更新检查表。

随着时间的推移,检查表自然的要变大。

但是,检查表的主要作用是帮助你把注意力集中在关键的方面。

太大以后,你将失去重点。

所以要定期复查缺陷数据,删除那些不能找到问题的表项。

  从个人检查表的方

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案 > 解决方案

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1