医院预约挂号系统的设计与实现

来源：叨叨游戏网

[标签:标题]

学士学位论文

题目：医院预约挂号系统的设计与实现

设计人：指导教师：所属系部：专业班级：

2011年 6 月 10 日

页脚内容1

[标签:标题]

中文摘要

随着计算机的发展，越来越多的行业实现了管理的信息化和自动化，医务行业也不例外。在很多医院中，挂号作为医院工作中最重要的一个环节还没有完全实现信息化管理，因此本系统选择医院预约挂号为研究对象，以实现网上预约挂号、缓解医院现场挂号难、提高医院工作效率为目标。

本次设计采用ASP.NET和SQL Server 2005为开发工具，并结合软件工程的设计思想，以B/S为模式设计并实现了医院预约挂号系统，实现了患者的预约、查询以及管理员对预约信息的管理等功能。

医院预约挂号系统有着很好的应用前景，用它来代替医院现场挂号，实现患者看病挂号网络化是一个必然趋势。随着计算机技术和网络技术的发展，它的功能将会得到不断的发展和完善。

关键词：预约挂号；ASP.NET；SQL Server 2005；B/S

页脚内容I

[标签:标题]

Hospital appointment registering online system

Author:Sun Zhenhua Tutor:Hu Jing

Abstract

With the development of computer technology, more and more industries have realized the informatization and automation of the management, medical industry has no exception also. But in many hospitals, registering, as a very important aspect of hospital work, has not fully achieved information management. Therefore, this system choose the hospital registering as the research object, in order to achieve registering on the internet, reduce the difficulty of registering in hospital and improve work efficiency in hospital.

The design uses ASP.NET and SQL Server 2005 as development tool, combined with software engineering design, to B/S for the model to achieve the hospital appointment registering system, to achieve the appointment, inquires of patients, to achieve the manegement of appointment information and so on.

Hospital appointment registering online system has a good prospect, it can be used to replace the traditional manual registering, achieving registering online for patients is an inevitable trend. With the development of computer technology and network technology, its functions will develop and improve continuosly.

Key words: Appointment registrating; ASP.NET; SQL Server 2005; B/S

页脚内容II

[标签:标题]

ABSTRACT .......................................................................................................................................................... II 第一章系统概述 ................................................................................................................................................... 1 1.1项目开发的背景和意义 ............................................................................................................................... 1 1.1.1项目开发背景 ........................................................................................................................................ 1 1.1.2项目开发意义 ........................................................................................................................................ 1 1.2项目开发环境 ............................................................................................................................................... 2 1.2.1硬件环境 ................................................................................................................................................ 2 1.2.2软件环境 ................................................................................................................................................ 3 1.3系统体系结构 ............................................................................................................................................... 3 1.3.1传统的C/S结构特性 ............................................................................................................................ 3 1.3.2 B/S结构的特性 ..................................................................................................................................... 3 1.4开发工具介绍 ............................................................................................................................................... 4 1.4.1开发工具介绍 ........................................................................................................................................ 4 1.4.2 C#语言 ................................................................................................................................................... 7 1.4.3 SQL Server 2005 ................................................................................................................................. 7 1.5系统开发方法 ............................................................................................................................................... 8 1.6本文所做的主要工作 ................................................................................................................................... 9 1.7本文结构安排 ............................................................................................................................................... 9 第二章需求分析 ................................................................................................................................................. 10 2.1可行性分析 ................................................................................................................................................. 10 2.1.1技术可行性 .......................................................................................................................................... 10 2.1.2操作可行性 .......................................................................................................................................... 10 2.1.3经济可行性 .......................................................................................................................................... 10 2.2任务概述 ..................................................................................................................................................... 10 2.2.1任务目标 .............................................................................................................................................. 10 2.2.2用户特点 .............................................................................................................................................. 11 2.3功能描述 ..................................................................................................................................................... 11 2.4数据描述 ..................................................................................................................................................... 11 2.4.1 数据流图 ............................................................................................................................................. 11 2.5数据字典 ..................................................................................................................................................... 14 2.6 E-R图 ......................................................................................................................................................... 15 2.7需求规定 ..................................................................................................................................................... 17 2.7.1功能需求 .............................................................................................................................................. 17 2.7.2 性能需求 ............................................................................................................................................. 18 2.7.3 运行需求 ............................................................................................................................................. 18 2.7.4其它需求 .............................................................................................................................................. 18 第三章总体设计 ................................................................................................................................................. 20 3.1总体设计原理 ............................................................................................................................................. 20

页脚内容III

[标签:标题]

3.2系统功能模块设计 ..................................................................................................................................... 21 3.3功能分析 ..................................................................................................................................................... 22 3.4数据库设计 ................................................................................................................................................. 23 3.4.1数据项定义 .......................................................................................................................................... 23 第四章详细设计与编码实现 ............................................................................................................................. 25 4.1程序流程图 ................................................................................................................................................. 25 4.2编码与实现 ................................................................................................................................................. 29 4.2.1管理员、专家登录界面及其相关代码 .............................................................................................. 29 4.2.2患者预约界面及其相关代码 .............................................................................................................. 31 4.2.3患者选择预约科室界面及其相关代码 .............................................................................................. 32 4.2.4患者查询界面及其相关代码 .............................................................................................................. 33 第五章网站测试及维护 ..................................................................................................................................... 34 5.1测试目的 ..................................................................................................................................................... 34 5.2测试方案 ..................................................................................................................................................... 34 5.3项目测试 ..................................................................................................................................................... 34 5.4综合测试 ..................................................................................................................................................... 35 5.5网站维护 ..................................................................................................................................................... 35 结束语 ................................................................................................................................................................... 37 致谢 ....................................................................................................................................................................... 38 参考文献 ............................................................................................................................................................... 39 附录 ....................................................................................................................................................................... 40

页脚内容IV

[标签:标题]

第一章系统概述

1.1项目开发的背景和意义

1.1.1项目开发背景

Internet最早在美国出现，如今，世界各国纷纷加入到这个行列，使Internet成为全球化的网际网络。随着用户的不断增加，其规模迅速扩大，它的领域也走向了多元化。除了原先的科学技术和教育外，Internet已进入了文化、经济、政治、体育、娱乐、商业和服务业。可以预见，Internet将为我们构筑未来崭新的生活方式。

随着计算机技术的飞速发展，计算机在系统管理中的应用越来越普及，利用计算机实现各个系统的管理显得越来越重要。对于一些大中型管理部门来说，利用计算机支持管理高效率完成日常事务的管理，是适应现代管理制度要求、推动管理走向科学化、规范化的必要条件。我国由于人口多，进而带来医院看病难的问题，由于人口众多，需要排队进行挂号，这样会浪费患者的时间，而且医院的效率也不高。患者挂号是一项琐碎、复杂而又十分细致的工作，患者数量之庞大，一般不允许出错，如果实行手工操作，每天挂号的情况以及挂号时间等须手工填制大量的表格，这就会耗费医院管理工作人员大量的时间和精力，患者排队等候时间长，辗转过程多，影响了医疗的秩序。如何利用现代信息技术使企业拥有快速、高效的市场反映能力和高效率，已是医院特别关心的问题。尽快建立一个医院预约挂号系统，完善现代医院的信息化管理机制，已成为医院生存发展的当务之急。所以，建立网上预约挂号系统势在必行。

本系统以医院为背景，在认真调研和分析了医院的现状之后，根据用户的需求和各个功能的关系，作出了积极的设计方案。在新的管理资源和管理模式上，一定能使工作质量、工作效率等得到提高，推动医院发展的步伐。 1.1.2项目开发意义

随着科学技术的不断提高，计算机科学技术日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域并发挥着越来越重要的作用。

计算机具有手工管理所无法比拟的优点，例如：检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高管理的效率,也是管理行业的科学化、正规化管理，与世界接轨的重要条件。

页脚内容1

[标签:标题]

开发医院预约挂号系统，使患者就诊系统化，规范化，自动化，从而达到提高管理效率的目的。本系统开发设计思想是实现患者预约挂号的数字化。尽量采用现有软硬件环境，及先进的管理系统开发方案，提高系统开发水平和应用效果的目的；系统应符合医院管理的规定，满足日常管理的需要，并达到操作过程中的直观，方便，实用，安全等要求；系统采用模块化程序设计方法，这样既便于系统功能的各种组合，又便于未参与开发的技术维护人员补充，维护；系统应具备数据库维护功能，及时根据用户需求进行数据的添加，删除，修改等操作。

网上预约挂号系统是一种基于互联网的新型挂号系统，是卫生信息化建设的最基础项目之一。利用该预约挂号系统，患者就可以在家里预约医院的专家，而无需受排队之苦。它能更好的改善就医环境，简化就医环节，节约就医时间，真正体现了一切以病人为中心，一切从方便患者出发，符合当今医院人性化服务温馨服务的理念。目前，门诊一直是阻挠医院提高服务质量的一个复杂环节，特别是医疗水平高、门诊量大的医院。而造成门诊量难以提高的因素主要有两个方面：一是集中式挂号，就诊人员流量不均，具有不确定性，有明显的就诊高峰和低谷。高峰期患者挂号排队长，就诊时间长，医生熟人插号现象，环境拥挤混乱，医生就诊时间短、不仔细、服务差。而低谷期，医生无患者可看，医院资源浪费。二是专家号难挂，特别是名专家，会出现倒号、炒号现象，严重损害患者利益，影响医院的声誉。而采用网上预约挂号，可有效解决这一现象，通过网上有效的身份验证，杜绝倒、炒专家号的现象，提高医院门诊服务质量，取得良好的社会效益和经济效益。此外，患者到医院就诊前对医院的相关信息了解不多，对所要挂的专科医生的情况不太了解，只能凭经验和印象进行选择，具有较大的盲目性。而当医院开通网上预约挂号服务以后，求医者只需坐在家中轻点下鼠标，就可以挂上医院专家门诊号，可以做到“足不出户选医生”。网上预约正悄然改变着求医者的看病观念。所以，预约看病应用将越来越广泛。

1.2项目开发环境

1.2.1硬件环境

处理器：Pentium 1GHz处理器或更高性能产品内存：至少512MB或更高硬盘空间：至少120GB以上硬盘容量

