软件工程课件

1第1章

软件工程概述1.0軟體概念軟體軟體的特點軟體發展歷程軟體概念-軟體軟體（

Software）是電腦系統中與硬體相互依存的另一部分，它是包括程式（Program）

，數據（Data）及其相關文檔（Document）的完整集合。Software=Program+Data+Document程式是按事先設計的功能和性能要求執行的指令序列數據是使程式能正常操縱資訊的數據結構文檔是與程式開發，維護和使用有關的圖文材料軟體概念-軟體的特點抽象性軟體是邏輯實體，沒有明顯的製造過程，運行和使用沒有磨損與老化問題。依存性軟體開發和運行依賴於電腦系統。工藝性軟體開發至今尚未完全擺脫手工工藝的開發方式。複雜性軟體邏輯結構、開發技術、專案管理複雜。成本高開發成本、維護成本高。風險大軟體專案的成功率低。維護難維護不能依靠原開發者，理解軟體代碼難，維護也是開發，維護成本高軟體工作涉及各種社會因素政策規章、管理思想、文化背景、資訊素養、技術水準、系統介面等。軟體的複雜性邏輯複雜軟體的邏輯結構非常複雜開發複雜成本難以估算、進度難以控制、人員素質要求、品質得不到保證成本高例：軟體成本風險大1995年美國Standish諮詢集團的統計分析(至90年代初的軟體專案執行情況)成功：16.2%失敗：31％受到挑戰：53.8%近幾年來的統計數據成功：26％失敗：28％受到挑戰：46%維護難維護形式多樣化改正性：修改故障完善性：增加功能適應性：移植維護成本越來越高55%到70％維護帶來的問題可能引發新的錯誤，經維護後邏輯結構更複雜1.1軟體危機軟體危機軟體發展歷程，軟體危機，軟體危機的表現。產生軟體危機的原因軟體特點有關，開發中的問題，維護中的問題。消除軟體危機的途徑正確認識“軟體”，重視軟體過程，採用有效的軟體開發技術和方法，引進工程管理方法。軟體發展歷程早期面向批處理有限的分佈自定義軟體第二階段多用戶即時資料庫軟體產品第三階段分佈式系統嵌入“智能”低成本硬體消費者的影響第四階段強大的桌面系統面向對象技術專家系統人工神經網路並行計算網路電腦1950196019701980199020001968年10月，北大西洋公約組織（NATO）的科學家在德國召開的學術會議上正式提出了軟體危機問題。軟體危機軟體危機是電腦軟體開發和維護過程中所遇到的一系列嚴重問題。主要包括下列兩個方面的問題：如何開發軟體，以滿足對軟體的日益增長的需求；如何維護不斷增多的已有軟體。軟體危機的典型表現對軟體開發成本和進度的估計常常很不准確；用戶對交付的軟體經常不滿意；軟體產品的品質往往達不到要求；開發出來的軟體通常難以維護；軟體產品文檔資料不適用和不完善；軟體成本在整個系統總成本中所占比例逐年上升；軟體開發生產率的提高不能滿足對軟體需求的增長；………成本問題電腦軟體和硬體費用比越來越大IBM360OS,5000多人年，耗時4年(1963－1966)，花費2億多美元美國空軍：1955年軟體占總費用(電腦系統)的18%，70年60%，85年達到85％美國全球軍事指揮控制系統，硬體1億美元，軟體高達7.2億美元軟體品質問題軟體應用面的擴大：科學計算、軍事、航空航太、工業控制、企業管理、辦公、家庭軟體越來越多的應用於安全攸關的系統，對軟體品質提出更高的要求80年代歐洲亞麗安娜火箭的發射失敗，原因是軟體錯誤美國阿托拉斯火箭的發射失敗，原因是軟體故障軟體的複雜性越來越高英國1986年開發的辦公室資訊系統Folios經4年，因性能達不到要求，1989年取消日本第5代機因為軟體問題在投入50億美元後於1993年下馬由於軟體品質問題導致失敗的軟體專案非常多專案進度問題專案進度難以控制專案延期比比皆是由於進度問題而取消的軟體專案較常見只有一小部分的專案能夠按期完成軟體維護問題軟體維護非常困難軟體維護的多樣性軟體維護的複雜性軟體維護的副作用產生軟體危機的原因與軟體本身的特點有關成本高、風險大、難於維護、邏輯複雜。軟體是電腦系統中的邏輯實體而不是物理實體，軟體生產與硬體不同，在它的開發過程中沒有明顯的製造過程。軟體是通過人們的智力活動，把知識與技術轉化成資訊的一種產品。在軟體的運行過程中，沒有“用壞”的問題。軟體維護意味著修正原來的設計，較為困難。與軟體開發與維護的方法不正確有關軟體專業人員對軟體開發和維護存在糊塗觀念，在實踐過程中採用了錯誤的方法和技術。如忽視軟體需求分析的重要性；輕視軟體維護。消除軟體危機的途徑正確認識“軟體”軟體≠程式，軟體是相關程式、數據及文檔的集合。正確認識“軟體開發”軟體開發不是個體勞動，而主要是一種有組織的團隊活動。研究軟體開發的技術手段在軟體開發中使用已證明行之有效的技術，研究和探索新的技術。更好地使用軟體工具，建立一個良好的軟體工程支撐環境。研究軟體開發的管理方法在軟體開發中使用已證明行之有效的工程管理方法。組織良好、管理嚴密，使各類人員協同配合，共同完成軟體開發的工程專案。軟體工程學的是由於“軟體危機”的出現和加重而產生的，研究用工程的方法來管理軟體的開發。開發一個具有一定規模和複雜性的軟體系統與編寫一個簡單的程式不一樣。大型、複雜軟體系統的開發是一項工程，必須按照工程化的方法組織軟體的生產和管理，必須經過分析、設計、實現、測試、維護等一系列軟體過程和活動軟體工程學的產生提出有效的方法和工具支持软件开发1968年提出軟體工程概念和思想20世紀70年代的結構化軟體開發方法20世紀80年代的面向對象的軟體開發方法新的技術:軟體重用、快速原型、需求工程典型技術:COM,Java,C++,J2EE,.Net,….支撐工具和環境：Jbuilder,VisualStudio,WebLogic,…解決危機的技術途徑20世紀80年代末，美國DoD和業界開始認識到管理的重要性美國DoD的一項研究表明，70%的專案由於管理不善導致難以控制進步、成本和品質；進一步的研究發現：管理是影響軟體專案成功開發的全局性因素，而技術只影響局部如果軟體開發組織不能對軟體專案進行有效管理，就不能充分發揮軟體開發方法和工具的潛力，也就不能高效率地開發出高質量的軟體產品解決危機的管理途徑1.2軟體工程軟體工程的概念軟體工程的基本原理軟體工程方法學軟體工程概念軟體工程是指導電腦軟體開發與維護的一門工程學科。採用工程的概念、原理、方法和技術來開發和維護軟體。將經過時間和實踐考驗而證明正確的管理方法和最好的技術手段結合起來，經濟有效地開發和維護軟體。軟體工程是一門不斷發展的學科。軟體工程定義(FritzBauer,1968)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

