技术研发模版Word格式文档下载.docx
- 文档编号:18888719
- 上传时间:2023-01-02
- 格式:DOCX
- 页数:24
- 大小:34.08KB
技术研发模版Word格式文档下载.docx
《技术研发模版Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《技术研发模版Word格式文档下载.docx(24页珍藏版)》请在冰豆网上搜索。
,i,m,n=0,1,2,…表示i版本系列下的改动或升级)
第二部分目录索引
一、版本控制规则
二、立项
1、说明
2、模板
三、需求分析
四、可行性分析
五、功能定义
2,模板
六、概要设计
1'
硬件部分
(1)说明
(2)模板
2、软件部分
七、详细设计
八、测试
1、测试流程
2、测试要求
(1)硬件部分
(2)软件部分
3、测试模板
九、从研发到产品的过渡
(1)要求
十、技术支持
H^一、文档工作的评估与审核
(1)评估标准
(2)审核要点
第三部分内容
、版本控制规则
(1)版本状态:
Beta/测试版,Release/正式版,Changing/变更
(2)版本号:
版本号以三位数字表示,格式为(i=0,1,2,…,n;
jk=01,…,99)
a.Beta版,i=0
b.第一次正式发布的Release版,
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)。
而立项之后的研发管理活动是保证项目团队“正确地做事情”(do
thingsright)。
"
正确的决策"
+"
正确地执行"
才有可能产生好的产品。
1、说明:
(1)立项:
任何一次研发工作的启动,包括全新的项目和在以往的项目基础上进行升级或改版的项目,都需要进行立项的工作。
(2)项目分级:
为了明晰立项的工作,使之有条理,可操作,所以将项目区分为一级项目和二级项目两个不同的等级
a、一级项目:
包括全新的项目的启动,原有项目的重大改版和升级
b、二级项目:
在以往项目的基础上进行的非重大的版本修改和完善
(3)项目审批:
a、所有一级项目必须由项目负责人提交项目申请计划书,并就项目的相关情况向总经理和技术总监书面陈述或面对面沟通,得
到总经理和技术总监的审批签字后方能启动;
b、一级项目必须附加需求分析与可行性分析
c、二级项目可以由部门经理指定或由项目负责人申请得到部门经理审批签字后即可执行,不必交由总经理和技术总监审批签字;
d、对于二级项目,必须将项目计划申请书(纸介质)交由技术文档负责人归档,总经理及技术总监对二级项目的进展情况具有知
情权,而项目负责人具有向总经理和技术总监汇报(主动或被动)项目相关情况的义务;
e、项目申请计划书一式两份:
纸介质文档与电子文档。
纸介质文档作为技术档案由专门负责人员备份归档。
电子文档按规范要求
存储在公司指定的文档服务器上。
(4)权利,责任与义务
a、总经理,技术总监,部门经理对其所具有审批权限的项目申请计划书具有否决的权利;
b、项目申请人有权要求否决人说明被否决的理由,而且否决人必须在被否决的项目申请计划书中陈述否决理由;
c、具有审批权限的人对于项目的合理性,需求性,可行性等判断负有全权责任;
2、项目申请计划书
项目申请计划书/立项建议书
项目编号
EPF2003NOX-01
级别
由一级项目□二级项目
类另U
口指定项目翌申请项目
版本说明
申请人
Su
申请日期
2003-8-18
负责人
组成员
Su,Zhang,Yu
项目名称
基于GPRS勺图像传输
产品名称
G-BIU(Hardware,GPRS-BasedImageUnit),
G-BIUST(Software,G-BIUSupportToolkit)
理由陈述
资源配置需求
成本简要核算
(暂时Rj』、添此项)
目标
近期
(年月日~年月日)
中长期
远期
问题与解决
问题
(在此陈述进行该项目可能遇到和需要解决的问题,除了技术层面外,还包括设备,人员配备等方方面面的主要问题)
解决方法
针对以上的问题,提出解决建议
备注说明
审批结果
口通过□否决审批日期
审批人签字
审批意见
三、需求分析:
如果说立项管理是为了解决dorightthings和dothingsright的问题,那么需求分析就是要解决dowhatthings的问题。
需
求产生目标,目标引领方向。
好的需求分析不仅要解决“需要做什么”,同时明确“什么不需要做”。
最好的,可能产生最大利益的产品
是“恰如其分”的产品。
所谓“恰如其分”就是:
产品的功能恰好满足那些特定的需求,产品功能不多也不少。
一般的情况下,总结出
“需好做什么”比区分“什么不需要做”要来的容易,但“什么不需要做”的界定往往会影响到成本投入和利益产出的比例。
(1)需求分析工作的安排:
进行一项产品的开发工作的一般流程应该是:
市场调查一需求分析一可行性研究一立项审核一概要设计
(总体设计)一详细设计一单元测试一集成测试一修改完善一项目评估,审核一批量生产一投放市场一技术支持与售后服务。
(2)需求的种类:
需求的本质上都来源于市场,但是在具体表现上又有所不同。
有的需求直接由用户提出,目标明确;
而有些需求则是我们从市场的零星反馈中总结出来的,带有预见性和自主性。
(3)需求分析的主要目的:
从市场的反馈或对市场的观察与预见中总结出市场的需求,并用理性的思维对这些需求进行分析和总结,
将需求明确,为后面的工作奠定基础。
(4)需求分析的作用:
需求分析是市场与技术的转换点。
经过需求分析后,工作的重心即由市场转移到技术,明确的需求分析是真正进行研发工作的起点,是进行产品开发一系列后序工作的基础。
(5)需求在进行研发的过程中如果发生变更,需要填写“需求变更说明书”
需求分析说明书/报告
配置编号
EPF2003NOX-02作者提交时间2003-8-18
目标用户
陈述产品的目标用户
需求陈述
内容
级别
1
□A口B口C
2
简单描述针对需求的初步解决意向
附加说明
讨论意见
项目评审委
员会结论
A需求:
紧急,重要
B需求:
重要,不紧急
C需求:
非A,B类需求
需求/功能变更说明书
EPF2003NOX-02-01
历史版本
改后版本
G-BIU(GPRS-BasedImageUnit)
时间
2003-8-19
变更内容
变更属性
变更原因
是否允许
变更项
□A
口D口M
口是□否
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、硬件部分:
为了简化操作流程,使文档既能体现设计原理与设计思路,又具有良好的操作性,所以对于硬件部分的概要设计要求只要求给出原理图,思路描述,主要器件,主要器件的技术参数。
概要设计报告(H)
EPF2003NOX-05-H负责人
时间2003-8-19
原理图
在此添入原理图配置编号,原理图配置编号由技术文档秘书统一编制,编号编制方法待讨论,
(改动:
EPF2003NOX-05-H-01)
设计思路描述
基本要求:
负责人必须对关键的设计思想进行清楚的描述
主要器件
及技术参数
器件名称
用途
技术参数参考
主要参考资料
资料名称
来源
编勺
按照重要,关键性器件一>主要器件一>辅助性器件的顺序描述主要器件及技术参数栏。
2、软件部分:
软件部分的概要设计需要提交的报告有:
概要设计报告,界面设计报告,数据库设计报告
概要设计报告(S)
EPF2003NOX-05-S-01
作者
提交时间2003-8-19
当前版本
,,
术语与缩写解释
术语
解释
G-BIAS
即GPS-BasedIntegratedApplicationSystem
设计约束
*系统应当遵循的标准或规范
*软硬件环境(包括运行环境与开发环境)的约束
*接口/协议的约束
*用户界面的约束
*软件质量约束,包括正确性,健壮性,可靠性,效率(性能),易用性,清晰性,安全性,可扩展性,兼容
性,可移植性。
(如果有约束,逐一填写;
如果不存在约束,可不填)
设计策略
*扩展策略一为了方便扩展,现在采取的措施
*复用策略一说明本系统在当前以及将来的复用策略
*折衷策略一如果存在两个主要目标难以同时优化时如何折衷
系统总体结构描
述
开发环境配置
软件
硬件
网络
主要升发工具及语言
运仃环境要求
包括操作系统,第三方软件平台
数据库
参考资料
资料
其他说明
*如果系统比较复杂,首先将系统分解成若干子系统,对各个子系统绘制逻辑图,说明子系统的功能
*解释如何以及为什么如此分解系统
*说明子系统间如何如何协调工作,以实现元系统的功能
*如果子系统N仍然需要分解成模块,则
(1)绘制模块逻辑图
(2)陈述分解理由
(3)说明模块间如何协调工作,从而实现子系统的功能
*如果系统相对简单,给出用工具Visio绘制的系统逻辑结构图
界面设计报告
界面设计报告(S)
EPF2003NOX-05-S-02
界面结构及风格
绘制界面视图
(1)主界面:
需要给出界面元素的作用与操作
(2)子界面:
给出子界面的主要作用
第二方界面兀素
控件,组件,函数
库及其来源
名称
作用
数据库设计报告主要完成数据库的物理设计,即表的结构设计与对表结构的第三范式处理
数据库设计报告(S)
EPF2003NOX-05-S-03
表汇总
表名
A
B
C
列名
数据类型(经度范围)
约束条件
备注
补充说明
角色与权限
可以访问的表与列
访问权限
角色A
角色B
七、详细设计
1.硬件部分,硬件部分的详细设计主要体现在下位机软件的代码上,所以详细设计文档的内容集中在对代码的要求上面,代码要求
(1)所有的代码模块必须用文件的方式组织
(2)在每一个文件中的开头以注释的方式写如下内容:
Copyright(c)2003,**公司,硬件开发部
*Allrightsreserved
*文件名称:
*文件标识:
文件标识可以统一规定,也可以自己选择
*摘要:
简要描述该文件的内容
*
*当前版本:
*作者:
输入作者或修改者的名字
*完成日期:
*取代版本:
*原作者:
(3)如果用C语言开发
a.必须将.H文件与.C文件区分开来,在.H中定义全局变量,结构,联合,自定义群体等,如链表;
函数的声明
b.在定义函数体前,以注释方式写如下内容
*函数的主要作用
*输入输出参数的含义
(4)全局变量的定义要集中,并说明用途
(5)主要变量必须在定义之后说明用途
(6)所有函数的定义必须给出函数的作用
详细设计报告(用
EPF2003NOX-06-H
时间2003-8-20
所有函数定义列
表
函数定义
主要用途
外部接口
流程图
外部接口/库
接口/库名
通讯协议
X
内部通讯协议
外部协议
填入内部通讯协议文档配置编号
如SMPPS7等
2.软件部分
软件部分的详细设计报告内容相对较多,所以设计报告分成若干部分
详细设计报告(SPD
EPF2003NOX-06-S-01
系统架构
如果能用图表示,必须用图表示,不好用图表示的部分,可以用文字描述
主要控件/组件
使用
类/结构
类名
主要的数据结构
数据结构
描述
关键算法
算法
实现过程
自定义消息
消息名称
消息ID
Invoke条件
主要控件一栏包括:
第三方控件,如MapXFlatStyle等,在使用此类控件中必须给出此控件的作用,来源如购买,Share等;
必须简要描
述此类控件的使用方法,如果控件本身带有资料描述,必须以附录资料的形式给出资料
主要的类/结构:
程序中所有用到的类,包括自己独立封装的类,从固有的类中集成下来的类,简要陈述类的作用。
如果
回使用建模工具,则需要用类图来推f述出类的结构,继承关系等。
主要的数据结构,如结构(记录),链表,栈,队列,图,树及作用
关键算法:
关键不是复杂,任何一个程序都有关键算法,这里的“关键”的引申含义为:
主要,重要。
必须给出算法的
作用与实现的思路过程描述
详细设计报告(SP2
EPF2003NOX-06-S-02
接口
参数描述
()
内部接口(方法/
函数/过程)
宿主
所谓接口,不过是函数在特定概念下的称谓。
外部接口,程序中所使用的外部函数。
例如,在使用MapX空件时,需要使
用()接口函数来计算距离,那么既需要描述出()的作用与参数描述
内部接口:
所谓宿主,即指包括此接口的自定义或从固有类继承而来的类,如果是全局函数,宿主栏填写G
详细设计报告(SP3
EPF2003NOX-06-S-03
EPF2003NOX-06-S-03-CF-01
流程图主要描述程序的关键流程,对关键的判断依据是:
如果没有此流程图描述,则对他人理解此程序存有障碍
由于流程图一般占用较大空间,所以将其作为详细设计报告(SP3)的附件
八、测试
bug,还可以发
1/4~1/3。
测试是产品研发中相当重要的部分,在IT领域越来越受到人们的普遍重视。
高水平的测试不仅可以发现表面存在的
现产品内部设计缺陷,消除潜在隐患,提出修改完善建议等。
测试,在产品研发中所占用的时间比例大约是整个研发周期的
但是,鉴于公司的实际情况,需要制定有效的,符合公司使用要求,实用的测试规程。
产品测试规定为两个部分
(1)内部测试:
即指开发人员自己进行的测试工作,基本要求是在一般情况下,产品能够正常启动运行即可
(2)产品测试:
当内部测试完成以后,测试人员进行产品测试,测试的依据为项目建议书,概要设计报告,功能定义报告,详细设计报告
(3)集成测试:
及产品的各个功能部分一起运作下的测试
产品测试在目前看来,最主要的是要测试产品的功能,测试功能的主要依据则是功能定义报告。
在产品测试前,开
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 技术 研发 模版