《软件工程导论》第一章-软件工程学概述-笔记整理

皮皮龍丶PPRON

已于 2023-11-27 18:06:15 修改

阅读量355

点赞数 2

分类专栏：软件工程导论-笔记整理-张海藩第6版文章标签：软件工程笔记

于 2023-11-22 12:40:08 首次发布

本文链接：https://blog.csdn.net/a1818618/article/details/134550183

版权

软件工程导论-笔记整理-张海藩第6版专栏收录该内容

1 篇文章 0 订阅

订阅专栏

个人向笔记整理，如有错误欢迎指正= =

参考教材：《软件工程导论》-张海藩第6版

目录

3.2 生命周期的组成：（3个时期、8个阶段）

5.3 传统方法学（生命周期方法学或结构化范型）

5.4 面向对象方法学

6 软件工程技术[补充]

1 软件工程的发展

1.1 软件工程发展的4个阶段

（1）第一阶段（20世纪60年代中期以前）：传统软件工程

软件通常是规模较小的程序，编写者和使用者往往是同一（或同一组）人。

（2）第二阶段（20世纪60年代中期-70年代中期）：对象工程

“软件作坊”的出现，广泛使用产品软件。“软件危机”出现。1968年北大西洋公约组织在联邦德国召开的国际会议上提出“软件工程”的概念。

（3）第三阶段（20世纪70年代中期-80年代中期）：过程工程

工程化的思想被引入软件开发中，结构化方法的发展，规模化软件开发。

（4）第四阶段（20世纪80年代中期至今）：构件工程

面向对象方法学发展，软件定制和满足客户需求。

1.2 软件危机

1.2.1 软件危机的概念：软件危机是指在计算机软件的开发和维护工程中所遇到的一些列严重问题。主要包括：

①开发：如何开发软件，以满足对软件日益增长的需求；

②维护：如何维护数量不断膨胀的已有软件。

1.2.2 软件危机的典型表现：

①对软件开发成本和进度的估计常常很不准确；

②用户对“已完成的”软件系统不满意的现象经常发生；

③软件产品的质量往往靠不住；

④软件常常是不可维护的；

⑤软件通常没有适当的文档资料；

⑥软件成本在计算机系统总成本中所占的比例逐年上升；

⑦软件开发生产率提高的速率，远远跟不上计算机应用迅速普及及深入的趋势。

1.2.3 软件危机产生的原因：

（1）客观原因：

①软件是计算机系统中的逻辑部件，而不是物理部件；

②软件的一个特点是规模庞大，而且程序复杂性将随着程序规模的增加，而呈指数级上升。

（2）主观原因：

①对软件开发和维护的观念模糊，存在错误的认识和做法，采用了错误的方法和技术；

②对用户要求没有完整准确的认识就匆忙着手编写程序；

③一个软件从定义、开发、使用、维护到最终被废弃，要经历一个漫长的时期；

④一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分；

⑤在软件开发的不同阶段进行修改需要付出的代价是很不相同的；

⑥轻视了软件维护的重要性。

1.2.4 消除软件危机的途径：

①应该对计算机软件有一个正确的认识，软件是程序、数据及相关文档的完整集合；

（程序：能够完成预定功能和性能的、可执行的指令序列

数据：使程序能够适当地处理信息的数据结构

文档：开发、使用和维护程序所需要的图文资料）

②工程方法：应该充分认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目；

③成功经验：应该推广使用在实践中总结出来的、开发软件的、成功的技术和方法；

④软件工具：应该开发和使用更好的软件工具。

2 软件工程

2.1 软件的定义

2.1.1 一般定义：

软件是程序、数据及相关文档的完整集合。

2.1.2 软件的三要素：

程序+数据+文档。

2.2 软件工程的定义

（1）1968年NATO会议：软件工程就是为了经济地获得可靠的、且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。

（2）1993年IEEE：软件工程是:①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。

2.3 软件工程的本质特性

①软件工程关注于大型程序的构造；

②软件工程的中心课题是控制复杂性；

③软件经常变化；（需求的不确定性与易变性）

