软件改造过程需要注意的问题

《软件改造过程需要注意的问题》由会员分享，可在线阅读，更多相关《软件改造过程需要注意的问题（7页珍藏版）》请在金锄头文库上搜索。

1、希赛软件工程专家网，软件过程改进/CMM/CMMI 评估平台，项目管理/软件测试资源站点 版权声明：版权声明：本文版权归希赛网软件工程频 道所有，未经许可，任何媒体均不得改变 其形式进行转载或摘录，违者必究！ 软件改造过程需要注意的问题软件改造过程需要注意的问题 谷剑芳 （中国人民解放军第 153 中心医院，郑州 450000） 摘要：摘要：任何软件系统都有其有限的生命期，随着软件所服务业务实体的各种变化：业务 范围变化、业务对象变化、组织结构变化、人力资源变化软件本身也需要适应这些变化 而进行改造。软件改造属于流程再造的范畴，与那些全新的信息化建设不同的是，软件改造 是在已有软件系统的基础上

2、，修改、完善设计软件结构，以适应新的业务流程。本文从四个 方面阐述软件改造过程中需要注意的一些问题。 软件改造是一个复杂的过程，这个复杂度，其一在于如何维持数据的延续性：由于在已 有系统的运行期间，已经积累了大量业务数据，而这些重要的数据无法完全丢弃，必须经过 整理继续使用；其二在于如何在旧的框架下设计出新的系统：由于是改造过程，以前系统中 的业务一些流程仍将被使用，这样一来如何解决保持新旧系统的运行、操作一致性，以及如 何在新系统中兼容已有的流程模式，是一个非常让人头疼的问题。 大凡涉及流程再造的企业，都希望以付出最小的代价，获得最大的成效。企业的领导往 往忽视再造过程中的复杂度，简单地认为

3、计算机能解决一切事情。对于软件改造任务的认识 不足，更增加了这其中的难度。忽视问题复杂的一面，必然导致时间、物质、技术上所给与 的支持不足。这就象盖房子，没有足够的钱还想盖高层，结果只能是个豆腐渣工程。软件工 程也一样，没有足够的支持，结果只能是一些没有用的面子工程。 问题摆在我们面前，那么如何在有限的条件下，把软件改造进行到底呢？除了寄希望于 企业高层给予更多的支持之外，还应当从以下几个方面注意改造过程的方法： 一、调整人力、轻装上阵 一、调整人力、轻装上阵 合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不同阶 段适时运用人员，恰当掌握用人标准。软件项目在不同阶段、不

4、同层次技术人员的参与情况 是不一样的。如人员配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定 人员配备方案时，在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情希赛网软件工程频道（http:/51cmm.CSAI.cn） 0731-8873047-8000， 第 1 页 希赛软件工程专家网，软件过程改进/CMM/CMMI 评估平台，项目管理/软件测试资源站点 况。 工作越复杂越需要精简工作队伍，在许多时候，人力越多并不定效率越高。就象一个全 副武装的突击队，可以迅速地穿越封锁线，在软件过程中有时我们也需要专家突击队。例如 在软件改造初期，通常是做业务流程的规范、改造

5、，并不涉及软件的深层开发。所以，为了 避免人力资源浪费，此时需要业务专家、系统分析师、项目经理，做需求分析和系统分析。 如果这个时候，让包括程序员、测试员在内的所有工程人员一起参与， 除了增加成本外，还 会形成混乱的局面。这软件开发中人力资源方面的问题，在著名学者 Putnam 的“软件开发的 权衡定律”1、Brooks 定律2以及著名的人件3中已经得到详细阐述。 越来越多的软件辅助工具，一方面为我们提供了全方面的帮助，同时也带来选择的困难。 即使在人的漫长一生中，我们也不可能精通所有开发工具或语言，所以在特定的开发项目中 我们必须轻装上阵。根据不同阶段的不同需要，仅选择最有用的和最有效的工具

