IP10105软件项目任务分解.ppt

  1. 1、本文档共56页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
IP10105软件项目任务分解

施加若干通信规则后,子系统之间的交互得以显著地简化 常用的子系统——可以在不同的系统中反复出现。 业务规则——指那些在计算机系统中编入的法律、规则、政策以及过程。 用户界面——应创建一个子系统,把用户界面组件同其他部分隔离开,以便使用户界面的演化不会破坏程序的其余部分。——如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

文档评论(0)

seunk + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档