| 修订历史 | ||
|---|---|---|
| 修订 0.2 | 2003/04/29 | jiangxin |
| 没有实践,何谈理论 | ||
| 修订 0.1 | 2003/03/24 | jiangxin |
| 理论篇 | ||
摘要
CMM(Capability Maturity Module for Software, 软件过程能力成熟度模型),是对于软件组织在定义、实现、度量、控制和改善其软件过程中各个发展阶段的描述。CMMI 则是CMMs 概念的整合和延续。
CMM/CMMI 不是教条,亦没有指定具体的实施方案,需要灵活运用;CMM/CMMI 的应用决不是以拿到认证证书为终极目标。应该拿 CMM/CMMI 当做镜子对照自己,作为尺子衡量自己,找出差距,采取措施切切实实提高软件组织的过程能力和软件过程的成熟度,这才是CMM/CMMI 应用的真正意义之所在。
Johnson, $Revision: 1.31 $, $Date: 2003/04/29 11:51:11 $
目录
下面的例子是否似曾相识?
公司A,发布产品 XXX 的预发布版 2.0.60 实现了立项时的所有预定义需求;
发布前,客户A,提出补充需求1,下达紧急开发任务,发布产品 2.0.61;
发布前,客户B,提出补充需求2,下达紧急开发任务,发布产品 2.0.62;
发布前,客户C,提出补充需求3,下达紧急开发任务,发布产品 2.0.63;
...
发布前,客户A,再次提出需求1的补充修改意见,发布产品2.0.90;
...
其中客户C的补充功能非常重要...其它补充功能个性化非常强,可有可无...
...
继2.0.60之后隆重推出更新的版本 2.0.100。
但是,问题突然暴露...
为客户B 补充的功能2,由于没有时间严格测试,引入一个大的 BUG,该BUG,将影响2.0.62之后所有版本:
客户A的更新版本 2.0.90,继2.0.61之后,由于加入了对其毫无意义的客户B的需求2,导致软件不可用,客户满意度下降;
最终发布版2.0.100也由于需求泛滥导致的测试力度下降,引入重大BUG,使公司市场行为无限延期...
为什么这样?该怎么办?
需要加强需求管理;
需求失控,组织将处于反应式(reaction-driven),必然导致开发处于被动状态,项目组成为救火队。
一个还可以的变更控制流程:

变更控制流程1
这是一个可行的变更控制,但存在着几个问题。
上述变更控制,没有体现版本控制系统的介入和分支的管理,也没有切实可行的监督作为保障;
代码需要建立基线,并建立分支管理:
客户A的需求1,需要进行代码分支,当客户A提出补充需求后,在该分支开发;
客户C的需求经评定,需要补充到最新发布版本中,于是继续在主线开发,测试完成后,将代码改动Merge到其它分支中...
客户B的需求2,个性化强,也要建立新的开发分支,完成该功能后,不必将代码改动转移到其它分支;
同时作为 SCM 的一个要点,要保证需求文档和代码的一致性、完整性,需求文档亦要建立分支。
这是修改后的变更控制流程,在人力不足的情况下,开发人员、测试人员都参与到过程的控制中来。

