小软件项目开发的管理
来源：网络 更新时间：2014-12-11
小软件项目开发的管理
一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人
的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项
目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别
，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。
一、小项目的特点
大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目
相比之下，具有以下特点:
1.项目功能相对较少
2.开发人员较少
3.开发周期较短
另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员
流动性较大，这也是不容忽视的一个现实.
二、小项目开发中常犯的错误
小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实
这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
1、开发之前没有认真地进行项目可行性和工作量的估计。
往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，
结果实际完成时间与估计完成时间往往有较大差别。
2、没有真正的设计过程
开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味
着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几
个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有
一份较正式的文档。
这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承
认人是会犯错误的)。一个误解可能造成以后的返工。
另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于
自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一
个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理
解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升
级都比较困难。
3.不经过单元测试而直接进入系统测试
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一
些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，
需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直
接用真正的数据来运行几次就行了。
殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模
块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，
大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系
统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边
界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一
下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。
三.合理的开发流程
合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开
发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的
一些特点，实行起来可以相对灵活些。
以下我从几个方面描述一下我认为比较合理的模式.
1.需求获取
在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是
很必要的。
软件项目可以大致分为专用软件和通用软件两大类。
