zoukankan      html  css  js  c++  java
  • 项目开发流程规范文档

     

    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 业务需求理解阶段                                         

    2.3.1系统设计人员理解需求

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

    理解需求文档的交付结果(可配置项)

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

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

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

     

    需求理解时间要求:

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

    复杂需求:理解需求时间4-8小时

     

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

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

     

    2.4 详细设计阶段

       详细设计阶段分两个步骤

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

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

      

    2.4.1系统设计人员详细设计阶段

    系统设计人员根据业务需求,详细设计模块。

    详细设计阶段的交付结果(可配置项)

    详细设计文档:

    业务接口定义

    数据库的数据项定义

    Web页面和Js接口定义等

     

    注:对于复杂的模块可以在详细设计文档中可以包含了UML类图,和时序图 ,从而进一步描述设计的内容

    详细设计时间要求:

    简单的业务需求:2-4小时

    复杂的业务需求4-12小时

     

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

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

     

    2.4.2 技术评审阶段

    技术评审流程

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

    2)在技术评审过程中,系统设计人员首先讲述详细设计文档

    3)评审人员对详细设计中各个环节进行询问和确认,提出修改方案。

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

      

    技术阶段的交付结果(可配置项)

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

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

    2.5 Coding阶段

    系统开发人员根据业务的项目详细设计文档,进行实际Coding过程。

    在Coding过程中的注意事项

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

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

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

    2.6 业务模块确认交付阶段

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

     

    验收步骤:

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

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

    3)测试人员的测试报告

     

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

        第三步完成流程如下:

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

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

       3)根据测试的结果,出测试报告。

     

     

    2.7 系统集成测试

    根据客户业务需求,测试人员设定一个测试环境,编写测试脚本,在测试服务器上部署好系统。按照测试用例进行业务功能上测试。

     

    测试人员准备工作清单:

    测试用例

    测试脚本

    当前实现模块

     

    硬件设备

    等同条件的客户运行环境

     

    系统集成测试阶段交付项(可配置项):

    系统集成测试报告

     

    系统集成测试报告格式

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

     

    2.8 系统打包部署

        客服安装人员将系统打包成一个安装文件,供在客户的系统环境中部署系统

    系统集成测试阶段交付项(可配置项):

    系统安装文件

  • 相关阅读:
    flume sink两种类型 file_rool 自定义sing com.mycomm.MySink even if there is only one event, the event has to be sent in an array
    为什么引入进程20年后,又引入线程?
    As of Flume 1.4.0, Avro is the default RPC protocol.
    Google Protocol Buffer 的使用和原理
    Log4j 2
    统一日志 统一订单
    网站行为跟踪 Website Activity Tracking Log Aggregation 日志聚合 In comparison to log-centric systems like Scribe or Flume
    Percolator
    友盟吴磊:移动大数据平台的架构、实践与数据增值
    Twitter的RPC框架Finagle简介
  • 原文地址:https://www.cnblogs.com/dingfangbo/p/5739908.html
Copyright © 2011-2022 走看看