第一篇：軟件工程實施體會

軟件工程實施體會

——本學期對軟件工程實驗使我學會的

軟件工程項目是需要團體作業才能夠完成的。團體作業就需要交流，有交流，就必然會有合作；有合作，就需要有分工；有分工，就需要有協調；有所有這些，就需要有管理。然而一個人的項目是否不需要管理？當然不是，因為有文檔，有代碼，有靈感，有經驗，等等都需要管理。只是此刻的管理是自己完成的，可以更簡單一點。我們已經有過一遍又一遍的調試以前已經fix過的bug體驗，也有過一遍又一遍的查找以前自己實現過的技術的經歷。軟件工程的理論，在開發過程中的作用，就是指導如何做好管理，以取得軟件的可用性、正確性和合理性。如果我們清楚知道這是它的目標，就可以拋開一些對自己不適用的枝節。

那么我們如何實現它呢？

我認為軟件工程中最重要的，最有實際意義的，是它界定了工作職能，從而也確定了責任歸屬。什么意思？說白了，就是什么人做什么事，出了問題誰負責。那么它是怎么界定工作職能的？是通過對軟件開發流程的劃分來實現的。軟件工程把軟件的開發劃分成很多個相對獨立的階段，每一個階段都有相關的人員來實現，也就有相關的人員來負責。分工不清，責權不明，是導致管理混亂的最主要的因素。所以即使是兩個人的項目，也是需要軟件工程來指導的，因為通過它，可以更好的知道如何可以合理分工，劃分工作職權以取得最終的成果。當然，走教條主義的道路是非常愚蠢的。

軟件工程是針對“軟件危機”提出來的。它是一種工程，把經驗和理論應用到實踐中來，解決軟件開發中出現的各種問題。這是什么意思？就是說，軟件工程是用來解決實際問題的。如果軟件開發中沒有遇到管理問題，軟件工程就不需要管理的內容；如果軟件開發中沒有遭遇文檔混亂，軟件工程就不需要文檔的部分。但是如果很幸運的遭遇到了這些，那么這一切都是不可或缺的。軟件工程不是一個固定的呆板的框框，而是一個有彈性的概念。

所以，如果不是要去申請iso或是cmm認證，完全不必要一板一眼的按照iso或是cmm的規范去做。所謂“有企業特色的軟件工程”，完全可以從吸收現有的模式和規范中完善起來。但這并不是說所有在開發過程中出現的都是軟件工程，只有那些能引導開發走向成功的才是真正有意義的軟件工程。其他的，最多只是失敗的嘗試。

軟件工程實施的時機；

首先要知道軟件工程，理解軟件工程；然后要了解現有的軟件工程的模式和規范。ISO、CMM或是Agility，都定義了一套規范。這些規范是經驗與技術，以及理論的積累。它們存在很多合理的、可行的模式，可以引用和參考；但銀彈是沒有的。當然，我們可以重頭再來，造他們造過的輪子，摔他們摔過的跤；但很明顯，這是不必要的。

實施的最好方法，也是最可行的方法，成本最小的方法，是根據開發的客觀的因素，修改那些規范，以符合我們的開發過程；但是最主要的，是修改我們的主觀認識，以符合那些規范；而最重要的，是在實施中發現那些規范不合理的地方，并改正它。我們擔心過小的項目應用軟件工程是否會陷入官僚主義，從而加重項目的負擔？我們再來看什么是軟件工程？軟件工程并沒有定義什么才是軟件工程！也沒有定義軟件工程自身的規模。軟件工程的意義在于對開發階段的劃分，以及分工和責任歸屬。這與項目的規模沒有什么沖突。相反，越是小的項目越是需要軟件工程的管理。

軟件開發的一個共識，是把一個大的項目劃分成一些小的模塊，再把小的模塊劃分成更小的模塊。如果這些小模塊是獨立的（或者原來就是一個獨立的項目），那么軟件工程至少可以提高它的重用性。對于一個軟件工程觀念不深的團隊，不要期望他們在接手大的項目的時候可以使用軟件工程，如果他們在小項目中不愿使用的話。前者的復雜度不是他們可以想象和承受的。軟件工程對工作量有什么影響？針對那些在不使用軟件工程管理的項目中很輕松的人而言的。軟件工程會使他們要么失業，要么負起責任來。相對工程師而言，他們會從混亂的毫無頭緒的狀態中解放出來，他們的工作會變得有效率。損失的是以前尸位素餐的人將暴露出來——這可能是它的唯一的缺陷，同時也是它受到很多企業/個人抵制的可能原因之一。

第二篇：軟件工程學習總結和體會2015

