细节决定软件成败[转]

细节决定软件成败

■ 张涛

对于用户而言,好的软件不仅体现在功能上能够胜任,更重要的还在于软件使用是否方便、易用等细节上。

信息系统的设计与实现是一项庞大而繁杂的工作,对技术人员要求很高,一方面要求对所涉及的业务知识相当熟悉,另一方面要求有一定的应用软件理论基础和开发经验。笔者将通过一些示例,把自己在信息系统的设计与实现过程中的经验和教训总结出来与大家分享。

软件系统的专业性

软件的专业性可以从业务专业性和技术专业性两个方面来考虑,下面我们分别说明。

1.业务专业性

每个行业都有自己的业务逻辑和业务流程,如何通过软件技术把用户的需求转换为业务功能,这是信息系统业务专业性的体现。那么我们是否把共性的业务逻辑体现出来就行了呢?答案是否定的,业务逻辑也有个性化的需求,我们应该留有扩充的余地。

比如: VIP用户每次买东西可以享受7折优惠,金卡用户享受8折优惠,银卡用户享受9折优惠。对于这样的需求我们如何进行设计?常规的方法是在用户档案表中设置一个字段,用于存放用户类型,在计算金额时通过关联获取折扣率。这样一来就出现一个问题,即:某用户由于某些原因属于金卡类,却能够享受7折优惠,但是在用户数的统计报表中仍然要按照金卡进行统计。此类问题并不鲜见,笔者感觉比较合适的设计是:字典还要建,这样可以保证数据一致性,但在用户档案中除了有用户类型字段外,还增加“折扣率”字段,正常情况下该字段值为“-1”。意为正常(从字典中获取折扣率),在特殊情况下可以进行修改,为个别用户提供个性化设置。这样既符合数据库范式的设计要求,又满足了实际业务需求。尤其是当业务项目之间逻辑复杂,或连带关系比较强的时候,这样处理不仅能够体现出系统的专业性,更能体现出应用软件的人性化设计。

2. 技术专业性

技术专业性是开发商软件开发能力的体现,包括:界面设计、提示设计、操作设计等,由于篇幅有限在此仅对界面设计进行简要描述。

无论是采用C/S还是B/S架构的系统,都要遵循合理、简洁、有效、一致、美观几个原则。目前各种开发工具都提供了充足的控件支持界面设计,所以我们在使用过程中更应该进行斟酌和推敲。比如:要设计一个选择现场工作人员的窗口(每次到现场的工作人员可能一个或多个),有两种设计(参见图1)。

《细节决定软件成败[转]》

其实两种设计都好,只是在不同的业务特点下孰优孰劣才能够体现出来:当需要选择的工作人员较多时方案二比较好,反之方案一比较好。总体上说,我们在进行界面设计前,首先要充分理解实际的业务需求和业务特点,其次熟练掌握每一种控件的主要功能和用途,这样才能够设计出比较好的界面。

软件系统的可扩充性

可扩充性很多时候被大家当成是一种惯用语,尤其是在一些与应用软件相关的文档中,而实际上在设计过程中,并没有很好地实现。笔者以为可扩充性应当通过以下几点体现出来:

1. 业务数据项目的扩充

随着时间的推移,用户的管理会逐渐细化,即:管理、分析的内容会逐渐增多,因此我们在最初的系统数据库设计时要充分考虑数据项目的扩充问题。比如:经过调研用户档案包括的项目有:编号、名称、类型、信用等级、联系人、联系电话、通讯地址。我们应当如何在满足当前需求的情况下,再预留一些扩充的余地呢?可以首先设计一个用户档案表,其中包含调研时的项目,而后再补充扩充属性字典表和扩充属性数据表,来满足日后的扩充需求(如图2所示)。

《细节决定软件成败[转]》

经过分析后系统中会有较多类似的情况,这时可以对扩充属性字典再次进行抽象和设计(比如,增加“是否必填”、“表现方式”等字段),达到通用、共用的效果。通过这样的方式构建用户档案库表,可能在程序实现上有一点难度,但是换来的效果是非常明显的。

