设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    我们的软件的作用是帮助用户实现准确快速的电子文档查重，我们对软件的定义是电子文档查重系统，即通过文档对比，统计文档内容的重复率的软件系统。软件的典型用户是大学教师，典型场景是老师对学生提交的论文进行方便快速准确的查重。

2. 我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

原计划做三个功能，全都做了；按照原计划交付的时间按时交付了；但原计划的用户数量没有达到，几乎没人用。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？有什么经验教训? 

因为之前做过用户需求调研，所以对用户的需求有一定的了解，我们一开始就是按照用户的需求做的，因此用户对重要的工能的接受程度跟我们预想的一样，我们离目标也更近了一步。

 计划

     1.是否有充足的时间来做计划? 

        有，整个软件的基本开发较快完成。

     2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

        对于计划的不同意见，我们是进行集体协商的，从中选择一个方法进行表决。

     3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

        原计划的工作几乎做完了，只差一些细微的改良，这是由于要应对老师的要求。

     4.有没有发现你做了一些事后看来没必要或没多大价值的事?

         没有，因为软件整体按需求和老师要求精简改良了。

     5.是否每一项任务都有清楚定义和衡量的交付件?

         没有每一项，因为软件只有一个查重算法，也是最核心的一个功能，所以对这一部分代码的编写至关重要，软件作为一个整体进行交付。

      6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

         项目的整个过程开发还算顺利，做的是pc端的程序，没有什么大风险，只是还要对老师的一些小要求进行改善。

      7.在计划中有没有留下缓冲区，缓冲区有作用么?

         没有留下缓冲区。

      8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

         大体上不会再有修改，软件已经成型，已经可以使用。

资源

1.我们有足够的资源来完成各项任务么?

我们是使用java语言来编程的，由于团队里成员此前都有学习过java，也都有过使用java编程的经验，所以在整个软件开发的过程中，程序编程，界面设计的资源还是很充足的。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

我们是将软件所需的要求划分成多个任务，每天都大致完成几个任务，精度是计算到每天。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 

·各项功能的测试时间相对充足，团队的每个队员完成一个模块后，都会进行简单的测试，最后整合进行总测试，减少出错率。

·人力和软件/硬件资源十分充足，我们是六个人的小组，每个人都各司其职，努力完成自己的模块，也会对别的队员提供自己的想法和帮助。

·美工设计我们确实有所低估，功能全部完成的前提下，软件整体的界面使用都不算特别美观。

·文案通常是我们组长来进行任务分配，每个人完成一个部分，再由一人总结，一般是人人都有参与。

 你有没有感到你做的事情可以让别人来做（更有效率）?

·王若凡：我所负责的工作之一就是项目管理和任务分配，将整个软件分成多个任务，根据组员自身的情况再来分配，这个需要对每个人的自身情况都要有了解，这个任务花时间是了解我觉得可以让别的组员来完成。

·许明涛：我主要是完成查重程序的算法一块看，界面一块也有涉及到。在查重算法上我们查阅了很多资料最后选择了余弦算法这一算法去实现查重功能，在算法上我是和另一个组员一同完成的，我的任务我觉得可以交由另一个组员去完成，但是单独一人除非是有很强的能力，效率实在太低了

·吕志哲：我是负责软件最后的测试以及需求分析说明书的制定，我觉得我做的还没达到我的理想指标，交由别的更细心的队友可能会有更好的效果。

·欧阳勇：我主要是负责界面这一块的，这块内容的编程我还是比较熟悉的，团队里每个人多多少少都有掌握好java，但我自认为还是比较擅长。

·卢少锐：我的任务在测试跟界面制作上都有涉及到，在参与开发的同时也参与了软件测试，这对测试的效率提高挺有帮助的，测试也可以交由其他有参与开发的人来完成，效率应该不差。

·刘存：我是负责开发者文件那一块的代码，在开发的过程中有碰到一下小问题，经过团队互帮互助都成功解决了，但我觉得我做的还不够，可能交由他人来做会更有效率吧。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

每个任务都会让人学习到很多，如果还重来一次，我们会重新分配任务，让组员去尝试不一样的任务，让人学习到不同的东西。

变更管理

1. 每个相关的员工都及时知道了变更的消息?

   成员都在一个班级，就隔壁宿舍而已，天天见面，而且现在有各种消息传递方式如qq群，所以变更消息能够及时知道。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

  首先判断这个功能的重要性，重要级别高就优先，其次看它的实现难度，如果成员们都解决不了就暂时推迟。对于重要功能就肯定是要实现，附加的额外功能若实现不了就可以选择放弃。

3.项目的出口条件（Exit Criteria）是否得到清晰的定义?

   对于我们来说，项目出口条件就是程序满足规定的要求，并且运行无误，没有bug，体验感好。

4. 对于可能的变更是否能制定应急计划?

   算是没有吧，一开始就将计划制定好了，将任务分配到个人，而出现变更就是看属于哪个任务由负责人解决。

5. 员工是否能够有效地处理意料之外的工作请求？

   对于该完成的功能成员们都有效处理了，对于一些难度太大无法解决的就只能放弃处理了。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

. 对于算法选择刚开始大家意见不同，不知道该选择哪种算法进行查重，所以最早选择使用三种算法供使用者选择，最后在 老师的建议下只选择了余弦算法。

. 对于页面设计，有人建议简洁的好，有人望越高端越好，但是实现是有难度的，所以最后决定选取简单的，然后能进行一些美化就好了。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

团队没有单元测试，由于大家都对测试比较陌生，基本没有使用过，所以此次就以完成代码为主要任务并没有想到去测试，而且都没有这个习惯。

 4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

导入文件功能：

 Bug1：导入按钮第一次使用面需要点击两次才能生效

原因：目前没有找到原因，三个按钮只有一个出现这种问题。

Bug2：导入文件时，零导入后，查重按钮可以执行，不过最后结果因为是空的，所以不能生成结果

原因:点击导入文件时 导入按钮事件响应后，之后的按钮也就收到反馈，但最后并没有数据进行处理。

发布后发现的问题：

Bug3：不能读取docx文件

原因：应该是导入的jar包不支持docx的word文档。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

大家在完成自己的代码时就完成多少就先审核多少，最后汇总大家互相查看代码，看有没有自己审核时没发现的问题，当局者迷，旁观者清。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

加深对项目的认识，并且争取更好的配合，此次合作中发现分工大家一起完成一个工作时，真的比较轻松与愉快。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

我们对测试有一个粗略的计划，按照计划去实施，是我们的测试有条不紊的进行。

2. 是否进行了正式的验收测试？

我们还没进行验收测试，之后还有一个阶段的时间去完善我们的程序。

3. 团队是否有测试工具来帮助测试？

没有

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们是一个查重的软件，衡量效能的标准是一次性导入文件的数量与查重时间的比值作为一个度量值，绘制表格，然后人工分析代码效率。相对低效。

5. 在发布的过程中发现了哪些意外问题？

在发布实施是跨电脑运行，32位系统和64位系统需要分系统使用

 b. 全组讨论的照片。

团队成员在Alpha阶段的角色和具体贡献：

团队作业7——Alpha冲刺之事后诸葛亮