軟體工程就是建立和使用一套合理的工程原理，從而經濟地獲得可靠的、可以在實際機器上高效運行的軟體。軟體工程定義(IEEE,1990)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1990.）

軟體工程是：（1）把系統的、規範的、可度量的途徑應用於軟體開發、運行和維護過程，也就是把工程應用於軟體；（2）研究（1）中提到的途徑。軟體工程定義(CMU/SEI,1990)

Engineeringisthe

systematicapplicationofscientificknowledge

increatingandbuildingcost-effectivesolutionstopracticalproblemsintheserviceofmankind.

Softwareengineeringisthat

formofengineering

thatappliestheprinciplesofcomputerscienceandmathematics

toachievingcost-effectivesolutionstosoftwareproblems.SEIsoftwareengineeringdefinitionfrom1990SEIReportonUndergraduateSoftwareEngineeringEducation(CMU/SEI-90-TR-003):軟體工程定義軟體工程是應用電腦科學、數學及管理科學等原理開發軟體的工程。它採用經過實踐驗證的工程的原則、方法，以提高品質，降低成本為目的。軟體工程的本質特性關注於大型程式的構造控制軟體複雜性適應軟體的經常變化性提高軟體開發的效率和諧合作開發軟體使軟體有效地支持它的用戶需求軟體是有一種文化背景的人為另一種文化背景的人開發的產品。軟體工程的基本原理用分階段的生命週期計畫嚴格管理堅持進行階段評審實行嚴格的產品控制採用現代程式設計技術結果應能清楚地審查開發小組的人員應該少而精承認不斷改進軟體工程實踐的必要性軟體工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工程學科。通常把在軟體生命週期全過程中使用的一整套技術方法的集合稱為軟體工程方法學(methodology)，也稱為範型(paradigm)。軟體工程方法學軟體工程方法學三要素軟體工程方法學包含3個要素：方法、工具和過程。方法完成軟體開發各項任務的技術方法。工具為運用方法而提供的軟體工程支撐環境（支撐分析、設計、開發等）。過程規定了完成軟體開發各項任務的工作步驟。傳統軟體工程方法學傳統軟體工程方法學是生命週期方法學軟體生命週期一個軟體定義、開發、使用和維護，直到最終被廢棄，要經歷的漫長的時期，稱為軟體的生命週期。生命週期方法學這種方法學把軟體生命週期的全過程依次劃分為若干個階段，然後順序地完成每個階段的任務。2面向對象方法學面向對象主要概念對象、類、繼承、消息等。面向對象方法學這種方法學把數據和行為看成同等重要，它是一種以數據為主線，把數據和對數據的操作緊密結合起來的方法1.3軟體生命週期軟體生命週期概念軟體生命週期模型軟體生命週期各階段任務常見的軟體工程方法學（幾大公司）軟體生命週期概念軟體生命週期基本階段軟體生命週期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又可劃分若干個階段。生命週期方法學軟體工程採用的生命週期方法學就是從時間角度對軟體開發和維護的複雜性進行分解，把軟體生存的漫長週期依次劃分為若干個階段，每個階段都有獨立的任務，然後逐步完成每個階段的任務。劃分軟體生存週期階段的基本原則使各階段的任務之間盡可能相互獨立，同一個階段各項任務的性質盡可能相同，從而降低每個階段任務的複雜程式，簡化不同階段之間的聯繫，有利於軟體開發工程的組織管理。1.4軟體生命週期模型

問題定義軟體定義可行性研究

需求分析

總體設計軟體生命週期軟體開發 詳細設計

編碼和單元測試（實現）

綜合測試 運行維護

軟體維護軟體生命週期基本階段的任務（1）軟體定義時期總目標的確定，可行性，採用策略，系統功能，所需資源與成本，工程進度表，也稱為系統分析時期，分為所定義，可行性研究和需求分析。（2）開發時期具體設計和實現前面所定義的軟體。分為：總體設計，詳細設計，編碼和單元測試，綜合測試。（3）維護時期使軟體儘量地滿足用戶需要，糾錯，適應新環境，滿足新需求軟體生命週期的階段1.問題定義要解決的問題是什麼？2.可行性研究問題能夠解決嗎？3.需求分析為了解決問題需要做什麼？4.總體設計為了解決問題，大概怎樣做？5.詳細設計為了解決問題，具體怎樣做？6.編碼和單元測試編程實現，並測試每一個程式模組，驗證程式達到設計要求。7.綜合測試集成測試、壓力測試、驗收測試，驗證系統滿足需求。8.軟體維護改正性維護、適應性維護、完善性維護、預防性維護，保障系統持久性滿足用戶的要求。問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟體維護要解決的問題是什麼？問題性質、工程目標和規模的報告分析員：實際用戶+負責人是否有解決辦法？分析員高層邏輯模型，準確和具體的工程規模和目標，成本/效益分析等可行性報告為了解決的問題，目標系統必須做什麼？準確確定系統的功能系統的邏輯模型（數據流圖+數據字典+簡要演算法）如何解決這些問題模組劃分軟體結構如何具體地實現系統：每個模組的流程圖（程式的詳細規格說明）通過各種類型的測試，使軟體達到預定的要求寫出正確的容易理解和容易維護的程式模組通過各種必要的維護活動使系統持久地滿足用戶的需要軟體生命週期的各階段任務軟體工程層次模型軟體工程：一種層次化模型品質關注點過程方法工具

軟體工程層次圖軟體工程三個要素：工具、方法、過程基礎層，綜合方法及工具，定義方法使用的順序，所需要的管理為軟體開發提供“如何做”的技術為軟體開發提供自動或半自動的軟體支撐環境，建立電腦輔助軟體工程(CASE)的軟體開發支撐系統軟體工程擴展模型軟體工程方法學例ALM（ApplicationLifecycleManagement，應用生命週期管理）MSF（MicrosoftSolutionFramework，微軟方案框架)RUP（RationalUnifiedProcess，統一軟體過程

）OOA/OOD/OOPOOA

