92 Star 580 Fork 382

hyzsbook / 软考资料

加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
克隆/下载
index.md 128.05 KB
一键复制 编辑 原始数据 按行查看 历史
软考资料 提交于 2019-04-14 18:59 . 更新文档目录

一. 信息与信息化

  1. 信息就是能够用来消除不确定性的东西,既不是物质,也不是能量
  2. 信息传输模型:信源→编码→信道(噪声)→解码→信宿
  3. 信息系统特点:①目的性;②可嵌套性;③稳定性;④开放性;⑤脆弱性;⑥健壮性。
  4. 信息化从“小”到“大”5 个层次:①产品信息化;②企业信息化;③产业信息化;④ 国民经济信息化;⑤社会生活信息化。
  5. “两网. 一站. 四库. 十二金”。两网:政务内网和政务外网。一站:政府门户网站。四 库:建立人口. 法人单位. 空间地理和自然资源. 宏观经济等四个基础数据库。十二金:分 3 类,第一类办公资源系统. 宏观经济管理系统(金宏);第二类金税. 金关. 金财. 金卡. 金审5个业务系统;第三类金盾. 金保. 金农. 金水. 金质5个业务系统。
  6. 移动互联网三层:移动终端. 接入网络. 应用服务。
  7. 电子政务的模式,重点G2G. G2B. G2C. G2E,注意和电子商务的区分。
  8. ERP功能: 1. 财会管理 2. 生产控制管理 3. 物流管理 4. 人力资源管理,还要注 意其子功能。 ERP 特点: 1. 是统一的集成系统 2. 是面向业务流程的系统 3. 是模块化可配置的 4. 是开放的系统。注意其是管理的变革,不是技术的变革 财务软件强调事后核算,而ERP软件强调事前计划和及时调整
  9. CRM 坚持以客户为中心,提高客户满意度. 增加客户的忠诚度. 以达到企业的最大利润, 在进行CRM的时候会进行企业业务流程的重组。CRM通过将人为资源. 业务流程与专业技术 进行有效的整合,最终为企业涉及到的各个领域提供了集成环境。
  10. 客户关系管理系统(CRM)包括的基本功能模块有自动化的销售. 客户服务和市场营销。
  11. 数据仓库是一个面向主题的. 集成的. 相对稳定的. 反映历史变化的数据集合,用于支

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训持决策分析,数据仓库的结构也可以看看。 12. 电子商务的概念,分类。关于电子商务的知识也尽量多掌握一些

  1. B2C 2. B2B 3. C2C 4. G2B(大家注意下,这里的G2B 是电子商务,是企业 卖东西给政府,注意下B2A)
  2. 商业智能(BI): 将组织中现有的数据转化为知识,帮助组织做出明智的业务经营决策 应具有的主要功能:数据仓库. 数据ETL. 数据统计输出(报表). 分析功能。强调决策。
  3. 国家信息化体系包括信息技术应用. 信息资源. 信息网络. 信息技术和产业. 信息化人 才. 信息化法规政策和标准规范6 个要素:上鹰(应用)下鸡(技术)左人右龟(规范)
  4. O2O-线上线下,优步打车是O2O模式
  5. 企业信息化结构:产品(服务层). 作业层. 管理层. 决策层,会判断谁是什么层
  6. 供应链管理:衡量供应链管理绩效最重要的指标是客户满意度。降低供应链的成本. 提 高供应链的响应速度等,都要以满足客户需求为前提。
  7. ERP. CRM. 和 SCM 有何关系。答案: ERP 包括 CRM 和 SCM,可以代替后再两者。
  8. 大数据5V特点:Volume(大量). Velocity(高速). Variety(多样). Value(价值). Veracity(真实性)。
  9. 大数据需经过5个环节:①数据准备;②存储管理;③计算处理;④数据分析;⑤知识 展现。
  10. 云计算服务类型:①IaaS(基础设施即服务);②Paas(平台即服务);③SaaS(软件即 服务)。
  11. 云计算技术架构4层:设施层. 资源层. 资源控制层. 服务层。
  12. 到2025 年,网络化. 智能化. 服务化. 协同化的“互联网+”产业生态体系基本完成, “互联网+”新经济形态初步形成,“互联网+”成为经济社会创新发展的重要驱动力量。
  13. 智慧城市5层模型和3 个体系:物联感知层. 网络通信层. 计算与存储层. 数据及服务 支撑层. 智慧应用层。标准规范体系. 安全保障体系. 运营管理体系。

二. IT 服务管理

  1. 系统集成资质。资质仍实行评审与审批相分离的制度,但目前所有资质认证中,涉及工 信部审批的部分,均改为:中国电子信息行业联合会。注意各等级条件---看最新的。
  2. 监理活动的主要内容被概括为“四控三管一协调”。会做判断选项具体的是什么?
  3. 总监理工程师不得将下列工作委托总监理工程师代表:
    1. 主持编写工程监理规划,审批工程监理细则;
    2. 协调建设单位和承建单位的合同争议,参与索赔的处理,审批工程延期;
    3. 根据工程项目的进展情况进行监理人员的调配,调换不称职的监理人员;
    4. 审核签认承建单位的付款申请. 付款证书和竣工结算。
  4. 监理大纲是在建设单位选择合适的监理单位时,监理单位为了获得监理任务,在项目监 理招标阶段编制的项目监理单位方案性文件。监理大纲的作用,是为监理单位的经营目标服 务的,起着承接监理任务的作用。
  5. 监理规划是在监理委托合同签订后,由监理单位制定的指导监理工作开展的纲领性文件。 它起着指导监理单位规划自身的业务工作,并协调与建设单位在开展监理活动中的统一认识. 统一步调. 统一行动的作用。监理规划在内容和深度等方面比监理委托合同更加具体化,更 加具有指导监理工作的实际价值。
  6. 监理实施细则是在监理规划指导下,监理项目部已建立,各项专业监理工作责任制已经 落实,配备的专业监理工程师已经上岗,再由专业监理工程师根据专业项目特点及本专业技 术要求所编制的. 具有实施性和可操作性的业务性文件。监理实施细则由各专业监理工程师

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训负责主持编制,并报送项目总监理工程师认可批准执行。 7. 信息系统工程监理实行总监理工程师负责制 8. 旁站监理. 隐蔽工程。 9. 监理方的依据是法律法规. 标准规范. 建设合同. 监理合同。监理方不会帮助承建方编 写技术文件。也不需要帮助建设方写什么文件。 10. 总监理工程师参与编制监理大纲有利于监理规划的编制 11. 中国特色信息系统集成及服务管理体系:①信息系统集成. 运维服务和信息系统监理资 质管理;②信息系统集成. 运维服务和信息系统监理相关人员管理;③国家计划(投资)部 门对规范的. 具备信息系统项目管理能力的企业和人员的建议性要求;④信息系统用户对规 范的. 具备信息系统项目管理能力的企业和人员市场性需求。 12. ITIL(Information Technology Infrastructure Library,信息技术基础架构库)。以 流程为向导. 以客户为中心。 13. ITSS(Information Technology Service Standard,信息技术服务标准)组织要素: 人员(People). 流程(Process). 技术(Technology). 资源(Resource),简称PPTR。 14. IT 服务生命周期5阶段:规划设计(Planning & Design). 部署实施(Implementing). 服务运营(Operation). 持续改进(Improvement). 监督管理(Supervision)。(PIOIS)

三 . 系统集成知识

  1. 信息系统的生命周期可以分为4 个阶段:立项(规划). 开发. 运维. 消亡。其中开发阶 段又分为5个阶段:总体规划阶段. 系统分析阶段. 系统设计阶段. 系统实施阶段. 系统验 收阶段。大家不仅仅要记住这4个,还要理解意思,要知道每个阶段有什么产品(输出)。
  2. 常用的开发方法有:结构化方法. 原型法. 面向对象方法。非常重要。各方法可以综合 使用。 结构化方法用于在项目前期就能清楚的知道用户的需求;结构化方法具有如下特点:
    1. 遵循用户至上原则。
    2. 严格区分工作阶段,每个阶段有明确的任务和取得的成果。
    3. 强调系统开发过程的整体性和全局性。
    4. 系统开发过程工程化,文档资料标准化。 原型法用于在项目前期不能清楚的知道用户的需求。其中原型法分为:抛弃型原型和演化型 原型。原型应当具备的特点如下: 1. 实际可行 2. 具有最终系统的基本特征 3. 构造方 便. 快速,造价低
  3. 需求分析的目的有: 1. 检测和解决需求之间的冲突; 2. 发现软件的边界,以及软件 及其环境如何交互; 3. 详细描述系统需求,以导出软件需求
  4. 项目组为保证系统的设计满足需求规格说明书而实施的过程叫做需求验证。
  5. 软件需求包含功能需求. 非功能需求. 设计约束三方面内容。而且要根据选项会判断, 另外,可验证性是需求的最基本特征。 业务需求表示组织或客户高层次的目标。业务需求描述了组织为什么要开发一个系统, 即组织希望达到的目标。 用户需求描述的是用户的目标,或用户要求系统必须能完成的任务。 系统需求用于描述包含多个子系统的产品(即系统)的顶级需求。
  6. 常用的测试方法有黑盒测试和白盒测试。程序员应避免检查自己的程序;在设计测试用 例时,应包括合理的输入条件和不合理的输入条件 黑盒测试:不考虑程序的内部结构,主要是在程序的接口上进行测试,测试方法有:(1 ). 等价类划分 2. . 边界值分析 3. . 错误推测法 4. . 因果图

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 白盒测试:把测试对象看做一个透明的盒子,对程序所有逻辑路径进行测试。具有代表 的逻辑覆盖包含: 1. 语句覆盖 2. 判断覆盖 3. 条件覆盖 4. 判定----条件覆盖 5. 条件组合覆盖 6. 路径覆盖 大家看到有覆盖就肯定是白盒测试。 软件测试中的静态分析主要包含控制流分析. 数据流分析. 接口分析和表达式分析等。 α测试:是在开发环境进行的测试; β测试:是用户在实际环境中进行的测试,开发 者不在旁边。 7. 在软件测试阶段,如果某个测试人员认为程序出现错误,他应首先要对错误结果进行确 认,然后再开展后续的工作 8. 软件维护----软件正式交付用户以后,即进入漫长的维护期。软件的维护从性质上分为: 纠错型维护. 适应型维护. 预防型和完善型维护。都是软件交付之后进行的。 9. 管理评审的目的是监控进展,决定计划和进度的状态,确认需求及其系统分配,或评价 用于达到目标适应性的管理方法的有效性。它们支持有关软件项目期间需求的变更和其他变 更活动。是评价管理方面。 10. 技术评审的目的是评价软件产品。以确定其对使用意图的适合性,目标是识别规范说明 和标准的差异,并向管理提供证据,以表明产品是否满足规范说明并遵从标准,而且可以控 制变更。是评价技术方面。 11. 质量保证是指为使软件产品规定需求所进行的一系列有计划的必要工作。 12. 审计是为评估XX 的独立的检查 13. 软件工程管理包含过程管理和项目管理,包括6 个方面:启动和范围定义. 软件项目计 划. 软件项目实施. 评审和评价. 关闭. 软件工程度量。 14. 统一建模语言UML---是一种语言;是一种可视化语言;是一种可用于详细描述的语言; 是一种构造语言;是一种文档化语言。不是过程,也不是方法,但允许任何一种过程和方法 使用它。简单并且可扩展,具有扩展和专有化机制,便于扩展,无需对核心概念进行修改。 比较适合于迭代式的开发。 - RUP 是迭代式方法) 图的名字 介绍 类图 描述一些类. 包的静态结构和它们之间的静态关系 对象图 给出一个系统中的对象的快照 构件图 描述可以部署的软件构件(比如Jar,ejb等)之间的静态关系 部署图 描述一个系统的拓扑结构 用例图 描述一系列角色和使用案例以及它们之间的关系,可以用来对 一个系统的最基本的行为进行建模 活动图 描述不同过程之间的动态接触,是使用用例图描述的行为的具 体化 状态图 描述一系列对象的内部状态的变化和转移,注意一个类不能有2 个不同的状态图 顺序图 是一种相互作用图,描述不同对象之间信息传递的时序 协作图 是一种相互作用图,描述发出信息,接受信息的一系列对象的 组织结构 15. 一个对象是现实世界中一个实体的抽象,一个类是一组对象的抽象。 16. 继承:使用已存在的定义作为基础建立新定义的技术。 17. 多态性:使得在多个类中可以定义同一个操作或属性名,并在每个类中可以有不同的实 现。多态性使得一个属性或变量在不同的时期可以表示不同类的对象。 18. 消息通信:封装使对象成为一些各司其职. 互不干扰的独立单位;消息通信为他们提供 了唯一的合法的动态联系途径,使他们的行为能够相互配合,构成一个有机的系统。

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 19. 与客户机/服务器(Client/Server ,C/S)架构相比,浏览器/服务器(Browser/Server , B/S)架构的最大优点是部署和维护方便. 易于扩展。 20. 中间件位于客户机服务器的操作系统之上,管理计算机资源和网络通信。中间件的分类。 21. SOAP(简单对象访问协议). UDDI(统一描述. 发现和集成). WSDL(Web Service 描述 语言). XML(可扩展标记语言)Web服务不适合于单机的应用程序和局域网的同构的应用程 序。是实现SOA的技术。 22. J2EE 跨平台能力强;支持JAVA 语言;.NET 不具备跨平台能力,仅支持Windows 系统, 支持VB. C++. C#. Jscript,通过组件还可支持Java 23. 第二层交换机工作在数据链路层;一般路由器工作在网络层。 24. IEEE 802.3 - CSMA/CD 以太网). 802.4(Token bus,令牌总线). 802.5(Token ring 令 牌环),802.11(无线局域网) 25. TCP. UDP协议:前者是可靠的,后者是不可靠的!TCP 没有UDP 传输的快。QQ. DNS. 微 信都用的是UDP。 26. 交换技术:可分为电路交换方式. 分组交换技术. 报文交换技术. ATM 交换方式. lP 电话技术. 软交换技术 27. DAS 是存储器与服务器的直接连接,一般通过标准接口;直接连网存储NAS—是一个带 有瘦服务器的存储设备,类似于一个专用的文件服务器;NAS产品是真正即插即用的。 存储区域网络SAN—是类似于局域网的高速存储网络。SAN 拥有极度的可扩展性. 简化的存 储管理. 优化的资源和服务共享以及高度可用性。 28. 无线网络根据数据发送的距离分为几种不同的类型:无线局域网络(WLANs). 无线广域 网络 - WWANs). 无线城域网络 - WMANs). 无线个人网络(WPANs)。 29. RAID 0 利用率100%,RAID 1 利用率50% 30. 构件标准主要有三大流派,分别是COM/DCOM/COM+,CORBA和 EJB。 31. 综合布线标准遵循的标准是:EIA/TIA 568A,适用范围:跨越距离不超过3000 米,建 筑总面积不超过100 万平方米,人口为50-5 万人。子系统分为以下6 个:建筑群子系统. 设备间子系统. 垂直干线子系统. 管理子系统. 水平子系统和工作区子系统。水晶头计算: 4.6N(N 是信息接点数量) 注意电阻。 32. 机房工程设计原则:实用性和先进性. 安全可靠性. 灵活性和可扩展性. 标准化. 经济 性. 可管理性。(根据题干描述判断) 33. 网络设计一般要遵循一些原则:先进性. 开放性. 经济型. 高可用性(根据题干判断) 34. 网络拓扑结构,注意星型。 35. 网线的直通和交叉线。 36. 数据总是由物理层到应用层是错误的 37. 在Web服务中,适用HTTP协议传送XML表示及封装的内容 38. AP接入点( ACCESSPOINT)是用于无线网络的无线 HUB,是无线网络的核心。它是移 动计算机用户进入有线以太网骨干的接入点,它在开放空间最大覆盖范围可达百米级。 39. 一些常见的网络名词. 命令 40. 提高可靠性的手段有什么?冗余设计。 41. 帧中继是一种宽带分组交换,使用复用技术时,其传输速率可高达 44.6Mbps 42. 逆向工程:设计模型(实现级);程序数据结构信息(结构级). 对象模型. 数据和控制 流模型(功能级); UML状态图和部署图(领域级); 43. 验证是阶段性审核的过程;确认是验收的过程; 44. 大部分应用服务器都要用到哪种服务器?(答案: DNS) 45. 软件质量分为内部质量. 外部质量. 使用质量,要区分这3 个质量。

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 46. 工作流程引擎是工作流管理系统的运行和控制中心。工作流程引擎的主要功能是流程调 度和冲突检测。 47. TCP/IP是Internet的核心,分4层模型:最高层(5-7 层),常见协议有:FTP. SMTP. DNS. SNMP. HTTP等。次高层(传输层),协议有TCP和UDP。第二层(网络层),协议有IP. ARP. RP. ICMP。最低层为网络接口层,使用串行线路连接时仍需要运行SLIP或PPP协议。 48. A类地址一般分配给具有大量主机的网络使用,B类地址分配给规模中等的网络使用,C 类地址分配给小型局域网使用。由NIC 管理。域名格式:机器名.网络名.机构名.最高域名。 49. 连接建筑群的主干网一般以光缆做传输介质。 50. 汇聚层的存在与否取决于网络规模的大小。 51. 典型的网络攻击步骤:①信息收集;②试探寻找突破口;③实施攻击;④消除记录;⑤ 保留访问权限。 52. GB 17895-1999《计算机信息系统安全保护等级划分准则》分5 个等级:①自主保护级; ②系统审计保护级;③安全标记保护级;④结构化保护级;⑤访问验证保护级。 53. 传统防火墙无法阻止和检测基于数据内容的黑客攻击和病毒入侵,同时也无法控制内部 网络之间的违规行为。扫描器无法发现正在进行的入侵行为。防毒软件对于基于网络的攻击 行为无能为力。目前市场上鲜见特别成熟的安全审计产品,主要从事入侵检测工作。

