發布日期： 6/23/2005 | 更新日期： 6/23/2005

本頁內容

	簡介
	MSF 簡史
	傳統的方法
	從傳統方法得到的教訓
	我們的解決方案：利用得到的教訓
	擴展可能性
	小結

簡介

Microsoft Solutions Framework (MSF) 是一個將軟件開發流程、原則和公認的做法完全集成的集合，并可以高度自定義和高度擴展，它旨在需要時能隨時隨地為用戶提供他們希望獲得的指導類型。MSF 內外兼收 Microsoft 的公認指導，并與 Visual Studio 2005 Team System 攜手共同為軟件開發生命周期 (SDLC) 內的流程自動化和指導提供無縫的體驗。本文對 MSF 4.0 進行介紹并簡要說明了它的發展歷史，同時討論了傳統方法在執行作為 SDLC 的一部分的流程指導時存在的問題，此外，還與 MSF 中正在采取的方法進行了對比，并提出了一些擴展可能性。

MSF 為改進應用程序開發提供了一套可自定義、可擴展的軟件開發指導。MSF 包括既靈活又正式的方法，允許用戶選擇最適合的途徑。采用 MSF 靈活的框架可以滿足任何項目的需要，同時不必考慮項目的大小與復雜性。MSF 的理念表明：沒有一個單獨結構或流程可以非常好地適用于所有項目的需求和環境。它還認識到指導存在的必要性。MSF 提供本指導不帶有強加說明性的詳細信息，并允許用戶自定義所提供的內容。MSF 組件可以獨立應用，也可以一起應用以提高很多類型項目的成功率。

MSF 的遠景目標是為軟件專業人員提供由軟件專業人員開發的高效、集成和可擴展的流程指導。

?	高效：MSF 的一個關鍵遠景目標是提高人們的工作效率。MSF 的流線型和自定義的流程指導表示，提供對高效性的支持。利用清單和指導（而不是詳細的內容），用戶可以迅速確定完成一項任務或活動的需求。
?	集成：通過整套工具的無縫集成、以及幫助和 MSF 內容的集成，在工具內即可提供解決方案和指導。所有這些元素均可輕松地在 MSDN 及整個工具集的所有方面進行更新。可以對內容本身進行組織，以實現輕松維護。
?	可擴展：流程指導和幫助在 MSF 內是完全自定義的。用戶可以選擇一個靈活或正式的方法，整合基于方案的開發，并通過內容確定他們自己的路徑。

MSF 指導關注的是對“人與流程”的管理。因為軟件開發小組的需要和做法在不斷發展，所以收集到 MSF 中的材料也同步進行不斷地更改和擴展。另外，MSF 與 Microsoft Operations Framework (MOF) 相互配合，從而為操作環境提供平穩過渡，這是長期項目成功的要求。

MSF 簡史

MSF 的元素基于眾所周知的業界最佳做法，并融入了 Microsoft 在高科技行業超過 25 年的經驗。將這些元素設計為協同工作，以幫助 Microsoft 顧問、合作伙伴和客戶解決在整個技術生命周期中遇到的許多重大挑戰。

1994 年，作為 Microsoft 產品開發成果和 Microsoft 咨詢服務工作的最佳做法的松散集合，MSF 被首次引入。從那時起，MSF 就植根于 Microsoft 內部來源（例如，Microsoft 開發團隊、Patterns & Practices 組、Trustworthy Computing、Microsoft Operations Framework 和 Engineering Excellence 組）的成功且實際的最佳做法而不斷發展。外部來源在 Microsoft 開發 MSF 的過程中也起到了重要作用。MSF 合作伙伴委員會 (MSF Partner Council) 的加入對確定 MSF 的方向起到了關鍵作用。MSF 合作伙伴委員會由全球服務集成商（例如，Accenture、Avanade、Capgemini、EDS、Fjuitsu、Infosys 和 Unisys）組成。其他外部來源也影響著 MSF 的未來，這些外部來源包括 Borland、Merrill Lynch、The Agile Alliance 和 The Software Engineering Institute。

