发信人: ninja_xena()
整理人: hnyjchuhong(2002-04-02 17:08:43), 站内信件
|
这个题目是不是吓人呢？诸位系统分析员不是觉得我猪头就是嫌我不够档次吧？呵呵，各位的心意心领了。
我想说的是，系统分析是必须的，但不应该和代码、文档、测试、维护分开。当然有个前提条件，就是帮企业做初步的信息系统。
我曾经做过一个程序。先是从老板到员工各自描述一遍业务和对系统的期望，然后回去整理，然后由去确认一遍，又回去整理。最后开始写代码，代码写好了，第一个测试版本出来，安装上测试。结果发现整个系统距离他们的期望很远，有一种整个系统分析都不对的感觉……
后来一边测试一边修改，始终让客户人员在现场，辛苦了数个日夜，才被“勉强用起来”。
回过头来看，整个过程，真正认为是系统分析的内容，已经被后来的“测试”改的面目全非了。与其做了一堆代码全部改一遍，想想不如一点点功能做，每做一部分功能就让客户人员参与测试一下，这样需要的时间更少。
当然老板是不喜欢他的员工浪费太多时间在他已经付了钱的服务上。但当时情势所迫，才勉强同意。不过这样做下来，反而能用起来。
其实也许按照书本的系统分析顺序一步步去走，有时候还不如下定决心要重写几十次代码，直接为客户一个个的功能去实现。开始的时候感觉好象是拼凑代码，很“业余”的感觉，但当一个系列的功能拼凑完了，你觉得代码混乱不堪，你就可能很有重新写一遍的欲望。在忍住强烈的恶心重新构造过自己的代码后，你会发现整个系统的结构和功能已经安排的井井有条，完全没有需要猜测和“预留”代码的需要了。——这就是重构的好处。
当然拉，在思考系统结构和实现过程中，USE CASE这类系统分析的概念还是很有用的，不过人家能写上书本的都是做大项目的做法（原谅我这只井底之蛙），那种“官僚主义”的文档真是无法让人接受——最重要的是一点实际用途都没有，至少我用不起ROSE这样豪华的工具，呵呵。
所以，我决心在使用角色在8个以内的系统的建造是，都会——一脚踢开该死的“系统分析”。 |
|