(Object-OrientedAnalysis面向對象分析)分析師拿到所有來自客戶的需求了；瞭解需求，分析需求、技術實現等，分析出來一個方案，即專案需求。分析師們分析結果出來後，形成了最早的需求模型，包括可行性報告、需求分析報告、系統模型、草圖等。OOD(ObjectOrientedDesign面向對象設計)設計師們拿到需求模型進行細化，模組化，定義所有的細節，設計軟體的詳圖，這裏就是詳細的需求分析規格書和具體的設計文檔。OOP(ObjectOrientedProgramming面象對象程式設計)程式員按照設計圖的要求完成專案的實際操作部分，在專案裏就是coding的工作和testing的工作。1.4軟體過程軟體過程是為了獲得高質量的軟體需要完成的一系列任務的框架，規定了完成各項任務的工作步驟。AprocessdefinesWhoisdoingWhat,When,andHow,inordertoreachacertaingoal.軟體過程定義了軟體工程的階段、應用方法的順序、應交付的文檔、保證軟體品質的措施、標誌軟體開發各階段的里程碑。軟體過程框架模型軟體過程是為了獲得高質量軟體所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。工作任務里程碑、交付物SQA(軟體品質保障)點公共過程框架輔助活動框架活動任務集合軟體過程模型軟體生命週期的每一階段都有明確的任務，把規模大、結構複雜、管理複雜的軟體開發變得容易控制和管理。各個階段的活動如何銜接，開發過程中採用什麼樣的策略，應遵守什麼樣的規定和制約，將這些活動框架（忽略不必要的細節）用一種模型表示出來，稱為軟體過程模型（或軟體開發模型或軟體生命週期模型）。軟體過程模型是軟體開發全部過程、活動和任務的結構框架。常用軟體過程模型（1）瀑布模型(WaterfallModel）（2）快速原型模型(RapidPrototypeModel)（3）增量模型(IncrementalModel)（4）螺旋模型(SpiralModel)（5）面向對象模型（噴泉模型、可重用組件模型）（6）統一軟體開發過程（IBMRUP）（7）敏捷(靈活)過程與極限編程（8）微軟過程（MicrosoftSolutionFramework）（1）瀑布模型(WaterfallModel)傳統瀑布模型評審評審評審評審評審瀑布模型問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟體維護軟體定義時期軟體開發時期軟體維護時期瀑布模型的特點階段間具有順序性和依賴性提供了軟體過程模型的基本框架,強調了每一階段活動的嚴格順序。前一階段產品（文檔）驅動下一階段的工作。推遲實現的觀點程式的物理實現集中在開發階段的後期，用戶在最後才能看到自己的產品。品質保證的觀點每一個階段必須完成規定的文檔；以評審確認階段工作，即上一階段的結束，下一階段的開始。傳統瀑布模型存在什麼問題？改進的瀑布模型及時回饋：開發時儘早知道上一階段的錯誤。維護分類：根據軟體維護的內容和程度，確定維護的階段。評審評審評審評審評審回饋回饋回饋回饋軟體維護瀑布模型的優缺點瀑布模型適合於用戶需求明確、完整、無重大變化的軟體專案開發。瀑布模型的成功在很大程度上是由於它基本上是一種文檔驅動的模型。“瀑布模型是由文檔驅動的”，這個事實是它的一個主要缺點。實際專案很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統開發完成。（2）快速原型模型

(RapidPrototypeModel)在用戶不能給出完整、準確的需求說明，或者開發者不能確定演算法的有效性、操作系統的適應性或人機交互的形式等許多情況下，可以根據用戶的一組基本需求，快速建造一個原型（可運行的軟體），然後進行評估，進一步精化、調整原型，使其滿足用戶的要求，也使開發者對將要做的事情有更好的理解。建造/修改原型

聽取用戶意見用戶測試運行原型原型實現範型快速原型模型快速原型法是一種新型的軟體開發方法，它使用交互的，快速建立起來的原型取代了形式的、僵硬的大量的規格說明，用戶通過在電腦上實際運行和試用原型系統而向開發者提供真實的回饋意見。建立原型系統修改原型符合用戶需要的應用系統用戶試用回饋意見快速原型模型快速原型驗證規格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證維護過程開發過程採用不帶回饋的瀑布模型，進行快速開發和修改。原型系統提交用戶評測，反復修改，直到用戶滿意。原型模型存在的問題⑴為了使原型儘快的工作，沒有考慮軟體的總體品質和長期的可維護性。⑵為了演示，可能採用不合適的操作系統、編程語言、效率低的演算法，這些不理想的選擇成了系統的組成部分。

⑶開發過程不便於管理。有效的使用原型模式建造原型僅是為了定義需求，之後就被拋棄（或被部分拋棄），實際的軟體在充分考慮了品質和可維護性之後才被開發。3）增量模型(IncrementalModel)是一種漸進地開發逐步完善的軟體版本的模型。需求分析驗證規格說明驗證設計驗證維護針對每個構件完成詳細設計、編碼和集成，經測試後交付給用戶需求分析一步到位；功能模組作為增量逐步交付。增量模型分析分析分析分析設計設計設計設計編碼編碼編碼編碼測試測試測試測試增量1增量2增量3增量4交付交付交付交付●●●●●反復地應用瀑布模型的基本成分和原型模型的迭代特徵，每一個線型過程產生一個“增量”的發佈或提交，該增量均是一個可運行的產品。早期的版本實現用戶的基本需求，並提供給用戶評估的平臺。需求作為增量逐步交付。增量模型的優點在較短時間內向用戶提交可完成部分工作的產品，並分批、逐步地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。整個軟體產品被分解成許多個增量構件，開發人員可以一個構件一個構件地逐步開發。逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟體可能給客戶組織帶來的衝擊。採用增量模型比採用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。增量模型的困難在把每個新的增量構件集成到現有軟體體系結構中時，必須不破壞原來已經開發出的產品。此外，必須把軟體的體系結構設計得便於按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟體體系結構必須是開放的。開發人員既要把軟體系統看作整體。又要看成可獨立的構件，產生觀念上的矛盾。多個構件並行開發，具有集成的風險。4）螺旋模型(SpiralModel)軟體風險是任何軟體開發專案中都普遍存在的實際問題，專案越大，軟體越複雜，承擔該專案所冒的風險也越大。

對於複雜的大型軟體，開發一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結合起來，加入了風險分析。在該模型中，軟體開發是一系列的增量發佈，早期的迭代中，發佈的增量可能是一個紙上的模型或原型，在以後的迭代中，逐步產生系統更加完善的版本。螺旋模型的基本思想是降低風險。簡單的螺旋模型快速原型驗證規格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證風險分析風險分析風險分析風險分析風險分析風險分析可看作在每個階段之前都增加了風險分析過程的快速原型模型。每一個階段都可能存在不同的風險！完整的螺旋模型原型版本當前進度

螺旋模型風險分析工程實施用戶交流用戶評估產品維護專案產品增強專案新產品開發專案概念開發專案計畫建造及發佈螺旋模型的優點和特點螺旋模型的優點對可選方案和約束條件的強調有利於已有軟體的重用，也有助於把軟體品質作為軟體開發的一個重要目標減少了過多測試或測試不足維護和開發之間並沒有本質區別螺旋模型的特點風險驅動，需要相當豐富的風險評估經驗和專門知識，否則風險更大主要適用於內部開發的大規模軟體專案，隨著過程的進展演化，開發者和用戶能夠更好的識別和對待每一個演化級別上的風險隨著迭代次數的增加，工作量加大，軟體開發成本增加（5-1）面向對象-噴泉模型噴泉模型(FountainModel)是面向對象模型。主要用於支持面向對象開發過程，體現了軟體創建所固有的迭代和無間隙的特徵分析設計實現測試集成演化（5-2）面向對象-構件集成模型

(ComponentIntegrationModel)

構件（components)也稱為組件，是一段實現一系列有確定介面的程式體，具有自己的功能和邏輯，能同其他構件集成起來協調工作。該模型（又稱為可重用部件組裝模型）支持軟體重用（Reusability）

