第1章 基础知识

本书主要介绍一个软件项目开发过程的案例。软件的开发过程需要软件工程和项目管理两门知识作支持，这两门知识对做好软件开发具有非常重要的指导作用。因此在正式讲解开发案例前，本章简单地介绍软件工程和项目管理，以及如何通过对二者的标准化来提升软件开发的质量、价值和效率，主要介绍如下5个内容。

（1）软件开发：定义软件开发过程、需要的基础知识以及常见问题。

（2）软件工程：软件工程的构成、作用、常见问题等。

（3）项目管理：项目管理的构成、作用、常见问题等。

（4）软件的标准化：解决软件工程和项目管理的标准化方法。

（5）标准化与项目管理目标（质量、进度、成本）的关系。

1.1　软件开发

首先定义软件开发的过程、阶段划分、每个阶段所需要的基础知识、存在的问题和对策等，让读者对软件开发有一个清楚的认知。

1.1.1　软件开发的过程

一般来说，一个软件的全生命周期大体可以分为3个大的阶段：①前期准备阶段；②开发实施阶段；③后期运维阶段。各个阶段包括的步骤和内容简述如下（根据软件公司、项目内容以及规模的大小等不同会有所差异，仅作参考）。

1.前期准备阶段

从销售员跟踪项目的活动开始，直至正式的需求调研开始前，这一阶段属于前期的准备阶段，包括以下步骤。

（1）售前咨询：售前咨询主要是初步收集客户高层对新建系统的需求（包括理念、目标、价值、期望等）、客户信息中心的基本情况，了解与竞争对手的差异，向客户宣传软件公司的理念、主张、本公司产品的优势，提出针对客户需求的解决方案等。

（2）项目立项：根据已获取的项目信息、客户需求等，对项目的目标、时间、成本、技术、竞争对手等进行多维度的可行性分析后，软件公司作出是否参与该项目的决定。

（3）合同签订：通过一系列的咨询和商务活动后，软件公司与客户签下软件开发的委托合同，确定待开发系统的范围、开发工期、合同金额、交付要求等。

（4）项目准备：签订合同后，做项目启动前的准备工作，包括确定项目组的经理和成员，编制实施路线图、里程碑计划、执行计划、《工作任务一览表》等。

2.开发实施阶段

从进入客户现场进行需求调研开始，直至系统交付、合同验收为止，都属于开发实施阶段，包括以下步骤。

（1）需求确定：开始正式的需求调研，经过需求收集、需求分析、需求确认等一系列活动，最终确定必须要开发的《功能需求一览表》以及《需求规格说明书》，这些文档是后续设计和编码工作的输入，以及客户最后进行合同验收的依据。

（2）软件设计：根据《需求规格说明书》等文档进行设计，包括概要设计和详细设计（含业务和技术）。设计的对象包括架构、功能、数据等。最终交付《设计规格书》，它是后续编码和测试的依据。

（3）编码实现：基于《设计规格书》进行编码工作，建立数据库、系统架构，逐一实现系统的功能，包括界面、算法、接口等。最后按设计要求完成系统。

（4）测试验证：检查完成的系统是否符合设计要求，测试分为模块测试和整体联调，通过测试确保系统准确无误，最后生成《测试验收报告书》。至此完成开发工作。

（5）上线实施：部署完成的系统，检查并确保系统运行正确，同时组织客户编制与系统相应的管理规则，培训系统的用户，完成系统的正式运行工作。

（6）合同交付：系统上线后，向客户交付代码、数据库、设计文档（需求、设计）、测试报告、操作指南等双方在《工作任务一览表》中约定的全部交付物。

3.后期运维阶段

从系统正式运行开始，系统的维护、改造、升级，直至系统被废弃为止，都属于后期运维阶段，包括以下步骤。

（1）维护：完成系统的交付后，根据系统的运行情况、用户提出的零星改进需求，以及运行中出现的Bug等对系统进行修改，确保系统可以正常运行。

（2）升级：使用一段时间后，根据客户提出的新需求，采用出现的新技术和新硬件等，对系统进行调整、拓展功能、优化运行性能等升级改造。确保系统在运行期间内始终与客户的业务和管理需求具有较高水准的匹配度。

（3）废弃：经过一段时间的运行后，判断该系统已不能适应客户的需求变化，且无法通过维护、升级或改造来提升系统的满意度，客户最终决定废弃旧系统，转而进行新系统的立项。至此，系统的生命周期结束。

1.1.2　软件开发的基础知识

本章的开头谈到在软件的开发过程中，一定会涉及软件工程和项目管理。对这两者的内容和作用简述如下（详细说明参见后续各节，以及其他专门的著作）。

1.软件工程

软件工程提供软件开发过程各阶段（需求分析、业务／技术设计、软件编码和测试等）所需要的理论、方法、标准和模板等，是指导软件开发的学科知识。

2.项目管理

项目管理提供对软件项目实施过程（项目启动、项目规划、项目执行、项目监控及项目收尾）的管理方法，是确保软件工程圆满完成的管理知识。

对于软件开发，软件工程和项目管理知识是不可或缺的，掌握这些知识并在软件开发过程中推行，可以有效地提升软件的客户价值和工作效率。软件公司必须建立基于这套知识的应用体系，包括开发流程、文档模板、检查标准等。

1.1.3　软件开发常见问题与对策

在软件开发的过程中存在两类比较常见的问题：一类是有关分析和设计的问题（与软件工程相关），另一类是有关软件开发的过程管理问题（与项目管理相关）。

1.分析与设计方面

1）存在的问题

需求工程师普遍缺乏调研和分析所需要的理论和方法，需求调研的质量得不到保证，项目开发常常因为需求不准和失真而造成返工。这也与软件行业内存在重技术（编码）、轻业务（分析与设计）的现状有关。在软件公司内缺乏业务设计、应用设计的方法及相应的岗位，而软件产品的价值恰恰又主要依靠业务设计和应用设计获得，这样就造成了软件行业长期存在着开发的软件产品数量不少，但是产品普遍存在质量低、客户价值低的现象，这个问题不解决，就难以提升客户的满意度。

2）需要采取的对策

针对分析和设计方面存在的问题，需要软件公司从公司层面完善软件工程的落地工作，深入研究需求分析和软件设计所需要的理论、方法、工具、标准等，增加所有相关人员的基础知识，特别是提升作为业务设计和应用设计主力的业务人员的能力，而提升他们的能力首先要解决的就是如何使他们获得专业的、体系化的培训问题。本书和《大话软件工程——需求分析与软件设计》一书的主要目的就是要解决此类问题。

2.过程管理方面

1）存在的问题

由于缺少软件工程知识的有效支撑，软件开发过程中的每道工序和产出物都难以量化，没有量化的工序和产出物在开发过程中就无法实现标准化，而没有标准化的开发过程也就无法实现有效的管理，即没有量化的管理就是无效的管理。其结果是项目经理对软件开发过程难以进行有效的管控，最终很容易造成项目的质量差，开发周期长，且成本超支等后果。

2）需要采取的对策

依靠软件工程的深化，实现软件工序和产出物的量化，进而实现开发过程的标准化。有了标准化作基础，就可以建立可控的软件开发过程，从而提升软件的项目管理水平。

软件工程和项目管理是支持软件开发过程的两个支柱，要想让这两个支柱发挥预期的作用和价值，就要实现这两者的对接和协同，做法是首先要实现这两者的标准化，其中软件工程的标准化是项目管理标准化的基础，项目管理是软件工程完美执行的保证。

1.2　软件工程

软件开发所需要的第一门学科就是软件工程，它是支持软件开发最重要、最基础的知识体系之一。软件工程提供软件开发过程中所需的理论、方法、标准和模板等，建立完善和实用的软件工程应用体系是解决上述所有问题的基础，因此，首先要实现的是软件工程的标准化。下面对软件工程的结构、内容做简单的说明。

1.2.1　软件工程的概念

下面就软件工程的定义、目的进行说明。

1.定义

关于软件工程的定义有很多版本，这里选取两种与本书提倡的观点较为接近的软件工程定义作为参考。

（1）IEEE的定义：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。

（2）《计算机科学技术百科全书》中的定义：软件工程是应用计算机科学、数学、逻辑学及管理科学等原理开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。

本书的软件工程的基本定义为：借鉴传统工程的概念、原则和方法，用系统性的、规范化的、可定量的方法来开发和维护软件。

2.目的

掌握软件工程的知识，让软件工程师对软件开发过程有整体的认知，建立软件工程的标准流程，可以帮助软件工程师按部就班、有条不紊且高效地进行软件的开发作业，确保最终获得高质量、高水平的开发成果，并可以利用软件工程结构作为框架，不断地、体系化地积累开发的经验、方法、模板、标准等，形成软件公司的企业知识库。

软件工程师包括咨询师、需求工程师、设计师、架构师、编程工程师、测试工程师以及实施工程师等所有与软件开发过程相关的岗位。

1.2.2　软件工程的4个子工程

对于软件工程的构成存在很多版本，不同版本的构成虽有所不同，但每个版本中都包含以下4个主要的子工程：需求工程、设计工程、编码工程和测试工程，如图1-1所示。这4个子工程的工作是构成软件开发方法和知识体系的核心内容。这4个核心子工程对应着1.1.1节所讲的软件开发3阶段中的第2阶段“开发实施阶段”的内容。

除这4个核心的子工程之外，软件工程中还包括配置、质量、工程等内容，本书重点介绍上述4个核心子工程，其他部分的内容在讲解过程中也会涉及。

下面用一个框架图来进一步展开这4个子工程，让读者对软件工程框架有一个概括性的、有形的认知，并以这个框架为导引进行全书内容的理解。

对图1-1中软件工程的构成向下做进一步的展开，形成图1-2，其中，横向为工程分解，纵向为工作分解。由于本书关注的重点是软件工程中的需求工程和设计工程（业务设计和应用设计部分）的内容，所以在图中省略了设计工程中的技术设计部分以及编码工程和测试工程的内容。

下面重点对需求工程和设计工程的内容进行说明。

1.需求工程

需求工程的目的是收集客户对新系统的需求。沿着工程分解的分析，将需求工程的工作分为两部分：第一部分是进行需求调研；第二部分是对调研获取的需求进行分析，通过分析最终确定需要开发的功能。

1）需求调研

需求调研的目的是通过与客户的交流，获取客户对未来待开发系统的原始需求，主要采用的调研方式有以下3种（本书重点介绍的方法，不限于此）。

