首页  思维导图  详情

软考-系统分析师-软件工程模块

2024-12-20 14:24:45   0  举报





AI智能生成

软考-系统分析师-软件工程模块

软考

系统分析师

软件工程

作者其他创作

大纲/内容

软件重用

概述

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等。

分类

软件重用可区别为横向重用和纵向复用。

横向重用

指重用不同应用领域中的软件元素，例如数据结构、构件、分类算法和人际界面构件等

纵向重用

指在一类具有较多公共性的应用领域之间进行软件重用。例如支付领域等。

逆向工程

概述

逆向工程（Reverse Engineering）与逆向工程相关的概念有重构、设计恢复、在工程和正向工程。

重构（restructureing）

重构是指在同一抽象级别上转换系统描述形式。例如：原来是JAVA实现，现在改为C++实现

设计恢复（Design recovery）

设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。

再工程（re-engineering）

再工程是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。

再工程队现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

他不仅仅能从已存的程序中获取设计信息，而且还能使用这些信息来重构现有系统，以改进他的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。

例如：破解版本的软件

正向工程（Forward Engineering)

正向工程不仅仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。

从逆向工程基础上了解了系统的设计思想，然后自己山寨一个相同的产品处理。

逆向工程的4个抽象层次

概述

逆向工程的完备性（某一个层次提供信息的详细程度，抽象层次越高完备性越低）可以用在摸一个抽象层次上提供信息的详细程度来描述。抽象层次越高完备性越低，通过逆向工程回复的难度越大。

实现级别：抽象的语法树、符号表、过程的设计表示。完备性最高，容器

结构级别：反应程序分量之间的相互依赖的信息，如调用图，结构图，程序和数据结构。

功能级别：反应程序段功能及程序段之间的关系的信息，如数据和控制流模型。

领域级别：反应程序分量或程序实体与应用领域之间对应关系的信息，如ER模型。最难的抽象级别。完备性最低

软件过程管理

CMM模型

初始级

未加定义的随意过程，软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所得的成功往往依赖个人的努力和机遇。

可重复级

规则化和纪律化的过程，软件过程已建立了基本的项目管理过程，可用对成本，进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成就。

已定义级

是标准的和一致的过程，用于管理的和工程的软件过程均已文档化、标准化、并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程进行操作。

已管理级

已管理级是可预测的过程。软件过程和产品质量有详细的度量标准。软件过程和软件产品质量得到了定量认识和控制。（给标准定义指标）

优化级

是持续改进的过程，通过对来自过程、新概念和新技术等方面的各种有用的信息定量分析，能够不断地、持续的对过程进行改进。

CMMI（能力成熟度模型集成）

融合和多种模型，形成了组织范围内过程改进的单一继承模型，主要是消除不同模型之间的不一致和重复，降低机遇模型进行改进的成本。

阶段式分组

可重复级

已定义级

已管理级

优化级

连续式分组

过程管理

项目管理

工程

支持

软件工程的工程管理能力和水平

临时凑合阶段

简单模仿阶段

完成定义阶段

管理阶段

最佳化阶段

软件生命周期

可行性研究

需求分析

概要设计

详细设计

实现

组装测试

确认测试

使用

维护

退役

软件开发方法

概述

软件开发过程遵循的方法和步骤，从不同角度可以将软件开发分为不同的开发分类

分类

开发风范分类

自顶向下

将大问题分化成多个小问题，然后逐一解决。每个问题对应一个模块来进行解决，且每个模块包括抽象步骤和具体步骤

自底向上

根据系统的功能要求，从具体部件、器件、构建出发或者相似其他出发，凭借设计人员的熟练的技巧和丰富的经验，通过对其进行相互连接，修改、扩大最终构成所要求的系统。

面向对象方法就是自底向上的代表。

性质分类

形式化

基于严格的逻辑，数学的形式机制的计算机研究方法。用的是数学推理的方法进行计算机系统研发工作

例如：词法分析和文法分析（编译软件中的有限自动机）

净室软件工程（CSE）

非形式化

结构化

结构化思维

阶段

结构化分析

结构化设计

结构化程序设计

优点（特点）

开发目标清晰化

每个阶段工作目标明确并输出相应的文档，阶段结束进行评审通过后才进入下一阶段，保持与用户沟通，让用户了解工作进展，校准工作方向

