软考系统架构师知识点整理(下)

目录

• 3.1 基于ODP的架构师实践
• 3.2 架构师的管理实践
• 3.3 层次式架构设计
• 3.4 企业集成架构设计
• 3.5 面向方面的编程
• 3.6 嵌入式系统设计
• 3.7 面向服务的架构
• 4.1 信息系统项目管理
• 4.2 信息技术服务知识
• 4.3 管理科学基础知识
• 4.4 知识产权与标准规范

基于ODP的架构师实践

基于ODP的架构开发过程

• 开放分布式进程的参考模型(RM-ODP)
  

系统构想

1. 架构构想是指系统开发人员与用户之间的共同协议
2. 好处
   * 有利于架构师对系统的认识更全面、准确
   * 有利于统一开发人员的思想和看法
   * 有利于正确确定需求的先后顺序
   * 最大程度提高与客户的沟通、客户对设计的参与

需求分析

1. 需求分析：
   * 系统范围对象关系图
   * 用户接口原型
   * 需求的适用性
   * 确定需求的优先级
   * 为需求建立功能结构模型
   * 使用质量功能分配(Quality Function Deployment, QFD)
2. 需求分析特点
   * 完整性
   * 一致性
   * 验证性：保持和用户要求的同步； 保持需求分析各侧面之间一致； 保持需求和系统设计间的同步

系统架构设计

• 开放分布式处理(Open Distributed Processing, ODP)从5个标准来分析系统架构，包括：企业业务架构、逻辑信息架构、计算接口、分布工程和技术的选择

系统转换、操作维护和系统移植

系统转换是由新的系统代替旧的系统的过程。系统交付后，转入操作维护阶段。

• 系统转换的方式
  • 直接转换
  • 平行转换
  • 分段转换
  • 分批转换
• 操作维护
  • 可维护性指标
    • 可理解性
    • 可测试性
    • 可修改性
  • 系统维护分类
    • 更正性维护：为了纠正和识别软件中的错误、改正软件功能和性能上的缺陷、排除在运行过程中的误使用，进行的诊断和改正错误的过程叫作改正性维护。
    • 适应性维护：在软件使用过程中，外部环境和数据环境都有可能发生变化。为使软件适应这种变化而修改软件的过程叫作适用性维护。
    • 完善性维护：在软件的运行过程中，用户往往会对软件提出更进一步的功能与性能要求。为了满足这些要求，开发人员需要修改、再开发软件，以扩充软件功能、增强软件性能、提高软件的可维护性。这种情况下进行的维护活动叫作完善性维护。
    • 预防性维护：指预先提高软件的可靠性和可维护性等,为以后进一步改进软件打下基础。采用先进的软件工程方法对需要维护的软件进行设计、编码和测试。
• 系统移植
  • 移植工作阶段
    • 计划阶段：在计划阶段，要从移植技术、系统内容、系统运行三个方面，探讨如何转换成新系统，确立移植工作体制及移植日程，决定移植方法。
    • 准备阶段：在准备阶段要进行移植方面的研究，准备软件转换所需的资料。该阶段的工作质量对以后的软件运行效率产生很大的影响。
    • 转换阶段：这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度、减轻下一阶段的测试负担是提高移植工作效率的基本内容。
    • 测试阶段：这一阶段是进行工作单元、程序单元的测试。在本阶段要核实程序在新系统中能否准确地工作。
    • 验证阶段：这是最后测试完的程序，使新系统开始正式工作，最后核实系统，准备正式运行。
  • 系统移植工具
    • 分析工具
    • 生成工具
    • 转换工具
    • 数据应用工具
    • 测试验证工具
    • 管理工具

架构师的管理实践

VRAPS组织管理原则

1. VRAPS组织管理原则是为实践软件架构的管理原则而提出的
   • V构想原则(Vision)：向受益人描述未来图景
   • R节奏原则(Rhythm)：定期根据可预测的进度、内容和质量进行检查和规划
   • A预见原则(Anticipation)：预测未来与现状之间做出平衡
   • P协作原则(Partnering)：如何识别并确保合作伙伴的有效支持
   • S简化原则(Simplificattion)：了解架构最小的基本特征并最小化架构
2. 构想原则与其他原则之间的交互关系：构想原则确立了系统的总体方向，使节奏原则提出的协调工作顺利进行。构想原则中的假设又根据预见原则来进行一系列的验证和测试。协作原则中合作伙伴的约束又是一个良好的构想原则的关键要素。所有原则之间都是彼此影响的。
   

概念框架

• 准则：用于判断每项原则的实施效果，说明是否和如何执行原则的问题
• 模式：在开发和使用软件中可能遇到的基本常见问题和解决问题的方法，能够帮助组织来更好地改进原则
• 反模式：组织在事件中可能遇到的各种陷阱，描述了不该做的事，可以帮助更深入地理解原则

构想原则

1. RUP的“4+1 架构视图”
   • 逻辑视图(Logic View):
     • 核心内容：描述系统的功能需求，即系统提供给最终用户的服务。它关注系统的静态结构，包括类、接口、包、模块等，以及它们之间的关系。
     • 表达方式：通常使用UML中的类图、交互图、时序图等来表示。
     • 关注点：系统的功能分解、模块划分、接口定义等，确保系统能够满足用户的功能需求。
     • 使用者：主要面向最终用户和系统分析师，帮助他们理解系统的功能架构。
   • 实现视图(Implementation View):
     • 核心内容：描述软件在开发环境下的静态组织，即软件的模块划分、包结构、库依赖等。它关注如何将逻辑视图中的功能模块映射到具体的实现单元。
     • 表达方式：通常使用UML中的组件图、包图等来表示。
     • 关注点：软件的模块化、可重用性、可维护性等，确保软件能够高效、可靠地开发出来。
     • 使用者：主要面向软件开发人员，指导他们进行软件的编码和集成。
   • 进程视图(Process View):
     • 核心内容：描述系统的并发性和分布性，即系统在运行时的行为。它关注进程、线程、节点、通信方式等，以及它们之间的同步和交互。
     • 表达方式：通常使用UML中的活动图、序列图等来表示。
     • 关注点：系统的性能、可用性、可伸缩性、容错性等，确保系统能够在多用户、高并发的情况下稳定运行。
     • 使用者：主要面向系统集成人员和性能测试人员，帮助他们评估系统的运行特性。
   • 部署视图(Deployment View):
     • 核心内容：描述系统的部署和配置，即软件如何映射到硬件上。它关注硬件、网络、服务器、存储等物理资源，以及软件在这些资源上的布局和交互关系。
     • 表达方式：通常使用UML中的部署图来表示。
     • 关注点：系统的可部署性、可管理性、安全性等，确保系统能够在目标环境中稳定运行。
     • 使用者：主要面向系统工程师和运维人员，指导他们进行系统的安装、配置和维护。
   • 用例视图(Use case View):
     • 核心内容：描述系统在不同情景下的使用场景，即用户与系统的交互过程。它关注用户界面、用例场景、用户需求等，以及这些场景如何驱动系统的设计和实现。
     • 表达方式：通常使用UML中的用例图和活动图来表示。
     • 关注点：系统的功能需求、用户交互、业务流程等，确保系统能够满足用户的实际需求。
     • 使用者：主要面向分析人员和测试人员，帮助他们理解系统的行为需求，并进行系统的验证和测试。同时，用例视图也是其他四个视图的重要输入，它确保了系统设计的一致性和完整性。
