今天是3/8妇女节，也是周末，同时又是两会正值高潮之际。

今天打开电视机，好家伙，30多个台都是一个画面，人大常委会报告。不看也罢。

 
爱同济的101个理由
（转自同济BBS）
昨天去了游园，才发现我已经爱上了同济。我站在汹涌的人群中，看着一张张映红笑脸，轻轻问自己：为什么爱着同济？

1.爱－－吃在同济。
对这句话，很多同济人都已经不屑一顾了。我有两个解释：一是你去上海其他高校吃一下食堂，有比较才有鉴别；二是吃在同济指的是赤峰路一条街，物产丰富，品种齐全，价廉味美。

2.爱－－同舟共济。
一人有难，八方支援。还有人还记得张婷和亓培玉吧，死者长已矣，但有一种感觉，我想，永远都会留在我们的心中：我们生活在一个数以万计的大集体里，我们有所寄托，有所依靠。
3.爱－－吴启迪校长。
我同学很多都是先知道吴校长，后知道同济大学的，我也是。也许当初就因为吴校长的部分原因，我才报了同济。

4.爱－－西南一楼。西南一不是每个人都有福气住的。
西南一有同济宿舍中最好的外形和历史，还有最好的阿姨和楼道管理员，传说中的西南一是共产主义（很多服务都是免费的）。

5.爱－－同济图书馆。
我承认图书馆是很丑，但结构上绝对上是同济的一大杰作，而且，图书馆很有内涵的，读懂了你才知道。

6.爱－－（楼下的，跟上啦。我去上课了）

7.同济的足球很强，作一个爱足球的人感到很荣幸！

8 同济的操场多，体育设施齐全，适合爱各种活动的人

9 同济朴实

10 同济有鹅

11.爱——同济三好圬：“山”青“水”秀，孕育无数同济才子佳人“同舟”爱河，彼此“共济”。

12.爱——同济有tongji.net

13.爱——不要忘了tongji.net

14.爱－－北大道上，
秋桐残叶。每到秋末雨后，桐叶的纹理被西北的绣鞋印在水门汀上，一如精美的水印，真的很美。你一定看过，如果没有看一次。

15.爱－－129操场。
我外地的同学来，一定要去看那里，她说《将爱情进行到底》就是在那里拍的，很美的。我说是么，有次看人家跑步，我才发现那个剧组把景点选在同济是对的，真的还可以。

16.爱－－同济的名字。
也许中国的大学里，同济的名气排不上一二三，但是，我敢说，没有哪个学校的名字比我们好。－－风雨同舟，匡时济世！

17.爱－－同济美女。
我大一大二的时候跟很多人一样，抱怨同济的女生............大三我才发现形而上学的错误是多么的愚蠢。

18、爱——和平路，同样在秋后，浓浓的学府味道

19.爱－－同济广播台。
有时候，到黄昏日下，我站在图书馆八楼的玻璃窗后，看着脚下优美的音乐和着人流细细流淌，常常有一种顿悟的冲动。

20. 爱－－同济的老建筑

同济的老建筑, 西南西北楼, 和平楼, 理化馆, 工程馆, 测量馆...... 不是太老, 称不上华丽, 也不很有气魄. 但里里外外让人亲近, 也须是早当自己的了. 有人知道旭日楼吗? 老土了. 129礼堂东面那栋小楼叫什么名字来着, 三个字, 爱, 说忘就忘. 有空到那里去看看.

21. 爱——同济的新建筑
一幢幢拔地而起，几乎在同一时间内建设的至少有两三幢，他们的崛起象征着一个奋起直追，蒸蒸日上的同济，一个充满希望的同济。

22. 爱－－同济的老师
没有天哪有地, 没有地哪有家, 没有家哪有您, 没有您哪有我您是老师, 我是学生, 我们家的名字叫同济.同济有无数非常可爱的老师. 举一个例子吧(多为听来的, 不负责解释). 翟立林先生, 同济文革时的第一张大字报是贴给他的, 后来他引以为豪. 英日德俄, 都是在同济精通(可能受益于文革的干校劳动). 德语大字典的主编. 他可不是学语言的, 教过很多门专业基础课(材料力学等)和专业课(土木, 管理类等). 在经管学院前身管理系成立当时无人可胜任系主任时(猜想), 他是名誉系主任.
更为可爱的是前几年80大寿, 学校大大操办了一下(估计是经管学院主办, 没考证). 各类发言过后, 他作了总结, 他对当今社会一字道破. 假! (不给这种老师贴大字报, 给谁! 这种老师, 真可爱! 爱－－同济的老师!)

23.爱----同济的男生
虽然很多不起眼，不小资，但是很实在。

24.爱——同济的生活方便，家乐福和易买得两大超市就在近旁，随时可以买到价廉物美的商品；

25.爱——同济的大学生俱乐部，每到周末，是放松休息的好去处。但不爱同济的耗子和拿耗子的人。

26爱——我们有亚洲高校最大的尸库哦

27爱——同济三宝：医学院（是不是现在的那个，大家心里有数），风洞，李国豪。

28.爱－－文远楼。
文远楼号称远东第一楼。有人假设：如果一场地震使上海的楼全部倒塌，文远楼将是你唯一的避难所。另外，文远楼也是学习和娱乐的好去处。学习就不说了，娱乐吗:文远楼的机房可是不错哦……

29.愛──考试再多不及格也不会不遣返回乡。

30.爱＿南楼，北楼，相视风雨中

31.爱　同济梧桐

32.爱 同济越来越多的草坪

33.爱－－亚洲之桥。
亚洲之桥在图书馆北楼，里面都是外文原版书，书都是免费的（收取运输费用，很少的）。最新的有布什总统传记，“文都死”2000操作系统，都是英文原版，很超值的，自己看去。（很多外地人，外校的很远赶来，我却很少见同济自己人去，很怪的，大概身在福中，总是不知福为何物。）

35.爱－－同济舞厅。
很多人都是慕名而来，尽兴而去。每到周末，红男绿女，双进对出；狂歌劲舞，入夜不散，一派歌舞升平，海清河晏的盛世繁华。

36.爱——同济趣园，青草音乐，令人忘忧。

37.爱——同济“问源”，小河潺潺，小桥流水，圆木长凳，石子铺地，翠竹青青，白鹅绿水，令人忘返。

38.怀恋－－民主楼。
民主楼曾经是同济最破的楼，现在轮到和平楼了。民主楼以前是学生会，社团联合会的基地，里面活跃这同济的精英合风云人物。民主楼一年四季都有青藤环抱，很有情调，有人称之曰：“青藤小屋”。

