软件工程导论复习

一、软件工程的概述

1、软件的定义

1.1概念

软件是计算机系统与硬件相互依存的另一部分，它包括程序、数据及其相关文档的完整集合.

软件=程序+数据+文档

程序=算法+数据结构

1.2软件发展的三个阶段

1. 程序设计阶段 ——50-60年代

2. 程序系统阶段 ——60-70年代

3. 软件工程阶段 ——70年代以后

1.3软件的特点

2、软件危机

2.1概念

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

2.2软件危机包含两个方面

2.3软件危机的表现

2.4软件危机的原因

2.5消除软件危机的途径

例题

例1：2018年3月20日凌晨，亚利桑那州坦佩市（Tempe, Arizona）一辆正在进行自动驾驶测试的UBER测试车撞到一名女子，并且该女子在送往医院后就不治身亡，这也成为自动驾驶汽车全球首例致行人死亡事故。事发时，Uber的无人车传感器已经探测到这位正在横穿马路的行人，但自动驾驶软件没有在当下采取避让措施。上述案例体现了软件危机的哪种具体表现？

正确答案（C）

• A、软件维护困难
• B、软件工期拖延、成本超支
• C、软件质量难以保证

例2：System/360是IBM在1964年4月7日推出的划时代的大型电脑，这一系列是世界上首个指令集可兼容计算机。IBM360系统一共写出了100万行源程序，但发行的每一新版本都是上一版1000个错误的修正。这体现了软件危机的哪种具体表现？

正确答案（A）

• A、软件维护困难
• B、软件开发工期拖延、成本超支
• C、软件质量难以保证
• D、软件需求经常变化

例3：软件危机的产生原因之一是误认为软件开发就是写程序并设法使之运行

正确答案（A）

• A、√
• B、×

例4：（多选题）《荀子·劝学》中说：“假舆马者，非利足也，而致千里；假舟楫者，非能水也，而绝江河。君子生非异也，善假于物也。”，如何理解这句话？

正确答案（ABC）

• A、在软件开发和维护的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，可以把这类工作做得既快又好。
• B、软件工程支撑环境是把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，可以提高软件开发的效率和质量。
• C、应对软件危机，就要鸠工庀材，善假于物，应该开发和使用更好的软件工具。
• D、利用软件工具可以解决软件危机中的一切问题。

二、软件工程

1.软件工程的定义:

2.软件工程的本质特性

例题

3.软件工程的基本原理

例题

4.软件工程方法学

定义:把软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为泛型

5.软件工程方法学包含三个要素

1. 方法：怎莫作

2. 工具：运行方法所提供的软件工程支撑环境

3. 过程：为获得高质量软件所需要的一系列任务框架

6软件工程方法学分类：

6.1传统方法学

速记：结构化、阶段

6.2面向对象方法学

速记：数据、对象、层次结构、类

7.软件生命周期

8.软件过程：

8.1瀑布模型

8.2改进的瀑布模型

8.3快速原型模型

8.4增量模型

8.5风险更大增量模型

8.6螺旋模型

8.7喷泉模型

8.8其他模型

速记

• 瀑布模型：按照固定顺序连接若干阶段
• 快速原型模型：能看到软件的概貌
• 螺旋模型：包含风险分析
• 增量模型：将项目分为几个版本发布，非整体开发
• 喷泉模型：采用面向对象的方法开发
• 敏捷过程模型：采用把软件开发分为多个短周期，多次迭代的方式开发
• Rational统一过程模型：分为若干阶段，每个阶段用标准的UML语言进行编写

例题

下图展示的是哪种软件过程模型？（ ）

正确答案（B）

• A、快速原型模型
• B、瀑布模型

三、可行性研究

1.可行性研究过程

目的：用最小的代价在最小的时间内确认问题是否能够解决

实质：系统分析和设计过程的大大压缩和简化，在较高层次上以较为抽象的方式进行系统的分析和设计过程。

过程：

例题

2.可行性研究步骤

