软考高项学习教程【第一阶段】：第1章-信息系统开发基础【考点笔记1】

文章目录

前言
一、信息系统开发基础
- 1.1 信息系统与信息化
- 1、信息系统建设：信息与信息系统的概念
- 2、信息系统的类型（了解)
- 3、信息系统的生命周期（产品生命周期）【重要】
- 4、信息系统规划方法
- 5、信息系统开发方法【考点】
- - 5.1 结构化方法（上世纪80年代提出）
  - 5.2、原型化法
  - 5.3、面向对象方法
  - 5.4 面向服务的方法（了解）
二、软件工程
- 2.1 需求工程（分析）
- 2.2 软件开发模型（项目软件生命周期模型）
- - 1、瀑布模型（SDLC）*
  - 2、V模型 *
  - 3、迭代模型
  - 4、螺旋模型
  - 5、原型化模型-构建组装模型（CBSD）
  - 6、统一过程
  - 7、敏捷开发模型
- 3、架构设计
- 4、软件设计
- - 4.1 典型架构
  - 4.2 测试原则与类型
  - 4.3 系统运行与维护
  - 4.4 软件复用
  - 4.5 软件开发环境及过程管理（了解）
三、面向对象技术
- 3.1 基本概念
- 3.2 UML
- 3.3 面向对象分析技术（OOA）
- 3.4 信息系统开发基础【重点】
- 3.5 GB/T 16260.1-2006质量模型【重要】

前言

什么是软考高项？
软考高项指的是软考高级信息系统项目管理师，信息系统项目管理师属于软考高级资格考试，通过考试获得证书的人员，用人单位可根据工作需要从获得证书的人员中择优聘任相应专业技术职务。软考包含多个级别资格考试，信息系统项目管理师属于软考高级资格考试。

编写系列笔记目的？
最近报了个软考高项培训，为11月份第一次冲击高级信息系统管理师（高级项目经理）职业证书做准备。这个证书，作为职业证书的一种，可以个税抵扣，也可以作为阅历的加成，好处还是多多的，相比于近几年PMP证书考试的难度，这项考试难度更大覆盖更广，通过率也相对较低，好在它是国家承认的职业证书（PS：PMP并不是国家认可的职业证书，因此不能享受个税减免，以考代评等服务）。报培训班的目的呢，也是在有限的时间内，画出考点重点，在那么厚一本教材中，找到重点，方便在几个月的时间内系统性的备考，似乎一次过的人也是很少的，但争取早日过，奥力给！！！

附上官方教程PDF资源一份，信息系统项目管理师教程-第三版，提取码：tzqj。需要的朋友可以免费自取。

本笔记结合教程书籍目录与培训考点总结，按照教程章节的结构来编写。

一、信息系统开发基础

教程目录：

1.1 信息系统与信息化

1.2 信息系统开发方法

1.3 常规信息系统集成技术

1.4 软件工程

1.5 新一代信息技术

1.6 信息系统安全技术

1.7 信息化发展与应用

1.8 信息系统服务管理

1.9 信息系统规划

1.1 信息系统与信息化

本节考试题型占比：考题点比重7-8个选择题
概要：

信息系统

信息与信息系统的概念

信息系统的类型

信息系统生命周期

信息系统规划方法

信息系统开发方法

1、信息系统建设：信息与信息系统的概念

信息：

定义1（控制论创始人维纳）：信息就是信息，既不是物质也不是能量，是客观事物的基本存在形式之一。不是物质也不是能量。
定义2（香农-信息论奠基人）：信息是有别于物质与能量的第三种东西，是对事物运动状态或存在方式的不确定性的描述。（用概率的方式进行描述的）

信息系统：

定义：信息系统是由计算机硬件、网络和通讯设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统

2、信息系统的类型（了解)

数据环境分类：数据文件、应用数据库、主题数据库、信息检索系统
应用层次分类：战略级（企业最高管理层）、战术级（企业中层经理及其管理部门）、操作级（服务型企业的业务部门）、事务级（企业的管理业务人员）

3、信息系统的生命周期（产品生命周期）【重要】

对应教程： 1.1.4 章节内容

信息系统的生命周期可简化为：

系统规划（可行性分析&项目开发计划）、

系统分析（需求分析）、

系统设计（概要设计、详细设计）、

系统实施（编码、测试）、

运行维护等阶段

