技术研发文档模版0.10

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

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

1 / 26
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功