精品課程《軟件工程》PPT課件-

1、軟件工程軟件工程第一章 概述使用規范說明圖表應用強調背景文本和線條陰影標題文本填充強調超鏈接已訪超鏈接標準配色單擊此處添加標題單擊添加目錄內容1單擊添加目錄內容2單擊添加目錄內容3單擊添加目錄內容4單擊添加目錄內容5單擊添加目錄內容6單擊添加目錄內容7一、軟件定義軟件程序文檔數據程序按事先設計的功能和性能要求執行的指令序列數據能使程序正常操作信息的數據結構文檔與程序開發、管理、維護和使用有關的圖文資料二、軟件的特點和分類軟件是一個邏輯實體，而不是具體的物理實體，因而具有抽象性軟件生產與硬件生產不同，沒有明顯的制造過程軟件不會用壞，但比較難維護軟件本身是復雜的，使人類能夠創造的最復雜的產物123

2、4軟件本身成本昂貴5軟件分類見表1.26三、軟件危機1、什么是軟件危機： 如何開發軟件，以滿足不斷增長，日趨復雜的需求；如何維護數量不斷膨脹的軟件產品。軟件開發成本和進度的估算常常不準確用戶對完成的軟件系統不滿意現象經常發生軟件產品的質量往往靠不住； Bug一大堆軟件常常是不可維護的軟件通常沒有適當的文檔資料2、軟件危機的表現軟件成本在計算機系統成本中所占的比例逐年上升軟件開發生產率提高的速度遠遠跟不上硬件的發展和人們需求的增長軟件本身特點：邏輯部件：管理和控制軟件開發過程相當困難，較難維護規模龐大：代碼長度不正比程序復雜程度軟件產品的質量往往靠不住； Bug一大堆軟件常常是不可維護的軟件通常

3、沒有適當的文檔資料軟件成本在計算機系統成本中所占的比例逐年上升軟件開發生產率提高的速度遠遠跟不上硬件的發展和人們需求的增長3、產生軟件危機的原因單擊此處添加標題文字內容文字內容文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加標題單擊此處添加標題段落一單擊添加內容文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字

4、內容單擊此處添加段落文字內容單擊此處添加標題單擊添加單擊添加單擊添加單擊添加單擊添加單擊添加內容文字單擊添加單擊添加內容文字單擊添加單擊添加內容文字單擊添加單擊添加內容文字單擊此處添加標題單擊此處添加標題文字內容文字內容文字內容雙擊添加標題文字單擊此處添加標題此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字1234567雙擊添加標題文字此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字雙

5、擊添加標題文字單擊此處添加標題單擊添加內容文字單擊此處添加標題單擊添加圖片標題文字單擊此處添加標題單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容文字內容文字內容文字內容單擊此處添加標題標題一標題二標題三 標題四內容一內容二內容三內容四內容五內容六內容七標示符號單擊此處添加標題單擊添加標題文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加標題此處添加標題單

6、擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊此處添加標題單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容雙擊添加標題文字單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容雙擊添加標題文字單擊此處添加標題內容標題單擊此處添加段落文字內容單擊此處添加段落文字內容單擊此處添加段落文字內容內容內容此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文字此處添加內容單擊添加段落文字單擊添加段落文

7、字The end謝謝 本次課程到此結束25軟件生存周期及模型第二章26一、軟件工程研究內容序號研究方面具體內容1軟件開發模型如：瀑布模型、增量模型、迭代模型2軟件開發方法如：面向過程方法、面向數據方法、面向對象方法3軟件支持過程如：CASE工具Rose、北大青鳥系統、PowerDesigner4軟件管理過程如：ISO9000、CMM、軟件企業文化271、軟件生存周期(Life cycle) 軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。 軟件生存周期通常包括可行性研究和項目開發計劃、需求分析、概要設計、詳細設計、編碼、測試、維護等活動（GB8567中規定）。28定義分析藍圖、圖表、庫存、采

8、購單等設計實現產品292、軟件生存周期模型概念模型是為了理解事物而對事物作出的一種抽象，它忽略了不必要的細節，是事物的一種抽象形式 。軟件生存周期模型是描述軟件開發過程中各種活動如何執行的模型。它確立了軟件開發和演繹中各階段的次序以及各階段活動的準則，確立開發過程所必須遵守的規定和限制等。目前有瀑布模型、增量模型、螺旋模型、噴泉模型、變換模型和基于知識的模型等。2022/7/19303、軟件工程的傳統途徑瀑布模型(Waterfall Model) 維 護開發定義DefinitionFeasibility StudyRequirements AnalysisProgram DesignCodin

9、g & Module TestingIntegration & System TestingDelivery & MaintenanceSystem Design31二、瀑布模型瀑布模型1970年由W.Royce提出瀑布模型是傳統軟件工程的基礎。瀑布模型的基本思想是將軟件生命周期劃分為若干明確定義的階段。每一階段活動具有嚴格性，要實施評審工作，以便及早發現錯誤，改正錯誤 ；以文檔形式驅動的，上一階段的結果作為本階段的輸入 ；軟件維護報告要求定義確認設計確認編碼確認測試確認維護確認測試報告源程序清單設計說明書需求說明書321、軟件定義時期基本任務：回答 要解決的問題是什么？該問題有行的通的解決辦