为了便于论述针对信息系统的项目管理，信息系统的生命周期可以简化为以下四个阶段：

立项阶段（也叫系统规划，企业全局、形成概念、需求分析）
开发阶段（项目经理介入阶段）
- 总体规划：起始阶段，以立项阶段所做的需求分析为基础，明确：开发目标，总体结构，组织结构，管理流程，实施计划，技术规范
- 系统分析：提供逻辑模型（需求模型）
- 系统设计：根据分析结构提出实施方案
- 系统实施：将设计阶段的成果，在计算机和网络上具体实现，即将设计文本变成软件体系
- 系统验收
运维阶段（通过验收、移交之后）
消亡阶段（更新改造、功能扩展、报废重建）

4、信息系统规划方法

对应教程书：1.9 章节内容

信息系统规划方法：重点在于BSP-企业系统规划法。它是IBM提出的一种方法，主要用于大型信息系统的开发。BSP采取自上而下的系统规划，而实现是自下而上分步进行。
BSP是通过全面调查，分析企业信息需求，制定信息系统总体方案的一种方法
企业系统规划法（BSP）：结合现有情况，明确未来开发方法
考点：考流程图

5、信息系统开发方法【考点】

对应教程书1.2 章节内容

常用的开发方法包括：结构化方法、面向对象方法、原型化方法、面向服务的方法等

5.1 结构化方法（上世纪80年代提出）

结构:是指系统内各大个缅怀要求之间的相互联系、相互作用的框架。

结构化方法，也称为“生命周期法”，是一种传统的信息系统开发方法。（结构化方法是目前最成熟，应用最广泛的工程化方法）

方法组成：由结构化分析（SA），结构化设计（SD），结构化程序设计（SP）三部分组合而成。

**适用场景：**成熟的，稳定的，需求明确的项目。在开发过程中不能随意更改。适合于数据处理领域的问题。不适应于规模较大，比较复杂的系统开发。

特点：
1、开发目标清晰化。“用户第一”，与用户保持沟通，取得共识
2、开发工作阶段化：每个阶段的工作内容明确，注重过程控制
3、开发文档规范化：每个阶段工作完成后，要按照要求完成相应的文档，保证各阶段衔接与系统维护工作的使得
4、设计方法结构化：强调整体性和全局性，自顶向下分解，自底向下实现

PPT 中特点：
- 用户至上
- 严格区分工作阶段，每阶段有任务与成果
- 强调系统开发过程的整体性和全局性
- 系统开发过程工程化，文档资料标准化
- 自顶向下，逐步分解（求精）、模块化设计

不足与局限性：
开发周期长：因为要按顺序历经各个阶段，直到系统实施后，用户才能使用系统
难以适应需求变化：用户需求变化是不可避免的，而结构化方法要求在系统分析阶段明确需求
很少考虑数据结构：结构化方法是一种面向数据流的开发方法，比较活生生系统功能的分析与抽象，数据结构方法兼顾不多。

5.2、原型化法

**原型化方法：也叫快速原型法，原型法。**是一种根据用户初步需求，利用系统开发工具，快速的建立一个系统模型展示给用户，在此基础上与用户交流，最终实现用户需求的信息系统快速开发方法。
原型：是系统的一个早期可运行版本，它反映最终系统的部分重要特性。
分类：
- 从最终结果来分：可分为抛弃式原型（指达到预期目的后，原型本身被抛弃），演化式原型（为开发增量式产品提供基础，逐步将原型演化成最终系统，主要用在必须易于升级和优化的场合，特别适用于Web项目）。
**应用场景：**适用于需求不明确，不断迭代的开发方法。对于分析层面难度大，技术层面难度不大的系统，适合于原型法
特点：
- 1、使系统开发的周期缩短、成本和风险降低、速度加快、获得较高的综合开发效益
- 2、以用户为中心来开发系统，用户参与度高，增加了用户满意度
- 3、有得于系统的运行与维护
不足：
- 1、开发环境要求高
- 2、管理水平要求高：系统的开发缺乏统一的规划和开发标准，难以对系统的开发过程进行控制。
  开发过程：

5.3、面向对象方法

