【系统分析师之路】系统分析师必知必会（软件工程）

【系统分析师之路】系统分析师必知必会（软件工程）

一. 逆向工程/再工程

1）逆向工程

逆向工程最早来源于硬件，目的是分析产品，得出设计，是一个设计恢复的过程。
逆向工程的抽象层次分四层：抽象层次越高，完备程度就越低。
逆向工程的最高抽象层次/完备性最低的是：导出实体关系模型。
逆向工程的完备性可以用在某一个抽象层次上，提供信息的详细程度来描述，在大多数情况下，抽象层次越高完备性就越低。
是一个恢复设计的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。
No 导出内容 导出类型 详细说明 抽象层次 完备性
1 过程的设计 表示文档 过程的设计模型 低 高
2 程序和数据结构 信息 程序和数据结构信息 中低 中高
3 对象模型、数据流和控制流 模型 对象模型、数据和控制流模型 中高 中低
4 导出实体关系 模型 UML图，状态及部署图 高 低

2）逆向工程概念

分析已有程序，寻求比源代码更高级的抽象表现形式。
与之相关的概念包括软件重构、设计恢复、重构工程等。
软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序表示的过程。逆向工程是一个恢复设计的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。恢复信息的级别分为：实现级、结构级、功能级和领域级。

3）恢复信息的四个级别

1. 实现级

实现级主要包括程序的抽象语法树、符号表等信息；

2. 结构级

结构级主要包括反映程序分量之间相互依赖的关系的信息
包括调用图、结构图等；

3. 功能级

功能级主要包括反映程序功能与程序之间关系的信息；

4. 领域级

领域级主要包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。

4）再工程

不仅能从已有信息中重新获得设计信息，而且还能使用这些信息改建或重构现有系统，以改进综合质量。
一般软件人员用再工程重新实现已存在的程序，同时加进新的功能，或改善它的性能。
重构与性能优化的关系
分解良好的程序，由于代码更加清晰，更容易与性能优化工具结合，分析系统性能瓶颈的具体位置。
分解良好的程序，使得性能分析的粒度更细，性能调整也更加的容易。

二. 软件开发模型

模型的概念

模型是现实世界的抽象或近似，主要包括叙述型、物理型、图解型和数学型等。
无论开发何种模型，准确性都是最关键的因素。一个不准确的模型通常会导致对问题的不准确解决方案。
客观的世界是复杂的，当评估现实世界的对象之间的关系和影响时，通常使用系统模型，用简化的模型来代替真实的系统
一个不准确的模型通常会导致对问题的不准确解决方案。
另外，大多数模型包括许多假设，应尽可能让这些假设同现实情况相符
大多数模型包括许多假设，应尽可能让这些假设同现实情况相符
软件开发模型的大致分类：
需求确定为前提的项目：瀑布模型
初始阶段提供基本需求时采用迭代或者渐进的模型：如增量，螺旋，RUP和敏捷方法。
以形式化为基础的变换模型

1）瀑布模型

线性顺序模型，严格定义了开发周期，将开发周期分为了六个阶段：计划，需求分析，设计，编码，测试，运维。
不适合需求经常发生变化的项目，风险后期才会暴露出来，不易纠正，风险控制力弱。
优点：是可以使过程比较规范化，有利于评审；
缺点：在于过于理想，缺乏灵活性，容易产生需求偏差。

2）演化模型

针对需求不能够完整定义，在原型基础上进行优化。
它也是一种原型化开发，但与快速原型不同的是快速原型模型在获得真实需求时就将原型抛弃；
而演化模型从初始的模型中逐步演化为最终软件产品，是一种渐进式原型法。

3）螺旋模型

它是瀑布模型和快速原型模型的一个结合。特别适合大型复杂系统的开发过程。
并且加入了两者所忽略的风险分析，建立一种软件开发模型。
在螺旋模型中，软件开发是一系列的增量发布。
螺旋模型的每一次迭代都包括：制定计划，风险分析，实施工程和客户评估等四个方面的工作。
它有以下的两个特点：
是采用循环的方式逐步加深系统定义和实现的深度。
确定一系列的里程碑，确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案。

4）喷泉模型

