软工2019_MucMuc项目个人总结

MucMuc项目个人总结

1.相关链接

2.项目个人分工

  1. 项目总体的部分设计
  2. 后端项目总体构建, 代码实现, 以及测试
  3. 阿里云后端服务器的配置和项目部署

3.开发过程

  1. 开始
    在项目最初的阶段, 整个组对于要做怎样的工作并没有清晰的想法. 不知道如何开始工作, 从何做起, 开发工具为何, 是面临的最大难题. 因为没有任何有对于web开发有经验的成员. 从前后端开发工具的选择上, 到前后端通信的具体流程, 都没有一个较好的认知. 这也直接导致了较长时间的前期准备.
  2. 正式开始
    在正式开始的时我的主要工作就是后端构建, 因为本组也没有后端熟手, 从零学起.
    第一步是寻找开发工具, 在搜寻了一定的资料后, 发现目前主流的后端开发语言(开发工具)是java, php, 和 .net asp. 其中最熟的莫过java, 选择php或者asp都会增加学习成本, 因此本项目的后端基于java开发.
  3. 开发框架与底层数据库选择
    SpringBoot是一个轻量级的, 易用的后端框架, 免去了Spring框架的复杂文件配置或者非轻量级SSM框架的整合过程.
    数据库方面, 本项目采用MySQL, 通过java的JDBC与数据库交互, 进行开发.
  4. 后端设计过程
    在最初的过程中, 后端开发较为顺利. 在写好了一个实体的各层实现后(最初的项目)就上传到了github上, 转为和组员马佳坚共同开发.
    在这之后可以说是问题涌现, 从DAO层到service层到接口层, 从接口多参数传递到fastjson的调用问题. 项目末期图片的传输也成了一大问题.
  5. 接口测试以及修改完善
    最后阶段, 接口的测试. 在开发的过程中除了最初的模板实体的实现接口外, 其他的接口都未经测试. 测试体现出的问题也很大, 各个层都发现了很多错误, 也暴露了不少设计问题.

4.遇到的问题

  1. github使用
    由于各组员, 在本次软工项目之前, 对github了解不多, 鲜有使用, 在项目进行的过程中发生了一些同步以及冲突的问题.
  2. 实体属性名
    在开发的过程中发现fastjson的字段映射存在大小写问题, 导致前后端无法通信.
  3. 合作开发的交流沟通问题
    由于每个人的想法不同, 导致在实现相同功能上的具体实现上也存在差异. 就拿后端开发来讲, 我们二人在service层实现上的风格差异较大, 这也带来后面代码阅读与测试时的一定困难.
  4. 其他...

5.反思与收获

  1. 沟通
    事实上团队合作最重要的就是沟通, 事情讲明白或问明白比闷着头做效果好很多. 如果我事先沟通好代码实现具体细节, 后端项目在风格统一上会做得更好, 错误也会更少.
  2. 设计阶段
    在后端开发中, 大部分的问题都是在实际开发过程中遇到的, 有时候不得不更改不少已经做好的东西. 如果能在设计阶段完善目标, 则可以减少重复改动的成本. 大多数此类问题都是经验不足导致.
  3. 时间观念
    本次项目作业中, 由于前期耽误的时间过长(主要是学习过程), 导致后期时间紧迫, 赶不上进度, 最终导致作业完成度不高, 效果不达预期.

6.课程建议

  • 总体来讲, 不管最终项目完成得如何, 这次合作开发于我而言收获不菲. 但作为一个参与此课程的学生来讲, 我个人认为课程中存在的某些问题也不可忽视.
  1. 分组问题
    我认为分组问题是本课程中的最大问题, 熟话说"闻道有先后, 术业有专攻", 可以说在本次项目开发中, 这一点更凸显出来.
    有的同学可能是web开发熟手, 有的则可能专研过桌面开发, 有的人又善于写网页, 总的来讲, 对于合作开发而言, 分组是一大难题. 就我们组来讲, 都是大数据方向的, 没有接触过安卓开发的, 也没有接触过H5&JS开发网页的, 完成一个web项目, 难度不小.
  2. 课程安排问题
    在最初的几周中, 本课程基本上没有什么实质性的内容, 大多数同学上课也是挂机, 基本上不会听课. 如果能将课程安排往前提个一到两周, 可能更加合适.
  3. 课程内容问题
    课程中可以多增加一些软工项目成功案例的深度剖析, 适当减少一些完全概念性的内容, 增强同学对软工更好的理解, 趣味性也好一点.

原文地址:https://www.cnblogs.com/Sirius-Z/p/12046491.html

时间: 2024-10-08 03:00:24

软工2019_MucMuc项目个人总结的相关文章

软工团队项目个人总结

