第一章 软件工程

  1. 什么是软件?软件的特点?

软件是计算机系统中与硬件相互依存的另一部分;它是包括程序,数据,文档的完整集合

  1. 软件危机的定义

软件开发和维护过程中所遇到的这一系列严重问题为软件危机:

软件十分复杂,价格昂贵,供需差日益则大

软件开发时常受挫,质量差,进度和完成日期不按时,研制失去控制

  1. 软件危机的原因

软件的复杂性:代码量大,系统类型多

软件产品的特殊性:一致性,可变性,不可见性

人们认识的局限性:忽视需求分析,当作编写程序,缺少度量标准,忽视软件维护

  1. 什么是软件工程

将系统化的,规范化的,可度量的方法应用于软件开发,运行,维护的过程,将工程化应用于软件中

软件工程是应用计算机科学,数学及管理科学等原理开发软件的工程。借鉴传统工程的原则,方法,以提高质量降低成本为目的

  1. 软件工程研究的内容是什么

软件工程以关注软件质量为目标,包括过程,方法和工具三个要素

过程:支持软件生命周期的所有活动

方法:为软件开发过程提供“如何做”的技术

工具:为软件开发方法提供自动或半自动的软件支撑环境

  1. 提高软件质量的手段

可靠性:正确性和健壮,正确性和对异常值边界值的处理能力

可维护性:可读性,可修改性,可测试性,完整性

可理解性:简单性,清晰性,可用性

效率:

f28bc3677ad2626ffd1d3ecc81ed92e0.png

  1. 什么是软件生命周期

一个软件被提出开始研制至软件最终被废弃不再使用为止的全过程,成为软件生命期,包括:软件定义,软件开发及软件运行维护

  1. 瀑布模型每一阶段的含义

可行性研究与计划

需求分析

设计

编码

测试

运行维护

  1. 瀑布模型的优缺点

优点:

强调开发的阶段性:阶段间具有顺序性和依赖性

强调早期计划及需求调查:推迟实现的观点

强调评审,强调产品测试:质量保证的观点

缺点:
依赖于早期进行的唯一一次需求调查,不能适应需求的变化

由于是单一流程,开发过程中的经验教训不能反馈于应用于本产品的过程

风险往往迟滞后期的开发阶段才显露,因而失去趁早纠正的机会。

文档驱动的,对于非专业用户难以阅读和理解

  1. 软件生命模型各自的特点

螺旋模型:
1)螺旋模型将瀑布模型与原型模型结合起来,
并且加入两种模型均忽略了的风险分析。

2)螺旋模型沿着螺线旋转,自内向外每旋转一 圈便开发出更完善的一个新版本。 ◆
制定计划 确定软件目标,选定实施方案, 弄清项目开发的限制条件;

◆ 风险分析 分析所选方案,考虑如何识别和 消除风险;

◆ 实施工程 实施软件开发

◆ 客户评估 评价开发,提出修正建议。

增量模型:

1)增量模型是迭代和演进的过程。

2)增量模型把软件产品分解成一系列的增量构件 ,在增量开发迭代中逐步加入。

3)每个构件由多个相互作用的模块构成,并且能够完成特定的功能。

4)早先完成的增量可以为后期的增量提供服务。

5)增量开发方法的新演进版本叫做“极限程序设 计(eXtreme Programming)”

原型模型:

1)原型模型是迭代的。因为软件与所有的复杂系统一样,必须经过不断演化才能完善。

2)原型模型先开发一个“原型”软件,完成部
分主要功能,展示给用户并征求意见,然后 逐步完善,最终获得满意的软件产品。

3)业务和产品需求在变化中,采用线性开发方 式是不实际的。

4)快速实现和提交一个有限的版本,可以应付 市场竞争的压力。

  1. 敏捷模型解决什么问题

敏捷过程为了使软件开发团队具有高效工作和快速响应变化的能力。

  • 快速的市场进入时间,要求高生产率

  • 快速变化的需求,需求模糊且经常改变

  • 快速发展的技术

第二章 可行性研究

  1. 什么是可行性分析

弄清楚要计算机解决的问题根本所在,确定新系统的作用域,以及项目所需资源和经费

  1. 可行性分析的目的

用最小的代价在尽可能短的时间内确定问题能否解决

  1. 可行性分析的内容

经济可行性,技术可行性,操作可行性