页脚内容2

[标签:标题]

网络设备：10M/100M全双工以太网卡或更高性能网络设备 1.2.2软件环境

操作系统：Microsoft Windows XP 开发工具：Microsoft Visual Studio 2005 设计工具：Microsoft Office Word 2003 数据库：Microsoft SQL Server 2005

1.3系统体系结构

1.3.1传统的C/S结构特性

C/S模式数据的存取和处理主要依赖于客户端程序，本地化的程序配制复杂(如必须配制本地ODBC或固定服务器机器名等)，逐台配置机器对于一个拥有多用户的复杂系统而言，工作量较大，维护成本高；而应用程序由于需要经常更新，因此逐台更新的问题比较复杂。

1.3.2 B/S结构的特性

B/S（Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本。

以目前的技术看，局域网建立B/S结构的网络应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。最大的缺点是对企业环境依赖性太强，由于各种原因引起企业中断都会造成系统瘫痪。

随着Internet和WWW的流行，以往的主机/终端和C/S都无法满足当前的全球网络开放、互连、信息随处可见和信息共享的新要求，于是就出现了B/S型模式，即浏览器/服务器结构。B/S模式最大特点是：用户可以通过WWW浏览器去访问Internet上的文本、数据、图像、动画、视频点播和声音信息，这些信息都是由许许多多的Web服务

页脚内容3

[标签:标题]

器产生的，而每一个Web服务器又可以通过各种方式与数据库服务器连接，大量的数据实际存放在数据库服务器中。客户端除了WWW浏览器，一般无须任何用户程序，只需从Web服务器上下载程序到本地来执行，在下载过程中若遇到与数据库有关的指令，由Web服务器交给数据库服务器来解释执行，并返回给Web服务器，Web服务器又返回给用户。在这种结构中，将许许多多的网连接到一块，形成一个巨大的网，即全球网。而各个企业可以在此结构的基础上建立自己的Internet。

B/S 结构对用户的技术要求比较低，对前端机的配置要求也较低，而且界面丰富、客户端维护量小、程序简单、更新维护方便．它容易进行跨平台布置，容易在局域网与广域网之间进行协调，尤其适宜信息发布类应用。采用B/S 形式，则只需在服务器上安装相应的服务程序和脚本程序，客户端就可以凭借网络浏览器通过Internet 访问服务器并进行相关的操作，而不需其它特殊要求。也就是说客户端只要能和服务器连接即可。这样就使得查询甚至控制系统变得非常方便，可以说是随时随地。

B/S的维护和升级方式比较简单。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级的方式是“瘦”客户机，“胖”服务器。

C/S 结构与B/S 结构各有利弊，综合考虑各种因素和系统的需求最终选用三层B/S 结构来实现本系统，即客户层、应用逻辑层(Web 层和应用层)和数据库服务层。

1.4开发工具介绍

1.4.1开发工具介绍

ASP.NET是一项功能强大、操作灵活的新技术，用于编写动态Web网页。ASP.NET是Microsoft公司的ASP和.NET Framework这两项核心技术的结合。ASP在Web计算机方面已有较长的历史，它所提供的用于创建动态Web页面的强健、快速、有效的方

页脚内容4

[标签:标题]

法已经有7年以上的历史。.NET Framework则是一整套新技术，Microsoft公司推出此技术的目的是改革未来在所有编程开发中所采用的方法，以及各公司从事业务活动的方法。因此，ASP.NET是利用,NET Framework提供的新功能来创建动态Web页面的一种方法。ASP.NET是建立在公共语言运行库上的编程框架，可用于在服务器上生成强大的Web应用程序。[1]

ASP.NET是目前主流的网络开发技术之一，具有许多优点和新特性，具体介绍如下：

1.增强性性能

ASP.NET是在服务器上运行的编译好的公共语言运行库代码。与被解释的前辈不同，ASP.NET可利用早期绑定、定时编译、本机优化和和盒外缓存服务，这相当于在编写代码行之前便显著提高了性能。

2.世界级的工具支持

ASP.NET Framework 补充了Visual Studio 集成开发环境中的大量工具箱和设计器。例如WYSIWYG编辑、拖放服务器控件和自动部署就是这个强大的工具中所提供的几种。

3.威力和灵活性

由于ASP.NET基于公共语言运行库，因此Web应用程序开发人员可以利用这个平台的威力和灵活性。.NET Framework 类库、消息处理和数据访问解决方案都可从Web无缝访问。ASP.NET也与语言无关，所以可以选择最适合应用程序的语言，或跨多种语言分割应用程序。另外，公共语言运行库的交互性保证在迁移到ASP.NET时保留基于COM的开发中的现有投资。

4.简易性

ASP.NET使执行常见任务变得容易，从简单的窗体提交和客户端身份验证到部署和站点配置。例如，ASP.NET页框架可以生成将应用程序逻辑与表示代码清楚分开的用户界面，和在类似Visual Basic的简单窗体处理模型中处理事件。另外，公共语言运行库利用托管代码服务简化了开发。

5.可管理性

ASP,NET采用基于文本的分层配置系统，简化了将设置应用于服务器环境和Web应用程序。由于配置信息是以纯文本的形式存储的，因此可以在没有本地管理工具帮助

页脚内容[标签:标题]

的情况下应用新设置。此“零本地管理”哲学也扩展到了ASP.NET Framework应用程序的部署。只需要将必要的文件复制到服务器，即可将ASP.NET Framework应用程序部署到服务器。不需要重新启动服务器，即使是在部署或替换运行的编译代码。

6.可缩放性和可用性

ASP.NET在设计时考虑了可缩放性，增加了专门用于在聚集环境和多处理器环境中提高性能的功能。另外，进程受到ASP.NET运行库的密切监视和管理，以便当进程行为不正常时，可就地创建新进程，以帮助保持应用始终可用于处理请求。

7.自定义和扩展性

ASP.NET随附了一个设计周到的结构，它是开发人员可以在适当的级别“插入”代码。实际上，可以用自己编写的自定义组件扩展或替换ASP.NET运行库的任何子组件。实现自定义身份验证。

8.安全性

借助内置的Windows身份验证和基于每个程序的配置，可以保证应用程序是安全的。

当一个HTTP请求到服务器并被IIS接收到之后，IIS首先通过客户端请求的页面类型为其加载相应的.dll文件，然后在处理过程中将这条请求发送给能够处理这个请求的模块。在ASP.NET 3.5中，这个模块叫做HttpHandler（HTTP处理程序组件），之所以.aspx文件可以被服务器处理，就是因为在服务器端有默认的HttpHandler专门处理.aspx文件。IIS在将这条请求发送给能够处理这个请求的模块之前，还需要经过一些HttpModule的处理，这些都是系统默认的Modules（用于获取当前应用程序的模块集合），在这个HTTP请求传到HttpHandler之前要经过不同的HttpModule的处理。这样做的好处，一是为了一些必需的过程，二是为了安全性，三是为了提高效率，四是为了用户能够在更多的环节上进行控制，增强用户的控制能力。

通常情况下，ASP.NET框架搭建在Windows Server（服务器版操作系统）+IIS（Web服务器，是Internet信息服务管理器的英文缩写）环境中，在安装.NET Framework时，安装程序将会在IIS中注册ASP.NET所需的ISAPI扩展（aspnet_isapi.dll），这就使得作为ASP.NET宿主的IIS在接收到客户端的HTTP请求后，将响应请求的控制权交给ASP.NET运行。

页脚内容[标签:标题]

1.4.2 C#语言

C#是微软公司发布的一种面向对象的、运行于.NET Framework之上的高级程序设计语言。C#是微软公司研究员Anders Hejlsberg的最新成果。C#看起来与Java有着惊人的相似；它包括了诸如单一继承、接口、与Java几乎同样的语法和编译成中间代码再运行的过程。但是C#与Java有着明显的不同，它借鉴了Delphi的一个特点,与COM(组件对象模型)是直接集成的，而且它是微软公司.NET windows网络框架的主角。

C#是一种安全的、稳定的、简单的、优雅的，由C和C++衍生出来的面向对象的编程语言。它在继承C和C++强大功能的同时去掉了一些它们的复杂特性（例如没有宏和模版，不允许多重继承）。C#综合了VB简单的可视化操作和C++的高运行效率，以其强大的操作能力、优雅的语法风格、创新的语言特性和便捷的面向组件编程的支持成为.NET开发的首选语言。 1.4.3 SQL Server 2005

使用SQL Server 2005，开发人员通过使用相似的语言，例如微软的Visual C# .NET和微软的Visual Basic，将能够创立数据库对象。开发人员还将能够建立两个新的对象——用户定义的类和集合。开发人员将能够在数据库层开发Web服务，将SQL Server当作一个超文本传输协议（HTTP）侦听器，并且为网络服务中心应用软件提供一个新型的数据存取功能。

SQL Server 2005 是一个全面的数据库平台，使用集成的商业智能 (BI) 工具提供了企业级的数据管理。SQL Server 2005 数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能，使您可以构建和管理用于业务的高可用和高性能的数据应用程序

SQL Server 2005 数据引擎是本企业数据管理解决方案的核心。此外 SQL Server 2005 结合了分析、报表、集成和通知功能。这使您的企业可以构建和部署经济有效的 BI 解决方案，帮助您的团队通过记分卡、Dashboard、Web services 和移动设备将数据应用推向业务的各个领域。

SQL Server集数据查询、数据操纵、数据定义和数据控制功能于一体，主要特点有以下几点：

1综合统一

SQL Server 语言风格统一，可以完成数据库生命周期中的全部活动，例如定义

页脚内容7

[标签:标题]

关系模式，插入数据，建立新数据库，还可以对数据库中的数据进行查询和更新，对数据库重构和维护，以及对数据库的安全和完整的控制。

2.高度非过程化

非关系数据模型的数据操纵语言是“面向过程”的语言，用“过程化”语言完成某项请求，必须制定存取路径。而SQL Server进行数据操作，只要提出“做什么”，而无需指明“怎么做”，因此无需了解存取路径，存取路径的选择以及SQL Server的操作过程由系统自动完成。这不但大大减轻了用户负担，而且有利于提高数据性。

3.面向集合的操作模式

