软件项目的时间管理

软件项目的时间管理（精选12篇）

软件项目的时间管理 第1篇

随着信息产业日渐成为国民经济的支柱产业,软件外包产业得到迅速发展,而作为软件项目管理中重要的时间管理却没能得到软件业界的重视。软件开发管理者往往没有主动地管理好时间,控制好进度。而时间管理不当,会导致项目延期甚至失败,不仅给项目开发者带来严重的影响,还会对公司和社会造成巨大的经济损失。

本文首先介绍了软件项目时间管理的理论,通过一个实例分析了软件项目的开发过程中存在的时间管理问题,并针对存在的问题提出了相应的建议。希望提醒软件开发者重视时间管理的理念,研究并运用适当的时间管理方法,保证软件项目能按时、保质完成。

1 软件项目的时间管理

项目时间管理,又叫做项目进度管理或项目工期管理,就是为确保项目按时完工所进行的一系列管理过程[1]。项目时间管理在理论上可概括为五个主要过程:

活动定义 确定为完成项目可交付成果所必须进行的各项具体活动;

活动排序 确定各活动之间的依赖关系,并形成文档;

活动历时估计 估算完成单项活动所需要的时间长度;

制定进度计划 制定项目的进度计划,并采取技术措施和组织措施来实现项目,使所耗时间短、费用少;

进度控制 对进度计划实施情况进行偏差分析和趋势预测,及时变更项目的进度计划[2]。

软件项目管理是根据管理科学的理论,结合软件产品开发的实际,保证工程化系统开发方法顺利实施的管理实践,为了使软件项目能够按照预定的成本、进度、质量顺利完成,从而对成本、人员、进度、质量、风险、文档等进行分析、管理、控制的一系列活动。软件项目本身的进度管理通过项目管理的五个过程实现,即软件项目的任务分解和定义,软件项目的活动排序,软件项目的工作量估算,软件项目进度计划的编制以及进度计划的变更管理[3,4]。

除此之外,软件项目是人参与的活动,对项目开发者的时间管理,也尤为重要。

1.1 软件项目本身的时间管理

(1) 软件项目的工作量估算

软件项目的工作量主要指软件开发过程中所花费的人力与时间,是从软件计划、需求分析、设计、编码、单元测试、集成测试到验证测试整个开发过程所花费的工作量。软件工作量的估算可以采取不同的操作方法自顶向下估算法、自底向上估算法、相似比较估算法、及Delphi估算法等[5]。

(2) 软件项目进度计划的编制

安排进度计划的目的是控制时间和节约时间,而项目的主要特点之一是有严格的时间期限,由此决定了进度计划在项目管理中的重要性。

基本进度计划要说明哪些工作必须于何时完成和完成每一任务所需要的时间,但最好同时也能表示出每项活动所需要的人数。常用的一些制定进度计划的方法有关键日期表、甘特图(Gantt chart)、里程碑图、关键路径法CPM(Critical Path Method)、计划评审技术PERT(Program Evaluation and Review Technique)、图示评审技术GERT(Graphical Evaluation and Review Technique)等。其中,关键日期表编制时间最短,费用最低;甘特图所需时间要长一些,费用也高一些;CPM要把每个活动都加以分析,如果活动数目较多,还需用计算机求出总工期和关键路线,因此花费的时间和费用将更多;PERT法可以说是制定项目进度计划方法中最复杂的一种,所以花费的时间和费用也最多[6]。

采用哪一种进度计划方法,主要考虑项目的规模大小、复杂程度、紧急性、对项目细节掌握的程度、总进度是否由一两项关键事项所决定、有无相应的技术力量和设备等因素。

(3) 软件项目进度计划的变更管理

在项目执行过程中,经常出现项目的进度早于或晚于计划进度,已经发生的实际成本低于或高于计划成本,这时需要对计划进行相应的调整。

对不同原因产生的进度偏差,采取的对策也不同。软件项目开发过程中常见的偏差原因和对策如表1所示[7]。

引起进度偏差的原因往往不是单一的,而是多种因素共同作用的结果。只有准确地找出问题产生的根源,才能从根本上解决问题。

1.2 软件项目开发团队的时间管理

项目毕竟是由人来完成的,进度计划再完善,倘若得不到团队很好的实施,也是惘然。据调查,在一个企业里面,员工大约80%的工作时间被白白浪费掉了,只有20%的时间在为公司创造效益,属于有效时间[8]。因此只有个人的时间得到有效利用,顺利地完成每一天的工作计划,项目整体的进度才不会拖延。

不论是项目经理还是团队的普通成员,都应对自身的时间进行有效管理。常用的方法是时间“四象限”法,即根据事件的紧急性和重要性的程度,将时间划分为四个象限:第一象限是紧急并且重要的事情;第二象限是不紧急但是重要的事情;第三象限是既不重要也不紧急的事情;第四象限则是紧急但不重要的事情,因此具有很大的欺骗性,因而像无谓的电话、应酬等事件紧急却并不重要,根本不需要花很多的时间去做。

项目经理是一个项目的灵魂。项目从开始到结束,都需要控制项目的各个方面按照计划进行,是整个项目开发团队的领导人物,因而项目经理的时间管理极其重要。因此,项目经理在工作中,要学会授权。项目经理只需为项目成员提供方向、动力或工具,和成员之间要维持充分的信任和协作关系,采取支持、鼓励、劝告、帮助的方式,实现项目成员的自我管理。这样不仅减少了项目经理的负担,也培育了团队整体的能力,从而提高了项目效率和效果。因而,授权体现了权、责的有效结合。其次,要排除干扰。项目经理常常会受到团队成员的干扰。一旦被别人打扰,时间被分割,就无法完成其他重要的事情。为此,项目经理可以采取下列措施:

① 训练助理,将他人可能的打扰集中起来,然后每天或每星期汇报一次;

② 每天保留一段固定的时间,供团队成员提出问题;

③ 鼓励团队成员以便条/邮件方式提出问题,而不必事事亲自上门。

2 软件项目的时间管理实例及分析

2.1 软件项目的时间管理实例

某软件公司获得了一个对日软件外包项目,包括40本程序(本是实现一个完整功能的程序单位,一本程序也就是一个程序)的详细设计、编码以及单体测试工作。客户的要求是:使用指定的技术和工具;在客户自主开发的平台上进行开发、测试;严格的文档格式和技术要求;必须保证工期在3个月内提供完整的产品。

项目立项后,公司立即成立了项目小组。项目经理具有丰富的对日软件项目开发经验,项目经理下设三个小组:负责详细设计的DS小组(6名成员),负责编程的PG小组(5名成员)以及负责测试的PT小组(5名成员)。同时,日方派驻了一名SE(高级分析设计人员),主要负责分析、设计以及中日两方的协调工作。

项目组经过分析,将40本程序分为A、B、C三类,分别包括10本、12本、18本程序。其中,A类是一些数据库表的维护工作,相对简单。B类和C类难度预计差不多,但是分别属于不同的业务领域。

项目顺利进行一个星期后,部分程序的详细设计出来了。三个小组开始同时进行。详细设计人员继续做详细设计,编码人员投入编码,而测试组成员同时编制测试设计书,并设计测试案例。

PG小组首先从难度最小的A类程序入手。一周后,A类程序全部编码完成,PT小组开始测试。很快,测试修改完毕后的5本程序交给日方,验收顺利通过,并得到极高的评价。

首战告捷使项目经理和所有成员信心倍增,开始进攻难度较高的B类、C类程序。经过仔细分析,B类和C类程序可以划分为输入、批处理、打印三类。项目经理因此更新了进度计划,每名PG成员分别负责2本输入程序、2本批处理程序、2本打印程序。

正当大家怀着胜利的喜悦继续前进的时候,PG小组遇到了很大的难题日方提供的开发平台太复杂了,已经开发完成的A类程序其实只是一种二层结构的程序,而B类、C类程序是复杂的三层结构,要搞清楚如何开发这些程序不只需要充足的时间、丰富的经验和高超的技能,更需要对开发平台的充分认识。

一周过去了,项目进度还是停滞不前。于是,项目经理开始要求大家加班。两周过去了,技术最好、经验最丰富的一名PG人员小G的进度率达到了40%,而其他成员仍然在原地踏步。大家纷纷去请教小G,小G不耐烦地回答:“去看开发文档吧”。

烦躁、焦虑、疲劳,两名PG成员接连病倒了。三周后,除了已经完成的A类程序外,只有小G的一本程序的进度达到了80%,其他队员都在忙着从数百页的日文开发手册中寻找答案。无奈之下,项目经理要求PT组有经验的成员加入PG组以填补空白。

工期已经非常逼近,公司只好从其他项目组中抽调了2名经验丰富的“技术高手”来协助,同时安排大家都加班。同时,公司安排小G不再继续开发工作,而是做专门的技术指导,帮助大家解决技术难题和开发平台相关的问题。经过大家的齐心协力,加班加点,在预定截止日期的当天,所有程序都勉强开发、测试完毕。

一周后,日方反馈的信息说明有很多问题和错误需要修正,并且提出了设计式样上的变更。于是,项目组继续奋战,经过多次变更修正,一个月后,项目终于结束了。

2.2 项目在时间管理中存在的问题分析及建议

预期三个月完成的项目却拖延了一个月才结束,仔细分析,在时间管理中存在的问题如下:

(1) 错误的工作量估算

项目经理对工作量的推算如下:一名PG 用两天完成一本程序,加上B类C类程序的难度,保守估计5天时间一本。那么完成40本程序的编程大概需要45天。一名测试人员用两天时间设计一本程序的测试设计书,4天测试完毕,保守估计5天。而且测试不存在很大的难度,只是工作量的问题。那么,总工期大约是60天。实在时间紧张,还可以安排加班,不存在很大的风险。

实际上在项目开发过程中,对客户的开发平台不熟悉,使得项目组成员需要过多的时间来熟悉掌握。同时,技术上的瓶颈导致B类和C类的一本程序花费了比三个星期还要多的时间。

(2) 不合理的进度计划

项目的开发手册有数百页之多,项目小组成员自然会有些敬畏,都感觉项目有些难度,但又不知道具体有多大。项目经理为了稳住军心,先将难度最小的A类程序排在进度计划的最前沿。然而首战告捷也使得项目组成员低估了B类、C类程序的技术难度,丧失了应有的危机意识。

另外,在完成B类、C类程序时,项目经理分配每名PG成员分别负责2本输入程序、2本批处理程序、2本打印程序。这样一来,每一名PG成员都需要同时去钻研三类程序中存在的技术难题。这种安排完全忽略了一个事实:同一类型的程序具有相同的技术难点,如果编写第一本程序需要15天,第二本可能只需要4天时间。由于项目经理对这种学习能力的忽视,导致他安排大家做同样的攻关工作,造成时间和智力的浪费,也影响了大家的情绪。直到后来请小G担任专门的技术专家,集中解决问题,才提高了开发效率。

因此,在安排进度计划时,项目经理应按照程序类型将任务分派给小组成员。每2个人负责一个类型的程序,一起开发,共同研究技术难点。这样,大家可以互相交流,不仅每个人身上的压力减少,开发的时间亦会缩短。

(3) 不当的进度控制

在项目的开发过程中,进度失控的情况异常严重,而项目经理却没有及时采取有效的措施。

① 出现技术瓶颈

项目开展三周后,项目的问题就已经很严重了。技术难题无法攻克,进度停滞不前,开发人员相继请假从而使得人力资源不足。直到离期限不到三周,实际完成的B类和C类程序的开发工作量还不到1/30的时候,项目经理才不得不向公司汇报情况。然后,经过公司高层的协调,才得以抽调人员,及时解决问题。其实,在此过程中,当发现只有小G一人有所进展的时候,项目经理应该组织大家对问题进行探讨,例如开展技术交流会,让小G为大家答疑解惑;或者像后来的情况,让小G专门负责技术咨询,这样就可以及早地帮助大家缓解压力,摆脱进度失控的危机状态。

② 频繁的设计变更

在外包项目中,频繁的设计变更常常是导致项目延期的主要原因。因此,在项目开始时,项目组应该在熟悉整个业务流程的基础上,通过与客户沟通,挖掘出客户真正的需求,而不是被动地接受客户提出的设计变更。

(4) 消极的个人时间管理

在PG组其他成员纷纷请教小G时,小G不耐烦地说:“去看日方发过来的资料吧。”显然,小G也在为分配的任务难以完成而感到烦躁。对他而言,完成手头的这本程序是最紧急且重要的事。须知,软件项目是项目开发团队集体协作共同的智慧成果,只有每个人的进度跟上了,整个项目的进度才不会拖延。所以,耐心地指导其他人,帮他们答疑解惑,一起攻克技术上的难关,才是上策。

PG组的其他成员也没有利用好自己的时间。经过了两周的愁眉不展和小G的提醒,大家才去翻看开发手册熟悉业务。而在此之前,他们的眼里只有难以解决的技术问题,因而陷入了极度消极的状况。

3 结 论

软件项目管理是根据管理科学的理论,结合软件产品开发的实际,保证工程化系统开发方法顺利实施的管理实践,其中的时间管理包括软件项目本身的进度管理及项目开发者的管理。本文通过实例分析,指出了软件项目在时间管理中存在的问题,并提出了相应的建议。同时希望提醒软件开发者重视时间管理的理念,研究并运用适当的时间管理方法,保证软件项目能按时、保质完成。

摘要：项目时间管理又称为项目进度管理或项目工期管理,是为确保项目按时完工所进行的一系列管理过程。对于软件项目来说,由于软件是由人开发的,不仅项目的进度需要管理,项目开发团队的时间也需要管理。首先介绍软件项目时间管理的理论,然后结合软件开发过程的特点,分析了软件项目的时间管理方法;然后用一个实例加以分析,指出软件项目在时间管理中存在的问题并提出建议,希望软件项目管理者在保证进度管理有序执行的同时,也注重对人的管理,保证软件项目能按时、保质完成。

关键词：软件项目,时间管理,进度

参考文献

[1]杨坤.项目时间管理[M].天津:南开大学出版社,2006.

[2](美)项目管理协会.项目管理知识体系指南(第3版)[M].北京:电子工业出版社,2005.

[3]Henry J.Software Project Management:a real-world guide to success[M].北京:科学出版社,2004.

