【软件工程导论第一章:软件工程学概论】

---

诞生来源：计算机系统至今为止已经历了4个阶段，仍未摆脱“软件危机”，为了有效地开发与维护软件，诞生了软件工程学。

1.1软件危机

背景介绍，方便理解，可选看计算机系统第一时期软件通常为规模较小的程序，个体化编辑，此软件环境除了程序清单，没有其它文档资料。
第二时期出现“软件工坊”但还是个体化，软件数量大幅度增长。而且运行错误，新的需求，软硬件更新都要修改程序等等维护工作资源耗费严重，且个体化特征严重导致最终不可维护。“软件危机真实开始”.

1.1.1软件危机介绍与典型表现

1包含两方面问题
①开发问题:以满足日益增长的需求
②维护问题:维护不断膨胀的已有软件
2.软件危机典型表现:
①对软件成本和进度估计不准确:成本高一个数量级(10倍),进度拖延几个月甚至几年
②用户对成品不满意:开发人员不理解完就开始编写,交流不充分导致实际需要不符合
③软件产品质量靠不住
④不可维护:就是软件错误修复不了,不适应新硬件,新的需求加不了等维护问题
⑤没有适当的文档资料:文档资料让管理人员好管理,开发人员的沟通工具,维护人员的维护参考(就是方便复盘)
⑥成本逐年升高:
……

1.1.2软件危机原因

一方面与软件特点有关,一方面是开发与维护方法不正确有关
1.客观原因:
①软件是计算机系统的逻辑部件,缺乏可见性.
②软件规模大,程序复杂性随规模增加呈现指数级上升
2.主观原因:
①开发维护因早期个体化形成糊涂观念,采用了错误方法和和技术.
②存在对开发和维护的错误认识和做法
③对用户需求没有完整准确认识就编程
④软件生命周期:问题定义,开发,使用,维护,废弃.
⑤认识到软件产品完整配置:软件=程序+数据+文档
⑥不同阶段修改代价不同:越早越好
⑦轻视维护

1.1.3消除危机途径

①对软件正确认识,消除软件就是程序的错误观念,而是{程序,数据,文档资料}的集合即{完成功能的指令序列,方便程序处理信息的数据结构,开发使用维护的图文资料}
②充分认识软件开发是一个工程,要组织良好,协调配合……

1.2软件工程(叙述性内容,价值不大,有兴趣自行检索)

1.2.1介绍:指导软件开发和维护的工程学科,采用工程的概念,原理,技术和方法来开发维护

1.2.2基本原理(七条)

1.2.3软件工程方法学(范型)

软件工程包括技术和管理两方面内容.
通常把软件生命周期全过程使用的技术方法的集合叫方法学或范型,其包括三个内容:方法(开发的技术方法:回答"怎么做"问题),工具(运用方法的环境)和过程(完成一系列任务的框架)
①传统方法学(结构化方法)
②面向对象方法学:比上面多了组件,类,继承等等,优点是降低了软件复杂性,促进了软件复用.
以上两个可以思考C语言和C++语言

1.3软件生命周期(后面几个章节的大体内容就是下面这些,详细参考后面)

1.问题定义
2.可行性研究
3.需求分析
4.总体设计
5.详细设计
6.编码和单元测试
7.综合测试
8.软件维护

1.4软件过程

软件开发时的一系列任务的结构框架(就是规定各项任务的步骤的不同模型)。
通常使用生命周期模型（规定了把生命周期划分为哪些阶段及各个阶段的执行顺序，因此也称为软件过程模型）描述软件过程

1.4.1瀑布模型（由文档驱动）

又叫顺序线性模型,引用最广泛的,基本可以用它描述传统软件工程方法学的软件过程

传统版瀑布模型:(过于理想化)
特点(缺点是前面两个＋过于理想化):
1.阶段间具有顺序性和依赖性:①前面阶段完成后面才能完成②前一阶段的输出文档就是后一阶段的输入文档.→所以前面对后面才对
2.推迟实现的观点:编码前设置了系统分析和系统设计的各个阶段,主要考虑系统逻辑模型,不涉及物理模型.清楚的区分逻辑设计和物理设计来尽可能推迟程序的物理实现(就是前面尽可能思考好后面的每一步)
3.质量保证的观点:为了保证质量而坚持:
(1)每个阶段都必须完成规定的文档,不交就当没完成.
(2)每个阶段结束前对所完成的文档进行评审
现实版瀑布模型:(不可能不犯错)

带反馈环的

当在后面阶段发现前面阶段的错误是沿图总左侧的反馈先返回前面阶段修正后再回来.

• 优点:①强迫开发人员使用规范方法
  ②严格规定文档的提交
  ③每个阶段交出的产品严格验证
  ④文档约束使得维护变容易
• 缺点
  ①由文档驱动是其主要缺点,在可运行的软件产品交付之前用户只能通过文档来了解产品,难以全面正确的认识产品,几乎完全依赖书面的规格说明可能导致不能真正满足用户的需要.

1.4.2快速原型链模型(抛弃型)

快速建立可以运行的程序,所完成的功能往往是最终产品的一个子集
快速模型代替需求分析

原理:第一步快速建立能反应用户主要需求的原型系统,让用户通过实践提出修改意见知道用户认为满足则开发人员据此输写规格说明嗯对来开发.

• 优点:
  主要优点是不带反馈环,产品开发基本是线性顺序进行的,因为:
  ①原型系统通过用户交互得到验证,据此产生的规格说明文档正确描述了客户需求.不易返工
  ②开发人员在建立原型的过程中了解到了系统该做什么,设计和编码阶段错误可能性小

1.4.3增量模型(分批完成需求,类似于组件)

原理:也叫渐增模型,把产品作为一系列的增量构件来设计,编码,集成和测试.第一个完成基本功能,再慢慢展开.
分解时唯一约束条件:当把新构件软件集成到现有软件中时所形成的产品必须可测试的.

优点:
①较短时间提交可完成部分工作的产品并之后逐步提交产品.即从第一个构件交付之日起用户就能做一些有用的工作.
②用户有充裕时间学习适应新产品,减少全新产品带来的冲击.
③采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。
缺点：
①集成新构件是必须不破坏原来已经开发出的产品，加入新构架时的过程必须简单方便，也就是软件体系结构必须是开放的
②开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。
③多个构件并行开发，具有无法集成的风险。

1.4.4螺旋模型

基本思想是降低风险。其为将瀑布模型和增量模型结合起来并加入风险分析

需求分析换成快速原型，并每个都加了风险分析

优点：风险驱动的，但是也是弱电，需要开发人员风险评估经验和这方面的专门知识

1.4.5喷泉模型

由于面向对象的特性。各个步骤之间界限变得模糊（分析，设计和编码等之间开始模糊，参考学习c++时的感受），具备了迭代和无缝的特性

• 维护圈变小代表采用面向对象范型后维护时间缩短了，向下箭头代表该阶段的迭代（求精），为避免开发过程过分无序用一个线性过程（例如快速原型模型或上图的中心垂线）作为总目标

1.5.6Rational统一过程

由Rational公司推出的一种完整的软件过程，提供了如何在开发组织中严格分配任务和职责的方法。

1.4.7敏捷过程与极限编程

1.敏捷过程：基于四个价值观提出的软件过程

2.极限编程（敏捷过程的一部分）