您现在的位置是: > 项目管理 > 项目管理流程百灵科技分享:软件项目管理流程总结

项目管理流程百灵科技分享:软件项目管理流程总结

时间:2019-02-08 19:34  来源:星夜孤灯  阅读次数: 复制分享 我要评论

兼职猎头

项目管理与软件开发的质量、效率、最终功效休戚相关,本文主要讲述软件项目的风险评价、本钱预算、客户沟通、须要分析、开发管理、制品托付等多个流程。

在现今国际的项目的管理形式异常纷乱,对管理缺欠重视,以至很多项目由于遗失管理而最终折腰。

很多的实战形人才只重视于开发环节,项目管理流程百灵科技分享:软件项目管理流程总结。而对其他的流程缺欠认识(包括自己),所以招致项目缺欠有条理的、阶段化的管理。

自己是一个典型的只重视开发的管理者,在屡次的训诫中深入地体会到管理的重要性,所以以此文章对项目管理作出一个总结,当中生活很多的不敷之处,敬请各位点评!

一、风险评价

软件项目风险是指在整个项目周期中所触及的本钱预算、开发进度、技术难度、经济可行性、太平管理等各方面的题目,以及由这些题目而对项目所孕育发生的影响。项目的风险与其可行性成正比,其可行性越高,风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、须要风险、相关性风险、管理风险、太平风险等六个方面:

1.产品规模风险

项目的风险是与产品的规模成正比的,凡是产品规模越大,题目就越突出。尤其是预算产品规模的方法,复用软件的若干,需求转移的若干等要素与产品风险休戚相关:项目管理流程百灵科技分享:软件项目管理流程总结。

(1)预算产品规模的方法

(2)产品规模预算的信托度

(3)产品规模与以前产品规模均匀值的缺点

(4)产品的用户数

(5)复用软件的若干

(6)产品需求转移的若干

2.需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目晚期容忍了这些不确定性,并且在项目进展历程当中得不到解决,这些题目就会对项目的告成造成很大恫吓。若是不控制与需求相关的风险要素,那么就很有可能孕育发生舛讹的产品恐怕巧妙地建造预期的产品。每一种状况对产品来讲都可能致命的,这些的风险要素有:

(1)对产品缺少清晰的认识

(2)对产品需求缺少认同

(3)在做需求分析历程中客户参与不够

(4)没有优先需求

(5)由于不确定的须要招致新的市场

(6)陆续变化需求

(7)缺少有用的需求变化管理历程

(8)对需求的变化缺少相关分析等

3.相关性风险

许多风险都是由于项目的外部环境或要素的相关性孕育发生的。控制外部的相关性风险,能缓解战术应该包括可能性计划,以便从第二资源或协同事业资源中取得必要的组成部门,并发现潜在的题目!与外部环境相关的要素有:

(1)客户提供条目或消息

(2)交互成员或交互整体依赖性

(3)外部或外部转包商的干系

(4)阅历厚实人员的可得性

(5)项目的复用性

4.技术风险

软件技术的飞速开展和阅历厚实员工的缺乏,意味着项目团队可能会由于技巧的由来影响项目的告成。在晚期,判别风险从而采取适宜的防范措施是解决风险领域题目的关键,譬喻:培训、礼聘垂问以及为项目团队雇用适宜的人才等。项目管理过程五个阶段。关于技术主要有上面这些风险要素:

(1)缺乏培训

(2)对方法、工具和技术理解的不够

(3)应用领域的阅历不敷

(4)对新的技术和开发方法应用不熟谙

5.管理风险

即使管理题目限制了很多项目的告成,但是不要由于风险管理计划中没有包括所有管理活动而感到惊诧。在大部门项目里,项目经理常常是写项目风险管理计划的人,他们有先性情的不敷——不能查抄到自己的舛讹。所以,使项目的告成变得加倍坚苦。若是不重视这些顺手的题目,它们就很有可能在项目实行的某个阶段影响项目自身。当我们定义了项目追踪历程并且明晰项目角色和义务,就能管制这些风险要素:流程。

(1)计划和任务定义不够充实

(2)对现实项目形态不了解