[4]张家浩.软件项目管理[M].北京:机械工业出版社,2005.

[5]韩万江,姜立新.软件项目管理案例教程[M].北京:机械工业出版社,2005.

[6](美)TMochal,J Mochal.项目管理十步法[M].北京:清华大学出版社,2005.

[7]Weinberg G M.Quality Software Management[M].北京:清华大学出版社,2004.

软件项目管理的论文 第2篇

软件项目开发是一项系统而复杂的工作 它需要一个团队互相配合、分工协作。软件项目管理系统可以规范一个软件开发团队的日常工作，下面是关于软件项目管理论文，欢迎借鉴!

随着信息技术的飞速发展，软件产品的规模也越来越庞大,各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。但国内软件企业对于软件项目的认知，在一定程度上盲目多于理性、理论多于实践。鉴于上述问题，本文分析了基于项目管理的软件开发过程需要注意的几个问题。

1需求开发要注意的问题

需求开发作为软件项目启动的初始工作有两个目标:发现真正的需求并以适合于用户和开发人员的方式加以表述。

发现需求即需求获取,“真正的需求”是指在实现时可以给用户带来预期价值的需求“;以适合于用户和开发人员的方式”即需求定义,主要是指对需求的最后描述必须让用户和开发人员无歧义的理解。在需求开发过程,软件开发人员要注意如下的两个问题:

1.1 不要忽视非功能需求

通常，需求分析人员更多的关注功能需求，而忽视非功能需求，从而导致 NV[2]( 即“下一版本”) 陷阱。陷入 NV 陷阱后，产品的质量会大打折扣，甚至“拿不出手”。另外，不完整的需求也容易导致架构的错误设计，如:1.1.1 XX 查询的响应时间必须小于 1 秒;1.1.2 并发用户的数量每小时超过 10000个用户对于此类性能方面的非功能需求，直接影响到架构中持久层设计所采用的技术，而且这种架构上的缺陷实际上很难在“下一版本”轻易的改变。为了防止陷入 NV 陷阱，非功能性需求从一开始就要被提出来，和功能性需求一样受到应有的重视。如果这些非功能性需求是确实需要的，就应该被写入需求规格书，并在产品开发过程中接受实现状况的检查。

1.2 正确面对需求变更

在大多数软件项目中最不稳定的部分就是需求。在项目需求分析阶段，必需全面的、应尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其它软件的接口要求，以及对项目进行评估的各种评价标准。但由于各方面的原因用户需求始终处在一个持续变化的状态中，这是项目开发人员必须的接收的事实。那么对于这样的现状，软件开发者该怎么办呢? 其一是把需求变化控制在最小的范畴，在需求变化发生之前尽量减少需求变化; 其二是在设计软件体系结构时，不仅应该想到如何满足现在已经提出的用户需求,同时也应适当地考虑到需求的变更，想办法应对需求变化，例如:采用面向对象的思想。世界都是由对象组成的，而对象都是持久的。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方法就被称为 OOAD(Ob-ject Orient Analysis & Design 面向对象的分析和设计)。

2项目管理人员需要克服的障碍

项目管理是一项控制性的工作,项目管理者的工作重点就是控制和协调。项目管理者首先要确保每个成员完全理解任务,要把任务的目标解释清楚，并强调他对最终期限及评估成果的期望。

在软件的整个开发过程中项目管理者需要有效的监控工作进展，并提供给每个成员必要的协助，以确保整个开发团队朝着目标前进，并且在项目迭代开发过程中的设定可观测的里程碑。作为团队开发的项目管理者,要让整个开发团队有效地运转，发挥团队每位成员的最大能量,必须要克服下列障碍：

2.1障碍一:不信任员工

最简单的例子是，在重量级(Heavyweight)方法[3](制定了大量的规则的 RUP 方法)中,基本假设是对人的不信任，但不信任就会产生很多的问题，比如士气不高，计划赶不上变化，创新能力低下，跳槽率升高等等。轻量级( Lightweight) (像XP 这样只制定少量的规则来规范行为的方法)方法的出发点是相互信任，做到这一点是很难的，但是一旦做到了，那么这个团队就能高效运作。

2.2 障碍二:对任务的控制走向极端

很多项目管理者害怕失去对任务的控制。如果能够保持沟通与协调的顺畅，采用类似“关键会议制度”等手段，强化信息流通的效率与效果，任务在完成的过程中，失控的可能性其实是很小的。同时，在安排任务的时候，项目管理者应该尽可能地把问题、目标、资源等，向各成员交代清楚，也有助于避免任务失控。

2.3 障碍三: 管理意识薄弱

在软件企业中，项目经理大多是技术骨干。因此有些项目管理者凭着自己的技术实力宁可自己做得很辛苦，也不愿意把工作内容交给团队成员。为什么呢? 他们认为，教会部下怎么做，得花上好几个小时; 自己做的话，不到半小时就做好了，花那么多时间教他们，还不如自己做更快些。问题是: 难道项目管理者就这样一直把所有的事情都自己做吗? 由于团队成员的经验、技能等方面的差异，尽管项目管理者自己亲自动手可能做得比其他成员好，但是如果项目管理者能够教会团队成员，就会发现: 其他成员也可以做得一样好，甚至更好。也许今天项目管理者要耽误几个小时来教其他成员干活，但以后他们会为项目管理者节省几十、几百个小时，让项目管理者有时间对关键业务作更多的更深入的思考，以保证软件开发的成功。

3 软件模块的再认识

每一个软件模块都具有三项职责: 第一个职责是它运行起来所完成的功能，这也是该模块存在的原因; 第二个职责是它要应对变化，几乎所有的模块在它的生命周期内都要变化，开发者应保证这种改变尽可能的简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它进行修正; 第三个职责是能和阅读它的人很好的沟通，对该模块不熟悉的开发人员也能比较容易的阅读并理解它。一个无法进行沟通的模块也是拙劣的，同样也需要对它进行修正。

当开发人员最初编写一个模块时，代码对于他们来说看起来也许是清晰的.。这是由于他们专注于代码的编写，对代码非常熟悉。

经过一段时间后，开发者回过头来在去看那个模块，就知道自己怎么会编写如此糟糕的代码。为了防止这种情况的发生，开发人员必须站在阅读者的位置，对代码进行必要的重构，这样其他的阅读者就能够理解代码，同时所有的代码也需要团队中其他成员的评审。

4 重视经验的总结

在软件开发的过程中，对每一问题的解决不可能一开始就有一个好的方法，在解决一系列类似的问题后，开发人员再回过头来重新审视和评价自己解决问题的方法，在大多数情况下，开发人员都可以对这些解决方法加以提炼，对具有共性的解决方法进一步抽象，寻求更通用的解决方式，并将该设计经验提交到团队资源库组织成项目事件库。项目尽管有其独特性，但借鉴从同类型的项目之间的经验教训提炼出来的知识是很十分有价值的。

在项目的收尾阶段，不仅是给项目的利益相关者一个正式交代，还有一个任务就是项目整个过程的经验教训予以提炼形成企业的知识财富[4]。企业的知识往往是隐含、散落在员工群体中，因此需要将员工的隐性知识转化成公司的显性知识。

结束语

项目管理虽然没有非常高深的理论，但要真正实施起来，也绝非易事。对于软件开发企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，从而在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。

参考文献：

[1]郑人杰等.实用软件工程[M].北京:清华大学出版社,.4.

[2]新产品开发项目中的需求问题[EB/OL].

[3]Roger S.Pressman;黄柏素,梅宏译.软件工程-实践者的研究方法 [M]. 北京: 机械工业出版社,,10.

论软件项目的质量管理 第3篇

关键词：软件项目质量；软件项目质量管理；需求；测试

1.软件项目质量管理相关背景

1.1 相关案例

美国项目管理专家资质认证委员会主席Paul Grace说过，在当今社会中，一切都是项目，一切也将成为项目。项目管理学科的发展，不管在国内还是国外，都进入了一个以超乎寻常的速度发展的阶段。软件项目管理作为一个新兴领域随着软件产业的蓬勃发展而愈发受人瞩目。而软件项目的质量如何对于这个软件而言是尤为重要的，所以想要提高软件项目的质量，就必须在项目的质量管理上狠下功夫。

在2005年的时候，日本东京证券交易所当时发生了一次非常严重的系统事故，导致所有的证券交易全部崩溃，在很短的时间里就造成了几千亿元的亏损。后来经过仔细调查，导致事故的原因竟然是当月交易系统的更新出现了问题。耗资如此巨大的软件系统本来就是为了进一步提高企业的工作效率，为企业创造更大的价值，更多的利润，但没想到因为一个小小的系统更新问题导致了如此惨重的损失，这一切都源于一个问题，就是项目的软件质量，如果软件质量出现了一点小问题，那么它造成的将是大后果。

1.2 相关概念

说到软件项目的质量管理，首先要弄清楚什么是质量。国际标准组织ISO9000对质量的定义是“一个实体的性能总和，它可以凭借自己的能力去满足对它的明示或暗示的需求”。所谓软件项目的质量，就是“软件项目能够满足已确定的全部需求的特征集合”，是能够满足软件项目在项目开始阶段确定的功能、性能等特点的总和[1]。它反映在一下三方面的信息特点：能达到客户的所有需求；运用合理的质量标准体系，来引导软件的开发；能否满足客户的隐性需求[2]。质量是构成社会财富的物质内容，没有质量就没有数量，也没有经济价值。

软件项目的质量管理的主要目的就是确保项目满足它所应满足的需求。从用户需求出发，保证最终交付的软件要满足客户的期望。质量管理的重点在事前的预防，而不是时候的检查，这就需要管理者在项目执行的全过程中持续坚持质量管理的理念，不断改进，使最终交付的软件产品满足客户明确需求、隐含需求的所有特性。

2.提高项目质量管理的方法

2.1加强人员的执行力和技术

对软件的项目质量造成影响的有这么几个原因，分别是技术、过程、人，而人大影响在这几个因素里是最大的很多时候导致企业缺乏核心竞争力的原因是执行力太差。对质量管理目的的偏差，是造成执行力低这一问题的很大因素。我们总是常常提到利润最大化这个词，如果开发公司不断盲目强调收益，而且是"用最小的投入获得最大的利益"。这会导致开发团队不得不最大限度地、甚至不择手段地去取得财务的增长，从而大大降低了他们的执行力。质量的目的只是为了解决销售，质量管理真正实现的根基就不存在。我们应当逐步让公司企业选择一种更和谐的盈利方式。使自己的开发团队去注重用户的感受，选择与客户、合作伙伴的长远利益。

人员的技术永远是质量过硬的最高保障，企业应当鼓励和奖励内部员工多去参加软件类的培训以及各种认证资格的考试，形成一个良性的竞争和学习环境，优胜略太，可以很大程度的提高企业员工的技术水平。

2.2清晰客户需求

清晰把握客户的需求是尤为重要的，在很多不成功的案例当中，很大程度就是由于企业不能清晰把握客户的需求。软件项目的需求决定了软件项目的功能和目标，目标不明确就没法制定下一阶段的工作计划，从而不能按质量完成整个软件项目。所以，如何真正把握客户的需求，是提高和确保软件项目质量的重中之重。

此外，软件项目负责人和需求的提出者应该尽可能早地分析项目的相关业务逻辑、明确软件项目的需求。项目需求明确的越早，就能够越早的制定开发计划，软件项目的开发质量就越容易得到保证。在项目的实施阶段，还需要对每个阶段的需求进行进一步明确，制定每个阶段的子计划，从而使得软件项目的开发得以分解。保证了每个子计划的开发质量，就能够保证整个项目的开发质量。

2.3 实施软件检测

在软件项目的质量管理工作当中，对于软件的检测是对软件的质量又有效的保障和最后的屏障。因为很多项目在实行的过程当中并不是十分规范，所以对于软件检测这一环节就更为重要[3]。检测一个软件项目在实行过程能否达到需求的逆向过程，是在整个软件开发过程中非常重要的环节。通过不同的检测环节，检测出各种错误环节来确保整个软件项目的质量，从而交付一个满意的项目成果给客户。

然而软件检测并不能发现所有的潜在问题，有些小的操作或功能方面的问题也许会在后期使用过程中出现，这是难以避免的，应该向使用人员提前说明，但是大的操作或功能性的问题绝不应该出现在正式运行过程中，是质量管理应当解决的问题。

2.4 进行代码走查

代码的质量很大程度上决定的软件的质量。编程人员在编写代码的时候，要高度认真负责，思路清晰明确，高质量的程序必须是高内聚，低耦合，同时也要结构合理，条理清晰。但由于在工作组中每个编程人员的编写代码习惯不同，能力差异，所编写出来的代码质量也有差异。所以，在软件开发过程中引入代码走查是相当重要的环节。在严格规定的时间内，让编程人员对其所编写的代码进行讲解和分析，不仅能促进编程人员提高编程水平，而且也可以经常内部交流，相互学习，更好的配合，从而提高和促进软件质量的提高。

3.结论

本文通过介绍了软件项目质量管理的重要性以及软件项目质量管理的内容， 重点研究了如何提高软件项目质量管理的方法，包括加强企业员工的的技术和执行力、清晰客户需求、实行软件测检测和进行代码走查这四种方法。近年来， 项目质量管理逐渐得到企业的重视， 但是要将项目质量管理更好的运用在实际的项目中，还有待于软件行业的不断发展和规范。加强软件质量管理的做法还有很多，质量管理的内容与执行也要时刻紧跟时代步伐，我们应当针对不同的项目采取不同的最适合本项目的方法，从而达到最好的效果。（作者单位：贵州财经大学MBA中心）

参考文献

[1]吴吉义.软件项目管理理论与案例分析 [M] .北京：中国电力出版社，2007：165.

[2]陈淦.也谈软件项目管理中的质量保证[J].福建电脑， 2006 （10）： 4. http： //www cnki com cn/Article/CJFDTotal-FJDN200610027 htm.

软件项目的时间管理 第4篇

