B002软体工程综观File.PPT

軟體工程綜觀 為何需要軟體工程 軟體工程是如何開發軟體的方法 資訊硬體日新月異，人們需要高品質且多功能性的軟體有效發揮硬體效用。 軟體已從「單一程式」演變成「複雜系統」。 單打獨鬥的開發方式已無法應付此種變化。 軟體工程愈來愈受到重視。 軟體工程的重要性 軟體架構工程師與程式設計員有差異。 軟體架構工程師了解、設計系統而程式設計員撰寫程式。 系統開發勿採用「土法煉鋼」的方式，要有工法 。 實踐軟體工程要成本與人力， 但值得(在維護階段)。 軟體開發的生命周期 軟體規格建立 軟體的設計與建置 軟體測試驗收 軟體維護更新 軟體規格的建立 軟體系統開發之前需要先進行「需求分析」並訂定功能。 事先未規劃好軟體的功能，會導致需求「無限擴張」。 影響整個開發時程、資源、資金與成功與否。 軟體規格的建立 分析需求後，軟體功能已確定，接著「系統設計」。 對軟體功能提出解決方案，同時設計軟體架構。 複雜系統的開發可以切割成多個子系統再進行開發。 同時由不同的開發者進行開發，最後再進行整合。 可縮短期程，避免在發生錯誤時影響整個系統。 規格產出後需檢視其中各子系統的關連性與介面設計是否合適 模糊的規格需再次定義。 專案發展(Project development) 專案發展的過程通稱為專案生命週期發展（Project Life Cycle Develpment），以後簡稱為PLCD。 PLCD定義軟體開發的過程，使軟體開發過程有跡可循。 循序專案開發過程 (Sequential PLC) SPLC軟體開發過程分為幾個階段: 專案開始（Project Initiation） 系統分析（System Analysis） 系統設計（System Design） 系統實作（System Implementation） 需求工程 (Requirements Engineering) 此階段得到系統的功能，以及使用上的限制條件。 需求工程產出軟體系統規格： 需求即客戶需求 需求規格就是系統的功能與性能與效能規格 軟體系統的規格屬於技術性的規格，是後續設計及製作的基礎。 軟體系統規格與需求規格有對應關係 軟體系統規格涵蓋大部分細節。 需求獲得策略 由上而下(top-down)：從企業的觀點出發，整合各部門需求。 由下而上(bottom-up)：從作業層次與部門的觀點出發。成效快成本低但容易忽略整合性。 應用系統的需求 系統規格經過確證 (Validation)後才可定案。 應用系統的需求會隨時間或環境改變。 需求改變會造成系統設計及製作上的變更。 需求分析流程 一定要有領域的專家參與。 先收集需求，再分析文件。 消除互相衝突的需求或合併類似的需求。 分析方法 分析方法：例如資料流 (Data-flow analysis)。 分析結果的表示：例如資料流程圖。 系統模型的規範：系統模型有既定的規範，使系統開發人員有統一的溝通標準。 語意資料模型 (Semantic data model)：描述資料的型態與資料之間的關係。 圖示說明: 矩形代表所描述的資料項目 相連的橢圓形代表資料項目的資料屬性 菱形代表所連接的資料項目的關係 1:M代表一對多的關係，例如一張訂單可能會產生多筆製造單。 需求的定義 軟體系統的需求分功能性的需求（Functional requirements）與非功能性的需求（Non-functional requirements）。 功能性的需求與軟體系統必須提供的功能相關。 非功能性的需求涵蓋了與功能無關的其他需求。 需求的定義要有觀念性描述與技術細節。 需求規格為了避免誤解，要使用正規的方式描述。 描述需求規格常見的方式 需求規格語言：特定的語法及語意描述需求規格。 圖形表示法： 以圖形的方式來描述需求規格。 結構化的自然語言：以結構化的定義加強自然語言的描述能力。 數學表示法：以正規化的數學表示法描述需求的規格。 類程式敘述表示法：使用類似於程式語言的語法與語意(Pseudo-code)定義系統的作業方式。 需求決定方法 JAD(Joint Application Design)：分析師、使用者、管理者都參與，由系統分析師主導。 JAD參與的人多，每個人發言的機會少，發言可能傾向某一類意見，有人可能完全不發言，都是JAD的潛在問題 。 GSS(Group Support System)：嘗試克服JAD的缺點，例如讓參與者可匿名的表達意見。 CASE工具：運用在系統開發初期。包括規劃的工具、繪圖的工具與雛形化的工具。 雛形系統(Prototyping)：建立簡易雛形系統以體驗系統的初步功能。透過雛形可評估某些較無法確定的需求。 專案開始及系統分析階段 專案開始：可行性評估 開發需要成本，開發前要確定