西安交通大學

2015級研究生課程專題作業

軟 件

工 程 心 得專 業: 班 級: 學 號: 姓 名: 電 話:

二○一五年十月

體 會

一、軟件生命周期各階段任務目的和主要方法

在分階段總結之前，首先要明確以下三個問題：

1、什么是軟件生存周期？

軟件生存周期是指從軟件定義、開發、使用、維護到淘汰的全過程。主要包括：

（1）問題定義；（2）可行性研究；（3）需求分析；（4）概要設計；（5）詳細設計；（6）編碼；（7）測試；

（8）軟件維護。

2、軟件生存周期為什么劃分成階段？

(1)任何一個階段的具體任務不僅獨立，而且簡單，便于不同人員分工協作，從而降低整個軟件開發工作的困難程度。

(2)可以降低每個階段任務的復雜程度，簡化不同階段的聯系，有利于工程的組織管理，也便于采用良好的技術方法。

(3)使軟件開發的全過程以一種有條不紊的方式進行，保證軟件的質量，特別是提高了軟件的可維護性。

3、應該怎樣來劃分階段？

(1)每一個階段的任務盡可能獨立；(2)同一階段內的任務性質盡可能相同；

(3)每一個階段任務的開始和結束有嚴格的標準。

下面分別對各階段進行討論：

1、問題定義

目的是將用戶提出的要求具體化、定量化，任務是確定研制系統的范圍，明確研制的邊界。

方法步驟：

(1)通過調查研究，了解系統要求；

(2)需求方與開發方討論確定系統的功能、性能、可靠性、安全保密性等方面的要求，以及費用、進度等方面的要求。

2、可行性研究

可行性研究說明該軟件開發項目的實現在技術上、經濟上和社會條件上的可行性，評述為合理地達到開發目的可能選擇的各種方案，目標是用最小的代價在盡可能短的時間內確定問題是否能夠解決。

可行性研究的方法是首先需要進一步分析和澄清問題定義；然后分析員導出系統的邏輯模型；最后對未來的行動方針提出建議。

在導出邏輯模型的過程中，具體要根據以下四個方面分析可行性：

(1)經濟可行性:進行成本效益分析,評估項目的開發成本,估算開發成本是否會超過項目預期的全部利潤.分析系統開發對其它產品或利潤的影響。

(2)技術可行性:根據客戶提出的系統功能,性能及實現系統的各項約束條件,從技術的角度研究實現系統的可行性。(3)法律可行性:研究在系統開發過程中可能涉及的各種合同,侵權,責任以及各種于法律相抵觸的問題。

(4)開發方案的選擇性:提出并評價實現系統的各種看法方案.從中選出一種用于軟件項目開發。

3、需求分析

需求分析是為了有效解決用戶的需要而進行的一項工程活動，要考慮的問題是功能需求、數據需求、性能需求和接口需求，開發者承擔分析任務，核心是用戶。

軟件項目的失敗大半源于需求分析沒有做好，軟件開發人員首先應該明確用戶的意圖和要求，正確獲取用戶的需求，然后形成一個軟件需求規格說明，它是軟件開發的重要基礎。

需求分析的方法：

(1)需求獲取：獲取客戶需求，客戶泛指某個人或機構部門等，一般方法是調查，包括訪談座談、問卷、跟班和收集資料，需求規約可表達用戶的軟件價值。

(2)需求分析與規格說明：建立需求模型，它是用戶需求的圖解，一些常用的模型有：業務樹圖、用例圖、活動圖。分別用于結構化需求建模、系統業務舉例和反映系統工作流程。

(3)需求驗證：要驗證的主要內容有：有效性驗證、一致性驗證、完整性驗證、現實性驗證和可檢驗性驗證。

需求建模的方法：

(1)關聯模型

(2)面向對象模型(3)原型方法

4、系統設計

此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等，一般分為概要設計和詳細設計，好的軟件設計將為軟件程序編寫打下良好的基礎。

概要設計是對需求規格說明書中提供的軟件系統邏輯模型進行進一步的分解，從而建立軟件系統的總體結構和各個子系統間及各個模塊間的關系，定義各子系統接口界面和各模塊的功能描述，并根據設計結果產生概 要設計文檔。

概要設計在早期有模塊化方法、功能分解方法；在60年代后期提出了面向數據流和面向數據結構的設計方法；近年來又提出面向對象的設計方法等。

詳細設計過程根據概要設計形成的結果對各個模塊的內部實現進行規劃設計，并根據設計結果產生詳細設計文檔。

