软考信息系统项目管理师论文范例.docx

软考信息系统项目管理师论文范例.docx

《软考信息系统项目管理师论文范例.docx》由会员分享，可在线阅读，更多相关《软考信息系统项目管理师论文范例.docx（24页珍藏版）》请在冰点文库上搜索。

软考信息系统项目管理师论文范例

信息系统项目管理师论文例1：

论软件项目的进度管理

摘要

本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责人，承担了项目管理工作．

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。

本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质量完成．本系统在电力系统已经运行，状况良好，受到一致好评．

正文

2003年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作．电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。

工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行．有效地防止不规操作，确保电力设施及现场工作人员的安全，提高安全意识．本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标准，同时为第二部分提供操作对象．工作票、操作票签发系统主要是在系统图的基础上进行点击操作，每饮点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规．

在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。

1、合理的估算项目工作量及技术难度

我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则．

本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根据功能点进行估算．将每个功能模块逐步分解，直至基本模块为止．我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。

系统图编辑部分主要是一个图形编辑系统．一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方法，电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，这些类又继承一个最基本的类．系统图编辑部分的工作量也就是这些类的实现，工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统图编辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算．

同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的案例，因此有不少的案例供我们参考．对于本系统的第二部分我们就是借鉴以前我们做过的基于C/S结构的系统，基于C/S结构的系统的框架基本上是一致的，数据库的设计、前台操作如对数据库进行添加、删除、修改、查询等一系列活动大体相同．正是如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改．在工作量的估算上也有很好的借鉴作用．这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据．在技术上，我们重点考虑本系统与其他C/S结构的系统的不同之处，相同或相似之处我们认为没有技术难点．系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十分完美，我们采用了Form++这个MFC扩展类库，这个扩展类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美．同时减少了工作量，在工作安排上，技术难度相对大一点的部分我们安排经验丰富的程序员，同时也同其他工作组的成员商讨技术细节间题，同他们进行技术探讨．这样不至于因为某一技术细节而影响整个工程进度．

根据上述分析我们制定一个详细的进度表并定义相应的里程碑．

2、识别关键任务

系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础之上，系统图编辑部分直接影响到整个项目．因此该部分是整个系统的关键部分，在这部分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作．工作票、操作票签发部分，是用户明确提出的要现的功能，直接面对用户，这部分的成功与否直接影响到该系统的质量，因此也是不容忽视的．如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁．因此是本项目的关键任务．在进度控制时我们将其作为重点对象进行控制．

3、随时了解项目进度，必要时调整进度表

在确定项目开发计划时，我们制定了详细的进度表．我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间．同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划．工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成品对自己的工作都要做工作日志，对自己每天的工作做详细记录．每周对自己的工作进展做出结论，向项目组汇报．在做结论时，不得使用“差不多”、“大概”、“完成了90%”…等模糊字眼．而是采用某任务“已经全部完成”、或者“90%的工作全部完成”或者“再过1天全部完成”…等方式．每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础．同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划．在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标准，这些类（包括其父类）的实现完成又为一个里程碑，……整个系统图编辑部分完成也是一个里程碑．每个里程碑的标准在系统设计时已经定义好．

结束语

《电力行业工作票、操作票系统》目前已经开发完毕，运行状况良好，受到一致好评。

在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员的各有特长，面向对象技术不是每个小组成员都熟练掌握，加之面向对象技术在我们公司还不是很成熟，必须有一个过渡，不能一下子转型，因此采用该种策略符合我们公司的现实情况。

由于项目进度管理得当，项目按期完成，我们小组赢得公司的好评，其他小组也研究我们的管理方式。

当然项目管理方式多种多样，根据项目不同、人员不同管理模式应做调整而不是一成不变。

适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中取得的效果是不同的，这有待于我们去研究，探索，实践，总结．

信息系统项目管理师论文例2：

论软件项目计划的制定

摘要

本文讨论了一个作者参与的软件项目的项目计划制订的若干问题．项目所开发的产品是一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写容显示在计算机屏幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机．

作者是该项目的软件开发组负责人兼软件架构师．作者针对项目计划的制定采取了：

分而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果．

正文

