任高军 008
于谦 015
2012/12/15 首次提交作业
2012/12/16 根据老师指出的缺陷和错误进行修改（添加相关链接地址，重新查找一遍学术搜索的移动端应用产品）
作业题目博文地址：http://www.cnblogs.com/xinz/archive/2012/03/26/2417699.html
第一部分
我们用IE9和Chrome浏览器对系统介绍中的每一个功能进行了测试，仅发现一个较为影响使用的功能缺陷。
以co-author graph为例（其他如co-auther path和citation graph等也有该问题），当作者较多并且合作关系复杂时，图片叠在一起，无法看到之间的关系，如下图：
http://academic.research.microsoft.com/VisualExplorer#28553
很自然的，用户会希望将图放大，也确实，右下角有缩放功能，但是放大后：
要知道用户并不是希望看到更大的图片，所以这一缩放功能的开发者未能明确该功能设计的需求依据。
修改建议：图片大小保持不变，调整两作者之间的距离。其实该系统的call for paper模块就有类似的实现：
http://academic.research.microsoft.com/CFP#latest=180
第二部分
通过对开发流程描述http://www.cnblogs.com/xinz/archive/2012/02/20/2358888.html的阅读，我们认为整个开发过程在需求、安全、人员方面存在些许瑕疵，下面是我们对该项目这几个方面的理解和一点建议。
1、需求管理
需求是开发方与客户方沟通协调的情况下产生的，必要的时候这一阶段还会有使用者、投资方等多种角色参与。本项目由于项目开发动机不同，由其他人模拟明确了系统的三种典型用户，并且给出了这三种用户的较为详细的需求。这可能归功于参与开发的研究员和工程人员都直接或者间接参与科研工作，对相关角色的需求较为熟悉。
但是这毕竟是权宜之计，在有了较为完整的原型系统之后，需要更系统的考虑目标用户及其核心需求，而这一步通常需要对实际用户或者潜在用户进行大量的需求信息采集，方式可能有采访、调查问卷等。遗憾的是，至少从该过程描述中来看，没有任何与用户交互的环节。也许由于开发团队综合素质的优势，可以弥补这种需求统计数据的缺失，但是当一个系统与其他系统进行竞争时，还是需要有一个明确的目标用户认知以及必须以此为依托的产品定位。
举例来说，该描述中提到系统中加入了支持facebook和twitter的集成，但是后来发现该功能使用者不多。虽然对于这一团队来说，这一功能实现代价不高，但是这一点暴露出前面所说的需求不明确的缺点。我们在自己组织人手做一些小项目的过程中，我的一般原则是使用最“优质”的人员、时间段来完成系统最关键的部分，避免浪费仅有的一些人员、时间资源。所以核心需求不明确很容易导致人力物力的浪费。
综合上述，我们认为项目在没有一个非常明确的需求分析的前提下，开发到现在完全依赖于开发团队的综合素质，但是作为一个日益庞大并且有潜力的项目，现在急需通过周密的市场分析、用户调查得到的一份需求说明书，从长远角度来看可以明确产品定位提升产品的竞争力，另外还可以合理分配开发资源，避免开发过程中人力物力浪费。
2、安全管理
在系统的V3M2时，该描述很风趣地记录“项目的名声也大了，黑客用他们独特的方式告诉我们网站有问题”，可以理解一个大型系统有一两个安全风险。但问题是我们在解决这个问题方面做了哪些工作。而通读该过程描述，我们只看到一条有关于安全检测的记录，是在V3M3时，“对所有代码进行了安全检查和修复”。
我们可以没有正规冗长的检测和认证过程（C&A），但是至少要有一定形式的安全检查机制，并且该机制应该是贯穿整个开发过程的。这并不是添加一道冗余的工序，而是为了在今后的开发中节省时间、降低风险。
详细来说，相信在V3M3中的代码安全检查修复过程一定耗费了大量人力，而当下一个版本中代码更改了，又没有一个合适的机制跟踪风险，那我们只能再来一次代码检查，所以说如果如同该过程描述所记录的没有风险管理机制，没有一个迭代检测的机制，使得整个系统的风险是不可控的。
对此我们建议添加正规的C&A机制，避免再出现“对所有代码进行…”的情况。
3、人员管理
在V2M3时，“一个新成员说某功能两天就可以搞定，后来搞了两星期，把一个模块活生生搞垮了”，真的很钦佩老师将这样的失败案例加入到过程描述中，其他人会引以为戒。但是仔细考虑之下，这一失败错不在这位新成员（至少不全是他的错），我们认为这主要是项目管理出现漏洞，本身一个两天的计划拖了两星期就是非常不合适的，即使最终这一功能超额完成任务，对于过程管理来说这样的纵容也是百害而无一利的。具体的解决措施（在两天没有完成计划时）可以有调整人员、重新评估等。
上述问题可能的解释是因为这位新成员是临时来的实习生，他的工作不会影响到其他人的进度，并且不属于核心需求。那么这就带来了一个新的问题：对于这种临时人员的有效管理。首先明确的是他们也是开发团队的一员，一个优秀的开发过程管理就应该充分发挥他们的作用。当然对于他们的管理方法可能与常驻成员不同，但同样需要一定的监督和检测机制，避免人员浪费。
在V2M7时，“有些问题太难，研究员们逐步撤出了项目”，可能是微软的项目参与机制具有很大的弹性，这给项目开发带来了很大的困难。但即使这样，其实本项目过程在团队凝聚力方面可以做得更好。
如果是因为问题难而导致部分成员望而却步，那么需要考虑一下我们的计划可行性分析是用来干什么的。我们的计划需要在已有基础上在限定时间内可能解决才算做可行，一个让成员撤出的计划难免让人怀疑存在目标过高的现象，而这种计划的通过也显示出对于人员建议采纳的积极程度。
第三部分
（1）
采访对象：软件工程专业研究生一年级学生
研究方向：网络安全
（2）
（3）
由于突然被采访，该同学便尝试一个最基本的功能：使用微软学术搜索获取网络安全的若干经典论文。
输入network security之后，系统返回了相关文章，该同学对于排在前面的几篇经典论文十分熟悉，并且还有清晰显示的引用次数，该同学对这一初次搜索结果满意。
但由于该同学通常使用google学术搜索http://scholar.google.com.hk/（一个强力的对手），他很自然地去找since某一年的链接，但是却没找到，稍作尝试后发现在advance search中找到相关功能。
（4）
建议：
1、在防止雷同的前提下考虑一下其他类似搜索引擎的用户习惯，更利于争夺这一部分用户。
2、domain下拉菜单，拉下以后，点击空白处无法收回，建议修改。
第四部分
（1）
如同题目中所说的，现在学术搜索产品大多基于web，这方面主要竞争者有google学术（http://scholar.google.com.hk/）、arnetminer（http://arnetminer.org/）等，经过仔细查找没有发现用于学术搜索的移动客户端程序。
经过老师的评语提示后发现我们查找相关产品的过程太粗略，因而两人又进行一轮2小时的查找，下面是目前已有的学术搜索移动端应用：
a、微软亚洲研究院出品的Academic Search Windows Phone版
http://www.windowsphone.com/zh-cn/store/app/academic-search/d9d2f110-37a3-e011-986b-78e7d1fa76f8
b、超星移动图书馆
Andoird版：http://download.sohu.com/down_project/10743/53739.html
iOS版：http://www.appannie.com/app/ios/chao-xing-yi-dong-tu-shu-guan/
c、一些满足特定学校的学术搜索应用
TSTC Publishing：http://www.windowsphone.com/zh-cn/store/app/tstc-publishing-books-technology-you/2dcbfd90-d465-4ceb-b884-301b4e4e2f9c
Education Assistant：http://www.windowsphone.com/zh-cn/store/app/education-assistant/42a43d4f-0276-466c-8ffe-f6bb6a712f4d
（2）
基本功能与web版类似，其中各种graph可能需要适当调整以适应移动端的显示条件。
最大的区别于web版的功能是各学术会议的同步直播。
这一功能的出发点是移动端用户更倾向于获取时效性较高的信息，而普通的微博、SNS对于我们的目标用户（学术界）来说略显冗余。同时我们常常看到一些学术会议注册人员由于种种原因而无法到达会议现场，所以学术会议直播功能应该会很受科研人员欢迎。
当然会议直播应得到会议组织者的同意并且在会议介绍中涉及，从而保证直播信息的合法性和权威性。而直播的形式可以有实时照片、实时speech等。
通过学术会议直播并不是用来完全取代出席会议或者给不参加会议一个理由，因为并不能提供很好的学术交流氛围，这一功能的目标是实时获取会议部分信息。
（3）
用P1…P5表示团队中的5个人
需求分析：P1，P2
可行性分析：P3，P4，P5
开发：P3，P4，P5（直接参与开发的人员在可行性分析更有发言权）
美工：P5（经验：小规模团队中美工也要会技术，否则还要配一个技术人员太浪费）
测试：P1，P2（依据需求的测试，因此这两部分均为P1，P2）
（4）
第1周：
需求分析人员市场调查、潜在用户采访更系统的收集需求，期间不断与可行性分析人员交流，从而更容易确定哪些功能无法实现，哪些功能暂时无法实现。这一周获得第一个版本的需求说明书及其可行性分析。
第2周：
开发人员开始实现软件的第一个版本，该版本应实现软件的核心搜索功能，该过程中美工人员设计大概的信息展示方式。测试人员开始根据需求说明书设计测试用例。
第3、4周：
开发人员加入主要扩展表示功能，即各种图的生成。测试人员可以连通上一周的核心功能一起进行第一轮测试，保证功能的稳定性、安全性。
第5、6周：
开发人员确定特色功能：实时会议功能的具体实现方法及预期效果并和需求分析人员沟通后，开始实现。这部分只需要两个开发人员即可，美工人员可以对已有软件进行第一次全面的界面设计。测试人员设计该模块的测试用例。
第7周：
邀请潜在用户使用系统，需求分析人员记录使用过程及建议，其他人员旁听采访过程。召开阶段总结会议，统一团队对软件的理解，确定下一阶段工作的优先级。
第8、9周：
根据用户反馈升级系统，同时根据阶段会议的工作优先级逐一实现尚未实现的功能。测试人员根据已编写好的测试用例逐一进行测试。
第10周：
开发人员给出软件的beta版本，测试人员根据测试用例进行系统的功能测试以及安全测试、压力测试等，美工人员进行第二次全面美化。
第11周：
邀请更多的潜在用户使用本软件，可联系实际会议举办方尝试实时学术会议功能，全体成员随时准备根据用户反馈修改相关文档、界面或代码。
第12周：
编写软件发布所需的相关文档，发布软件。举行总结会议，每人谈一下12周内的工作感受，具体包括认为对这一过程有什么可改进的、今后对于自身或团队的训练重点等。
来源：http://www.cnblogs.com/softwareengineer/archive/2012/12/16/2820204.html