scm(Supply_Chain_Management)供应链管理

scm Supply Chain Management 供应链管理 供应链管理 SCM Supply Chain Management 就是对企业供应链的管理 是对供应 需求 原材料采购 市场 生产 库存 定单 分销发货等的管理 包括了从生产到发货 从供应商的供应商到顾客的顾客的每一个环节 供应链管理 SCM 应用是在企业资源规划 ERP 的基础上发展起来的 它把公司的制造过程 库存系统和 供应商产生的数据合并在一起 从一个统一的视角展示产品建造过程的各种影响因素 供应链是企业赖以 生存的商业循环系统 是企业电子商务管理中最重要的课题 统计数据表明 企业供应链可以耗费企业高 达 25 的运营成本 它主要是一种整合整个供应链信息及规划决策 并且自动化和最佳化信息基础架构的软件 目标在于达到 整个供应链的最佳化 在现有资源下达到最高客户价值的满足 为一种新的决策智能型软件 覆盖在所 有供应链公司的 ERP 和交易处理系统之上 SCM 通常具有一个转换接口 用以整合供应链上各公司的应用系统 尤其是 ERP 系统 及各种资料型态 此转换会通过标准中介工具或技术 如 DCOM COBRA ODBC 等等 提供与主要决策系统互动的能力 SCM 能为企业带来如下的益处 增加预测的准确性 减少库存 提高发货供货能力 减少工作流程周期 提高生产率 降低供应链成本 减少总体采购成本 缩短生产周期 加快市场响应速度 随着互联网的飞速发展 越来越多的企业开始利用网络实现 SCM 即利用互联网将企业的上下游企业进行整合 以中心制造厂商为核心 将产业上游原材料和零配件供应商 产业下游经销商 物流运输商及产品服务商以及往来银行结合为一体 构成一个面向最终顾客的完整电子 商务供应链 目的是为了采购成本和物流成本 提高企业对市场和最终顾客需求的响应速度 从而提高企 业产品的市场竞争力 供应链管理是当前国际企业管理的重要内容 也是我国企业管理的发展方向 基于企业内部范围的管理 它将企业内部经营所有的业务单元如订单 采购 库存 计划 生产 质量 运输 市场 销售 服务等 以及相应的财务活动 人事管理均纳入一条供应链内进行统筹管理 当时企业重视的是物流和企业内部资 源的管理 即如何更快更好地生产出产品并把其推向市场 这是一种 推式 的供应链管理 管理的出发点 是从原材料推到产成品 市场 一直推至客户端 随着市场竞争的加剧 生产出的产品必须要转化成利 润 企业才能得以生存和发展 为了赢得客户 赢得市场 企业管理进入了以客户及客户满意度为中心的 管理 因而企业的供应链运营规则随即由推式转变为以客户需求为原动力的 拉式 供应链管理 这种供应 链管理将企业各个业务环节的信息化孤岛连接在一起 使得各种业务和信息能够实现集成和共享 SCM 软件配置管理 软件配置管理 1 什么是软件配置管理 SCM 软件配置管理是指通过执行版本控制 变更控制的规程 以及使用合适的配置管理软件 来保证所有 配置项的完整性和可跟踪性 配置管理是对工作成果的一种有效保护 Software configuration management SCM or just plain CM is an organizational framework that is a discipline for managing the evolution of computer systems throughout all stages of systems development 2 为什么需要配置管理 如果没有软件配置管理 最大的麻烦是工作成果无法回溯 随着工作的进展新的程序覆盖了老的程序 当突然发现新程序有问题而老程序正确时怎么办 那只能重写老的程序来覆盖新的程序 过一段时间又发 现原来的老程序有问题 而解决方法在原来的新程序中 您是不是快要发疯了 为了避免成果被覆盖 包括我自己在内的很多人早期采用手工管理版本的方式 例如当一个新版本产生时 用当时的日期来命名文件夹 然后再复制一下以后的修改在复制的文件夹内进行 这样上一个版本就被保 存下来了 周而复始不同的版本不会被覆盖 虽然这种方式可以从某种程度上解决版本的回溯问题 但他 存在的缺点是显而易见的 第一点如果保留结果过于频繁 将会导致产生大量的有着重复内容的文件夹 庞大的物理空间 管理起来很麻烦 如果保留旧版本的时间间隔太长 可能产生某些有用的老程序无法回 溯 拿我最近开发的一个程序来说程序只有几十兆 经过一年的开发各版本累计到 1G 第二容易产生版 本的混乱 如果是团队开发软件 这种简单的方法更难解决问题的本质了 3 人的问题 配置管理的方法是成熟的 而且相应的软件工具也是成熟的 基本上不存在看不懂 不会用的问题 配置管理的执行效果如何 完全是事在人为 妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪 在没出乱子的情况下 执行版本控制看起来有些麻烦 每次修改工作的时候总是要 Get Latest Version 接着 Check Out 修改完后又要 Check In 多做了三步 其实这三步加起来也就十几秒钟 而且不费脑 子 根本没有添加多少麻烦 仅仅是个人感觉不爽而以 然而不执行版本控制的话 万一发生工作成果被 覆盖或丢失等问题 麻烦就大了 4 软件配置管理规范 软件研发和管理过程中会产生许许多多的工作成果 例如文档 程序和数据等 他们都应当妥善地保 管起来 以便查阅和修改 如果把所有文件一股脑的塞进计算机里 那么使用起来很麻烦 凡是纳入配置管理范畴的工作成果统称为配置项配置项主要有两大类 一类是属于产品的组成部分 例如 需求文档 设计文档 源代码 测试用例等等 另一类是在管理过程中产生的文档 例如各种计划 报告 等 每个配置项的主要属性有名称 标识符 文件状态 版本 作者 日期等 配置项及历史纪录反映了软件 的演化过程 基线由一组配置项组成 这些配置项构成了一个相对稳定的逻辑实体 基线中的配置项被冻结后 不能在 被任何人随意更改 基线通常对应于开发过程中的里程碑 通常将交付该客户的基线称为一个 Release 为内部开发用的基线称为一个 Build 版本控制的目的是按照一定的规则保存配置项的所有版本 避免发生版本丢失或混乱等现象 配置项的状 态有三种 草稿 正式发布 和 正在修改 配置项的版本号与配置项的状态紧密相关 1 处于 草稿 状态的配置项的版本号格式为 0 YZ 2 处于 正式发布 状态的配置项的版本号格式为 X Y 一般只是 Y 值递增 当 Y 值到达一定的范围时 X 值才发生变化 3 处于 正在修改 状态的配置项的版本号格式为 X YZ 一般只增大 Z 值 当配置项修改完毕 状态重新变成 正式发布 时 将 Z 值变为 0 增加 X Y 值 5 常用的配置管理软件 自从 20 世纪 80 年代后期研制并完善了 增量存储算法 后配置管理工具的春天便开始了 目前国内常 用的配置管理工具大概有 SourceSafe CVS 和 ClearCase SCM Software Configuration Management 软件配置管理 软件配置管理 是一种标识 组织和控制修改的技术 软件配置管理应用于整个软件工程过程 我们知道 在软件建立时变更是不可避免的 而变更加剧了项目 中软件开发者之间的混乱 SCM 活动的目标就是为了标识变更 控制变更 确保变更正确实现并向其他 有关人员报告变更 从某种角度讲 SCM 是一种标识 组织和控制修改的技术 目的是使错误降为最小 并最有效地提高生产效率 软件配置管理 Software Configuration Management SCM 作为 CMM 2 级的一个关键域 Key Practice Area KPA 在整个软件的开发活动中占有很重要的位置 正如 Pressman 所说的 软件配置 管理是贯穿于整个软件过程中的保护性活动 它被设计来 1 标识变化 2 控制变化 3 保证变化 被适当的发现 以及 4 向其他可能有兴趣的人员报告变化 所以 我们必须为软件配置管理活动设计 一个能够融合于现有的软件开发流程的管理过程 甚至直接以这个软件配置管理过程为框架 来再造组织 的软件开发流程 一 迅速发展的软件配置管理 配置管理的概念源于美国空军 为了规范设备的设计与制造 美国空军 1962 年制定并发布了第一个 配置管理的标准 AFSCM375 1 CM During the Development Acquisition Phases 而软件配置管理概念的提出则在 20 世纪 60 年代末 70 年代初 当时加利福利亚大学圣巴巴拉分校的 Leon Presser 教授在承担美国海军的航空发动机研制合同期间 撰写了一篇名为 Change and Configuration Control 的论文 提出控制变更和配置的概念 这篇论文同时也是他在管理该项目 这个过 程进行过近一千四百万次修改 的一个经验总结 Leon Presser 在 1975 年成立了一家名为 SoftTool 的公司 开发了配置管理工具 Change and Configuration Control CCC 这是最早的配置管理工具之一 随着软件工程的发展 软件配置管理越来越成熟 从最初的仅仅实现版本控制 发展到现在的提供工 作空间管理 并行开发支持 过程管理 权限控制 变更管理等一系列全面的管理能力 已经形成了一个 完整的理论体系 同时在软件配置管理的工具方面 也出现了大批的产品 如 最著名的 ClearCase 开 源产品 CVS 入门级工具 Microsoft VSS 新秀 Hansky Firefly 在国外已经有 30 多年历史的软件配置管理 但在国内的发展却是在 21 世纪这几年的事 但是通过 专家们的介绍 我们感受到 国内的软件配置管理已经取得了迅速发展 并得到了软件公司的普遍认可 二 软件配置管理的基本目标 软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性 它的基本目标包括 目标 1 软件配置管理的各项工作是有计划进行的 目标 2 被选择的项目产品得到识别 控制并且可以被相关人员获取 目标 3 已识别出的项目产品的更改得到控制 目标 4 使相关组别和个人及时了解软件基准的状态和内容 三 XSSC 有关软件配置管理的方针 为了达到上述目标 如下的方针应该得到贯彻执行 技术部门经理和具体项目主管应该使用和遵循 XSSC 的 OSSP 中所描述的软件配置管理的工作过程 施行软件配置管理的职责应被明确分配 相关人员得到软件配置管理方面的培训 技术部门经理和具体项目主管应该明确他们在相关项目中所担负的软件配置管理方面的责任 软件配置管理工作应该享有足够的资金支持 这需要在客户 技术部门经理和具体项目主管之间协商 软件配置管理应该实施于如下产品 对外交付的软件产品 以及那些被选定的在项目中使用的支持类 工具等 软件配置的整体性在整个项目生命周期中得到控制 软件质量保证人员应该定期审核各类软件基准以及软件配置管理工作 使软件基准的状态和内容能够及时通知给相关组别和个人 四 常用的软件配置管理工具 现在常用的软件配置管理工具主要分为三个级别 Rational ClearCase CA CCC Havest Merant PVCS Microsoft VSS CVS 五 软件配置管理角色职责 对于任何一个管理流程来说 保证该流程正常运转的前提条件就是要有明确的角色 职责和权限的定 义 特别是在引入了软件配置管理的工具之后 比较理想的状态就是 组织内的所有人员按照不同的角色 的要求 根据系统赋予的权限来执行相应的动作 因此 在本文所介绍的这个软件配置管理过程中主要涉 及下列的角色和分工 项目经理 Project Manager PM 项目经理是整个软件研发活动的负责人 他根据软件配置控制委员会的建议批准配置管理的各项活动 并控制它们的进程 其具体职责为以下几项 制定和修改项目的组织结构和配置管理策略 批准 发布配置管理计划 决定项目起始基线和开发里程碑 接受并审阅配置控制委员会的报告 配置控制委员会 Configuration Control Board CCB 负责指导和控制配置管理的各项具体活动的进行 为项目经理的决策提供建议 其具体职责为以下几 项 定制开发子系统 定制访问控制 制定常用策略 建立 更改基线的设置 审核变更申请 根据配置管理员的报告决定相应的对策 配置管理员 Configuration Management Officer CMO 根据配置管理计划执行各项管理任务 定期向 CCB 提交报告 告 并列席 CCB 的例会 其具体职责 为以下几项 软件配置管理工具的日常管理与维护 提交配置管理计划 各配置项的管理与维护 执行版本控制和变更控制方案 完成配置审计并提交报告 对开发人员进行相关的培训 识别软件开发过程中存在的问题并拟就解决方案 系统集成员 System Integration Officer SIO 系统集成员负责生成和管理项目的内部和外部发布版本 其具体职责为以下几项 集成修改 构建系统 完成对版本的日常维护 建立外部发布版本 开发人员 Developer DEV 开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定 按照软件配置管理工具的使用 模型来完成开发任务 六 软件配置管理过程描述 一个软件研发项目一般可以划分为三个阶段 计划阶段 开发阶段和维护阶段 然而从软件配置管理 的角度来看 后两个阶段所涉及的活动是一致 所以就把它们合二为一 成为 项目开发和维护 阶段 项目计划阶段 一个项目设立之初 PM 首先需要制定整个项目的计划 它是项目研发工作的基础 在有了总体研发计 划之后 软件配置管理的活动就可以展开了 因为如果不在项目开始之初制定软件配置管理计划 那么软 件配置管理的许多关键活动就无法及时有效的进行 而它的直接后果就是造成了项目开发状况的混乱并注 定软件配置管理活动成为一种 救火 的行为 所以及时制定一份软件配置管理计划在一定程度上是项目成 功的重要保证 在软件配置管理计划的制定过程中 它的主要流程应该是这样的 CCB 根据项目的开发计划确定各个里程碑和开发策略 CMO 根据 CCB 的规划 制定详细的配置管理计划 交 CCB 审核 CCB 通过配置管理计划后交项目经理批准 发布实施 项目开发维护阶段 这一阶段时项目研发的主要阶段 在这一阶段中 软件配置管理活动主要分为三个层面 1 主要 由 CMO 完成的管理和维护工作 2 由 SIO 和 DEV 具体执行软件配置管理策略 3 变更流程 这 三个层面是彼此之间既独立又互相联系的有机的整体 在这个软件配置管理过程中 它的核心流程应该是这样的 1 CCB 设定研发活动的初始基线 2 CMO 根据软件配置管理规划设立配置库和工作空间 为执行软件配置管理就阿做好准备 3 开 发人员按照统一的软件配置管理策略 根据获得的授权的资源进行项目的研发工作 4 SIO 按照项目 的进度集成组内开发人员的工作成果 并构建系统 推进版本的演进 5 CCB 根据项目的进展情况 审核各种变更请求 并适时的划定新的基线 保证开发和维护工作有序的进行 这个流程就是如此循环往复 直到项目的结束 当然 在上述的核心过程之外 还涉及其他一些相关 的活动和操作流程 下面按不同的角色分工予以列出 各开发人员按照项目经理发布的开发策略或模型进行工作 SIO 负责将各分项目的工作成果归并至集成分支 供测试或发布 SIO 可向 CCB 提出设立基线的要求 经批准后由 CMO 执行 CMO 定期向项目经理和 CCB 提交审计报告 并在 CCB 例会中报告项目在软件过程中可能存在的问 题和改进方案 在基线生效后 一切对基线和基线之前的开发成果的变更必须经 CCB 的批准 CCB 定期举行例会 根据成员所掌握的情况 CMO 的报告和开发人员的请求 对配置管理计划作出 修改 并向项目经理负责 七 软件配置管理的关键活动 1 配置项 Software Configuration Item SCI 识别 Pressman 对于 SCI 给出了一个比较简单的定义 软件过程的输出信息可以分为三个主要类别 1 计算机程序 源代码和可执行程序 2 描述计算机程序的文档 针对技术开发者和用户 以及 3 数据 包含在程序内部或外部 这些项包含了所有在软件过程中产生的信息 总称为软件配置项 由此可见 配置项的识别是配置管理活动的基础 也是制定配置管理计划的重要内容 软件配置项分类软件的开发过程是一个不断变化着的过程 为了在不严重阻碍合理变化的情况下来控 制变化 软件配置管理引入了 基线 Base Line 这一概念 IEEE 对基线的定义是这样的 已经正式通 过复审核批准的某规约或产品 它因此可作为进一步开发的基础 并且只能通过正式的变化控制过程改变 所以 根据这个定义 我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线 配置项两类 例如 基线配置项可能包括所有的设计文档和源程序等 非基线配置项可能包括项目的各类 计划和报告等 配置项的标识和控制 所有配置项都都应按照相关规定统一编号 按照相应的模板生成 并在文档中的规定章节 部分 记 录对象的标识信息 在引入软件配置管理工具进行管理后 这些配置项都应以一定的目录结构保存在配置 库中 所有配置项的操作权限应由 CMO 严格管理 基本原则是 基线配置项向软件开发人员开放读取得权限 非基线配置项向 PM CCB 及相关人员开放 2 工作空间管理 在引入了软件配置管理工具之后 所有开发人员都会被要求把工作成果存放到由软件配置管理工具所 管理的配置库中去 或是直接工作在软件配置管理工具提供的环境之下 所以为了让每个开发人员和各个 开发团队能更好的分工合作 同时又互不干扰 对工作空间的管理和维护也成为了软件配置管理的一个重 要的活动 一般来说 比较理想的情况是把整个配置库视为一个统一的工作空间 然后再根据需要把它划分为个 人 私有 团队 集成 和全组 公共 这三类工作空间 分支 从而更好的支持将来可能出现的并行 开发的需求 每个开发人员按照任务的要求 在不同的开发阶段 工作在不同的工作空间上 例如 对于私有开发 空间而言 开发人员根据任务分工获得对相应配置项的操作许可之后 他即在自己的私有开发分支上工作 他的所有工作成果体现为在该配置项的私有分支上的版本的推进 除该开发人员外 其他人员均无权操作 该私有空间中的元素 而集成分支对应的是开发团队的公共空间 该开发团队拥有对该集成分支的读写权 限 而其他成员只有只读权限 它的管理工作由 SIO 负责 至于公共工作空间 则是用于统一存放各个 开发团队的阶段性工作成果 它提供全组统一的标准版本 并作为整个组织的 Knowledge Base 当然 由于选用的软件配置管理工具的不同 在对于工作空间的配置和维护的实现上有比较大的差异 但对于 CMO 来说 这些工作是他的重要职责 他必须根据各开发阶段的实际情况来配置工作空间并定制 相应的版本选取规则 来保证开发活动的正常运作 在变更发生时 应及时做好基线的推进 3 版本控制 版本控制是软件配置管理的核心功能 所有置于配置库中的元素都应自动予以版本的标识 并保证版 本命名的唯一性 版本在生成过程中 自动依照设定的使用模型自动分支 演进 除了系统自动记录的版 本信息以外 为了配合软件开发流程的各个阶段 我们还需要定义 收集一些元数据 Metadata 来记 录版本的辅助信息和规范开发流程 并为今后对软件过程的度量做好准备 当然如果选用的工具支持的话 这些辅助数据将能直接统计出过程数据 从而方便我们软件过程改进 Software Process Improvement SPI 活动的进行 对于配置库中的各个基线控制项 应该根据其基线的位置和状态来设置相应的访问权限 一般来说 对于基线版本之前的各个版本都应处于被锁定的状态 如需要对它们进行变更 则应按照变更控制的流程 来进行操作 4 变更控制 在对 SCI 的描述中 我们引入了基线的概念 从 IEEE 对于基线的定义中我们可以发现 基线是和变 更控制紧密相连的 也就是说在对各个 SCI 做出了识别 并且利用工具对它们进行了版本管理之后 如 何保证它们在复杂多变得开发过程中真正的处于受控的状态 并在任何情况下都能迅速的恢复到任一历史 状态就成为了软件配置管理的另一重要任务 因此 变更控制就是通过结合人的规程和自动化工具 以提 供一个变化控制的机制 在本文的前面的部分中 已经把 SCI 分为基线配置项和非基线配置项两大类 所以这里所涉及的变更 控制的对象主要指配置库中的各基线配置项 变更管理的一般流程是 A 获得 提出变更请求 B 由 CCB 审核并决定是否批准 C 被接受 修改请求分配人员为 提取 SCI 进行修改 D 复审变化 E 提交修改后的 SCI F 建立测试基线并测试 G 重建软件的适当版本 H 复审 审计 所有 SCI 的变化 I 发布新版本 在这样的流程中 CMO 通过软件配置管理工具来进行访问控制和同步控制 而这两种控制则是建立 在前文所描述的版本控制和分支策略的基础上的 5 状态报告 配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况 这样的 报告应该是定期进行 并尽量通过 CASE 工具自动生成 用数据库中的客观数据来真实的反映各配置项 的情况 配置状态报告应根据报告应着重反映当前基线配置项的状态 以作为对开发进度报告的参照 同时也 能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析 配置状态报告应该包括下列主要内容 A 配置库结构和相关说明 B 开发起始基线的构成 C 当前基线位置及状态 D 各基线配置项集成分支的情况 E 各私有开发分支类型的分布情况 F 关键元素的版本演进记录 G 其它应予报告的事项 6 配置审计 配置审计的主要作用是作为变更控制的补充手段 来确保某一变更需求已被切实实现 在某些情况下 它被作为正式的技术复审的一部分 但当软件配置管理是一个正式的活动时 该活动由 SQA 人员单独执 行 总之 软件配置管理的对象是软件研发活动中的全部开发资产 所有这一切都应作为配置项纳入管理 计划统一进行管理 从而能够保证及时的对所有软件开发资源进行维护和集成 因此 软件配置管理的主 要任务也就归结为以下几条 1 制定项目的配置计划 2 对配置项进行标识 3 对配置项进行 版本控制 4 对配置项进行变更控制 5 定期进行配置审计 6 向相关人员报告配置的状态 在此 我想特别指出的是 由于软件配置管理覆盖了整个软件的开发过程 因此它是改进我们的软件 过程 提高过程能力成熟度的理想的切入点 希望本文所描述的这个软件配置管理的角色分配和工作流程 能在实践中不断地得到完善 从而使我们的软件开发活动能够更加有序 高效的进行 八 实施配置管理的收益 国内很多软件企业已经逐渐认识到配置管理的重要性 都希望通过实施配置管理来提高软件开发管理 的水平 增强企业自身的竞争力 应对市场的压力 针对市场的这些需求 Hansky 公司在中国市场推出了业界技术领先的软件配置管理解决方案 产品 包括配置管理工具 Firefly 和变更管理工具 Butterfly Firefly 是 Hansky 公司推出的软件配置管理系统 它 可以轻松管理 维护整个企业的软件 代码和文档 Firefly 是一个高性能 运行速度极快的软件配置管理 系统 支持不同的开发 运行平台 因此它能在整个企业中的不同团队 不同项目中都得以广泛的应用 Firefly 能够对团队开发提供有力的支持 开发团队一旦拥有了 Firefly 就可以非常准确的定义 软件将在什么时间发布 当前发布版本中有哪些功能 由哪些组件构成 当前版本中加入了针对哪些 Bug 的修改 软件的某个修改是谁认可的 如何建立新的发布版本 等等 Butterfly 是 Hansky 公司提供的新一代的软件变更请求管理软件 它以软件产品为中心 有效的协调 软件项目中各职位人员的工作 能够使软件项目在较短时间内高质量完成 Butterfly 的主要功能如下 提供对开发过程中的缺陷 建议和任务的追踪管理 规划开发过程 完善源代码编写 提高软件重用率 最大限度保护企业知识财富 提供丰富的报表功能 以直观图形统计开发人员的工作进度和编码质量 客观评价员工表现 优化业务流程 科学的工作流系统使用户工作起来有条不紊 大大提高工作效率 同时用户可以根据 实际情况简单 快捷地定制自己的业务流程 掌握工作进度 在软件开发的各个阶段进行都可以进行强大的过程控制 开发人员可以明确地了解他被分配的开发任务 并根据优先级依次完成 提供友好的人机界面 支持工作分配的电子邮件自动通知 方便各种类型的工作人员使用 增加沟通 和交流 对软件的错误进行系统管理 从根本上提高软件产品竞争力 提高产品质量 加速开发进程 规范软件产品开发的各个阶段 避免浪费不必要的时间 Hansky 公司的配置管理解决方案给公司带来的益处将是显而易见的 管理者能够轻松控制产品的进 度 质量 开发人员将有更多的时间进行创造性的工作 测试人员将依照一个标准的流程高效完成日常工 作 产品发布人员能够确保交到用户手中的产品的质量 具体而言 用户可以在资金 管理水平和保护知识财富等方面得到切实收益 节约用户资金 1 Hansky 配置管理系统的总体实施成本低 对硬件系统性能的要求低 可以跨平台使用 节约了用户的投资 安装简单 易于维护 无需专职的系统管理员 功能简洁 实用 易于学习和掌握 可以有效缩短配置管理系统投入实际使用的周期 良好的扩展性和灵活的 License 管理方式 以及组件式的解决方案 使得我们的配置管理系统既支持 小组模式的用户 也能够支持大规模团队的协同开发工作 并且能够方便地进行扩展 用户可以根据实际 需要 灵活的配置 大大降低了降低初期投入的资金 具有前瞻性 保护用户的投资 Hansky 公司的软件配置管理产品采用最新的技术 如纯 TCP IP 技术 J2EE 技术 MS NET 的开发环境等 和全新的应用模式 如三层结构 B S 应用结构等 确保系统在 较长的时间内不会落后于同类产品或不需要技术上的更新 自带存储库增量备份 恢复功能 节约用户在备份方面的支出 2 缩短用户的产品开发周期 利用 Hansky 的 Firefly 系统对开发资源进行版本管理和跟踪 可以建立公司级的代码知识库 保存开 发过程中的所有历史版本 这样大大提高了代码的复用率 还便于同时维护多个版本和进行新版本的开发 最大限度地共享代码 利用 Butterfly 组建开发团体之间的问题跟踪及消息通讯机制 通过与电子邮件系 统的结合大大增强了开发团体之间的沟通能力 通过丰富的报表功能可对发现的问题进行整理 以报表方 式分类报出 作为开发的指导 通过使用 Hansky 的配置管理套件可以提高开发效率和产品质量 避免了 代码覆盖 沟通不够 开发无序的混乱局面 大大缩短了产品的开发周期 3 降低产品的部署费用 使用 Hansky 的软件配置管理解决方案后 用户可以在 Hansky 技术专家的帮助下建立规范的配置管 理流程 所有的软件产品将得到统一有效的管理 借助 Firefly 和 Butterfly 工程人员可以通过访问服务器 直接获取所需的最新版本 查找公司的知识库 提交变更请求 收集用户的反馈意见 开发人员无需到现 场即可再现用户环境 集中解决问题 发布补丁 这样可以同时响应多个地点的项目 防止开发人员分配 到各个项目点 力量分散 人员不够的弊端 同时节约大量的旅差费用 提高软件开发管理的水平 1 改进用户的开发工作模式 使用 Hansky 的配置管理解决方案 可以有效地改进用户的软件开发模式和过程 提高企业软件能力 成熟度的级别 借助 Firefly 和 Butterfly 用户可以 有效的管理工作空间 各个成员的具有独立的工作空间 并能记录其变更集和整个生命周期中的完整 变更历史 简便建立分支 支持分支之间的比较与合并 归并 管理基线 支持并行开发模式 提高开发效率 支持异地开发 Firefly 通过自动或手动同步不同开发地点的的存储库 为地理分布的开发团队提供很 好的支持 集成变更请求管理与项目生存周期中的变更记录与追踪 优化测试流程 完善的发布管理 可以方便的回溯任意版本 为不同的用户定制应用程序的版本 促进系统的快速部 署 提供发布版本内容的审计能力 支持变更集和原子事务 确保变更的一致性 支持离线的版本管理 帮助用户记录项目证明周期内的完整历史 内置 Defect RFE Task 问题 建议 任务 工作流 符合正规软件公司的软件开发流程 科学的 工作流系统可以使公司人员工作起来得心应手 有条不紊 从而大大提高工作效率 2 加强项目管理能力 通过浏览器 项目负责人可以方便地查看项目进展情况以及员工工作情况 利用 Web 界面即可实现代码复查和项目状态复查 丰富的图表 报告功能 可以自动生成变更统计报告 配置审计报告 支持过程管理与进度分析