终审项目展示

[b]团队成员[/b]

　　PM：符美潇

　　DEV：潘礼鹏、周文祥、焉域政

　　TEST：谢金洛、周文祥、潘成鼎、叶能端



[b]目标设定[/b]

Alpha阶段目标回顾：

　　1.要让爬虫跟原来看起来不一样——新界面！新功能！

　　2.要让爬虫爬得更快——改算法！

　　3.要让爬虫运行不出错——地毯式Debug！

Beta阶段目标回顾：

　　1.更稳定地爬取：线程池。针对Alpha阶段线程异常泛滥问题导致的爬取动作频繁崩溃。

　　2.更高效地爬取：动态爬取功能。实现无间断爬取、长时间爬取、大数目爬取，管理员不必频繁运行程序。

　　3.更健康地爬取：异常清理器。管理已爬取的文件，清除异常状态。

[b]工作分配[/b]



工作的阶段性
　　把每一个功能实现和目标阶段化，从而能更清楚地定义每个阶段衡量的交付件。分阶段的工作方法减少了工作的积压，保证开发的速度。

　


代码复审
　　每一项功能或目标都要求代码复审。分为两个阶段：DEV成员自审和PM代码复审。

　　


单元测试
　　Junit单元测试与两周开发工作同时进行。

　　




日常爬取
　　把爬取动作分摊到Beta阶段的每一个工作日中，避免挤压到最后几日匆忙爬取造成的数据不足。

　　


Debug自主化

　　


[b]时间的统筹[/b]

　　在计划中，我们第一周进行了需求分析和设计，第二、三周进行开发工作、单元测试，最后一周部署、稳定和系统测试。
　　


遇到的问题
　　由于对后期时间规划的失误，影响了工程项目的收尾质量：系统测试和动态爬取。原因主要在两个方面：在第四周稳定和系统测试阶段，由于数据库课设和主观的时间规划失误导致这一周的工作进度缓慢；在第四周之后又因为进入多门科目的考期难以挤出时间。

反思
　　1.在第一周的需求分析和设计中应该重视开发和稳定阶段的风险评估。
　　2.在迭代的各个阶段都需要统筹时间。明天有明天的事情要做。

[b]项目的成果[/b]
1.线程池的实现
　　因爬取速度过快而造成的爬取数目有限的情况不复存在。
　　


2.动态爬取的实现
　　在Alpha阶段中，如果在爬虫正在运行的过程中，我们想要加入新的种子链接，就不得不关闭当前的爬取动作，重新运行程序后添加进行爬取。这样的操作造成如下多个不良影响：
　　1.爬取的内容重复冗余性增加。

　　2.因为每个种子网页的最大爬取数目是不可预见的，管理员需要经常留意当前爬取动作是否已停止，进而决定是否重新运行程序爬取新网页。

　　动态爬取是能够在爬虫运行时不停止爬虫当前的爬取动作而添加种子URL，管理员可以在任何需要的时候进行添加动作。新功能在解决了以上两个不良影响的同时，还具备以下几个优势：

　　1.能为每个种子URL设定爬取数目。

　　2.时间容错性大，能够允许任何时间进行操作。

　　3.不必繁琐的关闭和重新运行程序，操作简易。

　　


3.异常清理器的实现
　　


多组协作工作的需求
1.视频链接爬取
　　


2.限制于基地址的规则爬取



[b]完整的文档[/b]

　　需求分析文档：

　　/article/5928405.html

　　项目设计文档：

　　/article/5928420.html

　　功能规格说明书：

　　/article/5928419.html

　　测试报告：

　　/article/5928447.html

　　源代码管理文档：

　　http://www.cnblogs.com/cnmxfd/p/5068470.html

[b]团队成员贡献[/b]

成员	角色	具体可量贡献	贡献分
符美潇	PM	日常会议组织、10篇Daily Scrum、1篇团队博客作业、发布说明、测试报告、展示博客、事后会议报告	67
潘礼鹏	DEV	开发动态爬取功能。1700行新添和改动代码。	70
焉域政	DEV	开发异常清理器。新添4个.java文件，800行已投入使用的异常显示代码。300行尚未完整的处理代码。	60
周文祥	DEV、TEST	开发线程池。新添600行代码。26次单元测试记录。	61
谢金洛	TEST	界面和监听器维护。涉及1300行的代码维护；累计爬取8W+个文件。	62
叶能端	TEST	相关资料的收集。	10
潘成鼎	TEST	相关资料的收集和功能性建议。	20

爬取数目

文件类型	爬取数目	目标数目
普通网页	73304	50000
问答页	50412	100000
视频链接	16243	30000
pdf	1916	1000
ppt	93	100
doc	138	100

代码比较

　　　　　　


代码覆盖测试

　　


TFS的使用

　　


[b]与M1比较和M2阶段总结[/b]

　　M1的开发工作令人不尽满意，所以在M2的设计阶段，我们团队就对M1的时候分析会议报告进行讨论，对我们M2的设计影响很大。

　　1. 开发阶段的规范性：每个工作日都有工作，每个工作日结束都有交付衡量，在达到一个小阶段的交付标准的时候，需要代码签入。

　　2.单元测试和代码复审的重视程度提高。

　　3.组与组之间协作联系更加密切，由此我们M2的开发是“集市”模式的。

　　4.小组内分工更加明确，工作量更加平均。

　　5.从M1到M2，我们切身体验了一个软件工程项目的生命周期，从需求分析到最后的部署和稳定及发布，实践使得我们对软工理论的理解更深一分。