仓库管理系统设计

前言

随着全球信息科技的飞速发展，当今社会已经进入了信息化的社会，企业信息管理的重要性也越来越突出。仓储管理是商业企业经营管理中的重要环节，也是一个企业能否取得效益的关键。仓储管理决策的正确与否直接影响到生产企业的效益问题，如果能够及时掌握销售和库存情况，合理配置企业资源，加快资金周转，减少企业商品在仓库中的积压时间，加快物质的流通频率，那么企业就能取得最佳的效益。然而，在传统的仓储管理中，企业领导者往往由于收集不到底层的数据而不能进行科学决策，最终导致企业资源的浪费，造成企业的运营成本居高不下。面对现代的市场环境，企业必须借助新型技术来解决仓储管理中可能出现的问题，提升自身的管理水平，加强仓储管理的力度。

    本文共分为六章介绍仓储系统的开发过程。第一章是系统调研，主要介绍公司基本情况、组织机构设置及其职能，并在了解仓储业务的基础上，分析业务流程，研究系统开发的可行性。第二章是系统分析，主要在分析业务流程的基础上使用结构化工具构造出新系统的逻辑结构模型。第三章是系统设计，将系统逻辑方案转换成可以实施的物理方案。第四章是系统实施，主要介绍了系统开发使用的开发工具及开发的软硬件环境。第五章是系统维护与评价，主要介绍了系统的维护与评价。 第六章是结论，就是系统开发的总结。

  

1系统调研

1.1 公司简介

    大成农牧(营口)有限公司的母公司大成农牧有限公司的发展历程是一步一个脚印走过来的．

    1952年 

    韩浩然先生在台南开办的一间小黄豆柞油厂为今天台湾最大的农畜食品上市公司开启了序幕，经过五十余年的风雨历程，大成集团已经成为纵惯亚洲、 太平洋地区、在海内外拥有三十多个子公司，一百多家分公司；横览饲料、食品、营养、餐饮、数码价值等八大事业群的国际知名企业集团．

    1990年

    大成集团选择了中国东北这个农业资源丰富的地区作为东北亚公司的生产基地．首先在沈阳投资1000万美元，成立了辽宁大成农牧实业有限公司，其中子公司包括大成农牧(大连)有限公司,大成农牧(营口)有限公司,大成农牧(铁岭)有限公司．1997年大成集团进一步与新加坡政府投资公司及美国大陆谷物公司共同成立了大成东北亚公司．目前大成东北亚公司旗下拥有15家分公司，12座饲料厂，4座肉品加工厂（肉鸡电宰厂）及配套的种鸡场和3座熟食品加工厂，共有四条龙在东北及华北地区封闭运作．

    2002年

    大成东北亚公司选择了黑龙江省三大畜牧强县之一的呼兰县，投资成立了大成农牧（铁岭）有限公司哈尔滨分公司，从事畜禽浓缩饲料及配合饲料的生产和销售．

2005年

随着黑龙江省畜牧业的快速发展，原大成农牧（铁岭）有限公司哈尔滨分公司的产量已远不能满足广大养殖户朋友们的需要，为此集团投入巨资成立大成农牧（黑龙江）有限公司．

    大成农牧(营口)有限公司是大成集团在东北地区最早成立的一批生产企业, 大成农牧(营口)有限公司的成功运营为大成集团在东北地区事业的发展增加了信心,为大成集团在东北乃至东北亚的发展起到了先锋的作用．

1.2企业组织结构

1.2.1公司组织结构图

   图1-1  组织结构图

Fig.1-1Organization structure drawing

图1-2 仓储科组织结构图

Fig.1-2Warehousing branch organization structure drawing

1.2.2部门业务

1）财务部

工作主要包括要求各部门主管每月月底交当月考勤及下月工作安排表;做好会计核算的基础工作,认真收集．审核原始凭证,做好会计的日常管理和核算工作,当好决策参谋,及时．准确地向总经理和有关人员提供真实．可靠的会计信息;及时了解掌握国家的最新税收政策,准确计算应纳税额,按时足额上交各项应交科费;执行公司制定的财务报销制度,凡报销人员须经财务审核工作,总经理签字,方可报销,每月底按时完成出纳现金审核工作,并上交结存表;主动妥善处理好公司办公用品的统购及发放工作．财务部下面还有咨询科统计室,咨询科主要负责两个厂区的计算机软硬件保养维修工作．

2）营业部

主要负责处理公司和客户的关系．客户包括饲养户、饲料购买商、成品鸡购买商及各种承包商． 营业部的职能还包括运用互联网提供在线咨询洽谈服务,下设”在线投资顾问室”．

3）行政部

下设有门卫、食堂、司机室、会议室．行政科长下面还有个科室的分管领导,门卫还有队长对行政科长负责．食堂负责员工的三餐;司机室是对公司的车辆进行配备,头一天会产生车辆调配表下放到各个司机手里,让他们知道他们第二天去哪里进行成鸡运输．会议室包括一级会议室、二级会议室和谈判会议室;一级会议室主要是给公司高级管理者开会专用的,二级会议室是配备给各个部门的, 谈判会议室主要用于公司领导和各客户交谈生意.

4）人事科

主要负责各部门人力资源开发和人才培养工作,为领导决策用人提供依据;负责职工考勤管理工作和劳动保护管理工作;负责整个公司劳动工资管理,编制报批年度工资计划,做好工资升档、晋职晋级、工资变动、奖惩待遇落实等工作的审核、报批;承办整个公司专业技术职务的评聘、晋升、考核、聘用工作;负责公司人事信息的和人事档案管理工作,落实好人事档案保密工作制度;负责生成人事统计报表、劳动工资报表、干部统计汇总表、年度职工考核表的工作,还要做好人事劳资年报工作;负责公司职工养老保险、失业保险和基本医疗保险等社保工作和统计报表的工作;负责公司的离退离休人员工资政策、福利待遇的贯彻落实．

5）生产科

是一个大部门,它包括化验室、前处理、后处理、挂鸡科和车间大厅．化验室对当天要屠宰的活禽进行化验,得出化验报告．交给生产科长．挂鸡科是生产的第一步,将成鸡挂上自动循环链条,前处理是指杀鸡,去毛,和去除内脏等一系列先期工作,后处理包括胸肉组,腿肉组和九件组．九件组是将鸡分成不同的小成品,然后用保险袋装上,运到冷库进行保存．．

6）仓储科

包括检验室和仓管室．检验室主要负责对生产科生产完的小袋肉品进行入库检验和记录,九件室的职工将装成箱的肉品分号类后,送往冷库,检验室的员工对其进行入库登记．．．仓管室主要负责对检验室检验合格的商品进行商品入库登记及商品出库登记，检验室也负责本公司的产品出厂出库检验登记,月底生成产品库存报告、月产品入库报告、月产品出库报告,年底统计出年产品库存报告等为公司的决策层提供准确无误及时的支持．

7）放养部

是负责给饲养户发放鸡雏的．它下面有技术科,主要给饲养户提供技术支持,实验室是对要卖给饲养户的饲料进行实验,检验产品是否合格．

8）动力科

动力科下面分为变电所、锅炉房、制冷室和污水班．变电所负责整个公司生产的供电工作;锅炉房负责冬季整个公司的取暖工作和后勤保障工作;制冷室负责夏季整个公司的防暑工作和对冷库提供冷气输送,确保冷库的正常运行,对公司的产品提供保障．污水班是负责整个生产车间产生的污水运用污水处理系统进行污水处理,使排出去的污水达到国家环保部门的标准．

1.3 现行系统的研究

1.3.1 现行系统存在问题

1、国内外现状研究：

计算机在管理中的应用开始于1954年，当时美国首先用计算机处理工资单。40多年来，计算机在处理管理信息方面发展迅速。例如，60年代美国计算机在管理中应用项目不到300项，到了1975年达到2670项。而现在，美国在财务会计上90%的工作由计算机完成；物资管理中80—100%的信息处理由计算机完成；计划管理中是80—90%。据计算机应用方面发展较快的国家统计，计算机用于经济管理的约占80%；用于科技运算的占8%；用于生产过程控制的占12%。因此，经济管理是计算机应用的主要领域。

当然，由于仓储管理在经济管理中占重要地位，其计算机化在发达国家中也已经达到了相当高的水平。我国在全国范围内推广计算机在管理中的应用，是在70年代末开始的，虽然起步较晚，近几年发展却较快，特别是微型计算机的出现和普及为信息处理提供了物美价廉的手段，对于推动我国管理信息处理的现代化起了重要的作用。 

2、本公司业务存在的问题：

仓储管理对企业来说是一项繁琐复杂的工作，每天要处理大量的单据数据。为及时结清每笔业务，盘点库存和货物流动情况，保证企业生产用料以及货物安全，仓管人员要花费大量人力物力和时间来作数据记录统计工作。

    公司的库存管理部分目前仍为手工、半手工操作。从供应单位办理入库登记开始，到客户领货出库手续为止，所有操作基本上都是由仓库管理人员笔写，手理，加上算盘、计算器来完成。这不仅繁锁，效率低，而且缺乏仓储管理的一些基本手段，如库存状况统计，查询订单量统计等，这给企业在一定程度上造成了管理上的落后，及经济利益上的损失。因此急需上马一个仓储管理系统，来解决目前公司仓储管理上的落后给公司的发展壮大所带来的瓶颈。