3、数据流图与数据字典

3.1数据流图

数据流图例题

例1

例2

例3

3.2数据字典

数据字典例题

4、成本效益分析

四、需求分析：

4.1需求分析的任务

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

4.3分析模型与规格说明

五、图形类工具

实体联系图

例1

状态转换图

例1

例2

结构图

例1

程序流程图和盒图

例题

类图

例题

例1

例2

时序图

用例图

例题

例1

例2

其他图形工具

优点：随着结构的逐步精细，对数据结构的描绘也越来越详细

优点：简略描绘系统的主要算法

验证软件需求：

六、总体设计

6.1模块化及模块化思想

1. 结构化设计：结构化设计(Structured Design, SD)，是一种面向数据流的设计方法，目的在于确定软件的结构。

2. 模块及模块化思想：

   • 系统的模块数目增加，每个模块的规模减小，开发单个模块的成本减小，但是，随着模块数目增加，设计模块间接口的工作量增也加。

   • 采用模块化原理可以使软件结构更加清晰，更加易于阅读和理解

   • 逐步求精中每一层中的模块都是对系统抽象层次的一次精化

   • 信息隐藏与局部化

6.2内聚和耦合

耦合定义

耦合（Coupling）是指不同模块之间相互依赖程度的度量。

常见耦合类型（由强到弱）

1. 内容耦合：
   • 定义：一个模块直接修改或操作另一个模块的数据。
   • 举例：在模块A中定义了某个变量，在模块B中直接使用了该变量。
2. 公共耦合：
   • 定义：两个以上的模块共同引用一个全局数据项。
   • 举例：我们定义了全局变量a，在模块、模块B和模块C中均使用到了此变量a。
3. 控制耦合
   • 定义：一个模块向另一模块传递一个控制信号，接收信号的模块将依据该信号值进行必要的活动。
   • 举例：模块A实现了统计最近三天以及最近七天销量的功能，而具体执行哪种统计由传入的控制参数决定，则该模块具有控制耦合。逻辑内聚的模块调用就是典型的控制耦合。
4. 标记耦合
   • 定义：两个模块至少有一个通过界面传递的公共参数，包含内部结构，如数组、字符串等。
   • 举例：模块A向模块B传递数组类型数据。
5. 数据耦合
   • 定义：模块间通过参数传递基本类型的数据。
   • 举例：模块A实现两个数的加法操作，模块B实现数字的初始化，模块B将数字传递给模块A，由模块A完成加法。

耦合原则

如果模块间必须存在耦合，就尽量使用数据耦合、少用控制耦合、限制公共耦合的范围以及坚决避免使用内容耦合。

内聚定义

内聚（Cohesion）是指一个模块之内各成分之间相互依赖程度的度量。

常见内聚类型（由低到高）

1. 偶然内聚
   • 定义：一个模块之内各成分之间没有任何关系，只是把分散的功能整合到了一起。
   • 举例：A模块中有三条语句（一条赋值，一条求和，一条传参），表面上看不出任何联系，但是B、C模块中都用到了这三条语句，于是将这三条语句合并成了模块A。模块A具有偶然内聚。
2. 逻辑内聚
   • 定义：几个逻辑上相关的功能放在同一模块中。
   • 举例：模块A实现了统计最近三天以及最近七天销量的功能，而具体执行哪种统计由传入的控制参数决定，则模块A具有逻辑内聚。
3. 时间内聚
   • 定义：一个模块完成的功能必须在同一时间内完成，而这些功能只是因为时间因素关联到一起。
   • 举例：模块A实现了全部全局变量的初始化操作。模块A这种初始化模块就具有时间内聚。
4. 过程内聚
   • 定义：处理成分必须以特定的次序执行。
   • 举例：模块A依次读取用户的用户名、密码和地址信息，并且这个次序是事先规定的，则模块A具有过程内聚。
5. 通信内聚
   • 定义：各成分都操作在同一数据集或生成同一数据集。
   • 举例：模块A根据员工生日分别计算员工年龄和退休日期，则模块A具有通信内聚。