詳細設計主要方法是通過采用結構化和面向對象的方法從視圖、控制、模型三層模型上細化概要設計的各個模塊，并完成偽代碼為編碼階段做準備。

5、編碼和測試

編碼是將軟件設計的結果轉換成計算機可執行的程序代碼。主要方法是依據詳細設計文檔實現設計中的算法、功能、接口、數據結構，采用結構化和面向對象化的方法編寫代碼。

編碼過程中要制定統一，符合標準的編寫規范，以保證程序的可讀性，易維護性，提高程序的運行效率。

軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。

測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨 意性。

6、軟件維護

軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。

軟件的維護包括糾錯性維護和改進性維護兩個方面。

二、課程主要收獲

《軟件工程》課程強調概念和知識的理解和掌握，側重軟件項目的分析、設計、實現和維護的基本技能。比較注意“點”和“面”的結合，是一門理論性和實踐性都較強的學科。作為一名已經在IT領域工作十年之后又重返校園的大齡學生，雖然已經不是第一次學習這門課程了，去年也剛在單位取得了信息系統項目管理高級工程師資格，從另一個側面對軟件開發過程有了更深層次的理解。不過溫故而知新，這次仍然選修這門課，我還是得到了一些新的啟示。最大的收獲就是在我看來，軟件工程與其說是一門課程，不如說是一門思想，是一個如何去分析和處理問題的過程，應該說其范疇已經遠遠不止局限于該門課程，它已經成為了一個綜合的能夠解決問題的思想集合。

此外，通過對軟件開發過程的重學習，并結合之前在軟件開發管理工作中的經驗，我對自己在軟件開發主要階段管理工作中的不足有了更進一步的認識，總結了相應的管理要點，具體闡述如下：

1、概要設計

主要任務：系統應該怎樣做，或概括地說，系統應該如何實現。本階段特點：將用戶的具體要求轉為抽象的計算機軟件設計。管理要點：

通過分析對比，從多種可能的實現方案和軟件結構中選出最佳方案及最合理的，即： 設想供選擇的方案→推薦最佳方案→選取合理的方案功能分解→ 軟件設計結構 → 數據庫設計 3 確定測試要求并確定測試計劃

作為項目管理者必須從概要設計開始就應該從全局角度開始把握整個系統的進展，并必須從此階段開始，時刻從全局觀的問題來發現問題，解決問題。

2、詳細設計

主要任務：系統應該怎樣具體地做，或概括地說，系統應該如何具體地去實現所有的要求。

本階段特點：將抽象的計算機軟件設計轉為形象的，具體的，面向用戶的計算機界面設計。

管理要點：

本階段尚未涉及具體編寫程序，而是要設計出程序的“藍圖”，所以詳細設計的結果基本上決定了最終的程序代碼的質量。邏輯是否正確性能是否滿足要求是否容易閱讀和理解 作為項目管理者在詳細設計階段，應始終不忘從一名用戶的使用角度出發，審視每一個界面的詳細設計，以保證設計出來的界面以及程序能夠滿足一般用戶希望將來的系統能夠通俗易懂，簡單實用的要求。

3、編碼

主要任務：用某種程序設計語言書寫計算機能夠識別的程序。

本階段特點：將詳細設計書的內容“翻譯”成計算機語言，直接關系到整個項目的質量。

管理要點：

本階段的編碼是設計的自然結果，因此，程序的質量主要取決于軟件設計的質量。但是，程序設計語言的特性和編碼途徑也對程序的以下特性產生深遠的影響： 程序的可靠性 2 程序的可讀性 3 程序的可測試性 4 程序的可維護性

作為項目管理者在編碼階段，必須從把握進度與質量這兩個基本方面來有效地實施對項目的管理。首先應該根據項目進度計劃來合理地安排每一名作業成員的作業日程，并且隨時監督每一作業的進展情況，還需要針對項目的最新變更及時對計劃進行調整，以保證項目的按時完成。同時，在項目的進展過程中還需要通過小組討論，檢查評審等形式洞察每項作業的質量，以保證項目的保質保量完成。可以說，本階段是一名項目管理者在項目開發過程中極為忙碌也異常重要的階段。

4、測試

主要任務：通過單元測試和綜合測試來保證軟件工程的高質量。

本階段特點：盡可能早地發現并糾正差錯，往往占到軟件開發總工作量的40%以上，是保證軟件質量的關鍵。

管理要點：

軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對其作必要的測試（稱之為單元測試），模塊的編寫者和測試者是同一人，編碼和單元測試屬于軟件生命周期的同一個階段。在此階段結束之后，對軟件系統還應該進行各種綜合測試，這是軟件生命周期的另一個獨立階段，通常由專門的測試人員來承擔這項工作。