经过了一个学期的软工课程学习,以及长期的团队开发,收获有下. 用户:创新就是极致的用户体验.在开发我们的这款游戏的开始阶段,我们与校内很多同学交流了一下他们对这款游戏的看法,并与他们在线下对游戏进行试玩,然后他们也对我们提出了很多意见,包括有些时候觉得我们某些地方设置的太傻了,随机性太大,博弈性不够等问题.而且有时候交流还会出现一些问题,但总的来说,我们还是从中挖掘了很多可以改进的点,分析了用户的需要,改进了挺多地方的规则的.然后,秉承着从软工课程上学到的,能让用户少点一下,绝不多点一下的类似的

软工个人项目WC(Python实现)

一.github地址:https://github.com/1371272989/WC.exe 实现功能: 1.-c:统计字符数: 2.-w:统计单词数: 3.-l:统计行数: 4.-a:统计复杂数据(空行.代码行和注释行): 5.-s:递归处理目录下符合条件的文件: 通配符没有全面,只能辨别后缀. 6.-x:通过图形界面选择文件: 可以通过图形界面选择文件,但输出还是在cmd上显示. 二.PSP PSP Personal Software Process Stages 预估耗时(分钟) 实际耗

软工实践项目课程的自我目标

对实践项目完成后学习到的能力的预期 组长说,攻坚安卓方向,那就希望首先懂得安卓这门语言吧 然后就是了解安卓应用的开发过程吧 对项目课程的期望 但愿难度不要太大,虽然越难越锻炼人,但我还是不希望难 有一定的补救机会就更好了 对项目的愿景规划 不懂,好好学习,天天向上!

软工团队项目之项目选择

项目基础:考试练习系统APP 项目扩展:能让客户坚持每天做题的APP 需求分析:首先,用户会选择这个APP,那么必然有做题的必要和需求,也许是为了即将来临的考试也可能是真的为了做题给自己填补漏洞,那么不管是哪种情况,大量的刷题是免不了的,那么我们这个APP就有了市场需求. 对市面上已有的类似的APP分析:其实在市场上已经有了很多成熟的类似的APP,那么我们所要制作的就必须有我们的特色.传统的考试系统或是练习系统,基本上都是能从数据库中抽取一定量的题,组合成一套试卷,来供用户使用,而在用户提交答案

2017BUAA软工个人项目之数独

1.项目GitHub地址:https://github.com/ZiJiaW/Soduko (由于一开始把sudoku看成了soduko,于是名字建错了,读起来可能有点奇怪-) 2.项目PSP表格如下: PSP2.1 Personal Software Process Stages 预估耗时 实际耗时 Planning 计划 0.5h 0.5h .Estimate .估计这个任务需要多少时间 0.5h 0.5h Development 开发 20.5h 21.5 .Analysis .需求分析(

软工个人项目——地铁最短路径分析

一.开发环境 IDEA(java) 二.需求分析 设计简单UI界面(Java Swing) 用户可以自行选择起点.终点的地铁线路和对应的站点 用户选择后后台返回一个或多个方案 三.设计思路 启动程序读取地铁站点和线路信息文件"subway.txt",并将站点和线路信息储存在有向图中 根据用户的选择输入起点终点等参数 UI界面提供地铁线路.起始站点和目的站点的选择 通过最短路径算法求解最优的出行线路(采用Dijkstra算法或Floyd算法),将结果输出到一个txt文件 测试优化 四.项

二、软工个人项目:文本信息统计器

本软件的代码:https://github.com/amekao/SE_work1 界面: 一.需求分析阶段: 需求分析: 总需求:需要用户在cmd运行程序,根据所输入的参数提供对应的计算模式 基本功能: -c -w -l 显示字符数,词数,行数 拓展功能:-a 显示具体行数, -s 可以递归遍历指定目录下的文件 高级功能: -x 弹出界面让用户选择要统计的文本,显示所有的信息 二.设计阶段: 考虑到python语言对文本操作提供了较好的接口,而且文件编码也比较丰富,因此决定使用python来完

软工个人项目(Java实现)

一. Github地址: https://github.com/RuiBingo/PersonalWork 二.个人PSP表格: PSP2.1 PSP阶段 预估耗时(分钟) 实际耗时(分钟) Planning 计划 60 20 · Estimate · 估计这个任务需要多少时间 60 20 Development 开发 1200  1080 · Analysis · 需求分析  120  100 · Design Spec · 生成设计文档  30  30 · Design Review · 设

三、软工结对项目:四则运算生成器

一. 1. github项目地址: https://github.com/amekao/SE_work2 2. 界面示例: 生成模式 批改模式 二.PSP表格 PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟) Planning 计划 · Estimate · 估计这个任务需要多少时间 1200 1200 Development 开发 · Analysis · 需求分析 (包括学习新技术) 180 200 · Design Spec