《软件工程》

1、第一章 软件工程概述思考题

1.1 结合你之前的工程经验以及任正非致员工信，谈谈你对软件工程的看法？

软件工程运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。是开发、运行、维护和修复软件的系统方法，为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则。

我认为软件工程在我们的开发过程中起着至关重要的作用，需要在满足各方面需求并保证软件效率的前提下，统筹管理好开发过程的每一步，以最少的人力物力耗费来实现期望的目标。

1.2 软件开发就是编码么？谈谈你对软件开发的本质的认识？

软件开发包含编码但不是仅有编码，编码只是软件开发中的一小部分，软件开发是一个涵盖了需求分析、设计、实现、部署等一系列过程的完整体系。我认为在软件开发的过程中，各部门之间的沟通才是最重要的，都达成统一之后才能更好的满足客户的需求。

1.3 举例说明软件的特点有哪些？

• 复杂性（Complexity）: 大型软件百万行源代码，上万个文件；模块间各种显性和隐性的依赖关系。
• 不可见性（Invisibility）：软件执行时，无法看到源代码的执行；软件出错很难完整重现程序出现的问题。
• 服从性（Conformity）：软件服从于硬件、服从于用户需求、行业系统要求。
• 易变性（Changeability）：比硬件容易修改，但正确修改难。

1.4 什么是软件危机？软件危机出现的原因及解决手段有哪些？

软件危机 : 是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

软件危机出现的原因：

• 用户需求不明确
• 缺乏正确的理论指导
• 软件开发规模越来越大
• 软件开发复杂度越来越高

解决手段：

• 重视需求分析，与客户的沟通，确切表达需求
• 重视设计和实现过程的资料
• 充分的测试工作
• 维护和管理工作
• 统一的、公认的方法论和规范指导

1.5 软件工程的要素有哪些？各有什么作用？

软件工程的要素是：方法 、过程 和 工具

作用：

• 方法是技术手段
• 过程是任务框架和步骤
• 工具是支撑环境

2、第二、三章 软件过程和软件过程模型思考题

2.1 简述软件简述软件过程、软件生存周期、软件过程模型（软件生存周期模型）三者之间的概念区别?

(1)软件过程：

• 软件生存周期中的一系列相关过程所涉及的活动。
• 过程是活动的集合。
• 活动是任务的集合。
• 任务是将输入转换为输出的操作

(2)软件生存周期：

• 软件也有一个从生到死的过程，这个过程一般称之为软件的软件生存周期或生命周期（Software Development Life Cycle）
• 软件生存周期可划分为定义、开发和运行三个时期，每个时期又细分为若干个阶段。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。
• 软件生存周期包括可行性分析、项目计划、需求分析、软件设计、编码与测试、运行与维护等阶段，每个阶段又包含一系列的活动。

(3)软件过程模型（软件生存周期模型）:

• IEEE 12207.0-1996 定义：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从系统的需求定义到系统的使用终止。
• 软件生存周期模型是一种软件过程的抽象表示，也称为软件开发模型。
• 软件生存周模型一般使用直观的图形标识软件开发的过程，主要根据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立过程模型。

2.2 软件过程就是软件开发过程么？为什么？

软件过程又称为软件生存周期过程，其不等于软件开发过程，因为软件过程知识软件生存周期中的一系列相关过程所涉及的活动，所以软件过程知识软件开发过程中的一部分，两者并不等同。

2.3 请选择两个常见的软件过程模型，谈谈你对它们的理解？并对它们进行比较。

瀑布模型

将软件生命周期划分为软件计划、需求分析和定义、设计、实现、测试、运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。

螺旋模型

是结合了瀑布模型和快速原型模型的迭代开发模型，强调了其他模型均忽略了的风险分析，包括风险识别、风险分析和风险控制，特别适合于大型复杂的系统。每一个周期都包括需求定义、风险分析、工程实现和评审。

比较

• 瀑布模型强调保证软件的质量，忽略一些其他的外在的风险影响，以质量为首要目标，当需求发生变更时大概率需要从头再来，该模型比较适合一些大型稳定的项目。
• 螺旋模型是结合了瀑布模型和快速原型模型的迭代开发模型，以进化的开发方式为中心，每个项目阶段使用瀑布模型法。

