Team project - needs analysis
Overall schedule
| deadline | task |
|---|---|
| 11.01 | Determining front and rear ends negotiate the interface, the UI complete home, building frame front and rear ends to complete the project, task allocation and determination module |
| 11.15 | The front end of the body portion is completed, the rear end of the docking interfaces |
| 11.18 | Test, modify, improve performance, check the code, release Alpha version |
| 11.23 | Project to improve user feedback + + test plans to improve |
| 12.1 | The new version of the module were written based on feedback and demand, Beta version released |
| 12.4 | The official version of the complete user's manual + |
Team division
alpha version of what things to do
Complete the prescribed functional requirements
Detailed division of labor
front end:
Chen Zheng Hua: architecture building, setting the front specification, front-end module development
Chen Yi: front-end module development
Li Zhenping: front-end module development
rear end:
Shen Yu: set the back-end specifications, build databases, back-end module development
Zhang Kai: the back-end module development
Wang Zehong: the back-end module development
Lin Wei Zheng: the back-end module development
UI:
Lin Yun Chuan: UI design
test:
all members
mind Mapping
http://111.230.63.143/team/%E6%80%9D%E7%BB%B4%E5%AF%BC%E5%9B%BE.png
Everyone on the team to assess the contribution of proportion to this assignment
Chen Cheng Hua: 5% (ppt reporting use case diagrams + + Activity FIG)
Wang Shi-ting: 25% (score + write + Create demand report grip ppt)
Chen Jiawen: 25% (score + write + Create demand report grip ppt)
Lin Yun Chuan: 10% (score + UI production)
Shen Yu: 10% (score + interface requirements clutched write)
Wang Zehong: 5% (FIG rates + class)
Li Zhenping: 5% (+ design review score table)
Zhang Kai: 5% (FIG state rates +)
Chen Yi: 5% (+ score Entity Relationship Diagram)
Lin Wei Zheng: 5% (+ score + print summary score table)
Table Design Review
Flexible work practice requirements analysis review form
Team number: 01
| project name |
|
Team Name |
|
|
| Crew Name |
|
|||
| Review content |
Respect for his group, serious scoring, requires realistic, scores can truly reflect the quality of reporting. |
|||
| Assessment results |
Said Ming |
|||
| mind Mapping |
/10 |
|
||
| prototype |
/10 |
|
||
| Special feature |
/10 |
|
||
| Competitiveness |
/10 |
|
||
| There are quantitative data |
/10 |
|
||
| P PT style |
/15 |
|
||
| Speech force |
/15 |
|
||
| content |
/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 |
整体计划安排
| 截止时间 | 任务 |
|---|---|
| 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 |