行业总体架构分析.docVIP

行业总体架构分析 国土行业总体架构管理的主要内容包括IT战略规划，IT政策、原则、指导纲要与管理流程，IT资产、技术管理、供应链管理，IT技术元素和工程模型，结合调整策略针对每部分内容进行分析： 行业的IT战略规划 建立稳定、轻便、开放的基础框架（系统运行框架而非开发框架）； 建立稳定的行业核心数据模型，并不断地丰富； 建立多项目业务逻辑开发的管理模式，使遵循子类继承父类，不同处理方式采用覆盖或重载来实现； 建立支撑以行业服务产品为核心的项目实施模式和IT支撑系统； 行业内部的IT政策、原则、指导纲要与管理流程 对一个行业来说，稳定是应对各种变化的最佳处理方法；需要为行业内部提供IT技术路线稳定、数据逻辑模型稳定、开发团队稳定的政策环境； 理解行业多项目并行开发版本管理的思想和熟练掌握使用版本管理工具； 行业多项目开发中核心业务处理逻辑必须建立起连续的类继承关系； 熟练使用代码版本控制工具和类关系管理工具； 尽量采用成熟的技术和模式来进行行业应用开发； 强化核心业务模型、数据模型的分析，建立逻辑处理结构模型； 应用开发中涉及到对数据库的操作以及业务逻辑的处理，均应该建立在对物理结构映射的逻辑结构层上； 加强软件开发的单元测试与代码检查； 适当降低项目经理对技术管理的决策权，使其加强对项目的成本控制，进度管理，人员协调； 行业的IT资产、技术管理、供应链管理 综上（二）所述， 行业内部的IT资产包括： 管理项目文档和项目插件代码的配置服务目录和相关结果说明文档； 多项目数据库备份，系统调试运行环境和相关配置文档； 系统部署的网络环境，数据库部署环境和相关设计文档； 行业核心业务数据模型库，逻辑处理组件库和相关设计文档； 表现层模版库和相关设计文档； 基础架构（系统运行时）代码和相关设计文档； 同类系统的数据结构分析，以及数据规整的处理方法，既包括GIS的，也包括普通数据库的； 员工的技能档案； 行业内部的技术管理几个主要方面： IT资产的管理制度； 生产技术管理制度； 新技术的引进管理； 技术研究成果的对外发布管理； 需求分析到设计实现的管理； Bug报告、分析、修改、测试过程管理和文档管理； 单元测试、集成测试、版本发布的管理； 技术档案管理制度； 档案的分类编目管理； 档案的更新发布管理； 行业内部的供应链管理： 对现有的供应链体系进行调整，使之适合以行业服务产品为核心的项目实施模式； 各个环节可交付物的管理； 下一个环节的操作人员与前一个环节的操作针对交付物的形式达成一致； 前一环节移交的交付物必须是下一环节可用的成果； 在技术工具相对完善后，坚决反对以word文档为主要形式作为前后环节交付物。 下一环节在使用前一环节的交付物后，必须对该交付物存在的问题提出改进意见，并备案； 供应链的优化管理 交付物质量优化； 生产交付物的技术手段改善； 不断加强每个环节的专业化、精确程度； IT技术元素和工程模型 IT技术元素 系统运行网络环境 软件开发环境 软件集成（运行）环境 系统部署 系统安全 业务模型 数据模型 逻辑处理模型 规范、标准 用户界面模版 工程模型 将工程模型分为四个方面的内容 行业IT资产的管理 行业服务产品管理 项目实施工程模型 行业供应链管理 行业IT资产管理 将行业资产管理环境作为项目运行环境的真实测试环境，以达到模拟现场实际的效果。行业IT资产管理环境需要支持多项目并行调试发布。结构如下： 行业服务产品管理 行业服务产品包括： 用户机构管理模式分析及改进方案； 通过分析用户的管理模式，分析公司行业服务产品的适用程度，对行业服务产品提出改进意见同时制定行业服务产品的实施策略。 用户网络建设，安全建设方案； 可以将公司的网络管理模式整理成为基于Windows网络管理的基础解决方案，并结合行业服务产品的部署模式，对网络环境的需求，对用户现有网络进行分析，提出网络建设方案。 行业管理IT解决方案； 从最核心的业务管理开始，并通过对IT资产的不断完善，不断完善和丰富IT解决方案的内容。 行业服务产品的完善和丰富，建立在稳定的基础架构和统一的技术体系之上，总体规划，逐步丰富，通过不断的迭代来实现。行业服务产品管理流程结构图如下： 解释说明： 各项目需求反馈 无论各项目现有需求/Bug是否自己修改，也需要录入到公司的需求管理配置库里。不要散落的word文档或者邮件。 对需求反馈内容的要求： 关键词： 什么功能出现什么问题 或什么业务出现什么问题 需求管理与行业服务产品改进设计 根据各项目组成员的集中程度，定期对各项目提出的需求/Bug经过讨论后，形成一种多方都可以接受的解决方案，在统一需求的前提下，进行行业应用组件的改进设计； 兼顾项目紧急程度和行业服务产品的稳定性，定期一般以三个月一次为宜。 针对各项目