以对象为驱动，描述面向对象的开发过程，各阶段无特定的顺序，无明显的边界。
所有的开发活动没有明显的边界，允许各种开发活动交叉进行

5）增量模型

增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
它采用的是一种递增式模型，它将软件产品划分成为一系列的增量构件，分别进行设计，编码，集成和测试

【适用场景】

在开发之初用户对系统的功能并不了解，并且系统的功能会不断变更，针对这种情况，应该采用增量的开发模型。记住这是和螺旋模型不一样的地方。
因为在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险

6）快速应用开发(RAD方法)

1. 概念定义

增量型线性顺序开发模型，强调极短周期和可复用的软件构件开发，它是瀑布模型的高度变种。
快速应用开发是一个完整的方法，生命周期包含了需求，设计，构建和验收四个阶段，和传统的软件开发生命周期各阶段相互对应。

2. 基本思想

用户积极参与系统分析，设计与构造
通过研讨会让干系人一起参与
通过迭代加速需求分析和设计
让用户看到一个可工作的系统

3. 目标

所有RAD方法的主要目标是通过用户参与系统开发的每一个阶段来缩减开发时间和费用。
由于RAD是一个连续的过程，因此随着设计的进行，RAD允许开发小组迅速地做出必要的修改。
当公司预算紧张时，对于发生在一个已制定好的长时期的进度表中的变化所带来的花费进行限制尤为重要。

4. 开发流程

业务建模，数据建模，处理建模，应用生成，测试与交付。

需求阶段

结合了软件开发生命周期的系统规划和系统分析阶段。
用户，经理和技术人员通过讨论对业务需求，项目范围，约束条件和系统达成一致意见。
当团队成员对关键问题达成一致意见，并获得管理部门继续进行授权时，需求计划阶段结束。

设计阶段

用户与系统分析员互相交流，并创建模型和原型来描述所有的系统过程，输入和输出。
RAD组或者子组通过结合使用JAD技术和CASE工具，从而将用户需求转变成工作模型。
用户设计是一个连续的，互相影响的过程，帮助用户理解，修改并最终通过满足他们需求的系统工作模型。

构建阶段

强调程序和应用开发任务，类似于软件开发生命周期。
所不同的是，在RAD中，用户一直参与其中，并且在实际界面或报表开发出来以后仍然可以提出修改建议。

验收阶段

类似于传统软件开发生命周期的实施阶段的最终任务，包括数据转换，测试，转变为新系统，以及用户培训。
和传统的方法相比，整个过程是被压缩的。这样，新系统就更快地被创建，交付和投入使用。

5. 优点

强调用户参与，可以尽早明确需求，降低系统开发风险，缩短周期。
使用大量的可以复用的构件，尽快开发提高开发速度

6. 不足之处

强调系统本身结构，整体目标和长期目标可能得不到满足
没更多时间提高项目质量，连贯性和标准化
并非所有的软件都适用这种开发方法
不适合的场景有：难以模块化的，由高性能要求的，技术风险高的项目不适合使用RAD。

7）原型法

对于许多需求不够明确的项目，比较适合采用该模型。它采用了一种动态定义需求的方法，通过快速地建立一个能够反映用户主要需求的软件原型，让用户在计算机上使用它，了解其概要，再根据反馈的结果进行修改，因此能够充分体现用户的参与和决策。

1）水平垂直原型

水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。
水平原型通常只是功能的导航，但未真实实现功能。水平原型主要用在界面上。
垂直原型也称为结构化原型，实现了一部分功能。
垂直原型主要用在复杂的算法实现上。

2）抛弃演化原型

抛弃式原型也称为探索式原型，是指达到预期目的后，原型本身被抛弃。抛弃式原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。
演化式原型为开发增量式产品提供基础，逐步将原型演化成最终系统，主要用在必须易于升级和优化的场合，适合于Web项目

3）不适合使用原型法的场景

缺乏适用的原型工具
用户不参与，不积极配合开发过程
用户的数据资源缺乏组织和管理
用户的软件资源缺乏组织和管理

4）原型法包括的步骤

确定用户基本需求
设计系统初始原型
试用和评价原型
整理原型和提供文档

