0.1　关于本书

做企业管理类的信息系统分析和设计是否很难？多数从事这方面工作的读者会认为是很难的，特别是面对大型复杂的系统、或是首次遇到的新业务领域时就会感觉到更难。难在哪里呢？难就难在说不清楚难在哪里！

0.1.1　本书的背景

笔者从事企业管理信息化的咨询、分析、设计及培训工作已有二十多年了，在这个过程中接触了大量从事相关工作的同行，在交流过程中发现大家都存在着相似的问题，这些问题可以从用户与开发者两个视角来看。

1．从系统用户视角看

在经过了多年的信息化建设后，很多企业都构建了庞大的管理信息系统，但是从使用的效果来看，还存在着很多不尽理想的现象，提出三个最为常见的问题（不限于此）：应用价值、应变能力和信息孤岛。

1）系统的应用价值低

系统仅解决了执行层的“手工替代”问题，经营管理层存在着无数据和信息可用的现象，未能做到用管理信息系统“支持企业计划、组织、领导、监控、分析，提供实时、准确、完整的数据，为企业的经营管理者提供决策管理依据”的预期目标。

2）随需应变能力差

系统上线后，通常用户使用的频率越高，发生需求变化的频率也越高，但是系统的开发者难以快速地响应需求的变化。

3）信息孤岛问题严重

不同时期构筑的系统之间数据不能共享，而且非常难以解决，企业守着积累的大量数据，却难以进行二次、三次的应用，作为企业数据资产的价值发掘不出来。

2．从系统开发者视角看

软件开发企业同样有很多的苦恼，提出三个常见问题：产品价值、产品质量和产品复用。

1）产品价值的问题

软件企业的产品为客户带来的价值低，也造成了自身的收益少，收益少又影响了对新产品研发的投入，这种非良性循环带来了行业内的同质竞争、低价竞争的问题。

2）产品质量的问题（不考虑bug部分的影响）

开发产品的质量低，从需求调研到产品上线，缺乏一套可以支持软件全过程的设计方法体系，特别是在前期花费大量人力和时间获得的分析设计成果，其表达方式多以文字说明为主、附以一些简单的图形。这样的表达既无法与客户进行有效的确认，也无法向后续的开发人员精确地表达设计意图，不但沟通效率低，而且经常发生严重的需求失真、遗漏、设计偏差等问题，是造成系统质量问题的主要原因之一。

3）产品复用的问题

产品的复用率低，或者说几乎没有复用能力，这使得每开发一个新系统都要重复地做着初级劳动，造成高成本、低效率，其结果还带来了对客户需求变化响应速度慢的问题。复用问题不解决，即影响客户的满意度，也阻碍开发企业降低成本的能力。

3．产生问题的背景分析

基于笔者常年的观察与实践经验来看，造成上述诸问题的重要原因可以从软件工程的构成上看到。在传统软件工程中有需求工程和设计工程，但是在设计工程中没有如图0-1中②所示的环节，在①的工作完成后，就进入③的工作（或是直接就进入了系统的开发工作）。

图0-1的①和③框中显示的是一般常见软件工程的主要工作内容，这些内容基本上都是围绕着功能实现进行的，它们各自的重点如下。

①需求工程的重点是获取功能需求，以收集、分析及确定客户对系统的功能需求为主。

②设计工程——业务设计／应用设计部分的工作内容，先设计出理想的客户业务形态，然后以实现这个理想的业务形态为目标再来判断和设计需要的功能，将这些功能置于“为支持实现理想的业务状态而存在”的位置。②的设计是以需求实现后要为客户带来最大价值（效率、效益）为目标的。

③设计工程——软件设计部分，重点是如何实现功能，以系统结构、数据接口、数据库、界面等内容的设计为主。这些工作都是偏软件实现方面的内容。

打个比方，②的作用就相当于建筑行业的“建筑设计”、汽车行业的“汽车设计”环节，这些环节的核心目标不是“如何实现产品”，而是“如何实现客户价值”。没有②对应的角色，就如同在建筑设计院中有结构设计师、设备设计师，但没有“建筑设计师”，在汽车制造厂有发动机设计师、电器设计师，但没有“汽车设计师”。这个“业务设计／应用设计”环节就相当于“建筑设计”和“汽车设计”的环节。

0.1.2　本书的观点与目的

1．本书的观点

作者认为造成客户和软件开发者存在问题的主要原因有三个（不限于此）。

（1）软件工程：缺乏从“业务”视角的分析和设计方法体系。

传统的设计工程重点是针对“功能需求”的获取和设计。而完美的系统设计应该是先建立优化的业务体系，然后将“功能”看作为优化后的业务运行提供支持服务的信息化手段。

（2）软件企业：缺乏以“设计”为驱动的理念。

软件企业通常用“架构”的概念代替“设计”，但是“架构≠设计”，“架构”只是“设计”这个大概念的一部分，架构是“粗粒度的设计”，而完美的设计需要包括大到一个系统的整体架构，小到一个控件的精细描绘。

（3）软件工程师：缺乏以“客户价值”为导向的设计思想。

重“功能”轻“业务”的现象比较多，这样做会忽视客户信息化价值。完美的设计应以“客户价值”为引导，理解客户购买的是“价值”，功能是为实现价值而存在的。