由于项目具有一次性和独特性的特点, 因此在项目实施完后, 很多在项目实施过程当中积累起来的知识就会随着项目的结束而消失, 这个对于软件企业来说是一个很大的损失。因此随着软件企业的发展, 软件规模的扩大, 国内企业纷纷使用知识管理的理论、方法来提高项目管理的水平, 各个企业也纷纷引进或开发知识管理软件和工具帮助知识管理在组织的实施, 据国内最大的协同软件社区www.my EC.org的调查数据显示, 目前我国知识管理相关软件的厂商已经超过了500家, 然而, 这么多的软件厂商, 实施效果却不尽如意, 一些研究人员指出知识管理项目的失败率是70%, 这个比例已经总体高于其它软件项目的实施。很多企业实施知识管理, 不但得不到应有的效果甚至给我们带来了损失和伤害。

根据调查, 由于软件企业一般采用的是项目型或矩阵型的组织形式, 企业的运作一般也是以项目的形式来开展的, 由于存在路径依赖性, 软件企业在实施知识管理时, 一般也是按照项目管理的过程和组织形式进行的, 即对于每个知识管理项目的实施, 公司会任命一个项目经理, 负责项目的实施, 然后组建相应的项目团队进行项目的实施。所以知识管理的实施, 国内软件企业一般是采用软件项目的理论、方法来指导实施的。

我们知道, 国内外的软件项目管理, 采用的是软件工程的思想和方法, IEEE计算机学会将软件工程定义为应用系统化的、科学化的、定量的方法, 来开发、运行和维护软件, 并对各种软件开发、运行和维护的方法进行研究。软件工程将软件生命周期划分为需求、设计、构造、测试、维护等几个阶段, 每个阶段的产出物都需要明确相关的文档, 而且每个阶段都包含了项目管理的五个过程, 即启动过程、规划过程、执行过程、控制过程和收尾过程, 各个阶段是彼此联系的, 每一个阶段中的工作, 均以前一段工作的结果为依据, 并为下一阶段工作创造前提。可见, 软件项目管理是一套关于软件实施的方法、工具和组织管理, 是以工程原理来设计、构造计算机程序并编写供开发、使用和维护计算机程序所需文件资料的一门学科。

对于知识管理的实施, 是否也可以按照软件项目管理的方法来开展呢?为便于比较, 本文以Arthur Andersen公司的知识管理实施方法论为例, 比较知识管理的实施和软件项目管理的不同。

Arthur Andersen公司是全球顶尖的咨询公司, 主要从事会计与审计、税务、商务顾问、咨询服务等业务, 被评为“2000年最受推崇的知识型企业”之一。A r t h u r Andersen公司认为知识管理的引进是非常复杂的过程, 牵涉到战略、流程、信息技术、人和组织等四大侧面, 实施过程需要经过战略、设计、原型开发与测试、引进及评估与维护等六个步骤, 以及包括项目管理和变革管理。其实施框架如下:

Arthur Andersen公司认为知识管理具有跨学科、覆盖面广、多层次、影响因素众多的特点, 需要有一个非常完善的知识管理实施模式来指导项目的进行, 否则将无从依循, 导致知识管理项目的失败。

对比知识管理实施方法论和软件项目管理方法论, 结合作者的实践和调查, 它们存在诸多不同, 这些不同的因素可能会导致知识管理的失败:

1、两者涉及的范围不同。采用软件项目管理的方法实施知识管理, 会让人认为实施知识管理就是开发软件和实施软件, 把知识管理等同于软件实施, 这些人一般会认为只要知识管理的软件上了, 企业就可以实现知识管理了。但是我们可以看到, 软件项目管理只能解决知识管理软件和工具的开发、实施等的技术问题, 而要实施知识管理, 除了技术这个因素外, 还要涉及到文化、战略、组织和流程等因素的影响。项目管理在实施知识管理时是必不可少的, 它是实施知识管理的基础, 但不是全部。很多软件企业实施知识管理失败的原因, 就是过多重视技术的因素, 而忽略了其它必要的因素。

2、由于项目具有一次性的特点, 采用软件项目管理方法实施知识管理, 会认为知识管理的实施也是一次性的, 而把知识管理的运行、维护和更新排除在知识管理实施的范围之外。而实际上, 如果知识管理要想在组织内产生效益, 就必须让知识不断在组织内运转, 形成知识螺旋, 在螺旋中知识不断创新和积累, 从而让知识不断为组织所用, 产生强大的效益。由于很多软件企业把知识管理实施当作软件项目实施, 往往在项目完成后需要知识管理系统出效益的时候, 在管理上却处于空白的状态, 不能让它良好运转, 没有产生应有的效益。很多企业开发或引进的知识管理系统本身是很好的, 但却没有得到良好的利用, 使辛苦开发出来的知识管理系统成为摆设, 导致知识管理的失败。

3、由于知识本身具有是主观性、不稳定性、难以结构化以及背景相关性等的特点, 所以知识本身是比较复杂的, 并不像信息那样可以方便地显示和传递, 这样导致知识管理也是复杂的, 知识管理是一项复杂的系统工程, 涉及面非常广, 既是常规的项目管理, 同时也是变革管理。所有很多组织实施知识管理, 并不是一次到位, 而是分步实施、逐步实现的, 在实施知识管理时, 组织需要清晰的战略规划和长远的组织安排, 而项目管理方法论更擅长于如何把清楚的事情做对即“把事情做正确”, 并不擅长于模糊的事情。所以知识管理的实施, 需要多方面的思想和方法论的支持。

摘要：本文先分析了软件项目管理和知识管理的特点, 然后阐述了软件项目管理方法论和知识管理实施方法论, 并针对软件企业普遍使用项目管理的过程方法实施知识管理的状况, 分析了软件项目管理和知识管理实施的不同, 并分析了可能导致知识管理失败的原因, 以供知识管理实施组织参考。

关键词：软件项目管理,知识管理,实施

参考文献

[1]、软件工程知识体系指南 (2004版)

[2]、杰克.吉多.成功的项目管理[M].机械工业出版社, 2004.

[3]、IEEE Standard Glossary of Software EngineeringTerminology.2002

[4]、廖开际, 李志宏, 周勇.知识管理原理与应用[M].清华大学出版社, 2007.

软件项目管理的理论与实践 第5篇

摘要：本文在探讨CMM/CMMI、敏捷编程等相关理论的基础上，结合软件开发实践，提出了平衡敏捷与纪律的软件管理思想，并探讨了融合敏捷与CMM/CMMI的最佳实践。

关键词：CMM/CMMI，敏捷 当CMM遭遇敏捷

本世纪初，在国务院18号文件《鼓励软件产业和集成电路产业发展的若干政策》的推动，以及鼎新、东软等先驱软件企业的带动下，国内掀起了一阵CMM风暴（CMM于2000年升级为CMMI，文中在不特别针对某个具体版本时，使用CMM泛指CMM/CMMI），软件企业的CMM/CMMI评估形成了一股席卷全国的潮流。据CSDN统计，截止到2010年9月，我国通过CMM/CMMI评估的企业已达到1300家，全球排名第二。一时之间，CMM似乎成为了衡量软件企业开发能力的唯一标准，成了发展我国信息技术行业的银弹。然而，自2005年开始，一些有识之士就已经认识到CMM的局限性，纷纷撰文提出质疑。目前，随着越来越多软件企业CMM神话的破灭，CMM已经完全走下神坛。现在打开百度，搜索CMM的相关内容，除去概念、介绍性的文章外，对其持否定态度占了绝大部分，继续力挺CMM的文章几乎绝迹。由此可见，中国的软件界已经从CMM的狂热阶段转入理性阶段。

在CMM由盛转衰的同时，以强调人本、效率为核心的敏捷思想开始悄然兴起。从Kent Beck的极限编程（eXtreme Programing，简称XP）和敏捷联盟的敏捷宣言中，中国程序员开始听到CMM外的声音。而随着Martin Fowler、Robert Martin等敏捷大师登陆中国，数届敏捷大会在北京召开，整个中国软件界掀起了一股以务实、高效、简约为特征的敏捷风。目前，软件行业的媒体、杂志上，充斥着介绍XP、Scrum等敏捷方法的专题文章，秉承敏捷思想进行管理的软件企业随处可见，敏捷成了过程改进的最热门话题。

面对CMM的盛极而衰和敏捷的方兴未艾，我们不禁要问：CMM到底怎么了？敏捷真的适合我们吗？我们该何去何从？ CMM怎么了

我第一次接触CMM是2000年。在此之前，我一直试图寻找一套软件开发标准，曾经学习过GB 85-88和IEEE-830、IEEE-12207等软件工程标准，但一知半解，远没有形成一个系统化过程的概念。CMM的丰富、广博确实让我眼前一亮，好象打开了一面通向世界软件技术的窗户，看到了从未想象过的世界。但是，CMM那些繁复的规定和要求，又让我望而却步，“可远观而不可亵玩焉”。2002年，在信产部政策的推动下，各地方政府纷纷出台了奖励政策，稍具规模的软件公司，都在跃跃欲试地准备CMM评估，CMM才真正走到我们面前，虽然当时还不完全了解CMM到底能带给我们什么。

其后几年，CMM/CMMI成了我工作的一部分，我对它有了更深刻的了解。可以说，CMM是中国软件行业规范化的启蒙者。CMMI-DEV 1.2的22个PA、48个特定目标、165个特殊实践，覆盖到了软件开发和管理的方方面面，让我们真正了解到什么是软件管理。每个职业软件人，无论是开发者还是管理者，都有必要了解、掌握这些内容。作为一个指导软件企业过程改进的框架，CMMI提供了阶段型和连续型两种方法论，并通过5个通用目标、17个通用实践，清晰地描绘了一条软件企业走向成熟的路线。比如CMMI-DEV 1.2 Ⅱ级的目标，就是“管起来”，无论你用什么方法，只要把计划、度量、需求、配置、质量保证等内容管起来，就认为是达到了Ⅱ级。当Ⅱ级积累到一定程度，认为各项目间有必要共享各自的经验的时候，就可以向Ⅲ迈进了。遗憾的是，我们在引进CMM的过程中，犯了急功近利的毛病，囫囵吞枣，没有真正按照框架的精神踏踏实实地进行过程改进，导致了CMM的水土不服。究其原因，我觉得问题应该出在以下几个方面：

1.CMM的移植问题。CMM起源于美国国防部和国家宇航局，所针对的都是大型项目。这些项目失败的成本巨大，对软件质量要求非常之高，因此，对过程的精细程度要求非常之高。在制定模型时，为了做到方法的完备性，所制定的过程框架又涵盖了各种情形，使过程模型更加复杂化。在移植到中国后，由于评估时间等的压力，我们并没有充分地消化CMM的精髓，没有考虑我们企业所能承受的成本，没有根据项目的实际情况进行有效裁剪，而是僵化地全套照搬，建立了过于复杂的管理流程，形成了大量面面俱到却无人问津的过程制品，反倒失去了对项目核心的掌控，导致生产效率降低，产品质量下降。而过程改进人员又普遍脱离了开发实践，CMM成了教条，使开发人员产生了反感情绪。

2.CMM缺少工程方法。CMM是一个能力标准，只讲要做什么，却没讲怎么做。例如CMMI-DEV 1.2 Ⅱ级的7个PA，全部是项目管理的内容，基本未提及工程方法。CMMI-DEV 1.2 Ⅲ的11个PA，虽然涉及到RD、TS、PI等技术领域的内容，但只提了宏观要求，并未涉及细节。这种设计方式，是因为CMM的创建者假定软件企业已经具备了适合本企业的、完整有效的软件工程方法论。我国企业在引进CMM前，基本上还没有形成自己的软件过程和文档体系，而是寄希望于CMM来改善这种情况。在CMM实施中，又普遍存在重管理轻技术的观点，忽视了企业资产的建立，通常是照办咨询公司提供的模板，没有进行有效的本地化，没有认真探索适合自身的工程方法，从而导致管理先进、技术落伍的不良状态，也从根本上违背了CMM“过程改进”的基本思想。

3.CMM不适合小型项目。CMM起点很高，对各个环节要求极严，是真正的重量级方法。对周期短、回报小、资源不足的小型项目来说，使用CMM的成本太高，可以说是得不偿失。这一点，在CMM刚刚进入中国时，SEI的专家们曾反复声明，CMM的创始人Watts Humphrey老先生也一再强调。在CMM之后，Humphrey先生又建立了用于小规模团队的TSP（Team Software Process）模型和用于个人的PSP（Personal Software Process）模型，作为CMM的补充。在为波音公司的IT部门进行CMM咨询时，Humphrey先生根据各部门的实际情况，分别制定了实施CMM Ⅲ、CMM Ⅱ、TSP、PSP的不同方案。由此可见，CMM并不是放诸四海而皆准的银弹，无论是公司还是项目，选择CMM，都应该根据自己的实际情况进行理性的选择，而不应该生搬硬套，以命令的形式强制推行。反过来，如果选择了CMM，就要提供足够的资源，否则就会事与愿违，反倒降低效率，影响产品进度和质量。

4.CMM的知识更新问题。CMM初稿是在1986年提出的，87年正式发布1.0版。它的基本内容，都是基于瀑布模型设计的。按照《人件》和《最后期限》的作者Tom DeMarco的说法，“CMM 已经有超过 20 年的历史，它的成功经验都是在 1985 年前获得的。CMM 试图将一个固定的模型强加于一个日新月异的行业之上，它鼓励你效仿 IBM 在 1970 年代所采用的软件开发方式。僵化，不敢面对变化，这是如今的软件业最忌讳的。”2006年8月发布的CMMI-DEV 1.2版本，开始寻求对这一局限进行突破，但是进展甚微。例如，目前迭代式开发已经被公认是先进的开发组织模式，可以有效应对变化。而CMM在某些方面却限制了迭代的应用。比如里程碑式的需求评审、设计评审，就是典型的瀑布模型的影响，与迭代方法中随着开发的深入逐步获取需求的思路完全矛盾，造成了两者的冲突，客观上限制了基于迭代的新式工程模型的应用。

