《系统集成项目管理工程师教程》第三版

做了一些题,总结了一些知识点。

重点知识点

第四章 信息系统架构

  • 任何软件都存在架构,但不一定有对该架构的具体表述文档。
  • 分布式架构的主要特征是:可以根据应用需求来配置资源,提高信息系统对用户需求与外部环境变化的应变能力,系统扩展方便,安全性好,某个节点所出现的故障不会导致整个系统停止运作。然而由于资源分散,且又分属于各个子系统,系统管理的标准不易统一,协调困难,不利于对整个资源的规划与管理。
  • 两层 C/S 结构通俗地说就是人们常说的“胖客户端”模式。在实际的系统设计中,该类结构主要是指前台客户端+后台数据库管理系统。
  • C/S 为浏览器与服务器模式
  • B/S 为客户端与服务器模式
  • 面向服务架构的本质是消息机制或远程过程调用(RPC)。
  • 架构愿景:设置 TOGAF 项目的范围、约束和期望,建立架构愿景,包括定义利益;相关者,确认业务上下文环境,创建架构工作说明书,取得上级批准等。
  • 模型核心的特征可以简化为三种基本形式:价值期望值、反作用力和变革催化剂。
  • 应用架构设计原则有业务适配性原则、应用企业化原则、功能专业化原则、风险最小化原则和资产复用化原则。
  • 数据架构设计原则有数据分层原则、数据处理效率原则、保障数据一致性原则、数据架构可扩展性原则、服务于业务原则。
  • 技术架构:成熟度控制原则;技术一致性原则;局部可替换
    原则;人才技能覆盖原则;创新驱动原则。
  • WPDRRC 模型有个环节和大要素。
    六个环节包括:预警(W)、保护§、检测(D)响应®、恢复®和反击©它们具有较强的时序性和动态性,能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。
    响应其中处理包括了封堵、隔离、报告等能力。主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。
    三大要素包括:人员、策略和技术。人员是核心,策略是桥梁,技术是保证。
  • OSI 开放系统互联安全体系的 5 类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。
  • OSI 定义了 7 层协议,其中除第 5 层(会话层)外,每一层均能提供相应的安全服务.
  • 外部和内部边界同时使用嵌套的防火墙并配合以入侵检测就是分层技术防御的一个实例
  • 静态约束应尽量包含在数据库模式中,而动态约束由应用程序实现
  • 针对数据库系统安全,我们需重点关注(完整性)设计。
  • 应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁,也受到“木马”和“陷阱门”的威胁。
  • 云原生的代码通常包括三部分:业务代码、三方软件、处理非功能特性的代码三部分中只有业务代码是核心

第五章 软件工程

  • 需求是多层次的,包括业务需求、用户需求和系统需求。
    (1)业务需求。业务需求是指反映企业或客户对系统高层次的目标要求。
    (2)用户需求。用户需求描述的是用户的具体目标,或用户要求系统必须能完成的任务。系统需求。
    (3)系统需求是从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束等。
  • 质量功能部署(QFD)是一种将用户要求转化成软件需求的技术,它将软件需求分为三类,分别是常规需求、期望需求和意外需求
  • 需求分析有三个层次的模型,分别是数据模型、功能模型和行为模型。

用实体联系图(E-R 图)表示数据模型; 用数据流图(DFD)表示功能模型; 用状态转换图(STD)表示行为模型。

  • 需求变更控制过程的排序:
    识别问题–>问题分析和变更描述–>变更分析和成本计算–>变
    更实现–>修改后的需求
  • 结构化分析(Structured Analysis, SA)方法给出一组帮助系统分析人员产生功能规约的原理与技术,其建立模型的核心是数据字典。围绕这个核心,有 3 个层次的模型,分别是:

数据模型、功能模型和行为模型(也称为状态模型)。

  • OOA 基本步骤:确定对象和类;确定结构;确定主题;确定
    属性;确定方法。
  • 系统需求是从系统的角度来说明软件的需求,包括功能需求、
    非功能需求和约束等。
  • UML 中主要有依赖关系、泛化关系、关联关系、实现关系等关系。其中,实现关系是类之间的语义关系,一个类指定了由另一个类保证执行的契约。
  • PAD 是一种改进的图形描述方式,可以用来取代程序流程图,
    比程序流程图更直观,结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。
  • 交互图展现了一种交互,它由一组对象或参与者以及它们之
    间可能发送的消息构成。交互图专注于系统的动态视图
  • 逻辑视图:逻辑视图也称为设计视图,它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集
  • 结构化设计(SD)是一种面向数据流的方法,它以 SRS 和 SA阶段所产生的 DFD 和数据字典等文档为基础,是一个自顶向下、逐步求精和模块化的过程。
  • 常用的 OOD 原则包括:
    单职原则:设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
    开闭原则:对扩展开放,对修改封闭。
    里氏替换原则:子类可以替换父类。
    依赖倒置原则:要依赖于抽象,而不是具体实现;要针对接口编程,不要针对实现编程。
    接口隔离原则:使用多个专门的接口比使用单一的总接口要好。
    组合重用原则:要尽量使用组合,而不是继承关系达到重用目的。
    迪米特原则(最少知识法则):一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的。
  • 构件图描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。
  • 确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致
  • 回归测试的目的是测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
  • 软件配置管理的核心内容包括版本控制和变更控制
  • 软件发布管理和交付,创建特定的交付版本,完成此任务的关键是软件库。
  • 程序设计风格包括 4 个方面:源程序文档化、数据说明、语句结构和输入/输出方法。
  • 集成测试的技术依据是软件概要设计文档
  • 在部署原则中提到两大部署方式为蓝绿部署和金丝雀部署。
    (1)蓝绿部署是指在部署的时候准备新旧两个部署版本,通过域名解析切换的方式将用户使用环境切换到新版本中,当出现问题的时候,可以快速地将用户环境切回旧版本,并对新版本进行修复和调整。
    (2)金丝雀部署是指当有新版本发布的时候,先让少量用户使用新版本,并且观察新版本是否存在问题。如果出现问题,就及时处理并重新发布;如果一切正常,就稳步地将新版本适配给所有的用户。
  • 组织管理:包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域,对软件组织能力进行综合管理。
  • 第 2 级项目规范级特征:项目依据选择和定义管理规范,执行软件开发和管理的基础过程;组织按照一定的规范,为项目活动提供支持保障工作。

