网络编程 | 站长之家 | 网页制作 | 图形图象 | 操作系统 | 冲浪宝典 | 软件教学 | 网络办公 | 邮件系统 | 网络安全 | 认证考试 | 系统进程
Firefox | IE | Maxthon | 迅雷 | 电驴 | BitComet | FlashGet | QQ | QQ空间 | Vista | 输入法 | Ghost | Word | Excel | wps | Powerpoint
asp | .net | php | jsp | Sql | c# | Ajax | xml | Dreamweaver | FrontPages | Javascript | css | photoshop | fireworks | Flash | Cad | Discuz!
当前位置 > 网站建设学院 > 网络编程 > 软件工程
Tag:注入,存储过程,分页,安全,优化,xmlhttp,fso,jmail,application,session,防盗链,stream,无组件,组件,md5,乱码,缓存,加密,验证码,算法,cookies,ubb,正则表达式,水印,索引,日志,压缩,base64,url重写,上传,控件,Web.config,JDBC,函数,内存,PDF,迁移,结构,破解,编译,配置,进程,分词,IIS,Apache,Tomcat,phpmyadmin,Gzip,触发器,socket
本月文章推荐
.SQA报告.
.Hibernate的检索策略小结.
.使用.NET多线程技术显示实时股票.
.项目管理中的(用户)需求变更控.
.项目沟通管理与会议管理问题.
.SOA核心理念的应用发展.
.戏说Visual Studio Team System.
.如何做好项目软件的分析.
.测试过程改进的缺陷漏测分析(1).
.RSA中UML建模元素的扩展与定制.
.架构设计师与SOA(一).
.关于项目团队的发展阶段特点、问.
.Z5NTS功能之icmp.
.探讨开源软件的互操作策略.
.UML 用例建模技巧.
.定义客户需求的原则和方法.
.3DS模型Bump Map(凹凸贴图)渲染.
.VC中利用多线程技术实现线程之间.
.LINQ 性能分析系列之传说中的LINQ.
.SOA的进化(二)标准组织与贡献厂商.

异议《浅析软件项目管理中的10个误区》

发表日期:2008-3-23



  7月3日天极网登载了一篇题为《浅析软件项目治理中的10个误区》(以下简称《误区》)文章,阅后对作者的观点有些异见,在此提出希共同交流。

  笔者大体认同的观点是:[误区5]中关于白盒法测试可由程序员担当--因为程序员对程序的设计思路最熟悉,对可能引发错误的地方最为清楚,所以他们能制作出最快、最准的测试用例,所以由程序员完成部分"白盒法"测试是可行的、于提高效率/质量有益的;[误区8]中项目经理不一定是所有项目成员中薪水最高的--假如项目经理只执行治理性质的工作,对项目不形成建设性成果,在项目组中,除了文秘人员外,项目经理的薪资甚至可以是最低的。

  作者所谓的误区3是:软件程序主要由代码组成,因此编码阶段是整个软件项目的最重要的阶段,应该给与大量的时间,并且集中主要的资源。--意即编码并不是主要的工作,分析、设计与测试才是主要工作,并提出了一个"资源的合理分配比例":项目论证、风险评估阶段3% ,项目需求分析阶段8%,系统总体/具体设计阶段45%,编码阶段10%,系统测试阶段34%。

  一般都看得到,软件程序由代码组成,代码是软件的实体。没有代码,再多、再完善的分析、设计、测试都是空洞/无意义的。在一定的技术水平条件下,系统中要编写的代码量是客观性质的,是硬性的工作量,不会因设计的不同而有太大的区别--除非一个外行、生手才可能堆砌大量冗余代码。分析、设计、测试则是可主观控制的,是柔性的工作量。好比收割一亩麦田,工作量是确定的--一亩麦田,工作方法是可以多样的,如一个人干、十个人干、用镰刀、用收割机;为完成该工作,也需要分析设计:如根据麦田的外形设计收割路线,以减少行走的距离,工作时休息几次、在何处休息,以使劳动者保持最佳舒适状态等等;为完成该麦田的收割,分析、设计的比重可以很小,小到可以为1%,总的工作量就是101%,工作的过程可能是劳动者苦一点、累一点;分析、设计的比重也可以很大,大到10000%,总的工作量就变为10100%,工作的有效成绩同样是完成一亩麦田的收割,只是工作的过程可能是劳动者感觉非常舒适。软件开发也是一样。同样的系统,其代码工作量是确定的,假设为100个人月。公司甲的开发方式中,资源分配比例是:论证1%、分析5%、设计9、编码70%、测试15%,公司甲对该项目的总开发成本是:100个人月/70%=约为143个人月。公司乙的开发方式中,资源分配比例是:论证3%、分析8%、设计45、编码10%、测试34%,公司乙对该项目的总开发成本是:100个人月/10%=约1000个人月。假如是竞标项目,显然公司甲更有获胜机会;假如是公司自身的项目,则公司甲的特点为:速度更快、成本更低,公司乙的特点为:工作流程更清楚、员工工作强度更低。实际中系统开发各部分的资源分配比例应如何,并无先天的规则,主要根据企业自身资金实力、企业文化、企业形象、员工福利待遇、及市场竞争等来定,非凡地,不一定投入的成本越大,系统就能做得越好!
  作者所谓的误区6是:软件项目治理只是相关技术部门的事情,与公司其他部门无关。意即软件项目治理需要提高公司的整体参与意识,需要公司各个部门协同作战。
