發表者

討論內容

冷日
(冷日)

發表時間：2008/3/14 8:41

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM再創軟體品質新典範

ALM專題系列之一　ALM再創軟體品質新典範

應用軟體生命週期的初現，使軟體開發脫離藝術創作的階段，轉而使用工程化的標準流程，並整合角色、流程、工具等各層面。我們後續將探討由週期理論朝向實踐過程中敏捷式開發流程成為主流、 CASE工具自動化、角色專業分工等，各層面之現況與影響，並帶入使用者對應用軟體生命週期的經驗分享，從案例中瞭解企業如何讓使用者、軟體工程師、企業主管等目標一致的實際作法。

使用者期望程式提供穩定的服務

從應用的層面，程式就像一個黑盒子（Black Box），使用者輸入數據，輸出是具商業價值的資料。以生活中的事物比擬，用戶期望程式像販賣機，丟進銅板（數據），選擇渴望的商品（商業邏輯），蹦出來的是解渴的飲料（商業價值）。由此邏輯看待程式與販賣機的共通點是，直覺化使用、處理快速、容易維護、可靠，重點是快速地滿足需求。至於處理的過程是否像科技藝術品般精緻，使用者並不再乎、也感受不到，即使是內建機械手臂的販賣機，使用者得到飲料後便匆忙離去，市場的時間競爭不會讓他們有閒情逸緻欣賞機械手臂選擇商品的過程，並讓人們樂在其中。對使用者而言，美輪美奐的販賣機與鐵盒方塊型的機臺並沒有太大的不同，能提供快速解渴服務的便是好機器。

但事與願違，程式開發技術普及，使用者期望工程師依其需求產生成品，而不是由工程師設計完成，使用者只能依循其邏輯而已。如果需求無法達成，即使程式設計再精巧，使用者也可以另尋高手。

以開放源碼的為例，使用者在網路上即可下載符合需求的軟體，相對於商用軟體供應商，仰賴飛機運送產品光碟到使用者手上，已是數小時後的事了。只是，供應商直到最近才發覺，數小時交貨的歷程中，使用者仍在持續改變需求，這個並反應在產品售價，也就是企業追求的利潤上。

軟體工程師期望程式融入個人創作
過去軟體工程師處心積慮設計軟體，塑造得像是採用機械手臂的販賣機，並期望使用者用心欣賞此「藝術」。當時，撰寫軟體確實是專業資訊工程師的智慧結晶，由於學習此技藝的門檻高，所以程式設計幾乎是個人的創意活動，因此比擬為藝術品般。開發過程從設計、實作到產品，成為高不可攀的藝術殿堂，軟體工程師也成為炙手可熱，許多企業願意重金禮聘的好手。

此時，軟體是少數企業有能力負擔價格，以及專屬的商業利器，代表著商業市場的競爭優勢，工程師僅需專注於設計專屬規格的軟體。以電子商務系統為例，藉由網際網路無國界與無間斷的運作，商業交易僅需要數分鐘即完成，缺少電子商務平臺的企業，最快的交易活動也只是靠飛機傳遞訂單，但飛機的速度永遠無法超越網際網路中傳遞的電子訊號。

企業期望軟體帶來直接獲利

企業經營者不希望軟體工程師花很多時間去琢磨程式的精緻度，卻偏離使用者需求與功能，更注重及時交付與及時上市（Just-in-Time與Time-to-Market），這些因素也正是軟體專案失敗率高達65%以上的原因，其結果是快速消耗企業營運成本，因此企業內各階層主管開始正視問題的成因，並致力尋求解決方法。

此外，企業經營者在獲利逐漸稀釋的過程中，開始精簡人事，並加強個人績效與產能，也就是管理通透化，並將資訊人員也納入評量對象。正如《平衡計分卡》（臉譜出版社）作者Robert Kaplan所說的：「If you can't measure it,you can't manage it.（你無法評量難以量化的績效）」。以往，軟體工程師的工作難以量化，開發活動侷限在企業內部，不受外在市場與顧客的挑戰，但現在經營者更期望工程師能直接面對客戶，即時反應並滿足其需求。

軟體是驅動商業活動的隱形引擎

過去開發時程是軟體工程師面對的重要挑戰之一，許多專案必須花費2~3年開發時間，才能產出一個軟體，這些時間是為了確保能夠達成一定的軟體品質。不過，今日的商業方式必須能夠即時回應客戶需求。特別是多層次（N-tier）架構等高度複雜性的企業應用軟體，必須在不降低品質的條件下，以更短的時間與更精簡的人力完成開發。

對使用者與工程師共通的交集是，雙方均認同「時間就是金錢」，但需求與時間競逐的結果，程式便常發生使用者最不想見到、而工程師難以避免的情況：當機。

面對這個畫面，工程師抱怨使用者因需求定義不明、使用不當，而使用者責怪工程師匆促交付品質欠佳的軟體，兩者各持己見，問題仍無法妥善化解。

應用軟體生命週期邁向全程通透化管理

與其面對市場萎靡不振，軟體供應商期望能夠管理創作的過程，避免專案失控。此外，Robert Martin於《敏捷軟體開發：原則、樣式及實務》（碁峰出版社）一書中提到：「客戶對延宕的時程、增加的預算，及粗劣的品質感到失望；開發人員則為了投注更長的工作時間卻產出更糟的軟體而感到灰心沮喪。一旦經歷過這樣的的慘敗，我們又擔心重蹈覆轍，這樣的恐懼激發我們創造出一套流程，用以約束我們的活動，並要求必要的產出與製品（Artifacts）。」於是軟體開發不但朝向工程化，更邁進全程透明化管理，讓軟體如同工程般可預期其結果。

軟體開發採用流程管理後，便從創意製作走向工程標準，也就是軟體工程化。工程化特性必須有效地結合人員、流程、技術或工具，需要完整的方法論，於是有應用軟體生命週期，涵蓋軟體維護的過程，但也有開發人員將軟體維護視為更廣義的軟體開發。軟體開發朝向工程化與管理面，主要優點是脫離開發技術（例如Java與.NET），及開發工具的束縛。