开发工作阶段化

每个阶段完成后，要进行评审，便于项目管理与控制

开发阶段文档化

每个阶段完成后，按照要求完成相应文档，保证系统维护工作的便利

设计方法结构化

自顶向下分解，进行分析与设计。根据设计要求编写各个功能模块，自底向上实现。

缺点

开发周期长

难以适应变化

由于用户只有在交付阶段才能看到最终产品，因此是否能够满足用户要求或者用户提出变更对系统影响非常大，可能无法变更。

测试阶段发现问题，可能不是开发阶段产生的，可能是设计阶段或者需求阶段产生，此时如果修改会对整个开发进行变更，成本高。

很少考虑数据结构

面向对象

阶段

面向对象分析OOA

面向对象设计OOD

面向对象的程序设计OOP

万事万物就是对象引入对象符合人类思维，对象有哪些属性方法就是能够执行哪些程序，相似特征的对象形成了类

主要的面向对象的方法

Coad/Yourdon方法

Coad-Yourdon 面向对象方法（OOAD）严格区分了面向对象分析OOA与面向对象设计OOD。

特点

概念清晰，简单易学

OOA（分析阶段）

5个步骤

标识类和对象

类和对象的定义应从应用领域开始，逐步形成整个应用的基础类和对象，然后据此分析系统的功能

标识结构

如标识基类，派生类、类的组合聚合等概念，刻画整体及其组成部分。

标识主题

相关的类和对象放到一起形成主题。

定义属性

对象所保存的信息（数据）称为对象的属性。类的属性所描述的状态信息，在类的某个实例中，属性的值标识该对象的状态值。

定义服务

对象收到信息执行的操作称为对象提供的服务，他描述了系统所需执行的处理和功能。

通过5个层次活动可以形成一个五个层次的问题领域模型

类和对象层

结构层

主题层

属性层

服务层

OOD（设计阶段）

在设计阶段扩展OOA模型，同时OOD模型同样包括OOA模型的五个层次，但又引进了四个部分

四个部分

设计问题域部分

设计问题域部分实际上是OOA工作的延续，是在OOA的基础上进行。实际上OOD的问题域设计部分与OOA并没有严格的界限划分。

设计人机交互部分

对用户分类、描述人机交互的脚本、设计命令层次结构、设计详细的交互、生成用户界面的原型、定义类等

设计任务管理部分

识别任务（进程）、任务所提供的服务、任务的优先级、进程的驱动模式，以及任务与其他进程和外界如何通讯等

设计数据管理部分

确定数据存储模式，如使用文件系统、关系型数据库系统还是面向对象数据库管理系统等。

Booch方法

Booch认为系统的开发一种螺旋上升的过程，每个周期包括4个步骤，分别是识别类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。主要特点是使用了建模思想。

开发模型包括静态模型和动态模型

动态模型

用来描述对象的状态变化和交互过程

包括

状态图

顺序图

静态模型

用来描述系统的构成和结构

包括

逻辑模型

类图

对象图

物理模型

模块图

进程图

OMT（Object Modeling Technique）方法

使用了建模思想，讨论如何建立一个实际的应用模型，包括对象模型、动态模型和功能模型，这三个模型分别不同的层面反映系统的内容，综合起来则全面反映目标系统的需求

三大模型

概述

功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的实体

对象模型

描述系统中对象的静态结构、对象之间的关系、属性和操作

主要使用对象图来实现

动态模型

描述与事件和操作顺序有关的系统特征

例如：激发事件、事件序列、确定事件先后关系的状态等

主要用状态图来实现动态模型

功能模型

描述一个计算如何从输入得到输出值，不考虑计算的次序

使用DFD来实现功能模型。

对象图

分支主题

数据流图

顶层数据流图

OMT方法通常包括4个活动：系统分析、系统设计、对象设计和实现

分析是OOA的任务

系统设计确定整个系统的架构

对象设计建立基于分析模型的设计模型并考虑实现细节

实现是将所设计的对象类及其关系转化为程序设计语言、数据库或硬件的实现

OOSE（Object Oriented Software Enginerring）方法

在OMT的基础上，对功能模型进行补充，提出了用例图的概念（USE CASE）,最终取代了DFD进行功能分析和功能建模

OOSE方法中采用五类模型确定目标系统：需求模型，分析模型，设计模型，实现模型，测试模型

