当前位置:论文网 > 论文宝库 > 信息科技类 > 计算机信息管理论文 > 正文

论信息系统项目管理之项目计划

来源:UC论文网2019-05-16 09:27

摘要:

  [摘要]本文讨论了一个作者参与的软件项目的项目计划制订的若干问题。项目所开发的产品是一种智能电子教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,并可以保存、编辑、打印用户输入的数据,联网的计算机也可以实时观看用户的书写过程,并且用户还可以通过投影在硬件端的PC机画面交互操作PC机。作者针对项目计划的制定采取了:分而治之,逐步求精,经验数据三个主要策略,从而得到较好的效...

  [摘要]本文讨论了一个作者参与的软件项目的项目计划制订的若干问题。项目所开发的产品是一种智能电子教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,并可以保存、编辑、打印用户输入的数据,联网的计算机也可以实时观看用户的书写过程,并且用户还可以通过投影在硬件端的PC机画面交互操作PC机。作者针对项目计划的制定采取了:分而治之,逐步求精,经验数据三个主要策略,从而得到较好的效果。


  中图分类号:D627;F426.61文献标识码:A文章编号:1009-914X(2016)21-0085-01


  作者:卢航远


  1.概述


  作者参与了一个项目,该项目开发出来的产品是一种智能教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容,联网的计算机也可以实时观看用户的书写过程。另外,用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机。对于这种实时通信且具有联网功能的软件项目,我认为首先需要制定一个良好的项目计划,才可以保证项目开发的成功。


  我认为行之有效的策略有三个,分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。


  2.分而治之


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


  比如针对这次项目中采取的RUP开发过程模型,我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定,最后合到一块儿就是完整的需求管理计划。


  除了按时间段分解的角度来制定项目计划,我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作,根据每个工作流在四个阶段业界通用的工作量估计来制定计划,安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流,我认为以这种方式分解是合理的.同时因为本项目的特点,我省略了业务建模工作流,这是因为这次的产品是以硬件为主,软件为辅的消费类产品,所以业务建模不是那么必要了.以不同的方式分解项目,可以从多个不同的角度来制定整个项目计划,有利于全面、深入地了解项目,避免“瞎子摸象”的情况发生.


  3.逐步求精


  计划工作其实是一种管理未来、管理未知的工作,而未来是变化莫测的,还存在许多自身无法掌握的因素,因此存在很大的难度.而解决这一困难的法宝就是逐步求精。按照先框架后细节,先粗后细地进行项目的计划.


  比如在这个项目中,在接受这个项目后就开始了做了一个初步计划,这个计划的内容主要是做出时间上的安排。因为打算在5月需要用这个项目的产品申请国家中小企业创新基金的支持,所以完成时间就定在了4月,预留一个月用于写申请报告。总的时间进度确定后,大概分配了三个时间段:系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结。


  比如在初始阶段时架构设计考虑以MFC为平台,根据这个决定软件开发计划的制定是比较粗略的,在细化阶段架构设计进一步详细,这时已经清楚各个模块和MFC的Doc/View主结构的接口定义,以及各模块之间的接口定义,这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代,第一次迭代计划一个月时间,第二次迭代两周时间,第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果,第二次迭代的主要任务是根据用户反馈进行修改调整。


  4.经验数据


  要制定一个良好的计划离不开精确的估算。不过项目计划是在项目开发的早期制定的,而在早期要完成精确的估算是非常困难的.要解决这个问题的关键就在于“经验数据”。由于整个软件产业都还十分年轻,经验数据的积累都普遍不足,才导致这一现象的出现。


  但是因为这次项目开发的产品在国内还没有开发过,再加上公司没有积累深厚系统的项目历史数据。针对面临的困难,我选用了FP功能点分析作为项目主要的估算方法。因为FP方法中有大量项目经验数据可以从网络上获得,同时其数据功能TLF、EIF,以及事务功能EI、EO、EQ的计算对经验数据依赖不强,只需对概念理解正确一般就可以正确估算了。在估算成本的时候,因为公司以前的生产率数据是以LOC为单位的,我利用软件工程书籍中的“逆火”经验数据,将LOC转换为功能点单位,当然,这里必然导致一些误差。为了降低估算误差,最后使用Delphi专家分析法对估算结果进行了调整。


  在上述三个策略的指导下,以及合适工具的辅助下,使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定。项目完成后发现的问题是早期计划的估算结论偏差还是较大,看来还是受到缺乏经验数据或者经验数据不够精确的影响,所以在以后的工作中需要开展有效的度量的工作,积累覆盖面广且尽量精确的经验数据.

核心期刊推荐