常识软件工程–第一部分：初步计划分析

从瀑布式开发到DevOps，有许多运动在努力推动软件编程效率的提高。但是，并非所有人都能将开发人员从压力下解放出来，以更快地交付结果。

自从2000年代初期出现极限编程（XP）以来，软件专业人员一直在尝试寻找新的方法来开发质量更高的应用程序，这些应用程序在越来越紧迫的期限，较小的预算以及资源日益减少的情况下进行。这些努力的大部分推力是由于当时将内部人才外包给价格较低的外国公司的新商业风潮所带来的越来越大的创伤而给IT组织施加的压力的结果。从真正的意义上说，专业软件开发社区（尤其是在美国）所遭受的创伤促使人们越来越多地避免采用成熟的策略，以便满足在同样的生产压力下却没有勇气进行管理的技术管理。情况不断恶化。

XP开发范例是第一个尝试减少实际项目开发基础的制定工作，其中包括初始计划分析，需求分析，设计过程分析，进度分析以及由于计划风险分析而进行的适当项目调整。想法是，由于新的微型计算机开发过程而越来越多地完成了一些项目，因此可以继续以代码优先结构来实施项目，而代码优先结构仍然困扰着当今的许多IT组织。确实，XP并不打算消除所有这些基础，而只是降低它们的重要性，而忽略了它们对高质量软件开发的关键应用程序的现实。

在XP之前，所有软件开发都是在标准的“瀑布”过程中完成的，通过该过程设计了主项目设计，并适当地计划，分析和设计了每个步骤，然后实施了这些步骤，而每个阶段所需的调整和缺陷都很简单通过循环回到某个阶段的初始起点，更正问题然后再次进入该阶段来解决问题。在大型机时代这是一个耗时但最终成功的过程，并且成功地进行到了微型计算机发展的初始阶段。

不幸的是，最初制定最终XP范式的尝试经历了成功与失败的bag贬不一，最终使该项目被取消，而XP则失败了。在新兴的微型计算机领域中，这都不是那么受欢迎。在许多人看来，它只是一种忽略经过时间检验的开发过程的方法。而且它包含配对编程对许多信息技术领域的资深人士来说意义不大。

尽管如此，当时的专业人员仍在通过XP尝试推广的基本概念来寻求方法，以定义新的软件成果。管理层（无论是技术人员还是非技术人员）间接地帮助了这一过程，最终消除了许多组织中的业务和系统分析人员层（也是由于大量外包以及声称有必要降低成本的说法），但没有根据开发人员除了可以掌握其技术技能外，还可以吸收此类专业知识。

敏捷和DevOps

这个过程最终导致了敏捷开发范例（在某些情况下将包含XP概念），在过去的几年中，一些组织现在正在让步，转向其概念的更企业版本，现在称为DevOps。这种新的结构是尝试将开发和运营更紧密地集成在一起。但是，这已经通过诸如ITIL（信息技术集成框架）之类的经过更长时间测试的较早框架来完成。不幸的是，现在有这么多年纪更大，更高级的专业人士离开了该行业，几乎没有什么可以帮助年轻员工适应这样成熟的过程，使他们相信自己正在用自己的解释创造新的东西。

敏捷和DevOps追随者都制定了自己的宣言，从本质上讲，这意味着这种范例既具有意识形态，又具有技术性。这种说法本质上比实际的可靠软件工程实践更具意识形态意识，这可以通过开发商开发新工具来适应他们的需求来证明，这些新工具可以适应它们的使用，并且背后隐藏着越来越多的“运动”，而这些运动通常非常在他们的支持中发声。尽管未必一定将其设想为某种意识形态，但阅读许多推广这些范式的文章可提供充分的证据，表明实际的意识形态涉及此处。

相反，软件工程本身已经制度化，几乎没有任何声名狼藉的团体在鼓励在IT组织基础结构中使用它。它的实践涉及的原理，实践和过程各不相同，并且包含许多可应用于任何类型的软件开发工作（无论大小）的功能。这些功能还包括与敏捷所吹捧的流程非常相似的流程。

软件工程的实践基于对开发范式和项目分析的多年研究，后者包括成功和失败的项目以及与之相关的因果关系。结果就是为软件开发专业人员提供了度量分析，例如与成功的过程改进范例，CMMI或“能力成熟度模型集成”一起推广的度量分析，可用于软件开发工作。通过度量分析，可以建立数学基础来正确分析和预测任何项目工作的期望。

尽管CMMI不直接与软件工程相关，因为它还必须在一般业务和其他技术流程（例如库存管理）中实现效率，但它确实提供了允许将软件工程分析与已证明的开发项目正确集成的流程随着时间的推移，以确保最短的开发进度在预算之内，同时消除缺陷，使某些项目可以声称生产中的零缺陷可交付成果。

不幸的是，这两个非常成功的流程环境都与大多数业务和技术管理背道而驰，以至于两者之一的实施对于它的从业者以及想要从事学习和后续集成工作的人来说，通常都是一场艰苦的斗争。这种对实用软件工程范式的明显拒绝基本上被认为是违反直觉的，这基本上植根于软件开发经理和他们自己的主管的心理中，他们通常更愿意满足难以捉摸的期限而不是产生实际的质量。

