技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

CMM的关键过程域

Capability Maturity Model   CMM——Capability Maturity Model,能力成熟度模型已经成为现阶段最具有影响力的质量管理体系。   五个成熟度等级序列:       初始级——团队完全没有过程或者虽然过程到位但是未经正式评估。       可重复级——组织实施并研究过程,适用的坚持,不适用的抛弃,有能力地进行学习和改进。包含需求管理  、软件项目策划、软件项目跟踪与监督、软件质量保证、软件配置管理和子合同管理6个关键过程域。       已定义级——组织拥有一套经过试验并得到验证的过程,已经具备条件对建立起来的过程制度化。包含组织过程焦点、组织过程定义、过程培训大纲、集成软件管理、软件产品工程、组间协调和同行评审7个关键过程域。       已管理级——关注于过程测量,着眼于持续的过程改进,测量那些已定义的过程的有效性,监控全部正在进行的项目,采集度量数据,以用于性能改进。包含定量过程管理、软件质量管理 2个关键过程域。       优化级——一种不间断的、持续的状态,着眼于持续的过程改进。包含缺陷防范、技术更新管理和过程更新管理3个关键过程域。... 全文

CMM过程域 休闲 职场

“实践软件工程”:未来40年软件工程趋势预测(一)

关键字实践软件工程 软件工程 互联网 案例分享 有效性 适用性前言笔者认为“实践软件工程”(Practical Software Engineering)将成为未来40年软件工程发展的大趋势。实践(Practical)一词的含义具有双重含义。一方面实践指日后的软件工程焦点将从知识的完备性、体系性、权威性转向有效性、适用性。另一方面它还指日后软件工程的实践者而非发明者将拥有更多的话语权乃至主导权,案例分享将取代培训课程成为主流的知识获取途径。... 全文

cmm CMM 互联网 产品 敏捷 敏捷开发

有效建立企业级配置管理体系

引言配置管理是CMM(Capability Maturity Model 能力成熟度模型)第2级的KPA之一,是软件项目管理不可或缺的组成部分。在一个项目中实施配置管理,也许没有那么复杂,但在企业中建立配置管理体系(多项目配置管理),不仅需要配置管理技术、方法,更需要组织保障,一种良好的运行机制。... 全文

企业级配置管理 CMM配置管理工具

规范软件开发过程

随着软件系统的规模、复杂度日益上升,软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分,行之有效的软件配置管理(以下简称SCM,Software Configuration Management)能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性,以及降低软件开发的风险。软件配置管理的概念... 全文

软件开发过程管理 软件配置 CMM 项目管理

答CSDN关于建模的系列问题

最近工作一直比较忙,很多想法没时间写下来,最近回复了CSDN杂志社的一系列相关的建模问题,顺便贴在这里,欢迎大家讨论。以下是我对建模的一些看法1 你怎么看待建模?... 全文

uml cmm 语言 eclipse borland 设计模式

谈谈我职业生涯中的三次潦倒

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。本文地址: http://blog.csdn.net/jobchanceleo/archive/2008/11/12/3285783.aspx ... 全文

工作 cmm 咨询 生活 电话 出版

“燕云十六将”之CSDN总裁蒋涛(16)

上周写了《“燕云十六将”之Yvonne林锦黛(15),作为本系列最后一篇文章,我来写CSDN创始人、总裁蒋涛。蒋涛做为CSDN的创始人,他不开这个公司就没有CSDN的博客,也不会有我现在200多万的PV。在此使劲滴感谢一下蒋总!!!我们其实还是很有缘分的。早在03年的时候我们就见过的面,当时上海的林锐来北京做个免费技术讲座,当年林的公司也刚成立不久。在讲座上,经人介绍我认识了蒋涛,当时我是家CMM咨询公司的销售,估计他早把这事儿忘了。... 全文

创业 cmm 出版 咨询 工作

软件项目外包之路何以如此坎坷?