(3)项目所有者和决策者分不清

(4)不确现实的应许

(5)不能与员工之间的实行充实地沟通

6.太平风险

软件产品自身是属于制作性的产品,产品自身的焦点技术失密非常重要。但一直以来,我们在软件这方面的太平认识比力稀薄,对软件产品的开发主要重视技术自身,而马虎了专利的保卫。软件行业的技术人员活动是很普遍的形象,随着技术人员的丧失、转移,很能会招致产品和新技术的保密,以致我们的软件产品被它公司盗取,招致项目曲折。而且在软件方面关于常识产权的认定目前还没有明白的一个行业典范榜样,
项目管理流程百灵科技分享软件项目管理流程总结项目管理流程百灵科技分享软件项目管理流程总结
这也是我们软件项目潜在的风险。

7.逃避风险的方式

(1)以开发方诱导能保证需求的完备,使需求与客户的真实期望高度一致。再以书面便利造成《用户需求》这一重要的文档,制止疏漏造成的吃亏在软件编制的后续阶段被逐渐地缩小。

(2)设立监视制度,项目开发中任何较大的确定都必需有客户参与实行的,在该项目中项目监视由项目开发中的质量监视组来实施。

(3)需求转移须要经过同一的肩负人提出!并且要用户需求的审核诱导认可!需求转移应该是按期而不是随时的提出!而且开发方应该做好详细的纪录!让客户了解需求转移的现实状况。

(4)控制编制的纷乱水平,过于简单的编制组织,对用户来使用比例会有较着的折扣,以至造成软件寿命过短。反之,软件组织的过于活泼和通用,地产项目现在好做嘛。势必惹起软件告终的难度增加,编制的纷乱度会高涨,这又会在告终和测试阶段带来风险。对比一下总结。适当控制编制的纷乱水平有益于下降开发的风险。

(5)从软件工程的角度看,软件维护费用约占总费用的55%~70%,编制越大,事实上百灵。该费用越高。对编制可维护性的轻视是大型软件编制的最微风险。在软件冗长的运营期内,业务规则肯定会陆续开展,迷信的解决此题目的做法是陆续对软件编制实行版本进级,学习管理。在确保可维护性的前提下逐渐扩展编制。

(6)设定应急计划,每个开发计划都至多应该设定一个应急预案去应对出现突发状况和不可遇知的风险。

二、本钱预算

1.本钱预算方式

(1)自上而下的预算方法

自上而下的预方法主要是依据下层、中层项目管理人员的管理阅历实行决断,对组成项目整体本钱的子项目本钱实行猜想,并把这些决断猜想的结果转达给低一层的管理人员,在此根源上由这一层的管理人员对组成项目的子任务和子项目的本钱实行猜想,然后继续向下一层转达他们的本钱猜想,直到转到达最低一层。项目管理三要素。

使用此预算方式,在下层的管理人员根据他们的阅历实行的费用猜想剖析到下层时,可能会出现下层人员以为下层的猜想不敷以完成相应任务的状况。这时,下层人员不一定会表达出自己的真实概念,不一定会和下层管理人员实行明智地计议,从而得出更为合理的预算分配计划。在现实中,他们往往只能安静地守候下层管理者自行发现题目并予以纠正,这样往往会给项目带来诸多题目。

自上而下更适用于项目发动的前期,与真实费用相差在30% ~ 70%之间。

Scrum使用自上而下的本钱预算方式,它不会立即切确地确定本钱,管理。而是以最大限度包容客户对异日产品央求所孕育发生的转移。

(2)自下而上的预算方法

自下而上方法央求运用WBS(WorkBreakdownStructure,事业剖析组织)对项目的所有事业任务的时间和预算实行仔细调查。起先,预算是针对资源(团队成员的事业时间、硬件的配置)实行的,项目经理在此之上再加上适当的直接费用(如培训费用、管理费用、不可预见费等)以及项目要到达的成本倾向就造成了项目的总预算。自下而上的预算方法央求统统推敲所有触及到的事业任务,更适用于项目的初期与中期,它能预备地评价项目的本钱,与真实费用相差在5%~ 10%之间。