四 . 新技术

  1. 物联网是通过射频识别(RFID). 红外感应器. 全球定位系统. 激光扫描器等信息传感设 备,按约定的协议,把任何物体与互联网相连接,进行信息交换和通信,以实现对物体的智 能化识别. 定位. 跟踪. 监控和管理的一种网络。物联网关键技术:感知层作为物联网架构 的基础层面,主要技术包括:产品和传感器(条码. RFID. 传感器等)自动化识别技术. 无 线传输技术(WLAN. Bluetooth. ZigBee. UWB). 自组织组网技术. 中间件技术。
  2. 二维条码/二维码能够在横向和纵向两个方位同时表达信息,因此能在很小的面积内表达 大量的信息。其信息量远远超过原来的条码技术,原来的条码技术仅能存储十多个字符,而 二维码存储容量可达数千字符。
  3. RFID 具有远距离读取. 高存储容量. 成本高. 可同时被读取. 难复制. 可工作于各种恶 劣环境等特点;条形码具有容量小. 成本低. 容易被复制. 构造简单. 灵活实用等特点
  4. 云计算的三个服务模式是IaaS. PaaS. SaaS。云计算的核心是虚拟化,通过虚拟化形成 可调用和管理的资源池。云计算架构包括:资源池. 云操作系统. 云平台接口。
  5. 4G技术又称IMT-Advanced 技术。 LTE
  6. IPV6 是128位, 用16进制表示IP 地址。
  7. “互联网+”简单点说就是需要将互联网与传统行业相结合,促进各行各业产业发展。它 代表一种新的经济形态,即充分发挥互联网在生产要素配置中的优化和集成作用,将互联网 的创新成果深度融合于经济社会各领域之中,提升实体经济的创新力和生产力,形成更广泛 的以互联网为基础设施和实现工具的经济发展新形态。
  8. 工业四代 - Industry4.0)是指利用物联信息系统 - Cyber—PhysicalSystem 简称CPS)将生 产中的供应,制造,销售信息数据化. 智慧化,最后达到快速,有效,个人化的产品供应
  9. 13五规划其中在显著位置提出:拓展网络经济空间。实施“互联网+”行动计划。完善 电信普遍服务机制,开展网络提速降费行动,超前布局下一代互联网。推进产业组织. 商业 模式. 供应链. 物流链创新,支持基于互联网的各类创新。
  10. 阿尔法狗:利用“价值网络” 去计算局面,用“策略网络” 去选择下子
  11. VR:综合利用计算机图形系统和各种现实及控制等接口设备,在计算机上生成的. 可交 互的三维环境中提供沉浸感觉的技术。其中,计算机生成的. 可交互的三维环境称为虚拟环 境(即Virtual Environment,简称VE)。虚拟现实技术是一种可以创建和体验虚拟世界的

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 计算机仿真系统的技术。它利用计算机生成一种模拟环境,利用多源信息融合的交互式三维 动态视景和实体行为的系统仿真使用户沉浸到该环境中 12. 中国制造2025:坚持“创新驱动. 质量为先. 绿色发展. 结构优化. 人才为本”的基 本方针,坚持“市场主导. 政府引导,立足当前. 着眼长远,整体推进. 重点突破,自主发 展. 开放合作”的基本原则,通过“三步走”实现制造强国的战略目标:第一步,到2025 年迈入制造强国行列;第二步,到2035年中国制造业整体达到世界制造强国阵营中等水平; 第三步,到新中国成立一百年时,综合实力进入世界制造强国前列。 13. 移动智能终端拥有接入互联网能力,通常搭载各种操作系统,可根据用户需求定制化各 种功能。生活中常见的智能终端包括移动智能终端. 车载智能终端. 智能电视. 可穿戴设备 等。 14. 移动互联网=移动通信网络+互联网内容和应用,它不仅是互联网的延伸,而且是互联网 的发展方向。 15. 移动互联网关键技术:①架构技术SOA:Service Oriented Architect,面向服务的架 构,不涉及底层编程接口和通讯模型,Web Service是目前实现SOA的主要技术。②页面展 示技术Web2.0:严格来说不是一种技术,而是互联网思维模式。③HTML5:在原有HTML 基 础上扩展了API,最大优势可以在网页上直接调试和修改。④Android:特点入门容易,因 为Android 的中间层多以Java 实现,指令相对减少. 开发相对简单,而且开发社群活跃, 开发资源丰富。⑥IOS:一个非开源的操作系统,开发人员必须加入苹果开发者计划,需要 付款以获得苹果的批准,开发语言是Objective-C. C. 和C++,开发难度大于Android。⑦ Windows Phone:微软一款手机操作系统,开发技术:C. C++. C#等。 16. 大数据关键技术:①HDFS:能提供高吞吐量的数据访问,非常适合大规模数据集上的应 用。②HBase:不同于一般的关系数据库,是非结构化数据存储的数据库。③MapReduce:一 种编程模型,主要思想:概念“Map(映射)”和“Reduce(归约)”。④Chukwa:用于监控大 型分布式系统的数据收集系统。

五. 项目管理一般知识

  1. 3种组织结构的优缺点(职能型. 矩阵型. 项目型)
  2. 每个项目阶段都以一个或一个以上的可交付物的完成为标志,这种可交付物是一种可度 量. 可验证的工作成果,如一份规格说明书. 可行性研究报告. 详细设计文档或工作样品。
  3. 螺旋模型特别适合于大型复杂的系统,风险大的项目。
  4. 喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软 件开发过程(注意题目里的问法,是开发方法还是生命周期)
  5. V模型 单元测试的主要目的是针对编码过程中可能存在的各种错误; 集成测试的主要目的是针对详细设计中可能存在的问题; 系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行; 验收测试通常由业务专家或者用户进行,以确认产品能真正符合用户业务上的需要。
  6. 迭代模型是很多过程串,每次执行一个完整的过程串。
  7. PMO 的职责可以了解下
  8. 可以为一个项目设立一个PMO,可以为一个部门设立一个PMO,也可以为一个企业设立一 个PMO,这三级PMO可以在一个组织内同时存在。PMO可以存在于任何组织结构中。
  9. PMO 关注于其内部的项目或子项目之间的协调计划. 优先级和执行情况。
  10. PMO 有支持型. 控制型. 指令型3 种;①支持型:PMO 担当顾问角色。②控制型:PMO 不仅给项目提供支持,而且通过各种手段要求项目服从PMO 的管理策略。③指令型:PMO 直

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 接管理和控制项目。 11. 项目目标的特点不包含临时性 12. 评审的目的是防止本阶段的错误传递到下一个阶段。 13. 产品的生命周期长于项目的生命周期。项目的成本不包含运营成本,产品的包含。 14. 敏捷方法是一种以人为核心. 迭代. 循序渐进的开发方法,适用于一开始并没有或不能 完整地确定出需求和范围的项目,或者需要应对快速变化的环境,或者需求和范围难以事先 确定,或者能够以有利于干系人的方式定义较小的增量改进。在于应对大量变更,获取干系 人的持续参与。

六. 立项管理

  1. 项目建议书(又称立项申请)是项目建设单位向上级主管部门提交项目申请时所必须的 文件,项目建议书应该包括的核心内容如下:(1 )项目的必要性。(2 )项目的市场预测。(3 ) 产品方案或服务的市场预测。 4. 项目建设必需的条件。
  2. 可行性研究:主要分为技术可行性. 经济可行性. 运行环境可行性. 其他方面的可行性。 在进行可研的时候必须遵守:科学性. 客观性. 公正性原则。
  3. 根据项目规模的大小,初步可行性研究可以省略。初步可行性研究的结构及研究的主要 内容基本与详细可行性研究相同,所不同的是占有的资源细节有较大的差异。
  4. 详细可行性研究方法很多,如经济评价法. 市场预测法. 投资估算法和增量净效益法等
  5. 建设方项目论证的内容:
  • 1)项目财务评价 - 2)项目国民经济评价 - 3)项目环境影响评价 - 4)项目社会影响评价
  1. 承建方项目论证的内容:注意和建设方的区别。
    1. 承建方技术可行性分析 2. 承建方人力及其他资源配置能力可行性分析 3. 项 目财务可行性分析 4. 项目风险分析 5. 对可能的其他投标者的相关情况分析
  2. 项目评估是在项目可行性研究的基础上,由第三方进行的。项目评估的方法: 1. 项目 评估法和全局评估法 2. 总量评估法和增量评估法 3. 费用效益分析法 4. 成本效用分 析法 5. 多目标系统分析法。项目评估报告是立项的最重要的报告,但是项目评估不是必 须的。
  3. 项目识别是承建方项目立项的第一步
  4. 在可行性研究报告中,可行性研究的结论包括项目的目标. 规模,技术方案概述及特点, 项目的建设进度计划,投资估价和资金筹措计划,项目财务和经济评价,项目综合评价结论 (在前期,经济是必须包含的,这个最重要)
  5. 投资回收期. 投资回收率需要会算(如果题目是按照具体年份开始的,先换为从0 开始。)
  6. 流程:甲方:(初步需求)---编写项目申请书----可行性研究----项目论证-----项目评估----- 获得批复-------发布招标文件(一般是这样,有的是有能力自己建设) 乙方:看到招标文件----做识别. 可行性研究. 论证. 评估 -----决定投标------中标 -----甲乙双方签订合同。
  7. 项目评估的程序: 1)成立评估小组,进行分工,制定评估工作计划; 2)开展调查研究,收集数据资料,并对可行性研究报告和相关资料进行审查和分析; 3)分析与评估; 4)编写评估报告; 5)讨论. 修改报告; 6)专家论证会; 7)评估报告定稿。

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 13. 项目建设书,变更额度在 10%以内的,不需要重新报建议书和可研报告,只需在项目初 步设计和投资概算报告中作补充说明。 14. 资格预审文件或者招标文件的发售期不得少于5日;通过资格预审的申请人少于3个的, 应当重新招标。投标保证金不得超过招标项目估算价的2%,招标保证金有效期应当与投标 有效期一致。 15. 履约保证金不得超过中标合同金额的10%。 16. 系统集成供应商所应承担的合同责任发生了转移,由组织转移到了项目组。一般来说, 系统集成供应商主要根据项目的特点和类型,决定是否在组织内部为所签署的外部项目单独 立项。 17. 内部立项主要原因:①通过项目立项方式为项目分配资源;②通过项目立项方式确定合 理的项目绩效目标;③以项目型工作方式,提升项目实施效率。 18. 项目内部立项时包括内容:①项目资源估算;②项目资源分配;③准备项目任务书;④ 任命项目经理。