步骤:
研究当前正在运行的系统
确定项目的规模和目标
建立新系统的高层逻辑模型
导出和评价各种方案
推荐可行方案
编写可行性研究报告

  1. 什么是人月,人月是什么单位

第三章 需求分析

  1. 需求分析的内容

  2. 需求分析的过程

需求获取

需求分析

规格说明

需求验证:确保需求编写正确。必须全面理解用户的各项要求,准确表达被接受的用户要求。

需求基线

需求管理:管理需求变化的过程,涉及需求变更如何被处理的策略、规程和过程

  1. 需求分析的方法

面向数据的结构化分析法(SA)

面向对象的分析方法(OOA)

  1. 需求报告的作用,需求报告主要内容,写作注意事项

作用:
作为用户和软件人员之间的合同,为双方互相了解提供基础
反映出问题结构,可用作为软件人员进行设计和编写的基础
作为验收的依据,即作为选取测试用例和进行形式验证的依据

内容:

eed66975e449863a439a907df6e10e57.png

注意事项:

简洁:保持语句和段落的简短

一致:需求陈述应该具有一致的样式

必须避免模糊的、主观的术语,减少不确定性

避免使用比较性词汇

不应该把多个需求集中在一个冗长的叙述段落中

  1. 需求文档的质量属性

完整,无二义性,可验证,正确,一致

  1. 结构化分析的分析模型

建立系统的功能模型 利用数据流图(Data Flow Diagram,DFD)将
大问题分割成若干个小问题,采用分层的数据流图,
先建立系统环境图(顶层),再逐步求精。

建立数据字典 采用结构化英语,小说明,补充材料等列出。

  1. E-R图

  2. 数据流图

数据守恒与数据封闭原则

加工分解的原则

子图与父图的“平衡“

合理使用文件

  1. 数据字典

  2. 状态迁移图

描述系统的状态如何响应外部的事件进行推 移的一种图形表示

  1. 判断树,判定表

在某些数据处理中,某数据流图的加工需要依赖于多
个逻辑条件的取值,就是说完成这一加工的一组动作是由
于某一组条件取值的组合而引发的。这时使用判定表来描 述比较合适

判定树是判定表的变种,它也能清晰地表达复杂的条件组
合与所对应的操作之间的关系。判定树的优点在于它无须任
何说明,一眼就能看出其含义,易于理解和使用

第四章 总体设计

  1. 总体设计的内容

将系统划分成模块

决定每个模块的功能

决定模块调用关系

决定模块界面,即模块间传递的数据

  1. 模块化设计的重要指导思想是什么

分解,信息隐蔽,确保模块独立

  1. 什么是耦合,具体哪些耦合方式

耦合是对一个软件结构内不同模块之间互联程度的度量。耦合的强弱取决于模块间接口的复杂程度,进入模或访问一个模块的点以及通过接口的数据

简单耦合

数据耦合

标记耦合

控制耦合

外部耦合

公共耦合

内容耦合

  1. 模块之间联系的原则

尽量使用数据耦合,少使用控制耦合,限制公共耦合范围,完全不用内容耦合

模块间互相调用时,传递参数最好只有一个

  1. 什么是内聚,内聚有哪些类型。设计时因追求什么内聚

内聚标志着一个模块内部各个元素间彼此结合的紧密程度。

功能内聚: 模块内所有处理元素属于一个整体,完成一个单一的功能

顺序内聚:
一个模块内部各个组成部分的处理动作是按顺序执行的,且前一个处理动作和输出数据是下一个处理动作的输入数据

通信内聚:
一个模块内各个组成部分的处理动作都引用相同的输入数据或产生相同的输出数据

过程内聚:
一个模块内部各个组成部分的处理动作各不相同,彼此也没有什么关系,但它们都受同一个控制流支配,决定它们的执行顺序

时间内聚: 一个模块各组成部分,它们处理动作和时间有关

逻辑内聚: 逻辑相关的函数或数据出现在同一个模型里

偶然内聚: 无关的函数,过程或数据出现在同一个模块里

  1. 模块化的基本原则

高内聚,低耦合。内聚比耦合更重要

  1. 模块的评价标准

可分解,可组装,可理解,连续性,保护性

  1. 什么是模块的深度和广度

  2. 扇入于扇出

扇出:一个模块之间调用/控制的模块数 3<=fan-out<=9

扇入:之间调用该模块的模块数 不破坏独立性的前提下,fan-in大的比较好

  1. 控制域作用域

