文章目录

一、软件工程概述
- 1. 定义
- 2. 软硬件失效
- 3. 软件危机
- 4. 软件工程三要素
- 5. 软件工程目标
- 6. 软件工程研究内容
- 7. 软件工程知识体系
二、软件生命周期模型
- 2.1 软件工程过程：PDCA循环
- 2.2 软件生命周期 software life cycle
- 2.3 过程模型（软件生命周期模型）
- - 2.3.1 瀑布模型
  - 2.3.2. V模型和W模型
  - 2.3.2 原型方法(prototyping)
  - 2.3.4. 演化模型
  - 2.3.5. 增量模型
  - 2.3.6. 螺旋模型
  - 2.3.7. 喷泉模型(迭代模型)
  - 2.3.8. 构件组装模型
  - 2.3.9. 快速应用开发(RAD)模型
- 2.4 新型软件生命周期模型
- - 2.4.1 统一软件开发过程
  - 2.4.2.敏捷开发
三、软件需求分析
- 3.1 系统分析
- 4.2 需求定义
- 4.3 软件需求分析的目标及任务
- 4.4 软件需求分析建模的原则和方法
- 4.5 软件需求工程
- - 4.5.1 软件需求分析过程
- 1.需求获取
- 2.需求建模
- 3.需求确认
四、面向对象需求分析方法
- 4.1 UML概述
- 4.2 UML图
- - 4.2.1. 用例图
  - 4.2.2. 类图
  - 4.2.3. 对象图
  - 4.2.4. 顺序图
  - 4.2.5. 协作图
- 4.3 面向对象分析概述
- 4.4 用例建模
- - 用例之间的关系
- 4.5 创建领域模型 Domain Model
- 4.6 绘制系统顺序图
- 4.7 创建系统操作契约
五、结构化分析
- 分析模型的结构
- 5.1. 数据建模与范式
- 5.1.1 实体关系图(ER图)
- - 5.1.2 数据结构规范化
5.2. 功能建模与数据流图
- 5.3 系统行为建模
- 5.4. 数据词典 (DD，Data Dictionary)
六、软件设计
- 6.1 软件设计概述
- 6.2 软件概要设计的步骤
- 6.3 软件详细设计的步骤
- 6.4 软件设计模型
- 6.5 软件设计原则
七、面向对象设计
- 7.1 面向对象设计综述
- 7.2 模型层次化
- 7.3 面向对象设计原则
八、结构化设计方法
- 8.1 结构化设计的映射模型
- 8.2 系统功能结构图及数据流映射
- 8.3 数据设计和文件设计的原则
- 8.4 设计的后处理
- 8.5 详细设计
九、软件实现、测试和维护
- 9.1 软件实现
- 9.2 软件测试基础
- - 9.2.1 软件测试概述
  - 9.2.2. 软件的可测试性
  - 9.2.3. 软件测试的对象(现代和广义的测试定义)
  - 9.2.4. 软件测试信息流
  - 9.2.5. 软件测试步骤
- 9.3 软件测试方法与技术
- 9.4 软件测试过程
- 9.5 软件维护

原课程：北京邮电大学软件工程 https://www.bilibili.com/video/BV1Bi4y1G7qYpm_id_from=333.337.search-card.all.click

一、软件工程概述

1. 定义

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

2. 软硬件失效

优点：
⑴ 软件生命周期的阶段划分不仅降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，便于将软件工程过程和软件管理过程有机地融合在一起，从而提高软件开发过程的可管理性。
⑵ 推迟了软件实现，强调在软件实现前必须进行分析和设计工作。
⑶ 瀑布模型以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。

缺点：
⑴ 模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题，这是瀑布模型最突出的缺点。因此，瀑布模型只适合于需求明确的软件项目。
⑵ 模型的风险控制能力较弱。成品时间长；体系结构的风险和错误只有在测试阶段才能发现，返工导致项目延期。
⑶软件活动是文档驱动的，文档过多会增加工作量，文档完成情况会误导管理人员。

