軟件工程實踐課件VIP

軟體工程原理電腦系統(tǒng)工程概念系統(tǒng)分析和定義硬件軟件系統(tǒng)（總體）設計硬體工程軟體工程電腦軟體電腦軟體定義（GB）：

a.與電腦系統(tǒng)的操作有關的電腦程式、規(guī)程、規(guī)則，以及可能有的檔、文檔及數(shù)據(jù)。

b.與電腦系統(tǒng)的操作有關的程式、規(guī)程、規(guī)則及任何與之有關的文檔。什麼是軟體？軟體是電腦系統(tǒng)中與硬體相互依存的另一部分，它是包括程式，數(shù)據(jù)及其相關文檔的完整集合。程式是按事先設計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程式能正常操縱資訊的數(shù)據(jù)結構文檔是與程式開發(fā)，維護和使用有關的圖文材料軟體的特點軟體是一種邏輯實體，而不是具體的物理實體。因而具有抽象性軟體的生產與硬體不同，在它的開發(fā)過程中沒有明顯的製造過程在軟體的運行和使用期間，沒有硬體那樣的機械磨損，老化問題軟體的開發(fā)和運行常受到電腦系統(tǒng)的限制，對電腦系統(tǒng)有著不同程度的依賴性軟體的開發(fā)至今尚未完全擺脫手工藝的開發(fā)方式軟體本身是複雜的實際問題的複雜性程式邏輯結構的複雜性軟體成本相當昂貴相當多的軟體工作涉及到社會因素軟體的分類—按功能進行劃分系統(tǒng)軟體操作系統(tǒng)資料庫管理系統(tǒng)設備驅動程式通信處理程式等支撐軟體文本編輯程式檔格式化程式磁片向磁帶向數(shù)據(jù)傳輸?shù)某淌匠淌綆煜到y(tǒng)支持需求分析、設計、實現(xiàn)、測試和管理的軟體

應用軟體商業(yè)數(shù)據(jù)處理軟體工程與科學計算軟體電腦輔助設計／製造軟體系統(tǒng)仿真軟體智能產品嵌入軟體醫(yī)療、制藥軟體事務管理、辦公自動化軟體電腦輔助教學軟體軟體的分類—按規(guī)模進行劃分類別參加人員數(shù)研製期限根源程式行數(shù)

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M

軟體的分類按工作方式劃分：即時處理軟體分時軟體互動式軟體批處理軟體按服務對象的範圍劃分：專案軟體產品軟體按使用的頻度進行劃分：一次使用頻繁使用按軟體失效的影響進行劃分：高可靠性軟體一般可靠性軟體軟體發(fā)展階段程式設計階段—50至60年代程式系統(tǒng)階段—60至70年代軟體工程階段—70年代以後軟體危機...電腦硬體性能／價格比和品質穩(wěn)步提高軟體成本逐年上升，品質沒有可靠的保證軟體已成為限制電腦系統(tǒng)發(fā)展的關健因素將軟體開發(fā)和維護過程中遇到的一系列嚴重問題統(tǒng)稱為“軟體危機”在６０年代後期開始認真研究解決軟體危機的方法，逐步形成了新興的電腦軟體工程學...軟體危機什麼是軟體危機？軟體危機是指在電腦軟體的開發(fā)和維護中所遇到的一系列嚴重問題。幾乎所有軟體都不同程度地存在這些問題概括地說軟體危機包含兩方面問題：如何開發(fā)軟體，怎樣滿足對軟體的日益增長的需求如何維護數(shù)量不斷膨脹的已有軟體軟體危機主要表現(xiàn)１．對軟體開發(fā)成本和進度的估計很不準確２．用戶對“已完成的”軟體不滿意的現(xiàn)象經常發(fā)生３．軟體產品的品質靠不住４．軟體不可維護５．軟體沒有適當?shù)奈臋n資料６．軟體成本占電腦系統(tǒng)總成本的比例逐年上升７．軟體開發(fā)生產率提高的速度遠遠跟不上電腦應用迅速普及深入的趨勢產生軟體危機的原因一方面與軟體本身的特點有關在軟體運行前，軟體開發(fā)過程的進展難衡量，品質難評價，因此管理和控制軟體開發(fā)過程相當困難；在軟體運行中，軟體維護意味著改正或修改原來的設計，較難維護；軟體的顯著特點是規(guī)模龐大，複雜度超線性增長。要保證高質量大型軟體的開發(fā)，極端複雜困難，不僅涉及技術問題（如分析方法、設計方法、版本控制），更重要的是必須有嚴格而科學的管理。另一方面與軟體開發(fā)和維護方法不正確有關，這是主要原因。特別是忽視軟體需求分析的重要性忽視軟體需求分析的重要性對用戶要求沒有完整準確的認識就匆忙著手編寫程式軟體開發(fā)與編程等同忽略文檔軟體定義不明輕視維護對軟體開發(fā)的錯誤認識（1）已經有了關於建造軟體的標準和規(guī)程使用了嗎？開發(fā)者知道嗎？適用嗎？完整嗎？已經有了很好的軟體開發(fā)工具還需要電腦輔助軟體工程（CASE）工具對軟體開發(fā)的錯誤認識（2）如果計畫落後，可以增加人員趕回來給一個已經延遲的軟體專案增加人手只會使其更加延遲原有人員需要抽實踐訓練新手有了目標的一般描述就可以開始寫程式不完善的系統(tǒng)定義是專案失敗的主要原因對軟體開發(fā)的錯誤認識（3）專案需求不斷變化，但軟體很靈活，變化能夠很容易地得到滿足軟體需求的變化確實是經常的，但其產生的影響隨著引入的時間不同而不同寫出程式並使其正常運行，工作就結束了越早開始寫程式，就要花越長時間才能夠完成對軟體開發(fā)的錯誤認識（4）在程式真正開始運行前，無法評估其品質正式的技術評審品質篩檢程式成功專案唯一應該提交的就是運行程式軟體=程式+文檔+數(shù)據(jù)文檔是成功開發(fā)的基礎文檔為維護提供指導解決辦法...全面解決軟體危機需要一系列綜合措施：在軟體研製的各個階段採用好的工具；對軟體的實現(xiàn)提供有效的構件塊；為保證軟體品質提供自動設計技術；以及為協(xié)調、控制、管理提供基本理論和技術——軟體工程。...解決辦法軟體工程這一要素將駕馭前面的工具、構件決和技術軟體工程把管理、控制、評審等方法與分析、設計、編碼、測試、維護等技術結合起來沒有堅實的軟體開發(fā)方法學，即使最先進的工具和技術也不能使軟體危機有所減輕軟體工程—工程化方法用於解決任何產品開發(fā)的一種工程化方法是：要求在定義、開發(fā)和維護階段的每一步中都採用經過驗證的方法要求一系列的復查，以便在產品開發(fā)中保證品質規(guī)定在每一步中要產生的特定的文檔鼓勵能夠加速開發(fā)的各種工具和方法的使用與研製提供從原始產品概念到最後產品製造的一個可追溯的途徑軟體工程是使電腦軟體走向工程科學的途徑軟體工程—軟體工程定義軟體工程是為了經濟地獲得可靠的和能在實際機器上高效運行的軟體而建立和使用的好的工程原則。（FritzBauer1969)軟體工程是應用於電腦軟體的定義、開發(fā)和維護的一整套方法、工具、文檔、實踐標準和工序。（GB）軟體工程：（1）將系統(tǒng)化的、規(guī)範的、可度量的方法應用於軟體的開發(fā)、運行和維護的過程，即將工程化應用於軟體中。（2）（1）中所述方法的研究。（IEEE93）軟體工程是模仿在硬體研製中行之有效的一套計畫、管理、技術、方法，基於軟體的生存期概念而建立起來的。軟體工程的定義Boehm：運用現(xiàn)代科學技術知識來設計並構造電腦程式及為開發(fā)、運行和維護這些程式所必需的相關檔資料FritzBauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法軟體工程三要素：方法、工具和過程軟體工程方法為軟體開發(fā)提供了“如何做”的技術軟體工具為軟體工程方法提供了自動的或半自動的軟體支撐環(huán)境軟體工程—視圖1...品質焦點過程方法工具...軟體工程—視圖1品質焦點：任何工程方法必須以有組織的品質保證為基礎。品質的理念刺激不斷過程改進，導致出現(xiàn)更加成熟的軟體工程方法。它是軟體工程的根基。過程：軟體工程的基礎是過程。軟體工程過程是將技術層結合在一起的凝聚力，使得軟體能夠合理地和及時地開發(fā)出來。方法：軟體工程方法層提供了建造軟體在技術上需要“怎麼做”。工具：在工具層對過程和方法提供了自動和半自動的支持。軟體工程—生存期概念電腦軟體生存期中有三個階段：定義階段、開發(fā)階段、維護階段。定義階段：為軟體專案做出計畫、預算資金和進度，分析並規(guī)定詳細的需求——做什麼開發(fā)階段：用經過驗證的各種設計、編碼和測試方法把軟體需求轉變?yōu)橐粋€可執(zhí)行的程式——怎麼做維護階段：糾正所遇到的各種問題，修正軟體使之適合於不同的工作環(huán)境，增強功能要求——改變每一個階段都有一系列的工程步驟，每一步都以能加以復查並可移交才作為結束軟體工程知識結構2001年5月ISO/IECJTC1（ISO和IEC的第一聯(lián)合技術委員會）發(fā)佈了《SWEBOK指南V0.95(試用版)》（GuidetotheSoftwareEngineeringBodyofKnowledge,簡稱SWEBOK）SWEBOK把軟體工程學科的主體知識分為10個知識領域。軟體工程知識結構

