小组软件开发过程7

《小组软件开发过程7》由会员分享，可在线阅读，更多相关《小组软件开发过程7（43页珍藏版）》请在金锄头文库上搜索。

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

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

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

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

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

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

7、作于小组中时，他们有时不愿 说出或提出建议和想法。这个问题在软件小组中特 别重要，因为主要的设计决定必须在工程早期形成 ，可那时小组刚组建，工程师们还互相不了解。而 这正是小组成员最不愿说话的时候。7.2 小组设计n7.2.3 使用整个小组的才智n所有的小组成员都应该意识到这个问题，都应该认 识到小组有广泛的经验和知识。每个人都应该贡献 ，无论他们是否认为自己具有专业的知识和经验。 主持小组会议和讨论的任何人都应该坚持不去问： 某人是否对正讨论的论题有更深远的想法或相关的 知识。这样就可以充分利用小组的贡献。这样做的 小组通常工作更有效率。7.3 设计的标准n几种重要的设计标准：n命名约定。应

8、详细陈述命名结构并让产品支持经理建立 一个系统词汇表。n界面格式。定义部件界面的内容和格式。n系统消息和错误消息。要为系统消息和错误消息建立标 准的格式和程序。n缺陷标准。建议你采用PSP缺陷的类型标准。nLOC的计算。在开始设计之前，你需要意见一致的LOC的 计算。n设计表示的标准。设计表示的标准定义了设计工作的产 品。7.3 设计的标准n7.3.1 设计表示的标准n你需要准确地把每一个设计做成文档。n无论你是使用PSP设计样板还是其它方法,你的设 计是完整准确的才是最重要的。n节省了实现时间n产生了一个在实现前可检验的可复核设计。 7.3 设计的标准n7.3.2 使用情形或PSP操作脚本n

9、靠描述一系列的输入活动以及系统对每个输入活动的反 应，脚本描述了程序的外部动态可视行为。菜单选择行 为和对错误输入的正确程序活动即为范例。n脚本帮助你考虑程序将怎样使用。在产生脚本时，你常常发 现细微的设计或可用性问题。n脚本还能用于定义测试条件。在总体设计期间，生成了一个 脚本，这个脚本要对程序的每一个关键功能详细说明其测试 顺序。n当制作集成测试和系统测试计划时，你要使用这个脚本。n部件层次的测试脚本也能暴露界面问题、功能问题和可用性 问题。7.3 设计的标准n7.3.3状态机分析n无论你采用什么设计方法，状态机分析能有助于 你发现复杂的、难以发觉的逻辑问题。n当你对程序行为感到怀疑时，最

10、好做一个状态机 分析。状态分析是真实了解程序如何工作的唯一 方式。n在程序经过几个开发周期的升级后，程序状态行 为变得复杂。为确保升级没有引入不可能的或自 相矛盾的条件，定义和分析程序状态机行为是种 好的想法。7.3 设计的标准n7.3.4 生成准确的设计n尽管生成一个准确的设计要花去相当数量的时间 ，但这样的设计会节省更多的实现和测试时间。n有一个完整定义的设计，你能快速地理解非常复 杂的程序行为。n在小组工程中准确设计是特别重要的，因为肤浅 的设计常存在单个工程师独自一人所看不出的基 本逻辑问题。这些问题通常在测试阶段很难诊断 ，以致有时不得不对实现的主要部分进行返工来 改正它。7.4 设

11、计的复用n在总体设计阶段，有效利用小组时间的一种方式是定 义小组的复用标准。这项工作包括确定可能的公共功 能，以及提出可复用部分的一个初始集。n对于小的TSPi产品，我们在设计阶段引入复用。对更 大一点的项目，你可以在需求和策略开发期间开始考 虑复用。n设计的复用的主要问题是定义标准界面和调用约定， 建立文档标准，产生高质量的产品，以及提供应用支 持。 7.4 设计的复用n7.4.1 复用界面标准n在复用中的一个关键问题是使成份便于使用。 做这的最好方式是定义自包含、独立的可复用 功能。为了一致地做这，你需要比较设计的一 种方式。在TSPi中建议的标准是看那种设计有 低的耦合、高的内聚。7.4

12、 设计的复用n7.4.1 复用界面标准n最重要的复用标准之一是调用-返回界面。如果可能 ，使这些标准类似于你正开发的产品中使用的标准。 这个工作节省了标准定义的工作，消除了一个混乱的 来源，还减少了错误。n伴随产品界面标准，要详细说明那些参数是作为变量 来使用，那些参数是为了返回，那些参数是针对特殊 消息和错误条件。你还要定义标准的错误消息和条件 以及对错误条件反应的标准方式。最后，你要为变量 和参数及可重用部分设立命名约定。7.4 设计的复用n7.4.1 复用界面标准n当为单 个工程开发可重用部分时，你能利用 公共体系结构框架和唯一的系统标 准集。框 架和标准的结合使得在工程师中共享成份更

13、容易，而且它增加了你确认公共部份和程序的 能力。7.4 设计的复用n7.4.2 复用文档标准n文档标准是可复用部分与不可复用部分的区别之所在。n当某一部分的功能没有被很好地制做成文档，可能的用户必 须寻找源代码来确定它是如何工作的。因为寻找要花费时间 ，绝大多数的工程师都把复用限制在他们个人书写和理解的 程序上。n当工程师们不必看源代码就理解如何使用可复用程序时，小 组复用就被最大化了。n这要求可复用部分列表包含每个部分的外部行为的完整的详 细说明。在每个可复用部分的源程序的顶部有一个如何使用 的注释段落，是一个好主意。7.4 设计的复用n7.4.3 复用部分的质量n高质量是复用策略的要素。n

14、为达到部分的高质量：n应充分地使用己定义的过程，指导个人复核，仔细检查设 计和代码。在PSP中，这通常需要PSP2.1或PSP3.0个人过程 。n运行通过单元测试来确保程序是适合于所有的变量和参数 值的。这包括对名义值，上下界和界外的测试。这个部分 同样应该用清楚标明错误输入或错误条件的错误消息来设 计。7.4 设计的复用n在决定复用一个己有的程序时,你应考虑下列问题。n程序有适合的功能？n程序界面是适合于新的应用？n程序性能是适合于新的应用?n所有需要的资料，如源代码，测试情况，测试数据和 应用说明，是否可以得到？n程序是否生成了合适的标准，诸如语言水平，编码标 准，命名标准和文件标准，以及

15、消息标准和帮助标准 ？n程序是否有可论证的高质量?7.4 设计的复用n7.4.4 应用支持n为最大程度复用，应使工程师们容易发现可用 部分以及了解如何使用它们。n最好有一个包含每个部分功能的清楚的详细说 明的部分索引。n当你开始程序的设计或实现时，尽可能复用可 得到的部件。一个小组做这个工作是靠每天召 开一个简单的会议，来复核设计者的正在开发 的功能，更新可复用功能的列表。7.4 设计的复用n7.4.4 应用支持n在TSPi中，产品支持经理是复用的提倡者：n要为支持可复用部分和保持对它们的完整记录 承担责任。这就为小组寻找帮助提供了一个中 心点。n产品支持经理还要在总体设计中和设计及代码 检查

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