但在現實環境中，由於臺灣的商業主體充斥許多中小企業，這些企業的軟體開發人員並不多，一般為5~10人。除了團隊規模小，另一種普遍的特性是一人身兼多種開發角色。這些身處中小企業的開發人員，為了因應市場快速變動，大多採用應用軟體生命週期的敏捷式開發方法（Agile Programming）。

善於溝通的工程師軟體、可用的軟體更勝於流程與工具
開發團隊展臂擁抱敏捷式開發流程，並非因為採用強制性的管理手段，以遏止才氣縱橫的天才型軟體工程師，反而是能在彈性的流程中，建立互動合作、積極溝通的開發團隊。

Robert Martin在《敏捷軟體開發：原則、樣式及實務》（碁峰出版社）一書中，開宗明義便帶出由Kent Beck等業界專家創作的《敏捷軟體開發宣言（The Manifesto of the Agile Alliance）》：
●個人及互動勝於流程與工具。
●可用的軟體勝於詳盡的文件。
●與客戶合作勝於合約談判。
●回應變更勝於墨守計畫。

我們可以從以上宣言所建立的4個價值觀中，歸納出敏捷式方法講究務實的作法，也因此，此方法有別於重型流程的開發方法（例如CMM或CMMI）。

我們在
訪談的過程中，也發現中小型企業實現應用軟體生命週期的方法之一，便是採用敏捷式開發流程，並歷經眾多軟體專案的驗證。

這類企業中的資訊主管面對軟體專案的挑戰，對內是致力於激發開發團隊的合作綜效，對外則是快速回應商業環境不斷的變動。然而，對經營者而言，不僅期望軟體開發採用工程化的生產方式，更期待有良善的管理方法，貫穿對內與對外等兩種壁壘分明的環境，而且兼顧利潤。

敏捷式開發流程為企業帶來的啟示，在於即使面對無法遏止的客戶需求變動，此流程採取反覆增益的開發流程，持續性整合與測試，交付符合客戶需求的軟體為優先目標，而達成此目標的方式，是建構團隊比建構以複雜流程或全功能為主的開發環境更重要。文⊙張瑞隆

名詞解釋

「軟體」常與「程式」畫上等號，兩者應清楚地釐清。在資訊領域中，軟體通常包括多個各別獨立的程式、運作所需的相關說明文件、組態設定檔、描述系統結構的系統說明文件等，甚至包括讓使用者更新產品版本的網站等。在應用軟體生命週期中，委託開發廠商交付給客戶的產品，除了上述的產出物與技術文件外，還包括管理文件，特別在客製化的軟體中，使用者需要發展過程的專案管理文件，以便後續的維護，避免過度仰賴委託廠商的牽制。

Ian Sommerville在其《軟體工程，第6版》（碁峰出版社）中，對「軟體工程（Software Engineering）」的定義是，「一門與生產軟體有關的工程學科，範圍從最開始的系統規格制定到系統開始使用之後的維護階段。」除了軟體生產所需的開發工具、方法與理論，也包括非技術性的活動，例如軟體的專案管理。

回覆

冷日
(冷日)

發表時間：2008/3/14 8:42

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM專題系列之二　中小型企業最適用的敏捷式開發流程

ALM專題系列之二　中小型企業最適用的敏捷式開發流程

應用軟體生命週期尋求方法論的解決方案，主要是為了實現管理手段，並整合開發角色、流程、技術等各層面。目前IT領域中，具體實現應用軟體生命週期的流程有兩種：整合的能力成熟度模型（CMMI）與敏捷式開發流程（Agile Programming）。前者適合大型企業或獨立軟體供應商等，具有為數較多的開發人員，以及講求制度的企業文化；後者則適用於各式開發團隊，也就成為我們此次探討的焦點。

應用軟體生命週期的方法論：角色、流程、工具

軟體開發生命週期方法論考量到角色、流程、技術等三個層面。對於中小企業的體質（例如開發團隊人數、企業文化、營運成本等）現況，雖然沒有絕對的方法論可規範軟體開發，我們也無法預期可以找到一個萬用的流程套用在所有專案上，其變因眾多，例如使用的技術、開發團隊的規模與地理位置、開發角色的工作風格、組織文化、市場風險等。此外，因為中小企業開發團隊人數不多，許多專案執行時，每個人常身兼多種角色，而敏捷式開發流程的彈性，則成為主流應用。

至於流程方法，主要是瀑布式（Waterfall Process）與敏捷式（Agile Process）兩種，後者也稱為反覆式（Iterative Process）。基本上企業的開發流程都可歸納為這兩種，只是本身並不知曉而已。這兩種流程的本質差異在於：如何將專案分解成更細小的部分，這也決定產品交付的次數與品質的優劣，瀑布式只交付產品一次，並決定品質與功能是否契合使用者需求；而敏捷式會交付多次，或者稱為多個發行版本（Release），功能會在反覆的開發過程中逐漸完整，而品質也會因為循序式的修正，而減少錯誤。

瀑布式開發流程無法預測軟體品質

以往，多數企業採用瀑布式開發流程，其問題在於軟體開發過程與結果無法事先預測。換句話說，可能在某個階段就偏離客戶需求規格，而團隊渾然不知，也缺乏有效可控管的修正機制。結果是造成重工（Re-work），或專案無法結案，因而耗費大量成本。

由於階段性的過程，所以瀑布式方法在前一階段完成後，才能進入下一階段的流程，而且必須經歷文件製作與核准的作業，耗費不必要的成本。貿然進入下一個階段會使得系統的結構不良。此外，瀑布式將軟體開發分割成多個階段，使專案不具彈性，無法針對客戶需求變更作快速回應。