5.实施过程中理论和实际的脱离。国内的CMM实施，最头疼的就是找不到合适的SEPG和QA人选。按照CMM的思想，SEPG和QA应该来自具有丰富开发经验的技术人员，能在开发过程中得到软件人员的尊重，并给予全方位的指导，从而得到客观的洞察力。而我们的软件企业通常比较年轻，人才积累少，SEPG和QA的软件经验普遍不足，兼之过于追求理论上的完美，不注重跟踪过程执行情况，不注重收集反馈信息，导致我们的流程、制度脱离开发实际，引起开发人员反感。正如软件界泰斗Boehm博士所说的那样，“过程改进黑暗面的诱惑力是巨大的，实施者们很容易受其诱惑而陷入只追求表面文章的黑暗面之中”。这样的过程改进只注重满足标准，片面追求过程与规范的符合度，脱离了软件开发实践，忽略了实践对理论的验证、反馈，违背了过程改进的初衷，偏离了提高效率、提高软件质量的根本目标。敏捷的特征

以CMM为代表的传统意义上的软件方法学描述，通常“能够”处理任何大小的项目，而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象，敏捷方法应运而生。相对于CMM这样的重量级方法，敏捷方法常被认为是“轻量级”方法。敏捷的倡导者认为，软件产品开发无法一开始就能定义产品最终的规程，开发过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。开发团队应有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

相对于传统方法，敏捷方法更重视“人”在软件研发中的作用，重视效率，重视对变化的积极响应，倡导迭代式开发，反对机械地盲从既有过程，反对面面俱到、堆积如山却无人问津的文档。自1996年敏捷先驱Kent Beck提出极限编程思想后，敏捷方法得到了广泛响应，敏捷爱好者于2001年成立了敏捷联盟，并发表了敏捷宣言：

 注重个人及互动 胜于 过程和工具  注重可用的软件 胜于 详尽的文档  注重客户协作 胜于 合同谈判  注重响应变化 胜于 恪守计划

2002年后，敏捷方法得到了迅猛发展。其中影响至深、波及至广的当属极限编程（XP）和Scrum方法。

极限编程是敏捷理论的先驱，“极限”的含义是将在开发中总结的最佳实践发挥到极至。例如，如果你认为迭代是好的，那么就将迭代的周期压缩至最小，甚至几天、几小时一次迭代。严格来说，极限编程并不是一套完整的方法论，而是一组核心理念和一套最佳实践的组合。XP倡导沟通、反馈、简单、勇气四个核心价值观，主张项目的设计、结构要保持简单，要注重沟通和用户反馈，要有勇气接受变化、重构代码。XP提出了项目计划（The planning game）、小版本（Small releases）、隐喻（Metaphor）、简单的设计（Simple design）、重构（Refactoring）、测试驱动（Test-driven）、结对编程（Pair programming）、代码共享（Collective ownership）、持续集成（Continuous integration）、不加班（40-hour week）、现场客户（On-site customer）、编码标准（Coding standards）等十二个核心实践，其中重构、测试驱动、小版本（迭代）、持续集成等实践已经成了敏捷思想的核心，被现代软件工程理论广泛接受。XP作为敏捷方法的先驱，最大贡献是为敏捷方法提供了大量基础实践。它的基本思想被各种敏捷方法广泛接受、继承，为敏捷的盛行奠定了基础。

Scrum方法的名字取源于英式橄榄球争球队，其用意就是要把体育比赛中那种团结、拼搏的精神施加于软件团队。和XP相比，Scrum提供了更具体的工程管理机制，从而使Scrum的可操作性更强。这也是近年来Scrum方法盛行的原因。Scrum方法的核心，是将开发过程分解为一系列小的迭代，每次迭代称为一个Sprint（冲刺）。每个Sprint通过计划会议明确任务，通过每日例会掌控进度、问题，通过评审会议总结成果。如此反复，经过一系列可控的“冲刺”，最终达成项目目标。其基本流程描述如下：

1.列举可以预知的所有任务，包括功能性和非功能性任务，形成所谓Backlog。2.将整个产品的Backlog分解成一系列Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。3.召开Sprint计划会议，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。Sprint的任务是以小时计算的，并不是按人天计算。

4.进入Sprint开发周期，在这个周期内，每天需要召开15分钟的每日Scrum例会。5.整个Sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。该会议为外部会议，邀请干系人参加，一般不超过4小时。

6.团队成员最后召开Sprint retrospective meeting，总结问题和经验。该会议为内部会议，时间不超过3小时。

7.这样周而复始，按照同样的步骤进行下一次Sprint。

无论是XP还是Scrum，其基本思想都是互通的。它们所倡导的最佳实践，看似一个个独立活动，实际上具有很高的耦合度，不能孤立地执行。例如，XP的共享代码权，如果没有编码标准、结对编程作为基础，是很难实现的；小版本没有重构作为保障，会导致结构的混乱；Scrum的每日例会，要以“站立会议”的方式进行，以保证效率；Scrum的Sprint要以持续集成、重构等实践作为保证，否则无法维护产品的完整性和可靠性，等等。

敏捷以一种充满活力的方式，挑战了传统软件工程思想的沉闷，激起了全球软件人员的强烈反响。然而，任何事情都有其不利的一面，敏捷也是如此。敏捷无法管理大型项目，即使对比较适合敏捷的中小项目来说，敏捷也有自身的弱点，例如：

1.敏捷过于依靠个人素质和Team leader的领导能力，因此在团队成员较新，缺乏足够的经验、技巧和敬业精神时，敏捷会失效；

2.敏捷经常会被误解成不写文档。事实上，敏捷反对的只是面面具到、求全责备的文档和过程，而不排斥必要的文档。例如XP的12个核心实践，就提到项目计划、隐喻和简单的设计三个涉及文档的活动。敏捷只是提倡用一种更直接、更轻量、更易于理解的方式编写文档，而不是一概否定文档。

由此可见，以CMM为代表的传统方法和敏捷思想实际是事务对立统一的两个方面。传统方法强调过程、强调纪律，而敏捷方法强调个体、强调创造。如果将两种思想有机结合起来，取长补短，达到平衡，就能找出更合适的过程改进之路。平衡敏捷与规范

在敏捷与传统为谁是谁非的问题争论的不可开交的时候，一些有识之士已经在考虑两者的融合。其中比较有代表性的一位，是以创造了COCOMO模型、螺旋模型和经典名著《软件工程经济学》而闻名的Boehm博士。Boehm博士在2003年出版了《Balancing Agility an Discipline》一书，对平衡敏捷和规范的问题进行了详细的论述。该书的中文版《平衡敏捷与规范》也已经于2005年由清华大学出版社出版。可见，平衡敏捷与规范，已经是被国内外学者所认同的发展之路。敏捷与规范之争，大致可以归结为以下两个方面：

1.人与过程孰重孰轻之争，或者软件到底是“工程”还是 “艺术”之争； 2.质量尺度的把握，或者说，需要为质量付出多少成本。

人与过程之争，焦点是软件开发过程创造性的地位问题。CMM把软件开发过程看作一个工程过程，希望利用在制造业等传统行业中获得的经验来管理软件开发，对开发中的“个人英雄主义”行为持明确的否定态度，倍加推崇正确的过程、严格的工序和绝对的纪律。而敏捷方法的核心就是强调发挥个人或团队的创造性，主张按照项目特点选择过程。在敏捷专家看来，没有什么规范是固定不变的，所有过程都由人而定，都是为项目成功服务的。敏捷和规范各有所长，以CMM为代表的规范过程更适合需求明确的大型项目，而敏捷更适合具有挑战性的研究项目。

质量尺度的把握。CMM强调质量至上，不会因为效率牺牲质量。敏捷强调效率，一些敏捷方法提出了“满意质量”的概念。满意质量基于“任何事情都带来成本，而我们所想要的总是超过我们的支付能力；质量在本质上是有条件的和主观的；为了在软件方面达到完美，我们不得不解决许多困难问题、达成许多折衷和解决相互冲突的价值，完美不会很容易或机械性地实现”的基本前提，提出了满意质量的定义：（1）可带来足够的利益；（2）不存在致命性问题；（3）所带来的利益超过问题所造成的损失；（4）在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。满意质量否定了质量至上的观念，说明了敏捷思想更加务实的价值观。应该说，CMM的质量目标更适合作为一种文化或信念，而满意质量是对质量目标更理性的思考，更具有说服力和实用性。

敏捷强调个体、强调效率，但同时对个体素质要求较高，局限性较大。而CMM强调过程，强调质量，更适合于简单、重复的生产活动，很难应付复杂多变的情况。事实上，敏捷与规范正是软件开发过程中两个不可或缺的方面。过分强调自由，开发过程就会失控，回到软件危机前的“混沌”状态；而过分强调规范，又会导致僵化，扼杀人的主动性和创造力。因此，软件管理的目标，就是平衡敏捷和规范的矛盾，使开发活动高效、有序地进行。对已经通过了CMM/CMMI评估，但仍希望持续改进的软件企业，我觉得最直接的平衡方法，是用敏捷的观点重新审视既有规范，用效率观点重新评价各种管理活动，逐步剔除其僵化、低效的部分，最终达到平衡。具体方法可概括如下。

1.对项目分类进一步精细化，提供更丰富的生命周期模型，并提供与之相适应的模板和规范要求，使之能够尽量适应不同类型项目的情况。通过CMM/CMMI评估的企业所采用的流程规范，大多是继承自咨询公司提供的模板。虽然在改进过程中有适当裁减，但并未真正接受实践的检验，而且普遍不能支持新的生命周期模型。要想让规范更好地支持开发过程，帮助企业提高开发效率、产品质量，就应该不断吸纳新知识、新思想，不断建立新模型，使企业资产库不断得到扩充。另一方面，企业资产库对开发部门应该是开放的。开发人员是推动企业知识更新最积极的因素，管理人员应该积极支持、帮助、配合项目组使用创新方法、过程，认真跟踪、观察新方法的执行效果，及时总结经验教训，将新方法及时合并到企业资产库。

2.提供更灵活的裁减条件，减少不必要的中间环节，给予项目经理更多的控制权限。任何过程都有其局限性，而每个项目都有其特殊性，不可能通过机械地复制既有过程就达到复制成功的目的。这一点，SEI的专家也是认同的，CMM的Ⅱ级命名为“可重复级”，升级到CMMI时更名为“管理级”，就隐含了这个道理。软件不同于简单的生产加工活动，是一个充满挑战和创造性的工作，软件管理也不可能完全照搬企业管理的经验，而必须强调“人”，特别是项目经理在整个过程中的主导作用。给予项目经理更多的控制权限，尤其是过程裁减的权限，更有利于发挥项目经理的聪明才智，引导项目走向成功。这是敏捷思想的精髓所在。对开发过程中的管理活动，要深入分析其对具体项目的作用，才能作出是否需要的合理判断。以专家评审为例。理论上，专家评审可以集中专家的智慧，对开发活动肯定是有益的。但某些企业由于环境、业务复杂度、技术复杂度、人际关系等等原因，专家可能不愿意或没能力提供有效意见，这样评审就不能达到预期目的。如果评审成了走过场，就要引发深度思考，考虑评审所带来的收益是否大于付出的成本，并决定是否裁减评审活动了。裁减的最终决策权应该交给项目经理，而不是SEPG人员。因为项目经理要对项目总体负责，只有他最了解、最关注项目的成本、进度、质量，其它人员的意见都具有局限性、片面性。

3.管理体制要从实践中来，到实践中去。所有针对软件开发的管理活动，都是为了让开发工作更有效、更可靠、更可控，都是为开发服务的。敏捷的最大魅力，就是所有最佳实践都是来自于开发活动的，所以才会得到开发人员的广泛拥戴。因此，管理制度的制定，尤其是过程、文档模板的制定，要坚持实践是检验真理唯一标准的原则，坚持从开发实践中总结经验，积累财富。要杜绝闭门造车式的过程改进，无论多么完美的理论，都要经过实践检验后，才能验证其正确性。软件管理人员必须具备软件开发经验，并不断深入开发实践，体会规范的实际运用效果。管理规范要经过实践检验后才能形成制度，并且要考虑是否能为开发人员所接受，所增加的管理成本是否物有所值等因素。如果脱离了实际，制度就会僵化，变成阻碍开发工作的束缚，达到适得其反的目的。

4.发现问题，量体裁衣，逐步实现过程改进。罗马不是一天建成的，任何进步都要有一个普及、接受、适应的过程。CMMI 的组织过程焦点（OPF）明确地列举了组织过程改进的方法。在CMM实施阶段，由于时间的压力，企业可能没有真正按照CMM的精神来实施过程改进，急于求全、求大，或多或少地存在制度与实际两层皮的情况。要改变这种状态，应该坚持持续改进的精神，改进要按照OPF的要求，评价组织过程，发现最薄弱环节，找出最紧迫的过程改进需要，制定改进计划，实施过程改进。按照这种方式，即使每次改进仅完成一个PA，只要真正落到实处，就会取得实际的进步。如此反复，企业就会得到真正的发展。如果违背了这个规律，一味求大求全，浮于表面，过程改进可能永远是一句空话。5平衡管理与技术

在平衡敏捷与规范的讨论中，还有一个不容忽视的问题，就是平衡管理与技术的关系。软件是一个技术密集型行业，是一种纯脑力劳动，技术对于项目成功的重要性，是不庸质疑的。在CMM登陆之前，我们普遍存在重技术、轻管理的现象。CMM作为一个管理框架，重点在于强调管理，正是对片面强调技术的纠正。然而，随着CMM思想的不断深入，又难免产生矫枉过正的情况，反倒让软件企业忘记了立身之本，忽略了技术的地位，造成管理至上的错误。管理与技术孰轻孰重？如何摆正管理与技术的关系？要想平衡管理与规范，这些问题都是不可避免的。

1.软件开发活动中技术的地位问题。软件不同于传统企业，软件产品的形成过程，主要依靠人的思维活动，是看不见、摸不着的。管理的目的，是为了引导人的思维活动按正确的方式发展，但是决不能替代人的思维。有人说，产生文档的根本原因，来自于项目经理的恐慌，因为项目经理无法感知、控制软件项目的进度和质量，只能依赖文档来进行监控。如果忽视了技术、技能的培养，忽视了软件人员的素质建设，思维就失去了基础，仅仅依靠管理、纪律，是不可能获得成功的。尤其在客户要求日益复杂、技术日新月异的今天，技术的重要性越发突出。一个良好的设计思路、技术决策，往往是觉得项目成功的关键。因此，应该正确认识技术在软件活动的地位，尊重知识，尊重技术，让管理为技术服务。

