軟體工程知識體系論文

⑴ 高級軟體工程師（J2EE）所必須具備的知識體系以及素養是什麼

高級這個概念很不好衡量，簡單的說，如果你已經是一個可以獨擋一面的軟體工程師了，那麼你在向架構師進發的過程中，都可以算是高級軟體工程師。

⑵ 軟體工程師必備知識

軟體工程師考試(高級)大綱
一、考試說明

1．考試要求：

（1）理解軟體工程管理的概念和任務；

（2）理解軟體生存期過程；

（3）理解軟體工程標准；

（4）掌握需求分析、測試、維護基本技術；

（5）掌握軟體度量、軟體配置管理方法；

（6）理解軟體復用概念；

（7）理解軟體質量保證的手段；

（s）理解軟體項目對人員的需求；

（9）理解軟體知識產權的基本知識。

2.通過本級水平考試的合格人員具有從事軟體系統分析與工程系統分析員、工程管理員的實際工作能力和業務水平。

3．本級水平考試范圍包括三個模塊，即模塊1、模塊2和模塊3。題型為單項選擇題十多項選擇題十綜合題。每個模塊考試時間為90分鍾。

二、考試范圍

模塊1：軟體工程技術

1．1軟體生存期過程

1．1．1軟體工程過程和軟體生存期

1．1．2軟體生存期模型

1．1.3國際標准：ISO／IECI2207信息技術一軟體生存期過程

1．2軟體需求分析

1.2．1需求分析的任務

1．2．2需求分析過程

1．2．3需求的類型。

1．2．4需求分析的原則

1．2．5需求分析人員和用戶的責任

1．2．6需求文檔

1．2．7需求說明技術的選擇

1．3軟體復用技術

1．3．1軟體復用的概念

1．3．2軟體開發過程

1．3．3構件技術

1．3．4分層式體系結構

1.3．5實施軟體復用開發單位的組織結構

1．4軟體測試技術

1．4．1軟體測試的基本概念

1．4．2測試用例設計

●白盒測試

●黑盒測試

1．4．3性能測試

1．4．4軟體測試策略

1.4．5軟體測試工具

1．5軟體維護

1.5．1軟體維護的概念

1．5．2軟體維護活動

1.5．3軟體維護的實施

1．5．4軟體可維護性

1．5．5軟體再工程

1．6軟體工具與軟體開發環境

1．6．1軟體開發工具的分類、作用和功能

1．6．2軟體開發環境的概念

模塊2：軟體質量管理與軟體質量保證

2．1軟體質量

2．1．1什麼是軟體質量

2．1．2軟體可靠性

2．1．3軟體質量問題的根源

2．1．4軟體產品質量與軟體過程質量

2.2軟體質量保證

2．2．1軟體質量保證的概念

2．2．2軟體質量保證體系

2．2．3質量保證的實施

2．2．4軟體質量設計

2．2．5軟體容錯技術

2．3軟體工程標准與軟體文檔

2．3．1什麼是軟體工程標准

2．3．2軟體工程標准化的意義

2．3．3軟體工程標準的制訂與推行

2．3．4軟體工程標準的層次

2，3．5軟體工程國家標准

2．4ISO9000國際標准

2．4．1質量管理、質量認證與質量審核

2．4．2ISO9000標准概要

2．4．3ISO9000族標准構成

2．4．4質量體系

2．4．5ISO9001的主要內容

2．4．6ISO9000_3實施指南概要

2．5軟體過程能力評估CMM

2．5．1軟體過程評估的意義

2．5．2軟體過程能力成熟度分級及其關鍵過程域

2.5．3軟體過程評估的國際標准

2．6軟體度量

2．6．1軟體度量的概念

2．6．2功能點方法計算軟體的大小

2．6．3程序環路復雜度計算

2．6．4Halstead程序工作量計算

2．6．5程序風格度量

2．7軟體配置管理

2．7．1什麼是軟體配置管理

2．7．2配置管理計劃的制訂

2．7．3變更管理

2．7．4版本管理和發行管理

模塊3：軟體工程管理

3．1軟體工程管理和軟體項目管理

3．1．1軟體工程管理的任務與意義

