软件工程课件

1

软件工程

SoftwareEngineering

1.1軟體的分類（1）系統軟體：系統軟體是一組為其他程式服務的程式。一些系統軟體(如編譯器、編輯器和文件管理程式)處理複雜的但也是確定的資訊結構。其他的系統應用(如操作系統、驅動程式和通訊進程等)則處理大量的非確定的數據。不管哪種情況，系統軟體均具有以下特點：與電腦硬體頻繁交互；多用戶支持；需要精細調度、資源共用及靈活的進程管理的併發操作；複雜的數據結構；及多外部介面。21.1軟體的分類（2）應用軟體：應用軟體是一些可以滿足特定業務需要的獨立應用程式。應用軟體處理商務或者技術數據，以協助業務操作和管理或技術決策。除了傳統數據處理的應用程式，應用軟體業被用於業務領域的即時控制（如：銷售點的交易處理，即時製造過程控制）31.1軟體的分類（3）工程和科學計算軟體：工程和科學計算軟體的特徵是“數值分析”演算法。此類應用含蓋面很廣，從天文學到火山學；從汽車壓力分析到太空梭的軌道動力學；從分子生物學到自動化製造。不過，目前工程和科學計算軟體已不僅限於傳統的數值演算法。電腦輔助設計、系統仿真和其他交互應用已經開始具有即時軟體和系統軟體的特徵。41.1軟體的分類（4）嵌入式軟體：智能產品在幾乎每一個消費或工業市場上都是必不可少的，嵌入式軟體駐留在只讀記憶體中，用於控制這些智能產品。嵌入式軟體能夠執行很有限但專職的功能(如微波爐的按鈕控制)，或是提供比較強大的功能及控制能力(如汽車中的數字控制，包括燃料控制、儀錶板顯示，刹車系統等)。51.1軟體的分類（5）產品線軟體：產品的設計方向為多個不同用戶的使用提供特定功能，關注有限的特定市場（例如庫存管理系統）或大眾消費品市場。（文字處理、電子錶格、電腦圖形、多媒體、娛樂、資料庫管理、個人及商業金融應用等）。61.1軟體的分類（6）Web應用軟體：“web應用”涵蓋廣泛的應用程式產品，如電子商務和B2B應用，各類網路應用，如BBS,blog等。71.1軟體的分類（7）人工智慧軟體：人工智慧(AI)軟體利用非數值演算法去解決複雜的問題，這些問題不能通過計算或直接分析得到答案。一個活躍的AI領域是專家系統，也稱為基於知識的系統。AI軟體的其他應用領域還包括模式識別(圖象或聲音)、定理證明和遊戲。最近，AI軟體的一個新分支，稱為人工神經網路，得到了很大進展。神經網路仿真人腦的處理結構(生物神經系統的功能)，這有可能導致一個全新類型的軟體登場，它不僅能夠識別複雜的模式，而且還能從過去的經驗中自行學習進步。81.2軟體的定義、發展和危機1.2.1軟體的定義軟體==程式+數據+文檔。數據==初始化數據+測試數據文檔==開發文檔+管理文檔。今天仍然有人認為：軟體等於程式。這些人一上來就寫程式。RogerS.Pressman說：“越早開始寫代碼的人，就是越遲完成代碼的人”。

