产品养成计划

产品开发技术文档模板

2018-10-08  本文已影响312人  cli1871

        产品的生命周期一般会经过规划,开发,测试,发布,验收,维护 6个阶段,是产品都有寿命,即使是软件产品,但为了讨个吉利,我不愿意把下线列入产品的生命周期里。

       产品规划更多的来自于产品经理,他们会识别机会,挖掘及探索用户需求,把他们转变为可行且有一定市场的方案,并落实成产品设计文档,作为与客户及研发人员沟通的媒介。 

      产品开发人员为了与产品经理与其它开发人员更好的沟通,一般会书写技术方法文档及设计文档,技术方法文档更多的是与产品经理及项目经理沟通的, 而设计文档更多的开发人员所在团队用了参考评审的。

      产品测试可以分为单元测试,功能测试,集成测试,稳定性测试,性能测试,测试建议不要用模块开发人员,避开思维惯性,当然对于功能测试,集成测试来说可以用白盒与黑盒两种方法进行测试,将相关测试点落实到测试文档中,方便审阅验收。

     产品发布需要发布文档,发布文档里会罗列新增的功能,修订的问题,测试报告。

     产品验收更多的是白盒测试,对产品所要功能进行测试。

     产品维护文档,一般是产品监控说明,产品报警机制,报警分类,及怎么解决等。

     现今的开发模式越来越倾向于轻文档,重编码的开发惯例,不过,在某些情况下,文档或多或少还是有它的用武之地,基于个人经验,总结一些相关文档模板供大家参考。


产品设计文档

1 产品/模块背景

1.1 产品/问题声明

         注释:描述一下产品由来,或许是产品不足,需要增强,或许是新的市场需求,或许是新技术等

1.2 产品分析

         注释: 描述一下商业客户应用,或者特定消费级用户使用情况

2 用例

         注释: 描述实际用例,怎么用

3 功能需求

3.1 功能需求 1

           注释: 用表格,图片或文字叙述方式,描述功能需求

3.2 功能需求2

            注释: 用表格,图片或文字叙述方式,描述功能需求

3.3 功能需求 ...

             注释: 用表格,图片或文字叙述方式,描述功能需求

4 验证

4.1 正确性验证

             注释:白盒测试,对功能需求正向数据进行验证

4.2 错误验证

             注释:白盒测试,对功能需求逆向数据进行验证

5 参考




技术方法文档

1 模块作者

      注释:开发人员/测试人员/部署人员

2 产品文档

2.1 问题声明

2.2 变化内容

2.3 变化前

2.4 变化后

2.5 用户影响

2.6 服务影响

3 解决方案

     注释:可以有多个解决方案,供大家选择

3.1 解决方案1

3.1.1 方案拆分

      注释: 方案需要涉及到哪些模块需要修改支撑,比如说前端,中间件,后端服务,数据库等

3.1.1.1 模块方案

      注释:简要描述模块所需支撑的功能,及接口是否改变

3.1.2 性能影响

      注释: 描述加入模块后对性能的影响评估

3.1.3 实施影响:

      注释: 描述是否需要环境改变支撑,比如带宽,内存等

3.1.4 模块依赖

       注释: 描述所依赖的模块

4 修订历史记录

注释:以表格形式列出修订历史记录,什么时间,改了什么方便查阅




技术设计文档

1 产品设计文档链接

注释: 可选的,可以加入产品文档链接方便参考

2 商业需求

注释:可选的,从客户角度描述一下商业需求,一般在产品设计文档赘述

3 用例

注释: 可选的,描述主要的用例

4 影响模块

注释:以表格形式列举那些受影响,那些不受影响,比较重要,因此在技术方法文档与技术设计文档都会阐述

5 影响接口

注释:以表格形式列举受影响的接口,及相应调整,应考虑前后兼容,或者如果不前后兼容,部署怎么解决对客户透明,0下线

6 技术设计

注释:描述系统架构,逻辑,流程,你可以用文字,伪代码或uml图的方式清晰表达你的设计思路及实施方案。常用的工具:Viso, wiki, StarUML etc。灵活运用用例图,组件图,类图,时序图,流程图等。设计应遵循以下原则:

        正确性: 一切以正确性为前提,设计及执行均满足产品设计需求

       健壮性: 程序至少经得住7*24稳定性测试

       可用性: 易用,运行时间在运行结果符合市场预期

       可行性:部署经费与开发时间可控

       可扩展:松耦合的模块内部设计,一般推崇SOA

        可实施: jenkins的持续集成持续部署

7 前提/限制

注释:可选的,模块运行需要前提条件,当前功能是否还有一些限制条件

8 实施/监控

注释:实施部署是否需要申请新的机器,或者原有机器是否需要磁盘或内存扩容,是否需要安装新的第三方库(第三方库是否开源,是否需要获取授权),数据库表格是否需要变化,数据是否需要做提前迁移,是否需要监控,监控哪些内容:如进程,进程资源消耗,进程是否有报警机制

9 测试环境变化

注释:从开发的角度,告知测试哪些人员,测试模块需要环境:是否需要安装新的软件及第三方库,运行的操作系统,测试配置等

10 工作计划

注释:以表格形式列举设计评阅,代码评阅,测试评阅,测试报告评阅,集成测试评阅,部署的相关时间点。

11 引用

注释:加入设计文档相关的文档或技术链接以供参考




测试文档

1 背景知识

注释: 加入这些文档(产品设计文档, 技术方法文档, 技术设计文档)的链接以供参考.  

2. 测试结果

注释: 

测试代码覆盖率:单元测试与集成测试

功能测试结果:多少个测试用例,是否全部通过。

稳定性测试结果:7*24,什么并发下稳定测试结果

性能测试结果:

3 测试用例

注释:用表格形式列举所有测试用例:输入,输出,期望结果,测试结果,是否通过

4 部署后检查

注释:从数据库,服务端口方面,原有模块及新上线功能模块白盒测试检查

5 参考


上一篇 下一篇

猜你喜欢

热点阅读