39.爱——同济的小排汤，味道鲜美，我经常喝，特别是四食堂的小排汤，不过最近有些水平下降。

40.爱——同济大，从杨浦区跑到闸北区，还没有跑出同济的范围，有一回跑到西南角的零陵路，举头一看，还有个一个同济大学牙科医院！

41.爱－－和平楼永不熄灭的灯光。
和平楼120是同济少有的几个通宵教室之一，而且，一年自始至终都不熄灯，里面终年坐着一群苦读的学子：考研的，考G的，考托福的，也有什么都不考，只是为了学习而通宵的人。每当深夜回宿舍经过和平楼时，都被那灯火通明的氛围所感动：同济多亏了这么一群人，我们的祖国也正需要这样的一群人...............

42.爱－－同济的土木建筑等相关学科
正是他们，才有了今日中国的城市面貌！～

43.爱－－青菜加大排。
青菜－－0.50，大排－－1.40，再加上三两饭，若是还有免费汤的话，一顿就这样有荤有素有汤有水的对付着过了。而且，大排一块四学校是贴钱卖的。很多时候，吃着大排青菜，感到的是一种关怀。
或许多年后，我会怀念那青菜大排陪我走过那一段清贫的学生时代，感谢学校，感激青菜大排。

44.爱－－问源边上的白鹅
惊喜的发现在这繁华得机械的大都市中，还有它们红掌绿波的灵力，不禁生出亲亲自然的冲动。交大的鸽子同济的鹅，数量不多，质量绝对一个顶三……

44：爱，同济大学给我一个妻子！！

45. 爱同济四食堂边的那一片水杉，到了冬天的时候，校园里没什么人，那些树就直挺挺地站在那里，很有味道。

46、爱过去的超市二楼books，可能是同济唯一的人文书店
只可惜现在没落了，老板只知赚钱，光盘的生意兴起

47，爱沪西生乐B，永不熄灯的乐园！

48. 爱——同济地下室，便宜，新鲜，呵呵。老板娘好说话。

49.爱——同济后面的Joy Bar，据说很灵的，把远在二医大的mm都勾来了，不过我没去过，呵呵。

50我来，爱—同济交通方便，不知道这附近的路是不是同济道交系的人设计的，所以故意偏袒着同济一把，连环绕同济跑的车都有115，817，874等，从前门跑到后门，那么窄的一条赤峰路竟然那么多车。后面有123，前面有55，你会发现去哪里都很方便。

51.爱－－同济里的同学。
高中毕业的时候，我和我的同学含泪作别：我以为我再也不会有那么好的同学和朋友了，这一别，也不知道何时再见，再见了，我们还是不是曾经的你我－－我会不会就这样永远失去，从此孤独。
但是，在大学里，我又找到很多朋友，写字的，码字的，卖字的，还有会测字的。都很有才华，而且很仗义，肯帮忙，所以我喜欢和他们在一起。其实，只要有心，在哪里都能有朋友，在哪里都会快乐。
上网也是哦，最近认识几个帖友也蛮好的拉，比如。。。（不说了，我阿谀之嫌

52.爱——黑松岭，旧貌换新颜。

53.爱——同济晚上10点后的一二九操场，爬过围栏，跑上两圈，偶而有所思，偶而无所想，只是静静地跑着……

54.爱——同济给我的节奏，不快不慢刚刚好，就象行走时，时而脚步匆匆，时而放慢，时而驻足，美丽的风景，欣赏啊。

55.爱——同济给我的空间，除了学习还有些别的。

56.爱——同济给我的感觉，随意中有股执着，厚重中有股轻盈，如白色的瑞安楼和红砖的图书馆，如路边的老梧桐和轻风中的开满的樱花树，如所向往的生活。

57.爱——同济的同学们联合写的这个帖子

59.爱－－同济校友。
早上在宿舍里发帖子，听见外面有人说话，打开门一看，两个人自我介绍说是校友，二十年前住在我们现在的宿舍里，趁着校庆回来看看，果真是少年英雄江湖老，二十年前的少年现在已经。。。他们久久的凝视着他们曾经的旧地，寻找着岁月的痕迹。二十年后来的人可能就是我，也许我会给他们讲我今天的故事。
60、爱同济正门对面彰武路上的音像店、可点、招行、新同济酒楼、装修的同济新村以及更远的鞍山路同济大学第一附属中学、同济绿园等等，同济的影响力可见一班，在四平整个社区到处可见同济的牌子。

61。爱——同济有几大杰出的建筑，上次说了文远楼，电影院说了吗？第一次来同济的时候，有人说那是亚洲十大杰出建筑，我怎么也没看出来。后来进去看了看，才觉得十分不错，宽敞而且没有柱子和梁。
外观朴实，内在扎实——这也是同济和同济人的特点。

62。爱——同济还有一个很牛的地方：毛主席像，上次有篇帖子提到过。
很多高校都有毛主席像，但大家是否注意到同济的毛主席像跟其他学校的毛主席像有什么不同吗？比如交大，复旦。交大复旦的毛主席像手是背在后面的，而只有咱们的手是挥出去的，不仅很有气势，而且是因为这个手伸出去是很有讲究的，大概是“结构力学”的问题吧。没有科学的计算，手臂会掉下来的——毛主席的手掉下来了，这就不是结构力学问题了，而是政治问题了。所以交大复旦在这个方面就没这么牛气啦，只好吧手背在后面。这就是为什么咱们的毛主席的手是高高挥舞，而交大复旦背在后面的原因：咱们建筑很牛！呵呵，听同济校友说得，姑且算一爱吧。
后来我去看了看，凡是建筑比较好的学校，毛主席的手才敢挥出去。

63.爱沪西桃李村
最有人情味了,上次看流星雨,别的区都锁门了,要爬进去,我们可是光明正大的走进去的还有阿姨会帮我们拖地,丢垃圾,隔壁有个女生有次没叠被子,她也帮忙，太好了

64.爱------同济的人
不管是老师还是同学,都让我有一种莫名的感动,人总是自家人好

65.爱－－西南八和西南九下的地下服务一条街。
学习用的，你能想到的都有，你想不到的也有。而且有一家“文印店”很便宜，A4：打印0.30元，复印0.10元，很省的喔。

67.爱——同济沪东校区
大一时在那里度过愉快的一年，尤其喜欢毓秀楼。想当年公寓还没盖好，我住那里通宵供电，爽呆了。而且沪东校区环境不错，非常安静，适合学习生活。

