软件开发的生命周期包括两方面的内容，一是项目应该包括哪些阶段，二是这些阶段的顺序..

免费智能真题库 > 历年试卷 > 信息系统管理工程师 > 2020年下半年信息系统管理工程师上午试卷综合知识

第60题

知识点：单元测试软件生命周期和资源管理系统测试 SD 编码软件设计生命周期需求分析

章/节：系统运行管理知识

软件开发的生命周期包括两方面的内容，一是项目应该包括哪些阶段，二是这些阶段的顺序如何。通常的软件生命周期会包括这样一些阶段（注意：下面的序号并非实际生命周期顺序序号）：
①安装(Install)；②集成及系统测试(Integration and System Test)；③编码(Coding) 及单元测试(UnitTest)；④软件设计（SD);⑤实施(Implementation)；⑥需求分析（RA)。这些阶段的正确顺序应该是（60）。

A. ①②③④⑤⑥

B. ⑥④③②①⑤

C. ③①②④⑤⑥

D. ⑥①②③④⑤

相关试题：软件管理

更多>

第58题 2019年上半年

42%

IT资源管理中，软件管理的范围涉及到对软件资源的认定。下列选项中，（）不属于软件资源。

第43题 2009年下半年

18%

一般的软件开发过程包括需求分析、软件设计、编写代码、软件维护等多个阶段，其中（43）是软件生命周期中持续时间最长的阶段。

第55题 2012年上半年

26%

软件开发完成并投入使用后，由于多方面原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须进行（55）。


知识点讲解
· 单元测试 · 软件生命周期和资源管理 · 系统测试 · SD · 编码 · 软件设计 · 生命周期 · 需求分析

单元测试

单元测试也被称为被模块测试。在模块编写完成且无编译错误后就可以进行。可以选用人工测试或机器测试，当用机器测试时，一般采用白盒测试法，多个模块可以同时进行。

（1）单元测试的内容。

在单元测试中，主要从模块的5个特征进行检查：模块接口、局部数据结构、重要的执行路径、出错处理和边界条件。

①模块接口，如果所测模块的数据流不能正确地输入、输出，则根本就无法进行其他的测试。所以在单元测试中要考察模块的接口。Myers提出了接口测试要点如下。

.调用被测模块的输入参数和形式参数在个数、属性、单位上是否一致

.调用其他模块时所给的实际参数和被调模块的形式参数在个数、属性、单位上是否一致

.调用标准函数时所用的参数在属性、数目和顺序上是否正确

.全局变量在各模块中的定义和用法是否一致

.输入是否仅改变了形式参数

如果模块完成了外部的输入或输出，还应该再检查以下要点：

.开／关的语句是否正确

.规定的I/0格式是否与输入输出语句一致

.在使用文件之前是否已经打开文件或使用文件完毕后是否已关闭文件

.输入输出的错误是否被检查并处理

.输出的提示信息是否有误

②局部数据结构，在单元测试中，局部数据结构出错是比较常见的错误，在测试时应重点考虑以下因素。

.变量的说明是否合适

.是否使用了尚未赋值或尚未初始化的变量

.变量的初始值或默认值是否正确

.变量名是否有错，例如拼写错误

.是否出现上溢。下溢或地址异常的错误

如果有可能，还应确定全局变量对模块的影响。

③重要的执行路径，在单元测试中，对路径的测试是最基本的任务。由于不能进行穷举测试，需要精心设计测试用例来发现是否有计算、比较或控制流等方面的错误。

计算方面的错误主要有：算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型彼此不匹配；算法不正确；表达式的符号表示不正确等。

比较和控制流是紧密结合的，一般是通过比较来决定控制流的改变。关于这方面的错误主要有：本应相等的量由于精度问题造成不相等；不同类型进行比较；逻辑运算符不正确或优先次序错误；循环终止不正确（如多循环一次或少循环一次）、死循环；不恰当地修改循环变量；当遇到分支循环时，发生出口错误等。

