软件项目管理作业_微软学术搜索bug等

微软学术搜索

第一部分

请分析下面博客描述的软件开发流程和生命周期,  并访问微软学术搜索网站， 测试各种功能:http://www.cnblogs.com/xinz/archive/2012/02/20/2358888.html

在软件测试课上, 我们学到了软件可能有多种类型的 bug， 请利用你所学的知识, 发现这个网站的功能性的缺陷 (functional bug), 至少一个.  用专业的语言描述(每个bug 不少于 40字), 如有必要, 可以配图。

注意,  要求是发现网站功能的问题,  而不是其他问题 (例如数据不全,  某项数据错误, 网速慢, 不支持IE6 等)

 

 

 Bug1：作者出版的边缘数据显示错误

 

 

图1-1 边缘数据错误

上面的数据显示为出版61，但是图示数据最高点为57

 

Bug 2：不能识别分词

 

图1-2 正常结果

 

如上图1-2，如果将and与另两个符号分开，则可以搜索到一些需要的结果，虽然正文中的" ξ1 and η2 "才是我们要找的，而标题中其实是不需要找单独的单词"and"

 

而如果换成连着的会怎样呢？如下图：

 

 

图1-3 不能识别分词

 

微软学术搜索没有给出相应的搜索结果，也缺乏智能提示功能。自动的将ξ1andη2视为一个单词予以搜索。

 

图1-4 不能识别分词

 

         如上图，即使将一部分分词手动的分离，系统任然不能对剩余的输入进行分词识别。

 

         再比如搜索经典的《人月神话》时，若在系统的使用的时候输入man-month和manmonth，两者搜出来的结果差异极大。而对比同类产品，google学术搜索则能给出搜索建议，相较之下微软学术搜索则不那么亲民。

 

Bug3：对重名的学术会议检索有误

   有两个ISWC会议，一个是关于语义网的会议，而另一个则是关于可穿戴式计算机。然而关于可穿戴式计算机的ISWC会议则从07年开始就未被检索。

 

 

第二部分  

你已经看过了这个项目的开发流程描述：

http://www.cnblogs.com/xinz/archive/2012/02/20/2358888.html

指出开发团队在软件工程方面至少 一个不足   (例如关于开发工具,  质量控制, 未来计划等等) 。要言之有物。 如有必要, 可以截图。

 

在项目的开发流程描述一文中提到过“绝大部分模块都进行了大规模的工程性重构，重写”，个人感觉模块的重构和重写是开发过程中不可缺少的一个环节，尽管大家都十分不愿意进行重构和重写，可是有时候还是在所难免的必须经历这么一个阶段。

如此大的一个项目在开发初期肯定考虑到了将来可能存在的需求变化风险。作为一名学生，我觉得尽管是敏捷开发，可是是不是能够在项目初期的时候考虑的再全面点，更详细点，来防止文中提到的大规模的重构和重写的情况出现。

 

 

第三部分  

现在你已经熟悉了微软学术搜索网站，我相信每个同学的朋友中一定有人需要搜索一些学术论文方面的内容. 每人写一个博客,  记载你对这位用户的采访。

提示:  采访提要

1)    介绍采访对象的背景

2)    让采访对象使用10 – 30 分钟学术搜索的功能  （请上传照片证明用户的确正在使用学术搜索,  远程采访的同学请让别人帮忙照相）

3)    描述用户使用这个产品的过程,  用户的问题解决了么?  软件在数据量/界面/功能/准确度上各有什么优缺点?

4)    用户对产品有什么改进意见?

 

采访对象背景：天津大学研一，软件工程专业。

使用产品过程： 打开微软学术搜索，输入论文名，查找相应的会议论文，找到相应的论文。

认为的优缺点： 全英文的界面使用起来很不方便，而且想要找到论文更多的信息的时候不知道该点什么按钮。

改进意见： 可以考虑出一些其他的语言版本，方便大家使用。

 

 

采访对象背景：天津大学本科毕业，现在美攻读EE专业研究生。

