架构设计 相关文档，希望互相学习，****************************
****************************共同进步
知识总览
共19章内容，主要包括：
1）1绪论、2计算机系统、3信息系统、4信息安全技术、5软件工程
2）6数据库设计、7系统架构设计基础知识
3）8系统质量属性与架构评估、9软件可靠性、
10软件架构演化与维护、11未来信息综合技术
4）12信息系统架构设计、13层次式架构设计、14云原生架构设计、
15面向服务架构设计、16嵌入式系统架构设计、17通信系统架构设计、
18安全架构设计、19大数据架构设计
每天进步一点点，加油！小伙伴们！💪
本文学习第5章 软件工程基础知识，以下为个人笔记，希望有所帮助，共同学习。
（本章节 + 下篇架构知识，非常重要，在三门考试中都会出题，日常开发中也常面对。本章节内容比较基础，难度不大，但是本章节 很重要！很重要！很重要！）
包括：软件工程（定义、软件过程模型、敏捷模型、RUP模型、软件成熟度模型）、
需求工程（获取、变更、追踪）、
系统分析与设计（机构化方法、面向对象方法）、
软件测试（测试方法、测试阶段）、
净室软件工程（理论基础、技术手段、应用与缺点）、
基于构件的软件工程（构件和构件模型、CBSE过程、构件组装）、
软件项目管理（概述、进度、配置、质量、风险管理）
第5章 软件工程基础知识
5.1 软件工程
5.1.1 定义
软件工程是以工程的管理方法去管理软件项目，涉及的知识点很多，也很重要。
软件危机（Software Crisis）。具体表现为：软件开发进度难以预测、软件开发成本难以控制、软件功能难以满足用户期望、软件质量无法保证、软件难以维护和软件缺少适当的文档资料。
◆软件工程过程 ：是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面：
(1) P (Plan)-----软件规格说明。规定软件的功能及其运行时的限制。
(2) D (Do)-------软件开发。开发出满足规格说明的软件。
(3) C (Check)---软件确认。确认开发的软件能够满足用户的需求。
(4) A (Action)----软件演进。软件在运行过程中不断改进以满足客户新的需求。
5.1.2 软件过程模型
软件过程模型：软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个全过程就是软件的生命周期。软件生命周期描述了软件从生到死的全过程。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型，有时也称为软件生命周期模型。
常见的软件过程模型主要包括：
1）瀑布模型（Waterfall Model）
定义：是结构化开发方法使用的软件过程模型，最早使用的软件过程模型之一。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。每一个阶段工作完成后都伴随着一个里程碑（一组检查条件）。
缺点：需求难以一次确定、变更的代价高、结果难以预见、 各阶段工作不能并行。
2）原型模型（Prototype Model）
原型模型，又称快速原型 ，是原型方法使用的生命周期模型。
解决：瀑布模型需求难以一次确定、结果难以预见的缺点。
原型模型的两个阶段：原型开发、目标软件开发 。
(1)原型开发阶段。即快速开发一个原型。
开发原型可以考虑3种途径：利用模拟软件系统的人机界面和人机交互方式；真正开发一个原型；找来一个或几个正在运行的类似软件进行比较。
(2)目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。
◆原型模型的使用应该注意以下内容：
·用户对系统的认识模糊不清，无法准确回答目标系统的需求。
要有一定的开发环境和工具支持。
·经过对原型的若干次修改，应收敛到目标范围内，否则可能会失败。
·对大型软件来说，原型可能非常复杂而难以快速形成，如果没有现成的原型模型，就不应考虑用原型法。
按原型作用不同分类：抛弃型原型将原型作为需求确认的手段，在需求确认结束后就被抛弃不用，继续用瀑布模型。演化性原型在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。
3）螺旋模型（Spiral Model）
是在快速原型的基础上结合瀑布模型扩展而成。
把整个软件开发流程分成多个阶段 ，每一个阶段都由目标设定、风险分析、开发和有效性验证、评审 4 部分组成。每迭代一次，螺旋线增加一圈，软件系统就生成一个新版本。
支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，强调 其他模型忽视的风险分析。
4）V模型
◆V模型：从整体上看起来，就是一个V字型的结构，由左右两边组成。
左边的下画线分别代表了 需求分析、概要设计、详细设计、编码。
右边的上画线分别代表了 单元测试、集成测试、系统测试、验收测试。
V模型的特点如下：
（1）单元测试 的主要目的是针对编码过程中可能存在的各种错误；
（2）集成测试 的主要目的是针对详细设计中可能存在的问题；
（3）系统测试 主要针对概要设计，检查系统作为一个整体是否有效地得到运行；
〈4）验收测试 通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
（5）V模型 用于需求明确、需求变更不频繁的情形。
注意：测试阶段依赖的文件是对应++开发阶段的上一个阶段++，如单元测试依据 详细设计文件。
5）增量模型
◆增量模型：首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。
6）喷泉模型
◆喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
7）基于构件的开发模型CBSD
基于构件的开发模型CBSD：利用预先包装的构件来构造应用系统。
构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
特点是：增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
8）形式化方法模型
◆形式化方法模型：建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。
5.1.3 敏捷模型（Agile）
敏捷开发宣言：++个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划++ 。
敏捷（Agile）模型，属于敏捷方法使用的模型。
包括：极限编程（Extreme Programming，XP）、水晶系列方法、
并列争球法（Scrum）、
**特征驱动开发方法（Feature Driven Development，FDD）**等敏捷方法。
显著特征如下：
++极限编程（XP）++：高效、低风险、测试先行（先写测试代码，再编写程序）。基础和价值观是 交流、朴素、反馈和勇气。任何一个项目从4方面改善：加强交流、从简单做起、寻求反馈、勇于实事求是。
++水晶系列方法++ ：不同的项目，采用不同的策略。每个都含有独特的角色、过程模式、工作产品和实践。
++并列争球法（Scrum）++：侧重于项目管理。Scrum 包括一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件），迭代增量软件开发过程。常用于敏捷软件开发。在 Scrum 中，使用产品 Backlog来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。根据 Backlog 的内容，将整个开发过程分为若干个短的迭代周期（Sprint），在 Sprint 中，Scrum 团队从产品Backlog 中挑选最高优先级的需求组成 Sprint Backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。
当所有 Sprint 结束时，团队提交最终的软件产品。
++特征驱动开发方法 FDD++：将开发人员分类，分为指挥者（首席程序员）、类程序员等。是个迭代的开发模型。认为有效的软件开发需要3个要素：人、过程和技术。
FDD 有5核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计、特征构建。
◆敏捷方法区别于其他方法的两个特点：
（1）是 "适应性"而非"预设性"。
（2）是"面向人的"而非"面向过程的"。
◆敏捷方法的核心思想：
（1）敏捷方法是适应型，而非可预测型。拥抱变化，适应变化。
（2）敏捷方法是以人为本，而非以过程为本。发挥人的特性。
（3）迭代增量式的开发过程。以原型开发思想为基础，采用法代增量式开发，发行版
本小型化。
5.1.4 统一过程模型 RUP
软件统一过程（ Rational Unified Process ， RUP ）模型， RUP 是一种重量级过程模型，属于 构件化开发使用的软件过程模型。RUP描述了如何有效的利用商业的、可靠的方法开发和部署软件，类似一个在线的指导者，可为所有方面和层次的程序开发提供指导方针、模版及事例支持。
其 生命周期是一个二维的软件开发模型 ，划分为多个循环 （Cycle ），每个循环生成产品的一个新的版本，每个循环依次由初始、细化、构造和移交 4 个连续 的阶段（Phase ）组成，每个阶段完成确定的任务。
初始阶段：定义最终产品视图和业务模型，并确定系统范围。
·细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
·移交阶段：把产品提交给用户使用，
RUP 中有 9 个核心工作流， 分别是：
++业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境++。
RUP 的特点： ++用例驱动的、以架构为中心的、迭代和增量的软件开发过程++ 。
RUP 用" 4+1 "视图模型来描述架构，如图 所示，后被 UML 吸收采纳。
1）逻辑视图：对应最终用户，主要支持功能性需求，即在为用户提供服务方面系统所应该提供的功能。逻辑视图常用 类图、对象图、状态图、协作图 表示。
2）实现视图：又称开发视图，对应程序员，关注软件开发环境下实际模块的组织，描述系统的各部分如何被组织为模块和组件即开发环境中软件的静态组织结构。
该视图通常包含 包图和组件图 。
3）进程视图：又叫过程视图，对应系统集成人员，考虑一些非功能性的需求，如性能和可用性，它可以解决并发性、分布性、系统完整性、容错性的问题。
进程视图常用 活动图 表示。
4）部署视图：又叫物理视图，对应系统工程师。描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。展示了如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通信等问题。
部署视图常用 部署图 表示。
5）用例视图：所有其他视图 都依靠用例视图（场景）来指导它们 ，这就是将模型称为"4+1 " 的原因。
RUP 在每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程。
5.1.5 软件能力成熟度模型 CMM
软件能力成熟度模型（ Capability Maturity Model for Software ， CMM ）， CMM 是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。随着软件组织定义、实施、测量、控制、改进其软件过程，软件组织的能力经过这些阶段逐步提高，分为5个级别：
软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）。 CMMI 是在 CMM 的基础上发展而来的。用于指导 软件开发过程的改进和进行软件开发能力的评估，共18个关键过程域，52个过程目标，3168种关键时间，循序渐进。CMMI 提供了一个软件能力成熟度的框架，它 将软件过程改进的步骤组织成 5 个成熟度等级 ：初始级、已管理级、已定义级、量化管理级、优化级。
量化管理级与已定义级的区别是 对过程性能的可预测 。
5.2 需求工程 RE
1概念
需求工程（Requirement Engineering，RE），需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统 及其行为特征和相关约束。
需求工程由需求获取、需求分析、形成需求规格（或称为需求文档化）、 需求确认与验证、需求管理 5 个阶段组成。
软件需求包括 3 个不同的层次：
（ 1 ）业务需求（ Business Requirement ），反映了组织机构或客户对系统、产品高层次的目标要求。
（ 2 ）用户需求（ User Requirement ），描述了用户使用产品必须要完成的任务，是用户对该软 件产品的期望。业务需求和用户需求构成了用户原始需求文档的内容。
（ 3 ）功能需求（ functional requirement ），从系统操作的角度定义了开发人员必须实现的软件 功能，来满足业务需求和用户需求。
软件需求规格说明书（Software Requirement Specification，SRS），SRS 具体包括功能需求、非功能需求和约束(设计约束和过程约束)。批准的 SRS 是需求开发和需求管理之间的桥梁。
需求管理是一个对系统需求变更、了解和控制的过程，包括变更控制、版本控制、需求跟踪等活动。
2需求获取
需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。需求获取的基本步骤：
（ 1 ）开发高层的业务模型。
（ 2 ）定义项目范围和高层需求。
（ 3 ）识别用户角色和用户代表。
（ 4 ）获取具体的需求。
（ 5 ）确定目标系统的业务工作流。
（ 6 ）需求整理与总结。
需求获取的方法包括 用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法和头脑风暴法 等。
3需求变更
变更控制委员会（ Change Control Board ， CCB ）
CCB 由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。 CCB 是决策机构，不是作业机构 ，通常 CCB 的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。 过程及操作步骤为制定决策、交流情况、重新协商约定。
需求变更管理过程：
4需求追踪
需求跟踪提供了 由需求到产品实现整个过程范围的明确查阅的能力 。
需求跟踪的目的是建立与维护 "需求---设计---编程---测试"之间的一致性， 确保所有的工作成果符合用户需求 。
需求跟踪有 正向跟踪 和逆向跟踪 两种方式，合称为" 双向跟踪 "。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。
ok, 今天就到这里吧 🤗
相关系列文章，欢迎点赞、收藏，提供意见！****
计算机系统基础知识 1分：概述、计算机硬件、计算机软件
操作系统 3分：进程管理、存储管理、文件管理、设备管理
数据库技术 3分：数据库设计、关系代数、范式、事务并发、数据库安全、新技术
嵌入式技术 3分：嵌入式硬件、嵌入式操作系统、嵌入式软件开发
计算机网络 3分（超纲较多）：OSI七层模型、TCP/IP协议族、网络生命周期、IP地址
其他计算机系统基础知识 1分：计算机语言、多媒体、系统工程
系统性能 1分：性能指标、性能设计
信息系统基础知识 3分：信息系统生命周期、开发方法、五大典型系统
信息安全技术基础 5分：安全属性、信息安全技术、网络安全技术、安全协议
软件工程 12分：概述、需求工程、系统设计、运维、测试、基于构件；
面向对象技术 3分：面向对象基础、分析设计、UML关系、图
项目管理 1分：进度管理、配置管理、质量管理、风险管理
系统架构设计 20分：架构概念、生命周期、ABSD、DSSA、架构风格、
架构复用、质量属性、架构评估
软件可靠性 2分：可靠性建模、软件可靠性设计
软件架构的演化和维护1分：架构演化分类、评估、面向对象架构演化
未来信息综合技术 3分：信息物理系统、人工智能、边缘计算、机器人、数字李生、云计算
数学与经济管理 2分：最小生成树、最短路径、网络与最大流量、线性规划、决策论
知识产权和标准化 2分：知识产权属性、保护期限、产权人确定、侵权判定
专业英语 5分：完形填空，大学英语3级难度，自学
|------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| 【架构专栏】架构考试介绍 | 【架构专栏】架构知识点 |
| 【架构专栏】第1章 绪论 | 【架构专栏】第11章 未来信息综合技术 |
| 【架构专栏】第2章 计算机基础知识 | 【架构专栏】第12章 信息系统架构设计理论与实践 |
| 【架构专栏】第3章 信息系统基础知识 | 【架构专栏】第13章 层次式架构设计理论与实践 |
| 【架构专栏】第4章 信息安全技术基础知识 | 【架构专栏】第14章 云原生架构设计理论与实践 |
| 【架构专栏】第5章 软件工程基础知识 | 【架构专栏】第15章 面向服务架构设计理论与实践 |
| 【架构专栏】第6章 数据库设计基础知识 | 【架构专栏】第16章 嵌入式系统架构设计理论与实践 |
| 【架构专栏】第7章 系统架构设计基础知识 | 【架构专栏】第17章 通信系统架构设计理论与实践 |
| 【架构专栏】第8章 系统质量属性与架构评估 | 【架构专栏】第18章 安全架构设计理论与实践 |
| 【架构专栏】第9章 软件可靠性基础知识 | 【架构专栏】第19章 大数据架构设计理论与实践 |
| 【架构专栏】第10章 软件架构的演化和维护 | |
[架构专栏 知识点]
希望有所帮助，互相学习、共同进步，欢迎点赞、收藏！