軟體工程複習筆記 第一章 -- 概述

第一章 概述

• 前言
• 1.1 軟體與軟體危機
• • 1.1.1軟體的特點
  • 1.1.2軟體危機--軟體生産的現狀
  • • 危機定義：
    • 軟體生産的現狀
    • 産生軟體危機
    • 産生軟體危機的原因
• 1.2 軟體行業的出路？--軟體工程
• • 1）1993 IEEE軟體工程定義
  • 2）軟體工程研究的主要内容
  • 3）軟體工程階層化
  • • 軟體工程三段論（補充）
    • 軟體項目開發
    • 軟體項目開發路線圖
    • 軟體項目管理
    • 軟體項目管理路線圖
    • 軟體過程改進
    • 軟體過程改進路線圖
  • 4）規範化和文檔化
  • 5）軟體工程的目标
• 1.3 軟體工程發展簡史
• 1.4 軟體工程的7條基本原理
• • 原理1、用分階段的生命周期計劃嚴格管理
  • 原理2、堅持進行階段評審
  • 原理3、實行嚴格的産品控制
  • 原理4、采用現代程式設計技術
  • 原理5、結果應能清楚地審查
  • 原理6、開發小組的人員應該少而精
  • 原理7、承認不斷改進軟體工程實踐的必要性
• 1.5軟體過程模型
• • 1）軟體生命周期
  • • 問題定義階段
    • 可行性研究
    • 需求分析
    • 概要設計
    • 詳細設計
    • 編碼和單元測試：
    • 系統內建和綜合測試：
    • 運作和維護：
  • 2）軟體過程
  • 3）軟體過程模型
  • 1.5.1瀑布模型
  • • 瀑布模型特點
    • 瀑布模型的作用及問題
    • 帶資訊回報的瀑布模型
    • 瀑布模型的優缺點：
    • 适用場合
  • 1.5.2快速原型化模型
  • • 快速原型化模型的優缺點
  • 1.5.3增量模型
  • • 增量模型限制和優缺點
  • 1.5.4螺旋模型
  • • 螺旋模型的優缺點
  • 1.5.5 Rational統一過程
  • • RUP軟體開發生命周期
    • Rational統一過程
  • 1.5.6靈活過程與極限程式設計
  • 1.5.7微軟過程
• 1.6軟體開發方法簡述
• • 軟體工程研究的最新方向
• 1.7軟體工程标準
• • 1）國際标準：
  • 2）國家标準
  • 3）行業标準
  • 4）企業标準
  • 5）項目規範
• 1.8軟體工程師職業道德規範
• 本章要點

前言

       總結自老師的PPT，不隻有知識點，還有一些相關内容的介紹順便複制進來了，自己感興趣就想多了解一些，最後有本章的一些小總結。 如有問題請多指教

1.1 軟體與軟體危機

軟體定義

       1983年，IEEE（國際電氣與電子工程協會）為軟體下的定義是：計算機程式、方法、規則和相關的文檔資料以及在計算機上運作時所必需的資料。

       對軟體比較公認的解釋：軟體是計算機系統中與硬體互相依存的另一部分，它包括程式、相關資料及其說明文檔。

記住 軟體=程式+資料+文檔 軟體≠程式

1.1.1軟體的特點

       軟體是一種邏輯實體，具有抽象性。人們可以把它記錄在紙上、磁盤或CD光牒等媒體上，但卻無法看到軟體本身的形态，必須通過觀察、分析、思考和判斷才能了解它的功能和性能。

       軟體一旦研究開發成功，其生産過程就變成複制過程，不像其他工程産品那樣有明顯的生産制造過程。由于軟體複制非常容易，是以出現了軟體産品的版權保護問題和打擊盜版的問題。

       軟體對硬體和環境有着不同程度的依賴性，這導緻了軟體更新和移植的問題。計算機硬體和支撐環境不斷更新，為了适應運作環境的變化，軟體也需要不斷維護，并且維護的成本通常比開發成本高許多。

       軟體生産至今尚未擺脫手工方式，軟體開發的手工行為造就了一個緻命的問題，就是為應用“量身訂做”軟體。其他工程領域有産品标準，所有生産廠家按照标準生産産品。例如，不管哪個廠家生産的燈泡，隻要瓦數、電壓、電流、接口幾個名額符合要求，使用者買來裝上就可以使用。是以，軟體産品規範性差、通用性差。近幾年，基于元件的軟體開發取得了重大進展，這樣在遇到不同的應用需求時，就可以考慮用已有的元件搭建新的系統。

       軟體涉及各行各業的知識，軟體人員通常缺少專門領域的業務知識，而領域專家往往缺少軟體知識，由此加劇了軟體和業務之間的鴻溝，造成開發的軟體不滿足業務需求。

       軟體不僅是一種在市場上推銷的工業産品，也是與文學藝術作品相似的精神作品。與體力勞動相比，精神活動過程的特點是“不可見性”，這大大增加了組織管理上的困難。