91.2.1軟體的定義軟體的最新定義：軟體==知識+程式+數據+文檔對這一定義的討論：正方：因為軟體是知識在網路上的體現，所以這個定義非常好。反方：程式、數據、文檔本身就是知識的表現，所以這個定義是畫蛇添足。10軟體文檔具有嚴格的層次關係(1)“目標程式”覆蓋“根源程式”；(2)“根源程式”覆蓋“詳細設計說明書”；(3)“詳細設計說明書”覆蓋“概要設計說明書”；(4)“概要設計說明書”覆蓋“需求規格說明書”；11(5)“需求規格說明書”覆蓋“用戶需求報告”；(6)“用戶需求報告”覆蓋“軟體合同”。管理文檔具有嚴格的時序關係：因為管理是一個過程。12程式的定義(1).面向過程的程式==演算法+數據結構。(2).面向對象的程式==對象+消息。(3).面向數據的程式==資料庫表+在表上的操作(如存貯過程、觸發器或視圖)。(4).面向構件的程式==構件+構架。13優秀的程式(或模組)，必須滿足“高內聚、低耦合”的性質。所謂高內聚，就是程式(或模組)內部結構緊湊，凝聚力和向心力強。所謂低耦合，就是程式(或模組)之間彼此依賴關係很低。有人說：“人生就是一段程式，這段程式是用特殊代碼寫成的，只是演算法極其複雜而已。”142024-2-7廣東工業大學電腦學院15軟體開發的發展過程電腦應用發展軟體數量多規模大軟體成本高質量低個體化軟體開發方法軟體維護困難軟體危機軟體工程2024-2-7廣東工業大學電腦學院161.2.2軟體的發展和危機自第一臺電腦誕生以來，軟體的生產就開始了。隨著電腦技術的飛快發展和應用領域迅速拓寬，自20世紀60年代中期以後，軟體需求迅速增長，軟體數量急劇膨脹。這種增長導致了軟體的發展，可以將軟體生產的發展劃分為三個時代。2024-2-7廣東工業大學電腦學院171.程式設計時代（1946~1956年）在這一時期，軟體的生產主要是個體手工勞動的生產方式。程式設計者使用機器語言、組合語言作為工具；開發程式的方法上主要是追求編程技巧和程式運行效率。在程式設計中還沒有注意其他輔助作用，因此所設計的程式難讀、難懂、難修改。這個時期軟體特徵是只有程式、程式設計概念，不重視程式設計方法。2024-2-7廣東工業大學電腦學院182.程式系統時代（1956~1968年）由於電腦的應用領域不斷擴大，軟體的需求也不斷增長，軟體由於處理的問題域擴大而使程式變得複雜，設計者不得不由個體手工勞動組成小集團合作，形成作坊式生產方式小集團合作生產的程式系統時代。生產工具是高級語言。開發方法仍舊靠個人技巧。開發方法仍舊靠個人技巧。由於大的程式需要合作，在程式設計中開始提出結構化方法。2024-2-7廣東工業大學電腦學院193.軟體工程時代（1968年至今）1968年在聯邦德國召開的國際會議上討論軟體危機的問題，在這次會議上正式提出並使用了“軟體工程”術語，新的工程科學就此誕生。軟體工程時代的生產方式是採用工程的概念原理技術和方法。使用資料庫、開發工具、開發環境、網路、分佈式、面向對象技術來開發軟體。2024-2-7廣東工業大學電腦學院201.2.3軟體危機所謂軟體危機是指在電腦軟體的開發和維護過程中所遇到的一系列嚴重問題。這種“嚴重問題”不僅僅是“不能正常運行”。實際上幾乎所有的軟體都不同程度地存在問題。軟體危機主要是指如何開發軟體，怎樣滿足對軟體日益增長的需求，如何維護數量不斷膨脹的現有軟體。2024-2-7廣東工業大學電腦學院211.軟體危機的表現（1）對於軟體開發的成本和進度的估計很不准確。由於缺乏軟體開發的經驗和軟體開發數據的積累，使得開發工作的計畫很難制定。主觀盲目制定的計畫，執行起來和實際情況有很大差距，使得開發經費一再突破。由於對工作量和開發難度估計不足，進度計畫無法按時完成，開發時間一再拖延。2024-2-7廣東工業大學電腦學院22（2）開發的軟體產品不能完全滿足用戶要求，用戶對已完成的軟體系統不滿意的現象常常發生。一般情況下軟體開發人員在開發初期對用戶的要求瞭解不夠明確，未能得到明確表達，就開始著手編程。開發工作開始後，軟體人員和用戶又未能及時交換意見，使得一些問題不能及時解決，導致開發的軟體產品不能完全滿足用戶要求。2024-2-7廣東工業大學電腦學院23（3）開發的軟體可靠性差。由於在開發過程中，沒有確保軟體品質的體系和措施，在軟體測試時，又沒有嚴格的、充分的、完全的測試，提交給用戶的軟體品質差，在運行中暴露出大量的問題。這種不可靠的軟體，輕則會影響系統正常工作，重則會發生事故，造成生命財產的重大損失。2024-2-7廣東工業大學電腦學院24（4）軟體通常沒有適當的文檔。開發過程無完整、規範的文檔，發現問題後進行雜亂無章的修改。程式結構不好，運行時發現錯誤也很難修改，導致可維護性差。2024-2-7廣東工業大學電腦學院25（5）軟體的可維護性差。由於開發過程沒有統一的、公認的規範，軟體開發人員按各自的風格工作，各行其是。很多程式中的錯誤非常難改，實際上不可能使這些程式適應新的硬體環境，也不可能根據用戶要求在程式中增加新功能。2024-2-7廣東工業大學電腦學院26（6）軟體開發生產率提高的速度，遠遠跟不上電腦應用普及深入的趨勢。軟體產品“供不應求”的現象使人類不能充分利用電腦硬體資源提供的巨大潛力。2024-2-7廣東工業大學電腦學院272.軟體危機的產生軟體發展第二階段的末期，由於電腦硬體技術的進步，電腦運行速度、容量和可靠性有顯著的提高，生產成本有顯著下降，為電腦的廣泛應用創造了條件。一些複雜的、大型的軟體開發專案提了出來。但是，軟體開發技術一直未能滿足發展的要求。軟體開發中遇到的問題因找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，導致了軟體危機。2024-2-7廣東工業大學電腦學院283.軟體危機的原因 在軟體的開發和維護過程中存在著這麼多的問題，一方面與軟體本身的特點有關，另一方面也與軟體的開發和維護的方法有關。造成上述軟體危機的原因概括起來有以下幾方面：2024-2-7廣東工業大學電腦學院29（1）軟體的規模愈發龐大。隨著電腦應用的日益廣泛，需要開發的軟體規模日益龐大，軟體結構也日益複雜。有人曾估計，軟體設計與硬體設計相比，其邏輯量要多達10~100倍。對於這種龐大規模的軟體，其調用關係、介面資訊複雜，數據結構也複雜，這種複雜程度超過了人所能接受的程度。2024-2-7廣東工業大學電腦學院30（2）軟體開發的管理困難。軟體不同於硬體，它是電腦系統中的邏輯部件。在寫出代碼並在電腦上試運行前，由於軟體規模大，結構複雜，又具有無形性，軟體開發過程的進展情況較難度量，品質也難評價。因此導致管理困難，進度控制困難，品質控制困難，可靠性無法保證。2024-2-7廣東工業大學電腦學院31（3）軟體本身的獨有特點確實給開發和維護造成一些客觀困難，但是人們在長期的實踐中也積累了不少成功的經驗。如果堅持使用成功的經驗和正確的方法，許多困難是可以克服的。但是相當多的軟體開發人員對於軟體的開發和維護存在不少糊塗的觀念，實踐中或多或少地採用錯誤的方法和技術。這可能是軟體危機的主要原因。2024-2-7廣東工業大學電腦學院32（4）軟體開發和維護中許多錯誤認識和方法的形成可以歸結與電腦發展早期軟體開發的個體化特點。其主要表現在對軟體需求分析的重要性認識不夠，錯誤地認為軟體開發就是寫程式並使之運行，不重視軟體需求分析與維護等工作。2024-2-7廣東工業大學電腦學院33（5）軟體開發技術落後。在20世紀60年代，人們注重一些電腦理論問題的研究，如編譯原理、操作系統原理、資料庫原理、人工智慧原理、形式語言理論等，不注重軟體開發技術的研究，用戶要求的軟體複雜性與軟體技術解決複雜性的能力不相適應，它們之間的差距越來越大。2024-2-7廣東工業大學電腦學院34（6）生產方式落後。軟體仍然採用個體手工方式開發，根據個人習慣愛好工作，無章可循，無規範可依據，靠言傳身教方式工作。2024-2-7廣東工業大學電腦學院35（7）開發工具落後，生產率提高緩慢。軟體開發工具過於原始，沒有出現高效率的開發工具，因而軟體生產率低下。在1960~1980年期間，電腦硬體的生產由於採用電腦輔助設計、自動生產線等先進工具，使硬體生產率提高了100萬倍，而軟體生產率只提高了2倍，相差十分懸殊。1.3軟體工程--定義IEEE[IEE93]的綜合定義(1)將系統化的、規範的、可度量的方法應用於軟體的開發、運行和維護的過程，即將工程化應用於軟體中(2)軟體工程的性質軟體工程要用工程科學中的觀點來進行費用估算、制定進度、制定計畫和方案；要用管理科學中的方法和原理進行軟體生產的管理；要用數學的方法建立軟體開發中各種模型和各種演算法，如可靠性模型，說明用戶需求的形式化模型等。

361.3軟體工程—學科、層次品質關注點過程方法工具37程式設計方法學和軟體工程方法學是為了解決軟體危機問題而逐漸形成的學科。“軟體工程”（SoftwareEngineering）作為一個術語，是在1968年北大西洋公約組織的一次電腦學術會議上，正式提出來的。這個會議專門討論了軟體危機問題。這次會議是軟體發展史上一個重要的里程碑1.3軟體工程—過程模型(1)溝通--與客戶以及與團隊成員的溝通(2)策劃--任務、需求、風險、計畫、產品規格(3)建模--軟體建模和設計(4)構建--編碼和測試(5)部署--軟體交付和意見回饋381.4軟體工程研究的內容(1).軟體開發模型，如：瀑布模型、增量模型、原型模型、螺旋模型、迭代模型等。(2).軟體開發方法，如：面向過程的方法、面向數據的方法、面向對象的方法(包括面向業務基礎平臺的方法、面向工作流方法、面向主體的方法、面向方面的方法、面向代理的方法等等)，以及形式化方法。39(3).軟體支持過程，如：CASE工具Rose、北大青鳥系統、PowerDesigner、ERWin，以及配置管理工具等。(4).軟體管理過程，如：ISO9000、CMM/CMMI、軟體企業文化(微軟企業檔、敏捷文化現象、IBM企業文化)。40