作為項目管理者在編碼階段，必須高度重視軟件測試工作，甚至可以說應該把測試看作與編寫程序同等重要的任務來對待。在要求每一名開發人員完成自己分內的單元測試，并且監督測試人員認真進行各項綜合測試的同時，應該把自己完全當成一名本軟件工程的用戶，從用戶的角度以一種高度負責，甚至近乎苛刻的嚴格態度來對軟件進行徹底的測試。在本階段通過嚴把質量關來確保軟件工程的質量。

所以說，尤其在軟件進入具體開發階段后，能否遵循要點進行管理是很重要的。

總之，實際工作當中軟件項目為什么會失敗？為什么交付日期會一拖再拖？我覺得項目失敗只有一個原因：就是項目經理不合格。除非這個項目經理在項目開始階段就已經提出來了這個項目會失敗，或者是完全屬于項目之外不可抗拒的原因導致失敗。也許還會有一些我的同行跳出來說不服，那么請繼續：

難道是新增需求的原因導致失敗？客戶會讓你新增100個需求而要你二天交貨嗎？必然是分析設計階段沒有充分考慮好可擴展性和新增需求導致現在不可控制而失敗的!

難道是程序員人力不足導致？人都沒有到位，怎么會失敗，多少人做多少人的事，多少人做多少人的計劃，不會有失敗。

難道是程序員技能不夠？項目經理是如何面試的？怎么在項目失敗了才發現是程序員技能不夠？有問題早提出來嘛。

難道測試人員沒有做好？少來了，測試人員只是加了一道保障證明。程序很多流程都通過不了，程序還屬于開發調試階段，與測試人員有什么關系？

我曾經在單位參加一些項目，發現有這樣一個概念很多項目經理都沒有搞清楚：什么叫開發階段？我認為開發階段最多只能包括單元測試這一部分。綜合測試絕對不能屬于開發階段了，也就是說不能到了最后交付階段還有程序流程走不通，程序隨便正常操作都會失敗。程序隨便正常操作都出現好多bug屬于開發還沒有完成，絕對還沒有過單元測試階段，離綜合測試和驗收階段還早著呢。說白了，還屬于代碼審查階段。

不懂程序設計的項目經理，往往不注重code開發人員,其實這是一個嚴重的錯誤。軟件的質量來源于什么？由誰來保證？有的項目經理說是由測試人員來保證，就算測試人員的測試用例寫得很詳細，把需求中的每一個功能點都測試到了，那最后就沒有問題了嗎？當然不是，很多邏輯上的東西要程序員來保證不出問題的，而測試人員只是起一個驗證的作用，問題不應該由測試人員來發現，而應該由開發人員來發現。也就是說，我們盡量不要讓測試人員來發現問題。如果第一次測試有至少25%以上的用例通不過，那說明質量控制出了問題。這樣的版本根本就不應該拿出來進行測試。由此可見，軟件的質量是由程序員來保證的，而不是測試人員。

總的說來，一個項目的成敗與否，與項目的各個階段皆有關系：需求都不清楚，開發起來肯定是南轅北轍；分析設計不夠好，會讓程序員難以維護，隨著新增需求的增多，會導致整個系統混亂不可控制；編碼不好，整個系統不穩定是必然的，Bug也是抓不盡的；測試不做好，系統是沒有保證的，少了哪個環節都不行。

所以做軟件項目開發過程管理工作，我認為重點要放在項目計劃、進度控制、質量控制、風險預測這四個方面。不要說項目的失敗是因為新需求引起的,一個沒有新增需求和風險的項目是不存在的，承認這一點之后,我們就不會有很多怨言了。

以下針對這四個方面進行詳述：

項目計劃：沒有項目計劃，那失敗還有什么話好說？大家都知道凡事預則立，不預則廢。項目計劃一定要包括這幾方面的內容：各階段里程碑時間點，各個里程碑的輸出結果，風險預測，意外應對。計劃時間一定要提前于交貨時間，并注意風險意外是否留下足夠的應對時間和處理方案。

進度監控：對每個階段把握好，每個階段要完成的任務一定要完成，如果完不成，是什么原因導致的？我們的應對策略是什么？我們要信任別人，但是不要忘記鎖門。同樣的，別人說完成了，你不能就認為別人完成了，要看到結果才能證明完成了。有的項目經理說，我也進度監控啦，他說完成了就完成了，誰想到沒有完成？到底是程序員不誠實還是項目沒有管理好？你沒有鎖好門，能怨別人偷你東西嗎？還有一種情況就是不懂如何鎖門，根本就不知道這一階段的輸出結果是什么？當然進度監控就是一句空話了。

