采用6sigma提高软件质量

在谈到了我们与印度的差距，其中我认为值得考虑的有2件。1是印度软件质量实现了6 sigma，也就是说每100万行代码只有3.4行错误，我们如何达到甚至超过印度软件的质量。2是印度软件质量依靠与软件的重用，我们如何提高我们的软件重用度。

软件质量

我认为一个成功项目的评定标准有3个：1准时，2保证质量，3满足客户需求。目前软件开发团队存在的最大的问题就是在规定的日程内无法保证产品的质量。我想我们需要更多的时间来讨论如何保证日程和质量。

我们现在有很多未知缺陷隐藏在项目开发中，我总结了各个项目评估。项目评估的大多数内容都是正面的，但我对项目评估的等级划分有所担忧。评估的结果可能隐藏着没有被察觉问题。如果评估的每一项都分为：非常满意，满意，一般，不满意，和非常不满意，五等级。这样的评估，对于不同性格的评估者会做出不同的结果。例如，性格温和的人将不满意的项评为一般，等等。项目评估是我们重要的客户反馈信息。我们必须认真对待。如何评估的项目有不满意，则都会得到我们的重视，但如何评为满意和一般，其重视程度就会下降。得来的重要反馈信息将会被忽视。所以我认为评估标准为满意和不满意两项即可。对于不满意的项目，希望客户能多提宝贵意见。
在项目评估中，客户的建议和意见多出现在项目管理，技术，成果的质量，语言几个方面。这些方面几乎涵盖了项目开发的所有阶段。那么我们如何发掘问题的本质和改正，改进项目开发的流程。我阅读了《6σ管理法》[1]一书，书中将质量改进分为以下几个阶段[1]。
定义-评估-分析-改进-控制
我认为它同样适合我们找出问题的根源。

1. 定义客户需求 首先我们要了解并追踪客户的需求和他们的态度。可以通过项目评估系统收集客户反馈信息。但目前项目评估系统没有足够的反馈信息，并且似乎没有使用这些反馈信息。只有当我们分析客户反馈数据并据此采取行动之后，顾客反馈数据才是有用的。
   调查客户的需求和行为后，撰写需求说明。需求说明是绩效标准简洁而全面的描述。
   例如：需求说明
   在项目开发过程中，使客户满意的因素是：
   1）懂得编写客户需要的各种文档；
   2）文档提交后的返工次数在1次以内；
   3）客户测试成果时出现的Defects在10个以内；
   4）按规定的schedule内完成成果；
   5）程序员具有在1天内解决2个以上Defects的能力；
   6）语言水平达到2级以上。
   需求说明首先设定合格需求说明或绩效标准的目标。接着应当做到如下几点[1]：
   1．保证需求说明与项目相联系。
   2．描述单个的绩效标准或因素。应当清楚描述客户需求的是什么或他们要进行评估的是什么---时间，成本，质量。
   3．用可观察的因素来描述客户需求，或者用可评估的因素来表述客户需求。应当将任何一个客户需求，努力转换常可观察的东西。
   4．设定产品或服务绩效的“可接受”和“不可接受”标准。
   5．需求说明应当与客户反馈相称，或者由后者决定其有效性。写需求说明是最重要的事情是：说明或具体需求应当满足客户的需求或期望。流程内的每一个需求应当能和外部客户的需求保持一致。
   定义需求说明后分析客户需求并对其排序。显然客户的所有要求并不是同等重要，对于每一个客户来说，其要求没有被满足时，不同客户的反应也不是天生一样的。我们可以把客户的需求划分成三种类型：
   1．不满意状态或客户的基本需求。客户认为绝对需要满足的需求包括一些因素，这些因素具有一些特征，表现为一定的绩效评估标准。如果满足了客户的这些需求，还不能说取得了“额外的信誉”；如果没有满足这些需求，客户绝对不会满意。例如：懂得编写客户需要的各种文档；按规定的schedule内完成成果。
   2．满意状态或者可变需求。在这类需求上，做的越好（坏），客户对公司的评价就越高（低）。最常见的是成果的质量。成果提交后的返工次数越少，客户的满意成多越高。如果我们能保证基本需求，那么，每一项流程改进活动就应优先集中精力于提高公司在质量提高上的能力和绩效。
   3．高兴状态或潜在需求。我们的成果的某些特征或因素会超出客户的期望值，或这些因素特征是以没有人提出过的需求为目标取向的。例如：我们为客户开发的某个功能的性能比原系统性能提高了200%，某一个Batch Job运行时间减少到原系统运行时间的1/3等等。
   另外在定义需求说明是我们还要注意：
   要建立一个范围较大的收集及使用客户信息体系。在这一点我们需要考虑是否改进客户的反馈系统，使其能收集更多的信息。
   要尽力编写出清楚的，可评估的，相关的需求说明。
   不要不跟踪，不评估公司针对客户需求的绩效。
