eci 嵌入式组织结构建议.pptVIP

ECI 嵌入式软件 组织结构 建议 组织结构设计建议以： 降低员工需要掌握的技能、方便员工独立完成工作、便于模块设计为依据。 划分方法： 按层次划分(目前正在实现的) 按功能划分 分层组织结构 按代码所在的位置(层次)对进行组织结构划分 驱动组 / 微码组 VPN命令行 Agent 组 主控组 协议 VPN主控代码 L2子卡VPN协议 驱动/NP微码 VPN功能为例 项目组职责 Agent 组：完成各应用模块的命令行和MIB 主控组： 完成各应用模块在主控单板上的需求。 协议： 在子卡上完成 所有相关协议 驱动组： 负责各板卡的驱动 和 Bootloader 分层组织结构(优点) 每个员工掌握的知识比较全面，有利于人才备份，风险防范。 各层间接口参数大致相同(内容不一致)，方便统一定义。 同一层，各模块间沟通比较直接。 按单板(CPU)分组，开发环境单一。 分层组织结构(存在的问题) 由于同一功能(应用)需要不同项目组配合完成，各层之间需要制定接口文档，增加了对接口理解的不一致的可能，给产品带来了风险。 由于每一层次都需要了解所有的功能(应用) ，导致每组学习和理解的工作量加大，导致对功能理解难以精通。 各层中，由于各模块没有明确的接口文档，设计人员设计比较随意，导致模块间耦合大，可裁剪和可重用性差。 可扩展性差，当每次增加一个功能的时候，需要所有组进行配合修改。 联调的时候,一个人负责的层有问题,往往会把相关上下的人都叫过来,这样 就占用了太多的人力资源,使得联调效率降低。 测试的时候 如果每个组都进行整体测试，会进行重复劳动，浪费人力。 如果仅仅根据接口进行测试，就无法保证整体功能正确，而且需要增加大量测试代码。 不利于建立模拟环境 按功能模块的组织结构 驱动组 / 微码组 Agent 组 VPN 协议 单板 路由 协议 MPLS 协议 QoS 协议 MCU Support CLI 芯片 按功能模块 项目组职责 Agent 组：完成各应用模块的命令行和MIB(功能不变，命令行框架成熟后，可将命令注册、解析功能分给各功能模块) Support组：完成除配置工具外的基础功能，如：Alarm，Pm，板卡，LED，TMU，HA，维护等，包括主控和子卡。 XX协议： 负责 子卡 和 MCU上 XX协议 相关实现。 驱动组： 负责各板卡的驱动 和 Bootloader(功能不变) 层次接口 Agent组 协议MCU代码 配置API 协议子卡代码 RPC 驱动接口 单板驱动软件 当同一种业务需要多种硬件平台支持的时候，建议将业务驱动接口明确，然后增加“驱动组”或“产品组” ，专门提供驱动接口到硬件或NP的实现，当然，也可以有现在的平台组承担。 子卡 主控 按功能模块组织的优点 由于同一功能(应用)有同一组完成，减少了接口理解的不一致的可能。 由于每个员工仅需要掌握支撑模块功能使用 和 所负责的功能，即可完成任务，易于深入理解。 各模块间需要定义明确的接口文档，减少耦合性，可裁剪和可重用性提高。 增加新功能时，所涉及的项目组变少，速度快，稳定性好，可扩展性得到增强。 测试的时候，每个组都可以进行整体测试，不会进行重复劳动。 容易实现模拟环境。