質量監控：也應該是分階段進行的，每一個階段的質量監控內容有所不同。

需求分析階段的質量監控就是完整而又正確的理解用戶需求，需求是否清楚可懂，寫用例的測試人員是否明白需求？

分析設計階段的質量監控就是設計是否完全滿足需求？這個設計方案是否滿足以后新功能的擴展？以及是否有考慮到新功能的意外和設備環境，運行平臺的變化？

編碼階段的質量監控就是變量命名是否規范？代碼是否可讀？是否有詳細的注釋？是否有重復代碼？要知道重復代碼是必然會造成系統不穩定，bug成群的。可變部分的代碼和不可變部分的代碼是否分離。要知道上面講的每一部分如果沒有做好，都會導致后期的產品出現大量問題。代碼階段還有一個重要的工作就是做code review代碼公開評審，你自己發現不了的問題別人也許就看得見。

單元測試階段的質量監控任務就是單元測試代碼是否測試通過？代碼覆蓋是否完全？單元測試報告提交情況如何？單元測試用例有沒有做好？ 綜合測試階段質量監控任務當然就是看用例是否完全？是否全部真正執行？測試報告有沒有寫好？

回歸測試當然得看以前測試的Bug是否還在，如果還在，當然是無條件打回去重新開發。

測試階段最主要的監控就是看用例是否真正執行，是否有安全性測試？破壞性測試？異常測試，壓力測試？

以上的每個階段最好完成了才進行下一階段，否則會造成混亂出現問題的，造成想并行進行節約時間卻反而浪費了時間。

以上就是我重學《軟件工程》并結合實際工作經驗所得到的啟示，不妥之處請劉老師批評指正！

第三篇：軟件工程課程設計個人體會

數學與信息工程學院

項目名稱： 實驗室設備管理系統 專業班級：11計教1班

學號：1129020025 姓名：蔣一瑭

承擔角色：美工，問題處理 組號：08 同組組長：鄧磊

同組其他成員：王宇翔 馬富偉 江濤 指導教師：鐘美

完成起止日期：2014.6.12 《軟件工程課程設計個人體會》 1.美化軟件和對在設計過程中所遇到的問題進行處理 2.在設計是會出現兩種錯誤，一種是系統部分自定義錯誤和數據庫錯誤。系統部分自定義錯誤在權限方面，管理員出現錯誤，而輸入方面用戶帳號和密碼出錯，查找方面找不到符合要求的記錄。對于數據庫，代碼出錯。

對于系統部分 自定義錯誤，需要添加/修改操作只能給幾十對輸入數據進行驗真。分析錯誤的類新。并給出相應的錯誤提示語句。

對于數據庫錯誤，可以在可能出錯的地方中輸入相應的出錯語句，并將程序重置，最后返回輸入階段。

此外，還有未解決的問題：未添加設備選購數量屬性，輸入賬戶密碼后，退出登錄后，賬戶密碼自動填充。

至于美工方面，就添了一張圖片，一切從簡，只留必須要留下的。

3.軟件工程課程設計課程設想心得體味，這也激起了我爾后勤奮進修的樂趣，我想這將對我以后的進修發作主動的影響。其次，此次課程設想讓我充實熟悉到團隊協作的主要性，只要合作協作才干保證整個項目標有條不絮。經過此次設想，我懂得了進修的主要性，體會到實際學問與實際相連系的主要意義，學會了堅持、耐心和勤奮，這將為自己爾后的進修和任務做出了最好的表率。我感受作為一名軟件工程專業的先生，此次課程設想是很故意義的。更主要的是若何把自己日常平凡所學的工具利用到理想中。固然自己關于這門課懂的并不多，良多根本的工具都還沒有很好的放縱，感受很難，也沒有很有效的法子經過自身去了解，可是靠著這一個多禮拜的“進修”，在小組同窗的輔佐和解說下，漸漸對這門課逐漸發作了些許的樂趣，自己起頭自動進修并逐漸從根本漸漸起頭弄懂它。

所以我以為此次的課程設想意義很深，和其他4位同窗的配合進修、配合、勤奮的進程也很歡快，別的還要感謝感動教員的耐心教育。

第四篇：軟件工程課程教學的一些體會

《軟件工程》課程教學的一些體會

陳中育

（浙江師范大學計算機學院，浙江金華321004）

摘要：在分析軟件工程課程教學特點的基礎上，討論了軟件工程課程教學對學生軟件開發習慣的一些影響，提出了軟件工程課程教學對教師素質的一些基本要求。

