软件工程课件

軟體工程

需求分析

軟體工程2.1需求分析的任務

需求分析的基本任務是準確地回答“系統必須做什麼?”這個問題。目標系統提出完整、準確、清晰、具體的要求。需求分析階段的具體任務一、確定對系統的綜合要求。

對系統的綜合要求有下述四個方面：

1．系統功能要求

應該劃分出系統必須完成的所有功能。

軟體工程2．系統性能要求

例如，聯機系統的回應時間(即對於從終端輸入的一個“事務”，系統在多長時間之內可以做出回應)，系統需要的存儲容量以及後援存儲，重新啟動和安全性等方面的考慮都屬於性能要求。

3．運行要求這類要求集中表現為對系統運行時所處環境的要求。例如，支持系統運行的系統軟體是什麼，採用哪種資料庫管理系統，需要什麼樣的外存儲器和數據通信介面等。

軟體工程4．將來可能提出的要求應該明確地列出那些雖然不屬於當前系統開發範疇，但是據分析將來很可能會提出來的要求。這樣做的目的是在設計過程中對系統將來可能的擴充和修改預做準備，以便一旦需要時能比較容易地進行這種擴充和修改。二、分析系統的數據要求任何一個軟體系統本質上都是資訊處理系統，系統必須處理的資訊和系統應該產生的資訊在很大程度上決定了系統的面貌，對軟體設計有深遠影響，因此，必須分析系統的數據要求，這是軟體需求分析的一個重要任務。分析系統的數據要求通常採用建立概念模型的方法。軟體工程複雜的數據由許多基本的數據元素組成，數據結構表示數據元素之間的邏輯關係。利用數據字典可以全面準確地定義數據，但是數據字典的缺點是不夠形象直觀。為了提高可理解性，常常利用圖形工具輔助描繪數據結構。常用的圖形工具有層次方框圖和Warnier圖。

三、導出系統的邏輯模型綜合上述兩項分析的結果可以導出系統的詳細的邏輯模型，通常用數據流圖、數據字典和主要的處理演算法描述這個邏輯模型。

四、修正系統開發計畫根據在分析過程中獲得的對系統的更深入更具體的瞭解，軟體工程可以比較準確地估計系統的成本和進度，修正以前制定的開發計畫。五、開發原型系統在電腦硬體和許多甚他工程產品的設計過程中經常使用樣機。建造樣機通常有兩個主要目的：檢驗關鍵設計方案的正確性及系統是否真正滿足用戶的需要。對於軟體系統的開發，使用“樣機”(更正確的名稱應該是原型系統)的主要目的是，使用戶通過實踐獲得關於未來的系統將怎樣為他們工作的更直接更具體的概念，從而可以更準確地提出和確定他們的要求。軟體工程2.2需求分析的原則

需求分析的前提是準確、完整地獲取用戶需求。向問題領域的專家學習，進行用戶需求查是需求分析的第一步。用戶需求通常可以分為功能需求和性能需求兩類。功能需求定義了系統應該做什麼，系統要求輸入什麼資訊，輸出什麼資訊，以及如何將輸入變換為輸出。性能需求則定義了軟體運行的狀態特徵，如系統運行效率，可靠性，安全性，可維護性等等。綜合起來，應該獲取用戶需求的內容包括：(1)物理環境。系統運行的設備地點、位置是集中式的還是分佈式的，對環境的要求如何(如溫度、濕度，電磁場干擾等)。

軟體工程(2)系統介面。要求與其他系統進行數據交換的內容與格式，終端用戶的類型與熟練程度，用戶對介面的特定要求，用戶操作的易接受性等。(3)系統功能。系統應該完成的功能以及何時完成，對於系統運行速度、回應時間或者數據吞吐量的要求，系統運行的許可權規定，系統可靠性要求，是否要求可移植，未來擴充或者升級的要求。(4)數據要求。輸入偷出數據的種類與格式，計算必須達到的精度，數據接收與發送的頻率，數據存儲的容量和可靠性，數據或者檔訪問的控制權限，數據備份的要求。軟體工程(5)系統文檔規格。系統要求交付什麼文檔，各類文檔的編制規範和預期使用對象。(6)系統維護要求。系統出錯後可以允許的最大恢復時間，對錯誤修改的回歸測試要求，系統運行日誌規格，是否允許對系統修改，系統變化如何反映到設計中。在獲取需求過程中遇到的典型問題及其解決方法是：(1)如何理解問題。大多數情況下，軟體開發人員不是問題領域的行家。但是要準確、完整的獲取需求必須對問題具有深入的理解與把握。許多問題即使是用戶業務人員也可能沒有自覺的認識。(2)分析員與用戶的通信問題。分析員對問題的理解軟體工程必須從資訊處理要求出發，而用戶更多的考慮是本身的業務領域。與用戶建立相互信任、有效的溝通是分析員的首要任務。(3)用戶需求的可變性。用戶需求通常是不斷變化的，而軟體開發人員則希望將需求凍結在某一時刻。影響用戶需求變化的因素可以是用戶領域的業務擴充或者轉移，市場競爭的要求，用戶主管人員的變更等。現實情況是分析員只能接受需求不斷變化的事實，應該千方百計地使其工作適應需求的變化。現實世界是複雜多變的。為了將現實世界中問題的求解映射為資訊處理模型，對問題進行分解與抽象是普遍有效的基本法則。

軟體工程2.3可行性研究

2.3.1可行性研究的任務可行性研究的目的就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。確定問題是否值得去解。首先需要進一步分析和澄清問題定義。在問題定義階段初步確定的規模和目標，如果

是正確的就進一步加以肯定，如果有錯誤就應該及時改正，如果對目標系統有任何約束和

限制，也必須把它們清楚地列舉出來。

在澄清了問題定義之後，分析員應該導出系統的邏輯模型。然後從系統邏輯模型出

發，探索若干種可供選擇的主要解法(即系統實現方案)。對每種解法都應該仔細研究它的

可行性，一般說來，至少應該從下述三方面研究每種解法的可行性：

軟體工程(1)技術可行性使用現有的技術能實現這個系統嗎?(2)經濟可行性這個系統的經濟效益能超過它的開發成本嗎?(3)操作可行性系統的操作方式在這個用戶組織內行得通嗎?

分析員應該為每個可行的解法制定一個粗略的實現進度。軟體工程2.3.2可行性研究的步驟

一、復查系統規模和目標

分析員訪問關鍵人員，仔細閱讀和分析有關的材料，以便對問題定義階段書寫的關於規模和目標的報告書進一步復查確認，改正含糊或不確切的敘述，清晰地描述對目標系統的一切限制和約束。二、研究目前正在使用的系統

現有的系統是資訊的重要來源。顯然，如果目前有一個系統正被人使用，那麼這個系統必定能完成某些有用的工作，因此，新的目標系統必須也能完成它的基本功能；另一方面，如果現有的系統是完美無缺的，用戶自然不會提出開發新系統的要求，因此，現有的系統必然有某些缺點，新系統必須能解決舊系統中存在的問題。

軟體工程

應該仔細閱讀分析現有系統的文檔資料和使用手冊，也要實地考察現有的系統。三、導出新系統的高層邏輯模型

優秀的設計過程通常總是從現有的物理系統出發，導出現有系統的邏輯模型，再參考現有系統的邏輯模型，設想目標系統的邏輯模型，最後根據目標系統的邏輯模型建造新的物理系統。四、重新定義問題

新系統的邏輯模型實質上表達了分析員對新系統必須做什麼的看法。用戶是否也有

