系统集成项目管理工程师5天备考第1天第4-6学时（1）

信息系统集成专业技术知识的涉及面非常之广，不过不必钻研过深，但也需要了解。虽然第4-6学时中的知识点大多出现在上午试题中，但下午的试题都是有关IT项目的案例，了解这些知识点不至于下午的案例看不明白。

本处3个学时中主要涉及信息系统建设、软件开发模型、软件工程、软件过程改进、软件复用、面向对象基础、UML、软件架构、SOA与Web Service、数据仓库、软件构件、中间件技术、J2EE与.NET、工作流技术与Ajax、计算机网络基础等方面的知识、信息安全知识，其中的某小块知识点在计算机专业的大学、研究生阶段可能就是一门课程，因此知识涵盖的面很广。下面来逐一学习。

一、信息系统建设

信息系统的生命周期分为四个阶段，即产生阶段、开发阶段、运行阶段和消亡阶段。

（1）产生阶段。也称为信息系统的概念阶段、需求分析阶段。这一阶段又分为两个过程，一是概念的产生过程，即根据企业经营管理的需要，提出建设信息系统的初步想法；二是需求分析过程，即对企业信息系统的需求进行深入的调研和分析，并形成需求分析报告。

（2）开发阶段。这个阶段是信息系统生命周期中最为关键的一个阶段。该阶段又可分为五个子阶段，即总体规划、系统分析、系统设计、系统实施和系统验收子阶段。

（3）运行阶段。当信息系统通过验收，正式移交给用户以后，系统就进入了运行阶段。

（4）消亡阶段。企业处在瞬息万变的市场竞争的环境中，企业的信息系统经常会不可避免地遇到系统更新改造、功能扩展，甚至是报废重建的情况，一个信息系统也必然后逐渐消亡，因此企业在信息系统建设的初期就要注意系统的消亡条件和时机，以及由此而带来的成本。

信息系统的开发方法有：结构化方法、快速原型法、企业系统规划方法、战略数据规划法、信息工程方法、面向对象方法。

结构化方法的开发过程一般是先把系统的功能看成是一个大的模块，再根据系统分析与设计的要求对其进行进一步的模块分解或组合。

快速原型法是一种根据用户需求，利用系统开发工具，快速地建立一个系统模型并展示给用户，在此基础上与用户交流，最终实现用户需求的信息系统快速开发的方法。

BSP（Business System Planning，企业系统规划方法）是企业战略数据规划方法和信息工程方法的基础和，也就是说，后两种方法是在BSP方法的基础上发展起来的，BSP方法的目标是提供一个信息系统规划，用以支持企业短期的和长期的信息需求。

战略数据规划方法是由世界级的信息系统大师詹姆斯•马丁提出的一种信息系统开发方法。这个方法认为，一个企业要建设信息系统，它的首要任务应该是在企业战略目标的指导下做好企业战略数据规划。一个好的企业战略数据规划应该是企业核心竞争力的重要构成因素，它有非常明显的异质性和专有性，好的企业战略数据规划必将成为企业在市场竞争中的制胜法宝。在信息系统发展的历程中共有四类数据环境，即数据文件、应用数据库、主题数据库和信息检索系统。

信息工程方法与企业系统规划方法和战略数据规划方法是一种交叉关系，即信息工程方法是其他两种方法的总结和提升，而其他两种方法则是信息工程方法的基础和核心。面向对象法专用于面向对象的软件开发。

二、软件开发模型

软件开发的模型有很多种，如瀑布模型、演化模型、增量模型、螺旋模型、喷泉模型、构件组装模型、V模型等。

1.瀑布模型

瀑布模型的开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。瀑布模型适用于需求比较稳定，很少需要变更的项目。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即瀑布模型采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，如图所示，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。




瀑布模型

2.演化模型

演化模型如图所示，是一种全局的软件（或产品）生存周期模型，属于迭代开发风范。该模型可以表示为：第一次迭代（需求-->设计-->实现-->测试-->集成）-->反馈-->第二次迭代（需求-->设计-->实现-->测试-->集成）-->反馈-->……。实际上，这个模型可看作是重复执行的多个“瀑布模型”。




演化模型

演化模型根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。

3.增量模型

增量模型如图所示，融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。




增量模型

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但是更强调每一个增量均发布一个可操作产品。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

4.螺旋模型

螺旋模型如图所示，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。



螺旋模型

螺旋模型采用一种周期性的方法来进行系统开发。该模型是快速原型法，以进化的开发方式为中心，螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：

Ø 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件。

Ø 风险分析──分析所选方案，考虑如何识别和消除风险。

Ø 实施工程──实施软件开发。

Ø 客户评估──评价开发工作，提出修正建议。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。

5.喷泉模型

喷泉模型如图所示，是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。



喷泉模型

喷泉模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

6.构件组装模型

构件组装模型融合了螺旋模型的许多特征。它本质上是演化的支持软件开发的迭代方法。但是，构件组装模型是利用预先包装好的软件构件（有时称为“类”）来构造应用程序的。

开发活动从候选类的标识开始。这一步通过检查将被应用程序操纵的数据及用于实现该操纵的算法来完成，相关的数据和算法封装成一个类。以前的软件工程项目中创建的类被存储在一个类库或仓库中、一旦标识出候选类，就可以搜索该类库，确认这些类是否已经存在。如果已经存在，就从库中提取出来复用。如果一个候选类在库中并不存在，就采用面向对象方法开发它。之后就可以利用从库中提取出来的类以及为了满足应用程序的特定要求而建造的新类，来构造待开发应用程序的第一个迭代。过程流程而后又回到螺旋，并通过随后的工程活动最终再进入构件组装迭代。

