《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代表修改工程评审委员会结论工程评审委员会给出是否进行变更的意见，由评委会主席签字生效四、技术可行性分析可行性分析是进行研发工作的重要环节，详细周到的可行性分析与论证为即将启动的工程把握一道至关重要的关口。技术可行性分析要求从技术层面上分析论证工程的可行性，即能否“做得到，做得快，做得好”。可行性分析报告由工程申请责任人归纳总结，撰写，并提交到工程评审委员会审阅。有工程申请/建议书，需求定义和需求报告仍然不能进行实质性的开发，必须要进行可行性分析，可行性分析包括几个部分（1） 市场分析：a.分析归纳总结市场的发展趋势，说明产品处于市场的什么发展阶段，粗略估计产品的生命周期
