作者：Peter Cheng 来自：Peter Cheng的Blog

没想到在小组成立的第八天才想起来该为这个项目记下点什么，不是开发设计文档，也不是使用手册或者项目进度表，而是为了我自己的一些回忆。这是我领导的第三个软件开发项目，真正意义上的应当是第一个，因为这次是软件工程课程的实践项目，相比而言以前的两个只能算是体验软件开发的一些经历而已。同样的，作为真正意义上的Leader，或者PM（项目经理Project manager），我还是个新手。毕竟，软件工程这门课刚刚开始五个星期，区区十五个学时还不能带给我一些什么，因而我努力阅读了大量的书目去丰富我的知识体系。我希望这个项目能够获得我期待的成功，至少这门课程的结业成绩能够让我满意，仅此而已。当然，如果能积累下宝贵的丰富经验那便是额外的巨大收获。


过去的一周让我充实，我从未如此大量的阅读书籍，在过去的七天中，我翻阅了近十本软件工程相关的书籍，它们大多是经典的和有效的，大约六本我仔细钻研了每一个细节，剩余的我循着前人的笔迹也汲取了足够的精华（这些书大多来自图书馆，感谢那些喜欢在书上乱涂乱画的前辈，是他们给我勾勒出了重点）。很难说我究竟学到了什么，技术上的也许没有，或者思想上的本就可以形式化为技术，那我的收获是丰富的。让我寄予期望最多的是著名的《人月神话》，这个书名让我的许多朋友误以为是小说的东西（事实上，人月指的是工作量，月指month），的确是那样迷人。如果说这本书与其它的书籍有什么区别，那就是：我阅读一般的两百页的书籍能够大约为其中的六七个闪光点而激动得手舞足蹈，而这本书有超过十次让我兴奋地从公交车上跳了起来（我不鼓励大家在公车上阅读，对视力的影响的确很大，尽管这是节省时间的一个有效的方法）。我要说的是，仅此而已，毕竟这是一本几十年前的书籍，尽管在它二十岁生日的时候再版过（这也正是我所阅读的版本），然而它并非是专为软件工程而设，尽管被软件工程领域的专家们奉为圣书。

我的这个小组共有五名成员，很多项目经理不愿意将自己记入到成员数目中，一个典型的说法是：我们小组由我以及另外四名成员构成。这会使得项目经理变得孤立，特别是人人都对上司有天生的反感的情况下，这种现象并不仅仅出现在中国。在上一次的OOP（面向对象项目）中，有三个骨干成员保留到了现在的小组，另外两个中的一个是同样出色的一名成员，也是小组中唯一的女生。最后的一个是一个不折不扣的新兵，是一个还不知道OO为何物的初学者（也许这样说有些自大，似乎我们已经清楚什么是真正的OO一样）。他的加入是一个偶然，纯粹是出于哥们儿义气，这也是大多数学生项目会遇到的问题之一，你不得不去面对一些你并不愿意一同合作的搭档。如何将这样的五个人捏合在一起将成为我们的项目成功的关键。在人面前，技术将变得索然无味，记住这样一个事实，项目管理是面向人的。于是我不得不花去相当多的时间帮助他通过Java来入门，这缘于我对Java的热爱以及Java很可能成为我们的开发语言这一事实（请记住，永远不要做无用功，争取让你现在做的每一件事都可以成为将来迭代的一部分）。

不要以为开会是一个不好的习惯，适当的会议是必要的，甚至是强行要求的，因为它可以让你的项目受益，我们为什么不适当进行会议呢。我的工作就是从第一次会议开始的，一个惊人的举动就是我决定在今后所有的字面文档和口头交流中都使用英文，为此我们进行了尝试，第一个吃螃蟹的人总是弥足珍贵，你的项目中需要有这样一个人，他有足够的能力，并且愿意尝试新鲜事物，不惧怕枪打出头鸟的传统观点。庆幸的，我们有这样一个组员（多使用“我们”而不是“我”，是每个项目经理应当养成的良好习惯）。于是，英文的交流顺利地展开了，尽管大家还有些约束，特别是那个新兵的四级考试还没有通过，着实让我汗颜。然而，轻车熟路之后一切都没有了障碍，单词成为了我们交流使用最多的单位，而不是句子。

第一次会议是轻松的，不要指望能通过这次会议得到些什么，这是一次互相熟悉的会议，彼此需要互相熟悉习性、说话的习惯、喜欢的零食甚至迟到的时间，对于一个项目经理，掌握这些更为重要，我无意重复实践的重要性，实际情况的反馈往往是制定今后计划和策略的基础，也是最直接的来源，然而不幸的是，没有人可以为你收集这些资料，你需要做的是默默记在心里，然后转为今后的行动依据，一些估算往往由此而来。

我们确定了文档的重要性，尽管文档驱动被更多的书籍称作软件开发的黑洞，一些专家认为文档仅仅是官僚主义的作风，当然没有人否认适当的文档是绝对必要的。什么样的文档应当生成呢？你需要将今后可能查阅的资料组织成文档，时刻告诫自己文档是面向未来的，而不是面向过去。单纯的流水账似的总结没有意义，附加上从中获得的经验教训才是这类文档的灵魂。

还有可笑的预算机制，对于学生项目而言，没有明确的所谓客户的概念，没有人会为你的付出买单，所有的开支都是有去无回的，对于许多并不富裕的学生来说任何的开销都倍加重要，请记住，没有一个一天只能吃一顿肉的孩子会为了打印一百页纸而花去四十块钱，他们更宁愿选择手抄。庆幸的，我们的小组成员虽然不能称得上富裕，但至少可以经常在菜盆中发现牛肉的痕迹。我们的预算（budget）机制很简单，也许称之为报销（reimbursement）机制更为合适：每个人先交十块钱给CFO（首席财政管，我们经常为起了这个名字而感到乐趣），也就是当然不让的那个女生，然后项目总结时一并从中报销开支，多退少补。就像许多班级收班费一样，简单的往往是最好的，因为它易于被最多的人接受。会议在轻松的气氛中结束，伴着混沌和锅贴的香味，看来选择食堂作为会议地点是一个不错的决定，因为这里足够嘈杂，不会让大家觉得拘束而不敢说出真实的想法，即使冷场也可以借用咀嚼的声音来打发无聊的时光。一个更现实的原因是，我们找不到其他的地方能同时拥有灯光、场地以及大声说话的权利了，我们没有会议室可用。请记住，这是一个学生项目。

