系统设计和数据库设计答辩问题汇总

---

整体来讲你们的系统说明书格式广泛存在问题，格式不统一，也和做业规定中的没有具体明确有关系。有若干团队项目系统说明书完成度不高。

• 那周余嘉熊掌将得队
• 追光的人
• echo
• 基于云的胜利冲锋队
• 待就业六人组
• 修！咻咻！
• 云打印
• 葫芦娃
• 火鸡堂
• 为了交项目干杯
• Skyreach
• 男上加男

---

那周余嘉熊掌将得队

• 权限控制打算如何实现？不一样角色拥有不一样的权限，是固定的不可配置；
• 报名经过后能否增长短信提示？目前经过邮箱通知，其余须要收费因此不考虑；
• 是否增长日程管理？有这个功能
• ER图中对关系的理解有误
• 4.2.9中比赛团队表中如何将报名队员与赛事关联?
• 4.2.12实验室老师表中，有无受权结束时间？
• ER图中不能体现比赛所需材料
• 数据安全防御如何保证？
• 数据库设计表与表之间的关联还须要进一步优化
• 安全验证，权限管理方面逻辑设计再完善
• 报名后应增长发送信息
• 如何防止图片木马？
• 查询功能是否知足多条件查询排序？
• 数据库权限角色不分明，统一root权限是否合理？
• 是否存在访问上限？
• 用户提交故障，是否能够加一项草稿或者撤回功能？
• 演讲能够增长一些例子

---

追光的人

• 问卷是否考虑增长条件问题，如回答B题的基础是A题的某选项？没有考虑，太复杂
• 问卷问题文本导入功能？考虑在之后版本实现，点子很好
• 系统设计说明书中的个别图的标号顺序有问题？时间太赶，再仔细检查
• 简答题的题干如何储存？
• 有些查询涉及列表较多，有没考虑创建经常使用的视图？
• 论坛的贴子积累，系统如何扩展？
• 访问速度如何提升？
• 点赞增长取消功能？
• 表设计过于复杂，可否肯定查询效率高
• PPT美化不够，字体加粗放大
• 没有主打功能
• 要考虑带宽

---

echo

• 物业管理系统首先限定在学生宿舍，咱们家小区就没有负责水电费的缴纳
• 界面如何设计的没有在系统设计说明说中看到
• 水电抄表建议增长业主确认环节
• ER图中业主与费用关联有误
• 系统是否考虑投诉、维修、反馈诉求，未处理的状况有误快速筛选功能？
• 对重复报修与投诉，系统如何甄别？
• 投诉有没时效性？
• 投诉有没标志显示是否回复？
• 为何只有舍长能缴费？
• 评审表没有对应本次答辩设计
• 若是舍长进行更换，系统会如何处理？
• 用户的权限如何分配？
• 改进类图，优化类关联
• 物业管理端的介绍不明确
• 类图设计部分冗余
• 对于投诉的表，能够增长日期，或能够重复投诉
• 排序算法未完善
• 对重复维修申请的处理
• 与物业管理的沟通不充分

---

基于云的胜利冲锋队

• 权限表设计？权限表根据角色绑定功能和数据权限
• 系统说明书只写了9页？漏了，下次博客补上
• 本次做业完成流程是什么样的？
• 团队成员的贡献度如何存储？
• 权限控制考虑功能权限与数据权限？
• 未给出模块间的接口定义
• 做业发布后能否编辑?
• 类设计评分类需进一步改善
• 对千帆竞发图的我的查看如何实现？
• 二次评分，好比手误操做如何验证？
• 如何防止学生修改为绩？
• 做业的分类不够精确
• 界面验收部分和功能验收标准不够详细

---

待就业六人组

• 智能推送如何推送，具体谈谈打算用什么算法？
• 我想查看以往投送结果如何查看？
• 有没有考虑增长信用机制，防止恶意发布虚假招聘？
• 智能推荐的信息是否应该存储起来？
• 存在较多岗位描述，但实际上相同
• 推荐算法使用什么具体算法？如何保证有效性
• 信用机制有没加入？
• 推荐有无记录下来？
• 改进ER图和类图
• 注释说明不足
• 计算量较大，如何获取计算资源，下降成本？
• 岗位信息不够完善
• 缺乏用户习惯收集
• 不须要用到推荐算法，其实就是筛选
• 虚假信息的监控不完善
• 大量数据存在内存，会影响性能
• 对岗位的定位较死板
• 未考虑垃圾广告问题
• 对用户所需岗位的按期推送没有存入表中

