問題定義階段必須回答的關鍵問題:“要解決的問題是什麽?”如果不知道問題是什麽,試圖去解決顯然是盲目的,只會浪費時間和金錢,最後的結果很可能是沒有意義的。盡管明確定義問題的必要性是顯而易見的,但這可能是實踐中最容易被忽視的壹步。
透過問題定義階段的工作,系統分析員應就問題的性質、工程目標及規模提交書面報告。通過對實際用戶和系統用戶的訪談和調查,分析人員簡要寫出自己對問題的理解,並在用戶和用戶的會議上認真討論書面報告,澄清歧義,糾正不正確的理解,最終獲得雙方滿意的文檔。
問題定義階段是軟件生命周期中最短的階段,通常只需要壹天或更短的時間。
2可行性研究
此階段需要回答的關鍵問題:“對於前壹階段確定的問題,是否有可行的解決方案?”為了回答這個問題,系統分析師需要進行壹個大大壓縮和簡化的系統分析和設計過程,即在更抽象的高層次上進行分析和設計的過程。
可行性研究應該相對較短。這壹階段的任務不是具體解決問題,而是研究問題的範圍,探索問題是否值得解決,是否有可行的解決方案。
在問題定義階段提出的項目目標和規模的報告通常是模糊的。在可行性研究階段,應導出系統的高層邏輯模型(通常用數據流圖表示),並在此基礎上更準確、具體地確定項目規模和目標。然後分析人員更準確地估計系統的成本和收益,對提議的系統進行仔細的成本/收益分析是這壹階段的主要任務之壹。
可行性研究的結果是使用部門負責人決定是否繼續項目的重要依據。壹般來說,只有那些可能從投資中獲得更大收益的項目才值得繼續。可行性研究的後期階段將需要更多的人力和物力。停止不值得投入時間的項目,可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體解決問題,而是準確確定“目標系統為了解決這個問題必須做什麽”,主要是確定目標系統必須具備什麽功能。
用戶知道自己面臨的問題,知道自己必須做什麽,但通常無法完整準確地表達自己的需求,更不用說如何用計算機解決問題了。軟件開發人員知道如何使用軟件來滿足人們的要求,但並不完全清楚具體用戶的具體要求。因此,系統分析師必須在需求分析階段與用戶密切配合,充分交流信息,才能得到用戶確認的系統邏輯模型。系統的邏輯模型通常用數據流圖、數據字典和簡要算法來描述。
在需求分析階段確定的系統邏輯模型是未來設計和實現目標系統的基礎,因此它必須準確、完整地反映用戶的需求。系統分析師通常是計算機軟件專家,技術專家壹般喜歡很快開始詳細設計。但是,壹旦分析師開始談論程序設計的細節,他們就會脫離用戶,從而無法繼續提出他們的要求和建議。壹個比較項目所采用的結構分析和設計的方法,為每個階段規定了具體的結束標準,需求分析階段必須提供完整準確的系統邏輯模型,用戶確認後才能進入下壹階段,可以有效防止和克服急於進行具體設計的傾向。
4總體設計
現階段必須回答的關鍵問題是:“壹言以蔽之,這個問題應該如何解決?”
首先,應該考慮幾種可能的解決方案。例如,目標系統的壹些主要功能是meter?1?75?1?7?1?七次結構組織。總體設計階段的第二個主要任務是設計軟件的結構,即確定程序由哪些模塊組成,以及它們之間的關系。通常,用層次圖或結構圖來描述軟件的結構。
5詳細設計
在總體設計階段,以更抽象的方式提出問題的解決方案。詳細設計階段的任務是將解決方案具體化,即回答以下關鍵問題:“這個系統應該如何具體實現?”
這個階段的任務不是寫程序,而是設計程序的詳細規格。該規範的作用與其他工程領域的工程師經常使用的工程藍圖非常相似。它們應該包含必要的細節,程序員可以根據它們編寫實際的程序代碼。
HIPO圖(層次圖加輸入/處理/輸出圖)或PDL語言(過程設計語言)通常用於描述詳細設計的結果。
6編碼和單元測試
這壹階段的關鍵任務是編寫易於理解和維護的正確程序模塊。
程序員要根據目標系統的性質和實際環境,選擇合適的高級編程語言(必要時可以是匯編語言),將詳細設計的結果翻譯成用所選語言編寫的程序,並仔細測試編寫的每個模塊。
7綜合測試
這壹階段的關鍵任務是通過各種類型的測試(以及相應的調試),使軟件達到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試,就是根據設計好的軟件結構,按照選定的策略,將經過單元測試的模塊組裝起來,在組裝過程中對程序進行必要的測試。所謂驗收測試,就是用戶(或在用戶的積極參與下)根據規格說明書(通常在需求分析階段確定)對目標系統的驗收。
如有必要,可通過現場測試或並行操作對目標系統進行進壹步測試和檢驗。
為了使用戶在系統投入生產運行後能夠積極參與驗收測試並正確有效地使用系統,通常需要以正式或非正式的方式對用戶進行培訓。
通過對軟件測試結果的分析,可以預測軟件的可靠性;另壹方面,根據軟件可靠性的要求,也可以決定測試和調試過程何時可以結束。
應該使用正式的文檔來保存測試計劃、詳細的測試計劃和實際的測試結果,作為軟件配置不可分割的壹部分。
8軟件維護
維護階段的關鍵任務是通過各種必要的維護活動,使系統永久滿足用戶的需求。
通常有四種類型的維護活動:糾正性維護,即診斷和糾正使用過程中發現的軟件錯誤;適應性維護,即修改軟件以適應環境的變化;完善維護,即根據用戶的要求對軟件進行改進或擴展,使其更加完善;預防性維護意味著修改軟件,為將來的維護活動做準備。
雖然維護階段沒有進壹步劃分為更小的階段,但實際上每壹個維護活動都要經歷壹系列的步驟,如提出維護需求(或報告問題)、分析維護需求、提出維護需求、提出維護計劃、批準維護計劃、確定維護計劃、修改軟件設計、修改程序、測試程序、評審驗收等,所以本質上是壹個壓縮簡化的軟件定義和開發的全過程。
都要經過提出維護需求(或報告問題)、分析維護需求、提出維護需求、提出維護計劃、審批維護計劃、確定維護計劃、修改軟件設計、修改程序、測試程序、驗收等壹系列步驟。因此,他們基本上經歷了壹個壓縮和簡化的軟件定義和開發的整個過程。