应用软件系列谈之二：艺高人胆大

应用软件系列谈之二：艺高人胆大 应用软件系列谈之二:艺高人胆大【2004-08-20 15:19】 【单美明】 【天极网】 “应用软件作为一种特殊的商品，不能像一般的商品那样可实现先期的样品展示。而顾客要付钱总得付得心里明白，放弃"用户别无选择"的假想，我们就得设法让顾客放心、又让 解决"的提供和逐步完善被认为是一自己不受损失。我们似乎已想了许多的办法，其中" 种与用户沟通和解决问题的好方法，但纸上谈兵的本质却越来越难以让用户放心地掏出钱来了。” 产品应用领域的细化使器具的制造商可以很专注地开展具体应用需求的把握，应用软件的生产商也希望生产出一种普遍实用于一个行业的东西，所以就有了"行业应用"的划分。 "商品化"的应用软件往往让用户感到蹩脚，因为应用软件商努力尝试以包罗万象的功能和强有力性能支持来生产出获得"行业"用户的普遍认同的"产品"，其结果是所提供的东西要么是画蛇添足的百宝箱，要么是哗众取宠的藏宝图，用户在领略了眼花缭乱的游戏式的功能操作迷宫后，没有付款的嗤之以鼻，付了款的大呼上当。 再回到这个问题:对于应用软件，开发者可不可以提出一种先根据用户要求生产然后再提交用户验收以决定付款的解决方式呢, 太多的经验会告诉我们，一个系统难以交付的最主要原因是用户对系统不会轻易认可，他们的业务处理要求太易变化、功能添加要求会无度增加，项目到了后期让人焦头烂额的原因似乎是开发者"对用户没有经济约束"。但排除了其它一些风险因素以后，如果你不从用户身上找原因的话，要回答这个问题，问题的关键就落在了开发者"能不能如期地、全面地满足用户真实需求"这点上来了。 这问题本身不太取决于给高手们看家的什么开发方法、什么架构、什么平台、什么工具等等实现技术。作为一个以实用为目标的东西，用户看重的是它的使用价值，而不是"技术含量"，技术和方法只是提供了一种实现的可能，不直接表现在目标上，立足于提高产品生产效益的"先进"技术的采用也不是"卖点"。 “我们公司前面有一项目，做的时候让约定三个月后试用决定要不要，再根据要求调整完善;再试用和培训2个月。先期商议一个总价，但不兑付，客户决定要时付40%，试用结束后付55%。因为我们的信心，所以项目出奇地顺利，而且那合同内约定的过程周期本身就是我们内的。” 这里更需要的是过程中目标的归纳、总结、确定和管理技术，因为其失误会对结果产生致命的影响。这一技术不是耍小聪明式的"创造"，是立足应用的需求发掘和目标落实。 要想得到用户的认可，得从提供给用户应用实惠方面下功夫。觉醒的用户会先对需求进行较为全面的概括，再逐步对其进行归纳和分析，最终确定自己完整的系统目标。这一过程一般会伴随系统开发的全过程，回避这一事实肯定是不可取的、而且是不负责任的，正确的方法应是与用户一道努力使目标完整实现。 现在来看看产品"目标"到底是什么。按照生产者基本出发点和着眼点的不同、目的要求的不同、对产品本身的认识理解不同，目标大体可分为三个层次。第一层，目标是最终实现一个可以与用户实现完整交易的产品;第二层，目标是按照用户需求完成的完整的应用系统;第三层，目标是提供给用户使用的全面支持其业务活动的灵活工作的工具集。 在第一层中，以商业化的模式理解应用软件产品，以商业运作方式去操作软件工程过程，其商业利益目标指导下的生产行为脱离软件产品本质，结果不仅是经济利益无法保证，更主要的是社会效益无从谈起，实际上就是一锤子买卖。 在第二层理解中，对应用软件有这样几个关键词:需求、完整、系统。所谓"需求"就是用户业务应用所需的功能、性能需要;所谓"系统"就是由一个个既相对独立又相互制约的"块"相互协作共同完成业务处理的统一体，其中包含着大量的时序和流的控制。这三个关键词合起来就是一句话:完整需求下的完整系统。然而，尽管有用户方大力的支持和开发方积极的努力，需求的完整性还是无法保证的，因为"需求"本身会随着项目进展、用户认识的提高和应用的发展而改变和扩展的，以静制动的"完整"规划需求只能是一个梦;同样的，系统本身作为一个有机整体从本质上已经制约了应用的灵活性和应用的扩展，系统内部越是联系紧密其扩展和灵活应用的空间越小，但不幸的是，紧密联系、有机协作正是"系统"的内涵，并常常被推崇。这样一来，扩展的难以实现，阻碍了对逐步认知的用户提出的需求调整和完善要求的实现，越想完整越是完整不了，越是强调协作越是牵一发动全身，这样的"系统"让其制造者在短暂的成功之后顾此失彼于无尽的擦不净屁股的疲惫之中。 按第三层理解将"完整的系统"看作"简单"的工具集，软件人一般是不认可的，但一旦将着眼点自愿地落实在支持用户一个个相对独立的业务处理操作上时，将系统的各"块"以灵活工具化的理念去和实现也就会顺理成章、水到渠成了。 用户的业务活动中，会有一些处理操作的数据来源牵扯到其它相关的业务结果数据，而且在时间顺序上有一定的制约，但大多数据操作是以源数据为依据的，与结果性数据并没有太严格的数据相关性，这就使我们有可能将"系统"的业务处理支持化整为零，分别进行规划和部署。在实现的方法层面上，所谓组件化开发正是力争让各自相对独立的应用分别实施得以实现，在技术支持层面上，面向对象、构件化为通用的更为小的"块"的规范和复用提供支持，这都有力保障了化整为零、分别实现的实施策略。在此，开发需求推动下实现技术进步的良苦用心可见一斑。 对于数据相关性较强的处理操作，充其量也只不过是多考虑了一下源数据是否已经存在而已。对于时间顺序性较强的操作间的协调，仍然可以归结对数据源的保证机制上，因为数据是处理操作的对象，是源、也是结果，那只要对数据标志进行检测，也就可决定本次操作的具体处理方式。 对于各个组成个体，所要考虑的更多的是友好性的体现方式，更趋成熟的一种高层次的理念是"人性化"的服务，这种服务实现的基础是生产者的素质修养。通俗一些讲，你所制造出来的东西会体现你的意识，带有你的灵魂和意志，将自己设身于很"低能"的用户，"用户"除了业务熟悉一些外，对计算机这神秘的东西很怯，那就考虑怎么才能让"用户"将"系统"的操作逻辑与业务逻辑轻松挂钩，并很快达到"熟练"操作的程度。 这里暂不讲需要在设计上使系统与业务本身相贴近，重点是每一操作处理过程中，在计算机规范逻辑与人的惯性思维逻辑的冲突点上，及时地给以准确、友好的操作指导。开发、特别是设计者们，往往以"高科技"意识将自己架空，除了什么编程工具、平台、架构等等的所谓技术，不屑于实用性的实际工作的真正落实。事实上，实用性的全面实现要比所谓"完整系统"的实现要难一些，这还需要一种理念、一种精神的支撑。 在统一设计、特别是数据设计的基础上，当一个"系统"化整为零后，就变为一个个由数据作为联接纽带的相对独立的个体了，我们就可将这种个体视同一个地地道道的工具了，其操作对象是数据，基本目标是实现对具体范围数据的具体业务处理，如果我们将数据的"范围"和"处理"方式扩展为由用户可选的，那就更接近于工具或用具的内涵了。个体的独立的功能范畴，可以让工具化的实现人员定向准确了解和把握具体需求、集中精力于松散联系的业务处理和紧密相关的数据操作的规划和实现。不仅如此，构件式的处理工具的调用机制会为其应用的灵活性增色不少，友好的交互界面会给操作者以"人文关怀"，在这方面你可以尽情地表现创造性发挥的崇高和伟大。 用户友好性在很大程度上表现为文字内容，遍布功能操作的各个角落的操作提示，是工具化个体的重要组成部分，其精髓远不只是操作的简单说明那么肤浅，除了在结构上体现操作的流畅以外，提示的方式、时机、准确性、易理解性等等，无不包含着目标要求和设计理念;用户文档、技术资料、应用引导、问题检索等等，其规模在整个系统开发工作中占有相当大的工作量，如果没有其指导应用的功用，除非是很小的系统，尽管我们在设计和实现上都力争实现易操作目标，应用的实现仍然几乎是缘木求鱼。 问题的本质还在于对目标的认识和在实现过程中的落实，出发点和实际工作切入点决定了目标结果的优劣。 作者系兰州信业信息技术有限责任公司 软件工程部经理 电脑软件www.9kuw.com