同樣的看法呢?分析員應該和用戶一起再次復查問題定義、工程規模和目標，這次復查軟體工程應該把數據流圖和數據字典作為討論的基礎。五、導出和評價供選擇的解法分析員應該從他建議的系統邏輯模型出發，導出若干個較高層次的(較抽象的)物理解法供比較和選擇。導出供選擇的解法的最簡單的途徑，是從技術角度出發考慮解決問題的不同方案。在數據流圖上劃分不同的自動化邊界，從而導出不同物理方案的方法。當從技術角度提出了一些可能的物理系統之後，應該根據技術可行性的考慮初步排除一些不現實的系統。軟體工程其次可以考慮操作方面的可行性。接下來應該考慮經濟方面的可行性。分析員應該估計餘下的每個可能的系統的開發

成本和運行費用，並且估計相對於現有的系統而言這個系統可以節省的開支或可以增加的收入。最後為每個在技術、操作和經濟等方面都可行的系統制定實現進度表，這個進度表不

需要(也不可能)制定得很詳細，通常只需要估計生命週期每個階段的工作量。六、推薦行動方針根據可行性研究結果應該做出的一個關鍵性決定是，是否繼續進行這項開發工程。分

析員必須清楚地表明他對這個關鍵性決定的建議。

軟體工程七、草擬開發計畫分析員應該進一步為推薦的系統草擬一份開發計畫，除了工程進度表之外還應該估計對各種開發人員(系統分析員，程式員，資料員等等)和各種資源(電腦硬體，軟體工具等等)的需要情況，應該指明什麼時候使用以及使用多長時間。此外還應該估計系統生命週期每個階段的成本。最後應該給出下一個階段(需求分析)的詳細進度表和成本估計。八、書寫文檔提交審查應該把上述可行性研究各個步驟的結果寫成清晰的文檔，請用戶和使用部門的負責人仔細審查，以決定是否繼續這項工程以及是否接受分析員推薦的方案。

軟體工程2.3.3系統流程圖

系統流程圖是描繪物理系統的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪系統裏面的每個部件(程式、檔、資料庫、表格、人工過程等等)。一、符號

當以概括的方式抽象地描繪一個物理系統時，僅僅使用圖2．1中列出的基本符號就夠了，其中每個符號表示系統中的一個部件。當需要更具體地描繪一個物理系統的時候還需要使用圖2．2中列出的系統符號，利用這些符號可以把一個廣義的輸入／輸出操作具體化為讀／寫存儲在特殊設備上的檔(或資料庫)，把一般的處理具體化為特定的程式或手工操作等等。

軟體工程圖2．1基本符號符號名

稱說

明處理能改變數據值或數據位置的加工或部件，例如，程式、處理機、人工加工等都是處理

輸入／輸出表示輸入或輸出(或既輸入又輸出)，是一個廣義的不指明具體設備的符號。

連接指出轉到圖的另一部分或從圖的另一部分轉來，通常在同一頁上

換頁連接指出轉到另一頁圖上或由另一頁圖轉來。

數據流用來連接其他符號，指明數據流動方向。

軟體工程圖2.2系統符號符號名

稱

穿孔卡片表示用穿孔卡片輸入或輸出，也可表示一個穿孔卡片檔。

文檔通常表示列印輸出，也可表示用列印終端輸入數據。

磁帶磁帶輸入／輸出，或表示一個磁帶檔。

聯機存儲表示任何種類的聯機存儲，包括磁片、磁鼓、軟碟和海量記憶體件等。

磁片磁片輸入／輸出。也可表示存儲在磁片上的檔或資料庫。

磁鼓磁鼓輸入／輸出，也可表示存儲在磁鼓上的檔或資料庫。

顯示CRT終端或類似的顯示部件，可用於輸入或輸出，也可既輸入又輸出。

人工輸入人工輸入數據的脫機處理，例如，填寫表格。

人工操作人工完成的處理，例如，會計在工資支票上簽名。

輔助操作使用設備進行的脫機操作。

通信鏈路通過遠程通信線路或鏈路傳送數據。

軟體工程二、例子

介紹系統流程圖的最好方法可能是通過一個具體例子說明它的用法。下麵是一個簡單的例子。某裝配廠有一座存放零件的倉庫，倉庫中現有的各種零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。當倉庫中零件數量有變化時，應該及時修改庫存清單主文件，如果那種零件的庫存量少於它的庫存量臨界值，則應該報告給採購部門以便定貨，規定每天向採購部門送一次定貨報告。該裝配廠使用一臺小型電腦處理更新庫存清單主文件和產生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，通過放在倉庫中的CRT終端輸入到電腦中；系統中的庫存清單程式對事務進行處理，更新存儲在軟體工程磁片上的庫存清單主文件，並且把必要的定貨資訊寫在磁帶上。最後，每天由報告生成程式讀一次磁帶，並且列印出定貨報告。圖2．3的系統流程圖描繪了上述系統的概貌。事務庫存清單程式訂貨資訊報告生成程式訂貨報告庫存清單主文件圖2.3庫存清單系統的系統流程圖軟體工程三、分層面對複雜的系統時，一個比較好的方法是分層次地描繪這個系統。首先用一張高層次的系統流程圖描繪系統總體概貌，表明系統的關鍵功能。然後分別把每個關鍵功能擴展到適當的詳細程度，畫在單獨的一頁紙上。這種分層次的描繪方法便於閱讀者按照從抽象到具體的過程逐步深入地瞭解一個複雜的系統。

軟體工程2.4需求分析方法

2.4.1結構化分析方法結構化分析技術是70年代中期由E．Yourdon等人宣導的一種面向數據流的分析方法。按照T．Demarco的定義，“結構化分析就是使用數據流圖、數據詞典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔。”這裏的結構化說明書，就是需求規格說明書。結構化分析技術將軟體系統抽象為一系列的邏輯加工單元，各單元之間以數據流發生關聯。按照數據流分析的觀點，系統模型的功能是數據變換，邏輯加工單元接受輸入數據流，使之變換成輸出數據流。數據流模型常用數據流圖表示。

軟體工程

建立功能模型

數據流程圖，又稱數據流圖，它是以圖形的方式來表達數據處理系統中資訊的變換和傳遞過程。作為一種描述手段，它可以模擬手工的、自動的以及兩兼而有之混合的數據處理過程。數據流程圖有三個重要屬性：

．可以表示任何一個系統(人工的、自動的或混合的)中的資訊流程。

．每個圓圈可能需要進一步分解以求得對問題的全面理解。