2.确定项目支出

总体本钱预算就是维系下列多个本钱预算方式综算计算的开发本钱:

(1)零基数预算

在本钱预算的初期应该使用零基数的计算原则,而不能够使用犹如彷佛于:以上一年总体费用加上20%这样大意的方式计算项目本钱。

(2)软硬件本钱、物品本钱

物品本钱是指犹如彷佛于:办事器(RAM硬盘CPU NIC卡RAID簇)本钱、维护本钱、机房租金、光纤通讯本钱、软件本钱等的本钱。

计算本钱时须要推敲安装硬盘需时的长短,技术人员须要齐备的质素,产品提供商能否提供保证质量,其实项目管理就业前景。管理时能否须要出格的管理人员这些多方要素。

(3)软件许可证本钱

(4)外包本钱

当使用犹如彷佛:视频、短信、搬动电信类办事、门户网站等子项目时能够推敲以外包形式完成,以下降开发本钱。

(5)人力资源本钱

计算人力资源本钱时应该使用以最高和最低的事业效率预算均匀效率的方式,计算出人力资源的均匀本钱。

(6)维修珍爱本钱

三、客户沟通的历程

从客户沟通的方向启航来看,软件项目可分为:需求判别、计划定制、项目实施、项目了局等4个不同的阶段,各个阶段都具有不同的沟通重点。

1.需求判别阶段

(1)文本沟通

在需求判别的前期,应该经由过程问卷、原型涌现、界面涌现、逻辑管制涌现、准化文档模板等方式实行全方位多角度的分析,随时将不明白之处反应给客户!以期待客户解答。并以文本纪录的方式建立须要分析书,并央求客户审核需求分析书,学习公司项目管理流程。以到达须要分析与客户的真实期望高度一致的结果。

(2)业务逻辑沟通

在实行业务沟通时,应该了解客户的行业讲话,以鼓动业务分析的历程,越过应用需求和开发之间的鸿沟。沟通历程提倡以草图恐怕可视消息化的方式实行!针对不同层面的企业用户提供最适合的操作界面。以多角度的方式思考题目,要抓住需求重点!尤其是客户方诱导所眷注的创新类和适用类需求。

(3)需求转移的典范榜样化管理

需求转移在软件开发类项目中是能够理解的!但必需对需求转移做好典范榜样化的管理,以制止出现需求无尽头转移的风险。需求转移必需由同一的肩负人提出!并且由用户需求的审核诱导者认可。需求转移的提出应该是按期而不是随时的,开发方应该做好详细的文本纪录!让客户了解需求转移的现实状况和开发方为之所付出的本钱代价。

2.计划定制阶段

该阶段项目的主要任务是与客户协同制定一个以前期明白的需求、两边的资源、项目先河的阶段、实施的时间商定、项目费用限制等为根源的具有可操作性的项目计划!从本阶段先河争取客户统统参与项目的管理,并以两边的协同利益推敲项目实施的满堂计划与风险闪避。

3.项目实施阶段

在该阶段!软件项目团队应该与客户协同诱导项目的实施。同时!项目团队应实时评价客户如意度!并经由过程持续矫正的方式进步客户如意度!还应央求客户出席必要的培训!以及在必要时查抄项目产品。在出现客户的需求转移前!应主动与客户沟通相易!使客户充实了解项目的每个环节!以及转移带来的影响!淘汰需求转移。若是出现客户需求转移!应与客户沿路协同解决由转移惹起的本钱、进度、质质变化。

4.了局阶段

该阶段主要实行项目功效的移交,并把编制托付给维护人员,辅助客户告终商务倾向,结清各种款项。完成这些事业后应该实行项目评价,审核此项目的功效并总结项目阅历。

5.售古人员注意事项

在产品型项目作为开发功效时,相关出卖人员应该注意:我不知道软件。对产品的倾销不应该过度应许。若是过度应许!会给后续的项目实施带来坚苦;一旦应许没有兑现!也会下降客户如意度!影响今后互助。若是有附加应许!一定要以文本形式纪录,让实施项目经理晓得并传达给项目组成员。