补充了版本控制和监督机制的变更控制流程
“他的程序怎么一点注释都没有?”每个人写的代码风格迥异,水平参差不齐,BUG多,代码质量难以控制;
解决之道:建立编程规范、QA组织的代码审核...
“我的机器染病毒了,一天的代码白写了,呜呜...”
解决之道:开发阶段就要开始版本控制,而不是到了非管不可的时候...
“怎么没看见你的代码?欧,我把代码check到别的分支了”;
解决之道:基线和分支管理、沟通管理...
“T: 我测试的这个版本有什么功能? D:包含所有的功能,但会可能相互打架...”
解决之道:需求管理...
办公室内大喊大叫:“楼上的,我要 check 代码了”。表面上的热火朝天,掩盖不了背后项目管理混乱,并干扰他人;
解决之道:沟通管理,注意使用email等沟通手段...
代码相互覆盖;“太对不起了,是我干的,但我不知道为什么会这样?”;
解决之道:版本控制,培训...
“如果xxx走了,这一摊儿,就没人懂了”。人员的流动,可能会导致工作难以继续;
解决之道:人事管理、文档管理、知识管理...
“xxx不能休假,他一休假,来了任务如何办?”,“xxx每天都在干什么?”
解决之道:轮岗、强制休假...
“编译失败了,哪天的代码出现的问题呢?”
解决之道:持续集成
“怎么项目没有个尽头,好像永远不能完工。”
解决之道:里程碑管理,适时的里程碑庆祝一下。
你是不是有更多的体会?
2003年,本是春暖花开的季节的北京,人们却不得不面对“非典”可怕的威胁。人们苦苦等待着治愈“非典”的特效药,期待着瘟疫早日过去。我和周围的所有人都确信,对付“非典”的“银弹”马上就会出现。
但是在软件开发行业的存在已久的软件危机这个可怕的瘟疫,在今天仍然在大大小小的软件公司中蔓延、肆虐,看不到一丝治愈的希望。
软件开发行业的危机,就是管理危机。软件产业不同于其它产业的最重要一点是,它的产品是智力产品,它的生产过程复杂,存在更多的不确定因素,因而难于管理。软件产品生产过程的复杂性导致管理的复杂。
在软件企业中实施 CMM/CMMI,通过在整个软件过程中的关键处建立检查点,使整个项目对于高层管理者不再成为一个黑盒。管理者的注意力集中到几个关键点 KPA/PA,既可统领全局又能事半功倍。
但CMM并没有,也不可能去硬性规定具体的工具和实施方案。很多企业可能正在有意识或者无意识的实践着CMM,但他们的具体的实施方法,一定是千差万别。
如何定制适合自己企业的CMM?什么样的管理才是适合软件开发的管理?目前的我,无法回答这个问题。我期待着不断的总结实践自己和别人的经验,最终能回答。本文的前半部分,是个人的管理经验、管理工具的积累,后面的部分是总结当今最新潮的管理理论。我也期待着什么时候能将这前后两个部分融为一体。
管理的最大问题源自沟通。我尝试过用新闻组、邮件列表等构建出简易的知识管理和沟通系统。
News vs. Mail
新闻组将文章统一管理,并保留历史文章。新来的员工可以借助新闻组了解公司制度、开发规范等等。而新员工怎么看以前的邮件呢?
排除强买强卖之嫌
每天我发送的和工作有关的邮件不下二三十封,在发送有的群发邮件时,难免有内疚之感,但是在新闻组里发贴则没有这些顾虑。
使用邮件列表实现新闻组内容的“推”
新闻组本身并不能主动把内容“推”到用户端,一般是需要用户通过客户端软件来“拉”。在特定的情况下,如员工出差、员工参与新闻组积极性不高,可以通过新闻组和邮件列表的连动,实现新闻组内容通过邮件列表的“推”到用户端。
对于这种“推”方式,我也不会感到强买强卖的尴尬,因为用户可以自行退订相应的邮件列表。
由大家共同维护的,而非个人,保障了内容的时效性。
“谁又占用了我的IP?”“这个MAC怎么乱发包?”以前都是有系统管理员逐一去统计,看看还有什么IP是可用的,但总是赶不上变化,Newsgroup 是一个好的信息发布平台。
参见:《InterNet News Howto》...
邮件列表可以自行订阅和退订,排除强买强卖之嫌;
邮件列表可以实现“推”的功能,开发人员身处异地,仍然可以进行顺畅的沟通;
和其它系统的无缝连接: 与 CVS 无缝挂接。
代码 commit/tag 的动作,将给相应的邮件列表发送邮件。
与“每晚编译系统”挂接。
编译成功或者失败的消息发送邮件;
与“新闻组”挂接。
将帖子“推”到用户端,对付那些“消极分子”。
参见:《Maillist Howto》。
CVS, SourceSafe or Starteam ?
Starteam 和 SourceSafe 是适合小项目的版本控制系统。对于复杂的项目,他们将成为管理员的恶梦!
CVS 是开放源码的一个奇迹,亦是开放源码得以延续和发展的推动者,是版本控制的经典。使用 CVS,受限的不是版本控制工具本身,而是你的想像力。
![]() |
|
参见:《软件配置管理 HOWTO》。 |
参见:《每晚构建(Nightly Build)》...
开发人员都希望自己的产品技术领先,好用,没有缺陷(BUG)。但一个能称为产品的软件项目,没有出现过 BUG 是不可以想像的,如果一个项目能够经过较充分的测试,也许可以将绝大多数 BUG 限制在软件发布前,在内部发现并解决,但用户的环境千差万别,总有挂万漏一。即便一时没有发现缺陷,但是需求变更总是有的,客户可能发现软件中有的功能不适用,于是便提出新的需求。这些软件缺陷、需求变更应被看做是软件不断成熟、发展的动力。软件开发中需要对这些缺陷报告、需求变更进行有效的跟踪和控制,这就是我们在这里要讨论的主题:缺陷跟踪。
缺陷跟踪,或称为:Bug Tracking, Defect Tracking,是软件开发中重要的辅助软件之一,跟踪记录软件的缺陷、需求变更等,作为开发人员与测试人员、客户的沟通的桥梁,保障软件开发流程更加协调。让我们看一个典型的例子:
测试人员、客户将软件的缺陷或称BUG,通过缺陷跟踪软件提交给开发人员;开发人员根据测试人员、客户提交的 BUG 的现象、描述、重现条件等数据对该缺陷进行分析,修正完成后,除了将修正的代码提交,编译成产品,还要修改缺陷跟踪软件中记录的对应的缺陷的状态,将其状态改为“已经修正”;现在球又传到了测试人员手中,测试人员对新编译的产品进行测试,看是否真的已经修正了这个缺陷,如果没有完成修正,重新将缺陷的状态改为“尚未修正”;如果经过测试发现已经修正,则将缺陷的状态改正为“关闭”。
从上面的例子中,我们可以看出,缺陷有自己的生存周期。 一般缺陷跟踪软件把缺陷的生存周期的各个阶段用“状态”来描述,例如:"new" 代表新提交的 bug,"open" 代表已经分配了的 bug,"working" 代表已经进入修正阶段,"fixed" 代表已经修正,"verify fix" 代表修正已经经过测试,"closed" 代表 bug 修正完成,进入关闭状态。
除了这些状态之外,还有一些状态,如:"duplicate" 代表重复提交的 bug;"can not reproduce" 代表不能重现的 bug;"deferred" 代表修改被延迟到下一个版本;"as designed" 代表不是缺陷,而是正常的现象。
缺陷跟踪软件应具有通知功能。Bug 的变更应该能够通过邮件通知相关的负责人。
缺陷跟踪软件应具有查询功能。例如:查询那些是属于本人负责的缺陷;查询仍处于 open 状态的 bug;
缺陷跟踪软件应具有统计功能,能够统计一段时期每个人发现的 BUG 数量,BUG 的平均修正时间,一个产品周期发现的 BUG 总数等等。这些统计数字对于软件测量具有重要意义。
缺陷跟踪的软件非常之多,Rational 的 ClearQuest,Starbase 的 Starteam (已被 Borland 收购),等是非常知名的商业软件,当然其价格也不菲。开放源码中也有许多非常好的缺陷跟踪软件,其中大名鼎鼎的是 GNATS 和 BUGZILLA,在下面的章节中重点介绍。
详细内容参见:《缺陷跟踪 Howto》...
为保障文档和代码的一致性,文档亦需要通过版本控制管理。但是对于 World 文档这样的二进制文档,几乎所有的版本控制系统都只能对其进行最简单的备份式的版本控制,而不能进行增量式的版本控制和版本之间的差异比较。对于一个10M大小的文档,如果向版本控制服务器提交了20次,则服务器端的空间占用约为 200M。因此如果使用版本控制系统管理文档,不能频繁 Checkin,只用来保存里程碑式的文档,而且不能进行团队的协作。
DocBook 格式的文档是文本格式的文档,这种文档最适合于使用版本控制服务器,如本文档就是在版本控制服务器下的DocBook格式的文档。但问题是,学习使用 DocBook 需要化非常大的精力,我不奢望大家都来用。
对于二进制文档,如果使用文件服务器来管理,则涉及到权限控制、备份策略、版本控制。
文档的管理策略:
里程碑式的文档,交由版本控制系统维护。文件的提交由配置管理组维护,一般只保留里程碑版本;
文件服务器用于日常的文档维护。文档分门别类放在项目目录中;
并且一个文档建立一个目录,文档的多个版本通过文件名体现;
关于编程规范,曾经使用过DocBook 文档进行过管理,但发现个人力量实在微乎其微,如果能使用上述的沟通和知识共享工具进行管理,再加以提炼总结,程序员间的代码互相评审,效果可能更好。
参见:《开发规范参考》...
还是一句话:“规范、制度执行与否,关键在人”。
如果新来的员工,大家都互不相识,凭什么让新员工能够和其它成员一起协同工作呢?... 因此人员培训并非可有可无。
实施方案:人事管理——给新员工的一封信,部门培训计划,小组培训计划...
下面先给各位打一针预防针,打完了,就开始理论学习。
可以把 SCM, SQA 比作厨子,可以做出一手饭菜,或好或坏,目的是能给各个项目组补充给养,提高战斗力。但是:
如果大家都不饿,厨子逼者大家吃,一定吃不出味道。如果再加上厨子的菜的味道不好,不但饭菜吃不成,还会产生矛盾;
如果项目进度非常紧张——“战斗”非常激烈,大家可能没有时间吃饭,如果偷吃,可能被看做是偷懒耍滑,那么直到饭菜凉了,可能还是吃不成;
吃没吃饱,对饭菜的口味是否合适,一定要跟厨子说一声,因为厨子一般都会认为大家喜欢。
因此想要吃好饭,一定是大家觉得饿了,或者能强迫让大家停下来歇一歇、吃口饭,如果大家又觉得饭菜还可以,那么吃饭就会成为习惯。
为 CMM 泼些冷水:
CMM 倡导持续改进,而非毕成功于一役的革命!
人是最关键的,没有人的积极参与,必定失败!
需要自顶向下,没有高层的支持,很难成功。
测试、QA 需要角色的独立。所谓分权才能制衡!
因为专业,所以分工;因为分工,才更专业。下列角色在 CMM/CMMI 模型中,具有其特定的功能。项目组可以根据其大小,某些角色可以兼任。
软件工程组SEG,Software Engineering Group
负责一个项目的软件开发和维护活动(需求分析、设计、编程和测试)的人员,包括管理人员和技术人员。
软件相关组SRG,Software Related Groups
当涉及到此术语时,要根据前后文确定是哪些组,可能是质量保证组、软件配置管理组等。
软件工程过程组SEPG,Software Engineering Process Group
按软件工程方法制定软件过程的专家组。
系统工程组SEG,System Engineering Group
负责说明系统需求,分配系统需求到硬件、软件和其他部件,规格说明硬件、软件和其他部件之间的接口,并监督这些部件的设计和开发,以确保符合规格。
系统测试组STG,System Test Group
负责计划和实施对软件的单独系统测试,以确定其软件产品是否满足其需求;
软件质量保证组SQAG,Software Quality Assurance Group
负责计划和实施项目的质量保证活动,以确保软件开发活动遵循软件过程规程和标准(作者注:注意并不是保证软件是高质量的)。
软件配置管理组SCMG,Software Configuration Management Group
负责计划、协调和实施项目的正规配置管理活动。
培训组TG,Training Group
协调和安排机构的培训活动。
虽然在中型、小型的组织中,部分角色可以兼任,但是 SQA和系统测试小组应保持其独立行:
SQA组可越过项目负责人、项目软件过程组和其他软件相关组向上级管理部门进行报告;
测试小组可不依赖软件开发人员,计划和准备系统和验收测试用例以及测试规程。
需求管理是CMM/CMMI 2级过程域(PA, Process Areas)中的一个,是其它过程域实施的前提。
没有好的需求管理会如何?
需求基本上是以失控的状态进入软件过程。
没有好的需求管理,自然项目缺乏计划性。
需求失控,组织处于反应式(reaction-driven),必然导致开发处于被动状态,项目组成为救火队。
项目失控,导致项目延期、士气低落,并非常有可能导致项目的最终失败。
因此,说需求管理是其它KPA的前提一点都不为过。
需求管理的目的:
The purpose of Requirements Management is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products.
Requirements Management 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Manage Requirements
Requirements are managed and inconsistencies with project plans and work products are identified.
SP 1.1 Obtain an Understanding of Requirements
SP 1.2 Obtain Commitment to Requirements
SP 1.3 Manage Requirements Changes
SP 1.4 Maintain Bidirectional Traceability of Requirements
SP 1.5 Identify Inconsistencies between Project Work and Requirements
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
要明确和建立需求来源渠道,既为了避免需求蔓延(requirements creep),又要避免忽视客户需求、重复劳动、和不严肃的承诺;
建立需求管理小组,对需求进行评审,如需求对系统的影响范围等;对管理需求变更管理,对于不同等级的需求,采取不同的测量;
需求文档要进行版本控制。需求亦有基线和分支,并要和代码、文档等其它产品的基线和分支保持一致;
需求文档中的SRS要具有唯一编号,可以通过项目号+SRS编号,唯一定位具体的需求;
在后续的代码、文档等数据中引用需求要确保和需求文档保持一致;
需求管理小组要严格控制进入设计和开发之后的需求变更,并根据变更频率,改进项目需求分析过程。
一个项目计划的好坏,往往决定了项目的命运。
对项目市场、利润的错误分析,导致项目盲目上马,最终失败,而这种失败实际上在项目计划阶段就注定了;
对项目规模、工作量的过小的估计,导致项目的投资加大、开发周期延长,最终影响市场推广;
没有对任务分解、时间表的详细分析,导致项目进度难于管理。
项目管理的目的:
The purpose of Project Planning is to establish and maintain plans that define project activities.
项目管理(Project Planning) 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Establish Estimates
Estimates of project planning parameters are established and maintained.
SP 1.1 Estimate the Scope of the Project
SP 1.2 Establish Estimates of Work Product and Task Attributes
SP 1.3 Define Project Life Cycle
SP 1.4 Determine Estimates of Effort and Cost
SG 2: Develop a Project Plan
SP 2.1 Establish the Budget and Schedule
SP 2.2 Identify Project Risks
SP 2.3 Plan for Data Management
SP 2.4 Plan for Project Resources
SP 2.5 Plan for Needed Knowledge and Skills
SP 2.6 Plan Stakeholder Involvement
SP 2.7 Establish the Project Plan
SG 3: Obtain Commitment to the Plan
SP 3.1 Review Plans that Affect the Project
SP 3.2 Reconcile Work and Resource Levels
SP 3.3 Obtain Plan Commitment
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
没有跟踪和控制的项目,就如同播种下种子而不去灌溉和养护一样。
项目经理不去关心项目进展,而偏重于技术的先进性,最终导致项目失控;
让开发人员承担管理负担,如填写工作日记,影响开发人员的注意力和浪费投资;
不注重处于关键路径的模块的管理,而偏重于非关键路径的模块的管理,导致由于关键路径模块的延期导致项目延期(这是一个统筹学的问题);
对于里程碑的延期没有引起足够重视,导致成为大患。
项目跟踪和控制的目的:
The purpose of Project Monitoring and Control is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.
项目跟踪和控制(Project Monitoring and Control) 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Monitor Project Against Plan
Actual performance and progress of the project are monitored against the project plan.
SP 1.1 Monitor Project Planning Parameters
SP 1.2 Monitor Commitments
SP 1.3 Monitor Project Risks
SP 1.4 Monitor Data Management
SP 1.5 Monitor Stakeholder Involvement
SP 1.6 Conduct Progress Reviews
SP 1.7 Conduct Milestone Reviews
SG 2: Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.
SP 2.1 Analyze Issues
SP 2.2 Take Corrective Action
SP 2.3 Manage Corrective Action
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
细化项目计划中WBS和时间表(可以用甘特图表示);
根据项目时间表,确定关键路径,并着重跟踪关键路径;
设定里程碑,并严格控制里程碑偏差;
项目经理而不是组员,负责每周的工作计划、工作总结和每日进度报告;
SQA 对项目里程碑、工作计划、工作日志定期检查;
软件变更的频度和复杂性,决定了配置管理的重要性。
程序员代码的更改记录,需要依靠配置管理工具备份和记录;
项目的周期开发,需要进行有效的分支管理,需要配置管理工具的帮助;
项目计划、需求文档、产品文档也要通过配置管理,保持和应用软件、代码的一致性;
软件发布的版本号管理;
软件的持续集成需要依靠版本控制系统。
缺陷控制系统,可以有效的规范开发-测试接口和工作流程;
目的:
The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
配置管理(Configuration Management) 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Establish Baselines
Baselines of identified work products are established.
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines
SG 2: Track and Control Changes
Changes to the work products under configuration management are tracked and controlled.
SP 2.1 Track Change Requests
SP 2.2 Control Configuration Items
SG 3: Establish Integrity
Integrity of baselines is established and maintained.
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
为文档、代码、缺陷控制建立相应的版本控制系统;
文档可能需要建立在受权限控制的文件服务器中,代码采用类似CVS的版本控制工具,缺陷控制使用类似GNATS的缺陷控制系统;
基线管理;
建立分支的原则是当前开发进入维护期,而主线需要进行新一轮开发,因此建立分支,分支取代主线作为上一个开发的基线。
版本号管理;
版本号由项目定义的版本号,分支版本号,和 build号构成。如: 1.3.0.0012,1.3为项目计划定义的版本号,0为分支号(0可能代表主线,如果有某个定制版本,可能为其它),后面的0012为build号,表示编译次数。
目的:
The purpose of Supplier Agreement Management is to manage the acquisition of products from suppliers for which there exists a formal agreement.
SUPPLIER AGREEMENT MANAGEMENT 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Establish Supplier Agreements
Agreements with the suppliers are established and maintained.
SP 1.1 Determine Acquisition Type
SP 1.2 Select Suppliers
SP 1.3 Establish Supplier Agreements
SG 2: Satisfy Supplier Agreements
Agreements with the suppliers are satisfied by both the project and the supplier.
SP 2.1 Review COTS Products
SP 2.2 Execute the Supplier Agreement
SP 2.3 Accept the Acquired Product
SP 2.4 Transition Products
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
目的:
The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs.
Measurement and Analysis 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Align Measurement and Analysis Activities
Measurement objectives and activities are aligned with identified information needs and objectives.
SP 1.1 Establish Measurement Objectives
SP 1.2 Specify Measures
SP 1.3 Specify Data Collection and Storage Procedures
SP 1.4 Specify Analysis Procedures
SG 2: Provide Measurement Results
Measurement results that address identified information needs and objectives are provided.
SP 2.1 Collect Measurement Data
SP 2.2 Analyze Measurement Data
SP 2.3 Store Data and Results
SP 2.4 Communicate Results
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
目的:
The purpose of Process and Product Quality Assurance is to provide staff and management with objective insight into processes and associated work products.
Process and Product Quality Assurance 属于 CMMI 2级的 PA 之一。内容如下:
SG 1: Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.
SP 1.1 Objectively Evaluate Processes
SP 1.2 Objectively Evaluate Work Products and Services
SG 2: Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.
SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
SP 2.2 Establish Records
GG 2: Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
GG 3: Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
One of the four Common Features of CMMI model. Ability to Perform (AB) groups the generic practices related to ensuring that the project and/or organization has the resources it needs.
参见Common Features, CO, DI, VE.
CMM (The Capability Maturity Model for Software, CMM or SW-CMM, 软件过程能力成熟度模型), developed by the Software Engineering Institute (SEI), has had a major influence on software process and quality improvement around the world.
The SW-CMM is based on the principles of total quality management (TQM) and continuous process improvement. Its five levels describe an evolutionary path from immature and ad hoc software processes to mature and disciplined software processes.
The five maturity levels in the SW-CMM (1-initial, 2-repeatable, 3-defined, 4-managed, and 5-optimizing) describe successive stages for continuous process improvement and define an ordinal scale for rating the maturity of an organization's software process.
Maturity levels are composed of key process areas that identify areas that an organization should focus on to improve its software process.