1.1.2軟體危機–軟體生産的現狀

危機定義：

       計算機軟體開發和維護過程中所遇到的一系列嚴重問題。

軟體生産的現狀

• “已完成”的軟體不滿足使用者的需求
• 軟體産品的品質沒有保證。
• 開發進度不能保障，傳遞時間一再拖延。
• 開發成本超出預算。
• 軟體沒有适當的文檔

産生軟體危機

例1

• 現象：開發進度不能保障，傳遞時間一再拖延。
• 案例：2002年的Swanick空運控制系統，包括英格蘭和威爾士全部空運線路，在系統傳遞時，已經延期6年，實際花費6.23億英鎊，比原計劃超出2.73億英鎊。
• 點評：軟體複雜程度高，開發周期長，并且各種變化不斷，是以軟體項目按期完成傳遞的很少。

例2

• 現象：軟體産品的品質沒有保證。
• 案例：1990年4月10日，在倫敦地鐵營運過程中，司機還沒上車，地鐵列車就駛離了車站，當時司機按了啟動按鈕，正常情況下如果車門是開的，系統就應該阻止列車啟動，當時的問題是，司機離開列車去關另一扇卡着的車門，但當他關上車門時，列車還沒有等司機上車就開動了。
• 點評：軟體品質和可靠性的評估非常困難，這些投資巨大、技術一流、管理規範、測試充分的軟體也難保不出現品質問題。

例3

• 現象：軟體通常沒有适當的文檔資料或文檔與最終傳遞的軟體産品不符。
• 點評：軟體幾乎不可能一版保證成功，而是經曆反複修改，其中的文檔很難與每次的修改保持一緻，錯誤的文檔就像錯誤的地圖一樣危險。

例4

• 現象：軟體的可維護程度低
• 點評：軟體開發過程中，起着重要作用的是開發者的邏輯思維過程。如果若幹年後由其他人來修改，必須要了解開發者當時的思維過程。是以說讀懂别人的程式比重新編寫的難度更大。

産生軟體危機的原因

• 與軟體本身的特點有關
  • 軟體缺乏“可見性”, 開發過程的進展情況較難衡量，軟體的品質也較難評價，管理和控制軟體開發過程相當困難
  • 軟體維護通常意味着改正或修改原來的設計，這就在客觀上使得軟體較難維護
  • 顯著特點是規模龐大，而且程式複雜性将随着程式規模的增加而呈指數上升,不僅涉及許多技術問題必須有嚴格而科學的管理
• 與軟體開發和維護的方法有關
  • 忽視軟體需求分析的重要性
  • 輕視軟體維護
  • 隻重視程式而忽視軟體配置其餘成分的糊塗觀念

1.2 軟體行業的出路？–軟體工程

1）1993 IEEE軟體工程定義

       軟體工程是①将系統化的、規範的、可度量的方法應用于軟體的開發、運作和維護過程，即将工程化應用于軟體開發和管理之中，②對①中所選方法的研究。

注意：軟體工程研究所依據的基礎理論：數學、計算機科學、經濟學、工程學、管理學和心理學等學科。其中

• 數學和計算機科學用于構造模型、分析算法；
• 工程學用于評估成本、制定規範和标準；
• 管理學和心理學用于進度、資源、環境、品質、成本等的分析和管理。

2）軟體工程研究的主要内容

技術方面：軟體生命周期全過程中使用的一整套技術方法的集合稱為方法學，其三要素：

1. 過程：擷取高品質軟體所需要的一系列任務架構（活動）、任務完成順序、以及品質保證點和項目管理------做什麼；
2. 方法：過程中規定各項任務中采取的技術方法------如何做；
3. 工具：為方法應用提供自動或半自動支援環境

管理方面：主要研究軟體項目管理學、軟體經濟學、軟體心理學。

3）軟體工程階層化

軟體工程三段論（補充）

軟體項目開發

開發過程是軟體人員“生産”軟體的過程，一般包括：需求分析、設計、編碼、測試等,相當于生産線上的生産過程。

軟體項目開發路線圖

軟體項目管理

       管理過程是項目管理者規劃軟體開發、控制軟體開發的過程，相當于生産線上的管理過程，管理過程是伴随開發過程進行的過程。

軟體項目管理路線圖

軟體過程改進

       過程改進相當于對軟體開發過程和軟體管理過程的“工藝流程”進行管理和改進，如果沒有好的工藝生産不出好的産品，它包括對開發過程和管理過程的定義和改進。

軟體過程改進路線圖

4）規範化和文檔化

