138.軟件工程_軟件工程學概述

時間 2019-11-20

標籤軟件工程工程學概述简体版

原文原文鏈接

1.1 軟件危機

　　迄今爲止，計算機系統已經經歷了4個不一樣的發展階段，可是，咱們仍然沒有完全擺脫「軟件危機」的困擾，軟件已經成爲限制計算機系統發展的瓶頸。
　　爲了更有效地開發與維護軟件，在20世紀60年代後期軟件工做者開始認真研究消除軟件危機的途徑，從而造成了一門新興的工程學科——計算機軟件工程學(一般簡稱爲軟件工程)。
　　在20世紀60年代中期之前，是計算機系統發展的早期時代，通用硬件至關廣泛，軟件倒是爲每一個具體應用而專門編寫的。
　　這時的軟件一般是規模較小的程序，編寫者和使用者每每是同一個(或同一組)人。這種個體化的軟件環境，使得軟件設計一般是在人們頭腦中進行的一個隱含的過程，除了程序清單以外，沒有其餘文檔資料保存下來。
　　從20世紀60年代中期到70年代中期，是計算機系統發展的第二代時期，這個時期的一個重要特徵是出現了「軟件做坊」，普遍使用產品軟件。
　　「軟件做坊」基本上仍然沿用早期造成的個體化軟件開發方法。

　　隨着計算機應用的日益普及，軟件數量急劇膨脹。要求軟件：
　　　　在程序運行時發現的錯誤必須設法改正；
　　　　用戶有了新的需求時必須相應地修改程序；
　　　　硬件或操做系統更新時，一般須要修改程序以適應新的環境。
　　上述種種軟件維護工做，以使人吃驚的比例耗費資源。更嚴重的是，許多程序的個體化特性使得它們最終成爲不可維護的。
　　「軟件危機」就這樣開始出現了!1968年北大西洋公約組織的計算機科學家在聯邦德國召開國際會議，討論軟件危機問題，在此次會議上正式提出並使用了「軟件工程」這個名詞，一門新興的工程學科就此誕生了。web

1.1.1 軟件危機的介紹

軟件危機：是指在計算機軟件的開發和維護過程當中所遇到的一系列嚴重問題。
這些問題毫不僅僅是不能正常運行的軟件才具備的，實際上，幾乎全部軟件都不一樣程度地存在這些問題。算法

歸納地說，軟件危機包含下述兩方面的問題：
　　　　如何開發軟件，以知足對軟件日益增加的需求；
　　　　如何維護數量不斷膨脹的已有軟件。

具體地說，軟件危機主要有如下一些典型表現。
(1)對軟件開發成本和進度的估計經常很不許確。
          實際成本比估計成本有可能高出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象並不罕見。這種現象下降了軟件開發組織的信譽。而爲了趕進度和節約成本所採起的一些權宜之計又每每損害了軟件產品的質量，從而不可避免地會引發用戶的不滿。
(2) 用戶對「已完成的」軟件系統不滿意的現象常常發生。
           軟件開發人員經常在對用戶要求只有模糊的瞭解，甚至對所要解決的問題尚未確切認識的狀況下，就匆忙着手編寫程序。因爲和用戶之間的信息交流不充分，必然致使最終的產品不符合用戶的實際須要。
(3) 軟件產品的質量每每靠不住。
    軟件質量保證技術(審查、複審和測試)沒有堅持不懈地應用到軟件開發的全過程當中，致使軟件產品發生質量問題。
(4) 軟件經常是不可維護的。
    不少程序中的錯誤是很是難改正的，沒法使這些程序適應新的硬件環境，也不能根據用戶的須要在原有程序中增長一些新的功能。
    「可重用的軟件」仍是一個沒有徹底作到的、正在努力追求的目標，人們仍然在重複開發相似的或基本相似的軟件。
(5) 軟件一般沒有適當的文檔資料。
    計算機軟件不只僅是程序，還應該有一整套文檔資料。這些文檔資料應該是在軟件開發過程當中產生出來的，並且應該是「最新式的」(即和程序代碼徹底一致的)。
    軟件開發組織的管理人員能夠使用這些文檔資料做爲「里程碑」，來管理和評價軟件開發工程的進展情況；
    軟件開發人員能夠利用它們做爲通訊工具，在軟件開發過程當中準確地交流信息；
    對於軟件維護人員而言，這些文檔資料更是必不可少的。缺少必要的文檔資料或者文檔資料不合格，必然給軟件開發和維護帶來許多嚴重的困難和問題。
(6) 軟件成本在計算機系統總成本中所佔的比例逐年上升。
    因爲微電子學技術的進步和生產自動化程度不斷提升，硬件成本逐年降低，然而軟件開發須要大量人力，軟件成本隨着通貨膨脹以及軟件規模和數量的不斷擴大而持續上升。美國在1985年軟件成本大約已佔計算機系統總成本的90%。
(7) 軟件開發生產率提升的速度，遠遠跟不上計算機應用迅速普及深刻的趨勢，軟件產品「供不該求」。編程

1.1.2 產生軟件危機的緣由

在軟件開發和維護的過程當中存在這麼多嚴重問題，
一方面與軟件自己的特色有關，
一方面和軟件開發與維護的方法不正確有關。

管理和控制軟件開發過程至關困難。
軟件不一樣於硬件，缺少「可見性」，在寫出程序代碼並在計算機上試運行以前，軟件開發過程的進展狀況較難衡量，軟件的質量也較難評價。數據結構

