数据库需求分析报告范例6篇

前言:中文期刊网精心挑选了数据库需求分析报告范文供你参考和学习,希望我们的参考范文能激发你的文章创作灵感,欢迎阅读。

数据库需求分析报告

数据库需求分析报告范文1

引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。

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开本;

用户手册

纸质文档,16开本;

在线帮助

电子文档,与软件产品一同分发、配置;

使用教程电子文档,与软件产品一同分发、配置。

6. 词汇表

列出本文件中用到的专业术语的定义,以及有关缩写的定义(如有可能,列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析 报告,要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语,是指业务层面上的专业术语,而不是软件专业或者计算机专业的术 语。但是,对于无法回避的软件专业或者计算机专业术语,也应该列入词汇表并且加以准确定义。

7. 数据定义

数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档,其中对每个数据元素和结构都准确描述:含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明,并且在软件产品开发和维护的任何阶段,均向风险承担者开放。

如果为软件开发项目创建一个独立的数据定义,而不是为每一项特性描述有关的数据项,有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告,容 易遗漏数据,也不方便阅读。因此还是建议为每个特性描述有关的数据项,汇总数据项创建数据定义,再根据数据定义复核全部数据,使得它们的名称和含义完全一 致。必须注意的是,为了避免二义性,在汇总数据项时应该根据数据项所代表的实际意义汇总,而不是根据数据项的名称汇总。

在数据定义中,每个数据项除了有一个中文名称外,还应该为它取一个简短的英文名称,该英文名称应该符合命名规范,因为在软件开发时将沿用该英文名称。可以使用等号表示数据项,名称写在左边,定义写在右边。常见数据项的描述方式如下:

原数据元素

一个原数据元素是不可分解的,可以将一个数量值赋给它。定义原数据元素必须确定其

含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行

注释文本,描述原数据元素的定义。

选择项

选择项是一种只可以取有限离散值的特殊原数据元素,描述时一一枚举这些值,并用方

括号括起来写在原数据元素的定义前。在两项离散值之间,使用管道符分隔。

组合项

组合项是一个数据结构或者记录,其中包含了多个数据项。这些数据项可以是原数据元

素,也可以是组合数据项,各数据项之间用加号连接。其中每个数据项都必须是数据定

义中定义过的,结构中也可以包括其它结构,但是绝对不允许递归。如果数据结构中有

可选项,使用圆括号把该项括起来。

重复项

重复项是组合项的一种特例,其中有一项将有多个实例出现在数据结构中,使用花括号

把该项括起来。如果知道该项可能允许的范围,就按“最小值:最大值”的形式写在花

括号前。

8. 分析模型

这是一个可选部分,包括或涉及到相关的分析模型,例如:

数据流程图;

类图;

状态转换图;

实体-关系图。

数据库需求分析报告范文2

关键词:高校后勤 财务管理模式 信息化平台

中图分类号:G475 文献标识码:A

文章编号:1004-4914(2012)05-094-02

评价一个财务信息系统成功与否的关键在于这个系统是否完成预期的建设目标,是否给高校的后勤财务管理带来效率和水平的真正提高。在财务信息化平台的建设过程中,可充分利用高校应运而生并迅速发展起来的新的信息技术手段和现代化设备,进一步拓展财务管理信息系统的各项功能,向集高校后勤财务管理与信息化校园于一体的“一体化”管理方向迈进。因此,高校后勤财务信息化平台应以账务核算、预算管理、资金管理和项目管理等模块建设为核心,结合校园一卡通系统,整合形成校园后勤管理的一整套业务流程。

一、后勤财务信息化的需求与系统管理目标的设计

(一)后勤财务信息化的需求分析

从高校后勤管理的实际出发,针对高校具体的财务管理状况和管理目标进行调研,作出符合实际情况的后勤财务信息化需求分析和评价。对于要达到的既定目标,既要用发展的眼光又不能脱离现实条件,尽可能细化、量化好系统需求方案制定前的组织调研工作。

1.理清高校的管理体制和结构。高校的办校规模不同,管理体制也不尽相同,无论是哪一方面的管理都要服务并服从于高校的整体管理,后勤财务信息系统要为学校的财务管理服务这一点无可厚非。部分高校多个校区,属于多级次的管理体制。管理体制的差异影响财务信息系统组织机构的功能设置,并对实施方案中的软硬件环境(诸如网络环境、软硬件设备的选择、人员的配备和岗位的设置)等要求产生影响。因此,只有明确了整个财务管理的组织结构以后,才能对财务信息系统的建设作出既科学又实用的规划和设计方案。

2.确定目标工作流程。完成系统需求分析后,要着手对后勤财务信息系统运行的整个工作流程进行分析和前景规划。通过对后勤财务信息系统工作流程与现行的财务工作流程进行比较,如果两个流程的差异很大,那么应该及时同财务主管领导做细致的沟通,分析可能出现的问题,杜绝可能出现的漏洞,确认目标工作流程的可操作性。为方便今后开展工作,经过反复研究论证后的最终工作流程的分析报告也需要得到财务主管领导的签字认可,方能进行下一步的工作。

3.信息化平台的目标定位。对于将要建设的后勤财务信息系统需要达到的目标应该有一个相对准确的描述和合理定位,包括这个系统要实现的功能目标和性能目标,以及为实现这样的目标对整个系统要进行多大规模的资金和人力投入,怎样投入等。整个系统建设周期的计划是什么,阶段性目标是什么,特别是如何进行对系统建设完工后的验收、使用和评价等。

4.出具需求分析报告。通过前期各阶段的准备工作,对系统的需求分析进行了论证调研得出结论后形成书面报告。需求分析报告将成为系统设计的依据和今后系统改造的基础资料。

(二)设计信息管理系统的目标方案

详细了解高校后勤财务管理状况以后,作出对具体的财务管理需求的分析报告,设计制定目标方案。理论上,财务信息化的目标与财务管理的目标应该保持一致,但我们必须要考虑财务信息化的阶段性发展问题这一客观因素的存在。不同阶段会面临要解决不同的问题,不能一刀切的看待遇到的各种障碍性因素,更不能主观期望从一开始就解决所有的财务管理问题,这种想法是不切实际的。在开始设计具体的实施方案前,对高校的财务管理状况要有一个比较整体、客观和细致的了解。要内外兼明,尤其是对于高校后勤现行的财务管理体制、上级部门的支持情况、部门内部的业务流程、人员配备和岗位设置情况,以及高校整体的信息化水平、软硬件环境等做一个比较细致的调查。应当明确高校后勤目前最迫切需要解决的财务管理问题,通过信息化平台建设能否解决这一问题,能否做到通过一定程度上制度的变革来为财务信息化扫清障碍,领导层是否做好了这方面的思想准备。因为,当我们决定开始启动财务信息系统后,都会在一定程度上引发财务管理体制“地震”,因而需要事前做好方方面面的准备工作。

二、后勤财务信息管理系统的建设

根据已经确定的需求分析报告对后勤财务信息管理系统进行规划、设计,制订出具体的设计方案。设计方案的内容包括:系统的网络环境要求、系统需要的硬件和软件配置、财务信息系统软件的选购、系统的运行维护、人员和岗位配置等,整合这些具体的设计方案就形成一个相对完整的后勤财务信息系统设计。

(一)硬件平台的设计与构建

1.规划和设计网络环境。通常情况下,单一校区的高校后勤多采用集中式财务管理模式,规模较大的高校后勤则采用分级管理。规模较大且多个校区的高校比较适合采取分散布局、集中管理的模式。建设后勤财务信息管理系统时,不同的管理模式对网络环境的要求也不一样。在设计后勤财务管理信息系统建设的方案时,一般都会优先考虑财务网络的建设方案。单一校区的高校,往往选择物理上与其他网络隔离的独立的网络环境,这样的网络环境安全系数比较高,缺点是与其他管理系统的数据共享和交换受限。规模较大且拥有多个校区的高校,在选择后勤财务信息管理系统的网络环境时,要考虑的因素就相对复杂得多。首先要考虑的是安全因素,其次要考虑到建设实施的成本问题。在校区间相距较远的条件下,构建独立的财务专用网络会产生较高的成本,这样建设难度就比较大。近些年来,高校的校园网络建设和发展速度较快,绝大部分高校都拥有自己的校园网,这是发展的必然趋势。所以,通过依托“校园网”建设“财务局域网”成为一种较好的解决方案。利用VNP技术,依托校园网搭建一个财务专网,成为一种较为现实可行的做法,因为这种做法不仅大大降低了建设成本,而且在技术上和安全性能上也有一定的保障。网络布局方案设计完成后,还应考虑网络环境建设需要的网络设备条件。网络设备的挑选通常按性能价格比的原则,在建设资金保障充分的前提下,可选择稳定性好、质量高的产品。

2.服务器及周边设备的选型与配置。服务器的选择非常重要,在选择前要先咨询这方面的专家。系统的应用规模和发展趋势是选择服务器种类的重要考量因素。同时要考虑到发展的需要,适当留有冗余。服务器工作环境要得到保障,条件允许的情况下,服务器最好设在通风、散热条件好、环境整洁的独立机房内。

(二)软件平台的建设

1.操作系统软件的配置。当前应用较广的操作系统有Linux、Unix、WindowsServer系列等等。高校在建信息系统的软件平台时,常会选择一种作为主要的操作系统软件。不过,也有混用的情况,如果从管理便捷性方面考虑,多种操作系统并用的情况往往会出现系统不兼容的现象,因此不利于管理。

2.选择数据库系统软件。数据库系统软件在很大程度上直接影响到系统处理财务信息的效率和质量。目前常用的数据库软件有SQLServer、Informix、Oraele、MySQL等,这些数据库软件在性能方面各有各的特点。不同操作系统对软件功能要求也有所不同。在建设财务信息化平台之前,要根据后勤财务管理的要求,同时考虑其他管理系统的需求,以便选择更适合后勤财务管理的数据库软件系统。

3.选择财务管理系统软件。在选择财务管理系统软件时要考量多方面的因素,软件应用的核心问题是它的配置。财务管理软件系统是整个财务信息系统运行的载体。财务管理软件取得的途径有两种:一是购买,另外一种是自行开发。在后勤财务信息化平台建设过程中,高校后勤财务管理系统软件的规划与选择是核心工作,一方面要考察财务管理系统软件在功能上是否能够满足高校后勤财务管理的需要,另一方面还要考虑自身的个性化需求。现在绝大多数高校都采用直接购买的方式取得软件,因为,这种方式的建设周期可以大大缩短,而且没有开发风险,系统运行也会比较稳定。但是,这种商品化软件通常都是通用软件,很可能存在短时间内无法满足单位的个性化需求的问题。

三、财务信息化平台的实施

(一)硬件平台的运行

系统硬件平台能够稳定的运行取决于很多因素,包括服务器及其配套设备、网络设备、备用电源供给、客户端设备配置等。硬件平台系统运行的稳定性、数据的安全保障是首要和重点考虑因素。财务信息系统因其功能的特殊性,在硬件设备配置的选择方面要求相对较高。首先做好网络设备的暗转与调试,其次做好服务器及周边硬件设备的安装与调试。

(二)软件平台的运行

要保证软件平台的正常运行,首先要做好操作系统软件和数据库软件的安装工作,然后进行财务管理软件系统的安装和调试。这时应注意确定财务管理信息子系统的使用规模和顺序。通常高校后勤在安装使用新系统过程中,首先要保证历史工作的正常运转和延续,因而会比较谨慎地选择一个或者几个有把握的子系统进行试运行,待稳定运行一个阶段后再使用其他子系统。当然,也有高校采用新旧系统同时运行一段时间的方法。各高校可根据自身的实际情况进行选择。另外,财务软件的初始化工作也是非常关键的环节之一。系统初始化的工作不仅重要,而且工作量也很大。为了保证财务信息系统安全、稳定地运行,同时还要在服务器和客户端上一并安装防病毒软件、数据备份软件等。

[基金项目:黑龙江省教育会计学会科研课题,编号:1155KJXH402;黑龙江省人文社会科学研究项目,编号:11552175]

参考文献:

1.肖富宁.高校财务信息化建设若干问题的探讨.首都经济贸易大学硕士论文,2009

2.许永斌.我国电算化会计信息系统模型改造理论基础.会计研究,1996

3.薛云奎,饶艳超.会计信息系统(第二版).复旦大学出版社,2008

4.于金红.税务会计应用的障碍性因素及发展思路研究.财会研究,2011(12)

5.王海林.试论会计信息系统运行阶段的风险与控制.会计之友,2009(1)

6.邹秀华.高校财务管理信息化建设研究.中国科技信息,2008(3)

数据库需求分析报告范文3

与传统的教学方式相比,项目教学对教师能力提出了更高的要求,其中最核心的要求是教师要科学地选择好课程项目内容,并具有课程项目开发和管理的实践经验。而目前职校的计算机教师基本上接受的都是学历性教育,虽然他们理论功底较扎实,也掌握了一定的教学方法和技巧,但是站在讲台上绝大多数还处于以理论解释理论的“纸上谈兵”状态。试想一个没有亲身经历项目系统开发的人,怎能能够“以就业为导向”、“以项目为主线”来开展好项目教学呢?

以能力为本位,设置项目

为了达到项目教学对教师提出的新要求,提高计算机专业项目教学的能力,作为计算机教研组的负责人,我利用学校学生信息管理要实现信息化的契机,带领计算机教研组的相关教师,深入软件公司进行实地考察和学习。

首先了解公司的实际用人需求、对员工的培养模式、软件开发的实际流程,对比出我们教学的不足与差距,探索出项目教学的目标,人才培养的方案;其次,联系学校的实际需求,与公司合作,将课程开发项目定位为既满足学校的应用需求,又满足教学需求的《学生信息管理系统》。

通过市场调研,教师亲自接触了用人市场,明确了学生的就业需求,教学中就能够以学生能力为本位,实现了人才培养与上岗就业“零距离”接轨的教学培养目标。

以市场为中心,分析项目

结合在软件公司的实地考察学习经验,在设计人员的指导下,按照公司项目开发的实际工作流程,我们首先编制了本课程项目的开发流程:需求分析方案设计系统设计项目实施调试运行。

从流程中可以看出,需求分析是项目开发和管理的基础。在项目开发中,所有的项目风险承担者对需求分析阶段都倍感兴趣。因为这部分工作做的到位,就易于开发出很优秀的软件产品,同时也会令客户满意;若处理不好,则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。

这部分工作有一定的难度,客户多数情况下只能说明整个项目的概念和目标。这些高层次的业务需求不足以提供开发的具体内容和时间,它要求项目开发人员在工作中要采用科学的方法和一定的技巧。

学生没有接触过市场和客户,这就需要教师在教学中将这方面的感受和经验传授给学生,因此教师首先要有接触市场的真实体会,并总结出方法和技巧。

按照这种思路,通过对学生科、教务科、班主任和任课教师等重要用户的反复调研,明确了用户的功能需求,建立了《学生信息管理系统》的系统用例图。

经过客户需求的调研,制作和反复修改需求分析报告,使得教师积累了市场经验。在日后的教学中,他们可以用实践经历向学生讲述软件开发需求调研的全部过程,需求分析在软件开发中的重要地位;同时把停留在书本上的理论化的职业道德转化为具体的道德实践,为学生形成良好的职业道德和规范化职业行为树立典范。这些是书本上永远学不到的知识

以就业为导向,实施项目

职业学校计算机数据库教学培养的人才就业方向为:了解数据库应用项目的开发流程,能够从事项目的初级编码或开发、软件调试及技术服务与软件销售等工作的专业人员。

初到岗位就业的毕业学生,基本上都是在设计人员设计思路指导下,展开项目的开发和编码工作,那么在学校的教学中,教师就要充当设计指导人员的角色。因此,要求教师具有数据库设计、实施的实践经验和科学的指导思想。在项目设计和实施的环节,就是以学生的这种就业需求为导向,来锤炼教师的设计思想,丰富项目实施经验。

在项目设计环节,首先教师通过学习软件设计理论,参考公司的典型案例,按照系统的功能需求分析,设计了《学生信息管理系统》的软件结构层次图;其次教师在认真分析本项目的数据要求的基础上,编制了系统的E-R图,并实现了E-R图向关系模型的转换。

通过数据库的设计,使项目开发的教师对规范、实体、属性、关系、字段等数据库概念有了进一步的理解,并使E-R、E-R到关系模型转换原则等难度大的理论在实践中得到了充分应用。

在项目实施环节,通过数据库建立、界面设计、代码编写和程序测试等几个阶段,

使得教师进一步在深度和广度上拓展了专业理论,掌握了所学专业、所任课程较为系统完整并具有前沿性的专业知识;强化了专业实践能力,锤炼了教师的设计思想,丰富了项目实施经验,提升教师解决特定问题的能力;进而促使教师根据职业教育的特征要求,进行有效的专业知识的整合优化与适度转化,形成满足学生专业实践能力培养所需的知识结构,更好地把握了以学生的就业需求为导向的教学原则。

以学生为主体,应用项目

《学生信息管理系统》开发的最终目的,一方面是成为真正的应用产品,实现了学校学生信息管理的信息化。软件在全校的使用提升了教师在学生中的威望,同时也扩大了该项目在学生中的影响力,激发了学生的学习积极性。

另一方面应用该课程项目,按照六个教学环节:分析任务确定项目分组讨论制订计划知识储备项目准备自主探索项目实施项目展示成果分享结果提交项目评价,“以项目为主线、教师为主导、学生为主体”, 就可以开展具体的数据库项目教学工作了。

通过教学经验的积累,教师探索出了项目教学的基本规律和教学技巧,顺利地实现了教学中师生角色的重新定位;同时原有的教材已无法满足所开发课程项目的教学,它引导教师在对原有教材进行整合的基础上,逐步进行数据库项目教学校本教材的开发。

教师通过科学地选择项目,直接参与课程项目的设置、分析、实施和应用,有效地提高了自身的项目教学能力,促进了数据库课程的教学改革与发展,实现人才培养与上岗就业“零距离”接轨的教学培养目标。

参考文献

数据库需求分析报告范文4

【关键词】计算思维;教学改革;数据库;PBL教学方法

2006年3月,美国卡内基·梅隆大学计算机科学系主任周以真(Jeannette M.Wing)教授在美国计算机权威期刊《Communications of the ACM》杂志上发表的《Computational Thinking》一文中定义了计算思维(Comp-utational Thinking)的概念,即计算思维是运用计算机科学的基础概念进行问题求解、系统设计以及人类行为理解等涵盖计算机科学之广度的一系列思维活动。计算思维是每个人的基本技能,不仅仅属于计算机科学家。

1.引言

医学生学习任务繁重,理工基础相对薄弱,记忆式学习占主导地位。医学院校传统的《数据库基础》教学往往采取“以教师为主导”的教学模式,即“教师讲什么,学生学什么,考试考什么”的灌输式的教学,学生的学习思维始终被教师牵制。教师单纯注重知识链条的系统性和完整性,力图做到把知识点“讲全讲细”,忽略了医学生的自身特点,没有将数据库知识与医学生所学专业有机的结合起来,没有将计算思维的本质即抽象(Abstraction)和自动化(Automation)的思想有效的灌输给学生,造成医学生的学习兴趣普遍不高,教学效果不甚理想。

为了改变这种落后的教学局面,对原有的教学模式重新进行了规划和设计,从培养兴趣出发,结合医学专业特色,采用PBL教学方法和任务驱动等教学方法,将科学的逻辑思辨能力和计算思维融入课堂教学环节,大幅提升了教学效果。

2.教学改革的实施过程

(1)教学分组

为了验证教学改革是否有效,将教授的法医学专业学生分成2组(每组30人),一组采用基于计算思维的教学模式进行教学(以下简称组一教学),另一组采用基于非计算思维的教学模式进行教学(即传统的教学模式,以下简称组二教学)。

(2)项目选题与实施

在组一教学中,打破传统的教学模式,从上课伊始就要求学生结合法医专业特点,自主选题,利用Visual FoxPro 6.0数据库程序开发与法医学应用相关的信息管理系统。由学生自愿组成5-6人的开发小组,由组长带领组员到学校的司法鉴定中心和法医学院各个教研室进行调研,设计需求分析报告,再根据需求分析报告进行模块分工,每个同学至少完成1个模块的编程任务,项目的开发周期贯穿整个学期。

在教学理念上,教师由传统的“主导教学”转变成“引导教学”,采用PBL教学方法(Problem-based learning,即以问题为导向的教学方法),激发学生的兴趣和自主创新意识,在课堂上大量采用讨论甚至争论的形式就开发过程中遇到的问题进行比较和分析,逐步完善解决方案。教师仅在设计的关键点上进行核心语句的讲解,把开发自完全下放给学生,着力培养学生自主学习能力及抽象和自动化的计算思维。比如有同学建议将尸检信息,如身高、体重、体形、肤色、尸斑大小、尸斑位置、死亡地点等信息抽象成二维表便于信息的处理。再如在死亡时间的推断问题上,多数同学都是根据尸体特征推测死亡时间的,有的同学提出还可以根据蝇蛆的生活史推断死亡时间,进而有的同学指出死亡时间的推断还应该考虑环境温度的影响。经过一学期的实践,同学们相继开发出诸如《法医毒物分析管理软件》、《法医尸检信息管理系统》《法医伤检图像分析系统》等具有一定应用价值的信息系统。

在组二教学中,采用传统的教学方式,在学期结束前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).