用例是OOSE方法的重要概念，在开发各种模型时，他贯穿OOSE活动的核心，描述了系统的需求及功能。

用例图

用例实际上是描述系统参与者（既可以是用户，也可以是与系统交互的其他系统）对于系统的使用情况，是从参与者的角度来确定系统的功能。因此，首先必须分析，确定系统的参与者，然后进一步考虑参与者的主要任务和使用方式，在识别出所使用的事件，即用例；

用例图模型：

OOSE的开活动主要分为三类：分析、构造和测试。

分析：分析过程分为需求分析和健壮性分析两个过程，分析活动分别产生需求模型和分析模型；

构造：构造活动包括设计和实现两个子过程；

测试：测试过程包括单元测试，集成测试和系统测试三个阶段，共同产生测试模型。

总结

OO方法使系统的描述以及信息模型的表示与客体相对应，符合人员的思维习惯，有利于系统开发过程中用户与开发人员的交流和沟通，缩短开发周期，提供系统开发的正确性和效率。

OO方法可以普适于各类信息系统的开发，但是OO方法也有明显的不足，例如：必须依赖一定的OO技术支持，在大型项目中具有一定局限性，不能涉足系统分析以前的开发环节。

当前，一些大型信息系统的开发，通常是把结构化的方法和OO方法相结合。首先，使用结构化方法进行自顶向下进行整体划分；然后，自底向上的采用OO方法进行开发。因此结构方法和OO方法仍然是两种在系统开发领域中相互依存、不可替代的方法。

构件化开发

基于构件/组件化开发的软件是解决复杂环境下软件规模与复杂性的一种手段。只要是系统的部分都可以当成构件，是基于面向对象的思想所产生的的。

构件与构件之间通过定义好的接口进行通讯。

构件的获取方法：

从现有构件中获取复合要求的构件，直接使用或做适应性修改，得到可重复利用的构件。

通过遗留工程（Legacy Engineering），将具有潜在复用价值的构件提取出来，得到可复用的构件。

从市场上购买现成的商业构件

开发符合要求的新的构件

从开源市场寻找免费的开源构件

构件分类

关键字分类法：关键字分类法将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图，每个概念用一个描述性的关键字表示

刻面分类法：刻面分类法定义若干用于刻画构建特征的“刻面”，每个面包含若干的概念，这些概念描述构件在刻面上的特征。刻面可以描述构件执行的功能，被操作的数据，构件应用的语言或者其他特征。

超文本分类法：所有构件必须辅以详尽的功能或者行为说明文档；说明中出现的重要概念或者构建以网状链接方式相互连接；检索者在阅读文档过程中可按照人类的联想思维方式任意跳转到包含相关概念或构件的文档；全文检索系统将用户给出的关键字与说明文档中的文字进行匹配，实现构件的浏览式检索。

构件复用（使用）方法

1、检索与提取构件；此阶段是要知道有哪些构件。

2、理解与评价构件；理解构建能完成什么功能等。

3、修改构件；如果构建无法达到要求则进行修改或者配置。

4、构件组装；利用构件进行应用组装，此阶段是真正的使用构建。

面向服务的方法

概述

思想是来源于构件化开发，将接口进一步封装形成服务，并将服务挂接到服务总线上（服务总线可以实现服务动态部署，调用，发现等等）

分支主题

三个主要的抽象级别

操作级别

位于最底层的操作代表单个逻辑单元的事物，执行操作通常会导致读、写或修改一个或多个持久性数据。服务的操作类似于对对象的方法，他们都有特定的结构化接口，并且返回结构化的响应。

就是简单的读写操作，无具体的业务逻辑。

服务级别

位于第二层的服务代表操作的逻辑分组。

业务流程

最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动，包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行称为服务或流程的编排，典型的情况是调用已编排的服务来响应业务事件。

面相服务的分析与设计

面向服务的分析与设计（SOAD，Service-Oriented Analysis and Design），综合了OOA、OOD、企业架构（Enterprise Architecture，EA）和业务流程建模（BPM)中的适当原理，将这些规则中的原理与许多独特的新原理组合起来。基础设计层，采用OOA和OOD的思想，其主要目标是能够进行快速而有效的设计、开发，以及执行灵活且可扩展的底层服务构件。

三个层次

业务组织

业务流程建模理论（BPM理论）