（1）图形收集（图形法）：通过绘制客户业务现状图的方法理解业务并收集需求。

（2）访谈收集（访谈法）：通过与客户访谈交流的形式收集需求。

（3）表单收集（表单法）：通过收集客户正在使用的报表和单据收集需求。

除上述3种方式外，根据不同的项目，还可以采用问卷法、原型法等调研方法，但是这些方法只能作为前面3种方法的补充或辅助。

需求调研完成后，形成《需求调研资料汇总》（或《用户需求报告》）。

2）需求分析

需求分析的目的是对收集到的需求进行分析、识别、补全、确认等。主要采用的分析方法是将收集到的原始需求（文字、图形、表格）内容进行抽提，归集为3种标准的需求形式：目标需求、业务需求和功能需求，在分析过程中对这3类需求按照顺序逐次进行转换，即“目标需求→业务需求→功能需求”，功能需求是最终要确定开发的系统功能，这3类需求的来源与转换关系如图1-3所示。

这3类需求分别来自于客户的不同层级。

（1）目标需求：主要来自于客户的决策层，给出对未来待建系统的目标和期望。

（2）业务需求：主要来自于客户的管理层，给出对现有业务和管理需要改进的要求。

（3）功能需求：主要来自于客户的执行层，给出未来系统中需要的具体功能说明。

完成需求分析后，形成《需求规格说明书》，此文档是需求工程的最终成果，它有以下4个主要用途（不限于此）。

（1）对需求调研工作的全面总结。

（2）向客户确认开发内容的依据。

（3）是后续设计工程、编码工程的输入。

（4）是项目完成后客户验收系统的主要依据之一。

2.设计工程

设计工程的目的是根据需求工程的成果作出对软件的设计，这个设计结果是编码工作的依据。设计工程分为了两部分，第一部分是非技术方面的，第二部分是技术方面的（省略）。第一部分又分为业务设计和应用设计，内容参考图1-2。

1）业务设计1——概要设计

概要设计是设计工程的第一个阶段，概要设计的依据是需求工程的成果，主要确定系统4方面的内容。

（1）规范：从系统顶层设计出发，确定目标、理念、主线、原则、标准等。

（2）架构：对业务进行优化，确定业务架构、系统、子系统、模块等的划分。

（3）功能：对已明确的业务功能进行分类、规划，确定开发的业务功能一览表。

（4）数据：对数据的范围、内容进行规划，确定数据标准、主数据等。

在概要设计阶段，设计师的关注重点应置于顶层设计、大的系统间规划、构建主要的业务／管理架构，此阶段不要过多纠结于细节、系统内部小模块之间的关系或某个具体的功能等。概要设计一般不是一次就能做到位的，而是需要反复地进行调整。在概要设计阶段，应最大限度地提取可以复用的模块，建立合理的结构体系，节省后续各设计阶段的工作量。

概要设计中的设计规范决定整个系统的设计走向、最终完成的系统是否能满足客户的需求、是否能给客户带来预期的信息化价值。概要设计的内容是整个设计工程中难度最大、最重要的部分，通常由项目组中综合能力最强的人担任总负责（或由公司指派）。

概要设计完成后，将设计资料汇总形成《概要设计规格书》，它是后续详细设计、应用设计和技术设计的指南。

2）业务设计2——详细设计

详细设计是业务设计的第二个阶段，基于概要设计成果，对工作分解的架构、功能和数据逐层进行精细的设计。在详细设计阶段，所有待设计的对象被划分为独立的系统／模块，根据概要设计约定好的局部任务和对外接口，设计相关的定义、关系、算法等内容。这里要特别注意，在详细设计过程中如果发现有架构调整的必要，必须返回概要设计，将调整后的内容反映到概要设计文档中，而不能只解决详细设计问题而不再维护概要设计文档。

详细设计完成后，形成《详细设计规格书》，至此从业务维度进行的设计已全部完成，此后进行的设计（应用、技术）中则不能对业务部分的内容再进行任意的修改。如果必须要做修改，修改前一定要取得业务设计担当者的确认。

3）应用设计

应用设计可以看成图1-2中“业务设计部分”与“技术设计部分”接合部的过渡设计，它给出系统中“机制”部分的设计和实现方法、系统的运行效果（包括布局、操作、规则等），客户导入信息化管理的重要价值就体现在这部分的设计成果中。

由于业务设计和技术设计两个阶段所需要的知识、方法都不同，所以两个阶段之间的应用设计定义不清、前后交接不顺、互不理解的问题时常发生。这部分是所有软件公司发生问题最多的地方。

应用设计应该是包括业务、技术、UI、美工以及体验等诸方面知识和技术的集合体。这部分的设计需要应用设计师具有跨界的知识和能力，包括一定的客户的专业知识、业务设计知识、技术设计知识、UI设计和美工设计知识以及系统上线的经验等。

应用设计完成后，形成《应用设计规格书》。

3.编码工程与测试工程

完成了需求工程、设计工程两个阶段的工作后，就要进入到编码工程和测试工程的阶段，下面简单地介绍一下它们的内容。

1）编码工程

根据前面设计工程的结果（包括业务设计、应用设计以及技术设计等），建立数据库、系统架构，利用编写代码或是低代码配置的方式完成系统的所有功能。

编码工程完成后，交付信息系统（软件）、数据库等。

2）测试工程

根据业务和技术的设计文档等资料，编写测试用例，对完成的系统进行技术方面的测试，然后再与业务人员合作，利用业务用例和应用用例进行验证，确保系统完全符合设计要求。

测试工程完成后，形成《测试验收报告书》。

1.2.3　软件工程的两阶段法

为了方便进行软件工程的研究以及在实际工作中对开发内容的划分，根据实际软件开发的分工、协同关系，对软件工程的4个子系统再进行一次分割，引入“两阶段法”的概念。两阶段法具有实用意义，可以帮助理解软件工程的构成以及不同工程的目的和作用。

1.两阶段法的概念

在实际的软件开发过程中，习惯上将从事不同工作的工程师粗分为两类，分别称为业务人员和技术人员。

●业务人员：主要从事咨询、需求调研与分析、业务设计、应用设计和实施等工作。

●技术人员：主要从事技术设计、建立数据库、编写程序、测试等工作。

由于这两部分工作的目的、内容、担当者以及需要的知识都不相同，因此为了方便说明，将他们各自负责的工作划分为两个不同的阶段。

●一阶段：从接触客户的售前咨询开始，到完成业务设计和应用设计为止。

●二阶段：从技术设计开始，到完成编码和测试为止。

将开发划分为两个阶段称为“两阶段法”，参见图1-4。它们的分界点设在由一阶段的业务人员向二阶段的技术人员进行前期成果的交底处。

在一阶段工作中的主要担当者称为业务人员，主要完成3类工作和交付物。

（1）咨询：进行售前咨询，提出解决方案（报告）等。

（2）需求：进行需求调研、需求分析，交付《需求规格说明书》等。

（3）设计：进行业务的概要设计、详细设计以及应用设计，交付《设计规格书》等。

在二阶段中的主要担当者是技术人员，在接受了业务人员对一阶段工作成果（文档）的交底后，主要完成3类工作和交付物。

（1）设计：以一阶段的成果为依据，做技术方面的概要设计、详细设计，交付《技术设计规格书》等。

（2）编码：基于前面的设计文档，用编写代码或无码配置的方式完成系统。

（3）测试：对完成的系统按照设计、用例的要求进行测试验证，交付《测试验收报告书》。

为了区别工作内容和岗位的不同，以下将一阶段中3部分的担当者分别暂称为咨询师、分析师、设计师。由于软件行业没有统一的标准，因此可以认为这是3个不同的独立岗位，也可以理解为是一名需求工程师在做3种不同的工作。目前大多数软件企业中的业务人员的工作重心在“调研、分析”位置的前后，他们努力向前方多移动一下，就可以接近咨询师的岗位，向后方多学习一点，就可以接近设计师的位置。

本书和《大话软件工程——需求分析与软件设计》都是针对一阶段工作的参考书。

2.两个阶段工作的区别

一阶段工作的目的是搞清楚客户采购系统的目的和系统覆盖的业务范围，以及在“人—人”环境中的业务现状、目标需求、业务需求和功能需求等，给出未来在“人—机—人”环境中需要进行的业务优化，确定要开发的系统功能等。也就是把“客户的需求”通过分析、设计，翻译为“软件的需求”。

二阶段的工作目的是实现一阶段的设计。二阶段的工作目的是在一阶段工作成果的基础上，给出具体的实现方法，并完成系统的编码和测试工作。二阶段的工作成果要同时满足一、二两个阶段的设计要求。

系统的客户价值大小、客户对系统的满意度高低等，主要取决于一阶段的工作成果（也就是业务人员的工作成果），两个阶段的目的差异如下。

（1）一阶段：通过分析、设计工作，决定系统的客户价值上限（系统好用）。

（2）二阶段：通过设计、编码工作，决定系统的客户价值下限（系统可用）。

3.两个阶段的相互影响

一阶段与二阶段的标准化工作的进程存在相互影响、相互促进的关系，随着一阶段的标准化推进，还可以更好地促进二阶段的改进水平，两者之间有如下作用关系。

●如果一阶段实现了分析与设计成果的标准化，且二阶段也实现了标准化（构件化、配置化、平台化等），则开发全过程就可以做到完美高效了。

●如果一阶段工作没有做标准化，二阶段工作做了标准化，那么总体效果是有限的。因为如果一阶段的交付物是随意的、非标准的，不利于在二阶段中形成标准化的“构件”。即使在二阶段实现了标准化，其也会因一阶段成果的不稳定而带来系统整体的不稳定。

●如果一、二阶段都没有实现标准化，可以先从一阶段的分析与设计开始做标准化，虽说两个阶段的标准化没有绝对的先后，但一阶段先标准化可以为二阶段的标准化提供良好的基础。另外，与二阶段标准化的难度相比，先实现一阶段标准化的门槛相对较低，投入少，见效快。

1.2.4　软件设计的3个层次

从软件工程结构图中可以看出，将设计工程内的工作分解为3个区域（概要、详细、应用），但是每个区域纵向的“工作分解”内容都是一样的，都是分为3个设计层，即架构层、功能层和数据层，如图1-5（a）所示。

工作分解的顺序是由上到下，这3层内容的关系是从粗到细，设计工程沿着横向的3个区域（概要、详细和应用）都是围绕架构、功能和数据3层进行不断的细化和深化。

1.工作分解1——架构层