第二次会议在一周之后举行，也就是昨天（还记得吗，我是在小组成立的第八天记录下的这篇文章）。一周以来，我明确了一个思想：项目经理必须和首席架构师分开，哪怕是四五个人的小型项目。这得感谢《人月神话》以及其他的软件项目管理的书籍（他们大多来自于机械工业出版社的软件开发技术丛书系列）。在以前的两个项目中，我都将项目管理和系统开发以及首席编程和测试融为一身，以至于曾经一个组员反问道：你都做完了还要我们干吗啊？的确，明确的分工是必要的，用人不疑，疑人不用。一个成功的项目经理应当懂得如何将工作交给适当的人去完成，而不是独自去完成所有的事。于是，我决定由另一个人来担任首席架构师的角色而不是我自己，这在我看来是一个破天荒的决定（尽管有些可笑），很多人（特别是学生和一些积极性不高的人）都会认为技术最好的人理应当成为项目经理，这也许也是我成为项目经理的原因，然而事实上要记住的是，项目经理是管理人的，而不是管理技术的，他所要做的仅仅是辅助首席架构师完成协调的工作，技术的事还是交给别人去完成吧。

我在图书馆花去了五个小时翻阅了几乎所有关于软件工程方面的国外书籍（不是我对国内的书籍作者有偏见，然而确实国外的教材要优秀的多，当然国内不乏鼎鼎有名的作者和同样鼎鼎有名的著作），从需求分析、设计到质量保证、配置管理，还有CMM，等等一切。我选出了九本书籍作为我们项目的主要参考书目。我为我们的小组设计了五个领导人（感到奇怪吗，我们一共只有五个人而已），分别是需求经理、首席架构师、质量保障经理、测试经理以及项目经理，也就是我自己。九本书的一本是所有人都必须阅读的，另外我为其他每个人选择了相关领域的各两本参考书，我认为它们是可获得的、经典的和有效的参考书，这是我五个小时的全部结晶。在每个阶段或者说每个领域，都会以特定的人为中心，其他人接受他的指派完成任务，这样做的好处是利用有限的人员让每个人能够尽可能多的体验到软件项目的所有阶段，请记住，这是一个学生项目，学习是第一位的。为什么要我亲自去选择参考书，因为我的时间比他们富裕，我免修了本学期的三门其他课程，因而我能够有足够的时间去做这些事情，同时，选择书籍的过程也是自我提升的过程，何乐而不为呢。

终于有人在第二次会议迟到了，直到我们收拾东西准备离场时才出现，后果就是我们已经分完了所有的职位，她没有选择地成为了需求经理。这并不是什么坏差事，然而对于这样的学生项目，没有真正的客户是一个很困难的问题。需求经理需要有强烈的自虐倾向，需要自己扮演客户、最终用户和需求分析师三个角色（如果你还不清楚客户和最终用户的区别，那太糟糕了。客户是出钱的人，用户是实际使用软件的人），这种经历恐怕是绝无仅有的，试想，一个人需要自己不断给自己出难题，然后去解决，太可怕了。那个新兵选择了质量保障经理，因为他认为这是个轻松的职位，不用太多的编写代码，他讨厌程序设计。事实上，我可以想象当他面对一大堆模型的时候他的反应。在软件项目中，如果你认为某一个职位是轻松的，那唯一的原因是你还没有真正理解这个职位的作用。

会议中我最后强调的是，每个人都应当适时地召开会议，并非只有项目经理才有权召开会议，如果必要，任何人都可以这样做。另外，软件项目不是生活的全部，每个人应当将更多的精力放到生活中去，比如陪伴自己的家人，或者处理其他学业，这仅仅是一个项目，是诸多生活元素中的一部分，仅此而已。

一周中我最大的工作是完成了项目计划的草案，这得益于我阅读的几本书籍，当然还有Rational SoDA，这是一个很棒的文档自动化工具，它的文档格式成为了我的设计标准，甚至教会了我许多Microsoft Word的使用技巧，比如自动生成目录。这份草案没有任何实质内容，仅仅是标题性的搭建了框架，所有的内容将在一周之内填充，为什么？因为我们还不知道项目的题目，除此以外的一切都会是徒劳。良好的准备是必要的，在组织任何文档之前都应当先建立模版或者框架，接下来的工作才是用内容去填充框架，而不是线性的编写过程。

也许我还做过许多别的事，然而八天的缘故已经难以一一记录，有一些大概已经在脑海里永远冬眠了，甚至我自己都难以提取形成文字。庆幸的是每个人同样可以获得这些，只要愿意去阅读一些经典的书籍，总能得到。

现在我能做的就是静静等待项目题目的出现，还有学习RUP，三个月之后项目交工之时我大约能够读完软件项目最经典的一百本书籍，这会是我最大的收获和骄傲。我喜欢从阅读中得到满足。

项目正式启动了，因为我们获得了一个导师推荐的题目，这是一个realty system，之所以推荐是因为它和Rational Rose教程中的例子是一样的，因而对于初学者而言有很多可以直接参考的UML模型，事实上，掌握UML是这次课程的重点。然而我们并没有打算做这个题目，因为我们不想依靠太多现成的东西，和更多的组撞车不是一个好主意，更重要的，我们既不能和现有模型太过相似，显然至少不能比它还要差，然而事实是这个模型已经相当完善了，我们没有了发挥的余地。于是在每周例会上，我们决定重新找一个题目。周例会也变成了每周两次，这样做是必要的，因为在开发的前期准备阶段，我们需要很多的时间来达成一些共识作为今后的行动准则，这同样可以营造出良好的讨论氛围和融洽的合作关系，为后面的开发做好铺垫，而这一阶段的文档要求并不高，工作量不大，有足够的时间来讨论。

不知道算不算一个明智的决定，我在题目决定之前就分发了风险组织的任务，因为我相信对于大多数项目而言，大多数的风险是相似的，这种相似包括可能性和影响级别，当然还有风险类别。也许80-20准则是适用的。现在看来这个决定暂时是明智的，因为在这个阶段我们没有太多的事可以做，或者说没有太多需要形成文档的工作。我们需要时刻保持对文档的熟悉，所以安排在这个时候做风险分析是合适的。我给出了一个模版，要求我们每一个人给出至少30条风险，其中至少有10条是和自己的角色相关的（比如测试经理必须给出10条与测试密切相关的风险），这样做一方面可以让各人更加熟悉自己的角色，同时也让各自风险雷同的几率小了很多，我们有更多的机会找到更多的风险。很快地，反馈回来了，这是第一次让我得到满足的反馈，Review Manager负责将这些风险组织起来，去掉雷同的并给出适当的翻译，可能会很奇怪为什么要这样做，我们一再要求所有的文档必须英文化，为什么还要多此一举把它再翻回来呢，因为在这些风险中，很多是来自于一些中文资料，每个人将它们用自己的英语生硬地翻译成英文之后提交了上来，面对那些蹩脚的英文或许翻回中文再阅读比较合适，当然最后还是要重新翻译成英文的。很快地，我们总结出了大约80条风险，去粗取精之后剩下了50条，形成了最终的风险表。不可能也没有必要对所有50条风险都做监督管理计划，我们选择了其中的30条形成各自的RMMM（Risk Mitigation Monitoring and Management，风险缓解、监督和管理计划），每个人负责6条的编写，当然都是和各自的角色密切相关的6条风险，所选择的风险或者发生可能性高同时影响也不低，或者尽管不大可能发生然而一旦发生后果很严重，它们都被列入了风险表并进行管理。同样地，伴随着分发的任务还有一份我制作的RMMM Template，需要说明的是，作为一个学生项目经理，最好能够尽可能多地给出各种文档模版给大家使用，因为我们并不是总有很多现成的模版可以使用，而事实上很多人不是很愿意去寻找模版，所以比起之后再统一格式，一个好的选择就是尽早地分发模版，当然，这要占用项目经理的很多时间。

