结对第一次作业--原型设计

临渊阁主

已于 2024-03-09 15:16:29 修改

阅读量905

点赞数 27

文章标签：软件工程

于 2024-03-09 11:08:00 首次发布

本文链接：https://blog.csdn.net/m0_62917770/article/details/136563380

版权

结对第一次作业–原型设计

这个作业属于哪个课程	软件工程实践-2023学年-W班
这个作业要求在哪里	结对第一次作业–原型设计
结对学号	222100223 222100233
这个作业的目标	1.阅读《构建之法》第三章和第八章 2.在原型设计结对作业中体现阅读成果
其他参考文献	CSDN 稀土掘金

一、原型地址

我们的原型

二、原型工具的使用

我们使用的是墨刀,主要是考虑到墨刀对国内教程的适配性以及易用性

三、原型设计思路及成果展示

3.1 原型设计思路

通过分析用户需求，我们认为用户的主要需求为关于选手排名、每日赛程、详细赛况的直观显示界面。

3.2 成果展示

3.2.1 首页

首页采用轮播图组件来展示赛事盛况

在这里插入图片描述

3.2.2 选手排名

展示选手具体排名的页面

在这里插入图片描述

3.2.3 每日赛程

用户可以通过切换日期来查看不同的赛程

在这里插入图片描述

3.2.4 详细赛况

用户可以在此查看选手具体比赛信息

在这里插入图片描述

四、困难的解决

4.1 困难一：墨刀的使用

困难描述

初次接触墨刀这类原型设计工具，开始上手查阅教程时，要在各种眼花缭乱的菜单中找到最适配当前项目的组件和事件方法，确实废了一番功夫。还有对前端页面的模仿，缺少美学天赋，做出的页面总是不尽人意。

解决方法

参考往届学长的成品，然后在B站寻找墨刀教程视频，并结合博客中的细致操作教学。

心得体会

视频和博客的结合学习方式，对掌握一项新的技术有极大的助力。

4.2 困难二：如何合作分工

困难描述

初次使用墨刀时，我们没有深入了解其内置的团队协作功能，觉得应该优先推进各自项目的进度，然后最后再合并。然而理想很丰满现实很骨感，墨刀中并没有我们想象中的一键合并功能(Git中有)。如果没有即时发现这一问题，最后手工合并的工作量就太大了。

解决方法

学习墨刀内置的团队协作功能，发送邀请链接使队友加入团队，共同操作一个项目。

心得体会

磨刀不误砍柴功，开发项目式在总体规划分工上提前谋篇布局，能事倍功半，免去不必要的重复劳动。

五、PSP表格和效能分析

5.1 PSP表格

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	35
• Estimate	• 估计这个任务需要多少时间	35	40
• Analysis	• 需求分析	45	55
• Learning	• 学习原型设计工具	70	100
• Discussion	• 结对讨论	30	35
• Design Spec	• 生成设计文档	30	35
• Design	• 界面原型设计	360	520
• Test and Improvement	• 原型测试与改进	90	150
Reporting	报告	90	120
• Achievements Exhibition	• 原型成果展示	45	60
• Problem Analysis & Postmortem	• 问题的分析和事后总结	45	55
	合计	870	1205

5.2 效能分析

在界面原型设计方面，由于是第一次使用墨刀软件，我们对其操作及原型设计都较为生疏。在使用过程中，我们遭遇了诸多挑战，例如缺乏充分的使用文档支持，墨刀软件中某些事件响应功能的限制，以及适用于web界面的组件相对较少。这些问题使得界面交云和排版上耗费了过多时间，导致实际设计时间远超预期。

为了改进，我们制定了以下策略：

在开始设计前，应先深入了解并比较不同的原型设计工具，权衡各自的功能及优缺点，以选出最适合项目需求的工具。通过讨论，我们选择了墨刀，但发现它更适合移动端设计而非我们的需求。

在动手使用设计工具之前，应该学习一些基础的设计概念和原则，这将对我们的设计工作大有裨益。

寻求外部反馈：通过将原型展示给老师、助教、用户和同学等，收集他们的反馈和建议，以便优化设计，更好地满足用户需求。

在原型的测试与改进方面，我们认为即使完成了原型设计，这一部分的工作也不应仓促结束，而应细致考虑改进。我们的策略包括：

首先，进行彻底的原型测试，结合多种测试方法，包括用户调研（以舍友模拟用户）、原型演示和可用性测试等。在测试中收集用户的反馈、错误报告和建议。

其次，分析测试结果，识别原型中的问题和错误，确定改进的方向，并详细记录下来。

然后，基于测试反馈进行原型修改，包括设计和功能的优化。

最后，执行再次测试。在多轮改进后，我们累计修改了10多次，最终达到了一个我们认为相对理想的测试标准。