架构层是工作分解的第一层，也是最上层，它的核心工作是对业务进行从上到下的规划、架构。通过从概要、详细和应用3个区域的接力式设计，完成从业务架构的规划、详细的流程分析，到最终转换为系统应用架构的机制。架构层是粗粒度的设计，是表达业务逻辑的重要部分。

2.工作分解2——功能层

功能层是工作分解的第二层，处在架构层和数据层的中间，它的主要工作是对业务功能的规划、设计。业务功能设计主要是对操作界面的设计，通过从概要、详细和应用3个阶段接力式的设计，完成功能需求→业务功能→业务组件的设计转换。功能层包括界面形式、业务逻辑、数据定义以及规则设置等大量的设计工作。

3.工作分解3——数据层

数据层是工作分解的第三层，它的核心工作是对数据的规划、设计。通过从概要、详细和应用3个阶段接力式的设计，完成对数据整体规划、领域规划、数据标准制定、主数据的选择、数据计算建模、数据的复用机制等一系列的设计。数据层的设计是最细致的工作。

4.各层工作量比例

架构、功能和数据3层的设计工作量占比是完全不同的，通常数据层＞功能层＞架构层，参考图1-5（b）。

（1）架构层：主要在开发过程中对系统进行整体规划，对业务和应用的架构进行设计等，其工作量在开发过程中是相对最少的（但起的指导作用是最大的）。

（2）功能层：主要在开发过程中做界面的分析、设计，界面是未来输入和展示数据的窗口，其工作量在开发过程中是中等的（所以是评估开发工作量的重点）。

（3）数据层：其工作量可以分为以下两部分。

●一是在系统开发过程中，主要由软件工程师制定数据标准、主数据，以及协助客户收集、规范企业的基础数据。

●二是在后期系统的使用过程中，对积累的数据做加工、分析、统计等应用。数据是客户企业的信息化资产。

由于数据的应用周期与系统的生命周期长度相同，所以数据层两部分的工作量加起来是三层中工作量最大的。

1.2.5　软件工程的常见问题与对策

下面来看一下与软件工程相关的常见问题和解决对策，这些问题是妨碍软件开发顺利进行的重要原因（不限于此），解决好这些问题有助于提升软件开发的效率和质量。

1.常见问题

虽然大家都知道，业务人员在一阶段的工作成果对开发出一款优秀软件起着非常重要的作用，但是目前在软件行业中普遍存在着“重技术、轻业务”的现象（即重视二阶段的工作，轻视一阶段的工作），这种现象也反映了支持一阶段工作的软件工程缺乏成体系的知识，包括分析与设计相关的理论、方法、标准和模板等，这就造成了在软件开发过程中常常会出现以下问题（不限于此）。

●一阶段知识不成体系，没有结构化，知识点松散，知识点之间没有前后衔接关系等。

●分析和设计成果用文字表达的多，用图形表达的少（UML在一阶段难以推广）。

●文档表达不严谨、分歧多、误解多、阅读效率低等，容易造成需求传递的失真等。

●最终造成完成的系统客户价值低、质量低、应用效果不好。

一般来说，软件公司普遍存在对二阶段工作的资源和时间投入力度都要大于一阶段的现象。一阶段从需求分析到软件设计的工作，大多数处于“经验导向、自由发挥”的状态，基本上没有形成标准化的作业方式。虽说大学有软件工程这门课程，软件企业也提倡标准化作业，但流于概念和形式的较多，很多的管理流程和规则不具有实际操作意义（形式为主），这些形式的东西没有给软件开发带来实质性的价值。

反观其他传统工程与制造行业（如建筑业、机械制造业等），从分析、设计、生产到检验的标准化作业都不是走形式，而是必须要执行的要求，严格的标准化作业形式也带来了相应的价值：可以按时、按质、按量地完成工作。

可以肯定地说：不提升一阶段业务人员的软件工程水平，就难以提升产品的设计水平，当然也就不会有二阶段的高水平发挥，最终也不会有高价值的、高满意度的产品诞生。

2.解决对策

解决上述软件工程中存在的问题，核心工作是让软件工程知识可落地、可操作、可检查，实现软件工程知识的标准化，内容包括以下几点。

●工作内容要从定性到定量，工作内容实现量化才有可能实现标准化。

●软件工程的知识落地，表达形式要实现结构化、图形化、工程化。

●在软件公司中设置设计师的岗位，确定设计师的职责以及开发过程中的主导地位等。

1.3　项目管理

软件开发所需要的第二门学科就是项目管理。项目管理提供软件开发全过程所需要的流程、标准等。项目管理是用于确保软件工程发挥作用的重要保障，项目管理和软件工程的协同工作确保了软件开发的顺利完成。下面对项目管理的结构、内容做简单的说明。

1.3.1　项目管理的概念

1.软件项目管理的定义

软件开发过程中采用的管理方式是项目管理，由于软件行业使用的项目管理方式与其他行业有所不同，因此为了区别，也可以称之为“软件项目管理”，这个词包含诸多的内容，这里先将“软件项目管理”一词进行拆分：软件→项目→管理→项目管理→软件项目管理，然后从每个词的字面定义上来看其含义。

1）软件

软件分为两类，系统软件和应用软件，其中系统软件并不针对某一特定应用领域，而应用软件则相反，不同的应用软件根据客户提出来的需求以及其所服务的业务领域提供不同的功能。在本章中“软件”特指应用软件（如企业管理、项目管理、人力资源管理等）。

2）项目

按照定义，项目是在某段时间内，为了实现一个或一组特定目标的活动过程，项目的参数包括范围、质量、成本、时间、资源等。项目是一次性的，即项目是有开始点和终止点的，项目一词在不同的行业对应不同的业务内容，以下为不同行业采用项目管理的工作内容。

●工程行业：构筑建筑物，如建造一栋办公楼、一座工厂、一座桥梁等。

●科研行业：研发、制造一款产品，如运载火箭、高铁列车、抗癌药物等。

●会展行业：举行大型活动，如策划组织大型国际会议、大型音乐会、结婚典礼等。

●软件行业：研发一款软件，如ERP、CRM、PM、HR等。

3）管理

按照定义，管理是指以人为中心，通过计划、组织、指挥、协调、控制及创新等手段，对组织所拥有的人力、物力、财力、信息等资源进行有效的决策、计划、组织、领导、控制，以期高效地达到既定业务目标的活动。常见的管理模式有项目管理、运营管理等。

4）项目管理

项目管理（=项目+管理）就是针对“项目”这个有始有终的活动过程而形成的一套管理方法。在有限的资源约束下（时间、人力等），运用系统的观点、理论和方法，对项目涉及的全部工作进行有效的管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

项目管理是对做事过程的管理，它有两个重要的概念：5个过程组和3大目标。本书有关项目管理的内容主要围绕这两个概念展开。

（1）5个过程组：将项目管理的全过程划分为5个过程组，即项目启动、项目规划、项目执行、项目监控和项目收尾。

（2）3大目标：从项目管理诸多的目标中，选出3个影响最大的作为对项目管理的评估目标，即质量目标、进度目标和成本目标。

项目管理是一套通用的管理方法体系，它适用于很多的行业和领域。

5）软件项目管理

软件项目管理（=软件+项目管理），它是结合了软件开发特点而形成的一套项目管理体系。软件与其他行业的产品（建筑、制造、会展等）相比有很多的特殊性。首先，软件是纯知识性的产品，由于它比较抽象，因此对它的开发进度、开发质量和开发成本都很难进行度量、预估、控制，所以软件开发的生产效率也难以预测和保证。其次，软件产品的复杂性也导致了开发过程中各种风险的难以预见和控制。构成软件项目管理体系的内容参考见图1-6，其中，

（1）主体过程：包括项目过程1和软件工程，是完成软件开发的主体。

（2）辅助过程包括以下内容。

●项目过程2：用于支持软件过程中的标准、质量、文档等的管理。

●过程管理：主要是对实施过程与软件过程等的管理。

●过程组织：是对整个项目提供从组织、人才到流程、成本等的管理。

以下如无特殊说明，项目管理与软件项目管理同义。

2.项目管理的重点

在本书的案例中，有关项目管理部分将会重点讲述以下两部分的内容。

（1）项目管理的两个基本概念，包括5个过程组、3大目标。

（2）项目管理与软件工程在开发过程中的协同方式等。

从事软件开发的相关者（不论是软件经理还是软件工程师），都需要掌握项目管理的这两个重要基本概念。

【参考】有关项目管理的知识，请参考《项目管理知识体系指南（PMBOK指南）（第六版）》等专业书籍。

1.3.2　项目管理的5个过程组

按照项目管理的规范，将项目管理的全过程划分为5个过程组，这5个过程组的目的和作用不同，分别管理5类不同的工作对象。

1.5个过程组的划分

项目管理的5个过程组分别是项目启动、项目规划、项目执行、项目监控、项目收尾，如图1-7（a）所示。这5个过程组的内容如下。

1）项目启动

项目是有始有终的，项目启动阶段就是一个项目的始点，工作内容包括：确定项目范围，制定项目章程，任命项目经理，组建项目组，确定约束条件和假设条件等。也就是说，项目管理过程中涉及的所有内容、步骤、标准等都要先在此进行准备。

2）项目规划

项目规划阶段的工作，是在项目正式执行前为项目规划实施路线图，编制项目执行的详细规划。项目规划要做到：明确项目范围、任务分解（WBS）和资源的分配，规划要详细到每个人在什么时间内必须完成什么交付物。

3）项目执行

项目执行阶段就是项目组成员按照实施路线图和执行计划分配的工作，按时、按质、按量地完成分配给自己的任务。项目经理需要做好前期工作准备、范围变更、项目信息记录、组员激励，以及控制好项目的范围及目标等。

4）项目监控

项目的监控工作内容是对项目全过程的每个节点进行监督和控制。在实际的运用上，项目监控的位置并非是固定地排在图1-7（a）的第Ⅳ位上，正确的表达方式是将项目监控与其他4个过程平行放置，它们之间的关系如图1-7（b）所示。

5）项目收尾

当项目的全部内容执行完成后，按照与客户签订的合同、软件公司给项目组下达的目标要求等约定内容，对项目实施的成果进行检查、评估、验收、总结等一系列工作，待全部确定合格后就关闭项目、解散项目组，一个完整的项目就算结束了。

2.项目管理与软件工程的关系

上面介绍的是一个通用项目的5个过程组划分，下面介绍项目管理的5个过程组与软件工程的4个子工程之间的对应关系。

