CMMI
文章平均质量分 56
zhangmike
这个作者很懒,什么都没留下…
展开
-
团队章程---促进团队合作
团队章程是提供指导原则、规则并管理团队成员行为的方针政策。[1]章程应由团队成员共同完成,并为所有成员服务。在团队章程中团队成员可以约定相互权力和义务,制定团队行事的基本原则,并设计面临突发事件时的应对措施。在实践中,一些质量团队的章程可以将质量目标和组织绩效目标联系起来。现代组织中很多团队中存在不同程度的人际信任、相互依存和共同责任问题,团队在动态发展中的内在”摩擦”是现实存在的。团队章程可以最大原创 2016-08-24 08:23:55 · 4794 阅读 · 0 评论 -
软件需求说明的前世和今生
软件需求说明软件需求说明,也称软件需求说明书,或者软件需求规格说明,或者软件需求规格说明书, 对应的英文是Software requirements specification, 缩写是SRS。软件需求说明是软件系统需求的规格化说明,是对将要开发系统的行为的说明。它包括功能性需求,也包括非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。英文原创 2014-04-19 09:00:56 · 2779 阅读 · 0 评论 -
关于代码评审的微博讨论汇集
编者按:7月12日,weibo上 @自律自强 发表了一条微博:十几年来的软件项目经历告诉我,评审是最有效也是成本最低的质量保证和提升的手段,设计书和代码100%肉眼全覆盖绝对值得,而且还是迅速提高新人能力及其成果物的规范性的有效手段。各路朋友纷纷参与讨论,各有观点,真知灼见也许就在其中,读来很有收益。所以汇总得本文。@自律则强 十几年来的软件项目经历告诉我,评审是最有效也是成原创 2013-08-01 09:10:29 · 3003 阅读 · 0 评论 -
关于CMMI级别阶梯式前进路线图的对话
Q:CMMI提供的阶梯式前进的路线图是不是基于组织当前瓶颈的?有什么问题?--------------下文取之于前几天的微博讨论。@张克强-敏捷307:CMMI提供了各项最佳实践的特征,提供了阶梯式前进的路线图,提供了弹性灵活的解决方案。@拯救与逍遥:提供了阶梯式前进的路线图,这就是个很值得探讨的问题。这样的改进路线,很有可能不是基于组织当前瓶颈的。这样会造成,过程改进时间漫长,而原创 2013-06-11 11:44:41 · 2162 阅读 · 0 评论 -
关于方法论的对话之二敏捷与方法论
@Phil Japikse:如今,敏捷方法论正迅速的从边缘角色发展向主流技术,甚至渗透到了很多大公司的软件开发团队里。敏捷革命给软件行业带来了巨大的变化。 大多数敏捷方法论主要针对的是过程管理问题,不涉及到其中的开发技术(Kent Benk 和 极限编程是例外)。@张克强-敏捷307:对于方法论集合的发展历史而言,11年不是长,而是短,对比下项目管理、精益、全面质量管理、CMMI、ISO9原创 2013-05-30 08:05:20 · 1582 阅读 · 0 评论 -
关于方法论的对话之一方法论基本
方法论是个常用词,原意是方法的集合,但有很多不同的理解。下文整理了最近在微博上关于方法论的讨论,首先是方法论的基本部分。@刘文圣-大圣:方法论是解决一类问题方法和实践的系统化总结,按照方法论的要求对解决类似问题可产生更稳定的质量,它并没有降低对人的能力的要求,相反还对人员的专业知识和技能提出了更明确的要求。@张克强-敏捷307:哲学和方法论是发展变化并继原创 2013-05-30 07:58:58 · 1875 阅读 · 0 评论 -
过程改进建设中的常见奖励措施
常见的有四类过程改进值得考虑的奖励措施一、Process Champion 过程冠军奖励在过程定义、知识整理并传播中突出贡献的人过程冠军 承担某方面过程的定义起草、编写教材,提供培训和指导。对提供的培训,让参与者打分,根据参与者数量和打分高低,进行评比奖励。 二、Process Hero 过程英雄奖励实施新过程规范的个人或团队原创 2013-05-28 20:15:59 · 1562 阅读 · 0 评论 -
SPICE:过程改进的又一种选择
根据2008年3月美国国防部直属的软件工程研究所(简称CMU/SEI)公布的年度数据显示,中国通过CMMI(能力成熟度集成模型)认证的企业总数达到448家,已超过印度(311家),居世界第二位,仅次于美国(847家)。虽然目前我国高成熟度企业只有52家,与印度(173家)和美国(135家)有较大差距,但这种进展仍令人刮目相看。笔者认为带来这种进展的原因可能是“印度的榜样力量”,再加上我国政府的鼓励转载 2012-07-09 10:18:00 · 3203 阅读 · 0 评论 -
从冲咖啡看统计过程控制
昨天,徐毅-Kaveri发了一条微博。 @徐毅-Kaveri:怎么#冲咖啡#?先倒水再放咖啡,还是先放咖啡再冲水?后续对话中提到他在强调统计过程控制,要用数据说话,并且at @拯救与逍遥 @张克强-敏捷307@拯救与逍遥 昨天之前也发了条微博:问了下cmmi咨询师,对方确认没有公司能做到,根据数据对软件开发过程进行统计控制。At@徐毅-Kaveri @张克强-敏捷307原创 2012-03-23 07:05:20 · 1894 阅读 · 0 评论 -
”过程”在敏捷开发中的位置
本文是《敏捷热点问题的多角度杂议》(首次刊发在程序员杂志2011年9月刊)的一部分,为方便讨论,在这里独立成文。敏捷软件开发宣言的第一个价值观指出“个体和互动 高于流程和工具”。“流程”对应的英文是“Process”,在有些地方也译为“过程”,下文中“流程”和“过程”为同义词。由于敏捷宣言和原则总共篇幅不长,并没有完全说明其中问题,导致了如下有趣又矛盾的现象:1,部分敏捷的执行者抱怨以原创 2011-12-22 15:32:19 · 2109 阅读 · 0 评论 -
小议团队自组织
本文是《敏捷热点问题的多角度杂议》(首次刊发在程序员杂志2011年9月刊)的一部分,为方便讨论,在这里独立成文。“自组织”是敏捷中难以把握的一个词,英文是self-organizing,也有地方是self-organization,还有self-organized,以上三个词的中文都译为“自组织”,从英文来看,显然三者是有区别的。 在敏捷软件开发宣言中没有提自组织,在敏捷原则中相原创 2011-12-08 14:35:36 · 2592 阅读 · 0 评论 -
对话:在敏捷中,是否可以仍然用需求来替代用户故事?
For Agile, could we still use Requirements instead of user stories, or could we combined both ?转载 2014-04-20 09:43:44 · 1701 阅读 · 0 评论 -
做好过程质量保证QA工作的几个关键方面
过程质量保证的范围是什么?过程质量保证是指不同于测试的、主要针对过程和中间工作产物的质量保证,一般而言,早年间的过程质量保证根据最早的CMM,也称为软件质量保证,缩写为SQA。现在最新的CMMI将其对应的过程域称为产品和过程质量保证,缩写是PPQA,这里面的一个P产品包括了最终产物,但其焦点是中间工作产物,所以这个P放在这里反而是带来一些混淆,与测试存在一些重叠。所以过程质量保证(PQA)原创 2014-04-12 10:14:35 · 11665 阅读 · 0 评论 -
最初步软件需求说法的简单调查报告
缘起笔者在这几年工作中,接触了各类需求,不同人员在不同的时间点按照不同表述方式来提供。在沟通交流中,有些时候会因为说法的不同和不同的说法,浪费不少时间,往往会有这样的感觉:唉,原来你说的是这个啊? 或者是这样:哦,我大概明白你的意思了,你的这个结构逻辑是这样的啊。所以在4月10日在微博上发起了如下的调查@张克强-敏捷307调查-你如何称呼最初步的软件需求? 业务需求?客户需求?用户原创 2014-04-13 10:54:16 · 3357 阅读 · 0 评论 -
苍狼敏捷软件开发团队建设指南-3-干系人管理
本指南的组成结构为了便于博客阅读,拆分成如下3部分: 1. 苍狼敏捷团队模型 2. 团队建设 3. 干系人管理干系人管理基础干系人管理是为了帮助团队在计划阶段识别组织内外部的干系人,在团队全生命周期当中计划并跟踪干系人的参与活动,以保障团队的成功。干系人又称为相关利益者。下文交待了干系人的基础说明,列举了潜在的干系人,给出了干系人管理策略和典型的干系人参与的活动。说明了如何识别干系人及其原创 2016-06-14 16:00:33 · 7026 阅读 · 0 评论 -
需求评审五个维度框架分析及其带来的启示-4-需求条目化管理
需求条目化管理是指需求的主体分条目管理,比如对于用例、用户故事、特征点的条目化列表管理,有些工具中条目称为工作项(work item)。条目化管理的特征是1,状态流转实现工作流;2,条目属性字段可定制。3.3节所分析的敏捷开发下的需求绝大多数是已经实现了条目化管理,产品待办列表就是Scrum进行条目化管理的载体。而条目化需求管理并不是敏捷开发的专利,当前已经有不少组织在非敏捷环境下采用条目化需求管理原创 2016-06-09 10:29:04 · 9185 阅读 · 0 评论 -
软件需求分层处理的多种常见方式
当前的需求 常见分 几个层次来管理? 原先的SRS只有一个层次,在瀑布型生命周期中发挥了重要作用,需求里程碑评审和需求变更管理都是围绕着SRS来进行的。随着时间推移,瀑布型生命周期的弊端越来越明显,而瀑布型生命周期的需求管理是首先被改进的。一个明显的趋势是不再只有SRS,而是分多个层次来分析需求,进而开展需求管理。目前,业界出现了多种需求层次划分方式,本文来列举下。原创 2015-10-31 07:36:05 · 3921 阅读 · 2 评论 -
需求文档可以不签字吗之二-理论推导
怎么可能在没有需求文档的情况下,把软件开发出来?完全有可能。回想下当年读书的教研组,回想下自己的编程经历,总有至少那么几次,在种种的原因下,在没有需求文档的情况下,软件已经编写好了。也许那个软件规模小些,质量不是太好,但确实是没有需求文档的情况下把它编了出来。所以没有需求文档是可以把软件开发出来的。为了保证这样的软件达到要求,显然需要另外的手段。笔者认为最要紧的手段是快速地将运行的软件给用户试用或原创 2015-01-12 21:21:09 · 1647 阅读 · 0 评论 -
需求文档可以不签字吗? 之一
在软件开发中,需求分析和需求管理一直被认为是软件开发成功与否的关键。在CMMI中,需求管理是CMMI2级的过程域,需求开发是CMMI3级的过程域。在瀑布型生命周期当中,安排了需求分析阶段,一般也安排需求分析里程碑评审。瀑布型生命周期存在了很多年,曾经几度写入到软件开发的国际标准、国家标准当中。由于瀑布型生命周期如瀑布般顺流而下,在设计阶段开始后,根据需求文档的结果来开展工作,要求需求文档的结果比较原创 2015-01-12 21:15:38 · 2779 阅读 · 0 评论 -
过程质量保证PQA的几个关键方面
过程质量保证的范围是什么?过程质量保证是指不同于测试的、主要针对过程和中间工作产物的质量保证,一般而言,早年间的过程质量保证根据最早的CMM,也称为软件质量保证,缩写为SQA。现在最新的CMMI将其对应的过程域称为产品和过程质量保证,缩写是PPQA,这里面的一个P产品包括了最终产物,但其焦点是中间工作产物,所以这个P放在这里反而是带来一些混淆,与测试存在一些重叠。所以过程质量保证(PQA)这个提法原创 2015-01-11 16:12:33 · 4855 阅读 · 0 评论 -
SVN下最高效打基线方法
方法二:利用SVN自身的revision number。最高效的方法是在关键commit时说明打基线,或者说明关键要点,比如评审后修改再复核通过,比如评审通过。方法二更加正式的做法是利用专门的表格记录关键点的Revision Number原创 2014-07-06 21:16:39 · 19177 阅读 · 1 评论 -
什么版本测试通过就能发布?
问题的另外一个问法:如何称呼提交正式测试的软件版本?这个版本如果后续测试通过的话,就能直接发布,但是在提交测试的时候,不知道测试是否通过。 发布候选版?正式测试版?相对的,如何称呼就算测试通过也不能发布的版本(比如因为部分特性未完工)?非正式测试版?提前测试版?回答1:release candidate是一个常用的叫法。 from @stephen_wang_7971关联回答1.1:Release原创 2014-07-24 07:46:12 · 4327 阅读 · 0 评论 -
组织敏捷之路上的七点体会
1,专门的机构或专人来推进组织级敏捷,可能的机构名称有:敏捷中心、卓越中心、过程改进部、SEPG、质量部、运营改善部、PMO、Delivery Excellence;可能的专人有:过程总监、质量总监、项目管理总监、Chief Agile Coach。 2,敏捷开发涉及到各项方方面面,就算是采用书本上的某些实践,比如用户故事,各个团队各个组织都有些定制化或改造过的做法,比如新加tech story,原创 2014-06-20 07:46:40 · 4118 阅读 · 3 评论 -
软件开发词汇表
本文用于收集整理软件开发词汇原创 2014-04-19 05:56:14 · 3102 阅读 · 0 评论 -
从“执行新过程新增5%的工作量”看新过程引入
“执行新过程新增5%的工作量”这个标题写下后发现它是有歧义的。 第一个意思是 执行了新过程后,整体工作新增了5%的工作量;第二个意思是 新过程执行后,过程执行本身增加了5%的工作量。 1, 过程执行本身的工作量是极为难以度量的。以需求开发中书写需求规格说明书为例,假设老过程是按照以往某个样例来书写,不需要同行评审,没有度量;新过程是按照模 板来书写,要求进行同行评审,进行了度量原创 2011-12-04 10:33:24 · 2144 阅读 · 3 评论 -
罗伯特议事规则与团队会议规则简化12条
美国人崇尚自由,但美国人对待开会却是严肃认真的,美国人是会少规矩多。说到开会的规矩,世界上恐怕没有人比得上美国人的规矩大了。他们有一本厚厚的开会规则——《罗伯特议事规则》(Robert's Rules of Order)。这在世界上是独一无二的。这部由亨利·马丁·罗伯特撰写的《议事规则袖珍手册》(Pocket Manual of Rules of Order)于1876年出版,几经修改后于2000原创 2011-11-07 17:48:27 · 3947 阅读 · 0 评论 -
敏捷改进与敏捷转型
用什么词来描述某个组织采用敏捷呢? 敏捷采用?敏捷导入?敏捷转型?敏捷引入?敏捷改进? 从这些词当中可以发现不同级别的组织采用敏捷是不一样的,大体可以分为项目级、部门级和公司级,不同组织级别的敏捷导入or转型or改进得到的高层支持不一样,可以采取的手段不一样。 #原创 2011-09-30 07:03:28 · 1952 阅读 · 0 评论 -
CruiseControl日构建简单配置
CruiseControl使用笔记本文所用cruisecontrol版本是2.8。1. 日构建配置日构建是指在每天指定的时间进行构建。1.1. requireModification 设为 false,含义是无论有没有变化,都要进行构建。1.2. > file="logs/${project.name}/status.txt"/>>原创 2008-11-29 19:49:00 · 1271 阅读 · 0 评论 -
Re:CMM和RUP、XP的关系是什么?
SEI官方说法:XP与CMM没有冲突。而在实践中,两者冲突比较明显。以需求为例。CMM要求有方法论得到文档化的需求。XP重视迭代,现场用户快速反馈。用户故事+程序反映需求。以计划为例,CMM要求有全面的开发计划,工期,工作量,项目规模,CCR等要作出估算。而且估算要有依据,而XP中没有如此要求,相反采用快速简单计划的方式来进行。最根本的关键还在于两者对工程师的态度上。XP鼓励工程师自由发挥。而CM原创 2005-10-10 07:19:00 · 2515 阅读 · 0 评论 -
CMMI/CMM组织的角色设置与行政角色设置的问题.
EPG Manager --- EPG GroupQA Manager --- QA GroupCM 配置管理员对于一个CMMI/CMM组织而言, EPG是过程改进的负责小组.QA是过程执行的监督者.CM是配置管理员,也承担一定的检察任务. 但一个问题是是不是要在行政角色中设立这个岗位?由于软件组织在过程改进之前往往没有EPG Manager,QA Manager等对应岗位,所以一般地进行过程改进原创 2005-04-21 06:59:00 · 3779 阅读 · 0 评论 -
简述软件配置管理
一、简述软件配置管理随着软件团队人员的增加,软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发面临越来越多的问题,其中包括对当前多种产品的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等,这些问题在实际开发中表现为,项目组成员沟通困难,软件重用率低下,开发人员各自为政,代码冗余度高,文档不健全等;造成的结果是:数据丢失,开发周期漫原创 2005-09-03 06:43:00 · 9414 阅读 · 1 评论 -
一个高成熟度组织的规程和指南目录
1.1 项目过程管理1.1.1 项目计划43_项目提议及立项规程:真正体现项目全生命周期管理。07_标准软件过程及其裁剪指南:指导项目如何开展进行和结束。25_开发计划编制规范:开发计划阶段指南。39_维护项目过程:项目后期维护指导。1.1.2原创 2005-09-03 06:38:00 · 2334 阅读 · 1 评论 -
SRS前需求双向追溯解决方法
第一个问题,什么是SRS前的需求SRS前的需求可以视为需求的原始素材,来自于客户的建议或要求,领导的意见,团队内部的点子都可以视为SRS前的需求.这些的陈述可能是凌乱的,没有结构的.第二个问题,SRS前会整理需求,有没有必要管理SRS前的需求在以前国内的标准和教学中,是没有SRS前需求管理的文档的.一般认为SRS会总结这些需求素材成SRS格式.在实际情况看,如果对SRS前需求进行管理,可以更好的管原创 2005-09-03 06:31:00 · 2657 阅读 · 0 评论 -
SRS后需求双向追溯解决方法
说来也很简单.常见的是利用工具(有专门的,也有用ACCESS,EXCEL,或定制)来得到一个需求矩阵的.这里介绍一种最简单的方法.1,在SRS中划分出一个一个需求,比如功能点,画面,条目等等,给每一个需求编号;2,在后续的所有工作产品中,与需求对应的地方,写下对应的需求编号. 比如在基本设计书中,一个类,就写清这个类对应的需求编号.在代码中,利用注释写清对应的需求编号.测试用例中记录对应的需求编原创 2005-09-03 06:16:00 · 2598 阅读 · 0 评论 -
关于软件组织培训的几个值得提倡的建议
1,培训课程要做到标准化,不因为老师的不同,而使培训主要内容发生过大变化。2,培训要有记录,包括学生的记录和老师的记录。3,培训要有计划,要根据培训需求来安排培训。4,值得安排一个指定的人员来管理培训,也可以把培训管理的职责交给人力资源部门专门管理。5,培训的结果要得到使用,没有接受相关岗位培训或免修,就不能就任相关工作。6,培训的效果应当得到调查,以提高培训水平,给老师和培训材料提出改进意见。原创 2005-09-03 06:15:00 · 2091 阅读 · 0 评论 -
工具在软件过程改进中的重要作用
过程改进必须依赖于工具1,工具可以提高效率2,工具可以保证既定规程得以较好的执行3,工具不会抱怨,能承担大量数据存储计算工作。4,规程工具化是每个过程改进开始时或进行中一直要考虑的问题,而且优先级要高。 即使不进行过程改进,如下工具是软件开发团队(10人以上)非常值得拥有1,缺陷管理工具.2,配置管理工具.(以上两项几乎是必备的)3,需求管理工具4,自动测试工具而在过程改进中,还要有额外的工具.原创 2005-09-03 06:14:00 · 2485 阅读 · 1 评论 -
目标驱动的软件度量(选译)
1 介绍1.1 目的这本指导书讲述了如何识别和定义软件度量来支持你们自己组织的商业目标。我们要讲解的这个过程会提供深入对于你们来说最重要的管理的洞察力。这些度量能够追溯到你们的商业目标,因此你们的数据收集活动会更好地集中在他们既定的目标上。我们把这个过程称之为"目标驱动度量"。在目标驱动度量中,首要的问题不是"我应当运用什么指标?",而是"什么是我想要知道的或要学习的?"[引自R ombach原创 2005-07-14 06:11:00 · 3000 阅读 · 0 评论 -
CMMI5级组织如何设定年度目标
CMMI5级组织如何设定年度目标作法1:明年继续保持在CMMI5级高成熟度评语:骗谁呢?作法2:在今年的基础上,生产率提升10%,缺陷密度下降10%评语:这叫人有多大胆,地有多大产。作法3: 1根据商业目标,确认反映商业目标的指标,一般是总体性质的。 2对每一种(类型)指标修正或建立 过程绩效模型。 3预计明年改进,对模型中参数的影响,将影响后的参数代入模型,得到具体的商业目标,一般是一个数值范围原创 2008-12-12 20:43:00 · 1470 阅读 · 0 评论 -
CMMI之需求管理和股票池管理
CMMI之需求管理和股票池管理 CMMI之需求管理和股票池管理 CMMI中需求管理过程域用于管理项目产品和产品组件的需求以识别需求与项目计划和工作产品之间不一致的地方。需求管理过程域只有一个特定目标:需求得到管理并且与项目计划和工作产品之间的不一致问题得到识别。对于这个过程域,在证原创 2008-12-12 21:04:00 · 1197 阅读 · 0 评论 -
原始需求的来龙去脉和核心要求
在软件工程术语中,“原始需求”并不是个常见的说法。这个“原始需求”的提法是本博主自己提出来的。它的起源与CMM有关,CMM中,有“客户需求”的说法。当时没有直接采用“客户需求”而采用“原始需求”的主要原因是当时开发产品不直接面对客户,直接面对的是工程实施部门,需求来自原创 2011-09-24 06:01:34 · 5872 阅读 · 0 评论