軟件較難維護
軟件在運行過程當中不會由於使用時間過長而被「用壞」，運行中發現的錯誤，極可能是在開發時期引入的在測試階段沒能檢測出來的錯誤，須要改正或修改原來的設計，使得軟件較難維護。架構

軟件不一樣於通常程序，其顯著特色是規模龐大，並且，程序的複雜性隨着程序規模的增長呈指數上升。
爲了在預約時間內開發出規模龐大的軟件，必須由許多人分工合做，然而，如何保證每一個人完成的工做合在一塊兒確實能構成一個高質量的大型軟件系統，是一個極端複雜困難的問題，不只涉及許多技術問題，更重要的是必須有嚴格而科學的管理。併發

軟件專業人員對軟件開發和維護的錯誤的認識和做法。
    軟件自己獨有的特色確實給開發和維護帶來一些客觀困難，可是人們在開發和使用計算機系統的長期實踐中，也確實積累和總結出了許多成功的經驗。
    若是堅持不懈地使用正確的方法，許多困難是徹底能夠克服的。
    可是，目前至關多的軟件專業人員對軟件開發和維護還有很多糊塗觀念，在實踐過程當中或多或少地採用了錯誤的方法和技術，這是出現軟件危機的主要緣由。框架

這些錯誤認識和做法的造成，能夠歸因於在計算機系統發展的早期階段軟件開發的個體化特色。
錯誤的認識和做法主要表現爲忽視軟件需求分析的重要性，認爲軟件開發就是寫程序並設法使之運行，輕視軟件維護等。模塊化

對用戶要求沒有完整準確的認識就匆忙着手編寫程序是許多軟件開發工程失敗的主要緣由之一。
只有用戶才真正瞭解他們本身的須要，可是許多用戶在開始時並不能準確具體地敘述他們的須要，軟件開發人員須要作大量深刻細緻的調查研究工做，反覆屢次地和用戶交流信息，才能真正全面、準確、具體地瞭解用戶的要求。急於求成，倉促上陣，對用戶要求沒有正確認識就匆忙着手編寫程序，最終必然失敗。
事實上，越早開始寫程序，完成它所須要用的時間每每越長。工具

一個軟件從定義、開發、使用和維護，直到最終被廢棄，要經歷一個漫長的時期。一般把軟件經歷的這個漫長的時期稱爲生命週期。post

軟件開發最初的工做應是問題定義，也就是肯定要求解決的問題是什麼；

而後要進行可行性研究，決定該問題是否存在一個可行的解決辦法；

接下來應該進行需求分析，也就是深刻具體地瞭解用戶的要求，在所要開發的系統(目標系統)必須作什麼這個問題上和用戶取得徹底一致的見解。

    通過上述軟件定義時期的準備工做才能進入開發時期。
    在開發時期首先須要對軟件進行設計(分爲概要設計和詳細設計兩個階段)，而後才能進入編寫程序的階段，程序編寫完以後還必須通過大量的測試工做(須要的工做量一般佔軟件開發所有工做量的40%～50%)才能最終交付使用。
    因此，編寫程序只是軟件開發過程當中的一個階段，並且在典型的軟件開發工程中，編寫程序所需的工做量只佔軟件開發所有工做量的10%～20%。
    程序只是完整的軟件產品的一個組成部分，在軟件生命週期的每一個階段都要得出最終產品的一個或幾個組成部分(這些組成部分一般以文檔資料的形式存在)。
    所以，一個軟件產品必須由一個完整的配置組成，軟件配置主要包括程序、文檔和數據等成分。必須清除只重視程序而忽視軟件配置其他成分的糊塗觀念。

　　做好軟件定義時期的工做，是下降軟件成本提升軟件質量的關鍵。在軟件開發的不一樣階段進行修改須要付出的代價是很不相同的。
早期引入變更，涉及的面較少，於是代價也比較低；
　　在開發的中期，軟件配置的許多成分已經完成，引入一個變更要對全部已完成的配置成分都作相應的修改，不只工做量大，並且邏輯上也更復雜，所以付出的代價劇增；
　　在軟件「已經完成」時再引入變更，固然須要付出更高的代價。根據美國一些軟件公司的統計資料，在後期引入一個變更比在早期引入相同變更所需付出的代價高2～3個數量級。圖1.1定性地描繪了在不一樣時期引入一個變更須要付出的代價的變化趨勢。

經過上面的論述不難認識到，輕視維護是一個最大的錯誤。
許多軟件產品的使用壽命長達10年甚至20年，在這樣漫長的時期中
　　必須改正使用過程當中發現的每個潛伏的錯誤；
　　當環境變化時（例如硬件或系統軟件更新換代）還必須相應地修改軟件以適應新的環境；
　　常常改進或擴充原來的軟件以知足用戶不斷變化的須要。
全部這些改動都屬於維護工做，並且是在軟件已經完成以後進行的。所以維護是極端艱鉅複雜的工做，須要花費很大代價。
統計數據代表，實際上用於軟件維護的費用佔軟件總費用的55%~70%。軟件工程學的一個重要目標就是提升軟件的可維護性，減小軟件維護的代價。

1.1.3 消除軟件危機的途徑

爲了消除軟件危機，首先應該對計算機軟件有一個正確的認識。
應該完全消除在計算機系統早期發展階段造成的「軟件就是程序」的錯誤觀念。
一個軟件必須由一個完整的配置組成，事實上，軟件是程序、數據及相關文檔的完整集合。其中，
程序：是可以完成預約功能和性能的可執行的指令序列；
數據：是使程序可以適當地處理信息的數據結構；
文檔：是開發、使用和維護程序所須要的圖文資料。