注解:在软件项目中!须要明白以下四种客户角色

A.要明白最终使用部门和用户!要去了解他们现有的事业方式!要让他们知道项目的倾向框架!知道项目要解决他们的哪些坚苦!但万万不是全部坚苦!这样能够较好的控制项目领域。

B.要明白需求的提出者!他恐怕他们要能够代表最终客户集体。提出产品需求的这类客户要具有一定的技术、业务本事和巨头!能够真正代表最终客户团队的志愿和想法!最好有IT根源!能够用IT讲话描摹题目和需求!以利于两边的沟通、协作!制止孕育发生歧义。

C.要明白做需求确认的中层诱导!他要支配方向。软件开发项目是解决现实坐褥恐怕管理题目!同时也是诱导编制树立的满堂告终!做需求确认的客户诱导!既要了解高层诱导的编制树立要点和方向!又要谙熟满堂业务和坐褥管理现实。若是是这样的客户诱导来支配和决策!对企业软件开发项目的亨通进展作用不凡。

D.要明白谁来对制品提意见!谁来验收。项目验收环节!是项目的扫尾环节!若是验收的人对项目初期的需求倾向不了解!会从态度和产品现实使用效果上对验收孕育发生反面的影响!对提供产品的企业关闭项目非常晦气。根据实验总结!由需求提出人和确认人来做项目的验收事业!能够鼓动项目的亨通完成!制止延期。

四、需求分析

1.需求分析的历程

需求历程包括需求开发和需求管理2个部门:

(1)需求开发就是对开发前期的管理,与客房的沟通历程,能够分为4个阶段:需求获取、需求分析、编写需求和需求考证。

(2)需求管理:相比看公司项目管理流程。就是软件项目开发历程中控制和维持需求商定的活动。包括:转移控制、版本控制、需求跟踪、需求形态跟踪。

2.需求的层次

需求的层次包括:业务需求、用户需求、功用需求、非功用需求等4个方面。

3.需求开发阶段的重点

(1)提取业务对象

业务对象是指编制使用的真实对象,例如一个提供链管理(Supply Chain Mvery goodment!简称SCM)业务对象主要包括:坐褥批发商、批发商、送货商、顾客多个层次。项目管理过程五个阶段。

(2)提取业务流程

在了解业务逻辑的历程中,应该枚举出所开发软件模块的各自职能,并细化每个事业流程,深入分析业务逻辑。

(3)机能需求

在分析的前期应该注意客户对所开发软件的技术机能目标,如存储容量限制、运转时间限制、太平失密性等。

(4)环境需求

环境需求是指软件平台运转时所处环境的央求,如硬件方面:机型、外部设备、数据通讯接口;软件方面:编制软件,包括操作编制、网络软件、数据库管理编制方面;使用方面:使用部门在制度上,操作人员上的技术水平上应齐备怎样的条件。

(5)确实性需求

对所开发软件在投入运转后发生妨碍的概率,应该按现实的运转环境提出央求。对于重要的软件,或是运转生效会造成告急后果的软件,应提出较高的确实性央求。

(6)太平失密央求

在需求分析时该当在这方面恰本地做出法则,对所开发的软件赐与特殊的安排,使其在运转中,其太平失密方面的机能获得必要的保证。

(7)用户界面需求

为用户界面细巧地法则到达的央求。

(8)资源使用需求

开发的软件在运转时和开发时所须要的各种资源。

(9)软件本钱破费与开发进度需求

在软件项目立项后,根据合同法则,对软件开发的进度和各步调的费用提出央求,作为开发管理的依据。

(10)开发倾向需求

事后猜想今后编制可能到达的倾向,看看项目。这样能够比力容易对编制实行必要的补充和批改。

4.需求分析的任务

需求分析的主要任务是借助于此刻编制的逻辑模型导出倾向编制的逻辑模型,其流程如下:

(1)确定对编制的分析需求(功用、机能、运转、增添需求)

(2)制作产品需求文档(PRD)

(3)分析编制的数据需求(概念模型、数据字典、典范榜样化)

(4)导出倾向编制的详细的逻辑模型(数据流图、数据字典、主要功用描摹)

