2009年12月_麦哲思科技任甲林

原创需求变更的5W1H分析

why，需求为什么变化？甲方的特殊原因：不知道如何说清楚需求；没有明确的需求；没有确认乙方描述的需求；乙方的特殊原因：理解错了需求；没有很好的诱导客户的需求；共性原因：业务就是变化；人与人之间的沟通本来就存在障碍；特殊原因是可以消除的，共性原因是难以消除的。 who : 谁会提出需求变化？客户：客户方的

2009-12-15 14:33:00 3093

原创例解：集成测试用例与单元测试用例的区别

函数一： getMaxInTwo(int a,int b) { if a>=b return a; else return b; } 函数二： getMaxInThree(int a,int b,int c) { a=a+1; int max=getMaxInTwo(a,b); max=getMaxInTwo(max,c); } 单元测试用例的设计： getMaxInTwo的UT用例：（3，2）

2009-12-08 16:15:00 5641 1

原创例解：如何将规范的过程敏捷化？

很多企业基于CMMI建立过程体系后，大家普遍反应太复杂，编写的文档太多，复杂的体系可能就无法贯彻执行下去，无法成为企业的文化。因此需要敏捷化，当我们对过程进行敏捷化时，是基于实效的目的而不是基于评估的目的。如何将一个规范的过程体系敏捷化呢，下文将针对软件企业反应突出CMMI中的DAR过程域为例，说明敏捷化的方法。首先，看看在CMMI体系中对DAR的要求：SP1.1建立决策分析指南SP1.2建立

2009-12-08 16:15:00 1885 2

原创例解:目标驱动的度量元识别方法

