《系统架构设计师教程（第2版）》第5章-软件工程基础知识-01-软件工程

最新推荐文章于 2024-08-30 21:17:14 发布

玄德公笔记

最新推荐文章于 2024-08-30 21:17:14 发布

阅读量993

点赞数 19

分类专栏： # 《系统架构设计师教程（第2版）》上册文章标签：系统架构系统架构设计师教程软考架构师软件工程基础知识软件工程清华第2版

本文链接：https://blog.csdn.net/xingzuo_1840/article/details/135256725

版权

《系统架构设计师教程（第2版）》上册专栏收录该内容

63 篇文章 29 订阅

订阅专栏

文章目录

1. 软件工程概述
- 1.1 软件工程的定义
- 1.2 软件工程过程
2. 软件过程模型
3. 敏捷模型
4. 统一过程模型 (RUP)
5. CMMI

1. 软件工程概述

1.1 软件工程的定义

定义：很多组织给出不同定义

以下了解即可：

Barry Boehm: 运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。
IEEE: 软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②对①中所述方法的研究。
Fritz Bauer: 在NATO会议上给出的定义，建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
《计算机科学技术百科全书》:软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则和方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法；工程科学用于制定规范、设计范型 (Paradigm)、评估成本及确定权衡；管理科学用于计划、资源、质量、成本等管理。

1.2 软件工程过程

概述：是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动
包括以下4个方面：
- P(Plan)——软件规格说明：规定软件的功能及其运行时的限制
- D(Do)——软件开发：开发出满足规格说明的软件
- C(Check)——软件确认：确认开发的软件能够满足用户的需求
- A(Action)——软件演进：软件在运行过程中不断改进以满足客户新的需求

2. 软件过程模型

2.1 瀑布模型 (Waterfall Model)

模型：如下图
特点：
- 因果关系紧密相连
  - 前一个阶段工作的输出结果，是后一个阶段工作的输入，
  - 每一个阶段都是建筑在前一个阶段正确实施的结果之上
- 每一个阶段工作完成后都伴随着一个里程碑（一组检查条件），对该阶段的工作进行审查和确认
优点：
- 有利于人员的组织管理
- 有利于软件开发方法和工具的研究
缺点：
- 需求不确定：软件需求的完整性、正确性等很难确定
  
  因为用户不理解计算机和软件系统，对系统将来的改变也难以确定
- 串行化：是一个严格串行化的过程模型，开发周期长，出现与用户期望不一致或需求变更将带来巨大损失。
- 阶段不可能性：其基本原则是在每个阶段一次性地完全解决该阶段的工作（不会出现遗漏、错误等情况）而实际上这是不现实或不可能的

2.2 原型化模型/快速原型 (Prototype Model)

模型结构如下图：
在这里插入图片描述

分为原型开发阶段和目标软件开发阶段两个阶段：

1）原型开发阶段

行为：软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。
原型包含的内容：包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。
开发原型可以考虑的3种途径：
- 利用模拟软件系统的人机界面和人机交互方式
- 真正开发一个原型。
- 找来一个或几个正在运行的类似软件进行比较
使用原型模型应该注意以下内容：
- 用户对系统的认识模糊不清，无法准确回答目标系统的需求
- 要有一定的开发环境和工具支持
- 经过对原型的若干次修改，应收敛到目标范围内
- 大型软件不应考虑原型法（难以快速形原型，除非有现成的原型模型）

2）目标软件开发阶段

原型的使用：
- 抛弃型原型：原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。
- 演化性原型：在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品

2.3 螺旋模型(Spiral Model)

1）概述

产生：在快速原型的基础上扩展而成，是生命周期模型与原型模型的结合
适用范围
- 大型软件开发
- 面向规格说明、面向过程、面向对象的软件开发方法

2）螺旋每一层的4个阶段

目标设定

为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制订详细的管理计划。

风险分析

对可选方案进行风险识别和详细分析，制定解决办法，采取有效措施避免这些风险。

开发和有效性验证

风险评估后，可以为系统选择开发模型，进行原型/软件开发

评审

对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制订下一阶段计划。

3）螺旋结构

上述4个部分不断迭代，每迭代一次，螺旋线就增加一圈，软件系统就生成一个新版本
该新版本是对目标系统的一个逼近
经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内（否则也有可能中途天折）

3. 敏捷模型

教材此处又不一定从哪儿抄的文案，颠三倒四，甚至有错误，以下对章节和内容做了整理和部分修改

3.1 敏捷方法的核心思想

1）是适应型（而非可预测型）

软件需求的不稳定，导致软件过程的不可预测
- 传统方法：针对可预测的环境，计划制订完成后拒绝变化
- 敏捷方法：欢迎改变