10、法嗎？若有解決問題的辦法，則需要多少費用、資源、時間？結束標準：提出關于問題性質、工程目標和規模的問題定義書面報告；提出可行性研究報告；若問題值得去解決，制定項目開發計劃。可行性研究和項目開發計劃需求分析基本任務：回答“為了解決這個問題，目標系統必須做什么”，確定目標系統的功能。結束標準：給出軟件需求說明書332、軟件開發時期系統設計概要設計基本任務：回答 “概括地說，應如何解決這個問題”。把確定的各項功能需求轉換成需要的體系結構。設計軟件的結構，確定程序由哪些模塊組成及模塊間的關系，同時設計該項目的應用系統的總體數據結構和數據庫結構。結束標準：給出概要設計文檔。詳細設計基本任務：回答 “應怎

11、樣具體地實現這個系統”。為每個模塊完成的功能進行具體描述，把功能描述轉變為精確的、結構化的過程描述。結束標準：設計出程序的詳細規格說明。342、軟件開發時期系統實現編碼基本任務：把每個模塊的控制結構轉換成計算機可接受的程序代碼。寫出的程序應是結構好，清晰易讀，并且與設計一致。結束標準：以某種程序設計語言表示的源程序清單。測試基本任務：通過各種類型的測試使軟件達到預定的要求。結束標準：軟件合格，能交付用戶使用。353、軟件維護時期基本任務：通過各種必要的維護活動使系統持久地滿足用戶需要。364、技術審查和管理復審 技術審查是從技術角度進行的審查，是保證軟件質量和降低軟件成本的重要措施。在每一階段

12、結束前進行，對于持續時間很長的開發階段，在階段中間還要根據需要進行多次正式的或非正式的技術審查。技術審查通常由技術專家組成的審查小組來承擔審查工作。審查過程包括：準備和閱讀被審文檔、開審查會、返工、復查。 管理復審的主要任務是在軟件生存周期的每個重要的里程碑，對工程項目的成本、實際花費的經費、投資回收的前景、項目的進度等經濟因素從管理角度進行審查。從管理角度對軟件開發工程進行復審，是對工程進行管理和控制的主要手段，對發現的問題可以及時采取措施加以解決，必要時甚至可以取消開發工程以避免更大的損失。37名詞解釋軟件工作產品在CMM中，它是軟件開發活動中的人工制品，如需求說明書、概要設計說明書、詳細

13、設計說明書、源程序、測試報告、用戶手冊，也包括軟件管理文檔，如軟件開發計劃、軟件質量保證計劃、各種評審報告、里程碑報告、變更申請表、不符合項跟蹤報告等。軟件產品在CMM中軟件產品是最終用戶使用的軟件。它是軟件工作產品的一部分。基線它是軟件工作產品。它是要經內部和外部評審過的，并且是下一階段工作的基礎，一根基線是一個里程碑或一個檢查點。檢查點它是由時間、計劃、事件驅動的檢查工作進度和質量的一個記號，一個檢查點不一定是基線或里程碑。里程碑它是一個記號，只需經過內部評審。它是一個檢查點，但不一定是基線。評審是對軟件工作產品質量的一次開會或匯簽活動。審計是復查評審活動程序的合法性，是否按程序與規范進行

14、。顧客客戶用戶客戶是顧客的一部分，顧客包括潛在的客戶。用戶是軟件產品的最終使用者，用戶是客戶的一部分。現有系統目標系統現有系統是用戶當前正在使用的系統（可能是手工系統）；目標系統是將要實現的系統。Capability Maturity Model forsoftware385、瀑布模型特點是一個理想化過程。會掩飾項目中真正的風險，當你太晚發現它們時已無濟于事。 過程逆轉性很差，因為上游的錯誤會在下游進行發散性傳播。所以逆轉會造成很大損失。缺乏靈活性;特別是無法解決軟件需求不明確或不準確的問題后期錯誤，修正代價高 。純瀑布模型的缺點是在項目開始的時候，在設計工作完成前和代碼寫出來前，很難充分描述

15、需求。瀑布模型最主要的問題是缺乏靈活性。必須在項目開始前說明全部需求。但這恰恰是非常困難的。6、瀑布模型適用場合當有一個穩定的產品定義和很容易被理解的技術解決方案時，純瀑布模型特別合適當你對一個定義得很好的版本進行維護或將一個產品移植到一個新的平臺上，瀑布模型也特別合適。純瀑布模型能夠降低管理費用，因為你可以預先完成所有計劃。對于那些容易理解但很復雜的項目，采用純瀑布模型比較合適，因為可以用順序方法處理問題。在質量需求高于成本需求和進度需求的時候，它尤為出色。當開發隊伍的技術力量比較弱或者缺乏經驗時，瀑布模型更為適合。39407、瀑布模型變種：V型模型該方法是對瀑布模型的修正，強調了驗證活動4

16、18、瀑布模型變種：生魚片模型把階段重疊起來的瀑布模型起源于日本硬件開發模型（富士通施樂）軟件概念需求分析架構設計詳細設計編碼和調試系統測試428、瀑布模型變種：生魚片模型傳統的瀑布模型強調階段之間最小的重疊，而生魚片模型強調大幅度的重疊，即在需求分析完成之前就可以進行架構設計和部分詳細設計純瀑布模型強調在任意兩個階段交接時，文檔從一個團隊交給另一個完全隔離的團隊，但是如果一個團隊完成各個階段任務時，可以沒有那么多文檔。問題：缺點是什么？生魚片模型因為階段重疊，因而里程碑不明確，很難有效地進行過程跟蹤和控制。439、瀑布模型變種：具有子項目的瀑布模型純瀑布模型的一個問題是必須完成全部的架構設計