過去，瀑布式之所以廣為採用，歸因於軟體複雜度低，需求與規格定義明確。如今，客戶很難釐清或清楚說明需求規格，使得許多開發過程常經歷劇烈的需求變動，增加軟體複雜度。許多採用瀑布式開發方法的廠商會向客戶要求，在初期先凍結需求規格，不允許任意的變動而修改規格，或僅能透過專案合約提出正式需求變更（Change Request，CR）表格，並以追加預算的方式執行。早期凍結需求的風險是最終產出物與客戶需求有嚴重的落差。一旦專案進入此階段，最嚴重的狀況是雙方的專案經理在談判桌上針鋒相對，使得專案無法結案，委託者拿到一個品質欠佳的產品，而開發一方也常收不到尾款，兩敗俱傷後收場。

敏捷式開發流程講求與客戶共同開發軟體
敏捷式開發流程特點是程式撰寫與測試為同一個開發循環內相近的活動，撰寫程式的程式人員也順便寫下測試程式。目前許多精巧型的開發團隊更採用測試先於設計，指的是撰寫程式碼之前，先寫測試案例。此測試程式的規格則與使用者討論後所制定，而寫程式是為了讓沒通過的測試案例通過測試，更能契合使用者需求。即使過程中使用者需求不斷更動，但因為使用者也參與過程，以及反覆性的週期，所以不至於產生需求落差。

敏捷式開發流程主要特性是以人為本的開發流程，所以注重開發角色的素質，以及各團隊成員間合作的默契。軟體開發雖然會因為需求變更而反複地變動，但仍遵循特定的流程，使得開發角色可以替換，不至於因為以人為本而疏於管理。為了平順地執行程式撰寫與測試反覆程序，敏捷式採用所謂的搭檔開發（Pair Programming）。這種搭檔方式並不一定是資深搭配資淺，也不是一人撰寫，另一人僅是觀看，而是共同創作、分享技術。

以臺灣的商業體系分類，大型企業動輒50~100人以上的開發團隊，適用CMMI的開發方式，而10人以下的中小型企業則適用敏捷方法，只是這樣的分法並非絕對，以微軟而言，雖然全球將近5000位軟體工程師，仍然可以將其拆開為5~10人左右的小型團隊，並套用敏捷式開發流程。

從市場面，也可以驗證敏捷式的開發方法確實適用。臺灣的軟體市場規模不如歐美，企業並不一定需要功能齊全、複雜度極高的大型軟體，而這類軟體需要大型開發團隊配合整合的能力成熟度模型等嚴密的流程，才能成功地產出。此外，以中小企業為主體的軟體市場，也無法負擔大型軟體的建置費用；由於市場規模小，容易飽和，所以供應商也必須快速推出新版，以吸引用戶購買，獲取利潤。歸納而言，小型團隊與需求頻繁變更，正是敏捷軟體開發方法的重要訴求，另一個現實面則在於，中小企業通常採用人治的管理方式，也就是很仰賴主管的直覺，敏捷式開發方法也正適用以人為本的開發方式。

敏捷式開發流程的特性：自動化的回歸測試、重構、持續整合
在瀑布式模型中，開發人員在需求分析中產生大量文件，到設計、開發、測試等一系列過程。相對地，敏捷式模型的重點在於先產出早期可檢驗與執行的軟體，系統從應用程式的一部份實作開始，特別是優先滿足使用者核心需求的功能，一般稱之為原型（Prototype），隨著客戶需求改變而不斷增加原型的功能。每次過程混合分析、設計、建立、測試等流程，反覆驗證系統架構，以保證客戶的需求，提升軟體品質。

敏捷式開發流程強調務實的、可預見結果的專案過程，使得專案關係人（Stakeholders）可明瞭的軟體開發實際進展情況，而不是憑文件想像軟體概念。在敏捷式開發流程的實務中，軟體團隊最關注的是結果。

依Martin Fowler所建議適合敏捷式開發流程主要特性，包括以下3種：
1.自動化的回歸測試（Automated Regression Tests）
以單元測試為例，單元測試的程式碼大小約等同於產品的程式碼。目前工具已具備這樣的功能。
2.重構（Refactoring）
重構是將一連串小的、可保留行為的轉換動作，實行到程式碼庫的工作方式。目前工具已具備這樣的功能。
3.持續整合（Continuous Integration）
又稱為收斂（Converge），當所有開發角色將程式碼放入程式碼庫時，都會自動啟動建構流程（Build process）。

以目前工具的發展，管理員可以要求各開發角色將程式碼存入中央儲存庫（Repository），系統會自動建立版本，並在建構過程中，列出程式錯誤。目前多數工具也可以執行完整的自動化回歸測試，並將結果包裝成為一個建構版本。文⊙張瑞隆

回覆

冷日
(冷日)

發表時間：2008/3/14 8:42

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM專題系列之三　整合式CASE工具自動化精簡開發流程

ALM專題系列之三　整合式CASE工具自動化精簡開發流程

CASE工具的發展能具體實現軟體開發生命週期，不僅開發過程更自動化，而且已將工具功能逐步結合流程的需求，成為理論轉為實踐的重要關鍵。除了商業版的開發工具，企業也可選擇開放源碼的解決方案，但前者高度整合與技術資源，可免除開發團隊應用工具的技術瓶頸。

實現應用軟體生命週期的CASE工具特性
企業面對CASE工具，常質疑其輔助上的意義，而不是必備的特性，但近來開發工具逐步自動化，卻能減少開發人員處理例行式事務的人力耗費，讓企業體認開發工具的效益。此外，由於敏捷開發方法在反覆增量的過程，更仰賴自動化的輔助，當工具結合流程後，跳脫輔助的角色，便成為開發人員不可或缺的利器。

以往企業面對CASE工具，難以確定應何時導入，以及應用的時機。但現在為了軟體能儘速上市，不僅仰賴工具高度自動化，也必須考量到CASE工具所帶來的成本效益。以下列出目前CASE自動化的主要功能與特色：
●正向工程（程式碼產生）

●逆向工程（由現有程式產生原架構與設計邏輯）
●支援抽象且完整的敏捷式開發流程
●測試模型與自動化
●模型與程式碼的雙向、同步開發
●自動產生文件
●自動建構版本（Build）
●搭檔開發（Pair Programming）
●支援新的塑模標準與模型轉換技術
●第4代程式語言（4GLs）
●中央儲存庫（Repository）

