项目结束于20天前，因为忙于考试，没有能及时记下最后几天的工作。这几天又忙着在实验室充电，几乎忘了这个事情。今天看到一个朋友的提醒才想起来应该有一个像样的负责的总结。
项目算是完成了，连夜加工，写程序的只有两个人，我写界面和定接口，另一个写数据库。我们其实已经做好了放弃的准备，因为我们的需求、分析和设计得到了助教的首肯，相当出色，我们心里面也清楚，这个项目得高分是铁板钉钉的了，代码出不出来已经不很重要。另外，我们通过项目得到训练的目的已经达到，不论是UML还是管理方面的一些基本知识我们都有所涉及和了解，应该说能做成这样大家都很满意。至于系统能不能跑起来，只是锦上添花的概念。这样说可能有些可笑，一个没有软件成品的项目怎么能算得上一个成功的项目？然而我们始终谨记这是一个学生项目，我们要的是尽量多涉及一些方面，多体会一些，而不是刻意的只是为了写代码。当然，我们的分析设计还是相当实用的，尽管不是一个非常有艺术的设计，但我们相信一个实用的设计才是最完美的设计。我们的代码写起来还是很快的，只是因为范围定得太大，我们的时间把握不大好，导致大量的功能被删减。尽管如此，复杂的数据库设计仍然让我的搭档费尽心思。确实，我们系统的业务逻辑太复杂了，很难完美的实现。这给我们提了一个醒，在初期定义范围时，一定要考虑仔细，有时候不仅仅只根据功能点和代码行来估算，一定要注意适当的加权，就是所谓3D功能点（也许是这么称呼的，我已经有所遗忘）。比如说即使一个功能可能估计仅需要几十行代码，但是这几十行可能要写一个晚上，我想凡是写过复杂逻辑的朋友们一定都有所体会。所以在确定功能时一定要谨慎，特别是学生项目，功能能少就少，满足基本需要就可以了，这样可以避免分析设计的时间过于拖沓，而且可能是在做无用功，因为后面这些功能会因为时间不足而被删减。更重要的，一定要记住点到为止的思想，我想这个思想应当贯穿项目始终。
话说回来，三个晚上几乎没合眼，我们两个人完成了所有的基本功能。其实我以前做完一些比较大的东西时，都会很兴奋，然而这次没有，相当平静，因为太累了。而且我发现书上提到的一种观点得到了验证：分析设计阶段做得太详细，会导致编码时程序员没有任何发挥的余地而产生不了成就感。的确是这样，我们在编码时仅仅是例行公事一样，没有什么好设计的了，再加上复杂的逻辑搞得大家精疲力尽，没有一点乐趣可言。我想，这是必然的，尽管对程序员显得不公平，可是对这个项目而言是必要的。毕竟，我们总是假设普通程序员的能力在一个团队中是最低的，那么应当由他们来完成最简单的事情——写代码，而且是依葫芦画瓢似的代码。
我不知道其他搭档从这个项目中学到了什么，我想每个人多少都会有所收获。我所看到的，我自己受益匪浅，因为我所进行的活动对我而言都是创造性的——风险、进度、估算……我之前都没有尝试过，所以我会有很多新的想法出来，会有很多新的体验和收获。我们的“架构师”收获也是巨大的，因为诸多的UML图来自于他，我想这种经验的积累是不可多得的；而且分析设计文档也都是他撰写的，这种经验更是让人倾羡的，我想完成一个50页的英文技术文档那种感觉是无与伦比的。我们的“需求分析师”至少在use-case上有所收获，包括use-case specification。可能另两个搭档收获会少一点。负责数据库的也许是最惨的，他付出了最多的劳动，但大多局限于编写代码；而且同样由他负责的测试工作因为时间的关系没有能按照测试计划正式展开，仅仅是按照我们以往的习惯进行的测试，不得不说是一个遗憾。我真的很渴望能多一个月的时间，这样我们的各项工作都会更加完善一些。
一些补充的：风险管理方面成为了最大的鸡肋，因为我们没有时间去维护RMMM；提交文档都用的PDF格式，可能更加正式一些，也更“时髦”一些；很多东西是可以作假的，比如评审工作，即使不进行评审也可以作出像样的文档，但是并不推荐这么做，因为评审实在是一个非常有意思又有意义的体验；尝试相信每个人，因为除了相信别无选择，永远不要怀疑你的搭档的能力，只要你可以恰当的安排工作，他们总能完成得很好，适当的多安排一点是残忍而可行的，除非他们主动拒绝；和气和团结是成功的根本。
最大的收获：项目计划在我看来是学生项目中最重要的一份文档
最大的教训：软件范围的定义一定要小，能小就小，因为你不会所有的时间都用来开发，要注意到超过一半的时间是在写文档、评审、绘图……为什么要这样？为了保证质量
最大的遗憾：测试工作做得不好，没有合理的规划test case，也没有按照规范来测试
最意外的满意：评审工作太有趣了，大家聚在一起讨论感觉很好，而且很有效
我们最后一块儿吃了顿饭，唱唱歌，作为庆祝
我的软件工程最后得分是：96分。原因：我的笔试成绩很不错，同时助教告诉我，我们的项目是最出色的
The End