1.3.2 业务流程图使用的符号

表1－1业务流程图符号说明

Table1-1 Table of Business Flow Diagram Symbol’s Explanation

1.3.3 系统业务流程图

图1-3 基本信息管理业务流程图

Fig.1-3Figure of transaction process of basic information management

图1-4 入库管理业务流程图

Fig.1-4Figure of transaction process of Warehousing management

图1-5 出库管理业务流程图

Fig.1-5Figure of transaction process of Leaves the storehouse management

图1-6 退货管理业务流程图

Fig.1-6Figure of transaction process of Returned goods management

图1-7 盘点安全检查业务流程图

Fig.1-7Figure of transaction process of Inventorying and Security check

1.3.4 新系统的目标

新系统主要是通过对销售、库存的管理，并通过出入库数据的分析，为企业决策做出准确的判断提供依据。依据确定系统目标的原则：可行性原则、重点性原则、求同性原则、确切性原则[4]，确定新系统的目标为：

1)亲切的操作界面，各种单据输入层次清晰、简单、直观，符合管理人员习惯，为用户提供多种灵活的选择方式，程序能提供出错提示。

2）信息的录入、保存和更新，包括基本资料、采购单据、销售单据、库存方面单据的录入、保存和更新。

3）信息查询，提供对各种表单的查询，以及数据的汇总查询。

4）各种单据数据统计和报表打印。

5）系统管理，包括系统用户的权限管理，加强数据与信息的安全性。

1.3.5 系统实现功能

新系统具备基本信息管理，入库管理，出库管理，退货管理，盘点安全检查管理等五大功能。

1.4 系统可行性分析

    可行性研究就是做出系统开发可行与否的结论。对于仓储管理系统的可行性，下面主要就系统开发的必要性、技术上的可行性、经济可行性和运行可行性等几个方面进行分析：

1.4.1系统开发的必要性

现阶段生产型企业的竞争再不仅仅是质和量的对决了，随着全球信息化的到来，企业之间的较量也要融入信息收集和处理等，由于大成农牧（营口）有限公司内仓储管理像现阶段很多生产型企业一样在企业内部物资信息的流通中还在采用纯人力的手工操作，这种情况只能说可以维持日常生产、存储的进行，但在某种程度上还不能够满足公司日益增长的业务需求。基于此我们打算开发一个关于仓储管理方面的系统做试运行，希望可以弥补现在存在的问题，所以企业的关于仓储管理方面的系统开发是必要的。

1.4.2 技术可行性

目前在管理信息系统开发中，使用的开发方法种类很多。但主要用到的是结构化开发方法和面向对象的开发方法。本系统采用结构化的开发方法，它是70年代发展起来的一种软件开发方法。它的突出优点是它强调系统开发过程的整体性和全局性，技术成熟，是一种被广泛采用的系统开发方法。

在软件方面。系统的前台开发工具应用了Eclipse3.2，Eclipse3.2是一个可视化图形界面应用程序开发环境。利用Eclipse3.2开发程序，不仅开发效率高，而且开发完成的应用系统能够切实保证数据的安全性、正确性，能够为最终用户提供一个界面友好、数据访问便捷高效、功能齐备的数据库应用系统[2]；系统的基本功能调试成功之后，更可以加入多媒体界面，使系统界面更加有亲切感，更加人性化；后台选取了Mysql，这些都是目前主流的大型的系统开发工具，功能完善，操作简捷，开发技术成熟，开发风险小，可以完成本系统的设计、开发和管理工作。

硬件方面。现在的计算机硬件技术和网络技术发展极为迅速，而且成本和价格下降很多，硬件设备完全能够满足本系统的开发和运行的要求。

用户使用和管理信息系统的能力方面。图书馆已经做出了部门调整，专门设立了网络信息中心，有专门的系统维护和设备及网络维护人员。

可见，开发新系统在技术上完全可行的。

1.4.3 经济可行性

虽然开发系统，购置新的设备和软件，人员培训等方面都需要花费一定的资金，但从长远利益来考虑，使用数据库技术，实行现代化管理，能有效的提高管理工作效率，提高资源利用率，节省了大量的人力、物力，还节省了大量的时间和经费开支，对管理机制的改革和进步起也到了巨大的推动作用。而且，从公司目前的经济状况和未来的发展预期来看，还是有能力承担此项费用的。

综合考虑，本系统经济方面可行。

1.4.4 运行可行性

从目标系统使用难易程度上来看并不复杂，界面设计亲切，容易使用，通过接触了解到公司的员工有较强的接受新事物的能力，大多数平时都有过使用电脑的经历，学习该系统的使用不会有大的困难。系统管理员要有一定的数据库方面的知识，要掌握设置数据源连接数据库的方法并要对公司的运作有较为深入的了解。但只需专业人事做短期的培训就可以拥有熟练使用系统的能力。最后，就是需要操作员对本系统的各部分功能有全面的了解。因此，本系统在操作上是完全可行的。

    综上所述，该进销仓储信息系统具备可开发的条件，项目可行。

2 系统分析

系统分析是管理信息系统开发的生命周期中的重要阶段。在系统规划的基础上，按系统规划所确定的各子系统开发优先次序进行各子系统开发时，则需要分别进行系统分析、系统设计、系统实施工作。系统分析是从逻辑上提出一个完成系统功能的新系统的模型。

系统分析阶段的目标就是按系统规划所确定的总目标及子系统的范围，进一步明确子系统的目标及用户需求，提出新系统的逻辑模型，即从逻辑上，或从信息处理的功能需求上提出系统的解决方案。系统分析在整个系统开发中，是要解决“做什么”的问题，为下一个阶段的系统设计（也称系统的物理模型设计）、解决“怎样做”提供依据。

系统分析的结构化工具有数据流程图、数据字典、处理逻辑表达工具等。

2.1 数据流程图

    数据流程图（Date Flow Diagram 简称DFD）是结构化分析的一种主要工具，是管理信息系统主要的开发工具，是组织中信息运动的抽象，是MIS逻辑模型的主要形式。它使用一组简单的符号，描述系统的数据由外部“流入”系统，经过多级的加工处理，经过不同的结构的存储，最后以用户所需的各种形式“流出”的全过程。它是面向功能的。

利用DFD，可以清楚地描绘出系统的输入、输出及系统的数据处理功能、数据处理过程、数据的存储情况等。

利用DFD，可以将系统分析员在系统分析中所设计的新系统逻辑模型描述出来，以表达设计者的逻辑方案及新系统的设计思想。

DFD是系统设计的主要依据。因为结构化系统设计方法强调系统开发的阶段性，前一阶段是后一阶段的基础，后一阶段是前一阶段的继续。在进行系统的物理设计时，必须依据逻辑模型。

DFD是利用有限的符号（外部实体，数据流 ，数据处理和数据存储）及若干规则来描述系统逻辑模型。

2.1.1 数据流程图中使用的符号及表示含义

数据流程图符号说明：

表2-1 DFD符号说明表

Table 2-1 Table of DFD symbol description

2.1.2 仓储管理系统的顶层图

图2-1  DFD顶层图

Fig.2-1 The top figure of DFD

2.1.3 一级细化图

图2-2  P1一级细化DFD

Fig.2-2 The first level detailed analysis DFD of P1

图2-3  P2一级细化DFD

Fig.2-3 The first level detailed analysis DFD of P2

图2-4  P3一级细化DFD

Fig.2-4 The first level detailed analysis DFD of P3

图2-5  P4一级细化DFD

Fig.2-5 The first level detailed analysis DFD of P4

图2-6  P5一级细化DFD

Fig.2-6 The first level detailed analysis DFD of P5

2.1.4 二级细化图

图2-7  P1的二级细化DFD

Fig.2-7 The second level detailed analysis DFD of P1

图2-8  P2的二级细化DFD

Fig.2-8 The second level detailed analysis DFD of P2

图2-9  P3二级细化DFD

Fig.2-9 The second level detailed analysis DFD of P3

图2-10  P4二级细化DFD

Fig.2-10 The second level detailed analysis DFD of P4

图2-11  P5二级细化DFD

Fig.2-11 The second level detailed analysis DFD of P5

2.1.5 三级细化图

图2-12  P1三级细化DFD   

Fig.2-12 The third level detailed analysis DFD of P1

图2-13  P3的三级细化DFD

Fig.2-13 The third level detailed analysis DFD of P3

图2-14  P5三级细化DFD

Fig.2-14 The third level detailed analysis DFD of P5

2.1.6 数据流清单

表2－2 数据流清单

Table2-2 List of Data Flow

2.1.7 数据存储清单

表2－4 数据存储清单

Table2-4 List of Data Store

2.2 数据字典

数据字典(Data Dictionary)是在完成新系统数据流程图的设计的基础上，用来对DFD的进一步定义和描述的结构化工具，是构成系统逻辑模型的重要部分，是系统设计、实施和维护的重要依据[7]。

