首先明确一点，软件开发，其实就是把需求转化成代码。
基本流程：
需求->设计->代码（编码&测试）
理想：
理想的开发过程，应该是在上一步完全完成并经过确认后，再进行下一步。这样做，不同阶段可以被完整的分离。
我们要做的事情就变得简单了：让设计尽量符合需求，然后让代码尽量符合设计。
关于需求：
最原始的需求可能是模糊的定性的。这种需求无法产生精确的抽象的定量的设计。所以需要对需求进行分析，进行明确的定义。
需求是开发的基础，现在项目开发中的大部分问题都是需求不够明确清晰带来的。
制定需求就像定做一件东西。只说“我想要一件漂亮的可以在宴会上穿的衣服”，是没有任何意义的。制定需求的人，必须说出：肩宽多少？袖长多少？颜色是什么？要用什么材料？甚至其他一些更细节的问题。定的越细越准确，自然最后得到的东西也会越符合要求。
关于设计：
需求是给人看的，是没有结构，与计算机无关的。要想把它转化成代码，就需要有一个中间步骤。这就是设计。
设计的目的，是对需求进行处理，得到可以直接转化成代码的结构（数据结构，程序结构，目录结构等。。）。
设计的好，编码甚至以后的维护都会变得简单。
而不好的设计，可能无法完全反映需求，或者给实现带来困难。
关于代码：
最好的编码状态是：所有的思考和分析都已经在设计阶段结束，所有和需求有关的问题都不必考虑。写代码的时候只要小心不犯错。
现实：
需求的不稳定会影响设计，设计的模糊又会影响代码。所以导致的结果是，开发的三个阶段往往混杂在一起，以至于开发人员经常搞不清自己在干什么，应该干什么。所以最后得到的产品也难以令自己满意：即使它实现了所有预定的功能，实现的方式也不是最理想的。
想完全按照 需求 ->设计->代码 的流程进行开发，在现实中是不可能的。针对各种开发中可能出现的问题，人们想出了很多开发模型了解决。
瀑布模型：
其实就是原始的需求 -> 设计 -> 代码的模式，这个模型在需求变更频繁，时间 要求又很紧的现实中是难以奏效的。但是，假如面对的是一个需求稳定时间 充裕的项目，按照这个模型开发其实是最好的。
快速原型模型：
不断开发出产品原型，供用户评估，直到用户形成稳定的明确的需求。才进行实际 的开发，而之前的原型就被丢弃。
这种模型中，强调的最重要的技巧是快速开发产品原型。只有尽快尽好的做出原型 来（有时候甚至要做多个原型），才能又快又准的确定需求。
与其说是软件开发模型，我觉得这种方法说是挖掘用户需求的手段更为合适。
增量模型：
先针对用户最核心最稳定的需求开发系统，然后在这个系统上不断添加功能，直到 满足用户的所有需求。
这个模型中，最重要的技巧是设计：设计的系统必须可以方便的添加新功能，并且 添加的结构不破坏已有的结构。这对设计人员的要求很高，挖掘需求也必须准确 （要得到核心稳定需求）。
这种开发方式和快速原型模型的相同点：他们同样延长了确定全部需求所用的时 间。快速原型模型是把前期大量时间都用来确定需求。增量模型是确定一点需求， 就开发一点。剩下的需求之后再确定。
这样既能保证开发进度，又兼顾了需求。当然对系统设计的要求也就更高了。
还有其他一些混合模型：
其实都没有什么新意，就不说了。
从上面的模型可以看出，软件开发面临的最大问题，就是需求的模糊，不确定和延迟。
这个问题现在还不是技术性的（而设计和编码，相对来讲都是技术性的），只能靠沟通，反复询问等方式来部分解决。什么时候可以找到一种又快又好的方式确定需求了，软件开发也就简单了。
我们的另一个问题是缺少设计。设计大部分存在于开发人员的脑子中，并且是边写代码边想。这样得到的代码是很容易出错，很难以维护的。而且由于过早的开始写代码，脑子里的设计没有经过确认，所以也经常不能很好的对应需求。
我的想法是。
尽量推迟开始写代码的时间，把更多的时间都用在确定需求和设计规划上。甚至宁可花时间写注释，都不要写代码。等到把其他辅助的工作全做好了，最后再写代码。这样写出的代码，用意明确，便于维护修改。而且把重心放在需求和设计上，得到的最终产品质量也更好。
