基于过程文档规范化训练的《JAVAEE实践》课程教学研究

石宝金 张正金

（1.蚌埠学院 计算机工程学院，安徽 蚌埠 233030 ;2.巢湖学院 信息工程学院，安徽 巢湖 238000）

近年来，为了增强学校教学与企业实际应用之间的适配性，一些高校的办学理念也渐渐体现出工程化的特点。而办学理念的最直接体现便是培养方案的调整、相关课程的增设和教学模式的改变。《JAVAEE》便是这转变中新加的一门课程：以JAVA程序设计、WEB和数据库基础为前继，强调标准化开发，面向企业级应用。以往的教学环节中大多课时都用在JAVAEE相关技术及常用框架（SSH、SSM）的讲解，以提高学生的编程能力为主要目的，继而在《JAVAEE实践》课程中也会延用之前的教学模式，即以编码实现系统为唯一考核标准。但上述教学模式并没有真正体现出企业级应用开发标准化这一特点，或者说过程文档的规范化训练如此重要的环节已被完全忽视。而这一问题通过调整相应课程的设置顺序，并适当改变教学的习惯性偏重等途径，是可以解决的。在实际的教学过程中，教师通过模拟公司项目管理实情，让学生自主组队、选题、分工，并对过程进行管理，过程文档的规范化与编码并重，强调对需求和业务的理解能力，达到教以适需、学习适用的教学目的的同时，不仅增强了教学效果，而且对学生的实践能力有很大的提升。

一、《JAVAEE实践》课程教学中存在的主要问题

（一）课程设置不尽合理

《JAVAEE实践》是《JAVAEE》的课程实践，一般会在大三开设。为适应企业级应用开发，除上文中提到的基础课程外，还应该增设一门前继课程——《UML》，并作为考试课程，以强调UML基础的重要性，而这一点是当前计算机软件教育所忽略的。

（二）教学的习惯性偏重

当前的软件教学，大多将学生编程能力的提升做为唯一目标，而忽略了过程文档的规范化训练，尤其是需求文档。编程能力的提升并不代表业务能力的提升，不懂需求和业务将直接导致项目开发的低效、反复、失败。而过程文档的规范化作为企业级应用开发的重要标准和前提之一，理应在实践教学中得到体现。

（三）缺乏工程经验

《JAVAEE实践》是一门理论联系实践的课程。需求工程更是贯穿软件开发的始终，尤需长期的经验。高校教师由于缺少工程实践经验，或是一直以来根本忽视了软件开发中过程文档规范化的重要性，而不能很好地将其融入教学，因此学生也很难得到此类训练。

二、基于过程文档规范化训练的《JAVAEE实践》课程教学设计与探索

基于以上考量，为了能够更好的兼容企业实际用人要求，本文提出了以过程文档规范化训练的方式来展开《JAVAEE实践》课程的教学工作。根据需求结合相应案例，按照软件开发的标准化要求，逐步实施需求获取、需求分析、需求规格说明及需求确认的过程，并按照需求列表去推进后继工作。以需求为导向，将知识点提炼融合，加深学生对工程化和规范化的理解，达到教以适需、学以适用的目标。具体实施过程如下：

（一）教学环节设计

教学环节根据过程文档的种类，按时间点划分为若干阶段，各阶段教师讲授与学生实践交替进行，教师对学生提交的阶段性成果进行评审。所有过程文档的规范化材料均由教师提供，并按模板所涉知识点，结合典型案例逐一分析。材料包括需求规格说明书、数据库设计、系统概要设计、系统详细设计、UI设计、系统测试等模板。实施进度如表1所示：

表1 各阶段教学进度

（二）教学环节实施过程

课程教学环节较多，现仅以需求分析（需求规格说明书的确立）过程为例，让学生理解需求调研——需求分析——需求确认的过程，并结合相应实例讲解UML中基本图形的设计要求，以此展开需求文档规范化的训练工作。

1、背景知识理论补强（教学重点）

（1）需求调研

确定原始需求，即通过走访、考察、沟通、分业务组讨论等方式获得，这一过程具有反复性。课堂是实际的模拟，缺少真实客户交流场景，可以通过典型案例的解析让学生拓展思维、异位思考（站在使用者的角度上去分析），再通过讨论总结等方式获取关键需求，这是教学的重点。另外也应强调后期的需求变更、经济及技术可行性论证等都是造成反复性的原因。

（2）需求分析

需求的分析过程是一个迭代的过程：从需求的获取开始，到整理再到验证，最后又返回需求的获取。为了加深学生对这一环节知识的理解，可以根据项目的类型选择不同的分析方法进行讲解，如功能角色划分、用例图、业务流程、行动图、状态图、非功能要求等。

（3）需求确认

需求确认环节是对前期分析结果的肯定，最终形成的需求列表应该是纯粹的用户意愿表达。根据需求列表建立需求规格说明书，再让学生以小组审核的方式对需求进行最终的签字确认，并以此开始软件设计开发工作。

