软考高级之系统架构师系列之软件开发模型
概述
如标题所述。本文面向于软考高级，具体来说是系统架构师。
本来几乎是纯粹的理论知识汇总，用于应付软考，在理解基础上注意抠字眼。
软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程，叫软件生存周期模型，又叫软件开发方法、软件开发模型（software develop model）、软件过程模型 （software process model）
| 分类 | 描述 |
|---|---|
| 结构化法 | 强调用户至上，严格区分工作阶段，每阶段都有任务和成果，强调开发过程的整体性和全局性，开发过程工程化，文档资料标准化，自顶向下逐步求精 |
| 原型法 | 适用需求不明确的开发，分为抛弃型原型和进化型原型 |
| 面向对象方法 | 更好的复用性，关键在于建立一个全面、合理、统一的模型 |
| 面向服务方法 | SOA方法有三个主要的抽象级别：操作、服务、业务流程。 SOA分为三个层级：底层服务构件、服务接口与协议、服务流程编排。 服务建模：分为服务发现、服务规约和服务实现三个部分 |
软件开发模型
大体来说，有3类：
- 软件需求完全确定为前提，可以采用瀑布模型；
- 软件开发初期阶段只能提供基本需求，可以采用迭代式或渐进式模型，如喷泉模型，螺旋模型、统一开发过程和敏捷方法、极限编程。开发人员对算法的效率，操作系统的兼容性和人机交互的形式不明确等情况下，快速原型开发
- 形式化为基础的变换模型
瀑布模型
特点：
阶段间具有顺序性和依赖性，前一阶段结束后才能开始后一阶段的工作，前一阶段的输出是后一阶段的输入；推迟实现观点，尽可能推迟程序的物理实现；强调质量保证观点，每个阶段必须完成规定的文档，每个阶段结束前完成文档以便及早改正错误。
瀑布模型可以说是最早使用的软件生存周期模型之一。由于这个模型描述软件生存的一些基本过程活动，所以它被称为软件生存周期模型。这些活动从一个阶段到另一个阶段逐次下降，形式上很像瀑布。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。
每一个阶段都是建立在前一个阶段的正确结果之上，前一个阶段的错误和疏漏会隐蔽地带入后一个阶段。这种错误有时甚至可能是灾难性的，因此每一个阶段工作完成后，都要进行审查和确认。
优点：
- 原理简单，容易掌握
- 各阶段间都有验证和确认环节，以便进行质量管理
- 主要用于支持结构化方法
缺点：
- 缺乏灵活性，不能适应用户的需求变化
- 缺乏演化性，返回上一级的开发需要付出十分高昂的代价
- 是线性的软件开发模型，回溯性差
适用场合：
- 适合于软件需求比较明确或很少变化，且开发人员可以一次性获取到全部需求的场合
- 适合开发技术比较成熟，工程管理比较严格的场合
- 一般用于低风险的项目，适合开发人员具有丰富的经验
原型模型
又称快速原型模型，是快速建立起来的可以在计算上运行的程序，是软件的一个早期可运行的版本，它的功能是最终产品的子集。用途主要是获取用户的真正的需求。
原型模型主要有两个阶段：
- 原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等
- 目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统
优点：
- 增强开发者于用户间的交流，有助于满足用户的真实需求
- 用户可及早得到有用的产品，可及早发现问题，随时纠正错误
- 减小技术、应用风险，可降低开发费用，缩短开发时间
缺点：
- 缺乏丰富而强有力的软件工具和开发环境
- 对设计人员及开发环境要求较高
- 难于做到彻底测试，更新文档较为困难
适用场合：
- 预先不能确切定义需求的软件系统，或需求多变的系统
- 开发人员对设计方案没信心或对将要采用的技术手段不熟悉或把握性不大
- 原型模型可作为单独的过程模型使用，也常被作为一种方法或实现技术应用于其他的过程模型中。
原型是软件系统的初始版本，用来演示概念并尝试设计选择，通常用来发现更多的问题和可能的解决方案。快速迭代式的原型开发能够有效控制成本，根据原型与最终产品之间的关系，原型开发分为三类：
- 抛弃式原型开发利用原型验证和澄清系统的需求描述，重新构造系统
- 演化式原型开发逐步改进和细化原型，将原型进化直至产生出目标系统
- 增量式原型开发在建立软件总体设计的基础上，采用增量开发方法，使原型成为最终系统
渐增模型
也叫增量模型，其实质上是分段的线性模型，是一种非整体开发模型，渐增模型把软件产品作为一系列增量构件来设计、编码、集成和测试，在项目开发过程中以一系列的增量方式来逐步开发系统。
优点：
- 可分批次提交软件产品，方便用户及时了解软件开发进展情况，及早发现问题
- 以组件为单位进行开发，降低软件开发风险
- 开发顺序灵活，优先级最高的服务首先交付
缺点：
- 由于对整个软件系统的需求没有一个完整的定义，会给总体设计带来麻烦。
- 在把每个新的增量构件集成到现有软件结构中时，必须不破坏原来已开发出的产品。
- 软件的体系结构必须是开放的，即向产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是可测试的，可扩充的。
适用场合：
- 软件产品可以分批次地进行交互
- 待开发的软件系统能够被模块化
- 软件开发人员对应用领域不熟悉、难以一次性地进行软件开发时
- 项目管理人员把握全局的水平较高时
- 对软件需求把握不准确、设计方案有一定风险的项目
喷泉模型
喷泉一词体现迭代和无间隙特性，迭代是指开发软件系统时，某些部分经常要重复多次，相关功能在每次迭代中随之加入演进的系统。
特点：
- 各阶段相互重叠，反映软件过程的并行性
- 以分析为基础，资源消耗呈塔形，在分析阶段消耗的资源最多
- 反映软件过程迭代的自然特性，从高层返回低层无资源消耗
- 强调增量开发，依据分析一点设计一点为原则，不要求一个阶段完成，整个过程是一个迭代的逐步提炼过程
螺旋模型
螺旋模型是在结合瀑布模型与快速原型模型基础上演变而成，加入风险分析。
软考很恶心的地方在于抠字眼（单选题）：
- 有瀑布和原型两个选项，选择原型
- 有快速、原型、瀑布三个选项，选择快速
其基本思想，使用原型及其它方法来尽量降低风险。沿着螺线进行若干次迭代。
两个显著特点：
- 采用循环的方式逐步加深系统定义和实现的深度，降低风险。
- 确定一系列里程碑，确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案。
在螺旋模型中，将软件过程表示为一个螺旋线，在螺旋线上的每一个循环表示过程的一个阶段。整个过程的实现按以下四个步骤完成：
- 指定计划：即目标设定，为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划
- 风险分析：对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险
- 工程实施：即开发和有效性验证，风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品
- 客户评估：即评审，对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。
适用场合：
- 适用于面向规格说明、面向过程和面向对象的软件开发方法
- 也适用于几种开发方法的组合和产生的组合模型
缺点：
要求开发人员必须具有丰富的风险评估经验和专门知识
形式化方法
形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。
主要优越性：能够数学（精确）地表述和研究应用问题及软件实现。
但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难以为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。
净室软件工程
Cleanroom Software Engineering，CSE。
软件开发的一种形式化方法，使用盒结构规约（或形式化方法）进行分析与设计建模，并将正确性验证作为发现和消除错误的主要机制，采用统计测试来获取验证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，以及使用基于数学的正确性来证明对设计模型的每个元素进行形式化验证。还强调统计质量控制技术，包括基于客户对软件的预期使用测试。
由三大关键技术来刻画：统计过程控制下的增量开发，基于函数的规范、设计和验证，以及统计测试和认证。
UP/RUP
统一过程开发模型，另起一篇，参考软考高级之系统架构师系列之RUP、4+1视图、JAD、JRP、RAD。
RAD
结构化方法
结构化分析方法，是一种面向数据流的需求分析方法，其基本思想是自顶向下逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决。结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型：数据模型、功能模型和行为模型（状态模型）。在实际工作中，一般用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。
数据流图是进行结构化分析时所使用的模型，其基本成分包括数据流、加工、数据存储和外部实体。在进行结构化设计时，通过对数据流图进行变换分析和事务分析可以导出程序结构图。
结构化分析
结构化分析是结构化方法的重要组成部分，一般要依次进行以下工作：
- 目标分析：系统目标是指系统在开发完成后所应达到的境地或标准。
- 环境分析：环境分析可分为对内部环境的分析和对外部环境的分析两方面。环境分析着重于对较宏观的情况的了解，并不过分要求某些细节问题和情况。
- 业务分析：业务或业务活动是对企业或机构的一切专业工作和活动的总的称呼。一般都是将企业业务或业务活动按性质划分，并由若干机构来进行管理。业务分析应该从业务调查入手，首先了解企业的组织结构、绘制组织结构图，从与企业生产经营直接相关的机构开始，进行业务流程的调查，并绘制成业务流程图，并逐步扩展到系统边界内的其他机构。
- 数据分析：数据分析的主要内容为数据流程图和数据字典。
- 效益分析：衡量信息系统效益的第一标准应该是系统是否投入使用，因为再好的系统如果放置不用，那就等于没有。而使用了的系统，成功与否取决于其效益。
- 逻辑模型的建立：逻辑模型即信息系统的功能模型，描述系统的总体构成、子系统划分和子系统的功能模块，并包括各子系统的业务流程和数据流程以及相关的数据定义和结构。
- 系统分析报告：一个完整的计算机信息系统的分析报告应包括3个部分，一部分是应用分析；其次是系统的运行平台，它是针对应用所应提供的软件和硬件条件以及它们的结构和配置的分析；最后是系统对网络和通信的要求。3个部分是相互联系和密切相关的。
结构化设计
结构化设计是以结构化分析的数据模型、功能模型和行为模型为基础，完成数据设计、体系结构设计、接口设计和过程设计。
数据设计
数据设计是把分析阶段创建的信息域模型转变成实现软件所需要的数据结构。可使用Jackson图来表示。
Jackson图和描绘软件结构的层次图形式相近，但是含义却有很大不同：
- 层次图中的一个方框通常代表一个模块；Jackson图中的一个方框并不代表一个模块，通常只代表几个语句；
- 层次图表现的是模块的调用关系；Jackson图表现的是组成关系。
Jackson图示例：
体系结构设计
体系结构设计确定程序的主要结构元素（即程序构件）之间的关系
。可使用HIPO图和Yourdon提出的结构图来表示。
HIPO图
Hierarchy plus Input-Process-Output，层次图加输入/处理/输出图，IBM公司发明。
层次图使用矩形框表示一个模块，用框间的连线表示模块的调用关系。如下图所示：
HIPO图在层次图里把除了顶层的方框之外的每个方框都加上编号，然后再使用一张IPO图描述这个方框代表的模块的处理过程。
IPO图的基本形式是在左边的框中列出输入数据，在中间的框中列出数据处理，在右边的框中列出输出数据。如下图所示：
或者可使用IPO表来表示：
结构图
结构图和层次图类似，也是用一个方框代表一个模块，在框内注明模块的名字或主要功能，用方框之间的箭头（或直线）表示模块的调用关系。同时，在结构图中通常还用带注释的箭头表示模块调用过程中来回传递的信息，并且用注释箭头尾部的形状来区分数据信息和控制信息：尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。此外，还可以使用一些附加的符号表示模块的选择调用或循环调用。结构图示例：
接口设计
接口设计的结果描述软件内部、软件与协作系统之间以及软件与使用它的人之间的沟通方式。接口用于传递数据，数据流图提供接口设计所需要的信息。
过程设计
过程设计把程序体系结构中的结构元素，变换成对软件构件的过程性描述。过程设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。
过程设计工具有很多种，包括图形、表格和语言3类。
程序流程图
程序流程图又称为程序框图，最熟悉、使用最广泛的工具。但由于程序流程图有很多缺点，如：诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构、不易表示数据结构等，所以很多专家都建议停止使用它。
盒图
Nassi和Shneiderman提出的盒图（N-S图）就是一种不允许违背结构程序设计精神的图形工具。
使用盒图可以很容易实现以下目标：
- 程序员在进行设计时必须符合结构设计原则，而不能随意转移控制
- 可以很容易地确定局部和全程数据的作用域
- 可以很容易地表现嵌套关系
盒图的基本符号如下图：
判定表和判定树
判定表能够非常清晰地表示多重嵌套的条件选择关系。
一张判定表由4部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。如下图所示：
但是当条件变得更多时，判定表会显得很复杂，不够简洁。这时可以使用判定树。
判定树是判定表的变种，以树枝的形式表示复杂的条件组合与应做的动作之间的对应关系。如下图：
判定树比判定表更直观，但简洁性却不如判定表。但是当数据元素的同一个值往往要重复写很多遍，而且越接近树的叶端重复次数越多。
过程设计语言
过程设计语言（Program Design Language，PDL）也称为伪码，它使用一种语言（通常是某种自然语言）的词汇，同时却使用另一种语言（某种结构化的程序设计语言）的语法，以表示数据和处理过程。
构件开发模型
软件构件是软件系统中具有一定意义的、相对独立的可重用单元。与对象相比，构件可以基于对象实现，也可以不作为对象实现。构件需要在容器中管理并获取容器提供的服务；客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。
软件构件是部署、版本控制和替换的基本单位。构件是一组通常需要同时部署的原子构件。原子构件通常成组地部署，但是它也能够被单独部署。构件与原子构件的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。一个模块是不带单独资源的原子构件。
构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行封装，同时对各种业务逻辑规则进行实现，用于处理用户的内部操作细节。构件是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能软件工程中的构件模块、软件框架、软件构架（或体系结构）、文档、分析件、设计模式等。
系统构件组装分为三个不同的层次：定制（Customization）、集成（Integration）、扩展（Extension）。
这三个层次对应于构件组装过程中的不同任务。
构件的特性：
- 独立部署单元
- 作为第三方的组装单元
- 没有（外部的）可见状态
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。构件的部署必须能跟它所在的环境及其他构件完全分离；构件作为一个部署单元是不可拆分的；在一个特定进程中只能存在一个特定构件的拷贝；对于不影响构件功能的某些属性可以对外部可见。
对象的特性：
- 一个实例单元，具有唯一的标志
- 可能具有状态，此状态外部可见
- 封装自己的状态和行为
基于可重用构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段髙效率、髙质量地构造应用软件系统的过程。基于构件的开发模型融合螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建、测试和发布5个阶段组成。
在基于构件的软件开发中：
- 逻辑构件模型：用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能
- 物理构件模型：用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
COP
面向构件的编程（Component-Oriented Programming，COP）关注于如何支持建立面向构件的解决方案。基于一般OOP风格，面向构件的编程需要下列基本的支持：
- 多态性（可替代性）
- 模块封装性（高层次信息的隐藏）
- 后期的绑定和装载（部署独立性）
- 安全性（类型和模块安全性）
面向构件的编程仍然缺乏完善的方法学支持。现有的方法学只关注于单个构件本身，并没有充分考虑由于构件的复杂交互而带来的诸多困难，其中的一些问题可以在编程语言和编程方法的层次上进行解决。
流派
构件模型是对构件本质特征的抽象描述。已形成三个主要流派，分别是OMG的CORBA、Sun的EJB和Microsoft的DCOM。这些实现模型将构件的接口与实现进行有效的分离，提供构件交互的能力，从而增加重用的机会，并适应目前网络环境下大型软件系统的需要。
CORBA
OMG，Object Management Group，对象管理组织，一个国际性非盈利组织，其职责是为应用开发提供一个公共框架，制订工业指南和对象管理规范，加快对象技术的发展。
CORBA，Common Object Request Broker Architecture，公共对象请求代理体系结构，通用对象请求代理架构是软件构建的一个标准。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制。由于独立于程序设计语言和特定ORB产品，一个CORBA对象的引用又称可互操作的对象引用（Interoperable Object Reference）。从客户程序的角度看，IOR中包含对象的标识、接口类型及其他信息以查找对象实现。
CORBA构件模型
- Object Adapter：对象适配器，用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。在底层传输平台与接收调用并返回结果的对象实现之间进行协调。目前采用的对象适配器规范是POA（Portable Object Adapter，可移植对象适配器），替代传统的BOA（Basic Object Adapter，基本对象适配器）
- Servant：伺服对象，CORBA对象的真正实现，负责完成客户端请求。指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。
- Adapter Activator：适配器激活器，
- Object Request Broker：对象请求代理，解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制
- 伺服对象定位器：
- 伺服对象激活器：
- 伺服对象管理器：伺服对象定位器和伺服对象激活器，用来提供CORBA服务端的对象查找服务，活动对象映射表用来保存已注册的CORBA对象标识和伺服对象之间的映射关系
CORBA体系结构是OMG为解决分布式处理环境中硬件和软件系统的互连而提出的一种解决方案，CORBA的核心是对象请求代理ORB（Object Request Broker，对象请求代理），它提供对象定位、对象激活和对象通讯的透明机制。客户发出要求服务的请求，而对象则提供服务，ORB把请求发送给对象、把输出值返回给客户。ORB的服务对客户而言是透明的，客户不知道对象驻留在网络中何处、对象是如何通讯、如何实现以及如何执行的，只要他持有对某对象的对象引用，就可以向该对象发出服务请求。CORBA使用IDL（Interface Description Language，接口定义语言）用于描述组件将呈现出来的接口。CORBA又规定从IDL到特定程序语言，如C++或Java，实现的映射。这个映射精确的描述CORBA资料类型是如何被用户端和服务器端实现的。标准映射的有C、C++、Java以及Python。
客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。
对象标识（Object ID）是一个用于在POA中标识一个CORBA对象的字符串。
它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。
POA是对象实现与ORB其他组件之间的中介，它将客户请求传送到伺服对象，按需创建子POA，提供管理伺服对象的策略。
OMG基于CORBA基础设施定义四种构件标准：
- Entity：实体构件需要长期持久化并主要用于事务性行为，由容器管理其持久化
- Process：加工构件同样需要容器管理其持久化，但没有客户端可访问的主键
- Session：会话构件不需要容器管理其持久化，其状态信息必须由构件自身管理
- Service：服务构件是无状态的
EJB
Enterprise JavaBean，企业级Java组件，EJB是SUN的服务器端组件模型，最大的用处是部署分布式应用程序。凭借Java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB是J2EE的一部分，定义一个用于开发基于组件的企业多重应用程序的标准。
EJB又可分为Session Bean，Entity Bean和Message Driven Bean。
- Session Bean：会话Bean，用于实现业务逻辑，可以是有状态、无状态的。每当客户端请求时，容器就会选择一个Session Bean来为客户端服务。Session Bean可以直接访问数据库，但更多情况下会通过Entity Bean实现数据访问。
- Entity Bean：实体Bean，域模型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象。事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。
- Message Driven Bean：消息驱动Bean，EJB 2.0（3.0？？）中引入的企业Bean，基于JMS（Java Message Service，Java消息服务）消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步无状态Session Bean，客户端调用MDB后无需等待立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。
DCOM
COM：Component Object Model，组件对象模型技术；
Distribute Component Object Model，分布式构件对象模型。
Microsoft的COM定义构件和它们的客户之间互相作用的方式，使得构件和客户端无需任何中介构件就能相互联系。DCOM扩展COM，使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通信。使用DCOM，应用系统就可以在位置上达到分布性，从而满足客户和应用的需求。因为DCOM是COM的无缝扩展，所以可以将基于COM的应用、构件、工具和知识转移到标准化的分布式计算领域中。在做分布式计算时，DCOM处理网络协议的低层次的细节问题，从而使开发人员能够集中精力解决用户所要求的问题。DCOM具有语言无关性，任何语言都可以用来创建COM构件。DCOM具有位置独立性，即DCOM使得构件的位置对用户来说完全透明，用户无需知道构件的具体位置，无论构件是位于客户的同一个进程中，还是位于地球的另一端。在任何情况下，客户连接和调用构件的方法都是一样的。DCOM不仅无需改变源码，而且无需重新编译程序。仅仅使用一个简单的再配置动作，就可以改变构件之间相互连接的方式。
DCOM是一系列微软的概念和程序接口，利用这个接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象。Microsoft的DCOM扩展COM，使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。使用DCOM，你的应用程序就可以在位置上达到分布性，从而满足客户和应用的需求。
COM+并不是COM的新版本，可以把它理解为COM的新发展，或者为COM更高层次上的应用。COM+的底层结构仍然以COM为基础，它几乎包容COM的所有内容。COM+倡导一种新的概念，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统。COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设计和实现，已经成为Microsoft系统平台策略和软件发展策略的一部分。COM+继承COM几乎全部的优势，同时又避免COM实现方面的一些不足。COM+紧紧地与操作系统结合起来，通过系统服务为应用程序提供全面的服务。
COM对象重用
为实现对象重用，COM支持两种形式的对象组装：
- 包含：一个外部对象拥有指向一个内部对象的唯一引用，外部对象只是把请求转发给内部对象；
- 聚集：直接把内部对象的接口引用传给外部对象的客户，而不再转发请求。
COM不支持任何形式的实现继承。COM没有定义或考虑单独的构件从内部如何去实现。构件可以由使用实现继承的类组成。无论何种情况，缺少实现继承并不意味着缺少对重用的支持。为实现对象重用，COM支持两种形式的对象组装：包含（Containment）和聚集（Aggregation）。
包含就是一种简单的对象组装技术，即一个对象拥有指向另一个对象的引用。从概念上来说，前者（称做外部对象）"包含"后者（称做内部对象）。外部对象只是把请求转发给内部对象。转发，就是调用内部对象的方法，以实现对某个外部对象方法的调用。
包含能重用内含于其他构件的实现。特别是，对于使用外部对象的客户程序，包含是完全透明的。调用接口函数的客户无法辨别调用是由提供接口的对象处理，还是被转发给另一个对象处理。如果包含层次较深，或者被转发的方法本身相对简单，包含会存在性能上的问题，晖此COM定义第二类重用形式，即聚集。聚集的基本思想很简单，直接把内部对象的接口引用传给外部对象的客户，而不再转发请求。对此接口的调用将直接到达内部对象，从而省去转发的代价。当然，只有在外部对象不希望截取调用以执行诸如过滤等额外处理时聚集。还有，保持透明性是很重要的，因为外部对象的客户无法辨别哪个特定接口是从内部对象聚集而来的。
敏捷开发
敏捷方法是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。敏捷方法的核心思想主要有以下三点：
- 敏捷方法是适应性而非预设性的。传统方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷方法则欢迎变化，其实它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化
- 敏捷方法是以人为本，而不是以过程为本。传统方法以过程为本，强调充分发挥人的特性，不去限制它，并且软件开发在无过程控制和过于严格烦琐的过程控制中取得一种平衡，以保证软件的质量
- 迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化
与UP/RUP相比，敏捷方法的周期可能更短。敏捷方法在几周或几个月的时间内完成相对较小的功能，强调尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，更加强调团队中的高度协作。相对而言，敏捷方法主要适合于以下场合：
- 项目团队的人数不能太多，适合于规模较小的项目
- 项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合
- 高风险项目的实施
- 从组织结构的角度看，组织结构的文化、人员、沟通性决定敏捷方法是否使用。
与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所作的决定得到认可、环境设施满足团队成员之间快速沟通的需要。
敏捷宣言，也叫做敏捷软件开发宣言，包括四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。四个核心价值：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
12条原则已经应用于管理大量的业务以及与IT相关项目中，包括BI：
- 通过早期和连续型的高价值工作交付满足客户
- 大工作分成可以迅速完成的较小组成部门
- 识别最好的工作是从自我组织的团队中出现的
- 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作
- 创建可以改善可持续工作的流程
- 维持完整工作的不变的步调
- 欢迎改变的需求，即使是在项目后期
- 在项目期间每天与项目团队和业务所有者开会
- 在定期修正期，让团队反映如何能高效，然后进行相应地行为调整
- 通过完车的工作量计量工作进度
- 不断地追求完善
- 利用调整获得竞争优势
Scrum
水晶方法
强调用最少纪律约束而仍能成功
XP
eXtreme Programming，极限编程，适用于费用控制严格的公司。提供几款供开发人员模仿的最佳实践：
- 结对编程
- 测试驱动
- 客户驻场
- 快速设计
- 计划游戏
- 隐喻
TDD
测试驱动开发，Test-Driven Development。
开放式源码方法
开发人员地域分布广。这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。
FDD
Feature Driven Development，特性驱动开发，功用驱动开发，将程序员分为首席程序员和类程序员（class owner），致力于短时的迭代，阶段和可见可用的功能。
DSDM
动态系统开发方法，Dynamic Systems Development Method
ASD
Adaptive Software Development，自适应软件开发。三个非核心的、重叠的开发阶段：猜疑、合作和学习
ADT
敏捷数据库技术，Agile Database Techniques
LSD
精益软件开发，Lean Software Development。
其他
V模型
开发和测试相结合，一种典型的测试模型。在V模型中测试过程被加在开发过程的后半部分，包括单元测试、集成测试、系统测试和验收测试。
演化模型
主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求。其主要缺点是，如果不控制地让用户接触开发中尚未稳定的功能，可能对开发人员及永固都会产生负面的影响。