④出错处理，好的设计应该能预测到出错的条件并且有对出错处理的路径。虽然计算机可以显示出错信息的内容，但仍需要程序员对出错进行处理，保证其逻辑的正确性，便于用户维护。对出错的测试应该着重考虑这些常见错误：错误的描述难于理解；错误提示与实际错误不相符；出错的提示信息不足以确定错误或确定造成错误的原因；在对错误进行处理之前，系统已经对错误条件进行了干预等。

⑤边界条件，边界条件的测试是单元测试的最后工作，也是非常重要的工作。软件容易在边界出现错误，如一个n维数组，在处理数组第n个下标时常常发生错误。要仔细选择测试用例，重点考察数据流、控制流在刚好等于、大于或小于最大值或最小值的情况。

模块测试通常由程序员本人来完成。但项目负责人应该注意测试结果，将这些些测试资料妥善保存，为后续的测试工作打下良好的基础。

（2）单元测试的方法。

由于模块不是独立运行的程序，各模块之间存在联系，即存在调用与被调用的关系，在对每个模块进行测试时，需要开发两种模块：

①驱动模块（driver）,相当于一个主程序，用于接收测试用例的数据，将这些数据送到被测模块，输出测试结果。

②桩模块（stub），也被称为存根模块，桩模块用来代替被测模块中所调用的子模块，其内可进行少量的数据处理，目的是为了检验入口，输出调用和返回信息。

驱动模块和桩模块是测试用的软件，不是要交给用户的软件组成部分，但需要占用一定的开发费用。为了降低成本，对于一些不能用简单的测试软件进行充分测试的模块，可以用下节介绍的增量式测试方法，在组装测试的同时完成对模块的详细测试。

提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲，所需的测试方案数目就会显著减少，而且更容易发现和预测模块中的错误。

软件生命周期和资源管理

软件生命周期指软件开发全部过程、活动和任务的结构框架。软件开发包括发现、定义、概念、设计和实现阶段。

选择一个适当的软件生命周期对项目来说至关重要。在项目策划的初期，就应该确定项目所采用的软件生命周期，统筹规划项目的整体开发流程。一个组织通常能为多个客户生产软件，而客户的要求也是多样化的，一种软件生命周期往往不能适合所有的情况。常见的软件生命周期如下表所示。

常见的软件生命周期

软件开发的生命周期包括两方面的内容，首先是项目应包括哪些阶段，其次是这些阶段的顺序如何。一般的软件开发过程包括：需求分析（RA）、软件设计（SD）、编码（Coding）及单元测试（Unit Test）、集成及系统测试（Integration and System Test）、安装（Install）、实施（Implementation）等阶段。

维护阶段实际上是一个微型的软件开发生命周期，包括：对缺隙或更改申请进行分析即需求分析（RA）、分析影响即软件设计（SD）、实施变更即进行编程（Coding），然后进行测试（Test）。在维护生命周期中，最重要的就是对变更的管理。软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

系统测试

系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统分析说明书来设计测试用例的，常见的系统测试主要有以下内容：

（1）恢复测试（Recovery Testing）。

恢复测试将检测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否能按照要求从故障中恢复过来，并在预定的时间内开始处理事务，而且不对系统造成任何损害。如果系统的恢复是自动的（由系统自动完成），则需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。

（2）安全性测试（Security Testing）。

系统的安全性测试用于检测系统的安全机制、保密措施是否完善且没有漏洞。主要是为了验证系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。例如，以系统的输入作为突破口，利用输入的容错性进行正面攻击；故意使系统出错，利用系统恢复的过程，窃取密码或其他有用的信息；想方设法截取或破译密码；利用浏览非保密数据，获取所需信息，等等。从理论上说，只要时间和资源允许，没有进入不了的系统。所以，系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。

（3）强度测试（Stress Testing）。

