软件工程导论笔记(同步更新)（已结束更新）

1.1软件危机

软件危机：软件开发和维护中遇到的一系列严重问题。
软件危机的典型表现：

1. 软件开发的成本和进度常估计不准确
2. 用户经常不满意已完成的软件
3. 软件产品的质量常靠不住
4. 软件常不可维护
5. 没有文档
6. 软件成本在计算机系统总成本中所占的比例逐年上升
7. 软件开发生产效率提高的速度，跟不上计算机应用迅速普及深入的趋势。

软件危机产生的原因：
与软件本身特点有关

1. 软件不同于硬件，管理和控制软件开发过程相当困难。
2. 软件在运行过程中不会因为使用过长而被“用坏”。如果运行中发现了错误，很可能是遇到了一个在开发时期引入的、在测试阶段没能检测出来的错误。
3. 软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
4. 事实上，对用户要求没有准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。
5. 目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念。在实践过程中或多或上地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
6. 错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。
   软件开发与维护的方法不正确有关
7. 只重视程序而忽视软件配置其余成分的糊涂观念。
8. 软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完成符合用户的需要。
9. 严重的问题是在软件开发的不同阶段进行修改需要付出的代价是很不相同的。

1.2软件工程

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件三要素：程序加数据，文档
软件工程三要素：方法，工具，过程，

1.4软件过程

模型示意图要会画

1.4.1瀑布模型

传统瀑布模型：需求分析->规格说明->设计->编码->测试->维护
特点
a.阶段间具有顺序性和依赖性
b.推迟实现：编码在步骤的后面
c.质量保证：每个阶段都要完成文档，每个阶段结束前都要对文档进行评审
实际瀑布模型：在后面阶段发现前面阶段的错误时，需要返回前面的阶段

优点：简单，容易使用，强迫开发人员采用规范的方法，提交的文档，验证
缺点：开发周期长
适用场合：需求明确，大家都做过很多遍，用户参与不多，比如编译器，系统。

1.4.2快速原型模型

为了解决过晚用户看到原型
在计算机快速建立一个可以运行的程序
阶段：快速原型-规格说明-设计-编码-综合测试-维护

与瀑布模型不同的是，最先做一个原型
优点：简单易用，少返工
工具：HTML，python，鲁比
适用场合：没做过这个项目，需求不明确，用户参与多

1.4.3增量模型

为了缩短瀑布模型开发周期，出现了渐增模型，分成了很多模块
每次只开发软件的一部分
过程：需求分析->规格说明->概要设计->对构件设计，编码，集成，测试
优点：避免一次性投入过大
适用：前期对用户把握不准，市场风险较大，期限要求比较严格，先开发一两个构件，发布一些简单的功能试水，例如：微信

风险更大的增量模型：

1.4.4螺旋模型

为了体改软件的质量
在快速原型的基础上每步骤都加了风险分析

1.4.5喷泉模型

为了解决瀑布模型交付时间过长的问题
与增量模型不同，它是每次都开发完整，但质量不高，通过迭代逐步完善。
是一个典型的循环迭代的过程。
迭代

1.4.6Rational统一过程（RUP）

RUP是由Ration公司推出的一种完整的软件过程

RUP总结了6条最有效的开发经验：
迭代式开发，管理需求，使用基于构件的体系结构，可视化建模，验证软件质量，控制软件变更

RUP开发周期：
RUP软件开发生命周期：
迭代四项：
初始，精化，构建，移交

1.4.7敏捷过程与极限编程

对传统软件过程反思，不应该过多的关注文档，应该回归软件本身
敏捷宣言：
1.个体和交互胜过过程和工具：个体是关注程序员的能力的提高，交互是合作
2.可以工作的软件胜过面面俱到的文档：没有人是通过看文档学会玩手机的，软件比文档更重要
3.客户合作胜过合同谈判：传统开发中不允许客户更改需求（需求冻结），但现在用户需求总在变化，要适用于时代的变化
4.响应变化胜过遵循计划

极限编程：把好的开发时间用到极致


用户故事是非形式化的。

1.4.8微软过程

就比较瀑布，快速原型法

1.5软件结构图

2.3系统流程图

系统流程图是概括描述物理系统的传统工具，描述数据在系统间流动的过程。
符号：
例子

2.3.3分层

系统很大，有很多系统流程图，可以分层分模块地来描述。用高层次的系统流程图描绘总体概貌（总图），表明关键功能，然后把每个关键功能再扩展详细（子图）。

2.4数据流图

2.4.1符号

基本符号

1. 正方形：数据的源点或终点
2. 圆角矩形：变换数据的处理
3. 开口矩形：数据存储
4. 箭头：数据的流动方向

2.5数据字典

3需求分析

笑死我了，先存图。
需求分析基本任务是准确的回答“系统要做什么”，不是怎么做。
准则

1. 理解并描述问题的信息域，根据这条准则应该建立数据模型。（清楚涉及到哪些数据，没有这个信息系统之前，怎么完成这件事的。）
2. 必须定义软件完成的功能，建立功能模型。
3. 描述作为外部事件结果的软件行为，建立行为模型。（根据一个事件，系统做出什么反应）
4. 对信息、功能、行为的模型进行分解，用层次的方式展示细节。

需求分析最后得到的是数据流图。

3.1需求分析的任务

如何建立需求？

3.1.1确定系统的要求（获取需求）

1. 功能需求
   指定系统必须提供的服务，系统必须完成的所有任务。
2. 性能需求
   指定系统必须满足的定时约束或容量约束，包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的要求。
3. 可靠性和可用性要求
   可靠性：定量的指定系统的可靠性（计算器的准确率是多少，稳定长时间运行）
   可用性：量化了用户可以使用系统的程度（用户容不容易上手）
4. 出错处理需求
   说明系统对环境错误应该怎么响应。比如它接收到从另一个系统发来的违反协议格式的消息，应该做什么。
5. 接口需求
   描述系统与它环境通信的格式，常见的有：用户接口，硬件接口，软件接口，通信接口
6. 约束
   描述设计和实现系统时应遵循的限制条件，比如：精度，工具和语言约束，应该使用的标准，应该使用的硬件平台。
7. 逆向需求
   不应该做什么
8. 潜在需求
   将来可能会提出来的需求

3.1.2分析系统的数据要求（分析）

数据字典：名称 编号 类型
数据结构：用图表示数据字典

3.1.3导出系统的逻辑模型（定义、建模）

导出详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型

3.1.4验证