小软件项目开发的管理

原创 2005年03月03日 19:46:00
小软件项目开发的管理
选自:松耦合空间制作组

一 个企业的管理,大公司有大公司的方式,小公司也有小公司的方式,如果把别人的经验生搬硬套到自己身上,可能会适得其反。同样,管理一个软件项目也一样,大 项目和小项目的方式不完全一样。但从另一个角度来看,项目的大与小并没有本质的区别,很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管 理。

一、小项目的特点
  大家知道,“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下,具有以下特点:

  1.项目功能相对较少

  2.开发人员较少

  3.开发周期较短

  另外,在现实中,有很多小项目是由一些中小公司进行开发的,这些公司往往人员流动性较大,这也是不容忽视的一个现实.

二、小项目开发中常犯的错误
  小项目看起来比较简单,比较容易成功,因而人们往往忽视了小项目的管理,其实这是一种误解,从本人的经验看来,小项目开发中容易犯以下的一些错误:

  1、开发之前没有认真地进行项目可行性和工作量的估计。

  往往由于项目较小,便很草率地制定一个开发日程表,没有认真地估计项目难度,结果实际完成时间与估计完成时间往往有较大差别。

  2、没有真正的设计过程

  开发人员少,意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头,讨论一下最基本的数据结构、函数接口便分头去做自己的工作了,没有一份较正式的文档。

  这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。

  另一个潜在的危险是由于讨论时忽略了某些情况,等大家都按当时的分工完成属于自己的工作后,才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。

  第三个潜在的危险是一旦有人中途退出开发队伍,其他人加入时,新来的人难以理解以前别人做好的代码,索性自己从头来。另外,没有文档的程序,日后维护和版本升级都比较困难。

  3.不经过单元测试而直接进入系统测试

   造成这一现象的原因是每个模块相对比较简单,但是为了测试一个模块需要建立一些测试环境。例如,为了测试一个函数是否正确,应该用一些测试数据去调用该 函数,需要编写一些测试数据。但很多开发人员嫌麻烦,觉得反正其他模块也很快出来了,直接用真正的数据来运行几次就行了。

  殊不知,一旦直接进入系统测试,发现运行结果不正确后需要一步步查找。由于 模块间的调用关系,可能查了很久才发现是某个模块的问题。这种方法一来效率比较低,大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全, 真正运行系统,当调用某模块时,可能大部分时候都是正常数据,极少出现边界情况,可能某些边界情况容易被忽视,很久之后才被发现。但是如果对每个模块进行 单元测试时都进行一下边界测试,就会很容易消除一些隐患。真可谓欲速则不达也。

三.合理的开发流程
  合理的开发模式,一句话形容就是“麻雀虽小,五脏俱全”,即使是小型项目的开发,仍然应该遵循软件开发的一般规律,必须的步骤不能省略。但是小项目有它自身的一些特点,实行起来可以相对灵活些。

  以下我从几个方面描述一下我认为比较合理的模式.

  1.需求获取

  在进入正式开发之前,必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。

  软件项目可以大致分为专用软件和通用软件两大类。

  对于专用软件,例如给某单位开发一套该单位专用的系统,一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓,而且往往在开发合同中已经大致地规定了。

  但是,开发合同上规定的只是一个大概的框架,在进入开发之前必须与用户进行比较具体的交流和讨论,了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做,往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解,那么必然造成时间上的浪费。

   对于通用软件,在开发之前应该做一定的市场调查工作,一方面是从经济效益考虑,调查产品的潜在市场有多大,另一方面是从技术的角度,必须了解清楚潜在用 户对软件的各种技术上的要求,例如,用户现有硬件配置如何,软件配置如何,使用什么网络,使用什么数据库等等,根据调查的统计结果决定即将开发的软件的一 些技术指标。

  为了比较好地与用户进行交流,使用一些工具是很有好处的。

  为了讨论用户界面,可以用VB, delphi等做一个原型,根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求,开发出来的原型本身可以作为下一步开发的基础,增量式地完成开发)

  为了讨论软件运行的流程,可以采用UML的Use Case图。

  2.需求分析

  在了解用户的需求之后,将需求用一种模型来表示,就是需求分析,目前比较流行的分析方法是面向对象的方法,通过分析用户需求,用类、类之间的各种关系来表示整个系统。

  这部分涉及到具体的方法,在此不详细讨论,但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。

  我想强调几个问题。

   一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能,而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序,程控机已经 是现成,输出的数据格式也已经是固定的,你的程序仅仅需要从程控机中读取相应的信息,那么,"程控机"在你的系统里只是一个外部的东西,把它作为一个类也 许就是不必要的,仅仅需要一个类来完成读数据的操作。又如,你需要在一个已经存在的数据库上开发一些应用,数据库的格式已经固定,并且已经有一个后台程序 在运行,你需要开发一个新的前台程序,这时,服务器程序对你来说就是一个外部的东西。但是,象这种外部的内容必须在分析文档中有一些说明,作为系统的外在 约束。

  二是需求获取与需求分析的关系。

  用什么方法来完成需求的获取,在很大程度上影响了需求分析的做法。

  例如当初采用Use Case来表示用户需求,那么从各种序列图中选出相互交互的各个实体,就是一个个类。

  三是分析与设计过程的衔接。

   分析过程的内容是用类的结构来表示目标系统,并不设计具体实现,如采用什么编程语言,在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成 的。面向对象方法的优点是分析、设计、编码过程表示法统一,能比较好的衔接。但是,是把分析和设计阶段分开,采用瀑布式开发,还是采用其他方式,要看具体 的情况。

  对于需求潜在变化不大的项目,可以采用瀑布模型,有一个很明显的设计阶段,这样做的好处是有一份比较完整的分析文档,这样以后如果需要采用不同的编程语言、或者采用其他的平台时,便可以以这份分析文档作为开发的基础。

  对于需求变化频繁的项目,可能采用少量分析->少量设计->少量编码->测试的方式更合适,而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。

  现在很多CASE工具并不区分分析和设计的阶段。但是,这并不意味着开发就可以对分析和设计不加区分,CASE工具如同一支笔,如何用好还得还人。

  3.设计过程

  设计阶段的工作包括:

  对分析模型必要的修改。可能需要对某些类结构进行一些修改,这些修改的原因可能是编程环境的要求,或者为了重用以前的某些工作。

  定义界面部分、数据访问(数据库)部分。

  由于目前很多编程语言都可以可视化地设计界面,所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。

  4.编码

  进入编码工作之后,可能会发现前面分析或设计阶段的某些错误,这时应返回到前面的阶段进行必要的修改。

  5.测试

  如前所述,即使是小项目,也应该严格地进行测试。

