软件工程导论

这篇是自己整理软件工程导论这门课的重要笔记~

一.软件工程学概述

软件危机：

指计算机软件在开发还有维护过程中所遇到的一系列严重问题。

软件危机的典型表现：

对软件开发成本和进度的估计常常很不准确；
用户对“已完成的”软件系统不满意的现象经常发生；
软件产品的质量往往靠不住；
软件常常是不可维护的；
软件通常没有适当的文档资料；
软件成本在计算机系统总成本中所占比例逐年上升；
软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

产生软件危机的原因：

软件本身的特点

软件不同于硬件，是逻辑部件，维护难度较大；
软件不同于一般程序，规模庞大，复杂性大；
软件开发人员的在开发，维护上的糊涂观念，采用错误的方法和技术；

软件开发与维护的方法不正确

忽视需求分析的重要性；
轻视软件的维护；
急于编程。

消除软件危机的途径：

几个基本概念：

软件：程序，数据以及相关文档的集合；
程序：能够完成预定功能和性能的可执行指令序列；
数据：使程序能够适当地处理信息的数据结构；
文档：开发，使用和维护程序所需要的图文资料。

全面消除软件危机，需要一系列综合措施。既要有必要的组织管理措施，也要有先进成熟的技术措施。

对计算机软件有一个正确的认识，软件不等于程序等；
管理：
开发和使用更好的软件工具，把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境；
按工程化的原则和方法组织软件开发工作是有效的也是摆脱软件危机的一个主要出路；
技术：
软件开发必须吸取和借鉴各种工程项目多积累的原理，概念，技术和方法；
推广使用实践中总结出的开发软件的成功的技术和方法，探索更有效的技术和方法。

软件工程的介绍：

1993年IEEE进一步给出了更全面更具体的定义：“软件工程是：1.把系统的，规范的，可度量的途径应用于软件开发，运行和维护过程，也就是把工程应用于软件；2.研究1中提到的途径。”

软件工程的本质特性：

软件工程专注于大型程序的构造；
软件工程的中心课题是控制复杂性；
软件经常变化；
开发软件的效率非常重要；
和谐地合作是开发软件的关键；
软件必须有效地支持它的用户；
在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品。

软件工程的7条基本原理：

用分阶段的生命周期计划严格管理；
坚持进行阶段审评；
实行严格的产品控制；
采用现代化程序设计技术；
结果应能清楚地审查；
开发小组的人员应该少而精；
承认不断改进软件工程实践的必要性。

软件工程方法学包含3个要素：

方法，工具和过程。

软件生命周期每个阶段的基本任务：

问题定义；可行性研究；需求分析；总体设计；详细设计；编码和单元测试；综合测试。

螺旋模型的主要优势在于：

它是风险驱动的，但是这也可能是它的一个弱点。

二.可行性研究

从3个方面研究每种解法的可行性：

技术可行性；经济可行性；操作可行性。

数据流图的概念：

数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入到输出的过程中所经受的变换。

数据流图的4类元素：

数据流；数据流分量（即数据元素）；数据存储；处理。

由数据元素组成数据的方式有3种基本类型：

顺序 即以确定次序连接两个或多个分量；
选择 即从两个或多个可能的元素中选取一个；
重复 即把指定的分量重复零次或多次。

三.需求分析

需求分析的基本任务:

准确地回答“系统必须做什么”这个问题。

需求分析的任务：

确定对系统的综合要求
分析系统的数据要求
导出系统的逻辑模型
修正系统开发计划

与用户沟通获取需求的方法

正式访谈
非正式访谈
问卷调查
情景分析

从哪些方面验证软件需求的正确性

一致性；完整性；现实性；有效性。

四.总体设计

设计过程

设想供选择的方案
选取合理的方案
推荐最佳方案
功能分解（核心）
设计软件结构
设计数据库
制定测试计划
书写文档
审查和复审

五.详细设计

详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统。
详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个“蓝图”写出实际的程序代码。

Jackson方法的原理

输入的数据结构与输出的数据结构以及两种数据结构的对应关系设计程序的方法。

六.实现

软件测试的目标

测试是为了发现程序中的错误而执行程序的过程；
好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
成功的测试是发现了至今为止尚未发现的错误的测试。

软件测试准则（七个）

测试应“尽早地和不断地进行”；
较早确定测试计划，严格执行测试计划；
注意错误的群集现象和应用Pareto原则；
测试规模应从小到大；
测试应一般由独立的第三方进行；
应保证测试用例的完整性和有效性；
应保存所有测试用例和出错统计等，直至软件不用为止。

测试方法

黑盒测试
白盒测试

集成测试

自顶向下集成
从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。
自底向上集成
从“原子”模块（即在软件结构最底层的模块）开始组装和测试。

回归测试

回归测试集（已执行过的测试用例的子集）包括下述3类不同的测试用例：
检测软件全部功能的代表性测试用例；
专门针对可能受修改影响的软件功能的附加测试；
针对被修改过的软件成分的测试。