主题的决定是艰难的，尽管否定了老师的推荐主题，我们仍然没有确定合适的替代者。我的建议是一定要围绕数据库开发，这样的好处是我们可以形成更多地UML图表（主要是类图），这也正是导师的初衷，主动去迎合他不是很好吗。于是，锁定在信息管理领域成为了第一个确定的范围。关于足球转会系统的设想失败了，因为我们的Requirements Manager（也就是那个唯一的女生）对足球不感兴趣，的确，很难想象让这样的角色去做不愿意做的事情，那对项目的损害是灾难性的。另一个提议是学生信息管理系统，或者通俗地讲就是做一个教务处系统，这是被我否决的提议。试想，这样一个系统导师和其他同学太过熟悉了，一旦包含任何的缺陷（这是必然的）很容易就会被发现，对于学生项目这是一个糟糕的主题。最后的选择是酒店管理系统，主要是面向前台的订房系统，这来源于需求经理的强烈兴趣，有时候非原则性的相互妥协是必要的，它可以激发团队的工作热情，更何况这是一个的确很不错的主题，因为它需要一定的专业领域知识，在一个项目中涉及到适当的专业知识可以使得需求范围进一步缩小，需求更加明确，同时可能会有比较多的现有系统来参考。不容忽视的是，并非每个同学和导师都会对这些领域的系统相当熟悉，也就容许了一些缺陷的偷偷存在。

我曾经试图将项目计划中的活动计划分发给每个人去完成，然而几经考虑之后不很合适，因为现在已经有太多的事情要做，为了保持团队的活力（一个重要的原因是我的课比起他们要少得多），我决定独立完成计划，当然这期间每个人仍然有自己的任务要完成，不要让任何一个人闲着，因为这表明对他的不信任和对他能力的低估，每个人都适当忙碌对大家都有益。项目计划也是有现成模版的，感谢Rational SoDA的模版，当然还有我综合各种文献进行的修改，使得文档的结构相当完善，好的结构是进行文档创作的第一步，需要再次强调模版的作用，前人的财富对于初学者总是享用不尽的。在制作项目开发进度的Gantt图（甘特图）时，我采用了Microsoft Project，尽管我不很愿意过多地使用Microsoft的产品（这是因为我是SUN和Java的忠实支持者，而非对Microsoft的技术抱有怀疑），然而最后还是选择了它，因为它太好用了，而且还提供了现成的模版，只需要根据实际情况稍作修改就可以了。尽管已经在计划上花去了太多的时间，然而这是值得的。我在制作Gantt图时耗费了一个下午（这还是在有模版的条件下），然而这一个下午我对项目的整个进程有了把握，明确了什么时候该做什么事，每件事的大概持续时间是多少。我惊奇的发现，风险分析已经和即将花去接近两个星期的时间，以至于我都耻于将这个事实记录在内，要知道，代码开发的计划不过是18天而已。这是个不很合适的比例，事实上两至三天的风险分析就已经足够了，对于学生项目而言可以适当放宽，因为还有其他的作业要完成。庆幸地，我发现代码开发的时间正好包含劳动节假期，这是一个不错的巧合。再次强调计划的重要性，这种重要性只有亲身做过才能体会得到。否则，一个无序的开发管理从一开始就泛滥了。没有完善的计划是项目失败的主要原因之一。

我们观察过几个现有的酒店管理系统，有几个是很不错的，各有特点，我们有了明确的方向和赶超的目标，或许它们就是我们潜在的假想对手。有了参照，我们的需求分析和原型搭建可以容易很多。界面相当重要，然而这不是Java的强项，至少不是AWT和Swing的强项，然而我们并不想贸然使用不熟悉的SWT，新技术的风险超过了获得成功的几率。稳妥和做好业务逻辑应当摆在首位，强大完善的功能同样不容忽视。经验告诉我们导师不会太多在意图形界面的细节，所以不必为了一两个像素的差别花去太多的时间，更多地放在提供足够的功能上，这是相当有分量的筹码。

每个人对我们的系统提供哪些功能有很大的分歧，即使对有几种类型的客户端都争论得不可开交，或许应当需求经理说了算，然而这是一个学生项目，每个人必须对自己开发的系统相当熟悉和满意才会充满热情，不得已的，每个人各自做一份功能计划书，下一次例会进行答辩，这是最民主的方式，也可以让每个人充分熟悉这个系统的功能范围。然后，一切才能继续。下次例会之后，一切都将明朗起来。

这是艰难的一周。一切都遭遇极大的阻力，新鲜感过去之后，后遗症出现了。有人出现了厌战情绪，有人时间紧张分不开身，混乱，成为了这一周的代名词。我有着不可推卸的责任。

我们首先试着确定项目的范围，或者说产品的范围，然而诸多的分歧让这个过程几乎停滞。我没有安排所有人很好的做调研，也没有安排所有人认真地去试用几个现有的系统，每个人都揣着自己的想法来到一起，这样也就罢了，更可怕的是很多人根本没有想法就来到了这里，于是对其他人的意见所能做的只有反驳。看来为了造成不必要的争执和尽快达到共识，事前一定要做好充足的准备。我曾经一度以为这个阶段我没有太多的事要过问，因为这是属于需求分析的阶段，我所要做的仅仅是组织开开会而已，现在看来这是完全错误的。这个阶段是最需要沟通和组织的阶段。一方面这是项目开始不久的阶段，大家的凝聚力还没有到可以脱离组织约束就能成事的阶段，另一方面这个阶段特别需要沟通，因为需求分析是后面所有活动的基础。我们的测试经理的一句话让我很有感悟：如果需求分析我不参加怎么知道我该测试什么东西呀。的确，这个阶段如果任何一个人对任何一个环节有任何的不清晰，哪怕是一丁点的模糊，累计到后面很可能带来的是整个项目的崩溃。