数据库需求分析报告范文5

关键词:航空;安全;设计

中图分类号:G350 文献识别码:A 文章编号:1001-828X(2016)028-0000-01

一、航空安全是近年来国家和社会普遍关注的一个问题,其中任何一个环节的缺失都可能造成不安全事件的发生,由于航空行业的特殊性,一旦发生航空事故就是很严重的事故,将给社会和家庭带来巨大的影响,因此航空安全需要做到准确、稳定、可靠。针对目前航空安全管理中业务处理的需求,采用了软件工程的设计思想,设计并实现了航空安全管理系统,对飞行管理的每一个阶段进行了流程化的管理,通过航空安全培训模块、风险管理模块、飞行管理模块、维护管理模块完成对整个航空安全的管理,实现了实时、准确的航空管理,同时采用了大数据分析技术提高了安全问题分析的可靠性和准确性。

1.登录功能:系统中采用了ajax技术实现对验证码的处理,通过对验证码进行局部刷新,保证了页面的稳定效果,用户进行手动验证码刷新,或有软件进行验证码刷新都保持了整体页面的无闪动效果。

2.航空安全培训模块:在本功能中主要是通过web页面提供封装的前台信息,系统服务对这些信息进行处理和存储,服务在业务处理完成后将生成相应的数据存储在数据库中,用户通过页面能够查询或浏览到计划信息。通过设计培训更新、查询等服务对数据库中的培训记录进行访问,提高了访问的效率和安全性。在本系统中设计了各种考核页面,用户可以通过在页面中指定培训id,系统将根据培训的内容生成考核的内容,用户通过考试页面完成考核内容的填写,提交给系统进行保存,考核部门给出考核评价意见。

