课程: 软件工程1916|W(福州大学)
做业要求: 结对第一次—原型设计(文献摘要热词统计)
结对成员:131601207 陈序展、221600440 郑晓彪
本次做业目标: 阅读《构建之法》,针对小樱了解顶会论文研究热点的需求以结对的形式进行软件的需求分析以及原型设计,初步体验两人合做的需求分析和原型设计过程
原型设计:顶会热词统计系统
附件:结对第一次—原型设计(文献摘要热词统计).PDFweb
碍于时间紧促,原型制做工具使用笨拙,在基本分析设计了基本需求的界面和功能的基础上,一些附加需求的分析和设计都有待完善
基本需求:数据库
小樱是一名大三的学生,一直痴迷于吃鸡类游戏,某日听闻同宿舍的小狼刚和导师去参加了CVPR会议,心里羡慕不已,便下定决心痛改前非、努力钻研,但愿能在毕业前完成一篇站在时代前沿的优秀论文。但使人苦恼的是,他不知道近几年顶会的热门领域和研究方向,根据论文list去一篇一篇查找总结效率又着实过低,因而求助于“软工实践互助爱心组织”,但愿咱们能帮助他设计一个平台解决现阶段的需求。但愿此平台至少具有如下功能:编程
附加需求:微信
作了需求分析后,咱们绘制了思惟导图,将需求对应的功能放置到了不一样的页面中去app
学术搜索是一个十分具备发展前景的领域,在学术搜索方面,目前市面上有中国知网,百度学术,万方智搜等一些学术搜索平台,相比于这些学术搜索平台,咱们的平台所具备的优点和劣势以下:工具
优点
一、目前的学术搜索平台并不支持批量检索的功能,而咱们的平台支持批量检索的功能,便于用户一次进行多篇论文的检索,提升了用户的检索效率
二、目前只针对于计算机视觉领域的三大顶会CVPR、ICCV、ECCV,因此搜索结果更具备专业性、精确匹配性
三、界面更加美观,易于用户使用操做
四、对于检索结果,提供了诸如关键词图谱、柱状分析图、折线分析图、饼状分析图等直观的表现形式,利于用户使用
五、顶会热词提供了顶会近年来TOP10热词,便于用户了解当前的学术趋势post
劣势
一、相比于其余学术搜索平台,咱们的数据库较小,检索内容有限
二、UI界面人机交互性不足,缺少美感
三、功能分配尚需改进学习
原型设计工具:墨刀测试
登陆注册页:
优化
主页:
检索结果页:
点击“顶会热词”查看顶会热词统计分析
批量搜索页:
点击“TOP10”进入批量论文分析
困难描述
一、在一开始对于需求有些地方不理解,如对论文列表进行增删改操做后面有个备注今年、近两年、近三年是什么意思
二、咱们对需求在原型设计中的权重安排,对功能在界面上的安排一直难以取舍
三、因为咱们都是第一次接触原型设计这个概念,也是第一次使用原型设计工具——墨刀,所以一开始对于墨刀的使用有些不熟悉
解决尝试
一、经过讨论,认为今年、近两年、近三年这三个条件能够做为筛选项,对论文爬取结果列表进行筛选
二、商量重要需求和通常需求,对重要需求,其功能在原型设计时可能要另外加页面,而一些通常需求只须要有所表示便可。如本次原型设计中的热词分析部分和论文批量处理部分,咱们都安排了另外的页面;而对国家、学校以及学校研究方向的统计分析,咱们缩放到检索结果页中的一个侧边栏,让用户能在搜索时看到数据就行了
三、经过查看教程,实际使用,不断提升使用墨刀进行原型设计的能力
是否解决
一、已解决
二、已解决
三、已解决
经过阅读《构建之法》一书和此次实际结对完成做业,对于结对编程的概念有所理解,并经过实践加深了理解,也对原型设计的理念有所了解。同时掌握原型设计工具——墨刀的基本使用方法。
131601207 陈序展
我是在软件工程的第一节课上第一次听到结对编程这个“新名词”的,第一时间我就经过百度搜索,了解告终对编程的基本概念,很快地就找定了本身的队友,后来经过阅读《构建之法》4.5节的内容,对于结对编程的定义有了进一步的理解。在此次的原型设计的过程当中,由于整体设计的时间比较长,因此我与队友之间“领航员”与“驾驶员”的角色时常互换,在实际的设计过程当中,我深入的体会了这种合做方式的好处,在我进行具体设计的时候,队友总能够提出一些我想不到的好点子优化个人设计,而在队友进行设计的时候,我也能够提出一些新的想法,不断地优化咱们的设计。固然咱们在实际的设计过程当中也发现了一些问题,好比一开始咱们可能对一些具体功能只有一些基本的设想,并无制定好详细的设计方案,致使在设计的过程当中,咱们的设计一改再改,浪费了许多时间,这是咱们须要总结并改进的方面。整体来讲,咱们的结对过程仍是比较良好的,咱们都很积极主动的参与任务,并无产生大的分歧,互相均可以积极的听取对方的建议。固然,除了收获了对于结对编程的实际体验,加深了对于结对编程的理解,我也在实际设计的过程当中,掌握了原型设计工具——墨刀的基本使用方法。
221600440 郑晓彪
经过本次对“小樱”需求的分析以及文献摘要热词统计原型设计的实践,我体会了两人合做,虽然时间只有短短五天,可是天天想着小樱的需求,想着原型怎么分配功能,怎么作的好看、合理,两我的提出了不少想法也参考了别人的作法。这么多想法的碰撞很难不和队友产生矛盾,很幸运,和结对伙伴的结对过程还算顺利。就如书中提到的结对过程是一个互相督促的过程,驾驶员和领航员的角色是要时常互换的。由于咱们都很难一眼看透用户需求,很难一下想到大部分功能,并且长时间紧张工做会使咱们的观察力和判断力降低,因此整个过程,我和队友都是相互分享,有不一样的想法就多思考,多参考,相互帮助,最后商量出统一的方法来,我想这在以后团队更多人的合做里是更为重要的。不过虽然过程比较顺利,可是我也发现了在这过程当中本身的问题:
一、在看到需求的时候对功能设计的思惟不够发散,多是眼界和设计实践的局限所致
二、参考越多本身越不知道作什么,这也想加,那也想改的,很头疼
因此,我也很感谢队友,在结对过程当中能提出个人问题,提出他的想法。
根据《构建之法》2.2节的内容,效能分析是对于程序代码的分析,因为咱们的平台目前还停留于原型设计阶段,并无进行效能分析
PSP是卡耐基梅隆大学(CMU)的专家们针对软件工程师所提出的一套模型:Personal Software Process (PSP, 我的开发流程,或称个体软件过程)
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务须要多少时间 | 20 | 20 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 120 | 180 |
• Design Spec | • 生成设计文档 | 60 | 80 |
• Design Review | • 设计复审 | 30 | 30 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 20 |
• Design | • 具体设计 | 450 | 540 |
• Coding | • 具体编码 | 0 | 0 |
• Code Review | • 代码复审 | 0 | 0 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 20 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 20 | 10 |
• Size Measurement | • 计算工做量 | 20 | 20 |
• Postmortem & Process Improvement Plan | • 过后总结, 并提出过程改进计划 | 20 | 30 |
合计 | 850 | 930 |