68：同济大学是我初恋的地方！
虽然没有成功，但是我很珍惜这一次的经历。

69:同济有这么多可爱的同学,比方说楼上的诸位.

70.爱----我们的结构力学老师
真真正正的老师，尽职尽业尽责

71。爱-----文远楼
结构上的精妙已经不需要我多说

72：爱工程试验馆，“问源”旁，竹林边，古朴有韵味，这里有着同济NO1,
NO2的仪器设备。

73：爱学苑广场的草坪，每天络绎不绝的人群，看报的，聊天的等等等等。

74：爱同济的书报亭，各色期刊杂志，样样有。

75：爱同济的“继往”、“开来”两石柱，它们时时鞭策着我们。

76：爱同济河边的木凳子，还有那水杉.....休闲学习的好地方。

77爱：同济的秋千，公园里面都不一定找的到！

78：爱，同济周围酒吧多。

79爱：每当有新闻媒体报道同济时我心中那种热血澎湃的感觉。

80爱——同济学生的好学上进

81爱-----沪西门口的吉祥馄饨,24小时外卖服务,随叫随到,熬夜者受益无穷啊 ~~

82爱----我们的专教,凌乱不堪,但真正的家一样的感觉.

83爱——今天登上本部图书馆顶楼，鸟瞰上海夜景，美不胜收！（我恐高，看得时候脚一直在抖～～～～～～）

84爱----沪西武装部(上军事理论的地方).隐蔽之极,转了几道弯之后才发现墙角一小木牌,上曰:武装部,"箭头".像绝了鹿鼎记中的天地会.
85爱－－当年沪东宁远楼，第一年的集体宿舍生活，对那里充满了太多的美好回忆！

86爱-----同济西北4楼前的"挪威森林"

87爱 同济校园里面的那些小麻雀。跳来跳去好可爱
88－行政楼门前有一块碑，上面写着“智圆行方”，我觉得很受启发。
89－爱同济的校徽。太吸引人了！特别是印有校徽的T恤，帅呆了！
90-
爱——同济有《同济大学生》，青藤小屋很温暖，大报的人很可爱！（其他的还在寻找中...）

问题

请教一下：
我们公司是这样的情况：研发部  项目部  质量部；
项目部用研发部的产品去部署，有的项目也涉及开发，会产生分支，项目比较多，每个项目没有专门的配置管理员；
公司只有一个配置管理员，既要管理研发产品又要管理项目资料；

我想建两个，一个产品库，一个项目库。
问题1 我不知道分支是应该放在产品库里还是项目库里？
问题2 我看了论坛上好多资料，有的前辈说建三个库，开发库、受控库、产品库，我不知道是不是每个项目都要建这样三个库？还是从公司的角度说总共建这三个库？
问题3  这三个库怎么联系起来？

答复

改变一下你的抽象问题的角度，如果你把研发部若干在研版本也看作是若干个项目，项目部的在客户化的各个项目只不过基于研发部的某个特定版本上作客户化，问题就解决了。针对不论是研发部还是项目部的项目，都需要有开发库，受控库和产品库这三个逻辑上的库，物理上可能是一个库，以分支的方式存在。
开发库-开发人员check in / out不受限制，日常的工作目录绑定；
受控库-处理完某个变更/需求/Bug后，Merge到受控库中用于集成并送测；一般来说在UCM中要求在CQ中绑定一个CQ；
产品库-测试通过的版本的快照及相应的其他资料（如手册，培训材料等）放入此分支；

至于你说产品部和项目部的配置库之间的关系，其实就是项目部到产品部申请某个基线版本，到自己建的本客户化项目的项目配置库中作为研发的基础版本。如此而已。

水平决定眼界

眼界决定心胸

心胸决定态度

态度体现水平

----

所以，

务必-

谦虚，平和，倾听，认同，合作，上进。

        摘要：质量管理如何去量化要求？怎么设定一个合理的质量目标？质量目标如何被分解？质量目标如何随着项目实施过程推进而被修正？这些都是困扰项目质量管理的老大难问题。本文尝试从缺陷分布模型的角度去提供一种思考维度。
        关键词：质量管理，量化，质量目标，质量预测。

项目量化管理与量化质量目标
        CMU SEI的CMMI模型中，把一个软件企业的软件能力成熟度分成五个等级。分别为初始级，可重复级，已定义级，已管理级和优化级。各成熟度等级的特征如下：
        初始级—软件过程是无序，无章可循的，软件项目的成功依赖项目组中的关键成员的个人能力，项目的成功是偶然和不可预见的。
        可重复级—项目已经定义了最基本的项目管理过程，对项目的进度，成本和质量在一定程度上起到控制作用，对同类型的项目，一些成功的经验是可以被复用和优化到新的项目过程中去的。
        已定义级—软件项目管理过程已经上升为组织级别的标准过程规范。组织的项目过程采用或裁剪自组织标准过程。
        已管理级—软件过程表现逐步稳定，软件过程和产品质量都能有量化的衡量准则，可以量化控制和预测过程和产品质量。
        优化级—在已管理级的基础上，通过对过程革新，来不断的优化过程，从而达到持续改进。
        那么，对于达到或者将要达到已管理级的这些公司，如何利用这些过程数据来控制和预测产品质量呢？基于规模数据和缺陷数据是很多公司比较早收集的，而且相关过程也是比较早达到稳定的，我们可以先从缺陷数据开始入手，建立初步的质量目标分解和质量预测体系。

构建缺陷分布模型和项目缺陷密度性能基线
        对于达到成熟度等级四级的公司来说，基于这个成熟度等级的项目一般来说项目管理、评审、测试等子过程的过程性能比较稳定，因此也有条件生成该过程的过程性能基线。通俗的讲，我们可以把一个公司某个过程的过程性能基线看作是该公司该过程的基准值。如，测试缺陷密度性能基线为[25±2] 个/千行，那么类似的项目的缺陷表现就可以参照这个数据了。
        对于构建本模型，我们需要一个缺陷分布模型和一个缺陷密度性能基线数据。假设A公司X类项目的缺陷分布模型如下：

缺陷发现阶段	缺陷比例
1-User Requirement / System Requirement Review	3%
2-High Level Design Review	4%
3-Low Level Design Review	4%
4-Unit Test	14%
5-Code Review	15%
6-System Integration Test	51%
7-External Defects	9%

        假设A公司X类项目的缺陷密度性能基线为M1 = [25±2] 个/千行。