17、后才能進行詳細設計，但是，整個系統中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為為子項目。問題：該模型有何問題？這種方法的主要風險是相關性無法預料。4410、瀑布模型變種：能夠降低風險的瀑布模型純瀑布模型要求在開始架構設計前，必須將用戶的所有需求都搞清楚，但是實際中是很困難的。可降低風險的瀑布模型是在頂端，即需求分析和架構設計階段引入螺旋以便降低風險。在該螺旋中，先開發一個用戶界面原型，采用系統情節串聯圖版（system storyboarding）引導用戶提出需求，記錄用戶與系統的交互操作方式，或者采用其它需求獲取方法。45演化模型需求的采集與細化客戶評價原型快速設計建造原型

18、加工原型產生樣品停止開始先開發一個“原型”軟件，完成部分主要功能，展示給用戶并征求意見，然后逐步完善，最終獲得滿意的軟件產品。46三、螺旋模型螺旋模型將瀑布模型與演化模型結合起來，并且加入兩種模型均忽略了的風險分析。螺旋模型沿著螺線旋轉，自內向外每旋轉一圈便開發出更完善的一個新版本。 制定計劃 確定軟件目標，選定實施方案，弄清項目開發的限制條件；風險分析 分析所選方案，考慮如何識別和消除風險；實施工程 實施軟件開發客戶評估 評價開發，提出修正建議。47三、螺旋模型螺旋模型是一種風險驅動的模型。螺旋模型需要有相當豐富的風險評估經驗和專門知識。2022/7/1948ReviewCommitment

19、PartitionRisk analy-sisPrototype 1Simulations, models, benchmarksRequirements plan, life-cycle planConcept of operationPrototype 2Risk analysisSoftware requirementsRequirements validationDevelop-ment planRisk analysisPrototype 3Software product designDesign validation and verificationIntegration and

20、 test planRisk analysisOperational prototypeDetailed designUnit testCodeIntegration and testAcceptance testImplementationPlan next phasesDevelop, verify next-level productDetermine objectives, alternatives, constrainsEvaluate alternatives, identify, resolve risksCumulative costProgress through steps

21、The spiral model49螺旋模型決定目標、方案和限制評價方案、識別風險、弱化風險開發、驗證、下一級產品計劃下一階段集成測試50四、增量模型123491011125678需求分析設計編碼測試第1塊第1次集成第2次集成第3次集成第N次集成第4次集成第1塊第1塊第1塊第1塊第N塊第4塊第3塊第2塊第2塊第2塊第2塊第3塊第3塊第4塊51四、增量模型遵循遞增方式進行軟件開發。開發一部分，向用戶展示一部分。增量模型是一種非整體開發的模型。適用條件：1）使用面向對象語言或第四代語言；2）需求可能發生變化，客戶接受分階段交付；3）分析設計人員對應用領域不熟悉，難以一步到位；4）項目風險高；52五

22、、原型模型-概念快速原型模型：先開發一個“原型”軟件，完成主要功能，展示給用戶并征求意見，然后逐步完善。探索型原型：用于需求分析階段；實驗型原型：用于設計階段；演化型原型：軟件開發全過程，及早向用戶提交一個原型系統。原型運用方式：拋棄策略和附加策略。53五、原型開發過程-開發步驟原型開發步驟:快速分析：分析人員與用戶配合，迅速確定系統的基本要求。要根據原型所要體現的特征，描述基本需求。關鍵是要注意分析描述內容的選取。構造原型：在軟件工具支持下盡快實現一個可運行的系統。運行原型：是發現問題、消除誤解、開發者與用戶充分協調的一個步驟。評價原型：評價原型的特性，糾正誤解與錯誤，增添新要求或提出要求變

23、動，提出全面的修改意見。修改：原型開發的循環。54五、原型模型的評價原型的優點：可及早為用戶提供有用的產品。可及早發現問題，隨時糾正錯誤。減少技術、應用風險，縮短開發時間，減少費用。促使用戶主動參與開發活動，促進各類人員的協調，減少誤解，適應需求的變化，能有效提高系統質量。原型存在的問題：缺乏豐富而強有力的軟件工具和開發環境。缺乏有效的管理機制，還未建立起自己的開發標準。對設計人員水平和開發環境要求較高。在多次重復改變原型的過程中，程序員會感到厭煩。系統的易變性對測試有一定影響，難于做到徹底測試，更新文檔較為困難。2022/7/1955五、原型模型-快速原型法快速原型法(Prototyping

24、)適用于用戶驅動的系統（即需求模糊或隨時間變化的系統）PrototypeFeedbackModification56快速原型模型需求分析需求說明設計說明源程序軟件產品設計編碼測試維護快速分析需求說明原型修改意見修改類型構造原型運行原型評價原型停止修改修改說明修改原型57六、噴泉模型主要用于采用面向對象技術的項目噴泉體現迭代和無間隙的特征軟件的某些部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分在分析、設計、實現等各項活動之間無明顯邊界58六、噴泉模型體現了迭代和無間隙的特性。系統某個部分常常重復工作多次，相關對象在每次迭代中隨之加入演進的軟件成分。無間隙是指在各項開發活動，即

25、分析、設計和編碼之間不存在明顯的邊界。噴泉模型是對象驅動的過程。 59需求階段分析階段設計階段編程階段集成與測試階段維護與演進階段60七、迭代模型（RUP模型）Rational Unified Process初始精化構建移交9個核心流程對初學者來說，使用比較困難61八、智能模型智能模型是基于知識的軟件開發模型，它把瀑布模型和專家系統綜合在一起。該模型在各個開發階段都利用了相應的專家系統來幫助軟件人員完成開發工作。為此，建立了各個階段的知識庫，將模型、相應領域知識和軟件工程知識分別存入數據庫。以軟件工程知識為基礎的生成規則構成的專家系統與包含應用領域知識規則的其他專家系統相結合，構成該應用領域的

