编写测试计划的目的是（54)。<br />①测试工作顺利进行<br />②使项目参与人员沟通更舒..

免费智能真题库 > 历年试卷 > 软件评测师 > 2011年下半年软件评测师上午试卷综合知识

第54题

知识点：测试计划制定评价计划规范化人员沟通软件过程

关键词：测试计划沟通软件过程软件质量测试章/节：软件测试过程模型

编写测试计划的目的是（54)。
①测试工作顺利进行
②使项目参与人员沟通更舒畅
③使测试工作更加系统化
④软件过程规范化的要求
⑤控制软件质量

A. ②③⑤

B. ①②③

C. ①②④

D. ①②⑤

相关试题：评价设计

更多>

第54题 2013年下半年

27%

以下关于测试计划的叙述中，不正确的是(54)。


知识点讲解
· 测试计划 · 制定评价计划 · 规范化 · 人员沟通 · 软件过程

测试计划

制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：

①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。

②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。

③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“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配置要求）

检查测试目标

测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。

①度量最终用户响应时间。

②定义最优的硬件配置。

③检查可靠性。

④查看硬件或软件升级。

⑤评估新产品。

⑥确定瓶颈。

⑦度量系统容量。

度量最终用户响应时间

查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。

负载和响应时间度量关系

定义最优的硬件配置

检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。

. 配置1：200MHz、64MB RAM。

. 配置2：200MHz、128MB RAM。

. 配置3：266MHz、128MB RAM。

检查可靠性

确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。

查看硬件或软件升级

执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。

评估新产品

可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。

确定瓶颈

可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。

系统不同点的性能

度量系统容量

度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。

响应时间与负载关系

制定评价计划

制定评价计划的活动由3个子活动组成：

①把评价方法编成文档，起草计划；

②优化评价计划；

③根据可用资源安排评价动作的进度。

编制评价方法文档和起草计划

把规定的测量或验证与要评价的各种产品部件的形式组合起来，以便把对部件实施的测量或验证的详细方法编成文档。

评价者应分析评价规格说明中规定的有关测量或验证的技术约束条件。这些约束条件可能包括：

①软件部件所用的形式；

②软件部件说明的电子或书面形式；

③预定义评价方法；

④支持评价技术的工具的可用性；

⑤软件部件的规模。

对评价规格说明中规定的每种测量或验证，评价者都应把有关的评价方法编成文档。

当描述的评价方法是基于使用软件工具的时候，应在评价计划中标识该工具。这种标识应至少包括工具的名称、版本标识和它的来源（如：供方）。

对评价的产品执行程序时，也应说明运行环境以及实际工作中可用的条款。

测量的优化

每个基本评价方法都计划应用在供评价的各个软件部件上。也会出现将不同的基本评价方法用于同一个软件部件的情况。

应对评价计划草案进行评审，以避免评价者的重复劳动，减少错误风险和降低计划的评价者的工作量。

安排评价动作的进度

评价者应安排计划动作的进度，评价者应考虑人员、软件工具、计算机等资源的可用性。

评价者应就软件及部件的交付进度与请求者达成一致。应规定软件部件的交付介质、形式以及拷贝数量。

应标识评价过程中满足的需求。当请求者不是软件产品的开发者时，应标识评价者和开发者之间的关系。特别是应规定开发者需要的支持。这种支持包括培训、非正式的讨论或办公场所。

必要时，对开发和运行场所的访问也应与所需资源一起规定。

评价计划的内容

评价计划应由两部分组成：评价方法文档和评价者采取评价动作的时间表。

评价计划中某些评价方法的文档可能包括对评价者个人材料的引用。在这种情况下，评价者应能判断该方法与相应评价规格说明元素的针对性，以及在应用该方法时，其自身的能力。

规范化

关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有：1NF、2NF、3NF、BCNF、4NF和5NF，其中1NF级别最低。这几种范式之间

成立。

通过分解，可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式，这种过程叫作规范化。下面将给出各个范式的定义。

1NF（第一范式）

【定义7.10】若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。记为R∈1NF。

例如，供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下：

FIRST（Sno，Sname，Status，City，Pno，Qty）

F=｛Sno→Sname，Sno→Status，Status→City，（Sno，Pno）→Qty｝

对具体的关系FIRST如下表所示。从下表中可以看出，每一个分量都是不可再分的数据项，所以是1NF的。但是，1NF存在4个问题：