(1)识别需要数据的人(Person）: 服务经理(2)识别管理目标（Goal）/要解决的问题(Problem)：提高客户请求的处理速度(3)定义如何量化管理目标/要解决的问题：（3.1）识别被度量的对象(Object)：待处理的客户变更请求(3.2) 识别被度量对象的属性(Attribute)：待处理的变更请求的个数待处理的变更请求的计划工作量(4)识别如何展示度量数据(Indica

2009-12-08 16:14:00 1533

原创东航，想说爱你不容易

我坐东航的航班是小概率事件。自05年6月做咨询以来，平均每月飞行12次，到现在大概有600次的飞行记录，坐东航的航班大概有10次。在10次的记录中，印象里只有一次准点，因此，在我印象里：东航准点也是小概率事件，所以, 除非万不得已，我不坐东航的航班。从今年五一到现在，今天是第三次坐东航的航班，次次晚点。本周二从成都飞西安，7点以后的航班只有东航的，结果应该是9点55分起飞的，延期了1个半小时才

2009-12-08 16:13:00 1370 1

原创西安印象

来西安大概有八次了。印象最深的就是西安的美女与羊肉泡馍。认识西安的美女不是在西安。曾经有济南的同事、有上海的和深圳的客户、北京的同行、南京的合作伙伴都是西安美女。西安美女最大的特征是：漂亮、大气、不拘小节。1995年，上海的一个客户，西安美女曾经到公司去参观，看完我们的软件演示进行讨论时，竟高兴的坐在了我们的办公桌上，害得办公室主任过来问我，是咋回事。认识羊肉泡馍却是在西安。2005年

2009-12-08 16:13:00 2114 1

TSP（Team software process）是Humphery提倡的解决CMM如何做的一个模型，他认为采用了TSP之后，可以加快企业达到CMMI5级的速度，可以提高企业的质量。在TSP中Humphery提出多项度量数据，我从中整理了如下的10个量化法则和大家分享，其中前5个法则是关于工作量的分布，后5个法则是关于质量的。其实这些法则中具体数值的大小完全可以商榷，但是最关键的是蕴含在这些数值

2009-12-08 16:12:00 1505

原创敏捷始于客户

每个失败的项目了都可以找这个借口：项目周期短、需求变化快、人员有限。需求、工期是由客户确定的。作为客户来讲，他不可能去合理评价给定的需求是否可以在某个时间内能够完成，至于投入多少人那更是开发方自己的问题。开发方对客户做出了承诺就要兑现承诺，否则就不要承诺，既然承诺了，就没有理由再去抱怨工期短、需求变化快。开发方必须接受这个现实，认可这个现实，然后才可以玩这个游戏，否则你就出局。 CMMI是应

2009-12-08 16:11:00 1329

原创正式评估时被访谈人员应该注意什么？

在进行CMMI的正式评估时，被访谈的人员应该快速、准确、条理清楚回答评估组成员的问题，这样才能在比较短的时间内让评估组成员做出正确的判断。根据我的访谈经验，被访谈人员应注意如下的问题：（1）听清楚问题，再回答问题。有的被访谈人员可能是由于紧张，没有听清楚评估组的成员问的是什么问题，就答非所问，浪费时间。当你不能确定提问者的问题的含义时，可以要求评估组的成员对问题做出进一步的解释

2009-12-08 16:11:00 1822

原创高成熟度的真正难点是什么？

很多朋友认为4-5级难做的原因是度量做的不好，其实我认为那只是表象，最根本的原因还是过程不稳定，2-3级的过程就没有做好，过程不稳定，反应在数据上就不稳定，MA可以做的很好，但是MA的结果可能没有管理的参考价值，建立的模型就没有意义。比如：我们可以很准确的度量身高、体重、年龄、每天的饭量、每天饭食里葡萄糖的含量、智商。我们希望建一个模型来预测智商，假如根据上述信息建立了一个模型：智商=f(

2009-12-08 16:11:00 1417

原创 QA与QC的差别

昨晚与朋友讨论质量保证（QA）与质量控制（QC）的概念差别，之所以要讨论这个问题，涉及到了在公司内关于质量保证活动的职责分配问题，涉及到了质量保证人员的配备的问题，因此具有一定的实践意义。先来看在CMMI模型中的相关描述：1 质量保证的定义：A planned and systematic means for assuring management that the defined standar

2009-12-08 16:10:00 2820

原创 QA人员的工作内容

1 与新项目的项目经理一起确定项目组应使用的管理标准。项目组的管理标准的来源主要包括4个：（1）国际、国家、行业等外部标准 (2) 企业内部标准（3）客户要求的标准（4）项目经理拟定的标准

2009-12-08 16:02:00 2652

原创 PPQA的8个原则

在运行检查中，发现PPQA常犯的错误实际上是由于没有掌握下面的8个基本原则所引起的：（1）对所有的交付物都要执行PPQA；（2）所有的活动都要执行PPQA；（3）在组织级要定义抽样的准则；（4）执行PPQA要有检查单；（5）有检查就要有记录，无论是否有问题；（6）有问题就要跟踪关闭；（7）对问题要分类分析（8）要对PPQA执行PPQA，并要有记录；

2009-12-08 16:01:00 3336

原创需求，传说中是这样的……

在软件开发中应该写哪些文档？如何写这些文档？这是在咨询过程中经常被询问的问题。在敏捷的方法与规范的方法中给出了不同的答案。无论采用何种开发方法，最基本的原则是：需求必须文档化！人类信息的沟通主要通过2种方式：文档与口头交流。文档可以流传很久，不容易存在歧义，在传递中不会增加或减少内容，比如《史记》之类的书流传了上千年。口头交流在传递的过程，很容易由于传递人个人的观点而对信息进行增删

2009-12-08 16:00:00 1150

原创如何在软件质量管理活动中更好地使用检查单？

作者：任甲林　来源：希赛网　http://www.csai.cn　2006年6月28日　　关键字：检查单形式内容分类发现效率　　摘要：本文总结了在软件质量管理活动中，设计与使用检查单的6个基本要点，为更好地利用检查单从事质量管理活动提供了一个实用性指南。　　检查单（Checklists）是软件质量管理活动中最常用的工具之一，通过检查单的作用是提醒检查人员检查哪些内容，避免遗漏。在设计

2009-12-08 16:00:00 1647

原创需求评审的案例分析

案例一：客户需求文档评审参与人员：1位主持人，1位作者，1位记录员，4位专家，1位咨询顾问旁观开始时间：15：40 结束时间：17：15 会议工时：6.3人时会前准备累计工时：9人时总工时：15.3人时会议前发现的问题：25个会中发现的问题：2个合计问题：27个会前评审效率：2.8个/人时会中评审效率：0.3个/人时评审文档的规模：13页缺陷

2009-12-08 15:59:00 2723

原创需求管理过程域的要点

今天在客户处，看到客户拿了一份从网上下载的对CMMI2级、3级的实践的注释，随手翻了一翻，刚读了第1个PA需求管理的5条特定实践，就发现基本上每条实践都有大大小小的误解，我想该材料很容易对CMMI的实施造成负面的影响。因此，特地根据我的咨询经验与体会，对该过程域的理解与实施要点进行了整理。在下表中：（1）没有翻译模型的原文；（2）包含了模型的要点；（3）扩展了模型的要求；（4）列出了客户的某些好的

2009-12-08 15:58:00 1918

原创需求与设计的界线

需求与设计的区别究竟是什么？教科书上的经典答案是：需求关注系统“做什么”，设计关注“如何做”，其实这是一个很模糊的说法。无论是在结构化方法中还是在面向对象的方法中，需求分析的结果既包括了“做什么”也部分包括了“如何做”，只不过描述“如何做”时抽象的层次比较高或者描述了某个局部需求的“如何做”。客户在提出系统需求时，可能对“如何做”提出一些约束条件，比如客户要求必须采用三层结构，必须采用某个中间件

2009-12-08 15:55:00 1962

原创需求评审会议亲历记

最近参加了一次需求评审，整理了整个过程如下：评审组构成：由EPG的组长担任评审会议主持人，评审组成员有12个人，6个开发人员，包括项目经理，都是项目组内部的人员，1个测试人员，4个EPG成员,1个外部咨询顾问。准备工作：（1）提前1天发了会议通知，没有为评审组成员准备检查单。（2）有2个人提前进行了准备，阅读了被审查文档，但是只找出了2-5个问题（3）QA提前进行了文档与标准符合性的检

2009-12-08 15:54:00 2531

原创关于需求跟踪矩阵的6个问题

1 需求跟踪矩阵（RTM）有什么作用？（1）在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。（2） RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。 2 需求跟踪矩阵分为哪几类？（1）纵向跟

2009-12-08 15:52:00 2487

原创和需求的提供者达成一致

前几天在客户处访谈,发现在一个项目组的周报中,项目组未计划到的应做的任务比较多,于是叫来了项目助理,让她统计一下,项目组到现在为止,计划外的工作量占计划内的工作量的比例。为了将任务布置的很清楚，我将他们的周报投影了出来，在白板上写下了：（1）周期性的任务不统计进来；（2）统计任务的实际工作量；（3）统计属于本项目组的任务；（4）统计表有三列：周次，计划内任务的工作量，计划外任务的工作量并

2009-12-08 15:51:00 1072

原创需求文档化的真理与谬误

如果是2个公司之间的供求关系,请将需求文档化; 如果是2个部门之间的供求关系,请将需求文档化; 如果是2个小组之间的供求关系,请将需求文档化; 如果是2个人之间的供求关系,请将需求文档化; 这是真理. 再好的合作关系,当发生分歧的时候,也会互相追究责任,在追究责任的时候,请拿出你的依据:文档. 道德是感性的,证据是理性的.道德是合作的基础,但并非有了良好的道德就一定能合作成功,因为分歧并非仅有道德

2009-12-08 15:51:00 1277

原创软件需求评审之道

作者：任甲林　来源：CSAI.cn　http://www.csai.cn　2005年6月13日摘要　　本文介绍了软件需求评审失败的5个案例，提出对软件需求评审的实践具有指导意义的9个建议。关键词　　需求评审，需求层次，阶段评审，检查单，评审流程　　软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有

2009-12-08 15:50:00 2438

原创为什么要进行需求管理？

作者：任甲林　来源：希赛网　http://www.csai.cn 摘要　　本文介绍了需求管理的必要性，并介绍了控制需求渐变的一些方法。关键词　　需求管理，需求渐变，需求复用　　软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把

2009-12-08 15:49:00 2853

原创企业管理软件的需求获取方法

作者：任甲林　来源：希赛网　　　在需求工程中，需求获取阶段是和用户交往最多的一段时间, 而绝大部分用户是不懂得需求分析方法的，他们不知道怎样全面而又准确无误地表达自己的需求，因而对于需求分析人员来讲，需要掌握很好的方法与技巧，恰当地启发引导用户表达自己的需求，以便为项目的成功提供一个很好的基石。一需求获取的2个基本原则 1 深入浅出　　对企业的需求调研的要尽可能的全面、细致,调研的需求是个

2009-12-08 15:49:00 1430

原创风险来源与风险分类的区别与联系

CMMI 1.2的RSKM 过程域的SP1.1为：Determine risk sources and categories，在该实践中明确区分了风险来源与风险分类。确定风险的来源和分类是为了全面、系统地识别潜在风险，合并类似风险的规避措施。风险来源用于在项目或组织内确定风险产生的原因。对项目来讲有许多风险来源，包括内部和外部的。风险来源标识了风险可能发生的常见领域。常见的内部和外部风险来源有：•

2009-12-08 15:48:00 2336 1

原创需求与设计人员如何配合工作？

在软件开发的过程中，经常出现需求与设计脱节的现象，如设计人员按照自己的理解去设计，没有遵从需求去设计系统；需求人员做完需求定义后，交给设计人员去设计，撒手不管了等等，为了使需求与设计人员更好的协作，建议采取如下的措施：Ø 需求人员与设计人员一定要分离，否则无法解决需求文档化的问题，但是文档并不能解决所有的沟通的问题，还需要面对面的沟通。Ø 需求评审设计人员一定要参加，设计评审需求

2009-12-08 15:47:00 1303

原创挣值管理的核心思想

挣值管理是以统一的一个度量单位计算投入、产出，以表示项目的进展情况、预测项目的完工情况的管理方法。通常情况下是以金额为统一的度量单位，在软件开发中，常常以工作量作为统一度量单位。挣值管理中的3个基本变量元：（1）PV（planned value）：计划价值，即计划产出，也是计划投入。（2）EV (earned value)：挣值，即实际产出，当任务完成后，挣值即为计划产出。（3）AC (a

2009-12-08 15:47:00 1374

原创如何管理小型软件项目？

如何管理小型软件项目？这个问题在多个客户那里探讨过多次。所谓的小型项目一般是指估计工作量大于3人月小于9个人月的项目。对于没有实施CMMI的企业，这类项目一般是放任自流，少有管理了，对于实施CMMI的企业，如果这类项目也想要达到CMMI的要求，管理的成本相对投入比较大，难以平衡管理的成本与收益，因此，需要做裁剪。如何裁剪，就是难点。经过与多个客户讨论，最终形成了如下的参考意见。每个企业的特点不同，

2009-12-08 15:46:00 1580

原创两个浪漫的人，一本理性的书

“两个浪漫的人，一本理性的书”是我对《重构极限编程》一书的评价。书买了有一段时间了，浏览过一遍，感觉很受启发。今天是第2遍读，边读边乐边反思。两位作者很浪漫，每个章节的开头，都改编了一首歌曲作为前言；两位作者很幽默，在文章里轻松、犀利地调侃极限编程的缺点；两位作者也很理性，对极限编程的某些优点也进行了充分的肯定。第一次读此书时，只注意了作者的理性，没有去读书里的歌词与调侃，第二遍读时，仔

2009-12-08 15:45:00 1233

原创软件开发经济实用的15条实践

无论是否参考CMMI的模型，在软件开发的过程，我认为如下的15条实践比较经济实用：（1）控制项目组的团队规模不超过10人，人员要少而精。（2）需求文档化，无论大小项目必须清晰的描述需求。（3）采用用例、界面原型描述需求，采用这2种手段强制使需求描述的完备而清晰。（4) 项目的阶段计划与2周计划，阶段计划定义总体承诺，2周计划定义近2周的详细任务安排。（5）逐日跟踪+周例会，每

2009-12-08 15:45:00 986

原创如何保证日志的准确性？

（1）开发一套WEB版的日志系统，只要有网络就可以填写日志，无论是否出差在外。（2）日志系统要操作最简单，员工天天用，操作烦琐了，就没有员工愿意用了。（3）日志系统能自动提醒没有按时提交日志的人员，如果靠QA人员或者PM天天去检查，容易遗漏，也太累啊。（4）日志系统能自动检查有错误倾向的日志，定义几条启发规则，比如1天工作超过了12小时的，低于4小时的等等。（5）在日志系统中，需要填写的

2009-12-08 15:44:00 1171

原创项目里程碑评审的关注点

（1）项目工期情况关键路径是否按计划完成了？如果没有按计划完成：提前或拖期的原因是什么？在后续阶段如何采取改进措施？对后续阶段的工期有什么影响？（2）任务进展情况计划完成的任务情况：计划完成的任务有哪些？提前完成的有哪些？提前完成的任务工作量有多少？未完成的任务有哪些？未完成的任务工作量有多少？（3）工作量投入计划投

2009-12-08 15:43:00 1838

原创为什么要记录日志?

有个小兄弟今天询问我这个问题,于是系统地归纳如下：工作日志记录了每个项目的每个人每天的每个任务投入的实际工作量与完成情况(完成任务的百分比、完成任务的规模，如代码行等)，基于这些数据可以实现：　　（1）统计每个项目、每个任务的实际工作量，并与计划工作量对比，分析人力成本的投入情况；　　（2）分析各种类型的任务在整个项目中的工作量分布情况，任务类型如：需求、设计、编码、测试、配置管理、质量保证

2009-12-08 15:43:00 1438

原创读＜软件工程的事实与谬误＞所得

买这本书,纯属偶然,完全是为它的名字所吸引,随手翻了一下,看了其中描述的几个事实,觉的有收获,值23元,就买了.买了后,一直没有读,频于准备讲课,盯项目. 偶然地,某天顺手拿了这本薄书,读了几个事实,真是好书! 道出了现实! 昨天终于在火车上读完了一书,感触比较深的有下边的13条事实: 1 在软件工程的三要素（人，过程，技术）中，人最重要。 2 最好的程序员要比最差的程序员强28倍之多，而

2009-12-08 15:42:00 894

原创读的感触点

1 开发人员的快乐: 创建事物, 开发对他人有用的东西, 组装的魅力, 持续学习的快乐, 在易于驾御的介质上工作开发人员的苦恼: 追求完美由他人设定目标对他人有依赖查找修改BUG 过时的很快 2 BROOKS法则:向拖期的项目追加人手,只能让项目更拖期 3 设计人员要少而精 4 开发人员如何避免画蛇添足 5 非正式交流,正式交流,

2009-12-08 15:42:00 873

原创目标之痛

作者：任甲林　来源：（希赛网原创）　 http://www.csai.cn 2005年07月25日　　摘要：本文给出了关于软件项目目标错误、目标摇摆、目标模糊、没有目标的 4 个案例，采用反面案例说明了目标的重要作用。　　关键词：关注目标，根本目标，优先级，产品特色　　5 年前读完高德拉特（ Eliyahu M. Goldratt ) 的名著《目标》后，我深受震撼，尽管那

2009-12-08 15:41:00 1079

原创如何开会？

作者：任甲林　来源：希赛网原创　 http://www.csai.cn 2005年08月14日　　看到题目可能大家觉得不值一提，开会？谁不会。可是下面的问题，您可能会经常遇到：　　§ 会议开始的时间到了，会议室仍然被其他人员占用，没有会场地；　　§ 会议开始的时间到了，投影仪无法正确连接；　　§ 需要打印出来的材料没有打印出来；　　§ 与会人员需要在白板上表达自己的思想时，却发现白板笔

2009-12-08 15:40:00 1114

原创软件项目管理的成功原则

来源：希赛网作者：任甲林 1 平衡原则　　在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：需求、资源、工期、质量四个要素之间的平衡关系问题。　　需求定义了"做什么"，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义

2009-12-08 15:37:00 1063

原创项目计划评审时的36个检查点

在多次的运行检查中,发现很多项目的计划存在一些共性问题,根据这些问题,归纳出来36个检查点供大家参考. 1 是否定义了项目的组织结构? 2 是否定义了每种角色的职责？ 3 PPQA是否有独立的渠道和高层沟通？ 4 如果有客户或客户代表的参与，是否定义了他们的职责？ 5 是否定义沟通了机制?（和客户的，和其他外部和伙伴的，内部成员的，和上级的，和其他项目组的） 6 是否定义了

2009-12-08 15:36:00 3193

空空如也

空空如也