軟體生命周期管理

當前的軟體生命周期不再只考慮瀑布型生命周期，另外常見的軟體生命周期模型有原型模型、螺旋模型、迭代模型。所以當前的軟體生命周期說明應當不再包括瀑布型生命周期中的典型階段。

因此，當前對軟體生命周期及軟體生命周期模型採用如下定義：

● 軟體生命周期是指軟體的產生直到成熟的全部過程。

● 軟體生命周期模型是指人們為開發更好的軟體而歸納總結的軟體生命周期的典型實踐參考。

根據最新發展情況來看，給軟體生命周期帶來最多活力的是敏捷軟體開發，使得這個領域呈現出勃勃生機，出現了一些更好響應變化、迎接競爭的生命周期模型。

敏捷軟體開發明確對生命周期模型提出了要求：短迭代開發。迭代模型的歷史可以追溯到上世紀50年代，但以往的迭代模型並沒有對迭代周期長度提出要求。而在敏捷軟體開發中，迭代周期長度一般不超過2個月，而常見的迭代周期是2周到4周，因此可以稱之為“短迭代”。

有些敏捷軟體開發在主開發過程前安排有預研或計劃或架構或需求階段等等，在主開發過程后安排有系統集成測試或驗收測試或試運行等等，這樣做並不違反敏捷開發原則，但其主開發過程應當採用短迭代開發，而且主開發過程的工期應當佔有顯著的比例，形成多個短迭代。

敏捷開發講究固定的節奏，建議按照固定的節奏開發，所以短迭代的周期長度在開始選定之後，一般不作改變。同樣的原因，敏捷迭代與迭代之間一般不安排緩衝期，上個迭代未完成的內容放到下個迭代中進行處理。

敏捷開發迭代與瀑布生命周期的階段是不同的。瀑布型中需求分析階段的產物一般是需求規格說明書，不同階段的產物是不同的；而敏捷開發迭代的產物是軟體本身，前期迭代的產物也許不完整，但各個敏捷開發迭代的產物是一致的、逐步改進完善的軟體本身。

一些專門用於ALM的軟體套件如圖一所示。

ALM（application lifecycle management）應用程序生命周期管理!

這些軟體生命周期一般從軟體工程文獻中獲得，並可加以修改，使之適於組織的情況。在制定項目定義軟體過程時，這些軟體生命周期可以和組織標準軟體過程結合在一起使用。以標準的流程管理方式，協助降低軟體開發過程中人為造成的開發瑕疵，特別適用於大型應用的開發。包括HP、Borland、Serena、IBM等，都有提供ALM產品。

ALM（adaptive logical module）在FPGA中指自適應邏輯模塊！

然而，由於一般ALM產品多僅考慮到軟體的開發、測試，並未將後端的資料庫系統列入，「讓資料庫程序管理成為軟體開發項目的漏網之魚，」微軟開發工具暨平台推廣處產品營銷經理胡德民說。

「未列入資料庫管理的ALM，已經讓許多開發人員吃足苦頭，」胡德民說。

「以軟體程序代碼版本控管來說，」他解釋道，程序開發人員常需更新程序代碼版本，但是與系統攸關的資料庫結構，卻一直沒有納入一致性的版本控管機制。

缺乏一致性的控管機制，即會加重開發人員的負擔。他舉例說，若資料庫欄位名稱需要變動，將會影響所有會抓取此欄位數據的程序指令，「修正會相當吃力，」他說。

他表示，透過該工具的重構（Refactoring）機制，可使資料庫對象被重新命名后，確保所有參考該對象的程序代碼都會自動變更。

除了自動重構，該工具亦提供了自動化比對兩個資料庫結構的版本異同，以及自動產生大量有意義的測試數據，協助進行質量與壓力負載測試等功能。

對於在大型企業中可能分屬不同單位的程序開發人員與資料庫管理人員，胡德民表示，在ALM納入資料庫管理前，兩方難以協同工作，「偏偏在軟體開發過程中，兩邊卻又常互相影響，」他表示，透過此一工具，將有助雙方的協同作業，改進軟體開發流程。

微軟發表的Microsoft Visual Studio 2005 Team Edition for Database Professionals，為一資料庫程序開發工具，為其ALM產品Visual Studio 2005 Team Edition之新工具，透過該工具，可促進應用程序開發人員與資料庫程序開發人員的協同工作，避免各行其是造成錯誤或瑕疵，為修補、更改而延宕應用程序開發。