2.2.1 数据字典的内容

   上面已经对人事管理信息系统的数据流程进行了分析，得到了数据流程图。数据流程图描述了系统的分解，即系统由哪几个部分组成、各部分之间的联系等，但是对于数据的详细内容却无法在数据流程图中反映，而只有当数据流程图中所出现的每一个成分都给出了明确的定义之后，才能完整、准确地描述这个系统。

数据字典（Data Dictionary,DD）就是在系统数据流程图的基础上，进一步定义和描述所有的数据元素、数据流、数据存储、处理过程和外部实体的详细逻辑内容与特征的工具，数据流程图与数据字典等工具相互配合就可以从图形和文字两个方面对系统的逻辑模型进行完整地描述。数据字典中共有五类条目,即数据元素,数据流,数据存储,处理逻辑和外部实体。

（1）数据元素：是数据的最小组成单位，在数据字典中主要描述其名称，编号，类型，长度，取值范围等。

（2）数据流条：由一个或一组固定的数据元素组成，在数据字典中的描述主要包括：名称，编号，来源，去向，组成等。

（3）数据存储：在数据字典中，数据存储条目主要描述数据的逻辑存储结构，而不涉及它的物理组织。

（4）处理逻辑：对数据流程图中最底层的处理逻辑加以说明。除了处理逻辑的名称，编号，简要的说明之外，还要说明处理逻辑的输入数据流和输出数据流。对处理过程的描述，目的在于使读者有一个比较明确的概念，了解这一处理的主要功能。

（5）外部实体：是信息系统中数据的来源和去向。数据字典中描述其名称，编号，简要的说明以及外部实体产生的数据流和系统传送给其的数据流。

2.2.2 数据字典

由于系统很大，所以建立数据字典的工作量很大,相当繁琐,但这又是不可缺少的一项工作，下面对系统中的比较典型的几个数据字典加以描述：

数据元素字典

图2-15商品编号数据元素卡

Fig.2-15 The data element card of product number

图2-16 客户编号数据元素卡

Fig.2-16 The data element card of customer number

数据流字典

图2-17 商品信息单数据流卡

Fig.2-17 The dataflow card of product information

图2-18订单信息查询结果数据流卡

Fig.2-18 The dataflow card of order form information

数据处理字典

图2-19 商品信息登记数据处理卡

Fig.2-19 The data process card of product information enter

图2-20安全库存检查数据处理卡

Fig.2-20 The data process card of safety stock check

数据存储字典

图2-21商品信息帐数据存储卡

Fig.2-21The data store card of product information account

图2-22库存明细帐数据存储卡

Fig.2-22 The data store card of stock itemized account

3 系统设计

经过系统分析阶段的工作,得到了目标系统模型,“做什么”的问题解决了。而将目标系统的总体设计方案具体化，解决“如何做”的问题，就是系统设计阶段的工作。

所谓系统设计，就是根据目标系统逻辑功能的要求，结合实际情况，采用一定的方法，详细地确定目标系统的结构和具体的实施方案，即建立目标系统的物理模型。

在这一阶段，要根据实际的技术条件，经济条件和社会条件，确定系统的实施方案。至此，可以用不同的方法来实现系统，根据一个逻辑模型可提出多个物理模型。

系统设计包括两个方面，首先是总体设计，其次是系统的详细设计，即具体物理模型设计，为各个具体任务选择适当的技术手段和处理方法。系统设计的主要内容包括系统结构设计、代码设计、数据库设计以及具体模块设计等设计工作。

系统设计是一项十分复杂的工作。在信息系统中数据量大，数据结构复杂、数据来源分散，要及时地采集、处理和传递这些数据本身就是一件很繁琐的工作。由于系统设计产品的无形性，系统设计的结果在未变成程序并运行之前是不能真正表现出来的。因而系统设计工作一定要保证高质量，否则会导致系统开发工作的返工甚至失败。所以我们在系统设计中主要遵循系统的观点，采用模块化的结构，做到阶段划分明确、分步实现，尽可能地选用先进及合适的计算机程序设计语言。

系统设计要尽可能地满足可靠性，工作质量，可维护性，工作效率和经济性的指标。

3.1 系统结构设计

系统的物理结构设计的依据是系统的逻辑模型，使用结构化设计工具HIPO（分层的输入、处理、输出）图或系统结构图来描述。新系统的物理结构设计采用结构化设计工具HIPO图来描述。

HIPO（Hierarchy plus Input-Process-Output）技术，是采用分层次的模块图来描述一个系统的输入、处理、和输出过程[2]。

对新系统的模块进行逐层分解，可以得到如下系统的HIPO图。

图3-1 HIPO

Figure3-2 HIPO

3.2 模块设计

HIPO图给出了系统软件的结构，而对于结构中每个模块的输入、输出和内逻辑处理内容，则用IPO图（输入-处理-输出图）来进行详细的描述，就像数据流程图需要数据字典进行注解一样，HIPO图的缺陷通过IPO图加以完善。IPO图描述了HIPO中每一个模块的输入、输出和处理结构，是系统设计的重要成果。

IPO图实际上是一张图形化的表格，它描述分层图中每一个模块的输入输出关系，处理内容，本模块的内部数据和模块间的调用关系，是系统设计的重点成果，是系统实施阶段编制程序设计任务书和进行程序设计的出发点和依据。在系统设计中，每一个模块必须有相应的IPO图作为设计结果的描述。但由于本系统的IPO图较多，因而只选取其中有代表性的几个IPO图列出。

图3-2 商品信息录入IPO图

Fig.3-2 IPO figure of product information enter

3.3 代码设计

代码又称编码，它是客观实体的名称、属性、状态等内容的标识。是用来表征客观事物的类别，以及属性的一个或一组计算机识别和处理的特殊符号或记号。如数字、字母或它们的组合。

经过编码而形成的代码系统，可提高信息处理的速度，保证信息处理准确性，其主要作用表现在：一是标志作用；二是统计分类与检索作用；三是对对象的状态的描述作用。

3.3.1码设计的原则

（1）唯一确定性：每一个代码都仅代表唯一的实体和属性。

1. 简洁性：代码的设计要尽可能简单明了，这样可提高运算速度和减少存储空间，还可降低误码率及输入输出的速度。
2. 可扩充性与灵活性：代码系统要考虑系统的发展变化。当增加新的实体或属性时，直接使用原代码加以扩充，而不需要变动代码系统。
3. 标准化：国际、国家和行业的有关标准是代码设计的重要依据，应尽量采用已标准化的编码，以使其通用化。
4. 便于识别和记忆：为了同时适合人和计算机，代码不仅要有逻辑含义，而且还应便于识别和记忆，对于一些容易混淆的字符和数字应少用。

3.3.2 代码设计

在本系统中所要涉及的代码设计主要有：客户、商品，订单编号等。原则上各个单据还应为其设计各种单号，以识别各张表单，但各个物理单据已经有相关的编号，且单号均由数字组成，由计算机自动生成，方便计算机的处理与使用，所以就不再为它们设计相关的代码，延用原单据的单号。

客户的代码设计，本系统所涉及的客户比较多，分为批发与零售。在此，采用客户名称的各个字的汉语拼音字母的第一个字母组成，接下来是客户类型码。如果遇上两个相同的话，就在它们的代码后面再加上数字以示区分，三个以上同样道理。这样设计主要考虑到方便记忆与通用性。设计模式如下

客户代码设计（见图3-2）

图3-5客户代码

Figure3-5 Customer code

商品的代码设计（见图3-3），商品的代码设计是设计代码的重点与核心。经过各个方面的考虑，将商品的代码设计成如下结构：商品码+类别码+等级码，设计模式如下：

图3-6商品代码

Figure3-6 Commodity code

订单的代码设计（见图3-4）

图3-7 订单代码

Figure3-7 Order form code

3.3.3 代码的校验

代码的唯一性和准确性是至关重要的，因而代码的校验也是必不可少的。代码校验的目的是保证输入的正确性，本系统采用的校验方法如下：

本系统的代码均是自动生成的方式给出，所以在录入或修改过程中没有手工输入。这样大大节省了代码的校验的工作。在查询统计中，需要手工输入代码的，我们也将输入过程中将编辑控件设定输入的类型与位数。这样就可以大大降低出错的频率，另外对于常输入的固定的数据采用了下拉列表的形式，这样就保证了特定数据输入的万无一失。

3.4 数据库设计

根据系统功能设计的要求以及功能模块的划分，对于本系统的数据库，可以列出以下的数据项和数据结构:

名称：　用户表

表名称标识：　operator

数据来源：　用户管理模块录入。

Table 3-1

表3-1

名称：　商品入库表

表名称标识：　warehousingin

数据来源：　数据入库模块录入。

Table 3-2

表3-2

名称：　商品出库表

表名称标识：　warehousingout

数据来源：　数据出库模块录入。

Table 3-3

表3-3

名称：　库存明细表

    表名称标识：　stockiformation

数据来源：　数据入库、出库模块计算所得。

Table 3-4

表3-4

名称：　商品信息表

    表名称标识：　commodityinformation

数据来源：　商品管理模块录入。

Table 3-5

表3-5

名称：　客户信息表

表名称标识：　customerinformation

数据来源：　客户管理模块录入。

Table 3-6

表3-6

名称：　订单表

表名称标识：　orderform