2. 评估公司当前绩效 本阶段的核心内容是评估目前的绩效。评估步骤的主要任务有两个要点：
   1．对比客户对产品和对公司服务方面的需求，评估公司业务流程的当前绩效。
   评估公司业务流程的当前绩效首先要完全认识清楚客户是如何评估公司的产品和服务的。我们的客户根据以下因素来评估我们的产品和服务：
   1．项目管理方法；
   2．技术能力；
   3．产品和服务的质量；
   4．项目范围管理能力；
   5．态度。
   那么平衡评估量的切实可行性和评估量的价值/有用性，可总结评估对象为：
   1．每个阶段所需时间，延期时间；
   2．各种文档的返工次数；
   3．各个阶段的Defects个数，原因；
   4．测试阶段的Defects个数，原因；
   5．解决一个Defects的时间。
   2．通过识别有关公司流程优势，劣势的资料，得出有效的评估结论。
   目前公司中可用的资料很多，例如：CMMI Defects文档等等。但是，要保证我们选取的来源可以提供准确的资料，并且能够代表我们想评估的工作流程，产品和服务。所以CMMI的文档（撰写过程中有保证其完美性的嫌疑。）是不能作为评估资料的。获得这些评估对象的数据需要我们所有公司同僚的共同努力和认真对待。
3. 分析问题 我们需要对数据分析和对流程分析。
   数据分析：利用评估量和有关数据（已经收集的数据或在分析阶段收集的新数据）来分辨问题模式，问题发展趋势或其他一些有关因素，不管这些因素是推测出来的，还是证明/未证明的可能原因。
   流程分析：深入调查并领会工作如何开展，从而辨别不一致的，不相关的或可能引起问题发生或导致问题发生的某些领域。
   根据数据分析编写原因的草稿：
   例如：
   1．编码阶段经常延期是因为编码阶段所规定时间太少的原因，而测试阶段的延期是因为编码没有完成而造成的连锁反应；
   2．文档返工的原因是没有在提交之前作有效的审查工作；
   3．编码中的Defects引起的原因是马虎，没有经验，没有编程规范等；
   4．Defects多出现的问题原因可分为：人为因素，技术问题，业务逻辑问题，开发标准问题。
   绘制流程图进行流程分析：
   流程图是最重要的一种方法。在流程图中，绘图这关注的主要焦点是改进，设计，评估和管理流程。流程图的基本要素很简单：一系列任务，决策点/检查点，工作流向。在绘制流程图时，可能会发现：最有启发性的信息确实来自“绘制流程图”阶段。当一个流程被记录下来并被有效确认之后，就可以分析一下一些特殊的问题领域：
   不一致性。指交接工作做得不好。或者与客户没有很好的交流需求。
   瓶颈。瓶颈指流程中某点的工作负荷大大超过此处的处理能力，从而延缓了整个工作流程的进度。例如：编码阶段和测试阶段。
   冗余现象。冗余现象指在流程的两个地方重复做的事情，也可以指两项产生同时结果的具有相似性的活动。
   返工周期。返工周期指产品需求在流程中加以修理，更正或修补。例如：文档的返工，代码的返工。
   决策点/检查点。指流程中的某些点，在此处，人们将做出选择，进行评估，检查或积极干预流程活动（会产生可能的延误）。
   分析阶段的注意事项：
   1．要详细阐述因果假说。
   2．要对假说持怀疑的态度。
   3．要运用尝试和创造力。
   4．不要把分析工作做得过细。
   5．不要分析不足。