我安排了两个人去独立的完成use-case，然而不幸的是他们参考了同一个系统，做出了几乎一样的use-case，这让我始料未及，于是两个人的努力变得没有任何意义，我的初衷是对他们俩的use-case做一个并，现在不可能了。在分配任务前一定要交代清楚，不仅仅是做什么和大概怎么做，还有做的意义都要解释得很明白才行，这样会减少很多无用功。在我们尝试确定具体的功能性需求时，分歧接踵而至。我们对太多的事情不能达成一致，我们做的是酒店管理系统，可我们中的一部分人根本没有住过酒店，另一些人住得较多所以意见和反响很大，我们难以达成一致。更重要的是下周还有考试，这大概是学生项目最头疼的问题，兼顾学业。我们的进度一拖再拖，幸好一次停课的机会让我们重新坐到了一起。是进度表拯救了我，拯救了我们。我展示了进度表，上面清晰地反映出我们已经落后预定进度三天了，要知道项目仅仅开始半个多月。大家有了清醒的认识，不再苛刻追求功能的完美实现，我们砍掉了大部分的次要功能，将他们作为增量的形式发布，尽管谁都清楚这个增量版本等于是天方夜谭罢了。在不至于牺牲太多质量的前提下，我们达成了一致，功能少了很多，然而我们取得了空前的统一，对功能的需求相当清晰了，甚至一些初步实现方案也有了端倪。一切似乎又步入了正轨。对于学生项目，能够完成才是最重要的，重要的是体会这个开发的过程，产品功能是否强大已经显得不重要了。每个人完成任务的能力我也有所了解，这为我以后任务的分配提供了依据。每个人的能力也能从开始的几个任务中得到体现，事实上，这种体现暴露得越早越好。

然而又一个失败让我沮丧，我没有过多斟酌就布置了估算的任务，我安排大家各自分工根据COCOMO和FA（功能点）对活动分解进行估算，然而后来当一个人已经完成提交的时候向我倾诉，FA根本不适合对于某一特定的活动进行估算，它只适合于整个系统。相似地，COCOMO也不很适合于此。我所建议的两个模型竟都不合适做这方面的事情，我只是想当然的以为这是两个万能模型。然而事情必须做，项目计划文档中还等着每个活动的工作量估算去完成，于是硬着头皮只能根据COCOMO大概给出一个PM值了，然后调整一下“杜撰”出一个最终的工作量来。大家做了很多工作，然而却不知晓使用了错误的模型，又是徒劳的努力，这是我个人彻底的失败。在选择模型时，千万不能草草了事，一定要参阅相关书籍，善于使用经典模型是好的，但一定要弄清楚这个模型在这种情况下适不适用。我做了补救，安排三个人对整个系统做一个基于FA的估算，这是比较正式的估算，因为我们已经有了足够的需求分析，这个结果也将是有意义的。然而一些人对估算不以为然，他们认为这是荒唐的事，一方面我们缺乏经验，另一方面未知的事太多，估算显得似乎没有意义。我明白估算出的绝对值是没有多大意义的，至少对学生项目是。然而相对值是有意义的，至少可以知道在哪些方面我们需要更多的人力来完成，哪些事情可以很快解决，这种对比是必要的，对把握进度是极为重要的。

关于评审，我们初步确定的是对一些关键的大型文档（主要是里程碑性的），做DR（正式设计评审），而对于次要文档至少要做一次inspection（审查）。他们的差别是DR需要大量的支持文档和较长时间的讨论，而inspecion可以相对随便。同时，DR不属于同行评审，也就是说这是上级对下级的审查，而inspecion是同行评审，是同事间的沟通和讨论。当然，我们的DR不大可能邀请到上级，也就是我们的导师。我初步想邀请助教参加我们的DR一到两次，这样一方面我们的DR可以比较正式，另一方面可以争取到更多的映像分，要知道这是学生项目中必须面对的现实。当然，每个组员必须一致同意才可以，否则凝聚力会大大下降。一切都只是策划，对于评审我们实在没有任何经验，书本是唯一的知识来源。

考完试之后，需求分析就要随之结束了，正式的设计即将展开，好戏渐渐上演，后面会发生什么，我很期待，也多了一丝担忧。我能做的，就是准备好充足的文档和模版，组织好会议，做好沟通，分布好任务，剩下的，需要每个人的努力。

先说些额外的话，本来想至少每周能记下一些东西的，现在看来真不一定什么时候有空了，工作一定时间积累些东西能形成两三千字就发上来吧，会议记录真的很管用，有时候我都会忘了过去的几天究竟做过什么事情，看看会议记录全想起来了，要不写这个东西就很困难了。今天看到很多朋友留了言，很多朋友的意见很中肯，几句话就让我受益匪浅，在此一并感谢。要重新说明的是，我记录的这些历程本意是想给今后学习软件工程课程的朋友们一些帮助，经验也好，教训也好，前人留给我很多东西，我也希望能做些什么。当然这一定是一个漏洞百出甚至幼稚至极的项目，可能几个月后我回过头来看自己写的东西也会觉得不好意思，不过这一切都是真实的。前辈们阅读之后请多提意见和建议，我很需要你们大家的帮助。如果大家觉得这些文字太可笑了不屑于发表些什么，那很抱歉我耽误了您的时间，但请不要对我个人进行任何形式的人身攻击，谢谢您。

回归正题。

需求分析算是告一段落了。我们的需求经理付出了很多（一些朋友提到用经理一词不很合适，的确，动不动就经理来经理去的似乎我们在做多大的项目一样，也显得不够谦虚。不过仅仅是称呼而已，我给每个人都安排了一个经理的头衔，包括需求经理、评审经理、测试经理等，这样做一方面可以明确各自的主要任务和角色，另一方面大家心理上也会愉悦很多，毕竟，大家都愿意称呼我为项目经理，如果我称呼每个人组员似乎不大合适，有些盛气凌人的感觉，也叫个经理有个缓和，茶余饭后也是大家的一种消遣，缓解一下气氛的笑料，何乐不为呢）。我结合各种模版做出了一份需求规格书（Software Requirements Specification）。我先是参考了Pressman的建议模版（因为我们用的就是Pressman的教科书–<>，<<软件工程，实践者之路第5版>>），另一方面参考了Sommerville的<>，上面给出了需求规格书内容的许多建议，还有就是飞思科技的<>，这本书很特别，基本上就是各种文档的模版，挺有趣的书，给了我很大帮助。当然还有Rational SoDA自带的一些模版，这个很有参考价值，一方面毕竟是大公司的推荐模版，商业性更强，前面的一些模版学术性可能稍强一些；另一方面毕竟是电子版的，可以直接用了，很方便。我基本上就是按照SoDA的模版结合其它的一些稍作修改形成了最终的模版给了需求经理，她的任务就是完成这个模版，因为完成了这个模版也就相当于做完了需求分析，这个模版的内容太丰富了，包括了足够的use-case信息和功能及非功能规约。参考各种模版也是不得已的和必要的，我们没有任何经验，甚至不知道需求文档中需要出现什么，这样用现成的模版很省事，能学到东西，能把事情做好。

Use-case完成得很快，我本以为又会拖很多时间，没想到三天就交工了（包括完成最重的文档），当然我们前期做了很多准备工作，大家基本筹备的差不多了，只是最后画一个图而已。我仔细看过，除了一些Documentation的语法错误以外，没有大的问题，至少我觉得是的。当然，我们准备以此作为一个训练做一次Inspection，长远的是打算针对系统设计文档做一个FTR（以前称呼它为DR，都是正式技术评审的意思，但似乎FTR用得更普遍一些），准备邀请助教参加的，不能出岔子，于是借用这个机会做一个训练，毕竟Inspection和FTR在流程上差别不是很大，区别主要在于参与者的权限，FTR有上级参与（这不是凭空说的，在Daniel Galin的<>中可以找到原话）。