6. 顺序内聚
   • 定义：各成分与一个功能相关，且一个成分的输出作为另一成分的输入。
   • 举例：模块A根据员工生日计算员工年龄，再根据员工年龄计算退休日期，则模块A具有顺序内聚。
7. 功能内聚
   • 定义：模块的所有成分对完成单一功能是最基本的，且该模块对完成这一功能而言是充分必要的。
   • 举例：模块A根据员工生日计算员工年龄。

6.3启发规则

什么是启发式

启发式是根据设计准则，从长期的软件开发实践中，总结出来的规则。它既不是设计目标，也不是设计时应普遍遵循的的原理。

常见的启发规则

1.改进软件结构提高模块独立性

设计出软件的初步结构以后，应该审查分析这个结构，通过模块分解或合并，力求降低耦合提高内聚。例如，多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时可以通过分解或合并模块以减少控制信息的传递及对全程数据的引用，并且降低接口的复杂程度。

2.模块规模应该适中

过大不易理解；太小则接口开销过大。
经验表明，一个模块的规模最好能写在一页纸内(通常不超过60行语句)。

3.深度、宽度、扇出和扇入都应适当

深度：表示软件结构中控制的层数。
深度能粗略地标志一个系统的大小和复杂程度，深度和程序长度之间有粗略的对应关系
宽度：表示软件结构中控制的总跨度。
宽度是同一个层次上的模块总数的最大值，宽度越大系统越复杂；对宽度影响最大的因素是模块的扇出。
扇出：表示一个模块直接控制(调用)的模块数目扇出为3-4，上限扇出为5-9。
扇入：表示有多少个上级模块直接调用该模块扇入越大则共享该模块的上级模块数目越多。

4.模块的作用域应该在控制域之内

模块的控制域：这个模块本身以及所有直接或间接从属于它的模块的集合。
模块的作用域：受该模块内一个判定影响的所有模块的集合。
在一个设计得很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。

5.力争降低模块接口的复杂程度

模块接口复杂是软件发生错误的一个主要原因。应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。接口复杂或不一致(即看起来传递的数据之间没有联系)，是紧耦合或低内聚的征兆，应该重新分析这个模块的独立性。接口复杂可能表明模块的独立性差。

6.设计单入口单出口的模块

这条启发式规则警告软件工程师不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时，软件是比较容易理解的，因此也是比较容易维护的。

7.模块功能应该可以预测

模块的功能应该能够预测，但也要防止模块功能过分局限。

• 相同输入必产生相同输出
• 反例：模块中使用全局变量或静态变量，则可能导致不可预测。

七、详细设计

1.判定树

概念

判定树（Decision Tree）是一种描述加工的图形工具，适合描述问题处理中具有多个判断，而且每个决策与若干条件有关。使用判定树进行描述时，应该从问题的文字描述中分清哪些是判定条件，哪些是判定的决策，根据描述材料中的联结词找出判定条件的从属关系、并列关系、选择关系，根据它们构造判定树。

案例介绍

在网上商城系统中，管理员可以查看具体库存情况。详细描述如下：

1. 若库存量小于等于0，则按缺货处理；否则，若库存量小于等于库存下限，则按下限报警处理；
2. 若库存量大于库存下限，而又小于等于储备定额，则按订货处理；
3. 若库存量大于库存下限，小于库存上线，而又大于储备定额，则按正常处理；
4. 若库存量大于等于库存上线，而又大于储备定额，则按上限报警处理。

2.判定表

判定表（Decision Table）分为四部分：

1. 判定表的左上部，会列出各种可能的条件；
2. 判定表的左上部，称为基本动作项，它列出了所有的操作；
3. 判定标的右上部，称为条件项，它列出了各种可能的条件组合；
4. 判定标的右下部，称为动作项，它列出在对条件组合下所选的操作。

案例介绍

商城管理员根据用户欠款时间长短和现有库存情况处理用户订货的方案。