關鍵詞：軟件工程；課程教學；開發習慣；教師素質

Some Pedagogical Experience of SE Curriculum Instruction

Chen Zhong-yu

(Institute of Computer Science of Zhejiang Normal University, Jinhua321004, China)

Abstract: Analyses the characteristic of SE curriculun instruction, Discusses the influence of SE curriculun instruction upon the develop style of the students, Presents some basic requirement of teacher culture about SE curriculun instruction.Keywords: SE；Curriculum Instruction；Develop Style；Teacher Culture

0引言

《軟件工程》是計算機科學與技術專業必修的一門專業課程。本人從事大學計算機專業本科生《軟件工程》課程教學近十年，在教學過程中深感學習該課程的重要性，這不僅是因為軟件工程與計算機專業其他先行基礎課程的密切關聯，更為重要的是軟件工程掌握的好壞直接關系到學生畢業以后的軟件開發思路和工作規范，甚至關系到我們國家整體軟件產業在世界軟件產業中的生存空間。

當前國內各大高校紛紛開辦軟件學院，其中一個非常重要的趨勢就是先行開設軟件工程專業，這也說明軟件工程知識是整個計算機軟件領域的核心內容。本文作者試圖根據自己在教學中的一些體會和認識來分析在軟件工程課程教學中我們到底應該堅持讓學生著重學習哪些知識、使學生得到什么能力的培養。

1軟件工程課程教學特點

（1）課程特點

《軟件工程》課程是一門要求基礎課程較多、應用實踐性較強、與產業標準行業規范銜接、概念多、涉及面廣的課程。屬于在高年級開設的專業必修課程，要求學生學習軟件工程的基本原理、概念和技術方法；自覺遵循軟件工程方法論中的一些規范和工業領域中的一些行業標準；目的是提高軟件開發的生產率，減少軟件開發和維護中的錯誤，確保最終用戶軟件產品的質量。

（2）要求基礎課程較多

要求學生在學習軟件工程之前已經完成高級語言程序設計、數據結構、數據庫系統概論、操作系統、計算機網絡等先行課程的學習。這些課程都是計算機專業的一些重要基礎課程，也是衡量一個學生是否具備計算機領域開發的技術能力。

任何大規模的軟件項目開發最終是由很多開發組織、很多開發人員的集體參與、協作完成。具體的技術工作就是依賴于這些先行課程的能力，而軟件工程所涉及的卻是從工程技術、工程組織、工程管理、軟件體系框架上的一系列難題。

（3）應用實踐性較強

我們認為目前高校大多數計算機專業的培養目標應當定位在軟件工程師，而不是計算機科學家，這應該是大多數高校計算機專業教學改革的出發點和根本點。作為軟件工程師一個根本的能力就是實際軟件開發能力問題，在課程學習尤其是軟件工程的課程學習必須堅持軟件開發技術開發能力的培養。在教學中必須強調理論學習與應用實踐的結合，把握軟件工程的發展方向，為學生在社會實踐、畢業論文、畢業設計中能理論聯系實際參與實際項目開發打下基礎。

（4）與產業標準行業規范銜接

隨著信息時代的到來，軟件產業已經成為全球高科技產業發展的最主要的推動力。對于中國的軟件業而言，如何抓住機遇，躋身國際軟件強國之列，已經成為一個首要的問題。毫無疑問，現實的中國軟件產業面臨著巨大挑戰，國情與我們類似的印度經過短短的十幾年發展時間，印度以其軟件公司的規范化和軟件開發實力占有了全球市場的相當大份額，印度的軟件出口額幾乎是中國的30倍。目前，中國軟件企業有5000家，是印度的5倍以上，但其中80％是小作坊式企業，不能形成較大的規模，一個根本的原因是我們的開發沒有很好地執行軟件規范化和行業標準所造成的。

造成這種局面，我們的軟件教學體制也有責任，我們必須在軟件工程的課程教學中認真學習軟件開發的通行規范和標準，課程教學與與產業標準行業規范銜接。

2軟件工程課程教學對軟件開發習慣的影響

（1）什么是軟件開發習慣

其實從某種程度上講行為習慣與做事風格是等同的兩個概念，記得在史濟民主編的《軟件工程原理、方法與應用》一書中是這樣描述風格的。所謂風格，就是作家、畫家和程序員在創作中喜歡和習慣使用的表達自己作品題材的方式。

