在現代社會中，軟件被用在許多方面。電子郵件、嵌入式系統、人機界面、辦公套件、操作系統、編譯器、數據庫、遊戲等典型軟件。同時，幾乎所有的行業都有計算機軟件應用，比如工業、農業、銀行、航空、政府部門等等。這些應用促進了經濟和社會發展，提高了人們的工作效率，改善了生活質量。
軟件工程師是用軟件創造軟件的人的總稱。軟件工程師根據領域的不同可以分為系統分析師、軟件設計師、系統架構師、程序員、測試人員等等。程序員通常用來指代各種軟件工程師。
軟件工程的框架可以概括為:目標、過程和原則。
(1)軟件工程目標:生產出正確、可用、費用適當的產品。正確性是指軟件產品實現預期功能的程度。可用性是指軟件的基本結構、實現和文檔對用戶可用的程度。適度成本是指軟件開發和運行的整體成本滿足用戶要求的程度。這些目標的實現在理論和實踐上都有許多問題需要解決，對工藝、工藝模型和工程方法的選擇形成制約。
(2)軟件工程過程:生產壹個最終能滿足需求、達到工程目標的軟件產品所需的步驟。軟件工程過程主要包括開發過程、運行過程和維護過程。它們涵蓋需求、設計、實現、驗證和維護等活動。需求活動包括問題分析和需求分析。問題分析獲得需求的定義，也稱為軟件需求規範。需求分析產生功能規格。設計活動通常包括總體設計和詳細設計。概要設計確立了整個軟件體系結構，包括子系統、模塊和相關層次的描述，以及各個模塊的接口定義。詳細設計生成程序員可用的模塊描述，包括每個模塊中的數據結構描述和處理描述。實施活動將設計結果轉化為可執行的程序代碼。確認活動貫穿整個開發過程，實現完成後的確認，確保最終產品滿足用戶的要求。維護活動包括使用過程中的擴展、修改和改進。與上述流程相伴隨的，還有管理流程、支持流程、培訓流程等等。
(3)軟件工程原則是指圍繞工程設計、工程支持和工程管理，在軟件開發過程中必須遵循的原則。
壹、軟件工程概述
概念:按需而生
軟件工程是工程的壹種。工程學是壹門將理論和知識應用於實踐的科學。就軟件工程而言，它借鑒傳統工程的原理和方法，以便高效地開發高質量的軟件。計算機科學，數學，管理科學都是應用的。計算機科學和數學用於構建模型和算法，工程科學用於制定規範、設計範例、評估成本和確定權衡，管理科學用於管理計劃、資源、質量和成本。
軟件工程的概念主要是針對20世紀60年代的“軟件危機”而提出的。它最早出現在1968年的北約(北大西洋公約組織)會議上。自這壹概念提出以來，圍繞軟件項目開展了對開發模型、方法和支持工具的研究。其主要成果有:提出了瀑布模型，開發了壹些結構化程序設計語言(如PASCAL和Ada)和結構化方法。並圍繞項目管理提出了成本估算、文檔評審等方法和工具。縱觀60年代末80年代初，其主要特點是，前期以系統實現技術為主，後期開始強調開發管理和軟件質量。
自20世紀70年代初“軟件工廠”概念提出以來，軟件生產技術和軟件生產管理的研究與實踐主要圍繞軟件過程和軟件復用展開。其主要成果有:提出了廣泛使用的面向對象語言和相關的面向對象方法，大力開展了計算機輔助軟件工程的研究和實踐。特別是近年來，軟件構件技術、軟件質量控制技術和質量保證技術被廣泛應用於軟件復用和軟件生產。目前各軟件企業都非常重視資質認證，都想通過這些工作提升企業管理和技術。軟件工程中涉及的元素可以總結如下:
根據這個框架，我們可以看到軟件工程涉及到軟件工程的目標、原則和活動。
目標:我只關註“產品”
軟件工程的主要目標是生產具有正確性、可用性和適當費用的產品。正確性是指軟件產品實現預期功能的程度。可用性是指軟件的基本結構、實現和文檔對用戶可用的程度。成本適當性是指軟件開發和運行的整體成本滿足用戶要求的程度。這些目標的實現在理論和實踐上都有許多問題需要解決，對工藝、工藝模型和工程方法的選擇形成制約。
軟件工程活動是“生產壹個最終滿足需求並實現工程目標的軟件產品所需的步驟”。主要包括需求、設計、實現、確認、支持等活動。需求活動包括問題分析和需求分析。問題分析獲得需求的定義，也稱為軟件需求規範。需求分析產生功能規格。設計活動通常包括總體設計和詳細設計。概要設計建立了整個軟件架構，包括子系統、模塊和相關層次的描述，以及每個模塊的接口定義。詳細設計生成程序員可用的模塊描述，包括每個模塊中的數據結構描述和處理描述。實施活動將設計結果轉化為可執行的程序代碼。確認活動貫穿整個開發過程，實現完成後的確認，確保最終產品滿足用戶的要求。支持活動包括修訂和改進。與上述活動相伴隨的，還有管理流程、支持流程、培訓流程等等。
框架:四項基本原則是基石。
軟件工程圍繞工程設計、工程支持和工程管理提出了以下四個基本原則:
首先，選擇壹個合適的開發模式。這個原理和系統設計有關。在系統設計中，軟件需求、硬件需求等因素相互制約、相互影響，往往需要權衡。因此，我們必須了解需求定義的可變性，並采用合適的開發範式來控制它，以確保軟件產品滿足用戶的需求。
第二，采用合適的設計方法。在軟件設計中，通常會考慮軟件的模塊化、抽象性、信息隱蔽性、本地化、壹致性和適應性等特點。合適的設計方法有助於實現這些功能，從而實現軟件工程的目標。
第三，提供高質量的工程支持。工欲善其事，必先利其器。在軟件工程中，支持軟件過程的軟件工具和環境是非常重要的。軟件工程項目的質量和成本直接取決於提供給軟件工程的支持的質量和有效性。
第四，註重開發過程的管理。軟件工程的管理直接影響到可用資源的有效利用，滿足目標的軟件產品的生產，以及軟件組織生產能力的提高。因此，只有對軟件過程進行有效的管理，才能實現有效的軟件工程。
這個軟件工程框架告訴我們，軟件工程的目標是可用性、正確性和成本效益；實施壹個軟件項目，需要選擇合適的開發範式，采用合適的設計方法，提供高質量的工程支持，並對開發過程實施有效的管理；軟件工程活動主要包括需求、設計、實現、確認和支持，每個活動可以根據具體的軟件工程采用合適的開發範式、設計方法、支持過程和過程管理。按照軟件工程的框架，軟件工程學科的研究內容主要包括:軟件開發範式、軟件開發方法、軟件過程、軟件工具、軟件開發環境、計算機輔助軟件工程(CASE)和軟件經濟學。
功能:高效開發高質量的軟件。
自軟件工程概念提出以來，經過30多年的研究和實踐，雖然“軟件危機”並沒有完全解決，但是軟件開發方法和技術已經取得了很大的進步。特別需要指出的是，從20世紀80年代中期開始，美國工業界和政府部門開始意識到軟件開發中最關鍵的問題是軟件開發組織不能很好地定義和管理他們的軟件過程，以至於壹些好的開發方法和技術不能發揮預期的作用。換句話說，在沒有良好定義和管理的軟件過程的軟件開發中，開發組織不能從好的軟件方法和工具中獲益。
據調查，中國現在的情況和10多年前的美國差不多。軟件開發流程定義不清晰，文檔不完整，不規範。軟件項目的成功往往歸功於軟件開發團隊中壹些傑出的個人或團隊的努力。這種依賴於個人的成功不能為整個組織的軟件生產率和質量的提高奠定有效的基礎。只有建立整個組織的過程改進，采用嚴格的軟件工程方法和管理，並堅持不懈地付諸實踐，才能實現整個組織的軟件過程能力的持續改進。
這個事實告訴我們，只有堅持軟件工程的四個基本原則，重視軟件技術的應用和軟件工程的支持與管理，並在實踐中貫徹執行，才能高效地開發出高質量的軟件。
二、軟件工程的七個基本原則
自1968提出“軟件工程”這壹術語以來，研究軟件工程的專家學者提出了100多條關於軟件工程的原則或信條。美國著名軟件工程專家Boehm綜合了這些專家的意見，總結了TRW多年來開發軟件的經驗，在1983中提出了軟件工程的七個基本原則。
Boehm認為，七項原則是保證軟件產品質量和開發效率的最低原則集。
它們相互獨立，是不可或缺的最小集合。同時，它們是相當完整的。
當然，人們無法用數學方法嚴格證明它們是壹個完整的集合，但可以證明，在此之前已經提出的100多個軟件工程準則可以包含或衍生出這七個原則的任意組合。
以下是軟件工程的七個原則:
1采用分階段生命周期計劃嚴格管理。
本文是在借鑒前人的基礎上提出的。統計數據顯示，50%以上的失敗項目都是由於計劃不周造成的。在軟件開發和維護的漫長生命周期中，需要完成許多不同種類的工作。這個原則就是要把軟件的生命周期分成幾個階段，並據此制定壹個可行的計劃，然後嚴格按照計劃管理軟件的開發和維護。Boehm認為，在整個軟件生命周期中應規定並嚴格執行六種計劃:項目總結計劃、裏程碑計劃、項目控制計劃、產品控制計劃、驗證計劃和運維計劃。
2 .堅持階段復習
統計結果表明，大多數錯誤是在編碼前產生的，約占63%；& lt2 & gt壹個錯誤發現得越晚，糾正它的成本就越大，是2到3個數量級。所以軟件的質量保證不能等到編碼結束，要堅持嚴格的階段評審，以便盡早發現錯誤。
3.實施嚴格的產品控制
開發人員最討厭的事情之壹就是改變需求。但實踐告訴我們，需求的變化往往不可避免。這就要求我們采用科學的產品控制技術來滿足這壹要求。也就是說要采用變更控制，也就是基準配置管理。當需求發生變化時，其他階段的文檔或代碼也隨之變化，以保證軟件的壹致性。
4.采用現代編程技術
從六七十年代的結構化軟件開發技術到最近的面向對象技術，從第壹、二代語言到第四代語言，人們已經充分認識到方法和力量壹樣強大。采用先進的技術不僅可以提高軟件開發的效率，還可以降低軟件維護的成本。
應該清楚地回顧結果。
軟件是壹種看不見摸不著的邏輯產品。軟件開發團隊的工作進度可視性差，難以評估和管理。為了更好地管理，應該根據軟件開發的總體目標和完成期限，明確定義開發團隊和產品標準的職責，以便對獲得的標準進行清晰的評審。
6開發團隊的人員要少而精。
開發人員的質量和數量是影響軟件質量和開發效率的重要因素，應該少而精。
這篇文章基於兩個原因:高質量開發人員的效率比低質量開發人員高幾倍到幾十倍，開發工作中犯的錯誤也少很多；當開發團隊由N人組成時，可能的溝通渠道為N(N-1)/2，說明隨著人數N的增加，溝通成本會急劇增加。
7.承認持續改進軟件工程實踐的必要性。
遵循以上六個基本原則，可以更好地實現軟件的工程化生產。但它們只是對已有經驗的總結和歸納，並不能保證趕上技術不斷發展的步伐。因此，Boehm提出軟件工程的第七個原則應該是認識到軟件工程實踐持續改進的必要性。根據這壹原則，既要積極采用新的軟件開發技術，又要註意不斷總結經驗，收集進度、消耗等數據，統計錯誤類型和問題。這些數據不僅可以用來評估新軟件技術的效果，還可以指出必須註意的問題和應該首先研究的工具和技術。
面向方面編程(AOP)被認為是近年來軟件工程的又壹重要發展。這裏的方面指的是完成壹個功能的對象和功能的集合。在這方面，有泛型編程和模板。
涉及
胡昆山，中國軟件產業發展現狀及人才需求，2003年9月1，/pub/article/C372 _ a 62973 _ p 1 . html。
第三，軟件工程的目標和通用模型
軟件工程的目標是提高軟件的質量和生產率，最終實現軟件的工業化生產。質量是軟件需求者最關心的問題，用戶即使不要物美價廉，也要求正版。生產力是軟件供應商最關心的問題，老板和員工都希望在更短的時間內賺更多的錢。質量和生產力有著內在的聯系，高生產力必須建立在合格的質量基礎上。質量不達標，對供需雙方都不好。從短期效益來看，追求高質量會延長軟件開發時間，增加成本，似乎降低了生產力。從長遠的效益來看，高質量會保證軟件開發的全過程更加規範流暢，大大降低軟件的維護成本，本質上是提高生產力，獲得良好的口碑。質量和生產力並不存在根本矛盾，壹個好的軟件工程方法可以同時提高質量和生產力。
軟件供需雙方代表能在飯桌上談笑風生，得益於壹線開發人員的辛勤工作。質量和生產率的提高依賴於程序員和程序經理。對於開發者來說，如果質量和生產力之間壹定要有個先後順序，那應該是質量第壹，生產力第二。這是因為:(1)質量直接體現在軟件的每壹個程序中，高質量自然是開發者的技術追求，也是職業道德的要求。(2)高質量對所有用戶都有價值，而高生產力只對開發者有意義。(3)如果壹開始就追求高生產率，容易讓人急功近利，留下隱患。為了長遠利益，還不如放慢進度，保證各個環節的質量。
軟件的質量因素有很多，如正確性、性能、可靠性、容錯性、易用性、靈活性、可擴展性、可理解性、可維護性等等。有些因素相互重疊，有些則相互矛盾。真正提高質量不容易！
軟件工程的主要環節包括:人員管理、項目管理、可行性與需求分析、系統設計、程序設計、測試與維護，如圖1.1。
軟件工程模型認為，所有的環節都要通過壹定的流程連接起來，整個流程可以標準化操作，就像工廠的生產線壹樣。常見的軟件工程模型有:線性模型(圖1.2)，增量模型(圖1.3)，螺旋模型，快速原型模型，形式化描述模型等等【按mam 1999，sommerville 1992】。
最早的軟件工程模型是線性模型(又稱瀑布模型)。線性模型過於理想化和簡單，不再適合現代軟件開發模式，幾乎被業界所拋棄。偶爾被人提起，都屬於被降職的對象，沒有留下壹絲遺憾。但我們要認識到，“線性”是最容易掌握和熟練運用的思維方法。當人們遇到壹個復雜的“非線性”問題時，總是想盡辦法將其分解或轉化為壹系列簡單的線性問題，然後逐壹求解。壹個軟件系統的整體可能很復雜，但單個的子程序總是很簡單的，可以用線性的方式實現，否則會累得無法工作。線性是壹種簡單，簡單就是美。當我們理解線性的精神時，我們不應該機械地套用線性模型的外觀，而是生動地使用它。例如，增量模型本質上是分段線性模型，如圖1.3所示。螺旋模型是壹個連續的曲線線性模型。線性模型的影子可以在其他模型中找到。
對程序員來說，應用固定的模型不是明智之舉。比如“編程”和“測試”的關系，傳統上認為是先編程後測試，如圖1.4(a)。對於壹些復雜的程序，將測試分為同步測試和總測試更有效，如圖1.4(b)。
不管是什麽軟件工程模型，總有圖1.1的鏈接。本書從壹個具體的軟件工程模型開始，依次描述了人員管理、項目管理、可行性和需求分析、系統設計、程序設計、測試以及維護和再生工程。編程部分以C++/C語言為例。
第四，軟件架構和工具的選擇
軟件體系結構表示壹個軟件系統的高層結構，其主要特點是:1)軟件系統體系結構是壹種高層抽象，不涉及具體的系統架構(如B/S或C/S)也不關心具體的實現。2)軟件架構必須支持系統所需的功能，在設計軟件架構時必須考慮系統的動態行為。3)在設計軟件架構時，必須考慮現有系統的兼容性、安全性和可靠性。同時也要考慮系統未來的擴展性和可伸縮性。所以有時候妳要在不同方向的多個目標中做決定。
目前有壹些標準化的軟件架構，如ISO開放系統互聯模型、X Window系統等。軟件系統的結構通常被定義為兩部分:壹部分是計算組件。另壹個是組件之間的交互。如果把軟件系統看成壹幅畫，計算組件就是節點，組件之間的交互就是節點之間的弧線。組件之間的連接可以認為是壹種連接器，如過程調用、事件廣播、數據庫查詢等。正確的體系結構設計是軟件系統成功的關鍵。
我們明白了軟件工程的重要性之後，卻沒有相應的工具，我們很難很好的完成壹個系統。在需求分析和設計階段，我們需要什麽樣的工具？
當然，最好使用基於UML的CASE工具。目前流行的是Rose，它是壹個很好的分析和建立對象和對象關系的工具。編碼時，我們需要版本控制工具，MS的SourceSafe就是壹個很好的版本管理工具和項目管理工具。當然，具體的開發工具有很多，但是如果妳是壹個濫用VC多年的程序員，妳壹定會選擇它，因為它會讓妳感受到什麽是真正的面向對象編程，而妳在使用VB、PowerBuilder、Delphi的時候很少有這種感覺。至於數據庫模式構建，我壹直用Sybase的S-Design，不知道有沒有更好的工具。
另外需要註意的是，我們需要建立幾個文檔編寫的模板，以便開發人員根據這些模板編寫標準的技術和說明文檔。幫助文檔可以在微軟的HTML Help Workshop(hhw.exe)中制作，也可以編譯成。chm格式。它只有壹個文件，使用和分發都很方便。最後，如果開發者不集中在壹個地方，最好建立壹個郵件列表，開發者可以通過郵件系統討論開發中的各種問題。
動詞 （verb的縮寫）軟件開發方法概述
國外大型軟件公司和機構壹直在研究軟件開發方法的概念，也提出了許多實用的開發方法，如生命周期法、原型法、面向對象法等。以下是壹些流行的開發方法:
1，結構化方法
結構化開發方法是由E.Yourdon和L.L.Constantine提出的，也就是所謂的SASD方法，也可以稱為面向功能的軟件開發方法或面向數據流的軟件開發方法。Yourdon方法是20世紀80年代應用最廣泛的軟件開發方法。它首先使用結構化分析(SA)來分析軟件的需求，然後使用結構化設計(SD)來設計整個系統，最後使用結構化編程(SP)。它給出了兩種典型的軟件結構(轉換型和事務型)，大大提高了軟件開發的成功率。
2.面向數據結構的軟件開發方法。
傑克遜方法是最典型的面向數據結構的軟件開發方法。傑克遜方法將問題分解成各部分的層次結構，這些層次結構可以用三種基本結構形式來表示。三種基本的結構形式是順序、選擇和重復。三種數據結構可以組合成壹個復雜的結構系統。該方法從目標系統的輸入輸出數據結構入手，導出程序框架結構，再補充其他細節，得到完整的程序結構圖。這種方法對於輸入輸出數據結構清晰的中小型系統特別有效，比如商業應用中的文件表處理。這種方法也可以與其他模塊詳細設計方法相結合。
3.面向問題的分析法
PAM(問題分析法)是日立公司在上世紀80年代末提出的壹種軟件開發方法。其基本思想是考慮輸入輸出數據的結構，指導系統的分解，並在系統分析的指導下逐步綜合。該方法的具體步驟是:從輸入輸出數據結構中導出基本處理框架；分析這些處理盒之間的順序關系；壹步壹步按順序處理盒子，直到畫出整個系統的焊盤圖。這種方法本質上是壹種全面的自下而上的方法，只是在逐步合成之前已經被有目的地分解了。這樣做的目的是充分考慮系統的輸入和輸出數據結構。PAM方法的另壹個優點是使用PAD圖。這是壹個二維樹形結構圖，是目前為止最好的細節設計表示方法之壹。當然，由於輸入輸出數據結構和整個系統之間也有差距，所以這種方法仍然只適用於中小型問題。
4.原型法
使用原型法的原因有很多，主要是隨著我們系統開發經驗的增加，我們也發現並不是所有的需求都可以提前定義，反復修改是不可避免的。當然可以采用原型法，因為開發工具發展很快，比如VB，DELPHI等工具，我們可以很快開發出壹個用戶看得見摸得著的系統框架，讓對計算機不是很熟悉的用戶可以根據這個模板提出自己的需求。
原型系統的開發通常包括以下幾個階段:
(1)確定用戶需求
(2)開發原始模型
(3)征求用戶對改進初始原型的意見。
(4)修改原型。
原型開發更適合用戶需求不明確、業務理論不確定、需求變化頻繁的情況。在系統規模不太大、不太復雜的情況下，最好使用這種方法。
5.面向對象的軟件開發方法
目前計算機行業最流行的詞是分布式、並行、面向對象。由此可以看出面向對象概念在當前計算機行業中的地位。例如，兩種流行的面向對象技術，DCOM和CORBA，就是例子。當然，我們其實用的是面向對象的編程語言，比如C++。不可否認，面向對象技術是軟件技術的壹次革命，在軟件發展史上具有裏程碑式的意義。
隨著面向對象程序設計向面向對象設計和面向對象分析的發展，最終形成了OMT。這種方法是自底向上和自頂向下的結合，它基於對象建模，不僅考慮輸入和輸出數據結構，而且包括所有對象的數據結構。因此，OMT完全達到了帕姆沒有完全達到的目的。而且OO技術在需求分析、可維護性、可靠性等軟件開發的三個關鍵環節和質量指標上有了實質性的突破，基本解決了這些方面的嚴重問題。
綜上所述，面向對象系統采用自底向上歸納和自頂向下分解的方法。通過對象模型的建立，可以真正建立基於用戶的需求，系統的可維護性大大提高。目前業界面向對象建模的標準是UML(統壹建模語言)。
這裏需要說壹下微軟MSF(微軟解決方案框架)的框架，它簡單的把系統設計分為概念設計、邏輯設計、物理設計三個階段。概念設計階段是從用戶的角度出發能獲得多少對象，以對象為主體繪制業務框架。邏輯設計階段是對概念設計階段的對象進行重新分析、細分、整合和刪除。並建立每個對象的方法屬性和對象之間的關系。實際上，物理設計就是確定我們實際需要的組件、服務、框架結構和具體的編程語言。MCF的整體結構清晰，是壹個良好的、可操作的基於對象開發的框架體系。
6.可視化開發方法
實際上，可視化開發不能單獨視為壹種開發方法，而是壹種輔助工具。比如用過SYBASE的S-Design的人都知道，這個工具可以用來建立壹個圖形化的數據庫模型進行顯示，並導入到不同的數據庫中。當然沒有多少人用過S-Design，但是很多人用過VB，DELPHI，C++ Builder等開發工具。事實上，妳正在使用可視化開發工具。
當然，不可否認的是，妳只是在編程中使用可視化，而不是在高層的系統分析和系統設計中。其實建立壹個系統分析和系統設計的可視化工具是壹個很好的賣點，國外也有很多工具致力於這方面的產品設計。例如，業務對象是壹個非常好的可視化數據庫分析工具。
可視化開發使我們專註於業務邏輯和業務流程，用戶界面可以通過可視化工具輕松形成。通過操作界面元素，如菜單、按鈕、對話框、編輯框、單選框、復選框、列表框和滾動條，應用軟件由可視化開發工具自動生成。
六、如何培養軟件工程的思維和方法。
作為壹個軟件開發人員，壹個常見的問題是，在項目開始的時候，我喜歡談論實現的細節，並且樂在其中。我們更傾向於討論如何用靈活簡短的代碼實現壹個特定的功能，而忽略了對整個系統架構的考慮。所以作為壹個開發人員，尤其是有經驗的開發人員，我們應該把自己從代碼中解放出來，更多的時候，我們甚至應該在頭腦中暫時放棄如何實現的思考，從整體的項目或者產品來考慮壹個軟件產品。
以下是我的壹些個人經歷:
1.考慮整個項目或產品的市場前景。作為壹個真正的系統分析師，不僅要從技術角度考慮問題，還要從市場角度考慮問題。換句話說，我們還需要考慮產品的用戶群是誰，產品投放市場後是否有生命力。比如，即使用最好的技術實現單進程操作系統，其市場前景也壹定不容樂觀。
2.站在用戶的角度考慮問題。比如有些操作對於開發者來說是非常明顯的問題。但是對於普通用戶來說可能很難掌握，也就是說有時候我們要在靈活性和易用性上妥協。另外，在功能實現上，也需要綜合考慮。雖然有些功能很強大，但是如果用戶幾乎不用，可能在產品的第壹個版本就不會推出。站在用戶的角度，也就是說用戶認可的才是好的，而不是開發者認為的好。
3.從技術角度來看