声明 转载自 http://www.mscto.com
没想到在小组成立的第八天才想起来该为这个项目记下点什么，不是开发设计文档，也不是使用手册或者项目进度表，而是为了我自己的一些回忆。这是我领导的第三个软件开发项目，真正意义上的应当是第一个，因为这次是软件工程课程的实践项目，相比而言以前的两个只能算是体验软件开发的一些经历而已。同样的，作为真正意义上的Leader，或者PM（项目经理Projectmanager），我还是个新手。毕竟，软件工程这门课刚刚开始五个星期，区区十五个学时还不能带给我一些什么，因而我努力阅读了大量的书目去丰富我的知识体系。我希望这个项目能够获得我期待的成功，至少这门课程的结业成绩能够让我满意，仅此而已。当然，如果能积累下宝贵的丰富经验那便是额外的巨大收获。
过去的一周让我充实，我从未如此大量的阅读书籍，在过去的七天中，我翻阅了近十本软件工程相关的书籍，它们大多是经典的和有效的，大约六本我仔细钻研了每一个细节，剩余的我循着前人的笔迹也汲取了足够的精华（这些书大多来自图书馆，感谢那些喜欢在书上乱涂乱画的前辈，是他们给我勾勒出了重点）。很难说我究竟学到了什么，技术上的也许没有，或者思想上的本就可以形式化为技术，那我的收获是丰富的。让我寄予期望最多的是著名的《人月神话》，这个书名让我的许多朋友误以为是小说的东西（事实上，人月指的是工作量，月指month），的确是那样迷人。如果说这本书与其它的书籍有什么区别，那就是：我阅读一般的两百页的书籍能够大约为其中的六七个闪光点而激动得手舞足蹈，而这本书有超过十次让我兴奋地从公交车上跳了起来（我不鼓励大家在公车上阅读，对视力的影响的确很大，尽管这是节省时间的一个有效的方法）。我要说的是，仅此而已，毕竟这是一本几十年前的书籍，尽管在它二十岁生日的时候再版过（这也正是我所阅读的版本），然而它并非是专为软件工程而设，尽管被软件工程领域的专家们奉为圣书。
我的这个小组共有五名成员，很多项目经理不愿意将自己记入到成员数目中，一个典型的说法是：我们小组由我以及另外四名成员构成。这会使得项目经理变得孤立，特别是人人都对上司有天生的反感的情况下，这种现象并不仅仅出现在中国。在上一次的OOP（面向对象项目）中，有三个骨干成员保留到了现在的小组，另外两个中的一个是同样出色的一名成员，也是小组中唯一的女生。最后的一个是一个不折不扣的新兵，是一个还不知道OO为何物的初学者（也许这样说有些自大，似乎我们已经清楚什么是真正的OO一样）。他的加入是一个偶然，纯粹是出于哥们儿义气，这也是大多数学生项目会遇到的问题之一，你不得不去面对一些你并不愿意一同合作的搭档。如何将这样的五个人捏合在一起将成为我们的项目成功的关键。在人面前，技术将变得索然无味，记住这样一个事实，项目管理是面向人的。于是我不得不花去相当多的时间帮助他通过Java来入门，这缘于我对Java的热爱以及Java很可能成为我们的开发语言这一事实（请记住，永远不要做无用功，争取让你现在做的每一件事都可以成为将来迭代的一部分）。
不要以为开会是一个不好的习惯，适当的会议是必要的，甚至是强行要求的，因为它可以让你的项目受益，我们为什么不适当进行会议呢。我的工作就是从第一次会议开始的，一个惊人的举动就是我决定在今后所有的字面文档和口头交流中都使用英文，为此我们进行了尝试，第一个吃螃蟹的人总是弥足珍贵，你的项目中需要有这样一个人，他有足够的能力，并且愿意尝试新鲜事物，不惧怕枪打出头鸟的传统观点。庆幸的，我们有这样一个组员（多使用“我们”而不是“我”，是每个项目经理应当养成的良好习惯）。于是，英文的交流顺利地展开了，尽管大家还有些约束，特别是那个新兵的四级考试还没有通过，着实让我汗颜。然而，轻车熟路之后一切都没有了障碍，单词成为了我们交流使用最多的单位，而不是句子。
第一次会议是轻松的，不要指望能通过这次会议得到些什么，这是一次互相熟悉的会议，彼此需要互相熟悉习性、说话的习惯、喜欢的零食甚至迟到的时间，对于一个项目经理，掌握这些更为重要，我无意重复实践的重要性，实际情况的反馈往往是制定今后计划和策略的基础，也是最直接的来源，然而不幸的是，没有人可以为你收集这些资料，你需要做的是默默记在心里，然后转为今后的行动依据，一些估算往往由此而来。
我们确定了文档的重要性，尽管文档驱动被更多的书籍称作软件开发的黑洞，一些专家认为文档仅仅是官僚主义的作风，当然没有人否认适当的文档是绝对必要的。什么样的文档应当生成呢？你需要将今后可能查阅的资料组织成文档，时刻告诫自己文档是面向未来的，而不是面向过去。单纯的流水账似的总结没有意义，附加上从中获得的经验教训才是这类文档的灵魂。
还有可笑的预算机制，对于学生项目而言，没有明确的所谓客户的概念，没有人会为你的付出买单，所有的开支都是有去无回的，对于许多并不富裕的学生来说任何的开销都倍加重要，请记住，没有一个一天只能吃一顿肉的孩子会为了打印一百页纸而花去四十块钱，他们更宁愿选择手抄。庆幸的，我们的小组成员虽然不能称得上富裕，但至少可以经常在菜盆中发现牛肉的痕迹。我们的预算（budget）机制很简单，也许称之为报销（reimbursement）机制更为合适：每个人先交十块钱给CFO（首席财政管，我们经常为起了这个名字而感到乐趣），也就是当然不让的那个女生，然后项目总结时一并从中报销开支，多退少补。就像许多班级收班费一样，简单的往往是最好的，因为它易于被最多的人接受。会议在轻松的气氛中结束，伴着混沌和锅贴的香味，看来选择食堂作为会议地点是一个不错的决定，因为这里足够嘈杂，不会让大家觉得拘束而不敢说出真实的想法，即使冷场也可以借用咀嚼的声音来打发无聊的时光。一个更现实的原因是，我们找不到其他的地方能同时拥有灯光、场地以及大声说话的权利了，我们没有会议室可用。请记住，这是一个学生项目。
第二次会议在一周之后举行，也就是昨天（还记得吗，我是在小组成立的第八天记录下的这篇文章）。一周以来，我明确了一个思想：项目经理必须和首席架构师分开，哪怕是四五个人的小型项目。这得感谢《人月神话》以及其他的软件项目管理的书籍（他们大多来自于机械工业出版社的软件开发技术丛书系列）。在以前的两个项目中，我都将项目管理和系统开发以及首席编程和测试融为一身，以至于曾经一个组员反问道：你都做完了还要我们干吗啊？的确，明确的分工是必要的，用人不疑，疑人不用。一个成功的项目经理应当懂得如何将工作交给适当的人去完成，而不是独自去完成所有的事。于是，我决定由另一个人来担任首席架构师的角色而不是我自己，这在我看来是一个破天荒的决定（尽管有些可笑），很多人（特别是学生和一些积极性不高的人）都会认为技术最好的人理应当成为项目经理，这也许也是我成为项目经理的原因，然而事实上要记住的是，项目经理是管理人的，而不是管理技术的，他所要做的仅仅是辅助首席架构师完成协调的工作，技术的事还是交给别人去完成吧。
我在图书馆花去了五个小时翻阅了几乎所有关于软件工程方面的国外书籍（不是我对国内的书籍作者有偏见，然而确实国外的教材要优秀的多，当然国内不乏鼎鼎有名的作者和同样鼎鼎有名的著作），从需求分析、设计到质量保证、配置管理，还有CMM，等等一切。我选出了九本书籍作为我们项目的主要参考书目。我为我们的小组设计了五个领导人（感到奇怪吗，我们一共只有五个人而已），分别是需求经理、首席架构师、质量保障经理、测试经理以及项目经理，也就是我自己。九本书的一本是所有人都必须阅读的，另外我为其他每个人选择了相关领域的各两本参考书，我认为它们是可获得的、经典的和有效的参考书，这是我五个小时的全部结晶。在每个阶段或者说每个领域，都会以特定的人为中心，其他人接受他的指派完成任务，这样做的好处是利用有限的人员让每个人能够尽可能多的体验到软件项目的所有阶段，请记住，这是一个学生项目，学习是第一位的。为什么要我亲自去选择参考书，因为我的时间比他们富裕，我免修了本学期的三门其他课程，因而我能够有足够的时间去做这些事情，同时，选择书籍的过程也是自我提升的过程，何乐而不为呢。
终于有人在第二次会议迟到了，直到我们收拾东西准备离场时才出现，后果就是我们已经分完了所有的职位，她没有选择地成为了需求经理。这并不是什么坏差事，然而对于这样的学生项目，没有真正的客户是一个很困难的问题。需求经理需要有强烈的自虐倾向，需要自己扮演客户、最终用户和需求分析师三个角色（如果你还不清楚客户和最终用户的区别，那太糟糕了。客户是出钱的人，用户是实际使用软件的人），这种经历恐怕是绝无仅有的，试想，一个人需要自己不断给自己出难题，然后去解决，太可怕了。那个新兵选择了质量保障经理，因为他认为这是个轻松的职位，不用太多的编写代码，他讨厌程序设计。事实上，我可以想象当他面对一大堆模型的时候他的反应。在软件项目中，如果你认为某一个职位是轻松的，那唯一的原因是你还没有真正理解这个职位的作用。
会议中我最后强调的是，每个人都应当适时地召开会议，并非只有项目经理才有权召开会议，如果必要，任何人都可以这样做。另外，软件项目不是生活的全部，每个人应当将更多的精力放到生活中去，比如陪伴自己的家人，或者处理其他学业，这仅仅是一个项目，是诸多生活元素中的一部分，仅此而已。
一周中我最大的工作是完成了项目计划的草案，这得益于我阅读的几本书籍，当然还有RationalSoDA，这是一个很棒的文档自动化工具，它的文档格式成为了我的设计标准，甚至教会了我许多MicrosoftWord的使用技巧，比如自动生成目录。这份草案没有任何实质内容，仅仅是标题性的搭建了框架，所有的内容将在一周之内填充，为什么？因为我们还不知道项目的题目，除此以外的一切都会是徒劳。良好的准备是必要的，在组织任何文档之前都应当先建立模版或者框架，接下来的工作才是用内容去填充框架，而不是线性的编写过程。
也许我还做过许多别的事，然而八天的缘故已经难以一一记录，有一些大概已经在脑海里永远冬眠了，甚至我自己都难以提取形成文字。庆幸的是每个人同样可以获得这些，只要愿意去阅读一些经典的书籍，总能得到。
现在我能做的就是静静等待项目题目的出现，还有学习RUP，三个月之后项目交工之时我大约能够读完软件项目最经典的一百本书籍，这会是我最大的收获和骄傲。我喜欢从阅读中得到满足。
项目正式启动了，因为我们获得了一个导师推荐的题目，这是一个realtysystem，之所以推荐是因为它和RationalRose教程中的例子是一样的，因而对于初学者而言有很多可以直接参考的UML模型，事实上，掌握UML是这次课程的重点。然而我们并没有打算做这个题目，因为我们不想依靠太多现成的东西，和更多的组撞车不是一个好主意，更重要的，我们既不能和现有模型太过相似，显然至少不能比它还要差，然而事实是这个模型已经相当完善了，我们没有了发挥的余地。于是在每周例会上，我们决定重新找一个题目。周例会也变成了每周两次，这样做是必要的，因为在开发的前期准备阶段，我们需要很多的时间来达成一些共识作为今后的行动准则，这同样可以营造出良好的讨论氛围和融洽的合作关系，为后面的开发做好铺垫，而这一阶段的文档要求并不高，工作量不大，有足够的时间来讨论。
不知道算不算一个明智的决定，我在题目决定之前就分发了风险组织的任务，因为我相信对于大多数项目而言，大多数的风险是相似的，这种相似包括可能性和影响级别，当然还有风险类别。也许80-20准则是适用的。现在看来这个决定暂时是明智的，因为在这个阶段我们没有太多的事可以做，或者说没有太多需要形成文档的工作。我们需要时刻保持对文档的熟悉，所以安排在这个时候做风险分析是合适的。我给出了一个模版，要求我们每一个人给出至少30条风险，其中至少有10条是和自己的角色相关的（比如测试经理必须给出10条与测试密切相关的风险），这样做一方面可以让各人更加熟悉自己的角色，同时也让各自风险雷同的几率小了很多，我们有更多的机会找到更多的风险。很快地，反馈回来了，这是第一次让我得到满足的反馈，ReviewManager负责将这些风险组织起来，去掉雷同的并给出适当的翻译，可能会很奇怪为什么要这样做，我们一再要求所有的文档必须英文化，为什么还要多此一举把它再翻回来呢，因为在这些风险中，很多是来自于一些中文资料，每个人将它们用自己的英语生硬地翻译成英文之后提交了上来，面对那些蹩脚的英文或许翻回中文再阅读比较合适，当然最后还是要重新翻译成英文的。很快地，我们总结出了大约80条风险，去粗取精之后剩下了50条，形成了最终的风险表。不可能也没有必要对所有50条风险都做监督管理计划，我们选择了其中的30条形成各自的RMMM（RiskMitigationMonitoringandManagement，风险缓解、监督和管理计划），每个人负责6条的编写，当然都是和各自的角色密切相关的6条风险，所选择的风险或者发生可能性高同时影响也不低，或者尽管不大可能发生然而一旦发生后果很严重，它们都被列入了风险表并进行管理。同样地，伴随着分发的任务还有一份我制作的RMMMTemplate，需要说明的是，作为一个学生项目经理，最好能够尽可能多地给出各种文档模版给大家使用，因为我们并不是总有很多现成的模版可以使用，而事实上很多人不是很愿意去寻找模版，所以比起之后再统一格式，一个好的选择就是尽早地分发模版，当然，这要占用项目经理的很多时间。
主题的决定是艰难的，尽管否定了老师的推荐主题，我们仍然没有确定合适的替代者。我的建议是一定要围绕数据库开发，这样的好处是我们可以形成更多地UML图表（主要是类图），这也正是导师的初衷，主动去迎合他不是很好吗。于是，锁定在信息管理领域成为了第一个确定的范围。关于足球转会系统的设想失败了，因为我们的RequirementsManager（也就是那个唯一的女生）对足球不感兴趣，的确，很难想象让这样的角色去做不愿意做的事情，那对项目的损害是灾难性的。另一个提议是学生信息管理系统，或者通俗地讲就是做一个教务处系统，这是被我否决的提议。试想，这样一个系统导师和其他同学太过熟悉了，一旦包含任何的缺陷（这是必然的）很容易就会被发现，对于学生项目这是一个糟糕的主题。最后的选择是酒店管理系统，主要是面向前台的订房系统，这来源于需求经理的强烈兴趣，有时候非原则性的相互妥协是必要的，它可以激发团队的工作热情，更何况这是一个的确很不错的主题，因为它需要一定的专业领域知识，在一个项目中涉及到适当的专业知识可以使得需求范围进一步缩小，需求更加明确，同时可能会有比较多的现有系统来参考。不容忽视的是，并非每个同学和导师都会对这些领域的系统相当熟悉，也就容许了一些缺陷的偷偷存在。
我曾经试图将项目计划中的活动计划分发给每个人去完成，然而几经考虑之后不很合适，因为现在已经有太多的事情要做，为了保持团队的活力（一个重要的原因是我的课比起他们要少得多），我决定独立完成计划，当然这期间每个人仍然有自己的任务要完成，不要让任何一个人闲着，因为这表明对他的不信任和对他能力的低估，每个人都适当忙碌对大家都有益。项目计划也是有现成模版的，感谢RationalSoDA的模版，当然还有我综合各种文献进行的修改，使得文档的结构相当完善，好的结构是进行文档创作的第一步，需要再次强调模版的作用，前人的财富对于初学者总是享用不尽的。在制作项目开发进度的Gantt图（甘特图）时，我采用了MicrosoftProject，尽管我不很愿意过多地使用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可以比较正式，另一方面可以争取到更多的映像分，要知道这是学生项目中必须面对的现实。当然，每个组员必须一致同意才可以，否则凝聚力会大大下降。一切都只是策划，对于评审我们实在没有任何经验，书本是唯一的知识来源。
考完试之后，需求分析就要随之结束了，正式的设计即将展开，好戏渐渐上演，后面会发生什么，我很期待，也多了一丝担忧。我能做的，就是准备好充足的文档和模版，组织好会议，做好沟通，分布好任务，剩下的，需要每个人的努力。
先说些额外的话，本来想至少每周能记下一些东西的，现在看来真不一定什么时候有空了，工作一定时间积累些东西能形成两三千字就发上来吧，会议记录真的很管用，有时候我都会忘了过去的几天究竟做过什么事情，看看会议记录全想起来了，要不写这个东西就很困难了。今天看到很多朋友留了言，很多朋友的意见很中肯，几句话就让我受益匪浅，在此一并感谢。要重新说明的是，我记录的这些历程本意是想给今后学习软件工程课程的朋友们一些帮助，经验也好，教训也好，前人留给我很多东西，我也希望能做些什么。当然这一定是一个漏洞百出甚至幼稚至极的项目，可能几个月后我回过头来看自己写的东西也会觉得不好意思，不过这一切都是真实的。前辈们阅读之后请多提意见和建议，我很需要你们大家的帮助。如果大家觉得这些文字太可笑了不屑于发表些什么，那很抱歉我耽误了您的时间，但请不要对我个人进行任何形式的人身攻击，谢谢您。
回归正题。
需求分析算是告一段落了。我们的需求经理付出了很多（一些朋友提到用经理一词不很合适，的确，动不动就经理来经理去的似乎我们在做多大的项目一样，也显得不够谦虚。不过仅仅是称呼而已，我给每个人都安排了一个经理的头衔，包括需求经理、评审经理、测试经理等，这样做一方面可以明确各自的主要任务和角色，另一方面大家心理上也会愉悦很多，毕竟，大家都愿意称呼我为项目经理，如果我称呼每个人组员似乎不大合适，有些盛气凌人的感觉，也叫个经理有个缓和，茶余饭后也是大家的一种消遣，缓解一下气氛的笑料，何乐不为呢）。我结合各种模版做出了一份需求规格书（SoftwareRequirementsSpecification）。我先是参考了Pressman的建议模版（因为我们用的就是Pressman的教科书--<>，<<软件工程，实践者之路第5版>>），另一方面参考了Sommerville的<>，上面给出了需求规格书内容的许多建议，还有就是飞思科技的<>，这本书很特别，基本上就是各种文档的模版，挺有趣的书，给了我很大帮助。当然还有RationalSoDA自带的一些模版，这个很有参考价值，一方面毕竟是大公司的推荐模版，商业性更强，前面的一些模版学术性可能稍强一些；另一方面毕竟是电子版的，可以直接用了，很方便。我基本上就是按照SoDA的模版结合其它的一些稍作修改形成了最终的模版给了需求经理，她的任务就是完成这个模版，因为完成了这个模版也就相当于做完了需求分析，这个模版的内容太丰富了，包括了足够的use-case信息和功能及非功能规约。参考各种模版也是不得已的和必要的，我们没有任何经验，甚至不知道需求文档中需要出现什么，这样用现成的模版很省事，能学到东西，能把事情做好。
Use-case完成得很快，我本以为又会拖很多时间，没想到三天就交工了（包括完成最重的文档），当然我们前期做了很多准备工作，大家基本筹备的差不多了，只是最后画一个图而已。我仔细看过，除了一些Documentation的语法错误以外，没有大的问题，至少我觉得是的。当然，我们准备以此作为一个训练做一次Inspection，长远的是打算针对系统设计文档做一个FTR（以前称呼它为DR，都是正式技术评审的意思，但似乎FTR用得更普遍一些），准备邀请助教参加的，不能出岔子，于是借用这个机会做一个训练，毕竟Inspection和FTR在流程上差别不是很大，区别主要在于参与者的权限，FTR有上级参与（这不是凭空说的，在DanielGalin的<>中可以找到原话）。
需求文档其实分为两个部分，一个称之为SoftwareRequirementsSpecification，它包括了几乎所有的内容，除了use-case图，最后我才发现这个问题，use-case图没地方放了，正好RationalSoDA有一个use-case-modelsurvey模版，专门用于形成use-case图的文档，挺适合的，于是出现了这样两份文档，有些奇怪，现在想想可能不大合适，不过也不打算改了。
风险管理拖到现在才最终完成，主要是RMMM的问题，有几个人没弄清RMMM文档的部分内容的含义，有一个内容是风险跟踪，我的理解就是出现了相关风险情况时就加以记录，可是有几个人撰写的时候就在这儿胡乱填了一些东西，挺奇怪的，可能我没有交代清楚。英文的文档就是这个不好，大家沟通起来不方便，这有点违背了文档的本意。记得一本书上说过，如何避免陷入文档驱动的黑洞中呢，很简单，只制作对未来有益和利于沟通的文档，我觉得可以这么说，文档就是用来沟通的。既然英文文档不利于沟通（至少现在感觉上是的），为什么还要采用，呵呵，学生项目嘛，一个直接目的是获取高分，形式上的东西是必要的，尽管可能不很合适。我也不知道今后的工作中是不是一定要用英文文档，英文究竟占据多大的地位也不清楚，先在做些准备不是什么坏事。
现在ChiefArchitect开始进行设计了，因为我们赶上了预定进度，时间上宽裕了起来。我很相信他的能力，我想作为组长对组员的态度就是用人不疑。我很清楚为什么我会被推选为组长，因为我的设计和编码能力是最强的，我想大多数学生小组选组长都是这个原则。然而现在我不应该去做这件事情，尽管我很乐意，但这是对他能力的怀疑，是对他的不尊重，更何况他也有很强的实力。越权不是一个好主意。当然，我在交付给他设计文档模版时还是给了一些必要的思路和建议，比如按照MVC的要求设计类，比如底层的RMI机制。另一方面，在评审时我可以将我的意见提出来，有很多方式可以让我自己参与到设计中来，当然，前提是第一个版本一定要让该做的人去做，任何事情都一样。这是对制度的遵守，对人的尊重。 软件开发网
不幸或者有幸的，我现在正式成为了第二个小组的组长，这是一个本体采集小组，与现在的酒店管理系统有很大的区别，当然管理上的区别可能不是很大。之所以这样是因为软件工程的教师正是我今后研究生阶段的意向导师，他有意让跟他的四个人单独出来组个小组做个东西，一方面增加交流，另一方面可以尽早接触今后的研究领域。于是有了这个小组的诞生，我还成为了组长。时间分配可能会更紧张，毕竟两个组都不能出岔子，未来的两个月会很忙。同样的，学习的机会也更多了。第二个组的工作我又要重新开始从计划做起了，呵呵，希望自己能好运。
下一阶段的任务，设计，主要就是完成类图了，其他大的方面大家都心中有数了，就差类图了，然后可以开始编码，大约一周之后吧，五一之后完成编码吧，编码怎么分工我还没考虑好，有能力参与的有四个人，GUI只有我比较熟悉，我们拥有一个数据库专家，称之为专家是因为他的数据库编程经验在我们之中是最丰富的，另外的方面我还不清楚，我不很清楚大家在编码方面究竟有多大的能力和潜力，我不想走一步算一步，可能让每个人自己选择负责的部分是一个好主意吧。说实话，需求做得很详细，功能上还是要实现很多东西的，我不时地想起来，总觉得全部实现有困难，导师说过，这是一个允许失败的项目，我可不想失败。我现在能做的就是先去做一个原型系统，把界面大概勾勒一下，让大家心中有数，然后，我们开始。
忘了强调一下RationalSoDA，这是个很棒的文档自动化工具，可以和Rational其他的组件结合得很好，比如根据RationalRose的use-casediagram可以自动生成相应的文档，很方便，很值得一试。
这一周是忙碌的。
需求分析基本完成了，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，那么font-size: 10.5pt; co
评论