粗说开发流程

关于软件开发过程可以给大家做一个简单介绍，主要是一些概念和自己的一些感受：
首先要说明的是：所有的软件开发流程都是一个方法论范畴的问题，要根据自己的实际要求进行选取和剪裁，不要完全照搬。它不是法律法规，只要很实际开发相结合才可能发挥其真正的作用。
第一个要介绍的就是瀑布开发方式，这是一个最早的开发流程，在70年代的软件危机的时候是他解决了很大的问题，它的特点是严格规范了开发流程，就是，调研（做需求），设计（概要设计、详细设计），实施（编码）、测试，安装使用（给用户上线），基本流程是这样。但它的缺点很明显，就是各阶段不可回朔。如果在一个非常严格的环境中，使用这个开发方式是很好的，听说日本人一直在使用这个开发流程，而且效果不错，这和他们的工作习惯和生活习惯有关，在做事情认真的问题上，我是很敬佩他们的，但我不喜欢日本人（当然这是另外一个话题）。
第二个是改进瀑布方法，就是各阶段可以回朔，如果调研没有作好，就进入了设计阶段，并且发现了问题，那么好，重新进入调研，改正错误，在进入设计，这是针对瀑布方式的一个改进。其他的方面变化不大。个人认为。我们的很多单位的基本开发方式都是这样。如果真能做到良好的实施，也是很不错的，但我们的需求总是做的很烂，所以无论是瀑布还是改良瀑布方法实际情况都不是很好（说一个问题，很多方法本身是有问题，但我们总是将自己开发 的问题简单归为开发方式的不好上，这不是一个认真的态度，以后有机会可以说这个问题）
第三个。快速模型法，该方法的特点是针对需求难做，主要解决这个问题。需要开发人员和客户交流，了解需求，这和上边的两个方法一样，改变的是，在很短的时间内作出第一个系统。该系统和以后真实的系统功能完全相同。从某种意义上说，用户在很短的时间内就可以看到系统了，但这个系统一般是不可运行的（一个demo），最起码是功能不全的，做这个版本的主要目的是用户可以使用这个demo，说明自己认为那里是合适的，那里是不对的，然后开发人员做第二个版本。这样循环几次，需求基本稳定，用户也知道以后的系统是什么样子。比较放心，开发人员对需求调研也比较放心。有几个问题，一个是开发人员需要有良好和客户交流的能力，而且要有很强的开发能力，可以迅速做demo（这不是一个很容易的事情），虽然采用这个方法可以确定需求，但一般的调研问题仍然会出现。所以不要认为使用这个方法，就可以完全解决调研问题，（请大家注意），后边的开发方法是一样的，就不多说了（模型可以采用改进继续发布形成增量开发，也可以抛弃，重新设计）
第四中快速应用法RAD。强调极短的开发周期。包括业务建模，数据建模，处理建模。应用生成。测试很反复。软件的复用性对它很重要。但不适合技术风险比较大的系统，另外客户的参与很重要。我自己的感觉，这个方法其实是将设计分解了，使一个复杂的问题分解为若干小问题，而且每个问题又分成几个步骤来解决，这样降低了风险。一般的信息系统使用他比较合适。
第五个。螺旋模型，引入了增量开发的概念。将一个大任务分为若干小任务，每个任务都有：用户通信（就是调研），计划（开发计划的定义），风险分析，工程，建造和发布（这实际就是设计和开发还有测试），用户评估六个标准阶段，但实际可以根据需要裁减这六个阶段，我的感受，如何划分任务实现增量开发是最重要的，也是最困难的，要有比较高的水平，其他的主要将项目管理的很多概念引入了这个模型，实际很多情况用不上的，比如风险评估一般开发人员根本用不上。另外该模型是全生命周期模型，也就是说要到软件不再使用的时候才结束，和其他的模型有一些区别，另外该模型被使用的程度不高。
第六个形式化模型，估计我这里没有人使用他。最有名的净室工作法。特点是用数学的方法来表示体系结构的说明、开发和验证，什么盒式规约。集合和构造性规约，一个头两个大，劝大家别玩这个，那时数学家玩的东西。
Xp又叫极限开发。特点,游戏规则，配对开发，测试先行，轻量级的文档等24个特点
不好的地方，往往是开发人员用来说不写文档的借口，但别忘了，人家是在统一的框架上编写的，这个框架可是一个文档，另外，要反复重构，这可也不是好玩的事情。

关于产品线的问题这回系统分析员考试的一个题目就是这个：简单说一下四个条件
1有深厚和长期的行业知识
2有良好的产品架构
3有一个核心资源库
4有好的环境支持。环境，资源、项目管理、资金等。