电子客票系统毕业论文 本文简介：
电子客票系统毕业论文第一章电子客票系统概论从实际方面来看，随着网络技术的日益普及，特别是现阶段我国机票预定和销售系统相对比较落后，还处在纸质机票阶段，对机票预定程序先对繁琐。去年4月，作为“简化商务”的首个试点地区，国际航协与中国民航信息网络有限公司(下称“中国航信”)签署了“简化商务”的战略合作协
电子客票系统毕业论文 本文内容：
电子客票系统毕业论文
第一章
电子客票系统概论
从实际方面来看，随着网络技术的日益普及，特别是现阶段我国机票预定和销售系统相对比较落后，还处在纸质机票阶段，对机票预定程序先对繁琐。去年4月，作为“简化商务”的首个试点地区，国际航协与中国民航信息网络有限公司(下称“中国航信”)签署了“简化商务”的战略合作协议，目标是于2007年底前,在国内实行100%BSP电子客票。
1.1
系统开发背景
自20世纪70年代以来，数据库技术得到迅速发展，目前世界上已经有数百万个数据库系统在运行，其应用已经深入到社会生活的各个领域。21世纪以来，随着网络技术的逐渐完善，WEB已经成为Internet中最流行、最主要的信息交流方式。计算机技术的飞速发展也促进了软件开发技术的深刻变化。为摆脱软件危机，软件工程学——从60年代末期开始迅速发展起来，现在已成为计算机科学技术的一个重要分支。20世纪90年代以来，软件工程不仅从方法论的角度为管理人员和开发人员提供可见的结构和有序的思考，而且大量的成功软件总结出的设计经验，使软件开发人员可以充分利用设计模式、框架和部件等。
ASP.NET是Microsoft
公司动态服务器页面（Active
Server
Pages）的最新版本，用于为万维网站点或企业的内部网创建动态的、交互的HTML页面。ASP.NET
是一种建立动态Web应用程序的技术。它是.NET
框架的一部分，您可以使用任何.NET兼容的语言来编写ASP.NET应用程序。
使用Visual
Basic
.NET，
C#，
J#，
ASP.NET
页面(Web
Forms)
进行编译可以提供比脚本语言更出色的性能表现。Web
Forms
允许您在网页基础上建立强大的窗体。当建立页面时，
您可以使用ASP.NET
服务端控件来建立常用的UI元素，并对它们编程来完成一般的任务。这些控件允许您使用内建可重用的组件和自定义组件来快速建立Web
Form，使代码简单化。
ASP.NET
提供了一种编程模型和结构，对比原来的Web技术来说，它能更快速、容易地建立灵活、安全和稳定的应用程序。??Visual
Studio?.NET
提供了若干项目模板，您可以使用它们来开始开发分布式应用程序。企业级模板定义分布式应用程序的初始结构，并且还提供应用程序设计方面的结构性和技术性指导。除定义企业级模板外，还可以创建自定义模板，供开发人员在小组环境中使用。
1.2
系统简介
1.2.1
系统产生的背景
从技术方面来看，Microsoft
公司推出的ASP.NET作为新一代的网络开发工具，它作为整个.NET
Framework的一部分，能够开发功能强大的、安全的Web应用程序。Visual
Studio
是一套完整的工具，用于生成桌面和基于团队的企业级
Web
应用程序。除了生成高性能的桌面应用程序外，还可以使用
Visual
Studio
基于组件的强大开发工具和其他技术，简化基于团队的企业级解决方案的设计、开发和部署。在Microsoft
Visual
Studio
.NET
2003开发环境下，学习其相关技术，特别是掌握访问数据库的ADO.NET技术，并在开发高校教师工作量统计管理系统中得以应用。
1.2.2
系统开发的意义
以东航为例，2005年东航共销售电子客票325万张，如果以每张电子客票节约10元的使用成本计算，仅此一项就为东航节约了3250万元。
资料显示，传统的纸质机票要经历印刷、销售、运输、存档等环节，除销售渠道建设和维护成本外，每张机票大约花费航空公司人民币50元-60元的成本，而电子客票的成本却只在人民币10元左右，如此大的降低成本空间自然让航空公司垂涎不已。网上售票系统可以为此提供支持，航空乘客在网上查询、预定、支付后，在机场进出港系统确认了其行程、姓名等基本信息后，仅凭一张身份证就可办理一整套登机手续，降低了销售成本。
1.3
系统的特点及实现目标
1.3.1
系统的特点
在此系统的运用中，基于Web基础之上，这不仅是一个很好的内容载体，而且可以随时随地访问、随时随地的预定。此系统有以下基本特点：
1．系统用户的登陆、注册和用户信息的修改。
2．用户预定的增添和退订。
3．管理员的增添、删除和密码修改。
4．管理员对客机信息的增添、修改、删除，对航线信息的增添、修改、删除，对可预定的航班的增添。
1.3.2
系统的实现目标
基于Web的电子客票系统设计的基本出发点在于：用户对机票的预订、方便用户在线浏览对自己历史订票信息、用户远程对其信息的修改：
·要求可以登陆系统的用户可以查询所有自己订票记录。
·要求管理员统一管理信息，包括对信息的编辑与添加。
·要求用用户可以自主注册修改自己的用户信息。
系统最基本的功能包括：系统用户的登陆、注册和用户信息的修改，用户预定的增添和退订，管理员的增添、删除和密码修改，管理员对客机信息的增添、修改、删除，对航线信息的增添、修改、删除，对可预定的航班的增添。
1.4
可行性分析
开发本系统是为了提高机票预定的效率，减少错误的发生。使用户网络触及之处方便的预定和查询航班信息，本系统查询方便，而且数据保存安全完整。
·技术可行性 使用现有Visual
Basic.NET网络编程技术、SQL
Server2000数据库开发管理技术的成熟，使我们可以用SQL
Server2000作为数据库开发平台，Visual
Basic.NET作为前台界面设计和编程语言平台。
·经济可行性 开发该系统，所需经济成本不高，耗费的人力物力都很低；且系统开发实现后，其对所需运行环境的要求也很低。可以大大降低机票的销售成本和用户登机程序。
·操作可行性 在系统运行的登陆界面上提供了详细的操作帮助，使用户可以在短时间内熟练的掌握此系统的操作。
由于以上这些原因可以得知这个电子客票系统，有很强的可行性。
本系统的系统流程图如图1.1和图1.2所示：
查询航班
用户登录
可选择航班信息
航班数据库
选择要预定的航班
用户信息
预定机票信息显示客户信息填写界面
网上支付
机票预定数据库
图1.1
机票预定流程图客户信息
查询客户预定情况
机票预定数据库
客户预定机票情况
核对航班信息
发放登机牌
数据更新
机票预定数据库
报销凭证
图1.2
登机流程图
第二章
相关理论与关键技术介绍
本章介绍了开发本系统所用到的理论和关键技术，包括软件工程、HTML技术、ASP.NET技术，Web数据库技术，这些是开发程序系统不可缺少的理论与技术，下面做详细介绍。
2.1
软件工程
软件工程是一门关于如何构建更加有效，实用，高质量的软件的技术。它涉及到程序设计语言，数据库，软件开发工具，系统平台标准，设计模式等方面。
21世纪是信息社会高速发展的世纪，软件作为信息技术的核心起着至关重要的作用。面对计算机日益广泛的应用需求，研究如何更快、更好、更经济地开发出相应的软件，是软件开发技术及软件工程师所面临的问题。
计算机技术的飞速发展也促进了软件开发技术的深刻变化。为摆脱软件危机，软件工程学——从60年代末期开始迅速发展起来，现在已成为计算机科学技术的一个重要分支。20世纪90年代以来，软件工程不仅从方法论的角度为管理人员和开发人员提供可见的结构和有序的思考，而且大量的成功软件总结出的设计经验，使软件开发人员可以充分利用设计模式、框架和部件等。
软件工程应用于多个方面。比如电子邮件，嵌入式系统，人机界面，办公套件，操作系统编译器数据库，游戏，互联网它应用于各个行业，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。
软件工程是面向软件从业人员的。它存在于各种应用中，存在于软件开发的各个方面。而程序设计通常指程序的编码，它是软件开发的一个阶段。力图对软件项目的各个方面做出指导，从软件的可行性分析直到软件完成以后的维护工作。软件工程认为软件开发与各种市场活动密切相关。软件生命周期的各个阶段可分为：
1．问题定义:
确定系统的基本功能
2．可行性研究:
确定系统是否能够实现及是否值得实现
3．需求分析:
确定系统必须完成的各种功能
4．总体设计:
确定如何实现软件
5．详细设计:
详细设计实现系统
6．编码和单元测试:
写出正确的容易理解和维护的程序模块
7．综合测试：通过各种类型的测试及调试使软件达到预定的要求
8．软件维护：通过各种必要的维护活动使系统持久地满足用户需要
正是基于此思想，本系统开发实际可行的软件，方便教师工作量相关信息的管理。
2.2
HTML简介
HTML英语意思是：Hypertext
Marked
Language，即超文本标记语言,是一种用来制作超文本文档的简单标记语言。它是网页构成的最基本元素，通过HTML精简却强大的文件设置功能可以轻松地设计出多姿多彩的超文本文件，通过各种浏览器浏览HTML文件的内容。用HTML编写的超文本文档称为HTML文档，它能独立于各种操作系统平台（如UNIX，WINDOWS等）。自1990年以来HTML就一直被用作World
Wide
Web
的信息表示语言，用于描述Homepage的格式设计和它与WWW上其它Homepage
的连结信息。使用HTML语言描述的文件，需要通过WWW浏览器显示出效果。
HTML是纯文本类型的语言，使用HTML编写的网页文件也是标准的纯文本文件，可以用任何文本编辑器，例Windows的“记事本”程序打开它以查看其中的HTML源代码；也可以在浏览器打开网页时，通过相应的“查看/源文件”命令查看网页中的HTML代码。
HTML文件可以直接由浏览器解释执行，无需编译，当用浏览器打开网页时，浏览器读取网页中的HTML代码，分析其语法结构，然后根据解释的结果显示网页内容，正是因为如此，网页显示的速度同网页代码的质量有很大关系！其缺点是：它把结构和显示部分混在一起，给浏览器太大的解释灵活性。
2.3
ASP.NET技术
ASP.NET是Microsoft
公司动态服务器页面（Active
Server
Pages）的最新版本，用于为万维网站点或企业的内部网创建动态的、交互的HTML页面。ASP.NET
是一种建立动态Web应用程序的技术。它是.NET
框架的一部分，您可以使用任何.NET兼容的语言来编写ASP.NET应用程序。
2.3.1
ASP.NET的功能和特点
使用Visual
Basic
.NET，
C#，
J#，
ASP.NET
页面(Web
Forms)
进行编译可以提供比脚本语言更出色的性能表现。Web
Forms
允许您在网页基础上建立强大的窗体。当建立页面时，
您可以使用ASP.NET
服务端控件来建立常用的UI元素，并对它们编程来完成一般的任务。这些控件允许您使用内建可重用的组件和自定义组件来快速建立Web
Form，使代码简单化。ASP.NET
提供了一种编程模型和结构，对比原来的Web技术来说，它能更快速、容易地建立灵活、安全和稳定的应用程序。??Visual
Studio?.NET
提供了若干项目模板，您可以使用它们来开始开发分布式应用程序
此外，ASP.NET还改进了配置、伸缩性、安全性和可靠性，对各种不同的浏览器提供了更好的支持。
2.3.2
ASP.NET的工作原理
ASP.NET
是一种编译型的编程框架,是基于.NET框架的,是第一次被浏览执行时,
ASP.NET原程序会被相应的编译器编译成MS中间语言(MSIL)并存储下来,然后送到CLR(公共语言运行时)内被JIT编译器编译成机器码并执行,在执行的过程中,利用.NET的基类定义一个特殊的ASP.NET
Page对象,该对象能生成HTML流,然后将HTML流返回到IIS,再从IIS返回到客户端。当再次被浏览时，只要原有的ASP.NET源程序未发生改变，JIT编译器就会直接将存储的MSIL语言编译执行。由于上述工作原理，第一次被浏览时ASP.NET程序的运行速度略慢于ASP程序被解释执行的速度，但总体上ASP.NET程序的运行速度要快于ASP程序运行速度。
2.3.3
ASP.NET的开发工具
ASP.NET
提供了一种编程模型和结构，对比原来的Web技术来说，它能更快速、容易地建立灵活、安全和稳定的应用程序。??Visual
Studio?.NET
提供了若干项目模板，您可以使用它们来开始开发分布式应用程序。企业级模板定义分布式应用程序的初始结构，并且还提供应用程序设计方面的结构性和技术性指导。除预定义企业级模板外，还可以创建自定义模板，供开发人员在小组环境中使用。
2.3.4
ASP.NET的运行环境
·Windows
2000/XP
(Windows
2000系列需要安装Service
Pack
2.0)。
·IIS
5.0
(Internet
信息服务管理器
5.0)。
·.NET
Framework
SDK
（.NET框架开发工具包）。
·MDAC
2.7（Microsoft
数据访问组件2.7）。
·客户端只要是普通的浏览器即可，如Internet
Explorer
5.0
或更高的版本。
2.4
WEB数据库技术
2.4.1
WEB数据库应用及结构
数据库与用户可使用的Web应用程序相集成的能力，使数据库变成了Web
数据库。Web
应用程序属n层体系结构，即常说的分布式体系结构。其典型的结构模型：
·表示层主要用于客户机处理信息表达和接收用户的输入数据。在表示层中主要通过Web
浏览器向用户呈现数据。
·业务逻辑层负责实现Web应用的具体服务功能，主要由Web表单和相关服务（如组件服务和XML
Web服务等）组成。业务逻辑层在硬件上需要相关的一台或多台服务器支持。
·数据层是存放数据的地方，数据层中可能包含一个或多个数据服务器（如
SQL
Server
和Oracle
等）。数据库服务软件一般安装在应用服务器或专用的数据服务器上。
DataSet类是ADO.NET中一个非常重要的核心成员，它是数据库中的数据在本地计算机中映射成的缓存。对DataSet的任何操作，都是在计算机缓存中完成的。
2.4.2数据库访问
ADO.NET是.net
Framework
SDK中用以操作数据库的类库的总称。ADO.NET是.NET应用程序的数据访问模型，它能够访问关系型数据库系统SQL
Sever
7.0
(及其后续版本)及很多其他已经配备了
OLE
DB
供应器的数据源。而DataSet类则是ADO.NET中最核心的成员之一，也是各种开发基于.Net平台程序语言开发数据库应用程序最常接触的类。之所以DataSet类在ADO.NET中具有特殊的地位，是因为DataSet在ADO.NET实现从数据库抽取数据中起到关键作用，在从数据库完成数据抽取后，DataSet就是数据的存放地，它是各种数据源中的数据在计算机内存中映射成的缓存，所以有时说DataSet可以看成是一个数据容器。同时它在客户端实现读取、更新数据库等过程中起到了中间部件的作用（DataReader只能检索数据库中的数据）。
各种.Net平台开发语言开发数据库应用程序，一般并不直接对数据库操作（直接在程序中调用存储过程等除外），而是先完成数据连接和通过数据适配器填充DataSet对象，然后客户端再通过读取DataSet来获得需要的数据，同样更新数据库中数据，也是首先更新DataSet，然后再通过DataSet来更新数据库中对应的数据的。可见了解、掌握ADO.NET，首先必须了解、掌握DataSet。DataSet主要有三个特性：
1.
独立性。DataSet独立于各种数据源。微软公司在推出DataSet时就考虑到各种数据源的多样性、复杂性。在.Net中，无论什么类型数据源，它都会提供一致的关系编程模型，而这就是DataSet。
2.
离线（断开）和连接。DataSet既可以以离线方式，也可以以实时连接来操作数据库中的数据。这一点有点像ADO中的RecordSet。
3.
DataSet对象是一个可以用XML形式表示的数据视图，是一种数据关系视图。
DataReader
对象用来读取数据库中的数据，可以用Command
对象ExecuteReader()方法来创建DataReader
对象。
本系统采用SQL
Server
2000，作为数据库工具。
第三章
电子客票系统需求分析
典子客票得以推广，在于它显而易见的低成本。传统的纸质机票要经历印刷、销售、运输、存档等环节，除销售渠道建设和维护成本外，每张机票大约花费航空公司人民币50元~60元的成本，而电子客票的成本却只在人民币10元左右，如此大的降低成本空间自然让航空公司垂涎不已。以东航为例，2005年东航共销售电子客票325万张，如果以每张电子客票节约10元的使用成本计算，仅此一项就为东航节约了3250万元。在美国，廉价航空公司得以“廉价”的一个重要原因，就在于它们最大限度地节约了销售成本。以廉价航空公司美西南航空为例，它的“直销”比例高达100%；而目前，我国航空公司的“直销”比例仅占到10%左右，东航2005年的电子客票销售达到15个亿，但也只占整个机票销售的5%。
资料显示，传统的纸质机票要经历印刷、销售、运输、存档等环节，除销售渠道建设和维护成本外，每张机票大约花费航空公司人民币50元-60元的成本，而电子客票的成本却只在人民币10元左右，如此大的降低成本空间自然让航空公司垂涎不已。网上售票系统可以为此提供支持，航空乘客在网上查询、预定、支付后，在机场进出港系统确认了其行程、姓名等基本信息后，仅凭一张身份证就可办理一整套登机手续，降低了销售成本。
3.1系统的功能需求
可登陆用户包括系统管理员、一般管理员、一般用户。系统的管理员可对系统进行日常的信息管理工作，通过对航班和客票信息的编辑实现对信息的管理，和用户登机。一般管理员只可以编辑航班信息或对用户进行登机管理。一般用户可以通过网络对自己预定和管理自己个人信息和预订信息。一般用户对航班信息进行浏览和预订，而不可以进行其他的操作。便于查询是本系统的又一大特点，所有可登陆本系统的用户都可以执行。
1．
一般用户从数据库中利用起始地和到达查询出航班信息。
2．
系统根据用户注册时的资料把订票信息存入数据库。
3．
管理员信息管理：系统的维护：数据库的管理，数据的编辑，数据的备份和恢复等等。登机管理：对用户登机进行管理。
功能层次图如图3.1所示：
功能层次图
电子客票系统
一般用户
系统管理
用户登陆
用户注册
用户预定
用户退订
客机信息管理
信息修改
航班信息管理
管理员管理
客机信息增添
客机信息修改
客机信息删除
航班信息增添
登机管理
航班信息修改
航班信息
删除
客户登机
查询
客户登机
增添管理员
修改密码
图3.1
系统层次图
3.2开发与运行环境的选择
3.2.1软件要求
从Web
应用程序的典型结构可以知道，运行Web
应用程序至少需要Web浏览器、Web
服务器、应用服务器（操作系统）、数据库服务器。而编写Web
应用程序需要一定技术支持和相关集成开发工具。因为用的是Microsoft
Windows操作系统和SQL
Server
2000数据库，所以本系统用的开发软件如下：
·Web浏览器：Internet
Explorer
5.0
或以上。
·Web服务器：IIS
5.0
或以上。
·应用服务器：Windows
2000/XP。
·
数据库服务器：SQL
Server
2000（必须安装SQL
Server
2000的Windows和SQL
Server
混合验证模式）。
·技术支持：Microsoft.NET
Framework
SDK。
·编程方式：ASP.NET和Visual
Basic.NET
2003。
3.2.2硬件要求
Web
应用程序虽然运行在多台客户机和至少一台服务器组成的网络上，但在开发阶段，我们可以把一台计算机作为客户机又作为服务器使用，开发完成后再把Web
应用程序迁移到网络中。
·CPU：PentiumⅢ
450MH以上。推荐使用PentiumⅢ，600MH以上处理器。
·内存：对Window2000
Professional要求在96MB以上，对Windows2000
Server要求在192MB以上。推荐：Professional版使用128MB以上、Server版使用256MB以上内存。
可用硬盘空间：系统驱动器至少需要500MB，安装驱动器为至少需要2.5GB。
3.2.3开发系统硬件配置
CPU：
AMD2000+
内存：
512M
硬盘：
120GB
分辨率：1024*768
3.3数据流图及其描述
根据上述的功能需求，我们画出了数据流图。数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理情况。
系统的数据流图描述如图
3.2和图3.3所示：
图3.2
机票预数据流图
图3.3
登机处理数据流图
3.4状态转换图
根据上述的功能需求和我们画出了的数据流图。画出系统状态转换图。状态转换图通过描绘系统的状态及引起的系统状态转换的事件，来表示系统的行为。系统的状态转换图描述如图
3.4所示：
图3.4
系统状态转换图
3.5数据字典
在系统的顶层数据流图包含的操作如下数据字典所示：
名称：航班信息
位置：D1
定义：航班号+机型+出发城市+到达城市+出发时间+到达时间+客机编号+经济舱价格+商务舱价格+头等舱价格。
说明：查找的主键是航班编号。
名称：客户预定信息
位置：D2
定义：订票编号+客户编号+客户姓名+证件类型+证件号码+航线编号+出发城市+到达城市+到达日期+舱位类型+舱位价格+是否结算+是否登机。
说明：客户订票信息的标识，主键为定票编号。
名称：客户信息
位置：用户登录和客户信息输入
定义：客户编号+用户名+客户姓名+证件类型+证件号码+联系电话+手机号码+传真
+电子邮箱+工作单位+通信地址+邮政编码+登录密码。
说明：这是客户登录和订票时的唯一标识，用户名是客户登录的唯一标识，主键是客户编号。
3.6
E-R图
3.6.1系统E-R图
系统E-R图如图3.5所示：
航班表
所属
航空公司
用户
订票信息
订票
预订
航班时刻信息
图3.5
系统E-R图
3.6.2各实体属性
航班表：航班号、机型、航空公司、出发地、目的地、出发时间、到达时间、运行里程、头等舱客售票数、商务舱客售票数、经济舱客售票数。
航空公司：航空公司编号、航空公司名称。
用户：用户编号、用户名、密码、邮箱地址。
订票信息：航班号、用户编号、客户姓名、客户身份证号码、机舱等级。
各等级机舱收费标准：航班号、机舱等级、票价。
3.6.3各实体间的约束
航班表——航空公司：m：1
航班表——订票信息：1：m
用户——订票信息：1：m
航班表——航班价格表：1：1
航班价格表——订票信息：1：m
第四章
总体设计
总体设计的基本目的就是要怎么做才可以实现这个系统。因此，总体设计又称为概要设计或初步设计。通过这个阶段的工作,设计人员将划分出组成系统的物理元素总体设计的另一项任务是确定软件结构,即确定系统中的每一个程序由哪些模块组成以及模块和模块之间的关系.通过这个阶段的工作将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级，这些黑盒子里的具体内容将在以后仔细设计。总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互之间的关系。
总体设计工程通常有两个主要阶段组成：
系统设计，确定系统的具体实现方案；结构设计确定软件结构，也就是要确定系统中每个程序拥有哪些模块组成的，以及这些模块之间的关系。在详细设计之前进行总体设计可以站在全局的高度上，花较少的成本，从中选出最佳方案和最合理的软件结构，从而用较低的成本开发出高质量的软件系统。
数据库的设计，确定所建立的数据库应该包含那些信息、结构和体系，以便服务系统的正常运行，为系统操作信息做准备。
4.1系统设计
4.1.1
系统设计的目标
我们所设计的飞机电子客票系统主要目的在于网上售票系统可以为此提供支持，航空乘客在网上查询、预定、支付后，在机场进出港系统确认了其行程、姓名等基本信息后，仅凭一张身份证就可办理一整套登机手续，降低了销售成本；使乘客更为快捷、安全的预定和乘机。从这方面考虑，该系统在设计过程中，应实现以下目标：
·能安全、准确地实现对客机航班信息的录入修改。
·能快捷、稳定地是用户对航班的预订。
·能简单、全面的对自己的订票信息进行查询。
4.1.2
系统结构分析
根据在需求分析阶段所制定出的该系统所应该具有的功能和航空订票的特点，经过系统模块化的分析设计将系统分为：一般用户模块、管理员管理模块。根据模块不同，它的具体功能也不同。
4.1.3各子模块功能详细说明
·一般用户模块：用户登录系统用户输入账号和密码通过身份验证才可以进入系统，用户注册只有注册用户才能准许登陆，用户预定用户通过航班搜索进行预定，用户退订用户可以查询自己预定的信息和进行退订，信息修改用户对自己的注册信息进行修改。
·管理员模块：客机管理对客机信息的增添、修改、删除，航班管理对航班信息的增添、修改、删除，登机管理客户登记的查询和登机操作，管理员管理管理员的增添和管理员密码修改。
系统管理员在这个系统中的权限最大，主要从事于对系统的授权维护。
4.2数据库的设计
数据库是整个系统数据存储以及对数据操作的最终媒介，在一个信息管理系统中占有非常重要的地位，数据库结构设计的好坏将直接对应用系统的效率以及实现的效果产生影响。合理的数据库结构设计可以提高数据存储效率，保证数据的完整和一致，并有利于程序的实现。开发一个基于Web
的数据库，最重要的一步就是后台数据库的结构设计必须符合整个系统的需求。在系统的数据库中分别对登陆人员信息和教师工作量信息进行存储，便于系统的分块开发、调试和维护，同时也可以使得各个模块能够相互独立的运行，这也符合软件工程的思想。本系统采用SQL
Server
2000。
4.2.1数据库系统
SQL
Server
2000
是一个全面的数据库平台，使用集成的商业智能
(BI)
工具提供了企业级的数据管理。其主要特点是：
·图形化用户界面，使系统管理和数据库管理更加直观、简单。
·丰富的编程接口工具，为用户进行程序设计提供了更大的选择余地。
·对Web技术的支持，使用户能够很容易的叫数据库中的数据发布到Web页面上。
·SQL
Server
2000
提供数据仓库功能，真正做到全面的服务系统。
4.2.2数据库管理系统
DBMS数据库管理系统，由许多程序组成。是支持用户建立、访问及维护数据库的一组软件，是数据库技术的直接体现。
DBMS主要包括以下功能：
1、数据定义功能：用户通过数据定义语言(DDL)对数据库中的数据对象进行定义。
2、数据操纵功能：用户使用数据操纵语言(DML)操纵数据实现数据库的基本操作。
3、数据库的运行管理：数据库在建立、运行和维护时由DBMS统一管理、统一控制，保证数据的安全性、完整性、多用户对数据的并发使用及发生故障后的系统恢复。
4、数据库的建立和维护功能：包括数据库初始数据的输入、转换功能，数据库的转储、恢复功能，数据库的重组功能和性能监视、分析功能等。
客户信息表设计如下：
表4.1
客户信息表
管理员表设计如下：
表4.2
管理员表
客机信息表设计如下：
表4.3
客机信息表
航线信息表设计：
表4.4
航线信息表
航线时刻舱位数量表设计如下：
表4.5
航线时刻舱位数量表
订票信息表设计如下：
表4.6
航线信息表
4.2.3
数据库的连接
ADO.NET是.NET框架中的数据访问组件，是一种新的数据访问对象模型。通过ADO.NET进行数据访问。ADO.NET提供了DataSet对象，它是一个与数据源无关的关系数据编程模型，它包含的对象和方法与关系数据模型相一致。ADO.NET连接的基本步骤如下：
1.声明一个连接对象；
2.提供一个连接字符串；
3.调用连接对象的OPEN方法；
4.只要ADO.NET方法需要，就指定连接对象的名称；
5.调用连接对象的CLOSE方法。
第五章
系统详细设计及编码实现
所谓的编码就是把软件结果翻译成用某种程序设计语言书写的程序。作为软件工程设计的一个阶段，编码是对设计进一步的具体化。因此，程序的质量主要取决于软件设计的质量。但是所选择的程序设计语言的特点及编码风格也将对程序的可靠性，可读性，可测试性和可维护性产生深远的影响。本系统运用VB.NET进行编程。
根据第三章需求分析和第四章总体设计，我们得到了系统的功能模块和系统的体系结构，详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，而在编码阶段可以把这个描述翻译成用某种程序设计语言书写的程序。下面在此基础上，对各个进行详细设计以及编码实现。
5.1一般用户模块设计
用户登录、用户注册、用户订票流程。
5.1.1用户登陆及用户注册界面
用户通过登陆窗口进行身份验证（输入账号和密码，系统将获取的用户信息与数据库里相应的用户信息进行比较）。如登陆信息都正确则进入系统最初界面，不同的用户将获得不同的权限。如登陆信息不正确，则无法登陆系统。添加新的用户，需要填写用户名、密码、确认密码和真实姓名。当填写完毕后且无误后点击确认按钮，如系统中不存在该用户（账号），则系统弹出“注册成功！”的对话框即添加成功，系统将自动转为用这个注册用户登录。系统将自动调转到航班查询页面。
登录和注册用户界面如图5.1和图5.2所示
图5.1用户登录页面
代码：
Private
Sub
Button2_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button2.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
客户信息表
where
用户名=
""
&
usename.Text
&
""and
登陆密码=""
&
pwd.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
temp
As
String
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
temp
=
reader.Read()
If
LCase(temp)
<>
"true"
Then
Response.Write("")
Else
Session("用户名")
=
reader.Item("客户姓名")
Session("用户编号")
=
usename.Text
Response.Redirect("航班搜索.aspx")
End
If
myconnection.Close()
End
Sub
图5.2用户注册页面
代码：
Private
Sub
Button2_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button2.ClickIf
namebox.Text
=
""
Or
num.Text
=
""
Or
honenum.Text
=
""
Or
mobnum.Text
=
""
Or
e_mail.Text
=
""
Or
work.Text
=
""
Or
addr.Text
=
""
Or
youbian.Text
=
""
Or
fax.Text
=
""
Then
Else
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
用户名
from
客户信息表
where
用户名=""
&
userid.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
temp
As
String
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
temp
=
reader.Read()
myconnection.Close()
If
LCase(temp)
=
"true"
Then
Response.Write("")
userid.Text
=
""
pwd.Text()
=
""
pwd1.Text
=
""
Else
If
pwd.Text
<>
pwd1.Text
Then
Response.Write("")
pwd.Text
=
""
pwd1.Text
=
""
Else
Dim
sql1
As
String
sql1
=
"insert
into
客户信息表(用户名,客户姓名,客户性别,证件类型,证件号码,联系电话,手机,传真,电子邮箱,工作单位,通信地址,邮政编码,登陆密码)
values
(""
&
userid.Text.Trim
&
"",""
&
namebox.Text.Trim
&
"",""
&
sex.SelectedItem.Text.Trim
&
"",""
&
post.SelectedItem.Text.Trim
&
"",""
&
num.Text.Trim
&
"",""
&
honenum.Text.Trim
&
"",""
&
mobnum.Text.Trim
&
"",""
&
fax.Text.Trim
&
"",""
&
e_mail.Text.Trim
&
"",""
&
work.Text.Trim
&
"",""
&
addr.Text.Trim
&
"",""
&
youbian.Text.Trim
&
"",""
&
pwd.Text.Trim
&
"")"
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
myconnection)
myconnection.Open()
selectcommand1.ExecuteNonQuery()
myconnection.Close()
Response.Write("")
Session("用户名")
=
namebox.Text
Session("用户编号")
=
userid.Text
Response.Redirect("航班搜索.aspx")
End
If
End
If
End
If
End
Sub
5.1.2用户预定、付款、推定界面
用户使用先是用航班搜索页面搜索出所需要的航班信息，用户选择所需要的航班在预定页面中列出这个航班的航班信息和该用户的注册信息，然后调转到用户订票信息页，用户在这也可以查看自己订票的信息，用户选择了自己所订的客票以后跳转到付款退订页，用户单击付款后到网上银行付款。
用户预定页面设计如图5.3
至
图5.6
所示
图5.3
航班搜索页面
代码：
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
航线信息表
where
出发城市=
""
&
TextBox1.Text
&
""and
到达城市=""
&
TextBox2.Text
&
""
"
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
mycommand
As
New
SqlDataAdapter(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
ds
As
New
DataSet
If
TextBox3.Text
=
""
Then
Response.Write("")
Else
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
myconnection.Close()
mycommand.Fill(ds,
"Literature")
DataGrid1.DataSource
=
ds.Tables("Literature").DefaultView
DataGrid1.DataBind()
Session("日期")
=
TextBox3.Text
Session("舱位类型")
=
DropDownList1.SelectedItem.Text
End
If
End
Sub
Private
Sub
ImageButton6_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.Web.UI.ImageClickEventArgs)
Handles
ImageButton6.Click
Calendar1.Visible
=
True
End
Sub
Private
Sub
Calendar1_SelectionChanged(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Calendar1.SelectionChanged
TextBox3.Text
=
Calendar1.SelectedDate
Calendar1.Visible
=
False
End
Sub
图5.4预定页面
代码：
Private
Sub
Page_Load(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
MyBase.Load
airnum.Text
=
Request.QueryString("a1")
takedate.Text
=
Session("日期")
cangwei.Text
=
Session("舱位类型")
userid.Text
=
Session("用户编号")
Dim
conn
As
SqlConnection
conn
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql1
As
String
sql1
=
"select
*
from
航线信息表
where
航线编号=
""
&
airnum.Text
&
"""
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
conn)
Dim
reader1
As
SqlDataReader
conn.Open()
reader1
=
selectcommand1.ExecuteReader()
reader1.Read()
takeup.Text
=
reader1.Item("出发城市")
takedown.Text
=
reader1.Item("到达城市")
takeuptime.Text
=
reader1.Item("出发时间")
takedowntime.Text
=
reader1.Item("到达时间")
plannum.Text
=
reader1.Item("客机编号")
price.Text
=
reader1.Item(cangwei.Text)
conn.Close()
Dim
sql2
As
String
sql2
=
"select
*
from
客户信息表
where
用户名=""
&
userid.Text
&
"""
Dim
selectcommand2
As
SqlCommand
=
New
SqlCommand(sql2,
conn)
Dim
reader2
As
SqlDataReader
conn.Open()
reader2
=
selectcommand2.ExecuteReader()
reader2.Read()
username.Text
=
reader2.Item("客户姓名")
zjleixing.Text
=
reader2.Item("证件类型")
zjnum1.Text
=
reader2.Item("证件号码")
conn.Close()
End
Sub
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
Dim
conn
As
SqlConnection
conn
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql2
As
String
sql2
=
"insert
into
订票信息表(客户编号,客户姓名,证件类型,证件号码,航线编号,出发城市,到达城市,舱位类型,出发日期,舱位价格,是否结算,登机)
values
(""
&
userid.Text.Trim
&
"",""
&
username.Text.Trim
&
"",""
&
zjleixing.Text.Trim
&
"",""
&
zjnum.Text.Trim
&
"",""
&
airnum.Text.Trim
&
"",""
&
takeup.Text.Trim
&
"",""
&
takedown.Text.Trim
&
"",""
&
cangwei.Text.Trim
&
"",""
&
takedate.Text.Trim
&
"",""
&
price.Text.Trim
&
"","否","否")"
Dim
selectcommand2
As
SqlCommand
=
New
SqlCommand(sql2,
conn)
conn.Open()
selectcommand2.ExecuteNonQuery()
conn.Close()
Response.Write("")
Response.Redirect("付款退定.aspx")
End
Sub
图5.5
用户订票信息页面
代码：
Private
Sub
Page_Load(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
MyBase.Load
userid.Text
=
Session("用户编号")
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
订票信息表
where
客户编号=
""
&
userid.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
mycommand
As
New
SqlDataAdapter(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
ds
As
New
DataSet
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
myconnection.Close()
mycommand.Fill(ds,
"Literature")
DataGrid1.DataSource
=
ds.Tables("Literature").DefaultView
DataGrid1.DataBind()
图5.6
付款退订页面
代码：
Private
Sub
Page_Load(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
MyBase.Load
num.Text
=
Request.QueryString("a2")
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
订票信息表
where
订票编号=
""
&
num.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
reader.Read()
username.Text
=
reader.Item("客户姓名")
airnum.Text
=
reader.Item("航线编号")
takeuptime.Text
=
reader.Item("出发日期")
takeup.Text
=
reader.Item("出发城市")
takedown.Text
=
reader.Item("到达城市")
price.Text
=
reader.Item("舱位价格")
cangwei.Text
=
reader.Item("舱位类型")
myconnection.Close()
End
Sub
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"update
订票信息表
set
是否结算="是"
where
订票编号=
""
&
num.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
myconnection.Open()
selectcommand.ExecuteNonQuery()
Response.Write("")
Response.Redirect("付款退定.aspx")
myconnection.Close()
End
Sub
Private
Sub
Button2_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button2.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"delete
from
订票信息表
where
订票编号=
""
&
num.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
myconnection.Open()
selectcommand.ExecuteNonQuery()
myconnection.Close()
Response.Write("")
Response.Redirect("付款退定.aspx")
End
Sub
5.1.3用户资料管理界面
用户登录后可以通过该页查看自己注册资料，点击修改并可以对想要修改的项目进行修改。
用户资料修改界面设计如图5.7
图5.8
图5.9所示
图5.7
用户资料查看界面
代码：
Private
Sub
Page_Load(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
MyBase.Load
userid.Text
=
Session("用户编号")
username.Text
=
Session("用户名")
If
userid.Text
=
""
Then
Response.Write("")
Response.Redirect("登陆.aspx")
Else
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
客户信息表
where
用户名=""
&
userid.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
reader.Read()
zjleixing.Text
=
reader.Item("证件类型")
zjnum.Text
=
reader.Item("证件号码")
honenum.Text
=
reader.Item("联系电话")
mobel.Text
=
reader.Item("手机")
fax.Text
=
reader.Item("传真")
e_mail.Text
=
reader.Item("电子邮箱")
work.Text
=
reader.Item("工作单位")
addr.Text
=
reader.Item("通信地址")
postnum.Text
=
reader.Item("邮政编码")
End
If
End
Sub
图5.8
用户资料修改界面
代码：
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"update
客户信息表
set
"
&
item.Text
&
"=""
&
TextBox1.Text.Trim
&
""
where
用户名=
""
&
Label1.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
myconnection.Open()
selectcommand.ExecuteNonQuery()
myconnection.Close()
Response.Write("")
Response.Redirect("个人资料管理.aspx")
End
Sub
图5.9密码修改界面设计
代码：
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
If
oldpwd.Text
=
""
Then
Response.Write("")
Else
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql1
As
String
sql1
=
"select
登陆密码
from
客户信息表
where
用户名=
""
&
Label4.Text
&
""and
登陆密码=""
&
oldpwd.Text
&
"""
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
myconnection)
Dim
reader1
As
SqlDataReader
Dim
temp1
As
String
myconnection.Open()
reader1
=
selectcommand1.ExecuteReader()
temp1
=
reader1.Read()
myconnection.Close()
If
LCase(temp1)
<>
"true"
Then
Response.Write("")
oldpwd.Text
=
""
Else
If
newpwd1.Text
<>
newpwd2.Text
Then
Response.Write("")
newpwd1.Text
=
""
newpwd2.Text
=
""
Else
Dim
sql2
As
String
sql2
=
"update
客户信息表
set
登陆密码=""
&
newpwd1.Text
&
""
where
用户名=
""
&
Label4.Text
&
"""
Dim
selectcommand2
As
SqlCommand
=
New
SqlCommand(sql2,
myconnection)
myconnection.Open()
selectcommand2.ExecuteNonQuery()
Response.Write("")
Response.Redirect("个人资料管理.aspx")
myconnection.Close()
End
If
End
If
End
If
End
Sub
5.2
系统管理模块设计
客机信息管理、航线信息管理、登机管理、管理员管理
5.2.1管理员登陆界面
不同的管理员有不同的权限，本系统设计了三种不同的管理员：系统管理员、登机管理员、航线管理员。其中航线管理员负责对客机信息和航线信息的添加、修改、删除，登记管理员负责在机场乘客登机操作，系统管理员权限最高兼有上诉两个管理员的功能。系统通过管理员登陆时来判断管理员的权限。管理员登陆界面设计如图5.10
所示，代码和用户登录相似这里略去。
图5.10
管理员登陆界面设计
5.2.2
客机信息管理
管理员登陆以后如果是航线管理员或者是系统管理员，就可对客机和航线进行增添修改。客机信息管理如图5.11
至
图5.14所示。
图5.11
客机信息管理界面
代码：
Dim
sql1
As
String
sql1
=
"select
*
from
客机信息表"
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
myconnection)
Dim
mycommand1
As
New
SqlDataAdapter(sql1,
myconnection)
Dim
reader1
As
SqlDataReader
Dim
ds1
As
New
DataSet
myconnection.Open()
reader1
=
selectcommand1.ExecuteReader()
myconnection.Close()
mycommand1.Fill(ds1,
"Literature")
DataGrid1.DataSource
=
ds1.Tables("Literature").DefaultView
DataGrid1.DataBind()
图5.12
客机信息增添界面
代码：
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
Handles
Button1.Click
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
*
from
客机信息表
where
客机编号=
""
&
plannum.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
temp
As
String
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
temp
=
reader.Read()
myconnection.Close()
If
LCase(temp)
=
"true"
Then
Response.Write("")
Else
Dim
sql1
As
String
sql1
=
"insert
into
客机信息表(客机编号,客机型号,购买日期,服役日期,经济舱座位数量,商务舱座位数量,头等舱座位数量)
values
(""
&
plannum.Text.Trim
&
"",""
&
plankind.Text.Trim
&
"",""
&
buydate.Text.Trim
&
"",""
&
usedate.Text.Trim
&
"",""
&
jjc.Text.Trim
&
"",""
&
swc.Text.Trim
&
"",""
&
tdc.Text.Trim
&
"")"
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
myconnection)
myconnection.Open()
selectcommand1.ExecuteNonQuery()
myconnection.Close()
Response.Write("")
plannum.Text
=
""
plankind.Text
=
""
buydate.Text
=
""
usedate.Text
=
""
jjc.Text
=
""
swc.Text
=
""
tdc.Text
=
""
End
If
myconnection.Close()
End
Sub
图5.13
客机信息修改删除界面
图5.14
客机信息修改界面
代码：代码与用户信息管管理和修改相似，这里略去。
5.2.3
航班信息管理
本功能有两个子功能，航线的增添、修改、删除和航线时刻的增添，用户通过这两个表搜索到航班信息。航班界面设计如图5.15
至
图5.20
所示。
图5.15
航线信息管理界面
代码：与客机信息管理相似这里略去。
图5.16航线信息增添界面设计
代码：与客机信息增添相似这里略去。
图5.17航线信息删除修改界面
图5.18
航线信息修改界面设计
代码：与客机信息修改和删除相似这里略去。
图5.19
航班信息管理界面设计
图5.20
航班增添界面设计
代码：与客机信息管理和客机信息增添相似这里略去。
5.2.4
管理员管理界面
本功能有管理员增添和修改密码，增添管理员只有系统管理员才能增添。其他管理员只能修改密码。管理员管理界面如图5.21
图5.22
所示。
图5.21
增添管理员
代码：
Private
Sub
Button1_Click(ByVal
sender
As
System.Object,
ByVal
e
As
System.EventArgs)
If
adminid.Text
=
""
Then
Response.Write("")
Else
Dim
myconnection
As
SqlConnection
myconnection
=
New
SqlConnection("server=(local);uid=sa;password=123;database=电子客票")
Dim
sql
As
String
sql
=
"select
管理员名
from
管理员表
where
管理员名=""
&
adminid.Text
&
"""
Dim
selectcommand
As
SqlCommand
=
New
SqlCommand(sql,
myconnection)
Dim
reader
As
SqlDataReader
Dim
temp
As
String
myconnection.Open()
reader
=
selectcommand.ExecuteReader()
temp
=
reader.Read()
myconnection.Close()
If
LCase(temp)
=
"true"
Then
Response.Write("")
adminid.Text
=
""
pwd1.Text
=
""
pwd2.Text
=
""
Else
If
pwd1.Text
=
""
Then
Response.Write("")
Else
If
pwd1.Text
<>
pwd2.Text
Then
Response.Write("")
pwd1.Text
=
""
pwd2.Text
=
""
Else
Dim
sql1
As
String
sql1
=
"insert
into
管理员表(管理员名,权限,密码)
values
(""
&
adminid.Text.Trim
&
"",""
&
DropDownList1.SelectedItem.Text.Trim
&
"",""
&
pwd1.Text.Trim
&
"")"
Dim
selectcommand1
As
SqlCommand
=
New
SqlCommand(sql1,
myconnection)
myconnection.Open()
selectcommand1.ExecuteNonQuery()
myconnection.Close()
Response.Write("")
Session("用户名")
=
adminid.Text
Session("权限")
=
DropDownList1.SelectedItem.Text
Response.Redirect("管理主页.aspx")
End
If
End
If
End
If
End
If
End
Sub
图5.22
修改密码
代码：与用户修改密码相似这里略去。
第六章
系统测试
本章主要进行系统的测试，经过上述对系统的分析、设计和编码后，应对系统进行详细的测试，这是软件投入使用前尽可能多的发现软件中的错误，并对错误进行修改，以达到系统在正式运行时性能等各方面状况良好。
6.1
测试理论
按照测试过程是否在实际应用环境中运行来分类，可将测试方法分为静态测试与动态测试。首先采用静态测试，然后运行整个程序，对重点模块采用动态的黑盒测试。
通过上述测试，把那些在设计和编码中的逻辑设计错误和编码错误找出来，消除系统运行中遇到的错误。本次测试检查出了数据库中的数据结构和所添数据不对应的错误。通过修改、调试使之数据一致，程序功能完整。
静态测试根据用户需求来检查需求分析文件，看系统功能是否有遗漏的地方，根据数据流图和数据字典来检查数据库设计是否合理。其次是反复阅读源程序和数据流图，对照模块功能说明、算法和语法规则来检查程序的语法错误及逻辑错误。最后自己来充当计算机的角色，按照程序的逻辑步骤用头脑来执行程序，以检查程序的逻辑与功能并从中发现错误。
动态黑盒测试。它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
下面介绍静态测试和动态测试的具体过程。
6.2具体测试实例
用户登陆时，如果登陆信息正确，则进入系统，并显示航班搜索界面（如图6.1）。如果登陆信息不正确，则显示“账号密码比正确！”返回登陆页（如图6.
2）。
图6.1
登陆成功
图6.2
登陆失败
用户注册时，如果正确输入就跳转到航班搜索页（如图6.3），如果输入不正确则弹出正确输入提示框（如图6.4
图6.5）。
图6.3
注册成功图6.4
带（*）号没填弹出提示框
图6.5密码确认不正确探出提示框
航班预定如果在能够搜索到航线则在搜索页的DataGrid中显示出该航线线的信息（如图6.6），如没有搜索到航线则DataGrid控件为空（如图6.7）。选择了所要航班以后，则跳转到预定页，在预定页中显示出所选的航线信息和登陆的用户信息（如图6.8）。用户选择预定则把该航班信息和用户信息存入客户预定表，并跳转到用户订票信息页在此页DataGrid中显示出登陆用户的订票信息，用户订票成功（如图6.9）。当时还没有付款用户选择了以预定的机票，则跳转到付款页（如图6.10）用户点击付款则付款成功。
图6.6
有搜索结果
图6.7
无搜索结果
图6.8
预定机票信息
图6.9
订票信息
图6.10
付款页
个人资料管理进入个人资料管理界面在此页中显示出以登陆用户的个人信息（如图6.11），用户点击修改则弹出修改页在此页中显示出用户名和需要修改的属性。用户在TextBox框中编辑要修改的内容(如图6.12)，修改后返回个人资料管理页（如图6.13）。用户修改密码时如果旧密码为空或者不正确则弹出错误提示（如图6.14，图6.1.15），如果新密码和确认密码不符弹出错误提示（如图6.1.16）。成功修改则返回个人资料管理页。
图6.11
个人信息管理页
图6.12
修改信息
图6.13
修改成功后
图6.14
旧密码为空
图6.15
旧密码不正确
图6.16
修改成功
结束语
这次设计开发飞机电子客票：通过网络，用户可以轻松的预定和查看航班信息，简化了客户预定和登机的程序。
经过将近四个月的设计开发，学会了开发一个完整的网站的全过程，学习了ASP.NET技术，对Web应用程序的开发有了进一步的了解，尤其是在Microsoft
Visual
Studio
.NET环境下编写、调试程序的能力有了明显提高，并在整个设计开发过程中掌握了许多解决问题的方法。使得自己得到了很好的锻炼，利用软件工程的思想进行系统的需求分析和设计、运用正确的设计方法，结合管理系统设计知识，提高系统设计实践能力，完成了对系统用户管理、航班搜索和客户预订航班、用户登机功能。理解了开发一个完整的系统是通过软件之间的相互协调工作支撑的。同时在这次论文的写作中，我也全心的投入，争取把自己学习到的最好的方面展示给所有的人。但今后系统还需要进一步完善，要做的工作还很多，这些只是实现了模块的简单功能，并没考虑其复杂功能，这需要今后去设计实现。
毕业设计，是一次很好地提高实践能力和自我发展能力的机会，我们可以综合运用所学专业知识分析、解决问题。为今后的研究开发工作打下了基础，积累了难得的宝贵经验，使我受益非浅。
致
谢
在这次毕业设计中，我得到了薛颂东老师的精心指导，在我们设计期间，老师给了我们很大的帮助和支持，并且还给我们提出了大量的具有实用价值的宝贵意见，帮我们理顺设计的思路，身边的同学也给了我很大的帮助，我对此表示由衷的感谢与敬意。
薛老师认真负责的工作态度，严谨的治学精神和深厚的理论水平都使我受益匪浅。他无论在理论上还是实践中，对给与我很大的帮助，使我学到了不少知识，得到了不少的提高。他给我提了很多的建议，纠正了我在设计初期犯的一些毛病。感谢他耐心的辅导。
最后祝愿在毕业设计中帮助我的老师和同学在今后的工作学习生活中一帆风顺，开开心心。
参
考
文
献
[1]
尚俊杰。
ASP.NET程序设计。
北京：北京清华大学出版社
北京交通大学出版社，
2005.3
[2]李禹生、刘兵。
ASP实用技术-网络设据库运用系统设计。
北京：中国水利水电出版社，2004.8
[3]
陈惠贞、陈俊荣。
ASP.NET程序设计。
北京：中国铁道出版社，2004.5
[4]
杨开英。数据库系统概论。武汉：武汉理工大学出版社，2003.11
[5]
李伟红。SQL
Server
2000实用教程。北京：中国水利水电出版社，2003
[6]
张海藩。软件工程。北京：人民邮电出版社，2004.11
[7]
URL:
http://news.xinhuanet.com/ec
/2006-02/07/content_4145543_1.htm
。07年全面无纸化电子机票敲响中小票代"丧钟"。北京：新华网。
2006.2
[8]
URL:http:///。黄金假日网站。北京：北京黄金假日旅行社有限公司。
[9]
URL:
http://eticketgroup.cs-air.com/。南方航空电子客票系统。附录I
英文翻译
英文原文
Chapter
8.
Process
Improvement
Planning
Make
no
little
plans;
they
have
no
magic
to
stir
men"s
blood
and
probably
themselves
will
not
be
realized.
Make
big
plans;
aim
high
in
hope
and
work,
remembering
that
a
noble,
logical
diagram
once
recorded
will
never
die,
but
long
after
we
are
gone
will
be
a
living
thing,
asserting
itself
with
ever-growing
insistence.
Remember
that
our
sons
and
grandsons
are
going
to
do
things
that
would
stagger
us.
Let
your
watchword
be
order
and
your
beacon
beauty.
—Attributed
to
Daniel
H.
Burnham
[(1846–1912),
American
architect
and
city
planner.]
While
Burnham
expressed
these
thoughts
in
a
paper
he
read
before
the
Town
Planning
Conference,
London,
1910,
the
exact
words
were
reconstructed
by
Willis
Polk,Burnham"s
San
Francisco
partner.
Polk
used
the
paragraph
on
Christmas
cards
in
1912
after
Burnham"s
death
in
June
of
that
year.
—Henry
H.
Saylor,
"Make
No
Little
Plans,"Journal
of
the
American
Institute
of
Architects,
March
1957,
pp.
95–99.
8.1
Introduction
The
purpose
of
this
chapter
is
to
give
you
guidance
for
writing
an
SEE
implementation
plan.
Armed
with
this
guidance,
you
can
establish
the
framework
for
applying
to
your
organization
the
things
discussed
in
the
preceding
chapters.
Our
approach
is
to
present
and
discuss
key
SEE
implementation
issues.
The
aim
of
this
discussion
is
to
provide
you
with
insight
into
how
to
lay
out
an
SEE
implementation
approach
that
makes
sense
for
your
organization.
For
example,
we
discuss
the
rate
at
which
ADPE
elements
should
be
developed
and
implemented.
We
describe
some
of
the
key
factors
bearing
upon
this
rate
(e.g.,
the
software
and
system
engineering
experience
level
of
your
organization"s
management
and
staff).
These
factors
should
help
you
plan
an
ADPE
development
and
implementation
rate
appropriate
for
your
organization.
Before
we
address
process
improvement
planning
issues,
we
set
context.
Figure
8-1
reminds
us
that,
as
we
repeatedly
stressed
in
the
preceding
chapters,
consistent
successful
software
systems
development
requires
sustained
effective
communication
between
the
software
seller
and
the
software
customer.
Reduced
to
the
simplest
terms,
the
concepts
and
principles
examined
in
these
chapters
have
their
roots
in
this
premise.
We
now
recall
some
of
these
concepts
and
principles
through
an
overview
of
the
preceding
chapters.
To
aid
you
in
this
recall,
Figure
8-2
highlights
the
theme
of
each
of
these
chapters.
Figure
8-1
At
the
most
fundamental
level,
the
avenue
to
consistent
successful
software
systems
development
is
sustained
effective
communication
between
the
wizard
(i.e.,
software
seller)
and
the
king
(i.e.,
software
customer).
(The
Wizard
of
Id,
September
30,
1983.
Reprinted
by
permission
of
Johnny
Hart
and
Creators
Syndicate,
Inc.)
Figure
8-2
The
preceding
chapters
capture
the
essence
of
things
that
you
need
to
consider
in
planning
for
implementing
a
systems
engineering
environment
(SEE)
in
your
organization.
SEE
implementation
is
a
structured
way
of
institutionalizing
consistent
successful
software
systems
development.
This
chapter
integrates
the
ideas
from
the
preceding
chapters
to
guide
your
SEE
implementation
planning
activity.
?
Chapter
1
(Business
Case)
explored
why
it
makes
good
business
sense
for
an
organization
to
take
the
time
to
alter
its
way
of
doing
software
development
to
achieve
consistency.
This
chapter
also
introduced
key
concepts
to
establish
a
working
vocabulary
for
the
rest
of
the
book
(e.g.,
software,
software
process,
product
and
process
"goodness,"
culture).
We
emphasized
that
customer/seller
faulty
communication
underlies
a
majority
of
software
systems
development
problems.
We
stressed
that
software
process
improvement
is
first
and
foremost
a
cultural
change
exercise.
We
introduced
the
requisite
software
systems
development
disciplines—
management,
development,
and
product
assurance.
We
introduced
the
change
control
board
(CCB)
as
a
mechanism
for
sustaining
effective
communication
among
these
disciplines
throughout
a
software
systems
development
project.
We
introduced
the
notion
of
"prescriptive
application"
of
an
organization"s
documented
software
systems
development
process.
We
explained
why
prescriptive
application
is
one
of
the
keys
to
institutionalizing
the
process.
The
SEE
also
provides
the
means
for
effecting
improvement
to
the
software
development
process.
Consistent
successful
software
systems
development
and
software
process
improvement
are
thus
intertwined
in
the
SEE
concept.
?
Chapter
2
(Project
Planning
Process)
provided
you
with
guidance
for
effectively
planning
software
systems
development
work.
We
referred
to
the
document
containing
planning
information
as
the
"project
plan."
We
indicated
that
the
project
plan
is
a
gauge
used,
in
part,
to
think
through
what
needs
to
be
done,
to
estimate
how
much
the
effort
may
cost,
and
to
determine
whether
software
systems
development
work
is
unfolding
as
it
was
envisioned.
We
stressed
that
project
planning
is
an
ongoing
negotiation
between
the
customer
(king)
and
the
seller
(wizard).
We
showed
you
how
to
plug
the
CCB
apparatus
into
your
project
plan
so
that
the
wizard
and
king
could
effectively
interact
throughout
the
project.
We
showed
you
how
the
life
cycle
concept
can
be
used
to
drive
out
specific
tasks
to
be
performed.
We
illustrated
this
fundamental
point
with
three
example
life
cycles—(1)
six-stage
classical
development,
(2)
prototype
development,
and
(3)
(data-centered)
information
engineering.
We
showed
you
how
to
design
a
simple
risk
assessment
approach
for
allocating
resources
to
the
three
sets
of
requisite
software
systems
development
disciplines—management,
development,
and
product
assurance—thereby
showing
how
you
can
explicitly
incorporate
risk
reduction
into
your
project
budget.
Most
importantly,
we
showed
you
how
to
plan
for
change.
We
organized
this
project
planning
guidance
into
an
easy-to-use
package
by
showing
you
how
to
develop
an
ADPE
element
defining
your
organization"s
project
planning
process.
?
Chapter
3
(Software
Systems
Development
Process)
established
the
focus
for
the
remainder
of
the
book.
We
defined
principles
for
defining
a
software
systems
development
process.
We
explained
that
a
process
constructed
by
applying
these
principles
is
likely
to
yield
consistently
"good"
products—i.e.,
products
you’re
your
customer
wants
and
that
are
delivered
on
time
and
within
budget.
To
help
you
apply
these
principles,
we
illustrated
them
by
defining
a
top-level
process
that
you
can
use
as
a
starting
point
to
formulate
a
process
for
your
own
organization.
We
again
stressed
the
critical
importance
of
maintaining
the
wizard
and
king
dialogue
by
making
the
CCB
a
key
element
of
the
top-level
process.
We
emphasized
that,
in
general,
the
process
cannot
be
reduced
to
a
rigidly
defined
procedure
with
a
definite
order
to
the
steps
to
be
followed.
Rather,
we
stressed
that
prescriptive
application
of
the
process
was
key
to
achieving
consistent
software
systems
development.
That
is,
the
process
should
specify
what
is
to
be
done;
individuals
should
be
empowered
to
figure
out
how
to
do
the
what.
We
showed
you
how
to
plug
a
specific
life
cycle
into
the
top-level
process
to
explain
how
a
project
unfolds
during
process
application.
We
showed
you
how
to
design
a
form
to
help
you
track
a
product
as
it
wends
its
way
through
your
software
systems
development
process.
We
explained
that
the
process
does
not
stop
once
the
product
goes
out
the
seller"s
door.
Rather,
we
discussed
the
customer
and
seller
responsibilities
after
the
seller
has
delivered
the
product
to
the
customer.
We
folded
the
chapter"s
process
definition
ideas
into
an
easy-to-use
package—namely,
an
annotated
outline
for
an
ADPE
element
defining
your
organization"s
software
systems
development
process.
We
explained
why
this
element
is
a
good
place
to
begin
setting
up
your
ADPE.
?
Chapter
4
(Change
Control
Process)
focused
on
the
change
control
board
(CCB)
as
a
forum
for
sustaining
effective
communication
between
the
wizard
and
king
as
well
as
among
the
wizard"s
staff.
We
provided
you
with
guidance
for
setting
up
CCBs
for
your
software
systems
development
process.
We
also
provided
guidance
for
managing
unplanned,
as
well
as
planned,
change.
We
thereby
closed
the
loop
introduced
in
Chapter
2
where
we
emphasized
that
you
need
to
account
for
the
unknown
in
your
project
plan
as
well
as
accounting
for
the
known.
Chapter
4
also
closed
the
loop
introduced
in
Chapter
3,
which
stressed
that,
by
integrating
the
customer/seller
CCB
into
your
software
systems
development
process,
you
make
product
acceptance
by
the
customer
almost
a
foregone
conclusion.
We
showed
you
how
to
do
this
integration
by
stepping
through
change
control
mechanics
for
both
planned
and
unplanned
changes.
We
explained
the
CCB
role
in
traversing
a
project
life
cycle.
We
introduced
the
following
three
scenarios,
each
regulated
by
a
CCB,
that
we
asserted
govern
all
of
change
control:
o
Do
we
want
something
new
or
different?
o
Is
something
wrong?
o
Should
we
baseline
the
product?
We
showed
you
what
to
record
at
CCB
meetings
and
gave
examples
of
CBB
minutes.
We
offered
you
guidance
for
choosing
a
CCB
chairperson
and
a
CCB
voting
mechanism.
We
offered
you
guidance
for
determining
when
CCB
hierarchies
are
appropriate
and
how
to
set
them
up.
We
gave
you
detailed
guidance
for
constructing
change
control
forms
to
support
the
preceding
change
control
scenarios.
We
also
gave
example
forms
to
help
you
get
started
in
applying
this
guidance.
We
organized
the
CCB
concepts
and
guidance
into
an
easy-to-use
package
by
showing
you
how
to
develop
an
ADPE
element
defining
your
organization"s
change
control
boards.
?
Chapter
5
(Product
and
Process
Reviews)
focused
on
the
product
and
process
reviews
needed
to
give
visibility
into
what
is
happening
on
a
software
project.
To
establish
context
for
the
chapter,
we
asserted
the
following:
o
Each
software
project
should
be
approached
with
the
candid
realization
that
it
is
a
voyage
through
iceberg-infested
waters
(or
worse!).
o
If
this
attitude
is
adopted,
then
common
sense
and
the
natural
instinct
for
self
preservation
can
lead
to
only
one
conclusion—that
some
way
must
be
found
to
steer
clear
of
the
icebergs
to
the
extent
prudently
possible.
o
Product
and
process
reviews
are
techniques
for
steering
clear
of
the
icebergs.
We
defined
a
two-dimensional
review
taxonomy
that
consists
of
the
following
product
and
process
reviews:
o
Management
Reviews
??
Product
and
Process
Programmatic
Tracking
??
Product
and
Process
Technical
Oversight
o
Development
Reviews
??
Product
and
Process
Peer
Reviews
??
Technical
Editing
of
Software
and
Software-Related
Documents
o
Product
Assurance
Reviews
??
Product
Quality
Assurance,
Verification
and
Validation,
Test
and
Evaluation,
and
Self-Comparison
??
Process
Quality
Assurance
at
the
Product
Level
and
at
the
Project
Level
The
product
reviews
identified
were,
for
the
most
part,
those
called
out
in
Chapter
3
when
we
defined
a
top-level
software
systems
development
process.
The
process
reviews
identified
were
extensions
to
the
product
reviews.
For
example,
for
management,
we
called
out
two
types
of
reviews—programmatic
tracking
and
technical
oversight—for
both
a
specific
product
and
the
software
systems
development
process.
We
organized
the
chapter
along
the
lines
of
the
systems
disciplines.
Because
we
believe
that
application
of
the
product
assurance
disciplines
offers
the
greatest
potential
for
reducing
risk
on
a
software
project,
the
chapter
devoted
considerable
attention
to
the
product
assurance
product
reviews.
In
particular,
the
chapter
stepped
through
the
mechanics
of
product
assurance
document
reviews
and
acceptance
testing.
In
this
book,
acceptance
testing
constitutes
that
activity
in
the
software
systems
development
process
where
the
wizard
formally
demonstrates
to
the
king
that
the
software
system
and
supporting
databases
do
what
they
are
supposed
to
do.
Acceptance
testing
is
therefore
the
bottom
line
of
the
software
systems
development
process.
For
this
reason,
the
chapter
includes
a
detailed
discussion
of
requirements
testability
with
a
worked
out
example.
For
reviews
not
addressed
(e.g.,
unit
and
integration
testing),
the
chapter
offered
suggestions
for
extending
the
taxonomy
to
include
such
reviews.
To
help
you
apply
the
review
guidance
presented
in
the
chapter,
we
showed
you
how
to
develop
an
ADPE
element
for
product
assurance
reviews.
We
showed
you
how
to
integrate
other
product
and
process
reviews
into
this
element.
Because
peer
reviews
are
generally
recognized
as
adding
significant
value
to
the
software
systems
development
process,
we
showed
you
how
to
develop
a
peer
review
ADPE
element.
?
Chapter
6
(Measurement)
provided
you
with
guidance
for
measuring
product
and
process
"goodness."
Borrowing
from
the
mathematical
discipline
of
vector
analysis,
we
quantified
"goodness"
as
the
length
of
a
vector
in
a
space
that
we
labeled
"integrity."
The
dimensions
in
this
space
are
the
product
or
process
attributes
that
we
are
interested
in
measuring.
For
example,
for
a
product
we
might
want
to
measure
the
extent
to
which
customer
requirements
are
satisfied
and/or
whether
delivery
was
on
time
and/or
delivery
was
within
budget.
For
a
process,
we
might
want
to
measure,
for
example,
whether
peer
reviews
were
conducted
and/or
whether
product
assurance
reviews
were
performed
and/or
whether
risk
assessment
was
performed
during
project
planning.
We
illustrated
how
to
set
up
value
scales
for
the
attributes
and
gave
you
guidance
for
establishing
value
scales
that
make
sense
for
your
organization.
We
illustrated
how
to
measure
the
integrity
of
a
requirements
specification,
a
user"s
manual,
computer
code,
and
a
project
plan.
We
illustrated
how
to
measure
the
integrity
of
the
process
introduced
in
Chapter
3.
To
help
you
apply
the
chapter"s
integrity
measurement
approach,
we
reduce
it
to
a
small
number
of
easy-to-follow
steps.
These
steps
also
show
you
how
to
relate
process
integrity
and
product
integrity
measurements
to
one
another
to
help
you
focus
your
process
improvement
efforts.
The
product/process
integrity
measurement
approach
presented
is
actually
a
very
general
approach
to
quantifying
almost
any
object.
We
thus
call
this
approach
"object
measurement,"
or
OM?.
To
hint
at
its
general
applicability,
we
applied
OM
to
the
Software
Engineering
Institute"s
Capability
Maturity
Model
for
Software
(CMM?
for
Software)
to
show
how
the
model"s
key
process
areas
(KPAs)
could
be
quantified.
We
also
showed
how
OM
can
be
used
to
quantify
abstract
entities
such
as
strategic
information
management.
In
addition
to
product
integrity
and
process
integrity
measurements,
we
showed
how
to
establish
other
process-related
measurements
tied
to
one
or
more
components
of
the
software
systems
development
process.
The
approach
was
based
on
taking
simple
averages
involving
the
number
of
times
a
particular
activity
or
set
of
activities
was
performed
on
various
projects
within
an
organization.
For
example,
we
defined
the
following
measurements
that
might
be
useful
for
an
organization
to
collect
for
the
purpose
of
assessing
process
effectiveness:
o
Average
number
of
peer
reviews
required
to
produce
deliverables
that
are
accepted
by
the
customer
(i.e.,
the
customer
returns
the
Acceptance
of
Deliverable
form
indicating
"the
product
is
accepted
as
delivered").
o
Percentage
of
deliverables
delivered
on
time
to
the
customer
during
a
specific
period
for
certain
projects,
where
"on
time"
is
according
to
delivery
dates
specified
in
project
plans
or
CCB
minutes.
o
Average
number
of
drafts
required
to
produce
a
project
plan
resulting
in
a
project.
o
Customer
perception
of
the
seller
organization.
We
organized
the
chapter"s
measurement
guidance
into
an
easy-to-use
package
by
showing
you
how
to
develop
an
ADPE
element
defining
your
organization"s
product
and
process
metrics
and
your
organization"s
approach
to
applying
them
to
improve
your
software(-related)
products
and
software
development
process.
?
Chapter
7
(Cultural
Change)
focused
on
the
human,
as
opposed
to
engineering,
issues
bearing
on
successful
software
systems
development.
The
chapter
proceeds
from
the
following
premise,
which
is
grounded
in
experience:
Getting
a
process
on
paper
is
a
challenge,
but
getting
the
people
in
the
organization
to
commit
to
the
change
is
the
challenge.
People
commit
to
change
for
their
own
reasons,
not
for
someone
else"s
reasons.
Therefore,
when
people
are
asked
to
commit
to
change,
their
first
concern
may
be
their
perceived
losses.
We
stressed
that
SEE
implementation
is
first
and
foremost
a
cultural
change
exercise—an
exercise
in
behavior
modification.
As
we
explain
in
the
current
chapter,
this
consideration
bears
heavily
on
developing
a
realistic
SEE
implementation
plan.
Successful
software
implementation
is
predominantly
a
people
management
exercise
and
not
an
engineering
management
exercise
Most
of
us
do
what
we
do
(whether
it
is
developing
software
systems
or
brushing
our
teeth)
because
we
feel
most
comfortable
doing
things
our
way.
It
should
therefore
not
be
a
surprise
that
persuading
people
in
the
software
systems
development
world
to
do
things
someone
else"s
way
(i.e.,
the
organization"s
way)
can
be
a
daunting
challenge—fraught
with
surprises.
We
examined
the
role
in
bringing
about
cultural
change
of
the
organization
responsible
for
writing
the
ADPE
elements
(i.e.,
the
process
engineering
group
[PEG])
and
seeing
to
it
that
they
are
implemented
and
continually
improved.
We
alerted
you
to
considerations
bearing
upon
PEG
member
qualifications
(e.g.,
hands-on
experience
developing
software
systems).
We
discussed
how
to
deal
with
ADPE
implementation
challenges
arising
from
the
wizard"s
project-level
individuals
who
will
have
to
adapt
to
practices
set
forth
in
the
ADPE
elements
that
govern
their
work.
On
the
customer
side,
we
discussed
how
to
deal
with
ADPE
implementation
challenges
arising
from
those
kings
who
give
technical
direction
to
wizard
project
managers.
In
this
vein,
we
discussed
how
to
get
the
customer
to
be
part
of
ADPE
implementation.
We
also
discussed
the
pros
and
cons
of
getting
the
customer
to
be
accountable
for
ADPE
implementation,
as
well
as
the
seller.
We
examined
the
key
role
that
seller
senior
management
plays
in
effecting
software
systems
development
cultural
change
through
ADPE
implementation.
On
the
other
side,
we
examined
the
impact
on
customer
senior
management
that
ADPE
implementation
brings
about.
We
provided
you
with
guidance
for
extracting
key
ideas
from
ADPE
elements
and
packaging
them
for
distribution
to
your
organization
as
a
means
for
effecting
cultural
change
(e.g.,
the
use
of
prominently
displayed
foam
boards
showing
key
process
concepts
such
as
requirements
based
acceptance
testing).
We
discussed
the
role
of
training
in
effecting
cultural
change.
In
particular,
we
stressed
the
key
role
that
ADPE
element
briefings
to
wizard
and
king
staff
plays
in
getting
the
organization
to
assimilate
desired
engineering
behavior.
Allied
with
the
role
of
training
in
bringing
about
cultural
change,
we
examined
the
role
of
mentoring
and
coaching.
We
discussed
how
to
sell
ADPE
implementation
as
a
career
growth
opportunity.
We
looked
at
organizational
factors
bearing
upon
how
long
it
takes
to
bring
about
cultural
change.
We
examined
why
an
ADPE
element
defining
the
ADPE
element
development
and
improvement
process
is
intimately
tied
to
organizational
cultural
change.
We
concluded
the
chapter
by
giving
you
an
annotated
outline
for
an
ADPE
element
defining
the
ADPE
element
development
and
improvement
process.
This
element
provides
the
framework
for
evolving
the
ADPE
in
a
self-consistent
manner.
Where
do
you
go
from
here?
How
do
you
put
together
the
concepts
and
guidance
from
the
preceding
chapters
to
lay
out
an
approach
for
consistent
successful
software
systems
development
or
to
improve
what
you
already
have?
As
Figure
8-3
indicates,
this
chapter
is
aimed
at
helping
you
plan
an
SEE
implementation
approach.
Figure
8-3
This
chapter
offers
planning
guidance
to
wizards
and
kings
for
setting
up
a
software
process
improvement
approach
via
SEE
implementation.
The
chapter
helps
you
select
concepts
from
the
preceding
chapters
to
construct
this
approach.
The
concept
of
implementation
plan
as
used
in
this
chapter
means
"anything
from
notes
scratched
on
the
back
of
an
envelope
to
a
multivolume
formal
and
highly
detailed
document—whatever
makes
sense
for
your
organization."
Reduced
to
simplest
terms,
plan
in
this
chapter
means
"think
and
coordinate
before
doing."
We
stress
at
the
outset
that
this
chapter
is
intended
for
both
wizards
and
kings.
If
you
are
a
wizard,
this
chapter
will
help
you
respond
to
a
king"s
request
for
a
wizard
whose
skill
lies
not
in
hand-waving
but
lies
in
setting
up
and
following
processes
that
consistently
yield
products
with
integrity
(ideally,
you
should
not
have
to
wait
for
a
king
to
ask
you
for
a
repeatable
way
of
doing
business).
If
you
are
a
king,
this
chapter
will
help
you
(1)
construct
an
SEE
implementation
approach
to
include
in
a
request
for
proposal
(RFP)
that
you
want
a
wizard
that
you
intend
to
hire
to
follow
or
(2)
give
guidance
in
an
RFP
to
a
wizard
that
you
want
to
hire
to
construct
an
SEE
implementation
approach
to
include
in
the
wizard"s
proposal
or
(3)
give
guidance
to
a
wizard
that
you
have
already
hired
to
construct
an
SEE
implementation
approach.
As
Figure
8-3
indicates,
"implementation
plan"
as
used
in
this
chapter
spans
a
broad
spectrum.
It
could
be
something
as
informal
as
notes
scribbled
on
the
back
of
an
envelope
highlighting
the
handful
of
things
that
need
to
be
accomplished
to
set
up
and
operate
within
an
SEE.
At
the
other
end
of
the
documentation
spectrum,
"implementation
plan"
could
be
a
multivolume
tome
(for,
say,
a
large
systems
development
effort
with
major
software
content,
or
for
a
large
organization
handling
fifty
to
several
hundred
or
more
concurrent
software
systems
development
efforts).
Or
"implementation
plan"
could
be
something
in
between
these
two
documentation
extremes.
No
matter
where
in
the
spectrum
it
lies,
the
purpose
of
the
plan
is
to
bring
involved
parties
within
an
organization
into
the
same
frame
of
reference
for
setting
up
a
consistent
way
of
doing
software
systems
development
business.
This
chapter
serves
as
a
guide
to
help
you
work
your
way
back
into
previously
introduced
ideas
to
integrate
them
into
an
SEE
implementation
approach
that
makes
sense
for
your
organization.
Since
we
do
not
know
the
details
of
your
organization,
this
chapter
bounds
your
thinking
by
giving
you
factors
to
consider
when
laying
out
an
implementation
approach.
For
example,
we
give
you
things
to
consider
bearing
upon
how
frequently
ADPE
elements
should
be
updated
so
that
you
can
include
in
your
implementation
plan
an
element
update
schedule.
8.2
SEE
Implementation
Planning
Key
Ideas
Figure
8-4
lists
the
key
ideas
that
you
can
expect
to
extract
from
this
chapter.
To
introduce
you
to
this
chapter,
we
briefly
explain
these
key
ideas.
Their
full
intent
will
become
apparent
as
you
go
through
the
chapter.
Figure
8-4
Here
are
some
key
process
improvement
planning
concepts
explained
in
this
chapter.
These
key
ideas
are
your
guide
to
plan
SEE
implementation
realistically.
A
realistic
SEE
implementation
plan
helps
to
focus
your
efforts
toward
consistent
successful
software
systems
development.
To
plan
realistically
in
this
chapter
means
"laying
out
an
approach
that
motivates
people
to
(1)
overcome
their
resistance
to
change
and
(2)
implement
SEE
business
practices."
1.
Plan
your
process
improvement
with
business
practices
defined
in
ADPE
elements.
Your
SEE
implementation
plan
should
propose
an
element
phase-in
strategy,
with
your
first
element
defining
your
software
systems
development
process.
As
we
showed
in
Chapter
3,
this
element
establishes
the
context
for
most
or
all
other
ADPE
elements.
The
software
systems
development
process
element
is
itself
thus
a
plan
for
subsequent
ADPE
development.
Any
SEE
should
include
at
least
this
element.
2.
The
primary
objective
of
SEE
implementation
is
to
establish
organizationwide
business
practices
that
do
not
depend
on
particular
individuals
for
their
successful
accomplishment.
This
objective
should
not
be
misunderstood.
Removing
dependence
on
particular
individuals
for
successful
software
systems
development
does
not
mean
that
SEE
implementation
is
designed
to
put
people
out
of
work.
Good
people
are
certainly
needed
to
achieve
successful
software
systems
development.
The
intent
of
establishing
organization-wide
business
practices
is
to
plug
all
these
people
into
a
consistent
way
of
doing
things,
so
that
on
any
given
day
good
work
will
be
done
no
matter
who
is
doing
the
work.
These
business
practices
leverage
the
goodness
of
people
across
the
organization
and
help
provide
them
with
professional
mobility.
For
example,
Chapter
4
showed
how
to
set
up
an
ADPE
element
governing
an
organization"s
CCB
meetings.
Specifically,
we
explained
how
this
element
can
be
used
to
specify
organizationwide
practices
for
setting
up,
conducting,
and
documenting
CCB
meetings.
These
practices
allow
CCB
meetings
to
be
conducted
and
documented
on
any
given
day
in
the
same
way
that
they
are
conducted
and
documented
on
any
other
day—no
matter
who
is
conducting
and
documenting
them.
Good
people
are,
of
course,
needed
to
make
these
meetings
worthwhile—that
is,
to
help
carry
through
on
software
project
work.
3.
Package
your
engineering
environment
in
a
binder
containing
your
ADPE
elements
and
material
pertinent
to
your
technology
environment.
Give
a
binder
copy
to
each
member
of
your
organization.
SEE
implementation
cannot
begin
to
happen
unless
the
SEE
gets
into
the
hands
of
your
organization"s
people.
One
standard
way
to
promulgate
ADPE
elements
and
the
associated
technology
environment
is
to
place
this
material
in
a
binder
(hard
copy
or
electronic)
and
give
each
member
of
your
organization
a
copy
when
that
person
joins
your
organization.
The
binder
should
also
contain
an
explanation
of
the
SEE
concept
and
the
relationship
of
this
concept
to
your
organization"s
business
objectives.
It
should
also
contain
instructions
for
adapting
its
contents
to
the
specific
project
work
to
be
accomplished
by
the
binder
recipient.
For
example,
each
binder
should
have
space
for
project-specific
material
such
as
a
copy
of
the
customer"s
statement
of
work
(SOW)
and
the
project
plan
governing
that
recipient"s
work.
Your
organization
should
set
up
a
process
for
sending
SEE
updates
to
binder
recipients.
Of
course,
packaging
the
SEE
in
a
binder
and
giving
binder
copies
to
each
member
of
your
organization
does
not
make
the
business
practices
in
the
binder
happen.
Among
other
things,
your
organization
should
establish
a
policy
delineating
that
each
individual
is
responsible
for
(1)
reading
its
contents,
(2)
following
the
practices
documented
therein,
and
(3)
promoting
these
practices
with
your
organization"s
customers.
To
make
this
policy
happen,
you
will
need
to
offer
training
and
incentives.
The
training
should
be
aimed
at
explaining
such
things
as
the
engineering
principles
underlying
ADPE
elements
and
the
value
added
of
following
the
practices;
the
training
should
also
stress
that
following
the
practices
offers
the
individual
career
growth
opportunities
because
the
individual
is
not
a
captive
of
a
particular
project
function
(e.g.,
with
a
documented
configuration
management
process,
individuals
currently
handling
configuration
management
functions
can
move
on
to
other
things
because
these
documented
functions
can
be
performed
by
other
individuals).
But
documenting
your
business
practices
(through
ADPE
elements
or
by
other
means)
itself
will
generally
not
make
SEE
implementation
happen.
People
will
need
to
be
offered
incentives
to
adapt
themselves
to
these
business
practices
(e.g.,
salary
raises
tied
to
the
degree
to
which
an
individual
can
demonstrate
that
he
or
she
has
followed
the
SEE
way
on
project
work).
4.
Make
the
CCB
your
process
focal
point
for
customer/seller
interaction.
At
the
outset
of
this
chapter,
we
reiterated
that
the
avenue
to
consistent
successful
software
systems
development
is
the
sustained
effective
communication
between
the
wizard
(i.e.,
software
seller)
and
the
king
(i.e.,
software
customer).
Chapter
4
detailed
how
the
CCB
is
a
mechanism
for
sustaining
this
communication.
Chapter
3
explained
how
the
CCB
serves
to
focus
project
activity.
A
CCB
mechanism
should
be
put
in
place
even
before
you
document
your
organization"s
software
systems
development
process.
Customer/seller
interaction
should
be
formalized
(via
a
CCB
mechanism)
at
project
outset—even
without
a
CCB
ADPE
element.
CCB
rules
can
be
stipulated
in
the
project
plan.
Lessons
learned
from
iterating
on
such
rules
during
the
early
stages
of
setting
up
an
SEE
can
be
folded
into
such
an
element
(to
be
promulgated
after
a
software
systems
development
process
ADPE
element
has
been
promulgated).
5.
In
a
small
organization
(say,
up
to
ten
people),
plan
for
packaging
the
ADPE
into
a
single
element,
with
each
section
addressing
what
in
a
larger
organization
would
be
a
separate
element.
A
consistent
way
of
doing
software
systems
development
business
is
independent
of
organization
size.
Thus,
documented
business
practices
have
a
place
in
small
as
well
as
in
large
organizations.
Because
the
number
of
communications
paths
among
individuals
is
much
less
in
small
organizations
than
it
is
in
large
organizations,
the
amount
of
documentation
needed
to
specify
these
practices
is
generally
much
less
in
small
organizations
than
it
is
in
large
organizations.
This
principle
should
be
applied
when
planning
SEE
implementation
for
a
small
organization.
However,
as
with
most
software
engineering
principles,
this
principle
is
not
inviolate.
In
some
cases,
it
may
be
necessary
to
have
voluminous
ADPE
elements
even
in
a
small
organization.
Such
would
be
the
case
if,
for
example,
a
small
organization
were
responsible
for
developing
software
systems
whose
failure
might
result
in
people
getting
killed,
suffering
injury,
or
sustaining
large
financial
loss.
Such
would
also
be
the
case
if
a
small
organization
were
developing
software
systems
under
a
fixed-price
contractual
vehicle.
In
this
case,
the
seller
might
sustain
large
financial
loss
if
the
way
of
doing
business
were
not
clearly
spelled
out
(particularly
if
the
seller
becomes
involved
in
litigation).
A
small
organization
might
also
need
voluminous
ADPE
elements
if
it
were
responsible
for
developing
warranted
software
systems
(for
example,
the
seller
would
be
responsible
for
repairing
or
replacing
computer
code,
databases,
and/or
documentation
for,
say,
up
to
one
year
after
purchase—at
no
cost
to
the
buyer).
6.
Include
in
your
plan
a
strategy
for
winning
people
over
to
the
ADPE
way
(e.g.,mentoring,
bonuses).
We
detailed
in
Chapter
7
how
ADPE
implementation
is
a
cultural
change
exercise.
A
realistic
SEE
implementation
plan
needs
to
include
a
strategy
for
winning
people
over
to
the
ADPE
way
by
(1)
accounting
for
people"s
natural
resistance
to
change,
(2)
building
upon
business
practices
that
may
already
exist,
and
(3)
encouraging
people
to
contribute
to
the
development
of
new
business
practices.
7.
Make
requirements
management
a
training
priority.
This
key
idea
is
a
corollary
to
the
message
in
the
wizard-and-king
comic
strip.
Requirements
management
is
the
number
one
challenge
industrywide
to
successful
software
systems
development.
If
it
does
nothing
else,
your
requirements
management
training
should
provide
guidance
on
how
to
institute
effective
oral
and
written
communication
between
the
wizard
and
king.
中文翻译
第八章
程序改进计划
没有小计划；他们没有魔力激起人们的热情，很有可能他们自己将不会被了解。制定大的计划；在愿望和工作上都要很高的标准，记住在我们离开以后一个重要而且合理的表格将不会死去，它将存在很长的时间，自己坚持成长。记住我们的子孙会质疑我们。让你的口令变成以你的指标的完美的命令。—丹尼尔.H.
Burnham
[(1846
–
1912),美国建筑师和城市规划师]是丹尼尔.Burnham在1910年伦敦城市规划会议前写在一张纸上的，被Burnham旧金山的合伙人威尔士.Polk发现。Polk用款圣诞卡伯纳姆在1912年逝世于该年6月.
-HenrySaylorH",没有什么计划,
"JournaloftheAmericanInstituteofArchitects,March1957,PP.
95-99
8.1
介绍
这章的目的是指导你如何写一个SEE的实施计划。用这个指导思想，你可以建立适合你自己的前章所学的知识结构。我们的方式是呈现并且讨论关键SEE实施问题。讨论的目标是让你具备如何为你的组织展开一个可行的SEE实施方案的能力。比如我们研究费用在哪一
ADPE
元件发展并实现。我们在这费用上描述对一些主要因数的影响（比如，你的组织管理人员和职员对软件和系统工程学经验等级)。这些因数应该帮助你对于你的组织是适当的计划一个
ADPE
发展和实施率。在我们提出程序进步计划之前，我们要先调查。图
8-1
提醒我们,如同我们在前面章中反复强调的一样,
一个的成功软件系统开发需要在软件卖方和软件客户之间的持续有效的通信。减少为最基本的周期，在这些章中被调查的观念和原则都有这个前提基本的前提。现在我们概述一下前面章节讲述的一些观念和原则。为了帮助你记忆，图
8-2
最亮区每章的主题。
图8-1在最基本的等级，一个成功的软件开发的途径是在精灵（卖方）和国王（软件客户）之间吃许有效的通讯（精灵的身分,1983年9月30日.
哈特和转载的许可约翰尼集团创股份有限公司）
图8-2千面章节所讲的为实现你的组织系统工程环境计划（SEE）方面考虑的事物本质。SEE的实施是一贯的创建成功软件系统开发结构化方法。本章整合了前面各章所述来指导你的SEE计划的实施。
?
第1章
(Business
Case)讲述了为什么当一个组织按自己的情况作软件开发能达到一个好的利润。本章还介绍了为书的其它部分创建功作词汇的主要观念（比如,
软件、软件程序、产品和程序
"
仁慈
"、耕种）。我们强调讲了有过失的通信位于多数的软件系统开发问题之下的客户/
卖方。我们强调软件程序的开发是首要的和一种文化改变的练习。我们介绍了必要的软件系统开发培训-
管理，开发和产品确保。我们介绍了变化控制板（CCB）是在一个软件系统开发各个部分之中的维持有效通信的一种机制。我们介绍的“约束应用程序”的概念，它是一个组织被人正的软件开发过程。我们解释了约束应用程序为什么是使程序组织化的关键之一。SEE也提供改进软件开发过程的手段。一贯的软件系统开发和软件改进都是这样围绕SEE的概念的。
?
第2章（工程计划过程）帮助你有效的规划软件系统开发的过程。我们提到的文件包含计划信息就像“工程计划”一样。我们指出工程计划在某种程度上用来度量，了解什么要去做，估计有多少工作量，决定软件系统开发是否按计划展开。我们强调了工程计划需要在客户（国王）和卖方（精灵）进行一格持续的协商工作。我们展示了如何在工程计划中插入CCB器使国王和精灵在整个工程中能够有效地互相进行联系。在进行详细任务分析时我们给出了生命周期的概念。为了说明这个知识点我们举了三个例子—（1）六步传统开发，（2）原型法开发，（3）（数据中心）信息工程学。我们还介绍了如何为一个必要的软件系统运营过程中的三个部分
—
经营，管理，客户服务设计一个低风险的经济分配方法
—
因此告诉你怎样明确地合并风险的减少项目预算。最重要的，我们教你怎么修改计划。我们组织了藉由表现你该如何发展一个定义你组织的计画规划程序的
ADPE
元件计划引导进一个简单易用软件包之内的这一个计画。我们举办这个项目规划为指导,简单易用的方案显示你如何建立ADPE因素确定贵组织的项目规划过程。
?
第3章（软件系统开发过程）确定剩下的规则。我们定义了定义一个软件系统开发过程的原则。我们介绍了运用这些原则创建一贯评价较好的的程序—就是客户需要，而且按时交付，在预算里面。为了帮助你应用这些原则，我们用插图的形式定义了一个最高层的程序，你可以从一个出发点开始你自己可以理解的组织来定义一个程序。我们再次强调最高层运用CCB这个关键要素来评定维持国王和精灵之间会话等级。我们强调,
大体上，程序不能够被转为有对一个明确的命令步骤的一个硬地定义的程序被依照。然而，我们强调了程序的规范应用程序是达成相容的软件系统开发的关键。程序必须讲述需要做什么；个人有理解如何去做的权利。我们还介绍了如何在顶层程序中插入明确地生命周期的说明，在程序申请阶段计划怎么展开。我们展示了如何设计一个表格跟踪产品的在整个软件系统开发过程中的环节。程序不能被停止甚至他已经交付使用。当把产品交付给顾客的责任，我们讨论了客户和开发的职责。我们折叠章的程序定义主意进一个简单易用软件包之内-即，一个被注解的大纲对于一个定义你的组织软件系统发展的
ADPE
元件处理。我们解释了这一个元件为什么是在你的
ADPE
上面开始置位的一个好位置。
?
第
4
章
(变化控制程序)
为维持在精灵和国王之间的有效通信和在精灵的职员之中把重心集中在如一个论坛的变化控制板
(CCB)
。我们为在
CCB上面置位提供指导给你你的软件系统开发处理。
我们也提供指导给管理非计划性的,
连同计划了的,变化。我们从而关闭了我们强调了你需要说明未知在你的方按计划和会计中解释未知数的在第
2
章中介绍的回路。第
4
章也关闭了在第
3
章中被介绍的回路,
强调,整合客户/
卖方
CCB
在你的软件系统发展程序中，你几乎发动客户的产品验收一个预定的事。我们教你该如何综合计划和非计划性的变化走过变化控制技巧。我们通过一个工程的生命周期解释了
CCB
的任务，我们断言控制所有的变化控制:
o
我们想要新的或不同的东西吗?
o
有什么不对吗?
o
应该是我们基线产品?
我们展示了在CCB会议上应该记录什么并且举出了CBB记录的例子。我们为选择一个
CCB
主席和
CCB
投票机制提供了指导。我们建议你领导决定当CBB有适当的层次，和怎么展示他们。我们为构造变化控制表格支援前面所讲的变化控制窗口给予了你详细说明引导。我们也举出了例子表格在应用这一个指导方面帮助你应用。我们表现你该如何发展一个定义你的组织变化控制板的ADPE元件组织CCB观念和指导进一个简单易用软件包之内。
?
第
5
章
(产品和程序评审)
把重点在评审需要进入正在偶然发现一个软件工程的东西中给可见性的产品和程序。为了建立章节中语境，我们断言了下列各项:
o
每个软件计划应该完全的实现它是通过航冰山患水(或更坏!)。
o
如果这态度被采用,然后常识和天然的本能对于自己的保存能引导只有一个结论-
一些方法一定被发现避免冰山对那延伸区审慎可能。
o
产品和程序评审是掌舵的技术冰山的清除。
我们定义了一个由以下产品和过程组成二维的分类评定法：
o
管理评审
??产品和处理节目的追踪
??产品和处理技术上的疏忽
o
发展评审
??产品和程序同等评审
??技术上编辑的软件和软件的描述文档
o
产品保证评审
??产品质量保证，确认再确认，测试再测试，还有自身比较
??在产品等级上的策划登记上保证程序质量
产品评审识别大致是和三章所讲定义顶层软件系统开发工程相同。工程评审时别是对产品评审的扩展。比如，对于管理，我们可以做出两种类型的评审—
节目追踪和技术上的疏忽—对于一种特定的产品和软件系统发展处理。
我们章节的组织是按照系统规则组织的。因为我们相信产品保证规则的应用为软件计划减少风险提供了最大的潜能，本章花了很大篇幅在产品保证和产品评审上。尤其是产品保证文档评审和接受测试贯穿本章。在这一本书中，接受测试组成软件系统开发的使用率处理精灵正式地对国王示范的地方软件系统而且支援数据库做他们应该做的哪里。接受测试因此是软件系统开发程序的底线。
因为这一个理由,
本章包括需求可测试性的详细讨论例子
因为评审不定址,(举例来说,
单位和集成测试)，本章给出扩充分类法包括的评审。帮助你应用在本章中提出评审指导，我们教你该如何为产品确保评审发展一个ADPE要素。我们讲了该如何把其他的产品和程序评审整合到这一个元件。因为同等评审通常被认为在软件系统开发中有重要意义，我们展示了如何对一个同等评审发展ADPE要素。
?
第6章（测量）为测量产品和程序“goodness”给你指导。借用数学的精确的矢量分析，我们定量了一个标示了“完整性的”空间矢量的长度“goodness”。产品或程序空间大小是我们所感兴趣的测定的属性。举例来说，对于我们可能想要测量客户需求是满意的程度一种产品及[或]是否交付准时，及[或]交付时是否在预算里面。对于工程，我们可能想要测量如是否执行了同等评审及[或]产品保证评审被执行及[或]在工程计划期间执行是否有评估的危险。我们举例说明该如何对属性建立数值标度并且为你的组织建立合理的数值标度给予指导。我们举例说明该如何测量需求约素的完整性，一本用户手册，计算机编码
,
和一个工程计划。我们举例说明了该如何测量在第
3
章中介绍的工程完整性。为帮助你应用本章的完整性测量方式
,
我们把它减少到少数的简单易作的步骤。这些步骤也帮助你该如何使程序完整性和产品完整性测量和彼此产生关联帮助你集中你的程序进步努力。产品/程序实际上呈现的完整性测量方式是几乎定量任何的事物非常一般的近似的方式。我们成这中方是为“事物测量”或OM。为了要在它的一般适用性暗示下,
我们为软件对软件工程协会的能力成熟度模型申请了OM（CMM?
对于软件）表示模型的主要程序区域
(KPAs)
可能如何被定量。我们也解释了OM能如何用来定量抽象的实质，像是策略的信息管理。
除了产品完整性和程序完整性测量之外,
我们展示如何建立被系到的其他程序-相关的测量一或较多元件软件系统发展处理。采取简单的方法是根据平均次数是涉及一系列活动或从事各种活动的组织工程。举例来说，我们定义了可能让一个组织是有用的为了估定程序可行性收集的下列测量:
o
必需生产被客户接受的待送货物的同等评审的平均数目（也就是客户返回对可以传送的形式指出的接受度“产品被认为是递送”）
o
百分比的待送货物准时为特定的计划在一个特定的周期期间递送给客户,
哪里“准时”是依照日期在工程计划或CCB数分钟中指定的交付。
o
必需生产一个造成一个工程的工程计划的草稿的平均数目。
o
卖方组织的客户感知。
我们展示你该如何发展一个定义你的组织产品和程序韵律学和你的应用他们改善你的软件
(-相关的)
产品和软件发展过程的组织达成的方式
ADPE
元件组织章的测量引导进一个简单易用软件包之内。
?
第
7
章
(文化的变化)
如工程学所反对把重心集中在人类与成功的软件系统开发有关的议题。来自下列的前章节收入，在经验方面将被废弃:
与其向在已有程序是挑战，不如向争取组织的人委托对变化挑战。人们委托为他们自己的理由改变,不管其他人理由。因此，当人被要求委托改变的时候,他们的第一关心可能是他们的感觉损失。
我们强调了
S.E.E
实施首先是一个文化的变化练习-性态修改的一种练习。就如我们在本章解释的,
这考虑很重地一发展忍受一现实的见到实施计划。成功的软件实施多是一种人们管理练习和不是一种工程管理练习。大部分时候我们做我们想做的（不管正在开发软件系统还是在刷牙），因为大部分时候我们用我们感到舒服的方式做事。信息科技应该因此不是惊奇劝在软件系统发展世界中的人做事物其他人方法（组织的方法）可能是使人畏缩的挑战-
含有由于惊奇的。
我们在引起组织的文化变化有责任的方面调查了角色因为写ADPE要素（程序工程学聚集）而且处理它他们被实现而且不断地被改良我们在做成员鉴定之对考虑提醒了你举止（发展中的软件系统的亲自参与的经验）。
我们讨论了该如何处理ADPE实施从精灵的将会必须适应在统治他们的工作ADPE元件中被发表的练习计划级的个体出现的挑战。在客户边上，我们讨论了该如何处理ADPE实施从那些把技术上的方向给精灵的工程经理的国王出现的挑战。在这一条血管中，我们讨论了该如何争取客户是ADPE实施的部份。我们也讨论了争取客户对ADPE实施，
连同卖方是有责任的职业者和骗局。
我们调查了那一个卖方年长者管理在透过ADPE实施产生软件系统发展文化的变化方面玩的主要角色。在另一边上，我们调查了在
ADPE
实施引起的客户年长者管理方面的冲击。
我们为了吸取来自ADPE要素的主要主意而且为如一个方法的对你组织的分配为产生文化的变化包装他们提供引导给你。（主要程序观念
,
像是被建立接受测试的需求显着地显示的泡沫板表现的使用）
我们讨论了在产生文化的变化方面教育的角色。尤其，我们强调了主要角色，对精灵和国王的ADPE元件简报职员在得到组织方面玩使需要工程性态同化。以在引起文化的变化方面教育的角色联盟,我们调查了良师而且训练的角色。
我们讨论了该如何卖如一个事业成长机会的ADPE实施。
我们看组织的因数生在它轮流引起文化的变化多久之上。
我们调查了一个亲切地定义ADPE要素发展和进步程序的ADPE要素为什么对组织的文化变化被系。
我们为一个定义ADPE要素发展和进步程序的ADPE要素给你一个被注解的大纲总结了章。这一个元件提供以首尾一致的样子进化ADPE架构。
从在这里你去哪里?
你如何集合来自前面的章节观念和引导对于一致的成功软件系统发展展开方式并且改善你已经有的?
就如图8-3指出的，这章被针对使你计划到实施接近。
图
8-3
这章对精灵提供计划引导而且成为君主因为在软件程序进步方式上面置位经由见到实施。本章帮助你选择来自前面章章节观念构造这方式。如这章所用的实施计划的观念意谓
“任何事从被擦到一个多音量在包封的背面上正式的和高度详细的文件注意-不论什么为你的组织有道理”为最简单的期限,
在这章中计划意谓“在做之前想而且协调”。
我们在这章为精灵和国王想要的着手强调。如果你是精灵,
这章将会帮助你回应的国王请求一个躺卧的精灵在波动手的但是在置位方面躺卧谎言在而且上面跟随一致地用完整性产生产品的程序。(理想地，你应该没有等候国王为做的可重复方法问你生意)
如果你是国王,
这章将会帮助你
(1)
构造
SEE
实施方式在对提议
(RFP)
的请求中包括，你想要一个你想要雇请跟随或
(2)
把在
RFP
的引导给一个你想要雇请构造的精灵一见到实施接近在精灵的提议中包括或
(3)
把引导给一个你已经雇用了构造的精灵一见到实施接近。
当图
8-3
指出,"
实施计划"如这章所用跨越一个宽广的光谱。当注意在包封的背面上潦草地书写标明一把事物的时候，资讯科技可能是某事如非正式的需要是完成在
SEE
里面建立而且操作
在文件编写光谱的另一端，“实施计划”可能是一个多音量册（因为,说,和主要的软件内容的一个大的系统发展努力,
或为一个大的组织处理五十对一些百或更多的同时发生软件系统发展努力）。或者"
实施计划
"
可能是某事在这二种文件编写极端之间。无论它在哪里在光谱中躺卧,计划的目的是为在做软件系统发展生意的一致方法上面置位进入相同的坐标之内在一个组织里面带来有关的团体。
这章视为关于的指南帮助你把你的方法工作回先前介绍的主意把他们整合到一为你的组织调查实施接近那有道理。
当展开实施方式的时候，既然我们不知道你的组织明细，这章藉由给你因数考虑跳跃你的思考。
举例来说，我们给你事物考虑生在
ADPE
元件应该被更新地多时常之上以便你能在你的实施中包括计划一种元件更新时间表。
8.2
SEE
计划实施主要思想
图8-4列出了列出你能期待从这章学到的主要思想。为了介绍这章给你，我们简短地解释这些主要思想。当你阅读完本章的时候，他们的完整意图将会变成明显。
图
8-4
这里是一些这章中用到的关于工程开发计划的重要概念。这些主要主意是关于指导SEE计划实际的实施。一个实际SEE
实施计划帮助集中你的向和谐的成功软件系统开发的方向努力。实际地在这章中计划意谓“用某种方法去激发人们（1）克服困难的决心（2）实现SEE业务的实施。”
1.
用在ADPE要素中被定义的事件执行计划你的工程开发。你的SEE实施计划应该计划一个元件逐渐采用策略,由你定义的软件系统发展程序的第一个元件。
正如我们在第3章中所讲的,这一个元件为大部分或全部由其他
ADPE
元件建立环境。软件系统开发共成元件如此是它本身关于后来的ADPE发展的计划。任何的SEE应该至少包括这一个元件。
2.
SEE实施的主要目的是建立组织广泛的惯例不依赖那些成功个人。
这一个目的不应该被误解。
为成功的软件系统发展除去依赖特别的个体不意谓那见到实施被设计工作使人恼怒。
好人确定地被需要达成成功的软件系统发展。
建立组织-
广泛的生意练习的意图是插入所有的这些人进做事物的一致方法之内,
所以在任何的给定日子好工作将会谁正在做工作被做无论。
这些生意练习杠杆式投机横过组织的人仁慈，而且帮忙提供专业的活动性给他们。
举例来说，第
4
章表示了该如何建立一个统治组织的
CCB
会议的
ADPE
元件。
明确地，我们解释了这一个元件能如何用来为置位叙述
organizationwide
练习在,上面引导,
而且证明
CCB
会议。
这些练习允许
CCB
会议同样地在任何的给定日子上被引导而且证明，他们在任何其他的日子上被引导而且证明-无论谁正在引导和证明他们。好人是，当然，需要使这些会议值得花时间-那是,
在软件计划工作上帮助携带过。
3.
包装一个包的你工程环境包含你的ADPE元件和事物的相关对你的技术环境。
把一个包拷贝给你的组织每个成员。
除非SEE进入你的组织人手，否则SEE实施不能开始。一个标准的方法发布ADPE元件而且当一个人参加你的组织时候，联合的技术环境是把这一个事物放在一个包
(影印本或电子的)而且给你的组织每个成员一个拷贝。包扎也应该包含SEE观念的一种解释和包含对你的组织事物目的的这一项观念的联系。
信息科技也应该为包接受者适应对特定的工程内容工作是完成的包含指令。如，每个包扎物应该为计划有空间
特定的事物如此的如一个客户的拷贝工作(SOW)和计划统治那个接受者的工作计划的指述。你的组织应该为送SEE更新给包接受者建立程序。
当然，包装一个包的SEE和把包拷贝给你的组织每个成员不在包中事务处理中发生。在其他的事物之中，你的组织应该建立一个描绘每个个体(1)负责读它的内容,(2)跟随在其中被证明的练习,(3)和你的组织客户促进这些练习的政策。
为了使这一个政策发生，你将会需要提供培训和激励。培训应该针对解释工程原则的事物在下面的ADPE元件，和数值跟随练习增加；培训也应该强调，因为个体不是特别的计划一个附加功能，跟随练习提供个别的事业成长机会。(比如藉由被证明的配置管理程序,
现在操作的个体配置管理功能转移至其他的事物，因为这些证明功能能被其他个体执行)但是证明练习(透过ADPE元件或藉着其他方法)本身通常将不制造的你生意见到实施发生。人们将会需要被提供激励使他们自己配合这些生意练习(比如薪水举起系达到度到个体能示范他或她已经跟随在计画上的SEE方法工作)。
4.
对于客户/卖方相互作用使
CCB
成为你的程序焦点的点。
在这章的着手，我们反复地说了一贯的成功软件系统开发的途径是在精灵(软件卖方)和国王(软件客户)之间的持续有效的通信。在第4章被详细说明的CCB是维持这一个通信的一个机制。第3章解释如何CCB服务集中计划使用率。在你证明你的组织软件系统开发工程之前，一个CCB机制应该被适当地放置。客户/卖方相互作用应该在工程着手被使正式(经由一个CCB机制)甚至没有一个CCB
ADPE元件。CCB规则能在工程计划中被规定。从反复在SEE的课上面学习置位的早级期间在如此的规则上能进入一个如此元件之内被折叠(在一个软件之后被发布哪一系统开发处理ADPE元件已经被发布)。
5.
在一个小的组织(十个人组成)中,包装ADPE进一个单一元件内的工程,等同于
在一个较大的组织中会是一个分开的元件每区段阐述。
做软件系统开发的一贯方法与组织大小无关。因此，证明事物练习有一个位置在小的连同在大的组织中。因为在个体之中的通信路径的数目在小的组织中比在大的组织中少得多，比较它是在大的组织中，被需要叙述这些练习的文件编写的数量在小的组织中是通常更加少。当为一个小的组织计划SEE实施的时候，这一项原则应该被应用。然而，关于大多数的软件工程原则，这一项原则被遵守。在一些外壳中，甚至在一个小的组织中可能有较多的必要ADPE元件。如此的会是外壳，比如说，一个小的组织负责可能造成风险，蒙受损失，或维持大的财政损失的人发展中的软件系统。如此的也会是外壳如果一个小的组织正在发展软件系统在一之下固定的
价格契约的上。如果做事物处理的方式不清楚，在这情况，卖方可能维持大的财政损失。(特别地如果卖方在诉讼中变成有关)如果它负责发展中的保证软件系统，一个小的组织也可能需要较多的ADPE元件(卖方会负责修理或更换计算机编码，数据库及[或]
文件编写因为,说,在购买后达到一年-
在没有费用对买主)。
6.
在你的计划中为得成绩优秀的人包括一个策略在之上到ADPE方法（比如，良师、奖金)
我们在第7章中详细说明ADPE实施如何是一种文化的变化练习。一个现实的SEE实施计划需要包括一个策略因为得胜的人在这之上到计划的ADPE方法对于天然的抗拒改变,(2)在生意之上建筑练习那可能已经存在,(3)鼓励人成为新生意练习的发展因素。
7.
使需求管理成为一个培训优先次序。
这主要主意是对精灵的信息一个系和国王连环图画脱去。需求管理是对成功的软件系统发展的第一大挑战
industrywide。如果它无其他事做，你的需求管理教育应该在该如何创立在精灵和国王之间的有效口试和书面的通信之上提供指导。
摘要
自20世纪70年代以来，数据库技术得到迅速发展，目前世界上已经有数百万个数据库系统在运行，其应用已经深入到社会生活的各个领域。21世纪以来，随着网络技术的逐渐完善，WEB已经成为Internet中最流行、最主要的信息交流方式。计算机技术的飞速发展也促进了软件开发技术的深刻变化。为摆脱软件危机，软件工程学——从60年代末期开始迅速发展起来，现在已成为计算机科学技术的一个重要分支。20世纪90年代以来，软件工程不仅从方法论的角度为管理人员和开发人员提供可见的结构和有序的思考，而且大量的成功软件总结出的设计经验，使软件开发人员可以充分利用设计模式、框架和部件等。本系统为B/S系统，通过ASP.NET技术与VB.NET语言相结合，实现了电子客票的基本功能，系统可以完成用户信息管理、客户的电子客票的定购、客户订购的管理、管理员对航班信息的管理。并利用上述技术实现了本系统的基本功能，最后在对各模块进行测试的基本上完成了对整个系统的综合测试。通过测试，本系统可以给用户提供一个方便的预定换环境。但系统的一些安全性有待完善，一些扩张功能还需完善。
关键词：电子客票；预订；用户管理。
Electronic
Tickets
Online
Ordering
System
Design
and
Development
Author:
Wu
Jiawei
Tutor:
Xue
Songdong
Abstract
Since
the
1970s,
the
rapid
development
of
database
technology,
the
world
has
a
one
million
database
system
in
operation,
its
use
has
expanded
in
all
fields
of
social
life.
21st
century,
with
the
gradual
improvement
of
network
technology,
Web
has
become
the
most
popular
Internet,
the
most
important
exchange
of
information.
The
rapid
development
of
computer
technology
has
also
contributed
to
the
profound
changes
in
software
development
technology.
Free
software
for
crisis
software
engineering
--
from
the
late
1960s
began
to
develop
rapidly,
and
now
has
become
an
important
branch
of
computer
science
and
technology.
Since
the
beginning
of
the
1990s,
software
engineering
methodology
not
only
from
the
perspective
of
managers
and
staff
that
the
development
of
the
structure
and
orderly
thinking,
but
a
lot
of
successful
experience
in
software
design
lessons
for
software
development
personnel
can
take
full
advantage
of
design
patterns,
frameworks
and
components.
B/S
system
to
the
system
through
ASP.NET
and
VB.NET
language
technology
through
a
combination
of
the
basic
functions
of
electronic
passenger
tickets,
the
system
can
complete
user
information
management,
customer
electronic
passenger
tickets
shall
purchase,
and
customer
orders
management,
manager
of
flight
information
management.
And
the
use
of
the
technology
to
achieve
the
basic
functions
of
the
system,
in
the
final
testing
of
the
module
essentially
completed
a
comprehensive
test
of
the
entire
system.
Through
testing,
the
system
will
give
users
a
convenient
target
for
the
environment.
Keyword:
electronic
passenger
tickets;
Booking;
User
management.
目录
第一章
电子客票系统概论
1
1.1
系统开发背景
1
1.2
系统简介
2
1.2.1
系统产生的背景
2
1.2.2
系统开发的意义
2
1.3
系统的特点及实现目标
3
1.3.1
系统的特点
3
1.3.2
系统的实现目标
3
1.4
可行性分析
3
第二章
相关理论与关键技术介绍
5
2.1
软件工程
5
2.2
HTML简介
6
2.3
ASP.NET技术
6
2.3.1
ASP.NET的功能和特点
7
2.3.2
ASP.NET的工作原理
7
2.3.3
ASP.NET的开发工具
7
2.3.4
ASP.NET的运行环境
7
2.4
WEB数据库技术
8
2.4.1
WEB数据库应用及结构
8
2.4.2数据库访问
8
第三章
电子客票系统需求分析
10
3.1系统的功能需求
10
3.2开发与运行环境的选择
12
3.2.1软件要求
12
3.2.2硬件要求
12
3.2.3开发系统硬件配置
12
3.3数据流图及其描述
13
3.4状态转换图
14
3.5数据字典
15
3.6
E-R图
15
3.6.1系统E-R图
15
3.6.2各实体属性
16
3.6.3各实体间的约束
16
第四章
总体设计
17
4.1系统设计
17
4.1.1
系统设计的目标
17
4.1.2
系统结构分析
18
4.1.3各子模块功能详细说明
18
4.2数据库的设计
18
4.2.1数据库系统
18
4.2.2数据库管理系统
19
4.2.3
数据库的连接
21
第五章
系统详细设计及编码实现
22
5.1一般用户模块设计
22
5.1.1用户登陆及用户注册界面
22
5.1.2用户预定、付款、推定界面
25
5.1.3用户资料管理界面
30
5.2
系统管理模块设计
34
5.2.1管理员登陆界面
34
5.2.2
客机信息管理
34
5.2.3
航班信息管理
37
5.2.4
管理员管理界面
40
第六章
系统测试
42
6.1
测试理论
42
6.2具体测试实例
43
结束语
48
致
谢
49
参
考
文
献
50
附录I
51
电子客票系统毕业论文 本文关键词：毕业论文，电子客票，系统
电子客票系统毕业论文 来源：网络整理
免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
《
电子客票系统毕业论文》
由：
76范文网互联网用户整理提供,链接地址：
http://m.yuan0.cn/a/84206.html
免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。