【例】請開發一個“圖書館資訊系統”，即圖書館MIS。這是一項軟體工程，為了完成這項任務，讀者首先要選擇軟體開發模型，確定開發方法，準備開發工具，設計開發環境和運行環境，然後進行需求分析、概要設計、詳細設計、編程、測試、試運行、正式運行、驗收和交付，最後是系統維護或系統升級換代。這一系列的軟體開發過程和管理過程，就是軟體工程。411.5軟體工程的基本原理(1).用分階段的生命週期計畫，嚴格管理軟體開發。這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗專案是由於計畫不周而造成的。在軟體開發與維護的漫長生命週期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命週期分成若干階段，並相應制定出切實可行的計畫，然後嚴格按照計畫對軟體的開發和維護進行管理。421.5軟體工程的基本原理(2).堅持進行階段評審。統計結果顯示：大部分錯誤是在編碼之前造成的，大約占63%；錯誤發現得越晚，改正它要付出的代價就越大，要差2到3個數量級。因此，軟體的品質保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便儘早發現錯誤。431.5軟體工程的基本原理(3).實行嚴格的產品版本控制。在軟體開發的過程中不應隨意改變需求，因為改變一項需求需要付出較高的代價。但是實踐告訴我們，需求的改動往往是不可避免的。由於各種客觀的需要，不能禁止用戶提出改變需求的要求，而只能依靠科學的產品控制技術來適應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其他各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。441.5軟體工程的基本原理(4).採用現代程式設計技術。從提出軟體工程的概念開始，人們主要的精力都用於研究各種新的程式設計技術，20世紀60年代的結構化軟體開發技術，隨後又發展的結構化分析和結構化設計技術，已成為大多數人認為的先進程式設計技術。後來又提出的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大於氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。45(5).結果應能清楚地審查。文檔要有嚴格要求。軟體產品不同於一般的物理產品，軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，儘量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。46

(6).開發小組的成員要少而精。開發人員的素質和數量是影響軟體品質和開發效率的重要因素，應該少而精。這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少得多。當開發小組為N人時，可能的通訊通道為N(N-1)/2，可見隨著人數N的增大，通訊開銷將急劇增大。

47(7).要不斷地改進軟體工程實踐的經驗和技術。遵從上述前六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐

(8).二八定律，這條原理特別重要，專案經理與高層經理，要特別牢記。在給定成本、進度的前提下，開發出具有可修改性、有效性、可靠性、可理解性、可維護性、可重用性、可適應性、可移植性、可追蹤性和可互操作性並滿足用戶需求的軟體產品。481.6軟體工程的作用（1）【例】20世紀90年代初，有兩個軟體團隊，一個較大（10多人），一個較小（6人），都在開發財務系統。較大的那個團隊，工作不規範，沒有文檔，沒有評審，沒有團隊精神，結果開發出來的產品可維護性差，沒有打開市場，致使產品與團隊最後同歸於盡。49

較小的那個團隊，分工明確：一人負責原始憑證和輸出報表的收集、歸類和整理，這實際上是做需求分；一人負責科目和數據字典（代碼），這實際上是做資訊的標準化與規範化；一人負責記賬憑證的錄入和修改，這實際上是做資料庫的設計和加載工；50

一人負責日記賬、明細賬和總賬之間的平衡與對賬，這實際上是做數據處理；一人負責統計、報表和查詢，這實際上是做數據輸出工作；一人負責總體設計和專案管理，這就是專案經理的工作。他們最後發展成為一個大型IT企業。511.6軟體工程的作用（2）

從軟體專案團隊來講，解決在規定的時間內，按照規定的成本，完成預期品質目標(軟體的功能、性能和介面達到需求報告標準)的軟體。從軟體企業本身來講，解決持續地規範軟體開發過程和軟體管理過程，不斷地優化軟體組織的個人素質和集體素質，從而逐漸增強軟體企業的市場競爭實力。52

從軟體發展進程來講，克服軟體危機，控制軟體進度，節約開發成本，提高軟體品質。從院校來講，以前它只是作為一門課或一本書。現在它成為一個學科，一個體系，一個電腦學位，即軟體工程碩士學位和軟體工程博士學位。53軟體工程作用的具體表現

在選擇開發工具上，軟體工程的基本觀點是：工具不是越新越好，而是你越熟悉越好；在風險評估上，軟體工程的基本觀點是：任何專案組都存在技術風險和技能風險；在專案策劃上，軟體工程的基本觀點是：需求分析在前，專案策劃在後；54

在開發進度上，軟體工程的觀點是：寧願慢些，也要保證軟體的品質；在開發品質上，軟體工程的觀點是：品質蘊涵於開發過程之中，而不是過程之後；在開發人員上，軟體工程的觀點是：專案組在中途靠增加開發人員來提高開發速度是無效的；在專案經理的職責上，軟體工程的觀點是：80%的時間是寫文檔，20%的時間是內部勾通.551.7軟體的開發方法

1.7.1三種開發方法

到目前為止，共有4種軟體開發方法：(1).面向過程的方法

(2).面向數據的方法

(3).面向對象的方法(包括面向業務基礎平臺的方法、面向工作流方法、面向方面的方法、面向服務的方法)。

(4).此外還有形式化方法。56開發方法來自於程式設計語言(1).面向過程的程式==演算法+數據結構。

(由順序、分支、迴圈三種結構組成)

由它產生了面向過程的方法。(2).面向數據的程式==表+表上的操作。由它產生了面向數據的方法。(3).面向對象的程式==對象+消息。由它產生了面向對象的方法。571.7.2面向過程的方法

內容：面向過程需求分析、面向過程設計、面向過程編程、面向過程測試、面向過程維護、面向過程管理。面向過程的方法，又稱為面向功能的方法，或稱為結構化方法。58面向過程的方法

特點：程式的執行過程，不由用戶控制，完全由程式員控制。優點：簡單實用。缺點：企圖用有窮的方法(枚舉法)來描述無窮的(隨機的)資訊世界，所以不能完全描述資訊世界；維護困難。59

【例】面向過程的方法，在軍事上的即時跟蹤監控系統中有很好的應用。如我方偵察衛星發射後其飛行軌跡的捕獲、測量、跟蹤和預報，導彈防禦系統中敵方導彈發射後飛行軌跡的捕獲、測量、跟蹤和預報，其軟體系統都是採用面向過程的方法設計和實現的。使用面向過程的方法，系統的執行路徑可由系統自動控制，也就是程式自動控制，這是一切自動控制與跟蹤系統所必須的。601.7.2面向對象的方法

內容：面向對象需求分析、面向對象設計、面向對象編程、面向對象測試、面向對象維護、面向對象管理。在分析、設計、實現中用到“對象、類、繼承、消息通信”這四個基本概，就是面向對象的方法。今天用UML來開發軟體，就是面向對象的方法。

61面向對象的方法

特點：

(1).程式的執行過程，不由程式員控制，完全由用戶控制。

(2).分析設計時面向類，編程時面向對象。

優點：用無窮的方法來描述無窮的(隨機的)資訊世界，所以能完全描述資訊世界；易於維護。

缺點：較難掌握

。62

【例】面向對象的方法在電子商務中的應用有：網站前臺介面的製作，資訊的發佈和處理，用戶在網上流覽和錄入資訊等應用軟體都是利用面向對象的方法設計與實現的。個人網頁的製作也是面向對象方法的應用例子。窗口操作系統與互聯網的出現，為面向對象方法開闢了無限的前景。63面向對象方法的特例1：

面向业务基础平台的方法

內容：業務基礎平臺遮罩了操作系統平臺、資料庫平臺的諸多技術細節，採用面向業務的建模方法進行開發，有效彌合了技術人員和業務人員之間的溝通鴻溝，可以使開發人員更多地關注業務部分，而不是技術細節。

64面向業務基礎平臺的方法

特點：面向業務領域的、而與技術無關的開發模式。本質上仍然是面向對象的方法。

優點：提升了構件的複用性。缺點：業務基礎平臺是面向業務行業的，不同行業之間的通用平臺標準尚出產生。651.7.3面向數據的方法

這裏講的面向數據的方法，既不是傳統軟體工程中所講的“面向數據流”的方法，也不是傳統意義上的面向數據結構的Jackson方法。事實上，這兩種方法早已過時，但是許多書上還在講，真是有點誤人子弟。66面向數據的方法

我們講的面向數據的方法，是面向元數據（Metadata）的方法，它是建設資訊系統資料庫和數據倉庫的基本方法。該方法將與關係資料庫同生死、共患難。