，對縮短軟體開發週期、降低專案成本有重要的現實意義。同時，建造符合某應用領域體系結構標準的構件，可以用來搭建分佈式的、跨越不同操作平臺(集成化軟體開發環境（ISEE）)的軟體，擴展了軟體的應用前景，促進了軟體標準化、商品化的發展。在此基礎上專家們又提出了“基於構件的軟體工程”(CBSE)。構件集成模型

構件集成模型軟體體系結構被建立後，必須用構件去充實，這些構件可從複用庫中獲得，或者根據專門需要而開發。整個過程可以演化地進行，面向對象方法給予技術上的支持。構件集成模型Sommerville提出基於組件開發有兩種思路：完成高層設計，對設計中的組件給出描述，以便找出可複用的組件，這些組件可在體系結構層次上加入或更詳細的設計層次上加入。先根據需求搜尋可複用組件，再將設計建立在獲得的組件基礎上。這兩種思路可結合起來。設計系統體系結構描述組件搜尋可複用組件集成系統先完成架構設計的複用系統需求描述搜尋可複用組件對需求作某些修改體系結構設計集成系統複用驅動設計構件技術主要有三種流行標準對象管理組織OMG的CORBA微軟的COM/DCOMSUN的EJB(EnterpriseJavaBean)OMG的CORBA對象管理組織OMG發佈的公用對象請求代理體系結構(CommonObjectRequestBrokerArchitecture)。通過一個對象請求代理（ORB)提供一系列服務，使得一個構件和其他構件通信，而不管它們在系統中的位置，實現了遠程對象通過介面進行通信的機制。為了解決CORBA對象引用不透明、缺少多重介面、系統過於複雜等問題，專家們又開發了新一代面向對象中間件平臺ICE（InternetCommunicationsEngine—互聯網通信引擎）。使構建分佈式應用系統更容易、性能和伸縮性更好。微軟的COM/DCOMCOM微軟提出、開發的構件對象模型（ComponentObjectModel)，它提供了運行於windows之上的單個應用系統使用不同廠商生產的構件的規約。DOM基於分佈式環境下的COM稱為DCOM(DistributeCOM)。SUN的EJB(EnterpriseJavaBean)隨著Java在企業級應用的地位日趨重要，Sun提出了一個統一的企業級Java平臺—J2EE（Java2EnterpriseEdition）。在J2EE中，EJB負責最核心的業務處理。它為伺服器端的應用程式提供了一種與廠商無關的Java介面，讓任何符合EJB規範的構件都可以運行在每一臺這樣的伺服器上。（6）統一軟體開發過程統一軟體開發過程（RationalUnifiedProcess，RUP)是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟體過程模型。RUP重複一系列週期，每個週期由一個交付給用戶的產品結束。每個週期劃分為初始、細化、構造和移交四個階段，每個階段圍繞著五個核心工作流（需求、分析、設計、實現、測試）分別迭代。RUP的“最佳實踐”軟體開發經驗迭代式開發按照原型模型，迭代開發產品，獲取用戶的回饋意見，加深對需求的理解，逐步趨向最終產品。管理需求人為需求分析是一個連續過程，使用有效的方法（如用例和腳本）捕獲用戶變化的需求，以驅動設計與實現。使用基於構建的體系結構提供使用現有構建和新開發構件定義體系結構的方法，採用構建來建造系統，從而減低軟體複雜性，提供軟體重用率。可視化建模採用可視化建模語言（UML）描述系統模型。驗證軟體品質建立貫穿整個開發過程的、全員參與的軟體品質評估方法。控制軟體變更控制、跟蹤和監控軟體的修改，確保迭代開發的成功。RUP軟體開發生命週期RUP初始階段：進行問題定義，確定目標，評估其可行性，降低關鍵風險。細化階段：制定專案計畫、配置各類資源、建立系統架構（包括各類視圖）。構造階段：開發整個產品，並確保產品可移交給用戶。移交階段：產品發佈、安裝、用戶培訓。在每個階段的每次迭代的最後，用例模型、分析模型、設計模型、實現模型都會增量，每個階段結束的里程碑處，管理層做出是否繼續、進度、預算、是否給下一階段提供資助等決定。不同階段工作流的側重點不同，前兩階段大部分工作集中在需求、分析和架構設計上；在構造階段，重點轉移到詳細設計、實現和測試上。（7）敏捷過程與極限編程2001年，為了解決許多公司的軟體團隊陷入不斷增長的過程泥潭，一批業界著名專家一起概括出了一些可以讓軟體開發團隊具有快速工作、回應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法很多，主要有：SCRUM，Crystal,特徵驅動軟體開發（FeatureDrivenDevelopment，簡稱FDD），自適應軟體開發(AdaptiveSoftwareDevelopment，簡稱ASD)，以及最重要的極限編程(eXtremeProgramming,簡稱XP)。極限編程(XP)是於1998年由Smalltalk社群中的大師級人物KentBeck首先宣導的。觀點在按照我的理解方式審查了軟體開發的生命週期後，我得出一個結論：實際上滿足工程設計標準的惟一軟體文檔，就是源代碼清單。--JackReeves設計和編程都是人的活動。忘記這一點，將會失去一切。--BjarneStroustrup敏捷過程敏捷軟體開發宣言個體和交互 勝過 過程和工具可以工作的軟體 勝過 面面俱到的文檔客戶合作 勝過 合同談判回應變化 勝過 遵循計畫敏捷宣言遵循的原則我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支持，並且信任他們能夠完成工作。在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。工作的軟體是首要的進度度量標準。敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。不斷地關注優秀的技能和好的設計會增強敏捷能力。簡單是最根本的。最好的構架、需求和設計出於自組織團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。敏捷過程認為的軟體設計“壞味道”僵化性很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其他改動。脆弱性對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。牢固性很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。粘滯性做正確的事情比做錯誤的事情要困難。不必要的複雜性設計中包含有不具任何直接好處的基礎結構。不必要的重複性設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。晦澀性很難閱讀、理解。沒有很好地表現出意圖。敏捷開發避免“軟體腐化味”的

