二、結構化生命周期方法
結構化分析與設計方法在軟件工程中應用已很普遍，并且越來越成熟。有許多大、中型項目都采用了這種方法進行開發(fā)并取得了顯著的成果。
按B.W.Boehm的描述，瀑布模型的的軟件生命周期可劃分七個階段:系統(tǒng)需求分析、軟件需求分析、概要設計、詳細設計、編碼、測試和運行維護。
（一）系統(tǒng)需求
“系統(tǒng)需求”包括:問題定義、可行性研究及軟件計劃。
1.問題定義
軟件開發(fā)的第一步就是進行問題定義。問題定義階段必須回答的關鍵問題:“軟件要解決的問題是什么?”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最常被忽視的一個步驟。這里所說的問題，就是指用戶的基本要求。說得通俗些，問題定義實際上就是了解用戶到底要建立什么系統(tǒng)，并確定分析員下一步應該做什么。因此，問題定義的來源是用戶。
通過問題定義階段的工作，系統(tǒng)分析員應該提出關于問題性質(zhì)、工程目標和規(guī)模的書面報告。這一階段的分析員應盡可能站在較高的角度去抽象、概括所要干的事情，不要拘泥于問題實現(xiàn)的細節(jié)。盡管用戶可能總是習慣于這樣做，但分析員在這一階段必須超脫出來，居高臨下鳥瞰系統(tǒng)的全貌。通過對系統(tǒng)的實際用戶和使用部門負責人的訪問調(diào)查，分析員扼要地寫出他對問題的理解，并在使用部門負責人的會議上認真討論這份書面報告，澄清含糊不清的地方，改正理解不正確的地方，最后得出一份雙方都滿意的文檔。
當用戶的要求不是很多并且不太復雜時，一兩個分析員用上一兩天就可以完成這一工作了。但當系統(tǒng)比較大，且復雜時，恐怕就要組織一個問題定義小組，花上一兩個星期，甚至數(shù)月來定義用戶的問題。
如果分析員和用戶及使用部門的負責人對所要解決的問題取得完全一致的看法，而且使用部門的負責人同意開發(fā)工程繼續(xù)進行下去，那么開發(fā)工程將轉(zhuǎn)入生命周期的下一個階段———可行性研究。
2.可行性研究
并不是所有問題都有簡單明顯的解決辦法，事實上，許多問題不能在預定的系統(tǒng)規(guī)模之內(nèi)解決。如果問題沒有可行的解，那么花費在這項開發(fā)工程上的任何時間、資源、人力和經(jīng)費和都是無謂的浪費。
可行性研究的目的在于用最小的代價確定在問題定義階段所確定的系統(tǒng)的目標和規(guī)模是否現(xiàn)實，所確定的問題是否可以解決，系統(tǒng)方案在經(jīng)濟上、技術上和操作上是否可以接受�？尚行匝芯恐貙θ缦戮唧w方案考慮:
（1）經(jīng)濟可行性。估計開發(fā)費用以及新系統(tǒng)可能帶來的收益，將兩者進行權衡，看結果是否可以接受。
（2）技術可行性。對要求的功能、性能以及限制條件進行分析，是否能夠做成一個可接受的系統(tǒng)。所考慮的因素通常還應包括開發(fā)的風險，是否能夠得到需要的軟件和硬件資源和一個熟練的有能力的開發(fā)隊伍，與系統(tǒng)開發(fā)有關的技術是否足以支持系統(tǒng)的研制。技術可行性的估計，需要有經(jīng)驗的人員去完成。
（3）操作可行性。判斷系統(tǒng)的操作方式在該用戶組織內(nèi)是否可行。
分析、設計人員應以新系統(tǒng)的目標和作用范圍為依據(jù)提出一種以上的設計方案，從技術可行性、經(jīng)濟可行性、操作可行性等方面進行比較，并選擇出綜合最優(yōu)的方案。
根據(jù)可行性研究結果要做出的決定是:是否繼續(xù)按預定目標進行這項開發(fā)工程，可行性分析人員必須清楚地表明他對這個關鍵性決定的建議。如果認為值得繼續(xù)進行這項開發(fā)工程，則應提供選擇一種最好的解法并說明理由�？尚行苑治鍪窃趩栴}的目標和約束之間的一種權衡，還可能有的結果則是修改目標或放寬約束。
3.軟件計劃
分析人員應該為推薦的系統(tǒng)草擬一份軟件計劃，其中描述的是為了成功地進行一個軟件項目，其所需要做的工作、需要的資源、需要的工作量和費用以及應遵循的進度安排。
軟件計劃由兩項任務組成:分析和估算。分析是對系統(tǒng)內(nèi)各軟件功能的界限的劃定。估算是指根據(jù)已有的定性數(shù)據(jù)和已往的經(jīng)驗對系統(tǒng)開發(fā)的資源、費用和進度進行定量的估計。
軟件開發(fā)項目的進度安排可以從兩種觀點來考慮:一是項目的交付日期已定，負責開發(fā)工作的軟件機構被限制在一個規(guī)定的時間范圍內(nèi)分配其工作量。二是項目最后的交付日期由軟件機構自已確定，可以從最佳的利用各種資源的角度出發(fā)來分配工作量，項目最后的交付日期經(jīng)過對軟件各部分仔細分析后才確定。在多數(shù)項目中，遇到的往往是第一種情況。
軟件計劃的閱讀者可以包括軟件主管部門、用戶和技術人員。所確定的成本與進度可供主管部門復審。它同時也給出了整個軟件生命周期的基本成本預算的進度安排。
（二）軟件需求分析
軟件需求分析工作是軟件生存期中重要的一步，也是決定性的一步。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規(guī)格說明，從而奠定軟件開發(fā)的基礎。軟件需求分析工作也是一個不斷認識和逐步細化的過程。該過程將軟件設計階段所確定的軟件范圍（工作域）逐步細化到可詳細定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。
制定軟件的需求規(guī)格說明不只是軟件開發(fā)人員的事，用戶也起著至關重要的作用。用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而軟件分析人員則要認真了解用戶的要求，細致地進行調(diào)查分析，把用戶“做什么”的要求最終轉(zhuǎn)換成一個完全的、精細的軟件邏輯模型并寫出軟件的需求規(guī)格說明，準確地表達用戶的要求。
1.軟件需求分析任務
需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統(tǒng)元素的接口細節(jié)。定義軟件的其他有效性需求。
分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉(zhuǎn)化為數(shù)據(jù)設計、結構設計和過程設計的數(shù)據(jù)與功能表示。在軟件完成后，制定的軟件需求規(guī)格說明還要為評價軟件質(zhì)量提供依據(jù)。
需求分析階段研究的對象是軟件項目的用戶要求。需要注意的是，必須理解用戶的各項要求，但又不能全盤接受所有的要求。因為并非所有用戶要求都是合理的。對其中模糊的要求還需要澄清，然后才能決定是否可以采納。對于那些無法實現(xiàn)的要求應向用戶做充分的解釋，以求得諒解。
準確地表達所接受的用戶要求，是需求分析的另一個重要方面。只有經(jīng)過確切描述的軟件需求才能成為軟件設計基礎。
通常軟件開發(fā)項目是要實現(xiàn)目標系統(tǒng)的物理模型，即確定待開發(fā)軟件系統(tǒng)的系統(tǒng)元素，并將功能和數(shù)據(jù)結構分配到這些系統(tǒng)元素中，它是軟件實現(xiàn)的基礎。但是目標系統(tǒng)的具體物理模型是由它的邏輯模型經(jīng)實例化，即具體到某個業(yè)務領域而得到的。與物理模型不同，邏輯模型忽視實現(xiàn)機制與細節(jié)，只描述系統(tǒng)要完成的功能和要處理的數(shù)據(jù)。作為目標系統(tǒng)的參考，需求分析的任務就是借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的“做什么”的問題。
（1）獲得當前系統(tǒng)的物理模型。當前系統(tǒng)可能是需要改進的某個已在計算機運行的數(shù)據(jù)處理系統(tǒng)，也可能是一個人工的數(shù)據(jù)處理過程。在這一步首先分析、理解當前系統(tǒng)是如何運行的，了解當前系統(tǒng)的組織機構、輸入輸出、資源利用情況和日常數(shù)據(jù)處理過程，并用一個具體模型來反映自己對當前系統(tǒng)的理解。這一模型應客觀地反映現(xiàn)實世界的實際情況。
（2）抽象出當前系統(tǒng)的邏輯模型。在理解當前系統(tǒng)“怎樣做”的基礎上，抽取其“做什么”的本質(zhì)，從而從當前系統(tǒng)的物理模型抽象出當前系統(tǒng)的邏輯模型。
在物理模型中有許多物理因素，隨著分析工作的深入，有些非本質(zhì)的物理因素就成為不必要的負擔，因而需要對物理模型進行分析，區(qū)分出本質(zhì)的和非本質(zhì)的因素，去掉那些非本質(zhì)的因素即可獲得反映系統(tǒng)本質(zhì)的邏輯模型。
（3）建立目標系統(tǒng)的邏輯模型。分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，明確目標系統(tǒng)統(tǒng)到底要“做什么”，從當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型。
（4）為了對目標系統(tǒng)做完整的描述，還需要對得到的邏輯模型做一些補充。
①說明目標系統(tǒng)的用戶界面。根據(jù)目標系統(tǒng)所處的應用環(huán)境及它與外界環(huán)境的相互關系，研究所有可能與它發(fā)生聯(lián)系和作用的部分，從而決定人機界面。
②說明至今尚未詳細考慮的細節(jié)。這些細節(jié)包括系統(tǒng)的啟動和結束、出錯處理、系統(tǒng)的輸入輸出和系統(tǒng)性能方面的需求。
③其他。例如系統(tǒng)的其他必須滿足的性能和限制等等。
2.需求分析的過程
需求分析階段的工作，可以分成以下4個方面:對問題的識別、分析與綜合、制定規(guī)格說明和評審。
（1）問題識別
首先系統(tǒng)分析人員要研究計劃階段產(chǎn)生的可行性分析報告（如果有的話）和軟件項目實施計劃。主要是從系統(tǒng)的角度來理解軟件并評審用于產(chǎn)生計劃估算的軟件范圍是否恰當。確定對目標系統(tǒng)的綜合要求，即軟件的需求。并提出這些需求實現(xiàn)條件，以及需求應達到的標準。也就是要求所開發(fā)軟件做什么，做到什么程度。這些需求包括:
·功能需求:列舉出所開發(fā)軟件在職能上應做什么。這是最主要的需求。
·性能需求:給出所開發(fā)軟件的技術性能指標，包括存儲容量限制、運行時間限制、安全保密性等。
·環(huán)境需求:這是對軟件系統(tǒng)運行時所處環(huán)境的要求。例如在硬件方面，采用什么機型、有什么外部設備、數(shù)據(jù)通信接口等等。在軟件方面，采用什么支持系統(tǒng)運行的系統(tǒng)軟件（指操作系統(tǒng)、網(wǎng)絡軟件、數(shù)據(jù)庫管理系統(tǒng)等）。在使用方面，需要使用部門在制度上、操作人員的技術水平上應具備什么樣的條件等等。
·可靠性需求:各種軟件在運行時，失效的影響各不相同。在需求分析時，應對所開發(fā)軟件在投入運行后不發(fā)生故障的概率，按實際的運行環(huán)境提出要求，對于那些重要的軟件，或是運行失效會造成嚴重后果的軟件，應當提出較高的可靠性要求，以期在開發(fā)的過程中采取必要的措施，使軟件能夠高度可靠地穩(wěn)定運行，避免因運行事故而帶來的損失。
·安全保密要求:工作在不同環(huán)境的軟件對其安全，保密的要求顯然是不同的。應當把這方面的需求恰當?shù)刈龀鲆?guī)定，以便對所開發(fā)的軟件給予特殊的設計，使其在運行中其安全方面的性能得到必要的保證。
·用戶界面需求:軟件與用戶界面的友好性是用戶能夠方便、有效、愉快地使用該軟件的關鍵之一。從市場角度來看，具有友好用戶界面的軟件有很強的競爭力。因此，必須在需求分析時，為用戶界面細致地規(guī)定達到的要求。
·資源使用需求:這是指所開發(fā)軟件運行時所需的數(shù)據(jù)、軟件、內(nèi)存空間等各項資源外，軟件開發(fā)時所需的人力、支撐軟件、開發(fā)設備等則屬于軟件開發(fā)的資源，需要在需求分析時加以確定。
·軟件成本消耗與開發(fā)進度需求:在軟件項目立項后，要根據(jù)合同規(guī)定，對軟件開發(fā)的進度和步驟的費用提出要求，作為開發(fā)管理的依據(jù)。
·預先估計以后系統(tǒng)可能達到的目標。這樣，在開發(fā)過程中，可對系統(tǒng)將來可能擴充與修改做準備。一旦需要時，就比較容易進行補充和修改。
·功能性需求是人們普遍關注的，但常常忽視對非功能性需求的分析。其實非功能性需求并不是無關緊要的，它們涉及到的方面多而廣，因而容易被忽略。如果在進行需求分析之前沒有做過可行性分析，那么補充完成這部分工作往往是必要的。從問題定義和調(diào)查研究入手，與用戶密切聯(lián)系，詳細了解問題提出的背景，弄清要解決什么問題。然后從軟件系統(tǒng)特性和用戶目標出發(fā)，做市場調(diào)查和現(xiàn)場考察。仔細收集信息之后進行數(shù)據(jù)分析和功能分析，建立系統(tǒng)的高層邏輯模型，再進一步做成本/效益分析。最后提交一份可行性分析報告，從技術、經(jīng)濟、社會效應等方面論證可行性，以確認軟件開發(fā)的目標是否可行。
問題識別的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。分析員必須與用戶、軟件開發(fā)機構的管理部門、軟件開發(fā)組的人員建立聯(lián)系。項目負責人在此過程中起協(xié)調(diào)人的作用。分析員通過這種通信途徑與各方商討，以便能滿足用戶的要求。
（2）分析與綜合
需求分析的第二步工作是問題分析和方案的綜合。分析員需從數(shù)據(jù)流和數(shù)據(jù)結構出發(fā)，逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據(jù)功能需求、性能需求、運行特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據(jù)功能需求、性能需求、運行環(huán)境需求等，剔除其不合理的部分，增加其需要的部分。最終綜合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。
在這個步驟中，分析和綜合工作反復地進行。在對現(xiàn)行問題和期望的信息（輸入和輸出）進行分析的基礎上，分析員開始綜合出一個或幾個解決方案，然后檢查這些方案是否符合軟件計劃中規(guī)定的范圍等等，再進行修改�？傊�，對問題進行分析和綜合的過程將一直持續(xù)到分析員與用戶雙方都感到有把握正確地制定該軟件的規(guī)格說明為止。
常用的分析方法有面向數(shù)據(jù)流的結構化分析方法（簡稱SA）、面向數(shù)據(jù)結構的Jackson方法（簡稱JSD）、面向?qū)ο蟮姆治龇椒ǎê喎QOOA）等，以及用于建立動態(tài)、模型的狀態(tài)遷移圖或Petri網(wǎng)等。這些方法都采用圖文結合的方式，可以直觀地描述軟件的邏輯模型。
（3）編制需求分析的文檔
已經(jīng)確定的需求應當?shù)玫角逦鷾蚀_的描述。通常把描述需求的文檔叫做軟件需求規(guī)格說明書。同時，為了確切表達用戶對軟件的輸入輸出要求，還需要制定數(shù)據(jù)要求說明書及編寫初步的用戶手冊，著重反映被開發(fā)軟件的用戶界面和用戶使用的具體要求。
此外，依據(jù)在需求分析階段對系統(tǒng)的進一步分析，從目標系統(tǒng)的精細模型出發(fā)，可以更確切地估計所開發(fā)項目的成本與進度，從而修改、完善與確定軟件開發(fā)的實施計劃。
（4）需求分析評審
作為需求分析階段工作的復查手段，在需求分析的最后一步，應該對功能的正確性、完整性和清晰性，以及其他需求給予評價。評審的主要內(nèi)容是:
·系統(tǒng)定義的目標是否與用戶的要求一致;
·系統(tǒng)需求分析階段提供的文檔資料是否齊全;
·文檔中的所有描述是否完整、清晰、準確所反映用戶要求;
·與所在其他系統(tǒng)成分的重要接口是否都已經(jīng)描述;
·所開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠、確定;
·所有圖表是否清楚，在不補充說明時能否理解;
·主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明;
·設計的約束條件或限制條件是否符合實際;
·開發(fā)的技術風險是什么;
·是否考慮過軟件需求的其他方案;
·是否考慮過將來可能會提出的軟件需求;
·是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認;
·有沒有遺漏、重復或不一致的地方;
·用戶是否審查了初步的用戶手冊;
·軟件開發(fā)計劃中的估算是否受到了影響。
為保證軟件需求定義的質(zhì)量，評審應以專門指定的人員負責，并按規(guī)程嚴格進行。評審結束應有評審負責人的結論意見及簽字。除分析員之外，用戶，開發(fā)部門的管理者，軟件設計、實現(xiàn)、測試的人員都應當參加評審工作。通常，評審的結果都包括了一些修改意見，待修改完成后再經(jīng)評審通過，才可進入設計階段。
文章責編：ak47
看了本文的網(wǎng)友還看了
