小组软件开发过程7.ppt

1、第七章 小组设计,在TSPi中: 设计阶段关注系统的总体结构。这个阶段制作出软件设计说明书（SDS），它将较高层次的设计形成了文档。 下一个层次的设计或详细设计则在实现阶段提出。,第七章 小组设计,本章内容： 设计的原则 以小组为单位的设计 设计的标准 设计的复用性 设计的可用性 设计的可测性 设计的复核和检查 TSPi设计草案,第七章 小组设计,设计过程的主要目标是为产品实现生成一个准确、完整、高质量的基础。 当一个人制作一个设计时，他（或她）要做完所有的工作。在一个小组里，靠把产品分割成一些部分，让每个小组成员设计和实现一些部分，你能工作得更快。但这种方法要求一些总体设计，这些总体设计不是

2、清楚准确的，没有仔细考虑过，那么系统的各个部分将不会和谐地工作。这正是许多项目在集成和系统测试阶段耗费大量时间的原因之所在。这些时间大部分是用来发现和修正总体设计的问题的，而这些问题应在设计阶段就被解决掉。,7.1 设计的原则,设计应该生成一个关于产品如何被建立的完整、准确的说明。 一个完整的设计定义了产品的主要部分，描述这些部分如何交互工作，还详细描述它们如何装配到一起来产生最终结果。,7.1 设计的原则,设计总体设计、细节设计 .总体设计与细节设计和实现的差别仅在于范围和细节。 例如，在总体设计层次，你将产品分割成一些可独立设计和实现的部分。因此总体设计必须生成一个说明，以便工程师们在独立

3、设计过程中能使用它。,7.1 设计的原则,当设计模糊或不准确时，工程师们在细节设计时要浪费时间来填充总体说明的不足。当问题出现时，每个工程师要独立地解决这些问题，而他们各自的决定是否一致，我们不能确切地知道。这种情况常常导致这样的结果：直到集成测试和系统测试阶段才察觉各部分不兼容。错误的设计不仅导致了时间的浪费，还引起严重的进程延迟。,7.1 设计的原则,当总设计准确完整时，工程师能很快制作出各个部份的细节设计。为达到这一点，他们需要知道每个部件、它们的界面以及状态行为的完整的功能的规格说明。然后，为了制作出最终产品，实现工程师们需要一个细节设计，它为每个程序定义了逻辑结构、所有循环初始化和步

4、进条件、细化的状态结构以及状态转换。 随后，实现工程师们生产实现设计的代码。他们的目标是源代码能够正确地执行所有被详细描述的功能，能适当地使用所有的系统设备，能结合可获得的重使用功能，而且遵循编码和系统的标准与习惯。最终完成的产品应该是一个编译和运行都没有任何错误或问题的源程序。,7.2 小组设计,当你独自设计一个产品时，你的主要问题是： 如何生成一个设计 以何顺序来设计产品的不同部分。 但当你在一个小组中工作时，你还面临另外三个问题： 各部分应由谁来设计？ 他们应该以何顺序来进行这项工作？ 这些部分如何组合到一起？,7.2 小组设计,7.2.1 使用整个小组 设计大的软件系统中的一个共同难题

5、是：在你进行任何事情之前，需要定义系统的总体结构。但在结构被设置好之前，划分工作是困难的。 处理这个难题的一种方法是整个小组一起致力于总体结构设计。 另一种方法是，当一或两名工程师定义结构和足够详细（即每个部件的设计都被完整地详细说明）地描述系统部件时，确定小组其人能干的任务。,7.2 小组设计,让整个小组一起致力于总体设计浪费了大量的时间。 通常只需要一两名工程师来将总体设计形成文档，详细描述界面，在部件中间分配系统功能，以及定义程序总体结构和逻辑。 对于类似于TSPi中通常开发的系统一样的小系统，总体设计工作可能不会用去太长时间。 对于大的产品，通常每个人都被要等到总体设计工作完成。一种选

6、择是确定工程师能做的其它任务。有三类这样的工作：设计研究，标准开发和重使用。,7.2 小组设计,7.2.2 设计研究 为指导有用的设计研究，开始你必须对可能的产品部件和它们的功能有个初步的想法。 当系统设计者正在制作外部部份说明时，其它工程师能思考设计部份的一些其它方式,他们甚至可能建立起原型。 早一点建立一个界面原型。,7.2 小组设计,7.2.3 使用整个小组的才智 在小组设计中另一个问题是所有成员想法的有效使用。小组的主要好处在于他们潜在的强有力的技巧和知识。在合作中最重要的问题是让所有成员都充分地贡献。当人们工作于小组中时，他们有时不愿说出或提出建议和想法。这个问题在软件小组中特别重要