需求文档其实分为两个部分，一个称之为Software Requirements Specification，它包括了几乎所有的内容，除了use-case图，最后我才发现这个问题，use-case图没地方放了，正好Rational SoDA有一个use-case-model survey模版，专门用于形成use-case图的文档，挺适合的，于是出现了这样两份文档，有些奇怪，现在想想可能不大合适，不过也不打算改了。

风险管理拖到现在才最终完成，主要是RMMM的问题，有几个人没弄清RMMM文档的部分内容的含义，有一个内容是风险跟踪，我的理解就是出现了相关风险情况时就加以记录，可是有几个人撰写的时候就在这儿胡乱填了一些东西，挺奇怪的，可能我没有交代清楚。英文的文档就是这个不好，大家沟通起来不方便，这有点违背了文档的本意。记得一本书上说过，如何避免陷入文档驱动的黑洞中呢，很简单，只制作对未来有益和利于沟通的文档，我觉得可以这么说，文档就是用来沟通的。既然英文文档不利于沟通（至少现在感觉上是的），为什么还要采用，呵呵，学生项目嘛，一个直接目的是获取高分，形式上的东西是必要的，尽管可能不很合适。我也不知道今后的工作中是不是一定要用英文文档，英文究竟占据多大的地位也不清楚，先在做些准备不是什么坏事。

现在Chief Architect开始进行设计了，因为我们赶上了预定进度，时间上宽裕了起来。我很相信他的能力，我想作为组长对组员的态度就是用人不疑。我很清楚为什么我会被推选为组长，因为我的设计和编码能力是最强的，我想大多数学生小组选组长都是这个原则。然而现在我不应该去做这件事情，尽管我很乐意，但这是对他能力的怀疑，是对他的不尊重，更何况他也有很强的实力。越权不是一个好主意。当然，我在交付给他设计文档模版时还是给了一些必要的思路和建议，比如按照MVC的要求设计类，比如底层的RMI机制。另一方面，在评审时我可以将我的意见提出来，有很多方式可以让我自己参与到设计中来，当然，前提是第一个版本一定要让该做的人去做，任何事情都一样。这是对制度的遵守，对人的尊重。

不幸或者有幸的，我现在正式成为了第二个小组的组长，这是一个本体采集小组，与现在的酒店管理系统有很大的区别，当然管理上的区别可能不是很大。之所以这样是因为软件工程的教师正是我今后研究生阶段的意向导师，他有意让跟他的四个人单独出来组个小组做个东西，一方面增加交流，另一方面可以尽早接触今后的研究领域。于是有了这个小组的诞生，我还成为了组长。时间分配可能会更紧张，毕竟两个组都不能出岔子，未来的两个月会很忙。同样的，学习的机会也更多了。第二个组的工作我又要重新开始从计划做起了，呵呵，希望自己能好运。

下一阶段的任务，设计，主要就是完成类图了，其他大的方面大家都心中有数了，就差类图了，然后可以开始编码，大约一周之后吧，五一之后完成编码吧，编码怎么分工我还没考虑好，有能力参与的有四个人，GUI只有我比较熟悉，我们拥有一个数据库专家，称之为专家是因为他的数据库编程经验在我们之中是最丰富的，另外的方面我还不清楚，我不很清楚大家在编码方面究竟有多大的能力和潜力，我不想走一步算一步，可能让每个人自己选择负责的部分是一个好主意吧。说实话，需求做得很详细，功能上还是要实现很多东西的，我不时地想起来，总觉得全部实现有困难，导师说过，这是一个允许失败的项目，我可不想失败。我现在能做的就是先去做一个原型系统，把界面大概勾勒一下，让大家心中有数，然后，我们开始。

忘了强调一下Rational SoDA，这是个很棒的文档自动化工具，可以和Rational其他的组件结合得很好，比如根据Rational Rose的use-case diagram可以自动生成相应的文档，很方便，很值得一试。

这一周是忙碌的。

需求分析基本完成了，use-case图几经修改，我们在绘制use-case之前进行过多次的讨论，试图完全明确所有的功能，然后再绘制use-case，企图一次成功，现在回过头看这个想法太天真了。不过经过充分的讨论，第一版的use-case已经基本符合要求了。大概是我们对use-case认识还不是十分明确，做出来的图比较简单，主要体现在各个用例之间似乎没有多大的联系，当然也可能是这个系统本身太简单的缘故。其实在刚做完use-case时，我们都以为这只是应付老师的一个图表罢了，对于项目过程而言没有多大的帮助作用，我仍然记得绘制图表的原则：只绘制对今后有用的图表。然而后面的分析设计中，这个use-case图却真正成为了我们的工作准则。因为这是一个经过充分讨论的成果，得到了所有人的认可，在后面的分析设计中，碰到过一些有争议的地方，一切符合use-case成为了事实的标准，然而这多少成为了一种约束，当然这种约束可能是有益的和必需的。不得不承认的是，这个use-case终究还是有一些遗漏的功能，然而我们后来在分析设计时发现之后，大家都不愿意再修改use-case了，因为相关的文档已经完成，加上时间紧迫，于是只能去掉那些可要可不要的功能，我们的借口就是：要符合use-case。这样做，我们事实上还是在采用瀑布模型，如果按照迭代的方法，这里是应当对需求分析进行修改的。幸好我们没有真正的客户，否则显然不能这么糊过去。自然的，我们失去了一次训练需求变更的机会，有些遗憾。反思为什么会这样：可能可以归结为时间不足，进一步考虑大概是因为进度表制定的不合理，再进一步考虑原因也许在于系统的范围还是定得太大了一点，使得我们的训练广度是保证了，然而精度不够。看来学生项目出于训练的目的，范围应当尽可能的小，甚至是一个HelloWorld都可以接受，因为项目的目的是尽可能熟悉和掌握软件工程的各个环节，软件本身不用很强大，想起一句话：麻雀虽小，五脏俱全。一个小的软件已经足以训练大部分的内容了。

需求文档也完成得很顺利，有了use-case一切都变得简单。对每一个use-case要做一个specification，也就是对它的一些简要说明、这个功能的输入输出、前置后置条件等等，这费了很大的功夫，犯过许多错误。一个典型的：我们需要将一部分信息组织成一个记录写入数据库，这个功能的输出（outputs）以及目的地（destination）是什么：起初的考虑是输出为信息，目的地是记录。然而后来发现这样似乎是有些荒唐的，因为输入也是信息，难道输入和输出不经修改是一样的，那这个功能还做了什么事情。后来改为了输出为记录，目的地为数据库，这是大家比较容易接受的结果，尽管我们也不很确定究竟怎么才算准确。想起以前和老师讨论一些问题时老师的一句话：当碰到两难时，
选择那种符合大多数人习惯，能让大多数人接受的方案。我想这里是适用的。