设定质量目标
        按照项目给定的范围，进行项目规模估算。假设估算的项目规模是Size = 20，000行，那么，根据缺陷密度性能基线数据，可以推算，该项目预计的缺陷总数为M2 = M1*Size/1000，得出M2 = [500±40] 个。然后按照缺陷分布模型的百分比，可以把缺陷发现指标分解到各个阶段中，如下表：

项目实施阶段	缺陷发现质量目标 (个)
1-User Requirement / System Requirement Review	14±1
2-High Level Design Review	19±2
3-Low Level Design Review	19±2
4-Unit Test	71±6
5-Code Review	75±6
6-System Integration Test	255±20
7-External Defects	47±4

        这样我们就得到了每个阶段缺陷发现的目标数和控制上下限，并作为质量目标固定下来了。

------------

 

罗耀秋，曾供职于中兴通讯移动事业部，目前供职于领先的离岸外包软件供应商群硕软件开发（上海）有限公司。PMI认可的PMP，6 Sigma绿带，曾经作为ATM成员参与过多次CMM/CMMI各成熟度级别的预评估和评估工作，并作为核心团队成员辅导某电信产品获得TL9000认证。7年的高成熟度企业软件研发和软件过程改进经验，熟悉6 Sigma，OPM3，CMMI，ITIL，Prince II， TL9000， ISO等管理框架、方法和模型。

• 项目管理框架需要较好的兼容性，能够通过在一定层次上的抽象去包容不同项目特征，不同商业运作模式和客户的对项目管理不同要求。
• 项目管理框架要较好的打通市场，销售，财务，研发和管理部门的壁垒，使项目的商业目标能在项目实施过程中得以有效的监控。

图2-1 GPLM框架示意图

      我们把一个全生命周期的项目模型定义为上图所示，划分为7个阶段，每个阶段均以一个里程碑点为标志。7个阶段和里程碑如下表：

 

#	阶段名称	阶段简介	里程碑名称	里程碑描述
1	Project Initial	项目启动阶段，主要是一些商务活动，如方案，合同等。	Contract Sign-off	以合同签署为结束标志，主要控制合同评审。
2	Scope Defining	客户需求调研，需求评审，需求确认以及合同重评估。	Requirement Sign-off	关注需求质量，合同重评估及本阶段的其他里程碑目标达成情况。
3	Functional Specification	系统设计及评审，测试方案编写及评审，如果必要的话，与客户签字确认方案。	Solution Sign-off	关注系统设计质量，同时监控本阶段的里程碑目标达成情况。
4	Development	详细设计，编码，单元测试设计与执行以及系统测试设计。	Code Complete	关注详细设计及编码质量，关注测试设计及单元/集成测试落实情况，同时监控本阶段的里程碑目标达成情况。
5	System Testing	系统测试执行及bug修复，用户文档编写。	Feature Complete	关注测试交付准则的落实情况，并监控本阶段的里程碑目标达成情况。
6	Release Preparation	UAT及用户培训。	General Availability	关注上线的准备工作及本阶段的其他里程碑目标达成情况。
7	Project Closing	项目收尾工作。	Project Closure	审核项目收尾并组织复盘。

 

表2-1 GPLM框架阶段和里程碑简介

      部分非全生命周期的项目，根据需要调用其中的部分阶段和里程碑作为过程定义。同时对于单个项目，如果一个比较大的变更的纳入，即时项目已经过了某些阶段和里程碑，则对于这些变更的部分，视情况决定是否再分解到上述的阶段和里程碑上进行细化控制。对于迭代开发的，上述4，5，6阶段和相应的里程碑可能在一个项目周期内会几次被重复调用。具体的控制力度及模型定义，根据具体的项目特征进行取舍，但需要经过相应的管理机构，如项目管理办公室或EPG批准。

2.2 GPLM框架实施简介

2.2.1 实施GPLM框架相应的组织结构

     为了顺利的推行GPLM框架，我们需要一定的组织机构并分配合适的职能。以下是一个比较典型的实施GPLM框架的组织结构：

   
运营管理办公室—负责公司和项目商务方面的监控与策略制定；负责项目财务目标的制定；

• SEPG组织—负责公司层面的过程规范制定；
• 项目管理办公室—负责项目里程碑目标的制定与跟踪监控；负责项目周期性的状态监控；负责对项目质量保证工作进行审核与监控；
• 质量保证组—负责项目过程和产品质量保证；
• 项目经理—负责项目目标的达成；负责项目里程碑目标的制定与实现；负责项目过程定义；

2.2.2 基于商业目标生成项目定义过程

GPLM采取一种高度抽象的方式来表述项目定义过程。如下图所示：

 
产生项目定义的过程集的步骤如下：

1．  根据项目合同情况，项目经理及上级给项目提出关于质量，进度，财务等方面的控制目标；这个目标一般需要通过公司层面的运营管理办公室的审批予以备案；

2．  项目经理根据审批后的项目目标，分解成项目各里程碑的目标；同时项目管理办公室和项目经理根据项目各里程碑目标，制定各里程碑的Milestone Checklist，用于监控里程碑目标的实现；

3．  在每个里程碑开始前，QA协助项目经理从组织标准的过程检查单集中定制本项目的过程检查单，用于控制本阶段各基本过程活动和过程产出物的质量，从而确保本阶段里程碑目标落实。过程检查单需要通过项目管理办公室的审批；

4．  在过程活动实施过程中，项目组参考过程检查单的要求，从公司庞大的过程资产库中，或客户要求的过程资产中选择过程规范，模板，指导书等。如果两者中都无合适的过程规范中，则在遵循过程检查单的要求的前提下，自行制定相应的过程规范。在此过程中，项目管理办公室和SEPG团队中的专家会提供专业的支持与指导。

      由于是基于目标出发，逐步细化推导出对各子过程和工作产品的要求，最终选择形成本项目需要遵循的过程规范集，从而保证了过程的适用性。组织上不对项目最终遵循什么样的过程规范集这个层次上做硬性要求，转而把对各子过程，过程工作产物和里程碑的要求以检查单的形式形成书面的承诺，从而保证了对GPLM框架对各类型项目的包容和有效控制。

2.2.3 基于商业目标的项目过程监控

在项目实施过程中，通过多渠道的过程监控活动确保商业目标的达成。主要有：