七. 整体管理

  1. 项目章程一般包括以下内容:①概括性的项目描述和项目产品描述;②项目目的或批准 项目的理由;③项目的总体要求,包括项目的总体范围和总体质量要求;④可测量的项目目 标和相关的成功标准;⑤项目的主要风险,如项目的主要风险类别;⑥总体里程碑进度计划; ⑦总体预算;⑧项目的审批要求,即在项目的规划. 执行. 监控和收尾过程中,应该由谁来 做出哪种批准;⑨委派的项目经理及其职责和职权;⑩发起人或其他批准项目章程的人员的 姓名和职权。 出资方代表要对项目的组织提要求,应以什么文件的形式提出?答案:项目章程。
  2. 在制定项目计划的其他分计划之前,首先要有一个范围说明书,首先应关注的是项目范 围说明书
  3. 项目收尾包含合同收尾和管理收尾,会区分2 者的区别。
  4. 组织过程资产的内容,注意区分社会环境因素
  5. 变更控制的5 步必须记住。
  6. 编写计划的原则:管理与技术的统一. 各干系人参与. 渐近明细。注意不是全员参与, 也不是项目经理一个人,注意案例。
  7. 功能需求不属于工作说明书的内容。
  8. 被批准确认的项目管理计划是基线
  9. 凡是控制过程的输入肯定有计划和绩效。
  10. 项目整体管理涉及4个方面:①各分目标之间的集成;②各项目干系人之间的集成;③ 各专业工作之间的集成;④各过程之间的集成。
  11. 作为整合者,项目经理必须:①与项目干系人主动沟通;②干系人之间寻找平衡点;③ 达到各种需求间的平衡。
  12. 项目管理计划制订步骤:①制订各自分项计划;②收集分项计划,整合成项目管理计划; ③执行和监控工作;④提出变更并审批;⑥实施变更,更新项目管理计划。

八. 范围管理

  1. 项目范围是否完成以项目管理计划. 项目范围说明书. WBS. 以及WBS 字典作为衡量标准, 而产品范围是否完成以产品要求作为衡量标准
  2. 需求管理计划是项目管理计划的组成部分,描述了如何分析. 记录和管理需求,以及阶 段与阶段间的关系对管理需求的影响。需求管理计划主要内容包括:①如何规划. 跟踪和报

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 告各种需求活动;②配置管理活动;③需求优先级排序过程;④产品测量指标;⑤需求被列 入跟踪矩阵;⑥收集需求过程。 3. 需求文件内容包括:①业务需求;②干系人需求;③解决方案需求;④项目需求;⑤过 渡需求;⑥与需求相关的假设条件。 4. 详细的范围说明书包括的直接内容或引用内容如下:(掌握,可以作为案例的素材) ①项目目标;②产品范围描述;③项目需求;④项目边界;⑤项目的可交付成果;⑥项目的 制约因素;⑦假设条件。 5. 焦点小组是召集预定的干系人和主题专家,了解他们对所讨论的产品. 服务或成果的期 望和态度。是一种群体访谈而非一对一访谈。 6. 研讨会能够比单项会议更早发现问题,更快解决问题。如,在软件开发行业,就有一种 称为“联合应用设计/开发(JAD)”的引导式研讨会。这种研讨会注重把业务主题专家和开 发团队集中在一起,来改进软件开发过程。在制造行业,则使用“质量功能展开(QFD)”这 种引导式讨论会,来帮助确定新产品的关键特征。 7. WBS 结构分为树型和列表型。树型层次清晰,非常直观,结构性很强,但是不容易修改, 适用于中小型项目。列表型直观性差,适用于大型项目。 8. WBS 的分解步骤:

  1. 识别项目交付物和相关工作; 2. 对WBS的结构进行组织; 3. 对WBS进行分解
  2. 对WBS 中各级工作单元分配标识符或编号 5. 对当前的分解级别进行检验,以确保它 们是必须的,而且是足够详细的。注意一定要内部团队确认WBS,甲方不需要确认。 分解WBS 结构的方法至少有如下三种:使用项目生命周期的阶段作为分解的第一层,而把项 目可交付物安排在第二层;把项目重要的可交付物作为分解的第一层;把子项目安排在第一 层,再分解子项目的WBS 分解工作结构应把握如下原则:
  3. 在各层次上保持项目的完整性,避免遗漏必要的组成部分。
  4. 一个工作单元只能从属于某个上层单元,避免变叉从属。
  5. 相同层次的工作单元应有相同性质。
  6. 工作单元应能分开不同的责任者和不同工作内容。
  7. 便于项目管理进行计划和控制的管理需要。
  8. 最低层工作应该具有可比性,是可管理的,可定量检查的。
  9. 应包括项目管理工作(因为管理是项目具体工作的一部分),包括分包出去的工作。
  10. WBS的最低层次的工作单元是工作包。一个项目的WBS 是否分解到工作包,跟项目的 阶段. 复杂程度和规模有关,一般来说早期,或复杂,或大规模的项目,其WBS的分解颗粒 要大一些,粗一些。需要遵守8/80原则。
  11. WBS 字典是WBS的配套文档,用来描述每个WBS元素。
  12. 范围基准:被批准的详细的项目范围说明书和其相关的WBS以及WBS词典是项目的范围 基准。范围基准是项目管理计划的一个组成部分。在整个项目的生命期,这个范围基准被监 控. 核实和确认
  13. 范围确认和质量控制是不同的,范围确认是有关工作结果的接受问题,而质量控制是有 关工作结果正确与否,质量控制一般在范围确认之前完成,当然也可并行进行。范围确认的 工作是检查,输出是可交付物和变更申请。(注意这里的“检查”的含义,是个广泛意义的 检查)
  14. 控制账户是在WBS 中提出的概念,是在规划包以下,工作包以上,便于管理监控设置的 控制点。是一个管理控制点,在该控制点上,把范围. 预算. 实际成本和进度加以整合,并 与挣值相比较,以测量绩效。控制账户在WBS中选定的管理节点上,每个控制账户可能包括

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 一个或多个工作包,但是一个工作包只能属于一个控制账户。 13. 范围确认完成时,同时应当对确认中调整的WBS 及WBS 字典进行更新 14. 工作分解结构中的要素应该是相对独立的,要尽量减少相互之间的交叉。每条分支分解 层次不必相等,一般控制在3-6层。 15. 编码设计对于WBS来说是个关键技术,进行编码设计时必须仔细考虑收集到的信息和收 集所用的方法。 16. 确认范围的一般步骤:①确认范围的时间;②需要哪些投入;③正式被接受的标准和要 素;④范围会议的组织步骤;⑤组织确认范围会议。 17. 项目干系人进行确认范围时,检查的6 个方面问题:①可交付成果是否确实的;②成果 是否有明确的里程碑;③是否明确质量标准;④审核或者承诺是否表达清晰;⑤是否覆盖了 所有活动;⑥风险发生概率,是否能够降低。 18. 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求 跟踪矩阵确保需求文件中被批准的每项需求在项目结束的时候都能交付。 19. 需求跟踪矩阵包括内容,根据项目取舍:①业务需求;②项目目标;③项目范围;④产 品设计;⑤产品开发;⑥测试场景;⑦详细需求。 20. 需求跟踪矩阵中记录的典型属性包括唯一标识. 需求的文字描述. 收录该需求的理由. 所有者. 来源. 优先级别. 版本. 当前状态(如活跃中. 已取消. 已推迟. 新增加. 已批准. 被分配和已完成)和状态日期。为确保干系人满意,可能需要增加一些补充属性,如稳定性. 复杂性和验收标准。 21. 需求基线定义了项目的范围。每次需求变更并经过需求评审后,都要重新确定新的需求 基线。随着项目的进展,需求基线将越定越高,容许的需求变更将越来越少。

九. 进度管理

  1. 重要的检查点是里程碑. 重要的里程牌是基线。
  2. 前导图法(单代号网络图)(必须全面掌握,要自己会画). 箭线图法(双代号网络图) (会看图,会计算). 双代号时标网络图(会计算)
  3. 虚活动。它不消耗时间,在网络图中由一个虚箭线表示,虚活动可以在关键线路中。
  4. 活动之间的三种依赖关系: - 1)强制性依赖关系. - 2) 选择性依赖关系. - 3)外部依赖关 系 4. 内部依赖关系
  5. 三点估算(PERT)必须会,注意下2 个公式和68%. 95%. 99%. 50%。PERT 可以用于进度 风险。当然,也可以用于其余风险的定量分析。
  6. 进度压缩的技术有以下几种。(注意和缩短工期的区别)
    1. 赶进度。赶进度并非总能产生可行的方案,反而常常增加费用
    2. 快速跟进。这种进度压缩技术通常同时进行按先后顺序的阶段或活动。快速跟进往往 造成返工,并通常会增加风险。
  7. 关键链法允许项目团队在任何项目进度路径上设置缓冲,以应对资源限制和项目的不确 定性。这种方法建立在关键路径法之上,考虑了资源分配. 资源优化. 资源平衡和活动历时 不确定性对关键路径的影响。关键链法增加了作为“非工作活动”的持续时间缓冲,用来应 对不确定性。如图所示,放置在关键链末端的缓冲称为项目缓冲,用来保证项目不因关键链 的延误而延误。其他缓冲,即接驳缓冲,则放置在非关键链与关键链的接合点,用来保护关 键链不受非关键链延误的影响。应该根据相应活动链的持续时间的不确定性,来决定每个缓 冲时段的长短。一旦确定了“缓冲活动”,就可以按可能的最迟开始与最迟完成日期来安排 计划活动。这样一来,关键链法不再管理网络路径的总浮动时间,而是重点管理剩余的缓冲 持续时间与剩余的活动链持续时间之间的匹配关系。

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 8. 资源优化技术是根据资源供需情况,来调整进度模型的技术。包括:①资源平衡(Resources Leveling),为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径 改变,通常是延长。②资源平滑(Resources Smoothing),从而使项目资源需求不超过预定 的资源限制的一种技术。相对于资源平衡而言,资源平滑不会改变项目关键路径,资源平滑 技术可能无法实现所有资源的优化。 9. 假设情景分析就是对“情景 X 出现时应当如何处理”这样的问题进行分析。可以评审各 种情景,使进度与计划保持一致 10. 缩短活动工期方法:①赶工,投入更多的资源或增加工作时间,以缩短关键活动的工期; ②快速跟进,并行施工,以缩短关键路径的长度;③使用高素质的资源或经验更丰富的人员; ④减少活动范围或降低活动要求;⑤改进方法或技术,以提高生产效率;⑥加强质量管理, 及时发现问题,减少返工,从而缩短工期。 11. 6标时的计算. 关键路径. 总工期. 自由时差的计算 12. 为了确保获得精确的绩效衡量信息,项目经理应该尽快重新修订项目进度计划。 13. 甘特图是用来做进度管理的 14. 双代号时标网络图3句话:

  1. 从起点到终点,没波浪线的就是关键路径;
  2. 波浪形的长度就是该活动的自由时差;
  3. 要求某活动的总时差,以该活动为起点,到终点,可能有多条路径,每一条路径的波浪形的长度的和的最小值就是该活动的总时差。

十. 成本管理

  1. 成本的类型:
    1. 可变成本:随着生产量. 工作量或时间而变的成本为可变成本。可变成本又称变动 成本。
    2. 固定成本:不随生产量. 工作量或时间的变化而变化的非重复成本为固定成本。
    3. 直接成本:直接可以归属于项目工作的成本为直接成本
    4. 间接成本:来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目 的费用 机会成本. 沉没成本可以了解下。
  2. 管理储备的使用需要经过批准,不属于基线中;应急储备是由项目经理自由使用的估算 成本,是成本基准的一部分。
  3. 成本预算之后,会形成成本基线,是进行成本控制的基础
  4. 成本估算的步骤:
    1. 识别并分析成本的构成科目
    2. 根据已识别的项目成本构成科目,估算每一科目的成本大小
    3. 分析成本估算结果,找出各种可以相互替代的成本,协调各种成本之间的比例关系。
  5. 确定资源费率:就是了解本项目中需要用到什么资源,每种资源的单价

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 6. 成本预算的步骤:

  1. 将项目总成本分摊到项目工作分解结构的各个工作包。分解按照自顶向下,根据占用 资源数量多少而设置不同的分解权重。
  2. 将各个工作包成本再分配到该工作包所包含的各项活动上。
  3. 确定各项成本预算支出的时间计划及项目成本预算计划。
  4. 挣值分析. 预测技术,一定要注意参数的找出. 典型. 非典型的判断。在案例里一定要 尽力多写点过程。
  5. 一个项目只可以有一个成本基准,当然,随着项目的实施,该基线可能被更新。

十一. 质量管理(特别注意下工具和技术的选择)

  1. 全面质量管理 - TQM)是一种全员. 全过程. 全企业的品质管理。全员参加的质量管理. 全 过程的质量管理. 全面方法的质量管理和全面结果的质量管理。
  2. 六西格玛的优越之处在于从项目实施过程中改进和保证质量,而不是从结果中检验控制 质量。这样做不仅减少了检控质量的步骤,而且避免了由此带来的返工成本,而且也培养了 员工的质量意识。
  3. 质量成本分为预防成本. 评估成本和缺陷成本(内部缺陷. 外部缺陷)。
  4. 质量计划的工具和技术: 1. 效益/成本分析 2. 基准比较 3. 流程图 4. 实验设计 5. 质量成本分析 6. 质量功能展开 7. 过程决策程序图法
  5. 流程图是指任何显示与某系统相关的各要素之间相互关系的示意图,和因果图的区别在 于强调相互关系和流程. 过程。
  6. 实验设计是一种统计方法,它帮助确定影响特定变量的因素,就是一种做试验,寻求一 种最佳的方案。
  7. 项目质量保证活动包括:如何建立质量标准,如何确立质量控制流程,如何进行质量体 系的评估。质量保证应该有独立于项目组的专业人员来进行。
  8. 质量审计是对其他质量管理活动的结构化和独立的评审方法。质量审计可以是预先计划 的,也可是随机的:可以是组织内部完成,也可以委托第三方(外部)组织来完成。
  9. 质量控制的18种工具:
    1. 测试
    2. 检查
    3. 统计抽样
    4. 6 西格玛
    5. 因果图
    6. 流程图
    7. 直方图
    8. 检查表
    9. 散点图
    10. 排列图
    11. 控制图
    12. 相互关系图
    13. 亲和图
    14. 树状图
    15. 矩阵图
    16. 优先矩阵图
    17. 过程决策程序图
    18. 活动网络图(就是进度网络图)
  10. 因果图又叫石川图或鱼骨图,它说明了各种要素是如何与潜在的问题或结果相关联。
  11. 直方图可反映各变量的分布。每一栏代表一个问题或情况的一个恃征或属性。每个栏的 高度代表该种特征或属性出现的相对频率。这种工具通过各栏的形状和宽度来确定问题的根 源,通过对抽查质量数据的加工整理,找出其分布规律。
  12. 散点图显示两个变量之间的关系和规律,两个点越接近对角线,两者的关系越紧密。
  13. 排列图也被称为帕累托图,是按照发生频率大小顺序绘制的直方图。80%的问题是20% 的原因所造成的。也可使用帕累托图汇总各种类型的数据,进行二八分析。注意题干中可能 是说50%的问题是6%的原因,这也是排列图
  14. 控制图; 又叫管理图. 趋势图,它是一种带控制界限的质量管理图表。控制图是对生产 过程质量的一种记录图形,图上有中心线和上下控制限
  15. 亲和图则主要用事实说话,靠“灵感”发现新思想. 解决新问题
  16. 统计抽样可以降低质量控制成本。注意统计抽样的小计算,很简单的。
  17. 新项目正在进行之中,项目经理正与质量保证部门一起试图提高每个人对项目将要满足 质量标准的信心,在开始该过程之前,需要先有质量度量标准

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 18. 要绘制帕累托图,首先要用到直方图。

