2005年度年末随笔（上）

时下这几年感觉“年度”这词比较火，如CCTV2的“感动中国年度人物”、Sina.com的“年度十大新闻评选”……，当然偶的这点烂笔头是不能与之相提并论的。以前总是在网上拜读 “大虾”们的文章，有一天突然发现（好象就是前几天，呵呵），自己作为四大媒体之一的从业人员（其实也就是经常把Msn、QQ、Skype挂在网上，美其名曰互联网从业人员），有义务为网络媒体的“物质文明”和“精神文明”建设贡献一点微薄之力（键盘敲到此处忽然发现映在背墙的身影开始变得高大起来……）。

我这里所谓的年末随想也就是把这一年自己所做的一些事情做一下简单的回忆，这也许对很多人来说是一些无用的口水话，但是我的本意还是希望自己所写的这点东西能够拿出来和“志同道合”朋友一起学习，在下笔之前没有做所谓的文章构思，完全是种随笔，想到哪写到哪，这也是自己在文字开头就强调自己是个“烂笔头”的原因。

我是今年7月份进入现在这家公司的，这是一家专门从事电力行业应用软件开发的公司，经过一个月时间的环境熟悉，便开始了我的项目旅程，在这项目中我主要负责项目管理、需求调研、系统设计，和功能实现详细文档的编写，虽然在下笔的这一刻系统还没有结项，但这已经没太多问题，整个过程给我的感觉就是一个字――累，为什么？沏壶茶，坐下来，听我慢慢说。

首先给大家简单地介绍一下项目的背景，这个项目是与XX集团的一个分公司签订的合同，但是系统所服务的对象是下属的各个电厂，也就是说系统的调研和实施都需要到各个电厂去，同时在系统设计上要求有良好的可扩展性和可维护性。

7月中下旬，跟随着一个项目经理和质保部经理开始去各电厂做调研，不知是因为公司给我的工作不够明确还是其他的原因，当时我并不能真正的参于进来。在做调研的过程中，每到一处都有一个共同点，就是绝大多数人并不知道我们是谁，来干什么的，简单的一阵茅遂自荐后，便开始了相关业务部门的调研工作，在进行调研时并没有按照“系统边界”（调研人员的主观系统边界）所涉及的业务进行调研，而是根据个人的主观意识选择性地进行调研（在这之前公司花了一年多的时间做了一个类似的系统，但基本上是失败的）。整个调研过程自己对该阶段的一些工作是够认同的：

1：工作协调没有到位，在这点存在两个层次的缺陷：

A．              分公司与下属各电厂之间在沟通上不够充分，最终用户内部对此件事情的了解不够充分，只有极少部分人知道要上一套信息管理系统这回事。在这种情况下则会引发一系统问题。首先最终客户很少会因此组织一个相应有效的项目组，在系统边界确定和业务环节方面缺乏总体把握的人员。第二在没有有效指引的前提下，所调研的对象也许并非是你所真正需要的。第三没有好的开始很难带动一个好的过程，你的调研行为有时并不一定会引起相关业务部门或调研对象的足够重视，这一点是非常危险的。

B．              自身准备不够充分，与分公司及最终用户的沟通不够。在调研开始前首先需要对项目背景要有一个充分的认识，这是制定一个良好的调研计划的前提。第二需要对调研单位及相关单位的当前情况有具体的了解。第三在前两点的前提下需要制定比较详细的调研计划，再与客户交流调研计划中的内容。这个过程能够让我们更加充分地了解到当前情况需要加强哪些准备工作，同时能够为客户更好地做好调研配合工作提供有利的依据。

2：调研步骤缺乏层次。

这是一个具体的调研方法问题，在调研开始就对具体业务细节过分地感兴趣，这或许并非是件好的事情。把整个过程分为全局和局部两个部分，更加有利于我们理清思路和系统边界，针对每个业务环节再制定细致的调研计划。当然这个过程也不可能是个瀑布式的过程，它应该是迭代交替的，领域专家和业务专家对真正做好这个过程来讲应该是不可或缺的。

3：调研过程主观意识成份过重，影响调研内容的全面性、客观性和准确性。

选择性地调研与调研工作的目的应该是相冲突，我觉得在我们未成领域专家或业务专家之前最好不要做这样的尝试。在做这个项目之前我们给另外一个电厂做过一个这样的系统（公司内部称之为第一版），但各电厂之间的管理模式并非完全一致，更确切地说应该是部分类似。选择性地调研使我们对非功能性需求和特性性需求无法得到全面、准确地掌握，而这些又是我们进行技术架构和系统架构的基础。如果在架构过程对这些需求没有充分考虑，那么这对整个系统来讲是非常危险的。