2．本书的对策

因为传统的“软件设计”中缺乏“业务设计／应用设计”的内容，所以软件设计的成果是不完整的，因此，笔者将图0-1的“③软件设计”中有关“界面设计”的部分移到了图0-1的“②业务设计／应用设计”中，将原软件设计的其他部分称为“技术设计”，将“设计工程”的内容扩展成为三个阶段：业务设计、应用设计和技术设计，见图0-2，完整的软件设计应该包括“业务设计、应用设计和技术设计”三个阶段的内容。

由于客户价值获取的重点在需求工程阶段，为了保持分析与设计的完整性，本书的内容包括需求工程和设计工程，其中设计工程包括前两个阶段：业务设计、应用设计。

本书虽然不包含技术设计阶段的内容（此阶段的内容比较成熟，参考书籍丰富），但是给出了三个阶段设计成果的传递与继承内容、标准、协同关系。

3．本书的目的

本书的目的是探索并提供一套方法体系来支持上述的设计工程。为了达到这个目的，笔者为本书的编写制定了四个目标。

目标一：明确“设计”在软件工程中的定位。

传统的软件工程——设计工程中虽然在分类上使用了“设计”一词，但在实际的软件开发过程中采用更多的是“架构”一词。在“设计”这个大概念中，“业务设计／应用设计”是非常重要的部分，这个部分决定了系统的客户价值大小。明确“设计”（特别是业务设计／应用设计部分）在软件工程中的定位，可以提升整个行业对“设计”重要性的认知，同时也可明确从事“非技术类工程师”在软件过程中的作用、价值和地位。

目标二：构建“业务设计／应用设计”的方法体系。

构建“业务设计／应用设计”的方法体系，它是需求工程与技术设计之间的桥梁，这套方法体系以客户的价值设计为核心，同时它可以作为与管理信息系统干系人之间进行沟通、决策的“共同语言”。

注：关于干系人

干系人包括：客户方、软件企业的业务方、技术方及其他相关人（如监理等）。

（3）目标三：确定“业务设计／应用设计”方法体系的应用模式。

参照传统行业的分析和设计方法，让“业务设计／应用设计”的体系符合“工程化设计”的原则、标准、流程，使得从需求调研到设计完成之间的所有成果都是标准的、规范的，并且都是可传递、可继承的，让这些成果与后续的技术设计形成精确的无缝衔接。

（4）目标四：提升软件企业和软件工程师的设计能力。

设计，不论在任何一个行业都是龙头，提升了企业和员工的设计能力，不但可以提升产品价值、产品质量和产品复用的能力，而且还可以助力“业务人员”成为“业务设计师”，让开发“程序员”成为开发“工程师”。

0.1.3　本书的特点

为了实现本书的目的，在构建“业务设计／应用设计”体系时，为这个体系设定了“三化一线”的要求，其中，三化为图形化、标准化、工程化；一线为逻辑线。

1．图形化

软件行业缺乏用“图”来表达分析与设计的现象由来已久（UML可表达的场景有限，同时也不能为所有干系人理解和使用），因此本书为软件工程划分了不同的阶段和层次（参见后续的软件工程框架），在所有的设计阶段和层次中都提供了对应的参考标准图形。采用图形表达为主的方式可以大幅度地减少需求与设计的失真，图形化的表达方式可以明显地提升工作效率和产品质量。图形化表达是工程化设计的基础。

注：关于自然图形

本书采用的图形是“自然图形”表达方式，读者不需要经过特别的培训就可以理解。

2．标准化

软件行业不能用“标准”的方式进行设计、传递、检验也是一个普遍问题。为了解决这个问题，本书制定了从图形表达到文字描述的标准化方式。用这样的表达方式可以实现“需求调研→需求分析→业务设计／应用设计→技术设计”之间的无缝传递、继承。

3．工程化

有了前述的图形化、标准化作为基础，将软件实现的各个环节按照工程化的模式串联起来，使软件行业的设计过程和设计资料如同建筑业、制造业可以按照流程进行操作。

本书采用了不同于传统软件工程的知识体系表达方式，如图0-3所示。

1）思维导图方式

如图0-3（a）所示，传统的软件工程知识体系多采用的是“思维导图”式的归集方式，它将知识进行了归集和分类，但从知识体系的整体上不严格地强调各环节之间的输入与输出、成果的传递与继承标准、流程等关系。

2）工程化方式

如图0-3（b）所示，将知识体系按照实操的过程进行归集、分类，设计工程中的每个阶段、环节的成果都是相互衔接的，明确了前后环节之间的输入、输出关系，这种方式有助于软件企业建立可以定性、定量的开发流程管理、计划管理、资源管理、配置管理，建立可以规范化地检验各环节作业完成情况以及建立相应的检查标准。

4．逻辑线

本书从需求调研开始直至应用设计为止，全书始终以“逻辑”为分析和设计的指导主线，让读者按照逻辑思路去理解知识、同时按照合乎逻辑的结构形式去表达设计结果。在软件工程的使用过程中，始终以逻辑为流转、传递、承接的依据，“逻辑”的通顺，可以确保分析与设计结果经得起推敲。同时符合逻辑的设计结果确保了“业务人员”和“技术人员”对接、交流的正确无误。逻辑是分析与设计过程的灵魂。