軟件工程複習（一）

1.  軟件危機產生的緣由

      是在軟件開發和維護過程當中所遭遇的一系列嚴重問題，致使開發延期甚至沒法交付、成本激增或者軟件運行質量事故、軟件沒法維護等。緣由是軟件再也不只是程序，人機交互、實時系統、業務系統等軟件規模愈來愈大，軟件複雜度也愈來愈高，應用範圍也逐漸增大。

2.  用例圖，活動圖，數據流程圖

     用例圖：描述系統的功能，展示了一組用例、用戶以及他們間的關係，即從用戶角度描述系統功能，用於收集用戶實際需求。

     

       活動圖：描述業務用例實現的工做流程。包含： 活動狀態圖、動做狀態、動做狀態約束、動做流、開始節點、終止節點、對象、數據存儲對象、對象流、分支與合併、分叉與匯合、異常處理、活動中斷區域、泳道。

       

      

      數據流程圖：數據流程圖（Data Flow Diagram,DFD ），是描述系統數據流程的工具，它將數據獨立抽象出來，經過圖形方式描述信息的前因後果和實際流程。數據流程圖的基本成分，系統部件包括系統的外部實體、處理過程、數據存儲和系統中的數據流四個組成部分。

      

3.  白盒測試（2種：靜態測試、動態測試）， 黑盒測試。

     白盒測試方法（White-box Testing），也稱結構測試或邏輯驅動測試。白盒測試方法是根據模塊內部結構瞭解，基於內部邏輯結構，針對程序語句、路徑、變量狀態等來進行測試，檢驗程序中的各個分支條件是否獲得知足、每條執行路徑是否按預約要求正確的工做。白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程序變異。

    靜態測試就是靜態分析，對模塊的源代碼進行研讀，查找錯誤或收集一些度量數據，並不須要對代碼進行編譯和仿真運行。靜態測試採用人工檢測和計算機輔助靜態分析手段進行檢測。

    動態測試是經過觀察代碼運行時的動做，來提供執行跟蹤、時間分析，以及測試覆蓋度方面的信息。動態測試經過真正運行程序發現錯誤。經過有效的測試用例，對應的輸入/輸出關係來分析被測程序的運行狀況。

    黑盒測試方法（Blake-box Testing），是把程序看做一個不能打開的黑盒子，不考慮程序內部結構和內部特性，而是考察數據的輸入、條件限制和數據輸出，完成測試

 

4. 驅動程序和樁程序

      驅動程序（driver）：對底層或子層模塊進行（單元或集成）測試時所編制的調用被測模塊的程序，用以模擬被測模塊的上級模塊。

      程序（stub）: 對頂出或者上層模塊進行測試時，所編制的替代下層模塊的程序，用以模擬被測模塊工做過程當中所調用的模塊。

      

5. 容錯測試

      軟件測試包括： 集成測試、功能測試、非功能測試（負載測試，容量測試，性能測試，安全性測試，容錯測試，兼容性測試，可靠性測試）和驗收測試。

      容錯測試是一種非功能測試，主要檢查系統的容錯能力，檢查軟件在異常條件下自身是否具備防禦性的措施或者某種災難性恢復的手段。

      容錯性測試是檢查軟件在異常條件下的行爲。容錯性好的軟件能確保系統不發生沒法意料的事故。

 

6.   數據詞典

      數據字典（Data dictionary）是一種用戶能夠訪問的記錄數據庫和應用程序源數據的目錄。主動數據字典是指在對數據庫或應用程序結構進行修改時，其內容能夠由DBMS自動更新的數據字典。被動數據字典是指修改時必須手工更新其內容的數據字典。

 

7. 內聚

      內聚有： 功能內聚性（最高）、順序內聚性（較高）、通信內聚性（中）、臨時內聚性（低）

 

8. 軟件工程概念的起源

   軟件工程是1968年北大西洋公約組織（NATO）的計算機科學家在聯邦德國召開國際會議，討論軟件危機問題，正式提出了「軟件工程」。

 

9. 管理模型： RUP全過程管理， 瀑布， scrum模型。

      RUP全過程管理模型 ：Rational Unified Process 是一種軟件過程，它提供了在開發組織中分配任務和職責的嚴格方法，綜合了許多現代軟件開發的最佳實踐（包括迭代開發、需求管理、基於構件的體系結構、可視化建模、驗證軟件質量和控制軟件的變動），以一種可剪裁、可操做、詳盡和實用的方式爲軟件項目提供過程指導，以幫助開發人員在預約的進度和預算範圍內開發出符合用戶需求的高質量軟件系統。Rup的完整框架能夠用一個二維結構來表示。其中，橫軸表明時間，刻畫了過程的時間因素和生命週期，體現了過程的動態結構，能夠用週期、階段、迭代和里程碑等術語來表示；縱軸表明核心過程規程，體現了過程的靜態結構，能夠用活動、規程、角色和工做流等術語來表示。特別適用於大型軟件團隊開發大項目。

      瀑布模型：1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的「瀑布模型」，直到80年代早期，它一直是惟一被普遍採用的軟件開發模型。

　　瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協做，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟件生命週期劃分爲軟件計劃、需求分析和定義、軟件設計、軟件實現、軟件測試、軟件運行和維護這6個階段，規定了它們自上而下、相互銜接的 固定次序，如同瀑布流水逐級下落。採用瀑布模型的軟件過程以下圖所示：

                   優勢：

                   1）爲項目提供了按階段劃分的檢查點。

                   2） 當前一階段完成後，您只須要去關注後續階段。

                   3）可在迭代模型中應用瀑布模型。

                  缺點：

                  1） 在項目各個階段之間極少有反饋。

                  2） 只有在項目生命週期的後期才能看到結果。

                  3）經過過多的強制完成日期和里程碑來跟蹤各個項目階段。

      瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下 落。從本質來說，它是一個軟件開發架構，開發過程是經過一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，每一個階段都會產生循環反饋，所以， 若是有信息未被覆蓋或者發現了問題，那麼最好 「返回」上一個階段並進行適當的修改，開發進程從一個階段「流動」到下一個階段，這也是瀑布開發名稱的由來。

      Scrum模型： 是一種迭代式增量軟件開發過程，一般用於敏捷軟件開發。包括了一系列實踐和預約義角色的過程骨架。Scrum中的主要角色包括同項目經理相似的Scrum主管角色負責維護過程和任務，產品負責人表明利益全部者，開發團隊包括了全部開發人員。

      一、客戶成爲開發團隊中的一部分。（例如客戶確定對開發的結果然正感興趣。）

      二、和全部其餘形式的敏捷軟件過程同樣，Scrum有頻繁的包含能夠工做的功能的中間可交付成果。 這使得客戶能夠更早的獲得能夠工做的軟件，同時使得項目能夠變動項目需求以適應不斷變化的需求。

      三、頻繁的風險和緩解計劃是由開發團隊本身制定。– 在每個階段根據承諾進行風險緩解，監測和管理（風險分析）。

      四、計劃和模塊開發的透明 – 讓每個人知道誰負責什麼，以及何時完成。

      五、頻繁的進行全部相關人員會議，以跟蹤項目進展 – 平衡的（發佈，客戶，員工，過程）儀表板更新 – 全部相關人員的變動 – 你必須擁有預警機制，例如提早了解可能的延遲或誤差。

      六、沒有問題會被藏在地毯下。認識到或說出任何沒有預見到的問題並不會受到懲罰。

      七、在工做場所和工做時間內必須全身心投入。– 完成更多的工做並不意味着須要工做更長時間。