采用业务流程管理，既BPM理论，现在广泛使用的是uml图建模，其中最常用的是UML的活动图。SOAD以现有的BPM方法为起点，以服务流程编排模型为补充。此外，SOAD中的流程建模必须与用例设计保持同步。

应用架构

采用企业架构理论

采用EA的理论框架。企业信息系统建设是一个庞大的工程，其中可能会涉及到众多的业务流水线和组织单元（部门）。因此，需要应用EA，以努力实现各方案之间架构的一致性。在SOAD中，应用结构层以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和服务既协定。

基础设计

用面向对象的分析与设计的理论。

采用OOA和OOD的思想，主要目标是能够进行快速而有效的设计，开发，以及执行灵活且可扩展的底层服务构件。

原型开发

概述

结构化方法和面向对象方法有一个共同点，既在系统开发初期必须明确系统的功能要求，确定系统边界。从工程学角度来看，这是十分自然的：解决问题之前必须要明确解决的问题是什么。但是对于信息系统而言，明确问题本身就非常困难。

原型化方法也称为快速原型法，或者简称为原型法。

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

原型方法的分类

按照功能划分

水平原型

行为原型，用户解决，系统需求但并未实现功能。

垂直原型

结构化原型，用于复杂算法的实现，实现了部分功能。

按照最终结果划分

抛弃式

探索式原型，解决需求不确定性、二义性、不完整性、含糊不清等

演化式

逐步演化为最终系统，用于易于升级和优化的场合，适用于WEB项目。

原型法的开发过程

步骤

1、确定用户基本需求

2、设计系统初始原型

3、适用和评价原型

4、评审判断是否达到要求

5、达到要求则整理原理，提供闻文档；否则修改和完善原型并重新评价（转移到3）

分支主题

原型法特点

从原型法的开发过程可以看出，原型法从原理到流程都十分简单，并无高深的理论和技术，所以应用广泛。

特点

优点

可以使系统开发的周期缩短、成本和风险降低、快速开发，获得较高的综合开发效益。

是以用户为中心来开发的系统，用户参与度高，开发的系统符合用户需求，因此增加了用户满意度，提高了系统开发成功率。

由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的移交，有利于系统的运行与维护。

缺点

开发的环境要求较高，例如对于开发人员的和用户的素质，系统开发工具、软硬件设备等，特别是原型法需要的快速开发工具的支持，开发工具的水平是原型法能否顺利实施的第一要素。原型法成败的关键以及效率的高低在于构件原型的速度。

管理水平要求高，系统的开发缺乏统一的规划和开发标准，难以对系统的开发过程进行控制。例如，如何确定用户的满意度，如何控制对系统原型的修改次数（原型迭代次数）等，都是比较难以协调的问题。

敏捷开发

概述

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各子项目都经过测试，具备集成课运行的特征。

从开发者角度来看，主要有短平快的会议、小版本的发布、较少的文档、合作为主、客户直接参与、自动化测试、适应性计划调整和结对编程；

从管理者角度来看，主要的关注点有测试驱动开发（先编写测试代码，然后在开发具体的功能）、持续集成和重构。

适用场景

项目团队的人数不多，适合于规模较小的项目。

项目经常发生变更。敏捷方法适用于需求萌动并且快速变化的情况，如果系统有比较高的关键性、可靠性、安全性等方面的要求则可能不适合敏捷开发。

高风险项目的实施

从组织结构的角度来看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但精干、开发人员所做的决定必须得到认可、环境设施满足团队成员之间快速沟通的需求。

敏捷宣言

个体和交互胜过过程和工具

可工作的软件胜过大量的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

敏捷方法强调让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。

敏捷开发类型

XP极限编程：高效、低风险、测试先行（先写测试代码，在开发具体功能）

水晶方法Cockburn：不同项目具有不同的策略

SCRUM并列争求法：迭代，30天为一个迭代周期，按照需求优先级实现。

FDD功用驱动方法：开发人员分类。分为指挥官（首席程序员），类程序员（具体干活的人员）。

开放式源码：虚拟团队，并发成员分布各地。

ASD自适应方法：预测--协作--学习

SCRUM并列争求法

