发信人: kenmlee()
整理人: majorsun(2000-03-08 19:23:11), 站内信件
|
发信人: ship@kapok (), 信区: Programming
标 题: meta-modal [转] (fwd)
发信站: (Mon Oct 7 19:05:24 1996)
转信站: kapok (local)
*** Forwarded file follows ***
发信人: jianzi ( 甜甜的，胖胖的~~~), 信区: SoftEng
标 题: meta-modal [转]
日 期: Mon Oct 7 18:43:32 1996
发信人: happen (偶然), 信区: SoftEng
标 题: meta-modal(1)
日 期: Wed Oct 2 15:13:48 1996
使用meta-模型达到软件开发系统的更灵活的管理
C.W. Dawson R.J.Dawson
当前在工业界使用的软件开发的范例大都是基于已建立的软件生命期
的模型。但随着技术的发展和更易于实现，出现了一些软件系统开发的更灵活
的模型，它们基于更有力的软件工程工具和更先进的开发方法。一种软件系统
开发的更积极的途径应允许不用更改开发管理的结构就能达到不同的开发模型
的集成。本文介绍了允许软件系统开发的更灵活的管理的META－模型。还介绍
了一种辅助的管理技术GANs（一般化的活动网络）。
1 导言
自从1967年，一个NATO的研究小组提出了软件危机以来，软件人员试
图更充分地理解软件开发的过程。早期的结构化软件开发过程的努力是基于已
有的工程实践的。但不久就证明这是不可行的，因为软件同物理的工程产品有
着根本的不同。
许多人很早就提出应用一种更灵活的软件系统开发的途径。但项目管
理者往往不愿使用缺乏结构和可见的方向的方法，再加上大公司的惰性，使得
绝大多数的软件项目仍使用基于生命期或瀑布模型的方法。有些人提出了一些
新的方法来避免瀑布模型带来的严格的约束，但它们仍通过定义软件开发的特
定的阶段和顺序对系统开发的方向加以严格的限制。解决这个问题的一种方法
是把几种不同的模型合并成混合模型（meta_modal）。它可以使得项目沿着更
易感应的方向发展，而且也提供了对项目有关的结构的管理。
2 软件开发过程
软件的开发从广义上来说是一种模糊的系统，它的起点和终点也都很
不清楚。为了把软件开发过程概念化和减少其复杂性，人们提出了不同的结构
。Rook, Macro和Buxton提出了一种三维的系统模型，包括支持要素、活动和
阶段。
支持要素是那些帮助软件开发者的工具和过程。包括标准、过程、文
档系统、项目管理工具和培训。它们能用来在项目生命期的特定阶段辅助特定
的活动或方法。CASE工具和IPSE（集成化的项目支持环境）都属于此类。
活动是软件开发组的成员在整个项目生命期中完成的工作。通常，这
些活动可以分配给特定的成员。如项目管理者要对资源和项目管理活动负责，
而项目的文档可以交给技术写作人员。
阶段代表了项目的整个过程中的可以从理论上定义的阶段。
但这个三维结构并没有从整体上表示软件开发的过程。现在，已有了
几种软件开发模型。可以定义一组比较宽泛的阶段，既能描述我们的目的，又
不对过程加以限制。
3 广义的表示
图1是软件开发过程的一种广义的表示。
+================+ +==============＋
| 辅助 | 辅助 | |
| 支持要素 |------------->| 活动 |
+================+ +==============+
| /
| /在开发生命期
| / 中进行
| v
辅助 | +=============+
| | |
| |模型/范例 |
| +=============+
| / \
V 能定义/ \定义内容
+================+ / \ +============+
| 方法 |v 协议 v| |
| 技术 |----------------->| 阶段 |
+================+ +============+
图1 软件开发过程的表示
3.1 模型
开发一个有效的模型要在实现一个易懂的生命期模型和一个可以灵活
地适应各种情况的过程间取得平衡。传统的瀑布模型是做不到的。
一些软件开发者总是使用一种已经熟悉的模型来开发各种软件。我们
主张在弄清要做什么之前先不要选定模型。也有些开发者没有有意识地使用一种
清晰的模型，特别是小型软件的开发，他们的方法常常是“编码＋修正(code+fix)”。
3.1.1 瀑布模型和经典的生命期模型： waterfall model or classical
life-cycle瀑布模型基于一种特定的阶段结构。它是基于工程模型的，可以追
溯到Bening在1956年的工作。由于大公司的惰性，瀑布模型及其变种仍在软件
开发中大量使用。它主要包括一下6个阶段。
需求分析
规格说明
详细设计
实现
使用
完结
3.1.2 原型：prototying
通用原型模型：在需求分析或规格说明阶段建立。
抛弃原型模型：用来代替瀑布模型的需求分析阶段或指快速
原型。
进化原型模型：开发一系列连续的模型收敛而成的产品，也
叫递增模型。
递增原型模型：二次开发的模型。
3.1.3 正规转换（正规方法模型）：(或形式转换?)
formal transformations(formal method model)
把从需求详细说明书而来的功能详细说明书，一步步地形式
地转变成一个软件系统。转变可以通过形式开发语言（如一些为次开发的4GL
〕或更集中的编码技术。可提高软件的安全性和可靠性。
3.1.4 进化交付模型：evolutionary deliveries.
类似于递增原型模型。它的好处在于可以使用离散的变化来
改变发展的方向来满足用户变化的需求。
3.1.5可操作的规格模型：operational specification
类似于原型模型，但它不需要在当时可能还不存在的系统上
开发。它把开放过程分成面向问题的和面向实现的两个阶段；它还给用户提供
了一个早期的可运行的系统模型。
3.1.6 螺旋模型：spiral model
由Boehm在1988年提出，封装了生命期模型和原型模型的一
些好的特性。它把开发过程分解成四个循环的过程：计划、风险分析、工程和
用户评价。这样，用户的评价可以反馈到下一步的设计阶段。它在下一阶段开
始之前要解决风险。如果风险不能被控制，或被限制在一个可接受的范围之内
，项目就结束了。
3.1.7 4GT模型：Fourth-generation techniques model
它更象是开放方法和工具，而不象模型。通过使软件可以在
一个很高的规格上开发，4GT开发的速度很快。这样就产生了基于它们的操作
的模型。从设计阶段开始使用4G技术。它的另一个分支是自动形式化和4GL模
型。
3.1.8自动形式化和4GL模型：automated formal and 4GL model
它把最近发展的4GL技术和形式化的方法结合起来。图2 解
释了它的过程。从需求分析开始，使用形式化的规格说明技术可以得到形式化
的规格说明。4GL可以用来从规格说明直接得到原型，再进行优化，形成可运
行的系统。它象其它的模型一样，在最后完结之前也要经过操作和维护。
3.1.9建立和修改：build and fix
这可能是能被软件开放过程所采用的最差的模型了。它没有
正式的规格说明和需求分析。它广泛地被业余的或小项目的开发者使用。
3.2 方法
1992年Spikes Cavell的调查表明73％的组织使用一定形式的软件开
发方法。 方法指的是在软件开发过程中的某些阶段使用的一种定义好的方式
。技术没有方法那么复杂，可以只覆盖某一阶段的某些部分。技术可以在方法
中被定义和使用，但它描述不了整个阶段，所以技术可以看作是子方法。它们
大多被工具所支持。
3.3 阶段
不同的方法定义的阶段数从2到超过15不等。虽然强加的阶段结构会
对过程的自然进展有限制，但项目阶段计划还不能抛弃，因为为任何过程的有
效管理都需要有一个基本的底层结构。
图3给出了一个广义的4阶段的开发结构，由分析、组织、运行和完结
构成。这4 个阶段有些重叠。它代表了阶段间的交互和反馈，但有时也构成了
软件开发过程中的“灰色”区域。如有时会有规格说明应在分析阶段还是在组
织阶段的争论。所以最好把它放在两个阶段的边界上。
4 阶段方法的僵化之处
首先，真正的项目很少能按照这个顺序；其次，在初始阶段用户很难说出他们的全部需求
;最后，用户在最后完成阶段才能看到产品的情况。
5 META模型（混合模型）
Bulter Group 认为软件开发是一种动态的过程，为了满足用户不断的要求和
更广泛的问题领而不断地变化。META模型就是一种能处理多种动态的系统开发
的模型。它提供了控制软件开发项目，在项目生命期中识别风险和决策点的方
法。在META模型中包含了8种已有的模型。
5.1 使用META模型的好处
项目管理者当然不愿意在没有概念化的框架的情况下进行开发。META模型把几种模型组合
一起，既能发挥每种模型的长处，也给项目管理者提供
了一个可操作的结构框架。meta模型允许管理者按照当前项目的状况来指导项
目的进程，而不用象传统的生命期的方法那样，非按照在项目刚开始的时候对
项目还很不了解的情况下指定的方向来做。 在需要决策的时候才决策。
6 灵活的管理技术
GANs（generalised activity networks）是 60年代发展起来的一项
技术。它同PERTs不同之处在于它们对活动的输入和输出的特性的定义不同。
GAN更灵活。它还能处理循环。
摘译自《Software Engineer Journal》 1995，5, p79-88
--
__ __
/ \./ \/\_
__{^\_ _}_ ) }/^\
/ /\_/^\._}_/ // /
( (__{(@)}\__}.//_/__A____A_______A_____A_____A_____A___A___A______
\__/{/(_)\_} )\\ \\---v-----V-----V---Y--v----Y----v---V-----v---
( (__)_)_/ )\ \>
\__/ \__/\/\/
\__,--'
送你一朵玫瑰花....嘻嘻...小心刺哦
--
游戏人生
--
※ 来源:．网易 BBS bbs.netease.com．[FROM: 202.96.166.212]
|
|