．著重強調的是數據流程而不是控制流程。軟體工程以工資處理為例，我們畫出這一過程中數據加工過程各項活動的數據流程圖(見2.4)。圖2.4可知，數據流程圖中的基本符號有：1、數據流數據流是有名字有流向的數據，在數據流程圖中，數據流用標有名字的箭頭來表示，如圖2.1中的工資調整表、工資發放表等。2、加工加工又稱處理邏輯，表示數據所進行的加工或變換，圖2.4中以標有名字的圓圈代表加軟體工程工資匯總表工資發放表工資條工資計算工資冊取款總務人事工資匯總工資分配開戶銀行職工統籌醫療費房租費水電費托兒費工資調整表調入人員工資單調出人員調出單病事假扣款單工資費用分配表工資發放圖2.4工資處理數據流程圖軟體工程工。指向加工的數據流是該加工的輸入數據，離開加工的數據流是該加工的輸出數據，如圖2.4中的工資計算、取款等。3、檔檔是數據暫存的處所，可對檔進行必要的存取，在圖中以標有名字的雙直線段表示，如圖2.1中的工資冊、工資匯總表等。對檔的存取分別以指向或離開檔的箭頭表示。由於檔的內容能顧名思義，因而對其進行存取的箭頭即使沒有名字也不會造成混亂。4、數據源及數據終點表明數據處理過程的數據來源或數據去向的標誌稱為軟體工程數據源及數據終點，在數據流程圖中均以命名的方框來表示，如圖2.4中的人事（科）。一般情況下，為了表達數據處理的數據加工過程，只用一個數據流程圖是不夠的。對稍為複雜一些的實際問題，常以層次結構的數據流程圖來表示。任何系統都是有層次的結構，如果按照層次結構對系統進行逐步分解，就能很清楚地表達和理解整個系統。在每一個層次上，最核心的部分就是數據加工乃其相關的數據流。除了上述4種基本成分外，數據流程圖還有幾種附加成分，例如，星號“﹡”表示幾股數據流之問是“與”的關係，加號“+”表示“或”的關係，⊙號表示從幾股數據流中選取一股，軟體工程即表示“互斥”的關係。我們來研究一個財務管理資訊系統中的材料核算部分。圖2.2中的基本系統模型把整個材料核算工作抽象成一個加工，並標上所有的輸入數據流和輸出數據流，即為材料核算子系統的項層數據流程圖。有關材料統計報表材料分類明細帳材料採購付款憑證材料核算採購合同收料憑證發料憑證材料匯總表圖2.5頂層數據流程圖軟體工程把材料核算處理功能進行分解。一般材料核算包括採購核算、儲存核算、發出核算等，據此，我們畫出如圖2.5所示的第一層數據流程圖。分解後的子圖中生出了一些新的數據流和文件，它們是頂層數據流程圖中加工“材料核算”內部的數據流和文件，與其外部元素沒有聯繫。在“材料核算”被分解後，這些數據流和文件成了一些子加工的介面。分別把第一層數據流程圖中的幾個核算處理（加工）再進行分解，可畫出第二層數據流程圖。圖2.5為其中的加工“材料發出核算”進行功能分解得到第二層數據流程圖，其他如材料採購核算、材料儲存核算等，都可以用同樣的方法講行分解擴展，畫出相應的數據流程圖。

軟體工程圖2.5、圖2.6和圖2.7畫出了3種不同層次的資訊流程，表示出需求分析一層比一層更為具體細緻。軟體工程收購憑證採購核算儲存核算發出核算材料匯總核算材料採購付款憑證採購合同發料憑證材料明細帳材料匯總表材料明晰分類帳有關材料統計報表材料採購合同執行情況材料採購成本材料採購明細帳材料發出憑證生成用料應攤材料成本差異表其他用料存儲材料明細帳生產材料分配表圖2.6第一層數據流程圖軟體工程圖2.7第二層數據流圖生產用料分配表材料發出憑證材料發出憑證按用途歸類按產品分配車間管理用料企業管理用料輔助生產用料材料明細表生產用料應攤材料成本差異軟體工程

數據流程圖是一種圖解方法，它在軟體需求分析中是非常有用的。然而，如果它的作用與程式流程圖(框圖)混淆的話，也會引起混亂。數據流程圖描繪的是資訊流，沒有明顯的控制說明(例如條件或迴圈)，它不是一個用圓圈表示的程式流程圖。在推導面向軟體的數據流時有幾個非常有用而簡單的準則：1、

1、

一層數據流程圖應當是基本系統模型。2、應當仔細說明原始的輸入／輸出檔。3、所有箭頭和圓圈均應加上標注(使用有意義的名字)。

4、必須維持資訊的連續性。

軟體工程5、每一次只應當細化一個圓圈。

6、可以在數據流程圖中加上物質流。有助於幫助用戶理解該數據流程圖。在畫分層數據流程圖時，要特別注意下麵幾個問題：

1、加工的編號方法

加工的編號遵循兩條原則：第一，從加工的編號能知道該加工處在哪一層分解；第二，從加工編號知道該加工是從父圖中哪個加工分解得來的。2、分解程度

分解程度問題包括兩個方面，其一是每個加工每次軟體工程分解成幾個子加工比較恰當；其二是分解深度，即分解的層數問題。這兩個問題之間有一定的聯繫。經驗表明，一個加工的分解以不超過7個子加工比較合適。3、父圖和子圖之間的平衡多層數據流程圖中的父圖和子圖之間的數據流必須保持一致(或稱保持“平衡“)，亦即，父圖中出現的輸入數據流和輸出數據流都應在子圖中出現，以保證加工過程的連續性和一致性。有時，當在子圖中對父圖的數據流做了分解後，檢驗父圖和子圖的平衡還需借助於數據字典。因為“自頂向下”逐層對數據流程圖的分解，實際上不僅是對加工進行分解，同時也對數據流進行分解。軟體工程

建立數據模型

在需求分析階段則既要分析用戶的數據要求（即需要哪些數據、數據之間有什麼聯繫、數據本身有什麼性質、數據的結構等等），又要分析用戶的處理要求(即對數據進行哪些處理、每個處理的邏輯功能等等)。為了把用戶的數據要求清晰明確地表達出來，系統分析員通常建立一個概念性的數據模型(也稱為資訊模型)。概念性數據模型是一種面向問題的數據模型，是按照用戶的觀點來對數據和資訊建模。它描述了從用戶角度看到的數據，它反映了用戶的現實環境，且與在軟體系統中的實現方法無關。最常用的表示概念性數據模型的方法，是實體一聯繫方法(Entity—RelationshipApproach)。這種方法用ER圖。軟體工程描述現實世界中的實體，而不涉及這些實體在系統中的實現方法。用這種方法表示的概念性數據模型又稱為ER模型。通常，軟體系統中有許多數據是需要長期保存的，為減少數據冗餘，簡化修改數據的過程，應該對數據進行規範化。ER模型中包含“實體”、“聯繫”和“屬性”等三個基本成分，下麵分別介紹這三個基本成分：1．實體

實體是客觀世界中存在的且可相互區分的事物。實體可以是人也可以是物；可以是具體事物也可以是抽象概念。例如，職工、學生、課程、教師等都是實體。在ER圖中用矩形框代表實體。軟體工程2．聯繫客觀世界中的事物彼此間往往是有聯繫的。例如，教師與課程間存在“教”這種聯繫，而學生與課程間則存在“學”這種聯繫。聯繫可分為三類：(1)一對一聯繫(1︰1)例如，一個部門有一個經理，而每個經理只在一個部門任職，則部門與經理的聯繫是一對一的。

(2)一對多聯繫(1︰N)例如，某校教師與課程之間存在一對多的聯繫“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教。軟體工程(3)多對多聯繫(M︰N)例如，學生與課程間的聯繫(“學”)是多對多的，即一個學生可以學多門程，而每門課程可以有多個學生來學。在ER圖中，用連接相關實體的菱形框表示聯繫。3．屬性屬性是實體或聯繫所具有的性質。通常一個實體由若干個屬性來刻畫。例如，“學生”實體有學號、姓名、性別、系、年級等屬性；“教師”實體有教工號、姓名、性別、職稱、職務等屬性；“課程”實體有課程號、課名、學時、學分等屬性。軟體工程聯繫也可能有屬性。例如，學生“學”某門課程所取得的成績，既不是學生的屬性也不是課程的屬性。由於“成績”既依賴於某名特定的學生又依賴於某門特定的課程，所以它是學生與課程之間的聯繫“學”的屬性。N1NM教師教工號性別姓名職稱職務教師教師教學姓名性別系年級學號成績課程號課名學時學分圖2.8某校教學管理ER圖軟體工程

在ER圖中用橢圓形或圓角矩形表示實體(或聯繫)的屬性，並用無向邊把實體(或聯繫)與其屬性連接起來。人們通常就是用實體、聯繫和屬性這三個概念來理解現實問題的，因此，ER模型比較接近人的習慣思維方式。此外，ER模型使用簡單的圖形符號表達系統分析員對問題域的理解，不熟悉電腦技術的用戶也能理解它，因此，ER模型可以作為用戶與分析員之間有效的交流工具。

