先说些额外的话，本来想至少每周能记下一些东西的，现在看来真不一定什么时候有空了，工作一定时间积累些东西能形成两三千字就发上来吧，会议记录真的很管用，有时候我都会忘了过去的几天究竟做过什么事情，看看会议记录全想起来了，要不写这个东西就很困难了。今天看到很多朋友留了言，很多朋友的意见很中肯，几句话就让我受益匪浅，在此一并感谢。要重新说明的是，我记录的这些历程本意是想给今后学习软件工程课程的朋友们一些帮助，经验也好，教训也好，前人留给我很多东西，我也希望能做些什么。当然这一定是一个漏洞百出甚至幼稚至极的项目，可能几个月后我回过头来看自己写的东西也会觉得不好意思，不过这一切都是真实的。前辈们阅读之后请多提意见和建议，我很需要你们大家的帮助。如果大家觉得这些文字太可笑了不屑于发表些什么，那很抱歉我耽误了您的时间，但请不要对我个人进行任何形式的人身攻击，谢谢您。
回归正题。
需求分析算是告一段落了。我们的需求经理付出了很多（一些朋友提到用经理一词不很合适，的确，动不动就经理来经理去的似乎我们在做多大的项目一样，也显得不够谦虚。不过仅仅是称呼而已，我给每个人都安排了一个经理的头衔，包括需求经理、评审经理、测试经理等，这样做一方面可以明确各自的主要任务和角色，另一方面大家心理上也会愉悦很多，毕竟，大家都愿意称呼我为项目经理，如果我称呼每个人组员似乎不大合适，有些盛气凌人的感觉，也叫个经理有个缓和，茶余饭后也是大家的一种消遣，缓解一下气氛的笑料，何乐不为呢）。我结合各种模版做出了一份需求规格书（Software Requirements Specification）。我先是参考了Pressman的建议模版（因为我们用的就是Pressman的教科书--<<Software Engineering, a practitioner's approach, fifth edition>>，<<软件工程，实践者之路第5版>>），另一方面参考了Sommerville的<<Software Engineering, seventh edition>>，上面给出了需求规格书内容的许多建议，还有就是飞思科技的<<CMMI3级软件过程改进方法与规范>>，这本书很特别，基本上就是各种文档的模版，挺有趣的书，给了我很大帮助。当然还有Rational SoDA自带的一些模版，这个很有参考价值，一方面毕竟是大公司的推荐模版，商业性更强，前面的一些模版学术性可能稍强一些；另一方面毕竟是电子版的，可以直接用了，很方便。我基本上就是按照SoDA的模版结合其它的一些稍作修改形成了最终的模版给了需求经理，她的任务就是完成这个模版，因为完成了这个模版也就相当于做完了需求分析，这个模版的内容太丰富了，包括了足够的use-case信息和功能及非功能规约。参考各种模版也是不得已的和必要的，我们没有任何经验，甚至不知道需求文档中需要出现什么，这样用现成的模版很省事，能学到东西，能把事情做好。
Use-case完成得很快，我本以为又会拖很多时间，没想到三天就交工了（包括完成最重的文档），当然我们前期做了很多准备工作，大家基本筹备的差不多了，只是最后画一个图而已。我仔细看过，除了一些Documentation的语法错误以外，没有大的问题，至少我觉得是的。当然，我们准备以此作为一个训练做一次Inspection，长远的是打算针对系统设计文档做一个FTR（以前称呼它为DR，都是正式技术评审的意思，但似乎FTR用得更普遍一些），准备邀请助教参加的，不能出岔子，于是借用这个机会做一个训练，毕竟Inspection和FTR在流程上差别不是很大，区别主要在于参与者的权限，FTR有上级参与（这不是凭空说的，在Daniel Galin的<<Software Quality Assurance>>中可以找到原话）。
需求文档其实分为两个部分，一个称之为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可以自动生成相应的文档，很方便，很值得一试。
