URL:http://technet.microsoft.com/en-us/library/aa578470.aspx
To purge data from the BizTalk Tracking database (SQL Server 2005)
1.Click Start, click Programs, click Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2.In the Connect to Server dialog box, specify the name of the SQL Server where the BizTalk Tracking (BizTalkDTADb) database resides and the appropriate authentication type, and then click Connect to connect to the appropriate SQL Server.
3.In Microsoft SQL Server Management Studio, double-click SQL Server Agent, and then click Jobs.
4.In the details pane, right-click DTA Purge and Archive (BizTalkDTADb), and then click Properties.
5.In the Job Properties - DTA Purge and Archive (BizTalkDTADb) dialog box, under Select a page, click Steps.
6.In the Job step list, click Archive and Purge, and then click Edit.
7.In the Job Step Properties - Archive and Purge dialog box, on the General page, in the Command box, change exec dtasp_BackupAndPurgeTrackingDatabase to exec dtasp_PurgeTrackingDatabase.
Caution
The exec dtasp_PurgeTrackingDatabase stored procedure does not archive the BizTalk Tracking (BizTalkDTADb) database. Before using this option, be certain that you no longer require archived tracking data.
8.In the Command box, edit the following parameters as appropriate, and then click OK.
@nHours tinyint — Any completed instance older than (live hours) + (live days) will be deleted along with all associated data.
@nDays tinyint — Any completed instance older than (live hours) + (live days) will be deleted along with all associated data. Default interval is 1 day.
@nHardDays tinyint — All data older than this day will be deleted, even if the data is incomplete. The time interval specified for HardDeleteDays should be greater than the live window of data. The live window of data is the interval of time for which you want to maintain tracking data in the BizTalk Tracking (BizTalkDTADb) database. Anything older than this interval is eligible to be archived at the next archive and then purged.
@dtLastBackup — Set this to GetUTCDate() to purge data from the BizTalk Tracking (BizTalkDTADb) database. When set to NULL, data is not purged from the database.
Your edited script should look similar to this:
declare @dtLastBackup datetime set @dtLastBackup = GetUTCDate() exec dtasp_PurgeTrackingDatabase 1, 0, 1, @dtLastBackup
9.On the Job Properties - DTA Purge and Archive (BizTalkDTADb) dialog box, under Select a page, click General, select the Enabled check box, and then click OK.
2008年7月17日 星期四
2008年7月13日 星期日
2007年11月27日 星期二
Android G Phone
Win Android $10 Million Developer Challenge by ZK Mobile for Android ;-)
Dennis Chen, Engineer, Potix Corporation
Jeff Liu, Engineer, Potix Corporation
Nov. 14, 2007
Version & Requirement
- ZK 3.0
- Google Android SDK
- jTwitter - Open-source Java Interface to Twitter
Introduction
Android
On Nov 12th, 2007, Google releases Android SDK and a complete tutorial. Android, licensed under the Apache license, is a fully integrated mobile platform of a Linux operating system, middleware, widgets set and applications.
Few features to be noticed:
To learn more about Android, click here
- Android SDK can be run in Windows, OSX(Mac), Linux
- Develop in Java on Eclipse with its Eclipse plugin
- Emulator comes with SDK for debug and application development
- Documentation and tutorial are complete and really helpfull
ZK Mobile for Android
The ZK Mobile for Android is the ZK extension that enables reachness of ZK applications to Android platform mobile devices with little programming. With the event-driven components and a markup language on server side, developing is as simple as programming desktops and authoring HTML. No Android prerequisite is required. The architecture of the ZK Mobile Computing for Android is as follows,
Binding ZK and Android by Server-Centric Architecture
With ZK's server-centric architecture, developing Android application becomes a very easy task. ZK mobile developers only need to write MIL (Mobile Interactive Language) files in ZK tags without understanding Android SDK detailly. MIL is a markup language that enables developers to author a page without programming. Also, due to the tendency of server-centric framework - application runs on server, developers don't need to re-deploy applications when applications update occurs and the business logic is controlled in server side. As soon as the application installed at the server is upgraded, the user will access the most updated version automatically. Moreover, the business logic is running at the server, so it requires much less memory in the mobile device.
2007年8月7日 星期二
淺談 SOAP
http://www.ibm.com/developerworks/tw/library/x-sisoap/
Example 1
Example 2
Example 3
Figure 5
級別: 入門
2001 年 8 月 01 日
本文對 SOAP 作了一個初步介紹，示範幾個簡單範例；接著比較 CORBA，DCOM/COM 與 SOAP 的連絡與區別；然後簡單起分析 SOAP 簡單的理解為 RPC+HTTP+XML 時的執行機制；最後展現 SOAP 的前景。
隨著電腦技術的不斷發展，現代企業面臨的環境越來越複雜，其訊息系統大多數為多平台、多系統的複雜系統。這就要求今天的企業解決方案具有廣泛的相容能力， 可以支援不同的系統平台、資料格式和多種連線方式，要求在Internet 環境下，實作系統是鬆散耦合的、跨平台的，與語言無關的，與特定介面無關的，而且要提供對Web 應用程式的可靠存取。
隨 著異種計算環境的不斷增加，各種系統間的互通性就愈顯得必要，要求系統能夠緊密地進行通信和共享資料，從而在 Internet 環境下，消除巨大的訊息孤島，實作訊息共享、進行資料交換，達到訊息的一致性。Web services 希望實作不同的系統之間能夠用"軟體-軟體對話"的方式相互呼叫，打破了軟體應用、網站和各種設備之間的格格不入的狀態，實作"基於WEB緊密整合"的目 標。
今年四月份的時候，W3C聯盟召開了第一次 Web 服務專題研討會，目的為探索 W3C 應向哪個方向發展才能實作新興的 Web 服務架構的標準化，期間提出了一個"Web 服務架構"的構想，如下圖，從圖中可以看出，SOAP在WEB服務架構中作為用於 XML 訊息傳遞的一種非常普遍的協定，發揮著十分重要的作用。
 |
 |
