- 1、本文档共4页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
工作分解结构在软件开发中的应用 一、概述
通过对项目管理的系统学习,我个人对于工作分解结构在软件中的应用有很深的感触,对于工作分解结构在软件开发中的应用有一些个人的看法和见解。
首先我们看一下项目分解结构的定义,工作分解结构是进行范围规划时所使用的重要工具和技术之一,是面向可交付成果的对项目元素的分组,它组织并定义了整个项目范围,未列入工作分解结构的工作将排除在项目范围之外。它是项目团队在项目期间要完成或生产出的最终细目的等级树,所有这些细目的完成或产出构成了整个项目的工作范围。
从项目分解结构的定义和我们的学习我们知道,项目分解结构主要针对的是可交付物以及工作细分。同时通过学习我们知道,项目分解结构产生于项目计划阶段过程,在项目执行过程的控制中对项目进行考核和控制,最后在项目结束阶段为整个项目的考核提供参考。但是,我个人认为,如果从软件开发的角度来看的话,项目分解结构这个工具在需求定义期间也能起到很好的应用,也是非常有意义的,我将会再下面的示例中进行阐述。下面结合实际工作案例对项目分解结构在软件开发项目中的应用作一个简单的描述。
二、软件项目存在的普遍性问题
1、工作范围界定
首先我们来看一下什么是软件开发,说白了,软件开发其实就是让电脑在我们设定好路线上行走的一个实现过程。而人的思维是逻辑的、发散性的,电脑的思维是单一的、指令性的。就此而言,在电脑软件的实现过程中需要对人的思维和操作方式进行整理,形成一个符合电脑工作的一个流程,在这中间就涉及到了工作范围界定,和各种信息的综合筛选。
2、工作量估算
通过几个软件项目的完工,我又这样的一个感触,一个软件项目如果完成时间超过预计时间15%以下就算是一个很不错完成时间。从我接触的几个项目上来看,最长的一个项目甚至延期了将近半年的时间,而最初的预期开发时间只有三个月。从后来对项目最终评估结果看来,除了由于客户的一些行政和人事原因引起的延时,很大一部分原因还是因为对项目的工作量把握不够,在一些关键的模块上产生了很严重的超时。
3、需求难以明确
在软件项目启动阶段,不管是甲方还是乙方,对于软件的估算都是不足的,项目的需求都有一个从模糊到清除的过程,在项目启动阶段,总是需求最模糊的一个阶段,而这个阶段却是项目的一个重要阶段,明确地需求直接关系到开发的成本和报价,怎样与客户通过沟通得到较为一致且明确地需求就显得非常重要。
4、软件开发过程控制
在软件开发过程中,沟通和交流的直接明了非常重要,通畅准确的沟通可以很好的提高开发效率和明确的得到最终交付物,但是如果光靠通过口头交流来说的话容易产生一定的偏差,通过文字来交流话又不是很直观。难以满足对项目及时调整、管理、甚至决策的需要。
从以上的各个问题来说,事实上我们需要的是一个统一的、规范的沟通标准,利用此标准可以是项目的各个参与方进行有效的信息沟通,同时可以确保业余与项目管理方获得准确实时的项目信息,以便高校的对整个项目的进度、成本、质量进行统一的计划和控制。
三、工作分解结构的具体应用
在这里我简单的描述一下项目,该项目是针对电力行业的一个MIS项目,在项目的执行过程中我们事实上没有完全按照项目管理的规范来做,但是,在项目的各个环节中我们都很多的用到了工作分解结构这样的一个工具,在这里我们分阶段进行应用阐述。
1、启动阶段
项目在最初定义阶段,不管是客户还是软件开发人员,对于系统的了解总是基于大模块的,而对于模块的局部结构的了即就比较模糊了,在需求定义和明确的过程中,首先通过软件人员的头脑风暴形成一个最初的软件分解结构,然后以此为基础与客户进行沟通就比较直观明了,便于客户形成直观的概念。但是,在这个阶段里面,项目里面的很多内容往往是不清晰和不确定的,在这里我们就可以很好的利用项目分解结构这个工具来进行有效的沟通。
我们可以从以下的三个图来说明这种情况,这几个图是在对MIS项目就行需求分析时产生的。首先图一表示的是通过开发人员的最初调研形成的组织分解结构图,然后在此基础上,通过与客户的交流发现MIS结构的模块分布式是上并不是原想的组织结构。我们了解到,电管站的电费最终也是收入到营销部,从电费归属的意义上来说的话,电管站最终也归营销部管理,所以我们对组织结构图进行了再一次的整合和修改。形成了第二个组织结构图,在大的模块的到确认的前提下,对其中的各个模块进行进一步的细分,对各个模块以最终可交付物为单位形成各个模块的细分结构,如图三,其他模块省略。这样就同时对软件开发人员和系统使用人员都形成了一个直观可行的模块印象。
在这里我们可以看出,在需求定义阶段,项目分级结构可以作为一个很好的客户与调研人员沟通的手段,可以更好的对项目的构建形成一个统一的认识,同时界定出项目的模块范围
文档评论(0)