1.4 本书的思路与方法
本书借鉴了各种软件工程方法学的理念、思想，同时又结合了企业管理类业务的特性进行了拓展、抽提，形成了适合于企业管理类信息化的分析与设计方法。
由于企业管理的复杂性造成了很多的差异，例如，不同行业之间的差异、相同行业内不同企业的差异、同一企业内不同业务部门之间的差异，以及业务与管理的差异等，各种差异和个性与共性的混合存在，使得在业务的分析与设计阶段，不能够单一地采用面向过程或是面向对象的方法，而是两种方法都有不同的用途，将二者的长处结合起来会带来比较好的效果。
已有的软件工程方法学比较偏重于软件的实现（不论是面向过程还是面向对象），但在实际的企业管理信息系统的实现过程中，在对业务进行分析和设计时常常遇到的问题是：客户并不清楚如何提出信息化的需求，没有做过管理信息化的企业在业务上都是很混乱的、很多衔接之处也是不交圈的，同时还要解决客户提出的期望、难点和痛点等隐性需求，因此软件工程师首先要解决这些问题，所以很难一开始就建立数据流模型或是理想的面向对象模型，这就是企业管理信息系统与其他类型系统之间的最大差异。
下面对比常用的几种分析与设计的方法，帮助读者理解本书的构成理念、目的和方法。
1.4.1 本书采用的方法
本书采用的方法是将面向过程与面向对象相结合，利用它们各自的优势去解决软件工程不同阶段的问题，通过面向过程的分析与设计方法搞清楚原始需求与业务优化；通过面向对象的分析与设计给出按需应变的模块化系统。
图1-11的示意图说明了通过将多样的业务对象①（不同的行业、不同的企业、不同的业务领域），通过业务分析与设计②的工作逐渐地收敛为固定的形态，然后交与后续的技术设计③和开发工程④。也就是说，在进入技术设计与编码工作的阶段后，业务信息的表达越少、变化规律越清晰，就越容易建立可以复用、快速应变的信息系统，开发完成的系统就越稳定。
图1-11 业务分析与设计的作用
因为技术的表达是通过编码方式实现的，由于编码有严格标准和规范，不论是什么样的业务形态最终都要将它转换为符合开发编码技术要求的形式才能实现，因此，各类的业务形态最终都要转换成为符合技术开发的形式。
1．需求工程
客户的需求来源于不同的行业、不同的企业、不同的领域以及不同的工作岗位，所以可以认为行业的范围是无限多的。
2．设计工程（业务、应用）
通过分析、设计，将业务形态进行抽提、归集，在完成了分析与设计工作后，无论有多少业务形式，其结果都被归集为架构、功能和数据的三层内容，此部分是从行业的原始需求到软件开发过程中收敛贡献幅度最大的部分，不但要解决业务优化的问题，它同时也是决定功能是否能够复用的重要设计一环。
3．设计工程（技术）
将设计工程（业务、应用）的设计成果进一步地进行抽提、收敛后，全部转换为技术的表达形式，如控件、接口、数据库等，可以看出，此部分相对于设计工程（业务、应用）又进行了进一步的收敛，但是收敛幅度已经减少，此部分的收敛幅度越小，说明设计工程（业务、应用）的作用越大，将来在实现功能的复用、提升系统的应变能力方面的效果就越好。此部分的工作使得设计成果完全符合开发编码的标准要求。
4．开发工程（技术）
由于前述分析设计的收敛效果，开发工程就相对地比较容易了，因为不论什么样的业务都被归纳为有限的形态。特别是在使用开发平台技术进行开发时，图1-11中设计工程（业务、应用）和设计工程（技术）起的作用越大，变化就越少，用有限的开发功能就可以完成开发工作，开发效率提高、成本降低。
关于图1-11中①～④之间比例关系变化对开发效率的影响，可参考图1-12，当需求工程面对的业务范围为M、开发工程（技术）的工作量为N时，开发工作量N的大小会随着图中设计工程（业务、应用）和设计工程（技术）收敛贡献的不同而变化。
图1-12 软件工程各阶段的作用与效果
（1）图1-12（a）：当图中②和③部分起的作用越大（②和③对①的收敛幅度贡献大），即N/M的值很小，则④需要的工作量就越小。
（2）图1-12（b）：当②和③部分起的作用越小（②和③对①的收敛幅度贡献小），即N/M的值很大，则④需要的工作量就越大。这个比例关系说明④的工作量容易随着业务需求的变化而变化。
（3）结论：②和③对①的收敛贡献大于④为好。
（4）虽然②和③都对①的收敛有贡献，但是希望②对①的收敛贡献更大。换句话说，就是“脏活累活都在②的阶段完成，整齐干净的工作尽可能地在③和④的阶段完成”。这样可以保持③的变化少，从而使得③和④的复用程度增大。
注：设计工程②的收敛作用
所谓的“收敛”，用②的作用来说明：①存在的不确定问题尽可能都在②中解决，而不要将①的问题放到②下面的③或是④中解决。在②中解决的问题越多，则②的倒梯形坡度越大，也就是对①的收敛的贡献越大。它的实际意义就在于如果把①中的部分业务问题放到③的技术设计中解决，就会造成系统耦合度高、开发成本增加，且不易于系统的复用和应变性。
1.4.2 面向过程与面向对象
作为与本书的方法对比参考，这里简单地介绍一下面向过程的方法和面向对象的方法。本书中虽然没有特别说明这两个方法的作用，但如果将这两个方法与本书的方法相比较，可以看出：在业务设计部分中（概要、详细）使用的方法接近于面向过程的方法，在应用设计部分中使用的方法接近于面向对象的方法，本书的方法是将面向过程和面向对象两个方法使用在了不同的设计阶段中。作者认为，作为从事需求分析和业务设计的工程师，需要同时掌握这两个方法，它们的结合使用才能完美地完成企业管理类信息系统的需求分析与业务／应用设计，两者之间不存在谁取代谁或是哪一个更加优秀的问题，特别是面对大型的、复杂的企业管理类信息系统更是如此。
参考1：面向过程的方法
面对企业管理类的课题，通常对于一个业务设计师来说是很难开始就从功能或是数据层面进行分析的，对他而言，初期与客户讨论时，讨论对象的粒度是经营、销售、采购、合同、投标、销售等，这样的一个词本身可能就代表一个系统，对这个词需要进行拆分若干层后才会出现数据，因此不能开始就从最细的数据粒度开始做数据流图，因为第一搞不清楚数据，第二容易从开始就陷入到细节中去，而是要以经营、销售等粗粒度的对象为节点，绘制业务逻辑图（业务架构图），这样的从粗到细易于与客户的高层进行交流、确认。
面对企业管理类型的信息系统，采用以业务逻辑关系表达为主的方法首先理清楚现状、业务逻辑、变化规律、范围、边界之后，再采用面向对象的方法进行细节的建模、分析、设计，不但可以降低初期研究的难度，而且可以有效地避免发生研究偏离目标的问题。
参考2：面向对象的方法
由于通过对业务过程的分析充分地理解了业务构成、业务逻辑以及变化规律，这样就可以设计出稳定的面向对象的模型。
在本书的描述中，没有具体地提到面向过程／对象的分析和设计方法，这是因为现实中大多数从事业务分析和设计的担当者是从某个业务领域转行而来的，他们并不掌握多少软件设计方法论的知识（面向对象的方法比较难理解和掌握），而且他们即使绘制了UML图形，也很难用这类图形与客户及其他相关人进行交流并作为确认的依据。
本书间接地将面向过程／对象的思想和理念融入到了设计说明中，如组合原理（黑／白盒、高内聚／低耦合等）、功能的业务设计和应用设计（模块化、组件化、构件等）。本书采用了业务分析和设计人员容易理解的非技术表达形式进行设计，采用自然表达方式绘制各类图形，它们不但容易为客户所理解，同时还容易为技术设计师所接受和继承（不论他是否采用面向对象的设计方法）。