• 規範化：使衆多的開發者遵守相同的規範，使軟體生産擺脫個人生産方式，進入标準化、工程化的生産方式—關注國标、行标。
• 文檔化：
  • 把軟體的設計思想、設計過程和實作過程完整地記錄下來，便于各類相關人員交流和溝通；
  • 使軟體開發過程由不可見變為可見，便于管理者對軟體生産進度和開發過程進行管理；
  • 是驗收、品質檢測的标準和依據。

5）軟體工程的目标

軟體工程旨在開發滿足使用者需要、及時傳遞、不超過預算和無故障的軟體，其主要目标如下：

• 實作預期的軟體功能，達到較好的軟體性能，滿足使用者的需求。
• 增強軟體過程可見性和可控性，保證軟體的品質。
• 提高軟體的可維護性，降低維護費用。
• 提高軟體開發生産率，及時傳遞使用。
• 合理預算開發成本，付出較低的開發費用。

1.3 軟體工程發展簡史

       1968年在德國格密斯（Garmish）舉行的學術會議上，北大西洋公約組織（NATO）正式提出了“軟體工程”這一術語。軟體工程作為工程學科家族中的新成員，對軟體産業的形成和發展起了決定性作用，它指導人們科學地開發軟體，有效地管理軟體項目，對提高軟體品質具有重要作用。

       在20世紀70年代基本形成了軟體工程的概念、架構、方法，被稱之為第一代軟體工程，即傳統軟體工程。結構化分析、結構化設計和結構化程式設計方法是這個時期的代表。

       80年代出現的Smalltalk 80程式設計語言标志着面向對象程式設計進入了實用階段，從80年代中到90年代中，研究的重點轉移到面向對象分析和設計上來，進而演化成軟體工程的第二代，稱之為對象工程。

       90年代後期，軟體工程的一個重要進展就是基于元件的開發方法。為了提高軟體生産力，盡可能地利用可複用元件來組裝成新的應用軟體系統。到目前為止，元件技術的研究和發展形成了新一代軟體工程，即第三代軟體工程，也有不少人稱之為元件工程。

       軟體工程至今還在不斷發展，無論是元件工程還是對象工程都在不斷發展，即使是傳統軟體工程的一些基本概念、架構，也随着技術的進步在發生變化。總之，軟體工程代與代之間并沒有鴻溝，它們不僅交叉重疊，也攜手并進。

1.4 軟體工程的7條基本原理

       著名的軟體工程專家B.W.Boehm綜合軟體工程的專家學者們的意見并總結了TRW公司多年開發軟體的經驗，于1983 年在一篇論文中提出了軟體工程的7條基本原理

原理1、用分階段的生命周期計劃嚴格管理

       在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作，這條基本原理意味着，應該把軟體生命周期劃分成若幹階段，并相應地制定出切實可行的計劃，按照計劃對軟體的開發與維護工作進行控制。

原理2、堅持進行階段評審

       軟體的品質保證工作不能等到編碼階段結束之後再進行。經過大量的統計資料表明，大部分錯誤是在編碼之前造成的，其中，設計錯誤約占軟體錯誤的63%，編碼錯誤占37%。

       在前期改正錯誤所需要的可能隻是橡皮和鉛筆，而在傳遞後改正錯誤需要的工作就太多了：查找出錯的代碼、重新組織程式結構和資料結構、測試、修改文檔。也就是說，錯誤發現與改正的越晚，所需付出的代價也越高。

       是以，在每個階段都應該進行嚴格的評審，以便盡早發現在軟體開發過程中所犯的錯誤，是一條必須遵循的重要原則。

原理3、實行嚴格的産品控制

       基準配置管理也稱為變動控制：一切有關修改軟體的建議，特别是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審和控制，獲得準許以後才能實施修改（基準配置又稱基線配置，它們是經過階段評審後的軟體配置成份 ）。目的是當需求變動時，其它各階段的文檔或代碼随之相應變動，以保證軟體的一緻性。

原理4、采用現代程式設計技術

       自從提出軟體工程概念後，人們一直把主要精力用于研究各種新的程式設計技術。60年代末提出了結構化程式設計技術，以後又進一步發展出結構化分析與設計技術、面向對象的分析和設計技術。實踐表明，采用先進的技術既可提高軟體開發和維護的效率，又可提高軟體品質。

原理5、結果應能清楚地審查

       軟體是一種看不見、摸不着的邏輯産品。軟體開發小組的工作進展情況難于評價和管理。為更好地進行管理，應根據軟體開發的總目标及完成期限，明确地規定開發小組的責任和産品标準，進而使所得到的産品有明确的标準能清楚地審查。

原理6、開發小組的人員應該少而精

       軟體開發小組成員的素質應該好，人數不宜過多。素質高的人員開發效率高、品質好、錯誤少。開發小組人員過多，資訊交流造成的通信開銷會急劇增加。

