敏捷型方法是“一种适应性的方法”而非“可预测性的方法”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
任何一个软件开发人员都遇到过同样的问题，就是“项目的需求总是在变” 。传统的软件开发在项目开始的初期进行需求分析，尽量获得一份关于待开发系统的全面理解；在需求确定之后，则尽量限制需求的变化。需求的完全确定是非常困难的，因为需求是在变化的，而敏捷型方法则是采用了另一种方法来处理需求的不断变更，它的开发过程是随着需求的不断变化而变化的，它是一种适应性的过程，用自己的积极变化来适应需求的变化。需求的不固定，毫无疑问确定了软件开发是不可预测的。
敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。敏捷型方法试图使软件开发工作顺应人的天性，而不是让人去遵守各种各样的过程。
现在出现了不少的敏捷型方法，它们有许多的共同特征，但也有一些重要的不同之处。下面是当前比较流行的一些敏捷型方法：
w XP，极限编程。在所有的敏捷型方法中，XP最为瞩目。
w Crystal，水晶方法系列。
w FDD，功能驱动开发。
w ASD，适应性软件开发
w DSDM，动态系统开发方法。
w SCRUM方法
虽然每一种敏捷型方法都有各自的特点，每一种方法在具体实施过程当中有很大的区别，但是每一种方法都摒弃了以前那种繁琐的工作步骤和各种各样中间文档的累赘，能够对需求的变化作出快速的反应，项目不会在需求的迅速变化中死亡。
RUP是一个完整的软件开发过程框架，实际应用中，可以从RUP中派生出各种各样的开发过程，包括一些具有较短生命周期的小项目的开发过程和那些大的，分布式项目组的开发过程。因此，在使用RUP进行软件开发时，不能生搬硬套RUP规定的各种步骤和工件，必须针对自己项目的实际情况，从中派生出适合自己的开发步骤。
通过RUP过程的研究，并采取了敏捷型方法的思想结合UML建模机制，对RUP过程进行了适当的裁减，保留了RUP的特点,即仍然是一个用例驱动、以架构为中心、迭代的开发过程。对裁减后的RUP，我取消了原来RUP四个阶段的定义，只给出了一些工作流程和一些原则，并且结合了UML建模机制，合理的选择了UML中的各种建模元素。为了使得在实际应用中能够更好地理解与操作，将每个工作流进行了定位，即分别属于：需求、分析、设计、实现、测试，每一个工作流后括号中的内容即为该工作流的定位。为了描述法方便，对裁减后的RUP取名为RRUP(Reduced RUP)。
RRUP是一个不断迭代的开发流程，每一个迭代过程都需要经过下列步骤：
1. 找出系统的功能需求和非功能性需求，功能需求使用用例表示，非功能性需求，可以使用规定格式的文档表示；项目开始时，找出一些主要的关键的用例即可，其他次要的用例可在以后的迭代中补充，对这些主要用例的描述应该保持尽量简单，对用例的描述可以使用文档来表示，也可以使用UML中的建模元素来表示，本文在模型中，选择了UML中的活动图来表示。对这些用例要标明其重要程度，对那些影响系统架构的用例要标以很高的重要程度。(需求)
2. 为这些用例建立简单的系统初始模型(可多个)，可以使用用例图来表示。从系统整个初始模型可以看出一个用例是否得当；也可以根据初始模型来确定团队的开发进度；并且根据系统原型能够得到系统潜在的一些系统架构；能够这些系统架构中考虑选择一个最恰当的系统架构。(需求)
3. 找出待开发系统领域的类，第一次可以找主要的类；并定义个各类的主要职责和各类之间的关系，创建UML中的类图来表示；将类分为边界类、控制类和实体类这三种类，并为实体类之间的关系创建一个类图，以便为以后的数据库设计打下基础。(分析)
4. 编写整个项目全部迭代计划(只此一次)，每个迭代周期为1周～2周，迭代周期必应该过长。选择要进行迭代开发的用例，这些用例的开发周期不能超过迭代周期。迭代应该注意：
² 迭代计划内容应该包括迭代目标、人员安排、迭代时间表、存在的风险、可交付的迭代结果。
² 每个迭代期间按照需求，分析，设计，实现和测试来进行管理。
5. 将要开发用例所应有的功能和类结合起来，即用类的对象来表示用力所具有的功能；创建UML中的序列图或者协作图来表示；通过讨论验证修改序列图/协作图，在验证时应注意：(分析)
² 每个对象是不是还有别的操作,需要访问的数据。
² 整个序列图/协作图所反映的过程是不是正确的。
² 根据序列图/协作图来反映相应类的操作。
6. 如果某个类的对象，具有一些非常重要的状态，则为该类创建状态图，状态图中的事件,动作和行为最后会转化成相应类的操作。(分析)
7. 在设计的层次上加强上面两个步骤中确定的序列图/协作图和状态图，讨论是否还有别的操作和类所需访问的数据，定义实体类的属性，并开始进行数据库的设计。(设计)
8. 根据上面的工作，对类图进行细化与更新，在实体类不断精化的基础上，完成数据库的设计。(设计)
² 对每个类已存在的域进行细化，比如方法，应该确定它的名字，参数和返回类型。
² 增加新发现的数据类型，消息，方法。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>