信息系统项目管理师考试大纲知识点详解_图文

信息系统项目管理师考试大纲知识点详解_图文内容摘要：

靠程度之后再开始 β 测试 ：β测试是由软件的多个用户在 实际使用环境 下进行的测试，这些用户返回有关错误信息给开发者，β测试是在开发者无法控制的环境下进行的软件现场应用。 β 测试着重于产品的支持性，包括文档、客户培训和支持产品。 只有当 α测试达到一定的可靠程度时，才开始β测试。 它处在整个测试的最后阶段。 软件维护 (1)更正性维护 ：软件产品交付后进行的修改，以更正发现的问题。 (2)适应性维护 ：软件产品交付后进行的修改，以保持软件产 品能在变化后或变化中的环境中可以继续使用。 (3)完善性维护 ：软件产品交付后进行的修改，以改进性能和 可 维护性。 (4)预防性维护 ：软件产品交付后进行的修改，以在软件产品中的潜在错误成为实际错误前，检测和更正它们。 ● 软件质量保证及质量评价 软件质量：软件特性的总合，软件满足规定或潜在用户需求的能力。 11/87 “软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。 软件质量管理过程包括：质量保证过程、验证过程、确认过程、评审过程、审计过程等。 1． 软件质量保证 软件质量保证过程通过 计划制订、实施和完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符合其规定的需求。 软件质量保证计划定义了用于保证为特定产品开发的软件满足用户需求并在项目的约束内具有最高的质量的手段。 2． 验证与确认 验证与确认过程使用能够定位缺陷并便于以后改正的测试技术直接处理软件产品质量问题。 验证与确认过程确定某一开发和维护 活动 的产品是否符合活动的需求， 最 终的软件产品是否达到其意图并满足用户需求。 验证过程 试图确保活动的输出产品已经被正确制造，即活动的输出产品满足前面活动施加的规范说明； 确认过程 则试图确保 建造了正确的产品，即产品满足其特定的目的。 3． 评审与审计 评审与审计过程包括：管理评审、技术评审、检查、走查、审计等。 管理评审 的目的是监控进展，决定计划和进度的状态，确认需求及其系统分配，或评价用于达到目标适应性的管理方法的有效性。 它们支持有关软件项目期间需求的变更和其他变更活动。 技术评审 的目的是评价软件产品。 以确定其对使用意图的适合性，目标是识别规范说明和标准的差异，并向管理提供证据，以表明产品是否满足规范说明并遵从标准，而且可以控制变更。 检查 的目的是检测和识别软件产品异常。 一次检查通常针对产品的 一个相对小的部分。 发现的任何异常都要记录到文档中，并提交。 走查 的目的是评价软件产品，走查也可以用于培训软件产品的听众，主要目标是： 发现异常、改进软件产品、 考 虑其他实现、评价是否遵从标准和规范说明。 走查类似于检查，但通常不那么正式。 走查通常主要由同事评审其工作，以作为一种保障技术。 软件审计 的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。 审计是正式组织的活动，识别违例情况，并产生一个报告，采取更正性行动。 CMMI:软件能力成熟度模型集成模型。 一级，已执行 级。 过程不 可预知，不能很好地被控制且是被动的。 12/87 二级， 已 管理级。 项目级别定义了过程且经常是被动的。  需求管理：管理项目产品和产品组件的需求，识别需求与项目计划和工作产品间的不一致性。  项目策划：建立和维护定义项目活动的计划。  项目监督和控制：了解项目进展，以便当项目性能明显偏离计划时采取适当的纠正措施。  供应商协议管理：管理来自供应商的产品和服务的采购。  度量分析：开发和保持测量能力，以支持管理信息的需要。  配置管理：利用配置标识、配置控制、配置状态记录和配置审计建立和维护工作产品的完整性。  产品和过程质量保证：使员 工和管理者对过程和相关的工作产品能有客观洞察。 三级， 已 定义级。 组织定义了过程且能起到积极主动的作用。  需求开发：引导、分析及建立客户、产品和产品部件的需求。  技术方案：设计、开发和实现对需求的解决方案。  产品集成：将产品组件组装成产品，确保组装后的产品能正常地运行并交付产品。  验证： 确保所选择的工作产品满足指定的需求。  确认： 证实产品或产品部件被置于其预定的环境中时，可以满足预期的使用需求。  组织过程焦点： 基于组织过程和过程资产的现有强项和弱项的深入理解，策划、实施和部署组织的过程改进。  组织过程定义 ：建 立和维护可用的组织过程资产集，工作环境标志，以及对团队的规则和指南。  组织培训： 开发人员的技能和知识，以便他们能有效且高效地履行其角色。  集成项目管理： 是根据由组织的标准过程集剪裁所得的集成的、已定义的过程，建立并管理项目以及利益相关方的参与。  风险管理： 在风险发生前，标识出潜在的问题，以便在产品或项目的整个生存周期中规划风险处理活动，并于必要时启动这些活动，以缓解对目标实现的不利影响。  决策分析和方案： 使用正式的评价过程分析可能的决策，此评价过程按所建立的准则评价所标识的备选方案。 四级， 已定 量管理级。 过 程度量和控制。 13/87  组织过程性能： 建立并维护对组织的标准过程集合的定量了解，并且为定量管理组织的各个项目提供过程性能数据、基线和模型。  定量项目管理： 对项目已定义过程实施定量管理，以便使项目实现所确定的质量和过程性能目标。 五级，优化级。 注重过程改进。  组织性能管理： 对选择并部署渐进式的改进项目和革新式的改进项目，对组织的过程和技术实施可度量的改进。  原因分析和决策： 识别导致缺陷和其他问题的原因，并采取措施，防止将来再次发生这些问题。 ● 软件配置管理 配置管理员根据《项目计划文档》、《配置管理计划》、《配置 项管理表》等文档，创建 构造或发行基线 ，供内部使用或交付给顾客。 软件配置管理是通过在软件生命周期的不同的时间点上对软件配置进行标志并对这些被标志的软件配置项的更改进行系统控制，从而达到保证软件产品的 完整性 和 可追溯性 的过程。 软件配置管理的四个功能： 配置 标识 、 配置控制 、 配置状态发布 、 配置的评审。 接受软件配置管理过程控制的软件受控配置项应包括一切可能对软件产品的完整性和一致性造成影响的组成要素。 比如项目文档、产品文档、代码、支撑数据、项目编译建立环境、项目运行环境等。 配置项 是逻辑上组成软件系统的各组成部分， 是软件配置管理的基础和前提。 基线 是一个配置项或一组配置项在其生命周期的不同时间点通过正式评审而进入正式受控的一种状态，这个过程被称为基线化。 每一个基线都是其下一步开发的出发点和参考点。 上一个基线加上增加和修改的基线内容形成下一个基线。 这就是基线管理， 基线具有以下属性： 通过正式的评审过程建立 基线存在于基线库中，对基线的变更接受更高权限的控制。 基线是进一步开发和修改的基准和出发点 配置 标识 是软件生命周期里选择定义各类配置项，建立各类基线、描述相关软件配置项及其文档的过程。 配置 标识 分为三 个步骤： 将软件分组成一系列软件配置项 14/87 定义对配置项命名规则 对配置项的描述文档（功能，性能，物理特性等） 配置控制 是对配置项的变更申请进行初始化、评估、协调、实现，包括将通过和实现的变更加入到基线中的更改控制过程。 变更控制 变更分为两种类型： 功能变更 和 错误修复变更 功能变更：根据客户的需要增加或删除某些功能，或者修改实现功能的方法所引起的变更 错误修改变更是为了修改漏洞的需要而产生的变更 变更申请 成本 /效益分析 决定是否进行变更 实施变更 审查 检入 配置状态报告 是跟 踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报。 用以跟踪对已建立基线的需求、源代码、数据，以及相关文档的更改。 配置状态记录 编制配置状态报告：软件配置项的状态、变更申请和已批准的变更实现情况 配置状态发布：通知相关管理人员和软件工程师 配置库 收集所有与配置有关的信息，评价系统变更的效果，为配置管理过程提供管理信息 开发库：专供给开发人员使用，内容可由开发人员决定是否修改 受控库：也称为软件配置管理库 产品库：存放最终产品、等待交付用户或现场安装的产品 配置评审 15/87 是验证一个可发布的软件基线是否包含了它应包括的所有内容。 包括功能配置评审和物理配置评审。 功能配置评审：确认软件已通过测试并满足基线规定的需求说明，保证正确性。 物理配置评审：确认将发布的软件包含了所有必需的组成部分（代码、文档、数据）保证完整性 判断变更是否正确完成，需进行正式技术评审和软件配置审核 正式技术评审：检查已完成修改的软件配置对象的技术正确性 软件配置审核：各项产品在技术上和管理上的完整性。 ● 软件开发环境 软件开发环境的结构为层次性结构，分为四层 宿主层 ：包括基本宿主硬件和基本宿主软件 核心层：包括工具组、环境数据库和会话系统 基本层：包括至少一组工具，如编译工具、调试工具等 应用层：以基本层为基础补充某些工具，以适应应用软件的要求。 ● 软件过程管理 软件过程改进 SPI： 帮助软件企业对其软件（制作）过程的改变（进）进行计划、（措施）制定以及实施 的过程，一般从 问题分析 开始。 五条核心原则：注重问题；强调知识创新；鼓励参与；领导层的统一；计划不断地改进。 ● 构件及其在信息系统项目中的重要性 ● 常用构件标准（ COM/DCOM/COM+、 CORBA和 EJB） ● 软件体系结构定义 ● 典型体系结构 ● 软件体系结构设计方法 ● 软件体系结构分析与评估 软件体系结构评估的主要方式：基于调查问卷或检查表的评估方式；基于场景的评估方式；基于度量的评估方式。 ● 软件中间件 ● 面向对象的基本概念 面向对象 =对象 +类 +继承 +消息通信 16/87 面向对象的基本概念有对象、类、抽象、封装、继承、多态、接口、消息、组件、模式和复用等。 对象 是是用来描述客观事物的一个封装，是构成系统的基本单位。 对 象包含三个基本要素，对象 标识 、对象 属性 和对象 服务。 每一个对象必须有一个名字以区别于其他对象，这就是对象标识； 属性 用来描述对象的某些特征 （静态） ； 服务 用来封装对象所拥有的业务操作 （动态）。 类 是 对象的抽象定义，是一组具有相同数据结构和相同操作的对象的集合。 对象是类的实际例子。 封装 是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。 继承 表示类之间的层次关系，这种关系使得某类对象可以继承另外一类对象的特征（ attributes）和能力（ operations），继承又可分为单继承和多继承，单继承是子类只从一个父类继承，而多继承中的子类可以从多于一个的父类继承， Java是单继承的语言，而 C++允许多继承。 假设类 B继承类 A，即类 B中的对象具有类 A的一切特征（包括属性和操作）。 类 A称为基类或父类或超类，类 B称为 类 A的派生类或子类，类 B在类A的基础上还可以有一些 扩展。 如图 32所示， Dog和 Cat类都是从 Mammal继承而来，具有父类的eyeColor属性特征，因此在子类中就下用重复指定 eyeColor这个属性。 17/87 多态 使得一个属性或变量在不同的时期可以表示不同类的 对象。 如图 33所示， Rectangle和 Circle都继承于 Shape，对于 Shape而言，会有 getArea0的操作。 但显而易见， Rectangle和 Circle的 getArea()方法的实现是完全不一样的，这就体现了多态的特征。 接口 就是对操作规范的说明。 接口只是说明操作应该 做什么 ( What)，但没有定义操作如何做 ( How)。 接口可以理解成为类的一个特例，它只规定实现此接口的类的操作方法，而把真正的实现细节交由实现该接口的类去完成。 接口在面向对象分析和设计过程中起到了至关重要的桥梁作用，系统分析员通常先把有待实现的功能封装并定义成接口，而后期程序员依据此接口进行编码实现。 消息 （ Message）是对象间的交互手段，其形式如下： Message: [,para] 其中 dest指目标对象 Destination Object， op指操作 Operation， para指操作需要的参数 Parameters。 ● 统一建模语言 UML UML是一种可视化建模语言。 UML标准并没有定义一种标准的开发过程，但它比较适用于 迭代式 的开发过程，是为支持大部分现存的面向对象开发过程而设计的。 ● 可视化建模 UML提供了如下 9种主要的图来对待建系统进行建模。 1） 用例图 ：用例模型描述的是外部执行者（ Actor）所理解的系统功能。