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

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

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

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

信息系统项目管理师论文例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对本项目的项目计划成功制定带来很大的帮助。

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

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

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

信息系统项目管理师论文例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系统正式上线，同时不再使用原先的系统。

　　因为整个项目要在11个月的时间完成，时间是非常紧迫的．如何在如此短的时间使项目能顺利进行，控制各种可能出现的风险是必要的．为此，在项目的初始阶段，我召开了小组成员开会，专门针对项目的风险进行了讨论．会上，大家把想得到的风险都提了出来．经过分析筛选，我最后确定了三个重点进行控制的风险，并采取了相应的措施进行控制．

　　1、控制进度风险

　　ERP的实施是一个大型的项目，涉及到企业的流程改造和其它方方面面的东西．而该项目的上线时间不能改变，所以，项目进度在这里是个潜在的风险，如果不能如期上线，则公司的运作将会受到重大的影响．为此，我在项目启动后，召集了项目小组成员开会制定项目计划．我首先用MicrosoftProject制定了项目的总体计划，在这个总体计划中，明确了各个阶段的任务和完成时间．如什么时候完成设计蓝图（Blueprint），什么时候进行关键用户的培训，什么时候进行测试和练习，什么时候进行数据的切换等．总体计划制定出来后，各顾问在总体计划下制定各模块的实施计划，把每个模块在每一阶段的问题细化．各模块的实施计划要在总体计划的基础上进行，在任务和时间上不能滞后于总体计划．无论是总体计划和实施计划，都要求明确各步完成的时间，要精确到哪一天，而不能用模糊的描述，比如“3月初完成Blueprint”这样的低描述是不充许的．为保证项日照进度进行，每周五都要召开项目会议，检讨项目的进展情况，发现有超期的任务，分析原因，及时解决．在进度的控制方面，还要应付突发的事件造成的影响，及时地调整计划以适应新的情况．2003年4月一5月，由于受到“非典”的影响，外部顾问不能出差来我公司，这使项目的进度受到了很大的影响．为了把这种影响降到最低，我即时调整了项目计划，把这段时间安排为关键用户的培训和对系统的熟悉。

因为之前顾问已对关键用户进行了一些培训，所以用户对SAP系统有了一定的认识．通过上机的操作，更进一步了解系统．有问题我们通过E-Mail与顾问联系。

通过这种方法，把原本以后进行的用户练习提到了前面．虽然没有顾问的现场指导，但通过自己的摸索对系统的印象更加深刻，为之后的工作打好的基础．

　　2、控制人员流失的风险

　　在实施SAP过程中，有两种可能会导致人员的离职，一是工作繁重乏昧，压力大；二是积累了一定的SAP经验后找工作相对比较容易，这时如果有其它更好的机会，员工会考虑跳槽．而项目小组人员流动将会对项目造成很大的影响，甚至导致项目的失败．所以如何控制这些风险，是作为项目经理要考虑的问题．为此，我首先与人力资源部一起，制定了一套有效的激励机制．包括，把参加SAP项目作为年终的一个绩效考核容，因为项目需要加班加点的，公司免费提供晚餐；设立项目基金，对表现突出的小组成员进行物质上的奖励；在整个公司的围大力宣传SAP，让项目小组成员感觉到SAP的重要性和实施项目的价值等．其次，为了避免出现某个项目小组成员离职导致项目不能进展的情况出现，我在每个模块都安排了两个人员负责，一个是主负责，一个是次要负责．这样，可以减少人员流失造成的损失。

在这里，我没有采用让项目小组成员签合同的方法，即实施项目后要在公司工作多少年。

我觉得这种方法会给小组一种压抑的感觉，而公司主要靠企业文化来吸引员工．事实证明，我所采用的措施是有效的：

在整个项目的实施过程中，没有一个小组成员退出或是离职．在项目运行一年多来，只有两个当时的关键用户离职，而他们离职后后备人员可以马上顶上来，对系统没有造成什么影响．