CMM Structure

The Five Levels of Software Process Maturity
参见CMM.
CMMI: The Capability Maturity Model Integration (CMMI) project. The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development, acquisition, and maintenance of products or services.
Since 1991, CMMs have been developed for a myriad of disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and Integrated Product and Process Development. Although these models have proven useful to many organizations, the use of multiple models has been problematic. The CMM Integration project was formed to sort out the problem of using multiple CMMs.
The components of both the staged and continuous representations are process areas, specific goals, specific practices, generic goals, generic practices, typical work products, subpractices, notes, discipline amplifications, generic practice elaborations, and references.

CMMI Model Components
参见CMM.
One of the four Common Features of CMMI model. Commitment to Perform (CO) groups the generic practices related to creating policies and securing sponsorship.
参见Common Features, AB, DI, VE.
Each key process area is organized into five sections called common features. The common features specify the key practices that, when collectively addressed, accomplish the goals of the key process area.
The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting.
The key practices of CMM models are divided among five Common Features sections: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
As a CMMI terminology, Common features are predefined attributes that group generic practices into categories.
There are four common features used in CMMI models with a staged representation: Commitment to Perform, Ability to Perform, Directing Implementation, and Verifying Implementation.
One of the four Common Features of CMMI model. Directing Implementation (DI) groups the generic practices related to managing the performance of the process, managing the integrity of its work products, and involving relevant stakeholders.
参见Common Features, CO, AB, VE.
目标
目标概括一个KPA(关键过程域)的KP(关键实践),用来确认是否一个组织或者一个项目已经有效的实现该关键过程域。在 CMMI 模型中,用 SG,GG来描述。
Generic Goals
Generic goals are called “generic” because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied.
Generic Practices
Generic practices provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models.
KP(Key Practice, 关键实践),每个KPA中都包含数个KP,是CMM评估的要点,其特点是描述"什么"而不是"怎样";
Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.
KPA (Key Process Areas, 关键过程域):为便于描述,在CMM 模型中的各个成熟度等级(2级到5级)的改进活动被组织为几个KPA中。KPA这个名词非常容易引起人们的误解:是不是还存在着非关键的过程域?其实CMM认为过程中实现了这些关键点就证明达到了相应的成熟度等级,CMM也并没有去定义过程中非关键点。在改进和整合后的 CMMI 模型中,KPA这个容易误解的名词,改为 PA(Process Areas)。
表 A.1. The Key Process Areas in the CMM/CMMI
| Level | Focus | CMM's KPA | CMMI's PA |
|---|---|---|---|
| 1 Initial | Competent people and heroics | ||
| 2 Repeatable(CMM), Managed(CMMI) | Project management processes |
|
|
| 3 Defined | Engineering processes and organizational support |
|
|
| 4 Managed(CMM), Quantitatively Managed(CMMI) | Product and process quality |
|
|
| 5 Optimizing | Continuous process improvement |
|
|
Use of the adjective key implies that there are process areas (and processes) that are not critical to achieving a maturity level. The SW-CMM does not describe all of the process areas relevant to developing and maintaining software. Instead, the SW-CMM describes the process areas that are critical to determining process capability.
software capability evaluations(软件成熟度评估)是在更为面向审计的环境中进行的。评价的结构将影响挑选承制方或投放资金。
software capability evaluations, in which a trained team of professionals identifies contractors who are qualified to perform the software work or monitors the state of the software process used on an existing software effort.
Software capability evaluations are focused on identifying the risks associated with a particular project or contract for building high-quality software on schedule and within budget. During the acquisition process, software capability evaluations may be performed on bidders. The findings of the evaluation, as structured by the CMM, may be used to identify the risks in selecting a particular contractor. Evaluations may also be performed on existing contracts to monitor their process performance, with the intent of identifying potential improvements in the software process of the contractor.
Software Engineering Institute 卡耐基-梅隆大学(CMU)的软件工程研究所;
Software Engineering Process Group软件工程过程组;
Specific Goals
Specific goals apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied.
Specific Practices
A specific practice is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components.
软件过程评估(SPA,Software Process Assessment),CMM评估的前期工作,目的是发现SP中的问题。
software process assessments, in which a trained team of software professionals determines the state of an organization's current software process, determines the high-priority software process-related issues facing an organization, and obtains the organizational support for software process improvement;
Software process assessments focus on identifying improvement priorities within an organization's own software process. Assessment teams use the CMM to guide them in identifying and prioritizing findings. These findings, along with guidance provided by the key practices in the CMM, are used (by a software engineering process group, for example) to plan an improvement strategy for the organization.
software process improvement,软件过程改进(或称软件过程评估),CMM评估的一种,主要目的是提供改进方向;
software process improvement, in which an organization plans, develops, and implements changes to its software process;
One of the four Common Features of CMMI model. Verifying Implementation (VE) groups the generic practices related to review by higher level management and objective evaluation of conformance to process descriptions, procedures, and standards.
参见Common Features, CO, AB, DI.
Copyright © 2006 WorldHello 开放文档之源 计划 |