軟體需求軟體設計軟體構造軟體測試軟體維護軟體配置管理軟體工程管理軟體工程過程軟體工程工具和方法軟體品質軟體工程的基本原理B.W.Boehm（1983）1)用分階段的生命週期計畫嚴格管理;2)堅持進行階段評審;3)實行嚴格的產品控制;4)採用現(xiàn)代程式設計技術;5)結果應能清楚地審查;6)開發(fā)小組的人員應該少而精;7)承認不斷改進軟體工程實踐的必要性。計畫管理缺乏科學而周密的計畫是軟體開發(fā)普遍現(xiàn)象不成功軟體專案一半以上由於計畫不周造成應把軟體生存期劃分為若干階段，制定科學周密、切實可行的計畫，並嚴格按計畫進行管理，這是軟體專案取得成功的先決條件計畫所做的和按計畫去做計畫一般包括：專案開發(fā)計畫、軟體配置管理計畫、軟體品質保證計畫、軟體測試計畫等評審在每個階段都進行嚴格的評審，以便儘早發(fā)現(xiàn)在軟體開發(fā)過程中所犯的錯誤，是一條必須遵循的重要原則品質保證工作不能等到程式編制完成後才進行：1.程式中的大部分錯誤是在編碼之前造成的2.錯誤的檢測與改正時間越晚，所付出的代價也就越高。3.錯誤還會被“放大”配置管理...軟體研製各階段產生的文檔、報告、程式清單和數(shù)據(jù)等，構成軟體配置全部軟體配置是一個軟體產品的真正代表，必須使其保持精確和一致為了保持軟體配置的一致性，必須實行嚴格的產品控制，對變更進行嚴格的控制和管理...配置管理配置管理是標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存週期內控制這些項的投放和變更，記錄並報告配置的狀態(tài)和變更要求，驗證配置項的完整性和正確性。它包括對軟體配置的標識、控制、審計、記錄等一系列的活動在軟體研製過程中，由業(yè)已經過正式審核與同意，可用作下一步開發(fā)的基礎，並且只有通過正式的修改管理步驟方能加以修改的規(guī)格說明或產品形成了配置管理的基線軟體開發(fā)方法和工具軟體工程鼓勵研製和採用各種先進的軟體開發(fā)方法和工具各種軟體開發(fā)方法的出現(xiàn)和採用大大改善了軟體的開發(fā)效率和維護效率軟體工程輔助工具、電腦輔助軟體工程（ＣＡＳＥ）環(huán)境工具和環(huán)境的使用進一步提高了軟體的開發(fā)效率、維護效率和軟體品質文檔...軟體研製是腦力勞動，具有不可見性為了實現(xiàn)對軟體研製過程的管理，在軟體研製的每個階段，都應按規(guī)定的格式編寫出完整準確的文檔文檔是軟體中不可缺少的組成部分...文檔的作用1)作為階段工作成果和結束標誌；2)向管理人員提供軟體開發(fā)過程中的進展和情況，把軟體開發(fā)過程中的一些“不可見的”事物轉換成“可見的”文字資料；3)記錄開發(fā)過程中的技術資訊，便於協(xié)調以後的軟體開發(fā)、使用和修改；4)提供對軟體的有關運行、維護和培訓的資訊，便於各類人員之間相互瞭解彼此的工作；5)向潛在用戶報告軟體的功能和性能，使他們能判定該軟體能否服務於自己的需要。開發(fā)小組軟體開發(fā)小組的組成人員的素質應該好，而人數(shù)則不宜過多開發(fā)小組人員的素質和數(shù)量是影響軟體產品品質和開發(fā)效率的重要因素隨著開發(fā)人員數(shù)目的增加，因為交流情況討論問題造成的通信開銷也急劇增加組成少而精的開發(fā)小組是一條基本原理不斷改進僅有前面六條基本原理並不能保證軟體開發(fā)和維護的過程能趕上時代前進的步伐、跟上技術的不斷進步Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條基本原理不僅要積極地採納新的軟體技術，而且要注意不斷總結經驗軟體工程基本原則-1抽象採用分層次抽象，自頂向下、逐層細化的辦法控制軟體開發(fā)過程的複雜性。資訊隱蔽將模組設計成“黑箱”，實現(xiàn)的細節(jié)隱藏在模組內部，不讓模組的使用者直接訪問。這就是資訊封裝，使用與實現(xiàn)分離的原則。模組化如C語言程式中的函數(shù)過程，C++語言程式中的類。模組化有助於資訊隱蔽和抽象，有助於表示複雜的系統(tǒng)。局部化要求在一個物理模組內集中邏輯上相互關聯(lián)的電腦資源，保證模組之間具有鬆散的耦合，模組內部具有較強的內聚。這有助於控制解的複雜性。軟體工程基本原則-2確定性

軟體開發(fā)過程中所有概念的表達應是確定的、無歧義性的、規(guī)範的。一致性整個軟體系統(tǒng)的各個模組應使用一致的概念、符號和術語。程式內部介面應保持一致。軟體和硬體、操作系統(tǒng)的介面應保持一致。系統(tǒng)規(guī)格說明與系統(tǒng)行為應保持一致。用於形式化規(guī)格說明的公理系統(tǒng)應保持一致。完備性軟體系統(tǒng)不丟失任何重要成分，可以完全實現(xiàn)系統(tǒng)所要求功能的程度。為了保證系統(tǒng)的完備性，在軟體開發(fā)和運行過程中需要嚴格的技術評審?？沈炞C性開發(fā)大型的軟體系統(tǒng)需要對系統(tǒng)自頂向下、逐層分解。系統(tǒng)分解應遵循系統(tǒng)易於檢查、測試、評審的原則，以確保系統(tǒng)的正確性。軟體研製過程模型軟體生存週期從產品的設想到不再使用，包含軟體開發(fā)、運行、維護全過程軟體開發(fā)包含一系列階段、活動和里程碑，如需求分析、設計、編碼、測試軟體研製過程模型給出了將這些基本階段進行有機組合的結構性模型生存週期支持過程2配置管理1文檔編制8問題解決3品質保證4驗證5確認6聯(lián)合評審7審核生存週期基本過程2供應1獲取3開發(fā)4運作5維護生存週期組織過程1管理3改進2基礎設施4培訓瀑布模型軟體測試詳細設計軟體實現(xiàn)系統(tǒng)需求軟體需求概要設計1970年由W.Royce提出瀑布模型描述從60年代開始，為解決軟體危機逐漸發(fā)展起軟體工程。瀑布模型則是傳統(tǒng)軟體工程的基礎。瀑布模型的基本思想是將軟體生命週期劃分為若干明確定義的階段。需求捕獲是軟體生命週期的第一個階段；上一個階段生成規(guī)定的軟體中間產品（軟體文檔，偽碼等），傳到下一階段作進一步加工，最後得到目標產品。瀑布模型是一個理想化過程，瀑布模型特點(1)階段間具有順序性和依賴性(2)推遲實現(xiàn)的觀點(3)品質保證的觀點瀑布模型的使用風險和適用情況使用風險需求未被充分理解系統(tǒng)太大而不能一次實現(xiàn)事先打算採用的技術迅速發(fā)生變化需求迅速發(fā)生變化有限的資源無法利用某一中間產品適用情況所有的系統(tǒng)功能一次交付時必須同時淘汰全部老系統(tǒng)時瀑布模型V模型系統(tǒng)需求軟體需求概要設計詳細設計單元測試組裝測試編碼確認測試系統(tǒng)聯(lián)試詳細設計概要設計軟體需求系統(tǒng)需求型號任務編譯後的單元測試後的單元組裝後的軟體測試後的軟體交付軟體驗證驗證驗證驗證驗證驗證驗證與確認驗證與確認