2.客观分析企业的状态。管理和技术是保证项目成功的两个决定因素，不能偏废。作为企业领导，要实现过程改进，就要客观分析企业的状态，分析清楚企业现在的弱项是管理还是技术，然后再制定相关政策，而不能想当然地片面强调某一方面，加剧不平衡状态。我个人认为，在没有实施任何认证的企业，忽视管理的可能性较大；在通过了ISO9000、CMM的企业，则往往夸大了管理，忽视了技术。

3.客观分析管理和技术的分别。面对企业在开发过程中暴露出来的问题，要进行客观、深入的分析，判断是管理问题还是技术问题，再采取相应措施。比如现在普遍存在的需求失控的问题，从表面上看，是需求开发（ReqD）和管理（ReqM）的问题。但是，如果深入到问题本质，可能会发现，需求变更是不可避免的。那么，就要从架构设计和开发过程方面找问题。例如可以采用组件式开发，让软件易于适应变化；可以使用原型法，让用户尽早看到产品；或者使用迭代式开发，及时规避风险，让产品逐步接近用户目标。如果死钻牛角尖，一味在需求调研、文档、评审上下功夫，就会事倍功半，降低效率。

4.注重技术人才的培养。“盖成非常之事，必待非常之人”。两千年前的汉武帝，就已经认识到人才的重要性。正是因为具有不拘一格用人才的非凡气魄，汉武帝才能挖掘出卫青、霍去病这样的军事天才，建立不世之功。在软件行业，也不乏盖茨、裘伯军、王江民这样以一己之力获得巨大成功的先例。因此，软件研发，尤其是开拓性软件的研发，必须要有大批具有专业知识、超凡能力的“非常之人”。软件企业要具备容纳百川的胸怀，重视技术人才的挖掘、培养，提供钻研技术的环境，打造尊重技术的企业环境，造就技术过硬的拔尖人才，才能提高自身素质，建立企业的核心竞争力，在市场上保持竞争优势。结束语

前文在剖析CMM的利弊的基础上，用敏捷观点重新审视了过程改进的方法，并阐述了软件企业中管理和技术的关系。最后，我们再回顾一下敏捷宣言，权作本文的结束语吧。

 注重个人能力，注重创新，注重互动，反对僵化的过程和低效的工具  注重编写好用的软件，反对面面具到却无人问津的文档  注重客户协作，避免生硬的商务谈判

浅析软件项目管理的进度计划与控制 第6篇

关键词：软件项目管理；进度计划；进度控制

中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2013） 01-0248-02

随着经济的快速发展和社会的进步，信息技术迎来了飞速发展的契机，对软件的开发已经不再仅仅局限于个人小作坊式的方法，而且这也不适合软件行业的发展。当前的软件开发正向大规模的方向前进，开发团队的人数也呈逐渐增大的态势，因此，如何有效对软件项目进行管理，就成为当前摆在人们面前的一个很大的问题。而其中软件项目管理的进度计划和控制更成为了其中的关键。鉴于此，本文在对相关概念探讨的基础上，对项目管理的进度计划与控制进行分析，希望可以为实践提供一定借鉴。

1 软件项目管理概述

进行软件项目管理有何意义呢？软件项目管理是一项为了能够使软件项目按照先前制定的进度、预算成本、质量等的完成而对项目中的质量、成本、人员、进度等进行分析与管理而进行的活动。软件管理最主要的作用之一就是让管理者完全详细的掌握整个项目的生命周期的过程。项目的生命周期包括任务的分析、设计、编码、测试以及维护这些环节，使软件产品能按期、按质在计划的成本下交付用户使用，以达到预期效果。

项目的生命周期可划分为四个基本阶段，即概念阶段、开发阶段、实施阶段和结束阶段，项目在不同的阶段，其管理的内容也不相同。概念阶段和开发阶段的主要工作是形成项目开发计划，实施阶段和结束阶段的主要工作是根据项目开发计划开展实际工作。项目开发计划制定必须是合理、可行的。项目团队要严格按照计划完成项目研发的工作，没有特殊因素，不可随意对计划进行更改。

软件项目管理的内容主要包括人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。本文主要探讨的就是软件项目计划方面的内容。

2 项目管理的进度计划与控制

制定合理的项目进度计划对于一个项目的执行具有非同凡响的重要作用。软件项目因其自身的特点和实际中的某些不可预测因素的影响，从而导致一般情况下项目进展难以与预先制定的计划相同。为了能够保证项目按计划实施，在执行计划时必须对项目进行跟踪控制。

软件项目管理的进度计划与控制，显而易见，包含进度计划和进度控制这两个主要内容。项目进度管理机制的主要职责是制定科学的进度目标，编制合理的资源供应计划和进度计划，从而控制项目的进度，在保证项目质量与成本目标相协调的情况下，达到项目的既定目标。

2.1 项目进度计划。众所周知，项目管理始终离不开质量、成本和进度这三个要素，因此，对软件开发项目的进度计划制定也是围绕这三个要素。而软件开发项目的进度计划制定一定要慎重，它关系到整个项目实施的成败。

项目进度计划是按照实际条件和合同要求，以拟开发项目的交付使用时间为目标，按照合理的顺序安排实施日程。其主要作用是把事先预定的项目各环节需要的时间按照先后顺序组合在一起，通过调整各环节的实际使用时间，使整个项目在时间和成本允许的范围下进行安排任务。

（1）制定进度计划的依据。在制定进度计划时，其主要依据有以下几方面：项目的目标范围、对工期的限制、项目自身的特点、项目结构分解单元，项目对各项环节工作的时间估计及项目的资源供应状况等。制定进度计划时必须要考虑到项目的成本、质量、安全性等各重要因素，客观的认识自身的条件，慎重进行风险预计，确保实现项目目标。（2）编制过程。在编制进度计划前，应对项目结构进行详细的分析，系统地掌握整个项目的结构构成的每一个实施细节，系统科学的分解项目。根据工作分解结构（以下简称“WBS”）原理来对项目进行结构分解。WBS是一个将项目按照内在结构和实施的时间顺序进行组层分解的分级的树型结构示意图。WBS分解的目的是将项目分解成内容相对独立的、易于成本检查与核算的工作单元。这样可以方便将具体的工作任务落实到人，方便工作进度的执行。进度计划方法。制定进度计划的方法主要有甘特图、计划评审技术和关键路径法三种。1）甘特图反映的是各种任务活动和日历表的对照图，它是由美国工程师在20世纪发明的方法，它主要用于跟踪软件开发项目的活动、阶段和任务的进度完成状态。2）计划评审技术的理论基础是假设项目的完成时间是随机的，并且服从某种概率分布。因此，可以估计出项目在计划内完成目标的概率。3）关键路径法一般指出一条关键路径从项目开始到结束由各项活动组成的不间断活动链，用于确定软件项目的起始时间和完工时间。关键路径上的工作项目在资源上享有最高的优先权。因为延迟任何关键路径上的开始时间都会造成项目工期的延迟。

2.2 项目进度控制。项目进度控制就是通过在预定的里程碑处（或项目进度表、工作分解结构中的控制级别），将实际进度与计划进度进行比较并分析结果，在保证项目工期不延迟，项目的质量不低于计划，项目成本最少的前提下，给出合理的对策，对项目进度进行更新。分析进度偏差和进行进度计划更新时项目进度控制的主要工作。

（1）进度偏差分析。项目进度偏差可以通过里程碑进度、人为设定活动进度、工作单元进展、挣值等进行分析。1）里程碑进度用于对项目总体进度的跟踪，尤其是对项目交付日期的持续跟踪。这里的里程碑指的是软件开发项目生存周期内的阶段节点，这种方法对里程碑的进度延迟量进行度量的计算公式为：里程碑进度差异=（第i个里程碑的进度延迟，单位：天）/（项目该阶段的工期）。2）人为设定活动进度用于对软件项目阶段的内部进度的跟踪控制。为测量和跟踪阶段内部的进度，该方法对软件项目阶段内的里程碑点赋予进度百分比预算值。3）工作单元进展是跟踪项目阶段的工作单元的完成状态。任务完成率定义为已经完成的工程任务数与计划应完成的工程任务数的比率。该方法利用的详细WPS的底层任务节点及其进度的计划值来观测任务的完成状态。4）挣值法用于对软件项目阶段的内部工程任务进度与成本完成状态的跟踪。该方法主要利用详细的WPS的底层任务节点的估计值以观测与评估任务进度与成本的完成状态。（2）进度计划更新。对项目进度计划进行更新，首先要分析进度偏差给项目带来的影响，然后再按照偏差影响对项目进度计划进行更新。1）进度偏差影响。对进度的偏差结果进行分析，判断出现进度偏差的活动是否为关键活动，进度偏差是否大于总时差，进度偏差是否大于自由时差等几个方面，给出偏差对后续活动及总工期所带来的后果。项目管理人员在掌握这些详细情况后，可以采取科学合理的调整进行更新措施，使其更符合计划进度。2）进度计划调整。按照进度偏差的影响，项目进度计划的调整一般分为关键活动调整、分关键活动调整、增减工作项目以及资源调整等四种情况。关键活动调整，对关键路径，由于其中任一活动的持续时间都影响着整个项目的工期，因此是进度更新的重点；非关键活动调整是在非关键路径上某些活动的持续时间在允许的范围内延长或者提前时不会影响到整个项目工期，从而不必调整进度计划；增减工作项目是指在编制计划时由于考虑不周等某些因素的影响需要增加或取消一些工作，应分析此项调整是否会影响到项目工期。若影响到工期，提出对策消除影响；资源调整是指在资源供应出现异常时，对供应资源进行调整。资源调整的目标是使项目工期不变或使工期更加合理。

3 结语

软件项目管理的进度计划与控制对软件项目实施来说，其重要性不言而喻，本文主要论述了进度计划管理方面的内容。软件项目的实施可按照自身情况的特点，适当参考本文中关于进度计划与控制的论述，希望能对项目实施有所帮助。

参考文献：

[1]薛保菊.谈软件开发项目的进度控制[J].科技情报开发与经济，2006，16（18）：233-235.

软件项目管理中的需求管理 第7篇

关键词：软件工程,需求管理,软件项目

1 背景

1.1 需求管理的概念

理解需求管理的第一步就是对什么是需求管理达成共识。Rational把需求定义为“(正在构建的)系统必须符合的条件或具备的功能”。

由于需求是正在构建的系统必须符合的事务,而且符合某些需求决定了项目的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的。换句话说,需求管理就是:一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

1.2 需求管理在软件项目管理中的地位

简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求,达到目标的几率就会降低。以下最近收集的证据很有说服力:Standish Group 从1994年到2001年的CHAOS Reports证实,导致项目失败的最重要的原因与需求有关。2001年,Standish Group 的CHAOS Reports报导了该公司的一项研究,该公司对多个项目作调查后发现,百分之七十四的项目是失败的,即这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是“变更用户需求”。

在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,在软件项目管理中需求工程是软件开发的第一步,是关键的一步,也是最难把握的一步。需求管理做得好坏直接影响到软件的质量,甚至软件项目的成败。从软件的项目立项、研发、维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能、优化性能、提高用户友好性的要求。在项目管理过程中,项目经理经常面对用户的需求变更,如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

2 需求管理现状

随着信息时代的发展,计算机软件的需求愈来愈复杂,规模愈来愈大,而且随着企业的发展,工作过程重组,需求变更已愈来愈成为必然。软件危机持续了30年之久,至今仍无法得以很好地解决。究其原因,软件本身具有的特点固然有关,但长期以来,缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。其中软件开发和维护方法的不正确性主要体现在:忽视软件开发前期的需求分析;开发过程缺乏统一的、规范化的方法论的指导;文档资料不齐全或不准确;忽视与用户之间、开发组员之间的交流;忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。

这样,就经常出现用户对“已完成”系统不满意,软件产品的质量经常出现漏洞,补丁一大堆。因此人们意识到以工程化的原则和方法组织软件开发工作是解决软件危机的一个主要出路。

需求分析作为软件生命周期的第一个阶段,并贯穿于整个软件生命周期,其重要性越来越突出,到20世纪80年代中期,逐步形成了软件工程的子领域需求工程。进入20世纪90年代后,需求工程成为软件界研究的重点之一。从1993年起,每两年举办一次需求工程国际研讨会(ISRE),1994年起,每两年举办一次需求工程国际会议(ICRE)。一些关于需求工程的工作小组相继成立。

3 存在的问题

3.1 需求描述的细致性问题

在文章的开头就说明了软件需求在整个软件系统开发中的重要性,正是由于它的重要性,一般来说,需求描述越详细越好。项目的开发方与用户在各种问题上的要求都是基本轮廓达到一致即可,具体的细节可以以后再填充,这是一种非常危险的思想。不管需求分析做的多么细致,以后对需求的变更都是必然的。另一方面,在需求分析阶段,开发人员希望再多投入一些时间,但是用户却不这么认为,因为需求阶段是软件系统开发首先要进入的阶段,离最终开发出可用的系统还有很长一段距离,这导致了双方的不一致。但如果在需求阶段投入很多时间,时间越长,可能的变化就越多,对设计的限制越严格,因此在需求描述的问题上,没有统一的界定,需要开发人员学会适当的把握。

3.2 需求描述的正确性

软件开发是一种专业行为,一般的业主难以理解软件开发人员的开发理念。所以在和业主交流时,他们讲述的需求在实际中利用现有的技术是实现不了的,用户以为自己很清楚自己的需求了,但实际上他们只是依据当时的工作需求提出的。随着开发工作的不断进展,用户可能想到更多的功能和特色,进而对以前的需求进行改动,导致需求的不一致。

另外一种情况就是开发人员和业主交流时,由于业主本身对需求的描述不清晰,导致开发人员误解或曲解了业主最初的要求,最后开发出来的系统不是不能满足用户,就是一个发生需求错误的系统。事实上这种错误在需求阶段也会经常发生。更可怕的是,对于需求阶段出现的错误,如果在软件项目进行到后期的时候才发现,修复费用是非常可怕的,甚至会超出项目本身的费用。因此做好需求管理、减少需求错误的出现对于降低软件项目的成本是必要的,也是至关重要的。

3.3 需求描述的完备性