将需求设置为一个一个的用户故事，并对用户故事进行排序，然后设置一个冲刺周期（通常是4周为一个周期），冲刺周期结束之后进行评审，以确定是否发布或进行下一轮冲刺。在整个的开发过程中，需要开每日站会和使用使用一些工具（例如，燃尽图来了解当前任务的执行情况）

适用范围

局部

整体

开发模型

概述

软件开发模型给出软件开发活动各阶段之间的关系，是软件开发过程的概括，是软件工程的和总要内容。软件开发模型为软件工程管理提供了里程碑和进度表，为软件开发过程提供了原则和方法。

瀑布模型

是一种严格定义方法，将软件开发过程分为计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，形如瀑布流水，最终得到软件产品。

瀑布模型是一种线性顺序模型，支持直线开发。它假设当线性顺序完成之后就能交付一个完善的系统，并没有考虑软件的演化特征。尤其是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做的事情，有利于项目管理。然而，在瀑布模型中，依赖早期的需求调查，不能适应需求的变化；由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；风险往往推迟至后期的开发阶段才显露出来，从而失去了及早纠正的机会。在瀑布模型中需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目的风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

阶段

计划->需求分析->设计->编码->测试->运维

瀑布模型是结构化开发方法所使用的一种模型。结构化开发方法的优缺点和瀑布模型的优缺点一样。

优缺点

优点

方便管理

具有严格的阶段划分，每个阶段目标清晰。

缺点

无法适应变化

风险控制能力较弱

在设计或者需求阶段产生的问题可能只有到了测试阶段段才能发现，此时纠正的成本较高。

原型模型

概述

原型模型是快速构建一个系统，让用户尽早了解最终系统所具有的特性。

对应的是原型开发方法，优点和缺点与原型模型一样

模型图：交流-->快速计划-->快速设计方式建模-->构建原型-->部署和反馈-->交流

构造过程

1、建造一个快速原型，实现客户或未来用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发的需求，确定客户的需求。

2、在第一步的基础上开发客户满意的软件产品。

优缺点

优点

能够减少由于软件需求不明确带来的开发风险。

缺点

所选用的开发技术和工具不一定符合主流的发展

快速建立的系统架构上连续的修改可能会导致产品质量低下。

建立多少原型才适合是难以控制的

螺旋模型

概述

螺旋模型是一种演化软件过程的模型，将原型实现的迭代特征与线性顺序模型中的控制的和系统化的方面结合起来，使软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。

是瀑布模型与原型模型的结合

螺旋模型沿着螺旋线进行若干次迭代，每次迭代都包括：制定计划、风险分析、实施工程和客户评估4个方面的工作。

螺旋模型强调风险分析（系统分析师来完成，风险分析是否能够做好取决于个人能力），开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适合庞大、复杂并且高风险的系统开发。

与瀑布模型相比，螺旋模型支持用户的需求动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，需要开发人员具有相当丰富的风险评估经验和专门的知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。

模型图

分支主题

喷泉模型

概述

是一种以用户需求为动力，以对象为驱动的模型，主要用于面向对象的软件开发过程。

是一种自底向上的实现过程。是从实现的角度来看系统开发，所有的功能最终都是落到具体的某个类上，因此设计类所具有的方法就可以完成系统所具有的功能。

该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的，就像水喷上去又落下来，类似一个喷泉。

各个开发阶段没有特定的次序要求，并且可以相互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

分支主题

特点

各个活动之间没有明显的边界。例如分析和设计之间没有明显的边界。这种特性称为无间隙性。面向对象的分析，分析的是系统的具有哪些对象，设计的时候针对的也是分析是的类。

是一个迭代过程

由于对象概念的引入，只用类和关系来表达分析、设计和实现等活动，从而可以比较容易的实现活动的迭代和无间隙，提高软件开发项目效率，节省开发时间。

V模型

概述

V模型并不属于某种具体的开发方法，是一种测试方面的模型。和瀑布模型有着一些共同的特性。是对瀑布模型的一种弥补。

V模型中的过程从左到右，描述了基本的开发过程和测试行为，其价值在于他非常明确的标明了测试过程中存在的不同级别，并清楚的描述了这些测试阶段和开发过程个阶段的对应关系。

分支主题

对应关系

需求分析-->验收测试

概要设计-->系统测试

详细设计-->集成测试

编码-->单元测试

W模型

概述