数据来源：　订单管理模块录入。

Table 3-7

表3-7

3.5 输出设计

输出设计是用计算机系统将输入数据进行处理的结果，通过一定的表现形式，提供用户使用。

本系统的输出设计本着为管理者提供简洁、明了、和有效数据信息的思想进行设计的，设计的内容包括输出的内容、输出方式和输出介质三方面。

1）商品入库单

输出代号：OP001                    输出名称：商品入库单

输出方法：打印输出                 输出设备：打印机

输出介质： 打印纸                  输出周期：每月一次

相关模块：打印采购订单             数据来源：商品入库单表

份    数：一份

数据结构：

表3－8商品入库单表

Table 3-8Table of Store Information

输出格式：                      

图3－8 商品入库单输出格式

Figure3-8 Output Form of Storer Information

3.6 输入设计  

输入设计的目标是保证向系统输入正确的数据。它是用户和系统运行的接口，输入设计的好坏，直接关系到用户对系统的满意程度和系统输入信息的正确性。

本系统的输入设计中尽量遵守了：输入量最小原则，输入过程简单原则，对输入数据的早检验原则。

1）商品入库信息

输入代号：IP001                       输入名称：商品入库信息

输入方法及设备：人工键盘输入

数据来源：由生产部门提供

原始数据格式：

图3－9商品入库信息原始格式

Figure3-9 Original Form of Store Information

输入屏幕格式：

图3－10 入库信息输入格式

Figure3-10 Input Form of Material Information

3.7 人机对话设计

人机对话主要是指在计算机程序运行中，使用者与计算机系统之间通过终端或其他装置进行一系列交替的询问与问答。对话设计的任务是与用户共同确定对话方式、内容与具体格式。本系统中主要使用了菜单式、问答式、提示式、输入数据式等对话方式。

1) 菜单式：将需要选择的操作项目在显示器上逐项列出，让用户选择某一项。

2) 问答式：在系统运行过程中，通过问答的方式来实现程序的去向。例如，在用户删除某一条信息时，提示用户确定要删除。

3) 提问式：用户在操作过程中出现误操作或错误的输入时，系统及时地给出提示和指导信息。例如，当管理输入密码出错时，系统会提示“密码错误，请重新输入！”

4) 输入数据式：查询程序需要用户通过对话方式输入查询对象的关键字或某些信息；修改或删除某个记录也需通过对话方式输入修改或删除对象的关键字或其它信息。

对话设计的原则：

1）对话要简单明了，不具二义性。

2）对话要求用户回答的信息必须简单，操作容易。

3）对于用户操作错误，给与明确指出，并允许用户修改错误。

4）对话信息的显示格式要精心设计，做到清晰，醒目，美观。

5）可采用多窗口技术，彩色光带，增强闪烁等方法来达到醒目的目的。

6）对话信息不能在屏幕上久留，对话结束应该马上消失[3]

3.8 软硬件配置

在进行软硬件配置时，要结合系统的需求、经济的可行性、质量要求等方面做综合的考虑。

1） 硬件配置:

（1）服务器配置：应有较高配置，因为服务器是整个系统的中枢，所有的数据信息都保存在服务器中，各客户端处理业务都需要访问服务器端。具体配置：

CPU：Intel P4 2.4或更高；内存：512M或更高；硬盘：80G或更高；光驱：52X或更高；显示器：17寸或更高；键盘鼠标使用光电套或更高。

（2）客户端配置：CPU：Intel P3或更高；内存：512M 或更高；硬盘：40G或更高；光驱：52X或更高；显示器：17寸或更高；键盘鼠标使用光电套或更高。

2） 软件配置

该系统的客户机端需在Windows98或更高版本的操作系统下运行，服务器端需在Windows2000 Server或更高操作系统下运行，后台数据库管理系统为服务器上安装MySQL数据库。

   

4 系统实施

系统实施阶段的工作是要将系统设计阶段得到的目标系统物理模型转换为可实际运行的软件系统。一个好的系统设计方案只有经过精心的实施，才能带来实际的效益。因此，系统实施阶段的工作对管理信息系统的最终质量有着直接的影响。

4.1 系统开发工具的选择

4.1.1　数据库平台

运行环境：Windows 9x 、Windows 2000、Windows XP

4.1.2　开发软件

现在，市场上可以选购的应用开发产品很多，流行的也有数十种。目前在我国市场上最为流行、使用最多、最为先进的可用作企业级开发工具的产品有：

基于C的：Visual Basic   Visual FoxPro 6.0    Visual C等；

基于Java的：Eclipse  MyEclipse  JBuilder等；

由于该系统的数据使用量不是太大，在此选用小型的数据库MySQL，在基于java的基础上选用MyEclipse6.0作为开发软件，而服务器选用的是Apache的Tomcat6.0服务器。

4.1.3  软件介绍

MyEclipse是Eclipse的插件，是一款功能强大的J2EE集成开发环境，支持代码编写、配置、测试以及除错。Eclipse 是一个开放源代码的、基于 Java 的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。幸运的是，Eclipse 附带了一个标准的插件集，包括 Java 开发工具（Java Development Tools，JDT）。

    虽然大多数用户很乐于将 Eclipse 当作 Java IDE 来使用，但 Eclipse 的目标不仅限于此。Eclipse 还包括插件开发环境（Plug-in Development Environment，PDE），这个组件主要针对希望扩展 Eclipse 的软件开发人员，因为它允许他们构建与 Eclipse 环境无缝集成的工具。由于 Eclipse 中的每样东西都是插件，对于给 Eclipse 提供插件，以及给用户提供一致和统一的集成开发环境而言，所有工具开发人员都具有同等的发挥场所。

这种平等和一致性并不仅限于 Java 开发工具。尽管 Eclipse 是使用 Java 语言开发的，但它的用途并不限于 Java 语言；例如，支持诸如 C/C++、COBOL 和 Eiffel 等编程语言的插件已经可用，或预计会推出。Eclipse 框架还可用来作为与软件开发无关的其他应用程序类型的基础，比如内容管理系统。

4.2 系统运行环境

运行环境：Windows 2000 , Windows XP，Windows 2003.

处理器型号及内存容量：Intel Pentium 2400 MHz以上，内存256M以上。

外存容量：80G 以上。

媒体及其存储格式：硬盘，数据库。

设备的型号及数量：服务器要求硬盘至少80G一个，若干主机、显示器和鼠标（作为客户端），型号任意。显卡型号要求32 M 以上。

输入及输出设备的型号和数量：输入是键盘和鼠标，型号任意；输出设备使用显示器和打印机。

说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束

仓管员：具有简单的电脑操作能力。

软件公司维护人员：计算机专业人员，具有一定的数据库相关知识和数据维护能力。

预期使用频度：每天二十四小时。

营业员：有简单的电脑操作能力。

4.3 系统测试

系统测试是以找错误为目的,不是要证明程序无错,而是要精心选取那些易于发生错误的测试数据,以十分挑剔的态度证明程序有错。测试时不仅使用合理有效的输入,还要包括无效或不合理的输入数据,将系统运行的结果与预期的结果进行对比,检查程序是否做了该做的事,还要检查程序是否做了不该做的事[13]。

系统测试的方法可分为：人工测试和机器测试。

1. 人工测试

a.个人复查：指源程序编完以后，直接由程序员自己进行检查。

b.走查：一般由3－5人组成测试小组，其成员是从未介入过该软件的设计工作的有经验的程序设计人员。测试人员扮演计算机的角色，人工输入数据，在纸上跟踪监视程序，让人代替计算机沿着程序的逻辑走一遍，以发现其中的错误。

c.会审：测试成员根据错误清单（从以往经验看一般容易发生的错误）填写检测表，列出根据错误类型要提问的问题。会审时测试人员对程序作者提出问题，讨论可能产生的错误。

2）机器测试

a.黑盒测试：也称功能测试。在完全不考虑程序的内部结构和特性的情况下，根据软件的模块说明设计测试用例，从程序的输入和输出特性上测试是否满足设定的功能。

b.白盒测试：也称结构测试。按照程序的内部结构和处理逻辑来选定测试用例，对软件的逻辑路径及过程进行测试，检查它与设计是否相符。

系统测试工作一般有四个步骤：

1）单元测试：即模块测试。测试系统中的每个模块，保证每个模块作为一个独立单元能够正确运行，一般采用白盒测试的方法，根据模块说明，从模块内部结构出发设计用例，进行测试。

2）组装测试：也称组合测试或综合测试。它是按照设计时作出的模块结构图把它们连接起来，以系统设计和程序设计为依据，采用黑盒测试方法进行测试。

3）确认测试：以整个系统作为测试对象，采用黑盒测试的方法，进一步检查系统是否符合需求说明的要求。此测试是面向用户需求的，因此应让用户参与。测试使用的测试用例也应以实际应用数据为基础，不再使用模拟数据。

4）系统测试：它是将信息系统的所有组成部分包括软件、硬件、用户以及环境等综合在一起进行测试，以保证系统的各组成部分协调运行，它要在系统的实际运行现场，在用户的直接参与下进行。

4.4 系统转换