5）原型法的优点

可以使系统开发的周期缩短，成本和风险降低，速度加快，获得较高的综合开发效益；
提高用户参与程度，增加用户满意度，提高系统开发的成功率；
由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的提交，有利于系统的运行和维护。

6）原型法的适用性

对于分层层面难度大、技术层面难度不大的系统，适合于原型法，而对于技术层面的困难远大于分析层面的系统，则不宜采用原型法。

8）统一过程UP

统一过程适合用于大中型项目的开发。
它可以分为四个阶段：初始阶段，细化阶段，构建阶段和移交阶段。
统一过程的三个核心：用例驱动，以架构为核心，迭代与增量
在为软件系统建模时，UP使用的是UML。

1）初始阶段

明确项目规模，建立项目的软件规模和边界条件，包括验收标准
了解环境及重要的需求和约束，识别系统的关键用例
评估项目风险，在基于RUP的迭代式软件过程中，很多决策要受风险决定，要达到这个目的，开发人员需要详细了解项目所面临的风险， 并对如何降低或处理风险有明确的策略
制定项目计划，估计整个项目的总体成本、进度和人员配备，综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源
阶段技术评审，初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目

2）细化阶段

分析问题领域，建立健全架构基础，淘汰项目中高风险的元素，该阶段必须在理解整个系统的基础上，对架构做出决策，包括其范围，主要功能，和诸如性能等非功能需求，同时为项目建立支持环境。
确定架构，建立一个已确定基线的架构，并验证其将在适当时间、以合理的成本支持系统需求; 制定构建阶段计划，为构建阶段制定详细的过程计划并为其建立基线；
建立支持环境； 选择构建；阶段技术评审。
资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析。

3）构建阶段

主要任务是通过优化资源和避免不必要的保费和返工，使开发成本降到最低，完成所有所需功能的分析，开发和测试；
确定软件场地和用户是否已经部署做好准备。
其中在构建阶段主要的文档有：设计模型。
在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
构建阶段的主要任务是通过优化、开发和测试，快速完成可用的版本

4）交付阶段

确保软件对最终用户可用。主要任务就是进行beta测试，制作产品发布版本；
对最终用户支持文档定稿，按用户的需求确认新系统；
培训用户和维护人员；
获得用户对当前版本的反馈，基于反馈来调整产品开发；
交付阶段结束时还要对成果物进行技术评审，评审目标是否实现，用户对交付产品是否满意等。
beta测试，版本发布，用户支持文档的定稿，用户需求确认，培训。

9）基于构件的开发模型

1. 基于构件开发方法

基于构件的开发模型是利用了模块化方法，将整个系统模块化，并在一定构件模型的支持下
复用构件库中的一个或多个软件构件，通过组合手段高效率，高质量地构造出应用系统的过程。

2. 基于构件特点

融合了螺旋模型的许多特征，其本质上是演化的，开发过程是迭代的。
为了提高构件的复用率，通常要求构件具有较好的通用性和可变性。

3. 基于构件优点

提高了软件开发的效率；
构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用
CBSD允许多个项目同时开发，降低了费用，提高了可维护性，可实现分布提交软件产品。

4. 基于构件缺点

由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入具有较大的风险
可重用性和软件高效性不易协调，需要精干的，有经验的分析人员和开发人员，一般的开发人员插不上手，客户的满意度低；
过分依赖构件，构件库的质量影响着产品的质量。

三. 软件开发方法

1）敏捷开发方法

是一种以人为核心，迭代，循序渐进的开发方法。在敏捷方法中，软件项目的构件被切分成多个子项目，各个子项目成果都经过测试，具备集成和可运行的特征。
在敏捷方法中，从开发者角度来看主要的关注点有：短平快的会议，小版本发布，较少的文档，合作为重，客户直接参予，自动化测试，适应性计划调整和结对编程。
从管理者的角度来看，主要的关注点有测试驱动开发、持续集成和重构。

【敏捷开发主要原则】