W模型特点：【活动串行】测试与开发同时进行，在V模型的基础上，增加了在开发阶段的同步测试。W模型中，软件开发和测试是紧密结合的，每个开发活动完成后就同步进行测试活动——需求分析完成后进行需求测试；设计完成后进行设计测试；编码完成后进行单元测试；集成完成后进行集成测试；系统构建完成后进行系统测试；完成交付准备工作之后进行验收测试。

分支主题

基于知识的模型

基于知识的模型是把瀑布模型和专家系统结合在-起。在开发的各个阶段都利用了相应的专家系统来帮助软件人员完成开发工作，使维护在系统需求说明一级上进行。

简历各阶段所需的知识库，将模型、相应领域知识和软件工程知识分别存人数据库，以软件工程知识为基础的生成规则构成的专家系统与含有应用领域知识规则的其他专家系统相结合,构成了该应用领域的开发系统。

特点

支持需求活动的专家系统

支持设计活动的专家系统

支持测试活动的专家系统

支持维护活动的专家系统

增量模型

概述

增量模型融合了瀑布模型的基本特点和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发（每一个增量相当于一个原型，但是原型不一定实现具体功能，增量模型一定是可发布的真实的功能）。

该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的增量，当使用增量模型时，第一个增量往往是核心的产品。

客户对每个怎了的使用和评价都作为下一个增量发布的新特性和功能，这个过程在每一个增量发布不断重复，直到产生了最终的完善的产品。增量模型强调每一个增量均发布一个可操作的产品。

分支主题

RAD快速应用开发

概述

快速应用开发（Rapid Application develop，RAD）是一种比传统生命周期法快得多的开发方法，他强调极短的开发周期。

RAD模型是瀑布模型的一种高速变种，通过使用基于构件的开发方法进行快速开发。阶段分为规划、设计（包括分析）、实现和运行

分支主题

基本思想

1、让用户更主动的参与到系统分析、设计和构造活动中来。

2、将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分析师、系统设计人员和开发人员一起参与。

3、通过一种迭代的构造方法，加速需求分析和设计阶段。

4、让用户提前看到一个可工作的系统。

RAD开发过程

RAD流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。

1、业务建模

确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向以及处理等，可以使用数据流图来帮助建立业务模型。

2、数据建模

为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用ER图来帮会组建立数据模型。

3、过程建模

将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即细化数据流图中的加工。

4、应用生成

利用第四代语言，写出处理程序，复用已有构件或者创建新的可复用的构件，利用环境提供的工具自动生成并构造出整个应用系统。

5、测试与交付

RAD强调复用，许多构件已经是测试过的，这就减少了测试的时间，由于大量复用，所以一般只做整体测试，但新创建的构件还需要测试。

RAD局限性

RAD通过大量使用可复用的构件，加快了开发速度过程，但也有局限性

1、并非所有应用都适合RAD。

RAD对模块要求比较高，如果有哪一项功能不能被模块化，那么RAD所需要的构件就会有问题；

如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得（需要对构件进行修改才能满足要），则RAD可能也不能有效

2、开发者和客户必须在短时间完成一系列的需求分析，任何一方配合不当，都会导致RAD失败

3、RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。

当一个新系统采用很多新技术，或当新系统要与现有系统较高的互操作时，就不合适使用RAD

RUP统一过程模型

概述

统一过程（Unified Process，UP）是一个通用过程框架，可以用于广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。

重型模型，主要体现在大项目（周期长，例如两年以上的项目）使用；在瀑布模型的基础上增加了一些内容，主要是增加了项目管理的内容。

UP是基于构件的，在为软件系统建模时，UP使用UML。

与其他软件过程相比，UP具有三个显著特点，即：用例驱动（需求分析可以使用用例图来完成），以架构为中心（系统由哪些构件组成，针对系统的不同的组成部分都用UML展示，4+1视图来展示），迭代和增量。

用例驱动

以架构为中心

迭代和增量

RUP是Rational公司开发和维护的过程产品，RUP将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。

RUP的阶段

RUP中的软件过程在时间上被分解为4个顺序的阶段，分别是初始阶段、细化阶段、构件阶段和移交阶段。每个阶段结束时都要进行进行技术评审，以确定这个阶段的目标是否已经达成，如果评审结果满意就进入下一阶段。

1、初始阶段

初始阶段的任务是为了建立业务模型并确定项目的边界

在初始阶段必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。