原理7、承認不斷改進軟體工程實踐的必要性

       遵循上述六條基本原理，就能夠按照當代軟體工程基本原理實作軟體的工程化生産。但是，僅有上述六條原理并不能保證軟體開發與維護的過程能趕上時代前進的步伐，是以，應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條基本原理。按照這條原理，不僅要積極地采納新的軟體技術，而且要注意不斷總結經驗、汲取教訓。

1.5軟體過程模型

1）軟體生命周期

• 軟體有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟體的生存期。
• 三個階段：定義、開發、維護
• 八個步驟：問題定義、可行性研究、需求分析；總體設計、詳細設計、編碼與單元測試、綜合測試；運作維護。

軟體定義

• ①問題定義
• ②可行性研究
• ③需求分析

軟體開發

• ①總體設計
• ②詳細設計
• ③編碼和單元測試
• ④綜合測試

運作維護

問題定義階段

• 主題：“要解決的問題是什麼?”
• 任務：通過對客戶的通路調查，系統分析人員弄清問題的背景、解決的意義和目标。扼要地寫出關于問題性質、工程目标和工程規模的書面報告，經過讨論和必要的修改之後這份報告應該得到客戶的确認。

可行性研究

• 主題：“對于上一個階段所确定的問題有行得通的解決辦法嗎?”
• 任務：分析待開發系統的總體目标和範圍，研究系統的可行性和可能的解決方案，對資源、成本及進度進行合理的估算。

需求分析

• 主題：“為了解決這個問題，系統必須做什麼？”。
• 任務：通過分析、整理和提煉所收集到的使用者需求，建立完整的分析模型，将其編寫成軟體需求規格說明和初步的使用者手冊。通過評審需求規格說明書，確定對使用者需求達到共同的了解與認識。需求規格說明書明确地描述了軟體的功能，列出軟體必須滿足的所有限制條件，并定義軟體的輸入和輸出接口。

概要設計

• 主題：“概括地說，應該怎樣實作目标系統?”
• 任務：概要設計“系統的藍圖”。确定解決問題的政策，設計目标系統架構結構和主要元素的布局。也就是确定程式由哪些子產品組成以及子產品間的關系

詳細設計

• 主題：“應該怎樣具體地實作這個系統呢?”
• 任務：根據整體結構設計具體的細節：使用者界面設計，子產品實作算法、資料結構和接口等，編寫設計說明書，并組織進行設計評審。設計過程将現實世界的問題模型轉換成計算機世界的實作模型，設計同樣需要文檔化，并應當在編寫程式之前評審其品質。

編碼和單元測試：

• 主題：“具體實作”
• 任務：
  • 将所設計的各個子產品編寫成計算機可接受的程式代碼。
  • 在設計測試用例的基礎上，測試軟體的各個組成子產品。一旦生成了代碼，就可以開始單元測試，這種測試一般由程式員完成。

系統內建和綜合測試：

• 主題：“全面測試軟體”
• 軟體是作為一個整體運作的，除了單個子產品的測試外，還需要進行系統內建，以及內建測試、系統測試和驗收測試等。
• 任務：通過各種類型的測試(及相應的調試)使軟體達到預定的要求，應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果儲存下來。

運作和維護：

• 主題：“維持軟體的正常運作”
• 一旦軟體傳遞運作之後，所做的任何修改就是維護。維護是軟體過程的一個組成部分，應當在軟體的設計和實作階段充分考慮軟體的可維護性。
• 任務：通過各種必要的維護活動使系統持久地滿足使用者的需要，包括改正性維護，适應性維護，完善性維護，預防性維護；每一項維護活動都應該準确地記錄下來，作為正式的文檔資料加以儲存。

2）軟體過程

• 定義：軟體過程是為擷取高品質軟體所需要的一系列任務架構，它規定了完成各項任務的工作步驟。
• 解釋：過程是為了達到一個目标所進行的一系列活動，或者說是為達到一個目标而設計的“路線圖”。
• 例如：為了培養一個世界體操冠軍，需要研究訓練方法、運用先進的訓練器械、不斷改進訓練過程，最終有可能培養出世界冠軍。

3）軟體過程模型

• 軟體過程是為擷取高品質軟體所需要的一系列任務架構。規定了要完成的各項任務、使用各種方法的順序、各個階段應傳遞的文檔資料、任務完成标記（裡程碑），為保證品質和協調變化應采取的管理措施。
• 軟體生命周期的每一階段都有明确的任務，各個階段的活動如何銜接，開發過程中采用什麼樣的政策，應遵守什麼樣的規定和制約，将這些活動架構用一種模型表示出來，稱為軟體過程模型。
• 也就是說， 軟體過程模型是軟體開發全部過程、活動和任務的結構架構。

1.5.1瀑布模型