• 运营管理办公室和项目管理办公室定期审核各项目，各子组织（事业部）的经营目标达成情况；
•  项目经理每月向项目管理办公室提交项目状态报告，项目管理办公室每月对各项目实施状态监控，跟踪项目目标和项目过程偏差，并形成公司项目状态报告汇报给高层；
• 项目经理向项目管理办公室提交里程碑点报告，项目管理办公室在里程碑点根据里程碑检查单审核里程碑状态，并出具里程碑审核结果给管理层进行里程碑决策；
• QA根据过程检查单检查项目过程质量和项目工作产品质量，形成审核报告向项目经理的主管，项目管理办公室报告。

      通过这四个层面的过程监控机制，实施监控从过程目标，到里程碑目标，到最终保证项目的商业目标达成情况，及时实施纠偏行动。

3 结束语

      实施GPLM框架同时也对项目管理办公室，项目经理及项目QA对过程的理解能力提出了较高的要求。要求他们能够如何根据商业目标，定制出切合实际的本项目的里程碑目标，从而制定出合适的里程碑检查单和过程及工作产品检查单。

      实施GPLM框架也对组织机构方面提出了一些要求，如何能够打通从研发、市场到项目管理、研发的通道，从而把项目商业目标和项目过程管理结合起来，使我们在实施GPLM框架前需要解决的问题。

      限于篇幅，本文并未对这些问题进行更细致的阐述。

 

－－－－－－－－－－－－－－

罗耀秋，曾供职于中兴通讯移动事业部，目前供职于领先的离岸外包软件供应商群硕软件开发（上海）有限公司。PMI认可的PMP，6 Sigma绿带，曾经作为ATM成员参与过多次CMM/CMMI各成熟度级别的预评估和评估工作，并作为核心团队成员辅导某电信产品获得TL9000认证。7年的高成熟度企业软件研发和软件过程改进经验，熟悉6 Sigma，OPM3，CMMI，ITIL，Prince II， TL9000， ISO等管理框架、方法和模型。

12月12日-14日在苏州召开了SEI的SEPG大会。这是第二届SEPG大会在中国召开。软件质量管理之父Watts Humphrey以及多达10来位主任评估师的参与，使的大会学术气氛比较浓厚。

另外，也有约30位企业过程改进/项目管理方面的代表上台与与会者分享了他们企业的一些做法。其中不乏务实的精神，大家似乎也意识到合用就是最好，而非高成熟度就能解决问题。

唯一遗憾的是，没有组织一些行业方面的专业讨论。如外包企业过程改进专场沙龙，度量专场等。相对来说，企业代表们私下的交流在会场外显的异常的热烈。我个人就认识了众多外包行业的过程改进和项目管理方面的代表。今天下午我也将就《质量管理层次框架》与与会者做一点分享。

后续我会就参会的一些具体细节和自己的体会陆续的发布一些小文章在blog里面与各位分享。

本次应广州赛宝朋友的邀请，参加了第六届全国系统及过程改进年会，并就商业目标驱动的过程改进与同行进行了分享。下面我就简要的记录一下本次参会的一些感触。

首先，让我先感谢赛宝朋友的热情招待和组织工作。虽然只有短短的2天，但却和很多赛宝的工作人员成为了朋友。建议以后大家有产品认证，体系认证，CMMI评估及咨询和软件评测的需求，可以把赛宝认证中心做为一个很重要的考虑伙伴。

下面转入正题：

1，本次会议正好和广东主办的一个信息产业周开幕放在一起，所以各地信息办的领导来了不少，国家的一些司局的领导和专家也来了。由于是演讲人之一，也有幸近距离的和一些专家进行了沟通交流。这些专家们都非常谦逊，但囿于时间的安排，分享的主题多是一些政策性，科普性的内容。但他们严谨，谦逊的态度，却是值得我们年轻人所学习的。

2，本次广州分会场很大一块还是在benchmark方面。Micheal和Peter这两个常客又一次进行一些有关度量及相关性方面的报告。其中Micheal的SPR研究所的那个软件，由于回上海是同机，所以他在飞机上还专门给我做了一下演示，我们也进行了一些深入的讨论。感觉对于单个项目经理的估算和项目管理还是有一定的参考作用。但对于企业级项目管理方面，我觉得还有待进一步的整合考虑。Micheal还专门作了一个小型的Workshop，半天时间，但由于大部分人纠缠在功能点方法的讨论上，反而关于度量，过程性能等方面的讲解和讨论的深入与进度受到影响了。看来中国搞过程的人的老毛病：喜欢玩新概念，却对过程本身的有效性方面不投入足够的关注在这个培训中暴露无遗。

3，本次还有很大一部分就是对各类培训，认证方面的推介和普及性讲解。有ITIL，美国ASQ的认证，ISTQB的认证，中国信产部的评估师认证，微软认证。郑人杰教授在这个section开始，做了一些软件人才方面的宏观分析：以06年数据，现在的软件人才的年产量接近150万，量是上去了，但质方面却差的远。软件外包行业平均从业年龄才3.5年。看来群硕现在给新员工1-3个月的全职培训，是在补大学里面的这堂课了。又是一年新兵到，愿所有毕业生找工作遂愿，也劝在校的学弟学妹们抓紧时间多学点东西，而不要在找工作时候抓耳挠腮。

4，本次年会广州会场最与过程改进切题的一个会场是8日下午的第四会场，主题是“基于商业目标的过程改进—最佳实践”。演讲人员有：

时　间	内　容	单位、职务	演讲人
13:30-14:10	软件外包过程改进实践---商业目标驱动的四维项目管理框架	群硕软件开发（上海）有限公司PMO	罗耀秋
14:10-14:40	面向业务的软件测试过程和策略	赛宝软件评测中心副主任	刘杰
14:40-15:20	建立自优化流程框架，推动全员过程改进	华为技术有限公司	周代兵
15:20-15:50	如何建立符合商业目标的度量体系	赛宝认证中心CMMI高级咨询师	刘小茵
15:50-16:20	利用RUP提升甲方对于外包软件项目的管理能力	IBM Rational资深技术顾问	朱育雄
16:20-17:00	CMMI vs.敏捷开发	广州华微明天软件技术有限公司常务副总经理	张传波

从会场大家的互动情况来看，过程改进中老大难问题：如何让过程改进真正助力公司发展，从而获得上下支持成为大家关注的焦点。大家反馈的问题都很具体和实际，也导致各个主题的时间有所延迟。我开了个“坏”的头，第一个研究就差不多多用了接近半个小时去答复热心听众提出的问题。由于时间关系，我演讲完后，只听到了刘小茵老师演讲的关于GQIM的这部分就不得不赶飞机回上海了。

5，9日的上海会场由于工作关系没办法去了。不过team另外两个弟兄，还有一个SQA经理去了。

