配置管理目录详解
软件配置管理状态报告
文档编号：
项目名称：
本文档修订记录：
修订人
修订日期
修订内容
1
软件名称
版本号
许可证号
数量
备注
2
配置库存放目录：
用户：
密码：
配置管理目录格式要求：
一级目录
二级目录
三级目录
四级目录
软件产品名称+软件
文档
质量记录
参考资料
数据库资料
用户手册
接口文档
其它资料
qehlcx11jl022002软件配置管理状态报告一级目录二级目录三级目录四级目录软件产品名称版本号安装部署xx子系统系统数据库应用软件文档质量记录参考资料数据库资料用户手册接口文档其它资料代码工程名称子工程名称设计工程单元测试代码安装工程子系统名称测试脚本其他21文档软件配置管理状态报告北京易华录信息技术股份有限公司文件编号
备份人
代码
工程名称
子工程名称
设计工程
单元测试代码
安装工程
子系统名称
测试脚本
其他
2.1
配置项
说明
版本号
基线版本号（如有）
修改人
修改日期
2.2
配置项
说明
版本号
基线版本号（如有）
修改人
修改日期
工程１
文件１
。。。
工程2
文件１
2.2
配置项
说明
版本号
基线版本号（如有）
修改人
修改日期
3
序号
备份名
备份内容
备份的
目的
备份日期
配置管理过程及工具的使用
配置管理过程
岗位及职责 项目建立 配置管理计划 出入库 变更流程 配置状态报告 SCM总结报告 验证
岗位与职责
SCCB（Software Configuration Control Board） SCCB负责人：一般由室主任、项目所有者(Project Owner)或项目负责人担当，主要职责是审批《配置 管理计划》、审批重大的变更； SCCB成员：一般由室主任、项目负责人、SQA人员 共同组成，主要职责是讨论、审批配置项或基线的 变更； SQA：主要职责为审核配置管理活动； 配置管理员：主要职责为制定《配置管理计划》、 创建和维护配置库、定期做《配置状态报告》。
包括中间发布和最后的发布配臵库结构说明3配臵管理放臵项目配臵项清单配臵管理光盘清单配臵状态报告等scm读写其他人只读质量保证放臵项目不符合报告sqa核查表和sqa周报等sqa读写其他人只项目跟踪和监控放臵项目状态报告项目周报个人工作周报等评审和报告基线工作产品入基线时评审的报告项目组长读写其他人只读配臵库使用说明1因为cvs工具本身的问题如果你将文件放在错误的位臵或者命名不规范scm进行位臵移动或者修改文件名称的时候会造成历史版本的丢失想要找回历史版本很不容易给配臵管理造成一定的工作量
配置审核
配置审核包括两方面的内容：配置管理活动审核及基线审核。配 置管理活动审核确保项目组成员所有配置管理活动遵循批准的软 件配置管理方针和规程，比如检入（Check in）/检出（Check Out）的频度，工作产品成熟度提升原则等。实施基线审核，保证 基线化软件工作产品的完整性和一致性，并且满足其功能要求。
the log message”， 请大家一定要填写，主要填写几个方面的内容：修改 的目的，修改的主要内容（段落或者函数名称），修 改可能造成的影响。 尤其是进入编码和测试阶段，要求每个文件的提交必 须有log message。请大家注意！
《大型医用设备配置许可管理目录(2018年)》政策解读
4.首次配置的整台（套）单价在3000万元人民币以上的大型医疗器械。
在《目录》制订过程中，主要遵循以下原则：坚持“放管服” ，充分考虑医改推进、医学技术进步、疾病诊治需求，以及设 备技术风险、资金投入、运行成本和使用费用等因素，按照问 题导向、最小必需、动态调整和权责一致的原则，紧紧围绕保 障医疗质量安全、促进资源共享、控制医疗费用的目的，以临 床应用风险高、购置费用和检查治疗服务价格高的设备为重点 ，与管理目的关系不紧密、对管理结果无直接影响的设备一律 不纳入目录。根据经济社会发展、健康需求变化以及在用设备 综合评估情况，适时动态调整，促进应用，降低医疗成本。同 时，合理划分中央和地方职权和责任边界，最大程度减少中央 部门审批事项。
2.正电子发射型磁共振成像系统（英文简称PET/MR）。是由正电子发射显像仪 （PET）与磁共振成像仪（MR）融合而成的大型功能代谢与分子影像诊断设备 ，用于肿瘤诊断、分期和再分期、疗效评估，预后评估以及神经和心脏疾病诊断 。应用技术复杂，还处于初级发展阶段，关键技术问题有待进一步完善，临床特 有优势还需积累大量临床病例进行验证，尚不具备大范围推广应用的条件。
按照国务院令第680号规定，国家卫生健康委员会对大型医用设备配置使用 管理工作进行了认真总结，委托第三方研究机构对“十二五”大型医用设 备管理目录进行了逐一评估，广泛征求了有关部门、行业协会学会、专家 、医疗机构和相关国内外企业的意见。在此基础上，形成了《目录》，会 同有关部门报国务院批准同意。制来自的基本原则配套政策措施
配置管理方案
元征科技配置管理方案(草稿)深圳元征科技有限公司版权所有Copyright ownership belongs to GUIYI, shall not be reproduced , copied, or used in other ways without permission. Otherwise GUIYI will have the right to pursue legal responsibilities.目录1.前言 (3)1.1.目的 (3)1.2.背景 (3)1.2.1.配置管理现状 (3)1.2.2.源码管理现状 (3)1.2.3.产品现状 (5)2.产品运行的几个环境 (5)2.1.开发环境 (5)2.2.测试环境 (6)2.3.预发布环境(待建) (7)2.4.生产环境(由运维部管理) (7)3.源码版本管理 (7)3.1.研发新库 (7)3.2. 研发旧库 (11)3.3. 库迁移 (11)3.4.源码库管理 (11)4.构建与发布（待补充） (12)4.1.构建 (12)4.2.产品发布 (15)4.2.1.客户端（app）发布 (15)4.3.实施部署 (16)4.4.紧急补丁发布 (17)4.5.升级包发布 .................................................................................... 错误！未定义书签。
5.发布版本注释（release note） (17)6.变更管理（待补充） (18)7.资源管理 (18)7.1.提供统一的工作环境标准 (18)7.2.文件共享(由信息部规划实现) (18)7.3.知识库 (18)8.服务器规划 (19)9.服务器安全管理(待完善) (23)9.1.备份管理 (23)9.2.业务连续性方案（待补充） (23)1.前言1.1.目的本文档针对目前公司的产品/项目规划、研发、发布、系统实施等提出整体的配置管理解决方案。
配置库目录结构
配置库目录结构
1.软件开发项目配置库
<项目名称>
├─01 开发工程库
│├─01 需求
│├─02 设计
││├─01 界面原型
││├─02 数据库设计
│├─03 编码
││├─01 源程序
││└─02 SQL日志
│├─04 测试
│├─05 交付
│└─06 评审区
├─02 项目管理库
│├─01 项目管理
││├─01 立项管理
││├─02 项目计划及监控（包括对风险的管理计划和监控）
││├─03 项目开发会议记录
││├─04项目报告
││└─05 经验与教训
│├─02 质量保证管理
││├─01 质量保证计划及记录
││└─02 质量保证报告
│├─03 配置管理
││├─01 配置管理计划及记录
││├─02 配置管理报告
││├─03 基线发布报告
││└─04 变更管理
│├─04 度量管理
││├─01 度量计划
││├─02 度量数据记录表
││└─03 度量报告
│└─05 同行评审
│├─01 评审通知及评审会议记录
│└─02 代码走读记录
├─03 受控库
│├─01 项目开发文档
│└─02 项目开发代码（根据项目特点可选择以打标签方式或者物理存储的方式）├─04 参考资料
└─05 基线库（根据项目特点可选择以打标签方式或者物理存储的方式）
2.组织过程资产库
目前已按这个进行管理了
欢迎您的下载，
资料仅供参考！
致力为企业和个人提供合同协议，策划案计划书，学习资料等等
打造全网一站式需求。
《配置管理培训》课件
分析也是选择工具时需要考虑的重要因素。
工具的使用
总结词
正确使用配置管理工具可以提高开发效率、减少错误并保证代码质量。
05
配置管理的最佳实践
制定合理的配置管理计划
总结词
制定计划是配置管理的第一步， 有助于明确目标和任务，确保资 源的合理分配。
详细描述
在制定配置管理计划时，应充分 考虑项目的规模、复杂度、资源 等因素，明确配置管理的目标、 范围、方法、时间表和预算。
加强团队间的沟通与协作
总结词
良好的沟通与协作是配置管理成功的 关键，有助于减少冲突和误解，提高 工作效率。
配置项的变更控制
总ቤተ መጻሕፍቲ ባይዱ词
对配置项的变更进行控制和管理，确保 变更的合理性和规范性。
VS
详细描述
在项目实施过程中，由于各种原因可能导 致配置项的变更。为了确保项目的顺利进 行和配置项的一致性，需要对变更进行严 格的控制和管理。需要制定变更申请和审 批流程，对变更进行评估和审核，确保变 更的合理性和规范性。
配置项可以是代码、文档、数 据、工具、环境等，它们在开
发过程中不断变化和演进。
配置项的管理包括标识、控制 、状态记录和审计等方面，以 确保配置项的完整性和准确性 。
配置项的管理有助于提高开发 效率和质量，减少错误和混乱 。
配置管理库
01
配置管理库是用于存储和管理配 置项的物理存储介质。
02
配置管理库通常包括硬件和软件 ，例如服务器、存储设备、数据
软件项目管理目录
第一章．软件项目开发管理概述●管理是重要的P7-10●什么是软件项目管理P12●软件项目管理的主要内容P151.过程管理（过程定义和剪裁、软件项目计划、软件度量、软件项目的跟踪和监督、风险管理）P16-212.人员管理（软件项目团队、纪律和激励机制）P22-243.产品管理（软件需求管理、软件质量保证、软件配置管理）P25-28●软件项目管理的规范和标准（CMM、ISO9001）P301.CMMP31-65第二章．软件开发过程的定义、剪裁和改进●什么是软件开发过程1.什么是过程P122.什么是软件项目开发过程P13-143.软件开发活动P15-184.软件开发活动间的关系P19●为什么需要过程P21●软件开发过程模型P231.瀑布模型P242.原型模型P253.增量模型P264.迭代模型P275.螺旋模型P28●如何定义过程1.定义软件开发过程的要求P302.定义软件开发过程的步骤P31-68步骤1：确定软件开发过程模型步骤2：确定和描述活动步骤3：确定和描述活动间的关系步骤4：文档化软件开发过程步骤5：文档化如何剪裁过程步骤6：文档化如何改善过程步骤7：过程评审、认可和发布步骤8：员工培训3.软件开发过程定义注意事项P69-734.软件开发过程定义文档P74●如何剪裁过程P76第三章．软件度量和估算●什么是软件度量1.基本概念P10-13●为什么需要软件度量P15-16●软件度量的内容P18-20●软件度量的方法--估算1.面向规模的度量P23-252.面向功能的度量P26-323.成本和工作量估算P33-341)代码行、功能和工作量估算P352)经验估算模型P44-504.软件质量度量P51-521)质量要素P53-542)质量要素的评价准则P55-563)软件质量的度量P57●在软件开发过程中进行软件度量1.软件开发过程中集成度量P59-60第四章．软件项目计划●什么是软件项目计划1.什么是软件项目计划P162.软件项目计划的内容P17-193.制定软件项目计划的基础和依据P204.制定软件项目计划的时机P215.初步和详细的软件项目计划P22-24●为什么需要软件项目计划●制定软件项目计划应考虑的因素1.制定软件项目计划的方法P282.软件项目计划制定的方式P29-313.软件开发活动关系的类型P32-354.估算活动的周期P36-395.确定里程碑P40-426.活动责任矩阵P43-467.描述项目进度计划（甘特图和网络图）P48-528.关键路径P53-559.参与、承诺和分发P56●制定软件项目计划的步骤P58-78指定项目进度协调者确定要使用的工具准备项目进度计划会议召开项目进度计划会议提交和分析数据使用工具创建进度计划评审项目进度计划使用工具更改项目进度计划批准项目进度计划分发项目进度计划●CMM对软件项目计划的要求P80-811.目标P822.制定方针政策P83-853.确保必备条件P86-904.实施过程活动P91-1095.度量和分析P1106.验证实施P111-113●成功的和过于乐观的软件开发计划1.成功的软件开发计划P1162.过于乐观的软件开发计划P1173.为什么会产生过于乐观的软件开发计划P118第五章．软件项目跟踪●什么是软件项目跟踪P101.软件项目跟踪的对象P112.软件项目风险P12-153.项目进展P16-184.开发活动进展P19-205.开发活动问题P21-226.项目展望P237.软件项目跟踪的基础P248.软件项目跟踪的方式P259.软件项目跟踪的目标P2610.软件项目跟踪示意图P27●为什么需要对软件项目进行跟踪P29●软件项目跟踪会议1.何时召开会议P322.谁来参加会议P333.跟踪会议的组织和召开P344.修复计划P355.问题升级P36●软件项目跟踪的过程和步骤P38-47指派PTT (Project T race T eam)负责人选定要用的工具和表格实施PTT培训准备PTT会议召开PTT会议开展工作/问题升级会议分发PTT会议记录转到第5步直到项目结束●CMM对软件项目跟踪的要求P49-511.目标P522.制定方针政策P53-543.确保必备条件P55-594.实施软件过程P60-735.度量和分析P746.验证实施P75-77第六章．软件开发的风险管理●什么是软件风险P14●如何进行风险管理1.什么是软件风险管理P172.风险管理的策略P18-193.风险管理的组成P20-22●风险评估1.风险识别（风险的类别：计划编制、组织和管理、开发环境、最终用户、客户、承包商、需求、产品外部环境、人员、设计和实现、过程）P25-412.风险分析P42-48评估风险发生的概率估算风险造成损失的大小计算风险危险度(Risk Explosure)风险优先级●风险控制1.风险管理计划P51-522.风险化解P53-543.风险监控P55-56第七章．软件需求管理●什么是软件需求1.什么是软件需求P10-132.获取软件需求的重要性P143.获取软件需求的复杂性P15-164.解决的方法和手段P17●如何进行软件需求分析1.什么是软件需求分析P202.软件需求分析的任务P213.软件需求分析的目标P224.软件需求分析的过程和步骤P23-31（收集软件需求、软件需求建模、文档化软件需求、评审软件需求）●软件需求管理为什么需要对软件需求进行管理P34需求管理的内容P35收集软件需求（如何收集软件需求、文档化所收集的软件需求、软件需求收集的注意事项）P36-42软件需求建模（为什么需要对软件需求进行建模、如何对软件需求进行建模）P43-46 撰写SRS（软件需求规格说明书）P47-48评审软件需求（为什么需要对软件需求进行评审、如何进行评审、软件需求评审结果）P49-54控制软件需求的变更（控制SRS、控制软件需求的变更）P55-59●CMM对需求管理的要求P61-631.目标P642.制定方针政策P653.确定必备条件P66-694.实施软件过程P70-725.度量和分析P736.验证实施P74-76第八章．软件质量保证●软件质量1.什么是软件质量P12-142.为什么需要关注软件质量P15●软件质量保证1.什么是软件质量保证P18-192.从哪些方面关注软件质量P20-223.谁来执行和实施软件质量保证P234.如何保证软件质量（正确理解用户的要求、制定标准和规程、审查软件开发活动、审核软件工作产品、测试源程序代码、记录开发活动和软件产品的偏差、记录所有不符合项并报告高级管理者）P24-31●软件质量保证计划及其实施P33-34●CMM对软件质量保证的要求P36-381.目标P392.制定方针政策P403.确保必备条件P41-444.实施软件过程P45-525.度量和分析P536.验证实施P54-56第九章．软件配置管理●什么是软件配置管理P91.软件配置项P10-132.基线P14-173.软件配置管理P18-22●如何进行软件配置管理1.SCI标识P25-322.版本控制P33-343.变更控制P35-374.软件配置审计P38-395.状态报告P40-436.谁来实施软件配置管理P44●软件配置管理计划P46-48●CMM对软件配置管理的要求P50-521.目标P532.制定方针政策P543.确保必备条件P55-594.执行活动P60-695.度量和分析P706.验证实施P71-74●软件配置管理工具P76第十章．软件开发团队的管理●什么是团队P3●团队管理的内容P5-6●团队的组织结构1.组件团队结构应考虑的因素（明确团队的目标、明确团队的种类、高效团队的特征）P8-122.团队的模式（业务团队、首席程序员团队、臭鼬项目团队、特征团队、搜索救援团队、战术（SW AT）团队、大型团队）P13-20●成功团队VS失败团队1.成功团队的特点P222.典型错误P23-253.技术人员需要增强沟通技能P264.沟通和协调的方法和工具P275.有效的非正式口头沟通P286.如何管理高业绩团队P297.团队为什么会失败P308.长期的团队建设P319.人是进行项目管理中最大的变数P3210.看曹操是怎么用人的P3311.团队领导的实践指南P34-36●团队激励机制（激励机制、开发人员的激励因素、项目经理的激励因素、成就感、发展机遇、工作乐趣、个人生活、成为技术主管的机会、奖励和认可、正确评价业绩、典型错误—士气杀手）P38-49●做一个好的项目经理P511.项目经理的技能P522.有效的&低效的项目经理P533.项目经理的职责P544.激励组员P555.关心下属的成长P566.永远支持组员P577.“信者，至诚，至实，至一，至公也”P588.项目经理的影响力和权力P599.正确使用权力P6010.提高办事效率P6111.持续改进P6212.学习过去P6313.利用沟通解决冲突P6414.项目经理要则P65。
Linux文件权限与目录管理详解
Linux⽂件权限与⽬录管理详解⼀、Linux⽂件系统的三种⾝份1）、⽂件所有者2）、同组⽤户同⼀个⽤户组的⽤户可以访问该⽤户组的⽂件；每个账号可以加⼊多个⽤户组。
在同⼀个⽤户组的⽂件也可以设置不同的权限，可以不让本组⽤户查看。
3）、其他⼈除了⽂件主、同组⽤户以外的⼈就是其他⼈。
PS： /etc/passwd 记录所有⽤户的账号/etc/shadow 记录所有⽤户的密码/etc/group 记录所有的组名⼆、⽂件属性ls -al 显⽰所有的⽂件名和相关属性（包括以.开头的隐藏⽂件）total 72drwxr-xr-x+ 28 chaibozhou staff 952 4 23 08:08 .drwxr-xr-x 5 root admin 170 4 13 21:24 ..-r-------- 1 chaibozhou staff 9 3 21 12:00 .CFUserTextEncoding-rw-r--r--@ 1 chaibozhou staff 10244 4 23 11:25 .DS_Storedrwx------ 5 chaibozhou staff 170 4 23 14:13 .Trash-rw------- 1 chaibozhou staff 3205 4 23 16:37 .bash_historydrwxr-xr-x 6 chaibozhou staff 204 4 4 15:51 .config第⼀列：⽂件的类型和权限d：⽬录⽂件-：普通⽂件l：链接⽂件b：⽤于存储数据的设备⽂件c：⽤于传输数据的设备⽂件：⿏标、键盘接下来都是三个字符为⼀组，分别表⽰⽂件所有者的权限、同组⽤户的权限、其他⽤户的权限，⽽且r、w、x的顺序是固定不变的。
第⼆列：有多少⽂件名连接到此节点第三列：这个⽂件/⽬录的所有者账号第四列：这个⽂件所属的⽤户组第五列：这个⽂件的⼤⼩，单位是B第六列：这个⽂件的创建⽇期或修改⽇期若想要现实完整的⽇期时间，可以在ls上加上参数：ls -l –full-timePS:在Linux的命令中，如果参数以－开头，则表⽰后⾯的参数是简写；如果以－－开头，则表⽰后⾯的参数是完整的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SVN配置管理详细说明
目录
1.网站目录地址 (2)
2.目录说明 (2)
2.1目录详细说明 (2)
2.2目录配置流程说明 (3)
2.3目录下对应版本类型 (4)
3.人员目录 (4)
3.1项目人员对应目录 (4)
3.2项目人员对应目录操作步骤 (4)
4.版本命名 (6)
4.1产品版本命名规范 (6)
4.2项目过程中版本命名规范 (6)
5.版本发布流程 (8)
1.网站目录地址
网站名称为内部暂定为卡老师，对应的配置管理目录为：https:///svn/kalaoshi
2.目录说明
2.1目录详细说明
目录路径：
Kalaoshi
|
+--develop
+ |
+ +----trunk
+ + |
+ + +----开发
+ + + |
+ + + +-----人员1
+ + + +-----人员2
+ + +----设计
+ + + |
+ + + +-----人员1
+ + + +-----人员2
+ + +----整合代码
+ +----branches
+ + |
+ + +----代码
+ + +----设计
+ +----tags (只读)
+ + |
+ + +----代码
+ + +----设计
+----control
+ |
+ +----代码
+ +----设计
+----Product (只读)
+ |
+ +----产品1
+ +----产品1
+----项目文档
+ |
+ +----trunk
+ + |
+ + +----人员1
+ + +----人员2
+ + +----人员3
+ +----branches (只读)
+ + |
+ + +----开发
+ + +----设计
+ + +----产品
+ + + |
+ + + +----需求说明文档
+ + + +----产品原型
+ + +----测试
+--其他(只读)
+ |
+ +----SVN配置管理
+ +----测试文档
+ +----文档模版
+ +----开发注意事项
2.2目录配置流程说明
目录存放内容说明：
Trunk：每个人都有自己的trunk路径，类似自己的本地，只有自己去操作，别人不能对你的路径操作。
branches：这个目录有两个分别是在develop下和项目文档下，都是存放交付给测试或者检验端口的内容（代码，设计，文档）。
tags：这个目录有2个，在develop下的此目录存放代码和设计稿件，是由配
置管理员，取需要交付测试和检验的的文档存放于此。
另一个是在项目文档下，
此处放的是文档，是基线了的文档。
其他：存放的是不是项目阶段中的文档是规范，培训等公用性的文档。
配置管理流程：
开发和设计需要将Trunk下自己的需要交付给测试检验端口的内容，复制到branches下，再有配置管理员，将此处的内容取至tags中，并
存放到control下，测试检验人员针对control下的内容进行测试检验。
项目人员需要将自己Trunk下自己的需要交付给评审检验的文档，复制到branches下，评审检验人员在此目录下进行评审检验操作，文档
评审完毕后，由配置管理员放到tags 基线。
项目每完成一个版本，需要有配置管理人员，将此版本所有内容存放到Product下，以便后期其他项目参考。
配置管理人员需要定期（一般为1个月）清理项目过程中前一个月的内容。
2.3目录下对应版本类型
目录branches，版本类型：rip
目录tags,版本类型：alpha
目录control, 版本类型：Beta
目录Product, 版本类型：Release
3.人员目录
3.1项目人员对应目录
开发：
●kalaoshi\项目文档\trunk\
●kalaoshi\项目文档\branches
●kalaoshi\develop\trunk
●kalaoshi\develop\branches
设计：
●kalaoshi\项目文档\trunk\
●kalaoshi\项目文档\branches
●kalaoshi\develop\trunk
●kalaoshi\develop\branches
项目人员：
●kalaoshi\项目文档\trunk\
●kalaoshi\项目文档\branches
3.2项目人员对应目录操作步骤
将内容交付给测试检验操作：
对应SVN分支功能，分支操作只能针对一个文件或文档，不能同时支持多个
点击【确定】，后自动完成将文件或者目录A拷贝到目录或文件B
4.版本命名
4.1产品版本命名规范
起始版本V1.0.0
1.当版本发生重大变化主版本号增1，次版本号和修订号归零。
则为：V
2.0.0
2.当版本发生相对较小的变化主版本号维持不变，次本版号增1. 则为：V1.1.0
3.当一个版本发布后出现了bug需要修订。
修订版本号增1. 则为：V1.0.1
4.2项目过程中版本命名规范
1.版本号.此版本号.rip.年月日.修订数(统指本地的修订数）
2.当开发有新功能需要测试的时候，主版本号维持不变，A增 1. 则为：
V1.0.0.A.B.rip.年月日.修订数
3.当功能模块出现了bug需要修订。
B增1. 则为：V1.0.0.A.B.rip.年月日.修订数
修订数获取操作：
版本列就是我们需要找的修订数
5.版本发布流程
1.每个版本结束后，需要纸质文档发布，需标注发布内容。
2.版本发布需要准备纸质文档并需涉及开发，测试验收核实，领导审核。