系统转换是指以新系统替换老系统的过程，在转换时要保证新老系统进行平稳而可靠的交接，最后使整个新系统正式交付使用。系统转换有很多种方式，包括直接转换、并行转换和分段转换。本系统使用分段转换，它是在新系统全部正式运行之前，分段一部分一部分地替代老系统，它是一个渐进的过程，转换过程可靠而且费用不高，但是要注意转换中的接口问题，第一批新老系统的转换的效果至关重要，它的效果直接影响以后其他部分的转换。

本系统与旧系统采用的转换方式为并行转换方式， 由于本系统中的工资管理需要很多数据项的计算，但是在测试过程中可能采用的数据都是比较简单的数据，因而很难发现错误，所以工资管理部分我们采用边使用边测试的方式，而档案管理，招聘管理，以及工作变动管理这些主要以记录为主的模块我们采用直接转换的方式，而工资管理初始仍用原来的手工操作进行管理，等确认本系统运行无误后，在放弃手工操作。

4.5 系统完成情况

从系统的分析、设计到实施，花了将近两个月的时间，现在已基本完成，基本达到了系统要预期的目标，也能满足大成农牧（营口）有限公司的业务需求。

表4－1 系统完成情况表

Table4-1 Table of System’s Completed Situation

5 系统维护与评价

5.1 系统维护

新系统进入正常运行阶段，支持公司仓储业，为了改正系统隐藏的错误，扩充功能，延长系统使用寿命，需要不断的对系统进行维护。软件的可理解性、可测试性和可修改性是决定软件可维护性的基本因素。软件生命周期每个阶段的工作都和软件可维护性有密切关系[1]。良好的设计，完善的文档资料，以及一系列严格的复审和测试，使得一旦发现错误时比较容易诊断和纠正；当用户有新要求或外部环境变化时系统能较容易地适应，并且能够减少维护引入的错误。

新系统的维护工作包括硬件设备的维护、数据的维护、代码的维护三方面内容。

1）硬件设备维护，这就需要公司配备专职的硬件维护人员来负责，对设备定期保养和维修突发的故障。

2）数据维护，一般是由数据库管理员来负责，主要负责数据库的安全性和完整性以及进行并发控制。数据库管理员负责对用户定义操作权限，还负责数据库的备份和当系统出现故障得到排除后的数据库的恢复工作。

3）代码维护，新系统的代码设计是建立在对公司业务的深入分析和未来发展预测的基础上的，代码具有可扩充性，有需要只要在原代码上进行扩充即可。因此，系统不需要专门的代码维护工作。

5.2 系统评价

新系统在投入使用后，在应用不断的深入过程中，要对系统的性能进行估计、检查、测试、分析和评审，包括用实际指标与计划指标进行比较，以及评价系统目标实现的程度。通过系统评价，一方面能对系统当前状态有明确的认识，另一方面也可以为系统今后的发展和提高做准备[1]。新系统主要从经济、性能、管理三方面进行评价。

1）经济方面，在调研阶段，经过分析将新系统的经济目标设定为经济实用、尽可能大的经济效益。新系统设计所需的软、硬件配置，在公司经济能力下完全可以负担。新系统的开发运行以后，可以节省人力资源，提高经济效益。系统便捷的输入输出设计，减轻了工作的劳动强度，降低了劳动费用和管理费用。可以说，新系统的使用直接为公司带来经济效益。

2）性能方面，新系统的操作方便、灵活、安全保密性好，完全能够处理公司入库、出库、库存盘点、安全检查等业务的管理及统计工作，且对数据的处理准确、及时，为公司的管理决策提供了有力的依据。新系统有很好人机对话设计，如果操作人员出现误操作，系统会有错误提示，帮助用户完成操作，方便使用。该系统处理速度快，性能稳定，响应时间短，所以从性能的角度看，新系统达到了预期目标。

    3）管理方面，新系统的实施，加快了商业企业现代化管理的进程，使公司管理更加科学。信息处理及时、准确，为公司管理决策提供了有力的证据。新系统采用友好的用户界面，操作简单，管理人员经过简单培训就可以熟练掌握本系统，发挥新系统的优势。，新技术的采用能够促进企业对员工素质的要求的提高，员工素质提高，企业的管理也能上升到一个新的层次。新系统的实施减轻了员工的工作量，使员工有更多的经历放到其他的工作上，提高了整体的工作效率。加快了企业管理现代化的进程。

6 结论

在两个多月的紧张学习后，终于结束了整个毕业设计的工作。通过毕业设计，学习到很多从前根本没有涉猎过的领域和技术，如J2EE，mysql等等，使自己不但熟练得掌握开发工具以及开发流程，更开阔了眼界。回首整个开发设计过程，我的确学到了许多书本上学不到得知识，更重要的是通过这次毕业设计大大提高了我的动手能力，并对整个软件开发的过程有了一个感性的认识，因为我在开发物业管理系统的过程中，无论是系统可行性分析、系统需求分析、系统概要设计、系统设计、系统设计还是系统测试与维护，都要我自己亲自动手负责，而每个设计阶段我都能学到一个新知识。

    当然，在系统的开发过程中，也遇到了很多困难，在总体设计的数据库设计时没有考虑全面，程序制作过程中发现数据表不很合理，又重新修改表的结构，带来了许多不便，深深得体回到了软件工程思想的重要性，流程必须严格执行，才会避免出现这种错误，也明白了各阶段的顺序必要性。

    开发过程中，我力求从软件结构上达到设计与实际工作要求基本一致，以满足用户使用的要求。如模块的划分、功能的安排，都是在自己思考并与其他人讨论后做出的工作。另外考虑到用户操作的简便，我们尽量不让用户重复输入数据库中已经存在的信息，对可选择的部分使用下拉菜单，方便输入。系统的业务报表结算也比较灵活、方便，具有良好的提示信息，这些都给操作员带来很大的方便。

    由于时间比较仓促和开发经验的缺乏，本系统还有很多地方可以完善使之趋向完美化，系统中功能的实现途径很多，我采用的不一定是最佳方法，代码的书写风格也缺乏流畅和精炼。在以后的学习过程中，我将尽量完善代码，弥补这些不足之处。在功能方面，本系统还是有一些欠缺，主要是还没有做到个性化的一面。

这次设计，是对我四年来所学知识的一次严格的检验与总结，是从所学理论到应用实践的一次跨越性的转变。这次设计，一方面，让我认识到了自己知识上的欠缺，和缺乏动手能力；但另一方面也增强了我继续学习的决心和动力，提高了我解决实际问题的能力，可以说我受益非浅。也认识到了自己的不足，在设计功能，技术方面还有很多不足，需要在以后的时间里不断的学习充实自己。

致谢

毕业设计的开发过程，是一个自我锻炼和提高的过程。在此期间，我们的毕设课题小组指导老师给予我大量的指导和帮助，在他的直接领导下我的课程设计稳定有序的进行。对我所开发的仓储管理信息系统，他提出了许多宝贵的意见和建议，使我的开发过程能按进度顺利完成，并且使我在此期间学习进步了许多，不仅掌握了企业管理信息系统的基本开发设计方法，还进一步学习领会了软件开发的方法和思想精髓，真正地体验了一回程序开发人员的工作，这对于我们以后从事软件开发设计有很大的帮助。另外，还有我的同学对我的系统的开发也提出了宝贵的建议，在程序开发和调试中给予了很多帮助，在此一并向他们表示感谢，希望你们在今后的生活中幸福、快乐。

参考文献

[1]邓一凡,余勇,罗云峰等译.JFC Swing标准教材(第二版)[M].北京:电子工业出版社,2005.2

[2]王珊.数据库系统概论[M].高等教育出版社,2004.04

[3]路世昌.现代企业管理原理[M].北京:高等教育出版社,2003.

[4]李东.管理信息系统的理论和应用[M].北京:北京大学出版社,2006.

[5]张毅.企业资源计划（ERP）[M].北京:电子工业出版社,2007.1.

[6]杨翠蓉，等.ERP环境下的仓库管理信息系统设计[J].计算机与现代,2008.3. 95-98

[7]陈炜，JAVA语言程序设计案例教程[M].北京：人民邮电出版社，2005.1

[8]江义华，JAVA完美经典[M].北京：中国铁道出版社，2004.3

[9]吴其庆，JAVA模块设计实例经典[M].北京：北京冶金工业出版社，2004.6

[10]阎宏.JAVA与模式[M].北京:电子工业出版社,2006.10

[11]Marty Hall,Larry Brown 赵学良 译.Servlet与JSP核心编程第2版[M].北京：清华大学出版社，2007.1

[12] Basham,Sierra & Bates.Head First Servlet & JSP(中文版)[M].北京：中国电力出版社，2006.

[13]Sun Microsystems.java-doc文档. http://www.java-doc.com/.2006

附录A 译文

配置管理系统中的概念

至于怎样才算是构成CM系统的，对此还没有普遍接受的定义。例如：假如系统有版本控制功能，它是否就是一个CM系统呢？理想的CM系统是基于以上定义提供所有功能的系统。但是， 实际中的系统只能提供某种程度上实现的版本控制功能、配置识别功能、系统构建功能、系统建模功能，或某种程度上提供CM的意识就被软件工程大家族认为是CM系统了。应注意的是， 现有的CM体系提供只是一种功能的综和而不是一标准的体系。本报告提及15个CM系统，目前至少有40个系统可以为今所用。

