software engine homework

The Ten Most Powerful Principles for Quality in (Software and) Software Organizations for Dependable Systems

可靠系统软件组织的十大质量原则

摘要

软件知道自己有问题。解决方案比比皆是，但是哪些解决方案有效呢？我们在成功的项目中可以遵守的最基本的基本原则是什么？这篇文章提出了10个没有被广泛传授的强有力的原则。它们基于测量、量化和反馈的思想。众所周知，我们在“数字”方面的成熟度很低。希望随着我们迈向更高的成熟度水平，我们也将开始意识到思想的度量和数字表达的力量。我们现在能做什么呢？我建议第一步是认识到你们所有的质量要求都可以而且应该用数字来规定。我不是在说“数虫子”。我说的是量化质量，如安全性、可移植性、适应性、可维护性、健壮性、可用性、可靠性和性能。决定在您的项目中将它们设置为数字。今天起草一些数字要求，明天给您的团队带来惊喜

十大原则

1. 使用反馈
2. 确定关键措施原则
3. 控制多个目标原则
4. 循序渐进原则
5. 及时缝一针省九原则
6. 动力移山原则
7. 竞争是永恒的原则
8. 事情需要时间原则
9. 坏事与好事原则
10. 眼睛盯着你要去的地方

1.介绍

与最初的计划和承诺相比，所有项目都有一定程度的失败。太多的软件项目完全失败了。在20世纪90年代中期，美国国防部估计大约有一半的软件项目是彻底失败。民间部门也好不到哪里去。那么，我们可以做些什么来提高项目的成功率呢？本文概述了成功的软件开发方法的十个关键原则，它们是最佳实践的特征。之所以选择这10条最有力的软件质量原则，是因为有实践经验表明，它们确实能让我们控制质量，控制质量成本。他们有真正的过往记录。这一记录经常跨越IBM、惠普和雷神等公司数十年的实践。他们并没有什么“新鲜事”。它们是经典的。

原则1：使用反馈
正式反馈方法的经验已经有几十年的历史了，许多人确实欣赏它们的力量。然而，太多的软件工程师和他们的经理仍然在实践低反馈的方法，例如瀑布项目管理(也称为Big Bang，Grand Design)。太多的人还依靠测试来检查系统的质量，“当天晚些时候”，当他们完成整个系统的生产时。甚至很多教科书和课程继续呈现低反馈的方法。这不是因为有意识地拒绝高反馈方法，而是因为忽视了许多成功的、记录良好的项目，这些项目详细说明了反馈的价值。
使用反馈的方法成功了，没有反馈的方法似乎失败了。“反馈”是软件工程中唯一最强大的原则。(本文中的大多数其他原则实际上都是支持使用反馈的想法。)。反馈通过提供有关实际情况的事实，帮助您更好地控制项目。当然，我们的假设是，反馈的时间足够早，可以做一些有益的事情。这就是症结所在：快速反馈。我们必须有项目时间来利用反馈(例如，如果需要的话，从根本上改变方向)。一些最值得注意的快速高反馈方法包括：

• 缺陷预防流程
  缺陷预防过程(DPP)等同于软件工程学会CMM级别5，就像IBM在1983-1985和[14]中实践的那样。DPP是消除缺陷根本原因的成功方法。在短期内(一年)可以预期减少50%的缺陷；在2-3年内，可以体验70%的减少(与原始水平相比)，在5-8年的时间范围内，95%的缺陷减少是可能的(来源：IBM经验，雷神经验[5])。
  关键的反馈思想是将调查缺陷的初始原因分析活动“分散”给基层程序员和分析师。这会给你真正的原因和可接受的、现实的改变建议。然后，更深入的“原因分析”和“测量的过程纠正”工作可以由更专业、更集中的过程改进团队在截止日期之前的项目之外进行。反馈机制很多。例如，从使用规范的人员那里获得当天的反馈，从过程改进团队那里获得早期的数字过程变更结果反馈
• 检查
  它最初主要关注代码和代码设计中的bug清除,今天，许多人继续以这种方式使用它。然而，近年来，检验的性质发生了变化。今天，通过专注于测量任何软件或上游市场规范的样本区域(而不是处理整个文档)中的主要缺陷级别(软件标准冲突)，它可以更具成本效益地使用[9]。缺陷水平测量应该用来决定整个规范是否适合下游发布(退出)使用，比如‘进行/不进行’决策评审或进一步细化(测试计划、设计、编码)。
  检查反馈的主要组成部分包括：
• ·同事就软件标准合规性向作者提供的反馈。

• ·向作者反馈所需的标准遵从性级别，以便认为他们的工作是可发布的。

