课程
01-software-engineering-overview
软件与软件危机
软件: ![[assets/Pasted image 20260109212802.png|600]]
特点:
- 软件本身的复杂性
- 软件的成本高昂
- 软件开发未摆脱手工开发方式
- 软件维护与硬件有本质差,维护难度高
- 软件开发不是传统硬件制造过程
- 软件是一种逻辑实体,无磨损性
软件危机:在计算机软件 开发 和 维护 过程中所遇到的一系列严重问题
- 如何开发软件
- 如何维护软件
软件危机的表现:
- 计划不准确
- 用户不满意
- 质量不可靠
- 系统难维护
- 文档不适合
- 成本上升
- 开发效率低
消除软件危机的方法:
- 对计算机软件有正确的认识
- 积累有效的原理、概念、技术和方法
- 积极开发和使用计算机辅助开发软件
- 探索更好的管理措施对开发过程进行管控
判断题:
- 开发软件就是编写程序。(×)
- 软件是指使用程序设计语言(如PASCAL、C等)编写的程序,软件开发实际上就是编写程序代码。(×)
- 软件的开发与运行经常受到硬件的限制于约束。(√)
- 软件危机完全是由硬件引起的问题。(×)
选择题:
- 软件是一种()实体,具有抽象性
- A 有形
- ==B 逻辑==
- C 物理
- D 消耗
- 开发软件所需高成本和产品的低质量之间有着尖锐的矛盾,这种现象叫做()
- A 软件工程
- B 软件周期
- ==C 软件危机==
- D 软件产生
- 产生软件危机的原因主要与两个方面的问题有关()
- ==A 软件产品本身的特点,而且在软件的开发和维护过程中用的方法不正确==
- B 软件在计算机中很难识别,存在磁盘中也看不到
- C 软件设计对人的智商要求很高,也要求很高的资金投入
- D 软件很难理解,硬件也很复杂
- 软件危机的主要原因是()
- A 软件工程落后
- B 软件生产能力不足
- C 实行严格的产品控制
- ==D 软件本身的特点及开发方法==
软件工程
软件工程:指导计算机软件开发和维护的工程学科
- 采用工程的概念、原理、技术和方法来维护软件
- 将管理技术与当前经过时间考验的而证明是正确的技术方法结合起来
- 强调使用生存周期方法学和结构化技术
20世纪60年代提出了软件工程的概念
软件工程基本原理:
- 用分阶段的软件生命周期计划进行严格的质量管理
- 坚持进行阶段评测
- 实行严格的产品控制
- 采用现代程序设计技术
- 软件工程结果应能清楚的审查
- 开发小组的人员应该少而精
- 承认不断改进软件工程实践的必要性
软件工程方法学:软件生命周期中使用的一整套技术方法的集合称为软件工程方法学
三要素:
- 方法
- 工具
- 过程
分类:
- 结构方法学(结构化分析SA,结构化设计SD,结构化程序设计SP)
- 采用结构化技术
- 把软件生命周期的全过程依次划分为若干个阶段
- 每一阶段的开始和结束都有严格标准
- 每一阶段结束前需严格审查和复审
- 面向对象方法学(面向对象分析OOA,面向对象设计OOD,面向对象程序设计OOP)
- 用对象分解取代传统方法学的功能分解
- 把所有对象都划分为类
- 按照父类和子类的关系,把若干个相关的类组成一个层级结构的系统
- 对象间仅通过发送消息相互联系
选择题:
- 软件工程的出现主要是由于()
- A 软件设计方法学的影响
- B 其他工程学科的影响
- ==C 软件危机的影响==
- D 计算机的发展
- 软件工程是一门学科,主要关注的是()
- A 硬件和软件的继承
- ==B 软件的开发和维护==
- C 电子产品的生产
- D 网络安全
- 下列哪个不是软件工程方法学中的要素
- A 方法
- B 工具
- ==C 程序==
- D 过程
软件生命周期
定义:软件产品或软件系统从设计、投入使用到被淘汰的全过程
3时期、8阶段 ![[assets/Pasted image 20260109222526.png|600]]
软件定义时期
- 问题定义:弄清楚客户需要解决什么问题
- 可行性研究:确定软件开发的可行性,输出《可行性研究报告》
- 需求分许:明确客户需求,输出标准化《需求规格说明书》
软件开发时期
- 总体设计(概要设计):设计软件结构,确定功能模块以及模块间的关系,输出《总体设计说明书》
- 详细设计:详细设计每个模块,确定所需算法和数据结构,输出《详细设计说明书》
- 编码和单元测试:将详细设计用语言实现,并测试每个模块,输出软件产品
- 综合测试:编写详细测试计划并严格按照计划执行
软件维护时期
- 运行和维护:使软件在整个生命周期内保证满足用户需求
判断题:
- 软件工程采用的生命周期方法就是从时间角度对软件的开发和维护这个复杂问题进行分解,将软件生命周期的时期分为若干个阶段。(√)
- 软件生命周期是从软件开始到开发结束的整个时期。(×)
- 软件生命周期中先进行需求分析,在进行可行性分析。(×)
选择题:
- 下列那个阶段不是属于软件生存周期的三大时期()。
- A 定义阶段
- B 开发阶段
- ==C 编码阶段==
- D 维护阶段
- 软件生存周期包括问题定义、可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、()、维护等活动。
- A 应用
- ==B 测试==
- C 检测
- D 以上都不对
- 软件设计阶段可以分为()设计和()设计阶段。
- A 逻辑
- ==B 详细==
- C 程序
- ==D 概要==
软件开发模型
软件过程:在整个软件生命周期的系统开发、运行和维护过程所实施的全部过程、活动和任务的结构框架。通常采用软件过程模型来描述软件过程。
软件过程模型:
- 传统软件过程模型:
- 瀑布模型(线性顺序模型)
- 快速原型模型
- 增量模型
- 螺旋模型
- 喷泉模型
- 现代软件过程模型:
- Rational统一过程模型(UML)
- 敏捷软件开发
- 基于构件的开发模型
| 开发模型 | 特点 | 应用场合 |
|---|---|---|
| 瀑布模型 | 线性模型,每一阶段必须完成规定的文档 | 需求明确的中小型软件开发 |
| 快速原型模型 | 用户介入过早,通过迭代完成用户需求,应用快速开发工具 | 需求模糊的小型软件开发 |
| 增量模型 | 每次迭代完成一个增量,可用于00开发 | 容易分块的大型软件开发 |
| 螺旋模型 | 典型迭代模型,重视风险分析,可用于00开发,强调版本与风险驱动 | 具有不确定性的大型软件开发 |
| 喷泉模型 | 典型的00过程模型,体现迭代和无缝的特性 | 需求明确的中小型软件开发 |
00开发即面向对象开发
瀑布模型
将软件生命周期的各项活动规定为按固定顺序而连接的若干工作阶段,形如瀑布流水,最终得到的软件产品。
以文档为驱动、适用于软件需求确定的软件项目的开发。
软件开发过程与软件生命周期基本一致,也成为经典生命周期模型
- 定义时期
- 可行性研究
- 需求分析
- 开发时期
- 总体设计
- 详细设计
- 编码和单元测试
- 系统测试
- 验收测试
- 维护时期
- 运行与维护
特点:
- 阶段间具有顺序性与依赖性,自上而下,相互衔接,前阶段的输出文本是后一阶段的输入文本
- 推迟实现的观点:编码前的分析和设计各个阶段主要考虑逻辑模型不涉及具体实现
- 质量保证的观点:每个阶段必须完成规定的文档,每个阶段结束都要对所完成的文档进行评审,发现问题,保证质量
优点:
- 强迫开发人员使用规范化的方法
- 严格要求每个阶段必须提交文档
- 要求每个阶段交出的所有产品都必须是经过验证的
缺点:
- 仅通过静态规格说明,无法及时验证需求是否正确、完整
- 几乎完全依赖说明,很容易导致软件产品不能真正满足用户需求
- 不支持产品演化,缺乏灵活性,使软件产品难以维护
快速原型模型
快速构建起可运行的程序,它完成的功能往往是最终产品功能的一个子集 ![[assets/Pasted image 20260110173723.png|250]] 优点:
- 开发的软件产品通常满足用户需求
- 软件产品开发基本上是线性过程
缺点:
- 准确原型设计困难
- 原型理解可能不同
- 不利于开发人员创新
增量模型
先完成一个系统子集的开发,再按同样的开发步骤增加功能(系统子集),如此递增直到完成全部系统需求。 ![[assets/Pasted image 20260110174037.png|400]]
优点:
- 短时间内可提交完成部分功能
- 逐渐增加产品功能,用户适应性快
缺点:
- 增量构件划分以及集成困难
- 容易退化为边做边改模型
螺旋模型
在每个阶段之前都增加了风险分析过程的快速原型构建模型 ![[assets/Pasted image 20260110174249.png|400]]
优点:
- 利于把软件质量作为软件开发目标
- 减少测试
- 维护和开发不分开
缺点:
- 风险评估困难
喷泉模型
![[assets/Pasted image 20260110174534.png|250]]
判断题:
- 软件工程中的“瀑布模型”是一种线性和顺序的开发过程,其中各个阶段依次完成。(√)
- 快速原型模型可以有效适应用户需求的动态变化。(√)
选择题:
- 下列选中中,()不是软件过程模型。
- A 螺旋模型
- B 增量模型
- ==C 功能模型==
- D 瀑布模型
- 瀑布模型适用于()的系统。
- A 需求不确定性高的
- ==B 需求确定的==
- C 管理信息
- D 实时
- 瀑布模型存在的问题是()。
- A 用户容易参与开发
- ==B 缺乏灵活性==
- C 用户与开发者易沟通
- D 适用可变需求
- ()引入了“风险驱动”的思想,适用于大规模的内部开发工程。
- A 增量模型
- B 喷泉模型
- C 原型模型
- ==D 螺旋模型==













