免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2012年下半年 信息系统项目管理师 下午试卷 案例
  第2题      
  知识点：   项目管理   编码   编码阶段   测试报告   关键技术   开发过程   开发人员   配置管理   配置库   评审   系统测试   详细设计   项目计划   需求分析   验收测试   质量保证   总体设计

 
某项目是一个新产品开发项目，项目计划开发周期为12个月，项目团队有11个人，包括：项目经理1人，开发工程师5人，测试工程师2人，文档工程师1人，配置管理1人，SQA1人。
项目于2010年7月1日开始，项目计划如下：需求分析一个月，总体设计一个月，详细设计二个月，编码五个月，测试一个半月，文档准备、客户验收测试半个月，修改BUG 并发布半个月，项目开工后，项目团队充满激情地努力工作，项目经理也非常有信心按期完成该项目，并在开工会上公布了该项目的考核与激励制度。
2010年8月1日，项目组按期完成《需求规格设计说明书》；2010年9月1日，按期完成了总体设计。
此时，市场部提出，最近有几名客户都问到这个产品了，9月份可能有客户要看演示的DEMO,需要加快开发进度，问项目经理是否可以先开发DEMO,详细设计后后面再补充， 先把产品的原型做出来。
项目经理经过与项目组及项目管理部协商，决定去掉详细设计这个环节，直接进入产品的编码阶段，安排开发工程师根据总体设计负责各自模块的开发工作。
5名开发工程师组成的开发小组进入非常忙碌的编码阶段后，经常加班加点，开发过程中，由于原来制定的计划已完全被打乱，SQA无法再根据原来的质量保证计划进行跟踪，项目组其他人员也已无法发挥作用。
2011年2月15日，项目经理向公司管理层反映这个项目存在的问题，市场部提的需求有部分不能实现，遇到了技术瓶颈，而且有团队成员要离职，为此由项目管理部组织会议，对新增的部分需求进行评审，包括研发总监、研发副总裁在内，最终决定产品要继续开发， 确定关键技术问题的解决时间为2011年3月15日，其他工作继续进行。
遗憾的是，关键技术问题一直到5月1日才解决，这时已有2名开发人员因为信心问题而离职，项目经理除了要考虑项目进度外，还要考虑项目资源，由于此时其他项目任务也很重，公司资源很紧张，他不得不重新招聘开发人员。
等项目经理招到2个新人后，已是2011年6月15日，这本应是项目计划中系统测试结束的关键里程碑，但现在编码任务至少还需要1个月，在公司的月度会议上，项目经理向包括总裁在内的各位高层领导做了汇报，并因为项目进度延迟受到了批评。
2011年8月1日，测试部终于拿到了系统的第一个测试版本。
2011年10月20日，系统终于开发和测试完毕，测试部输出最终的测试报告，同意该产品向市场发布，所有的文档，包括《详细设计》、《需求规格说明书书》、《产品说明书》 等还没有上传到配置库。
 
问题：2.1   请简要分析项目管理方面存在哪些问题？
 
问题：2.2   支出本题案例中的项目至少延期了多少时间？
 