④开发软件的效率非常重要；（高效的方法和工具）

⑤和谐地合作是开发软件的关键；

⑥软件必须有效地支持它的用户；

⑦在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品。（为其他领域和文化背景创造产品）

2.4 软件工程的基本原理

2.4.1 七条基本原理：

①用分阶段的生命周期计划严格管理；

②坚持进行阶段评审；

③实行严格的产品控制；

④采用现代程序设计技术；

⑤结果应能清楚地审查；

⑥开发小组的人员应该少而精；

⑦承认不断改进软件工程实践的必要性。

2.4.2 意义：

遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。这七条原理相互独立、缺一不可，是确保软件产品质量和开发效率的原理最小集合。

3 软件工程的生命周期

3.1 软件工程生命周期的概念

软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3 个时期组成,每个时期又进一步划分成若干个阶段。

3.2 生命周期的组成：（3个时期、8个阶段）

3.2.1 软件定义时期：

（1）问题定义：回答“要解决的问题是什么？”，最终应得到关于问题性质、工程目标和工程规模的书面报告。

（2）可行性研究：回答“对于上一个阶段所确定的问题有行得通的解决办法吗？”，研究的结果是客户做出是否继续进行这项工程的决定的重要依据。

（3）需求分析：确定目标系统必须具备的功能。该阶段须确定的系统逻辑模型是以后设计和实现目标系统的基础，通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。分析的结果产物是需求规格说明书（包括验收测试计划）。

3.2.2 软件开发时期：

（4）总体设计（概要设计）：概括地回答“应该怎样实现目标系统”，任务一是设计出实现目标系统的几种可能的方案，通常至少应该设计出低成本、中等成本和高成本3种方案。任务二是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。

（5）详细设计：是把解法具体化。即回答 “应该怎样具体地实现这个系统呢？”，详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。该阶段的产物是详细规格说明书（包括单元测试计划）。

（6）编码和单元测试：关键任务是写出正确的容易理解容易维护的程序模块，即根据详细规格说明书把结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

（7）综合测试：关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求，最基本的测试是集成测试和验收测试，必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。同时应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。验收测试结束后必须提交最终用户手册给用户。

3.2.3 软件维护时期：

（8）软件维护：关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。通常有4类维护活动：

①改正性维护：诊断和改正在使用过程中发现的软件错误；

②适应性维护：修改软件以适应环境的变化；

③完善性维护：根据用户的要求改进或扩充软件使它更完善；

④预防性维护：修改软件，为将来的维护活动预先做准备。

4 软件过程

4.1 软件过程的概念

软件过程是为了获得高质量软件所需完成的一系列任务的框架，它规定了任务完成各项任务的工作步骤。一般使用软件生命周期模型（过程模型）简洁地描述软件过程，生命周期模型规定了把生命周期划分成的阶段及各个阶段的执行顺序。

4.2 典型软件过程模型

4.2.1 瀑布模型

图1 传统瀑布模型图2 实际瀑布模型

（1）传统瀑布模型（不带反馈环）的特点：（图1）

①阶段间具有顺序性和依赖性；

②推迟实现的观点；

③质量保证的观点（文档、评审）。

（2）实际的瀑布模型（带反馈环）的优点：（图2）

①可强迫开发人员采用规范的方法；

②严格地规定了每个阶段必须提交的文档；

③要求每个阶段交出地所有产品必须经过质量保证小组的仔细验证；

④对文档的约束降低了软件维护的成本和对软件的预算。

（3）瀑布模型的缺点：

①瀑布模型是由文件驱动的模型，仅通过纸面静态的规格说明很难正确地认识动态的软件产品，缺乏灵活性；

②由于几乎完全依赖书面的规格说明，线性开发的结果存在很大的未知性和风险性。

（4）瀑布模型的适用范围：

①用户的需求非常清楚全面，且在开发过程中没有或很少变化；

②开发人员对软件的应用领域很熟悉；

③用户的使用环境非常稳定；

④开发工作对用户参与的要求很低。

4.2.2 快速原型模型

（1）快速原型模型（不带反馈环）的优点：