FIRST

（1）冗余度大。例如每个供应者的Sno、Sname、Status、City要与其供应的零件的种类一样多。

（2）引起修改操作的不一致性。例如供应者S1从“天津”搬到“上海”，若不注意，会使一些数据被修改，另一些数据未被修改，导致数据修改的不一致性。

（3）插入异常。关系模式FRIST的主码为Sno、Pno，按照关系模式实体完整性规定主码不能取空值或部分取空值。这样，当某个供应者的某些信息未提供时（如Pno），则不能进行插入操作，这就是所谓的插入异常。

（4）删除异常。若供应商S4的P2零件销售完了，并且以后不再销售P2零件，那么应删除该元组。这样，在基本关系FIRST找不到S4，可S4又是客观存在的。

正因为上述4个原因，所以要对模式进行分解，并引入了2NF。

2NF（第二范式）

【定义7.11】若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。

换句话说，当1NF消除了非主属性对码的部分函数依赖，则称为2NF。

例如，FIRST关系中的码是Sno、Pno，而Sno→Status，因此非主属性Status部分函数依赖于码，故非2NF的。

若此时，将FIRST关系分解为：

FIRST₁（Sno，Sname，Status，City）∈ 2NF

FIRST₂（Sno，Pno，Qty）∈2NF

因为分解后的关系模式FIRST1的码为Sno，非主属性Sname、Status、City完全依赖于码Sno，所以属于2NF；关系模式FIRST₂的码为Sno、Pno，非主属性Qty完全依赖于码，所以也属于2NF。

3NF（第三范式）

【定义7.12】若关系模式R（U，F）中不存在这样的码X，属性组Y及非主属性

使得X→Y，

成立，则关系模式R∈3NF。

即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。

例如，FIRST₁?3NF，因为在分解后的关系模式FIRST₁中有Sno→Status，Status→City，存在着非主属性City传递依赖于码Sno。若此时将FIRST₁继续分解为：

FIRST₁₁（Sno，Sname，Status）∈ 3NF

FIRST₁₂（Status，City）∈3NF

通过上述分解，数据库模式FIRST转换为FIRST₁₁（Sno，Sname，Status）、FIRST₁₂（Status，City）、FIRST₂（Sno，Pno，Qty）三个子模式。由于这三个子模式都达到了3NF，因此称分解后的数据库模式达到了3NF。

可以证明，3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，所以具有较好的性能。对于非3NF的1NF、2NF其性能弱，一般不宜作为数据库模式，通常要将它们变换成为3NF或更高级别的范式，这种变换过程称为“关系模式的规范化处理”。

BCNF（Boyce Codd Normal Form，巴克斯范式）

【定义7.13】关系模式R∈1NF，若X→Y且

时，X必含有码，则关系模式R∈BCNF。

也就是说，当3NF消除了主属性对码的部分函数依赖和传递函数依赖，则称为BCNF。

结论：一个满足BCNF的关系模式，应有如下性质。

（1）所有非主属性对每一个码都是完全函数依赖。

（2）所有非主属性对每一个不包含它的码，也是完全函数依赖。

（3）没有任何属性完全函数依赖于非码的任何一组属性。

例如，设R（Pno，Pname，Mname）的属性分别表示零件号、零件名和厂商名，如果约定，每种零件号只有一个零件名，但不同的零件号可以有相同的零件名；每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖：

Pno→Pname，（Pname，Mname）→Pno

由于该关系模式R中的候选码为（Pname，Mname）或（Pno，Mname），因而关系模式R的属性都是主属性，不存在非主属性对码的传递依赖，所以R是3NF的。但是，主属性Pname传递依赖于码（Pname，Mname），因此R不是BCNF的。当一种零件由多个生产厂家生产时，零件名与零件号间的联系将多次重复，带来冗余和操作异常现象。若将R分解成：

R1（Pno，Pname）和R2（Pno，Mname）

就可以解决上述问题，并且分解后的关系模式R1、R2都属于BCNF。

4NF（第四范式）

【定义7.14】关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y且

时，X必含有码，则关系模式R（U，F）∈4NF。

4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。

注意：如果只考虑函数依赖，关系模式最高的规范化程度是BCNF；如果考虑多值依赖，关系模式最高的规范化程度是4NF。

连接依赖5NF