附件是我的讲稿，就当抛砖引玉，与各位分享。PPT内容较简单，大家对内容有什么疑义，可以按照PPT的联系方式和我联系。谢谢。

提高测试效率：
1，改进测试方法：引入自动化测试工具；
2，多做一些前端的测试：如各类工作产品的评审和单元测试，组件测试
3，改进测试设计：可以采取各类测试设计技术提高测试设计对测试对象的最小集覆盖；
4，在质量要求尽量满足的情况下，最小化测试内容。如对部分 比较有把握的模块，不实施全覆盖；
5，加强测试管理：测试任务有更强的计划性，尽量能细化到测试的功能和测试的case这个级别去监控进度；
6，对于集成测试，还要保证开发部送测版本的质量。避免测试终止或者多轮测试版本才能放行的情况。我们这边会用版本送测次数，版本测试失败次数去衡量开发部门送测版本的质量

本期给馨园主人留言的问题答复：
*****************有关版本发布问题*****************
我是深圳的，我有以下问题想请教你，能帮我解答一下吗？谢谢！
产品安装后显示的版本是否一定要与测试内部版本一致？
因为有时候为了方便发布，程序员吧要发布的版本如v2.0写在界面上（而实际上测试的版本可能是v1.11）。我不知道这样做行不行。 但这样做比较方便，因为程序员的程序是在服务器上打包的，如果测试通过就可以直接发布了，不要再重新打包再测了。

还有公司规范了版本格式，比如v1.1.20061112，那这个格式只是软件程序需要遵守还是我们的一些文档也要遵守呢？这个我很不明白。
－－－－－－－－－－－－－－－－－－－－－－－－－
答复：
1，版本升级不一定文档就需要升级。比如：一个coding的错误导致重新发布，则此前的设计，需求文档显然不需要更新。但是一个错误如果从设计就开始错了，则需要变更相应的文档。我们可以做好缺陷引入阶段的分析和缺陷波及分析，从而修复由该缺陷带来的从文档到代码的系列工作产品的更新。
2，外部发布的产品标识和内部的版本肯定是可以分开的。只是需要在配置管理和产品管理层面维护这样一个对应关系即可。试想一个手机产品，可以有五花八门的市面上的称呼，但在研发内部，硬件各模块都有自己的版本号，软件各功能模块也有自己的版本号，符合系统集成时候又有一个总的版本号。有几套编号是为了各自分系统内部的管理方便。对于管理来说，只要维系这种对应关系并能被相关干系人知晓和理解即可。

有一段时间没有更新自己的个人空间了。一是断网半年，在公司基本不怎么上外网；二是确实懒了，每天疲于应付工作，基本没有什么心情去想一些东西，去总结一些东西，去疑惑一些东西，进而去学习一些东西。

最近有一点点想法：有关过程管理工作的环境论因素。

我们经常抱怨一个公司的过程管理环境，从表层看，是人员配合，领导重视，生存压力等因素。但从深层次发掘，我们就会发现这其实是质量成熟度要求（质量管理要求）层面的环境。

某些做应用软件项目的公司，可能干着一锤子的买卖，它用这种一锤子买卖的方式比做百年老店更能得到现实利益的，那么它的质量管理要求是一种情况。

某些业务导向型而非技术导向型的公司，软件团队管理复杂度也不算大，其软件对健壮性等质量属性要求又一般，比如各类mis，那么它对质量管理的要求又是一种情况。

还有一种是系统的复杂性较高，技术与业务并重，对质量有非常严格的要求，如军工和电信，以及调度等，这种项目和公司对质量管理又是另外一个要求。

也许我们思索一下在这三种质量要求条件下，我们最能给企业带来现实的质量和经营业绩改善的点是什么，着眼于这个小点，兼顾一些战略点，那么才能在某些特定的环境因素下使自己的质量管理工作得到认同，认可，从而产生实质效果。这样的思路，也有利于我们言必CMMI之教条。

－－－－－－－－－－－－－－

很久很久以前有一位很牛的很精通医术的男人，为了得到王位、攀附权势，将自己的
老婆脸上刻字，全家发配到很远很远的地方，然后娶了另外一位大王的女儿。

这个男人登上皇位了，带着前妻给自己生的儿子，娶了年轻漂亮的王后幸福的生活着
~~~~没完呢

大王对前妻有点愧疚哈，所以每天对着那幅画像，深情的很~新王后吃醋了，就跟大王
的大儿子乐和，生了一个小孩子，记在大王名下，不知道该叫爷爷还是爸爸

花开俩朵，各表一枝。这位大王的前妻流放过程遇到一位太医，感恩阿，以身相
许，生了一个咪咪很大的女儿，后来这个女孩子入宫跟她爸爸一起做王室的医生，后
来这个咪咪很大的女孩子跟大王的大儿子乐和……也就是她同母异父的兄长

大王也知道这些乱七八糟的事情，然后每天给老婆喝毒药，想让她慢慢疯掉，眼不见
为净。这女的咪咪不大但是也不傻啊。每天绣菊花，准备造反！

大王的前妻为王后做事，为了保护自己的儿子，为了杀前夫报仇雪恨，看来女人要是
报仇还真是狠毒呢

大王的新旧老婆密谋杀大王，大王偶然在宫里抓到了前妻，封了那位太医的高官，然
后派了很多很多打扮像电焊工的高手去灭门。大儿子知道了重阳节要造反之后通过苦
肉计告诉了大王

重阳节开始造反了！周杰伦演的二儿子打扮得像黄金圣斗士，带了一两万号人开始造
反，没有打过皇帝的一两万白银圣斗士，《圣斗士星矢》里面好像也是青铜的牛比一
些，永远也打不死，为熟吗？没想明白阿

外面打，里面打，那个搞不清是孙子还是儿子的三小子长得还真像大王子也，他刺死
了自己的爸爸然后被大王杀死，鞭尸，王后冷眼看，噢也~~真乱

外面造反打输了，黄金圣斗士就剩了一个二儿子还活着，被抓到里面，里面也打输
了，大王还是最牛比的，然后大王请母子吃饭，自己孩子就别嫌弃了，造饭也不车
裂，只是让他伺候自己亲妈喝毒药，周杰伦不忍心啊，于是自刎了，埃~

然后大王就一个人一个人吃饭然后就全剧终了

看完了之后理解了一句名言：时间就像乳沟，要挤总会有的，并强烈建议改名为《后
宫淫乱史》



不过不管怎么样，每一个镜头都很精美，视觉震撼的很啊