通过软件项目外包的形式获得令人满意的产品并非易事,想想当初为何美国国防部要求卡内基梅隆大学的软件工程研究所(SEI)制定现在广为人知的CMM就明白了。在此,我想就我的工作体会谈一谈软件项目外包之路为何如此坎坷。首先要明白的一点是,软件外包项目承包商(后面简称为“承包商”)与雇主之间的关系更多的是博奕,而非真正意义上的合作,因为两者之间存在利益冲突。雇主为了确保外包项目获得成功,必然会为承包商制定严格的成功评价标准,比如缺陷数不能大于多少,等等。承包商为了达到雇主所制定的成功评价标准,必然想法设法保证评价标准的稳定。要做到这一点,这就需要雇主做好需求管理 — 提供恰当、稳定的需求,然而即使雇主拥有经验丰富的架构师要做到这一点并非易事,最终结果就是很容易因为需求的不确定性而出现双方扯皮,从而影响了开发效率。造成承包商与雇主之间成为博奕关系的另一个原因与项目开发时间的估算有关。@Thinker姜志辉在MPD的演讲中指出,“估计项目开发时间的的目的是为了适应变化,而非评估本身有多精确”,他还让与会者通过做硬币游戏的方式深刻理解这一观点。尽管我本人完全认同这一观点,但该观点却无法在软件外包项目上获得认可而实践。理由很简单,雇主是以软件的完成时间支付外包费用的 — 软件开发所花费的时间越长,雇主所支付的报酬就越多。正因为做到精确评估项目所需开发周期不可能,这就使得开发时间的估算成为了承包商与雇主争夺的“制高点”。在“制高点”的争夺战中,会形成一种有趣的动态变化过程。如果承包商评估的时间存在富裕(这是她生存使然的行为),一旦被雇主感知(后面我们会谈雇主是如何感知的),雇主就会在项目的下一阶段通过某种方式的施压而压缩评估时间。承包商一旦接受,很有可能在开发的过程中发现时间不够,就会采用牺牲长远质量的做法,达到在承诺的时间内“完成”项目,承包商所采取的短视行为让项目欠下了技术债。由于技术债的存在,承包商在下一个阶段中会向雇主施压获取更多的估算时间,雇主由于产品面市方面的压力,即使觉得不合理也会答应承包商的要求(更换承包商会拉长项目周期)。这种“拉锯战”的最终结果往往不会是产品质量稳步上升(功能数量确实会稳步上升),反而是承包商在过程中不断地累积更多的技术债。最终雇主会发现,她花钱为自己制造了壁垒 — 项目只有该承包商可做,否则就得承担更大的损失。前面还留下了一问题,即雇主是如何感知评估时间是否过于富裕的呢?有两种途径。最“菜”的方式是通过项目阶段性“生产”出的代码行。之所以说这种方法“菜”,是因为这会诱导承包商采用copy-paste的方法“生产”出大量的冗余代码。另一种方式是评估软件的设计质量(注意,不是评估缺陷数量)。很不幸,真正懂软件设计的人其实很少,这一点我在《软件开发:个人与团队是永远的核心》中通过“能力金字塔”已指出。就我在Motorola的经历来看,与承包商打交道的架构师正是因为不懂软件设计而使得不能及时地发现项目中存在的风险(很多架构师虽有其名,但由于长时间脱离代码,最终蜕变成对软件设计质量毫无鉴别能力)。我曾经就某外包项目的软件设计质量对与承包商接口的架构师进言,他当时很气愤地质疑我“show me evidence”。戏据性的是,该架构师最后因为项目质量问题而调离了岗位,最后项目从承包商手中收回,并由Motorola的美国与中国团队进行了大规模的重新设计。软件项目外包的困境并非完全来自承包商与雇主之间,还来自承包商的内部。承包商通常不只为一个雇主服务,也很有可能承接多个项目。由于各项目存在不同的优先级,从而使得各项目间存在公司资源竞争。一旦某项目因为无法从公司内部获取好的人才,这势必影响项目的进展和质量。另外,由于承包商并不拥有产品,对于他们来说只能是做一单是一单,谈不上对所做的产品进行长期规划,这在很大程度上会影响软件人才的培养进程。在这类企业工作的工程师通常不会有很强的归属感,也不容易激发他们的学习兴趣,职场晋升的机会也相对少。如果你怀疑这一点,去了解一下大连的外包产业就知道了,据说大连的一些外包商已经在做相应的转型了。至此我们不难得出结论,要真正使外包项目成功,不光要承包商具备很强的专业性(不是指通过CMM5认证什么的,如果你还相信CMM能带来成功,多少有点幼稚。我所指的专业性在《软件开发:个人与团队是永远的核心》中有些阐述),还要求雇主对项目质量具备很强的控制能力(主要是架构师的能力。什么?靠项目经理?找死!),否则失败是早晚的事。由于人才的稀缺性,要满足这两个条件中的一个已不是易事,更别说两个。本文出自李云的博客,请务必保留此出处:http://blog.csdn.net/hzliyun/article/details/7844896。... 全文

