新产品项目开发规范文档.docx
《新产品项目开发规范文档.docx》由会员分享,可在线阅读,更多相关《新产品项目开发规范文档.docx(8页珍藏版)》请在冰豆网上搜索。
新产品项目开发规范文档
文档编号:
T/KFGF
文档版本:
0.1
项目编号:
YC_FLATFORM
项目开发规范文档
编写人:
徐文兵
日期:
2009-7-20
审核人:
日期:
批准人:
日期:
修改记录(REVISIONCHART)
版本
作者
修改描述
修改日期
0.1
徐文兵
初稿
2009-7-22
1概述
目的与概述
本文档为XX公司的开发规范文档,给开发团队提供开发标准和规范。
整体说明
在开发规范中包含了两个部分,第一部分是项目开发流程规范,主要阐述在项目开发过程中的各个阶段的规范。
第二部分为Coding开发规范,Coding开发规范阐述了在一个框架中的各个层的开发规范
(注:
在第一版中不包含对工作流开发的规范制定)
覆盖范围
阅读对象
1.项目管理人员
2.系统设计人员
3.系统开发人员
参考资料
略
2项目开发流程规范
2.1业务需求调研阶段
●调研的目标
系统层面:
客户的系统运行环境
业务层面:
了解客户需要什么样的系统,具体了解业务目的,业务逻辑,业务数据,客户的操作习惯,页面风格习惯等。
●调研的准备工作:
行业知识的准备:
了解客户的行业背景,行业领域的业务术语,含义。
结合客户行业背景,了解客户的业务知识。
业务专家需求:
在行业领域的复杂度不高的情况下,业务分析人员直接收集并学习行业知识就可以了,但行业知识的准备工作还是要做的
在行业领域业务复杂度高的情况下,需要业务专家对客户的业务的进行整理。
●调研的流程:
第一步,项目启动阶段了解客户的IT环境。
第二步,讨论并具体确定客户系统的范围,并获得客户业务功能点的原始的单据。
在这个过程中准备一个本和一只笔记录讨论的业务信息
第三步,整理业务信息,和原始表单,抽取出有效业务信息,并对于不明确的业务信息进行整理和归类,并制作成问卷形式进一步调研。
第四步,发放调研问卷,再次进行业务调研(直接转到三)
第五步,卷写调研问卷,并内部评审
第六步,调研问卷客户评审并确认。
●调研阶段的交付项(可配置项)
软件需求说明书
软件需求说明书的目录:
1客户行业背景
2客户系统的意义
3客户系统运行的环境
4业务功能点描述(业务目的,业务逻辑,业务数据,优先级别,使用频率等)
5客户的操作习惯,页面风格习惯。
2.2概要设计阶段
概要设计阶段主要分两个步骤:
1框架设计2业务模块概要设计,下面分别对两个步骤进行描述:
2.2.1框架设计
(注:
这边的框架设计是按照传统的开发方式进行阐述,基于平台的开发方式待补)
●框架设计的目标:
根据客户需求,设计系统的后台架构,前台界面框架,数据模型。
在设计之前要考虑客户的业务特点,性能要求,已有的IT环境,同时还要考虑将来业务的增长,保证系统一定得可扩展性。
●框架设计包含的内容:
后台框架:
各层的职能划分,技术实现的方式,层之间的交互规则,异常处理规则,目录定义规则
界面框架:
操作主界面定义
页面整体风格的定义,页面流转关系等
数据模型:
系统基础数据(组织人员结构,权限设置,字典参数设置)
业务数据
●框架设计阶段交付项:
文档:
系统架构
界面框架
数据模型
注:
三份文档可以融合在一份文档之中。
2.2.2业务模块概要设计
系统设计人员根据业务分析人员的业务需求文档,进行概要设计。
在概要设计过程中主要关注三个关键点
1)业务模块的页面显示内容:
信息显示的内容,显示的方式;交互接口的定义,等
举例:
查询人员信息模块
操作说明,查询条件,显示字段,排序和显示方式。
2)业务逻辑描述
对业务逻辑进行详细的描述。
3)业务数据项
业务模块涉及到数据的描述。
具体的描述包含
数据项名称,显示方式,是否必填,输入方式,相关逻辑
●概要设计阶段的交付项
概要设计文档
2.3业务需求理解阶段
1
2
2.1
2.3.1系统设计人员理解需求
在系统设计人员理解需求之前,业务分析人员必须提供相关模块的客户需求文档。
系统设计人员阅读并理解客户需求文档。
●理解需求文档的交付结果(可配置项)
业务需求对于客户来讲,目的是什么,解决什么问题,有什么意义?
具体业务的执行逻辑是什么?
在业务流转过程中的业务数据有哪些?
●需求理解时间要求:
简单的需求,理解时间为2-3小时
复杂需求:
理解需求时间4-8小时
●复杂的业务需求需要需求分析人员确认。
复杂的业务需求按照涉及到的业务的复杂度来决定的。
2.4详细设计阶段
详细设计阶段分两个步骤
●第一步骤,系统设计人员根据业务需求的理解,详细设计业务模块,并出详细设计文档
●第二步骤,核心设计人员对系统设计人员的详细设计文档进行技术评审。
2.2
2.4.1系统设计人员详细设计阶段
系统设计人员根据业务需求,详细设计模块。
●详细设计阶段的交付结果(可配置项)
详细设计文档:
业务接口定义
数据库的数据项定义
Web页面和Js接口定义等
注:
对于复杂的模块可以在详细设计文档中可以包含了UML类图,和时序图,从而进一步描述设计的内容
●详细设计时间要求:
简单的业务需求:
2-4小时
复杂的业务需求4-12小时
●详细设计文档的书写原则:
系统设计人员在文档中能描述清楚业务模块的详细设计,不拘泥于格式。
2.4.2技术评审阶段
●技术评审流程:
1)系统设计人员在技术评审之前,将自己的详细设计文档分发给技术评审的与会人员。
2)在技术评审过程中,系统设计人员首先讲述详细设计文档
3)评审人员对详细设计中各个环节进行询问和确认,提出修改方案。
4)最后项目技术负责人确认调整后的设计方案。
●技术阶段的交付结果(可配置项)
业务确定的详细设计文档。
注:
此文档是交付确认的标准之一。
2.5Coding阶段
系统开发人员根据业务的项目详细设计文档,进行实际Coding过程。
在Coding过程中的注意事项
1)在Coding过程中严格按照Coding开发规范来执行。
2)在Coding过程中,发现详细设计文档中的严重缺陷,则需要和项目设计人员确认,如非常复杂,则需重新技术评审。
3)在详细设计发生改变时,需要及时更新详细设计文档。
2.6业务模块确认交付阶段
项目技术负责人和业务分析人员共同对业务模块进行验收。
验收步骤:
1)业务分析人员确认功能模块实现功能和客户需求一致
2)技术负责人对功能模块进行技术上的确认。
3)测试人员的测试报告
注:
第三步主要看公司的具体的情况和业务复杂度,
第三步完成流程如下:
1)准备测试阶段测试人员根据业务需求,设定一个业务环境,写成测试脚本,
2)测试阶段根据测试环境和业务需求进行测试
3)根据测试的结果,出测试报告。
2.7系统集成测试
根据客户业务需求,测试人员设定一个测试环境,编写测试脚本,在测试服务器上部署好系统。
按照测试用例进行业务功能上测试。
测试人员准备工作清单:
测试用例
测试脚本
当前实现模块
硬件设备:
等同条件的客户运行环境
系统集成测试阶段交付项(可配置项):
系统集成测试报告
系统集成测试报告格式
功能点测试人测试脚本测试结果异常原因
2.8系统打包部署
客服安装人员将系统打包成一个安装文件,供在客户的系统环境中部署系统
系统集成测试阶段交付项(可配置项):
系统安装文件