OA架构设计之启示
2004-09-09 22:34
295 查看
最近帮公司开发OA系统,由于是项目经理,所以参与了系统的架构设计。偶有感想,便付于纸面。
有何不妥之处还望各位指点。
第一:需求分析一定要仔细,越明确用户的需要越可能较好的把握架构的设计,因为需求确定软件架构。
第二:要从用户角度考虑各种与软件和软件架构有关的因素,这些因素是:
1)架构的简单性,这和设计机器设备时要保证结构简单(从而可以使用户简单维护,用户不懂机器设计!!)的原理是一致的。但是这也带来了简单复杂性,为何?打个比方:现代的pc体积很小,但结构上和第一台计算机大致一致,然而现在一般人都可以使用PC,而第一台计算机却要专业不能再专业的人使用。之所以现在人们可以轻松使用PC,是因为交互界面和硬件维护简单了。软件的架构也是这个道理,虽然看起来我们把它设计很简单,很容易维护,但开发人员不知道要为它多封装几层的功能代码!对用户而言简单了,对开发人员复杂了,但软件最终是给用户使用的,所以简单就是真理。这就是所谓的“有得必有失吧”。
2)适度性:有的开发人员愿意搞“完美主义”,什么都要最全最好,但是用户只需要那么点功能,而且用户只给你那么多时间和资源。然而有些开发人员将时间和金钱用在了用户不需要的功能上(国内的开发人员容易这样作),带来了项目的进度和成本的风险。很不划算!所以设计架构时我注意了必要的功能我一定集中精力设计,对于没有必要的我会考虑舍去。
3)适应性:用户的业务总在变化,所以要使用灵活的架构!设计模式将是一个较好的解决方法。
4)高内聚低耦合:这是老声长谈的问题,然而又有多少人做的好哪?
5)开发不能一步到位:人的思维模式总是从简单到复杂,然而有有些开发人员喜欢一步到位,上来就编代码!这样很会造成后期不断修改的结果,所以软件开发要从简单到复杂,不求一步到位。
6)要善用辅助工具:有的开发人员认为软件重用就是开发一个组件就可以了,但是方法重用哪?很多好的软件设计、开发方法被集成在如CASE,代码生成等工具中,然而很多开发人员不用,他们喜欢从零开始,但是我们开发软件目的是显示我们技术高超还是为用户及时地高质量的提供可用的软件?善用工具的人必定是善于理解用户需求的人。软件开发的目的性决定了开发人员应当有何行为,而非技术。
OA系统的最终目的就是使用户能够在一个平台上进行日常办公的所有工作,利用系统的快速和便捷来高效地完成工作,从而节省大量宝贵时间,如果不能完成这一功能就是个失败品。要做成一个成功的产品既难也容易。难的是如果不能很好理解客户的真正需求和办公中的详细业务流程,不但开发过程要及其缓慢,而且作出来的产品也不会被用户接收,容易的是只要与客户进行充分彻底地沟通就可以完全理解客户的详细需求,通过详细地分析设计就可以做成一个很好的产品,毕竟做OA系统不像开发系统工具那样困难。
以前只知道需求分析阶段与客户沟通的重要,其实在整个软件开发过程中无时不刻要考虑到用户,系统的分析,架构的设计以及编码、测试都要想到客户,从客户角度审视自己的工作,随时与客户保持联系。否则任何一个环节的失误都会导致系统的失败。希望能够看到后面具体的架构设计方法方面的内容。
有何不妥之处还望各位指点。
第一:需求分析一定要仔细,越明确用户的需要越可能较好的把握架构的设计,因为需求确定软件架构。
第二:要从用户角度考虑各种与软件和软件架构有关的因素,这些因素是:
1)架构的简单性,这和设计机器设备时要保证结构简单(从而可以使用户简单维护,用户不懂机器设计!!)的原理是一致的。但是这也带来了简单复杂性,为何?打个比方:现代的pc体积很小,但结构上和第一台计算机大致一致,然而现在一般人都可以使用PC,而第一台计算机却要专业不能再专业的人使用。之所以现在人们可以轻松使用PC,是因为交互界面和硬件维护简单了。软件的架构也是这个道理,虽然看起来我们把它设计很简单,很容易维护,但开发人员不知道要为它多封装几层的功能代码!对用户而言简单了,对开发人员复杂了,但软件最终是给用户使用的,所以简单就是真理。这就是所谓的“有得必有失吧”。
2)适度性:有的开发人员愿意搞“完美主义”,什么都要最全最好,但是用户只需要那么点功能,而且用户只给你那么多时间和资源。然而有些开发人员将时间和金钱用在了用户不需要的功能上(国内的开发人员容易这样作),带来了项目的进度和成本的风险。很不划算!所以设计架构时我注意了必要的功能我一定集中精力设计,对于没有必要的我会考虑舍去。
3)适应性:用户的业务总在变化,所以要使用灵活的架构!设计模式将是一个较好的解决方法。
4)高内聚低耦合:这是老声长谈的问题,然而又有多少人做的好哪?
5)开发不能一步到位:人的思维模式总是从简单到复杂,然而有有些开发人员喜欢一步到位,上来就编代码!这样很会造成后期不断修改的结果,所以软件开发要从简单到复杂,不求一步到位。
6)要善用辅助工具:有的开发人员认为软件重用就是开发一个组件就可以了,但是方法重用哪?很多好的软件设计、开发方法被集成在如CASE,代码生成等工具中,然而很多开发人员不用,他们喜欢从零开始,但是我们开发软件目的是显示我们技术高超还是为用户及时地高质量的提供可用的软件?善用工具的人必定是善于理解用户需求的人。软件开发的目的性决定了开发人员应当有何行为,而非技术。
OA系统的最终目的就是使用户能够在一个平台上进行日常办公的所有工作,利用系统的快速和便捷来高效地完成工作,从而节省大量宝贵时间,如果不能完成这一功能就是个失败品。要做成一个成功的产品既难也容易。难的是如果不能很好理解客户的真正需求和办公中的详细业务流程,不但开发过程要及其缓慢,而且作出来的产品也不会被用户接收,容易的是只要与客户进行充分彻底地沟通就可以完全理解客户的详细需求,通过详细地分析设计就可以做成一个很好的产品,毕竟做OA系统不像开发系统工具那样困难。
以前只知道需求分析阶段与客户沟通的重要,其实在整个软件开发过程中无时不刻要考虑到用户,系统的分析,架构的设计以及编码、测试都要想到客户,从客户角度审视自己的工作,随时与客户保持联系。否则任何一个环节的失误都会导致系统的失败。希望能够看到后面具体的架构设计方法方面的内容。
相关文章推荐
- OA架构设计之启示
- OA架构设计之启示 选择自 WarCo 的 Blog
- .net erp(办公oa)开发平台架构概要说明之表单设计器
- .net erp(办公oa)开发平台架构概要说明之表单设计器
- 迎接2012之三层架构简单设计
- [架构设计]第三讲:软件架构的目的
- 双机高可用、负载均衡、MySQL(读写分离、主从自动切换)架构设计
- web架构设计经验分享
- 高性能、高流量互联网应用架构设计实战原则
- web架构设计经验分享
- 如何设计架构?
- Hadoop分布式文件系统:架构和设计(zz)
- web架构设计经验分享
- 健壮且可读的安卓架构设计
- 架构设计:系统间通信
- 产品开发第一步-架构设计
- 又拍网架构中的分库设计
- 分布式会话跟踪系统架构设计与实践
- MySQL架构设计谈:从开发规范、选型、拆分到减压(转)
- 信息架构的设计思路