之后想起来应当做一份glossary（词汇表，或称为数据词典吧），就是对需求分析中用到的一些词加以解释，这些词可能贯穿于整个开发过程中，有这样一份词典后面看文档的人碰到陌生的用语时有据可查。这份文档做得晚了，我就被一件事情困扰过。我们做需求分析的组员对于“续住”这个功能（还记得我们做的是酒店管理系统吗）用的英文单词是continue，这倒无妨，只是我看文档时对着这个单词琢磨了半天也不能参透这个功能的意义，后来和她交流才知道是续住的意思，试想如果当时就有glossary将省多少事。更可怕的，如果我误解了后果将很严重（其实我起初的理解是由登录窗口进入主窗口，叫做continue，呵呵，幸好和她有一个交流）。

这些工作做完之后，我们认为需求分析的文档就基本成形了，于是我们举行了一次评审，这是一次审查（Inspection），由所有组员参与，评审对象就是需求文档。我们提前两天将文档打印分发给每个人回去浏览准备，一个小插曲是打印和复印的费用花去了我们第一笔集资经费（50元）的一半，让我们吃了一惊，后面要勒紧裤腰带省点用了，毕竟大家都还是学生，花的是自己的伙食费。其实我本来以为这次评审将是失败的，因为大家以前没有过经验，而且这段时间大家都比较忙，可能不会太认真的去阅读文档和找出瑕疵。然而事实让我吃了一惊，每个人都做了充分的准备工作，人均花费了两个小时阅读文档，这已经足够了。我们的评审相当顺利，问题接二连三地被提出来。当然有一点遗憾是评审的时间没有把握好，有点拖沓了，不是因为问题太多，而是花了一些时间在如何解决上。按照各种书籍的观点，评审会议应当着重发现问题而不是解决问题，我们不经意的犯了这个错误。然而这样做是有道理的，因为在完成需求文档时，犯的一些错误多半是对这个问题不理解，而不是不知道该怎么解决，也就是说不是很清楚what，一旦明白了what，那么how可能是比较容易的。所以我们有必要及时指出问题是什么，指出问题的本质，这样长远的看是节省时间的，减少返工的次数。为什么大家会愿意去花宝贵的时间阅读文档和找出瑕疵，我想一个直接的原因是因为打印这些文档的开支比较大，大家都很心疼钱，所以不忍浪费，于是才会认真地阅读文档。挺好的。

起初是我们的“首席架构师”完成系统结构的设计，为了节省时间我们试图同时完成系统架构的设计和模块的细节设计，于是碰到了问题，功能上有点不统一，直接原因是对需求没有做很好的回顾和了解，仍然比较模糊，于是，原型系统发挥作用了。我在拿到需求文档之后，花了一个晚上做了一个原型系统，只有简单的界面，示意一下，这大概也是原型系统的初衷之一吧，原型系统本来是为客户服务的，与客户有一个基本的交流对象。我当时的本意是直接做正式的界面（这个天真的想法是很不合适的，然而我当时相当自信，认为没有问题），而不是做原型系统，后来我们的“评审经理”提醒我说你现在做的应当是一个原型系统，用一下就抛弃的，我才察觉到险些犯了一个巨大的错误。庆幸的，这个系统正好可以被用作原型系统，为我们的分析设计做了很好的铺垫。我们的设计师不是很愿意阅读需求文档，更愿意直接看原型系统来发掘设计思路和要求，幸好这个原型是比较完善的，至少没有遗漏一些功能表示。

然而，第一个设计是失败的，原因之一是对RMI（远程方法调用）没有很好的了解，RMI是这个系统的底层实现，这是我的要求，我的另一个要求是力争符合MVC的标准，或者向着它努力，以它为原则。然而我们的设计师之前没有RMI和MVC的基础知识，就直接进行了设计，显然是不合适的。我们否决之后重新阅读了书籍，建立了第二个架构，模块分得也比较仔细和合适了，基本可以接受，然而整个系统结构显得有些冗余和不清晰，问题出在MVC中的M。我们的理解中，V就是界面，对应于分析类中的boundary方面的内容；C毫无疑问就是主控器了；然而M，都知道是模型Model的意思，起初的思路是寻找系统中的名词，找到之后形成类，也就形成了相应的M。于是，系统中充斥着M。去掉一些不必要的，还是有很多，我隐约的觉得有些不必要。我花了一个下午推翻了重做，建立的设计方案中几乎没有M，或者说实体（Entity）类，这样的方案是简单的：界面发出事件请求，相应的控制器进行响应，然后更新界面并反馈信息，没有实体什么事。这或许不是一个面向对象的系统，因为乍一看找不到对象。然而这样的系统实现起来相当简单和直接，难道是设计的倒退吗，还是或者根本没有弄清楚面向对象的实质。我们的设想是，所有的名词（实体对象）都通过数据库持久性存储起来了，访问或者更改的时候直接查库，然后直接把查询结果以ResultSet（结果集）的形式交给界面去更新就可以了，何必假惺惺的封装起来再给界面，然后界面那边又要解封装，似乎多此一举。我们没有找到这样设计的大缺陷，尽管我们知道这可能是不合适的，比如不利于扩展，不利于代码重用等等。另一个重要的缺陷是，界面部分也要完成一些业务逻辑，比如对结果集信息的提取，这显然是不符合MVC要求的。然而鉴于我们现在的编程水平，易于实现是相当重要的。于是，这个方案被接受了，这是一种妥协，更像是一种失败的妥协，或者说这样的设计更像是一种失败的设计。可能后面还会返工，适当的增加一些M的部分，比如至少不能把ResultSet交给界面吧。呵呵，偶尔想起来太荒唐了。

界面设计方面，仍然存在很大的争议，因为可以参考的系统很多，很难达成一致。这部分工作正在做，我把我的初始意见形成草案分发了出去，大家讨论之后试图在五一前达成一致，因为一旦放假，沟通将变得困难。一个合适的考虑是五一期间基本完成编码，当然前提是大家都对各自要做什么相当清楚，接口的定义要一致和清晰，这部分我们还比较弱，设计还是粗粒度的。我们渴望接下来的几天能够提速，现在也正在提速。尽管我们落后进度将近一周，不过通过加快设计并形成良好的设计方案，我们的编码能够节省很多时间，测试也是一样，大家对按时完成充满了信心。当然，没必要也不可能五个人都参与编码，可能直接编码的只有两三个人，我负责界面，另外一个数据库编程的高手，其他的适时而定，编码方面绝对不是人多了时间就短的，绝对不能用人月除以人数得到月份，我觉得对这样的学生系统，一两个人写代码就足够了。

最后用一句话总结这一周：紧张而充满希望。