非关系数据模型采用的是面向记录的操作方式，操作对象是一条记录。而SQL Server采用集合的操作方式，不仅操作对象、查找结果可以是元组的集合，而且一次插入、删除、更新操作的对象也可以是元组的集合。

4.以同一种语法结构提供多种使用方式

SQL Server既是的语言，又是嵌入式语言。作为的语言，它能够地用于联机交互的使用方式，用户可以在终端键盘上直接键入SQL Server命令对数据库进行操作；作为嵌入式语言，SQL Server语句能够嵌入到高级语言程序中，供程序员设计程序时使用。而在两种使用方式下，它的语法结构基本上是一致的。提供了极大的灵活性与方便性。

1.5系统开发方法

管理系统的开发是一个复杂的系统工程，它涉及到计算机处理技术、系统理论、组织结构、管理功能、管理知识等各方面的问题。管理系统的开发方法主要有：结构化生命周期开发方法、原型法、面向对象的开发方法等。

目前较为流行的MIS开发方法是结构化生命周期开发方法，其基本思想是：用系统的思想和系统工程的方法，按用户至上的原则，结构化、模块化地自上而下对生命周期进行分析与设计。用结构化生命周期开发方法开发一个系统，将整个开发过程划分为5个依次连接的阶段：1.系统规划阶段：主要任务是明确系统开发的请求，并进行初步的调查，通过可行性研究确定下一阶段的实施。2.系统分析阶段：主要任务是对组织结构与功能进行分析，理清数据流程的处理，并且将数据流程抽象化，通过对功能数据的分析，提出新系统的逻辑方案。3.系统设计阶段：主要任务是确定系统的总体设计方案、

页脚内容8

[标签:标题]

划分子系统功能、确定共享数据的组织，然后进行详细设计。4.系统实施阶段：主要任务是讨论确定设计方案、对系统模块进行调试、进行系统运行所需数据的准备、对相关人员进行培训等。5.系统运行阶段：主要任务是进行系统的日常运行管理，评价系统的运行效率，对运行费用和效果进行监理审计。原型法的基本思想是系统开发人员凭借自己对用户需求的理解，通过强有力的软件环境支持，构造出一个实在的系统原型，然后与用户协商，反复修改原型直至用户满意。面向对象的系统开发方法的基本思想是将客观世界抽象地看成是若干相互联系的对象，然后根据对象和方法的特性研制出一套软件工具，使之能够映射为计算机软件系统结构模型和进程，从而实现信息系统的开发。经过综合比较，医院预约网络预约系统以结构化生命周期法为开发方法。

1.6本文所做的主要工作

本文介绍了开发医院预约挂号系统所用到的技术方法，并运用软件工程的设计思想，在ASP.NET环境下，用C#语言进行编写。

通过可需求分析、总体设计、详细设计、编码实现、软件测试全面介绍了医院网络预约挂号系统。对系统的数据流和程序流程进行了详细的图解描述。

1.7本文结构安排

为了使您短时间内了解该论文，特介绍论文内容如下：

第一章介绍论文的选题背景、发展现状、所做工作、所用技术以及论文的机构安排。

第二章系统需求分析，主要对网站进行需求分析，并设计出数据流图。第三章系统总体设计，对系统模块化，并对各个模块进行详细的描述分析。第四章系统的详细设计与实现，包括系统的页面设计、系统的各个模块的设计与实现。

第五章对本系统的测试以及网站维护的方法及注意事项。

页脚内容9

[标签:标题]

第二章需求分析

2.1可行性分析

2.1.1技术可行性

（1）对系统的简要描述

基于Microsoft Visual Studio 2005开发环境和使用SQL数据库开发的面向患者、医院管理员和专家的网上信息管理系统。系统在安装了Windows XP操作系统且与Internet连接了的个人电脑上使用。

（2）系统处理流程

患者登录该系统后，根据自己病情，查询医院内自己所需的专家信息及专家简历，选中专家后，登记患者的姓名及身份证号以及简要病历，并填写预约时间。患者预约信息反馈到医院系统管理员后，管理员对预约信息进行整理，产生预约清单。预约清单开放给医院预约挂号号码发放处和医院内各专家，医院预约挂号号码发放处根据预约清单打印并在预约当日按照预约清单发放挂号号码，医院内各专家可以进入系统根据预约清单查询预约自己的患者的数量及患者的简要病历。 2.1.2操作可行性

本系统操作方法简单，只需掌握基本上网知识，用户即可以轻易学会使用方法及操作流程。系统管理员需要进行简单培训。 2.1.3经济可行性

本系统开发需要一台安装Windows XP的计算机，以及Visual Studio 2005软件以及

Microsoft Office Word 2003和Microsoft SQL Server 2005软件。

2.2任务概述

2.2.1任务目标

此系统在可行性分析的基础上，进一步的说明对医院预约挂号系统的要求，准确的定义出医院预约挂号系统要完成的任务，确定该系统要完成哪些工作，使系统尽可能的满足用户的要求，尽可能的简单方便的运行。

页脚内容10

[标签:标题]

2.2.2用户特点

医院预约挂号系统面对的使用对象是广泛的群众，对于具有一般上网知识者都可以方便使用。

2.3功能描述

1.预约挂号

实现患者从网上直接预约挂号。预约的时候需要填写患者的姓名、身份证号、电话以及简单的病情症状。

2.预约查询

患者可以从次功能输入自己的身份证号，查询自己的预约信息。 3取消预约

患者查询到自己的预约信息后，可以从次功能对先前的预约进行取消操作。 4.登录

管理员以及专家用户可以从登录功能模块进行登录。 5.整理专家信息

管理员登录以后可以对用户进行添加、删除和修改，实现对用户的管理。 6.调配专家

管理员登录后通过次模块可以查看患者预约信息，并对患者预约的专家进行调配。 7.门诊流量统计

管理员登录后可以通过次模块对每天的预约人数进行统计并导出。 8.专家查询

专家用户登录以后可以查询预约自己的患者信息。通过查询患者信息，可以对工作有一个合理的安排与准备。

2.4数据描述

2.4.1 数据流图

数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。数据流图有四种基本符号：正方形表示数据的源点或终点；圆

页脚内容[标签:标题]

角矩形代表变换数据的处理；开口矩形代表数据存储；箭头表示数据流。

医院网络预约挂号系统中需要处理的信息有登录信息，专家信息以及患者预约信息，根据数据信息的流向画出本系统的数据流图。

1. 顶层数据流图

医院预约挂号系统顶层数据流图如图2.1所示。

图2.1 顶层数据流图

反馈信息登录信息预约信息患者预约信息预约系统反馈信息管理员登录信息专家

页脚内容[标签:标题]

2. 医院预约挂号系统完整数据流图

医院预约挂号系统完整数据流图如图2.2所示。

D1 专家信息专家信息登录信息管理员 P1 登录验证登录信息 P2 修改专家信息专家信息预约信息患者 P3 患者预约预约信息登录信息预约信息预约信息 D2 预约清单预约信息预约信息 D2 预约清单 P4 患者查询预约信息调配信息 P8 调配专家登录信息 P6 专家查询 P7 流量统计专家 P5 取消预约门诊流量预约信息预约信息退出患者专家图2.2 医院预约挂号系统完整数据流图

管理员

页脚内容13

[标签:标题]

2.5数据字典

数据流图表达了数据和处理的关系，数据字典则是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。

数据字典通常包括数据项、数据结构、数据流、数据存储、数据处理五部分，其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义描述数据流、数据存储的逻辑内容。根据数据流图，得出了相应的数据字典卡片，每张卡片上主要应该包括名字、描述、定义。

表2-1预约信息表

名字：预约信息别名：预约报表描述：患者预约时填写的患者各项预约信息定义：预约信息=姓名+身份证号+预约时间+预约专家+病历+联系方式位置：预约清单

表2-2管理员及专家登录信息表

名字：管理员及专家登录信息别名：描述：管理员及专家登录所需的用户名及密码定义：管理员及专家登录信息=用户名+密码+用户权限位置：

表2-3专家信息表

名字：专家信息别名：描述：患者预约挂号时查询的各个专家的姓名、科室、电话及特长定义：专家信息=姓名+科室+电话+特长位置：页脚内容14

[标签:标题]

表2-4公告栏信息表

名字：公告信息别名：描述：医院最近的新闻及公告定义：公告信息=医院公告位置：

2.6 E-R图

为了把用户的数据清楚、准确地描述出来，系统分析员通常要建立一个概念数据模型。概念结构于支持数据库的DBMS，具有能充分反映现实世界、易于理解、易于更动、易于向关系、网状或层次等各种数据模型转换。可根据实体间的关系和属性得到E-R图。

E-R图中的三个基本符号：矩形表示实体型，矩形框内写明实体名；椭圆形表示属性，并用无向边将其与相应的实体型连接起来；菱形表示联系，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1,1:n或m:n）。

医院网络预约挂号系统是针对医院管理员，医院专家和患者的系统。所以，在本系统中有患者、系统管理员、医院专家三个实体。患者在预约的时候必须填写相关的预约信息，即患者姓名、身份证号、联系方式、预约时间、预约的专家以及患者简单病情症状，这些都是“患者”实体的属性。系统管理员有自己的登录用户名和密码，还可以修改自己的密码，这些是“管理员”实体的属性。专家为了能让在网上预约的患者清晰的了解自己，所以系统里有专家的姓名、电话、科室、编号、特长、可以预约的人数，已经预约的人数，专家进系统查询预约患者信息时还需要登录系统，所以专家还有登录系统所需要的用户名和密码，这些是“专家”实体的属性。“患者”、“管理员”、“专家”三个实体的属性图如下所示。

页脚内容15

[标签:标题]

患者及其属性，如图2.3所示：

联系方式患者姓名病历身份证号预约专家预约时间图2.3“患者”实体及其属性图

管理员及其属性，如图2.4所示：

管理员

用户名密码

图2.4“管理员”实体及其属性图

修改密码

专家及其属性，如图2.5所示：

页脚内容用户名密码电话专家编号当前预约人数科室姓名特长可预约人数图2.5“专家”实体及其属性图

[标签:标题]