2002年6月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地将用户在硬件端的书写容显示在计算机屏幕上，用户可以保存、编辑、打印通过硬件端输入到计算机的书写容，联网的计算机也可以实时观看用户的书写过程．另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机．作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构架师的角色．对于这种实时通信且具有联网功能的软件项目，我认为首先需要制定一个良好的项目计划，才可以保证项目开发的成功．总结这次项目的经验，我认为行之有效的策略有三个，分别是分而治之、逐步求精、经验数据。

下面就结合这三个策略详细讨论本次项目计划的制订。

一、分而治之

将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀，这种方法人类已经采用了几千年．这里我们也可以用于项目计划的制定．因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力．为了解决这个问题，可以将整个项目分解为一些更小的组织体，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。

比如针对这次项目中采取的RUP开发过程模型，我在完成需求管理计划时我就将计划容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划．除了按时间段分解的角度来制定项目计划，我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。

因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的．同时因为本项目的特点，我省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不是那么必要了．以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生．

二、逐步求精

计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自身无法掌握的因素，因此存在很大的难度．而解决这一困难的法宝就是逐步求精．按照先框架后细节，先粗后细地进行项目的计划．比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的容主要是做出时间上的安排．因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了2003年4月，预留一个月用于写申请报告．总的时间进度确定后，大概分配了三个时间段：

系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结．等到确定这改项目后的RUP开发模型后，就可以继续对项目计划进行第二改求精了。

其实RUP过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品．这样我就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段我再具体地制定每类计划的详细容．比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时我就可以根据所需开发的模块制定计划。

比如这时我就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整．

三、经验数据

要制定一个良好的计划离不开精确的估算．不过项目计划是在项目开发的早期制定的，而在早期要完成精确的估算是非常困难的．要解决这个问题的关键就在于“经验数据”．由于整个软件产业都还十分年轻，经验数据的积累都普遍不足，才导致这一现象的出现．但是因为这次项目开发的产品在国还没有开发过，再加上公司没有积累深厚系统的项目历史数据．针对面临的困难，我选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。

为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整．Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法．当然，请专家增加了项目成本，不过最后得到高质量的项目计划还是值得的．比如，在某专家的建议下我们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的中间件产品，这个策略的调整在后来证明是正确的．一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了．最后谈一下使用的工具软件．在制定项目计划过程中我采用了Microsoft的Project2003绘制甘特图．因为项目的进度安排是和项目中每个人都是息息相关的，所以在做甘特图前我首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的颜色标识关键任务，放大任务摘要信息，突出里程碑信息等．这在有些项目管理者看来似乎是小事，不过我认为一个赏心悦目的甘特图可以带给观看者好的心情，而好的心情可以大大提高工作效率。

同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依赖关系时我采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”我填入5%-15%，也就是说当任务完成90%左右时就可以结束转而执行下一个任务．因为本项目中的所有人员几乎是全程参与，所以我不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。

配合Project2003使用的估算软件是SoftwareProductivityResearch的KnowledgePlan.这款工具软件的最新版加强了对MicrosoftProject2003以及RUP开发模型的支持，而且其中的ProjectTemplate功能允许用户采用自己定制的WBS来进行估算，这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助．

在上述三个策略的指导下，以及合适工具的辅助下，使最后形成的计划有效地指导了后期的开发活动。

项目开发出来的产品通过了专家的鉴定，获得了国家中小企业创新基金的支持．

项目完成后发现的问题是早期计划的估算结论偏差还是较大，看来还是受到缺乏经验数据或者经验数据不够精确的影响，所以在以后的工作中需要开展有效的度量的工作，为公司积累覆盖面广且尽量精确的经验数据．

信息系统项目管理师论文例3：

论软件开发成本管理

摘要

2004年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理．系统基本功能包括：

业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块．系统采用Struts+Hibernate主流Web应用框架，实现Web应用程序服务器WebSphere与协作应用程序服务器LotusDomino的高度集成．

项目的成功很大程度上归功于在项目过程中各个阶段对进度和成本的有效管理和控制。

本文以该项目为例，结合作者实践，讨论了信息系统项目中的成本管理问题，主要通过在计划阶段做好工作量估算，有效管理和控制风险因素，在实施阶段进行成本跟踪和控制等方法来有效管理和控制项目成本．实施结果…

