新产品项目开发规范文档.docx

新产品项目开发规范文档.docx

《新产品项目开发规范文档.docx》由会员分享，可在线阅读，更多相关《新产品项目开发规范文档.docx（7页珍藏版）》请在冰豆网上搜索。

新产品项目开发规范文档

项目开发规范文档

编写人：

徐文兵

日期：

2009-7-20

审核人：

日期：

批准人：

日期：

文档编号

T/KFGF

文档版本

0.1

项目编号

YCFLATFORM

修改记录（REVISIONCHART）

0.1

徐文兵初稿

2009-7-22

1概述

目的与概述

本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。

整体说明

在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。

开发规范阐述了在一个框架中的各个层的开发规范

（注：

在第一版中不包含对工作流开发的规范制定）

第二部分为Coding开发规范，Coding

覆盖范围

阅读对象

1.

2.

3.

项目管理人员

系统设计人员

系统开发人员

参考资料

2项目开发流程规范

2.1业务需求调研阶段

调研的目标

系统层面：

客户的系统运行环境

业务层面：

了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。

调研的准备工作：

行业知识的准备：

了解客户的行业背景，行业领域的业务术语，含义。

结合客户行业背景，了解客户的业务知识。

业务专家需求：

在行业领域的复杂度不高的情况下，

在行业领域业务复杂度高的情况下，

业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的需要业务专家对客户的业务的进行整理。

调研的流程:

第一步

第二步，

第三步，

第四步，

第五步，

第六步，

，项目启动阶段了解客户的

讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。

在这个过程中准备一个本和一只笔记录讨论的业务信息整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。

发放调研问卷，再次进行业务调研（直接转到三）

卷写调研问卷，并内部评审

调研问卷客户评审并确认。

IT环境。

调研阶段的交付项（可配置项）软件需求说明书

软件需求说明书的目录:

客户行业背景

客户系统的意义

客户系统运行的环境

业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等）客户的操作习惯，页面风格习惯。

2.2概要设计阶段

概要设计阶段主要分两个步骤:

1框架设计2业务模块概要设计，下面分别对两个步骤进行描述:

2.2.1框架设计

（注：

这边的框架设计是按照传统的开发方式进行阐述，基于平台的开发方式待补）

框架设计的目标：

根据客户需求，设计系统的后台架构，前台界面框架，数据模型。

在设计之前要考虑客户的业务特点，性能要求，已有的将来业务的增长，保证系统一定得可扩展性。

IT环境，同时还要考虑

框架设计包含的内容:

后台框架：

各层的职能划分，技术实现的方式，层之间的交互规则，异常处理规则，目录定义规则

界面框架:

操作主界面定义

页面整体风格的定义，页面流转关系等

数据模型:

系统基础数据（组织人员结构，权限设置，字典参数设置）业务数据

框架设计阶段交付项:

文档：

系统架构

界面框架

数据模型

注：

三份文档可以融合在一份文档之中。

系统设计人员根据业务分析人员的业务需求文档，进行概要设计。

在概要设计过程中主要关注三个关键点

1）

222业务模块概要设计

业务模块的页面显示内容：

信息显示的内容，显示的方式；交互接口的定义，等举例：

查询人员信息模块

操作说明，查询条件，显示字段，排序和显示方式。

2）

业务逻辑描述

对业务逻辑进行详细的描述。

3）

业务数据项

业务模块涉及到数据的描述。

具体的描述包含

数据项名称，显示方式，是否必填，输入方式，相关逻辑

概要设计阶段的交付项

概要设计文档

2.3业务需求理解阶段

2.3.1系统设计人员理解需求

系统设计人员阅读并理解客户需求文档。

在系统设计人员理解需求之前，业务分析人员必须提供相关模块的客户需求文档。

理解需求文档的交付结果（可配置项）

业务需求对于客户来讲，目的是什么，解决什么问题，有什么意义？

具体业务的执行逻辑是什么？

在业务流转过程中的业务数据有哪些?

需求理解时间要求:

简单的需求，理解时间为2-3小时

复杂需求：

理解需求时间4-8小时

复杂的业务需求需要需求分析人员确认。

复杂的业务需求按照涉及到的业务的复杂度来决定的。

2.4详细设计阶段

详细设计阶段分两个步骤

第一步骤，系统设计人员根据业务需求的理解，详细设计业务模块，并出详细设计文档

第二步骤，核心设计人员对系统设计人员的详细设计文档进行技术评审。

2.4.1系统设计人员详细设计阶段系统设计人员根据业务需求，详细设计模块。

详细设计阶段的交付结果（可配置项）

详细设计文档：

业务接口定义

数据库的数据项定义

Web页面和Js接口定义等

详细设计文档的书写原则：

系统设计人员在文档中能描述清楚业务模块的详细设计，不拘泥于格式。

1）

2）

3）

4）

2.4.2技术评审阶段技术评审流程：

系统设计人员在技术评审之前，将自己的详细设计文档分发给技术评审的与会人员。

在技术评审过程中，系统设计人员首先讲述详细设计文档评审人员对详细设计中各个环节进行询问和确认，提出修改方案。

最后项目技术负责人确认调整后的设计方案。

技术阶段的交付结果（可配置项）

业务确定的详细设计文档。

注：

此文档是交付确认的标准之一。

2.5Coding阶段

Coding过程。

系统开发人员根据业务的项目详细设计文档，进行实际在Coding过程中的注意事项

1）在Coding过程中严格按照Coding开发规范来执行。

2）在Coding过程中，发现详细设计文档中的严重缺陷，则需要和项目设计人员确认，如非常复杂，则需重新技术评审。

3）在详细设计发生改变时，需要及时更新详细设计文档。

2.6业务模块确认交付阶段

项目技术负责人和业务分析人员共同对业务模块进行验收。

验收步骤：

1）业务分析人员确认功能模块实现功能和客户需求一致

2）技术负责人对功能模块进行技术上的确认。

3）测试人员的测试报告

注：

第三步主要看公司的具体的情况和业务复杂度，

第三步完成流程如下：

1）准备测试阶段测试人员根据业务需求，设定一个业务环境，写成测试脚本,

2）测试阶段根据测试环境和业务需求进行测试

3）根据测试的结果，出测试报告。

2.7系统集成测试

根据客户业务需求，测试人员设定一个测试环境，编写测试脚本，在测试服务器上部署好系统。

按照测试用例进行业务功能上测试。

测试人员准备工作清单:

测试用例

测试脚本

当前实现模块

硬件设备：

等同条件的客户运行环境

系统集成测试阶段交付项（可配置项）系统集成测试报告

系统集成测试报告格式

功能点测试人测试脚本测试结果异常原因

2.8系统打包部署

客服安装人员将系统打包成一个安装文件，供在客户的系统环境中部署系统系统集成测试阶段交付项（可配置项）：

系统安装文件