小组软件开发过程7.ppt

第七章 小组设计 在TSPi中: 设计阶段关注系统的总体结构。这个阶段制作出软件设计说明书（SDS），它将较高层次的设计形成了文档。 下一个层次的设计或详细设计则在实现阶段提出。 第七章 小组设计 本章内容： 设计的原则 以小组为单位的设计 设计的标准 设计的复用性 设计的可用性 设计的可测性 设计的复核和检查 TSPi设计草案 第七章 小组设计 设计过程的主要目标是为产品实现生成一个准确、完整、高质量的基础。 当一个人制作一个设计时，他（或她）要做完所有的工作。在一个小组里，靠把产品分割成一些部分，让每个小组成员设计和实现一些部分，你能工作得更快。但这种方法要求一些总体设计，这些总体设计不是清楚准确的，没有仔细考虑过，那么系统的各个部分将不会和谐地工作。这正是许多项目在集成和系统测试阶段耗费大量时间的原因之所在。这些时间大部分是用来发现和修正总体设计的问题的，而这些问题应在设计阶段就被解决掉。 7.1 设计的原则 设计应该生成一个关于产品如何被建立的完整、准确的说明。 一个完整的设计定义了产品的主要部分，描述这些部分如何交互工作，还详细描述它们如何装配到一起来产生最终结果。 7.1 设计的原则 设计——总体设计、细节设计 .总体设计与细节设计和实现的差别仅在于范围和细节。 例如，在总体设计层次，你将产品分割成一些可独立设计和实现的部分。因此总体设计必须生成一个说明，以便工程师们在独立设计过程中能使用它。 7.1 设计的原则 当设计模糊或不准确时，工程师们在细节设计时要浪费时间来填充总体说明的不足。当问题出现时，每个工程师要独立地解决这些问题，而他们各自的决定是否一致，我们不能确切地知道。这种情况常常导致这样的结果：直到集成测试和系统测试阶段才察觉各部分不兼容。错误的设计不仅导致了时间的浪费，还引起严重的进程延迟。 7.1 设计的原则 当总设计准确完整时，工程师能很快制作出各个部份的细节设计。为达到这一点，他们需要知道每个部件、它们的界面以及状态行为的完整的功能的规格说明。然后，为了制作出最终产品，实现工程师们需要一个细节设计，它为每个程序定义了逻辑结构、所有循环初始化和步进条件、细化的状态结构以及状态转换。 随后，实现工程师们生产实现设计的代码。他们的目标是源代码能够正确地执行所有被详细描述的功能，能适当地使用所有的系统设备，能结合可获得的重使用功能，而且遵循编码和系统的标准与习惯。最终完成的产品应该是一个编译和运行都没有任何错误或问题的源程序。 7.2 小组设计 当你独自设计一个产品时，你的主要问题是： 如何生成一个设计 以何顺序来设计产品的不同部分。 但当你在一个小组中工作时，你还面临另外三个问题： 各部分应由谁来设计？ 他们应该以何顺序来进行这项工作？ 这些部分如何组合到一起？ 7.2 小组设计 7.2.1 使用整个小组 设计大的软件系统中的一个共同难题是：在你进行任何事情之前，需要定义系统的总体结构。但在结构被设置好之前，划分工作是困难的。 处理这个难题的一种方法是整个小组一起致力于总体结构设计。 另一种方法是，当一或两名工程师定义结构和足够详细（即每个部件的设计都被完整地详细说明）地描述系统部件时，确定小组其人能干的任务。 7.2 小组设计 让整个小组一起致力于总体设计——浪费了大量的时间。 通常只需要一两名工程师来将总体设计形成文档，详细描述界面，在部件中间分配系统功能，以及定义程序总体结构和逻辑。 对于类似于TSPi中通常开发的系统一样的小系统，总体设计工作可能不会用去太长时间。 对于大的产品，通常每个人都被要等到总体设计工作完成。一种选择是确定工程师能做的其它任务。有三类这样的工作：设计研究，标准开发和重使用。 7.2 小组设计 7.2.2 设计研究 为指导有用的设计研究，开始你必须对可能的产品部件和它们的功能有个初步的想法。 当系统设计者正在制作外部部份说明时，其它工程师能思考设计部份的一些其它方式,他们甚至可能建立起原型。 早一点建立一个界面原型。 7.2 小组设计 7.2.3 使用整个小组的才智 在小组设计中另一个问题是所有成员想法的有效使用。小组的主要好处在于他们潜在的强有力的技巧和知识。在合作中最重要的问题是让所有成员都充分地贡献。当人们工作于小组中时，他们有时不愿说出或提出建议和想法。这个问题在软件小组中特别重要，因为主要的设计决定必须在工程早期形成，可那时小组刚组建，工程师们还互相不了解。而这正是小组成员最不愿说话的时候。 7.2 小组设计 7.2.3 使用整个小组的才智 所有的小组成员都应该意识到这个问题，都应该认识到小组有广泛的经验和知识。每个人都应该贡献，无论他们是否认为自己具有专业的知识和经验。主持小组会议和讨论的任何人都应该坚持不去问：