强度测试是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行的情况下，性能下降的幅度是否在被允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行，例如，运行使系统处理超过设计能力的最大允许值的测试用例；设计测试用例使系统传输超过设计最大能力的数据，包括内存的写入和读出，外部设备等；对磁盘保留的数据，设计产生过度搜索的测试用例；等等。强度测试主要是为了发现，在有效的输入数据中可能引起的不稳定或不正确的数据组合。

（4）性能测试（Performance Test）。

性能测试用于检查系统是否满足系统分析说明书对性能的要求。特别是实时系统或嵌入式系统，即使软件的功能满足需求，但性能达不到要求也是不行的。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。

（5）可靠性测试（Reliability Testing）。

对于系统分析说明书中提出了可靠性要求时，要对系统的可靠性进行测试。通常使用以下几个指标来衡量系统的可靠性：

.平均失效间隔时间（Mean Time Between Failures MTBF）是否超过了规定的时限。

.因故障而停机时间（Mean Time To Repairs MTTR）在一年中应不超过多少时间。

（6）安装测试（Installation Testing）。

在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否易操作等。主要检测：系统的每一个部分是否齐全；硬件的配置是否合理；安装中需要产生的文件和数据库是否已产生，其内容是否正确等。

最后再强调一下，信息系统的开发过程通常为系统分析、设计、编码实现等阶段。而每个阶段都有可能出现错误，测试过程正好与开发过程相反，其开发和测试的关系如下图所示，单元测试主要是发现编码阶段的错误。组装测试主要用于发现设计阶段产生的错误，如果在确认测试中发现系统分析有错误，这就需要重新修改系统分析、设计和编码。这说明越早犯的错误要到最后才能被发现，因此要重视开发的前期工作。

测试与开发的各阶段的关系

SD卡（Secure Digital Memory Card）是一种基于半导体快闪记忆器的新一代记忆设备。SD卡由日本松下、东芝及美国SanDisk公司于1999年8月共同开发研制。大小犹如一张邮票的SD记忆卡，重量只有2g，但却拥有高记忆容量、快速数据传输率、极大的移动灵活性以及很好的安全性。

SD卡在24mm×32mm×2.1mm的体积内结合了SanDisk快闪记忆卡控制与MLC（Multilevel Cell）技术和Toshiba（东芝）0.16μ及0.13μ的NAND技术，通过9针的接口界面与专门的驱动器相连接，不需要额外的电源来保持其上记忆的信息。而且它是一体化固体介质，没有任何移动部分，所以不用担心机械运动的损坏。

编码

编码过程

在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：

（1）确定源程序的标准格式，制订编程规范。

（2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。

（3）编写代码。

（4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。

编码准则

在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。

具体来说，在编写代码时，需要做到以下几点：

.保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。

.封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。

.消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。

.减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。

.编写优雅流畅的代码。

.遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。

编码技术

编程规范

在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。

编程规范主要涉及的三方面内容：

.命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。

.编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。

.注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。

性能优化

由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：

.尽量使用整数（char、short、int和long）的加法和减法。

.如果没有硬件支持，尽量避免使用乘法。

.尽量避免使用除法。

.如果没有硬件支持，尽量避免使用浮点数。

下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。

算术运算性能优化的例子

软件设计

软件设计的任务

在给定系统的需求规格说明书后，需要对软件的结构进行设计，并对设计的过程进行管理。在嵌入式系统的软件设计过程中，需要完成以下一些任务。

准备工作计划

在软件设计之前，首先要制订详细的工作计划，其内容包括：

.过程管理方案：包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等；

.开发环境的准备方案：包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等；

.软硬件联机调试的方案：联调的起始时间、地点、人员和具体的准备工作；

.质量保证方案：包括质量目标计划、质量控制计划等；

.配置控制方案：包括配置控制文档的编写、配置控制规则的制订等。

确定软件的结构

设计软件的各个组成部分，包括：

.任务结构的设计：使用操作系统提供的函数，设计出一个最佳的任务结构；

.线程的设计；

.公共数据结构的设计：在确保系统一致性的基础上，设计出所需的公共数据；

.操作系统资源的定义；

.类的设计；