其中最重要的是中央儲存庫，扮演著應用軟體生命週期所需的控管中心，可分為兩個主要部分：資訊儲存庫（Information Repository）與資料字典（Data Directory）。在《系統分析與設計：理論與實務應用》（培生出版社）書中對這兩者的定義，「資訊儲存庫結合了企業的資料與其應用程式組合的所有相關資訊，並提供自動化工具，以管理及控制存取儲存庫。而資料字典是一種電腦軟體，用來管理及控制存取資訊儲存庫。它提供工具來記錄、排序與處理各種資料。」

從以上這些特性，我們可歸納出一個重點，工具的演變將許多瑣碎的工作採用自動化的方式執行，猶如一個專屬的秘書（過去大型專案可能編列秘書這角色的預算），讓程式設計師專注於商業邏輯設計上。然而，自動化的工具並無法協助開發人員針對需求變更的溝通，所以工具逐漸加強塑模的功能，並同時採用UML標準。

ALM藉由工具整合朝向廣度流程趨勢
由於應用軟體生命週期已推出多年，帶動CASE工具功能發展更齊全，也因此，各解決方案的供應商也走向更廣泛的流程整合，以凸顯其特色與優勢。

以Borland為例，目前不僅提供支援完整應用軟體生命週期的CASE工具，未來更將進展為SDO(Software Delivery Optimization)，致力於整合軟體專案控管的廣闊度，以及保有自動化管理的特質。至於CA(組合國際)則將應用軟體生命週期整合資訊服務(Information Service)、安全(Security)、儲存(Storage)等應用層面，延伸生命週期，不單僅侷限在軟體開發與維護。此外，鼎新採取完全客製化內部團隊所需的系統與流程，後續將此方法論結合產品，使客戶也獲得應用軟體生命週期所帶來的高品質。

在CASE工具發展上，無論是商用軟體或開放源碼，均以塑模標準的UML作為溝通，並貫穿整個生命週期。由於塑模工具也邁向自動化發展，除了模型與程式碼雙向互動外，也內建模型轉換技術，此作法有助於以視覺化的呈現程式結構與設計邏輯，減少傳統經由文件或程式碼的溝通不良，並降低開發方向偏離的危險。

CASE工具自動化的限制：專案管理涵蓋度仍需加強
首先，「專案經理」角色的功能還有加強的空間。軟體開發專案產出物（Artifacts）可粗略地區分為兩種：技術性文件與管理性文件，前者主要是架構分析、操作說明、源碼等；後者則包括成本、時程、任務分配、風險、人力組織資源等。目前工具尚無法完整地關聯技術性與管理性的文件，以及同步的版本控管。往後專案經理需要重覆運用最佳實務（Best Practice）時，可能需要在文件儲存庫中遍尋各關聯性文件。

Sommerville提到，CASE工具自動化對軟體工程的改善有限，主要原因有兩個：

1.軟體工程基本是以創意為主的設計活動。現有的CASE工具能夠對例行性的活動做自動化，但完整的設計活動還是需要許多人為的介入。簡單地說，CASE 工具並不像是熱狗製造機，將豬肉與佐料放進入口，便可以期待出口是咖哩味的熱狗，它仍然需要結合軟體工程師的領域知識。

2.在大部分的組織中，軟體工程是一項團隊的活動。軟體工程師必須花許多時間與團隊成員溝通。CASE工具畢竟只是協助工具，僅能增加溝通的管道，但無法絕對地提升溝通效率。文⊙張瑞隆

軟體的Alpha測試與Beta測試
可接受度測試為軟體測試中的階段之一，也是我們所熟知的「Alpha測試」，以單一用戶的使用層面測試程式，直到開發者與使用者都認同軟體符合需求即可。接下來便是稱為所謂的「Beta測試」階段，將程式交由更多的使用者使用，並向開發者回報錯誤。程式可能經過多次的「Beta測試」，以及多次的「Release」等版本，之後便是上市販賣。

「歷久彌新」的測試人員

隨著關鍵性任務為主的應用系統日益複雜，企業更重視軟體品質，使得軟體測試成為開發過程中不可或缺的流程之一。企業也意識到，測試越早規畫，以及頻繁地執行，則開發成本下降越大。相對地，當軟體品質問題越晚發現，後續修正所須付出的代價與成本將以指數性成長。

CASE工具的進展已具備測試功能，原因是應用軟體生命週期將測試列為軟體品質保證的最後一關。敏捷式開發流程更提出，在軟體開發前期，便應擬定基於客戶需求的測試計畫（Test Plan），而且測試與開發是交互執行的，貫穿整個生命週期，並不存在嚴格的先後順序。

以軟體測試顧問服務為主的叡揚資訊，其副總陳志雄提出中肯的建議，軟體測試方法乃是基於數學模型與分析，不因資訊技術更新而有所不同。此外，軟體測試需要豐富的領域知識與經驗，以及高度的敏銳性和直覺，這兩點因素使得專業的測試工程師，抵抗資訊技術潮流快速轉變的衝擊，更不因工具自動化或測試外包而減損其價值，這也是與其他開發角色最大的不同處。對於專注於撰寫程式的開發人員，是個可參考的發展方向。

「黑箱測試」與「白箱測試」

在訪談的過程中，叡揚資訊系統工程師吳欣宇提到，測試依使用案例所設計的測試方法，區分為兩種。「黑箱測試（Black Box Testing）」，顧名思義，工程師已知程式或元件的設計規格，將程式視為一個「黑箱」，測試人員輸入資料後，並比對輸出值，如果結果與預期不一致，表示測試結果成功偵測出程式功能運作上的問題。簡單地說，測試人員只關心程式的功能，而不是實作的技術。
「白箱測試（White Box Testing）」則是針對程式或元件產生測試數據，測試工程師必須瞭解程式結構與實作方式，並分析程式碼，以證明各種功能均符合規格書所述的要求。

應用軟體生命週期解決方案整理表
表中分列各家供應商的解決方案步驟、工具、特色說明與模型圖等，我們可以由其中瞭解每個方案的特色與關鍵技術。(詳見220期iThome)

