【系统分析师】软件工程

---

【系统分析师-系列文章目录 】

---

非 系统分析师 的重点！！！

1、软件生命周期

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生命周期或生存周期。

1.1 软件生存周期过程

在国家标准 GB/T 8566-2007 标准中，将软件生存周期中可能执行的活动分为：

1. 5个基本过程
2. 9个支持过程
3. 7个组织过程

每个生存周期过程划分为一组活动，每一项活动进一步划分为一组任务。

1.1.1 5个基本过程

基本过程供 各主要参与方在软件生存周期期间使用，主要参与方是发起或完成软件开发、运行或维护的组织。

基本过程分为：

1. 获取过程
2. 供应过程
3. 开发过程
4. 运作过程
5. 维护过程

1.1.2 9个支持过程

支持过程，作为一个有机组成部分 支持其他过程，以便取得软件项目的成功，并提到软件项目的质量。

支持过程包括：

1. 文档编制过程
2. 配置管理过程
3. 质量保证过程
4. 验证过程
5. 确认过程
6. 联合评审过程
7. 审核过程
8. 问题解决过程
9. 易用性过程

1.1.3 7个组织过程

组织过程 可被某个组织 用来 建立和实现 由相关的生存周期过程和人员组成的基础结构 并不断改进这种结构的过程。

应用它们通常超出特定的项目和合同的范围，但是，这些特定项目和合同的经验教训有助于改善组织状况。

组织过程包括：

1. 管理过程
2. 基础设施过程
3. 改进过程
4. 人力资源过程
5. 资产管理过程
6. 重要大纲管理过程
7. 领域工程过程

1.2 软件生命周期各阶段的任务

根据 GB/T 8566-2007，软件生命周期可以划分为可行性研究、需求分析、概要设计、详细设计、实现、组装测试、确认测试、使用、维护、退役 10个阶段。

1. 可行性研究：确认软件项目性质、目标和规模，得出可行性报告。如果是可行的，就要指定详细的项目开发计划。
2. 需求分析：把软件性能和功能的总体概念 描述为具体的软件需求规格说明，从而奠定开发的基础。
3. 概要设计：根据软件需求规格说明建立软件的总体结构和模块间的关系，定义各功能模块接口，设计全局数据库或数据结构，规定设计约束，指定组装测试计划。
4. 详细设计：将各模块要实现的功能用相应的设计工具详细描述出来。
5. 实现：程序员根据详细设计文档将详细设计转化为程序，完成单元测试。
6. 组装测试：经过单元测试的模块逐步进行组装和测试。
7. 确认测试：测试系统是否达到了系统需求，由用户或用户参与 对系统进行验收。
8. 使用：
9. 维护：
10. 退役

---

立项阶段
开发阶段
运维阶段
消亡阶段

其中重头戏是：开发阶段
单个系统开发 流程

# 需要关注不同阶段的产出物 - 会考选择
系统规划
系统分析
系统设计
系统实施
系统验收

2、软件开发方法

2.1 形式化方法

2.1.1 形式化方法概述

提高软件可靠性的一种重要技术是使用形式化方法。

形式化方法建立在严格数学基础上，具有精确数学语义的开发方法。

近年来，形式化方法在以下两个方面的发展大大改善了其实用性：

1. 形式化方法与图形语言机制相结合。为图形语言机制赋予形式化的语法和语义，从而兼具了图形表示的直观、简洁，以及形式化方法的严谨、精确等优点。
2. 用CASE（计算机辅助软件工程）工具支持形式化软件开发。CASE工具不仅能简化描述工作，而且还可以利用自动证明技术，帮助开发人员验证软件的数学性质。

2.1.2 净室软件工程

• 是软件开发的一种形式化方法
• 使用 盒结构规约 进行分析和建模
• 并且将正确性验证作为发现和排除错误的主要机制
• 使用统计测试来获取认证软件可靠性所需要的信息。

主要缺点：

1. 对开发人员的要求比较高
2. 正确性验证的步骤比较困难，且比较耗时
3. 开发小组不进行传统的模块测试，这是不现实的。

2.1.3 逆向工程

相关概念

1. 重构：在同一抽象级别上转换系统描述的方式。
2. 设计恢复：利用工具xxxx
3. 再工程：得到新的
4. 正向工程：改善

完备性

例题

2.2 软件开发模型

2.2.1 软件开发模型概述

瀑布模型

缺点：
1、需求或设计中的错误，往往只有到了项目后期才能被发现；
2、对于项目风险的控制能力较弱
3、软件项目常常延期完成 或 开发费用超出预算
4、项目管理人员专注于文档的完成和审核来评估项目的进展

原型