1983年IEEE爲軟件下的定義是：
    計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據。
    雖然表面上看來在這個定義中列出了軟件的5個配置成分，可是，方法和規則一般是在文檔中說明並在程序中實現的。
    更重要的是，必須充分認識到軟件開發不是某種個體勞動的神祕技巧，而應該是一種組織良好、管理嚴密、各種人員協同配合、共同完成的工程項目。

　　應該推廣使用在實踐中總結出來的開發軟件的成功的技術和方法，而且研究探索更好更有效的技術和方法，儘快消除在計算機系統早期發展階段造成的一些錯誤概念和作法。
　　應該開發和使用更好的軟件工具。
在軟件開發的每一個階段都有許多繁瑣重複的工做須要作，在適當的軟件工具輔助下，開發人員能夠把這類工做作得既快又好。
若是把各個階段使用的軟件工具備機地集合成一個總體，支持軟件開發的全過程，則稱爲軟件工程支撐環境。
總之，爲了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。
軟件工程正是從管理和技術兩方面研究如何更好地開發和維護計算機軟件的一門新興學科。

1.2 軟件工程

1.2.1 軟件工程的介紹

歸納地說，
軟件工程：是指導計算機軟件開發和維護的一門工程學科。
採用工程的概念、原理、技術和方法來開發與維護軟件，把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它，這就是軟件工程。

人們曾經給軟件工程下過許多定義，下面給出兩個典型的定義。
1968年在第一屆NATO會議上曾經給出了軟件工程的一個早期定義：「軟件工程就是爲了經濟地得到可靠的且能在實際機器上有效地運行的軟件，而創建和使用完善的工程原理。」
這個定義不只指出了軟件工程的目標是經濟地開發出高質量的軟件，並且強調了軟件工程是一門工程學科，它應該創建並使用完善的工程原理。
1993年IEEE進一步給出了一個更全面更具體的定義：「軟件工程是： ①把系統的、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件； ②研究①中提到的途徑。」

雖然軟件工程的不一樣定義使用了不一樣詞句，強調的重點也有差別，可是，人們廣泛認爲軟件工程具備下述的本質特性。
1. 軟件工程關注於大型程序的構造
     「大」與「小」的分界線並不十分清晰。一般把一我的在較短期內寫出的程序稱爲小型程序，而把多人合做用時半年以上才寫出的程序稱爲大型程序。傳統的程序設計技術和工具是支持小型程序設計的，不能簡單地把這些技術和工具用於開發大型程序。
    事實上，在此處使用術語「程序」並不十分恰當，如今的軟件開發項目一般構造出包含若干個相關程序的「系統」。

2. 軟件工程的中心課題是控制複雜性
    一般，軟件所解決的問題十分複雜，以至不能把問題做爲一個總體通盤考慮。
    人們不得不把問題分解，使得分解出的每一個部分是可理解的，並且各部分之間保持簡單的通訊關係。
    用這種方法並不能下降問題的總體複雜性，可是卻可以使它變成能夠管理的。
    注意，許多軟件的複雜性主要不是由問題的內在複雜性形成的，而是由必須處理的大量細節形成的。

3. 軟件常常變化
    絕大多數軟件都模擬了現實世界的某一部分。現實世界在不斷變化，軟件爲了避免被很快淘汰，必須隨着所模擬的現實世界一塊兒變化。所以，在軟件系統交付使用後仍然須要耗費成本，並且在開發過程當中必須考慮軟件未來可能的變化。

4. 開發軟件的效率很是重要
    目前，社會對新應用系統的需求超過了人力資源所能提供的限度，軟件供不該求的現象日益嚴重。所以，軟件工程的一個重要課題就是，尋求開發與維護軟件的更好更有效的方法和工具。

5. 和諧地合做是開發軟件的關鍵
    軟件處理的問題十分龐大，必須多人協同工做才能解決這類問題。
    爲了有效地合做，必須明確地規定每一個人的責任和相互通訊的方法。爲了迫使你們遵照規定，應該運用標準和規程。一般，能夠用工具來支持這些標準和規程。
   總之，紀律是成功地完成軟件開發項目的一個關鍵。

6. 軟件必須有效地支持它的用戶
    軟件提供的功能應該能有效地協助用戶完成他們的工做。所以，僅僅用正確的方法構造系統還不夠，還必須構造出正確的系統。
    有效地支持用戶意味着必須仔細地研究用戶，以肯定適當的功能需求、可用性要求及其餘質量要求(例如：可靠性、響應時間等)。
   有效地支持用戶還意味着，軟件開發不只應該提交軟件產品，並且應該寫出用戶手冊和培訓材料，此外，還必須注意創建使用新系統的環境。

7. 在軟件工程領域中是由具備一種文化背景的人替具備另外一種文化背景的人創造產品。
    軟件工程師是諸如Java程序設計、軟件體系結構、測試或統一建模語言(UML)等方面的專家，他們一般並非圖書館管理、航空控制或銀行事務等領域的專家，可是他們卻不得不爲這些領域開發應用系統。
    缺少應用領域的相關知識，是軟件開發項目出現問題的常見緣由。

    軟件工程的基本原理共7條，
    這7條原理互相獨立，其中任意6條原理的組合都不能代替另外一條原理，所以，它們是缺一不可的最小集合；
    這7條原理又是至關完備的，人們雖然不能用數學方法嚴格證實它們是一個完備的集合，可是，能夠證實在此以前已經提出的100多條軟件工程原理均可以由這7條原理的任意組合蘊含或派生。

