关于软件开发---迭代开发
好久没有更新自己的博客了,感觉自己就是懒,不愿意动手去写东西,做更有意义的事。反省自己是该做些改变的时候了。
四月十号听说最近学校的SRTP项目要结项了,最近才赶紧的写了一个版本,虽说有很多不足的地方,可是自我感觉还是蛮不错的。虽然是短短的几天,可是整个开发的过程还是有很多体会的,就此发表出来,希望和大家交流。
软件开发的整体流程基本是需求分析--数据库分析--系统设计--编码与重构的循环--项目结束了。不过比较传统的瀑布式开发模式已经不适用潮流的发展了,敏捷开发的模式深入人心。在这个几乎谁都认为可工作的软件胜过面面具到的文档的时代,大家都把与用户的交流和迭代开发放在首位。只有与用户充分的交流,才能够得知用户的需求,才能了解用户需要的是什么东西,只有知道了用户需要的是什么东西,开发出来的软件才不会与用户要求的差之千里。
需求是第一步的工作,虽然说用户不能一次说出所有的需求,或者说用户在看到最后的软件之前其实并不知道他想要什么,即使用户知道这些,需求分析者和用户之间的理解也是有差异的。然而在进行编码之前设计是必要的,而且是必须的。虽然设计会在开发过程中会发生变化,会随着细节的凸显而演变,可是合理粒度、结构清晰的设计可以减少重构中的问题,使得开发过程出现的设计变更不会影响项目进度,甚至影响项目的成败。而设计是建立在需求的基础之上的,可见需求--设计--开发之间的任何一个环节出现问题,都会关系到项目成败。
怎样才能够合理把握三者之间的关系呢?“软件开发中最不会改变的就是需求永远是变化的”,还有一点就是“主要的功能需求变化最小”。所以首轮迭代开发实现需求中的最主要功能的设计和编码,拿出可工作的软件,然后和用户交流,让用户看到工作的成果,一会让用户对他们想要什么有更清晰的认识,二是对项目成员的工作的肯定,三能帮助需求分析师得到更全面的需求,设计师更好的把握系统。第二轮迭代时实现第一次迭代过程确定的主要需求,以此类推。这样整个的开发过程既有用户的参与,又有开发设计人员的配合,最终的到的软件必然是用户想要的。
迭代开发减少了用户投入的风险,降低了项目失败的风险,能够增强用户的竞争力,同时减少了开发的复杂度,增强了系统的易用可用性。
四月十号听说最近学校的SRTP项目要结项了,最近才赶紧的写了一个版本,虽说有很多不足的地方,可是自我感觉还是蛮不错的。虽然是短短的几天,可是整个开发的过程还是有很多体会的,就此发表出来,希望和大家交流。
软件开发的整体流程基本是需求分析--数据库分析--系统设计--编码与重构的循环--项目结束了。不过比较传统的瀑布式开发模式已经不适用潮流的发展了,敏捷开发的模式深入人心。在这个几乎谁都认为可工作的软件胜过面面具到的文档的时代,大家都把与用户的交流和迭代开发放在首位。只有与用户充分的交流,才能够得知用户的需求,才能了解用户需要的是什么东西,只有知道了用户需要的是什么东西,开发出来的软件才不会与用户要求的差之千里。
需求是第一步的工作,虽然说用户不能一次说出所有的需求,或者说用户在看到最后的软件之前其实并不知道他想要什么,即使用户知道这些,需求分析者和用户之间的理解也是有差异的。然而在进行编码之前设计是必要的,而且是必须的。虽然设计会在开发过程中会发生变化,会随着细节的凸显而演变,可是合理粒度、结构清晰的设计可以减少重构中的问题,使得开发过程出现的设计变更不会影响项目进度,甚至影响项目的成败。而设计是建立在需求的基础之上的,可见需求--设计--开发之间的任何一个环节出现问题,都会关系到项目成败。
怎样才能够合理把握三者之间的关系呢?“软件开发中最不会改变的就是需求永远是变化的”,还有一点就是“主要的功能需求变化最小”。所以首轮迭代开发实现需求中的最主要功能的设计和编码,拿出可工作的软件,然后和用户交流,让用户看到工作的成果,一会让用户对他们想要什么有更清晰的认识,二是对项目成员的工作的肯定,三能帮助需求分析师得到更全面的需求,设计师更好的把握系统。第二轮迭代时实现第一次迭代过程确定的主要需求,以此类推。这样整个的开发过程既有用户的参与,又有开发设计人员的配合,最终的到的软件必然是用户想要的。
迭代开发减少了用户投入的风险,降低了项目失败的风险,能够增强用户的竞争力,同时减少了开发的复杂度,增强了系统的易用可用性。
![Creative Commons License](http://i.creativecommons.org/l/by/2.5/cn/88x31.png)
本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名孙镜涛(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言。