2. 将构想原则实践：准则到模式、反模式的映射

   准则——如何度量	反模式——不该做的	模式——该做的
   架构师的构想与发起人、用户和最终用户期望实现的目标是否保持一致	风险后置	前后一致
   实施人员是否信任并使用架构	墙头草(反复变化)	三个臭皮匠(集思广益)
   关于架构和构件的潜藏知识对其用户是否可见、可获得的	一叶障目	轮转工作

节奏原则

1. 节奏是一个架构团体的内部及架构团体与供应者、客户等之间重复出现的、可以事先预测的一系列活动。有三个组成要素：速度、质量和内容
2. 将节奏原则付诸实践：准则到模式、反模式的映射

   准则——如何度量	反模式——不该做的	模式——该做的
   项目经理定期再评估、同步和调整架构	一步成功(忌讳企图一次到位)	发布委员会
   架构用户对架构发布的进度和内容具有高度的信心	超敏捷(不可反应过于迅速)	舍兵保帅(抓大放小、聚焦核心)
   通过节奏协调明确的活动	销售未检验的产品	同步发布

预见原则

1. 预见、验证和调整的定义
   • 预见是架构人员根据实际运行的情况、变化的技术、客户的需求来预测、验证和调整架构的程度。
   • 验证不仅局限于传统软件工程的测试，还包括对架构的测试。
   • 调整包含架构本身，也包含构架思想。
2. 将预见原则付诸实践：准则到模式、反模式的映射

   准则——如何度量	反模式——不该做的	模式——该做的
   不断增强架构的能力向：（1）预见到的风险、架构客户要求；（2） 市场驱动的标准和演变的技术	遗漏细节	示范区
   战略性业务方向的改变，通过快速复审和开发周期，评估技术和业务上的风险与机会	半生不熟	架构复审
   当认识到关键的估计或假设有错时，及时调整功能特性、预算	赌奇迹	外包

协作原则

1. 协作是架构的受益人保持一个明确的、合作的角色,并将其所提供和获得的价值最大化的程度。成功的协作不仅仅是对架构负责人而言的，合作伙伴也必须采取行动，来确定和提供预期的价值，给出特定问题的解决办法。
2. 将协作原则付诸实践：准则到模式、反模式的映射

   准则——如何度量	反模式——不该做的	模式——该做的
   架构师不断努力了解谁是最关键的受益人、他们如何贡献价值以及他们需要什么	光说不做	了解受益人干系人
   受益人之间达成明确和强制性契约	不记录讨论结构	互利互惠
   通过社会行为制度和非正式规范强化合作	非正式时间做正式工作	杜绝意外、与HR等部门密切合作

简化原则

1. 简化是指架构师对所作用组织和环境进行巧妙地理解和最小化。简化之前，必须对组织和架构进行澄清。
2. 将简化原则付诸实践：准则到模式、反模式的映射

   准则——如何度量	反模式——不该做的	模式——该做的
   开发人员长期不断地使用架构，减少了总成本和复杂性	简单复制并修改	由慢而快
   架构小组明确理解关键最小需求并且将其构造成多应用共享地核心元素	缺乏有效抽象	迁移途径
   通过长期地预算和行动确保当相关元素没有被共享、增加了不必要的复杂性时，或者是因为有明确的业务理由时，把相关元素从核心移走	编码大于架构	统计构件变更

层次式架构设计

体系结构设计

软件体系结构：软件体系结构为一个软件系统提供了行为、结构和属性的高级抽象，主要由元素描述、元素的相互作用、知道元素的集成模式以及模式约束组成。
主要从以下三方面考察：
1. 利益相关人员之间的交流
2. 系统设计的前期决策
3. 可传递的系统级抽象
设计原则：
1. 在设计初始时，设计者应该尽量控制层次化的程度，有核心层、汇聚层、接入层三个层次就足够了，太多的层次会造成系统冗余，导致网络性能的下降，增加网络的延迟。
2. 接入层:应当严格控制网络结构的保持，接入层的用户是为了获得更大的网络访问带宽随意申请其他的渠道来访问外网是不允许的。
3. 不能在设计中加入额外连接，可以保证网络的层次性，额外连接会导致网络中出现各种故障。
4. 在进行设计时，接入层的设计是首位的，根据流量、行为和对流量负载的分析，对上层数据进行容量规划，再依次完成各层的设计。
5. 其他层次应尽量采用模块化方式，但不包括接入层。模块与模块之间的边界应非常清晰。

表现层框架设计

1. MVC模式设计表现层。主要有模型(Model)、控制器(Controller)、视图(View)三个核心模块。使用MVC设计表现成优点：
   1. 允许多用户界面的扩展
   2. 易于维护
   3. 适用于功能强大的用户界面
      
2. 表现层动态生成设计思想：基于XML的界面管理技术
   

中间层架构设计

• 业务逻辑层组件设计
  • 接口
  • 实现类
• 业务逻辑层工作流设计
  • 过程定义导入/导出接口
  • 客户端应用程序接口
  • 应用程序调用皆苦
  • 工作流机协作接口
  • 管理和监视接口
• 业务逻辑层实体设计
  • 业务逻辑层实体表示为XML的优点
    • 标准支持
    • 灵活性
    • 互操作性
  • 业务逻辑层实体表示为通用DataSset的优点
    • 灵活性
    • 序列化
    • 数据绑定
    • 排序与过滤
    • 与XML的互换性
    • 开放式并发
    • 可扩展性
• 业务逻辑层框架
  • Domain Model是领域层业务对象
  • Service是业务过程实现的组成部分
  • Control服务控制器

数据访问层设计(持久层架构设计)

1. 五种数据访问模式：
   • 在线访问
   • Data Access Object.DAO是标准J2EE设计模式之一。有以下组件：一个DAO工厂类； 一个DAO接口； 一个实现了DAO接口的具体类； 数据传输对象。
   • Data Transfer Object
   • 离线数据模式
   • 对象/关系映射(Object/Relation Mapping)
2. Hibernate设计思想
   

数据架构规划与设计、标准BS分层式结构

1. 数据库设计与XML设计融合。XML文档的存储方式：
   1. 基于文件的存储方式。
   2. 数据库存储方式，
2. 标准的BS分层结构
   

企业集成架构设计

企业集成平台

1. 企业集成平台(Enterprise Integration Platform，EIP)技术是近年来用于企业信息化系统集成的一种先进的软件技术。经过多年的发展，企业集成平台可以实现企业资源共享和集成。
   
2. 企业集成平台基本功能：
   1. 通信服务。
   2. 信息集成服务。
   3. 应用集成服务。
   4. 二次开发工具。
   5. 平台运行管理工具。
3. 实现技术发展趋势
   1. 集成技术实现了从2层到N层的过渡。
      
   2. 集成支持的方式面向过程集成、服务集成。
      • 面向过程集成：主要是采用工作流管理方式对业务过程逻辑和应用逻辑进行分离，来实现建模过程、数据、功能的分离。
        
      • 面向服务集成：主要是为支持大范围内的公共业务过程集成而提出的一种动态集成方式。
        
   3. 集成规范的标准化程度提高。
      4.集成粒度及耦合度的变化。

企业集成平台的实现

1. 数据集成(企业集成平台首要目的)主要三种模式：数据联邦、数据复制和基于接口技术的数据集成。
   
2. 应用集成四种模式：适配器集成模式、信使集成模式、面板集成模式、代理集成模式。
3. 企业集成主要有三种模式：前端集成模式、后端集成模式和混合集成模式。

企业集成的关键应用技术