2.3.2. V模型和W模型

(1) V模型——瀑布模型的变种

2.3.2 原型方法(prototyping)

1. 提出原因
完整准确的需求规格说明很难得到
通过加强评审和确认、全面测试也不能从根本上解决需求不稳定带来的问题。

2. 概述
原型：是指模拟某种产品的原始模型。软件原型是一个早期可以运行的版本，它反映最终系统的部分重要特性。

原型方法构造软件系统：

获得一组基本的需求说明，快速分析构造出一个小型的软件系统，满足用户的基本要求；
用户试用原型系统，对其进行反应和评价；
开发者根据用户意见对原型进行改进，获得新的原型版本；
周而复始，直到产品满足用户的要求。

原型化方法是在研究需求分析技术的过程中产生的，但也可以用于软件开发的其他阶段

3. 原型的种类（目的）
探索型：弄清对目标系统的要求
实验型：系统实现前考察系统的可行性
进化型：将原型扩展到开发过程，通过原型开发逐步实现所有系统功能。

4. 原型的使用策略
废弃策略：探索型和实验型
追加策略：进化型
原型不同于最终的系统，需要快速实现和运行，因此，原型可以忽略一切暂时不必关心的部分（抽象）

5. 优点

有助于增进软件人员和用户对系统服务需求的理解
提供了一种有力的学习手段
容易确定系统的性能、服务的可应用性、设计的可行性和产品的结果
原型的最终版本可作为最终产品或最终系统的一部分

6. 缺点

文档容易被忽略
建立原型的许多工作会被浪费掉
项目难以规划和管理

7. 应用过程

演化模型主要针对需求不是很明确的软件项目

演化模型缺点：

可能会抛弃瀑布模型的文档控制优点，开发过程不透明
探索式演化模型可能会导致最后的软件系统的系统结构较差
可能会用到一些不符合主流、不符合要求或者不成熟的工具和技术

2.3.5. 增量模型

结合了瀑布模型和演化模型的优点。

允许客户的需求可以逐步提出来；每一次“增量”需求的划分与“增量”实现的集成是以不影响系统体系结构为前提的。

螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：

制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件
风险分析──分析所选方案，考虑如何识别和消除风险
实施工程──实施软件开发
客户评估──评价开发工作，提出修正建议

螺旋模型适合于大型软件的开发;然而风险分析需要相当丰富的评估经验，风险的规避又需要深厚的专业知识，这给螺旋模型的应用增加了难度。

2.3.7. 喷泉模型(迭代模型)

喷泉模型认为软件开发过程具有两个固有的本质特征：
迭代：多次重复、演进。
无间隙：各阶段间无明显的界限。支持分析和设计结果的自然复用。

适用：面向对象的软件开发过程。对象概念的引入，对象及对象关系在分析、设计和实现阶段的表达方式的统一，使得开发活动之间的迭代和无间隙性能够容易地实现。

2.3.9. 快速应用开发(RAD)模型

快速应用开发(Rapid Application Development，RAD)是一个增量型的软件开发过程模型，采用构件组装方法进行快速开发。

RAD模型包含如下阶段：
(1)业务建模：通过捕获业务过程中信息流的流动及处理情况描述业务处理系统应该完成的功能。回答以什么信息驱动业务过程运作要生成什么信息谁生成它信息流的去向由谁处理可以辅之以数据流图。
(2)数据建模：对于支持业务过程的数据流，建立数据对象集合,定义数据对象属性,与其它数据对象的关系构成数据模型，可辅之以E-R图。
(3)过程建模：定义如何使数据对象在信息流中完成各业务功能。描述数据对象的增加、修改、删除、查找。即细化数据流图中的处理框。
(4)应用生成：利用第四代语言(4GL)写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具，自动生成，构造出整个的应用系统。
(5)测试及迭代：由于大量重用，一般只作总体测试，但新创建的构件还是要测试的。当一轮需求完成快速开发后，可以迭代进入下一轮需求的开发。