系统的需求是层出不穷的,我们不可能做到把所有的需求都一一列举出来,并且随着时间的推进,用户的需求也会越来越多,要穷举需求是不可能做到的。另外,并不是用户提出的所有需求都要满足,在项目的最后,改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处。

3.4 需求的变更

需求的变化问题是每个开发人员、每个项目经理都遇到的问题,也是最头痛的问题,一旦发生了需求变化,你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等,需求的变化好比是万恶之源,为项目的正常的进展带来不尽的麻烦,怎么办?管理它!使需求在受控的状态下发生变化,而不是随意变化,需求管理就是要按照标准的流程来控制需求的变化。难题随之而来,需求中的变化一般不是突发的革命性的变化,最常见的是项目需求的渐变(Project Scope Creep)问题,这种渐变很可能是客户与开发方都没有意识到的,当达到一定程度时,双方才蓦然回首,发现已经物是人非,换了一番天地。

4 解决问题的策略

4.1 对需求文档版本控制

客户签收的所有过程文档都要作为基线确定下来,做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线,需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档,这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后,都要重新确定新的需求基线,以免将来用户需求发生变更时,原来的需求无法查找。为有效进行需求变更控制,必然要做的工作就是保存好各个版本的需求基线,维护需求基线文档,以备不时之需。

4.2 正确认识需求变更

在软件开发过程中有这样一条真理:需求的变化是永恒的,需求不可能是完备的。软件开发的过程实际上是一个变化的过程,需求的变更不一定是坏事,也有可能是好事。

变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动。

需求变更贯穿了软件项目的整个生命周期,通过建立规范的变更控制流程,改进软件分析与设计,把变化纳入计划之中,在应对需求变更时可以更加的从容和有信心。

4.3 管理需求变更

变更控制不应该只是软件开发过程应该考虑的事情,随着软件产品的开发和时间的推进,用户会提出越来越多的新需求,甚至在交付软件产品的最后阶段用户还会有不同的需求,因此需求变更的管理应贯穿于整个项目生命周期的全过程。

为了使变更对项目的影响降到最小,就应当采取合适有效的变更控制策略,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程。对需求的变更的处理应该分以下几个步骤:提出变更、变更评估、实施变更、监督变更过程。

4.4 建立需求管理模型

需求建模是表达需求的一种形式,是对需求的一种描述与阐释,它使用标准的语言,利用类似积木的概念来建模,最大的好处是大家可以直接根据需求,轻易地反复修改需求模型。并且不会产生歧义,从而可以使大多数人快速地理解。

需求建模的目的是要消除人际沟通随意性很强的弱点,所以需要致力于将沟通标准化、自动化、准确化,而且责任到人负责的具体阶段。具有可测试、可验证性的特点。建模的过程就是通过需求的特点和要求进行分析,以建模标准为基础进行准确、完备和有效的阐述,以确保客户和开发方都能够明确无误地、通用的理解。

4.5 与用户充分沟通

在需求管理过程中与用户的沟通很重要,因为它直接决定着最终软件产品是否满足客户的要求,即很大程度上决定着项目的成败。在沟通时,双方对需求的认识要一致,不能模棱两可。

讨论需求及变更需求时,需求人员与客户及用户应该尽量采取协作的态度,良好的工作氛围也会提高工作效率,很难想象双方在“刁难”与“对付”的态度下是多糟糕的工作场景。确定需求基线的过程也是与客户用户交流的过程,而频繁大量的需求变更在很大程度上也是交流不充分的后果。所以,有效的充分的交流尤为重要,需求人员认真听取客户用户的要求,进行分析和整理,并最终取得用户的确认。

4.6利用需求管理工具

需求变更控制委员会可以采取商业化的需求管理工具,以此来在数据库中存储不同类型的需求。这些工具提供了对每项需求的属性描述、状态跟踪等,并可以在需求与其它的相关工作产品间建立跟踪能力联系链。

5结束语

需求管理是需求分析过程中的一个步骤,是一个持续的不断完善的过程,软件项目开发过程中需求管理的问题有很多,随时都有用户需求变更,需求分析的错误也时常发生,需求质量难以保证,针对这些问题,如何采取有效的措施尽可能减少这些问题可能给项目造成的影响也显得尤其重要,另外关于需求的质量问题,怎样结合CMM标准进行需求的质量管理,有效提高软件的总体质量水平也是需要关注的问题。

参考文献

[1]陈丽杰.浅析软件项目管理中的需求管理.科技资讯,2007NO.14.

[2]苏兴华,方明.软件需求变化及对策.软件工程与标准化,

[3]姬晓鹏,吴朝晖.需求管理的一个系统解决方案,计算机工程,2003.11.

[4]江小丁,王朝晖.软件项目需求管理的研究.计算机与现代化,2006NO.2.

时间管理在软件项目中的应用 第8篇

项目时间管理是指为保证项目各项工作及项目总任务按时完成而执行各项工作的综合管理过程。项目时间管理就是采用科学的方法确定目标进度,编制项目计划,进行进度控制,在与质量、费用目标协调的基础上,实现项目工期目标。项目时间管理是一系列科学的工作过程,它能有效避免目前软件项目普遍出现的工期拖延、进度失控等问题,是保障软件项目顺利进行的基础。

2 时间管理的过程

项目时间管理的主要工作包括:活动定义、活动排序、活动工期估算、进度安排、进度控制几个方面:

2.1 活动定义

项目的活动是指为了完成项目而必须进行的具体的工作。项目活动是分析进度状况、编制进度计划和控制进度的基本工作包。活动通常出现在工作分解结构中,有预计的工期、成本和资源要求。

活动定义的主要输出是活动清单、活动属性、里程碑清单和请求变更。其中,活动清单是项目进度中的活动列表,其内容应包括活动名称、活动标识或者每项活动的号码以及活动的简短描述。活动属性显示与进度相关的信息,例如前导活动、后续活动、资源需求、逻辑关系、提前和滞后、约束、强制日期等。里程碑是完成项目阶段性工作的标志,通常指一个阶段性的可交付成果的完成,它是项目中的重大事件,只是一个时间点,在项目过程中不占资源。

2.2 活动排序

活动排序:是指通过分析项目活动清单中各项活动之间的联系和依赖关系,据此对项目各项活动的先后顺序进行合理安排,以确保项目的顺利进行。

在时间管理中,活动之间的依赖关系是指活动与活动之间在时间顺序上的关系。例如,一个活动的开始是否必须在另外一个活动完成之后?活动能不能并行执行?能不能交叉?确定在活动之间的这些依赖关系对于合理安排项目进度有重要的指导意义。

网络图法是进行活动排序的有效方法,网络图是各项活动之间的联系和依赖关系的图示。比较常用的网络图法是前导图法,它用节点表示活动,用箭线表示各活动之间的逻辑关系。此外,还有箭线图法,它用箭线表示活动,用节点表示活动之间的连接关系,节点表示事件,它不占用任何资源和时间,表示指向节点的活动全部完成后,该节点后面的活动才能开始。

2.3 活动工期估算

活动工期的估算是指根据多方面情况加以分析,计算出项目活动的工期。项目范围说明书、企业环境因素、组织过程资产、活动清单、活动属性、活动资源需求、资源日历和项目管理计划都是进行工期估算的重要信息。

在做活动工期估算的时候最重要的是估量资源的可用性,如人力、设备、材料、资金等。特别是人力资源,如项目活动对工作人员有什么技术要求?需要多少人来完成项目活动?项目工期估算完成后,应将估算结果形成文档,同时更新活动清单。活动工期估算可采取如下几种方式:

1)专家判断法。让对类似项目活动有丰富经验的专家来对当前项目活动工期进行估算。

2)类比估算法。用以前类似的项目活动为依据,进行类比,估算当前项目活动的工期。以前的项目活动已经形成的各种文档,对类比估算有较大的参考价值,应注意有效利用。

3)定量型的基础工期。当产品可以用定量标准计算工期时,则以计量单位为基础数据进行整体估算。

4)保留时间。工期估算时预留一部分多余时间,以应对项目活动进行时的风险。保留时间的取值可取项目活动时间的某个百分比。

2.4 进度安排

项目的进度安排是指使用前面所有项目时间管理过程的结果,确定项目活动的开始和结束时间。进度表的确定应根据多方面情况统一考虑,如项目网络图、估算的活动工期、资源需求、资源共享情况、项目执行的工作日历、进度限制、最早和最晚时间、风险管理计划、活动特征都是进行进度安排的重要依据。

为了有效预测整个项目的工期,并防止进度超期,可以采用关键路径法。关键路径法是一种运用特定的、有顺序的网络逻辑和估算出的项目活动工期,确定项目每项活动的最早与最晚开始和结束时间,并做出项目工期网络计划的方法。关键路径法关注的核心是项目活动网络中关键路径的确定和关键路径总工期的计算,可以通过关键路径得出完成项目所需的最短时间。对关键路径可以进行时间压缩优化,即结合各方面因素对整个计划进行调整,尽量将关键路径所需要的时间压缩至最短,从而得到最佳的进度计划。

进度安排输出的结果包括项目进度计划、项目管理计划、进度基线、进度模型数据、资源需求的更新、活动属性、项目日历、请求变更。所有的项目时间管理过程通常需要有多次反复,才能使进度安排的结果更为合理,进度安排的结果将作为进度控制的基础。

2.5 进度控制

软件项目中进度控制主要是通过监督进度的执行状况,提高项目进度的透明度,及时发现和纠正项目执行过程中的偏差和错误。进度控制的输出包括绩效度量、请求变更、建议的纠正措施、进度模型数据的更新、进度基线、组织过程资产等。在控制中要考虑影响项目进度变化的因素、项目进度变更对其他部分的影响因素、进度表变更时应采取的实际措施。

进度安排的输出结果是进度控制过程中检查、沟通、纠正和采取预防措施的基础。当项目进度出现问题的时候,要具体分析多方面的因素。考察任务分配、人力资源分配、时间分配等是否合理,如考察活动安排是否合理?工作量估算是否准确?项目成员自身的技术水平和工作态度是否满足要求?是否需要增加项目成员?在准确分析造成项目进展出现问题的各因素之后,应及时、有效的给出相应的解决方案,保障项目顺利的完成。

3 结束语

项目时间管理是一个科学和系统的过程,其中的每项工作都是相互关联、相互影响的,只要其中一个环节出现问题,都会影响到整个软件项目的进展,所以项目管理者应高度重视软件项目的时间管理,对时间管理的每项工作要认真执行,这样才能按时按需、保质保量的完成软件项目。

摘要：针对当今软件项目中普遍出现的工期拖延、进度失控问题,介绍了时间管理的基本概念,接着从活动定义、活动排序、活动工期估算、进度安排、进度控制几个方面介绍了时间管理的过程。

关键词：时间管理,项目,进度安排,活动排序,估算

参考文献

[1]樊伟.论项目时间管理[J].现代商贸工业,2010,22(5).

[2]曹桂涛,喻姗姗.软件项目的时间管理[J].计算机应用与软件,2010,27(7).

[3]张家浩.现代软件工程[M].北京:机械工业出版社,2009.

论金融软件的项目需求管理 第9篇

软件工程理论认为, 在软件生命周期中需求分析 (Requireme nts Analys is) 是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的, 高质量需求对软件开发往往起到事半功倍的效果, 在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。

需求分析的过程, 是分析用户的需求的过程, 是全面理解用户的各项要求, 并且准确地表达所接受的用户需求的过程。如果投入了大量的人力、物力、财力和时间开发出来的软件并不是用户真正需要的东西, 那么所有投入都是徒劳, 开发出来的东西不能得到用户的认可, 从而造成重新开发, 这样不仅影响项目进度, 而且严重影响项目组人员的积极性。

需求管理是调度、协调需求工程活动, 如获取、分析、规约及验证, 并编制文档的整体过程。在实际工作中, 伴随着需求的改进, 需求工程的各阶段有时是交织在一起的, 其最终结果是产生需求分析文档《软件需求规格说明书》, 相当于最终用户和开发机构之间的技术合同书。它既是开发者开发软件系统的依据, 也是最终用户验收软件系统的依据。

2需求管理过程

2.1需求统一入口

金融软件项目有很多应用, 而每个应用实施是相对独立、同步的。如此一来, 就难以整体把握需求, 洞悉相互关联。集中一点归集, 实现需求统一入口, 归集各种渠道而来的需求, 并结合优先级、需求明确粒度等抽取规则, 确立需要进入下一环节的需求。

2.2需求分类

按业务范围可分为资产负债管理、客户关系管理、财务绩效管理、风险管理和监管合规管理五大类;按支持方式可以分为系统应用支持和业务条线/部门两大类;按工程实现方式可以分为接口、报表和完整业务应用实施三类需求。

2.3需求分解

不同的需求分类对应着不同的管理方法, 而管理方法的基础则是进行需求分解, 需求分解的好坏将决定需求管理的效果。需求分解的益处包括以下几点:便于对需求点进行全程跟踪, 包含业务定义、数据分析、数据校验、设计、开发、测试及各阶段问题、计划的执行情况、迭代管理等;有利于实现内部协作的共享与监督管理;以需求细化为基础, 能对不断优化的需求及需求变更进行规范管理;有助于指标、报表甚至功能的复用。

需求分解的方法和粒度因需求类型的不同而有差异。接口类需求按照接口表与字段两个维度进行分解;报表类需求以报表指标为粒度进行分解, 分解时需先结合指标维度进行最细层拆分, 再根据维度的共通性、实现的难易、取数的规则等进行适当的合并;综合类需求则需要对具体功能模块不断进行分解, 分解的合理性与需求分析的规范性是分不开的, 目前综合类的需求以需求分析文档为主, 结合需求管理工具进行管理。

2.4需求分析

需求分解后就可以进行需求分析工作, 在分析中关注的是如何使分析的过程更为有序、高效和严谨。

2.5需求确认

需求分析完成后就需要进行需求确认, 即由需求提出方对需求进行评审和确认, 是项目转入实施阶段的关键。

2.6需求基线与变更管理

在需求获取确认后, 需求即被打上一条基线。被基线化的需求可以是一个应用的完整需求, 也可以是部分需求。基线化后, 需求的变化即纳入变更管理。一个新的需求变更会重新循环到需求统一入口这一环节。