67面向數據的方法內容：

(1)數據位於資訊系統的中心。

(2)由元數據構成的數據模型是穩定的。

(3)對元數據的處理方法是可變的。

(4)企業資訊系統的核心是數據模型。

(5)系統的實現方法主要是面向對象。

(6)用戶始終參與資訊系統的開發。68面向數據的方法

特點：程式的執行過程，有時由程式員控制，有時由用戶控制。優點：適合數據層(資料庫伺服器)設計與實現。缺點：實現窗口介面較困難。69

【例】面向數據的方法在電子商務中也有應用。網站後臺資料庫伺服器上的數據處理和數據傳輸，其軟體都是利用面向數據的方法設計與實現的。實際上，不管網路應用系統結構是兩層結構或三層結構，在資料庫伺服器上對數據的分析、設計和實現，都自覺或不自覺地使用了面向數據的方法。70*1.7.4軟體工程的形式化方法

不講，考研的人可以自學。因為在IT企業用不上。711.7.5四種開發方法總結對比方法名稱優點缺點適合的場合面向過程的方法

簡單好學

不適應窗口介面，維護困難

大型工程計算，即時數據跟蹤處理，各種自動化控制系統，以及系統軟體實現等領域面向對象的方法

功能強大，易於維護

不易掌握

互聯網路時代，完全由用戶交互控制程式執行過程的應用軟體和系統軟體的開發面向數據的方法

通俗易懂

不適應窗口介面

以關係資料庫管理系統為支撐環境的資訊系統建設形式化方法準確、嚴謹難於上手和應用對安全性要求極高，不容許出錯的軟體系統，如軍事、醫藥、交通等領域721.8軟體工程的五個面向理論

面向過程的方法、面向對象的方法、面向數據的方法，這三種開發方法哪個最好呢？當然是面向對象。但是，任何好與壞，都是相對的，有條件的，不是絕對的。這三種開發方法各有千秋，面向對象方法稍強，它們分別適合於不同的環境和不同的場合。73五個面向理論

綜合這三種開發方法的優勢，特別提出“五個面向”的實施理論：

1.面向流程分析

2.面向數據設計

3.面向對象實現

4.面向功能測試

5.面向過程管理74面向流程分析

面向流程分析，就是面向流程需求分析。在需求分析時，系統分析員要面向業務流、資金流、資訊流進行分析。只有將這“三個流”分析透了，才建立好系統的業務模型和功能模型。因為電腦網絡在本質上只認識數據及數據流(二進位數據的流動)，而且這“三個流”，可以用“數據流”這一個流程來代替，或者說“三個流”是“數據流”在三個不同方向的投影。75面向數據設計

面向數據設計，就是面向元數據進行概要設計。在系統設計時，系統設計師要採用面向數據的方法進行概要設計。面向數據就是面向“元數據”（Metadata）。76面向數據設計

概要設計的主要任務是建立系統的概念數據模型CDM和物理數據模型PDM，以及體現業務規則的存儲過程和觸發器，然後以數據模型為支撐，去實現系統的業務模型和功能模型。為此，要對元數據進行分析，只有將元數據分析透了，才能建立好由元數據所構成的數據模型。這裏講的面向數據設計，主要表現在資料庫伺服器上的關係資料庫設計。77面向對象實現

面向對象實現，就是面向對象進行詳細設計和編程實現。在兩層結構(C/S)的客戶層上，在三層結構(B/A/S)的表示層和業務邏輯層上，進行詳細設計和編程實現時，要採用面向對象的方法。當然，在數據服務層上的設計和編程實現，仍然要採用面向數據的方法，因為主要是設計和編寫存儲過程，它們是面向數據的，不是面向對象的。78面向對象實現

詳細設計和編程實現，實質上是用構件加上程式來實現系統的業務模型和功能模型。只有對三個模型思想(業務模型、功能模型、數據模型)吃透了，才能設計和編寫出合格的程式。面向對象實現，實質上是面向類實現，因為實例化的類稱為對象。79面向功能測試

面向功能測試，就是面向功能進行單元測試、集成測試、Alpha測試和Beta測試。在進行測試時，測試人員要採用面向功能的方法。這裏講的功能，包括系統的功能、性能和介面三部分內容。面向功能測試的方法就是黑盒子測試方法，今後採用白盒子測試方法(面向程式執行路徑測試)的人，只有從事軟體構件生產和核心代碼編程的極少數人員。80面向過程管理

面向過程管理，就是面向過程對軟體生命週期各個階段進行管理和控制。因為軟體產品品質的提高與改進，完全取決於軟體企業生產過程的改善。無論是CMM/CMMI、ISO9000、微軟企業文化，都是站在軟體生命週期過程的觀念上去提高軟體企業的素質。811.9軟體的支持過程

軟體工程中的過程，是指軟體生命週期(LifeCycle)中的時間序列。過程作為一個時間序列，它自然有起始點和終止點。例如，可以將一個軟體的生命週期劃分為市場調研、立項、需求分析、策劃、概要設計、詳細設計、編程、單體測試、集成測試、運行、維護這幾個過程。過程與階段(Phase)相對應，階段與里程碑(Milestone)相對應。某些重要的里程碑上的文檔，又對應基線(baseline)。82軟體的支持過程軟體工程的支持過程，由支持軟體生存週期各個階段的生產工具所組成。生產工具如需求分析工具、設計工具、實現工具、測試工具、維護工具、配置工具，開發環境。軟體開發環境又稱CASE工具，如北大青鳥系統，SanFrancisco，Rose，面向行業領域開發的業務基礎平臺(包括軟體企業內部使用的各種J2EE平臺和.Net平臺)。831.10軟體的管理過程

“外行關注結果，內行關注過程”。

管理過程和支持過程又稱為“軟體過程工程”。

1974年，美國人始認識到“軟體需要管理”。

1984年，美國人認識到“軟體管理是過程管理”。84軟體的管理過程

軟體中的過程，分為“基本過程、支持過程、組織過程”三種.

基本過程是需求、設計、實現、測試、驗收過程；

支持過程是支持過程開發和過程管理的各種CASE工具；

組織過程是建立的有關小組，如軟體工程組、品質保證組、測試組、文檔組。85軟體的管理過程

軟體工程中主要存在3類過程管理模型：

(1).ISO9000品質管理和品質保證體系

(2).CMMI過程能力成熟度模型集成

(3).企業文化

(微軟企業文化、敏捷文化現象等

)86序號名稱來源特點1ISO9000品質管理和品質保證體系

國際標準化組織

ISO

按20多個品質要素管理2CMMI軟體能力成熟度模型

美國卡內基-梅隆大學軟體工程研究所（CMU/SEI）

按24個過程域PA，分階段模型和連續模型兩種方式管理，屬於重載過程管理3

軟體企業文化Microsoft公司、IBM公司、敏捷方法

屬於輕載過程管理871.10.1ISO9000體系1.“品質手冊”內容：品質方針和目標、公司簡介、組織機構、品質體系要求、品質手冊管理細則等2.“程式檔”內容：規定每個品質要素在何時、在何地、由何人、按照什麼標準、規範或規程去做。做完後書寫品質記錄的範本格式(如：用戶需求報告範本或指南、設計說明書範本或指南、測試報告範本或指南、用戶手冊範本、評審報告範本)88ISO9000體系3.“品質記錄”內容：對每個品質要素，在執行活動中，按照書寫品質記錄的範本格式書寫的文檔(如：用戶需求報告、設計說明書、測試報告、用戶手冊、各種評審與審計報告)891.10.2微軟企業文化