4．範式通常用“範式(NormalForms)”定義消除數據冗餘的程度。第一範式(1NF)數據冗餘程度最大，第五範式(5NF)數據冗餘程度最小。但是，範式級別越高，存儲同樣數據就軟體工程需要分解成更多張表，因此，“存儲自身”的過程也就越複雜。第二，隨著範式級別的提高，數據的存儲結構與基於問題域的結構間的匹配程度也隨之下降，因此，在需求變化時數據的穩定性較差。第三，範式級別提高則需要訪問的表增多，因此性能（速度）將下降。從實用角度看來，在大多數場合選用第三範式都比較恰當。

1．第一範式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內部結構。2．第二範式滿足第一範式條件，而且每個非主屬性完全依賴於某個軟體工程候選鍵(而不是部分依賴於某個候選鍵)3．第三範式。符合第二範式的條件，所有非主屬性即不部分依賴於某個候選鍵，也不傳遞依賴於某個候選鍵。

軟體工程

建立行為模型

狀態轉換圖通過描述狀態以及導致系統改變狀態的事件來表示系統的行為，它沒有表示出系統所執行的處理，只表示了處理結果可能的狀態轉換。STD用帶標記的圓圈或矩形表示狀態，用箭頭表示從一種狀態到另一種狀態的變換，箭頭上的文本標記表示引起變換的條件。轉換條件狀態圖2.9狀態轉換圖基本圖形元素軟體工程分析建模是實現真實世界模型向電腦模型轉換的核心環節，也是一種處理軟體複雜性的有效手段。在需求開發階段，分析建模的關鍵是針對用戶需求建立抽象的分析模型，從而有助於開發人員理解用戶需求，同時增強自然語言的需求規格說明。分析模型往往採用一些圖形化的表示方式，從數據、功能和行為等不同角度表達用戶需求。結構化分析是面向數據流進行需求分析的方法，經過20多年的發展，已經成為廣泛應用的技術之一。結構化分析方法以數據字典為核心，採用實體關係圖、數據流圖和狀態轉換圖等圖形來表達需求，直觀明瞭且易於理解和掌握。

軟體工程

數據詞典

數據字典是結構化分析方法的一個有力工具，它對數據流程圖中出現的所有數據元素給出邏輯定義。有了數據字典，使數據流程圖上的數據流、加工和文件能得到確切的解釋。

數據字典的條目可以分成四大類，即：

·數據流條目。

·檔條目。

·資料項目條目。

·加工條目。軟體工程數據字典中的數據構成如圖2.10所示的層次關係。這些數據元素的定義通常用定義式的形式給出。圖2.10數據字典中數據的層次關係數據流檔數據結構數據元素軟體工程通常，在數據字典的定義式中可能出現的符號及其含意是(設x和a、b都是數據元素)：

x=a+bx由a和b構成

x=[a︱b]x由a或b構成

x=(a)數據元素a在x中可出現，也可不出現

x={a}x由0個或多個重複的a構成軟體工程1、數據流條目數據流條目主要說明數據流條目是由哪些資料項目組成的，以及數據在單位時間內的流量，它的來源、去向等。條目格式如下：數據流名：組成：流量：來源：去向：軟體工程例如：數據流“銀行對帳單”條目：條目格式如下：數據流名：銀行對帳單組成：月份＋日期＋銀行支票＋金額流量：2張∕3天，每張約40筆數據來源：開戶銀行去向：資金管理組軟體工程2、檔條目檔條目主要說明文件由哪些資料項目組成，存儲方式和存取頻率等。條目格式如下：檔案名：

組成：

存儲方式：

存儲頻率：軟體工程例如：檔“現金日記賬”條目如下：檔案名：現金日記賬

組成：月份＋日期＋摘要＋收入＋支出＋結存

存儲方式：順序

存儲頻率：20筆∕天軟體工程3、資料項目條目

資料項目名：

類型：

長度：

取值範圍：資料項目條目主要說明資料項目類型、長度、取值範圍等。軟體工程例如：資料項目“憑證號”條目和數據項“經辦人”條目如下：

資料項目名：憑證號

類型：數值

長度：6位（含小數一位）

取值範圍：1000.0～4999.9軟體工程4、加工條目加工條目主要說明加工的輸入數據、輸出數據及其加工邏輯等。條目格式如下：

加工名：

輸入數據：

輸出數據：

加工邏輯：

軟體工程例如加工“工資分配”條目：加工名：工資分配輸入數據：工資結算單(匯總表)輸出數據：工資費用分配表加工邏輯：各車間根據工資結算單，按產品種類或批別，分別分配管理人員工資和生產工人工資，並按比例提取福利基金。

軟體工程

和數據流程圖的層次概念相類似，一個數據字典的定義式不宜包含過多的項，這可以採取逐級定義的定義式，使得一些複雜的數據元素自頂向下多層定義，直到最後給出無需定義的基本數據元素。例如：日期=年+月+日數據字典就是這樣構造起來的一組定義式。必要時，定義式之間還可能有一些特定的注釋行出現，以利於理解。常用的詞典相似，數據字典所收集的數據定義，都按詞典的編輯方法順序排列，以方便使用。當然，不允許出現一個數據元素有多個定義的現象。

軟體工程2.4.2面向對象分析方法與UML

面向對象分析方法面向對象方法是一種把面向對象的思想應用於軟體開發過程中，指導開發活動的系統方法，簡稱OO方法，它是建立在對象概念(對象、類和繼承)基礎上的方法。面向對象方法成為90年代的主流開發方法，其原因主要在於：

1．從認知學的角度來看，面向對象方法符合人們對客觀世界的認識規律

2．面向對象方法開發的軟體系統易於維護，其體系結構易於理解、擴充和修改

3．面向對象方法中的繼承機制有力支持軟體的複用

軟體工程一、面向對象的基本概念PeterCoad和EdwardYourdon提出用下列等式來認識面向對象方法：面向對象=對象(Obiect)+分類(Classification)+繼承(Inheritance)+通過消息的通信(CommunicationWithMessages)可以說，採用這4個概念開發的軟體系統是面向對象的。1．對象

對象是指一組屬性以及這組屬性上的專用操作的封裝體。屬性通常是一些數據，有時它也可以是另一個對象。

軟體工程

對象中的屬性只能通過該對象所提供的操作來存取或修改。操作也稱為方法或服務，它規定了對象的行為，表示對象所能提供的服務。封裝是一種資訊隱蔽技術，用戶只能看見對象封裝介面上的資訊，對象的內部實現對用戶是隱蔽的，封裝的目的是使對象的使用者和生產者分離，使對象的定義和實現分開。一個對象通常可由對象名、屬性和操作三部分組成。

2．類

類是一組具有相同屬性和相同操作的對象的集合。一個類中的每個對象都是這個類的一個實例。

不必為每個對象逐個定義，只需對類作出定義，而對類的屬性的不同賦值即可得到該類的對象實例，類和軟體工程

對象之間的關係類似於程式設計語言中的類型和變數之間的關係。通常把一個類和這個類的所有對象稱為類及對象，或稱為對象類。一個類可以定義為另一個更一般的類的特殊情況，如“轎車”類是“汽車”類的特殊情況，我們稱一般類是特殊類的父類，特殊類是一般類的子類。這樣可以形成類的一種一般一特殊的層次關係。在這種一般一特殊的關係中，子類可以繼承其父類(或祖先類)的所有屬性和操作，同時子類中還可以定義自己特有的屬性和操作。所以子類的屬性和操作是子類中的定義部分和其祖先類中的定義部分的總和。繼承是類間的基本關係，它是基於層次關係的不同類共用數據和操作的一種機制。父類中定義了其所有子類的公共屬性和操作，在子類中除了定義自己特有的屬性和軟體工程操作外，還可以對父類(或祖先類)中的操作重新定義其實現方法。如果一個子類只有惟一一個父類，這個繼承稱為單一繼承。如果一個子類有一個以上的父類，這種繼承稱為多重繼承。