1. 常见数据交换格式有：电子数据交换技术(Electronic Data Interchange, EDI)、可扩展标记语言(Extensible Markup Language，XML)、产品模型数据交互规范(Standard for the Exchange of Product Model Data, STEP)、包描述标记语言(Packet Description Markup Language, PDML)。
2. 分布式应用集成基础框架
   1. CORBA公共对象请求代理体系结构的核心是对象请求代理，支持对象服务，通用设施领域接口、应用接口之间的交互和通信
      
   2. COM+是一个开放的组件标准，包括结构化存储、统一数据传输、智能命名等。
   3. J2EE(Java 2 Platform Enterprise Edition)很好地融合了 Internet 技术，有利于建立基于Web、具有 N层结构的分布式应用。
   4. WebService(Web服务)将应用部署在 Web上来提供服务。

面向整体解决方案的企业模型

1. 选择参考模型的步骤
   1. 确定企业建模的基本需求和建模
   2. 划定建模范围
   3. 提出候选模型
   4. 确定最终使用模型
2. 参考模型实例化的具体操作方法
   1. 继承
   2. 剪裁
   3. 细化
   4. 扩充
   5. 修改
3. 企业模型演化的生命周期
   

面向方面的编程

方面编程的概念

1. 面向切面编程(Aspect Oriented Programming，AOP)是面向对象编程(Object Oriented Programming，OOP)的补充。AOP引入“横切”的技术，解开封装。主要技术有：
   1. 连接点技术(joint point)
   2. 切入点技术(point cut)
   3. 通知技术(adivce)
   4. 方面技术(aspect)
   5. 引入技术(introduce)
2. AOP的程序设计步骤
   1. 将系统需求分解，产生普通关注点、横切关注点。
   2. 单独完成每一个关注点的编码和实现。
   3. 用联结器指定的重组规则将组件代码进行组合，最终形成系统
3. 当前AOP技术有：AspectJ、AspectWerkz、JBossAOP、SpringAOP

AspectJ、Spring AOP

1. AspectJ：Aspect既是一个语言的规范,也是一个AOP的语言实现,是从Java语言中扩展而来的。AspectJ是目前已知最好的、应用最广泛的 AOP 实现。
2. Spring AOP：Spring的架构性有效地组织了中间层对象，是一站式解决方案，定位于典型应用的大部分基础结构，应用对框架的依赖性最小。

嵌入式系统设计

6~10分

嵌入式系统基础

1. 基础概念
   1. 嵌入式系统：一种以应用为中心、以计算机技术为基础，可以适应不同应用对系统、可靠性、成本、体积、功耗等方面得要求，集可配置，可裁剪得软、硬件为一体得专用计算机系统，它具有很强得灵活性，主要由嵌入式硬件平台、相关支撑硬件、嵌入式操作系统组成。嵌入性、专用性与计算机系统是嵌入式系统得三个基本核心要素。
   2. 嵌入式系统特点：① 专用性强； ② 实时性强； ③ 软、硬件依赖性强； ④ 处理器专用； ⑤ 多种技术紧密结合；⑥ 系统透明； ⑦ 系统资源受限。
2. 系统基本结构
   
   • 系统软件和应用支撑软件是基础
   • 应用软件是最能体现整个嵌入式系统得特点和功能得部分。
   • 微处理器是整个嵌入式系统得核心，负责控制系统得执行。
   • 外部设备是嵌入式系统与外界交互的通道
   • 嵌入式系统中经常使用的存储器有三种类型：RAM、ROM(Read-Only Memory, 只读内存)和混合存储器
   • 系统的存储器用于存放系统的程序代码、数据和系统运行结果
3. 嵌入式操作系统
   
4. 嵌入式数据库管理
   1. 嵌入式数据库也称为移动数据库或嵌入式移动数据库，其作用主要是解决移动计算环境下数据的管理问题。移动数据库是移动计算环境中的分布式数据库。
   2. 嵌入式数据库使用环境的特点：
      • 设备随时移动
      • 网络频繁断接
      • 网络条件多样化
      • 通信能力不对称
   3. 嵌入式数据库管理系统的组成：
      
5. 嵌入式网络
   
   1. 现场总线是一种低带宽的底层控制网络，位于生产控制和网络结构的底层，因此被称为底层网(Infranet)，主要应用于生产现场。
   2. 采用双绞线、电力线或光纤等作为总线，把多个测量控制仪表连接成网络
   3. 短程无线网主要包括IEEE 802.11、蓝牙、IrDA及HomeRF等。无线Internet或移动Internet主要采用两种无线连接技术：一种是移动无线接入技术，如GSM、GPRS、CDPD(Cellular Digital Packet Data)等；另一种是固定无线接入技术，如微波、扩频通信、卫星及无线光传输等。

嵌入式系统设计

1. 开发模型与设计模型
   1. 常用开发模型：
      1. 瀑布模型：
         1. 需求分析阶段：确定目标系统的基本特点
         2. 系统结构设计阶段：将系统的功能分解为主要的构架
         3. 编码阶段：程序编写和调试
         4. 测试阶段：检测错误
         5. 维护阶段：主要负责修改代码以适应环境的变化，并改正错误、升级。各个阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动，是一个理想的自顶向下的设计模型。
      2. 螺旋模型。
      3. 逐步求精模型：逐步求精模型是一个系统被建立多次，第一个系统被作为原型，其后逐个将系统进一步求精。
      4. 层次模型：
   2. 开发过程：项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段
      • 硬件抽象层是位于操作系统内核与硬件电路之间的接口层，其作用在于将硬件抽象化。它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。
      • 嵌入式实时操作系统(BTOS)实时性：影响的因素有常用系统调用平均运行时间、任务切换时间、线程切换时间、信号量混洗时间(指从一个任务释放信号量到另一个等待该信号量的任务被激活的时间延迟)、中断响应时间等
      • 嵌入式实时操作系统(BTOS)可靠性：看门狗
      • 嵌入式实时操作系统(BTOS)体系结构
   3. 嵌入式开发领域核心技术：处理器技术、IC技术、设计/验证技术
2. 嵌入式系统开发环境与设计模型
   • 与嵌入式操作系统配套的开发环境：如PalmOS、THOS、VxWorks、Windows CE 等商业嵌入式操作系统都有与其配套的功能齐全的开发环境。
   • 与处理器芯片配套的开发环境：处理器厂商提供
   • 与具体应用平台配套的开发环境：具体平台公司提供
   • 其他类的开发环境：基于开源基础上开发的通用环境

面向服务的架构

3~6分

SOA的特性

基本的web服务协议

• UDDI(Universal Description Discovery and Integration, 统一描述、发现和集成):提供了有一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用。UDDI规范描述了服务的概念，同时也定义了一种变成接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。UDDI包含以下三个部分：
  • 数据模型：UDDI数据模型是一个用于描述业务组织服务的XML Schema。
  • API：UDDI API 是一组用于查找或发布UDDI数据的方法，UDDI API基于SOAP。
  • 注册服务：UDDI注册服务是SOA中的一种基础设施，对应着服务注册中心的角色。