|
SOAP（Simple Object Access Protocol ）簡單物件存取協定是在分散或分散式的環境中交換訊息的簡單的協定，是一個基於XML的協定，它包括四個部分︰SOAP Envelop，Envelop定義了一個描述訊息中的內容是什麼，是誰傳送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則 （encoding rules），用於表示應用程式需要使用的資料類型的實體; SOAP RPC表示(RPC representation)，表示遠端過程呼叫和回應的協定；SOAP繫結（binding），使用底層協定交換訊息。
雖然這四個部分都作為SOAP的一部分，作為一個整體定義的，但他們在功能上是相交的、彼此獨立的。特別的，信封和編碼規則是被定義在不同的XML命名空間(namespace)中，這樣使得定義更加簡單。
SOAP 的兩個主要設計目標是簡單性和可擴充性。這就意味著有一些傳統訊息系統或分散式物件系統中的某些性質將不是SOAP規範的一部分。比如︰分散式垃圾收集 (Distributed garbage collection)、批次傳送訊息(Boxcarring or batching of messages)、物件參照 (Objects-by-reference（which requires distributed garbage collection）)、物件啟動 (Activation（which requires objects-by-reference）)。
1．第一個例子闡明了SOAP中一個簡單的通信訊息，包括了兩個不是SOAP定義而是應用程式定義的元素︰標頭區塊元素alertcontrol 和主體區塊元素alert。標頭區塊元素包括兩個參數︰priority 和expires。主體區塊元素包括的是實際傳送的訊息。
Example 1
2． SOAP通信與底層的不同協定和不同的交換格式有關，下面的例子SOAP使用HTTP作為底層通信協定，從而可以很好的使用 request/response機制來傳送訊息。 SOAP/HTTP請求包括一個GetLastTradePrice的區塊元素，該請求攜帶一個字串參數和ticker符號，在SOAP回應中傳回一個浮 點數。XML命名空間欄位用來區分SOAP標誌字元和應用程式特定的標誌字元。
Example 2
3. 例3 展示的是StockQuote SOAP服務訊息，是對例2的請求作出的一條回應訊息。
Example 3
|
|
|
在SOAP剛剛提出來的時候，許多人就提出了疑問︰SOAP與CORBA和DCOM的區別何在？
- CORBA（Common Object Request Broker
Architecture）公用物件請求代理架構是由OMG組織制訂的一種標準的物件導向應用程式體系規範。由物件請求代理ORB、物件服務、公用設施、 網域介面和應用介面這幾個部分群組成。其核心部分是物件請求代理ORB（Object Request Broker）。ORB提供了一種機制，透過這種機制，物件可以透明的發出請求和接收回應。分布的、可以互操作的物件可以利用ORB建立可以互操作的應 用。ORB可看作是在物件之間建立客戶/服務關係的一種中介軟體。基於ORB，客戶可以透明的呼叫服務物件提供的方法，該服務物件可以與客戶執行在同一台 機器上，也可以執行在其它機器上透過網路與客戶進行交互。ORB截取客戶傳送的請求，並負責在該軟體匯流排上找到實作該請求的服務物件，然後完成參數、方 法呼叫，並傳回最終結果。CORBA 1.1 由物件管理組織在 1991 年發佈。定義了介面定義語言（IDL）和應用程式介面（API），從而透過實作物件請求代理（ORB）來啟動客戶/伺服器的交互。CORBA 2.0 於 1994 年的 12 月發佈定義了如何跨越不同的 ORB 提供者而進行通訊。 - COM/DCOM(Component Object Model / Distributed Component Object
Model )是微軟公司提出的分散式元件物件模型標準，支援在區域網路、廣網域網甚至Internet上不同電腦的物件之間的通訊。DCOM基於COM的應用程式、 元件、工具等的基礎之上，處理網路協定的低層次的細節問題，而不必關心太多的網路協定細節，從而使使用者能夠集中精力解決使用者所要求的問題。DCOM位 於應用程式的元件之間，將元件以不可見的方式膠合在一起組成具有完整功能的應用程式。 - SOAP 與CORBA，DCOM/COM的比較。
3.1 首先指出的是SOAP不會取代CORBA，COM/DCOM，三者的概念有所區別。COM/DCOM是個元件模型標準，CORBA是分散式應用的服務標 準。CORBA和DCOM為分散式應用程式建立服務，服務物件來執行客戶端呼叫的服務。而SOAP是基於XML和HTTP的分散式物件的通信協定，是 COM/DCOM和CORBA物件進行通訊的協定。實際上，利用SOAP的互通性和CORBA強大的執行能力，兩者可以很好的結合在一起。 OMG （Object Management Group responsible for the CORBA specification）正在關注這方面的發展。
3.2. CORBA應用程式和DCOM應用程式不能實作互操作，兩者不能在一起協同合作。因為在ORPC(Object RPC)協定中，用ObjRef代表了一個正在執行物件的參照；在CORBA/IIOP(Internet Inter-Orb Protocol)中，用交換可互操作物件參照IOR（Interoperable Object Reference）代表一個伺服器的物件參照。不幸的是，IOR 與 ObjRef不能夠關聯起來。然而，使用SOAP可以實作在垂直應用層面上CORBA ，DCOM技術的水平整合，能夠更好的整合CORBA，DCOM為一個整體。
3.3 SOAP並沒有定義訊息的語義，服務品質，基於INTERNET的交易處理。而是採用 XML 進行訊息編碼，正確的處理需要伺服器和客戶端本身來執行，理解和執行彼此使用的訊息格式（ONE-TO-ONE，REQUEST/REPLY， BROADCAST，ETC），應用程式本身在語義解析中扮演著十分重要的角色。而CORBA，DCOM表示了傳送訊息的語義，對參數和傳回值使用二進位 編碼。可對諸如參數名稱或類型的任何元訊息都不編碼，但使中介很難處理訊息。又因為每個系統使用不同的二進位編碼，系統間的互操作的很難實作。
3.4 儘管CORBA可以在不同的平臺上執行，DCOM可以在微軟的各種平臺上執行，但是基於CORBA和DCOM的解決方案必須依賴於單一的應用程式。比如 說，假如執行的是DCOM伺服器程式，所有的分散式的客戶端不得不執行於微軟的作業平臺上。CORBA 雖然可以執行於不同的平台，但CORBA的互通性並沒有在更高層的服務上進行擴充，如安全性和交易處理，在這種情況下，許多提供的服務沒有得到很好的最佳 化。DCOM和CORBA適合於伺服器--伺服器間的通訊，但是對於客戶端--伺服器的通訊十分脆弱，尤其當客戶程式分布在INTERNET上更是如此。
3.5 SOAP不像DCOM一樣試圖定義分散式系統的所有元素，SOAP沒有提供分散式類別庫，類型安全檢查，版本控制等等，SOAP比它處於一個更低的層次， 有點類似於IIOP在CORBA的作用，DCOM卻提供了一些額外的協定功能，是IIOP 或者SOAP所不具備的。然而，許多. DCOM的額外功能只有在伺服器__伺服器間通信時才會用到，對於客戶端__伺服器之間的通信則是多餘的。
|
|
|
SOAP簡單的理解，就是這樣的一個開放協定SOAP=RPC+HTTP+XML︰採用HTTP作為底層通訊協定；RPC作為一致性的呼叫途徑，ＸＭＬ作 為資料傳送的格式，容許服務提供者和服務客戶經過防火牆在INTERNET進行通訊交互。RPC的描敘可能不大準確，因為SOAP一開始構思就是要實作平 台與環境的無關性和獨立性，每一個透過網路的遠端呼叫都可以透過SOAP Envelop起來，包括DCE（Distributed Computing Environment ） RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。
SOAP 使用 HTTP 傳送 XML，儘管HTTP 不是有效率的通訊協定，而且 XML 還需要額外的文件解析（parse），兩者使得交易的速度大大低於其它方案。但是XML 是一個開放、健全、有語義的訊息機制，而 HTTP 是一個廣泛又能避免許多關於防火牆的問題，從而使SOAP得到了廣泛的應用。但是如果效率對你來說很重要，那麼你應該多考慮其它的方式，而不要用 SOAP。
為了更好的理解SOAP,HTTP,XML如何工作的，不妨先考慮一下COM/DCOM的執行機制，DCOM處理網路 協定的低層次的細節問題，如PROXY/STUB間的通訊，生命週期的管理，物件的識別。在客戶端與伺服器端進行交互的時候，DCOM採用NDR （Network Data Representation）作為資料表示，它是低層次的與平台無關的資料表現形式。
DCOM是 有效的，靈活的，但也是很複雜的。而SOAP的一個主要優點就在於它的簡單性，SOAP使用HTTP作為網路通訊協定，接受和傳送資料參數時採用XML作 為資料格式，從而代替了DCOM中的NDR格式，SOAP和 DCOM執行過程是類似的，如下圖，但是用XML取代 NDR作為編碼表現形式，提供了更高層次上的抽象，與平台和環境無關。
Figure 5
客戶端傳送請求時，不管客戶端是什麼平台的，首先把請求轉換成XML格式，SOAP閘道可自動執行這個轉換。為了保證傳送時參數，方法名，傳回值的唯一性，SOAP協定使用了一個私有標籤表，從而服務端的SOAP閘道可以正確的解析，這有點類似於COM/DCOM
中 的STUB。轉化成XML格式後，SOAP終端設備名（遠端呼叫方法名）及其它的一些協定識別訊息被封裝成HTTP請求，然後傳送給伺服器。如果應用程式 要求，伺服器傳回一個HTTP回應訊息給客戶端。與通常對HTML頁面的HTTP GET請求不同的是，此請求設定了一些HTTP HEADER，識別著一個SOAP服務活動，和HTTP套件一起傳送。例如︰對於一個詢問股票價格的應用程式，伺服器端具有元件提供某股票目前的價格，元 件是COM或CORBA在伺服器上建立的。客戶端傳送一個SOAP請求給伺服器詢問股票價格。伺服器依賴於伺服器上的SOAP閘道，使用內嵌的HTML物 件呼叫合適的方法， 然後把得到的價格透過SOAP回應傳給客戶端。
|
|
|
W3C於2000年5月8日發表了Simple Object Access Protocol (SOAP) 1.1版本，具體規範發佈在下列網站上（ http://www.w3.org/TR/SOAP/ ）。又與今年7月9號推出了SOAP Version 1.2版本的建議草案，具體規範發佈在下列網站上（ http://www.w3.org/TR/soap12/ ）。編寫SOAP Version 1.1版本的工作小組的成員包括︰ DevelopMentor, International Business Machines Corporation, Lotus Development Corporation, Microsoft, UserLand Software 。
SOAP 的推出是令人興奮的。可以相信，隨著網路服務的的不斷發展，它將極大的改變我們的思考模式和開發模式。現在，已有許多大公司著手支援SOAP的開發，去年 IBM公司 和 Microsoft公司 都發行了實作 SOAP 的第一批版本。 IBM 公司啟動了Apache SOAP 專案計劃，微軟最近又推出了SOAPtoolkit2.0的正式版，主要包括如下的一些特性︰SOAP的高層介面和低層介面，訊息物件介面，完全支援 WSDL 1.1標準，支援使用者自訂類型對應，並且提供了豐富和完整的開發文件以及應用實體。而且，兩家公司正在互通性方面努力研究。可以樂觀的估計，不用多久， SOAP 互通性的時代就將來臨。
- HTTP 1.0 or greater（ http://www.w3.org/Protocols/HTTP/ietf-http-ext ）
- the core W3C XML recommendation（ http://www.w3.org/TR/1998/REC-xml-19980210 ）
- W3C XML namespace recommendation（ http://www.w3.org/TR/REC-xml-names ）.
- XML Schema（ http://www.w3.org/TR/xmlschema-1/ ）
| Organization | Product |
| Rogue Wave | Nouveau ORB |
| Iona | Orbix 2000 |
| ObjectSpace | Voyager |
| Digital Creations | Zope, the Python Application Server |
| UserLand | Frontier groupware product |
| Microsoft | Windows DNA 2000 |
SOAP是一個協定，與程式設計語言無關。實際上，許多語言已經開始支援SOAP，如︰java,c/c++,vb,c#,perl,php.下面列出了在Java/C++/Perl/ADA/Python環境下SOAP的執行工具︰
- Java : Apache SOAP, DevelopMentor's implementation, IdooXoap from ZVON
- Python : PythonWare (client side only)
- C++ : IdooXoap from ZVON
- Perl : SOAP::Lite
- ADA : An ADA implementation
- Microsoft Visual Studio: The Microsoft SOAP toolkit.
|
|
|
- http://www.ibm.com/developerworks/tw/ （IBM公司）
- http://msdn.microsoft.com/ （微軟公司）
- http://www.w3.org/TR/soap12/ （W3C聯盟）
- http://www.soaprpc.com/
- http://www.webservices.org
- http://www.soapwebservices.com
- http://www.xml.org.tw （台灣xml聯盟）
|
|
|
| |
段智華: 進階軟體工程師，對工作流程系統有深入研究，曾參與基於XML的SU-PDM2.0產品資料管理系統的開發。目前在上海市易方公司從事SOAP/XML的研究。可透過E-mail: duanzhihua@263.net 與作者連絡。 | |
Web Services介紹
Web Services介紹
資策會數位教育研究所講師 鄧文焯
這一年多來，不管是從報章雜誌、網路文章、電視、收音機，甚至路邊兩個人的對話，你都可能看到、聽到網路服務、Web服務，或者Web Services這幾個字眼。究竟這是個甚麼東西，為甚麼會弄得沸沸揚揚到處都出現呢？這篇短文就將為你簡單的說明甚麼是Web Services以及關於Web Services的幾個重要標準。
甚麼是Web Services
這個問題問十個人可能會的到十個以上的答案，希望以下的說明不會讓你答案版本數字再多加一。
“Web Services是一種軟體元件，它透過Web 通訊協定及資料格式的開放式標準(例如 HTTP、XML 及 SOAP等)來為其他的應用程式提供服務。”
這句話簡單的表達了Web Services的意義，這裡面有兩個重點，一是它是一個提供服務的元件。二是它以Web的開放標準為基礎。
根據以上的認識，我們可以看出Web Services的價值。
作為提供服務的元件，它可用來建構分散式架構系統，實現分散式架構動態整合、平衡負擔、單元升級等優點。
以Web的開放標準為基礎，在已經廣被使用的Web網路架構上來運作，採用開放式標準讓Web Services具有良好互通性，在不同平台上用不同程式語言建置的系統也可以輕易整合，克服目前分散式系統各自使用不同機制造成整合困難的情形。
舉一個最常被提到的例子來說明Web Services在實際應用上帶來的可能性。假設我們要建立一個旅遊網站，網站提供的服務包括了旅遊資訊查詢、機票和飯店的預訂和付款、天氣狀況查詢等等，將來只要找到提供這些服務的Web Services，然後將它們整合到網站中即可，不需要再花費時間和資源自己去維護一個包含了旅遊資訊、天氣資訊的資料庫，不需要再自行建立和各飯店、航空公司的資料聯繫和訂位付款機制等等。這個網站就像是建立在Web上整合了這些Web Services元件的一個應用程式系統。更重要的是，透過Web Services的使用，不必擔心這些服務是使用甚麼平台、甚麼技術來建立，而將來如果有更好的服務或服務提供者時，也可以輕易的將服務更換或更新。對系統的開發者來講，可以快速輕鬆的將系統建構完成，將心思專注在規劃更好、更完善的系統上。對服務的提供者而言，只要能設計出一個好的服務，它的潛在使用者市場將不再受到使用者平台的限制而有無限的可能。單就這類應用所呈現的美好遠景，應該可以解釋為甚麼會到處聽到有人在談論Web Services了。
Web Services的重要標準
前面說過Web Services是以Web的開放標準為基礎，其中最基本的是HTTP和XML。但建構完整的Web Services運作還需要更多基礎，以下這些都是以XML為基本語法建立的重要標準。
UDDI (Universal Description Discovery and Integration) : 提供註冊與搜尋Web Service資訊的一個標準。
WSDL (Web Service Description Language): 描述一個Web Services的運作方式，以及指示用戶端與它可能的互動方式。
SOAP (Simple Object Access Protocol): 在網路上交換結構化和型別資訊的一種簡易通訊協定。
這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。
在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。
這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。
在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。
結語
作為一個新起的技術，Web Services還在持續發展中，包括安全、管理等方面的規範仍不斷被研究討論和推出，至於，它是不是真的能成功的發展起來，被普遍的接受使用？是不是可以實現它所給予的美好遠景？不知道！不過可以確定的是，在未來幾年中，它仍將是一個熱門的主題，你還是無法避免在路邊聽到有人提到它。
資策會數位教育研究所講師 鄧文焯
這一年多來，不管是從報章雜誌、網路文章、電視、收音機，甚至路邊兩個人的對話，你都可能看到、聽到網路服務、Web服務，或者Web Services這幾個字眼。究竟這是個甚麼東西，為甚麼會弄得沸沸揚揚到處都出現呢？這篇短文就將為你簡單的說明甚麼是Web Services以及關於Web Services的幾個重要標準。
甚麼是Web Services
這個問題問十個人可能會的到十個以上的答案，希望以下的說明不會讓你答案版本數字再多加一。
“Web Services是一種軟體元件，它透過Web 通訊協定及資料格式的開放式標準(例如 HTTP、XML 及 SOAP等)來為其他的應用程式提供服務。”
這句話簡單的表達了Web Services的意義，這裡面有兩個重點，一是它是一個提供服務的元件。二是它以Web的開放標準為基礎。
根據以上的認識，我們可以看出Web Services的價值。
作為提供服務的元件，它可用來建構分散式架構系統，實現分散式架構動態整合、平衡負擔、單元升級等優點。
以Web的開放標準為基礎，在已經廣被使用的Web網路架構上來運作，採用開放式標準讓Web Services具有良好互通性，在不同平台上用不同程式語言建置的系統也可以輕易整合，克服目前分散式系統各自使用不同機制造成整合困難的情形。
舉一個最常被提到的例子來說明Web Services在實際應用上帶來的可能性。假設我們要建立一個旅遊網站，網站提供的服務包括了旅遊資訊查詢、機票和飯店的預訂和付款、天氣狀況查詢等等，將來只要找到提供這些服務的Web Services，然後將它們整合到網站中即可，不需要再花費時間和資源自己去維護一個包含了旅遊資訊、天氣資訊的資料庫，不需要再自行建立和各飯店、航空公司的資料聯繫和訂位付款機制等等。這個網站就像是建立在Web上整合了這些Web Services元件的一個應用程式系統。更重要的是，透過Web Services的使用，不必擔心這些服務是使用甚麼平台、甚麼技術來建立，而將來如果有更好的服務或服務提供者時，也可以輕易的將服務更換或更新。對系統的開發者來講，可以快速輕鬆的將系統建構完成，將心思專注在規劃更好、更完善的系統上。對服務的提供者而言，只要能設計出一個好的服務，它的潛在使用者市場將不再受到使用者平台的限制而有無限的可能。單就這類應用所呈現的美好遠景，應該可以解釋為甚麼會到處聽到有人在談論Web Services了。
Web Services的重要標準
前面說過Web Services是以Web的開放標準為基礎，其中最基本的是HTTP和XML。但建構完整的Web Services運作還需要更多基礎，以下這些都是以XML為基本語法建立的重要標準。
UDDI (Universal Description Discovery and Integration) : 提供註冊與搜尋Web Service資訊的一個標準。
WSDL (Web Service Description Language): 描述一個Web Services的運作方式，以及指示用戶端與它可能的互動方式。
SOAP (Simple Object Access Protocol): 在網路上交換結構化和型別資訊的一種簡易通訊協定。
這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。
在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。
這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。
在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。
結語
作為一個新起的技術，Web Services還在持續發展中，包括安全、管理等方面的規範仍不斷被研究討論和推出，至於，它是不是真的能成功的發展起來，被普遍的接受使用？是不是可以實現它所給予的美好遠景？不知道！不過可以確定的是，在未來幾年中，它仍將是一個熱門的主題，你還是無法避免在路邊聽到有人提到它。
2007年7月29日 星期日
CMMI（ Capability Maturity Model Integration）
[轉貼]
CMMI（ Capability Maturity Model Integration）的本質是軟件管理工程的一個部分。軟件過程改善是當前軟件管理工程的核心問題， 50多年來計算的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。基於模型的過程改進是指用採用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。
然而，軟件組織形成一套完整而成熟的軟件過程不是一蹴而就的事情，需要經歷一系列的成熟度。軟件組織首先要進行差異分析，評定自己比較接近哪一個成熟度，然後再根據自身的情況來決定要採取哪些改進活動，來更有效地改進自己的軟件過程。這就對軟件過程的評定提出了一個客觀的標準。美國卡內基梅隆大學軟件工程學院於1987年研究成功的SW-CMM（Capability Maturity Model for Software）就是這樣的一個理論模型，其目的在於幫助軟件組織改善軟件生產流程，以探索一個保證軟件產品質量、縮短開發週期、提高工作效率的軟件工程模式與標準規範。
CMMI是一個可以改進系統工程和軟件工程的整合模式。1997年10月SEI停止對CMM的研究，改而致力於CMMI，以解決使用多個過程改進模型的問題。SEI同時宣佈CMMI將取代CMM，與2000年8月11日頒布了CMMI-SE/SW 1.0版本，2001年12月頒布了1.1版本，這次發佈標誌著CMMI正式啟用,並準備今年內完成CMM到CMMI的過渡。說到CMMI就不能不提 CMM。
CMM
CMM框架用5個不斷進化的層次來評定軟件生產的歷史與現狀：初始級描述了不成熟，或者說是未定義的過程的組織，是混沌的過程以不可預測結果為特徵；可重複級是經過訓練的軟件過程；已定義級是標準一致的軟件過程，以組織內改進項目執行為特徵；已管理級是可預測的軟件過程，以改進組織性能為特徵；優化級是能持續改善的軟件過程，以可快速進行重新配置的組織性能，和定量的、持續的過程改進為特徵。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬於這5個層次中的某一個層次。
CMM包括兩部分"軟件能力成熟度模型"和"能力成熟度模型的關鍵過程域"。"軟件能力成熟度模型"主要是描述此模型的結構，並且給出該模型的基本構件的定義。"能力成熟度模型的關鍵過程域"詳細描述了每個關鍵過程方面涉及的過程域。
可重複級關鍵過程域：需求管理，軟件項目計劃，軟件項目跟蹤和監控，軟件子合同管理，軟件質量保證，軟件配置管理。
已定義級關鍵過程域：組織級過程焦點，組織級過程定義，培訓大綱，集成軟件管理，軟件產品工程，組間協調，同行評審。
已管理級關鍵過程域：定量過程管理，軟件質量管理。
優化級關鍵過程域：缺陷預防，技術更新管理，過程更改管理。
多數組織的基本目標是達到成熟度3級。評估組織當前的成熟度級別的手段之一是軟件能力評估（SCE）。SCE通過評估軟件過程（一般以方針陳述的形式）和項目實踐來確定該組織是否言行一致。組織的過程體現了如實記錄所做的工作，項目實施（對該過程的特定剪裁和解釋）應該證明說到做到。
現在全球許多不同的組織以CMM為協助企業作全面的過程改進活動，除了肯定其軟件成熟度外，更像征具有跨足國際市場的能力。現在通過CMM5級認證的組織達到了一百多家。
CMMI
CMM的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、人力資源、集成產品開發、軟件採購等等，從CMM衍生出了一些改善模型，比如：SW－CMM,SE-CMM,IPD-CMM等。不過，在同一個組織中多個過程改進模型的存在可能會引起衝突和混淆。CMMI就是為了解決怎麼保持這些模式之間的協調。
由業界、美國政府和卡內基·梅隆大學軟件工程研究所率先倡導的能力成熟度模型集成（CMMI）項目致力於幫助企業緩解這種困境。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的重複，增加透明度和理解，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。
與原有的能力成熟度模型類似，CMMI也包括了在不同領域建立有效過程的必要元素，反映了業界普遍認可的"最佳"實踐；專業領域覆蓋軟件工程、系統工程、集成產品開發和系統採購。在此前提下，CMMI為企業的過程構建和改進提供了指導和框架作用；同時為企業評審自己的過程提供了可參照的行業基準。
CMMI的源模型：軟件能力成熟度模型2.0版，C稿；電子行業協會臨時標準（EIA/IS）731；集成產品開發能力成熟度模型（IPD-CMM)。
CMMI的原則：
1． 強調高層管理者的支持。過程改進往往也是由高層管理者認識和提出的，大力度的、一致的支持是過程改進的關鍵。
2． 仔細確定改進目標，首先應該對給定時間內的所能完成的改進目標進行正確的估計和定義並制定計劃。選擇能夠達到的目標和能夠看到對組織的效益。
3． 選擇最佳實踐，應該基於組織現有的軟件活動和過程財富，參考其他標準模型，取其精華去其糟粕，得到新的實踐活動模型。
4． 過程改進要與組織的商務目標一致，與發展戰略緊密結合。
CMMI目標:
1. 為提高組織過程和管理產品開發、發佈和維護能力的提供保障。
2. 幫助組織客觀評價自身能力成熟度和過程域能力，為過程改進建立優先級以及執行過程改進。
CMMI的方法：
1 決定哪個CMMI模型等級最適合組織過程改進需要。
2 選擇模型的表示法是連續式還是階段式。
3 決定組織需要用到的模型中的知識領域。
4 類似CMM提出的過程改進6步，集成化過程改進分成：開始集成過程改進,建造集成改善平台，集成傳統過程，啟動新過程，進行改進評估。
CMMI內容
CMMI內容分為"要求"、"期望"和"提供信息"三個級別，來衡量模型包括的質量重要性和作用。最重要的是"要求"級別，是模型和過程改進的基礎。第二級別"期望"在過程改進中起到主要作用，但是某些情況不是必須的可能不會出現在成功的組織模型中。"提供的信息"構成了模型的主要部分，為過程改進提供了有用的指導，在許多情況下他們對需要和期望的構件做了進一步說明。
"要求"的模型構件是目標，代表了過程改進想要達到的最終狀態，它的實現表示了項目和過程控制已經達到了某種水平。當一個目標對應一個關鍵過程域，就稱為"特定目標"；對應整個關鍵過程域就稱為"公用目標"。整個CMMI模型包括了54個特定目標，每個關鍵過程域都對應了一到四個特定目標。每個目標的描述都是非常簡捷的，為了充分理解要求的目標就是擴展"期望"的構件。
"期望"的構件是方法，代表了達到目標的實踐手段和補充認識。每個方法都能映射到一個目標上，當一個方法對一個目標是唯一就是"特定方法"；而能適用於所有目標時就是"公用方法"。CMMI模型包括了186個特定方法，每個目標有兩到七個方法對應。
CMMI包括了10種"提供的信息"：目的，概括和總結了關鍵過程域的特定目標；介紹說明，介紹關鍵過程域的範圍、性質和實際方法和影響等特徵；引用，關鍵過程域之間的指向是通過引用；名字，表示了關鍵過程域的構件；方法和目標關係，關鍵過程域中方法映射到目標的關係表；註釋，註釋關鍵過程域的其他模型構件的信息來源；典型工作產品集，定義關鍵過程域中執行方法時候產生的工作產品；子方法，通過方法活動的分解和詳細描述；學科擴充，CMMI對應學科是獨立的，這裡提供了對應特定學科的擴展；公用方法的詳細描述，關鍵過程域中公用方法應用實踐的詳細描述。
CMMI提供了階段式和連續式兩種表示方法，但是這兩種表示法在邏輯上是等價的。我們熟悉的SW-CMM軟件能力成熟模型就是階段式的模型，SE-CMM系統工程模型是連續式模型，而IPD-CMM集成產品開發模型結合了階段式和連續式兩者的特點。
階段式方法將模型表示為一系列"成熟度等級"階段，每個階段都有一組KPA指出一個組織應集中於何處以改善其組織過程，每個KPA用滿足其目標的方法來描述，過程改進通過在一個特定的成熟度等級中滿足所有KPA的目標而實現的。
連續式模型沒有像階段式那樣的分散階段，模型的KPA中的方法是當KPA的外部形式，並可應用於所有的KAP中，通過實現公用方法來改進過程。它不專門指出目標，而是強調方法。組織可以根據自身情況適當裁剪連續模型並以確定的KPA為改進目標。
兩種表示法的差異反應了為每個能力和成熟度等級描述過程而使用的方法，他們雖然描述的機制可能不同，但是兩種表示方法通過採用公用的目標和方法作為需要的和期望的模型元素，而達到了相同的改善目的。
======================================================================
CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我們指的CMM。CMMI與SW-CMM的主要區別就是覆蓋了許多領域；到目前為止包括四個下面領域：
1．軟件工程（SW-CMM）
軟件工程的對象是軟件系統的開發活動，要求實現軟件開發、運行、維護活動系統化、制度化、量化。
2．系統工程（SE-CMM）
系統工程的對象是全套系統的開發活動，可能包括也可能不包括軟件。系統工程的核心是將客戶的需求、期望和約束條件轉化為產品解決方案，並對解決方案的實現提供全程的支持。
3．集成的產品和過程開發（IPPD-CMM）
集成的產品和過程開發是指在產品生命週期中，通過所有相關人員的通力合作，採用系統化的進程來更好地滿足客戶的需求、期望和要求。如果項目或企業選擇IPPD進程，則需要選用模型中所有與IPPD相關的實踐。
4．採購（SS-CMM）
採購的內容適用於那些供應商的行為對項目的成功與否起到關鍵作用的項目。主要內容包括：識別並評價產品的潛在來源、確定需要採購的產品的目標供應商、監控並分析供應商的實施過程、評價供應商提供的工作產品以及對供應協議和供應關係進行適當的調整。
在以上模塊中，企業可以選擇軟件工程，或系統工程，也可以都選擇。集成的產品和過程開發和採購主要是配合軟件工程和系統工程的內容使用。例如，純軟件企業可以選擇CMMI中的軟件工程的內容；設備製造企業可以選擇系統工程和採購；集成的企業可以選擇軟件工程、系統工程和集成的產品和過程開發。 CMMI中的大部分內容是適用各不同領域的，但是實施中會有顯著的差別，因此模型中提供了"不同領域應用詳解"。
CMM的基於活動的度量方法和瀑布過程的有次序的、基於活動的管理規範有非常密切的聯繫，更適合瀑布型的開發過程。而CMMI相對CMM更一步支持迭代開發過程和經濟動機推動組織採用基於結果的方法：開發業務案例、構想和原型方案；細化後納入基線結構、可用發佈，最後定為現場版本的發佈。雖然 CMMI保留了基於活動的方法，它的確集成了軟件產業內很多現代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯繫。
在 CMMI 模型中在保留了CMM階段式模式的基礎上，出現了連續式模型，這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的瞭解它的過程成熟度。同時，連續模型的採用可以給一個組織在進行過程改進的時候帶來更大的自主性，不用再像CMM 中一樣，受到等級的嚴格限制。這種改進的好處是靈活性和客觀性強，弱點在於由於缺乏指導，一個組織可能缺乏對關鍵過程域之間依賴關係的正確理解而片面的實施過程，造成一些過程成為空中樓閣，缺少其他過程的支撐。兩種表現方式（連續的和階段的）從他們所涵蓋的過程區域上來說並沒有不同，不同的是過程區域的組織方式以及對成熟度（能力）級別的判斷方式。
CMMI 模型中比 CMM 進一步強化了對需求的重視。在 CMM 中，關於需求只有需求管理這一個關鍵過程域，也就是說，強調對有質量的需求進行管理，而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中，3 級有一個獨立的關鍵過程域叫做需求開發，提出了對如何獲取優秀的需求的要求和方法。CMMI 模型對工程活動進行了一定的強化。在CMM中，只有3級中的軟件產品工程和同行評審兩個關鍵過程域是與工程過程密切相關的，而在CMMI中，則將需求開發，驗證，確認，技術解決方案，產品集成這些工程過程活動都作為單獨的關鍵過程域進行了要求，從而在實踐上提出了對工程的更高要求和更具體的指導。 CMMI中還強調了風險管理。不像在CMM 中把風險的管理分散在項目計劃和項目跟蹤與監控中進行要求，CMMI3級裡單獨提出了一個獨立的關鍵過程域叫做風險管理。
worookie edited on 2003-09-25 18:07
CMMI（ Capability Maturity Model Integration）的本質是軟件管理工程的一個部分。軟件過程改善是當前軟件管理工程的核心問題， 50多年來計算的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。基於模型的過程改進是指用採用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。
然而，軟件組織形成一套完整而成熟的軟件過程不是一蹴而就的事情，需要經歷一系列的成熟度。軟件組織首先要進行差異分析，評定自己比較接近哪一個成熟度，然後再根據自身的情況來決定要採取哪些改進活動，來更有效地改進自己的軟件過程。這就對軟件過程的評定提出了一個客觀的標準。美國卡內基梅隆大學軟件工程學院於1987年研究成功的SW-CMM（Capability Maturity Model for Software）就是這樣的一個理論模型，其目的在於幫助軟件組織改善軟件生產流程，以探索一個保證軟件產品質量、縮短開發週期、提高工作效率的軟件工程模式與標準規範。
CMMI是一個可以改進系統工程和軟件工程的整合模式。1997年10月SEI停止對CMM的研究，改而致力於CMMI，以解決使用多個過程改進模型的問題。SEI同時宣佈CMMI將取代CMM，與2000年8月11日頒布了CMMI-SE/SW 1.0版本，2001年12月頒布了1.1版本，這次發佈標誌著CMMI正式啟用,並準備今年內完成CMM到CMMI的過渡。說到CMMI就不能不提 CMM。
CMM
CMM框架用5個不斷進化的層次來評定軟件生產的歷史與現狀：初始級描述了不成熟，或者說是未定義的過程的組織，是混沌的過程以不可預測結果為特徵；可重複級是經過訓練的軟件過程；已定義級是標準一致的軟件過程，以組織內改進項目執行為特徵；已管理級是可預測的軟件過程，以改進組織性能為特徵；優化級是能持續改善的軟件過程，以可快速進行重新配置的組織性能，和定量的、持續的過程改進為特徵。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬於這5個層次中的某一個層次。
CMM包括兩部分"軟件能力成熟度模型"和"能力成熟度模型的關鍵過程域"。"軟件能力成熟度模型"主要是描述此模型的結構，並且給出該模型的基本構件的定義。"能力成熟度模型的關鍵過程域"詳細描述了每個關鍵過程方面涉及的過程域。
可重複級關鍵過程域：需求管理，軟件項目計劃，軟件項目跟蹤和監控，軟件子合同管理，軟件質量保證，軟件配置管理。
已定義級關鍵過程域：組織級過程焦點，組織級過程定義，培訓大綱，集成軟件管理，軟件產品工程，組間協調，同行評審。
已管理級關鍵過程域：定量過程管理，軟件質量管理。
優化級關鍵過程域：缺陷預防，技術更新管理，過程更改管理。
多數組織的基本目標是達到成熟度3級。評估組織當前的成熟度級別的手段之一是軟件能力評估（SCE）。SCE通過評估軟件過程（一般以方針陳述的形式）和項目實踐來確定該組織是否言行一致。組織的過程體現了如實記錄所做的工作，項目實施（對該過程的特定剪裁和解釋）應該證明說到做到。
現在全球許多不同的組織以CMM為協助企業作全面的過程改進活動，除了肯定其軟件成熟度外，更像征具有跨足國際市場的能力。現在通過CMM5級認證的組織達到了一百多家。
CMMI
CMM的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、人力資源、集成產品開發、軟件採購等等，從CMM衍生出了一些改善模型，比如：SW－CMM,SE-CMM,IPD-CMM等。不過，在同一個組織中多個過程改進模型的存在可能會引起衝突和混淆。CMMI就是為了解決怎麼保持這些模式之間的協調。
由業界、美國政府和卡內基·梅隆大學軟件工程研究所率先倡導的能力成熟度模型集成（CMMI）項目致力於幫助企業緩解這種困境。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的重複，增加透明度和理解，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。
與原有的能力成熟度模型類似，CMMI也包括了在不同領域建立有效過程的必要元素，反映了業界普遍認可的"最佳"實踐；專業領域覆蓋軟件工程、系統工程、集成產品開發和系統採購。在此前提下，CMMI為企業的過程構建和改進提供了指導和框架作用；同時為企業評審自己的過程提供了可參照的行業基準。
CMMI的源模型：軟件能力成熟度模型2.0版，C稿；電子行業協會臨時標準（EIA/IS）731；集成產品開發能力成熟度模型（IPD-CMM)。
CMMI的原則：
1． 強調高層管理者的支持。過程改進往往也是由高層管理者認識和提出的，大力度的、一致的支持是過程改進的關鍵。
2． 仔細確定改進目標，首先應該對給定時間內的所能完成的改進目標進行正確的估計和定義並制定計劃。選擇能夠達到的目標和能夠看到對組織的效益。
3． 選擇最佳實踐，應該基於組織現有的軟件活動和過程財富，參考其他標準模型，取其精華去其糟粕，得到新的實踐活動模型。
4． 過程改進要與組織的商務目標一致，與發展戰略緊密結合。
CMMI目標:
1. 為提高組織過程和管理產品開發、發佈和維護能力的提供保障。
2. 幫助組織客觀評價自身能力成熟度和過程域能力，為過程改進建立優先級以及執行過程改進。
CMMI的方法：
1 決定哪個CMMI模型等級最適合組織過程改進需要。
2 選擇模型的表示法是連續式還是階段式。
3 決定組織需要用到的模型中的知識領域。
4 類似CMM提出的過程改進6步，集成化過程改進分成：開始集成過程改進,建造集成改善平台，集成傳統過程，啟動新過程，進行改進評估。
CMMI內容
CMMI內容分為"要求"、"期望"和"提供信息"三個級別，來衡量模型包括的質量重要性和作用。最重要的是"要求"級別，是模型和過程改進的基礎。第二級別"期望"在過程改進中起到主要作用，但是某些情況不是必須的可能不會出現在成功的組織模型中。"提供的信息"構成了模型的主要部分，為過程改進提供了有用的指導，在許多情況下他們對需要和期望的構件做了進一步說明。
"要求"的模型構件是目標，代表了過程改進想要達到的最終狀態，它的實現表示了項目和過程控制已經達到了某種水平。當一個目標對應一個關鍵過程域，就稱為"特定目標"；對應整個關鍵過程域就稱為"公用目標"。整個CMMI模型包括了54個特定目標，每個關鍵過程域都對應了一到四個特定目標。每個目標的描述都是非常簡捷的，為了充分理解要求的目標就是擴展"期望"的構件。
"期望"的構件是方法，代表了達到目標的實踐手段和補充認識。每個方法都能映射到一個目標上，當一個方法對一個目標是唯一就是"特定方法"；而能適用於所有目標時就是"公用方法"。CMMI模型包括了186個特定方法，每個目標有兩到七個方法對應。
CMMI包括了10種"提供的信息"：目的，概括和總結了關鍵過程域的特定目標；介紹說明，介紹關鍵過程域的範圍、性質和實際方法和影響等特徵；引用，關鍵過程域之間的指向是通過引用；名字，表示了關鍵過程域的構件；方法和目標關係，關鍵過程域中方法映射到目標的關係表；註釋，註釋關鍵過程域的其他模型構件的信息來源；典型工作產品集，定義關鍵過程域中執行方法時候產生的工作產品；子方法，通過方法活動的分解和詳細描述；學科擴充，CMMI對應學科是獨立的，這裡提供了對應特定學科的擴展；公用方法的詳細描述，關鍵過程域中公用方法應用實踐的詳細描述。
CMMI提供了階段式和連續式兩種表示方法，但是這兩種表示法在邏輯上是等價的。我們熟悉的SW-CMM軟件能力成熟模型就是階段式的模型，SE-CMM系統工程模型是連續式模型，而IPD-CMM集成產品開發模型結合了階段式和連續式兩者的特點。
階段式方法將模型表示為一系列"成熟度等級"階段，每個階段都有一組KPA指出一個組織應集中於何處以改善其組織過程，每個KPA用滿足其目標的方法來描述，過程改進通過在一個特定的成熟度等級中滿足所有KPA的目標而實現的。
連續式模型沒有像階段式那樣的分散階段，模型的KPA中的方法是當KPA的外部形式，並可應用於所有的KAP中，通過實現公用方法來改進過程。它不專門指出目標，而是強調方法。組織可以根據自身情況適當裁剪連續模型並以確定的KPA為改進目標。
兩種表示法的差異反應了為每個能力和成熟度等級描述過程而使用的方法，他們雖然描述的機制可能不同，但是兩種表示方法通過採用公用的目標和方法作為需要的和期望的模型元素，而達到了相同的改善目的。
======================================================================
CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我們指的CMM。CMMI與SW-CMM的主要區別就是覆蓋了許多領域；到目前為止包括四個下面領域：
1．軟件工程（SW-CMM）
軟件工程的對象是軟件系統的開發活動，要求實現軟件開發、運行、維護活動系統化、制度化、量化。
2．系統工程（SE-CMM）
系統工程的對象是全套系統的開發活動，可能包括也可能不包括軟件。系統工程的核心是將客戶的需求、期望和約束條件轉化為產品解決方案，並對解決方案的實現提供全程的支持。
3．集成的產品和過程開發（IPPD-CMM）
集成的產品和過程開發是指在產品生命週期中，通過所有相關人員的通力合作，採用系統化的進程來更好地滿足客戶的需求、期望和要求。如果項目或企業選擇IPPD進程，則需要選用模型中所有與IPPD相關的實踐。
4．採購（SS-CMM）
採購的內容適用於那些供應商的行為對項目的成功與否起到關鍵作用的項目。主要內容包括：識別並評價產品的潛在來源、確定需要採購的產品的目標供應商、監控並分析供應商的實施過程、評價供應商提供的工作產品以及對供應協議和供應關係進行適當的調整。
在以上模塊中，企業可以選擇軟件工程，或系統工程，也可以都選擇。集成的產品和過程開發和採購主要是配合軟件工程和系統工程的內容使用。例如，純軟件企業可以選擇CMMI中的軟件工程的內容；設備製造企業可以選擇系統工程和採購；集成的企業可以選擇軟件工程、系統工程和集成的產品和過程開發。 CMMI中的大部分內容是適用各不同領域的，但是實施中會有顯著的差別，因此模型中提供了"不同領域應用詳解"。
CMM的基於活動的度量方法和瀑布過程的有次序的、基於活動的管理規範有非常密切的聯繫，更適合瀑布型的開發過程。而CMMI相對CMM更一步支持迭代開發過程和經濟動機推動組織採用基於結果的方法：開發業務案例、構想和原型方案；細化後納入基線結構、可用發佈，最後定為現場版本的發佈。雖然 CMMI保留了基於活動的方法，它的確集成了軟件產業內很多現代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯繫。
在 CMMI 模型中在保留了CMM階段式模式的基礎上，出現了連續式模型，這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的瞭解它的過程成熟度。同時，連續模型的採用可以給一個組織在進行過程改進的時候帶來更大的自主性，不用再像CMM 中一樣，受到等級的嚴格限制。這種改進的好處是靈活性和客觀性強，弱點在於由於缺乏指導，一個組織可能缺乏對關鍵過程域之間依賴關係的正確理解而片面的實施過程，造成一些過程成為空中樓閣，缺少其他過程的支撐。兩種表現方式（連續的和階段的）從他們所涵蓋的過程區域上來說並沒有不同，不同的是過程區域的組織方式以及對成熟度（能力）級別的判斷方式。
CMMI 模型中比 CMM 進一步強化了對需求的重視。在 CMM 中，關於需求只有需求管理這一個關鍵過程域，也就是說，強調對有質量的需求進行管理，而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中，3 級有一個獨立的關鍵過程域叫做需求開發，提出了對如何獲取優秀的需求的要求和方法。CMMI 模型對工程活動進行了一定的強化。在CMM中，只有3級中的軟件產品工程和同行評審兩個關鍵過程域是與工程過程密切相關的，而在CMMI中，則將需求開發，驗證，確認，技術解決方案，產品集成這些工程過程活動都作為單獨的關鍵過程域進行了要求，從而在實踐上提出了對工程的更高要求和更具體的指導。 CMMI中還強調了風險管理。不像在CMM 中把風險的管理分散在項目計劃和項目跟蹤與監控中進行要求，CMMI3級裡單獨提出了一個獨立的關鍵過程域叫做風險管理。
worookie edited on 2003-09-25 18:07
CMM 能力成熟度模型（Capability Maturity Model）
CMM是一種用來評估軟體開發能力的一套標準，企業可以經由使用這套方法以改善軟體的品質及提昇軟體生產力。CMM讓企業能夠在達成產品開發時程及預算的要求下，達成Time-to-market、Cost saving和High Quality 的目標。
CMM是一種軟體開發的流程標準，可說是種軟體開發的品質保証，就像ISO是組織管理的品質保証一樣。細分之下，CMM/CMMI。分成五級，從第一級（Level 1）到第五級（Level 5），分別標示軟體公司流程管理的競爭力程度，一級只要提出申請即可列入，不需經過審查，而到第四級為可做質量管理，第五級則為最佳化，可預防缺陷。
CMM是美國卡內基美隆大學的軟體工程學院（SEI）於1986年所發展而成，是目前國際上最流行和實用的軟體開發設計流程的公認標準和軟體成熟度等級認証標準，同時並已成為軟體量產所不可或缺的工具，更是進軍國際市場所必備的通行證。
http://taiwan.cnet.com/enterprise/glossary/term/0,2000062921,2000054176,00.htm
CMM是一種軟體開發的流程標準，可說是種軟體開發的品質保証，就像ISO是組織管理的品質保証一樣。細分之下，CMM/CMMI。分成五級，從第一級（Level 1）到第五級（Level 5），分別標示軟體公司流程管理的競爭力程度，一級只要提出申請即可列入，不需經過審查，而到第四級為可做質量管理，第五級則為最佳化，可預防缺陷。
CMM是美國卡內基美隆大學的軟體工程學院（SEI）於1986年所發展而成，是目前國際上最流行和實用的軟體開發設計流程的公認標準和軟體成熟度等級認証標準，同時並已成為軟體量產所不可或缺的工具，更是進軍國際市場所必備的通行證。
http://taiwan.cnet.com/enterprise/glossary/term/0,2000062921,2000054176,00.htm
訂閱：
文章 (Atom)