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