免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2013年上半年 系统集成项目管理工程师 下午试卷 案例
  第1题      
  知识点：   评审   CMM   CMMI   编码   查找   概要设计   集成测试   能力成熟度模型   数据库   数据库设计   数据库设计说明   图形   系统测试   需求分析

 
公司承接了一个信息系统开发项目，按照能力成熟度模型CMMI制订了软件开发的流程与规范，委派小赵为这个项目的项目经理。小赵具有3年的软件项目开发与管理经验。公司认为这个项目的技术难度比较低，把两个月前刚从大学招聘来的9个计算机科学与技术转移的应届毕业生分配到这个项目组，这样，项目开发团队顺利建立了。项目的开发按照所制定的流程规范进行。在需求分析、概要设计、数据库设计等阶段都按照要求进行了评审，编写了需求分析说明书、概要设计说明书、数据库设计说明书等文档。但在项目即将交付时，发现了很多没有预计到的缺陷与BUG。这说明许多质量问题并没有像原来预计的那样在检查与评审中发现并予以改正。由于项目的交付期已经临近，为了节省时间，小赵让程序员将每个模块编码完成后仅由程序员自己测试一下，就进行集成测试和系统测试。在集成测试和系统测试的过程中，由于模块的BUG太多，集成测试越来越难，该项目没有能够按照客户的质量要求如期完成。为了查找原因，公司的质量部门调查了这一项目的进展情况，绘制了下面的图形（如图1 所示）：
 
问题：1.1   图1是一种质量控制所采用的工具，叫做（1）图。根据上述描述，图中的A应该是（2）。请讲上面（1）、（2）处的答案填写在答题纸的对应栏内。
 
问题：1.2   质量控制中所依据的一个最重要的模型是计划、执行、检查、行动。请根据这一模型，给出质量控制的基本步骤。
 
问题：1.3   分析本案例中产生质量问题的原因。
 
