搜索
小软件项目开发的管理一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。一、小项目的特点大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:1.项目功能相对较少2.开发人员较少3.开发周期较短另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.二、小项目开发中常犯的错误小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:1、开发之前没有认真地进行项目可行性和工作量的估计。往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。2、没有真正的设计过程开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。3.不经过单元测试而直接进入系统测试造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。三.合理的开发流程合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。以下我从几个方面描述一下我认为比较合理的模式.1.需求获取在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。软件项目可以大致分为专用软件和通用软件两大类。对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。为了比较好地与用户进行交流，使用一些工具是很有好处的。为了讨论用户界面，可以用VB,delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)为了讨论软件运行的流程，可以采用UML的UseCase图。2.需求分析在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类-类之间关系,可能需要不断修改而形成一份分析文档。我想强调几个问题。一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。二是需求获取与需求分析的关系。用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。例如当初采用UseCase来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。三是分析与设计过程的衔接。分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。3.设计过程设计阶段的工作包括:对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。定义界面部分、数据访问(数据库)部分。由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。4.编码进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。5.测试如前所述，即使是小项目，也应该严格地进行测试。四、人员的安排比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，经验告诉我几条原则:1.协调几个人的工作比自己完成一段编码更重要.由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。2.给每个开发人员明确的任务书.不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。3.让大家都大致熟悉设计模型.让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。1．记住往往事与愿违纯粹的“轶事工程”（原文为：anecdotalproject，其含义不好理解，暂译为轶事工程，盼指正--译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：你失败的机会大于你成功的机会。为什么我要从这个令人丧气的预测开始我的话题呢？因为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：“你只能从此三者中选择一个”。记住你身后高高堆积的纸牌[i]非常重要。你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。如果你懂得你的处境属于后者，你将会说：“是的，这很好。但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。”一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。一份很好的资料是RobertsGlass（一位爱好研究崩溃的专家）的著作：《软件失控》(SoftwareRunaways,出版信息：PrenticeHall1998)，以及他其它的著作。此外可以阅读TomDemarco和TimLister的经典之作《人件——生产性工程和团队》(Peopleware:ProductiveProjectsandTeam,出版信息：第二版，DorsetHouse,1999)。2．切合实际地安排时间时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。最近我校正了自己的时间安排策略。我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：functionpoint，若有其他正规译法，请指正）分析都需要对功能点进行猜测。我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。用更少的时间，也许产生更好的结果。但是，我的猜测是建立在我自己的经验之上的。3．首先让它运作起来当我试图进行一些无意义的事情时，我最大的创造性成功来临了。铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么疯狂的事情简单地让你的工程运作起来。这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。我在后面将要提到的Python语言就是这样一种工具。将你的计划运作起来有很多好处。凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不