2.4 瀑布模型和其他常见模型有什么关联和区别？

• 原型模型利用原型法技术尽可能快地构造一个实际系统的简化模型。实现一个基本原型，让用户对原型进行评价，逐步调整，使其满足用户最终需求。
• 增量模型中某些阶段按照瀑布模型的整体方式开发；某些阶段按照增量方式开发，即融合了瀑布模型的基本成分和原型实现的迭代特征
• 螺旋模型由Barry Boehm提出，是结合了瀑布模型和快速原型模型的迭代开发模型

2.5 根据你当前所在的团队项目，你更倾向于选择哪一种软件过程模型？为什么？

螺旋模型，因为该模型结合科瀑布模型和快速原型模型，在每一个周期都会包括需求定义、风险分析、工程实现和审评，有利于我们后期进行更多功能的添加和修改。

3、第五章 软件需求分析思考题

3.1 需求分析的目的是什么，有什么作用？

• 目的：要求开发人员准确地理解用户需要什么，进行细致地调查分析，将用户的需求陈述转化为完整的需求定义，再由需求定义转化为相应的软件需求规格说明。

• 作用：深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。需求分析虽处于软件开发的初期阶段，但它对于整个软件开发过程以及产品质量至关重要。

3.2 软件需求有哪些分类？请举例说明。

• 业务需求（Business requirement）：反映了组织机构或客户对系统、产品高层次的目标要求。从组织或者客户的角度，实质就是业务的建设方；比如房地产市场的开发商
• 用户需求（user requirement）：用户的目标，或用户要求系统必须能完成的任务。从使用产品的用户的角度；比如买房的人
• 功能需求（ functional requirement）：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。从产品本身的角度，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求；比如房子。
• 非功能需求（non-functional requirements）：非功能需求主要与系统的总体特征相关，是一些限制性要求，是对实际使用环境所做的要求。

3.3需求分析有哪些步骤？

步骤包括：

沟通、导出需求、与客户和用户协商、可行性研究、精化需求、编写需求规格说明、验证需求、管理需求

3.4需求获取方法有哪些？

会谈技术：

• 非正式会谈：提出一些可自由回答的问题。
• 正式会谈：提出一些事先准备好的议题。

调查技术

• 确定调查内容：非正式会谈、制定调查表、组织调查
• 可靠可信分析：检查问卷指标是否合理、指标之间是否存在关联、结果是否可信

场景分析技术

• 场景：用户与软件系统交互的过程
• 分析员与项目相关人员共同识别出场景，并捕获这些场景的细节。
• 场景是对交互实例片段的描述，每个场景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型场景的信息。
• 情景开始于一个框架，在导出过程中，细节被逐渐增加，知道产生交互的一个完整的描述。

3.5你所在的项目团队会选择采取哪些需求获取方法？请具体实践获取需求，在博客中展示（问卷调查表或会谈照片、小视频等）。并总结获取的功能需求以及非功能需求。

具体见团队博客

4、第六章 结构化分析方法思考题

4.1 结构化分析的特点是什么？

结构化分析的特点是采用自顶向下、逐层分解的方法求解复杂问题。

4.2 数据流图的建模元素有哪些？如何构建数据流图？有哪些注意事项？

建模元素：
数据的源点或终点、加工或处理、数据存储、数据流

如何构建数据流图：

1. 先确定系统的输入输出，构建顶层DFD；
2. 对顶层DFD图细化，构建0层DFD；
3. 对0层DFD的每个加工进行细化，分别构建1层DFD，依次类推，逐层精化，直至构建出底层图

注意事项：

• 命名：数据流图中每个元素必须有名字，且命名合理。
• 加工名字应该反映整个加工的功能，而不是一部分功能。加工命名一般为动词+名词短语。
• 数据流名字应该代表整个数据流的内容，而不是仅仅反映它的某些成分。数据流命名为名词。
• 画数据流不是画控制流。数据流图反映的是系统“做什么”，不反映“如何做”。
• 每个加工至少有一个输入数据流和一个输出数据流，反映出此加工数据的来源与加工的结果。

4.3 数据字典有哪些要素（条目）定义？

数据字典应该由四类元素的定义组成