一个软件项目从哪里开始、到哪里结束呢？起始与终止不同，划分内容就不同，对此不同的软件公司有不同的划分方法，例如项目的起始，可以设在项目商谈时、项目合同签订时、需求调研开始时等不同的时期，但是对项目的结束（项目收尾）的认知是一致的。

由于本书的内容主要是讲述软件工程的应用，以及软件工程和项目管理的工作协同，所以结合本书中的案例，重点介绍与软件工程一阶段内容有密切关系的部分，项目管理的5个过程组与软件工程的4个子工程的对应关系如图1-8所示。

从图中可以看出项目管理要比软件工程的图形要宽一些，这是因为完成一个项目开发，项目管理工作的起止点要长于软件工程工作。二者关系的说明如下。

Ⅰ.项目启动：将项目启动设定在项目合同签约后开始。项目启动的工作包含项目组成立、项目经理的确定、人力资源、技能培训、成本预算等，参考第4章。

Ⅱ.项目规划：项目规划的工作包含《工作任务一览表》编制、执行计划制订、管理规则确定等，参考第4章。

Ⅲ.项目执行：主要工作是对开发过程进行组织、管理，是对应软件工程的重点内容，参考第5章～第14章。

Ⅳ.项目监控：主要工作是对进度、成本、质量等进行监督，监督的范围包括第5章～第14章等软件工程全过程。

Ⅴ.项目收尾：主要工作是软件交付、文档归档、总结分享等，参考第15章。

1.3.3　项目管理的3大目标

项目管理的5个过程组给出了软件项目执行过程的形式，那么对项目的执行结果设置了哪些必须要达成的目标？如何对达成结果进行评估呢？

通常从项目管理诸多的管理目标中抽提出3个最有代表性的目标，以它们的达标程度作为评定项目管理优劣的主要参考依据，这3个目标分别是质量目标、进度目标和成本目标。这就是所谓的项目管理3大目标，其内容和作用如下。

1.3大目标的设定

1）质量目标

开发项目在事前要制定质量要求和保证措施，确保软件必须正确地按照设计要求完成编码和测试。保证运行结果正确，运行效率和系统安全满足客户需求等。达成质量目标是客户认可系统并支付合同金的基本前提条件。

2）进度目标

编制进度计划，在每个时间段上标明需要完成的工作内容、工作量、交付物以及所需的人力资源等。随着项目的推进，可以确认项目计划在什么时候完成，需要交付什么，是否发生了进度的偏差，等等。进度目标是项目经理管理开发过程的重要抓手。

3）成本目标

项目成本主要就是人工费，项目开始前就要确定在需求阶段、设计阶段、编码阶段及测试阶段需要什么样的资源（需求工程师、架构师、设计师、程序员、测试员、实施工程师等）、数量、时间、单价（人月）等。确保进度和质量的要求，以避免发生超额用工而造成项目成本的超标。控制成本目标是确保项目利润的重要保证措施。

项目管理的3大目标，多角度地、均衡地表达项目的完成情况，不论是软件客户还是软件公司都是围绕着这3大目标开展工作的。

2.3大目标与软件工程的关系

项目管理3大目标能否达成，最为重要的影响因素之一就是软件工程的水平，因为项目的质量取决于需求分析、软件设计、系统编码以及测试验证的水平；进度和成本，取决于软件工程能否进行标准化并做到量化管理，后续各节中将详细地讲解项目管理的3大目标与软件工程的标准化问题。

1.3.4　项目管理的常见问题与对策

下面讲解与项目管理相关的常见问题和解决对策，这些问题是妨碍软件开发过程顺利进行的重要原因。

1.常见问题

参加过软件项目开发的读者都很清楚，要想达成项目管理的3大目标是非常困难的。目前在软件的开发过程中大多以项目经理的个人经验为主进行管理，依靠项目经理掌握的项目管理知识，仅在“组织、管理”层面上做努力，可以说几乎是不可能实现的，更别提要进行科学的项目管理。

软件行业的“软件制造”与其他行业的“实物制造”相比，难就难在软件的开发过程不容易量化，没有量化就无法标准化，而没有标准化的工作是难以进行精准、有效管理的。这一连串的原因就造成了难以制订相应的计划和资源安排，最终项目管理的效果也不明显。下面从3方面说明难点所在。

1）难以确立标准的交付物及验收标准

传统的分析和设计方式没有对分析和设计对象进行量化拆分，因此难以建立标准的分析、设计方法体系（包括分析与设计的流程、分析与设计的建模等工作），同时也影响确立标准的交付物和验收标准。这些标准的缺乏会给后续开发工作带来很多不确定的问题。

2）难以确立清晰的目标和计划

交付物的不标准造成了计划编制的困难。项目管理成功的重要基础之一就是制订精确的、可执行、可检查、可验收的项目计划。由于对需求和设计的内容难以定性和量化，所以在需求真伪的判断、设计质量的评估、工作量的计算等方面都存在大量的不确定性，造成难以在开发前制订可信的项目计划，因此在开始后大多数的软件项目都难以控制在计划内，超出合同工期的现象比较普遍，而且项目的规模越大、内容越复杂，延误工期的现象就越严重。

3）难以确立匹配的组织和管理方法

由于交付物和计划难以标准化，所以也造成对项目成员能力缺乏相应的评估方法，这样就会影响建立合适的项目组以及选择匹配工作内容的成员。所有的工作都是在目标、计划及交付物标准模糊不清的状态下，依靠项目经理的经验随机推进，这样就不能制定科学的、有效的组织和管理机制，最终难以达成预期的项目管理目标。

从上述说明可以看到，要想实现项目管理的3大目标（质量、进度和成本），就要首先解决上述问题，否则即使勉强完成了软件的开发，最终也会出现交付的产品质量不佳、工期拖延、成本超标的后果。

2.解决对策

一般来说，软件公司大多比较重视项目管理知识在软件开发过程中的作用，要求项目经理等相关人员学习和掌握项目管理知识并取得相应的资质，但对软件工程的知识和作用重视不足。事实上，如果想在软件开发的过程中实现项目管理的3大目标，单独依靠项目管理方面的知识和经验是完全不够的。这一点可以从图1-8中看出来，项目管理的5个过程组中“Ⅲ.项目执行”是项目管理的核心，工作量也是最大的，这部分就是基于软件工程的工作，因此，做好项目管理工作首先要做的是以软件工程为基础对软件进行量化和标准化，继而实现项目管理的标准化，这样才可能从根本上消除影响项目管理3大目标达成的障碍。

项目管理的标准化是以软件工程的标准化为前提的。

1.4　软件的标准化

在上述软件开发、软件工程、项目管理三者存在的问题中，出现频率最高的一个关键词就是“标准化”，标准化就如同一把解决上述诸多问题的通用钥匙。

软件的标准化就是以软件工程的知识为基础，结合项目管理，建立起在软件开发过程中的模式、标准、规范以及相应的交付物，从而提升软件开发工作的效率和效益。软件的标准化需要软件工程和项目管理的协同和支持。

由于本书重点讲述的是一阶段的工作内容，所以以下如无特殊说明，“软件的标准化”均指的是一阶段中以业务人员为主的工作，即需求分析和软件设计。至于二阶段的技术设计和软件编程的标准化问题不在本书讨论。

1.4.1　软件标准化的困局

软件开发、软件工程、项目管理三者存在的问题，都与软件的标准化有着非常紧密的关联，如果能够有效地实现软件的标准化，那么上述存在的问题都可以得到很好的解决或给出解决方案。那么在软件行业中软件的标准化做得如何呢？

1.软件标准化的现状

软件标准化的重要性无须赘述，有着一定规模和年限的软件公司都在不同程度上进行过标准化的探索和实践，当中可能不乏成功的公司，但是多数软件公司的标准化进行得都不顺利，效果也不好，主要表现在以下几个方面（不限于此）。

●标准化目的不清晰，缺乏整体规划，部门各自为战。

●从事标准化制定的人员没有掌握相应的理论和方法，甚至也没有工程的概念，只是参考一般的文档管理方法来制定软件标准化的内容和规则。

●标准化的要求大多用文字描述，既烦琐又不易掌握，容易产生歧义，且无法复用。

●标准化制定了很多零散的且前后工序不衔接、不通用的模板。

最终软件标准化的工作变成了仅仅是为了符合标准化的文档形式，标准化没有带来预期的效果，这样的标准化不但没有给软件工程师减负，反而增加了他们的工作量。

2.软件标准化不成功的原因

前面提到的是软件标准化不成功的表象，那么为什么软件标准化难以成功呢？下面举几个影响标准化的有代表性的例子来说明原因。

1）缺乏指导的理论和方法

首先是缺乏软件标准化的理论、方法，参与编制标准的担当者有些甚至没有从事过软件的开发（不论是一阶段的工作还是二阶段的工作），他们仅仅把建立软件开发标准看成制定一些文档管理的规范。常常由于负责制定标准的人不够专业，造成了即使制定出了标准化的条条框框，也由于不符合实际而被软件工程师吐槽、反对，或被束之高阁。

标准化的方法不得当，不但不会提升质量和效率，反而会费时费力，最终不知为何而做标准化，流于形式不了了之。

2）缺乏过程的结构化

在制定标准化的过程中不重视结构化的表达形式，仅仅是规范一些模板，但这些模板散乱、孤立、无上下游的衔接标准和要求。

缺乏对软件实现过程的整体规划，软件实现过程中不仅仅需要“记录模板”的标准化，包括分析和设计方法都要标准化，如拆分方法、调研方法、记录方法、分析方法、架构方法、设计方法，以及编码和测试工作等都需要“标准化”。标准化涉及人、方法、交付物3方面，模板仅仅是其中交付物的一部分。

3）缺乏表达的图形化

仅就模板而言，所谓的标准化，也就是固定了模板的标题和表格的格式而已，内容的描述方式是自由的，因为大多是以文字描述为主，所以表达内容中歧义多，遗漏多，且逻辑表达不准确。不用图形的形式表达分析和设计结果，就不能满足细度、精度的要求，特别是不用图形难以表达业务逻辑这个非常重要的分析和设计成果，极易造成后续的技术设计和编程工作的逻辑错误。

4）缺乏系统的模块化

由于存在缺乏量化和标准化的问题，使得软件难以实现模块化的设计，这样开发出来的软件可以看成一个用代码直接写出来的、具有高度耦合性的“固化系统”，这样的系统当然在后面就难以再拆分成可以复用的标准化模块，也影响系统的维护与升级。