• WSDL(Web Service Description Lauguage, Web服务描述语言):是对服务进行描述的语言，它有一套基于XML的语法定义。WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。样例：通信协议，跨平台
• SOAP(Simple Object Access Protocol, 简单对象访问协议):定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用(Remote Procedure Call， RPC).SOAP 主要包括以下四个部分：封装、编码规则、RPC表示、绑定。
  1. 底层传输层。底层传输层主要负责消息的传输机制，HTTP、JMS(JavaMessagingService，Java 消息服务)和SMTP 都可以作为服务的消息传输协议，其中 HTTP 使用最广。
  2. 服务通信协议层。服务通信协议层的主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是SOAP和REST协议。
  3. 服务描述层。服务描述层主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是 WSDL。
  4. 服务层。服务层的主要功能是将遗留系统进行包装，并通过发布的WSDL 接口描述被定位和调用。
  5. 业务流程层。业务流程层的主要功能是支持服务发现、服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。
  6. 服务汪册层的主要功能是便服务提供者能够通过 WSDL 发布服务定义，并支持服务请求
     者查找所需的服务信息。相关的标准是 UDDI。
• BPEL(Business Process Execution Language For Web Services)的意思是面向 Web 服务的业务流程执行语言,也有的文献简写成 BPEL4WS。它是一种使用 Web 服务定义和执行业务流程的语言使用 BPEL,用户可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构(SOA)。BPEL提供了一种相对简单易懂的方法,可将多个 Web服务组合到一个新的复合服务(称作业务流程)中。

SOA的用途

• 把应用和资源转化成服务
• 把服务变成标准的服务，形成资源的共享

SOA的设计原则

• 明确定义的接口。服务请求者依赖于服务规约来调用服务。
• 自包含和模块化
• 粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低
• 松耦合
• 互操作性

SOA的实施过程

1. SOA业务实施过程：首先进行SOA解决方案选择，然后进行业务流程分析。
2. SOA实施之前考虑三原则：
   1. 尽可能选择全局规划的方案
   2. 充分考虑企业需求
   3. 从平台、技术进行考察
3. 业务流程分析方法：自顶向下分析法、业务目标分析法、自底向上分析法。

信息系统项目管理

2~6分

项目管理基础

1. 项目是为提供一项独特产品、服务或成果所做的临时性努力。

2. 项目特点：临时性； 独特的产品、服务和成果； 逐步完善； 资源约束； 目的性。

3. 项目工作的三个目标(三约束)：时间、成本和质量。

4. 项目经理的责任就是在时间、成本、质量和项目范围之间进行权衡以保证项目的成攻。

5. 日常运作和项目区别：

   • 日常运作是持续不断和重复进行的，而项目是临时性、独特的。
   • 项目和日常运作的目标有本质的不同。项目的目标是实现其目标，然后结束项目；而持续进行的日常运作的目标一般是维持经营。
   • 项目的实现机制与日常运作大相径庭，应为当宣布的目标实现时，项目即结束。

   不同点	项目	日常运作
   目的	独特的	常规的，普遍的
   责任人	项目经理	部门经理
   持续时间	有限的	相对无限的
   持续性	一次性	重复性
   组织结构	项目组织	职能部门
   考核指标	以目标为导向	效率和有效性
   资源需求	多变性	稳定性

6. 项目管理就是把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求。

7. 项目管理师通过应用和综合诸如启动、计划、实施、监控和收尾等项目管理过程来进行的。

8. 管理一个项目包括：识别要求；确定清楚而又能够实现的目标； 权衡时间、成本、质量和项目范围方面互不相让的要求； 使技术规格说明书、计划和方法适合于各种各样项目干系人的不同需求与期望等。

9. 项目团队应当将项目置于其所处的文化、社会、国际、政治和自然的环节及其同这样环境之间的关系中加以考虑：文化与社会环境、国际与政治环境、自然环境。

项目管理知识体系构成

1. 项目管理知识体系：应用领域的知识、标准和规定； 项目环境知识；通用的管理知识和技能；软技能或人际关系技能；
   
2. 标准和规则的区别：
   • 标准：一致统一并建立的公共规则
   • 规则：政府等强力团体强制的要求
3. 管理团队要结合项目所在的行业、社会等背景条件综合考虑。

IPMP/PMP

1. 国际项目管理协会(International Project ManagementAssociation，IPMA) 1965 年,非赢利性组织。
2. 国际项目管理资质标准(IPMACompetenceBaseline，ICB)是IPMA 建立的知识体系。划分为28个核心要素和14个附加要素。

   ICB 的知识与经验
   核心要素（28个）	项目和项目管理	项目管理的实施
   	按项目进行管理	系统方法与综合
   	项目背景	项目阶段与生命期
   	项目开发与评估	项目目标与策略
   	项目成功与失败的标准	项目启动
   	项目收尾	项目结构
   	范围与内容	时间进度
   	资源	项目费用与融资
   	技术状态与变化	项目风险
   	效果度量	项目控制
   	信息、文档与报告	项目组织
   	团队工作	领导
   	沟通	冲突与危机
   	采购与合同	项目质量管理
   附加要素（14个）	项目信息管理	标准和规则
   	问题解决	谈判、会议
   	长期组织	业务流程
   	人力资源开发	组织的学习
   	变化管理	行销、产品管理
   	系统管理	安全、健康与环境
   	法律方面	财务与会计

3. 国际项目管理专业资质认证(International Project Management Professional,IPMP)是IPMA在全球推行的四级项目管理专业资质认证体系的总称。
4. 依据国际项目管理专业资质标准，针对项目管理人员专业水平的不同将项目管理专业人员资质认证划分为四个等级，即A级、B级、C级、D级，每个等级授予不同级别的证书。
5. 项目管理知识体系(Project Management BodyofKnowledge，PMBOK)是在 20 世纪 70 年
   代末被提出的。
6. PMBOK 指南每四年更新一次，2021年为第7版。分为十个知识领域:范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、干系人管理、采购管理、风险管理和整体管理。
7. PMP认证相当于IPMA的C级，有效期为三年

PRINCE2

1. PRINCE2 认证在国际认可度高

2. PRINCE2是基于流程的结构化项目管理方法。

3. PRINCE2的原则、主题和流程与PMBOK指南一致
   PRINCE2基于七项基本原则，这些原则是项目管理的基石，为项目经理提供了指导性的方向：

   1. 持续的业务验证：
      • 项目必须与其商业论证保持一致，确保项目在启动和每个阶段都具备商业可行性。
   2. 从经验中学习：
      • 项目团队应记录和分享经验教训，以改进未来的项目管理实践。
   3. 明确定义的角色和职责：
      • 每个项目成员都应清楚自己的角色和职责，以确保有效的沟通和协作。
   4. 分阶段管理：
      • 项目应分解为多个阶段，每个阶段都有明确的输入、输出和控制机制。
   5. 例外管理：
      • 设定明确的容差范围，当项目偏离计划时，采取适当的纠正措施。
   6. 关注产品：
      • 项目的交付物（产品）应明确界定，并确保其满足质量标准和客户需求。
   7. 根据项目环境剪裁：
      • 根据项目的具体需求和环境，对PRINCE2方法论进行裁剪，以提高项目的适应性和成功率。

   PRINCE2的主题涵盖了项目管理的关键方面，为项目经理提供了全面的指导：

   1. 商业论证：
      • 确保项目与其商业目标保持一致，并具备持续的商业可行性。
   2. 组织：
      • 定义项目团队的结构、角色和职责，以确保有效的沟通和协作。
   3. 质量：
      • 确保项目的交付物满足质量标准和客户需求。
   4. 计划：
      • 制定详细的项目计划，包括时间、成本、资源和质量等方面。
   5. 风险：
      • 识别、评估和管理项目风险，以降低项目失败的可能性。
   6. 变更：
      • 管理项目变更，确保变更得到适当的评估、批准和实施。
   7. 进展：
      • 监控项目的进展情况，及时发现问题并采取纠正措施。

   PRINCE2的流程涵盖了项目从启动到收尾的整个生命周期，确保项目能够成功交付价值：

   1. 项目准备（Pre-project）：
      • 确定项目的商业论证、可行性和初步范围。
   2. 项目启动（Starting Up a Project）：
      • 正式启动项目，制定项目章程和初步计划。
   3. 项目指导（Directing a Project）：
      • 项目高层管理者对项目进行指导和监督，确保项目与商业目标保持一致。
   4. 阶段控制（Controlling a Stage）：
      • 对项目的每个阶段进行监控和控制，确保阶段目标得以实现。
   5. 管理产品交付（Managing Product Delivery）：
      • 管理项目交付物的开发、测试和交付过程。
   6. 管理阶段边界（Managing Stage Boundaries）：
      • 在项目阶段之间进行过渡，确保下一阶段的顺利启动。
   7. 项目收尾（Closing a Project）：
      • 正式结束项目，进行项目总结和经验教训的记录。