面向对象方法（Object-Oriented, OO）： 客观世界是由各种对象胶原蛋白的，任何事物都是对象。复杂的对象可由相对简单的各种对象以某种方式而构成，不同的对象组合及相互作用就构成了系统。
特点：
1、更好的复用性
2、关键在于建立一个全面、合理、统一的模式（用例模型和分析模型）
3、OO方法也划分阶段，但系统分析，设计，实现这三个阶段之间界限变得不明确
4、缩短开发周期
不足：
必须依靠一定的OO技术支持
大型项目的开发上有局限性

一些大型信息系统的开发，通常是将结构化方法和OO方法结合起来。首先，使用结构化方法进行自顶向下的整体划分，再自底向上的用OO法进行开发。

5.4 面向服务的方法（了解）

面向服务（Service-Oriented, SO)是一个较新的领域，有待进一步深入。

二、软件工程

对应教程书 1.4章节内容

软件工程：是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。
IEEE对软件工程的定义：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究，即为软件工程。
组成部分：方法、工具、过程。
主要内容点：

软件开发模型（项目生命周期模型。教程2.7章节内容）

需求工程（需求分析。教程1.4.1 章节内容）

软件设计

软件测试

软件运行与维护

软件复用

软件开发环境

2.1 需求工程（分析）

**软件需求：**是指用户对新系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力。是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。
需求开发的过程有四个主要活动：
- 1、需求获取：积极与用户交流，捕捉、分析和修正用户地目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》
- 2、需求分析：目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型
- 3、需求定义：目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。
- 4、需求验证：也叫需求确认，指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。实际工作中，通过需求评审和需求测试工作来对需求进行验证。
**需求分类：**六类
- 1、业务需求：指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、客户单位管理人员、市场营销部，产品策划部等，业务需求可确定 项目视图和范围。它描述了组织为什么要开发一个系统，即组织希望达到的目标，使用前景和范围文档来记录业务需求，这份文档有时也被称为项目轮廓图或市场需求文档。
- 2、用户需求：描述用户的具体目标
- 3、系统需求：从系统的角度来说明软件的需求。用于描述包含多个子系统的产品（即系统）的顶级需求：包括功能需求、非功能需求、设计约束
  - 3.1 功能需求：也叫行为需求，规定了开发人员必须在系统中实现的软件功能
  - 3.2 非功能需求：（性能需求）指系统必须具备的属性或品质
  - 3.3 设计约束：限制条件或补充规约，通常是一些系统约束说明，如必须采用国有自主产权的数据库系统，必须运行在UNIX操作系统之下等

需求分析涉及分析需求的过程，其目的如下：
1、检测和解决需求之间的冲突
2、发现软件的边界，以及软件与期环境如何交互
3、详细描述系统的需求，以导出软件需求

软件需求规格说明书（Software Requirement Specification, SRS）是需求开发活动的产物，编制该文档的目的是使项目干第人与开发团队对系统的初始规定有一个共同的理解，使这成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应缺少。
国家标准GB/T 8567 -2006中，规定SRS应用包括以下内容：范围，引用文件，需求，合格性规定，需求可追踪性，尚未解决的问题，注解，附录。

2.2 软件开发模型（项目软件生命周期模型）

见教程2.7章节内容，软件开发模型，又叫”项目生命周期模型“
软件开发模型：即方法的具体实例，一共9个模式

瀑布模型 *

V模型 *

原型化模型

迭代模型

螺旋模式*

构建组装模型

统一过程（RUP）

喷泉模型

敏捷方法

标星为重点掌握模型，其余了解即可

1、瀑布模型（SDLC）*

瀑布模型的几个阶段：可行性分析（计划）、需求分析、软件设计（概要设计，详细设计）、编码（含单元测试）、测试、运行维护
特点：
- 从上一项开发活动接受该项活动的工作对象作为输入。（严格按顺便执行工作）
- 利用这一输入，实施该项活动就完成的工作内容
- 给出该项活动的工作成果，作为输入传给下一项开发活动（每阶段有成果产出并传递给下一阶段）
- 对该项活动的实施工作成果进行评审。若工作成果得到确认，则继续进行下一项开发活动。否则返回前一项，甚至更前项的活动。（阶段存在返工可能）

瀑布模型：是结构化开发方法的具体应用

适应场景：只适用于需求明确，成熟稳定的项目

如上：

每个阶段都有一定的成果，如设计阶段会产生文档到编码阶段，成为一个单向瀑布流
每个阶段向上的箭头：每个阶段产生的成果可能不满足要求，因而需要返工