这里，有必要将CM系统和CM工具两概念区分一下。CM系统可看作是其支持环境的一部分且以这种形式被售出。譬如，在RATIONAL[14]环境下CM功能成为该环境必不可少的一部分。CM工具可看作是一独立的工具。譬如，版本控制系统（RCS）只是一个工具，因为它可被安装在一个现有环境中。由于这种区分在本文不是那么重要，术语CM系统就被用来表示这两概念。

1.CM以用户为导向的典型情形

在讨论CM体系之前，我们描述了一个简单、典型的、以用户为导向的CM系统来作参考。在此情形下，包含了具有不同职责的人员：负责软件小组的项目经理、负责CM规程和方针的配置经理、负责软件产品开发与维护的软件工程人员、负责验证产品正确性的测试人员、负责确保产品高质量的质量保证经理、使用产品的用户。

  每一角色都有他们的目标和任务。对项目经理来讲，其目标是确保产品在一定的时间框架里得以开发。因此，经理监控开发过程并发现问题，解决出现的问题。这些又必须通过对软件系统的现状形成报告并予以分析以及对系统进行审核才能完成。

  配置经理的目标是确保用来建立、更改及编码测试的规程和方针得以贯彻执行，同时使有关项目的信息容易获得。为了对编码更改形成控制，经理引入对正规请求更改的机制，评估更改的机制[通过更改控制机构（CCB），由它负责批准对软件系统的更改]，和批准更改的机制。经理负责为工程人员创建并宣导任务单，基本上创建项目的框架。同时，经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问题的构件的信息。

    对于软件工程人员，他们的目标是有效地创造出产品。这就意味着工程人员在创建产品、编码测试及支持文档的产生中不必相互间干涉。与此同时，他们能有效地进行沟通与协作。他们利用工具以帮助创建性能一致的软件产品，通过相互通知要求的任务和完成的任务来进行沟通与协调。做出的更改通过将它们进行融合、分散和冲击而得知。产品中的所有元素的演变连同其更改的原因及实际更改的记录都予以保留。工程人员在创建、变更、测试及编码的汇合上有自己的工作范围。在某一点上，编码会形成一个基线，它使得进一步开发得以延续，为其它平行开发得以进行。

    测试的目标是确保产品经过测试达到要求。这里包括产品某一特定版本的测试和对某个产品的某种测试及其结果予以记录。将错误报告给相关人员并通过回归测试进行修补。

质量保证经理的目标是确保产品的高质量。这意味着特定的规程和方针应当完成并得到相关的批准。错误应得到纠正并应对变化的部分进行充分测试。客户投诉应予以跟踪。

  不同的客户使用的产品版本也是不同的。客户总是遵循规则来做变更要求、错误显示及产品改进。理想的CM系统在这种情形下应能够支持所有这些目标、角色和任务。这也意味着这些角色、任务和目标决定了一CM系统要求的功能。本文提出的一些概念就是为了解决这些问题。

2.CM系统的集成

任何CM系统在某种程度上都能与它的环境融合。CM系统可与其它工具并存或完全融合。适合与不同环境方面融合的有：过程、工具组和数据库。过程集成是将CM系统的使用模式（指CM过程）同环境的使用模式（指软件生命周期过程）的结合；工具组的集成是将CM系统安装在环境中使之至少能环境中其它所有工具共存。譬如，在编辑过程中， 每当用户发出“SAVE”命令时，用户就会要求CM功能能建立一新的版本。数据集成指的是CM数据库的逻辑定位——它是否能与现存环境的数据库能做某种方式的合并，或它的数据库是否独立存在的，或它能否利用其它数据库中的信息。所有此类集成都是普通的工具集成和技术的转换问题。但，由于CM将影响到环境中的绝大部分物件并贯穿每一物件生命周期的所有阶段，CM系统的集成势必对环境中的很多工具有重要影响。大多数CM系统能与其它工具共存，有些环境把CM看成其必不可少的一部分。

3.何时启用CM系统

对于在开发和维护产品过程中, 项目组何时启用CM系统是不定的。有些项目组选择在产品经历开发生命周期并准备发到用户地时开始启用。有的选择在项目一开始就将一切置于CM下。二者都有各自的一般费用。譬如，项目组可能基于变更要求的费用上来决定何时启用。如果有许多的手工程序（如：将变更申请表归档、寻求CCB的批准与确认可），项目组会选择在大部分开发完成之后将软件置于CM的控制之下。但如果变更要求程序能在线很快地得到处理，CM将在软件生命周期的早期就被用上。理论上讲，CM在产品的整个生命周期都能派上用场 —— 从创建、开发、产品发放、交付、使用到维护。在理想的情形下，CM能在较少的花费下对此予以支持，由此CM才能在项目中尽可能早地予以应用。

然而，现有的CM系统只关注生命周期的某一特定的阶段，用户因此受到限制。

4.CM的控制水平

很多的程序、方针和工具组合一块来支持CM的应用。它们在对用户的支持和产品的演变予以不同程度控制水平支持。譬如，它们会要求开发人员递交正式的书面的更改请求。配置经理则会建立一个工作区间给软件开发人员。配置经理可从受控库存中抽取所要的文档并将其置于该开发人员的工作区间里。当然，不同的程序、规定和工具事实上允许开发人员也可以通过电子邮件的方式将更改请求通知配置经理及CCB的其他成员。成员之间通过电子邮件予以迅速回应。一经批准，更改请求将被指派给开发人员，他可以直接从库存中抽取相关的文件并作出更改。所有这些无需手工介入。由于CM系统会自动记录所有的登入，更改过程的正式记录就可创建。

前一种情形可被看成对行动具有积极的控制，后者较为松且被动。在前一种情形中由于手工耗费的原因，经常性的更改不予以主张，而后者恰恰相反。这种不同的控制水平在产品生命周期的特定阶段有其适用性。譬如，前者更适合维护而后者适合开发。不管CM系统这么用，它对于用户和产品的演变历史都有一定程度的控制。它将驱动用户的过程并将其加强。现有的CM系统提供或松或紧的控制水平但很少能灵活地允许用户选择控制的种类。

5.过程与产品的区分

CM包括过程和产品。CM过程表示执行CM是所需的一系列工作任务。从根本上讲，过程是一个计划，它定义要做什么、谁来做及如何做。支持这过程是管理的功能。过程模型将组织的方针、程序和软件开发生命周期模型通盘考虑。CM的产品是工程管理任务的结果。CM系统的功能需要为二者予以支持。现有的CM系统提供一些产品及过程的支持，但在同一CM系统中一般不能形成对二者完全支持。

6.CM自动化水平

目前，CM一般是手工和自动程序二者兼而有之。无需任何在线支持来实施CM也是可能的。但这样做的效率很低。我们的目标是将CM中非创造性的部分尽量多地自动化。譬如，书面更改表格和对此回应的监控一般只在组织方针里予以记录，而不能在线获取与加强。

7.CM系统功能

现有的CM系统提供的只是所有不同种类的用户的部分功能。但随时间的推移和用户的需求和环境结构的能力得到更好理解后，这种情况将可能得以改进。以下部分描述的是现有CM系统概念范围。

8.组件的概念

组件的概念是与标明和访问软件产品的组件相关。它们包括下文所描述的库和分布式组件。

9.库

库的概念是配置管理系统的根本。修订控制系统(Revision Control System（RCS）)[15]提供了ASCII码文件库的概念。从效果上来说，库是集中控制的文件库并提供对库中所存储文件的版本控制。任何库中的文件都被视为在确定的配置管理之下。库中的文件是不会变的——它们不能被更改。任何更改被视为创建了一个新版本的文件。文件所有的配置管理信息和文件的内容都存贮在库中。所以，任何配置的管理和控制都与库中的文件相关联。当工作于一个文件时，用户将某个版本的文件导入工作目录，然后开始工作，处理完了，然后将文件导回库中。这样就生成了这个文件的新版本。所以用户不可能导出一个文件并同时在库中修改源文件。

从库的角度来看，导出的文件自动被锁定直到文件重新被导入，一个版本号自动与新版本文件相关联。这样一来，用户可以随时根据特定的版本号来导出任何文件（缺省的是最新的版本）。对最新版本的修改的结果是产生一个新的，顺序递增的版本；而对更老版本的修改的结果是产生一个分支版本。在版本编号策略和使用模式共同作用下，产生了文件版本历史树，用来表示祖先和后代版本。库中不但存储了文件的不同版本，更改的理由，而且存储谁在什么时候替换了某个版本的文件等文件历史信息。请注意，对于每个不同版本文件，不是所有的代码都存储起来，而只是不同版本间实际的差异才存储起来：这称为增量。这种方法有利于节省空间和节省对最新文件版本的访问时间。另外，可以根据状态给文件加上标签，然后基于状态的值进行导出。它们同样也可以根据修订版本号，日期和作者进行导出操作。库总是和文件所在的目录相关联。总而言之，库捕捉配置管理信息并把不同版本的文件存储为不可修改的对象。

10.分布式组件

