免费智能真题库 > 历年试卷 > 系统分析师 > 2014年上半年 系统分析师 上午试卷 综合知识
  第28题      
  知识点:   配置标识   系统测试   测试阶段   系统测试阶段   系统分析阶段
  关键词:   测试阶段   分析阶段   系统测试   系统分析   测试        章/节:   项目管理知识       

 
(28)是系统分析阶段结束后得到的工作产品,(29)是系统测试阶段完成后的工作产品。
 
 
  A.  系统设计规格说明
 
  B.  系统方案建议书
 
  C.  程序规格说明
 
  D.  单元测试数据
 
 
 

 
  第29题    2014年上半年  
   65%
(28)是系统分析阶段结束后得到的工作产品,(29)是系统测试阶段完成后的工作产品。
  第32题    2015年上半年  
   51%
软件配置管理中,每一项配置变更都要在配置状态报告中进行详细的记录。配置状态报告的信息流如下图所示,图中①②③处分别是()..
  第21题    2011年上半年  
   57%
软件配置管理的活动主要有编制配置管理计划、配置标识、(21)、配置状态报告、配置评价、发行管理和交付。
   知识点讲解    
   · 配置标识    · 系统测试    · 测试阶段    · 系统测试阶段    · 系统分析阶段
 
       配置标识
        配置标识是配置管理的基础性工作,是配置管理的前提。配置标识是确定哪些内容应该进入配置管理形成配置项,并确定配置项如何命名,用哪些信息来描述该配置项。
               确定配置项
               信息系统项目中形成的技术性文档和管理性文档,除一些临时性的文档外一般都应该进行配置管理。一般来讲,判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用,这些文档往往在项目的进程中不断地修正和扩展,要保证每个使用者都使用同一版本的文档,就必须将这些文档纳入配置管理,成为受控的配置项。
               (1)识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码/模块、工具(如编辑器)、接口描述等。在软件工程方面,Roger S.Pressman认为至少以下所列的文档应该成为配置项:系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。
               (2)配置项命名。确定了配置项后,还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之,必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构,树状结构上节点之间存在着层次的继承关系。
               (3)配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关系,因此它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息(名字、描述、一组资源、实现)唯一地标识。配置项间的关系有整体和部分的关系及层次关系,也有关联关系。配置项间的关系可以用MIL语言(Module Interconnection Language)表示。MIL描述的是配置项间的相互依赖关系,可自动构造系统的任何版本。
               (4)识别配置项的步骤。识别配置项的主要步骤如下:
               .识别配置项。
               .为每个配置项指定唯一性的标识代号。
               .确定每个配置项的重要特征。配置项的特征主要包括作者、文档类型、代码文档的程序设计语言。
               .确定配置项进入配置管理的时间。
               .确定每个配置项的拥有者及责任。
               .填写配置管理表。
               .审批配置管理表。CCB审查配置管理表是否符合配置管理计划和项目计划文档的规定,审批配置管理表。
               基线
               基线(baseline)是项目生存期各开发阶段末尾的特定点,也称为里程碑(milestone),在这些特定点上,阶段工作已结束,并且已经形成了正式的阶段产品。
               建立基线的概念是为了把各开发阶段的工作划分得更加明确,使得本来连续开展的开发工作在这些点上被分割开,从而更加有利于检验和肯定阶段工作的成果,同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果,并且认为建立了里程碑,有些完成的阶段成果已被冻结。
               作为阶段工作的正式产品,基线应该是稳定的,如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿,就不能作为基线,不能被冻结。
               如果把软件看做是系统的一个组成部分,以下3种基线最受人们关注的:功能基线、分配基线、产品基线。
               (1)功能基线:指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
               (2)分配基线(指派基线):指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
               (3)产品基线:指在软件组装与系统测试阶段结束时,经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
               另外,交付给外部顾客的基线一般称为发行基线,内部使用的基线称为构造基线。交付(释放)是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。其中,是将系统集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。
               提出基线的概念本来是为了更好地实现变更控制,但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及到基线的很小部分。例如,假定某个大型软件中的一个模块修改了,如果将这一变更当做整个软件产品基线的变更,就很不方便。
               建立配置管理系统
               在配置管理中,要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下:
               (1)建立适用于多控制等级配置管理的管理机制。生存周期中不同时间所需的控制等级不同,不同的系统类型所需的控制等级不同,在满足专属性和安全性方面的不同的控制等级。
               (2)存储和检索配置项。
               (3)共享和转换配置项。
               (4)存储和复原配置项的归档版本。
               (5)存储、更新和检索配置管理记录。
               (6)创建配置管理报告。
               (7)保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。
               (8)权限分配。CMO的权限最高,一般项目成员可拥有添加、检入/检出、下载的权限,但是不能有删除的权限。
               创建基线或发行基线
               创建基线或发行基线的步骤如下:
               (1)获得CCB的授权。CMO根据项目进展情况或项目组的要求和基线计划规定,提出创建基线的书面请求,提请CCB授权。
               (2)创建构造基线或发行基线。
               (3)形成文件。
               (4)使基线可用。
 
       系统测试
        如果项目不只包含软件,还有硬件和网络等,则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列集成与确认测试。一般来说,系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常在系统分析阶段(需求分析阶段)完成。
 
       测试阶段
        . 可靠性测试(含于集成测试、系统测试);
        . 排错;
        . 可靠性建模;
        . 可靠性评价;
        . 调整可靠性活动计划;
        . 收集可靠性数据;
        . 明确后续阶段的可靠性活动的详细计划;
        . 编制可靠性文档。
 
       系统测试阶段
        UML模型可作为测试阶段的依据。系统的测试通常分为单元测试、集成测试、系统测试和验收测试几个不同级别。
        .单元测试是对几个类或一组类的测试,通常由程序员进行。
        .集成测试集成组件和类确认它们之间是否恰当的协作。
        .系统测试将系统当成一个黑箱,验证系统是否具备用户所要求的所有功能。
        .验收测试由客户完成,与系统测试类似,验证系统是否满足所有的需求。
        不同的测试小组使用不同的UML图作为测试依据:单元测试使用类图和类规格说明;集成测试使用组件图和合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。
 
       系统分析阶段
        在信息系统开发实践中,经过成功和失败的教训,使人们认识到,为了使开发出来的目标系统能满足实际需要,在着手编程之前,首先必须要有一定的时间用来认真考虑以下问题:
        ——系统所要求解决的问题是什么?
        ——为解决该问题,系统应干些什么?
        ——系统应该怎么去干?
        在总体规划阶段,通过初步调查和可行性分析,建立了目标系统的目标,已经回答了上的第一个问题。而第二个问题的解决,正是系统分析的任务,第三个问题则由系统设计阶段解决。
        要解决“系统应干些什么”的问题,系统分析人员必须与用户密切协商,这是系统分析工作的特点之一。根据现行信息系统与计算机信息系统各自的特点,认真调查和分析用户需求。所谓用户需求,是指目标系统必须满足的所有性能和限制,通常包括功能要求、性能要求、可靠性要求、安全保密要求以及开发费用、开发周期、可使用的资源等方面的限制。弄清哪些工作交由计算机完成,哪些工作仍由人工完成,以及计算机可以提供哪些新功能。这样就可以在逻辑上规定目标系统目标的功能,而不涉及具体的物理实现,也就解决了“系统应干些什么”的问题。
        系统规格说明书是系统分析阶段的最后结果,它通过一组图表和文字说明描述了目标系统的逻辑模型。设计逻辑模型是系统分析工作的另一个特点。逻辑模型包括数据流程图、数据字典、基本加工说明等。它们不仅在逻辑上表示目标系统目标所具备的各种功能,而且还表达了输入、输出、数据存储、数据流程和系统环境等。逻辑模型只告诉人们目标系统要“干什么”,而暂不考虑系统怎样来实现的问题。
        简单说来,系统分析阶段是将目标系统目标具体化为用户需求,再将用户需求转换为系统的逻辑模型,系统的逻辑模型是用户需求明确、详细的表示。
   题号导航      2014年上半年 系统分析师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第28题    在手机中做本题