4. PRINCE2 突出广泛性

5. PRINCE2 适用于有一定经验的用户

6. PRINCE2四要素：原则、流程、主题和项目环境
   

7. 项目管理委员会的活动涵盖在项目指导流程中，该流程从项目之前就开始，一直到(并包括)最终阶段。

组织结构对项目的影响

1. 以项目为基础的组织分类：
   1. 主要收入源自依照合同为他人履行项目的组织。
   2. 采用项目制进行管理的组织。
2. 组织结构

   表 22-3 组织结构对项目的影响

   组织类型 项目特点	职能型组织	矩阵型			项目型组织
   		弱矩阵型组织	均衡型组织	强矩阵型组织
   项目经理的权力	很小或没有	有限	小到中等	中等到大	大到全权
   组织中全职参与项目工作的职员比例	没有	0%～25%	15%～60%	50%～95%	85%～100%
   项目经理的职位	部分时间	部分时间	全时	全时	全时
   项目经理的一般头衔	项目协调员/项目主管	项目协调员/项目主管	项目经理/项目主任	项目经理/计划经理	项目经理/计划经理
   项目管理/行政人员	部分时间	部分时间	部分时间	全时	全时

3. 职能型组织
   
4. 弱矩阵型组织
   
5. 平衡矩阵型组织
   
6. 强矩阵型组织
   
7. 项目型组织
   
8. 复合型组织
   

信息系统项目的生命周期

1. 通用生命周期特征：
   1. 成本与人力投入呈现正弦曲线波动
      
   2. 风险与不确定性随着项目进行和生命周期的变化呈现递减状态
      
2. 阶段与阶段的关系又两种基本类型：顺序关系、交叠关系
   • 快速跟进：在交叠关系中，一个阶段在前一个阶段完成前就开始，可作为进度压缩的一种技术。
   • 阶段交叠可能需要增加额外的资源来并行开展工作，可能增加风险,也可能因尚未获得前一阶段的准确信息就开始后续工作而造成返工。

信息系统项目典型生命周期模型

1. 瀑布模型(适用于需求明确或很少变更的项目)：可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护六个阶段
   
2. V模型：V模型是基于瀑布模型升级后的模型。主张将测试融入到全过程中去。是一个对称的结构，非常明确地表明了测试过程中存在的不同级别，并且非常清晰地描述了这些测试阶段和开发阶段的对应关系。
   1. 单元测试。一般由开发人员来执行，首先设定最小的测试单元，然后通过设计相应的测试用例来验证各个单元功能的正确性。
   2. 集成测试。主要关注点是系统能够成功编译，实现了主要的业务功能，系统各个模块之间数据能够正常通信等。
   3. 系统测试。验证整个系统是否满足需求规格说明。
   4. 验收测试。从用户的角度检查系统是否满足合同中定义的需求或者用户需求。
      
3. V模型的特点：
   1. 主要思想是开发和测试同等重要，左侧代表开发活动，右侧代表测试活动。
   2. 针对每个开发阶段都有一个测试级别与之对应
   3. 测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应
   4. 适用于需求明确和需求变更不频繁的情形
4. 原型法：很难立即全面准确地提出用户需求的情况下，首先不要求对系统作全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，快速开发一个原型系统，然后通过反复修改来实现用户的最终的系统需求。特点：
   1. 实际可行。
   2. 具有最终系统的基本特征。
   3. 构造方便、快速，造价低。
5. 螺旋模型(演化软件模型):将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来，使得软件的增量版本的快速开发成为可能。螺旋模型的四个象限分别表示每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
   
6. 迭代模型的生命周期四个阶段:初始、细化、构造、移交，可进一步描述为周期(Cycle)、阶段(Phase)、迭代(Iteration)。核心工作流从技术角度描述迭代模型的静态组成部分，包括:业务建模、需求获取、分析与设计、实现、测试、部署。
   
7. 敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。换言之，就是把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成，在此过程中，软件一直处理可使用状态。
8. 敏捷开发原则：
   • 快速迭代
   • 测试人员和开发者参与需求讨论
   • 编写可测试的需求文档
   • 多沟通、尽量减少文档
   • 做好产品原型
   • 及早考虑测试
9. 喷泉模型:主要用于描述面向对象的开发过程，体现了面向对象开发过程的迭代和连续性
   • 描述：喷泉模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关功能在每次迭代中随之加入演进的系统。它允许各阶段的活动可以任意顺序进行，可以随时由一个阶段过渡到下一个阶段，并且在某一阶段（如设计阶段）中可以随时回到前一阶段（如分析阶段）进行修改。
   • 定义：喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。它认为软件的开发过程是多个开发周期的迭代过程，每个周期都包括需求分析、设计、实现和测试等阶段，但这些阶段并不是严格按照顺序进行的，而是可以并行或交替进行。
   • 特点：① 迭代性；② 无间隙性；③ 以对象为中心；④ 强调团队合作；⑤ 灵活性。

单个项目的管理过程

1. 项目管理各过程组成的五个过程组可以对应到PCCA循环“计划(Plan)一执行(Do)-检查(Check)-行动(Act)”循环，即戴明环

2. 项目管理过程组包括五个:启动过程组、计划过程组、执行过程组、监督与控制过程组、收尾过程组。

   1. 启动过程组定义并批准项目或项目阶段，包括“制定项目章程”和“识别项目干系人两个过程。
   2. 计划过程组定义和细化目标，并为实现项目而要达到的目标和完成项目要解决的问题范围而规划必要的行动路线。
   3. 执行过程组整合人员和其他资源，在项目的生命期或某个阶段执行项目管理计划。
   4. 监督与控制过程组要求定期测量和监控项目绩效情况，识别与项目管理计划的偏差，以便在必要时采取纠正措施，确保项目或阶段目标达成，
   5. 收尾过程组正式验收产品、服务或工作成果，有序的结束项目或项目阶段。

3. 项目管理五大过程组十大知识领域对照表

   知识领域	启动	计划	执行	控制	收尾
   项目整体管理	制定项目章程	编制项目管理计划	指导和管理项目执行	监控项目工作、整体变更控制	项目收尾
   项目范围管理		编制范围管理计划、收集需求、范围定义、建立WBS		范围核实、范围控制
   项目时间管理		编制进度管理计划、活动定义、活动排序、资源估算、历时估算、制定进度计划		进度控制
   项目成本管理		编制成本管理计划、成本估算、成本预算		成本控制
   项目质量管理		制订质量管理计划	质量保证	质量控制
   人力资源管理		制订人力资源计划	团队组建、团队建设、团队管理
   项目沟通管理		沟通规划	管理沟通	控制沟通
   项目风险管理		制订风险管理计划、风险识别、风险定性分析、风险定量分析、风险应对计划		风险监控
   项目采购管理		编制采购管理计划	实施采购	控制采购	结束采购
   项目干系人管理	识别干系人	编制干系人管理计划	管理干系人参与	控制干系人参与