motorola cmm 产品 工作 制造 游戏

阿蒙:一个程序员老总的年终总结

  这个题目让我面红耳赤,尽管在FasterSoft的创立与经营过程中我确确实实在头衔上是GM,但我有自知之明,公司发展得不好,任何的头衔都只是虚像或者是一个符号,实际上本质上我只是一个程序员,说得好听些,是程序员创业,目前FasterSoft规模不大,象许许多多的中国软件企业一样就十几个员工,公司成立一年多,目前仅可生存,因此我没有什么财富,但我觉得自已有创造财富的潜力,我也不象蒋涛同学那样的有名气,但或许我比蒋同学有朝气,因为我年轻,我冲劲十足,蒋同学的CSDN我有时并不看好,但我不看好并不代表它不好,或许现实中,CSDN的员工们正在等着蒋同学发放厚厚一贴的年终奖金,每个人都在笑逐颜开地骂我是SB呢。 阿蒙个小体弱,对于CSDN,还是少说为妙,否则引起群殴,偶是吃不消的,呵呵。 言归正传,首先很感谢我的合作伙伴:李青教授,刘文印博士,阎武博士,他们虽然不会太多参与公司的管理与运营,但他们的智慧与经验对我是难得的财富,我在他们的身上有学不完的东东,年底了,我已提交一份全面的、详细的公司运营报告给他们阅读,我在这里写的总结,纯属个人方面的,也许对各位同行有一点点的启发或帮助,那样的话,阿蒙就可以过一个快快乐乐的新年了。 商务方面 在过去的一年中,FasterSoft在商务运营方面还是取得了不错的成绩的,比如通过了国家双软认证,成为NEC的软件外包提供商,成为珠海移动的开发商,成为吉林大学珠海学院与中科大软件学院的科研实习基地,同时还获得了一些机构的相关资助,等等,这些成绩得益于每一个员工的努力工作以及公司管理层的良好决策,当然很重要的一点是得到了很多朋友与同行的大力帮助。 成立一个公司并不难,难的是让它成长并发展起来,这需要我们充分利用各种资源,作为程序员出身,我认为自已在企业商务运作方面还是有很多的不足之处,比如有时较拘谨与腼腆,好象不太适应大场面,还有口才欠佳,现在在努力提高中,知识面也不够丰富,当年我曾号称是国内看书最多的程序员,什么文学音乐美术天文地理三教九流都通通阅读,但还是感觉不够,我是很羡慕余秋雨同学的,他好象什么都懂,而且讲起来有如长江之水滔滔不绝,黄河泛滥一发不可收拾,我看到福布斯作家财富排行榜中,他老人家是排首位的,阿蒙是一个艰苦的创业者,将他人家拿到这里来开侃,真是委屈了。 我觉得人的精力是有限的,我渴望学习很多很多的东东,但有时感到力不众心,应该说程序员从事企业运营方面,虽然有诸多的不足,但也有好的地方,比如我们对人坦诚,思维慎密,逻辑严谨,擅长于分析,最主要是要有激情,脸皮要厚。随着公司的发展,我也期待自已不断地自我提高与完善。 研发方面 呵呵,这是我的老本行,应该说我对FasterSoft过去一年在研发方面的表现是满意的,很多人也许知道我是搞VC++出来的,FasterSoft成立之初也是以Microsoft的技术方向为主,但通过一年的发展,FasterSoft现在已形成了两个主要的技术方向:一个是以Microsoft的.NET、C#、VC++、SQL SERVER等为主的研发团队,另一个是以JAVA、ORACLE为主的研发团队,公司的研发能力已达到较高的水平,对目前主流的开发技术都能运用自如,可以应付更高要求软件项目或产品的研发,这要感谢各位同事的努力学习与工作。 在研发管理方面,我们也形成了自已的特色,我们没有照抄照搬什么规范标准之类的玩意,那些CMM啊,ISO啊,我们高攀不起,我们只是一家小公司,我们需要快速的反应,需要高效率的沟通与工作,我们每一个研发小组通常是3-5个人,根据项目或产品的规模来灵活分配人员,你可以说我们是小作坊式的,但那又有什么关系呢,关键是我们能在规定的周期内完成产品或项目的研发任务,这是最重要的,其它的让它们见鬼去吧,看看我们的研发TEAM,我想到一个名词:极限编程即XP,可能这是这样吧,我也没有时间去核准。  市场方面 这是我的弱点,也是我以及FasterSoft未来一年要重点提高的关键所在,我承认自已在市场营销的理论与实践方面都很缺乏,我也看了很多相关的书,但似乎不是看书就可以搞定的,中国软件业最弱的两个地方,一个是管理,另一个就是市场,面对日益猖獗的盗版以及摸不清搞不透的市场黑幕,我们是退缩还是前进?我开始的时候是很怕这方面的,用有限的资金去研发一个产品,我觉得有把握,但如果用有限的资金去投放在一个产品的市场上,我认为风险太高了,除非你的产品是非常独特的,只有你有,别人都没有,而且技术门槛很高,但试问国内有这种产品? 因此我是保守的,我觉得最好是投入的时候就可以看到收益,比如做软件项目,做软件外包,我看得见收入,但新产品的市场投入,有时就好象把MONEY丢进去了大海里,或许我的分析更加说明了我在这方面的愚昧无知,但不管如何,作为一家企业,必须面对市场,面对竞争,你不能因为困难而停滞不前,软件项目与外包很大的程度是为了生存,以及积累经验,企业最终还是必须要有自已的核心产品,并去市场上实现价值。期待来年,阿蒙能在这方面有所突破。 行政与财务方面 这也是公司很重要的方面,很感谢我的下属能很好地工作,使得公司其它方面能正常稳定地运作。作为企业的管理者,必须对公司的财务状况一清二楚,并能很好地做预算,能准确地算出项目的收益值与风险,我们的头脑里想得更多的应是赚钱,而不是守钱。 小结 呵呵,看完了吧,其实我只是简单地总结一下,也许有点班门弄斧,不过没什么,我脸皮厚,不在乎攻击,晚上一样能呼呼入睡,第二天又精神抖擞地投入工作与学习,每一天都要有新想法,新激情,所以我也期待CSDN哪天能旧貌换新颜,能带给我们一些亮点一点surprise! 顺便祝福每一个软件人工作顺利,来年好运!2006-12-26 22:30 http://www.vchome.net  ... 全文

