小组软件开发过程8.ppt

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,.,*,第八章 产品实现,本章描述了实现过程，我们从讨论设计完成标准、实现标准、实现策略以及复核和检查开始。然后我们依据IMP1和IMPn草案一步步地描述TSPi实现过程。,.,81 设计完成标准,在开始实现之前，检查你是否真正完成了总体设计。对大的系统而言，总体设计常常要求几个阶段。在第一层次，你将系统划分为子系统，部件或模块。你应该采用第七章描述的 DES1或 DESn过程的步骤来做这件工作。最后，你应该对每个子系统、部件或模块加上外部详细说明，还应有为系统所做的最高层次的详细设计。,.,811 设计的层次,如果这些子系统相当大，应对每个子系统或部件重复总体设计过程。而且，你最后应有每个子系统部件的外部规范，还应有为子系统成员所做的最高层次详细设计。依据系统的大小，你可能要反复进行这个过程。最后你会得到关于系统最低层原子模块的外部规范。那时就是你从总体设计进入实现之时。对于真正的大系统，一个连续的系统层次可能是：,.系统，,子系统，,.产品，,部件，,模块。,.,继续这个重复设计过程，直到你得到对系统真正的基本元素的外部规范为止。这些元素小到可以直接实现，而且它们的大小通常为150或更少的LOC。尽管这些模块可能包含更低层的目标或程序，但这些附属的程序不是相当小，就是已被开发，或者是复用部分，或者是可获得的库功能。,达到最低层次的详细说明可能要付出大量的努力，但除非你已经准备好进入实现阶段，你应该继续重复DES1和DESn草案。然而，对于大的系统，你有时必须在结束其它部分的设计之前实现某些产品元素。,.,812 并行的实现,如果有一个足够大的开发小组，你就能在完成部件的外部规范之后，立刻开始实现这些。尽管在你定义好最高层次所有规范之前，开始实现系统的任何部分都是有风险的，但你靠将大系统分割为部件，然后在成员的外部规范完成且检查之后实现它们，这能最小化风险。如果开发周期短这一点很重要，那么这种方式将能节省大量时间。,.,82 实现标准,关于标准的重要性可以谈出相当多的东西，但实际开发和使用标准不应该占大量的时间。在工程初期用少量时间定义标准，以后就能节省大量的时间。首先，当一个小组对需要的标准意见一致后，你就安排一两名小组成员来开发这个草案。然后小组才能有效地讨论该草案，并对他们将使用的具体标准的内容取得一致。质量进度监督经理领导小组的制定这些标准的活动。,实现标准加入并扩宽了设计阶段定义的标准。在外几段我们探讨这些标准问题：,.,标准的复核,.命名、界面和消息标准：,编码标准；,大小标准；,缺陷标推；,预防缺陷。,尽管通常不被认为预防缺陷是一个标准问题，但它与缺陷标准联系紧密，故于此处讨论。,.,821 标准的复核,注意实用性。如果一个被提出的标准看来有用，你就使用它，并在你熟悉它之后改进它。不要尝试第一次就产生一个完美的标准。你会很容易地在讨论抽象的提议时浪费大量时间。如果你以一个合理的草案为起点，并在尝试着使用它们之后更新它们，你将用较少的时间产生较好的标准。,复核在设计阶段完成的命名、界面和信息标准，以确保它们仍是合理的并被合适地使用着。还要检查可复用程序的列表是否完整以及所有小组成员是否正在使用它。,.,下一步，复核命名词汇表来确保每个人都对同样的条款使用了同样的名字，以及整个系统范围的名字都被记录在词汇表中。还要检查部件和子元素名字，并复核被共用的变量、,参数和文件名是否一致。还要检查界面和消息来确保所有系统内外部界面和消息已被定义，被记录在词汇表中，并为所有的小组成员了解和使用。,.,822 编码标准,如果你计划使用你在PSP课程中使用的语言，你可能使用同样的编码标准。但要确认整个小组都同意使用同样的标准。一个共同的编码标准确保小组的所有代码看来都一样。这种一致性将使代码检查更容易迅速且更有效。,一个被精心构造的编码标准还定义了注释约定。好的注释约定可以加快代码的复核，并在以后的开发周期中使升级更容易。一个公共的编码标准还使小组成员间的代码共享更容易。当一个程序看来像你写的代码，并且它使用了同样的惯例和注释约定时，你很可能考虑在你的程序中复用它。这样的复用常常能节省大量的设计和实现时间。,.,823 大小标准,需要一个共同的小组标准。如果你对设计阶段的标准不同意，现在就做一个标准。,除了LOC以外，绝大多数的项目产生几种产品，如SRS和SDS文档即是一例。在TSPi中，我们建议你使用页数来度量文档大小。下面是一些可能需要度量大小的产品元素：,需求文档（SRS）；,总体设计文档（SDS）；,细节设计；,屏幕和报告；,数据库；,信息；,测试草案和测试材料。,.,对于需求，你可以使用文章页数、段落数或“shall”来计数。“shall”定义了计划的产品被要求具有的功能。一个shall说明通常用于代表一个所期望的功能。举例来说，“4M一当某行代码被删除后，在程序中该行被删掉的地方要用注释来保存被删掉的那一行。”,总体设计的最简单度量方式是样板的页数，文本行数或使用场合。对于细节设计而言，伪代码行数是一种度量方式。对于小的程序，我们使用LOC来估计。然后当有了实际的LOC数时，我们使用实际的LOC来度量细节设计产品的大小。,.,8.2.4度量其他类型产品的大小,度量剩余的部分是比较困难的。如果你的小组正在一学期的课程中实现一个相对小的产品，可能除了文本页数和LOC外，你不需要考虑其它任何大小的度量。你应集中精力来建立这个产品。,如果你仍需要附加的度量，请考虑两个问题：第一，时间是否用在了代表整个工程工作的重要部分的产品类型上？如果不是这样，那么工程从度量得到的收益很小或是没有。相关的工程工作可能是如此小以致不能判断有关大小的估计和计划。因为你想要度量大小的主要原因是帮助估计和跟踪工作，当某种产品类型的工作仅是总工作中的一小部分时，你没有必要知道有关大小的估计，仅需要估计你期望这项工作花的时间。,.,假定一种产品类型代表了工作的重要部分，那么你需要一种与开发这个产品所用时间相关的大小度量。如果你能完成那样的一种度量，那么就足够了。如果你不能，你唯一的选择是使用产品元素的数量来作为大小估计。例如对于屏幕，就使用屏幕数及开发一个屏幕的平均经验时间来估计。,对于相当多的数据，你能使用PSP中用于目标LOC上的同样的过程。将这些屏幕数据划分为一些类。在PSP中使用的方法是将数据分成特小（VS），小（S），中（M），大（L），以及特大（VL）这些类别。将你的经验数据划分为这几类，并为每一类产生一个平均开发时间。如果还有很多数据，你可以将这些产品数据再划分一些类型，如数据输入，菜单选择等。,.,然后在计划时，你估计需要多少屏幕，而且判断进入这五个类别的各有多少。对于任何其它的大小度量，你能使用同样的方法。要了解怎样以这种方式估计大小及使用大小数据，请参考软件工程规则。,.,82.5 缺陷标准,标准的PSP缺陷类型对你的需要来说应当是足够了。然而，PSP并没有讨论测试资料的缺陷。,在你创造任何新的缺陷类型之前，请考虑以下几点。第一，存在无穷多种方式来定义缺陷类型。因此，你和你的小组成员可能要花时间来争论你所偏好的类型。,第二，将缺陷归为一些类型的目的是帮助分析、改进开发过程。尽管缺陷类型帮助你将大量的缺陷数据分类，但你一定要仔细检查关于某个特定缺陷的报告来改进过程。做这件事的共同步骤是首先分析你的数据来确认关键的类型。,对单个缺陷类型（例，类80的功能缺陷），在专门的类80缺陷报告中寻找有关细节来看哪种类型导致了大部分的问题。当你确定了一个关键的问题区域（例如，只有一个被遗漏），,.,要确定如何在设计和编码复核中发现这些缺陷。然而，你可能将类80分解成了多个子类，那么做这就是困难的。原因在于你将总有一个其它类别包含了大多数情形。如果你有一个足够好的分解来避免这个问题，你将有一个非常大的缺陷类型列表，而这个列表只能用于研究，毫无实用价值。,.,第三，缺陷类型标准仅当它们很少时才有用。在标准中的类型越多，你在为缺陷选择类型时犯的缺陷就越多，而且分类与记录每个缺陷所花的时间也越多。这说明你仅需要在有足够多的一种新类型的缺陷数据时，才对PSP标准有所添加。,许多人混淆缺陷原因和缺陷类型，他们认为缺陷类型是不完整的需求，贫乏的应用知识，设计的误解或语言上无经验。这些不是缺陷类型，而是缺陷原因。举例来说，绝大多数早期没有纠正的需求缺陷导致了最终产品的功能缺陷。那样的缺陷是在需求分析阶段产生，通常是由没很好定义的需求导致的，但缺陷类型通常是数据（70）、功能（80）或系统（90）。,.,826 预防缺陷,缺陷原因的理解有助于预防缺陷。将缺陷原因分类是困难的。不得不返回去看专门的缺陷报告来理解这些问题，然后找出如何预防它们。此处的困难是普遍性的。为限制原因类型的数目，这些类型必须是非常普通的，但你不能为普通的原因创造出预防措施。,.,建议你从以下四类开始：,教育：学习有关语言、环境和应用的更多知识；,交流：修正这个过程；,事务处理：使用更好的工具；,监督：改善你的过程，使用更好的方法。,.,尽管在缺陷预防上有很多种用来分析缺陷原因的方法，但笔者发现以下方式是最有效的。,选择出那些看来引起绝大多数麻烦的缺陷类型。这些缺陷可能浪费了绝大多数的测试时间，或者是很难诊治和修正的，或者是非常令人厌烦的。,检查这种类型的一些缺陷来确定专门的缺陷原因，并决定哪些原因应被强调。,当你看到一个你认为自己能避免的缺陷时，你要做出一个过程改变来避免它。,假如这种方式是有效的，开始寻找下一个缺陷类别，并以同样的方式处理它。,.,缺陷预防的关键在于寻找可以预防缺陷的改变。然后再在你的过程中将这些改变组合起来。下一步，跟踪执行来看这个变化是怎样起作用的。如果这些缺陷类型仍存在，找出先前的变化不起作用的原因，然后再一次进行调整。,当你知道了缺陷的原因时，在LOGD表的注释里记上它。但如果你以同样的标准混淆了缺陷类型和缺陷原因，你的数据将是无用的。原因在于同样的缺陷类型可能出现在几个不同的地方，这使你不能靠频率来排列缺陷类型。,.,83 实现策略,实现策略通常应和设计策略保持一致，也就是说，你应与设计它们的方式保持一致地实现程序。为避免实现和测试的问题，我建议你考虑以下三个论题：,.复核；,.复用：,测试。,.,831 实现策略：复核,在设计时，应从大局入手逐渐深入到细节。但在复核时，应考虑从细节入手逐渐拓宽到大局。笔者发现的最有效的策略是从底部开始复核。首先，复核所有没有从属部分的最低层次的对象。当你确信这些原子对象是按照它们的外部说明一致时，进入下一个高一级的层次。然后，当你在下一个高一级的层次复核碰到这些对象时，你能信任它们，并且不必去再一次复核它们。,为遵循从底部入手策略，实现同样首先应从最低层次的对象做起，然后逐渐移向高一点的层次。这通常是确认最低层次对象规范中的问题的最快方式。靠早点发现这些详细说明中的问题，你能在它们被广泛实现前修正它们。这项工作还能节省大量的测试和返工时间。因为最低层的原子对象最容易被复用，故一个从底部入手的实现策略也使复用更方便。,.,832 实现策略：复用,靠遵循一些简单的实现惯例，你能使程序的复用更容易。举例来说，对每个源程序采用标准注释题头。这个题头应集中提供所有重要的使用信息，帮助潜在的用户快速了解这个程序是干什么的。用户部分在程序名和标识块之下立即接着的源码清单的顶部开始。在用户部分，简要地描述（以语言和公式）这个程序做什么，详细说明调用和返回格式，命名所有的变量和参数以及确定变量的范围、类型和格式，还要描述其它条件和警告，诸如变量值的限制，溢出条件以及精度限制。应用黑体大写字母（BOLD CAPITAL）列出所有这样的限制以免它们被遗漏。,靠在每天简短的小组会议上讨论实现计划，你能提高复用。在讨论中，检查复用库，问其它人是否有你正需要的复用对象或倒行程序。你还要观察你正在开发的对象中是否有一些可为其它人所用。如果有，将它们命名，并让产品支持经理将其加到复用部分清单，并附带上它们的功能规范。每天用几分钟来做这，你能节省大量的实现时间。,.,833 实现策略：测试,在开发策略中应着重关注的一点是可测试性。故在实现之前，复核开发策略以确信程序实现的顺序是与你的测试计划一致的。,.,84 复核和检查,841 随机缺陷,许多实现缺陷是由于按键的随机缺陷导致的简单打字错误。每一干LOC中按键导致了28个错误。而且这些错误与程序的逻辑是无关的。,因为这些按键的随机缺陷没有逻辑性，。故它们随机散布在你的程序中。这些数目令人吃惊的错误产生了对编程语言的规则无效的代码。因此，这些类似造句的错误，编辑器无法发现。C十编辑器只能发现造句和类似于造句的错误的94。在编辑之后，你的程序里，每一千LOC大约有2 到 3个随机的按键错误。,.,842 对测试的影响,对于一两百LOC的程序，这些数目的随机缺陷似乎不重要。即使对于5000 LOC的小系统，也仅对逻辑缺陷和编码缺陷只添加了10到15个缺陷。但在测试时发现这些缺陷是非常困难的。,在一个由有经验的工程师开发的4000 LOC程序里，系统测试要用去两个月时间，因为在系统测试中要发现并改正38个缺陷。另一个使用PSP和TSP开发的8000 LOC的商业程序，它仅有一个缺陷，系统测试需要一个星期。,随机缺陷的发现是困难的，原因在于测试仅用于发现由专门测试环境碰到的缺陷。因此，为保证找出所有的随机缺陷，你必须要运用所有的程序逻辑路径，用所有可能的数据和操作环境来测试。,.,8.4.3 详尽测试的困难,为广泛地测试59LOC程序需要67种测试环境，368条逻辑路径，以及65536个数值而这些仅是为了 59 LOC。,尽管有人可能争辩这些联合中的许多在逻辑上是不可能的 但随机缺陷产生的问题是导致了程序的无逻辑性。将它放到一边，假如我们犯了一个逻辑错误，编程将会更简单而且测试能够更有效。但对于一个中等复杂的程序用少量测试发现一个随机缺陷的可能性是非常小的。这就是复核重要的原因之所在、取代看单个值和一条逻辑路径一个复核者能同时为程序的逻辑部分考虑所有的路径和数据。,这就是复核比测试更有效的原因 也是复核者更可能发现由工程师们导致的缺陷的原因、但为了组织有效的复核你应使用个人代码复核清单井在每次程序开发和检查之后使用它更新清单。,.,8.4.4 对源程序的设计检查,当对源程序复核和检查时 发现一个复杂的设计缺陷是困难的、因为那时不仅有更多的文件，而且你很能陷入编码细节从而失去了对设计的观察。为了制作出高质量的程序你必须制作出精确完整的设计文档，然后复核、检查，井在开始编码之前修正它们、在你做完这些工作后，在实现阶段没有必要再次复核设计，除非你修改过设计。如果程序设计还没有被复核，你必须在实现时检查它、附寻C中有关于检查方法的更多讨论。,.,8.5 IMP 草案,.,8.5.1 开始条件,为满足IMP1的开始条件，你必须有：,一个完整的开发策略和计划；,.完整的，被复核过的，及更新了的SRS和SDS规范：,一个定义好且被制做成文档的编码标准,程序功能详细说明清单、命名词汇表和小组采用的其它标准的可获得的副本。,如果你没有这些条目 立刻停下来弥补所缺的。对于IMPn，开始条件仅要求有更新的策略和计划，更新的SRS和SDS规范以及命名词汇表和小组标准的最新版本。,.,.,852 实现计划,实现计划的第一步是复核所有将要做的工作并确信将所有任务分配给小组成员设计某个模块或例程的工程师可能对实现它更熟悉。但是因为一些工程师比另外一些人更擅长于实现，故不同的分配是有意义的一种解决方法是让一些工程师关注于设计，而另一些工程师关注子实现、因为一些工程师可能更擅长于特定部件功能的实现即使他们 没有设计它们。让他们实现它们也是个不错的主意。在分配任务时关键是考虑工程师们的兴趣和能力如果有必要，让小组领导人来帮助小组分配任务。,在分配完这些任务之后。每个工程师计划他自己的实现工作。对于那些预期几个小时可完成的任务，简单的时间估计就足够对诸如实现一个程序对象或模块之类的大一些的工作，你应使用SUMP和SUMQ表格做一个类似PSP的简单计划。对于大量的非编程任务，使用SUMTASK表格来估计划,.,8.5.3 详细设计和设计复核,在此时，你准备为你计划要实现的程序模块开发详细设计虽然此时有几种方式进行，但许多工程师发现在开始下一个程序的详细设计之前对一个程序进行从详细设计到单元测试是最有效的但在许多情形中，几个程序设计是如此紧密相关以致它们应同时设计不管怎样，你应由专门的情形引导。遵循对你的情形合适的设计策略。,下一步是指导对每个模块成对象的个人设计复核。在复核中，不仅要用检查清单来细察设计，还要用可追踪表或状态机分析来检查循环和所有复杂的逻辑。,.,85.4 测试的开发,在修正了复核中发现的问日之后，开发一些特殊的单元测试代码和设施因为在测试开发时道常比设计复核或单元测试时能发现更多的设计问题，故在检查细节设计之前进行测试的开发是很重要的。测试开发工作应遵循测试计划，而且应包括所有的逻辑决策、逻辑路径、以及循环上进和终止年件的检查、它应检验所有的变量和参数的名义值、上下界、以及其它一些限制最后，确认在所有预期的错误 下程序都能适当地进行反应。特别是，无论在何处需要人的行为，都要在那几测试可能的类型错误。,.,8.55 详细设计的捡查,在测试开发之后，让质量/进度监督经理带领你和一两名小组成员来进行详细设计的检查。如果小组的生产超过70%是一致的，那么你仅需要一名工程师来检查设计，尽管那样简单的检查不需要质量生产经理参与，但你应将检查数据记入INS表格中，并将主要缺陷记入你的LOGD中，还要将几份完整的INS表格交给质量l生产经理和小组领导人，以使其包括于工程笔记本中。,.,无论你怎样进行检查，要确信对于程序的每个循环或者状态机结构，至少有一名工程师完成了一个跟踪表，一个执行表，以及状态机制分析。做这个工作的一种方式是与检查小组见面，并决定对设计的每一部分由谁来进行哪种分析，如果你决定做同一代码段的状态机分析和可跟踪表分析，让两名不同的工程师来进行分析。这种方法最大化了发现问题的可能性。,.,856 编码和代码复核,在细节设计的检查之后，对模块进行编码。然后在你自己复核它之前，查看你的缺陷史，判断你可能在编码中引入了多少缺陷。一种方法是列出你每小时编码可能引入的缺陷数量。还要确定对每一千LOC你所引人的缺陷数量，当你了解了你的历史上最大和最小的缺陷率之后，你能对程序中缺陷数量的范围有个好的估测。然后在编码复核中将目标定为发现这样数目的缺陷。,.,为引导代码复核，设立一个时间目标也是一个不错的主意。笔者建议你至少用50（最好是70）时间来编程。因为源程序的阅读要用比这更少的时间，直到用完所有的计划时间之前，保持查看程序。取代每次以同样的方式看代码，应每一次寻找不同的东西。某次检查名宇一致性，然后检查初始化，标点，赋值和等式，然后是检查指针，调用顺序，以及包含。,那儿有很多东西要寻找。你要确信正使用你的检查清单来作向导。如果你正在发现缺陷，即使用了比计划更多的时间，也要继续进行下去。如果在复核中不能发现足够的缺陷，在编译代码之前请求其它工程师复核你的代码。然后编译程序。,.,.,857 代码检查,在编译之后，将你的设计，设计复核，代码和代码复核时间与小组质量计划比较。你还要检察缺陷的层次与缺陷率。如果你的数据指示你碰到了问题，或者如果你不知道这些数据意味着什么，和质量/进度监督经理一起复核你的结果。判断程序质量是否相当好的一种方式是使用表58中给出的质量标准。,用于设计的时间应比编码时间长。,用于复核设计的时间应比设计时间长50。,用于复核代码的时间应比编码时间长50，最好是长75。,你在复核编码时发现的缺陷至少应是编译时发现缺陷的两倍；,每复核一个小时，你要发现3个以上的缺陷；,你的复核速率应小于每小时 200 Loc。,.,在质量检查之后，使用质量评估结果来导引编码的检查，如果你的程序质量好而且如果你与复核者的工作大约70重合，那么就要求质量/进度监督经理使用两个或更多的复核者来检查。程序质量越差，重复越低，越需要更多的复核者。,.,如果程序有质量问题，在你改正这些已知的缺陷之前，让一到两名工程师做其它的复核。使用一些还没复核过这个程序，而且你们还没告诉它发现了哪些缺陷的工程师。当复核结束后，检查他们的复核数据，再估计重合。但是，如果他们发现了许多没有人能预先发现的缺陷，就要以同样的方式来再进行一次复核。持续进行这种方式的复核，直到每个缺陷至少被两名工程师发现或者直到你没有可用的复核者为止。,.,858 单元测试,在检查完代码之后，下一步是进行单元测试。请使用已开发好的测试材料，遵循细节,设计时准备的测试计划。,.,8.59 部件质量复核,在编码检查和单元测试之后，让质量/进度监督经理复核这些部件数据来确定部件质量是否好到可包含进基准系统里。在这里的标准即是在质量计划阶段小组所建立的标准。正如在表83中的SUMQ表格样本，这些数据包含了缺陷的层次，缺陷比率，过程的时间以及时间比率。如果一个部件在任何一方面有质量问题，那么小组应该讨论这个情况，并决定要做什么。无论如何要选择是将这个部件置入基准，还是做更多的设计，或者做更多的代码复核和检查，或者在集成之前让其它工程师返工这个部件。,.,尽管再复核和返工要用几个小时的工程时间，但它们通常要为小组节省几天的集成和系统测试时间。在图8.1中列出了对这些决策所建议采用的标准。在第二区域，要再一次检查程序的设计，让复核者使用跟踪表或执行表仔细检查程序的设计。同样，如果程序有多个状态，复核者还应进行状态机分析。除了让每个工程师按这种方式检查整个程序，还要让每个复核者选出一或几个程序段来仔细检查。,在区域III，指导另外一组遵循以前描述的步骤再做一次详细的代码检查。在区域IV，让一名工程师返工整个程序。这包括从头书写看起来有问题、松散的代码。,.,部件质量复核的目标是，确信程序的每个逻辑段用执行表或追踪表至少分析过一次。而且，对每个有状态行为的程序段，确保用状态机分析至少检查过一次。当程序的逻辑特别复杂，或程序有许多缺陷时，让两名或者更多的工程师来进行同样的检查。并且，进行同样程序的不同分析时，使用不同的工程师。,尽管图81对4个区域都给出了完整的标准，但请记住，这仅是建议，当程序有越来越多的编译和单元测试缺陷时。你预料它们有越来越多未发现的缺陷。靠看部件代码和过程数据，你能感觉到程序是否有严重的质量问题。在这种复核中，使用图81中的区域来帮助你判断。,.,8510 部件的放行,完成的部件通过了质量复核之后，将它交给技术支持经理以记入系统基准。,.,8.511 结束标准,在完成实现阶段时，你必须有：,完整的，被复核和检察过的部件；,记入了配置管理系统的部件；,为设计检查，代码检查以及再检查而完成的INS和LOGD表格；,系统和它的所有部件部分更新的SUMP，SUMQ和SUMS表格；,单元测试计划和支持材料；,大小，时间和缺陷数据；,更新的工程笔记本。,.,