增量式提交
最优先要做的是尽早持续的交付有价值的软件来使客户满意
接受变更
即使到了开发的后期，也欢迎改变需求，利用变化为客户创造竞争优势。
经常性交付
经常交付可以工作的软件，时间越短越好，但不要求每次交付的都是系统的完整功能。
积极沟通
团队内部最有效的信息沟通方法就是面对面的沟通。
客户参与
让客户尽早的参与进来，不仅可以减少返工的成本，而且可以帮助我们更容易掌控需求。

【敏捷开发四大价值观】

个体交付胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
####【适用敏捷的情况】
规模较小的项目
经常发生需求变更的项目
高风险项目实施
组织文化支持谈判，彼此信任，人少精干，开发人员决定易认可，成员间快速沟通

【敏捷限制因素】

客户参与往往依赖于客户自身的意愿和客户自身的代表性
团队成员的性格可能不适合激烈的投入，可能无法做到和其他成员之间的良好的沟通
对系统中的变更做出优先级排序可能是极其困难的
维护系统的简洁性往往需要额外的工作，但迫于移交时间表的压力，可能没有时间执行系统简化过程。

【影响较大的敏捷方法论】

1. XP极限编程

强调以人为中心，而不是以流程为中心；
测试先行，测试驱动；
四大价值观是沟通，简单，反馈，勇气
12种最佳实践
计划游戏，小型发布，隐喻，简单设计，测试先行，结对编程，重构，集体代码所有制，程序集成，每周工作40小时，代码标准，客户现场工作。

2.SCRUM

迭代的增量化过程，用于产品开发或者工作管理，可以集合各种开发实践的经验化过程框架。
发布产品的重要性高过一切。
旨在寻求充分发挥面向对象和构建技术的开发方法，是对迭代式面向对象方法的改进。

3. 水晶方法

在20世纪90年代末提出，是个系列，因为创始人相信不同的项目需要不同的方法。
发展和提倡了一种机动性的软件开发方法，定义了一系列方法，包含核心元素，角色、过程模式、工作产品和实践
水晶敏捷方法实际是一组经过证明对不同类型项目都非常有效的敏捷过程，其目的是使得敏捷团队可以根据其项目和环境选择最合适的水晶系列成员。

4. FDD特征驱动开发

针对中小型项目；是一个模型驱动的快速迭代开发过程；
FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

5. ASD

