结对第一次作业--原型设计
| 这个作业属于哪个课程 | <2023年福大-软件工程实践-W班> |
|---|---|
| 这个作业要求在哪里 | <软件工程实践结对作业一> |
| 结对学号 | <222000109 222000112> |
| 这个作业的目标 | 阅读《构建之法》第3章和第8章、结对合作完成网页原型模型 |
| 其他参考文献 | 澳大利亚网球公开赛、Axure Rp、构建之法 |
目录
- 一、原型地址
- 二、NABCD模型的详细说明
- 2.1 什么是NABCD模型
- 2.2 根据NABCD模型进行项目分析
- N(Need,需求)
- A(Approach 方法)
- B(Benefit 好处)
- C(Competitors 竞争)
- D(Delivery 推广)
- 三、原型设计
- 3.1 原型设计工具
- 3.2 原型设计思路
- 四、结果汇报
- 4.1 原型展示
- 主页
- 晋级图
- 选手排名
- 比赛结果
- 4.2 遇到的困难及解决方法
- 五、PSP表格和效能分析
- 5.1 PSP表格
- 5.2 效能分析
- 六、结对体验
- 6.1 结对过程
- 6.2 结对感受
- 6.3 对队友的评价
一、原型地址
二、NABCD模型的详细说明
2.1 什么是NABCD模型
“NABCD”是由Need、Approach、Benefit、Competitors、Delivery这五个单词的首字母组成,分别指需求、方法、好处、竞争、推广五部分。通过对这五部分的分析,可以清楚简明的把项目的特点概括出来。
2.2 根据NABCD模型进行项目分析
N(Need,需求)
[澳大利亚网球公开赛](https://ausopen.com/)是网球四大满贯赛事之一,比赛通常于每年一月的最后两周在澳大利亚维多利亚州的墨尔本体育公园举行,是每年四大满贯中最先举行的一个赛事,也是最年轻的大满贯。
我们需要设计一个平台,通过图表等形式来直观显示:
选手排名
用两个表格分别展示男子、女子单打排名,表格中显示运动员的姓名、排名、参赛场次和得分总数。
每日赛程
展示每一天的赛事,用表格显示比赛类型(女单男单等),比赛场地,参赛选手,比赛时间和比分,且获胜者姓名加粗显示;可以通过上方导航条切换日期查看不同的赛程,也可以点击某场比赛查看详细赛况。
详细赛况
展示比赛的成绩,包含本场比赛参赛选手、每个小场比分和获胜选手、最终比赛的获胜选手等。
晋级图
可以通过晋级图看到选手的晋升路线,晋级图展示选手和姓名和比分,并高亮显示晋级选手;当鼠标移动到某一场比赛时,高亮或显示边框提示
A(Approach 方法)
数据获取
有两种方法,一种是通过数据库事先储存数据后,在有需要的地方调用目标数据并展示;另一种是通过实时爬取对应网站的数据,并转移并显示到自己的网页上。
前端设计
通过导出原型网页获取基础前端框架的html代码,再对其进行优化。
后端编写
使用php和JavaScript等易与html混用的语言进行编写,免去前后端交互的麻烦。
B(Benefit 好处)
使用网页进行展示,只需在浏览器中输入网址即可,方便快捷。
访问网页的用户无需登录就可查看比赛的各项信息,免去管理用户耗费的时间精力。
网页页面简介美观,数据内容详细直观,没有其他无意义信息。
操作简单,详略得当,用户体验良好。
C(Competitors 竞争)
主要竞争对手
- 其他结对小组
- 其他平台的澳网专栏
优势
- 界面更加简洁,对应模块除导航栏外无其他信息,无冗余功能
- 对部分功能进行优化,进一步提升用户使用体验
- 逻辑结构清晰明了,构建和维护成本低
劣势
网页仅展示比赛的各项信息,未提供信息查询功能
网站所使用数据均来自官网已有数据,如有新数据则必须手动更新
D(Delivery 推广)
- 可以在比赛期间在各类体育论坛上发布,吸引网球爱好者对这项赛事的关注
- 也可以将网站作为案例推广给正在学习网页制作的学生,让他们通过类似的基础项目快速入门
- 在抖音、Bilibili等热门视频网站上投稿,凭借其巨大的流量获取关注度
三、原型设计
3.1 原型设计工具
考虑到本次设计的是网页原型,而Axure在PC端的表现更好,也更为多数产品经理所使用,且其可以直接生成一个源文件,方便和队友的交流改进,故最后选用Axure作为本次实现网页原型设计的工具。
3.2 原型设计思路
仿照澳网公开赛的内容结构和整体风格,除去冗余功能,保留选手排名、每日赛程和晋级图这三个页面,其中,点击每日赛程页面中的具体场次可以进入详细赛况页面。
为了使内容更加丰富,我们添加了主页,用来介绍澳网的历史,以及前几届澳网的比赛情况,让用户对澳大利亚网球公开赛有更深入的了解。
以下是原型的结构概览:

四、结果汇报
4.1 原型展示
主页
- 我们主要采取了类似于澳网官方的色调风格

- 主页没有导航栏,取而代之的是类似于菜单展开:

- 下面是主页的其他部分展示:



晋级图
- 左右按钮可以实现滑动效果,以及鼠标经过高亮显示


选手排名
- 这里的表格支持Aces的正序,倒序


比赛结果

- 日期选择下方设置滑动条:

- 点击赛事会进入详细赛况:

- 下拉框支持切换:

4.2 遇到的困难及解决方法
- 如何分工?如何合作?
- 困难描述:本次实践是小组两人的第一次结对作业,两个人都缺少结对合作的经验;而本次实践又需要使用原型设计工具来辅助网页原型的构建,这对我们来说也是陌生的领域。
- 解决尝试:他山之石,可以攻玉,我们参考了往届的学长学姐是如何进行分工合作的,并选择性地移植到我们分工合作的过程中。
- 有何收获:完成一个项目往往不完全取决于个人能力,而是和组员间的默契。要善于学习他人的经验并转化为带有个体特色的收获,再加上合理的分工合作、默契的配合,可以达到1+1>2的效果。
- Axure原型设计工具的使用
- 困难描述:队伍两人都不会使用Axure,而Axure在网上的教程也不多,需要花费较多时间进行摸索。
- 解决尝试:最终我们两人决定,共同学习Axure的使用方法,但是主要由其中一人使用软件进行原型设计,另一人在需要时,帮忙查找对应解决方法,并帮助优化设计。
- 有何收获:在遇到新事物时,我们要有主动学习的热情;在团队合作时,要充分发挥每个人的优势,增加团队的凝聚力,提高团队的效率,达到事倍功半的效果。
- 鼠标悬停显示边框的实现
- 困难描述:原型需求中提到,晋级图页面,鼠标悬停在某场比赛的表格上方时,需要高亮或显示边框提示。在使用Axure进行界面原型设计,具体到这个需求时,我们发现,鼠标悬停功能和我们的想象存在差异:当鼠标悬停在表格上方时,可以实现边框显示,但是当鼠标移开后,并不会恢复原状。
- 解决尝试:我们把鼠标悬停拆解成两个步骤,一是鼠标移入,二是鼠标移出,因此我们对鼠标的移入移出两个动作分别添加了事件;而显示边框在原网站的效果是从淡灰色变为蓝色,我们具体实现时发现无法做到边框颜色的改变,于是将这一步改为提高边框的不透明度。
- 有何收获:在遇到具体的困难时,可以尝试把一个困难拆解为若干个小问题,再逐步解决这些小问题,分布克服困难;也可以将其转化为可实现的、最终效果相似的方案,用自己更加熟练的方式完成这个方案来等效代替难以解决的困难。
- 每日赛程日期条的实现
- 困难描述:不同日期赛程的展示有点类似于导航栏,但是Axure中导航栏不同内容的切换的实质是页面的切换,这无疑使网页结构更复杂;而且不同日期展示的赛程内容和结构大同小异,复用性高,重新编写这些重复内容十分繁琐。
- 解决尝试:我们参考了原网站该部分内容的实现,发现使用的是有序列表+按钮的实现:整个日期条是个有序列表,其中每个日期都对应一个按钮,点击按钮则动态改变下方表格和数据。经研究,我们发现Axure可以将选定的组件构成一块动态面板,然后为其添加滚动条,从而实现所有日期都能同时展示。
- 有何收获:一些需要实现的功,有时候不一定要原封不动地照搬原有的实现方式,而要有自己的思考。在能实现原有功能的情况下,也需要同时考虑实现方式、实现的难易程度以及最终效果,最合适的才是最好的。
五、PSP表格和效能分析
5.1 PSP表格
| PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
|---|---|---|---|
| Planning | 计划 | 60 | 30 |
| • Estimate | • 估计这个任务需要多少时间 | 60 | 30 |
| Development | 开发 | 630 | 720 |
| • Analysis | • 需求分析 (包括学习新技术) | 180 | 180 |
| • Initial Discussion | • 初步讨论 | 30 | 30 |
| • Design Review | • 设计复审 | 30 | 30 |
| • Detail Discussion | • 细节讨论 | 30 | 60 |
| • Prototype Design | • 界面原型设计 | 210 | 270 |
| • Prototype Review | • 原型复审 | 30 | 30 |
| • Test | • 测试(自我测试,修改设计,提交修改) | 120 | 120 |
| Reporting | 报告 | 240 | 300 |
| • Test Report | • 测试报告 | 180 | 240 |
| • Size Measurement | • 计算工作量 | 30 | 30 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 930 | 1090 |
5.2 效能分析
通过对比PSP表格中预估耗时和实际耗时我们发现,时间差距最大的是细节讨论、界面原型设计和测试报告三个环节。
细节讨论
这个环节,我们还未开始在软件上具体实施先前初步讨论的结果,而是在复审初步设计后,对还有不恰当的地方进一步讨论。由于对具体实现部分功能的可行性存疑,所以我们错误估计了原型设计软件可实现的功能,在其可以完成的功能上仍花费时间讨论,使得实际耗时增加。
界面原型设计
由于系统学习原型设计工具需要花费大量时间,我们小组决定先把基础功能学会,在界面原型设计过程中,遇到难题在针对性地查询问题解决办法。事实证明,这是有效的方式,但是问题出在原型设计工具的适用性并不高,导致部分问题难以找到解决办法,很多时候只能查找类似的问题,再想方设法转换成目标问题,有时候甚至会觉得原型设计工具还不如html代码,它确实方便了大部分的原型设计,但是很多细节处理起来没有html那样随心所欲、有章可循。
测试报告
在撰写测试报告的环节中,实际耗时超过预估耗时的主要原因出在小组两人的分歧和描述遇到的困难与解决方法上。因为我们小组的分工是一个人进行界面原型设计,另一个进行原型优化和报告撰写,所以在最后撰写报告的原型设计部分,撰写报告者为原型各个设计做的介绍与原型设计者的原意有出入,所以在写报告过程中,时不时需要返工;在编写遇到的困难与解决方法部分,尽管在原型设计过程中确实遇到了诸多困难,但是要将其转化为书面文字,还是存在一定的麻烦。同时在完成项目时,没有养成遇到困难就记录下来的习惯,导致编写该部分的时候,还要重新回想,这又耗费了时间。
六、结对体验
6.1 结对过程
聊天记录





交流讨论的图片

6.2 结对感受
222000109 方龙飞:这是第一次的结对作业,两个人虽然是舍友,但是一直以来没有合作完成过同一份作业,在完成过程中还经常使用的是个人作业的思维模式,导致分歧的产生。但两人都愿意与对方交流,共同商讨出合理的解决办法。相信下次结对时,会更加熟练、更加默契。
222000112 李思腾:作为舍友,我们在沟通方面很顺畅,在分歧方面我们也迅速的制定出了一套符合双方要求的方案,期待下次结对我们能更加的契合。
6.3 对队友的评价
对222000109 方龙飞:方龙飞同学做事情很稳,对一些操作有着透彻的理解,并且语言表达很好,在博客方面也是他在主要负责将我们的想法完整形象的表达出来。
对222000112 李思腾:李思腾同学学习效率高,对如何使用界面原型工具上手很快,在我们着手设计原型的第一天就搭建好了网页的大致框架。李思腾同学也很有想法,在一些细节的处理上,有自己独到的见解,能用合理的方式解决问题,将预期的效果以不寻常的方式展现出来。
相关推荐
房间界面.xd-----第一次结对作业
第一次结对作业文件
软件工程实践结对作业二.md
"软件工程实践结对作业二.md"这篇文档是关于软件工程实践中的一份结对作业,作业目标在于提升团队协作能力和编程实践技能。作业的参与者是学号为061900408加一和221900239树一的两位同
基于Python语言的P4程序结对作业设计源码
项目的具体任务被划分为不同的结对任务,如第一次结对任务、第二次结对任务等等,表明项目采用分阶段的方式进行,每个阶段都有明确的实践目标和学习重点。
师徒结对.doc
师傅的定期听课和作业批改的监督,确保了教学质量的稳定性与持续提升。徒弟在此过程中,不仅学会了如何准备与实施一堂课,更学会了如何在教学中发现问题、分析问题并解决问题。这种师徒结对模式的益处是全面的。
C#【结对编程作业】小学数学习题助手-附件资源
C#【结对编程作业】小学数学习题助手-附件资源