3．消息傳遞消息傳遞是對象間通信的手段，一個對象通過向另一個對象發送消息來請求其服務。一個消息通常包括接收對象名、調用的操作名和適當的參數(如果有必要的話)。消息只告訴接收對象需要完成什麼操作，但並不指示接收者怎樣完成操作。消息完全由接收者解釋，接收者獨立決定採用什麼方法完成所需的操作。軟體工程4．多態性

多態性是指同一個操作作用於不同的對象上可以有不同的解釋，並產生不同的執行結果。例如“畫”操作，作用在“矩形”對象上，則在螢幕上畫一個矩形，作用在“圓”對象上，則在螢幕上畫一個圓。也就是說，相同操作的消息發送給不同的對象時，每個對象將根據自己所屬類中定義的這個操作去執行，從而產生不同的結果。

與多態性密切相關的一個概念就是動態綁定(亦稱動態定連)。傳統的程式設計語言的過程調用與目標代碼的連接(即調用哪個過程)放在程式運行前進行(稱為靜態綁定)，而動態綁定則是把這種連接推遲到運行時才進行。

軟體工程二、面向對象分析

面向對象分析(Object—Oriented．Analysis，OOA)的目標是完成對所解問題的分析，確定待建的系統要做什麼，並建立系統的模型。為達到這一目標，必須完成以下任務：

(1)在客戶和軟體工程師之間溝通基本的用戶需求。

(2)標識類(包括定義其屬性和操作)。

(3)刻畫類的層次結構。

(4)表示類(對象)之間的關係。

(5)為對象行為建模。

軟體工程(6)遞進地重複任務(1)至任務(5)，直至完成建模。

其中任務(2)至任務(4)刻畫了待建系統的靜態結構，任務(5)刻畫了系統的動態行為。

面向對象分析的一般步驟如下：

(1)獲取客戶對系統的需求：包括標識場景(Scenario)和用例(IJseCase)，以及建造需求模型。

(2)用基本的需求為指南來選擇類和對象(包括屬性和操作)。

(3)定義類的結構和層次。

(4)建造對象．關係模型。

軟體工程(5)建造對象一行為模型。(6)利用用例／場景來復審分析模型。三、面向對象設計

面向對象設計(Object-Oriented．Design，OOD)是將OOA所創建的分析模型轉化為設計模型。與傳統的開發方法不同，OOD和OOA採用相同的符號表示，OOD和OOA沒有明顯的分界線，它們往往反復迭代地進行。在OOA時，主要考慮系統做什麼，而不關心系統如何實現。在OOD時，主要解決系統如何做，因此需要在OOA的模型中為系統的實現補充一些新的類，或在原有類中補充一些屬性和操作。OOD時應能從類中導出對象，以及這些對象如何互相關聯，還要描述對象間的關係、行為以及對象間的通信如何實現。

軟體工程OOD同樣應遵循抽象、資訊隱蔽、功能獨立、模組化等設計準則。

面向對象設計的一般步驟如下：

(1)系統設計。·將子系統分配到處理器。

·選擇實現數據管理、介面支持和任務管理的設計策略。

·為系統設計合適的控制機制。

·復審並考慮權衡。

軟體工程(2)對象設計。

·在過程級別設計每個操作。

·定義內部類。

·為類屬性設計內部數據結構。

(3)消息設計。

使用對象間的協作和對象．關係模型，設計消息模型。

(4)復審。

復審設計模型，並在需要時迭代。

目前有許多種面向對象方法，例如Coad&Yourdon方法、OMT方法、Booch方法等。

軟體工程統一的建模語言

一、UML概述

1994年Booch和Rumbaugh在R~ionalsoftwareCorporation開始了UML的工作，其目標是創建一個“統一的方法”，他們把Booch一93和OMIT一2統一起來，於1995年發佈了UM0.8(UnifiedMethod)。

OOSE的創始人jacobson加盟到這項工作中，他們以Booch方法、OMT方法、OOSE方法為基礎，吸收了其他流派的長處，於1996年6月、10月、1997年1月、11月分別推出了UML0.9，UML0.91，UML1.0，UMLl.1。

1997年11月，國際對象管理組織OMG(ObjectManagementGroup)批准把UML1.1作為基於面向對象技術的標準建模語言。

軟體工程一個系統往往可以從不同的角度進行觀察，從一個角度觀察到的系統，構成系統的一個視圖(View)，每個視圖是整個系統描述的一個投影，說明了系統的一個特殊側面。若干個不同的視圖可以完整地描述所建造的系統。視圖並不是一種圖表(Graph)，它是由若干幅圖(Diagram)組成的一種抽象。每種視圖用若干幅圖來描述，一幅圖包含了系統某一特殊方面的資訊，它闡明了系統的一個特定部分或方面。由於不同視圖之間存在一些交叉，因此一幅圖可以作為多個視圖的一部分。一幅圖由若干個模型元素組成，模型元素表示圖中的概念。UML語言建立在面向對象的基礎上，它採用面向對象的概念和範型。UML語言的體系結構建立在四層元模型結構之上，這4層元模型分別為：元一元模型、元模型、軟體工程模型、用戶對象。1．元一元模型層元一元模型(Meta—metamodel)是建立元模型體系結構的基礎結構(Infrastructure)。元一元模型定義描述元模型的語言，是任何模型的基礎，用於對概念的形式化。2．元模型層元模型層(Metamodel)定義描述模型的語言。在UML語言的元模型中，定義了面向對象的範型的概念，如“對象類”、“屬性”、“操作”、“組件”等，它們是元模型層的元對象。元模型是元一元模型的一個實例。例如，“對象類”、“軟體工程屬性”、“操作”分別是“元對象類”、“元屬性”、“元操作”的實例。“對象類”是對一組具有共同的結構特徵、行為特徵、聯繫和語義的對象的描述。“對象”是“對象類”的一個實例。“關聯”是對一組具有共同的結構特徵、行為特徵、聯繫和語義的鏈接的描述，“鏈接”用於為兩個或多個實體(對象類)之間具有共同特徵的聯繫建立模型。“鏈接”是“關聯”的一個實例，“鏈接”用於為兩個或多個對象之間的聯繫實例建立模型。3．模型層模型(Model)是元模型的一個實例，在模型層定義用於描述資訊領域的語言。模型是對現實世界的抽象。無論是問題領域還是解決軟體工程方案，都可以抽象成模型。模型是系統構建和更新的基礎，用於對問題和解決方案的理解與交流，便於管理和控制系統的複雜性。4．用戶對象層用戶對象(Userobjects)是模型的實例，用戶對象層定義一個特定的資訊領域。用戶對象層用於表達一個模型的特定情況。為了模型的可視化，UML為每一個模型元素規定了獨特的圖形表示符號，稱為圖示(Icon)。這些圖示簡潔明瞭能夠容納足夠的語義，並且容易繪製方便區別。在UML的核心包中定義的分類符，如對象類、介面、軟體工程數據類型、節點、組件、信號、UseCase、子系統等，它們的圖示如圖2．11所示。其中，對象類的圖示是一個矩形框，並且可以劃分成3個分割框，分別含有類的名字、屬性和操作。介面的圖示是一個圓，旁邊標有介面的名字。數據類型的圖示是一個矩形框，框內含有構造型<type>>、數據類型的名稱、以及關於取值範圍的說明(可選)。信號的圖示是一個矩形框，框內含有構造型<<signal>>和信號的名字。UseCase的圖示是一個橢圓，內含UseCase的名字。組件的圖示是一個大矩形框的左邊帶兩個小矩形，大框內含有組件的名字。節點的圖示是一個三維立方體，其內含有節點的名字。包的圖示是一個大矩形框的左上角帶一個小矩形。子系統用包的圖示表達，即在包的圖示中含有構造型<<subsystem>>和軟體工程子系統的名字。實際上，以上這些分類符的圖示中可以包含比名字更多的資訊。學生姓名入學註冊查詢成績對象類分析風險UseCase<<type>>Int{from–2**31to=2**31-1}數據類型<<signal>>offHook信號<<subsystem>>教學管理子系統子系統介面IUnknown

