正在阅读：经验之谈:我是这样领导一个学生项目的经验之谈:我是这样领导一个学生项目的

　　然而又一个失败让我沮丧，我没有过多斟酌就布置了估算的任务，我安排大家各自分工根据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图的文档，挺适合的，于是出现了这样两份文档，有些奇怪，现在想想可能不大合适，不过也不打算改了。