3.风险管理模块:风险采集,该功能完成对指定位置信息的采集和由人工进行风险提供的工作,本功能设计风险设备管理和风险设备参数设定功能,通过该功能使用者能够对风险设备的信息进行查询和管理。风险评估,在本功能中提供了风险评估方法和参数的调整功能,对不同的类型风险进行评估时所采用的评估方法是不同的,因此在页面中提供了风险评估方法的定义和修改。风险决策,在本功能中为了能够使决策具有合理性,系统提供了多个人员对风险决策进行评阅的功能,在页面中提供了多人决策的内容,不同的人员可以对统一风险进行决策,同时在系统生成决策报告时,必须由多个决策人员都填写意见后才能生效。

4.飞行管理模块:该模块完成对飞行前的检查工作,在本模块中设计了多个检查流程,该流程的作用是完成对飞行准备工作的核查,任何一项核查没有通过都不能进行实施。飞行实施模块,该模块完成飞行过程的记录工作,其中包括对飞行航线、飞行参数、飞行通信信息的记录工作,同时为了能够方便用户实施跟踪飞机的飞行轨迹,通过调用GPS数据在页面上进行实时轨迹显示。

5.维护管理模块:日常维护功能,完成维护计划的指定和维护计划的执行,由于日常维护是常规性的工作,所以在本功能中提供了日常维护计划模板,通过模板可以方便快捷的实现维护计划的生成。维护信息管理功能,该功能完成对维护工作的相关信息的统一管理,其中设计了设备信息管理、维护作业信息管理等功能。