1. 用分階段的生命週期計劃嚴格管理
    經統計發現，在不成功的軟件項目中有一半左右是因爲計劃不周形成的，可見把創建完善的計劃做爲第一條基本原理是吸收了前人的教訓而提出來的。
    在軟件開發與維護的漫長的生命週期中，須要完成許多性質各異的工做。這條基本原理意味着，應該把軟件生命週期劃分紅若干個階段，並相應地制定出切實可行的計劃，而後嚴格按照計劃對軟件的開發與維護工做進行管理。
    不一樣層次的管理人員都必須嚴格按照計劃各盡其職地管理軟件開發與維護工做，毫不能受客戶或上級人員的影響而擅自背離預約計劃。

2. 堅持進行階段評審
    軟件的質量保證工做不能等到編碼階段結束以後再進行。理由：
    第一，大部分錯誤是在編碼以前形成的，例如，根據Boehm等人的統計，設計錯誤佔軟件錯誤的63%，編碼錯誤僅佔37%；
    第二，錯誤發現與改正得越晚，所需付出的代價也越高。所以，在每一個階段都進行嚴格的評審，以便儘早發如今軟件開發過程當中所犯的錯誤，是一條必須遵循的重要原則。

3. 實行嚴格的產品控制
    在軟件開發過程當中改變需求是不免的，只能依靠科學的產品控制技術來順應這種要求。當改變需求時，爲了保持軟件各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基準配置管理。
    所謂基準配置又稱爲基線配置，它們是通過階段評審後的軟件配置成分。基準配置管理也稱爲變更控制：一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審，得到批准之後才能實施修改。絕對不能誰想修改軟件，就隨意進行修改。

4. 採用現代程序設計技術
    研究各類新的程序設計技術，並進一步研究各類先進的軟件開發與維護技術。
    實踐代表，採用先進的技術不只能夠提升軟件開發和維護的效率，並且能夠提升軟件產品的質量。

5. 結果應能清楚地審查
    軟件產品是看不見摸不着的邏輯產品。軟件開發人員(或開發小組)的工做進展狀況可見性差，難以準確度量，從而使得軟件產品的開發過程比通常產品的開發過程更難於評價和管理。
    爲了提升軟件開發過程的可見性，更好地進行管理，應該根據軟件開發項目的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所獲得的結果可以清楚地審查。

6. 開發小組的人員應該少而精
     開發小組人員的素質和數量是影響軟件產品質量和開發效率的重要因素。
    素質高的人員的開發效率比素質低的人員的開發效率可能高几倍至幾十倍，並且素質高的人員所開發的軟件中的錯誤明顯少於素質低的人員所開發的軟件中的錯誤。
    此外，隨着開發小組人員數目的增長，由於交流狀況討論問題而形成的通訊開銷也急劇增長。
    所以，組成少而精的開發小組是軟件工程的一條基本原理。

7. 認可不斷改進軟件工程實踐的必要性
遵循上述6條基本原理，就可以按照當代軟件工程基本原理實現軟件的工程化生產，可是，僅有上述6條原理並不能保證軟件開發與維護的過程能遇上時代前進的步伐，能跟上技術的不斷進步。
所以，把認可不斷改進軟件工程實踐的必要性做爲軟件工程的第7條基本原理。按照這條原理，不只要積極主動地採納新的軟件技術，並且要注意不斷總結經驗。

1.2.3 軟件工程方法學

軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所造成的工程學科。

管理：就是經過計劃、組織和控制等一系列活動，合理地配置和使用各類資源，以達到既定目標的過程。
一般把在軟件生命週期全過程當中使用的一整套技術方法的集合稱爲方法學(methodology)，也稱爲範型(paradigm)。在軟件工程領域中，這兩個術語的含義基本相同。

軟件工程方法學包含3個要素：
方法、工具和過程。
方法：是完成軟件開發的各項任務的技術方法，回答「怎樣作」的問題；
工具：是爲運用方法而提供的自動的或半自動的軟件工程支撐環境；
過程：是爲了得到高質量的軟件所須要完成的一系列任務的框架，它規定了完成各項任務的工做步驟。

    目前使用得最普遍的軟件工程方法學，分別是傳統方法學和麪向對象方法學。
1. 傳統方法學
傳統方法學：也稱爲生命週期方法學或結構化範型。
    它採用結構化技術(結構化分析、結構化設計和結構化實現)來完成軟件開發的各項任務。
    這種方法學把軟件生命週期的全過程依次劃分爲若干個階段，而後順序地完成每一個階段的任務。

　目前，傳統方法學仍然是人們在開發軟件時使用得十分普遍的軟件工程方法學。
此外，要全面瞭解面向對象方法學，先要了解傳統方法學。

傳統方法學優勢（生命週期方法學或結構化範型）
    把軟件生命週期劃分紅若干個階段，每一個階段的任務相對獨立，並且比較簡單，便於不一樣人員分工協做，從而下降了整個軟件開發工程的困難程度；
    在每一個階段結束以前都從技術和管理兩個角度進行嚴格的審查，保證了軟件的質量，特別是提升了軟件的可維護性。
    總之，採用生命週期方法學能夠大大提升軟件開發的成功率，軟件開發的生產率也能明顯提升。