microsoft 产品 vc++ 工作 sql server cmm

软件工程师所需掌握的“终极技术”是什么?

最近,我在微博上看到@程序员邹欣老师发的一条微博 — “不少大学同学都有一个想法:先做几年技术,然后做管理;也有一些同学说:我技术不行,希望直接找到一个管理的工作,就像PM那样。请看 PM 需要什么样的能力:(链接略去)”。在读这条微博的前一部分内容时,我的第一反应是:难道同学们以为做技术管理不需要很好的技术功底?刚好在此之前,我写过《技术敏感度 — 基层技术管理者必备》一文,强调技术功底对于基层技术管理者的重要性。于是,我对该条微博评论了:“建议邹老师建议他们好好地学一学技术,技术的精进一定会让我们或多或少地贯通管理(掌握软件开发的常识)。对于真要做管理的,建议他们在以后摆好心态 — 承认自己对技术的‘无知’,以及充分尊重技术人才并放权于他们”。之后,邹欣老师帮同学们提了一个让人深思的问题 — “技术有很多,有些技术还会过时,你具体指哪些技术呢?”某种程度上,这问题可以理解为是问:“终极技术”是什么?在执笔本文时,我总觉得以前写过类似的文章。查了一下,两年前的确以《软件开发,到底应当学什么?》为题写过了一篇博文。不过,过去的两年我又有了新的收获,或许可以借此机会再梳理一下自己的认识,以便与大家分享。身处节奏很快的IT行业,软件工程师一定希望自己在职业发展的道路上掌握“终极技术”,以便将来即使“长江后浪推前浪”仍能获得竞争优势。掌握“终极技术”对于我们究竟意味着什么?深刻理解这一问题有助于我们在面对技术学习和技术选择时不至于迷茫或人云亦云。我认为,掌握“终极技术”的最终目的不是为了能在工作中“耍酷”(“哇,这问题其他哥们都搞不定,只有我能!”),也不是为了追赶“技术潮流”(“听说Go语言以后能替代C/C++和Java,我得赶快去学!”),而是为了高质高效地工作,因为只有这样才能提高我们的生活品质和减少浪费(浪费可能包括奢华的青春和/或宝贵的社会资源)。实际上,我们一生都是在工作质量和工作效率的二维坐标系上“画线”。有的人一生都难以走出低质低效的困境(比如下图中黑色曲线所代表的人),而有的人却能进入高质高效的殿堂(比如下图中红色曲线所代表的人)。明白了掌握“终极技术”的意义,那“终极技术”究竟是什么?会是C/C++、Java、Objective-C或Go等编程语言吗?当一个只精通C/C++编程语言的人加入到以Objective-C为编程语言的项目上时,显然他必须重新学习编程语言。由此看来编程语言因为对不同的项目并不具备普适性,难以拥有“终极技术”之名。对于网上不少为编程语言而打口水仗的人,我真怀疑他们将编程语言当作是“终极技术”了。一旦知晓了“终极技术”的存在,你一定会发现,其实所谓的编程语言“优劣”跟本就不是业内的大问题。如果某种语言直接导致了项目的失败,那该语言早就绝迹了;反过来,如果某种语言直接导致了项目的成功,那世界上估计也只会有这一种语言了。因此,选择编程语言的重点不是考究其“优劣”,而是其适用性。过分计较编程语言的“优劣”其实是不成熟的一种表现。这类人还容易犯的一个毛病是 — 生怕落后,热衷于学习新的编程语言。请别忘了,编程语言我们无论如何也学不全,即使真有人学全了,我也怀疑他所学的只是皮毛。“终极技术”又会是Linux或Windows这样的操作系统平台吗?由于它们同样不具普适性,所以不可能有“终极技术”之实。同样地,.Net、ACE、QT等都不可能是“终极技术”。真正的“终极技术”一定具有一定的普适性,能让我们将之运用于各种不同的软件项目。正因如此,“终极技术”具有一定的抽象性。对于软件行业来说,真正掌握“终极技术”意味着:深刻地理解软件(开发)的复杂性本质,并拥有有助于实现高质高效工作的行为(意识、工作习惯等)、能力(思维、业务、沟通)和方法(流程、工具、复用)。由于“终极技术”过于抽象,使得我们不得不通过一些问题来间接感知。比如:1)编程好习惯对于软件产品的质量重要吗?如果重要,如何让团队形成良好的编程习惯?哪些编程习惯算是好的?2)软件质量的根本是什么?是设计,抑或测试?高质量的软件对工程师的工作与生活又意味着什么?3)软件架构师重要吗?还是只是个虚职?如果重要,软件架构师需要掌握哪些技能?4)在软件行业具有很大影响力的CMM(软件成熟度模型),其倡导用软件过程的成熟度来度量组织的软件开发能力。那为什么通过CMM最高级别认证的组织仍会开发出质量一塌糊涂的软件?如果你身临其中,能发现导致这种糟糕结果的关键因素吗?5)软件平台与框架被广泛地认为是高效开发高质软件的方法,但为什么企业运用这一方法后,平台与框架最终却成了一个包袱?困境的表现是什么?什么因素造成了这种困境?有方法避免进入这种困境吗?6)业内大量使用“最佳实践”这一词汇。真正存在最佳实践吗?为什么有的“最佳实践”在组织中却无效?7)……这些问题大多是开放性的,而且不少问题既涉及管理域,又涉及技术域。面对这些问题的关键不在于其是否有标准答案(或许根本没有标准答案),而在于我们是否为之痛苦过、思考过,并形成了自己的想法。要知道,这些想法就是我们在工作中面对选择时用作决策的依据。如果从来没有这类苦恼,很难想象我们真正掌握了“终极技术”。值得一提的是,这些问题只是基于我自己肤浅的认识所提出的,我相信读者还有很多类似或其他的问题。如果将软件(开发)的复杂性比喻为一头大象,那么我们每一个人或许是正在摸象的又瞎又聋的人,我们穷一生通过“摸”的方式,在头脑中构建“象”的模样。这个比喻间接地告诉我们,“终极技术”并非是某种一成不变的内容,其中更涵盖有每个人根据自己的阅历所总结出来的在高质高效工作道路上成功应对困境的方法和信念。“终极技术”一定是通过掌握象编程语言等非“终极技术”而最终掌握的,也需要我们通过经受软件项目的痛苦磨砺去沉淀。在没有掌握“终极技术”之前,请不要停留在编程语言专家、Linux内核专家、.Net专家这样的光环之下,继续探索,前面还有更大的舞台等着你!在掌握“终极技术”的职场旅途中,我们得先认识到一点:就技术内容而言,职场首先比拼的并不是智商,而是我们的坚持与良好的工作习惯。工作中的很多道理我们都懂,但就是不能坚持做到深究,也难以通过坚持克服陋习去形成更多的好习惯。在掌握“终极技术”的道路上,我们一定会看到很多不尽人意的内容,也会面临不少困难与挫折,即使理智上悲观,但我们在行动和意志上一定要保持乐观(注:Antonio Gramsci的原话是“理智上悲观,意志上乐观”)。推荐阅读技术敏感度 — 基层技术管理者必备》《软件开发:个人与团队是永远的核心》《什么是软件设计》《软件设计的真谛》《软件质量是什么》《软件架构师的能力与特质》《软件平台与框架的生命周期》《该死的“代码就是文档”》本文出自李云的博客,请务必保留此出处:http://blog.csdn.net/hzliyun/article/details/8053957。... 全文

编程 语言 工作 cmm 平台 框架

多少钱也不能卖我的命——蒋涛 PK Leo实录(4)

接上次《CSDN总裁的第二次创业经历——蒋涛 PK Leo实录(3)》 Leo我的第二次创业是这样,我从一毕业97年一直做到04年,我现在的职业是职业规划师,有人问我说,Leo这么多年你有没有迷茫过?问题很尖锐,我每次都不避讳回答这个问题,不只迷茫过而且次数很多。... 全文

创业 工作 咨询 cmm 技术人 产品

1