瀑布模型規定了軟體生命周期的各項活動：問題定義、可行性研究、需求分析、軟體設計、編碼、測試、運作和維護。各項活動自頂向下、互相銜接如同瀑布一樣。

瀑布模型特點

階段間具有順序性和依賴性

1. 必須等前一階段的工作完成之後，才能開始後一階段的工作
2. 前一階段的輸出(文檔)就是後一階段的輸入(文檔)

推遲實作的觀點：清楚地區分邏輯設計與實體設計，盡可能推遲程式的實體實作

品質保證的觀點

1. 每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務；
2. 每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。

瀑布模型的作用及問題

       它提供了裡程碑式的工作流程，為軟體項目按規程管理提供了便利，例如，按階段制定項目計劃，分階段進行成本核算，進行階段性評審等；

       其作用還展現在文檔上。每個階段都必須完成規定的文檔，并在每個階段結束前都要對所完成的文檔進行評審。這種工作方式有利于軟體錯誤的盡早發現和盡早解決，并為軟體系統今後的維護帶來了很大的便利。

       但是，在實際的軟體項目中存在着許多不穩定因素。例如，開發中的工作疏漏或通信誤解；在項目實施中途，使用者可能會提出一些新的要求；開發者也可能在設計中遇到某些未曾預料的實際困難，希望在需求中有所權衡等。是以，提出經過改進的，跟實際開發環境更加接近的瀑布模型。

帶資訊回報的瀑布模型

當在後面階段發現前面階段的錯誤時，需要沿圖中左側的回報線傳回前面的階段，修正前面階段的産品之後再回來繼續完成後面階段的任務。

瀑布模型的優缺點：

優點：為項目提供了按階段劃分的檢查點；目前一活動完成後，隻需要去關注後續活動；它提供了一個模闆，這個模闆使得分析、設計、編碼、測試和支援的方法可以在該模闆下有一個共同的指導。

缺點：瀑布模型确定了需求分析的絕對重要性，在項目開始的時候，使用者常常難以清楚地給出所有需求；使用者與開發人員對需求了解存在差異；由于開發模型是線性的，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發的風險；早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

适用場合

• 當有一個穩定的産品定義和很容易被了解的技術解決方案 時，純瀑布模型特别合适。
• 當你對一個定義得很好的版本進行維護或将一個産品移植到 一個新的平台上，瀑布模型也特别合适。
• 對于那些容易了解但很複雜的項目，采用純瀑布模型比較合适，因為可以用順序方法處理問題。
• 在品質需求高于成本需求和進度需求的時候，它尤為出色。
• 當開發隊伍的技術力量比較弱或者缺乏經驗時，瀑布模型更為适合。

1.5.2快速原型化模型

• 定義：快速建立起來的可以在計算機上運作的程式，它 所能完成的功能往往是最終産品能完成的功能的一個子集
• 步驟：
  • 快速建立一個能反映使用者主要需求的原型系統
  • 使用者試用原型系統之後會提出許多修改意見
  • 開發人員按照使用者的意見快速地修改原型系統，傳回上一步
  • 使用者認為這個原型系統确實能做他們所需要的工作，開發人員便可據此書寫規格說明文檔，根據這份文檔開發出的軟體可以滿足使用者的真實需求

    

快速原型化模型的優缺點

适用于使用者驅動的系統（即需求模糊或随時間變化的系統）。

優點：

• 從實踐中學習(Learning by doing)
• 改善通信
• 改善使用者參與
• 使部分已知需求清晰化
• 展示描述的一緻性和完整性
• 提高系統的實用性、可維護性
• 節省開發的投入、縮短整個軟體的開發周期

缺點：

• 使用者有時誤解了原型的角色，例如他們可能誤解原型應該和真實系統一樣可靠。
• 缺少項目标準，進化原型方法有點像編碼修正。
• 缺少控制，由于使用者可能不斷提出新要求，因而原型疊代的周期很難控制。
• 額外的花費：研究結果表明構造一個原型可能需要10%額外花費。
• 為了盡快實作原型，采用了不合适的技術，運作效率可能會受影響。
• 原型法要求開發者與使用者密切接觸，有時這是不可能的。例如外包軟體

1.5.3增量模型

• 定義：通過構造一系列可執行的軟體構件來實施開發活動，以增量方式逐漸完善待開發的軟體。當一個新的構件被編碼和測試後，并入到軟體系統結構中，然後将該結構作為一個整體進行測試。這個過程不斷循環往複直到軟體系統達到要求的功能為止。
• 增量模型在各個階段并不傳遞一個可運作的完整産品，而是傳遞一個子集。整個産品被分解成多個構件，開發人員可以分别實作各個構件，每個構件都可以獨立運作。

  

增量模型限制和優缺點

