ASP.NET电子客票系统
第一章 电子客票系统概论
从实际方面来看，随着网络技术的日益普及，特别是现阶段我国机票预定和销售系统相对比较落后，还处在纸质机票阶段，对机票预定程序先对繁琐。去年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所示
ASP.NET电子客票系统
查询航班
用户登录
可选择航班信息
航班数据库
选择要预定的航班
用户信息
预定机票信息显示客户信息填写界面
网上支付
机票预定数据库
图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)。
ASP.NET电子客票系统
.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
ASP.NET电子客票系统
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 航线信息表
ASP.NET电子客票系统
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.Click
If 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()
ASP.NET电子客票系统
图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所示。
ASP.NET电子客票系统
图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 修改密码
代码：与用户修改密码相似这里略去。
ASP.NET电子客票系统
第一章 系统测试
本章主要进行系统的测试，经过上述对系统的分析、设计和编码后，应对系统进行详细的测试，这是软件投入使用前尽可能多的发现软件中的错误，并对错误进行修改，以达到系统在正式运行时性能等各方面状况良好。
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环境下编写、调试程序的能力有了明显提高，并在整个设计开发过程中掌握了许多解决问题的方法。使得自己得到了很好的锻炼，利用软件工程的思想进行系统的需求分析和设计、运用正确的设计方法，结合管理系统设计知识，提高系统设计实践能力，完成了对系统用户管理、航班搜索和客户预订航班、用户登机功能。理解了开发一个完整的系统是通过软件之间的相互协调工作支撑的。同时在这次论文的写作中，我也全心的投入，争取把自己学习到的最好的方面展示给所有的人。但今后系统还需要进一步完善，要做的工作还很多，这些只是实现了模块的简单功能，并没考虑其复杂功能，这需要今后去设计实现。
毕业设计，是一次很好地提高实践能力和自我发展能力的机会，我们可以综合运用所学专业知识分析、解决问题。为今后的研究开发工作打下了基础，积累了难得的宝贵经验，使我受益非浅。
ASP.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://www.goldenholiday.com/。黄金假日网站。北京：北京黄金假日旅行社有限公司。
[9] URL: http://eticketgroup.cs-air.com/。南方航空电子客票系统。
ASP.NET电子客票系统
附录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.
ASP.NET电子客票系统
中文翻译
第八章 程序改进计划
没有小计划；他们没有魔力激起人们的热情，很有可能他们自己将不会被了解。制定大的计划；在愿望和工作上都要很高的标准，记住在我们离开以后一个重要而且合理的表格将不会死去，它将存在很长的时间，自己坚持成长。记住我们的子孙会质疑我们。让你的口令变成以你的指标的完美的命令。—丹尼尔.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。如果它无其他事做，你的需求管理教育应该在该如何创立在精灵和国王之间的有效口试和书面的通信之上提供指导。
ASP.NET电子客票系统
摘要
自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.
