转自:http://column.chinadaily.com.cn/article.php?pid=19312
一、项目组织架构
根据我们以往在项目管理和实施方面的经验,建议项目的组织机构如下设置:
图4-1项目组结构示意图
二、项目过程管理
2.1项目进度控制办法
本项目中我们将采用下列进度控制办法:
(1).合理划分项目任务
(2).根据技术人员情况进行合理分工
(3).采用并行开发和施工,本地化开发与工程实施并行进行。
(4).关注关键任务的进展
(5).每周进展分析报告
(6).里程碑进展状态评审
(7).加强原型技术预研
(8).计划提前评审和测试,尽早发现问题
(9).风险识别、跟踪与规避。
三、需求变更管理
3
3.1需求变更控制原则
(1)及时、反复、全面地评审需求,及早发现需求问题。
(2)测试尽可能早的参与项目需求工程。
(3)对于不能明确的需求可以进行原型探索。
(4)需求的变更尽量控制在早期阶段,需求阶段和概要设计阶段可以进行大量反复的需求变更,详细设计阶段可以进行部分需求变更,在编码阶段一般不能允许需求变更,需要实施严格控制。
(5)定量目标:需求阶段,需求变更率可以控制在20%左右,设计阶段控制在5%左右,编码及测试阶段控制在0%,即不能进行变更。如果一定要变更则根据变更流程可以改签或续签协议合同。
3.2需求变更管理流程
(1)项目的需求变更分两级控制:项目经理、CCB,项目经理可以直接决定影响轻微的需求变更。如果需求变更将引起资源、进度或软件质量的变化,则需要CCB共同协商确定、并由双方高级经理确认批准,否则不予变更。
(2)从变更申请到变更分析、确认、批准、处理直至完成,遵循公司NSP的变更处理规程,流程图如下图所示。
(3)首先对于发现的任何有关需求的问题,都必须形成文档化的变更申请,提交项目经理
(4)项目经理初步确认,如果风险很小,则可以直接决定是否变更,否则提交CCB。
(5)CCB评审讨论,进行影响分析,确定是否引起资源与约定的变更,如果没有影响,则协调项目组内部和相关组资源,进行变更。否则提交双方高级经理。
(6)双方高级经理协商考虑资源与约定的影响,决定是否批准变更。对于允许的变更需要签定增补合同,协调外部资源,并更新计划和约定。
(7)项目组和相关组处理并跟踪需求变更。
图4-2 需求变更申请流程示意图
3.3项目沟通管理
(1)沟通的顺畅和有效是保证项目进度按计划实施的关键,因此做好项目的沟通管理非常重要。
(2)在项目实施过程中建立项目沟通管理的目的是:
(10).识别项目实施过程中需要的信息;
(11).定义信息收集需要的资源;
(12).把信息流向、时间跨度、接收信息者和发生的频率进行文档化;
(13).选择信息有效流动的技术方法和载体。
(3)项目沟通管理主要包括:项目计划、沟通媒介、定期会议、报告、进度表、假设、依赖、风险和成本,以及其它。
3.4项目文档管理
为了使项目信息更好地共享,我们将根据局方情况设定项目文档电子化管理,使项目成员和有关人员能够依权限从中获得项目管理、项目成果、项目问题、变更、项目消息、联络信息、外来参考资料等信息和文档,同时在其权限范围内发布项目信息和输入项目文档、工作计划等。
为了有序的管理项目电子文档,这里规定项目文档按照以下方式进行管理。
(1)项目文档分类
我们把项目文档划分为以下类别:
(14).项目管理文档(项目管理标准、程序、状态报告、阶段总结、问题、变更等)
(15).质量报告
(16).需求报告
(17).测试文档(测试计划、案例、测试结果、测试接受等)
(18).培训文档
(19).开发文件(含源代码)
(20).系统设计与分析
(21).接口文档
(22).系统管理
(23).合同等
(24).会议安排和记录
(2)项目阶段
为了把项目文档与项目发生的时间或阶段联系起来,需要明确项目的阶段如下:
(25).项目准备
(26).需求分析
(27).系统设计
(28).应用开发
(29).测试
(30).部署与运行
(3)项目文档机密级别
定义项目文档机密级别如下:
保密、机密、绝密和公开
对项目文档机密的管理,要求此类文档必须记录机密级别,项目经理对查阅人员进行授权。对保密要求,见开发商与用户签署的保密协议。
(4)项目文档电子化管理处理说明
在项目组中设置项目行政管理人员,其职责之一是管理项目文档。各方把其交付的文档同意交付到项目行政管理人员,由其传至各个审核人员,得到批准或审核完毕,由项目行政管理人员发布到网络上,并根据浏览权限进行设置,注明机密级别、版本等。
对于绝密文件,不进行浏览授权,查阅文件需要得到用户方项目经理的特别批准。
如果项目文档存在更新版本,发布最新版本,并注明其有效性,同时说明以前版本作废。
不允许任何个人私自发布项目文档。
3.5系统测试和验收方案
3.5.1系统测试方案
为了确保该系统的质量,我们将采用科学的方法和业界最先进的测试技术与工具,对该系统进行严格、规范的系统测试。在系统正式交付用户使用前,我们将组织专业测试团队,分别对该系统的应用功能、应用性能进行测试。
本节描述了各项测试的目标、测试环境和我们将采用的测试工具、测试方法、测试指标体系、测试实施计划、测试报告形式和测试结果确认方式,系统测试实施前,我们将根据系统实施的实际情况和用户需求,确定最后的测试内容和制定更详细的测试实施方案,在经用户方审核同意后,实施具体的测试。
3.5.2项目验收方案
(1)验收标准
以招标文件、总体设计为基础,根据实际情况,从系统性能、系统功能两个方面,对应用软件制定相应的验收标准草案,经过评审通过后,形成正式的验收标准。
(2)验收环境准备
验收环境准备包括:
(31).验收数据的准备
(32).验收运行环境准备
(33).验收用例准备
(3)验收内容
系统完成测试运行后,我公司将拟制初验计划和验收内容,供用户确认。
1)应用软件。
2)应用软件源程序。
3)相关文档。
应用软件验收项目包括
(34).系统功能度;
(35).界面友好性;
(36).系统可靠性和安全性;
(37).容错性;
(38).可伸缩性。
应用系统文档验收包括:
(39).应用软件需求分析说明书;
(40).应用软件概要设计说明书;
(41).应用软件详细设计说明书;
(42).应用软件功能说明书;
(43).应用软件用户手册;
(44).应用软件安装手册;
(45).系统管理手册;
(46).系统安装手册;
(47).系统维护手册;
(48).应用系统源程序。
(4)验收程序
对系统的验收包括工程组内部验收、用户初步验收(初验)和用户最终验收(终验)三个阶段。工程组对应用软件的内部验收应按照相关规定,组织我公司技术委员会、行业咨询专家等对应用软件进行内部评审和验收。内部验收完成后,应用软件的初验和终验应履行正式手续,双方成立专门的验收委员会,负责组织、监督和裁决整个应用软件的验收过程。
依据甲方单位授予合同的相关条款要求,组织项目的用户最终验收。
四、项目风险分析
1、对于项目风险管理的定义:
内部风险管理计划是为了确定项目风险,定义出规避或缩小这些风险所采取的行动。为此,必须定义出所有已知的和潜在的项目风险,充分评估这些风险发生的可能性,并且指定出规避和管理这些风险的行动。
2、风险管理计划:
针对本项目,项目组经过对项目的技术,进度,预算等多方面内容的分析,初步定义以下的项目风险管理表:
表4-1 风险管理计划
序号
|
风险内容
|
风险概率
|
对项目的影响
|
规避风险行动
|
1
|
客户业务需求更改
|
50%
|
延误开发进度。
|
需求阶段确认需求,并进行协议控制,遵循需求变更流程;
|
2
|
人员流动性不可预测
|
30%
|
延误开发进度, 影响开发质量。
|
加强项目后勤管理;人力资源管理;充分考虑后备人力资源;关键工作安排两人以上执行。
|
3
|
开发过程中新的业务需求出现
|
20%
|
延误开发进度。
|
系统框架具有好的扩展性和适应性。
|
4
|
开发机器设备、运行主机设备不到货
|
5%
|
项目延后
|
提早规划,准备应急临时设备
|
5
|
开发环境故障
|
20%
|
项目数据丢失
|
数据备份,统一配置管理
|
6
|
天灾人祸等人力不可抗拒因素
|
0.1%
|
项目失败
|
与甲方协商处理方法
|