image.java組件節點資料庫伺服器圖2．11分類符圖示示例軟體工程UML定義的聯繫，如依賴、關聯、泛化、實現(Realization)等，它們的圖示如圖2．12所示。其中，依賴的圖示是一條虛箭線，從源模型元素指向目標模型元素，表示源模型元素依賴於目標模型元素。關聯的圖示是一條實線，連接兩個模型元素，在關聯端可標有多重性標記和關聯角色。泛化的圖示是一條帶空心三角箭頭的實箭線，從表示特殊性事物的模型元素指向表示一般性事物的模型元素。實現的圖示是一條帶空心三角箭頭的虛箭線，從源模型元素指向目標模型元素，表示源模型元素實現目標模型元素。UML定義的聯繫還有聚合與組合。聚合與組合是兩種特殊的關聯，表示事物之問的部分與整體的關係。聚合與組合的圖示是在關聯線的一端分別加上一個空心或實心軟體工程（a）依賴（b）泛化（c）關聯（d）實現（e）聚合（f）組合圖2．12聯繫的圖示示例的小菱形，小菱形端連接表示整體事物的模型元素，另一端連接表示部分事物的模型元素。

軟體工程UML定義的行為事物基本上分為兩大類：交互和狀態機。交互是這樣一種行為：在一個特定的上下文環境裏，一組對象之間交換消息，完成某個指定的任務。交互所涉及的模型元素有對象、消息、動作序列、鏈接等。消息的圖示是一條帶實心三角箭頭的實箭線，從消息的發送對象指向消息的接受對象。消息的圖示如圖（a）所示。添加訂貨(a)消息

休閒(b)狀態制定計畫(c)活動圖2．13消息、狀態和活動的圖示示例狀態機是這樣一種行為：一個對象的狀態序列，或一個在整個對象的生存期中回應事件的交互。一個對象類軟體工程和多個對象類的協同可以用狀態機描述。狀態機所涉及的模型元素有狀態、轉移、事件、活動等。狀態的圖示是一個帶4個小圓角的矩形，含有狀態的名字。活動(動作狀態)的圖示是一個由上下兩條平行線段、兩側圓弧構成的圖形，含有活動的名字。狀態與活動的圖示分別如圖

(b)和圖(c)所示。

UML定義的注解性的模型元素——注解(Comment)，是附加在其他模型元素上的一個文字串，用來對該模型元素做解釋。注解沒有強制性的語義，只是對模型元素作說明。注解常用注釋(Note)圖示表示。注釋圖示是一個右上角折角的矩形，內含注釋文字或約束運算式。注釋圖示也可以標有特定的構造型，如<<requirement>>、軟體工程<<constraint>>等，說明注釋的作用或類型。表達一個模型元素的注釋是把它的一個注釋圖示用一條虛線連接到該模型元素，如圖2．14所示。

安全當前值（）歷史值（）<<requirement>>遵照系統登錄事務的規定，滿足資訊系統安全性要求圖2．14注釋示例用於表示模型元素之問相互連接的關係也是模型元素，如關聯(Association)、泛化(Generalization)、依賴(Dependency)、聚集(Aggregation)等。這些關係的含義如下：

(1)關聯：連接(Connect)模型元素及鏈接(Link)實例。

軟體工程(2)泛化：表示一般與特殊關係，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化(Specialization)。

(3)依賴：表示一個元素以某種方式依賴於另一個元素。

(4)聚集：表示整體與部分的關係，即“部分”元素是“整體”元素的一部分。

UML中有9種圖(Diagram)和五種視圖。九種圖是：用例圖(Use—caseram)、類圖(Class)、對象圖(Object)、狀態圖(State)、時序圖(Sequence)、協作圖(Collaboration)、活動圖(Activity)、構件圖(Component)和部署圖(Deployment)。軟體工程UML可以從下列五種視圖來觀察系統，即用例視圖、邏輯視圖、構件視圖、併發視圖和部署視圖。二、使用UML的過程UML給出了面向對象建模的符號表示和規則，但並沒有描述如何工作，即沒有描述使用語言的過程或方法。實際上，UMI是為不同規模和目標的過程而設計的，儘管如此，要成功地使用UML仍需要一些過程。UML的設計者在設計UML時頭腦中是有一些過程的，使用UML。過程的基本特徵是：用例驅動(Use-case-driven)、以體系結構為中心(Architecture-centric)、反復(Iterative)、漸增式(Incremental)。

軟體工程面向對象(OO)方法的主要步驟是需求分析、設計、實現和測試。UML的設計者將他們原先各自的面向對象開發過程進行合併，命名為RationalObjectoryProcess，其開發過程如圖所示。初始階段細化階段構造階段……細化階段圖2．15RationalObjectory開發過程1、初始階段

初始階段主要確定專案的範圍和目標，並進行可行性分析。

軟體工程2、細化階段

細化階段對開發專案的問題領域和功能做詳細分析，畫出用例圖，建立系統的基礎結構。

3、構造階段

通常具有高優先順序、高體系結構風險和高進度風險的用例應儘早實現，不要風險留到最後。4、移交階段

移交階段一般不再開發新的功能，該階段的工作主要有B測試、產品包裝、培訓等。

軟體工程2.5軟體需求分析建模與規格說明

2.5.1需求分析建模

目標軟體系統的模型用來刻劃系統所涉及的資訊、處理功能及實際運行時的外部行為，但是，分析階段所建造的模型不應涉及軟體實現細節，因為這樣會分散分析人員的注意力，限制軟體設計人員為提高軟體的品質和效率而選擇實現方法的自由度。通常，分析人員選定一些圖形記號分別表示資訊流、處理功能及系統行為．井利用受限的自然語言給出用戶需求的描述。此外，為了處理大型問題，模型的表示機制還應具備良好的結構化能力。建立軟體模型是分析活動的焦點。因為模型以一種簡潔、準確、結構清晰的方式系統地描述了軟體需求，從而使軟體工程於分析人員剔除用戶描述中的模糊性和不一致性，並使軟體需求臻於完全。分析過程實質上是軟體模型的建造和不斷完善的過程。在分析的初期，開發方和用戶方的聯合小組通過訪談、會議及實際觀察為構築模型收集素材．同時也利用不太完整的初步模型作為小組內都相互溝通的需求表示機制、此後，分析人員不斷地對模型進行精確化、一致化、完全化方面的工作。最終確立的軟體模型既是生產需求規格說明的基礎，又是軟體設計和實現的基礎。軟體工程2.5.2規格說明及形式化說明技術

軟體需求規格說明書(SoltwareRequirementSpecificatiOns，SIRS)是需求分析階段的主要文檔，它以一致的，無二義性的方式完整、準確地表達目標系統應該實現的用戶需求。SRS既是軟體開發設計的依據，也是將來用戶測試驗收的依據。提交並且通過復審的SRS是需求分析結束的里程碑。SRS圍繞以下四個方面組織：(1)系統規格說明：目標系統的總體概貌；系統功能、性能要求；系統運行要求；將來可能的修改擴充要求。如果採用SA方法進行需求分析，則數據流圖是描述系統邏輯模型主要工具。(2)數據要求：建立數據詞典描繪系統數據要求，給出系統邏輯模型的準確、完整定義。軟體工程(3)用戶描述：從用戶使用角度對系統的描述，相當於初始的用戶手冊。內容包括系統功能、性能概述，預期的系統使用步驟與方法，用戶運行維護要求等。(4)修正的開發計畫：經過需求分析，對系統開發的成本估計，資源使用要求，專案進度計畫的可能修改。一份好的軟體需求規格說明應該具有唯一性、完整性、可驗證性、一致性、可跟蹤性、可修改性等特徵。1．唯一性用戶的每一個要求／系統功能僅有一種解釋。自然語言的二義性可能導致對於系統功能、性能的不同理解。