3．1．2軟體工程管理的范圍

3．1．3軟體文檔管理

3．1．4軟體成本估算

3．1．5軟體風險分析

3．1．6軟體項目進度計劃與監控

3．2軟體人員管理

3．2．1軟體開發組織結構

3.2．2軟體人員能力成熟度模型

3．2．3軟體工程師道德和職業活動規范

3．3軟體知識產權保護

3．3．1什麼是知識產權

3．3．2計算機軟體著作權

3．3．3計算機軟體著作權登記管理

3．3．4計算機軟體著作權侵權與法律保護

3．3.5計算機軟體的商業秘密與反不正當競爭

=================================
高級軟體工程師哪些必須精通2007年09月26日 星期三 下午 05:31程序員的七種武器

信息技術的發展時間雖然不長，但其爆炸式的發展速度使信息技術迅速覆蓋社會和人類生活的各個角落。程序員們是這場信息化浪潮的見證者之一，更是其中的主要參與者，這是時代賦予每個程序員的機會和責任。

信息技術的更新速度是驚人的，程序員的職業生涯則是一個要求不斷學習的過程，永遠不能固步自封。本人在工作期間曾看見過很多程序員只要有閑暇時間就瀏覽一些沒有太大作用的網頁，在網上聊天，打游戲，浪費了大量的時間，十分不可取。而另外一種情況是，IT技術的日新月異使很多程序員眼花繚亂，什麼都想學，卻又不知從何學起，今天看看這個，明天學學那個，貪多不熟。

雖然IT技術發展迅速，但很多技術都是有規律可循，一些基本的概念、原理和方法還很通用，可以舉一反三。本人根據自己的體會和經驗，向那些剛剛踏入IT行業的新程序員們或正在迷茫的程序員們推薦程序員必須掌握的七種武器，有了這七種武器，雖不敢說笑傲江湖，但將自己立於不敗之地還是可以的。

第一種武器：開發工具

至少熟練掌握兩到三種開發工具的使用，這是程序員的立身之本，其中C/C++和JAVA是我重點推薦的開發工具，C/C++以其高效率和高度的靈活性成為開發工具中的利器，很多系統級的軟體還是用C/C++編寫。而JAVA的跨平台和與WEB很好的結合是JAVA的優勢所在，而本人對SUN公司的「網路即計算機」的概念相當欣賞，並相信JAVA即其相關的技術集JAVA One會成為未來的主流開發工具之一。其次，如果能掌握一種簡便的可視化開發工具，如VB，PowerBuilder，Delphi，C++ Builder，則更好，這些開發工具減小了開發難度，並能夠強化程序員對象模型的概念。另外，需要掌握基本的腳本語言，如shell,perl等，至少能讀懂這些腳本代碼。

第二種武器：資料庫

為什麼資料庫是如此重要？很多應用程序都是以資料庫的數據為中心，而資料庫的產品也有不少，其中關系型資料庫仍是主流形式，所以程序員至少熟練掌握一兩種資料庫，對關系型資料庫的關鍵元素要非常清楚，要熟練掌握SQL的基本語法。雖然很多資料庫產品提供了可視化的資料庫管理工具，但SQL是基礎，是通用的資料庫操作方法。如果沒有機會接觸商業資料庫系統，可以使用免費的資料庫產品是一個不錯的選擇，如mySQL, Postgres等。

第三種武器：操作系統

當前主流的操作系統是Windows，Linux/Unix，熟練地使用這些操作系統是必須的，但只有這些還遠遠不夠。要想成為一個真正的編程高手，需要深入了解操作系統，了解它的內存管理機制、進程/線程調度、信號、內核對象、系統調用、協議棧實現等。Linux作為開發源碼的操作系統，是一個很好的學習平台，Linux幾乎具備了所有現代操作系統的特徵。雖然Windows系統的內核實現機制的資料較少，但通過互聯網還是能獲取不少資料。只有對操作系統有一定的了解後，你會發現自己上了一個新的台階。

第四種武器：網路協議TCP/IP