# 涉及 迭代思想
1、原型
2、螺旋模型:看到 风险 选螺旋模型
3、瀑布模型
4、增量模型
5、快速原型模型

演化模型

主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中 提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这个过程，直到演化成最终的软件产品。

优点：

1. 任何功能一经开发 就能进入测试，以便验证是否符合产品需求

缺点：

1. 如果不加控制的让用户接触开发中尚未稳定的功能，可能对开发人员以及用户都会产生负面的影响

螺旋模型

螺旋模型，是瀑布模型和演化模型相结合，并加入两者所忽略的 风险分析 所建立的一种软件开发模型。

螺旋模型沿着螺线进行若干次迭代，每次迭代都包括

1. 制定计划
2. 风险分析
3. 实施工程
4. 客户评价

四个方面的工作。

螺旋模型强调风险分析！！！

优缺点：

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

喷泉模型

是一种面向对象模型

• 以用户需求为动力
• 以对象为驱动的模型
• 该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的。
• 适用于需求不明确或经常变更的项目，以及需要快速响应变化的项目。

变换模型

基于形式化规格说明语言和程序变换的软件开发模型。

智能模型

也称 基于知识的软件开发模型。

V模型

主要是强调：测试活动如何与分析、设计相关联的！！！测试贯穿始终！！！

2.2.2 快速应用开发

• 强调极短的开发周期
• 瀑布模型的高速变种
• 通过使用基于构件的开发方法获得快速开发

基本思想

• 让用户更主动的参加到系统分析、设计和构造活动中来；[用户参与]
• 将项目开发组织成 一系列重点突出的研讨会，让项目投资方、用户、系统分析师、设计人员和开发人员一起参与；
• 通过一种迭代的构造方法，加速需求分析和设计阶段；[迭代]
• 让用户提前看到一个可工作的系统。

RAD的开发阶段

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

1. 业务建模：确定 驱动业务过程 运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以使用DFD来帮助建立业务模型。
2. 数据建模：为支持业务过程的数据流 查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用 E-R图来帮助构建数据模型。
3. 处理建模：将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即 细化数据流图中的加工。
4. 应用生成：复用已有构件或创建新的可复用构件，利用环境提供的工具自动生成并构造出整个应用系统。
5. 测试与交付：由于RAD强调复用，许多构件是已经测试过得，减少了测试的时间。由于大量复用，所以一般只做总体测试，但是新创建的构件还是要测试的。

RAD 特点

优点：

1. 使用可复用构件，加快了开发速度

缺点：

1. 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一项功能不能被模块化，那么建造RAD所需要的构件就会有问题；
2. 如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不奏效
3. 开发者和客户必须在很短的时间，完成一系列的需求分析，任何一方不配合，都会导致RAD项目失败；
4. RAD只能用于信息系统开发，不适合技术风险很高的情况。

2.2.3 统一过程 ***

爱考

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

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

三个显著特点

1. 用例驱动
2. 以架构为中心
3. 迭代和增量

RUP概述

• RUP 是 Rational公司开发和维护的过程产品，是由Objectory过程演化而来。

• RUP将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。

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

1. 初始阶段：确认需求和风险评估、确定系统的边界问题、识别关键用例。产出物：项目蓝图文档、用例模型、项目计划。
2. 细化阶段：完成架构设计，淘汰高风险元素
3. 构建阶段：开发剩余构件，组装构件，测试。产出物：UML模型，测试用例。
4. 移交阶段：β测试，交付。产出物：软件产品、用户手册、用户支持计划。

---

初始阶段

初始阶段的任务是为系统建立业务模型并确定项目的边界。
在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。
在这个阶段，所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。

初始阶段实现过程如下：

1. 明确项目规模：建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的需求和约束，识别系统的关键用例。
2. 评估项目风险：
3. 制定项目计划：估计整个项目的总体成本、进度和人员安排。综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源
4. 阶段技术评审：项目规模的定义、成本、进度、对软件的理解、风险是否有规避的方法~

细化阶段

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

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

细化阶段的实现过程如下：

1. 确定架构
2. 制定 构建阶段 计划：为构建阶段制定详细的过程计划并为其建立基线。
3. 建立支持环境：开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。
4. 选择构件：评估现有构件和潜在构件，成本控制构件~~集成所选构件，并按主要场景进行评估。
5. 阶段技术评审：需要检验 详细的系统目标和范围、架构的选择，以及主要风险的解决方案

在细化阶段，可执行的原型依赖于项目的范围、规模、风险和先进程度。必须至少处理初始阶段中识别的关键用例，因为关键用例通常揭示了项目的主要技术风险。

构建阶段

构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。

从某种意义上说，构建阶段是一个制造的过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。

