SP20105软件项目任务分解.ppt

上述图形告诉我们，面向对象的软件开发，任务分解过程如下： 明确软件系统——名称、作用、范围、功能（列表） 将软件系统分解为子系统和包——子系统的名称、作用、范围、包的构成和功能（列表） 对包进行分解，得到类的列表和关系图 至此，完成初步的WBS，下面是程序员的事了 对类进行分解，设计每个类中的数据结构和子程序 对子程序（方法）再分解，得到程序内部结构 * 面向对象的WBS * 层1 层2 层3 第1 层：软件系统 就是整个系统。 有的程序员直接从系统层次就开始设计类——很危险！ 从子系统或者包这些类的更高组织层次来思考才是正确的。 第2 层：分解为子系统或包 识别出所有的主要子系统——确定如何把程序分为主要的子系统，并定义清楚允许各子系统如何使用其他子系统 这些子系统可能会很大，如数据库、用户界面、业务规则、命令解释器、报表引擎等。 注意：不要让所有的子系统都能同其他子系统通信，否则你就完全失去了把它们分开所带来的好处。 * 例如，有六个子系统的系统示例 当子系统之间的通信没有任何限制时就会像这个样子 施加若干通信规则后，子系统之间的交互得以显著地简化 常用的子系统——可以在不同的系统中反复出现。 业务规则——指那些在计算机系统中编入的法律、规则、政策以及过程。 用户界面——应创建一个子系统，把用户界面组件同其他部分隔离开，以便使用户界面的演化不会破坏程序的其余部分。——如MVC设计模式 在大多数情况下，用户界面子系统会使用多个附属的子系统或类来处理用户界面、命令行接口、菜单操作、窗体管理、帮助系统，等等。 数据库访问——把对数据库进行访问的实现细节隐藏起来，让程序的绝大部分可以不必关心处理底层结构的繁琐细节，并能像在业务层次一样处理数据。 第3 层：分解为类 识别出系统中所有的类。例如，数据库接口子系统可能会被进一步划分成数据访问类、持久化框架类以及数据库元数据。 当定义子系统中的类时，也就同时定义了这些类与系统的其余部分打交道的细节。尤其是要确定好类的接口。 总的来说，这一层的主要设计任务是把所有的子系统进行适当的分解，并确保分解出的细节都恰到好处，能够用单个的类实现。 第4 层：分解成子程序 把每个类细分为子程序。在第3 层中定义出的类接口已经定义了其中一些子程序，而第4 层的设计将细化出类的私用（private）子程序。 完整地定义出类内部的子程序，常常会有助于更好地理解类的接口，反过来有助于对类的接口进行进一步修改，也就是说再次返回第3 层的设计。 注意： 这一层次的分解和设计通常是留给程序员个人来完成的，程序员必须在设计和编程之中（最迟是之后），必需把设计的结果用文档描述出来，不能停留在头脑中。 第5 层：子程序内部的设计 为每个子程序布置详细的功能。 编写伪代码、选择算法、组织子程序内部的代码块，以及用编程语言编写代码。 这一层的设计工作必须以文档（流程图+列表+算法描述）描述出来. 有时是经过深思熟虑而出色完成的。 * * * * * 注意-1：在项目管理活动中，所有参与项目的有关单位和人员，都要有以一个共同的信息结构为基础，这就是WBS。 注意-2：WBS结构是以等级状或树状来构成的——底层是管理项目所需的最低层次的信息，可以满足用户对交流或监控的需要，也是项目经理、软件工程技术管理项目所要求的最低水平。 任务分解的过程 5.3.1 基本步骤 5.3.2 分解的标准 5.3.3 分解结果的检验 * 5.3.1 基本步骤 分解意味着分割主要工作细目，使它们变成更小、更易操作的要素。基本步骤如下： 确认并分解项目的主要组成要素； 确定分解标准，按照选定的项目实施方法进行分解（分解中可按实际需要回调实施方法）； 确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任； 确定项目交付成果，交付成果是有衡量标准的，以此检查交付结果； 验证分解正确性，验证分解正确后，建立一套任务编码体系。 * 5.3.2 分解的标准 任务分解的高层，应该采用一种标准。WBS的高层可选标准： 以项目选定的软件生存期阶段为标准（简称按阶段组织）； 以项目范围说明书规定的功能/产品组成为标准（简称按功能组织，或按产品组织）； 对于较大项目、多部门实施的，以项目的组织单位为标准（简称按部门组织）。 * 例如，教材中的图5-3“变化计数器”这是一个统计程序规模的软件工具。项目的任务分解，采用了“功能组成标准”对任务进行了分解。 * 5.3.3 分解结果的检验 任务分解后，何如判断WBS的正确性？主要是检查： 较低层次的分解是否必要和充分？ ——如果不必要或者不充分，这个组成要素就必须重新修正（增加细目、减少细目或修改细目）。 最底层要素是否有重复？ ——关键在于名称的区别，有重复的