• 渐进式项目管理
  自1970年[15]、[13]、[2]、[8]、[10]以来，渐进式项目管理(Event Project Management，EVO)已成功地应用于要求最苛刻的空间和军事项目。美国国防部将他们的软件工程标准(2167a)改为EVO标准(MIL-STD-498，该标准派生出后续的公共标准(例如IEEE))。报告(操作。同上)。我自己的经验是，与传统的项目管理方法相比，EVO带来了卓越的按时交付和预算能力，甚至更好的能力[16]。一个EVO项目被有意识地划分为小的、早期的、频繁交付的、利益相关者关注结果的步骤。每一步都会带来好处，并朝着满足最终需求的方向发展。步长通常为每周或总时间或预算的2%。这就产生了关于团队向选定的利益相关者交付有意义的、可衡量的结果的能力的出色的、定期的和现实的反馈。反馈包括关于设计适宜性、涉众的反应、需求的权衡、成本估计、时间估计、人力资源估计和开发过程方面的信息。

• 统计过程控制
  统计过程控制(SPC)虽然广泛应用于制造业[4]，但实际应用于软件工作的程度有限。在高级检查中发现了一些用途[5]、[18]。计划研究(或检查)法案周期被广泛认为是一种基本的反馈机制。

原则2：确定关键措施

任何系统都是如此，有几个因素可以导致系统死亡。这适用于您的身体、您的组织、您的项目以及您的软件或服务产品。经理们称它们为“关键成功因素”。如果您分析系统，寻找导致缺陷或故障的所有关键因素，您将得到需要更好控制的因素列表。它们既包括利益相关者的价值(如适用性、可靠性、适应性、便携性和可用性)，也包括交付这些价值所需的关键资源(如人员、时间、金钱和数据质量)。你会发现，对于每一个关键因素，一系列的错误，包括

• ·未能系统地确定所有关键利益攸关方及其关键需求
• ·未能以可衡量的方式定义该因素。通常，只使用流行语，没有给出生存失败的指示)和目标(成功)措施
• ·未能定义衡量因素的实用方法
• ·未能针对关键因素进行可测量的收缩
• ·未能为达到因素的临界水平进行设计
• ·未能使整个项目团队意识到关键因素所需的数字水平
• ·未能在高峰负载或系统增长期间维持关键性能的关键水平
  我们关于‘软件需求’的整个文化和文献系统地没有考虑到大多数关键因素。通常，只指定了少数几个，如绩效、财务预算和截止日期。大多数质量因素根本没有定量定义。在实践中，所有关键措施都应该始终使用有用的衡量标准来定义。然而，人们没有接受过这样的培训，经理们也不例外。其结果是，我们定义关键的“分解”性能级别和管理成功交付的能力从一开始就被摧毁了。

原则3：控制多个目标

你没有奢侈品可以随心所欲地管理质量和成本。您不能决定让软件项目只管理几个关键因素，而避免处理其他因素。您必须处理您的项目、组织或系统面临的所有潜在威胁。您必须同时跟踪和管理所有关键因素。如果不是，那么“被遗忘的因素”很可能是项目或系统失败的真正原因。
我已经开发了影响评估(IE)方法来实现对关键因素的跟踪，但它确实依赖于已经确定和指定的关键目标和量化目标。考虑到大多数软件工程师还没有学会定量地指定他们所有的关键因素(原则2)，下一步，跟踪量化目标的进度(这个原则)通常是不可能的。
IE在概念上类似于质量功能部署[1]，但它更加客观和数值。它提供了一幅可以监控的现实图景[8]、[10]。参见表1，IE表的示例。提供IE的所有底层细节超出了本文的范围。简而言之，百分比(%)估计(见表1)尽可能基于来源引用、可信度评估、客观的书面证据。IE可用于在想法应用之前对其进行评估，也可用于(如表1所示)在演进项目期间跟踪实现多个目标的进度。在表1中，“实际”、“差异”和“总计”数字表示对管理层已决定监控的选定关键因素集的小步反馈。如果项目偏离了计划，这将很容易看到，并可以在下一步纠正。

原则4：循序渐进

软件工程本质上是在玩弄未知。如果我们已经完全拥有了我们需要的东西，我们就会重新使用它。当我们选择开发软件时，存在着多种类型的风险，这些风险威胁着软件开发的结果。解决这一问题的一种方法是一步一步地处理发展问题。如果出了问题，我们会立即知道。我们也将有能力退回到前一步，达到令人满意的质量水平，直到我们懂得如何再次进步。
表1。一个IE表的例子。这个项目管理影响表为项目经理提供了不断的现实反馈，基于实现目标的实际措施，以及成本信息