使用过程截图：

使用产品过程：

打开微软学术搜索，输入作者的名字，查找作者的相关信息。找到了作者的相关信息之后，又查看了相应的合作作者等信息。初次搜索时遇见找不到作者名字的缘故，但是系统给出了搜索建议所以还不错。

认为的优缺点：

 英语功底较好所以使用起来难度不是很大，但是由于非母语的缘故还是略不方便探索更多的功能。合作作者之前有图表表示感觉很好，但是那些合作图过于拥挤又不能放大显示，看起来很不舒服。而且有的地方线条重叠看起来很费劲。

改进意见：

可以考虑给合作作者关系图中增加一个放大局部查看的功能，建议在考虑作者关系远近的同时，使用更加优良的弹簧算法。

 

 

图2-1 拥挤的作者关系图，不方便直观的看细节关系

 

 

图2-2 拉开之后才能看见细节的作者关系图

 

第四部分

目前学术搜索产品以网页为主, 越来越多的用户开始使用移动设备（手机, 平板设备）, 如果你要开发一个在移动设备上的应用软件帮助学术界的用户（大学老师,研究生, 图书情报人员等），你应该怎么办?  描述下列内容:

目前市场上有什么样的产品了?

你要设计什么样的功能? 为什么用户会用你的产品?

如果你的团队有5个人, 3个月的时间, 你作为项目经理, 应该如何配置角色  (开发, 测试，美工等等)?

描述你的团队在12 周 期间每周都要做什么, 才能在第12周如期发布软件。

 

 

1      目前市场上关于学术搜索的产品大部分仅限于网页搜索，例如谷歌学术，维普资讯，万方学术搜索，Scirus，Vascoda等。

 

2      一个学术搜索产品面向的市场是老师，学生，科研工作者等人，所以需要一个很完整的，功能强大的搜索功能，能够尽可能的涵盖大部分领域，并且搜索的准确率也要有一定的保障，其次可以为产品添加SNS功能，用户可以分享自己觉得优秀的论文，再次添加上推送功能，将最新最热的学术论文向用户推送。

         这样的一个产品技能像传统的学术搜索网站一样为用户提供搜索功能，其次加上SNS化后，可以将研究相同领域的用户关联起来，使得用户之间产生一些很有意思的隐形价值，进一步将一些跨学科的研究人员联系起来，拓宽用户们的研究思维。可以和一些期刊会议合作，讲一些国际会议的最新消息推送给用户，也是本应用的一个亮点。

 

3 A,B,C,D,E 五个人。

项目初期：A,B,C参与开发，C,D参与测试，D,E负责美工；

         项目初期的时候在开发上需要投入一定量的人员，测试相对来说工作量不是特别的大，与此同时，美工也有相当的工作量，需要进行产品UI的第一个Demo的设计。

项目中期：A,B,C负责开发， C,D,E负责测试，E负责美工；

         项目进行到中期的时候，需要投入一定量的人进行功能性的测试工作，确保已经完成的功能点运行稳健。此时美工的工作量相对来说就不是那么的大了。

项目后期：A负责开发，B,C,D负责测试， D,E负责美工；

         项目进行到后期的时候，开发的工作减少到最低，测试的工作也主键攀升起来，所以在测试上投入的人力是最多的，此时，美工的工作有可能随着客户的介入，需要有一定的修改，因此此时也有一定量的人力投入。

 

4      项目采用迭代式开发过程。每周都需要有理会来确认项目的风险点来确保进度的正常进行。人员分工明确，

每个里程碑要有阶段性的会议进行完成任务的检查和下一步任务的确认。

同时还要有组员之间开发经验的沟通交流，确保大家在大方向上的朝着相同的方向前进。彼此不会延误彼此的开发进度。

最主要的是要讨论项目可能存在的风险点，以及如何控制，确保项目按照原计划进行开发。

最后需要提一点，项目文档是贯穿整个12周必须要做的事情，完整的文档是保证项目顺利进行的前提。