Alpha和Beta测试的区别（5点）

α开发者测，β用户自己测；
α有人指导，β无人指导；
遇到错误时，α开发者记录，β自己记录；
α受控测试，β非受控测试；
α由测试部门执行，β由传统发行部门执行。

七.维护

软件的可维护性：

可理解性；
可测试性；
可修改性；
可移植性；
可重用性。

八.软件项目管理

软件项目管理的困难

智力密集，可见性差；
单位生产；
劳动密集，自动化程度低；
使用方法繁琐，维护困难。

代码行技术

每个人都估计程序的最小规模（a），最大规模（b）和最可能的规模（m），分别算出这3种规模的平均值之后，再用下式计算程序规模的估计值。
用代码行技术估算软件规模时，当程序较小时常用的单位时代码行数（LOC），当程序较大时常用的单位是千代码数（KLOC）
代码行技术的优点：
代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。
代码行技术的缺点：
源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数所需要的代码行数并不相同；这种方法不适用于非过程语言。

功能点技术

单位：功能点（FP）
功能点技术定义信息域的5个特性：
输入项数；输出项数；查询数，主文件数和外部接口数。

E是以人月或人年为单位的工作量。

开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。

COCOMO2模型

用于不同类型的项目；
用于同一个项目的不同开发阶段。

软件项目的开发时间最多可以减少到正常开发时间的75%。

关键路径

关键路径上的事件（关键事件）必须准时发生，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。

人员组织

责任到人，合理分工，责权均衡。

软件项目成功的关键：

高素质的软件开发人员；
把多名开发人员合理地组织起来。

软件质量：

概念：软件与明确地和隐含地定义的需求相一致的程度。

软件质量因素与产品活动的关系：

软件质量保证的措施：

基于非执行的测试；
基于执行的测试；
程序正确性证明。

质量保证活动主要是：计划，监督，记录，分析和报告。

软件配置管理

概念：软件配置管理是在软件的整个生命周期内管理变化的一组活动。

作用：

标识变化；
控制变化；
确保适当地实现了变化；
向需要知道这类信息的人报告变化。

软件配置

软件配置项

软件过程的输出信息可以分为3类：
计算机程序（源代码和可执行程序）
描述计算机程序的文档（供技术人员或用户使用）
数据（程序内包括的或在程序外的）

基线的定义：

类似需求分析各个版本概要设计的各个版本已经通过正式复审的规格说明和中间产品；
进一步开发的基础，每一步都是后续工作的基础，下一阶段工作的基础；
只有通过正式的变化控制过程才能改变它。

能力成熟度等级

初始级；可重复级；已定义级；已管理级；优化级。

九.几种模型的优缺点

瀑布模型

（适用于功能和性能需求明确的软件项目的开发和维护，如编译系统等）

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现的观点
• 质量保证的观点

优点：

• 强迫开发人员使用规范的方法
• 严格规定了每个阶段必须提交的文档
• 要求每个阶段提交的产品都经过了仔细验证是一种文档驱动的模型

缺点：

• 几乎完全依赖于书面的规格说明，可能导致开发的软件产品不能真正满足客户的需要
• 实际的软件开发过程中，各阶段之间并非完全的自上而下线性顺序展开
• 在开发过程中，用户看不见系统，只有在最后交付的时候系统才能和用户见面
• 不够灵活，完全依赖于规格说明（针对需求模糊或变化的情况）

快速原型模型

优点：

• 有助于用户的真实需求得到满足
• 开发基本时线性顺序进行的
  （产生的规格说明文档不会导致较大返工；通过建立原型，开发人员设计和开发阶段发生错误的可能性小）

缺点：

• 不宜利用原型系统作为最终产品
• 原型模型的“快速”特点对最终系统不适用

增量模型

优点：

• 分批地向用户提交产品，减少全新软件产品对用户带来的影响
• 能在较短时间内向用户提交可完成部分工作的产品
• 逐步增加功能可使用户有充裕的时间来学习和适应新产品
• 可以根据需要补充人员
• 能够有计划的管理技术风险
• 不需要大的资金支出
• 用户能及早使用及早发现问题
• 分解的规模应该适中，遵守约束条件:集成后，可测试

缺点

• 新构件集成到现有软件体系结构时，必须不破坏原来的产品
• 软件体系结构必须时开放的
• 本身自相矛盾，一方面把软件看作整体，另一方面又要看作构建序列
• 构件可能无法集中到一起
• 若产品整体结构设计不当，则难为其增加新的增量
• 由于采用 增量开发，故难于进行彻底的测试

螺旋模型

（适合内部开发的大规模软件项目）

优点：

• 有利于已有软件的重用
• 减少了过多测试和测试的不足
• 维护只是模型的另一个周期
• 是风险驱动的

缺点：

• 要求软件开发人员擅长风险分析
• 风险分析会导致项目终止而终止合同，出现违约诉讼
• 对于小项目，风险分析的成本可能与整个项目的成本相当