 |
|
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！ |
|
|
恭喜您是本站第 1674142
位訪客!
登入 | 註冊
|
|
|
|
| 發表者 |
討論內容 |
冷日
(冷日) |
發表時間：2008/3/14 8:41 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [分享]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）」的定義是，「一門與生產軟體有關的工程學科，範圍從最開始的系統規格制定到系統開始使用之後的維護階段。」除了軟體生產所需的開發工具、方法與理論，也包括非技術性的活動，例如軟體的專案管理。 |
|
|
|
討論串
|
[分享]ALM再創軟體品質新典範 (冷日