J.McDermid於1994年在“軟體工程師參考手冊”中提出增量模型軟體1：運行維護詳細設計編碼測試系統(tǒng)需求軟體需求概要設計軟體2：運行維護詳細設計編碼測試增量模型描述預先計畫的產品改進從一套給定的需求開始，通過一系列的造型實施開發(fā)，第一個造型納入一部分需求，下一個造型納入更多的需求，以此類推，直到系統(tǒng)完成在每個造型中實行必要的過程、活動和任務增量模型特點在開發(fā)每個造型時，開發(fā)過程中的活動和任務順序地或部分平行重疊地使用當相繼的造型在部分併發(fā)地被開發(fā)時，開發(fā)過程中的活動和任務可以在造型間平行地被採用增量模型的使用風險和適用情況風險需求未被很好地理解突然提出一些功能事先打算採用的技術迅速發(fā)生變化需求迅速發(fā)身變化長時期內有限的資源投入適用情況需要早期獲得功能中間產品可以提供使用系統(tǒng)被自然地劃分成增量工作人員和（或）資金可以逐步增加漸進模型開發(fā)1運行維護1開發(fā)3運行維護3開發(fā)2運行維護2漸進模型描述和特點通過造型開發(fā)系統(tǒng)需求不能被完全理解，且不能在初始時就確定需求一部分被預先定義，然後在每個相繼的造型中逐步完善每個造型被開發(fā)時，開發(fā)過程中的活動和任務順序地或部分重疊並行地被採用對所有造型，開發(fā)過程中的活動和任務通常按同意順序被重複使用採用漸進模型的一些原因1）需要某些用戶經驗來改進和完善需求；2）某些部分的實現(xiàn)可能取決於未來技術的可用性；3）某些新的用戶需求被預料到，但目前還不清楚；4）某些需求可能比遇到的那些還難以滿足，並且確定不允許因這些需求推遲可用的交付。漸進模型的使用風險和適用情況風險突然提出一些功能長時期內有限的資源投入適用情況需要早期獲得功能中間產品可以提供使用系統(tǒng)被自然地劃分成增量工作人員和（或）資金可以逐步增加需要用戶回饋來理解全部需求便於對技術變化的監(jiān)督原型開發(fā)模型需求分析快速設計用戶評價原型建立原型生產產品修改原型原型分類拋棄式原型開發(fā)樣品式原型開發(fā)漸增式原型開發(fā)螺旋模型B.Boehm於1988年提出螺旋模型描述瀑布模型和漸進模型相結合，增加風險分析用來指導大型軟體專案的開發(fā)將開發(fā)劃分為制定計畫、風險分析、實施工程、客戶評估四類活動沿螺旋線每轉一圈，表示開發(fā)出一個更完善的新的軟體版本噴泉模型噴泉模型描述1990年B.H.Sollers和J.M.Edwards提出主要用於採用面向對象技術的專案噴泉體現(xiàn)迭代和無間隙的特徵軟體的某些部分常常被重複工作多次，相關對象在每次迭代中隨之加入漸進的軟體成分在分析、設計、實現(xiàn)等各項活動之間無明顯邊界RUP模型軟體過程模型的選擇1）模型應符合軟體本身的性質（規(guī)模、複雜性）2）模型應滿足軟體應用系統(tǒng)整體開發(fā)進度要求3）模型應有可能控制並消除軟體開發(fā)風險4）模型應有可用的電腦輔助工具（如快速原型工具）的支持5）模型應與用戶和軟體開發(fā)人員的知識和技能相匹配6）模型應有利於軟體開發(fā)的管理與控制航太型號軟體研製過程模型航太型號研製經歷方案階段、模樣、初樣、試樣（正樣）、定型型號軟體研製通常也經歷模樣、初樣、試樣（正樣）模樣、初樣、正樣軟體是針對同一個軟體開展的迴圈研製，側重面不同。結合原型、漸進模型，以原型-基本型-更新型來形成航太型號軟體研製過程模型原型、基本型、更新型基本思想是：首先在需求尚不明確的情況下，對已知的需求和尚不能確定的需求進行分析整理，在此基礎上簡單地設計、編制軟體，產生一個軟體的原型，並對原型進行多方面的研究、分析和討論，以便確定所採取的技術實現(xiàn)方案是否可行，需求還要做哪些補充、修改和完善，從而獲得一個內容較完整、介面較明確的軟體需求和一個切實可行的軟體實現(xiàn)技術途徑；其次在軟體原型研製的基礎上，進行一次完整、嚴格的軟體研製工作，獲得一個高質量的軟體基本型；最後在軟體基本型的基礎上，針對更新的軟體需求，採用軟體更新與更改的的方法，對軟體進行更新，獲得軟體的更新型模樣、初樣、試樣-正樣模樣初樣正樣原型基本型更新型更新版本1更新版本2……原型軟體原型研製的目的是明確介面、確定需求、試驗系統(tǒng)方案需求分析：根據(jù)系統(tǒng)的任務分解和技術要求，對已知需求、應有需求、未確認需求等進行綜合分析，形成粗略的原型軟體需求規(guī)格說明。設計：對軟體的總體結構和介面進行設計，形成軟體設計說明。編碼調試：編制程式並調試通過。分析總結：運行軟體，並與系統(tǒng)總體、相應介面單位進行詳細的分析討論，對軟體需求進行補充、修改和完善，並確定技術途徑的可行性。對高質量要求的軟體研製，軟體原型研製所獲的程式應廢棄，不帶入以後的研製階段?；拘突拘脱醒u的任務是根據(jù)基本確定的軟體需求，全面開展軟體的研製工作，形成一個基本滿足系統(tǒng)對軟體各項要求的基本型軟體，以直接應用於型號或作為下一步更新的基礎?；拘蛙涹w的研製，必須採用瀑布式開發(fā)過程，嚴格執(zhí)行。研製階段包括：系統(tǒng)需求、軟體需求分析、概要設計、詳細設計、軟體實現(xiàn)、軟體組裝測試、軟體確認測試、系統(tǒng)聯(lián)試軟體開發(fā)方法軟體開發(fā)方法是軟體開發(fā)過程所遵循的方法和步驟，其目的在於有效地得到一些工作產品，既程式和文檔，並且滿足品質要求程式設計方法是軟體開發(fā)方法的組成部分此外還有分析方法和設計方法評價軟體開發(fā)方法的四大特徵技術特徵：支持各種技術概念的方法特色，如層次性、抽象性、並行性、安全性、正確性等使用特徵：用於具體開發(fā)時的特色，如易理解性、易移植性、易複用性、工具的支持、任務範圍、使用的廣度、活動過渡的可行性、產品的易修改性、對正確性的支持等管理特徵：增強對軟體開發(fā)活動管理的能力方面的特色，如易管理性、支持或阻礙團隊工作的程度、中間階段的確定、工作產品、配置管理、階段結束準則、費用估計等經濟特徵：給軟體組織產生的在品質和生產力方面的可見效益，如分析活動的局部效益、全生存週期效益、獲得該開發(fā)方法的代價、使用它的代價、管理的代價等選用軟體開發(fā)方法的考慮因素1對該開發(fā)方法是否已具有經驗，或者已有受過培訓的人員2開發(fā)專案的進度、人員組成情況3為開發(fā)專案提供的資源如何4計畫、組織、管理的可行性5開發(fā)專案的領域知識準備情況航太的考慮結構化方法較全面、最成熟、最基礎、使用最廣泛、有成功經驗結構化方法適合航太軟體研製工作結構化方法是基礎性方法結構化方法包括就形成了配套的軟體結構化分析方法、結構化設計方法和結構化編程方法，其核心和基礎是結構化程式設計理論為什麼要講這些所謂的“方法”？“我只要滿足需求就可以了，我自己開發(fā)使用什麼方法你管不著?！薄斑@些方法根本沒有什麼用處，我們那裏高手很多，我們不屑於使用這些方法?！薄敖Y構化”起源：對GOTO的認識1968年Dijkstra在ACM通訊中發(fā)表了“GOTO語句是有害的”文章，認為：GOTO語句是有害的，是造成程式混亂的禍根，程式的品質與GOTO語句的數(shù)量成反比，應該在所有高級程式設計語言中取消GOTO語句激起了強烈的反響和長期廣泛的論戰(zhàn)論據(jù)1966年，Boehm和Jacopini證明了程式設計語言只要上旬、選擇和重複三種形式的控制結構就足以表達出各種其他形式的結構1970年McKeeman稱其XPL編譯程序僅用一個GOTO語句1972年C.Strachey設計的操作系統(tǒng)只在五處使用了標號和GOTO語句爭辯否定GOTO取消GOTO後，程式易理解、易排錯、易維護沒有其他好的結構代替GOTO的話，容易濫用GOTO無GOTO的程式容易進行正確性證明肯定GOTO在塊和進程的非正常出口處往往需要使用GOTO會使程式執(zhí)行效率較高在合成程式目標時，GOTO語句往往是有用的，如返回語句用GOTO結論1974年Knuth發(fā)表了總結性文章：“帶有GOTO的結構化程式設計”令人信服地總結和證實了以下三點：濫用GOTO語句確實有害，應儘量避免完全避免使用GOTO語句也並非是個明智的方法，有些地方使用GOTO語句，會使程式流程更清楚、效率更高爭論的焦點不應該放在是否取消GOTO語句，而應該放在用什麼樣的程式結構上最後一點使關鍵，肯定以提高程式清晰性為目標的結構化方法“方法”的核心是模型所謂的“方法”通常圍繞一系列的模型展開，給出這些模型的建立，校驗和轉換方法。COMPUTERMODELREALREAL仿自：CantwellSmith“Computers,ModelsandtheEmbeddingWorld”方法與模型電腦設計模型REAL實際分析模型分析編碼設計分析模型和設計模型分析模型：對當前所處的環(huán)境，或者現(xiàn)實情況建立的模型，用於分析和評估。設計模型：對未來要建造的系統(tǒng)或者環(huán)境建立的模型，用於系統(tǒng)實施，也用於交流和評價。建立模型有助於精確有效地表達和溝通。結構化方法結構化程式設計：一種良好定義的軟體開發(fā)技術，它採用自頂向下設計和實現(xiàn)方法，並嚴格地採用結構化程式的控制構造結構化方法的原則清晰第一效率第二設計先於編碼自頂向下逐步細化1清晰第一效率第二著名的“清晰第一，效率第二”已成為當今主導的程式設計風格“先求清楚後求快”“保持程式簡單以求快”“寫清楚——不要為‘效率’犧牲清晰”2設計先於編碼“開始寫程式越早，完成程式需要的時間就越長。”“設計先於編碼”已成為所有程式設計必須遵守的一條原則。設計一定要利用各種設計工具來進行。3逐步細化的設計方法…逐步細化方法是結構化程式設計的心臟。1）中心思想a.程式設計是一個由粗到細的過程;b.程式設計不僅包括對控制結構的設計，也包括對數(shù)據(jù)結構的設計，兩者都要一步步地細化。3逐步細化的設計方法2）指導原則a.先分解主要問題，次要的問題可暫時擱置；b.堅持漸進的原則，每一步的變化不要太大；c.過程的細化與數(shù)據(jù)結構的細化宜並行、交叉地進行；d.選用適合於問題的設計工具；e.最後一步應詳細到所得結果可以直接翻譯為根源程式。3）優(yōu)點a.便於控制開發(fā)的複雜性;b.便於驗證程式的正確性。結構化方法採用的原則抽象逐步求精資訊隱藏模組化模組獨立模組化原則模組是由邊界元素限定的相鄰的程式元素(例如，數(shù)據(jù)說明，可執(zhí)行的語句)的序列，而且有一個總體識別字來代表它。模組是構成程式的基本構件。模組化就是把程式劃分成獨立命名且可獨立訪問的模組，每個模組完成一個子功能，把這些模組集成起來構成一個整體，可以完成指定的功能滿足用戶的需求。模組化原則主要思想是：將整個系統(tǒng)進行分解成為若干功能獨立的，能分別設計、編程和測試的模組程式員能單獨地負責一個或幾個模組的開發(fā)開發(fā)一個模組不需要知道系統(tǒng)其他模組的內部結構和編程細節(jié)模組之間的介面盡可能簡明，模組應盡可能彼此隔離模組化和軟體成本Meyer模組化五條標準…(1)模組可分解性如果一種設計方法提供了把問題分解為子問題的系統(tǒng)化機制，它就能降低整個問題的複雜性，從而可以實現(xiàn)一種有效的模組化解決方案。(2)模組可組裝性如果一種設計方法能把現(xiàn)有的(可重用的)設計構件組裝成新系統(tǒng)，它就能提供一種並非一切都從頭開始做的模組化解決方案。Meyer模組化五條標準…(3)模組可理解性如果可以把一個模組作為一種獨立單元(無需參考其他模組)來理解，那麼，這樣的模組是易於構造和易於修改的。(4)模組連續(xù)性如果對系統(tǒng)需求的微小修改只導致對個別模組，而不是對整個系統(tǒng)的修改，則修改所引起的副作用將最小。Meyer模組化五條標準…(5)模組保護性如果在一個模組內出現(xiàn)異常情況時，它的影響局限在該模組內部，則由錯誤引起的副作用將最小。模組化應達到的要求具有可修改性：對整個系統(tǒng)的一次修改只涉及少數(shù)幾個模組，這種局部性的修改不僅能滿足系統(tǒng)修改的要求，而且不會影響系統(tǒng)已經具有的良好品質具有易讀性：每個模組的含義和職責被明確，模組之間的介面關係清楚，從而降低複雜性，使得閱讀和理解比較方便具有易驗證性：只有每個模組能實現(xiàn)正確，才可能使整個系統(tǒng)的正確性有必要的前提抽象人類在認識複雜現(xiàn)象的過程中使用的最強有力的思維工具是抽象。人們在實踐中認識到，在現(xiàn)實世界中一定事物、狀態(tài)或過程之間總存在著某些相似的方面(共性)。把這些相似的方面集中和概括起來，暫時忽略它們之間的差異，這就是抽象。抽象就是抽出事物的本質特性而暫時不考慮細節(jié)。逐步求精逐步求精是人類解決複雜問題時採用的基本技術，也是許多軟體工程技術的基礎?？梢园阎鸩角缶x為：“為了能集中精力解決主要問題而儘量推遲對問題細節(jié)的考慮?！鼻缶珜嶋H上是細化過程。抽象與求精抽象與求精是一對互補的概念抽象使得設計者能夠說明過程和數(shù)據(jù)，同時卻忽略低層細節(jié)。可以把抽象看作是一種通過忽略多餘的細節(jié)同時強調有關的細節(jié)，而實現(xiàn)逐步求精的方法。求精則幫助設計者在設計過程中揭示出低層細節(jié)。這兩個概念都有助於設計者在設計演化過程中創(chuàng)造出完整的設計模型。資訊隱藏應用模組化原理時，自然會產生的一個問題：“為了得到最好的一組模組，應該怎樣分解軟體”Parnas提出的資訊隱藏是模組化程式設計的基本方法資訊隱藏：為了實現(xiàn)部件的可見性控制，在分層構造軟體模組時，要求這些部件只在模組內部可見，在模組外部不可見模組獨立“模組獨立”概念是模組化、抽象、逐步求精和資訊隱藏等概念的直接結果，也是完成有效的模組設計的基本標準。模組的獨立程度可以由兩個定性標準來度量，這兩個標準分別稱為內聚和耦合。耦合衡量不同模組彼此間互相依賴(連接)的緊密程度；內聚衡量一個模組內部各個元素彼此結合的緊密程度。耦合耦合是對一個軟體結構內不同模組之間互連程度的度量。耦合強弱取決於模組間接口的複雜程度，進入或訪問一個模組的點，以及通過介面的數(shù)據(jù)。應該追求盡可能鬆散耦合的系統(tǒng)。研究、測試或維護任何一個模組可以不需要對系統(tǒng)的其他模組有很多瞭解。發(fā)生在一處的錯誤傳播到整個系統(tǒng)的可能性就很小。內聚內聚標誌一個模組內各個元素彼此結合的緊密程度，它是資訊隱蔽和局部化概念的自然擴展。簡單地說，理想內聚的模組只做一件事情。設計時應該力求做到高內聚，通常中等程度的內聚也是可以採用的，而且效果和高內聚相差不多；但是，低內聚很壞，不要使用。內聚和耦合內聚和耦合是密切相關的，模組內的高內聚往往意味著模組間的松耦合。內聚和耦合都是進行模組化設計的有力工具，但是實踐表明內聚更重要，應該把更多注意力集中到提高模組的內聚程度上。事實上，沒有必要精確確定內聚的級別。重要的是設計時力爭做到高內聚，並且能夠辨認出低內聚的模組，有能力通過修改設計提高模組的內聚程度降低模組間的耦合程度，從而獲得較高的模組獨立性。啟發(fā)規(guī)則以下的啟發(fā)規(guī)則有助於模組化：改進軟體結構提高模組獨立性模組規(guī)模應該適中深度、寬度、扇出和扇入都應適當模組的作用域應該在控制域之內力爭降低模組介面的複雜程度設計單入口單出口的模組模組功能應該可以預測結構化方法圖示數(shù)據(jù)字典DFDSTDERD加工規(guī)約數(shù)據(jù)對象描述控制規(guī)約介面設計體系結構設計數(shù)據(jù)設計過程設計結構化分析方法結構化分析(SA)方法是結構化程式設計理論在軟體需求分析階段的運用。它是七十年代中期宣導的基於功能分解的分析方法，常用於基於瀑布模型的軟體研製過程的需求分析階段，其目的是幫助弄清用戶對軟體的需求。按照DeMarco的定義，“結構化分析就是使用數(shù)據(jù)流圖（ＤＦＤ）、數(shù)據(jù)字典（ＤＤ）、結構化英語、決策表和決策樹等工具，來建立一種新的、稱為結構化規(guī)格說明的目標文檔。”結構化分析五個步驟1)通過對用戶的調查，以軟體的需求為線索，獲得當前系統(tǒng)的具體模型；2)去掉具體模型中非本質因素，抽象出當前系統(tǒng)的邏輯模型；3)根據(jù)電腦的特點分析當前系統(tǒng)與目標系統(tǒng)的差別，建立目標系統(tǒng)的邏輯模型；4)完善目標系統(tǒng)並補充細節(jié)，寫出目標系統(tǒng)的軟體需求規(guī)格說明；5)評審直到確認完全符合用戶對軟體的需求。八條指導原則1)請用戶共同參與開發(fā)；2)編寫用戶資料，考慮他們的專門技術水準和閱讀與使用資料的目的；3)使用畫圖工具做媒介，減少與用戶交流時發(fā)生問題的可能性；4)進行系統(tǒng)設計之前建立一個系統(tǒng)的邏輯模型；5)自頂向下進行分析設計；6)自頂向下的方法進行測試；7)驗收之前，就讓用戶看到系統(tǒng)的某些主要輸出，使用戶能夠儘早地看到結果，及時地提出意見；8)對系統(tǒng)的評價不僅是指開發(fā)和運行費用的評價，而是對整個生存過程中的費用和收益的評價。結構化分析方法四大特點一是用畫圖的方法二是自頂向下地分解三是強調邏輯而不是物理四是沒有重複性結構化分析的工具1)數(shù)據(jù)流圖(DFD)；2)控制流圖(CFD)；3)數(shù)據(jù)字典(DD)；4)控制邏輯表達方法,包括狀態(tài)轉換圖(STD)等；5)處理邏輯表達方法，包括結構化語言、判斷樹和判斷表；6)數(shù)據(jù)存儲結構規(guī)範化；7)數(shù)據(jù)立即存取圖(DIAD)。四句指導工作的準則分層分片，均衡分解；父子平衡，推遲細節(jié)。分層就是逐步細化；分片就是用一組數(shù)據(jù)流圖來代替一大張包羅萬象的總圖。均衡分解是指自頂向下畫分層數(shù)據(jù)流圖時，各個子系統(tǒng)的分解程度應大致均勻。父子平衡是指數(shù)據(jù)流圖的父圖與子圖在輸入數(shù)據(jù)和輸出數(shù)據(jù)上應該分別保持一致。推遲細節(jié)是指為了優(yōu)先考慮重要問題，允許將一些細節(jié)推遲到下層數(shù)據(jù)流圖來處理。結構化設計方法70年代提出的面向數(shù)據(jù)流、重點確定軟體結構的設計方法“結構化設計就是採用最佳的可能方法設計系統(tǒng)的各個組成部分以及各成分之間的內部聯(lián)繫的技術。也就是說，結構化設計是這樣一個過程，它決定用哪些方法把哪些部分聯(lián)繫起來，才能解決好某個具體有清楚定義的問題。”基本思想是將軟體設計成由相對獨立、單一功能的模組組成的結構。評價模組結構品質的兩個具體標準——內聚度和耦合度耦合度耦合度：耦合度是各模組之間相互聯(lián)繫的一種度量，它是對模組獨立性的直接衡量，耦合度越弱就意味著模組的獨立性越高，則模組間相互影響就越小。耦合度的強弱可以由弱至強分為非直接耦合、數(shù)據(jù)耦合、特徵耦合、控制耦合、外部耦合、公共耦合和內容耦合七個等級。內聚度內聚度是指一個模組內部各成分（語句或語句段）之間的聯(lián)繫程度，內聚度高，則模組的相對獨立性勢必會提高。內聚度由低到高可劃分為偶然內聚、邏輯內聚、時間內聚、過程內聚、通訊內聚、順序內聚和功能內聚七個等級。結構化設計方法設計步驟1)建立初始結構圖;2)改進初始結構圖。建立初始結構圖開始細化/修改軟體需求規(guī)格說明中的數(shù)據(jù)流圖是變換型嗎？變換分析事物分析將映射得來的初始結構圖改進為最終結構圖對最終結構圖進行評審結束是否從數(shù)據(jù)流圖過渡到結構圖傳入傳入部分變換中心傳出部分（a）變換型結構傳出變換接受事務分析動作1動作2動作3接受部分事務中心（b）事務型結構DFD主模組輸入模組主加工模組輸出模組(a)事務控制模組接受模組動作發(fā)送模組動作1模組動作1模組動作1模組(b)SC改進初始結構圖…

