软件过程

软件行业导入六西格玛过程中的错误解读，六西格玛在制造业的流水线过程以及硬件过程获得巨大成功，这个成绩让软件行业按捺不住，开始把六西格玛植入软件领域，然而几十年过去了，回头看，六西格玛在软件这块地盘似乎并没有给我们带来什么拿得出手的斩获。 那么六西格玛的植入真的是个错误么？非也！目前六西格玛在软件行业的尴尬处境很大程度上源于对其的错误解读，我这里列举了一些常见的错误，和大家一起解析。 误解1：六西格玛仅能度量缺陷密度 软件组织在实施六西格玛项目时，会被三个基本问题所困扰：“如何计算西格玛？”“什么是缺陷（defect）？”什么是机会？”因为有数据，许多软件组织仅仅用缺陷密度作为西格玛度量。他们忽略了一个简单事实：缺陷密度只是开发过程中的度量，并不等价于用户使用软件产品的满意度。如果缺陷密度等过程中的度量不能和最终用户使用挂上钩，那么这个度量意义不是很大的。 误解2：只有具备CMMI高成熟度的软件组织才能使用六西格玛 这个误解主要来源于对六西格玛理解的局限，其实当你了解了六西格玛的精髓，你会发现它和CMMI1.3的GPs和CMMI2.0的II和GOV也有密切关系，正如前面讲的六西格玛的Enabling Project。其实六西格玛的许多理念、原则、方法可以帮助到任何级别的软件组织。 误解3：六西格玛仅仅是统计技术的使用 六西格玛（西格玛- 统计学中的标准差）的名字是造成误解的原因之一

本文是个人对于UT的一些想法和总结，参考时建议请查阅官方资料。 转载请注明出处：http://www.cnblogs.com/sizzle/p/4476392.html 测试思想 编写UT测试代码，通常是为了达到下面几个目的： 在程序可以运行前确认部分模块的正确性。 实行自动测试，减少人力成本。 增加测试手段，降低bug到下游的概率。 明确变更代码时产生的影响。 但是在实际的开发过程中，UT做成后很难达成以上目标，反而会产生一些副作用： UT代码难于编写导致成本增加。 使用UT检测出的bug量少，甚至在初期检测出的bug都是UT编写错误而引入的无效bug。 以上问题发生的原因是开发人员在设计和编码时没有考虑可测试性，导致UT容易发生弊大于利的情况。 在设计和编码时充分考虑可测试性，需要具备丰富的测试经验，而且难于达成，因此产生了”测试驱动开发“（Test Driven Development，简称TDD）。 TDD的测试做成过程很简单，基本可以概括为以下步骤： 根据需求和接口式样书编写测试代码，验证接下来编写的功能代码是否满足期待实现的需求点（此时的测试结果是NG）。 编写功能代码。 确认测试结果，如果NG需要修改功能代码或测试代码，如果OK则从1步骤开始实现下一个需求点或完善功能代码。 总之，TDD过程就是先写期待实现功能的测试代码，然后实装代码使测试通过的。当然

　　读Inside Steve’s Brain后，内心里溢满的是对Jobs本人的无限崇敬，他光辉耀眼，带领跟随者冲破黑暗。而读《梦断代码》时，感觉这是一艘载着人类梦想的航船，有着强大的风帆和孔武的水手，但终是没能远航。最后搁浅在海滩上，给后来者无限的宽慰和警示。 　　我本人没有太多软件开发经历，但也十分懂得软件开发的艰辛和困难，所以在听到“为什么就是不能像造桥那样造软件”的呐喊时，来着灵魂深处的触动和震撼，宣泄了自己在过去软件开发过程里的所有委屈和无奈，做软件太难。 　　关于Chandler项目本身是否有决策失误，对于我这样的小人物不敢有过多的评论，这里拾遗了一些自己比较有感触的部分，结合眼下自己团队正在进行的Team Project做一下简单的分析。 　　规格说明，这在实现环节里显得非常重要，它将需求——软件开发者的客户提出的目标或愿景——翻译成指挥程序员的详细行军指令。而“根本没在规格说明里写出”这好像是每个遭遇阻碍的软件项目不可避免会遇到的问题。在我们的Team Project中，需求大多都是自己臆想的，只真正调查过2个用户（这显得相当的不足），而如何把调查的用户的需求转化成我们的开发指南，并细化为具体的步骤，再按责任分到dev的手中，显得极为重要，这也就真正体现了团队协作开发的能力。 　　我们的项目是一个时间驱动的软件开发过程，软件的开发周期是2个月

最近在整理部门内部的培训材料，希望通过培训和在项目中的实践来提升整个团队的分析和设计能力，同时也是自己所了解的一点知识的总结。 谈到软件开发，一个项目的成败，关键因素是人的因素，人就是一切，或者说几乎是一切。对于项目的成功来所，项目人员的素质、人员的组织和管理是比其它工具或技术方法更重要。团队质量直接决定项目的成功和失败，团队的沟通能力，协作能力尤为重要，一个高效的团队一定是沟通能力很强的团队，我们所从事的软件项目，其实不是在研发新技术，而是利用别人的研究成果而已，只是成果的应用，说白了没有什么“纯”技术含量，这里纯加了引号，如今是个知识爆炸的时代，互联网高度发达，你需要什么信息，只要有时间，一般都能找到相关内容。所以说软件项目的开展，更侧重于社会性，而不是科学性。软件开发本身是一个复杂性活动，著名的“没有银弹”中介绍过，复杂性是软件开发的根本属性，短期内不会有任何的工具或方法会使软件生产率有数量级的提升。它是一个复杂的纯思维的活动，这个世界同时又成千上万个软件项目在开展，但是没有任何两个是完全一样的。相同的功能，可以有上百个实现，一个功能，可能用一个类实现，也可能5个、10个类，但是为什么是5个类，而不是3个，没有定型的优劣之分。只有掌握了合适的方法，总结前人的经验成果，研究较好的或经典设计，并在项目中实践应用，才能逐步提升自己的能力水平。 我们以往的项目中存在的问题