6、，而无论这 个工具看起来是不是最流行或最时髦的。比如在系统设计的时候，需要的是业务专家提供准 确的业务分析和各种业务资料（图、表等数据） ，然后系统设计师利用简单的辅助工具（UML 工具）而不是复杂的设计工具，来进行初步的设计。我们常常会见到，设计师们一边听取业 务分析、一边记下简单的摘要，有时他们还会在翻阅业务资料的时候，画一些简单的流程图。 而在一些临时的会议场所，你会发现，即使是再轻便的笔记本电脑也比不上笔和纸在设计人 员手中的使用频率。 二、理清思路、简化结构 二、理清思路、简化结构 在软件改造过程中，往往先被已有系统的庞大和复杂看得晕头转向，当然这也正是为什 么我们不能在一开始就确定

7、新系统工作流程的原因。 由于软件改造任务的重点是改造而非重新设计，因此，就必须搞清楚已有系统中存在的 问题和缺陷。我们可以通过已有系统中的各种设计文档资料和实际操作调查，建立一个简单 模型。这个模型可以是一个演示文档，也可以是一份图文说明。总之要以最精炼的语言、最 直观的图表来体现已有系统，而无论它有多复杂。当然在描述模型时，要有功能、操作、数 据流程图，以及优缺点分析。除了系统模型，还需要一个系统分析，用来详细说明旧系统中 需要改造的地方，有了这些就可以结合新业务进行结构改造设计。 人有的时候，会很容易把事情做得复杂，尤其在对待一项复杂的事情时。而复杂的系统 并不意味着需要一个复杂的结构来支

8、撑，反而需要合理的结构、灵活的设计以及高效友善的 操作方式。尤其对于一个企业级的软件系统，其本身所服务的业务过程是复杂而繁琐的，而 软件的任务就是要变复杂为简单、变繁琐为直接。而已有系统不适应现有业务的问题，很大 程度来自于软件本身效率已经落后于企业业务发展。 我们必须剔除软件系统中那些看似合理、 周密的环环操作，摒弃那些复杂报表的层层嵌套、合并那些反复出现的提交与确认、删除那希赛网软件工程频道（http:/51cmm.CSAI.cn） 0731-8873047-8000， 第 2 页 希赛软件工程专家网，软件过程改进/CMM/CMMI 评估平台，项目管理/软件测试资源站点 些繁琐的警告，在保

9、证功能完整的前提下，简化结构设计、简化操作流程、简化交互模式， 让用户真正体验到软件所带来的高效与轻松。比如在面向对象的开发过程中，我们可以充分 面向对象的封装、继承、多态等特性和可复用构件技术，以及合理的设计模式，来实现对软 件结构的简化，使系统具有开放性、可扩充性、集成性的优点。 三、简化过程，轻量开发 三、简化过程，轻量开发 一提到开发过程，很容易想到各种软件设计文档。编写软件设计文档，为软件开发过程 的可靠性、稳定性提供了保证，也是应当提倡的方法。但是实际工作中，我们没有足够的时 间去编写完整的文档。仅仅靠编写代码又不能保证开发的完整性，那么如何保证开发过程的 科学稳定呢。由于软件改造

10、过程的复杂，轻量级开发是很重要的。在市场竞争的日趋激烈的 条件下，我们在开发的时候，无法再象以前那样有足够的时间去论证、研讨、开会。客观环 境要求我们必须不断降低开发成本、缩短开发周期，同时也要保证开发品质。轻量级的敏捷 开发方法，可以简化传统开发过程、提高效率。提到敏捷开发，我认为除了卡片和结对编程 之外，还可以通过设计一些能反映设计结构的表格，简化开发过程。比如在设计数据库时， 可以按照下面列举的表格形式进行表结构设计： 序号 字段名 字段注释类型长度是否为空说明 表名 存储特性说明 主键 外键 在进行模块化结构设计时，可以利用如下的表格来简单明了地说明新模型的设计方法： 1、模块与功能对

11、照 模块分类 子模块 功能描述 包含用户 备注 2、模块运行控制 模块分类 子模块 所使用到的表 3、模块与程序结构的对应 模块分类 子模块 包含的窗口对象 包含的数据窗口对象 模块分类 子模块 包含的用户函数 包含的用户对象 4、模块与时间特性要求 模块分类 子模块 对特性时间要求 5、用户权限与功能模块对照 人员分类 分类代码 希赛网软件工程频道（http:/51cmm.CSAI.cn） 0731-8873047-8000， 第 3 页 希赛软件工程专家网，软件过程改进/CMM/CMMI 评估平台，项目管理/软件测试资源站点 权限分类 级别 用户代码 包含菜单 菜单子项 别小看这些表格，这

