开发模型

IT行业直到现在，如何管理好软件项目还一直是大家讨论的话题，这是因为软件项目失败的太多。就中国目前很多软件开发团队的实际情况来看，从某种程度上来说，错误的使用和依赖两个软件来管理项目是项目失败的一个重要理由。

在一个软件开发组织中处理过程采用问题有合适的方法，也有不合适的方法。在本文里作者指出了一些常见的错误，即通常被看作是反模式（anti-pattern）,是由项目领导者在过渡到迭代开发方法时所造成的。

通常，坚定地相信迭代化方法的软件开发者必须为那些出于各种原因而坚持使用传统的瀑布方法理念的客户服务。本文就是讨论如何帮助那些人改变观念，转为使用Rational Unified Process。

Catalysis 以3个建模概念为基础，同时用框架来描述3个概念的之间的递归模式。

一个理想的迭代开发方法模型在很多方面与理想的瀑布开发模型有着根本上的不同。但是，从实际来说，没有一个团队严格的应用了每一种开发方法模型。本文解释了为什么开发团队决定逐步的从类似瀑布型的开发方法转变成更加类似迭代开发的方法，同时也概述了能够帮助这种转变的步骤。

在本文中，我们把极限编程（eXtreme Programming，XP）和敏捷联盟（Agile Alliance）里的一些合适的原则拿来，应用在建模领域。本文覆盖了敏捷联盟和XP的12条原则，并展示了它们是怎样适用于系统建模的，尤其是高可靠性（high-assurance）的系统。

FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发的一套针对中小型软件开发项目的开发模式。

最近一直在研究开发模式的改善，关注点有3个：Peer Review、代码评审和测试驱动。

微软产品周期模型是微软28年实际开发经验的精髓，微软的所有产品，从最初的产品策划到编程，Beta版发行，正式版本的发布，下一个版本的开发，都遵循该周期模型。微软产品周期模型是整个微软开发流程的核心和基础。微软开发团队模型是以“三驾马车”架构为核心的矩阵模型，合理的人员配置、合理的团队架构保证了团队成员各司其职，充分沟通，开发出符合用户需求的高质量产品。

传统的软件开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务（文档）后才能够进入下一个阶段。

测试驱动的编程是 XP 困扰程序员的一个方面。对于测试驱动的编程意味着什么以及如何去做，大多数人都做出了不正确的假设。这个月，XP 方面的讲师兼 Java 开发人员 Roy Miller 谈论了测试驱动的编程是什么，它为什么可以使程序员的生产力和质量发生巨大变化，以及编写测试的原理。

无论你遵从的是重量级的方法,比如Enterprise Unified Process(EUP)，还是轻量级的开发过程，如Extreme Programming(XP)，建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象Object Management Group (OMG)和IEEE这类组织的标准。

AM的实践之间是相互促进的，因为他们彼此支持，彼此激发。为了使AM更有效率的工作，你需要了解它的实践是如何组合的。图1显示了AM的实践之间的关系，它们被分为七类。AM的核心实践集中在头四种类别中－验证，迭代和递增，团队协作，和简单，你需要完全接受它们才能真正理解敏捷建模。然后，才轮到属于辅助实践的文档，动机，生产率这三个类别。我们先针对核心实践的四个类别，讨论各类中的实践之间的关系，然后我们再针对辅助实践的三个类别，研究各类中实践之间的关系，最后我们来讨论类别之间的关系。

DSDM（动态系统开发方法，也称业务中心框架开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效的进行系统开发。我们可以把DSDM看成一种控制框架，重点在于快速交付、并补充如何应用这些控制的指导原则的框架。

GOOGLE和其他大公司采用不同的研发模式，其研发模式是小组开发。这个研发模式可以说是GOOGLE目前最大的核心竞争力。这种研发模式诱发了不断的创新。但是很明显的一点是：这种研发模式只是适用于现阶段GOOGLE的模式，最终这种模式会被其他研发模式取代。

Granville Miller 暂时放弃需求收集主题，着手讨论另一个引人入胜的主题：子整体软件编程。 让我们找找这个方法如何补充和扩展灵活开发运动原则，以及它在主流开发界中的出现如何可能改变软件开发者的教育和软件开发实践。