IP101-05软件项目任务分解

1、北方民族大学北方民族大学 计算机科学与工程学院计算机科学与工程学院 陶铮陶铮 2009年年9月月 1 课件IP101 引言：回顾 采购计划、计划合同制定、询价、选择卖方、 合同管理、合同收尾。 2 合同管理的基础是WBS 活动，是软件生命周期规定的过程中的活动； 任务，是活动内细分的一个个工作单元。 产品，任务完成的标志性成果。 3 4 项目初期的工作场景 5 本章内容 6 7 WBS （Work Breakdown Structure） 1.对项目任务由粗到细进行分解，每细分一个层次，表 示对项目工作元素更细致的描述； 2.任务分解的描述形式，一般采用一个分级的树型结构； 任务分解结构的最低

2、层，是任务完成的可交付成果 （也叫做的工作包）。 3.所有被分解出来的工作包的集合，应该符合合同范围 规定的交付物，没有纳入WBS结构里的工作被认为不在 项目的范围之内。 4.交付成果也可以分配给另外一位项目经理进行计划和 执行，也可以通过子项目的方式完成。 8 将问题进行分解，直到分解后的子问题容易解决， 然后分别解决这些子问题。 规划项目时，也应该从任务分解开始，将一个项目 分解为更多的工作细目或者子项目，使项目变得更 小、更易管理、更易操作。 9 基本设计原则 只有能够实现的设计才是可接受的设计 在约束条件下，满足更多风险承担者的需要和 要求的设计更好 能够以更少的资金、更短的时间、更低

3、的风险 构建出来的设计更好 使程序更易于修改的设计更好 10 提高估算成本、时间和资源的准确性，使工作 变得更易操作，责任分工更加明确。 任务分解是对需求的进一步细化，是最后确定 项目所有任务范围的过程。 新的知识点：软件估算知识将在后面介绍。 11 12 进行任务分解时，可以采用清单或者图表的形式表 达任务分解的结果 5.2.1 清单类型 将任务分解的结果以清单的表述形式进行层层分 解的方式。 项目的名字定义为“变化计数器”，它是统计程 序大小的软件工具 当修改一个程序的时候，这个工具可以统计各个 版本之间有多少代码行被增加、删除或修改。 采用清单方式进行任务分解如下： 13 1.1.1 预

4、处理 1.1.2 文件比较 1.1.3 结果处理 1.2.1 找出增加的代码行 1.2.2 找出删除的代码行 1.3.1 统计增加代码行数 1.3.2 统计删除代码行数 14 5.2.2 图表类型 以上面的“变化计数器”为例，分解结果如图5.3所示。 15 图图5-3 “变化计数器变化计数器”的图表分解的图表分解 注意：不要箭头注意：不要箭头 需 求 分需 求 分 析析 内容需求与栏目组织内容需求与栏目组织 表现需求与发布需求表现需求与发布需求 需求评审需求评审 规 划 设规 划 设 计计 功能需求功能需求 人机交互需求人机交互需求 创意设计创意设计 安全需求安全需求 设计评审设计评审 开 发

5、 整开 发 整 合合 系统设计系统设计 模板设计与制作模板设计与制作 数据迁移（旧数据迁移（旧新）新） 页面设计与制作页面设计与制作 功能设计与实现功能设计与实现 资源整合资源整合+内容管理系统导入内容管理系统导入 阶段成果审查阶段成果审查 测 试 发测 试 发 布布 页面测试页面测试 导航测试导航测试 功能测试功能测试 性能测试性能测试 后台管理测试后台管理测试 系统部署与交付系统部署与交付 发布前审核发布前审核 管 理 维管 理 维 护护 制定运维计划制定运维计划+人员培训人员培训 制定网站业务流程制定网站业务流程 建立运维机制（组织建立运维机制（组织+制度）制度） 运维费用管理运维费用管

6、理 16 细化后的任务分解图细化后的任务分解图 5.3 任务分解的过程 1.1.合同及其附件规定的任务及合同及其附件规定的任务及需求分析初步结果， 项目相关的要求，如软件生存期阶段选择等）软件生存期阶段选择等） 2.2.概要设计方案，人员、时间等资源的信息概要设计方案，人员、时间等资源的信息 3.以往的项目分解结果（参照用） 17 图图5.4任务分解的基本过程任务分解的基本过程 WBS示例，图5.5是有些软件企业进行项目分解的WBS 模板。 18 图图5.5一个一个WBS模板模板 制作WBS时已实施内容 5.3.1 基本步骤 5.3.2 分解的标准 5.3.3 分解结果的检验 19 5.3.1

