程序員必學之精華----軟件工程

1、軟件工程的定義

      軟件工程學是一門指導軟件開發和維護的工程學科，是爲了經濟地得到可以在實際機器上有效運行的可靠軟件而創建和使用的一系列完善的工程化原則。它應用計算機科學、數學及管理科學等原理，借鑑傳統工程的原則、方法來生產軟件，以達到提升質量、下降成本的目的。

軟件工程包括3個要素：方法、工具和過程

2、軟件工程的目標

      軟件工程研究的目標是「以較少的投資獲取高質量的軟件」。

      即從技術和管理上採起多項措施之後，組織實施軟件工程項目的最終目的是保證項目成功，即達到如下幾個主要目標：

       • 付出較低的開發成本

       • 達到預期的軟件功能

       • 取得較好的軟件性能

       • 使軟件易於移植

       • 須要較低的維護費用

     能按時完成開發工做，及時交付使用

     在項目的實際開發中，使以上幾個目標都達到理想的程度每每很是困難，並且上述目標極可能是相互衝突的。軟件過程所實現的多目標中，有的是互補的，例如縮短開發期，顯然可下降成本，維護是須要代價的，易於維護就可下降總成本。高性能與高可靠性是互補的。而有的目標則是互斥的，例如，要得到高的可靠性，一般要採起一些冗餘的措施，每每成本會增長。

    以上幾個目標是判斷軟件開發方法或管理方法優劣的衡量尺度。在一種新的開發方法提出之後，人們關心的是它對知足哪些目標比現有的方法更爲有利。實際上實施軟件項目開發的過程就是在以上目標的衝突中取得必定程度平衡的過程。爲了實現軟件工程的多目標，要對軟件的的各項質量指標進行綜合考慮，以實現軟件開發的「多！快！好！省！」的總目標。

3、軟件工程的原則

   1. 分解

      分解是人類分析解決複雜問題的重要手段和基本原則，其基本思想是從時間上或是從空間上將一個複雜抽象問題分紅若干個較小的、相對獨立的、容易求解的子問題，而後分別求解。軟件瀑布模型，結構化分析方法，結構化設計方法，Jackson方法，模塊化設計都運用了分解的原則

  2. 抽象和信息隱蔽

      儘可能將可變因素隱藏在一個模塊內，將怎樣作的細節隱藏在下層，而將作什麼抽象到上一層作簡化，從而保證模塊的獨立性。這就是軟件設計獨立性要遵照的基本原則。模塊化和局部性的設計過程使用了抽象和信息隱蔽的原則。

   3. 一致性

      研究軟件工程方法的目的之一，就是要使開發過程標準化，使軟件產品設計有共同遵循的原則。要求軟件文件格式一致，工做流程一致，軟件開發過程要標準化，統一化。

  4. 肯定性

     軟件開發過程要用肯定的形式表達需求，表達的軟件功能應該是可預測的，用可測試性，易維護性，易理解性，高效率的指標來具體度量軟件質量。

  5. 完備性

     軟件系統不丟失任何重要成分，能夠徹底實現系統所要求的功能。爲保證系統的完備性，在軟件開發和運行過程當中須要嚴格的技術評審。

  6. 可驗證性

      開發大型的軟件時須要對系統逐層分解，系統分解應遵循使系統易於檢查、測試、評審的原則，以確保系統的正確性。

4、軟件生存週期

      同任何事物同樣，軟件也有一個孕育、誕生、成長、成熟和衰亡的生存過程。軟件生存週期是指一個軟件從提出開發要求開始直到該軟件報廢爲止的整個時期。把整個生存週期劃分爲若干階段，使得每一個階段有明確的任務，把規模大、結構複雜和管理複雜的軟件開發變得容易控制和管理。   

     1. 問題定義及可行性研究

       (1) 問題定義

        問題定義要回答的關鍵問題是：「要解決的問題是什麼?」，系統分析員應提出關於問題的性質、軟件系統的目標和規模的書面報告。經過對系統的實際用戶和使用部門負責人的訪問調查，分析員要扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不清的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。  

       (2) 可行性研究

        可行性研究要回答的關鍵問題是：「對於定義的問題有行得通的解決辦法嗎?」。這個階段的任務不是具體解決問題，而是研究問題的範圍，探索這個問題是否值得去解，是否有可行的解決辦法。這一階段，系統分析員需在較短的時間內模擬進行系統分析和設計過程，即在較抽象的層次下進行分析和設計。系統分析員應對用戶的需求和環境進行深刻細緻的調查，在此基礎上進行技術上、經濟上、法律上等多方面的可行性論證。

      可行性研究的結果是使用部門負責人作出是否繼續進行這項工程的決定的重要依據，通常說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。不值得投資的工程項目要及時停止，避免更大的浪費。

   2. 需求分析

       需求分析階段的任務不是具體地解決問題，而是準確地肯定「軟件系統必須作什麼」，肯定軟件系統必須具有哪些功能。系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，須要對用戶的需求去粗取精、正確理解，而後把它用軟件工程開發語言表達出來，以得出通過用戶確認的系統邏輯模型。一般用數據流圖、數據字典和簡要的算法描述表示系統的邏輯模型。該模型必須準確全面地體現用戶的需求，是之後設計系統的基礎。該階段的主要任務是：對用戶提出的要求進行分析並給出詳細的定義；編寫軟件需求說明書及初步的系統用戶手冊，提交管理機構評審。

   3. 概要設計