Sherpa设计管理系统（The Sherpa Design System（DMS））[7]提供一个文件库，其中的文件分散分布在不同的硬件平台上。在逻辑上，库是集中控制的，但在物理上，库中的数据是分布的。Sherpa 设计管理系统自己知道数据的分散分布，并把这个因素考虑到配置管理系统中去，例如，在提供必要的文件格式转换时提供一定的容错能力。这样，对于用户来说，数据的分布是透明的——用户对库进行的任何工作感觉上和所有文件放在自己的本地工作站上一样。一组地理上分散分布的用户可以针对同样配置的文件一起工作。多个文件的副本可以在不同的工作站上存在。Sherpa设计管理系统总是知道最新文件版本的位置。任何对从库中所导出文件的更改会导致所有分散的本地工作站上的副本更新，因为系统知道所有本地副本放置的位置。更新可以是一步一步交互式样地发生，也可以是批处理式地完成。有效的，分散分布的用户能够直接访问集中控制的库。对他们来说，配置管理能力看起来遍布整个异构网络。

11.配置管理系统的未来

图2所示配置管理概念光谱图表示了商用配置管理系统的典型概念。我们预计，随着研究的继续，和不断从这些概念的结合使用中获取经验，光谱图上的许多分支将会互相连接。这意味着，每个配置管理系统最终都可能将提供一个基本的配置管理服务集，从而更好地适应用户需求。但是，即使不考虑是否每个配置管理系统设计者都试图实现这些共同的特征，还有政治和技术方面的因素都会影响未来的软件配置管理系统。（政治层面的因素是指与市场和标准化相关，技术因素则是关乎实现某一特定机制的可行性。）

一个主要的政治因素是关于CASE（计算机辅助软件工程）工具的发展。例如：CASE工具经销商是否应该假设环境经销商会在他们的框架内提供配置管理支持，所以他们自己可以避免在他们的工具中实现配置管理。或者，是否应该由CASE工具开发商在他们的工具中提供配置管理支持。如果CASE经销商合并他们自己的配置管理支持，那么当用户安装不同的CASE工具时，用户将不得不自己解决如何集成不同的CASE工具的问题。同样，从经销商的视角看，他们会真正重复去做那些已经被整个环境框架尝试过的工作吗？

另一方面，如果CASE经销商不把配置管理合并到他们的工具中去，他们能依赖环境集成商提供合适的环境框架，去集成CASE工具并同时提供某种通用的配置管理能力吗？这些问题的答案都是未知的。我们都可以看到，任何一种情况都意味着，对于环境来说，配置管理系统需要一定的标准化。反之亦然。

许多技术、研究方面的问题都影响着配置管理系统的能力，冒出来了如下这些问题：

什么适当的技术可作为配置管理系统的基础？对象命名约定不变的面向的对象数据库技术是最合适的吗？在环境体系结构中软件配置管理是在哪一层？它是否应该作为环境框架中一部分，放在数据库的基础层，还是把配置管理看作一个过程，处于体系结构的较高层？配置管理的机制能否从所有的配置管理功能中分离出来？也就是说，是否有一个标准的配置管理本质部分，能够在任何环境中使用，并支持所有的配置管理功能。存在一个统一的配置管理模型吗？是否可能提供分布式的配置管理支持？在地理上分散的软件开发组能否与本地配置管理和系统集成使用同样的配置管理系统。这是工业界的一个主要难题，尤其是对于国防合同承包商来说。配置管理支持跨软件开发吗？工程师是否能够在主机上开发产品，然后在保持对产品的配置管理控制的同时轻易地将它转移到目标机上去吗？规模是配置管理系统的一个限制性因素吗？配置管理对一百万线产品的支持和对一兆线产品的支持是一样的吗？有可能将配置管理过程中，包括劳力密集型的部分，所有方面都建模，并在配置管理系统中实现它吗？

    对以上这些问题的回答都不是显而易见的。因为很可能要管理的过程有着不同的来源，从配置管理系统经销商，开发环境集成商，研究人员，工具继承商，软件过程建模论坛，还有计算机辅助设计，计算机辅助工程，计算机集成制造等不同的领域。

12.结论

配置管理是对软件产品发展演化进行的管理。从配置管理系统的操作层面上看，配置管理是认证，控制，状态统计，审计，评估，制造，过程管理和团组合作。它是软件工程领域的一部分。它的工作对象是这个领域中产生的过程。这从概念光谱图可以明显地看出来，同样也可以从已有的配置管理系统的数量和它们的能力看出来。本文的光谱图表示的是许多不同的配置管理系统经已实现的概念的一个快照。每个存在的系统的重点都不同，在用户问题——包括角色，集成，控制，自动化层，过程等等，与产品支持，什么时候是开始使用配置管理的最佳时机，系统能提供哪些功能等之间进行竞争和权衡。希望提供这个光谱图能够有助于对配置管理系统能力的理解，并且提供一个配置管理支持工具的通用框架。

附录B 外文文献

Concepts in Configuration Management Systems

As to what constitutes a CM system, there is no universally accepted definition. That is, there is no unified notion of a CM system. For instance, if a system has version control, is it a CM system? Ideally speaking, a CM system is one that provides all functionality based on the definition given above. But practically speaking, any system that provides some form of version control, configuration identification, system structuring, system modeling , and has the intent of providing CM (to some degree) is considered by the software engineering (and sales) community to be a CM system. It should be noted that existing CM systems provide their own combination of functionality rather than a standard set. This report mentions 15 CM systems, yet there are at least 40 CM systems that can be acquired for use today.

It is worthwhile clarifying one minor notion for this paper, the notion of a CM system and a CM tool. A CM system can be considered part of an environment where the CM support is an integral part of the environment and the CM system is sold in that manner as part of a package. For instance, the Rational [14] environment has CM functionality that is an integral part of it. A CM tool can be considered a stand-alone tool. For instance, the Revision Control System(RCS) [15]) is a CM tool since it is intended to be installed into an existing environment. But because the distinction is not important to this paper, the term CM system will be used to represent both notions.

1. A Typical CM User Scenario

Before discussing CM systems, a simple, typical, CM user scenario of an organization is described in order to present a frame of reference. The scenario involves various people with different responsibilities: a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the software engineers who are responsible for developing and maintaining the software product, the tester who validates the correctness of the product, the quality assurance (QA) manager who ensures the high quality of the product, and the customer who uses the product.

Each role comes with its own goals and tasks. For the project manager, the goal is to ensure that the product is developed within a certain time frame. Hence, the manager monitors the progress of development and recognizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system.

The goals of the configuration manager are to ensure that procedures and policies for creating, changing, and testing of code are followed, as well as to make information about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating changes (via a Change Control Board (CCB) that is responsible for approving changes to the software system), and for authorizing changes. The manager creates and disseminates task lists for the engineers and basically creates the project context. Also, the manager collects statistics about components in the software system, such as information determining which components in the system are problematic.

For the software engineers, the goal is to work effectively in creating the product. This means engineers do not unnecessarily interfere with each other in the creation and testing of code and in the production of supporting documents. But, at the same time, they communicate and coordinate

Efficiently . They use tools that help build a consistent software product and they communicate and coordinate by notifying one another about tasks required and tasks completed. Changes are propagated across each other’s work by merging them and resolving and conflicts. A history is kept of the evolution of all components in the product along with a log with reasons for changes and a record of what actually changed. The engineers have their own work area for creating, changing, testing, and integrating code. At a certain point, the code is made into a baseline from which further development continues and from which parallel development for variants of other target machines emerges.

The tester’s goal is to make sure all the product is tested and found satisfactory. This involves testing a particular version of the product and keeping a record of which tests apply to which version of the product along with the results of the tests. Any errors are reported back to the appropriate people and fixes are put through regression testing.

The QA manager’s goal is to ensure the high quality of the product. This means that certain procedures and policies must be fulfilled with the appropriate approval. Bugs must be fixed and fixes propagated to the appropriate variants of the product with the correct amount of testing applied to each variant. Customer complaints about the product must be followed up.

The customers use the product — most likely, different customers use different versions and variants of it. Customers follow certain procedures for requesting changes and for indicating bugs and improvements for the product. Ideally, a CM system suited to this scenario should support all these goals, roles and tasks. That implies, these roles, tasks and goals determine the functionality required of a CM system. This paper presents some concepts that attempt to address these.

2. Integration of a CM System

Any CM system has some notion of integration level with its environment. A CM system can co-exist with other tools or be fully integrated. Integration pertains to various aspects of the environment: process, toolset, and database. Process integration means incorporating the usage pattern of the CM system (which makes up the CM process) with the usage pattern of the environment (which pertains to the software lifecycle process). Toolset integration means installing the CM system into the environment so that it can at least co-exist with all the other tools in that environment. For instance, the user would like to invoke CM functions to create a new version every time the "save" command is issued while in the editor. Database integration concerns the (logical) positioning of the CM database — whether it is combined in some way with the extant environment’s database, or whether its database is a separate entity, and whether it makes use of information in other databases. All these kinds of integration are general tool integration and technology transition issues. But since CM is intended to affect most objects in an environment and throughout all phases of the lifecycle of an object, integration of a CM system is bound to have significant impacts on many of the tools in the environment. Most CM systems co-exist with the other tools, and some environments have CM as an inherent part of themselves.