7、，因为主要的设计决定必须在工程早期形成，可那时小组刚组建，工程师们还互相不了解。而这正是小组成员最不愿说话的时候。,7.2 小组设计,7.2.3 使用整个小组的才智 所有的小组成员都应该意识到这个问题，都应该认识到小组有广泛的经验和知识。每个人都应该贡献，无论他们是否认为自己具有专业的知识和经验。主持小组会议和讨论的任何人都应该坚持不去问：某人是否对正讨论的论题有更深远的想法或相关的知识。这样就可以充分利用小组的贡献。这样做的小组通常工作更有效率。,7.3 设计的标准,几种重要的设计标准： 命名约定。应详细陈述命名结构并让产品支持经理建立一个系统词汇表。 界面格式。定义部件界面的内容和格式。

8、系统消息和错误消息。要为系统消息和错误消息建立标准的格式和程序。 缺陷标准。建议你采用PSP缺陷的类型标准。 LOC的计算。在开始设计之前，你需要意见一致的LOC的计算。 设计表示的标准。设计表示的标准定义了设计工作的产品。,7.3 设计的标准,7.3.1 设计表示的标准 你需要准确地把每一个设计做成文档。 无论你是使用PSP设计样板还是其它方法,你的设计是完整准确的才是最重要的。 节省了实现时间 产生了一个在实现前可检验的可复核设计。,7.3 设计的标准,7.3.2 使用情形或PSP操作脚本 靠描述一系列的输入活动以及系统对每个输入活动的反应，脚本描述了程序的外部动态可视行为。菜单选择行为和

9、对错误输入的正确程序活动即为范例。 脚本帮助你考虑程序将怎样使用。在产生脚本时，你常常发现细微的设计或可用性问题。 脚本还能用于定义测试条件。在总体设计期间，生成了一个脚本，这个脚本要对程序的每一个关键功能详细说明其测试顺序。 当制作集成测试和系统测试计划时，你要使用这个脚本。 部件层次的测试脚本也能暴露界面问题、功能问题和可用性问题。,7.3 设计的标准,7.3.3状态机分析 无论你采用什么设计方法，状态机分析能有助于你发现复杂的、难以发觉的逻辑问题。 当你对程序行为感到怀疑时，最好做一个状态机分析。状态分析是真实了解程序如何工作的唯一方式。 在程序经过几个开发周期的升级后，程序状态行为变得

10、复杂。为确保升级没有引入不可能的或自相矛盾的条件，定义和分析程序状态机行为是种好的想法。,7.3 设计的标准,7.3.4 生成准确的设计 尽管生成一个准确的设计要花去相当数量的时间，但这样的设计会节省更多的实现和测试时间。 有一个完整定义的设计，你能快速地理解非常复杂的程序行为。 在小组工程中准确设计是特别重要的，因为肤浅的设计常存在单个工程师独自一人所看不出的基本逻辑问题。这些问题通常在测试阶段很难诊断，以致有时不得不对实现的主要部分进行返工来改正它。,7.4 设计的复用,在总体设计阶段，有效利用小组时间的一种方式是定义小组的复用标准。这项工作包括确定可能的公共功能，以及提出可复用部分的一个

11、初始集。 对于小的TSPi产品，我们在设计阶段引入复用。对更大一点的项目，你可以在需求和策略开发期间开始考虑复用。 设计的复用的主要问题是定义标准界面和调用约定，建立文档标准，产生高质量的产品，以及提供应用支持。,7.4 设计的复用,7.4.1 复用界面标准 在复用中的一个关键问题是使成份便于使用。做这的最好方式是定义自包含、独立的可复用功能。为了一致地做这，你需要比较设计的一种方式。在TSPi中建议的标准是看那种设计有低的耦合、高的内聚。,7.4 设计的复用,7.4.1 复用界面标准 最重要的复用标准之一是调用-返回界面。如果可能，使这些标准类似于你正开发的产品中使用的标准。这个工作节省了标

12、准定义的工作，消除了一个混乱的来源，还减少了错误。 伴随产品界面标准，要详细说明那些参数是作为变量来使用，那些参数是为了返回，那些参数是针对特殊消息和错误条件。你还要定义标准的错误消息和条件以及对错误条件反应的标准方式。最后，你要为变量和参数及可重用部分设立命名约定。,7.4 设计的复用,7.4.1 复用界面标准 当为单个工程开发可重用部分时，你能利用公共体系结构框架和唯一的系统标准集。框架和标准的结合使得在工程师中共享成份更容易，而且它增加了你确认公共部份和程序的能力。,7.4 设计的复用,7.4.2 复用文档标准 文档标准是可复用部分与不可复用部分的区别之所在。 当某一部分的功能没有被很好

13、地制做成文档，可能的用户必须寻找源代码来确定它是如何工作的。因为寻找要花费时间，绝大多数的工程师都把复用限制在他们个人书写和理解的程序上。 当工程师们不必看源代码就理解如何使用可复用程序时，小组复用就被最大化了。 这要求可复用部分列表包含每个部分的外部行为的完整的详细说明。在每个可复用部分的源程序的顶部有一个如何使用的注释段落，是一个好主意。,7.4 设计的复用,7.4.3 复用部分的质量 高质量是复用策略的要素。 为达到部分的高质量： 应充分地使用己定义的过程，指导个人复核，仔细检查设计和代码。在PSP中，这通常需要PSP2.1或PSP3.0个人过程。 运行通过单元测试来确保程序是适合于所有