5）缺乏传递与继承

由于缺乏上述的结构化、图形化和模块化的标准，所以就难以做到每道工序的成果在上下游工序之间的正确传递和继承，仅强调标准化，不强调前后工序成果的传递与继承，其结果就是每个阶段的工程师都是各自做各自的，这样的标准化意义何在？如果所做的工作只需要一个人，或是只有一道工序，那么就不需要标准化了。正是因为所做的工作需要多人协同、多道工序衔接，所以才需要传递与继承，标准化是传递与继承的基础。

6）缺乏组织的支持

软件公司对分析和设计专业人才没有给予足够的重视。在组织上缺乏相应的部门和岗位设置，如业务架构师、业务设计师等，在流程和规则上没有设置相应的工作环节和岗位职责（权限），当然在软件开发过程中业务人员也缺乏明确的话语权。

3.软件标准化的现实意义

前面列举了很多关于标准化缺失造成的问题，那么标准化到底有哪些现实意义呢？关于软件标准化的作用并非仅限于软件公司一方，它对客户的信息化管理和运用也有很重要的影响，下面就从客户与软件公司两方面讲解标准化的意义。

1）从客户方面看

由于企业信息化管理的不断深入，系统与现实业务进行了深度融合。因此根据市场的不断变化，客户也会频繁地提出新的需求，这些新需求带来了对既有系统的维护、改造、升级的沉重压力。客户对系统的依赖程度越高，其对软件公司的要求就越高，他们期望（要求）软件公司提供的系统要能够做到随需应变、随时应变（即使是定制的系统，也难免被频繁地要求进行改造），如果不能满足这样的要求，就会影响信息系统的使用价值，甚至是系统的生命周期。

2）从软件公司方面看

业务人员比较少，且流动比较严重，这就使得软件公司拥有的业务人员数量不足，特别是有丰富经验的高水平业务人员的流失，造成了软件公司原本就比较薄弱的需求分析和设计能力变得更加力不从心。现在相当部分已完成的信息系统既无标准化的设计和标准化的文档，也没有进行标准化的编码。在原开发人员离职的情况下，一旦客户要求升级改造既存的信息系统，软件公司就会难以应对，这就使得软件标准化更具有现实意义和急迫感。

对比一下建筑行业大力推进建筑标准化施工的例子就容易理解了。由于建设行业的规模急剧增大，为补充熟练工人不足的缺口而大量使用缺乏施工经验的农民工，造成建设工程质量、效率的下降。为了解决这个问题，建筑行业大力推广标准化的施工方式，如图1-9所示，即将建筑结构拆分为不同的标准构件见图1-9（a），在工厂中用机械生产这些构件见图1-9（b），最后运到建筑工地，通过吊装完成施工，见图1-9（c）。

建筑行业采用标准化的作业方式后，不但解决了人力不足、质量下降的问题，还优化了施工环境，缩短了施工周期，降低了施工成本，并大幅度地提升了施工的生产效率，更重要的是还降低了对施工者个人能力的要求。软件行业遇到的困难与建筑行业是相似的，同时软件行业采用的（或即将采用的）解决对策与建筑行业也是相似的。从这里也可以看出，传统工程行业的做法对软件行业具有很好的启发和示范意义。

1.4.2　软件标准化的思路

上述的标准化工作缺乏结构化、图形化、模块化以及传递—继承的要求等，可以认为是“非工程化”的软件标准化，也就是说做好软件标准化的基础是“工程化”。消除上述标准化过程中的各种问题，建立符合软件行业的标准化，借鉴成熟的传统工程行业标准化做法可以为软件行业的标准化提供非常有价值的参考。

1.什么是工程化

所谓工程化，就是参考其他成熟的传统行业（建筑业、制造业等）的标准化做法。工程化有两个显著的特点：一是要规定分析设计的结果是以图形为主、文字为辅的表达形式；二是工程化方式强调“传递与继承”，即上下游工序间传递的信息准确、无歧义，工程化的生产是严格“按图制作”的。

实现软件标准化也就是实现软件开发过程中各个环节工作的标准化。由于支持软件开发各个工序的知识体系是软件工程，因此实现软件标准化的关键工作是软件工程内容的标准化。有了软件工程做标准化的基础，项目管理的标准化也就容易实现了。有了标准化的软件工程和项目管理作支撑，软件开发全过程的标准化作业就容易实现了。

知道了解决软件标准化的重要工作是软件工程内容的标准化，按照软件工程的定义来看，软件工程是采用工程的概念、原理、技术和方法，以及系统性的、规范化的、可定量的过程化方法来开发和维护软件。这个定义也给出了软件工程的框架和阶段的划分，初步建立了软件工程的概念。软件工程是一门学科知识，它具有多少实用价值还要通过它在实际软件开发过程中发挥的作用来评估。下面以《大话软件工程——需求分析与软件设计》一书提供的内容（分析与设计部分）为基础，探索如何实现能满足工程化要求的软件标准。

2.符合工程化要求的软件标准

下面讲解如何制定符合工程化要求的软件标准。构建符合工程化要求的软件标准需要下述5个步骤：对象拆分、要素量化、标准化、工程化（条件）、工程化（标准），参见图1-10，下面对图中的各个步骤进行说明。

1）对象拆分

标准化的第一步就是对复杂的软件开发过程进行拆分，化大为小，化繁为简，然后逐一地进行标准化。拆分是将一个完整的对象拆分成若干要素，合理的拆分方法、合理的要素粒度是后续进行要素量化、模块化的基础。例如，做企业管理信息系统，首先要知道怎么拆分“企业”这个对象，拆分结果要与后续的量化、分析、建模和设计等工作有关联。依据何种理论进行拆分是非常重要的，因为不同的指导理论会导致不同的拆分结果。

2）要素量化

要素量化是对从图1-10中“（1）对象拆分”中得到的要素进行量化处理。所谓的量化就是定义这些要素，使每个要素具有独立的含义，可计量（大小、多少）、可设计、可检查、可验证。例如对“企业”拆分后给出4个要素（业务、管理、组织、物品），对“需求”拆分后给出3类需求（目标需求、业务需求、功能需求），对“设计”拆分后给出3个层（架构层、功能层、数据层）等。

【参考】《大话软件工程——需求分析与软件设计》中的2.1.2节、5.2节和第8章。

3）标准化

标准化是将图1-10中“（2）要素量化”的成果再进行分类、归集，给出标准的定义、建模。例如根据不同的目的，可以将功能需求（界面部分）分为4类，即活动功能、字典功能、看板功能和表单功能。因为同类型功能的目的、用途和设计方法都相似，所以可以使用相同的设计模板。这样不但能减少设计的复杂度、提升功能的可复用性，而且从整体上提升了工作效率。

【参考】《大话软件工程——需求分析与软件设计》第10章。

图1-10中的（1）～（3）给出了一般常见的标准化方式。很多软件公司的标准化工作到此就结束了，而这就是标准化效果不好的主要原因，因为这里只是打下了标准化的基础，下面还要对这些成果进行满足工程化要求的进一步设计。

4）工程化（条件）

工程化是本书所提倡软件标准化的最重要的条件。图1-10中“（4）工程化（条件）”主要有3个：模块化、结构化和图形化，其定义如下。

①　模块化：满足模块化要求，就是指量化后的内容所具有的处理功能能够独立地完成某个业务目标，这样的功能内容称为模块。模块粒度有大有小，大到可以是一个系统，小到可以是一个界面。

②　结构化：结构化有两层含义，一是模块之间的关系要结构化，二是按照传递和继承的要求建立工作顺序（参考软件工程的框架图）。

③　图形化：对分析和设计成果的表达原则上要以图形为主、文字描述为辅。这样可以在一张图上同时表达逻辑和功能，精确地表达和传递上游设计师的意图。

5）工程化（标准）

当软件标准化采用模块化、结构化和图形化3个方法后，完成的软件设计成果就应该满足以下6个标准（不限于此），参见图1-10中“（5）工程化（标准）”。

①　可计量：经过拆分、量化、模块化后，工作量可计量，含类型、难度、人工数等。

②　可执行：可按规范和标准进行分析、设计的工作，并有明确的交付成果和交付标准。

③　可传递：完成的文档以图形为主，可向下游工序进行准确、无误的传递和交底。

④　可继承：下游以上游的成果为输入，并在此成果之上进行下一步工序的作业。

⑤　可检验：完成的成果对照相应的标准，可以进行验收并评估成果的完成度。

⑥　可追溯：发现问题后，可以向上游工序追溯问题的来源及发生的原因等。

满足工程化要求的软件标准形成一个整体。在满足工作成果质量的同时，还可以通过成果复用（传递—继承）显著地提升工作效率。这样的设计文档不论交给哪家公司，读取的信息都是一样的，照图完成的产品都是一样的。联想一下其他的传统建筑业、制造业，它们早已完成了上述的工程化协同。

1.4.3　标准化要求的文档

搞清楚了符合工程化要求的标准后，就可以确定具体的、符合要求的文档标准。

每个软件公司都有自己的文档标准，符合工程化标准的文档不但要做到表达精准，而且还要做到“化繁为简”。标准文档要能够通过文档的复用、内容的快速阅读等方式提升工作效率，要能够给使用标准文档的软件工程师“减负”。制定标准文档的要求有很多，这里重点提出3个文档标准供参考：用语标准、表达标准和结构标准。

1.符合工程化要求的文档标准

1）用语标准

前面已经讲过，业务人员的文档要让客户和技术三方都看得懂，所以用语必须要达到客户、业务人员和技术人员三方面的统一。不论任何标准文档，首先都要对关键内容进行用语的统一。如对客户专业方面的用语，要定义用语，以确保客户与软件公司业务人员之间的理解和表达完全一致，无歧义。同样，在软件公司的内部，需求工程师之间、需求工程师与编码工程师、测试工程师之间也必须统一用语。

2）表达标准

每份文档都必须由图形、表格、文字3种表述方式混合构成。设计文档不能只用文字表达，特别是逻辑部分要用图形表达，因为图形表达的逻辑信息量要大于文字，且精确、不易发生歧义。如图形按照框架图、分解图、流程图；表格按照需求4件套、流程5件套。需要用文字描述的地方尽量采用条目化的方式。

3）结构标准

结构的标准可以分为两个层次：软件工程的结构和文档内部的结构。首先，软件开发过程必须要结构化，软件工程框架是典型的结构化模型，参见图1-2。这样的结构化方便前后、上下游岗位之间的协同关系，也利于各阶段成果的传递与继承。其次，文档内部要有规律、结构化，这样易于文档的掌握、维护，参见图1-10。

