信息系统项目管理师论文评分参考标准.doc_第1页
信息系统项目管理师论文评分参考标准.doc_第2页
信息系统项目管理师论文评分参考标准.doc_第3页
信息系统项目管理师论文评分参考标准.doc_第4页
信息系统项目管理师论文评分参考标准.doc_第5页
已阅读5页,还剩26页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

信息系统项目管理师论文评分参考标准1.论文满分是75分,论文评分可分为优良、及格与不及格3个档次。评分的分数可分为:60分至75分优良(相当于百分制80分至100分)。45分至59分及格(相当于百分制60分至79分)。 0分至44分不及格(相当于百分制0分至59分)。 评分时可先用百分制进行评分,然后转化为以75分为满分(乘0.75)。2具体评分时,参照每一试题相应的“解答要点”中提出的要求,对照下述5个方面评分: (1)切合题意(30%) 无论是技术论文、理论论文或实践论文,都需要切合解答要点中的一个主要方面或者多个方面进行论述。可分为非常切合、较好地切合与基本上切合3档。 (2)应用深度与水平(20%) 可分为很强的、较强的、一般的、较差的独立工作能力4档。 (3)实践性(20%)可分为如下4档; 有大量实践和深入的专业级水平与体会。 有良好的实践与切身体会和经历。 有一般的实践与基本合适的体会。 有初步实践与比较肤浅的体会。 (4)表达能力(15%) 可从是否逻辑清晰、表达严谨、文字流畅和条理分明等区分为3档。 (5)综合能力与分析能力(15%) 可分为很强、比较强和一般3档。 3下述情况的论文,需要适当扣分: 摘要应控制在200-400字的范围内,凡是没有写论文摘要,摘要过于简略,或者摘要中没有实质性内容的论文。 字迹比较潦草,其中有不少字难以辨认的论文。 正文基本上只是按照条目方式逐条罗列叙述的论文。 确实属于过分自我吹嘘或自我标榜、夸大其词的论文。 内容有明显错误和漏洞的,按同一类错误每一类扣一次分。 内容仅属于大学生或研究生实习性质的项目、并且其实际应用背景的水平相对较低的论文。 可考虑扣5分到10分。4下述情况之一的论文,不能给予及格分数: 虚构情节,文章中有较严重的不真实的或者不可信的内容出现的论文。 未能详细讨论项目开发的实际经验,主要从书本知识和根据资料摘录进行讨论的论文。 所讨论的内容与方法过于陈旧,或者项目的水准相对非常低下的论文。例如,数据库设计仅讨论了Foxpro。且没有鲜明特色的应用;开发的是仅能用单机版的(孤立型的)、规模很小的、并且没有特色的应用项目。内容不切题意,或者内容相对很空洞,基本上是泛泛而谈的、没有较为深入体会的论文。正文与摘要的篇幅过于短小的论文(如正文少于1200字)。 文理很不通顺,错别字很多,条理与思路不清晰,字迹过于潦草等情况相对严重的论文。5下述情况,可考虑适当加分: 有独特的见解或者有着很深入的体会,相对非常突出的论文。 观点很高,确实符合于当今计算机应用系统发展的新趋势与新动向,并能初步加以实现的论文。内容翔实,体会中肯,思路清晰,非常切合实际的很优秀的论文。项目难度很高,或者项目完成的质量优异,或者项目涉及重大课题,并且能正确按照试题要求论述的论文。 可考虑加5分到10分。论软件项目管理中的需求变更控制摘要从计算机系统集成软件开发项目需求变更控制的角度,简单分析需求变更产生的原因、需求变更将会对项目产生的影响,并结合实践说明如何在实际工作中对软件开发项目的需求变更进行有效控制和管理,以减少项目风险,使项目顺利交付。关键词项目管理 需求变更 控制软件项目在执行过程的变更,特别是需求的变更是最难把握的,它也是影响到整个项目成败的关键因素。一、计算机系统集成软件开发项目需求变更产生的原因对于软件项目的需求而言,产生变更的原因集中在下面几个方面:1.用户对系统功能理解的分歧。在进行用户需求调查分析时,分析人员的知识、背景、与用户的交流情况等因素会造成系统分析人员和用户在功能理解上的分歧,随着项目的进行,这种分歧肯定会带来变更。2.用户业务逻辑发生了变化。用户自身的业务逻辑不太明确,特别是处于激烈竞争情况下的用户肯定要随着市场情况的变化,随时调整自己的运作来适应这种变化,这肯定会对相关的软件产品提出更多的变更要求。3.用户在试用过程中提出的变更。当用户拿到测试版本可以进行实际操作时,用户一般都会对功能、性能、界面、操作方式等提出新的意见,这时变更产生了。4.技术的升级。技术的升级分为两个方面,一方面是随着信息化技术的迅速发展,原项目中使用的技术可能变成过时技术,需要对原技术进行升级;另一个方面是开发方自身对软件版本升级、性能改进、设计修正时产生的变更。从上面可以看出,指望软件项目需求能从始至终一成不变是不可能的。二、计算机系统集成软件开发项目需求变更的影响及管理原则1.设定项目需求基线。需求基线是需求变更的参照标准,每次的变更均应在需求基线的基础上进行。每次变更评审通过后要重新确定需求基线,使其符合需求变更后的状况。2.严格执行需求变更流程,并记录在变更过程中产生的所有文档。3.成立项目变更控制委员会(CCB),负责对项目变更进行评估,裁定哪些变更需要执行,哪些变更应该放弃。变更控制委员会的成员应由项目所涉及到的多方面人同组成,应该包括用户方和开发方的决策人员在内。4.需求变更后,受影响的相关软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。三、计算机系统集成软件开发项目需求变更的流程在软件项目需求变更时,一般采用下面的流程进行控制:1.申请变更。当项目开发组确认将要产生需求变更时,用标准的变更申请表格将用户的每一次变更申请记录存档。2.变更评估。项目开发组收到用户提交的需求变更申请后,应对该变更所带来的影响进行评估。它包括项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素,以及外部因素如资本、用户要求的完工时间、项目负债情况等各个方面的影响。对于一个变更的申请,可能会有以下几个可能的评估结果:(1)在现有资源和时间范围允许的情况下可以采纳该变更。(2)可以采纳,但要延长交付时间。(3)在现有的可交付时间内可以采纳,但需要额外的资源支持。(4)可以采纳,但需要额外的资源和延长交付时间。(5)可以采纳,但需要采取多次发布策略,并排定不同发布时期交付成果的优先次序。这种情况的发生非常频繁,项目经理需要权衡将一些重要的工作提前完成,而有一些不重要的工作延迟完成。(6)不能采纳。3.变更的实施。一旦确定变更后,下一步就是分析和选择可行的实施方案。项目的目标、预算、团队以及项目的进度是决定项目成功实施的主要因素。在需求变更时,力求在尽可能小的变动幅度内对这些主要的因素进行微调。为了将项目变更的影响降低到最小,一定要认真执行变更的控制流程,减小项目风险。四、实际项目分析以某学院的信息管理系统软件开发项目为例。该系统包括了学籍管理、排课管理、学生选课、教材管理、学生考勤管理、教学质量管理、考试管理、成绩管理、宿舍管理、财务管理、证明管理、招生管理等子系统。在开发过程中,我们对需求变更进行了较严格的管理,产品得以按时保质地上线。在该管理信息系统的开发过程中,变更的因素有以下几个:1.由于项目启动时间距离第一个版本的上线时间很近,不可能在短时间内将所有的需求都获取到。2.开发人员有时会对用户的描述理解不正确,或遗漏某些要求,所以要对已有的需求进行修改。3.用户在项目开始的时候,大都不是很了解自己到底需要什么,等他们使用一段时间管理系统后,就会在实际使用中不断发现这样那样的需求。4.最主要的因素,就是该学院成立时间不长,且不是采用国内常规的管理方法,而要使这些管理方法适合国内的高校管理体制,需要有一段磨合期,所以学院内部的管理经常变,导致系统的相应需求也必须变。变更控制委员会由主管这套系统开发的副院长、项目经理以及配置管理员三个人组成。根据开发的实际情况,我们制定了一套变更管理程序,就是所有变更都必须以变更申请书的形式提交给变更控制委员会,变更控制委员会评估后,出具变更报告,然后才交给相关人员做相应处理,之后,由测试人员对变更后的相关用例进行测试跟踪。一个需求变更申请提交后,变更控制委员会对其进行评估,如确认进行变更,则由我方项目经理出具一份变更报告,写明变更事由、提出方、提出时间、变更评估结果。配置管理员将这份变更报告加到配置管理库中存档,并分发给变更申请人以及相关系统分析员。系统分析员对之进行分析,提交出一份变更列表,将该变更所影响到的文档、程序都详细的列出来,上交给配置管理员进行存档。然后,系统分析员对列表的中所列出来的文档逐个进行修改,再交由编程人员进行相应的代码修改,然后提交测试员测试,出具测试报告。这些修改的文档、代码以及测试报告都要提交给配置管理员进行存档管理,配置管理员还要根据提交情况对变更列表进行相应维护,如某项修改完成了,就要在它后面打上完结标记。当该变更列表中的所有变更项都完结了,配置管理员在变更报告后要加上实际完成时间。这样,变更所导致的文档、程序变化就可以在一个可以追溯、可以控制的状态下进行了。减少了遗漏的可能性,并便于变更的追踪。由于采取了上述变更控制方法,即使该项目的变更比较多,但还是能保持开发工作正常有序地进行。五、结束语对于软件开发的过程中不可避免的会出现需求变更,并且这些变更会发生在项目的整个生命周期里,因此变更控制显得尤其重要,变更控制的管理好坏对项目成败有重要影响。论IT软件项目中的沟通管理【摘要】IT软件项目开发中最普遍的现象是一遍一遍的返工,项目工期一推再推,项目成本一再加大,客户需求不断提出,项目管理日益困难,造成这些普遍现象的一个重要因素就是沟通管理问题。沟通失败常常是软件项目成功的最大障碍。对于软件项目来说,要科学地组织、指挥、协调、控制项目的实施过程,就必须进行良好的沟通管理。【正文】1.建立适合组织的项目沟通管理体系1.1基于组织结构的沟通计划编制。沟通计划编制主要是确定项目干系人的信息需求和沟通需求;何人,在何时,需要何种信息,以及信息提供的方法。虽然所有项目都需要进行项目信息沟通,但所需要的信息和发布的方法差别甚远。因为项目的组织结构将在很大程度上影响项目的沟通需求,所以沟通计划的编制一定是在组织结构的基础上建立的。项目沟通计划是项目管理计划中的一部分,它的作用非常重要。在IT软件项目过程中经常会出现被动式、应付式沟通,造成项目随意而行、混乱无序。这种问题的原因主要是在早期项目计划阶段没有制定完善的沟通计划。在一个组织中,一般会有以往项目实施的沟通管理计划,在一个新的项目实施时,可以重复利用组织的过程资产,结合新项目的组织结构特点修订相应的沟通管理计划。从便于管理和节约的角度看,组织应该在各个项目间采取基本统一格式的沟通管理模版。一个沟通管理计划的样本模块主要包括分发给项目干系人的信息、信息分配的动机、信息分发的频率、信息分发的时间表、信息编排与传输方法以及项目成员沟通职责等。1.2信息分发。信息分发涉及向项目干系人及时提供所需的信息。信息分发的技术主要包括沟通技能,书面的、口头的,内部的、外部的,正式的、非正式的,纵向的以及横向的;信息查询体系,包括人工存档体系、电子数据库、项目管理软件以及允许查阅的诸如设计规范、测试计划等技术文档系统。信息发送方法,包括项目会议、书面文挡复印件的发布、共享的网络电子数据库、传真、电子邮件、语音邮件、电视会议和项目内部网。一般从信息的迫切性、项目环境的可能性等方面综合考虑确定何种技术和方法。1.3绩效报告。绩效报告是向所有项目干系人提供信息,主要包括状态报告、进度报告以及预测。一般使用项目日报、项目月报、召开阶段性会议、汇报等方式来提供有关范围、进度、费用、质量等信息。项目管理者可以基于绩效报告的有关信息进一步开展相关的偏差分析、趋势分析以及挣值分析。通常,项目绩效的分析通常产生对项目的某些方面变更的要求。1.4管理收尾。管理收尾包含项目结果文档的形成、归档,对符合最终规范的保证、对项目的成功、效果及取得的教训进行的分析。在收尾过程中,除了要注意使客户满意外,还应当使干系人都感到满意。2.存在的沟通障碍沟通贯彻于项目的整个生命周期中,沟通应保证信息的准确性、完整性、有效性。但在实际工作中,由于多方面的因素,信息往往被曲解、丢失或者失效等,造成了沟通的障碍。主要表现在以下几个方面:2.1不善沟通。有些IT开发人员善于使用开发语言来进行开发工作,面对着的是“哑终端”,但却不善于与客户沟通,不善于和同事交流,沟通、交流不到位、不及时,就只能一味迁就客户,全盘接收客户恰当或不恰当、合理或不合理的需求。结果是只能通过额外的工作加加点来解决。实际上,有些问题只需通过沟通就能解决,沟通到位了,便会事半功倍,根本不需要投入额外的工作量。2.2害怕沟通。有时候当项目进展不理想,实施中存在问题或矛盾时,项目成员往往因为担心受到批评和埋怨,不敢或不愿意汇报给上级,把问题和困难藏着、掖着,却不知已经失去了解决问题或困难的最佳时机。然而,藏着、掖着并不能解决问题,只能拖延,最后的结果可能是矛盾越积越大,问题越积累越复杂,直到实在兜不住的时候再爆发出来,那时候的局面就很难收拾。2.3想当然、满怀假设。用自己的假设来代替没有调研清楚的客户需求,想当然地认为客户的需求就是自己想的那样,而事实上,客户的真正需求和假设往往相反。这种以假设为依据的决策,往往因为假设是错的,结论也是错的。这种想当然的假设造成沟通障碍,势必引发诸多误会,造成很多返工。2.4信息失真。信息沟通主要是依据组织系统分层次逐层传递的。在按层次传达同一信息时往往会受到个人思维能力、表达能力、理解能力的影响,降低了信息沟通的效率,同时信息失真率也会增大。组织的机构越庞大,层次太多,将影响信息沟通的及时性和真实性。除以上几个方面,还有误解,主要是发送者在提供信息时表述不清晰或者接收者接收信息时不准确;表达方式不当,措辞不当,使用方言等,这些都会增加沟通双方的心理负担,形成双方沟通的障碍。3.沟通的技巧和方法3.1运用正确的表达方式。沟通必须目的明确。在信息交流之前,发送者应考虑好自己将要表达的意图,要力求简明扼要。用简单明了的词句表明自己的意思。漫无目的的沟通实际上就是通常意义上的唠嗑。发送人可以根据不同的沟通目的选择不同的沟通方式。在沟通过程中要使用双方都理解的用语和示意动作,并恰当地运用语气和表达方式。发送者有必要对所传递信息的背景、依据、理由等作出适当的解释,使对方对信息有明确、全面的了解。3.2提高倾听技能。沟通不仅仅是说,而是说和听。倾听既是我们取得关于他人第一手信息、正确认识他人的重要途径,也是我们向他人表示尊重的最好方式。在倾听过程中,我们可以使用目光接触,感知对方的心理和情绪变化,及时调整;可以展现赞许性点头和恰当的面部表情,复述对方所说的内容,表现出倾听兴趣,更有利于对方更好地说。要有耐心,不要随意插话,不要妄加批评和争论。3.3避免无休止的争论。在IT软件项目过程中,总会存在一些业务或技术的问题,而围绕这些问题的争论也时常是喋喋不休,永无休止。这种无休止的争论带来的结果是没有定论,不仅问题没有解决,而且延误了问题解决的时间。在IT软件项目沟通过程中,要极力避免这种无休止的争论,当遇到这种情况时,项目经理要果断决策。3.4保持畅通的沟通渠道。沟通固然重要,但如果没有畅通的沟通渠道,组织就必然呈现自发的无组织状态,就无法获得需要的真实的信息,整个组织的运转效能就会下降。随着组织规模扩大、人员增加、机构复杂、信息流量上升,就会出现信息阻塞、信息失真等沟通障碍,为使信息能有序的流动,管理者一定要建立稳定合理的信息传播体系,以便控制组织内部、外部的信息流动。3.5使用高效的沟通工具。在IT项目组织内,通常会使用相关的成熟的项目管理软件、电子邮件系统、办公自动化系统等工具来支持项目各种信息的生成、传递及存储的要求。这些工具的使用,大大提高了沟通的效率,拉进了沟通双方的距离,减少了不必要的面谈和会议。3.6把握沟通原则。一是沟通内外有别。即要求团队作为一个整体对外意见要一致,一个团队要用一种声音;二是非正式的沟通又助于关系融洽;三是采用对方能接受的沟通风格;四是沟通的升级原则,即第一步,和对方沟通;第二步,和对方的上级沟通;第三步,和自己的上级沟通;第四步,自己的上级和对方的上级沟通。五是扫除沟通的障碍。结束语沟通既是一门科学,更是一门艺术。沟通管理上的条条框框虽然是定死的,但可以灵活地去应用它。每个IT软件项目都具有自身的特点,沟通方法、沟通形式、沟通渠道都可能不同。但是无论怎样,作为项目管理者,必须保证项目在一个规则、和谐、合作、理解、沟通的环境下进行,因此,如何更好地把握项目沟通的原则,改善沟通技巧并灵活运用到实际项目中去,还有待于我们去进一步研究、探索、实践和总结。论信息系统项目的成本管理 摘要:成功的成本管理就意味着项目成功了一半。本文先总结笔者参与主持过的许多失败案例的成本管理过程中存在的问题。再以一个成功的成本管理案例承压设备和特种设备案例管理系统为例,首先概要介绍该项目的简介,接着介绍成本管理的主要内容,再结合本案例说明范围管理对成本估算的影响,详细介绍资源估算计划过程及本项目采取成本估算的方法以及以前失败案例的成本估算方法,然后介绍了项目预算的过程,最后介绍了有效的项目控制方法和如何利用挣值分析方法对项目进行绩效评估。笔者在该项目中担任了开发方的项目经理,参与了整个项目的设计开发管理过程,项目估算为320万元,为期半年,开发过程中运用了本文所介绍的成本管理过程,不仅按时完成项目,同时在成本管理方面取得可喜成绩,项目实际支出为270多万,为公司节约了近50万的预算成本。正文笔者参与管理过的众多项目中,在成本管理上曾经有许多失败的案例,这些项目完成后,实际使用成本都大大超出预算值,究其原因,大致有以下几种:(1) 对项目范围管理不够重视,忽略范围确认过程,导致项目后期变更频繁,直接影响项目成本上升。(2) 对项目风险估计不足,比如项目组成员流动太大的风险、项目组成员水平太低造成的风险等等。由于这些问题导致的项目进度、项目质量等原因产生的成本超支。(3) 亏本估算不够精确。比如采用经验估算和专家头脑风暴估算的成本估算结果准确程度较低。或者成本估算时太乐观或忽略了一些细节问题,比如项目组成员培训费用等。(4) 在进度和质量控制上力度不够,导致项目延期、返工率增加。(5) 在成本控制的关键环节缺乏行之有效的管理方法和流程。笔者于2005年10月开始主持承压设备和特种设备案例管理系统项目开发任务,该系统包括压力管道安全管理及图文分析子系统、压力管道定期检验管理子系统、压力容器安全管理子系统、压力容器定期检验管理子系统、特种设备(起重机、电梯、厂内车辆)安全管理子系统、特种设备定期检验管理子系统、锅炉安全管理子系统、锅炉定期检验管理子系统、承压设备和特种设备使用注册登记管理子系统等。该系统在总结了过去众多项目的经验教训的基础上,经过周密的成本估算,合理的预算及严格的成本控制,配合专家化的范围管理和严格的进度和质量控制,在成本管理方面取得了可喜的成绩。项目预算投入320万元,实际投入开以成本只有270多万,为公司节省了成本支出并按期完成了项目,获得客户的好评。成功的成本管理对控制项目成本超支现象起决定性作用。美国斯坦迪什咨询公司的研究结果说明信息系统项目完成时成本超出预算已经成为一种普遍现象,但是如果对项目成本进行详细的估算和切合实际的预算,并加以有效的成本控制手段,将项目成本控制在预算成本以内是完全的可能的。承压设备和特种设备安全管理系统是根据特种设备安全监察条例、压力管道安全管理与监察规定、在用工业管道定期检验规程、压力管道使用登记管理规则、压力容器安全监察规程、在用压力容器定期检验规程、锅炉使用注册登记规则、锅炉定期检验规程等有关国家法规要求的基础上开发的。系统内大部分管理内容都是国家强制性执行的,因此系统需求必须符合这些法规的规定。在需求确认阶段,我公司特地聘请中国机械工程学会压力容器和压力管道分会的高级专家对项目需求分析结果WBS工作分解结构作了一个详细的会审,会审的结果使项目的范围变更大大减少,为进行准确的成本估算打好坚实的基础。首先进行的是资源计划估计。利用专家会审过的WBS工作分解结构,对每项完成该交付物所需的资源和数量做出估计。这个过程中我们借鉴了以前公司开发过的一个类似项目设备及计量器具管理系统开发过程国的实际资源和数量的使用情况记录。这一过程的结果应该产生一份详细的资源需求清单,其中包括人员、材料、设备等关键信息。如果项目经理想在预算限制内完成项目,他们必须进行严格的成本估算。以往几个成本管理失败的案例的成本估算大部分采用的是类比估算法,这是由有关专家根据以往类似项目召开头脑风暴会议确定项目总成本,再将总成本按照WBS结构依次下传到最底层的活动。这种成本估算方法虽然简单易行,而且投入的成本费用也比较少,但是结果往往比较粗糙。为后续成本管理工作带来困难。考虑到本项目的需求范围法规约束性很强,经过专家会审的WBS工作分解结构在范围管理方面的误差已经很小,我们决定采取基于WBS工作分解结构的详细估算方法。根据完成的WBS工作分解结构和进度计划表就可以进行成本估算了。先对WBS最底层的要素进行详细的费用估算,再向上汇总至各项分工作、分任务的费用,最终得到项目和整个计划的累积统计。这个过程我们必须交付下列报告:(1) WBS结构各项要素的费用,各项分工作、分任务的费用;项目和整个计划的费用报表。(2) 每个部门的计划工时费用曲线。如果部门工时曲线含有峰谷,应考虑对进度表作出改变,以得到工时的均衡。(3) 逐月的工时费用总结。信息系统项目管理师网 以便项目费用必须削减时项目负责人能够利用此表和工时曲线作出权衡性研究。(4) 季度和年度费用分配表,此表以WBS要素来划分,表明每季度的所需费用,此表实际上是每项活动的先进流量的总结。(5) 原料及支出预测表。它表明供货商的供货时间、支付方式以及支付原料的先进流量等。基于WBS工作分解结构的详细估算方法本身需要大量的计算工作,工作量较大,估算过程需要一定的时间和费用。但是这种方法估算结果准确度较高,在估算的过程中可以采取一些现代计算机软件辅助计算。比如Microsoft Project2003、P3项目管理软件甚至是Microsoft Excel2000等。成本估算过程中还必须考虑一些容易忽略的费用。比如需要考虑一部分风险应急金和质量预防成本;必须对意外事件(通货膨胀、意外事故、项目延期处罚等)进行估计成本,列入成本估算时的考虑支出;另外可以提前考虑项目管理上产生的费用,估算项目管理储备金。最后,给项目估算总成本一个误差,例如本项目表示为32030万(为什么是30万,一般是20%偏差)。成本预算是将项目的成本估算分配到项目的各项具体WBS要素,确定各项工作和活动的成本定额,制订项目成本控制的基准。可见在基于WBS分解结构基础上的成本估算工作完成后,成本预算工作就很简单了。根据系统成本估算结果很容易得出成本总计和制订成本基准计划。用S曲线表示出各个时段(如各月、各季度、年度)的成本基准。它表明了项目的预期资金,便于项目经理在开销之前能提供必要的信息去支持资金要求,所以意义非常重大。另外,请注意项目预算的项目资金需求是成本基线与项目管理储备之和,项目管理储备不包括在项目成本基线之中。成本预算时也可以使用成本估算所用的计算机辅助工具。成本预算完毕后,在项目实施过程中,一定要对成本费用用实时记录,以便追踪实际花销是否按照项目预算进度来支出。在承压设备和特种设备安全管理系统的成本控制过程中,我们根据员工周报对已完成的项目交付物进行严格的质量控制和验证,实时更新项目绩效报告。根据阶段绩效报告利用挣值管理进行绩效测量。 根据阶段绩效报告计算实际成本(AC)支出,再根据成本估算结果获取在该阶段投入的计划成本支出(PV),利用绩效报告在成本基准计划中汇总已完成工作的总预算价值即该阶段的挣值(EV)。在获得、PV、EV之后就可以利用偏差分析和挣值分析技术进行项目绩效评估了。结束语经过上述行之有效的项目成本管理流程,承压设备和特种设备安全管理系统项目传问完成后不仅为公司节省了近50万元的预算支出,而且在进度和项目质量控制上也取得了不错的结果,获得了用户的好评。当然,这次成功的项目成本管理是一个难得的经验,是一项积极的组织过程资产。综上所述,我们看到信息系统项目的成本管理绝对不仅仅是处理一堆数据,它贯串于项目的始终,目的在于帮助项目经理更好地发现项目存在的问题并且为之采取必要的措施提供了依据,经验告诉我们,成功的成本管理就意味着项目成功了一半。论信息系统项目的成本管理摘要:成功的成本管理就意味着项目成功了一半。本文先总结笔者参与主持过的许多失败案例的成本管理过程中存在的问题。再以一个成功的成本管理案例承压设备和特种设备案例管理系统为例,首先概要介绍该项目的简介,接着介绍成本管理的主要内容,再结合本案例说明范围管理对成本估算的影响,详细介绍资源估算计划过程及本项目采取成本估算的方法以及以前失败案例的成本估算方法,然后介绍了项目预算的过程,最后介绍了有效的项目控制方法和如何利用挣值分析方法对项目进行绩效评估。笔者在该项目中担任了开发方的项目经理,参与了整个项目的设计开发管理过程,项目估算为320万元,为期半年,开发过程中运用了本文所介绍的成本管理过程,不仅按时完成项目,同时在成本管理方面取得可喜成绩,项目实际支出为270多万,为公司节约了近50万的预算成本。正文笔者参与管理过的众多项目中,在成本管理上曾经有许多失败的案例,这些项目完成后,实际使用成本都大大超出预算值,究其原因,大致有以下几种:(1) 对项目范围管理不够重视,忽略范围确认过程,导致项目后期变更频繁,直接影响项目成本上升。(2) 对项目风险估计不足,比如项目组成员流动太大的风险、项目组成员水平太低造成的风险等等。由于这些问题导致的项目进度、项目质量等原因产生的成本超支。(3) 亏本估算不够精确。比如采用经验估算和专家头脑风暴估算的成本估算结果准确程度较低。或者成本估算时太乐观或忽略了一些细节问题,比如项目组成员培训费用等。(4) 在进度和质量控制上力度不够,导致项目延期、返工率增加。(5) 在成本控制的关键环节缺乏行之有效的管理方法和流程。笔者于2005年10月开始主持承压设备和特种设备案例管理系统项目开发任务,该系统包括压力管道安全管理及图文分析子系统、压力管道定期检验管理子系统、压力容器安全管理子系统、压力容器定期检验管理子系统、特种设备(起重机、电梯、厂内车辆)安全管理子系统、特种设备定期检验管理子系统、锅炉安全管理子系统、锅炉定期检验管理子系统、承压设备和特种设备使用注册登记管理子系统等。该系统在总结了过去众多项目的经验教训的基础上,经过周密的成本估算,合理的预算及严格的成本控制,配合专家化的范围管理和严格的进度和质量控制,在成本管理方面取得了可喜的成绩。项目预算投入320万元,实际投入开以成本只有270多万,为公司节省了成本支出并按期完成了项目,获得客户的好评。信息系统项目管理师网 成功的成本管理对控制项目成本超支现象起决定性作用。美国斯坦迪什咨询公司的研究结果说明信息系统项目完成时成本超出预算已经成为一种普遍现象,但是如果对项目成本进行详细的估算和切合实际的预算,并加以有效的成本控制手段,将项目成本控制在预算成本以内是完全的可能的。承压设备和特种设备安全管理系统是根据特种设备安全监察条例、压力管道安全管理与监察规定、在用工业管道定期检验规程、压力管道使用登记管理规则、压力容器安全监察规程、在用压力容器定期检验规程、锅炉使用注册登记规则、锅炉定期检验规程等有关国家法规要求的基础上开发的。系统内大部分管理内容都是国家强制性执行的,因此系统需求必须符合这些法规的规定。在需求确认阶段,我公司特地聘请中国机械工程学会压力容器和压力管道分会的高级专家对项目需求分析结果WBS工作分解结构作了一个详细的会审,会审的结果使项目的范围变更大大减少,为进行准确的成本估算打好坚实的基础。首先进行的是资源计划估计。利用专家会审过的WBS工作分解结构,对每项完成该交付物所需的资源和数量做出估计。这个过程中我们借鉴了以前公司开发过的一个类似项目设备及计量器具管理系统开发过程国的实际资源和数量的使用情况记录。这一过程的结果应该产生一份详细的资源需求清单,其中包括人员、材料、设备等关键信息。如果项目经理想在预算限制内完成项目,他们必须进行严格的成本估算。以往几个成本管理失败的案例的成本估算大部分采用的是类比估算法,这是由有关专家根据以往类似项目召开头脑风暴会议确定项目总成本,再将总成本按照WBS结构依次下传到最底层的活动。这种成本估算方法虽然简单易行,而且投入的成本费用也比较少,但是结果往往比较粗糙。为后续成本管理工作带来困难。考虑到本项目的需求范围法规约束性很强,经过专家会审的WBS工作分解结构在范围管理方面的误差已经很小,我们决定采取基于WBS工作分解结构的详细估算方法。根据完成的WBS工作分解结构和进度计划表就可以进行成本估算了。先对WBS最底层的要素进行详细的费用估算,再向上汇总至各项分工作、分任务的费用,最终得到项目和整个计划的累积统计。这个过程我们必须交付下列报告:(1) WBS结构各项要素的费用,各项分工作、分任务的费用;项目和整个计划的费用报表。(2) 每个部门的计划工时费用曲线。如果部门工时曲线含有峰谷,应考虑对进度表作出改变,以得到工时的均衡。(3) 逐月的工时费用总结。信息系统项目管理师网 以便项目费用必须削减时项目负责人能够利用此表和工时曲线作出权衡性研究。(4) 季度和年度费用分配表,此表以WBS要素来划分,表明每季度的所需费用,此表实际上是每项活动的先进流量的总结。(5) 原料及支出预测表。它表明供货商的供货时间、支付方式以及支付原料的先进流量等。基于WBS工作分解结构的详细估算方法本身需要大量的计算工作,工作量较大,估算过程需要一定的时间和费用。但是这种方法估算结果准确度较高,在估算的过程中可以采取一些现代计算机软件辅助计算。比如Microsoft Project2003、P3项目管理软件甚至是Microsoft Excel2000等。成本估算过程中还必须考虑一些容易忽略的费用。比如需要考虑一部分风险应急金和质量预防成本;必须对意外事件(通货膨胀、意外事故、项目延期处罚等)进行估计成本,列入成本估算时的考虑支出;另外可以提前考虑项目管理上产生的费用,估算项目管理储备金。最后,给项目估算总成本一个误差,例如本项目表示为32030万(为什么是30万,一般是20%偏差)。成本预算是将项目的成本估算分配到项目的各项具体WBS要素,确定各项工作和活动的成本定额,制订项目成本控制的基准。可见在基于WBS分解结构基础上的成本估算工作完成后,成本预算工作就很简单了。根据系统成本估算结果很容易得出成本总计和制订成本基准计划。用S曲线表示出各个时段(如各月、各季度、年度)的成本基准。它表明了项目的预期资金,便于项目经理在开销之前能提供必要的信息去支持资金要求,所以意义非常重大。另外,请注意项目预算的项目资金需求是成本基线与项目管理储备之和,项目管理储备不包括在项目成本基线之中。成本预算时也可以使用成本估算所用的计算机辅助工具。成本预算完毕后,在项目实施过程中,一定要对成本费用用实时记录,以便追踪实际花销是否按照项目预算进度来支出。在承压设备和特种设备安全管理系统的成本控制过程中,我们根据员工周报对已完成的项目交付物进行严格的质量控制和验证,实时更新项目绩效报告。根据阶段绩效报告利用挣值管理进行绩效测量。信息系统项目管理师网 根据阶段绩效报告计算实际成本(AC)支出,再根据成本估算结果获取在该阶段投入的计划成本支出(PV),利用绩效报告在成本基准计划中汇总已完成工作的总预算价值即该阶段的挣值(EV)。在获得、PV、EV之后就可以利用偏差分析和挣值分析技术进行项目绩效评估了。结束语经过上述行之有效的项目成本管理流程,承压设备和特种设备安全管理系统项目传问完成后不仅为公司节省了近50万元的预算支出,而且在进度和项目质量控制上也取得了不错的结果,获得了用户的好评。当然,这次成功的项目成本管理是一个难得的经验,是一项积极的组织过程资产。综上所述,我们看到信息系统项目的成本管理绝对不仅仅是处理一堆数据,它贯串于项目的始终,目的在于帮助项目经理更好地发现项目存在的问题并且为之采取必要的措施提供了依据,经验告诉我们,成功的成本管理就意味着项目成功了一半。论软件项目管理中的质量控制摘 要我国软件业与世界先进国家相比,差距甚远,其主要原因是软件工程化技术没有得到广泛的应用。今天,软件开发不再是软件开发人员的个人行为而是团队行为,对软件开发机构来说,如何在要求的时间内、合理的投资下保质保量地交付软件产品是一个巨大的挑战。无论是在软件水平最高的美国还是在我国,软件开发项目超期、超预算、最终的软件产品的质量不能使最终用户满意等问题,都是困扰软件开发机构的重大问题。本文从建立专职质量提升组织、软件开发过程的质量识别与控制、完善的测试手段与软件过程能力成熟度模型的应用等方面来叙述提高软件的质量控制的途径。关键词软件工程 项目管理 质量控制 测试手段 成熟度模型一、引言在国内软件业开始诞生和起步的时候,软件企业在质量管理方面比较落后,大部分的软件企业没有设置专门的测试组织。软件产品的质量完全依赖于程序设计和编写者的技术水平和工作效果。这种依赖使得软件产品的质量水平低下。虽然国内一些软件企业在2000年左右开始建立内部的测试小组,但仍然只起到了“事后检验”的功能,大部分产品质量缺陷仍然无法及时和较全面的被发现和解决,更不用说“预防缺陷”。即使这种具有“事后检验”功能的测试小组被建立,但由于没有必要的支持,以及人力资源投入严重不足,导致测试小组在软件质量上的贡献和业绩表现并不佳。同时由于对产品质量的认识缺乏全面的理解,仅仅建立一个测试小组对产品质量的提升很有限。随着中国WTO的发展步伐,国内涌现出了越来越多的软件企业,其中以外包企业为主,外包软件开发公司一般都需要取得一定的资质认证才能够接到来自国外的委托项目,其中以CMMI(或CMM)认证为主。国内软件行业即将迎来一个新的发展时期,规范与规模化。二、建立专职质量提升组织在开发项目上按照规范化软件的生产方式进行生产,在开发质量管理流程上采用ISO9000的标准进行。每个项目除配备了项目开发所需角色外,还需专门配备配置管理小组、测试小组和质量保证小组确保质量管理的实施。(一)配置管理小组职责配置管理小组是保证项目开发完毕的同时,内部文档和外部文档都同时完成。内部文档的及时产生和规范,是保证项目开发各小组能够更好地接口和沟通的重要前提。从另一个方面讲,也是保证工程不被某个关键路径所阻塞而延滞的前提。配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括:完善各个部门发送需要存档和进行版本控制的代码、文档和阶段性成果;对代码、文档等进行单向出入的控制;对所有存档的文档进行版本控制;提供文档规范,并传达到开发组中。(二)测试小组职责测试小组作为质量控制的主要手段,负责软件的测试设计和执行工作。如同软件开发一样,测试在执行之前,同样需要进行测试计划和测试策略的设计,通常情况下测试可以分为:正确性、功能性、性能、安全和系统测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试,确保程序编译、运行正确。测试人员根据详细设计的文档对软件要实现的功能进行一一测试,保证软件的执行正确的实现设计要求,在此也只证明了软件正确地反映了设计思想,但是否真正反映了用户的需求仍需要进一步的功能性测试。测试人员只有根据软件需求规格说明书所提及的功能进行检测,才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后,需要测试的是软件的性能,软件的性能在项目中占有重要的地位,性能要求有可能改变软件的设计,为避免造成软件的后期返工,测试在性能上需要较大的侧重。测试小组还需要做安全测试,以确保系统使用安全可靠。(三)质量保证小组职责质量保证小组作为质量保证的实施小组,主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告,提出差异原因和改进方法。在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时,提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上,因而文档版本的控制,特别是软件配置管理,直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括:系统分析人员是否正确的反映了用户的需求;软件执行体是否正确的实现了分析人员的设计思想;测试人员是否进行了较为彻底的和全面的测试;配置管理员是否对文档的规范化进行得比较彻底,版本控制是否有效。三、软件开发过程的质量识别与控制对于质量管理来说,结果很重要,过程也很重要。 (一)获取过程质量有过程就必然有过程质量。软件产品是需要经过一系列的过程才得以形成的。根据软件工程理论,在瀑布式软件开发过程中定义了软件产品的基本开发过程:需求分析规格说明概要设计详细设计代码编写/单元测试集成测试系统测试。软件工程的基本目标是优质、高产。为了保证所开发的软件的质量,在瀑布模型的每个阶段都应该坚持两个重要做法:1.每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介,也是运行时期对软件进行维护的重要依据。2.每个阶段结束前都要对完成的文档进行评审,以便尽早发现问题,改正错误。事实上,越是早期阶段犯下的错误,暴露出来的时间就越晚,排除故障改正错误所付出的代价也越高。因此,及时审查,是保证软件质量,降低软件成本的重要措施。瀑布式软件开发过程:(1)在软件需求定义阶段会产生“需求质量”;(2)在软件设计阶段会产生“设计质量”;(3)在软件实现阶段会产生“实现质量”。(二)过程质量控制过程质量控制=规范+输入/输出标准+反馈(控制点或检查点)从整个研发过程看,需要制定一些规章制度和项目研发规范来使工序部门之间的工作能够协调开展,比如设置工序部门的工件输入、输出标准,让质量低下的工件不会流入下一个工序环节,起到“缺陷预防”的作用。如果我们单独看某一个工序部门,如负责需求分析的产品组,为了确保需求描述文档的准确性与易读性,可以制定一种“需求设计规范”或“需求文档编写规范”来使需求设计工作实现内部理解一致,即让需求分析人员编写出格式统一,表述统一的需求文档。这样的文档才能便于程序员去理解和实现,同时测试人员也可以从这样的高质量需求文档中获益,提高测试工作质量。同样地在程序设计方面,可以制定“程序设计规范”、“代码编写规范”来实现程序设计质量的提升。3将软件最终质量分解到过程中,为:“需求质量”、“设计质量”、“实现质量”、“发布和维护质量”。质量控制点一般设置在工序节点处,这样比较经济一些。控制点一般采用“评审”或“审查”为主,当然技术手段也很重要。(三)需求管理与质量目前,迭代式开发方式已基本替代了瀑布式开发方式而被越来越多的软件企业所采用。迭代式开发方式主要解决了风险与需求变更问题,那么需求管理在迭代式开发方式中也显得极为重要,需求管理好了,项目开发过程将会事半功倍,开发将会有节奏,项目可视化程度将会得到提高;需求管理不好,项目将面临频繁返工、功能混乱、重构代码工程次数高、测试用例维护成本增长和工作低效率、低质量的境地。论大型信息系统项目的风险管理 摘要2008年6月,本人参与了“党校教学教务管理系统”的项目建设,担任项目经理一职。这是一个集教务工作自动化和信息化为一体的先进计算机网络系统,将为党校教务管理有关部门提供优质、稳定的信息化服务。该项目做为省委党校的教务管理重点工程,受到省委及校领导的高度重视。做为建设方的项目经理,本人在项目的风险管理过程中,科学的运用项目风险管理的理论知识,结合自己的项目实践,在项目的实施过程中,将风险管理当做一项重点的工作来抓,依照风险管理计划编制、风险识别、风险分析、风险应对计划编制、风险监控等过程,全面展开对风险的管控,使得项目顺利进展,保证了项目的工期、成本及质量,受到用户方的高度评价。正文一、项目概述随着党校教学规模的扩大、教学模式发生了转变,使得学校教学教务管理任务越来越重,不仅增大了工作量、更是增大了工作难度。这些根本性变化的同时也对学校的教务管理提出了更高的要求,为了适应这些新变化,提高教学教务管理的工作效率,建立一套完整统一、技术先进、高效稳定、安全可靠的基于Internet/Intranet的教学管理信息系统成为当务之急。信息系统项目管理师网 作为党校IT核心支撑系统,要求为教务教学管理提供IT支撑。学校通过本系统可以实时了解教务管理情况和学员反馈情况,有利于提高教务管理水平。本项目内容包含学校招生管理、教研计划、教务处理、教学质量管理、教师考核管理、学生档案管理等。通过公开招投标,我公司终以绝对的优势取得了该项目的承建权。该系统为支持党校教务管理工作的核心系统,为教务教学管理提供IT支撑。该系统采用B/S模式开发,使用J2EE技术,提供web访问模式。其面向的使用对象包括省委党校及下属各分校的教务工作人员、教师及学员,为其提供各类综合性服务。工作人员通过本系统完成所有的日常教务工作。从招生到学员毕业离校,其在校内的所有和教务相关的数据都通过教务系统进行管理。学员则可以通过系统进行网上报名、选课及查询自己的个人相关信息(教学计划、课程表、成绩等)。教师则可以查询自己的课程安排,上传课件,录入学员成绩,查询教师业绩考核情况等。项目启动后,本人被公司任命为该项目的项目经理,全面负责项目的建设工作。在省委党校领导的亲切关怀下,项目各组干系人的通过配合与支持下,我与项目组全体成员一起并肩作战,通过近10个月的努力,终于在2009年3月3日全面通过系统验收,项目总花费

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论