7.V模型

V模型如图所示，它是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。在这种模型的测试过程中，首先，进行可行性研究需求定义，然后以书面的形式对需求进行描述，产生需求规格说明书。之后，开发人员根据需求规格说明书来对软件进行概要设计，测试人员根据需求规格说明书设计出系统测试用例。概要设计之后，开发人员根据概要设计对软件进行详细设计，测试人员根据概要设计设计出集成测试用例。详细设计之后，开发人员根据详细设计进行编码，测试人员根据详细设计设计出单元测试用例。编码完成之后，测试人员根据单元测试用例对设定的软件的测试单元进行测试，单元测试完成之后，进行集成测试，然后进行系统测试，最后进行验收测试。



V模型

8.RUP

RUP（Rational Unified Process，统一软件开发过程）是一个面向对象且基于网络的程序开发方法论。

根据Rational(Rational Rose和统一建模语言的开发者的说法，RUP好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP和类似的产品，例如面向对象的软件过程，以及OPENProcess都是理解性的软件工程工具，把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

初始阶段的目标是为系统建立商业案例并确定项目的边界，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。

　　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构里程碑。

　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能里程碑，此时的产品版本也常被称为“beta”版。

　　交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布里程碑。

三、软件工程

1.软件需求

软件需求包括三个不同的层次：业务需求、用户需求和功能需求、非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能需求包括产品必须遵从的标准、规范和合约，外部界面的具体细节，性能要求，设计或实现的约束条件及质量属性。

2.软件设计

软件设计是把许多事物和问题抽象起来，并且抽象它们不同的层次和角度。软件设计的基本原则是信息隐蔽与模块独立性。

内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高，相对地，它与其他模块之间的耦合性就会减低，而模块独立性就越强。由此可见，模块独立性比较强的模块应是高内聚低耦合的模块。



模块的独立性和耦合性

模块的独立性和耦合性如图所示。内聚按强度从低到高有以下几种类型：

Ø 偶然内聚，即巧合内聚。如果一个模块的各成分之间毫无关系，则称为偶然内聚。

Ø 逻辑内聚。几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。

Ø 时间内聚。如果一个模块完成的功能必须在同一时间内执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为时间内聚。

Ø 过程内聚。如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称为过程内聚。

Ø 通信内聚。如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。

Ø 顺序内聚。如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

Ø 功能内聚。模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚。

内聚性参考记忆口诀：“偶逻时过通顺功”。

耦合性由低到高有以下几种类型：

Ø 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。

Ø 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。

Ø 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。其实传递的是这个数据结构的地址；

Ø 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。

Ø 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

Ø 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

Ø 内容耦合：如果发生下列情形，两个模块之间就发生了内容耦合

耦合性参考记忆口诀：“非数标控外公内”。

3.软件测试

软件测试是指使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

软件测试从是否关心软件内部结构和具体实现的角度划分为白盒测试、黑盒测试、灰盒测试；从是否执行程序的角度划分为静态测试、动态测试；从软件开发的过程按阶段的角度划分为单元测试、集成测试、确认测试、系统测试、验收测试。

动态测试指通过运行程序发现错误；静态测试指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。

 黑盒测试把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。白盒测试把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。

桌前检查由程序员自己检查自己编写的程序。代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。

代码走查与代码审查的过程大致相同，但开会的程序与代码审查不同，代码走查不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

面向对象测试是与采用面向对象开发相对应的测试技术，它通常包括4个测试层次，从低到高排列分别是算法层、类层、模板层和系统层。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

第三方测试指独立于软件开发方和用户方的测试，组织的测试也称为“独立测试”。软件质量工程强调开展独立验证和确认（IV&V）活动，是由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程。软件第三方测试是由相对独立的组织进行的软件测试，一般情况下是在模拟用户真实应用环境下，进行软件确认测试。

4.软件维护

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。依据软件本身的特点，软件具有可维护性主要由可理解性、可测试性、可修改性三个因素决定。

软件的维护从性质上分为：纠错性维护、适应性维护、预防性维护和完善性维护。纠错性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征，这方面的维护占整个维护工作的50%～60%。预防性维护是为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

四、软件过程改进

软件过程改进（Software Process improvement，SPI）帮助软件企业对其软件过程的改进进行计划、制定以及实施，它的实施对象就是软件企业的软件过程，也就是软件产品的生产过程，当然也包括软件维护之类的维护过程。

CMM（Capability Maturity Model for Software，全称为SW-CMM，软件能力成熟度模型）就是结合了质量管理和软件工程的双重经验而制定的一套针对软件生产过程的规范。CMM是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

CMM将成熟度划分为5个等级，如图所示。



CMM的5个等级

（1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它依旧被视为初始级。

（2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

（3）已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

（4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变为一个工业生产活动。

（5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。

CMMI与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程和软件工程是基本的科目，对于有些组织还可以应用集成产品和过程开发方面的内容，如果涉及到供应商外包管理可以相应的应用部分。

CMMI有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法依旧把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。

CMMI也划分为5个成熟度级别，如下所示：

（1）完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候依旧能够完成任务。企业在完成级上的项目实施对实施人员有很大的依赖性。

（2）管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。

（3）定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。

（4）量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。

（5）优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。