十二. 人力资源管理

  1. 可使用多种形式描述项目的角色和职责,常用的有三种,层次结构图. 责任分配矩阵和 文本格式
  2. OBS(组织分解结构)与工作分解结构形式上相似,但是它不是根据项目的交付物进行分 解,而是根据组织现有的部门. 单位或团队进行分解
  3. 责任分配矩阵 - RAM)是最直观的方法。RACI 也是如此。
  4. 组建团队的工具:事先分派. 谈判. 采购. 虚拟团队都需要掌握定义
  5. 马斯洛. X. Y. 赫兹伯格双因素. 期望理论。如果考了,是送分题的。马斯洛的5 层;X 是消极,Y是积极;保健因素. 激励因素;目标效价. 期望值。
  6. 团队建设的5 个阶段:形成阶段. 震荡阶段. 规范阶段. 发挥阶段. 结束阶段。请记住, 如果新增加一个成员或是减少一个成员,都是从形成期开始。另外,结束阶段有的题目是没 的。
  7. 冲突的解决办法:问题解决. 合作. 强制. 妥协. 求同存异. 撤退。其中,最好的办法 是问题解决。
  8. 冲突的来源:项目的高压环境. 责任模糊. 存在多个上级. 新科技的使用。
  9. 冲突的特点:①冲突是自然的;②冲突是一个团队问题;③应公开地处理冲突;④冲突 的解决应聚焦在问题;⑤冲突的解决应聚焦在现在。
  10. 人员配备管理计划是项目管理计划的一个分计划,描述的是何时以及怎样满足人力资源 需求。人员配备管理计划包括:①人员招募;②资源日历;③人员遣散计划;④培训需求; ⑤表彰和奖励;⑥遵守的规定;⑦安全性。
  11. 项目经理应该负责团队成员得到培训。
  12. 项目经理5 种权利:①合法的权利;②强制力;③专家权利;④奖励权利;⑤感召权利; 最好用奖励权利和专家权利来影响团队成员,避免强制力。项目经理的合法权利. 奖励权利 和强制力是来自公司的授权,其他权利来自项目经理本人。

十三. 沟通管理

  1. 沟通模型,需要注意噪声和反馈。噪音的三种形式:①外部噪音;②内部噪音;③语义 噪音。
  2. 沟通方式分类:①参与讨论方式;②征询方式;③推销方式(说明);④叙述方式。 控 制程度由弱到强。
  3. 沟通方式的选择基于以下因素:①掌握信息的能力;②是否需要听取其他人的意见和想 法;③是否需要控制信息内容。讨论(头脑风暴);征询(调查问卷);推销(叙述解释); 叙述(劝说鼓动)。
  4. 会议方式是最常见的一种沟通渠道。会议的管理和控制都是非常重要的。成功会议的特 征:①会议有准备;②会中有控制;③会后有结论。
  5. 干系人登记册信息:①主要沟通对象(主要干系人);②关键影响人;③次要沟通对象。
  6. 沟通计划编制的第一步就是干系人分析,得出项目中沟通的需求和方式,进而形成较为 准确的沟通需求表,然后再针对需求进行计划编制
  7. 沟通管理计划应该包括以下内容。①干系人的沟通要求;②沟通信息的描述;③发布信 息的原因;④沟通的具体人员;⑤信息保密的具体人员授权;⑥信息接收的个人或组织;⑦ 沟通渠道的选择;⑧沟通频率。
  8. 沟通管理计划编制过程一般分为如下几个步骤:

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训

  1. 确定干系人的沟通信息需求,即哪些人需要沟通,谁需要什么信息,什么时候需 要以及如何把信息发送出去。
  2. 描述信息收集和文件归档的结构。
  3. 信息交流的形式和方式,主要指创建信息发送的档案:获得信息的访问方法。
  4. 常用的沟通方式的优缺点或特点介绍如下
  5. 信息项目绩效报告需要包含的内容:
  • 1)项目的进展和调整情况。
  • 2)项目的完成情况。
  • 3)项目总投入. 资金到位情况。
  • 4)项目资金实际支出情况。
  • 5)项目主要效益情况。
  • 6)财务制度执行情况。
  • 7)项目团队各职能团队的绩效。
  • 8)项目执行中存在的问题及改进措施。
  • 9)预测——随着项目的进展,根据获得的工作绩效信息对以前的预测进行更新并重新签发。
  • 10)变更请求——对项目绩效进行分析后,通常需要对项目的某些方面进行变更。这些变更 请求应按整体变更控制过程所描述的办法进行处理。
  • 11)其他需要说明的问题
  1. 沟通渠道:N(N-1)/2,(N 为项目干系人数量),如果本项目干系人数较多,请注意项 目变更的可能较大
  2. 项目管理中,保证客户和干系人满意的最重要的活动是将需求记录下来整理为文件。干 系人管理是项目经理的职责,是均衡各干系人的期望。
  3. 沟通的原则:
  4. 沟通内外有别
  5. 非正式的沟通有利于关系的融洽
  6. 采用对方能接受的沟通风格
  7. 沟通的升级原则
  8. 扫清沟通的障碍
  9. 阻碍有效沟通的因素:
  10. 沟通双方的物理距离; 2. 沟通的环境因素; 3. 缺乏清晰的沟通渠道; 4. 复杂的 组织结构; 5. 复杂的技术术语(行话); 6. 有害的态度
  11. 沟通渠道的选择基本上从两个维度进行考虑。1)即时性维度2)表达方式维度
  12. 沟通关注的要点:效果和效率

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训

十四. 干系人管理

  1. 沟通管理和项目干系人管理的联系和区别:沟通管理强调对项目信息的计划. 收集. 存 储. 组织. 发布,以及监控沟通以保证它的高效性。项目干系人管理强调的不仅是要管理干 系人的期望,更要保证他们的适度参与,而后者是项目成功非常关键的因素之一。
  2. 通常,由项目经理负责项目干系人管理。
  3. 权利/利益方格:首先关注B 区(重点管理. 及时汇报);C 区(随时告知);A 区(令其 满意);D 区(化最少的精力来监督他们)。
  4. 项目经理已通过干系人分析技术把干系人分类:①不了解;②抵制;③中立;④支持; ⑤领导。 干系人参与评估矩阵 C:当前参与程度 D:所需参与程度 干系人 不知晓 抵制 中立 支持 领导 干系人1 C D 干系人2 C D 干系人3 D C
  5. 常用的沟通方法:①交互式沟通;②推式沟通;③拉式沟通。
  6. 干系人管理计划通常还包括:
  • 1)关键干系人的所需参与程度和当前参与程度;
  • 2)干系人变更的范围和影响;
  • 3)干系人之间的相互关系和潜在交叉;
  • 4)项目现阶段的干系人沟通需求;
  • 5)需要分发给干系人的信息,包括语言. 格式. 内容. 详细程度和发送频率;
  • 6)分发相关信息的理由,以及可能对干系人参与所产生的影响;
  • 7)随着项目的进展,更新和优化干系人管理计划的方法。
  1. 在项目生命周期中,应该对干系人参与进行持续控制,并随着项目进展和环境变化, 维 持并提升干系人参与活动的效率和效果。