概要設計階段要解決的問題是：「應該如何宏觀地實現系統功能？」 。把各項功能需求轉換成須要的體系結構，在該體系結構中，每一個成分都是意義明確的模塊，即每一個模塊都和某些功能需求相對應，以比較抽象歸納的方式提出瞭解決問題的辦法。概要設計的主要任務是選擇合適的設計方案，肯定軟件的結構，模塊的功能和模塊間的接口以及全局數據結構的設計。

   4. 詳細設計

     詳細設計階段要完成的工做就是對每一個模塊要完成的功能進行具體描述，即把解決方法具體化。詳細設計的任務是設計每一個模塊的實現細節和局部數據結構。這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的做用很相似於其它工程領域中工程師常用的工程藍圖，它們應該包含必要的細節，程序員能夠根據它們寫出實際的程序代碼。 

  5. 編碼

      編碼階段就是把每一個模塊的控制結構轉換成計算機可接受的程序代碼，即寫成以某特定程序設計語言表示的「源程序清單」。程序員應該根據目標系統的性質和實際環境，選取一種適當的程序設計語言，把詳細設計的結果翻譯成用選定的語言書寫的程序，而且仔細測試編寫出的每個模塊。具體的工做包括如下兩個方面：把軟件設計轉換成計算機能夠接受的程序代碼，即寫成以某一種特定程序設計語言表示的「源程序清單」；寫出的程序應當是結構良好、清晰易讀，且與設計相一致的。

  6. 測試

     軟件分析、設計、程序編寫過程當中不免有各類各樣的錯誤，須要經過測試來查找和修改，以保證軟件的質量。軟件測試階段的主要任務是：

    單元測試：查找各模塊在功能和結構上存在的問題並加以糾正；

    組裝測試：將已測試過的模塊按必定順序組裝起來；

    有效性測試：按規定的各項需求，逐項進行測試，決定已開發的軟件是否合格，可否交付用戶使用。

  7. 維護

     軟件項目開發成功後，要投入運行。軟件系統在運行過程當中，受系統內、外環境變化及各類人爲的、技術的、設備的影響，要求軟件可以適應這種變化，不斷地完善，這就要進行軟件維護，以保證正常而可靠地運行，並能使軟件不斷地獲得改善和提升，充分發揮其做用。

     軟件維護有四種類型，它們分別完成如下各自的任務：

     改正性維護：運行中發現了軟件中的錯誤而進行的修正工做；

     適應性維護：爲了適應變化了的軟件工做環境，而作出適當的變動；

     完善性維護：爲了加強軟件的功能而作出的變動；

     預防性維護：爲將來的修改與調整奠基更好的基礎而進行的工做。

    在軟件工程中的每個步驟完成後，爲了確保活動的質量，必須進行評審。爲了保證系統信息的完整性和軟件使用的方便，還要有相應的詳細文檔。

    在大部分文獻中將生存週期劃分爲5個階段，即要求定義、設計、編碼、測試及維護。其中，要求定義階段包括可行性研究和項目開發計劃、需求分析，設計階段包括概要設計和詳細設計。

    爲了描述軟件生存期的活動，提出了多種生存期模型。例如：瀑布模型、快速原型模型、增量模型、噴泉模型、螺旋模型等。