软件开发和土木工程：（读一下，便于理解敏捷开发适应性的作用）
传统软件开发方法的基本思路一般是从其他工程领域借鉴而来，比如土木工程等。在这类工程实践中，通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分，交给不同的施工人员分别完成。但是，软件开发与上面的土木工程有着显著的不同。软件的设计是难以实现的，并且需要昂贵的有创造性的人员。土木工程师在设计时所使用的模型是基于多年的工程实践，而且一些设计上的关键部分都是建立在坚实的数学分析之上。而在软件设计中，完全没有类似的基础。软件开发无法将设计和实施分离开来，一些设计错误只能在编码和测试时才能发现，根本无法做出一个交给程序员就能直接编码的软件设计。所以，软件过程不可能照搬其他工程领域原有的方法，需要有适应其特点的新开发方法。

2）以人为本（非以过程为本）

传统开发方法：
- 将人看成一种资源，尽可能减少人的因素对开发的影响（角色很重要，个体可替代）
敏捷开发方法：
- 开发人员必须有权做技术方面的所有决定
- 特别强调开发中相关人员之间的信息交流（面对面交流）
操作：敏捷方法一般都按照高内聚、低耦合的原则将项目划分为若干小组，以增加沟通，提高敏捷性及应变能力

3）迭代增量式的开发过程

以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。
制订版本发行计划的依据：客户需求的优先级、开发风险

3.2 常用的敏捷方法

3.2.1 极限编程 (Extreme Programming,XP)

极限编程概述：
- 是一个轻量级的、灵巧的软件开发方法
- 是一个严谨和周密的方法
基础和价值观
- 交流（加强交流）
- 朴素（从简单做起）
- 反馈（寻求反馈）
- 勇气（勇于实事求是）
过程：（一种近螺旋式的开发方法）
- 将复杂的开发过程分解为一个个相对比较简单的小周期
- 积极交流、反馈，根据情况调整开发过程
通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程

3.2.2 水晶系列方法

其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷
团队可以根据其项目和环境选择最合适的 Crystal家族成员。

3.2.3 Scrum

概述：
- 侧重于项目管理
- 使用产品 Backlog 来管理产品的需求
- 包括了一系列实践和预定义角色的过程骨架(是一种流程、计划、模式，用于有效率地开发软件)
过程
- 创建产品 Backlog，它是一个按照商业价值排序的需求列表
- 根据Backlog 的内容，将整个开发过程被分为若干个短的迭代周期 (Sprint)
- 挑选最高优先级的需求组成 Sprint backlog
- 在每个迭代结束时，递交潜在可交付的产品增量
- 当所有 Sprint结束时，团队提交最终的软件产品

3.2.4 特征驱动开发方法 (Feature Driven Development,FDD)

3个要素：人、过程、技术
6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家（角色可重叠）
5个核心过程：
- 开发整体对象模型
- 构造特征列表
- 计划特征开发：
  - 根据构造出的特征列表、特征间的依赖关系进行计划
  - 设计出包含特征设计和特征构建过程组成的多次迭代
- 特征设计
- 特征构建

4. 统一过程模型 (RUP)

软件统一过程 (Rational Unified Process,RUP)
概述：
- 是一种重量级过程
- 其命周期是一个二维的软件开发模型
- 它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持
核心工作流（Discipline）：是相关活动的集合，这些活动都和项目的某一个方面有关

如：和业务建模相、和需求相关，和分析设计相关，等等。

4.1 九个核心工作流

业务建模 (Business Modeling)
- 理解待开发系统所在的机构及其商业运作
- 确保所有参与人员对待开发系统所在的机构有共同的认识
- 评估待开发系统对所在机构的影响。
需求 (Requirements)
- 定义系统功能及用户界面
- 使客户知道系统的功能
- 使开发人员理解系统的需求
- 为项目预算及计划提供基础。
分析与设计 (Analysis & Dcsign)
- 把需求分析的结果转化为分析与设计模型
实现 (Implementation)
- 把设计模型转换为实现结果
- 单元测试
- 将不同实现人员开发的模块集成为可执行系统。
测试
- 检查各子系统之间的交互、集成
- 验证所有需求是否均被正确实现
- 对发现的软件质量上的缺陷进行归档
- 对软件质量提出改进建议
部署 (Deployment)
- 打包、分发、安装软件，升级旧系统
- 培训用户及销售人员，并提供技术支持。
配置与变更管理 (Configuration & Change Management)
- 跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理 (Project Management)
- 为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
环境 (Environment)

为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

4.2 生命周期

1）循环(Cycle)