2. 面向對象方法學
    當軟件規模龐大，或者對軟件的需求是模糊的，或軟件需求會隨時間而變化的時候，使用傳統方法學開發軟件每每不成功。
    此外，使用傳統方法學開發出的軟件，維護起來仍然很困難。
緣由：
    這種技術要麼面向行爲(即對數據的操做)，要麼面向數據，把數據和操做人爲地分離成兩個獨立的部分，天然會增長軟件開發與維護的難度。

面向對象方法學具備下述4個要點。
(1) 把對象(object)做爲融合了數據及在數據上的操做行爲的統一的軟件構件。用對象分解取代了傳統方法的功能分解。
(2) 把全部對象都劃分紅類(class)。
(3) 父類與子類的繼承關係。
    把若干個相關類組成一個層次結構的系統，下層派生類自動擁有上層基類中定義的數據和操做。
(4) 對象彼此間僅能經過發送消息互相聯繫。
        對象的全部私有信息都被封裝在該對象內，不能從外界直接訪問，這就是一般所說的封裝性。

面向對象方法學優勢
面向對象方法學的出發點和基本原則，是儘可能模擬人類習慣的思惟方式，從通常到特殊，從特殊到通常，使開發軟件的方法與過程儘量接近人類認識世界解決問題的方法與過程。傳統方法學強調自頂向下順序地完成軟件開發的各階段任務。事實上，人類認識的過程，是一個漸進的過程，通過屢次反覆才能逐步深化。
運用面向對象方法學的開發軟件，最終的軟件產品由許多較小的、基本上獨立的對象組成，下降了軟件產品的複雜性，提升了軟件的可理解性，簡化了軟件的開發和維護工做。

軟件重用。對象是相對獨立的實體，容易在之後的軟件產品中重複使用。
繼承性和多態性，進一步提升了面向對象軟件的可重用性。

1.3 軟件生命週期

軟件生命週期：由軟件定義、軟件開發和運行維護，直到最終被廢棄所經歷的時期。

每一個時期又進一步劃分紅若干個階段。

軟件定義時期的任務是：
　　肯定軟件開發工程必須完成的總目標；
　　肯定工程的可行性；
　　導出實現工程總目標應該採用的策略及系統必須完成的功能；
　　估計完成該項工程須要的資源和成本，制定工程進度表。
這個時期的工做又稱爲系統分析，由系統分析員負責完成。
這個時期進一步劃分紅3個階段：
　　問題定義、可行性研究和需求分析。

開發時期的任務是：
    設計和實如今前一個時期定義的軟件，它一般由下述4個階段組成：
    整體設計，詳細設計，編碼和單元測試，綜合測試。
    其中前兩個階段又稱爲系統設計，後兩個階段又稱爲系統實現。

維護時期的主要任務是：
使軟件持久地知足用戶的須要。具體地說：
當軟件在使用過程當中發現錯誤時應該加以改正；
當環境改變時應該修改軟件以適應新的環境；
當用戶有新要求時應該及時改進軟件以知足用戶的新須要。維護時期再也不進一步劃分階段。

生命週期每一個階段的基本任務。
1. 問題定義
關鍵問題是：「要解決的問題是什麼?」
弄清楚

2. 可行性研究
關鍵問題是：「對於上一個階段所肯定的問題有行得通的解決辦法嗎?」
任務：探索這個問題是否值得去解，是否有可行的解決辦法。
不是具體解決問題。

3. 需求分析
    主要是肯定目標系統必須具有哪些功能。
    得出通過用戶確認的系統邏輯模型。一般用數據流圖、數據字典和簡要的算法表示。
    任務：是用正式文檔準確地記錄對目標系統的需求，這份文檔一般稱爲規格說明書(specification)。

4. 整體設計
關鍵問題是：「以歸納的方式，應該怎樣實現目標系統?」
整體設計又稱爲概要設計。
主要任務之一：制定出實現最佳方案的詳細計劃。
主要任務之二：設計程序的體系結構，肯定程序由哪些模塊組成以及模塊間的關係。

軟件設計的一條基本原理就是，程序應該模塊化，一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。

5. 詳細設計
    詳細設計階段的任務就是把解法具體化。
任務：
    設計出程序的詳細規格說明，其做用很相似於工程藍圖，它們應該包含必要的細節。
具體地說：
    詳細地設計每一個模塊，肯定實現模塊功能所須要的算法和數據結構。
    詳細設計也稱爲模塊設計，
    還不是編寫程序

6. 編碼和單元測試
    關鍵任務：寫出正確的容易理解、容易維護的程序模塊。

7. 綜合測試
關鍵任務:經過各類類型的測試(及相應的調試)使軟件達到預約的要求。
單元測試，查找各模塊在功能和結構上存在的問題並加以糾正
組裝測試，將已測試過的模塊按必定順序組裝起來
按規定的各項需求，逐項進行有效性測試，決定已開發的軟件是否合格，可否交付用戶使用

8. 軟件維護
關鍵任務：經過各類必要的維護活動使系統持久地知足用戶的須要。
一般有4類維護活動：
改正性維護：診斷和改正在使用過程當中發現的軟件錯誤；
適應性維護：修改軟件以適應環境的變化；
完善性維護：根據用戶的要求改進或擴充軟件使它更完善；
預防性維護：修改軟件爲未來的維護活動預先作準備。

每一項維護活動都要通過：
    提出維護要求(或報告問題)，分析維護要求，提出維護方案，審批維護方案，肯定維護計劃，修改軟件設計，修改程序，測試程序，複查驗收等一系列步驟，實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程。
    每一項維護活動都應該準確地記錄下來，做爲正式的文檔資料加以保存。