阶段目标：通过业务用例（Business Use Case）了解业务并确定项目的边界，包括项目的验收规范、风险评估、所需资源估计、阶段计划等。

要确定项目边界，需识别所有与系统交互的外部实体，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。

Milestone：软件目标里程碑。包括一些重要的文档，如项目愿景（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务场景等。

需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。

2 – 细化阶段

阶段目标：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。

Milestone：体系结构里程碑。包括风险分析文档、软件体系结构基线(baseline)、项目计划、可执行的进化原型、初始版本的用户手册等。

通过评审确定软件体系结构的稳定性、确认高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

3 – 构造阶段

阶段目标：将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。

Milestone：运行能力里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。

要确定软件、环境、用户是否可以开始系统的运行。

4 – 移交阶段

阶段目标：软件产品正常运行并交付用户使用。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。

Milestone：产品发布里程碑。包括维护和售后支持文档手册等。

要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。

(2) RUP的迭代增量开发思想
RUP是以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型

RUP的每一个阶段可以进一步划分为一个或多个迭代过程，从一个迭代过程到另一个迭代过程增量形成最终的系统。
RUP是融合了喷泉模型和增量模型的一种综合生命周期模型。

RUP将整个项目的开发目标划分成一些更易于完成和达到的阶段性小目标。每一次迭代就是为了完成一定阶段性小目标而从事的一系列开发活动，包含需求、设计、实施（编码）、部署、测试等。

XP的工作环境
每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。
用户也是项目组的一部分。
所有人都在同一个开放的开发环境中工作。

XP的需求分析

开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story）；
这些模块又会根据实际情况被组合在一起或者被分解成更小的模块，且它们都被记录在一些小卡片（Story Card）上；
客户根据每个模块的商业价值来指定它们的优先级；
然后，开发人员确定每个需求模块的开发风险；
经过开发人员和客户的评估后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；
客户为每个需求模块指定验收测试（功能测试）。

XP的设计
从开发的角度来看，XP内层的过程是一个基于Test Driven Development周期，每个开发周期都有很多相应的单元测试。
随着这些测试的进行，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。

同时，XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；

XP的编程
XP提倡配对编程（Pair Programming），而且代码所有权是归于整个开发队伍（Collective Code Ownership）。
程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。
任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。

XP的测试
XP提倡在开始写程序之前先写单元测试。

开发人员应该经常把开发好的模块整合到一起（Continuous Integration，持续集成），每次整合后都要运行单元测试；
做任何的代码复核和修改，都要运行单元测试；
发现了BUG，就要增加相应的测试。
除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。
所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

三、软件需求分析

3.1 系统分析

1. 系统分析
系统分析是一组统称为计算机系统工程的活动。它着眼于所有的系统元素，而不仅仅是软件。
系统分析主要探索软件项目的目标、市场预期、主要的技术指标等，用于帮助决策者做出是否进行软件项目立项的决定。

4.4 软件需求分析建模的原则和方法

分析建模的操作性原则：

问题的信息域必须被表示和理解。(数据模型)
软件将完成的功能必须被定义。(功能模型)
软件的行为(作为外部事件的结果)必须被表示。 (行为模型)

数据模型
问题的信息域包含三个不同的数据和控制视图：
（1）信息内容和关系
信息内容表示了个体数据和控制对象，它们可和其他的数据和控制对象关联。
（2）信息流
信息流表示了数据和控制在系统中流动时变化的方式。
（3）信息结构
信息结构表示了各种数据和控制项的内部组织。
功能模型
对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出。功能模型从顶层的语境层模型开始，经过一系列的细化迭代，越来越多的功能细节被发现，直至得到所有系统功能。
行为模型
大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。

需求分析的工程化原则：

首先要正确地理解问题，再建立分析模型。
记录每个需求的起源及原因，保证需求的可回溯性。
开发一个人机交互过程的原型。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

软件工程知识点总结