信息技术服务知识

产品、服务和信息技术服务

1. 产品是可以满足人们需求的载体，是被生产出的物品
2. 服务和产品不同的特点：无形性(Intangibility)、不可分离性(Inseparability)、异质性(Heterogeneity)、易消失性(Perishability)。
3. 信息技术服务(InformationTechnology Service，IT 服务)：《信息技术服务分类与代码》(GB/T 29264-2012)供方为需方提供开发、应用信息技术的服务，以及供方以信息技术为手段提供支持需方业务活动的服务
4. IT服务包括产品维护服务、IT 专业服务、集成和开发服务、IT管理外包服务。

运维、运营和经营

1. 运行维护服务(OperationMaintenance Service)：《信息技术服务分类与代码》(GB/T29264-2012)采用信息技术手段及方法，依据需方提出的服务级别要求，对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务。
2. 运维阶段是内容最多、最繁杂的部分，是对信息系统提供维护和技术支持以及其他相关的支持和服务。
3. 运维阶段六类：《信息技术服务分类与代码》(GB/T29264-2012)基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类。
4. 运维能力模型：《信息技术服务运行维护第1部分:通用要求》(GB/T 28827.1-2012)模型定义了运维服务能力的四个关键要素:人员、资源、技术和过程。以及运维能力提升方法。
5. 运营：是对组织经营过程的计划、组织、实施和控制，是与产品生产和服务创造等密切相关的各项管理工作的总称
6. 运营强调以经营为中心，是投入产出的过程。运营管理的对象是运营过程和运营系统。运营过程不仅是一个投入、转换、产出的过程，也是一个价值增值的过程，它是运营的第一大对象。
7. 经营思想六个观念：市场观念、竞争观念、效益观念、创新观念、长远观念、社会观念。
8. 经营目标三个层次：
   1. 决定企业长期发展方向、规模、速度的总目标或基本目标
   2. 中间目标，分为对外与对内目标
   3. 具体目标，即生产和市场销售的合理化与效率目标
9. 经营目标分为战略目标和战术目标。
10. 制定目标原则:目标的关键性原则、目标的可行性原则、目标的定量化原则、目标的一致性原则、目标的激励性原则、目标的灵活性原则。
11. 经营计划特点:决策性、外向性、综合性、激励性。
12. 经营计划的任务:把经营目标具体化、分配各种资源、协调生产经营活动、提高经济效益。
13. 企业的经营管理，是指对企业整个生产经营活动进行决策、计划、组织、控制、协调，并对企业员工进行激励，以实现其任务和目标一系列工作的总称。

IT治理

1. 内涵：IT 治理就是在信息化过程中关于各方利益最大化的制度安排。
2. 信息化目标与企业战略目标保持一致。
3. 利益相关者和经营者共同的责任。
4. 风险管理：合理利用IT 资源，平衡成本和收益。
5. 目标：构建一个信息化的决策、实施、服务、监督等流程以及 IT相关的资源与企业战略和目标紧密关联，从而最大化提升企业价值的体系。
6. IT 治理的一个关键性问题是:企业的 IT 投资是否与战略目标相一致，从而形成必要的核心竞争力。

IT服务管理

1. 内部提供服务：传统IT服务管理由企业内部IT开发部门提供。
2. IT服务管理(IT Service Management, ITSM)：是一套帮助组织对IT 系统的规划、研发实施和运营进行有效管理的方法论。
3. ITSM核心思想：提供低成本、高质量的 IT 服务。这是一种以服务为中心的 TT 管理。
4. ITSM根本目标：以客户为中心提供IT服务，提供高质量、低成本的服务，提供的服务是可准确计价。
5. ITSM基本原理：第一次是“梳理”，第二次是“打包”。
6. ITSM的主要任务：是管理客户和用户的IT需求。

项目管理

1. 项目三层定义：
   1. 有待完成，且有环境和要求的任务
   2. 在一定组织内，用有限资源定时完成任务
   3. 任务满足一定性能、质量、数量、技术指标等要求。
2. 项目管理：一是管理活动；二是管理科学
3. 项目特性：临时性、独特性、渐进性、不确定性。
4. 项目阶段：项目启动、项目规划、项目执行、项目监控、项目收尾
5. 项目管理五个变量：时间、成本、质量、范围、风险。
6. 项目群是一种灵活的临时组织结构，用于协调、指导、监督一系列相关的项目和活动的实施情况，用以交付与组织战略目标相关的成果和收益。项目群管理关注项目群的组织和领导、收益管理、利益干系人管理和沟通、风险管理和问题解决、项目群计划编制与控制、商业论证管理、质量管理等。
7. 项目群组织结构形式分为：单类项目群组织结构(单客户项目群和单业务项目群)、多类项目群组织结构(多客户项目群和多业务项目群)、复合式组织结构。
8. 多类项目群组织结构需要项目群层级管理协调。
9. 项目群也具有其特色的生命周期，包括识别项目群、定义项目群、对项目群综合治理项目的组合管理、项目群的收益管理、项目群的收尾管理等。

质量管理理论

1. 质量三部曲：质量策划(计划)、质量改进(变好)、质量控制(保持)

2. 质量控制理论表

   表 质量控制常见理论

   戴明环	"策划（P）—实施（D）—检查（C）—检查处理（A）"管理循环是现场质量保证体系运行的基本方式，它反映了不断提高质量应遵循的科学程序
   质量三部曲	质量策划、质量改进和质量控制
   零缺陷	"第一次就把事情做对（即差错不一定必须发生）" "质量是免费的（即提高质量之效益可以大于其花费）" 质量不仅是一个控制系统，它更是一个管理功能
   六西格玛管理	六西格玛（6σ）是一个质量目标，达到这个目标就意味着如果做100万件事情，其中只有23.4件是有缺陷的

3. 质量策划内容：设定质量目标、确定达到目标的途径、确定相关的职责和权限、确定所需的其他资源、确定实现目标的方法和工具、确定其他的策划需求

4. 质量控制要点：质量控制范围包括生产过程和质量管理过程，质量控制的关键是使所有质量过程和活动始终处于完全受控状态，质量控制的基础是过程控制。

5. 质量保证要点：制订质量保证计划、过程与产品质量检查、编制质量保证工作报告和问题跟踪与持续改进。

6. 质量控制是质量改进的前提，质量改进是质量控制的发展方向，控制意味着维持其质量水平改进的效果则是突破或提高。质量控制是面对“今天”的要求，而质量改进是为了“明天”的需要。

7. PDCA七步法：明确问题、掌握现状、分析问题产生原因、拟定对策并实施、确认效果、防止问题再发生并标准化、总结。

8. DMAIC方法：定义(Define)、测量(Measure)、分析(Analyze)、改进(Improve)、控制(Control)五个阶段构成的过程改进方法。