1.4 軟件過程

    軟件過程是爲了得到高質量軟件所須要完成的一系列任務的框架，它規定了完成各項任務的工做步驟。
    過程定義了運用方法的順序、應該交付的文檔資料、爲保證軟件質量和協調變化所須要採起的管理措施，以及標誌軟件開發各個階段任務完成的里程碑。
    一般使用生命週期模型簡潔地描述軟件過程。生命週期模型規定了把生命週期劃分紅哪些階段及各個階段的執行順序，所以，也稱爲過程模型。

1.4.1 瀑布模型

    在20世紀80年代以前，瀑布模型一直是唯一被普遍採用的生命週期模型，如今它仍然是軟件工程中應用得最普遍的過程模型。
    傳統軟件工程方法學的軟件過程，基本上能夠用瀑布模型來描述。
圖1.2所示爲傳統的瀑布模型。

按照傳統的瀑布模型開發軟件，有下述的幾個特色。

1. 階段間具備順序性和依賴性
這個特色有兩重含義：
①必須等前一階段的工做完成以後，才能開始後一階段的工做；
②前一階段的輸出文檔就是後一階段的輸入文檔。
2. 推遲實現的觀點
對於規模較大的軟件項目來講，每每編碼開始得越早最終完成開發工做所須要的時間反而越長。

3. 質量保證的觀點
每一個階段都應堅持兩個重要作法：
（1） 每一個階段都必須完成規定的文檔。
（2） 每一個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。

傳統的瀑布模型過於理想化了，事實上，人在工做過程當中不可能不犯錯誤。
所以，實際的瀑布模型是帶「反饋環」的，如圖1.3所示。

當在後面階段發現前面階段的錯誤時，須要沿反饋線返回前面的階段，修正前面階段的產品以後再回來繼續完成後面階段的任務。

瀑布模型有許多優勢：
    強迫開發人員採用規範的方法；
    嚴格地規定了每一個階段必須提交的文檔；
    要求每一個階段交出的全部產品都必須通過質量保證小組的仔細驗證。
    遵照瀑布模型的文檔約束，將使軟件維護變得比較容易一些。
   文檔驅動。

瀑布模型的缺點：
文檔驅動
用戶僅僅經過寫在紙上的靜態的規格說明，很難全面正確地認識動態的軟件產品。
　一旦用戶開始使用最終系統，並對系統有更多的學習之後，觀點會發生很大的變化。用戶的這種變化經常是沒法預測的。
最終產品更多的反映用戶在項目開始時的需求，而不是最後的需求。致使最終開發出的軟件產品不知足用戶需求。

1.4.2 快速原型模型

所謂快速原型：是快速創建起來的能夠在計算機上運行的程序，它所能完成的功能每每是最終產品能完成的功能的一個子集。
如圖1.4所示

快速原型模型的第一步是快速創建一個能反映用戶主要需求的原型系統，讓用戶在計算機上試用它，經過實踐來了解目標系統的概貌。

用戶試用原型系統以後
　　提出許多修改意見，
　　開發人員快速地修改原型系統，
　　而後再次請用戶試用……直到獲得用戶承認，
　　開發人員即可據此書寫規格說明文檔，反映了用戶的真實需求。
所以快速原型模型是不帶反饋環的，這正是這種過程模型的主要優勢：軟件產品的開發基本上是線性順序進行的。

1.4.3 增量模型

增量模型也稱爲漸增模型，如圖1.5所示。

使用增量模型開發軟件時，把軟件產品做爲一系列的增量構件來設計、編碼、集成和測試。

增量模型的優勢：
能在較短期內向用戶提交可完成部分工做的產品；
逐步增長產品功能能夠使用戶有較充裕的時間學習和適應新產品。

使用增量模型的困難是：
在把每一個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。
必須把軟件的體系結構設計得便於按這種方式進行擴充，即加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。
從長遠觀點看，具備開放結構的軟件擁有真正的優點，這樣的軟件的可維護性明顯好於封閉結構的軟件。

     若是一個增量模型的設計很是靈活並且足夠開放，那麼，這樣的設計將容許在不破壞產品的狀況下進行維護。
意味着：
    使用增量模型時開發軟件和擴充軟件功能（完善性維護）沒有本質區別，都是向現有產品中加入新構件的過程。
    維護時期反饋環很小。

1.4.4 螺旋模型

軟件風險是任何軟件開發項目中都廣泛存在的實際問題，項目越大，軟件越複雜，承擔該項目所冒的風險也越大。
軟件風險可能在不一樣程度上損害軟件開發過程和軟件產品質量。

    所以，在軟件開發過程當中必須及時
    識別和分析風險，
    而且採起適當措施，
   以消除或減小風險的危害。

     構建原型是一種能使某些類型的風險降至最低的方法。
    在需求分析階段：經過快速地構建一個原型，下降交付給用戶的產品不能知足用戶須要的風險。
    在後續的階段中也能夠經過構造適當的原型來下降某些技術風險。
    螺旋模型的基本思想是，使用原型及其餘方法來儘可能下降風險，在每一個階段以前都增長了風險分析過程的快速原型，如圖1.7所示簡化的螺旋模型。

Boehm於1988年提出，主要針對大型軟件項目的開發。
四個象限
制定計劃
風險分析
實施工程
客戶評價

