组长本次作业博客链接
一、组队后的团队项目的整体计划安排
| 阶段 | 主要任务 | 计划时间 | 内容 |
|---|---|---|---|
| 1 | 项目选题 | 第七周 | 选择可行性强并且能在带给福大学子便利的项目，完成项目描述市场调研，竞品分析等 |
| 2 | 需求分析 | 第八周 | 撰写需求分析说明报告，安排具体分工以及初步原型设计 |
| 3 | 设计分工 | 第九、十周 | 编码规范、平台环境搭建、初步架构搭建、明确细节分工 |
| 4 | 模块编程 综合对接 |
第十一、十二周 | 各模块编码、测试、项目管理同步推进、各模块完成后进行对接 |
| 5 | 测试反馈 | 第十三周 | 实景测试反馈优化、形成最终正式版本 |
| 6 | 优化完善 | 第十四周 | 根据测试反馈优化，形成最终正式版本 |
| 7 | 项目宣发 | 第十五、十六周 | 用户手册、发布、文案 |
二、团队分工
确定alpha版本需要做哪些事情
需要十分紧凑严格的任务安排，需要时间和熬夜，需要团队成员共同的努力和稳定输出...
* alpha版本：
| 模块序号 | 模块名 | 模块具体内容 |
|---|---|---|
| 1 | 登录注册模块 | 完成用户的登录与注册 |
| 2 | 推荐模块 | 根据专业年级只能推荐书籍 |
| 3 | 搜索模块 | 买家自主搜索书籍，按关键字的相关度或者分类 |
| 4 | 交易模块 | 买家和卖家之间下单、线下交易 |
| 5 | 社区模块 | 用户间关于书籍的交流 |
| 6 | 个人基础信息模块 | 昵称、性别等个人信息的编辑存储 |
| 7 | 个性化模块 | 多样的界面 |
各成员分工明细及TODO list
| 成员 | 分工明细 | TODO list |
|---|---|---|
| 张逸杰 | 跟踪项目进程、安排整体计划、后端助攻 | 跟踪后端小分队进程，协商完成后端开发 |
| 苏凯婷 | 前端主力一号 | 完成登录注册模块、搜索模块、个性化模块前端开发 |
| 鲍冰如 | 原型设计、UI设计 | 配合前端开发进程，完成各个界面UI设计 |
| 陈荣杰 | 后端主力三号、接口设计辅助 | 完成各模块的接口设计，配合后端开发 |
| 杨锦镔 | 前端主力二号 | 完成推荐模块、交易模块前端开发 |
| 王嵚 | 接口设计、后端辅助 | 配合完成接口设计、配合完成后端开发 |
| 林家伟 | 后端主力一号、数据库搭建 | 完成后端开发 |
| 黄彬煌 | 后端主力二号 | 完成后端开发 |
| 黄智锋 | 原型设计、UI设计 | 配合前端开发进程，完成各个界面UI设计 |
| 吴智勇 | 接口设计，数据库搭建辅助 | 配合完成接口设计、配合完成数据库搭建 |
| 刘汪洋 | 前端主力三号 | 完成社区模块、个人基础信息前端开发 |
燃尽图
三、思维导图
下面是“易书”app的思维导图：
四、团队成员贡献比例
撰写需求规格说明书的流程图
组员分工及工作量
| 负责人 | 任务 | 工作量比例 |
|---|---|---|
| 张逸杰 | 撰写需求分析报告 | 8% |
| 苏凯婷 | 答辩演讲 | 15% |
| 鲍冰如 | 撰写博客 | 10% |
| 陈荣杰 | PPT和评审表的制作 | 10% |
| 杨锦镔 | PPT和评审表的制作 | 10% |
| 王嵚 | 撰写需求分析报告 | 8% |
| 林家伟 | 撰写需求分析报告 | 8% |
| 黄彬煌 | 绘制UML图 | 8% |
| 黄智锋 | 原型设计 | 10% |
| 吴智勇 | 原型设计 | 8% |
| 刘汪洋 | 文档审核 | 5% |
五、评审表格设计
下面是我们团队此次制作的评审表：
六、UML
Part1 用例图
这里描述的是系统哪个部分？
描述了用户选择买家找书和买家卖书以及买家和卖家交易的方法。
这部分要面临什么样的问题？
如何确定元素之间，角色之间，用例之间关系。
以下设计解决了什么样的问题
明确了用例间的关系，获取了需求，对过程中的其他工作流起到指导作用。
附用例图
Part2 类图
这里描述的是系统哪个部分？
描述的是系统的各种类。
这部分要面临什么样的问题？
需要了解实现功能所需的各个类以及相应方法
以下设计解决了什么样的问题
总结了各个类对象所必需的属性，以及实现活动图各个操作的方法
附类图
Part3 活动图
这里描述的是系统哪个部分？
活动图描述了买家买书和卖家卖书的具体流程，例如寻找书籍和上架书籍信息等。
这部分要面临什么样的问题？
买家和卖家如何交易二手书籍的这个流程需要更多的考量。
以下设计解决了什么样的问题
解决了买家获得所需书籍的方式，包括智能分类和自主搜索，以及卖家和买家之间在社区留言板关于书籍的交流。
附活动图
Part4 状态图
这里描述的是系统哪个部分？
状态图描述了系统在不同使用场景下的状态转移逻辑。状态图将系统分为九种状态，用户首先处于未注册状态，经过注册的触发进入已已注册状态；再经过登录成功的触发进入选择角色（买家或者卖家）的状态；如果进入买家的状态，则可进入找书的状态，进而到买书、结算或者留言的状态，而卖家能经触发进入与买家结算的状态。
这部分要面临什么样的问题？
包括各种状态的设置，状态转移关系的设置。
以下设计解决了什么样的问题
明确了系统在不同使用场景下的状态转移逻辑
附状态图
Part5 实体关系图
这里描述的是系统哪个部分？
用来描述信息系统中概念模型的数据存储。买家具有用户名、支付账号、邮箱等属性，订单具有订单号和订单时间等属性，卖家具有用户名、收款账号、邮箱等属性，书城具有书籍号、书籍名等属性。
这部分要面临什么样的问题？
需要明确数据在系统中各个处理阶段的状态是怎样的。
以下设计解决了什么样的问题
解决了实体间关联模糊的问题。
附实体关系图
七、工具选择
使用StarUML制作思维导图，用例图，活动图，状态图，类图；使用WPS制作ER图、燃尽图。
八、工具评价
StarUML是一款颜值高的软件，简直让人想要迫不及待画个UML图，界面也很简洁，使用起来也没什么障碍，体验很好。WPS是熟悉的工具，制作ER图也没有很大的难度。
九、答辩总结
小组现场答辩得分
| 组名 | 得分 |
|---|---|
| 第一组 | 54 |
| 第二组 | 54 |
| 第三组 | 55.8（去掉最高分） |
| 第四组 | 54 |
| 第五组 | 52.8（）去掉最低分 |
| 第六组 | 54 |
| 第七组 | 54.6 |
| 第八组 | 55 |
| 第九组 | 53 |
| 第十组 | 55.2 |
去掉一个最低分和一个最高分，最后得分54.225
回答提问
(1)请问你们是怎样保证安全性？
由于我们的软件主要面向福大的学生，而学生的学号也具有唯一性，所以针对用户的登录安全，我们到时会在登录注册时进行学号验证，即用户输入教务处账号和教务处密码，绑定成功即可登录注册。
(2)你们是如何对用户上传的二手书籍信息进行审核的呢？
对于二手书籍的审核比较关键的问题是要对用户上传信息的真实性进行验证，而我们的软件要求用户上传商品时同时上传商品照片和商品描述，再者，因为我们的主要用户是福大学子，而我们相信，福大学子是有内涵，有情操，有思想，为人诚信的完美用户，他们是不会做这种上传虚假商品的无聊行径，用户的自觉性也是我们审核工作的保障。
完善和修改需求分析报告
（1）建议：可以添加用户登录安全性的验证
修改：添加了用户的安全性由教务处账号密码保障的说明。
(2)建议：可以添加关于用户上传的二手书籍信息的审核说明
修改：着重说明卖家上传书籍信息时要包括书籍照片和新旧程度介绍，以及添加了号召用户发挥自觉性创建良好二手交易氛围的部分。
十、需求规格说明书
十一、遇到的困难及解决办法
（1）原型设计方面
困难描述：
在我们这款app的原型设计工作上，风格或者功能排版等设计很难将每个人的想法统一起来
做过哪些尝试
两个人参与原型设计，一起决定app各部分的设计，风格也采取简洁风。
是否解决
是，解决了，做出了优秀的原型设计，两个人一起提意见一起设计。
有何收获
增加了我们在移动端原型设计上的经验，在设计的时候也要和队友多交流，避免设计风格不统一的问题。
（2）需求分析报告方面
困难描述：
很难对用户的需求面面俱到地进行分析，一个人下一子都不能做好需求分析，缺乏对项目需求分析的经验，对非功能性需求中的总体需求和性能需求的定义不清楚
做过哪些尝试
安排三人完成需求分析报告，人多力量大；搜寻相关文档，参考网络上的类似案例，逐步深入需求细节
是否解决
是，解决了，明确了用户的需求，顺利制作了需求分析报告
有何收获
对软件工程的需求分析有了初步的认识，也对接下来的工作流程更加了解了。需求分析需要和队友之间密切交流讨论，不断完善分析，感受到了团队的重要性。
十二、PSP
| PSP2.1 | Personnal Software Process Stagese |
预估耗时 （分钟） |
实际耗时 （分钟） |
|
|---|---|---|---|---|
| Planning | 计划 | 20 | 20 | |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 | |
| Development | 开发 | 500 | 650 | |
| · Analysis | · 需求分析（包括学习新技术） | 60 | 90 | |
| · Design Spec | · 生成设计文档 | 220 | 240 | |
| · Design Review | · 设计复审 | 20 | 30 | |
| · Coding Standard | · 代码规范（为目前的开发制定合适的规范） | 0 | 0 | |
| · Design | · 具体设计 | 240 | 220 | |
| · Coding | · 具体编码 | 0 | 0 | |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 | |
| Reporting | 报告 | 50 | 80 | |
| · Test Repor | · 测试报告 | 0 | 0 | |
| · Size Measurement | · 计算工作量 | 30 | 30 | |
| · Postmortem & Process Improvement Plan |
· 事后总结，并提出过程改进计划 | 30 | 30 | |
| · 合计 | 1190 | 1980 |
十三、学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 10 | 10 | 学习axure的使用方法 |
| 2 | 2000+ | 2000+ | 130 | 140 | 学习html,css,js,前端制作 |
| 3 | 1000+ | 3000+ | 20 | 160 | 算法 |
| 4 | 0 | 3000+ | 20 | 180 | 对需求分析报告有了更深了解 |
| ... |