二、航空安全是航空企业生产的重点,由于航空安全贯穿了生产过程,因此在目前的航空企业管理中,存在信息系统结构简单、兼容性差的问题,在不同的部门间存在信息难以交流,工作重复开展的问题,给航空企业带来了资源、人力、物力的浪费。

为了解决航空企业安全管理中存在的问题,在信息化建设的基础上,对本企业航空安全管理工作进行系统化的调研、分析和论证,最终结合软件系统的开发经验设计并实现了航空安全管理系统,实现了对航空企业安全管理工作的统一化、信息化和智能化,提高了企业管理的效率和质量,同时为企业信息化提供了一条新的建设思路。

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]LI Feng, LIU Xiao-jie, LIN Han-he. Tolerant system based on Oracle[J]. Computer Engineering and Design,2011(11)

数据库需求分析报告范文6

创新型和创业型人才的培养是当前推进高校教育教学改革的重点。软件工程专业是近年来就业比较热门的专业之一。《软件工程导论》课程是该专业非常重要的一门专业基础课程,也是软件开发系列课程的基础。针对当前该门课程在教学中存在的问题,并结合当前各高校开展的应用型转型的发展目标,文章提出基于项目的实践训练的授课形式的教学模式,以进一步改善软件工程专业人才培养的效果。