尽管敏捷和DevOps范式似乎比其他任何事物都更具文化理论，但两者都已成功实施，并且有度量标准可以证明这种成功，但涉及的专业人员更有可能实际实施了完善的软件工程方法和/或过程管理技术，而不是与这些新技术化身中的嗡嗡声和炒作实际相关的任何东西。毫不奇怪，如果您要去软件工程学院 ，将会发现在该组织所做的研究中提到了敏捷，但在预期的情况下却没有。相反，您会发现Agile从属于实际的软件工程实践。

简单地总结一下；除了如何开发高质量软件外，您不能开发高质量软件。您可以更改处理方式的范式，但是如果它不包含将产生可交付成果的必要构造，则范式本身并不会带来太大的意义。取而代之的是，人们经常吹嘘Google等成功的公司如何投资和使用诸如Agile之类的新架构，现在它已成为DevOps的最新企业化身。但是，没有标准软件工程实践中的合理概念，诸如Google，Microsoft和其他公司之类的高科技公司就无法生产其高质量的产品。但是，这些组织并没有完善的软件生产记录，实际上遭受了严重的失败，表明在这些非常成功的实体中甚至有些不对劲。但是，对于他们的优质产品，他们的开发范例可能被称为软件工程以外的东西，但它们仍然仅仅是这样。任何认为否则的人都只是在自欺欺人。

敏捷已经试图纠正XP的原始缺陷，但是在许多IT组织中似乎都采用了XP，但是它并没有采取很多措施来弥补这一缺陷。在这样的组织中，它仍然可以“忘记要求和设计，只需要编写代码……”。

初步计划分析：两个基本概念

无论您称其为软件工程还是其他专业，成功的初始计划分析都必须是任何新项目或新任务的第一阶段。忽略其至关重要的意义是最终确保一定程度的项目失败。为此，然后我们可以理解为什么如此众多的软件尝试继续以大约70％的高比率失败，而这仍然是IT行业的总体项目失败率。

许多人指出，在所有技术专业人员中，我们的专业仍然是唯一从未真正成熟为具有确定的标准和流程以生产高质量可交付成果的专业。这直接归因于以下事实：年轻，后代的新专业人员仍在尝试寻找神奇的灵丹妙药，使他们能够在技术和业务管理制定的日益不可能的情况下创造优质产品。鉴于目前的趋势，人们会期望在将来的某个时候，该行业会出现系统性的彻底失败，因为对这种公式的徒劳的搜索仍在继续，因为对任何高质量软件产品的创建速度都存在一定的限制。

应当指出，从软件工程的角度来看，项目失败不是全部或全部的构造。如果未满足计划项目的任何方面，则将导致此类项目失败。因此，如果一个项目超出预算，不能满足规定的要求，不能满足预定的期限或仅在处理过程中出现缺陷，则该项目将被视为统计失败。这种构造的结果是，在失败的领域中，不必考虑某个项目是不可使用的。但是，实际上很多事实都是这样。

合理的初步计划分析必须在目标用户和开发人员之间开始，并且要有两个基本的理解……

1. 项目预期目标

2. 用户希望控制的整个项目的各个方面

相信或不了解新项目或任务的预期目标对于其成功至关重要。因此，理解这种概念还将定义项目的预期范围。因此，最终为此目的而计划和设计的一切都将受到这种约束。没有这样的限制，开发团队就无法进行准确的计划和实施阶段，因为在这种情况下，该项目只是开放式的以适应需求。

不幸的是，大多数项目已经并且仍然是开放式的，期望代码库应尽可能灵活以包含必要的新要求。然后，这种类型的项目设置将向技术经理开放，在某些情况下，开发人员将首选“如果...怎么办？” 思考的场景。雄心勃勃的技术经理或技术人员经常提倡这种情况，他们希望其项目易于扩展，以便可以添加任何内容。这些人员认为，所有代码都应该是可扩展的，并且在许多情况下是通用的，因此从字面上可以像傻瓜一样模制。这种思想是许多软件项目所遭受的神奇思想的根深蒂固的一部分。

一方面，人们只能现实地规划已知的要求，同时要注意是否可能包含特定过程的变化，例如数据的导入。在项目的后期阶段，可以在可能添加的范围内考虑某些过程。但是，这里也有必要在某种程度上将这种定义包括在内。说一个项目可能需要通过MSMQ导入过程数据的能力实际上并没有说什么，因为即使在这里也需要精确的计划。

但是，由于开发团队无法专注于已知需求，而不得不在已知与未知之间进行分配，因此，这样的项目是最终项目失败的良好候选者。如果您实际上可以聘请可以预测未来的人，那将是一个不错的技巧。这种开放性思想的结果是，一个简明的项目无法成功地计划和实施，以实现质量的完成，因为项目的范围经常定期更改，从而迅速引起“功能蠕变”，这是遭受其后果的许多项目的祸根。

