免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2017年上半年 信息系统项目管理师 下午试卷 案例
  第3题      
  知识点：   编码   编码阶段   概要设计   评估   瀑布模型   生命周期   系统架构   详细设计   需求分析   需求分析阶段   需求说明书   智慧城市

 
【说明】
项目经理小李负责了一个新的项目，该项目的内容是为某市开发一套智慧城市公共综合信息服务平台。项目启动阶段，甲方仔细查看了小李提交的项目实施方案，提出由于该项目的投资方构成复杂，项目需求不清晰，希望项目组能想办法解决这个问题。
小李向公司申请了几名经验丰富的系统分析师，加强需求分析阶段的工作。经过较为充分的需求调研，形成了初步的需求说明书。小李认为需求分析工作较为详细，按照公司常用的软件开发生命周期模型，选择了瀑布模型进行开发。
在编写概要设计和详细设计说明书的过程中，客户方提供了几处需求的修改要求。由于其工作量不大，小李直接安排系统分析师按客户的要求进行了修改。在编码阶段后期，由于客户的投资方发生了变化，新的投资方采用了新的运营模式，导致需求发生较大变化，由于前期甲方已经强调过项目需求特点和要求，小李只能接受客户新的变更要求。在执行变更的过程中，项目组发现新的需求将导致系统架构的更改，经过评估该变更将使项目延期。
 
问题：3.1   （5分）
请分析该项目在整个过程中存在哪些主要问题？
 
问题：3.2   （7分）
请说明项目范围（需求）变更控制流程。
 
问题：3.3   （6分）
请将下面（1）~（6）处的答案填写在答题纸的对应栏内。
每项记录在册的变更请求都必须由（1）批准或否决。
变更结束后，形成新的项目基线并纳入到配置库的（2）库中，这时配置管理员应向项目组成员提交一份（3）报告。
（4）、（5）、（6）构成了项目的范围基准。
 