1）減少塊間聯(lián)繫，降低耦合度：可從方式、作用、數(shù)量等方面著手，其中最常用的是減少模組間傳遞的參數(shù)個數(shù)；2）消除管道性模組，提高內聚度：管道性模組的塊內聯(lián)系很弱，只是像管道一樣將一些參數(shù)從主模組傳送到它的幾個下層模組，對這樣的模組，應予以消除；3）適當考慮系統(tǒng)將來可能發(fā)生的變化；改進初始結構圖4）注意模組的大小：限制模組大小是降低複雜性的手段之一；5）適當調整調用和被調用的次數(shù)，即深度、寬度、扇出和扇入都要適當。一個模組調用或被調用過多，往往是設計不好的跡象；6）整體考慮問題：即盡可能研究整張結構圖，而不是只分別考慮一張結構圖的各個部分。三條指導規(guī)則1）對模組分割、合併和變動模組調用關係的指導規(guī)則2）保持高扇入/低扇出的規(guī)則3）把作用域保持在控制域之內的規(guī)則對模組分割、合併和變動模組調用關係的指導規(guī)則分割或合併結構圖中的模組，應以提高模組獨立性為首要的標準：力求提高內聚，降低耦合，簡化介面，少用全局性和控制型資訊要適當考慮快的大小對模組位置應否變更，視處理是否方便來定，不必拘泥於數(shù)據(jù)流圖保持高扇入/低扇出的規(guī)則扇入數(shù)指調用該模組的模組個數(shù)扇出數(shù)指該模組調用的模組個數(shù)扇入高則上級模組多，能增加利用率扇出低則下級模組少，能減少複雜度扇出數(shù)以３－４為宜，最好不超過5-7軟體結構通常具有“甕”形或“清真寺”形的形狀把作用域保持在控制域之內的規(guī)則一個模組的控制域，等於模組本身加上其下級模組。一個模組的作用域，是受這個模組中的判定所影響的模組。規(guī)則的含義是：a.作用域不要超過控制域的範圍；b.軟體系統(tǒng)的判定，其位置離受它控制的模組越近越好。結構化編程方法用一組標準的準則和工具從事程式設計，稱為結構化程式設計；這些準則和工具包括一組基本控制結構，自頂向下擴展原則，模組化和逐步求精結構化編程方法派生於結構化程式設計理論，它要求使用順序、選擇、迴圈等基本控制結構，並遵循增加程式產量、提高程式可讀性、容易測試和驗證的原則來編寫程式。結構化編程應遵循的原則…1)使用程式設計語言中的順序、選擇、迴圈等有限的控制結構表示程式的控制邏輯；2)選用的控制結構只準許有一個入口和一個出口；3)程式語句組成容易識別的塊，每塊只有一個入口和一個出口；4)複雜結構應該用嵌套的基本控制結構來實現(xiàn)；結構化編程應遵循的原則5)語言中所沒有的控制結構，應該採用前後一致的方法來模擬；6)嚴格控制GOTO語句，僅在下列情況才可使用：a.用一個非結構化的程式設計語言去實現(xiàn)一個結構化的構造；b.若不使用GOTO語句會使功能模糊；c.在某種可以改善而不是損害程式可讀性的情況下。結構化編程方法的主要優(yōu)點1)易於理解、使用和維護。程式員採用結構化編程方法，降低了程式的複雜性，因此容易編寫程式。程式員能夠進行逐步求精、程式證明和測試，以確保程式的正確性，程式容易閱讀並被人理解，便於用戶使用和維護。2)提高編程工作的效率，降低了軟體開發(fā)成本。由於結構化編程方法能夠把錯誤控制到最低限度，因此能夠減少調試和查錯時間。結構化程式是由一些為數(shù)不多的基本結構模組組成，這些模組甚至可以由機器自動生成，從而極大地減輕了編程工作量。結構化方法的缺點著名的“兩個鴻溝”“數(shù)據(jù)和過程的鴻溝”“分析和設計的鴻溝”專注於過程的分析模型，其抗擊變動的能力和可複用性就相對較差。軟體開發(fā)的原則（1）規(guī)範嚴格的原則遵循嚴格化原則，可以達到開發(fā)出正確、成功的軟體產品的目的軟體開發(fā)過程是創(chuàng)造性的工作過程，但嚴格化不會抑制創(chuàng)造性嚴格的分析設計可以增強對創(chuàng)造性成果的信心嚴格化對可靠性、維護性、可移植性、可理解性等產生影響過程詳細記錄可供精確地掌握和控制開發(fā)過程軟體開發(fā)的原則（2）分隔化的原則解決複雜問題時從不同的方面把問題分隔開，然後單獨集中精力解決每一個方面的問題分隔化原則是要將相互關係不太緊密的方面分割開，對相互聯(lián)繫僅考慮其影響分隔的途徑：以時間次序、以品質指標、以軟體規(guī)模、以不同的視圖、以開發(fā)人員的技能軟體開發(fā)的原則（3）模組化的原則先對複雜問題進行分析，找出基本要素，儘量使之獨立，然後各個擊破簡單的單元易於加工、維修，可以標準化、通用化複雜問題的分解，基於自頂向下的思路已有模組的組合，基於自底向上的思路軟體開發(fā)的原則（4）抽象化的原則重要、帶有普遍意義特徵的方面或內容被抽象出來，次要的、缺乏普遍意義的方面或內容被忽略抽象是分隔化原則的一種特殊應用軟體開發(fā)的原則（5）預見變動的原則軟體由於其錯誤、新需求、新環(huán)境而產生變化要求開發(fā)時就要考慮到軟體變動的要求PARNAS的原則開發(fā)系列產品漸進開發(fā)，從子集出發(fā)，資訊隱藏，保持介面不變採用為變化而設計的技術軟體開發(fā)的原則（6）通用化的原則儘量找出對類似問題或相關問題的具有一定普遍意義的解決方法，並在相應產品開發(fā)中應用，使軟體產品具有一定的通用性對普遍性、通用性問題的解決方法具有品質、經濟方面的價值對通用和專用，需要在經濟和效率方面進行權衡通用性原則是設計通用的軟體產品的一個最基本原則軟體開發(fā)的原則（7）逐步完善的原則由於難以確定用戶的具體需求，只能從不完善逐步走向完善必須注意：記錄每一個有意義的漸進文檔必須儘早反映變動，變動得到控制MICROSOFT在採用逐步完善原則方面取得了成功軟體開發(fā)的原則（8）有關軟體品質的原則用戶至上的原則以用戶的利益為前提處處為用戶使用方便著想千方百計幫助用戶使用好軟體注意與用戶的交流品質可靠的原則在品質、成本之間進行權衡軟體開發(fā)的原則（9）有關軟體文檔的原則文檔標準化原則用戶手冊簡明原則用詞規(guī)範盡可能使用用戶的專業(yè)術語或行話通俗易懂描述的句子不要太長軟體開發(fā)的原則（10）有關設計編碼的原則根據(jù)文檔設計（需求記錄在文檔）注意概念的完整整個軟體要適於變動、易於維護程式編制簡明清晰注意技術與工具更新軟體開發(fā)的原則（11）有關軟體測試的原則測試的獨立性原則克服心理障礙獨立公正專業(yè)優(yōu)勢成功的測試是發(fā)現(xiàn)問題的測試要分析錯誤產生的原因，舉一反三需求分析概念軟體需求的定義客戶定義的“需求”對開發(fā)者是一個較高層次的產品概念。開發(fā)者所說的“需求”對用戶來說像是詳細說明。軟體需求包含多個層次，不同層次的需求從不同角度與不同程度反映著細節(jié)問題。IEEE軟體工程術語（1997）的需求定義：（1）用戶解決問題或達到目標所需的條件或能力。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)範或其他正式強制性檔所需具有的條件或能力。（3）反映上面（1）或（2）所描述的條件或能力的文檔說明。上述定義包括從用戶（外部）、從開發(fā)者（內部）角度來闡述需求。需求的層次業(yè)務需求（businessrequirement）：反映組織機構或客戶對系統(tǒng)、產品高層次的目標要求。用戶需求（userrequirement）：描述用戶使用產品必須要完成的任務。功能需求（functionalrequirement）：定義開發(fā)人員必須實現(xiàn)的軟體功能。需求規(guī)格說明中還包括非功能需求。軟體需求各組成部分之間關係業(yè)務需求用戶需求功能需求系統(tǒng)需求品質屬性其他非功能需求約束條件專案視圖與範圍檔使用實例文檔軟體需求規(guī)格說明需求管理的困難性不成熟的需求分析無足夠用戶參與用戶需求的不斷增加摸棱兩可的需求不必要的特徵（鍍金）過於精簡的規(guī)格說明忽略了用戶分類不準確的計畫高質量需求過程的獲益開發(fā)後期和整個維護階段的重做的工作大大減少Boehm發(fā)現(xiàn)可以節(jié)省成本68倍有研究認為可以節(jié)省成本200倍強調產品開發(fā)中的通力合作，面向市場，讓用戶積極參與，可以建立忠實的客戶關係，避免在無用功能上白耗精力，彌補用戶期望和開發(fā)者實際開發(fā)間的期望鴻溝採用系統(tǒng)方法將需求分配到各子系統(tǒng)可以簡化集成有效的變更控制和影響分析能降低變更的負面影響清晰、無二義的需求文檔有利於測試需求說明的特徵完整性正確性可行性必要性劃分優(yōu)先順序無二義性可驗證性需求規(guī)格說明的特點完整性先用TBD標明缺項在開發(fā)前必須解決所有TBD一致性可修改性每項需求只在SRS中出現(xiàn)一次可追蹤性結構、粒度方便設計、實現(xiàn)、測試的追蹤誰是客戶定制軟體：合同甲方（提出方）通用軟體：高層管理者和（或）市場部嵌入式軟體：軟體所屬電腦系統(tǒng)客戶的權利1要求分析人員使用符合客戶語言習慣的表達2要求分析人員瞭解客戶的業(yè)務及目標3要求分析人員編寫軟體需求規(guī)格說明4要求得到需求工作結果的解釋說明5要求開發(fā)人員尊重你的意見6要求開發(fā)人員對需求及產品實施提供建議7描述產品易使用的特性8調整需求，允許重用已有的軟體組件9要求對變更的代價提供真實可信的評估10獲得滿足客戶功能和品質要求的系統(tǒng)客戶的義務1給分析人員講解你的業(yè)務2抽出時間清楚地說明並完善需求3準確而詳細地說明需求4及時地作出決定5尊重開發(fā)人員的需求可行性及成本評估6劃分需求優(yōu)先順序別7評審需求文檔和原型8需求出現(xiàn)變更要馬上聯(lián)繫9應遵守開發(fā)機構處理需求變更的過程10尊重開發(fā)人員採用的需求工程過程對簽定需求協(xié)議的認識簽約是客戶同意需求的標誌行為客戶不應當忽略簽約的嚴肅性開發(fā)方不應當因此拒絕變更簽約應當建立在一個需求協(xié)議的基線上應當理解為：“我同意這份文檔表達了目前我們對專案軟體需求的瞭解。進一步的變更可在此基礎上通過專案定義的變更過程來進行。我知道變更可能會使我們要重新協(xié)商成本、資源和專案時間工期任務等?！毙枨箝_發(fā)過程需求開發(fā)過程需求獲取需求分析編寫需求規(guī)格說明需求驗證知識培訓需求管理專案管理需求獲取的內容在同用戶的交流過程中收集各種用戶的資訊認真理解用戶的各項要求澄清模糊排除不合理明確約束分析人員的兩個信條第一：只有在徹底瞭解和掌握了用戶的全部意圖之後，才有可能建立起成功的軟體系統(tǒng)。第二：一切從用戶的角度著想，在條件允許的情況下，應盡可能地保證用戶從所構造的軟體系統(tǒng)中獲得最大的利益。容易產生的問題交流障礙誤解各方缺乏共同的語言“完整性”問題需求永遠會變化用戶本身的意見不一致錯誤的要求認識上混淆目標和需求需求獲取的過程確定需求開發(fā)過程編寫專案目標和範圍文檔將用戶群分類並歸納各自特點選擇各類用戶的產品代表建立起典型用戶的核心隊伍讓用戶代表確定使用實例召開應用程式開發(fā)聯(lián)繫會議分析用戶工作流程確定品質屬性和其他非功能屬性通過檢查當前系統(tǒng)的問題報告來進一步完善需求跨專案重用需求工作流程用戶調查具體模型邏輯抽象當前系統(tǒng)邏輯模型當前系統(tǒng)計算機化評審修改正式模型完善細節(jié)目標系統(tǒng)目標系統(tǒng)初始模型經認可的問題需求系統(tǒng)模型用戶建立模型的步驟分析現(xiàn)有系統(tǒng)和過程，建立物理模型抽取特徵，建立舊系統(tǒng)的邏輯模型根據(jù)新的要求，補充和建立新的邏輯模型需求分析的任務需求分析的內容提煉、分析和仔細審查已收集到的需求確保所有利益相關者都明白其含義並找出其中的錯誤、遺漏或其他不足的地方是從用戶最初的非形式化需求到滿足用戶要求的軟體產品的映射過程是對用戶意圖不斷進行提示和判斷的過程需求分析的步驟繪製系統(tǒng)關聯(lián)圖創(chuàng)建用戶介面（介面）原型分析需求可行性確定需求的優(yōu)先順序別為需求建立模型創(chuàng)建數(shù)據(jù)字典使用品質功能調配（QFD）明確哪些是客戶最關心的特徵編制需求規(guī)格說明的過程採用軟體需求規(guī)格說明（SRS）模版指明需求的來源為每項需求注上標號記錄業(yè)務規(guī)範（操作原則）創(chuàng)建需求跟蹤矩陣需求規(guī)格說明的作用為用戶、分析人員和設計人員之間的交流提供方便支持目標軟體系統(tǒng)的確認控制軟體開發(fā)進程軟體需求規(guī)格說明文檔條目1範圍2引用文檔3工程需求3.1外部介面需求3.2功能需求3.3內部介面3.4數(shù)據(jù)元素要求3.5適應性要求3.6容量和時間要求3.7安全要求3.8保密要求3.9設計約束3.10軟體品質因素3.11人的工程需求3.12需求的可跟蹤性4合格性需求4.1合格性方法4.2特殊的合格性需求5交付準備軟體需求必須包括的屬性1）標識：每項軟體需求都必須有標識，使以後的各階段容易跟蹤。2）需要：基礎軟體需求必須用上述標識標明?；A軟體需求是非協(xié)商性的；其他不那麼重要的需求是可協(xié)商的。3）優(yōu)先順序：對於遞增式交付，每一項需求必須包括優(yōu)先順序程度，以便決定研製進度。4）穩(wěn)定性：某些需求在軟體生存期內是穩(wěn)定的；另一些可能是更依賴來自各設計階段的回饋，或可能在軟體生存期內要有所修改，這種非穩(wěn)定性需求應當被指出。5）源：每一項軟體需求都必須有一個能回溯到系統(tǒng)需求的索引。6）清晰性：如果需求有一個並且只有一個解釋它就是清晰的。7）驗證性：每一軟體需求都必須是能被驗證的。這意味著必須能做到：檢查需求已經體現(xiàn)在設計中；證明該軟體將實現(xiàn)需求；測試該軟體確實能實現(xiàn)需求。IEEE需求規(guī)格說明的編寫8原則1從實際重分離功能，描述“做什麼”不描述“怎麼做”2要求有一個面向處理的軟體系統(tǒng)規(guī)格說明語言，以描述軟體系統(tǒng)的動態(tài)行為3必須對以該軟體為元素的系統(tǒng)進行說明，以描述清楚之間的關係4必須對軟體系統(tǒng)的運行環(huán)境進行說明，以保持介面描述的一致性5必須是認識的模型而不是實際的模型6必須是可操作的7必須容忍不完備性和可修改性8必須局部化和鬆散耦合，使得變化時只修改一個片段SRS編寫風格（Kovitz1999)保持語句和段落的簡短採取主動語態(tài)的表達方式編寫具有正確的語法、拼寫和標點的完整句子使用的術語和辭彙表中所定義的應該一致需求陳述應該採用一致的樣式，如“主體+動作+可觀察的結果”避免使用模糊的、主觀的術語以避免不確定性避免使用比較性的辭彙需求表達需求說明語句保持語句和段落的簡短採用主動語態(tài)的表達方式編寫具有正確的語法和標點的完整句子使用的術語應該和辭彙表中定義的一致需求陳述應該具有一致的式樣，例如“系統(tǒng)必須……”，或者“用戶必須……”，並緊跟一個行為動作和可觀察的結果，例如“倉庫管理子系統(tǒng)必須現(xiàn)實一張在所請求的倉庫中有存貨的藥品名單?！毙枨蟊磉_為了減少不確定性，避免採用模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優(yōu)越的、可接受的和健壯的。避免使用比較性的辭彙，例如：提高，最大化，最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。需求表達“產品必須在固定的時間間隔內提供狀態(tài)消息，並且每次時間間隔不得小於60秒”後臺任務管理器應該在用戶介面的指定區(qū)域顯示狀態(tài)消息在後臺任務進程啟動之後，消息必須每隔60（+_10）秒更新一次，並且保持連續(xù)的可見性。如果正在正常處理後臺任務進程，那麼後臺任務管理器必須顯示後臺任務進程已完成的百分比當完成後臺任務時，後臺任務管理器必須顯示一個“已完成”的消息。如果後臺任務中止執(zhí)行，那麼後臺任務管理器必須顯示一個出錯資訊。需求表達“產品必須在顯示和隱藏非列印字元之間進行瞬間切換”“用戶在編輯文檔時，通過啟動特定的觸發(fā)機制，可以在顯示和隱藏所有HTML標記之間進行切換?！毙枨蟊磉_“分析程式應該能生成HTML標記出錯的報告，這樣就可以使HTML的初學者使用它來迅速排錯”在HTML分析程式完全分析完一個檔後，該分析程式必須生成一個出錯報告，這個報告中包含了在分析檔中所發(fā)生錯誤的HTML所在的行號以及文本內容，還包含了對每個錯誤的描述。如果分析過程中未發(fā)生任何錯誤，就不必生成任何錯誤報告需求驗證審查需求文檔以需求為依據(jù)編寫測試用例編寫用戶手冊確定判別產品合格的準則需求驗證的內容一致性：任何需求不與其它需求矛盾可行性：現(xiàn)有技術條件下可以實現(xiàn)完整性：包括用戶需要的每一個功能和性能有效性：正確有效，確實能夠解決用戶面對的問題知識培訓培訓需求分析人員培訓軟體需求的用戶代表和管理人員讓開發(fā)人員瞭解應用領域的基本概念編寫專案術語彙編分析員的職責１）作為管理員、用戶和顧客的顧問；２）從各種來源收集數(shù)據(jù)，並綜合問題的解答；３）分析新的系統(tǒng)，並評價現(xiàn)有的系統(tǒng)；４）準備文檔和管理報告；５）理解硬體和軟體的介面；６）為了產生軟體需求規(guī)格說明，必要時要進行一些研究工作；７）為編寫軟體需求規(guī)格說明主持座談會；８）不斷吸收先進技術。分析員的素質１）能夠合乎邏輯地、象徵性地、抽象地、創(chuàng)造性地思考問題；２）能作為小組中的一個成員很好地開展工作；３）熟悉電腦硬體和軟體的能力；４）自覺遵守時間，能按規(guī)定的進度完成任務；５）在系統(tǒng)的分析和設計中能發(fā)揮其他人的作用；６）能保持教師和學生的雙重身份，願意培養(yǎng)其他人，而他本人亦能通過夜校、自學、培訓班等不斷提高；７）能夠傾聽別人的意見，但又能根據(jù)客觀事實來作決策，而不是依賴別人的意見；８）熟悉商業(yè)和政策管理部門的組織、原則。分析員應該顯示的性格特徵1）善於領會一些抽象的概念，重新整理使之成為各種邏輯成分，並根據(jù)各種邏輯成分綜合出問題的解決辦法。2）善於從各種相應衝突或混淆的原始資料中汲取恰當?shù)囊罁?jù)。3）能夠理解用戶——需求者的環(huán)境。4）具備把系統(tǒng)的硬體部分和（或）軟體部分應用於用戶——需求者環(huán)境的能力。5）具備良好的用書面或口頭形式進行討論及交換意見的能力。6）具有“既能看到樹木，又能看到森林”的能力。需求管理確定需求變更控制過程建立變更控制委員會（CCB）進行需求變更影響分析跟蹤所有受需求變更影響的工作產品建立需求基準版本和需求控制版本文檔維護需求變更歷史記錄跟蹤每項需求的狀態(tài)衡量需求穩(wěn)定性使用需求管理工具與需求分析相關的專案管理選擇一種合適的軟體開發(fā)模型基於需求的專案計畫發(fā)生需求變更時協(xié)商專案約定文檔化和管理與需求相關的風險跟蹤需求工程耗費的工作量需求分析方法工具描述工具數(shù)據(jù)流圖(DataFlowDiagram，簡稱DFD)控制流圖(ControlFlowDiagram，簡稱CFD)狀態(tài)轉換圖（StateTransitiondiagram，簡稱STD）數(shù)據(jù)字典(DataDictionary，簡稱DD)處理說明分析模型的結構實體—關係圖狀態(tài)—遷移圖數(shù)據(jù)流圖數(shù)據(jù)對象描述加工規(guī)格說明數(shù)據(jù)字典控制規(guī)格說明數(shù)據(jù)和控制模型的關係過程模型PSPECDFD控制模型CSPECCFD控制輸入數(shù)據(jù)輸出控制輸出數(shù)據(jù)輸入數(shù)據(jù)條件過程啟動數(shù)據(jù)流圖:DFD（DataFlowDiagram）數(shù)據(jù)流圖是用來描述系統(tǒng)邏輯模型的一種圖形工具數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫數(shù)據(jù)流從輸入到輸出的移動變換過程數(shù)據(jù)流圖圖符2.1列印數(shù)據(jù)流DataFlow加工處理Process外部實體ExternalEntity數(shù)據(jù)存儲DataStore數(shù)據(jù)流圖圖符說明數(shù)據(jù)流：箭頭表示數(shù)據(jù)流方向。一般在旁邊標注數(shù)據(jù)流名。加工處理：對數(shù)據(jù)進行加工、處理和變換，從而實現(xiàn)某個功能或操作外部實體：表示要加工處理的數(shù)據(jù)是從外部得到或從外部提供，同時也是數(shù)據(jù)結果的接收者，可以是人、組織、其他系統(tǒng)數(shù)據(jù)存儲：表示處理過程中存放各種數(shù)據(jù)的檔建立DFD的步驟由外向裏：先畫系統(tǒng)的輸入輸出，然後畫系統(tǒng)的內部，再畫處理的內部。由頂向下：頂層、中間層、底層數(shù)據(jù)流圖逐層分解：從外向裏數(shù)據(jù)流圖的層次結構為了表達數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要採用層次結構的數(shù)據(jù)流圖。按照系統(tǒng)的層次結構進行逐步分解，並以分層的數(shù)據(jù)流圖反映這種結構關係，能清楚地表達和容易理解整個系統(tǒng)數(shù)據(jù)流圖的層次頂層DFD用一個加工處理表示軟體含所有相關外部實體含外部實體與軟體中間的數(shù)據(jù)流不含數(shù)據(jù)存儲唯一描述軟體的作用範圍，對總體功能、輸入、輸出進行抽象描述，反映軟體和系統(tǒng)、環(huán)境的關係ABC軟體abcd頂層數(shù)據(jù)流圖軟體系統(tǒng)外部實體外部實體……外部實體外部實體……輸入數(shù)據(jù)流輸入數(shù)據(jù)流輸出數(shù)據(jù)流輸出數(shù)據(jù)流中間和底層DFD2.1aaa2.2bbb2.3cccddd數(shù)據(jù)分層的數(shù)據(jù)流圖F0A0B0F11A0B0F12F13F14F15p1C1D1M1N1F21M1F22N1F23K2F24W2F25p1Y2X2第n