面向對象的設計原則單一職責原則(SRP)：一個類應該僅有一個引起它變化的原因。開放-封閉原則(OCP)：軟體實體應該是可以擴展的，但是不可修改。Liskov替換原則(LSP)：子類型必須能夠替換掉它們的基類型。依賴倒置原則(DIP)：抽象不應該依賴於細節。細節應該依賴於抽象。介面隔離原則(ISP)：不應該強迫客戶依賴於它們不用的方法。介面屬於客戶，不屬於它所在的類層次結構。重用發佈等價原則(REP)：重用的粒度就是發佈的粒度。共同封閉原則(CCP)：包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對於其他的包不造成任何影響。共同重用原則(CRP)：一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。無環依賴原則(ADP)：在包的依賴關係圖中不允許存在環。穩定依賴原則(SDP)：朝著穩定的方向進行依賴。穩定抽象原則(SAP)：包的抽象程度應該和其穩定程度一致。極限編程極限編程(eXtremeProgramming，XP)是敏捷過程中最有名的一個,適於小型專案。極限編程對於傳統的軟體工程中看來是“極端的”實踐.極限編程的有效實踐1、完整團隊XP專案的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。2、計畫遊戲計畫是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。3、客戶測試作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。4、簡單設計團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。5、結對編程所有的產品軟體都是由兩個程式員、並排坐在一起在同一臺機器上構建的。6、測試驅動開發編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的回饋迴圈，尤其是功功能能驗證方面的回饋迴圈。程式員以非常短的迴圈週期工作，他們先增加一個失敗的測試，然後使之通過。極限編程的有效實踐7、改進設計隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的乾淨、具有表達力。8、持續集成團隊總是使系統完整地被集成。一個人拆入（Checkin）後，其他所有人責任代碼集成。9、集體代碼所有權任何結對的程式員都可以在任何時候改進任何代碼。沒有程式員對任何一個特定的模組或技術單獨負責，每個人都可以參與任何其他方面的開發。10、編碼標準系統中所有的代碼看起來就好像是被單獨一人編寫的。11、隱喻將整個系統聯繫在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。12、可持續的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把專案看作是馬拉松長跑，而不是全速短跑。XP專案的整體開發過程XP迭代開發過程XPvaluesCommunicationSimplicityFeedbackCourageRespect（8）微軟過程Microsoft解決方案框架(MSF)是一種成熟的、系統的技術專案方法，它基於一套制定好的原理、模型、準則、概念、指南，以及來自Microsoft的、經過檢驗的做法。MSF提供了一個靈活的和可伸縮的框架，其適應能力能夠滿足任何專案（不論其規模和複雜性）的要求，以規劃、構建和部署業務驅動的技術解決方案。MSF的觀點是，沒有哪個單一的結構或者過程能夠適應所有專案的環境和要求。儘管如此，但是它也認為：對指導的需求是存在的。作為一個框架，MSF就提供了這樣一種指導，而不會強迫實施很多限制性的細節，否則這只會將其用處限制到有限範圍的專案方案裏。微軟軟體生命週期階段劃分和主要里程碑微軟過程的生命週期模型94/27內容摘要基於電腦的系統系統工程的任務可行性分析95/27內容摘要基於電腦的系統系統工程的任務可行性分析96/27

所謂基於電腦的系統是指：通過處理資訊來完成某些預定義目標而組織在一起的元素的集合或排列。組成基於電腦系統的元素主要有：軟體、硬體、人員、資料庫、文檔和規程（Procedure）基於電腦的系統97/27系統元素軟體—指電腦程式、數據結構和相關的工作產品，以實現所需要的邏輯方法、規程或控制硬體—指提供計算能力的電子設備、支持數據流的互連設備（如網路交換器、電信設備）和提供外部世界功能的電子機械設備（如感測器、馬達等）人員—指硬體和軟體的用戶和操作者98/27資料庫—指通過軟體訪問並持久存儲的大型的有組織的資訊集合。文檔—指描繪系統的使用和/或操作的描述性資訊（如模型、規格說明、硬複製手冊、聯機幫助檔、Web站點）。規程（procedures）—指定義每個系統元素的特定使用或系統所處的過程性語境的步驟。99/27系統的層次結構基於電腦的系統本身可以成為一個更大的基於電腦系統中的一個元素，稱其為那個更大系統的宏元素。這樣，基於電腦的系統可呈現一個層次結構。100/27工廠自動化

系統101/27內容摘要基於電腦的系統系統工程的任務可行性分析102/27電腦系統工程電腦系統工程是一個問題求解的活動，其目的是分析基於電腦的系統的功能、性能等要求，並把它們分配到基於電腦系統的各個系統元素中，確定它們的約束條件和介面。

103/27系統工程的任務識別用戶的要求標識系統的功能和性能範圍，確定系統的功能、性能、約束和介面。104/27系統建模和模擬通常可考慮建立如下模型：硬體系統模型：描述基於電腦系統中的硬體（包括電腦、受系統控制的其他硬體設備等）配置、通信協議、拓撲結構、以及確保基於電腦系統的安全性、可靠性、性能等要求的措施。軟體系統模型：描述各軟體子系統的功能、性能等要求，它們在硬體系統中的部署情況，以及軟體子系統之間的交互。人機介面模型：描述人如何與基於電腦的系統進行交互，包括用戶環境、用戶的活動、人機交互的語法和語義等。數據模型：描述基於電腦的系統使用了哪些資料庫管理系統，如果使用多個數據庫管理系統，還應描述它們之間的數據轉換方式，必要時可給出主要的數據結構。105/27系統模型通常可用圖形描述，並加以相應的文字說明。必要時，在系統建模後可構造原型，進行系統模擬，以分析所建的模型能否滿足整個基於電腦的系統的要求。106/27成本估算及進度安排對將開發的基於電腦的系統進行成本估算，並作出進度安排。可行性分析從經濟、技術、法律等方面分析所給出的解決方案是否可行，通常只有當解決方案可行並有一定的經濟效益和/或社會效益時才開始真正的基於電腦的系統的開發。生成系統規格說明107/27內容摘要基於電腦的系統系統工程的任務可行性分析108/27可行性分析開發一個基於電腦的系統通常都受到資源（人力、財力、設備等）和時間上的限制，可行性分析主要從經濟、技術、法律等方面分析所給出的解決方案是否可行，能否在規定的資源和時間的約束下完成。109/27經濟可行性分析經濟可行性主要進行成本效益分析，從經濟角度，確定系統是否值得開發。基於電腦的系統的成本主要包括：購置硬體、軟體（如數據庫管理系統、第三方開發的構件等）和設備（如感測器等）的費用系統的開發費用系統安裝、運行和維護費用人員培訓費用110/27效益經濟效益包括使用基於電腦的系統後可增加的收入和可節省的運行費用（如操作人員數、工作時間、消耗的物資等）。在進行成本效益分析時通常只統計五年內的經濟效益。社會效益指使用基於電腦的系統後對社會產生的影響（如提高了辦事效益，使用戶滿意等），通常社會效益只能定性地估計。經濟效益通常可用貨幣的時間價值、投資回收期和純收入來度量。111/27貨幣的時間價值設：當前金額為P，年利率為i，n年後的金額為F，則計算時，累計經濟效益應折合成當前金額例如，一個基於電腦的系統使用後，每年產生的經濟效益為10萬，如果年利率為5%，那麼，五年內該系統的累計經濟效益是43．2948萬，而不是50萬。112/27投資回收期：累計的經濟效益正好等於投資數（成本）所需的時間。純收入：累計經濟效益–

