[VisualStudio]VS 2010 ALM Overview
思索了一陣子，覺得還是先將整個VS 2010在ALM上的功能做個Overview再開始講內部細節會讓大家看得較為清楚，之後幾篇主要會著重在VS 2010所提供的應用程式生命週期的架構做些介紹。
VS 2010架構圖
下圖為VS 2010的架構圖：
我們可以看到VS 2010分成三個版本：Professional、Premiun、Ultimate，其功能差異如下表，這邊要特別注意的是，若我們要使用之後文章介紹到的內容，你可能都要使用Ultimate的版本，因為Premium或者Professional提供的功能並不完整。
上述的功能有機會我們再一一介紹，但其實最最重要的，是Visual Studio自2008起，已經由單純的IDE(Integrated Development Envoriment)工具逐步轉變成應用程式開發生命週期工具(ALM)，在VS 2003/VS 2005的版本，我們主要使用Visual Studio的程式開發功能來撰寫我們的Code、Design我們的畫面，搭配簡單的VSS來做原始碼的管理(沒有足夠的控管功能)，僅僅這樣，卻已滿足了IDE該具備的多數功能了，但對於應用程式開發生命週期來說，似乎仍少了許多東西。
應用程式生命週期(ALM)
系統分析：需求管理(Issue Tracking)、系統分析工具(Modeling Tool)
(這邊可能會多一個系統架構規劃)
系統設計：模組架構設計(Architecture Tool)、介面設計(Interface Design)、整合設計(Integration Design)等模型設計工具
程式設計：Coding Tool、Debugging Tool、UI Design Tool...
測試：Unit Test、Load Test、Performance Test、Auto Test...
發行：Deployment Tool，一般我們又會分為測試環境(跟PG開發時的環境不同)與Production環境
Control：Source Control、Version Control、Process Control、Document Control...
一個完整的開發週期，應該要進行前述幾項程序，而一套完整的ALM更應該將整個程序給串起來，每個步驟產出的內容應該是對下個步驟有意義的。
資源重複浪費
VS 2005以前的版本，只有提供了程式設計功能、部分的測試功能與部分的發行功能，但在開發過程，還是有許許多多的人為工作，而在Control的部分，過去只有提供Source Control的功能，只幫我們做原始碼的管制，讓同一個人不能同時修改同一份檔案，但重要的Version Control或者Process Control(EX:建構管理的程序)都無法在過程中被落實，讓人感覺有些許的缺漏。
若真的要落實軟體生命週期管理，我們在每個階段都要有特定的產出做為建構項目(CI)，交付下手後開始進入下一個程序，以系統分析為例，我們就需要產出客戶需求列表，而在產出過程，我們可能會使用Use Case/Activity Diagram等UML工具來協助我們釐清客戶需求，關於這部分可以參考我之前的兩篇文章：
[系統開發生命週期]Use Case Diagram概述
[系統開發生命週期]Use Case Diagram補完
既然被稱為生命週期，其運作過程中的每個產出，應該是可交付下手後直接被有效的利用，若我們仍需進行過多的轉化動作，所花費的成本都是一種浪費，舉例來說：系統分析師(SA)使用Use Case或者其他UML工具產出來的系統分析文件，交付系統設計師(SD)後仍需要完整確認整個需求細節，然後重新產生一份系統設計文件；系統設計文件交付給程式設計師(PG)後，系統設計文件上呈現的UI我們仍要透過IDE拉出一樣的畫面，並開始進行Coding，SA交給SD的內容無法re-use；SD交給PG的內容也一樣無法re-use，問題到底在哪邊？主要原因有以下兩者：
1.文件格式不統一
2.管理系統不一致，無法整合
文件格式不統一，有再強的工具都無法針對每種格式的文件進行解讀，而且會花費許許多多的溝通時間，即使使用了UML這一類公定的標準工具來溝通，我們還是需要定義我們自己的規範，例如：Use Case Diagram中要不要使用Include、Extends，或者像寫Code，我們還是要訂出自己的Coding Style，工具只是輔助，使用了工具若沒有良好的規範依循，都是白搭。
管理系統不一致，若系統分析、設計、程式開發、測試、發行、Control等等程序的系統都不相同，我們如何確保彼此之間的溝通是沒有障礙的，如何確保每個簽出都有對應到一個工作項目(Work Item)？如何確保一個SA Work Item結束後會銜接另一個SD Work Item？若系統間不能溝通，過程中我們肯定要自己開發其他系統來管理，也可能增加了許多的人力成本。
資源重複浪費的問題難道沒有得解嗎？有機會的，只要解決以上兩個問題，我們就有機會將資源浪費的比率降到最低，而VS 2008後引入的TFS功能更是大大的加強了這一塊。
VS 2008：加入TFS(Team Fundation Server)整合
TFS有個很大的目地就是要取代生命週期中的Control block，讓我們在開發過程中所有的工作產出都可以受到管制，包含Version Control、Project Control、Configuration Management、Build Management等...
而其中最可貴的我覺得在於它的表單與流程客製化，以ALM來說，上頭這張圖大概是最基礎的程序，我們可以在每個程序中去定義一張表單，紀錄每個角色簽出簽入程式時該填寫的資料，舉例來說：
1.PM會先將專案中的Work Item填入TFS中，並分派給每個角色，並設定好工作項目的前置任務
2.SA依據Work Item A申請了想要修改的SA文件SA001，開始進行修改，修改完畢後簽入系統
3.SD本來想要申請SD001(對應到SA001)，但因為Work Item A仍未被完成，因此SD的Work Item B仍不允許進行，直到Work Item A被完成為止
4.PG則需等到SD001完成才能簽出PG001開始進行修改，整個過程都受到系統的管制
透過這樣的程序管制，我們可以減少許多問題，例如：SA文件還沒改好，SD文件已經先動了，PG的Code也改了，最後規格與程式對不起來；沒有Work Item對應，我們就隨便簽出文件或程式進行修改，版本控管的功能就出現了缺漏；TFS上可以看到自己身上還有多賞WorkItem為完成，可協助工作管制與專案控管...
流程客製化的功能更優，測試的程序每家公司或者每個專案都不太一樣，有些只要經過一道測試步驟就可以出到Production環境，但在我們公司的產品卻需要經過兩道測試步驟，所以在流程上我們就自己多定義了個關卡。
有了TFS，在生命週期管理中，我們還缺了哪些內容呢？沒錯，就是系統分析與系統設計工具在這個解決方案中還沒有被提供，而VS 2010就針對了這兩點上提供了解決方案。
VS 2010：加入Modeling功能
2010中將UML的功能整合到IDE中，包含以下幾種Diagrams：
針對Class Diagram、Sequence Diagram、Use Case Diagram、Activity Diagram、Component Diagram等標準的UML圖型在這邊就不說明了，後續針對有需要補充的內容我們再行補充吧，而Layer Diagram的部分可以參考這篇文章：VSTS 2010 Layer Diagram
到了VS 2010，在VSTS+TFS的加持下，微軟似乎已經推出了一套較為完整的ALM解決方案，2010加強的功能當然不僅僅是Modeling這麼簡單，但以ALM來看，最主要的仍是這一點，這套解決方案在2010推出後，功能性上就算沒有90分應該也有80分了，但我覺得仍有個很關鍵的缺點，這與本主題無關，所以不在本文中提出了。
參考資料：
微軟VS2010投影片
Tutorial: Getting Started with TFS in VS2010
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