ASD (自适应软件开发）由Jim Highsmith在1999年正式提出。
ASD强调开发方法的适应性，这一思想来源于复杂系统的混纯理论。
ASD不像其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

6. DSDM动态系统开发

以业务为核心，快速有效地进行系统开发。
在英国称为应用最为广泛的快速应用开发方法。
DSDM不仅遵守敏捷开发的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

7. RUP

它是一个过程框架，它可以包容许多不同类型的过程，Craig Larman极力主张以敏捷的方式来使用RUP。

2）结构化开发方法

1. 结构化概念

是一种传统的信息系统开发方法，由结构化分析、结构化设计和结构化程序设计三部分有机组合而成
它的精髓是自顶向下、逐步求精和模块化设计。

2. 划分阶段

结构化方法的基本思想是将系统的生命周期划分为五个阶段：系统规划，系统分析，系统设计，系统实施和系统维护。

3. 主要特点

开发目标清晰化
开发工作阶段化
开发文档规范化
设计方法结构化
结构化开发方法强调系统业务过程的数据流和控制流。

4. 适用性

是目前最成熟，应用较为广泛的一种工程化方法，它特别适合与数据处理领域的问题
但是它不适合与规模较大，比较复杂的系统开发。

5. 缺点局限性

开发周期长
难以适应需求变化
很少考虑数据结构

6. 其他

这种方法遵循系统工程原理，按照事先设计好的程序和步骤，使用一定的开发工具完成规定的文档，在构件化和模块化的基础上进行信息系统的开发工作。
结构化方法的开发过程一般是先把系统功能视为一个很大的模块。再根据系统分析与设计的要求，对其进行进一步的模块分解和组合。
系统逻辑设计阶段产生的图表或文档是最后一次验证系统功能需求。
系统方案建议书是系统分析阶段结束后得到的工作产品
操作手册是系统测试阶段完成后的工作产品。

3）面向对象方法

一些大型信息系统的开发，通常是将结构化方法和OO方法结合起来，使用结构化方法进行自顶向下的整体划分，然后自底向上的采用OO方法进行开发。
因此结构化方法和OO方法任然是两种在系统开发领域中互相依存的，不可替代的方法。
面向对象设计是模型驱动和用例驱动的，整个设计过程将需求模型作为输入，并生成设计模型作为输出。
面向对象使系统的描述及信息模型的标识与客观事实相互对应。符合人们的思维习惯，有利于系统开发过程中用户与开发人员的交流与沟通，缩短开发周期，提供系统开发的正确性和效率。
在面向对象方法中，信息流是通过向参与者或内部对象发送消息形成的。
顺序图用于描述进出系统的信息流。顺序图用来描述对象按照时间顺序的消息流来建模用例；
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程

【基本概念】

面向对象方法是当前的主流开发方法。
面向对象方法认为客观世界是由各种对象组成的。
任何事物都是对象，每一个对象都有自己的运动规律和内部状态，都属于某个类，是该类的一个元素。
复杂的对象可由相对简单的各种对象以某种方法而构成，不同对象的组合以及相互作用就构成系统

【三个阶段】

面向对象方法包括面向对象分析OOA，面向对象设计OOD，面向对象程序设计OOP三个阶段。
1）OOA面向对象分析
它的任务是了解问题域所涉及的对象，对象间的关系和操作，然后构造问题的对象模型。
2）OOD面向对象设计
它在分析对象模型的基础上，设计各个对象，对象之间的关系和通信方式，其主要作用是对OOA的结果作进一步的规范化整理。
3）OOP面向对象编程
它的实现在OOD阶段所规定的各个对象所应完成的任务，它包括每个对象的内部功能实现，确定对象哪一些处理能力应在哪些类中进行描述，确定并实现系统的界面，输出的形式等。

1）OMT方法

OMT方法使用了建模的思想，讨论如何建立一个实际的应用模型，包括对象模型、动态模型和功能模型。
对象模型描述系统中对象的静态结构、对象之间的关系、属性和操作，主要用对象 图来实现
动态模型描述与时间和操作顺序有关的系统特征，例如，激发事件、事件序列、确定 事件先后关系的状态等，主要用状态图来实现动态模型;
功能模型描述一个计算如何从输入值得到输出值，它不考虑计算的次序，主要用DFD来实现功能模型。简单地说，功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。

2）OOSE方法

建立在OMT的基础上，对功能模型进行了补充，提出了用例的概念，取代数据流图来进行需求分析和建立功能模型。
OOSE建立的五类模型：需求模型，分析模型，设计模型，实现模型，测试模型。

3）Booth方法

Booth认为软件开发是一个螺旋上升的过程。每个周期包括四个步骤：分别是标识类和对象，确定类和对象的含义，标识关系，说明每个类的接口和实现。
它的基本模型包括类图和对象图。它不仅建立了开发方法，还提出了设计人员的技术要求以及不同开发阶段的人力资源配置。

4）Coad/Yourdon方法

主要由面向对象的分析，和面向对象的设计构成。
OOA的任务主要是建立问题域的分析模型。
OOD由四部分组成：人机交互部件，问题域部件，任务管理部件和数据管理部件。

5）UML方法

UML是一种定义良好，易于表达，功能强大普遍使用的建模语言。
它融入了软件工程领域的新思想，新方法和新技术，它的作用域不限于支持OOA和OOD，还支持从需求分析开始的软件开发全过程。
从总体上看，UML有三种：基本的构造快，规则，公共机制组成。
UML有三种基本的构造块：事物（thing）、关系（relationship）和图（diagram）。
公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明），修饰，公共分类（通用划分）和扩展机制四种。

【结构化和面向对象方法的对比】

结构化开发方法关注的是系统的功能，强调业务过程的数据流和控制流
采用模块化，自顶向下逐步求精的方法，各阶段相对独立，结构清晰，有利于提高软件质量，
适用于规模较大，结构化程度较高的系统开发。
面向对象开发方法关注的是数据，它是以对象为中心，对象能够将数据及其行为统一
对象之间通过消息交换的机制来转发对象的行为。
对象模型提高了数据和功能复用，简化了开发流程，可维护性也得到了改善。

4）模型驱动架构（MDA)

