一、软件与软件危机
1、软件发展经历三个阶段：程序设计、程序系统、软件工程
2、软件的概念：软件是计算机系统与硬件相互依存的另一部分，包括程序、数据以及相关文档的完整集合，软件=程序+数据+文档
- 数据：使程序能够适当处理信息的数据结构
- 程序：能够完成预定功能和性能的可执行执行序列
- 文档：是开发、使用和维护过程程序锁需要的图文资料
3、软件的特点：
- 软件本身复杂性
- 软件的成本高昂
- 软件开发未摆脱手工开发方式
- 软件维护与硬件有本质差别，维护难度高
- 软件开发部署传统硬件制造过程
- 软件是一种逻辑实体，无磨损性
4、软件危机的概念：在计算机软件开发和维护过程中所遇到的一些列严重问题。两个方面内容：
- 如何开发软件，以满足对软件日益增长的需求
- 如何维护数量不断膨胀的已有软件
5、软件危机的表现：
- 对软件开发成本和进度估算不准确
- 用户对已经完成软件不满意
- 软件质量不可靠
- 没有适当文档资料
- 软件成本在计算机系统中所占比例逐年上升
- 软件开发生产率低
6、软件危机的原因：
主观原因
- 忽视需求分析
- 轻视软件维护
- 没有认识到程序只是软件的一部分
- 没有认识到软件开发只是漫长的软件生命周期中一个比较次要的阶段
- 越到后期引入变动付出代价越高
客观原因：
- 软件是逻辑实体、缺乏可见性，管理和控制困难
- 软件不会磨损，维护意味着修改原来设计，维护困难
- 软件规模庞大，程序复杂性随规模增加指数上升
7、消除软件危机的途径：
- 对计算机软件应该有正确的认识
- 吸取借鉴人类长期从事各种工程项目积累的原理概念技术和方法
- 积累开发和使用计算机辅助开发工具
- 探索更好更有效的管理措施和手段对开发过程进行控制和管理
二、软件工程
1、定义：采用工程的概念、原理、技术和方法来开发与维护软件，把经历时间考验二证明正确的管理技术和当前能够得到的最好技术方法结合起来，经济的开发出高质量的软件并维护他
2、软件工程的本质特性：
- 关注大型程序的构造
- 中心课题是控制复杂性
- 软件经常变化
- 开发效率非常重要
- 开发人员和谐合作是关键
- 软件需有效支持用户
- 软件开发者替代其他领域人员创造产品
3、基本原理：
- 按软件生存期分阶段制定计划并认真实施
- 坚持进行阶段评审
- 坚持严格的产品控制
- 使用现代程序设计技术
- 结果能够得到清楚的审查
- 用人少而精
- 承认不断改进软件工程实践的必要性
4、软件工程方法学：
把软件生命周期全过程中使用的一整套技术方法的集合成为方法学，也称泛型
软件工程的方法学包括三要素：方法、工具和过程
- 方法：完成软件开发各项任务的技术方法
- 工具：为运用方法提供的自动或半自动软件工程支撑环境
- 过程：为了获得高质量软件所需要完成的一系列任务框架
5、软件生命周期
三、软
件过程
软件过程是为了获得高质量软件所需要完成的一系列任务框架
通常用软件声明周期模型描述软件过程
瀑布模型
将软件生命周期的各项获得规定为依据固定顺序连接若干阶段工作，最终得到软件
特点:
- 阶段间具有顺序性和依赖性
- 推迟实现的观点
- 质量保证的观点
- 每个阶段必须完成规定的文档
- 每个阶段结束前完成文档审查及早改正错误
快速原型模型
快速建立可运行的程序，他完成的功能往往是最终产品功能的一个子集
增量模型
把分析设计编码测试交付分成一个个增量，每个增量都是一个完整的流程，先完成一个系统子集的开发，再按照同样的开发步骤增加功能，如此递增下去直至满足全部系统需求
优点：短时间内可提交完成部分功能，主键增加产品功能，用户适应产品快
缺点：增量构建划分以及集成困难，容易退化为边做边改模型
还有风险更大的递增模型，就是并行执行的他们的效率更高了，但是也有可能很难组合一起
螺旋模型
在每个阶段之前都增加了风险分析过程的快速原型模型，看作增加了风险分析的快速原型模型
优点：
- 利于把软件质量作为软件开发目标
- 减少测试
- 维护和开发不分开
缺点：风险估计困难
喷泉模型
典型的面向对象软件过程模型，体现迭代和无缝的特性
四、可行性研究
目的：用最小的代价在最小的时间内确定问题是否能够解决
实质：系统分析和设计过程的大大压缩和简化，在较高层次上比较抽象的方式进行系统的分析和设计过程
过程：
- 分析和澄清问题定义
- 导出系统的逻辑模型（数据流图和数据字典）
- 根据逻辑模型探索若干种可以供选择解法
- 研究每种解法可行性
- 经济可行性：经济效益是否大于开发成本
- 技术可行性：现有技术能够实现
- 操作可行性：系统操作方式是否可行
- 其他可行性：法律、社会效益
成本效益分析：从经济角度分析新系统的开发是否盈利，帮助使用部门正确做出是否投资的决定
五、软件设计阶段
设计过程
总体设计又称概要设计或初步设计
任务：
- 确定系统每个程序由哪些模块组成以及这些模块相互间的关系
- 划分出物理元素，包括程序、文件、数据库、文档等
设计过程包括系统设计阶段和结构设计阶段
设计原理
- 模块化
- 模块:能够单独命名，由边界元素限定的程序元素的序列，是构成程序的基本构件。
- 模块化:把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求
- 抽象：抽出事务的本质特性而暂时不考虑它们的细节
- 逐步求精：逐步揭露出底层细节
- 信息隐藏和局部化
- 信息隐藏:指一个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。主要是指模块的实现细节。
- 局部化:指把一些关系密切的软件元素物理地放得彼此靠近，它有助于实现信息隐藏。
- 模块独立
- 模块独立性·是模块化、抽象、信息隐蔽和局部化概念的直接结果
- 模块独立是好设计的关键，设计是决定软件质量的关键环节
- 度量标准:耦合、内聚
耦合：对软件结构内不同模块之间相互联系程序的度量，耦合强度取决于模块接口的复杂程度、通过接口的数据等。耦合性越高，模块独立性越弱
耦合分类（程度从低到高）：
无直接耦合→数据耦合→标记耦合（特征耦合）→控制耦合→外部耦合→公共耦合
内聚：是模块内部各个元素彼此结合的紧密成都
内聚分类（程度从低到高）：
偶然内聚→逻辑内聚→时间内聚→过程内聚→通信内聚→顺序内聚→功能内聚
同其他模块强耦合的模块意味着内聚弱，强内聚模块意味着与其他模块松散耦合
设计目标：高内聚、低耦合
启发规则
改进软件结构提高模块独立性
模块规模应该适中
深度、宽度、扇入和扇出应适当
- 深度: 表示软件结构中控制的层数。
- 宽度: 软件结构内同一个层次上的模块总数的最大值。
- 扇出:一个模块直接控制(调用) 的模块数目，扇出过大意味着模块过分复杂一般一个设计的好的典型系统的平均扇出是3或4，扇出的上限是5到9。
- 扇入: 指有多少上级模块调用它，扇入大说明上级模块共享该模块的数目多好的软件结构顶层扇出比较高，中层扇出比较少，底层扇入到公共的实用模块中，即底层模块有高扇入。
模块的作用域应该在控制域之内
- 作用域: 指受该模块内一个判定影响的所有模块的集合
- 控制域: 是这个模块本身以及所有直接或间接从属于它的模块的集合
力争降低模块接口的复杂程度
设计单入口单出口的模块
模块功能应该可以预测
六、测试阶段
软件生命周期中编码和测试统称为实现
软件测试是为了发现错误而执行程序的过程
- 编码阶段（单元测试）
- 测试阶段（各种综合测试）
软件测试的方法:
- 黑盒测试：将软件看作一个黑盒子，不考虑其内部结构和处理过程，只按照规格说明书的规定，测试软件是否能够正确接收输入数据，产生正确的输出数据，即测试程序是否正确的实现了其功能
- 白盒测试：完全知道程序内部结构和处理算法，因此可以将程序看做一个透明的白盒子，根据程序内部的逻辑结构测试程序内部的主要执行通路是否能够按照预定的要求准确工作，结构测试