需求变更是软件开发人员最为头疼的事情, 但不得不承认, 软件的需求变更必然存在。外部环境改变、业务规则变化、人员更迭、沟通不畅等, 都是需求发生改变的诱因。随着优化需求的不断增加、数据与功能的复用和整合日渐增多, 需求变更会逐渐成为需求管理的一个重点。需求变更需从影响性分析和变更评估开始, 直到变更完成, 也需要经过一个完整的过程管理。需求变更管理也是保障需求与最终产品一致性的关键环节。

2.7需求跟踪管理

需求基线化工作的结束标志着开发实施阶段的开始, 在实施过程中, 由于沟通、人员、能力、知识等各种原因, 会发生各阶段产品与需求的偏差, 为使需求在各环节的流转保持一致和可回溯, 就需要进行对需求的跟踪管理, 通过需求与设计、设计与开发、需求与测试之间的需求跟踪矩阵进行持续的跟踪管理, 发现问题及时沟通并反馈, 以保障需求没有遗漏、没有重复、没有偏差地传递到最终产品。对数据仓库的应用需求而言, 跟踪矩阵大多是以数据的流转过程和数据间的关系为核心进行体现。

3金融软件需求管理的一般原则

为做好金融软件的开发和管理, 要特别重视软件需求管理, 金融软件需求的管理要符合需求工程的一般要求。

3.1对需求的约束软件需求直接关系到软件产品的质量。一个好的软件需求应具有如下特性:

完整性:

要从全局出发, 不能单纯从本业务考虑问题。一方面要完整地反映该项业务, 另一方面还要全面反映本项业务同其它关联业务的联系。

准确性:

准确无误, 无二义, 各项要求、业务做法、每种处理的详细流程、数据等方面的要求等明确定义, 不能摸棱两可、含糊不清。

通用性:

业务需求要具有较广泛的适应性, 要能够适应大部分分支机构、适应大部分业务处理情况, 减少以后各分支机构对系统的修改要求。

前瞻性:

业务需求要具有前瞻性, 要能够反映该项业务当前的发展状况 (包括同业情况) 和发展趋势。系统要留有可扩充的余地。

稳定性:

一定时限内相对稳定、不变。

权威性:

业务需求要具有权威性, 能被普遍接受, 并具有很强的约束力。

可行性:

需求在技术实现和经济负担上要符合实际, 切实可行。

安全性:

金融业在社会经济生活中的特殊性对金融软件的安全性提出了较高的要求, 从需求的提出就应充分考虑软件的安全性问题, 要有专门负责安全生产或稽核的人员全程参与需求管理及软件开发。

在金融软件开发的实践中, 业务需求要全面符合上述要求比较困难。一般由应用部门综合考虑各点有求, 并有所侧重。但是, 为了保证软件产品的质量, 还是应该尽量满足各项要求。

3.2对需求管理的约束金融软件的需求管理是一个综合性的过程, 应做到以下几点:

负责制:应用部门和开发部门都应实行, 两个部门都要有专门的机构负责从本部门的角度进行需求管理, 由专人负责, 有专门的部门领导负责协调, 并对需求中出现的各种问题和错误负责。需求管理涉及后续各个方面, 直接关系到软件产品的最终质量, 因此必须强化需求负责制, 确保需求及其变更始终处于良好的管理之下。

规范化:规范化是现代管理工作的基本要求。强调规范化管理, 可以避免非程序性、随意性等多方面问题。金融软件需求管理同样应遵循科学规范的原则。在需求管理中, 对需求的获取、需求分析、需求分析的描述 (《软件需求规格说明书》及其它文档) 、需求的变更等需求管理的各方面制定相应的管理规范, 并在工作中加以完善, 坚持执行。

严肃性与灵活性:业务需求的提出及变更是一件严肃的事情。需求管理的目标之一, 就是减少需求的变动, 维护需求的相对稳定性。需求的每一处变动, 都会对后续的开发工作产生影响, 甚至导致某些工作推倒重来。因此必须维护需求的严肃性, 不允许随意变更需求的内容。如确有必要, 应经过变更需求的管理程序。对于业务上某些不影响原则问题的细节调整, 开发部门可以根据开发工作的实际情况, 在符合需求的大框架内予以满足, 并将变更的内容及时归档记录, 作为《软件需求规格说明书》的附件, 从而在需求管理上体现出一定的灵活性。

4总结

软件项目的时间管理 第10篇

项目管理是在一定的约束条件下, 为高效率地实现项目业主的目标, 以项目经理个人负责制为基础和以项目为独立实体进行经济核算, 并按照项目内在的逻辑规律进行有效地计划、组织、协调、控制的系统管理活动。

从软件工程的角度讲, 软件开发主要分为以下几个阶段:需求分析、总体设计、详细设计、编码和单元测试、综合测试、运行和维护。在开展软件项目管理时, 应遵循以下7条基本原则: (1) 用分阶段的生命周期计划严格管理; (2) 坚持进行阶段评审; (3) 实行严格的产品控制; (4) 采用现代程序设计技术; (5) 结果应能够清楚地审查; (6) 开发小组的人员应该少而精; (7) 承认不断改进软件工程实践的必要性。

2 项目管理实践研究

2.1 项目简介

Android手机操作系统自问世以来, 凭借其强大的易用性、开放性、丰富的硬件选择面及便捷的开发功能, 迅速成为智能手机市场的新宠儿。“PC遥控器”是基于JDK和Android SDK, 以Java语言编写的一款Android平台手机应用软件。本款软件的开发意图在于使随身携带Android手机的人群无需再花钱购买专门的远程控制设备, 如电子笔、无线鼠标等, 或者在忘记携带上述设备的情形下, 直接使用手机远程操控计算机, 为用户节省时间和金钱。从虚拟触摸板功能、文件浏览功能, 到智能PPT遥控功能、虚拟游戏手柄功能, “PC遥控器”将给用户带来更为实用、更为便捷的全新体验, 让用户在工作、娱乐中尽情享受指尖在屏幕上滑动的乐趣。

2.2 生命周期模型选择

增量模型融合了瀑布模型的基本成分 (重复应用) 和原型实现的迭代特征, 该模型采用随着日程时间的进展而交错的线性序列, 每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时, 第1个增量往往是核心的产品, 即第1个增量实现了基本的需求, 但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能, 这个过程在每一个增量发布后不断重复, 直到产生了最终的完善产品。

因本软件涉及触摸板、文件浏览、PPT控制、游戏控制等多个相对比较独立的子功能, 所以我们采用的是以增量模型 (图1) 的方式, 把软件产品作为一系列的增量构件来逐一设计、编码、集成和测试, 根据测试结果不断改善直至达到预期。

采用增量模型的优点是人员分配灵活, 刚开始不用投入大量人力资源。如果核心产品很受欢迎, 则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时, 它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户, 可以使用户有较充裕的时间学习和适应新产品。此外, 增量能够有计划地管理技术风险。

依据采用的增量模型, 将该系统的开发阶段分为需求分析、系统设计、编码实施、测试、系统试运行等, 在每个开发阶段中进行质量、成本和进度等跟踪控制管理, 主要从文档、工具、沟通、制度、合作4个方面进行。管理模型如图2。

2.3 需求分析

需求分析是每个软件开发的基础, 是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法, 可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。全面的需求获取是从保证系统开发少走弯路为前提。项目开发中采用了多种方法从不同角度获取不同用户、不同平台的不同需求。分析方法主要有用户调查问卷、定期召开研讨会、原型展示等。对于每一次的调查和会议, 都有专门人员做好全程记录, 会后及时做好应对策略。

本项目具有较强的可行性和创新性, 因此, 正确而又全面地做好系统的需求分析是十分重要的。本项目所开发的系统的主要特点有:

(1) 系统主要分为Android手机端应用软件和配套的PC服务端软件两部分。

(2) 手机端应用软件基于Android操作系统平台, 应充分考虑到针对各种不同硬件配置和操作系统版本的兼容性。

(3) 配套的PC服务端软件应能够跨各种不同操作系统平台运行, 且占用较少系统资源。

(4) 系统应能够在大多数无线环境下使用, 保证数据连接的速率和操作的顺畅。

(5) 软件所面向用户群体的计算机专业知识参差不齐, 因此简单友好的可视化操作界面是至关重要的。

本系统具体功能需求如表1。

2.4 项目规划

项目规划是建立项目行动指南的基准, 包括对软件项目的估算, 风险分析、进度规划、人员的选择与配备、产品质量规划等。本项目采用Microsoft Project制定项目管理计划。在制定计划时注意保证计划的可行性, 明确责任划分。项目管理计划随着系统的进行不断细化, 不断调整。对于影响系统整体进度的调整, 及时召开小组会议进行讨论决定并记录形成文档。

2.5 系统设计与编码

系统设计阶段分为概要设计和详细设计两阶段完成。概要设计阶段将系统划分为连接模块、通信协议模块、触摸板模块、文件浏览模块、PPT控制模块、游戏手柄模块、设置模块、帮助模块、关于模块及退出程序模块等10个模块, 并对这些模块进行了初步设计分析;针对PC服务端软件, 为了达到在各种操作系统平台上的可用性, 编程语言采用了跨平台的Java。系统总体流程如图3。

详细设计阶段给出了每个模块的控制流程、算法和数据结构等。每个模块的层次不同。有些模块难度较大, 涉及范围较大, 会交给编程老练、心思缜密的队员完成。每完成一个模块都将对这一模块进行反复的测试和修改, 直至稳定为止, 尽可能地降低风险和成本。

在编码实施阶段, 采用代码版本管理工具SVN, 使各子系统的功能得到最大限度的发挥, 子系统之间互相补充, 弥补软件开发过程中的短板, 降低软件开发过程中的风险和难度。这还有助于使得软件开发人员在测试和调试过程中能够针对某个特定的开发信息回到以前的任一版本, 提高软件过程的跟踪率。

2.6 测试和运行

软件测试伴随着整个项目进行, 项目中制定了详细的测试计划、精心编写了测试用例。每一个子模块由该模块编程人员之外的人员进行反复测试, 对测试过程中出现的任何问题和建议进行记录, 以备该模块编程人员修改。在编写测试用例过程中, 对测试目标、测试环境、输入数据、测试步骤、预期结果等记录具有代表性的数据, 并形成文档。

试运行阶段, 首先, 小范围地对每个子模块试运行, 试运行成功后再对整体软件试运行, 并对反馈的运行结果记录、斟酌和完善。试运行成功后编写用户手册、制作PPT并录制视频说明, 其中标注联系方式等, 以备用户反馈。

2.7 项目后期管理

当系统经过安装试用一段时间, 具备验收的各项条件之后, 我们就需要着手验收阶段的准备工作。首先我们需要把到目前为止完成的工作进行一个总结, 列出我们已经完成的各项目工作成果、各类文档, 对合同以及各类约定的技术文档中的相关内容进行自查。要彻底了解系统目前完成的情况如何, 对于没有完成的, 要考虑准备采取什么策略去进一步完成或者采取一定的回避措施, 使客户在验收的时候不再提出这些未实现的需求。

系统交付后的软件维护是必不可少的。软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改, 修改时应充分利用源程序。修改后要填写程序修改登记表, 并在程序变更通知书上写明新旧程序的不同之处。

2.8 项目跟踪控制

从软件项目前期需求分析到后期运行维护, 均需坚持整个过程的监控, 这是为通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果、风险等, 不断地了解项目的进展情况, 以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施, 使项目能恢复到正常轨道, 或者更正计划的不合理之处。

2.9 团队管理

软件项目的成功是靠项目管理、系统分析设计、程序编制、测试、市场营销等不同角色人员共同协作完成的, 不同角色的人执行的工作相互促进和制约着其他角色的人的工作, 因此一个高效的软件开发团队是高质量软件项目或产品的保证。

高效的软件开发团队是建立在合理的开发流程及团队成员密切合作的基础之上, 成员共同迎接挑战, 有效地计划、协调和管理各自的工作, 以至完成明确的目标。高效的开发团队具有明确且有挑战性的共同目标, 具有很强的凝聚力, 具有融洽的交流环境, 具有共同的工作规范和框架, 采用合理的开发过程。

本项目的开发团队包括5位成员, 进行科学分工, 相互协助设计、开发和测试。团队成员在专业技术上有所差异, 而项目管理能力的表现也不是很突出, 因此对于整个团队而言, 具有一定的难度。我们严格按照软件工程中开发软件的方法来控制整个项目的进行, 具体成员的工作安排如表2。

团队管理是对项目组全体成员的管理和项目组织自身的管理, 是项目管理中最为根本的一项管理。团队开发, 永远不是一个人在行动, 因此需要制定团队规范来约束大家的行为, 以保证进度和质量。团队规范的内容主要包括: (1) 每个开发人员每天晚上汇报当天的工作进度; (2) 每周末总结本周工作, 制定下周进度计划; (3) 遇到问题及时沟通, 充分利用团队优势; (4) 不能完成任务或提前完成任务及时告知负责人; (5) 个人独立解决一个问题的时间不能超过半小时, 半小时之后未解决应及时与其他成员商讨; (6) 阶段性的技术总结、团队内部技术、经验交流; (7) 使用版本管理工具来协助开发; (8) 保证充分可靠的文档; (9) 周期执行检查工作; (10) 实行公正合理的奖惩制度。团队管理的目的是使项目组人员的主观能动性得到充分发挥, 做到人尽其才、事得其人、人事相宜, 同时保持项目组织高度的团结性和战斗力, 从而成功地实现项目的既定目标。

3 结语

软件项目管理是一门很大的学问, 它贯穿于项目启动、计划、执行、控制、收尾等5个阶段, 它不仅需要项目管理相关的基础理论知识作为指导, 也需要在实践中不断学习、摸索。因此, 总结项目经验是非常重要的, 它有利于团队技术与管理经验的积累, 对于今后的项目有非常重要的指导意义, 必须引起足够的重视。

本项目通过将软件项目管理的相关知识应用到Android应用开发的过程中, 在需求分析、项目规划到系统设计与编码、测试和运行乃至团队管理等方面, 有效地保证了项目保质保量地向前推进, 有利于归纳出适合团队的开发过程, 提高团队的开发经验。同时, 团队的每位成员在项目开发的整个过程中都切实负起责任, 既增强了团队合作意识, 提高了团队的凝聚力, 又保证了用户的真实需求得到满足。