MSF 使用這個實際最佳做法池（它已得到 Microsoft 內外的驗證），并對其進行簡化、合并和驗證，以便合作伙伴和客戶可以更加輕松地理解并采用。MSF 現在是一個健壯且成熟的框架，它由 Microsoft 內部一個專門的產品團隊管理和開發，并受到國際顧問委員會主題專家的指導和評審。MSF 也繼續利用當前的 Microsoft 經驗。Microsoft 不同業務方向的其他團隊也經常在內部創建、查找和共享最佳做法和工具。團隊從這些內部項目成果學到的東西可以通過 MSF 合并，并分發到 Microsoft 之外。

傳統的方法

流程的兩個理念和兩個方法

在過去的幾年中，軟件社區中流程的方法發展成兩個基本理念。兩種方法都有相對的優點和缺點。另外，流程的兩個獨立方法在更大的業務環境內得到了發展，一個與軟件行業無關，而另一個則試圖創建以軟件為中心的流程。

靈活流程模型

靈活流程模型是由一個名為 Agile Alliance 的軟件專業人員團體創建的，他們拒絕接受流程比人重要的觀念。靈活流程模型獲得了成功，但這種方法遭受的主要非議是：它的成就可能更多地取決于相關個體的天賦，而不是該流程模型的效力。

正式流程模型

正式流程模型是在業務環境（大部分在軟件開發文化之外）得到發展的。正式方法提供一個公認的框架，但是當應用于 SDLC 時，它會變得很麻煩、很糟糕，可能無法最終產生響應市場并及時交付的高質量軟件。

兩種方法：獨立于軟件，與軟件相關聯

除了上述兩種流程模型之外，開發 SDLC 流程的兩種方法也得到了發展。一種方法開發獨立于軟件行業需求的流程，并創立了“一種流程應對所有行業 (one process fits all industries)”的指導。這種流程與軟件開發相分離，深深依賴于發布的文本和方法。許多軟件專業人員的反應是，問道：“這怎么能適用于我和我的項目呢？”

對創建與軟件開發相關的流程的嘗試也已經步入到臺前。雖然現有的打包流程解決了與 SDLC 相關的問題，但軟件專業人員發現它常常提供太多的信息，以致很難為“實際”軟件開發所理解并適應。

對于軟件專業人員，流程指導最重要的元素是，能夠在正確的時間即時提供與工具支持集成組合在一起的正確指導。流程指導的制定是 MSF 的焦點所在，它是 SDLC 中的日常活動密不可分的部分。

從傳統方法得到的教訓

項目經理經常抱怨流程培訓費用高昂，而且方法不好掌握。當前這種使用現有工具將流程指導合并到 SDLC 的方法，導致了指導經常與幫助和工具本身產生分離。另外，對于用戶來說，映射整個內容的路線不明顯。

鋪天蓋地的內容

現有解決方案中所提供的內容可能不合適、過時且又鋪天蓋地。目前，這樣的內容采用的是“掩埋”法。對于所提供的數量巨大的內容，需由用戶對其進行分類，并從中挑選出與特定項目有關的內容。雖然這種掩埋法試圖讓每個人滿意，但最終卻無人為之喝彩，原因在于它時而靈活，時而卻很笨拙。另外，現有的打包流程指導不容易更新。這經常導致工具幫助、模板和指導之間不匹配。

自定義沒有用或不直觀

SDLC 流程自定義的嘗試難以取得最佳效果。自定義需要首先使用指導，而為自定義提供的示例不夠充分且實際使用價值不大。這經常導致指導一經自定義就無法識別。

在現有的打包流程指導中，用戶沒有自始至終感受到一致的整體體驗。要使自定義的流程進入有用的系統，用戶經常需要做大量的工作。其結果是，靜態流程經常沒有隨著項目技術與環境的變化而變化。這種靜態流程很快就會變得過時，因此也就沒有用處。另外，這種自定義流程僅僅相當于一組 Web 頁。與選定的工具集相集成采取的是一種特定頁面形式，這種頁面專門在流程的上下文中使用軟件開發工具或部署環境。它很少考慮到流程和工具集之間的所有交互。人們使用這個工具時，必須切換到瀏覽器去尋找適當的主題。其結果是有斷開連接的感覺。

相比之下，流程和工具的和諧統一注定 MSF 有一個高效且集成的方法。在 MSF 中，每個操作都會在流程上下文中捕獲到。對某些衡量標準（例如，實際工作與計劃工作、測試覆蓋與錯誤修復、代碼變動與代碼穩定性）可以自動跟蹤，無需進行任何額外的工作。數據會作為日常活動的一部分加以收集。流程需要的、在以前很難進行的任務，現在因 MSF 而變得很簡單、不顯眼、無需費力。

