免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2011年上半年 信息系统项目管理师 下午试卷 案例
  第1题      
  知识点：   编码   测试阶段   评审   设计阶段   需求分析   需求文件   业务系统   银行业

 
某公司承接了一个银行业务系统的软件开发项目，质量要求非常高。项目经理小赵制定了项目的整体计划，将项目划分为需求、设计、编码和测试四个阶段，他将测试阶段预留了大量时间，以便开展充分的测试工作。
需求分析完成后，项目组编写了《需求分析报告》，项目经理小赵召集部分骨干人员召开评审会。为了尽快进入下一阶段工作，评审会从早上9点一直开到晚上9点，终于把全部的文件都审完了。评审组找到了几处小问题，并当场进行了修改，项目经理宣布可以设计阶段了。　　　
设计人员根据需求文件编写了《设计说明书》，并提交给小赵。小赵对设计文件仔细审阅后，便安排程序员开始编程。
编程结束后，进入了测试阶段。第一轮测试，发现了70个缺陷。项目组对发现的缺陷进行了修改，又重新提交了测试。第二轮又发现了100多个缺陷，就这样反复修改和测试，直到第六轮，发现了33个缺陷。各轮发现的缺陷数如下：

这时，小赵终于松了一口气，由于第六轮只剩下33个缺陷，他觉得测试工作应该很快就会结束了。
 
问题：1.1   请分析此项目的质量管理过程中存在哪些问题？
 
问题：1.2   请在答题纸上标出纵坐标的刻度值，并画出测试缺陷的趋势图。根据趋势图分析“小赵觉得测试工作很快就会结束了”是否有道理，并分析原因。
 
问题：1.3   请结合软件生命开发周期分析软件存在缺陷的可能原因。
 
问题：1.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）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。
        （4）协助承建单位建立质量保障体系。
        （5）协助承建单位完善现场质量管理制度。
        （6）组织设计文件及设计方案交底会，制定质量要求标准。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       需求文件
        需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始，可能只有高层级的需求，随着有关需求信息的增加而逐步细化。只有明确的、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
        需求文件的主要内容包括：
        .业务需求
        可跟踪的业务目标和项目目标。
        执行组织的业务规则。
        组织的指导原则。
        .干系人需求
        对组织其他领域的影响。
        对执行组织内部或外部团体的影响。
        干系人对沟通和报告的需求。
        .解决方案需求
        功能和非功能需求。
        技术和标准合规性需求。?支持和培训的需求。
        质量需求。
        报告需求（可用文本记录或用模型展示解决方案需求，也可两者同时使用）。
        .项目需求
        服务水平、绩效、安全和合规性等。
        验收标准。
        .过渡需求
        .与需求相关的假设条件、依赖关系和制约因素
 
       业务系统
        该重工集团有自己的管理模型。顶端按照工业4.0，集团管控，包括阿米巴经营模式；相应的流程制度，岗位职责，工作标准，成本绩效。左边是信息化管控，右边是智能化建设，下面是精益管理，底下是企业文化。这样的管理需要用信息化系统去实现。
        在这架构中，ERP系统是基础，利用CRM系统和客户对接，SRM管理供应链，MES监控生产。利用OA把所有业务打通，而后利用专业软件，实现前端的商务智能分析。
        下图的物联网设想把MES系统和机床、物流以及检测设备连起来，做成物联化，把ERP升级到CRM或者SCRM，把供应商和客户打通，形成企业的互联网。
        
        智能工厂物联网体系
        下图是整个业务系统的总体架构图。一个平台、两级部署、三层应用，包括商业分析、移动应用、企业门户和协同管理。
        
        智能工厂业务系统整体架构
        在业务系统这块，先后上线了ERP系统、PLM系统、OA系统和MES系统。上线的这些系统，虽然参与了生产、管理，打通了业务，却没有让领导层参与，反馈报告依然采用Excel、PPT。作为决策者，领导层更应该参与数据的可视化呈现过程。所以，2014年上线了帆软报表系统，提升了数据前端展示，利用某报表软件承担的BOSS系统决策，将领导层纳入管理体系。
 
       银行业
        银行信息系统是指基于信息技术，以前后台处理、柜面服务和自助服务为主要功能，实现银行业务自动化处理的综合信息系统。
        （1）可用性要求级别高。金融业务活动频繁，业务类型与业务量增长快，银行信息系统的功能需要不断地扩充、改进与完美，并同步集成到网上银行、自助银行、电话银行、手机银行。因此，银行业务系统的运维对持续性与稳定性方面的要求很高，如“5个9”（99.999%）或“6个9”（99.9999%）级别的可用性，即业务系统的非计划年度宕机时间不可超过5分钟或30秒。
        （2）安全性要求级别高。银行业务的客户端应用变得形式多样，在这些业务中留有很多对外开放的接口，增加了黑客攻击的渠道；又由于银行的特殊性，银行信息系统自然成为黑客攻击的主要目标，对于各类应用尤其是Web类的应用，安全运维不可懈怠。
        （3）数据运维责任重大。金融业正在加快实现全国数据集中处理，在提高管理效率和降低运维成本的同时，却由于技术风险中产生新的金融风险，如数据集中牵一发而动全身，数据处理响应的实时性、大规模数据处理的高并发性，使得数据中心的运维压力日益加大。
   题号导航      2011年上半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第1题    在手机中做本题