投資數當純收入大於零時，該工程值得投資開發當純收入小於零時，該工程不值得投資（除非它有明顯的社會效益）當純收入等於零時，通常也不值得投資顯然，純收入越大越好。113/27技術可行性分析技術可行性主要根據系統的功能、性能、約束條件等，分析在現有資源和技術條件下系統能否實現。技術可行性分析通常包括風險分析、資源分析和技術分析。114/27風險分析：分析在給定的約束條件下設計和實現系統的風險。採用不成熟的技術可能造成技術風險人員流動可能給專案帶來風險成本和人員估算不合理造成的預算風險風險分析的目的是找出風險，評價風險的大小，並有效地控制和緩解風險。115/27資源分析：論證是否具備系統開發所需的各類人員、軟體、硬體等資源和相應的工作環境。例如，有一支開發過類似專案的開發和管理的團隊，或者開發人員比較熟悉系統所處的領域，並有足夠的人員保證，所需的硬體和支撐軟體能通過合法的手段獲取，那麼從技術角度看，可以認為具備設計和實現系統的條件。116/27技術分析：分析當前的科學技術是否支持系統開發的各項活動。在技術分析過程中，分析員收集系統的性能、可靠性、可維護性和生產率方面的資訊，分析實現系統功能、性能所需的技術、方法、演算法或過程，從技術角度分析可能存在的風險，以及這些技術問題對成本的影響。技術可行性分析時通常需進行系統建模，必要時可建造原型和進行系統模擬117/27法律可行性分析研究系統開發過程中可能涉及到的合同、侵權、責任以及各種與法律相抵觸的問題。1990年我國頒佈了《中華人民共和國著作權法》，其中將電腦軟體作為著作權法的保護對象。1991年國務院頒佈了《電腦軟體保護條例》。這兩個法律檔是法律可行性分析的主要依據。118/27方案的選擇和折衷一個基於電腦的系統可以有多個可行的實現方案，每個方案對成本、時間、人員、技術、設備都有不同的要求，不同方案開發出來的系統在功能、性能方面也會有所不同。因此要在多個可行的實現方案中作出選擇。方案評估的依據是待開發系統的功能、性能、成本、開發時間、採用的技術、設備、風險以及對開發人員的要求等。由於系統的功能和性能受到多種因素的影響，某些因素之間相互關聯和制約。如，為達到高的精度就可能導致長的執行時間，為達到高可靠性就會導致高的成本等等。因此，在必要時應進行折衷。119/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理120/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理121/42AlanDavis把需求工程定義為“直到（但不包括）把軟體分解為實際架構構件之前的所有活動”

HerbKrasner定義了需求工程的五階段生命週期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理MatthiasJarke和KlausPohl提出了三階段週期的說法：獲取、表示和驗證…

…122/42本書將軟體需求工程細分為：需求獲取、需求分析與協商、系統建模、需求規約、需求驗證和需求管理六個階段。123/42需求獲取系統分析人員通過與用戶的交流、對現有系統的觀察及對任務進行分析，確定系統或產品範圍的限制性描述、與系統或產品有關的人員及特徵列表、系統的技術環境的描述、系統功能的列表及應用於每個需求的領域限制、一組描述不同運行條件下系統或產品使用狀況的應用場景以及為更好地定義需求而開發的任意原型。需求獲取的工作產品為進行需求分析提供了基礎124/42需求分析與協商

需求獲取結束後，分析活動對需求進行分類組織，分析每個需求其他需求的關係來，檢查需求的一致性、重疊和遺漏的情況，並根據用戶的需要對需求進行排序。在需求獲取階段，經常出現以下問題：用戶提出的要求超出軟體系統可以實現的範圍或實現能力；不同的用戶提出了相互衝突的需求125/42系統建模

建模工具的使用在用戶和系統分析人員之間建立了統一的語言和理解的橋樑，同時系統分析人員借助建模技術對獲取的需求資訊進行分析，排除錯誤和彌補不足，確保需求文檔正確反映用戶的真實意圖。常用的分析和建模方法有面向數據流方法、面向數據結構方法和麵向對象的方法。126/42需求規約軟體需求規約是分析任務的最終產物，通過建立完整的資訊描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟體的各種需求。需求規約作為用戶和開發者之間的一個協議，在之後的軟體工程各個階段發揮重要作用。127/42需求驗證作為需求開發階段工作的復查手段，需求驗證對功能的正確性、完整性和清晰性，以及其他需求給予評價。為保證軟體需求定義的品質，評審應以專門指定的人員負責，並按規程嚴格進行。128/42在實際的開發過程中，獲取、分析、建模、編寫規約和驗證這些需求開發活動不會是線性地、順序地完成。實際上，這些活動是交叉的、遞增的和反復的。129/42需求管理需求工程包括獲取、分析、規定、驗證和管理軟體需求，而“軟體需求管理”則是對所有相關活動的規劃和控制。換句話說，需求管理就是：一種獲取、組織並記錄系統需求的系統化方案，以及一個使用戶與專案團隊對不斷變更的系統需求達成並保持一致的過程。130/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理131/42軟體需求包括功能需求性能需求用戶或人的因素環境需求介面需求文檔需求數據需求資源使用需求安全保密要求可靠性需求軟體成本消耗與開發進度需求其他非功能性要求

