UML软件工程组织

 

 

“适用性”是最重要的需求
 
2007-11-22 作者:aaronzhu 出处:cnblogs
 

题目这句话来自金英勋的《如何准备PMP考试》,我学习这一观点的时候,有点似懂非懂。对这句话有了台阶性的认识是那次……(镜头渐淡,并切换至某年某月某日……呼呼……)

前段时间跟上海市某区的信息委进行接触,对该区建设人口数据平台进行可行性分析。对方是个较懂计算机的可爱的老头儿。我过去后,他把我拉到他桌子边,捻来一张纸,张口就跟我说:“其实这个很简单的,就是一个数据库。”然后就画了一个简单的框图,说上面是上海市的人口基础数据中心,下面是区里的数据库,区里有一些人口的扩展数据,如计划生育数据、劳动保障数据、教育数据等等。大概半个小时之后我脑子里有了我的印象,并画出来(如下图)跟他说:

“您说的是这个意思嘛?”

“对对,就是这个意思。”

“那么这些区委职能部门的业务具体有哪些呢?”我问,因为我觉得职能部门的应用才是这个系统的最重要的部分。

不料他说:“你不用管这些,你先考虑上面的。职能部门这些还不确定可能增加、减少都不一定。”

坦白说,当时我有点懵。决定先回来考虑清楚、整理一下再来讨论。

我整理后大致是这样的(诸位可以也大致想象一下这样的“人口数据平台”应该包括哪些):

系统的用户或者说角色主要包括:区数据中心的维护人员(就是区信息委),区委各职能部门工作人员,市人口基础数据中心。

主要功能包括:

(1) 从市人口基础数据中心获取人口基础数据

(2) 各个区委职能部门根据基础数据建立“扩展数据”,并对扩展数据进行维护(如:新增了几个计划生育对象啦,又有几个小孩要上学啦,等等)

(3) 由于他说区委各个职能部门的不确定性比较大,我还考虑设计一个比较通用的数据层接口,可以扩展数据和扩展职能部门的应用

(4) 由于各个区是新增人口(如新出生的、从外地新转来的)的采集源,因此我们还考虑到将新增基础数据同步到市人口基础数据中心

整理出数据流图:

并且我还考虑到各个职能部门应用系统的开发周期、难度等,最后给出了一个大致的预算。

当我把我的文档给他看时,他显得不可思议(是对于预算,大大超过了他的考虑):“你们把问题搞复杂了。”可是也不知道哪里搞复杂了。

于是我又跟他反复聊,指着一个大图,问他“这里有没有问题、那里有没有问题”。最后,我终于搞明白他的意思:

各个职能部门的应用只是查询,所有数据更改都在信息委数据维护中心。修改后数据流图:

什么意思?举个“将某十个人列为计划生育对象”例子:

(1) 计生职能部门的工作人员通过该人口数据系统查出这十个人,并将他们的保存在本地(如导出成Excel保存在他们自己的机器上);

(2) 将这些信息相应字段进行修改;

(3) 确定修改完毕将该文件上传给信息委,专门管理人口数据的工作人员会打开数据核对,“经确认后”更新到区委人口数据平台中;

(4) 数据更新完毕。

区委所有职能部门对于人口数据的管理都通过这样的操作来实现。区里新增的人口基础数据也是通过另外的数据库文件上报到市里,而不是通过数据库直接同步回去。

明白了没有?这其实是一个超乎我们“正常”想法的实现方式。我们通常直接的反应是:“这样不是很傻?”甚至会怀疑是不是因为对方不了解计算机真正能干什么才这样考虑的。其实不是!

好像就在离开那个可爱的老头的办公室的一瞬间,我明白了好多东西(呼呼……),同时觉得他考虑真是实在实际。

(镜头切换回来……呼呼……)
我们之前那种方案(且称为“方案一”),固然好、“科学”。但是各个职能部门应用系统的复杂性显然大大增加,于是我们其实隐含的做了假设:“系统所有用户将具有一定的计算机应用能力”。而客户跟我们说:那些职能部门的工作人员都是年纪比较大的,能用用简单的Excel已经很不错了,不可能要他们学习操作一个复杂的系统的。再有,方案一的系统建成后的稳定性可能远远低于方案二,且成本相差悬殊。

方案二看上去有点“傻”,可是如果考虑到用户的实际情况,那么简直就是很完美的方案:首先,大大降低了对用户的要求;其次,大大增加了系统建设成功的可能性;再次,大大降低了系统建设成本,系统维护成本;最后,他们能够达到“保护数据”的目的,因为“如果各个部门的人都可以改来改去不是乱了套?”,与其要制定很多章程、规则不如把数据更新工作全部统一到一个专门部门,总体上看显然增加了可行性并降低了实施成本。唯一的缺陷就是增加专门的维护数据的模块和人员,但是这一点缺陷却远远不能反驳上述几个优势。

我后来想了很多次,越来越觉得他们的解决方案很精妙,达到了很多他们的目标和想法。相反,方案一显得臃肿、笨重、可行性差。我还觉得,这种思想在政府行业信息化的过程中相当重要,因为政府机关他们普遍具有同样的情况。设计者光从系统设计的角度出发、从设计一个“完美”的产品的角度出发,却跟客户心里真正想要的东西相差甚远有什么用?

我们往往对于质量这个概念有个很大的误解:质量高的软件就是软件思想、设计、编码各方面都很先进一流的软件。非也!适合的才是最好的。这一点在PMBOK中有解释:不要把质量与等级混淆。一件产品可以等级低,但是不能质量低。等级低,是因为用户对之要求就低,而质量低,则是因为生产过程没有控制好导致不能满足期望。比如说:建两间小房子,一间要粉刷墙壁,一间只要毛坯。这叫等级不同。如果要刷墙的那个刷完后总起皮或者掉泥块,这叫质量差。

现代质量管理最重要的观点之一就是:理解、管理和影响需求,从而达到客户的希望。这就要求项目产品符合要求(项目必须生产它所承诺生产的产品),并且应该具有适用性(项目提供的产品或服务必须能满足实际需要)。忽视适用性的后果就是可能导致100万成本建设的系统还没有人家花10万块弄的小程序给人感觉好!所以啊,尽量避免自己在那儿一厢情愿、自以为是的闭门造车,多跟客户沟通!

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号