回覆

冷日
(冷日)

發表時間：2008/3/14 8:43

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM專題系列之四　開發角色轉變：團隊的功勞與工匠的苦勞

ALM專題系列之四　開發角色轉變：團隊的功勞與工匠的苦勞

應用軟體生命週期依流程而搭配專業分工，將以往集一身於大成的開發工作，區分為分析人員、架構人員、開發人員、測試人員與管理人員等。專業分工不僅是配套措施而已，企業在軟體工程化的經驗中，發現專業分工的不足、權責不明，是導致軟體品質低落的因素之一。《人月神話》（經濟新潮社）一書作者Frederick Brooks提到，軟體開發團隊應如同一個外科手術小組，明確定義專業分工的角色與職掌，點明角色與分工的意義。

但我們更應瞭解到，人員與角色的區別。以企業中現行的狀況，無論是一對一或多對一的配置，只要每個角色的業務能準確地執行，縱使一個人負責多個角色仍不至於影響軟體品質，也就是應用軟體生命週期所要達成的目標。舉例而言，一位有歷練與認知的開發人員，當他實施測試工作時，應公正地驗證程式效能，不必然非區分不可，特別是中小企業中，無法負擔大型開發團隊的人事成本，而且敏捷式開發方法也未強制規定角色的配置。然而，分工卻帶來職業生涯上的衝擊。

許多開發人員經歷大學教育與資訊工作的歷練，磨練出撰寫複雜程式的能力，但這個角色的工作因為印度與大陸的崛起，受到就業競爭的挑戰。企業常將例行性、低技術性的程式撰寫工作，委託印度或大陸完成，甚至整個專案均透過外包，而營運中心僅需配置專案經理，供整合與驗收而已。摒除工具自動化，為專業分工的開發角色帶來的職業衝擊，敏捷開發方法更因為一人身兼多種角色的工作，而必須同時瞭解架構、測試、管理等，不僅只是程式撰寫的業務而已。

以下我們將針對應用軟體生命週期主要的角色：分析、架構、開發、測試、管理等，簡述其工作內容，以及其面對變革的職業衝擊。

分析人員釐清客戶需求
分析人員（Analysts）的主要工作負責確認客戶需求，並將需求以文字敘述在文件上，交由架構設計人員規畫軟體規格，簡單地說，分析人員是客戶與架構人員之間的橋樑，以及需求與規格之間的關鍵。過去這個角色的工作由專案經理或業務人員擔任，常由於缺乏技術背景，而造成傳達需求時的落差。此外，現行的許多專案都無法避免劇烈的需求變動，在訊息傳遞失真的狀況下，只會讓錯誤不斷地放大。

目前已可仰賴需求管理工具（Change Management）控管變更的歷史過程，系統並自動化地衍生版本別以分類文件，包括軟體程式碼或模型的連動部分，甚至當客戶取消變更的需求時，系統也可回溯至更動前的版本，減少人力處理與變化的影響。

分析人員在專業分工中所面對的挑戰，在於將客戶對需求的非技術式描述，精確而簡單扼要地表達在文件上。分析人員不一定具備實作的能力，但應熟稔程式開發技術的最新發展，以及各行業的領域知識。由於此工作需要累積經驗，所以不受工具發展的衝擊，也不因新人崛起而取代。

架構人員主導開發方向
架構人員（Architects）主要工作是針對分析師所寫的需求文件，規畫出對應的軟體設計規格（Specification）。為了清楚表達這些規格，架構師可能需要與客戶討論需求概念、與專案經理討論設計議題、與開發人員討論軟體結構特性，以及程式所採用的技術、外觀與風格等，並將規畫以文字寫成規格書，同時也必須撰寫架構設計圖。

同樣地，塑模工具的進展，除了支援統一塑模語言（Unified Modeling Language，UML），協助開發人員採用視覺化的圖形描述軟體的架構設計，也發展出自動化地進階模型處理，例如模型轉換Web Services程式碼等。工具通常已具備正向工程（forward-engineering）與逆向工程（reverse-engineering），前者在寫程式前先畫出UML圖，後者則由已存在的程式碼產生UML圖。相對而言，UML所繪出的模型圖與流程比較，更適合用於專業人員間的溝通，以彌補業務流程的不嚴謹的文件溝通，並且已成為軟體開發塑模標準之一。

架構人員所面對的挑戰，在於將概念上需求具體化為軟體結構模型，此能力仰賴工作經驗中所啟發的專業直覺，塑模工具自動化的發展，僅是取代人工繪製模型圖的低技術工作，無法取代其角色的價值。正如Martin Fowler所描述的，「好的設計師了解系統哪些部分容易受到需求影響而不斷修改，而能把系統中不變與易變的兩個部分隔開，因而控制需求上的變動。」

開發人員專注於實現技術

開發人員（Developers）所負責的工作，在於依規格書或架構設計圖，以程式碼實作出對應的功能或元件，並撰寫說明文件。由於目前程式語言逐漸統一為.NET與Java兩種，開發工具高度自動化，使得入行的門檻低，因而培養眾多的開發人員。

開發工具的發展，不但可由模型轉換程式碼、語法標準檢查、重構等自動化，甚至發生如「SQL Injection」等邏輯錯誤所造成的安全性問題，工具也可自動驗證，降低人工開發的疏失。

此外，開發人員面對的職業生涯衝擊，是所有角色中最高的，除了因為技術標準化，以及工具自動化的影響，使得入行門檻低，工作價值被工具所取代，為數眾多的開發人員也正稀釋其薪資水準。

測試人員扛起品質責任
測試人員（Testers）主要負責確保軟體的正確性、完整性與品質等三種要求。測試流程包括處理程式中的缺陷（Defect）測試與臭蟲（Bug），兩者不同點在於，測試是為驗證缺陷的存在，而偵錯則是找出並修正這些缺陷。