2．完整性軟體工程需求分析的完整性包括：·系統包含全部重要的用戶需求(功能、性能、設計約束、外部介面)；·規定每種輸入數據的軟體回應(正確輸入的回應和不正確輸入的回應)；·全部術語、圖表完整，符合需求規範標準。3．可驗證性

SRS中每個功能、性能需求是可以驗證的。

4．一致性SRS陳述的各項功能、性能要求是相容的，沒有互相發生軟體工程矛盾或者衝突。5．可修改性SRS的組織結構使得當需求發生必須的變化時，對SRS的修改能夠保證完整、一致、容易地完成。在SRS中，如果存在一個有關SRS內容的列表、索引和交叉引用表，則當某個需求發生變化時，就可以方便對SRS中必須修改的部分進行定位和修改。6．可跟蹤性對於軟體開發中的每個需求在SRS中可以追溯出其來源。實現可跟蹤性的常用方法是對SRS中每個段落按層編號，每個需求給以唯一編碼，使用特殊指示字對同一需求在SRS中的不同出現進行標識。軟體工程2.6軟體需求正確性驗證

2.6.1軟體需求正確性要求和驗證方法

為了提高軟體品質，確保軟體開發成功，降低軟體開發成本，一旦對目標系統提出一組要求之後，必須嚴格驗證這些需求的正確性。一般說來，應該從下述四個方面進行驗證：一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。完整性需求必須是完整的，規格說明書應該包括用戶需要的每一個功能或性能。現實性指定的需求應該是用現有的硬體技術和軟體技術基本上可以實現的。對硬體技術的進步可以做些預測，軟體工程對軟體技術的進步則很難做出預測，只能從現有技術水準出發判斷需求的現實性。有效性必須證明需求是正確有效的，確實能解決用戶面對的問題。那麼，怎樣驗證軟體需求的正確性呢?驗證的角度不同，驗證的方法也不同：1．驗證需求的一致性當需求分析的結果是用自然語言書寫的時候，除了靠人工技術審查驗證軟體系統規格說明書的正確性之外，目前還沒有其他更好的“測試”方法。但是，這種非形式化的規格說明書是難於驗證的，特別在目標系統規模龐大、規格軟體工程說明書篇幅很長的時候，人工審查的效果是沒有保證的，冗餘、遺漏和不一致等問題可能沒被發現而繼續保留下來，以致軟體開發工作不能在正確的基礎上順利進行。為了克服上述困難，人們提出了形式化的描述軟體需求的方法。當軟體需求規格說明書是用形式化的需求陳述語言書寫的時候，可以用軟體工具驗證需求的一致性，從而能有效地保證軟體需求的一致性。2．驗證需求的現實性為了驗證需求的現實性，分析員應該參照以往開發類似系統的經驗，分析用現有的軟、硬體技術實現目標系統的可能性。必要的時候應該採用仿真或性能模擬技術，輔助分析軟體需求規格說明書的現實性。軟體工程3．驗證需求的完整性和有效性只有目標系統的用戶才真正知道軟體需求規格說明書是否完整、準確地描述了他們的需求。因此，檢驗需求的完整性，特別是證明系統確實滿足用戶的實際需要(即，需求的有效性)，只有在用戶的密切合作下才能完成。然而許多用戶並不能清楚地認識到他們的需要(特別在要開發的系統是全新的，以前沒有使用類似系統的經驗時，情況更是如此)，不能有效地比較陳述需求的語句和實際需要的功能。只有當他們有某種工作著的軟體系統可以實際使用和評價時，才能完整確切地提出他們的需要。

軟體工程2.6.2用於需求分析的軟體工具

為了更有效地保證軟體需求的正確性，特別是為了保證需求的一致性，需要有適當的軟體工具支持需求分析工作。這類軟體工具應該滿足下列要求：(1)必須有形式化的語法(或表)，因此可以用電腦自動處理使用這種語法說明的內容；(2)使用這個軟體工具能夠導出詳細的文檔；(3)必須提供分析(測試)規格說明書的不一致性和冗餘性的手段，並且應該能夠產生一組報告指明對完整性分析的結果；(4)使用這個軟體工具之後，應該能夠改進通信狀況。作為需求工程方法學的一部分，在1977年設計完成了軟體工程RSL(需求陳述語言)。RSL中的語句是電腦可以處理的，處理以後把從這些語句中得到的資訊集中存放在一個稱為抽象系統語義模型(ASSM)的資料庫中。有一組軟體工具處理ASSM資料庫中的資訊以產生出用PASCAL語言書寫的模擬程式，從而可以檢驗需求的一致性、完整性和現實性。美國密執安大學開發了PSL／PSA(問題陳述語言／問題陳述分析程式)系統。這個系統是“電腦輔助設計和規格說明分析工具(CADSAT)”的一部分，它的基本結構類似於RSL。其中PSL是用來描述系統的形式語言，PSA是處理PSL描述的分析程式。用PSL描述的系統屬性放在一個資料庫中。一旦建立起資料庫之後即可增加資訊、刪除資訊或修改資訊，並且保持資訊的一致性。PSA對數據庫軟體工程進行處理以產生各種報告，測試不一致性或遺漏，並且生成文檔資料。PSL／PSA系統的功能主要有下述四種：(1)描述任何應用領域的資訊系統；(2)創建一個資料庫保存對該資訊系統的描述符；(3)對描述符施加增加、刪除和更改等操作；(4)產生格式化的文檔和關於規格說明書的各種分析報告。PSL／PSA系統用描述符從系統資訊流、系統結構、數據結構、數據導出、系統規模、系統動態、系統性質和軟體工程專案管理等八個方面描述資訊系統。一旦用PSI一對系統做了完整描述，就可以調用PSA產生一組分析報告，其中包括所有修改規格說明資料庫的記錄，用各種形式描述資料庫資訊的參照報告(包括圖形形式的描述)，關於專案管理資訊的總結報告，以及評價資料庫特性的分析報告。借助PSL／PSA系統可以邊對目標系統進行自頂向下的逐層分解，邊將需求分析過程中遇到的數據流、檔、處理等對象用PSI。描述出來並輸入到PSL／PSA系統中。PSA將對輸入資訊作一致性和完整性檢查，並且保存這些描述資訊。軟體工程2.7需求分析指南

按照軟體工程對軟體開發過程的描述，需求階段我們可以細分為需求調研和需求分析兩個小階段，需求調研需要充分細緻的瞭解客戶目標，用戶業務內容、流程等，這是一個對需求的採集過程，是進行需求分析的基礎準備。當我們已經瞭解、理解了用戶的業務，於是可以開始分析需求了。軟體系統的需求分析可以由產品工程師或系統分析員或兩者分階段合作完成全部的需求分析工作。一、

提取出核心、主要、急迫的業務，明晰業務流程二、

運用管理思想，優化業務流程

軟體工程本章小結

