导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:954950
  •  

2007-7-17 13:19 | 软件架构师-转载自IBM

在电影制作术语中,软件项目经理被称作制作人,因为他们决定需要做什么事情。而软件构架师就是导演,他来决定所作的事情是否正确,并且他要保证产品符合投资人的要求。下面这篇文章就是描述软件构架师的。 illustration这篇文章是关于软件构架的系列文章(共四篇)中的第二篇。上个月,这个系列文章中的第一篇给构架作了一个定义。因此现在我们可以把注意力集中到创建构架的人员——构架师身上。软件构架师被证明是软件开发项目过程中最具挑战性的角色。软件构架师是项目的技术领袖,并且从技术角度来讲,他承担了项目成败的责任。
下面是电气及电子工程师协会给“构架师”做的定义:
软件构架师是技术主管
首先,软件构架师是技术主管,这意味着除了他要有技术上的技能外,还要有很好的领导才能。构架师的领导能力在团队中和项目质量控制中起着十分重要的作用。
在团队中,构架师是项目的技术总管,他需要有丰富的知识背景,以便作出技术上的决定。相对于构架师来说,项目经理是来管理项目的资源,时间进度和花费的。使用电影制作来做类比的话,项目经理就是制片人(他要确定工作被完成了),而构架师是导演(他需要确定工作被正确的完成)。由于他们在项目中所处的位置,构架师和项目经理是公众人物,在一个团队中,他们是整个项目所涉及的所有人员的联系枢纽。构架师应该为建立软件构架争取投资,并且要明确建立软件构架能给组织带来的价值。
构架师还要把团队组织在构架周围,并且要积极地投入到计划活动上,因为要把构架转化成为完成任务的先后顺序,这样才能及时地确定在什么位置需要什么技术。有一点需要注意,由于构架师能否成功与团队的整体水平有很大关系,所以构架师应该参与团队新成员录用的面试。
根据构架师所拥有的能力,他可以同时参与其他团队的工作。构架师需要根据具体的实例情况来做领导决定,并且在决定过程中要展现出足够的自信。一个成……
编辑 | 阅读全文(2290) | 回复(1),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | CMM精彩隐语两则

案例背景:有一间房子,里面有一些人,一些杯子和水壶,以及用于烧水的用具,所有的人都需要喝开水。 CMM 1级:
过程:
找到杯子和水壶
倒水喝
问题:
找不到杯子,没水喝
找不到水壶,没水喝
水壶没水——不知道该怎么办
一天要喝多少水——不知道
倒一杯水要花多少时间,每个人每天为倒水花多少时间——不知道
思考:
买个饮水机能解决问题吗?
CMM 2级:
过程:
杯子放在茶几上
水壶放在餐台上
如果水壶没水,在厨房烧水
杯子用完要清洗,并放回茶几
培训:厨房烧水,清洗杯子
度量一天要烧几壶水,每个人每次/每天倒水要花多少时间
有人检查是否所有人用完杯子后都清洗并放回餐台
管理者关注这些活动的执行状态与成效
问题:
烧水太花时间
水要等凉了才能喝
效率不稳定:有人每天花20分钟倒水,有人每天花80分钟
思考:
买个饮水机能有帮助吗?
CMM 3级:
过程:
所有人都先在茶几取杯子,再去餐台倒水
统一用大杯子
每人每次倒两杯水,与人分享
指派专人定时烧水,放在凉水壶里
指派专人定时收集和清洗杯子
问题:
怎样才能做得更好?
思考:
买个饮水机划算吗?
CMM 4级:
过程:
建立评价模型:节省1分钟=节省1元钱,如果每人每天节省1分钟,则100个人1个月(30天)可以节省3000元——只要每月花费不超过3000元,我们就可以尝试新过程定义量化的管理目标:3个月内将每人每天用于倒水的时间减少2分钟以现在每人每天用于倒水的时间建立基线:平均10分钟,最少5分钟,最多20分钟每个人为自己制定优于平均值的目标:本人每天用于倒水的时间不超过6分钟
度量并监控每天用于倒水的时间,一旦超过6分钟,要分析根本原因,并制定调整措施;最后结果是8分钟,超出预定的目标,但比平均值要好3个月后调整基线:平均8分……
编辑 | 阅读全文(1267) | 回复(1),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 流程重要还是人重要