軟體測試過程也歸類為驗證與確認（Verification and Validation，V&V）。其過程可區分為5種：單元測試、整合測試、確認測試、系統測試、驗收測試。除了前兩者通常由開發人員負責完成外，其餘便由專屬的測試人員負責。開發人員與測試人員負責不同的測試過程，並非因為專業分工的要求，而是本質上的不同。開發人員所負責的單元測試主要是為驗證其程式功能在正常運作時的問題，而測試人員則驗證程式在非正常運作下的問題，例如高負載或突然拔掉電源插座。

敏捷式開發極重視自動化測試，工具的輔助也有助於偵察程式設計錯誤。由於現今企業應用系統因網路環境而日益複雜，測試人員面對的挑戰在於複雜系統所產生的突顯（Emerge）錯誤。處理程式或系統錯誤，其實測試人員必須具備通才的本領，包括豐富的程式碼撰寫經驗與對臭蟲的敏感度，有如一位犯罪現場偵查員般，抽絲剝繭找尋開發人員無心犯下的錯誤，甚至是細心設下的陷阱等（例如程式後門），測試人員都要早在使用者發覺前，率先發出警訊。測試人員仰賴每次測試所累積的知識，以至於無法輕易取代。

專案管理人員為團隊的精神領袖

管理師（Managers），一般也稱為專案管理師（Project Manager），本身不參與技術細節，但負責專案的進度、任務分配與團隊成員間溝通/協調/仲裁等，以及掌控風險、成本、時程、產出物等，並撰寫專案計畫書（Project Plan）。

目前專案管理工具可用汗牛充棟來形容，但僅侷限於非技術性文件，與軟體專案產生的技術文件，如需求說明、模型圖、程式碼等，兩者缺乏共通的管理工具。

管理人員的重要性在於帶動各成員的工作熱誠，以免落入例行性或瑣碎的事務，降低工作效率。乍看之下，此角色所需的技能與軟體開發無直接關連，但技術背景的管理人員可憑經驗，瞭解開發時的瓶頸與解決方向，而不至於讓問題懸而未決。此外，由於軟體開發為創意工作，所以會因為個人習慣所影響，因而形成某些特殊的團隊文化，管理人員除了兼顧個人與團隊的差異，也必須避免抹煞創意，這是其無法取代的原因。

客戶需求是開發角色共通的目標
應用軟體生命週期雖講求專業分工，但在循序漸進的過程中，客戶需求一直是共通的目標，無論哪一個角色，只要在其工作中融入領域知識（Domain Know-How），便不至於淪落為供應苦勞的工匠，其工作成效也能展現在主管的評量表。文⊙張瑞隆

回覆

冷日
(冷日)

發表時間：2008/3/14 8:43

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM專題系列之五　「人」是應用軟體生命週期的關鍵

ALM專題系列之五　「人」是應用軟體生命週期的關鍵

對企業而言，採用敏捷式開發方法是實現應用軟體生命週期的方式之一，在反覆淬煉的過程中，逐漸增強軟體品質，但不是用於確保軟體品質。此外，企業莫因為軟體開發工程化，而將人員比擬為另一種形式的工具，相對的，人員依舊是企業的重要資產，與創意來源。

「銀彈」無法解決所有的問題

過去，企業面對天才型或英雄型工程師的職業衝擊，現在將他們歸入流程之下，等於瓦解他們自主的能力，猶如要求一個身經百戰的士兵繳械，情何以堪。然而，人員、流程、工具等三者整合缺一不可，否則應用軟體生命週期形同具文。一些組織避免使用流程，代之以個人英雄主義和他們開發組的天才發揮；另一些團隊過於強調流程，試圖透過給團隊過多的過程來保證成功。之所以企業會有如此大的差異，在於聽信組織變革的神話，以及高估流程變更的能力，與低估其阻力。Frederick Brooks在其著名的《No Silver Bullets》一文中提到，沒有單一的方法論（無論是技術上或管理上），能將現有的軟體開發生產率提高一個數量級。我們知道，單一的解決方案不能解決任何問題，實際上，最終的成功必須包括所有的因素－－在人員（組織）和專案之間取得平衡，不能偏廢。

人治與法治之間的平衡：彈性的流程與以人為主

以法約束人的行為，這是軟體工程化強調流程的出發點，以及必然的趨勢。然而，臺灣本地人情事故管理特性使然，往往注重口頭命令與告誡治理業務，也就是人治。敏捷式開發流程既注重流程（法治），又兼具以人為本（人治）等，兩方都未偏廢。雖然敏捷開發方法不盡然適用所有中小型企業的開發團隊，但其優點是，僅規範原則、保有最大彈性，企業可以適其商業流程、人員習慣、組織特性、應用技術與工具等，逐步調整。

管理的反樣式（Anti-pattern）：人員的互動更勝於流程與工具
敏捷式方法面對3個重要的問題：程序不是很清楚、仰賴自動化工具、以及不重視系統結構，而重視快速滿足客戶需求。雖然軟體品質可以在漸進過程中逐步強化，但開發人員必須具備充足的經驗，以避免在變動過程中迷失方向，成為管理黑洞。

許多軟體團隊的管理者，因循舊式的管理習慣，或因應客戶要求進度，但無法及時交付特定版本的軟體，採用文件敷衍了事，因而過於注重文件化，而非實質的產出物，也就是軟體。敏捷式開發方法注重軟體實質的品質改進，將文件交由工具自動產生。也因此，其採用稱為Martin文件第一法則（Martin’s First Law of Documentation），以防止設計師落入例行性的文書作業：
「除非對文件有立即且重大的需求，否則不產出文件。」

我們曾遇到一個案例，也就是委託者與受委託者達成採用美軍498的軟體專案標準（Mil-498），結案後客戶收到的產出物，卻是塞滿6大箱A3紙箱的各式文件。這些文件其實意義不大，因為很難光從文件回推原設計者的架構，而且仔細閱讀這些文件更是耗時費力的工作。