关键词:

应用型;基于项目;实践训练;答辩考核

随着我国高等教育改革的进一步深化,由教育部提出针对在校大学生的创新型人才和创业型人才的培养正逐渐成为应用型院校转型的目标。那么如何让在校大学生具备软件项目开发的技能和知识也是软件工程专业的培养目标之一。培养学生软件开发的应用能力已经成为软件工程专业的人才培养的首要目标。[1]《软件工程导论》课程的教学任务也由原来软件开发理论知识的讲授转变为软件开发基本技能和文档撰写能力的训练和培养,通过学习这门课使学生能够了解软件开发的流程,并且知道在开发的过程中每个阶段都做什么和怎么去做,让学生能够直接进入到项目组里,参与软件项目开发。这样改革的好处是多样的:1.这样除了对学生应用能力进行了培养,而且让学生对软件项目的了解进一步加深,后续为以后的其它专业课的学习也打下了基础;2.在同步开设的其他课程中,进行横向联合,让学生都针对同一项目进行训练,让学生能够学有所用,大大提高了学习兴趣和积极性;3.对各门专业课的教学内容和方式都有所触动,促进了教学改革的深入。目前,国内各个高校的软件专业中都开设有《软件工程导论》这门课。多数学校还是当作一门专业基础理论课来讲授,这样的学校大多是研究型大学,学生基础比较扎实,对枯燥的理论可以接受,但是只学理论没有实践造成的后果是学完就忘,学生只会答题;还有一些学校对《软件工程导论》课程进行了一些改革,比如将理论基于一种开发环境的软件开发,试图将理论和实践相结合,但是多数是面向对象开发方式,理论多实践少,落到实际课堂教学上还是教师说的多,学生做的少,对学生实践能力培养并没有多大的改变。对课程的教学改革主要包括教学内容的改革,教学方式方法的改革,考核方法的改革。