　　3、控制系统的功能

　　有人戏称SAP是“StopAllProduction”，这也从一个方面反映了实施SAP的风险所在．而造成上了系统后停产的一个原因就是系统功能不能满足物流和生产的需要，这也是我担心的一个问题．因为切换后系统不能再使用，如果这时候新系统满足不了需要，就真的会造成停产．为此，我在项目中采用了演化型的原型开发方法，用演化型的开发方法，可以让用户针对已配置好的原型进行测试，发现不能实现的功能及时提出来，改进后再测试，再改进．在这里，测试工作显得很重要．为此，我强调一定要做好测试工作．在系统测试阶段，我把所有的项目成员集中在会议室中进行系统测试．在测试中，我要求用真实的数据，模拟真实的环境进行．系统测试通过后，我还特别做了一次上线前的演习，即把所有相关的数据都导致SAP，配置一个上线后要用的系统，在此系统上进行操作．这次演习成功后，坚定了大家使用系统的信心．系统上线后也没有出现什么大的问题．

　　通过以上措施，使把SAP的主要风险基本上都控制在萌芽状态，项目没有因为这些风险受到影响，最后项目如期上线，受到了管理层和用户的肯定．

　　在项目进行过程中，有些风险并没有事先预计出来．比如说顾问的问题．有的顾问水平高，但项目也多．用在我们这个项目上的时间就比较少，这给项目带来了不利影响．为此，我通过和该项顾问所在的公司签定合同，注明顾问在我们公司的工作时间，否则属违约，通过这一方式使顾问的管理得到改善．

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

利用CMM保证软件质量

　　【摘要】

　　本文论述了如何在一个规模较大的网上管理系统的开发中结合CMM二级的框架要求，以及软件工程学的质量保证策略进行项目的软件质量保证工作．

　　本项目的特点有：

（1）开发人员多，有40人左右；

（2）采用面向对象分析与建模技术，JAVA语言，WebLogic应用服务器等以前项目中未采用过的开发模式和技术．因此不确定性因素很多，急需采用有效的质量保证策略．公司为了提高软件开发能力，已经于近期全面引入了当今软件界正在流行、且行之有效的CMM质量保证体系，并在顾问公司和主评审员的帮助下，由公司的SEPG结合公司实际，制定了初步的规体系和模板文件，并决定将本项目作为试点项目．

　　本文详细论述了作为SEPG负责人之一，并且担任本项目质量保证人员的笔者，是如何在本项目中有效推行CMM二级质量保证措施的，并指出了其中的经验教训和有关的建议．

　　【正文】

　　本项目是一个面向政府管理部门，全市房地产企业和个人用户的网上管理系统，它既是一个电子商务项目，又是一个电子政务项目．本系统采用了B/S结构，融合了政府部门和房地产企业的部网上管理系统于一身，同时作为全国建设系统信息化的一部分而实现Inter-net平台上的上下集成．它还提供信息发布、房屋交易等电子商务功能。

　　本项目对系统的安全以及可靠性等方面有着较高要求，公司决定采用三层架构模式的J2EE环境作为运行环境．另外，本项目参与人员众多，面临看新技术、工期紧等影响软件质量的不利因素，对软件质量保证工作提出了很高的要求．本人作为公司CMM实施工作的负责人之一，以质量保证人员的角色参与到项目的开发和管理工作中，主要负责质量保证策略的建立以及实施工作．

　　一、以CMM二级理论为指导，采取措施保证开发过程与开发规的符合性，以过程质量的提高来保证产品的高质量

　　1、建立起明确的权责制度，减少因权责不明而产生的混乱

　　为确保质量保证人员有独立的途径向公司反映开发中的问题，同时为了避免质保经理与项目经理、软件配置经理之间过分隔阂，本人在项目启动阶段，起草了《项目管理人员责任书》，并由相关人员评审通过；