殊不知道,公司设立专门的项目治理团队,就是为了能尽可能由该团队独立地解决掉项目过程中的各种问题,不要仍然象没有独立治理团队时一样,碰到一个问题时动不动就吆五喝六,把公司各部门的人都搅动起来,影响/牵制公司的全局工作。一个优秀的项目治理者,只有在非常必要时,才会去请求其他部门的协助--他首先会尽可能在项目团队内解决问题。

  作者所谓的误区7是:在开发进度滞后的情况下,可以聘请更多的程序员加入到开发团队中,通过增加人力资源来赶上进度。意即项目进行过程中,新人的加入不一定是有益的,可能会"好心好意做坏事",因为引导新人融入团队需要花费开发团队许多时间和精力,很有可能使项目进度更慢。其实作者的这一观点笔者也是认同的,只是作者文章前后的说法有点自相矛盾。作者贬见的是"作坊式"的软件治理,褒见的是"软件工厂式"治理、软件工程方法。按照软件工程规范来进行项目治理,各种文档、流程必然是相当规范的,而且软件工程化的主要目的之一也是要使项目不依靠于个人、能持续进行,即如此,新人加入时、融入团队时自然不应该存在什么困难!作者的矛盾,大概是理论与实际无法统一带来的尴尬。

  作者所谓的误区8是:技术骨干应该成为项目的项目经理。意即在"软件作坊"时代,这是一种普遍使用而且效果不错的方法;而在"软件工厂"时代,这种方法却带来各种问题,有时甚至直接导致项目失败。软件项目不同于建筑项目,建筑项目中,绝大部分工作都是明确的,可明确分配给工人去做的,建筑项目治理中主要的问题是组织、领导、协调的问题,它确实不必需要建筑技术专才来治理;而软件项目中,大部分工作是不能简单描述清楚的,也不是简单地分配下去了就能被完成的,首先工作任务如何划分就需要技术能手才能作出,每一个任务可安排给团队中谁来做,也需要技术能手才能把握得准确,虽然不是必须的,但用技术骨干担当项目经理,更能保证项目组的工作效率、更能保证项目的成功。
单从项目组效率上讲,技术骨干型项目经理带领的团队能保证90%以上的效率,而非技术型项目经理带领的团队大约只能保证40%--60%的效率。因为项目治理中还有不少人际交流上的问题,所以为技术骨干型项目经理配一个善于协调的助手/秘书,则更是一种黄金组合。
以上仅为笔者的一些浅见,欢迎指教。
上一篇:使用ADO.NET的最佳实践 人气:480
下一篇:IT 架构和应用程序的端到端测试 人气:425
浏览全部软件工程的内容 Dreamweaver插件下载 网页广告代码 祝你圣诞节快乐 2009年新年快乐