制定計劃：肯定軟件項目目標；明確對軟件開發過程和軟件產品的約束；制定詳細的項目管理計劃；根據當前的需求和風險因素，制定實施方案，並進行可行性分析，選定一個實施方案，並對其進行規劃。
風險分析：明確每個項目風險，估計風險發生的可能性、頻率、損害程度，並制定風險管理措施規避這些風險。
實施工程：針對每個開發階段的任務要求執行本開發階段的活動。
客戶評估：客戶使用原型，反饋修改意見；根據客戶的反饋，對產品及其開發過程進行評審，決定是否進入螺旋線的下一個迴路。

1.4.5 噴泉模型

噴泉模型也稱迭代模型，認爲軟件開發過程的各個階段是相互重疊和屢次反覆的，就象噴泉同樣，水噴上去又能夠落下來，既能夠落在中間，又能夠落到底部。
各個開發階段沒有特定的次序要求，徹底能夠並行進行，能夠在某個開發階段中隨時補充其餘任何開發階段中遺漏的需求。

優勢：
提升開發效率
縮短開發週期

缺點：難於管理

1.4.6面向對象過程

RUP

RUP（Rational Unified Process）是由Rational公司（現被IBM公司收購）開發的一種軟件工程過程框架，是一個面向對象的基於web的程序開發方法論。
RUP既是一種軟件生命週期模型，又是一種支持面向對象軟件開發的工具，它將軟件開發過程要素和軟件工件要素整合在統一的框架中。

RUP的基本結構

RUP中的軟件生命週期在時間上被分解爲四個順序的階段：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。
每一個階段結束於一個主要的里程碑(Major Milestones)，並在階段結尾執行一次評估以肯定這個階段的目標是否已經知足。若是評估結果使人滿意的話，能夠容許項目進入下一個階段。

初始階段
目標是爲系統創建商業案例（business case）並肯定項目的邊界。
商業案例包括項目的驗收規範、風險評估、所需資源估計、階段計劃等。
要肯定項目邊界，需識別全部與系統交互的外部實體，並在較高層次上定義外部實體與系統交互的特性，主要包括識別外部角色（actor）、識別全部用例並詳細描述一些重要的用例。
階段結束里程碑：生命週期目標（Lifecycle Objective）里程碑。生命週期目標里程碑包括一些重要的文檔，如：項目構想（vision）、原始用例模型、原始業務風險評估、一個或者多個原型、原始商業案例等。須要對這些文檔進行評審，以肯定正確理解用例需求、項目風險評估合理、階段計劃可行等。

細化階段
目標是分析問題領域，創建健全的體系結構基礎，編制項目計劃，完成項目中高風險需求部分的開發。
里程碑：生命週期體系結構（Lifecycle Architecture）里程碑。生命週期體系結構里程碑包括風險分析文檔、軟件體系結構基線、項目計劃、可執行的進化原型、初始版本的用戶手冊等。經過評審肯定軟件體系結構已經穩定、高風險的業務需求和技術機制已經解決、修訂的項目計劃可行等。

構造階段
將全部剩餘的技術構件和穩定業務需求功能開發出來，並集成爲產品，全部功能被詳細測試。從某種意義上說，構造階段只是一個製造過程，其重點放在管理資源及控制開發過程以優化成本、進度和質量。
里程碑：初始運行能力（Initial Operational Capability）里程碑。包括能夠運行的軟件產品、用戶手冊等，它決定了產品是否能夠在測試環境中進行部署。此刻，要肯定軟件、環境、用戶是否能夠開始系統的運行。

移交階段
移交階段的重點是確保軟件對最終用戶是可用的。交付階段能夠跨越幾回迭代，包括爲發佈作準備的產品測試，基於用戶反饋的少許調整。
里程碑：產品發佈(Product Release)里程碑。此時，要肯定最終目標是否實現，是否應該開始產品下一個版本的另外一個開發週期。在一些狀況下這個里程碑可能與下一個週期的初始階段的相重合。

RUP的迭代增量開發思想
RUP是融合了噴泉模型和增量模型的一種綜合生命週期模型。

RUP的9個核心工做流
6個核心過程工做流
　　商業建模（Business Modeling）
　　需求（Requirements）
　　分析和設計（Analysis & Design）
　　實現（Implementation）
　　測試（Test）
　　部署（Deployment）
3個核心支持工做流：
　　配置和變動管理（Configuration & Change Management）
　　項目管理（Project Management）
　　環境（Environment）

RUP的最佳實踐：
　　短期分區式的迭代：2～6周，不鼓勵時間推遲；
　　適應性開發：小步驟、快速反饋和調整；
　　在早期迭代中解決高技術風險和高業務價值的問題；
　　不斷地讓用戶參與迭代結果的評估，並及時獲取反饋信息，以逐步闡明問題並引導項目進展；
　　在早期迭代中創建內聚的核心架構。該實踐是和早期處理高技術風險和高業務價值問題有關的，由於核心架構通常和高風險因素緊密相關。
　　不斷地驗證質量；儘早、常常和實際地測試；
　　使用用例驅動軟件建模：用例是獲取需求、制定計劃、進行設計、測試、編寫終端用戶文檔的驅動力量。
　　可視化軟件建模：使用UML（Unified Modeling Language，統一建模語言）進行軟件建模。
　　仔細地管理需求：不要草率地對待需求，而要有機地進行需求的提出、記錄、等級劃分、追蹤。拙劣的需求管理是項目陷入麻煩的一個常見緣由。
　　實行變動請求和配置管理。

敏捷模型