通过在项目中实践软件项目管理的方法, 在最后开发出的软件中, 基本上达到了我们预期的目标, 既完成了预定的各个功能模块, 同时也在软件人性化、系统安全等方面都进行了认真地关注, 并努力修正了很多方面的细节问题。

摘要：通过在一个Android平台小型软件的开发过程中应用软件项目管理的相关知识, 初步探讨了Android平台软件开发的特点, 阐述了需求、质量、进度等方面的管理理念和方法, 特别是如何对项目进行跟踪、监控和度量, 以保证软件按照进度高质量地完成、交付和使用。

软件项目的时间管理 第11篇

关键词：软件项目；设计与开发；过程管理；有效性

中图分类号：TP311.52 文献标识码：A 文章编号：1674-7712 （2012） 14-0057-01

对软件项目设计与开发的全过程进行有效的管理，不仅是要为了顺利实现软件的特定功能与性能，还要确保能够保质、保量、低成本的完成软件开发的任务，使软件在投入使用后也能够保持稳定性、可靠性、实用性和经济性。简单的说，软件设计与开发的过程就是要将需求转变为软件表达的过程，要想切实提高软件项目设计与开发过程管理的有效性，不仅要坚持正确的软件项目设计原则，还要明确软件的设计流程，在设计与开发的各个过程都采取行之有效的管理对策。

一、软件项目设计与开发的基本原则

（一）实用性

实用性指的是软件项目的设计与开发一定要能够满足现代企业经营管理的需求，能够促进企业的不断发展，要避免“形式主义”、“中看不中用”等问题，否则有可能导致企业软件开发资金的浪费，难以取得良好的投资回报效果。因此，在选择软件设计与开发技术时，不能过度追求先进性和高投入，而是应当在充分了解企业实际需求的基础上，结合企业的发展方向，充分满足企业在不同层次和环节上的管理需求，这也是决定软件开发项目成败的关键因素。

（二）先进性

毋庸置疑，在信息技术不断变化发展的时代背景下，先进性是软件项目设计开发过程中必须充分考虑的问题，这可以有效降低企业在未来的投入，避免未来在软件项目开发中的重复建设和系统升级等问题。因此，企业在进行软件项目的开发设计时，一定要面向社会经济的未来发展方向和人民生活需求的变化趋势，紧跟社会步发展的步伐，与信息技术、计算机技术、通信技术以及相关学科的发展方向保持一致，这样才能不断推动社会的进步。

（三）经济性

任何一个软件项目的设计与开发，都必须充分考虑到投入产出比的问题，力争用最小的经济投入获取最大的投资回报，实现最好的软件开发设计效果和更高的经济效益，这也是软件开发企业的主要目标。因此，在保证软件开发质量的前提下，软件的开发费用需要控制在合理的预算范围之一，并尽量压缩，在设计开发过程中必须要考虑到软件在后期运行维护过程中的费用投入，实现软件项目设计与开发全过程费用的节约。

（四）系统性

在软件项目的开发设计中，一定保证其整体功能的完整性，既能满足企业在整体上的管理需要，设计与开发的系统必须能够全面、完整覆盖企业管理的软件信息系统，又要能够满足采购、生产、销售等个别部门的管理需求，便于各个部门之间信息数据的传递和衔接。此外，还应当制定系统的软件项目设计与开发的管理规范，如开发文档的管理规范、报表文件规范、数据格式规范等，这是确保软件系统开发和操作水平的重要条件。

（五）可靠性

为了充分保证软件项目系统运行的高效、平稳和准确，不仅要保证软件系统在正常运行状况下数据传递的准确性和系统运行的可靠性，还需要确保软件系统项目在非正常状态下的可靠运行，因此在软件项目的开发设计过程中要提前针对一些紧急情况制定相应的应对策略。一个优秀、可靠的软件系统，必然是一个灵活的系统，即使在软、硬件环境发生故障时，仍旧能够保持部分使用或正常运行。

二、软件项目设计与开发的全过程管理

（一）软件项目设计与开发的启动

在软件项目的设计与开发过程中，实施全过程管理的第一个阶段就是项目的启动。在软件项目的启动阶段，首先，要明确软件项目设计与开发的目的，并在软件开发与软件使用的双方协议或者合同中进行约束，并对软件设计的主题、工程量进行量化，合理确定软件项目开发和设计的阶段目标和周期。其次，要加强同软件用户的充分沟通，了解用户的软件使用需求，理清软件记录的关键点，制定出完整的软件设计与开发流程；再次，对于在调研过程中所获取的原始资料，一定要进行加工处理，理清相关的约束条件和非功能性的客户需求，确保软件开发与建设项目具有很强的可实现性。

（二）软件项目设计与开发的规划

软件项目的规划，是软件设计与开发过程中比较复杂的阶段，也是决定软件开发质量和开发水平的关键，做好软件项目的整体规划将会为整个软件项目的运行奠定良好的基础。具体说来，软件项目规划主要包括项目预算、风险分析与预测、进度管理、质量控制等内容，在编制软件项目的开发计划时，一定要理清各个开发环节之间的关系，并制定出完整、科学的项目计划书，以期为软件项目设计与开发的全过程管理提供相应的参考依据。

（三）软件项目设计与开发的实施

软件项目实施阶段的有效管理，其目的就是要保证软件项目安装在预先设置的计划上正常运行，确保项目不要偏离预定的开发进程和设计目标。在软件项目的实施阶段，一定要按照软件项目的初步规划进行，并在实施过程中，增强对软件项目开发的有效控制，确保成本支出控制在相应的预算定额之内。同时，要对软件项目开发的成果进行动态的监控，随时与原先的计划过程进行比较，对于出现的偏差或缺陷要及时进行调整，确保各项软件开发指标和系统功能的顺利实现。

（四）软件项目设计与开发的结束

一个完善的软件项目管理过程，必然离不开软件项目的结束，这时相关人员要进一步确认软件项目在设计与开发过程中取得的成就，做好软件项目的交接、评审等工作。

三、结语

总之，为了提高软件项目设计与开发的质量和水平，软件设计人员需要首先认识到软件质量的重要性，树立应有的软件项目质量管理意识，要坚持正确的软件设计与开发原则，懂得加强过程管理与控制，同时还要对风险控制、配置管理等环节给予足够的重视，采用科学的技术方法和先进的管理技术来提高软件项目质量管理的有效性。

参考文献：

[1]李勇华，骆启武，付春燕.基于问题管理提升软件项目过程质量的实践[J].计算机与现代化，2007，4.

[2]商惠华.基于过程改进的软件质量管理模型[J].计算机工程与设计，2011，5.

基于软件测试的项目管理研究 第12篇

1 什么是软件测试

软件测试是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。一般来说,软件测试是为了发现错误而执行程序的过程,即根据软件开发各阶段的规格说明和内部结构而精心设计的一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序以发现错误程序的过程,随着软件开发技术的发展,人们对软件测试及其重要性的认识也进一步加强,1983年IEEE(电气和电子工程师协会)提出的软件工程标准术语中给软件测试下的定义是:“使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”定义包含了两方面的含义:是否满足规定的需求和是否有差别。如果有差别,说明设计或实现中存在缺陷,自然不可能满足规定的需求。软件测试目的就是查找软件中存在的错误,检验软件是否满足需求目标,由此所带来的附加收获是:测试结果为软件可靠性分析提供了依据;可以通过分析错误产生的原因和错误的分布特征,帮助项目管理者发现当前所采用的程序代码的缺陷,以便改进。同时,分析的结果也能帮助测试人员设计出更有针对性的检测方法,改善测试的有效性。新型的测试软件会帮助你跟踪错误而且允许其它人看到你是如何处理错误的。如果其它人看到了你的测试过程,他们就会避免重复你的工作,同时还可以将他们的测试信息反馈给你。

2 测试软件在软件测试中的应用

在测试软件当中,使用Bugzilla的用户还是比较普遍的。Bugzilla是一个错误跟踪系统,用于对软件产品程序开发过程的错误跟踪,简单的说,它是一个臭虫的数据库。它让用户报告软件的臭虫而且把它们转给合适的开发者。开发者能使用bugzilla保持一个要做的事情的优先级,还有时间表和跟踪相关性。不是所有的“bugs”都是臭虫。一些数据库中的内容是作为增强的请求(RFE)。比如说很多错误是程序员经常犯的,我们将它记录在Bugzilla中,当其他用户再次出现此错误时,可以在Bugzilla上查询到相应的解决方案。Bugzilla可以帮助我们更好的在软件开发过程中跟踪软件的错误,为开发、测试软件以及软件产品质量的度量提供数据支持,从而有效的保证软件产品的质量。当我们被大量的测试数据所淹没时,测试软件可以帮我们跟踪软件测试中遇到的的问题,Bugzilla使用数据库进行管理,提供全面详尽的报告输入项,产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配功能,并根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时,开发人员、测试人员、及管理人员将及时获得动态的变化信息,允许我们获取历史纪录,并在检查错误的状态时参考这一记录。它可以对软件产品设定不同的模块,并针对不同的模块设定开发人员和测试人员。这样可以实现提交报告时自动发给指定的责任人,并可设定不同的小组,权限也可划分。设定不同的用户,这些用户对Bug记录的操作权限不同,可高效的对错误进行管理。测试软件可以自动发送Email,通知相关人员。根据设定的不同责任人,自动发送最新的动态信息,有效的帮助测试人员和开发人员进行沟通。软件测试人员在测试时,可以利用测试软件将软件测试中出现的错误按照优先级记录下来,这样下次遇到同样的问题时,可以很轻松的通过查询测试数据库解决,尤其是当开发团队人员比较多时,更能体现出测试软件的优越性,在某些测试软件中软件测试的的漏洞按严重性可以分为不同的等级,并且团队的负责人可以通过该软件为每一个成员分配任务和时间,当时间到达指定期限时,该软件自动向成员发出警示信息。这大大提高了软件测试的效率。

软件测试的流程如图1所示:

测试过程遵循的原则如上图所示,开始阶段进入测试后先收集缺陷,然后对收集的缺陷分门别类,有很多的缺陷在测试时需要跟项目编程人员,甚至是项目的设计人员协商之后才能确定的,并对所有的错误做详细的记录。根据缺陷的严重等级和缺陷所属的模块进行划分,在缺陷管理软件上写清楚错误的类型和所属的模块并将错误分配给相应的每一个人,这时跟踪系统会自动的发邮件给项目组每一个人。还会根据跟踪系统的最后日期对相应的测试人员进行提醒。有些错误是不需要修改的。这时需要填写报告,作相应的记录,将需要修改的错误转给开发人员进行修改,修改完毕后转测试人员通过更为完善的测试用例,测试系统的健壮性。假如错误消失则提交Bug,并将详细的解决思路提交到Bug跟踪软件,标注为已解决。测试结束,假如仍然有问题则填写相应的报告,继续转入缺陷收集。重新确认错误并分派相应的人员处理。

3 软件测试管理与项目管理相结合

为了有效地控制软件开发流程以保证产品的质量。必须有一套好的研发流程并配备较高素质的测试人员。将测试管理软件与项目管理相结合,很多企业拥有先进的测试软件,但是人员的素质没有相应的跟上,企业领导层不重视,导致软件测试与企业的项目管理相脱节,不能有效发挥软件测试的作用。

在软件测试中有很多问题是重复出现的,通过与项目组的其他成员进行沟通,相同的问题可以通过讨论,借助团队的力量得到解决,而闭门造车,单一个体解决问题相对较困难,在开发团队内部通过团队合作,将出现的问题记录在缺陷管理软件上,这样,团队中的每个人都可以看到此错误的解决方案,这样就提高了开发效率,缩短了开发时间。

在注重测试环节与企业的项目管理密切结合的同时,也应注重测试人员的技术水平,有时候测试人员和开发人员、需求人员一样,需要有自己单独的行政管理路线,借助于一套完整的测试管理软件,形成一套必要的测试软件流程,再通过这样的系统,把需求、开发、测试三个环节融合在一起,让团队中的所有成员都遵循同样的研发思路,需求人员真正理解用户的业务需要,认真研究后形成需求文档作为产品一个个功能的详细说明;开发人员写出测试文档,然后测试做出来的功能是否符合最初的设想。整个过程碰到的任何问题都可通过缺陷管理软件来记录、跟踪,相关人员通过缺陷管理软件来商谈、沟通相应的解决方案,团队中的每一个人都可以用缺陷管理软件来记录跟踪开发信息,记录的事件不仅仅是代码中的缺陷,还可以是设计的变动,新需求的说明,软件产品的详细介绍等,这些都可以通过软件测试流程有效地管理起来。这样就可以逐步统一研发人员的思维以及做事模式,让整个团队可以有效地运转起来,同时还能不断优化项目的软件研发流程,提高产品质量,从而使产品可持续发展。

4 结束语

对于企业来说,管理好一个项目往往包括很多的内容,比如项目的范围管理、时间管理、成本管理、质量管理、人力管理、沟通管理、风险管理和版本控制。软件测试是一种以错误为纽带,将软件开发过程中的人员,工具,源代码紧密联系在一起的一种开发方式,它处于项目开发过程中的核心环节。所以我们应该通过软件测试的流程来整合管理每一个方面,通过与项目管理相结合,使软件研发流程有计划、有目的的进行,最大限度的发挥软件测试的作用,保证软件产品质量。

摘要：随着软件企业的发展,软件测试在提高软件产品的质量和可维护性等方面,起着越来越重要的作用,软件系统的建设过程中项目管理对整个项目的成败起着至关重要的作用,在软件开发中应掌握其中蕴含的软件测试流程思想,并有效的将测试管理融入到项目管理中,优化软件开发流程,提高产品质量。

关键词：软件测试,团队合作,项目管理

参考文献

[1]Shaft Lawrence Pfleeger.软件工程理论与实践[M].北京:清华大学出版社,1999.

[2]金凌紫.面向对象软件测试技术进展.计算机研究与发展,1998,35(1):6-13

[3]赵元聪,朱三元.面向对象软件测试的认识.计算机应用与软件,1996,13(3):1-4,46

[4]孟岩,刘振飞.Bug管理的经验和实践(上),2005.1.