连接依赖：当关系模式无损分解为n个投影（n>2）会产生一些特殊的情况。下面考虑供应商数据库中SPJ关系的一个具体的值，如下图所示。

关系SPJ是三个二元投影的连接

第一次SP、PJ投影连接“

”起来的结果比原始SPJ关系多了一个元组“S2，P1，J2”，即上图中带下画线的元组。第二次连接的结果去掉了多余的元组，从而恢复了原始的关系SPJ。在这种情况下，原始的SPJ关系是可3分解的。注意，无论我们选择哪两个投影作为第一次连接，结果都是一样的，尽管在每种情况下中间结果不同。

SPJ的可3分解性是基本与时间无关的特性，是关系模式的所有合法值满足的特性，也就是说，这是关系模式满足一个特定的与时间无关的完整性约束。将这种约束简称为3D（3分解）约束。上述情况就是连接依赖要研究的问题。

连接依赖：如果给定一个关系模式R，R₁，R₂，R₃，…，R_n是R的分解，那么称R满足连接依赖JD^*｛R₁，R₂，R₃，…，R_n｝，当且仅当R的任何可能出现的合法值都与它在R₁，R₂，R₃，…，R_n上的投影等价。

形式化地说，若R=R₁∪R₂∪…∪R_n，且

，则称R满足连接依赖JD^*｛R₁，R₂，R₃，…，R_n｝。如果某个R_i，就是R本身，则连接依赖是平凡的。

为了进一步理解连接依赖的概念，我们考虑银行数据库中的子模式：贷款（L-no，Bname，C-name，amount）。其中：

.贷款号为L-no的贷款是由机构名为Bname贷出的。

.贷款号为L-no的贷款是贷给客户名为C-name的客户。

.贷款号为L-no的贷款的金额是amount。

我们可以看到这是一个非常直观的逻辑蕴涵连接依赖：

JD^*（（L-no，Bname），（L-no，C-name），（L-no，amount））

这个例子说明了连接依赖很直观，符合数据库设计的原则。

【定义7.15】一个关系模式R是第五范式（也称投影-连接范式PJNF），当且仅当R的每一个非平凡的连接依赖都被R的候选码所蕴涵，记作5NF。

“被R的候选码所蕴涵”的含义可通过SPJ关系来理解。关系模式SPJ并不是5NF的，因为它满足一个特定连接依赖，即3D约束。这显然没有被其唯一的候选码（该候选码是所有属性的组合）所蕴涵。其区别是，关系模式SPJ并不是5NF，因为它是可被3分解的，可3分解并没有为其（Sno，Pno，Jno）候选码所蕴涵。但是将SPJ3分解后，由于3个投影SP、PJ、JS不包括任何（非平凡的）连接依赖，因此它们都是5NF的。

人员沟通

人员沟通在“风暴期”中显得尤为重要。因为在这个阶段，大家有可能质疑系统规划与管理师的能力。如果系统规划与管理师是在这个团队里被提拔上来的，大家对他还比较了解。但如果系统规划与管理师此时面对的是一个全新的团队，且员工的风格又大部分都是技术型的，对系统规划与管理师的能力也不太了解，那么，此时的系统规划与管理师就要多利用自己在管理上的优势，不断与要完成关键指标的员工保持密切沟通，多听、多问、多了解员工的想法，看看他们在执行过程中遇到什么困难，是否需要帮助。

在这个阶段，系统规划与管理师一定要想办法在一两件自己擅长的事情上，建立自己在团队中的威望，让大家感到系统规划与管理师是有能力的，也能为大家解决一些问题。系统规划与管理师一定要有人际敏感度，就是要处理好与团队成员之间的关系，因为时间短、任务重，大家的压力都很大，如果能一起挺过这一关，就将为后续的合作打下良好的基础。

在现实IT服务项目当中，经常会出现一种情况，即整个IT服务团队长期驻扎在客户现场，有的员工从一招进来就进入该项目，平时只有开会或费用报销时才回一趟公司，一个项目结束后，又很快被派到另外一个项目上，还是重复以前的工作状态。一段时间后，对客户的了解比对自己公司或组织的了解还深。因此，这些员工很容易被组织忽略，他们也往往缺少对公司企业文化、价值观的了解，所以流失率相对较高。其实这样的员工随时处于风暴期当中，如果系统规划与管理师的关注度不够，处理不当，很容易造成人员流失，再次陷入匆忙的招人／调人、工作交接或和客户解释工作的旋涡中，所以，系统规划与管理师需要对他们多关注，尤其是在他们需要组织帮助、需要系统规划与管理师帮助的时候。那么，他们平时不经常在公司内，系统规划与管理师怎样才能知道他们对公司或组织的需求呢？