十五. 风险管理(特别注意下工具和技术的选择)

  1. 风险管理并不是完全消除风险
  2. 风险识别工具和技术:德尔菲法. 头脑风暴法. SWOT 技术. 检查表
  3. 风险识别的原则:(①由粗及细,由细及粗;②严格界定风险内涵并考虑风险因素之间的 相关性;③先怀疑,后排除;④排除与确认并重;⑤必要时,可作实验论证。 风险识别是一项反复过程。随着项目生命周期的推进,新风险可能会不断出现

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 4. 定性风险分析的工具:概率和影响矩阵. 紧迫性评估等 5. 定量风险分析的工具:期望货币值(要会计算). PERT. 蒙特卡洛(不需要专家参与) 6. 消极风险或威胁的应对策略: 1. 规避 2. 转移 3. 减轻 4. 接受 积极风险或机会的应对策略: 1. 开拓 2. 分享 3. 提高 4. 接受 降低要求是规避;投保是转移;冗余是减轻。 7. 风险再评估。风险监控过程通常要求使用本章介绍的过程对新风险进行识别并对风险进 行重新评估。 8. 风险审计在于检查并记录风险应对策略处理已识别风险及其根源的效力以及风险管理过 程的效力。 9. 权变措施:随机应变,是在风险监控中用的。 10. 状态审查会。项目风险管理可以是定期召开的项目状态审查会的一项议程。 11. 风险管理计划的内容。 12. 对于低等级的风险不是不管了,是先观察,看其发展 13. 风险管理计划包括内容:①方法论;②角色与职责;③预算;④时间安排;⑤风险类别; ⑥风险概率和影响的定义;⑦概率和影响矩阵;⑧修订的干系人承受力;⑨报告格式;⑩跟 踪。

十六. 变更管理

  1. CCB 是决策机构,不是作业机构,可以只有一个人,如果是一个人,那就是甲方老板。 通常,CCB 的工作是通过评审手段来决定项目是否能变更,但不提出变更方案。一般来说, 甲方. 乙方. 监理方都需要有代表参与到CCB。
  2. 变更初审的目的如下:
    1. 对变更提出方施加影响,确认变更的必要性,确保变更是有价值的。
    2. 格式校验,完整性较验,确保评估所需信息准备充分。
    3. 在干系人间就提出供评估的变更信息达成共识。
    4. 变更初审的常见方式为变更申请文档的审核流转。
  3. 变更的流程必须清楚。
  4. 如果有监理方参与的项目,需要最开始把变更申请提交给监理方。监理机构在变更的初 审阶段,对于完全无必要的变更,可以在征求建设单位的意见后驳回变更申请。
  5. 配置管理工具有:Rational ClearCase. VisualSourceSafe和Concurrent Versions System, 这个知识点做了解。(了解),但是也可以用手工的方式进行。
  6. 项目经理在变更中的作用是:响应变更提出者的要求,评估变更对项目的影响及应对方 案,将要求由技术要求转化为资源需求,供授权人决策;并据评审结果实施即调整项目基准, 确保项目基准反映项目实施情况。
  7. 变更管理的基本原则是首先建立项目基准. 变更流程和变更控制委员会。
  8. 变更影响分析由项目经理负责,项目经理可以自己或指定人员完成。变更影响分析内容 包括:技术可行性. 对进度的影响. 对成本的影响. 对质量的影响以及变更风险分析。
  9. 变更管理过程中包含配置管理活动:①配置项识别;②配置状态记录;③配置确认与审 计。

十七. 采购管理

  1. 自制和外购决策要会。如果决定自制,那么可能要在采购计划中规定组织内部的流程和 协议。如果决定外购,那么要在采购计划中规定与产品或服务供应商签订协议的流程。
  2. 采购工作说明书描述足够的细节,以允许预期的卖方确定他们是否有提供买方所需的产

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 18 品. 成果或服务的能力。这些细节将随采购物的性质. 买方的需要或预期的合同形式而变化。 采购工作说明书描述了由卖方提供的产品. 服务或者成果。工作说明书包括的主要内容有前 言. 服务范围. 方法. 假定. 服务期限和工作量估计. 双方角色和责任. 交付资料. 完成标 准. 顾问组人员. 收费和付款方式. 变更管理等。采购工作说明书是采购过程中的一个关键 文件,可以根据需要进行修改,直到达成最终协议。 3. 投标人会议(不可以只组织部分的投标人来) 4. 加权系统 5. 采购审计:是从采购计划编制到合同管理的采购过程中的一种结构性审查。采购审计的 目标是找出采购过程中的成功和失败之处,以保证成功的对项目或其他项目的采购合同进行 准备和管理。属于合同收尾。 6. 项目经理在编制询价计划时,由于待采购的内容比较专业,为了更加明确采购需求,该 项目经理需要使用的文件为供应商意见书 7. 询价不是仅仅是询问价格,还有服务 8. 在项目中准备进行采购时,应组织制定的采购文件包括采购管理计划. 工作说明书. 标 书(RFP)和评估标准等内容 9. 采购文件是买方准备的,建议书是卖方准备的 10. 评分标准在制定询价计划中就应该完成 11. 项目经理采用记录管理系统来管理合同. 采购文档和相关记录。 12. 合同分成三种:①总价合同;②成本补偿合同;③工料合同。采用总价合同,买方必须 准确定义要采购的产品或服务。总价合同进一步分固定总价合同和变动总价合同两种。 13. 固定总价合同特点是范围确定。对卖方(乙方)来说,卖设备时使用此种合同,固定总 价合同最简单的形式就是一个采购单。如下项目可签订固定总价合同:①工程量小. 工期短; ②工程设计详细,图纸完整;③风险小;④投标期相对宽裕;⑤验收标准明确。总价加激励 费用合同(FPIF),要设置一个价格上限。总价加经济价格调整合同(FP-EPA):允许根据条 件变化以事先确定的方式对合同价格进行最终调整。 14. 成本补偿合同:向卖方支付为完成工作而发生的全部合法实际成本. 人工费用以及合理 的利润。成本加固定费用合同(CPFF),费用只能针对已完成的工作来支付。成本加激励费 用(CPIF),向卖方支付预先确定的激励费用,如果最终成本低于或高于原始估算成本,则 买方和卖方需要根据事先商定分摊超出费用。成本加奖励费用(CPAF),为卖方报销履行合 同工作所发生的一切合法成本,但是只有在满足了合同中规定的某些笼统. 主观的绩效标准 的情况下,才能向卖方支付大部分费用。完全由买方根据自己对卖方绩效的主观判断来决定 奖励费用,并且卖方通常无权申诉。成本加成本百分比,卖方的实际项目成本,买方报销。 卖方的费用以实际成本的百分比来计算。 15. 工料合同适应情况:当不能迅速确定准确的工作量或者工作说明书时,工料合同适用于 动态增加人员. 专家或其他外部支持人员等情况。在时间紧急的情况下,选择工料合同比较 稳妥。

十八. 合同管理

  1. 合同可以是书面形式. 口头形式和其它形式。书面形式是指合同书. 信件和数据电文(包 括电报. 电传. 传真. 电子数据交换和电子邮件)等可以有形地表现所载内容的形势
  2. 合同的8 要素:当事人的名称和地址;标的;数量;质量;价款和报酬;履行期限. 地 点和方式;违约责任和解决争议的办法。另外,对于IT项目合同,还需要注意:验收时间. 标准,知识产权. 售后服务等。
  3. 按信息系统范围划分的合同分类: 1. 总承包合同 2. 单项项目承包合同 3. 分包合

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 19 同 4. 按项目付款方式划分的合同分类: 1. 总价合同 2. 单价合同 3. 成本加酬金合同 当不能迅速确定准确的工作量时,时间和材料合同(不是成本补偿合同. 成本加酬金合 同等)适用。 5. 要约. 要约邀请. 承诺 6. 合同法规定了4种违约责任的承担方式:

  1. 继续履行。
  2. 采取补救措施(如质量不符合约定的,可以要求修理. 更换. 重作. 退货. 减少 价款或报酬等)。
  3. 赔偿损失。
  4. 支付约定违约金或定金。
  5. 合同的管理包含合同的签订管理. 履行管理. 变更管理. 档案管理
  6. 索赔的性质属于经济补偿行为,而不是惩罚。索赔在一般情况下都可以通过协商方式友 好解决
  7. 按索赔的目的分类可分为工期索赔和费用索赔
  8. 索赔里的时间:28天
  9. 项目发生索赔事件后,一般先由监理工程师调解,若调解不成,由政府建设主管机构进 行调解,若仍调解不成,由经济合同仲裁委员会进行调解或仲裁。
  10. 索赔的依据有法律法规. 标准规范. 合同文件. 招投标文件. 往来记录. 相关凭证等
  11. 找谁索赔,是需要看合同关系的,没合同关系,不可以索赔。
  12. 无效合同:①一方以欺诈. 胁迫的手段订立合同,损害国家利益;②恶意串通,损害国 家. 集体或者第三人利益;③以合法形式掩盖非法目的;④损害社会公共利益;⑤违反法律. 行政法规的强制性规定。

十九. 配置管理

  1. 从重要性和质量要求方面可以分为非正式文档和正式文档;从项目周期角度可分为开发 文档. 产品文档. 管理文档。什么文档是什么文档,必须会。文档质量分四级:①最低限度 文档(1 级);②内部文档(2 级);③工作文档(3级);④正式文档(4 级)。
  2. 典型配置项包括项目计划书. 需求文档. 设计文档. 源代码. 可执行代码. 测试用例. 运行软件所需的各种数据。基线配置项可能包括所有的设计文档和源程序等,非基线配置项 可能包括项目的各类计划和文档。
  3. 配置库可以分为动态库(开发库. 程序员库. 工作库). 受控库(主库). 静态库(软件 仓库)和备份库4种类型。存放的内容需要知道。
  4. 配置项的状态可分为“草稿”. “正式”和“修改”三种,要会判断。
  5. 配置审计分为物理配置审计和功能配置审计。要会区分。一个是功能性方面,一个是物 理介质方面
  6. 配置管理包括6 个主要活动:①制定配置管理计划;②配置标识;③配置控制;④配置 状态报告;⑤配置审计;⑥发布管理和交付。
  7. CASE 工具操作手册不属于配置项
  8. SCM 是对软件配置的质量的管理
  9. 所有配置项的操作权限应由CMO(配置管理员)严格管理,基本原则是:基线配置项向 软件开发人员开放读取的权限;非基线配置项向PM. CCB及相关人员开放。
  10. 配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。
  11. 配置管理涵盖了项目的整个生命周期

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 12. 在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置 项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛 弃旧版本。版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或 混淆等现象,并且可以快速准确地查找到配置项的任何版本。 13. 配置库的建库模式:决定配置库的结构是配置管理活动的重要基础。一般常用的是两种 组织形式:按配置项类型分类建库和按任务建库。 14. 实施配置审核的时机:通常选择以下几种情况实施配置审核:信息系统产品交付或是信 息系统产品正式发行前;信息系统开发的阶段工作结束之后;在维护工作中,定期地进行。 15. 配置基线由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体。基线通常对 应于开发过程中的里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线。 交付给外部顾客的基线一般称为发行基线(Release Milestone),内部开发使用的基线一般 称为构造基线(Build Baseline)。 16. 对于每一个基线,定义的内容:建立基线的事件. 受控的配置项. 建立和变更基线的程 序. 批准变更基线所需的权限。 17. 配置管理员进行的配置管理活动:①编写配置管理计划;②建立和维护配置管理系统; ③建立和维护配置库;④配置项识别;⑤建立和管理基线;⑥版本管理和配置控制;⑦配置 状态报告;⑧配置审计;⑨发布管理和交付;⑩对项目成员进行配置管培训。 18. 发布管理和交付主要任务:①存储;②复制;③打包;④交付;⑤重建。

二十. 安全管理

  1. 保密性:信息不被泄漏给未授权的个人. 实体和过程或不被其使用的特性。 完整性:保护资产的正确和完整的特性, 就是确保接收到的数据就是发送的数据。数据不应 该被改变,这需要某种方法去进行验证。例如可以用MD5实现。 可用性:需要时,授权实体可以访问和使用的特性. 磁盘和系统的容错及备份. 可接受的登 录及进程性能. 可靠的功能性的安全进程和机制可以来实现。路由选择控制和审计跟踪等技 术主要用于提高信息系统的可用性。 不可抵赖性:是指建立有效的责任机制,防止用户否认其行为,这一点在电子商务中是极其 重要的。可以通过数字签名实现
  2. 信息系统安全的技术体系包括物理安全. 运行安全. 数据安全
  3. 用户权限的分配遵循“最小特权”原则;用户密码应严格保密,并及时更新;重要用户 密码应密封交安全管理员保管,人员调离时应及时修改相关密码和口令。
  4. 系统运行安全与保密的层次构成 按粒度从粗到细的排序是:系统级安全. 资源访问安全. 功能性安全. 数据域安全。
  5. 安全等级可分为保密等级和可靠性等级两种,系统的保密等级与可靠性等级可以不同。 保密等级应按有关规定划为绝密. 机密和秘密。可靠性等级可分为三级,对可靠性要求最高 的为A级,系统运行所要求的最低限度可靠性为C级,介于中间的为B级
  6. 对称加密技术:加密和解密函数都使用同一个密钥的加密方式。常见的对称加密方法有 IDEA. DES. 3DES 等,其中IDEA密钥长度为128 位,DES 有效密钥长度为56 位,3DES为112 位。对称加密具有:加/解密速度快,密钥管理简单,适宜一对一的信息加密传输过程等优 点,但是具有加密算法简单,密钥长度有限,加密强度不高,密钥分发困难,不适宜一对多 的加密信息传输等确定。 非对称加密技术:加密和解密函数使用不同的密钥的加密方式。常见的非对称加密方法 有RSA。非对称加密具有加密算法复,密钥长度任意,加密强度很高,适宜一对多的信息加 密交换等优点,但是具有加/解密速度慢,密钥管理复杂的缺点

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训 7. 安全审计是指对主体访问和使用客体的情况进行记录和审查,以保证安全规则被正确执 行,并帮助分析安全事故产生的原因。安全审计是落实系统安全策略的重要机制和手段,通 过安全审计识别与防止计算机网络系统内的攻击行为. 追查计算机网络系统内的泄密行为, 是信息安全保障系统中的一个重要组成部分。作用不包括保证可信网络内部信息不外泄。安 全审计产品主要包括主机类. 网络类及数据库类等等。安全审计的作用如下:

  1. 检测对系统的入侵,对潜在的攻击者起到震慑或警告作用
  2. 发现计算机的滥用情况,对于已经发生的系统破坏行为提供有效的追纠证据
  3. 为系统安全管理员提供有价值的系统使用日志,从而帮助系统安全管理员及时发现系 统入侵行为或潜在的系统漏洞。
  4. 为系统安全管理员提供系统运行的统计日志,使系统安全管理员能够发现系统性能上 的不足之处或者需要改进与加强的地方
  5. 入侵检测系统IDS 是一种主动保护自己免受攻击的网络安全技术。入侵检测系统能够帮 助系统对付网络攻击,扩展了系统管理员的安全管理能力(包括安全审计. 监视. 攻击识别 和响应),提高了信息安全基础结构的完整性。 入侵监测系统:负责监视网络上的通信数据流和网络服务器系统中的审核信息,捕获可疑的 网络和服务器系统活动,发现其中存在的安全问题,当网络和主机被非法使用或破坏时,进 行实时响应和报警,产生通告信息和日志。不仅仅检测来自外部的入侵行为,还可以检测内 部用户的未授权活动,数据分析是入侵检测系统的核心
  6. 入侵检测的步骤是信息收集. 数据分析. 响应
  7. 数字签名不可以保证保密性 11.《信息安全等级保护管理办法》将信息系统的安全保护等级分为5 级。第一级(合法权 益造成损害);第二级(合法权益严重损害);第三级(公共利益造成严重损害或国家安全造 成损害);第四级(公共利益造成特别严重损害国家安全造成严重损害);第五级(国家安全 造成特别严重损害)。
  8. GB 17859-1999 标准是计算机信息系统安全等级保护系列标准的核心,规定了计算机系 统安全保护能力的五个等级。①用户自主保护级;②系统审计保护级;③安全标记保护级; ④结构化保护级;⑤访问验证保护级。
  9. 安全空间的五大属性:认证. 权限. 完整. 加密. 不可否认
  10. 访问控制技术可以分为强制访问控制(MAC). 自主访问控制(DAC). 基于角色的访问 控制(RBAC 和访问控制列表方式(ACL)。基于角色的访问控制中,角色由应用系统的管理 员定义。角色成员的增减也只能由应用系统的管理员来执行,即只有应用系统的管理员有权 定义和分配角色。而且授权规定是强加给用户的,用户只能被动接受,不能自主地决定。用 户也不能自主地将访问权限传给他人,这是一种非自主型访问控制。

二十一. 收尾管理

  1. 项目的收尾管理包含合同收尾和管理收尾2个方面
  2. 项目收尾管理工作包括:①项目验收工作;②项目总结工作;③系统维护工作;④项目 后评价工作。
  3. 系统集成项目的验收工作包括如下步骤:
    1. 系统测试 2. 系统的试运行 3. 系统的文档验收 4. 项目的最终验收报告
  4. 对于系统集成项目,所涉及的文档应该包含如下部分:
    1. 系统集成项目介绍 2. 系统集成项目最终报告 3. 信息系统说明手册 4. 信息系 统维护手册 5. 软硬件产品说明书. 质量保证书等
  5. 项目总结的主要意义如下。

提供信息系统项目管理师. 系统集成项目管理工程师. 系统规划. 一级建造师. 二级建造师全程辅导培训

  1. 了解项目全过程的工作情况及相关的团队或成员的绩效状况。
  2. 了解出现的问题并进行改进措施总结。
  3. 了解项目全过程中出现的值得吸取的经验并进行总结。
  4. 对总结后的文档进行讨论,通过后存入公司的知识库,从而纳入企业的过程资产。
  5. 一般的项目总结会应讨论如下内容:项目绩效. 技术绩效. 成本绩效. 进度计划绩效. 项目的沟通. 识别问题和解决问题. 意见和建议
  6. 验收测试工作可以由业主和承建单位共同进行,也可以由第三方公司进行,但无论哪种 方式都需要双方认可的正式文档为依据进行验收测试。如果验收测试未获通过,则应立即查 找原因,一般会转向变更环节进行修改和补救。
  7. 举行绩效评估会议是完成项目评估的最常用方法之一。
  8. 信息系统后评价工作主要内容:①信息系统目标评价;②信息系统过程评价;③信息系 统效益评价;④信息系统可持续性评价。

第二十二. 知识产权. 法律法规. 标准规范

  1. 招投标法相关内容
  2. 政府采购法相关内容
  3. 合同法相关内容
  4. 著作权法相关内容
  5. 招投标法实施条例
  6. 政府采购法实施条例
  7. 文档管理指南
  8. 质量保证规范
  9. 质量特性
  10. 机房设计规范
  11. 综合布线。
  12. 可靠性与可维护性 到今天了,上面的12 个内容应该都看了部分,做了相关的历年考题,对相关法规标准规范 有了一定的学习,如果还没看,请去把我在题目书里画的一些重点去看看。 著作权保护年限: 50 年;商标10 年(若注册人死亡或倒闭1 年后,未转移则可注 销,期满前6 个月内必须续注);发明专利: 20 年;使用新型和外观设计专利权: 10 年 著作权法不适用于下列情形:法律. 法规,国家机关的决议. 决定. 命令和其他具有立 法. 行政. 司法性质的文件,及其官方正式译文;时事新闻;历法. 通用数表. 通用表格和 公式。 知识产权的特性是从它的本质属性即无体性派生出来的,具体包括无体性. 专有性. 地 域性. 时间性。

下午题知识点

一. 可行性研究分析(立项管理)

项目的必要性分析: ①原有系统开发不规范,缺少必要的技术文档,原开发人员跳槽,新接手的开发人员很 难维护原有系统,维护成本可能会接近或超过新开发的成本。 ② 原系统采用落后的设计或因设计人员的水平有限,系统架构设计不合理,难以扩充 和修改。 ③ 原系统设计虽然合理,也考虑到了日后的扩充,但因业务发展太快,远远超过原来 的设想,量变引起质变 ④ 原系统开发工具已过时,用落后的开发工具继续维护还不如用新的开发工具重新开 发。 ⑤原系统所基于的硬件或软件平台已过时,在原有平台继续维护已无必要,需要开发基 于当前流行平台的新系统项目的可能性。 可行性研究的内容: ①技术可行性分析;②经济可行性分析;③运行环境可行性分析;④其他方面的可行性 分析(法律可行性. 社会可行性)。 可研过程中可能出现的问题?

  1. 项目经理的技术经验不足

  2. 没有正式. 书面的新产品研发项目建议书就开展可行性研究工作

  3. 新产品研发的可行性研究工作不充分,尤其缺少技术可行性分析和论证

  4. 研发过程中对人才缺乏. 竞争对手等带来的风险缺乏充分的分析,没有合理有效的应对方案

  5. 没有新产品的初步设计方案就开始研发工作

  6. 新产品的需求和技术指标不应由领导把关,应进行外部评审

  7. 在项目启动前缺少对项目成本的估算或成本估算工作未到位

  8. 可行性研究报告缺少必要的内部论证或外部评估环节

  9. 没有制订综合. 全面的项目管理计划,进度计划不能代替项目管理计划,领导的指示不能代替项目管理计划

  10. 项目发生进度延误的可能性时未及时调整或更新进度计划并与领导及相关各方沟通

  11. 前期立项工作中人员参与不充分,缺少关键技术人员和财务人员 可行性研究的步骤: ①明确项目规模和目标;②研究正在运行的系统;③建立新系统的逻辑模型;④导出和评价 各种方案;⑤推荐可行性方案;⑥编写可行性研究报告;⑦递交可行性研究报告 项目建议书批准后的主要工作一般为:

  12. 确定项目建设的机构. 人员。

  13. 选定建设地址,申请规划设计条件,做规划设计方案。

  14. 落实筹措资金方案。

  15. 落实原料的供应. 配套方案. 安全消防措施等。

  16. 外商投资企业申请企业名称预登记。

  17. 进行详细的市场调查分析。

  18. 编制可行性研究报告。 项目评估的程序: 1)成立评估小组,进行分工,制定评估工作计划; 2)开展调查研究,收集数据资料,并对可行性研究报告和相关资料进行审查和分析; 3)分析与评估; 4)编写评估报告; 5)讨论. 修改报告; 6)专家论证会; 7)评估报告定稿。(项目评估的最终成果是项目评估报告) 二. 整体管理 可能的问题?

  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. 变更不应由项目经理审批,应有CCB审批

  62. 项目变更实施前没有及时变更合同

  63. 缺少范围确认环节(或项目需求. 设计等没有得到用户的正式评审);

  64. 范围控制存在问题 范围管理应对措施:

  65. 项目范围进行清晰定义,并根据定义对工作进行分解,制定WBS;

  66. 对项目进行合理估算,对工作量有量化的把握;

  67. 对项目范围进行有效控制;

  68. 重新定义项目范围必须得到高层和客户的确认;

  69. 进行沟通管理,协调多个项目干系人之间的矛盾。 项目范围说明书的内容: 1 )成果性目标. 约束性目标2)产品范围描述3)项目的可交付物4)项目边界5)产品验收标准6)项目的约束条件7)项目的假定; 需求管理计划的主要内容至少包括:

  • 1)如何规划. 跟踪和报告各种需求活动。

  • 2)配置管理活动,例如,如何启动产品变更,如何分析其影响,如何进行追溯. 跟踪 和报告,以及变更审批权限。

  • 3)需求优先级排序过程。

  • 4)产品测量指标及使用这些指标的理由。

  • 5)用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

  • 6)收集需求过程 需求文件的主要内容至少包括:(注意和上面的区别) ①业务需求,包括:可跟踪的业务目标和项目目标. 执行组织的业务规则. 组织的指导 原则。 ②干系人需求,包括:对组织其他领域的影响. 对执行组织内部或外部团体的影响. 干 系人对沟通和报告的需求。 ③解决方案需求,包括:功能和非功能需求. 技术和标准合规性需求. 支持和培训的需 求. 质量需求. 报告需求(可用文本记录或用模型展示解决方案需求,也可两者同时使用)。 ④项目需求,例如:服务水平. 绩效. 安全和合规性,以及验收标准。 ⑤过渡需求。 ⑥与需求相关的假设条件. 依赖关系和制约因素。 树型. 列表型;按生命周期. 按子项目. 按可交付物三种分解方法. 分解步骤。还有8 个 原则 需求变更的可能问题:

  1. 没有按照严谨的变更控制流程对整个需求变更做完整的记录和跟踪(对于需求变更 请求没有记录. 没有对变更进行正式的评审和批准. 对于变更的结果没有验证)
  2. 对需求变更可能造成的影响进行全面的评估和分析(只分析了需求变更对于工期的 影响)
  3. 没有修改项目管理计划并重新评审(项目经理不应口头布置任务,同时里程碑的调 整没有通知相应的管理层)
  4. 配置管理工作没有做好(没有对需求文件和设计文件进行修改,并升级相应版本, 相应的模块编码的修改也没有进行版本控制)
  5. 变更结果没有跟客户沟通(需求变更实施完成后,没有让客户对最终结果进行确认) 需求变更出现问题的影响:
  6. 没有遵循正式的变更控制流程,可能导致需求变更的过程失控和不可追溯。
  7. 没有对变更的影响进行完整的分析,可能导致无法全面了解这次变更对项目的进度. 范围. 成本. 质量等造成多大的影响。
  8. 没有修改项目管理计划,可能导致实际工作内容与计划有较大的偏差,使项目管理 计划无法指导项目实施。
  9. 没有对相应技术文档进行修改可能导致需求. 设计与编码无法对应,不利于后期的 测试和以后的维护工作。版本管理和配置管理没有做好,可能导致在变更失败后无法将项目 恢复到变更前的状态。
  10. 没有让用户对最终结果进行确认,可能导致双方对变更结果的意见不一致,不利于 项目验收和最终交付。