7、 基本步骤 1.确认并分解项目的主要组成要素； 2.确定分解标准，按照选定的项目实施方法进行 分解（分解中可按实际需要回调实施方法）； 3.确认分解是否详细，分解结果是否可以作为费 用和时间估计的标准，明确责任； 4.确定项目交付成果，交付成果是有衡量标准的， 以此检查交付结果； 5.验证分解正确性，验证分解正确后，建立一套 任务编码体系。 20 5.3.2 分解的标准 以项目选定的软件生存期阶段为标准（简称按阶 段组织）； 以合同规定的功能/产品组成为标准（简称按功能 组织，或按产品组织）； 对于较大项目、多部门实施的，以项目的组织单 位为标准（简称按部门组织）。 21 例如，教材中的图5-

8、3“变化计数器” 这是一个统计程序规模的软件工具。项目的任务分 解，采用了“功能组成标准”对任务进行了分解。 22 5.3.3 分解结果的检验 1.较低层次的分解是否必要和充分？ 如果不必要或者不充分，这个组成要素就必须重新如果不必要或者不充分，这个组成要素就必须重新 修正（增加细目、减少细目或修改细目）。修正（增加细目、减少细目或修改细目）。 2.最底层要素是否有重复？ 关键在于名称的区别，有重复的就应重新分解关键在于名称的区别，有重复的就应重新分解/命名。命名。 3.所有的细目的名称是否有明确、完整的定义？ 4.所有细目是否能够估算？是否有人能够担负完成 该任务的责任？ 如果没有，就必须修

9、正（合并、撤销、修改）。如果没有，就必须修正（合并、撤销、修改）。 23 24 示例：网站的产品构成 作业 25 作业 26 注意：理想的网站设计所要考虑的 因素是很多的。 27 28 进行任务分解注意事项（简化版）： 1.任务分解的规模和数量因项目而异。 2.注意收集与项目相关的所有信息。 3.先分大块任务，然后再细分小的任务，最低层 是可控的和可管理的，避免不必要的过细，最 好不要超过7层。（一般5层为好） 4.按照软件项目的平均规模来说，推荐任务分解 时至少拆分到一周的工作量（40小时）。 5.每个工作包至少有一个提交物定义任务完 成的标准。 6.任务分解结果必须有利于责任分配。 29

10、30 根据对项目的需求规格分析，采用图表方式进 行任务分解，分解结果如图5.7所示（下页图）； 该WBS是按照功能组成标准进行任务分解的，其 中没有包括管理、质量等相关的任务，WBS可以 随着系统的完善而不断增加和完善。 31 32 图图5.7 校务通管理系统校务通管理系统的任务分解的任务分解 案例分析 一、标的技术的内容、范围及要求中的“3. 具体需求见SOW” 注：注：SOW，即工作任务说明，即工作任务说明（Statement of Work）；）； 33 第3章案例说明（摘要，整理） 针对项目开发特点，参考企业的生存期模型说明和软件 过程体系，决定采用增量式模型（见图3.13）。 1）校

11、务通系统的全部功能分成通用功能和日常业务管理功 能两大类 2）先基于通用功能做出一个最小的使用版本（即最初的产 品集），然后再逐步添加其余的功能。 3）开发中，让用户先试用最小版本，由此期待用户提出更 多的、明确的需求，这有助于下一阶段的开发，大大减 小了开发的风险。 34 注意：WBS的设计，依赖于软件开 发过程模型 35 最终的产品最终的产品 范围范围 图图3.13的增量式模型的增量式模型 案例分析（回答） 这是因为，在需求不明的、且预期功能增加、结构调整的可 能性很大的情况下（同时，企业尚没有过该项目的体系结构 设计的经历和成果），故意对高层做出简单分解，以便留有 余地。 这样，既能够满

12、足用户的阶段性需求，又可以为自己的后续 开发流出结构空间。 36 37 图图5.7 校务通管理系统校务通管理系统的任务分解的任务分解上半部上半部 38 39 WBS的由来工业工程理念 针的制造过程把铁拉成线条状，然后切成很多 段，把每段的一端磨尖，另一端钻上孔，等等 与“一个人做一根针”相比，效率如何？ 预想该系统的设计过程将非常复杂，因而整个设计 过程按计划被分解成一系列准独立的子系统模 块。 注意：每个模块的设计必须遵照某些共同的规则， 以保证这些模块能够构成一个和谐、完整的系统 40 模块化设计思想：集中式“自上而下” 可以从多个模块中选择最好的设计来构成系统。 甚至，一旦确立了设计规则