2、V模型 *

V模型的重要意义：它明确表明了测试过程中存在的不同的级别，并清晰的描述了这些测试阶段和开发阶段的对应关系
- 单元测试：对应详细设计，验证软件单元是否按照详细设计说明来正确执行，即保证每个最小的单元能够正常进行。一般由开发人员来执行。
- 集成测试：对应概要设计，检查多个单元是否按照系统概要设计描述的方式协同工作。
- 系统测试：对应需求分析，验证整个系统是否满足需求规格说明
- 验收测试：对应用户需求，从用户的角度检查系统是否满足合同中定义的需求或用户需求
特点：
- 1、体现了开发和测试同等重要，左侧代表开发活动，右侧代表测试活动
- 2、测试贯穿整个开发的每个阶段
- 3、测试依旧是开发生命周期中的阶段
应用场景： V模型适用于需求明确和需求变更不频繁的情形

与瀑布模型相似，但每个阶段有对应的测试
注意：测试是贯穿整个开发流程的工作
本节重点：掌握每个阶段所对应的测试类型

3、迭代模型

**迭代模型：**如上图，水平方向为时间流向维度，从组织管理的角度，描述整个软件开发生命周期，分四个阶段：初始，细化，构造，移交。纵向为核心工作流，从技术角度描述迭代模型的静态组成部分。
特点：
- 图中阴影部分描述了不同的工作流，在不同的时间段内工作量的不同，几乎所有工作流在所有时间段都有工作量，只是大小不同。

4、螺旋模型

螺旋模型：是一个演化软件过程模型，将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来。
特点：
- 在螺旋模型中，软件开发是一系列的增量发布。
- 螺线代表随着时间推进的工作进展，四个象限标志每个周期所划分的四阶段：制订计划，风险分析、实施工程、客户评估。
- 强调了风险分析
适用场景：适用于庞大而复杂的，高风险的系统
把螺纹拉开即是一条直线，且分为了多个瀑布过程。
本质：结构化方法+原型方法的思路。（瀑布模型和快速原型模型的结合）
特殊点：两条直线坐标，作用：将整个螺旋沿着螺线的迭代分为了四种活动：制定计划，风险分析，实施工程，客户评估
强调软件开发过程中的”风险分析“，
适合于：风险大，复杂的大型系统

5、原型化模型-构建组装模型（CBSD）

面向对向方法对应的模型。

模仿瀑布模型，但没有时间线介入

6、统一过程

面向对象化方法下的模型

7、敏捷开发模型

敏捷开发，是一种应对快速变化的需求的一种软件开发能力。以人为核心、迭代、秩序渐进。更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
Scrum是一种迭代式增量软件开发过程，常用于敏捷软件开发。

**适用于：**小团队，小规模项目，小步快跑模型
**4大价值观：**沟通、简单、反馈、勇气
**5大原则：**快速反馈、简单性假设、逐步修改、提倡更改、优质工作
23个最佳实践：
- 小版本、规则游戏、现场客户
- 隐喻、简单设计、重构
- 测试欢动开发、持续集成、结对编辑
- 代码共有、编程标准、每周40小时工作

3、架构设计

架构设计：即需求分配，将满足需求的职责分配到组件上。主要设计宏观体系结构。为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。
**软件架构：**是一个描述软件系统的子系统和组件，以及他们之间相互关系的学科
**架构视图：**一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。什么是软件视图

4、软件设计

软件设计包含3个过程：

1、架构设计：架构模式，宏观设计
- 逻辑视图（满足功能需求）
- 过程视图（并发问题）
- 组件视图（实现问题）
- 部署视图（分布问题）

2、概要设计

3、详细设计（设计模式、微观），以下三个原则要掌握（*）
- 自顶向下，逐步求精
- 信息隐蔽（为了模块独立）
- 模块独立（高内聚、低耦合）

4.1 典型架构

典型架构模式有以下7种：

管理/过滤器：有助于快速定位错误（管理-连接过滤器，不改变数据；过滤器-处理构建，可以改变数据）
面向对象模式：为了复用性
事件驱动模式
分层模式：把复杂问题分层解决
知识库模式：复杂版的事件驱动模式
客户机/服务器模式（C/S；B/S）：C/S模式维护验证，局域网，安全性差
面向服务的架构：SOA架构，高内聚低耦合

4.2 测试原则与类型