作用域是指该模块中一个判断所影响的所有其它模块

控制域指该模块本身以及所有直接或间接从属于它的模块

  1. 模块设计时的启发式规则

低耦合,高内聚;模块规模适中;适当控制深度宽度;降低接口复杂程度;争取单入单出;模块功能可预测

第五章 详细设计

  1. 详细设计的内容

以总体设计阶段的工作为基础

在总体设计阶段,数据项和数据结构以比较抽象的方式描述,而详细设计阶段则应在此基础上给出足够详细描述。

详细设计要提供关于算法的更多的细节

  1. 详细设计的任务和原则

任务:

确定每个模块算法

确定每一个模块的数据组织

为每一个模块设计一组测试用例

编写详细设计说明书

原则

模块的逻辑描述正确可靠

采用结构化程序设计方法,改善控制结构,降低程序复杂度,提高程序可读性,可测试性和可维护性

详细设计的工具,优缺点

  1. 程序流程图

优点:比较直观 和清晰地描述过程的控制流程

缺点:

不是逐步求 精的好工具,忽略了程序的全局结构

随意转移控制

表示数据结构方面存在不足。

  1. H-S图

功能域

控制转移不能任意规定

容易确定局部数据和全局数据的作用域

容易表现嵌套关系,也可以表示模块的层次结构

  1. pad图
  1. 清晰度和结构化程度高。
  1. PAD图中的最左面的线是程序的主干线,即程序的
    第一层结构。随着程序层次的增加,PAD图逐渐 向右延伸。因此,PAD图可读性强。
  1. 利用PAD图设计出的程序必定是结构化的程序。
  1. 容易将PAD图转化成高级语言源程序。
  1. PAD图支持自顶向下逐步求精的方法。
  1. 环形复杂度,如何计算

绘制流图:程序流程图中的顺序的处理框序列和菱形判定框,
可以映射成流图中的一个结点,仅仅描绘程序的控制流程,完全不表现对数据的具体操
作以及分支或循环的具体条件

流图中区域数(包括图外区域)

流图边数-节点数 + 2

判定结点数+1

  1. 环形复杂度对编程的指导意义

环形复杂度高 的程序,往往是最困难、最容易出问题的程序.

模块规模以V(G)≤10为宜,也就是说,V(G)=10 是模块规模的一个更科学更精确的上限

第六章 编码

  1. 编程语言共有的特性有哪些

名字说明

类型说明

初始化

程序对象的局部性

程序模块

循环控制结构

分支控制结构

异常处理

独立编译

  1. 什么是编码规范,枚举常用的编码规范

编码风格实际上是一种编码原则。编码的目标从强调效率转变到强调
清晰。与此相应,编码风格也从追求“聪明”和 “技巧” ,变为提倡“简明”和“直接”
。人们 逐渐认识到,良好的编码风格能在一定程度上弥
补程序设计语言存在的缺点。反之,如果不注意
编码风格,即使使用了结构化的现代语言,也很 难写出高质量的程序。

1). 序言性注释

2). 描述性注释

3). 变量名选择合理

4). 表达式书写

5). 循环语句设计

  1. 什么是程序内文档,如何做程序内文档

指编码时适当选择标识符的名字、适当安排注释和注重程序的整个组织形式。

  1. 提升代码效率的方法

准则:

  1. 效率是一种性能需求,目标值应该在需求分析阶段设定。软件效率应该以需求为准,不应该以人力所及为准
  1. 好的设计可用提高效率
  1. 代码效率与代码简单性相关

方法:
(1)应先简化算术和逻辑的表达式。

(2)仔细研究嵌套的循环,以确定是否有语句可以 从内层往外移。

(3)尽量避免使用多维数组。

(4)尽量避免使用指针和复杂的列表。

(5)使用执行时间短的算术运算。

(6)即使语言允许,一般也不要采用混合数据类型。

(7)尽量使用整数表达式和布尔表达式。

第八章 维护

  1. 维护的种类

纠错性维护

适应性维护

完善性维护

预防性维护

  1. 什么是再工程(预防性维护)

再工程是一个重构活动,软件再工程是一类软件工程活动,是一个工程过程,它将逆向工程,重构和正向工程组合起来,将现存系统重新构造为新的形式

  1. 文档是影响软件可维护性的决定性因素
× 请我吃糖~
打赏二维码