如何进行软件设计——不断迭代

辛苦堆砌,转载请注明出处,谢谢!

最近工作,开始了新的软件设计,所不同的是,这次从需求对接开始的。之前的设计往往是已有的系统重新设计架构;有时是需求已经确定,已经进入正常的设计阶段;更有甚者,不进行需求分析,也不进行设计,直接开始开发,所谓的边开发边设计。可能我还能处理这种情况,但是具备设计能力的开发人员不多,寄希望于边开发边设计,真的是很有风险的。敏捷开发不建议重量级的设计,但不否认要对系统的关键点进行必要的设计。


那么,我们如何进行软件设计呢?


经过这一次的软件设计实践,我认为最好的软件设计都是一次次迭代的结果。软件开发讲求迭代,设计也讲求迭代,需求转化为设计,也需要迭代,一切都是迭代产生的。之所以这样说,个人的理解,主要是以下几个因素导致的。


需求提出者本身对需求也不是很清楚

我没有开玩笑,的确这样,需求提出者只有很笼统的需求,比如,我希望做一款电商使用的APP。他往往会忽略操作,忽略流程,忽略所有其他的,对他来说,他就要一款电商APP,但是这个APP包含什么功能?去问他,他会说,和其他电商APP一样就好了。这样的回答实际上没有给出任何有用的答案。


所以,需求的探究需要迭代,我们需要问他,你要什么,他会给你一些描述,你拿着这些描述,回去琢磨一下,会发现有一些会影响你的设计的因素,他并没有给出答案,然后我们需要再和他问一遍,你想做什么?然后加上我们的问题,他可能会发现,原来他当初没有考虑到这一点。一次次迭代,需求就会逐渐清晰。


有需求的人可能不懂开发

很多人有奇思妙想,但是他们并不具备开发能力。这些人可能会认为做这样一个软件很有前景,然后想找懂开发的人去做。这时候,我们在帮助他理清需求之后(一般理解到80%时),需要做的是出简单的原型,让他能够清楚这个东西我们可以做,但是我们需要他告诉我们做成什么样。


不过我的原型可能更简单,我不会构建整个系统,我会在技术难点和用户最期望的功能上下些功夫,做出一系列Demo,每一个Demo可以满足用户的一个功能需求。这些Demo我不会丢弃,他们之后会作为功能模块添加到我的产品中,但是我抛弃了界面的优雅,而重在功能的组织和架构。利用这些Demo我告诉需求方,我能做这些,同时我会配合一些简单的界面示意图,我说这个功能可以这样展示,让他提出意见,一同讨论,看看如何处理会更好。需求方必然会提出改进意见,但是你会发现,这个时候的改进意见往往是界面上的,但是这同时会引发他对功能需求的进一步思考,很有可能会引出非功能需求。


比如这段时间的软件,要求可以扫条码,我自以为需求方会有扫描二维码的可能,我就擅自添加了扫描二维码,但是使用时,无意中将二维码也扫上了,需求方就会说,我不希望扫条码被干扰,我会问确定永远不会扫二维码,他很确定地说是,那好,我们在我们的设计清单中把扫二维码功能去掉就好了,庆幸自己还没有开发。


我们的设计不会十全十美

谈完需求方的原因,说说我们自己的原因,人无完人,做软件我们不可能考虑到方方面面,任何我们自以为是的想法,都反而被需求方所忽略,反而我们忽略的东西,需求方可能更看重。就像我上面扫二维码的例子一样,自以为是往往自食苦果。


我们的设计一定要不断交给需求方看,界面的示意图,初始的功能Demo等等,需求方在看到这一系列东西时,一定会提出他自己的看法,我们要及时采纳,修改设计,然后再让需求方过目。


同时,在这个过程中,我们会看到自己设计忽视掉的问题,给了我们更多的弥补过错的机会,何乐而不为。


人的认识能力有限

人的认识能力是有限的,我们不可能想到所有,所以设计过程的不断迭代,就一层层加深了我们对系统以及自己设计的理解,这样,我们才能尽可能的减少开发中的风险,能够更好地评估开发的效率。


以上是我对软件设计的一些理解,可能有一些不太成熟,但是会随着以后的实践进一步提高自己的软件设计能力,到时候再和大家分享。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值