2. 业务算法/业务逻辑的扩充

在功能或报表中有些算法或逻辑会随着时间的推移而发生变化,如果我们想要减少日后的维护成本和服务响应时间,就必须考虑业务算法或业务逻辑的扩充性。比如:一级分销商年终返利的计算方法是A,二级分销商是B,三级分销商是C。如果规划时采用两层架构就能满足需求,我们会把算法放到数据库的存储过程或自定义函数中,达到提高扩充性的目标。如果规划时采用N层架构,那么我们一定要把业务算法或业务逻辑以组件的方式发布到应用服务器上,数据库中仅仅存放一个算法的影射,这样不仅可以提高系统的扩充性,还可以满足日后企业应用系统集成的需求。具体实现时会有一点难度,实践证明这样做是很值得的。

软件系统的灵活性

随着用户软件应用水平的不断提高,对应用软件可控度的要求也大幅度提升,在功能设计过程中应当对下面几点予以关注:

1. 自定义查询

说到自定义查询大家也许立即在脑海里呈现出一些字段、逻辑运算符、关系连接符和函数,把这些统统组合到一个窗口里面就形成了真正意义上的自定义查询。是这样吗?答案是否定的。尽管系统中确实提供了自定义条件的查询功能,但用户使用起来死板生硬,系统功能没有深度。

我们可以换一个思路: 首先把最常用的查询条件展现给用户,同时系统还支持上面所说的完全自定义,这样不仅在培训的时候使用户能够在较短时间内能够熟练应用,而且给用户预留了相当的发挥空间。

3.自定义汇总

由于用户的软件应用水平参差不齐,自定义在很多情况下会让用户手足无措,实际上用户最常用的汇总方式就那么几种,所以在设计时应将最常用的汇总方式以最直接的提供给用户(比如:放几个按钮或复选框),而后再提供自定义的汇总方式,既可以满足不同应用水平的用户,又可以使系统具有一定的应用深度。

4. 自定义报表

这个问题凡是做过管理信息系统的人都非常清楚,很多时候如果没有自定义报表用户会抱怨系统的灵活性太差,但是当我们把功能超强、费了很大精力开发的自定义报表提供给用户时,用户又会抱怨太复杂、无法掌握。究竟是为什么呢?主要原因是我们在规划功能时没有很好地分析软件的使用对象!如果拿着功能很强的自定义报表给系统管理员,他会感觉很不错;如果给一线操作员,他会觉得比较复杂,但是还比较实用,特别是以后领导临时要一些统计数字,可以立即提取出来;如果给领导,那肯定不会有好结果。因此,在规划设计时要将自定义的功能按照应用人员的岗位特点进行强弱划分,既不能大马拉小车,又不能小马拉大车。

软件系统的安全性

随着信息系统规模的不同,用户对系统安全性的要求也会不仅相同,在此仅对系统应用层面的安全性进行讨论说明。系统安全性可以划分为两种类型:控制权限、数据权限。

控制权限:即是否允许操作员执行某个功能(打开功能窗口、窗口控件是否有效)。我们较常用的权限分配方法是把系统的功能菜单以及功能窗口中的关键控件提取出来,供系统管理员进行权限分配。

数据权限:即是否允许操作员对数据进行浏览、增加、删除、修改、保存。这种权限分配方法越来越为用户所关注,也是应用软件的一种设计方向,即:让用户只看到、处理与自己有关的数据,这样可以最大限度地避免由于数据误操作引起不必要的麻烦和纠纷。

我们在进行设计时要充分考虑以上两种情况,实际应用过程中要与用户的实际业务真正结合起来,以利于系统管理员后期的日常维护。

综上所述,在管理信息系统的设计与实现过程中,除了要遵循大的原则和规范之外,还要关注很多细节问题,有些问题甚至不属于技术的范畴,只有这样才能够真正好用,实用的软件系统。

(计算机世界报 2005年08月15日 第32期 C15)

点赞