5、軟件開發模型

     爲了反映軟件生存週期內各類工做應如何組織及週期各個階段應如何銜接，須要用軟件開發模型給出直觀的圖示表達。軟件開發模型是軟件工程思想的具體化，是實施於過程模型中的軟件開發方法和工具，是在軟件開發實踐中總結出來的軟件開發方法和步驟。總的說來，軟件開發模型是跨越整個軟件生存週期的系統開發、運做、維護所實施的所有工做和任務的結構框架。

  ->瀑布模型

    瀑布模型也稱爲「傳統生命週期」或「線性順序模型」。瀑布模型是將軟件開發活動中的各項活動規定爲依線性順序聯接的若干階段工做，形如瀑布流水，最終獲得軟件系統或軟件產品。瀑布模型提出了軟件開發的系統化、結構化的方法，它是按照分析、設計、編碼、測試和維護順序進行的，借鑑了傳統的工程週期。換句話說，它將軟件開發過程劃分紅若干個互相區別而又彼此聯繫的階段，每一個階段中的工做都以上一個階段工做的結果爲依據，同時做爲下一個階段的工做基礎。

    瀑布模型如圖所示，從圖中能夠看出每項開發活動均應具備下述特徵：

                                                        

      瀑布模型獲得了普遍的應用，它在消除非結構化軟件、下降軟件的複雜性、促進軟件開發工程化方面起了很大的做用。但在大量的仍然機軟件開發實踐中也逐漸暴露出它的缺點。因爲瀑布模型是一種理想的線性開發模式，缺少靈活性，也沒法解決軟件需求不許確或者不明確的問題。這些缺點對軟件開發帶來了嚴重影響，因爲需求不明確，會致使開發的軟件不符合用戶的需求而夭折。另外，因爲軟件開發須要人們合做完成，所以人員之間的通信和軟件工具之間的聯繫以及開發工做之間的並行和串行等都是必要的，但瀑布模型中並無體現出這一點。

    ->快速原型模型

    快速原型模型如圖所示，從需求分析開始。軟件開發者和用戶在一塊兒定義軟件的總目標，說明需求，並規劃出定義的區域。而後快速設計軟件中對用戶/客戶可見部分的表示。快速設計致使了原形的建造，原形由用戶/客戶評估，並進一步求精待開發軟件的需求。逐步調整原形使之知足用戶需，這個過程是迭代的。原型模型的優勢和缺點以下所述。

    1. 優勢

    快速原型模型法在獲得良好的需求定義上比傳統生存週期法好得多，不只能夠處理模糊需求，並且開發者和用戶可充分通訊。

    快速原型模型系統可做爲培訓環境，有利於用戶培訓和開發同步，開發過程也是學習過程。

    快速原型模型給用戶以機會更改心中原先設想的、不盡合理的最終系統。

    快速原型模型能夠低風險開發柔性較大的計算機系統。

    快速原型模型使系統更易維護、對用戶更友好的機會。

    快速原型模型使總的開發費用下降，時間縮短。

                                               

     2. 缺點

     「模型效應」或「管中窺豹」。對於開發者不熟悉的領域把次要部分看成主要框架，作出不切題的原型。

      原型迭代不收斂於開發者預先的目標。爲了消除錯誤，每次更改，次要部分愈來愈大，「淹沒」了主要部分。

      原型過快收斂於需求集合，而忽略了一些基本點。

      資源規劃和管理較爲困難，隨時更新文檔也帶來麻煩。

      長期在原型環境上開發，只注意獲得滿意的原型，容易「遺忘」用戶環境和原型環境的差別

    3. 適用範圍

    • 特別適用需求分析與定義規格說明

    • 設計人機界面

    • 充做同步培訓工具

    • 「 一次性 」 的應用

    • 低風險引入新技術

   4. 不適用範圍

     • 嵌入式軟件

     • 實時控制軟件

     • 科技數值計算軟件

   ->增量模型

     增量模型是一種非總體開發的模型。根據增量的方式和形式的不一樣，分爲基於瀑布模型的漸增模型和基於原型的快速原型模型。

             

       該模型具備較大的靈活性，適合於軟件需求不明確、設計方案有必定風險的軟件項目。增量模型和瀑布模型之間的本質區別是：瀑布模型屬於總體開發模型，它規定在開始下一個階段的工做以前，必須完成前一階段的全部細節。而增量模型屬於非總體開發模型，它推遲某些階段或全部階段中的細節，從而較早地產生工做軟件

     ->噴泉模型

       噴泉模型是由B.H.Sollers和J.M.Edwards於1990年提出的一種新的開發模型。主要用於採用對象技術的軟件開發項目。它克服了瀑布模型不支持軟件重用和多項開發活動集成的侷限性。噴泉模型使開發過程具備迭代性和無間隙性。軟件的某個部分經常被重複工做屢次，相關對象在每次迭代中隨之加入漸進的軟件成分，即爲迭代的特性；而分析和設計活動等各項活動之間沒有明顯的邊界，即爲無間隙的特性。噴泉模型與傳統的結構化生存期比較，具備更多的增量和迭代性質，生存期的各個階段能夠相互重疊和屢次反覆，並且在項目的整個生存期中還能夠嵌入子生存期。就像水噴上去又能夠落下來，能夠落在中間，也能夠落在最底部。

                                                                       

           噴泉模型是以面向對象的軟件開發方法爲基礎，以用戶需求做爲噴泉模型的源泉。從圖中能夠看出其特色以下：

          (1) 噴泉模型規定軟件開發過程有4個階段，即分析、系統設計、軟件設計和實現。

          (2) 噴泉模型的各階段相互重疊，它反映了軟件過程並行性的特色。

          (3) 噴泉模型以分析爲基礎，資源消耗成塔型，在分析階段消耗的資源最多。

          (4) 噴泉模型反映了軟件過程迭代性的天然特性，從高層返回低層無資源消耗。

          (5) 噴泉模型強調增量開發，它依據分析一點，設計一點的原則，並不要求一個階段的完全完成，整個過程是一個迭代的逐步提煉的過程

          (6) 噴泉模型是對象驅動的過程，對象是全部活動做用的實體，也是項目管理的基本內容。

          (7) 噴泉模型在實現時，因爲活動不一樣，可分爲系統實現和對象實現，這既反映了全系統的開發過程，也反映了對象族的開發和重用過程。

     -> 螺旋模型

        對於大型軟件，只開發一個原型每每達不到要求。螺旋模型將瀑布模型和增量模型結合起來，並加入了風險分析。它是由TRW公司的B.Boehm於1988年提出的。

        軟件風險是廣泛存在於任何軟件開發項目中的實際問題。對於不一樣的項目，其差異只是風險有大有小而已，在制定軟件開發計劃時，系統分析員必須回答：項目的需求是什麼，須要投入多少資源以及如何安排開發進度等一系列問題。然而，要他們立即給出準確無誤的回答是不容易的，甚至幾乎是不可能的。但系統分析員又不可能徹底迴避這一問題，憑藉經驗的估計出發給出初步的設想便不免帶來必定風險。實踐代表，項目規模越大，問題越複雜。資源、成本、進度等因素的不肯定性越大，承擔項目所冒的風險也越大。總之，風險是軟件開發不可忽視的潛在不利因素，它可能在不一樣程度上損害到軟件開發過程或軟件產品的質量。軟件風險駕馭的目標是在形成危害以前及時對風險進行識別、分析，採起對策，進而消除或減小風險的損害。

       模型將開發劃分爲制定計劃、風險分析、實施工程和客戶評估四類活動。沿着螺旋線每轉一圈，表示開發出一個更完善的新的軟件版本。若是開發風險過大，開發機構和客戶沒法接受，項目有可能就此終止；多數狀況下，會沿着螺旋線繼續下去，自內向外逐步延伸，最終獲得滿意的軟件產品。螺旋模型沿着螺線旋轉，將開發過程分爲幾個螺旋週期，如圖所示，每一個螺旋週期可分爲4 個工做步驟：

     第一步，制定計劃：肯定目標、方案和限制條件；

     第二步，風險分析：評估方案、標識風險和解決風險；

     第三步，實施工程：開發確認產品；

     第四步，客戶評估：計劃下一週期工做。

                                                           

        沿螺線自內向外每旋轉一圈便開發出更爲完善的一個新的軟件版本。例如，在第一圈，肯定了初步的目標、方案和限制條件之後，轉入右上象限，對風險進行識別和分析。若是風險分析代表，需求有不肯定性，那麼在右下的工程象限內，所建的原型會幫助開發人員和客戶，考慮其餘開發模型，並對需求作進一步修正。客戶對工程成果作出評價以後，給出修正建議。在此基礎上需再次計劃，並進行風險分析。在每一圈螺線上，作出風險分析的終點是否繼續下去的判斷。假如風險過大，開發者和用戶沒法承受，項目有可能終止。多數狀況下沿螺線的活動會繼續下去，自內向外，逐步延伸，最終獲得所指望的系統。

     若是軟件開發人員對所開發項目的需求已有了較好的理解或較大的把握，則無需開發原型可採用普通的瀑布模型，這在螺旋模型中可認爲是單圈螺線。與此相反，若是對所開發項目需求理解較差，則須要開發原型，甚至須要不止一個原型的幫助，那就須要經歷多圈螺線。在種狀況下，外圈的開發包含了更多的活動。也可能某些開發採用了不一樣的模型。

    螺旋模型適合於大型軟件的開發，應該說它是最爲實際的方法，它吸取了軟件工程「演化」既念，使得開發人員和客戶對每一個演化層出現的風險有所瞭解，繼而作出應有的反映。螺旋模型的優越性比起其餘模型來講是明顯的，但並非絕對的。要求許多客戶接受和使用該模型並不容易。這個模型的使用須要具備至關豐富的風險評估經驗和專門知識，若是項目風險較大，又未能及時發現，勢必形成重大損失。此外，螺旋模型是出現較晚的新模型，遠不及瀑布模型普及，要讓廣大軟件人員和用戶充分確定它，還有待於更多的實踐。

     謝謝園友們可以看到這裏，證實大家有一種對知識的渴望和求知的慾望，相信經過咱們不斷的學習，無論是理論知識仍是實際開發技術，都會獲得一個好的提高，重在堅持哦！加油！