(5)开发原形编制

(6)从PRD提取编制软件需求规格评释书(SRS)

注解:SRS格式

1.引言

2编制概述(项目背景、编制倾向、焦点业务流程)

3.术语评释

4.编制组织(架构图、功用图)

5.主体功用与业务逻辑(重点)

6.接口需求(外部、外部接口、)

7.网络总体安排(拓扑网络、主机、组网)

8.运转环境(Linux、Windows、IIS、WebLogic、Tomcto、OLAP、OLTP、JDK8.0、.NETFrin the morningework 4.0等)

五、面向对象程序安排(略)

1.安排原则

(1)SRP繁多职责链

每个类都应该只肩负做一件事。

(2)OCP开关闭合原则

软件的实体(类、模块、函数等)应该是能够扩展的,但是不可批改的。

(3)LSP替代原则

子类必需能替代他们的基类型。

(4)DIP依赖倒置原则

高层模块不应该依赖于低层模块,二者都应该依赖于接口与笼统类。学习pmp证书含金量。笼统不应该依赖于细节,细节应依赖于对象。

(5)ISP接口隔离原则

不应该逼迫客户依赖于并未使用的接口,而应该把胖接口星散。

2.告终UML建模

(1)业务对象的提取

(2)根据SRS、CRC等告终用况建模

(3)告终业务规律图

(4)建立类图,根据用况图建立对象之间的关联

(5)绘制活动图、告终协作图、形态图

六、开发管理

1.建立项目计划

(1)安排总体架构

针对编制的实施须要,采取适当的且幼稚的框架组织。

(2)控制可扩展度

扩展渡过大,流程。将进步编制的纷乱水平,延迟开发时间;扩展渡过低,会直接影响编制的二次开发与维护。控制编制的可扩展性,能进步开发效率,下降编制维护的难度。

(3)建立根源设施

合理分配安顿软、硬件等根源设施所须要的时间与本钱(例如:办事器的订购装置、光纤接入、软件平台订购)。

(4)划隔离发任务

应用WBS(WorkBreakdownStructure,事业剖析组织)对可托付结果实行分类与分别。每个项目都能分别为多个不同阶段,每个阶段又能够分为多个事业包(WorkPair conditioning unitk),事业包是WBS里最小的可托付结果,末了从事业包中剖析出多个开发任务列表。

(5)安顿开发进度

一个项目应该按进度分别为多个开发阶段,每个阶段的开发周期凡是在30~60个事业日以内。在此阶段内应该与客户举行协商会议,制定产品门路图,在开发历程中邀请客户主动参与并提出反应意见。然后把该时段内的开发任务遵守开发难度,依赖性,重要性等多方条件分别为多个迭代周期。

在Scrum敏捷软件开发原则中,应该把每个迭代任务进一步细分为多个开发任务列表,想知道项目。再开发任务分配给组员各自肩负,而开发时间应该控制在15个事业小时以内。若是开发时间超出15个事业小时,应该推敲把开发任务再度细化。开发任务提倡应该由组员自主选拔,而不要使用强制分配的方式。

(6)测试项目功效

每个事业包都应该同步安顿测试事业,进步项目的质量。对出错BUG的事业包应该由测试人员以文本方式纪录,向开发人员涌现舛讹所在,让开发人员及时实行批改。

2.管理开发团队

(1)组建团队

遵守事业任务与项目时间的前提条件建立团队,按团队职责分配人员,凡是团队人数应该控制在8~12人之间。当团队人数超越15人时,应该推敲把团队剖析成2个独立团队,肩负不同的开发任务。

(2)分配开发任务

在每个迭代周期内(凡是是15~30个事业日),应该把每个事业包进一步细分为多个开发任务,项目管理过程五个阶段。再开发任务分配给组员各自肩负,开发时间应该控制在15个事业小时以内。若是开发任务的开发时间超出15个事业小时,应该推敲把任务再度细化。而开发任务应该以自在选拔的方式分配给每个组员。看着项目管理工资高吗。

(3)监视开发进度

