第六周作业
软件过程日志（2016.3.28-2016.4.9）
本日志记录了我们小组近两周的活动。我们小组本时间段的主要任务是学习项目所需要的新知识、进行小组内部的再次分组、修改已有的文档、撰写设计说明书以及第一版产品的编码。由于前一周周末正值清明假期，所以文档的预定完成日期推迟到了后一周，该两周的任务安排不便分割。以下是我们在这两周的一些工作记录与成果以及我的体会。
小组工作记录
- 2016.3.28-3.30 自行学习项目所需要的新知识。
- 2016.3.31 小组第二次正式会议，讨论团队内分组以及技术细节。
- 2016.4.1-4.4 继续学习有关知识，撰写设计文档。
- 2015.4.5 完成概要设计第一版
- 2015.4.6-4.9 进行详细设计的撰写及软件编码
个人心得
在本周的项目中，我有如下几点心得体会以及想说的地方：
关于项目进度
我们小组当前的工作进度并没有符合当初的规划，主要体现在详细设计说明书的延期。我认为主要原因是我们忽视了实际情况，制定计划有些不太合理。
当时制定任务的时间表时考虑的原因：
- 立项时我们选定了增量开发模型，我认为至少应当完成两次的迭代，这意味着我们的项目进度必须很快，如果制定的计划还要往后拖的话就无法完成两次迭代了，所以指定一个这样紧的计划表是迫不得已的。
- 由于这段时间有一个清明节的假期，所以应该有充足的时间来完成设计文档的攥写。
然而实际情况是：我们没有人之前写过这方面的程序，不写出代码，面对设计文档根本无法下手。这导致设计文档，特别是详细设计的延期。我想很多人都有这样的体会，不写出代码，我怎么知道接口怎么设计，流程图长什么样，变量怎么设计。实际上也有很多人是先写出代码再补文档，不然文档就只能拍脑袋。指定计划的时候，我们能按照课本上灌输给我们的概念，先立项，分析需求，设计，再编码，测试，而完全忽视实际的情况。我目前同意工业上应该先写文档，再按照文档写代码，而不是按照自己的想法只顾着编码，这样才能做出大型的软件。然而，我们还不是专业的工程师，我们的经验很缺乏，还不能做到看到需求就可以设计出可行的产品，我们只能实践出真知，所以我们决定将详细设计的截止时间推迟到周末，边尝试编码边进行详细设计的编写，并且不推迟后续的流程。我们决定这样虽然可能有悖于软件工程的流程，但是基于实际的情况，这是我能想到的能够保证按时按质按量完成整个项目，不拍脑袋写出文档的最好的方法。
关于“拍脑袋”
上面那个项目进度的事件也可以说是拍脑袋的后果。我承认拍脑袋不好，但是目前只有这样。我知道可以用科学的方法对时间进行估算，比如LOC/FP估算，基于过程的估算，但是感受到自己并不能在实践中进行应用，我并不知道知道我们的项目有多少LOC，我不知道我们项目组的成员每天能写多少代码，我不知道每个过程要多大工作量，也只能接着拍。或许我们可以上网查下这个项目要多少行代码，要多少人写多少天，但是，别人的数据是别人的，别人一行写完的东西我们可能要写100行，别人速度也不能代表我们的速度。我们总不能先写点其它东西看下我们的速度吧，或者派个人先把项目写完吧，这样就知道有多少行了……我们经验不足，我们比不上专业人士，凭我们的经验弄出来的估计可能连数量级都不对；我们精力不足，我们也不是只有一门课程，可以投入无限的精力到这一门课程上，这样做只会影响别的课程的学习，甚至是毕业考研应聘等，我想这也不是老师愿意看到的。课本上说软件工程与计算机科学与技术的区别是会对各方面的实际情况的各种折中，我们所谓的“拍脑袋”的结果也是我们向有限的能力与精力进行折中考虑的结果。希望老师能够理解。