• 数据流条目
• 数据存储条目
• 数据项条目（数据流或数据存储分量）
• 加工条目

4.4请采用面向数据流的方法对你所在团队项目的功能需求进行建模。

具体见项目文档

5、第七章 软件设计思考题

5.1 软件设计的目标及主要任务有哪些?

目标：

• 软件系统设计是把软件需求“变换”为用于构造软件的蓝图。“输入”是需求分析各种模型元素，“输出”是软件设计模型和表示
• 软件设计阶段的基本目标是构造系统“怎么做”的模型描述。
  “- 设计先于编码”，这是软件工程“推迟实现”基本原则

主要任务：

• 总体设计，也称为概要设计，软件结构设计，或高层设计。体系结构设计：定义软件模块(构件)及模块之间的关系；接口设计：包括用户接口（界面）、外部接口、内部接口；数据设计：软件涉及的数据结构、文件系统的结构、数据库的表结构等。
• 软件详细设计，也称为（模块）过程设计，或低层设计；模块内部细节设计：包括模块所需的算法和数据结构等

5.2什么是模块（构件）化设计思想？

把一个大型软件系统的全部功能，按照一定的原则合理地划分为若干个模块，每个模块完成一个特定子功能，所有的这些模块以某种结构形式组成一个整体，这就是软件的模块化设计（Modular
Design）

分解、抽象、逐步求精、信息隐蔽和模块独立性，是软件模块化设计的指导思想。

5.3模块独立性的两个度量标准是什么？

• 模块自身的内聚（Cohesion），也称为块内联系，指一个模块内部元素彼此结合的紧密程度。
• 模块之间的耦合（Coupling)，也称为块间联系。

5.4 内聚和耦合的含义是什么？各有那些种类？请举例说明每一类型。

（1）内聚性是从功能的角度对模块内部聚合能力的量度。

高内聚是模块独立性追求的目标：

• 功能性内聚：模块各个成分结合在一起，完成一个特定的功能。功能性模块具有内聚性最强、与其他模块联系少的特点。例如: 解析XML文档模块（解析XML元素, 解析XML属性，解析XML注释等）
• 顺序性内聚：模块内的各个任务是顺序执行的。通常，上一个任务的输出是下一个任务的输入。例如: 规则引擎：一个任务读配置，输出执行计划。另一个任务以执行计划为输入，执行该计划。通常，面向数据流的设计方法设计出的模块具有顺序性内聚。

中内聚:

• 通信性内聚（信息内聚）：模块内部的各个任务靠公用数据联系在一起，即都使用同一个输入数据，或者产生同一个输出数据。例如：学生管理系统的数据库CRUD操作，都对学生信息进行增删查改操作。
• 过程性内聚：模块内的各个任务必须按照某一特定次序执行。在函数级别的模块比较常见。例如：读/写文件操作：判断文件是否存在、判断文件是否有相应权限、打开文件、读（或写）文件。

低内聚：

• 时间性内聚：模块内的各个任务由相同的执行时间联系在一起。例如：初始化模块，异常处理模块。某个异常处理模块封装了“释放资源”、“记录日志”、“通知用户”几个任务。
• 逻辑性内聚：模块通常由若干个逻辑功能相似的任务组成，通过模块外引入的一个开关量选择其一执行。这种内聚增大了模块间的耦合。例如：一个输出设备模块将打印机类和显示器类封装到同一个包里，该包即输出设备模块。打印机类和显示器类虽然都具有输出功能，但是具有不同的职责。
• 偶然性内聚：模块内的各个任务在功能上没有实质性联系，纯属“偶然”因素组合了块内各个互不相关的任务。例如：一个处理正方形的模块有两个功能：计算面积，画出这个正方形。

（2）耦合性是对一个软件结构内不同模块之间互连程度的度量。

耦合性的强弱取决于模块间接口的复杂程度，以及通过接口的数据类型和数目。弱耦合是模块独立性追求的目标。

弱耦合：

• 非直接耦合：同级模块相互之间没有信息传递，即没有耦合。非常底层的模块，自给自足，可以无耦合。较高层的模块，通常需要重用其他模块的功能，产生耦合。
• 数据耦合：调用下属模块时，如果交换的都是简单变量，便构成数据耦合。 要点：通过参数传递，而不是通过全局数据、配置文件、共享内存等其他方式；传递的是基本数据类型，不是数据结构。
• 特征耦合（数据结构耦合）：调用下属模块时，如果交换的是数据结构，便构成特征耦合。由于传递的是数据结构，不仅数据量增加，而且会使模块的相关性增加。

