硕士研究生论文常见的结构问题

一、概述

    本文主要描述常见的研究生论文结构方面的问题及对应解决办法

 

二、论文中不应有的内容

 

2.1 工程硕士论文常见的不适当内容

 

2.1.1 歌功颂德

    常见的是在论文的摘要、绪论部分，过分拔高论文的来源价值及意义。这些内容，对于学术论文的严肃性是极大的伤害。

 

例如： 本课题在XXX领导的关心、帮助和支持下，取得了丰硕的建设成果

 

2.1.2 政府机构/国营单位的套话

    论文的部分内容，像是政府工作报告。“落实工作”、“发扬xx总之”、“坚定不移推进XXX”这些官话套话出现在正文。

 

例如：XXX的建设将以便民、高效、廉洁、规范为宗旨，推行“一站式办公、一条龙服务、并联式审批、阳光下作业、规范化管理”的运行模式

 

2.1.3 项目实施计划

    论文中出现了项目实施计划。注意，学术论文不是项目建设书，不需要有项目计划

例如：表格 2项目实施计划

阶段	时间要求
需求分析阶段	2012年11月-2011年12月
方案确认阶段	2013年01月-2013年01月
开发实施阶段	2013年02月-2013年04月
系统培训阶段	2013年05月-2013年05月

 

2.2 工学硕士论文常见的不适当内容

TBD

 

三、常见问题及应对

 

3.1 总体

 

1. 需求、概要设计、详细设计所叙述的内容必须一一对应：在需求分析中，例举的功能性需求，需要在概要设计中有对应的模块，在详细设计中应该有对应模块的详细分解。
   避免出现：需求分析中有功能需求1、功能需求2，但是概要设计中只有对功能需求2和需求分析中未提到的功能需求3的模块设计；概要设计中有n个模块，那么详细设计中也应该对应有这n个模块。
   除非：做出特别说明，指明自己论文所做工作在各个阶段（需求、概要、详细、测试等）的具体内容，并且解释这些具体内容在各个阶段不对应的原因。例如：详细设计这一章的章节标题写成“部分重要模块的详细设计”，就能够让读者清楚知道你的论文工作只是选择了一部分模块做详细设计。也可以在这一章的第一部分用文字说明。

3.2 需求部分

 

1. 需求部分，尤其是功能需求，必须要有总体需求概述，不能在开篇直接写每个功能需求。需求概述从整体上对系统的需求进行统一描述。对应于论文的大纲，参见《软件工程方向硕士论文撰写指南》中5.3节的ch3大纲结构。
   
   
2. 有些论文所撰写的所有需求，都使用文字描述，没有图形。必须改为：
   a. 增加用例图描述静态功能需求
   b. 增加时序图或活动图，描述功能的动态流程
   
   
3. 避免使用单一的复杂用例图。有些论文只有一张用例图，图中有很多用例，文字又小有多，难以分辨。必须改为：
   a. 将大用例图按照描述粒度拆分（这是最优的方法）。一张主图展示系统最顶层功能需求；对于每一个（类）大的功能需求，分别单独绘制用例图，将该功能需求细化
   b. 将大用例图按照功能分组拆分（这是次优的方法）。多个功能需求，按照需求间的耦合度，分为几组。每组功能需求绘制一张用例图
4. 如果论文有业务建模部分，需要放置到需求章节的第一部分。业务建模，是指对目标组织所执行的复杂的业务需求进行描述；这个工作，对于执行复杂业务流程的软件系统，例如金融保险行业的业务系统，是需要的；但是，对于其它无需考虑复杂业务流程的系统而言，不需要进行业务建模。业务建模之后，根据业务模型推导出系统的功能性需求和非功能性需求。

3.3 设计部分

1. 总-分结构：在系统设计中，要遵循层次化的原则，粒度上由粗到细进行描述。
2. 避免直接给出设计结果：直接给出设计结果，是指将项目文档中的细节部分一次性展示在论文中，缺少铺垫。而采用“总-分”式的描述，使得论文工作呈现出逐步推进的态势。这样方能体现出“分析”工作。
3. 如果论文将设计分为“概要设计”和“详细设计”两个章节，一般来说，类图应该放置到详细设计中描述
4. 数据库设计原理要放置到第二章“相关技术”中论述。数据库设计原理是属于“原理”性的内容，不属于作者课题工作的主要部分。
5. 设计部分的章节标题中，避免出现“功能”二字，而应该代以“模块”、“子系统”等字样。例如
   “4.2.无纸化业务功能设计”这种叙述是错误的，应该改为“4.2.无纸化业务子系统设计”

3.4 实现部分

1. 软件的开发框架一般放到第二章（相关技术）中进行描述。所谓软件开发框架，是指在论文作者在进行课题工作时，所用到的其他人提供的工具、代码框架等。软件开发框架不属于论文作者的课题工作，因此应放置到“相关技术”中论述

3.5 部署与测试部分

TBD

3.6 图和表

1. 每一副描述系统动态模型的流程图前面，都需要有引述铺垫，不可直接放一张图
2. 流程图绘制必须规范，要么使用结构化分析方法中的流程图符号（word、powerpoint、visio都有标准图形），要么使用UML中的活动图。不可自行发明或者自作主张使用图形
3. 过于复杂的流程图需要拆分。保证流程图贴入word文档中之后，图片不被压缩或者放大，显示比例为100%为准（word页面可以横向放置）。流程图拆分有两种基本方法
   a. 将流程图按照流程拆为前后衔接的多个部分
   b. 将流程图按照参与流程动作的主题拆分为多个部分
4. 绘制流程图也要遵循粒度控制的原则，这一点上与用例图类似。可以首先绘制总体（或者高层）的流程，之后，再将该总体/高层流程中的每个动作再细化为新的更细粒度的流程图
5. 各种图形，包括功能结构图、系统逻辑结构图、流程图等，如果使用了专有的名词或者缩略语，那么必须在该图前面的文字叙述中加以解释