公司软件项目管理规范.doc
《公司软件项目管理规范.doc》由会员分享，可在线阅读，更多相关《公司软件项目管理规范.doc（24页珍藏版）》请在冰点文库上搜索。
公司软件项目管理规范
公司软件项目管理规范
V1.0
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件标识：
QD-RJ-A00-00
当前版本：
1.0
作者：
王重
完成日期：
2010年7月15日
研发中心软件项目管理规范
1.1.项目实施原则
Ø项目实施过程要遵守标准规范的项目管理体系进行
l项目执行的规范性是项目成功的保证。
l项目执行的规范性可以有效保证项目质量。
1.2.项目实施方法
金山顶尖在多年的应用软件项目实施过程中，积累了丰富的项目实施经验，曾先后组织实施了多个上千万元的复杂项目，同时也积累了丰富的项目实施经验。
1.2.1.管理目标与指导思想
l管理目标
以客户体验为中心，持续改进产品生产及交付过程，面向客户提供优质产品或服务,持续提高客户满意度。
l指导思想
通过持续的过程改进，逐步提高项目交付的产品（服务）质量与生产效率，更好的满足客户的需求，提升公司客户满意度。
1.2.2.质量保证体系
依据ISO9001:
2008的规定，金山顶尖质量体系文件划分为4层层级结构，自上而下分别为纲领性文件、制度性文件，作业指导性文件和质量记录模版，下级文件的制定和修改必须符合上级文件的要求，如下图所示：
手册、方针
过程文件
作业规范、指南文件
质量记录、模板文件
质量体系文件层次示意图
l第一级为质量手册和方针文件
质量手册和方针文件是公司质量管理及过程改进体系的纲领性文件。
它依据GB/T19001-2008质量管理体系要求、系统工程生产过程域的目标要求，规定了公司提供产品及服务的过程质量控制标准及其工作产品质量目标要求。
l第二级为制度性文件
制度性文件是规范公司生产管理过程的一系列规章制度和办法文件，它适用于公司所有部门，是公司所有员工工作沟通的平台，主要包括项目管理控制程序文件、软件及系统工程管理控制程序文件、销售管理控制程序文件、服务保障体系文件、客户满意及投诉管理体系文件以及其他业务支持体系文件。
l第三级为作业规范及指南文件
作业规范及指南文件是针对过程控制体系文件对公司各业务领域的作业规范要求制定的具体的设计、开发、实施、服务及运营保障管理作业说明书，是对过程控制体系文件的进一步细化和补充。
l第四级为质量记录及模版文件
质量记录及模版文件体现了ISO9001-2008的基本质量要求及过程质量控制要素，为公司员工执行作业程序提供了一系列的参考模板、质量记录和工具表单文件。
金山顶尖质量保障体系如下图示意表示：
质量体系文件构成图
1.2.3.软件开发实施管理流程
根据项目实施管理流程要求，金山顶尖应用软件开发项目划分为以下项目阶段：
1）项目启动阶段
开始标志：
项目经理任命书发布，表明进入项目启动阶段。
结束标志：
签订项目启动计划和项目启动会为标志。
2）项目策划阶段
开始标志：
签订项目启动计划为开始标志。
主要工作：
制定项目计划、召开项目外部启动会，并制定系统需求调研计划。
结束标志：
项目计划发布并经客户确认。
3）需求分析阶段
开始标志：
确认项目计划，开始需求调研为标志。
主要工作：
调研用户需求，完成用户需求说明书和系统规格说明书，并经过用户书面确认，编写系统验收标准并与客户达成一致。
如项目需要，制作系统原型。
结束标志：
系统规格说明书发布并经客户确认。
4）系统设计阶段
开始标志：
系统规格说明书发布并经客户确认。
主要工作：
根据确认后的系统规格说明书展开系统设计工作，编写系统设计说明书，通过评审后，根据项目需要编写详细设计说明书。
并根据系统规格说明书编写测试计划，包括《系统测试大纲》、《测试计划》、《测试用例》等内容。
结束标志：
设计说明书发布并经客户确认。
5）系统实现阶段
开始标志：
设计说明书发布并经客户确认。
主要工作：
根据设计要求，完成编码与单元测试，并完成系统集成测试。
结束标志：
项目系统版本封闭，经项目经理认可。
6）系统测试阶段
开始标志：
项目系统版本封闭，经项目经理认可。
主要工作：
公司软件测试部门执行系统测试，编写系统测试报告；设计人员根据情况修改设计文档，编制用户手册。
结束标志：
项目系统版本达到项目验收标准要求。
7）部署与试运行阶段
开始标志：
项目系统版本达到项目验收标准要求。
主要工作：
系统安装环境检查、系统安装调试、用户培训、根据系统试运行情况填写系统跟踪报告、编写系统维护手册等，如有初验收，须与客户签署“初步验收合格证书”。
结束标志：
签署系统试运行情况报告，或签署“初步验收合格证书”。
8）项目移交与总结阶段
开始标志：
签署系统试运行情况报告，或签署“初步验收合格证书”。
主要工作：
执行项目验收工作，签署项目验收报告，项目实施组将项目实施中的各类资产与资料移交相关单位，并签署项目移交报告，进行客户满意度调查。
完成项目总结报告。
结束标志：
签署项目验收报告、与技术工程部门签署项目移交报告。
项目进入售后服务支持阶段。
1.2.4.项目实施的质量保证
项目管理是项目过程和管理过程相结合的产物。
在项目推进过程中，通过在项目启动、项目计划、项目执行与控制、项目收尾各阶段对项目过程的合理管理与控制，不但可以确保客户需求的合理满足，也有利于交付质量合格的项目系统和项目进度与费用的有效控制。
金山顶尖采取以下措施用以保证软件开发项目的实施质量。
1）优化规范、建立范例，提高项目实施质量与效率
基于软件开发项目的阶段划分与项目人员角色分工，通过建立、优化贯穿于整个软件开发过程中的各种规范、范例，有效指导项目实施人员的分析、设计、编码与测试等各项工作，可以大大提高项目实施的工作质量与工作效率。
具体包括的规范有：
l软件开发规范
可行性分析规范（FS）
需求分析规范（RS）
功能说明规范（FSS）
用户界面规范（UIS）
总体设计规范（GDS）
详细设计规范（DDS）
程序编码规范（CS）
软件测试规范（TS）
l项目管理规范
填写项目立项报告
项目章程（项目约定）
任命项目经理
项目计划
项目状态报告
。
。
。
同时，通过各种规范范例的建立，可以有效知道项目实施人员开展项目实施工作。
2）责权清晰的多级管控体系，有利于将项目问题及早解决
在项目实施过程中，项目成员、项目经理、项目管理层与项目客户出于各自利益考虑，都会对项目范围、进展、质量与费用进行监控。
这些角色的责权利便构成了项目的多级管理控制体系。
典型项目的职责划分如下：
3）基于项目周报的进度控制
项目实施期间，项目成员、项目经理以及软件开发部门经理每周定时汇报项目情况，使公司在员工工作层面、单个项目层面和多个项目层面等三个层次有全面的掌握，便于项目进度的掌控与资源的协调。
项目周报包括：
软件开发部门经理：
项目状态周报
项目经理：
项目周报
项目成员：
员工工作周报
4）基于流程审批的项目变更管理
项目执行过程中，出现与项目计划不符的项目范围、进度、与费用的变化是正常现象，以上三项项目要素中任何一个要素的变化都会导致项目计划的变更。
为保证项目目标的实现，任何涉及上述内容的变化必须经过项目变更审批，方可执行。
1.3.项目测试规范
1.3.1.测试的范围与内容
系统测试范围主要包括以下内容：
用户界面测试：
验证用户界面是否符合操作习惯，是否符合合同技术附件的要求；
功能测试：
保证系统满足业务工作需要的功能，并正确执行预定的功能；
接口测试：
保证与其它系统或子系统的接口工作正常；
兼容性测试：
保证系统在各种可能的用户群众都可以正常使用，如，不同的操作系统、浏览器、数据库等；
负载测试：
保证系统在最大设计负载下运行平稳。
一个好的测试经验是让系统在超过最大设计负载25%的数据和处理负载下运行；
恢复测试：
保证备份和恢复程序工作正常，以及当系统遇到突发事件如断电、网络连接中断时对数据的正确处理。
一般来说，恢复程序的基本测试在系统测试开始时进行，然后在系统测试结束之前再进行进一步的恢复测试；
安全测试：
验证系统安全满足要求，必须是系统的合法用户才能登录并进行允许的相关操作。
由于安全是系统的基本功能，所以安全测试通常安排在系统测试的开始；
转换测试：
验证现有的数据能进行正确的转换。
通常情况下，在处理测试过程中转换的数据与新数据一起使用来验证数据转换的正确性；
文档测试：
验证系统的用户手册、安装手册、帮助信息等说明性文档的内容是否符合功能及易读、易理解；
性能测试：
验证系统满足性能标准（例如响应时间）。
系统测试可以由不同角色的用户来进行，如：
业务人员测试系统功能，技术人员测试系统性能等。
有些情况下，一些测试工作可以合并在一个测试中完成。
测试小组成员负责测试工作的准备、测试人员的协调、专业测试的执行以及测试结果的整理等。
1.3.2.系统测试方法
项目实施的过程中，系统测试将遵循“W”模型的测试方法。
如下图所示：
在整个项目实施过程中，测试工作将伴随项目实施的全过程。
在概要设计阶段，测试小组将根据最终明确的用户需求编写《系统测试大纲》、《测试计划》、《测试用例》。
在概要设计完成后，测试小组将根据《概要设计说明书》编制《集成测试用例》；
在详细设计完成后，测试小组将根据《详细设计说明书》编制《单元测试用例》；
在编码实现过程中，开发人员和测试人员将先后进行单元测试、集成测试
在系统测试阶段，测试人员进行系统测试、功能测试、性能测试、安装测试、业务流程测试。
在项目交付过程中，测试人员和客户方人员还需要进行验收测试。
1.3.3.测试工具
在项目实施过程中，测试管理工具使用的是TestDirector7.6，性能测试工具将使用LoadRunner8.0。
1）测试管理工具TestDirector7.6简介
TestDirector它是MercuryInteractive公司推出的基于WEB的测试管理工具，无论是通过Internet还是通过Intranet都可以以基于Web的方式来访问TestDirector。
TestDirector能够让用户系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。
TestDirector能够帮助用户维护一个测试工程数据库，并且能够覆盖用户的应用程序功能性的各个方面。
在项目的工程中的每一个测试点都对应着一个指定的测试需求。
TestDirector还为用户提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。
TestDirector还专门提供了一个完善的缺陷跟踪系统，它能够让用户跟踪缺陷从产生到最终解决的全过程。
TestDirector通过与用户的邮件系统相关联，缺陷跟踪的相关信息就可以被整个应用开发组，QA,客户支持，负责信息系统的人员所共享。
TestDirector提供了与MercuryInteractive公司的测试工具（WinRunner,LoadRunner,QuickTestProfessional,AstraQuickTest,QuickTestProfessionalforMySAP.comWindowsClient,AstraLoadTest,XRunner,VisualAPIandVisualAPI-XP）、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。
TestDirector能够与这些测试工具很好的无缝链接，为用户提供的全套解决方案选择来进行全部自动化的应用测试。
TestDirector会指导用户进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段。
通过整合所有的任务到应用程序测试中来确保你的客户收到更高质量的产品。
2）性能测试工具LoadRunner8.0简介
LR:
LoadRunner®是一种预测系统行为和性能的工业级标准性能测试负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。
通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
MercuryInteractive的LoadRunner能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。
LoadRunner是一种适用于各种体系架构的负载测试工具，它能预测系统行为并优化系统性能。
LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。
此外，LoadRunner能支持广泛的协议和技术，为用户的特殊环境提供特殊的解决方案。
1.3.4.系统测试流程
项目实施过程中，系统测试流程如下所示：
1）明确测试内容、测试标准及测试风险评估和避免措施
2）设计测试用例和数据
3）准备测试环境
4）测试执行，监控测试结果和改进测试过程
5）测试总结及缺陷跟踪，分析测试结果，给出测试报告，确定系统的可用性，对于测试发现的缺陷进行跟踪，确保缺陷最终被消除。
对于每一次测试，都需要形成《测试报告》，作为测试成果提交项目经理。
1.3.5.测试缺陷定义
根据国家的相关标准及金山顶尖的质量管理体系，项目缺陷严重等级共分为五级，具体如下：
缺陷分类
缺陷说明
备注
一级缺陷
Low
功能建议
操作建议
校验建议
说明建议
建议性的改进要求
二级缺陷
Medium
操作界面错误
打印内容、格式错误
删除操作未给出提示
长时操作未给出提示
界面不规范
使操作者不方便或遇到麻烦，但不影响执行工作功能的实现
三级缺陷
High
一般性的错误或功能实现有不完美处
影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动软件不属于更正办法
四级缺陷
Veryhigh
被测试功能不能正常实现
软件错误导致数据丢失
用户需求未实现
数据库发生死锁
数据库的表、缺省值未加完整性等约束条件
数据库连接错误
数据库中的表有过多的空字段
由开发人员分析原因并写出问题说明和解决办法；必须立即修改。
五级缺陷
Urgent
导致系统崩溃；
导致程序模块丢失；
业务流程出现断点；
内存泄漏；
导致死机。
由开发人员分析原因并写出问题说明和解决办法；必须立即修改。
1.3.6.测试标准
测试标准包括进行测试的标准、测试通过的标准以及中止测试（不通过）的标准。
1）测试进入的标准
测试计划经评审通过后；
测试用例经评审通过后；
申请测试提交单审核通过；
测试环境通过环境检查表验证；
2）测试通过的标准：
测试用例执行率达到100%
缺陷修复率不低于90%；
系统遗留的4、5级缺陷数为0；
3）测试中止（不通过）的标准：
近半数以上测试用例无法执行；
5级缺陷开发人员不能解决；
1.4.项目过程控制
根据项目里程碑定义和项目进度计划，在项目执行期间将采用基于里程碑评审的质量管理模式。
即从一个项目里程碑进入下一个项目里程碑需要经过项目评审委员会的评审，评审的内容包括管理评审和技术评审两项，只有通过评审才能进入下一项目阶段。
通过项目全过程的质量控制来保证交付系统的质量。
项目评审委员会由业主方代表、金山顶尖代表及聘请的专家组成。
本项目包括的具体里程碑评审环节如下：
项目计划确认
需求分析评审
系统设计评审
系统测试评审
分系统初验收
系统整体终验收
里程碑评审的时间为在里程碑任务完成后，由项目实施单位提出，项目业主应及时安排里程碑评审，确保项目进度不会因里程碑评审导致项目延期。
1.5.项目风险管理
风险管理是人们对潜在的意外损失进行辩识、评估、预防和控制的过程。
风险管理是对项目目标的主动控制。
首先对项目的风险进行识别，然后将这些风险定量化，对风险进行控制。
国际上把风险管理看作是项目管理的组成部分。
风险管理和目标控制是项目管理的两大基础。
金山顶尖一贯注重项目风险的识别，并根据识别的风险及时采取各种应对措施，将项目风险消除在萌芽状态，确保能够按时按质交付满意的系统与服务。
1.5.1.项目风险评估
所有可能危害项目的因素都称为风险。
被刻画为风险的事件最终可能发生也可能不发生。
人们对待风险有两种态度。
一种是被动态度，可比作救火模式。
另一种是主动态度，可比作防火模式。
风险管理属于防火模式，目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。
为了便于量化管理，我们给风险定义3个参数：
l风险严重性
指风险对项目造成的危害程度，例如可以划分为5个等级：
5－很严重，4－比较严重，3－中等，2－轻度，1－低微。
l风险可能性
指风险发生的几率，可以用百分比表示。
l风险系数
是风险严重性和风险可能性的乘积。
风险管理有4个主要活动：
风险识别，风险分析，风险减缓，风险跟踪。
4个活动循环执行。
风险的类别：
项目的风险包括商业风险、管理风险和技术风险等。
l商业风险
商业风险包括政治风险、市场风险、客户风险以及分包商风险等。
需要根据实际情况进行判断。
l管理风险
管理风险包括项目计划、项目团队以及公司领导及各部门支持的风险。
l技术风险
技术风险包括需求控制与开发的风险、综合开发能力（包括设计、编码和测试）风险等。
项目的实施过程中，可能存在着技术风险和管理风险，风险的具体内容以及对项目的影响详见下表：
序号
风险名称
风险
分类
风险描述
风险影响
概率
影响程度
风险
指数
1.
需求
风险
技术类
需求开发有局限，模块范围定义不合理，或模块业务需求分析不到位
项目后期反复修改，进度、成本增加
0.6
60
36
2.
测试
风险
技术类
由于测试与修改组织不利，造成测试周期拖延
质量、成本
0.6
30
36
3.
人力资源风险
管理类
项目组人员发生变动
项目进度超期
0.5
40
20
4.
编码
风险
技术类
代码质量失控
测试修改周期延长
0.4
40
16
5.
计划
风险
管理类
公司对项目组成员增加计划外任务安排，影响项目组原定计划的工作
项目进度延期
0.5
30
15
6.
开发
风险
技术类
底层关键技术改造无法在预订时间内完全实现
项目进度延期
0.5
30
15
注：
影响程度按人日估计。
1.5.2.风险控制过程
风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。
风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些风险的战略。
风险管理包括的活动如下图所示。
风险评价（riskassessment）是一个检查工程项目并识别潜在风险区域的过程。
可以通过列举通常的软件项目风险因素，如需求风险因素的办法来使风险识别（riskidentification）更加方便容易。
在风险分析中，应检查一些特定风险对项目可能造成的潜在后果。
风险分级（riskprioritization）有助你通过评价每项风险的潜在危害值，优先处理最严重的风险。
风险危害值（riskexposure）包括带来损失的可能性大小和潜在损失的规模。
风险避免（riskavoidance）是处理风险的一种方法：
尽量别作冒险的事。
如果你不承担任何项目，采用成熟而并非处于研究阶段的技术，或者将难以实现的特性都排除在项目之外你就可以避开风险。
但更常见的是，需要采取风险控制（riskcontrol）的方法来管理那些已被发现为高优先级的风险。
制定风险管理计划是一项处理具有一旦发生，影响较大的风险的计划，包括降低风险的方法、应急计划、负责人和截止日期。
应尽量避免让风险成为真正的问题，或即便问题发生了，也应尽量让其影响降低到最小。
风险不能够自我控制，所以风险解决方案就包括了降低、减少每项风险的执行计划。
最后，通过风险监控（riskmonitoring）来跟踪风险解决过程的进展情况。
这也是例外的项目状态跟踪的一部分内容。
监控可以很好了解降低风险工作的进展情况，可以定期地修订先前风险清单的内容和划分的优先级。
1.5.3.项目风险对策
根据以上风险分析，金山顶尖采取以下几个方面的措施，确保项目的顺利实施。
序号
风险名称
风险指数
风险应对策略
责任人
1.
需求风险
36
需求评审、同类产品对比
项目经理
2.
测试风险
36
优化测试修改工作流程，规范过程管理
测试负责人
3.
人力资源风险
20
确保项目组人员稳定，并招聘备选人员
项目部经理
4.
编码风险
16
制定并落实代码互查、走查制度
项目经理、QA
5.
计划风险
15
公司层面避免
金山顶尖副总
6.
开发风险
15
对关键技术排优先级，根据项目时间要求，分步骤推出可运行版本
项目经理
1.5.4.重点风险识别及防范
（1）系统调研风险
A、业务部门人员配合风险
［风险定义］
某些业务部门人员不配合调研，或者配合程度不够。
［解决策略］
加强沟通，耐心细致讲解调研的作用和目的，调研人员要发扬不怕苦不怕累不怕麻烦的作风，同时，还可增加调研次数，或者其它电话，邮件联系等方式，解决问题。
B、调研时间安排与实际时间冲突风险
［风险定义］
在调研进度安排中安排的某个部门的调研时间，而该部门由于某些原因在预定的时间内不能进行调研。
［解决策略］
从两个方面：
一个就是在制定调研计划的时候，对调研时间安排留有一定的裕度，这样，当出现这种风险时可以利用裕度时间从新调研。
另一个就是每天分析调研时间表上的时间安排和各个业务部门人员工作安排，加强沟通，一旦发现某个部门时间安排不上，可以及时和其它部门的调研时间做对调，尽量减少损失。
C、调研资料变更风险
[风险定义]
业务部门填写好的调研资料，突然提出要修改，比如，某些数据项不共享了，造成某些部门的调研数据经常改变，没法确认。
［解决策略］
对每次调研过程做记录，包括原始数据资料和谈话内容，避免事后不认帐的情况发生，同时，也可以为行政协调提供依据。
D、行政协调风险
[风险定义]
由于行政协调的原因，某些部门拒绝调研人员进行调研。
［解决策略］
首先还是继续行政协调，同时，修改调研计划，保证尽量减少对其它部门调研的影响，其次，如果协调不成功，则汇总所有行政协调不成功的业务部门情况，和用户一起，综合分析，决定不实施、暂缓实施或者其它解决办法。
E、其它系统调研风险
在调研过程中，还会出现其它不可预知的风险，需要开发方和用户方密切配合，及时采取适当的措施，尽量减少风险带来的负面影响。
（2）需求变更
[风险定义]
升级会员 