互联网IT行业项目管理规章制度全Word下载.docx
- 文档编号:16727128
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:16
- 大小:31.48KB
互联网IT行业项目管理规章制度全Word下载.docx
《互联网IT行业项目管理规章制度全Word下载.docx》由会员分享,可在线阅读,更多相关《互联网IT行业项目管理规章制度全Word下载.docx(16页珍藏版)》请在冰豆网上搜索。
依据公司业务开展及软件产品应用现状所提出的需求,均须遵循本制
度内容执行
1.需求分类:
(1)根据其紧急程度,分为紧急类需求和非紧急类需求;
(2)根据其实施优先级,分为紧急、高、中、低级四个级别;
2.审批流程
(1)需求申请人提交《产品需求申请单》(详见附件1)至业务归管部门进行业务评审,评审通过后,报至产品技术中心。
(2)产品技术中心根据产品需求进行分析,形成评审报告进行内部评审,评审通过后列入部门工作计划,并提交至公司中高决策层。
评审报告内容主要包括预计工作量和成本、风险、可行性分析等(详见附件2:
《产
品需求文档(PRD)模板》)。
(二)立项管理
经评审确认后的产品需求由产品技术中心提交公司中高决策层,讨
论通过后立项。
(三)项目计划与监控
对于产品需求,软件开发采用项目形式管理,项目经理负责整个项目的计划、组织、协调和控制。
技术总监配合项目经理、产品经理与项目干系人进行有效沟通,在项目目标、项目计划和工作方法上达成一致。
(四)系统设计
1.在系统设计阶段中,邀请用户或者业务一线人员充分参与,确保系统设计能满足系统需求。
2.项目组结合需求规格说明书或者系统原型,进行数据库设计和功能设计,并形成《DB设计书》。
项目组组织相关人员对核心功能的相关设计进行评审,出具《评审报告》,评审人员应对评审意见签字确认。
3.项目组进行详细设计,出具《单元测试案例》。
《详细设计说明书》
中,需要定义系统输入输出说明和接口设计说明。
4.详细设计评审和DB设计评审均以《业务需求规格说明书》为依据,确保系统设计满足全部需求。
5.对已确认的系统设计进行修改,需项目经理及技术组负责人及测试负责人审批。
(五)系统实现
1.系统实现包括程序编码、单元测试和集成测试。
2.在系统实现时保证开发、测试和生产环境独立,为各环境建立访问权限控制机制,并明确项目成员的职责分工。
对生产环境、测试环境与开发环境在物理或逻辑方面应该做到隔离。
3.项目组进行单元测试和集成测试,出具《单元测试报告》、《集成测
试报告》和《系统测试用例》,测试人员签字确认测试结果(详见附件3:
《XXX系统—测试报告》、附件4:
《XXX系统—测试用例》)。
4.项目组完成《用户操作手册》(参照附件5),凡涉及应用系统的变更,应对手册及时更新。
(六)系统测试及验收测试
1.项目测试组依据项目整体计划制定项目测试计划。
2.产品技术中心确保开发、测试、验收、上线运营环境独立,为各环境建立访问权限控制机制。
3•搭建验收环境供内部测试,网络运营中心在验收测试环境进行验收测试,并在《验收测试报告》签字确认。
4.业务部门邀请合作伙伴参与测试,确保与系统控制活动相关的功能得到充分的测试,确保系统生成的与编制财务报告相关的报表的正确性。
5.验收测试通过后,进一步完善《用户操作手册》。
(七)系统试运行
1.网络运营中心根据项目规模及影响决定试运行策略。
2.研发事业部组织制定《试运行计划》并提交网络运营中心审批。
3.研发事业部进行相关系统部署工作,准备培训资料,对相关用户和信息技术人员进行培训。
4.试运行达到《试运行计划》规定的终止条件时,项目组编写《试运行报告》。
此报告应由项目组和试运行单位审批确认,并提交系统主要使用部门负责人审批。
(八)系统验收
1.研发事业部及业务归管部门组织验收小组,从业务需求和功能需求及技术需求进行系统评估验收。
2.验收小组依据验收情况整理形成《产品验收报告》提交信息系统研发事业部及业务归管部门审阅。
(九)系统上线
1.系统上线应遵循稳妥、可控、安全的原则。
2.研发事业部提交系统上线发布申请。
3.研发事业部在系统发布前检查经测试人员、相关业务归管部门负责人审批确认的《系统发布申请》、相关《测试报告》是否齐全,并提交公司决策层审批确认。
(十)数据转换
1.研发事业部配合数据转换/初始化各相关部门,根据网络运营中心和研发事业部负责人签字确认的《数据迁移计划》/《数据初始化计划》进行数据转换/初始化操作。
2.研发事业部将数据转换/初始化结果记录在《数据迁移结果报告》/
《数据初始化结果报告》中,由网络运营中心负责人审阅并签字确认。
(十一)结项管理
系统结项后,将系统交由运维团队进行维护支持工作。
(十二)配置管理
1.产品技术中心统一使用SVN进行版本控制。
2.软件开发过程中各项目管理文档和工作成果均作为配置项进行管理,其中包括:
需求文档、设计文档、代码、测试用例、测试数据、数据转换记录以及项目相关文档。
五、开发模式
我公司采用混用开发模式,以传统瀑布式开发模式加入敏捷开发特点,多讨论、多沟通,减少冗杂,做到项目的科学管理,完成产品的快速迭代升级。
(一)前期准备、评审阶段
此阶段主要内容为需求分析,制定相应的解决方案,并对方案进行分析。
1.需求分析:
专业业务需求人员需明确产品需求,分析其版本功能、业务背景、需解决问题、用户操作场景等主要信息。
2.解决方案:
包括系统功能、技术方案等,内容格式可自由扩展,但需明确满足产品需求的方式、方法。
3•方案评审:
须经业务专家级人员及业务经验丰富的人员参与评审,做
出关键评审意见,在此基础上进一步充实解决方案,形成项目列表。
同时完成针对每个开发功能,拆解为详细的开发步骤,估算出工作量。
(二)项目实施阶段
本阶段重点内容为确立产品最终需求,使团队成员更加清晰了解产品需求、开发、测试等多个环节,合理安排工作任务,做到科学规范,合理裁剪,快速敏捷。
项目实施所涉及的过程管理,参照本制度中开发管理过程等内容。
工作任务安排如下图:
XXX阶段任务安排
(三)迭代开发阶段
本阶段实施过程中,需遵循科学的开发管理过程,并根据实际情况进行相应的调整。
1.跨越版本升级过程中的小版本迭代升级,为短周期迭代,周期半个月,一个月,两个月不等。
快速迭代过程中,技术团队应时刻重视团队合作,每个迭代过程必须遵循科学的开发管理过程,根据实际的情况进行裁剪。
2.迭代开发周期结束后,需提交可验证的交付物,团队成员针对此迭代阶段进行评审、总结,在下一个迭代过程发扬优势,规避劣势。
3.迭代开发交付的成果为经过测试团队严格测试、需求分析人员认可、
满足本次迭代需求的有价值的成果。
4.迭代过程监控:
涵盖晨会、夕会、周会、站立会,时间为10-20分钟。
团队成员需做如下总结:
昨天的成果、今天的计划、遇到的问题。
项目可视化方式包含:
任务燃烧图,BUG趋势图,明细任务显示图等。
(四)集成测试阶段
本阶段按《测试计划》(详见附件5:
《xx系统_测试计划—模板》)进行兼容性测试、功能测试、性能测试,确保产品整体稳定性,可靠性;
制定BUG趋势图,测试工程师需对出现的BUG进行跟踪管理,可采用禅道项目管理软件等。
(五)产品上线
产品开发经过以上过程,完成内部评审后,方可上线。
产品开发过程管理
前期准备
需求分析
解决方案
方案评审
1,需求确认
2,解决方案
3,项目进度
4,任务分配
1,过程监控
2,进度跟踪
3,质量管理
4,自适应团队
集成测试
内测
集成测试通过后
发布测试版内测
正式上线
附件
(一)
产品需求申请表
提出人
提出部门提出时间年月日
版本
系统模块
问题描述
提出部门
意见
领导签字:
日期:
产品部
技术组
执行人
签字:
附件
(二)
产品需求(PRD)文档
编号:
PRD002-V2.0-20151009
日期:
2015年10月09日
h编号
文档版本
修订内容
修订原因
修订日期
修改人
i
2
一、引言13
1.产品概述及目标:
13
2.产品路线图:
3.预期读者:
4.成功的定义和判断标准:
13
5.名词说明:
二、需求概述14
1.需求概览:
14
2.用户类与特征:
3.运行环境:
14
4.设计和实现上的限制:
5.时间要求:
6.产品风险:
15
三、功能需求15
1.功能结构15
2.产品功能描述15
2.1货主版15
2.2车主版15
2.3管理后台15
3.产品规则15
四、非功能性需求16
1.性能要求:
16
2.易用性需求:
16
3.安全性需求:
4.运行环境约束:
5.外部接口:
一、引言
这部分的内容有:
产品概述及目标、产品roadmap、预期读者、成功的定义标准
和判断、参考资料、名词说明
解释说明该产品研发的背景以及核心功能。
为产品规划的蓝图,每个关键阶段完成的核心任务。
产品研发是个不断迭代的过程,需要经过若干个版本的迭代,对一个功能点做了N个迭代后最终又回归到了
第一个迭代是很常见。
产品经理需要做好心理准备。
产品roadmap并不需要全部
规划好所有的阶段目标,但是对产品未来发展趋势的一种预估,要达到目标,需要更多的更新和迭代。
清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌,更好的控制研发过程。
文档的使用对象
旨在说明产品的目标。
名称、说明。
名称就是对文档中会出现的比较新的名称,说明则是对这些名称
进行解释。
需求概述
一是业务流程图,对产品整个业务流程的发生过程做图形化的展示,是对产品整体功能流程的阐释。
二是需求清单,对本次要开发的需求任务做分类,给出简明扼要的需求描述并标注优先级。
产品的最终用户,确定产品的最终使用者,并对使用者的角色和操作行为做出说明。
该功能上线后需要在以下操作系统中正常运行:
MicrosoftWindowsXP、WindowsServer、WindowsVista、Windows7、
Windows8等版本;
比如控件的开发环境、接口的调用方式等等
此需求需要在2014年3月30日完成需求评审,在2014年5月1日前完成开
发,在上线时间等等
里程碑
时间
交付物
描述产品可能存在的风险,比如性能瓶颈,没有解决的问题,用户不当使用的风险等等。
三、功能需求
1.功能结构
产品功能的框架图。
2.产品功能描述
产品功能需求的详细描述。
2.1货主版
2.2车主版
2.3管理后台
3.产品规则
涉及产品中的各种规则,比如积分细则,会员等级划分等等
四、非功能性需求
1•性能要求:
用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。
用户在界面的易用性、美观性,以及对面向用户的文档和培训资料等方面的要求。
用户在身份认证、授权控制、私密性等方面的要求。
用户对软件系统运行环境的要求。
用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。
附件(三)
XXX_测试报告
版本号
修订描述
修订人
批准人
颁布日期:
2015年11月06日
受控状态:
■受控□非受控
分发范围:
产品技术中心
1概述19
1.1背景19
1.2目标19
1.3测试范围19
1.4测试环境19
1.5参考文档20
2测试过程20
2.1测试概述20
2.2测试用例执行率20
2.3遗留缺陷20
3测试分析21
3.1功能测试分析21
4测试结论21
4.1结论错误!
未定义书签
4.2风险及局限性21
4.3建议22
5测试总结22
测试报告
概述
背景
[说明编写本报告的目的,测试所依据的文档和测试参与方。
]
目标
[说明测试的目标]
测试范围
[说明测试的测试范围及测试内容]
序号
测试内容
1
界面测试
验证界面是否满足UI及需求定义
测试环境
[说明软件测试所需的测试环境,包括操作系统、数据库、配置,手机型号、品牌等。
数据库服务器配置
主机
IP
型号
配置
操作系统
Tomcat版本
数据库
管理端客户端配置
品牌
测试手机
手机品牌
参考文档
[说明本测试报告所用到的参考资料等。
文档
已创建或可用
已被接收或已经过复审
作者或来源
XXXXXX
是■否口
SVN
测试过程
测试概述
[说明测试的测试模块,测试方法,测试时间、测试地点、测试人员等]
本次测试的时间、地点和测试人员如下表所示:
项目
描述
测试模块
车主版APP(ISO及Android)货主版APP(ISO及Android)及后台
管理
测试方法
界面测试、冒烟测试、功能测试、回归测试、兼容测试
测试时间
2015.10.19至2015.10.29
测试地点
河南华侨实业有限公司
测试人员
王景新孙真真
测试用例执行率
[说明测试的测试主模块,测试用例数量,测试用例执行数量及测试用例执行率]
主模块
测试用例数量(个)
测试用例执行数量(个)
货主版APP
(ISO及
Android)
侧滑宣传页
11
100%
我的货源
9
我要发货
56
我的订单
28
遗留缺陷
[说明测试的缺陷遗留情况]
缺陷列表详见缺陷列表清单
缺陷模块
缺陷数量
(个)
遗留缺陷数量(个)
遗留缺陷率(%)
APPAndroid
17
0%
测试分析
功能测试分析
[对此次测试情况进行测试分析]
测试结论
[编写测试结论]
测试结论中说明测试项是否测试通过。
有三种选择:
通过:
此模块没有遗留问题;
基本通过:
此模块有遗留问题,但问题不影响功能的正常使用;
不通过:
此模块有遗留问题,但影响功能的正常使用
测试结果
程序界面是否符合
UI设计
通过
缺陷级别
缺陷总数(个)
遗留缺陷数(个)
是否通过结束测试准则
所有缺陷
115
综合上述数据,本次发布版本的程序测试结论:
发现的所有缺陷已修复,通过测试,可以进入下一个
阶段。
风险及局限性
[编写风险及局限性]
风险因素
说明
遗留bug
没有遗留bug
建议
[编写测试或项目建议]
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 互联网 IT 行业 项目 管理 规章制度