“平等、自由、親和、融洽、創新、激情、溝通和主人翁精神”的企業文化，是“以人為本”企業文化的具體表現，是微軟的精神管理模式。企業文化實質上是一種企業環境，而環境就是一種生產力。微軟的用人之道是“人品、智慧、團隊精神”三要素，以及“寧缺勿濫”和“不拘一格”的原則，它是微軟招聘、培養、考察、提升員工的標準。90軟體招聘人才例子

上世紀末，國內軟體公司人才跳槽現象普遍，軟體版權觀念淡薄，有這樣一個人到微軟公司去應聘，你們認為能成功嗎？這個人自稱，在原公司掌握了某軟體產品的核心技術，而且將原代碼也偷出來了，因此可為你公司創造很大經濟效益。911.10.3CMM/CMMI

CMM/CMMI的作用概括地講，軟體企業的過程能力成熟度模型CMM的作用，是軟體組織的能力評估和過程改進，它的應用領域具體表現在三個方面：

(1)軟體組織：用它來不斷改進自身的軟體過程管理能力；

(2)評估機構：用它來評估某軟體組織當前軟體能力成熟度的級別；

(3)客戶：用它來評價某承包商(軟體外包商)的軟體能力。92CMM/CMMI的實質

(1)以“過程”為核心抓軟體組織的管理，即軟體“組織”的過程改進。

(2)以“專案”為手段抓團隊開發過程的“活動”，即落實過程改進的措施。

(3)以“活動”記錄為基礎抓軟體過程的“度量”，即“度量”軟體組織改進的情況。通過以上三項措施，使軟體過程逐漸變為可視、可控，從而實現CMMI精神：品質源於過程、過程需要改進、改進需要模型、改進永無止境。93CMM/CMMI的實質“過程”，既包括軟體開發過程，又包括軟體管理過程。“組織”，是指軟體企業自己，或自己內部的一個軟體研發部門。“專案”，是指軟體企業的專案開發團隊。“活動”，包括專案的開發活動和專案的管理活動兩個方面。“度量”，是指對軟體測量資料庫中的專案管理記錄數據進行統計和分析。94CMM的級別CMM1級：初始級，無序管理。

CMM2級：可重複級，專案級管理。

CMM3級：已定義級，組織級管理。

CMM4級：已管理級，數據級管理。

CMM5級：優化級，優化級管理。95CMM/CMMI的內容(1)CMM的內容：五個級別、18個關鍵過程域(KPA)(2)CMMI的內容：階段式模型：五個級別、24個過程域(PA)

連續式模型：六個級別、24個過程域(PA)961.11軟體工程與資訊系統工程

利用電腦網絡技術、數字通信技術與資料庫技術實現資訊採集和處理的系統，稱為當代資訊系統。資訊系統由社會環境、網路環境、數據環境和程式環境這四個部分組成。97軟體工程與資訊系統工程

資訊標準化，就是資訊代碼化和規範化。

代碼化就是用數字或字元代碼來表示資訊，這種表示方式便於在資訊系統中交流。規範化就是代碼要遵守一套規定和標準，不能自行其事。981.12本章小結

本章介紹了軟體工程的定義、內容、作用，以及三種開發方法、五個面向理論。這些都是軟體工程的精華；本章既是研究軟體工程的出發點，又是研究軟體工程的歸宿。既是緒論，又是總結。由於軟體工程是一門實踐性很強的科學，所以要真正弄懂它，吃透它，一定要理論聯繫實際，學以致用。99資訊系統建設案例分析

港口綜合MIS系統包括如下子系統：（1）貨物運輸子系統（2）船舶調度子系統（3）設備管理子系統（4）物資管理子系統（5）客運管理子系統（6）外輪代理子系統（7）集裝箱子系統（8）人事勞資子系統港口資訊系統建設案例分析

成功的秘密歸納起來，有4點：（1）自始至終堅持採用“面向數據的方法”不動搖。即堅持面向數據分析、面向數據設計、面向數據實現、面向數據測試、面向數據維護。（2）自始至終堅持採用Oracle關係資料庫管理系統不動搖。客觀地說，建設大型資訊系統，Oracle資料庫具有穩定可靠的強大功能和優秀性能。港口資訊系統建設案例分析