一、教学内容的改革

目前《软件工程导论》课程的教学内容包括:软件开发基础知识,需求分析,总体设计、详细设计、编码、测试[2]、项目管理这些内容,采用的是结构化的软件开发方法。之前我们只讲理论知识,特别是开发过程中的一些技术和软件,但是学生学完即使会做题也不会开发项目。现在,我们将教师实际参与开发的项目带领学生从需求开始分析,进行总体设计和详细设计加入到授课内容中,结合实际的项目开发的内容,把理论和实践相结合。学生边学理论知识,边完成自己的项目,可以将学到的知识应用到项目中,做到学有所用。希望培养学生整体软件开发的方法、软件项目管理能力、软件需求分析能力、数据库设计能力、人机交互设计能力、软件测试计划及方案的制定能力、课程报告撰写能力、学习态度等各方面能力。

二、教学方式方法的改革

《软件工程导论》是一门理论课,多数是在多媒体教室由教师讲授为主进行授课。现在,在开课之初,我们要求每个学生申报一个题目,整个学习过程中学到哪个阶段,学生就自己去完成所申报题目的该阶段的任务,这样课堂上老师讲怎么开发软件,在课下布置了大量的阶段性文档要求学生去完成,而且各个阶段所采用的方法也不同,随着各阶段任务的完成,学生也体会到了项目开发的过程、方法。为了保证学生提交的阶段文档的质量和保证学生的项目能够顺利进行,我们将阶段评审添加到了教学过程中。学生需要提交的阶段任务文档有:《软件需求规格说明书》、《软件概要设计说明书》、《软件测试报告》和《课程综合报告》。其中《课程综合报告》中要求按照毕业论文的格式要求去排版和完成,希望同学们通过这样的训练能够在毕业设计中取得较好的效果和成绩。在教学改革时我们还尝试着和同时开设的《数据库原理与应用》、《面向对象程序设计》等课联合起来,分别针对同一题目进行阶段训练,在最终答辩的时候由三门课的老师同时参与答辩,答辩成绩被记入到三门课的最终成绩里,比如《数据库原理与应用》课学习如何设计数据库就应用在了《软件工程导论》课的总体设计阶段,学生需要画出E-R图,给出主要表结构;《面向对象程序设计》课最终就是根据《软件工程导论课》分析和设计的结果用JAVA语言开发出一个小项目,这样学生不仅写出了阶段文档,最终还能做出一个实际的项目,增加了完整性和学习积极性。

