一，设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
①解决的问题：我们的软件是一款基于联邦型知识图谱的关键词搜索引擎。目前，联邦RDF 系统由许多自治的SPARQL 端点组成，SPARQL 端点只提供查询接口而用户不能通过此接口远程下载数据集来建立全局倒排索引，因此，关键字检索难度很大。我们基于一种在联邦RDF 系统上进行关键字搜索的方法，通过SPARQL 端点上下文检索把关键字映射到子图结构中，然后通过子图生成SPARQL 查询来查询Endpoints 上的数据集，而不需要在不同SPARQL Endpoints 上建立全局倒排索引。为了提高查询性能，我们设计了多重查询优化策略来重写查询语句，广泛的实验证明我们的技术还是有效的。
②典型用户及典型场景：我们这个项目定位不属于商业应用型项目，而是一个算法研究型项目，所以典型用户不是我们这些日常的搜索引擎的使用者，而是专门的程序员或者RDF技术研究者，典型场景也偏向于研究而不是商业应用，更倾向于为专门的研究者服务，为算法研究提供前端界面并保存下大量中间结果及查询日志以方便研究者进一步改进算法。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们基本达到了第一次迭代的计划于目标，我们原计划的功能包括要实现用户登录，注册，邮箱激活，权限管理，搜索算法实现，结果展示等六大功能，最终我们按照进度如期完成了原计划的迭代。但是在页面美化尤其是结果页的处理上还需要在第二次迭代时进一步优化。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
与之前一阶段相比，我们团队的工程质量提高了很多包括
①软件架构层面的优化：我们组之前的代码基本没有思考软件架构的优化，所以前后端混在一起，所有事物基本都使用代码实现，并且每次数据操作均需要频繁开关连接，所以代码拓展性和可维护性极差，但是现在我们组将前端，数据库，业务逻辑完全剥离，并且使用了很多配置文件来避免“硬编码”，还使用了连接池来专门管理连接，整个工程分为了若干模块，代码拓展性和可维护性都大大提高。
②代码的复用性的改良：我们组之前在写代码时很多函数直接写死了而且数据粒度比较大使得代码复用性比较差，在这次迭代中我们注意了这个问题，一些函数采用了接口的形式，并且降低了很多函数的数据粒度来增强代码的复用性。
③编码习惯的改良：我们组之前的代码在变量命名上比较随意并且基本不注释，所以代码可读性比较差，经过了一个阶段的修正我们组现在在编码时就比较注意变量命名规范性以及增加必要的注释。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量及用户的接受程度基本符合预期，因为目前我们的系统是一个研究型项目，面向的主要是专门的代码研究人员，用来方便他们的算法研究所以与不懂电脑的普通人相比，我们的用户作为比较专业的程序员对于我们的系统比较容易上手。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
对于典型用户与典型场景一定要明确清晰，如果重来我们会发扬这次的经验，在项目开始时尽快确定项目的用户及场景。
二，计划
1. 是否有充足的时间来做计划?
我们组比较严格地按照边老师的要求，在每周日晚会讨论决定小组的周计划，之后个人再根据小组进度安排自己的周计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们组在计划阶段小组内部确实产生了很多不同意见，我们是先一起评估一下争议点的工程量及我们的能力最后讨论确定最终的计划的。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
第一次迭代的原计划的工作基本都完成了，关于页面美化尤其是结果页的处理上还需要在第二次迭代时进一步优化。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有很多，比如一些其他架构的探索以及使用socket通信时一开始采用了txt文件来过渡等等，不过感觉这些虽然最后没有使用在最终的工程里但是对于技术探索还是有益的。
5. 是否每一项任务都有清楚定义和衡量的交付件?
我们组在需求文档和第一次迭代开发文档里对每一项任务都有清楚定义和衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目整个过程基本是按照计划进行，当然中途也出现了些意外，在验收前五天时项目组的服务器意外宕机了，导致当时项目组进度被停滞，这一点是之前没考虑到的，主要是想之前没有提前思考硬件故障的问题（尤其是腾讯这种大厂竟然说出问题也出问题。。。）
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
这次我们制作计划时没有留下缓冲区，导致最后几天频繁刷夜（整个周末感觉比高三时还拼╥﹏╥...），缓冲区可以为一些意外事件提前留出解决的时间。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来计划我们一定要提前考虑到各种意外出现的可能性，留足缓冲区时间，避免最后几天刷夜（实在肝不起了）
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在计划中要留下缓冲区，如果重来一遍我们会提前考虑到各种意外出现的可能性，留足缓冲区时间
三，资源
1. 我们有足够的资源来完成各项任务么?
①硬件方面我们组有自己的一台服务器和老师的一台服务器基本满足需求
②软件方面我们组均为一个专业的，空闲时间比较集中，编程能力上大家自学能力也都比较强，所以基本可以完成任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们组是根据任务的工程量，要做到的精细程度和我们自身的编码能力来评估所需时间和资源的，精度比较准确。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
前期估计比较准确，所以在测试阶段资源基本足够，对于不需要编程的资源比如文案及UML图等我们小组都是一起解决的，所以并没有低估难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
基本没有过，小组分工还算合理，我比较擅长数据库及前后端联系，软件架构层面，最终分配任务也是承担的这方面的任务。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
尽管小组分工比较合理，但还是不够细化，小组开发时还是很多时候出现了交叉甚至每个人慢慢地都快变成了“全栈工程师”，当然这主要是因为我们还是在一些基础技术上掌握得不是很熟练，很多技术架构都是直接现学现用导致很容易碰到问题所以小组只能是每个人每个地方都会些，一个人出现问题了可能全组人一起帮助解决。如果重来一遍，一个team还是要尽量避免这种交叉编程的。
四，变更管理
1. 每个相关的员工都及时知道了变更的消息?
项目组有专门的群用来讨论以及变更的通知。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们组一般会根据任务的工程量，功能是否是核心功能以及我们自身的编码能力先讨论决定“推迟”和“必须实现”的功能，当然如果意见迟迟不能统一就投票决定或是向指导老师请教。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们组在需求文档及项目原型中对项目的出口条件进行了清晰的定义。
4. 对于可能的变更是否能制定应急计划?
我们组没有在项目开始时事先制定应急计划，但这次迭代中发生变更时我们组都会抽时间一起讨论来快速制定应急计划。
5. 员工是否能够有效地处理意料之外的工作请求？
我们会进行动态的任务分配，一些意料之外的任务可能会动态的分配给一些编程能力较强的人。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了 对于项目的出口条件，应急计划等一定要提前计划好，如果重来一遍，我们会在项目开始时事先制定下大概的应急计划。
五，设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们的设计工作是第七周左右开始的，并且采取了全组一起完成的方式（全组均为开发人员），时间节点上比较合理，人员分配基本合理。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
团队一般会讨论最后表决确定最终的设计
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
①我们组使用了starUML来制作UML图以及powerdesigner来制作数据库的E-R图，可能我们的工程与真实企业项目还是有差距，这些工具有作用可以帮助我们明晰需求及项目设计但用处不是非常大
②因为项目需求文档最后进行了一定的修改，项目开始的 UML 文档也进行了相应的更新
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
搜索这个核心功能bug最多，因为它牵涉核心算法，数据库操作与socket通信等多个模块，在发布前进行了大量测试发现了数据库连接空指针报错，连接服务器超时，socket通信空指针错误等多个bug但都在发布前解决了。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码审查我们是依据边老师之前发的阿里编程规范文档中的要求结合网上一些案例进行的，整体上比较严格地执行了代码规范。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了很多，包括各种工具的使用以及编码规范等，如果重来一遍，我们会在迭代时学习使用单元测试等工具及github或工蜂等代码托管平台的使用来避免我们串联工程时一遍遍地import工程。
六，测试/发布
1. 团队是否有一个测试计划？为什么没有？
项目最后事先留了一整天来进行各子模块及整个工程的测试。
2. 是否进行了正式的验收测试？
项目进行了正式的验收测试
3. 团队是否有测试工具来帮助测试？
这次团队没有使用专门的测试工具来帮助测试
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队是交叉测量对方负责模块的效能的，这些测试工作帮助我们找到了很多bug使我们在发布前解决了软件的bug
5. 在发布的过程中发现了哪些意外问题？
在发布前进行了大量测试发现了数据库连接空指针报错，连接服务器超时，socket通信空指针错误等多个bug但都在发布前解决了。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学会了要提前留出测试的时间并做好测试的计划，如果重来一遍，我们还会学习下专门的测试工具来帮助测试。
七，团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队是根据成员的编程能力来确定角色的，基本算是人尽其才，但分工可以进一步细化
2. 团队成员之间有互相帮助么？
团队采取了先个人编程搭好框架，再团队一起编程遇到问题一起解决的方式（图书馆二楼基本快被软工16级占没了。。）
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
小组一般会讨论最后表决确定最终的设计
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学会了什么才是一个team（话说最后一个周末还是第一次五个人从早到晚连吃饭都在一起连续待了两天半）如果历史重来，我们会进一步细化分工，避免小组成员全变成“全栈工程师”的趋势。
八，总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
嗯，觉得大体在第二等级到第三等级上（我们没第一等级辣么差，嗯，也没第四第五等级那么好）
2.你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
团队合作的话处于规范这一阶段（嗯，谦虚点）
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
①软件架构层面的优化：我们组之前的代码基本没有思考软件架构的优化，所以前后端混在一起，所有事物基本都使用代码实现，并且每次数据操作均需要频繁开关连接，所以代码拓展性和可维护性极差，但是现在我们组将前端，数据库，业务逻辑完全剥离，并且使用了很多配置文件来避免“硬编码”，还使用了连接池来专门管理连接，整个工程分为了若干模块，代码拓展性和可维护性都大大提高。
②代码的复用性的改良：我们组之前在写代码时很多函数直接写死了而且数据粒度比较大使得代码复用性比较差，在这次迭代中我们注意了这个问题，一些函数采用了接口的形式，并且降低了很多函数的数据粒度来增强代码的复用性。
③编码习惯的改良：我们组之前的代码在变量命名上比较随意并且基本不注释，所以代码可读性比较差，经过了一个阶段的修正我们组现在在编码时就比较注意变量命名规范性以及增加必要的注释。
4.你觉得目前最需要改进的一个方面是什么?
具体设计上结果页的处理及美化是当前最需要改进的
最后希望我们的第二次迭代也能圆满结束，否则都对不起我们组的咖啡钱和夜晚里掉落的头发（ヾ(´∀`o)+）