（3）自始至終堅持採用CASE工具不動搖。這些工具包括設計工具PowerDesigner和實現工具Developer2000，它們都是面向數據的開發工具。（4）自始至終堅持港口資訊系統建設不動搖。要做行業ERP，就必須熟悉並精通該行業的業務流程和規則，長期堅持某一行業的方向不動搖，才能做該行業領域的業務專家，才能與時俱進地把握該行業領域的客戶需求。2024-2-71033.1可行性研究任務與步驟可行性研究與其他的研究不同，這個階段不是去開發一個軟體專案，也不是解決問題。而是研究這個軟體專案是否值得去開發，其中的關鍵和技術難點是什麼，問題能否得到解決，怎樣達到目的等。可行性研究的主要內容是對問題的定義，要初步確定問題的規模和目標，問題定義後，要導出系統的邏輯模型。然後從系統的邏輯模型出發，選擇若干供選擇的主要系統方案。2024-2-7104（1）技術可行性研究。根據客戶提出的系統功能、性能及實現系統的各項約束條件，從技術的角度研究實現系統的可行性。（2）經濟可行性研究。進行成本效益分析，評估專案的開發成本，估算開發成本是否會超過專案預期的全部利潤。分析系統開發對其他產品或利潤的影響。2024-2-7105（3）法律可行性研究。研究在系統開發過程中可能涉及的各種合同、侵權、責任以及各種與法律相抵觸的問題。（4）開發方案的選擇性研究。提出並評價實現系統的各種開發方案，從中選出一種用於軟體專案開發。2024-2-71063.1.1研究任務在進行專案可行性研究中，首先需要進行概要的分析研究，初步確定專案的規模和目標，確定專案的約束和限制，把它們清楚地列舉出來。要研究目前正在使用的系統。如果目前有一個系統正在使用，那麼這個系統一定能完成某些有用的工作。所以新系統的目標也必須能完成這些基本功能。如果現有的系統是完美的，那麼用戶就不會提出開發新系統。2024-2-7107一般來說，應該從以下四方面分析研究每種解決方法的可行性。1.技術可行性要確定使用現有的技術是否能夠實現系統，那麼就要對開發專案的功能、性能和限制條件進行分析，確定在現有的資源條件下，技術風險有多大，專案是否能實現，這些是技術可行性研究的內容。2024-2-7108數學建模、原型建造和模擬是基於電腦系統技術分析活動的有效工具，描述了技術分析建模過程的資訊流圖。系統分析員通過對現實世界的觀察和分析建立技術分析模型，評估模型的行為並將它們與現實世界對比，論證系統開發在技術上的可行性和優越性。2024-2-7109基於電腦系統模型必須具備下列特性：（1）能夠反映系統配置的動態特性，容易理解和操作，能夠提供系統真實的結果並有利於評審。（2）能夠綜合與系統有關的全部因素，能夠再現系統運行的結果。（3）能夠突出與系統有關的重要因素，能夠忽略與系統無關的或次要的因素。（4）結構簡單，容易實現，容易修改。2024-2-7110技術可行性一般要考慮的情況如下：（1）技術。 通過調查瞭解當前最先進的技術，分析相關技術的發展是否支持這個系統。（2）資源的有效性。 用於建立系統的硬體設備、軟體、開發環境等資源是否具備。特別是用於開發專案的人員在技術和時間上是否存在問題。2024-2-71112.經濟可行性電腦技術發展異常迅速的根本原因在於電腦的應用促進了社會經濟的發展，給社會帶來了巨大的經濟效益。因此，基於電腦系統的成本-效益分析是可行性研究的重要內容，它用於評估基於電腦系統的經濟合理性，給出系統開發的成本論證，並將估算的成本與預期的利潤進行對比。2024-2-7112經濟可行性問題包含兩方面：一方面是經濟實力；另一方面是經濟效益。分析經濟可行性研究的內容是要進行開發成本的估算，瞭解專案成功取得效益的評估，確定要開發的專案是否值得投資開發。2024-2-7113一般說來，基於電腦系統的成本由如下四部分組成：（1）購置並安裝軟硬體及有關設備的費用；（2）系統開發費用；（3）系統安裝、運行和維護費用；（4）人員培訓費用。2024-2-7114在系統分析和設計階段只能得到上述費用的預算，即估算成本。在系統一切完畢並交付用戶運行後，上述費用的統計結果就是實際成本。系統效益包括經濟效益和社會效益兩部分。經濟效益指應用系統為用戶增加的收入，它可以通過直接的或統計的方法估算；社會效益只能用定性的方法估算。2024-2-71153.社會可行性 社會可行性研究的內容包括：研究開發的專案是否存在任何侵犯、妨礙等責任問題。4.操作的可行性 要開發專案的運行方式在用戶組織內是否行得通，現有管理制度、人員素質和操作方式是否可行。2024-2-71163.1.2研究步驟1.系統定義系統定義是一個系統的關鍵，如果系統沒有定義好，也就是沒有確定系統的邊界。就談不上確定專案規模和目標。為了定義好一個系統，分析員對有關人員進行調查訪問，仔細閱讀和分析有關的材料，對專案的規模和目標進行定義和確認，描述專案的一切限制和約束，確保分析員正在解決的問題確實是要解決的問題。2024-2-71172.對於現行系統進行分析研究要認識到現行系統是資訊的重要來源。需要研究它的基本功能、性能、環境，存在的問題，運行現行系統需要多少費用，對新系統有什麼新的功能要求，新系統運行時能否減少使用費用等。具體方法可以實地考察現行系統，收集、研究和分析現行系統的文檔資料。2024-2-71183.導出新系統的邏輯模型根據對現行系統的分析研究，搞清了新舊系統的特徵，逐漸明確新系統的功能、處理流程以及所受的約束。有了這些理解後，就可以用建立邏輯模型的工具——數據流圖和數據字典來描述數據在系統中的流動和處理情況。2024-2-71194.設計方案分析員根據新系統的高層邏輯模型，從技術角度出發，根據用戶的要求和開發的技術力量，提出實現高層邏輯模型的不同方案。5.推薦可行的方案根據上述可行性研究的結果，同時要根據用戶的具體情況，應該決定該專案是否值得去開發。2024-2-71206.編寫可行性研究報告將上述可行性研究過程的結果按照：說明要求、目的、條件與限制、可行性研究方法及評價尺度；處理流程、工作負荷、費用開銷和局限性；說明處理流程、運行環境和局限性；技術條件的可行性；經濟方面的可行性；社會條件的可行性；其他可供選擇的系統；結論的順序寫成可行性研究報告，提請用戶和使用部門仔細審查，從而決定該專案是否進行開發，是否接受可行的實現方案。2024-2-71213.2系統分析如果確認開發一個新的軟體系統是必要而且可能的，那麼就要進入系統分析階段。這個時期的首要任務是認識和對問題的評價、建立模型和對規格的分析。系統分析員要研究系統規格說明（systemspecification）和軟體專案計畫（softwareprojectplan）。其次，為了確保對問題的識別，必須為分析建立通信關係。系統分析員的目標是弄清用戶已經理解的基本問題元素。2024-2-7122第二項任務是分析，是主要工作問題評價與解的綜合。系統分析員必須定義和詳細描述全部軟體功能，熟悉影響系統事件前後關係的軟體行為，建立系統介面的特徵，評價資訊流和資訊的內容，以及揭示設計限制。最後一項任務是需求分析文檔（規格說明和用戶手冊）。它是作為用戶和開發人員進行評審的基礎。2024-2-71233.2.1系統分析員系統分析員必須具備下列能力：（1）能掌握抽象概念（abstractconcepts），並能把其整理為邏輯劃分（logicaldivisions），以及根據每一個邏輯劃分綜合為解（solutions）的能力。（2）有弄清用戶環境的能力。（3）有從衝突（conflict）或混淆（confusions）中吸取恰當事實的能力。2024-2-7124（4）有用較好的書面和口頭形式進行通信（communication）的能力。（5）有把硬體和軟體系統用於用戶環境（user/customerenvironments）的能力。（6）“從樹木見森林”的能力。2024-2-7125系統分析員在軟體需求分析階段有五個方面的工作：（1）問題識別（problemrecognition）。（2）評價和綜合（evaluationandsynthesis）。（3）建模（modeling）。（4）規格說明（specification）。（5）評審（review）。2024-2-71263.2.2面臨的問題域在系統分析的過程中，都會遇到許多問題。問題識別與問題評價和解綜合，在很大程度上決定於能否獲得恰當的資訊。應當收集什麼資訊？應當怎樣對它們進行表示？誰能提供各種資訊的初始模型？以及採用什麼技術和工具才能方便地進行資訊收集？所有這些都是要解決的問題。2024-2-71273.2.3通信技術一個軟體開發的開始往往是用戶提出一個問題，並認為這個問題可能適合用電腦來解決，於是尋找開發者，這時開發者對用戶的請求回答是可以幫助的。這樣，開發者與用戶間的通信就開始了。2024-2-71281.過程的開始當用戶與開發者有了合作意向後，經常使用的分析技術是會議或訪問，將它作為用戶和開發人員之間的通信橋樑。系統分析員可以就此切入，瞭解用戶的現行運作，希望在那些地方用電腦來解決問題，提出用戶、總目標和效益方面問題，如：2024-2-7129（1）這項工作主要在哪些部門應用？（2）專案的結構主要是誰使用？（3）專案成功的應用帶來什麼樣的經濟效益？（4）為了達到目的，還需要其他什麼資源？2024-2-7130為了利於系統分析員對問題更好地理解，而用戶又能夠表達關於目標的理解。可以進一步瞭解：（1）如何表示一個成功的目標能產生一個好的輸出形式？（2）這樣的理解可以解決一些什麼樣的問題？（3）顯示或描述一下這樣的目標要使用的環境。（4）這種方式的解對特殊的性能問題或限制將有哪些影響？2024-2-7131通過初步瞭解後，系統分析員會發現一些更具體和技術上的問題。為了通信的有效性，要考慮的稱為元問題（meta-questions）。建議如下：（1）誰是能回答這些問題的人？（2）誰能貼切解決這些問題？（3）問題是否提得太多？（4）這裏還有其他人可以提供其他方面的資訊嗎？（5）還有什麼事情是我應該問的？2024-2-7132上述所有這些問題將有助於打開僵局和初步的通信，這種通信是成功分析的基礎。在交流的過程中最好不要用一問一答的會議形式。事實上，問答式會議應當只用於第一次會面，然後採用交換式會議的形式，綜合問題的各個元素協商和說明。2024-2-71332.深入瞭解向用戶索取有關業務源頭與結果的資料，通過對資料的分析，對於一些複雜的業務，要到現場去跟隨業務流程“跟單”，然後把理解的過程用合適的技術表示出來。2024-2-71343.方便的應用規範技術由於在思想上存在“你我”的問題，一些研究機構開發出一種面向組的方法，應用於分析和規格說明早期的需求收集，這種方法叫做方便的應用規範技術(FacilitatedApplicationSpecificationTechnique，簡稱FAST)。FAST促使用戶和開發人員組成一個聯合組一起去確定問題，提出解的各個元素，協商不同方法，並定義一個初步解的需求集。2024-2-7135FAST已廣泛地應用於資訊系統界。這種技術對於促進通信在所有類型的應用中具有潛力。現在，FAST有許多不同的方式，每種方式的使用都有不同的背景，但所有應用都必須遵循以下原則：（1）會議由上一級部門或請中立部門主持，開發人員和用戶雙方參加。（2）一位主持人（可以是用戶、開發商或局外人），是被指定控制會議的人。（3）確定準備和參加的原則。2024-2-7136（4）提出一個議事日程，這個議事日程是正規的，並包括所有重要觀點。但是要不拘禮節地鼓勵大家自由發表意見。（5）一張確定的日程（可以是工作單、可轉動的圖表、牆上張貼物或牆上印刷牌）。（6）目標就是確定問題，提出解的各種元素，協商不同方法，以及定義一個初步解的需求集，而且能在一個有助於目標完成的氣氛中進行。2024-2-71373.3分析原理所有的分析方法都與下述一組基本原理相聯系：（1）問題的資訊域必須能被表示和被理解。（2）應當開發描述系統資訊、功能和行為的模型。（3）問題必須能按一定形式進行分割，就是用一種層次（或分層）形式來揭示它們的細節。（4）分析過程應當從基本資訊開始，直到實現細節。2024-2-71383.3.1資訊域在電腦的應用領域中，所有的軟體應用都可以被統稱為數據處理（dataprocessing）。資訊處理也指處理代表資訊的數據並確定被處理數據的意義的過程，所以可以用資訊處理代替數據處理。資訊處理的對象是資訊，而資訊的定義是：一方面是物質狀態發生改變的一種表徵，通常指數據消息中所包含的意義；另一方面它是知識的一種元素，以任何形式聚合，能產生一完整的概念、條件或情況的數據。2024-2-7139資訊域是一資訊字或一組資訊中的特定部分，資訊域中的內容通常被作為一個整體來處理。它包括三種不同方面的數據和控制：資訊內容、資訊結構和資訊流。每個方面都由電腦程式處理。在需求分析的過程中，搜集與分析的主要對象是資訊域，為了完全地瞭解資訊域，對資訊的每一個方面都應該進行研究。2024-2-71401.資訊內容 知識的一種元素，描述了單個數據和控制項，這些項可以組成更大的資訊項。2.資訊結構 資訊結構描述了各種數據和控制項的內部組織。2024-2-71413.資訊流 資訊流描述了數據和控制沿系統流動變化的方式。2024-2-71423.3.2建立模型在軟體需求分析過程中，要完成將建立的系統的模型。模型主要說明系統必須做什麼，而不是表達怎樣做。在一般情況下，用圖形符號表示的方法來描述資訊、處理、系統行為，而其他特性則使用性質不同的和公認的圖符（icons）表示。2024-2-7143在需求分析中，模型的建立可以反映人們對事物的認識，起到很重要的作用：首先，這種模型可以輔助分析人員更好地瞭解系統的資訊、功能和行為，從而使分析更容易和更系統化。其次，模型是評審的焦點，是確定系統完整性（completeness）、一致性（consistence）和規格說明準確性（accuracy）的關鍵。最後，模型也是設計的基礎。模型能給設計人員提供一種軟體的基本運算式，這種運算式可以映射成為實現的正文。2024-2-71443.3.3分解在相關領域中，通常都會有涉及到多技術的複雜問題分析。把一個很大和複雜的問題作為一個整體很難被完全理解。因此，為了能夠較容易地理解這個問題，人們力圖把這樣的問題分解為若干部分。從本質上講，分解就是把一個問題劃分為幾個組成部分。在概念上，可以建立一種分層的功能或資訊運算式，然後按下述兩條分解出最主要的元素：（1）在分層中，按垂直方向逐層細化。（2）在分層中，按水準方向對功能進行分解。2024-2-7145對於文字處理軟體的需求，可以根據產品劃分的資訊、功能、行為等幾部分來分析。下圖給出了文字處理軟體功能部分的水準分解和垂直分解。2024-2-71463.4系統模型與模擬3.4.1系統模型系統分析員將系統功能和性能分解，定義若干個子系統及其介面之後，開始建立系統模型，為需求分析和設計階段的工作奠定基礎。輸入—處理—輸出（IPO）結構是系統建模的基礎，它將基於電腦的系統轉換成一個資訊變換模型。2024-2-71471.結構圖系統分析員用結構範本開發系統模型。它由用戶介面處理、輸入處理、處理和控制功能、輸出處理、維護和自測試五部分組成。結構範本能幫助分析人員按照系統工程和軟體工程的建模技術自頂向下、由粗到細地建立基於電腦系統的系統模型。2024-2-7148結構範本2024-2-7149結構流程的層次結構2024-2-7150其中，系統總體結構關係圖（ACD）位於系統模型圖的最頂層。ACD定義了系統的組成，定義了各子系統引用和生成的資訊，建立了系統與系統運行環境之間的資訊介面。系統分析員借助ACD的幫助定義各子系統的結構流圖（AFD）。2024-2-71512.系統結構規格說明為滿足後續工作的需要，系統分析員必須準確、詳細地說明系統結構、組成系統的各個子系統以及各子系統之間的資訊流和控制流。結構圖規格說明（ADS）描述子系統資訊以及子系統之間的控制流和資訊流資訊。系統範本說明書描述各子系統的功能、資訊處理的對象和結果以及與其他子系統的連接關係。系統結構字典定義系統結構圖中的每個資訊項。2024-2-71523.4.2系統建模和模擬一個系統一般採用交互方式實現系統與現實世界的資訊交流。系統通過硬體、軟體對現實世界的對象、事件和過程進行管理和控制。為了減少在真實環境中試驗的風險和代價，人們在系統分析和設計階段普遍採用系統建模和模擬技術。模型是現實系統的一種描述，是現實系統的抽象和簡化。模型必須反映現實系統的本質和實際；模型必須由現實系統的有關元素組成；模型必須反映這些元素之間的關係。2024-2-7153現實系統模型可分為物理模型和數學模型兩大類。物理模型由物理元素構成，故稱形象模型。數學模型由數學符號、邏輯符號、數字、圖表、圖形等組成，故稱抽象模型。2024-2-7154用於現實系統模擬的模型必須遵循科學的社會規律，必須反映現實系統的本質，必須具有一定的精度。在此基礎上，還應力求簡單，儘量刪除某些不必要的細節，如有可能儘量採用已有的模型，在實驗過程中不斷修改和完善模型，使之更能反映現實系統的本質和特徵。2024-2-7155系統建模與模擬的主要步驟是：（1）分析問題、確定模擬的目標。（2）建立模型。（3）運行模型並分析模型結果。（4）修改模型（如有必要）。（5）撰寫模擬文檔。2024-2-71563.5成本-效益分析成本-效益分析的目的是從經濟角度評價開發一個新的軟體專案是否可行。成本-效益分析首先是估算將要開發的系統的開發成本，然後與可能取得的效益進行比較和權衡。2024-2-71571.成本估計一個軟體開發的成本主要表現在人力消耗。由於這種消耗估計不是精確的科學計算，因此可以用幾種方法計算後相互驗證。首先可以用代碼行定量估算方法，把開發軟體中實現每一個功能所需要的源代碼行數與成本聯繫起來。其次可以用任務分解技術估算成本。2024-2-71582.貨幣的時間價值系統的經濟效益是使用新系統增加的收入和節約的運行費用。而經濟效益和運行費用在軟體生命週期中都存在，這就是說經濟效益與軟體的生命週期的長度有關。所以應該合理地估計軟體的壽命。2024-2-71593.投資回收期用投資回收期是衡量一個開發專案價值的常用方法。投資回收期就是累計收回的經濟效益等同於最初投資費用所需的時間。收回投資以後的經濟效益就是利潤。很明顯，投資回收期越短，獲得利潤就越快，則該專案就越值得開發。4.純收入純收入就是在整個生命週期之內的累計經濟效益與投資之差。2024-2-71603.6可行性研究的文檔規格說明書要按照如下原則進行：（1）從實現中抽出功能度。（2）用面向過程的系統規格說明語言。（3）規格說明要圍繞整個系統，軟體是其組成部分。（4）規格說明書是一個可以認知的模型。2024-2-7161（5）必須是局部化的和鬆散耦合的。（6）必須圍繞系統的操作環境。（7）必須是可以操作的。（8）允許系統的規格說明書的不完整和可擴充。2024-2-7162一個可行性研究報告的主要內容如下：（1）引言：說明編寫本文檔的目的，專案的名稱、背景，本文檔用到的專門術語和參考資料。（2）可行性研究前提：說明開發專案的功能、性能和基本要求，達到的目標，各種限制條件，可行性研究方法和決定可行性的主要因素。2024-2-7163（3）對現行系統的分析：說明現行系統的處理流程和數據流程、工作負荷、各項費用支出、所需各類專業技術人員和數量、所需各種設備，現行系統存在什麼問題。（4）所建議系統的技術可行性分析：對所建議系統的簡要說明，處理流程和數據流程，與現行系統比較的優越性，採用所建議系統對用戶的影響，對各種設備、現有軟體、開發環境和運行環境的影響，對經費支出的影響，對技術可行性的評價。2024-2-7164（5）所建議系統的經濟可行性分析：說明所建議系統的各種支出，各種效益，收益/投資比、投資回收週期。（6）社會因素可行性分析：說明法律因素對合同責任、侵犯專利權和侵犯版權等問題的分析，說明用戶使用可行性是否滿足用戶行政管理、工作制度和人員素質的要求。2024-2-7165（7）其他可供選擇方案：逐一說明其他可供選擇的方案，並說明未被推薦的理由。（8）結論意見：說明專案是否能開發，還需什麼條件才能開發，對專案目標有何變動等。2024-2-71663.7專案開發計畫3.7.1方案選擇系統分析任務完成後，系統分析員開始研究問題求解方案。由於系統開發成本又可劃分為研究成本、設計成本、設備成本、程式編碼成本、測試和評審成本、系統運行和維護成本、系統退役成本等，因此在開發系統所用總成本不變的情況下，由於系統開發各階段所用成本分配方案的不同，也會對系統的功能和性能產生相當大的影響。2024-2-71673.7.2制定專案開發計畫經過可行性研究後，就得到一個專案是否值得開發的結論。如果可行，則接下來應制定專案開發計畫。分析員應當進一步為推薦的系統編寫一份開發計畫。軟體專案開發計畫是軟體工程中的一種管理性文檔。主要是對開發的軟體專案的費用、時間、進度、人員組織、硬體設備的配置、軟體開發環境和運行環境的配置等進行說明和規劃，是專案管理人員對專案進行管理的依據，據此對專案的費用、進度和資源進行控制和管理。2024-2-7168專案開發計畫是一個管理性文檔，它的主要內容如下：（1）專案概述：說明專案的各項主要工作；說明軟體的功能、性能；為完成專案應具備的條件；用戶及合同承包者承擔的工作、完成期限及其他條件限制；應交付的程式名稱，所使用的語言及存儲形式；應依附的文檔。3.1立項方法