项目管理联盟论坛上的一个激烈讨论,值得一看。
 
1)过程(process)是非常重要的。
2)过程是可以根据项目的特性等进行设计的。
3)过程是需要通过量化指标(metreics)来衡量的。
4)量化指标是用来显示项目的状态的,更是用来进行项目控制的。
5)“人”和“过程”相比,“人”是次要的,“过程”是主要的。就是说,不能因为什么人水平很高就可以不按照“过程”去做。
 
具体链接:
 
编辑 | 阅读全文(1484) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 管理摘要

灵活要有原则,原则不可灵活
原则或规范一制定出来就不能轻易改变,而且需要项目经理带头遵守。
 
不能有活无人做,也不可有人无活做。更可怕的是一件事许多人在做!遇责任则无人承担,遇功劳则人人有份!
角色和职责一定要定义明确,项目经理和成员都要勇于承担责任。
 
过程与结果:对基层的职员要重视过程管理,对高层的职员要重视结果管理。如果颠倒过来,管理必乱。如果一视同仁,集体的效率必下降。
 
批评是管理必要的手段之一,但不是主要的手段。从不批评下属的领导不是好领导,不会批评的领导也不是好领导。批评不是苛责和谩骂,批评应成为一种激励方式。因此批评必须建立在所犯错误事件主体的基础上,不要做任何延伸。批评要以指导、校正工作为目的。
 
何为合理的目标?即是让他需要跳起来才能摘到的果子。也就是说目标不要太容易达到,也不要太高让他无法达到。太容易达到的目标没有促进作用,无法调动员工的全部工作激情;太高的目标,又会让其认为反正努力也没有用从而失去激励作用,员工心灰意冷,丧失斗志。
目标是需要多比别人努力才能够达到的东西
 
工作标准化、工作表单化、工作流程化、工作细致化、工作合理化是发展型企业必要的五化。
这里是有先后关系的,逐步改进
 
我们必须尊重每个人作为个体的特异性。随着社会的发展,这一点愈加重要。可是一个企业也有其独特之处。所以当企业遭遇人才时,该如何处理两个特定个体的矛盾?如果过于尊重人才的特异性,那么会出现换一个经理就换一个管理模式,企业始终不能形成规范的操作模式。如果过于拘泥于企业的固有特性,那么使人才缚住手脚,才华不得施展,同样,企业长期没有新的观念、方法,就无法革新与进步。怎么办?
在满足企业或项目大原则的条件,最大限度的尊重个体差异.
 
……
编辑 | 阅读全文(1936) | 回复(1),人月&神话 发表于 2007-7-17 13:19
    项目管理与产品管理是紧密相关而又不同的管理内容。在企业中,产品管理是主线,而产品生命周期中的具体阶段的工作过程,则可以通过项目实现。产品管理是项目管理的目标,而项目管理是产品管理的实现手段。同时,产品生产工艺特点决定了项目的基本过程,但具体的生产过程组织,只有通过项目管理才能完成。在具体项目中,往往两者会同时存在,特别是在提供服务的项目中,也包含了服务产品的生产过程,项目管理者必须在非常清楚两者各自的管理内容的前提下,将两者有机地结合起来,才能同时满足各方面的要求。   以软件项目为例,看看软件工程方法与项目管理方法之间的关系。一提到软件工程,大家自然就会想到软件开发、项目组,想到新产品开发有关的种种相关的工作内容。现在把项目管理和软件工程联系起来,就更让人想到软件开发中的项目管理、项目组的管理。那么,项目管理和软件工程之间到底应该是什么关系呢?
  我们首先来回顾一下软件工程的有关内容。软件工程是针对软件这一具有其特殊性质的产品的工程化方法。它关注的是软件产品的生命周期,包括从规划、设计、编程、测试、到运营和升级维护等主要阶段,而且随着软件产品的不断升级维护,还会使同一软件产品经历多次这样的生命周期,软件工程在产品的一次生命周期的各个阶段中,提供了一整套的工程化的方法,来指导软件人员的开发工作。因此可以说,软件工程是一种围绕产品生命周期的工程化方法,是软件产品的生产工艺。
  我们再来看一下项目管理。项目管理是针对一个项目的管理方法,它关注的是项目的生命周期,包括从项目的启动、计划、执行,到控制和收尾共五个主要的项目过程。在不同的过程中都涉及到对时间、人员、成本、质量、风险等内容的管理,强调的是项目的绩效,通过有效的项目管理来完成对项目提出的需求,这当中也包括交付软件产品。因此,项目管理是关注项目生命周期的管理方法。
  既……