從70年代以來，軟件工程發展到今天，編碼的目的從最初的強調程序執行效率到強調程序結構清晰到對象封裝。伴隨著程序設計語言從過程設計到面向對象的程序設計，隨著軟件工程技術的深入研究、發展和運用，人們逐步認識到，在大型系統的開發中，規范一致的開發習慣非常重要，增進成員之間的相通訊交流，減少因不協調而引起的問題，提高軟件重用程度，軟件開發的習慣也從過去的個人作坊到團隊合作，從過去的強調過程代碼編寫到強調流程管理，從過去的強調代碼實現到強調規范化文檔編寫，從過去的過程模塊技術到現在的組件技術、構件技術、應用中間件技術。

（2）程序設計語言選擇習慣

任何軟件系統的實現都必須選擇至少一種程序設計語言來完成，選擇語言工具一個重要的評價標準就是看它能不能很好的解決所需要解決的問題，而不是開發小組成員能否使用某種語言工具。我們在實際教學中遇到很多學生選擇語言上主要看自己是否喜歡和掌握程度來決定，雖然這樣的大多數語言能解決大多數問題，但這樣的選擇原則是錯誤的，也不利于跟蹤和利用最新軟件開發工具和環境。軟件工程是發展的，隨著新技術新方法的出現，我們的開發方式也必須隨之變化。

值得一提的是，就軟件工程現狀而言，我認為任何從事軟件開發的人員都必須掌握兩種語言。其中C是非常基礎的語言，它對于培養軟件開發的基本思維方式，培養良好的軟件開發習慣，培養模塊化、結構化等基本軟件開發技能都具有非常重要的作用。同時，掌握了C，也就獲得了通向程序底層環境的通行證，可以在需要的時候深入到任何的層次，解決需要解決的各種問題。而C＋＋的最大特點，除了對C的基本特性的繼承外，最重要的就是他可以培養程序員完整的面向對象編程的概念，及基本的技巧，還可以使得開發人員充分了解WINDOWS等多任務操作系統上程序運行的基本原理，從而為實際的應用開發提供最基礎的思維模式。

（3）善于合作開發的習慣

我們必須看到，現在的軟件業已經不是發展初期的軟件業了，如今軟件業的產業化規模已經相當大，要想在市場上取得成功，一個產品需要有非常多的人力、物力、財力的投入。什么是產業？它是一個通過計劃、合作、創新，通過市場化的運作來創造價值的活動。對于

一個產業來說，個人作坊式個人英雄主義色彩幾乎是中國軟件產業的一個軟筋。

我們發現高年級的學生大都積累了編程經驗，也參與過一些開發實踐，但是我們在軟件工程教學中要求學生自由組合、合作開發、團隊作戰等思想時，他們馬上感到無所適從，覺得自己一身編程能力無法得到發揮。教師在課堂上必須給學生說明：每個人的技術特長需要封裝在軟件開發的各個階段細節上，一個成功的產品，必須經過嚴格的產業化運作，包括規劃、開發、測試、包裝、宣傳、營銷、客戶服務。必須強調編程高手孤高倨傲、急功近利是非常有害的。

（4）用軟件工程觀點思考問題的習慣

我們周圍很多從事計算機教學、科研和開發的專業人員有一種普遍的錯誤認識，認為軟件開發主要的是技術問題，認為“不采用軟件工程”也能做好軟件產業化工作，這正是我們國內軟件產業界落后思想的表現，也是軟件企業短視、個人自由散漫、高傲自大的表現。如果這樣的思想被多數人認可，將是我們軟件產業界的一大悲哀。

曾經有一位同事這樣評價軟件工程這們課程，說軟件工程其實就象是教育學，當然他的態度是教育學并不重要軟件工程也不重要。如果我們的計算機教師都是這樣的觀點，那么我們怎么能讓學生正確認識軟件工程的重要性呢？

我們的問題決不在于需不需“軟件工程”的爭論，這本身就是無可置疑的。問題在于怎樣去利用軟件工程的思想和方法服務于我們的軟件開發工作，這才是關鍵之關鍵。如果沒有真正理解軟件工程的根本思想，生搬硬套一些規程、一套文檔格式和一些方法，只能給軟件開發工作帶來干擾和破壞，不會產生任何建設性作用。

所以，我們在教學中首先應該普及的是軟件工程的基本思想，把它灌輸到每一個學生的頭腦之中，那么，軟件工程的基本思想究竟是什么？我想也會有許多不同的觀點，但我認為這樣幾點應該是共同的：（1）軟件的開發一定要以產業化的思想來看待，強調合作和規范，杜絕隨意性；（2）軟件的開發過程一定要采用某種方法進行進度和成本的控制；（3）軟件的質量必須得到保證，保證的措施一是提高開發過程的質量，二是通過嚴格測試；（4）客戶的需求永遠是軟件開發的終極目標，客戶的需求一定要準確，并且一絲不茍地滿足；（5）軟件開發的所有成果必須存在于容易理解的書面文件中，而不是僅僅存在于軟件開發人員的頭腦中。