層第n+1

層第n+2

層數(shù)據(jù)流圖的層次在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化，形成子圖。數(shù)據(jù)流圖中的其他圖形元素ABC------有A則B或者C，或者兩者都有*ABC+ABC------有A則B與C，或者兩者同時有------有A則B或C，但不會同時有B與C------當A或B有一個存在就有CABC*ABC------只有當A與B都存在，則有CDFD規(guī)則和注意事項數(shù)據(jù)存儲不出現(xiàn)在頂層圖中，外部實體通常不出現(xiàn)在頂層圖外數(shù)據(jù)存儲之間不應該有數(shù)據(jù)流仔細、恰當?shù)貫樘幚砻禾幚?對象仔細、恰當?shù)貫閿?shù)據(jù)流命名：反映整體含義對處理建立唯一、層次性編號每個處理通常要求既有輸入又有輸出一個DFD的處理個數(shù)為7±2（魔數(shù)7±2）不要試圖讓DFD反映處理的順序檢查數(shù)據(jù)流圖的正確性a.數(shù)據(jù)守恆某個處理用以產生輸出的數(shù)據(jù)沒有輸入給這個處理，即出現(xiàn)遺漏另一種是一個處理的某些輸入並沒有在處理中使用以產生輸出b.數(shù)據(jù)存儲（檔）的使用數(shù)據(jù)存儲（檔）應被數(shù)據(jù)流圖中的處理讀和寫，而不是僅讀不寫、或僅寫不讀c.父圖和子圖的平衡父子關係和平衡規(guī)則父圖表示子圖間的介面，即數(shù)據(jù)流的方向和數(shù)量子圖代表父圖中某個處理的細節(jié)子圖個數(shù)不大於父圖中的處理個數(shù)所有子圖的輸入、輸出數(shù)據(jù)流和父圖中相應處理的輸入、輸出數(shù)據(jù)流必須一致父圖和子圖的平衡發(fā)票1.3開領書單領書單(a)父圖1.3.1學生領書單1.3.21.3.3教材(b)子圖遵守加工編號規(guī)則頂層加工不編號第二層的加工編號為1,2,3,…,n號第三層編號為1.1,1.2,1.3…n.1,n.2…等號依此類推人工銷售教材系統(tǒng)流程圖舉例學生開購書證明購書證明開購書發(fā)票