---

修！咻咻！

• 说明书中的原型设计图呢？后面再完善，由于时间关系，目前一直再作原型迭代
• 在哪一个平台实现？是否是安卓，ios，web都要实现？计划支持Windows和Android，目前是Web端，建议使用Html 5。
• 权限控制表如何实现？经过角色控制功能菜单
• 预定单中为什么要设置3个component字段？
• 若是申请的配件不止3个该如何？
• 学生用户现有设备为何用String列表？
• 维修场次表不能用管理员帐户String
• 预定单与设备是1:1？是的，目前是一个预定单支持一个设备
• 答辩前应仔细检查准备的资料，避免出现纰漏
• PPT图片字体过小，看不清楚
• 表结构过于冗余，一张表快20个属性
• 数据库字段设置不足
• 预定表的设计不够合理
• 普通管理员不该该直接对数据库操做

---

云打印

• 遇到恶意评价如何处理？
• 保留默认好评，以避免用户懒得评价？
• 商家配送能否采用众包形式呢？
• 哪些数据放Redis，哪些放MySQL?
• Redis和MySQL数据交换的策略
• 用户打印要求各项参数如何保存？
• 索引采用什么具体技术？
• 恶意评价如何解决？
• 数据量估计有误
• 过时订单如何处理？
• 负载均衡有考虑但不够
• 演讲内容过多，没有控制好时间
• 没有对言论审查功能
• 用户信息不明确
• 增长评论管理

---

葫芦娃

• 界面设计可否换成电子版？目前不能，计划在Beta阶段实现界面美化
• 玩家与攻击的关系有误
• 武器为什么不存？
• 未来如何扩展？
• 武器类为什么不设置？
• 外挂如何避免？
• 功能模块划分不清晰
• 游戏描述不清楚
• 武器类设计，表设计须要改进
• 类图说明不明确
• 游戏基础技术细节不明
• 扩展性设计不足
• 是否存在同名角色？
• 能够对数据的分类进行思考
• 序号固定数值，不利于后续更新

---

火鸡堂

• 考虑预算制定功能? 需求有，标签里面有额度，额度就是预算
• 验收标准文档4.2标题格式和正文格式相同? 疏忽了
• 验收标准细粒度有待增强? 好的
• 标签没有额度属性，如何预算？
• 是否需联网？
• 如何保证安全性？
• 做为本地软件是否更加合理？
• ER图中的“记录”名称有歧义？
• 功能遗失，需求有，设计没有体现
• 评审表中的NABCD模型无关
• 类图过于简单，表设计还需进一步挖掘
• 表设计没有说明
• 与高级便签相比，有何区别？
• 用户分析不明确，市场定位不明确
• 演讲思路不够清晰，内容不够完整
• 记帐功能设计不完整

---

为了交项目干杯

• 没有ER图? 有提供，在数据库说明书中
• 没有系统结构图? 有提供，在系统设计说明书中
• 验收标准格式不清晰? 后期找标准的验收格式 需求分析中已经给出
• 内部接口，外部接口定义错误
• 出错处理过于简单
• 任务接受后，没法完成如何解决？
• 任务有没开始时间和结束时间？
• 表结构适当增长接单效率表
• 计划表不明确，无里程碑
• 表设计无注释
• 数据统计功能不全
• 对于整个任务发布流程是否应该再仔细思考？
• 取消任务，任务违约如何解决？
• 验收标准格式不清晰

---

Skyreach

• 系统说明书的格式是在哪里找到的？怎么和数据库设计书合在一块儿了？经过网络查的，格式不对；
• 验收标准时什么样的？
• 缺乏ER分析
• 数据表结构截图不够完整，没有给出外键和字段说明
• 数据库接口设计没有说清楚
• 评审表能够更新一下，把当次答辩内容体现出来
• 表结构缺少相关的叙述，类设计需进一步优化
• 没有按要求撰写说明书

---

男上加男

• 系统说明书中有多个空标题
• 游戏UI的工做量预估大概有多少？
• 关键的武将武器设计尚未提。如何对战的呢？是相似于炉石仍是三国杀、皇室战争仍是游戏王？
• 并发量考虑不足
• 请改进表结构和ER图设计
• 多设计游戏模式，避免雷同
• 设计文档内容不完整
• 玩法不明确，玩法仍与卡牌游戏类似
• 自主设计UI与卡牌等工做量巨大
• 系统设计不全，原型没见到
• 只作了网站的功能模块
• 并发控制有没考虑？