　　敏捷建模（Agile Modeling，AM）是由Scott W. Ambler從許多的軟件開發過程實踐中概括總結出來的一些敏捷建模價值觀、原則和實踐等組成的，它只是一種態度，不是一個說明性過程。
　　AM是對已有生命週期模型的補充，它自己不是一個完整的方法論，在應用傳統的生命週期模型時能夠借鑑AM的過程指導思想。
　　極限編程(eXtreme Programming, XP)是敏捷過程當中最富盛名的一個，其名稱中「極限」二字的含義是指把好的開發實踐運用到極致。目前，極限編程已經成爲一個典型的開發方法，普遍應用於需求模糊且常常改變的場合。

敏捷建模的價值觀
　　溝通：建模不但可以促進團隊內部開發人員之間溝通，還可以促進團隊和項目干係人（project stakeholder）之間的溝通。
　　簡單：畫一兩張圖表來代替幾十甚至幾百行的代碼，經過這種方法，建模成爲簡化軟件和軟件開發過程的關鍵。
　　反饋：經過圖表來交流建模想法，能夠快速得到彼此的反饋。
　　勇氣：若是一項決策證實是不合適的時候，就須要勇氣作出重大的決策：放棄或重構（refactor）先前的工做，修正建模方向。
　　謙遜：最優秀的開發人員都擁有謙遜的美德，他們總能認識到本身並非無所不知的。

敏捷建模核心原則：
　　主張簡單；
　　擁抱變化；
　　軟件開發的第二個目標應是可持續性
　　遞增的變化
　　令項目干係人投資最大化
　　有目的地建模

　　多種模型
　　高質量的工做
　　快速反饋
　　以有效的方式，製造出知足項目干係人所須要的軟件，而不是製造無關的文檔、無關的用於管理的工件，甚至無關的模型
　　輕裝前進

敏捷模型補充原則：
　　內容比表示更重要
　　三人行必有我師
　　瞭解軟件建模方法
　　瞭解軟件開發工具
　　局部調整
　　開放誠實的溝通
　　利用好直覺

敏捷建模核心實踐(極限編程)
項目干係人的積極參與
正確使用工件
集體全部制
測試性思惟
並行建立模型
建立簡單的內容
簡單地建模
公開展現模型
切換到另外的工件
小增量建模
和他人一塊兒建模
用代碼驗證
使用最簡單的工具

敏捷模型補充實踐：
使用建模標準
逐漸應用模式（pattern）
丟棄臨時模型
合同模型要正式
爲外部交流建模
爲幫助理解建模
重用現有的資源
不到萬不得已不更新模型

極限編程的有效實踐（特點）

客戶做爲開發團隊的成員（不必定是真客戶）
使用用戶素材（用戶故事，記錄在卡片上）
短交付週期（兩週-一個月）
驗收測試
結對編程
測試驅動開發
集體全部
持續集成
可持續的開發速度（每週40個小時）
開放的工做空間
及時調整計劃
簡單的設計
重構
使用隱喻（隱喻至關於體系結構，從客戶角度來描述一個項目的全局，用戶故事則從局部來描述）

極限編程的開發過程

極限編程的迭代過程

極限編程的特色

綜上所述，以極限編程爲表明的敏捷過程，具備對變化和不肯定性的更快速，更敏捷的反映特性，並且在快速的同時仍然能保持可持續的開發速度。上述這些特色使得敏捷過程可以較好的適應商業競爭環境下對小型項目提出的有限資源和有限開發時間的約束。

微軟過程

做爲世界上最大的同時也是最成功的軟件公司之一，Microsoft（微軟）公司擁有本身獨特的軟件開發過程，幾十年的實踐證實微軟過程是很是成功和行之有效的。

主要內容
微軟過程準則
微軟軟件生命週期
微軟過程模型

微軟過程準則

項目計劃應該兼顧將來的不肯定因素
用有效的風險管理來減小不肯定因素的影響
常常生成並快速地測試軟件的過渡版本，從而提升產品地穩定性和可預測性
採用快速循環，遞進地開發過程
用創造性地工做來平衡產品特性和產品成本
項目進度表應該具備較高穩定性和權威性
使用小型項目組併發地完成開發工做
在項目早期把軟件配置項基線化，項目後期則凍結產品
使用原型驗證概念，對項目進行早期論證
把零缺陷做爲追求的目標
里程碑評審會的目的是改進工做，切忌相互指責

微軟軟件生命週期

五個階段及里程碑

（1）規劃階段
肯定產品目標。
獲取競爭對手的信息。
完成對客戶和市場的調研分析。
肯定新版本產品應具有的主要特徵。
肯定相對於前一版本而言，新版本應該解決的問題和須要增長的功能。
（2）設計階段
根據產品目標編寫系統的特性規格說明書。主要描述軟件特性、系統結構、各構件間的相關性以及接口標準。
從系統高層着手開始進行系統設計，主要完成：系統設計方案，描繪系統結構圖，肯定系統中存在的風險因素，分析系統的可重用性。
劃分出系統的子系統，給出各自系統和各個構件的規格說明。
根據產品特性規格說明書制定產品開發計劃。
（3）開發階段
完成產品中全部構件的開發工做，包括編寫程序代碼和書寫文檔。
（4）穩定階段
對產品進行測試和調式，以確保已經正確地實現了整個解決方案，產品能夠發佈了。
（5）發佈階段
發佈產品獲解決方案，並把項目移交到運營和支持人員手中，以得到最終用戶對項目的承認。