KF项目开发流程规范10.docx
《KF项目开发流程规范10.docx》由会员分享，可在线阅读，更多相关《KF项目开发流程规范10.docx（21页珍藏版）》请在冰豆网上搜索。
KF项目开发流程规范10
产品部项目开发流程规范
撰写人：
审核人：
20120115发布20120129实施
修改历史记录
序号
更改单号
版本
编制\日期
审核\日期
批准\日期
1
1.0
目录
项目开发流程架构图3
一、项目开发流程4
1、老产品功能扩展或升级维护流程4
2、新产品开发流程5
二、开发流程细则6
过程一、项目立项6
过程二、分析7
过程三、设计9
过程四、开发10
过程五、测试13
过程六、评审15
过程七、项目验收与结项18
三、禅道操作详细说明19
登录：
19
步骤一：
19
步骤二：
19
步骤三：
19
步骤四：
19
步骤五：
20
步骤六：
20
步骤七：
20
步骤八：
20
步骤九：
20
步骤十：
21
步骤十一：
21
步骤十二：
21
项目开发流程架构图
一、项目开发流程
1、老产品功能扩展或升级维护流程
序号
工作内容
禅道软件工作内容
角色
过程一
项目立项，填写《项目任务书》
步骤二~步骤六
部门经理或项目经理
过程二
过程三
过程四
进行开发工作或文档编写
开发人员
过程六
文档评审，填写《文档评审表》
上传到项目文档库
开发人员与评审人员
过程五
开发工作完成创建测试版本
步骤七
开发人员
过程五
给测试人员下达任务
步骤八
开发人员
过程五
编写测试用例并测试
步骤九
测试人员
过程五
测试人员将发现的BUG反馈给开发人员进行修改
步骤十
测试人员
过程五
开发人员将BUG修改完毕，提出再次测试
步骤七~步骤八
开发人员
过程五
测试人员重新测试
步骤九
测试人员
过程七
BUG解决并且测试没有问题，提出版本发布
步骤十一~步骤十二
测试人员
过程七
部门助理根据项目任务书的内容进行审核存档并发布
部门助理
说明：
上述流程中，没有涉及到的步骤可以跳过。
若项目只做少许的修改，过程二~过程三可跳过。
禅道中每个步骤的详细说明见本文档后面介绍的禅道操作详细说明。
上述流程是按照小规模的项目流程写的，如果项目规模较大，项目经理需将任务分解下达，每项任务工时不可超过一周。
2、新产品开发流程
序号
工作内容
禅道软件工作内容
角色
过程一
准备新产品立项文档
项目经理
过程一
文档评审，填写《文档评审表》
项目经理和评审人员
过程一
新产品到财务备案、立项
步骤一
部门助理和产品部经理
过程一
立项文档及《文档评审表》归档
上传到产品文档库
部门助理
过程一
任务分解，填写《项目任务书》
步骤二~步骤六
部门经理或项目经理
过程二
系统分析
开发人员
过程三
系统设计
开发人员
过程四
系统开发
开发人员
过程六
文档评审，填写《文档评审表》
上传到项目文档库
开发人员与评审人员
过程五
开发工作完成创建测试版本
步骤七
开发人员
过程五
给测试人员下达任务
步骤八
开发人员
过程五
编写测试用例并测试
步骤九
测试人员
过程五
测试人员将发现的BUG反馈给开发人员进行修改
步骤十
测试人员
过程五
开发人员将BUG修改完毕，提出再次测试
步骤七~步骤八
开发人员
过程五
测试人员重新测试
步骤九
测试人员
过程六
产品评审，填写《评审表》
上传到项目文档库
评审人员
过程七
BUG解决并且测试没有问题，提出版本发布
步骤十一~步骤十二
测试人员
过程七
部门助理根据项目任务书的内容进行审核存档并发布
部门助理
二、开发流程细则
过程一、项目立项
1.1新产品立项
Ø全新产品开发和在老产品的基础上开发新产品均算作新产品，必须由部门经理写《项目任务书》。
Ø全新产品开发必须到财务立项。
Ø在老产品的基础上开发新产品需由部门经理确定是否到财务立项。
1.2老产品升级维护
Ø老产品升级维护只需填写《项目任务书》即可。
过程二、分析
注：
在老产品升级维护中，该阶段如无特殊要求可省略。
2.1输入文档
做系统分析之前，应准备好项目立项文档，技术建议、合同与技术协议（合同性项目），第三方接口协议，项目任务书。
2.2分析内容
系统功能、系统现状、系统的性能与实现、系统接口分析、风险评估、成本分析。
2.3输出文档
需要完成的文档：
项目系统分析文档（参见项目系统分析模板）。
2.4评审
评审发起人：
项目负责人
评审流程见技术评审流程章节。
过程三、设计
注：
在老产品升级维护中，该阶段如无特殊要求可省略。
3.1输入文档
系统分析文档，项目任务书
3.2输出文档
《概要设计方案》、界面设计说明书（没有界面设计项目的没有）参见《界面设计模板》，数据库设计说明说（没有数据库设计项目的没有）《参见数据库设计模板》，系统设计文档，参见《系统设计模板》。
文档撰写人为架构设计人，一般为技术负责人或其它指定人员。
3.3评审
评审发起人：
项目负责人
评审流程见技术评审流程章节。
过程四、开发
4.1输入文档
系统分析文档，界面设计文档，数据库设计文档，系统设计文档，上级任务书（一般为信息平台下达），开发规范（原理图设计规范，PCB设计规范，程序编码规范）。
4.2开发流程
4.2.1模块开发顺序
自底向上：
顶让人很容易了解系统
自顶向下很难测试（装模块很难实现）
先自底向上走通一条路
横向扩展：
即便于测试，又有整体效果后开始横向扩展
4.2.2模块开发
（1）硬件
原理图设计
审核或评审：
由技术负责人组织
PCB设计
审核或评审：
由技术负责人组织
（2）软件
数据结构设计
代码编写
（3）注意事项：
如需要调整任务计划，由项目经理批准
如需要更改设计，需经过设计人员批准，同时修改设计文档。
4.2.3存在分析、设计问题
如果在系统开发中发现了问题，就要返回到系统设计，重新进行系统设计，然后再依次按程序往下走。
4.2.4单元测试
每个模块开发完后由开发人员本人或测试人员及时测试，并编写编程测试用例说明与测试
报告（参见《测试用例模板》和《单元测试报告》）。
4.2.5文档编写
编写编程文档和硬件原理说明书（参见《编程文档》）。
4.2.6注意事项
对于紧急研发，可以后补开发文档，但必须经常讨论开发内容
4.3集成测试
（1）测试人员：
项目经理即组织者，系统设计人员，开发人员
（2）测试方法：
硬件与面向过程的程序：
采用增量测试，即逐步增加模块测试
面向对象的程序：
采用非增量测试，即全编译测试。
4.4项目跟踪
项目经理应每天填写实际计划，并与基准计划对比，实际计划与基准计划误差较大时应及时与部门领导沟通。
4.5编写使用说明书：
用于工程移交
4.6输出文档
硬件SCH、PCB图，程序源代码，编程文档（参见《编程文档模板》），代码评审报告（参见《代码评审报告模板》），硬件原理说明书（参见《硬件原理说明书模板》）。
4.7评审
评审发起人：
项目负责人
评审流程见技术评审流程章节。
过程五、测试
5.1输入文档
系统分析文档，界面设计文档，数据库设计文档，合同（合同性项目），使用说明书。
5.2参与人员
组织者：
项目经理
测试人员：
工程部或其它项目组
5.3确认测试
文档确认
软硬件确认
测试环境确认
5.4测试用例
5.4.1分析需要测试的要点
5.4.2测试用例设计
测试人员根据项目的实际情况设计测试用例，常用方法有：
等价类划分，边界值，错误推测。
5.5系统测试
5.5.1功能测试
是否完成系统分析或合同中的所有功能；是否存在与系统分析或合同中不一致的情况。
5.5.2性能测试
压力测试，容量测试，性能测试，安全测试，错误测试等
5.5.3界面测试
参见《界面测试检查表》
5.5.4其它测试
需要公司其它部门或客户进行配合测试。
5.6测试回归
测试过程中发现的问题要回归到开发。
5.7输出文档
软件测试及缺陷跟踪报告（参见模板《系统测试及缺陷跟踪报告》）。
过程六、评审
6.1评审范围
主要涉及以下几个方面:
设计正确性：
设计是否正确。
设计准确性：
是否有更好的方案。
成本分析：
投入产出值不值，是否有替代方案。
可实施性：
实施的难度。
重要、难点问题讨论。
6.2评审流程：
6.2.1评审发起
评审会议项目负责人或技术负责人向部门助理提出，部门助理向部门领导提请审核。
6.2.2评审负责人指定
部门领导同意评审后同时指定评审负责人或转交相关技术负责人处理。
6.2.3评审准备
评审负责人与评审发起人沟通，确定评审时间、地点和人员，提前将文档发给相关人员。
6.2.4评审过程
评审过程由评审负责人主持，评审发起人对评审对象（文档或产品）进行讲解，评审人员可以随时提出问题，部门助理同时做好评审记录。
评审会议结束后应有评审人员商讨得出评审结论。
6.2.5评审报告撰写与发布
部门助理：
评审技术后部门助理应对审评记录和结论进行整理，与评审负责人沟通并撰写评审报告。
评审报告与评审发起人确认，并将缺陷改正时间或不修改的理由确认后提交到部门领导。
6.2.6缺陷跟踪
部门领导决定哪些缺陷需进行改正，并制定改正时间。
部门助理开始跟踪缺陷改正情况，并定期向部门领导报告，汇报时间由评审评审发起人和部门助理根据实际情况自行决定。
6.2.7评审过程完成
项目负责人完成所有缺陷改正后，评审负责人与评审成员采用正式或非正式的讨论，完成最终结论报告后由部门助理提交部门领导。
6.2.8评审存档
由部门助理对评审报告进行归档。
过程七、项目验收与结项
注：
如果是老产品维护，则通过测试人员的测试即可发布，该项可省略。
7.1项目验收
由部门领导组织，进行项目验收总结。
7.2工程移交会议
7.3前端发布文档编写
7.4对前端进行发布会议
7.5工作总结
提交两个报表：
人员任务工作量报表和费用报表，最后进行经验总结。
7.6文档归档
由部门助理进行文档归档工作。
三、禅道操作详细说明
Ø登录：
登录内网网址：
http:
//172.16.0.10:
88/zentao登录禅道，
外网登录地址为：
http:
//124.207.136.120:
88/zentao
登录名：
产品部员工姓名的全拼
密码：
123456
Ø步骤一：
创建产品：
点击
->
，按照界面提示将内容填写完整，保存即可。
Ø步骤二：
创建计划：
计划是在产品的基础上创建的，在
中先选择要创建计划的产品，然后点击
->
，按照界面内容提示填写完整，保存即可。
Ø步骤三：
创建需求：
在
中点击
->
，按照界面内容提示填写，选择要关联的计划（注意一个计划可以关联多个需求），选择是否需要评审（不需要评审的需求状态是激活的，只有激活状态的需求才能关联到项目中，进行开发；若需要评审，评审结果必须通过，状态才能激活。
）。
如果需求的内容较多或是电子版文档，可添加附件上传，作为需求内容，填写完成保存即可。
Ø步骤四：
创建项目：
我们现在有了产品、计划、需求，现在我们需要创建一个项目来完成这个需求。
在
中点击
，按照界面内容提示填写完成，保存。
关联产品：
在
中点击
选择该项目关联的产品，保存。
关联需求：
在
中点击
选择与该项目关联的产品的需求，保存。
Ø步骤五：
确定团队成员：
在
中选择要建立团队的项目，然后点击
->
，增加项目团队成员，分配角色，保存。
Ø步骤六：
分派并创建任务：
进入
->
，在要分解任务的需求后面点击
，指出完成该项任务的人员，描述任务内容，若有相关资料可以以附件的形式上传，保存。
Ø步骤七：
创建Build：
若干任务完成之后，就可以提交测试了，这时需要创建一个测试版本号即Build。
进入
选择要创建Build的项目，点击
->
，进入创建页面，填写Build的名称编号，编号可以是产品名_版本号_状态（stble,beta之类）_日期；描述里面可以填写完成的需求列表，最后保存。
Ø步骤八：
创建测试任务：
进入
选择
->
，在创建测试任务页面一定要选择相应的项目和Build，指派测试人员，在任务描述里面，可以注明此次测试需要注意的地方。
Ø步骤九：
创建测试用例：
进入
选择
->
，每一个测试用例都有若干个步骤组成，每一个步骤都可以设置自己的预期值。
这样可以非常方便进行测试结果的管理和bug的创建。
填写完毕保存即可。
说明：
如果测试人员认为测试用例使用不方便或者测试内容覆盖不全面，可以用《软件测试及缺陷跟踪报告》填写，测试完成后，将报告以附件的形式上传到测试用例页面。
Ø步骤十：
创建BUG：
进入
选择
->
，选择BUG所属的产品、项目、需求及任务，这样可以将bug和项目，任务，需求关联起来，以便以后的统计分析。
重现步骤应该翔实准确，确保开发人员可以重现改bug，若重现步骤过多可以以文档的形式上传到附件中。
Ø步骤十一：
修改、BUG关闭：
开发人员修改BUG重复步骤七——步骤十，测试人员经过测试后发现BUG已解决可进入
选择
，在该项BUG后面点击
。
Ø步骤十二：
进入
选择
->
，将发布页面内容填写完毕，即发布完成。
升级会员 