軟體可以在漸進式的變動中改進品質，但人員可能因為頻繁的變動帶來開發壓力，而造成工作效率低落，因此，敏捷式開發很重視人員的經驗與素質，包括其承受工作壓力的特質。許多敏捷式開發方法下的軟體，是每日建構小型版本，而每周建構大型版本，並在2~3個月結案，交付產品。因為歷程過短，許多階段中衍生的開發經驗無法吸引沉澱，便被迫進入另一個階段，甚至另一個專案。多數時間，開發人員重複運用舊經驗，而沒有時間吸取新經驗，週而復始會造成工作效率不彰。由於軟體設計很講求創意與靈感。我們在採訪使用者經驗的過程中，歸納出共通的認同，均表示敏捷式開發流程的前提是成員對軟體設計有極高的熱誠，甚至超過薪資的回饋。

團隊成員把不斷變動的系統的發展藍圖記在腦海，沒有任何其他方式比面對面的互動更快速、更有效地傳達這些發展藍圖。

敏捷軟體開發宣言第一條便表明：個人及互動勝於流程與工具，「人」方是成功最重要的因素。如果團隊中沒有優秀的成員，就算有好的流程也無法防止專案失敗；但劣質的流程卻也能讓優秀的成員變得毫無效率。良好的合作、溝通與互動比寫程式天份更為重要，程度一般但溝通良好的軟體工程師所組成的團隊，會比一群沒有團隊互動的天才型開發人員更有可能獲致成功。也因此，建構團隊比建構環境更為重要。許多團隊和管理者犯了先建構環境的錯誤，以為團隊就能自動地凝聚成形；相反地，要先創建團隊，再讓團隊根據其需要構建出開發環境。

高品質的軟體：可維護性、延展性、效率、可用性
對企業內部而言，軟體品質是團隊共通的責任。對企業外部而言，軟體必須反應對客戶需求的特性，綜合以上兩點，軟體至少應具備以下幾種特性，才可稱為具有品質的軟體：可維護性（Maintainability）、延展性（Scalability）、效率（Efficiency）、可用性（Usability）。

軟體的聖杯之路：開發時程競賽與異質性整合
Sommerville提到軟體工程正面臨重要挑戰，主要有三種：
1. 傳統的挑戰：
企業面對Legacy System，避免使用極高的成本進行軟體的維護與更新，並且仍然能夠持續提供重要的商業服務。

2. 異質性整合挑戰： SOA企業在資訊系統的發展，久而久之包括各種不同的電腦與對應的支援系統，企業所面臨的挑戰是抉擇適當的技術，並開發軟體有足夠的彈性處理這些異質系統。

3. 開發時程的挑戰： 由於商業活動要求快速回應，造成企業面對軟體品質與開發時程間競賽，而難以兼顧的兩難局面。如何在不降低軟體品質下，以更短的時間開發完成。

另一個重大挑戰則涵蓋以上三種情況，也就是突顯的系統特性。以往各個分離的單一系統，其特性單純且容易描述，當各個子系統整合成大型系統時，由於系統間交互作用，其效應便是所謂的突顯（Emerge）性質。這些特性並不受企業歡迎，因為難以預測，而且會因為系統複雜程度成等比級數成長，難以掌控。軟體開發過程中，通常到後期的上線測試才會出現問題，其成因可能因為新舊系統或異質平臺整合，或在多層次架構設計上，因為不周延而拖累其他系統。

人才是流程的關鍵與企業重要的資產

產品交貨順利與否的關鍵在於人，不是流程。碩網資訊協理葉爾瞻引用Martin Fowler的形容：「方法論者和恐怖份子間的差異是什麼？答案是，至少恐怖份子可以談判。」我們在訪談中歸納出，高度熱誠的開發人員才是成功的秘訣。敏捷式開發並不注重形式化的儀式與專案文件，而是讓工程師在技術實作過程中盡情發揮能力。

在應用軟體生命週期解決方案中，總結地說：人是關鍵，但優秀人才仰賴發掘，而不是培養，這也是工具自動化後無法取代的趨勢。文⊙張瑞隆

藍領與白領的差異
在大陸，資訊領域常區分為三類人才：第一類是資訊技術、管理與領域知識等兼具的「軟件金領」；第二類是系統分析與設計的「軟件白領」，相當於我們所稱的軟體工程師；第三種是熟練撰寫程式碼（彼岸稱為編程）的「軟件藍領」（又稱為基礎程序員或技術工人）。在大陸，許多資訊人員停留在相當於藍領階段，印度也在這個領域有充沛的人力資源。鼎新電腦顧問周忠信認為，專業分工與工具自動化對開發角色的衝擊，將造成開發人員重新界定生涯規畫。

但這些階級區別並非絕對，鼎新電腦的作法是將適合的角色放在適當的職位，或透過潛力開發與教育訓練的方式，協助職員瞭解能力。程式撰寫人員雖然可能面對工具自動化的衝擊，但因為工具僅能產生主要程式碼，具備技術與領域知識的程式設計師仍能保有優勢。

回覆

冷日
(冷日)

發表時間：2008/3/14 8:44

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[分享]ALM專題系列之六　開發經驗談：團隊特質為ALM的關鍵指標

ALM專題系列之六　開發經驗談：團隊特質為ALM的關鍵指標

為了讓大家更瞭解應用軟體生命週期的應用現況，我們採訪鼎新、碩網、HSDC等3家廠商，分別代表大型、中型、小型等軟體開發團隊，探討其實際作法與分享經驗。

大型開發團隊自訂ALM系統
對於跨國性商業為主的企業或獨立軟體供應商，其開發人員可超過100人以上，屬於大型開發團隊，具高度自主的開發實力，不必仰賴其他廠商推動的解決方案。這類企業可傾向自行開發專屬的應用軟體生命週期系統，從需求、塑模到驗證等，以整合本身業務所需的商業運作邏輯為主要考量。我們在直覺上以為大型企業應有充足的IT經費，採購商用工具或導入供應商完整的解決方案，但在此例中，卻發現這類型的企業更重視投資效益，對於商用工具繁複的功能，但不一定完全適用本身的企業內部開發文化，採取自行開發的優點為高度自主與整合能力。