Visual Studio 2005 Team Edition for Database Professionals繁體中文版定價為145,900元，搭配MSDN開發人員訂閱服務與軟體升級保證的定價則為230,510元。使用者若為套裝產品Visual Studio 2005 Team Suite之用戶，則可以免費取得該產品授權。此外，微軟另在官網上提供180天試用版供下載試用。

此外，Hansky（中國）公司，在ALM方面也有卓越的方案，其應用生命周期管理（Hansky ALM），管理應用生命周期的所有環節，包含需求、設計、編碼、測試、發布和維護，它能夠極大地提高應用系統的可視化、可用性、可靠性和可管理性，並大大降低成本，從本質上提升管理水平。便於廣大軟體運營商及軟體開發商對整個研發過程有一個獨到的見解。

了解優化的時機

如果你已經熟悉了軟體開發，你就了解了標準，從而謹慎地避免“過早優化”。然而，這意味著在不同的業務模型中有著不同的東西。在Devoxx UKH上Java SE軌跡的領導者 Richard Warburton這樣說，“過早意味著什麼？讓我們看看你正在為一個商業網站做開發。你可能會說（基於可靠的研究）‘如果我們的頁面載入時間超過一定數字，我們就會丟失流量、失去客戶、就會造成虧損。’事先，你可能會很明確地確定出你的時間預算是多少。”

據Richard說，在ALM中你需要進行優化的時間點，是當你的應用根據業務需求變化不能滿足你的要求時。而對於移動應用，你可能需要更早地進行功能優化，如用戶響應能力，它將會影響你的應用聲譽。你可能會以迭代的方式進行優化測試，在移動領域與其它關鍵需求測試一樣。當然，如果應用已經很好了，你不必打亂計劃而去做更多調整，除非它不能滿足業務需求了。這對於那些可能被淘汰的移動應用，或者隨著設備，瀏覽器，網路，或用戶的行為的變化而需要大修改的應用來說，尤其是個真理。

要認識到部署只是一個人的工作

實際上，如果你已經人工部署了一個應用的話，你知道這可能更像是一個10到20人的工作任務。在現代化持續部署的世界中，沒有盡頭是一個惡夢。Serena Software的CEO David Hurwitz說，在這個領域中，世界上的大型組織都開始意識到，當遇到移動部署時，他們是不能只通過手一直做事的。“在過去的幾年中，在沒有自動化的時候，我看到應用部署是多少的勞動密集型的工作，這對於我來說太震驚了。坦率地說，在Serena Software我們的部分大機遇是在2000年進行應用自動化應部署。這對於客戶來說是一個巨大的成功。”

這對於每周，或者甚至是每天者需要更新的移動應用來說很真實。對於移動ALM，如果你一個可靠的預測的話，那就是未來將會自動化的。只需一個開發人員按下一個按鈕就可以啟動一連串的事件，最終應用程序會正確地部署到生產中。ALM中管理將來必須包括在供應鏈中要有更高水平的監督工作，而且應用本身將會有更高的自治能力，如果企業希望加快他們的移動步伐的話。

徠學習識別出合適的技能

當然，其中最重大的障礙是找到了解整個移動開發領域的人才。正如有的文章所講，“組織真正需要的人是他能夠看到整個前景，並相應地架構出移動解決方案，這正在成為一個更加大的挑戰，而不是只是簡單地把有才能的工有經驗的開發人員組成團隊而已。”

但是選擇出正確的團隊成為也是很重要的。我們問了Raymond Augé，他是Liferay的資深軟體架構師，問他在尋找人才中，什麼技能對於員工來說是最關鍵的。他說，技能就是不是你知道什麼，而你認識誰。對於那此與組織以外的新興知識有聯繫，並貢獻於此的開發人員，他們會給團隊帶來更大的業務價值。“這歸結到底就是，不用過多的特殊技術，而是要多了解如何參與於社區當中。”

這在開源領域相關性特別高，在開源領域中，協作讓企業在軟體開發世界中可獲得成千上萬的優秀人員，以便解決他們在移動應用開發中的問題。當然，在這個大型社區中，每個都只看到ALM這個拼圖中的一部分。然而，至少你擁有了大量部分拼圖，這些部分拼圖正是企業移動ALM架構師們需要的，用來獲得更大前景視圖的一部分。