免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2014年上半年 系统集成项目管理工程师 下午试卷 案例
  第1题      
  知识点：   配置管理   配置管理系统   配置管理员   配置控制   配置控制委员会   配置库   评审   软件文档管理指南   项目生命周期   质量保证   GB/T16680-1996   测试计划   产品文档   概要设计   管理文档   基线   开发过程   开发文档   配置管理计划   权限机制   生命周期   数据设计   数据字典   文档管理

 
（25分）
阅读下列说明，回答问题1至问题4,将解答填入答题纸的对应栏内。
小张被任命为公司的文档与配置管理员，在了解了公司现有的文档及配置管理现状和问题之后 ，他做出如下工作计划：
（1）整理公司所有文档，并进行归类管理
小张在核理公司文档时，根据GB/T16680-1996《软件文档管理指南》，从项目生命周期角度将文档划分为开发文档，产品文档和管理文档，并对公司目前的文档进行了如下分类：
①开发文档：可行性研究报告、需求规格说明书、概要设计说明书、数据设计说明书、数据字典。
②管理文档：开发计划、配置管理计划、测试用例、测试计划、质量保证计划、开发进度报告，项目开发总结报告。
③产品文档：用户手册、操作手册。
（2）建立公司级配置管理系统，将配置库划分为开发库与受控库，并规定开发库用于存放正在开发过程中的阶段成果，受控库作为基线库存放评审后的正式成果。
（3）建立配置库权限机制，允许公司人员按照不同级别查看并管理公司文档，考虑到公司总经理权限最大、项目经理要查看并了解相关项目资料等额外因素，对受控库进行了下表的权限分配，（√表示允许，X表示不允许）：

进行了如上配置管理工作后，此时有一个项目A的项目经理告知小张，发现基线库中有一个重要的功能缺陷要修改,项目经理组织配置控制委员会进行了分析讨论后，同意修改，并指派了程序员小王进行修改，于是小张按照项目经理的要求在受控库中増加了小王的修改权，以便小王可以在受控库中直接修改该功能。
 
问题：1.1   （1）依据16680-1996《软件文档管理指南》，小张对公司项目文档的归类是否正确？
（2）从候选答案中选择8个正确选项（多选该题得0分），将选项编号填入答题纸纸对应栏内。
应归入“开发文档”类的文档有：
候选答案：
A.可行性研究报告
B.需求规格说明书
C.用户手册
D.数据字典
E.操作手册
F.开发计划
G.配置管理计划
H.测试用例
I.测试计划
J.质量保证计划
K.项目开发总结报告
 
问题：1.2   小张在建立配置管理系统时，不清楚如何组织配置库，请帮助小张组织配置库（至少写出两种配置库组织形式，并说明优缺点）。
 
问题：1.3   本案例中当发现基线库中有一个重要的功能缺点需要修改时，你认为小张的做法存在哪些问题，并说明正确的做法。
 