快速原型模型不带反馈环，使得软件产品的开发基本上是线性顺序进行的：

①原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。

②开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

（2）快速原型模型的缺点：

①设计过程缺乏可见性；

②软件产品的结构性通常较差。

（3）快速原型模型的适用范围：

①对所开发的领域比较熟悉而且有快速的原型开发工具；

②项目招投标时，可以以原型模型作为软件的开发模型；

③进行产品移植或升级时，或对已有产品原型进行客户化工作。

（4）与瀑布模型的比较：

快速原型模型在确定需求的效率上优于瀑布模型，弥补了瀑布模型不适用于需求动态变更的缺点，提供了学习方法。

4.2.3 增量模型（渐增模型）

（1）增量模型的原理：

使用增量模型开发软件时，把软件产品看为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

（2）增量模型的优点：

①能在短时间内向用户提交可完成部分工作的产品；

②用户由较充裕的时间学习和适应新的产品；

③降低了失败的风险；

④最重要的系统服务接收到最对的测试。

（3）技术难点：

①在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，即，软件体系结构必须是开放的。

②增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。

（4）风险更大的增量模型：

4.2.4 螺旋模型

（1）螺旋模型的基本思想：

使用原型及其它方法来尽量降低风险。可以把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。（风险驱动型模型）

（2）简化的螺旋模型：

（3）完整的螺旋模型：

（4）螺旋模型的优点：

①对可选择方案和约束条件的强调有利于已有软件的重用，有助于把软件质量作为开发的一个重要目标；

②减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；

③在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质的区别。

（5）螺旋模型的缺点：

螺旋模型是风险驱动型模型。因此需要软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险。

（6）螺旋模型的适用范围：

螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。

4.2.5 喷泉模型

（1）喷泉模型的原理和特点：

是典型的面向对象的软件过程模型之一。“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在交迭；而面向对象方法在概念和表示方法上的一致性，保证了在各项开发活动之间的无缝过渡，事实上，用面向对象方法开发软件时，在分析、设计和编码等各项开发活动之间并不存在明显的边界。图中在一个阶段内的向下箭头代表该阶段内的迭代（或求精）。图中较小的圆圈代表维护，圆圈较小象征着采用了面向对象范型之后维护时间缩短了。

（2）要求：

为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程作为总目标。同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。

4.2.6 Rational统一过程（Rational Unified Process, RUP）

（1）最佳实践：RUP 总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验被称为“最佳实践”：

①迭代式开发；

②管理需求；

③使用基于构件的体系结构；

④可视化建模；

⑤验证软件质量；

⑥控制软件变更。

（2）RUP软件开发生命周期：是一个二维的生命周期模型。

横轴表示时间；纵轴表示核心工作流。

A.核心工作流：

前6个为核心过程工作流程；后3个为核心支持工作流程。

B.工作阶段：

①初始阶段：建立业务模型,定义最终产品视图，并且确定项目的范围；

②精化阶段：设计并确定系统的体系结构，制定项目计划,确定资源需求；

③构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能；

④移交阶段：把开发出的产品提交给用户使用。

（3）RUP的特点：

①迭代：RUP强调在软件开发过程中采用迭代和增量的方法。每个迭代都会产生可见的、可测试的、可执行的产品；

②以风险为驱动：RUP是以风险为驱动的过程。在每个迭代中，都需要识别和解决最重要的风险；

③以用例为驱动：RUP是以用例为驱动的过程。用例被用来捕捉需求，指导设计、实现和测试；

④高度可配置：RUP是一个框架，而不是一个具体的过程。它可以根据项目的特性和团队的需求进行定制和配置。

4.2.7 敏捷过程：

（1）适用范围：

敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间地约束。

（2）价值观声明：

①个体和交互胜过过程和工具；

②可以工作的软件胜过面面俱到的文档；

③客户合作胜过合同谈判；

④响应变化胜过遵循计划。

4.2.8 极限编程（eXtreme Programming, XP）

（1）XP的整体开发工程：

（2）XP的迭代开发过程：

（3）XP的特点：

①极限编程为代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性；