132/42需求獲取方法與策略建立順暢的通信途徑訪談與調查觀察用戶操作流程組成聯合小組用況（UseCase）133/42建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對問題進行分析。134/42訪談與調查在具體的實踐中，通常採用折衷的方法，即適當地計畫好面談，但不要過於詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提問的問題應該循序漸進，從整體的方面開始提問，接下來的問題應有助於對前面的問題更好的理解和細化；不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題；提問和回答在匯總後應能夠反映用戶需求的全貌。135/42例子：“賽艇比賽成績計算系統”的第一次面談的準備計畫初次與Dartchurch航行俱樂部的航行秘書（DR）接觸，面談有關事宜。(在電話交談時，瞭解到他們希望得到的是一個“價廉”的，基於PC的系統，以用於計算賽艇比賽成績)時間：2005-6-5地點：對方場地主要問題確定基本問題。確定DR的角色――還涉及其他人員嗎？調查財物方面事宜。系統（大致上）是如何運作的？當前存在的問題是什麼？他們都希望做些什麼？136/42觀察用戶操作流程到用戶的實際工作環境中對用戶的工作流程進行觀察，瞭解用戶實際的操作環境、操作過程和操作要求，對照用戶提交的問題陳述，對用戶需求可以有更全面、更細緻的認識。137/42組成聯合小組便利的應用規約技術(FacilitatedApplicationSpecificationTechniques,FAST)

：打破用戶（需方）和開發者（供方）的界限，共同組成一個聯合小組，發揮各自的長處，共同負責專案的推進，這樣有助於發揮各自優勢並增進解和協調138/42FAST基本原則在中立的地點舉行由開發者和用戶出席的會議；建立準備和參與會議的規則；建議一個足夠正式的議程以便可以進行自由的交流；一個“協調者”(他可以是用戶、開發者或其他外人)來控制會議；使用一種“定義機制”(它可以是工作表、圖表、牆上膠黏紙或牆板)；目標是標識問題、提出解決方案的要素、商議不同的方法、以及在有利於完成目標的氛圍中刻畫出初步的需求。139/42FAST會議步驟1) 當舉行了開發者和用戶之間的初步訪談後，確定一個FAST會議的時間地點，並在會議日之前將產品請求發佈給所有的與會者。2) 要求每個FAST出席者會前列出一組圍繞系統環境的對象，以及對這些對象的操作或對象之間的交互功能，並開發出約束列表(如，成本、規模大小、權重)和性能標準列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個人對系統的感覺。3) 進行FAST會議時，當團隊的每個成員提出單個列表後，整個團隊將創建一個組合的列表，該組合列表刪去冗餘項，並加入在表達過程中出現的新思想。在建好所有主題的組合列表後，開始討論活動。縮短、加長或重新組合列表以適當地反映將被開發的產品。140/42FAST會議步驟(續)4) 一旦創建了意見一致的列表，應該將團隊分為更小的小組，每個小組力圖為每個列表中的一個或多個項開發出小型的規約（即對包含在列表中的單詞或短語的精細化）。每個小組然後將他們開發的每個小規約提交給所有的FAST出席者討論，進行添加、刪除或進一步的精化等工作。（在所有討論過程中，團隊可能提出某些不能在會議過程中解決的問題，此時要保留問題列表以使這些思想在以後的活動中產生作用。）5) 在小規約完成後，每個FAST的出席者提出一個針對產品的確切標準列表，並將該列表提交給團隊，然後創建一個意見一致的確定的標準列表。這個列表作為需求獲取的結果，為需求分析和建模提供基礎資訊。141/42用況（UseCase）當需求作為非正式會議、Fast的一部分而收集起來之後，分析員就可以創建一組標識一串待建造系統的使用場景。創建用況模型的主要步驟如下：確定誰會直接使用該系統，即參與者（Actor）選取其中一個參與者定義該參與者希望系統做什麼，參與者希望系統作的每件事將成為一個用況對每件事來說，何時參與者會使用系統，通常會發生什麼，這就是用況的基本過程描述該用況的基本過程142/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理143/42需求分析原則1．必須能夠表示和理解問題的資訊域2．必須能夠定義軟體將完成的功能3．必須能夠表示軟體的行為(作為外部事件的結果)4．必須劃分描述數據、功能和行為的模型，從而可以分層次地揭示細節5．分析過程應該從要素資訊移向細節資訊144/42資訊域資訊域：包括資訊內容、資訊流、以及資訊結構。資訊內容表示了單個數據和控制對象，目標軟體所有處理的資訊集合由它們構成。例如，數據對象“工資”是一組重要數據體的組合：領款人的姓名、淨付款數、付款總額、扣除額等等145/42資訊流表示了數據和控制在系統中流動時的變化方式，輸入對象被變換為中間資訊(數據和/或控制)，然後進一步被變換為輸出資訊結構表示了各種數據和控制項的內部組織數據或控制項將被組織為n維表還是樹形結構？在結構的語境內，什麼資訊是和其他資訊相關的？資訊包含在單個結構中，還是使用不同的結構？在某資訊結構中的資訊如何和在另一個結構中的資訊相關？146/42抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關係首先關注一般問題的解決途徑，進而指導特殊問題的解決方法。147/42問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。較大規模或較為複雜的問題可以被分解為若干子問題進行理解和分析分解可以逐級進行，直至子問題被分解為一個容易分析理解的部分例如橫向分解縱向分解148/42需求協商協商的過程就是討論需求衝突，找出每個人都滿意的折衷方案協商不是簡單的邏輯或技術上的爭論要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉移③組織文化④組織管理態度和士氣⑤部門差異149/42通常會議是解決衝突最快的方式參加者應該包括發現衝突、遺漏或重疊的分析員，以及可以解決發現的問題的專案相關人員會議應該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段150/42需求建模在軟體需求分析階段，所創建的模型，要著重於描述系統要做什麼，而不是如何去做目標軟體的模型不應涉及軟體實現細節151/42常用的分析方法：面向數據流的結構化分析方法(SA)面向數據結構的分析方法面向對象的分析方法(OOA)152/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理153/42需求規約的原則1． 從現實中分離功能，即描述要“做什麼”而不是“怎樣實現”。2． 要求使用面向處理的規約語言（或稱系統定義語言），討論來自環境的各種刺激可能導致系統做出什麼樣的功能性反應，來定義一個行為模型，從而得到“做什麼”的規約。3． 如果被開發軟體只是一個基於電腦的系統中的一個元素，那麼整個大系統也包括在規格說明的描述之中。4． 規約必須包括系統運行環境。154/42需求規約的原則(續)5． 規約必須是一個認識模型，而不是設計或實現的模型。6． 規約必須是可操作的，以便能夠利用它決定對於任意給定的測試用例，已提出的解決方案是否都能滿足規約。7． 規約必須允許不完備性並允許擴充。8． 規約必須局部化和鬆散耦合。它所包括的資訊必須局部化，這樣當資訊被修改時，只要修改某個單個的段落（理想情況）。同時，規約應被鬆散地構造（即松耦合），以便能夠很容易地加入和刪去一些段落。155/42需求規約Ⅰ.引言A.系統參考文獻B.整體描述C.軟體專案約束Ⅱ.資訊描述A.資訊內容表示B.資訊流表示：ⅰ數據流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設計約束ⅴ支撐圖C.控制描述ⅰ控制規約ⅱ設計約束Ⅳ.行為描述A.系統狀態B.事件和回應Ⅴ.檢驗標準A.性能範圍B.測試種類C.期望的軟體回應D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄156/42引言：陳述軟體目標，在基於電腦的系統語境內進行描述。資訊描述：給出軟體必須解決問題的詳細描述，記錄資訊內容和關係、流和結構。功能描述：描述解決問題所需的每個功能。其中包括，為每個功能說明一個處理過程；敘述設計約束；敘述性能特徵；用一個或多個圖形來形象地表示軟體的整體結構和軟體功能與其他系統元素間的相互影響。行為描述：描述作為外部事件和內部產生的控制特徵的軟體操作。檢驗標準：描述檢驗系統成功的標誌。即對系統進行什麼樣的測試，得到什麼樣的結果，就表示系統已經成功實現了。它是“確認測試”的基礎。參考書目：包含了對所有和該軟體相關的文檔的引用，其中包括其他的軟體工程文檔、技術參考文獻、廠商文獻以及標準。附錄：包含了規約的補充資訊，表格數據、演算法的詳細描述、圖表以及其他材料。157/42需求驗證需求驗證目的是要檢驗需求是否能夠反映用戶的意願評審人員評審時往往需要檢查以下內容：系統定義的目標是否與用戶的要求一致；系統需求分析階段提供的文檔資料是否齊全；文檔中的描述是否完整、清晰、準確地反映了用戶要求；被開發專案的數據流與數據結構是否確定且充足；主要功能是否已包括在規定的軟體範圍之內，是否都已充分說明；設計的約束條件或限制條件是否符合實際；開發的技術風險是什麼；是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認。