在互聯網如此普及的今天，如果您還沒有對互聯網的支撐協議TCP/IP協議棧有很好的掌握，就需要迅速補上這一課，網路技術已改變了軟體運行的模式，從最早的客戶/伺服器結構，到今天的WEB Services，再到未來的網格計算，這一切都離不開以TCP/IP協議棧為基礎的網路協議支持，所以，深入掌握TCP/IP協議是非常必要的。至少，你需要了解ISO七層協議模型，IP/UDP/TCP/HTTP等常用協議的原理和三次握手機制。

第五種武器：DCOM/CORBA/XML/WEB Services

隨著技術的發展，軟體與網路的無縫結合是必然趨勢，軟體系統的位置無關性是未來計算模式的重要特徵之一，DCOM/CORBA是當前兩大主流的分布計算的中間件平台，DCOM是微軟COM(組件對象模型)的擴展，而CORBA是OMG支持的規范。程序員需要做的不僅僅是利用商業的開發平台來開發軟體，而是要理解這些技術的初衷，即為什麼需要這項技術，如果你能理解了這一點，再回頭看這些技術的具體實現，就如庖丁解牛，迎刃而解。XML/WebServices重要性不言而喻，XML以其結構化的表示方法和超強的表達能力被喻為互聯網上的「世界語」，是分布計算的基石之一。

第六種武器：軟體工程與CMM

現代大型軟體系統的開發中，工程化的開發控製取代個人英雄主義，成為軟體系統成功的保證，一個編程高手並不一定是一個優秀的程序員，一個優秀的程序員是將出色的編程能力和開發技巧同嚴格的軟體工程思想有機結合，編程只是軟體生命周期中的其中一環，優秀的程序員應該掌握軟體開發各個階段的基本技能，如市場分析，可行性分析，需求分析，結構設計，詳細設計，軟體測試等。一句話可以概括我的看法：「創意無限，流程保證」。

第七種武器：強烈的好奇心

什麼才是一個程序員的終極武器呢，那就是強烈的好奇心和學習精神。沒有比強烈的好奇心和學習精神更好的武器了，它是程序員們永攀高峰的源泉和動力所在。

⑶ java軟體工程師要學習的java知識體系是什麼樣的

JavaSE基礎階段
JavaEE Web開發階段
JavaEE 高級階段
行業應用開發階段
筆試面試實戰課程
職業素養課程
實訓項目強化輔導課程
後面幾個是博洋贈送的課程
幫助學員更快速的找到滿意的工作
具體可以到博洋的網頁。高端課程里看看
或者直接在線咨詢。

⑷ 簡述軟體工程專業主幹知識體系

軟體工程專業主幹學科：馬克思主義理論、大學外語、高等數學、大學物理、物理實驗、線性代數、概率論與數理統計、程序設計語言、數據結構、離散數學、操作系統、編譯技術、軟體工程概論、統一建模語言、軟體體系結構、軟體需求、軟體項目管理。

軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及程序設計語言、資料庫、軟體開發工具、系統平台、標准、設計模式等方面。

(4)軟體工程知識體系論文擴展閱讀：

軟體工程的七條基本原理：

（1）用分階段的生存周期計劃進行嚴格的管理。

（2）堅持進行階段評審。

（3）實行嚴格的產品控制。

（4）採用現代程序設計技術。

（5）軟體工程結果應能清楚地審查。

（6）開發小組的人員應該少而精。

（7）承認不斷改進軟體工程實踐的必要性。

⑸ 軟體工程中項目管理的知識體系包括哪些內容

樓主，軟體工程項目管理根據我的理解應該是包括;項目范圍管理 ,需求和迭代管理 \時間管理,方法和模板管理,費用管理,承諾管理,質量管理,執行管理,溝通管理,現狀調查,資源管理,問題和風險管理,采購管理,整體管理。這些功能8thManage的項目管理軟體都具有，如果您想了解更詳細的資料可以上它的官網。
.

⑹ 軟體工程師應具備哪些知識體系

編程語言，資料庫（SQL），網路（TCP/IP)，操作系統（Linux/Unix），編碼技術（讀《代碼大全》），軟體方法（OOP，SOA）

⑺ 軟體工程知識體系圖的內容 兩條主線

