项目管理体系完整版1.docx
《项目管理体系完整版1.docx》由会员分享，可在线阅读，更多相关《项目管理体系完整版1.docx（66页珍藏版）》请在冰豆网上搜索。
项目管理体系完整版1
1项目管理方法
2
2.1项目管理原则
2.2
项目管理是指在执行质量保证体系的基础上，在人力资源和组织、计划、质量控制、资源协调、财务、风险控制等方面进行科学地管理，确保该项目如期、高质量地完成。
我公司在多年的软件开发过程中，不断吸取国际先进的项目管理理念，并结合自身的特点，形成了一整套行之有效的管理方法，并形成了标准、规范、受控的配套文档体系。
根据我公司的软件工程的管理规范要求，软件项目根据适用的生命周期模型分为开发项目和维护项目，根据项目所面对客户，分为产品研发和合同项目开发。
对于本项目而言，属合同项目开发，我们进一步按照本章开始时划分的阶段将之分解为两个子项目：
第一阶段以研发为主，属开发项目，第二阶段以推广、升级、维护为主，属维护项目。
下面我们从项目组织架构、软件生命周期模型、项目管理关键阶段、项目管理关键活动等方面细述对本项目的项目管理计划。
2.3组织架构
2.4
在一个大型系统集成项目中，为了保证工程的顺利进行，需要建立相应的开发和管理机构，其典型的结构如下图所示：
在项目实施的组织结构中，各小组的职责如下：
✧工程领导组
✧
是XX项目实施中双方协同工作的最高管理机构，是由参与工程的双方领导组成，对项目的重大事件进行决策并对项目全过程进行监督及协调，保障项目人、财、物力等基础资源，凡由双方人员参与的各组织机构均在其领导下工作并对其负责。
✧项目经理
✧
负责项目的实施，组织、协调并监督各工程组的工作情况及进度，对工程领导组负责，对具体方案具有决定权，并负责计划与控制、人员配置管理和工程进度等工作。
✧项目评议组
✧
由业务、运行维护以及各方面的专家组成，负责对项目的可行性、成本收益、进度、质量等进行评议作业。
✧质量控制组
✧
由用户主要负责部门的工作人员与承建方人员组成，直接对项目经理负责，对应用程序编制及测试过程、内容、结果进行审查和评估，具有质量否决权。
✧系统需求组
✧
由用户方主要负责部门的技术人员和相关部门的工作人员与承建方的技术人员组成，对系统各项业务需求做作出总体描述，提交技术和业务部门共同论证，形成正式业务需求。
✧总体设计组
✧
由用户方信息化技术负责人与承建方的技术专家、顾问咨询人员构成，负责系统结构设计、系统需求、技术管理、系统模块设计。
还包括对开发小组的协调等工作。
✧开发小组
✧
主要由承建方的技术工程师构成，负责子系统详细设计、编码等工作。
✧测试小组
✧
主要由承建方的技术人员构成，负责编写测试方案、系统测试及编写测试报告。
用户方的业务工作人员及技术人员协助对系统的运行进行测试。
✧系统集成组
✧
主要由承建方的技术工程师组成，负责系统硬件、网络、软件及开发工具技术支持、技术培训支持。
✧文档管理组
✧
主要由承建方的技术人员组成，完成整个项目过程中的所有文档、资料、技术报告、软件介质的管理。
✧后勤保障组
✧
主要由承建方的人员组成，负责合同管理、材料管理、后勤保障等。
上述组织及职责划分根据项目进展情况由工程领导组及项目经理负责启动并调整，在项目经理领导下各组由参与工程各方根据工程需要分配人员，各方应在项目实施阶段保持人员的稳定性，确保工程按计划实施。
2.5项目管理控制
2.6
项目管理是贯穿整个咨询项目的一项任务。
通过实施有效的项目管理，保证本咨询项目能够按工作范围要求、按时间、按质量完成。
在我公司的项目管理过程中包含以下这些关键性活动，每一个项目经理必须执行和良好的完成这些任务。
⏹项目计划、执行和监控
⏹
⏹制定周密完整的项目计划，定义项目任务、子任务及任务的依赖关系、顺序、时间、资源安排
⏹
⏹控制项目按计划执行，对出现的偏差做出必要的纠正措施
⏹
⏹监督、确认项目当前状态
⏹
⏹项目协调与沟通
⏹
⏹针对项目时间、进度、任务执行情况、资源、各方配合等方面协调项目组与用户项目组的关系；协调项目组内部关系
⏹
⏹每周召开项目组内部例会
⏹
✓针对项目计划、进度、任务完成情况、出现问题、各方配合等方面与用户方进行沟通，每周向用户方负责人提交书面项目情况通报；每两周与用户方管理层开一次项目协调会，通报项目状态，协调处理项目待解决问题；每月提交项目月度报告，汇报每月项目进展、下月计划、待解决问题等
✓
✓对于项目组无法解决的问题提交到双方管理层
✓
⏹风险管理
⏹
⏹制定风险防范计划
⏹
⏹监控项目情况，发现潜在风险
⏹
⏹评估、定义风险的范围、影响
⏹
⏹制定风险防范策略，执行风险防范措施
⏹
⏹质量管理
⏹
⏹制定并执行项目质量计划
⏹
⏹制定项目质量标准和规范
⏹
⏹制定项目质量流程
⏹
⏹组织项目质量活动，如设计文档审查、测试等
⏹
⏹监督项目质量标准和规范的执行情况；对出现的偏差作出适当判断，制定相应的纠正措施
⏹
⏹制定项目测试计划，保证测试执行的质量
⏹
⏹文档管理，包括文档命名、规范、版本的控制，文档归档和分发
⏹
⏹变更管理
⏹
⏹制定变更管理计划（任务、流程、责任、组织）
⏹
⏹变更识别、确认
⏹
⏹变更范围及其影响评估
⏹
⏹应变措施制定
⏹
⏹应变措施执行及记录
⏹
⏹其他
⏹
⏹定义项目组织结构、所需人员，有效组织全体项目成员投入项目工作中，保证项目资源的有效使用
⏹
⏹有效控制项目费用
⏹
⏹对项目全程执行我公司规定的涉密管理标准规范
⏹
其中进度控制管理、质量管理、风险管理、涉密管理由于其重要性而具有特殊意义，在以下各节加以描述。
2.6.1项目进度控制
2.6.2
2.6.2.1项目进度管理的原则
2.6.2.2
要求全体成员积极主动，在项目进展中，遇到问题主动找相关人员解决，若解决不得力而又确实属此人管的，则应及时向上一级反映，不得以任何借口推脱不按进度计划完成任务，除非确实是技术上不可解决的，即便如此，也应尽早汇报，以免影响整体进度。
2.6.2.3项目进度管理的方法
2.6.2.4
在开始实施项目时，项目经理必须根据任务情况做好进度安排计划，按周做计划以书面呈交项目协调委员会，以周为单位做计划以书面形式下达各组，各组分头安排落实到个人，组长或个人在接到计划书时，认为恰当，则签字；若认为不恰当，必须及时陈述理由，否则责任自负。
在计划时间到时，项目经理严格按照进度计划书验收。
在验收合格情况下，项目经理在原下达的计划书上签字，并结合完成任务情况给出一定的评价，将来作为奖励晋级的参照依据；若验收不合格，则责成3日内修正，若仍不能完成必须以书面形式说明理由，项目经理依情况处理。
在每次验收都合格或者在责成期限内都合格的情况下，若项目不能及时完成，则责任应在项目经理身上，项目经理必须以书面形式向项目协调委员会陈述理由。
2.6.2.5项目沟通机制管理
2.6.2.6
交流有助于解决问题，尤其是在研究开发、系统集成等项目组之间，具有更频繁和更公开交流过程的组织在新产品开发过程中比那些交流不太频繁和封闭的组织有更大的创新倾向。
针对本项目的特殊性——多方参与，沟通机制更为重要。
沟通畅通能融多方智慧，促进项目成功；沟通阻塞，则障碍重重、举步维艰，这方面我们是有教训的，也是有经验的。
项目实施组作为沟通畅通的领头羊，制订相关计划，定期举行项目组和用户的交流会，建立和保持与主要利益相关者的关系，做到双向沟通；定期安排项目组内部各小组之间的相互交流；在日常工作中，营造相互学习共同成长的氛围。
2.6.2.7资料文档的管理
2.6.2.8
为保证系统的建设和正常运行，我们将提供如下几类资料和文档。
一、产品类
●硬件资料
●
●系统软件及开发工具资料
●
●其他相应产品资料
●
二、工程类
●系统需求规格书
●
●逻辑设计文档
●
●系统结构设计文档
●
●数据库设计文档
●
●接口需求说明书
●
●接口设计文档
●
●程序详细设计说明书
●
●系统故障处理流程文档
●
三、计划与测试类
●项目开发与管理计划
●
●项目实施计划
●
●系统开发标准手册
●
●测试计划及测试标准
●
●测试结果报告
●
●验收计划及验收标准
●
●验收结果报告
●
四、技术支持与维护类
●应用系统用户手册
●
●系统操作员手册
●
●系统运行手册
●
●网络操作手册
●
●网络接口手册
●
●系统接口标准
●
●故障处理和恢复手册
●
上述各类文档资料由专人负责归档，后三类文档需经项目经理签字有效。
2.6.2.9项目实施规划
2.6.2.10
本阶段主要目标是制定项目的实施计划，详细项目计划的制定，定义主要的工作包、里程碑和项目进度安排。
内容如下：
开始标准
结束标准
项目文档
工作综述
项目文档签署
功能规范签署
分析阶段工作计划
技术体系结构签署
确定项目发起人
实施计划
确定项目关键成员，并制定时间表
用户需求定义、访谈、反馈、汇总
接收标准得到认可
用户需求文档得到确认和接受
编写项目设计
概要设计及详细设计文档得到确认和接受
项目编码
提交用户可以测试的系统
项目上线
用户验收系统
2.6.2.11需求调研与分析
2.6.2.12
2.6.2.12.1需求调研
2.6.2.12.2
1．业务需求调研
对电子税收信息管理系统的业务功能、用户情况、安全和性能需求进行全面的调研。
业务需求调研包括以下方面的内容：
Ø用户数；
Ø
Ø用户管理模式；
Ø
Ø系统的使用模式；
Ø
Ø系统功能需求；
Ø
Ø系统安全要求；
Ø
Ø系统管理需求；
Ø
Ø与其它系统的接口要求。
Ø
2．流程调研和确定
为更明确整个系统的实际需求和流程定义情况，依据以往的实施B/S/S结构系统的经验，应在具体的代码设计和开发前进行全面、细致、到位的流程调研和需求的确定，从而在实际的开发过程中能尽可能接近和达到用户的需求。
在整个调研过程中，开发公司将设计各种适合的流程和需求调研表格，用户可根据实际的情况和需求进行填写，对于一些特殊的情况，开发公司将另行向用户详细了解。
3．管理维护功能的调研和确定
管理维护功能的统计和查询功能要求较高，同时还需要导出和打印，需要对统计的要求和导出格式等功能进一步调研和明确。
2.6.2.12.3需求分析
2.6.2.12.4
本阶段任务主要是确定并定义问题区、客户的需求、项目范围、项目成功标准与客户接收标准。
1．定义实施范围
确定并定义项目实施的目标、范围和关键的成功要素。
2．需求分析
对用户需要达到的目标进行确定并文档化。
工作成果
格式
需求调查问卷反馈及汇总、分析
接收文档
用户需求文档签署
接收文档
功能规范
MSWord+图表
功能规范签署
接收文档
技术体系结构
MSWord+图表
技术体系结构签署
接收文档
项目实施计划
MSWord+MSProjectPlan
2.6.2.13系统设计阶段
2.6.2.14
电子税收信息管理系统的详细设计阶段主要包括如下工作内容：
1．系统结构的总体设计：
决定系统的总体结构，包括整个系统分哪些部分，各部分之间有什么联系以及已确定的需求对这些组成部分如何分配等方面。
2．数据结构的设计：
决定数据库系统的模式、子模式、关系以及数据完整性、安全性设计。
3．系统模块化设计：
设计出系统的详细模块设计文档。
4．制定初步的系统测试方案：
对系统测试的策略、方法和步骤等提出明确的要求。
2.6.2.15应用系统开发
2.6.2.16
在所有流程、需求、表格、统计信息等详细需求资料确定并得到用户方确认后，我公司将开始有计划、可估算的系统开发工作。
将预先根据收集的信息，制定清晰的开发进度和开发程度估算指标，同时与客户保持密切、有效的协调和沟通机制，确保在整个开发过程得到最好管理和控制。
2.6.2.17系统测试
2.6.2.18
在每个应用和功能完成时我公司都将先进行内部的测试工作，在通过我们内部的测试后，再将功能和应用提交北京地税；负责本次工作的负责部门进行初步测试，在相关部门和领导的安排和协调下组织最终用户进行试用前的测试，即对调试完毕的系统进行详细的系统功能测试、系统压力、稳定性、安全性测试，输出验收测试报告。
同时开始对相关的技术支持人员和业务人员进行维护和应用培训，初验合格将投入试运行。
测试阶段相关文档主要包括如下内容：
交付
格式
系统测试结果
MSWord+TestOutput
系统测试停止
接受文档
UAT结果
MSWord+TestOutput
UAT停止
接受文档
所有的文档
广泛兼容的文档
培训材料
产品培训指南
培训参加列表
MSWord
培训评估表
MSWord
项目停止
接受文档
2.6.2.19系统安装与试运行
2.6.2.20
本阶段的主要目标是完成设备的软件安装，系统联调，并着手验收手册、用户手册的输出。
2.6.3项目质量控制
2.6.4
2.6.4.1项目质量控制过程
2.6.4.2
本项目的质量管理不仅仅是项目开发完成后的最终评价，而且还要在“电子税收信息管理系统”开发过程中进行全面质量控制。
也就是说，不仅包括系统实现时的质量控制，也包括系统分析、系统设计时的质量控制；不仅包括对系统实现时的软件质量控制，而且还包括对文档、开发人员和用户培训的质量控制。
我公司的项目质量控制吸取了CMM的SQA思想，为项目的实施过程提供适当的可视化管理，并对开发过程和产品的进行审核。
2.6.4.2.1项目质量控制综述
2.6.4.2.2
在本项目中，我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的三种不同倾向或观点。
这三种倾向是：
产品运行、产品修改和产品转移。
我们可以采取以下步骤实施全面质量控制：
Ø实行工程化开发
Ø
在本项目整个的开发过程中，建立严格的工程控制方法，按照工程控制方法规范每一步开发流程，并要求每一个项目实施人员必须遵守工程实施规范。
Ø实行阶段性冻结与改动控制
Ø
在项目实施的每一个阶段末都要冻结一部份成果，作为下一阶段工作的基础，冻结的成果并不是不可以修改，而是在修改时需要经过一定的审批流程，并涉及到整个项目的开发计划调整。
Ø实行里程碑式的审查与版本控制
Ø
里程碑式的审查就是在整个项目生命周期的每一个阶段结束之前，都正式使用结束标准对该阶段的冻结结果进行严格的技术审查，如果发现问题，可以在本阶段内进行及时处理和解决。
Ø全面测试
Ø
对于本项，系统测试将采用整体测试，即从系统调研、系统分析设计、系统实现、系统文档输出等各个阶段进行全面细致的质量测试和控制，确保工程质量。
Ø实行面向用户参与的原型演化
Ø
高质量的开发和高性能产品的生产需要用户的实际参与和量身定做。
在本项目中，将采用用户参与的原型化方法进行需求调研和开发，即每一阶段都要进行原型设计并与用户共同讨论其与需求的偏离程度，并进行及时修正，保证工程的快速、高效率和高性能的开发。
2.6.4.2.3符合RationalUnifiedProcess的质量管理
2.6.4.2.4
质量管理的目的在于：
Ø对合格的质量确定适合的指标（基本指标）。
Ø
Ø确定用于质量评估的适当的评测方法。
Ø
Ø及早并尽可能有效地确定和妥善处理影响质量的问题。
Ø
质量管理贯穿RationalUnifiedProcess的所有工作流程、阶段和迭代过程。
一般来说，在整个生命周期内进行质量管理即是要使流程质量和产品质量达标，并对此进行评测和评估。
下面是每一工作流程在管理质量维度要强调的工作：
需求工作流程中的质量管理涉及：
分析需求工件集的一致性（工件标准和其他工件之间）；清晰性（向所有的股东、涉众和其他角色明白无误地传达信息），以及精确性（适当的详细程度和精确度）。
分析设计工作流程中的质量管理涉及：
评估设计工件集，包括评估设计模型从需求工件转变过来，再转换为实施工件的一致性。
实施工作流程中的质量管理涉及：
评估实施工件，并根据需求、设计和测试工件评估相应的源代码/可执行工件。
测试工作流程就是质量管理的过程，该工作流程的绝大部分工作都是为达到管理上述确定的质量目标而进行的。
环境工作流程，和测试一样，主要工作要为实现管理质量的目的而服务。
在此，可获得如何对流程进行最佳配置以满足需要的指导。
部署工作流程中的质量管理涉及：
评估实施和部署工件，并根据需求、设计以及将产品交付给最终客户所需的测试工件来评估相应可执行的部署工件。
项目管理工作流程包括对质量管理大部分工作的概述，涉及复审和审核开发流程的实施、遵守以及进展情况。
2.6.4.2.4.1产品质量
2.6.4.2.4.2
产品质量是正在由流程生产的产品的质量。
在软件开发中，产品是许多工件的聚合关系，其中包括：
已部署的可执行代码（应用程序、系统等），这可能是最显而易见的工件，因为项目通常是由于该工件才存在的。
也就是说，它是为客户（最终用户、股东、涉众等）提供价值的首要产品。
已部署的不可执行工件，包括用户手册和教程资料等工件。
未部署的可执行工件，如工件的实施集，包括已创建用于支持实施的测试脚本和开发工具。
未部署的不可执行工件，如实施计划、测试计划和各种模型。
由于很多工件都建立在其他工件的基础上，所以在某种程度上，所有工件的质量都是相关的。
因此，对每个工件的质量都应该评测和评估。
1．可执行工件的产品质量（部署的和未部署的）：
可执行工件是通过其需求来描述的，并表述为用例或补充需求（如销售、性能等）。
要评测并达到质量要求，必须了解这些需求并以清楚、简明和可核实（可测试）的方式陈述这些需求。
对于软件来说，测试角色不会将所有需求当作测试对象（如市场渗透或销售收益）。
对于那些将成为测试对象的需求来说，测试设计员必须能够指定一种方法来核实是否满足需求（正如已指定的）、没有偏离既定意图并且没有缺陷。
Ø产品质量是通过评测以下质量维度和评测产品是否满足这些维度的要求来决定的：
Ø
Ø可靠性：
已部署的代码在执行过程中的防故障（崩溃、挂起、内存丢失等）能力。
Ø
Ø功能：
已部署的代码按既定意图执行所需的用例。
Ø
Ø性能：
在实际的操作特征（如负载、强度和长时间运行）条件下，已部署的代码以及时和可以接受的方式执行和响应，并以可接受的方式继续运行。
Ø
对于每一维度，在测试的一个或多个不同阶段，应该实施和执行一种或多种测试类型。
此外，还可通过评测每一工件新版本的可执行工件中所作的变更数量和类型来评估产品质量。
2．不可执行工件的产品质量（已部署的或未部署的）：
不可执行工件的产品质量通过工件的目的、目标和结构来描述，并通过确保工件符合以下各项要求来评估：
Ø工件内部和工件之间的一致性（语言的使用、术语或语义等）。
Ø
Ø指南、标准和合同需求（语言的使用、术语、语义、格式或内容等）的兼容性。
Ø
此外，还可以通过工件版本之间所作变更的数量和类型来评估不可执行工件的产品质量。
为了帮助评估RUP中工件的产品质量，我公司运用了RUP中针对大多数工件的信息类型：
Ø工件指南和检查点：
有关如何开发、评估和使用工件的信息。
Ø
Ø模板：
工件的“模型”或原型，为内容提供结构和指导。
Ø
2.6.4.2.4.3流程质量
2.6.4.2.4.4
流程质量是指为了生成工件而对可接受的流程（包括质量评测和质量标准）实施和遵守的程度。
软件开发需要一张错综复杂的步骤网，其中既有串行步骤，又有平行步骤。
随着项目规模的扩大，必须包含更多步骤来管理项目的复杂性。
所有流程都由产品活动和日常管理活动组成。
产品活动会取得在形成最终产品方面的实际进展。
而日常管理活动对最终产品有着无形的影响，许多计划、管理和评估任务都需要进行日常管理活动。
对流程质量进行评测和评估的目的是：
Ø管理利润率和资源；
Ø
Ø管理和化解风险；
Ø
Ø管理和维护预算、进度与质量；
Ø
Ø获取可改进流程的数据；
Ø
在某种程度上，如果遵守流程并达到了较高的流程质量，这多少会在工件的质量上得以体现。
也就是说，如果遵守流程并达到较高的流程质量，生成低质量工件的风险就会降低。
但反之未必亦然：
生成高质量的工件并不一定表示遵守了流程。
因此，不仅要按照流程被遵循的程度来评测流程质量，还要按照流程中产生成果所达到的质量等级来评测流程质量。
一般而言，项目组每个人都应负责实施和遵守已得到认同的流程，并确保生成工件的质量达到已认同的质量标准。
不过，特定的角色（如项目经理）可能会执行特定的任务来判定和影响流程质量。
2.6.4.2.4.5评测质量
2.6.4.2.4.6
对质量（包括产品质量和流程质量）的评测需要收集信息并对其进行分析，这些信息通常以评测和指标来表述。
评测的目的主要是为了控制项目，以便能够管理项目。
评测还被用来评估项目在完成情况、质量情况、对需求的符合情况等方面与计划所设定目标之间的差距。
指标用来达到两个目标，即了解情况的目标和变更（或成果）目标：
Ø知识目标：
Ø
使用动词如评估、预测、监控来表述。
您要更好地了解开发流程。
例如，可能要评估产品质量、获得用来预测测试工作的数据、监控测试覆盖或跟踪需求变更等。
Ø变更（或成果）目标：
Ø
通过使用动词如增加、减少、提高或实现进行表述。
通常，您感兴趣的是，随着项目的进展事情如何从一个迭代到另一个迭代、从一个项目到另一个项目发生变更或得到改进。
使用这两个目标的指标来评测进度和产品质量。
所有指标都需要标准来标识并确定是否达到可接受的质量程度或级别。
可接受的质量级别是可以协商并可以变化的，需要在开发生命周期的初期被确定并认同。
例如，在早期的迭代中，可以接受较多的应用程序缺陷，但不能接受构架缺陷。
而在后期迭代中，只有应用程序中美观方面的缺陷才是可以接受的。
验收标准可以采用多种方式进行说明，并可以包括多种评测方法。
常见验收标准可能包括以下评测方法：
Ø缺陷数和/或趋势，如已确定、已解决或仍然打开（没有解决）的缺陷数。
Ø
Ø测试覆盖率，如（测试）计划、实施并执行的代码（或用例）的百分比。
通常，测试覆盖率要和上面确定的缺陷标准一起使用。
Ø
Ø性能，如发生指定操作（用例、操作或其他事件）所需的时间。
该标准通常用于性能测试、故障转移及恢复测试或其他测试，在这些测试中，时间危急程度是本质问题。
Ø
Ø相容性。
该标准表示工件或流程活动/步骤必须满足已认同的标准或准则的程度。
Ø
Ø可接受性或满意度。
该标准通常用于主观评测，如可用性或美观性。
Ø
1．评测产品质量
2．
以清晰、准确和可测试的方式说明需求只是达到产品质量的一部分。
还必须确定相应的评测和标准，用来确定希望达到的质量级别，并判断是否已经达到该质量级别。
评测说明如何获取用来评估质量的数据，而标准则确定产品达到可接受（或不可接受）质量的级别或点。
对可执行工件的产品质量进行评测是通过使用一种或多种评测技术实现的，例如：
Ø复审/走查
Ø
Ø检查
Ø
Ø执行
Ø
根据评测的性质和质量目标，将使用不同的指标。
例如，在复审、走查和检查中，首要目标集中在功能和可靠性质量等维度。
缺陷、覆盖率和相容性是在使用评测技术时采用的主要指标。
但是，执行则可能集中在功能、可靠性或性能上。
然而，缺陷、覆盖率或性能是所使用的主要指标。
其他评测和指
升级会员 