用户操作
[即时聊天] [发私信] [加为好友]
emag_seID:emag_se
39850次访问,排名2862好友0人,关注者0
emag_se的文章
原创 17 篇
翻译 0 篇
转载 0 篇
评论 29 篇
最近评论
aaatingting:业博通CRM比较实用, 操作简单易学易用, 最重要的是易推行! 可以到这里了解一下! 搜索关健词:[url=http://www.crmway.net/Domestic]crm软件[/url];[url=http://www.crmway.net/crm-mfbml/crm-mfb]crm系统[/url];[url=http://www.crmway.net/crm-xyptml/crm-p……
oiom2000:个人觉得造成这种问题的原因是因为国人大多在技术领域支撑不了多长时间就转投到管理方向了~
在微软和IBM这样的顶级公司其测试人员很多都是在开发领域工作了长达10年以上的~有相当的工作经验,能熟练的设计中不完善的算法国内有几个人坚持到10年以上~
《十年学会编程》很多人都看过了吧,有几个人是这样做的~
mark0402:“在微软等软件过程比较规范的大公司,软件测试人员的数量和待遇与程序员没有多大差别,优秀测试人员的待遇甚至比程序员还要高。”

说明两点:
1.数量和待遇普遍不如程序员
2.优秀测试人员要到甚至的程度才有可能会比程序员待遇高
sherryguan:是啊,国内的软件测试的处境,以上七点基本能概括,让我们这些做测试人的IT ,有些茫然
vanbastan2:测试还是不受重视啊,开发可以随意拖延转测试时间,但是测试的时间却是从来被压缩的,而且SE感觉是和开发一伙的。测试的兄弟当自强呀
文章分类
收藏
    相册
    杂志封面样刊
    存档
    软件项目交易
    订阅我的博客
    XML聚合  FeedSky
    订阅到鲜果
    订阅到Google
    订阅到抓虾
    订阅到BlogLines
    订阅到Yahoo
    订阅到GouGou
    订阅到飞鸽
    订阅到Rojo
    订阅到newsgator
    订阅到netvibes

    原创 [竹马推荐]砖头XP(88TechReview提供)收藏

    新一篇: [竹马推荐]转型:管理之路VS技术之路(管理频道提供) | 旧一篇: [竹马推荐]旧话重提:开发过程中的软件质量保证(88TechReview提供)

    砖头*XP*简单设计

    frankcai@freecity(frankcai_zju@csdn)
    就读于浙江大学计算机学院, 涉猎比较广泛,
    曾在浙江大学嵌入式系统实验室, Autodesk上海软件研发
    中心从事软件开发,对c++,软件工程比较有感情,
    现在做j2ee方面的金融项目。

    扔块砖头先,
    大牛们多砸些玉过来,好像小辈开开眼:)
     
    XP主张简单设计,在extreme programming explained 里面说到
    原因是传统软件工程认为应付变化的成本随时间指数增长。
    xp认为现代软件开发过程中这条定理已经不成立了,
    因为采用了面向对象软件设计方法和设计模式之类的方法就可以,
     
    我觉得这应该不太可能吧?
    即使是面向对象,即使是很好的运用模式,
    这最多也 是在一定程度上可以从容应付变化吧?
    如果是需求变的太大,再怎么面向对象也是没用的吧?
    不知道实际中是怎么样的?
     
    然而我还是非常同意简单设计,原因是既然需求总是多变,
    我们不可能在一开始就把需求真正捕捉到,与其把大量的时间花在
    对那些错误需求的设计,实现,测试中,还不如开始的时候简单一点,
    把最核心,最不可能变的那部分做出来,然后再用它捕捉需求,对它进行修改,也许
    这时候我们会觉得要花很多时间,但是其实在前面我们节省了很多时间了,
    而且总的看来,我们浪费在错误需求上的时间少了,节省的时间就多了,
    这可能也可以说是原型方法吧。
    另外,在技术风险比较大的时候,(比如我们学生用新学的东西做事)
    开始过多的考虑细节,试图一次把问题全部搞定,
    往往会降低效率,比如一点一点做来的好,当然,这是在整体的结构已经清楚的情况下。
    (这一点是我自己实际的体会:)
     
    以上拙见,诸君见笑。

    发表于 @ 2005年03月10日 15:04:00|评论(loading...)|编辑

    新一篇: [竹马推荐]转型:管理之路VS技术之路(管理频道提供) | 旧一篇: [竹马推荐]旧话重提:开发过程中的软件质量保证(88TechReview提供)

    评论

    #for 发表于2005-03-12 04:33:00  IP: 221.202.169.*
    最近想对某一特定类型项目产品做些评估工作,就从评估谈起吧。
    从方法上评估一般有事先的评估和事后的评估,也就是主观评估和客观评估。主观评估一般借助于专家的知识和经验,以及一些相关客观评估结果作为参考;客观评估可以做对比测试等方法。

    对于一个项目及其衍生产品,主观评估与客观评估应该是完全不同的两个方法。主观评估在方法论上就有天生的问题,相对于客观评估的“客观性”、“最终裁决性”,主观评估蕴含着固有的风险和不可知性,但有时是唯一方式,另外相对付出的代价相对很低。

    比较于软件项目的开发,一开始总不能有什么客观评估吧,只能进行主观上的考虑,所以按照以前的方法,比如瀑布式开发,尽可能找多一些和大一些的牛人,甚至借鉴其他类似项目的客观评估结果,力图使主观预测和计划达到完善。但是这种方式没有改变方法论本身的固有缺陷,无法有效规避这种方法论本身带来的风险。

    所以近些年来就提出了一些新的方法论,也就是不再完全依赖于具有天生缺陷的前期主观计划,而是另辟蹊径,从项目进行的过程上进行控制。比如rup,xp,都强调迭代,也就是采用代价相对较小的方式引入客观评估,以期达到逐步逼近理想目标的效果。但是在每一个迭代过程中,还是要强调尽可能的主观完善,否则就真成了摸着石头过河了。

    其实这种方式早就存在于国家体制的演变和军队战争中,但那都由于要付出血的代价而恶名昭著,因而避之不及,结果特别是在技术理论方面造成了另外一种极端状况,就是过分依赖于前期的主观判断,反而后患无穷。

    人生就在天堂与地狱之间。
    发表评论  


    当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
    Csdn Blog version 3.1a
    Copyright © emag_se