• 軟體産品分解成增量構件的限制
  • 軟體體系結構必須是開放的，向現有産品中加入新構件的過程必須簡單、友善；
  • 需要更精心的設計；
  • 當把新構件內建到現有軟體中時，所形成的産品必須是可測試的
• 優點：
  • 在較短時間内向使用者送出可完成部分工作的産品
  • 逐漸增加産品功能可以使使用者有較充裕的時間學習和适應新産品，進而減少一個全新的軟體可能給客戶組織帶來的沖擊

1.5.4螺旋模型

       螺旋模型即是一種引入了風險分析與規避機制的過程模型，是瀑布模型、快速原型方法和風險分析方法的有機結合。

       螺旋模型基本方法是，在各個階段建立原型進行項目試驗，以降低各個階段可能遇到的項目風險。例如，為了降低使用者對軟體界面不滿意的風險，可以在需求分析階段建立“界面原型”；為了降低軟體不能按設計要求實作的風險，可以在設計階段針對所采用的技術建立“仿真試探原型”。

• 用螺旋線表示軟體項目的進行情況，其中，螺旋線中的每個回路表示軟體過程的一個階段。是以，最裡面的回路與項目可行性有關，接下來的一個回路與軟體需求定義有關，而再下一個回路則與軟體系統設計有關，以此類推。

• 螺旋線中的每個回路都被分成為四個部分：

  1）目标設定：确定項目的階段性目标，分析項目風險。

  2）風險評估：對風險進行詳細地評估分析，并确定适當的風險規避措施。

  3）開發軟體：根據對風險的認識，決定采用合适的軟體開發模型，實施軟體開發。

  4）制定計劃：對項目進行階段評審，制定項目下一個階段的工作計劃。

螺旋模型的優缺點

• 對于大型系統及軟體的開發，這種模型是一個很好的方法。開發者和客戶能夠較好地對待和了解每一個演化級别上的風險。
• 需要相當的風險分析評估專門技術，比較複雜。

1.5.5 Rational統一過程

Rational Unified Process，RUP

Rational公司推出的一種完整的軟體過程

總結多年商業化驗證的6條有效的開發經驗，被稱為“最佳實踐”

• 疊代開發（可運作版本）:通過一系列的細化、若幹個漸進的反複過程得出有效解決方案
• 管理需求：如何提取、組織系統的功能性需求和限制條件并文檔化；有效方法包括用例、腳本
• 使用基于構件的體系結構：使得軟體重用成為可能
• 可視化模組化（UML）：模型是為了解事物而對事物的一種抽象
• 驗證軟體品質：内建的品質評估過程，評估過程不再是事後型的軟體過程
• 控制軟體變更：具有管理變更的能力

RUP軟體開發生命周期

• 二維生命周期模型

  ①橫軸：時間

  ②縱軸：核心工作流

• 四個階段，九個工作流

• 核心工作流

  ①業務模組化

  ②需求

  ③分析和設計

  ④實作

  ⑤測試

  ⑥部署

  

Rational統一過程

• RUP把軟體生命周期劃分成4個階段

  ①初始階段：建立業務模型，定義最終産品視圖，确定項目範圍

  ②精華階段：設計并确定系統體系結構，制定項目計劃，确定資源需 求

  ③建構階段：開發構件和産品，內建并進行測試

  ④移交階段：開發産品送出給使用者

• RUP疊代和漸增式開發

  每次考慮一部分，每次疊代增加一部分，每個階段進一步劃分或多次疊代，但不同的疊代過程中以不同的工作重點和強度對這些核心工作流程進行通路

1.5.6靈活過程與極限程式設計

• 靈活過程（Agile Process，AP）

  原則：

  • 文檔适度、度量适度、管理适度
  • “溝通、簡單、回報、勇氣”
  “靈活軟體開發宣言”闡述的4條價值觀
  • 個體和互動勝過過程和工具：強調優秀的團隊成員是軟體開發項目獲得成功的最重要因素
  • 可以工作的軟體勝過詳盡的文檔：軟體開發的主要目标是向使用者提供可以工作的軟體而非文檔，重大意義是才寫文檔
  • 與客戶協作勝過合同談判：能夠滿足使用者不斷變化的需求的切實途徑是與客戶密切合作
  • 響應計劃勝過遵循計劃：計劃必須有足夠的靈活性和可塑性
• 靈活方法（Agile Methodology，AM）
• 靈活模組化（Agile Modeling，AM）

• 極限程式設計（eXtreme Programming，XP）

  極限程式設計是靈活過程中最有名的一個

  XP的整體開發過程

  

  

1.5.7微軟過程

微軟軟體生命周期

規劃階段：市場擷取使用者情況、客戶需求、競争對手等資訊

設計階段：已經确定了70%以上的需求，包括系統規格說明書、設計方案、系統結構圖、劃分子系統、制定産品開發計劃書

開發階段：完成編碼，并進行單元測試

