软件工程导论考纲知识点

📑对应

复习提纲对应教材为《软件工程（第3版）》，清华大学出版社

软件工程定义

软件工程是应用计算机科学理论和技术以及工程管理原则和方法，安远和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

📑引用

《计算机科学技术百科全书》中的定义

软件危机解释

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

随着计算机在各个领域的广泛应用，软件的需求量越来越大，软件的复杂度也越来越高，导致软件的开发远远满足不了社会发展的需要，超出预算的经费、超过预期的交付时间的事情经常发生。

由于缺乏文档以及没有好的开发方法的指导，使得大量已有的软件难以维护，到20世纪60年代中期出现了人们难以控制的局面，即“软件危机”。

软件生存周期

1. 计算机系统工程

   计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，作出进度安排，并进行可行性分析。

2. 需求分析

   需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成软件需求规约（也称软件需求规格说明）。

3. 设计

   系统设计的任务是设计软件系统的体系结构，详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法。

4. 编码

   编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。

5. 测试

   测试阶段的任务是发现并纠正软件中的错误和缺陷。

6. 运行和维护

   软件交付使用后，在软件运行期间，当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外部环境的变化等情况出现时，对软件进行修改。

典型软件工程模型

1. 瀑布模型

   上一阶段的活动完成并经过评审才能开始下一阶段的活动，接受上一阶段活动的结果作为本阶段活动的输入，依据上一阶段活动的结果实施本阶段应完成的活动，对本阶段的活动进行评审。

2. 演化模型

   从结构初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。

3. 增量模型

   将软件的开发过程分为若干个日程时间交错的线性序列，融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征，特别适用于需求经常发生变化的软件开发。

4. 原型模型

   开发人员和用户在“原型”上达成一致，缩短了开发周期，加快了工程进度，降低成本。

5. 螺旋模型

   将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来，不仅体现了这两种模型的优点，而且增加了风险分析。

6. 喷泉模型

   各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

计算机辅助软件工程（Computer Aided Software Engineer, CASE)定义

计算机辅助软件工程是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施，以确保这些活动能高效率、高质量进行。

软件工具分类

1. 支持软件开发过程的工具

   支持软件开发过程的工具主要有：需求分析工具、设计工具（通常还可以分为概要设计工具和详细设计工具）、编码工具、排错工具、测试工具等。

2. 支持软件维护过程的工具

   支持软软件维护过程的工具主要有：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具等。

3. 支持软件管理过程和支持过程的工具

   支持软件管理过程和支持过程的工具主要有：项目管理工具、配置管理工具、软件评价工具等。

基于计算机的系统定义

基于计算机的系统是指通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。

组成基于计算机的系统的元素

组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程。

系统工程的任务

1. 识别用户的要求

   识别用户对基于计算机的系统的总体要求，标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。

2. 系统建模和模拟

   一个基于计算机的系统通常可考虑建立以下模型：硬件系统模型、软件系统模型、人机接口模型、数据模型。

3. 成本估算及进度安排

   开发一个基于计算机的系统需要一定的资金投入和时间约束（交互日期），需进行成本估算，并作出进度安排。

4. 可行性分析

   主要从经济、技术、法律等方面分析所给出的解决方案是否可行。

5. 生成系统规格说明

   作为以后开发基于计算机的系统的依据。

可行性分析的任务及对应解决的问题

1. 经济可行性

   经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发

   a) 成本

   b) 效益

   c) 货币的时间价值

   d) 投资的回收期

   e) 纯收入

2. 技术可行性

   技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现。技术可行性分析通常包括风险分析、资源分析和技术分析。

   a) 风险分析

   b) 资源分析

   c) 技术分析

3. 法律可行性

   法律可行性主要研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。

4. 方法的选择和折衷

   依据待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等进行方案评估并作出选择。

需求工程阶段及对应具体任务

1. 需求获取：系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析。

2. 需求分析与协商：分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需求对需求进行排序。

3. 系统建模：通过合适的工具和符号系统地描述需求。

4. 需求规约：给出对目标软件的各种需求。

5. 需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。

6. 需求管理：对需求工程所有相关活动的规约和控制。

软件需求定义及分类

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。具体分类如下。

1. 功能需求
2. 性能需求
3. 用户或人的因素
4. 环境需求
5. 界面需求
6. 文档需求
7. 数据需求
8. 资源使用需求
9. 安全保密需求
10. 可靠性需求
11. 软件成本消耗与开发进度需求
12. 其他非功能性需求

需求获取方法与策略

1. 建立顺畅的通信途径

   即在用户、系统分析人员、软件开发小组、管理人员之间建立良好的沟通方式。

2. 访谈与调查

   项目开始前，分析人员从分析已经存在的同类软件产品，或从行业标准、规则中，甚至从Internet上搜索相关资料提取初步需求，然后以个别访谈或小组会议的形式开始与用户进行初步沟通。

3. 观察用户操作流程

   到用户实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

4. 组成联合小组

   打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自长处，共同负责项目推进。

   此方法被称为便利的应用规约技术（Facilitated Application Specification Techniques, FAST)

5. 用况

   用况常称为用例，需求作为非正式会议——FAST的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。

需求协商定义及解决冲突的最快方式

复杂的系统有许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案。

通常会议是解决冲突的最快方式。

需求建模定义及常用的分析方法

创建模型时需求分析阶段重要活动。模型以一种简洁、准确、结构清晰的方式系统地描述软件需求，并成为复审的焦点，还将成为软件设计的基础。

模型着重于描述系统要做什么，而不是如何去做。目标软件的需求模型不应设计软件的实现细节。

常用的分析方法如下。

1. 面向数据流的结构化分析方法(SA)
2. 面向数据结构的分析方法
3. 面向对象的分析方法(OOA)

软件设计工程定义及基本任务

软件设计是把软件需求变换成软件表示的过程，基本任务如下。

1. 数据/类设计：将分析类模型变换成类的实现和软件实现所需要的数据结构。

2. 体系结构设计：定义了软件的整体结构，由软件部件、外部可见的属性和他们之间的关系组成。

3. 接口设计：描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。

4. 部件级设计：将软件体系结构的结构性元素变换为对软件部件的过过程性描述。

软件设计原则

1. 抽象：从特殊到一般的过程
2. 逐步求精：把问题求解过程分解成若干步骤或阶段，每一步都比上一步更精化，更接近问题解法
3. 信息隐蔽
4. 模块独立

模块化相关概念定义及关系

模块是数据说明、可执行语句等程序对象的集合，是单独命名的，并且可以通过名字来访问的。

模块化是指把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。

模块化设计就是程序的编写不是开始就逐条录入计算机语句和指令，而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来，并定义和调试好各个框架之间的输入、输出链接关系。

耦合和内聚定义及关系

1. 耦合

   耦合（coupling）是模块之间的相对独立性（互相连接的紧密程度）的度量，耦合方式如下。

   a) 内容耦合：当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时就发生了内容耦合。此时，被修改的模块完全依赖于修改它的模块。如果发生下列情形，两个模块之间就发生了内容耦合：