12、是对整个程序框架的形象描绘，当然如果能够再补充一份接口说明， 那就完全不亚于一份详细设计说明书了。而且如果想要充分利用已有系统的设计结构，就必 须用简捷明了的方法建立清晰的框架。当然在各种条件允许的情况下，还是要写好软件设计 文档。 在轻量级开发方法中，还应当将迭代开发方法应用到开发过程中去。迭代开发，是通过 一系列细化，若干个渐进的反复过程生成有效解决方案的方法。采用迭代方法，不仅极大地 减少了项目中的风险，也帮助我们能够尽早地为用户提供可使用的版本。 四、图形驱动，快速建模 四、图形驱动，快速建模 对于一些运行了七八年的陈旧而庞大的系统，往往很难从繁琐的文字材料中建立业务模 型。那么就需要

13、从当前新的需求出发，首先建立新的业务模型。 建立业务模型的过程，首先是弄清楚系统的架构、流程，这些可以从需求分析中获得。 其次是深入分析，其次就是建立业务用例、业务实体、业务角色业务用例、业务实体、业务角色。确定业务角色，也就知道 的软件的使用对象、确定业务的使用边界。但是这个业务边界仍然只是一个框架，还不知道 其中到底有那些业务将被涵盖。这就需要确定业务实体，任何公司的业务都会随着自身或者 外部因素的影响而产生变化，而业务实体本身并不会随之改变。比如肯德基餐厅卖汉堡的业 务，并不会因为某一种汉堡不适合大众口味或是价格变化而导致这项卖汉堡的业务停止。要 想让软件系统达到稳定、灵活，就必须先确定

14、业务实体。软件若能提供准确、可靠的业务实 体，那么它的生命力就自然大大增强。有了业务实体，等于一个人的骨骼已经发育完整，那 么还需要丰富的血液给生命带来活力。这丰富的血液就是业务用例，业务用例说明了每一个 业务实体中的具体细节，是业务实体的实现。 使用 UML 工具建立业务用例是一种高效、准确的方法。通过 UML 定义的公共图形字符集， 可以化繁为简。将复杂的业务描述，用清晰直观的方式表达。比如肯德基卖汉堡业务和卖署 条业务，用 UML 可表达为： 当然可以用活动流程图更生动地说明某项业务是怎样进行的，如下： 希赛网软件工程频道（http:/51cmm.CSAI.cn） 0731-887304

15、7-8000， 第 4 页 希赛软件工程专家网，软件过程改进/CMM/CMMI 评估平台，项目管理/软件测试资源站点 图形方式的最重要的优点是， 通过绘图驱使技术人员把更多的注意力放在用户的需求上。 建立了业务模型之后，需要与原有系统进行对比。对比可按由面及点、从上而下的分层 顺序进行。首先是在业务实体间进行对比，分析总结出变化的方面。然后在业务用例层进行 详细的对比，这个比较是非常详细的。而且通过业务用例层的分析对比，可以得出整个软件 改造的技术级方案。在整个建模期间，充分利用图形驱动的优势，形成以 MDA 为指导的思想， 对于快速建模式十分有益的。 五、合理分层，均衡负载 五、合理分层，均

16、衡负载 由于技术认识上的不成熟，前几年许多单位所应用的数据库系统，大多以传统的 C/S 模 式的两层结构，即数据库层、客户交互层。但是随着业务流量的骤增和历史数据的不断增加， 这种传统的架构已无法承担 OLAP、OLTP 和大流量数据并发控制处理的能力。因此在改造系统 的时候，应该采用多模式下的三层结构：即灵活使用 C/S、B/S 模式，并将系统结构划分为表 现层、逻辑层、数据层。数据层，是指广义上的数据，可以是数据库、文本、多媒体等各种 存储信息；逻辑层定义了访问数据层的逻辑和接口；表现层是人机会话层，人们通过表现层 实现对数据层信息的访问。 三层模式的主要优点为： 1良好的灵活性和可扩展性。对于环境和应用条件经常变动的情况，只要对应用层实施希赛网软件工程频道（http:/51cmm.CSAI.cn） 0731-8873047-8000，infocs