【参考】《大话软件工程——需求分析与软件设计》第22章。

2.工程化与标准化的关系

从工程化的定义已经知道，符合工程化要求的文档一定是标准化的，但标准化的文档却不一定满足工程化要求。下面举例说明工程化与标准化的关系。

1）符合工程化要求的标准文档

先看一个符合工程化要求的标准文档。这是一个界面设计模板（简称4件套），文档由4个独立的模板构成，从4个维度描述同一个界面（原型、定义、规则和图形），要求文档不但模板必须一致，而且必须是结构化的，要用图、表和文字综合表达，并确保表达的内容是唯一的、无歧义的，如图1-11所示。其中各模板内容如下。

（1）模板1-业务原型：给出对业务内容的界面布局。

（2）模板2-控件定义：对界面上的每个字段进行详细的定义。

（3）模板3-规则说明：对界面整体进行说明。

（4）模板4-逻辑图形：对界面内复杂的数据关系等用图形方式进行说明。

利用这套结构化的标准模板定义一个界面的设计，表达的结果非常严谨、直观。虽然是需求工程师做的界面设计，其内容不但客户方看得懂，编码工程师也看得懂，且三方都不会有歧义。这种形式的文档编写效率高、质量高、不易出错、易于复用，而且非常便于在不同工序之间进行传递与继承，是满足工程化要求的标准文档。

2）不符合工程化要求的标准文档

作为对比，再看一个符合标准化，但不符合工程化要求的例子，如图1-12所示。

这类标准文档通常只使用具有统一标题和表格的模板。这种以文字描述为主的文档表达形式，只要在规定的表格内进行描述就可以，其描述的内容因为缺乏不同维度的标准约束（如设计用的4件套模板），很容易因描述人的表达水平不同，读取人的理解不同，最终产生不同的解释，从而得出不同的结论。这种方式不但在表达形式上不标准，在编写、阅读、复用等方面的工作效率也比较低，而且还容易出现质量问题。

目前大多数的软件公司采用的是这种没有工程化要求的标准化文档。这也说明了为什么它们推进的开发标准化没有获得明显效果，花费了大量的时间、人力和物力后仍在为不断发生的问题所困扰。

1.4.4　标准化与软件工程

以上讲述了软件标准化的思路和具体要求，下面看一下如果真正实现了软件标准化，那么将会对1.1节～1.3节中提到的问题产生什么样的影响。

从前面的讲解已经知道，解决这些问题的基础，首先就是要做到软件工程的标准化，所以本节先来看一下软件标准化对软件工程的影响。

按照工程化标准的要求，对软件工程各个阶段的工作对象进行标准化处理，图1-13是《大话软件工程——需求分析与软件设计》一书中给出的软件工程各阶段的标准工作对象，这些标准化的工作对象满足了工程化的要求。

从图中可以看出，沿着软件工程的工程分解走向（横向），每个阶段的工作内容（纵向）都被拆分，并进行了符合工程化要求的标准化。按照图中的结构进行需求分析和软件设计，每一步都有相应的理论、方法、标准和模板做支撑。这样软件开发的过程就会变得非常有序，并且可以同时实现高质量和高效率，每个岗位的人都知道自己在做什么，所做工作的输入和输出是什么，交付物是什么，交付的标准是什么，等等。

本书给出了一个软件开发的案例，完全就是按照这个软件工程框架提供的知识和流程进行的。对这个框架更加详细的量化和标准化说明，参考《大话软件工程——需求分析与软件设计》相关篇章。

1.4.5　标准化与项目管理

再来看一下软件标准化对项目管理的影响。

从图1-14可以看出，项目管理中的“Ⅱ.项目规划”“Ⅲ.项目执行”“Ⅳ.项目监控”与软件工程的标准化有着密切关系。如果软件工程相关内容的标准化做好了，自然而然地项目管理中与之相关部分的标准化就很容易进行。下面对项目管理中的Ⅱ、Ⅲ、Ⅳ项进行说明。

Ⅱ.项目规划：由于对工作内容（分析、设计、文档等）进行了量化，相应的工作量、需要的人力资源、计划工期等的计量都变得容易、精确。

Ⅲ.项目执行：由于有了符合工程化要求的软件标准，处理流程、各类模板，开发过程上下游工序成果的传递与承接都是符合要求的，因此可以按照预先制定的进度、工期、质量、成本等的标准推进项目。

Ⅳ.项目监控：由于建立了符合工程化要求的软件标准，所有的工作内容都有相应的标准（包括交付物、交付内容、验收标准等）。因此项目监控不但容易做到，而且可以做到精准的控制和验收。

有了这样的软件标准化作基础，就可以采用更加科学的管理方法，对于最终达成软件项目管理的三大目标（质量、进度和成本）也就更有信心了。

1.4.6　标准化与软件开发

最后来看标准化对软件开发的影响。

由于软件标准化改变了软件工程和项目管理，那么基于软件工程和项目管理的标准化，也一定会对软件开发的过程带来重大影响。

从软件开发的标准化来看，二阶段的技术设计和编程方面已经做了很多贡献，例如SOA、平台式架构、低代码开发等，同时硬件技术的进步也大幅度地改善了技术的不足。但是二阶段相关的技术和硬件进步并不能直接带动一阶段分析和设计水平的提升。长期以来，一阶段的工作方法几乎没有显著的进步，缺乏一套符合一阶段业务人员工作内容和习惯的、完整的、体系化分析和设计方法。可以说，一阶段低水平的分析和设计成果抵消了二阶段进步的效果，拉低了软件系统整体开发水平和客户价值。

从建筑、汽车制造等其他传统行业的发展过程来看，早期这些行业的工作方式也是非标准化的。

●建筑行业：早期采用现场砌砖、搅拌砂浆水泥、绑钢筋等方式建造房屋，通过构件化、标准化，继而实现了在工厂流水线制造构件，在现场用机械吊装的模式。

●汽车行业：早期从手工作坊开始，通过模块化、标准化，实现了流水线的生产模式。实现了标准化生产的同时实现了产品质量和生产效率的大幅提升。

建立了软件工程的标准化、项目管理的标准化后，再进行标准化的软件开发就有了基础，达到或接近其他行业的管理水平和效果就有了可能。成功的软件开发过程必须要有软件工程和项目管理二者的紧密结合与协同。这里参考《大话软件工程——需求分析与软件设计》一书提出的“分离原理”中的关于“业务”和“管理”的拆分，来说明软件工程和项目管理各自所起的作用。将完成软件开发的过程看作一个“工程”，支持工程业务的技术来自软件工程，支持工程管理的技术来自项目管理。

●软件工程：提供软件开发所需要的知识，包括分析、设计、编程和测试等一系列工作的理论、方法、技术、标准、规范等。

●项目管理：给出达成开发目标和确保软件工程得以正确实施的保证措施，包括组织、流程、管理、规则等内容。

软件工程与项目管理是相互作用的，如果没有软件工程作方法和标准的支持，科学的、高效的软件开发过程是不可能实现的，项目最终难以按预定规划完成，当然项目管理的3大目标（质量、进度和成本）也就难以达成。同样，如果没有项目管理作组织和保障支持，确保各工序之间按量、按时、按质进行成果交付，单靠软件工程也无法按照预期目标开发出优秀的产品。软件工程和项目管理是相辅相成的，缺一不可，因此只有实现标准化，才可能同时提升这两个技术的实现效率和效果。

本书所举的软件项目开发案例，就是按照这种理想的标准化方式进行的。读者可以感受到按照标准化方式作业的开发过程是如何提升工作效率的，并在满足客户需求的前提下，同时达成项目管理的3大目标。

影响项目管理3大目标的因素有很多。下面选取与软件工程相关的因素，就如何达成项目管理3大目标的方法做进一步的说明。

1.5　标准化与项目质量

从本节开始，共分3节讲解软件标准化对达成项目管理3大目标的影响。本节首先介绍对项目管理3大目标之一“质量”的影响。

1.5.1　影响项目质量的因素

软件产品和建筑、机械等使用寿命很长的产品一样，对客户和制造商来说，最终交付产品的质量永远都是第一位的。影响软件产品质量的问题有很多种，这里重点讲解在一阶段（分析和设计）工作中存在的问题。

1.需求阶段易发生的质量问题

1）调研与分析方面的问题

由于缺乏实用的分析理论和方法做指导，需求工程师面对收集的散乱需求，不知从何下手梳理、归集，不会判断已获取的需求是否完整、到位，同时也缺乏识别需求真伪的方法。需求分析的担当者自身不能确定需求分析的结果是否正确。

需求的不确定是造成开发结果返工，甚至系统推倒重来的重要原因之一。

2）需求记录的标准问题

缺乏标准的需求记录方式，记录时不区分记录业务逻辑、功能原型、数据的形式，需求描述大多用文章体的文字记录。这样做不统一、不严谨、歧义多，而且容易发生遗漏。这种纯文字的描述方式难以准确地将需求传递给后续的工序。

需求记录描述得不准确、不规范，是造成后续需求失真的重要原因之一。

2.设计阶段易发生的质量问题

1）设计方面的问题

设计方面的问题在于，由于缺乏统一、实用的设计理论、方法和标准作指导，同时大多数的软件公司没有给设计师设置相应的工作环节和岗位，因此很多时候需求工程师把从客户那里获得的需求直接作为编码依据交给后续的程序员。殊不知“客户需求”和“软件设计”是两个不同的概念。这就如同在建筑行业，当业主提出了盖房子的要求后，省略了设计院设计图纸的环节，施工公司直接按照业主的要求盖房子一样，这样的做法其结果可想而知。

缺乏设计或者完全没有设计环节是另一个影响项目质量的重要原因。

2）设计记录的标准问题

与需求阶段的问题一样，设计阶段也缺乏标准的设计结果表达方法。设计结果应该是一阶段结束的标志，二阶段按照一阶段的设计成果展开工作。设计文档不标准、歧义多，甚至没有设计文档，是造成后续工作发生问题时相互推诿的重要原因。

由于分析与设计的成果没有标准化，且项目组成员能力参差不齐，造成分析不到位，设计不清晰，再加上缺乏验收标准，所有的设计结果都是模糊的，逻辑不清楚且因人而异，这些问题造成开发中沟通时间长，开发完成后需要大量返工。分析与设计的质量低下，带来的问题往往会大于编码Bug带来的影响。因为后者的错误是局部的，而前者的错误轻则返工，重则可能推倒重来。

