软件工程导论复习整理
- 软件工程导论复习整理（第一、二、三章）
-
- 第一章 软件工程学概述
-
- 1.1 软件危机
- 1.2软件工程
- 第二章 可行性研究
-
- 2.1可行性研究的任务
- 2.2可行性研究过程
- 2.3系统流程图
- 2.4数据流图
- 2.5数据字典
- 2.6成本/效益分析
- 第三章 需求分析
-
- 3.1需求分析的任务
-
- 3.1.1 确定对系统的综合要求
- 3.1.2 分析系统的数据要求
- 3.1.3 导出系统的逻辑模型
- 3.1.4 修改系统开发计划
- 3.2 与用户沟通获取需求的方法
- 3.3分析建模与规格说明
软件工程导论复习整理（第一、二、三章）
第一章 软件工程学概述
1.1 软件危机
1、软件危机：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2、软件危机的典型表现：
（1）对软件开发成本和进度的估计常常很不准确。
（2）用户对“已完成的”软件系统不满意的现象经常发生。
（3）软件产品的质量往往靠不住。
（4）软件常常是不可维护的。
（5）软件通常没有适当的文档资料。
（6）软件成本在计算机系统总成本中所占的比例逐年上升。
（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
3、产生软件危机的原因：
(1) 软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。
(2) 软件开发的过程是多人分工合作，分阶段完成的过程，参与人员之间的沟通和配合十分重要。
(3) 开发和管理人员只重视开发而轻视问题的定义，使软件产品无法满足用户的要求。
(4) 软件管理技术不能满足现代软件开发的需要，没有统一的软件质量管理规范。
(5) 在软件的开发和维护关系问题上存在错误的观念。
为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。软件工程正是从__管理和技术__两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
1.2软件工程
1、软件工程（概念）：软件工程是指导计算机软件开发和维护的一门学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效的维护它。
2、软件工程的7条基本原理
（1）用分阶段的生命周期计划严格管理
（2）坚持进行阶段评审
（3）实行严格的产品控制
（4）采用现在程序设计技术
（5）结果应能清楚地审查
（6）开发小组的人员应该少而精
（7）承认不断改进软件工程实践的必要性
软件是程序、数据、相关文档的完整集合。
软件工程方法学包含3个要素：方法、工具和过程。
软件工程方法学：
1.传统方法学(数据流方法学或结构化范型)——强调自顶向下
SA->SD->SP
2.面向对象方法学——强调主动地多次反复迭代
OOA->OOD->OOP->OOT
3、软件生命周期
三个时期八个阶段：软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成若干个阶段。 （明确每个阶段的任务）
4、维护阶段的关键任务：通过各种必要的维护活动使系统持久的满足用户的需要。
4类维护活动：1.改正性维护 2.适应性维护 3.完善性维护 4.预防性维护
软件过程（P15）
| 模型名称 | 优点 | 缺点 | 使用范围 |
|---|---|---|---|
| 瀑布模型（文档驱动） | 可强迫开发人员采用规范的方法；严格规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证 | 缺乏灵活性、失败率高 | 适用于需求明确/需求冻结的软件开发、文档驱动 |
| 快速原型模型（用户驱动） | 减少由于软件需求不明确带来的开发风险；软件开发成本较低；快速； | 所选的开发技术和工具不一定符合主流的发展，快速建立的系统结构加上连续的修改可能会导致产品质量低下 | 适用于需求不明确的软件开发、需求驱动 |
| 增量模型（构建驱动） | 能在较短时间内向用户提交可完成部分工作的作品；每次只提交部分功能，使用户有较充足的时间学习和适应新产品，减少给用户带来的冲击；提高系统可维护性，当需求变更时只变更部分部件，不必影响整个系统 | 在把每个新的增量构件集成到现有的软件体系中时，要求必须不破坏原来已经开发出的产品；软件体系结构必须是开放的 | 适用于团队小、用户希望较早开始使用的情况、设计方案有一定风险的软件项目 |
| 螺旋模型（风险驱动） | 引入了风险分析；设计灵活，可以在项目各个阶段变更；成本计算容易；保证了项目的可控性 | 建设周期长，很容易引起软件开发完毕后和当前的技术水平差距大，无法满足当前用户需求 | 适用于内部开发的大规模软件项目、风险驱动 |
| 喷泉模型（对象驱动） | 各个阶段没有明显界限，开发人员可以同步进行开发；提高软件项目开发效率；节省开发时间 | 各个开发阶段是重叠的，所以对开发人员需求大，不利于项目管理 | 适用于面向对象的软件开发、对象驱动 |
| V模型（测试驱动） | 整个开发过程中贯穿测试；能尽早发现缺陷进行修复；测试与开发独立起来，并与开发并行 | 由于需求变量较大，导致要重复变更需求、设计、编码、测试，返工量大 | 测试驱动 |
5、RUP统一过程（重点）
6、极限编程的四个价值观：
（1）个体和交互胜过过程和工具；
（2）可以工作的软件胜过面面俱到的文档；
（3）客户合作胜过合同谈判；
（4）响应变化胜过遵循计划。
第二章 可行性研究
2.1可行性研究的任务
1、可行性研究的目标：用最小的代价在尽可能短的时间内确定问题是否能够解决。
2、可行性研究的方面：技术可行性，经济可行性，操作可行性，社会因素可行性。
2.2可行性研究过程
1.复查系统规模和目标
2.研究目前正在使用的系统
3.导出新系统的高层逻辑模型
4.进一步定义问题
5.导出和评价供选择的解法
6.推荐行动方针
7.草拟开发计划
8.书写文档提交审查
2.3系统流程图
系统流程图：是概括地描绘物理系统的传统工具。表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
2.4数据流图
（1）基本符号：
数据存储：数据存储是处于静止状态的数据； 数据流：数据流是处于运动中的数据。
数据流图所描述的是实际系统的逻辑关系。
（2）附加符号： 星号（*）：表示“与”关系；
加号（+）：表示“或”关系；
异或（⊕）：表示互斥关系。
（3）原则：
① 数据流一定和加工有关
② 数据守恒和数据封闭（黑洞、灰洞和奇迹）
③ 子图和父图的平衡（父图的加工可分解）
④ 合理使用存储
⑤ 加工分解的原则：自然性；均匀性；分解度不超过7个。
2.5数据字典
数据字典
（1）定义：关于数据的信息集合，也就是对数据流图中包含的所有元素的定义集合。
数据流图和数据字典共同构成系统的逻辑模型。
（2）数据字典的组成：数据流；数据流分量(即数据元素)；数据存储；处理。
2.6成本/效益分析
每行代码的平均成本主要取决于软件的复杂程度和工资水平。
P50页 表2.2
第三章 需求分析
需求分析是软件定义时期的最后一个阶段。
①它的基本任务是准确地回答“系统必须做什么”这个问题
②对目标系统提出完整、准确、清晰、具体的要求
③系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。
3.1需求分析的任务
3.1.1 确定对系统的综合要求
1.功能需求 要求收集、整理分析需求、生成需求规格说明书
2.性能需求 性能点列表
3.可靠性和可用性需求
4.出错处理需求
5.接口需求 接口列表
6.约束
7.逆向需求
8.将来可能提出的要求
3.1.2 分析系统的数据要求
常用的图形工具有层次方框图和Warnier
3.1.3 导出系统的逻辑模型
通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
3.1.4 修改系统开发计划
3.2 与用户沟通获取需求的方法
1.访谈
2.面向数据流自顶向下求精
3.简易的应用规格说明技术
4.快速建立软件原型
3.3分析建模与规格说明
1、分析建模
（1）数据模型：E-R图；
功能模型：数据流图；
行为模型：状态转换图；数据字典。
（2）DFD和E-R描述了系统的静态方面的信息，STD（状态转换图）描述了系统行为方面的信息。
（3）数据字典是分析模型的核心；实体-联系图用于建立数据模型的图形；数据流图是建立功能模型的基础；状态转换图是行为建模的基础 。
2、分析系统的数据要求
建立数据模型——ER图 描绘数据结构——层次方框图和Warnier图 数据结构规范化
3、其他图形工具（了解）
层次方框图
IPO图（输入、处理、输出图）
4、验证软件需求
一致性：需求必须是一致的，任何一条需求不能和其他需求互相矛盾
完整性：需求必须是完整的
现实性：需求应该是现有的硬件技术和软件技术基本可以实现的
有效性：必须证明需求是正确有效的