9. 质量管理旧七工具表

   表 质量管理旧七工具

   统计分析表	利用统计表对数据进行整理和初步原因分析的一种工具
   数据分层法	将性质相同的、在同一条件下收集的数据归纳在一起，以便进行比较分析
   排列图	又称为帕累托图，是分析和寻找影响质量主要因素的一种工具。通过对帕累托图的观察分析，可抓住影响质量的主要因素
   因果分析图	是以结果作为特性、以原因作为因素，在它们之间用箭头联系表示因果关系
   直方图	又称柱状图，是表示数据变化情况的一种主要工具
   散布图	又叫相关图，是将两个可能相关的变量数据用点画在坐标图上，来表示一组成对的数据之间是否有相关性
   控制图	就是对生产或者服务过程的关键质量特性值进行测定、记录、评估并监测过程是否处于控制状态的一种图形方法

   

10. 质量管理新七工具表

    表 质量管理新七工具

    系统图法	是指系统地分析、探求实现目标的最好手段的方法
    关联图	就是把现象与问题有关系的各种因素串联起来的图形
    亲和图	也叫 KJ 法，是指把收集到大量的各种数据、资料，按照其之间的亲和性（相近性）归纳整理，使问题明朗化，从而有利于问题解决的一种方法
    矩阵图	是指从问题事项中找出成对的因素群，分别排列成行和列，找出其间行与列的相关性或相关程度大小的一种方法
    矩阵数据分析法	与矩阵图法类似。它区别于矩阵图法的是：不是在矩阵图上填符号，而是填数据，形成一个分析数据的矩阵
    PDPC 法	又称过程决策程序图法。它是在制订达到研制目标的计划阶段，对计划执行过程中可能出现的各种障碍及结果作出预测，并相应地提出多种应变计划的一种方法
    箭条图法	又称矢线图法。它是计划评审法在质量管理中的具体运用，使质量管理的计划安排具有时间进度内容的一种方法

11. 新旧工具差异：旧七种工具”的特点是强调用数据说话，重视对制造过程的质量控制;而“新七种工具”则基本是整理、分析语言文字资料(非数据)的方法，着重用来解决全面质量管理中PDCA循环的P(计划)阶段的有关问题。

信息安全管理

1. 信息安全管理体系(ISMS)是整个管理体系的一部分。它是基于业务风险的方法，来建立实施、运行、监视、评审、保持和改进信息安全的结构、方针政策、规划活动、职责、实践、程序过程和资源。

2. 信息安全的基本属性表

   表 信息安全的基本属性

   完整性	指信息在存储或传输的过程中保持不被修改、不被破坏、不被插入、不延迟、不乱序和不丢失的特性
   可用性	指信息可被合法用户访问并能按要求顺序使用的特性，即在需要时就可以取用所需的信息
   保密性	指信息不被泄露给非授权的个人和实体，或供其使用的特性
   可控性	指授权机构可以随时控制信息的机密性
   可靠性	指信息以用户认可的质量连续服务于用户的特性

3. 信息安全管理活动主要有:定义信息安全策略、定义信息安全管理体系的范围、进行信息安全风险评估、确定管理目标和选择管理措施、准备信息安全适用性申明。

4. 信息安全等级保护是我国在信息化推进进程中实施的对信息系统安全保护的基本制度、方法和策略

5. 等级保护的主要环节:定级、备案、安全建设整改、等级评测和安全检查。

   表 信息系统安全保护等级的划分

   等级	安全功能	保障/有效性	国家管理程度	对象
   一级	用户自主保护	基本保障	自主	中小企业
   二级	系统审计保护	计划跟踪	指导	政府机构业务用的一般系统，企事业单位内部生产管理和控制的信息系统
   三级	安全标记保护	良好定义	监督	基础信息网络、政府、重点工程、大型国企
   四级	结构化保护	持续改进	强制	国家政府机关的重要部门的信息系统重要子系统
   五级	验证保护	严格监控	专控	国家重要核心部门的专用信息系统

管理科学基础知识

3分

运筹学属于管理科学的一种，经常用于解决现实生活中的复杂问题，特别是改善或优化现有系统的效率。考试中大概有3分左右的题目出自运筹学。由于运筹学研究的内容十分广泛，本小时精选了一些基础的、难度不大的、多次出现的题目进行解析，供广大考生学习。尽管我们不需要掌握太多太复杂的运筹学方法，但学好运筹学有助于启发思维，对日后的工作、学习都会有一定的帮助。

最小生成树

最大流量

决策论

1. 乐观主义准则，也称为“最大最大准则”，其决策原则是“大中取大”。
2. 悲观主义准则，也称为“最大最小原则”，其决策原则是“小中取大”
3. 后悔值也称为“最小最大后悔值”，该决策法的基本原理为:将每种自然状态的最高值(指收益矩阵，如果是损失矩阵应取最低值)定为该状态的理想目标，并将该状态中的其他值与最高值相比,所得之差作为未达到理想的后悔值。为了提高决策的可靠性,在每一方案中选取最大的后悔值，再在各方案的最大后悔值中选取最小值作为决策依据，与该值所对应的方案即为入选方案。

灵敏度分析

线性规划

动态规划

知识产权与标准规范

3分

知识产权的基本范围

广义的知识产权包括著作权、邻接权、专利权、商标权及商业秘密权、防止不正当竞争权、植物新品种权、集成电路布图设计权和地理标志权等。狭义的知识产权就是传统意义上的知识产权，包括著作权(含邻接权)、专利权、商标权三个主要组成部分。

知识产权的特性

1. 无体性：知识产权的对象没有具体形体，不能用五官触觉去感受，是一种抽象财富。
2. 专有性：知识产权的专有性指除权利人同意或法律规定外，权利人以外的任何人不得享有或使用该项权利。
3. 地域性：知识产权的地域性是指知识产权只在授予其权利的国家或确认其权利的国家产生,并且只能在该国范围内受法律保护，而其他国家则对其没有必须给予法律保护的义务。
4. 时间性：知识产权一旦超过规定的法律期限，相关知识产品即成为整个社会的共同财富,为全人类共同使用。

知识产权的内容

1.著作权与邻接权。
* 著作权也称版权，是指基于文学、艺术和科学作品依法产生的权利。
* 邻接权是与著作权相关的权利，指作品传播者在作品的传播过程中依法享有的权利，如艺术表演者、录音录像制品制作者、广播电视节目制作者依法享有的权利。
* 著作与邻接权的保护期为50年
2.专利权：专利权是国家按专利法授予申请人在一定时间内对其发明创造成果所享有的独占、使用和处分的权利。
* 发明专利的保护期限是20年
* 实用新型和外观设计专利的保护期限都是10年
3. 专利侵权人应该承担的法律责任有:停止侵权、公开道歉、赔偿损失。
4. 商标权，注册商标的有效期为10年，需要继续使用的，应当在期满前6个月内申请续展注册:在此期间未能提出申请的，可以给予6个月的宽展期。每次续展注册的有效期为10年。。：下列标志不得作为商标注册:
* 仅有本商品的通用名称、图形、型号的。
* 直接表示商品的质量、主要原料、功能、用途、重量、数量及其他特点的。

著作权法

商标法

商标法实施条例

计算机软件保护条例

软件工程国家标准