3軟件工程課程教學對教師素質的一些特殊要求

（1）豐富的大型軟件系統開發經驗

軟件工程本身是一門實踐性很強的課程，沒有實踐開發經驗、大型系統分析能力的教師

很難勝任軟件工程課程教學任務，這是軟件工程教師應該具備的一個很重要的素質，目前無論業界還是高校計算機專業最缺的正是這樣的專業人員。

（2）良好的語言溝通和文字表達能力

雖然作為教師本身就應該有這樣的素質，但是軟件工程教學中這種素質尤為重要，面對用戶需求理解和表達，面對計劃報告的書寫，面對合作團隊的組織、溝通和協調，等等，都必須具備這方面的素質。

（3）一定的市場運作能力

我們必須明確地告訴學生，你所開發的軟件產品必須被用戶接受被市場認可，了解市場把握市場善于運作市場也是教師應該具有的素質之一。

（4）較強的工程經濟分析能力

軟件作為一個工業產品，它應當賺取足夠的利潤，才能使軟件開發組織生存下去。因此，從事軟件開發的軟件工程師應當具有較強的工程經濟分析能力，能夠分析軟件產品的市場前景和經濟價值，并做出合理的投資效益預測。

（5）健康的心理素質

開發軟件本身就是一項艱苦的腦力和體力勞動，成功開發一個軟件產品，要經過反復修改，要花費大量的進間和精力，這些都要求軟件人員有較好的心理承受能力、團隊合作精神、成果分享精神。

4結束語

以上這些思考只是從軟件工程教學中容易被忽視的一些問題，希望以此話題引起同行們的思考和爭鳴。

作者簡介：陳中育（1964--），男，浙江浦江人，浙江師范大學計算機學院副教授，研究方向：軟件工程、數據庫。

第五篇：學習軟件工程的心得與體會

學習軟件工程的心得體會

整本書的內容邏輯很清晰明了，由淺入深循序漸進，首先我就大概描述下我們所學的內 容，第一章是從整體分析軟件工程這門學科的發展和所處的社會環境，接著后面的幾章深入分析了軟件開放過程和模式、軟件項目管理、計算機工程、需求分析、結構化分析建模以及基于UML面向對象分析建模等。接著我就詳細介紹下我對這門課程知識點的理解概括：

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

軟件生存周期：一個軟件從定義到開發、使用和維護，直到最終被棄用，要經歷一個漫長的時期，通常把軟件經歷的這個漫長的時期稱為生存周期。軟件的生存周期可分為八個階段：①問題定義；②可行性研究；③需求分析；④總體（概要）設計；⑤詳細設計；⑥編碼與單元測試；⑦綜合測試；⑧軟件維護； 瀑布模式：原型進化模式：增量模式：螺旋模式：

軟件開發的整個過程：①需要項目團隊，組建優秀的團隊可以開發出更搞質量的軟件產品。任務開發團隊要求小而精，成員大多在8人以內，主要成員有項目負責人、開發人員、資料管理員和軟件測試員。②項目計劃是為了使軟件開發各項工作有秩序地進行，包括任務分配和基于里程碑的進度安排，甘特圖和任務網絡圖是用來描述進度計劃的工具。項目計劃書可以作為軟件開發的工作指南。③項目成本估算，由于項目有來自各方面的成本包括工資開支、場地費、差旅費、設備費和資料費等，但是軟件主要是對人力成本的估算，常用的方法有程序代碼成本估算法等。④軟件風險管理包括很多不確定的風險因素，如計劃風險、管理風險、需求風險、技術風險、人員風險、產品風險、用戶風險和商業風險等等，而風險管理的主要任務是：風險識別、風險評估、和風險防范。⑤軟件文檔管理，軟件文檔是工程模式軟件開發的成果體現，包括技術文檔、管理文檔和用戶文檔。⑥軟件配置管理與軟件質量管理，包括配置規劃、軟件變更控制、軟件版本控制和質量控制計劃。

《軟件工程》課程既強調基本概念和基本知識的理解和掌握，又側重軟件項目的分析、設計、實現和維護的基本技能。比較注意“點”和“面”的結合。我還是蠻喜歡這門課的，通過對這門課的學習讓我意識到理論學習很重要，實踐更重要，實踐是檢驗真理的唯一標準，只有將理論與實際結合，才更能發揮我們所學的知識的作用，更能直接的創造效益，社會和國家做出貢獻。