构建阶段的主要任务是

1. 通过优化资源和避免不必要的报废和返工，使开发成本降到最低；
2. 完成所有所需功能的分析、开发和测试，快速完成可用的版本；
3. 确定软件、场地和用户是否已经为部署软件做好准备。

构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。

交付阶段

当极限已经足够完善，可以安装到最终用户实际环境中，则进入交付阶段。

交付阶段的重点是确保软件对于最终用户是可用的。

交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，例如，进行调试、性能或可用性的增强等。

2.2.4 敏捷方法

SCRUM使用最多，下面介绍一下SCRUM

---

---

2.2.5 构件组装模型

# 优点：
1.构件组装模型导致了软件的复用，提高了软件开发效率
2.构件可以由一方定义其规格说明，被另一方实现，然后供给第三方使用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可以分步提交软件产品。
# 缺点：
1.由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入较大的风险；
2.可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员，一般开发人员插不上手，客户满意度低；
3.过分依赖于构件，构件库的质量影响着产品质量。

# 构件获取途径
1.从现有构件中获得符合要求的构件，直接使用或做适用性修改，得到可复用的构件
2.通过遗留工程，将有价值的构件提取出来，得到
3.从市场上购买现成的商用构件
4.开发新的符合要求的构件
具体选用哪种，考虑，一次性成本和维护成本

---

统一过程[UP]和敏捷开发的区别？

---

汇总：

# 之前 信息系统开发 - 涉及到三种，见第一篇文档
1、结构化方法
2、面向对象的方法
3、面向服务的方法

# 此处补充说明 面向服务的方法
OO的应用构建在类和对象之上，随后发展起来的建模技术将相关对象按照业务功能进行分组，就形成了构件的概念。
对于跨构件的功能调用，则采用接口的形式暴露出来，进一步将接口的定义与实现进行解耦，则催生了服务和面向服务的开发方法。
由此可见，面向对象、基于构件、面向服务 是三个递进的抽象层次。

SO方法有三个主要的抽象级别：操作、服务和业务流程，
1、操作（最低层）：代表单个逻辑单元的事物。
	执行 操作 通常会导致读、写或修改一个或多个持久性数据。服务的操作类似于对象的方法，都有特定的结构化接口，并且返回结构化的响应；
2、服务：代表操作的逻辑分组；
3、业务流程：为了实现特定业务目标而执行的一组长期运行的动作或活动 ，包括 依据一组业务规则按照有序序列执行的一系列操作。
	其中：操作的排序、选择和执行 成为服务或流程的编排，典型的情况是：调用已编排的服务来响应某业务事件。

3、软件开发工具与环境

非重点

软件环境主要是分为两个：
1. 软件开发环境（SDE）
2. 软件生存期支持环境

##3.1 软件开发环境-SDE
Software Development Environment

什么是软件开发环境？

SDE 是指支持软件的工程化开发和维护而使用的一组软件
由：1）软件工具集；2）软件环境集成机制 构成。

3.1 SDE-软件环境集成机制

软件开发环境应支持多种集成机制：
如：平台集成、数据集成、界面集成、控制集成和过程集成等。

软件开发环境应支持小组工作方式，并为其提供配置管理。环境的服务可用于支持各种软件的开发活动，包括分析、设计、编程、调试和文档等。

较完善的软件开发环境通常具有多种功能，如 软件开发的一致性和完整性维护、配置管理及版本控制、数据的多种表示形式及其在不同形式之间的自动转换、信息的自动检索与更新，项目控制与管理、以及对开发方法学的支持。

软件开发环境具有 集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。

集成机制根据功能的不同，可划分为1）环境信息库；2）过程控制与消息服务器；3）环境用户界面 三部分。

3.2 SDE-软件工具集

系统规划工具
建模工具
分析设计工具
编程工具
测试工具
项目管理工具

3.3 软件生存期支持环境（忽略）

(1)软件生存期支持环境应能支持软件生命周期各个阶段:
（包括程序设计、系统分析、软件设计、软件测试和软件维护等）的各种技术活动和项目管理活动。
(2)其主要任务是支持大型软件项目的开发和维护，达到缩短开发周期、节省开发成本和提高产品质量的目的。
(3)在软件生存期支持环境的帮助下，软件开发团队能够更高效地进行软件需求分析、设计、编码、测试以及后续的维护等工作。
(4)这个环境提供了各种工具和方法，帮助开发团队确保软件的质量、可靠性和性能，同时降低开发过程中的风险。

4、能力成熟度模型

4.1 CMM

CMM - Capability Maturity Model

4.2 CMMI

Capability Maturity Model Integration
是CMM模型的最新版本