免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2013年上半年 信息系统项目管理师 下午试卷 案例
  第2题      
  知识点：   项目组织   编码   单元测试   第三方测试   调试   活动清单   集成测试   监理单位   平台建设   详细设计   需求分析   硬件   用户需求

 
W公司与所在城市电信运营商Z公司签订了该市的通信运营平台建设合同。W公司为此成立了专门的项目团队，由李工担任项目经理，参加项目的还有监理单位和第三方测试机构。李工对项目工作进行了分解，制作出如下表所示的任务清单。经过分析后李工认为进度风险主要来自需求分析与确认环节，因此在活动清单定义的总工期基础上又预留了4周的应急储备时间。该时度计划得到了Z公司和监理单位的认可。

在项目启动与人员、资源调配（任务A）阶段，李工经过估算后发现编码、单元测试、集成测试（任务F）的技术人员不足。经公司领导批准后，公司人力资源部开始招聘技术人员，项目前期工作进展顺利，进入详细设计（任务E）后，负责任务E的骨干老杨提出，详细设计小组前期没有参加需求调研和确认，对需求文档的理解存在疑问。经过沟通后，李工邀请Z公司用户代表和项目团队相关人员召开了一次推进会议。会后老杨向李工提出，由于先前对部分用户需求的理解有误，须延迟4周才可完成详细设计。考虑到进度计划中已预留了4周的时间储备，李工批准了老杨的请求，并按原进度计划继续执行。
任务E延迟4周完成后，项目组织开始编码、单元测试和集成测试（任务F）。此时人力资源部招聘的新员工陆续到职，为避免进度延误，李工第一时间安排他们上岗。新招聘的员工大多是应届毕业生，即便有老员工带领，工作效率仍然不高。与此同时，W公司领导催促李工加快进度，李工只得组织新老员工加班。虽然他们每天加班，可最终还是用了20周才完成原来计划用15周完成的任务F。此时已临近春节假期，在李工的提议下，W公司决定让项目组在假期结束前提前1周入驻Z公司进行现场安装与软硬件联合调试。由于Z公司和监理单位春节期间只有值班人员，无法很好地配合项目组工作，导致联合调试工作进展不顺利。为了把延误的进度赶回来，经公司同意，春节后一上班，李工继续组织项目团队加班。此时许多成员都感到身心疲惫，工作效率下降，对项目经理的安排充满了抱怨。
 
问题：2.1   根据任务清单，将前导图填充完整，并指出项目的关键路径、计算计划总工期、活动C 和G的总时差（总浮动时间）。
 
问题：2.2   结合本案例简要叙述项目经理在进度管理中存在的主要问题。
 
问题：2.3   如果你是项目经理，请结合本案例简要叙述后续可采取哪些应对措施。
 
