軟體工程經濟學總成本

㈠ 軟體工程經濟環境

軟體工程學的主要內容是軟體開發技術和軟體工程管理． 需要用到高中計算機科學、數學：用於軟體模型的建立與演算法設計。 工程管理科學：用於制訂規范和文檔標准，建立成本分析、監督復審的技術。 管理科學：用於軟體計劃、資源、成本的控制與管理。軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。

㈡ 軟體工程經濟學問題

軟體成本的測算影響的因素很多，難以准確的測算，只能說在10%的准確度，任務復雜，所以測算困難。
測算流程可以參考一下這個：http://wenku..com/view/9bf91ad026fff705cc170ad9.html

下面是構成，不知道能否幫到你哦
系統軟體的成本構成
系統軟體的成本作為一個經濟學范疇，應反映軟體產品在其生產過程中所耗費的各項費用，為原材料、燃料、動力、折舊、人工費、管理費用、財務費用待項開支的總和。
從財務角度來看，列入系統軟體的成本有如下的項目：
（1）硬體購置費如計算機及相關設備的購置，不 間斷電源、空調器等的購置費。
（2）軟體購置費，如操作系統軟體、資料庫系統軟體和其它應用軟體的購 置費。
（3）人工費，主要是開發人員、操作人員、管理人員、的工資福利費等。
（4）培訓費。
（5）通訊費，如 購置計算機網路設備、通訊線路器材、租用公用通訊線路等的費用。
（6）基本建設費，如新建、擴建機房、購置計算機機台、機櫃等的費用。
（7）財務費用。
（8）管理費用，如辦公費、差旅費、會議費、交通費。
（9）材料費，如列印紙、包帶、磁碟等的購置費。
（10）水、電、汽、氣費。
（11）專有技術購置費。
（12）其它費用，如資料費、固定資產折舊費及咨詢費。
系統軟體的成本由軟體的開發和維護成本所構成，即： C=C1+C2
式中：C為系統軟體的開發成本；C1為系統軟體的開發成本所構成；C2為系統軟體的維護成本。
1、系統軟體的開發成本C1的測算。
我們認為系統軟體的開發成本按其工作量及單位工作量成本來測算是可行的，具體測算方法為按系統軟 件的軟體規模（一般為軟體源程序的指令行數，不包括注釋行）、社會平均規模指數以及工作量修正因素來 進行。尤其是CAD系統軟體的實際測算，結合國內外研究成果的綜合分析和專家咨詢，軟體社會平均生產率 參數和軟體社會平均規模指數可分別確定為3.5和1.3左右；軟體工作量訂由八個因子、五個等級組成。
2、系統軟體維護成本C2的測算。
系統軟體的維護為修正現有可運行軟體並維護欺其主要功能不變的過程。系統軟體在其交付使用後，其維護階段在軟體生命周期或生存期中占較大比重，有的可達軟體生存周期的50-70%.因此，系統軟體的維護成本是軟體成本測算中不可忽略的一部分。
系統軟體的維護包括三類：A、改正、糾正性維護；B、適應性維護；C、完美性維護。其中C類是為擴充 功能、提高性能而進行的維護，在軟體資產價值評估中一般不計入該系統軟體成本，而A、B兩類，則與軟 件的開發過程有著緊密的聯系，應計入軟體成本。
在系統軟體維護階段，對軟體工作量的影響因素與開發階段的影響因素基本相同，是開發階段影響因素 的後的影響。因此，系統維護的可靠性越大，規模越復雜，隱錯越難發現，糾錯越難。系統軟體越復雜， 要使其適應軟、硬環境變化，進行適應性維護也越困難。當然，可靠性大、復雜度高的系統軟體，其可維 護性要求也越高，軟體在運行中出錯的可能性也會少些。基於上述分析，系統軟體維護成本的測算，可按 系統軟體開發成本乘以一個該系統軟體的維護參數來求取。這一維護參數，可按系統軟體的復雜度從簡單 到一般、到復雜的順序，分別取0.15、0.20、0.25及0.30、0.35、0.40等。

㈢ 軟體工程的意義和作用

提高軟體開發的效率和質量。使軟體開發標准化，工業化。

㈣ 簡述什麼是軟體工程

軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科，它涉及程序設計語言、資料庫、軟體開發工具、系統平台、標准、設計模式等多方面。 現代社會，軟體幾乎應用於各個行業，如工業、農業、銀行、航空、政府部門等，這些應用促進了經濟和社會的發展，使得人們的工作效率和生活效率得以提高。典型的軟體有電子郵件、嵌入式系統、人機界面、辦公套件、操作系統、編譯器、資料庫、游戲等。
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義。

BarryBoehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE：在軟體工程術語匯編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體；2.在1中所述方法的研究

FritzBauer：在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

《計算機科學技術網路全書》：軟體工程是應用計算機科學、數學、邏輯學及管理科學等原理，開發軟體的工程。軟體工程借鑒傳統工程的原則、方法，以提高質量、降低成本和改進演算法。其中，計算機科學、數學用於構建模型與演算法，工程科學用於制定規范、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。

比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。

㈤ 《工程經濟學》什麼是功能整理

功能整理，是指在對價值工程對象進行功能定義後，應用系統思想方法，找出產品各項功能之間的邏輯關系，組成一個體系，並用圖表形式表達。功能整理的目的在於掌握必要功能，認定功能定義的正確性，劃分功能領域，並為功能價值的定量評價發現和消除不必要功能，作好准備。

功能整理是指通過對產品及零部件的全部功能加以劃分功能類別，明確功能系統，剔除或修正不必要的多餘功能，區分基本功能、輔助功能、外觀功能和畫出功能系統圖等一系列工作。

功能整理是指通過對產品及零部件的全部功能加以劃分功能類別，明確功能系統，剔除或修正不必要的多餘功能，區分基本功能、輔助功能、外觀功能和畫出功能系統圖等一系列工作。目的是要搞清各個功能之間的關系，區分「目的功能」和「手段功能」。

「目的功能」定下之後，「手段功能」可以廣泛選擇，通過整理，去掉無目的的手段，或選擇更好的手段。

(5)軟體工程經濟學總成本擴展閱讀：

《工程經濟學》軟體開發技術和軟體工程管理：

1、軟體工程的理論和技術性研究的內容主要包括軟體開發技術和軟體工程管理；

2、軟體開發技術包括軟體開發方法學、開發過程、開發工具和軟體工程環境，其主體內容是軟體開發方法學；

3、軟體開發方法包括分析方法，設計方法和程序設計方法；

4、軟體工程管理包括軟體管理學，軟體工程經濟學，軟體心理學等；

5、軟體管理學包括人員組織，進度安排，質量保證，配置管理，項目計劃等；

6、軟體工程經濟學是研究軟體開發中成本的估算，成本效益的方法和技術。

軟體工程的原則：抽象，信息隱蔽，模塊化，局部化，確定性，一致性，完備性，可驗證性。

㈥ 什麼是軟體工程經濟學軟體工程經濟分析的基本要素是什麼

軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及程序設計語言、資料庫、軟體開發工具、系統平台、標准、設計模式等方面。在現代社會中，軟體應用於多個方面。典型的軟體有電子郵件、嵌入式系統、人機界面、公套件、操作系統、編譯器、資料庫、游戲等。同時，各個行業幾乎都有計算機軟體的應用，如工業、農業、銀行、航空、政府部門等。這些應用促進了經濟和社會的發展，也提高了工作效率和生活效率。研究領域有：軟體架構、軟體設計方法、軟體領域建模、軟體工程決策支持、軟體工程教育、軟體測試技術、自動化的軟體設計和合成、基於組件的軟體工程、計算機支持的協同工作、編程語言和軟體工程、計算機網路、信息與通信安全、計算機圖形學與人機交互、多媒體技術應用、人工智慧與識別、嵌入式軟體與應用、自動控制、分布式計算與網格計算、雲計算技術、存儲技術、資料庫技術研究、計算機輔助設計與應用技術、大數據分析與處理

㈦ 軟體工程主要學習的是什麼需要用到高中哪幾門學科的知識啊

軟體工程學的主要內容是軟體開發技術和軟體工程管理．
需要用到高中計算機科學、數學：用於軟體模型的建立與演算法設計。
工程管理科學：用於制訂規范和文檔標准，建立成本分析、監督復審的技術。
管理科學：用於軟體計劃、資源、成本的控制與管理。
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。

㈧ 關於軟體工程這門課程

軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：

Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。

Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。

軟體工程基本原理

著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

軟體工程必須遵循什麼原則

圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：

(1)選取適宜的開發模型

該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。

(2)採用合適的設計方法

在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

