技术研发文档模版010.docx
《技术研发文档模版010.docx》由会员分享，可在线阅读，更多相关《技术研发文档模版010.docx（25页珍藏版）》请在冰豆网上搜索。
技术研发文档模版010
第一局部总纲
一﹑目的：
（1）标准公司内部技术研发工作的文档管理；
（2）保持技术研发工作的完整性与连续性；
（3）防止技术流失，减少风险；
（4）使技术文档成为技术研发工作中的重要组成局部。
二﹑适用范围：
本公司内部一切与技术研发有关的部门及个人，包括
（1）总经理；
（2）技术部门经理或负责人；
（3）研发工程师；
（4）测试工程师；
（5）技术支持工程师。
三﹑目标：
通过切实可行的文档管理标准，使得研发工作透明，明确，有章可循，合作无障碍，衔接环节畅通；使得所有的研发产品从开始研发——研发进程——测试——修改——阶段性结束——产品转化——升级维护过程中的所有环节都得以在相应的文档中表达。
四﹑〔〕。
五﹑制定原那么：
（1）实用：
鉴于公司目前的状况，通用性的开发模板〔如国标〕在很大程度上对于本公司并不实用，所以本标准将不会完全照搬此类模板，而是根据公司的具体情况制定公司内部的标准；
（2）可行：
可行性是该标准的起码要求，没有可行性的标准不能成为真正的“标准〞；
（3）高效：
如果将国标中的所有标准内容都纳入本标准，一定可以到达目的，实现目标。
但是，同时必将为相关人员增添大量的工作量，而且很多工作对于本公司来说是冗余，从而造成相关人员的抵触情绪，使标准难于贯彻。
所以，本标准应力求在尽量少的模板中表达尽量多的内容；
（4）科学：
本标准的制定虽然不完全照搬其他通用性的标准，但将大量参照通用标准，特别是国标中的某些局部内容，不是抛弃国标，而是以国标为原那么，以保证科学性；
（5）建立在广泛意见根底上：
本标准并非公司某一个人单方面的意愿，而是从公司利益出发，全体相关人员共同参与，集体的结晶。
六﹑实行过程及生效日期：
（1）标准为标准草稿，草稿制订完成后，将在相关部门和相关人员中进行传阅和广泛征求意见。
经过三次全体相关人员参与讨论和修改，由总经理审批签字后的标准版本为0.40。
（2）标准〔〕标准要求进行文档的相关操作。
在此过程中，如果发现标准〔i=1,2,3,…n,〕〔j=1,2,3,…,n〕。
（3）标准将作为公司内部与技术研发工作相关的所有人员在今后相当一段时间内共同遵守的标准，并且将文档的撰写工作作为技术研发的一个重要组成局部正式纳入到技术研发工作中。
（4）标准将具有强制性和高约束力。
〔注：
Vi.00，i=0,1,2,…表示i版本系列；Vi.mn，i，m，n=0，1，2，…表示i版本系列下的改动或升级〕
第二局部目录索引
一﹑版本控制规那么
二﹑立项
1﹑说明
2﹑模板
三﹑需求分析
1﹑说明
2﹑模板
四﹑可行性分析
1﹑说明
2﹑模板
五﹑功能定义
1﹑说明
2.模板
六﹑概要设计
1﹑硬件局部
（1）说明
（2）模板
2﹑软件局部
（1）说明
（2）模板
七﹑详细设计
1﹑硬件局部
（1）说明
（2）模板
2﹑软件局部
（1）说明
（2）模板
八﹑测试
1﹑测试流程
2﹑测试要求
（1）硬件局部
（2）软件局部
3﹑测试模板
（1）硬件局部
（2）软件局部
九﹑从研发到产品的过渡
（1）要求
（2）模板
十﹑技术支持
（1）要求
（2）模板
十一﹑文档工作的评估与审核
（1）评估标准
（2）审核要点
第三局部内容
一﹑版本控制规那么
（1）版本状态：
Beta/测试版，Release/正式版，Changing/变更
（2）〔i=0，1，2，…，n；jk=01，…，99〕
a.Beta版，i=0
b.
c.用Changing来表示Beta或Release版本的修改或升级
d.小的改动或升级i，j保持不变，只增加k值即可，k的升值幅度为修改或升级处的数目，当k值到达或增加至9时，j=j+1，k=0
e.比拟大的改动如，一次修改或升级处的数目>10，功能性的增加或改变，那么i保持不变，增加j值。
如果是功能性的修改或变动，每有一项j+1；如果是>10的非功能性的修改，每10处修改，j+1，个数局部用k来表示
f.重大变动，i值增加
g.累计功能变动超过百次，i+1，jk=00
二﹑立项
立项管理〔ProjectInitializationManagement，PIM〕的目的是采纳符合公司最大利益的立项建议，通过立项管理使该建议成为正式的工程〔合法化〕。
杜绝不符合公司最大利益的立项建议被采纳，防止公司人力资源的，资金，时间的浪费。
立项管理是决策行为，目标是“做正确的事情〞〔dorightthings〕。
而立项之后的研发管理活动是保证工程团队“正确地做事情〞（dothingsright）。
“正确的决策〞+“正确地执行〞才有可能产生好的产品。
1﹑说明：
（1）立项：
任何一次研发工作的启动，包括全新的工程和在以往的工程根底上进行升级或改版的工程，都需要进行立项的工作。
（2）工程分级：
为了明晰立项的工作，使之有条理，可操作，所以将工程区分为一级工程和二级工程两个不同的等级
a﹑一级工程：
包括全新的工程的启动，原有工程的重大改版和升级
b﹑二级工程：
在以往工程的根底上进行的非重大的版本修改和完善
（3）工程审批：
a﹑所有一级工程必须由工程负责人提交工程申请方案书，并就工程的相关情况向总经理和技术总监书面陈述或面对面沟通，得到总经理和技术总监的审批签字前方能启动；
b﹑一级工程必须附加需求分析与可行性分析
c﹑二级工程可以由部门经理指定或由工程负责人申请得到部门经理审批签字后即可执行，不必交由总经理和技术总监审批签字；
d﹑对于二级工程，必须将工程方案申请书〔纸介质〕交由技术文档负责人归档，总经理及技术总监对二级工程的进展情况具有知情权，而工程负责人具有向总经理和技术总监汇报〔主动或被动〕工程相关情况的义务；
e﹑工程申请方案书一式两份：
纸介质文档与电子文档。
纸介质文档作为技术档案由专门负责人员备份归档。
电子文档按标准要求存储在公司指定的文档效劳器上。
（4）权利，责任与义务
a﹑总经理，技术总监，部门经理对其所具有审批权限的工程申请方案书具有否决的权利；
b﹑工程申请人有权要求否决人说明被否决的理由，而且否决人必须在被否决的工程申请方案书中陈述否决理由；
c﹑具有审批权限的人对于工程的合理性，需求性，可行性等判断负有全权责任；
2﹑工程申请方案书
工程申请方案书/立项建议书
工程编号
EPF2003NOX-01
级别
一级工程□二级工程
类别
□指定工程
申请工程
版本说明
申请人
Su
申请日期
2003-8-18
负责人
Su
组成员
Su,Zhang,Yu
工程名称
基于GPRS的图像传输
产品名称
G-BIU〔Hardware，GPRS-BasedImageUnit〕，G-BIUST（Software，G-BIUSupportToolkit）
理由陈述
资源配置需求
本钱简要核算
〔暂时可不添此项〕
目标
近期
〔年月日~年月日〕
中长期
〔年月日~年月日〕
远期
〔年月日~年月日〕
问题与解决
问题
〔在此陈述进行该工程可能遇到和需要解决的问题，除了技术层面外，还包括设备，
人员配备等方方面面的主要问题〕
解决方法
针对以上的问题，提出解决建议
备注说明
审批结果
□通过□否决
审批日期
审批人签字
审批意见
三﹑需求分析：
如果说立项管理是为了解决dorightthings和dothingsright的问题，那么需求分析就是要解决dowhatthings的问题。
需求产生目标，目标引领方向。
好的需求分析不仅要解决“需要做什么〞，同时明确“什么不需要做〞。
最好的，可能产生最大利益的产品是“恰如其分〞的产品。
所谓“恰如其分〞就是：
产品的功能恰好满足那些特定的需求，产品功能不多也不少。
一般的情况下，总结出“需好做什么〞比区分“什么不需要做〞要来的容易，但“什么不需要做〞的界定往往会影响到本钱投入和利益产出的比例。
1﹑说明：
（1）需求分析工作的安排：
进行一项产品的开发工作的一般流程应该是：
市场调查—需求分析—可行性研究—立项审核—概要设计〔总体设计〕—详细设计—单元测试—集成测试—修改完善—工程评估，审核—批量生产—投放市场—技术支持与售后效劳。
（2）需求的种类：
需求的本质上都来源于市场，但是在具体表现上又有所不同。
有的需求直接由用户提出，目标明确；而有些需求那么是我们从市场的零星反应中总结出来的，带有预见性和自主性。
（3）需求分析的主要目的：
从市场的反应或对市场的观察与预见中总结出市场的需求，并用理性的思维对这些需求进行分析和总结，将需求明确，为后面的工作奠定根底。
（4）需求分析的作用：
需求分析是市场与技术的转换点。
经过需求分析后，工作的重心即由市场转移到技术，明确的需求分析是真正进行研发工作的起点，是进行产品开发一系列后序工作的根底。
（5）需求在进行研发的过程中如果发生变更，需要填写“需求变更说明书〞
2﹑模板1
需求分析说明书/报告
配置编号
EPF2003NOX-02
作者
提交时间
2003-8-18
目标用户
陈述产品的目标用户
需求陈述
内容
级别
1
□A□B□C
2
解决方法
简单描述针对需求的初步解决意向
附加说明
讨论意见
工程评审委员会结论
A需求：
紧急，重要
B需求：
重要，不紧急
C需求：
非A,B类需求
模板2
需求/功能变更说明书
配置编号
EPF2003NOX-02-01
历史版本
改后版本
产品名称
G-BIU（GPRS-BasedImageUnit）
负责人
时间
2003-8-19
变更项
变更内容
变更属性
变更原因
是否允许
1
□A□D□M
□是□否
2
3
附加说明
变更属性中A代表增加，D代表删除，M代表修改
工程评审委员会结论
工程评审委员会给出是否进行变更的意见，由评委会主席签字生效
四﹑技术可行性分析
可行性分析是进行研发工作的重要环节，详细周到的可行性分析与论证为即将启动的工程把握一道至关重要的关口。
技术可行性分析要求从技术层面上分析论证工程的可行性，即能否“做得到，做得快，做得好〞。
可行性分析报告由工程申请责任人总结，撰写，并提交到工程评审委员会审阅。
有工程申请/建议书，需求定义和需求报告仍然不能进行实质性的开发，必须要进行可行性分析，可行性分析包括几个局部
（1）市场分析：
a.分析总结市场的开展趋势，说明产品处于市场的什么开展阶段，粗略估计产品的生命周期
b.本产品和同类产品的价格比对
c.统计产品当前市场总额，竞争对手所占的份额，分析本产品有哪些比拟优势，可能占有多少市场份额
d.为产品定位，即确定产品用户群，分析产品消费群体特征，消费方式及影像市场的因素分析
（2）政策分析
a.分析有无相关政策“支持〞或“限制〞
b.分析有无地方政府或其他机构的“扶持〞或“干扰〞
（3）竞争分析
a.分析竞争对手的市场状况，产品的优点与缺点
b.预测可能形成的竞争的特点与周期
（4）技术可行性分析
（5）时间和资源可行性分析
a.按正常的运作，从产品开发到投入市场，时间上是否来得及
b.方案中的人员能否及时到位
c.方案中的软硬件需求能否及时到位
d.本钱核算能否负担得起
（6）知识产权分析
a.是否已经存在某些专利将阻碍本产品的开发与推广
b.产品能否得到知识产权的保护
技术可行性分析报告
配置编号
EPF2003NOX-03
报告撰写人
提交时间
2003-8-19
可行性论述
由工程负责人总结，撰写
主要从能否“做得到〞，“做得快〞，“做得好〞的角度分析
如果能“做得到〞，“做得快〞，“做得好〞，需要给出通过怎样的方法保证
如果不能，需要给出理由
讨论意见
由技术秘书总结
撰写人提交报告后到工程评审委员会后，工程评审委员组织人员对报告的“可行性论述〞展开讨论，技术秘书总结各方意见，记述在此栏
工程评审委员会意见
工程评审委员会给出整体意见，供决策人参考
五﹑功能定义
1.说明：
功能定义是对dowhatthings的明确界定，是针对明确的需求来定义产品功能的过程。
是产品设计的实质性阶段，此后的研发工作将围绕功能定义展开，功能定义说明书是参与研发的人员进行工作的根底文档，是产品测试与评审，用户手册的编制，市场宣传的主要依据。
2.模版
功能定义说明书
配置编号
EPF2003NOX-04
负责人
提交时间
2003-8-19
功能项
功能描述
1
2
3
附加说明
工程评审委员会意见
工程评审委员会给出整体意见，供决策人参考
六﹑概要设计
1、硬件局部：
为了简化操作流程，使文档既能表达设计原理与设计思路，又具有良好的操作性，所以对于硬件局部的概要设计要求只要求给出原理图，思路描述，主要器件，主要器件的技术参数。
概要设计报告〔H〕
配置编号
EPF2003NOX-05-H
负责人
时间
2003-8-19
原理图
在此添入原理图配置编号，原理图配置编号由技术文档秘书统一编制，编号编制方法待讨论，
〔改动：
EPF2003NOX-05-H-01〕
设计思路描述
根本要求：
负责人必须对关键的设计思想进行清楚的描述
主要器件
及技术参数
器件名称
用途
技术参数参考
1
2
3
主要参考资料
资料名称
来源
编号
1
2
●按照重要，关键性器件—>主要器件—>辅助性器件的顺序描述主要器件及技术参数栏。
●每一种参考资料都有自己的编号如：
EPF2003NOX-05-H-R1
2、软件局部:
软件局部的概要设计需要提交的报告有：
概要设计报告，界面设计报告，数据库设计报告
概要设计报告〔S〕
配置编号
EPF2003NOX-05-S-01
作者
提交时间
2003-8-19
当前版本
历史版本
术语与缩写解释
术语
解释
G-BIAS
即GPS-BasedIntegratedApplicationSystem
设计约束
﹡系统应当遵循的标准或标准
﹡软硬件环境〔包括运行环境与开发环境〕的约束
﹡接口/协议的约束
﹡用户界面的约束
*软件质量约束，包括正确性，健壮性，可靠性，效率〔性能〕，易用性，清晰性，平安性，可扩展性，兼容性，可移植性。
〔如果有约束，逐一填写；如果不存在约束，可不填〕
设计谋略
﹡扩展策略—为了方便扩展，现在采取的措施
﹡复用策略—说明本系统在当前以及将来的复用策略
﹡折衷策略—如果存在两个主要目标难以同时优化时如何折衷
系统总体结构描述
开发环境配置
软件
硬件
网络
主要开发工具及语言
运行环境要求
软件
包括操作系统，第三方软件平台
硬件
网络
数据库
参考资料
资料
配置编号
来源
1
2
其他说明
﹡如果系统比拟复杂，首先将系统分解成假设干子系统，对各个子系统绘制逻辑图，说明子系统的功能
*解释如何以及为什么如此分解系统
﹡说明子系统间如何如何协调工作，以实现元系统的功能
﹡如果子系统N仍然需要分解成模块，那么
（1）绘制模块逻辑图
（2）陈述分解理由
（3）说明模块间如何协调工作，从而实现子系统的功能
﹡如果系统相对简单，给出用工具Visio绘制的系统逻辑结构图
界面设计报告
界面设计报告〔S〕
配置编号
EPF2003NOX-05-S-02
作者
时间
2003-8-19
当前版本
历史版本
界面结构及风格
绘制界面视图
（1）主界面：
需要给出界面元素的作用与操作
（2）子界面：
给出子界面的主要作用
第三方界面元素控件，组件，函数库及其来源
名称
来源
作用
1
2
数据库设计报告主要完成数据库的物理设计，即表的结构设计与对表结构的第三范式处理
数据库设计报告〔S〕
配置编号
EPF2003NOX-05-S-03
作者
时间
2003-8-19
当前版本
历史版本
表汇总
表名
功能描述
1
A
2
B
3
C
A
列名
数据类型〔经度范围〕
约束条件
备注
1
2
补充说明
角色与权限
可以访问的表与列
访问权限
角色A
角色B
七﹑详细设计
1.硬件局部，硬件局部的详细设计主要表达在下位机软件的代码上，所以详细设计文档的内容集中在对代码的要求上面，代码要求
（1）所有的代码模块必须用文件的方式组织
（2）在每一个文件中的开头以注释的方式写如下内容：
Copyright〔c〕2003，**公司，硬件开发部
*Allrightsreserved
*文件名称：
*文件标识：
文件标识可以统一规定，也可以自己选择
*摘要：
简要描述该文件的内容
*
*当前版本：
*作者：
输入作者或修改者的名字
*完成日期：
*
*取代版本：
*原作者：
*完成日期：
（3）如果用C语言开发
a.必须将.H文件与.C文件区分开来，在.H中定义全局变量，结构，联合，自定义群体等，如链表；函数的声明
b.在定义函数体前，以注释方式写如下内容
*函数的主要作用
*输入输出参数的含义
（4）全局变量的定义要集中，并说明用途
（5）主要变量必须在定义之后说明用途
（6）所有函数的定义必须给出函数的作用
详细设计报告〔H〕
配置编号
EPF2003NOX-06-H
作者
时间
2003-8-20
当前版本
历史版本
所有函数定义列表
函数定义
主要用途
外部接口
1
2
流程图
外部接口/库
接口/库名
主要用途
来源
1
2
通讯协议
内部通讯协议
外部协议
1
填入内部通讯协议文档配置编号
如SMPP，S7等
2
其他说明
软件局部的详细设计报告内容相对较多，所以设计报告分成假设干局部
详细设计报告〔SP1〕
配置编号
EPF2003NOX-06-S-01
作者
时间
2003-8-20
当前版本
历史版本
系统架构
如果能用图表示，必须用图表示，不好用图表示的局部，可以用文字描述
主要控件/组件
名称
作用
来源
使用
1
2
类/结构
类名
作用
1
2
主要的数据结构
数据结构
描述
1
2
关键算法
算法
作用
实现过程
1
2
自定义消息
消息名称
消息ID
Invoke条件
1
2
其他说明
主要控件一栏包括：
●第三方控件，如MapX，FlatStyle等，在使用此类控件中必须给出此控件的作用，来源如购置，Share等；必须简要描述此类控件的使用方法，如果控件本身带有资料描述，必须以附录资料的形式给出资料
●主要的类/结构：
程序中所有用到的类，包括自己独立封装的类，从固有的类中集成下来的类，简要陈述类的作用。
如果回使用建模工具，那么需要用类图来描述出类的结构，继承关系等。
●主要的数据结构，如结构〔记录〕，链表，栈，队列，图，树及作用
●关键算法：
关键不是复杂，任何一个程序都有关键算法，这里的“关键〞的引申含义为：
主要，重要。
必须给出算法的作用与实现的思路过程描述
详细设计报告〔SP2〕
配置编号
EPF2003NOX-06-S-02
作者
时间
2003-8-20
当前版本
历史版本
外部接口
接口
作用
参数描述
1
Map.Distance（）
2
3
内部接口〔方法/函数/过程〕
接口
作用
宿主
参数描述
1
2
3
其他说明
●所谓接口，不过是函数在特定概念下的称谓。
外部接口，程序中所使用的外部函数。
例如，在使用MapX控件时，需要使用Map.Distance（）接口函数来计算距离，那么既需要描述出Map.Distance（）的作用与参数描述
●内部接口：
所谓宿主，即指包括此接口的自定义或从固有类继承而来的类，如果是全局函数，宿主栏填写G
详细设计报告〔SP3〕
配置编号
EPF2003NOX-06-S-03
作者
时间
2003-8-20
当前版本
历史版本
流程图
配置编号
1
EPF2003NOX-06-S-03-CF-01
2
其他说明
●流程图主要描述程序的关键流程，对关键的判断依据是：
如果没有此流程图描述，那么对他人理解此程序存有障碍
●由于流程图一般占用较大空间，所以将其作为详细设计报告〔SP3〕的附件
八﹑测试
测试是产品研发中相当重要的局部，在IT领域越来越受到人们的普遍重视。
高水平的测试不仅可以发现外表存在的bug，还可以发现产品内部设计缺陷，消除潜在隐患，提出修改完善建议等。
测试，在产品研发中所占用的时间比例大约是整个研发周期的1/4~1/3。
但是，鉴于公司的实际情况，需要制定有效的，符合公司使用要求，实用的测试规程。
产品测试规定为两个局部
（1）内部测试：
即指开发人员自己进行的测试工作，根本要求是在一般情况下，产品能够正常启动运行即可
（2）产品测试：
当内部测试完成以后，测试人员进行产品测试，测试的依据为工程建议书，概要设计报告，功能定义报告，详细设计报告
（3）集成测试：
及产品的各个功能局部一起运作下的测试
产品测试在目前看来，最主要的是要测试产品的功能，测试功能的主要依据那么是功能定义报告。
在产品测试前，开发人员必须提供一套测试样本。
产品测试报告〔HP1〕
配置编号
EPF2003NOX-07-H-01
测试人负责人
测试时间
2003-8-21
产品名称
版本
历史版本
测试环境及工具
测试项
功能
是否通过
备注
1
□Yes□No
2
遗留问题
问题描述
问题级别
原因分析
1
□R□Y□O
升级会员 