2、需求规格说明书标准

各软件项目，需求规格说明书的标准虽有不同，但在一些关键点上是共通的，现给出需求规格说明书的通用模板，如表2所示：

表2 需求规格说明书

3、关键知识点分析（教学难点）

教学的目的是让学生理解掌握知识，并在实践中应用。以项为引导，以需求规范化理论知识讲解相辅助，并对不同分析方法间的联系和区别作比较，找到相通之处，这是教学的难点。下面将以用例图和行动图为例，对功能需求进行讲解。

（1）用例图

用例图体现了面向对象分析和设计的全过程，以用户为视角，对需求进行抽象、归纳和总结，并建立模型。一个好的用例图必须是易于用户理解的，因此应该用通俗易懂的语言，而非专业术语。另外，虽然生动直观是用例图最大的价值体现，但仅凭用例图又会使分析丢失很多信息，因而需要添加用例说明辅助表达。下面将以学生选课环节为例，讲解需求分析中用例说明的规范。

学生选课用例图，如图1所示：

图1 学生选课用例图

表2 需求规格说明书

这里需要向学生强调“*”部分——非功能要求。非功能要求因与技术相关联，而最容易被忽视，如安全性、并发性等要求。考虑到大量用户会在同一时间进行选课，故这一部分的操作对并发性要求较高，因此在前期需求分析时，应该考虑系统的架构选择。

（2）行动图

用例说明，用纯文字的方式对业务流程和分支进行描述，强调了分散的细节而丢失了对工作流程的整体把握。而UML中的行动图将各个活动节点连接并说明相互间的递转顺序，图文并茂，有效地弥补了用例图的不足。下面将以在买家在线下单为例，讲解需求分析行动图的规范。买家在线下单行动图，如图2所示：

图2 买家在线下单行动图

该行动图的开始点、活动、分支点、同步点（分叉和汇合）、动作流、结束点，分别用实心圆点、圆角矩形、菱形、实心横杠、实线箭头和中心黑点的圆环表示，结合泳道将行动图划分为买家、系统和卖家三部分，描述了买家在线下单后，系统及卖家的一系列处理流程。具体的动作描述、转移描述等规范化表格不再赘述。

（三）学生实践过程设计

当开始《JAVAEE实践》课程时，学生已经具备了基本编程和数据库应用能力。考虑到课程需要，以学生自主分组，自拟题目的形式来开展工作。因期间需要组员进行讨论、确认的场景很多，故要求每小组成员不得少于6人，各成员职责分工明确（需求、数据库、UI、编码、测试、文档书写等），且共同参加需求列表的确认工作，每一小组各指定项目经理和副经理各一名，负责管理小组、管控项目进度和质量。

自拟题目后，在教师指导下，项目经理向组员下发每一阶段任务，并管理项目实施的全过程：项目启动、过程管理、需求分析、系统设计、编码测试、发布交付等环节。所有材料除代码外，均以文档形式提交（电子稿、纸制稿）。其中过程管理和发布交付环节所涉内容如表4所示：

表4 过程管理和发布交付内容表

三、课程考核标准

（一）组内预评

由各项目组经理及副经理根据组员的日常表现及所做贡献讨论给出：过程管理、编码测试、发布交付三环节各占50%、40%、10%，按每组6人计算，预评分数95至70，每5分一档且仅用一次。

（二）教师评分

系统功能演示情况占60%(基本功能实现、业务逻辑正确、UI设计合理各占20%)；过程文档规范化程度占40%（以需求分析为例，项目介绍完整、功能划分明确、用例图、行动图表述正确，各占10%）。

（三）学生最终成绩

组内预评分数和教师评分各占学生最终成绩的50%。如1组6人的预评分数为95、90、85、80、75、70，教师对1组的评分为85，则1组6人的成绩分别为90、87．5、85、82．5、80、77．5。

结语

传统教学仅需提交代码、数据库脚本，并打印课程设计报告。学生成绩分小组划定，即组内成员分数均相同。通过过程文档规范化训练，模拟公司项目管理实情，开展的《JAVAEE实践》课程教学，除上述材料外，每组还需提交过程文档电子稿和打印稿(需求分析、数据库设计、详细设计报告等)，学生成绩由组内预评和教师评分两部分综合，呈等差分布。

在课时不变的前提下，新教学方式的授课内容、范围、学生的工作量都明显增加，这对学生提出了更高的要求，即需要课下花费较多的时间去理解和消化。对于基础不好的班级，18周每周2学时的课时设置明显不足，相应教学环节不得不删减(如UI设计，系统测试等)。但从实际教学效果来看，新教学方式的实施更有利于提升学生学习兴趣以及对企业级应用开发标准化流程的理解，更能体现出软件专业化培养的特点。