正文

2004年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理．当然也做一些编码工作，主要是基础性公用代码和关键核心代码的编写与维护．授信是指银行以自身信用向客户提供贷款（包括项目贷款）、担保、开票信用证、汇票乘兑等业务，授信业务是商业银行资金运作中最为重要的业务之一。

开发授信业务系统，提高授信业务的管理水平和运行效率、充分利用共享的信息资源、减小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义．系统基本功能包括：

业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块．系统全面实现授信业务的网上操作，实现流程的上报，审批和管理，大大提高了授信业务工作效率。

提供了强大的业务查询和统计功能，便于对授信业务工作的管理和监督．其中业务操作模块实现授信业务工作流程，主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程．

系统采用Struts+Hibernate主流Web应用框架，开发工具采用WebSphereStudioApplicationDeveloper5.0（WSAD5.0），WSAD5.0集成并扩展了Eclipse2.0的功能．硬件配置方面：

IBMP610小型机用于安装WebSphere5.0，DELL服务器用于安装DominoR6和SQLServer2000。

实现Web应用程序服务器WebSphere与协作应用程序服务器LotusDomino的高度集成，并使用SingleSignOn（SSO）实现单点登陆．总体架构思想，将表单数据的生成和分析采用关系型数据库来实现，通过WebSphere架构实现业务逻辑的处理，而表单的审核流程由Domino进行驱动．将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合．

由于考虑到银行年度等因素，客户要求系统在2004年12底前交付，项目开发周期为4个月。

项目人员配备情况，项目经理l人，开发人员4人，测试人员3人，界面美工人员1人，项目行政秘书1人，配置管理人员1人，质量管理人员1人．其中开发人员小来自某某银行科技处．项目行政秘书、配置管理、质量管理等人员为兼职人员，为多项目共享。

由于公司属于大型软件企业，在项目基础设施方面包括开发服务器、开发机、测试服务器、配置管理服务器、开发工具等配备状况较好。

软件成本管理是软件项目管理的一个重要组成部分，也是一个十分容易被忽视但却又是十分重要的容．成本管理的目的是通过执行项目成本管理过程和使用一些基本项目管理工具和技术来改进项目成本绩效。

项目组整体上把按进度和预算交付项目作为我们最大的挑战，因此我们十分重视对项目进度和成本的控制和管理．该项目中我们借助项目管理软件MicrosoftProject2003来辅助进度和成本的计划和管理．我们主要通过在计划阶段做好工作量估算，有效管理和控制风险因素和在实施阶段进行成本跟踪和控制等方法和策略来有效管理和控制项目成本．

1、计划阶段做好活动历时（工作量）估算

项目需求分析阶段结束，《软件需求说明书》得到客户正式签字确认后，我们开始创建工作分解结构WBS和制定详细项目进度计划．我们认为工作量估算是成本估算的基础，对于项目成本管理＋分关键．由于对代码行（LOC）估算、功能点（FP）估算等估算方式研究不是很深入，工作量估算主要采用基于公司项目历史绩效数据库和个人经验的估算方法．对于部分涉及流程的活动单位一般比较难一次性把握其活动的历时，事实上流程调试的工作量在页面基本功能（增加/删除了修改）的3倍工作量以上．例如业务操作模块——问题类授信业务申报——问题类客户行动计划申请流程页面提交工作量为2日/人，而流程调试需要涉及20多个角色和8条路径．对于估算把握不是很好的任务，我们一般通过提供一个乐观估算A、悲观估算B、正常估算M进行3次估算然后利用PERT公式[1（4*M+A+B）/6]计算取整．每项活动我都先确定具体人员，然后需要对活动本身进行详细分析，必要时查看公司项目历史绩效数据库。

最后需要为各项活动建立了依赖关系，明确各项活动的前置任务，活动开始时间和结束时间．总体上讲活动历时估算工作量较大，我花费了数个工作日．

项目组人员流动率较低，在J2EE和Struts架构下的WEB应用开发已经有一定的项目积累和团队合作基础．如项目组自行开发了功能完善的Struts-config.xml统一维护工具，实现了FormBean和ActionBean方便管理。