發展的兩條主線:一條是形式化技術,一條是工程化技術。
學習的兩條主線:軟體工程的學習是以技術和管理兩條主線展開，圍繞一個軟體過程即需求、分析、設計、構造、測試，以軟體建模為核心，以規范化程序設計為基礎，最終達到指導軟體開發全過程、實現項目成功的最終目標。

⑻ 不同崗位的軟體工程師分別應有的知識體系結構是怎樣的

⑼ 軟體工程方向的工程碩士論文方向

軟體工程碩士的論文選題方向：
1.1. 專業碩士
軟體工程碩士方向的專業碩士論文選題，按照目前培養方案的要求，必須是與軟體工程有關的內容。關於選題的官方說法，參見：==>【2011年校學術委員會簽發的文件】。
所謂與軟體工程碩士有關的內容包括：
1. 軟體的開發
這是最常見的選題方向，也是最正規、最容易得到認可的方向。一般來說，軟體開發的題目，可以是一個系統，也可以是一個或者幾個模塊。不過，不論是系統還是模塊，都要包括如下幾個階段：
a) 需求分析
b) 概要(總體)設計和詳細設計
c) 編碼(是指重要的、關鍵的演算法部分)
d) 部署和測試

2. 軟體工程碩士的其它方向內容
例如：
a) 軟體需求管理、變更
b) 軟體體系架構
c) 軟體測試 (軟體測試方向的論文大綱參見博文《軟體測試相關碩士論文大綱》)
d) 軟體過程改進
e) 更多內容，參見《軟體工程知識體系指南》
3. 論文覆蓋的內容及范圍
按照軟體工程碩士學科的論文要求，軟體工程方向的論文，需要至少覆蓋軟體工程的兩個階段，例如：需求+設計，設計+實現，需求+設計+實現，需求+設計+實現+測試，設計+實現+測試，......
如果是測試領域的論文，則應該涉及到：測試設計+測試執行+結果分析
如果是需求管理領域的論文，則應涉及到：需求獲取、需求變更管理、需求分解、需求跟蹤等方面
1.2. 工學碩士
工學碩士選題一般均按照導師要求執行，與工程碩士依據自己實際工作或者實習內容選題有所不同。總體上，工學碩士選題與工程碩士類似，但論文的內容應當偏學術。工學碩士也可以選擇研究性的課題。

⑽ 軟體工程論文