通过以上描述的各个实体的属性图，这样就可以了解系统的实体信息，实体属性图中描述了各个实体的属性，这些也是在进行系统操作时可以得到的信息。这是以需求说明为基础设计的局部概念模型，然后以这些局部模型为基础集成为一个全局的概念模型，在概念模型设计中多是采用这种自底向上的设计方式，称为系统集成法。

分析得出系统中实体属性后，每个实体之间都有一定的联系，“管理员”实体与“专家”实体之间的关系为管理员管理专家，“管理员”与“患者”实体之间的关系是管理员管理患者的预约信息，“专家”与“患者”两实体之间的关系为专家对患者进行诊治。所以得出的医院预约挂号系统E-R图如图2.6所示。

N 患者诊治 1 专家 N 管理 M M 管理员管理 N

图2.6医院预约挂号系统E-R图

2.7需求规定

2.7.1功能需求

医院预约挂号系统主要实现一下几部分功能：内部人员权限管理，预约挂号，门诊流量统计，公告栏管理，专家信息管理。

内部人员权限管理模块：管理员以及专家的登录以及修改密码。管理员可以从登录模块进入系统对预约信息以及专家基本信息进行整理。专家可以从登录模块进入系统查询患者预约情况。

预约挂号模块：全国各地患者可以通过此模块进行预约挂号，并填写自己的挂号信

页脚内容17

[标签:标题]

息。可以查询自己先前的预约信息，也可以通过此系统取消先前的预约。

门诊流量统计：记录每天门诊的患者流量，对其进行统计。

专家信息管理：管理员可以对医院专家的信息进行增加、修改和删除。公告栏：医院里的通知和新闻都由此功能模块展示到网页上。 2.7.2 性能需求

系统应具有配置灵活、易于维护、便于扩展、性能可靠等突出优点，支持面向对象的大型数据库系统。如：SQL Server等，可处理大容量数据，并具有高安全性和可靠性。

1..时间特性

操作响应时间一般在1~3秒之内，随之数据量的增大，操作的响应时间就要延长。

2数据精度

各种数据的输入，输出要满足各种对数据精度的要求，严格按照系统要求的格式。 3.适应性

适应现有Windows XP系统的需求，并有可能适应更高级别的系统。 2.7.3 运行需求 1.用户界面

用户界面简单直观，一目了然，给用户带来极大的便利，让用户能够简单直接的运用本系统。 2.硬件接口

不需要特定的硬件或硬件接口进行支撑，一般微机均可运行。 3.软件接口

运行于Windows XP或者更高版本的操作系统上。 2.7.4其它需求

1.保密需求：必须输入相关的正确的用户名和密码才能进入系统，并且不同的用户选择相应的权限才能登录成功。

2.数据要求：对于患者和专家的联系电话，必须有严格的位数，经过分析研究，联系电话位数必须11位。

3.身份证要求：为杜绝无关人员对系统进行恶意的破坏，在患者预约挂号时，必须填写自己真实的18位身份证号，输入的位数不对以及输入的身份证格式不对，系统则

页脚内容18

[标签:标题]

会提示身份证输入有误，不予存到系统数据库里，预约失败。

4.可维护性：平时由管理人员可以维护，遇到大问题或难解决的问题由开发人员进行维护。

5.可扩展性：在系统使用过程中，如果有医院在预约挂号方面有新的要求，则应能在本系统中进行扩展，增加新的功能。

页脚内容19

[标签:标题]

第三章总体设计

3.1总体设计原理

经过需求分析，已经清楚了系统所要完成的全部功能，现在决定“怎么做”，总体设计的基本目的就是回答“概括的说，系统应该如何实现？”这个问题。因此总体设计又称为概要设计或初步设计。通过这个阶段的工作，将划分出组成该系统的物理元素——程序、文件、数据库、人工过程和文档等，但是这些物理元素仍然处于黑盒子级别。总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成，以及这些模块间的相互关系。

总体设计过程首先要寻找实现目标系统的的各种不同的方案，需求分析阶段得到的数据流图是设想的各种可能方案的的基础，然后从这些供选择的方案中选取若干个合理的方案，为每个合理的方案都准备一份系统流程图。然后分析比较这些合理的方案，选出最佳的方案，进一步为这个最佳方案设计软件结构，设计出初步的软件结构后还要进行多方改进，从而得到更合理的结构，进行数据库设计。

进行总体设计，可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。

典型的总体设计过程包括9个步骤：1.设想供选择的方案；2.选取合理的方案；3.推荐最佳方案；4.功能分解；5.设计软件结构；6.设计数据库；7.制定测试计划；8.书写文档；9.审查和复审。[2]

页脚内容20

[标签:标题]

3.2系统功能模块设计

在需求分析的时候已经对系统的的功能进行了初步分析，在这里对系统功能进行详细的设计。

由于系统中面向的是医院的系统管理员，医院的坐诊专家，以及广大患者，所以对系统分为三大主功能模块，即管理、专家、患者三大主功能模块。

管理模块是针对管理员对系统的管理进行设计的功能模块，管理员需要进行登录系统后方可进行系统信息管理，所以首先要有登录模块。管理员登录系统后需要对专家的信息进行增加、删除和修改，所以在此主功能模块下设计了一个整理专家信息模块，管理员可以通过此模块对专家信息进行管理。管理员还需要对每天患者预约的信息进行查看整理，所以设计了一个调配专家，调配专家模块用于当患者预约的专家在预约当日临时有事不能按时坐诊的话，管理员可以通过此模块给相关患者进行专家调配，就是给相关预约患者调配一个与患者预约的专家同科室的专家，然后保存到数据库里，以便患者查询预约信息。系统要求有一个统计门诊流量的功能，统计每天预约的人数，所以在管理模块下设计了一个统计门诊流量的功能模块。在主页面有一个公告栏，来公示医院的通知以及医院的新闻动态，公告栏由管理员管理，所以在管理主功能模块下设计了一个公告栏模块。

专家主功能模块下设计了一个专家查询模块，专家从此模块查询患者预约信息。专家登录系统则从管理模块下的登录模块进行登录，登录的时候选择登录相应的登录权限。

患者主功能模块下设计了三个分模块：预约、查询信息和取消预约。患者从网上进行预约挂号时，需要填写预约的各种信息，患者可以进入预约模块填写自己的预约信息，并保存，预约成功。当患者预约成功后，患者想查询先前的预约信息，则需要一个查询模块，所以在患者主功能模块下设计了一个查询信息模块。当患者在预约当日有事不能按时就诊，患者需要取消先前的预约，所以在患者主功能模块下设计了一个取消预约的模块。

页脚内容21

[标签:标题]

医院网络预约挂号系统功能模块图，如图3.1所示。医院预约挂号系统管专理家统调整公专计配理告家预登约门专专管查录家理询诊家流信量息

图3.1总体功能模块图

患者查询信息取消预约

3.3功能分析

1.登录：当管理员和专家用户需要进入系统时，可以从登录模块输入用户名和密码，并选择自己权限进行登录。当输入错误的信息时系统拒绝访问。

2.统计门诊流量：管理员可以用此功能进行每天预约的患者数量，做出统计。 3.调配专家：当患者预约的专家在预约的时间临时有事情不能给患者看病的情况下，管理员可以对此患者进行专家调配，调配为同一科室的专家。

4.整理专家信息：管理员通过此功能添加、修改和删除专家信息，及时更细医院里专家的信息，以方便患者进行预约。

5.公告栏：用于展示医院里的通知、公告以及新闻等内容，由管理员进行管理。 6.专家查询：专家用户登录系统后，进入到查询信息模块，查询预约自己的患者信息，以方便专家做好合理的安排和准备。

7.预约：患者进入此网站后，进入预约系统，查看各个科室的各个专家信息，根据

页脚内容22

[标签:标题]

自己的病情预约适合的专家。

8.查询信息：当患者预约完毕后，可以通过查询功能，输入自己的身份证号，对自己先前的预约信息进行查询、核对。

9.取消预约：当患者临时有事不能到医院看病时，可以通过查询信息查询到自己的预约信息，然后取消自己先前的预约。

3.4数据库设计

数据库是信息系统的核心和基础，数据库设计的质量将直接关系到信息系统开发的成败和优劣。数据库设计是根据业务需求，信息需求，和处理需求，确定系统中的数据结构、数据操作和数据一致性约束的过程。

数据库设计是在一个给定的应用环境中，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效的存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境，包括数据库的存取效率、数据库存储空间的利用率、数据库系统运行管理的效率等。[3] 3.4.1数据项定义

医院网络预约挂号系统中需要用到四种数据流，所以设计了预约信息表、登录信息表、专家信息表和公告信息表四个数据库表。

预约信息表主要存储患者的预约信息，患者预约挂号时填写的各种信息都存储到预约信息表中。

登录信息表中存储的是管理员和专家登录系统时所需要的用户名和密码，以及识别登录权限信息。

专家信息表用于存储医院专家的信息，专家的姓名、科室、电话、联系方式、预约人数等信息都存储啊在专家信息表中。

公告信息表用于存储主页上公告栏里的通知、公告以及新闻等信息。

医院网络预约挂号系统数据库中各个表格设计结果如下所示。每个表格表示数据库中的一个表。

页脚内容23

[标签:标题]

表3-1预约信息表

字段名称姓名身份证号专家病历预约日期电话列标识 PatientName IdentityCard SpecialistID CaseReport OderDate Tel 字段类型 varchar varchar varchar varchar datetime int 长度 50 50 50 200 15 主键是否否否否否描述患者的姓名患者身份证号预约的专家患者简单病历预约的日期患者联系电话

表3-2登录信息表

字段名称用户名称密码权限列标识 UserName PassWord IsSys 字段类型 varchar varchar smallint 长度 50 50 主键是否否描述登录用户名登录密码登录权限

表3-3专家信息表

字段名称姓名编号性别科室特长可预约人数当前预约人数电话列标识 SpecialistName SpecialistNO. SpecialistSex Office Resume OrderNum CurrentNum Tel 字段类型 varchar int varchar varchar varchar int int int 长度 50 50 50 50 200 50 50 50 主键否是否否否否否否描述专家的姓名专家的编号专家的性别专家所属科室专家的特长专家允许预约的人数专家当前的预约人数专家的电话表3-4公告信息表字段名称列标识 Notice 字段类型长度主键描述公告 varchar 200 是医院新闻公告页脚内容24