在这个阶段中，所关注的是整个项目的业务和需求方面的主要风险。

对于建立在原有系统基础上的开发项目来说，初始阶段可能很短

初始阶段实现过程如下

明确项目规模：建立项目的软件规模和边界条件，包括验收标准；了解环境以及重要的需求和约束，识别系统的关键用例；

评估项目风险：了解项目所面临的风险，并对如何降低或处理风险有明确的策略；

制定项目计划：估计整个项目总体成本、进度和人员配备。综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源。

阶段技术评审：初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。

2、细化阶段

这个阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。

在细化阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能注入性能等非功能需求，同时为项目监理支持环境。

细化阶段主要工作

确定架构：通过处理架构方面重要的场景，建立一个已确定极限的架构，并验证其将在适当时间，以合理的成本支持系统需求；

制定构建阶段计划：为构建阶段制定详细的过程计划并为其建立基线；

建立支持环境：包括开发环境、开发流程、支持构件团队所需的工具和自动化/半自动化支持。

选择构件：集成所选构件，并按主要场景进行评估；

阶段技术评审：检验详细的项目目标和范围、架构的选择，以及主要的风险解决方案。

3、构建阶段

对系统进行详细设计，并进行编码，测试、集成

4、移交阶段

对系统全面测试，补充各种文档，并发产品移交给用户等。

分支主题

4+1视图

概述

4+1视图是从5种不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件系统结构。

每一个视图只关心系统的一个侧面，只有5个视图结合在一起才能反应系统结构的全部内容。

分支主题

场景视图

场景视图，用例图来表示

所有其他视图都依赖用例（场景）来指导，每一种场景都可以用一个用例来表示，这也是称之为4+1的原因、

逻辑视图

用类图（类图从用例图中导出）、对象图、状态图（系统状态转换）、协作图来表示

主要支持功能性需求，系统应该为用户提供哪些服务。系统分解为一系列的关键抽象，大多数来自于问题域，表现为对象或对象类的形式。

分支主题

过程视图

活动图来表示

进程视图是可执行线程和进程作为活动类的建模，他描述开发与同步结构

分支主题

开发视图

包图、组件图来表示

关注软件开发环境下实际模块的组织。软件打包成小的程序块（库，子系统），可以由一人或几人开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。

组件图

物理视图

部署图来表示

秒如何将前三个视图中所述的系统设计实现为一组现实世界的实体。展示如何把软件映射到硬件，他通常考虑系统性能，规模，可靠性等。解决系统拓扑结构、系统安装和通讯等问题。

分支主题

开发环境与工具

基于架构的软件工程（CBSE）

基于构件的软件工程(Component-Based Software Engineering,CBSE)是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE强调构件是购买而非重新构造。

构件的特征

可组装性

可部署性

文档化

独立性

标准化

CBSE主要过程

系统需求概览

识别候选构件

根据发现的构件修改需求

体系结构设计

构件定制与适配

组装构件，创建系统

CBSE过程与传统的软件开发过程的不同点

(1)早期需要完整的黑求_以便尽可能多地识别出可复用的构件

(2)早期阶段根据可利用的构件来细化和修改需求以匹配CBSE。

(3)架构设计完成后，可能需要修改构件以适合功能和架构的需求。

(4)开发过程就是组装构件的过程，有时需要开发适配器。

(5)CBSE中的架构设计阶段特别重要，决定和限制了可选构件的范围。

基于架构的软件设计ABSD

Architecture-Based Software Design，强调由商业、质量和功能需求的组合驱动软件架构设计。ABSD是一个自顶向下，递归细化的软件开发方法，它以软件系统功的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。该方法特别适用于开发一些不能预先决定所有需求的软件系统，也可为需求不能在短时间内明确的软件项目提供指导。

ABSD方法有三个基础

1、功能分解。

2、通过选择体系结构来实现质量和商业需求。

3、软件模板的使用。

ABSD开发阶段

1、架构需求

明确用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。主要活动包括需求获取、标识构件、架构评审。

2、架构设计

这是一个迭代过程，利用架构需求生成并调整架构决策。主要活动包括提出架构模型、将已标识的构件映射到架构中、分析构件之间的相互作用、产生系统架构的架构设计评审。

3、架构文档化

对架构设计进行分析与整理，生成架构规格说明书和测试架构需求的质量设计说明书。

4、架构复审