|
中小信息化项目易犯的五个错误提到“软件危机”,人们的印象往往是指一些大型信息化项目延期而导致项目交接困难。但这并不意味着“软件危机”就与中小型信息化项目毫不相关。 本文关键字: 中小型信息化项目常犯错误 相对于大型软件项目,中小型软件项目灵活性更大、项目功能相对简单、参与开发人员少、开发周期较短,因此小项目的管理常常被人忽视,因而在小项目管理中常犯一些错误。 在企业层面常常表现为: ① 草率确定项目人员 对于中小企业来讲,人员流动性高,岗位频繁调换是不争的事实。如果这种情况出现在项目中,将对项目造成致命的影响。试想一下如果一个项目,即使是个小型项目,开发人员三天两头调来调去,开发设计怎么可能实现?因此,企业要根据其项目的周期长短谨慎选择开发人员,保障其在开发过程中发挥的可持续性作用。 ② 忽视隐性影响 项目一开始,项目组成员的命运就与项目的成败联系在一起。项目成败无疑会对项目组成员造成心理上、情绪上的影响。许多中小企业往往由于大型项目的大收益,只关注那些大型项目的成果,从而忽视了中小型项目。必然对项目组成员造成不良的隐性影响。最终影响项目实施。 在项目管理层面表现为: ① 草率的计划方案 企业往往由于项目规模较小,在项目开始之前没有认真地进行项目可行性和工作量的估计,便草率地制定开发日程表,不能正确预期项目难度,结果实际完成时间与估计完成时间往往有较大差别,从而使项目陷入困境。许多中小企业对于这种偏差的认识始终停留在是执行过程出了差错,然而根源却是项目的前端出了问题。 ② 蹩脚的设计过程 从中小项目的特点来看,开发人员少,意味着不同人员的程序之间交互、接口相对少一些;开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者虽是小项目的优势,但却都让人容易犯些错误。比如,实施中往往是几个人碰一下意见,讨论一下最基本的数据结构、函数接口便分头去做自己的工作了,并没有一份较正式的文档。这种做法为项目实施带来风险: 其一,有的人可能会对讨论出的接口、结构理解有偏差,应该承认并不是所有参加会议的人总是很明白,人是会犯错误的。而往往一个单纯的误解可能造成以后的返工; 其二,由于讨论时忽略了某些情况,等大家都按当时的分工完成属于自己的工作后,才发现各个模块组合起来却形不成一个完整的系统。其根源在于系统设计不充分,没有一个负责协调的人员不断监控整个开发过程; 其三,一旦有人中途退出开发队伍,其他人加入,新来的人因无法理解前人做好的工作,索性自己从头再来。同时,没有文档的程序,日后维护和版本升级也比较困难。 ③ 直奔系统测试 项目不经过单元测试而直接进入系统测试,造成这一现象的原因是每个模块相对比较简单,但是为了测试一个模块需要建立一些测试环境。比如为了测试一个函数是否正确,应该用一些测试数据去调用该函数,需要编写一些测试数据。 有人嫌麻烦,觉得反正其他模块也很快出来了,直接用真正的数据来运行几次就行了。 殊不知,一旦直接进入系统测试,发现运行结果不正确后需要一步一步查找。同时,由于模块间的调用关系,可能查了很久才发现是某个模块的问题。 这种方法如果侥幸成功,效率可能会很高,但概率不超过40%。所以,总体看来,这种方法一方面效率较低,大量的时间用在了将一个错误定位在模块上;另一方面,由于测试不完全,真正运行系统,当调用某模块时,可能大部分时候都是正常数据,极少出现边界情况,可能某些边界情况容易被忽视,很久之后才被发现。 中小信息化项目防患于未然 “麻雀虽小,五脏俱全”,即便是中小型信息化,仍然应该遵循软件开发的一般规律,必要的步骤不能省略。但也同时根据小项目自身的灵活的特点也可以相对变通。为避免所谓的“软件危机”防患于未然,笔者将中小信息化项目管理经验总结如下: ① 准确获取需求 制定统一需求模型 在这上面花费大量的时间很有必要,也很值得。所有信息化项目进入正式开发之前,必须先从用户处获取准确的需求信息,并对信息加以分析。 我们知道一般的软件项目可以大致分为专用软件和通用软件两大类。对于专用软件,需求相对较为明确,例如给某单位开发一套该单位专用的系统,一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓,而且往往在开发合同中已经大致地规定了。但是,开发合同上往往规定的只是一个大概的框架,项目经理必须与用户进行比较具体的交流和讨论,了解清楚用户心目中的产品究竟是什么样子。做好这个步骤,那么就可以避免开发后期因开发人员的理解和用户的要求存在误解,而造成的时间上的浪费。 对于通用软件,一方面是从经济效益考虑,另一方面是从技术的角度。例如,用户现有硬件配置如何,软件配置如何,使用什么网络,使用什么数据库等等。为得到这些信息,需要做一定的市场调查,并根据调查的统计结果决定即将开发的软件的一些技术指标。 需求分析就是将需求用一种模型来表示。目前比较流行的分析方法是面向对象的方法, 这部分涉及到具体的方法,在此不详细讨论,只想强调分析与设计过程的衔接。 分析过程的内容是用类的结构来表示目标系统,并不设计具体实现,如采用什么编程语言,在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一,能比较好的衔接。但是,是把分析和设计阶段分开,采用瀑布式开发,还是采用其他方式,要看具体的情况。一般来讲,对于需求潜在变化不大的项目,可以采用瀑布模型,有一个很明显的设计阶段,这样做的好处是有一份比较完整的分析文档。 ② 对需求分析模型进行必要修改的设计过程 设计过程需要根据设计要求对需求分析模型必要的修改。可能需要对某些类结构进行必要修改,这些修改的原因可能是编程环境的要求,或者为了重用以前的某些工作。比如定义界面部分、数据访问(数据库)部分。由于目前很多编程语言都可以可视化地设计界面,所以界面部分工作往往留到了编码阶段来完成。 ③ 中小项目的编码与测试必不可少 进入编码工作之后,可能会发现前面分析或设计阶段的某些错误,这时应返回到前面的阶段进行必要的修改。测试阶段正如前所述,即使是中小项目,也应该严格地进行测试,在此不再赘述。 ④ 项目经理人员安排的三个原则 中小信息化项目,往往是几个人来完成,这几个人基本上从头到尾参加开发。在这几个人中,有一位项目负责人,负责分析、设计和协调的工作。由于项目小,项目负责人也要参与项目开发。因此项目经理在项目的人员安排上需把握如下原则: 协调工作比自己去做更重要 项目管理主要工作就是协调,如果协调上出了漏洞,可能导致很大的问题,所以项目负责人必须随时监控各开发人员的工作,包括内容是否与要求发生偏差,进度是否滞后等等。只有在完成这些工作之后,项目负责人才可以利用剩余时间参与项目开发; 责编:匿名用户 微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友 著作权声明:kaiyun体育官方人口
文章著作权分属kaiyun体育官方人口
、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。 |
|
|