本文介绍了软件工程的基础概念，包括软件的定义及其特性、软件危机的原因与启示，以及软件工程的目标和原则等内容。此外，还详细阐述了软件生命周期、常见的软件过程模型、需求分析方法等关键知识点。
目录
第一章 软件工程概述
1.1软件
软件是计算机中与硬件相互依存的另一部分，软件包括程序、数据及相关文档的完整集合。
软件的特点：逻辑实体、生产与硬件不同、不会磨损和老化、依赖硬件、手工开发为主、成本高，风险高、涉及社会因素
1.2软件危机
1.2.1软件危机的表现与原因
表现：在软件开发的过程中，会经常出现一些不能按时完成任务、产品质量得不到保证、工作效率低下和开发经费严重超支等现象。计算机软件的开发、维护和应用过程中普遍出现的这一些严重的问题便是软件危机。
原因：
忽视软件开发前期的调研和需求分析工作
缺乏软件开发的经验和有关软件开发数据的积累，使得开发计划很难制定。
开发过程缺乏统一的、规范化的方法论指导
忽视与用户、开发组成员间的及时有效的沟通
文档资料不规范不准确。导致开发者失去工作的基础，管理者失去管理的依据。
没有完善的质量保证体系
忽视测试的重要性和不重视维护
1.2.2软件危机的启示
软件危机给我们的最大启示，是使我们更加深刻的认识 到软件的特性以及软件产品开发的内在规律。
1.3软件工程
1.3.1软件工程的概念
IEEE对软件工程的定义为：将系统化、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。
软件工程层次图
软件工程以关注质量为目标，方法、工具、过程是软件工程的三要素
1.3.2软件工程研究的内容
软件开发技术：主要研究软件开发的方法、软件开发过程、软件开发工具和环境
软件开发过程管理：主要研究软件工程经济学和软件管理学
1.3.3软件工程目标和原则
目标：
达到要求的软件功能
取得较好的软件性能
开发出高质量的软件
付出较低的开发成本
需要较低的维护费用
能按时完成开发工作
及时交付使用
原则：
用分阶段的生命周期计划进行严格的管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
软件工程结果应该清楚地审查
开发小组的人员应该少而精
承认不断改进软件软件工程实践的必要性
1.3.4软件工程的发展
1.4软件开发方法
常见的软件开发方法包括：
结构化方法
面向数据结构方法
面向对象方法
形式化方法
第二章 软件过程
2.1软件过程概述
软件过程是为了开发出软件产品，或者是为了完成软件工程项目而需要完成的有关软件工程的活动，每一项活动又可以分为一系列的工程任务。
2.2软件生命周期
2.2.1软件生命周期的概念
软件产品的生命周期是指从设计该产品的构想开始，到软件需求 的确定、软件设计、软件实现、产品测试与验收、投入使用以及 产品版本的不断更新，到最终该产品被市场淘汰的全过程。
2.2.2传统软件生命周期的各个阶段
2.3软件过程模型
常见的软件开发模型有很多种，这里主要介绍瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、基于组件的开发模型、统一软件开发过程模型以及敏捷模型与极限编程。
2.3.1瀑布模型
瀑布模型是一种线性的开发模型，具有不可回溯性
优点：过程模型简单
缺点：无法适应变更
瀑布模型适用于具有以下特征的软件开发项目：
软件开发过程中需求不发生变化或很少变化，开发人员可以一次性获取到全部需求。
软件开发人员具有丰富的经验，对软件应用领域很熟悉。
软件项目的风险较低。瀑布模型不具有完善的风险控制机制
2.3.2快速原型模型
快速原型的本质是“快速”
原型系统内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见不断地修改原型。
原型还一个重要的用途是获取用户的需求。
快速原型模型适用于具有以下特征的软件开发项目：
已有产品或产品的原型（样本），只需客户化的工程项目
简单而熟悉的行业或领域
有快速原型开发工具
进行产品移植或升级
2.3.3增量模型
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次的分析、设计、编码和测试这些增量组件。软件开发过程是递增式的过程。
优点：将待开发的软件系统模块化和组件化。可以分批次的提交产品，降低了软件开发的风险。
缺点：要求待开发的软件系统可以被模块化。
增量模型适用于具有以下特征的软件开发项目：
软件产品可以分批次地进行交付
待开发的软件系统能够被模块化
软件开发人员对应用领域不熟悉，难以一次性的进行系统开发
项目管理人员把握全局的水平较高
2.3.4螺旋模型
螺旋模型是一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。
优点：将风险分析扩展到各个阶段中，大幅降低软件开发的风险
缺点：管理和控制较为复杂，可操作性不强，对项目管理人员的要求较高
螺旋模型适用于具有以下特征的软件开发项目：
支持需求不明确、特别是大型软件系统的开发
支持面向过程、面向对象等多种软件开发方法
2.3.5喷泉模型
喷泉模型主要适用于面向对象的软件项目的开发。
各阶段之间没有明显的界限，而且常常重复、迭代地进行。
2.3.6基于组件的开发模型
考虑的焦点是集成，而非是实现。
体现了软件复用的思想，降低了开发成本和风险，并加速了产品开发。
2.3.7统一软件开发过程模型
是一种面向对象软件开发模型，解决了螺旋模型的可操作性问题，采用迭代和增量递进的开发策略，并以用例驱动为特点。
特点：基于迭代地思想、由软件构件构建而成，适用范围极为广泛，但对开发人员的素质要求较高
2.3.8敏捷过程与极限编程（XP）
极限编程是一种实践性较强的规范化的软件开发方法，它强调用户需求和团队合作工作。
第三章 可行性研究及需求分析
3.1可行性研究
3.1.1项目立项概述
项目立项包括项目发起、项目论证、项目审核和项目立项4个过程。
可行性研究不是解决问题，而是确定问题是否值得去解决。
3.1.2可行性研究的内容
战略可行性、操作可行性、计划可行性、技术可行性、社会可行性、市场可行性、经济可行性、风险可行性
3.1.3可行性研究的步骤
明确系统目标、分析研究现行系统、设计新系统的高层逻辑模型、获得并比较可行的方案、撰写可行性研究报告
3.2需求分析
3.2.1需求分析的任务
确定系统的运行环境要求：硬件环境、软件环境
确定系统的功能性需求和非功能性需求
进行有效的需求分析
在需求分析的过程中应遵守一些原则
需求分析的两个任务：建模阶段、描述阶段
需求分析规格说明书
3.2.2需求分析的步骤
需求获取
分析建模
需求描述（编写SRS）
需求验证
3.2.3需求管理
3.2.4需求分析的常用方法
功能分解方法：将一个系统看成是由若干功能模块组成的（自顶向下，逐步求精）
结构化分析方法：逻辑模型由数据流图和数据词典构成并表示，它是一种面向数据流的需求分析方法
信息建模方法：E-R图，其基本要素由实体、属性和关系构成
面向对象的分析方法：描述系统静态结构的对象模型、描述系统控制结构的动态模型、描述系统计算结构的功能模型，其中对象模型是最基本、最核心、最重要的
第四章 结构化分析
4.1结构化分析概述
一种考虑数据和处理的需求分析方法被称作结构化分析方法（SA法）
结构化分析方法是一种面向数据流的需求分析方法
结构化分析方法适合于数据处理类型软件的需求分析
4.2结构化分析方法
4.2.1功能建模
功能建模的思想就是用抽象模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解。
数据流图（DFD图）：
1、数据流图中表示的符号：
（1）数据变换：表示对数据进行加工或处理
（2）外部实体：表示数据的源点或终点，它是系统之外的实体，同一个外部实体可以在一张数据流程图中出现若干次。
（3）数据流：表示数据和数据的流动方向
（4）数据存储：表示输入或输出文件
2、环境图
环境图也称为系统顶层数据流图（或0层数据流图），仅包括一个数据处理过程。
功能模型数据流图——订货系统实例：
需求描述：
• 假设一家工厂的采购部里的采购员每天需要订货系统产生一张订货报表。报表按照零件编号排序，表中列出了所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述信息：零件编号、零件名称、价格、主要供应商、次要供应商。
• 零件入库或出库称作事务，仓库管理员通过仓库的终端把事务报告给订货系统。当某种零件的库存少于库存量临界值时就应该再次订货了。
画出数据流图：
顶层：
0层：
1层：
4.2.2数据建模
数据建模的思想是在较高的抽象层次上对数据库结构进行建模。数据模型用实体-关系图来描述。
数据模型包括3种相互关联的信息：数据对象（实体）、属性、关系
（1）数据对象：矩形框代表实体
（2）属性：定义数据对象的性质，用椭圆形来表示实体的属性
（3）关系：数据对象彼此之间互相连接的方式，用菱形来表示
数据模型E-R图——仓库管理系统实例
• 请为某仓库的管理系统设计一个ER模型。该仓库管理系统主要管理零件的订购和供应等事项。仓库管理系统向工程项目供应零件，并且根据需要向供应商订购零件。
• 实体类型“零件”的主要属性是：零件编号，零件名称，颜色，重量。实体类型“工程项目”的属性主要是：项目 编号，项目名称，开工日期。实体类型“供应商”的属性主要有：供应商编号，供应商名称，地址。
4.2.3行为模型
状态转换图是一种描述系统对内部或外部事件响应的行为模型。它描述系统状态和事件。
事件引发系统在不同状态间进行转换，而不是描述系统中数据的流动。
这种模型尤其适合用来描述实时系统，因为这类系统多是由外部环境的激励而驱动的。
1、状态：
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
2、事件：
事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或转换状态的控制信息。
状态图中所使用的主要符号：
行为模型状态转换图——图书馆系统为例：
图书馆系统里的图书主要有这几种状态：新上、可借阅、已借出、已丢弃这四种状态，触发这些状态进行转换的事件有分类、借阅、归还、续借、破损、遗失等。
4.2.4数据字典
可以把数据字典作为数据流图的补充，对数据流图中的所有元素作详细的文字说明。
4.2.5加工规格说明
加工规格说明一般用结构化语言、判定表和判定树来表述。
第五章 软件设计
5.1软件设计的基本概念
5.1.1软件设计的意义和目标
5.1.2软件设计的原则
一、模块化：
1、概念：把系统或程序划分为独立命名并且可以独立访问的模块，每个模块完成一个特定的子功能。模块集成起来可以构成一个整体，完成特定的功能。
2、属性：
功能：指定该模块要完成的任务
逻辑：描述模块为了完成任务内部需要怎么做
状态：表明使用该模块时的环境和条件
3、注意：模块规模要适中、提高模块独立性，降低耦合度、提高模块的内聚程度、加强模块的保护性。
（1）模块独立性：软件系统中每个模块只涉及软件要求的具体的子功能，与其他模块没有太多联系。
（2）耦合：是模块之间互相连接的紧密程度的度量。其强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
非直接耦合：两个模块间没有直接关系，他们之间不存在直接的数据联系
数据耦合：调用模块和被调用模块之间只传递简单的数据参数
标记耦合：调用模块和被调用模块之间传递数据结构而不是简单数据。
控制耦合：模块之间传递的不是数据信息，而是控制信息。
外部耦合：系统允许多个模块同时访问同一个全局变量
公共耦合：系统允许多个模块同时访问同一个全局性的数据结构。
内容耦合：两个模块中的一个模块直接引用了另一个模块的内容，那么他们之间就是内容耦合。
软件设计时，要注意尽量使用数据耦合，少用控制耦合，限制公共耦合的使用范围，完全不用内容耦合。
（3）内聚：一个模块内各个元素彼此结合的紧密程度用内聚（或称聚合）来度量。模块内聚性高，就意味着模块内部各个元素是为了完成一个功能而存在。
内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。
偶然内聚：一个模块内的各处理元素之间没有任何实质性联系，只是偶然地被凑到一起。
逻辑内聚：模块内部各组成成分的处理动作在逻辑上相似，但是功能却彼此不同。
时间内聚：如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。
过程内聚：模块内部各个成分按照确定的顺序进行并不相关联系的工作。
通信内聚：如果模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据，则称为通信数据。
顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素的输入数据），则称为顺序内聚。
功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚
二、抽象
三、逐步求精
四、信息隐藏
一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。
这一原理的目的，是为了提高模块的独立性。
五、复用性原则
软件复用就是将已有的软件成分用于构造新的软件系统。
六、灵活性设计
5.1.3软件设计的分类
软件设计可以从活动任务观点和工程管理观点分别对其进行分类
5.2数据库结构设计
数据库结构设计包括概念结构设计、逻辑结构设计和物理结构设计。
扫一扫
6236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
