200604231319105.html

软件工程的红包书

<P>3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 对照制定的安排表跟踪使用时间的方式；</P>
<P>4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 决定应该改变什么意思自己的行动达到所作安排的要求。</P>
<P>复查时间的分类情况。周活动总结表给出了每周用在各个活动上的平均时间、最大时间和最小时间。检查一下这些活动的分类，是否有些类别包含的范围过大了，而另一些有分得过细。时间管理的重点放在那些站用大部分时间的少数几项活动上。</P>
<P>作出时间安排。时间安排表是如何使用时间的计划，根据以前如何使用时间的数据，就可以作出计划，分配以后活动所需要的时间，如表3.3所示。</P>
<P>&nbsp;<IMG src="200636142820216.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636142820216.jpg" border=0>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 找出更多的时间。管理好时间的关键是逐步对使用时间的方式进行反复平衡，因为时间每天24小时是固定的。如果希望以后在某些任务多用一些时间，除非能够在另外一些任务中少用一些时间，否则，这常常只是一个愿望而已。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 制定基本规则。我们在做许多事情是都是按照一定的规则去做的。为了对时间进行有效管理，也需要有规则可循。不同的是前些规则是别人制作的，而时间管理必须自己制定这些规则。实际上，时间管理的安排就是为管理自己的时间而制定的规则。时间管理的基本规则：已经决定如何使用时间，就必须切实的按照预定的方式去做；为了切实按照预定的安排去做，就必须有非常具体的计划。表3.4就是位置到每天活动制定的每天时间安排表。</P>
<P><IMG src="200636142917987.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636142917987.jpg" border=0>&nbsp;</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 设定时间分配的优先级。有些时间是固定不点的，如每周例会，可以把这些时间称为固定时间。进行其他活动的时间就是可变动的时间，只要有时间就可以去做这些活动。可变时间又分成需要完成的任务和自行斟酌的任务。需要的活动如编程、读书，虽然是需要的活动，但它们的时间是可变动的，因为无论如何找出时间都可做这些事情，并且每周在这些活动上所用的时间是不同的。自行斟酌的活动就是要做的所有其他的事情：吃饭、睡觉、社交、观看电视及其其他的娱乐活动。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 当作出全面的时间安排时，固定时间的安排是没有什么问题，最常见的问题是分配可变动的时间。列出需要尽快做的事情，首先努力完成最重要的任务。重要的任务推此时，你会不自觉的为这些任务担心，立刻处理这些事情常常是更有效的，并且也将给人们带来一种完成任务的成就感。此外，记住一旦开始了一项令人生畏的任务，就很少会感到象你想象中的那么困难。</P>
<P>可以考虑从自行斟酌的活动中抽出那些额外的时间，但是这需要合理的安排，对个人是否真愿意按照这时间安排来执行。没有休息的时间会导致人们将管理好时间的想法推翻。做时间安排以及跟踪时间是重要的，但是时间安排一定要是自己实际愿意接受的。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 执行时间安排表。按照时间安排表工作的能力很大程度上取决于个人的自觉性，但是它还取决于要做的工作的数量和它们的优先次序。预料不到的时间是生活中很自然并且是很正常的一部分，特别是在软件工程中。危机常常会打破人们的计划，因此不得不作出调整。</P>
<P>在第一次使用时间安排表时，可能会感到它不是很有用，这是正常的，不要因为第一次没有起作用就放弃对时间安排的过程，而是要考虑所发生的事情，看看是否存在一些不可能再发生的反常时间、或者存在对有正常事件引起人而意外花费了很多时间？如果是紧急的情况，不必对时间安排做大的调整，下一周再试着用它，然后复查结果。如果一些经常发生的事情扰乱了安排，应考虑对安排进行改动，为以后类似事情提前做好准备。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最后，按照时间安排表跟踪实施的性能，要继续收集时间数据。根据经验复查时间安排表，在根据需要和经验修改安排，要逐步的作出改变。在改变时间安排表时，要保存以前的版本。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 时间管理的目标。收集时间是为了帮助自己管理时间。如果收集的数据被证明是没有用的，就需要重新考虑自己收集时间数据的方法。但是，只有在已经实践了安排的时间之后再这样做。记事作了时间安排表，如果由于一些原因对时间安排变化很大，那么也应该收集更多的数据，知道自己明白当前是如何使用时间为止。</P>
<P><STRONG>八、个体软件过程PSP之<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603081721125.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603081721125.html'" tppabs="http://www.itisedu.com/phrase/200603081721125.html" target="_new">缺陷管理</a></STRONG></P>
<P><STRONG>1、什么是缺陷</STRONG></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 缺陷是指程序中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程序语句，是任何影响程序完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 有人把缺陷称为Bug，这是不正确的。当成为Bug时，令人想到的是那些令人讨厌的小虫子，应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事，会养成一种错误的态度。缺陷并不像无足轻重的Bug，更像是定时炸弹。大家可能会觉得有些夸大其词，绝大部分细小的缺陷没有引起严重后果。然而不幸的是，很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题，但很快就会成为一个重要的问题。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 设计错误的复杂性和所导致的缺陷的影响没有之间关系，一些微小的编码错误却可能引起严重的系统问题。事实上，绝大多数<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603111651085.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603111651085.html'" tppabs="http://www.itisedu.com/phrase/200603111651085.html" target="_new">软件缺陷</a>都源于程序员的疏忽大意。</P>
<P>为了减小缺陷，就必须进行缺陷管理，研究已经引入的缺陷，确定引起这些缺陷的原因，并学会在将来如何避免重复同样的错误。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 缺陷分类。在分析缺陷时，将缺陷进行分类是有帮助的。通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上，一旦这几类缺陷得到控制，在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 不要急于把10种类型的每一类细分出若干子类，直到你已经搜集到大量程序的缺陷数据。那时，才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。</P>
<P><IMG src="200636143042844.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636143042844.jpg" border=0></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 统计缺陷个数。采用缺陷记录日志，记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解，但是要管理好缺陷，就必须收集有关缺陷的准确数据。如果原谅缺陷，那只会自欺欺人。如果你这样做的话，就别指望有所提高。</P>
<P><IMG src="200636143129153.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636143129153.jpg" border=0></P>
<P><STRONG>2、缺陷查找技术</STRONG></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 为什么要尽早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程序，经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程序，它将永远是有缺陷的。虽然你可以修复所有已知的问题，并且让它通过所有的测试，但它还是一个有许多不定的有缺陷的程序。如果工程师能宽容有缺陷的工作，他将生产出低质量的产品。“我们忙，以后在修补吧”，这样的态度不可能出产出优质产品。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 发现和修复缺陷的费用。在典型项目中，产品被分成很多小的模块，由不通的工程师负责开发。在模块设计、实现、编译后，工程师作初始的<a href="200602281036115.html" tppabs="http://www.itisedu.com/phrase/200602281036115.html" target="_new">单元测试</a>；单元测试后，多个模块组成一些大<a href="200603302222545.html" tppabs="http://www.itisedu.com/phrase/200603302222545.html" target="_new">组件</a>进行<a href="200603111743305.html" tppabs="http://www.itisedu.com/phrase/200603111743305.html" target="_new">集成测试</a>；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行<a href="200603111950135.html" tppabs="http://www.itisedu.com/phrase/200603111950135.html" target="_new">系统测试</a>。随着系统的规模和复杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同，但几乎所有规模的软件产品，都需要这个过程。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 研究证明，开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍。尽管缺陷的修复时间变化很大，但平均时间总是遵循这样的规律，而与缺陷的类型无关。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 发现和修复缺陷的方法。尽管没有办法不引入缺陷，但是在开发过程中尽早发现和修复缺陷还是可能的。有多种发现程序中的缺陷的方法，基本上都包括以下步骤：表示缺陷征兆；从征兆中推断出缺陷的位置；确定程序中的错误；决定如何修复缺陷；修复缺陷；验证这个修复是否已经解决了这个问题。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 有多种工具和辅助手段来帮助完成这些步骤，工程师最常用的工具是编译器，它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码，并且可能会在源程序有缺陷的情况下生成代码。因此，不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的征兆，你必须自己对问题定位，并确定是什么问题，通常很快能够做到这一点，但偶尔也需要较长的时间</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 另外一种常用方法就是上面讲述的测试。测试的质量是由<a href="200603291707535.html" tppabs="http://www.itisedu.com/phrase/200603291707535.html" target="_new">测试用例</a>覆盖所有程序功能的程度决定的。测试可以用来验证程序几乎所有的功能，但有自己的缺点：同编译器一样只能满足缺陷派出的第一个步骤，你仍必须从缺陷征兆找出问题的根源，然后才能修复；随着项目规模的扩大，全面的测试会花费大量的时间，要进行完全测试几乎不可能的。</P>