可以说，一阶段的错误对于系统是致命，有时甚至是不可挽回的。除去个人能力不足造成的问题难以在短时间内得到解决以外，如果能够建立分析和设计的标准体系，推广标准化作业，那么也可以明显地提升一阶段的成果质量（参考建筑行业发生的变化）。

确保项目质量的关键之一就是做好需求分析和软件设计。下面重点介绍两个可以明显改善项目质量的对策：一是分析和设计方法的标准化，二是记录文档的标准化。

1.5.2　对策1：分析与设计的标准化

解决项目管理质量的对策首先是将分析和设计的方法进行标准化。做好一阶段分析和设计的标准化需要有1套基础能力和2套标准方法。

（1）基础能力：专业用语、逻辑思考与逻辑表达的能力。

（2）标准方法1——需求方法：包括需求调研三方法（图形、访谈和表单）和需求三分类的转换（目标需求、业务需求和功能需求）。

（3）标准方法2——设计方法：包括设计工程三阶段（概要、详细和应用）和设计工作三层次（架构、功能和数据）。

其中，（1）的内容是做好（2）和（3）的基础，（2）和（3）的内容是一阶段工作的主要成果，也是二阶段工作的输入。只要（2）和（3）的过程和成果都实现了标准化，并且被熟练地掌握和运用，那么一阶段工作成果的质量就能够获得极大的保证，同时也奠定了二阶段工作获得高质量成果的基础。

1.基础能力

1）专业用语

专业用语指的是在分析和设计中，客户与软件公司双方交流时使用的专用名词。统一用语是软件项目开始运行的第一件工作，也是重要的标准化工作。双方的用语如果不在第一时间进行统一，就会造成后续交流时的误解、歧义，甚至在系统完成后返工。例如客户的业务用语“成本”，它的定义、用途、计算方式等在同一家公司内部只能有一种解释，不能在销售部门、财务部门、生产部门之间的有不同的称呼。如果确实不一样，则必须要加以不同的定义，最好是在“成本”一词的前面加上不同的前缀，如生产成本、财务成本、销售成本等。

同时，用户也必须掌握与系统相关的用语，例如流程、系统、架构、功能、界面、数据等，以确定需求工程师要做的系统功能有什么用途，是否与自己的需求相符合，而且未来在信息化管理环境中工作时，用户也必须使用这些用语。

2）逻辑思考与表达能力

逻辑思考与逻辑表达是正确地分析和设计的基础能力，只有内在思考的逻辑正确，才有可能让外在的逻辑表达正确。很多系统的流程和功能看上去是混乱的、不清晰的，其实质是研发者思考的逻辑不对，或是思考的逻辑虽然正确，但逻辑表达的方法不正确，结果就造成了后续一连串的错误。因此不要把分析和设计的标准化简单地理解成不用思考，只需利用各类模板“依葫芦画瓢”就可以了。没有正确的逻辑思考作指导，按照模板做出来的成果再规范也可能是错的。关于逻辑方面的学习内容主要有两个：思考方法和表达方法。

（1）逻辑思考方法：逻辑思维是分析性的、有条理的。做逻辑思维时，每一步必须准确无误，否则无法得出正确的结论。面对线下纷杂的客户业务和原始需求，运用逻辑思考整理出条理清晰的系统需求是非常重要的基本功。

（2）逻辑表达方法：是将逻辑思考的结果可视化，落在纸上（用图形、文字等方式），并向他人正确传递的手段。不论是编制需求规格说明书，还是做架构和设计，正确的逻辑表达都是不可或缺的。

【参考】关于提升逻辑思考与逻辑表达的能力，参见本书的附录A。

2.标准方法1——需求方法

1）目标需求

目标需求来自客户企业的经营管理者、项目投资人。目标需求说明了企业高层对信息化的目的、目标、期望等，建立对目标需求的正确理解和精准分析方法，是决定项目成功与失败的基础和关键。

2）业务需求

业务需求来自客户企业的最高层管理者。业务需求说明了企业管理层希望系统可以应对哪些业务，如何对应。指导业务需求的是高层的目标需求，建立从目标需求向业务需求转换的方法是目标需求落地、业务需求细化的基础。

3）功能需求

功能需求来自所有客户的各个层级，主要是未来系统的直接用户。功能需求说明要在系统中具体提供什么样的系统功能。建立从业务需求向功能需求转换的方法是业务需求落地、功能需求细化的基础。

3.标准方法2——设计方法

1）架构设计

架构是软件工程框架图中第一层的设计对象。架构设计指的是用图形方式表达的业务形态，也是业务逻辑的重要表达方式之一。标准的图形称为模型，主要有分析模型（需求分析用）和架构模型（业务架构用）。用图形表达逻辑直观、易懂、无歧义，用架构图形表达的业务逻辑如果没有错误，就可以确保系统不出现致命错误。

2）功能设计

功能是软件工程框架图中第二层的设计对象。功能设计指的是用界面形式表达的业务形态，它定义了系统中的全部数据，给出用户使用系统的具体内容和操作方法。功能的设计是系统设计和编码工作中数量最大的部分，它不但承载了具体业务数据输入与输出的需求，同时也承载着企业对业务在管理控制方面的要求。

3）数据设计

数据是软件工程框架图中第三层的设计对象。数据设计指的是对采集的数据进行加工以满足各类应用需求，其中数据标准的规划和规范不仅关系到本系统的运行，而且关系到与其他系统的融合，确保未来不出现信息孤岛的问题。

【参考】《大话软件工程——需求分析与软件设计》第11章、第14章和第18章。

1.5.3　对策2：记录文档的标准化

解决项目管理质量的第二个对策是记录文档的标准化。有了分析和设计方法的标准化，还要做到分析和设计的记录标准化。因为记录是分析和设计成果的载体，它可以确保分析和设计的成果被正确地传递和继承。

建立项目方案的实施、验收标准。为了标准易于被执行和验收，应尽可能地采用模板的形式完成设计和记录，例如文档模板、表格模板、流程模板等。这样可以避免每个人对标准的解释不同而造成结果不同，同时有了模板作基础，文档的复用、验收效率也会大幅提升，有利地支持后续的进度管理和成本管理。

1.标准化的条件

支持高效率、高质量工作的模板，要按照工程化的要求进行设计。模板要满足下面的两个条件（不限于此），即结构化、可传承。

（1）模板结构化：指不论是图形模板还是文字模板，都需要实现结构化。结构化的模板规律性强，容易理解和掌握，不易产生歧义，不易发生失真等，可以同时提升编写者和阅读者双方的工作效率。

（2）模板可传承：指按照软件工程的流程，上游向下游传递的文档必须满足下游工作的标准要求，且下游工序必须继承上游工序的成果，这就要求上下游的传递与继承标准是一致的。标准包括专业用语、逻辑图形、算式规则等。

2.标准化的内容

具体的标准化交付物包括架构、功能和数据3个主要内容。

（1）架构图：模型（框架图、分解图、流程图等）、记录模板（流程5件套）等。

（2）功能图：分类（活动、字典、看板、表单）、记录模板（业务4件套）等。

（3）数据表：分类（过程数据、基础数据等）、主数据、数据标准等。

进行标准化作业后，即使初期分析和设计做得不够完善，但由于是标准化的表达和记录方式，出现了问题可以清楚地看出来，并且可以反向追溯，找出问题发生的原因，从而在早期解决问题，大幅减少或避免在开发完成后的返工现象。

【参考】《大话软件工程——需求分析与软件设计》第2章～第4章。

1.6　标准化与项目进度

本节介绍软件标准化对达成项目管理3大目标之二“进度”的影响。

1.6.1　影响项目进度的因素

影响项目进度的因素有很多，但是大多数软件公司和项目经理首先想到的就是要尽量压缩一阶段的工作（需求、设计）时间，尽可能地将大部分时间留给二阶段的编码工作，认为只有这样做才是确保开发工期不超标的最佳方式，但这样做是否能达到预期目的呢？结果是大多数开发项目的工期最终是超标的，可见压缩一阶段的时间，结果也未必能按期交付。这就是说项目进度超期一定另有原因。这里列举两个造成影响的因素：量化和表达方法。

1.量化的影响

工作对象不能量化，造成标准化不到位，而标准化不到位则工作效率低。工作效率低是影响进度的重要原因之一（不限于此）。

1）缺乏可执行计划

由于工作内容没有量化，也就没有标准化工作成果的积累，所以无法编制一份可执行、可检查、可验收的有效执行计划。因为没有这样的计划，就无法进行有效的项目进度管理。

2）工作分配不能量化

没有软件工程的基础，且分析、设计和开发的内容做不到可量化，同时也缺乏对人才能力的量化评估，因此难以确定一个开发项目“需要多少人、具有何种能力、在多长时间内、完成什么难度的工作、交付多少成果”等的计量问题。

3）成果不能复用

复用包括对历史成果的直接复用、方法的复用，以及模板的复用。因为缺乏分析与设计的量化标准，每个岗位都有自己的表达方式，这不但增加了不必要的沟通困难，而且成为了成果复用的障碍。提升复用率是进度管理的重要保证。

2.表达的影响

1）沟通时间长

由于缺乏标准化的分析和设计方法，使得客户与需求工程师之间、需求工程师之间、需求工程师与编程工程师之间的沟通时间非常长，不但效率低，而且质量差。

2）无法检查和验收

由于没有量化，没有标准化的交付物，无法建立检查和验收的标准，结果也就无法进行有效的检查和验收。检查和验收凭经验，难以看出交付物中存在的错误。这些错误可能在编码完成后的测试中出现，或在上线后被用户发现，这势必会造成开发返工。

3）需求失真

由于在一阶段的各个环节中出现了对需求理解的差异（分析、设计、记录），造成最终的需求失真问题，而需求失真是造成进度管理失控的重要原因。只要发生了开发返工，则进度管理就是失败。确保项目进度的关键之一就是做到开发不返工。

1.6.2　对策1：路线图与计划

建立软件的标准化之后，就可以在标准化的基础上进行进度计划的编制。

1.调整岗位与时间

在进行路线图和计划的编制前，先对传统的开发过程进行调整和优化。

前面谈到确保进度计划达标的重要措施是不返工，而确保不返工的最有效措施就是分析和设计的全过程和交付物实现标准化。按照工程化的方法，对开发过程的岗位设置和所需时间进行优化，可以将各个阶段的时间比例进行如下调整，参考图1-15。