五一期间一直在写代码，现在看来是个错误的选择。我本以为尽管是一个训练软件工程的项目，然而把程序完成仍然是十分必要的，甚至是最重要的。如果系统都没能按计划完成，那这个项目谈何成功呢。于是，我们决定利用五一期间的长假完成一些代码，主要是我负责的界面部分。为什么从界面开始，因为之前写过一个原型系统，对这个系统的轮廓已经略知一二；另一方面，更重要的是，我们还没有进行详细的设计。设计只是表面的，比如确定了RMI，确定了门面模式，确定了最简单的单控制器机制等等，然而一个核心是内部的方法、属性都没有具体定义，尽管有些可笑的是完成了数据库的初步设计。一切，都有些荒唐，至少顺序上是的，也许是我个人有些急功近利了，想早点完成这个事情，毕竟我们还有别的课要上，软件工程不是我们本学期的全部。当时的想法是：我写写界面，边写边进行类的设计，然后逐渐明确数据库设计方案，然后列出方法簇给负责数据库的拍档去完成内部逻辑。换句话说，所有的接口都是边写界面边确定的。这样做是完全错误的，本以为可以缩短时间，哪知道在我向其他人解释这些接口的时候费尽周折，以至于我自己都很难描述清楚某个方法究竟是做什么用的。这时我才渐渐明白为什么一定要先确立接口，这是大家共同的语言，有了接口，有了明确的子系统划分，大家可以舒适地并行开发。然而现在，我们的情况更像是流水线开发，我做出一个界面，扔几个方法给数据库那边去完成功能。可事实上我在逐渐往后开发时总是不免的又会修改前面的设计，越改越乱，这才造成了数据库那边的编码困难。核心是什么，核心是分析设计不充分，甚至可以追述到需求的不充分。比如确定一个订单，我们只是简单地提到了要有这个订单，然而订单具体包括哪些项目我们没有明确下来，而是打算留到后面的分析设计去完成。我们之所以敢于这样是因为这是一个学生项目，没有真正的客户，我们甚至可以随心所欲地更改需求，只要可以方便我们实现。于是，为了省事，我们将许多稍显麻烦的工作留到了后面，一次一次往后拖，逐渐的，越发混乱。

现在想来，我们应当在需求阶段就明确界面元素（事实上原型系统应当更加完善），这样我们对所有的事情可以达成统一，不至于在后面找实体类时东挑西拣迟迟不能决定。我们的功能或者说范围定义太过模糊，我们没有确定一个明确的问题陈述（导师的推荐项目题中给了一个明确的Statement作为客户的代理，可以据此进行需求分析）。也就是说，我们还不大清楚这个系统到底应当完成什么，然后，一切却开始了。幸好这个项目美其名曰一个迭代的开发过程，我们可以逐步修改我们的需求分析，直到在问题域和我们的能力之间达到平衡，或者说是妥协。其实现在，因为时间关系我们已经放弃了接近1/3的功能，这个数字可能还会继续扩大，最后可能可以真正实现的部分只是一个很小的子集。导师的话提醒了我们：重要的是把整个流程走一遍，真正做出什么东西来并不重要。

我们显然没有追上预定进度，这完全是因为不恰当的提前进入了编码阶段。不过比起导师制定的一些里程碑底线还是绰绰有余的。我们的评审工作得到了肯定，选用经典文档模版收到了称赞。助教提了一些意见，的确，我们在用例分析时犯了些严重的错误：用例，是面向用户的，能够为用户提供有意义结果的动作序列。我们表示了一个用例叫做数据库管理，然后其他所有的用例都include了这个用例，我们为之得意洋洋。然而，我们忽视了这个数据库管理对于用户而言是不可见的，或许它不适合作为单独的用例出现，尽管它的确是有意义的动作序列。在分析阶段将它提取出来建立一个分析包或许是一个合适的选择。同样的，我们在书写需求规约的Action时，写的太过简单，千篇一律。其实Action或许是需求文档中最重要的一个部分，它就代表了这个动作序列，尽可能的详细对于后面的分析设计是极为有利的，可以避免不一致性。

我们几乎跳过了分析阶段，直接进行的设计和编码，对于小的系统，这样做并非不可行，然而带来的不利后果就是可能会产生不少模糊，对一些概念可能会出现不一致，对需求的理解是不详尽的，不充分的。寻找分析包和分析类本身对于理解这个系统是极为有用的，甚至超过产生的制品。寻找分析类是有趣的过程，我们在后面补分析文档的时候体会到了这一点。其实看着一个个包被提取出来相当有成就感，我们对系统的理解逐步深入，各个模型逐渐细化，随之再进行设计编码一定相当轻松。可惜，我们没有忠实执行这个过程，导致我们的设计过程相当艰辛，最终产生了一个“万能类”Controller，处理几乎所有的功能请求。这是很多书上提到的经典反例（特别是三大巨头写的《统一软件开发过程》），很有趣，这个大反例就出现在我们身上。不过这个系统的确相当简单，似乎没有必要将这个控制器再拆减了。即使设计阶段作了拆减，相信我们实现的时候一定会再把它们合起来。

编码真的成为了最没有意思的事情，绘制UML图是那么有趣，编码显得那么枯燥。其实写代码的成就感来源于解决问题的挑战性，一旦完成了设计，就表明所有的功能都是理论上已经实现了的，这样写代码就成了例行公事，哪里还会有成就感而言。尽管对于如期交付是有益的，不过可以想象程序员的生活有多么枯燥和乏味。说到写代码，其实对于这样的小型系统，两三个人负责就可以了，更多的人参与其中，花在交流和协调上的时间远远超过人员增加带来的速度提升。当然，这与我们对接口的定义不清有关，与我们的编码能力和表达描述能力有关，不过对于学生项目，参与编码的人越少越好。事实上，一个小组中，真正有能力编码的又能有几个人呢。

管理方面有一些新的收获，凡是一定要以身作则，比如迟到这件事，起初我要求大家讨论会不能迟到，然而我自己却迟到了几次，说出的话自然没有说服力了。后来自己来得早了，大家自然也相互配合。很多朋友说一个真正的项目经理，应当学会尊重组员，是请求他们做事，而不是要求他们做事。是的，一方面，大家是朋友、同学，不是也绝没有上下级的关系，大家合作的努力完成这个实践，仅此而已。大家更应当学会享受这个过程，能学会些东西更好，重要的是相互熟悉，相互合作，培养这种精神，培养合作的精神，培养这种努力的意志。毕竟，现在学的东西以后能用到的很难说有多少，然而思想上的是能伴随一辈子的，理念和思路值得花时间去研究。

最近的讨论会越来越少，毕竟，进入编码阶段要讨论的事也没有多少，我们更多的讨论仅仅是聚在一起吃吃夜宵，相互交流一下进度，分配一下后面的任务，仅此而已。似乎一切都变得有些轻松，毕竟，大局已定，距离最后的提交已经很近了，大体已经有了定论，需要提交的文档基本已经完成了雏形，评审之后就可以了，我们即将收工。因为对于系统本身的实现不很关注，我们不会将更多的时间花在上面，这意味着后面我们将没有太多的事情可以做。也许一切就要这样结束了。