问题：3.4   （3分）
小李选择瀑布模型作为生命周期模型是否合适？如合适，请说明理由；如不合适，请说明理由，并给出合适的生命周期模型。
 
 
 

   知识点讲解    
   · 编码    · 编码阶段    · 概要设计    · 评估    · 瀑布模型    · 生命周期    · 系统架构    · 详细设计    · 需求分析    · 需求分析阶段    · 需求说明书    · 智慧城市
 
       编码
               编码过程
               在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：
               （1）确定源程序的标准格式，制订编程规范。
               （2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。
               （3）编写代码。
               （4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。
               编码准则
               在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。
               具体来说，在编写代码时，需要做到以下几点：
               .保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容：
                      .命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。
                      .编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：
                      .尽量使用整数（char、short、int和long）的加法和减法。
                      .如果没有硬件支持，尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持，尽量避免使用浮点数。
                      下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       编码阶段
        . 可靠性测试（含于单元测试）；
        . 排错；
        . 调整可靠性活动计划；
        . 收集可靠性数据；
        . 明确后续阶段的可靠性活动的详细计划；
        . 编制可靠性文档。
 
       概要设计
        1）设计软件系统总体结构
        设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
        2）数据结构及数据库设计
        （1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
        （2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。
        ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。
        ②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。
        ③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
        3）编写概要设计文档
        文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
        4）评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。
 
       评估
        评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。
        进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。
        网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。
 
       瀑布模型
        瀑布模型也称为生命周期法，是结构化方法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。采用瀑布模型的软件过程如下图所示。
        
        软件生存周期的瀑布模型
        （1）软件计划（问题的定义及规划）：主要确定软件的开发目标及其可行性。
        （2）需求分析：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
        （3）软件设计：主要是指根据需求分析的结果，对整个软件系统进行设计，如系统框架设计和数据库设计等。软件设计一般分为总体设计（概要设计）和详细设计。
        （4）程序编码：将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范，以保证程序的可读性和易维护性，提高程序的运行效率。
        （5）软件测试：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
        （6）软件维护：软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件可能会不能继续适应用户的要求，这时如果要延续软件的使用寿命，就必须对软件进行维护。
        瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”，即每个活动只做一次，最后得到软件产品，也称做“线性顺序模型”或者“传统生命周期”，其过程是从上一项活动接收该项活动的工作对象并作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审，若其工作得到确认，则继续下一项活动，否则返回前项，甚至更前项的活动进行返工。
        瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下的，而是呈线性图式，因此，瀑布模型存在严重的缺陷。
        （1）由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。
        （2）在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。
        （3）在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。
        ：瀑布模型适用于需求明确或很少变更的项目。
 
       生命周期
        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服务供方的服务过程、交付结果实施监督和绩效评估。
 
       系统架构
               客户机／服务器系统
               C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到客户机端和服务器端来实现，降低了系统的通信开销。目前大多数应用软件系统都是客户机／服务器形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和客户机／服务器应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
               浏览器／服务器系统
               B/S （Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（浏览器）实现，但是主要事务逻辑在服务器端（服务器）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握，成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（如LAN，WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。
               多层分布式系统（Multi-tier System）
               （1）概念。
               随着中间件与Web技术的发展，三层或多层分布式应用体系越来越流行。在多层体系中，各层次按照以下方式进行划分，实现明确分工：
               ①瘦客户：提供简洁的人机交互界面，完成数据的输入／输出。
               ②业务服务：完成业务逻辑，实现客户与数据库对话的桥梁。同时，在这一层中，还应实现分布式管理、负载均衡、Fail/Recover、安全隔离等。
               ③数据服务：提供数据的存储服务。一般就是数据库系统。
               （2）多层系统主要特点。
               多层系统主要特点是：
               .安全性。中间层隔离了客户直接对数据服务器的访问，保护了数据库的安全。
               .稳定性。对于要求24×7工作的业务系统，多层分布式体系提供了更可靠的稳定性。一是中间层缓冲Client与数据库的实际连接，使数据库的实际连接数量远小于Client应用数量。当然，连接数越少，数据库系统就越稳定。二是Fail/Recover机制能够在一台服务器宕机的情况下，透明地把客户端工作转移到其他具有同样业务功能的服务上。
               .易维护。由于业务逻辑在中间服务器，当业务规则变化后，客户端程序基本不做改动。
               .快速响应。通过负载均衡以及中间层缓存数据能力，可以提高对客户端的响应速度。
               .系统扩展灵活。基于多层分布体系，当业务增大时，可以在中间层部署更多的应用服务器，提高对客户端的响应，而所有变化对客户端透明。
               （3）多层系统举例。
               目前最为流行的两类多层应用架构为Sun的J2EE和Microsoft.Net，下面简单介绍J2EE的多层架构。
               
               J2EE多层应用架构
               （4）客户层。
               客户层用于与企业信息系统的用户进行交互以及显示根据特定商务规则进行计算后的结果。基于J2EE规范的客户端可以是基于Web的，也可以是不基于Web的独立（Stand Alone）应用程序。
               在基于Web的J2EE客户端应用中，用户在客户端启动浏览器后，从Web服务器中下载Web层中的静态HTML页面或由JSP或Servlets动态生成的HTML页面。
               在不基于Web的J2EE客户端应用中，独立的客户端应用程序可以运行在一些基于网络的系统中，例如手持设备或汽车电话等。同样，这些独立的应用也可以运行在客户端的Java Applet中。这种类型的客户端应用程序可以在不经过Web层的情况下直接访问部署在EJB容器（EJB Container）中的EJB组件。
               （5） Web层。
               J2EE规范定义的Web层由JSP页面、基于Web的Java Applets以及用于动态生成HTML页面的Servlets构成。这些基本元素在组装过程中通过打包来创建Web组件。运行在Web层中的Web组件依赖Web容器来支持诸如响应客户请求以及查询EJB组件等功能。
               （6）业务层。
               在基于J2EE规范构建的企业信息系统中，将解决或满足特定业务领域商务规则的代码构建成为业务层中的Enterprise JavaBean （EJB）组件。EJB组件可以完成从客户端应用程序中接收数据、按照商务规则对数据进行处理、将处理结果发送到企业信息系统层进行存储、从存储系统中检索数据以及将数据发送回客户端等功能。
               部署和运行在业务层中的EJB组件依赖于EJB容器来管理诸如事务、生命期、状态转换、多线程及资源存储等。这样由业务层和Web层构成了多层分布式应用体系中的中间层。
               （7）企业信息系统层。
               在企业应用系统的逻辑层划分中，企业信息系统层通常包括企业资源规划（ERP）系统、大型机事务处理（Mainframe Transaction Processing）系统、关系数据库系统（RDMS）及其他在构建J2EE分布式应用系统时已有的企业信息管理软件。
 
       详细设计
        总体设计只是为整个信息系统提供了一个设计思路和框架，框架内的血肉需要系统的设计人员在详细设计这个阶段充实。总体设计完成后，设计人员要向用户和有关部门提交一份详细的报告，说明设计方案的可行程度和更改情况，得到批准后转入系统详细设计。详细设计阶段主要是在总体设计的基础上，将设计方案进一步详细化、条理化和规范化，为各个具体任务选择适当的技术手段和处理方法。系统的详细设计一般包括如下。
        （1）代码设计。
        代码设计就是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。
        （2）数据库设计。
        数据库设计就是构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。
        （3）输入／输出设计。
        输入／输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。
        （4）用户界面设计。
        用户界面设计是指在用户与系统之间架起一座桥梁。主要内容包括：定义界面形式；定义基本的交互控制形式；定义图形和符号；定义通用的功能键和组合键的含义及其操作内容；定义帮助策略，等等。
        （5）处理过程设计。
        总体设计将系统分解为许多模块，并基本决定了每个模块的功能和界面。处理过程设计则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。通过处理过程设计，为编写程序制定一个周密的计划。一般来说，每一个功能模块都应设计一个处理流程。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       需求分析阶段
        . 确定软件的可靠性目标；
        . 分析可能影响可靠性的因素；
        . 确定可靠性的验收标准；
        . 制定可靠性管理框架；
        . 制定可靠性文档编写规范；
        . 制定可靠性活动初步计划；
        . 确定可靠性数据收集规范。
 
       需求说明书
        设计人员在需求分析的基础上对网络应用系统进行设计并形成需求说明书，在此基础上，用户、需求分析人员和设计人员要对之进行评审，确定设计的正确性与否的同时，验证网络需求的全面性、精确性和一致性，并使用户和网络设计人员对需求说明书的理解达成一致，另外还会根据实际情况对需求分析进行修订。
        需求说明书是由设计人员经需求分析后形成的网络设计文档，其内容更为系统、精确和全面，因为它必须服务于以下目标：
        （1）便于用户、分析人员和网络设计人员理解和交流。用户通过需求说明书在分析阶段即可初步判定目标网络系统能否满足其原来的期望，网络设计人员则将需求说明书作为网络设计的基本出发点。
        （2）支持目标网络系统的确认。网络系统建设的目标是否完成不应由网络测试阶段的人为因素决定，而应根据需求说明书中确定的可测试标准来决定。
        （3）控制系统进化过程。在需求分析完成后，如果用户追加需求，那么需求说明书将用于确定是否为新需求。
        需求说明书的主体包括功能与行为需求的描述及非行为需求描述两部分。功能与行为需求描述说明网络数据包的产生、传送和接收过程中各结点之间的相互关系。非行为需求是指网络系统在运作时应具备的各种属性，包括传输时间、带宽利用率、吞吐量、延迟等指标。
        为使需求说明书更加简洁易懂，其他内容不应写入需求说明书，如人员需求、成本预算、进度安排、网络设计方案等就不应写进去。
        完成需求说明书之后，要制订确认测试计划，其中主要内容有网络系统说明、进度安排、条件、测试资料、测试对象、人员培训、测试设计（系统容量、功能、性能、对应用的支持程度）、标准评价（范围、尺度、数据整理）。
 
       智慧城市
               智慧城市的概念及内涵
               国际电工委员会（IEC）对智慧城市的定义为：智慧城市是城市发展的新理念，是推动政府职能转变、推进社会管理创新的新方法，目标是使得基础设施更加智能、公共服务更加便捷、社会管理更加精细、生态环境更加宜居、产业体系更加优化。
               智慧城市是利用新一代信息技术来感知、监测、分析、整合城市资源，对各种需求做出迅速、灵活、准确反应，为公众创造绿色、和谐环境，提供泛在、便捷、高效服务的城市形态。新一代信息技术包括云计算、大数据、物联网、地理信息、人工智能、移动计算等，是“互联网+”在现代城市管理的综合应用，是“数字城市”发展的必然和全面跃升。
               智慧城市的参考模型
               智慧城市建设主要包括以下几部分：
               .通过传感器或信息采集设备全方位地获取城市系统数据。
               .通过网络将城市数据关联、融合、处理、分析为信息。
               .通过充分共享、智能挖掘将信息变成知识。
               .结合信息技术，把知识应用到各行各业形成智慧。
               智慧城市建设参考模型包括五个有依赖关系的功能层和三个对建设有约束关系的支撑体系，如下图所示。
               
               智慧城市建设参考模型
               五个功能层：
               .物联感知层：提供对城市环境的智能感知能力。
               .网络通信层：以互联网、电信网、广播电视网以及传输介质为光纤的城市专用网作为骨干传输网络，以覆盖全城的无线网络、移动4G为主要接入网，组成网络通信基础设施。
               .计算与存储层：包括软件资源、计算资源和存储资源，为智慧城市提供数据存储和计算，保障上层对数据汇聚的相关需求。
               .数据及服务支撑层：利用SOA（面向服务的体系架构）、云计算、大数据等技术，通过数据和服务的融合，支撑承载智慧应用层中的相关应用，提供应用所需的各种服务和共享资源。
               .智慧应用层：各种基于行业或领域的智慧应用及应用整合，如智慧交通、智慧家政等，为社会公众、企业、城市管理者等提供整体的信息化应用和服务。
               三个支撑体系：
               .安全保障体系：为智慧城市建设构建统一安全平台，实现统一入口、统一认证、统一授权、日志记录服务。
               .运营管理体系：为智慧城市建设提供整体的运维管理机制，确保智慧城市整体建设管理可持续运行。
               .标准规范体系：用于指导和支撑我国各地城市信息化用户、各行业智慧应用信息系统的总体规划和工程建设，同时规范和指导我国智慧城市相关IT产业的发展。
               智慧城市建设的指导思想、原则和目标
               我国智慧城市建设的指导思想为：
               按照走集约、智能、绿色、低碳的新型城镇化道路的总体要求，发挥市场在资源配置中的决定性作用，加强和完善政府引导，统筹物质、信息和智力资源，推动新一代信息技术的创新应用，加强城市管理和服务体系智能化建设，积极发展民生服务智慧应用，强化网络安全保障，有效提高城市综合承载能力和居民幸福感受，促进城镇化发展质量和水平全面提升。
               我国智慧城市建设的基本原则如下：
               .以人为本，务实推进。
               .因地制宜，科学有序。
               .市场为主，协同创新。
               .可管可控，确保安全。
               我国智慧城市建设的主要目标为：
               到2020年，建成一批特色鲜明的智慧城市，聚集和辐射带动作用大幅增强，综合竞争优势明显提高，在保障和改善民生服务、创新社会管理、维护网络安全等方面取得显著成效。其具体表现为：
               .公共服务便捷化。
               .城市管理精细化。
               .生活环境宜居化。
               .基础设施智能化。
               .网络安全长效化。
               智慧城市建设的主要内容
               智慧城市建设的关键内容如下：
               .科学制定智慧城市建设顶层设计
               加强顶层设计。
               推动构建普惠化公共服务体系。
               支撑建立精细化社会管理体系。
               促进宜居化生活环境建设。
               建立现代化产业发展体系。
               加快建设智能化基础设施。
               .切实加大信息资源开发共享力度
               加快推进信息资源共享与更新。
               深化重点领域信息资源开发利用。
               .积极运用新技术新业态
               加快重点领域物联网应用。
               促进云计算和大数据健康发展。
               推动信息技术集成应用。
               .着力加强网络信息安全管理和能力建设
               严格全流程网络安全管理。
               加强要害信息设施和信息资源的安全防护。
               强化安全责任和安全意识。
   题号导航      2017年上半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第3题    在手机中做本题