整体计划安排
截止时间 | 任务 |
---|---|
11.01 | 前端和后端商议确定接口,UI完成首页,前后端完成项目构架搭建,确定模块并分配任务 |
11.15 | 完成前端主体部分,对接后端接口 |
11.18 | 测试,修改,改善性能,检查代码,发布Alpha版本 |
11.23 | 项目完善+用户使用反馈+测试计划改进 |
12.1 | 根据反馈和需求进行新版本的模块编写,发布Beta版本 |
12.4 | 正式版本完善+用户手册 |
团队分工
alpha 版本需要做哪些事情
完成预先规定的功能需求
分工明细
前端:
陈郑铧:构架的搭建,设定前端规范,前端模块开发
陈益:前端模块开发
李镇平:前端模块开发
后端:
沈国煜:设定后端规范,数据库搭建,后端模块开发
张凯:后端模块开发
王泽鸿:后端模块开发
林铮威:后端模块开发
UI:
林云钏:UI设计
测试:
全体成员
思维导图
http://111.230.63.143/team/%E6%80%9D%E7%BB%B4%E5%AF%BC%E5%9B%BE.png
评估团队中每个人对本次作业的贡献比例
陈郑铧:5%(ppt汇报+用例图+活动图)
王思婷:25%(评分+需求报告攥写+制作ppt)
陈佳雯:25%(评分+需求报告攥写+制作ppt)
林云钏:10%(评分+UI制作)
沈国煜:10%(评分+接口需求攥写)
王泽鸿:5%(评分+类图)
李镇平:5%(评分+设计评审表)
张凯:5%(评分+状态图)
陈益:5%(评分+实体关系图)
林铮威:5%(评分+打印+汇总评分表)
评审表格设计
软工实践需求分析审查表
小组编号:01组
项目名称 |
|
队伍名称 |
|
|
组员姓名 |
|
|||
评审内容 |
尊重他组,认真打分,要求实事求是,分数能真实反应报告质量。 |
|||
评审结果 |
说 明 |
|||
思维导图 |
/10 |
|
||
原型 |
/10 |
|
||
独特之处 |
/10 |
|
||
竞争力 |
/10 |
|
||
有量化数据 |
/10 |
|
||
PPT样式 |
/15 |
|
||
演讲力 |
/15 |
|
||
内容 |
/20 |
|
||
优点:
缺点:
建议:
最终分数: /100 |
UML
part1
用例图:
描述的部分:
(1)描述了我们软件必须完成的任务,定义了必须完成的软件功能;
(2)基本呈现用户与用例之间的具体关系;
(3)基本表达系统的基本功能;
(4)基本表达系统的具体行为。
面临的问题:
(1)如何具体对用例进行分类,使得用例更加具体;
(2)如何对用户与不同用例之间的关系详细分析。
解决的问题:
(1)初步获取用户的需求;
(2)指导测试;
(3)在整个过程中对其他工作流起到指导作用。
part2
类图:
描述的部分:
(1)描述了我们软件必须完成的类、接口以及它们之间的静态结构和关系;
面临的问题:
(1)绘制类图软件的选择和该软件在类图绘制上的使用方法
(2)类的定义(如属性和方法)和个数比较不明确;
解决的问题:
(1)与其他负责后端任务的组员讨论交流沟通,确定主要的类的属性、方法和个数;
(2)方便了后端在开发中的设计问题
part3
活动图:
描述的部分:
(1)表情包的制作
(2)表情包的发布
面临的问题:
(1)功能模块较为单一
part4
状态图:
描述的部分:
(1)描述了用户使用小程序的状态
面临的问题:
(1)搜索表情时分类如何更加明确
part5
实体关系图:
描述的部分:
(1)描述小程序中关系概念模型
面临的问题:
(1)如何吸引用户
工具选择
对工具的评价
好用!
答辩总结
现场答辩得分:
回答提问:
1表情包的素材会不会分类,例如熊猫头或者杰尼龟
答:应该会
2虽然市场需求确实挺大的,但还是觉得不会有人为了一个表情而专门去下载app,可能得在宣传上多下点功夫
答:小程序
3表情包的素材方面会不会推出一些新鲜的素材,还是说大部分素材都是当下比较流行的
答:希望表情包的数量足够大
5原型看起来很简陋,希望后期能够改善一下做出比较好的成品
答:感谢建议
6为什么你们的验收验证标准和界面原型不太符合?
答:出了差错,已修改
7为什么你们接口地址都是xxx
答:还没确定具体url
8建议是做出一些与现有的表情包有些不同的表情包,突出特色,吸引用户
答:好的谢谢建议
9你们小程序是只提供从互联网得到的热门表情包?
答:只是其中一个模块
10请问你们的功能中的图片拼接gif是要怎么实现的呢?它的应用场景是什么?
答:技术问题就不在这里长篇大论了..
12活动图分叉是这么用的吗?状态图很多框里不是状态而是动作, MD5加密.
答:感谢指正
修正
http://111.230.63.143/team/2.pdf
1.删除了权限部分的错误,不需要用到什么权限
2.修正了接口部分的url
3.修正了ppt中的验收验证标准
遇到的困难
困难描述:其他课太多了,这门课时太少
做过的尝试:旷课
是否解决:没有
有何收获:学会冷静
PSP
PSP2.1 | Personal SoftwareProcess Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 40 |
Estimate | 估计这个任务需要多少时间 | 0 | 0 |
Development | 开发 | 0 | 0 |
Analysis | 需求分析 (包括学习新技术) | 60 | 90 |
Design Spec | 生成设计文档 | 500 | 700 |
Design Review | 设计复审 | 5 | 5 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) |
0 | 0 |
Design | 具体设计 | 0 | 0 |
Coding | 具体编码 | 0 | 0 |
Code Review | 代码复审 | 0 | 0 |
Test | 测试(自我测试,修改代码,提交修改) | 0 | 0 |
Reporting | 报告 | 0 | 0 |
Test Repor | 测试报告 | 0 | 0 |
Size Measurement | 计算工作量 | 15 | 45 |
· Postmortem & Process Improvement Plan |
事后总结, 并提出过程改进计划 | 45 | 45 |
合计 | 1155 | 2225 |
学习进度条
第N周 | 新增代码(行) | 累计代(行) | 本周学习耗时(小时) |
---|---|---|---|
1 | 100 | 100 | 5 |
2 | 300 | 400 | 10 |
3 | 300 | 700 | 15 |
4 | 1200 | 1900 | 20 |
5 | 0 | 1900 | 5 |