编辑 | 阅读全文(1023) | 回复(1),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 看球感悟CMMI

CMMI组织级规范和过程资产:国际足联规则,大家必须遵守,裁判完全按此规则执法。有异议可以上报到国际足联讨论和修订。
 
过程裁剪:各洲可以制定自己的规则,对国际足联规则进行裁剪或补充。如亚足联可以制定《亚足联规程》,但必须要上报到国际足联批准。
 
裁判:QA人员,检查是否按照规程执行。其中助理裁判主要检查项目是否跳过程执行。
 
教练:项目经理,追求的不仅仅是一场胜利,而是一个有冲击力的战斗团队。
 
技术指标统计:类似于CMMI中的MA度量分析,其中既包含了收集和统计数据,又包含了分析数据。收集数据可以由他人或系统自动完成,但分析数据需要项目经理来完成。
 
排兵部阵:类似于项目计划,知己知彼,百战百胜,教练排兵需要充分考虑对手,自己队员,场地,环境等多方面因素。项目经理拟制项目计划需要考虑相关干系人,项目目标范围,依赖约束,风险等多项因素。
 
阵型:究竟是打442,还是433或其它阵型,需要充分考虑对手,环境特点。因此阵型类似软件项目管理中软件开发生命周期模型的选择。必须要对项目规模,周期,需求等多种因素综合分析后才能选择出合适的生命周期模型和开发方法论。
 
替补队员:项目资源计划余量,替补队员也是项目首发成员有可能受伤或表现不佳风险的应对措施,这里替补队员是一种主动接受的应对类型。
 
守门员:防止项目需求蔓延,更多应该是项目经理程度该责任。
 
中后卫:最后一道防线,对比到项目中的后期系统测试和验收测试,通过即可以完成项目。
 
边后卫:对应项目的单元测试和集成测试,完成产品首先要过这第一关。
 
前锋:给需求人员,第一时间接触客户,了解用户需求并将其转化为软件需……
编辑 | 阅读全文(1480) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 说梦话的境界-转

那段时间我最好的一个兄弟比较喜欢下象棋,有天晚上睡着了,他LP在旁边看书。
 
突然听他嘿嘿嘿笑了几声,然后大喊一声:“将军!”他LP知道他在说梦话,头都没回接口到:“那我支士!”那家伙马上就说:“我下马将你又如何?”他LP:“出帅。”兄弟:“我沉炮将你又如何?”他LP:“呢我上相!”兄弟:“老子的车摆在这里好久了你还敢上相,你棋都看不到还下个P啊!”他LP:“那你赢了......”
 
我兄弟又嘿嘿嘿笑了几声就继续睡了......
编辑 | 阅读全文(1283) | 回复(0),人月&神话 发表于 2007-7-17 13:19
关键字:CMM
对于实施CMMI,对软件过程进行改进,我原来一直观点是CMMI实施不一定能够提高软件的质量,因为过程和人始终是两个重要因素,软件项目团队和人往往起到重要作用。
 
当我们持这种观点的时候往往就表明了我们的成熟度比较低,没有上升到项目级和组织级,整个项目的成功往往取决于项目中的几个关键人员,这样对项目和组织的危险性都是很大的。实施CMMI的一个重要目的就是要尽量的减少人对项目的影响,形成组织级的过程和规范。因此我现在观点是实施CMMI一定可以改进软件质量,如果你实施了CMMI没有改进质量,只能够说明你某些重要的KPA没有达到CMMI的要求。
 
需求的不稳定或需求范围的蔓延往往是我们经常都要分析到的软件项目的关键风险,出现频繁需求变更的一个关键其实是需求开发RD这个过程域没有做好,如果我们前期需求收集,需求开发,与用户有足够多的沟通,交互和原型的演示,原则上不应该出现过多的需求变更。
 
