|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（5）确定和配置管理有关的项目干系人并确定其介入时机。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求。管理一个项目包括：
|
|
|
|
|
|
|
|
.权衡质量、范围、时间和成本方面的要求，使技术规格说明书、计划和方案适合于各干系人的不同需求与期望。
|
|
|
|
|
|
除了专门的项目管理技术以外，项目管理组至少应能理解和使用以下5方面的知识领域：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
项目管理体系是指用于管理项目的工具、技术、方法、资源和规程。项目管理计划说明如何使用项目管理体系。
|
|
|
|
|
|
|
|
.社会环境：经济、人口、教育、道德、种族、宗教和其他特征等。
|
|
|
|
|
|
|
|
|
|
项目管理办公室（PMO）是在管辖范围内集中、协调地管理项目的组织单元。也可指“大项目管理办公室”、“项目办公室”或“大项目办公室”。PMO监控项目、大项目或各类项目组合的管理。由PMO管理的项目不必要有特定的关系，PMO关注与上级组织或客户的整体业务目标相联系的项目或子项目之间的协调计划、优先级和执行情况。
|
|
|
|
PMO执行的职责可以是一个宽广的范围，包括从以培训、软件、标准政策和规程、模板的形式提供项目管理支持功能，到实际直接管理项目和项目的结果。
|
|
|
|
|
|
|
|
.追求的目标不同。项目经理关注于特定项目的目标，而PMO管理主要的大项目范围的变化，并将之视为更好地达到业务目标的潜在机会，其工作目标包含组织级的观点。
|
|
|
|
.项目经理控制赋予项目的资源以最好地实现项目目标，而PMO对所有项目之间的共享资源进行优化使用。
|
|
|
|
.项目经理管理本项目的范围、进度、费用和质量，而PMO管理整体的风险、整体的机会和所有项目的依赖关系。
|
|
|
|
|
|
过程就是一组为了完成一系列事先指定的产品、成果或服务而必须执行的互相联系的行动和活动。
|
|
|
|
|
|
.面向管理的过程。即项目管理过程，其目的是启动、规划、执行、监控和结束一个项目。
|
|
|
|
.面向产品的过程。一般由项目生命期规定，并因领域而异。
|
|
|
|
项目管理过程和创造产品的过程从项目开始到结束始终彼此重叠交互。
|
|
|
|
任何项目都必须执行5个项目过程组，它们与应用领域或特定行业无关。过程组不是项目阶段，每一阶段或子项目都要重复过程组的所有子过程。
|
|
|
|
.启动过程组。定义并批准项目或阶段。在多阶段项目中，后续阶段进行的启动过程是为了确认在指定项目章程与拟定初步项目范围说明书过程中所做的原假设与决策的合理性。启动过程组也定义了项目意图，确定了目标，并授权项目经理进行项目。
|
|
|
|
.规划过程组。定义和细化目标，规划最佳的行动方案，即从各种备选方案中选择最优方案，以实现项目或阶段所承担的目标和范围。项目团队应让所有项目干系人参与项目计划过程。当项目计划工作结束时，不管是由组织还是由项目团队负责，都要有明确的指导方针，否则将无法确定如何进行后续的反馈和细化。项目管理计划的渐进明细经常被称作“滚动式计划”，这意味着计划是一个迭代和持续的过程。
|
|
|
|
.执行过程组。整合人员和其他资源，在项目的生命期或某个阶段执行项目管理计划。
|
|
|
|
.监控过程组。要求定期测量和监控项目进展，识别与项目管理计划的偏差，以便在必要时采取纠正措施，确保项目或阶段目标达成。
|
|
|
|
.收尾过程组。正式接受产品、服务或工作成果，有序地结束项目或阶段。
|
|
|
|
项目管理过程组和“计划-执行-检查-行动（即PDCA）”循环的对应关系如下图所示。
|
|
|
|
|
|
|
|
规划过程组与PDCA循环中的“计划”对应；执行过程组与循环中的“执行”对应；监控过程组与循环中的“检查”和“行动”对应。启动过程组是这些循环的开始，而收尾过程组是其结束。
|
|
|
|
|
|
项目管理过程组通过它们各自所产生的结果而联系起来——一个过程的结果或者输出通常会成为另一个过程的输入或者整个项目的最终结果。在项目过程组之间以及项目过程本身当中，这种联系是迭代的。
|
|
|
|
如果一个项目被划分成阶段，每个阶段中的过程经常会反复进行。项目中过程组的相互作用如下图所示。
|
|
|
|
|
|
|
|
5个项目过程组与44个项目管理过程及9个项目管理知识域的映射关系如下表所示。
|
|
|
|
|
|
|
|
注：1．在《信息系统项目管理师教程》中，“团队组建”被划分为规划过程组。在PMBOK 2004版中，“团队组建”在执行过程组中，笔者认为划分在执行过程组中更合理。
|
|
|
|
2．发包规划在《信息系统项目管理师教程》中也称为计划签约和编制合同。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
变更请求是关于修改任何文档、可交付成果或基准的正式提议。变更请求被批准之后将会引起对相关文档、可交付成果或基准的修改，也可能导致对项目管理计划其他相关部分的更新。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。变更请求可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的。
|
|
|
|
|
|
.纠正措施：为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
|
|
|
|
.预防措施：为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
|
|
|
|
.缺陷补救：为了修正不一致的产品或产品组件而进行的有目的的活动。
|
|
|
|
.更新：对正式受控的项目文件或计划等进行的变更，以反映出修改或增加的意见或内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
|
|
|
|
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
|
|
|
|
作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
|
|
|
|
如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
|
|
|
|
（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
|
|
|
|
（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
|
|
|
|
（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
|
|
|
|
另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
|
|
|
|
：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
|
|
|
|
信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
|
|
|
|
|
|
根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
|
|
|
|
为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
|
|
|
|
|
|
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
|
|
|
|
|
|
变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
|
|
|
|
|
|
配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
|
|
|
|
（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
|
|
|
|
（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
|
|
|
|
|
|
状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能随意修改，对基线的变更必须遵循正式的变更控制程序。
|
|
|
|
基线可以是一组拥有唯一标识号的需求、设计、源代码文件以及相应的可执行代码、构造文件和用户文档构成的产品，也可以是产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例与使用手册等）。基线需要定义的内容包括建立基线的事件，受控的配置项，建立和变更基线的程序，批准变更基线所需的权限。
|
|
|
|
基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release Baseline），内部开发使用的基线一般称为构造基线（Build Baseline）。
|
|
|
|
|
|
|
|
.新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
|
|
|
|
.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
|
|
|
|
.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
|
|
|
|
|
|
.开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
|
|
|
|
.受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
|
|
|
|
.产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
|
|
|
|
配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
管理信息系统是由人、计算机和管理规则等组成，以采集、加工、维护和使用信息为主要功能的人－机系统。例如金融、财会、经营、管理、教育、科研、医疗、人事、档案、物资等各方面都有大量的信息需要及时分析和处理，以便为决策提供依据。虽然在这方面应用中计算公式并不复杂，但数据量极大，在当今信息爆炸的时代，人工已难以胜任这一重任，计算机则成为信息管理的重要工具。该系统一般以数据库管理系统为核心，以其他软件和网络系统为支撑环境，而用户则通过专门的人机交互界面，进行数据的查询、修改等操作，并实现统计分析、规划、决策等功能。在信息管理方面，我们正经历着从单项事务的电子数据处理，向以数据库为基础的管理信息系统，及以数据库、模型库和方法库为基础的决策支持系统发展的过程，并且呈现出系统集成化、结构分布化、信息多元化、功能智能化等趋势。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.电子通信管理，如电子邮件、传真、语音信箱、电话、视频和网络会议、网站。
|
|
|
|
.项目管理电子工具，如基于网页界面的进度管理工具和项目管理软件，会议和虚拟办公支持软件，门户网站和协同工作管理工具。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ISO将质量定义为：“质量是反映实体满足明确和隐含需要的能力的特性总和”。我国国家标准GB/T1900—2000将质量定义为：“质量是一组固有特性满足要求的程度”。这些定义表明质量是通过实体来体现的，质量的实体可以是产品，也可以是某项活动或过程的工作质量，还可以是质量管理体系运行的质量。
|
|
|
|
ISO将质量管理定义为：“在质量方面指挥和控制组织的协调活动”。我国国家标准GB/T1900-2000对质量管理的定义是：“在质量方面指挥和控制组织的协调的活动”。在质量方面的指挥和控制活动，通常包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
|
|
|
|
我国国家标准GB/T1900—2000对质量保证的定义是：“质量保证是质量管理的一部分，致力于增强满足质量要求的能力”。也就是，质量保证是为了提供足够的信任表明实体能够满足质量要求，而在质量体系中实施并根据需要进行全部有计划和有系统的活动。
|
|
|
|
我国国家标准GB/T 1900—2000对质量控制的定义是：“质量管理的一部分，致力于满足质量要求”。质量控制的目标就是确保产品的质量能满足顾客、法律法规等方面所提出的质量要求，如适用性、可靠性和安全性。质量控制的范围涉及产品质量形成全过程的各个环节，如设计过程、采购过程、生产过程和安装过程。
|
|
|
|
项目质量管理是为了保证项目最终能够达到预期的质量目标而进行的一系列的管理过程。项目的质量管理可以分解为质量计划编制、质量保证与质量控制三个过程。
|
|
|
|
（1）质量计划编制。是指确定与项目相关的质量标准，并决定如何达到这些质量标准。
|
|
|
|
（2）质量保证。是定期评估总体项目绩效的活动之一，以树立项目能满足相关质量标准的信心。
|
|
|
|
（3）质量控制。是指监控具体的项目结果以判断其是否符合相关的质量标准，并确定方法来消除绩效低下的原因。
|
|
|
|
质量管理与项目管理是相辅相成的，例如质量管理和项目管理这两门学科都认识到以下几方面的重要性：
|
|
|
|
（1）顾客的满意程度。强调对顾客的需求深刻理解、认真评估、准确定义和严格管理，以便与顾客的期望相符。这就要求既符合要求（项目交付的产品要与它宣布将交付的产品相符）又适于使用（交付的产品或服务要满足实际需求）。
|
|
|
|
（2）预防胜于检查。强调预防比检查更重要。防患于未然的代价总是小于检查所发现错误的纠正代价。
|
|
|
|
（3）管理层的责任。成功需要项目团队全体成员的参与，然而提供取得成功所需的资源却仍然是管理层的职责。
|
|
|
|
（4）持续改进。计划、执行、检查和改进循环是质量改进的基础。执行组织采取的质量改进措施，不仅会改善项目管理的质量，而且也会改进项目产品的质量。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
质量管理计划是项目管理计划的组成部分，描述将如何实施组织的质量政策，以及项目管理团队准备如何达到项目的质量要求。
|
|
|
|
质量管理计划可以是正式或非正式的，非常详细或高度概括的，这取决于项目的具体需要。应该在项目早期就对质量管理计划进行评审，以确保决策是基于准确信息的。这样做的好处是，更加关注项目的价值定位，降低因返工而造成的成本超支金额和进度延误次数。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
质量审计是用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化的、独立的过程。质量审计的目标是：
|
|
|
|
|
|
|
|
|
|
.积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率。
|
|
|
|
|
|
质量审计还可确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预防措施）的实施情况。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）能够最大限度地满足招标文件中规定的各项综合评价标准。
|
|
|
|
（2）能够满足招标文件的实质性要求，并且经评审的投标价格最低。但是投标价格低于成本的除外。
|
|
|
|
评标委员会经评审，认为所有投标都不符合招标文件要求的，可以否决所有投标。依法必须进行招标的项目的所有投标被否决的，招标人应当重新招标。
|
|
|
|
在确定中标人前，招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。评标委员会成员应当客观、公正地履行职务，遵守职业道德，对所提出的评审意见承担个人责任。评标委员会成员不得私下接触投标人，不得收受投标人的财物或其他好处。评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况，以及与评标有关的其他情况。
|
|
|
|
中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知所有未中标的投标人。中标通知书对招标人和中标人具有法律效力。中标通知书发出后，招标人改变中标结果的，或者中标人放弃中标项目的，应当依法承担法律责任。招标人和中标人应当自中标通知书发出之日起30日内，按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。招标文件要求中标人提交履约保证金的，中标人应当提交。
|
|
|
|
依法必须进行招标的项目，招标人应当自确定中标人之日起15日内，向有关行政监督部门提交招标投标情况的书面报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