第六章 数据工程

  • 一般来说,数据预处理主要包括数据分析、数据检测和数据修正 3 个步骤
  • 数据挖掘流程一般包括确定分析对象、数据准备、数据挖掘、结果评估与结果应用 5 个阶段。
    数据挖掘常见的主要任务包括数据总结、关联分析、分类和预测、聚类分析和孤立点分析。
  • 数据服务主要包括数据目录服务、数据查询与浏览及下载服务、数据分发服务。
  • 数据集成就是将驻留在不同数据源中的数据进行整合,向用户提供统一的数据视图,使得用户能以透明的方式访问数据。
  • 存储介质的类型主要有磁带、光盘、磁盘、内存、闪存、云存储等
  • 资源调度管理的功能主要是添加或删除存储节点,编辑存储节点的信息,设定某类型存储资源属于某个节点,或者设定这些资源比较均衡地存储到节点上。它包含存储控制、拓扑配置以及各种网络设备如集线器、交换机、路由器和网桥等的故障隔离。
  • 从技术上看,衡量容灾系统有两个主要指标,即 RPO(恢复点目标)和RTO(复时间目标),其中 RPO 表示了当灾难发生时允许丢失的数据量,而RTO 则代表了系统恢复的时间。
  • 当前最常见的数据备份结构可以分为四种:DAS 备份结构、基于 LAN 的备份结构、LAN-FREE 备份结构和 SERVER-FREE 备份结构。DAS 备份结构将备份设备(RAID 或磁带库)直接连接到备份服务器上。
  • 常见的备份策略主要有三种:完全备份、差分备份和增量备份。
  • 根据容灾系统保护对象的不同,容灾系统分为应用容灾和数据容灾两类。数据备份是数据容灾的基础。容灾不是简单备份。
  • 客观存在的并可以相互区分的事物称为实例,而同一类型实
    例的抽象称为实体
    ,如学生实体(学号、系名、住处、课程、成绩)、教师实体(工作证号、姓名、系名、教研室、职称)。实体是同一类型实例的共同抽象,不再与某个具体的实例对应。相比较而言,实例是具体的,而实体则是抽象的。
  • 逻辑模型是在概念模型的基础上确定模型的数据结构,目前主要的数据结构有层次模型、网状模型、关系模型、面向对象模型和对象关系模型。其中,关系模型成为目前最重要的一种逻辑数据模型
    根据模型 应用的目的不同 ,可以将数据模型划分为 3 类:概念模型、逻辑模型和物理模型。
    概念模型的基本元素:实体、属性、域、键、关联。
    真正实现在数据库存放的是物理模型。物理模型考虑的主要问题包括命名、确定字段类型和编写必要的存储过程与触发器等。
  • 数据标准化具体过程包括四个阶段:
    (1)确定数据需求:将产生数据需求及相关的元数据、域值等文件。
    (2)制定数据标准:要处理“确定数据需求"阶段提出的数据需求。如果现有的数据标准不能满足该数据需求,可以建议制定新的数据标准,也可建议修改或者封存已有数据标准。
    (3)批准数据标准:数据管理机构对提交的数据标准建议、现行数据标准的修改或封存建议进行审查一经批准,该数据标准将扩充或修改数据模型。
    (4)实施数据标准:在各信息系统中实施和改进已批准的数据标准。
  • 元数据:是关于数据的数据
  • 数据质量评价过程:
    数据质量评价过程:
  • WSDL 一种基于 XML 格式的关于 Web 服务的描述语言。
  • 二维数据可视化就是地理信息系统(GIS)。
  • SOAP 为消息传递的协议:规定了 Web Services 间传递信息的方式。
  • 把数据密级划分为 5 个等级,分别是 L1(公开)、L2(保密)、L3(机密)、L4(绝密)和L5(私密)。
  • 数据脱敏原则主要包括算法不可逆原则、保持数据特征原则、保留引用完整性原则、规避融合风险原则、脱敏过程自动化原则和脱敏结果可重复原则等。

第七章 软硬件系统集成

第八章 信息安全工程

系统集成考前必背