重要的是要注意，这些小步骤不仅仅是开发增量。重点是它们是已确定的涉众需求的增量满足。早期的利益相关者可能是需要工作系统进行演示的销售人员、需要使用某些东西的系统安装人员/帮助台/服务/测试人员，最后是早期试用用户。每一小步的持续时间通常是一周左右。被广泛报道的最小步骤是微软使用的每日构建，这是有用的质量系统。它们累积到6-10周的“可发货质量”里程碑

原则5：及时缝一针省九

必须尽早进行质量控制，从最早的计划阶段开始，以减少后期发现缺陷造成的延误。需要有强有力的规范标准(如“所有质量要求都必须量化”)和严格的检查，以衡量规则在实践中的应用。如果规格不是某个最低标准(如剩余的<1个主要缺陷/页)，则必须对其进行编辑，直到它们变得可接受为止。

• ·使用检查抽样以降低成本，并允许在规范完成、更正和学习之前及早进行。
• ·使用数字退出开发流程，例如“每页最多0.2个专业”
  
  图1.来自Woodward99：EVO的一个优势是您可以专注于尽早向关键的涉众交付高价值增量。上线代表早期的高价值。
  要的是，对于大规格，例如在工作的前10页内，及早进行检验的质量控制是很重要的。如果工作不符合标准，那么可以在浪费更多精力之前纠正过程。我看到半天的检查(基于3页的随机抽样)显示，在40，000页的空中交通管制逻辑设计中，每页大约有19个逻辑缺陷(1986年，瑞典)。同样的经理，他们最初“批准”了逻辑设计,编码在我的帮助下进行了检查。不用说，这个项目严重地迟到了。
  
  在另一个案例中，我协助(美国，1999，飞机部件供应商)8名经理sam-从82页的需求文档中翻出两页，并测量每一页有150个“主要”缺陷。不幸的是，他们在项目开始的三年前没有做这样的抽样，所以他们已经经历了一年的延迟;并告诉我，他们希望在从项目中消除缺陷的同时，再推迟一年。考虑到他们发现的缺陷密度和已知的主要缺陷的平均成本，这两年的延迟是可以精确预测的。他们很惊讶.
  原则6：动力移山
  动力就是一切！当个人和团体没有积极的动力时。他们不会前进。当他们有负面动机(恐惧、不信任、怀疑)时，他们会抵制改变新的、更好的方法。激励本身就是一种方法。事实上，有很多大大小小的项目对你的团队的“动力总和”做出了贡献。我们可以有效地将“激励问题”分为四类：
• ·变革的意愿
• ·变革的能力
• ·变革方向的知识
• ·关于所需变革方向进展的反馈。
  导者(我不是说“经理”)通过给人们一个积极的、有趣的、挑战的以及成功的自由和资源来创造改变的意愿。20世纪80年代惠普(Hewlett Packard)的首席执行官约翰·杨(John Young)激励了他的员工，他说，他认为他们的目标是到80年代末(1980-1989)在服务和产品质量方面提高十倍(“10倍”)。他没有再来一次。他支持他们做这件事。他们失败了。稍微！他们报告说，在这十年中，他们的表现平均提高了9.95倍。在许多其他公司，如IBM的糟糕时期，该公司是健康的，具有竞争力的。改变方向的知识是激励的关键；人们需要将他们的能量引导到正确的方向！在软件和系统世界中，这个问题有三个要素，其中两个在前面的原则中已经讨论过了
• ·各利益攸关方要求和目标的可衡量、量化的清晰度(原则2)
• ·对所有多个关键目标的了解(原则3)·对资源和法律等制约因素的正式认识。这些因素是一个持续的沟通问题，因为：
• ·我们没有系统地将我们的“改变方向”转换成清晰可衡量的想法；人们不清楚目标，也没有能力获得关于“正确”方向移动的数字反馈。我们可能会说，我们需要一个“稳健的”或“安全的”系统；而不太可能将这些粗略的理想转化为具体的、可衡量的、已确定的、商定的要求或目标。
• ·当我们的现实要求我们同时跟踪多个关键因素以避免失败并确保成功时，我们往往专注于单一的可衡量因素(如“建造百分比”或“预算支出”)。我们不知道我们应该跟踪什么，我们也没有得到足够的“丰富”反馈。

原则7：竞争是永恒的

我们传统的项目管理理念强烈表明，项目有明确的开始和明确的结束。在我们这个竞争激烈的世界里，这并不像戴明所说的那样是一种明智的哲学。我们可以有一组无限的“里程碑”或成果交付的演进步骤，并在需要时使用它们；当我们放弃一个项目时，我们就把机会交给了我们的竞争对手。他们可以超越我们的表现水平，夺走我们的市场。