26、開發系統。 62用戶要求需求分析概要設計詳細設計程序編碼測試維護支持需求 分析的專家系統支持軟件 設計的專家系統 支持測試的專家系統 支持維護的專家系統6364九、軟件生存周期模型的剪裁在一個成熟的IT企業或軟件組織內部，通常要根據各種軟件開發模型的特點，結合本單位的開發經驗和行業特點的具體實際，還需要定制適合本單位的“生存周期模型裁剪指南”，有針對性地對選定的軟件開發模型中定義的生存周期，進行適當剪裁，使它完全適合于本單位的需求。所謂裁剪，就是對原模型中定義的內容進行增、改、刪，去掉對本單位不適用的內容，同時進一步細化，從而構成了完全適合本單位的“軟件生存周期模型裁剪指南”。該指南在軟件組織

27、內部，專供高層經理和項目經理在軟件策劃中選取軟件開發模型時使用。 65在軟件開發過程中必須遵循的軟件工程原則有：抽象與自頂向下、逐層細化信息隱蔽和數據封裝模塊化局部化確定性一致性和標準化完備性和可驗證性 十、軟件工程原則66軟件工程的基本原理有：按軟件生存期分階段制定計劃并認真實施；堅持進行階段評審；堅持嚴格的產品控制；使用現代程序設計技術；明確責任，使得工作結果能夠得到清楚的審查；用人少而精；不斷改進開發過程。十一、軟件工程的基本原理67案例分析整定軟件采用了以原型模型為主的軟件開發模型。故障分析是電力系統中非常基本的運算，算法比較成熟，軟件用戶對此模塊的功能也較熟悉，需求變動相對較小，因而

28、本功能模塊可以采用瀑布模型。但由于我們已有故障分析程序，只需對該程序的接口、部分功能算法進行修改和調整，所以采用原型模型較為合適。軟件開發階段中重點關注需求分析階段，弄清楚已有程序與用戶需求間的差距。圖形建模在建模范圍方面基本明確，但在具體內容方面仍有不確定性，原因是用戶對此功能模塊的想法還不夠清晰，通常用“待基本的出來后再討論”來回答一些細節問題。此外，我們有以前其他項目的圖形建模軟件基礎，所以本模塊采用了演化型原型模型，采用附加策略。先在以前圖形建模的軟件基礎上去除一些不需要的內容和添加新的內容，向用戶提交初步的原型系統，然后再根據用戶的意見進行修改，在反復多次中才達成需求的徹底清晰，此時

29、本模塊軟件也可以基本開發完成。整定計算是專業性很強的內容，通常需要較多的整定人員工作經驗，而整定經驗的獲得往往無法一次完成，因此開發方需要經常與用戶交流溝通。此外，整定計算模塊用戶最關心的是軟件的可用性，即計算過程是否方便、透明，計算結果是否合理。因此，整定計算也采用了原型模型，以某種原理的保護為例反復設計與修改整定的流程，直到滿足用戶的可用性和實用性為止，其他原理的保護整定則以此為模板進行開發。 68總結掌握：軟件生存期各個階段的基本任務；軟件生存期模型。了解：軟件生存期的各種模型及特點。69第三講軟件要求定義70學習內容可行性研究項目開發計劃軟件需求分析71項目來源合同：為別人做；立項：為

30、自己做；失敗：無盈利賠錢聲譽影響官司失敗：盡賠錢公司倒閉東山再起難！學到的遠比失去的多！ 72可行性研究（ Feasibility Study） 可行性研究的目的就是用最小的代價在盡可能短的時間內確定該軟件項目是否能夠開發，是否值得開發，最后給決策者提供做與不做的依據。 可行性研究實質上是要進行一次簡化、壓縮了的需求分析和設計過程，要在較高層次上以抽象的方式進行需求分析和設計過程。73可行性研究的任務 首先需要進行概要的分析研究，初步確定項目的規模和目標，確定項目的約束和限制。 然后進行簡要的需求分析，抽象出該項目的邏輯結構，建立邏輯模型。 最后從邏輯模型出發，經過壓縮的設計，探索出若干種可供

31、選擇的主要解決辦法，對每種解決方法都要從以下三方面研究它的可行性。技術可行性經濟可行性社會可行性74技術可行性在現有資源條件下，項目能否實現，風險有多大（技術、資源是否成熟）。社會可行性是否存在侵權、軟件操作方式是否適合用戶所在組織、現有管理制度、人員素質是否可行？75經濟可行性（成本效益分析） 成本效益分析首先是估算將要開發的系統的開發成本，然后與可能取得的效益進行比較和權衡。效益分有形效益和無形效益。有形效益可以用貨幣的時間價值、投資回收期和純收入等指標進行度量；無形效益主要從性質上、心理上進行衡量，很難直接進行量的比較。貨幣的時間價值：通常用利率表示。 F=P(1+n i) 不計復利投資

32、回收期：就是使累計的經濟效益等于最初的投資費用所需的時間。純收入：就是在整個生存周期之內的累計經濟效益（折合成現在值）與投資之差。76提示不是解決問題，而是確定是否可解值得解所以不要花過多精力，占總成本的 5 10 %例：實踐性大作業 3 方面考慮：技術上- 23 學生, 7 周, 電腦, 開發經驗 ，決心，風險（影響其它課程）. 社會上- 產品有沒有人用 經濟上 - 預算, 盈利, .77可行性研究的具體步驟1、確定項目規模和目標，明確限制和約束。我們認為用戶要的 用戶要的2、研究老系統 解決老系統問題老系統功能新增功能注：注意了解與其它系統的接口。 新系統效益 老系統效益 78可行性研究的

