IP101-05软件项目任务分解.ppt

施加若干通信规则后，子系统之间的交互得以显著地简化 常用的子系统——可以在不同的系统中反复出现。 业务规则——指那些在计算机系统中编入的法律、规则、政策以及过程。 用户界面——应创建一个子系统，把用户界面组件同其他部分隔离开，以便使用户界面的演化不会破坏程序的其余部分。——如MVC设计模式 在大多数情况下，用户界面子系统会使用多个附属的子系统或类来处理用户界面、命令行接口、菜单操作、窗体管理、帮助系统，等等。 数据库访问——把对数据库进行访问的实现细节隐藏起来，让程序的绝大部分可以不必关心处理底层结构的繁琐细节，并能像在业务层次一样处理数据。 第3 层：分解为类 识别出系统中所有的类。例如，数据库接口子系统可能会被进一步划分成数据访问类、持久化框架类以及数据库元数据。 当定义子系统中的类时，也就同时定义了这些类与系统的其余部分打交道的细节。尤其是要确定好类的接口。 总的来说，这一层的主要设计任务是把所有的子系统进行适当的分解，并确保分解出的细节都恰到好处，能够用单个的类实现。 第4 层：分解成子程序 把每个类细分为子程序。在第3 层中定义出的类接口已经定义了其中一些子程序，而第4 层的设计将细化出类的私用（private）子程序。 完整地定义出类内部的子程序，常常会有助于更好地理解类的接口，反过来有助于对类的接口进行进一步修改，也就是说再次返回第3 层的设计。 注意： 这一层次的分解和设计通常是留给程序员个人来完成的，程序员必须在设计和编程之中（最迟是之后），必需把设计的结果用文档描述出来，不能停留在头脑中。 第5 层：子程序内部的设计 为每个子程序布置详细的功能。 编写伪代码、选择算法、组织子程序内部的代码块，以及用编程语言编写代码。 这一层的设计工作必须以文档（流程图+列表+算法描述）描述出来. 有时是经过深思熟虑而出色完成的。 * * * 5.3.1 基本步骤 分解意味着分割主要工作细目，使它们变成更小、更易操作的要素。基本步骤如下： 确认并分解项目的主要组成要素； 确定分解标准，按照选定的项目实施方法进行分解（分解中可按实际需要回调实施方法）； 确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任； 确定项目交付成果，交付成果是有衡量标准的，以此检查交付结果； 验证分解正确性，验证分解正确后，建立一套任务编码体系。 * 5.3.2 分解的标准 任务分解的高层，应该采用一种标准。WBS的高层可选标准： 以项目选定的软件生存期阶段为标准（简称按阶段组织）； 以合同规定的功能/产品组成为标准（简称按功能组织，或按产品组织）； 对于较大项目、多部门实施的，以项目的组织单位为标准（简称按部门组织）。 * 例如，教材中的图5-3“变化计数器”这是一个统计程序规模的软件工具。项目的任务分解，采用了“功能组成标准”对任务进行了分解。 * 5.3.3 分解结果的检验 任务分解后，何如判断WBS的正确性？主要是检查： 较低层次的分解是否必要和充分？ ——如果不必要或者不充分，这个组成要素就必须重新修正（增加细目、减少细目或修改细目）。 最底层要素是否有重复？ ——关键在于名称的区别，有重复的就应重新分解/命名。 所有的细目的名称是否有明确、完整的定义？ 所有细目是否能够估算？是否有人能够担负完成该任务的责任？ ——如果没有，就必须修正（合并、撤销、修改）。 * * 示例：网站的产品构成 作业 网站项目的WBS——第一层是按照什么标准设计的？第二层及其以下是按照什么标准设计的？——产品 * 作业 网站项目的WBS——第一层是按照什么标准设计的？第二层及其以下是按照什么标准设计的？——阶段 * 注意：理想的网站设计所要考虑的因素是很多的。 * * 进行任务分解注意事项（简化版）： 任务分解的规模和数量因项目而异。 注意收集与项目相关的所有信息。 先分大块任务，然后再细分小的任务，最低层是可控的和可管理的，避免不必要的过细，最好不要超过7层。（一般5层为好） 按照软件项目的平均规模来说，推荐任务分解时至少拆分到一周的工作量（40小时）。 每个工作包至少有一个提交物——定义任务完成的标准。 任务分解结果必须有利于责任分配。 * * 《校务通管理系统》的任务分解： 根据对项目的需求规格分析，采用图表方式进行任务分解，分解结果如图5.7所示（下页图）； 该WBS是按照功能组成标准进行任务分解的，其中没有包括管理、质量等相关的任务，WBS可以随着系统的完善而不断增加和完善。 * * 图5.7 《校务通管理系统》的任务分解 案例分析 确定WBS，用到了“合同”内容——合同内容见第2章的“案例说明”，即： 《一、标的技术的内容、范围及要求》中的“3.具体需求见SOW” ——注：SOW，即工作任务说明（St