本文同步刊登於 MSDN：http://www.microsoft.com/taiwan/msdn/columns/jhu_ming_jhong/Exam_70-547.htm
前幾期我們將 .NET Framework 2.0 的技術專家考試（Technology Specialist Exam, TS）全部瀏覽過一遍，可以發現，TS 考試最多只考到評估如何使用某些技術，並且如何將技術依需求給實作出來而已，這其實也是 TS 考試的定位，它只是要測驗考生在這項技術有沒有足夠的的知識與實作能力而已，它並沒有測驗到為何使用、評估是否要使用這項技術，以及要在哪些情況下使用這項技術等等，屬於概念與規劃層級的知識，這些知識，都是放在比 TS 考試更高一層的專業級考試（Professional Exam, PRO），這也是 MCTS 要升級到 MCPD 的必經之路。PRO 考試的最大特點，就是不考細節性的東西（程式設計、系統設定或指令等等），它考的是概念、規劃、選擇、應用與維護等等觀念性的知識，也就是考生的規劃、分析與應用能力。
要由無到有設計一個 Web-Based Solution，需要相當多的知識，才能夠設計出能夠解決企業問題的應用程式出來，例如先期的需求分析（Requirements Analysis）、功能點建立與定義（Define Function Points）、企業流程萃取與改良（Fetching and Improving Business Process）、系統規格書（System Specification）、環境的規劃與設計、使用者介面的設計、元件化與可重覆使用性設計、應用程式機能設計、測試到最後部署後的支援等等，背後隱含了許多的重要背景知識，例如資料庫設計（Database Design）、物件導向系統分析與設計（OOAD）、物件導向程式設計（OOP）、分散式系統、軟體測試等等，這些背景知識，再適度搭配 .NET Framework 所提供的服務，才可以設計出具有水準的 ASP.NET Web Application，否則若設計出來的應用程式無法解決企業問題，有寫就和沒寫一樣，還白白浪費了開發預算。
因此，在 PRO 考試中所出現的考題，大多數是以需求導向（Requirement-Oriented）的方式出題，考生只能在題目給定的環境與需求中，去思考最適合的答案，而不像在 TS 考試的答案較具有絕對性。有時可能多個答案才能組合成一個解決方案（也就是正確答案），或者是可能有三個可行的答案，卻只能夠選二個的題目出現。這種題型能夠真正的測驗出考生的實際經驗如何，只有具有充分知識與實務經驗的考生，才可以找的出最適合的答案，也就是最正確的答案。
.NET Framework 2.0 的 PRO 考試共有三科，分別為 70-547（Web Application）、70-548（Windows Application）與 70-549（Enterprise Application）三個科目，每一科都代表一個 MCPD 的認證，也代表通過這些考試的考生，具有特定應用程式的設計與發展能力。
首先，我們就來先瀏覽 70-547 這科考試。
考試背景
Exam 70-547: PRO: Designing and Developing Web Applications by using Microsoft .NET Framework 係以 ASP.NET 與 .NET Framework 服務為基礎，測驗考生應用 .NET Framework 2.0 設計 Web Application 的概念（Concepts）、方法（Methods）、評估（Evaluations）與推行（Delivering）的能力，這些能力構成了 MCPD: Web Developer 所需要具備的技能。
考生應先具備 70-528（TS: Web Client Development）或同等於 70-528 的 ASP.NET 程式設計技能，沒有設計過 ASP.NET 程式的話，是無法規劃與發展出具水準的 ASP.NET Web Application 的，微軟建議考生最好有至少 3-4 年的 Web 應用程式開發經驗，並且有 1-2 年的 .NET Framework 開發經驗。
筆者認為，考生最好有開發 ASP.NET 1.x-2.0 應用程式的經驗，若有考過 70-305（VB）或 70-315（C#）以及 70-300（Solution Design）的話更好，或者是具有同等級的知識，並且已經通過 70-528 的考試。若是在學學生，則建議大學三年級以上，至少要修習過下列課程：
- 系統分析與設計（或物件導向系統分析與設計）。
- 物件導向程式設計（或程式設計課程中有講授物件導向觀念）。
- 資料庫設計（或資料庫管理系統）。
- 網路程式設計（或是講授 ASP.NET 的課程）。
- 管理資訊系統（或是資訊管理導論）。
考試測驗的技能
70-547 的考試多以概念與設計時所需要考量的部份為主要出題方向，出現的程式碼相當的少，目前支援 Visual Basic 與 C# 兩種語言，共分為六大主題。
- 願景化（Envisioning）與設計應用程式。
所謂的願景化（Envisioning），是在開始設計應用程式之前，在和委託開發應用程式的公司或客戶洽談，在需求與功能項目經過討論之後，形成一個應用程式的模型，因為這個模型只停留在紙上階段，尚未付諸實行，所以稱為應用程式願景（Envision of Application），表示未來實作出的應用程式應該要具有這樣的功能。在願景化過程中，可能需要不斷和客戶洽談，將所有的需求都整理出來，在經過分析以後，將主要的需求內容萃取出來，形成應用程式的主要功能（Feature）之一，在需求內部隱含的可能會是相當簡單的一個動作，或者是一個很複雜的商業流程（Business Process），將商業流程萃取並形成一個規則（Rule）是在願景化應用程式過程中的重要程序之一。然而不是所有的需求都需要設計進應用程式中，可能會因為已經有一個現行的應用程式或是因為某些限制（如技術或行為），而無法被實作到系統中，可行性分析（Feasibility Analysis）就是特別針對這類型的需求而進行的，分析過程可能需要經過討論或實驗（Lab Analysis）等等，如果經過可行性分析而認為確實不可行時，其需求可能就要暫時不列入功能項目或是經過修訂，或是對需求的達成程度妥協，但雙方要就這個部份達成協議。
在應用程式願景化模型完成時，要將模型用簡單的方法建構成一個可以評估的小程式（或小系統），這個程序稱為原型化（Prototyping），或稱為可證明概念的原型（Proof-of-concept prototype），這個原型可以供客戶或使用者評估應用程式的適合度，在實作原型的過程中，也可以對使用的技術做可行性的評估，以確定應用程式確實能夠解決企業的問題。
在經過應用程式的原型評估，所用的技術與方向確能符合企業需求時，在原型與功能清單中有列出的功能項目，就可以寫入技術規格（Technical Specification）中，技術規格就是未來設計應用程式時的藍圖與基準。而在技術規格訂定後，藍圖就要變身為設計規格，負責系統設計的人員（SD）就要將這些規格再做進一步的設計，化成一份一份的詳細規格（Detailed Specification），就像是一份建築圖，向下深入到細部的設計詳圖般，每一個功能區都可以深入分為一個或數個細部設計，諸如像是傳統的 DFD，ERD，流程圖或是物件導向設計方法的循序圖（Sequence Diagram）、狀態圖（State Diagram）或關聯圖等等圖說與文字規格，再將這些資料交由程式設計人員（Programmer），按圖施工。
在技術規格化成每一功能區的技術詳細資訊的過程中，在功能區中的每個部份，包含資料（Data）、流程（Process），規則，作業程序以及所使用的技術，方法等等進行細部的評估與設計，包含應用程式分層，資料庫概念與邏輯設計（包含正規化），應用程式互連設計（Interoperability Design），通訊規格設計，資料存取方法等等設計工作，這個部份的設計流程統稱為應用程式邏輯設計（Application Logical Design），在邏輯設計階段完成時，代表應用程式的整個設計規格已經大致底定。
整個應用程式的邏輯設計完成後，就可以開始評估與進行實體設計（Physical Design），實體設計是指將應用程式實際依指定的平台來設計，通常在進行實體設計之前，平台就會先指定好，例如要使用 Windows 平台或是 Linux 平台；使用 Java 或是 .NET；使用 Oracle 或是 SQL Server 資料庫；使用IIS或是Apache Web Server等等，都會影響到邏輯設計付諸到實體設計時的預算與風險程度，也影響到專案的成敗。
願景化與應用程式設計，可以算是整個 Web Application 發展的概念性與方法階段，在整個設計過程中，需要對應用程式的特性、能力以及限制多做評估（即可行性評估），Web Application 有先天的優點，但卻不能忽視缺點，否則設計出的功能可能到最後就無法實作或是被迫放棄等，這些都會被列為專案的成敗指標之一，這也是這個主題所要測驗的部份。
- 設計與開發使用者介面。
使用者介面（User Interface）是應用程式與使用者溝通的重要項目，使用者對應用程式的評價，多放在使用者介面上，方便且具效率的使用者介面可以加速使用者的效率，不方便的使用者介面容易招來使用者的冷眼與罵聲，相信有寫過應用程式的讀者都很清楚。
ASP.NET Web Application 有非常豐富的使用者介面控制項可以使用，開發人員應善用這些控制項來組成使用者介面，以及善用導覽型控制項（例如 Site Map/Menu 或 Wizard 等控制項）以加強使用者的瀏覽便利性。
在資訊界有一句名言：Garbage-In, Garbage-Out (GIGO)，說明了一件事，就是使用者是不可相信的，也就是使用者輸入的資料都要經過驗證，尤其是關鍵性或者是格式有限制的資料，這些資料寫入資料庫時必須要是正確的，否則會在應用程式中產生錯誤的計算或是分析，容易使得使用這些資訊的決策階層錯誤解讀，導致錯誤的決策。若使用者操作錯誤時，應用程式應該適當的給予訊息或指示，同時在應用程式中也需要在表單或是輸入資料的地方給予適切的提示與說明（例如 Tooltip 或是 Message Box 等），說明資訊在應用程式中也佔有重要地位，它是使用者在產生疑惑時的參考方向；而若是應用程式發生例外錯誤（Exception）時，應用程式應該給予一個適當的方法記錄、顯示錯誤的說明，並提供使用者 Feedback 的功能。
控制項的選用與佈置（layout）亦是一個重要的課題，例如哪些控制項可以簡化使用者輸入；哪些控制項可以方便使用者瀏覽（navigation），哪些控制項可以讓使用者對資訊一目瞭然等等，都是要列入使用者介面設計考量，以功能性為主，最後再來思考美觀。使用者的操作環境也是需要評估的，不能因為設計者使用 1280*1024 解析度，就要強迫使用者使用 1280*1024 解析度，也許使用者的電腦螢幕只能上到 1024*768，或者是硬體支援度差等等，在設計使用者介面時，也需要預留一些空間上的彈性。
若沒有設計過 ASP.NET Web 應用程式的話，就很有可能在這個主題失掉很多分數，尤其是選擇正確合適的控制項、是否發展 User Control/Custom Control、以及如何適當的利用 Master Page/Web Part/Scripting 等網頁部件來組合應用程式的問題。
- 設計與開發元件。
元件（Component）是一組程式碼的集合，在 .NET Framework 通常被稱為一個組件（Assembly），為 .NET Framework 應用程式的部署單元，一個元件可以裝載一個或多個類別或控制項，在多數的情況下被用來設計可重覆使用的程式碼元件，在分層次的應用程式中，元件會被應用在資料存取層（Data Access Layer），商業邏輯層（Business Logic Layer），或是工作流程層（Workflow Layer）等地方。
在元件的設計上，除了控制項或視覺化元件（Visual Component）會顯露使用者介面之外，元件是沒有使用者介面的，它們都隱藏在使用者介面後方，負責核心的資料處理與存取等工作，而這些工作都會以 API 的方式，開放給其他的元件或程式碼來存取，而可以被其他元件或程式碼存取的程度，就稱為可重覆使用性（Reusability），可重覆使用性愈高，表示程式碼的設計愈精良，切割的工作更細。
元件的設計要思考的層面很多，像是記憶體的使用（static or general）、使用的範圍、是否要切割，以及其他的考量（如效能，維護性與安全性等等），每一個考量會影響到元件的設計。物件導向設計方法（Object-Oriented Design）經常用在元件設計上，包含屬性（Property）與方法（Method）等等，開放適當的屬性與方法就像是開放適當的途徑般是相當重要的，這些屬性與方法會成為元件的 API，元件之間也會有適當的通訊方法，這就是事件（Event）的設計用意，而元件之間也許會有關聯，而構成物件模型（Object Model）等，元件設計的藍圖擴大時，就會組成像是 Office 般大型的物件庫（Object Base），此時的可重覆使用性就更高了。
考生要注意與元件設計有關的 UML 圖（例如部署圖、類別圖與循序圖等）、如何在元件之間處理例外狀況、以及如何依照給定的需求，適當的設計元件所開放出來的 API（屬性與方法）等部份，OOP 與 OOAD 在這個主題中佔了很重要的地位。
- 設計與開發應用程式機能。
這裡指的應用程式機能（Application Framework）是指一種可以作為應用程式基礎服務的元件與類別庫，通常企業應用程式中都會有一組由許多應用程式所共用或者共享的類別庫或應用程式服務，這種服務就是 Application Framework。
只要是應用程式，就一定會處理到資料，所以資料存取幾乎是一定會在各種應用程式中存在的機能，和資料處理機能相輔相成，並且會經常性的交換資料，構成應用程式中核心的計算、處理與分析能力。
資料處理元件（Business Component）通常是以許多商業規則構成，這些規則都是在需求分析時就萃取出來，構成一組流程或是驗證的依據，商業規則少則數條，多則數百條或上千條，它們在資料存取元件之前，做資料的處理與把關的工作，任何資料在寫入資料庫之前都要被資料處理元件所處理，以確保資料的正確性。資料存取元件（Data Access Component）則負責資料來源的讀寫工作，而資料來源可能會有很多種，像資料庫、檔案、XML、異質性資料（像 IBM Mainframe）、硬體或是其他種類的資料，資料存取元件必須要不受資料來源種類的影響，以支援應用程式的資料層級服務。
事件記錄與例外處理也是相輔相成的一組機能，例外處理負責所有在應用程式中產生的例外狀況，而在應用程式中可能產生的例外相當多且可能無法預測，例外處理的方式也有很多種，要看應用程式的例外處理策略（Exception Handling Strategies），而事件記錄則是要處理由應用程式中發出的事件記錄要求，而記錄的方式也分很多種，像是寫入事件檢視器（Event Log）、資料庫或是檔案等等，所以它可能也會和資料存取元件交換資料；記錄的方式也會受到要記錄的資料所影響，像是效能或是特定的事件資料，可能是 XML 或是圖形資料，這些資料會較適合寫入資料庫。
組態設定元件則是負責應用程式中的所有組態設定，將組態設定與應用程式碼分開可有助於應用程式的可延展性與轉換的便利性，像是連線字串可以寫入組態資料，由組態設定元件讀入程式中，這樣就不必再修改與重新部署程式碼，提高可轉換的程度。
Application Framework 也是一種元件，所以一定會有可延展性以及可擴充性，設計精良的 Application Framework 可以依需求做適度的延伸、發展或是擴充，並且可以為保護程式碼的部份行為，而封閉擴充或繼承的能力。
- 測試與穩定化應用程式。
測試與除錯（Test and Debug）是每個開發專案的必經之路，相信每個開發人員都一定有很多的經驗，在程式碼中找出臭蟲、除錯、再測試、再除錯、…這樣的循環總是在程式開發階段中上演，直到問題排除為止。
在應用程式開發階段進行時，開發團隊可以在小部份的程式碼中開始進行測試，以檢驗程式的正確性，在程式大小愈來愈大時，可以透過像是單元測試（Unit Test）的方式來測試，而模組之間可以利用整合測試（Integrated Test）來驗證模組間整合的正確性。應用程式在發展到一定程度後，為了要能夠事先知道系統的負載程度，通常會進行壓力測試（Stress Test）、負載測試（Load Test），和效能測試（Performance Test）等重要測試工作，通過了層層的測試之後，應用程式才算是穩定。
程式碼檢閱（Code Review）是一個程式碼檢測程序，用來檢驗程式碼中是否有一些暗藏的問題，或是一些可能出問題的地方，例如記憶體裂痕，緩衝區滿溢（Buffer Overflow）等等，同時也可以檢閱有沒有設計中的小瑕疵，經過這樣的檢閱程序，可以增加軟體的品質。
當使用者或測試人員回報軟體發生問題時，開發人員需要由使用者或測試人員提供的資訊，進行錯誤情境重建（Reproduce bug scenario），在錯誤情境重建完成時，開發人員即可以使用除錯器來追蹤程式碼，以找出問題的發生點，並且進行修補；但不是所有的臭蟲都可以在短時間內進行情境重建，或者臭蟲對其他程式碼有相當的影響，此時就算是修補了臭蟲，也需要經過進一步的測試，才可以釋出修正檔，這段修補時間需要列入專案的成本，也需要評估是否要修補的必要。
考生需要注意測試的細節部份，尤其各測試所涵蓋的範圍、程式碼檢閱時找出的問題，以及重現 Bug 所需要的程序與資訊等。
- 部署與支援應用程式。
在應用程式全部完成後，即可進行部署工作，將應用程式安裝到使用者環境中，以 Web-Based 應用程式來說，就是開放讓使用者瀏覽，或是建立 Web 安裝程式，不同的應用程式會有不同的部署方法，同時，也必須要有能力設定好部署的環境以支援應用程式的發展。若應用程式要在大型環境中做部署時，則必須要訂定部署計畫與部署策略（Deployment Strategy），然後按照計畫來執行，這樣才能降低在部署時的衝擊與影響，例如使用軟體原則（Software Policy）來部署應用程式。
但部署完成後也不是就沒事了，後續的支援才正式開始，應用程式將面對現實環境的嚴酷考驗，在正式環境的運作和在實驗室中的測試環境有很大的不同，實驗室環境雖然可以針對目標平台模擬出類似的環境，但是仍然會有一些地方和正式環境有所不同，所以時常要持續的監控與調整，並且在程式出現問題時予以修補，以維持應用程式的正常活動。
考生要注意在應用程式部署時，所處在的系統環境（可能會有防火牆、應用程式伺服器、Cluster、Web Farm 等），會影響到部署的方式與策略，而部署之後的應用程式監控，也是考試重點之一，考生要能夠在給定的條件下找出發生問題的地方（應用程式、網路、I/O 或 CPU 問題）。
準備方法
70-547 考試所需要的基礎知識，大多都分散在各個系統分析與設計的書籍中，而像是資料庫設計與軟體測試的主題，也都有相關的專門書籍探討，考生可能需要多讀一些這方面的書，然後結合 ASP.NET 程式設計的知識，才有利於準備 70-547 這科考試，而微軟官方並沒有對應到這門科目的官方課程，但有出版自學教材，考生可到網路或者有進口原文書的書店找找，可以找的到這本自學教材，微軟也將準備 MCPD: Web Developer 的考試用書集合成一套，考生也可以自行選購。
不過筆者認為，多充實基礎部份的知識，不但對準備這科考試有利，也對接下來的 70-548 與 70-549 有利，因為這三科 PRO 考試，有多數主題考的概念是相似的，但視點（View-point）不一樣，這是 MCPD 的技術分流策略，考生不一定要考到所有的 MCPD 認證，只需要考自己需要的就好了。
在這也要提醒考生，不要把各種應用程式的設計方法混為一談，因為每種應用程式都有不同的設計概念、方法與限制，不能用同樣的眼光來看待。
考試資訊
考試代碼：Exam 70-547
考試名稱：PRO: Designing and Developing Web Applications by using Microsoft .NET Framework
考試題數：40
通過分數：700