33、具體步驟3、導出高層邏輯模型(conceptual design)抽象實現改進老系統模型新模型新系統應該告訴用戶“What”而不是“How”79系統流程圖（事務圖）高層邏輯模型80可行性研究的具體步驟 3、邏輯模型4、復查和重新定義 1、復查定義 注：此時合同未簽，應考慮成本，不宜反復太多次。5、導出和評價多種解法進度表經濟上合算技術上可行操作上可行技術上不可行用戶不可能操作不合算81可行性研究的具體步驟6、推薦行動方針Yes or No?NoYesWhy?Which one is the best?Why? (cost / benefit)8、審查、存檔7、編寫可行性報告（開發計劃） 任務分

34、解，確定負責人 大致進度規劃 財務預算 風險分析及對策粗略82文檔：可行性報告 參考GB856788中的可行性研究報告，進行適當裁剪。83項目開發計劃 是對開發項目的費用、時間、進度、人員組織、硬件設備的配置、軟件開發環境和運行環境的配置等進行說明和規劃。 是項目管理人員對項目進行管理的依據，據此對項目的費用、進度和資源進行控制和管理。工具：Project85注意事項標書 ：我國對軟件成本認識不足人月不能互換：需求的變更、人員的流動、環境的變化；困難：就是缺乏數據估計，導致估計不科學；估算項目復雜度（熟悉程度）、規模 86軟件需求分析：“做什么？” 需求分析的過程是開發人員與用戶共同協商，明確

35、系統的全部功能、性能以及運行規格，并且使用軟件開發人員和用戶都能理解的語言準確地表達出來，即完成需求規格說明的過程。87軟件需求重要性例子 “喂，是Jack嗎？我是人力資源部的Tom,我們在使用你編寫的職員系統時遇到一個問題，一個職員想把她的名字改成Sparkle Starlight,而系統不允許，你能幫幫忙嗎？”“她嫁給了一個姓Starlight的人嗎？”Jack問道。“不，她沒有結婚，而僅僅是要更改她的名字，”Tom回答，“就是這問題，好象我們只能在婚姻狀況改變時才能更改姓名。”“當然這樣，我從沒想到誰會莫名其妙地更改姓名，我也不記得你曾告訴我系統需要處理這樣的事情。”Jack說。 Tom

36、說：“我想你當然知道每個人只要愿意都可以隨時合法更改其姓名。但不管怎樣，你在本周五之前解決這問題，否則Sparkle不能支付她的帳單。”“這不是我的錯！我現在正忙著做一個新的系統，還要做一些別的需求變更請求。很抱歉，只能下周才能修改。”88故事帶給我們的啟示 影響：作為客戶，很惱火，因為軟件系統不能進行一項基本的操作。哪怕開發者給其解決了，也不會感謝他。作為開發者，也很煩人，迫使你增加了當前的工作，又要你優先處理。原因：由于收集、編寫、協商、修改需求過程的手續或方法失誤帶來的。這里是非正式信息的收集、未確定或不明確的功能、未發現或未經交流的假設、不完善的需求文檔，以及突發的需求變更過程所造成的

37、。解決辦法：重視需求分析，派經驗豐富的人員做，最大程度的減少類似情況發生。89定值整定原則1：按與相鄰接地距離保護配合整定；原則2：按相鄰零序電流保護配合整定；1231與2配；1與3配；方案1：原則相鄰線方案2：相鄰線原則90需求分析的特點老問題：問題的復雜性交流障礙（講究技巧和原則）不完備性和不一致性需求易變性（動態性）派經驗豐富的人去干！系統分析員91軟件需求的任務理解、分解、表達、評審whf:劃分系統所有1.問題識別：雙方確定問題的綜合需求。功能需求：系統必須做什么？ 性能需求：做得怎樣？例：response time , memory , back-up memory , 環境需求：運

38、行環境、軟硬件配置等。用戶界面需求可靠性、安全性、保密性、可移植性和可維護性等方面的需求。將來可能提出的要求共同理解！92軟件需求的任務2.分析與綜合:導出軟件的邏輯模型。對獲取的需求進行一致性的分析檢查，在分析、綜合中逐步細化軟件功能，劃分成各個子功能。也對數據域進行分解，分配到各個子功能上，并用圖文結合的形式，建立起新系統的邏輯模型。93軟件需求的任務3.編寫文檔：編寫需求說明書 編寫初步用戶使用手冊編寫確認測試計劃 修改完善項目開發計劃94需求文檔用戶需求報告需求規格說明書對外的，驗收依據對內的，設計依據是合同的產物是立項建議書的產物由用戶需求報告可產生需求規格說明書當前系統，目標系統目

39、標系統（數據字典，算法分析）95軟件需求的任務驗證需求的一致性驗證需求的完整性驗證需求的現實性驗證需求的有效性方法： 人工審查 開發原型系統探索型使用軟件工具 完整性、一致性基線4.技術審查和管理復審96需求分析的方法結構化分析方法：由數據流和數據字典構成，適于數據處理領域問題。但該方法的一個難點是確定數據流之間的變換，而且數據字典的規模也是一個問題，對數據結構的強調很少。功能分解法：系統功能子功能功能接口。過程抽象觀點，很難與軟件設計明確分離。基點放在功能上，不穩定，難以適用需求的變化。97需求分析的方法信息建模方法：從數據角度來對現實世界建模。基本工具是E-R圖，數據不封閉，每個實體和它的