问题：1.4   结合案例.请指出小张在整个受控库的权限分配方面存在哪些问题。
 
 
 

   知识点讲解    
   · 配置管理    · 配置管理系统    · 配置管理员    · 配置控制    · 配置控制委员会    · 配置库    · 评审    · 软件文档管理指南    · 项目生命周期    · 质量保证    · GB/T16680-1996    · 测试计划    · 产品文档    · 概要设计    · 管理文档    · 基线    · 开发过程    · 开发文档    · 配置管理计划    · 权限机制    · 生命周期    · 数据设计    · 数据字典    · 文档管理
 
       配置管理
        配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
        GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
 
       配置管理系统
        配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。
 
       配置管理员
        配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：
        .编写配置管理计划。
        .建立和维护配置管理系统。
        .建立和维护配置库。
        .配置项识别。
        .建立和管理基线。
        .版本管理和配置控制。
        .配置状态报告。
        .配置审计。
        .发布管理和交付。
        .对项目成员进行配置管理培训。
 
       配置控制
        配置控制即配置项和基线的变更控制，配置控制包括如下活动：
        .变更申请：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。
        .变更评估：CCB对变更申请进行评估并确定变更对项目的影响、变更的内容是否必要、变更的范围是否考虑周全、变更的实施方案是否可行、变更工作量估计是否合理。CCB对变更申请作出决定。
        .通告评估结果：CCB把关于变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
        .变更实施：项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。
        .变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
        .变更的发布：配置管理员将变更后的配置项纳入基线并将变更内容和结果通知相关人员，并做好记录。
        为了解决一个文档的变更引起多个相关文档的变更时文档修改不全面，以及多个开发人员对同一部件进行修改引起版本混乱等问题，可以基于配置库进行变更控制。
        基于配置库的变更控制过程如下图所示。
        
        基于配置库的变更控制
        下面以某软件产品的升级为例，说明基于配置库变更的流程：
        （1）将待升级的基线（假设版本号为V1.0）从产品库中复制到受控库。
        （2）程序员甲将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”，其他程序员无法检出，以保证同一段代码只能同时被一个程序员修改。
        （3）程序员甲将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以检出该段代码了。
        （4）软件产品的升级修改工作全部完成后，将受控库中的新基线更新到产品库中（软件产品的版本号更新为V1.1，旧的V1.0版并不删除，继续在产品库中保存）。
 
       配置控制委员会
        配置控制委员会（Configuration Control Board, CCB）负责对配置变更做出评估、审批以及监督已批准变更的实施。
        CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员和配置管理员等。CCB不必是常设机构，可以根据工作需要组建。小的项目CCB可以只有一个人，甚至只是兼职人员。通常，CCB不只控制配置变更，还负有更多的配置管理任务，如配置管理计划审批、基线设立审批和产品发布审批等。
 
       配置库
        配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
        .哪些客户已提取了某个特定的系统版本。
        .运行一个给定的系统版本需要什么硬件和系统软件。
        .一个系统到目前已生成了多少个版本，何时生成的。
        .某一特定的构件变更，会影响系统的哪些版本。
        .一个特定的版本曾提出过哪几个变更请求。
        .一个特定的版本有多少已报告的错误。
        使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
        配置库一般可以分为如下三种类型：
        .开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
        .受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
        .产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
        配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
        
        配置库的建库模式
 
       评审
        在软件开发各个阶段都要进行评审。
 
       软件文档管理指南
        该标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。下面以列表形式说明软件文档管理的重点内容、软件文档种类以及软件文档的四个级别。
        软件文档可区分为开发文档、产品文档和管理文档三类文档，下表描述了三类文档的定义、作用以及种类。
        
        文档种类比较表
        根据软件文档质量要求，可以将软件文档的重要性划分为四个等级，参见下表。
        
        文档的四个级别
 
       项目生命周期
               项目生命周期的定义
               项目生命周期指项目从启动到收尾所经历的一系列阶段。
               项目生命周期通常规定：
               .每个阶段应完成哪些技术工作？
               .每个阶段的交付物应何时产生？对每个交付物如何进行评审、验证和确认？
               .每个阶段都有哪些人员参与？
               .如何控制和批准每个阶段？
               项目阶段的特征：
               .每个项目阶段都以一个或多个可交付成果的完成为标志。
               .项目阶段的结束通常以对完成工作与可交付成果的审查为标志。
               .在未决定是否启动任何其他阶段时，也可以结束一个阶段。
               .阶段的正式完成不包括核准随后的阶段。阶段末审查往往称为阶段放行口、阶段关卡或验收站。
               项目生命周期的特征
               大多数项目生命周期都具有如下特征：
               .在初始阶段，费用和人员水平较低，在中间阶段达到最高，当项目接近结束时则快速下降。
               .项目初始阶段不确定性水平高，因此不能达成项目目标的风险也高，后续阶段完成项目的确定性逐渐变好。
               .随着项目阶段的深入，变更和缺陷修改的费用通常会增加。
               .项目初始阶段，项目干系人影响项目的最终产品特征的能力最高，随着项目的继续逐渐变低。
               项目生命周期与产品生命周期的关系
               产品生命周期开始于经营计划，经过构思，到产品，到日常经营和产品退出市场。
               在某些应用领域，项目生命周期可以视为产品生命周期的一部分。
               典型信息系统项目生命周期模型
                      瀑布模型
                      经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在项目开始时就对产品和可交付成果进行定义，对任何范围变化都要进行仔细管理。
                      瀑布模型一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段，通过顺序执行各个阶段的活动来完成项目。瀑布模型适用于需求明确或很少变更的项目，适用于充分了解拟交付的产品，有厚实的行业实践基础，或者整批一次性交付产品有利于干系人的项目。
                      迭代和增量模型
                      迭代方法是通过一系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。一次迭代中，将执行所有项目管理过程组中的活动。每次迭代结束时，将完成一个或一组可交付成果。后续迭代可能对这些可交付成果进行改进，也可能创造新的可交付成果。
                      RUP是迭代模型的一种，可分四个阶段：初始、细化、构造、移交，这四个阶段的顺序执行就形成了一个周期。各阶段的主要任务有：
                      .初始阶段：系统地阐述项目的范围，选择可行的系统构架，计划和准备业务案例。
                      .细化阶段：细化构想，细化过程和基础设施，细化构架并选择构件。
                      .构造阶段：资源管理、控制和过程最优化，完成构件的开发并依据评价标准进行测试，依据验收标准评估产品的发布。
                      .移交阶段：同步并使开发的构造增量集成到一致的实施基线中，根据完整的构想和需求集的验收标准评估与实施有关的工程活动的实施基线。
                      迭代和增量模型适用于组织需要管理不断变化的目标和范围，组织需要降低项目的复杂性，或者，产品的部分交付有利于一个或多个干系人，且不会影响最终或整批可交付成果的交付。大型复杂项目通常采用迭代方式来实施，这使项目团队可以在迭代过程中综合考虑反馈意见和经验教训，从而降低项目风险。
                      敏捷方法
                      敏捷方法也被称为适应型生命周期或变更驱动方法，是为了应对大量变更，获取干系人的持续参与而采用的方法。适应型生命周期也包含迭代和增量的概念，但和迭代增量模型不同之处在于，迭代很快（通常2～4周迭代1次），而且所需时间和资源是固定的。
                      敏捷方法是一种应对快速变化的需求的软件开发方法，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队，也更注重软件开发中人的作用。
                      敏捷方法适用于需要应对快速变化的环境，需求和范围难以事先确定的情况，或者能够以有利于干系人的方式定义较小的增量改进的情况。
                      V模型
                      V模型如下图所示，左边开发过程的各开发阶段和右边测试过程的各测试阶段相互对应，形成了字母“V”的形状。
                      
                      V模型示意图
                      V模型的价值在于它非常明确地标明了测试过程中存在的不同阶段，并且清楚地描述了这些测试阶段和各开发阶段的对应关系。
                      原型化模型
                      原型化模型是为弥补瀑布模型的不足而产生的。
                      原型化模型首先要构造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。在实际中，原型化经常在需求分析定义的过程中进行。原型化模型减少了瀑布模型因为软件需求不明确而给开发工作带来的风险，因为在原型基础上的沟通更为直观，也为需求分析和定义提供了新的方法。
                      一般有两种原型，即抛弃型原型和进化型原型：
                      .抛弃型原型：此类原型在系统真正实现以后就抛弃不用了。
                      .进化型原型：此类原型的构造从目标系统的一个或多个基本需求出发，通过修改和追加的过程逐渐丰富，演化成为最终的系统。
                      对于复杂的大型软件，开发一个原型往往达不到要求，为减少开发风险，在瀑布模型和原型化模型的基础上演进，出现了螺旋模型以及大量使用的RUP。
                      螺旋模型
                      螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来，使得软件的增量版本的快速开发成为可能。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
 
       质量保证
        质量保证是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程，其主要作用为促进质量过程改进。
               输入
                      质量管理计划
                      质量管理计划描述了项目质量保证和持续过程改进的方法。
                      过程改进计划
                      项目的质量保证活动应该支持并符合执行组织的过程改进计划。
                      质量测量指标
                      质量测量指标提供了应该被测量的属性和允许的偏差。
                      质量控制测量结果
                      质量控制测量结果是质量控制活动的结果，用于分析和评估项目过程的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
                      项目文件
                      项目文件可能影响质量保证工作，应该放在配置管理系统内监控。
               工具与技术
                      质量管理与控制工具
                      质量保证过程使用制订质量管理计划和质量控制过程的工具和技术。除此之外，其他可用的工具包括：
                      .亲和图：与心智图相似，针对某个问题，产生出可联成有组织的想法模式的各种创意。在项目管理中，使用亲和图确定范围分解的结构，有助于WBS的创建。
                      .过程决策程序图（PDPC）：用于理解一个目标与达成此目标的步骤之间的关系。PDPC有助于制订应急计划，因为它能帮助团队预测那些可能破坏目标实现的中间环节。
                      .关联图：关系图的变种，有助于在包含相互交叉逻辑关系（可有多达50个相关项）的中等复杂情形中创新性地解决问题。可以使用其他工具（如亲和图、树形图或鱼骨图）产生的数据来绘制关联图。
                      .树形图：也称系统图，可用于表现WBS、RBS（风险分解结构）和OBS（组织分解结构）的层次分解结构。在项目管理中，树形图依据定义嵌套关系的一套系统规则，用层次分解形式直观地展示父子关系。
                      .优先矩阵：用来识别关键事项和合适的备选方案，并通过一系列决策，排列出备选方案的优先顺序。先对标准排序和加权，再应用于所有备选方案，计算出数学得分，对备选方案排序。
                      .活动网络图：过去称为箭头图，包括AOA（活动箭线图）和最常用的AON（活动节点图）两种格式的网络图。活动网络图连同项目进度计划编制方法一起使用，如计划评审技术（PERT）、关键路径法（CPM）和紧前关系绘图法（PDM）。
                      .矩阵图：使用矩阵结构对数据进行分析。在行列交叉的位置展示因素、原因和目标之间的关系强弱。
                      以上七种质量管理和控制工具如下图所示。
                      质量审计
                      质量审计是用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化的、独立的过程。质量审计的目标是：
                      .识别全部正在实施的良好及最佳实践。
                      .识别全部违规做法、差距及不足。
                      .分享所在组织或行业中类似项目的良好实践。
                      .积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率。
                      .强调每次审计都应对组织经验教训的积累做出贡献。
                      质量审计还可确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预防措施）的实施情况。
                      过程分析
                      过程分析是指按照过程改进计划中概括的步骤来识别所需的改进。它也要检查在过程运行期间遇到的问题、制约因素，以及发现的非增值活动。过程分析包括根本原因分析（用于识别问题、探究根本原因，并制订预防措施的一种具体技术）。
                      
                      七种质量管理和控制工具示意图
               输出
                      变更请求
                      可以提出变更请求，并提交给实施整体变更控制过程，以全面考虑改进建议。可以为采取纠正措施、预防措施或缺陷补救而提出变更请求。
                      项目管理计划更新
                      项目管理计划中可能需要更新的内容包括质量管理计划、范围管理计划、进度管理计划和成本管理计划。
                      项目文件更新
                      可能需要更新的项目文件包括质量审计报告、培训计划和过程文档。
                      组织过程资产更新
                      可能需要更新的组织过程资产包括组织的质量标准和质量管理系统。
 
       GB/T16680-1996
        GB/T 16680—1996《软件文档管理指南》（NEQ ISO/IEC TR 9294-1990）标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。GB/T 16680—1996的目的在于协助管理者在他们的机构中产生有效的文档。GB/T 16680—1996涉及策略、标准、规程、资源和计划，管理者必须关注这些内容，以便有效地管理软件文档。
        根据GB/T 16680—1996，文档是指一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如，技术文件、设计文件、版本说明文件。软件文档的作用是管理依据、任务之间联系的凭证、质量保证、培训与参考；软件维护支持、历史档案。
        软件文档可归入3种类别：开发文档（描述开发过程本身）、产品文档（描述开发过程的产物）、管理文档（记录项目管理的信息）。
               文档计划
               文档计划是指一个描述文档编制工作方法的管理用文档。该计划主要描述要编制什么类型的文档，这些文档的内容是什么，何时编写，由谁编写，如何编写以及什么是影响期望结果的可用资源和外界因素。
               文档计划一般包括以下几方面的内容：
               （1）列出应编制文档的目录。
               （2）提示编制文档应参考的标准。
               （3）指定文档管理员。
               （4）提供编制文档所需要的条件，落实文档编写人员、所需经费以及编制工具等。
               （5）明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等等。
               （6）绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。
               此外，文档计划规定每个文档要达到的质量等级，以及为达到期望结果必须考虑哪些外部因素。文档计划还确定该计划和文档的分发，并且明确叙述参与文档工作的所有人员的职责。
               开发文档
               开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下5种作用：
               （1）它们是软件开发过程中包含的所有阶段之间的通信工具，它们记录生成软件需求、设计、编码和测试的详细规定和说明。
               （2）它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做。
               （3）它们用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时，管理者将失去跟踪和控制软件项目的一个重要工具。
               （4）它们形成了维护人员所要求的基本软件文档。而这些支持文档可作为产品文档的一部分。
               （5）它们记录软件开发的历史。
               基本的开发文档有可行性研究和项目任务书；需求规格说明；功能规格说明；设计规格说明，包括程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划、标准、进度；安全和测试信息。
               产品文档
               产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品文档起到如下3种作用：
               （1）为使用和运行软件产品的任何人规定培训和参考信息。
               （2）使得那些未参加本软件开发的程序员维护它。
               （3）促进软件产品的市场流通或提高可接受性。
               产品文档用于下列类型的读者：
               （1）用户。他们利用软件输入数据、检索信息和解决问题。
               （2）运行者。他们在计算机系统上运行软件。
               （3）维护人员。他们维护、增强或变更软件。
               产品文档包括如下内容：
               （1）用于管理者的指南和资料，他们监督软件的使用。
               （2）宣传资料。通告软件产品的可用性并详细说明它的功能、运行环境等。
               （3）一般信息。对任何有兴趣的人描述软件产品。
               基本的产品文档有培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
               管理文档
               管理文档建立在项目信息的基础上，例如：
               （1）开发过程的每个阶段的进度和进度变更的记录。
               （2）软件变更情况的记录。
               （3）相对于开发的判定记录。
               （4）职责定义。
               这种文档从管理的角度规定涉及软件生存的信息。相关文档的详细规定和编写格式见GB8567。
               文档等级
               文档等级是指所所需文档的一个说明，它指出文档的范围、内容、格式及质量，可以根据项目、费用、预期用途、作用范围或其他因素选择文档等级。每个文档的质量必须在文档计划期间就有明确的规定，文档的质量可以按文档的形式和列出的要求划分为四级。
               （1）最底限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
               （2）内部文档（2级文档）：可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
               （3）工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
               （4）正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档应遵守GB8567的有关规定。
 
       测试计划
        制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：
        ①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。
        ②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。
        ③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。
        下面详细论述负载压力测试计划过程的4个步骤。
               分析应用程序
               负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
                      确定系统组件
                      绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。
                      如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。
                      
                      联机银行系统应用布署
                      描述系统配置
                      增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：
                      . 连接到系统的用户数；
                      . 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；
                      . 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；
                      . 服务器与应用程序客户端之间的通信方式；
                      . 前端客户端与后端服务器之间的中间件配置和应用程序服务器；
                      . 可能影响响应时间的其他网络组件（调制解调器等）；
                      . 通信设备的吞吐量以及每个设备可以处理的并发用户数。
                      例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。
                      
                      客户端配置内容
                      分析使用模型
                      定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。
                      例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
                      任务分布
                      除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。
               定义测试目标
               开始测试之前，应精确地定义想要实现的目标。
                      以可度量的指标制定目标
                      确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。
                      例如：
                      . 一般性目标产品评估：选择Web服务器的硬件。
                      . 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。
                      . 测试目标
                      ①度量最终用户的响应时间，完成一个业务流程需要多长时间；
                      ②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；
                      ③检查可靠性，系统无错误或无故障运行的时间长度或难度；
                      ④查看硬件或软件升级对性能或可靠性有何影响；
                      ⑤评估新产品，应选择哪些服务器硬件或软件；
                      ⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；
                      ⑦确定瓶颈，哪些因素会延长响应时间。
                      确定测试的时间
                      负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。
                      
                      产品生命周期与测试类型
               计划方案实施
               下一步是确定如何实现测试目标。
                      定义性能度量的范围
                      可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。
                      . 度量端到端的响应时间。
                      可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。
                      可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。
                      
                      端到端的响应时间
                      . 度量网络和服务器响应时间。
                      可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。
                      
                      网络和服务器的响应时间
                      . 度量GUI响应时间。
                      可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。
                      
                      GUI响应时间
                      . 度量服务器响应时间。
                      可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。
                      
                      服务器响应时间
                      . 度量中间件到服务器的响应时间。
                      如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。
                      定义Vuser活动
                      根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。
                      
                      中间件到服务器响应时间
                      根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。
                      此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。
                      选择Vuser
                      确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：
                      . 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；
                      . 使用RTE Vuser来模拟终端用户；
                      . 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。
                      例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。
                      
                      Vuser的数量和类型
                      选择测试硬件和软件
                      硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。
                      在确定计算机的数量和正确的配置时，请考虑以下事项。
                      . 建议在一台单独的计算机上运行测试工具主控台。
                      . 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。
                      . GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
                      关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。
                      
                      测试机硬件与软件要求（Windows配置要求）
                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
                      有关最新的安装要求，请访问
                      http://www.mercuryinteractive.com/products/loadrunner/technical/
                      
                      测试机硬件与软件要求（UNIX配置要求）
                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
               检查测试目标
               测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。
               ①度量最终用户响应时间。
               ②定义最优的硬件配置。
               ③检查可靠性。
               ④查看硬件或软件升级。
               ⑤评估新产品。
               ⑥确定瓶颈。
               ⑦度量系统容量。
                      度量最终用户响应时间
                      查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。
                      
                      负载和响应时间度量关系
                      定义最优的硬件配置
                      检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。
                      例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。
                      . 配置1：200MHz、64MB RAM。
                      . 配置2：200MHz、128MB RAM。
                      . 配置3：266MHz、128MB RAM。
                      检查可靠性
                      确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。
                      查看硬件或软件升级
                      执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
                      评估新产品
                      可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。
                      确定瓶颈
                      可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。
                      
                      系统不同点的性能
                      度量系统容量
                      度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
                      
                      响应时间与负载关系
 
       产品文档
        产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品文档起到如下三种作用：
        （1）为使用和运行软件产品的任何人规定培训和参考信息。
        （2）使得那些未参加本软件开发的程序员维护它。
        （3）促进软件产品的市场流通或提高可接受性。
        产品文档用于下列类型的读者：
        （1）用户。他们利用软件输入数据、检索信息和解决问题。
        （2）运行者。他们在计算机系统上运行软件。
        （3）维护人员。他们维护、增强或变更软件。
        产品文档包括如下内容：
        （1）用于管理者的指南和资料，他们监督软件的使用。
        （2）宣传资料。通告软件产品的可用性，并详细说明它的功能、运行环境等。
        （3）一般信息。对任何有兴趣的人描述软件产品。
        基本的产品文档有培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告。
 
       概要设计
        1）设计软件系统总体结构
        设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
        2）数据结构及数据库设计
        （1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
        （2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。
        ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。
        ②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。
        ③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
        3）编写概要设计文档
        文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
        4）评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。
 
       管理文档
        管理文档建立在项目信息的基础上，诸如：
        （1）开发过程的每个阶段的进度和进度变更的记录；
        （2）软件变更情况的记录；
        （3）相对于开发的判定记录；
        （4）职责定义。
        这种文档从管理的角度规定涉及软件生存的信息。相关文档的详细规定和编写格式见GB8567。
 
       基线
        基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
        如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
        （1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        （2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        （3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        ：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       开发文档
        开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下五种作用：
        （1）它们是软件开发过程中包含的所有阶段之间的通信工具，它们记录生成软件需求、设计、编码和测试的详细规定和说明。
        （2）它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做。
        （3）它们用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时，管理者将失去跟踪和控制软件项目的一个重要工具。
        （4）它们形成了维护人员所要求的基本软件文档。而这些支持文档可作为产品文档的一部分。
        （5）它们记录软件开发的历史。
        基本的开发文档有可行性研究和项目任务书；需求规格说明；功能规格说明；设计规格说明，包括程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划、标准、进度；安全和测试信息。
 
       配置管理计划
        主要内容
        配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
        主要步骤
        制订配置管理计划的主要步骤如下：
        （1）建立并维护配置管理的组织方针。
        （2）确定配置管理所需要的资源。
        （3）分配责任。
        （4）培训计划。
        （5）确定和配置管理有关的项目干系人并确定其介入时机。
        （6）制订识别配置项的准则。
        （7）制订配置项管理表。
        （8）制订基线计划。
        （9）制订配置库备份计划。
        （10）制订变更控制流程。
        （11）制订审批计划。
 
       权限机制
        权限机制的基本思想是：给用户授予不同类型的权限，在必要时，可以收回授权。使用户能够进行的数据库操作及所操作的数据限定在指定的范围内，禁止用户超越权限对数据库进行非法的操作，从而保证数据库的安全性。在SQL Server中，权限可分为系统权限和对象权限。
 
       生命周期
        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服务供方的服务过程、交付结果实施监督和绩效评估。
 
       数据设计
        一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
        
        测试数据表
        测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。
        以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括以下内容。
        场景6——账户不存在/账户类型有误：未找到账户或账户不可用；
        场景6——账户不存在/账户类型有误：禁止从该账户中提款；
        场景7——账户余额不足：请求的金额超出账面金额。
        在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
        ①无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）；
        ②无法读卡（读卡机堵塞、脱机或出现故障）；
        ③账户已消户、冻结或由于其他方面原因而无法使用；
        ④ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币值都不足）；
        ⑤无法联系银行系统以获得认可；
        ⑥银行网络离线或交易过程中断电。
        结论：所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，它能极大地提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验，这是测试人员最宝贵的财富。
 
       数据字典
        数据流图描述了系统的分解，即描述了系统由哪几部分组成，各部分之间的联系等，但没有说明系统中各成分的含义。只有当数据流图中出现的每一成分都给出定义之后，也就是使数据流图上的数据流名字、处理逻辑名字等都具有确切地解释之后，才能真正完整、准确地描述一个系统。为此，还需要其他工具对数据流图加以补充说明。
        数据字典就是这样的工具。数据字典最初用于数据库管理系统。它为数据库用户、数据库管理员、系统分析员和程序员提供某些数据项的综合信息。这种思想启发了信息系统的开发人员，使他们想到将数据字典引入系统分析。
        数据字典是以特定格式记录下来的、对系统的数据流图中各个基本要素（数据流、处理逻辑、数据存储和外部实体）的内容和特征所做的完整的定义和说明。它是结构化系统分析的重要工具之一，是对数据流图的重要补充和说明。
        建立数据字典的工作量很大，而且相当繁琐。但这是一项必不可少的工作。数据字典在信息系统开发中具有十分重要的意义，不仅在系统分析阶段，而且在整个开发过程中以及今后的系统运行中都要使用它。
        数据字典可以用人工方式建立。事先印好表格，填好后按一定顺序排列，就是一本字典。也可以建立在计算机内，数据字典实际上是关于数据的数据库，这样使用、维护都比较方便。编写数据字典是系统开发的一项重要的基础工作。一旦建立，并按编号排序之后，就是一本可供查阅的关于数据的字典，从系统分析一直到系统设计和实施都要使用它。在数据字典的建立、修正和补充过程中，始终要注意保证数据的一致性和完整性。
        （1）数据字典的条目。
        数据字典中有6类条目：数据项、数据结构、数据流、数据存储、处理过程和外部实体。不同类型的条目有不同的属性，现分别说明如下：
        ①数据项又被称为数据元素，是系统中最基本的数据组成单位，也就是不可再分的数据单位，如学号、姓名、成绩等。一般分析数据特性应从静态和动态两个方面去进行。但在数据字典中，仅定义数据的静态特性，具体包括：
        .数据项的名称。名称要尽量反映该元素的含义，便于理解和记忆。
        .编号。一般由字母和数字组成。
        .别名。一个数据元素，可能其名称不止一个；若有多个名称，则须加以说明。
        .简述。有时候名称仍然不能很确切地反映元素的含义，则可以给该数据项加一些描述信息。
        .数据项的取值范围和取值的含义。指数据元素可能取什么值或每一个值代表的意思。
        数据项的取值可分为离散型和连续型两类。如人的年龄是连续型的，取值范围可定义为0～150岁。而“婚姻状况”取值范围是“未婚、已婚、离异、丧偶”，是离散型的。
        一个数据项是离散的，还是连续的，视具体需要而定。例如在一般情况下，我们用岁数表示一个人的年龄，是连续的。但有时，我们只要用“幼年、少年、青年、壮年、老年”表示，或者区分为成年、未成年即可，这时年龄便是离散型的。
        .数据项的长度。指出该数据项由几个数字或字母组成。如学号，按某校的编法由7个数字组成，其长度就是7个字节。
        .数据类型。说明取值是字符型还是数字型等。
        下表就是数据项条目的一个例子。数据字典中对“职工姓名”数据项的描述。
        
        一个数据项的例子
        ②数据结构数据结构描述某些数据项之间的关系。一个数据结构可以由若干个数据项组成；也可以由若干个数据结构组成，还可以由若干个数据项和数据结构组成。在数据字典中对其定义包括：名称；编号；简述；数据结构的组成。例如下表所示订货单就是由三个数据结构组成的数据结构，表中用DS表示数据结构，用I表示数据项。
        
        一个的数据结构的例子
        如果是一个简单的数据结构，只要列出它所包含的数据项。如果是一个嵌套的数据结构（即数据结构中包含数据结构），则需列出它所包含的数据结构的名称，因为这些被包含的数据结构在数据字典的其他部分已有定义，见下表。
        
        用户订货单的数据结构
        ③数据流数据流由一个或一组固定的数据项组成。定义数据流时，不仅要说明数据流的名称、组成等，还应指明它的来源、去向和数据流量等。在数据字典中数据流的属性包括：
        .名称。名称含义应尽量便于理解和记忆。
        .编号。一般由字母和数字组成。
        .简述。对该数据流的补充说明。
        .数据流的来源。数据流可以来自某个外部实体、数据存储或某个处理。
        .数据流的去向。某些数据流的去处可能不止一个，若有多个去处，则都需要进行说明。
        .数据流的组成。指数据流所包含的数据结构。一个数据流可包含一个或多个数据结构。若只含一个数据结构，应注意名称的统一，以免产生二义性。
        .数据流的流通量。指单位时间（每日，每小时等）里的数据传输次数。可以估计平均数或最高、最低流量各是多少。
        .高峰期流通量。
        下表是一个数据流的例子。
        
        一个数据流的例子
        ④处理逻辑的定义处理逻辑的定义仅对数据流程图中最底层的处理逻辑加以说明。在数据字典中对其定义包括：处理逻辑名称；编号；简述；输入；处理过程；输出；处理频率，如下表所示。
        
        一个处理逻辑的例子
        ⑤数据存储数据存储在数据字典中只描述数据的逻辑存储结构，而不涉及它的物理组织。在数据字典中对其定义包括：数据存储的编号；名称；简述；组成；关键字；相关的处理。下表给出了一个数据存储定义的例子。
        
        一个数据存储定义的例子
        ⑥外部实体定义外部实体是数据的来源和去向。因此，在数据字典中关于外部实体的条目，主要说明外部实体产生的数据流和传给该外部实体的数据流，以及该外部实体的数量。外部实体的数量对于估计系统的业务量有参考作用，尤其是关系密切的主要外部实体。在数据字典中对外部实体的定义包括：外部实体编号；外部实体名称；简述；输入的数据流；输出的数据流。下表给出了一个外部实体定义的例子。
        
        一个外部实体定义的例子
        （2）数据字典的作用。
        数据字典实际上是“关于系统数据的数据库”。在整个系统开发过程以及系统运行后的维护阶段，数据字典都是必不可少的工具。数据字典是所有人员工作的依据、统一的标准。它可以确保数据在系统中的完整性和一致性。具体地讲，数据字典有以下作用：
        ①按各种要求列表。可以根据数据字典，把所有数据元素、数据结构、数据流、数据存储、处理逻辑、外部实体，按一定的顺序全部列出，保证系统设计时不会遗漏。
        如果系统分析员要对某个数据存储的结构进行深入分析，需要了解有关的细节，了解数据结构的组成乃至每个数据元素的属性，数据字典也可提供相应的内容。
        ②相互参照，便于系统修改。根据初步的数据流图，建立相应的数据字典。在系统分析过程中，常会发现原来的数据流图及各种数据定义中有错误或遗漏，需要修改或补充。有了数据字典，这种修改就变得容易多了。
        例如，在某个库存管理系统中，“商品库存”这个数据存储的结构是：商品编号、商品名、规格、当前库存量。一般来讲，考虑能否满足用户订货，这些数据项就够了。但如果要求库存数量不能少于“安全库存量”，则这些数据项是不够的。这时，在这个结构中就要增加“安全库存量”这个数据项。以前，只要“顾客订货量小于或等于当前库存量”，就认为可以满足用户订货；现在则只有“顾客订货量小于或等于当前库存量且当前库存量大于或等于安全库存量”时才能满足顾客订货。有了数据字典，这个修改就容易了。因为在该数据存储的条目中，记录了有关的数据流，由此可以找到因数据存储的改动而可能影响到的处理逻辑，不至于遗漏而造成不一致。
        ③由描述内容检索名称。对于一个稍微复杂的系统，数据字典的量是相当大的，有时候系统分析员可能没有把握断定某个数据项在数据字典中是否已经定义，或者记不清楚其确切名字，这时可以通过内容查找其名称，就像根据书的内容查询图书的名字一样。
        ④一致性检验和完整性检验。根据各类条目的规定格式，可以检验一下一些问题。
        .是否存在没有指明来源或去向的数据流。
        .是否存在没有指明数据存储或所属数据流的数据元素。
        .处理逻辑与输入的数据元素是否匹配。
        .是否存在没有输入或输出的数据存储。
        （3）数据字典的编写与管理。
        数据字典的内容是随着数据流图自顶向下，逐层扩展而不断充实的。数据流图的修改与完善，将导致数据字典的修改，这样才能保证数据字典的一致性和完整性。数据字典的编写可以有两种方式：手工编写和计算机辅助编写。
        手工编写的主要工具是笔和卡片，当然可以辅以计算机文字处理手段。这时计算机只是作为手工书写工具来使用，没有处理数据字典的结构、内容和格式的功能。由于数据字典各条目的定义、说明和分解细化主要靠人的知识、经验和判断，手工编写具有较大的灵活性与适应性，也就是说，可以随着系统分析工作的深入和对用户信息需求的了解的细化而不断充实、修正数据字典的内容。但手工编写效率不高、编辑困难、容易出现疏漏与错误，对数据字典的检验、维护与查询、检索、统计、分析都不方便。
        计算机辅助编写数据字典时，计算机以输入的方式接受数据字典各类成分的定义和说明的原始数据，根据规范要求提供编辑、索引、完整性、一致性检查的功能。具有统计、报告、查询功能，可以定义在某些加工中使用、但数据流图上未注明的数据元素。这类计算机辅助工具称为计算机辅助系统工程（Computer-Aided Systems Engineering）工具，或称计算机辅助软件工程（Computer-Aided Software Engineering，CASE）工具。这些CASE工具提供DFD和DD的编制功能，具有图形处理、数据管理和文字编辑的能力，有的还能在系统设计与系统实施阶段提供辅助。
        对于计算机辅助编写数据字典来说，最重要的是建立便于输入、查询与维护的数据库，称之为数据字典库。因此，除了采用商品化的CASE工具软件辅助编写数据字典外，也可采用通用的开发工具和数据库管理系统来创建数据字典库及相应的编辑、查询与检验程序。
        但在开发初期，对于规模不太大的系统，手工编写更方便实惠。
        编写数据字典的基本要求是：
        .对数据流图上各种成分的定义必须明确、唯一、易于理解。命令、编号与数据流图一致，必要时可增加编码，以方便查询、检索、维护和统计报表。
        .符合一致性和完整性的要求，对数据流图上的成分定义与说明没有遗漏。
        .数据字典中无内容重复或内容相互矛盾的条目。
        .数据流图中同类成分的数据字典条目中，无同名异义或异名同义者。
        .格式规范、风格统一、文字精炼，数字与符号正确。
        数据字典的建立，对于系统分析人员、用户或是系统设计人员均有很大好处，他们可以从不同的角度分别从数据字典中得到有关的信息，便于认识整个系统并随时查询系统中的部分信息。随着系统开发工作的不断深入，数据字典所带来的效益也将越来越明显。
        为了保证数据的一致性，数据字典必须由专人（数据管理员）管理。其职责就是维护和管理数据字典，保证数据字典内容的完整一致。任何人（包括系统分析员、系统设计员、程序员）要修改数据字典的内容，都必须通过数据管理员。数据管理员要把数据字典的最新版本及时通知有关人员。
 
       文档管理
        信息系统软件运维文档是对运维服务参与各方主体从事信息系统软件运维实施及运维管理提供决策支持的一种载体。在信息系统软件运维过程中，能及时、准确、完善地掌握与运维有关的大量信息，处理和管理好各类运维策划、实施、检查和改进信息，是运维管理的重要工作内容。
        文档能提高软件运维过程的能见度，把用户反映的问题、用户提交的报告、用户增加的需求、对用户反映问题的维护反馈记录、运维过程中发生的事件以某种可阅读的形式记录在文档中，管理人员可把这些记载下来的材料作为检查软件运维进度和运维质量的依据，正确统计运维的工作量，实现对信息系统软件运维的工程管理，提高运维效率。文档作为运维人员一定阶段的工作成果和结束标志，记录运维过程中的有关信息，便于管理人员、运维人员、操作人员、用户之间的协作和交流，使信息系统软件运维更科学、更有成效。
        信息系统软件运维文档管理应注意如下方面。
        （1）文档管理制度化。形成一整套完善的文档管理制度，根据这一套制度来协调控制、评价信息系统软件运维中各类人员的工作。
        （2）文档标准化、规范化。在信息系统软件运维前要选择或制定文档标准，在统一的标准约束下来规范地建立各类文档。
        （3）落实文档管理人员。应设专人负责集中保管与信息系统软件运维相关的文档，他人可按一定的流程向文档管理员借阅文档。
        （4）保持文档的一致性。信息系统软件在运维过程中如果修改了原来的需求和设计，但是文档却没有进行同步修改，造成交付的文档与实际信息系统软件不一致，使用户在使用信息系统软件参考文档对软件进行维护时出现许多误解，这将严重影响系统的质量和维护的效率。所以，在信息系统软件运维过程中，如果修改部分涉及设计文档或用户手册的，一定要及时更改，这样才能达到事半功倍的效果。
        （5）维护文档的可追踪性。由于信息系统软件运维的动态性，软件的某种修改最终是否有效要经过一定的时间检验，所以运维文档也应与相应的信息系统软件一样要分版本进行管理，这样软件和文档就具有可追踪性，便于持续地运维与改进。
   题号导航      2014年上半年 系统集成项目管理工程师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题