2020软工第一次结对作业
| 这个作业属于哪个课程 | |
|---|---|
Hi校友
PSP表格
| PSP3.1 | Team Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 20 |
| Estimate | 估计这个任务需要多少时间 | 480 | 500 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 80 |
| Design Spec | 生成设计文档 | 60 | 80 |
| Design Review | 设计复审 | 60 | 40 |
| Design | 具体设计 | 60 | 30 |
| Coding | 具体原型制作 | 180 | 240 |
| Reporting | 报告 | 20 | 30 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 40 |
| Sum | 合计 | 980 | 1080 |
需求分析
用户需求
- 教师、同学们等同一实验室的成员可以相互查看信息
- 学弟学妹们可以看到学长学姐们的去向，这也是是否选择该实验室的重要因素
- 学弟学妹们可以请求已经就业的学长学姐们内推，同时已经就业的学长学姐们可以想学弟学妹们发起内推邀请
- 学生、教师们可以发起求助、帮助别人
- 安全性、隐私性要求同学们的信息要得到良好的保护
- 封闭性，以一个实验室为单位，仅同一个实验室内的成员可见
利益相关者
- 用户：实验室同学、教师
- 顾客：栋哥
- 软件团队：我和我的队友
- 软件工程师：我和我的队友
竞争性需求分析(NABCD模型)
-
N(Need)
在该项目当中，客户的苦衷在于如何实现学弟学妹更加了解学长学姐的毕业去向，因此我们做出了一个实验室专用交流平台，在项目当中，学弟学妹能够向学长学姐发问直接求助，或通过发帖来向实验室成员求助，能够在平台中了解到学长学姐的邮箱、电话等联系方式，可服务于以下几类用户：
1.学弟学妹：学弟学妹通过平台能够更加清楚从实验室学长学姐口中了解到毕业后的待遇，可以查看学长学姐的个人联系方式，以便求助学长学姐进行内推等有利于就业的机会。
2.学长学姐：学长学姐可利用平台了解到学弟学妹目前的困扰，更有利于帮助学弟学妹答疑解惑，了解到学弟学妹当前所掌握的技能，并帮助学弟学妹在公司获得实习机会锻炼自己。
3.教师：教师可通过创建实验室功能将实验室成员集合在一起，在平台中能够更好进行交流，使得学弟学妹与学长学姐间交流更加便捷，同时可进行成员审核，保证在交流过程中隐私等方面的安全性。
-
A(Approach)
1.项目构想：为更加便捷进行交流，该项目做为小程序的形式，不用进行下载APP等操作。
2.安全性：采用简历实验室的方法将实验室成员集合与一起，教师或管理员可以进行身份审核以保证平台的安全性。
3.隐私性：用户可通过个人设置内的选项对自己资料卡的信息进行可选定化显示。
4.实用性：在平台中，学弟学妹可以和学长学姐进行交流以及发帖求助等操作，能够设置帖子的分类如求助帖和内推帖，在查看帖子类型时更加便捷。
5.有效性：平台用户可以通过修改资料卡实时改变自己的资料，以便于他人查看和询问相关信息。
6.封闭性：利用实验室这一机制将非实验室成员隔离开来，保证实验室是一个封闭的环境。
-
B(Benefit)
1.作为小程序内嵌在某Q、某chat中，占用内存小。
2.聊天页面简洁。
3.封闭式聊天，个人资料可选可见范围，隐私性强。
-
C(Competitors)
优势：1.教师和管理员可通过审核成员信息将其拉入或踢出实验室，保证了组织内部的隐私安全性。
2.以内推作为重点，更有利于学弟学妹获取实习机会等有利于就业的机会。
3.以小程序内嵌更加便捷。
劣势：1.UI界面过于简陋。
2.由于实验室的多样性，无法将帖子群发到多个实验室可见，而需要多次在某个实验室内发帖。
-
D(Delivery)
从班级同学出发，让同学体验产品带来的便捷性，让同学帮助转发宣传产品，在拥有一定数量的用户后，发布调查问卷，了解产品在使用中存在的缺点以及收集用户建议，进而完善产品。在产品功能较为完善后进行实验室宣传，拥有更多用户，同样使用问卷形式了解这一阶段当中产品存在的缺陷以及用户建议。在用户达到一定数量后进行校园内宣传，可联系各个渠道进行投放小规模广告，或在线下布置产品体验点进行宣传。
功能的定位和优先级
- 首要功能就是可以查看实验室其它成员的信息(同时要满足信息的安全性、隐私性)
- 其次重要的功能就是围绕内推（学长学姐邀请内推。学弟学妹请求内推）
- 帮助功能包括发起求助，回应求助，方法有（私聊、发帖、回复帖子）
UML用例图
UML类图
流程图
原型模型
注册登陆
编辑信息
首页
消息页面
我的实验室
我的
隐私设置
GitHub的使用
结对过程
讨论照片
工作安排
-
09-20~09-21
确定结对对象
-
09-21~09-23
- 阅读《构建之法》
- 学习原型制作工具墨刀的使用
-
09-24~09-26
- 讨论主要功能、内容
- 确定基于小程序开发
-
09-27~09-28
- 利用墨刀进行原型制作
- 在制作工程中继续讨论完善
-
09-29-09-30
- 博客的编写、完善
- 原型的修改、完善
总结
在结对后，组织进行了阅读《构建之法》，初读还未能深刻了解书中所述软件开发过程中的相关知识和注意事项，但在后续进行产品功能构想以及产品原型设计中才懂得，制作一个较为完整的产品必须将产品功能构想做的完整，在从产品原型设计开始后，产品功能构想的内容会被初步阉割，而团队中总有成员会坚持着初始构想进而出现思想上的分歧，导致回到产品功能构想的修改阶段，耽误产品原型设计的进程。而在考虑到后续开发过程中部分功能实现的难易程度以后，产品原型设计也会受到相应的改变，过于复杂的UI界面导致了开发的难度大，也不符合当前个人实力，但又在保存产品功能的完整线和开发的难易度中犹豫不决。在这次结对作业中，以上点都出现过，在面对开发难度大时，我们选择了产品原型设计的更加简洁以便于开发。但在原型开发后，又发现了产品功能不够完整，进而再次对产品原型进行修改。设计初期的分歧主要集中在产品功能构想以及原型设计中，团队成员思想的不一致导致开发进度缓慢，而这也是需要在团队成员更加互相了解后才能够调解，分歧是必然的，但如何减少今后开发产品过程中分歧的出现是相当重要的，一个好的产品，需要团队每一位成员的共同努力才能够完成。
