免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 10204 | 回复: 19
打印 上一主题 下一主题

小软件项目开发的管理(zt) [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2004-04-22 17:53 |只看该作者 |正序浏览
小软件项目开发的管理


作者:不详


文章来源:http://www.lnu.edu.cn/book/se/happy.html  
  

--------------------------------------------------------------------------------
  一个企业的管理,大公司有大公司的方式,小公司也有小公司的方式,如果把别人的经验生搬硬套到
自己身上,可能会适得其反。同样,管理一个软件项目也一样,大项目和小项目的方式不完全一样。但从
另一个角度来看,项目的大与小并没有本质的区别,很多方法是共通的。本文的目的是从作者的经验来谈
谈小项目开发的管理。  
一、小项目的特点  
  大家知道,“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下,具有以
下特点:  

  1.项目功能相对较少  

  2.开发人员较少  

  3.开发周期较短  

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

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

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

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

  2、没有真正的设计过程  

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

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

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

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

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

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

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

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

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

  1.需求获取  

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

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

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

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

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

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

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

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

  2.需求分析  

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

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

  我想强调几个问题。  

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

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

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

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

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

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

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

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

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

  3.设计过程  

  设计阶段的工作包括:  

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

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

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

  4.编码  

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

  5.测试  

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

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

  经验告诉我几条原则:  

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

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

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

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

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

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

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

论坛徽章:
0
20 [报告]
发表于 2007-10-20 11:06 |只看该作者
原帖由 ibmxp 于 2005-10-25 17:13 发表
我觉得还是管理比较主要。一个软件生存周期少则3或5年,大则更长,现在人员流动性比较大,需求说明、开发文档、程序注释这些是一定要的,只有合理管理才能控制软件开发维护成本、使人力资源合理应用!



知识型的团队,一定要注意管理,特别是知识的管理,详细设计文档,公司的编码规范,要不然后续的软件维护成本会飙升

论坛徽章:
0
19 [报告]
发表于 2007-10-20 11:00 |只看该作者
原帖由 雨夜 于 2004-4-29 17:17 发表
其实这些小项目没有那么复杂,找1~2可以信任的熟手就行了。实际上,我的经验是5万代码(不包含自动生成的代码)以下的系统成功的关键不是项目管理的能力,而是核心程序员的能力。


偶 深有体会啊, 整个团队有时候就是几个牛人撑起来的

论坛徽章:
0
18 [报告]
发表于 2007-10-19 19:03 |只看该作者

软件测试人员逐渐成为IT行业的"金饭碗"

说起找茬,一般人第一反应都是鸡蛋里挑骨头,或者想起网络流行的小游戏“大家来找茬”。不过这些“找茬”充其量不过是小儿科水平,真正的骨灰级“找茬”是要让别人哭着喊着求你来找,找完了不光特虔诚地对你说声“谢谢阿”,还倒给你一大堆钱。这不是笑话,在软件行业还真就有这么一种“找茬”职业,位居2007IT热门职业的榜首,是国家重点培养的目标,行业人称软件测试人员是也。那么究竟是何原因让其成为的IT行业“金饭碗”呢?小编经过多方查证最终发现了它的四大魅力之所在:

就业竞争小

据前程无忧数据显示,目前国内120万软件从业人员中,真正能担当软件测试职位的不超过5万人,人才缺口达到20万并有逐年扩大的趋势。人才的极度匮乏令许多IT企业不得不延缓甚至停止项目,为企业发展带来消极影响,但对人才就业却有积极意义。人才供不应求让软件测试人员的就业竞争压力明显小于同类其它职业,有利于从业者的身心健康。另外,由于软件测试在我国起步较晚,独立设置测试部门、对测试人员有强烈需求的多为独具慧眼的大中型IT企业。软件测试人才不需要在小企业积累经验就能获得知名企业的入门通行证,工作起点高于同类其它职业,如北大青鸟测试培训班刚毕业的学员就已在摩托罗拉、SAP、雅虎中国、索尼爱立信等国内外知名IT企业中工作。

高薪没商量

“我是今年7月毕业的,6月份就找到了工作,现在全年收入在五六万左右。”就职于北大青鸟商用信息系统有限公司的金星对自己当前的待遇很满意。像他这样刚入行的软件测试人员,起步月薪就在3000-5000元左右,远高于同龄人1000-2000元的薪资水平,另外还可享受带薪年假、内部培训、住房公积金等福利待遇,工作2-3年月薪大约在8000-13000元之间,甚至超出很多相同服务年限的软件开发人员的薪资水平。

多元化发展

“与其他IT职位相比,软件测试人员最大的优势就是发展方向太多了。”在海辉软件公司担任软件测试工程师的曹永辉如是说,“像我比较喜欢钻研技术,对编程也有一定兴趣,朝技术方向努力就错不了。” 由于工作的特殊性,测试人员不但需要对软件的质量进行检测,而且对于软件项目的立项、管理、售前、售后的等领域都要涉及。在这过程中,测试人员不仅提升了专业的软件测试技能,还能接触到各行各业,项目管理、沟通协调、市场需求分析等能力都能得到很好的锻炼,从而为自己的多元化发展奠定了基础。“我的一个员工,进公司是先从测试员做起的,后来升到了项目主管,现在负责我们公司新产品的市场推广工作。是不是很有戏剧性啊。”康普塞特信息技术有限公司总经理王亚智略有感慨地说,“软件测试工作确实能给年轻人提供更广阔的发展平台。”因此,经过软件测试岗位洗礼的人才往往是行业中的多面手,比其它IT人才具有更强的可塑性,在技术、管理、市场甚至其它非IT领域都能得到良好的发展。

无性别歧视

如果把软件开发领域比作男子单打,那么软件测试领域就是混合双打。由于工作的特殊,软件测试人员往往更偏好认真、耐心、细致、敏感、等个性元素,而这在一定程度上与女性的个性气质相吻合。“在我们部门,软件测试岗位的男女比例基本差不多。”北京康赛普特信息技术有限公司总经理王亚智这样告诉记者。据了解,目前很多IT企业中软件测试人员的比例更趋向平衡,甚至出现女性员工成主流的情况。对此,北京青鸟信息技术教育发展有限公司CEO杨明认为,无性别歧视是职业设置合理的一种表现,有利于软件测试工作的稳定发展,对人才的大量培养也起到积极的促进作用。

软件测试人员的职业魅力列了一大堆,归根结底就一句话——发展前景那可是相当不错的啊!有志于为软件行业贡献青春、锤炼自己的兄弟姐妹们可以考虑考虑。甭急着赶着投简历,先掂量掂量自己有几两沉,心虚的赶紧给回炉重造一番,趁着人才供不应求的大好发展时机显示身手。只要你有软件测试的本事,那就只有你挑企业的份儿(一般人我不告诉他)北京最大软件测试培养基地诚邀您来参加大型软件测试职业体验活动:1,it英才俱乐部    2.知名软件测试专家职业规划及行业展望. 北航地址:北京市海淀区学院路40号大唐电信北大测试楼
复兴门地址:北京市西城区佟麟阁路95号尚信大厦3层.北航电话:010-62303230 62303260 62303223 62303278复兴门电话:010-66421960 66421956 66421965
网址:www.btestingsky.com

论坛徽章:
0
17 [报告]
发表于 2007-10-12 11:17 |只看该作者
做这些工作要用到哪些软件?

有没有好的,推荐一下!

论坛徽章:
0
16 [报告]
发表于 2005-10-25 17:13 |只看该作者

小软件项目开发的管理(zt)

我觉得还是管理比较主要。一个软件生存周期少则3或5年,大则更长,现在人员流动性比较大,需求说明、开发文档、程序注释这些是一定要的,只有合理管理才能控制软件开发维护成本、使人力资源合理应用!

论坛徽章:
0
15 [报告]
发表于 2005-10-14 21:00 |只看该作者

小软件项目开发的管理(zt)

[quote]原帖由 "雨夜"]其实这些小项目没有那么复杂,找1~2可以信任的熟手就行了。实际上,我的经验是5万代码(不包含自动生成的代码)以下的系统成功的关键不是项目管理的能力,而是核心程序员的能力。[/quote 发表:


哈,哈,哈

看什么应用了,拿出去圈钱得当然可以

论坛徽章:
0
14 [报告]
发表于 2005-10-06 20:31 |只看该作者

小软件项目开发的管理(zt)

看过一本软件工艺的书,作者强调的是人的因素,和软件工程恰恰相反,软件工程中,强调的是只有想不到的,没有做不到的,只有规划合理,文档详尽,就能完成项目,但想想我门在实际开发项目中,大型除外,本身软件工程就是为大型项目做准备的,是核心程序员更重要,还是项目规划管理更重要??

论坛徽章:
0
13 [报告]
发表于 2005-09-30 00:37 |只看该作者

小软件项目开发的管理(zt)

使用必要的工具和文档管理是也是很重要的..超过7个人以上的开发团队就要有软件和文档保证. 不然..不要说客户..连管项目管理人都没办法追踪问题

论坛徽章:
0
12 [报告]
发表于 2005-09-26 11:26 |只看该作者

小软件项目开发的管理(zt)

说的有道理!
  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP