最近在整理部门内部的培训材料，希望通过培训和在项目中的实践来提升整个团队的分析和设计能力，同时也是自己所了解的一点知识的总结。
谈到软件开发，一个项目的成败，关键因素是人的因素，人就是一切，或者说几乎是一切。对于项目的成功来所，项目人员的素质、人员的组织和管理是比其它工具或技术方法更重要。团队质量直接决定项目的成功和失败，团队的沟通能力，协作能力尤为重要，一个高效的团队一定是沟通能力很强的团队，我们所从事的软件项目，其实不是在研发新技术，而是利用别人的研究成果而已，只是成果的应用，说白了没有什么“纯”技术含量，这里纯加了引号，如今是个知识爆炸的时代，互联网高度发达，你需要什么信息，只要有时间，一般都能找到相关内容。所以说软件项目的开展，更侧重于社会性，而不是科学性。软件开发本身是一个复杂性活动，著名的“没有银弹”中介绍过，复杂性是软件开发的根本属性，短期内不会有任何的工具或方法会使软件生产率有数量级的提升。它是一个复杂的纯思维的活动，这个世界同时又成千上万个软件项目在开展，但是没有任何两个是完全一样的。相同的功能，可以有上百个实现，一个功能，可能用一个类实现，也可能5个、10个类，但是为什么是5个类，而不是3个，没有定型的优劣之分。只有掌握了合适的方法，总结前人的经验成果，研究较好的或经典设计，并在项目中实践应用，才能逐步提升自己的能力水平。
我们以往的项目中存在的问题，多是需求方面，没有掌握一个好的需求方法，程序大都是面向过程的，即结构化分析方法，或用着面向对象的工具干着面向过程的活。这和人员水平有着直接的关系。需求方面，怎樣挖掘用戶深層次需求？用戶所說的是不是就是對的？怎樣確認和驗證需求的正確性？有着一系列的问题。其实是有方法可以解决的。系统分析人员要了解甚至精通用户的业务领域，成为业务专家，但现实往往不是这样，那我们怎样验证需求呢？其实用户的目标有时用户自己都不是太清楚，系统分析员需要通过一定的方法引导用户，和设计人员一起帮助用户逐步地清晰目标，这本身就是一个迭代演进的过程，不是通过需求阶段完成后通过签署需求规格说明书就算完了的。我们可以通过原型，和不同迭代周期的产品，频繁的使用户参与反馈，强调用户的反馈和改写。在早期降低关键风险，最终提供用户想要的系统。
大家都知道，结构化分析方法在处理一些业务不是太复杂的系统时是快速高效的，但是很难处理高复杂性业务时就难以应付了，这样在后续维护上造成很大麻烦。这就涉及到了系统分析方法的问题了，面向过程和面向对象本身没有好坏之分，只有适合不适合，看你用在什么场合，本质都是我们认识这个世界的方法。这些技术都是重要的，但什么是面向过程?什么是面向对象?二者有什么区别?今天也不早了，我们在下次再讨论。
未完待续