GG通用实践里面有两个重要的实践,一个是提供相应的资源,当资源技能不足的时候组织应该保证充足的技能培训。但我们项目一启动的时候,一般这两点都很难满足要求,及时资源能够满足,但人员的知识和技能水平往往也不能马上得到满足,而往往这个时候项目根本不可能说等着组织把你的人员培训来技能满足要求了,再给你,再开始项目,所以往往你知道人员技能有问题,还是得开始你得项目。所以经常出现这种情况往往是我们得GG根本没有达到要求,而CMMI很简单给你一个实践在需要时候可以得到充足满足技能得资源,及时不满足组织级可以通过技能培训让资源满足要求。所以这看似简单一句话,就包含了诸多需求我们进行过程改进得地方,需要考虑人得因素得地方,你做不到不能说CMMI不好或者没有要求,只有说你成熟度没有够。
 
有些项目往往一开始就注定失败,一个重要得是技术方案得选择,对于决定着项目重要成败得技术方案CMMI……
编辑 | 阅读全文(2026) | 回复(2),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | CMMI基础知识回顾

CMMI包含了三部分的内容:CMM的内容,系统工程的内容,集成产品开发IPD的内容。充分体现了集成,体现了软件工程和系统工程的集合。因此CMMI既可以用于软件工程,也可以用于系统工程。
 
CMMI分为阶段型和连续型。阶段型是从1到5级。连续型是从0到5级。
 
组织级的过程能力是靠一组过程能力结合起来体现的,而不仅仅是实现单独一个过程。而提高组织级能力成熟度一般采用阶段型模型,即Level1到Level5,每个级别都又相关的KPA.
 
过程域PA可以按照过程管理,项目管理,支持,工程四个大类进行划分,具体可以参考Blog中的下图:http://blog.sina.com.cn/u/493a8455010004c7
 
有两种类型的目标和实践:一种是特别目标SG和特定实践;一种是共性目标GG和共性实践GP。
 
GG和GP主要分为是个步骤来实现:执行委托-》执行能力-》指导实施-》验证实施。其中执行委托是GP2.1;实现能力是GP2.2 GP2.3 GP2.4 GP2.5 GP3.1;指导实施是GP2.6 GP2.7 GP2.8 GP3.2 ;验证实施是GP2.9 GP3.0
 
CMMI实施一般遵循IDEAL方法论,即启动(I)->诊断(D)->建立(E)->行动(A)->学习(L)
 
阶段表示能力成熟度的五个等级:初始级(1)->受管理级(2)->已定义级(3)->定量管理级(4)->持续优化级(5).
 
