软件工程笔记
目录
- 第一章 软件工程概述
- 第二章 可行性研究
- 第三章 需求分析
- 第五章 总体设计
- 第六章 详细设计
- 第七章 实现
- 第八章 软件维护
- 第九章 面向对象方法学
- 第十章 软件项目管理
第一章 软件工程概述
1.1 软件危机
1.1.1软件危机介绍
📌软件危机：
就是计算机软件开发和维护过程中遇到的一系列问题。
主要包括：
- 如何开发
- 如何维护
📌软件危机的典型表现：
- 软件开发的成本和进度估计往往不正确
- 用户对已完成的软件产品不满意
- 软件的质量不可靠
- 软件不可维护
- 没有合适的文档
- 软件的成本占整个计算机系统的成本的比例逐年增加
- 软件开发的效率赶不上计算机应用普及的速度
1.1.2产生软件危机的原因
📌软件本身的特点
- 软件是逻辑产品不是物理部件。
- 软件规模庞大，程序复杂性随着规模的增长成指数上升。
📌开发和维护软件的方法不正确
- 对软件开发和维护有很多错误观念
- 对用户需求没有完整准确的认识就着手编写代码
- 轻视软件维护
- 只重视程序而忽视软件配置其余成分
- 软件开发在不同的阶段进行修改需要付出的代价不同
- 软件从定义，开发，使用和维护，直到最终被废弃，要经历漫长的时期
1.1.3消除软件危机的途径
📌彻底消除软件就是程序的错误观念。
📌组织管理各类人员协同配合，共同完成。
📌使用在实践中总结出来的开发软件的成功的技术和方法。
📌开发和使用更好的软件工具。
1.2 软件工程
1.2.1软件工程概念
📌软件工程概念：
软件工程是使用工程的原理，概念，方法和技术开发和维护软件，把经过时间证明的正确的管理方法以及目前能够得到的最先进的技术，经济的开发和维护软件产品的工程学科
软件工程本质特征：
- 软件工程关注大型程序的构造。
- 软件工程的中心课题是控制复杂性。
- 软件经常变化。
- 开发软件的效率非常重要。
- 和谐的合作是开发软件的关键。
- 软件必须有效的支持他的用户。
- 在软件工程中通常由一种文化背景的人为另一种文化背景的人创造产品。
1.2.2软件工程基本原理
📌软件工程基本原理：
- 用分阶段的生命周期计划严格管理。
- 坚持阶段评审。
- 实行严格的产品控制。
- 采用现代程序设计技术。
- 结果应能清楚的审查。
- 开发小组人员应该少而精。
- 承认不断改进软件工程实践的必要性
1.2.3软件工程方法学
📌软件工程方法学概念：
软件工程方法学就是软件生命周期过程中使用到的一系列方法和技术的集合
三要素：方法，过程和工具
分为：传统方法学（结构化泛型）和面向对象方法学
📌软件过程：是为了获得高质量产品进行的一系列任务的框架
{软件过程是软件工程方法学的一个重要的要素}
📌1.传统方法学
定义：
采用结构化技术（结构化分析，结构化设计，结构化实现）来完成软件开发的各项任务，并使用适当的软件工具和软件过程环境支持结构化技术的运用。
优点：
- 把软件生命周期划分成若干个阶段，每个阶段的任务相互独立，而且简单，有利于不同人员协作开发
- 在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，且在每个阶段结束之前都进行严格的审查，保证了软件的质量，提高了软件的可维护性
- 采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能得到提高
📌2.面向对象方法学
把数据和行为看成同等重要，以数据为主线，把数据和操作紧密结合起来的方法。
要点：
- 把对象作为融合了数据及在数据上的操作行为的统一软件构件。
- 把所有对象划分成类。
- 继承性，多态性，封装性。
- 对象间仅能通过消息互相通信。
优点：
- 降低了软件产品的复杂性。
- 提高了软件的可理解性。
- 简化了软件的开发和维护工作
- 提高了软件的可重用性。
1.3软件生命周期
1.3.1软件生命周期定义
📌 定义：
软件生命周期是指一个软件从提出，定义，开发和维护到最后淘汰经历的漫长时期
1.3.2软件生命周期划分
软件生命周期划分为：
- 软件定义
- 问题定义 （确定系统要解决的问题）
- 可行性研究 （对于定义的问题确定是否有行得通的解或值得解）
- 需求分析 （确定系统应该具备哪些功能,编写需求规格说明书SRS）
- 软件开发
- 总体设计 （应该怎样实现系统，设计系统的体系结构，确定程序由哪些模块组成，以及模块间的关系
- 详细设计 （详细设计每个模块，确定模块功能和数据结构）
- 编码和单元测试
- 综合测试
- 软件维护 （通过各种必要的维护活动使系统持久的满足用户的需要）
📌改正性维护 （软件交付使用后，修改和改正软件运行过程中发现的错误的过程）
📌完善性维护（为了满足用户对系统提出的新的功能和性能的要求，扩充和完善软件功能的过程）
📌适应性维护 （为了适应软件运行环境变化修改软件的过程）
📌预防性维护（为了提高软件将来的可维护性，可靠性或者为了给未来的改进奠定良好的基础而修改软件的过程）
1.3.3软件生命周期模型
-
瀑布模型
瀑布模型是应用得最早，也是最广泛的生命周期模型。
定义：
传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。
特点：
-
阶段间具有顺序性和依赖性
① 必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
② 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
-
推迟实现的观点
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。
-
质量保证的观点
（1） 每个阶段都必须完成规定的文档。
（2） 每个阶段结束前都要对所完成的文档进行评审。
实际的瀑布模型是带“反馈环”的，如图1.3所示。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务
📌优点：
- 迫使开发人员采用规范的方法；
- 严格的规定每个阶段都要提交文档；
- 要求每个阶段交出的所有产品都必须要经过质量小组的仔细验证；
- 对文档的约束，使软件维护变得容易一些，且能降低软件预算
📌缺点： - 难以适应需求不确定或者经常变化的项目，缺乏灵活性。
- 开发过程末期见到成果，风险大；
- 开发早期存在的问题往往要到交付使用时才发现，维护代价大。
-
-
快速原型模型
- 快速建立起来的可以在计算机上运行的程序，完成的功能少于最终产品的。
- 不带反馈环，软件开发基本是线性顺序进行的。（原因有二：原型系统已经通过与用户交互而得到验证，不会进行较大的返工；建立原型系统已经学到了许多东西，发生错误的可能性小。）
- 适合于一些需求可变、模糊不定的软件系统开发。
[外链图片转存失败,源
最低0.47元/天 解锁文章
扫一扫
1837
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