1、信息系统安全的属性包括保密性、完整性、可用性和不可抵赖性。
(1)保密性是应用系统的信息不被泄露给非授权的用户、实体或过程,或供其利用的特性。
(2)完整性是信息未经授权不能进行改变的特性。
(3)可用性是应用系统信息可被授权实体访问并按需求使用的特性。
(4)不可抵赖性也称作不可否认性,在应用系统的信息交互过程中,确信参与者的真实同一性。
2、数据库与数据仓库两者的区别主要有:
(1)数据库是面向事务的设计;数据仓库是面向主题设计的。
(2)数据库一般存储的是在线交易数据,数据仓库存储的一般是历史数据。
(3)数据库设计是尽量避免冗余,一般采用符合范式的规则来设计;数据仓库在设计时有意引入冗余,采用反范式的方式来设计。
(4)数据库是为捕获数据而设计,数据仓库是为分析数据而设计。出于决策的需要,数据仓库中的数据都要标明时间属性。
(5)数据库的操作者是一般的企业技术人员,而数据仓库的使用者一般是企业的领导层或决策层。
3、区块链(Block chain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。
区块链目前分为三类,其中混合区块链和私有区块链可以认为是广义的私链。
区块链的基本特点:去中心化;开放性;自治性;信息不可篡改;匿名性。
4、电子商务是在Internet开放的网络环境下,基于浏览器/服务器应用方式,实现消费者的网上购物,商户之间的网上交易和在线电子支付的一种新型的商业运营模式。
Internet上的电子商务可以分为三个方面:信息服务、交易和支付。
参与电子商务的实体有四类,分别是顾客(个人消费者或企业集团)、商户(包括销售商、制造商、储运商)、银行(包括发卡行、收单行)和认证中心。
5、商业智能系统应具有的主要功能:数据仓库、数据ETL、数据统计输出(报表)、分析功能OLAP。
商业智能的实现有三个层次:数据报表、多维数据分析和数据挖掘。
商业智能项目的实施步骤可分为如下6步:
(1)需求分析
(2)数据仓库建模
(3)数据抽取
(4)建立商业智能分析报表
(5)用户培训和数据模拟测试
(6)系统改进和完善
6、软件质量管理过程由许多活动组成,一些活动可以直接发现缺陷,另一些活动则检查活动的价值。其中包括质量保证过程、验证过程、确认过程、评审过程、审计过程等。
(1)软件质量保证:通过制订计划、实施和完成等活动保证项目生命周期中的软件产品和过程符合其规定的要求。
(2)验证与确认:确定某一活动的产品是否符合活动的需求,最终的软件产品是否达到其意图并满足用户需求。
验证过程试图确保活动的输出产品已经被正确构造,即活动的输出产品满足活动的规范说明;确认过程则试图确保构造了正确的产品,即产品满足其特定的目的。
(3)评审与审计:包括管理评审、技术评审、检查、走查、审计等。
管理评审的目的是监控进展,决定计划和进度的状态,或评价用于达到目标所用管理方法的有效性。技术评审的目的是评价软件产品,以确定其对使用意图的适合性。
软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动,识别违例情况,并要生成审计报告,采取更正性行动。
7、各种软件开发模型的特点比较。
模型名称 技术特点 适用范围
瀑布模型 简单,分阶段,阶段间存在因果关系,各个阶段完成后都有评审,允许反馈,不支持用户参与,要求预先确定需求 需求易于完善定义且不易变更的软件系统
迭代模型 不要求一次性地开发出完整的软件系统,将软件开发视为一个逐步获取用户需求、完善软件产品的过程 需求难以确定、不断变更的软件系统
螺旋模型 结合瀑布模型、迭代模型的思想,并引进了风险分析活动 需求难以获取和确定、软件开发风险较大的软件系统
敏捷方法 拥抱变化;较少的文档,简单设计;持续集成,小步快走 小型项目、小型团队,需求快速变化
原型化模型 在原型上沟通更直观 适合需求分析
8、TCP协议与UDP协议的主要区别
(1)TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。
(2)TCP提供IP环境下的数据可靠传输,它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。
(3)UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说,TCP对应的是可靠性要求高的应用,而UDP对应的则是可靠性要求低、传输经济的应用。
(4)TCP支持的应用协议主要有:Telnet、FTP、SMTP等。
(5)UDP支持的应用层协议主要有:NFS(网络文件系统)、SNMP(简单网络管理协议)、DNS(主域名称系统)、TFTP(通用文件传输协议)等。
9、基于风险方法来进行审计的步骤
(1)编制组织使用的信息系统清单并对其进行分类。
(2)决定哪些系统影响关键功能和资产。
(3)评估哪些风险影响这些系统及对商业运作的冲击。
(4)在上述评估的基础上对系统分级,决定审计优先值、资源、进度和频率。审计者可以制定年度审计计划,开列出一年之中要进行的审计项目。
10、信息系统的生命周期可以分为立项、开发、运维及消亡四个阶段
(1)立项阶段:即概念阶段或需求阶段,这一阶段根据用户业务发展和经营管理的需要,提出建设信息系统的初步构想;然后对企业信息系统的需求进行深入调研和分析,形成《需求规格说明书》并确定立项。
(2)开发阶段:以立项阶段所做的需求分析为基础,进行总体规划。之后,通过系统分析、系统设计、系统实施、系统验收等工作实现并交付系统。
(3)运维阶段:信息系统通过验收,正式移交给用户以后,进入运维阶段。要保障系统正常运行,系统维护是一项必要的工作。系统的运行维护可分为更正性维护、适应性维护、完善性维护、预防性维护等类型。
(4)消亡阶段:信息系统不可避免地会遇到系统更新改造、功能扩展,甚至废弃重建等情况。对此,在信息系统建设的初期就应该注意系统消亡条件和时机,以及由此而花费的成本。
11、项目目标包括成果性目标和约束性目标。项目的约束性目标也叫管理性目标,项目的成果性目标有时也简称为项目目标。项目成果性目标指通过项目开发出的满足客户要求的产品、系统、服务或成果;项目约束性目标是指完成项目成果性目标需要的时间、成本以及要求满足的质量。例如要在一年的期间内完成一个ERP项目,同时还要满足验收标准(质量要求)。
12、运营与项目
(1)运营是持续不断和重复进行的,项目是临时性的、独特的。
(2)项目的目标是实现其目标(约束性目标和成果性目标),然后结束项目。运营的目标一般是为了维持业务的经营。
(3)项目具有逐步完善的特点,不可能一开始就明确全部细节。运营遵循标准化的流程开展工作,一开始就能够明确工作的全部细节。
(4)项目目标实现时,项目也就结束了。运营目标实现时,会不断地用新目标取代旧目标。
13、职能型、矩阵型、项目型组织结构辨别
(1)项目经理的权力大小不同。项目经理权力由小到大排序:职能型、弱矩阵、平衡矩阵、强矩阵、项目型。平衡矩阵组织以下往往将“项目经理”称为项目协调员(往往是兼职);从平衡矩阵组织开始,项目有了专职的项目经理;强矩阵型组织开始,项目经理(们)有了自己的项目部门,项目经理有了自己的经理;项目型组织则没有职能部门。
(2)组织中全职参与项目工作的职员比例不同。职能型组织:没有、弱矩阵型组织:0-25%、平衡矩阵型组织:15%-60%、强矩阵型组织:50%-95%、项目型组织:85%-100%。
(3)组织结构图不同,详情见《系统集成项目管理工程师》(第2版)P194。
14、作为整合者,项目经理必须
(1)通过与项目干系人主动、全面的沟通,来了解他们对项目的需求。
(2)在相互竞争的众多干系人之间寻找平衡点。
(3)通过认真、细致的协调工作,来达到各种需求间的平衡,实现整合。
15、项目管理过程组
(1)启动过程组:定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段。
(2)规划过程组:明确项目范围,优化目标,为实现目标制定行动方案。
(3)执行过程组:完成项目管理计划中确定的工作,以满足项目要求。
(4)监控过程组:跟踪、审查和调整项目进展与绩效,识别必要计划变更并启动相应变更。
(5)收尾过程组:正式完成或结束项目、阶段或合同。
16、项目经理与PMO的作用区别
项目经理是负责实现具体项目目标的个人,对具体项目的成功负责。PMO是组织中一个常设的职能部门,负责提升整个公司的项目管理水平,并对组织中项目经理提供项目管理相关的技术和培训。
17、项目可行性研究内容
(1)投资必要性,主要根据市场调查及预测的结果,以及有关的产业政策等因素,论证项目投资建设的必要性。
(2)技术可行性,主要从项目实施的技术角度,合理设计技术方案,并进行比较、选择和评价。
(3)财务可行性,主要从项目及投资者的角度,设计合理财务方案,从企业理财的角度进行资本预算,评价项目的财务盈利能力,进行投资决策,并从融资主体(企业)的角度评价股东投资收益、现金流量计划及债务偿还能力。
(4)组织可行性,制定合理的项目实施进度计划、设计合理的组织机构、选择经验丰富的管理人员、建立良好的协作关系、制定合适的培训计划等,保证项目顺利执行。
(5)经济可行性,主要是从资源配置的角度衡量项目的价值,评价项目在实现区域经济发展目标、有效配置经济资源、增加供应、创造就业、改善环境、提高人民生活等方面的效益。
(6)社会可行性,主要分析项目对社会的影响,包括政治体制、方针政策、经济结构、法律道德、宗教民族、妇女儿童及社会稳定性等。
(7)风险因素及对策,主要对项目的市场风险、技术风险、财务风险、组织风险、法律风险、经济及社会风险等因素进行评价,制定规避风险的对策,为项目全过程的风险管理提供依据。
18、项目章程的作用
(1)确定项目经理,规定项目经理的权力。
(2)正式确认项目的存在,给项目一个合法的地位。
(3)规定项目的总体目标,包括范围、时间、成本和质量等。
(4)通过叙述启动项目的理由,把项目与执行组织的日常经营运作及战略计划等联系起来。
19、项目管理计划的主要内容
(1)管理子计划(9):范围、进度、成本、质量、人力资源、干系人、沟通、风险、采购管理计划。
(2)其他管理计划(4):质量改进计划;配置、变更、需求管理计划。
(3)重要基准(3):范围基准、进度基准、成本基准。
(4)为项目选用生命周期和过程(2):项目所选用的生命周期及各阶段将采用的过程、生命周期模型。
20、项目管理计划的主要用途
(1)指导项目执行、监控和收尾。
(2)为项目绩效考核和项目控制提供基准。
(3)记录制订项目计划所依据的假设条件。
(4)记录制订项目计划过程中的有关方案选择。
(5)促进项目干系人之间的沟通。
(6)规定管理层审查项目的时间、内容和方式。
21、变更请求可能包括
(1)纠正措施。为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
(2)预防措施。为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
(3)缺陷补救。为了修正不一致的产品或产品组件而进行的有目的的活动。
(4)更新。对正式受控的项目文件或计划等进行变更,以反映修改或增加的意见或内容。
22、整体变更控制的程序或流程
(1)提出和接受变更申请
(2)对变更的初审
(3)变更方案论证
(4)项目变更控制委员会审查
(5)发出变更通知并开始实施
(6)变更实施的监控
(7)变更效果的评估
(8)判断发生变更后的项目是否已纳入正常轨道
23、项目收尾包括合同收尾与行政收尾,合同收尾与行政收尾的区别
(1)主要是指收集项目记录、分析经验教训,收集、整理、分发和归档各种项目文件,以便正式确认项目产品合格性等,同时伴随组织过程资产的更新和人力及非人力资源的释放。每个项目阶段完成时,都要及时整理项目信息和经验教训,从而防止项目信息丢失。
(2)合同收尾针对外包形式的项目,通常在行政收尾之前进行,一个合同只需要一次合同收尾,是由项目经理向卖方签发的合同结束的书面确认。
(3)合同收尾和行政收尾相比的关键差别在于,前者还包括产品核实。
24、监控项目工作的输入、输出、工具与技术
(1)输入:项目管理计划、进度预测、成本预测、确认的变更、工作绩效信息、事业环境因素和组织过程资产。
(2)输出:变更请求、工作绩效报告、项目管理计划更新、项目文件更新。
(3)工具与技术:分析技术、项目管理信息系统和会议。
25、实施整体变更的输入、输出、工具与技术
(1)输入:项目管理计划、变更请求、工作绩效报告、事业环境因素、组织过程资产。
(2)输出:批准的变更请求、变更日志、项目管理计划更新、项目文件更新。
(3)工具与技术:会议、变更控制工具。
26、编制范围管理计划的输出
(1)范围管理计划:范围管理计划是项目或项目集管理计划的组成部分,描述了如何定义、制定、监督、控制和确认项目范围。根据项目需要,范围管理计划可以是正式或非正式的,非常详细或高度概括的。
(2)需求管理计划:需求管理计划是项目管理计划的组成部分,描述了如何分析、记录和管理需求,以及阶段与阶段间的关系对管理需求的影响。
27、详细的范围说明书或引用的文档
(1)项目目标:包括衡量项目成功的可量化标准。
(2)产品范围描述:产品范围描述了项目承诺交付的产品、服务或结果的特征。
(3)项目需求:描述了项目承诺交付物要满足合同、标准、规范或其他强制性文档所必须具备的条件或能力。
(4)项目边界:严格地定义了项目内包括什么和不包括什么,以防有的项目干系人假定某些产品或服务是项目中的一部分。
(5)项目的可交付成果:在某一过程、阶段或项目完成时,产出的任何独特并可核实的产品、成果或服务。
(6)项目的制约因素:指具体的与项目范围有关的约束条件,它会对项目团队的选择造成限制。
28、WBS分解步骤
(1)识别和分析可交付成果及相关工作。
(2)确定WBS的结构和编排方法。
(3)自上而下逐层细化分解。
(4)为WBS组件制定和分配标识编码。
(5)核实可交付成果分解的程度是否恰当。
29、范围控制的输入、输出、工具与技术
(1)输入:项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产。
(2)输出:工作绩效信息、变更请求、项目管理计划更新、项目文件更新、组织过程资产更新。
(3)工具与技术:偏差分析。
30、活动之间的四种依赖关系
(1)强制性依赖关系:是法律或合同要求的或工作的内在性质决定的依赖关系。
(2)选择性依赖关系:它通常是基于具体应用领域的最佳实践或者是基于项目的某些特殊性质而设定,即便还有其他顺序可以选用,但项目团队仍缺省按照此种特殊的顺序安排活动。如果打算进行快速跟进,则应当审查相应的选择性依赖关系,并考虑是否需要调整或去除。
(3)外部依赖关系:是项目活动与非项目活动之间的依赖关系。
(4)内部依赖关系:是项目活动之间的紧前关系,通常在项目团队的控制之中。
31、总时差与自由时差的区别
(1)总时差是在不延误项目工期的前提下,某活动的可自由利用的机动时间。
(2)自由时差影响的是紧后活动的最早开工时间(ES)。
(3)计算公式:总时差=最迟-最早;自由时差=紧后活动的最早开工时间(ES)的最小值-本活动的最早完工时间。
32、挣值分析计算:
(1)SPI进度绩效指数:SPI=EV/PV,SPI<1,则表示进度落后;SPI>1,则表示进度提前
(2)CPI成本绩效指数:CPI=EV/AC,CPI<1,则表示成本超出;CPI>1,则表示成本节约
(3)ETC剩余工作成本:非典型偏差(进行调整)ETC=BAC-EV,典型偏差(不进行调整)ETC=(BAC-EV)/CPI
(4)EAC完工估算:EAC=AC+ETC,非典型偏差EAC=AC+BAC-EV,典型偏差EAC=BAC/CPI
33、成本失控原因
(1)对工程项目认识不足
(2)组织制度不健全
(3)方法问题
(4)技术的制约
(5)需求管理不当
34、应急储备与管理储备
(1)应急储备应对已知的未知风险,项目经理有权直接使用,是成本基准的一部分;
(2)管理储备应对未知的未知风险,项目经理无权直接使用,必须经管理层批准后使用,不是成本基准的一部分。
35、质量成本

36、典型的QA的职责包括:过程指导、过程评审、产品审计、过程改进、过程度量。
(1)导师的角色:在项目前期,QA辅助项目经理制定项目计划,包括根据质量体系中的标准过程裁剪得到的项目过程,帮助项目进行估算,设定质量目标等;对项目成员进行过程和规范的培训以及在过程中进行指导等。
(2)警察的角色:在项目过程中,QA有选择性地参加项目的技术评审,定期对项目的工作产品和过程进行审计和评审。
(3)医生的角色:在项目过程中,QA也可以承担收集、统计、分析度量数据的工作,用于支持管理决策。
37、规划质量管理过程的输入、输出、工具和技术
(1)输入:项目管理计划、干系人登记册、风险登记册、需求文件、事业环境因素、组织过程资产。
(2)输出:质量管理计划、过程改进计划、质量测量指标、质量核对单、项目文件更新。
(3)工具和技术:成本效益分析法、质量成本法、标杆对照、实验设计、其他质量管理工具。
38、质量控制的老七工具和新七工具
(1)老七工具:流程图、因果图、直方图、散点图、帕累托图、控制图、核查表。
(2)新七工具:亲和图、过程决策程序图、关联图、树形图、优先矩阵图、活动网络图、矩阵图。
39、冲突的解决方法
(1)问题解决:冲突各方一起积极地定义问题、收集问题的信息、制定解决方案,最后直到选择一个最合适的方案来解决冲突,此时为双赢或多赢。这是冲突管理中最理想的一种方法。
(2)合作:集合多方的观点和意见,得出一个多数人接受和承诺的冲突解决方案 。
(3)强制:以牺牲其他各方的观点为代价,强制采纳一方的观点,一般只适用于赢-输这样的零和游戏情景里。
(4)妥协:冲突的各方协商并且寻找一种能够使 冲突各方都有一定程度满意、但冲突各方没有任何一方完全满意、是一种都做一些让步的冲突解决方法。
(5)求同存异:冲突各方都关注他们一致的一面,而淡化不一致的一面,一般求同存异要求保持一种友好的气氛,但是回避了解决冲突的根源,也就是让大家都冷静下来,先把工作做完。
(6)撤退:把眼前的或潜在的冲突搁置起来,从冲突中撤退。
40、冲突的下列特点
(1)冲突是自然的,而且要找出一个解决办法。
(2)冲突是一个团队问题,而不是某人的个人问题。
(3)应公开地处理冲突。
(4)冲突的解决应聚焦在问题,而不是人身攻击。
(5)冲突的解决应聚焦在现在,而不是过去。
41、激励理论
(1)马斯洛的需求层次理论(生理需求、安全需求、社会交往的需求、受尊重的需求、自我实现的需求)。
(2)赫茨伯格的双因素理论(保健因素、激励因素)。
(3)麦格雷戈的X理论和Y理论(X理论-人天性好逸恶老;Y理论-人天性热爱工作)。
(4)弗鲁姆的期望理论(激发力量=目标效价×期望值)。
42、团队发展的五个阶段:形成阶段、震荡阶段、规范阶段、发挥阶段、结束阶段。
43、项目人力资源管理的基本过程
(1)规划沟通管理:根据干系人的信息需要和要求及组织的可用资产情况,制定合适的项目沟通方式和计划的过程。
(2)管理沟通:根据沟通管理计划,生成、收集、分发、储存、检索及最终处置项目信息的过程。
(3)控制沟通:在整个项目生命周期中对沟通进行监督和控制的过程,以确保满足项目干系人对信息的需求。
44、沟通方法
(1)交互式沟通。在两方或多方之间进行多向信息交换。这是确保全体参与者对特定话题达成共识的最有效的方法,包括会议、电话、即时通信、视频会议等。
(2)推式沟通。把信息发送给需要接收这些信息的特定接收方。这种方法可以确保信息的发送,但不能确保信息送达受众或被目标受众理解。推式沟通包括信件、备忘录、报告、电子邮件、传真、语音邮件、日志、新闻稿等。
(3)拉式沟通。用于信息量很大或受众很多的情况。要求接收者自主自行地访问信息内容。这种方法包括企业内网、电子在线课程、经验教训数据库、知识库等。
45、风险具有下列性质
(1)客观性
风险是一种不以人的意志为转移,独立于人的意识之外的客观存在。因为无论是自然界的物质运动,还是社会发展的规律,都由事物的内部因素所决定。由超过人们主观意识所存在的客观规律所决定。
(2)偶然性
由于信息的不对称,未来风险事件发生与否难以预测。
(3)相对性
风险性质会因时空各种因素变化而有所变化。
(4)社会性
风险的后果与人类社会的相关性决定了风险的社会性,具有很大的社会影响力。
(5)不确定性
发生时间的不确定性。从总体上看,有些风险是必然要发生的,但何时发生却是不确定的。例如,生命风险中,死亡是必然发生的,这是人生的必然现象,但是具体到某一个人何时死亡,在其健康时却是不能确定的。
46、项目合同签订的注意事项
(1)当事人的法律资格
(2)质量验收标准
(3)验收时间
(4)技术支持服务
(5)损害赔偿
(6)保密约定
(7)合同附件
(8)法律公证
47、以下情况可采用竞争性谈判方式
(1)招标后没有供应商投标或没有合格标的或者重新招标未能成立的;
(2)技术复杂或者性质特殊,不能确定详细规格或者具体要求的;
(3)采用招标所需的时间不能满足用户紧急需要的;
(4)不能事先计算出价格总额的。
48、配置项状态,可分为“草稿”“正式”和“修改”三种,分别对应的版本号0.YZ、X.Y、X.YZ。当配置项修改完毕并重新通过评审时,其状态又变为“正式”。
49、配置标识(Configuration Identification)也称配置识别,包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。配置标识是配置管理员的职能,基本步骤如下:
(1)识别需要受控的配置项;
(2)为每个配置项指定唯一性的标识号;
(3)定义每个配置项的重要特征;
(4)确定每个配置项的所有者及其责任;
(5)确定配置项进入配置管理的时间和条件;
(6)建立和控制基线;
(7)维护文档和组件的修订与产品版本之间的关系。
50、配置审计
(1)功能配置审计。功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致)。
(2)物理配置审计。物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值