在迭代的前期举行一次会议,让组员了解开发的进展及流程,并以自主选拔的方式分配开发任务。时期可使用MicrosoftProject等工具纪录开发流程的进展,在每个事业包完成开发后应该实行性功用的测试,并以文本方式纪录测试结果。

每天举行一次15分钟的站立会议,让组员交待前一天已完成的开发任务,当天将要做的任务,与开发历程中所遇到的题目。并在每周末举行一次例行会议,交待总体进程。

在迭代末期举行一次冲刺会议,总结项目的进展,科技。交行已完成的任务,回首回头回忆该迭代周期内所遇到的题目,为下一个迭代做好预备。

(4)编制测试

对每个已完成的事业包实行适时的测试,保证编制质量与机能。对测试结果实行文本的纪录,并把测试结果与绩效工资支出挂钩,并以真实数据计算组员的绩效支出。

(5)解决开发中所遇到的题目

对开发人员实行前期培训,可适当按事业本事分配任务,指导组员的开发。当遇到题目时应该在当天的站立会议时立即提出,并在15个事业小时内解决所遇到的题目以防止题目进一步扩大。

3.监管产品德量

(1)质量须要的是计划、安排而并非稽察的。在产品建立的初级,对比一下分享。必需与“质量保证”(QA)的部门实行协商,以正式文档的方式,确定适合的质量战术和轨范。

(2)在开发历程中使用TDD(测试驱动开发)的形式,进步开发质量。测试人员应该以文本方式纪录virus,并与开发人员协同事业的,把突出的缺陷演示给开发人员,以进步批改的效率。

(3)在每个迭代的了局时实行一次产品效果的演示,从客户、使用者、高层诱导中搜罗反应消息。在团队外部举行评审会议,分析测试结果,了解产品机能,为下次迭代所须要做的矫正做好计划。

4.批改项目计划

(1)在产品须要判别阶段,应该以文档形式纪录产品功用与开发流程,在开发计划须要批改时,应该与客户协同探讨,让客户了解计划批改对项目进度所造成的影响。

(2)项目计划的批改应该由同一的肩负人提出!并且由用户需求的审核诱导者认可。电力公司项目管理中心。需求转移的提出应该是按期而不是随时的。

(3)计划的转移应该做好详细的文本纪录,让客户了解需求转移的现实状况和开发方为之所付出的本钱代价。

七、产品托付

1.项目的前期审核

在项目开发最终完成后,对开发人员来说可算是放下事业的重担,但对项目经理来说这往往是项目的关键时刻。前期的风险评价、本钱预算、需求分析、软件安排都是为了引导项目走向这一时刻,此时所有的眼光都将投向项目管理人员。你可能发现多量而琐碎的事业将要在几个小时内完成,此刻项目经理更须要连结醒悟与沉着,把末了的事业视为微型项目来周旋。细巧地对项目实行前期的审核,分析项目功效、项目团队的效率、可托付产品的价值,以此审核结果可作为项目管理阅历总结的一部门。

2.质量评审

在项目托付前,应该把项目交给相关的“质量保证”(QA)部门实行质量评审,并邀请典型用户感受产品的质量。

3.项目的最终托付

一般状况下在项目的前期就会订立项目托付的协议,项目托付方式分为非正式验收与正式验收两种。凡是在项目完成后都会先实行非正式验收,让客户体会项目的质量并提出反应意见,末了在客户肯定产品德量后再以书面协议的形式实行正式的产品验收。

4.项目的最终叙述

在项目的末了,应该制定项目的最终叙述,此叙述能够视为是对该项目一个纪录,但叙述不用蕴涵项目的所无方面。凡是最终叙述应该蕴涵以下方面:

(1)起先引进项目时的初期项目视图

(2)对该项目的价值评价及支持性消息

(3)项目的领域

(4)项目的开发流程及WBS

(5)项目的会议纪录

(6)项目转移的叙述及转移的理由

(7)与项目相关的沟通历程文件

(8)项目的审核叙述与客户验收叙述

(9)项目成员的浮现叙述

(10)项目的最终功效

作者:风尘浪子

leslies2/orgvery goodize/2012/06/29/.html

原创作品,转载时请注明作者及出处