需求跟踪矩阵通常包括有以下内容,具体取舍根据项目需要:

  • 1)业务需要. 机会. 目的和目标。

  • 2)项目目标。

  • 3)项目范围/WBS 可交付成果。

  • 4)产品设计。

  • 5)产品开发。

  • 6)测试策略和测试场景。

  • 7)高层级需求到详细需求。 需求跟踪矩阵中记录的典型属性包括唯一标识. 需求的文字描述. 收录该需求的理由. 所有者. 来源. 优先级别. 版本. 当前状态(如活跃中. 已取消. 已推迟. 新增加. 已批准. 被分配和已完成)和状态日期。为确保干系人满意,可能需要增加一些补充属性,如稳定性. 复杂性和验收标准。需求跟踪矩阵连接了需求与需求源,用于在整个项目生命周期中对需求 进行跟踪。 四. 进度管理 进度管理计划会规定:

  • 1)项目进度模型制定。

  • 2)准确度。

  • 3)计量单位。

  • 4)组织程序链接。

  • 5)项目进度模型维护。

  • 6)控制临界值。

  • 7)绩效测量规则。

  • 8)报告格式。

  • 9)过程描述。 进度管理可能出现的问题以及可以采用的办法,其中还要注意可能会和成本一起考!

    1. 团队成员没有及早参与,需求分析耗时长,要早期参与进项目
    2. 经验不足,进度计划制定不准,采取有效的历时估算方法和网络计划技术,制定 进度计划
    3. 考虑项目期间特定时期会对进度产生影响
    4. 增加人手,聘请更有经验的人员,或找兼职人员
    5. 加班
    6. 并行
    7. 重新估算后面的工期
    8. 加强沟通,减少变更
    9. 加强控制,避免返工
    10. 外包
    11. 加强沟通,先完成关键需求
    12. 增加资源有时可能压缩工期有限
    13. 关注关键路径,在关键路径上加资源,有效果
    14. 关注里程碑
    15. 加强进度与成本. 风险. 质量等知识点的协调 解决方案:
  • 1)向公司申请增加资源,或使用经验丰富的员工

  • 2)优化网络图,重排活动之间的顺序,压缩关键路径

  • 3)临时加班(赶工),尽可能补救耽误的时间或提高资源利用率 4. 将部分阶段的工作改为并行,并进行内部流程的优化 5. 变更原来的进度计划。根据上一阶段的绩效,对后续工作重新评估,修订计划, 并征得项目干系人的同意 (6)加强同项目干系人的沟通 (7)加强对交付物. 项目阶段工作的及时检查和控制,避免后期出现返工 8. 尽可能调配非关键路径上的资源用于关键路径上的任务 9. 优化外包,采购等环节,并全程监控。 进度压缩的方法: 1. 赶进度。 2. 快速跟进。 缩短工期的方法:

  • 1)赶工,投入更多的资源或增加工作时间,以缩短关键活动的工期;

  • 2)快速跟进,并行施工,以缩短关键路径的长度;

  • 3)使用高素质的资源或经验更丰富的人员;

  • 4)减小活动范围或降低活动要求;---(如果是自己答案例,请在前面写:经过甲方同意)

  • 5)改进方法或技术,以提高生产效率;

  • 6)加强质量管理,及时发现问题,减少返工,从而缩短工期。 进度提前的变更方法

    1. 分析进度,找出哪些地方需要采取纠正措施;
    2. 确定应采取哪种具体纠正措施;
    3. 修改进度计划,并将纠正措施列入计划;
    4. 重新计算进度,估计计划采取的纠正措施。 活动资源估算的工具:1)专家判断2)多方案分析3)出版的估算数据4)项目管理软件5) 自下而上估算 活动历时估算的工具:1)专家判断2)类比估算3)参数估算4)三点估算5)后备分析 制定进度表的工具:1)进度网络分析2)关键路线法3)进度压缩4)假设情景分析5)资 源平衡6)关键链法7)项目管理软件8)应用日历9)调整时间提前与滞后量10)进度模 型 进度控制的主要技术和工具:
  1. 进度报告
  2. 进度变更控制系统;
  3. 绩效衡量;
  4. 项目管理软件;
  5. 偏差分析;
  6. 进度比较横道图;
  7. 资源平稳
  8. 假设条件情景分析
  9. 进度压缩;
  10. 制订进度的工具 如何保证满足项目的进度要求:1. 进行计划的贯彻;2. 调整工作;3. 抓住关键路径;4. 提高资源利用率;5. 加强组织管理工作;6. 加强进度控制。 监督和跟踪项目进度的步骤:1. 细化WBS,基于WBS 和工时估算制定活动网络图,制定项 目工作计划;2. 建立对项目工作的监督和测量机制;3. 确定项目里程碑,并建立有效的评 审机制;4. 对项目中发现的问题. 及时采取纠正和预防措施,并进行有效的变更管理。5. 使用有效的项目管理工具,提升项目管理的工作效率。

7 其实进度管理主要是计算题,要会找关键路径. 会求6标时. 自由 时差,要会调整工期,还需要会结合挣值进行分析。 提示:在压缩了一个活动之后,要分析关键路径是否有变化,不管有没变化,都需要在答题 纸上说明。 五. 成本管理

  1. 成本估算和预算的联系:都运用类比估算. 参数模型. 自下而上等工具和技术;都是以 WBS为基础的。
  2. 成本估算和预算的区别:估算成本是对完成项目活动所需资金进行近似估算的过程;估算成本其输出是成本估算,这种估算并未得到管理层的批准;成本估算的精确程序以工作包为基础;制定预算是汇总所有单个活动或工作包的估算成本,建立一个经批准的成本基准的过程;成 本预算将基于工作包的成本估算分配到每项活动及相应时间段;成本预算输出的是成本基准计划即经过批准的成本预算。 其实成本管理主要是计算题,注意和进度的结合。 EV. PV. AC. BAC . CV. SV. EAC. ETC . CPI. SPI 公式:CV=EV-AC >0,节省 <0,超支 SV=EV-PV >0,提前 <0 滞后 CPI=EV/AC, >1,节省 ; <1,超支 SPI=EV/PV , >1,提前 ; <1,落后 ETC= - BAC-EV) 当前偏差被看做是非典型的 ETC= - BAC-EV)/CPI 当前偏差被看做是代表未来的典型偏差 EAC=AC+ETC ----衍化为下面两个公式 EAC=AC+BAC-EV 当前偏差被看做是非典型的 EAC=AC+ - BAC-EV)/CPI 当前偏差被看做是代表未来的典型偏差 VAC=BAC-EAC 提示:一定要按过程写,就算是不会,也一定要多写,写公式,能写几步是几步。另外呢?如果 是和进度结合的题目,如果题目里没特殊说明,求PV 的时候要按照网络图来,就是按最早开始 算,当然,如果题目里有限制条件,则按照限制条件来。

成本估算的工具:1)类比估算2)确定资源费率3)自下而上估算4)参数估算5)项目管 理软件6)供货商投标分析7)准备金分析8)质量成本 成本预算的工具:1)成本汇总2)准备金分析3)参数估算4)资金限制平衡 成本估算的步骤

  1. 识别并分析成本的构成科目
  2. 根据已识别的项目成本构成科目,估算每一科目的成本大小
  3. 分析成本估算结果,找出各种可以相互替代的成本,协调各种成本之间的比例关系。 成本预算的步骤
  4. 将项目总成本分摊到项目工作分解结构的各个工作包。分解按照自顶向下,根据占用 资源数量多少而设置不同的分解权重。
  5. 将各个工作包成本再分配到该工作包所包含的各项活动上。
  6. 确定各项成本预算支出的时间计划及项目成本预算计划。 项目成本控制的定义,包括如下内容: ①对造成成本基准变更的因素施加影响; ②确保变更请求获得同意; ③当变更发生时,管理这些实际的变更; ④保证潜在的成本超支不超过授权的项目阶段资金和总体资金; ⑤监督成本执行(绩效),找出与成本基准的偏差; ⑥准确记录所有的与成本基准的偏差; ⑦防止错误的. 不恰当的或未批准的变更被纳入成本或资源使用报告中 ⑧就审定的变更,通知项目干系人; ⑨采取措施,将预期的成本超支控制在可接受的范围内。 成本超支进度落后措施:用高效人员. 在预防风险的情况下并行施工等. 提高工作效率 成本超支进度超前措施:抽调人员. 放慢进度,采取措施控制成本,必要时调整基线。 六. 质量管理 项目质量管理可能问题:
  7. 有制定可行的质量管理计划并积极实施;
  8. 没有全面的质量管理进展情况报告;
  9. 沟通方式单一或不全面,容易误导用户,致用户不必要的担心
  10. 质量保证过程中缺乏QA的参与
  11. 质量控制环节缺失,例如评审和测试
  12. 测试方法不当或不充分
  13. 测试控制的流程不对,或测试安排的紧张,或未进行质量控制就进行了范围确认。
  14. 没有质量保证经验。
  15. 检查频率的设定有问题。
  16. 应加强项目过程中的质量控制或检查,不能等到工作产品完成后才检查。
  17. QA发现问题应与当事人协商,如果无法达成一致要向项目经理或更高级别的领导汇报,而不能自作主张。
  18. 在质量管理中,没有与合适的技术手段相结合。
  19. 对程序员在质量意识和质量管理的培训不足
  20. 职责分配不清楚
  21. 项目经理在项目质量管理方面的经验欠缺
  22. 进度计划制定的不合理(或进度计划安排过于紧张)
    1. 需求分析. 系统设计阶段的质量控制可能不到位. 缺少评审环节
    1. 测试过程中配置管理工作未到位
  • 19)项目缺乏质量标准和质量规范
  • 20)没有建立项目的质量保证体系
  • 21)在质量管理中,没有采用合适的工具. 技术和方法 应该怎么解决或提高项目质量?
  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. 提出合理有效的质量整改措施(如建议的纠正措施. 对项目计划可能的更新等)

