软件工程课程设计题目-2016
软件工程课程设计选题
软件工程课程设计选题第一篇：软件工程课程设计选题软件工程课程设计选题1、俄罗斯方块设计俄罗斯方块游戏程序，用户可以通过平移和转动自动落下的不同形状物体，填满一行来得分。
开发智力和反应能力。
要求（1）界面的左侧是游戏区域。
新的图形会在顶部刷新，并且自动下落，可以通过方向左右键平移和方向上键顺时针旋转来控制图形落下的位置。
（2）界面的右侧是选项和显示区，显示现在的得分，以及开始游戏、暂停游戏、结束游戏按钮。
2、商品销售统计编写商品销售统计程序，商品的信息有：商品的名称，计量单位（重量或件），单价。
所有商品的信息事先已存入计算机，屏幕上显示所有商品的名称，选择商品名，输入商品计量单位(如重量，件数等)，根据单价算出总价。
客户一次购物可能购买多种商品，程序应计算出客户应付的钱款数。
要求（1）第一部分用于输入商品的信息并允许修改和删除；（2）第二部分实现销售统计。
程序运行时由用户选择进入哪一部分功能，并能在运行时在两部分之间切换。
第二部分运行时，首先显示所有商品名称及代码（商品数目较多时，应考虑分屏显示），用户输入商品代码及商品重量或件数，用户一次操作可输入若干商品的购买信息，然后输入一个特殊的代码表示本次购物结束。
此时。
程序计算出应付钱款数并显示。
3、校园卡管理系统针对校内通用的校园卡需要统一管理这一需求而推出。
通过这个程序，可以较为方便地实现用户的登陆以及个人信息的查询更改等服务，同时管理员将以特定的帐号登陆，实现对所有用户信息及账户信息的管理。
要求（1）以用户身份登陆可查询个人信息，并对相关信息作出修改，提交后新信息将写入数据库，取代原有信息。
可查询个人的帐户信息，包括帐户余额、今日消费、末次充值情况等。
可实现网上充值，通过与银行卡的连接，只要用户输入正确密码，即可从银行卡往校园卡转帐，同时帐户信息中末次充值情况将自动更新。
可修改个人的登陆信息，对登陆密码作出修改。
（2）以管理员身份登陆，可查阅所有用户的信息，以及他们对应的帐户信息。
软件工程课程设计报告
软件工程课程设计报告( 2015 -- 2016 学年第一学期)课程名称：软件工程课程设计题目：学生宿舍管理系统院系：控制与计算机工程学院班级：组号：组长：组员：指导教师：设计周数：两周小组成绩：日期：2016 年1月8日《软件工程》课程设计任务书一、目的、要求通过软件开发的实践训练，进一步掌握软件工程的方法和技术，提高软件开发的实际能力，培养工程设计能力和综合分析、解决问题的能力。
具体如下：1.学习和实践在分析和设计计算机应用系统所需要的知识,包括面向对象的系统分析与设计,编码和测试方面的知识；2.熟悉自动化的软件开发工具Rational Rose，并将其运用于软件开发的全过程；3.进一步加强和提高软件工程文档的编写能力；4.培养协作能力和团队精神。
二、主要内容1．运用面向对象方法进行校园宿舍管理系统的需求分析与设计；2．建模语言采用UML，以Rational Rose为建模工具，进行系统的静态建模和动态建模；3．利用对象模型自动生成数据模型,自动建立数据库；4．使用hibernate技术以面向对象的方式编程管理数据库，前端使用html+css结合javaScript 进行设计，后台逻辑采用java来实现，整个系统采用了ssh框架来实现，使得各个模块低耦合，分层明确，提高了代码的重用以及二次开发；5．撰写课程设计报告。
三、任务分配四、进度计划序号设计内容名称完成时间备注1 分组及确定题目1个工作日2 初步的需求分析与设计建模, 确定实2个工作日现平台，并搭建环境3 详细的需求分析与设计建模2个工作日进行中期检查4 关键模块的实现与测试3个工作日5 编写课程设计报告1个工作日6 验收检查及评定成绩1个工作日五、设计成果要求1．建立系统分析模型与设计模型；2．初步建立系统原型，实现关键的功能；3．编写课程设计报告。
六、考核方式1．系统演示及讲解占50%。
2．设计报告占50%。
指导教师：日期：2015 年12 月25 日《软件工程》课程设计成绩评定一、指导教师评语二、成绩学号姓名成绩备注指导教师：日期：2015 年 1 月8 日摘要：学生宿舍管理是学校的一项重要工作，使用计算机技术来管理学生宿舍，不但可以节省时间、人力和资源，更能全面有效地掌握学生的基本情况，及时获取最新的准确资料和信息，加强对来访人员的管理，优化宿舍内部信息的公示，提高报修物品的处理效率，督促学生提高宿舍的卫生质量，重点监控学生缺寝情况，为同学们营造一个良好、舒适、安全的宿舍环境，从而提高生活质量。
软件工程课程设计(酒店管理系统)
《软件工程》课程设计报告题目：酒店管理系统一．1.1 系统介绍 (3)1.2 系统设计目标 (3)1.3 开辟与运行环境 (3)1.4 系统功能 (3)1.5 系统总体功能需求与性能需求 (4)1.6 业务流程分析 (4)1.7 人员分配 (4)2.1 数据字典 (5)2.2 需求规格说明书 (5)a) 登录模块 (5)b) 前台预定模块 (9)c) 前台接待模块 (11)d) 收银模块 (13)1.1 系统介绍酒店管理系统是一套功能强大而又简便实用管理管理软件，其实现功能包括客房预定系统、前台接待系统、前台收银系统、帐务系统、系统、管理者系统`、帐务报表、匡助信息等功能模块，实现了餐饮住宿娱乐企业日常营运全面自动管理，是餐饮住宿娱乐企业进行电脑信息化管理理想选择。
1.2 系统设计目标为酒店设计出一款现代化管理系统，可以完成酒店所有日常工作，包括客房预定、前台接待、账务结算等业务。
酒店管理系统将先进电脑技术及现代酒店服务管理完美地结合起来，实现了住宿、餐饮、娱乐全新概念服务与管理方式。
本管理系统参照了大量同类软件，旨在用计算机系统来完成所有能完成工作，并保持很高灵便性与易操作性。
1.3 开辟与运行环境采用企业已经拥有硬件环境， windows XP 等 PC 机上安装PowerBuilder 9.0 进行开辟。
在客户端， windows 2000 ，windows XP， Vista, Windows7 等 PC 机上可以直接运行。
1.4 系统功能模块酒店管理系统客房前台前台系客历登录管理报表(图1 模块图)客房预定模块：提供个人预定、团体预定，预定未定处理，预售查询等功能，预定系统可随时查询 30 天以内酒店客房预售一览表，及可售房间数，可查询某间客房预定情况。
前台接待模块：提供个人入住登记，团体入住登记，修改客人信息，转房，调房，等功能，如果客人入住，将会个客人生成一个惟一账号，并允许客人先消费再付帐，最终结算，如果是团体入住，将设置主账号及分账号，并分清消费情况记入主账户还是分账户。
软件工程课程设计可供选的题目
软件工程课程设计可供选的题目1.学生学籍管理系统2.图书查询系统3.电话交费系统4.单机五子棋游戏软件开发5.简单图形显示软件6.学生通讯录管理系统7.医药管理系统8.库存管理系统9.货物进销管理系统10.“贪吃蛇”游戏开发与设计11.学分统计系统12.博客系统13.模拟飞行系统14.多媒体播放设计15.计算机屏保开发16.“扫雷”游戏开发17.基于过滤的个人防火墙设计18.“二合一”小游戏开发19.财务管理系统20.工资管理系统21.项目管理系统22.学校收费管理系统23.基于bmp格式的图象压缩24.教务管理系统25.舰艇对战游戏26.俄罗斯方块小游戏27.企业备忘录系统28.图书借阅管理系统29.学生成绩管理系统30.会员管理系统31.网上订书系统32.银行储蓄系统33.医院药品进销存系统34.英语学习助手35.大学生就业咨询系统36.教务辅助管理系统37.手机话费查询系统38.教师信息管理系统39.人事档案管理系统40.学生公寓管理系统41.球队管理系统42.编写一个记事本程序43.模拟龟兔赛跑44.万年历45.日历记事本46.加密与解密47.小游戏48.聊天小程序49.网络监听程序50.网页浏览器开发其中部分的题目的（数据与功能）要求如下：（一）学生学籍管理系统1、主要的数据表学生基本情况数据表,学生成绩数据表,课程表,代码表等。
2、主要功能模块实现学生基本情况的录入,修改,删除等基本操作。
对学生基本信息提供灵活的查询方式。
完成一个班级的学期选课功能。
实现学生成绩的录入,修改,删除等基本操作。
能方便的对学生的个人学期成绩进行查询。
具有成绩统计,排名等功能。
具有留级,休学等特殊情况的处理功能。
能输出常用的各种报表。
具有数据备份和数据恢复功能。
3、设计要求学生成绩表的设计,要考虑到不同年级的教学计划的变化情况。
对于新生班级,应该首先进行基本情况录入,选课,然后才能进行成绩录入。
（二）图书管理系统1、主要的数据表图书基本信息表,借书卡信息表,借阅信息表,图书分类信息表,代码表等。
软件工程课程设计题目
软件部署与维护
软件部署的目标和任务
确保软件能够在目标环境 中正常运行
提高软件的可维护性和可 扩展性
保证软件的安全性和稳定 性
优化软件性能和响应时间
软件部署的方法和技术
自动化部署：通过脚 本和工具实现自动化 部署，减少手动操作 和错误。
版本控制：使用版本 控制系统（如Git） 来跟踪代码的变更和 部署历史。
从实践中总结出的经验和教训
需求分析：了 解用户需求， 避免后期频繁
修改
团队协作：合 理分工，加强 沟通，避免信
息不对称
进度控制：合 理规划时间， 避免项目延期
测试与调试： 及时发现并解 决问题，确保
软件质量
THANK YOU
汇报人：
软件实现与测试
软件实现的常用编程语言和技术
Java：面向对 象，跨平台，
广泛应用于 Web开发、移 动应用等领域
Python：语法 简洁，易于学 习，常用于数 据分析、人工
智能等领域
C++：高效性 能，适用于系 统级开发和游
戏开发等
JavaScript： 前端开发必备， 用于构建交互 式网页和Web
课程设计的任务和要求
任务：根据软件 工程课程设计要 求，完成一个实 际软件项目的需 求分析、设计、 编码、测试和维
护工作。
要求：学生需按 照软件工程理论， 采用适当的开发 工具和技术，按 照预定的时间表 完成项目，并撰 写相应的文档和
报告。
课程设计的评价标准
功能性：满足用户需求和业务目标 性能效率：运行速度快，资源利用率高 可靠性：系统稳定，故障率低 可维护性：易于维护和升级 可扩展性：适应未来发展和变化
原型法：设计初步 的产品原型，让用 户提前体验并提出 建议和意见
软件工程的15个课程设计课题样本
●题目一: “教务管理系统之子系统——学院课程安排”●系统简介每个学期期中, 学校教务处向各个学院发出下各学期教学筹划, 涉及课程名称、课程代码、学时、班级类别（本科、专科、成人教诲、研究生）、班号等；学院教学主管人员依照教学任务和规定给出各个课程有关限制（如: 任课教师职称、上课班数、最高和最低周学时数等）；任课教师自报本人授课筹划, 经所在教研室协调任可, 将教学筹划上交学院主管教学筹划人员, 批准后上报学校教务处, 最后由教务处给出下个学期全学院教师教学任务书。
●假设上述排课过程所有由人工操作, 现规定为上述过程实现计算机自动解决过程。
●限定条件（1）每位教师主授课程门数不超过2门/学期: 讲师如下职称教师不能承担学院定主课主讲任务。
（2）学院中层干部主讲学时不能超过4学时/周。
（3）本学期浮现严重教学事故教师不能承担下各学期主讲任务。
（4）本系统输入项至少涉及: 教务处布置教学筹划, 学院教师自报授课筹划和学院定关于授课限制条件。
本系统输出项至少涉及: 教务处最后下达全院教师教学任务书和学院各个班级下各学期课程表（可以不含上课地点）。
●题目二: “学校教材定购系统”●系统简介本系统可以细化为两个子系统: 销售系统和采购系统销售系统重要工作过程为: 一方面由教师或学生提交购书单, 经教材发行人员审核是有效购书单后, 开发票、登记并返给教师或学生领书单, 教师或学生可以到书库领书。
采购系统重要工作过程为：若是教材脱销, 则登记缺书, 发缺书单给书库采购人员；一旦新书入库后, 即发进书告知给教材发行人员。
以上功能规定在计算机上实现。
●技术规定和限制条件（1）当书库中各种书籍数量发生变化（涉及进书和出书）时, 都应修改有关书库记录, 如库存表或进/出库表。
（2）在实现上述销售和采购工作过程时, 需考虑关于合法性验证。
系统外部项至少涉及: 教师、学生和教材工作人员。
系统有关数据存储至少涉及: 购书表、库存表、缺书登记表、待购教材表、进库表和出库表。
软件工程课程设计
软件工程课程设计软件工程课程设计题目：固定资产管理系统学院：数学与XXX专业：计算机科学与技术班级：计科学051学号：************学生姓名：XXX同组成员：XXX指导教师：XXX目录：一、可行性报告二、需求说明书三、总体设计说明书四、详细设计说明书五、程序源代码六、课程设计体会七、参考文献第一章可行性报告1.1 固定资产管理概述1.1.1 固定资产的定义根据财政部颁发的《企业会计准则-固定资产》中的定义，固定资产是指同时具有以下特征的有形资产：为生产商品，提供劳务，出租或经营管理而持有的；使用年限超过一年；单位价值较高。
1.1.2 固定资产的标准固定资产的具体标准主要有两个方面：时间标准和价值标准。
根据《企业会计准则-固定资产》规定，固定资产是指企业使用期限超过1年的房屋、建筑物、机器、机械、运输工具以及其他与生产、经营有关的设备、器具、工具等。
不属于生产经营主要设备的物品，单位价值在2000元人民币以上，并且使用年限超过2年的，也应当作为固定资产。
1.1.3 固定资产的分类按其经济用途分类，可以分为生产经营用固定资产和非生产经营用固定资产；按其所有权划分，可分为自有固定资产和租入固定资产；按来源渠道划分，可分为外购的固定资产、自行建造的固定资产、接受投资转入的固定资产、接受捐赠的固定资产、以非货币资金换入的固定资产、改建扩建新增的固定资产、盘赢的固定资产、融资租入固定资产；按使用情况划分，可以分为使用中的固定资产、未使用的固定资产和不需用的固定资产；按其经济用途和使用情况综合划分，可分为生产经营用固定资产、非生产经营用固定资产、租出固定资产（指经营性租赁）、不需用固定资产、未使用固定资产、土地、融资租入固定资产。
1.2 固定资产管理系统可行性分析及开发计划固定资产管理系统是一种对企业固定资产进行管理的软件系统，可帮助企业更好地管理和利用固定资产，提高企业的经济效益。
该系统的开发具有可行性，因为它可以解决企业固定资产管理中存在的问题，提高企业的管理水平和经济效益。
软件工程课程设计报告
淮海工学院计算机工程学院课程设计报告设计名称：软件工程课程设计选题名称：计算机等级管理系统的设计与实现姓名：学号：专业班级：计算机科学与技术系（院）：计算机工程学院设计时间：2016.6.14~2016.7.5设计地点：软件实验室、教室1．课程设计目的软件工程课程设计是计算机专业一个综合性的实践教学环节，其目的在于促进学生复习和巩固计算机软件设计知识，加深对软件设计方法、软件设计技术和设计思想的理解，并能运用所学软件设计知识和面向对象技术进行综合软件设计，通过本课程设计能够进行简单软件系统的开发，掌握软件设计的方法和面向对象程序设计的基本技术，提高学生的综合应用能力。
2．课程设计任务与要求：任务结合《软件工程》、《面向对象程序设计》课程以及相关课程中所学知识，积极完成设计任务。
要求通过设计，深对课程基本内容的理解和综合运用。
学生自选课题学生原则上可以结合个人爱好自选课题，要求课题有一定的深度与难度，有一定的算法复杂性，能够巩固数据结构课程所学的知识。
学生自选课题需在16周前报课程设计指导教师批准方可生效。
要求：（1）通过文献资料查阅和学习，了解当前软件设计技术和一般方法。
（2）参考和研究一些公司和高校/企业成功的软件开发案例和实现方案，结合《面向对象程序设计》、《软件工程》等课程中所学知识，积极完成设计任务。
（3）认真完成需求分析，并根据需求分析完成各设计题目的总体设计、详细设计和测设等环节的设计任务，开发工具推荐使用|Vc++|。
（4）每位同学需提交可独立运行的软件程序。
（5）认真按时完成课程设计报告，课程设计报告内容包括：课程设计目的、设计任务与要求、需求分析、概要设计、详细设计、调试分析、测试结果、附录和设计心得体会等。
（6）每位同学需独立提交设计报告书（每人一份），要求编排格式统一、规范、内容充实，不少于10页（代码不算）。
图1登录界面数据流图图3层次方框图图5考生报名E-R图图7登录流程图图9登录界面4.3考生报名核心代码。
软件工程课程设计参考题目
软件工程课程设计参考题目软件工程是一个综合性强、涵盖广泛的学科，其课程设计是培养学生综合运用所学知识和技能解决实际问题的重要环节。
为了帮助同学们更好地完成软件工程课程设计，以下为一些参考题目供大家选择。
1. 基于C++的学生信息管理系统设计要求设计一个能够实现学生信息的录入、查询、修改和删除的学生信息管理系统。
系统需要支持学生基本信息的录入，并能通过学号或姓名查询和修改学生信息。
2. 基于Java的图书管理系统设计设计一个图书管理系统，实现图书的借阅、归还和查询功能。
系统需要能够记录图书的基本信息，并提供用户账号、密码进行登录和操作。
3. 基于Python的商城网站设计设计一个简单的商城网站，包含商品列表、购物车、订单管理、用户管理等功能。
要求能够对商品进行分类展示，并提供用户注册、登录和购买商品的功能。
4. 基于的在线学习平台设计设计一个在线学习平台，包含课程内容的上传、浏览、下载和讨论功能。
要求能够提供用户账号管理、课程管理和学习记录查看等功能。
5. 基于Android的旅游攻略应用设计设计一个旅游攻略应用，提供用户浏览不同地区的旅游景点、美食、酒店等信息，并支持用户进行评论和分享。
要求能够通过地图定位和导航功能，方便用户寻找目的地。
6. 基于iOS的健身计划管理应用设计设计一个健身计划管理应用，能够帮助用户制定健身计划、记录健身进度和查看健身建议。
要求能够提供用户登陆、个人资料管理和健身数据统计等功能。
以上为软件工程课程设计的一些参考题目，通过选择适合自己的题目，并结合所学知识和技能，能够在课程设计中获得更好的学习效果和实践经验。
希望同学们能够认真对待课程设计，充分发挥自己的能力，取得优秀的成果。
软件工程课程设计题目
软件工程课程设计一、课程设计的目的：●网站设计的目的在于：●学会对网站的调查分析。
●对网站功能、业务、设计等作全面评估，为网站规划和制作做前期准备。
●在网站建设前对市场进行分析、确定网站的目的和功能，并根据需要对网站建设的步骤、建设中的技术、内容、费用、测试、维护等做出规划。
●熟练掌握在商城商店平台上建立网上商店的方法和过程。
●将前期网站规划报告，通过技术手段实现。
●为后期的网络营销建立必要的网站环境。
●学习页面格式内容设计的方法。
●培养独立学习、吸取他人的经验、探讨技术的习惯二、课程设计题目1、软件工程课程设计管理系统。
教师和学生可以应用该系统实现如下功能：（1）学生使用自己的姓名和学号（密码）登陆后，可以从题库中选择一个题目，并且填写同组的其他同学的姓名，学号，班级，小组长等。
且选题一旦保存就不能再更改。
（2）学生可以修改自己的密码。
可以查询自己的选题情况。
学生可以查询自己的课程设计成绩。
（3）学生在课程设计的各个阶段的工作报告上传至该系统。
（4）教师使用姓名和工资号（密码）登陆后，可以查看学生的选题情况；可以查看学生的设计报告，填写学生的项目进度情况，并且给出最后的分数。
（5）教师可以修改自己的密码。
教师把课程设计的题目，学习的资料等上传到该系统。
（6）其他使用该系统的人，可以以客户身份登陆浏览。
2、小型超市管理系统（1）、零售前台（POS）管理系统，本系统必须具有以下功能：商品录入：根据超巿业务特点制定相关功能，可以通过输入唯一编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。
该扫描录入方法可以充分保证各种电脑操作水平层次的人员均能准确快速地进行商品扫描录入。
收银业务：通过扫描条形码或者直接输入商品名称（对于同类多件商品采用一次录入加数量的方式）自动计算本次交易的总金额。
在顾客付款后，自动计算找零，同时打印交易清单（包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号）。
2016年软件工程课程设计题目
College of Computer Science & Technology2016 Software Engineering Practice Project2016.5.30 - 2016.6.24Course Registration RequirementsProblem 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.。
软件工程课程设计题目（合集5篇）
软件工程课程设计题目（合集5篇）第一篇：软件工程课程设计题目1.销售管理系统通过对某公司的订单销售系统进行分析、调查，系统主要实现以下功能：（1）处理顾客和销售员送来的订单。
具体为：销售部门把送入的订单进行数额核对，查看仓库是否有足够的货物。
（2）仓库根据订单来调拨货品，发出货物的同时开出发票。
并且根据需要及时的进货，随时进行盘点。
（3）销售部门收到顾客付款后，根据发票存根及信贷状况进行应收款处理，同时注销已提货的订单。
（4）主管部门对订单、库存进行统计，并且对所有的发票存根进行统计、结帐，完成月报表与年报表的制作。
本系统主要分为四个功能模块。
销售合同管理模块：该模块主要实现对客户及合同的查询，在浏览每个客户的资料时，都将显示与该客户有关的所有的销售记录。
对客户的查询有两种方式；按客户编号和按姓名。
主要功能为：输入销售合同、修改销售合同、删除销售合同、输入销售合同完成情况、查询销售合同（按合同号、客户、产品、交货日期、交货日期区间、合同完成情况等查询）、统计销售合同（按交货日期和产品统计、按交货日期区间和产品统计、按客户和产品统计）。
产品信息管理模块：该模块主要是对产品进行管理，包括查询、修改、添加和删除。
在对产品信息的更新时，将保证更新操作的事务性。
对产品的查询可以查询全部，或者输入产品编号查询。
主要功能为：输入产品信息、修改产品信息、删除产品信息、查询产品信息、按产品名称查询、按产品规格型号查询。
销售记录管理模块：该模块的功能相对复杂一点，主要功能如下：查询销售记录：可以查询某一年内或某月或某日内的所有销售记录。
选择结果的排序方式：可以按产品编号排序，也可以按客户编号排序。
产品信息和客户信息：当用户选择一条记录时，会显示与这条销售记录有关的客户信息和产品信息。
备份功能：将客户查找出来的所有销售记录到出导一个有用户命名的单独的数据表中。
客户意见的管理模块：该模块的主要功能是管理客户购买产品之后的反馈意见，该模块也相对比较复杂，主要功能如下：输入客户信息、修改客户信息、删除客户信息、查询客户信息、按客户名称查询。
软件工程课程设计题目
软件工程课程设计题目一、教学目标本节课的教学目标是让学生掌握软件工程的基本概念、原则和方法，理解软件开发过程中的各个阶段和活动，培养学生分析问题和解决问题的能力，提高学生软件开发实践的能力。
具体来说，知识目标包括：了解软件工程的起源、发展历程和基本原理；掌握软件开发过程中的需求分析、设计、实现、测试和维护等基本活动；理解软件项目管理的方法和技巧。
技能目标包括：能够运用软件工程的方法和工具进行软件开发；具备良好的编程习惯和团队协作能力；掌握软件测试和调试的基本方法。
情感态度价值观目标包括：培养学生对软件工程的兴趣和热情，增强其对软件开发事业的认同感；培养学生严谨、务实的工作态度，提高其职业素养。
二、教学内容本节课的教学内容主要包括软件工程的基本概念、原则和方法，软件开发过程中的各个阶段和活动，以及软件项目管理的方法和技巧。
具体来说，教学大纲如下：1.软件工程概述：介绍软件工程的起源、发展历程和基本原理。
2.软件开发过程：讲解需求分析、设计、实现、测试和维护等基本活动。
3.软件项目管理：介绍软件项目管理的方法和技巧，如进度控制、风险管理、团队协作等。
4.软件工程工具：介绍常用的软件工程工具，如UML、Visio、Eclipse等。
三、教学方法为了提高教学效果，本节课将采用多种教学方法，如讲授法、讨论法、案例分析法和实验法等。
1.讲授法：用于讲解软件工程的基本概念、原则和方法，以及软件开发过程中的各个阶段和活动。
2.讨论法：鼓励学生积极参与课堂讨论，提高其对软件工程的理解和认识。
3.案例分析法：通过分析实际案例，让学生了解软件工程在实际开发中的应用。
4.实验法：让学生动手实践，掌握软件工程工具的使用和方法。
四、教学资源为了支持教学内容和教学方法的实施，本节课将准备以下教学资源：1.教材：选用权威、实用的教材，如《软件工程》、《软件开发过程》等。
2.参考书：提供相关的参考书籍，以便学生深入研究软件工程的相关知识。
软件工程课程设计题目-2016
软件工程大作业课程设计题目：图书借阅管理子系统（LMIS）设计本系统模拟学生在图书馆借阅图书的管理内容，包括查询图书、借书、借阅后的查询、统计以及超期罚款等的处理情况，简化的系统需要管理的情况如下。
（1）可随时查询出可借阅图书的详细情况，如图书编号（bno）、图书名称（bna）、出版日期（bda）、图书出版社（bpu）、图书存放位置（bpl）和图书总数量(bnu)等，这样便于学生选借。
（2）学生查询图书情况后即可借阅所需图书，可借阅多种图书，每种图书一般只借一本。
若已有图书超期，则应在交清罚金后才能开始本次借阅。
（3）为了唯一标识每一学生，图书室办借书证需要如下信息：学生姓名(sna)、学生系别(sde)、学生所学专业(ssp)、借书上限数(sup)及唯一的借书证号(sno)。
（4）每位学生一次可借多本书，但不能超出该生允许借阅的上限数（上限数自定），每位学生可多次借阅，允许重复借阅同一本数。
规定借书期限为二个月，超期每天罚二分。
1．项目：用结构化方法进行需求分析性质：[设计]题目：对系统LMIS进行需求分析目标与要求：（1）用结构化的方法对系统进行需求分析（2）写出需求规格说明书，分别给出系统数据模型（EDM)、功能模型（DFD)、动态模型(状态转换图) 。
(3) 两周内提交2．项目：用结构化的方法进行系统设计性质：[设计]题目：对系统LMIS进行概要设计目标与要求：（1）用结构化的方法对系统进行总体设计（2）写出系统总体设计方案，画出系统总体模块结构图（3）设计数据结构（关键库和表）（4）设计系统的几个主要界面（5）两周内提交3．项目：用结构化的方法进行详细设计性质：[设计]题目：对系统LMIS进行详细设计目标与要求：（1）用结构化的方法对系统中的个别重要模块进行详细（2）写出模块详细设计方案，画出模块流程图（3）对这些模块进行测试，写出相应的测试例（4）两周内提交4．项目：用面向对象方法进行需求分析性质：[设计]题目：对系统LMIS进行需求分析目标与要求：（1）用面向对象的方法对系统进行需求分析（2）写出需求规格说明书，分别给出系统的对象模型、功能模型（DFD)、动态模型。
软件工程课程设计题目
软件工程设计题目1.学生学籍管理系统要求：1）包括基本需求：主要对学生的学籍进行管理。
学籍管理包括各种信息的录入、修改、删除等操作；此外还有对各种信息的查询，便于老师和学生查看。
（其中，教师具备对学籍的录入、修改、删除等操作，学生只具备查询的权限）2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
2.学生成绩管理系统要求：1）包括基本需求：对学生成绩进行综合管理，学生信息要素：学期、学号、姓名、课程名称、课程成绩。
因此学生成绩管理系统的主要功能为：●学生信息管理●课程信息管理●成绩信息管理2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
3.个人通讯录管理系统要求：1）包括基本需求：增加记录、删除记录、显示所有记录、查询记录、退出。
通讯录记录信息包括：姓名，电话，email等。
（其中，用户输入正确的用户名和密码才能看到自己的通讯录信息）2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
4.网上书店要求：1）包括基本需求：购书者可以通过访问Web站点，得到图书信息。
系统可以：●显示每本书的详细信息●显示购物车和顾客选购的图书信息●增加新购买的新书●对定单的修改、确认、提交等●图书销售数量的排行（注意管理员和客户分别具备的权限）2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
5.企业办公自动化管理系统（企业客户管理）要求：1）包括基本需求：针对企业常用的功能设计一个普遍适用的企业办公自动化管理系统，包括考勤管理，客户管理，每天的工作管理，个人信息修改，权限管理，注销等功能。
2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
6.小型商业网站管理系统要求：1）包括基本需求：主要是宣传性质的网站，包括产品展示，公司简介，销售查询，销售排行，商品管理，公告管理等。
（注意分配普通消费者，会员消费者和公司管理人员对该网站的权限）2）自拟扩展需求3项：保证每位组员的分工包括至少一个模块三个功能函数的完成。
软件工程课程设计题目
软件工程课程设计题目一、题目（分组任选一，每组题目不同，每组2-3人）1. 基于WEB的通用试题库组卷系统的设计与实现2. 操作系统精品课程网站设计与实现3. 基于Internet的毕业设计双向选题系统的设计与实现4．民航订票系统5．图书检索系统6．高校设备管理系统7．远程办公系统8. 邮件管理系统9. 手机电子点餐系统10.网络游戏管理系统11. 自选题。
要求：完全按照软件工程的具体过程（即可行性、需求分析、概要设计、详细设计、编码（至少要有两个模块的编码）、测试和维护等过程）完成课程设计。
二、本课程设计的基本步骤1．问题理解和分析（分析）充分地分析和理解问题本身，弄清要求做什么（What to do?）。
本阶段要产生软件需求文档，并提交给指导教师审阅。
2.确定解决问题的方法（技术）主要是找到解决问题的主要思路，是怎么做（How to do?）。
在此阶段可考虑系统的功能和模块划分等。
本阶段要产生软件（概要）设计说明书。
3.详细设计和编码（设计）——要求至少两个功能模块进行编码确定算法的主要流程，再进行编程（Coding）。
在此阶段应提醒学生程序可先在纸上写，尽量想清楚了再动手上机，在编程过程中注意程序结构的清晰性，避免出现很多明显的程序逻辑错误和语法错误，提高后面程序调试效率。
本阶段本来也要编写软件详细设计说明书，但是受时间限制，就不做强制要求，但希望提供。
同时，对存在数据（库）设计的需要提供数据（库）设计说明书。
4.程序调试和运行（调试）使学生掌握程序调试，运用排错/白盒法/黑盒法的基本方法。
本阶段要产生测试分析文档，由其他同学执笔完成（相互测试对方的）。
5.完成课程设计报告（整理）按照课程设计报告格式提交。
本步骤是帮助学生学会在项目完成后，如何整理（Regulate）一个工程项目，以便提交给后来的技术维护人员和提交项目配置管理要求的资料，同时也利于自己提高和撰写科研论文，因此学生必须掌握。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程大作业课程设计题目：图书借阅管理子系统（LMIS）设计本系统模拟学生在图书馆借阅图书的管理内容，包括查询图书、借书、借阅后的查询、统计以及超期罚款等的处理情况，简化的系统需要管理的情况如下。
（1）可随时查询出可借阅图书的详细情况，如图书编号（bno）、图书名称（bna）、出版日期（bda）、图书出版社（bpu）、图书存放位置（bpl）和图书总数量(bnu)等，这样便于学生选借。
（2）学生查询图书情况后即可借阅所需图书，可借阅多种图书，每种图书一般只借一本。
若已有图书超期，则应在交清罚金后才能开始本次借阅。
（3）为了唯一标识每一学生，图书室办借书证需要如下信息：学生姓名(sna)、学生系别(sde)、学生所学专业(ssp)、借书上限数(sup)及唯一的借书证号(sno)。
（4）每位学生一次可借多本书，但不能超出该生允许借阅的上限数（上限数自定），每位学生可多次借阅，允许重复借阅同一本数。
规定借书期限为二个月，超期每天罚二分。
1．项目：用结构化方法进行需求分析性质：[设计]题目：对系统LMIS进行需求分析目标与要求：（1）用结构化的方法对系统进行需求分析（2）写出需求规格说明书，分别给出系统数据模型（EDM)、功能模型（DFD)、动态模型(状态转换图) 。
(3) 两周内提交2．项目：用结构化的方法进行系统设计性质：[设计]题目：对系统LMIS进行概要设计目标与要求：（1）用结构化的方法对系统进行总体设计（2）写出系统总体设计方案，画出系统总体模块结构图（3）设计数据结构（关键库和表）（4）设计系统的几个主要界面（5）两周内提交3．项目：用结构化的方法进行详细设计性质：[设计]题目：对系统LMIS进行详细设计目标与要求：（1）用结构化的方法对系统中的个别重要模块进行详细（2）写出模块详细设计方案，画出模块流程图（3）对这些模块进行测试，写出相应的测试例（4）两周内提交4．项目：用面向对象方法进行需求分析性质：[设计]题目：对系统LMIS进行需求分析目标与要求：（1）用面向对象的方法对系统进行需求分析（2）写出需求规格说明书，分别给出系统的对象模型、功能模型（DFD)、动态模型。
（3）两周内提交5．项目：用面向对象的方法进行设计性质：[设计]题目：对系统LMIS进行总体设计目标与要求：（1）用面向对象的方法对系统进行系统设计（2）写出系统总体设计方案，画出系统三种模型（3）给出系统数据结构和界面设计方案（4）两周内提交1、项目：用结构化方法进行需求分析性质：[设计]题目：对系统LMIS进行需求分析目标与要求：（1）用结构化的方法对系统进行需求分析（2）写出需求规格说明书，分别给出系统数据模型（EDM)、功能模型（DFD)、动态模型(状态转换图) 。
(3) 两周内提交需求分析：一、功能需求：读者管理（1）学生管理简述：学生信息管理，包括信息存入，信息查询，信息修改，信息删除；输入：学生信息处理过程描述，学生信息存数据库输出：操作成功或失败的提示信息（2）老师管理简述：老师信息管理，包括信息存入，信息查询，信息修改，信息删除；输入：老师信息处理过程描述，老师信息存数据库输出：操作成功或失败的提示信息借阅管理（1）学生管理简述：学生信息，包括学生姓名，学号，年级专业，借阅时间，借阅书籍编号；输入：学生姓名，学号，年级，专业，书籍编号，借阅时间；输出：学生姓名，学号，年纪，专业，书籍编号，借阅时间及归还时间，确认提示信息；（2）老师管理简述：老师信息，包括老师姓名，编号，办公室门号，所借书籍编号，借阅时间；输入：老师姓名，编号，办公室门号，所借书籍编号，借阅时间；输出：老师姓名，编号，办公室门号，所借书籍编号，借阅时间及归还时间，确认提示信息；还书管理（1）学生还书简述：学生姓名，学号，年级，专业，借阅书籍编号，借阅时间，归还时间；输入：书籍编号，学生姓名，学号，归还时间；输出：归还确认提示信息；（2）老师还书简述：老师姓名，编号，办公室门号，所借书籍编号，借阅时间，归还时间；输入：书籍编号，老师姓名，老师编号，归还时间；输出：归还确认提示信息；预约管理（1）学生预约简述：学生信息，包括学生姓名，学号，年级，专业，预约书籍编号，预约时间，借阅时间；输入：学生姓名，学号，年纪，专业，预约书籍编号及预约时间；输出：学生姓名，学号，年纪，专业，预约书籍编号及预约时间，借阅时间，确认提示信息；（2）老师预约简述：老师姓名，编号，办公室门号，所借书籍编号及预约时间，借阅时间；输入：书籍编号，老师姓名，老师编号，预约书籍编号及预约时间；输出：老师姓名，编号，办公室门号，所借书籍编号及预约时间，借阅时间，确认提示信息；书籍管理（1）书籍分类简述：书籍信息，包括书名，编号，作者，出版社，入库时间；输入：书名，编号，作者，出版社，本书，入库时间；输出：入库确认信息及分类表。
（2）书籍统计管理简述：书籍信息，库存量；输入：书名，编号；输出：书名，编号，作者，出版社，库存量；二、数据流图借书数据流程图办公室数据流程图三、IPO表四、数据字典读者信息数据字典图书信息记录数据字典借还书记录数据字典五、实体关系图工作人员实体描述借书证实体描述总E—R图2、项目：用结构化的方法进行系统设计性质：[设计]系统功能结构图题目：对系统LMIS进行概要设计运行环境运行平台：Windows XP/Windows 2007/Win 8 CPU: 以上内存：1Gb 以上硬盘：500 gb 以上二、系统功能图读者管理子系统图书管理子系统四、接口设计1、用户接口用户和管理员通过在输入窗口输入登录名和密码进入各个模块2、外部接口（1）图书管理模块为图书统计模块，和图书查询模块提供基础数据。
必须现有图书数据后，才能使用统计和查询模块（2）借阅管理模块为图书管理系统提供基础数据（3）图书管理模块为借书证办理模块为图书借阅模块提供基础数据（4）在借阅模块中可以使用查询模块，查询图书信息五、系统数据结构设计1、逻辑结构设计要点（1）学生信息数据设计（2）图书信息数据设计（3）借书信息数据设计（4）处罚信息数据设计（5）管理员信息数据设计2、数据结构与程序的关系数据结构与程序是软件的重要组成部分，程序的正确执行依赖于合理的数据结构。
六、系统出错处理设计3．项目：用结构化的方法进行详细设计性质：[设计]题目：对系统LMIS进行详细设计目标与要求：（1）用结构化的方法对系统中的个别重要模块进行详细（2）写出模块详细设计方案，画出模块流程图（3）对这些模块进行测试，写出相应的测试例（4）两周内提交详细设计一、系统功能分析1．图书管理功能分析“读者管理”完成的功能是对读者的类别进行设置和对读者的档案进行管理，对于读者的类别，主要是针对不同的读者类型设置其借书的上限，比如教师为8本，研究生为6本，本科生为4本。
并据此创建一个读者类别信息表，对于读者档案管理，实在读者办理图书证的时候对该读者相关信息的登记，并且读者借书证号唯一，并据信息创建一个读者信息表。
2.图书管理功能分析“图书管理”完成的功能是对图书的类别进行设置和对图书的档案进行管理。
对于图书的类别进行设置，图书类别的如上，并据此创建一个图书类别信息表。
图书的档案管理实际上是对每一本书的信息进行登记，并据此创建一个图书信息登记表，由于以上两部分的操作相对简单，所以没有画出流程图。
3.借阅功能分析图书借阅时，首先输入借书证号，然后判断该读者是否已经达到借阅上限，或者有无罚款拖欠现象，在没有拖欠或已缴清欠款后，开始进入借书界面，输入要接的图书编号，若库存大于一，则将图书借出，否则，读者可以选择是否预定此图书。
若预定，将图书加入预定队列，若不预定，则提示读者是否重新选择，然后若是，则循环到输入图书编号阶段，若否，则退出借书页面。
回到主页面。
4.图书归还和处罚功能分析图书归还时：然后开始判断图书是否有因破损，延期，丢失而需要发生的罚款项目，如果没有，则直接进行图书归还处理，更新库存和读者借阅信息，然后判断该图书是否有预定，如果有则E-mail通知读者前来取书。
5.图书预借功能分析二、接口设计1）用户接口用户和管理员通过在输入窗口输入登录名和密码进入各个模块2）外部接口（1）图书管理模块为图书统计模块，和图书查询模块提供基础数据。
必须现有图书数据后，才能使用统计和查询模块（2）借阅管理模块为图书管理系统提供基础数据（3）图书管理模块为借书证办理模块为图书借阅模块提供基础数据（4）在借阅模块中可以使用查询模块，查询图书信息三、运行设计1）运行模块组合本程序主要以一个窗口为模版，一般一个窗口完成一个特定的功能，主窗口通过打开另一个子窗口来实现各模块之间不同功能的链接和组合。
各模块之间相互独立。
各模块主要以传递数据项的引用开实现模块之间的合作和数据共享。
2）运行控制系统运行时根据操作人员的角色，确定各模块的操作权限和数据的处理权限3）运行时间各种模块组合将占用各种资源的时间根据用户的意愿和角色的不同会有区别，可以由用户确定。