1. 概念定义

模型驱动架构（MDA)是对象管理组织（OMG)提出的一种新的软件开发方法，
它强调由软件系统的建模行为驱动整个系统的开发过程，来完成系统的需求分析、架构设计、构建、测试、部署和运行维护等工作。
它的英文全称是Model Driven Archtecture。

02. 与UML模型区别

与传统的UML模型相比，MDA能够创建出机器可读和高度抽象的模型，这种模型通过转换（Transformation)技术可自动转换为代码、测试脚本、数据库定义以及各种平台的部署描述。
通过使用MDA技术，可以有效解决传统软件开发过程中的生产效率问题、系统移植问题、互操作问题以及文档和系统后期维护问题。

3. 开发过程中的主要活动

需求分析人员根据领域需求得到描述软件系统外部特征的计算无关模型（CIM）；
在对CIM进行分析的基础上，得到平台无关模型（PIM）并根据业务逻辑进一步精化PIM；
进行PIM到平台特定模型（PSM)的模型转换；
将每个PSM转换为实现特定模型（ISM)，生成应用程序代码，并进行测试。

4. 与传统的软件开发过程的5个主要区别

自动实现模型变换。
模型是开发产品，也是程序生成的基础设施
模型变换过程与代码生成过程同步，可维护性强
业务逻辑模型与实现技术平台分离
提高了开发效率与软件质量

5. MDA的三个特点

1.可移植性
在MDA中，先会建立平台无关模型（PIM），然后转换成平台相关模型（PSM），1个PIM可以转换成多个PSM，所以要把软件移植到另一个平台时，只需要将平台无关模型转换成另一个平台的相关模型即可。所以移植性比较强。
2.平台互操作性
在MDA中，整个开发过程都是模型驱动的，所以标准化程度很高，这样为平台的互操作带来了非常大的帮助。
3.文档代码的一致性
在MDA中，代码是由模型生成的，所以具有天然一致性。这一点其他方法无法比拟。

5）面向服务开发方法

1. 概念

面向服务的开发方法是将接口的定义和实现进行了解耦，并将跨构件的功能调用暴露出来，
该方法有三个主要的抽象级别：
最底层的操作代表单个逻辑单元的事物，包含特定的结构化接口，并且返回结构化的响应；
第二层的服务代表操作的逻辑分组；
最高层的业务流程则是为了实现特定的业务目标而执行的一组长期运行的动作或者活动。

2. 服务建模三个阶段

按照实施的阶段，服务建模可以分为服务发现，服务规约和服务实现三个阶段。

3. 面向服务优点

加强了系统的灵活性，可复用性和可演化性。

4. 面向服务的特点

服务基础架构基于粗粒度，松散耦合和基于标准的服务这三个特点
使得信息系统的建设能够保持主动，这种方法使信息系统能够通过自身的业务和转换来应对市场挑战。

6）净室软件开发

净室软件工程是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并将正确性验证作为发现和排除错误的主要机制，采用统计测试来获取验证软件可靠性所需要的信息。

四. 软件过程管理CMMI

1. CMM1初始级

无秩序，混乱，软件过程的成功依赖于极个别人的努力和机遇。

2. CMM2可重复级

焦点集中在软件管理过程上。从管理角度可看到一个按计划执行的且阶段可控的软件开发过程。
建立了基本的项目管理过程。对类似的项目有章可循，并能重复以往取得的成功。
包括需求管理，软件项目计划，软件项目跟踪与监控，软件子合同管理，软件质量保证，软件配置管理。

3. CMM3已定义级

用于管理的和工程的软件过程均以文档化，规范化，并形成整个软件组织的标准软件过程。
无论是管理还是工程软件开发，都有一套文档化的标准。
包括管理方面的：集成综合软件管理，组间协调；
组织方面的组织过程焦点，组织过程定义和培训程序；
工程方面的软件产品工程，同级评审。

4. CMM4可管理级

软件过程和产品质量有详细的度量指标，包括定量方面的定量管理过程和工程方面的软件质量管理。

5. CMM5优化级

