最近在整理部门内部的培训材料,希望通过培训和在项目中的实践来提升整个团队的分析和设计能力,同时也是自己所了解的一点知识的总结。

谈到软件开发,一个项目的成败,关键因素是人的因素,人就是一切,或者说几乎是一切。对于项目的成功来所,项目人员的素质、人员的组织和管理是比其它工具或技术方法更重要。团队质量直接决定项目的成功和失败,团队的沟通能力,协作能力尤为重要,一个高效的团队一定是沟通能力很强的团队,我们所从事的软件项目,其实不是在研发新技术,而是利用别人的研究成果而已,只是成果的应用,说白了没有什么“纯”技术含量,这里纯加了引号,如今是个知识爆炸的时代,互联网高度发达,你需要什么信息,只要有时间,一般都能找到相关内容。所以说软件项目的开展,更侧重于社会性,而不是科学性。软件开发本身是一个复杂性活动,著名的“没有银弹”中介绍过,复杂性是软件开发的根本属性,短期内不会有任何的工具或方法会使软件生产率有数量级的提升。它是一个复杂的纯思维的活动,这个世界同时又成千上万个软件项目在开展,但是没有任何两个是完全一样的。相同的功能,可以有上百个实现,一个功能,可能用一个类实现,也可能5个、10个类,但是为什么是5个类,而不是3个,没有定型的优劣之分。只有掌握了合适的方法,总结前人的经验成果,研究较好的或经典设计,并在项目中实践应用,才能逐步提升自己的能力水平。

我们以往的项目中存在的问题,多是需求方面,没有掌握一个好的需求方法,程序大都是面向过程的,即结构化分析方法,或用着面向对象的工具干着面向过程的活。这和人员水平有着直接的关系。需求方面,怎樣挖掘用戶深層次需求?用戶所說的是不是就是對的?怎樣確認和驗證需求的正確性?有着一系列的问题。其实是有方法可以解决的。系统分析人员要了解甚至精通用户的业务领域,成为业务专家,但现实往往不是这样,那我们怎样验证需求呢?其实用户的目标有时用户自己都不是太清楚,系统分析员需要通过一定的方法引导用户,和设计人员一起帮助用户逐步地清晰目标,这本身就是一个迭代演进的过程,不是通过需求阶段完成后通过签署需求规格说明书就算完了的。我们可以通过原型,和不同迭代周期的产品,频繁的使用户参与反馈,强调用户的反馈和改写。在早期降低关键风险,最终提供用户想要的系统。

大家都知道,结构化分析方法在处理一些业务不是太复杂的系统时是快速高效的,但是很难处理高复杂性业务时就难以应付了,这样在后续维护上造成很大麻烦。这就涉及到了系统分析方法的问题了,面向过程和面向对象本身没有好坏之分,只有适合不适合,看你用在什么场合,本质都是我们认识这个世界的方法。这些技术都是重要的,但什么是面向过程?什么是面向对象?二者有什么区别?今天也不早了,我们在下次再讨论。

未完待续



posted on 2011-03-24 02:00  Jerry Tian  阅读(341)  评论(0编辑  收藏  举报