4. 改进，提出、选择并实施解决方案 解决方案说明。解决方案说明是一份清楚表述改进活动的建议性文件。解决方案说明的价值在于：它能使人们对正在考虑中的各种建议有一个全局的概念和把握。
   例如：
   1．解决文档返工问题：制定文档审查标准，根据CheckList进行自我审查和上级审查。
   2．解决编码延期问题：在设计阶段将部分已清楚的子模块提前进入编码。在设计阶段的初期就定义好界面的风格规范。
   3．编程出现的Defects问题：制定编程标准。制作自动标准审查软件。
   4．Defects的问题：敢于发现并记载错误(Defects)。不能回避错误，或不能有避免提出Defects的观念。越多的发现错误就越能有助于提高我们的质量。
   改进阶段的注意事项：
   1．要寻找真正具有创新性的改进方案。
   2．要把目标指向你的解决方案。
   3．要实现做好细致的规划。
   4．不要从开始就全面实施（方案）。
   5．不要忘记进行评估。
5. 持续改进 提供连续的评估量和措施以支持改进。为解决方案建立强有力的支持。
   要做好文件记录以支持新流程。
   要选择一种评估两间的平衡搭配来检测流程绩效。
   要编制传递信息间接迅速的评估报告。
   要准备流程中一旦产生问题时的应对计划。
   不要对文件记录弃之不用。
   不要忘记流程图的存在。

定义-评估-分析-改进-控制的方法来源于6σ，但不管其名称如何，其目的是让我们能够准确地找到并且根除潜在的问题，使我们的软件达到无缺陷。我认为提高软件质量到无缺陷的水平是我们永恒的目标，因此我们需要用一种可行有效的方法帮助我们逐步靠近这个目标。

软件复用

如何提高软件开发进度和质量？目前一个热门的话题就是使用可重用的组件。印度通过使用可复用组件。成倍提高了其软件开发的速度和质量。那么我们为什么没有大量的使用可复用的组件呢。

1. 软件重用的困难在哪里 目前我们存在一些困难阻碍了我们使用可复用的组件。
   1．一切重头开始的习惯
   首先现在我们还没有现成使用可复用组件的概念。大多数的程序员都习惯于重头开发，从无到有的过程。这是一个观念问题。要想普遍软件重用的概念先要让所有人习惯软件重用的观念。具体地说就是，软件开发时的第一意识是寻找已存在的组件来实现需求。
   2．不知道到哪去找组件
   寻找需要有场所。我们现在还没有存储可复用组件的场所。所以我们必须先要建立一个组件库。
   3．没有可重用的组件。
   有了组件库，我们就可以将组件存储在组件库里。但是，如果组件库里没有足够的组件，那么我们就找不到我们想要得组件。解决这一问题需要我们所有人的努力。我们要采用面向对象的方法，在开发软件时以可复用的组件为单位，并及时将开发的组件存入组件库。
   4．即使有也不敢使用-质量
   有缺陷的组件是不能使用的。因此在组件库中的组件必须经过质量的审核。
   总之，解决以上问题的方法就是采用组件库管理系统和软件重用的观念以提高软件的开发速度和质量。
2. 开发组件库管理系统迫在眉睫 关于组件库管理系统的开发建议，详见技术人生之我的硕士论文。
   中国软件业已经错过独立开发操作系统的年代，又错过独立开发数据库的年代，不能再错过软件重用的年代。