(3)提供高質量的工程支撐

工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

(4)重視軟體工程的管理

軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。

軟體工程是指導計算機軟體開發和維護的工程學科。

採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。

軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。

把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。

目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。

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

開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。

維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。

下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。

2可行性研究

這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：

低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。

上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。

5詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」

這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。

通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。

6編碼和單元測試

這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。

程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。

7綜合測試

這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。

最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。

為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。

應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。

8軟體維護

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。

雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

㈨ 軟體工程該學習些什麼

書的話，如果是入門，我推薦《C++入門經典》（第三版），這本書由淺入深，章節安排很合理。樓上各位提到的《C++ Primer》這本我覺得不適合初學者，因為章節安排不是循序漸進的。至於譚浩強的書，我沒看過他寫的C++，所以不做評論。但是我看過他寫的C語言的書，被人稱之為「方言版的C語言」，雖然好懂，但是不標準的寫法甚至錯誤的寫法，懂了又有何用。如果是有C++基礎了，那麼，可以看《C++編程思想》、《C++編程規范》等等。其實學習的重點放在哪裡那是根據個人習慣及熟練程度而定，不要太看重，多看看書，你會有所體會的。但是，注意，一次主攻一本書，不能雜，另外的書只能當做參考。上面提到的幾本書我都有電子版的，你提供郵箱，我可以發給你。反正我都是看的電子版的，畢竟正版書太貴了，盜版也難找到。

程序設計重在實踐。編寫代碼不用太急，慢慢來，從簡單的寫起，我不建議首先進行手寫，那樣沒實際意義，即使再簡單，拿到計算機上去跑，然後逐步修改並添加功能。就拿我當初看到 vector 這個東西時來說吧，我覺得 push_back() 這個成員函數很好用，所以我就寫了那麼兩三行，只是為了看看 push_back() 這個成員函數的作用。所以，我覺得，書上的代碼在最開始沒必要完整的寫一遍，因為那些可能涉及到還沒有看到的內容。看到了新東西，就可以簡單的自己去驗證一下那麼一點小功能，像這樣小的東西寫多了自然就熟悉了，之後寫稍微長的代碼就更熟練。同時，對於書上的一些代碼，先不要急這自己獨立寫出來，畢竟別人寫書的，對於出版出來的代碼應該是經過精心設計的，其中很可能就用到一些技巧，剛開始寫不出很正常，主要是因為不熟練。
慢慢的，當你對於C++中的新東西有個比較清楚的認識後（不用急著記住每個新東西），你可以將以前自己用C寫過的代碼改成C++方式，比如，一般的數組用vector代替，C風格的字元串用C++中的 string 類型替代，這樣寫出C++版本的代碼。如果以前用C寫過得東西不多，你可以將書上的習題來練習。寫多了，熟悉了，以後寫代碼就逐漸轉變成C++的代碼風格。由於C++標准庫很強大，所以，以前很多C代碼都可以修改得更精簡，看起來更舒服！
到了後面的高級內容，開始可以就簡單的將書上完整的代碼抄寫一遍（不是手寫），然後進行一定得調試。此時候要注意的不是代碼的具體功能，而是其中代碼風格。比如，類，注意構造函數，析構函數該怎樣寫，成員的對外可見性如何寫，等等。創造的話，如果看完了類，並且懂得類書寫的基本風格，那麼，你可以用自己的方法寫出一個 vector 類，當然，此時不需要處理異常，不需要完整的實現標准版本的功能，就實現諸如 push_back(), size(), empty()等功能，然後用自己寫的類進行別的操作。之後，諸如deque,list等等都可以用自己的方法實現。同時，這時候寫的代碼也可以留作以後逐步完善，等你非常牛逼時候，就寫出了不遜色於標准庫的代碼了。

總之，我認為，不因為寫那麼兩三行代碼拿到電腦上去跑就嫌麻煩，多在實際中跑自己寫的代碼，由簡單的寫起，由兩三行寫起。C++對於C來說有很多新東西，每看到一個，就自己寫寫去驗證，一個一個來，慢慢的組合那些小的細節以實現更多功能。此時，不要太看重演算法，數據結構，就像英語，學習語法時，我們主要學應用語法造句，而不是學造文章，文章是之後的事。這只是個學習的先後次序問題

最後，代碼風格一定要標准規范，可以附加看看《C++編程規范》等。不懂的問題及時在書上或者到網上搜查。