质量保证体系包含?

  1. 是否制定明确的质量计划
  2. 是否建立健全专职的质量管理机构
  3. 是否实现管理业务标准化,管理流程程序化
  4. 是否配备必要的资源条件
  5. 是否建立了一套灵敏的质量信息反馈系统。 质量保证人员,在整个项目中应该完成哪些工作?
    1. 计划阶段制定质量管理计划和相应的质量标准
    2. 按计划实施质量检查,是否按标准过程实施项目工作。注意项目过程中的质量检查,每次进行检查之前准备检查清单(checklist),并将质量管理相关情况予以记录
    3. 依据检查的情况和记录,分析问题,发现问题,与当事人协商进行解决。问题解决后要进行验证;如果无法与当事人达成一致,应报告项目经理或更高层领导,直至问题解决
    4. 定期给项目干系人发质量报告
    5. 为项目组成员提供质量管理要求方面的培训或指导

质量控制的工作应做好以下几方面内容:

  1. 维护工作进行质量控制,做好相关文档工作;
  2. 在有条件情况下,开始对已交付系统进行文档建设,尤其是用户手册的建设工作;
  3. 建立组织级的质量管理体系和相关的标准及规范,取得高层领导的支持和信任,开 展整体质量控制观念的培养,在以后工作中实施严格的质量控制工作。 质量管理体系的改进步骤:
    1. 找出目前质量体系不合适项目实际情况的问题
    2. 制定改进计划,对项目实施流程进行改进
    3. 将改进工作分配给各部门
    4. 修改体系文件并会同各部门进行评审
    5. 在部分项目中试运行改进后的体系,找出问题,改进
    6. 正式发布改进后的体系并持续改进 企业的质量管理体系主要存在以下问题:
    7. 目标工作与实际工作和原有管理割裂开来,认为目标归目标,实际工作中没沿用原来的管理模式;
    8. 未能结合企业的实际情况,照搬照抄,其后果导致旧的方法弃之不用,新的方法不知如何使用;
    9. 实际运行中缺乏指导性. 操作性。
    10. 在体系建立和实施过程,个别领导和富有管理职能的人员,对体系理解不透. 不准确,而其又要具体指导目标工作,以致于体系无法在本单位得到有效的贯彻;
    11. 把目标工作看成是额外安排的一件事,被动应付,不推不动,实施不用心,满足于上级下达的目标任务;
    12. 个别单位对体系的宣传力度不够,使一些部门领导和员工对体系的认识存在偏差;
    13. 在体系的建立和实施过程中的各种工作较为肤浅,缺乏深入的研究及遇到问题主动的解决。

改进之策:

  1. 加强领导的组织和协调作用;
  2. 统一认识,牢固树立目标的长久思想;
  3. 加强培训和教育;
  4. 以质量管理体系为中心,整合各种管理制度间的关系;
  5. 强化内审和管理评审工作;
  6. 重视持续改进;
  7. 重视质量管理制度化建设,加强考核,强化监督保障机制的作用。

质量计划的方法:效益/成本分析. 基准比较. 流程图. 实验设计. 质量成本分析. 质量功 能展开. 过程决策程序图法 质量控制的方法: 4 个:统计抽样. 检查. 测试. 6西格玛 老七种工具:因果图. 流程图. 直方图. 检查单. 散点图. 排列图(帕累托图). 控制图(管 理图. 趋势图) 新七种工具:相互关系图. 亲和图. 树状图. 矩阵图. 优先矩阵图. 过程决策程序图. 活动 网络图 质量管理过程可以分解为 4个环节:

  1. 确立质量标准体系。
  2. 对项目实施进行质量监控。
  3. 将实际与标准对照。
  4. 纠偏纠错。 项目管理过程的质量保证活动的基本内容如下:
  5. 制定质量标准。
  6. 制定质量控制流程。
  7. 提出质量保证所采用方法和技术。
  8. 建立质量保证体系。 项目质量控制过程一般要经历以下基本步骤:
  9. 选择控制对象。
  10. 为控制对象确定标准或目标。
  11. 制定实施计划,确定保证措施。
  12. 按计划执行。
  13. 对项目实施情况进行跟踪监测. 检查,并将监测的结果与计划或标准比较。
  14. 发现并分析偏差。
  15. 根据偏差采取相应对策.
  16. 质量控制跟质量保证的区别:质量保证主要是按照既定的质量计划来对过程进行追踪, 并且还包含质量改进;而质量控制则监控项目的具体结果,确定其是否符合项目的质量标准, 并进行不合格情况的追踪。(简单记忆:质量保证看得是整个项目,控制是关注各阶段具体 可交付成果,另外质量保证工具有质量审计跟过程分析,从这两点上区分控制跟保证。此题 也可以结合输入工具输出来作答)

七. 人力资源管理

人力资源可能问题: ①缺乏足够的项目管理能力和经验;②兼职过多,精力和时间不够用,顾此失彼;③没 有进入管理角色,定位错误,疏于对项目的管理;④新人缺乏培训和全程的跟踪和监控;⑤ 没有进行良好的冲突管理。 应对措施:

  1. 事先制定岗位的要求. 职责和选人的标准,并选择合适的人选;
  2. 对工作进行全面估算,如果有人负荷过重,需要找人代替,解决负载平衡问题;
  3. 事前沟通并对相应人员明确要求,明确角色的轻重缓急,促使尽快转换角色;
  4. 上级应该注意平时对人员的培养和监控;
  5. 对项目团队进行有效的冲突管理。
  6. 采用合适的团队建设手段,消除团队成员间的隔阂。
  7. 明确项目团队的目标及项目组各成员的分工。
  8. 建立清晰的工作流程和沟通机制。
  9. 建立明确的考核评价标准。
  10. 鼓励团队成员之间建立参与和分享的氛围。
  11. 制定有效的激励措施。 团队组建常见问题: ①招募不到合适的项目成员;②团队的组成人员尽管富有才干,但却很难合作;③团队 气氛不积极,造成项目团队成员的士气低落;④项目团队的任务和职责分配不清楚;⑤人员 流动过于频繁。 产生原因: ①没有能够建立人力资源获取和培养的稳定机制;②没有完整识别项目所需的人力资源 种类. 数量和相关任职条件;③没有建立一个能充分. 有效发挥能力的团队;④没有清楚地 分配工作职责到个人或人力单元。 应对措施: ①建立稳定的人力资源获取和培养机制;②在项目早期,进行项目的整体人力资源规划, 明确岗位设置. 工作职责和协作关系;③进行项目团队建设,加强团队沟通,建立合作氛围; ④根据项目团队成员的工作职责和目标,跟踪工作绩效,及时予以调整和改进,提升项目整 体绩效。

八. 沟通管理和干系人管理

项目干系人包括: ①项目经理,②顾客/客户,③执行组织,④项目团队成员,⑤项目管理团队,⑥出资 人,⑦有影响的人,⑧项目管理办公室。 如何进行项目干系人分析: ①进行项目干系人识别;②分析项目干系人的重要程度;③进行项目干系人的支持度分 析;④针对不同项目干系人,特别是重要的项目干系人,给出管理项目干系人的建议,并予 以实施。 如何改进项目沟通: ①使用项目管理信息系统;②建立沟通基础设施;③使用项目沟通模版;④把握项目沟 通基本原则;⑤发展更好的沟通技能;⑥把握人际沟通风格;⑦进行良好的冲突管理。 保证团队沟通顺畅的六点措施: ①有效的沟通者;②发布者;③避免沟通阻断器;④紧密矩阵式结构;⑤指挥室;⑥有效的会议。 沟通基本原则: ①沟通内外有别;②非正式的沟通有助于关系的融洽;③采用对方能接受的沟通风格; ④沟通的升级原则;⑤扫除沟通的障碍。 可能问题和应对措施的补充

  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. 采用项目管理信息系统 沟通管理计划应该包括以下内容:
  • 1)干系人的沟通需求。
  • 2)针对沟通信息的描述,包括格式. 内容. 详尽程度等。
  • 3)发布信息的原因。
  • 4)负责信息沟通工作的具体人员。
  • 5)负责信息保密工作的具体人员的授权。
  • 6)信息接收的个人或组织。
  • 7)沟通渠道的选择。
  • 8)信息传递过程中所需的技术或方法。
  • 9)进行有效沟通所必须分配的各种资源,包括时间和预算。
  • 10)沟通频率,例如,每周沟通等。
  • 11)上报过程,针对下层无法解决的问题,确定问题上报的时间要求和上报路径。
  • 12)项目进行过程中,对沟通管理计划更新与细化的方法。
  • 13)通用词语表. 术语表。
  • 14)项目信息流向图. 工作流程图. 授权顺序. 报告清单,会议计划等。
  • 15)沟通过程中可能存在的各种制约因素。
  • 16)沟通工作指导以及相关模板。
  • 17)有利于有效沟通的其他方面,比如,建议的搜索引擎,软件使用手册等。

干系人管理计划通常还包括:(掌握)

  • 1)关键干系人的所需参与程度和当前参与程度;
  • 2)干系人变更的范围和影响;
  • 3)干系人之间的相互关系和潜在交叉;
  • 4)项目现阶段的干系人沟通需求;
  • 5)需要分发给干系人的信息,包括语言. 格式. 内容. 详细程度和发送频率;
  • 6)分发相关信息的理由,以及可能对干系人参与所产生的影响;
  • 7)随着项目的进展,更新和优化干系人管理计划的方法。

干系人登记册

    1. 基本信息,如干系人的姓名. 职位. 地点. 项目角色. 联系方式;
  • 2)评估信息,如主要需求. 主要期望. 对项目的潜在影响. 与生命周期的哪个阶段最 密切相关;
  • 3)干系人分类,如关键干系人/非关键干系人. 内部/外部. 支持者/中立者/反对者等

干系人管理说明

  • 1)重要干系人对项目可能有重大影响, 有时关键干系人能决定项目成败,在项目早期 就要尽早识别干系人;
  • 2)项目干系人对项目的影响可能是积极的也可能是消极的;
  • 3)项目中干系人的期望可能是互相矛盾的;
  • 4)识别干系人, 了解和管理干系人的期望. 处理好利益冲突,是项目干系人管理的重 要内容;
  • 5)干系人的满意度是一个关键的项目目标;

管理干系人参与活动

  • 1)让干系人的支持者理解项目. 争取支持,反对者降低敌意,提高项目成功概率;
  • 2)调动干系人适时参与, 获取或确认他们对项目成功的持续承诺;
  • 3)管理干系人的期望,确保实现项目目标;
  • 4)处理尚未成为问题的关注点,预测干系人可能提出的问题;
  • 5)澄清和解决已识别出的问题; #九. 配置管理. 变更管理

配置管理过程

  1. 制定配置管理计划
  2. 配置标识
  3. 配置控制
  4. 配置状态报告
  5. 配置审计
  6. 发布管理和交付

配置管理问题

  1. 没有项目管理经验,不适合项目经理的职位。
  2. 项目经理兼任配置管理员,精力不够,无法完成配置管理工作;
  3. 范围管理有问题;
  4. 版本管理没有做好,没有统一的版本管理机制,各版本不可追溯,导致重要版本丢失
  5. 项目中没有建立基线,导致需求. 设计. 编码无法对应;
  6. 没有做好变更管理,项目中的变更不可控
  7. 配置管理计划不应由CCB制定。
  8. 基线变更流程缺少变更验证(或确认)环节
  9. CCB成员的要求不应以人数作为规定,而是以能否代表项目干系人利益为原则
  10. 该公司可能没有版本管理规定或甲乙没有统一执行版本规定
  11. 变更审查应该提交CCB审核
  12. 变更发布应交由CMO 完成
  13. 甲乙两人不能同时修改错误
  14. 没有做配置管理规划,缺少完整的配置管理方案
  15. 缺少配置管理及变更管理流程,没有配置管理委员会
  16. 试运行的系统版本没有及时建立基线并让各业务部门正式确认;
  17. 配置权限管理存在问题;
  18. 人员职责不清晰,没有CMO(配置管理员)的参与并控制配置权限;
  19. 开发人员没有按照变更流程的要求修改系统及代码;
  20. 开发人员修改代码后没有及时修改文档,导致两者不一致;
  21. 代码被修改后没有及时进行回归测试并请干系人确认;
  22. 文档管理存在问题,没有 做好文档的交接. 更新. 变更管理工作;
  23. 配置管理过程中没有做好相应的记录;
  24. 新人的培训工作没有跟进到位。