问题：2.4   除了采取进度网络分析，关键路径法和进度压缩技术外，请指出李工在制定进度计划时还可以采用那些方法或工具。
 
 
 

   知识点讲解    
   · 项目组织    · 编码    · 单元测试    · 第三方测试    · 调试    · 活动清单    · 集成测试    · 监理单位    · 平台建设    · 详细设计    · 需求分析    · 硬件    · 用户需求
 
       项目组织
        组织结构一般有三种类型：职能型、矩阵型和项目型。矩阵型可进一步划分为弱矩阵、平衡矩阵和强矩阵。不同组织结构的区别如下表所示。
        
        组织机构的三种类型
        组织文化
        大多数组织已经形成了自己独特的、可描述的文化。这些文化体现在：
        .组织的共同价值观、行为准则、信仰和期望。
        .组织的方针、办事程序。
        .组织对于职权关系的观点。
        .众多其他的因素。
        .组织文化常常会对项目产生直接的影响。
 
       编码
               编码过程
               在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：
               （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）单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等，而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计，而不仅仅定位于代码的实现。
        （3）单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
               单元测试的特性
               单元测试具有如下特性：
               （1）单入测试是覆盖代码区间的最小单元。
               （2）单元测试支持组包测试。
               （3）单元测试的执行率为100%。
               （4）单元测试确定变动后的代码对原代码的功能未做修改。
               （5）单元测试提升了软件系统整体的可信赖度。
               （6）单元测试包含对可能出现问题的代码进行排查。
               （7）单元测试支持开发人员先测试后编码的行为。
               （8）单元测试支持变化，任何变化导致的失败情况均会被反映出来。
               （9）单元测试准确地反映了代码设计，便于后期维护。
               单元测试的认识误区
               （1）单元测试是全部规范。单元测试本质上是种特定的测试方式，是系统的实现方法规范的补充，而不是整个规范。
               （2）单元测试浪费时间。单元测试不会浪费太多的时间，反而会节省项目时间。
               （3）单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖，必须进行人工检查。
               （4）单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例，不仅仅只是对代码的测试。
               单元测试的原则
               单元测试需要遵守如下原则。
               （1）单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档，根据详细设计编写单元测试用例，而不能根据代码编写单元测试用例。
               （2）单元测试执行前先检查单元测试入口条件是否全部满足。
               （3）单元测试必须满足一定的覆盖率，重要的接口函数必须做单元测试。
               （4）单元测试在修改代码后修改测试用例，将全部单元测试用例进行回归测试。
               （5）单元测试必须满足预定的出口条件才能结束。
               （6）在单元测试完成后，记录《单元测试报告》，分析问题的种类和原因。
               （7）单元测试始终在配置管理控制下进行，软件问题的修改必须符合变动规程的要求。
               （8）单元测试文档、测试用例、测试记录和被测程序等齐全，符合规范。
               单元测试的主要任务
               单元测试主要针对程序模块进行测试，主要有5个任务：模块接口、局部数据结构、执行路径、出错处理和边界条件。
                      模块接口测试
                      通过对被测模块的数据流进行测试，检查进出模块的数据是否正确。因此，必须对模块接口，包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容：
                      .模块接受输入的实际参数个数与模块的形式参数个数是否一致。
                      .输入的实际参数与模块的形式参数的类型是否匹配。
                      .输入的实际参数与模块的形式参数所使用的单位是否一致。
                      .调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
                      .调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。
                      .调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位是否一致。
                      .调用内部函数时，参数的个数、属性和次序是否正确。
                      .在模块有多个入口的情况下，是否引用有与当前入口无关的参数。
                      .是否修改了只读型参数。
                      .全局变量是否在所有引用它们的模块中都有相同的定义。
                      局部数据结构测试
                      测试用例检查局部数据结构的完整性，如数据类型说明、初始化、默认值等方面的问题，并测试全局数据对模块的影响。
                      在模块的工作过程中，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
                      局部数据结构应注意以下几类错误：不正确或不一致的类型说明；错误的初始化或默认值；错误的变量名，如拼写错误或书写错误；下溢、上溢或者地址错误。
                      执行路径测试
                      测试用例对模块中重要的执行路径进行测试，其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
                      常见的错误有误解或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。
                      针对判定和条件覆盖，测试用例能够发现的错误有：不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。
                      出错处理测试
                      测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。
                      检验程序中的出错处理可能面对的情况有以下几种：
                      .对运行发生的错误描述难以理解。
                      .所报告的错误与实际遇到的错误不一致。
                      .出错后，在错误处理之前就引起系统的干预。
                      .例外条件的处理不正确。
                      .提供的错误信息不足，以致无法找到错误的原因。
                      边界条件测试
                      边界条件测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处，测试模块是否能够正常工作。
                      一些与边界有关的数据类型，如数值、字符、位置、数量、尺寸等，以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
                      在边界条件测试中，应设计测试用例检查一下情况。
                      .在n次循环的第0次、第1次、第n次是否有错误。
                      .运算或判断中取最大值、最小值时是否有错误。
                      .数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
               单元测试的执行过程
               通常，单元测试在编码阶段进行，在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，开始设计单元测试用例。
               由于模块并不是一个独立的程序，在考虑测试模块时，同时要考虑与其有关的外界联系，因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种：
               （1）驱动（Drive）模块。用于模拟被测试模块的上一级模块，相当于被测模块的主程序，用于接收测试数据，并把这些数据传送给被测模块，启动被测模块，最后输出实测结果。
               （2）桩（Stub）模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理，不需要把子模块的所有功能都带进来，但不允许什么事情也不做。
               单元测试停止的条件
               单元测试停止的条件如下。
               （1）单元测试用例设计已经通过评审。
               （2）按照单元测试计划完成了所有规定单元的测试。
               （3）达到了测试计划中关于单元测试所规定的覆盖率的要求。
               （4）被测试的单元每千行代码必须发现至少3个错误。
               （5）软件单元功能与设计相一致。
               （6）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
       第三方测试
        这里所说的第三方测试是指独立于软件公司自身测试的测试。所谓的第三方是指在软件公司和软件用户之间的一方。第三方测试机构也是一个中介的服务机构，它通过自己专业化的测试手段为客户提供有价值的服务。但是第三方测试机构提供的服务不同于公司内部的测试。因为，第三方测试机构的测试除了发现软件问题之外，还有对软件进行科学、公正的评价的职能，这就要求第三方测试机构要保持公正、廉洁、客观、科学、独立的态度。
        第三方测试机构存在的价值主要是由软件公司、软件用户以及国家的公正诉求所决定的。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，第三方测试机构独立公正的地位有助于对被测软件进行客观公正的评价，帮助用户选择合适、优秀的软件产品。而对于一些信息工程项目来说，在验收之前，经过第三方机构的严格测试，可以最大程度地避免信息行业的“豆腐渣”工程。此外，经过国家认可的第三方测试机构，还为国家软件产品的质量监督抽查提供独立公正的测试支持。
        由此可见，第三方测试机构的测试工程师面对的是各种各样的系统，而且大多与具体的业务相关，这就要求他们不仅有宽广深厚的软件技术功底、测试技术功底，而且需要积累行业知识和经验，并且要融会贯通。目前，我国涌现了很多的第三方测试机构，虽然它们处于不同的发展阶段，但是它们的存在必将对我国整个软件产业的健康发展起到巨大的促进作用。
 
       调试
        调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。
 
       活动清单
        活动清单是包含项目所需的全部活动的综合清单。活动清单中包括每个活动的标识及工作范围详述，以保证项目团队成员知道需要完成什么工作。每个活动都应该有一个独特的名称，用来表示它在进度计划中的位置。
 
       集成测试
        集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
        . 组装时需要考虑的问题。
        ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
        ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
        ③各个子功能组合起来，能否达到预期要求的父功能；
        ④全局数据结构是否有问题；
        ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
        因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
        子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
        选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
        . 模块组装成为系统的方式。
        模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
        ①一次性组装方式（big bang）。
        它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
        
        一次性组装方式
        在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
        ②增殖式组装方式。
        这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
        . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
        
        自顶向下的增殖方式
        自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
        . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
        以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
        
        一次性组装方式
        
        自底向上的增殖方式
        . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
        自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
        自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
        在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
        . 满足某些软件需求；
        . 在程序的模块结构中位于较高的层次（高层控制模块）；
        . 较复杂、较易发生错误；
        . 有明确定义的性能要求。
        在做回归测试时，也应该集中测试关键模块的功能。
        . 集成测试的组织和实施。
        集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
        ①采用何种系统组装方法来进行集成测试。
        ②集成测试过程中连接各个模块的顺序。
        ③模块代码编制和测试进度是否与集成测试的顺序一致。
        ④测试过程中是否需要专门的硬件设备。
        解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
        在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
        . 集成测试完成的标志。
        集成测试完成的标志主要有以下几项。
        ①成功地执行了测试计划中规定的所有集成测试。
        ②修正了所发现的错误。
        ③测试结果通过了专门小组的评审。
        集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
        在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
        集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
 
       监理单位
        项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。
        根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。
        （1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。
        （2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。
        （3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
        监理单位的主要作用如下。
        （1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。
        （2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。
        （3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。
 
       平台建设
               底层平台
               在区块链产业，平台级的机会是目前很多公司关注的方向。无论是创业公司还是大公司，纷纷在布局区块链底层平台，希望能抢占下一波红利。但是，由于区块链还处于非常早期的阶段，因此各家对于平台的理解和实践路径并不一样。目前，公有链、联盟链和BaaS是三种比较主流的平台模式。
               （1）公有链。公有链是指向全世界所有人开放，每个人都能成为系统中的一个节点参与记账的区块链，它们通常将激励机制和加密数字验证相结合，来实现对交易的共识。目前，公有链被看作是区块链领域最有前景的方向，因为它更符合区块链的本质，很可能成为下一个系统级的平台。
               （2）联盟链。联盟链是指若干个机构共同参与记账的区块链，即联盟成员之间通过对多中心的互信来达成共识。联盟链的数据只允许系统内的成员节点进行读写和发送交易，并且共同记录交易数据。联盟链作为支持分布式商业的基础组件，更能满足分布式商业中的多方对等合作与合规有序发展要求。联盟链和公链相比，在高可用、高性能、可编程，隐私保护上更有优势，它被认为是“部分去中心”或者是“多中心”的区块链。
               （3）BaaS。BaaS通常是一个基于云服务的企业级的区块链开放平台，可一键式快速部署接入、拥有去中心化信任机制、支持私有链、联盟链或多链，拥有私有化部署与丰富的运维管理等特色能力。BaaS目前可广泛应用于金融、医疗、零售、电商、游戏、物联网、物流供应链、公益慈善等行业中，重塑商业模式，提升客户在行业内的影响力。
               公有链与联盟链/BaaS虽然采取了不同的策略和发展路径，但是两者依然会长期共存，甚至有些平台最后可能会殊途同归，或者通过跨链技术将分散的联盟链系统与公链相连接，形成更大范围的价值互联网产业生态。
               数字资产存储
               区块链产业的发展需要有新型的数字资产存储方式，这就催生了数字钱包的诞生。数字钱包提供钱包地址的创建、数字加密资产的转账、钱包地址的历史交易查询等功能。数字钱包按照密码学原理，可以创建一个或多个钱包地址，每个钱包地址对应一个密钥对：私钥和公钥。在数字加密资产的世界里，私钥是最重要的，它是数字加密资产所有权的唯一凭证，因为公钥和地址均能通过私钥推导出来。因此，私钥的生成和存储方式决定了数字加密资产的安全性，而数字钱包的主要作用就是帮助用户管理和使用私钥。安全是数字钱包的根基，一个安全的数字钱包应该能在任何时候都让用户的私钥／助记词处于安全保护之下。目前，数字钱包类型主要分为冷钱包和热钱包等。冷钱包就是不联网的钱包，也叫离线钱包；热钱包就是保持联网上线的钱包，也就是在线钱包。冷钱包不联网会比热钱包更安全，因为它能保证私钥不接触网络，从而防止私钥被黑客窃取。
               此外，去中心化也是区块链领域数字钱包发展的一大特点。中心化钱包和去中心化钱包的最根本区别就是，私钥是否自持。去中心化钱包的特点包括：①私钥是用户自持，当然密码也是用户自持；②资产是存储在区块链上，而不是托管在中心化的服务器上，并且目前也无需实名认证，即可生成钱包；③无法实现“账户冻结”“交易回滚”等操作。因此，去中心化钱包很难遭受黑客的集中攻击，用户也不用担心钱包服务商出现监守自盗的情况。
               区块链技术解决方案
               区块链解决方案主要是指在底层平台的基础上进行扩展，目的是便于开发者基于区块链技术开发出产品和应用，或者是服务商直接为客户提供针对具体业务场景的解决方案。
 
       详细设计
        总体设计只是为整个信息系统提供了一个设计思路和框架，框架内的血肉需要系统的设计人员在详细设计这个阶段充实。总体设计完成后，设计人员要向用户和有关部门提交一份详细的报告，说明设计方案的可行程度和更改情况，得到批准后转入系统详细设计。详细设计阶段主要是在总体设计的基础上，将设计方案进一步详细化、条理化和规范化，为各个具体任务选择适当的技术手段和处理方法。系统的详细设计一般包括如下。
        （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       硬件
        硬件是计算机物理设备的总称，也称为硬件设备，通常是电子的、机械的、磁性的或光的元器件或装置，一般分为中央处理器、存储器和输入、输出设备。
 
       用户需求
        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段，应始终保持与关键人员之间的交流，以确保网络工程建设不偏离用户需求。
        用户服务表用于表示收集和归档的需求信息，也用来指导管理人员和网络用户进行讨论。
   题号导航      2013年上半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第2题    在手机中做本题