40、屬性的處理需求不是組合在同一實體中，沒有繼承性和消息傳遞機制來支持模型。是面向對象分析的基礎。面向對象的分析：采用了實體、關系和屬性等信息模型分析中的概念，同時采用了封閉、類結構和繼承性等面向對象程序設計語言中的概念。98ER模型（Entity-Relationship Approach）實體：客觀世界中存在且可相互區分的事物。用矩形框代表。聯系：事物間是有聯系的。(1:1、1:N、M:N) 用連接相關實體的菱形框表示。屬性：實體或聯系所具有的性質。 用橢圓形或圓角矩形表示。教師學生課程教學學號職稱成績學分1NNM99注意事項在需求分析時要注意用戶對軟件開發的了解程度。避免造成兩種極端認識。

41、需求的變動或新增是一個極為普遍的問題，既然普遍，所以軟件開發人員不僅應該在心理上接受這種變動，還應該在需求分析時積極的發掘需求。需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應形成規范的需求文檔，經用戶確認。如果為寫文檔而寫文檔，不進行及時更新，甚至準備在軟件開發完成后再補文檔，這是絕對錯誤的觀點。 100可能錯誤沒有足夠用戶從參與（類型、數量）開發方與用戶溝通可能處于劣勢不要錦上添花，畫蛇添足不要寫的過于簡練，過于模糊；計劃需求的時間少了，導致需求不完整另外，要注意：需求在簽約前要與決策者溝通好；到競爭對手那兒找不足不要被過細的不成熟的細節影響記下不明確的需求，約定期限明確，否則易遺

42、漏101總結熟練掌握：軟件需求分析的任務及分析的方法 掌握：可行性研究的任務。了解：其余作一般了解。102作業一人組：交實驗三；二人組：交實驗三、實驗四三人組：交實驗一/二、實驗三、實驗四四人組：交實驗一/二、實驗三、實驗四、實驗五103104結構化方法105學習內容結構化方法概述結構化分析數據流圖數據字典加工邏輯的描述結構化設計106一.結構化方法概述 它包括結構化分析（Structured Analysis）、結構化設計（ Structured Design）和結構化程序設計（ Structured Programming）三部分組成。 結構化方法的基本指導思想是自頂向下，逐步求精，它的基

43、本原則是抽象與分解。107結構化方法特點成功率較高，發展較為成熟；簡單、易掌握，適應于瀑布模型；特別適合于數據處理領域中的應用，對規模大的項目，特別復雜的應用不太適應。難于解決軟件重用問題，難于適應需求的變化。108二、結構化分析策略：它根據軟件內部數據傳遞、變換的關系，自頂向下逐層分解描繪出滿足功能要求的軟件模型。 X1231.11.21.33.13.23.32.12.2頂層：整個系統逐層添加細節109結構化分析步驟建立當前系統的物理模型（系統流程圖，怎么做）抽象出當前系統的邏輯模型。（做什么）建立目標系統的邏輯模型。作進一步補充和優化。110描述工具數據流圖 ：描速系統的分解。數據詞典：定

44、義數據流圖中的數據和加工。描述加工邏輯的結構化語言、判定表、判定樹等工具：詳細描述數據流圖中不能被再分解的每一個基本加工的處理邏輯 。111數據流圖 數據流圖（Data flow Diagram，簡稱DFD）是表示系統邏輯模型的一種工具，以圖形的方式描繪數據在系統中的流動和處理過程。由于只反映系統必須完成的邏輯功能，所以是一種功能模型。112數據流圖基本圖形符號數據源點和終點：系統的外部實體。一般只出現在頂層圖中。為了避免在數據流圖上出現數據流的線條交叉，同一個外部實體允許在一張圖上出現多次。數據源/終點名稱源/終點名稱源/終點名稱或113數據流圖基本圖形符號加工 ：對數據進行處理。加工名一般

45、用一個動詞和一個作賓語的名詞所組成。編號加工名或編號加工名114數據流圖基本圖形符號數據流： 數據及其流向，通常由一組數據項組成。有時數據流很難用簡單而適當的詞表達，這時可用概括性的語句來表達，一般用名詞或名詞短語表示。數據流名問詢訂貨單顧客支票信息顧客顧客事務處理顧客事務處理顧客事務內容115數據流圖基本圖形符號數據存儲：信息的靜態存儲。它也允許在一張數據流圖上重復出現相同的數據存儲，以避免數據流的交叉。數據名稱或編號數據名稱F2 庫存記錄F2 庫存記錄116數據流圖的分層方法 描述一個復雜的系統，不可能一下子引進太多的細節。否則用一張數據流圖畫出所有的數據流和加工，則這張圖將是極其龐大而復

46、雜，因而難以繪制，也難以理解。所以必須用分層的方法將一個流程圖分解成幾個流程圖，來分別表示。117數據流圖的分層方法一套分層的數據流圖由頂圖、0層圖、中間層和底圖的數據流圖所組成。頂圖說明了系統的邊界，即系統的輸入和輸出的數據流，頂圖只有一個加工，標識被開發的系統。畫系統內部，一般將層號從0開始編號。0層圖分解頂層圖的系統為若干子系統。底圖由一些不必再分解的加工組成，這些加工稱為基本加工。在頂圖和底圖之間是中間層。稱上層圖為下層圖的“父”圖，下層圖稱為上層圖的“子”圖。118子圖P1bd子圖P2cabd父圖（0層圖）cde子圖P3eP1P3P2acP1 .3P1 .2P1 .1P2 .1P2