中耦合：

• 控制耦合：模块间传递的信息不是一般的数据，而是作为控制信息的开关值或标志量。例如，逻辑性内聚的模块调用就是典型的控制耦合。

较强耦合：

• 外部耦合：若允许一组模块访问同一个全局变量，可称它们为外部耦合。
• 公共耦合：若允许一组模块访问同一个全局性的数据结构，则称它们为公共耦合。全局性的数据结构可以是共享的通信区、公共的内存区域、任何存储介质文件、物理设备等。

强耦合：

• 内容耦合：若一个模块可以直接访问另一个模块中的内部数据，或者一个模块直接转到另一个模块的内部，或者一个模块有多个入口，则称为内容耦合。

5.5 为什么要高内聚和低耦合？高内聚低耦合是否意味着内聚越高越好，耦合越低越好呢？

高内聚低耦合是基于面向对象思想的概念。首先面向对象的主要特点是封装、继承和多态。实质上是将本来混乱的代码尽可能的抽象出共性，分门别类。最终达到复用，提高开发效率和保证软件质量的目的。面向对象追求的是代码复用和运行稳定，即在模块之间减少联系。可以想象，如果各模块之间联系太过紧密对于代码复用是不容易的，因为很难会再找到同样适合的环境。同时对于运行来说也是不利的，软件发生错误是不可避免的，那么各模块如果联系紧密则错一处而动全身，好比多米诺骨牌。所以一个好的软件各模块之间的联系不能过分紧密，即低耦合。

6、 第八章 结构化设计思考题

6.1 软件结构图的形态特征有哪些指标？各有什么含义？

• 深度：指结构图控制的层次，即模块的层数。
• 宽度：指一层中最大的模块个数。
• 扇出：指一个模块直接下属模块的个数。
• 扇入：指一个模块直接上属模块的个数。

6.2 软件结构有哪些优化原则？

• 模块独立性准则 ：划分模块时，尽量做到高内聚、低耦合，保持模块相对独立性，以此原则优化初始的软件结构。
• 软件结构的形态特征准则 ：软件结构的深度、宽度、 扇入数和扇出数都要适当。
• 模块的大小准则 ：按模块的独立性，即根据模块的功能来决定模块的大小。过大的模块应该进行分解。过小的模块会增加模块间接口的复杂性，可以进行适当的合并，但不应降低模块的独立性。
• 模块控制域与作用域之间的准则 ：一个模块的作用域应在其控制范围之内，且条件判定所在的模块应与受其影响的模块在层次上尽量靠近。
• 模块的接口准则 ：模块的接口要简单、清晰，力求降低模块接口的复杂程度，设计单入口、单出口的模块

6.3 数据流模型的类型有哪些？各有什么特点？

• 变换流：整个数据流体现了以输入、变换、输出的顺序方式，沿一定路径前行的特征，就是变换型数据流，简称变换流。
• 事务流：具有根据条件选择处理不同事务的数据流，就是事务型数据流，简称事务流。
• 混合流：具有将事务流和变换流组合出现，就是混合型数据流，简称混合流。

6.4 简述面向数据流的变换以及事务设计方法的步骤。

1）复查基本系统模型，并精化系统数据流图
2）分析数据流类型，确定数据流具有变换流特征还是事务流特征
3）采用自顶向下、逐步求精的方式完成模块分解，确定相应的软件组成结构
4）根据软件结构优化准则，对导出的软件结构进行优化

6.5 结构化详细设计工具有哪几种？各有什么特点？

• 图形工具：把过程的细节表示成一个图的组成部分，在这个图上，逻辑构造用具体的图形来表示。例如：流程图，盒图，PAD图
• 列表工具：用一个表来表示过程的细节，这个表列出了各种操作及其相应的条件，即描述了输入、处理和输出信息。例如：判定表，判定树
• 语言工具：用伪代码来表示过程的细节，这种伪代码很接近于编程语言。例如：PDL语言

未完待续