但是，有许多成功的项目实际上都在计划可扩展性，但是这种能力是已知的或预期的因素，将被包含在项目生命周期的后期阶段，这些阶段通常包括过程中的主要完成里程碑。因此，例如，如果期望应用程序从许多来源接收可能的导入输入（即CSV文件上传），则可以采用以下方式设计将负责此类过程的代码部分：添加新模块以合并新的模块。导入过程遵循易于识别的实施模式。但是，对于有多少技术经理没有为这种情况做计划，而是宁愿考虑“异想天开的思想”作为对项目开发的适当要求，您会感到惊讶。这种想法通常属于“也许”类别。

上面提到的第二项实际上是任何项目成功的最重要基础。这是初始项目计划的一部分，用户和开发人员都将决定用户需要和/或倾向于控制项目的哪些区域才能满足其成功实施自己的需求。但是，无法向用户提供完全控制权，否则项目将失败，因为开发团队将永远无法对可用于其自身设计过程的项目范围施加合法约束。同样，允许用户控制项目的整个过程只会使其经受“特征蠕变”的持续有害过程。

软件权衡三角

当开发人员与用户或用户团队会面时，提出项目计划这一方面的最佳方法是向他们展示“软件折衷三角”图片。

为了使项目成功，在整个项目生命周期中，软件三角形的三个组成部分必须连续保持平衡状态。如果不平衡，则开发人员和用户必须就如何重新平衡达成一致。项目越复杂，随着努力的进行，保持三角形的平衡水平就变得越关键。

同样，只能允许用户控制三角形的三个方面中的两个。因此，如果用户要控制产品和成本方面，则开发团队将定义项目进度表。如果用户只需要控制三角形的“产品”方面，则开发团队可以提供“进度表”和“成本”组合，从而允许用户选择最适合其需求的组合。

为了阐明三角形的三个组成部分，我们将它们定义如下：

• 进度表–成功完成项目所需的估计时间

• 产品–假定产品具有所需的功能和质量

• 成本–分配给项目的预算和资源

如果用户坚持对项目的各个方面进行全面控制，则开发团队必须通知用户该项目将无法成功完成。

一旦了解了项目的主要目标并且由谁来控制项目的哪些方面，便会启动一般项目范围，以便可以开始实际需求分析。

一言以蔽之

在最初的计划会议中，开发人员通常为用户提供生产级产品的交付估算。用户和技术经理都认为，由于可能已经定义了项目目标，因此经验丰富的开发专业人员也可以提供要交付的估计目标数据，然后将其作为实际交付日期。没有东西会离事实很远。

估计问题就是他们就是那个；在此类会议上，充其量只能根据一般性进行有根据的猜测。甚至是有根据的猜测也将这个概念延伸得太远了。在项目计划过程的如此早期阶段就可以要求人们提供任何准确度的估计的想法，是由许多在管理高质量软件开发方面没有实际经验的技术经理推崇的一种观念。它使他们对自己的业务用户和主管看起来很好，但是这种感觉通常是短暂的。当项目认真开始时，任何这样的估计都将很快被发现是完全站不住脚的，这随后使技术经理处于共同的位置，要求不合理的加班时间向开发人员施加压力，迫使他们制定没有计划支持的截止日期。

统计中已明确证明，在此过程的早期阶段，估计的现实时间对于项目完成所需的时间太长或太短。如下图所示，这种估计的不准确性可能高达16倍。尽管此信息是20年前定义的，但它的统计基础仍然与当今的项目相关，因为提供时并没有真正改变不支持的项目估算。

所有项目时间表，无论如何计划和定义，都遵循详细的进度，从而使开发人员可以提供越来越准确的目标日期。这种描述准确的完成日期的分阶段过程还具有以下优势：通常在最短的时间结束时，指定的项目本可以以高质量的结果交付。注意上图中的部分，开发人员可以提供一个阶段到估计到实际完成日期的估计过程，这将使他们在完成这样的完成日期时比尝试遵守初始估计要灵活得多。如图所示，随着更多的设计数据被纳入计划过程，完成日期预测的准确性将提高。

为了在最初的计划会议中避免这种情况，无论哪一方控制软件权衡三角形的组成部分，开发人员都应主动避免提供任何此类不受支持的估计。相反，最好的做法是通知用户，在对初始需求进行了适当的分析之后（无论何时完成了初始产品需求），都会向用户提供一个“评估包”，但需注意的是，这仅仅是一个基于到目前为止已知的有关该项目的信息的初始估计，以及两个，随着计划的进行，估计将发现实际上在缩小而不是扩大。

这样的“估算包”将基于实际项目要求和提供估算时已知的数据。但是，只有在已为项目提供了所有要求并且开发人员可以分解项目中每个组成部分所需的各个时间表时，完成数据计划的现实才有实际意义。

在生成该分析级别之前，可以预期所有此类估计都不过是预期项目何时完成的一般预期。再次，此类初步估计仅是任何经验丰富的开发人员的最佳受过教育的猜测。

在本系列的后半部分将充实准备反映实际组件时间轴分析的此类估算程序包的细节。但是，为达到这一点，我们首先必须研究项目设计的第一个关键方面，即需求分析。在这个阶段中，将提供项目的许多基本设计数据。