688
社区成员
发帖
与我相关
我的任务
分享| 这个作业属于哪个课程 | 2023年福大-软件工程实践-W班 |
|---|---|
| 这个作业要求在哪里 | 结对第一次作业--原型设计 |
| 结对学号 | 222000303 222000305 |
| 这个作业的目标 | 1、完成原型设计结对作业 2、撰写博客 |
| 其他参考文献 | 《构建之法》 |
第三章:了解到软件开发的工作量和质量的评估参考,主要与任务量/时间的比例、缺陷、按时交付有关,重在看结果,以过程为辅,这也对员工的绩效评估有一定参考性。在这之后还了解了一些思维误区,也很映衬我现在或曾经所进入的一种状态。比如分析麻痹,不用说一个项目,在之前我准备开始学习某方面的知识时,由于需要实践结合,我总是想着这些知识太简单会不会用不上?这个项目扩展性低怎么办?万一以后学到更好的不还得重新做?这也是想要“过早优化”。特别是,当时我正在学习框架方面的知识,于是又想要依赖框架。但之后实习时,带我的主程给我讲了很多开发流程和框架方面的事,才知道这些其实是可以在开发过程中一步一步完成的,而不是在开发之初定下所有的细节,谁也无法保证在正常的开发周期中所有的细节能够实现。
第八章:软件需求确实需要软件团队能够引导出需求(但团队一定是想要一个能够说出需求的客户),对团队来说最重要的应该是成本,这包括了实现难度与资源成本。对于用户来说,需要的一定是便捷有用的软件,拿游戏来说,用户只看做出来的游戏好不好玩、优化好不好、游戏引导怎么样。它们对整体细节是没有概念的(有句话说的好:必须把玩家当三岁小孩)。
澳大利亚网球公开赛是网球四大满贯赛事之一,比赛通常于每年一月的最后两周在澳大利亚维多利亚州的墨尔本体育公园举行,是每年四大满贯中最先举行的一个赛事,也是最年轻的大满贯。我们希望能设计一个平台,通过图表等形式来直观显示选手信息、正式赛每日结果等。
技术上采用客户端的形式开发,通过平台就可以直观地查看澳大利亚网球公开赛的选手排名、每日赛程、详细赛况、晋级图。将各个功能做出区域的区分,菜单和显示区域拥有固定的位置,避免用户注意力的跳跃。分页式的设计交互简单
使用这个产品能够方便地查看大赛信息。这个产品尝试使大部分的组件参展澳洲网球公开赛的结构设计,减少用户花费时间学习使用软件的时间。其次,软件将采用简介的设计,避免信息被复杂的UI设计影响,保证用户使用各个功能的时候有明了的体验,能够第一时间获取其想要的信息。
澳大利亚网球公开赛也算是很出名的赛事了,其他人也一定会推出能够查看赛事的产品。
我方优势:能够简单方便地查看大赛信息。类似一种官方的信息输出平台。作为中文社区能够提供专项的网球赛事信息。
我方劣势:功能不够全面、信息不够细致。由于同是面向PC客户端的用户,很难保证网页端用户愿意迁移。并且由于资源远远比不上网页,无法了解对用户群体想法的掌控。
可以通过QQ、微信、贴吧、微博等媒体进行推广。
Axure Rp
原因是在大二时使用过该工具建立网页原型。该工具的界面简洁易懂,很符合小组对工具样式的要求。
整体仿照原网站的样式,以便提供足够的信息。在顶部设置导航栏,以便随时可以切换主界面内容。增加首页,首页轮播宣传图,默认选中。

每日赛程:顶部有一个下拉菜单,节省空间,下方一个动态面板显示不同日期的赛程。每个赛程为一整个排布用组件,便于动态生成。赛况详情只实现了第一天第一个赛程,用于展示。

详细赛况:依然仿照网页排布,顶部直接显示有关比赛胜者的关键信息,下方密集展示每一个比赛事件,并垂直排布,整体作为一个排布组件便于动态生成。