13、，各模块化设计小组可 以不必整合成一个组织。 41 模块究竟是什么？ 42 模块性原则模块性原则 该问题变成：“小型模块具有多少个直接部件？” 在过程编程中（如C语言），有一个约定是子程序不能超 过60行代码（该规则显然与代码清单的打印载体的大小 有关一页打印纸可以打印的行数为60行）。 另一个约定是编译单元不超过500行代码。符合这些限制 的模块就是小型模块。 43 模块划分的一个经验法则 分解后得到的模块数=72，即59项。 建议，类应当有7 （2）个公有操作，或者函 数应当被分为不超过7 （2） 个子函数。 44 结构设计的原则是必须有效和分等级，结构设计的原则是必须有效和分等级， 但不

14、必在结构内建太多的层次，因为层但不必在结构内建太多的层次，因为层 次太多了不易有效管理。次太多了不易有效管理。 45 面向对象设计面向对象设计 46 参考资料：参考资料： 代码大全（第二版）代码大全（第二版） 1.软件系统软件系统 2.分解为子系统和包分解为子系统和包 3.分解为包中的类分解为包中的类 4.分解为类中的数据和子程序分解为类中的数据和子程序 5.子程序内部子程序内部 1.明确软件系统名称、作用、范围、功能 （列表） 2.将软件系统分解为子系统和包子系统的名 称、作用、范围、包的构成和功能（列表） 3.对包进行分解，得到类的列表和关系图 4.对类进行分解，设计每个类中的数据结构和子

15、 程序 5.对子程序（方法）再分解，得到程序内部结构 47 48 系统 子系统-1 类1-1 数据 方法方法 类1-2类1-3类1-4 子系统-2子系统-3 类3-1 子系统-4 就是整个系统。就是整个系统。 有的程序员直接从系统层次就开始设计类有的程序员直接从系统层次就开始设计类很危险！很危险！ 从子系统或者包这些类的更高组织层次来思考才是正确的。从子系统或者包这些类的更高组织层次来思考才是正确的。 识别出所有的主要子系统识别出所有的主要子系统确定如何把程序分为主要的子确定如何把程序分为主要的子 系统，并定义清楚允许各子系统如何使用其他子系统系统，并定义清楚允许各子系统如何使用其他子系统 这

16、些子系统可能会很大，如数据库、用户界面、业务规则、这些子系统可能会很大，如数据库、用户界面、业务规则、 命令解释器、报表引擎等。命令解释器、报表引擎等。 注意：不要让注意：不要让所有的所有的子系统都能同其他子系统通信，否则你子系统都能同其他子系统通信，否则你 就完全失去了把它们分开所带来的好处。就完全失去了把它们分开所带来的好处。 50 例如，有六个子 系统的系统示例 当子系统之间的 通信没有任何限 制时就会像这个 样子 施加若干通信规则后，子系统之间的交互得以显 著地简化 业务规则业务规则指那些在计算机系统中编入的法律、规则、政策指那些在计算机系统中编入的法律、规则、政策 以及过程。以及过程

17、。 用户界面用户界面应创建一个子系统，把用户界面组件同其他部分应创建一个子系统，把用户界面组件同其他部分 隔离开，以便使用户界面的演化不会破坏程序的其余部分。隔离开，以便使用户界面的演化不会破坏程序的其余部分。 如如MVCMVC设计模式设计模式 在大多数情况下，用户界面子系统会使用多个附属的子系统或类来在大多数情况下，用户界面子系统会使用多个附属的子系统或类来 处理用户界面、命令行接口、菜单操作、窗体管理、帮助系统，等处理用户界面、命令行接口、菜单操作、窗体管理、帮助系统，等 等。等。 数据库访问数据库访问把对数据库进行访问的实现细节隐藏起来，让把对数据库进行访问的实现细节隐藏起来，让 程序的

18、绝大部分可以不必关心处理底层结构的繁琐细节，并能程序的绝大部分可以不必关心处理底层结构的繁琐细节，并能 像在业务层次一样处理数据。像在业务层次一样处理数据。 识别出系统中所有的类。例如，数据库接口子系统识别出系统中所有的类。例如，数据库接口子系统 可能会被进一步划分成数据访问类、持久化框架类可能会被进一步划分成数据访问类、持久化框架类 以及数据库元数据。以及数据库元数据。 当定义子系统中的类时，也就同时定义了这些类与当定义子系统中的类时，也就同时定义了这些类与 系统的其余部分打交道的细节。尤其是要确定好类系统的其余部分打交道的细节。尤其是要确定好类 的接口。的接口。 总的来说，这一层的主要设计任务是把所有的子系总的来说，这一层的主要设计任务是把所有的子系 统进行适当的分解，并确保分