1. 对于欠款时间小于等于30天的客户，若其需求量小于库存量，则立即发货；若库存量不足，则按库存发货，进货后再补发。
2. 对于欠款时间大于30天且小于等于100天的客户，若其需求量小于库存量，则通知其先付款再发货；若库存量不足，则不发货。
3. 对于欠款时间大于100天的客户，通知其先付欠款再议。

3.PAD图

概念

PAD是Problem Analysis Diagram的缩写，它是日本日立公司提出，由程序流程图演化来的，用结构化程序设计思想表现程序逻辑结构的图形工具。

详细画法

案例介绍

用户在完成登陆后，可以进入到购物界面。在购物界面中，用户可以挑选商品，并且将商品加入到购物车中。之后用户可以选择是否停止购物，选择是会返回购物界面；选择否会进入确认订单页面。至此新建订单操作完成。
该模块的程序流程图如下：

4.NS图

N-S图

N-S图，也被称为盒图或 NS 图（Nassi Shneiderman图），是结构化编程中的一种可视化建模。

N-S图特点

• NS图形象直观，功能域明确，具有良好的可见度；
• 很容易确定局部和全局数据的作用域；
• 不可能任意转移控制；
• 很容易表示嵌套关系及模块的层次关系；
• 复杂度接近代码本身，修改需要重画整个图；
• 它强制设计人员按SP方法进行思考并描述他的设计方案，因为除了表示几种标准结构的符号之处，它不再提供其他描述手段，这就有效地保证了设计的质量，从而也保证了程序的质量。

N-S图解结构

案例介绍

用户进入用户登陆界面后，系统会提示用户曾经是否注册过账号。

1. 若未注册过账号，则需进行新用户注册，之后再进行登陆操作；
2. 若注册过账号，则直接填写完用户密码即可。之后点击登录按钮，通过密码审核即登录成功，否则重新执行用户登录操作。
3. 登陆成功后，即进入购物界面，在购物界面中，用户可以选择关键字检索、分类商品、最新商品、推荐商品功能。
   该模块的程序流程图如下：

八、实现

1.编码

编程语言选择标准

1. 性能要求：

   如果所开发的软件的对性能有很高的要求，或者计算开销较大，那么最好使用静态的、可编译的语言，如C#，Java等。

2. 用户的要求。
   如果是用户来负责维护将来开发出来的软件，则用户一般要求使用他们熟悉的语言编写程序。

3. 软件的运行平台。
   软件的运行平台往往限制了编程语言的选择，如果目标运行平台不支持你想要的语言，那么你就不能使用它，如在嵌入式编程中选择51单片机，则不能使用Python语言。

4. 程序员的知识。
   在科学合理的原则下，我们最好选择开发人员熟悉的编程语言。如果开发人员对某一种语言比较熟悉，就可以很好地预测开发时间、开发过程等内容，避免大的未知变数，提高开发效率。

5. 软件的可移植性要求。
   如果将来开发的软件要在不同系统平台运行，就要使用可移植性好的语言，如Java、Golang等。

6. 软件的应用领域。
   各种语言都有自己的适用范围，通用设计语言并不是适用于所有领域，如嵌入式平台、IOS平台。有许多特定的领域有自己的专用语言。比如：财务分析、文本解析、科学计算、实时领域、服务器、人工智能等。使用领域的专用语言可以减少很多工作量，提高编程效率。

2.软件测试基础

软件测试的目标

G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。

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

测试目标决定了测试方案的设计：

1. 如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；
2. 如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

软件测试的准则

基本准则：

1. 所有测试都应该能追溯到用户需求：
   从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。
2. 应该远在测试开始之前就制定出测试计划：
   因为一旦完成了需求模型就可以着手制定测试计划，建立设计模型后就可立即开始设计详细的测试方案。所以在编码之前就可对所有测试工作进行计划和设计。
3. 把Pareto原理应用到软件测试中:
   测试发现的80%错误很可能是由程序中20%的模块造成的。
