软件项目管理在小软件项目中的应用.doc.doc

软件项目管理在小软件项目中的应用 【摘要】但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。【关键词】【】he 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、需求获取 　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。 　　软件项目可以大致分为专用软件和通用软件两大类。 　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。 　　但是，开发合同上规定的只是一