图3.学习和改进的休哈特循环—P、D、S、A循环。摘自W.Edwards Deming 1991年5月18日给作者的一封信
实际结果是，我们的整个心态必须始终放在为我们的组织能力以及我们的产品和服务能力设定新的雄心勃勃的数字“利益相关者价值”目标上。IBM、雷神公司和其他公司[14]、[5]、11在软件和服务领域的持续改进努力表明，我们可以在5到8年的时间框架内将关键成本和性能因素提高20：1。项目必须成为永恒的运动，才能领先并保持领先

原则8：事情需要时间

尽管有错误、灾难、失败和失望，列奥纳多从未停止过学习、探索和实验。他在求知过程中表现出极大的毅力。在他笔记本上的犁图旁，列奥纳多宣称：“我不会离开我的犁沟。”在其他地方，他指出，“障碍不会让我弯曲”，“每一个障碍都是通过严谨来摧毁的。”

图4.质量成本与时间的关系：雷神95-减少返工的8年演变。在雷神过程改进(Dion，1995)的案例中，1000名程序员需要多年持续的过程更改，才能将返工成本从占软件开发总成本的43%降至5%以下

技术管理人员需要有一个长期计划，以改进其组织和产品的关键特性。这样的长期计划需要是数字可跟踪的，并在多个关键维度说明。同时，应该规划、预期和跟踪朝着这些长期目标取得的明显的短期进展。

图5.设计思想对成本和质量影响的评估：A和B是解决方案/策略/设计，我们打算通过它们来满足“质量”(涉众价值)要求的“手段”。它们对许多质量要求和许多成本预算都有影响。条形的长度表示对目标或预算水平的影响程度(用箭头表示)

原则9：坏事与好事

为了正确了解任何想法对于满足我们的目的有多好，我们必须：

• ·对我们的要求、我们的质量目标和我们的资源(人员、时间、金钱)有一个量化的多维规格说明
• ·了解每个设计想法对所有这些质量目标和资源的预期影响·评估每个设计想法对我们的需求的总的、预期的或真实的影响；未实现的目标和未使用的成本预算。我们需要估计对我们目标的所有影响。我们要减少、避免或接受负面影响。我们必须避免简单化的一维论据。如果我们不能使用这一系统工程纪律，那么我们将会遇到延误和质量差的令人不快的意外，这似乎是当今软件工程中的常态。对这些影响建模的一种实际方法是使用IE表(如表1所示)。

原则10：眼睛盯着你要去的地方

手段的完美和目的的混乱似乎是我们这个时代的特征“阿尔伯特·爱因斯坦
要发现问题，我们只需要求说明：“为什么？”答案将是更高水平的规范，更接近实际目的。我们要求的款式太多了！你可能会说，何必费心呢？软件的全部意义不就是编写代码吗？谁需要高级抽象，那就删掉代码吧！但不知何故，这段代码来得太晚，质量也不尽如人意。原因通常是缺乏对涉众和项目真正需求的关注。我们需要这些关于我们的利益相关者需要的高级抽象，这样我们就可以集中精力给他们提供他们付钱给我们的东西！我们的任务是设计和提供最好的技术，以具有竞争力的成本满足他们的需求。总有一天，软件工程师会意识到首要任务是满足他们的利益相关者。他们将学会针对涉众需求(多个并发需求！)进行设计。总有一天我们会成为真正的系统工程师，并会意识到软件工程不仅仅是写代码！

• 1.反馈快，纠错快。
• 2.如果您不关注对您的系统至关重要的几个措施，它将会失败。
• 3.如果您不能同时控制多个质量和成本度量，则您的系统将因未控制的度量而失败。
• 4.你必须朝着你的目标以小的增量或“步子”前进；大的步子失败会扼杀你的全部努力。尽早、频繁地交付结果在政治和经济上都是明智的。财政预算总额的2%只是一小步，如果事情没有按计划进行，你可以承受失败的代价。
• 5.必须尽早进行质量控制，从最早的计划阶段开始，以减少后期发现缺陷造成的延误。
• 6.只有当人们有动力时，“最好的方法”才会奏效。
• 7.只要你在竞争中，永恒的过程改进是必要的。(转述戴明关于PDSA周期结束的内容)。
• 8.改变一种文化需要多年的坚持不懈。
• 9.你选择的任何方法(手段、解决方案、设计)都会对质量和成本产生多重影响，无论你喜欢与否！
• 10.你必须把重点放在本质结果上，决不能成为手段的牺牲品。

2 结论

通过经常给人们数字反馈和自由使用任何解决方案来激励人们走向真正的结果，这会带来这些结果。指定就这么简单。这件事真的很难做到。