作者：黄坤

一般地，小型软件项目有项目功能相对较少、开发人员较少、开发周期较短的特点。小型软件项目看似简单，比较容易成功，因而人们往往忽视了对其的管理。其实这是一种误解，从本人的经验来看，在小型软件项目开发中容易犯以下的一些错误:
　　1、开发前没有认真地进行项目可行性和工作量的估计
　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
　　2、没有真正的设计过程
　　开发人员少，意味着不同人员之间的程序交互、接口相对少一些；开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都容易让人犯些错误。往往是几个人碰一下头，讨论一下基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。
　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差。一个误解可能造成以后的返工。另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
　　3、不经过单元测试而直接进入系统测试
　　一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。
　　这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分情况都是正常数据，极少出现边界情况，某些边界情况容易被忽视，很久后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。
　　针对这些情况，我们在开发时要设置合理的开发模式，用一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必需的步骤不能省略。但是小型软件项目有它自身的一些特点，实现起来可以相对灵活些。
　　本人从以下几个方面来描述个人认为比较合理的模式。
一、软件开发过程，分五步：
1、需求获取
　　在进入正式开发前，必须先从用户处获取准确的需求。在这上面花费相当时间是很有必要的。
　　在进入开发前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有做好，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
　　对于通用软件，也就是我们所说的产品软件，在开发前应该做一定的市场调查工作，必须了解清楚潜在用户对软件的各种技术上和功能上的要求，根据调查的统计结果决定即将开发的软件的一些技术指标。
　　2、需求分析
　　在了解了用户的需求后，将需求用一种模型来表示，这就是需求分析。目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
3、设计过程
　　设计阶段的工作包括:
对分析模型进行必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
　　定义界面部分、数据访问(数据库)部分。由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。
4、编码
　　进入编码工作后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。
5、测试
　　如前所述，即使是小型软件项目，也应该严格地进行测试。
二、开发人员的安排
比较小的项目，往往是由几个人来完成，这几个人基本上从头到尾参加开发，一般是２～５人。为降低系统开发过程的复杂性，程序员小组之间、小组内程序员之间的任务必须清楚并尽量简化。
开发方式有两种：一是“主程序员”组织软件开发小组。“主程序员”就是“工程师或高级工程师”，其他成员包括工程师、中级开发员、开发员等，是主程序员的助手。主程序员负责规划、协调和审查小组的全部技术活动，其他人员负责软件的分析和开发。这种形式的成败主要取决于主程序员的技术和管理水平。除了按主程序员负责的程序员小组组织开发人员外，还可以按“无我程序设计”建立软件民主开发小组。这种组织形式强调组内成员人人平等，组内问题均由集体讨论决定。这种组织形式有利于集思广益、互相取长补短，但可能工作效率比较低。
三、经验性的开发原则:
　　1、协调几个人的工作比自己完成一段编码更重要
　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
只有在完成这些工作后，项目负责人剩下的时间才能用于编程。 　　
2、每个开发人员要有明确的任务
　　不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。但是，到具体开发时，每个开发人员必须非常明确自己的任务。
　　3、让大家都大致熟悉设计模型
　　让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时候可能会发现设计模型中的漏洞，避免了各人的代码编写完毕后又要修改的后果。
4、分解原则
　　“化繁为简，各个击破”是自古以来解决复杂问题的不二法门，对于大型软件项目来讲，可以划分成几个小型软件项目来做，将周期长的项目化分成几个明确的阶段。对于小型的软件项目，同样也适用，将开发过程分成几个阶段，并规定在计划的时间内完成各个阶段的任务，在每个阶段中，也可以把每个阶段的主要功能分离出来，进行逐个击破。这样目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感，能充分调动开发人员的积极性。
四、开发文档的管理
虽然是写文档，其实是设计程序，整理一下思路与架构。磨刀不误砍柴工，这样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性的东西都在写文档这段时间内完成了。
当然我们这里的文档格式不像ISO那样规定了条条框框，我们的文档格式相对自由，基本上能随意发挥，但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。
　　开发文档有两类，一类是函数说明，另一类是设计文档。
函数说明中需要写明的是本模块完成的任务，解决什么问题，有什么作用，为什么要这些功能。此外还可以添加进适用范围，有什么不足，注意点是什么，还有哪些地方在以后可以进行改进。在这个函数说明中不涉及到任何非常详细的算法。
设计文档主要描述实现此模块所涉及到的主要算法、数据结构、类的层次结构及调用关系。这个文档的阅读者主要是开发人员，包括任何想了解详细实现代码的人，帮助人们理解代码。
    以上是我个人对小型软件项目开发的一些看法。在实际的工作中，往往是编写代码的时间占80%以上，对软件需求、详细测试以及开发稳定等没有太多的关注。当然这样也能完成项目，但在保证软件质量的同时更快地开发软件，做一些磨刀功还是很必要的。