47、.2P2 .3P3 .3P3 .2P3 .1Pabe源點1終點源點2頂圖119繪制數據流圖的幾個問題合理地命名：數據流程圖中對每一個元素都要命名，恰當地命名有助于數據流程圖的理解與閱讀。命名原則：為了避免引起錯覺，為每個元素所取的名字要能反映該元素的整體性內容，而不只是它的部分內容。每個元素的名字都能有唯一地標識該元素。避免用空洞的名字，要具體的含義。如果發現難以為某個數據流或加工命名時，這往往是數據流圖分解不當的征兆，可重新分解。120繪制數據流圖的幾個問題編號的設置子圖的編號是父圖相應的加工的編號。子圖中加工編號由子圖號、小數點與局部號組成。121繪制數據流圖的幾個問題父圖與子圖的平衡子圖

48、是詳細地描述父圖中加工，因而子圖的輸入、輸出數據流應該同父圖中加工的輸入、輸出數據流相一致。訂貨單P提貨單P3P1P2提貨單數量客戶122繪制數據流圖的幾個問題局部數據存儲 局部數據存儲不是父圖中相應加工的外部接口，而只是本圖中某些加工之間的數據接口。在子圖中出現的數據存貯，可以不出現在父圖中，畫父圖時只需畫出處理邏輯之間的聯系，不必畫出各個處理邏輯內部的細節，有助于實現信息隱蔽。acP1 .3P1 .2P1 .1庫存記錄123繪制數據流圖的幾個問題加工的分解與分細的程度為提高數據流圖的易理解性，注意合理分解。分得太細，則使得層次太多；分得太快，則達不到分層的目的。從管理的層次結構原理來看，一

49、個領導人管理他的下屬一般不超過7人，故在分解一層時不宜超過7個加工。一個加工分解到基本加工為止。基本加工：能表達系統所有的邏輯功能和必要的數據輸入與輸出，這些功能與數據的描述能使用戶清楚地理解，并且還能使以后的系統設計人員看到每一個加工，有一個明確的概念，并據此能設計程序模塊實現這些加工。注意子加工的獨立性和勻稱性。124125126數據流圖實例以某企業的銷售管理系統為例，采用SA方法進行需求分析，建立功能模型。該企業銷售管理的描述如下：（1）接受顧客的訂單，檢驗訂單。若庫存有貨，則進行供貨處理，即修改庫存，給倉庫開備貨單，并將訂單留底；若庫存量不足，則將缺貨訂單登入缺貨記錄。（2）根據缺貨記

50、錄進行缺貨處理，將缺貨通知單發給采購部門，以便采購。（3）根據采購部門發來的進貨通知單處理進貨，即修改庫存，并從缺貨記錄中取出缺貨訂單進行供貨處理。（4）根據留底的訂單進行銷售統計，打印統計表給經理。 127數據流圖實例頂層圖1280層圖1291層圖圖1圖21301層圖圖3圖41311層圖圖5修改下面的經營處理系統顧客供應商訂貨單發貨單訂貨單發貨單頂層數據流程圖經營處理系統經理統計表顧客P1銷售P2采購供應商F1 配件庫存P3會計付款收據應付款通知收款通知到貨通知訂貨單訂貨單發貨單發貨單統計缺貨通知第0層數據流程圖經理統計表付款收據付款收據付款收據134數據流圖的優缺點總體概念強，每一層都明確

51、強調“干什么”，“需要什么”，“給出什么”。可以反映出數據的流向和處理過程。由于自頂向下分析，容易及早發現系統各部分的邏輯錯誤，也容易修正。容易與計算機處理相對照。不直觀，一般都要在作業流程分析的基礎上加以概括、抽象、修正來得到。如果沒有計算機系統幫助的話，人工繪制太麻煩，工作量較大。135與其它流程圖的差別與系統流程圖的區別系統流程圖中不僅有數據流，還有物質流、資金流。數據流程圖僅以數據流的形態來反映一個組織中整個管理業務的過程。與程序結構圖的區別程序結構圖反映模塊之間的控制關系，以及模塊之間的調用關系，而數據流圖則不反映控制關系、調用關系、控制流，只畫數據流。136與其它流程圖的差別與程序

52、流程圖的區別程序流程圖中的處理框之間有嚴格的時間上的順序，也就先執行哪個處理框，起始點以及終止點等。而數據流程圖只反映數據的流向、加工和必要的數據存儲，它不反映加工的先后的時間順序。數據字典Data Dictionary，簡稱DD數據字典是用來定義DFD中各個成分的具體含義的，它以一種準確的、無二義性的說明方式為系統的分析、設計及維護提供了有關元素的一致的定義和詳細的描述。它和數據流圖共同構成了系統的邏輯模型。 數據字典的內容數據流、數據存貯、數據項、基本加工。數據字典的符號符 號含義舉例及說明被定義為與X=a+b表示X由a和b組成。 | 或X=a|b表示X由a或b組成。重復X=a表示X由0個

53、或多個a組成。m n或 nm重復X=2a5或X a 52 表示X中最少出現2次a，最多出現5次a，5、2為重復次數的上下限。()可選X=(a)表示a可在X中出現，也可不出現。“”基本數據元素X=“a”,表示X是取值為字符a的數據元素。 連接符X=1 9，表示X可取1到9中任意一個值。139數據流條目 在一個數據流圖上，數據按數據流為單位傳輸。主要內容有：數據流名稱、別名及簡述。數據流的來源：可能是一個外部實體、處理邏輯、數據存貯。數據流的去處。（同上）數據流的組成：一個數據流可能包括若干個數據結構，若只有一個數據結構，就不需要專門定義。數據流的流通量：單位時間內的傳輸次數。140數據流條目舉例