[标签:标题]

第四章详细设计与编码实现

结构化详细设计是对概要设计的进一步细化，其目标是为软件结构图中每个模块提供可供程序员编程实现的具体算法。

详细设计阶段的根本目标是确定应该具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

详细设计阶段的任务还不具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个蓝图写出实际的程序代码。因此，详细设计的结果基本上决定了最终的程序代码的质量。考虑程序代码的质量时必须注意，程序的“读者”有两个人。那就是计算机和人。在软件的生命周期中，设计测试方案、诊断程序错误、修改和改进程序等等都必须首先读懂程序。实际上对于长期使用的软件系统而言，人读程序的时间可能比写程序的时间还要长的多。因此，衡量程序的质量不仅要看它的逻辑是否正确，性能是否满足要求，更主要的是要看它是否容易阅读和理解。详细设计的目标不仅仅是逻辑上正确的实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。结构程序设计技术是实现上述目标的关键技术，因此是详细设计的逻辑基础。[2]

详细设计常采用的描述方式有三类：图形描述、语言描述和表格描述。图形描述包括程序流程图和问题分析图；语言描述主要是程序设计语言；表格描述包括判定表等。这里主要运用了程序流程图来分析医院预约挂号系统。

4.1程序流程图

程序流程图又称程序框图，是描述过程设计的方法。程序流程图中使用的符号如下：椭圆形表示开始或停止；长方形表示处理；菱形表示多分支；箭头表示控制流。

1.管理员和专家登录程序流程图

管理员和专家登录流程图如图4.1所示，用于描述管理员和专家登录系统的过程。管理员和专家进入主页后，在登录框输入用户名、密码和登录权限，若输入正确，则登录系统。若输入错误，则提示输入用户名和密码不对，请重新输入。管理员登录成功后则进入后台管理页面，专家登录成功后则进入后台专家查询页面。

页脚内容25

[标签:标题]

管理员和专家进入主页输入用户名、密码和登录权限 Y 输入是否有误 N 登录成功进入后台页面结束

图4.1管理员和专家登录程序流程图

登录成功后，管理员和专家就可以执行各自的功能了。 2.预约挂号程序流程图

患者预约挂号程序流程图如图4.2所示，用于描述患者预约挂号的过程。当患者进入主页后，点击预约，进入到预约挂号页面，患者在这里填写自己的信息以及选择要预约的专家，然后保存预约，预约挂号程序结束。

页脚内容26

[标签:标题]

患者进入主页进入预约页面填写预约信息 N 保存预约是否预约成功 Y 结束

图4.2预约挂号程序流程图

3.患者查询及取消预约流程图

患者查询及取消预约流程图如图4.3所示，用于描述患者查询预约信息的过程。当患者进入主页，点击预约界面后，患者输入自己的身份证号对自己先前的预约进行查询，浏览自己的预约信息。查询成功后，若取消，则取消先前的预约，结束。否则直接结束。

页脚内容27

[标签:标题]

患者进入主页进入预约页面输入身份证号 Y 输入是否有误 N 输出预约信息是否取消预约 Y 取消预约 N

结束

图4.3患者查询及取消预约流程图

4.管理员调配专家程序流程图

管理员调配专家程序流程图如图4.4所示。当患者预约的专家临时有事不能按时接诊的情况下，管理员可以给相关的患者调配一个同科室的专家。

页脚内容28

[标签:标题]

管理员登录系统进入调配专家页选择需要调配的患者选择要调配的专家结束

图4.4管理员调配专家程序流程图

4.2编码与实现

本系统模版设计有三个，一个是管理员操作页面模版，一个是专家查询页面模版，一个是患者预约挂号操作页面模版。 4.2.1管理员、专家登录界面及其相关代码

管理员和专家可以进入医院网络预约挂号系统前台主页面时，通过主页上的登录功能登录进入系统，然后可以进行相应的权限操作

管理员和专家登录界面如图4.1所示。

图4.5管理员和专家登陆界面

页脚内容29

[标签:标题]

实现代码如下：

页脚内容[标签:标题]

4.2.2患者预约界面及其相关代码

管理员进入主页以后，点击预约挂号连接，进入一下界面，在一下界面中填写相关的预约信息，并确保信息内容真实、格式正确。

预约界面如图4.6所示。

图4.6患者预约挂号界面

实现代码如下：

