引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
1.1编写目的
说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。
1.2项目风险
具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：
任务提出者;
软件开发者;
产品使用者。
1.3文档约定
描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括：
正文风格;
提示方式;
重要符号;
也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。
1.4预期读者和阅读建议
列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：
用户;
开发人员;
项目经理;
营销人员;
测试人员;
文档编写入员。
并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
1.5产品范围
说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，或者业务策略相联系。
描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。
1.6参考文献
列举编写软件产品需求分析报告时所用到的参考文献及资料，可能包括：
本项目的合同书;
上级机关有关本项目的批文;
本项目已经批准的计划任务书;
用户界面风格指导;
开发本项目时所要用到的标淮;
系统规格需求说明;
使用实例文档;
属于本项目的其它己发表文件;
本软件产品需求分析报告中所引用的文件、资料;
为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：
标题名称;
作者或者合同签约者;
文件编号或者版本号;
发表日期或者签约日期;
2.综合描述
这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。
2.1产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况：
是否是产品系列中的下一成员;
是否是成熟产品所改进的下一代产品;
是否是现有应用软件的替代品(升级产品);
是否是一个新型的、自主型的产品。
如果该软件产品需求分析报告定义的软件系统是：
大系统的一个组成部分;
与其它系统和其它机构之间存在基本的相互关系。
2.2产品的功能
因为将在需求分析报告的第4部分中详细描述软件产品的功能，所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利读者理解本软件产品。
为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。
参考用户当前管理组织构架，了解各个机构的主要职能，将有助于陈述软件产品的主要功能。
2.3用户类和特性
用户不一定是软件产品的直接使用者，通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以，应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。
2.4运行环境
描述了本软件的运行环境，一般包括：
硬件平台;
操作系统和版本;
其它与该软件有关的软件组件;
与该软件共存的应用程序。
2.5设计和实现上的限制
确定影响开发人员自由选择的问题，并且说明这些问题为什么成为一种限制。可能的限制包括下列内容：
必须使用的特定技术、工具、编程语言和数据库;
避免使用的特定技术、工具、编程语言和数据库;
要求遵循的开发规范和标准
例如，如果由客户的公司或者第三方公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准;
企业策略的限制;
政府法规的限制;
工业标准的限制;
硬件的限制
数据转换格式标淮的限制。
2.6假设和约束(依赖)
计划使用的商业组件，或者其它软件中的某个部件;
假定产品中某个用户界面将符合一个特殊的设计约定;
有关本软件用户的若干假定(例如：假定用户会熟练使用SQL语言。);
有关本软件开发工作的若干假定(例如：用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。);
有关本软件运行环境的一些问题;
此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括：
工期约束;
经费约束;
人员约束;
设备约束;
地理位置约束;
其它有关项目约束;
3.外部接口需求
通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口，必须对接口数据和外部组件进行详细描述，并且写入数据定义中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的全部详细需求并入到这一部分实例中。
注意：必须将附加用户类的特征与外部接口需求加以区分，附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求;而外部接口需求描述的是接口本身的需求。
3.1用户界面
陈述需要使用在用户界面上的软件组件，描述每一个用户界面的逻辑特征。必须注意，这里需要描述的是用户界面的逻辑特征，而不是用户界面。以下是可能包括的一些特征：
将要采用的图形用户界面(GUl)标准或者产品系列的风格;
有关屏幕布局或者解决方案的限制;
将要使用在每一个屏幕(图形用户界面)上的软件组件，可能包括：
选单;
标准按钮;
导航链接;
各种功能组件;
消息栏;
快捷键;
各种显示格式的规定，可能包括：
不同情况下文字的对齐方式;
不同情况下数字的表现格式与对齐方式;
日期的表现方法与格式;
等等。
错误信息显示标准;
对于用户界面的细节，例如：一个特定对话框的布局，应该写入具体的用户界面设计说明中，而不能写入软件需求规格说明中。
如果采用现成的、合适的用户界面设计规范(标准)，或者另文描述，可以在这里直接说明，并且将其加入参考文献。
3.2硬件接口
描述待开发的软件产品与系统硬件接口的特征，若有多个硬件接口，则必须全都描述。接口特征的描述内容可能包括：
支持的硬件类型;
软、硬件之间交流的数据;
控制信息的性质;
使用的通讯协议;
3.3软件接口
描述该软件产品与其它外部组件的连接，这些外部组件必须明确它们的名称和版本号以资识别，可能的外部组件包括：
操作系统;
数据库;
工具;
函数库;
集成的商业组件
说明：这里所说的“集成的商业组件”，是指与系统集成的商业组件，而不是与软件产品集成的商业组件。例如：中间件、消息服务，等等。
描述并且明确软件产品与软件组件之间交换数据或者消息的目的。描述所需要的服务，以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必须使用一种特殊的方法来实现数据共享机制，例如：在多用户系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。
3.4通讯接口
电子邮件;
WEB浏览器;
网络通讯标准或者协议;
数据交互用电子表格;
消息格式;
通讯安全或加密问题;
数据传输速率;
同步和异步通讯机制;
4.系统功能需求
如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言之，必须选择一种是读者容易理解预期产品的组织方案。
用简短的语句说明功能的名称，例如：“4.1系统参数管理”。按照服务组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述4.1~4.3这三个部分。
可以通过各种方式来组织这一部分内容，例如采用：使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。
对应一些被共享的独立使用实例，可以定义一些公用系统功能。
必须特别注意的是，在2.2节“产品的功能”中描述的全部需求，以及它们的规格说明;必须在某个系统功能描述中有所反映，而且不应重复。
4.1说明和优先级
对该系统功能进行简短的说明，并且指出该系统功能的优先级是：高、中、还是低。需要的话，还可以包括对特定优先级部分的评价，例如：利益、损失、费用和风险，其相对优先等级可以从1(低)到9(高)。
4.2激励/响应序列
描述激励/响应序列时，不仅需要描述基本过程，而且应该描述可选(扩充)过程，包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程，有可能影响软件产品的功能;如果遗漏例外过程，则有可能会引发系统崩溃。
如果采用流程图来描述激励/响应序列，比较容易让用户理解。
4.3输入/输出数据
列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法，以及相应地输出数据，描述对应区别：输入数据和输出数据。
当有大量数据需要描述时，也可以分类描述数据，并且注明各项数据的输入、输出属性。
对于每一项数据，均需要描述：
数据名称;
实际含义;
数据类型;
数据格式;
数据约束;
5.其它非功能需求
在这里列举出所有非功能需求，主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1性能需求
阐述不同应用领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定：
相互合作的用户数量;
系统支持的并发操作数量;
容量需求
存储器;
磁盘空间;
数据库中表的最大行数。
5.2安全措施需求
5.3安全性需求
5.4软件质量属性
详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点，例如：易用性优于易学性，或者可移植性优于有效性。
5.5业务规则
列举出有关软件产品的所有操作规则，例如：那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。一个业务规则的范例如下：“进行达到或者超过10，000，00元人民币的储蓄业务时，必须通过附加的管理员认证。”
列举业务规则时，可以根据规则的数量，选取合适的编目方式。
5.6用户文档
列举出将与软件产品一同交付的用户文档，并且明确所有己知用户文档的交付格式或标准，例如：
安装指南
纸质文档，16开本;
用户手册
在线帮助
电子文档，与软件产品一同分发、配置;
使用教程电子文档，与软件产品一同分发、配置。
6.词汇表
7.数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述：含义、类型、数据大小、格式、计量单位、精度以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。
如果为软件开发项目创建一个独立的数据定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇总。
在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下：
原数据元素
一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其
含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行
注释文本，描述原数据元素的定义。
选择项
选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方
括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。
组合项
组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元
素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定
义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有
可选项，使用圆括号把该项括起来。
重复项
重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号
把该项括起来。如果知道该项可能允许的范围，就按“最小值：最大值”的形式写在花
括号前。
8.分析模型
数据流程图;
类图;
状态转换图;
实体-关系图。
关键词：高校后勤财务管理模式信息化平台
中图分类号：G475文献标识码：A
评价一个财务信息系统成功与否的关键在于这个系统是否完成预期的建设目标，是否给高校的后勤财务管理带来效率和水平的真正提高。在财务信息化平台的建设过程中，可充分利用高校应运而生并迅速发展起来的新的信息技术手段和现代化设备，进一步拓展财务管理信息系统的各项功能，向集高校后勤财务管理与信息化校园于一体的“一体化”管理方向迈进。因此，高校后勤财务信息化平台应以账务核算、预算管理、资金管理和项目管理等模块建设为核心，结合校园一卡通系统，整合形成校园后勤管理的一整套业务流程。
一、后勤财务信息化的需求与系统管理目标的设计
（一）后勤财务信息化的需求分析
从高校后勤管理的实际出发，针对高校具体的财务管理状况和管理目标进行调研，作出符合实际情况的后勤财务信息化需求分析和评价。对于要达到的既定目标，既要用发展的眼光又不能脱离现实条件，尽可能细化、量化好系统需求方案制定前的组织调研工作。
1.理清高校的管理体制和结构。高校的办校规模不同，管理体制也不尽相同，无论是哪一方面的管理都要服务并服从于高校的整体管理，后勤财务信息系统要为学校的财务管理服务这一点无可厚非。部分高校多个校区，属于多级次的管理体制。管理体制的差异影响财务信息系统组织机构的功能设置，并对实施方案中的软硬件环境（诸如网络环境、软硬件设备的选择、人员的配备和岗位的设置）等要求产生影响。因此，只有明确了整个财务管理的组织结构以后，才能对财务信息系统的建设作出既科学又实用的规划和设计方案。
2.确定目标工作流程。完成系统需求分析后，要着手对后勤财务信息系统运行的整个工作流程进行分析和前景规划。通过对后勤财务信息系统工作流程与现行的财务工作流程进行比较，如果两个流程的差异很大，那么应该及时同财务主管领导做细致的沟通，分析可能出现的问题，杜绝可能出现的漏洞，确认目标工作流程的可操作性。为方便今后开展工作，经过反复研究论证后的最终工作流程的分析报告也需要得到财务主管领导的签字认可，方能进行下一步的工作。
3.信息化平台的目标定位。对于将要建设的后勤财务信息系统需要达到的目标应该有一个相对准确的描述和合理定位，包括这个系统要实现的功能目标和性能目标，以及为实现这样的目标对整个系统要进行多大规模的资金和人力投入，怎样投入等。整个系统建设周期的计划是什么，阶段性目标是什么，特别是如何进行对系统建设完工后的验收、使用和评价等。
4.出具需求分析报告。通过前期各阶段的准备工作，对系统的需求分析进行了论证调研得出结论后形成书面报告。需求分析报告将成为系统设计的依据和今后系统改造的基础资料。
（二）设计信息管理系统的目标方案
详细了解高校后勤财务管理状况以后，作出对具体的财务管理需求的分析报告，设计制定目标方案。理论上，财务信息化的目标与财务管理的目标应该保持一致，但我们必须要考虑财务信息化的阶段性发展问题这一客观因素的存在。不同阶段会面临要解决不同的问题，不能一刀切的看待遇到的各种障碍性因素，更不能主观期望从一开始就解决所有的财务管理问题，这种想法是不切实际的。在开始设计具体的实施方案前，对高校的财务管理状况要有一个比较整体、客观和细致的了解。要内外兼明，尤其是对于高校后勤现行的财务管理体制、上级部门的支持情况、部门内部的业务流程、人员配备和岗位设置情况，以及高校整体的信息化水平、软硬件环境等做一个比较细致的调查。应当明确高校后勤目前最迫切需要解决的财务管理问题，通过信息化平台建设能否解决这一问题，能否做到通过一定程度上制度的变革来为财务信息化扫清障碍，领导层是否做好了这方面的思想准备。因为，当我们决定开始启动财务信息系统后，都会在一定程度上引发财务管理体制“地震”，因而需要事前做好方方面面的准备工作。
二、后勤财务信息管理系统的建设
根据已经确定的需求分析报告对后勤财务信息管理系统进行规划、设计，制订出具体的设计方案。设计方案的内容包括：系统的网络环境要求、系统需要的硬件和软件配置、财务信息系统软件的选购、系统的运行维护、人员和岗位配置等，整合这些具体的设计方案就形成一个相对完整的后勤财务信息系统设计。
（一）硬件平台的设计与构建
2.服务器及周边设备的选型与配置。服务器的选择非常重要，在选择前要先咨询这方面的专家。系统的应用规模和发展趋势是选择服务器种类的重要考量因素。同时要考虑到发展的需要，适当留有冗余。服务器工作环境要得到保障，条件允许的情况下，服务器最好设在通风、散热条件好、环境整洁的独立机房内。
（二）软件平台的建设
1.操作系统软件的配置。当前应用较广的操作系统有Linux、Unix、WindowsServer系列等等。高校在建信息系统的软件平台时，常会选择一种作为主要的操作系统软件。不过，也有混用的情况，如果从管理便捷性方面考虑，多种操作系统并用的情况往往会出现系统不兼容的现象，因此不利于管理。
2.选择数据库系统软件。数据库系统软件在很大程度上直接影响到系统处理财务信息的效率和质量。目前常用的数据库软件有SQLServer、Informix、Oraele、MySQL等，这些数据库软件在性能方面各有各的特点。不同操作系统对软件功能要求也有所不同。在建设财务信息化平台之前，要根据后勤财务管理的要求，同时考虑其他管理系统的需求，以便选择更适合后勤财务管理的数据库软件系统。
三、财务信息化平台的实施
（一）硬件平台的运行
系统硬件平台能够稳定的运行取决于很多因素，包括服务器及其配套设备、网络设备、备用电源供给、客户端设备配置等。硬件平台系统运行的稳定性、数据的安全保障是首要和重点考虑因素。财务信息系统因其功能的特殊性，在硬件设备配置的选择方面要求相对较高。首先做好网络设备的暗转与调试，其次做好服务器及周边硬件设备的安装与调试。
（二）软件平台的运行
［基金项目：黑龙江省教育会计学会科研课题，编号：1155KJXH402；黑龙江省人文社会科学研究项目，编号:11552175］
参考文献：
1.肖富宁.高校财务信息化建设若干问题的探讨.首都经济贸易大学硕士论文，2009
2.许永斌.我国电算化会计信息系统模型改造理论基础.会计研究，1996
3.薛云奎，饶艳超.会计信息系统(第二版).复旦大学出版社，2008
4.于金红.税务会计应用的障碍性因素及发展思路研究.财会研究，2011（12）
5.王海林.试论会计信息系统运行阶段的风险与控制.会计之友，2009（1）
6.邹秀华.高校财务管理信息化建设研究.中国科技信息，2008（3）
与传统的教学方式相比，项目教学对教师能力提出了更高的要求，其中最核心的要求是教师要科学地选择好课程项目内容，并具有课程项目开发和管理的实践经验。而目前职校的计算机教师基本上接受的都是学历性教育，虽然他们理论功底较扎实，也掌握了一定的教学方法和技巧，但是站在讲台上绝大多数还处于以理论解释理论的“纸上谈兵”状态。试想一个没有亲身经历项目系统开发的人，怎能能够“以就业为导向”、“以项目为主线”来开展好项目教学呢？
以能力为本位，设置项目
首先了解公司的实际用人需求、对员工的培养模式、软件开发的实际流程，对比出我们教学的不足与差距，探索出项目教学的目标，人才培养的方案；其次，联系学校的实际需求，与公司合作，将课程开发项目定位为既满足学校的应用需求，又满足教学需求的《学生信息管理系统》。
通过市场调研，教师亲自接触了用人市场，明确了学生的就业需求，教学中就能够以学生能力为本位，实现了人才培养与上岗就业“零距离”接轨的教学培养目标。
以市场为中心，分析项目
结合在软件公司的实地考察学习经验，在设计人员的指导下，按照公司项目开发的实际工作流程，我们首先编制了本课程项目的开发流程:需求分析方案设计系统设计项目实施调试运行。
从流程中可以看出，需求分析是项目开发和管理的基础。在项目开发中，所有的项目风险承担者对需求分析阶段都倍感兴趣。因为这部分工作做的到位，就易于开发出很优秀的软件产品，同时也会令客户满意；若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。
学生没有接触过市场和客户，这就需要教师在教学中将这方面的感受和经验传授给学生，因此教师首先要有接触市场的真实体会，并总结出方法和技巧。
按照这种思路，通过对学生科、教务科、班主任和任课教师等重要用户的反复调研，明确了用户的功能需求，建立了《学生信息管理系统》的系统用例图。
经过客户需求的调研，制作和反复修改需求分析报告，使得教师积累了市场经验。在日后的教学中，他们可以用实践经历向学生讲述软件开发需求调研的全部过程，需求分析在软件开发中的重要地位；同时把停留在书本上的理论化的职业道德转化为具体的道德实践，为学生形成良好的职业道德和规范化职业行为树立典范。这些是书本上永远学不到的知识
以就业为导向，实施项目
职业学校计算机数据库教学培养的人才就业方向为：了解数据库应用项目的开发流程，能够从事项目的初级编码或开发、软件调试及技术服务与软件销售等工作的专业人员。
初到岗位就业的毕业学生，基本上都是在设计人员设计思路指导下，展开项目的开发和编码工作，那么在学校的教学中，教师就要充当设计指导人员的角色。因此，要求教师具有数据库设计、实施的实践经验和科学的指导思想。在项目设计和实施的环节，就是以学生的这种就业需求为导向，来锤炼教师的设计思想，丰富项目实施经验。
在项目设计环节，首先教师通过学习软件设计理论，参考公司的典型案例，按照系统的功能需求分析，设计了《学生信息管理系统》的软件结构层次图；其次教师在认真分析本项目的数据要求的基础上，编制了系统的E-R图，并实现了E-R图向关系模型的转换。
通过数据库的设计，使项目开发的教师对规范、实体、属性、关系、字段等数据库概念有了进一步的理解，并使E-R、E-R到关系模型转换原则等难度大的理论在实践中得到了充分应用。
在项目实施环节，通过数据库建立、界面设计、代码编写和程序测试等几个阶段，
使得教师进一步在深度和广度上拓展了专业理论，掌握了所学专业、所任课程较为系统完整并具有前沿性的专业知识；强化了专业实践能力，锤炼了教师的设计思想，丰富了项目实施经验，提升教师解决特定问题的能力；进而促使教师根据职业教育的特征要求，进行有效的专业知识的整合优化与适度转化，形成满足学生专业实践能力培养所需的知识结构，更好地把握了以学生的就业需求为导向的教学原则。
以学生为主体，应用项目
《学生信息管理系统》开发的最终目的，一方面是成为真正的应用产品，实现了学校学生信息管理的信息化。软件在全校的使用提升了教师在学生中的威望，同时也扩大了该项目在学生中的影响力，激发了学生的学习积极性。
通过教学经验的积累，教师探索出了项目教学的基本规律和教学技巧，顺利地实现了教学中师生角色的重新定位；同时原有的教材已无法满足所开发课程项目的教学，它引导教师在对原有教材进行整合的基础上，逐步进行数据库项目教学校本教材的开发。
教师通过科学地选择项目，直接参与课程项目的设置、分析、实施和应用，有效地提高了自身的项目教学能力，促进了数据库课程的教学改革与发展，实现人才培养与上岗就业“零距离”接轨的教学培养目标。
参考文献
【关键词】计算思维；教学改革；数据库；PBL教学方法
2006年3月，美国卡内基·梅隆大学计算机科学系主任周以真（JeannetteM.Wing）教授在美国计算机权威期刊《CommunicationsoftheACM》杂志上发表的《ComputationalThinking》一文中定义了计算思维（Comp-utationalThinking）的概念，即计算思维是运用计算机科学的基础概念进行问题求解、系统设计以及人类行为理解等涵盖计算机科学之广度的一系列思维活动。计算思维是每个人的基本技能，不仅仅属于计算机科学家。
1.引言
医学生学习任务繁重，理工基础相对薄弱，记忆式学习占主导地位。医学院校传统的《数据库基础》教学往往采取“以教师为主导”的教学模式，即“教师讲什么，学生学什么，考试考什么”的灌输式的教学，学生的学习思维始终被教师牵制。教师单纯注重知识链条的系统性和完整性，力图做到把知识点“讲全讲细”，忽略了医学生的自身特点，没有将数据库知识与医学生所学专业有机的结合起来，没有将计算思维的本质即抽象（Abstraction）和自动化（Automation）的思想有效的灌输给学生，造成医学生的学习兴趣普遍不高，教学效果不甚理想。
为了改变这种落后的教学局面，对原有的教学模式重新进行了规划和设计，从培养兴趣出发，结合医学专业特色，采用PBL教学方法和任务驱动等教学方法，将科学的逻辑思辨能力和计算思维融入课堂教学环节，大幅提升了教学效果。
2.教学改革的实施过程
（1）教学分组
为了验证教学改革是否有效，将教授的法医学专业学生分成2组（每组30人），一组采用基于计算思维的教学模式进行教学（以下简称组一教学），另一组采用基于非计算思维的教学模式进行教学（即传统的教学模式，以下简称组二教学）。
（2）项目选题与实施
在组二教学中，采用传统的教学方式，在学期结束前3周由教师统一布置《住院信息管理系统》的开发项目，将学生以5-6人为规模进行分组，指定组长，采取组长负责制，由组长负责子模块的划分，组员独立完成子模块的设计，完成整个项目系统的开发工作。
（3）教学改革评价
在学期结束后向学生就教学改革中所涉及的8个方面进行了认可程度的问卷调查（见表1），发放60份，收回有效问卷58份。对所收集到的数据进行t检验的成对二样本统计分析，其P
3.讨论
但由于计算思维本身的抽象性和高度概括性，如何理解计算思维的本质和内涵，如何确定计算思维的内容和体系，如何着手培养学生的计算思维等，还需要广大计算机教育工作者继续深入的探索。
[1]董荣胜.计算思维与计算机导论[J].计算机科学，2009（4）：50-53.
[2]董荣胜，古天龙.计算思维与计算机方法论[J].计算机科学，2009，36（1）：1.
[3]周以真.计算思维[J].中国计算机学会通讯，2007，3（11）.
[4]宋晓荣，姬明丽，司艳莉，刘友才.研讨式教学法在机能学综合实验教学中的应用[J].新乡医学院学报，2011，28（3）：399-400.
[5]陈杰华，戴丽娟.以培养计算思维为核心的程序设计实验教学[J].实验技术与管理，2011，28（1）：125-127.
[6]廖伟志，李文敬，王汝凉.计算思维在离散数学课堂教学中的应用[J].计算机科学，2008（（11）.
[7]王荣良.信息技术课程中算法学习的价值探索[J].中国电化教育，2008（8）：78-81.
[8]萨师煊，王珊.数据库系统概论[M].北京：高等教育出版社，2006.
[9]朱立平，林忐英.基于思维教学理论的程序设计课程教学模式的构建[J].计算机教育，2008（8）.
关键词：航空；安全；设计
2.航空安全培训模块：在本功能中主要是通过web页面提供封装的前台信息，系统服务对这些信息进行处理和存储，服务在业务处理完成后将生成相应的数据存储在数据库中，用户通过页面能够查询或浏览到计划信息。通过设计培训更新、查询等服务对数据库中的培训记录进行访问，提高了访问的效率和安全性。在本系统中设计了各种考核页面，用户可以通过在页面中指定培训id，系统将根据培训的内容生成考核的内容，用户通过考试页面完成考核内容的填写，提交给系统进行保存，考核部门给出考核评价意见。
3.风险管理模块：风险采集，该功能完成对指定位置信息的采集和由人工进行风险提供的工作，本功能设计风险设备管理和风险设备参数设定功能，通过该功能使用者能够对风险设备的信息进行查询和管理。风险评估，在本功能中提供了风险评估方法和参数的调整功能，对不同的类型风险进行评估时所采用的评估方法是不同的，因此在页面中提供了风险评估方法的定义和修改。风险决策，在本功能中为了能够使决策具有合理性，系统提供了多个人员对风险决策进行评阅的功能，在页面中提供了多人决策的内容，不同的人员可以对统一风险进行决策，同时在系统生成决策报告时，必须由多个决策人员都填写意见后才能生效。
4.飞行管理模块：该模块完成对飞行前的检查工作，在本模块中设计了多个检查流程，该流程的作用是完成对飞行准备工作的核查，任何一项核查没有通过都不能进行实施。飞行实施模块，该模块完成飞行过程的记录工作，其中包括对飞行航线、飞行参数、飞行通信信息的记录工作，同时为了能够方便用户实施跟踪飞机的飞行轨迹，通过调用GPS数据在页面上进行实时轨迹显示。
二、航空安全是航空企业生产的重点，由于航空安全贯穿了生产过程，因此在目前的航空企业管理中，存在信息系统结构简单、兼容性差的问题，在不同的部门间存在信息难以交流，工作重复开展的问题，给航空企业带来了资源、人力、物力的浪费。
为了解决航空企业安全管理中存在的问题，在信息化建设的基础上，对本企业航空安全管理工作进行系统化的调研、分析和论证，最终结合软件系统的开发经验设计并实现了航空安全管理系统，实现了对航空企业安全管理工作的统一化、信息化和智能化，提高了企业管理的效率和质量，同时为企业信息化提供了一条新的建设思路。
1.完成了航空安全管理工作的需求分析和项目建设的可行性分析，首先通过在本企业的系统化调研，对企业中安全管理工作进行了梳理和整合，形成了具有权威性的需求分析报告，依据需求分析内容对软件系统开发的经济、技术的投入进行了论证和分析，证实了航空安全管理系统建设具有必要性和可行性。
2.完成了航空安全管理系统的总体结构的设计，根据航空安全系统的需求分析和软件设计的规范，设计了安全管理系统的总体结构，规范了数据库设计的方法和软件开发方法，并完成了数据库结构的设计。确定软件开发采用JAVA语言、B/S结构，数据库管理系统采用oracle数据库。
3.完成了航空安全管理系统的具体功能的设计与实现，根据软件的总体设计规划，对飞行管理子系统、风险管理子系统、安全培训子系统和维护管理子系统具体功能进行了编码和实现，在WEB开发中采用了S2SH架构。
4.完成了航空安全管理系统的测试工作，依据软件测试规范和系统的需求分析设计了科学合理的测试方案，采用了人工和工具测试相结合的方法，从模块、集成、系统三个阶段完成了测试工作，证实了航空安全管理系统具有功能全面性，性能稳定性，满足了航空企业进行信息化安全管理的需求。
三、航空安全管理工作是一项长期存在的工作，从其业务的范围呈现逐步扩大的趋势，所以在航空企业中，安全管理将成为工作的重点，结合国外航空安全管理系统的实例和软件技术发展的趋势，本项目的研究未来具有以下趋势：
1.充分结合物联网技术，通过物联网技术实现大量人工操作到传感器的转移，人工工作逐步向管理转移。
2.未来的发展将webgis技术进行很好的应用，对于企业安全管理将采用基于可视化的webgis技术。
3.大数据技术将被应用于航空企业信息的分析和管理，通过大数据技术实现对数据的可靠、可信、高效的管理。
[1]詹敏，孟予希.航空安全信息管理与决策辅助系统框架研究[J].科技促进发展.2012，（03）
[2]田波，吴倩，甄浩.航空公司信息安全管理系统的构建与安全保障体系研究[J].情报科学.2011，（09）
[3]朱雪飞.航空公司安全管理系统（SMS）项目的建设与应用研究[D].山东大学2013
[4]LIFeng，LIUXiao-jie，LINHan-he.TolerantsystembasedonOracle[J].ComputerEngineeringandDesign，2011（11）
关键词：
应用型；基于项目；实践训练；答辩考核
一、教学内容的改革
目前《软件工程导论》课程的教学内容包括：软件开发基础知识，需求分析，总体设计、详细设计、编码、测试[2]、项目管理这些内容，采用的是结构化的软件开发方法。之前我们只讲理论知识，特别是开发过程中的一些技术和软件，但是学生学完即使会做题也不会开发项目。现在，我们将教师实际参与开发的项目带领学生从需求开始分析，进行总体设计和详细设计加入到授课内容中，结合实际的项目开发的内容，把理论和实践相结合。学生边学理论知识，边完成自己的项目，可以将学到的知识应用到项目中，做到学有所用。希望培养学生整体软件开发的方法、软件项目管理能力、软件需求分析能力、数据库设计能力、人机交互设计能力、软件测试计划及方案的制定能力、课程报告撰写能力、学习态度等各方面能力。
二、教学方式方法的改革
三、考核方法的改革
作者：苏丹邹红崔晓微仲晓庆马英瑞单位：大庆师范学院
[1]王菁华.地方高校向应用型转型必须实现三个根本转变[J].职业教育，2016.