一、设想和目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的系统是《联邦型知识图谱关键词搜索引擎》
由于计算机可以理解RDF 描述和携带的元数据的含义,因此可以做到基于内容的精确检索。为此,我们的系统是一种基于RDF 的科技论文搜索引擎而设计的。查询结果为搜索网页的元数据显示,从而使用户对查询结果有准确的了解,可大大提高用户的搜索效率。
我们对我们所要解决的问题定义的非常清晰，目前，联邦RDF 系统由许多自治的SPARQL 端点组成，SPARQL 端点只提供查询接口而用户不能通过此接口远程下载数据集来建立全局倒排索引，因此，关键字检索受到了很大的挑战。我们基于一种在联邦RDF 系统上进行关键字搜索的方法，通过SPARQL 端点上下文检索把关键字映射到子图结构中，然后通过子图生成SPARQL 查询来查询Endpoints 上的数据集，而不需要在不同SPARQL Endpoints 上建立全局倒排索引。为了提高查询性能，我们设计了多重查询优化策略来重写查询语句，广泛的实验证明我们的技术还是有效的。
我们的典型用户为网络浏览者(即访客)、网站注册用户、网站管理员。要求基本熟悉网络及Windows 操作规范，同时，基本了解Life-Science、Cross-Domain 两个数据库。
1.2 是否有充足的时间来做计划?
我们的团队在一轮迭代过程中有充分的时间完成研究与设计工作，并且开发过程中不断完善我们的前端设计。
这是第一次团队的合作，正处于磨合期。所以效率不是很理想。而且除了这门课程之外还有其他的课程。所以第一轮迭代时间不是很充足。希望能够在第二次迭代有所改进。
1.3 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们经常在图书馆研讨空间进行讨论，会上大家会将自己的想法提出，每个人对于其他人提出的想法都会认真思考分析并提出自己的建议，大家一起商讨可行性之后，对于计划的是否实施与实施程度进行决策。
在一些关键问题上面，我们采用投票的方式。使得大家的意见可以完整的、无拘束的表述出来。除了开会之外，我们组建了QQ群，如果有组员有什么问题，都可以在QQ群里面提出，老师也在群里面，以方便对于项目决策的快速响应。组员们出现了什么问题，大家也会一同解决，求同存异，一切以项目优先。
1.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在软件开发前期一定要将整个架构做好，团队一定要有明确的美工，否则每个人如果没有做好自己的部分，会严重影响团队的效率。
如果历史重来一遍，那么我们一定会改进上述问题：
首先是明确分工，
选出最适合审美的人来专职美化前端，提供各种素材与修改各种素材；
定义好接口，为每个人提供最适合他的分工，第一轮迭代我们每个人都完成了部分代码，第二轮迭代过程中为整个团队的效率，团队成员应该各司其职，做自己适合的部分，明确自己的职责，不要东做一下西做一下。
———————————————————————————————————————————————————
二、计划
2.1 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我最初的原计划基本完成，因为我们团队经常一起讨论，遇到问题可以及时解决，我们也不拖延，在规定的时间里完成开发。在整个过程中，团队的凝聚力都很强，虽然我们每个人都有很忙的事，但是都把项目这件事看得很重要。
2.2 有没有发现你做了一些事后看来没必要或没多大价值的事?
我们在设计的时候花了太多的时间在撰写文档上，我认为这是浪费了我们很大的时间，虽然文档非常重要，但是作为第一次迭代开发，能够有一个成型的东西才是最重要的。
2.3 是否项目的整个过程都按照计划进行?
项目在整个过程中并没有完全按照计划进行。所以项目虽然整体上跟上步伐，但是细化到每一天，确实不完全按照计划进行。
2.4 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划主要会做以下几个方面的修改：
1.在实际开发中会更加注重接口定义以及模块测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有期末考试，大家的时间会更少，所以应该留够更长的缓冲区。
3.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
2.7我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
总的来说，这次的项目我们学到了很多知识。
如果历史重来一遍，就像我刚才说的，我们会做四件事情：
1.在实际开发中会更加注重接口定义以及模块测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有数据库，编译大作业，大家的时间会更少，所以应该留够更长的缓冲区。
3.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
三、设计/实现
3.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是大家一起完成的。每个部分的设计详情可以参考我们的会议记录。应该说项目一拿到第一时间就是完成设计工作，而且每个模块的设计人员都是对那个模块很感兴趣，最后的设计都是很有意思的。
3.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
项目中有些模块的设计确实碰到过模棱两可的情况，会随着项目的进展进行确定下来。
3.3 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
首先每个模块写完，我们会有一位同学负责（我）代码复审。然后代码汇总后，再一次进行复审。
3.4我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
最初设计的时候并没有很完整把整个框架都设计出来，这也导致了开发过程进行到了一半时各个模块的工作进度没有协调好。接口没有设计好，导致一些功能实现的难度增大。
-------------------------------------------------------------------------------------------
四、总结
4.1你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?
我们正处于第二阶段到第三阶段的过渡状态，目前团队正处于磨合到规范的过渡状态。在前几周的工作之中，我们团队相互磨合，已经较为成功的完成了整个项目的第一次迭代。并且在这之上我们定义了相关的文档，已经将程序部分规范化。大家协同作战，成员们就很多事情取得了一致。
4.2你觉得目前最需要改进的一个方面是什么?
成果可维护性、可移植性不是很高。所以我们下一步会更加的规范这一类的程序、文档。争取在第二次迭代中期进入CMM中第三阶段，使团队状态处于规范阶段。
4.3 什么是在下个阶段要改进的地方? 越具体越好。
这个阶段的不足，以及下个阶段要改进的地方，已经都在上文中列出了。主要的问题如下：
1、正式开发前没有完全定义好接口，使得整合工作难度加大。
2、分工上没有完全利用好团队资源。也是由于经验不足，我们在分工的时候确实对某些模块的工作量和难度有误判，导致有特长的同学的同学反而没有发挥的空间。
最后，愿我们小组在第二轮迭代中，发扬优点，改正缺点，共同进步！