立項的具體表現形式，就是在市場調查研究的基礎上，分析立項的必要性(是否有市場前景)和可能性(是否有能力實現)，並具體列出系統的功能、性能、介面和運行環境等方面的需求，當前客戶群和潛在客戶群的情況，以及投入產出分析，然後再按照編寫參考指南書寫立項建議書，並對它進行評審，評審通過後才算正式立項。169立項案例分析【例3-1】2003年初冬，煙臺市某軟體公司的老總在西安出差，發現西安市的大中型餐廳基本上都有電子點菜系統，客人一點菜，資訊馬上出現在廚房大師傅眼前，大師傅馬上炒菜，小姐很快上菜。以後一打聽，這個點菜系統叫“餐飲系統”，是北京某軟體公司開發的。於是這位老總又飛到北京，不但拜訪“餐飲系統”的開發公司，而且到幾家餐飲大店去吃飯，親身體驗“餐飲系統”的使用情況。返回煙臺後，老總拍著腦袋決定馬上立項，快速開發本公司的“餐飲系統”。170立項案例分析

不到三個月，“餐飲系統”開發完畢，但是在後來的兩年中，該系統在煙臺市總共也只賣出兩套，投入與產出比是五比一。這是為什麼？就是因為煙臺是中等城市，不像北京、西安是大城市，“餐飲系統”的客戶群少得可憐。171立項方法