[編輯本段]基本信息
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義： 軟體工程（1）、BarryBoehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。 （2）、IEEE在軟體工程術語匯編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體；2.在1中所述方法的研究 （3）、FritzBauer在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。 目前比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。 （4）、《計算機科學技術網路全書》中的定義：軟體工程是應用計算機科學、數學及管理科學等原理，開發軟體的工程。軟體工程借鑒傳統工程的原則、方法，以提高質量、降低成本。其中，計算機科學、數學用於構建模型與演算法，工程科學用於制定規范、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。
[編輯本段]目標
軟體工程的目標是：在給定成本、進度的前提下，開發出具有可修改性、有效性、可靠性、可理解性、可維護性、可重用軟體工程性、可適應性、可移植性、可追蹤性和可互操作性並且滿足用戶需求的軟體產品。追求這些目標有助於提高軟體產品的質量和開發效率，減少維護的困難。下面分別介紹這些概念。 （1）可修改性（modifiablity）。容許對系統進行修改而不增加原系統的復雜性。它支持軟體的調試與維護，是一個難以達到的目標。 （2）有效性（efficiency）。軟體系統能最有效地利用計算機的時間資源和空間資源。各種計算機軟體無不將系統的時/空開銷作為衡量軟體質量的一項重要技術指標。很多場合，在追求時間有效性和空間有效性方面會發生矛盾，這時不得不犧牲時間效率換取空間有效性或犧牲空間效率換取時間有效性。時/空折衷是經常出現的。有經驗的軟體設計人員會巧妙地利用折衷概念，在具體的物理環境中實現用戶的需求和自己的設計。 （3）可靠性（reliability）。能防止因概念、設計和結構等方面的不完善造成的軟體系統失效，具有挽回因操作不當造成軟體系統失效的能力。對於實時嵌入式計算機系統，可靠性是一個非常重要的目標。因為軟體要實時地控制一個物理過程，如宇宙飛船的導航、核電站的運行，等等。如果可靠性得不到保證，一旦出現問題可能是災難性的，後果將不堪設想。因此在軟體開發、編碼和測試過程中，必須將可靠性放在重要地位。 （4）可理解性（understandability）。系統具有清晰的結構，能直接反映問題的需求。可理解性有助於控制軟體系統的復雜性，並支持軟體的維護、移植或重用。 （5）可維護性（maintainability)。軟體產品交付用戶使用後，能夠對它進行修改，以便改正潛伏的錯誤，改進性能和其他屬性，使軟體產品適應環境的變化，等等。由於軟體是邏輯產品，只要用戶需要，它可以無限期的使用下去，因此軟體維護是不可避免的。軟體維護費用在軟體開發費用中佔有很大的比重。可維護性是軟體工程中一項十分重要的目標。軟體的可理解性和可修改性有利於軟體的可維護性。 （6）可重用性（reusebility）。概念或功能相對獨立的一個或一組相關模塊定義為一個軟部件。軟部件可以在多種場合應用的程度稱為部件的可重用性。可重用的軟部件有的可以不加修改直接使用，有的需要修改後再用。可重用軟部件應具有清晰的結構和註解，應具有正確的編碼和較低的時/空開銷。各種可重用軟部件還可以按照某種規則存放在軟部件庫中，供軟體工程師選用。可重用性有助於提高軟體產品的質量和開發效率、有助於降低軟體的開發和維護費用。從更廣泛的意義上理解，軟體工程的可重用性還應該包括：應用項目的重用，規格說明（也稱為規約）的重用，設計的重用，概念和方法的重用，等等。一般來說，重用的層次越高，帶來的效益也就越大。 （7）可適應性（adaptability）。軟體在不同的系統約束條件下，使用戶需求得到滿足的難易程度。適應性強的軟體應採用廣為流行的程序設計語言編碼，在廣為流行的操作系統環境中運行，採用標準的術語和格式書寫文檔。適應性強的軟體較容易推廣使用。 （8）可移植性（portability）。軟體從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。為了獲得比較高的可移植性，在軟體設計過程中通常採用通用的程序設計語言和運行環境支撐。對依賴於計算機系統的低級（物理）特徵部分，如編譯系統的目標代碼生成，應相對獨立、集中。這樣，與處理機無關的部分就可以移植到其他系統上使用。可移植性支持軟體的課重用性和課適應性。 （9）可追蹤性（tracebility）。根據軟體需求對軟體設計、程序進行正向追蹤，或根據程序、軟體設計對軟體需求進行逆向追蹤的能力。軟體可追蹤性依賴於軟體開發各個階段文檔和程序的完整性、一致性和可理解性。降低系統的復雜性會提高軟體的可追蹤性。軟體在測試或維護過程中或程序在執行期間出現問題時，應記錄程序事件或有關模塊中的全部或部分指令現場，以便分析、追蹤產生問題的因果關系。 （10）可互操作性（interoperability）。多個軟體元素相互通信並協同完成任務的能力。為了實現可互操作性，軟體開發通常要遵循某種標准，支持折衷標準的環境將為軟體元素之間的可互操作提供便利。可互操作性在分布計算環境下尤為重要。 軟體工程活動是「生產一個最終滿足需求且達到工程目標的軟體產品所需要的步驟」。主要包括需求、設計、實現、確認以及支持等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體體系結構，包括子系統、模塊以及相關層次的說明、每一模塊介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。支持活動包括修改和完善。伴隨以上活動，還有管理過程、支持過程、培訓過程等。
[編輯本段]過程
生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
[編輯本段]原則
軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。軟體工程的原則有以下四項軟體工程師基本原則：
1）選取適宜開發范型
該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其他因素之間是相互制約、相互影響的，經常需要權衡。因此，必須認識需求定義的易變性，採用適宜的開發范型予以控制，以保證軟體產品滿足用戶的要求。
2）採用合適的設計方法
在軟體設計中，通常要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。
3）提供高質量的工程支持
「工欲善其事，必先利其器」。 在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。
4）重視開發過程的管理
軟體工程的管理，直接影響可用資源的有效利用，生產滿足目標的軟體產品，提高軟體組織的生產能力等問題。因此，僅當軟體過程得以有效管理時，才能實現有效的軟體工程。 這一軟體工程框架告訴我們，軟體工程的目標是可用性、正確性和合算性；實施一個軟體工程要選取適宜的開發范型，要採用合適的設計方法，要提供高質量的工程支撐，要實行開發過程的有效管理；軟體工程活動主要包括需求、設計、實現、確認和支持等活動，每一活動可根據特定的軟體工程，採用合適的開發范型、設計方法、支持過程以及過程管理。根據軟體工程這一框架，軟體工程學科的研究內容主要包括：軟體開發范型、軟體開發方法、軟體過程、軟體工具、軟體開發環境、計算機輔助軟體工程(CASE) 及軟體經濟學等。
[編輯本段]基本原理
自從1968年提出「軟體工程」這一術語以來，研究軟體工程的專家學者們陸續提出了100多條關於軟體工程的准則或信條。美國著名的軟體工程專家巴利·玻姆（Barry Boehm）綜合這些專家的意見，並總結了美國天合公司（TRW）多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。 玻姆認為，這七條原理是確保軟體產品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。 人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程准則都可以有這七條原理的任意組合蘊含或派生。下面簡要介紹軟體工程的七條原理：
1、用分階段的生命周期計劃嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。 玻姆認為，在整個軟體生命周期中應指定並嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。
2、堅持進行階段評審
統計結果顯示： 大部分錯誤是在編碼之前造成的，大約佔63%錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。 因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤。
3、實行嚴格的產品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。
4、採納現代程序設計技術
從六、七時年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。
5、結果應能清楚地審查
軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限， 盡量明確地規定開發小組的責任和產品標准，從而使所得到的標准能清楚地審查。
6、開發小組的人員應少而精
開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。 這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少的多； 當開發小組為N人時，可能的通訊信道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。
7、承認不斷改進軟體工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，玻姆提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的 軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。
[編輯本段]方法學
軟體工程的方法有很多方面的意義。包括專案管理，分析，設計，程序的編寫，測試和質量控制。 軟體工程師軟體設計方法可以區別為重量級的方法和輕量級的方法。重量級的方法中產生大量的正式文檔。 著名的重量級開發方法包括ISO9000，CMM，和統一軟體開發過程（RUP）。 輕量級的開發過過程沒有對大量正式文檔的要求。著名的輕量級開發方法包括極限編程（XP）和敏捷流程（AgileProcesses）。 根據《新方法學》這篇文章的說法，重量級方法呈現的是一種防禦型的姿態。在應用重量級方法的軟體組織中，由於軟體項目經理不參與或者很少參與程序設計，無法從細節上把握項目進度，因而會對項目產生恐懼感，不得不要求程式設計師不斷撰寫很多「軟體開發文檔」。而輕量級方法則呈現「進攻型」的姿態，這一點從XP方法特別強調的四個准則—「溝通、簡單、反饋和勇氣上有所體現。目前有一些人認為，重量級方法合於大型的軟體團隊（數十人以上）使用，而「輕量級方法」適合小型的軟體團隊（幾人、十幾人）使用。當然，關於重量級方法和輕量級方法的優劣存在很多爭論，而各種方法也在不斷進化中。 一些方法論者認為人們在開發中應當嚴格遵循並且實施這些方法。但是一些人並不具有實施這些方法的條件。實際上，採用何種方法開發軟體取決於很多因素，同時受到環境的制約。
[編輯本段]主要課程
外語、高等數學、線性代數、高等代數、電子技術基礎、離散數學、計算機引論（C語言）、數據結構、C++程序設計、JAVA程序設計、Delphi程序設計、匯編語言程序設計、演算法設計與分析、計算機組成原理與體系結構、資料庫系統、計算機網路、軟體工程、軟體測試技術、軟體需求與項目管理、軟體設計實例分析、CMM/ISO9000等。 另外，還包括操作系統、軟體體系結構概論、設計模式、多媒體技術基礎、UML建模、概率論、大學英語等，部分院校還會包括大學物理，工程制圖，數值分析等。
[編輯本段]發展方向
敏捷開發（Agile Development）被認為是軟體工程的一個重要的發展。它強調軟體開發應當是能夠對未來可能出現的變化和不確定性作出全面反應的。 敏捷開發被認為是一種「輕量級」的方法。在輕量級方法中最負盛名的應該是「極限編程」（Extreme Programming，簡稱為XP）。而與輕量級方法相對應的是「重量級方法」的存在。重量級方法強調以開發過程為中心，而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。 面向側面的程序設計（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟體工程的另外一個重要發展。這里的方面指的是完成一個功能的對象和函數的集合。在這一方面相關的內容有泛型編程（Generic Programming）和模板。
[編輯本段]需求分析
軟體工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟體工程第一個也是很重要的一個階段，本文以醫院管軟體工程需求分析理系統為例詳細介紹了需求工程的構成和進行方法。 首先人們必須了解需求工程和其他項目過程的關系： 圖1需求與其他項目過程的關系 軟體需求包括三個不同的層次-業務需求、用戶需求和功能需求-也包括非功能需求：業務需說明了提供給客戶和產品開發商的新系統的最初利益，反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明；用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明；功能需求定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。 需求工程分為了需求開發和需求管理兩個階段：下面就以這兩個階段說明： 一，需求開發 需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己確定合適的步驟。 1．需求獲取： 1）確定需求開發過程：確定需求開發過程確定如何組織需求的收集、分析、細化並核實的步驟，並將它編寫成文檔。對重要的步驟要給予一定指導，這將有助於分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行。 2）編寫項目視圖和范圍文檔：項目視圖和范圍文檔應該包括高層的產品業務目標，所有的使用實例和功能需求都必須遵從能達到的業務需求。項目視圖說明使所有項目參與者對項目的目標能達成共識。而范圍則是作為評估需求或潛在特性的參考。 表1項目視圖和范圍文檔的模板 a、1背景在這一部分，總結新產品的理論基礎，並提供關於產品開發的歷史背景或形勢的一般性描述。 a、2業務機遇描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市場和信息系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案，並指出所建議的產品為什麼具有吸引力和它們所能帶來的競爭優勢。 a、3業務目標用一個定量和可測量的合理方法總結產品所帶來的重要商業利潤，把重點放在給業務的價值上。 a、4客戶或市場需求描述一些典型客戶的需求，包括不滿足現有市場上的產品或信息系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能運行的軟、硬體平台。 a、5提供給客戶的價值確定產品給客戶帶來的價值，並指明產品怎樣滿足客戶的需要。 a、6業務風險總結開發（或不開發）該產品有關的主要業務風險，例如市場競爭、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能採取的減輕風險的措施。 b.1項目視圖陳述編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場、企業框架、組織的戰略方向和資源局限性為基礎。 b.2主要特性包括新產品將提供的主要特性和用戶性能的列表。強調的是區別於以往產品和競爭產品的特性。可以從用戶需求和功能需求中得到這些特性。 b.3假設和依賴環境在構思項目和編寫項目視圖和范圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。 c.1首次發行的范圍總結首次發行的產品所具有的性能。描述了產品的質量特性，這些特性使產品可以為不同的客戶群提供預期的成果。c.2隨後發行的范圍如果你想像一個周期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，並期待隨後版本發行的日期。 c.3局限性和專用性明確定義包括和不包括的特性和功能的界線是處理范圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能。 d.1客戶概貌客戶概述明確了這一產品的不同類型客戶的一些本質的特點，以及目標市場部門和在這些部門中的不同客戶的特徵。 d.2項目的優先順序一旦明確建立項目的優先順序，風險承擔者和項目的參與者就能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟體項目的五個方面：性能、質量、計劃、成本和人員。e.產品成功的因素明確產品的成功是如何定義和測量的，並指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的范圍內的事務，還要包括外部因素。如果可能，可建立測量的標准用於評價是否達到業務目標. 3）用戶群分類：產品的用戶在很多方面存在著差異，例如：用戶使用產品的頻度、他們的應用領域和計算機系統知識、他們所使用的產品特性、他們所進行的業務過程、他們在地理上的布局以及他們的訪問優先順序。根據這些差異，你可以把這些不同的用戶分成小組。用戶類不一定都指人，你可以把其它應用程序或系統介面所用的硬體組件也看成是附加用戶類的成員。以這種方式來看待應用程序介面，可以幫助你確定產品中那些與外部應用程序或組件有關的需求。將用戶群分類並歸納各自特點為避免出現疏忽某一用戶群需求的情況，要將可能使都有所差異。詳細描述出它們的個性特點及任務狀況，將有助於產品設計。 4）選擇產品代表：擇每類用戶的產品代表為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表並能作出決策。這對於內部信息系統的開發是最易實現的，因為此時，用戶就是身邊的職員。而對於商業開發，就得在主要的客戶或測試者中建立起良好的合作關系，並確定合適的產品代表。他們必須一直參與項目的開發而且有權作出決策。每一個產品代表者代表了一個特定的用戶類，並在那個用戶類和開發者之間充當主要的介面。 5）建立核心隊伍：建立起典型用戶的核心隊伍把同類產品或產品的先前版本用戶代表召集起來，從他們那裡收集目前產品的功能需求和非功能需求。這樣的核心隊伍對於商業開發尤為有用，因為你擁有一個龐大且多樣的客戶基礎。與產品代表的區別在於，核心隊伍成員通常沒有決定權。 6）確定使用實例：讓用戶代表確定使用實例從用戶代表處收集他們使用軟體完成所需任務的描述-使用實例，討論用戶與系統間的交互方式和對話要求。在編寫使用實例的文檔時可採用標准模版，在使用實例基礎上可得到功能需求。 一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個使用實例是相關的用法說明的集合，並且一個說明是使用實例的例子。在描述時列出執行者和系統之間相互交互或對話的順序。當這種對話結束時，執行者也達到了預期的目的。 對於一些復雜的使用實例，畫出圖形分析模型是有益的，這些模型包括數據流程圖、實體關系圖、狀態轉化圖、對象類和聯系圖。 使用實例的描述並不向開發者提供他們所要開發的功能的細節。為了減少這種不確定性，需要把每一個使用實例敘述成詳細的功能需求。每一個使用實例可引伸出多個功能需求，這將使執行者可以執行相關的任務；並且多個使用實例可能需要相同的功能需求。使用實例方法給需求獲取帶來的好處來自於該方法是以任務為中心和以用戶為中心的觀點。比起使用以功能為中心的方法，使用實例方法可以使用戶更清楚地認識到新系統允許他們做什麼。 每一個使用實例都描述了一個方法，用戶可以利用這個方法與系統進行交互，從而達到特定的目標。使用實例可有效地捕捉大多數所期望的系統行為，但是你可能有一些需求，這些需求與用戶任務或其他執行者之間的交互沒有特定的關系。這時你就需要一個獨立的需求規格說明。 7）召開應用程序開發聯系會議：召開應用程序開發聯系會議應用程序開發聯系會議是范圍廣的、簡便的專題討論會，也是分析人員與客戶代表之間一種很好的合作辦法，並能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發人員間的合作夥伴關系付諸於實踐。 8）分析用戶工作流程：分析用戶工作流程觀察用戶執行業務任務的過程。畫一張簡單的示意圖（最好用數據流圖）來描繪出用戶什麼時候獲得什麼數據，並怎樣使用這些數據。編制業務過程流程文檔將有助於明確產品的使用實例和功能需求。你甚至可能發現客戶並不真地需要一個全新的軟體系統就能達到他們的業務目標。 9）確定質量屬性：確定質量屬性和其它非功能需求在功能需求之外再考慮一下非功能的質量特點，這會使你的產品達到並超過客戶的期望。對系統如何能很好地執行某些行為或讓用戶採取某一措施的陳述就是質量屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。你將要和用戶一起商討精確定義他們模糊的和主觀言辭的真正含義。 10）檢查問題報告：通過檢查當前系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新產品或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。 11）需求重用：跨項目重用需求如果客戶要求的功能與已有的產品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟體組件。