很简单，系统规划与管理师可以多花些时间主动与这些员工进行沟通。定期召开现场会议或电话会议，随时向他们传达公司或部门近期发生的大事，以及客户对他们工作的评价，往往员工很在意客户通过第三方给他们的评价。在此，系统规划与管理师一定要注意的是，这种反馈要以正面的信息为主，如果客户提出来的确有需要改进之处，那系统规划与管理师也要站在员工的角度一起想办法解决问题，而非刻板的传达客户的不满。此外，系统规划与管理师一定要与这个团队的小组长多沟通，因为平时大部分时间，异地团队是靠这个小组长来带领的，他的一言一行对整个团队影响非常大。

除此之外，系统规划与管理师也可以不定期地去客户现场看望他们，从情感上照顾他们，让他们亲身感受到被重视的感觉。

还有一种实际情况是“小团体”现象。通常遇到这种情况，系统规划与管理师都很头疼，尤其是在风暴期，如果没有处理好这个问题，系统规划与管理师就会有被架空的风险。“解铃还须系铃人”，这个系铃人就是这个小团体的精神领袖，他们往往以资格老或能力强而取信于众。所以，遇到这种情况，系统规划与管理师首先要切忌一个思维定式，即“只要是小团体，就肯定是不好的”，其实未必如此，仔细分析，小团体的凝聚力往往非常强，执行力也非常强，如果这个团队能在正确的方向上贡献他们的聪明才智，这时不但没必要去打散他们，甚至可以对其中做得比较好的员工给予一些鼓励，请他介绍自己的成功经验，往往这些员工在介绍成功经验时，就会意识到自己成功的特殊性，系统规划与管理师可通过不断让小团队的个人分享成功的方式，让他们多与其他团队成员进行更多的交流。

如果小团队的方向与整个项目团队乃至整个组织的方向不一致，而且系统规划与管理师与“系铃人”多次沟通还没效果，系统规划与管理师就要考虑是否在工作分配或岗位分配上做些调整。总而言之，一切出发点都是以组织和团队的整体利益为主，而非系统规划与管理师的个人判断。

软件过程

在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为"软件过程"。过程是活动的集合，活动是任务的集合。软件过程有3层含义：一个是个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等；二是整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体；三是工程含义，即指解决软件过程的工程，应用软件的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件的生产率，降低成本。

能力成熟度模型（CMM）

CMM将软件组织的过程能力分成五个成熟度级别：初始级、可重复级、已定义级、已管理级和优化级。由低到高，软件开发生产精度越来越高，每单位工程的生产周期越来越短。

（1）初始级。软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。

（2）可重复级。建立了基本的项目管理过程来跟踪费用、进度和功能特性；制定了必要的过程纪律，能重复早先类似应用项目取得的成功。

（3）定义级。已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

（4）管理级。收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解和控制。

（5）优化级。过程的量化反馈和先进的新思想、新技术促使过程不断改进。

能力成熟度模型集成（CMMI）

CMM的成功导致了适用不同学科领域的模型的衍生，如系统工程的能力成熟度模型，适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科，因此有必要将各种过程改进的工作集成起来。1998年，由美国产业界、政府和卡内基.梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。

CMMI提供了两种表示方法：阶段式模型和连续式模型。

1）阶段式模型

阶段式模型的结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版中有5个成熟度等级。

初始的：过程不可预测且缺乏控制。

已管理的：过程为项目服务。

已定义的：过程为组织服务。

定量管理的：过程已度量和控制。

优化的：集中于过程改进。

2）连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（Capability Level，CL）。CMMI中包括6个过程域能力等级，等级号为0-5。能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级。

能力等级可以独立地应用于任何单独的过程域，任何一个能力等级都必须满足比它等级低的能力等级的所有准则。对各能力等级的含义简述如下。

CLo（未完成的）：过程域未执行或未得到CLi中定义的所有目标。

CLi（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。

CL2（已管理的）：其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。

CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。

CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。

CLs（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。

题号导航 2011年下半年软件评测师上午试卷综合知识

本试卷我的完整做题情况



	第54题在手机中做本题