相关的名称和术语定义如下:
干系人(Stakeholder)
项目经理(Project manager)
高级经理(Senior manager)
组织(Org……
编辑 | 阅读全文(1651) | 回复(0),人月&神话 发表于 2007-7-17 13:19
你们的项目组使用源代码管理工具了么?
采用ClearCase进行源代码管理,同时启用开发,测试,集成三个分支,对于Bug分支根据版本实际情况确认是否启用。
 
你们的项目组使用缺陷管理系统了么?
使用ClearQuest管理缺陷和变更
 
你们的测试组还在用Word写测试用例么?
采用TestManager写测试用例和管理测试用例,必要配合Excel进行。
 
你们的项目组有没有建立一个门户网站?
项目有专门的讨论工作室。
 
你们的项目组用了你能买到最好的工具么?
能够买到。主要是VS.Net和PL/SQl Developer.其它辅助工具全部用开源工具。如打包采用Nant,反翻译采用Reflector,单元测试采用Nunit.
 
你们的程序员工作在安静的环境里么?
是的,有独立安静空间。
 
你们的员工每个人都有一部电话么?
一般两人一部电话,还可以通过RTX进行沟通。
 
你们每个人都知道出了问题应该找谁么?
知道
 
你遇到过有人说“我以为…”么?
有时候会遇到,但情况不多。
 
你们的项目组中所有的人都坐在一起么?
没有。全部座来分开,通过RTX即时通讯,邮件,电话进行沟通。
 
你们的进度表是否反映最新开发进展情况?
有及时准确的进度表,但不是每个项目成员都很容易看到。进度表有专门的基线和里程碑的定义。
 
你们的工作量是先由每个人自己估算的么?
不是开发人员自己估算,是有项目的估算小组进行估算。估算时候会适当考虑个体差异。
 
你们的开发人员从项目一开始就加班么?
基本不会。
 
你们的项目计划中Buffer Time是加在每个小任务后面的么?
不是……
编辑 | 阅读全文(1370) | 回复(0),人月&神话 发表于 2007-7-17 13:19
许多人都以为项目经理总是与“理想与光荣”相伴的,其实作为一个有志于改进中国软件开发流程的项目经理来说,他们承担的更多的是“艰辛与痛苦”。
  
在这里,我通过我担任项目经理期间所遇到的种种现象,来总结项目经理所必需具备的素质,当这些素质您不具备的话,就需要花费多年的努力来培养他,如果无法培养成功,那么请您转换岗位,因为项目经理不适合您,您难以在这个方面获的成功。
 
1.执着
可以这么说,在中国如果不执着是做不成任何事情的,因为在软件开发流程中推行各种规范和管理制度的时候,你可能遇到各种各样的阻力和障碍,如果没有应付挫折的思想和准备,你是很难推行成功的。要知道这样一个基本事实,项目管理成败的关键是:如果你不坚持,谁也不会坚持下去的。指望领导的扶持和群众的自觉是不可能的。只有坚定信念,努力打动别人,才能成功。
坚持到成功为止。只要决定上管理流程了,就不要后悔,唯有坚持,因为你拼命努力而实现了99%,你却不知,最后当你决定放弃的时候也许就是你要成功之时。要知道你准备放弃的时候可能正是对方也准备放弃之时,唯有坚持,你才能成功。
 
2.亲和力
亲和力是指你和团队相互依赖,相互信任能力的大小。亲和力是你领导团队走向成功的基础,如果一个团队的向心力不够,各自为政,那么失败就会在身边陪伴你。要团队的每个成员都信任你,你必须要做到关心下属,主动与下属沟通,为下属争取合法权利等。关心下属就是在日常工作中对下属的工作状况,发展方向进行指导,避免其走弯路;在生活中也对其身体状况进行关心,促进身体和心理健康的恢复。
  
多找下属沟通是消除误会的润滑剂,同时也是了解下属内心真实想法唯一捷径。做项目经理的人,在某些事情上的处理的确会与人不同,也难以令人理解。这个时候只有多与下属沟通,逐步达成共识,争取大家的理解和支持。记住,没有……
编辑 | 阅读全文(953) | 回复(0),人月&神话 发表于 2007-7-17 13:19
有一天,猎人带着一只猎狗,到森林中打猎,猎狗将一只兔子赶出了窝,追了很久也没有追到。后来兔子一拐弯,不知道跑到哪去了。牧羊犬见了,讥笑猎狗说:“你真没用,竟跑不过一只小小的兔子。”猎狗解释说:“你有所不知,不是我无能,只因为我们两个跑的目标完全不同,我仅仅是为了一顿饭而跑,而它却是为了性命啊。” 
这话传到了猎人的耳朵里,猎人想,猎狗说得对呀,我要想得到更多的兔子,就得想个办法,消灭“大锅饭”,让猎狗也为自己的生存而奔跑。猎人思前想后,决定对猎狗实行论功行赏。 (大锅饭是扼杀积极性的第一敌人)
于是猎人召开猎狗大会,宣布:在打猎中每抓到一只兔子,就可以得到一根骨头的奖励,抓不到兔子的就没有。 
  
这一招,果然有用,猎狗们抓兔子的积极性大大提高了,每天捉到兔子的数量大大增加,因为谁也不愿看见别人吃骨头,自己却干看。 
  
可是,一段时间过后,一个新的问题出现了:猎人发现猎狗们虽然每天都能捉到很多兔子,但兔子的个头却越来越小。 
猎人疑惑不解,于是,他便去问猎狗:“最近你们抓的兔子怎么越来越小了?” 
  
猎狗们说:“大的兔子跑得快,小的兔子跑得慢,所以小兔子比大兔子好抓得多了。反正,按你的规定,大的小的奖励都一样,我们又何必要费那么大的力气,去抓大兔子呢?” 
  
猎人终于明白了,原来是奖励的办法不科学啊!于是,他宣布,从此以后,奖励骨头的多少不再与捉到兔子的只数挂钩,而是与捉到兔子的重量挂钩。 
  
此招一出,猎狗们的积极性再一次高涨,捉到兔子的数量和重量,都远远超过了以往,猎人很开心。  (考核机制要适当量化,定性和定量要结合)
  
  
遗憾的是,好景不长。一段时间过后,新的问题……
编辑 | 阅读全文(1175) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 软件开发管理模式

SCRUM
由Ken Schwaber和Jeff Sutherland提出和倡导
是一种极为轻型的灵活性模式的翻版
非完整的:没有整个流程的定义
采用所谓的"sprints",即一般是一个月为周期,来进行循环式的短期性的开发和发行管理
每天进行15分钟的团队“scrum会议”
采用每天进行项目的最新状态汇报,发表“burn down graph”
适合于整个开发团队在同一个大房间里一块工作
scrum本意是指橄榄球在开赛前的手拉手聚在一起商议进攻方案,在这里是指项目管理的模式,指每天在开始工作前要所有团队成员在一起开会,商讨当天的工作和遇到的问题。
 
Adaptive Software Development(ASD)
由Jim Highsmith提出和倡导
也是一种轻型的灵活性模式,强调在混乱的边缘上争取平衡
不要求执行者完全按照流程规则来做
在项目周期里安排一个学习阶段,具体解决哪些是重要的开发任务
将项目的历程分成3个阶段:思索、合作、学习(speculate,collaborate,and learn)
讲究在合作阶段进行循环式的重复渐进,采取“时间盒”(TimeBoxed)的方法
 
Crystal
由Alistaire Cockburn提出和倡导
灵活性模式的一种,尊重不同大小的项目在管理上需要有不同程度的正式性管理规章,强调在完成目前的开发项目的同时,要将眼光放在开发团队和企业未来的位置
使用几个不同的管理方式:透明、黄色、桔黄、红色等模式
采用轻型化的规章制度
比较注重项目文档的用途,要求管理人员使用各种文件来帮助管理
 
eXtreme Programming(XP)
由Kent Beck,Ward Cunningham,Ron Jeffries提出和倡导
……
编辑 | 阅读全文(2372) | 回复(0),人月&神话 发表于 2007-7-17 13:19
Ivar Jacobson博士   
 
他被认为是影响或改变了整个软件工业开发模式的几位世界级大师之一,是软件方法论的一面”旗帜”。他是组件和组件架构、用例、现代业务工程、Rational统一过程等业界主流方法或技术的创始人。
  
Ivar Jacobson博士认为,如果采用不良的软件过程,通过CMM/CMMI的成熟度级别越高,只会使软件企业生产不合格软件的过程更加有效率,而不是使企业开发出更好的软件。
  
软件外包是时下的一个热门话题,被我国不少软件企业视为一座金矿,而CMM被人们认为是进入这个市场的敲门砖,为了拿到那张代表资格的CMM认证证书,不少企业甚至不惜投入数百万之巨。事实上,拿到CMM认证在国外并不代表企业就能提供一个合格的软件,著名的软件专家、拥有组件技术、用例技术等多项发明、与Grady Booch、James Rumbaugh一起被称为UML之父的Ivar Jacobson博士在近期访华期间一再提醒中国的软件企业,谨防掉入CMM陷阱。

CMM/CMMI的缺点
  
CMM/CMMI最早起源于美国国防部。为了改变在采购过程中频繁地采购到大量不合格软件的局面,美国国防部需要一种评估软件质量的方法,这就是要求软件企业进行CMM/CMMI认证。然而,CMM/CMMI真正解决这个问题了吗?
  
CMM/CMMI被认为是一种最成熟、最有效地提高软件工程化水平的方法和标准,用来评估和改进过程,它是一个描述在软件开发过程中有待改进的关键因素的框架,描述了一个能用渐进方式进行改进的途径。它为软件过程改进提供一个基础,将软件开发从一个相对来说随意、不成熟的过程变成非常成熟的、有规律的、可管理的过程。
  
然而,CMM/CMMI也有一些与身俱来的缺点不容忽视。比如,CMM/CMMI的评估……
编辑 | 阅读全文(1694) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 973 条) 1 2 ... 19 20 21 22 23 ... 64 65 翻页至

仅列出标题