需求分析是在可行性研究的基礎上進行的，可行性研究實質上是一次完整的分析和設計過程，只不過是在抽象的層次上進行的大大壓縮和簡化了的分析和設計過程。因此在可行性研究階段已經進行了某些初步的分析，特別是已經得出了高層次的數據流圖。但是，需求分析的主要任務是得出詳細的系統邏輯模型。通常需求分析工作從可行性研究得出的數據流圖出發，首先確定構成輸出數據的各個數據元素，沿數據流圖回溯尋求每個數據元素的源，在此過程中確定必要的處理演算法並補充必要的數據元素，同時也會產生一些新的問題。在尋求這些問題的答案時，將澄清一些演算法並劃分出更多的數據元素，可能也會再遇到一些問題。對這些問題的解答又將導致對系統的更深入更具體的認識。在對系統的主要軟體工程處理演算法有充分瞭解之後，應該把數據流圖進一步分層細化。通過需求分析應該得出用數據流圖、ER圖、數據字典和IPO圖(或PDL等其他描述演算法的工具)描繪的精確的系統邏輯模型。為了提高文檔的可理解性，還可以用層次方框圖或Warnier圖等圖形工具輔助描繪系統中的數據結構。為了減少冗餘、簡化修改步驟，往往需要規範數據的存儲結構。需求分析的結果是軟體開發的基礎，必須仔細驗證它的正確性，開發人員必須和用戶取得完全一致的意見，需求分析的文檔應該被用戶所確認。軟體工程第6章項目管理

本章要點：軟體專案管理概念專案管理組織及過程

軟體品質及保證CMM模型軟體工程本章學習目標：瞭解專案管理過程

理解專案的估算方法瞭解CMM模型的層次結構

軟體工程6.1專案管理概述

專案管理就是為了滿足甚至超越專案涉及人員對專案的需求和期望而將理論知識、技能、工具和技巧應用到專案的活動中去。

需要在下面這些相互間有衝突的要求中尋求平衡：

範圍、時間、成本和品質

有不同需求和期望的專案涉及人員

明确表示出来的要求（需求）和未明确表达的要求在軟體行業，對專案實施有效的管理是軟體成敗的關鍵。軟體工程專案管理的過程

軟體專案啟動度量

估算

風險分析

進程安排

追蹤和控制

軟體工程6.2專案計畫

計畫是管理工作的重要職能，在軟體專案管理中，軟體專案從制定專案計畫開始。專案計畫中需要確定以下幾項內容：

目標：定義了待完成的目標，迫切需要的資源，約束和優先順序。範圍：定義待開發系統的邊界，什麼包括在系統裏，什麼不包括在系統裏。產品技術說明：說明軟硬體資訊以及有關功能、性能、安全性等方面的約束。時間：進度表。資金：預算。地點：工作空間分配。人員：參與人員以及專案組織。軟體工程6.3進度安排

軟體開發專案的進展安排有兩種考慮方式：

系統最終交付日期已經確定，軟體開發部門必須在規定期限內完成任務。系統最終交付日期只確定了大致的年限，最後交付日期由軟體開發部門確定

進度安排是基於對專案的需求分析和評審軟體工程專案的並行性提出一系列進度要求。因為並行任務是同時發生的，以進度計畫決定任務之間的從屬關係，確定各個任務的先後次序和銜接，以及各個任務完成的持續時間。

軟體工程6.4專案估算對軟體專案進行有效的估算，取決於掌握多少有關專案範圍的原始資料。估算的兩個主要方法是：第一種方法是根據專案特徵和演算法進行估算。第二種方法是採用類比的方法，根據歷史數據來進行估算。

軟體工程專案規模估算量軟體專案規模最常用的概念--LOC

L指所有的可執行的源代碼行數，包括可交付的工作控制語言（JCL：JobControlLanguage）語句、數據定義、數據類型聲明、等價聲明、輸入/輸出格式聲明等。

規模估算的三種方法方法一、Delphi法

方法二、類比法方法三、功能點估計法

軟體工程軟體開發成本估算軟體開發成本主要是指軟體開發過程中所花費的工作量及相應的代價。軟體開發成本的估算，應是從軟體計畫、需求分析、設計、編碼、單元測試、組裝測試到確認測試，整個軟體開發過程所花費的代價作為依據的。

對於一個大型的軟體專案，要進行一系列的估算處理，主要靠分解和類推的方法進行。基本估算方法分為3類：

自頂向下的估算方法自底向上的估算法差別估計法軟體工程6.5專案組織組織原則

（1）

早落實原則

（2）

減少介面

（3）

責權均衡

2人員配備

軟體工程6.6軟體品質按照ANSI/IEEE1983年的標準，軟體品質定義為“與軟體產品滿足需求所規定的和隱含的能力有關的特徵和特性的全體。”軟體產品中所能滿足用戶給定的全部特性的集合軟體具有所期望的各種屬性組合的程度用戶主觀得出的軟體是否滿足其綜合期望的程度決定所用軟體在使用中將滿足其綜合期望程度的軟體合成特性軟體工程品質保證的主要內容軟體工程品質保證應用於整個軟體過程的保護活動，包括：（1）

品質管理方法（2）

有效的軟體工程技術（方法和工具）。（3）

應用於整個軟體過程的形式化技術評論。（4）

多等級測試策略。（5）

軟體文檔以及對軟體進行改變和維護的控制和約束（6）

確保遵照軟體開發標準的過程。（7）

測量和報告機制。軟體工程軟體工程標準化軟體工作的範圍從只是使用程式設計語言編寫程式，擴展到

整個軟體生存期。所有這些方面都應逐步

建立起標準或規範來。

軟體工程標準的類型也是多方面的。它可能包括過程標準(如方法、技術、度量等)、產品標準(如需求、設計、部件、描述、計畫、報告等)、專業標準(如職別、道德準則、認證、特許、課程等)以及記法標準(如術語、表示法、語言等)。

軟體工程軟體工程標準的制定與推行通常要經歷一個環狀的生命期(參看圖6．2)。最初，制定一項標準僅僅是初步設想，經發起後沿著環狀生命期，順時針進行要經歷以下的步驟：軟體工程CMM模型

CMM(CapabilityMaturityModel)即能力成熟度模型，定義了當一個組織達到不同的過程時應該具有的軟體工程能力。它描述了軟體過程從無序到有序、從特殊到一般、從定性管理到定量管理、最終到達可動態優化的成熟過程。給出了該過程中5個成熟階段的基本特性和應遵循的原則、採取的行動，以幫助軟體組織改進其軟體過程。

CMM的基前提是：軟體品質在很大程度上取決於開發軟體的軟體過程的品質和能力；軟體過程是一個可管理、可度並不斷改進的過程；軟體過程的品質受到用以支撐它的技術和設施的影響；軟體開發組織在軟體過程中所採用的技術層次應適應於軟體過程的成熟度。軟體工程CMM模型

將CMM組織成下圖所示的5個等級，其意在於增加軟體過程成熟的改進行動按優先順序排序。圖中帶有標記的箭頭，指示在成熟度框架的每一步驟上，組織應予以規範化的過程能力的類型。

[5]優化級[4]已管理級[2]可重複級[3]已定義級[1]初始級軟體工程6.7軟體配置管理系統配置指的是交付給特定客戶的一個系統構件的集合

軟體配置管理是監督和控制工作產品中變化的過程。變化遍及整個軟體開發過程。

軟體配置管理是軟體系統發展過程中管理和控制變化的規範[IEEEStD.1042-1987]。配置管理系統使得版本的識別、存儲和檢索以及支持狀態記錄自動完成。配置管理包括下列活動：配置項的確定變化控制狀態記錄審核軟體工程配置管理的過程軟體配置管理的方法大致分三類：單獨檔、增量和條件編譯。以上三種方法各有優缺點，在實際的專案培訓配置管理中是將這些方法有機結合起來滿足複雜的配置管理要求。

軟體工程6.8常用軟體專案管理工具

開發人員有許多配置管理和版本管理的工具可用，就解以下幾種:

RCS[Tichy,1985],CVS[Berliner,1990],Perforce[Perforce],

Clea