1、测试原则：

尽早、不断的进行测试
程序员避免测试自己设计的程序
既要选择有效、合理的数据，也要选择无效、不合理的数据
修改后应进行回归测试
尚未发现的错误数量与该程序已发现的错误数成正比

2、测试类型：
按“是否需要执行”可以将测试分为2大类：

动态测试（需要执行程序）：
- 黑盒测试法：通过输入，输出判断。特点：等价类划分，边界值划分，错误推断，因果图。（不了解内部结构）
- 白盒测试法：特点：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖。（了解内部结构的前提下进行的）
- 灰盒测试法：不常用
静态测试（不需要执行程序）：
- 桌前检查
- 代码走查
- 代码审查（审计）

系统集成项目管理工程师教程3.3内容：
从是否关心软件内部结构和具体实现的角度划分白盒测试，黑盒测试，灰盒测试。
从是否执行程序的角度划分静态测试和动态测试
从软件开发的过程按阶段划分有：单元测试，集成测试，确认测试，系统测试，验收测试

3、测试阶段

根据软件项目生命周期V模型中可以将测试分为如下阶段：

单元测试：测模块接口、局部数据结构、边界条件、独立的路径、错误处理（测内部）
集成测试：模块间接接口和通信
系统测试：包括恢复测试、安全性测试、强度测试、性能测试、可靠性测试、和安装测试
验收测试：有效性测试、软件配置审查、验收测试

其他测试：

回归测试：发现并解决问题后进行

负载测试：按设计原则进行测试，没要测性能

压力测试：测系统能承担的最大能力

4、测试管理

测试管理过程包括：制定测试计划及用例，执行测试，发现并报告缺陷，修正缺陷，重新测试
测试管理分类：

测试团队管理：根据不同业务分

测试计划管理

错误（缺陷）跟踪管理

测试件管理

4.3 系统运行与维护

软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动，这些活动包含在(1)交付前完成的活动，以及(2)交付后完成的活动。交付前完成的活动包括交付后运行的计划·和维护计划等，交付后的活动包括软件修改、培训、帮助资料等。

系统运维分为4类：

改正性维护（25%）:指在使用过程中发现了隐蔽的错误后，为了诊断和改正这些隐蔽错误而修改软件的活动。该类维护一般占总维护工作量的25%
适应性维护（20%）：指为了适应变化了的环境而修改软件的活动。该类维护一般占总维护工作量的20%
完善性维护（50%）：指为了扩充或完善原有软件的功能或性能而修改软件的活动。一般点总维护工作量的50%
预防性维护（5%）：指为了提高软件的可维护性和可靠性，为未来的进一步改进打下基础而修改软件的活动。

4.4 软件复用

软件复用是指利用已有软件的各种有关知识构造新的软件，以缩减软件开发和维护的费用。软件复用是提高软件生产力和质量的一种重要技术。
分类：

代码的复用

设计的复用

分析的复用

测试信息的复用

4.5 软件开发环境及过程管理（了解）

开发环境：

建模工具（Rational Rose)
设计工具（PowerDesign，ERWin）
开发工具（VisualStudio.NET,Eclipse)
测试工具（LoadRunner）
项目管理工具（Project，Clearcase，VSS，CVS）

软件过程管理：（集成了过程管理和项目管理，包括以下6个方面）

启动和范围定义
软件项目计划
软件项目实施
评审和评价
关闭
软件工程度量

三、面向对象技术

此节包含以下三个部分：
1、面向对象基本概念
2、UML
3、面向对象分析与设计

3.1 基本概念

面向对象技术有以下几个概念：

对象
类
抽象
封装
继承与泛化
多态(*)：指两个或多个属于不同类的对象，对于同一个消息（方法调用）作出不同响应的方式。它是一种方法，这种方法使得在多个类中可以定义同一操作或属性，并在每个类中可以由不同的实现。使得一个属性或变量在不同的时期可以表示不同类的对象。
接口
消息：可以理解为方法调用（函数）
组件
模式和复用

面向对象设计的7大原则（了解）：

单一职责原则：设计目的单一的类
开放、封闭原则：对扩展开放，对修改封闭
李氏替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现，针对接口编程，不要针对实现编程
接口隔离原则：使多个专门接口比使用单一的总接口要好
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
迪米特原则（最少知识法原则）：一个对象应对其他对象有尽可能少的了解。

