🌈个人主页： 十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客
💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
[1. 前言](#1. 前言)
[2. 章节简介](#2. 章节简介)
[3. 软件工程概述](#3. 软件工程概述)
[3.1 认识软件工程](#3.1 认识软件工程)
[3.1.1 软件工程是什么](#3.1.1 软件工程是什么)
[3.1.2 软件工程师是什么](#3.1.2 软件工程师是什么)
[3.2 软件工程的前世今生](#3.2 软件工程的前世今生)
[3.2.1 软件发展中出现的问题](#3.2.1 软件发展中出现的问题)
[3.2.2 软件工程中的核心方法](#3.2.2 软件工程中的核心方法)
[3.2.2.1 软件开发标准](#3.2.2.1 软件开发标准)
[3.2.2.2 软件开发中的方法](#3.2.2.2 软件开发中的方法)
[3.2.2.2.1 问题分析方法](#3.2.2.2.1 问题分析方法)
[3.2.2.2.2 系统化方法](#3.2.2.2.2 系统化方法)
[3.2.2.2.3 工程化方法](#3.2.2.2.3 工程化方法)
[3.3 软件工程的未来](#3.3 软件工程的未来)
[3.3.1 变化的本质](#3.3.1 变化的本质)
[3.3.2 软件工程的 Wasserman 规范（或基本概念）](#3.3.2 软件工程的 Wasserman 规范（或基本概念）)
[4. 典型例题 编辑](#4. 典型例题 编辑)
[5. 总结](#5. 总结)
1. 前言
今天是软件工程课程考试前两周，趁着软件工程考试，猫猫来进一步梳理软件工程这门课程的知识，希望也能给阅读本系列文章的友友们提供一些帮助。
本系列分为两个部分：
- 全面知识梳理
- 特别知识梳理
（全面知识梳理一律加上【第*章】字样，是软件工程所有知识的全面梳理）
（特别知识梳理一律加上 【一篇搞定】字样，仅仅作为特别重要内容的展开延申）
2. 章节简介
这一章介绍软件工程的发展历程，其所使用的技术及工具；如何分析问题以及寻求解决方案；软件开发人员们取得的进展以及需要努力的方向；软件开发的涉及人员及 Wasserman规范将实践融为一体的八个概念。
一句话记忆：
认识软件工程，了解软件工程的前世今生，探讨软件工程的未来（和谈恋爱一样流程）
3. 软件工程概述
3.1 认识软件工程
3.1.1 软件工程是什么
软件工程（SE）的定义、方法、作用：
- SE的定义：软件工程就是用系统化、工程化的方法解决软件开发问题。系统化、工程化方法结果就是"软件开发规范"，规范里面体现软件开发的固有规律。
- SE 的方法：面向对象模式，结构化模式，基于过程的模式等。
- SE 的作用：付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，开发的软件易于移植，需要较低的维护费用，能按时完成开发工作，及时交付使用。
3.1.2 软件工程师是什么
以计算机科学理论和计算机功能为基础，通过对要解决问题的本质的了解，基于软件工程技术设计方案，推出高质量的软件产品。
（将计算机作为问题求解的工具，将软件工程知识作为问题求解的工具）
3.2 软件工程的前世今生
软件工程的前世------软件发展中出现的问题
软件工程的今生------软件发展中的核心方法
3.2.1 软件发展中出现的问题
1、零缺陷软件无法出现
由于市场压力促使软件开发人员快速交付产品，零故障软件无法实现。
2、故障，错误和失效各自的含义（含举例）及它们之间的联系：
- 错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。
- 故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。
- 失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。
联系：
- 人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。
- 故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。
3、关于 bug
- 改正(fixing)有时比重写(rewriting)整个系统要困难。
- 错误修正的越晚，付出的代价越大。
- 复审(review)十分重要，是正式团队的行为规范；自己检查能只能找出开发阶段故障的 1/5，同行评审能够揭示其余 4/5 的故障。
3.2.2 软件工程中的核心方法
因为软件工程中出现前面的问题------零缺陷软件很难出现，存在错误、故障、失效问题。
在软件工程中，工程师提出了许许多多 方法与标准 希望可以提高软件质量
3.2.2.1 软件开发标准
从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
产品(product)质量：
用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。
过程(process)质量：
有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。几个量化模型：CMM、ISO 9000、SPICE（了解）
商业（business）环境背景下质量：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
商业环境背景下质量=商业价值+技术价值
3.2.2.2 软件开发中的方法
3.2.2.2.1 问题分析方法
- 分析(analysis)：将问题分解成可以理解并能够处理的若干小部分，确定问题的本质含义。
- 合成(synthesis)：将每个小问题的解决方案组合成一个大的结构，合成解决方案。工具(tool)：用更好的方式完成某事情的设备或自动化系统。
- 过程(produce)：把工具和技术结合起来，共同生产特定产品。
- 范型(paradigm)：构造软件的特定方法、途径或哲学（如面向对象开发的模式、结构化开发的模式、基于过程开发的模式、某种订制开发的模式）。
3.2.2.2.2 系统化方法
把软件看作一个系统，系统由四大要素组成：实体、活动、关系、系统边界的集合。
(1) 活动和对象
活动(activity)：活动是发生在系统中的某些事情，通常描述为由某个触发器引发的事件，活动通过改变某一特性把一个事物转变成另一个事物。
对象(object)或实体(entity)：活动中涉及的元素称为对象或实体（如记录数据的对象）。
(2) 关系和系统边界
关系(relationship)：对实体和活动间数据项及动作相互关系的描述。
系统边界(system boundary)：用于描述系统中包含什么，不包含什么。
活动、关系是核心。
为什么要刻画系统边界？
几乎不存在与其他系统没有关联的系统，因此刻画系统边界十分重要，很容易了解什么在系统内部、什么不在以及什么超出了边界。系统可能存在于另一个系统中。
边界定义的详细正确，那么根据较小的部分构建较大的系统是相对容易的。开发可以由内而外,但设计最好得由大到小, 这就带来了难度。
（关键点） 增量式开发方法：
包含一系列阶段，其中每一个阶段都使前面的系统不受当前系统约束的限制（前面系统不会因为当前系统而无法通过测试）。系统逐渐地从旧的软件和硬件中脱离开，直到它体现出新系统的设计。
增量是逐块建造的概念，例如：画一幅人物画，我们可以先画人的头部，再画身体，再画手脚......。
3.2.2.2.3 工程化方法
以工程化方法进行软件开发---------将软件开发过程工程化。以固定的阶段、流程进行软件开发。
（1）需求分析：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。
（2）系统设计：包括用户界面的设计【《SAD》即《软件系统结构图》：如何制作软件】与复审（开发者与客户）。
（3）程序设计：包括模块功能算法与数据描述设计【相关文档】与复审（开发者）。（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。
（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。
（7）系统测试：按《SRS》对系统总体功能进行测试与复审（开发者与客户）。（8）系统提交：交付产品【用户手册和操作手册】与复审。
（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。
注：圆括号中的为测试人员，方括号为生成的文档。
额外说明（了解）：以上阶段只是大致的划分，软件团队实际执行时比这要复杂，还有若干辅助性过程和阶段，而有些阶段实际是相互重叠、相互影响的。
3.3 软件工程的未来
软件开发过程也不是一成不变，而是随时间发生变化的。
3.3.1 变化的本质
早期程序： 线性输入，输出为字母数字，系统设计方式分为两种：转换(transformation)：将输入转换为输出；事务(transaction)：由输入决定哪个功能将被执行。因此瀑布模型开发方式可行。
**当今程序：**多系统运行，跨平台运行，基础功能：网络控制，安全性，用户界面表示和处理，以及数据或对象管理等。相较于早期变化巨大，瀑布模型不适用。
（关键点） 使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
**总结：**时间、技术成本、互联网、面向对象技术、图形化用户界面、瀑布模型的缺点
说明（了解） ：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
3.3.2 软件工程的 Wasserman 规范（或基本概念）
基于前面提到的软件工程出现的变化，以及软件工程的未来，Wasserman 提出了软件工程的几个规范。希望未来的软件工程技术能够按照这几个概念所规范的去发展。
(1) 抽象(abstraction)： 基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构： 定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。
（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。
（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程： 软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。
(6) 重用或复用(reuse)： 重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)： 通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境： 通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。
问题与规范：
1、时间紧迫性------》重用+工具和集成环境+软件体系结构+抽象
2、硬件成本低，人工成本高------》用户原型界面
3、提高软件质量：分析和设计方法以及符号描述系统+软件过程+测度和度量
八个规范本质是：开发软件整个过程中的流程拿到问题------抽象------给出分析和设计方法并给出符号描述系统去描述问题------利用 软件过程去进一步分析开发------ 进行软件代码编写，软件体系结构去分解代码------利用重用和复用去提高代码编写效率------给出用户界面原始模型------测试代码------整个过程需要工具和集成环境
4. 典型例题 
5. 总结
以上便是软件工程------第一章·软件工程概论部分的全部内容
如果觉得对你有帮助，麻烦点个赞啦~~~
