软件工程知识点总结
概述
软件
程序+数据+文档
软件危机
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发和维护过程中出现一系列严重问题的现象
软件危机的表现
- 对软件的开发成本和进度的估计不准确
- 用户对已完成的系统不满意
- 软件质量不可靠
- 软件可维护性差
- 缺乏文档资料
- 软件成本上升
- 生产速率跟不上计算机应用普及的趋势
软件危机的原因
软件自身原因
软件自身特点使得开发和维护困难，主要表现在两个方面：
- 复杂性
- 不可见性
软件开发和维护方法不正确
- 没有科学的工程化思想来组织和指导开发
- 没有完善的质量保证体系
- 软件文档没有得到重视
- 从业人员缺乏经验
软件工程
软件工程的定义
软件工程是指导计算机软件开发和维护的一门学科，
采用工程的概念原理技术和方法来开发与维护软件，
把经过时间考验而证明正确的管理技术和当前能够的到的最好的技术方法结合起来，
以经济地开发出高质量的软件并有效地维护它。
软件工程的本质特征
- 关注于大型程序的构造
- 中心课题是控制复杂性
- 软件经常变化
- 开发效率非常重要
- 和谐开发是关键
- 必须有效地支持用户
- 开发者与用户的文化背景不同
软件工程的基本原理
- 用分阶段的生命周期计划严格管理
- 坚持阶段评审
- 实行严格的产品控制
- 采用现代程序设计技术
- 结果应能清楚地进行审查
- 开发小组应少而精
- 承认不断改进软件工程实践的必要性
软件开发方法学
软件生命周期中使用的一整套技术方法的集合称为方法学，也称为泛型
方法学要素
- 方法：软件开发如何做？
- 工具：为软件工程方法提供的软件支撑工具
- 过程：用于开发、管理、维护软件的一系列活动，是将软件工程的标准、方法、工具综合起来以达到合理及时进行软件开发管理维护活动的序列
类型
- 传统方法学
- 面向对象方法学
软件生命周期
软件开发三个阶段
- 定义阶段
- 开发阶段
- 维护阶段
软件生命周期每个阶段的基本任务
- 可行性研究
- 需求分析
- 软件设计
- 编码
- 软件测试
- 软件维护
软件开发模型（软件过程）
软件过程是为了获得高质量软件所需要完成的一系列任务的框架。规定了完成各项任务的工作步骤
用UML 建模语言来描述软件工程模型
瀑布模型 ☆
各阶段间的组织方式就如同瀑布流水一样，逐级下落，完成前一阶段任务后才可开始下一阶段工作
特点
- 阶段间具有顺序性和依赖性
- 必须等前一阶段完成后，才能开始下一阶段工作
- 前一阶段的输出文档就是后一个阶段的输入文档
- 推迟实现的观点：规模大的软件，编码开始越早，最终完成所需时间越长，瀑布模型尽可能推迟程序的物理实现
- 质量保证的观点
- 基于里程碑的阶段过程，开发人员为每个阶段设立里程碑，并做好评审
优点：
- 过程模型简单
- 强迫开发人员采用规范的方法，严格要求文档并需要经过评审，能够保证软件质量
缺点：
- 无法适应变更
快速原型模型
快速建立起能反映用户需求的程序，让用户试用，以了解目标系统概貌，并按照客户要求快速修改原型系统，不断重复。
优点：
- 简单快速
缺点：
- 需要花费额外成本构造原型
- 不利于创新
增量模型 ☆
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。是一个递增的过程，分批次交付软件
优点：
- 模块化可分批次交付，便于客户了解进展
- 模块化降低开发风险，一个周期内的错误不会影响整个系统
- 开发顺序灵活
螺旋模型
用于风险较大的大型软件项目开发过程，可以看成是增加了风险分析过程的快速原型模型
喷泉模型
一种过程模型，支持面向对象，由于面向对象经常需要迭代，喷泉模型可随时回到底层
敏捷模型
敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员间充分的交流和沟通以及合理的机制来有效地响应变化。
敏捷软件开发宣言：
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
习题
可行性研究
可行性研究的目的
用最小的代价在尽可能短的时间内确定问题是否能够并且值得解决可行性研究的根本任务
对以后的行动方针提出建议可行性研究的三个组成：
- 技术可行性 现有技术能否实现
- 经济可行性 经济效益能否超过开发成本
- 操作可行性 系统的操作方式在用户组织内行的通吗
此外还应在法律、社会、管理等其他方面分析
可行性研究的过程
- 复查系统规模和目标
- 研究目前正在使用的系统
- 导出新系统的高层逻辑模型
- 进一步定义问题
- 导出并评价共选择的方案
- 推荐行动方针
- 草拟开发计划
- 书写文档提交审查
系统流程图
是概括描述物理系统的传统工具,表达数据在系统各部件之间流动的情况
用于分析现有系统！！！
复杂系统时应该分层画
数据流图
数据流图描绘系统的逻辑模型，无具体的物理元素，值描绘信息在系统中流动处理的情况
成本效益分析
成本估计
代码行技术
2Xf2E6aEU7n685eHEbXGYHrmWn2y7a62UWBrtZzodVdD
任务分解技术
将软件开发工程分解成若干个相对独立的任务，分别估算，累加得到总成本
开发成本估计技术
需要软件和数据的支撑
习题
总体设计
软件设计的任务
以软件需求规格说明书为依据，着手实现软件的需求，并将设计的结果反应在“设计规格说明书”的文档中
总体设计（概要设计）
根据软件需求，设计软件系统结构和数据结构确定程序的组成模块之间的关系，从抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选取最佳方案和最合理的软件结构，从而用较低成本开发出高质量的软件系统
详细设计（过程设计）
确定模块内部的算法和数据结构，选定某种过程的表达形式来描述算法，生成详细文档
设计过程
- 提供选择方案
- 从需求阶段的数据流图出发
- 选取合理方案
- 系统流程图
- 组成系统的物理元素清单
- 成本效益分析
- 实现系统的进度计划
- 推荐最佳方案
- 功能分解
- 设计软件结构
- 设计数据库
- 制定测试计划
- 书写文档
- 系统说明
- 用户手册
- 测试计划
- 详细的实现计划
- 数据库设计结果
- 审查和复审
设计原理
模块化
什么是模块？
模块是数据说明和可执行语句等程序对象的集合，每个模块单独命名并且可以通过名字对模块进行访问
模块化思想
采用自顶向下的方式，逐层把软件系统划分成若干个可单独命名和可编址的模块，每个模块完成一个特定的子功能，所有模块按照某种方法组成一个整体，完成整个系统所要求的的功能。
模块化的优点
- 降低软件复杂性
- 减少开发工作量
- 降低成本
- 提高软件生产率
模块化与软件成本的关系
并非模块越多越好！
抽象
什么是抽象？
认识复杂事物和现象时，抽出事物本质的共同特性而暂不考虑他们的细节
逐步求精
为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。可以看做把一个时期内必须解决的问题按照优先级排序的技术，是一种自顶向下的设计策略
miller原则
一个人在任何时候都只能把注意力集中在5-9个知识块上
信息隐藏和局部化
在设计和确定模块时，使得一个模块内包含的信息（过程或数据），不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必项交换的信息。
局部化：将一些关系密切的软件元素物理地彼此靠近：如局部变量
模块独立（低耦合，高内聚）
模块只完成系统要求的相对独立的功能，符合信息隐蔽原则，模块间关联和依赖程度尽量小
优点
容易开发测试和维护
两个原则
低耦合、高内聚
详见另一篇博客：耦合与内聚
启发规则
- 改进软件结构提高模块独立性
- 模块规模应该适中
- 深度、宽度、扇出、扇入应适当
- 模块的作用域应在控制域之内
- 力争降低模块接口的复杂程度
- 设计单入口单出口的模块
- 模块功能应该可以预测