论信息系统项目的进度管理.doc

《论信息系统项目的进度管理.doc》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、论信息系统项目的进度管理【摘要】本文以我参与过的资源管理系统为实例，探讨了在项目管理过程中，在进度管理方面遇到的实际问题及相应的解决办法，认为在项目管理过程中，如果进度管理做到位，将有利于项目下一步工作的有序展开，最终促使项目走向成功，并满足各利益相关者的需求和预期期望。在此项目中，我担任了系统开发方的子系统开发经理，参与了整个系统的建设任务，项目从启动至验收历时15个月，系统至今运行稳定，获得了客户的一致好评，很大程度上得益于进度管理方面的工作做得扎实到位。【正文】一、本项目简介某通信运营商为解决各专业网络的资源管理问题，分别开发建设了数据、交换、传输、无线等四大专

2、业网络资源管理系统，这四大专业系统在一定程度上，缓解了该企业在网络资源管理方面所面临的压力。但是，由于这四大专业资源管理系统是分散建设的，水平也参差不齐，在一定程度上制约了这四大专业网络资源信息的共享和应用。因此，该通信运营商向集团公司申请进行四大专业网络资源管理系统的整合工作，开发综合网络资源管理系统，此系统在某年某月得到集团公司的正式批复，随后开始启动综合网络资源管理系统的全面建设。我负责资源展示子系统和报表子系统的需求调研和系统开发工作。系统上线以来，运行稳定，并在各地市推广应用。其中，无线专业在济源进行了实施；话务、数据等专业也在相关专业科室投入了使用。系统投

3、入使用后，在资源利用率、网络运维能力、业务支撑能力的提升等方面发挥了重要作用。二、我在本项目中的工作内容第一步：需求调研按照我们制定好的综合资管项目调研计划，我与网管中心的A主任取得联系，通过我和A主任的沟通对话，让A主任非常清楚我此次去用户现场调研的业务目标，以便A主任根据我此次调研的目标，及时安排相关业务的科室负责人配合我调研需求，到了用户现场之后，我们会和用户现场业务骨干人员针对现场具体业务进行深入具体的沟通交流。第二步：原型制作我对网管中心的业务调研告一段落之后，我即开始根据调研到的需求，制作静态的原型页面，也就是系统演示Demo，此Demo操作起来，感觉和真

4、实系统相似，只是没有编写后台代码实现功能。第三步：客户确认原型制作好了之后，我再次主动和网管中心的A主任取得联系，预约时间，以便向网管中心主要人员演示综合资管系统Demo。此次演示的目的，主要是为了让用户和我们一同，以Demo这种所见即所得的直观方式，来确认我们开发方对需求的理解是否正确无误，如果用户看过Demo之后，指出了我们需求调研之后，理解不正确的地方，我们会及时的修改Demo，一直循环下去，知道Demo正确为止。第四步：设计系统架构和编写代码进行概要、详细设计，然后搭建一个资源展示子系统的开发框架，制定包括什么类别的程序放到什么包里面等开发规范，并且确保搭建好

5、的开发环境可以运行起来，以供调试开发。制定开发计划，并组织相关开发人员，进行编码开发一、我遇到的进度管理问题由于我负责的资源展示系统，主要工作是开发出拓扑图建模工具，以及使用建模工具建立起覆盖所有专业的拓扑图模板库，资源展示系统必须能够根据选择的不同的拓扑图模板，自动提取业务数据灌入到模板中，从而生成一幅拓扑图示例。但是等我们从客户那里拿到绘制拓扑图原始资料的时候，才发现我们面对的拓扑图结构之复杂，数量之多，超出了当初的预想。而工期又是事先和用户约定好的，虽然按期完成开发任务似乎难度很大，但是无路可退，进度控制显得尤为重要。二、本项目从以下几方面入手来解决遇到的进度管

6、理问题首先，我认为，鉴于目前大任务量和工期紧的实际情况，参与开发的开发人员必须是有一定开发经验的开发人员，刚刚毕业的大学毕业生显然心有余力不足，因此特申请调到我们项目组的开发人员，必须有一年以上开发经验。其次，加强技术和业务培训力度，由于我们是在美国一家中间件的基础上，进行二次开发，因此，必须加大此中间件的API培训力度，同时进行四大专业拓扑图结构的相关业务培训。最后，合理安排好每个开发人员的任务，坚决避免有的开发人员闲着无所事事，有的开发人员忙的连水都喝不上一口。做好统筹兼顾。为了赶早不赶晚，在开发过程中，对于那些业务比较复杂，而且又采用了新技术的功能模块儿，严格把

7、控进度，及时组织能力强的业务人员和开发人员进行业务和技术攻关，临时会安排加班赶任务，把有工期风险的任务消灭掉。三、项目总结和展望项目最终成功上线，并运行良好，成功的经验固然是宝贵的，不足之处同样值得重视。在实际开发的过程中，开发组长有的时后没有按照调研的需求，严格用程序实现，而是想当然的认为，这样或那样做会更好一些，导致程序开发告一段落后，才发现与客户的需求不一致，导致返工。在以后的项目中，应该加强对项目开发关键人员进行业务培训，加强开发组长对需求的理解程度，让开发组长，真正的理解需求，为什么要这样做，避免类似情况的再度出现。