14、的变量和参数值的。这包括对名义值，上下界和界外的测试。这个部分同样应该用清楚标明错误输入或错误条件的错误消息来设计。,7.4 设计的复用,在决定复用一个己有的程序时,你应考虑下列问题。 程序有适合的功能？ 程序界面是适合于新的应用？ 程序性能是适合于新的应用? 所有需要的资料，如源代码，测试情况，测试数据和应用说明，是否可以得到？ 程序是否生成了合适的标准，诸如语言水平，编码标准，命名标准和文件标准，以及消息标准和帮助标准？ 程序是否有可论证的高质量?,7.4 设计的复用,7.4.4 应用支持 为最大程度复用，应使工程师们容易发现可用部分以及了解如何使用它们。 最好有一个包含每个部分功能的清楚

15、的详细说明的部分索引。 当你开始程序的设计或实现时，尽可能复用可得到的部件。一个小组做这个工作是靠每天召开一个简单的会议，来复核设计者的正在开发的功能，更新可复用功能的列表。,7.4 设计的复用,7.4.4 应用支持 在TSPi中，产品支持经理是复用的提倡者： 要为支持可复用部分和保持对它们的完整记录承担责任。这就为小组寻找帮助提供了一个中心点。 产品支持经理还要在总体设计中和设计及代码检查期间使小组注意力保持在复用上，帮助小组确认可能的可复用部分以及确保可复用部分被广泛使用。,7.5 可用性设计,使产品可用的一种方式是为每一个关键的用户功能制作脚本，确信它们反映了用户所想要的那种系统。 当你

16、不清楚功能如何工作时，应和应用专家复核相关脚本或者建立和示范一个简单的原型。 如果你能得到有效的原型化工具，将所有的用户界面原型化并示范，这通常是个不错的主意。,7.6 可测性设计,详细的单元测试需要专门的测试代码提供一个合适的测试环境。你应尝试制作一个需要尽量少的测试代码的设计。 进行一个详细的测试计划工作也是重要的。当小组正计划集成测试和系统测试时，他们通常在测试的计划期间比实际测试期间发现更多的错误。完整的计划和广泛的脚本集能加速测试的计划工作，改进测试的效率。,7.6 可测性设计,黑箱测试和白箱测试。都是十分有用的，都应该被使用。 在系统层次的黑箱测试不要求专门的准备，因为这些测试类似

17、于用户使用产品的方式。另一方面，单个模块和部件的黑箱测试通常需要一些界面驱动程序和专门的支持程序来提供模拟的系统环境。但靠以适当的顺序开发部件，你能使这种专门的驱动程序的需要降至最少。 白箱测试在设计期间需要一些思考。在此处，困难在于提供测试程序结构的每个方面的能力。通常，一般目的测试工具能有助于做这个工作，但专门开发的测试代码或专一的测试设施同样也需要。再者，你要考虑你的设计和开发策略怎样能使专门测试代码的需要最小化。,7.7 设计的复核和检查,对一个有效的设计检查，你首先需要的是完全文档化的设计。 当你正进行个人设计复核或者为设计的检查做准备时，你一定要做一个详尽的设计分析。仅仅看一个设计

18、不能发问题。应检查每一个设计要素以确保它适当地工作。例如，检查界面，检查循环的初始化、步进和终止。以及分析状态行为。,7.8 TSPi设计草案,7.8.1 开始标准,7.8 TSPi设计草案,7.8 TSPi设计草案,7.8.2 总体设计 以如下步骤产生一个总体设计；决定总体产品结构，命名产品部件，将产品功能分配给部件，制件部件的外部说明，分配使用情形功能（casefunction）给这些部件，以及确定要完成的设计任务。 7.8.3 设计标准 质量（或过程）经理带领小组生成设计标准和命名词汇表。,7.8 TSPi设计草案,7.8.4 总体产品结构 你的小组要对总体结构、总件名称、在部件中分配产

19、品取得一致意见。 为了把品功能分配给不同的部件，使用类似于定义策略时使用的一个可跟踪表。你还要考虑对每个开发周期你将在何时何处进行升级；尽管在概念设计阶段你已经完成了第一次分配，但现在你需要考虑其它可选择的方式，并确定你的设计是合理的。,7.8 TSPi设计草案,7.8.5 设计任务的分配 开发经理领导小组安排SDS文档的设计，确定制件这个文档所需的工作，然后把这些工作分为几个部分。随后，在小组领导人的帮助下，小组把这些部分分配给小组成员，并得到他们何时完成各自的部分的承诺。,7.8.6 设计详细说明 当你正在制作SDS时，要为每个部件定义外部界面和功能规范。作为SDS的一部分，产生一个包含所有部件外部功能的脚本的全集。但要注意，每个脚本可能包含了几个功能。总体设计的最后一步是制作出不同的设计文档，这些文档详细说明了主要系统结