L1和L2为两条不同开发方式所用时间的分配比例示意。其中L1为传统方式，L2为改进后符合工程化要求的软件标准化作业方式。从图中可以看出，相较于传统的L1开发方式，L2的开发方式有如下变化。

1）一阶段内容

（1）需求：由于有标准化方法的支持，L2在需求调研、需求分析阶段花费的时间较L1缩短，正确率增加。

（2）设计（业务／应用）：新增业务／应用设计的环节，以弥补传统方式L1在设计方面严重不足的缺陷（不但可以消除开发返工，而且可以提升客户价值，响应需求应变等）。

2）二阶段内容

（1）设计（技术）：由于前面业务／应用设计的标准化，提供的文档符合技术要求和阅读习惯，实现了上下游之间设计文档的传递与继承，L2节省了技术设计时间，同时也大幅减少了业务和技术之间的无效沟通时间。

（2）编码：由于需求正确，设计逻辑清晰，可以减少编码的错误。且由于编码技术的进步（低代码、装配化、平台化等），L2的编码部分所需时间缩短最为明显。

（3）测试：同理，由于需求和设计阶段的错误少，编码阶段的错误也就少，因此L2的测试工作时间就会缩短。

（4）返工：由于前面各个工序的正确实施、传递，最终L2实现了大幅减少返工用时。

总结一下，最终，采用工程方式（L2）比采用传统方式（L1）进行软件开发不仅有明显的工期缩短，而且还会带来效率的提升和质量的提升。

2.实施路线图

根据新调整过的工序和步骤，下面绘制实施路线图。

实施路线图的绘制要以软件工程、项目管理和《工作任务一览表》等内容为依据，实施路线图的特点有以下几点（不限于此）。

●路线不与进度时间、人力资源等相挂接。

●仅考虑有哪些关键工作步骤、步骤的顺序、各步骤的关键交付物等。

它的主要依据是软件工程框架，是给后续各种规划提供一个粗略的、方向性的标识，实施路线图一般不需要太过于重视细节（太细了，反而不容易看清楚主体，它的作用与后面的里程碑计划图是相似的、匹配的），参见图1-16。

3.里程碑计划（粗粒度）

里程碑计划，顾名思义，就是要确立项目开发过程中关键内容的交付节点，并在此树立里程碑标志。这是项目推进过程中的关键识别节点，也是重要工作的控制点。

里程碑计划图的绘制方法比较简单，就是利用甘特图的形式绘制。首先画出时间表格，然后以这个时间表格为背景框，以合同工期为横轴，以实施路线图中的关键工序为纵轴，图中横置的柱形为关键作业内容，小旗子（里程碑）作为标志，表明该部分工作完成的时间点，参见图1-17。

里程碑计划的编制需要以《工作任务一览表》／实施路线图为依据。里程碑计划是客户和软件公司的双方领导最关心的内容，也是把握整体和关键节点进度的重要方法。通常客户和软件公司的双方领导开会或检查工作时，基本是以里程碑计划图为主要参考资料的。

另外，注意里程碑计划不要设置过于详细的内容，只挑关键的节点表达即可。

4.执行计划（细粒度）

相对于表达粗粒度关键节点的里程碑计划，项目的执行计划就是具体指导作业的详细计划（细粒度）。执行计划的编制需要以《工作任务一览表》／路线图／里程碑计划为依据。如图1-18所示的表是项目经理日常管理项目的直接抓手，因此执行计划要详细到具体的月、周、日、担当者、交付成果等。编制进度的执行计划，重点考虑以下5个步骤（不限于此）。

（1）收集作业内容：以《工作任务一览表》为依据，收集项目全部的作业内容，不限于软件工程相关的工作，也包括项目管理必需的工作（项目启动、项目收尾等）。

（2）确定实施路线：确定作业内容的最佳实施路线图，需要参考软件工程框架图、项目管理流程图等。

（3）建立时间坐标：参考项目合同的工期、开发的关键节点等，建立时间的坐标轴。可以利用专业项目进度管理软件，也可以利用表格软件自行设计。

（4）计算所需资源：根据作业内容的数量、工期日数，确定完成作业内容所需要的人数，包括项目经理、各类高级岗位、项目组成员等。

（5）整合前述4项：将前述4项内容（作业的内容、路线、时间和资源）进行整合，用路线图与时间轴叠加，在各时间段下标注作业的内容、资源量等，形成计划。

5.里程碑计划和执行计划的关系

执行计划是里程碑计划的详细展开，也可以说，里程碑计划是从执行计划中将关键节点抽提出来形成的。通常在客户与软件公司双方高层领导参加的会议上，讨论有关进度的问题时是以里程碑计划为参考的。这样可以忽略细节而关注重点，而且大领导们也不太清楚计划细节（也不必太清楚，因为他们同时需要管理多个项目）。他们只要定期监控里程碑关键节点的进度就可以了，而执行计划则是项目经理用于对每个人、每一天、每项工作、每个交付物的详细安排和监督。

1.6.3　对策2：复用与标准化

关于对项目进度计划的管理，除去通过路线图和计划控制外，提升历史项目成果的复用率也是非常重要的措施。复用的对象包括分析和设计用的标准模板、已经交付的历史项目文档等。

1.模板的复用

使用标准模板是确保进度的最简单、高效的方法。按照软件工程的流程，预先准备好每个阶段、每个环节交付物对应的模板。准备的模板越周全，效率越高，越不容易出现遗漏，特别是对新人较多的项目组来说作用非常大。从咨询开始直到设计完成，下面3个阶段需要准备的模板数量会非常大。

（1）咨询阶段：咨询问卷、交流方案、解决方案。

（2）需求阶段：调研模板（包括图形用、访谈用、表单用模板）、分析模板、规格说明书等。

（3）设计阶段：概要设计模板（包括框架图、分解图、流程图）、流程定义5件套、详细设计模板、界面定义4件套等。

2.文档的复用

建立文档库，将已完成的系统文档按照分类进行保存。然后可以根据新项目的类型进行匹配，找到相似的需求分析和设计文档。

通常设计阶段实际设计的功能（界面）数量要比需求阶段获取的原始需求数量多得多。这是因为需求阶段获得功能需求大多来自于用户，仅考虑某个模块中一些核心的业务处理功能。而进入设计阶段，通过架构设计后，为确保该模块运行会增加很多功能，如增加字典类功能、看板类功能和可以打印的表单类功能等，增加数量的多少会由于项目特点、组员经验而有所变化，但是通常会带来多达20%～50%的功能数量增加。如果有文档库作参考，项目组在规划进度时就可以周全地考虑工作量，避免遗漏。系统的文档库也可以帮助新组员快速地熟悉分析和设计的内容。

1.7　标准化与项目成本

本节介绍软件标准化对达成项目管理3大目标之三“成本”的影响。

1.7.1　影响项目成本的因素

最终的项目成本管理结果决定着软件开发完成后软件公司是否会得到收益。与质量目标和进度目标一样，标准化也极大地影响着成本目标的达成。如果有标准化作支撑，那么从合同签订的合同额估算开始，编制项目计划的工作量和人员数量的计算，直到交付物的产生和检查，标准化有助于在项目执行过程中大幅减少各类影响成本的风险，因此标准化对成本的控制也起到了重要的保障作用。

相反，如果没有标准化作参考依据，所有的内容都是靠经验，拍脑袋，那么从项目合同的估算开始就容易出现误差（这个误差会造成签订的合同额与开发工作量不匹配），再加上后面计划的误差，以及项目过程的不可检查和不可控制的风险，这些问题积累到一定程度后，一定会触发进度问题（因为要赶工期），继而影响成本。在项目实施过程中，不论是进度失误、分析设计失误、质量失误还是其他的任何错误，最终要用多付出成本的方式来弥补失误，也就是说，每项没有做好的工作最后都直接或间接地用“赔钱”的方式来解决。

建立交付物内容的标准化，对人才能力评估的标准化，以及作业过程（流程）的标准化，是确保项目成本不超标的重要保证措施。下面介绍两个最基本的对策（仅作参考）：交付物的标准化和人才能力的标准化。

确保项目成本的关键之一就是做好交付物和人才能力的标准化。

1.7.2　对策1：交付物的标准化

前面重点介绍了记录文档标准化的重要性。工作内容指的是各阶段的交付物，包括合同协议书、工作任务一览表、项目计划、分析与设计标准等。由于软件公司不同，建立的标准格式也会有所不同。可以先针对每项工作建立一个基本模板，然后在工作过程中不断完善、改进。

这里要注意，编制标准化的文档必须以内容的量化为前提，不能进行有效的计量、检查和控制的标准化是没有效果的。初期可以先少量地开始，一个点、一个点地逐渐量化、标准化，再在实践中不断地完善和改进。流于形式的标准化最好少做或不做。

这里举个例子来说明交付物标准化的效果。不论是在需求调研、设计、编码和测试的哪个阶段，界面相关的工作量都是最大的，大约占各阶段总工作量的70%以上。虽然它的工作量大，但却非常容易进行标准化（参见图1-11的4件套形式）。如果通过标准化的形式可以将它的工作时间减少20%，那么软件开发的总体时间就可以节约0.2×70%=14%。通过时间和人月单价，就可以反算出节约的成本值。

1.7.3　对策2：人才能力的标准化

对人才能力的评估也要尽可能地做到标准化。因为对人才能力的评估会极大地影响合同金额和工期，软件行业在确定合同金额时常以“人月单价”为基础的计算方式，即

合同金额=开发月数×所需人数×费用／人月（单价）

设定人才能力标准要与所做的工作内容标准相匹配，如做需求分析或业务架构，那么担当者就必须知道需求分析或业务架构的相关理论、方法、工具和标准，才能完成此任务。人才能力标准化举例（不限于此）如下。

●按照标准，可以做什么样的业务架构，如业务规划、流程图。

●按照标准，可以设计什么样的业务功能，如字典界面设计。

●按照标准，可以做什么样的数据架构和设计，如主数据、数据标准。

如果对组员的能力没有掌握，也没有标准单价的计算方法，那么即使签了开发合同，将来在开发过程中还是会发生很多问题，最后难以按质、按时、按量完成合同约定的工作。

【参考】关于人才能力的评估，参见本书的附录B。

以上对软件开发过程所需要的理论、方法进行了讲解，希望读者在阅读后面的项目案例时，可以时刻想起本章的内容。通过案例，不但可以了解项目的开发过程，而且可以了解该如何做好这个项目。