经过一段时间在电厂之间的穿梭后，开始整理需求文档，编制完《需求规格说明书》，质保部对其进行了一番评审。在这段时间项目组内发生了一些人事调整，由我来负责这个项目的工作，当时听到这个安排时心里是矛盾的，高兴的是刚进公司就能得到这样的机会，忧虑的是一些前期工作并非我想象中的那样到位，而且在整个项目过程中还须承担第一版系统繁杂的维护工作。话题有点扯远了，让我们继续接着刚才的内容往下走，评审结束后开始制定系统开发计划，总体计划分配时间为：系统设计45日、系统编码60日、系统实施60日（两个电厂）。计划提交后，很快得到公司决策层的批示：计划时间太长、必须缩减到45日，当我听到这样的批示时感到非常的惊讶，我原本以为我已作压缩的计划会得到公司的通过。压缩项目时间这似乎是大多数公司喜欢做的一件事情，每个公司都希望用最短的时间、最少的投入获得最大的收益，但是绝大数往往事与愿违（这仅是我个人的观点，比较偏激，如有雷同、纯属巧合，呵呵），虽然在很多关于软件工程的书籍中强调不要以这种方式来决定项目期限，但可惜的是公司决策层或者说老板一般不会看这种书籍。在公司坚定的决策前，我只能修改计划的数字，这个过程是个痛苦的过程，尽管时间非常短暂，既要兼顾计划的“合理性”、“可执行性”又要让它看起来更符合公司决策层的“想法”，修改后的计划很快得到了公司的通过，在完成高度用例分析之后，根据业务内容进行用例分类，将用例分发给其他两个分析人员进行更细致的局部分析（加上我项目组一共有三名系统分析人员）。在设计伊始强调在项目组内必须采用UML规范进行系统分析，为了达到这个要求项目组内采取了一些短暂的培训工作，但最后的分析结果却差强人意，整个过程除了消耗了一些时间和精力外，似乎并没取得一些其他的收获，他们更喜欢或者说是习惯直接用文字和流程图在WORD中进行描述。最后只好在项目组内放弃这个规范，允许每个分析员按照自己的习惯进行分析，我不知道这样做是不是错误的，但我觉得这是我所能想到的在当前情况下最适合项目组的方式。画用例图、编写用例文档、画用例活动图，这是个非常枯燥而又繁琐的过程（我个人不成熟的观点），但这又是个不可逾越的过程，这一步的工作质量直接影响到以后的分析内容，当完成这一步工作，突然惊醒，翻弄了一下日历，才发现这段工作所耗费的时间在项目期限中所占比率不轻。

在完成用例的分析之后，准备进行设计模型的分析，但是受一些因素的影响最终放弃了这步及其之后的步骤。在这个系统的实现上公司将采用一个新的开发平台来完成（通过一套自身的Tag lib实现了Rich Client的封装，并通过Ajax技术实现Web Browser与Web Service之间的数据交互，在开发模式上引入了一些C/S开发工具的方式），由于是个全新的平台，系统设计人员对这个平台的架构机制都不是太了解，当然也没花时间去了解，所以也没做太多的构架分析，基本依托平台现有的架构。在简单地完成了系统层次架构分析之后，开始进行对象抽象分析，寻找对象、定义对象、描述对象静态关系、动态关系，在极其有限的分析时间内完成这样一个庞大的工作量几乎是不可能的，最后只能选择放弃这种模式。转而直接根据《用户需求规格说明书》和用例分析图进行数据库设计，经过几个昼夜的艰苦奋战数据库的设计终于完成。对照一下计划，虽然超出了规定的时间，但值得庆幸的是在可以接受的范围内。分析到这一步基本上算告一段落，便开始对分析的结果进行评审，先在项目组内部进行评审，最后再由公司进行评审，这个过程感觉是漫长的，评审的每一天都是在解释与争论中渡过的。系统设计终于在一片不协调的声音中定型，赶紧为系统的实现制订详细的开发计划，根据用例的重要程度、风险程度、难易程度进行分类并划分优先级，最后将用例的开发分配到具体的开发人员。开始为每个用例编写详细开发文档，我们以IPO表格作为详细文档作为模板，然后每个功能模块制作相应的静态页面，开发人员根据详细文档和静态页面进行代码实现，这实际上是一种非常古老的方法，但它似乎比较适合项目组的现状（现在回想起来，感觉在分析方法上就像一锅大杂烩，呵呵）。当然编写详细文档和制作静态页面的工作量也是非常具大的，不可能在所有的详细文档和静态页面编写完成后再着手编码，那样做时间上是不允许的，代码实现工作和文档准备工作基本上同步进行的，但是将文档准备工作控制在代码实现的前一周完成。感到欣慰的是，这种模式在很短的时间内实现了设计阶段向编码阶段的过渡，系统分析人员所表达的思想基本能够比较准确地传递给开发人员，终于进入编码了…

写到这已是深夜了，先告一段落吧，之后就是系统开发阶段和系统实施阶段的内容了，这一部分的情况将在《2005年度年末随笔（下）》中向大家介绍，最后祝大家新年快乐！（未完待续）

[e-mail]

2006-1-25 00:26