4. 应该从“小规模”测试开始，逐步进行“大规模”测试:
   单个程序模块 ➔ 集成的模块簇 ➔ 整个系统
5. 穷举测试是不可能的:
   穷举测试: 把程序所有可能的执行路径都检查一遍。
   即使是一个中等规模的程序，其执行路径的排列数也十分庞大，由于受时间、人力和资源的限制，在测试过程中不可能执行每个可能的路径。因此，测试只能证明程序中有错误，不能证明程序中没有错误。但是，精心地设计测试方案，有可能充分覆盖程序逻辑并使程序达到所要求的可靠性。
6. 为达到测试最佳效果，应由独立的第三方从事测试工作:
   最佳效果:有最大可能性发现错误的测试。
   开发软件的软件工程师主要承担模块测试工作。

软件测试的方法

（1）黑盒测试（Black-box Testing）

已经知道了产品应该具有的功能，通过测试检验是否每个功能都能正常使用。
黑盒测试又称功能测试,把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。

在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。

（2）白盒测试（White-box Testing）

知道产品的内部工作过程，通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。

白盒测试又称为结构测试，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。

黑盒测试是从用户观点的测试，白盒测试是从开发人员观点的测试。

软件测试的步骤

（1）单元测试（Unit Testing）

在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。

目的：保证每个模块作为一个单元能正确运行。
所发现的错误：往往是编码和详细设计的错误。

（2）子系统测试（Subsystem Testing）

把经过单元测试的模块放在一起形成一个子系统来测试。

测试过程中的主要问题：模块相互间的协调和通信。
测试重点：模块的接口。

（3）系统测试（System Testing）

把经过测试的子系统装配成一个完整的系统来测试。’

’
测试目的：
a.发现设计和编码的错误。
b.验证系统确实能提供需求说明书中指定的功能。
c.系统的动态特性符合预定要求。
子系统测试、系统测试，通常称为集成测试。

（4）验收测试（Acceptance Testing）

把软件系统作为单一的实体进行测试。
测试内容与系统测试基本类似，但它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试，发现的往往是系统需求说明书中的错误。

测试目的：验证系统确实能够满足用户的需要。

（5）平行运行（Parallel Operation）

同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。

这样做的具体目的有如下几点：
a.可以在准生产环境中运行新系统而又不冒风险；
b.用户能有一段熟悉新系统的时间；
c.可以验证用户指南和使用手册之类的文档；
d.能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

3.白盒测试

• 逻辑覆盖：每个语句至少执行一次
• 判定覆盖：每个判定的每个分支都至少执行一次
• 条件覆盖：每个语句至少执行一次，而且使判定表达式的每个条件都取到各种可能的结果

九、维护

定义

在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

软件维护的原因

• 改正在特定使用条件下暴露出来的一些潜在程序错误或设计缺陷；
• 因在软件使用过程中数据环境发生变化（如所要处理的数据发生变化）或处理环境发生变化（如硬件或软件操作系统等发生变化），需要修改软件，以适应这种变化；
• 用户和数据处理人员在使用时常提出改进现有功能、增加新功能、以及改善总体性能的要求，为满足这些要求，需要修改软件。

四类软件维护的活动

• 改正性维护：交付给用户使用的软件，即使通过严格的测试，仍可能有一些潜在的错误在用户使用的过程中发现和修改。诊断和改正错误的过程称为改正性维护。
• 适应性维护：随着计算机的飞速发展，新的硬件系统和外部设备时常更新和升级，一些数据库环境、数据输入/输出方式、数据存储介质等也可能发生变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。
• 完善性维护：在软件投入使用过程中，用户可能还会有新的功能和性能要求，可能会提出增加新功能、修改现有功能等要求。为了满足这类要求而进行的维护称为完善性维护。
• 预防性维护：为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而进行的修改，称为预防性维护。这种维护活动在实践中比较少见。

软件维护的特点