问题：1.4   针对案例中项目的现状，假设项目无重大设计缺陷，为完成该项目，从质量管理的角度，给出改进措施。
 
 
 

   知识点讲解    
   · 评审    · CMM    · CMMI    · 编码    · 查找    · 概要设计    · 集成测试    · 能力成熟度模型    · 数据库    · 数据库设计    · 数据库设计说明    · 图形    · 系统测试    · 需求分析
 
       评审
        在软件开发各个阶段都要进行评审。
 
       CMM
        CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。
        （1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。
        （2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
        （3）已定义级：用于管理方面和工程方面的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。
        （4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。
        （5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。
        在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域（Key Process Area，KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。每个级别对应的关键过程域见下表。
        
        关键过程域的分类
 
       CMMI
        与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。
        CMMI可以看做把各种CMM集成到一个系列的模型中了，CMMI的基础源模型包括软件CMM 2.0版（草稿C）、EIA-731系统工程，以及集成化产品和过程开发IPD CMM（IPD）0.98a版等。CMMI也描述了5个不同的成熟度级别。
               CMMI的表示方法
               每一种CMMI模型都有两种表示法，即阶段式和连续式。这是因为在CMMI的三个源模型中，CMM是“阶段式”模型，系统工程能力模型是“连续式”模型，而集成产品开发（IPD）CMM是一个混合模型，组合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势，都有很多支持者，因此，CMMI产品开发群组在集成这三种模型时，为了避免由于淘汰其中任何一种表示法而失去用户对CMMI的支持，并没有选择单一的结构表示法，而是为每一个CMMI都推出了两种不同表示法的版本。
               不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考查基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考查整个组织的过程成熟度阶段，其关键术语是“成熟度”。
               尽管两种表示法的模型在结构上有所不同，但CMMI产品开发群组仍然尽最大努力确保了两者在逻辑上的一致性，两者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表示法中都一样，特定实践和共性实践在两种表示法中也不存在根本区别。因此，模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进时，可以从实用角度出发选择某一种偏爱的表示法，而不必从哲学角度考虑两种表示法之间的差异。
               CMMI的级别
               阶段式模型也把组织分为以下5个不同的级别。
               （1）初始级。代表了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能。
               （2）已管理级。代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。
               （3）严格定义级。代表了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。
               （4）定量管理级。代表了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。
               （5）优化级。代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。
               CMMI的目标
               CMMI的具体目标是：
               （1）改进组织的过程，提高对产品开发和维护的管理能力。
               （2）给出能支持将来集成其他科目CMM的公共框架。
               （3）确保所开发的全部有关产品符合将要发布的关于软件过程改进的国际标准ISO/IEC 15504对软件过程评估的要求。
               CMMI的优点
               使用在CMMI框架内开发的模型具有下列优点。
               （1）过程改进能扩展到整个企业级。
               （2）先前各模型之间的不一致和矛盾将得到解决。
               （3）既有分级的模型表示，也有连续的模型表示，可任意选用。
               （4）原先单科目过程改进的工作可与其他科目的过程改进工作结合起来。
               （5）基于CMMI的评估将与组织原先评估得分相协调，从而保护当前的投资，并与ISO/IEC 15504评估结果相一致。
               （6）节省费用，特别是当要运用多科目改进时，以及进行相关的培训和评估时。
               （7）鼓励组织内各科目之间进行沟通和交流。
 
       编码
               编码过程
               在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：
               （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）哈希表及其查找
        根据设定的哈希函数H（key）和处理冲突的方法，将一组关键字映射到一个有限的连续地址集上，并以关键字在地址集中的像作为记录在表中的存储位置，这种表称为哈希表，也称散列表。这一过程所得到的存储位置称为散列地址，由此形成的查找方法称为散列查找。
 
       概要设计
        1）设计软件系统总体结构
        设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
        2）数据结构及数据库设计
        （1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
        （2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。
        ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。
        ②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。
        ③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
        3）编写概要设计文档
        文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
        4）评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。
 
       集成测试
        集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
        . 组装时需要考虑的问题。
        ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
        ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
        ③各个子功能组合起来，能否达到预期要求的父功能；
        ④全局数据结构是否有问题；
        ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
        因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
        子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
        选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
        . 模块组装成为系统的方式。
        模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
        ①一次性组装方式（big bang）。
        它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
        
        一次性组装方式
        在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
        ②增殖式组装方式。
        这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
        . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
        
        自顶向下的增殖方式
        自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
        . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
        以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
        
        一次性组装方式
        
        自底向上的增殖方式
        . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
        自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
        自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
        在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
        . 满足某些软件需求；
        . 在程序的模块结构中位于较高的层次（高层控制模块）；
        . 较复杂、较易发生错误；
        . 有明确定义的性能要求。
        在做回归测试时，也应该集中测试关键模块的功能。
        . 集成测试的组织和实施。
        集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
        ①采用何种系统组装方法来进行集成测试。
        ②集成测试过程中连接各个模块的顺序。
        ③模块代码编制和测试进度是否与集成测试的顺序一致。
        ④测试过程中是否需要专门的硬件设备。
        解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
        在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
        . 集成测试完成的标志。
        集成测试完成的标志主要有以下几项。
        ①成功地执行了测试计划中规定的所有集成测试。
        ②修正了所发现的错误。
        ③测试结果通过了专门小组的评审。
        集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
        在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
        集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
 
       能力成熟度模型
        能力成熟度模型（简称CMM）是对一个组织机构的能力进行成熟度评估的模型。成熟度级别一般分成五级：1级-非正式执行、2级-计划跟踪、3级-充分定义、4级-量化控制、5级-持续优化。其中，级别越大，表示能力成熟度越高，各级别定义如下：
        . 1级-非正式执行：具备随机、无序、被动的过程；
        . 2级-计划跟踪：具备主动、非体系化的过程；
        . 3级-充分定义：具备正式的、规范的过程；
        . 4级-量化控制：具备可量化的过程；
        . 5级-持续优化：具备可持续优化的过程。
        目前，网络安全方面的成熟度模型主要有SSE-CMM、数据安全能力成熟度模型、软件安全能力成熟度模型等。
               SSE-CMM
               SSE-CMM（Systems Security Engineering Capability Maturity Model）是系统安全工程能力成熟度模型。SSE-CMM包括工程过程类（Engineering）、组织过程类（Organization）、项目过程类（Project）。各过程类包括的过程内容如下表所示。
               
               SSE-CMM系统安全工程能力成熟度模型过程清单
               SSE-CMM的工程过程、风险过程、保证过程的相互关系如下图所示。
               
               SSE-CMM的工程过程、风险过程、保证过程关联图
               SSE-CMM的工程过程关系如下图所示。
               
               SSE-CMM的工程过程关联图
               SSE-CMM的工程质量来自保证过程，如下图所示。
               
               SSE-CMM的保证过程图
               数据安全能力成熟度模型
               根据《信息安全技术数据安全能力成熟度模型》，数据安全能力成熟度模型架构如下图所示。
               
               数据安全能力成熟度模型架构
               数据安全能力从组织建设、制度流程、技术工具及人员能力四个维度评估：
               .组织建设——数据安全组织机构的架构建立、职责分配和沟通协作；
               .制度流程——组织机构关键数据安全领域的制度规范和流程落地建设；
               .技术工具——通过技术手段和产品工具固化安全要求或自动化实现安全工作；
               .人员能力——执行数据安全工作的人员的意识及专业能力。
               详细情况参考标准。
               软件安全能力成熟度模型
               软件安全能力成熟度模型分成五级，各级别的主要过程如下：
               . CMM1级——补丁修补；
               . CMM2级——渗透测试、安全代码评审；
               . CMM3级——漏洞评估、代码分析、安全编码标准；
               . CMM4级——软件安全风险识别、SDLC实施不同安全检查点；
               . CMM5级——改进软件安全风险覆盖率、评估安全差距。
 
       数据库
        数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       数据库设计
        数据库的设计质量对整个系统的功能和效率有很大的影响。数据库设计的核心问题是：从系统的观点出发，根据系统分析和系统设计的要求，结合选用的数据库管理系统，建立一个数据模式。设计的基本要求是：
        .符合用户需求，能正确反映用户的工作环境
        .设计与所选用的DBMS所支持的数据模式相匹配
        .数据组织合理，易操作、易维护、易理解
               数据库设计步骤
               数据库的设计过程可以分为4个阶段，即用户需求分析、概念结构设计、逻辑结构设计和物理结构设计。下图反映和分析了这一设计过程，其中：
               
               数据库设计步骤
               .用户需求分析是对现实世界的调查和分析
               .概念结构设计是从现实世界向信息世界的转换。根据用户需求来进行数据库建模，也称为概念模型，常用实体关系模型表示。
               .逻辑结构设计是从信息世界向数据世界的转化。将概念模型转化为某种数据库管理系统所支持的数据模型。
               .物理结构设计是为数据模型选择合适的存储结构和存储方法。
               用户需求分析
               用户需求分析需要结合具体的业务需求分析，确定信息系统的各类使用者以及管理员对数据及其处理、数据安全性和完整性的要求。主要设计如下三方面：
               （1）系统应用环境分析。
               系统应用环境及系统所服务和运行的特殊组织环境。不同业务单位有不同的组织结构和业务工作流程。环境的特殊性将决定数据库的整体设计思路和风格。
               （2）用户数据需求及加工分析。
               用户需求及加工分析指用户希望从数据库中获得那些信息以及对信息的处理要求。由此决定数据库中应该存储哪些信息以及对数据需要进行哪些加工处理，包括在处理过程中特定的查询要求、响应时间要求，以及数据安全性、保密性、完整性和一致性等方面的要求，应在此基础上编制数据字典。
               （3）系统约束条件分析。
               系统约束条件分析及分析现有系统的规模、结构、资源和地理分布，明确现有系统存在的种种限制或约束，从而使系统设计不至于脱离实际条件，确保系统设计顺利实施。
               数据库概念结构设计
               概念结构设计是指由现实世界的各种客观事物及其联系转化为信息世界中的信息模型的过程，即为数据库的概念结构设计。E-R模型即实体-联系模型是描述数据库概念结构的有力工具。下面结合实例说明E-R模型的构建。
               在一个政府部门中存在着多个不同科室，每一个由若干名科员构成，每个科室都有一名主管上级领导，科室公务员负责为前来机关办事的群众提供相关的服务。现分别画出各个科室的E-R模型图，再画出整个机关的E-R模型。
               一个科室结构应包括：
               （1）实体，即上级领导、科室、科员、群众。
               （2）实体联系，主管领导与科室之间是一对多的关系，科室与科员之间的联系也是一对多的关系，科员与群众之间是多对多的关系。
               （3）各个实体所具有的属性。
               .主管上级领导，属性可以有编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室的属性可以包括科室号
               .科员的属性包括编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众属性包括服务日期、服务事宜、处理结果
               .服务，包括服务日期、服务事宜、处理结果
               通过以上分析，可以得到如下的E-R模型，如下图所示（部分属性）。
               
               科室E-R模式图
               数据库逻辑结构设计
               逻辑结构设计的任务是要将概念结构设计阶段完成的概念模型转换成能被选定的数据库管理系统支持的数据模型。现行的数据库管理系统一般支持网状、层次和关系三种数据模型中的一种，其中关系型的数据模型在DBMS中的应用和支持较为广泛，已成为主流。
               下面简单介绍一下由E-R模型转换为关系数据模型的转化规则。在关系数据模型下，数据的逻辑结构是一张二维表，每个关系为一张二维表格。E-R模型转换为关系数据模型的转化规则如下。
               .每一实体及其属性对应于一个关系模式。实体名作为关系名，实体的属性作为对应关系的属性。所谓关系模式，就是对关系的描述，用关系名（属性1、属性2、属性3，……属性n）来表示。
               .两两实体之间的联系及其属性一般对应一个关系模式，联系名作为对应的关系名，联系的属性作为对应关系的属性；不带属性的联系可以去掉。
               .实体和联系中关键字属性在关系模式中仍作为关键字。
               上图中所示的实体关系图可以按照这些转换规则进行转化得到如下对应的关系模型。
               .主管上级领导，编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室，包括主管上级领导编号、科室号
               .科员，包括科室号、编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众，包括来访者编号、姓名、性别、年龄、来访日期、服务事宜
               .服务，包括受理公务员编号、来访者编号、服务日期、服务事宜、处理结果
               不同的系统配备的数据库管理系统性能不同，因而必须结合具体DBMS的性能和要求将一般数据模型转换成所选用的数据管理系统支持的数据模型，若选用的DBMS支持层次、网络模型，则还要完成从关系模型向层次或网络模型的转换。
               数据库物理结构设计
               数据库的物理设计以逻辑结构设计的结果为输入，结合关系数据库系统的功能和应用环境、存储设备等具体条件为数据模型选择合适的存储结构和存储方法。从而提高数据库的效率。物理结构设计的主要任务如下。
               （1）确定存储结构。
               根据用户对数据结构和处理的要求，权衡数据存取时间、空间利用率和维护代价等三方面的利弊，综合考虑存储效率、维护成本等相关因素，从数据库管理系统提供的各种存储结构（例如顺序存储结构、索引存储结构，等等）中，选取合适的结构并加以实现。
               （2）选择和调整存储路径。
               数据库必须支持多个用户的多种应用，因此必须提供多个存取入口、多条存取路径，建立多个辅助索引。此过程中需要考虑一些问题，例如如何选取合适的数据项建立索引，如何建立辅助索引从而达到检索效率和存储空间的统一等。
               （3）确定数据存储位置。
               按照不同的应用可将数据分为若干个组。根据各组数据利用频率和存储要求的不同，各类数据的存放位置、存储设备以及区域划分都应有所不同。应该把存取频率和存取速度要求较高的数据存储在高速存储器上，把存取频率和存取速度要求较低的数据存储在低速存储器上。
               （4）确定存储分配。
               大多数据库管理系统会提供一些存储分配参数，例如溢出区大小、块大小、缓冲区大小和个数等，设计人员应全面考虑这些参数，以进行物理优化。
               （5）确定数据的完整性与安全性约束。
               进行物理设计时不仅要考虑所选用数据库管理系统提供的安全机制和完整性约束，还要考虑用户使用制度、应用程序、计算机系统等各个涉及具体应用的方面。
               （6）考虑数据恢复方案。
               数据库的物理设计阶段也要考虑数据库的恢复问题，采取必要的物理措施和手段，为突发事件和故障后的恢复做好准备，提供必要的物理工具。
 
       数据库设计说明
        数据库设计是指数据库应用系统的设计。编制数据库设计说明书的目的是对设计中的数据结构的所有标识、逻辑结构和物理结构做出具体的设计规定。编写提纲和内容要求如下。
        （1）概述。
        .目标，说明开发的意图、应用目标、作用范围以及有关数据库开发的背景材料
        .主要功能，简要说明数据库系统的主要功能。
        .用户的安排，指最终用户。说明操作人员、数据管理人员和维护人员的水平。
        （2）需求规定。
        .性能规定
        .精度，简述对数据精度的要求。
        .有效性，说明对数据库存取数据的有效性的要求。
        .时间要求，如响应时间、数据的转换和传送时间等。
        .其他专门要求。
        （3）运行环境要求。
        .设备，简述运行数据库系统的硬设备及其专门功能。
        .支撑软件，列出支撑软件并说明测试前的软件。
        .安全保密，说明在安全保密方面的全部要求。
        .其他要求。
        （4）设计考虑。
        .逻辑结构设计，简要说明本系统（或子系统）内所使用的数据结构中，有关数据项、记录、文件的标识定义、长度及它们之间的相互关系。
        .物理结构设计，简要说明本系统内所使用的数据结构中有关数据库的存储要求、访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密处理。
        （5）评价。
        简要说明对时间、空间效率、维护代价和各种用户要求进行权衡所产生的方案性能情况。
        （6）验收。
 
       图形
               表示与存储
               图形是指能在人的视觉系统中产生视觉印象的客观对象，它包括人眼观察到的自然景物、拍摄到的图片、绘图工具得到的工程图、用数学方法描述的图像等。图形是客观对象的一种抽象表示，它带有形状和颜色信息。构成图形的要素有几何要素（刻画对象轮廓形状的点、线、面、体等）和非几何要素（刻画对象表面属性或材质的颜色、灰度等）。图形可用形状参数和属性参数表示，即参数表示法；也可用带有灰度或色彩的点阵图表示，简称像素图、图像（数字图像），即点阵表示法。
               图形是计算机图形学（Computer Graphics, CG）研究的对象。ISO给计算机图形学的定义为：研究用计算机进行数据和图形之间相互转换的方法和技术。还有定义为：计算机图形学是运用计算机描述、输入、表示、存储、处理（检索／变换／图形运算）、显示、输出图形的一门学科。计算机图形技术主要研究如何在计算机中表示图形，以及利用计算机进行图形的计算、处理和显示的相关原理和算法，其核心是将客观世界对象以图形的形式在计算机内表示出来，主要包括模型生成和图形显示，如下图所示。模型生成是获取、存储和管理客观世界物体的计算机模型，以在计算机上建立客观世界的模拟环境。图形显示是生成、处理和操纵客观世界物体模型的可视化结果，以在输出设备上呈现客观世界物体的图像。
               
               计算机图形生成模型
               计算机图形技术所涉及的研究内容非常广泛，如图形硬件、图形标准、图形交互技术、光栅图形生成算法、曲线曲面造型、实体造型、真实感图形计算与显示算法、风格化绘制、科学计算可视化、计算机动画、自然景物仿真、虚拟现实等。
               图形的文件格式
               ① TIF。
               TIF格式是平面设计中最常用的一种图形格式，因为其属于跨平台的格式，而且支持CMYK色，所以经常被用于印刷输出的场合。此外还有一个特色就是其支持LZW压缩，即不失真压缩，也就是说不管如何压缩，图档的品质都还能保持原来的水准。
               ②TGA。
               TGA图形格式的最大特点就是可以制作出不规则形状的图档，一般图档都为四方形，若需要圆形、菱形甚至镂空的图档时，TGA格式可能就会派上用场了。TGA格式同样支持压缩，也属于不失真压缩。
               ③ PSD。
               PSD格式是Photoshop专用的图形文件格式，该格式包含图形中的色层、遮罩、色频、选取区等Photoshop可以处理的属性，这样全方位的存储如果运用得当，几乎可以将创作的过程完整地记录，以便日后的修改。
               ④UFO。
               UFO格式是另一个著名制图软件Ulead Photoimapct的专用图形格式，其是致力于追赶Adobe的有力科技，同样也发展出了与PSD格式类似的图档格式，能够完整记录所有处理过的属性，不过在记录原理上却有些不同，UFO以物件代替图层，这一点并无大碍，因为Photoimapct与Photoshop本身就有很多的不同之处。
               ⑤RIF。
               RIF是著名制图软件Painter的专用图形格式，处理方式和前面两种大同小异，都可以存储相当多的属性资料。另外，Painter可以打开PSD文件，而且经过Painter处理的PSD文件可以在Photoshop中通用，这样就可以使同一文件在Photoshop和Painter中交换使用了。
               ⑥ CDR。
               CDR是著名制图软件CorelDRAW的专用图形格式，由于CorelDRAW是向量软件，所以CDR可以记录的资料可以说是千奇百怪，各物件的属性、位置、分页通通可以存储，以便日后修改。在兼容度上，目前基本没有其他软件可以打开CDR文件，这是向量软件的通病。
               ⑦EPS。
               EPS是印刷时经常用到的格式，向量图可以转换成EPS格式，点阵图也可以转成EPS格式。EPS文件可以同时存储点阵以及向量，故专门用于印前操作，如排版等，所以一般在印刷时都使用EPS文件。
               图形处理技术
               图形处理技术的范围很广，这里以真实感图形绘制和非真实感图形绘制为例简单介绍图形处理技术。
               真实感图形绘制是指借助数学、物理、计算机等学科知识使用计算机生成三维场景中真实逼真的图形、图像的过程。真实感图像绘制主要包括两个方面：表面特性的精确表示和场景中光照效果的物理描述。真实感图形绘制的应用非常广泛，例如计算机动画制作、影视特效仿真、计算机游戏、多媒体教育和虚拟现实等。真实感图形绘制所涉及的技术主要有消隐技术、表面细节绘制技术、纹理贴图技术、高级光照与着色技术等。
               非真实感图形绘制是指利用计算机生成不具有照片般真实感而具有手绘风格的图形的技术，其目标不在于表现图形的真实性，而是在于表现图形的艺术特质、模拟艺术作品（甚至包括作品中的缺陷）或作为真实感图形的有效补充。非真实感图形绘制的应用领域也非常广泛，其中一个重要的应用领域就是对绘画进行模拟，主要模拟的画种有油画、水彩画、钢笔画、铅笔画、水墨画和卡通动画。非真实感图形绘制所涉及的技术主要有基于像素的绘制，基于线条、曲线和笔画的绘制，模拟绘画绘制等。
               如下图所示，树和天空是采用真实感图形绘制技术绘制出来的，国画是采用非真实感图形绘制技术绘制出来的。
               
               真实感图形绘制和非真实感图形绘制
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段，系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。
        系统测试由独立测试小组在测试组长的监督下进行，测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。
               负载测试
               负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
               负载测试的加载方式通常有如下几种。
               （1）一次性加载。一次性加载某个数量的用户，在预定的时间段内持续运行。例如，在早晨上班的时间访问网站或登录网站的时间非常集中，基本属于扁平负载模式。
               （2）递增加载。有规律地逐渐增加用户，每几秒增加一些新用户，交错上升。借助这种负载方式的测试，容易发现性能的拐点，即性能瓶颈。
               （3）高低突变加载。某个时间用户数量很大，突然降到很低，过一段时间，又突然加到很高，反复几次。借助这种负载方式的测试，容易发现资源释放和内存泄露等问题。
               （4）随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟系统长时间的运行过程的状态。
               压力测试
               压力测试又称为强度测试，是在强负载（加大数据量、大量并发用户等）下的测试，用于查看应用系统在峰值使用情况下的操作行为，目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
               微软测试实践经验表明，如果软件产品通过72小时压力测试，则在72小时后出现问题的可能性微乎其微。所以，72小时成为微软产品压力测试的时间标志。
               负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载，测试其变化，看最后在满足性能的情况下，系统最多能接受多大负载的测试。压力测试是在满足性能的情况下，能使系统处于失效的状态，通俗来说，就是发现在什么条件下，系统的性能会变得不可接受。
               压力测试的一般步骤如下：
               ①进行简单多任务测试。
               ②简单压力缺陷修正后，增加系统的压力直到系统崩溃。
               因此，负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
               可靠性测试
               软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
               可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。
               安全性测试
               安全性测试是测试系统在应付非授权的内部／外部访问、非法侵入或故意的损坏时的系统防护能力，检验系统有能力使可能存在的内／外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。
               安全性测试需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中，测试者扮演成试图攻击系统的角色，尝试获取系统密码，利用能够瓦解任何防守的客户软件攻击系统；或者把系统“制服”，使别人无法访问。
               安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。破坏系统保护机构的主要方法有以下几种：
               （1）正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。
               （2）以系统输入为突破口，利用输入的容错性进行正面攻击。
               （3）申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统。
               （4）故意使系统出错，利用系统恢复的过程，窃取用户口令及其他有用的信息。
               （5）通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令、安全码和译码关键字等信息。
               （6）浏览全局数据，期望从中找到进入系统的关键字。
               （7）浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。
               一般情况下，网络软件的安全评估包括以下情况；
               （1）检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。
               （2）会话跟踪是否足够。
               （3）是否正确使用了加密技术。
               （4）变量限制的设定。
               （5）在服务器端执行程序中的安全漏洞。
               （6）HTML源码中是否有敏感的信息或没有必须出现的信息。
               兼容性／配置测试
               兼容性／配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。
               可以从如下几个方面进行兼容性测试。
               （1）检查版本是否兼容。检查新版本操作习惯与老版本是否兼容，目的是使老版本的用户很快地适应新版本的变化。
               （2）检查数据格式是否兼容。数据格式有许多种形式，如文件格式、网络协议和共享数据等。例如，通信协议软件版本升级后，检查升级版本和老版本的通信协议是否一致等。
               （3）检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用，是否属于某个平台或版本独有，是否在不同平台上有差异。
               （4）检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例，检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。
               容错性测试
               容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。
               可用性测试
               可用性是指系统正常运行的能力和用户接受的程度，一般用如下公式表示。
               可用性=平均正常工作时间／（平均正常工作时间+平均修复时间）
               影响可用性的因素有如下几个：
               （1）不充分的测试。
               （2）更改管理问题。
               （3）缺少在线监视和分析。
               （4）操作错误。
               （5）弱编码。
               （6）与外部服务或应用程序的交互。
               （7）不同的操作条件（使用级别更改、峰值重载）。
               （8）异常事件（安全性失败、广播风暴）。
               （9）硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和CPU）。
               （10）环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。
               下面给出提高系统可用性的一些办法。
               （1）使用集群。集群是指将至少两个系统连接到一起，像一个系统那样工作。当某一系统出现失效时，集群提供即时故障转移服务。
               （2）使用网络负载平衡。当检测某服务器失败后，网络负载平衡自动将通信量重新分发给仍然运行的服务器。
               （3）使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。
               （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
   题号导航      2013年上半年 系统集成项目管理工程师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题