【摘要】信息技术的飞速发展已是无需争论的事实，软件产业的创造的价值也在逐年增加，在某些国家软件开发已然成为了支柱产业。在看到我国软件开发人员的不断成熟，软件开发环境不断与国际社会接轨的同时，我们也不能忽视我国当前软件行业存在的弊端：缺乏统一的行业标准和相应的法律法规，一些中小型软件项目仍然以原始的个人或者小团体为主的手工作坊式的方式进行开发，在大量浪费人力物力的同时也使得程序员辛苦创造的价值在无形之中流失。很多人认为小型软件项目不需要严格的管理，事实上恰恰与此相反，小型软件项目不单需要进行项目管理，而且不能完全照搬大型软件项目的管理方式和开发模式，应该遵循一种适合小型软件项目的管理方式；但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。 【关键词】小软件项目 项目管理 软件开发 【正文】
第一部分 软件项目管理概述
1-1软件项目管理的目的
从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。
软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。项目管理的根本焦点集中在T、Q、C、S上，即：开发进度（The progress of development）、特性与品质（Character and Quality）、成本（Cost）、顾客服务（Service）。其中最核心的是开发进度、特性与品质两个方面。其它一切管理工作都必须围绕这些焦点进行。 1-2软件项目管理的内容
从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、
详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。 1-3软件项目管理的原则
在八十年代初，著名软件工程专家B．W．Boehm①总结出了软件开发时需遵循的七条基本原则，同样，我们在进行软件项目管理时，也应该遵循这七条原则。它们是： （1）用分阶段的生命周期计划严格管理； （2）坚持进行阶段评审； （3）实行严格的产品控制； （4）采用现代程序设计技术； （5）结果应能够清楚地审查； （6）开发小组地人员应该少而精； （7）承认不断改进软件工程实践地必要性。
第二部分 小软件项目开发
2-1小项目的特点
本文所说的“小软件项目”是指直接开发人员的数目在3-10人，软件开发的周期在1-5个月之间，代码数量在5000-20000行，子程序数量在100-500之间的小型软件开发项目。
大家知道，“软件危机②”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点： ·项目功能相对较少 ·开发人员较少 ·开发周期较短
另外，在现实中，有很多小项目的开发人员流动性较大，这也是不容忽视的一个现实。
2-2小项目开发中常犯的错误
小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误： 1、开发之前没有认真地进行项目可行性和工作量的估计。往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计
完成时间往往有较大差别。 2、没有真正的设计过程
开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。
这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。
另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解 以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。
3、不经过单元测试而直接进入系统测试
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。 2-3合理的开发流程
合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。
以下我从几个方面描述一下我认为比较合理的模式。 1、需求获取
在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。
软件项目可以大致分为专用软件和通用软件两大类。
对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
为了比较好地与用户进行交流，使用一些工具是很有好处的。为了讨论用户界面，可以用VB, delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)
为了讨论软件运行的流程，可以采用UML③的Use Case图④。 2、需求分析
在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的 分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。 3、设计过程
设计阶段的工作包括：
对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。定义界面部分、数据访问(数据库)部分。
由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。 4、编码
进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。 5、测试
如前所述，即使是小项目，也应该严格地进行测试。 2-4需要强调几个问题
一、是要分清问题域与系统责任。
系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。
二、是需求获取与需求分析的关系。
用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三、是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程 语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，
是把分析和设 计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。 对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采 用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。
现在很多CASE工具⑤并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。
四、人员的安排
比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用。
第三部分 小结
我过去开发过的项目：
《小型药店收费系统》代码数量： 3000行 开发周期：1个月 开发环境：VB 《武警执勤数据库》 代码数量： 7500行 开发周期：1个月 开发环境：VFP 《网络视频会议系统》代码数量：12000行 开发周期：3个月 开发环境：VC# 基本上都存在这样的问题：
1．缺乏详细的需求分析。习惯了的个人开发模式是，详细了解项目的要求与功能之后，开一个基本的框架，即小样。不断与用户沟通，细化到每个组件子程序的详细功能，并进行测试,逐步完善。因为缺乏全局的需求分析，经常反工，浪费大量的时间和人力物力。
2．没有完整的开发文档。一个完整的软件项目应包括以下的相关文档： 项目开发计划 测试分析报告 概要设计说明书 测试计划 操作手册
模块开发卷宗 用户手册 项目开发总结报告 详细设计说明书 数据要求说明书 软件需求说明书 可行性研究报告 开发进度月报 数据库设计说明书 模块开发卷宗 用户手册 项目开发计划 项目开发总结报告
而在实际中，只有简单的用户操作手册和开发日志。由于缺乏详细的开发文档，导致软件的开发完全脱离计划，对开发周期有相当大的影响；所有的资料全部包含在软件中，加大了和用户沟通的难度；后期的软件测试和维护无章可循。
3．没有专门的美工和测试人员。开发出的软件成品，外观较差；自己设计的代码自己测试，这是软件测试的大忌，给后期的系统全局测试留下较多的隐患。是开发周期变长，成本变大。几乎全局测试要占用整个开发周期的一半以上！ 经验告诉我几条原则：
1、协调几个人的工作比自己完成一段编码更重要。
由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。 只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 2、给每个开发人员明确的任务书。
不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系 统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。
3、让大家都大致熟悉设计模型。
让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。
【注释】
①
2005年5月
Barry W.Boehm博士是软件业中最有影响的专家之一，他开创并发展了COCOMO
II模型。他的经典著作《Software Engineering Economics》（软件工程经济学）奠定了软件成本估算领域的基础。Boehm博十与美国南加州大学软件工程中心的其他同事—起，引领着软件成本估算技术的发展。
②
软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题。
1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(software crisis)这个名词。概括来说，软件危机包含两方面问题：一、如何开发软件，以满足不断增长，日趋复杂的需求；二、如何维护数量不断膨胀的软件产品。
③
Unified Modeling Language，统一建模语言。1997年，OMG组织（Object
Management Group对象管理组织）发布了统一建模语言。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域
的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。
④
用例视图(use
case view)。用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本
流程的\"角色\"（actors，也就是与系统交互的其他实体）关系，以及系统内用例之间的关系。用例图一般表示出用例的组织关系--要么是整个系统的全部用例，要么是完成具有功能（例如，所有安全管理相关的用例）的一组用例。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个角色（表示一个系统用户），可绘制一个人形符号。角色和用例之间的关系使用简单的线段来描述，如图所示。
⑤
CASE，Computer-Aided Software Engineering。一般认为，UML CASE工具应
该有一些共同的特性： ·方便地制图及纠错
·管理模型的信息，修改具有关联性 ·在模型元素之间易于导航 ·支持多用户协同工作
·支持代码框架生成
·支持逆向转换，即由代码生成模型 ·支持更多的开发环境 ·其它
目前的CASE工具可能并不相互兼容。由此也产生了模型互换的概念，就是某个工具产生的模型要能够应用到其它工具中去。各种工具一般都是用自己的数据库来保存模型信息，而实现模型互换的前提是将这样的存储模型的格式标准化，标准化的益处是显而易见的，但是目前还没有相应的标准。
【参考文献】
1．《实用软件工程（第二版）》郑人杰 殷人昆 陶永雷 清华大学出版社 2．《软件工程经济学Software Engineering Economics》[美]Barry W. Boehm 机械工业出版社
3．《软件项目管理—一个统一的框架》周伯生 机械工业出版社 4．《软件项目管理案例教程》韩万江 机械工业出版社
4．《UML和统一过程实用面向对象的分析和设计》[英]Jim Arlow， Ila Neustadt 机械工业出版社
5．《使用UML进行面向对象的项目管理》[美] Murray Cantor 人民邮电出版社
012班贾鹏指导教师赵鹏
文章见解独特，对软件项目管理有深刻的分析，论述层次清晰、规范。
因篇幅问题不能全部显示，请点此查看更多更全内容