發(fā)票收書費

領書單發(fā)書學生學生教材購銷系統(tǒng)購書單領書單缺書單進書通知進書通知保管員1銷售購書單領書單學生缺書單進書通知2採購保管員第1

層第2

層

教材存量表F1

缺書登記表F2外部實體外部實體

教材銷售子系統(tǒng)無效書單購書單1.3登記並開領書單1.2開發(fā)票1.1審查有效性1.4登記缺書1.5補售教材采購學生學生進書通知有效書單發(fā)票領書單暫缺書單1銷售購書單領書單缺書單進書通知2採購進書通知缺書登記表教材存量表學生保管員第2

層補售書單第3層

教材存量表F1

缺書登記表F2F1書號單價數(shù)量

各班用書表F3

售書登記表F4外部項1銷售購書單領書單缺書單進書通知2採購進書通知缺書登記表教材存量表學生保管員採購子系統(tǒng)

第2層第3

層缺書單2.3修改教材庫存和待購量銷售進書通知進書通知2.1按書號匯總缺書2.2按出版社統(tǒng)計缺書保管員

教材存量表F1

待購教材表F5

教材一覽表F6

缺書登記表F2控制板感測器家庭安全軟體電話線警報控制板顯示警報類型感測器狀態(tài)用戶命令和數(shù)據(jù)顯示數(shù)據(jù)電話號碼信號與用戶交互1配置系統(tǒng)2啟/停系統(tǒng)3顯示消息狀態(tài)5處理口令4監(jiān)控系統(tǒng)6配置資訊用戶命令和數(shù)據(jù)配置請求配置數(shù)據(jù)啟/?？诹钆渲脭?shù)據(jù)配置數(shù)據(jù)啟/停消息顯示消息感測器資訊有效標識消息感測器狀態(tài)電話號碼信號警報類型評價防備設置6.1顯示格式化6.2生成警報信號6.3撥電話6.5讀感測器6.4配置資訊感測器標識,類型感測器狀態(tài)電話號碼配置數(shù)據(jù)感測器標識,定位警報數(shù)據(jù)感測器資訊電話號碼信號控制流圖（CFD）2.1列印控制流ControlFlow加工處理Process外部實體ExternalEntity數(shù)據(jù)存儲DataStore控制說明與用戶交互1配置系統(tǒng)2啟/停系統(tǒng)3顯示消息狀態(tài)5處理口令4監(jiān)控系統(tǒng)6配置資訊顯示動作狀態(tài)（完成、進行中）控制板控制板顯示警報電話線感測器感測器事件閃爍標誌警報狀態(tài)時間溢出警報信號啟/停開關數(shù)據(jù)字典（DD）數(shù)據(jù)字典是對所有與系統(tǒng)相關的數(shù)據(jù)元素的一個有組織的列表，以及精確的、嚴格的定義，使得用戶和系統(tǒng)分析員對於輸入、輸出、存儲成分和中間計算結果有共同的理解。數(shù)據(jù)字典把不同的需求文檔和分析模型緊密結合在一起數(shù)據(jù)字典的作用DFD中的數(shù)據(jù)流、數(shù)據(jù)存儲表示某個有組織的數(shù)據(jù)集合，它們要由SA的其他描述工具-需求字典(數(shù)據(jù)字典)來描述，包括：詞條描述數(shù)據(jù)結構描述加工邏輯說明數(shù)據(jù)字典的內容DD包含的資訊名稱（標識）別名來源去向組成（內容描述）流動屬性（頻率、數(shù)據(jù)量）補充資訊數(shù)據(jù)的層次關係原數(shù)據(jù)元素組合項重複項選擇項可選項數(shù)據(jù)字典基本符號＝表示“等於”，“定義為”，“由什麼構成”＋表示“與”，“和”[|]表示“或”，即選擇括弧中用“|”號分隔的各項中的某一項{}表示“重複”，即括弧中的項要重複若干次，重複次數(shù)的上下限也可以在括弧邊上標出（）表示“可選”，即括弧中的項可以沒有**表示“注釋”（1）數(shù)據(jù)流詞條描述數(shù)據(jù)流名：說明：簡要介紹作用即它產生的原因和結果數(shù)據(jù)流來源：來自何方數(shù)據(jù)流去向：去向何處數(shù)據(jù)流組成：數(shù)據(jù)結構數(shù)據(jù)量流通量：數(shù)據(jù)量，流通量舉例：購書單發(fā)票領書單審查並開發(fā)票開領書單無效書單學生12各班學生用書表學生教材存量表數(shù)據(jù)流詞條說明舉例數(shù)據(jù)流名:發(fā)票別名:

無簡述:

學生購書時填寫的專案來源:

學生去向:

加工1“審查並開發(fā)票”組成:(學號)＋姓名＋｛書號＋數(shù)量｝數(shù)據(jù)流量:1000次/周

高峰值：開學期間1000次/天

（2）數(shù)據(jù)元素詞條描述數(shù)據(jù)元素名：類型：數(shù)字（離散值，連續(xù)值），文字（編碼類型）長度：取值範圍：相關的數(shù)據(jù)元素及數(shù)據(jù)結構：數(shù)據(jù)元素詞條舉例資料項目名:貨物編號別名:G-No,G-num簡述:本公司的所有貨物的編號類型:字串長度：10取值範圍及含義:

第1位：[J｜G](進口/國產)

第2-4位：LB01..LB29(類別)

第5-7位：“A00”..“A99”(規(guī)格)

第8-10位：“001”..“999”(品名編號)（3）數(shù)據(jù)檔詞條描述數(shù)據(jù)檔案名：簡述：存放的是什麼數(shù)據(jù)輸入數(shù)據(jù)：輸出數(shù)據(jù)：數(shù)據(jù)檔組成：數(shù)據(jù)結構存儲方式：順序，直接，關鍵碼存取頻率：數(shù)據(jù)檔（存儲）詞條舉例檔案名:庫存記錄別名:無簡述:存放庫存所有可供貨物的資訊組成：貨物名稱＋編號＋生