.模块结构设计：在设计时要充分考虑模块的划分、标准化、可重用和灵活性等；

.内存的分配与布局。

设计评审

对于软件设计的结果，进行一次设计评审，并在必要时对设计进行修正。具体内容包括：

.确认每件工作的执行方法是否恰当，其内容是否完善；

.确认该设计完成了系统需求规格说明书所要求的功能和服务；

.评估任务结构设计、评估类的设计、评估模块结构设计；

.对软件设计的结果进行总结，编写出相应的文档。

维护工作计划

执行软件设计工作控制，在每日、每周和每月的时间粒度上对进度进行控制，确保软件设计能够如期完成。

与硬件部门密切合作、相互协调

根据工作计划中的安排，定期与硬件部门召开会议，协调各自的进展。如果软件规格说明书发生了变化，立即进行调整，重新进行软件设计。

控制工作的结果，把工作记录存档

掌握当前的工作进展情况，尽早地发现和分析问题，并采取相应的措施。对各种事件进行跟踪记录，包括：

.执行过程控制，跟踪进展情况并定期记录、存档。

.执行质量控制，保留质量记录。

.记录产品的配置、版本变化、bug的发现和处理等信息。

软件架构设计

软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。

架构的形成过程概要

软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。

软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。

在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。

（1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。

（2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。

（3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。

（4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。

以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。

软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。

类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。

架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。

一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。

在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。

模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。

下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。

架构的多维度分析

在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。

软件设计方法

在将系统分解为各个组件的过程中，需要采取不同的策略，而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略，设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。

（1）基于功能分解的设计方法。实时结构化分析与设计采用了功能分解，系统被分解为多个函数，并且以数据流或控制流的形式定义函数之间的接口；基于并发任务结构化的设计（Design Approach for Real-Time Systems，DARTS）提供了任务结构化标准，辅助人员确定系统中的并发任务，并指导定义任务接口。

（2）基于信息隐藏的设计方法。面向对象（Object Oriented，OO）设计方法将数据和数据上操作封装在对象实体中，对象外界不能够直接对对象内部进行访问和操作，只能通过消息间接访问对象，符合人类思维方式，提高软件的扩展性、维护性和重用性。

（3）基于模型驱动开发的设计方法。通过借助有效的（Model Driven Development，MDD）工具，构建和维护复杂系统的设计模型，直接产生高质量的代码，将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。

生命周期

IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。

（1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。

（2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。

（3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。

（4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。

（5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。

需求分析

需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：

（1）结构化分析方法。本节后续内容将详细讨论SA的内容。

（2）面向对象分析方法。将在10.3节中进行详细介绍。

（3）面向问题域的分析（Problem Domain Oriented Analysis, PDOA）方法。PDOA更多地强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段，并未广泛应用。

业务流程分析

业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。

业务流程分析的步骤如下：

（1）通过调查掌握基本情况。

（2）描述现有业务流程（绘制业务流程图）。

（3）确认现有业务流程。

（4）对业务流程进行分析。

（5）发现问题，提出解决方案。

（6）提出优化后的业务流程。

在业务流程图中使用的基本符号如下图所示。

数据流图

DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。

业务流程图符号

DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：

（1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。

（2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。

（3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。

办理取款手续的DFD

为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。

下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。

分层数据流图

概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：

（1）DFD中的所有图形符号只限于前述4种基本图形元素。

（2）顶层DFD必须包括前述4种基本元素，缺一不可。

（3）顶层DFD中的数据流必须封闭在外部实体之间。

（4）每个加工至少有一个输入数据流和一个输出数据流。

（5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。

（6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。

（7）可以在DFD中加入物质流，帮助用户理解DFD。

（8）图上每个元素都必须有名字。

（9）DFD中不可夹带控制流。

数据字典

数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。

对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。

（1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。

（2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。

（3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。

题号导航 2020年下半年信息系统管理工程师上午试卷综合知识

本试卷我的完整做题情况



	第60题在手机中做本题