②在快速的同时仍然能够保持可持续的开发速度。

4.2.9 微软过程

（1）微软过程基本准则：

项目计划应该兼顾未来的不确定因素；
用有效的风险管理来减少不确定因素的影响；
经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性；
采用快速循环、递进的开发过程；
用创造性的工作来平衡产品特性和产品成本；
项目进度表应该具有较高稳定性和权威性；
使用小型项目组并发地完成开发工作；
在项目早期把软件配置项基线化，项目后期则冻结产品；
使用原型验证概念，对项目进行早期论证；
把零缺陷作为追求的目标；
里程碑评审会的目的是改进工作,切忌相互指责。

（2）微软软件生命周期：

A.规划阶段：

①确定产品目标获取竞争对手的信息；

②完成对客户和市场的调研分析；

③确定新版本产品应该具备的主要特性；

④确定相对于前一版本而言，新版本应该解决的问题和需要增加的功能。

B.设计阶段：

①根据产品目标编写系统的特性规格说明书，这份规格说明书主要描述软件特性、系统结构、各构件间的相关性以及接口标准；

②从系统高层开始着手进行系统设计，主要完成下述工作：简明扼要地描述整个系统的设计方案，绘制系统结构图，确定系统中存在的风险因素，分析系统的可重用性。

③划分出系统中的子系统，给出各个子系统和各个构件的规格说明；

④根据产品特性规格说明书制订产品开发计划。

C.开发阶段：

这个阶段的主要任务是，完成产品中所有构件的开发工作，包括编写程序代码和书写文档。一些开发工作可能会持续到稳定阶段，以便在那时对测试中发现的问题做出修改。

D.稳定阶段：

这个阶段的主要任务是对产品进行测试和调试，以确保已经正确地实现了整个解决方案，产品可以发布了。这个阶段测试的重点是，产品在真实环境下的使用和操作。

E.发布阶段：

在这个阶段项目组发布产品或解决方案，稳定发布过程，并把项目移交到运营和支持人员手中,以获得最终用户对项目的认可。

（3）微软过程模型：

①定义：

微软过程的每一个生命周期发布一个递进的软件版本，哥哥生命周期持续、快速地迭代循环。

②特点：

a.目的软件过程模式，微软过程综合了Rational统一过程
和敏捷过程的许多优点是对众多成功项目的开发经验的正确总结；

b.微软过程也有某些不足之处，例如对方法、工具和产品等方面的论述不如RUP和敏捷过程全面，人们对它的某些准则本身也有不同意见。在开发软件的实践中，应该把微软过程与RUP和敏捷过程结合起来，取长补短，针对不同项目的具体情况进行定制。

5 软件工程方法学

5.1 软件工程方法学的概念

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（methodology），也称为范型（paradigm）。

5.2 软件工程方法学的三要素

①方法：完成软件开发的各项任务的技术方法，回答“怎么做”的问题；

②工具：为运用方法而提供的自动的或者半自动的软件工程支撑环境；

③过程：为了获得高质量的软件所需完成的一系列任务框架，它规定了完成各项任务的工作步骤。

5.3 传统方法学（生命周期方法学或结构化范型）

5.3.1 传统方法学的定义：

它采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。

5.3.2 开发步骤：

传统方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务：

①从对问题的抽象逻辑分析开始，一个阶段一个阶段地顺序进行开发；

②前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节；

③每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准；

④在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两个方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果没通过检查，则必须进行必要的返工，而且返工后还要再经过审查。

5.3.3 传统方法学的优点：

①把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；

②在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性；

③采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。

5.3.4 传统方法学的缺点：

①当软件规模庞大、对软件需求不明确或需求会随时间变化而变化时，传统方法学开发软件往往不成功；

②传统方法学开发出的软件，在维护性方面较差；

③结构化范型技术不能同时面向行为和数据，而软件系统本质上是信息处理系统。

5.4 面向对象方法学

5.4.1 面向对象方法学的定义和基本原则：

面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间（问题域）与实现解法的解空间（求解域）在结构上尽可能一致。

5.4.2 面向对象方法学的要点：