3.2 UML

UML：UML 是一种定义良好、易于表达、功能强大旦普遍适用的建模语言。是面向对象分析的重要表示方法。它的作用域不限于支持OOA和OOD，还支持从需求分析开始的软件开发全过各。

1、UML的结构包括：

构造块：3种基本的构造块——事物，关系、图。（事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合）
规则：是构造块如何放在一起的规定
公共机制：指达到特定目标的公共UML方法。包括：规格说明（详细说明）、修饰、公共分类、扩展机制

2、UML中的关系：

依赖：两个事物之间的主义关系，其中一个事物发生变化会影响另一个事物的主义
关联：关联描述一组对象之间连接的结构关系
泛化：是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象
实现：是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

UML的特征：

可视化的建模语言

面向对象分析与设计的一种标准表示

允许任何一种过程和方法是用它

简单并且可扩展

强调重用（架构、框架、模式和组件）

3、UML2.0的图形分类：

用例图：特点-有客户元素。描述一组用例、参与者与它们之间的关系
顺序图/序列图：强调消息的时间次序。（是一种交互图，但有强调时间）
通信图/协作图：强调收发消息的对象或参与者的结构组织。
定时图*：强调消息跨越不同对象或参与者的实际时间，
状态图：有状态，有条件等元素。描述一个状态机，它由状态、转移、事件和活动组成。
活动图：强调对象的流转关系。将进程或其他计算结构展示为计算内部一步步的控制和数据流。
交互概览图*
类图：描述一组类、接口、协作和它们之间的关系。常在OO系统的建模中
对象图：描述一组对象及它们之间的关系。
包图*：描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
组合结构图*：描述结构化类的内部结构，包括结构化类与系统其余部分的交互点
构件图：描述一个封闭的类和它的接口、商品以及由内嵌的构件和连接件构成的内部结构
部署图：带服务器，TCP/IP的图
制品图*：描述计算机中一个系统的物理结构。包括文件、数据库和类似的物理比特集合。

UML图形描述之间的关系

3.3 面向对象分析技术（OOA）

面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。
OOA：Object Orient Analyse,面向对象分析
SA：Structural Analyse，结构化分析

1、用例模型
构建用例模型一般需要经历四个阶段：

识别参与者

合并需求获得用例

细化用例描述

调整用例模型：利用用例之间的关系来调整用例模型。（关系主要有：包含、扩展、泛化）

2、分析模型

定义概念类
识别类之间的关系：包括依赖，关联，聚合，组合，泛化，实现关系。
为类添加职责
建立交互图

下图描述类之间的关系表示：

3、面向对象分析与设计
步骤：

发现角色/参与者
发现用例
建立用例模型
进行领域分析
建立对象-关系模型
建立对象-行为模型
建立功能模型

目标：

描述用户需求
建立软件设计基础
定义可被确认的需求

面向对象设计分类：

用例设计
类设计
子系统设计

3.4 信息系统开发基础【重点】

1、软件质量保证与质量评价
软件：是计算机程序及其有关的数据和文档，也包括固化了的程序
**软件质量：**指软件产品中能满足给定需求的各种特性和和总和。这些特性称做质量特性，包括：功能特性，可靠性，时间经济必，资源经济性，可维护性和移植性等。
软件质量管理过程：

质量保证过程
验证过程：
确认过程：
审计过程：指评价软件产品
评审过程

验证是指确定软件开发周期中一个给定阶段的产品是否达到上一阶段确定的需求的过程
**确认：**指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程【重要】
**测试：**是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一
**审计：**指评价软件产品和过程对于设定规则、标准、流程等的遵从性。【背下来】

2、软件质量保证与质量评价

评审对现有的或提出项目成果所做的正式评估和审查，基目的是找出可能会影响项目产品、过程或服务工作的适用必和环境方面的缺陷，并制定补救措施，以及找出在性能、安全性和经济方面的可能的改进。
评审分类：
- 技术评审：目的是评价软件产品，以确定其对使用意图的适合性
- 管理评审：目的是监控进展，决定计划和进度的状态，或评价用于达到目标所用管理方法的有效性

3、软件质量保证的主要职责是？

检查开发和管理活动是否与已定的过程策略，标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。检查关键交付物的质量，是质量控制要做的事情。

3.5 GB/T 16260.1-2006质量模型【重要】