因此，大型開發團隊可將應用軟體生命週期畫分更精細的階段，並配合高度專業分工的角色，以保證軟體品質。此作法不同於敏捷式開發流程所訴求的每日版本建構（Daily Build），而是以開發角色為主，並清楚地定義每個角色的技術與任務，各司其職但又目標一致。鼎新便是其中的代表性案例，針對自有的流程與週期開發專屬的管理系統（DSCALM）。此外，鼎新的管理人員可透過兩種不同的視野了解專案的進展：指標（Indicator）與報表，前者是關鍵績效指標值（KPI），後者則是執行成效。此系統的特點在於貫穿所有流程，使得所有專案關係人都可以一目瞭然地取得專案進展，以避免專案失控。

此外，企業經營者應致力發掘開發人員的潛能，適才適用，而不是任其淪為程式工匠。對於應用軟體生命週期對開發人員的衝擊，周忠信提出建議，開發人員的價值在於完成高品質的軟體，而不是將個人天才型的想法任意置入程式碼中，使得程式異常複雜，讓企業擔負軟體銷售風險。鼎新鼓勵內轉的任用制度，各開發人員以其才能選擇適當職位，盡情發揮長才，降低職業生涯衝擊。

至於業界正流行的「極致開發流程（XP）」，周忠信認為此流程適用於小型的軟體開發案，原因是此流程強調反覆增益快、重構精準、自動測試正確，但又必須保留需求前後一致特性，所以常採用具演化增益的原型，但並非所有開發團隊均認同演化型的流程，以及原型適合用於驗證架構與技術，而不是客戶需求。

中型開發團隊：極致式搭配開放原碼工具
以10~15人組成的開發團隊，可歸類為中型的組織。中型開發團隊導入應用軟體生命週期，目的是加強軟體品質與產品競爭力，例如採用Rational解決方案，以及CMM驗證標準。由於Rational United Processes（RUP）清楚區分各個流程階段與分工角色，缺乏實際運作彈性，以及商業工具難以客製化與整合其他應用工具，所以這類開發團隊也從RUP轉向極致開發流程，並搭配開放源碼工具。這類團隊選擇開放源碼，主要是可取得開發工具原始碼的優點，為使用者提供自主的客製化與整合其他工具時使用，並歷經應用市場的驗證。

以碩網為例，其工具的選擇為：用於專案規畫、追蹤的Xplanner、以開發框架為主的Junit、程式開發平臺的Eclipse等。葉爾瞻提到，商用工具功能雖齊全，但不一定適用於精巧型的開發團隊，至於採用極致開發流程，則是因為此流程以人為本，講求緊密溝通與合作，有助於帶動開發人員的工作熱誠，適合碩網這樣的靈活輕巧的開發團隊。

他也談到天才型或個人英雄主義型的開發人員，不適合極致開發流程，以搭檔編輯（Pair Programming）為例，講究互助合作與分享技術和經驗，並以客戶價值為最終目標。極致開發流程雖然以人為本，但注重團隊合作的熱誠更勝於無法掌控的英雄式作風。

小型開發團隊培養柔軟的思考力
HSDc顧問賴信仁建議，本土的開發人員應邁向架構設計人員，培養抽象化結構設計的能力，他引用Martin Fowler所說：「Keeping Software Soft.」，以避免開發人員陷入「dirty work」的代工苦勞。他也採用80/20法則的觀點分析，本地的開發人員應充實架構設計能力，才能以20%的心力，獲取80%的利潤，擺脫大陸與印度不斷追趕的壓力。

此外，他也推崇極致開發流程。軟體專案常面對的不僅是客戶需求改變，而是客戶所要的，都是開發人員所想不到的。極致開發流程以測試為主（Test First Design），將客戶納入軟體開發週期內，由客戶撰寫測試腳本，並由開發人員實作測試程式，並以增量（Iteration）的改進方式，逐步完成符合需求的功能測試。賴信仁形容極致開發流程的優點是，開發人員持續與客戶討論需求與回饋，在需求不斷改變時，開發人員也不斷釋出新版程式（Release Often），使得原型（Prototype）如同樹木般成長，契合客戶的期望與需求，他稱此過程為「Feedback Loop」。在增量的過程中，開發人員應保持架構與程式碼同步，並不斷地與客戶需求驗證，使得開發人員兼具架構設計與技術實作等多才多藝的能力，展現無可取代的價值。

培養開發團隊的管理思維

軟體專案外包已是無法阻檔的趨勢，臺灣不能故步自封，一昧地抗拒大陸與印度等資訊知識與人才逐漸超越的事實，軟體技術標準化使得領域知識無法藏私，況且這兩地區在軟體工程上更早導入嚴謹的流程制度，以保有軟體代工的優勢。相對地，臺灣正學習這股流程改善的熱潮，但目標著重培養成熟的管理體系與機制，與外包代工業者產生互補效應，而不是形成市場上針鋒相對的競爭者。

此外，軟體專案4大成因：時程、範疇、成本、品質等，除品質是開發團隊可掌控之外，其餘均受客戶需求所限定。由於軟體品質受了前3項的限制，但客戶常壓縮時程，連帶影響範疇與成本，直接衝擊軟體品質，造成開發團隊在品質上偷工減料，反而以客戶容易顯而易見的功能與使用者介面敷衍專案進度，也就是不注重架構設計，並造成客戶在後續維護的高風險與低擴充彈性。如同一棟建築樣品屋，雖然家電、廚具、傢俱樣樣精美且俱全，但鋼骨結構與海沙填充等偷工減料，卻是造成建築物無法承受地震的主因。

品質良好的軟體應呈現簡潔的架構、卻有高度的穩定性，並保有可重覆使用性（Reusability），使得各元件可抽換，展現出如同樹木般生生不息的生命力。在軟體開發上，就是在初期的架構設計時，便將抽象邏輯抽出，以軟體本質思考架構應具有的特性。至於應用軟體生命週期中3個主要元素：人員、流程與工具中，流程與工具僅是實現手段，軟體本質才是根本，並應展現在架構上，也因此，軟體開發應以人為本，而不是廣義的生產工具。文⊙張瑞隆

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

軟工藝術 : [分享]ALM再創軟體品質新典範