function QueryIdentityCard() { var IdentityCard=document.all.IdentityCard.value checkIdcard(IdentityCard)

页脚内容31

[标签:标题]

var StrReturn=$Server(0,\"OrderSys.PatientOrder\",\"QueryIdentityCard\",new Array(IdentityCard.toString())); if(StrReturn==\"Have\") { document.all.ICard.innerHTML=\"身份证号重复了，请重新输入\"; document.all.IdentityCard.value=\"\"; document.all.IdentityCard.focus(); } else if(StrReturn==\"None\") { document.all.ICard.innerHTML=\"\"; document.all.ICard.innerHTML=\"可以使用\"; } }

4.2.3患者选择预约科室界面及其相关代码

当患者填写完整预约信息后，选择要预约的专家，首先需要选择科室，选择科室界面如下。选择科室界面如图4.7所示

图4.7患者预约科室选择界面

实现代码如下：

function addSelectOfficesOption() { _rsSelectOffices=$Server(0,\"OrderSys.PatientOrder\",\"SelectOffices\"); //_rsStoreType.sort=\"ID ASC\"; if(_rsSelectOffices.recordcount>0)_rsSelectOffices.movefirst; document.all.SelectOffices.options.length=0; while(!_rsSelectOffices.eof) { _OPTION=document.createElement(\"OPTION\"); _OPTION.text=_rsSelectOffices(\"Offices\").value _OPTION.value=_rsSelectOffices(\"Offices\").value document.all.SelectOffices.options.add(_OPTION); _rsSelectOffices.MoveNext } }

页脚内容32

[标签:标题]

4.2.4患者查询界面及其相关代码

当患者想确定一下自己先前的预约信息时，可以通过此界面输入自己的身份证号进

行查询预约信息。患者查询界面如图4.8所示。

图4.8患者查询界面

实现代码如下：

function bnQuery()

{ var Key=document.all.Key.value; rsReturn=$Server(0,\"OrderSys.PatientOrder\",\"GetQueryRecordset\",new Array(Key.toString())); if(rsReturn!=null && rsReturn.recordcount>0) { xmlSave.recordset(\"ID\").value=rsReturn(\"ID\").value; xmlSave.recordset(\"PatientName\").value=rsReturn(\"PatientName\").value; xmlSave.recordset(\"OrderDate\").value=rsReturn(\"OrderDate\").value; xmlSave.recordset(\"IdentityCard\").value=rsReturn(\"IdentityCard\").value; xmlSave.recordset(\"BillNo\").value=rsReturn(\"BillNo\").value; xmlSave.recordset(\"Memo\").value=rsReturn(\"Memo\").value; xmlSave.recordset(\"CaseReport\").value=rsReturn(\"CaseReport\").value; xmlSave.recordset(\"SpecialistID\").value=rsReturn(\"SpecialistID\").value; xmlSave.recordset(\"SpecialistName\").value=rsReturn(\"SpecialistName\").value; xmlSave.recordset(\"SpecialistNo\").value=rsReturn(\"SpecialistNo\").value; xmlSave.recordset(\"SpecialistSex\").value=rsReturn(\"SpecialistSex\").value; xmlSave.recordset(\"Offices\").value=rsReturn(\"Offices\").value; xmlSave.recordset(\"Resume\").value=rsReturn(\"Resume\").value; xmlSave.recordset(\"OrderNum\").value=rsReturn(\"OrderNum\").value; xmlSave.recordset(\"STel\").value=rsReturn(\"STel\").value; xmlSave.recordset(\"CurrentNum\").value=rsReturn(\"CurrentNum\").value; alert(\"查询成功，您的姓名为：\"+xmlSave.recordset(\"PatientName\").value) } }

页脚内容33

[标签:标题]

第五章网站测试及维护

5.1测试目的

1．测试为了发现程序中的错误而执行程序的过程.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进。

2．测试是为了证明程序有错误，而不是证明程序没有错误。 3．一个成功的测试是发现了至今为发现的错误的测试

5.2测试方案

该系统主要运用的是黑盒测试，黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。只在程序借口进行测试，检查程序功能是否能按照正常的规定使用，程序是否能适当的接受输入数据并产生正确的输出信息，程序运行过程中是否保持外部信息的完整性。

5.3项目测试

1.测试一

测试项目名称：登录，测试内容如表5-1所示。

表5-1登录测试表输入数据错误的用户名或密码正确的用户名和密码预期输出出现错误的用户名或密码提示登录成功测试结果与预期输出一致与预期输出一致

页脚内容34

[标签:标题]

2.测试二

测试项目名称：预约挂号，测试内容如表5-2所示。

表5-2预约挂号测试表

输入数据输入空姓名或者空身份证号输入错误的身份证号按照正确格式和要求填写

预期输出预约失败预约失败预约成功测试结果与预期输出一致与预期输出一致与预期输出一致 3.测试三

测试项目名称：患者查询，测试内容如表5-3所示

表5-3患者查询测试表

输入数据错误的身份证号正确的身份证号

预期输出出现错误的身份证号提示显示预约信息测试结果与预期输出一致与预期输出一致 5.4综合测试

在以上测试的基础上，对系统功能进行了整体测试，依次检验系统功能是否符合系统开发的目标。经过使用大量的数据多次进行系统测试，发现了系统存在的问题并及时改进，最终实现了网站的开发目标。

5.5网站维护

软件维护就是在软件已经交付使用之后，为了纠正错误或满足新的需要修改软件的过程。

软件维护可以分为四类： 1.改正性维护

在程序使用期间，用户必然会发现程序错误，把遇到的错误问题报告给维护人员，然后由系统维护人员进行改正错误。

页脚内容35

[标签:标题]

2.适应性维护

为了和变化的环境适当的配合而进行软件修改。 3.完善性维护

为了满足用户使用过程中提出的新功能或着修改系统中已有功能的需求，而对软件进行的完善性维护。

4.预防性维护

为了改进软件未来的可维护性和可靠性，或者给软件未来的改进奠定更好的基础而对软件进行维护

页脚内容[标签:标题]

结束语

四年大学生涯转眼已到尾声，当初迈进大学校门的情景还历历在目，转而大学毕业论文已经结束。在经过三个月的探索与实践中，我终于如愿以偿的完成了毕业设计。

在毕业论文中，我采用了ASP.NET和SQL Server数据库技术。由于在以前的课堂学习中，大部分在与学习理论知识，初步把课堂理论知识运用于毕业设计的实践中，感觉有点吃力，但是在老师的帮助和自己的努力下，终于的完成了毕业设计。

在这段做毕业设计的时间里，我学到了很多知识也有很多感受。从当初对ASP.NET不太了解的状态，在老师的帮助下，我开始学习和试验，查看相关的资料和书籍，让自己头脑中模糊的概念逐渐清晰，使自己非常稚嫩的设计一步步完善起来，每一次改进都是我学习的收获，每一次试验成功都会让我兴奋好一段时间。让我也充分认识到医院网络预约挂号系统给患者和医院带来的极大的方便。

这次毕业设计的经历让我终身受益，我感受到做论文是要真真正正用心去做的一件事情，是真正的自己学习和研究的过程，不学习就没有研究的能力，没有自己研究，就不会有所突破，希望这次经历能激励我在以后的生活中继续学习。

本次毕业设计，让我学会了把理论知识运用到实践中来。让我明白了做一件事情必须尽全力，用一个认真的态度去对待。

页脚内容37

[标签:标题]

致谢

在这里我首先感谢培养我的，给我提供了一个很好的学习和生活环境感谢曾经培养我的老师们，感谢他们在四年的大学生活、学习中对我的教育、指导和关心。

在毕业设计这个短暂的过程中，有许多可敬的师长、同学和朋友给了我莫大的支持与帮助，在这里请接受我诚挚的谢意！

在整个毕业设计过程中，我得到了胡静老师的悉心指导和大力支持，从需求分析到编码测试，不足之处，胡老师都耐心地给予指出。毕业设计程序经过老师多次的指点，终于能顺利的运行。论文经过胡老师的多次批改及自己的修改，终于比较完整。在胡老师耐心的指导下，我成功的完成了这次毕业设计。在此对胡老师表示衷心的感谢和诚挚的敬意！

感谢我的同学和朋友们，在毕业设计过程中给了我很大的帮助。感谢我的同学对我从无怨言的热心帮助，感谢我寝室的室友们，在与他们激烈的探讨中，让我学到了很多知识，顺利的完成了毕业设计。

页脚内容38

[标签:标题]

参考文献

[1] 马瑞新 ASP.NET程序设计案例教程北京清华大学出版社，2009年 [2]张海藩软件工程导论北京：清华大学出版社，2008年 [3]王珊，萨师煊.数据库系统概论.北京：高等教育出版社，2006年 [4]陈明.软件工程实用教程.北京：电子工业出版社，2004年 [5]刘兆毓.计算机英语.北京：清华大学出版社，2003年

[6]毕硕本,卢桂香.软件工程案例教程.北京：北京大学出版社，2007年 [7]郭洪涛. ASP.NET（C#）大学实用教程.北京：电子工业出版社，2007年 [8]常永英. ASP.NET程序设计教程（C#版）.北京：机械工业出版社，2009年 [9]蔡继文. 21天学通ASP.NET.北京：电子工业出版社，2009年 [10]卢潇.软件工程.北京：清华大学出版社，2005年

[11]朱印宏，苏震巍. ASP.NET 3.5+SQL Server网站模块化开发全程实录. 北京清华大学出版社，2009年

[12]宋海兰李航. ASP.NET 3.5项目开发实战.北京：电子工业出版社，2009年 [13]余金山 ASP.NET 2.0+SQL Server 2005企业项目开发与实战北京电子工业出版社．2008

[14]房大伟 ASP.NET开发典型模块大全北京人民邮电出版社 2010年

页脚内容39

[标签:标题]

附录

英文原文

Chapter 1 Understanding Software Engineering

In order to understand software engineering, we first need to look at the projects that were reported in the early software engineering literature. One feature is immediately striking-the absence of reports on commercial applications. Most case studies are of either large defense projects of small scientific project. In either case, the projects typically involved sever hardware and software challenges that are not relevant to most modern projects.

A typical example is the SAFEGUARD Ballistic Missile Defense System, which was developed from 1969 through 1975. “The development and deployment of the SAFEGUARD System entailed the development of one of the largest, most complex software system sever undertaken.” The projects took 5,470 staff-years, starting with 1888 staff years in 1969 and peaking at 1.261 staff-years in 1972. Overall productivity was 418 instructions per staff-year.

SAFEGUARD was a very large software engineering project that challenged the state of the art at the time. Computer hardware was specially developed for the project. Although the programming was done in low-level languages, the Code and Unit Test activities required less than 20% of the overall effort. System Engineering and Design each consumed 20% of the effort, with the remainder being accounted for by Integration Testing.

The Paradox of Software Engineering

In trying to understand software engineering, we need to keep two points in mind : 1.Projects the size of SAFEGUARD are extremely rare.

2.These very large projects (1,000-plus staff-years) helped to define software engineering.

Similarly, The Mythical Man-Month4 by Fred Brooks was based on IBM’s experiences when developing the OS/360 operating system. Even though Brooks wrote about the fact that large programming projects suffer management problems that are different from the problems encountered by small ones due to the division of labor, his book is nevertheless still used to support the ideas behind software engineering.

These really large projects are really systems engineering projects. They are combined hardware and software projects in which the hardware is being developed in conjunction with the software, A defining characteristic of this type of project is that initially the software developers have to wait for the hardware, and then by the end of the project the hardware people are waiting for the software. Software engineering grew up out of this paradox.

What Did Developers Do While Waiting for the Hardware ?

Early in the typical software engineering project, there was plenty of time. The hardware was still being invented or designed, so the software people had plenty of time to investigate the requirements and produce detail design specifications for the software. There was no point in starting to write the code early, because the programmers lacked hardware on which to run the code. In some cause, the programming language wasn’t even chosen until late in the project. So, even design specifications were complete, it was

页脚内容40

[标签:标题]

pointless to start coding early.

In that context, it made sense to define a rigorous requirements process with the goal of producing a detailed requirement specification that could be reviewed and signed off. Once the requirements were complete, this documentation could be handed off to a design team, which could then produce an exquisitely detailed design specification. Detailed design reviews were a nature part of this process, as there was plenty of time to get the design right while waiting for the development of the hardware to advance to the point where an engineering prototype could be made available to the software team.

How Did Developers Speed Up Software Delivery Once the Hardware Became Available ?

The short answer is, “Throw lots of bodies at the problem .” This was the “human wave” approach that Steven Levy described and that can be seen in the manpower figures reported from SAFEGUARD project. As soon as the hardware became available, it made sense to start converting the detailed design specifications into code. For optimum efficiency, the code was reviewed to ensure that it conformed to the detailed design specification, because any deviation could lead to integration problems downstream.

Lots of people were needed at this stage because the project was waiting for the software to be writing and tested. So, the faster the designs could be converted into tested code, the better. Early software engineering projects tended to use lots of programmers, but later on the emphasis shifted towards the automatic generation of code from the designs through the use of CASE tools. This shift occurred because project teams faced many problem in making the overall system work after it had been coded. If the code could be generated from the design specifications, then projects would be completed faster, and there would be fewer problem during integration.

Implications for the Devlopment Process

Software engineering projects require lots of documentation. During the course of a project, three different skill sets are needed:

Analysts to document the reqirements

Designers to create the design specifications Programmers to write the code

At every stage, the authors of each document must add extra detail because they do not know who will subsequently be reading the document. Without being able to assume a certain, common background knowledge, the only safe course is to add every bit of detail and cross-referencing that the author knows. The reviewers must then go through the document to confirm that it is complete and unambiguous.

Complete documentation brings with it another challenge: Namely, team members must ensure that the documents remain consistent in the face of changes in requirements and design changes made during implementation. Software engineering projects tackle this challenge by making sure that there is complete traceability from requirements through to implemented code. This ensures that whenever a change must be made, all of the affected documents and components can be identified and updated.

This document-driven approach affects the way that the people on the project work together. Designers are reluctant to question the analysts, and the programmers may be encouraged not to question the design nor to suggest “improvements” to the design. Changes are very expensive with all of the

页脚内容[标签:标题]

documents, so they must be controlled.

A great way to control changes from the bottom is to define a project hierarchy that puts the analysts at the top, with the designers below them, and the programmers at the bottom of the heap. This structure is maintained by promoting good programmers to become designers and allowing good designers to undertake the analysts' role.

The Modern Definition of Software Engineering

Over the last 30 years, the software engineering community has followed the path of applying mechanical metaphors to the software development process. Software engineering is now an accepted academic subject and an active research field for universities. The focus for software engineering projects is on a defined, repeatable approach as exemplified by the IEEE definition:

Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.

This systematic, disciplined, and quantifiable approach to software development has proved to be very effective at developing safety critical systems. The team that writes the software for the space shuttle, for example, used this approach and has managed to achieve an admirable defect rate.

The last three versions of the program—each 420,000 lines long—had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors

In the process, however, other process constraints had to be relaxed.

Money is not the critical constraint: The group's $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations

This is an appropriate engineering trade-off. When lives are at stake, it makes sense to use whatever resources are needed to ensure that nothing goes wrong. But what about software development when the consequence of error is lower?

Good Enough Software—Software Engineering for the Masses

For some software, rapid development of feature-rich applications is what matters. The idea is that users will put up with errors in programs because they have so many useful features that are unobtainable elsewhere. As Edward Yourdon[8] put it, “I'm going to deliver a system to you in six months that will have 5,000 bugs in it—and you're going to be very happy!”

Good enough software is a logical extension of the ideas of software engineering. It represents the engineering trade-off between resources, schedule, features, and defects. The space shuttle software is safety-critical, so it has to minimize defects, accepting the resulting schedule and resource demands. Commercial shrink-wrapped applications like word processors and Web browsers need lots of features that must be developed quickly. Resources are constrained by the need to make a profit, so the engineering trade-off is made to shrink the schedule by spending less time removing known defects. The idea is that for some kinds of known defects, it is not economic to take the time to remove them.

Is Software Engineering a Good Choice for Your Project?

Systems engineering projects that involve the development of new hardware and software are a natural

页脚内容[标签:标题]

fit for software engineering. Many defense and aerospace projects fit within this category. When I'm a passenger in a “fly by wire” aircraft, I want to know that a systematic, disciplined, and quantifiable approach was taken to the development and verification of the flight control software. After all, it would not be very comforting to know that the software “was developed by the lowest bidder.”

If your organization develops large, shrink-wrapped consumer software applications and is good at making appropriate engineering trade-offs, you might be able to use the good enough software approach. The key to success with this type of software engineering is volume. You need to be selling millions of units in a competitive market where customers buy on the basis of reviews and marketing rather than on detailed, side-by-side comparisons of products.

In all other cases, you should be looking for alternatives to software engineering.

Chapter 2. The Problems with Software Engineering

The biggest problem with software engineering is the assumption that a systematic, disciplined, and quantifiable approach is the only possible approach. By imposing the mechanical engineering metaphor on software development, it stops us from seeing alternatives. Classic examples of this problem are the software engineering concepts of “defect potential” and “defect removal efficiency”:

Defect potential: the total universe of errors or bugs that might be expected in a software project

Defect removal efficiency: the percentage of potential defects eliminated prior to releasing a software project to customers.

This mechanical view omits the fact that better developers make far fewer mistakes and are much better at finding defects. Software engineering makes us forget that what really matters on a project is the skill, knowledge, and experience of the individual software developers.

In a landmark field study of large software engineering projects, the importance and contribution of exceptional designers as individuals was readily apparent:

Many projects had one or two people, usually senior systems engineers, who assumed prime responsibility for designing the system. On about one-third of the projects we studied, one of the individuals had remarkable control over the project direction and outcome and, in some cases, was described by others as the person who “saved” the system. Since their superior application domain knowledge contrasted with that of their development colleagues, truly exceptional designers stood out in this study, as they have elsewhere, as a scarce project resource.

The field study went on to note that

conventional wisdom on software development often argues that no software project should rely on the performance of key individuals. The experience of many successful large projects, however, indicates why this is more troublesome in theory than in practice. An exceptional designer represents a crucial depth and integration of knowledge domains that are arduous to obtain through a group design process.

In the search for the engineering nirvana of a systematic, disciplined, and quantifiable approach, we have confused ourselves. We should not be talking about the defect potential of a project; we should be talking about the defect potential of a developer.

The idea is simple. An exceptional designer will make fewer mistakes than his development colleagues, will have a lower defect potential, and will have a higher defect removal efficiency. Fred Brooks states this really well:

页脚内容[标签:标题]

one wants the system to be built by as few minds as possible. Indeed, most experience with large programming systems shows that the brute-force approach is costly, slow, inefficient and produces systems that are not conceptually integrated The conclusion is simple: If a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.

The key problem with software engineering is that it lets us forget about the people doing the software development. The implicit promise of software engineering is that if we can just define a systematic, quantified process, anyone can be successful at software development. This idea is wrong. As the field study showed, even with a process, exceptional developers are vital to the success of projects. We need to focus our attention on how we nurture software developers so that they, too, can excel. As part of doing that, we need to question what we mean by a systematic software development process.

Can Software Development Be Made Systematic and Quantified?

Is achieving a defined and repeatable process actually desirable in software development? The team that created the SCRUM software development process states the following:

If a process can be fully defined, with all things known about it so that it can be designed and run repeatably with predictable results, it is known as a defined process, and it can be subjected to automation. If all things about a process aren't fully known—only what generally happens when you mix these inputs and what to measure and control to get the desired output—these are called empirical processes.

Under this definition, software development is not a defined process. At best, all we can hope to achieve is an empirical process. The reason is that the sources of all software requirements are people. There is no way to automate requirements elicitation; rather, people must talk to each other so that the software team can learn what the users really need the application to do. At the same time, the users are learning the technical constraints and costs and then use that knowledge to adjust the feature set that they ask for.

Once the software team has learned what the user needs, there remains the problem of documenting these requirements. To have a defined development process, we need to start with complete, unambiguous requirements. This is exceedingly hard to do. Gause and Weinberg illustrate this problem well by showing some of the possible interpretations of “Mary had a little lamb.” By emphasizing different words or combinations of words, a completely new meaning can be generated.

Gause, Don, and Gerald Weinberg, Understanding Requirements Quality Before Design, Dorset House, 19.

Mary had a little lamb. It was Mary's lamb, not John's. Mary had a little lamb. She doesn't have it any longer.

Mary had a little lamb. She had only one lamb; other people had more. Mary had a little lamb. It really was surprisingly small.

Mary had a little lamb. She didn't have the curried chicken that everyone else had.

It is practically impossible to be precise and unambiguous in English (or in any other language, for that matter). Requirements elicitation is a “high-touch” activity, and we want to make sure that developers keep on talking to their users because we cannot afford the mistakes that could arise from alternative interpretations of a written requirements document. You don't want a defined requirements capture process.

页脚内容[标签:标题]

第一章理解软件工程

为了看清软件工程适用（以及不适用）的范畴，我们首先需要对软件工程有一个深入的理解。为了理解软件工程，我们首先需要了解在早期软件工程文献中提到的那些项目。稍做研究，你就会发现一个令人惊讶的事实：这些文献中几乎没有对商用软件的报告。在所有案例中，绝大多数都是大型国防项目或者小型科研项目。在这两类项目中，开发者通常都需要面对及其严峻的硬件/软件条件；而在现代的商用项目中，环境通常会宽松很多。

一个非常典型的例子就是美国国防部于1969年至1975年间开发的SAFEGUARD弹道导弹防御系统。“SAFEGUARD系统的开发和部署堪称有史以来最大、最复杂的软件系统”。在项目开始的第一年（1969年），工作量为188人年；到1972年，年工作量已经达到1261年；整个项目的工作量共计5407人年，平均生产率为每人年41指令。

SAFEGUARD是一个极其庞大的软件工程项目，它也代表了当今软件工程的最高水平。它所使用的计算机硬件是专为此项目而开发的。尽管程序设计工作都是用低级语言完成的，但编码和单元测试阶段在全部工作量中所占的比重还不到20%。系统工程（需求分析）和设计各自占据了20%的工作量，其他的工作量（超过40%）则用于集成测试。

软件工程的悖论

在试图理解软件工程时，我们需要在脑海中牢记下列两点： 1.像SAFEGUARD这样规模的项目属于凤毛麟角。

2.但软件工程正式在这些超大型项目（超过1000人年）的基础上定义的。

同样，Fred Brooks 的《人月神话》也是建立在IBM开发OS/360操作系统的经验基础上的。所以，尽管Brooks在书中也提到了“由于人员的分工，大型编程项目碰到的管理问题和小项目区别很大”这一事实，但他的书仍然被用来支持软件工程背后的观点。

这些大型项目是真正的“系统工程”项目。这些项目通常同时包含硬件和软件的开发，其中硬件是专为与软件协作而开发的。这一类项目有一个共同的特点：在项目的前期，软件开发者需要等待硬件的开发，而在项目的后期，则是硬件开发者在等待软件的开发。软件工程正是在这样的一对矛盾中发展起来的。

等待硬件开发时，软件开发者在干什么？

在典型的软件工程项目的前期，软件开发者会有很多的时间。这时，硬件发明或者设计者设计尚未完成，所以软件开发者有大把的时间来做需求调研，并编写出详尽的软件设计规格书。他们根本不可能提前开始写代码，因为用于执行代码的硬件环境根本还不存在（在很多较早的规范中，在这一阶段甚至连编译器和代码加载器都还不存在）。有时，连编程语言都必须到项目的后期才能选定。所以，就算设计规格书已经巨细靡遗，提前开始编码也是毫无意义的。

这种情况下，“定义一个严格的需求获取过程，并通过这个过程生成详尽的、可复审的、一步到位的需求说明书”的做法就是有意义的。需求文档一旦完成，就可以交给设计团队；而设计团队则可以根据需求文档编写出极其详尽的设计规格书。我们都知道，硬件开发时相当费时的。就连为软件开发团队设计出一个可用的工程原型，也需要相当长的时间。所以，细致入微的设计复审也是软件工程开发过程中的一部分，因为软件设

页脚内容45

[标签:标题]

计团队有足够的时间来检查他们的设计。

得到可用的硬件之后，软件开发者如何加快交付的速度？

对于这个问题，最简单的答案就是：“投入大量的人手。”这也就是Steven Levy所说的“人海战术”，从SAFEGUARD项目的人力资源统计图中也可以明显地看出这一点。一旦硬件能够投入使用，软件开发者就应该立刻动手将详细设计规格转化成代码。为了获得最高的开发效率，还需要对代码进行复审，以保证其完全与详细设计规格相符，因为任何的偏差都可能导致下游的集成阶段出现问题。

这个阶段需要大量的人手，因为整个项目都在等待软件的编码和测试。所以，从设计到代码的转换过程越快越好，但后来人们将关注的焦点转移到“使用CASE工具自动从设计生成代码”上面。之所以出现这样的转变，是因为在完成编码之后，项目组仍然需要排除代码中存在的大量错误才能让整个系统正常运转。如果代码能够从设计规格自动生成，那么集成阶段的问题就会大大减少，项目也可以更快的完成。

传统开发过程的内蕴

软件工程项目需要大量的文档。在整个项目的过程中，需要3类不同的技术人员： 1.分析师，负责编写需求文档； 2.设计师，负责创建设计规格； 3.程序员，负责编写代码。

在每个阶段，每份文档的作者都必须在文档中加入额外的细节，因为他们无法知道随后将要阅读这份文档的人是谁。由于无法假设阅读者的知识背景，所以唯一安全的办法就是：将作者所知道的所有细节、所有交叉引用都写在文档中。然后，文档的复审者必须仔细浏览整个文档，以确定它是完善并且明白无误的。

完善的文档也带来了另一个难题：当在实现阶段需要对需求和设计做出修改时，团队成员必须修改所有相关的文档，以保证文档与真实系统之间的一致性。软件工程项目解决这个问题的办法是：确保从需求分析到代码实现的整个过程是完全可回溯的。无论在任何时候需要做出修改，这种可回溯性都将保证相关的文档和组件能够被发现并被更新。

这种文档驱动的开发方式也影响项目中人员的工作方式：设计师不愿意主动质疑分析师的文档，而程序员对设计方案的质疑或改进建议也是不受鼓励的——对与任何一份文档的修改都需要付出高昂的代价，因此所有的修改都必须受到严格的控制。

要想控制对文档的修改，一个很好的办法就是：定义一个分层的项目人员体系，将分析师放在最顶端，设计师次之，程序员位于最低的地位。而维持这一结论的办法则是：将优秀的设计师担任分析师角色。

软件工程的当代解读

在过去30年中，软件工程社群一直用“工程学”这个略显呆板的比喻来看待软件开发过程。现在，软件工程已经成为了计算机专业学生的一门必修课。在各个大学的计算机系中，软件工程也是一个活页的研究领域。人们最关注的是软件工程项目中那种确定的、可重复的开发方式。按照IEEE的定义，这种方式就是：

软件工程是指采用一种有组织、有纪律、可计量的方式来开发、使用及维护软件，也即在软件领域中对工程学的采用。

页脚内容46

[标签:标题]

对于强调安全性的软件系统，这种有组织、有纪律、可计量的开发方式已经被证明是非常有效的。例如，为航天飞机编写软件的团队就使用这种开发方式，并成功地获得了缺陷率极低的软件系统：

在这个程序的最后3个版本（平均代码长度为420 000行）中，每个版本只有一个错误；在其最后11个版本中，总共只有17个错误。同等复杂度的商用程度将会有5000个错误。

但是，在这样的过程中，其他的约束条件则不得不被放松：金钱不是关键的约束条件：项目组每年3500万美元的预算对于NASA来说不过是九牛一毛。但是，这个预算额就意味着每行代码价值1美元。这使得该项目组成为了全美国最值钱的软件组织。

从工程学的角度来说，这是一个恰当的利弊权衡。面对性命攸关的软件，人们毫无疑问会慷慨地用一切资源来确保系统不出错。但是，对于那些出错的代价相对较低的软件，又应该如何去开发呢？

“足够好的软件”——庶民的软件工程

对于某些软件来说，快速的开发出具有丰富功能的应用程序才是最重要的。这种观点的核心思想是：用户能够容忍程序中的错误，因为他们能够得到很多无法从其他地方获得的有用功能。正如Edward Yourdon所说：“我将在6个月之内交付一个系统，其中会有5000个错误——但你一定会非常高兴！” 实际上，“足够好的软件”只不过是软件工程思想的一个衍生物，它的出现完全合乎逻辑。它体现出了让人们在资源、进度、功能和缺陷等各方面做出的工程学权衡。航天飞机的软件最重视安全性，因此必须尽可能的减少其中的缺陷，并同时接受项目组为了提高质量而提出的资源、进度方面的要求；另一方面，打包的商用软件（例如文字处理软件、Web浏览器等）则要求开发者快速实现大量的功能，因此开发者就会很自然地做出“节省排除已知缺陷的时间从而压缩进度”的工程学权衡。这种权衡的核心思想是：对于某些类型的已知缺陷，花时间去排除它们并不经济。

软件工程适合你的项目吗？

需要同时开发全新的软/硬件系统的系统工程类项目显然是适合于使用软件工程方法的，很多国防项目和航天项目都可以归于这一类。如果我要乘坐一架数控驾驶的航天飞机飞向太空的话，我一定希望飞行控制软件的开发和检验是以一种“有组织、有纪律、可计量的方式”进行的。起码，如果听说这个软件是“由出价最低的软件公司开发的”，我的心里一定不会太好受。

另一个方面，如果你的企业需要开发大型的、打包销售的消费类软件，并且又善于作出恰低昂的工程学权衡，那么你很可能会使用“足够好的软件”这种方法。这类软件工程成功的秘诀就是以量取胜：消费类软件的市场充满了竞争，消费者决定是否购买某个软件的依据不是细致的比较，而是别人的评论和软件厂商的市场宣传，因此软件厂商只有以最低的价格卖出及其大量的产品才可能占据市场。

除了上述两种项目之外，对于其他类型的项目，你都需要寻找一种软件工程的替代品，因为软件工程并不适合于你的项目。

页脚内容47

[标签:标题]

第二章软件工程的困境

软件工程存在的最大问题就是：它假设那种“有组织、有纪律、可计量的开发方式”是唯一可行的方式。软件工程实际上是把工程学的隐喻强加于软件开发之上，从而使我们一叶障目不见泰山，看不到其他开发方式的存在。有一个例子能够将这一问题彰显无遗，那就是软件工程中的“缺陷可能性”和“缺陷排除率”这两个概念：

1.缺陷可能性：软件项目中预期可能存在的全木错误和缺陷。

2.缺陷排除率：在将软件项目发布给消费者之前，被排除的缺陷占潜在缺陷总数的百分比。

这种机械的观点忽略了一个事实：越好的程序员，所犯的错误就越少，并且发现错误也越快。教条主义的软件工程使我们忘记了软件的本质：真正决定项目成败的，是作为个体的程序员的技能、知识和经验。

Bill Curtis等人对大型软件工程项目进行了一组意义深远的现场调研。从这些调研结果中，我们可以清楚地看到杰出的设计师作为个体对整个项目所做的贡献以及他们的重要性：

每个项目组中都会有这样的一两个人。他们通常是资深系统工程师，他们在系统的设计中承担主要责任。在我们研究过的所有项目中，大约有三分之一的项目存在这样的情况：某个人对整个项目起主导作用，项目的发展方向由他决定，项目的成果依赖于他的工作成果。有时候，项目组的其他成员甚至会将他称为“救世主”。这些真正杰出的设计师拥有的应用领域知识比其他同事要丰富的多，因此，在我们的研究结果中，他们显得格外出类拔萃。他们是项目的一种稀缺资源。随后，这份研究报告还写道：

软件开发的传统观点往往认为：软件项目的成败不应该依赖于某个关键人物的发挥。但是，很多成功的大型项目的经验却告诉我们：这种理论一旦被利用于实践，可谓贻害无穷。优秀的设计师又有的领域知识不论在深度上还是在广度上都胜人一筹，而这些知识很难通过一组设计过程获得。所以，优秀的设计师的确是不可或缺、不可替代的。在期盼通过工程学的超度而达到“有组织、有纪律、可计量的开发方式”时，我们逐渐地迷惑了自己的头脑。其实，我们应该讨论的不是“项目缺陷的可能性”，而是“开发者的缺陷的可能性”。

道理很简单：优秀的设计师所犯的错误要比他们的同事们少得多，因此优秀设计师的“缺陷可能性”就比较低；同时，优秀的设计师也能够快地发现系统中的缺陷，因此他的“缺陷排除率”也比较高。对此，Fred Brooks 早已作出精辟的论断；

系统应该由尽可能少的人员来开发。实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢的、低效的,开发出的是缺乏概念完整性的产品。......得出的结论很简单：如果在一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。

简而言之，软件工程的关键问题就在于：它使我们忘记了“是人来开发软件”这样一个简单的事实。软件工程含蓄的给了我们一个承诺：只要能定义出一个有组织、有纪律、可计量的开发过程，任何人都可以成功地完成软件开发。可惜，这只能是一个梦想。正如Curtis的调研报告所表明的：就算有了一个理想的过程，想要获得项目的成功，出类拔萃的开发者仍然是必不可少的。所以，我们有必要认真考虑这样一个问题：如何培养软件开发者，才能使他们也有可能出类拔萃？不过，在回答这个问题之前，我们需要先解决另一个问题：所谓“有组织的软件开发过程”，究竟意味什么?

页脚内容48

[标签:标题]

“有组织的、可计量的”软件开发过程现实吗？

对于软件开发者来说，所谓“确定的、可重复的过程”真的能够达到吗？SCRUM软件开发过程的创始人曾经这样说道：

如果某个过程能够完全确定下来（即能够了解过程所涉及的所有细节，从而将其设计为可以重复地多次运行，并且完全能够预测其结果），那么该过程就被称为“确定过程”。从理论上来说，一切确定的过程都可以被自动完成。另一方面，如果人们并未了解某个过程中的所有细节，知识大致地知道在某些初始条件下、通过某些调节和控制就能得到想要的结果，这样的过程就被称为“经验过程”。

按照这个定义，软件开发不是一个确定的过程。实际上，我们所能希望获得的最好结果也就只是一个经验过程而已。之所以这样说，是因为所有的软件需求都来自于人。需求的获取无法自动完成，开发者必须和用户彼此沟通才能了解用户的真正需求。同样，用户也必须在与开发者的交流中了解项目中存在的技术局限性和克服这些局限所需要的开销，从而不断调整自己要求的功能，使软件项目的性价比达到最佳。

在软件开发者了解用户的需求之后，下一个问题就是：如何将这些需求记诸文档。在一个确定的开发过程中，我们应该从一开始就整理出完整而明确的需求。可是，在一般情况下，要想做到这一点难于登天。Gause和Weinberg曾经非常精辟的阐释过这个问题：对于一个简单的句子，“玛丽有一只小羊”，根据语句的重音不同，就可能有截然不同的含义：

玛丽有一只小羊。（是玛丽的羊，而不是约翰的。）玛丽有一只小羊。（他的确有这只羊，不是骗人的。）玛丽有一只小羊。（她只有一只羊，没有更多的。）玛丽有一只小羊。（这只羊真小，小的令人吃惊。）玛丽有一只小羊。（她拥有的是一只羊，而不是火鸡。）

从这个例子中，我们就可以清楚地看到：对于任何一种自然语言，实际上根本无法做到精确无误的地步。需求获取需求开发者与用户保持紧密的联系，即使在需求文档成型之后，开发者也需要不断的与用户交流，因为谁都无法保证需求文档中所写的内容不会有多种不同的解释。由于自然语言与生俱来的不精确性，你不可能喜欢一个确定而僵死的需求获取过程。

页脚内容49

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部频道

医院预约挂号系统的设计与实现