改进措施:

  1. 从项目整体出发,做好配置管理规划
  2. 定义合理的配置管理流程,规定项目中出现变更的处理办法
  3. 与各方干系人达成共识,组建配置管理委员会
  4. 识别配置项,并为配置项建立惟一标识,保证其可追溯
  5. 建立配置基线,使重要配置项处于受控状态
  6. 定期提效配置状态报告,改进配置管理方法
  7. 组建配置管理方案设计小组
  8. 仔细了解单位的情况. 历史. 人员. 组织形式等
  9. 对配置管理工具进行有效评估
  10. 制定全面有效的配置管理计划,包括建立配置管理环境. 组织机构. 成本. 进度等, 在配置管理计划中详细描述,建立示例配置库. 配置标识管理. 配置库控制. 配置的检查和
  11. 评审. 配置库的备份. 配置管理计划附属文档
  12. 梳理变更脉络,确定统一的最终需求和设计;
  13. 梳理配置项及其历史版本;
  14. 对照最终需求和设计逐项分析现有配置项及历史版本的符合情况;
  15. 根据分析结果由干系人确定整体变更计划并实施;
  16. 加强整体版本管理。

配置库的作用

  • 1)记录与配置相关的信息.
  • 2)利用库中的信息可评价变更后的后果
  • 3)从库中可提取各种配置管理过程的管理信息,可利用库中的信息查询回答许多配置

管理问题 配置项:典型配置项包括项目计划书. 需求文档. 设计文档. 源代码. 可执行代码. 测试用 例. 运行软件所需的各种数据,它们经评审和检查通过后进入软件配置管理。 配置管理中的权限问题:所有配置项的操作权限应由配置管理员(CMO)严格管理,基本原 则是:基线配置项向软件开发人员开放读取的权限;非基线配置项可以向项目经理(PM)变 更管理委员会(CCB)及相关人员开放; 工作 负责人 编制配置管 理计划 创建配置管 理环境 审核变更计 划 变更申请 变更实施 变更发布 CCB √ CMO √ √ √ √ 项目经理 √ 开发人员 √ √

配置识别的内容如下:

  • 1)识别需要受控的软件配置项。
  • 2)给每个产品和它的组件及相关的文档分配唯一标识。
  • 3)定义每个配置项的重要特征及识别其所有者。
  • 4)识别组件. 数据及产品获取点和准则。
  • 5)建立和控制基线。
  • 6)维护文件盒组件的修订与产品版本之间的关系。

创建基线或发行基线的主要步骤如下

  1. 配置管理员识别配置项;
  2. 为配置项分配标识;
  3. 为项目创建配置库,并给每个项目成员分配权限;
  4. 各项目团队成员根据自己的权限操作配置库;
  5. 创建基线或发行基线并获得CCB的授权。

建立配置管理系统的基本步骤

  1. 组建配置管理方案构造小组。包括: 小组负责人。 技术支持专家。 配置管理技术专家。 配置管理系统用户代表。
  2. 对目标机构进行了解. 评估。
  3. 配置管理工具及其提供商评估。
  4. 制订实施计划。
  5. 定义配置管理流程。
  6. 试验项目的实施。
  7. 全面实施。

什么时候进行配置审核:

  • 1)产品交付或是产品正式发行前
  • 2)阶段工作结束以后
  • 3)在维护工作中,定期的进行 参与配置审核的人员可以是项目租人员或非项目组人员,例如其他项目的配置管理人员. 项 目组织内部的审核人员以及组织的配置管理人员。 变更的流程:1. 接受变更申请;2. 对变更的初审;3. 变更方案论证;4. 批准或拒绝;5. 实施;6. 监控7. 效果评估;8. 验证变更。 变更的原因:1. 计划. 定义有误;2. 项目执行有偏差;3. 外部环境的改变;4. 客户新的 需要;5. 为了应对紧急事件。 变更中常见的问题:1. 没有遵循变更控制流程;2. 没有书面的记录3. 应该有CCB进行审 批4. 没有及时更新项目管理计划。

十. 合同管理

项目合同签订的注意事项

  1. 当事人的法律资格当事人订立合同,应当具有相应的民事权利能力和民事行为能力。
  2. 质量验收标准质量验收标准是一个关键指标。如果双方的验收标准不一致,就会在系统验收时产生纠纷。
  3. 验收时间当事人没有约定设备的交付时间或者约定不明确的,可以协议补充,不能达成协议的,依照合同有关条款或交易习惯确定。若仍不能确定,则供货方可以随时履行,采购方也可以随时要求履行,但应当给予对方必要的准备时间。
  4. 技术支持服务
  5. 损害赔偿原则上,委托方与被委托方都具有损害赔偿这项权利,但比较多的情况是因为承建方对于企业实施信息系统的困难估计不足,结果陷入到期后难以完成项目的尴尬局面。
  6. 保密约定 当事人在订立合同过程中知悉的商业秘密,无论合同是否成立,不得泄露或者不正当地使用。泄露或者不正当地使用该商业秘密给对方造成损失的,应当承担损害赔偿责任。
  7. 合同附件合同生效后,当事人就质量. 价款或者报酬. 履行地点等内容没有约定或者约定不明确的,可以协议补充:不能达成补充协议的,按照合同有关条款或者交易习惯确定。
  8. 法律公证为避免合同纠纷,保证合同订立的合法性,当事人可以将签订的合同拿到公证机关进行公证。经过公证的合同,具有法律强制执行效力。

合同管理里可能会出现的问题

  1. 合同没订好,没有就具体完成的工作形成明确清晰的条款

  2. 甲方没有对需求及其变更进行统一的组织和管理

  3. 缺乏变更的接收/拒绝准则

  4. 项目干系人及其关系分析不到位,范围定义不全面. 不准确

  5. 甲乙双方对项目范围没有达成一致认可或承诺

  6. 缺乏项目全生命周期的范围控制

  7. 缺乏客户/用户参与

  8. 甲方无法进行跨部门协调

  9. 实施范围不清楚. 验收标准不清楚

  10. 项目沟通有问题

  11. 客户不验收或拖延验收. 签字. 客户有情绪. 不付款

  12. 客户对项目质量信心不足. 售后没有承诺等。

  13. 缺少违约责任相关条款;

  14. 缺少变更处理及索赔相关条款索赔流程:1. 提出索赔要求;2. 报送索赔资料. 3. 监理工程师答复4. 监理工程师逾期答复 后果5. 持续索赔

  15. 仲裁与诉讼如果甲方向乙方公司提出索赔要求,乙方应该如何处理? 1.公司在接到甲方的索赔要求及索赔材料后,应根据公司与甲方签订的合同,进行认真分析和评估,给出索赔答复; 2. 在双方对索赔认可达成一致的基础上,向甲方进行赔付;如双方不能协商一致,按照合同约定进行仲裁或诉讼; 3. 同时公司依据与其他相关公司(下游供应商或分包商)签订的合同,向其他公司提出索赔要求,按索赔流程处理。

后续可以怎么做?

    1. 对双方的需求(项目范围)做一次全面的沟通和说明,达成一致,并记录下来,请 建设方签字确认。
    1. 就完成的工作与建设方沟通确认,并请建设方签字。
    1. 就待完成的工作列出清单,以便完成时请建设方确认。
    1. 就合同中的验收标准. 步骤和方法与建设方协商一致。
    1. 必要时可签署一份售后服务承诺书,将此项目周期内无法完成的任务做一个备忘, 承诺在后续的服务期内完成,先保证项目能按时验收。
    1. 对于建设方提出的新需求,可与建设方协商进行合同变更,或签订补充合同

十一. 收尾管理

项目收尾的具体内容主要是项目验收. 项目总结和项目评估审计。项目总结会的内容总结的内容应包括:项目绩效. 技术绩效. 成本绩效. 进度计划. 绩效识别问题和解决问题意见和建议。

项目总结内容和意义

  1. 了解项目全过程的工作情况及相关的团队或成员的绩效状况。
  2. 了解出现的问题并进行改进措施总结。
  3. 了解项目全过程中出现的值得吸取的经验并进行总结。
  4. 对总结后的文档进行讨论,通过后即存入公司的知识库,从而纳入企业的过程资产。

对于系统集成项目,所涉及的文档应该包含如下部分:

  1. 系统集成项目介绍
  2. 系统集成项目最终报告
  3. 信息系统说明手册
  4. 信息系统维护手册
  5. 软硬件产品说明书. 质量保证书等项目团队的转移。转移的时候需要考核绩效. 评估团队成员,并进行奖励。

团队成员转移的流程:

  1. 项目团队成员的管理计划,也就是项目人力资源管理计划中描述所说的人员转移条件已经触发
  2. 项目团队成员所承担的任务已经完成,提交了经过确认的可交付物并已完成工作交接
  3. 项目经理与项目团队成员确认该成员的工作衔接已告一段落或已经完成。
  4. 项目经理签发项目团队成员转移确认文件
  5. 项目经理签发项目团队成员的绩效考核文件
  6. 项目经理通知所有相关的干系人
  7. 若是项目收尾全体项目成员结束工作,应召开项目总结表彰大会,肯定项目的成绩. 团队人员的业绩,同时总结项目的经验教训。

怎么才可以促使甲方项目验收?

  1. 请求公司的管理层出面去与甲方协调
  2. 重新确认需求并获得各方认可
  3. 和甲方明确合同. 以及双方确认的补充协议等,包括修改后的范围. 进度和质量方面的文件等,作为验收标准
  4. 准备好相应的项目结项文档,向甲方提交可能的收尾的问题?
    1. 没有充分做好验收前的准备,或软件系统没有达到验收前的标准,或软件还存在计划修复的缺陷,这些缺陷未经修复和确认便进入正式验收环节。
    2. 在验收过程中未根据变更控制流程对软件进行修改,导致文档与软件不一致
    3. 软件更新后没有对文档进行变更便交付给客户。
    4. 项目验收未正式完成,未签署验收报告变更进行了项目总结
    5. 项目收尾过程不完整,缺少正式的项目总结环节,不能只编写总结报告
    6. 项目总结报告未能反映项目的实际情况
    7. 缺少项目评估或审计环节。

项目收尾的具体内容? 项目收尾的具体内容主要是项目验收. 项目总结和项目评估审计。 项目的正式验收包括验收项目产品. 文档及已经完成的交付成果。 项目总结属于项目收尾的管理收尾,而管理收尾有时候又被称为行政收尾,就是检查项 目团队成员及相关干系人是否按规定履行了所有责任。实施行政收尾过程还包括收集项目记录. 分析项目成败. 收集应吸取的教训,以及将项目信息存档供本组织将来使用等活动统一为一个整体。 项目评估的意义是将项目的所有工作加以客观的评价,从而对项目全体成员的成果形成 绩效结论。好的项目评估会引导后续项目的开展,并对项目过程的改进起到很重要的作用。 项目审计应由项目管理部门与财务部门共同进行,相关的审计项目应在项目成本管理中 列出,在项目收尾的时候,对已经列出的支出和收入进行财务审计,对不合理的支出和收入 加以分析,为改进项目的管理服务。

验收中存在的主要问题:

  1. 没有进行有效的系统测试;
  2. 没有准备好相应的文档;
  3. 没有按照规范的流程进行验收;
  4. 与客户的沟通不良。

验收工作的步骤:

  1. 系统测试
  2. 系统试运行
  3. 文档验收
  4. 最终的验收报告。

验收需要正式的验收报告。对于系统集成项目,一般来说,需要证书的验收测试工作, 验收测试工作可以由业主和承建单位共同进行,也可以由第三方公司进行,但无论哪种方式 都需要双方认可的正式文档为依据进行验收测试。

十二. 风险管理

主要风险来源: ①需求风险;②技术风险;③团队风险;④关键人员风险;⑤预算风险;⑥范围风险。 风险项 产生原因 应对措施 没有正确理解业务问题 项目干系人对业务问题的 认识不足. 计算起来过于复 杂. 不合理的业务压力. 不 现实的期限 用户培训. 系统所有者 和用户的承诺与参与. 使用高水平的系统分析 师 用户不能恰当的使用系统 信息系统没有与组合战略 相结合. 对用户没有做足够 的解释. 帮助手册编写的不 好. 用户培训工作做的不够 用户的定期参与. 项目 的阶段交付. 加强用户 培训. 完善信息系统文 档 拒绝需求变更 固定的预算. 固定的期限. 决策者对市场和技术缺乏 正确的理解 变更管理. 应急措施 对工作的分析和评估不足 缺乏项目管理经验. 工作压 力过大. 对项目工作不满意 采用标准技术. 使用具 有丰富经验的项目管理 师 人员流动 不现实的工作条件. 较差的 工作关系. 缺乏对职员的长 远期望. 行业发展不规范. 企业规模较小 保持好的职员条件. 确 保人与工作匹配. 保持 候补. 外聘. 行业规范 缺乏合适的开发工具 技术经验不足. 缺乏技术管 理准则. 技术人员的市场调 研或对市场理解有误. 研究 预先测试. 教育培训. 选择替代工具. 增强组 织实力 预算不足. 组织实力不够 缺乏合适的开发与实施人员 对组织架构缺乏认识. 缺乏 中长期的人力资源计划. 组 织不重视技术人才的技术 工作. 行业人才紧缺 外聘. 招募. 培训 缺乏适合的开发平台 缺乏远见. 没有市场和技术 研究. 团队庞大陈旧难以转 型. 缺乏预算 全面评估. 推迟决策 使用了过时的技术 缺乏技术前瞻人才. 轻视技 术. 缺乏预算 延迟项目. 标准检测. 前期研究. 培训 风险管理计划包括以下内容。

  • 1)方法论
  • 2)角色与职责
  • 3)预算
  • 4)时间安排
  • 5)风险类别
  • 6)风险概率和影响的定义
  • 7)概率和影响矩阵
  • 8)修订的干系人承受力
  • 9)报告格式
  • 10)跟踪 风险应对计划的主要内容:
    1. 需要应对的风险清单。
    2. 形成一致意见的应对措施。
    3. 实施所选应对策略采取的具体行动。
    4. 明确风险管理人和分配给他们的责任。
    5. 风险发生的征兆和预警信号。
    6. 实施所选应对策略需要的预算和进度计划活动。
    7. 设计好要准备的符合有关当事人风险承受度的用在不可预见事件上的预留时间和 费用。
    8. 应急方案和要求实施方案的引发因素。
    9. 要使用的退出计划,它作为对某个已经发生,并且原来的应对策略已被证明不当 的风险的一种反应。
    10. 对于特定的风险,如果它们可能发生,为了规定各方的责任,可以准备用于保险. 服务或其他相应事项的合同。
C#
1
https://gitee.com/hyzsbook/rk.git
git@gitee.com:hyzsbook/rk.git
hyzsbook
rk
软考资料
master

搜索帮助