有大量可供复用的东西，如公共基础代码包，权限管理模块等．这些也是在我们工作量估算中需要考虑的因素．

2、有效管理和控制风险因素

项目中我们对项目风险进行了必要的管理，以避免风险事件的发生引发项目成本增加或超支．公司项目管理部门提供了风险管理计划的模板和风险事件列表模板．为了让项目组整体在各个阶段保持良好的风险意识，我尝试采用了“十大风险事项跟踪”，把项目中各主要风险事项按照排名贴在公告栏上．由于当时有部分未明晰的需求包括：

①问题类客户行动计划申请流程；②查询统计部分需求；③客户方面可能提出的新需求．需求和围界定不清、计划不充分、用户参与不足、缺乏领导支持、技术问题等为我们项目计划阶段主要风险事件．事实表明，这种做法效果是非常明显的．特别是客户方面，我定期把风险事件列表Email给客户方项目负责人方某．为了能尽快落实未明晰的需求部分，我与客户方主要项目负责人方某进行了面对面的沟通．通过一番利弊关系的述，达成尽快明晰悬留部分需求的共识．需求问题很快得到解决．项目组整体信心十足，积极性和责任感增加．公司领导方面对项目组也表现出特别的关心，特别是公司总开始频繁出现在项目组的每周进度评审会议上，他们也开始担心因为对项目支持不够而导致项目的失败．

3、实施阶段进行成本跟踪和控制

实施阶段需要进行成本的跟踪和控制．Project2003中需要设定各项资源（人员）的工时标准费率，即人员每小时的工作成本．项目组成员每周五下班前通过网B/S项目管理信息系统PMIS提交《项目周报》，把各自本周完成的任务进度情况和下周任务计划进行汇报．报告要求按百分比严格量化任务完成情况，PMIS只提供具体百分比的选择．项目经理（我）把各项任务实际完成数据输入到进度计划中，Project2003自动成本统计表，清楚显示任务基准和实际成本信息．通过查看跟踪甘特图就可以较好把握项目总体的进度绩效．

授信业务系统在2004年12月下旬正式上线，提前1周完成了项目．目前系统运行正常，受到客户方各有关部门的一致好评，对项目满意度较高．项目的成功很大程度上归功于在项目过程中各个阶段对进度和成本的有效管理和控制．没有成本管理，项目也可能成功．但没有成本管理的项目，对于项目管理质量、时间、成本三大目标的实现是具有巨大风险．

信息系统项目管理师论文例4：

论软件开发的风险管理

摘要

本文讨论了某公司实施SAP系统的风险管理．该公司原先运行着一套ERP系统，现在要转到SAP上，需要完成新系统的流程的重新定义，数据的切换，用户的培训等工作．项目要求在11个月的时间完成．实施一个大型的ERP系统有着各种的风险，这些风险如果不加分析和控制，将会给整个项目造成致命的影响．我作为项目经理，主要从控制进度风险，人员流动风险和系统功能风险三个方面去进行风险的管理．最后这三方面的风险都得到了有效的控制，从而使项目顺利完成．

正文

2003年1月，我参与了西门子集团下某公司的SAP留系统的实施，提任项目经理．该公司之前运行着另一套ERP软件：

QAD的MFG/PRO系统．由于集团总部的要求，要用SAP系统替换原先的MFG/PRO系统，并且要在2003年11月前完成．整个项目完成以下阶段，首先是项目的引进，包括成立项目小组，由顾问对项目小组成员进行初步的培训，让小组成员对SAP的标准流程有个大概的认识．接下来是要分模块进行讨论，制定出各模块的实施蓝图（blueprint）．该公司实施了以下的模块：

SD（销售与分销），MM（物料管理），CO（成本控制），QM（质量管理），PP（生产控制），FI（财务核算），CO（成本控制）等．在Blueprint完成后，由顾问根据定下的流程配置一个测试的系统，用户在该测试环境下进行练习和测试．测试完成后就是数据的准备和切换了，要从MFG/PRO系统把需要的数据下载下来然后你上传到SAP系统。

完成数据的切换，SAP系统正式上线，同时不再使用原先的