三、考核方法的改革

原来我们都是采用试卷考核的方式,但是试卷考核只能考察学生的知识掌握能力,并不能考核学生的实践应用能力,而我们希望通过这门课程让学生具备一定的软件开发实践能力,所以由试卷考核改为答辩考核和平时阶段性评审。[3]这也要求在开课之初就制定出比较详细和全面的考核方案,我们的考核方案从课程报告、答辩平时表现这三大方面出发进行考核。而且,在课程报告提交时,我们有统一的文档格式和内容要求,包括需求分析报告,概要设计报告、测试报告、课程设计报告,在平时授课阶段就需要提交上来;而答辩时,将学生答辩的项目原型与学生之前提交的需求、设计进行对应,审核是否是按照需求和设计进行的开发;而且在近几次的答辩中,我们将答辩所占的比重逐步增加,这样可以看出学生的表达能力、思维能力、项目综合运用能力的高低。《软件工程导论》课程改革的目标就是希望将枯燥、抽象的理论课变成充满趣味和挑战的实训课,让学生通过本课程学习能够知道项目开发各阶段的工作内容,且能够开发一个简单的项目,避免在毕业设计时犯一些软件开发的常识性错误,比如项目开发流程弄错,如何进行分析和设计等等。同时为了提高学生的创新能力,让学生自己申报题目,从需求分析到最终分析设计结束都需要学生自己动手来做,通过学习软件工程思想和方法去完成软件开发过程,可以调动学生的主观能动性,真正做到独立思考,能够激发学生的潜能和创新性,为创新型和应用型人才的培养打下坚实的基础。

作者:苏丹 邹红 崔晓微 仲晓庆 马英瑞 单位:大庆师范学院

参考文献

[1]王菁华.地方高校向应用型转型必须实现三个根本转变[J].职业教育,2016.