"投身IT英勇无畏,
工作行业看似高贵,
其实生活极其琐碎,

为了生计吃苦受累,
鞍前马后终日疲惫,
客人投诉照死赔罪,
点头哈腰就差下跪,

日不能息夜不能寐,
老板一叫立即到位,
一年到头加班受罪,
劳动法规统统作废,

身心交瘁暗自流泪,
屁大点事反复开会,
逢年过节家人难会,
分分秒秒不敢离位,
迎接审核让人崩溃,

接待应酬经常喝醉,
不伤感情只好伤胃,
工资不高自己交税,
走亲访友还得破费,

抛家舍业愧对长辈,
身在其中方知其味,
不敢奢望社会地位,
全靠傻傻自我陶醉"

软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用；某某某软件功能全、结构合理、层次分明、语言流畅。这些模模糊糊的语言实在不能算作是软件质量评价，特别不能算作是软件质量科学的定量的评价。但是，软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。对于什么是产品质量，可以从以下几个观点来看：
* 透明性观点:质量是产品一种可以认识但不可定义的性质;
* 使用者观点:质量是产品满足使用目的之程度;
* 制造者观点:质量是产品性能和规格要求的符合度;
* 产品观点:质量是联结产品固有性能的纽带;
* 基于价值观点:质量依赖于顾客愿意付给产品报酬的数量。
按照ISO/IEC9126-1991(GB/T16260-1996)"信息技术软件产品评价质量特性及其使用指南"国际标准，对软件质量也有定义，软件质量 (software quality)是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。
其含义有四:
其一，能满足给定需要的特性之全体;
其二，具有所期望的各种属性的组合的程度;
其三，顾客或用户觉得能满足其综合期望的程度;
其四，软件的组合特性，它确定软件在使用中将满足顾客预期要求的程度。
简言之，软件质量是软件一些特性的组合，它仅依赖软件本身。
对于软件质量有三种不同的视面。用户主要感兴趣的是如何使用软件、软件性能和使用软件的效果。所以他们关心的是：
(1)是否具有所需要的功能;
(2)可靠程度如何;
(3)效率如何;
(4)使用是否方便;
(5)环境开放的程度如何(即对环境、平台的限制，与其他软件连接的限制)。
而开发者负责生产出满足质量要求的软件，所以他们对中间产品的质量以及最终产品。对于管理者来说，也许要注重总的质量，而不是某一特性。为此，根据商务要求对各个特性 赋予权值，他还须从质量管理入手，运用有限的资源和时间使软件质量达到优化目的。我们进一步解释软件质量特性，一个软件质量特性可破细化成多个子特性。按照ISO/IEC 9126一1991的规定软件质量可用6个特性来评价:
1.功能性(functionality)是与一组功能及其指定的性质有关的一组属性
这里的功能是指满足明确或隐含的要求的那些功能。
注:
·这组属性以软件为满足需求做些什么来描述，而其他属性则以何时做和如何做来描述。
·质量的定义注解适用于本特性中的明确或隐含的需求。
2.可靠性(reliability)是与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。
注:软件不会老化。可靠性的种种局限是由于需求、设计和实现中的错误所致，由这些错误引起的故障取决于软件产品使用方式和程序任选项的选用方法，而不取决于时间的流逝。
3．易用性(usability)是与一组规定或潜在用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性

最近正在准备抽象两个模型：

1、抽象出中小软件项目的标准质量管理框架模型；

2、抽象出中小软件企业质量保证工作模型；

题目有点大。欲思欲难得其圆满，几成不可能完成的任务了。

困难啊！也许还是行业的沉淀不够，还有很多东西想不清楚，后续会逐步贴出来，与同侪交流。

1单元的定义

单元是指完成单一（较小）功能的相关数据（数据结构）及对应算法函数集的集合。

功能块的划分并没有标准可依，只要代码行数还比较多，就都可以把一个功能块再拆分为若干子功能块。一般代码量在200～2000行的，可以认为是单元；超过2000行的可以认为是模块，需要进行功能块拆分；小于200行的，应该进行功能块聚合。

单元应该只含有单一逻辑。通过收发消息进行耦合的代码，由于同时含有业务逻辑（业务流程）和并发逻辑（操作系统层面的收发消息、信号量、定时器等），一般都划为模块。将2种逻辑解耦后，只含业务逻辑的代码才考虑是否可以简单到成为单元

SDL进程状态机一般都逻辑略嫌复杂，应该划为模块，它的每个进程页才考虑是否可以简单到成为单元。

一个大功能块拆分为多个子功能块时，必然还有大量代码不能划入任何一个子功能块，这些代码则是集成测试时所要关注的内容。单元测试阶段并不要求所有代码都经测试覆盖。

没有返回值、回传参数，也不向外发送消息的函数不可能独立构成单元。

2单元测试的重点

单元测试时关注的核心是数据而不是算法函数。因为功能的完成总是以数据发生变化来表现的。

3单元测试的目的

l         单元测试能发现很多设计、编码中的错误。但是，要发现几乎所有错误，它的工作量将是非常大的。由于单元测试是由开发人员完成的，这样做将会严重影响开发进度。所以，“发现几乎所有错误”的责任在软件工程里一直都是交由独立的测试部门完成的。所以，单元测试不该对黑白盒覆盖率提太高的指标，一般都是用例制。

l         单元测试用来证明代码满足“客户需求”。单元测试的用例应该模拟客户使用这些代码的方式。当单元测试通过的时候，我们就能知道客户的需求被满足了；当我们不知道如何写单元测试代码时，就意味着客户也将不知道如何使用这些单元代码。

l         单元测试用来证明bug已经被修复。当发现bug时，应该先拟制一个新的单元测试用例，它能确保触发bug，修改bug后，再跑这个测试用例，当成功通过过，我们就可以认为bug确实被修复了。

l         单元测试能确保后来对代码的修改没有破坏已有功能。无论修改bug还是追增功能，都很容易导致已有功能被破坏。如果能用自动测试机对已有测试用例自动跑一遍，就可以确保已有功能未遭破坏。

4单元测试的投入

            代码走查、单元测试、模块测试……都可以提高软件质量。但是，软件开发是一个经济学范畴的事情，应该合理安排所有这些步骤的投入。我认为对核心代码走查，对重要代码单元测试，用例制而不要太看重各覆盖率指标。

5单元测试的平台

            单元应该与平台、支撑尽量解耦，在调试方便的windows平台进行。