1. 《信息技术软件工程术语》(GB/T 11457-2006)

   表 《信息技术 软件工程术语》(GB/T 11457-2006)

   序号	术语	解释
   1	验收准则	软件产品要符合某一测试阶段必须满足的准则，或软件产品满足交货要求的准则。
   2	验收测试	确定一系统是否符合其验收准则，使客户能确定是否接收系统
   3	需方	从供方获得或得到一个系统、产品或服务的一个机构。需方可以是买主、拥有者、用户、采购人员等
   4	活动	一个过程的组成元素。对基线的改变要经过有关当局的正式批准
   5	审计	为评估是否符合软件需求、规格说明、基线、标准、过程、指令、代码和标准或其他的合同计特殊要求是否恰当和被遵守，以及其实现是否有效而进行的活动
   6	代码审计	由某人、某小组或借助某种工具对源代码进行的独立的审查，以验证其是否符合软件设计文件和程序设计标准。还可能对正确性和有效性进行估计
   7	配置审计	证明所要求的全部配置项均已产生出来，当前的配置与规定的需求相符。技术文件说明书完全而准确地描述了各个配置项目，并且曾经提出的所有更动请求均已得到解决的过程
   8	认证	一个系统、部件或计算机程序符合其规定的需求，对操作使用是可接受的一种书面保证。例如，一个计算机系统是安全的允许在定义的环境中操作的书面的认可；为使系统获准投入运行性使用，对系统遵循规定的需求是可接受的所做的正式演示；验证系统或部件遵循规定的需求，且其操作使用是可接受的过程
   9	走查	一种静态分析技术或评审过程，在此过程中，设计者或程序员引导开发组的成员通读已书写的设计或编码，其他成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准等方面进行评论
   10	鉴定	一个正式的过程，通过这个过程确定系统或部件是否符合它的规格说明，是否可在目标环境中适合于操作使用
   11	基线	业已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理步骤方能加以修改的规格说明或产品；在配置项生存周期的某一特定时间内，正式指定或固定下来的配置标识文件和一组这样的文件。基线加上根据这些基线批准统一的改动构成了当前配置标识。对于配置管理，有以下三种基线：功能基线（最初通过的功能配置）、分配基线（最初通过的分配的配置）、产品基线（最初通过的或有条件地通过的产品配置）
   12	配置控制委员会	对提出的工程上的更动负责进行估价、审批，对核准进行的更动确保其实现的权力机构
   13	配置管理	标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性；对下列工作进行技术和行政指导与监督的一套规范；对配置项的物理功能和物理特性进行标识和文件编制工作；控制这些特性的更动情况；记录并报告对这些更动进行的处理和实现的状态
   14	配置状态报告	记录和报告为有效地管理某一配置所需的信息。包括列出经批准的配置标识表、列出对配置提出更动的状态表和经批准的更动的实现状态
   15	设计评审	在正式会议上，将系统的初步的或详细的设计提交给用户、客户或有关人士共其评审或批准；对现有的或提出的设计所做的正式评估和审查，其目的是找出可能会影响产品、过程或服务工作的适用性和环境方面的设计缺陷并采取补救措施，以及（或者）找出在性能、安全性和经济方面的可能的改进
   16	桌面检查	对程序执行情况进行人工模拟，用逐步检查源代码中有无逻辑或语法错误的办法来检测故障
   17	评价	决定某产品、项目、活动或服务是否符合它的规定的准则的过程
   18	故障、缺陷	功能部件不能执行所要求的功能
   19	功能配置审计	验证一个配置项的实际工作性能是否符合它的需求规格说明的一项审查，以便为软件的设计和编码建立一个基线
   20	功能测试	忽略系统或部件的内部机制只集中于响应所选择的输入和执行条件产生的输出的一种测试。有助于评价系统或部分与规定的功能需求遵循性的测试

2. 《信息技术软件生存周期过程》(GB/T8566-2007)

   表 《信息技术软件生存周期过程》(GB/T8566-2007)

   过程名		主要活动和任务描述
   主要 过程	获取过程	定义、分析需求或委托方进行需求分析而后认可；招标准备；合同准备以及验收
   	供应过程	评审需求；准备投标；签订合同；制订并实施项目计划；开展评审及评价；交付产品
   	开发过程	过程实施；系统需求分析；系统结构设计；软件需求分析；软件结构设计；软件详细设计；软件编码和测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装及软件验收支持
   	运作过程	过程实施（制订并实施运行计划）；运行测试；系统运行；对用户提供帮助和咨询
   	维护过程	问题和变更分析；实施变更；维护评审及维护验收；软件移植及软件退役
   支持 过程	文档编制过程	设计文档编制标准；确认文档输入数据的来源和适宜性；文档的评审及编辑；文档发布前的批准；文档的生产与提交、储存和控制；文档的维护
   	配置管理过程	配置标志；配置控制；记录配置状态；评价配置；发行管理与交付
   	质量保证过程	软件产品的质量保证；软件过程的质量保证，以及按 ISO 9001 标准实施的质量体系保证
   	验证过程	合同、过程、需求、设计、编码、集成和文档等的验证
   	确认过程	为分析测试结果实施特定的测试；确认软件产品的用途；测试软件产品的适用性
   	联合评审过程	实施项目管理评审（项目计划、进度、标准、指南等的评价）；技术评审（评审软件产品的完整性、标准符合性等）
   	审核过程	审核项目是否符合需求、计划、合同、以及规格说明和标准
   	问题解决过程	分析和解决开发、运行、维护或其他过程中出现的问题，提出相应对策，使问题得到解决
   	易用性过程	过程实施，以人为本的设计（HCD）、策略、推广和保障方面的人为因素
   组织 过程	管理过程	制订计划；监督计划的实施；涉及到有关过程的产品管理、项目管理和任务管理
   	基础设施过程	为其他过程所需的硬件、软件、工具、技术、标准，以及开发、运行或维护所用的各种基础设施的建立和维护服务
   	改进过程	对整个软件生存周期过程进行评估、度量、控制和改进
   	人力资源过程	过程实施、定义培训需求、补充合格的员工、评价员工绩效、建立项目团队需求、知识管理
   	资产管理过程	过程实施、资产存储和检索定义、资产的管理和控制
   	重用大纲过程	启动、领域标识、重用评估、策划、执行和控制、评审和评价
   	领域工程过程	过程实施、领域分析、领域设计、资产供应、资产维护

3. 《信息技术软件包质量要求和测试》(GBT17544-1998)

   1. 产品描述的要求:产品描述定义产品。每个软件包应有一个产品描述。产品描述是产品软件包文档的一部分，它提供关于用户文档、程序及数据(如果有的话)的信息。
      产品描述的主要目的是：
      • 帮助用户或潜在的购买者作出产品是否适用于他们的评价。从这一意义上说，产品描述也是销售信息。
      • 作为测试的基础。
   2. 用户文档的要求:用户文档应包含产品使用所需信息。在产品描述中说明的所有功能以及在程序中用户可调用的所有功能，都应在用户文档中加以完整的描述。
      用户文档中应再次说明产品描述中给出的所有边界值。
      如果安装能由用户来完成，则用户文档应包括安装手册，该手册包含所有必要的信息。安装手册宜说明一次安装的最小文卷和最大文卷。
      如果维护能由用户来完成，则用户文档应包括程序维护手册，该手册包含各种有关该软件维护所需要的信息。
      测试记录包括：
      • 测试计划或包含测试用例的测试规格说明。
      • 与测试用例相关的所有结果，包括在测试期间出现的所有失败。
      • 测试中涉及的人员身份。

4. 《信息技术软件产品评价质量特性及其使用指南》(GB/T16260-2006)
   GB/T 16260.1-2006中提出了软件生存周期中的质量模型
   

   GB/T 16260.1—2006 定义了 6 个质量特性和 21 个质量子特性

   功能性	可靠性	易用性	效率	维护性	可移植性
   适合性 准确性 互用性 依从性 安全性	容错性 易恢复性 成熟性	易学性 易理解性 易操作性	时间特性 资源特性	可测试性 可修改性 稳定性 易分析性	适应性 易安装性 一致性 可替换性