穩定階段：完整的進行內建測試，確定真實環境下的使用和操作

釋出

微軟過程準則：

• Microsoft擁有自己的軟體開發過程
• 項目計劃應該兼顧未來的不确定因素
• 用有效的風險管理來減少不确定因素
• 經常生成并快速地測試軟體的過度版本
• 采用快速循環、疊代的開發過程
• 用創造性的工作來平衡産品特性和産品成本
• 項目進度表應該具有較高的穩定性和權威性
• 使用小型項目組并發地完成工作
• 在項目早期把軟體配置基線化，項目後期則當機産品
• 使用原型驗證概念，對項目進行早期論證
• 把零缺陷作為追逐的目标
• 裡程碑評審的目的是改進工作，切忌互相指責

1.6軟體開發方法簡述

1）結構化方法

• 1978年，E.Yourdon和L.L.Constantine提出了Yourdon方法，也稱為結構化方法或面向功能的軟體開發方法或面向資料流的方法。

• Yourdon方法是80年代使用最廣泛的軟體開發方法。它首先用結構化分析技術進行需求分析，然後用結構化設計技術進行總體設計和詳細設計，最後是結構化程式設計。這一方法的精髓是自頂向下、逐漸求精，也就是将功能逐漸分解，直到人們可以了解和控制它為止。

  2）面向對象方法：

• 研究始于1966年，自90年代以來，面向對象的分析、設計、測試、度量和管理等研究都得到長足發展。
• 對象是由資料和容許的操作組成的封裝體，與客觀實體有直接對應關系，一個對象類定義了具有相似性質的一組對象。
• 繼承性是對具有層次關系的類的屬性和操作進行共享的一種方式。
• 基本思想：用對象模拟問題領域中的實體，以對象間的關系刻畫實體間聯系。本質是主張從客觀世界固有的事物出發構造系統。

軟體工程研究的最新方向

       軟體形式語言的研究：目前，大部分軟體文檔都是用自然語言書寫的。由于自然語言本身具有模糊性，是以有一部分專家研究“形式化描述語言的應用，以及不同形式化語言之間的轉換”。這類研究工作難度較大，也不容易為一般人所接受。但是由于越來越多的大型軟體的複雜程度與日俱增，這些軟體一旦出錯所引起的後果十分嚴重，是以形式化的研究工作就顯得非常重要。

       構件技術：軟體開發構件化可以說是軟體開發技術的一個發展趨勢，也是軟體工程界的一個熱門話題。近年來，軟體技術的進步以及CORBA，DCOM，JavaBean等構件标準的出現已經使情況開始改變，這給軟體危機的真正緩和帶來了希望。

       品質管理：軟體開發過程的品質控制将逐漸得到重視。軟體開發過程中精神活動的“不可見性”大大增加了過程管理的困難。是以軟體工程管理的指導思想就是千方百計地使這些過程變為“可見的”，以及事後可以檢查的記錄。隻有從一開始就在軟體開發過程中嚴格貫徹品質管理，軟體産品的品質才有保證。否則，開發工作一旦進行到後期，無論怎樣測試和補漏洞，都無濟于事。這就是近年來國際上十分重視的“軟體生産過程品質管理”思想。

1.7軟體工程标準

1）國際标準：

由國際聯合機構制定和公布，提供各國參考的标準。

• ISO（International Standards Organization）國際标準化組織，該機建構立了“計算機與資訊處理技術委員會”（簡稱ISO／TC97)，專門負責與計算機有關的标準化工作。
• 這類标準通常标有ISO字樣，如ISO 8631—86 Information processing —Program constructs and conventions for the representation（資訊處理——程式構造及其表示法的約定)，該标準現已被我國收入國家标準。

2）國家标準

• 由政府或國家級的機構制定或準許，适用于全國範圍的标準。
• GB——中華人民共和國國家标準。國家技術監督局是我國的最高标準化機構，它所公布實施的标準簡稱為“BG”。
• ANSI（American National Standards Institute)——美國國家标準協會。這是美國一些民間标準化組織的上司機構，具有一定權威性。
• BS（British Standard)——英國國家标準。

3）行業标準

• 由行業機構、學術團體或國防機構制定并适用于某個業務領域的标準。
• IEEE（1nstitute Of Electrical and Electronics Engineers)——美電氣和電子工程師學會。近年該學會專門成立了軟體标準分技術委員會（SESS)，積極開展了軟體标準化活動，取得了顯著成果，受到軟體界的關注。IEEE通過的标準常常要報請ANSI審批，使其具有國家标準的性質。是以，我們看到IEEE公布的标準常冠有 ANSI字頭。例如，ANSI／IEEE Str 828—1983軟體配置管理計劃标準。
• GJB——中華人民共和國國家軍用标準。這是由我國國防科學技術工業委員會準許，适合于國防部門和軍隊使用的标準。例如，1988年釋出實施的GJB473—88軍用軟體開發規範。
• DOD-STD（Department Of Defense- STanDards)——美國國防部标準。适用于美國國防部門。