54、數據流的名稱：銷售科發貨單別名：無簡述：工廠對顧客辦理的發貨單數據流來源：“銷售科”外部實體數據流去向：“核對發貨單”處理邏輯數據流組成：發貨單標識+顧客+配件流通量：50份/天141數據存儲條目 數據存儲是數據結構停留或保存的場所。主要內容：數據存儲的名稱、別名及其簡述。流入、流出的數據流：流入的數據流指出其來源，流出的數據流指出其去向。數據存儲的組成：指它所包含的數據項或數據結構。組織方式、查詢要求等。數據存儲條目舉例數據存儲名稱：銷售歷史別名：無簡述：公司從月初到目前為止所有配件的銷售量。流入的數據流：“顧客的發貨單”，來源是“產生發貨單”處理邏輯。流出的數據流：“銷售量”，去向是“產生

55、銷售報表”處理邏輯。數據存貯的組成：配件編號+日期+銷售量。組織方式：以配件編號為關鍵字建立索引。查詢要求：能立即查詢。143數據項條目 數據項也稱數據元素，是“不可再分”的數據單位，是數據的最小組成單位。主要內容有：數據項名稱、別名及簡述：給數據項取名時，按“顧名思義”的原則，反映該數據項的含義，易于他人理解、記憶。數據項的類型數據項的長度：指數據項所包含的字符或數字的位數。取值的范圍和取值的含義144數據項條目舉例數據項名稱：貨物編號別名：G_No，Goods_No簡述：本公司的所有貨物的編號。類型：字符串長度：10取值/含義：第一位：進口/國產24位：類別57位：規格810：品名編號加工

56、條目用來說明DFD中基本加工的處理邏輯的。加工名；編號；簡述：對處理邏輯的簡明描述，其目的是使人了解這個處理邏輯是做什么用的。激發條件；優先級；輸入、輸出；加工邏輯：描述該加工“做什么”，即實現加工的策略，而不是實現加工的細節，描述如何把輸入數據流變換為輸出數據流的加工規則。常用的描述方法：結構化語言、判定表及判定樹。146加工條目舉例加工名：確定能否供貨編號：1.2簡述：激發條件：接受到合格訂單時優先級：普通輸入：合格訂單輸出：可供貨訂單、缺貨訂單加工邏輯：根據庫存記錄IF 訂單項目的數量該項目庫存量的臨界值THEN 可供貨處理ELSE 此訂單缺貨，登記，待進貨后再處理ENDIF147加工邏

57、輯的描述結構化語言 結構化語言是在自然語言基礎上加了一些限定，使用有限的詞匯和語句來描述加工邏輯，其結構分內外二層。外層用來描述控制結構，采用順序、選擇、重復三種基本結構。內層一般采用祈使語句的自然語言短語。使用數據字典中的名詞和有限的自定義詞，動詞含義要具體。還可使用一些簡單的算術運算和邏輯運算符號。148結構化語言示例IF 顧客訂額1000IF 顧客信譽好訂單設“優先”標志ELSEIF 顧客是老顧客訂單設“優先”標志ELSE訂單設“正常”標志ENDIFENDIFELSE訂單設“正常”標志ENDIF加工邏輯的描述判定表條件定義條件取值的組合動作定義在各種取值的組合下應執行的動作判定表1234

58、5678條件顧客訂額1000顧客信譽好顧客是老顧客處理訂單設“優先”標志訂單設“正常”標志150判定表判定表能把什么條件下系統應做什么動作準確地表示出來，同時能發現需求的不完整性，如某些條件組合下缺少應采取的動作。也能發現冗余的動作，可將條件合并。但判定表不能描述循環的處理特性，循環處理還需結構化語言。YNYYNN兩條規則合并YN-151加工邏輯的描述判定樹 好-優先處理1000 顧客信譽 老顧客-優先處理顧客訂額 不好顧客是 新顧客-正常處理 C(p2)then E(p1) E(p2)因為C(p1+p2) C(p1)+ C(p2)，所以 E(p1+p2) E(p1)+ E(p2).定義有效的

59、模塊系統的能力：模塊可分解性模塊可組裝性模塊可理解性模塊連續性模塊保護性2、抽象分解：對于一個復雜的系統，為了將復雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決。 抽象：分解可以分層進行，即先考慮問題最本質的屬性，暫把細節略去，以后再逐層添加細節，直至涉及到最詳細的內容，這種用最本質的屬性表示一個子系統的方法就是“抽象”。3、逐步求精求精：是細化過程，對高抽象級功能陳述說明具體實現細節。 求精可以幫助程序員對復雜問題的思考，是一種自頂向下的設計策略。4、信息隱藏 應該這樣設計和確定模塊，使得一個模塊內部包含的信息（過程和數據等實現細節）對于不需要這些信息的模塊來說，不能訪

60、問。5、 軟件獨立性準則 軟件獨立性的含義是指開發具有功能專一，模塊之間無過多相互作用的模塊。又稱為模塊獨立性準則。 這種類型的模塊可以并行開發，開發容易，能減少錯誤的影響，使模塊容易組合、修改及測試。 軟件獨立性的度量標準是兩個定性指標： 耦合性 用于描述模塊之間聯系的緊密程度。內聚性 用于描述模塊內部聯系的緊密程度。耦合分類：數據耦合：模塊間有且僅有數據交換控制耦合：模塊間有控制信息交換公共耦合：多個模塊通過一個公共環境相互作用。復合耦合：兩個模塊既往公共環境送變量又從公共變量里面取數據內容耦合：一個模塊訪問另一個模塊內的全部數據。內聚性(cohesion)偶然型邏輯型瞬時型通訊型順序型弱