立項就是決策，IT企業的決策必須按照決策程式進行。沒有決策程式就要先制定決策程式，不能一個人拍腦袋定決策。

立項建議書的目的，就是在某種程度上代替開發合同或用戶需求報告，作為軟體策劃的基礎。172立項方法

立項建議書的編制者一般不是軟體開發人員，而是軟體公司的市場銷售人員，因為他們對市場行情及客戶需求熟悉，所以在此給出它的編寫參考指南，對市場銷售人員和軟體策劃人員都會有幫助。1733.2立項文檔

立項文檔就是《立項建議書》，文檔彙編中給出它的編寫參考指南。不要認為它太死板、太複雜，需要仔細閱讀其格式和內容，並不斷地問“為什麼？”。只有這樣，才能增長學問，使自己早日融入IT企業的軟體文化之中，使高校的軟體工程教育與IT企業的軟體文化平滑接軌。1743.3簽訂合同的方法與文檔【例3-2】西元2005年2月，珠海一家軟體公司(乙方)與珠海一家中藥網站公司(甲方)，簽訂了一個“中藥網站開發合同”。該合同中的有關條款規定：“軟體開發費用共計9萬元人民幣，開發工期總共為一個月，即2月至3月”。並且還規定：“乙方若不按期交付專案，每拖延一天，甲方扣除乙方的軟體開發總費用的1%”。請讀者分析一下，該合同有什麼問題？後來的事實證明，該合同至少造成了如下幾個問題：175簽訂合同的方法與文檔

開發工期太短，乙方肯定不能按時交付專案。開發費用太低，乙方肯定不能獲利。至於“每拖延一天，甲方扣除乙方的軟體開發總費用的1%”的約定，更是甲方懸在乙方頭上的一把曆箭。由此可見，正確而合理地簽訂軟體專案開發合同，對軟體企業是何等地重要！176簽訂合同的方法與文檔

任何有營業執照的軟體企業，都有自己的合同文本格式。合同的文檔有兩份，一份是主文件，即合同正文。另一份是合同附件，即技術性的檔，它的格式和內容，與立項建議書的主體部分基本相同。附件的內容應覆蓋系統的功能點列表、性能點列表、介面列表、資源需求列表、開發進度列表等。177合同正文的主要內容