系统设计与规划--一点总结

  有感于目前公司的一个项目产品中遇到的一些问题,结合着自己的设计与开发经历,总结一下系统设计与规划的必要性和知识点,作为将来设计的参考,也与大家一同探讨系统设计中要注意的各方面。

  产品简介:该产品是一个WebGIS系统,历经2-3年的开发与实施,目前准备从项目升级为产品,但是在项目实施中暴露出大量问题,使得实施人员和开发人员狼狈不堪,离产品要求还有较大差距,所以领导层意识到问题的严重性,要求进行改造,并让我做一些技术指导和设计上的把关。作为一个未曾参与开发的其它小组成员,以旁观者的身份进行观察,发现

  目前存在的一些问题:

  1. 系统功能不稳定,很多基本功能都会偶尔冒出问题,搞得实施人员提心吊胆,对产品没信心。
  2. 系统中出现一些低级错误,比如分页功能出错,上传文件的功能没有文件类型过滤...诸如此类,有失专业水准。
  3. 只支持IE浏览器,但对IE6和IE8不支持,只能强迫用户安装IE7,并且要用兼容模式浏览,使用很不方便。
  4. 因为不同项目的需求不同,客户的界面风格喜好不一样,所以为各个项目的修改和定制花费大量精力。
  5. 在修正客户所提的bug过程中,时常引入另外的bug,把原本好的功能弄出错误。
  6. 对运行环境的测试不充分,遇到64位操作系统或者英文版操作系统,就会出一些问题。
  7. 数据库限定太死,目前只支持ORACLE,且限定在特定的版本,如果使用ORACLE的RAC还会很麻烦。
  8. 部署太麻烦,手动执行数据库脚本,配置文件有好几个,每次换IP或者数据库发生变动,要手动替换好些字符串,最让人郁闷的是居然把URL地址记录在数据库表里。
  9. 没有运行日志记录,所以很难由客户提供运行的异常信息,只能自己调试。

  这样的问题其实一直都存在,只是以前我不知道罢了,但实施人员多次反映,客户也一直提出问题,依然得不到彻底的解决,使我更加迷惑。于是通过与开发人员和实施人员的交流,了解到造成困局的一些原因:

  1. 前期需求不完整,造成后期的变更频繁,开发人员难以应付。
  2. 数据库访问存在多种方式:JDBC, Hibernate和公司研发的访问组件。
  3. 最初的项目是在ORACLE上实施,所以一直以此为目标数据库,没有兼顾到其它数据库,也没有测试过RAC环境。
  4. 由于考虑到一些界面效果,使用了IE7上的特性,造成浏览器不兼容。
  5. 各功能模块之间的耦合度太高,相互依赖,所以牵一发而动全身,不敢轻易改动。
  6. 由于缺少测试人员,开发人员只能自己测试,但没有使用单元测试和自动化测试工具,也没有压力测试和运行环境的测试。
  7. 各个项目同时实施,开发人员身兼各个项目的技术支持和维护,版本维护和代码修改难免出现混乱。

  出现这样的局面,其实是多方面的因素:需求分析、过程管理、架构设计、代码质量等。但个人觉得,最主要的还是没有做好系统设计,缺乏整体规划,过早进入编码阶段,使得系统僵化,扩展能力不足,无法灵活应变。所以我才想到了系统设计规划这样一个主题,这个主题也没有什么明确的定义,个人理解是对软件产品和项目的一个分析和评估,考虑系统所涉及的几个重要方面,并做好相应的准备,但不涉及解决方案的细节。同时,系统设计规划也不同于架构设计和详细设计,个人认为后两者更偏向于业务逻辑的分层和模块组织,以及核心类设计,更偏向于业务和代码实现。根据个人的设计经验,对系统进行分析和评估应该考虑以下几个因素:

  1. 技术选型
  2. 分层设计
  3. 数据库设计
  4. 技术难点
  5. 技术标准与行业规范
  6. 性能设计
  7. 测试设计
  8. 调试设计
  9. 安全设计
  10. 部署设计

  在这所列的10个因素中,前5个是经常涉及的,也是考虑的较多的,但后5个可能考虑的不多。这些因素,每个都是一个很大的主题,背后都有很深的理论知识和丰富的实践素材,没有人能给出一个统一的解决方案。所以,我这里只是用图表的形式进行划分,并列举出每个主题的相关内容和关注点。每个关注点背后也都涉及到很多知识,在系统设计时,需要结合着自身的开发实际和需求进行取舍,并找到适当的应对策略。总之,我的目的是希望在系统设计之初,做好宏观的分析和把握,制定出合适的解决方案,使得系统从容应对后期的需求变更和代码维护。

  上图所列内容完全来源于个人经验,定有许多不足之处,还望补充和指正。

it知识库系统设计与规划--一点总结,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。