第 6章信息管理系统分析与设计
本章导读：
本章本章从软件工程的角度介绍了信息管理系统设
计的基本过程和各阶段的关键内容
本章主要知识点：
（ 1）信息管理系统的分类
（ 2）信息管理系统的开发过程和各阶段主要任务
（ 3）系统分析、系统设计、系统实施与维护
第 6章信息管理系统分析与设计
6.1 概述
6.2 系统分析
6.3 系统设计
6.4 系统实施与维护
6.1 概述
6.1.1 信息管理系统分类
6.1.2 信息管理系统开发过程
6.1 概述
6.1.1 信息管理系统分类
1．办公自动化系统
办公自动化系统是用信息管理技术来提高办公室工作效率,
对办公室工作人员进行支持的系统 。 根据办公室工作的特点,
办公自动化系统主要是进行文件的管理, 按照办公的工作流
程来完成相应的工作, 其主要功能如下：
（ 1） 收文管理 。 包括外来文件的收文输入, 登记, 流转, 审
阅, 批示, 检索等功能 。
（ 2） 拟文管理 。 包括内部草拟文稿的输入登记, 审阅, 会签,
核稿, 签发, 清稿, 成文登记, 排版打印, 发文登记, 检索
查询等功能 。
（ 3） 呈报文管理 。 包括呈批件的文稿输入, 流转, 审阅, 批
示, 检索和存档等功能 。
6.1 概述
6.1.1 信息管理系统分类
（ 4）档案管理。包括收文、拟文处理完毕后的文件
自动转入档案管理系统进行归档、立卷处理等功能。
（ 5） 电子邮件系统 。 利用电子邮件实现公文和其它文
件的传送, 接收, 下载等功能 。
（ 6） 个人事务管理 。 包括个人事务的安排管理, 如名
片管理, 会议, 工作日程安排, 重大事件提醒等功
能 。
（ 7） 系统管理 。 根据系统使用部门, 人员的变动进行
用户管理, 包括用户名单的增, 删, 权限设定, 修
改等功能 。
另外，还应该注意提高办公自动化系统的安全保密性。
6.1 概述
6.1.1 信息管理系统分类
2．管理信息系统
管理信息系统（ Management Information System,MIS）
是一个由人和计算机组成的能进行组织内部和外部信息
的收集、传递、存储、加工、维护和使用，支持组织的
作业控制、计划管理和辅助决策的信息管理系统。管理
信息系统主要指数据库管理系统，利用数据库技术实现
各种管理业务。
6.1 概述
6.1.1 信息管理系统分类
2．管理信息系统
主要功能
（ 1）数据处理功能。包括数据的输入 /输出、删除、修改、传输、
存储、加工、查询。
（ 2） 计划功能 。 根据用户的目标和环境条件, 制订各部门的工作
计划 。
（ 3） 控制功能 。 根据收集到的信息, 对计划的执行情况进行监督,
检查和控制 。
（ 4） 预测功能 。 对企业效益, 市场的变化情况及各种计划完成的
可能性做出预测 。
（ 5）辅助决策功能，为企业的决策人提供可靠的决策信息和决策
方案。
6.1 概述
6.1.1 信息管理系统分类
3.决策支持系统
? 决策支持系统 （ Decision Supporting System,DSS） 产生于 20世
纪 70年代 。 是在管理信息系统 （ MIS） 的基础上发展起来的, 主要
强调为管理者提供辅助决策的能力 。
? 决策支持系统综合利用各种数据, 信息, 知识, 人工智能和模型
技术辅助高层决策者解决半结构化或非结构化决策问题 。 非结构
化决策是指决策过程是非常规的, 不存在标准的固定的解法, 也
不能用确定的算法来描述 。 半结构化决策指决策过程一部分是结
构化的, 一部分是非结构化的 。
? 决策支持系统以模型库为主体, 通过定量分析进行辅助决策 。 模
型库决定着系统的分析能力, 由模型库管理系统进行控制 。 此外
决策支持系统还应该包括数据库管理系统和会话管理系统的功能 。
返回本节目录
6.1 概述
6.1.2 信息管理系统开发过程
?软件的生命周期：
软件开发过程是由一系列相关活动组成的，包括从提
出要求，经过研制，到交付使用，在使用过程中不断
的增补修订，直到最后因被新的软件所代替而淘汰的
全部过程。
?阶段划分
?系统分析
?系统设计
?系统实施与维护
6.1 概述
6.1.2 信息管理系统开发过程
?阶段划分
?系统分析
?该时期的任务是确定信息管理系统的总目标、确定系统的可行
性、确定系统的实现方案、确定系统必须完成的功能以及完成
该系统需要的资源和成本，并且制定系统完成的预计进度，写
出系统分析报告。
?通常划分为三个阶段：问题定义、可行性研究和需求分析。由
分析人员负责完成。
?系统设计
?该时期的任务是根据系统分析时期的结果，逐步完成系统的设
计开发工作，最终得到运行良好的软件。通常由软件设计、软
件编码、软件测试三个阶段组成。
?系统实施与维护
?主要任务是为保证软件长久的满足用户的需要而对软件进行的
一系列修改工作。 返回本章目录
6.2 系统分析
6.2.1 问题定义
6.2.2 可行性研究
6.2.3 需求分析
6.2 系统分析
6.2.1 问题定义
问题定义阶段必须回答的关键问题是：
“系统要解决的问题是什么”。
系统分析员应该提出关于问题性质、工程
目标和规模的书面报告。通过对系统的实际用
户和使用部门负责人的访问调查，分析员简明
扼要的写出他对要开发的系统的理解，并在和
用户及使用部门负责人的会议上认真讨论这份
书面报告，澄清理解不清楚的地方，改正理解
错误的地方，最后得到一份双方都满意的文档，
即软件计划，标志问题定义阶段结束。
返回本节目录
6.2 系统分析
6.2.2 可行性研究
?关键问题是：“对上一阶段提出的问题有可
行的解决方案吗？”。
?可行性研究的任务
?可行性研究的目的就是用最小的代价在尽可能
短的时间内确定问题是否能够解决。
?可行性研究的内容：
?经济可行性
?技术可行性
?法律可行性
?开发方案的选择
6.2 系统分析
6.2.2 可行性研究
可行性研究的步骤
明确新系统的实现目标，研究旧系统
分析问题，导出新系统模型
确定系统开发计划
完成可行性研究报告
返回本节目录
6.2 系统分析
6.2.3 需求分析
需求分析的任务
确定目标系统的具体要求
? 运行环境要求：硬件环境、软件环境
? 系统的性能要求
? 系统功能要求
? 可靠性,安全保密性、用户界面等
建立目标系统的逻辑模型
? 分析系统的数据需求，并利用图形工具描述数据
结构（如层次图,Warnier图,IPO图等），并用
数据流图、数据字典及处理算法描述目标系统的
逻辑模型。
6.2 系统分析
6.2.3 需求分析
需求分析的任务
修正系统的开发计划
通过需求分析, 可对目标系统更深入更具体的了
解, 因而可以更准确地估计系统的开发成本和进度,
修正前阶段制定的开发计划 。
制定初步的系统测试计划
为了验证系统是否满足用户的需求, 必须对系统
功能进行测试 。 在系统开发早期就制定测试计划,
这有利于明确设计目标, 保证设计正确 。
编写初步的用户手册
6.2 系统分析
6.2.3 需求分析
需求分析的步骤
进行调查研究
调查研究是需求分析的主要手段。分析员对可行性研究报告
中描述的目标系统的运行环境、功能、性能等要和用户进行
详细的交流，对各项内容进一步细化并取得一致意见。
分析和描述系统的逻辑模型
分析员把来自用户的信息加以分析，从信息流和信息结构出
发，逐步细化系统的功能，找出各元素之间的联系、接口特
性和设计上的约束，分析他们是否满足功能要求、是否合理。
根据功能需求、性能需求、运行环境需求等，去掉不合理部
分，增加需要部分。最后抽象出系统的详细逻辑模型。
评审
6.2.3 需求分析
评审
为了保证需求分析的质量，应对需求分析的结果进行严格的
审查，并应由专门人员负责，并按照规程严格进行。评审人
员不仅包含系统分析员和用户，开发部门的管理者、软件设
计、实现、测试的人员都应该参加评审工作。评审工作应对
软件功能的正确性、完整性、清晰性，以及其它需求给与评
价并提出修改意见，修改完成后，需要再次进行评审、修改
，直到评审通过为止。
评审的主要内容
1.系统定义的目标是否与用户的要求一致 。
2.系统需求分析阶段提供的文档资料是否齐全 。
3,文档中所有描述是否完整, 清晰, 准确反映用户要求 。
4,与所有其它系统成分的重要接口是否都已经描述 。
5,所开发项目的数据流与数据结构是否足够, 确定 。
6.2 系统分析
6.2 系统分析
6.2.3 需求分析
评审的主要内容
6.所有图表是否清楚，在不补充说明时是否能够理解。
7.主要功能是否已包含在规定的软件范围之内，是否
都已充分说明。
8,设计的约束条件和限制条件是否符合实际 。
9,开发的技术风险是什么 。
l0,是否考虑过软件需求的其它方案 。
11,是否考虑过软件将来可能会提出的其它需求 。
12,是否详细制定了检验标准, 它们对系统定义是否
能成功进行确认 。
13,有没有遗漏, 重复或不一致的地方 。
14,用户是否审查了初步的用户手册 。
15,软件开发计划中的估算是否受到了影响 。
返回本章目录
6.3 系统设计
6.3.1 软件设计
6.3.2 编码
6.3.3 软件测试
6.3 系统设计
6.3.1 软件设计
任务是确定系统, 怎么做, 的问题 。
划分
总体设计：总体设计阶段要解决的问题是：, 总体
上, 系统应该如何实现？,, 因此总体设计又称为
概要设计或结构设计 。 总体设计阶段重要任务之一
就是确定系统的总体结构, 即确定系统由哪些模块
组成以及各模块之间的调用关系和接口说明 。
详细设计：设计每个模块的内部实现细节 。 详细设
计又称为过程设计 。
6.3 系统设计
6.3.1 软件设计
软件设计的过程
确定目标系统的各种可能的不同的方案, 在需求分析阶段得到的数据流图是
设计实现方案的基础 。
分析员向用户推荐最佳实现方案, 并制订详细的实现计划, 在得到用户认可
后可进入下面阶段 。
设计软件结构 。 首先进行总体设计, 确定系统由哪些模块组成, 以及模块之
间的相互关系 。 然后进行详细设计, 确定每个模块的实现算法和处理过程 。
数据库设计 。 对于涉及数据库技术的软件系统, 要根据需求分析的结果设计
数据库的结构 。
制订测试计划 。 在软件开发的早期提前考虑测试计划, 能够促使设计人员注
意软件的测试问题, 有利于提高软件的可测试性 。
编写文档 。 总体设计说明书 （ 包括系统实现方案和软件结构 ）, 详细设计说
明书, 测试计划 （ 包括测试策略, 测试方案, 预期的测试结果, 测试进度计
划等 ）, 初步的用户操作手册, 详细的实现计划和数据库设计的结果 。
复审 。 在总体设计和详细设计结束时要进行严格的技术审查和管理复审 。
6.3 系统设计
6.3.1 软件设计
模块
模块是能够单独命名并且能够独立完成一定功能的数据说明和程
序语句的集合 。 模块能够通过名字来访问, 如过程, 函数, 子程
序等 。
模块划分的原则
尽量提高模块的独立性：应尽量使每一个模块完成一个相对独立
的功能, 参数传递应尽量使用简单数据类型, 而不要使用结构类
型变量, 尽量少使用全局变量, 降低接口的复杂程度 。
模块的规模应该适中：不要太大, 不要太小, 模块的规模最好以
一页纸 （ 高级语言 50行左右 ） 为宜
降低模块接口的复杂性, 模块之间传递的参数个数应尽量少, 类
型应尽量简单 。
设计单入口, 单出口的模块 。
6.3 系统设计
6.3.1 软件设计
总体设计的图形描述工具
层次图, HIPO图 （ 层次图 +输入 /处理 /输出图 ）, 结构图 。
结构图
用一个方框代表一个模块, 框内注明模块的名字或主要功能；
方框之间用箭头或直线表示模块的调用关系；用带注释的箭
头表示模块调用时传递的信息, 箭头方向表示数据传递方向,
箭头尾部用空心圆表示传递的是数据信息, 实心圆表示传递
的是控制信息；
A
B
A A A
C B C D B B
（ a ）基本形式 （ b ）顺序调用 （ c ）选择调用 （ d ）重复调用
结构图的基本符号
结构图举例
解
格式化解
格式化解
解
编辑结果
原始输入
好输入
产生最佳解
得到好输入 计算最佳解 输出结果
读输入 编辑输入 结果格式化 显示结果
解
原始输入
好
输
入
图 6-2 产生最佳解的结构图
6.3 系统设计
6.3.1 软件设计
详细设计的图形描述工具
常用工具有：程序流程图, 盒图 （ N-S图 ）, PAD图, 过程设
计语言 PDL,判定表, 判定树, Jackson图等 。 它们都可以形
象的描述程序的控制流程, 处理过程, 数据组织以及各方面
的实现细节, 作为编码的依据 。
程序流程图 程
序
流
程
图
的
基
本
符
号
起止端点 数据 处理 准备或预处理 预先定义的处理
条件判断 循环上界限 循环下界限 文档 流线
虚线 省略符 平行线 注释
6.3 系统设计
6.3.1 软件设计
详细设计的图形描述工具
盒图,又称 N-S图, 是 1973年由 Nassi和 Shneiderman提出的,
它撇弃了程序流程图控制转移的随意性, 以结构化的方式严
格控制处理之间的转移 。
第一个任务
第二个任务
第三个任务
F 条件 T
E L S E
部分
T H E N
部分
CA S E 条件
值 1 值 2 … 值 1
Ca s e 1
部分
Ca s e 2
部分
Ca s e n
部分
循环条件
DO - W H IL E
部分
D O _U N T IL
部分
循环条件
A
（ a ）顺序结构 （ b ）选择结构 （ c ）多分支结构
（ d ）循环结构 （ e ）调用子程 序 A
图 6-4
N-S
图
的
基
本
符
号
返回本节目录
6.3 系统设计
6.3.2 编码
软件编码是系统设计过程的继续, 是将软件设
计转换成用程序设计语言编写的源程序的过程 。
为了保证程序设计的质量, 程序员必须熟练掌
握并正确运用程序设计语言的语法规则, 因为
只有语法上没有错误的程序才能通过编译系统
的语法检查, 程序才可能运行 。 但是完成一项
信息管理系统的开发, 对程序编码的要求决不
仅仅是源程序语法上的正确性, 也不只是源程
序中没有各种错误 。 此外, 还要求源程序应有
良好的结构和良好的程序设计风格 。
6.3 系统设计
6.3.2 编码
1．结构化程序设计的设计原则
使用语言中的顺序, 选择, 循环等有限的基本控制结
构表示程序逻辑 。
选用的控制结构只有一个入口, 一个出口 。
程序语句组成容易识别的块, 每块只有一个入口和一
个出口 。
复杂结构应用基本控制结构进行组合嵌套来实现 。
程序中没有的控制结构, 可用一段等价的程序段来模
拟, 但要求程序段在整个系统中应前后一致 。
6.3 系统设计
6.3.2 编码
2．程序设计语言的选择
除了选择结构化的程序设计语言, 还应该考虑如下几个
方面：
l 系统应用领域 。
l 算法和计算的复杂性 。
l 软件执行环境 。
l 性能考虑, 程序设计语言能否达到软件系统的需求 。
l 数据结构的复杂性 。
l 软件开发人员的知识水平和心理因素等 。
6.3 系统设计
6.3.2 编码
2．程序设计语言的选择
项目的应用领域是选择语言的关键因素, 不同的应用领
域有适应该领域软件特点的不同的程序设计语言开发
环境 。 如在科学计算领域多使用 FORTRAN语言, 在数据
库应用领域主要使用 PowerBuilder,SQL Server、
ORACLE,ACCESS,Sybase等, 网 页设计主要采用
JavaScript,VBScript,ASP,PHP,JSP等程序设计语
言, 对于实时性较高的应用系统一般采用汇编语言, C
语言, C++等 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
良好的程序设计风格主要有四个方面：源程序文档化, 数据说明,
语句结构和输入 /输出技术 。
（ 1） 源程序文档化
① 标识符的命名
标识符指表示模块名, 变量名, 常量名, 子程序名, 函数名等的名
字 。
名字命名应符合其表示的实际意义 。 例如, 用 number表示编号, 用
name表示姓名, 用 sum表示总和, 用 average表示平均值等等, 为此,
标识符的长度不应限制 。 但是标识符也不应该太长, 过长的标识符会
增加程序员的工作量, 增加出错机会 。 所以应选择精炼的意义明确的
名字 。
通常是采用单词缩写的形式 （ 如用 num表示编号 ）, 但要注意缩
写规则要一致, 并应该给每个标识符加上适当的注释 。 特殊情况还可
以使用汉语拼音或汉语拼音缩写的形式定义标识符, 但要保证在程序
中的定义规则一致 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 1） 源程序文档化
② 程序注释
程序的注释能够帮助读者理解程序, 是程序员和日后的程序读
者之间通信的重要手段, 为后续的测试和维护工作的顺利进行
提供了有利保证 。
序言性注释：序言性注释置于模块的开头部分, 包括模块的功
能说明, 接口说明 （ 调用形式, 参数描述, 子程序清单等 ）,
模块位置, 主要算法, 开发简历 （ 编码者, 复审者, 复审日期,
最后修改日期等 ） ；
功能性注释 。 功能性注释嵌在源程序体内, 用于描述一些程序
段的功能 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 1） 源程序文档化
③ 程序的形象化组织
使用空格, 空行和移行来改善视觉效果, 使程序
的结构清晰, 层次分明, 易于理解 。
例：写法一
float score;char degree;if (score>90)
degree='A';else if (score>80) degree='B';else……
写法二：
float score;
char degree;
if (score>90)
degree='A';
else
if (score>80)
degree='B';
else
……
显然，写法二中程序的结构则更清晰，便于理解和查错、改错。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 2） 数据说明
数据说明的次序应当规范化, 规定说明的先后次序 。 例如, 常
量说明, 简单变量类型说明, 数组说明, 结构类型说明, 函数
说明等 。 在类型说明中, 还可以进一步要求, 如按照整型变量,
实型变量, 字符型变量, 指针变量的顺序进行 。
当多个变量名用一个语句说明时, 应对这些变量按字母表的顺
序排列 。
如果设计了一个复杂的数据结构, 应当使用注释, 说明在程序
实现时这个数据结构的固有特点 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 3） 语句结构
语句结构应力求简单, 直接, 不能片面追求效率而使结构语句复杂化 。
注意以下几个方面：
在一行内只写一条语句, 并且采用适当的移行格式, 使程序的逻辑和
功能变得更加明确 。
程序的编写应当首先考虑清晰性, 不要刻意追求技巧性, 使程序编写
的过于紧凑 。
程序编写的要简单, 写清楚, 直截了当的说明程序员的用意 。
除非对效率有特殊的要求, 程序编写要做到清晰第一, 效率第二 。
首先要保证正确性, 然后才要求提高速度 。
6.3.2 编码
3．程序设计风格
（ 3） 语句结构 注意方面：
尽可能使用库函数 。
避免使用临时变量而使可读性下降 。
尽量用公共过程或子程序去代替重复的功能代码段 。
使用括号清晰的表达, 算术表达式和逻辑表达式的运算顺序 。
避免不必要的转移 。
用逻辑表达式代替分之嵌套 。
避免使用空的 else语句和 IF…,THEN…,IF语句 。
避免使用 ELSE GOTO和 ELSE RETURN语句 。
使与判定相联系的动作尽可能的紧跟着判定 。
尽量减少使用, 否定, 条件的条件语句 。
避免过多的循环嵌套和条件嵌套 。
不要使 GOTO语句相互交叉 。
对递归定义的数据结构尽量使用递归过程 。
经常反躬自省：, 如果我不是编码的人, 我能看懂它吗？,, 考虑他
的可理解性达到什么程度 。
6.3.2 编码
3．程序设计风格
（ 4） 输入 /输出 （ I/O） 技术
输入 /输出规则：
? 对所有输入数据都应进行校验 。。
? 检查输入项重要组合的合法性 。
? 保持输入格式简单 。
? 使用数据结束标记, 不要要求用户指定数据的数目 。
? 应给用户明确的输入提示 。
? 应允许缺省值 。
? 给所有输出数据加标志, 并设计输出报表格式 。
返回本节目录
6.3 系统设计
6.3.3 软件测试
1．软件测试的目标
G·Myers给出了如下一些观点, 可以作为测试的目标或定义：
（ 1） 测试是为了发现程序中的错误而执行程序的过程 。
（ 2） 好的测试方案是即可能发现迄今为止尚未发现的错误 。
（ 3）成功的测试是发现了至今为止尚未发现的错误的测
试。
错误观点：,测试是为了证明程序是正确的,,, 测试
时没有发现错误则证明程序是正确的,
6.3 系统设计
6.3.3 软件测试
2．软件测试的原则
（ 1）应当尽早地、不断地进行软件测试。
（ 2）测试用例应由测试输入数据和预期的输出结果两部
分组成。
（ 3）程序员应避免检查自己的程序，开发小组和测试小
组分开。
（ 4）注意测试中的群集现象，即程序中的错误往往集中
在少量的模块中。如果在某些模块中发现的错误数较
多，应当对这些模块进行重点测试。
（ 5）测试用例应当包含合理的输入数据和不合理的输入
数据。
6.3 系统设计
6.3.3 软件测试
2．软件测试的原则
（ 6） 严格执行测试计划, 避免测试的随意性 。
（ 7） 应当对每一测试结果作全面检查 。 否则可能会遗漏
错误 。
（ 8） 在程序修改之后要进行回归测试 。 因为在改正错误
的同时可能会引入新的错误, 因此在程序修改后, 应
对以前的测试用例重新进行测试 （ 称为回归测试 ）,
以便发现程序中新引进的错误 。
（ 9） 要妥善保管测试计划, 测试用例, 修改记录, 出错
统计和最终分析报告, 为维护提供方便 。
6.3 系统设计
6.3.3 软件测试
3．软件测试的步骤
（ 1） 单元测试
程序员编写完源代码以后, 首先对自己编写的模块进行初步的测试,
称为单元测试, 又称模块测试 。 主要测试单个模块的功能是否达
到了预定的功能要求 。 多个模块的单元测试可以同时进行 。
（ 2） 集成测试
又称组装测试, 将多个模块组装在一起进行测试, 主要测试模块间
接口是否正确, 模块之间能否协调工作 。 根据系统的规模, 又可
以分为子系统测试和系统测试两个步骤 。
（ 3） 确认测试
又称验收测试或有效性测试, 该阶段是在开发环境下和用户的参与
下, 使用真实的数据进行验收, 测试系统的整体功能和性能是否
达到了用户的要求 。
（ 4） 平行运行
又称系统测试, 是将软件安装到用户的实际使用环境下试运行, 并
且和旧系统或手工操作方式同时运行, 用以检验新软件的功能和
性能, 以便发现错误 。
6.3 系统设计
6.3.3 软件测试
需求分析 软件设计 编码
确认测试 集成测试 单元测试
需求分析
说明书
总体设计
说明书
详细设计
说明书
源程序
代码
单元
测试
集成
测试
确认
测试
图 6-5 软件测试与软件开发各阶段的关系
6.3 系统设计
6.3.3 软件测试
4．测试方法
（ 1） 静态分析
静态测试是指对系统分析, 系统设计各阶段的文档进行
分析, 检查, 而不在实际的计算机运行环境下运行程
序的过程 。 通常采取程序审查会和人工运行的方法组
织测试工作 。 实践证明, 这种方法对发现文档和程序
中的错误是十分有效的 。
（ 2） 动态测试
动态测试是指利用测试数据作为输入在计算机环境下运
行程序, 根据实际的输出与预期的输出结果是否一致
来确认程序是否有错的测试过程 。
动态测试的测试方法有黑盒测试法和白盒测试法 。
6.3 系统设计
6.3.3 软件测试
4．测试方法
黑盒测试法是指将程序模块看成是一个不透明的黑盒
子, 完全不考虑程序的内部结构和处理过程, 只检查
程序的功能是否按照需求说明书的规定正常使用, 能
否适当的接收数据并产生正确的输出信息, 并保持外
部信息 （ 如数据库或文件 ） 的完整性 。 因此, 黑盒测
试法又称为功能测试, 是在模块的接口处进行的测试 。
白盒测试法将程序模块看成是一个透明的白盒子, 测
试人员能够清楚的看到程序的内部结构和处理过程,
因此可以按照程序的内部逻辑结构进行测试, 检验程
序中的每一条路经能否按照预定的要求正常工作 。 因
此白盒测试又称为结构测试 。
6.3 系统设计
6.3.3 软件测试
5．测试和调试
软件测试是为了发现错误而执行程序的过程 。
调试则是在进行了成功的测试之后才开始进行
的, 其目的是为了进一步诊断和改正程序中潜
在的错误 。
软件调试工作包含两部分内容：
（ 1） 确定程序中错误的确切性质和位置 。
（ 2） 对程序 （ 设计, 编码 ） 进行修改, 排除错误 。
因此调试是测试工作的延续 。
返回本章目录
6.4 系统实施与维护
6.4.1 维护的分类
6.4.2 提高软件可维护性的方法
6.4.3 维护的过程
6.4 系统实施与维护
? 系统实施与维护是软件开发周期中最后一个阶
段。
? 软件实施：当软件经过充分的测试后可交付
用户使用，即系统实施。
? 软件维护：在使用过程中，不可避免的会发
现一些错误，或者用户的使用环境变更，或者
是用户提出了新的需求等使得软件运行与实际
需要出现不一致的现象，为了保证软件能够长
期的有效运行需要对软件作进一步的修改，这
就是维护的工作。
? 系统实施与维护是交替进行的，通常把它们作
为一个阶段。
6.4 系统实施与维护
6.4.1 维护的分类
维护：在系统实施与维护阶段对软件产品进行的修改 。
分类：
1,改正性维护
因为软件测试不可能发现大型软件中潜藏的所有错误, 在用户使用
过程中, 必然会在特定的环境下暴露出来 。 为了识别和纠正软件
错误, 改正软件性能上的缺陷, 排除实施中的误使用而进行的诊
断和改正软件错误的过程, 称为改正性维护 。
2,适应性维护
随着计算机的飞速发展, 计算机的软, 硬件环境都可能会发生变化,
为了适应新的运行环境而修改软件的过程称为适应性维护 。 例如,
将某个软件从 DOS环境移植到 Windows环境 。
6.4 系统实施与维护
6.4.1 维护的分类
3,完善性维护
在软件的使用过程中, 用户往往提出新的功能或修改已有功能的要
求 。 为了达到扩充软件功能, 增强软件性能, 提高工作效率或提
高软件可维护性等要求而进行的维护活动称为完善性维护 。
4,预防性维护
为了提高软件的可维护性, 可靠性等, 或为未来改进软件提供更好
的基础而修改软件的维护活动称为预防性维护 。 目前这种维护活
动相对来说比较少 。
国外的统计数字表明 。 完善性维护占全部维护活动的 50～ 66%,改正
性维护占 17～ 21%,适应性维护占 18～ 25%,其它维护活动只占 4%
左右 。
返回本节目录
6.4 系统实施与维护
6.4.2 提高软件可维护性的方法
定义,软件可维护性指维护人员理解, 修改或
改进软件的难易程度 。
衡量：可以从软件的可理解性, 可测试性,
可修改性以及可移植性四个方面来衡量 。
提高可维护性可采取的措施：
l 严格按信息管理系统开发过程组织软件开发活动 。
l 利用先进的软件技术和工具 。
l 选择可维护的程序设计语言 。
l 改进和完善软件文档 。
返回本节目录
6.4 系统实施与维护
6.4.3 维护的过程 人员分配
人员分配
严重
不严重
改正性
低 高
完善性
或适应性
修改后的软件
评价错误
严重程度
确定维
护类型
安排改正
性维护
评价
优先级别
开始
问题分析
维护任务
开始分析 复审
错误改正目录
开发目录
复审后供使用的软件及文档
图 6-6
软
件
维
护
的
工
作
流
程
本章小结
系统分析 过程完成问题定义, 可行性研究和需求分析
工作, 确定系统要解决的问题, 可行的方案和系统要
实现功能的确切定义, 要求明确各阶段的任务和主要
工作 。
系统设计 过程是将分析的结果逐步实现的过程, 包括
系统设计 （ 总体设计和详细设计 ）, 编码和测试 。 体
现了对复杂问题逐步求精的设计思路, 简化了设计工
作并提高工作效率 。 总体设计的工具 —— 结构图和详
细设计的工具 —— 程序流程图, 盒图能够很好的描述
设计成果 。 要求掌握个阶段的任务, 步骤和掌握结构
图, 程序流程图以及盒图的使用方法 。
系统维护 是保证在软件投入使用后能够长时间正常运
行的有效手段, 需要的工作量相当大, 必须引起软件
人员的重视 。 这部分主要掌握软件维护的定义, 维护
的种类 （ 改正性维护, 适应性维护, 完善性维护, 预
防性维护 ） 和维护的过程 。 返回本章目录
本章导读：
本章本章从软件工程的角度介绍了信息管理系统设
计的基本过程和各阶段的关键内容
本章主要知识点：
（ 1）信息管理系统的分类
（ 2）信息管理系统的开发过程和各阶段主要任务
（ 3）系统分析、系统设计、系统实施与维护
第 6章信息管理系统分析与设计
6.1 概述
6.2 系统分析
6.3 系统设计
6.4 系统实施与维护
6.1 概述
6.1.1 信息管理系统分类
6.1.2 信息管理系统开发过程
6.1 概述
6.1.1 信息管理系统分类
1．办公自动化系统
办公自动化系统是用信息管理技术来提高办公室工作效率,
对办公室工作人员进行支持的系统 。 根据办公室工作的特点,
办公自动化系统主要是进行文件的管理, 按照办公的工作流
程来完成相应的工作, 其主要功能如下：
（ 1） 收文管理 。 包括外来文件的收文输入, 登记, 流转, 审
阅, 批示, 检索等功能 。
（ 2） 拟文管理 。 包括内部草拟文稿的输入登记, 审阅, 会签,
核稿, 签发, 清稿, 成文登记, 排版打印, 发文登记, 检索
查询等功能 。
（ 3） 呈报文管理 。 包括呈批件的文稿输入, 流转, 审阅, 批
示, 检索和存档等功能 。
6.1 概述
6.1.1 信息管理系统分类
（ 4）档案管理。包括收文、拟文处理完毕后的文件
自动转入档案管理系统进行归档、立卷处理等功能。
（ 5） 电子邮件系统 。 利用电子邮件实现公文和其它文
件的传送, 接收, 下载等功能 。
（ 6） 个人事务管理 。 包括个人事务的安排管理, 如名
片管理, 会议, 工作日程安排, 重大事件提醒等功
能 。
（ 7） 系统管理 。 根据系统使用部门, 人员的变动进行
用户管理, 包括用户名单的增, 删, 权限设定, 修
改等功能 。
另外，还应该注意提高办公自动化系统的安全保密性。
6.1 概述
6.1.1 信息管理系统分类
2．管理信息系统
管理信息系统（ Management Information System,MIS）
是一个由人和计算机组成的能进行组织内部和外部信息
的收集、传递、存储、加工、维护和使用，支持组织的
作业控制、计划管理和辅助决策的信息管理系统。管理
信息系统主要指数据库管理系统，利用数据库技术实现
各种管理业务。
6.1 概述
6.1.1 信息管理系统分类
2．管理信息系统
主要功能
（ 1）数据处理功能。包括数据的输入 /输出、删除、修改、传输、
存储、加工、查询。
（ 2） 计划功能 。 根据用户的目标和环境条件, 制订各部门的工作
计划 。
（ 3） 控制功能 。 根据收集到的信息, 对计划的执行情况进行监督,
检查和控制 。
（ 4） 预测功能 。 对企业效益, 市场的变化情况及各种计划完成的
可能性做出预测 。
（ 5）辅助决策功能，为企业的决策人提供可靠的决策信息和决策
方案。
6.1 概述
6.1.1 信息管理系统分类
3.决策支持系统
? 决策支持系统 （ Decision Supporting System,DSS） 产生于 20世
纪 70年代 。 是在管理信息系统 （ MIS） 的基础上发展起来的, 主要
强调为管理者提供辅助决策的能力 。
? 决策支持系统综合利用各种数据, 信息, 知识, 人工智能和模型
技术辅助高层决策者解决半结构化或非结构化决策问题 。 非结构
化决策是指决策过程是非常规的, 不存在标准的固定的解法, 也
不能用确定的算法来描述 。 半结构化决策指决策过程一部分是结
构化的, 一部分是非结构化的 。
? 决策支持系统以模型库为主体, 通过定量分析进行辅助决策 。 模
型库决定着系统的分析能力, 由模型库管理系统进行控制 。 此外
决策支持系统还应该包括数据库管理系统和会话管理系统的功能 。
返回本节目录
6.1 概述
6.1.2 信息管理系统开发过程
?软件的生命周期：
软件开发过程是由一系列相关活动组成的，包括从提
出要求，经过研制，到交付使用，在使用过程中不断
的增补修订，直到最后因被新的软件所代替而淘汰的
全部过程。
?阶段划分
?系统分析
?系统设计
?系统实施与维护
6.1 概述
6.1.2 信息管理系统开发过程
?阶段划分
?系统分析
?该时期的任务是确定信息管理系统的总目标、确定系统的可行
性、确定系统的实现方案、确定系统必须完成的功能以及完成
该系统需要的资源和成本，并且制定系统完成的预计进度，写
出系统分析报告。
?通常划分为三个阶段：问题定义、可行性研究和需求分析。由
分析人员负责完成。
?系统设计
?该时期的任务是根据系统分析时期的结果，逐步完成系统的设
计开发工作，最终得到运行良好的软件。通常由软件设计、软
件编码、软件测试三个阶段组成。
?系统实施与维护
?主要任务是为保证软件长久的满足用户的需要而对软件进行的
一系列修改工作。 返回本章目录
6.2 系统分析
6.2.1 问题定义
6.2.2 可行性研究
6.2.3 需求分析
6.2 系统分析
6.2.1 问题定义
问题定义阶段必须回答的关键问题是：
“系统要解决的问题是什么”。
系统分析员应该提出关于问题性质、工程
目标和规模的书面报告。通过对系统的实际用
户和使用部门负责人的访问调查，分析员简明
扼要的写出他对要开发的系统的理解，并在和
用户及使用部门负责人的会议上认真讨论这份
书面报告，澄清理解不清楚的地方，改正理解
错误的地方，最后得到一份双方都满意的文档，
即软件计划，标志问题定义阶段结束。
返回本节目录
6.2 系统分析
6.2.2 可行性研究
?关键问题是：“对上一阶段提出的问题有可
行的解决方案吗？”。
?可行性研究的任务
?可行性研究的目的就是用最小的代价在尽可能
短的时间内确定问题是否能够解决。
?可行性研究的内容：
?经济可行性
?技术可行性
?法律可行性
?开发方案的选择
6.2 系统分析
6.2.2 可行性研究
可行性研究的步骤
明确新系统的实现目标，研究旧系统
分析问题，导出新系统模型
确定系统开发计划
完成可行性研究报告
返回本节目录
6.2 系统分析
6.2.3 需求分析
需求分析的任务
确定目标系统的具体要求
? 运行环境要求：硬件环境、软件环境
? 系统的性能要求
? 系统功能要求
? 可靠性,安全保密性、用户界面等
建立目标系统的逻辑模型
? 分析系统的数据需求，并利用图形工具描述数据
结构（如层次图,Warnier图,IPO图等），并用
数据流图、数据字典及处理算法描述目标系统的
逻辑模型。
6.2 系统分析
6.2.3 需求分析
需求分析的任务
修正系统的开发计划
通过需求分析, 可对目标系统更深入更具体的了
解, 因而可以更准确地估计系统的开发成本和进度,
修正前阶段制定的开发计划 。
制定初步的系统测试计划
为了验证系统是否满足用户的需求, 必须对系统
功能进行测试 。 在系统开发早期就制定测试计划,
这有利于明确设计目标, 保证设计正确 。
编写初步的用户手册
6.2 系统分析
6.2.3 需求分析
需求分析的步骤
进行调查研究
调查研究是需求分析的主要手段。分析员对可行性研究报告
中描述的目标系统的运行环境、功能、性能等要和用户进行
详细的交流，对各项内容进一步细化并取得一致意见。
分析和描述系统的逻辑模型
分析员把来自用户的信息加以分析，从信息流和信息结构出
发，逐步细化系统的功能，找出各元素之间的联系、接口特
性和设计上的约束，分析他们是否满足功能要求、是否合理。
根据功能需求、性能需求、运行环境需求等，去掉不合理部
分，增加需要部分。最后抽象出系统的详细逻辑模型。
评审
6.2.3 需求分析
评审
为了保证需求分析的质量，应对需求分析的结果进行严格的
审查，并应由专门人员负责，并按照规程严格进行。评审人
员不仅包含系统分析员和用户，开发部门的管理者、软件设
计、实现、测试的人员都应该参加评审工作。评审工作应对
软件功能的正确性、完整性、清晰性，以及其它需求给与评
价并提出修改意见，修改完成后，需要再次进行评审、修改
，直到评审通过为止。
评审的主要内容
1.系统定义的目标是否与用户的要求一致 。
2.系统需求分析阶段提供的文档资料是否齐全 。
3,文档中所有描述是否完整, 清晰, 准确反映用户要求 。
4,与所有其它系统成分的重要接口是否都已经描述 。
5,所开发项目的数据流与数据结构是否足够, 确定 。
6.2 系统分析
6.2 系统分析
6.2.3 需求分析
评审的主要内容
6.所有图表是否清楚，在不补充说明时是否能够理解。
7.主要功能是否已包含在规定的软件范围之内，是否
都已充分说明。
8,设计的约束条件和限制条件是否符合实际 。
9,开发的技术风险是什么 。
l0,是否考虑过软件需求的其它方案 。
11,是否考虑过软件将来可能会提出的其它需求 。
12,是否详细制定了检验标准, 它们对系统定义是否
能成功进行确认 。
13,有没有遗漏, 重复或不一致的地方 。
14,用户是否审查了初步的用户手册 。
15,软件开发计划中的估算是否受到了影响 。
返回本章目录
6.3 系统设计
6.3.1 软件设计
6.3.2 编码
6.3.3 软件测试
6.3 系统设计
6.3.1 软件设计
任务是确定系统, 怎么做, 的问题 。
划分
总体设计：总体设计阶段要解决的问题是：, 总体
上, 系统应该如何实现？,, 因此总体设计又称为
概要设计或结构设计 。 总体设计阶段重要任务之一
就是确定系统的总体结构, 即确定系统由哪些模块
组成以及各模块之间的调用关系和接口说明 。
详细设计：设计每个模块的内部实现细节 。 详细设
计又称为过程设计 。
6.3 系统设计
6.3.1 软件设计
软件设计的过程
确定目标系统的各种可能的不同的方案, 在需求分析阶段得到的数据流图是
设计实现方案的基础 。
分析员向用户推荐最佳实现方案, 并制订详细的实现计划, 在得到用户认可
后可进入下面阶段 。
设计软件结构 。 首先进行总体设计, 确定系统由哪些模块组成, 以及模块之
间的相互关系 。 然后进行详细设计, 确定每个模块的实现算法和处理过程 。
数据库设计 。 对于涉及数据库技术的软件系统, 要根据需求分析的结果设计
数据库的结构 。
制订测试计划 。 在软件开发的早期提前考虑测试计划, 能够促使设计人员注
意软件的测试问题, 有利于提高软件的可测试性 。
编写文档 。 总体设计说明书 （ 包括系统实现方案和软件结构 ）, 详细设计说
明书, 测试计划 （ 包括测试策略, 测试方案, 预期的测试结果, 测试进度计
划等 ）, 初步的用户操作手册, 详细的实现计划和数据库设计的结果 。
复审 。 在总体设计和详细设计结束时要进行严格的技术审查和管理复审 。
6.3 系统设计
6.3.1 软件设计
模块
模块是能够单独命名并且能够独立完成一定功能的数据说明和程
序语句的集合 。 模块能够通过名字来访问, 如过程, 函数, 子程
序等 。
模块划分的原则
尽量提高模块的独立性：应尽量使每一个模块完成一个相对独立
的功能, 参数传递应尽量使用简单数据类型, 而不要使用结构类
型变量, 尽量少使用全局变量, 降低接口的复杂程度 。
模块的规模应该适中：不要太大, 不要太小, 模块的规模最好以
一页纸 （ 高级语言 50行左右 ） 为宜
降低模块接口的复杂性, 模块之间传递的参数个数应尽量少, 类
型应尽量简单 。
设计单入口, 单出口的模块 。
6.3 系统设计
6.3.1 软件设计
总体设计的图形描述工具
层次图, HIPO图 （ 层次图 +输入 /处理 /输出图 ）, 结构图 。
结构图
用一个方框代表一个模块, 框内注明模块的名字或主要功能；
方框之间用箭头或直线表示模块的调用关系；用带注释的箭
头表示模块调用时传递的信息, 箭头方向表示数据传递方向,
箭头尾部用空心圆表示传递的是数据信息, 实心圆表示传递
的是控制信息；
A
B
A A A
C B C D B B
（ a ）基本形式 （ b ）顺序调用 （ c ）选择调用 （ d ）重复调用
结构图的基本符号
结构图举例
解
格式化解
格式化解
解
编辑结果
原始输入
好输入
产生最佳解
得到好输入 计算最佳解 输出结果
读输入 编辑输入 结果格式化 显示结果
解
原始输入
好
输
入
图 6-2 产生最佳解的结构图
6.3 系统设计
6.3.1 软件设计
详细设计的图形描述工具
常用工具有：程序流程图, 盒图 （ N-S图 ）, PAD图, 过程设
计语言 PDL,判定表, 判定树, Jackson图等 。 它们都可以形
象的描述程序的控制流程, 处理过程, 数据组织以及各方面
的实现细节, 作为编码的依据 。
程序流程图 程
序
流
程
图
的
基
本
符
号
起止端点 数据 处理 准备或预处理 预先定义的处理
条件判断 循环上界限 循环下界限 文档 流线
虚线 省略符 平行线 注释
6.3 系统设计
6.3.1 软件设计
详细设计的图形描述工具
盒图,又称 N-S图, 是 1973年由 Nassi和 Shneiderman提出的,
它撇弃了程序流程图控制转移的随意性, 以结构化的方式严
格控制处理之间的转移 。
第一个任务
第二个任务
第三个任务
F 条件 T
E L S E
部分
T H E N
部分
CA S E 条件
值 1 值 2 … 值 1
Ca s e 1
部分
Ca s e 2
部分
Ca s e n
部分
循环条件
DO - W H IL E
部分
D O _U N T IL
部分
循环条件
A
（ a ）顺序结构 （ b ）选择结构 （ c ）多分支结构
（ d ）循环结构 （ e ）调用子程 序 A
图 6-4
N-S
图
的
基
本
符
号
返回本节目录
6.3 系统设计
6.3.2 编码
软件编码是系统设计过程的继续, 是将软件设
计转换成用程序设计语言编写的源程序的过程 。
为了保证程序设计的质量, 程序员必须熟练掌
握并正确运用程序设计语言的语法规则, 因为
只有语法上没有错误的程序才能通过编译系统
的语法检查, 程序才可能运行 。 但是完成一项
信息管理系统的开发, 对程序编码的要求决不
仅仅是源程序语法上的正确性, 也不只是源程
序中没有各种错误 。 此外, 还要求源程序应有
良好的结构和良好的程序设计风格 。
6.3 系统设计
6.3.2 编码
1．结构化程序设计的设计原则
使用语言中的顺序, 选择, 循环等有限的基本控制结
构表示程序逻辑 。
选用的控制结构只有一个入口, 一个出口 。
程序语句组成容易识别的块, 每块只有一个入口和一
个出口 。
复杂结构应用基本控制结构进行组合嵌套来实现 。
程序中没有的控制结构, 可用一段等价的程序段来模
拟, 但要求程序段在整个系统中应前后一致 。
6.3 系统设计
6.3.2 编码
2．程序设计语言的选择
除了选择结构化的程序设计语言, 还应该考虑如下几个
方面：
l 系统应用领域 。
l 算法和计算的复杂性 。
l 软件执行环境 。
l 性能考虑, 程序设计语言能否达到软件系统的需求 。
l 数据结构的复杂性 。
l 软件开发人员的知识水平和心理因素等 。
6.3 系统设计
6.3.2 编码
2．程序设计语言的选择
项目的应用领域是选择语言的关键因素, 不同的应用领
域有适应该领域软件特点的不同的程序设计语言开发
环境 。 如在科学计算领域多使用 FORTRAN语言, 在数据
库应用领域主要使用 PowerBuilder,SQL Server、
ORACLE,ACCESS,Sybase等, 网 页设计主要采用
JavaScript,VBScript,ASP,PHP,JSP等程序设计语
言, 对于实时性较高的应用系统一般采用汇编语言, C
语言, C++等 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
良好的程序设计风格主要有四个方面：源程序文档化, 数据说明,
语句结构和输入 /输出技术 。
（ 1） 源程序文档化
① 标识符的命名
标识符指表示模块名, 变量名, 常量名, 子程序名, 函数名等的名
字 。
名字命名应符合其表示的实际意义 。 例如, 用 number表示编号, 用
name表示姓名, 用 sum表示总和, 用 average表示平均值等等, 为此,
标识符的长度不应限制 。 但是标识符也不应该太长, 过长的标识符会
增加程序员的工作量, 增加出错机会 。 所以应选择精炼的意义明确的
名字 。
通常是采用单词缩写的形式 （ 如用 num表示编号 ）, 但要注意缩
写规则要一致, 并应该给每个标识符加上适当的注释 。 特殊情况还可
以使用汉语拼音或汉语拼音缩写的形式定义标识符, 但要保证在程序
中的定义规则一致 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 1） 源程序文档化
② 程序注释
程序的注释能够帮助读者理解程序, 是程序员和日后的程序读
者之间通信的重要手段, 为后续的测试和维护工作的顺利进行
提供了有利保证 。
序言性注释：序言性注释置于模块的开头部分, 包括模块的功
能说明, 接口说明 （ 调用形式, 参数描述, 子程序清单等 ）,
模块位置, 主要算法, 开发简历 （ 编码者, 复审者, 复审日期,
最后修改日期等 ） ；
功能性注释 。 功能性注释嵌在源程序体内, 用于描述一些程序
段的功能 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 1） 源程序文档化
③ 程序的形象化组织
使用空格, 空行和移行来改善视觉效果, 使程序
的结构清晰, 层次分明, 易于理解 。
例：写法一
float score;char degree;if (score>90)
degree='A';else if (score>80) degree='B';else……
写法二：
float score;
char degree;
if (score>90)
degree='A';
else
if (score>80)
degree='B';
else
……
显然，写法二中程序的结构则更清晰，便于理解和查错、改错。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 2） 数据说明
数据说明的次序应当规范化, 规定说明的先后次序 。 例如, 常
量说明, 简单变量类型说明, 数组说明, 结构类型说明, 函数
说明等 。 在类型说明中, 还可以进一步要求, 如按照整型变量,
实型变量, 字符型变量, 指针变量的顺序进行 。
当多个变量名用一个语句说明时, 应对这些变量按字母表的顺
序排列 。
如果设计了一个复杂的数据结构, 应当使用注释, 说明在程序
实现时这个数据结构的固有特点 。
6.3 系统设计
6.3.2 编码
3．程序设计风格
（ 3） 语句结构
语句结构应力求简单, 直接, 不能片面追求效率而使结构语句复杂化 。
注意以下几个方面：
在一行内只写一条语句, 并且采用适当的移行格式, 使程序的逻辑和
功能变得更加明确 。
程序的编写应当首先考虑清晰性, 不要刻意追求技巧性, 使程序编写
的过于紧凑 。
程序编写的要简单, 写清楚, 直截了当的说明程序员的用意 。
除非对效率有特殊的要求, 程序编写要做到清晰第一, 效率第二 。
首先要保证正确性, 然后才要求提高速度 。
6.3.2 编码
3．程序设计风格
（ 3） 语句结构 注意方面：
尽可能使用库函数 。
避免使用临时变量而使可读性下降 。
尽量用公共过程或子程序去代替重复的功能代码段 。
使用括号清晰的表达, 算术表达式和逻辑表达式的运算顺序 。
避免不必要的转移 。
用逻辑表达式代替分之嵌套 。
避免使用空的 else语句和 IF…,THEN…,IF语句 。
避免使用 ELSE GOTO和 ELSE RETURN语句 。
使与判定相联系的动作尽可能的紧跟着判定 。
尽量减少使用, 否定, 条件的条件语句 。
避免过多的循环嵌套和条件嵌套 。
不要使 GOTO语句相互交叉 。
对递归定义的数据结构尽量使用递归过程 。
经常反躬自省：, 如果我不是编码的人, 我能看懂它吗？,, 考虑他
的可理解性达到什么程度 。
6.3.2 编码
3．程序设计风格
（ 4） 输入 /输出 （ I/O） 技术
输入 /输出规则：
? 对所有输入数据都应进行校验 。。
? 检查输入项重要组合的合法性 。
? 保持输入格式简单 。
? 使用数据结束标记, 不要要求用户指定数据的数目 。
? 应给用户明确的输入提示 。
? 应允许缺省值 。
? 给所有输出数据加标志, 并设计输出报表格式 。
返回本节目录
6.3 系统设计
6.3.3 软件测试
1．软件测试的目标
G·Myers给出了如下一些观点, 可以作为测试的目标或定义：
（ 1） 测试是为了发现程序中的错误而执行程序的过程 。
（ 2） 好的测试方案是即可能发现迄今为止尚未发现的错误 。
（ 3）成功的测试是发现了至今为止尚未发现的错误的测
试。
错误观点：,测试是为了证明程序是正确的,,, 测试
时没有发现错误则证明程序是正确的,
6.3 系统设计
6.3.3 软件测试
2．软件测试的原则
（ 1）应当尽早地、不断地进行软件测试。
（ 2）测试用例应由测试输入数据和预期的输出结果两部
分组成。
（ 3）程序员应避免检查自己的程序，开发小组和测试小
组分开。
（ 4）注意测试中的群集现象，即程序中的错误往往集中
在少量的模块中。如果在某些模块中发现的错误数较
多，应当对这些模块进行重点测试。
（ 5）测试用例应当包含合理的输入数据和不合理的输入
数据。
6.3 系统设计
6.3.3 软件测试
2．软件测试的原则
（ 6） 严格执行测试计划, 避免测试的随意性 。
（ 7） 应当对每一测试结果作全面检查 。 否则可能会遗漏
错误 。
（ 8） 在程序修改之后要进行回归测试 。 因为在改正错误
的同时可能会引入新的错误, 因此在程序修改后, 应
对以前的测试用例重新进行测试 （ 称为回归测试 ）,
以便发现程序中新引进的错误 。
（ 9） 要妥善保管测试计划, 测试用例, 修改记录, 出错
统计和最终分析报告, 为维护提供方便 。
6.3 系统设计
6.3.3 软件测试
3．软件测试的步骤
（ 1） 单元测试
程序员编写完源代码以后, 首先对自己编写的模块进行初步的测试,
称为单元测试, 又称模块测试 。 主要测试单个模块的功能是否达
到了预定的功能要求 。 多个模块的单元测试可以同时进行 。
（ 2） 集成测试
又称组装测试, 将多个模块组装在一起进行测试, 主要测试模块间
接口是否正确, 模块之间能否协调工作 。 根据系统的规模, 又可
以分为子系统测试和系统测试两个步骤 。
（ 3） 确认测试
又称验收测试或有效性测试, 该阶段是在开发环境下和用户的参与
下, 使用真实的数据进行验收, 测试系统的整体功能和性能是否
达到了用户的要求 。
（ 4） 平行运行
又称系统测试, 是将软件安装到用户的实际使用环境下试运行, 并
且和旧系统或手工操作方式同时运行, 用以检验新软件的功能和
性能, 以便发现错误 。
6.3 系统设计
6.3.3 软件测试
需求分析 软件设计 编码
确认测试 集成测试 单元测试
需求分析
说明书
总体设计
说明书
详细设计
说明书
源程序
代码
单元
测试
集成
测试
确认
测试
图 6-5 软件测试与软件开发各阶段的关系
6.3 系统设计
6.3.3 软件测试
4．测试方法
（ 1） 静态分析
静态测试是指对系统分析, 系统设计各阶段的文档进行
分析, 检查, 而不在实际的计算机运行环境下运行程
序的过程 。 通常采取程序审查会和人工运行的方法组
织测试工作 。 实践证明, 这种方法对发现文档和程序
中的错误是十分有效的 。
（ 2） 动态测试
动态测试是指利用测试数据作为输入在计算机环境下运
行程序, 根据实际的输出与预期的输出结果是否一致
来确认程序是否有错的测试过程 。
动态测试的测试方法有黑盒测试法和白盒测试法 。
6.3 系统设计
6.3.3 软件测试
4．测试方法
黑盒测试法是指将程序模块看成是一个不透明的黑盒
子, 完全不考虑程序的内部结构和处理过程, 只检查
程序的功能是否按照需求说明书的规定正常使用, 能
否适当的接收数据并产生正确的输出信息, 并保持外
部信息 （ 如数据库或文件 ） 的完整性 。 因此, 黑盒测
试法又称为功能测试, 是在模块的接口处进行的测试 。
白盒测试法将程序模块看成是一个透明的白盒子, 测
试人员能够清楚的看到程序的内部结构和处理过程,
因此可以按照程序的内部逻辑结构进行测试, 检验程
序中的每一条路经能否按照预定的要求正常工作 。 因
此白盒测试又称为结构测试 。
6.3 系统设计
6.3.3 软件测试
5．测试和调试
软件测试是为了发现错误而执行程序的过程 。
调试则是在进行了成功的测试之后才开始进行
的, 其目的是为了进一步诊断和改正程序中潜
在的错误 。
软件调试工作包含两部分内容：
（ 1） 确定程序中错误的确切性质和位置 。
（ 2） 对程序 （ 设计, 编码 ） 进行修改, 排除错误 。
因此调试是测试工作的延续 。
返回本章目录
6.4 系统实施与维护
6.4.1 维护的分类
6.4.2 提高软件可维护性的方法
6.4.3 维护的过程
6.4 系统实施与维护
? 系统实施与维护是软件开发周期中最后一个阶
段。
? 软件实施：当软件经过充分的测试后可交付
用户使用，即系统实施。
? 软件维护：在使用过程中，不可避免的会发
现一些错误，或者用户的使用环境变更，或者
是用户提出了新的需求等使得软件运行与实际
需要出现不一致的现象，为了保证软件能够长
期的有效运行需要对软件作进一步的修改，这
就是维护的工作。
? 系统实施与维护是交替进行的，通常把它们作
为一个阶段。
6.4 系统实施与维护
6.4.1 维护的分类
维护：在系统实施与维护阶段对软件产品进行的修改 。
分类：
1,改正性维护
因为软件测试不可能发现大型软件中潜藏的所有错误, 在用户使用
过程中, 必然会在特定的环境下暴露出来 。 为了识别和纠正软件
错误, 改正软件性能上的缺陷, 排除实施中的误使用而进行的诊
断和改正软件错误的过程, 称为改正性维护 。
2,适应性维护
随着计算机的飞速发展, 计算机的软, 硬件环境都可能会发生变化,
为了适应新的运行环境而修改软件的过程称为适应性维护 。 例如,
将某个软件从 DOS环境移植到 Windows环境 。
6.4 系统实施与维护
6.4.1 维护的分类
3,完善性维护
在软件的使用过程中, 用户往往提出新的功能或修改已有功能的要
求 。 为了达到扩充软件功能, 增强软件性能, 提高工作效率或提
高软件可维护性等要求而进行的维护活动称为完善性维护 。
4,预防性维护
为了提高软件的可维护性, 可靠性等, 或为未来改进软件提供更好
的基础而修改软件的维护活动称为预防性维护 。 目前这种维护活
动相对来说比较少 。
国外的统计数字表明 。 完善性维护占全部维护活动的 50～ 66%,改正
性维护占 17～ 21%,适应性维护占 18～ 25%,其它维护活动只占 4%
左右 。
返回本节目录
6.4 系统实施与维护
6.4.2 提高软件可维护性的方法
定义,软件可维护性指维护人员理解, 修改或
改进软件的难易程度 。
衡量：可以从软件的可理解性, 可测试性,
可修改性以及可移植性四个方面来衡量 。
提高可维护性可采取的措施：
l 严格按信息管理系统开发过程组织软件开发活动 。
l 利用先进的软件技术和工具 。
l 选择可维护的程序设计语言 。
l 改进和完善软件文档 。
返回本节目录
6.4 系统实施与维护
6.4.3 维护的过程 人员分配
人员分配
严重
不严重
改正性
低 高
完善性
或适应性
修改后的软件
评价错误
严重程度
确定维
护类型
安排改正
性维护
评价
优先级别
开始
问题分析
维护任务
开始分析 复审
错误改正目录
开发目录
复审后供使用的软件及文档
图 6-6
软
件
维
护
的
工
作
流
程
本章小结
系统分析 过程完成问题定义, 可行性研究和需求分析
工作, 确定系统要解决的问题, 可行的方案和系统要
实现功能的确切定义, 要求明确各阶段的任务和主要
工作 。
系统设计 过程是将分析的结果逐步实现的过程, 包括
系统设计 （ 总体设计和详细设计 ）, 编码和测试 。 体
现了对复杂问题逐步求精的设计思路, 简化了设计工
作并提高工作效率 。 总体设计的工具 —— 结构图和详
细设计的工具 —— 程序流程图, 盒图能够很好的描述
设计成果 。 要求掌握个阶段的任务, 步骤和掌握结构
图, 程序流程图以及盒图的使用方法 。
系统维护 是保证在软件投入使用后能够长时间正常运
行的有效手段, 需要的工作量相当大, 必须引起软件
人员的重视 。 这部分主要掌握软件维护的定义, 维护
的种类 （ 改正性维护, 适应性维护, 完善性维护, 预
防性维护 ） 和维护的过程 。 返回本章目录