1. 结构化维护与非结构化维护的差别巨大
2. 软件维护的代价高昂
3. 维护的问题很多

决定软件可维护性的因素

软件可维护性是：维护人员理解、改正和改进软件的难易程度。
一个软件的可维护性，主要由五个因素决定：

• 可理解性：可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。
• 可测试性：在设计开发阶段应该注意尽量把软件设计成容易测试和容易诊断的，可用的测试工具和调试工具对测试和诊断非常重要。
• 可修改性：软件的可修改程度与软件设计阶段采用的原则和策略是直接相关的。如：模块的耦合、内聚、控制范围和作用范围、局部化程度都直接影响软件的可修改性。
• 可移植性：软件可移植性指的是，把程序从一种计算环境 （硬件配置和操作系统） 转移到另一种计算环境的难易程度 。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。
• 可重用性：很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的 可重用构件越多，适应性和完善性维护也就越容易 。

决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的好坏。提高软件的可维护性是软件工程的一个重要目标。

影响维护工作量的因素

1. 系统大小。系统越大，功能越复杂，理解掌握起来就越困难，需要的维护工作量越大。
2. 程序设计语言。使用功能强的程序设计语言可以控制程序的规模。语言的功能越强，生成程序所需的指令数就越少；语言的功能越弱，实现同样功能所需的语句就越多，程序就越大，维护起来就越困难。
3. 系统年龄。老系统比新系统需要更多的维护工作量。许多老系统在当初并未按照软件工程的要求进行开发，没有文档，或文档太少，或者在长期的维护中许多地方与程序不一致，维护起来困难较大。
4. 数据库技术的应用。使用数据库工具，可有效地管理和存储用户程序中的数据，可方便地修改、扩充报表。数据库技术的使用可以减少维护工作量。
5. 先进的软件开发技术。在软件开发时，如果使用能使软件结构比较稳定的分析与设计技术（如面向对象分析、设计技术），可以减少一定的工作量。
6. 其它。如，应用的类型、数学模型、任务的难度、IF嵌套深度等等都会对维护工作量产生一定的影响。

逆向工程和软件再工程的区别

软件再工程（Re-engineering）， 再工程不仅能从已有的程序中重新获得设计信息，而且还能使用这些信息改建或重构现有的系统。

都直接影响软件的可修改性。

• 可移植性：软件可移植性指的是，把程序从一种计算环境 （硬件配置和操作系统） 转移到另一种计算环境的难易程度 。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。
• 可重用性：很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的 可重用构件越多，适应性和完善性维护也就越容易 。

决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的好坏。提高软件的可维护性是软件工程的一个重要目标。

影响维护工作量的因素

1. 系统大小。系统越大，功能越复杂，理解掌握起来就越困难，需要的维护工作量越大。
2. 程序设计语言。使用功能强的程序设计语言可以控制程序的规模。语言的功能越强，生成程序所需的指令数就越少；语言的功能越弱，实现同样功能所需的语句就越多，程序就越大，维护起来就越困难。
3. 系统年龄。老系统比新系统需要更多的维护工作量。许多老系统在当初并未按照软件工程的要求进行开发，没有文档，或文档太少，或者在长期的维护中许多地方与程序不一致，维护起来困难较大。
4. 数据库技术的应用。使用数据库工具，可有效地管理和存储用户程序中的数据，可方便地修改、扩充报表。数据库技术的使用可以减少维护工作量。
5. 先进的软件开发技术。在软件开发时，如果使用能使软件结构比较稳定的分析与设计技术（如面向对象分析、设计技术），可以减少一定的工作量。
6. 其它。如，应用的类型、数学模型、任务的难度、IF嵌套深度等等都会对维护工作量产生一定的影响。

逆向工程和软件再工程的区别

软件再工程（Re-engineering）， 再工程不仅能从已有的程序中重新获得设计信息，而且还能使用这些信息改建或重构现有的系统。

逆向工程（Reverse Engineering），用于软件的起始建造阶段，而Re-engineering用于软件后续的修改阶段。