江西师范大学软件工程导论 2012年考研专业课初试真题
864-软件工程导论
江西师范大学硕士研究生入学考试初试科目考试大纲科目代码、名称: 864 软件工程导论适用专业: 083500 软件工程一、考试形式与试卷结构（一）试卷满分及考试时间本试卷满分为150分，考试时间为180分钟。
（二）答题方式答题方式为闭卷、笔试。
试卷由试题和答题纸组成；答案必须写在答题纸相应的位置上。
（三）试卷内容结构单项选择题：10小题，每小题3分，共30分简答题： 5小题，每小题8分，共40分分析设计题：5小题，共80分二、考查目标（复习要求）软件工程专业学术型研究生入学考试科目为《软件工程导论》，该科目要求考生系统掌握本课程的基本知识、基础理论和基本方法，并能运用相关理论和方法分析、解决软件工程中的实际问题。
三、考查范围或考试内容概要第1章软件工程学概述1．软件危机2．软件工程3．软件生命周期4．软件过程第2章可行性研究1．可行性研究的任务2．可行性研究过程3．系统流程图4．数据流图5．数据字典6．成本/效益分析第3章需求分析1．需求分析的任务2．与用户沟通获取需求的方法3．分析建模与规格说明4．状态转换图5．验证软件需求第4章总体设计1．设计过程2．设计原理3．启发规则4．描绘软件结构的图形工具5．面向数据流的设计方法第5章详细设计1．结构程序设计2．人机界面设计3．过程设计的工具4．面向数据结构的设计方法5．程序复杂程度的定量计算第6章实现1．编码2．软件测试基础3．软件测试过程单元测试，集成测试，确认测试3．软件测试技术白盒测试技术，黑盒测试技术4．调试第7章维护1．软件维护的定义2．软件维护的特点3．软件维护的过程4．软件的可维护性第8章面向对象方法学1．面向对象建模对象模型，动态模型，功能模型2．面向对象分析面向对象分析的基本过程，建立对象模型，建立动态模型，建立功能模型3．面向对象设计面向对象设计的准则，启发规则，软件重用，设计与优化4．面向对象实现程序设计语言，程序设计风格，测试策略第9章软件项目管理1．估算软件规模2．工作量估算3．进度计划4．人员组织5．质量保证6．软件配置管理7．能力成熟度模型参考教材或主要参考书：张海藩．软件工程导论（第五版）．北京：清华大学出版社，2008四、样卷一.单项选择题(本大题共10小题，每小题3分，共30分)在每小题列出的四个选项中只有一个选项是符合题目要求的，请将正确选项前的字母填在题后的括号内。
2012年全国硕士研究生入学统一考试408计算机学科专业基础综合真题及详解
2012年全国硕士研究生入学统一考试408计算机学科专业基础综合真题及详解一、单项选择题：l～40小题。
每小题2分，共80分。
下列每题给出的四个选项中，只有一个选项是最符合题目要求的。
1．求整数n（n≥0）阶乘的算法如下，其时间复杂度是（）。
A．O（log2n）B．0（n）C．O（nlog2n）D．O（n2）【答案】B。
【解析】设fact（n）的运行时间函数是T（n）。
该函数中语句①的运行时间是0（1），语句②的运行时间是T（n-1）+O（1），其中O （1）为乘法运算的时间。
因此，当n≤1时，T（n）-0（1）；当n>1时，T（n）＝T（n-1）+O（1）。
则，T（n）＝O（1）+T（n-1）＝2×O（1）+T（n-2）＝（n-1）×O（1）+T（1）＝n×O（1）＝O（n）即fact（n）的时间复杂度为O（n）。
2．已知操作符包括‘+’、‘-’、‘*’、‘／’、‘（’和‘）’。
将中缀表达式a+b-a*（（c+d）／e-f）+g转换为等价的后缀表达式ab+acd+e／f-*-g+时，用栈来存放暂时还不能确定运算次序的操作符。
若栈初始时为空，则转换过程中同时保存在栈中的操作符的最大个数是（）。
A．5B．7C．8D．11【答案】A。
【解析】基本思想是：采用运算符栈是为了比较运算符的优先级，所有运算符必须进栈。
只将大于栈顶元素优先级的运算符直接进栈，否则需要退栈栈顶运算符（先出栈的运算符先计算，同优先级的运算符在栈中的先计算）。
表达式a+b-a*（（c+d）／e-f）+g产生后缀表达式的过程如下表所列：“*”的优先级大于栈顶元素“-”，则“*”*ab+acd+e／通过上表可以看出，显然转换过程中同时保存在栈中的操作符的最大个数是5。
3．若一棵二叉树的前序遍历序列为a，e，b，d，c，后序遍历序列为b，c，d，e，a，则根结点的孩子结点（）。
A．只有eB．有e、bC．有e、cD．无法确定【答案】A。
864软件工程导论考试大纲
江西师范大学硕士研究生入学考试初试科目考试大纲科目代码、名称: 864 软件工程导论适用专业: 083500 软件工程一、考试形式与试卷结构（一）试卷满分及考试时间本试卷满分为150分，考试时间为180分钟。
（二）答题方式答题方式为闭卷、笔试。
试卷由试题和答题纸组成；答案必须写在答题纸相应的位置上。
（三）试卷内容结构单项选择题：10小题，每小题3分，共30分简答题： 5小题，每小题8分，共40分分析设计题：5小题，共80分二、考查目标（复习要求）软件工程专业学术型研究生入学考试科目为《软件工程导论》，该科目要求考生系统掌握本课程的基本知识、基础理论和基本方法，并能运用相关理论和方法分析、解决软件工程中的实际问题。
三、考查范围或考试内容概要第1章软件工程学概述1．软件危机2．软件工程3．软件生命周期4．软件过程第2章可行性研究1．可行性研究的任务2．可行性研究过程3．系统流程图4．数据流图5．数据字典6．成本/效益分析第3章需求分析1．需求分析的任务2．与用户沟通获取需求的方法3．分析建模与规格说明4．状态转换图5．验证软件需求第4章总体设计1．设计过程2．设计原理3．启发规则4．描绘软件结构的图形工具5．面向数据流的设计方法第5章详细设计1．结构程序设计2．人机界面设计3．过程设计的工具4．面向数据结构的设计方法5．程序复杂程度的定量计算第6章实现1．编码2．软件测试基础3．软件测试过程单元测试，集成测试，确认测试3．软件测试技术白盒测试技术，黑盒测试技术4．调试第7章维护1．软件维护的定义2．软件维护的特点3．软件维护的过程4．软件的可维护性第8章面向对象方法学1．面向对象建模对象模型，动态模型，功能模型2．面向对象分析面向对象分析的基本过程，建立对象模型，建立动态模型，建立功能模型3．面向对象设计面向对象设计的准则，启发规则，软件重用，设计与优化4．面向对象实现程序设计语言，程序设计风格，测试策略第9章软件项目管理1．估算软件规模2．工作量估算3．进度计划4．人员组织5．质量保证6．软件配置管理7．能力成熟度模型参考教材或主要参考书：张海藩．软件工程导论（第五版）．北京：清华大学出版社，2008四、样卷一.单项选择题(本大题共10小题，每小题3分，共30分)在每小题列出的四个选项中只有一个选项是符合题目要求的，请将正确选项前的字母填在题后的括号内。
江西师范大学计算机信息工程学院863数据结构与程序设计历年考研真题专业课考试试题
2013年江西师范大学863数据结构与程序设计考研真题 2014年江西师范大学863数据结构与程序设计考研真题 2015年江西师范大学863数据结构与程序设计考研真题 2016年江西师范大学863数据结构与程序设计考研真题 2017年江西师范大学863数据结构与程序设计考研真题 2018年江西师范大学863数据结构与程序设计考研真题
2013年江西师范大学863数据结构 与程序设计考研真题
2014年江西师范大学863数据结构 与程序设计考研真题
2015年江西师范大学863数据结构 与程序设计考研真题
2016年江西师范大学863数据结构 程序设计考研真题2017年江西师范大学863数据结构 与程序设计考研真题
2018年江西师范大学863数据结构 与程序设计考研真题
江西师范大学计算机信息工程学院硕士研究生招生专业简介
面向对象分析与并行计算 人工智能与智能教育软件
计算机数学及其应用
数据库理论与网络工程
微机系统开发与计算机网络结构 嵌入式系统
软件体系结构及实用的软件开发方法
毕业与学位授予：毕业证+学位证（工学硕士）
2、“软件工程” 一级学科硕士点
培养目标：包含软件工程理论、软件工程技术、软件工程管理、 软件服务工程等二级学科，培养具备本学科理论基础和较高深 的专业技能、能独立进行学术研究的高级技术人才，可从事软 件工程基础研究、应用基础研究和关键技术创新等工作。
2006年获批“计算机科学与技术”一级学科硕士点，并于 次年开始招生，目前是江西省“十二五”重点学科。
2011年获得“软件工程”一级学科硕士点，该学科是国家 2011年新设立的一级学科之一；2013年，经教育部同意，我校 在“软件工程”一级学科下自主增设二级学科“物联网技术”。
2004年获得“现代教育技术”专业教育硕士授予权。
➢ 国家奖学金：20000元（每人都有两次评选机会，2013年评选名额为100余 名，2014年下半年评）
➢ 省政府奖学金：10000元 ➢ 学业奖学金：4000—8000元（覆盖面100%，以最终文件为准）
“三助”岗位： 每年设立两百余个“助教”、“助研”、“助管”岗位，既锻炼能力， 又解决经济问题。 此外，还有“三好研究生”、“优秀研究生干部”、“研究生优秀 单项奖”等奖项。
师资队伍
学院现有专业教师 82 人，其中教授16名，副教授24名， 博士20余人，硕士研究生导师30余名。
近五年来，获国家级课题20项，省部级课题60余项，厅 局级课题100余项；发表论文500多篇，其中核心期刊近 400 篇；获得省部级奖励10余项。
学术型研究生
江西师范大学历年考研专业课真题_C语言程序设计与数据结构2012--2014
1、 在 C 语言中，正确的标识符是由字母、________、下划线组成的，其中第一个字符应为字母或下划线。=y 后的 x 值是_________。 3、 若有 10<x<100，则其正确的 C 语言表达式是_________。 4、 设有语句 int a[3][4]; 则共定义了_______个数组元素。 5、设有以下宏定义： #define M 3 则执行语句 z=2*M+5;后，z 的值是_________。 三、 判断题，对打“√” ，错打“X” （5 小题，每小题 2 分，共 10 分）
4
1、 对于图 1 所示的二叉树：
图1
写出这棵二叉树的前序、中序和后序遍历序列。 2、设哈希表长度为 11，哈希函数 H(x) = x%11，给定的关键字序列为 1，13，12，34，38，33，27，29。试画出线性 探测法解决冲突时所构造的哈希表。 3、已知无向图 G=(V, E)，其中 V 表示顶点集合，E 表示边集合，且 V={a, b, c, d, e}, E={<a, b>, <a, c>, <c, d>, <c, e>, <d, e>, <b, d>}，请画出无向图 G，并写出该无向图 G 的邻接矩阵。 五、 程序设计题（5 小题，每小题 10 分，共 50 分）
1
2
3
江西师范大学 2013 年全日制硕士研究生入学考试试题 （A 卷）
专业： 120100 管理科学与工程 01、04 方向 科目：C 语言程序设计与数据结构 注：考生答题时，请写在考点下发的答题纸上，写在本试题纸或其他答题纸上的一律无效。
（本试题共 3 页）
一、 简答题（共 8 小题，其中第 5 小题 8 分，其余每小题 6 分，共 50 分） 1、 简述 C 语言中有哪些算术运算符。 2、 简述 C 语言中，输出操作有哪些常用函数？ 3、 简述以下 switch 语句的执行过程。 switch （表达式） { case 常量 1: 语句 1； case 常量 2: 语句 2； case 常量 3: 语句 3； ....... case 常量 n: 语句 n； default : 语句 n+1； } 4、 简述 C 语言中 while 循环和 do-while 循环的异同。 5、 什么叫串（字符串）？空串和空格串是否相同，为什么? 6、 抽象数据类型堆栈的常用操作有哪些（至少写出三个）？ 7、 在顺序队列中，什么叫假溢出？ 8、 简述二叉树和一般树的主要区别。 二、 填空题（5 个空，每空 2 分，共 10 分）
2012计算机考研真题及答案
2012 年全国硕士研究生入学统一考试—计算机专业基础综合试题2012 年全国硕士研究生入学统一考试计算机科学与技术学科联考计算机学科专业基础综合试题（科目代码 408）1一、单项选择题：第1～40小题，每小题2分，共80分。
下列每题给出的四个选项中，只有一个选项最符合试题要求。
1．求整数n(n≥0)阶乘的算法如下，其时间复杂度是int fact(int n){if (n<=1)return 1;return n*fact(n-1);}A. O(log2n)B. O(n)C. (nlog2n)D. O(n2)2．已知操作符包括…+‟、…-‟、…*‟、…/‟、…(‟和…)‟。
将中缀表达式a+b-a*((c d)/e-f)+g转换为等价的后缀表达式ab+acd+e/f-*-g+ 时，用栈来存放暂时还不能确定运算次序的操作符，若栈初始时为空，则转换过程中同时保存在栈中的操作符的最大个数是A. 5B. 7C. 8D. 113.若一棵二叉树的前序遍历序列为a, e, b, d, c，后序遍历序列为b, c, d, e, a，则根结点的孩子结点A.只有eB.有e、bC.有e、cD.无法确定4．若平衡二叉树的高度为6，且所有非叶结点的平衡因子均为1，则该平衡二叉树的结点总数为A. 10B. 20C. 32D. 335．对有n个结点、e条边且使用邻接表存储的有向图进行广度优先遍历，其算法时间复杂度是A. O(n)B. O(e)C. O(n+e)D. O(n*e)6．若用邻接矩阵存储有向图，矩阵中主对角线以下的元素均为零，则关于该图拓扑序列的结论是A.存在，且唯一C.存在，可能不唯一B.存在，且不唯一D.无法确定是否存在7．对如下有向带权图，若采用迪杰斯特拉（Dijkstra）算法求源点a到其他各顶点的最短路径，则得到的第一条最短路径的目标顶点是b，第二条最短路径的目标顶点是c，后续得到的其余各最短路径的目标顶点依次是A.d,e,fB.e,d,fC. f,d,eD.f,e,d8．下列关于最小生成树的说法中，正确的是 I. 最小生成树树的代价唯一II. 权值最小的边一定会出现在所有的最小生成树中III. 用普里姆（Prim ）算法从不同顶点开始得到的最小生成树一定相同 IV. 普里姆算法和克鲁斯卡尔（Kruskal ）算法得到的最小生成树总不相同A. 仅 IB. 仅 IIC. 仅 I 、IIID. 仅 II 、IV9．设有一棵 3 阶 B 树，如下图所示。
江西师范大学2006~2012年硕士研究生入学考试试题[推荐5篇]
![江西师范大学2006~2012年硕士研究生入学考试试题[推荐5篇]](https://img.taocdn.com/s3/m/96ac8d0d3069a45177232f60ddccda38366be14b.png)
江西师范大学2006~2012年硕士研究生入学考试试题[推荐5篇]第一篇：江西师范大学2006~2012年硕士研究生入学考试试题2012江西师大现当代考研真题一、名词解释1、《大雁和我的保姆》2、左联3、《北京人》4、“主观战斗精神”5、《春之声》6、印家厚二、简答1、周作人《人的文学》对新时期文学的意义2、简析觉新的性格特征及意义3、简述张承志小说的诗话内涵4、沙叶新《陈毅市长》的艺术特征三、论述1、试论鲁迅《野草》的思想内容及艺术特征，并从创作动机的角度谈谈与《呐喊》和《彷徨》的主要区别。
2、分析《青春之歌》中“林道静的成长模式”，并谈谈“林道静成长模式”的时代意义以及历史局限。
2012文学理论一、名词解释1、文学活动2、语境3、抒情话语4、文学传播二、简答1、文学创作中意识与无意识的关系2、文学的审美意识形态的特殊性三、辨析1、叙述者等同于作者，对否？2、文学作品的艺术生命力与其商业价值有无必然关系四、论述1、请运用下列批评模式——伦理道德批评，社会历史批评，审美批评，心理学批评，语言学批评，文化批评中的任意一种，简评中外文学史上你所熟悉的一位作家或作品。
、2、谈谈你对人文关怀的理解并结合这一有关的理论内容，对中国现当代文学或世界文学中的有关创作现象做些简要分析与评价。
2011 现当代一、名词解释 1,《潘先生在难中》2,《上海屋檐下》3,七月诗派4,《青春之歌》5,贺敬之6,《我与地坛》二、简答题1、简述毛泽东《在延安文艺座谈会上的讲话》的主要思想内容2、简述曹禺剧作的主要艺术成就3、简述孙犁小说的风格特征4、简述朦胧诗派的审美特征三、论述题1、为什么中国现代小说从鲁迅开始，又在他手中成熟2、《芙蓉镇》如何体现“伤痕”和“反思”文学的特色2011文学理论一、名词解释文学活动的“四个要素” 艺术发现文学典型文学风格二、简答题1、什么是艺术概括？艺术概括有哪些具体的规定？2、文学意境有哪些基本特征？三、辨析题1、作家的情感越是强烈，他所创作出来的文学作品越伟大。
江西师范大学硕士研究生入学考试试题样卷
江西师范大学硕士研究生入学考试试题（样卷）专业: 081200 计算机科学与技术科目：数据结构与程序设计注：考生答题时，请写在考点下发的答题纸上，写在本试题纸或其它答题纸上的一律无效！（本试题共计页）一、选择题（每小题2分，共20分）1、若语句S的执行时间为O（1），那么下列程序段的时间复杂度为：（）for（i=0; i<n; i++）for（j=0; j<=i; j++)S;（A）O（n）（B）O（n2）（C）O（nlog n）（D）O（n*i）2、在一个单链表中，若p所指结点不是最后结点，在p之后插入s所指结点，则执行的语句序列是（）。
（A）s->next=p; p->next=s; （B）p->next=s; s->next=p;（C）s->next=p->next; p=s; （D）s->next=p->next; p->next=s;3、设高度为h的二叉树上只有度为0和度为2的结点，则此类二叉树中所包含的结点数至少为（）（注：只含有一个根结点的树高为1）（A）2h （B）2h-1 （C）2h+1 （D）h+14、一组记录的关键码为（46，79，56，38，40，84），则利用堆排序的方法建立的初始堆为（）。
（A）84，79，56，38，40，46 （B）79，46，56，38，40，80（C）84，79，56，46，40，38 （D）84，56，79，40，46，385、设二叉排序树中关键字由1至1000的整数构成，现要检索关键字为363的结点，下述关键字序列哪一个不可能是二叉排序树上搜索到的序列（）。
（A）2，252，401，398，330，344，397，363（B）924，220，911，244，898，258，362，363（C）952，202，911，240，912，245，363（D）2，399，387，219，266，382，381，278，3636、已知某完全二叉树采用顺序存储结构，结点数据信息A、B、C、D、E、F、G、H，顺序存放在数组的前8个单元，则该完全二叉树的后序遍历序列为（）。
2012年软件工程课程设计题目
Course Registration Requirements2008 Software Engineering Practice Project2012.8.12 - 2012.8.25College of Computer Science & Technology2012 Software EngineeringProblem StatementAs the head of information systems for Wylie College you are tasked with developing a new student registration system. The college would like a new client-server system to replace its much older system developed around mainframe technology. The new system will allow students to register for courses and view report cards from personal computers attached to the campus LAN. Professors will be able to access the system to sign up to teach courses as well as record grades.Due to a decrease in federal funding, the college cannot afford to replace the entire system at once. The college will keep the existing course catalog database where all course information is maintained. This database is an Ingres relational database running on a DEC VAX. Fortunately the college has invested in an open SQL interface that allows access to this database from college’s Unix servers. The legacy system performance is rather poor, so the new system must ensure that access to the data on the legacy system occurs in a timely manner. The new system will access course information from the legacy database but will not update it. The registrar’s office will continue to maintain course information through another system.At the beginning of each semester, students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites, will be included to help students make informed decisions.The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case the student cannot be assigned to a primary selection. Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be canceled. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. If a course fills up during the actual registration process, the student must be notified of the change before submitting the schedule for processing.At the end of the semester, the student will be able to access the system to view an electronic report card. Since student grades are sensitive information, the system must employ extra security measures to prevent unauthorized access.Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings. In addition, the professors will be able to record the grades for the students in each class.GlossaryIntroductionThis document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions andother project documents can focus on what the system must do with the information.DefinitionsThe glossary contains the working definitions for the key concepts in the Course Registration System.CourseA class offered by the university.Course OfferingA specific delivery of the course for a specific semester – you could run the same course in parallelsessions in the semester. Includes the days of the week and times it is offered.Course CatalogThe unabridged catalog of all courses offered by the university.FacultyAll the professors teaching at the university.Finance SystemThe system used for processing billing information.GradeThe evaluation of a particular student for a particular course offering.ProfessorA person teaching classes at the university.Report CardAll the grades for all courses taken by a student in a given semester.RosterAll the students enrolled in a particular course offering.StudentA person enrolled in classes at the university.ScheduleThe courses a student has selected for the current semester.TranscriptThe history of the grades for all courses, for a particular student sent to the finance system, which in turn bills the students.Supplementary SpecificationObjectivesThe purpose of this document is to define requirements of the Course Registration System. ThisSupplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.ScopeThis Supplementary Specification applies to the Course Registration System, which will be developed by the OOAD students.This specification defines the non-functional requirements of the system; such as reliability, usability,performance, and supportability, as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications.)ReferencesNone.FunctionalityMultiple users must be able to perform their work concurrently.If a course offering becomes full while a student is building a schedule including that offering, the student must be notified.UsabilityThe desktop user-interface shall be Windows 95/98 compliant.ReliabilityThe system shall be available 24 hours a day 7 days a week, with no more than 10% down time.PerformanceThe system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.The system shall provide access to the legacy course catalog database with no more than a 10 secondlatency.Note: Risk-based prototypes have found that the legacy course catalog database cannot meet ourperformance needs without some creative use of mid-tier processing powerThe system must be able to complete 80% of all transactions within 2 minutes.SupportabilityNone.SecurityThe system must prevent students from changing any schedules other than their own, and professors from modifying assigned course offerings for other professors.Only Professors can enter grades for students.Only the Registrar is allowed to change any student information.Design ConstraintsThe system shall integrate with an existing legacy system, the Course Catalog System, which is an RDBMS database.The system shall provide a Windows-based desktop interface.Use-Case ModelCourse Registration System Use-Case Model Main DiagramClose RegistrationBilling SystemClose RegistrationBrief DescriptionThis use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.Flow of EventsBasic FlowThis use case starts when the Registrar requests that the system close registration.1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar, andthe use case terminates. The Close Registration processing cannot be performed if registration is in progress. 2. For each course offering, the system checks if a professor has signed up to teach the course offering and at leastthree students have registered. If so, the system commits the course offering for each schedule that contains it.3. For each schedule, the system “levels” the schedule: if the schedule does not have the maximum number ofprimary courses selected, the system attempts to select alternates from the schedule’s list of alternates. The first available alternate course offerings will be selected. If no alternates are available, then no substitution will be made.4. For each course offering, the system closes all course offerings. If the course offerings do not have at leastthree students at this point (some may have been added as a result of leveling), then the system cancels the course offering. The system cancels the course offering for each schedule that contains it.5. The system calculates the tuition owed by each student for his current semester schedule and sends a transactionto the Billing System. The Billing System will send the bill to the students, which will include a copy of their final schedule.Alternative FlowsNo Professor for the Course OfferingIf, in the Basic Flow, there is no professor signed up to teach the course offering, the system will cancel the course offering. The system cancels the course offering for each schedule that contains it.Billing System UnavailableIf the system is unable to communicate with the Billing System, the system will attempt to re-send therequest after a specified period. The system will continue to attempt to re-send until the Billing Systembecomes available.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system in order for this use case to begin.Post-ConditionsIf the use case was successful, registration is now closed. If not, the system state remains unchanged.Extension PointsNone.LoginBrief DescriptionThis use case describes how a user logs into the Course Registration System.Flow of EventsBasic FlowThis use case starts when the actor wishes to log into the Course Registration System.1. The actor enters his/her name and password.2. The system validates the entered name and password and logs the actor into the system.Alternative FlowsInvalid Name/PasswordIf, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an errormessage. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.Special RequirementsNone.Pre-ConditionsThe system is in the login state and has the login screen displayed.Post-ConditionsIf the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.Extension PointsNone.Maintain Professor InformationBrief DescriptionThis use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system.Flow of EventsBasic FlowThis use case starts when the Registrar wishes to add, change, and/or delete professor information in the system. 1. The system requests that the Registrar specify the function he/she would like to perform (either Add aProfessor, Update a Professor, or Delete a Professor)2. Once the Registrar provides the requested information, one of the sub flows is executed.If the Registrar selected “Add a Professor”, the Add a Professor subflow is executed.If the Registrar selected “Update a Professor”, the Update a Professor subflow is executed.If the Registrar selected “Delete a Professor”, the Delete a Professor subflow is executed.Add a ProfessorThe system requests that the Registrar enter the professor information. This includes:- name- date of birth- social security number- status- department1. Once the Registrar provides the requested information, the system generates and assigns a unique idnumber to the professor. The professor is added to the system.2. The system provides the Registrar with the new professor id.Update a Professor1. The system requests that the Registrar enter the professor id.2. The Registrar enters the professor id. The system retrieves and displays the professor information.3. The Registrar makes the desired changes to the professor information. This includes any of theinformation specified in the Add a Professor sub-flow.4. Once the Registrar updates the necessary information, the system updates the professor record.Delete a Professor1. The system requests that the Registrar enter the professor id2. The Registrar enters the professor id. The system retrieves and displays the professor information.3. The system prompts the Registrar to confirm the deletion of the professor.4. The Registrar verifies the deletion.5. The system deletes the professor from the system.Alternative FlowsProfessor Not FoundIf, in the Update a Professor or Delete a Professor sub-flows, a professor with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.Delete CancelledIf, in the Delete A Professor sub-flow, the Registrar decides not to delete the professor, the delete iscancelled, and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.Extension PointsNone.Maintain Student InformationBrief DescriptionThis use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting Students from the system.Flow of EventsBasic FlowThis use case starts when the Registrar wishes to add, change, and/or delete student information in the system.1. The system requests that the Registrar specify the function he/she would like to perform (either Add a Student,Update a Student, or Delete a Student)2. Once the Registrar provides the requested information, one of the sub flows is executed.If the Registrar selected “Add a Student”, the Add a Student subflow is executed.If the Registrar selected “Update a Student”, the Update a Student subflow is executed.If the Registrar selected “Delete a Student”, the Delete a Student subflow is executed.Add a Student1. The system requests that the Registrar enter the student information. This includes:- name- date of birth- social security number- status- graduation date2. Once the Registrar provides the requested information, the system generates and assigns a unique idnumber to the student. The student is added to the system.3. The system provides the Registrar with the new student id.Update a Student1. The system requests that the Registrar enter the student id.2. The Registrar enters the student id. The system retrieves and displays the student information.3. The Registrar makes the desired changes to the student information. This includes any of theinformation specified in the Add a Student sub-flow.4. Once the Registrar updates the necessary information, the system updates the student information.Delete a Student1. The system requests that the Registrar enter the student id2. The Registrar enters the student id. The system retrieves and displays the student information.3. The system prompts the Registrar to confirm the deletion of the student.4. The Registrar verifies the deletion.5. The system deletes the student from the system.Alternative FlowsStudent Not FoundIf, in the Update a Student or Delete a Student sub-flows, a student with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.Delete CancelledIf, in the Delete A Student sub-flow, the Registrar decides not to delete the student, the delete is cancelled and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the student information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.Extension PointsNone.Register for CoursesBrief DescriptionThis use case allows a Student to register for course offerings in the current semester. The Student can also update or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.Flow of EventsBasic FlowThis use case starts when a Student wishes to register for course offerings, or to change his/her existing course schedule.1. The Student provides the function to perform (one of the sub flows is executed):If the Student selected “Create a Schedule”, the Create a Schedule subflow is executed.If the Student selected “Update a Schedule”, the Update a Schedule subflow is executed.If the Student selected “Delete a Schedule”, the Delete a Schedule subflow is executed.Create a Schedule1. The system retrieves a list of available course offerings from the Course Catalog System and displaysthe list to the Student.2. The Select Offerings subflow is executed.3. The Submit Schedule subflow is executed.Update a Schedule1. The system retrieves and displays the Student’s current schedule (e.g., the schedule for the currentsemester).2. The system retrieves a list of available course offerings from the Course Catalog System and displaysthe list to the Student.3. The Student may update the course selections on the current selection by deleting and adding newcourse offerings. The Student selects the course offerings to add from the list of available courseofferings. The Student also selects any course offerings to delete from the existing schedule.4. Once the student has made his/her selections, the system updates the schedule for the Student using theselected course offerings.5. The Submit Schedule subflow is executed.Delete a Schedule1. The system retrieves and displays the Student’s current schedule (e.g., the schedule for the currentsemester).2. The system prompts the Student to confirm the deletion of the schedule.3. The Student verifies the deletion.4. The system deletes the Schedule. If the schedule contains “enrolled in” course offerings, the Studentmust be removed from the course offering.Select OfferingsThe Student selects 4 primary course offerings and 2 alternate course offerings from the list of availableofferings.Once the student has made his/her selections, the system creates a schedule for the Student containing the selected course offerings.Submit ScheduleFor each selected course offering on the schedule not already marked as “enrolled in”, the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are noschedule conflicts.The system then adds the Student to the selected course offering. The course offering is marked as“enrolled in” in the schedule.The schedule is saved in the system.Alternative FlowsSave a ScheduleAt any point, the Student may choose to save a schedule rather than submitting it. If this occurs, theSubmit Schedule step is replaced with the following:The course offerings not marked as “enrolled in” are marked as “selected” in the schedule.The schedule is saved in the system.Unfulfilled Prerequisites, Course Full, or Schedule ConflictsIf, in the Submit Schedule sub-flow, the system determines that the Student has not satisfied the necessary prerequisites, or that the selected course offering is full, or that there are schedule conflicts, an errormessage is displayed. The Student can either select a different course offering and the use case continues, save the schedule, as is (see Save a Schedule subflow), or cancel the operation, at which point the BasicFlow is re-started at the beginning.No Schedule FoundIf, in the Update a Schedule or Delete a Schedule sub-flows, the system is unable to retrieve the Student’s schedule, an error message is displayed. The Student acknowledges the error, and the Basic Flow is re-started at the beginning.Course Catalog System UnavailableIf the system is unable to communicate with the Course Catalog System, the system will display an errormessage to the Student. The Student acknowledges the error message, and the use case terminates.Course Registration ClosedWhen the use case starts, if it is determined that registration for the current semester has been closed, amessage is displayed to the Student, and the use case terminates. Students cannot register for courseofferings after registration for the current semester has been closed.Delete CancelledIf, in the Delete A Schedule sub-flow, the Student decides not to delete the schedule, the delete iscancelled, and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Student must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the student schedule is created, updated, or deleted. Otherwise, the system state is unchanged.Extension PointsNone.Select Courses to TeachBrief DescriptionThis use case allows a Professor to select the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.Flow of EventsBasic FlowThis use case starts when a Professor wishes to sign up to teach some course offerings for the upcoming semester.1. The system retrieves and displays the list of course offerings the professor is eligible to teach for the currentsemester. The system also retrieves and displays the list of courses the professor has previously selected to teach.2. The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcomingsemester.3. The system removes the professor from teaching the de-selected course offerings.4. The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with eachother or any course offerings that the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects (i.e., records the professor as the instructor for the course offering).Alternative FlowsNo Course Offerings AvailableIf, in the Basic Flow, the professor is not eligible to teach any course offerings in the upcoming semester, the system will display an error message. The professor acknowledges the message and the use case ends.Schedule ConflictIf the systems find a schedule conflict when trying to establish the course offerings the Professor shouldtake, the system will display an error message indicating that a schedule conflict has occurred. The system will also indicate which are the conflicting courses. The Professor can either resolve the schedule conflict(i.e., by canceling his selection to teach one of the course offerings), or cancel the operation, in which case,any selections will be lost, and the use case ends.Course Catalog System UnavailableIf the system is unable to communicate with the Course Catalog System, the system will display an errormessage to the Student. The Student acknowledges the error message, and the use case terminates.Course Registration ClosedWhen the use case starts, if it is determined that registration for the current semester has been closed, amessage is displayed to the Professor, and the use case terminates. Professors cannot change the courseofferings they teach after registration for the current semester has been closed. If a professor change isneeded after registration has been closed, it is handled outside the scope of this system.Special RequirementsNone.Pre-ConditionsThe Professor must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the course offerings a Professor is scheduled to teach have been updated. Otherwise, the system state is unchanged.Extension PointsNone.Submit GradesBrief DescriptionThis use case allows a Professor to submit student grades for one or more classes completed in the previous semester.Flow of EventsBasic FlowThis use case starts when a Professor wishes to submit student grades for one or more classes completed in the previous semester.1. The system displays a list of course offerings the Professor taught in the previous semester.2. The Professor selects a course offering.3. The system retrieves a list of all students who were registered for the course offering. The system displays eachstudent and any grade that was previously assigned for the offering.4. For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the student’sgrade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change the grade for a student by entering a new grade.Alternative FlowsNo Course Offerings TaughtIf, in the Basic Flow, the Professor did not teach any course offerings in the previous semester, the system will display an error message. The Professor acknowledges the message, and the use case ends.Special RequirementsNone.Pre-ConditionsThe Professor must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, student grades for a course offering are updated. Otherwise, the system state is unchanged.Extension PointsNone.View Report CardBrief DescriptionThis use case allows a Student to view his/her report card for the previously completed semester.Flow of EventsBasic FlowThis use case starts when a Student wishes to view his/her report card for the previously completed semester.1. The system retrieves and displays the grade information for each of the course offerings the Student completedduring the previous semester.2. When the Student indicates that he/she is done viewing the grades, the use case terminates.Alternative FlowsNo Grade Information AvailableIf, in the Basic Flow, the system cannot find any grade information from the previous semester for theStudent, a message is displayed. Once the Student acknowledges the message, the use case terminates.Special RequirementsNone.Pre-ConditionsThe Student must be logged onto the system before this use case begins.Post-ConditionsThe system state is unchanged by this use case.Extension PointsNone.。
2020智慧树,知到《软件工程导论》(江西师范大学)章节测试完整答案
2020智慧树，知到《软件工程导论》（江西师范大学）章节测试完整答案见面课：软件艺术--软件的构造1、问题:以下哪个不属于人机交互的内容选项：A:有用信息获取的速度B:用户对需求的输入C:人机交互界面设计D:系统信息处理答案: 【有用信息获取的速度】2、问题:以下哪个不属于用户界面的方向选项：A:用户研究B:界面设计C:交互设计D:用户体验答案: 【用户体验】3、问题:交互设计的主要内容包括选项：A:用户体验与用户研究B:交互设计方法和流程C:视觉可视化设计D:系统信息处理答案: 【用户体验与用户研究;交互设计方法和流程;视觉可视化设计】4、问题:用户研究需要解决的问题是选项：A:它是得到用户需求和反馈的途径B:它是检验界面与交互设计是否合理的重要标志 C:它是了解用户使用行为的途径D:它是产品设计的依据答案: 【它是得到用户需求和反馈的途径;它是检验界面与交互设计是否合理的重要标志】 5、问题:UI交互设计的三大模型是选项：A:实现模型B:表现模型C:设计模型D:心理模型答案: 【实现模型;表现模型;心理模型】6、问题:人机交互(HCI)是关于( )的。
选项：A:关于计算机的B:关于人的C:关于产品的D:关于设计的答案: 【关于计算机的;关于人的;关于设计的】7、问题:常用的原型设计工具有选项：A:POPB:AxureRPC:MockplusD:LoadRunner答案: 【POP;AxureRP;Mockplus】8、问题:人机交互就是交互式设计。
选项：A:对B:错答案: 【错】见面课：需求分析文档案例分析1、问题:编写需求说明的原因为选项：A:保证软件开发的质量、需求的完整B:保证业务需求提出者与需求分析人员、开发人员、测试人员及其相关利益人对需求达成共识C:保证软件开发的质量、需求的可追溯性D:其他选项都是答案: 【其他选项都是】2、问题:软件需求规格说明，英文可以缩写为选项：A:SRSB:SRDC:SRMD:SRP答案: 【SRS】3、问题:引言是对整个软件需求规格说明的概要，它不包括以下哪个内容选项：A:目的B:产品前景C:范围D:参考文献答案: 【产品前景】4、问题:软件需求规格说明包括选项：A:功能性描述B:详细描述C:非功能性需求D:其他选项都是答案: 【其他选项都是】5、问题:软件接口应表述为选项：A:描述系统中软件和硬件每一接口的特征B:描述与产品所使用的通信功能相关的需求，包括电子邮件、Web 浏览器、网络通信标准或协议及电子表格等等C:描述该产品与其他外部组件(由名字和版本识别)的连接，包括数据库、操作系统、工具、库和集成的商业组件D:陈述所需要的用户界面的软件组件答案: 【描述该产品与其他外部组件(由名字和版本识别)的连接，包括数据库、操作系统、工具、库和集成的商业组件】6、问题:下列说法对软件需求规格说明文档描述错误的是选项：A:软件需求规格说明文档的完整性体现为不能遗漏任何必要的需求信息B:软件需求规格说明文档的一致性是指规格说明中的需求与其他软件需求或高层(系统、业务)需求不相矛盾C:软件需求规格说明文档的可修改性表现为需求会因为各种原因而发生变化，而需求规格说明文档必须是可以被修改的D:软件需求规格说明文档的可阅读性指采用文学手段，使文档引人入胜答案: 【软件需求规格说明文档的可阅读性指采用文学手段，使文档引人入胜】7、问题:需求规格说明书的作用不应包括选项：A:软件可行性研究的依据B:软件验收的依据C:软件设计的依据D:用户与开发人员对软件要做什么的共同理解答案: 【软件可行性研究的依据】8、问题:以下属于软件需求规格说明的写作注意事项的是选项：A:格式规范B:明确文档编写目的C:按照写作模板写作D:适当创作答案: 【格式规范;明确文档编写目的;按照写作模板写作】9、问题:编写软件需求规格说明书必须采用标准模板。