您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
   
 订阅
  捐助
项目集和项目估算- RDP-GJB5000A
 
   次浏览      
 2019-7-25  
 
编辑推荐:
本文来自于csdn, 什么是项目项目集,项目集进度及一些经验。接着讲解了如何进行软件项目估算?

什么是项目集,协助项目集管理从理论走向现实

相信很多人对项目管理已经有相对比较深入的理解,且实际运用到日常科研创新项目的管理中;但提起项目集管理,估计大部分就会有点茫然了,什么是项目集?如何有效管理?

其实,什么是项目集,业界相对通俗易懂的解释如下:

项目集常有多个相关联(注:这是要点)的项目组合而成,最容易让我们联想起的首推美国太空总署的“阿波罗探月计划”,它组合多个阿波罗太空任务,让人类登上月球。从今天PMI项目集的定义来说,阿波罗探月计划应该称为“阿波罗探月项目集”。项目集与项目的最大差异是“项目集”必须透过一些相关的项目交付物提交项目集的最终成果(注:这是重点)。

总结一下,个人认为项目集具备如下2特征:

涵盖多个项目;

项目集中的项目是关联的,进度是协同的;

具体到科研创新管理,我们经常会把复杂的产品开发划分为相对独立的单元,每个单元有相应团队负责,而每个相对独立单元的研制就是可以作为一个项目,而这些项目的汇总就是项目集;

为什么要划分多个项目,按照项目集来管理,实际项目集有哪些形态?

适应部门壁垒的现状;很多科研机构,科室与科室之间的部门墙还是比较厚的,短时间打破部门墙,构建跨部门的项目团队,对,就是华为IPD的那一套,从而对项目端到端的整体负责,还是一种理想状态,理想丰满,而现实骨感,所以拆分为小项目,划分到具体科室,由科室主任对应负责,也不失为一个好的办法,这样就形成了多个项目,而这些项目的汇总就是项目集。

技术开发与产品开发相分离;这个是第3代研发管理的核心要素,而技术开发是一个项目,负责把货架技术搞定;产品开发是一个项目,负责将成熟的货架技术组装为产品,这两个项目是相互独立,又相互关联的关系,这就是项目集。

产品相互直接有共享的物理模块;公司同时有3个机器人开发项目,而每个机器人都需要机器人手臂,如果三个项目都独立设计自己的机器人手臂,就太Low了,资源、成本都是极大的浪费,所以会把机器人手臂的设计落实到一个项目中,并且要求他们设计时要同时兼顾三个项目的需求,这样通过机器人手臂就把三个项目关联在一起了,手臂进度延期三个项目都受影响,而这三个项目就需要统一协调管理,这就是项目集。

基于本人实际项目集管理经验,认为项目集管理需要重点关注如下4点:

1.项目集中的各个项目的进度要协同一致;

2.项目之间的权限要融合一体,主项目要能对辅助项目进行有效管控;

3.项目集中各个项目的交付要能统一汇总;

4.项目集中的项目变更要协同一致,通知相关变更影响方;

RDP-GJB5000A军工科研GJB5000A解决方案,在项目集信息化管理方面进行了一些有价值的探索,现无偿分享给广大科研创新从业者,希望对大家有帮助。

首先,RDP-GJB5000A理解的项目集生命周期模型,如下图:

其次,RDP-GJB5000A通过项目集进度总览图,实现项目进度协同一致,如下图:

第三,RDP-GJB5000A汇总各个项目的交付到一起,并能统一打包审核发布,如下图:

最后,项目集中任何项目的变更都会自动分析变更的关联影响,并决定是否允许变更,如何变更,如下图:

这就是我们对项目集管理的探索成果

如何进行软件项目估算?

针对软件如何估算?业界专家提出比较多的方法,比较常见的有类比法、德尔菲专家估算法、功能点估算法,其中功能点估算要求非常精细,已经渗透到设计层级,针对项目初始估算,功能点估算就有比较大的局限性,因为项目这时还没有那么多细节信息来支撑进行功能点估算;针对这些估算的操作方法业界已经有很多相应书籍和案例供学习,本文就不再赘述,本文重点讲解一下如何借助信息化手段,提升估算效率,将估算成为项目运作的重要一环,整体项目估算过程如下:

首先,实际业界项目团队通常以需求或模块为估算对象,个人认为需求和功能点有相通之处,需求再细化就可以到功能点层级;模块是大家非常熟悉的对象,例如用户管理模块、权限管理模块、账单管理模块等;估算专家正式估算前,为了提升估算的效率,需要提供相应的历史经验参考,例如历史某个物理模块实际有多少行代码,历史某个需求特性实现时用了多少行代码等;每个专家进行估算时,需要充分考虑复用率系数,通过历史代码复用可以有效节约项目资源投入,如下:

考虑到不同软件项目生命周期的生产率(LOC/人天)不同,所以软件项目生命周期模型选择不同、软件技术难度系数不同,会导致同样规模的软件项目需要投入的工作量(人天不同),如下:

最后,结合所选择软件项目生命周期模型,基于模型定义,我们就可以知道这些工作量在不同阶段是如何分布的,如上,系统需求分析阶段工作量占项目整体工作量比例为10%,大概为69.2人天,再结合我们能在这个阶段投入的人员数量,我们就可以清晰知道这个阶段需要持续多长时间,这样就形成了相对客观准确的项目计划。

这就是我们对软件项目估算实际信息化的探索,信息化带来非常大的好处是便于积累历史经验数据,通过持续历史经验的积累,使我们的估算越来越准,希望以上探索对你有帮助。

   
次浏览       
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证