6单元测试的设计

            介绍单元测试的书有不少，此处推荐《Design by Contract原则与实践》（Richard Mitchell与Jim Mckim）一书。

            于此节选其中一个实例供大家参考。虽然是Eiffel语言写的，但绝对不会影响理解其思想。

7 可测试性的提高

            单元测试的可测试性，无法在代码编码完成后再进行提高，是要在设计阶段就要预先考虑的。也就是说，可测试性是设计出来的。

            具体方法，请参看《测试驱动开发》（Kent Beck）。一书之言，恕我无法数言以概。

CMMI v1.2模型变更:模型变更概述

 

“CMMI v1.2模型变更”系列旨在解析CMMI v1.2模型的主要变更.CMMI v1.2相对于v1.1主要有模型架构变更、模型细节变更、术语变更和过程域变更等。将分成四部分来介绍：

l           模型变更概述

l           细节变更

l           术语变更

l           过程域（PA）变更

 

1、 模型变更概述

模型变更主要有下列目的：

l           减小模型的复杂度和规模

l            扩展模型的覆盖面

 

减小模型的复杂度和规模

为了减小模型的复杂度和规模，进行了如下变更：

l           删除了高级实践（advanced practice）和公共特性（common feature）；

l           删除针对外包（SS）领域的附加信息（addition）

l           集成供方管理(ISM)被集成到供方协定管理(SAM

l           整理和简化了IPPD相关资料

l           在术语表中增加、修改和整理了相关术语定义（例如，双向跟踪(Bidirectional Tracibility)，子过程（Subprocess））

l           采用单一文档方法（例如，模型的阶段式和连续式两种表示法被发布成一个文档）

 

扩展模型的覆盖面

为了扩展模型的覆盖面，进行了如下变更:

l           增加了针对硬件工程(Hardware)的扩充（Amplification）

l           增加了两个针对工作环境的特定实践(SPs),分别在组织过程定义(OPD)过程域和集成项目管理(IPM)过程域

l           更新了表述服务开发和外包的注解和样例

l           为反映新的CMMI架构（Architecture）,模型的名称被更新为“面向开发的CMMI模型(CMMI-DEV)”

 

其它重大的模型变更

其它重大的模型变更包括：

l           改进了概要部分（Overview Section）（第一部分（Part One））的清晰度

l           增加和澄清如果应用通用实践(GPs)方面的信息

l           把通用目标和实践移到文档的第二部分

l           解释过程域如何支持通用实践的实施

l           增加了对通用实践GP 3.2的详述

l              限制能被认定为不适用（Not Applicable）的过程域仅有供方协定管理SAM

l           在组织过程聚焦OPF和集成项目管理IPM过程域中增加了对项目启动(Project Startup)活动的重视

 

SCAMPI A类评估方法v1.2变更的主要方面：

1.     减少评估方法的复杂度和模糊性

2.        在需要的地方提供附加指导

3.      强化评估规划和实施

4.        强化了对评估的报告

5.        定义评估的有效期限

6.        强化对主任评估师的要求

 

减少复杂度

删除了对评估工具（例如：调查表）的要求

目前仅需要两种类型的客观证据：

l           文档

l           访谈

 

下列章节在方法定义文档（MDD）中被修订：

l           交换2.2节“验证和确认客观证据”和2.3节“文档化客观证据”的顺序，这样任务的顺序能够放映评估过程的自然顺序、

l          为了更好地描述每个过程，把“验证客观证据”和“确认初步的发现(findings)”分开改变了术语“实例（Instantiation）” 的使用：

l          实例（Instantiation）目前被定义成：模型相关实践在一个组织单元内的实施

l          实例（Instantiation）针对项目和组织级实体的应用被“项目(Project)”或“支持团队Support Group)”替代

 

减少模糊性

澄清评定“不予评级（NotRated）”的概念

l           模型范围之外的过程域(PAs)被定为：范围之外（Out of Scope）。例如，对于一个成熟度３级的评估，成熟度４级和五级的过程域被定为“范围之外（Out of Scope）”

l          对于没有充足数据评定的过程域，评级为：不予评级（Not Rated）

l          在模型范围内但在组织范围外的过程域(PAs)被定为：不适用(Not Applicable)。仅有一个过程域SAM能被定为不适用(Not Applicable)（这由评估团队决定）。

 

实践特征表被修订：

l           澄清了虚拟访谈和实况访谈的使用

l          把“面对面访谈（face-to-face interviews）”改变为“口头访谈（oral interviews）”

 

附加指导：

扩大了预评审（readiness reviews）指导涵盖的范围，包括团队和后勤准备

对使用虚拟方法提供附加指导（例如，对访谈和简报等）

为可选实践提供附加指导（例如,附录C：可选实践识别和特征指导）

 

强化评估规划和评估实施

组织单元取样（sampling）被修订为：（详细参见：方法定义文档MDD）

l           强化组织取样的要素和限制（例如，识别出最小数量的聚焦项目）

l           增加报告取样决策的标准

 

目前实施评估阶段必须在90天内完成

目前评估团队成员必须签署最终评估发现（final findings）。

 

强化了评估报告

目前评估公告陈述(ADS)需要以下信息：

l           组织取样标准和决策（例如，包含的项目，排除的项目，在组织中所占的比例）

l          成熟度/能力4级和5级评估结果的基于：

可管理的子流程

子流程到质量和过程执行目标的映射

l           主任评估师（Lead Appraiser）和主办人（sponsor）联名签署

主任评估师确认评估范围能代表整个组织单元

主办人认可评估公告陈述（ADS），同时准许SEI在认为有必要进行审计。

 

定义评估的有效期限

l          1.2版本的评估结果自评估公告陈述(ADS)签署之日起有效期最长为3年

l          1.1版本的评估结果将到2007年8月或评审后3年（取较迟的期限）失效

 

强化对主任评估师的要求

主任评估师在主持v1.2版本的SCAMPI评估之前，须满足下列要求：

l           目前的候选或授权的主任评估师以及团队领导必须完成CMMI v1.2升级培训

l          候选或授权的主任评估师必须参加SCAMPI面对面培训

l          准备主持SCAMPI v1.2的4级或5级评估的评估师必须经过认证。认证要求如下：

        在4级和5级领域的教育、培训和经验

完成口头测验

  总结

  根据收到的变革请求，SCAMPI A评估方法修订的主要目标：

l           减少复杂度和模糊性

l          在需要的地方提供附加指导

l          强化评估规划和实施

l          强化评估报告

l          定义评估有效期限

l          强化对主任评估师的要求

SCAMPI A类评估方法的这些变革使得评估更精确、更可靠、更高效。