軟體開發周期介紹

從時間角度對軟體開發和維護的複雜問題進行分解，把軟體開發的漫長周期依次劃分為若幹個階段，每個階段有相對獨立的任務，然後逐漸完成每個階段的任務。

從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發；前一個階段任務的完成是後一個階段工作的前提和基礎，而後一個階段任務通常是使前一階段提出的解法更進一步的具體化，加進了更多的實作細節。

生命周期各階段的基本任務：問題定義→可行×××→ 需求分析→ 總體設計（概要設計） → 詳細設計→ 編碼和單元測試→ 綜合測試→ 軟體維護。

問題定義階段必須回答的關鍵問題：“要解決的問題是什麼？”。問題定義階段是軟體生存周期中最簡短的階段，一般隻需要一天甚至更少的時間。問題定義階段的工作，系統分析員應該提出關于問題性質、工程目标和規模的書面報告。通過對系統的實際使用者和使用部門負責人的通路調查，分析員扼要地寫出他對問題的了解，并在使用者和使用部門負責人的會議上認真讨論這份 書面報告，澄清含糊不清的地方，改正了解不正确的地方，最後得出一份雙方都滿意的文檔。

這個階段要回答的關鍵問題：“對于上一個階段所确定的問題有行得通的解決辦法嗎？”。可行×××應該比較簡短，個階段的任務不是具體解決問題，而是研究問題的範 圍，探索這個問題是否值得去解，是否有可行的解決辦法。

可行×××階段應該導出系統的高層邏輯模型（通常用資料流圖表示），并且在此基礎上更準确、更具體地确定工程規模和目标。

可行×××的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，隻有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行×××以後的那些階段将需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。

這個階段的任務仍然不是具體地解決問題，而是準确地确定“為了解決這個問題，目标系統必須做什麼”，主要是确定目标系統必須具備哪些功能。

系統分析員在需求分析階段必須和使用者密切配合，充分交流資訊，以得出經過使用者确認的系統邏輯模型。通常用資料流圖、資料字典和用例圖表示系統的邏輯模型。

使用者了解他們所面對的問題，知道必須做什麼，但是通常不能完整準确地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實作人們的要求，但是對特定使用者的具體要求并不完全清楚。

在需求分析階段确定的系統邏輯模型是以後設計和實作目标系統的基礎，是以必須準确完整地展現使用者的要求。

總體設計也稱為概要設計，這個階段必須回答的關鍵問題是：“概括地說，應該如何解決這個問題？” 。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上，推薦一個較好的系統（最佳方案），并且制定實作所推薦的系統的詳細計劃。

總體設計階段的第二項主要任務就是設計軟體的結構，也就是确定程式由哪些子產品組成以及通常至少應該考慮下述幾類可能的方案：

Ø  低成本的解決方案。系統隻能完成最必要的工作，不能多做一點額處的工作。

Ø  中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很友善，而且可能還具有使用者沒有具體指定的某些功能和特點。雖然使用者沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中将證明是很有價值的。

Ø  高成本的“十全十美”的系統。這樣的系統具有使用者可能希望有的所有功能和特點。

詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實作這個系統呢？” 。

這個階段的任務還不是編寫程式，而是設計出程式的詳細規格說明。

規格說明的作用很類似于其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程式員可以根據它們寫出實際的程式代碼。通常用類圖、時序圖、協作圖、狀态圖、活動圖等等描述詳細設計的結果。

這個階段的關鍵任務是寫出正确的容易了解、容易維護的程式子產品。

程式員應該根據目标系統的性質和實際環境，選取一種适當的進階程式設計 語言（必要時用彙編語言），把說細設計的結果翻譯成用標明的語言書寫的程式，并且仔細測試編寫出的每一個子產品。

在這一階段我們會使用設計階段各種UML表示的分析和設計模型，換成某種面向對象程式設計語言的代碼，在對UML表示的分析和設計模型進行轉換時，最好不要直接把模型轉化成代碼，因為在早期階段，模型是了解系統并對系統進行結構化的手段。

這個階段的關鍵任務是通過各種類型的測試及相應的調試，是軟體達到預定的的要求。

最基本的測試是內建測試和驗收測試，通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果儲存下來，做為軟體配置的一個組成成分。

所謂內建測試是根據設計的軟體結構，把經過單元測試檢驗的子產品按某種標明的政策裝配起來，在裝配過程中對程式進行必要的測試。

所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段确定），由使用者（或在使用者積極參加下）對目标系統進行驗收。必要時還可以再通過現場測試或平行運作等方法對目标系統進一步測試檢驗。

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足使用者的需要，通常有四類維護活動：

Ø  改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；

Ø  适應性維護，即修改軟體以适應環境的變化；

Ø  完善性維護，即根據使用者的要求改進或擴充軟體使它更完善；

Ø  預防性維護，即修改軟體為将來的維護活動預先做準備

雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，确定維護計劃，修改軟體設計，修改程式，測試程式，複查驗收等一系列步驟，是以實質上是經曆了一次壓縮和簡化了的軟體定義和開發的全過程。在這階段可能會用到元件圖和部署圖。

軟體項目開發有三個要素：符号、工具和方法，符号就是UML具有表現力的圖形模組化語言，工具UML等等CASE計算機輔助工具，可以幫助我們實作正向工程（從模型生成代碼）、返向工程（從代碼生産模型）等等功能，我們在上一章中已經介紹過的Rose和Jude等等。還有一個要素就是方法，我們無論做任何事情都要講究方法，軟體項目開發更是應該講究方法。下面我們介紹現在比較流行的軟體開發方法學問題。