软件工程第一次结对作业
| 这个作业属于哪个课程 | http://dwz.date/cts4 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/SE2020/homework/11224 |
| 这个作业的目标 | 完成需求分析 建立原型模型 |
| 学号 | 031802516 031802513 |
团队简介
团队成员
| 学号 | 姓名 |
|---|---|
| 031802513 | 黄展 |
| 031802516 | 兰杰 |
结对过程
因为我们是舍友，所以在老师一开始说有结对作业的时候我们就组好队了。结对作业出来之后，我们很快就开始初步讨论，但发现讨论过程中存在着跑题的现象，为了防止跑题，我们一起观看了相声《跑题》以及生活大爆炸有关于跑题的片段。随着进一步需求分析，我们决定采用web的形式完成需求，并且很快地着手原型模型的建立。由于我们白天很少有相同的空闲时间，所以我们的结对工作大都是在晚上进行的，工作过程中，我们严格按照结对的要求，一个人作为驾驶员坐在电脑面前工作，一个人站在背后作为导航员。
结对照片
需求分析
NABCD模型
-
N （Need 需求）
实验室的现役成员不能很好的知晓已经出师的学长学姐的去向和现状，已经出师的学长学姐也没有便捷有效的方式了解实验室现役成员的研究方向以及实验室现在发展的情况。 -
A（Approach 做法）
我们团队开发的web给实验室新老成员提供了登录内部页面的功能，账号注册将由管理员审核后通过，解决了成员信息离散的问题，使成员无需访问对方即可查看其研究方向、工作信息等基本信息，也提供了聊天功能使成员之间可以进一步交流，同时提供匹配功能，用户可以匹配到和自己研究方向相同或相近的实验室成员。 -
B（Benefit 好处）
把实验室成员信息集中化，解决了实验室新老成员间交流无门的问题。
匹配功能增强了成员之间交流的效率，优化了用户体验感。 -
C（Competitors 竞争）
web可以在多平台使用
相对于其他开发平台，web 成本低，而且可以呈现出高质量 -
D（Delivery 推广）
在实验室现役成员间可以由实验室指导老师直接推广
要在退役成员之间推广，就需要指导老师、现役成员结合各种社交媒体共同推广
利益相关者
- 开发团队
- 已经离开实验室的学长学姐
- 还在实验室里修炼的学弟学妹
- 投资商--栋哥
原型模型
原型开发工具
Axure RP 9
模型
-
登录界面
login
-
注册界面
没有账户的用户提供个人信息，提交后经管理员审核通过后，即注册成功
-
成员列表界面
用户可以按标签来筛选出某一方向的成员，可以点击其他用户查看具体信息，点击 纸飞机 可以进入私聊窗口，点击❤可以关注该用户。
-
聊天界面
聊天页面除了支持最基本的文本消息，还支持包括文件传输，表情包等类型的消息，还提供保存历史消息等功能。
-
个人主页
个人主页会提供一些基本的信息，点击页面右上角的消息icon可以查看接收到的消息，也提供了查看关注者和粉丝的button,以及github跳转链接（大家都是程序员出身，github可以使成员之间更有效的交流），还提供了留言板块。
-
动态界面
用户在动态界面可以发表/查看动态。
-
匹配界面
用户在动态界面选择想要匹配的技术类型，系统会根据用户的选择匹配到相符的对象。
UML用例图
我们给普通用户（实验室现役成员和退役成员）提供了查看成员信息，跟成员聊天，关注成员，分享动态，留言，同类型成员匹配等功能，系统管理员负责管理用户。
流程图
web的功能流程图
github
-
commit 提交截图
效能分析
两个人都是第一次接触原型模型开发，在前期的软件下载，资源库下载以及建立团队项目等方面花费了比较多的时间，而且在原型建立时没有考虑充分，原型模型的有些部分是在写博客时再返回去删除或是添加的（凸显了先设计好再动手实践的重要性）。虽然两个人都是第一次做原型模型建立，但是凭借着两人多年的 游戏 合作经验，不可取代的默契，让这次结对作业进行的顺利不少。总体上来说这次的结对作业效率达到了预期的效果。
PSP表
PSP
| 2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 80 |
| Estimate | 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | ||
| Analysis | 需求分析 (包括学习新技术) | 40 | 40 |
| Design Spec | 生成设计文档 | 30 | 30 |
| Design Review | 设计复审 | 20 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ||
| Design | 具体设计 | 200 | 240 |
| Coding | 具体编码 | ||
| Code Review | 代码复审 | ||
| Test | 测试（自我测试，修改代码，提交修改） | ||
| Reporting | 报告 | 40 | 30 |
| Test Report | 测试报告 | ||
| Size Measurement | 计算工作量 | 5 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 90 |
| 合计 | 405 | 460 |