3. When to Start Using a CM System

It varies as to when project teams start using a CM system on the products they are developing and maintaining. Some teams choose to do so when the product has been through its development lifecycle and is ready for shipment to the customer site. On the other hand, others choose to put everything under CM from the initiation of a project. Both choices have their own overheads. For instance, a team may make the choice based on the overheads associated with asking for a change. That is, if there are a number of manual procedures (such as filing a change request form, seeking CCB approval and getting acknowledgment), a team opts for placing the software under CM control once the major part of development is complete. But if the change request procedure can be done on-line with little time and effort expended by the team, CM will be used at an earlier part of the lifecycle. In theory, CM is applicable throughout the product’s lifetime—from creation, development, product release, customer delivery, customer use, through maintenance. Ideally, CM systems should support this with minimum overhead possible, thereby allowing CM to be applied as early as possible on a project. Existing CM systems, however, tend to focus mostly on a particular phase of the lifecycle, so users are limited by that functionality.

4. Levels of CM Control

A number of procedures, policies and tools combine to assist in carrying out CM. They will provide varying degrees of control over the users and evolution of the product. For instance, they may require an engineer to submit a formal, written change request. This is followed by a CCB evaluation and authorization of a change. The configuration manager then sets up a workplace for the software engineer. Particular files are extracted by the configuration manager from a guarded repository and placed in that workspace solely for that engineer. On the other hand, different procedures, policies and tools may actually allow the engineers to electronically mail their request for changes to the configuration manager and other members of the CCB. The members mail their responses immediately. Upon approval, the change request is assigned to an engineer who extracts the pertinent files directly from a repository and makes the changes. All this is done without any manual intervention. And since the CM system would automatically log all accesses, an official record of the change process is created.

The first scenario can be considered to have tight, active control over any action, but the latter scenario has loose, passive control over actions. Frequent changes are discouraged in the first scenario because of all the manual overhead, whereas in the latter scenario frequent change is encouraged since it is easy to do. These different levels of control may be more appropriate at certain phases of the product’s lifecycle, for example, the first one is suitable for maintenance but the second for development. Whatever CM system is used, it will have a certain level of control over the user and the timeliness of the product’s evolution. It will either drive the user’s process, enforce it, or a bit of both. Existing CM systems provide their own level of control which is either loose or tight and few are flexible enough to allow the user to pick the kind of control.

5. Distinguishing Between Process and Product

CM involves a process and a product. A CM process represents the sequence of tasks needed to carry out CM. Essentially , the process is a plan that defines what needs to be done, who does it and how it is be carried out. Supporting the process is a management function. The process model takes into account policies and procedures of the organization and its software development lifecycle model. The CM product is the result of the process that is an engineering task. A CM system needs to provide functionality for both aspects. Existing systems provide some product and process support, but generally not comprehensive support for both in the same CM system.

6 .Amount of CM Automation

At present, CM is generally a combination of manual and automated procedures. It is possible to perform CM without any kind of on-line assistance. But that is recognized as being inefficient. The goal is to automate as many as possible of the non-creative parts of CM. For instance, written change request forms and the protocol of responding to them are generally documented in an organization’s policy folder rather than captured and enforced on-line. Yet there are systems that can provide for completely automated change requests. Each CM system automates some function of CM to a different degree. And users need to supplement automated procedures with manual ones when procedures are not supported on-line.

7. CM System Functionality

Existing CM systems provide some of the required functionality for CM, but no single system provides all the functionality required by all the kinds of users. This is likely to improve though, with time, as the needs of users and the capabilities of environment architectures are better understood. The next section highlights the spectrum of concepts in existing CM systems.

8 .Component Concepts

Component concepts deal with identifying and accessing components of a software product. They are the repository and distributed component and are described below.

9. Repository

The notion of a repository is fundamental to a CM system. The Revision Control System (RCS) [15] provides the notion of a repository for ASCII files. In effect, the repository is a centralized library of files and provides version control for the files in the repository. Any file, while in the repository, is considered to be under a form of CM. The files in the repository are immutable — they cannot be changed. Making a change means creating a new version of a file. All the CM information about files and the content of the files are kept in the repository. Hence, any CM controls pertain to files in the repository. To work on a file, users check out a particular version of it into their working directory, perform any work on it, and, at the their discretion, check it back into the repository. This creates a new version of that file. So that users cannot simultaneously check out the same file and change it, the file checked out is automatically locked (from the repository’s perspective) until checked back in. A version number is automatically associated with a new version; consequently, users can check out any file with a particular version number at any time although the default is the most recent version. Changes to the most recent version result in a new, sequential version whereas changes to older versions result in a variant version. Together, the version numbering scheme and usage pattern result in a version history tree for the file, indicating predecessor/successor versions. The repository stores file history information that includes the different versions of the files, the reason for a change, who replaced that version of the file and when. Note that the complete code for the different versions is not stored. Rather, only the actual difference between each version is stored; this is known as the delta. This assists in space savings and access time to the most recent version of a file. Files can be tagged with a state and checked out based on that state’s value. They can also be checked out based on a revision number, date and author. The repository is generally associated with the directory in which the files exist. In sum, a repository captures CM information and stores versions of files as immutable objects.

10. Distributed Component

The Sherpa Design Management System (DMS) [7] provides a repository for files distributed on different hardware platforms. The repository is logically centralized, but the data from the repository can be physically distributed. Sherpa DMS is aware of the distribution and carries out its CM taking that into account, for example, by providing some fault tolerance facilities along with the necessary translations of file formats. So, to the users, the distribution is transparent — users carry out their work on the repository as though all the files were located on their own workstations. A team of users geographically dispersed can be working on the same configuration of files. Multiple copies of files can exist on different workstations. Sherpa DMS is aware of the location of the most recent version of a file. Any changes to files in the repository can result in the local copy on the distributed workstations being updated since the system knows where all the local copies are. Updates can occur interactively or be done in batch mode. In effect, distributed users have access to a centralized repository, and to them the CM facilities seem to span the network of heterogeneous workstations.

11. The Future of CM Systems

The spectrum of concepts in Figure 2 represents typical concepts in commercially-used CM systems. It is envisioned that as research continues, and experience in using and combining the concepts is gained, the many "arms" of the spectrum will join. This means that there is probably a set of fundamental CM services that each CM system will eventually attain to better suit user requirements. But regardless of whether every CM system designer is trying to implement the same features, there are political and technical issues that affect the future of CM systems. (Political issues relate to marketing and standardization; technical issues concern the feasibility of implementing certain mechanisms.)

A major political issue concerns the evolution of Computer Aided Software Engineering (CASE) tools. For instance, should CASE tool vendors bypass implementing CM within their tools and assume that environment vendors will provide the CM support in their frameworks? Or should CASE tools builders provide CM support in their tools? If CASE vendors incorporate their own CM support, users will have to solve the problem of integrating different CM systems when they install their different CASE tools. Also, from the vendors’ viewpoint, will they essentially be duplicating much of the work that has already been attempted for environment frameworks?

On the other hand, if CASE vendors do not incorporate CM into their tools, can they rely on environment architects to provide a suitable framework to integrate CASE tools and simultaneously provide some sort of global CM capability? The answers to these questions are not known. In any case, there is the implication that some kind of standardization would probably be needed for CM systems in relation to environments, or vice versa.

Many technical, research issues affect the capabilities of CM systems. Questions such as the following arise. What is the appropriate technology on which to base a CM system? Is an object-oriented database with persistency notions for objects the most suitable? In what layer of an environment’s architecture does CM fit? Should it be at the base level in the database, making it an integral part of an environment framework? Or is it all a matter of specifying CM as a process at a higher level in the architecture? Can the mechanisms for CM be separated from all the CM functionality, that is, are there "standard" CM primitives that could be used in any environment to support all the CM functionality? Is there a unified CM model? Is it possible to provide distributed CM support? Can geographically dispersed software teams use the same CM system for local CM and for system integration? This is a major problem in industry, particularly for Department of Defense contractors. Is it possible to support cross-development of software? Can engineers developing a product on a host machine easily move it to the target machine while still maintaining CM control over the product? Is scale a limiting factor for CM systems? Is the CM support for a million line product the same as that for a 100 million line product? Is it possible to model all aspects of the CM process, including the people-intensive parts, and implement those in a CM system?

Answers to the above questions are not yet obvious. It is likely that progress will come from various sources—from CM system vendors, environment architects and researchers, tool integrators, the software process modeling forum, and from the computer-aided design/engineering, computer-integrated manufacturing worlds.

12. Conclusions

CM is management of the evolution of a software product. At the operational level for CM systems, CM is identification, control, status accounting, audit, review, manufacture, process management and team work. It is an area in software engineering environments where progress has been made. That is evident from the spectrum of concepts, as well as from the number of existing CM systems and their capabilities. The spectrum presented in this paper represents a snapshot of many concepts implemented by various CM systems. Each system addresses differently, the user issues — roles, integration, control, automation level, process versus product support, when is the best time to start using CM and what functionality is provided by the system. It is hoped that presenting the spectrum may aid in understanding the capabilities of CM systems and in providing a common framework for discussing CM tool support.