第二章 軟體程序
軟體程序是生產軟體產品的一組相關活動。
軟體程序的基本活動：
1.軟體規格制訂：定義軟體的功能以及運作上的限制。
2.軟體設計與實作：產生符合規格的軟體。
3.軟體確認：必須經過確認是否符合客戶的需求。
4.軟體演進：持續維護及改進，以符合客戶一直在變動的需求。
除了上述活動外，程序的描述可能包含：
1.產品：程序活動的產物。
2.角色：程序相關人員的職責。
3.前置和後續條件：程序活動執行或產品生產前後為真的敘述。
有時軟體程序被分類成計劃驅動式或敏捷式程序。
計劃驅動式：指所有程序活動都是事先經過規劃。（類似結構化）
敏捷式：先定義早期的增量模組，但後續增量模組的開發則是要看進度和客戶的優先順序而定。
2.1 軟體程序模型
軟體程序模型是軟體程序的一種簡化表示方式。每一種程序模型都是以某個觀點來表示其程序，所以只能提供關於該程序的部分資訊。
一般性的模型並不是用來詳細描述軟體程序的，而是適合用來解釋軟體開發各種方法的抽象模型。
2.1.1 瀑布式模型
將規格制訂、開發、確認、演進表示成各個分開獨立的程序階段。
又被稱作「軟體生命週期」：從某階段進入下一個階段是以類似瀑布的方式進行。
基本活動：
1.需求分析與定義
2.系統與軟體設計：系統的設計程序會將需求分割成硬體和軟體系統。
3.實作與單元測試
4.整合與系統測試：經過測式後軟體系統就可以交付給客戶。
5.運作與維護
原則上，每一個階段都會產生一或多份經過核准的文件，這個動作稱為「簽結」（Sign off）。
製作和核准文件的成本使反覆動作的代價非常高，而且必須重做許多工作。有問題的話就留給後面去處理、忽略或用程式來解決。太早凍結需求可能會導致開發的系統不符合使用者的需求。
瀑布式模型的其中一種重要的變型是正規化系統開發，正規化開發程序適合用來開發需要非常嚴格的安全性、可靠性或保全性的系統。
優點：
1.每個階段都有產生文件，換成其他工程程序模型也可以相容。
2.程序可見，經理人可以對照開發計畫掌控進度。
缺點：
1.將專案分割成相互分離的階段，會讓整個專案失去彈性。
2.在程序的早期階段就必須凍結一些成果，所以要回應一直變動中的需求會有困難。
特色：只用在需求非常清楚，而且在開發期間不會經常變動的情況。
2.1.2 增量式開發
讓規格制訂、開發、確認等活動交互進行。
基本概念：先開發出一個初始版本給使用者評估，然後根據使用者的意見再做修改，接著不斷重複這些步驟，直到開發出最適當的系統為止。
優點：
1.可降低為了適應變動中的客戶需求所需要的成本。
2.比較容易得到客戶對目前已完成的開發成果的回應。
3.能夠更快交付和部署有用的部分軟體給客戶。
缺點：
1.程序不是很透明化。
2.系統的結構隨著新的增量模組加入而越來越差。
特色：
1.規格制訂、開發、確認是交錯進行的。
2.是最常見的開發方式。
3.可以是計劃驅動式或敏捷式，或是混合式。
2.1.3 再利用導向式軟體工程
以現有可重複使用的元件為基礎。開發的過程主要是整合這些元件，而非從零開始開發。這種非正式的再利用，與採用何種開發程序無關。
優點：
1.可以減少實際開發的軟體數量
2.降低成本與風險
3.較快完成軟體
缺點：
1.必須妥協需求，系統通常不符合使用者的真正需求。
2.可再利用元件的開發不受組織控制，故元件的新版本可能會對系統的演進造成困擾。
特色：
1.前面的需求規格制訂及後面的確認階段與其他程序相同，但中間是以再利用技術為導向。
(1)元件分析：根據需求規格尋找符合所需的元件。通常只能找到提供一部份功能而非全部的元件。
(2)需求修改：使用找元件所提供的資訊來分析系統的需求，必要時修改需求。若需求不可修改，就返回元件分析活動，尋找其他解決方案。
(3)以再利用方式進行系統設計：設計framework或是再利用現有的framework。（沒有可利用的framework時再設計）
(4)開發與整合：開發無法購得的軟體，整合前面的元件與COST系統來建立出新系統。系統整合部份可能是屬於開發程序的一部份，而非獨立的活動。
2.可以再利用導向式程序中使用：
(1)根據服務標準開發的Web Service，可用在遠端呼叫中。
(2)物件集合package，可與.NET及J2EE整合。
(3)在特定環境下使用的單機軟體系統。
2.2 程序活動
軟體程序由一連串的技術、合作、管理活動交錯而成，整體目標是制訂規格、設計、實作、測試某個軟體系統。
基本程序活動：如何執行下面活動，是依據軟體種類、人員、組織架構而定。
1.規格制訂
2.開發
3.確認
4.演進
2.2.1 軟體規格制訂（software specification）
1.又稱需求工程（requirements engineering）
2.目的：瞭解與定義系統所需的服務，以及系統運作與開發的一些限制條件。
3.需求文件：通常表達為兩種詳細程度。
(1)終端使用者與客戶需要較高階的需求敘述。
(2)系統開發人員需要比較詳細的系統規格。
4.主要活動：（可能是交錯進行）
(1)可行性研究（feasibility study）：
評估目前軟體和硬體技術是否可以滿足使用者的需求。
會從企業觀點來考量提出的系統是否符合成本效益、是否能在預算限制下開發完成。
產生的結果能夠決定此系統是否要繼續做更進一步的分析。
(2)需求抽取與分析（requirement elicitation and analysis）
可透過對現有系統的觀察、與使用者和客戶的討論與工作分析等過程，衍生出系統的需求。
可能會牽涉到一或多個不同系統模型和雛形開發。
(3)需求規格制訂（requirements specification）
將分析活動期間收集到的資訊，轉譯為需求定義文件。含：
a.使用者需求：給客戶端和終端使用者較為抽象的需求敘述。
b.系統需求：詳細描述功能。
(4)需求確認（requirements validation）
檢查需求是否能夠具體實現，以及它的一致性和完整性。
一定會發現需求文件的錯誤，必須修正。
2.2.2 軟體設計與實作
實作：將系統轉換成可執行系統的過程。通常包含軟體設計與程式撰寫。
詳細描述：
1.軟體的結構
2.系統使用的資料模型和結構
3.系統元件間的介面
4.使用的演算法
活動種類將依據被開發系統的類型而變化。
設計中的可能活動：
1.架構設計（architectural design）：找出系統的整體結構、主要元件（有時稱子系統或模組）、它們之間的相互關係，以及它們如何分佈。
2.介面設計（interface design）：
(1)定義系統元件之間的介面。
(2)必須定義清楚，不能有模棱兩可的情況。
(3)有精確的規格後，其它元件才能直接使用，而不必知道它如何實作。
(4)介面規格通過核准，就可以進行各元件的設計和開發。
3.元件設計（component design）：設計每個系統元件要如何運作。
4.資料庫設計（database design）：設計系統的資料結構，以及它們在資料庫中如何表示。
上述活動會產生出一組設計輸出。
程式設計是屬於個人的活動，而且通常沒有通用的程序可以依循。
程式設計人員會在開發完成程式碼時，便立即進行一些簡單測試。如此可以立即發現程式的缺陷，並且馬上修改，這個動作稱為偵錯（debugging）。
1.測試：用來證實缺陷的存在。
2.偵錯：找出位置並且修正這些缺陷。
2.2.3 軟體確認（software validation）
一般稱為「驗證與確認」（Verification and Validation）。
目的：確保系統符合規格與客戶的期望。
確認方式：測試程式本身，也就是讓系統使用模擬的測試資料來執行。可能包含針對軟體程序各階段的各種檢查程序。
大部分的確認成本是發生在系統實作期間和之後。
Verification：符合某規範所得認證，屬於特性規範。
Validation：須符合合約，而隱含規範則不一定要符合，屬於合約需求。
V&V是間接成本。
測試程序：
1.開發測試（development testing）：由開發系統的人員負責測試組成系統的個別元件。每一元件是獨立測試，與其他元件無關。
2.系統測試（system testing）：將元件組成完整的系統。找出元件之間因為非預期的互動所引發的問題，及元件介面問題。
確認系統是否符合功能性與非功能性需求，及測試系統的外顯性質。
3.驗收測試（acceptance testing）：必須使用客戶提供的資料，而非模擬的測試資料速行測試。可能會發現：
(1)系統需求定義中錯誤或遺漏的部份。
(2)系統的能力無法真正符合使用者需求。
(3)系統執行效能令人無法接受。
有時被稱為「Alpha測試」。客製化系統是針對單一客戶開發的系統，它的Alpha測試程序會持續進行，直到系統開發人員和客戶都同意此系統的作符合需求為止。
通常元件的開發和測試是交錯進行的。
公開的軟體產品會進行「Beta測試」，是指將此系統分送給一些同意試用此系統的客戶，再由客戶向系統開發人員回報使用上的問題。
2.2.4 軟體演進（software evolution）
傳統上通常會將程序劃分為２：
1.軟體開發程序
2.軟體演進程序（又稱作軟體維護程序software maintenance）
而現在，開發與維護之間的區別已漸漸不明顯，且將之視為連續性的動作，而非分開的兩個程序。
2.3 適應變更
變更在所有大型軟體專案裡都是無法避免的。
無論使用哪種軟體程序模型，它必須能夠適應軟體變更的要求。
重做（rework）：有些已經完成的工作要重新再來。
降低重做的成本：
1.避免變更（Change avoidance）：在軟體程序中包含能在需要大量重做前，先預期可能出現什麼變更的活動。
2.容忍變更（Change tolerance）：將程序設計成可以較低的成本來適應變更。通常會牽涉到增量式開發。
持續變更的方法：
1.建立系統雛形：對系統或部分系統快速開發一個版本，以檢查客戶的需求和某些設計決策的可行性。支援避免變更，因為允許使用者在系統交付前先試用並修訂他們的需求。
2.增量式交付：支援避免變更和容忍變更。能夠避免對成熟的需求投入太多精力，能讓變更以較低的成本納入後來的增量模組。
2.3.1 建立軟體雛形（prototype）
雛形：軟體系統某個初始版本，通常是用來展示軟體系統的概念、嘗試設計的選項，以及用來瞭解問題和找出解決方案。
事先考慮可能需要的變更：
1.需求工程程序中，使用雛形可以幫助擷取和確認系統需求。
2.系統設計程序中，使用雛形有助於尋找軟體的解決方案和支援使用者介面設計。
為了試用系統或檢查所提出設計的可行性，可能會使用系統雛形來確認。
建立雛形對使用者介面的設計程序也是必要的，因為使用者的介面動態本質不適合使用靜態文件說明和圖表來表達使用者介面需求。
不可將拋棄式雛形交付給客戶，原因：
1.開發雛形時通常會忽略非功能需求。
2.開發雛形時因為需要快速修改，因此雛型通常不會有說明文件，唯一的設計規格就是雛形的程式碼。
3.開發雛形期間所做的修改，可能會讓系統結構變差，導致系統不容易維護和維護成本變高。
4.在開發雛形時通常會放寬組織所訂定的品質標準。
2.3.2 增量式交付
特色：
1.將部份已經開發好的增量模組交付給客戶，並部署到實際營運環境中開始使用。
2.由客戶定義出一系列的交付增量模組（delivery increment），每個增量模組可提供一部份的系統功能。
3.定義好優先順序，由優先順序最高的服務最先交付給客戶使用。
4.客戶先用完成的功能，能夠更清楚的知道後面增量模組的需求，或是釐清對目前這個增量模組的改版需求。
優點：
1.客戶可以把最早的增量模組視為雛形，從這個雛形中獲得一些開發後續增量模組的經驗。系統完成後，客戶不必再重新學習。
2.客戶不需要等到整個系統完成之後才開始使用。
3.程序保有增量式開發的優點，為系統進行變更會較容易。
4.因為具有最高優先順序的模組會先交付給客戶，而後續的模組再與它整合，所以最重要的系統會被測試最多次。系統重要的部份不會遇到軟體故障問題。
缺點：
1.很難先定義出所有增量模組都會需要的共用工具。
2.若是要取代舊系統，而使用者要的功能可以在舊系統上使用，經常出現不願意試一個不完整的新系統的情況，所以反覆式開發會有困難。
3.反覆式程序的本質是將規格與軟體一起開發，通常會要求在系統開發合約中要包含完整的系統規格，會與很多機構的採購模式相衝突。
2.3.3 螺旋式開發
不是將軟體開發程序以一連串的活動來表示，而是以螺旋的方示來表示，螺旋的一個迴圈代表軟體開發程序中的一個階段。
分成四個部分：
1.目標設定：定義專案目前階段的特定目標、找出程序和產品的限制、規劃詳細的管理計劃、確認專案的風險、根據風險可能需要規劃出替代策略。
2.風險的評估與降低：對專案的每個風險進行詳細分析，並採取降低風險的步驟。
3.開發與確認：風險評估後，就可以為此系統選擇適當的開發模型。
4.計劃：審查此專案，並決定是否繼續進行下一個螺旋迴圈，若決定繼續進行，必須擬出此專案下一個階段的計劃。
螺旋模型在程序中明確的考慮到開發的風險。
2.4 Rational Unified Process（RUP）方法
為現代程序模型的範例之一，由UML和相關的Unified Software Development Process衍生而來。
三個觀點：
1.動態觀點：顯示模型隨著時間經過的各階段。
2.靜態觀點：顯示進行的程序活動。
3.經驗觀點：建議在程序期間可採用的良好經驗。
RUP大部份描述是嘗試在同一個圖形中，合併靜態和動態的觀點。
RUP是一種階段性的模型，它定義軟體程序中４個分離的階段：
1.起始階段：為系統建立一個企業案例。
2.細述階段：瞭解問題領域、為系統建立架構體架、開發專案計畫並找出專案主要的風險。（UML、結構的描述、軟體的開發計畫）
3.建構階段：進行系統設計、程式設計與測試。（系統的各部份是平行開發再整合）
4.轉變階段：讓系統上線運作。（成本很高、易出問題）
基本的最佳經驗：
1.以反覆方式開發軟體
2.要管理需求
3.使用以元件為基礎的架構
4.視覺化的模型軟體
5.檢驗軟體品質
6.控制軟體的變更
2013/7/17 8:57 第一次編輯
2013/12/3 5:53 第二次編輯
2013/12/4 2:10 完成編輯
沒有留言:
張貼留言