选手排名:简单的两张表格动态生成。

晋级图:依旧仿照原网站,如果数据多考虑启用水平滚动。实现方式可能为:内部水平排列多个垂直布局,根据比赛信息规划不同间距。

解决:一开始以为是子组件覆盖了父组件的一部分,导致鼠标指针优先对最上层级的组件起作用,于是我将父组件的层级调成高于子组件,并设置为完全透明,但是转念一想,这样并不是真正解决此问题的方法,因为子组件这时候就被覆盖了,之后想要实现子组件的逻辑就又有这个问题了。于是我将这整个组件作为一个组合,这样应该没问题了吧。结果!还是不行,于是我又继续研究,点来点去,发现选中整个组时面板有个选项“Apply wigit”。我开启了它,终于这个问题解决了,但是又出现了新的问题,子组件的边框也高亮了(父组件的效果),但这时我想到css的样式覆盖,我把一些不需要边框的组件取消边框,需要自己独立事件的组成新的子组合,并且不勾选"Apply…",于是这个问题也解决了,现在父子物体都可以独立工作了!
收获:解决问题时首先从未知的或直接的方向入手,再根据自身经验做一些尝试。解决问题后不仅仅能知道这个问题该如何解决,还能获得其他的经验,这可以度量一个问题是否应该解决。
解决:使用动态面板可以解决同框分页的问题,但是动态面板是一种Mask,只能显示动态面板区域的东西,这时候就要启用它的滚动功能,但是启用之后即使下拉到底依然还是不能显示完全(此时有多个动态面板嵌套),我开始思考被滚动是整个面板还是面板中的内容,这涉及到该让哪个面板启用滚动,我先让最里的面板启用,因为它的内容是部分显示的,理应滚动。诶!不行。。那再启用父面板?可以了,但是出现了两个滚动条,太不美观了。后来这样循环尝试了半天,最后发现,子面板的范围超出了父面板导致面板和内容都需要滚动。调回正常范围,启用子面板滚动,问题解决了。
收获:UI即使简单,但也容易出错,当涉及到具体的逻辑时问题就会更多了。
| PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
|---|---|---|---|
| Planning | 计划 | 10 | 5 |
| • Estimate | • 估计这个任务需要多少时间 | 10 | 5 |
| Development | 开发 | 325 | 435 |
| • Analysis | • 需求分析 | 60 | 90 |
| • Learn | • 学习原型设计工具 | 5 | 5 |
| • Discuss | • 结对讨论 | 20 | 30 |
| • Design | • 具体设计 | 180 | 240 |
| • Design Review | • 设计复审 | 60 | 70 |
| Reporting | 报告 | 180 | 220 |
| • Write Report | • 撰写报告 | 120 | 180 |
| • Postmortem | • 事后总结 | 60 | 40 |
| 合计 | 515 | 660 |
通过这个PSP表格,发现在需求分析、具体设计和撰写报告上面的时间与预估出入较大,主要是因为做原型这东西是第一次,还不太熟练,需要反复地去修改,令原型能够正确反映我们的产品,能够满足需求。写报告也特别地费时间。对时间的估计也不够准确,没有正确认识自己的能力,以后需要改进。
陈博源:以往的作业基本都是自己一个人完成的,这次的结对说实话还蛮新鲜的。因为是舍友,沟通起来也容易。两个人一起做真的比一个人单独做轻松了许多。
陈宇焜:作业量适中,结对能有更多的时间处理自己方向上的学习内容,对于原型开发,既要考虑实现的任务量,又要完整地达到客户的需求。此次使用的原型工具与开发过程部分类似,节省很多思考时间。

对陈宇焜的评价:动手能力强,比我更熟练地使用Axure Rp,能够很耐心地回答我的问题,原型设计有他真是帮大忙了。
对陈博源的评价:能够达到良好的沟通,能接受观点、提出问题,及时解决问题,排除误区,减少工作量,能够承担并完成相应的任务。