我们这个周末会有个聚会，算是大家忙了两个月，轻松一下，大家一块儿唱唱歌吃吃饭，调节一下。如果可能的话，为后面几天的编码和测试工作开个好头，大家都能精力充沛的做好收关工作。其实最近的一个月，因为编码的关系，过得并不开心，没有能享受软件工程带来的快感和愉悦，确实，写代码是枯燥的。我们在饶有兴趣进行了一个多月的新事物尝试之后，好奇心淡了，实质的任务多了。前一个月，我们会为了一次评审而欢呼雀跃，那是多么有意思的一件事；现在，我们为了应付助教参与的一次评审而焦头烂额，准备大量的文档已经成为习惯，每天每个人都在和文档打交道。满脑子的英文使得我们已经无暇顾及别的事情，是该好好休息了。都说战线不能拉得太长，两个月对于初涉这个领域的我们而言，是有些长了，有些单调和乏味。我们总是时常后悔将项目的范围定得这么大，然而一切已经于事无补，我们能做的只有在烂摊子上继续走下去，把这件事做做好，问心无愧就可以了，我们不愿意这个实践是被我们“糊”过去的。

不得不提一下人，人的因素对软件工程有多重要已经无需再提，每个人的能力是有差别的，我想组长在安排任务上应当有些考虑。固然大家争取平分所有的任务，然而不是每个人都能够胜任自己的工作，能力强的理所当然可以接受更多的工作。这不是对他的不公平，这不会招致他的反对，这是对他的一种信任，我想每个强手都会乐于接受挑战。组长对于几乎所有的事情都应当有所过问，干预的程度可以不同，但是一定要准确的知道每个人当前在做什么，未来一周要做什么，没有这个度，项目的进度将相当可怕。有时候，订立截止日期是有道理的。一味的放任可能造成进度的拖沓，适当的严厉和所谓“独裁”可以挽救这个项目，然而如何平息大家的不满就需要自己做功课了。


项目结束于20天前，因为忙于考试，没有能及时记下最后几天的工作。这几天又忙着在实验室充电，几乎忘了这个事情。今天看到一个朋友的提醒才想起来应该有一个像样的负责的总结。

项目算是完成了，连夜加工，写程序的只有两个人，我写界面和定接口，另一个写数据库。我们其实已经做好了放弃的准备，因为我们的需求、分析和设计得到了助教的首肯，相当出色，我们心里面也清楚，这个项目得高分是铁板钉钉的了，代码出不出来已经不很重要。另外，我们通过项目得到训练的目的已经达到，不论是UML还是管理方面的一些基本知识我们都有所涉及和了解，应该说能做成这样大家都很满意。至于系统能不能跑起来，只是锦上添花的概念。这样说可能有些可笑，一个没有软件成品的项目怎么能算得上一个成功的项目？然而我们始终谨记这是一个学生项目，我们要的是尽量多涉及一些方面，多体会一些，而不是刻意的只是为了写代码。当然，我们的分析设计还是相当实用的，尽管不是一个非常有艺术的设计，但我们相信一个实用的设计才是最完美的设计。我们的代码写起来还是很快的，只是因为范围定得太大，我们的时间把握不大好，导致大量的功能被删减。尽管如此，复杂的数据库设计仍然让我的搭档费尽心思。确实，我们系统的业务逻辑太复杂了，很难完美的实现。这给我们提了一个醒，在初期定义范围时，一定要考虑仔细，有时候不仅仅只根据功能点和代码行来估算，一定要注意适当的加权，就是所谓3D功能点（也许是这么称呼的，我已经有所遗忘）。比如说即使一个功能可能估计仅需要几十行代码，但是这几十行可能要写一个晚上，我想凡是写过复杂逻辑的朋友们一定都有所体会。所以在确定功能时一定要谨慎，特别是学生项目，功能能少就少，满足基本需要就可以了，这样可以避免分析设计的时间过于拖沓，而且可能是在做无用功，因为后面这些功能会因为时间不足而被删减。更重要的，一定要记住点到为止的思想，我想这个思想应当贯穿项目始终。

话说回来，三个晚上几乎没合眼，我们两个人完成了所有的基本功能。其实我以前做完一些比较大的东西时，都会很兴奋，然而这次没有，相当平静，因为太累了。而且我发现书上提到的一种观点得到了验证：分析设计阶段做得太详细，会导致编码时程序员没有任何发挥的余地而产生不了成就感。的确是这样，我们在编码时仅仅是例行公事一样，没有什么好设计的了，再加上复杂的逻辑搞得大家精疲力尽，没有一点乐趣可言。我想，这是必然的，尽管对程序员显得不公平，可是对这个项目而言是必要的。毕竟，我们总是假设普通程序员的能力在一个团队中是最低的，那么应当由他们来完成最简单的事情——写代码，而且是依葫芦画瓢似的代码。

我不知道其他搭档从这个项目中学到了什么，我想每个人多少都会有所收获。我所看到的，我自己受益匪浅，因为我所进行的活动对我而言都是创造性的——风险、进度、估算……我之前都没有尝试过，所以我会有很多新的想法出来，会有很多新的体验和收获。我们的“架构师”收获也是巨大的，因为诸多的UML图来自于他，我想这种经验的积累是不可多得的；而且分析设计文档也都是他撰写的，这种经验更是让人倾羡的，我想完成一个50页的英文技术文档那种感觉是无与伦比的。我们的“需求分析师”至少在use-case上有所收获，包括use-case specification。可能另两个搭档收获会少一点。负责数据库的也许是最惨的，他付出了最多的劳动，但大多局限于编写代码；而且同样由他负责的测试工作因为时间的关系没有能按照测试计划正式展开，仅仅是按照我们以往的习惯进行的测试，不得不说是一个遗憾。我真的很渴望能多一个月的时间，这样我们的各项工作都会更加完善一些。

一些补充的：风险管理方面成为了最大的鸡肋，因为我们没有时间去维护RMMM；提交文档都用的PDF格式，可能更加正式一些，也更“时髦”一些；很多东西是可以作假的，比如评审工作，即使不进行评审也可以作出像样的文档，但是并不推荐这么做，因为评审实在是一个非常有意思又有意义的体验；尝试相信每个人，因为除了相信别无选择，永远不要怀疑你的搭档的能力，只要你可以恰当的安排工作，他们总能完成得很好，适当的多安排一点是残忍而可行的，除非他们主动拒绝；和气和团结是成功的根本。


最大的收获：项目计划在我看来是学生项目中最重要的一份文档

最大的教训：软件范围的定义一定要小，能小就小，因为你不会所有的时间都用来开发，要注意到超过一半的时间是在写文档、评审、绘图……为什么要这样？为了保证质量

最大的遗憾：测试工作做得不好，没有合理的规划test case，也没有按照规范来测试

最意外的满意：评审工作太有趣了，大家聚在一起讨论感觉很好，而且很有效


我们最后一块儿吃了顿饭，唱唱歌，作为庆祝

我的软件工程最后得分是：96分。原因：我的笔试成绩很不错，同时助教告诉我，我们的项目是最出色的

The End

（原文链接）