4）企業标準

一些大型企業或公司，由于軟體工程工作的需要，制定适用于本部門的規範。例如，美國IBM公司通用産品部（General Products Division)1984年制定的“程式設計開發指南”，僅供該公司内部使用。

5）項目規範

由某一科研生産項目組織制定，并且為該項任務專用的軟體工程規範。例如，計算機內建制造系統（CIMS)的軟體工程規範。

1.8軟體工程師職業道德規範

1）規範

• 1999年由ACM/IEEE-CS軟體工程師道德規範和職業實踐（SEEPP）聯合工作組制訂了《軟體工程師職業道德規範》，規範含有8組由關鍵詞命名的行為準則。
• 公衆 、客戶和雇主 、産品 、判斷 、管理 、專業 、同行 、自身 。

2）職業化素質

• 職業化，簡單說就是能勝任工作，讓人放心。
• “能勝任工作”，就需要具備相應的專業技能、知識和經驗；
• “讓人放心”意味着很多，包括遵守行業成文的或未成文的規則和規範，積極有效地和同僚溝通，確定自己的工作産品是大家所期望的，盡可能地向客戶提供最專業的服務和産品。
• 自律、溝通和技能是成為職業化軟體工程師的必要條件。

3）職業化軟體工程師忌諱的十大問題

行為一：對外傳遞半成品。

行為二：不遵守标準和規範。

行為三：不積極幫助他人。

行為四：版權意識不敏感。

行為五：對待計劃不嚴肅。

行為六：公事私事相混淆。

行為七：不注意知識更新。

行為八：不主動與人溝通。

行為九：不遵守職業規則。

行為十：不夠誠實和正直。

本章要點

       軟體危機的主要表現是　“已完成”的軟體不滿足使用者的需求；開發進度不能保障；軟體開發成本難以準确估算；軟體産品的品質沒有保證。

       軟體工程是采用工程的概念、原理、技術和方法來開發與維護軟體，把經過時間考驗而證明正确的管理方法和先進軟體開發技術結合起來，運用到軟體開發和維護過程中，來解決軟體危機。

       軟體工程研究的主要内容是軟體開發技術和軟體開發管理兩個方面。軟體開發技術方面主要研究軟體開發方法、軟體開發過程、軟體開發工具和環境。軟體開發管理方面主要研究軟體工程管理學、軟體工程經濟學、軟體工程心理學。

       軟體工程的7條基本原理是①用分階段的生命周期計劃嚴格管理②堅持進行階段評審③實行嚴格的産品控制④采用現代程式設計技術⑤結果應能清楚地審查⑥開發小組的人員應該少而精⑦承認不斷改進軟體工程實踐的必要性。

       軟體生命周期是指一個軟體從提出開發要求開始到該軟體報廢為止的整個時期。通常将軟體的生命周期劃分為問題定義、可行性研究、需求分析、概要設計、詳細設計、編碼和單元測試、內建和測試、維護階段。

       軟體生命周期模型反映的是軟體開發過程、活動和任務的結構架構。它能夠清晰、直覺地表達軟體開發全過程，明确規定要完成的主要活動和任務。對于不同的軟體系統，可能采用不同的開發方法，使用不同的程式設計語言、不同的管理方法和手段、以及各種具有不同技能的人員參與工作，但是對于軟體生命周期模型來說都應該是穩定有效和普遍适用的。到目前為止，已經提出了多種模型，主要有瀑布模型、快速原型模型、演化模型、螺旋模型、V模型等。模型的選擇是基于軟體的特點和應用領域。

       目前，主流的軟體開發方法有結構化方法和面向對象方法。

       為了提高軟體開發的效率，保障軟體産品的品質，軟體工程領域中公布了許多國際标準、國家标準、行業标準、企業标準、項目規範，通常由低級到進階使用。軟體工程的标準關系到許多方面，有規範開發過程的标準，有定義産品的标準，還有管理标準和記法符号的标準等等。

       1999年由ACM/IEEE-CS軟體工程師道德規範和職業實踐（SEEPP）聯合工作組制訂了《軟體工程師職業道德規範》，規範含有8組由關鍵詞命名的準則。公衆 、客戶和雇主 、産品 、判斷 、管理 、專業 、同行 、自身 。

       職業化軟體工程師要注意的十大問題：①高品質地完成任務②遵守行業标準，不能肆意按照自己的想象來發揮③積極幫助他人④版權意識敏感⑤嚴格遵守計劃⑥公私分明⑦注意知識更新⑧善于溝通⑨遵守職業規則⑩誠實和正直。