158/42內容摘要需求工程概述需求獲取需求分析、協商與建模需求規約與驗證需求管理第4章形式化說明技術4.1 概述4.2 有窮狀態機4.3 Petri網4.4 Z語言4.5 小結4.1 概述4.1.1非形式化方法的缺點非形式化是指用自然語言描述軟體需求（如系統規格說明書）。因此，可能存在矛盾性、二義性、含糊性、不完整性、抽象層次混亂等問題。4.1.2形式化方法的優點形式化方法是指在軟體工程中引入數學方法和模型。利用數序的簡潔性、嚴謹性、科學性，克服非形式化方法的缺點。4.1.3應用形式化方法的準則“軟體需求”是軟體產品的高層、概念模型，而“形式化方法”是嚴謹、科學的數學方法，因此，在形式化方法的應用方面應考慮適度性、實用性、實用性。常用的形式化方法較嚴格的形式化方法（語法和語義都嚴謹）：有窮狀態機、Petri網、Z語言………半形式化方法（語法和語義都不太嚴謹）：系統流程圖、數據流圖、數據字典、ER圖、資料庫範式、狀態轉換圖、層次方框圖、Warnier圖、IPO圖、IPO表………4.1.1非形式化方法的缺點矛盾性在需求規格說明書（ReqirementSpecifications）中對同一問題前後存在不同的描述。二義性需求規格說明書的讀者對其中同一問題的描述存在不同的理解。含糊性需求規格說明書中對某一問題的描述不清晰、不可理解、不知如何實現、不具可操作性。不完整性需求規格說明書中對某一問題的描述不完整。只說明了局部，沒有說明整體；或者只說明了概要，未說明細節。因此不具可操作性。抽象層次混亂在不同層次的抽象模型中內容混亂，如在高層模型中混有底層細節，造成讀者不能理解系統的整體功能和下級功能。4.1.2形式化方法的優點可嚴謹地描述軟體需求中的問題可簡介、準確描述物理現象、對象或動作的結果問題；適用於描述詳細的需求規格；可用數學方法驗證需求。可在軟體工程不同階段平滑過渡從需求、到設計、到實現都基於同一系統模型，平滑過渡。可提供高層確認手段可用數學方法證明軟體工程各階段的正確性（可回溯性），如“設計”符合“規格說明”、“編碼實現”符合“設計”。形式化方法的適用性問題形式化方法能較好地解決需求的“二義性”、“含糊性”問題。但不能解決需求的矛盾性、完整性等問題，這些問題涉及工程管理。4.1.3應用形式化方法的準則應該選用適當的規格說明表示方法應該採用形式化，但不要過分形式化應該估算推行形式化的成本應該引入形式化方法的顧問與諮詢應該結合傳統的、證明有效的開發方法應該在採用形式化的同時，建立詳盡的文檔應該堅持品質保障活動應該不總是盲目依賴形式化方法應該重視測試應該重視重用4.2 有窮狀態機4.2.1 有窮狀態機概念4.2.2 有窮狀態機例子4.2.3 有窮狀態機方法評價4.2.1 有窮狀態機概念通過簡單例子引入有窮狀態機的基本概念：一個保險箱上裝了一個複合鎖，鎖有三個位置，分別標記為1、2、3，轉盤可向左(L)或向右(R)轉動。這樣，在任意時刻轉盤都有6種可能的運動，即1L、1R、2L、2R、3L和3R。保險箱的組合密碼是1L、3R、2L，轉盤的任何其他運動都將引起報警。引例——保險箱的狀態轉換圖4.1保險箱的狀態轉換圖

引例——保險箱的狀態轉換有窮狀態機——概念一個有窮狀態機包括下述5個部分：狀態集J、輸入集K、由當前狀態和當前輸入確定下一個狀態(次態)的轉換函數T、初始態S和終態集F。狀態集J：有所有可能的狀態構成的有窮集合；輸入集K：引發狀態變換的可能的外部輸入（或操作）；轉換函數T：由當前狀態和當前輸入變換到下一個狀態(次態)的函數（或規則）；初始態S∈J，狀態機的初始狀態；終態集F∪J，狀態機的終止狀態集；引例——保險箱的有窮狀態機狀態集J：｛保險箱鎖定，A，B，保險箱解鎖，報警｝。輸入集K：｛1L，1R，2L，2R，3L，3R｝。轉換函數T：見“狀態轉換表”初始態S：保險箱鎖定終態集F：｛保險箱解鎖，報警｝有窮狀態機——形式化表示一個有窮狀態機可以表示為一個5元組(J，K，T，S，F)，其中：J是一個有窮的非空狀態集；K是一個有窮的非空輸入集；T是一個從(J-F)×K到J的轉換函數；S∈J，是一個初始狀態；F∪J，是終態集。擴展的有窮狀態機——增加謂詞集一個有窮狀態機可以表示為一個6元組(J,K,P,T,S,F)，其中：J是一個有窮的非空狀態集；K是一個有窮的非空輸入集；P是一個有窮的非空謂詞集(條件函數集合)；T是一個從(J-F)×K×P到J的轉換函數；S∈J，是一個初始狀態；F∪J，是終態集。4.2.2 有窮狀態機例子-電梯