[讨论]需求,设计,建模,您是如何走出泥潭?(来探讨一下开发中的实际问题)
列举几项,请大家畅所欲言
--请大家尽量以开发中的实际经验来说明,我将举一些本人遇到的问题,请提一些建议
1.您是如何挖掘需求的
用户并没有用过软件再加上交流的不正确,以致软件功能与用户想象的并不同。
2.您是怎样合理设计的
我认为设计的最大问题就是难以决断功能的耦合度,
从开发上讲-功能相互关联少,软件就易于修改与变更,不会牵一发而动全身。
从业务上讲-功能相互要有相当的数据及业务交流,软件才能达到相应的效果
3.您的数据库建模经验
数据库设计如何更何的服务于程序设计与开发,更便于后期维护
------解决方案--------------------关注
------解决方案--------------------楼主的问题覆盖面太大
------解决方案--------------------用户并没有用过软件再加上交流的不正确,以致软件功能与用户想象的并不同。
----------------------------
与用户交流的时候不要讲太多的术语,尽量采用启发式提问
------解决方案--------------------一直都在关注这个话题
和楼主有同样的问题
顶,mark
等高手
------解决方案--------------------您是如何挖掘需求的
说到需求,人们往往认为满足客户的要求就是完成了需求。其实所说的需求,并不是客户业务的完全重现,而是提炼与升华。将一个现实的业务,完全模拟计算机操作,没有必要,也不可能。在了解客户需求时,不仅想完成他们要求的,还要想到充分利用计算机的特点,结合与改变他们的业务逻辑,从更高层次上把握他们的潜在要求,简化他们的业务流程,提升他们的业务体验。这些才是真正的业务需求。只有你看得比他们更远,你的程序才不会在变化面前不知所,你的程序才不会因为需求变化而改得面目全非。
很多项目,负责人都以为自已明白了人家的需求,其实,他只是明白了人家怎么样去办业务,而不明白为什么要这样办。在这种情况下,程序设计出来以后,必定要大改特改。理由非常简单:客户在看完你的程序,用了两天以后,他们在思考过程中就会发现:“如果我们这样做,会更好”所以,业务需求肯定变。有人将这些归罪于客户,认为在提需求时不明确。这样是不对的,因为人家花钱请你,是为了满足要求,如果不能满足要求,人家也没有必要花大笔的钱来请你。
所以,你所做的,不是一个程序,而是一个业务,在这点上,你需要更象一个咨询公司,而不是一个软件公司。软件,不是过业务经过重组与结合之后的一个副产品而已。
------解决方案--------------------up
------解决方案--------------------支持。希望老手们都交流下经验了。我们新手多学习总结下了
------解决方案--------------------学习一下
------解决方案--------------------关注..
------解决方案--------------------1.您是如何挖掘需求的
用户并没有用过软件再加上交流的不正确,以致软件功能与用户想象的并不同。
---------------------------------------
需求挖掘是螺旋向上的,并且与用户交流,开始要少,慢慢增多。开始在你做基础构架的时候,不需要知道他们的具体业务,只知道他们大概需要做什么,牵涉到的几个概念以及流程。然后做一个设计,写出粗略的代码,并让代码得以运转。这个时候,class 很多,但是代码相当的少。如果class有100个,那么代码全加起来也不过3千行。好了,这就是基础,然后在这个基础上,可以与客户交流具体的东西了。把你的理解与客户对照,一定要让客户明白你这样划分的目的。然后客户对你进行反驳,你也反驳他,他反驳你,你反驳他,他反驳你,再根据交流的意见,对这些class进行重构。周而复始,直到永远。class里面,抛弃大多数方法,动态绑定数据,动态绑定class类型,增加帮助类,使用iterator或visitor,状态不开放,适当使用mediator。这样做,可以让你做的class,能真正的重用,便于修改。对接口编程,不要侠义的理解为接口就是interface。
2.您是怎样合理设计的
由 1 可以得知你的设计是否合理。
3.您的数据库建模经验
由 1 得到模型,然后根据数据库特点进行抛弃三个范式的行动。
------解决方案--------------------学习
------解决方案--------------------就4个字
日积月累
------解决方案--------------------看你选择MDA方向还是XP方向(XP好象是指敏捷开发吧)条件好可以选择前者,难度相当大,要求也不一样,不是一般程序员可以随便弄的。