原型法思想搭建业务部门与IT部门沟通的桥梁.pdfVIP

维普资讯 发展论坛 Developm ent arum 原型法思想搭建业务部门 与IT部门沟通的桥梁 华夏银行个人业务部国际卡中心 吴俊涛 在银行应用开发中，经常会遇到这种现象：一方面IT 大。 人员抱怨业务部门提出的需求不明确或经常变动，造成系 此外 ，按照传统的基于结构化思想的软件工程生命周 统开发量增加甚至延迟上线 ；另一方面 ，业务人员又解释 期理论 ，需求讨论是周期的开始，具有提纲挈领 、为系统 说 ，应用的需求是在讨论与开发中才能逐渐明晰的，并且 边际定界的功能。IT人员也据此作为系统开发的方法论， 抱怨IT人员项 目管理不到位，在系统架构的设计上缺乏灵 过分强调需求的严谨性与稳定性 ，拒绝在开发过程中对需 活性 ，不能更好、更快地适应需求的变化。 求做出修改。 1．业务需求的有效性与系统建设周期之间矛盾的 2．原型法的特点和作用 原 由 如何避免上述情况的发生?在开发过程中，IT人员与 业务人员和开发人员因为角色不同，处理事务的出发 业务人员共同秉承原型法思想是解决这一问题的有效思路 点也不一样 ：IT部门希望按照需求 ，将系统尽快交付上 之一。 线 ，希望需求越明确、越稳定越好；业务部门一般根据激 原型法又称快速原型法(RapidPrototyping)，它首先 烈的市场竞争状况提出需求，尽管对系统 目标有着较充分 由系统开发人员与用户共同协商构造一个功能简单的原型 的理解 ，但在需求提出的初期，对如何实现 目标的细节却 系统，然后通过对原型系统逐步求精，不断扩充完善以得 不甚清楚或难以确定 ，特别是在有同业同时期推出类似产 到最终的软件系统。原型系统是应用系统的模型，可以认 品的时候，为了及时跟上并超越竞争对手所能实现的功 为是缩小比例的保留了大部分功能的实际系统，该模型在 能，需求不断修改、完善的情况更是难以避免。其结果往 运行中可以被检查、测试、修改、演化、迭代甚至扬弃， 往是业务部门与IT部门相互抱怨、拖延工期 ，甚至 因为 直到客户满意为止。因此，这个工作模型很快可以转换成 架构的局限性导致系统无法适应需求的快速变化，最终系 最终的 目标系统 。原型法需要建模理论 、软件重用技术、 统要么无法满足业务部门的需求，要么推倒重来 ，损失更 第四代可视化语言 (4GL)等理论或快速开发工具的支持。 56 国 国 话 阳卡 2oo8o5 维普资讯 DevelopmentForun 发展论坛囊豳豳翻 原型法的提出基于以下事实 ：开发人员难以保证其生 3．原型法在应用中需要注意的几个问题 产的软件是用户所需要的，用户也很难一次性把其真正的 (1)在系统的开发初期，IT人员不能要求业务人员 要求完全提交。用户在开始阶段提出的往往只是对系统的 立即拿出详细的最终版本的需求说明书。对于在开发过程 期望和比较模糊的设想而已。原型系统为用户提供了一个 中业务人员提出的需求修改建议，也不应以 “前期没有提 模型，用户参照模型就能进一步提出他们的真正需求。 出，现在无法修改”为借 口予以拒绝。IT人员要意识到， 原型法包括三个层次的工作。第一层，确定屏幕及报 大量的求精工作是必要的、不可避免的，甚至是应该加以 表的版式和内容，确定屏幕活动的顺序等。第二层，检验 鼓励的。系统开发部门同时要派 出经验丰富的系统分析人 数据库 的交互操作 ，主要 目的是论证系统关键 区域 的操