概述：RUP 把软件开发生命周期划分为多个循环
每个循环生成产品的一个新的版本

2）阶段(Phase)

概述：每个循环包含4个连续的阶段
- 初始 (inception) 阶段：定义最终产品视图和业务模型，并确定系统范围
- 细化 (elaboration) 阶段：设计及确定系统的体系结构，制订工作计划及资源要求
- 构造 (construction) 阶段：构造产品并继续演进需求、体系结构、计划直至产品提交
- 移交 (transition) 阶段：把产品提交给用户使用。
程碑 (Milestone) ：
- 位置：每个阶段结束前
- 作用：评估该阶段的工作
  - 未能通过里程碑的评估：决策者应该做出决定，是取消该项目还是继续做该阶段的工作

3）迭代 (Iteration)

概述：每一个阶段都由一个或多个连续的迭代 (Iteration) 组成
- 每个迭代针对不同用例的细化和实现（而不是重复相同的事）
- 每个迭代都是一个完整的开发过程
它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪。

4.3 RUP中的核心概念

1）角色 (Role)

概述：述某个人或一个小组的行为与职责（Who）
内容：
- RUP预先定义了很多角色
如体系结构师 (Architect)、设计人员 (Designer)、实现人员(Implementer)、测试员 (tester) 、配置管理人员 (Configuration Manager) 等
- RUP对每一个角色的工作和职责都做了详尽的说明

2）活动 (Activity)

概述：是一个有明确目的的独立工作单元（How）

3）制品(Artifact)

概述：是活动生成、创建或修改的一段信息（What）

Artifact有的书反以为：产品、工件

4）工作流 (Workflow)

概述：工描述了一个有意义的连续的活动序列
- 每个工作流产生一些有价值的产品，并显示了角色之间的关系

5）其他概念

如工具教程 (ToolMentor)、检查点 (Checkpoints)、模板 (Template) 和报告 (Report) 等

4.4 RUP 的特点

其特点如下：

用驱动的
以体系结构为中心的
迭代和增量的软件开发过程

1）用例驱动

即需求分析、设计、实现、测试等活动都是用例驱动的。

2）以体系结构为中心

RUP中的开发活动是围绕体系结构展开的。软件体系结构的设计和代码设计无关，也不依赖于具体的程序设计语言。

软件体系结构（架构）：
- 是一个多维结构
- 是软件设计过程中的一个层次
- 超越计算过程中的算法设计、数据结构设计
- 其设计包括：系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。
体系结构的设计需要考虑多方面的问题：
- 在功能性特征方面要考虑系统的功能
- 在非功能性特征方面要考虑系统的性能、安全性和可用性等
- 与软件开发有关的特征要考虑可修改性、可移植性、可重用性、可集成性和可测试性等
- 与开发经济学有关的特征要考虑开发时间、费用、系统的生命期等
- 以上特征之间有些是相互冲突的，一个系统不可能在所有的特征上都达到最优，这时就需要系统体系结构设计师在各种可能的选择之间进行权衡
4+1 视图模型：描述软件系统的体系结构
- 用例视图：
  - 描述：系统的行为
  - 关心人员：分析人员和测试人员
- 逻辑视图
  - 描述：系统功能
  - 关心人员：最终用户
- 实现视图
  - 描述：系统的配置、装配等问题
  - 关心人员：程序员
- 进程视图
  - 描述：系统的性能、可伸缩性、吞吐率等问题
  - 关心人员：系统集成人员
- 部署视图
  - 描述：系统的发布、安装、拓扑结构等问题
  - 关心人员：系统工程师

在这里插入图片描述

3）迭代与增量

RUP强调采用迭代和增量的方式来开发软件
- 把整个项目开发分为多个迭代过程
- 在每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程
- 每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现
- 直至最后项目的完成
优点
- 在软件开发的早期就可以对关键的、影响大的风险进行处理。
- 可以提出一个软件体系结构来指导开发。
- 可以更好地处理不可避免的需求变更。
- 可以较早得到一个可运行的系统，鼓舞发团队的士气，增强项目成功的信心。
- 为开发人员提供一个能更有效工作的开发过程。

5. CMMI

5.1 概述

CMM
- 软件能力成熟度模型 (Capability Maturity Model for Software,CMM)
- 是一个概念模型
- 框架和表示是刚性的（不能随意改变），但模型的解释和实现有一定弹性
CMMI
- 软件能力成熟度模型集成（Capability Maturity Model Integration for Software）
- 在 CMM 的基础上发展而来的，一种软件能力成熟度评估标准
- 作用：
  - 指导软件开发过程的改进
  - 进行软件开发能力的评估