四、人员的安排
  比较小的项目,往往是几个人来完成,这几个人基本上从头到尾参加开发。在这几个人中,有一位项目负责人,负责分析、设计和协调的工作。由于项目小,项目负责人也要参加编程,那么这人必须把时间合理运用,

  经验告诉我几条原则:

  1.协调几个人的工作比自己完成一段编码更重要.

  由于协调上出了漏洞,可能导致很大的问题,所以项目负责人必须随时监控各开发人员的工作,包括内容是否与要求发生偏差,进度是否滞后等等。

  只有在完成这些工作之后,项目负责人剩下的时间才能用于编程。

  2.给每个开发人员明确的任务书.

  不管是用面向对象或者其他方法开发,分析、设计模型只是从功能的角度来描述系统。但是,具体开发时每个开发人员必须非常明确自己的任务,这些任务应该采用明确的文档来表示。

  3.让大家都大致熟悉设计模型.

  让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位,有时侯可能会发现设计模型中的漏洞,避免了各人的代码编写完毕之后又要修改的后果。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

软件项目中需求的开发和管理

 引言 在软件开发过程中,项目最开始的信息来源于客户需要处理某件事情或某项工作,一般都是临时性,紧急性,独立性和系统性的的。所以这就导致我们承接项目后项目的不确定因素就非常多。在这其中项目需求...

华为软件开发云测评报告一:项目管理

体验环境 体验方式:PC端 系统:Windows 64位 浏览器类型:Chrome浏览器 浏览器版本:49.0.2623.110 m 体验时间:2017.05.11 ...

管理软件开发项目关键风险

1.人员流失风险 考虑了下,还是把人员流失作为项目第一大风险,软件项目管理最重要的还是人的因素。特别是关键项目成员流失可能会导致整个项目的重大延期和失败。人的职业过程中主要受到金脉,知脉和人脉三个因...

软件开发与项目管理易理——简单与灵活

“是故百战百胜,非善之善者也;不战而屈人之兵,善之善者也。” ——《孙子兵法·谋攻篇》一场战役,以多胜少与以少胜多相比,后者更为胜。软件开发犹如一场战役,投入的资源好比是兵马,所要开发的软件好比是要打...

谈谈软件开发项目管理的积分制

软件开发项目管理的积分制(以下简称积分制)是一种软件开发项目的绩效管理模式,以项目利润、客户满意度、项目质量、创新等为KPI指标,将积分与员工福利奖金、晋升、荣誉等捆绑以此来调动员工的积极性,从而建立...
  • xiaoyw
  • xiaoyw
  • 2016-10-18 22:53
  • 1117

开发管理软件项目存在的风险(上)

1、人员流失风险      软件项目管理最重要的还是人的因素。特别是关键项目成员流失可能会导致整个项目的重大延期和失败。人的职业过程中主要受到金脉,知脉和人脉三个因素的影响,任何一个因素出现重大问...

浅谈软件开发过程中的项目管理

摘要:大量软件开发实例表明,如果不能在软件开发中加强项目管理,随着国内软件行业的不断发展与壮大,国内的软件开发企业将面临严峻的挑战性与风险性。因此,为了确保软件开发的效率与质量,必须认识到强化项目管理...

软件开发与项目管理易理——你该相信谁?

一般情况下,程序开发流程为:第1步:编写代码(包括程序所需的其他资源,诸如配置文件、数据库等),实现期望的功能。第2步:编译代码,生成可执行文件。若编译不同过,返回第1步。第3步:运行。若运行结果不正...

开发管理软件项目存在的风险(下)

3.需求不明确和需求变更多     需求不明确直接的表现就是目标和范围不明确,项目管理的首要过程域就是项目范围管理,如果这个都不明确直接导致一个项目无法开展,导致项目成员没有共同奋斗的目标。需求是...

如何管理软件开发项目?

方法概要 管理软件开发项目,是一个非常复杂的问题。本方法虽只涉及非常粗浅的步骤和概念,相信正是因为其精简性,会给初学者带来指导性的效果。应该有一些用处吧。 1 将目标具体化 ...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)