我們的解決方案：利用得到的教訓

MSF 包括了從以前嘗試中得到的重要發現，以便使軟件開發流程正式化，以及合并流程指導。其結果是使 Microsoft 的最佳做法、外部參與者的技術專長和這些重要發現的組合，成為一個可按需提供適當且有用的指導的框架。融入到 MSF 遠景目標的一些重要教訓包括：為維護而設計的內容、一個清楚的元模型、一個清楚的插件模型和許多貫穿整個內容的導航路徑。

為維護而組織的內容

MSF 被設計成能夠按照主觀意愿有效地更新內容。可以輕松地在 MSDN 及整個工具集的所有元素中更新內容。這種同時更新模板、指導和工具幫助的功能，確保了流程指導的所有方面均相匹配。這使得用戶在廣泛使用該集成指導程序包時工作效率更高。

清晰的元模型

MSF 由一個拱形元模型控制。這個框架確定如何將流程指導呈現給用戶，并確保它以一致的方式顯示。使用該元模型，用戶可以輕松地確定他們需要的指導類型，以及項目要求的復雜程度。一旦用戶選擇了一種指導類型和復雜程度，MSF 就可以及時、快速地提供適當的指導。

清晰的插件模型

MSF 提供一種清晰的方式來自定義和“插入”內容。一旦用戶選擇了流程指導的類型和復雜程度，MSF 提供的內容就可以“按原樣”使用，或者對其進行自定義以滿足用戶和項目的特定需要。在 MSF 中，示例內容非常強大而且是相關的，從而給用戶一個堅實的基礎，以便于從中構建高質量的流程指導。

眾多導航路徑

MSF 提供的不只是一個貫穿流程指導的導航路徑，而是各種各樣的路徑，它們會隨著用戶決定的改變而改變。根據用戶的需要，MSF 可以提供十分詳細的“即購即用 (out of the box)”的流程指導，或者較為基本的清單（可以根據項目的要求對這些清單進行自定義）。每次用戶訪問 Visual Studio 2005 Team System 中可用的集成工具時，都可以選擇他們期望在流程指導中擁有的詳細程度和自定義級別。

通過吸取所得到的教訓并利用 Microsoft 的內外資源，Visual Studio 2005 Team System 中的流程集成以一種前所未有的方式為軟件專業人員提供解決方案。

擴展可能性

有了 MSF，流程就不僅僅是文檔。它也證明了自身是一個真正的工具行為變革。如果您在項目開始時選擇流程，則您還選擇了工作流和工作產品，而這些將驅動系統的行為方式。對 SDLC 流程的支持是內置的，這有助于為工作流提供無縫支持。通過將流程集成到團隊成員日常使用的工具中，MSF 降低了采用流程的門檻，從而可以自動收集跨功能的項目衡量標準，而無需與手動報告有關的開銷。MSF 的下列元素可以自定義：

?	流程指導
?	迭代結構
?	進入條件和退出條件視圖
?	工作項類型定義和規則（活動和工作產品）
?	工作項查詢
?	源代碼簽入策略
?	角色群集和安全組
?	文檔模板（Excel 和 Word）
?	Microsoft 項目模板
?	報告
?	項目門戶/SharePoint 站點模板

MSF 使用方法模板來定義各個項目所遵循的流程。沒有一個通用的流程對所有組織甚至一個組織中的所有項目都有效。為了解決這個問題，MSF 提供一個靈活的工具集，它可以使用既靈活又正式的流程。Microsoft 的 Global Solution Integrator 合作伙伴提供他們自己的產品可用的方法模板，您也可以創建自己的方法模板。流程擴展性允許自定義工作項類型、簽入策略、自定義報告和項目管理模板。

小結

通過在正確的時間為正確的人提供正確的流程，MSF 為軟件開發提供了更好的流程指導。基于來自 Microsoft 內部來源和合格的外部來源的成功、實際的最佳做法，MSF 避免了以前試圖使軟件開發流程正式化的缺陷，并且融入了成功的元素。MSF 解決方案為高效、集成和可擴展的流程指導提供了一個框架，同時提供了一個可以使用既靈活又正式的流程的靈活工具集。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=662023