问题：2.3   为了实现本题案例中市场部提出的要求，作为项目经理，你认为可以采取哪些措施来应对？
 
 
 

   知识点讲解    
   · 项目管理    · 编码    · 编码阶段    · 测试报告    · 关键技术    · 开发过程    · 开发人员    · 配置管理    · 配置库    · 评审    · 系统测试    · 详细设计    · 项目计划    · 需求分析    · 验收测试    · 质量保证    · 总体设计
 
       项目管理
        定义
        把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求。管理一个项目包括：
        .识别要求。
        .确定清楚而又能实现的目标。
        .权衡质量、范围、时间和成本方面的要求，使技术规格说明书、计划和方案适合于各干系人的不同需求与期望。
        项目管理需要的知识领域
        除了专门的项目管理技术以外，项目管理组至少应能理解和使用以下5方面的知识领域：
        .项目管理知识体系。
        .应用领域的知识、标准和规定。
        .项目环境知识。
        .通用的管理知识和技能。
        .软技能（处理人际关系技能）。
        项目管理体系
        项目管理体系是指用于管理项目的工具、技术、方法、资源和规程。项目管理计划说明如何使用项目管理体系。
        项目管理环境
        项目管理团队应该考虑的项目环境包括：
        .社会环境：经济、人口、教育、道德、种族、宗教和其他特征等。
        .政治环境：法律、风俗和政治风气等。
        .自然环境：生态和自然地理等。
        项目管理办公室
        项目管理办公室（PMO）是在管辖范围内集中、协调地管理项目的组织单元。也可指“大项目管理办公室”、“项目办公室”或“大项目办公室”。PMO监控项目、大项目或各类项目组合的管理。由PMO管理的项目不必要有特定的关系，PMO关注与上级组织或客户的整体业务目标相联系的项目或子项目之间的协调计划、优先级和执行情况。
        PMO执行的职责可以是一个宽广的范围，包括从以培训、软件、标准政策和规程、模板的形式提供项目管理支持功能，到实际直接管理项目和项目的结果。
        PMO可以存在于任何组织结构中，包括职能型组织。
        项目经理和项目管理办公室的区别如下：
        .追求的目标不同。项目经理关注于特定项目的目标，而PMO管理主要的大项目范围的变化，并将之视为更好地达到业务目标的潜在机会，其工作目标包含组织级的观点。
        .项目经理控制赋予项目的资源以最好地实现项目目标，而PMO对所有项目之间的共享资源进行优化使用。
        .项目经理管理本项目的范围、进度、费用和质量，而PMO管理整体的风险、整体的机会和所有项目的依赖关系。
        过程和过程组
        过程就是一组为了完成一系列事先指定的产品、成果或服务而必须执行的互相联系的行动和活动。
        项目管理过程由项目团队实施，包括两大类：
        .面向管理的过程。即项目管理过程，其目的是启动、规划、执行、监控和结束一个项目。
        .面向产品的过程。一般由项目生命期规定，并因领域而异。
        项目管理过程和创造产品的过程从项目开始到结束始终彼此重叠交互。
        任何项目都必须执行5个项目过程组，它们与应用领域或特定行业无关。过程组不是项目阶段，每一阶段或子项目都要重复过程组的所有子过程。
        .启动过程组。定义并批准项目或阶段。在多阶段项目中，后续阶段进行的启动过程是为了确认在指定项目章程与拟定初步项目范围说明书过程中所做的原假设与决策的合理性。启动过程组也定义了项目意图，确定了目标，并授权项目经理进行项目。
        .规划过程组。定义和细化目标，规划最佳的行动方案，即从各种备选方案中选择最优方案，以实现项目或阶段所承担的目标和范围。项目团队应让所有项目干系人参与项目计划过程。当项目计划工作结束时，不管是由组织还是由项目团队负责，都要有明确的指导方针，否则将无法确定如何进行后续的反馈和细化。项目管理计划的渐进明细经常被称作“滚动式计划”，这意味着计划是一个迭代和持续的过程。
        .执行过程组。整合人员和其他资源，在项目的生命期或某个阶段执行项目管理计划。
        .监控过程组。要求定期测量和监控项目进展，识别与项目管理计划的偏差，以便在必要时采取纠正措施，确保项目或阶段目标达成。
        .收尾过程组。正式接受产品、服务或工作成果，有序地结束项目或阶段。
        项目管理过程组和“计划-执行-检查-行动（即PDCA）”循环的对应关系如下图所示。
        
        项目管理过程组和PDCA循环的对应
        规划过程组与PDCA循环中的“计划”对应；执行过程组与循环中的“执行”对应；监控过程组与循环中的“检查”和“行动”对应。启动过程组是这些循环的开始，而收尾过程组是其结束。
        过程的交互
        项目管理过程组通过它们各自所产生的结果而联系起来——一个过程的结果或者输出通常会成为另一个过程的输入或者整个项目的最终结果。在项目过程组之间以及项目过程本身当中，这种联系是迭代的。
        如果一个项目被划分成阶段，每个阶段中的过程经常会反复进行。项目中过程组的相互作用如下图所示。
        
        过程组的相互作用
        5个项目过程组与44个项目管理过程及9个项目管理知识域的映射关系如下表所示。
        
        过程组、过程和类知识域的映射关系
        注：1．在《信息系统项目管理师教程》中，“团队组建”被划分为规划过程组。在PMBOK 2004版中，“团队组建”在执行过程组中，笔者认为划分在执行过程组中更合理。
        2．发包规划在《信息系统项目管理师教程》中也称为计划签约和编制合同。
 
       编码
               编码过程
               在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：
               （1）确定源程序的标准格式，制订编程规范。
               （2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。
               （3）编写代码。
               （4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。
               编码准则
               在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。
               具体来说，在编写代码时，需要做到以下几点：
               .保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容：
                      .命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。
                      .编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：
                      .尽量使用整数（char、short、int和long）的加法和减法。
                      .如果没有硬件支持，尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持，尽量避免使用浮点数。
                      下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       编码阶段
        . 可靠性测试（含于单元测试）；
        . 排错；
        . 调整可靠性活动计划；
        . 收集可靠性数据；
        . 明确后续阶段的可靠性活动的详细计划；
        . 编制可靠性文档。
 
       测试报告
        测试报告是整个项目的第一份供大家交流和供领导查阅的报告，人们对工程的满意程度和对工程质量的认可很大程度上来源于这份报告。通常在独立网络测试后，要总结测试数据，并基于此对测试过的同类产品进行排序；而系统内部的测试仅是得出一个简单的结论。
        测试报告呈现的内容和采取的表现形式非常重要，测试报告通常包含以下信息。
        ◆测试目的：用一句或两句话解释本次测试的目的。
        ◆结论：从测试中得到的信息推荐下一步的行动。
        ◆测试结果总结：对测试进行总结并由此得出结论。
        ◆测试内容和方法：简单地描述测试是怎样进行的，应该包括负载模式、测试脚本和数据收集方法，并且要解释采取的测试方法怎样保证测试结果和测试目的的相关性，以及测试结果是否可重现。
        ◆测试配置：网络测试配置用图形表示出来。
        测试报告的形式可以是一个简短的总结（2～4页），也可以是一个很长的书面文档（5～20页）。测试总结可以使用图形表示测试结果，如应用程序的响应时间、吞吐量和产品评估。而系统衰减性测试、配置规模测试和应用程序的功能／特性测试的测试报告还要包括更多的信息。
        在非常特殊的情况下，测试报告需要长达50页。它通常包括从项目开始到结束按时间编排的所有活动，以及非常详细的问题信息和解决问题的信息。
 
       关键技术
        一个完整的嵌入式DBMS由若干子系统组成，包括主DBMS、同步服务器、嵌入式DBMS、连接网络等几个子系统，如下图所示。
        
        嵌入式数据库系统组成
        （1）嵌入式DBMS。嵌入式DBMS是一个功能独立的单用户DBMS。它可以独立于同步服务器和主DBMS运行，对嵌入式系统中的数据进行管理，也可以通过同步服务器连接到主服务器上，对主数据库中的数据进行操作，还可以通过多种方式进行数据同步。
        （2）同步服务器。同步服务器是嵌入式数据库和主数据库之间的连接枢纽，保证嵌入式数据库和主数据库中数据的一致性。
        （3）数据服务器。数据服务器的主数据库及DBMS可以采用Oracle或Sybase等大型通用数据库系统。
        （4）连接网络。主数据库服务器和同步服务器之间一般通过高带宽、低延迟的固定网络进行连接。移动设备和同步服务器之间的连接根据设备具体情况可以是无线局域网、红外连接、通用串行线或公众网等。
               移动DBMS的关键技术
               嵌入式移动数据库在实际应用中必须解决好数据的一致性（复制性）、高效的事务处理和数据的安全性等问题。
               （1）数据的一致性。嵌入式移动数据库的一个显著特点是，移动数据终端之间以及与同步服务器之间的连接是一种弱连接，即低带宽、长延迟、不稳定和经常性断接。为了支持用户在弱环境下对数据库的操作，现在普遍采用乐观复制方法，允许用户对本地缓存上的数据副本进行操作。待网络重新连接后再与数据库服务器或其他移动数据终端交换数据修改信息，并通过冲突检测和协调来恢复数据的一致性。
               （2）高效的事务处理。移动事务处理要解决在移动环境中频繁的、可预见的断接情况下的事务处理。为了保证活动事务的顺利完成，必须设计和实现新的事务管理策略和算法。
               （3）数据的安全性。许多应用领域的嵌入式设备是系统中数据管理或处理的关键设备，因此嵌入式设备上的DBS对存取权限的控制较严格。同时，许多嵌入式设备具有较高的移动性、便携性和非固定的工作环境，也带来潜在的不安全因素。同时某些数据的个人隐私性又很高，因此在防止碰撞、磁场干扰、遗失、盗窃等方面对个人数据的安全性需要提供充分的保证。
               移动DBMS的特性
               移动DBMS的计算环境是传统分布式DBMS的扩展，它可以看做客户端与固定服务器结点动态连接的分布式系统。因此移动计算环境中的DBMS是一种动态分布式DBMS。由于嵌入式移动DBMS在移动计算的环境下应用在EOS之上，所以它有自己的特点和功能需求：
               （1）微核结构。考虑到嵌入式设备的资源有限，嵌入式移动DBMS应采用微型化技术实现，在满足应用的前提下紧缩其系统结构以满足嵌入式应用的需求。
               （2）对标准SQL的支持。嵌入式移动DBMS应能提供了对标准SQL的支持。支持SQL92标准的子集，支持数据查询（连接查询、子查询、排序、分组等）、插入、更新、删除多种标准的SQL语句，充分满足嵌入式应用开发的需求。
               （3）事务管理功能。嵌入式移动DBMS应具有事务处理功能，自动维护事务的完整性、原子性等特性；支持实体完整性和引用完整性。
               （4）完善的数据同步机制。数据同步是嵌入式数据库最重要的特点。通过数据复制，可以将嵌入式数据库或主数据库的变化情况应用到对方，保证数据的一致性。
               （5）支持多种连接协议。嵌入式移动DBMS应支持多种通信连接协议。可以通过串行通信、TCP/IP、红外传输、蓝牙等多种连接方式来实现与嵌入式设备和数据库服务器的连接。
               （6）完备的嵌入式数据库的管理功能。嵌入式移动DBMS应具有自动恢复功能，基本无须人工干预进行嵌入式数据库管理，并能够提供数据的备份和恢复，保证用户数据的安全可靠。
               （7）支持多种EOS。嵌入式移动DBMS应能支持Windows CE、Palm等多种目前流行的EOS，这样才能使嵌入式移动DBMS不受移动终端的限制。
               另外，一种理想的状态是用户只用一台移动终端（如手机）就能对与它相关的所有移动数据库进行数据操作和管理。这就要求前端系统具有通用性，而且要求移动数据库的接口有统一、规范的标准。前端管理系统在进行数据处理时自动生成统一的事务处理命令，提交当前所连接的数据服务器执行。这样就有效地增强了嵌入式移动DBMS的通用性，扩大了嵌入式移动数据库的应用前景。
               在嵌入式移动DBMS中还需要考虑诸多传统计算环境下不需要考虑的问题，例如，对断接操作的支持、对跨区长事务的支持、对位置相关查询的支持、对查询优化的特殊考虑，以及对提高有限资源的利用率和对系统效率的考虑等。为了有效地解决这些问题，诸如复制与缓存技术、移动事务处理、数据广播技术、移动查询处理与查询优化、位置相关的数据处理及查询技术、移动信息发布技术、移动Agent等技术仍在不断地发展和完善，会进一步促进嵌入式移动DBMS的发展。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       开发人员
        ①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       配置管理
        随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
               （1）该项目对配置管理的要求。
               （2）实施配置管理的责任人、组织及其职责。
               （3）需要开展的配置管理活动及其进度安排。
               （4）采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
               （1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
               （2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置库
        配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
        .哪些客户已提取了某个特定的系统版本。
        .运行一个给定的系统版本需要什么硬件和系统软件。
        .一个系统到目前已生成了多少个版本，何时生成的。
        .某一特定的构件变更，会影响系统的哪些版本。
        .一个特定的版本曾提出过哪几个变更请求。
        .一个特定的版本有多少已报告的错误。
        使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
        配置库一般可以分为如下三种类型：
        .开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
        .受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
        .产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
        配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
        
        配置库的建库模式
 
       评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试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）代码设计。
        代码设计就是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。
        （2）数据库设计。
        数据库设计就是构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。
        （3）输入／输出设计。
        输入／输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。
        （4）用户界面设计。
        用户界面设计是指在用户与系统之间架起一座桥梁。主要内容包括：定义界面形式；定义基本的交互控制形式；定义图形和符号；定义通用的功能键和组合键的含义及其操作内容；定义帮助策略，等等。
        （5）处理过程设计。
        总体设计将系统分解为许多模块，并基本决定了每个模块的功能和界面。处理过程设计则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。通过处理过程设计，为编写程序制定一个周密的计划。一般来说，每一个功能模块都应设计一个处理流程。
 
       项目计划
        项目计划阶段，监理的主要工作如下。
        （1）对软件计划的相关内容（重点是组织、技术标准、开发计划和进度要求等）、项目计划过程、项目计划组织和文档格式等进行审查，确认是否满足要求。
        （2）给出符合要求的结论。
        （3）确定其可否作为软件开发的前提和依据。
        项目计划监理的基本准则如下。
        （1）承建单位制订了软件项目计划，同时该项目计划通过了正式的评审，软件项目计划对项目组织、进度计划、工程标准进行了承诺，项目的风险分析合理，风险管理方案可行。
        （2）项目的阶段划分是明确的。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       验收测试
        验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
        验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
               验收测试的常用策略
               验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
                      正式验收测试
                      正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
                      在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .测试的细节是已知的，并且可以对其进行评测。
                      .这种测试可以自动执行，支持回归测试。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      缺点包括：
                      .要求大量的资源和计划。
                      .这些测试可能是系统测试的再次实施。
                      .可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
                      非正式验收测试
                      在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
                      大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      .与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
                      缺点包括：
                      .要求资源、计划和管理资源。
                      .无法控制所使用的测试用例。
                      .最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
                      .最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
                      .用于验收测试的资源不受项目的控制，并且可能受到压缩。
               验收测试的条件
               在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
               （1）软件开发已经完成，并全部解决了已知的软件缺陷。
               （2）验收测试计划已经过评审和批准，并且置于文档控制之下。
               （3）对软件需求说明书的审查已经完成。
               （4）对概要设计及详细设计的审查已经完成。
               （5）对所有关键模块的代码审查已经完成。
               （6）对单元、集成、系统测试计划和报告的审查已经完成。
               （7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
               （8）使用配置管理工具且代码置于配置控制之下。
               （9）软件问题处理流程已经就绪。
               （10）已经制定、评审并批准验收测试完成标准。
               验收测试的过程
               （1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
               （2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
               （3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
               （4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
               （5）测试实施：测试并记录测试结果。
               （6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
               （7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
               软件配置审核
               软件配置审核包括审查和审核。
               审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
               通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
               对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
               可执行程序的测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
               不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
               验收测试的内容
               具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
               如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
 
       质量保证
        系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是开发高质量的系统。
               质量特性
               讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性，目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代，其主要改进包括将兼容性作和安全性作为质量特性，ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。
                      ISO/ICE 25010系统和软件质量模型
                      ISO/ICE 25010系统和软件质量模型包含8个质量特性，每个特性由一组相关的质量子特性组成，如下图所示。该产品质量模型既可以用于软件，又可以用于任何包含软件的计算机系统。
                      
                      产品质量模型
                      其中，各质量特性和质量子特性的含义如下。
                      （1）功能适合性（functional suitability）。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。
                      .功能完整性（functional completeness）：与对规定任务和用户目标加以实现的功能是否完整有关的属性。
                      .功能适当性（functional appropriateness）：与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。
                      .功能正确性（functional correctness）：与能够得到正确或相符的结果或效果有关的产品或系统属性。
                      （2）性能效率（performance efficiency）。在规定条件下，系统的性能水平与所用资源量之间的关系有关的一组属性。
                      .时间特性（time behavior）：与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。
                      .资源利用率（resource utilization）：与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。
                      .容量（capacity）：与系统满足特定需求时指标参数的最大限制有关的属性。
                      （3）兼容性（compatibility）。与系统或组件与其他系统或组件进行信息交换，或在不同软硬件环境中执行所需功能有关的一组属性。
                      .共存性（co-existence）：与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。
                      .互操作性（interoperability）：与同其他指定系统进行交互操作的能力相关的属性。
                      （4）易用性（usability）。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。
                      .可识别性（appropriateness recognizability）：与用户识别系统是否满足需求有关的属性。
                      .易学性（learnability）：与用户为学习使用产品（例如操作控制、输入、输出）的有效性、效率、风险和满意度相关的属性。
                      .易操作性（operability）：与用户为进行操作和操作控制所付出的努力有关的属性。
                      .错误防御（user error protection）：与阻止用户错误输入有关的属性。
                      .界面美观性（user interface aesthetics）：与系统用户界面使用户进行愉快满意交互有关的属性。
                      .可访问性（accessibility）：与用户可访问系统完成特定目标的范围和能力有关的属性。
                      （5）可靠性（reliability）。与在规定的一段时间内和规定的条件下，系统维持在其性能水平有关的能力。
                      .成熟性（maturity）：与正常操作情况下满足可靠性需求有关的属性。
                      .可用性（availability）：与系统运行可用使用能力有关的属性。
                      .容错性（fault tolerance）：与在系统错误或违反指定接口的情况下，维持指定的性能水平的能力有关的属性。
                      .易恢复性（recoverability）：与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的属性。
                      （6）安全性（security）。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。
                      .机密性（confidentiality）：与系统确保只有授权才能访问其数据能力有关的属性。
                      .完整性（integrity）：与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。
                      .不可抵赖性（non-repudiation）：与对系统使用行为及发生时间真实性有关的属性。
                      .可审计性（accountability）：与对系统使用行为进行追踪有关的属性。
                      .真实性（authenticity）：与证明主体或资源身份是所声称的身份有关的属性。
                      （7）可维护性（maintainability）。与进行规定的修改所需要的努力有关的一组属性。
                      .模块性（modularity）：与所组成系统的模块独立性有关的属性。
                      .可复用性（reusability）：与模块用于其他系统有关的属性。
                      .易分析性（analyzability）：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的属性。
                      .易修改性（modifiability）：与进行修改、排错或适应环境变换所需努力有关的属性。
                      .易测试性（testability）：为确认经修改系统所需努力有关的属性。
                      （8）可移植性（portability）。与系统可从某一环境转移到另一环境的能力有关的一组属性。
                      .适应性（adaptability）：与系统转移到不同环境时的处理或手段有关的属性。
                      .易安装性（installability）：与在指定环境下对系统进行安装／卸载所需努力有关的属性。
                      .易替换性（replaceability）：与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。
                      Mc Call软件质量模型
                      Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性，如下图所示。Mc Call也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。
                      
                      Mc Call软件质量模型
               质量保证
               质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的产品。在系统质量方面强调三个要点：首先系统必须满足用户规定的需求，与用户需求不一致的系统，就无质量可言；其次系统应遵循规定标准所定义的一系列开发准则，不遵循这些准则的系统，其质量难以得到保证；最后系统还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，而这些隐含的需求可能未被明确地写在用户规定的需求中，如果系统只满足它的显性需求而不满足其隐含需求，那么该系统的质量是令人担忧的。
               质量保证包括7个主要活动相关的各种任务，分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量（metrics）、记录保存和报告。
 
       总体设计
        总体设计也被称为概要设计，是系统开发过程中关键的一步。系统的质量及一些整体特性基本上是由这一步的成果所决定的。总体设计的主要任务是完成对系统总体结构和基本框架的设计。系统总体结构设计包括两方面的内容，系统总体布局设计和系统模块化结构设计。
        模块化设计的工作任务包括如下内容。
        .按需求和设计原则将系统划分为若干功能模块。
        .决定每个模块的具体功能和职责。
        .分析和确定模块间的调用关系。
        .确定模块间的信息传递。
        系统总体布局方案包括系统网络拓扑结构设计和系统资源配置设计方案。
   题号导航      2012年下半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第2题    在手机中做本题