能够不断持续的进行过程改进。
包括组织方面的技术改进管理，过程改进管理。
CMM级别 关键过程域
初始级 无
可重复级 需求管理，软件项目计划，软件项目跟踪和监视，软件质量保证，软件配置管理
可定义级 组织过程的目标，组织过程的定义，培训计划，综合软件管理，软件产品工程，开发小组之间的合作，同行评审
管理级 定量的过程管理，软件质量管理
优化级 技术变更管理，过程变更管理，缺陷预防

五. 软件配置项目分类

系统方案建议书是系统分析阶段结束后得到的工作产品，操作手册是系统测试阶段完成后的工作产品。
类别 定义 例子
环境类 指软件开发环境或软件维护环境 编译器、操作系统、编辑器、数据库管理系统、开发工具、项目管理工具、文档编制工具等
定义类 是需求分析与定义阶段结束后得到的工作产品 需求规格说明、项目开发计划、设计标准或设计准则、验收测试计划等
设计类 设计阶段结束后得到的工作产品 系统设计规格说明、程序规格说明、数据库设计、编码标准、用户界面标准、测试标准、系统测试计划、用户手册等
测试类 系统测试完成后的工作产品 例系统测试数据、系统测试结果、操作手册、安装手册等
维护类 进入维护阶段以后产生的工作产品 -

六. 软件过程改进

1. 软件过程

软件过程是人们用来开发和维护软件以及相关产品的一组活动、方法和实践
是软件企业中最复杂、最重要的业务流程。

2. 软件过程改进

帮助软件企业规划、实施软件过程的改进，为企业的业务服务，必须受企业发展战略的指导。
软件过程改进通过在软件开发实践中发现软件过程中的问题，并在实践中找到解决问题的方法，不断推动软件过程的持续改进，提高产品或服务的质量，提高软件开发的效率。
软件企业想要高效率、高质量和低成本地开发软件，必须以软件过程改进为中心，全面开展软件工程和质量管理。
英文缩写：（Software Process Improvement，SPI）

3. 软件过程改进的主要步骤

1）找出目标差距

需要对当前的状态进行分析，并明确要达到的状态（目标状态），然后分析其中的差距。

2）选定改进范围

确定改进的范围，对范围的定义不够明确，做不到可量化、可验证程度。
项目范围的明确定义，有经验的项目经理及系统分析员将起到至关重要的作用。
1）确定计划的责任权
2）陈述主要目标和问题
3）将问题分组关联到相应的目标
4）确定目标和问题足够明确和引人注目
5）设定目标优先权
6）导出针对目标的度量标准

3）制定改进计划

计划制定的是否合理、工作量、难度是否适中，都直接会影响我们过程改进的成败。
可以从比较关键的如下几个方面进行改进计划的制定：
1）成立过程改进小组，派专人负责整个过程改进
2）根据背景及业务分析，项目分析，内部因素，产品特点进行现有软件过程评估
3）根据评估给出详细的软件过程改进建议
4）根据软件过程改进建议转化为行动，整个行动由改进小组SPEG负责监控与跟踪。
5）实施软件过程改进，并同时密切监控改进过程。有问题立刻解决
6）对实施的过程改进进行评估
7）对成功实施的软件过程进行制度化

4）实施改进计划

包括建立和部署解决方案，坚定想法并且克服阻力。
实施改进的过程中可以考虑从如下几个方面进行：
1）优先处理期望的和必需的工作
2）持续强调目标和问题
3）协调管理人员和实践者的行为

5）检查改进进展

需要做的就是检查改进计划的进展，跟踪进展使你能够了解到改进活动的进行状况，提供对改进活动的可见度从而及早检测出问题，并且给出数据使得未来计划更有效。
在过程改进活动执行进程中为机构提供反馈。
基于业务目标制定的度量标准是有助于获得考察进展和指导改进活动的基本信息。
从以下几个方面可以对进度进展进行检查：
① 是否针对目标取得进展；
② 是否针对改进计划取得进展；
③ 是否针对改进框架取得进展；
④ 迄今得到那些经验教训。

6）总结本轮改进的经验

当一轮改进完成之后，再进行下一轮的改进，是一个持续改进的过程