技术研发文档.docx
- 文档编号:590918
- 上传时间:2022-10-11
- 格式:DOCX
- 页数:23
- 大小:28.78KB
技术研发文档.docx
《技术研发文档.docx》由会员分享,可在线阅读,更多相关《技术研发文档.docx(23页珍藏版)》请在冰豆网上搜索。
技术研发文档
第一部分总纲
目的:
1)规范公司内部技术研发工作的文档管理;
2)保持技术研发工作的完整性与连续性;
3)防止技术流失,减少风险;
4)使技术文档成为技术研发工作中的重要组成部分。
1)
2)
3)
4)
5)
适用范围:
本公司内部一切与技术研发有关的部门及个人,包括总经理;
技术部门经理或负责人;
研发工程师;
测试工程师;技术支持工程师。
三﹑目标:
通过切实可行的文档管理规范,使得研发工作透明,明确,有章可循,合作无障碍,衔接环节畅通;使得所有的研发产品从开始研发——研发进程——测试——修改——阶段性结束——产品转化——升级维护过程中的所有环节都得以在相应的文档中体现。
四﹑版本:
E2003V0.10(简称V0.10)五﹑制定原则:
(1)实用:
鉴于公司目前的状况,通用性的开发模板(如国标)在很大程度上对于本公司并不实用,所以本规范将不会完全照搬此类模板,而是根据公司的具体情况制定公司内部的标准;
(2)可行:
可行性是该标准的起码要求,没有可行性的标准不能成为真正的“标准”;
所以,
(3)高效:
如果将国标中的所有规范内容都纳入本标准,一定可以达到目的,实现目标。
但是,同时必将为相关人员增添大量的工作量,而且很多工作对于本公司来说是冗余,从而造成相关人员的抵触情绪,使标准难于贯彻。
本标准应力求在尽量少的模板中体现尽量多的内容;
(4)科学:
本标准的制定虽然不完全照搬其他通用性的标准,但将大量参照通用标准,特别是国标中的某些部分内容,不是抛弃国标,而是以国标为原则,
以保证科学性;
(5)建立在广泛意见基础上:
本标准并非公司某一个人单方面的意愿,而是从公司利益出发,全体相关人员共同参与,集体的结晶。
六﹑实行过程及生效日期:
(1)V0.10版的规范为规范草稿,草稿制订完成后,将在相关部门和相关人员中进行传阅和广泛征求意见。
经过三次全体相关人员参与讨论和修改,由总经理审批签字后的规范版本为0.40。
(2)V0.40为试用版本,在V0.40的试用过程中,将要求并给予相关人员以合理的时间尽量按照V0.40版的要求规范修改,补充和完善V0.40版以前(包括V0.10以前欠缺的文档)的有价值文档。
在此期间,如有新的研发工作开始启动,将要求相关人员按照V0.40版的规范要求进行文档的相关操作。
在此过程中,如果发现规范中需要修改和补充之处,每经过一次大幅度的修改,版本即升级到V0.5i(1,2,3,⋯n,),每经过一次小的修改或补充,版本将升级为V0.4j(1,2,3,⋯)。
(3)V1.00为正式版本。
此时的版本已经经过讨论,试用,修改,补充和不断完善,并且V1.00以前欠缺的文档与V0.40试用过程中的文档都已经按照V0.40版本的要求整理完毕,此时的V0.40版已经成熟,可以整体升级到V1.00版。
V1.00版本的文档规范将作为公司内部与技术研发工作相关的所有人员在今后相当一段时间内共同遵守的规范,并且将文档的撰写工作作为技术研发的一个重要组成部分正式纳入到技术研发工作中。
(4)V1.00规范将具有强制性和高约束力。
(注:
.00,0,1,2,⋯表示i版本系列;,i,m,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)版本状态:
测试版,正式版,变更
(2)版本号:
版本号以三位数字表示,格式为(0,1,2,⋯,n;01,⋯,99)
a.版,0
b.第一次正式发布的版,1.00
c.用来表示或版本的修改或升级
d.小的改动或升级i,j保持不变,只增加k值即可,k的升值幅度为修改或升级处的数目,当k值达到或增加至9时,1,0
e.比较大的改动如,一次修改或升级处的数目>10,功能性的增加或改变,则i保持不变,增加j值。
如果是功能性的修改或变动,每有一项1;如果是>10的非功能性的修改,每10处修改,1,个数部分用k来表示
f.重大变动,i值增加
g.累计功能变动超过百次,1,00
二﹑立项
立项管理(,)的目的是采纳符合公司最大利益的立项建议,通过立项管理使该建议成为正式的项目(合法化)。
杜绝不符合公司最大利益的立项建议被采纳,避免公司人力资源的,资金,时间的浪费。
立项管理是决策行为,目标是“做正确的事情”()。
而立项之后的研发管理活动是保证项目团队“正确地做事情”()。
“正确的决策”+“正确地执行”才有可能产生好的产品。
1﹑说明:
(1)立项:
任何一次研发工作的启动,包括全新的项目和在以往的项目基础上进行升级或改版的项目,都需要进行立项的工作。
(2)项目分级:
为了明晰立项的工作,使之有条理,可操作,所以将项目区分为一级项目和二级项目两个不同的等级a﹑一级项目:
包括全新的项目的启动,原有项目的重大改版和升级b﹑二级项目:
在以往项目的基础上进行的非重大的版本修改和完善
(3)项目审批:
a﹑所有一级项目必须由项目负责人提交项目申请计划书,并就项目的相关情况向总经理和技术总监书面陈述或面对面沟通,得到总经理和技术总监的审批签字后方能启动;
b﹑一级项目必须附加需求分析与可行性分析
c﹑二级项目可以由部门经理指定或由项目负责人申请得到部门经理审批签字
后即可执行,不必交由总经理和技术总监审批签字;
d﹑对于二级项目,必须将项目计划申请书(纸介质)交由技术文档负责人归档,总经理及技术总监对二级项目的进展情况具有知情权,而项目负责人具有向总经理和技术总监汇报(主动或被动)项目相关情况的义务;
e﹑项目申请计划书一式两份:
纸介质文档与电子文档。
纸介质文档作为技术档案由专门负责人员备份归档。
电子文档按规范要求存储在公司指定的文档服务器上。
(4)权利,责任与义务a﹑总经理,技术总监,部门经理对其所具有审批权限的项目申请计划书具有否决的权利;
b﹑项目申请人有权要求否决人说明被否决的理由,而且否决人必须在被否决的项目申请计划书中陈述否决理由;
c﹑具有审批权限的人对于项目的合理性,需求性,可行性等判断负有全权责
任;
2﹑项目申请计划书
项目申请计划书/立项建议书
项目编号
200301
级别
一级项目□二级项目
类别
□指定项目申请项目
版本说明
V0.10
申请人
申请日期
2003-8-18
负责人
组成员
项目名称
基于的图像传输
产称品名(,),(,)
理由陈述
资源配置需求
成本简要核算
(暂时可不添此项)
目标
近期(年月日~年月日)
中长期(年月日~年月日)
远期(年月日~年月日)
问题与解决
问题
(在此陈述进行该项目可能遇到和需要解决的问题,除了技术层面外,还包括设备,人员配备等方方面面的主要问题)
解决方
法
针对以上的问题,提出解决建议
备注说明
审批结果
□通过□否决审批日期
审批人签字
审批意见
三﹑需求分析:
如果说立项管理是为了解决和的问题,那么需求分析就是要解决的问题。
需求产生目标,目标引领方向。
好的需求分析不仅要解决“需要做什么”,同时明确“什么不需要做”。
最好的,可能产生最大利益的产品是“恰如其分”的产品。
所谓“恰如其分”就是:
产品的功能恰好满足那些特定的需求,产品功能不多也不少。
一般的情况下,总结出“需好做什么”比区分“什么不需要做”要来的容易,但“什么不需要做”的界定往往会影响到成本投入和利益产出的比例。
1﹑说明:
(1)需求分析工作的安排:
进行一项产品的开发工作的一般流程应该是:
市场调查—需求分析—可行性研究—立项审核—概要设计(总体设计)—详细设计—单元测试—集成测试—修改完善—项目评估,审核—批量生产—投放市场—技术支持与售后服务。
(2)需求的种类:
需求的本质上都来源于市场,但是在具体表现上又有所不同。
有的需求直接由用户提出,目标明确;而有些需求则是我们从市场的零星反馈中总结出来的,带有预见性和自主性。
(3)需求分析的主要目的:
从市场的反馈或对市场的观察与预见中总结出市场的需求,并用理性的思维对这些需求进行分析和总结,将需求明确,为后面的工作奠定基础。
(4)需求分析的作用:
需求分析是市场与技术的转换点。
经过需求分析后,工作的重心即由市场转移到技术,明确的需求分析是真正进行研发工作的起点,是进行产品开发一系列后序工作的基础。
(5)需求在进行研发的过程中如果发生变更,需要填写“需求变更说明书”
2﹑模板1
需求分析说明书/报告
配置编号
200302作者提交时间2003-8-18
目标用户
陈述产品的目标用户
需求陈述
内容
级别
1
□A□B□C
2
解决方法
简单描述针对需求的初步解决意向
附加说明
讨论意见
项目评审委员会结论
A需求:
紧急,重要
B需求:
重要,不紧急
C需求:
非类需求
模板2
需求/功能变更说明书
配置编号
200302-01
历史版本
V2.00
改后版本
V2.17
产品名称
()
负责人
时间
2003-8-19
变更项
变更内容
变更属性
变更原因
是否允许
1
□A□D□M
□是□否
2
3
附加说明
变更属性中A代表增加,D代表删除,M代表修改
项目评审委员会结论
项目评审委员会给出是否进行变更的意见,由评委会主席签字生效
四﹑技术可行性分析可行性分析是进行研发工作的重要环节,详细周到的可行性分析与论证为即将启动的项目把握一道至关重要的关口。
技术可行性分析要求从技术层面上分析论证项目的可行性,即能否“做得到,做得快,做得好”。
可行性分析报告由项目申请责任人总结,撰写,并提交到项目评审委员会审阅。
有项目申请/建议书,需求定义和需求报告仍然不能进行实质性的开发,必须要进行可行性分析,可行性分析包括几个部分
(1)市场分析:
a.分析总结市场的发展趋势,说明产品处于市场的什么发展阶段,粗略估计产品的生命周期
b.本产品和同类产品的价格比对
c.统计产品当前市场总额,竞争对手所占的份额,分析本产品有哪些比较优势,可能占有多少市场份额
d.为产品定位,即确定产品用户群,分析产品消费群体特征,消费方式及影像市场的因素分析
(2)政策分析
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 技术 研发 文档