免费智能真题库 > 历年试卷 > 信息系统管理工程师 > 2009年下半年 信息系统管理工程师 上午试卷 综合知识
  第43题      
  知识点:   软件生命周期和资源管理   软件维护   开发过程   软件设计   生命周期   维护   需求分析
  关键词:   软件开发过程   软件设计   软件生命周期   软件维护   需求分析   开发   开发过程   软件开发   生命周期   维护   需求        章/节:   系统运行管理知识       

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

 
  第56题    2013年上半年  
   44%
在软件管理中,(56)是基础架构管理的重要组成部分,可以提高IT维护的自动化水平,并且大大减少维护IT资源的费用。
  第55题    2012年上半年  
   26%
软件开发完成并投入使用后,由于多方面原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须进行(55)。
  第60题    2017年上半年  
   45%
软件分发管理是基础架构管理的重要组成部分,可以提高IT维护的自动化水平,实现企业内部软件使用标准化,减少维护IT资源的费用。..
   知识点讲解    
   · 软件生命周期和资源管理    · 软件维护    · 开发过程    · 软件设计    · 生命周期    · 维护    · 需求分析
 
       软件生命周期和资源管理
        软件生命周期指软件开发全部过程、活动和任务的结构框架。软件开发包括发现、定义、概念、设计和实现阶段。
        选择一个适当的软件生命周期对项目来说至关重要。在项目策划的初期,就应该确定项目所采用的软件生命周期,统筹规划项目的整体开发流程。一个组织通常能为多个客户生产软件,而客户的要求也是多样化的,一种软件生命周期往往不能适合所有的情况。常见的软件生命周期如下表所示。
        
        常见的软件生命周期
        
        软件开发的生命周期包括两方面的内容,首先是项目应包括哪些阶段,其次是这些阶段的顺序如何。一般的软件开发过程包括:需求分析(RA)、软件设计(SD)、编码(Coding)及单元测试(Unit Test)、集成及系统测试(Integration and System Test)、安装(Install)、实施(Implementation)等阶段。
        维护阶段实际上是一个微型的软件开发生命周期,包括:对缺隙或更改申请进行分析即需求分析(RA)、分析影响即软件设计(SD)、实施变更即进行编程(Coding),然后进行测试(Test)。在维护生命周期中,最重要的就是对变更的管理。软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
 
       软件维护
        系统维护工作的对象是整个系统的配置。由于问题可能来源于系统的各个组成部分,产生于系统开发的各个阶段,因此系统维护工作并不仅仅是针对源程序代码,而且还包括了系统开发过程中的全部开发文档。所以,一旦业务处理出现问题或发生变化,就要修改应用程序及有关文档。软件维护是系统维护最主要的内容。
               软件维护管理
               (1)任何人员不得擅自对系统文件进行删除或修改。软件操作人员不得对系统文件进行任何内容的操作。
               (2)系统管理员对软件系统进行全面维护,并进行记录。
               (3)定期对系统进行病毒检查。
               (4)建立故障报告制度。系统运行或软件操作中发生故障,如属简单故障,由系统管理员现场解决;现场无法解决的,由第一发现者进行故障登记,部门负责人会同系统管理员制定处理方案(方案包括:故障分析、拟采取措施、保障数据安全防范措施等),经核算中心分管主任批准后实施。对于无法排除的故障,由系统管理员及时联系相关单位解决。
               (5)对软件进行修改、升级时,首先要全面备份系统的数据,做好新旧系统数据的衔接工作。
               按照维护的具体目标分类
               (1)完善性的维护。完善性维护就是在应用软件系统使用期间为不断改善和加强系统的功能和性能,以满足用户日益增长的需求所进行的维护工作。在整个维护工作量中,完善性维护居第一位。
               (2)适应性维护。适应性维护是指为了让应用软件系统适应运行环境的变化而进行的维护活动。适应性维护工作量约占整个维护工作量的25%。
               (3)纠错性维护。纠错性维护的目的在于,纠正在开发期间未能发现的遗留错误。对这些错误的相继发现,对它们进行诊断和改正的过程被称为纠错性维护。这类维护约占总维护工作量的20%。
               (4)预防性维护。其主要思想是维护人员不应被动地等待用户提出要求才做维护工作,而应该选择哪些还有较长使用寿命的部分加以维护。
               按照开发方分类
               自己公司开发的软件、合同开发的软件、市场买的软件,这三种软件的维护途径可以是不同的。
               自己公司开发的软件一般由原开发人员进行维护。
               按合同开发的软件产品交付后,开发方应依据开发时签定的合同,负责软件的维护和软件版本升级工作。维护活动一般包括:对顾客使用中出现的软件故障进行测试、分析和修复;在维护阶段,按顾客提出的功能和性能改进要求进行软件版本升级,升级后的软件版本应纳入配置管理,并保存软件维护、升级记录。
               若购买了某种软件产品且该软件在产品支持周期内,则还可以购买该软件公司的软件维护服务。软件公司为软件产品用户推出专业技术支持服务,服务一般由公司具有丰富产品知识和实践经验的资深软件工程师协同技术中心专家组成专业技术团队共同提供,目的是帮助客户及时、快速、可靠地解决在软件系统的维护过程中所遇到的技术问题,使得客户的软件系统可以更加安全稳定地运行,以保障和促进客户业务的顺利开展并取得更大的成功。
               软件维护合同一般包括软件的更新和技术支持。两者捆绑在一起每年统一收取一笔费。客户需要签定软件维护合同,以获得技术支持和将来的升级服务。在多数情况下合同的主要目的是软件的更新。
               系统维护中经常会遇到一些问题。系统维护中的编码本身造成的错误比例并不高,仅占4%左右,而绝大部分问题源于系统分析和设计阶段。通常,理解别人编写的程序是很难的,且难度随着软件配置文档的减少而增加;绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改,如有些模块不够独立,牵一发而动全身;系统维护工作相对缺乏挑战性,使系统维护人员队伍不稳定。所以,一般来说,系统维护人员应当就是系统的原开发人员中的一部分。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
 
       软件设计
               软件设计的任务
               在给定系统的需求规格说明书后,需要对软件的结构进行设计,并对设计的过程进行管理。在嵌入式系统的软件设计过程中,需要完成以下一些任务。
                      准备工作计划
                      在软件设计之前,首先要制订详细的工作计划,其内容包括:
                      .过程管理方案:包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等;
                      .开发环境的准备方案:包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等;
                      .软硬件联机调试的方案:联调的起始时间、地点、人员和具体的准备工作;
                      .质量保证方案:包括质量目标计划、质量控制计划等;
                      .配置控制方案:包括配置控制文档的编写、配置控制规则的制订等。
                      确定软件的结构
                      设计软件的各个组成部分,包括:
                      .任务结构的设计:使用操作系统提供的函数,设计出一个最佳的任务结构;
                      .线程的设计;
                      .公共数据结构的设计:在确保系统一致性的基础上,设计出所需的公共数据;
                      .操作系统资源的定义;
                      .类的设计;
                      .模块结构设计:在设计时要充分考虑模块的划分、标准化、可重用和灵活性等;
                      .内存的分配与布局。
                      设计评审
                      对于软件设计的结果,进行一次设计评审,并在必要时对设计进行修正。具体内容包括:
                      .确认每件工作的执行方法是否恰当,其内容是否完善;
                      .确认该设计完成了系统需求规格说明书所要求的功能和服务;
                      .评估任务结构设计、评估类的设计、评估模块结构设计;
                      .对软件设计的结果进行总结,编写出相应的文档。
                      维护工作计划
                      执行软件设计工作控制,在每日、每周和每月的时间粒度上对进度进行控制,确保软件设计能够如期完成。
                      与硬件部门密切合作、相互协调
                      根据工作计划中的安排,定期与硬件部门召开会议,协调各自的进展。如果软件规格说明书发生了变化,立即进行调整,重新进行软件设计。
                      控制工作的结果,把工作记录存档
                      掌握当前的工作进展情况,尽早地发现和分析问题,并采取相应的措施。对各种事件进行跟踪记录,包括:
                      .执行过程控制,跟踪进展情况并定期记录、存档。
                      .执行质量控制,保留质量记录。
                      .记录产品的配置、版本变化、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)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
   题号导航      2009年下半年 信息系统管理工程师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第43题    在手机中做本题