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

　　产品简介：该产品是一个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知识库：系统设计与规划--一点总结，转载需保留来源！

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