當前位置:萬佳範文網 >

心得體會 >學習心得體會 >

軟件工程學習心得體會範文(精選9篇)

軟件工程學習心得體會範文(精選9篇)

軟件工程學習心得體會範文 篇1

在本學期的軟件工程課程的學習中,我們學習了十一章的內容。第一章軟件與軟件工程的概念,這一章主要講解的是一些概念性和基礎性的內容,例如軟件的概念、特性,軟件危機的主要表現,軟件工程的概念以及軟件生存期、典型生存期模型等等。第二章軟件工程方法與工具,這一章主要對軟件工程方法進行介紹,包括三種方法:傳統方法、面向對象方法、形式化方法。還引出了工具UML。第三章軟件需求獲取與結構化分析方法,本章詳細介紹了需求獲取與需求分析階段的任務以及結構化分析方法,畫分層的數據流圖、E-R圖以及狀態圖式本節的重點。第四章結構化分析方法,這一章重點講解了使用變換型映射方法和事務型映射方法生成初始的模塊結構以及模塊結構的改進。第五章編碼,這一章重點講解了編碼的風格及規範,還告訴我們編碼規範説帶來的好處,並告誡我們將來一點要形成好的編碼風格。第六章軟件測試方法,本章講解了軟件測試相關的概念及重要性,軟件測試與開發各個階段的關係;還介紹了白盒測試技術以及黑河測試技術。第七章統一建模語言UML概述,本章詳細介紹了UML的基本模式、事物、關係及建模時用到的各種圖進行了介紹。第八章面向對象分析,這一章主要講解了面向對象分析的3種模型,包括功能模型、靜態模型和動態模型。第九章軟件體系結構與設計模式,本章對軟件體系結構的基本概念、典型風格等進行了講解。第十章面向對象設計,本章的重點是對面向對象分析時建立的對象模型進行調整和細化。第十一章軟件維護,本章主要介紹軟件維護的任務、軟件維護活動以及軟件維護方法進行了介紹。

軟件工程學習心得體會範文(精選9篇)

要學習軟件工程,學會如何系統的思考,以及養成良好的編碼習慣,想學好軟件工程,就必須知道軟件工程的目標、過程和原則:軟件工程目標:生產具有正確性、可用性以及開銷合宜的產品。正確性指軟件產品達到預期功能的程度。可用性指軟件基本結構、實現及文檔為用户可用的程度。開銷合宜是指軟件開發、運行的整個開銷滿足用户要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題,它們形成了對過程、過程模型及工程方法選取的約束。

軟件工程過程:生產一個最終能滿足需求且達到工程目標的軟件產品所需要的步驟。軟件工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義,又稱軟件需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟件系統結構,包括子系統、模塊以及相關層次的説明、每一模塊的接口定義。詳細設計產生程序員可用的模塊説明,包括每一模塊中數據結構説明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程,實現完成後的確認,保證最終產品滿足用户的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程,還有管理過程、支持過程、培訓過程等。

軟件工程的原則是指圍繞工程設計、工程支持以及工程管理在軟件開發過程中必須遵循的原則。

我們學習了詳細設計的方法,其原則是過程描述是否易於理解、複審和維護,進而過程描述能夠自然地轉換成代碼,並保證詳細設計與代碼完全一致。包括程序流程圖、N-S圖、PAD圖、HIPO圖

程序流程圖:程序流程圖又稱之為程序框圖,它是軟件開發者最熟悉的一種算法表達工具。它獨立於任何一種程序設計語言,比較直觀和清晰地描述過程的控制流程,易於學習掌握。在流程圖中只能使用下述的五種基本控制結構:順序型;選擇型;while型循環;until型循環;多情況型選擇。

N-S圖:一種符合結構化程序設計原則的圖形描述工具,稱為盒圖,又稱為N-S圖。在N-S圖中,為了表示五種基本控制結構,規定了五種圖形構件。順序型;選擇型;WHILE重複型;UNTIL重複型;多分支選擇型。

PAD圖:它是用結構化程序設計思想表現程序邏輯結構的圖形工具。PAD也設置了五種基本控制結構的圖示,並允許遞歸使用。

HIPO圖:HIPO圖是由一組IPO圖加一張HC圖組成。它是美國IBM公司在軟件設計中使用的主要表達工具。

HC圖既是層次圖,用於表示軟件的分層結構。HC圖中的每一個模塊,均可用一張IPO圖來描述。IPO圖由輸入、處理和輸出三個框組成,需要時還可以增加一個數據文件框,這種圖形的優點,是能夠直觀地顯示輸入—處理—輸出三者之間的聯繫。

還有測試方法:按照測試過程是否在實際應用環境中來分,有靜態分析與動態測試。測試方法有分析方法(包括靜態分析法與白盒法)與非分析方法(稱黑盒法)。

靜態分析技術:不執行被測軟件,可對需求分析説明書、軟件設計説明書、源程序做結構檢查、流程分析、符號執行來找出軟件錯誤。

動態測試技術:當把程序作為一個函數,輸入的全體稱為函數的定義域,輸出的全體稱為函數的值域,函數則描述了輸入的定義域與輸出值域的關係。

還學習了其他很多工具、語言、方法等,雖然不是都學得很透徹,但我相信在今後的學習中一定會慢慢的完善的。

軟件工程對於初學者來説,知識基礎較薄弱,對一些應用操作、概念、工具方法等理解起來較為困難,要能從整體概念上較好地理解和把握、學好軟件工程,不是僅僅把幾本專業書籍細緻地看幾遍,然後上機練習幾次就可以成功,學習過程中要注意多看多練要注意結合實際,更要多思考,面對錯誤不要一範就問,要嘗試自己去解決。但是還要注意什麼都學,肯定是什麼都學不透的,要集中精力打攻堅戰,學習軟件工程首先要明白自己的學習目標究竟是什麼,根據自己的實際工作出發,有針對性的在相應的學習方向上進行提高,制定出詳細的學習規劃。還要注意與其他科目的相輔相成,就像我們在學習面向對象分析的時候要結合大一學習的面向對象及其方法學這一專業科目進行研究拓展;在學習語言時,要看看與C語言的聯繫,多思多想,把從各個科目學到的知識通匯貫通。

在軟件工程的學習中,我瞭解到了軟件並非是一些代碼這麼簡單,在開發軟件的過程中,編寫代碼的工作量其實只佔不到所有工程量的30%,而後期的管理和維護更是佔了60%到80%之多。一個完整的項目規劃須包括,軟件的定義,可行性分析報告,項目開發計劃,軟件需求説明書,概要設計説明書,詳細設計説明書,用户操作手冊,測試計劃,測試分析報告,開發進度報告,項目開發總結報告,軟件維護手冊,軟件問題報告,軟件修改報告,等多個文檔,每個文檔都要上級驗收審查,而文檔數量眾多,要做好這點真的不是很容易,而恰恰寫好文檔正能保證完成軟件工程其中一個目的的關鍵,既研究如何用最小的開銷做出生存期較長的軟件,再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排,且各階段要據具體情況不斷的反覆才能達成,所以代碼只是開發軟件這個浩大的工程的一個小小的過程。

而編碼的學習中,我更瞭解到形成自己獨特的規範的編碼風格是非常重要的事。因為這影響到了軟件後期繁重的維護,大家都要閲讀你的程序,如果你寫的程序毫無規範可言,那麼別人怎麼能讀懂你的程序?讀不懂程序,維護又從何談起呢?所以,我們在今後的學習中,一定要注意這方面的培養,在寫程序的過程中,要逐步的在規範的基礎上形成屬於自己的風格,即方便自己的修改,也方便日後他人的閲讀。

在學習中,我們還要注意比較三種方法的優缺點,例如:傳統方法雖然使軟件擺脱了混亂和無序,但其在適應需求變化的方面不夠靈活,而且傳統方法要麼面向行為,要麼面向數據,缺乏兩者的有機結合。而面向對象方法的程序設計和問題求解更符合人們日常自然的思維習慣,適合大型、複雜及交互性比較強的系統。形式化方法則是一中基於形式化數學變換的軟件開發方法,它可將系統的規格説明轉換為可執行的程序。

在今後的學習中要注意多讀書、多思考、多練習、多討論,不斷熟悉書本的基礎,並以此為基礎將其擴散開來,應用於今後的實踐。不斷鍛鍊自己,向一名合格的程序設計師邁進。

軟件工程學習心得體會範文 篇2

學習了這門課程, 還有老師們的多元化教課,不但讓我從理論上掌握軟件工程,還有從不同的實例,讓理論和實踐得到了很好的結合。整一個學期下來,總的來説還是學到了很多東西的,有很多地方是值得肯定的,其實在我看來,軟件工程與其説是一門課程,不如説是一門思想。是一個如何去分析和處理問題的過程,應該説其範疇已經遠遠不止侷限於該門課程,成為了一個綜合的一個能夠解決問題的思想集合。

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

軟件:軟件是能夠完成預定功能和性能的可執行的計算機程序和使程序正常執行所需要的數據,加上描述程序的操作和使用的文檔。軟件的特徵:①軟件是一種邏輯實體,而不是具體的物理實體,因而它具有抽象性。②軟件是通過人們的智力活動,把知識與技術轉化成信息的一種產品。③軟件成為產品後,其生產只是簡單的拷貝,不同於硬件製造。④維護過程比硬件複雜的多,甚至會引發新的錯誤。軟件危機:指的是軟件開發和維護過程中遇到的一系列嚴重問題。出現軟件危機的原因:①軟件維護費用急劇上升,直接威脅計算機應用的擴大。②軟件生產技術進步緩慢。軟件工程是指導計算機軟件開發和維護的工程學科。 軟件生存週期:一個軟件從定義到開發、使用和維護,直到最終被棄用,要經歷一個漫長的時期,通常把軟件經歷的這個漫長的時期稱為生存週期。軟件的生存週期可分為八個階段:①問題定義;②可行性研究;③需求分析;④總體(概要)設計;⑤詳細設計;⑥編碼與單元測試;⑦綜合測試;⑧軟件維護;

瀑布模式:是傳統的軟件開發模式,其中的“瀑布”是對這個模式的形象表達,由山頂傾瀉下來的水,自頂向下、逐漸細化。其特點是:線性化過程;分為分析、設計、編碼、集成等幾個階段,並且各階段逐級推進,不允許跨越。里程碑管理;階段評審;文檔驅動;簡潔便於工程應用的線性化過程步驟,並可以通過里程碑管理機制而使項目進程量化。其明顯的優點就是沒個階段結束前都要對所完成的階段成果進行評審,這使得軟件的錯誤能夠在個階段內儘早發現並儘早解決,總的來説瀑布模式具有良好的質量保證機制,有很強的生命力。

原型進化模式:對軟件進行直接模擬或仿真,只需要分析需求框架後進行原型創建,再對原型系統進行逐步細化與完善,通過版本更新逐步滿足用户對於軟件的多方面需要。

增量模式:開發過程有三個任務域,分別是設計結構、開發構件和集成系統,它既有完善的工程管理機制,又能適應用户需求變更,有利於質量的監控,並且各局部基於構件構造,有利於逐步構建與完善;由於先交付核心構件可利於降低項目的技術風險。

螺旋模式:是一種可較好的規避開發風險過程的模式,項目是基於任務的螺旋式推進,每個螺旋由內之外分別是需求分析、軟件設計、系統集成、驗證與交付。

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

計算機系統由硬件、軟件、數據資源、網絡資源、使用系統的人等諸多元素。有三種典型的計算機體系結構:①主機結構,主機集中了全部智能,並依靠終端接口與外部設備連接。②Client/Server結構,智能分佈於服務器與客户機,並依靠網絡連接成系統,其中,服務器處於核心位置,提供被動核心服務;客户機處於邊緣位置,可主動訪問服務器,尋求服務支持。③Browser/server結構,可適應互聯網遠程交互的特殊結構,基於Web服務器構建。

需求分析:系統開發前期需求分析很重要,它是為了有效解決用户問題的需要進行的一項工程活動,所需要考慮的需求問題是功能需求、數據需求、性能需求和接口需求,開發者承擔分析任務,核心是用户。其步驟有三個:①獲取客户需求,客户泛指某個人或機構部門等,一般方法是調查,包括訪談、座談、問卷、跟班和收集資料,需求規約可表達用户的軟件價值。②建立需求模型,它是用户需求的圖解,一些常用的模型有:業務樹圖、用例圖、活動圖。分別用於結構化需求建模、系統業務舉例和反映系統工作流程。③進行需求驗證,要驗證的主要內容有:有效性驗證、一致性驗證、完整性驗證、現實性驗證和可檢驗性驗證。 結構化分析建模:它是建立在需求規約基礎上的,對軟件問題進行全面解説,包括四個方面:①數據建模,它與數據庫設計密切相關,ER圖涉及實體、關係、屬性等圖形元素,在業務層面建立數據庫概念模型,一般用於前期的建模構想。②功能建模,是對系統數據加工的圖解,數據流程圖是常用的建模工具,涉及數據接口、數據處理、數據流、數據存儲等圖形元素,用於描述系統數據加工細節。③行為建模,行為模型用於説哦名軟件系統與環境的交互,狀態轉換圖常用的軟件行為建模工具涉及狀態、事件等圖形元素。⑤數據字典,是用於定義軟件的元素,使軟件元素獲得嚴肅的、詳密的、精確的規格説明。需求分析模型中的數據、功能、行為等諸多方面的元素,都有必要通過數據字典給予細節説明,以達到對系統較完整全面的規格定義。

基於UML對象面向對象分析建模:UML是統一建模語言,有統一的語法、語義和語用規則,其建模過程的特點是:用例驅動、以構架為中心和增量迭代,通過包實現對模型的有效的一體化管理。包括三部分:①用例建模,它面向用户需求的,能夠反映系統的用户價值,用例圖的基本元素有用例、參與者、交流;用例之間有泛化、延伸和包含關係。②活動建模,活動圖用於描述系統動態過程,主要圖形元素有:活動、轉換、起點、終點、判斷、併發、同步、泳道等。可描述高層業務級活動,涉及整個業務流程,針對每個用例活動建模,反映用例內部活動細節。③類分析建模,這裏就只考慮實體類,實體類所代表的數據相互之間通常有一定的關係,依靠這種關係可形成有組織的程序數據結構。實體類之間的主要數據關係有:關聯、聚類、泛化。

接下來我就簡單説下我上這門課的簡單的心得體會,我們是大四的學生了,也只有這個學期有課了,剛開始課表安排出來的時候覺得挺意外的,只有前八週有課,當時我還是有點小感動的,大四事情很多,有要考研的和工作的,大家也都有各自的事情,如果有16周的課,那麼每週課不是特別多,但是時間特別分散,也不能集中某段時間去做什麼事情。但是相對於老師的壓力也有,課程壓縮了相當於每節課的教學任務大大增加了,在加上有些假期沖掉課,就感覺我們好像上課學不到什麼東西,也只是一些關鍵的和考試掛鈎的才重點講,完全沒有擴展的時間和空間了。但是總的來説,學校開了這門課,我們上了這門課,總是學到了點東西的,不可能明明上了軟件工程這門課,卻像沒上一樣什麼都不懂。在上課的時候我還是很認真地去聽老師所講述的內容的,我覺得他的思想和我一向而來的培養計算機學生綜合素質的理解還是在一定程度上不謀而合了,所謂的需求獲取,那就是一個談判,辯論,交流的過程,已經不是單純的編編程序就能解決的問題了。從我所看到的聽到的來説,我最怕的就是計算機系的學生被別人説成是個帶着厚眼鏡的,只能夠在電腦前編編程序的,在交際場上不知道説什麼而一個字都説不出來的人。我覺得這樣的人進入社會之後是沒有什麼前途的,起碼他們缺乏了與人溝通交流的能力。而這門課程在一定程度上給了我們這些學生一個機會來鍛鍊自己在另一方面的能力,設想一下,一個又有技術又能夠與人交流合作的人所取得的成就自然要比一個單單隻會編程序的人要大得多。其次,這門課程教給了我們在完成一個實際項目時的一般程序及過程,我認為這是一份非常具有實際意義的教學內容。當我們在畢業之後,這是我們實際要運用的一項非常有用的技能,而且不僅僅侷限於軟件工程的範疇,我們即使是從事與其它行業,不也是要從需求獲取開始,一直有條有理地到最後成品的出爐嗎?應該説這就是這門課的價值所在。無論是在上課,還是在學生會裏面做學生工作,我都深深地感覺到,技術性的工作就好比變魔術,其實原理是非常簡單的,甚至可以説簡單的可笑,但是當你就是做出這麼一個簡單的東西出來之後,一些外行們有時候會用崇拜的眼光看着你,覺得你很厲害,很高深莫測。但是製作的過程他們卻不知道,也許知道之後他們只是會啞然失笑,原來這個東西的製作過程是如此的簡單。這個可以説就是技術的魅力了,而作為需求獲取及之後的一系列過程則是類似於魔術揭祕的過程,但是作為這個祕密我們並不需要一揭到底,至於揭的程度如何那就是我們那就是我們學出的程度如何了,我們要讓對方知道我們在做什麼?以及如何去做?這些東西需要我們以一定的技巧敍述出來,所起到的作用就是能夠讓對方瞭解自己的進度,卻又能夠不讓對方來干涉自己的工作過程。因為我們是技術員,對方只是外行,即使對方知道了這個魔術的操作過程,也並不代表他們就能夠向變着魔術的我們來隨便修改這個魔術的變法,況且我們能夠用不同的過程來得出一個同樣的結果,這個過程的得出的主動權如何掌握在我們的手上,就看我們如何以高明的方式來揭開這個魔術的謎底了。當然了,在純粹的理論上,我覺得開設這樣一門課程是很成功的。但是畢竟現實裏有太多的不確定的因素。最重要的因素就是授課的老師和聽課的學生。這兩個可以説是這門課成與敗的決定性的因素。

作為我們學生來説,應該負起比較主要的責任。在大學裏有了太多的基礎課程,基礎課程大多都比較枯燥無味,也許在第一個學期裏我們還能夠保持着新鮮感,但是在6學期之後,可以説再有新鮮感就是一件比較困難的事情了,我們都已經開始變得遲鈍了。其次的,沒有認識到這門課程的價值。這門課的價值我已經在上面説過了,是不言而喻的。但是並不是每個同學畢業之後都回從事計算機行業,也不是每個同學都知道這門課程的意義已經不僅僅侷限於計算機這個範疇。或許有些人覺得反正以後不是這個發展方向,也就不在乎這個課程吧。我個人覺得這門課確實是挺好的,如果認真學必能學到很多東西,動手實踐能力和從整個大體分析系統開發的邏輯性思維也會明顯增強,不管以後從事哪個方面的工作,這對以後來説都是一筆很大的隱性財富。説到我自己對這麼課的學習,還是有點愧疚的,前面四周我每週每節課都去上的,並且上課也認真聽,一邊聽老師講課一邊自己看書本的介紹,但是後來我上這門課的次數就降低了,因為覺得時間很緊吧,而且老師上課的節奏我個人覺得有點慢,我都可以自己預習看到後面去了,但是這門課我還是每週至少上一節課的,雖然我早上7點多一點就出門,在自習室,但是有時候明明知道到了上課的時間,明明上課的地方離自習的地方不遠也不太想去。我記得有次上課時候老師生氣了,説來上課的人少,我仔細環顧了下四周發現確實人很少,稀稀疏疏的分散着,看起來確實不太舒服,讓我不得不反思了,這大學的教育到底怎麼了,怎麼到了大四大家都不來上課,雖然我不是每節課都來,但是我還是時不時來上課的,可能是比較浮躁吧,快畢業了,覺得上課學不到什麼實際的東西,要麼實際一點好好考研繼續深造,要麼去培訓增強實踐能力這樣才能較好的為找個滿意的工作做好鋪墊。

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

軟件工程學習心得體會範文 篇3

軟件工程心得體會未接觸軟件工程之前一直都很想學這門課程,因為覺得這門課很牛,是那些有工程師稱號的高手才擺弄的東西。學了一個學期的軟件工程課,終於知道了個軟件工程的大概。學的時候總覺得很抽象,理解起來好像不難,但總是摸不着頭腦一種很茫然的感覺。曾經以為程序就是軟件,軟件就是程序。學習這門課程第一個收穫是,知道了二者的不同之處。以前做過的一些小型的軟件比如加密軟件,我也只是在程序旁邊附上一個軟件的説明,看來已經很接近作坊了。不過大的項目沒有接觸過,用軟件工程的方法還是第一次。我想也是程序的不斷複雜化導致了軟件危機的發生,使得人們不得不探索新的解決方法。

經過倪老師的講解,理解了軟件工程,就是一套用於軟件的團隊開發,以提高軟件質量和程序員工作效率為目的的規範。其核心就是,對於軟件開發的5個重要組成部分:需求分析,設計,編碼,調試,維護,如何組織這5個部分的工作,以及如何完成每一個工作。吾生也有涯,而知也無涯,學習永無止境。起初,對軟件工程處於一知半解的狀態,分工比較混亂。

在劃分模塊後明確了各自分工,漸漸形成良性循環。在學習過程中,知道了團隊合作十分重要,爭議固然存在,但通過討論、協商,羣策羣力,在不斷磨合中能夠達成一致與默契。團隊成員中能力各有高下,互相尊重,各取所長,不宜妄自菲薄。組長多加協調,組員積極配合,才能合作愉快。學習能力體現在能儘快接受新的知識,順應變化,學為所用。

上《軟件工程導論》這門課,我的收穫大概如下:我們為什麼需要軟件工程呢?上面已經給出了一些原因。專業點講,軟件工程最終是為了實現“軟件製造業”的社會化,工業化大生產,提高其勞動生產效率。只有如此,軟件業才能實現社會化,工業化大生產,才能“做大做強”。沒有管理的設計是失敗和混亂的設計,沒有設計指導的編程是無序的忙碌的。根據開發的軟件的規模,應該適當程度的運用軟件工程化的思想,需要靈活,畢竟我們開發的軟件大多數是中小型的,大型的並不多見(我是這麼認為的)。但只要涉及人員間的交流和溝通,或多或少都要需要軟件工程才能更有效率,工作成果更穩定。

其實開發軟件,就像是解決一個邏輯問題。想想自己平時是怎樣寫程序的。首先是要有一個想法,即我寫的這個程序是要幹什麼的;然後就是對要實現的核心功能大概構思一種或多種實現方法,並從中選出一種自認為是較好的;接下來就是將涉及的各種主要或次要功能分成各個模塊;最後就是分模塊來編碼和DEBUG。在我看來,除了第一步外,其餘的步驟應該是一個循環的過程。在編碼的過程中,你總是需要不斷地回過頭來修改原先的模塊設計,甚至最初選定的實現算法。具體到每一步的工作要怎樣完成,是非常靈活的,只要把握住大體的方向就行。在進行分析,設計,編碼,調試,維護這幾部分的工作的時候,最核心的就是文檔的編寫。1.可行性分析就是關於當前項目能不能幹的分析結果。

2.項目描述這是在決定立項以後,對當前項目的一份扼要説明。

3.需求分析就是對客户要求的功能的定義。

4.軟件設計這就是對程序的每一個模塊的詳細設計的説明文檔。

5.開發日誌我一直都認為這是文檔中最有趣的部分。開發日誌相當於編碼階段的文檔,它的形式可以很隨意,主要是記錄一些在寫程序時突然萌發的靈感,或對代碼的一些微小的修改,或對程序結構的一些微小變動等,還要對上述這些修改變動作些説明。

6.測試分析用於指出程序存在或潛在的缺陷和錯誤,以及程序性能的數字描述。

軟件工程學習心得體會範文 篇4

這次軟件工程實訓是從20xx.12.26號開始的,截至20xx.12.31號。實訓內容是用java相關知識(主要是jsp)做一個物流配送系統。下面談談對這次實訓的看法。

因為自己平時對java知識儲備不足,特別是jsp這一塊基本不瞭解怎麼回事,所以一拿到這個項目,我心裏都是沒有底的,再加上我被分到的那個組,我知道就意味着是我一個人在戰鬥了。呵呵,26號,實訓開始了,我們的老師是來自中軟國際公司的程序員,一個是周褀,一個是朱映,都是一身樸素的着裝,讓我感覺做軟件的也沒什麼兩樣。老師介紹了自己之後,就直接切入正題了,分析了下我們各個組的系統,即將用到的知識,然後就總體把覺得需要補充的知識(jsp和數據庫連接等這幾塊)給我們實際操作了下,因為當時看到用jsp,還講的那麼認真,當時我就後悔了,平時要是多聽點,現在老師這麼認真的給我們講,這是一個多麼難得的機會啊。後悔也沒用啊,開始還勉強能理解一點,後來就直接暈了。然後再給大家介紹了一些即將用到的工具,比如rationalRose,SVN,MyEclipse等等。接下來的幾天就不再細講了。下面談談通過這次實訓的心得體會吧。

通過這次實訓,讓我瞭解到工程開發的過程,可行性分析——>需求分析——>概要設計——>詳細設計——>代碼編寫——>測試——>驗收。從技術方面上,我開始jsp基礎基本上就是零的,在老師和syz2(另外一個物流小組,我一個人基本上是跟她們做的,或者説是看着她們做的)的幫助下,對jsp有了一個大概的認識。其實實訓開始前,我還以為做個系統沒什麼大不了,可是當真正拿到一個項目,我卻真的無從下手了,而且就是在知道需求分析和詳細設計,在代碼編寫時,一樣寸步難行。通過這個實訓,也讓我瞭解到,團隊協作是多麼的重要。一個人的精力是多麼的有限。進一步理解到,企業為什麼如此重視團隊協作。同時借用老師的話就是團隊協作固然重要,但是是建立在個人素質的基礎上,假設你個人素質不行,將會影響到整個團隊,就別提對團隊作更多貢獻了。**老師説這幾句話的時候,朝向了我,估計是有特殊意義的吧,所以,我將謹記老師的教導。

還有一個收穫是從一個同學(小胖)那裏得到的,他的那組成員跟我的這組大體一樣,我倒是覺得沒什麼了,不過他倒是很重視這個問題吧。然後他説出來,我也覺得這個問題確實其實是個大的問題。就是不管你會不會這門技術,會不會做這個東西,態度要正確才好,就算你不會做,你也應該認真的對待,將來 出身到社會,就不是説像你現在,不會做就不做,跑去玩遊戲了。小胖説出了這段話,也在我身上有了一個印證,雖然我jsp技術知識為0,但我也還是在認真的跟着他們一起做,不會做,就多問,畢竟現在我們是學生,可以毫不顧忌的詢問各種問題,老師也會盡力為你回答。將來出身社會就不一樣了。雖然,我就算個打醬油的水平,但是這個醬油也要打得有涵量啊。不管怎麼樣,我能對自己有個交待,雖然我不會,但是這次實訓我確實是認真對待了,六天的實訓,除了晚上加班外,還花了2個通宵來完成不同階段的任務,完成與否也不重要了,我至少我做了,這點,是這次我應該對自己的一個肯定。

這次實訓的心得基本上就是這些了,最後特別感謝中軟國際帶我們的那兩個老師(周褀,朱映),這兩個老師對待我們很平易近人,對我們提出的問題,總是不光解決了,還進行了擴展,晚上也跟我們一起加班加到很晚,印象尤其深刻就是朱映老師為了給小胖解決一個問題,臉都變紅了,還在繼續努力,這點我並不會覺得老師知識儲備不夠,我想應該是這個問題的突發吧,一時沒想到怎麼處理。相反讓我感覺更多的就是老師很認真,很負責。還要感謝就是syz2小組的傾力支持,輔導。

軟件工程學習心得體會範文 篇5

一、 實訓目的:

通過對java語言、sql數據庫的應用以及sql語言的複習和鍛鍊,並且通過使用MyEclipse開發平台設計管理項目,以達到充分熟悉開發平台及應用設計。同時掌握並實踐軟件項目設計規範及其開發流程:需求分析、概要設計、詳細設計、代碼編寫等,以便提前適應軟件公司開發流程、環境和工作要求。

二、實訓內容:

1. 項目:(“噹噹網”)

2. 完成(用户註冊、登錄、列表、購物車、刪除、修改)等功能

3. 數據庫設計、SQL應用

4. 項目實戰

三、實訓總結:

轉眼間實訓已過去一段時間,之前的興奮、喜悦如今已經讓我熟悉,在實訓的每一天都會讓我有成為一名真正的財富者擁有的衝動。也許,在這期間不一定會讓一個人有着翻天覆地的變化,但變化就是這樣一點一點產生的。通過這一期的實訓,雖然倍感折磨,但是收穫卻是很大的,學習中我不但有了學習成果的喜悦,而且自己也日漸成熟,有種説不出的喜悦。

在實訓的過程中,我深深的體會到了自己在專業知識方面的欠缺和不足,也意識到了自己作為計算機軟件專業的學生,要想在以後的職業中嶄露頭角,除了要有過硬的理論知識,健康的體魄之外,還必須具備良好的心理素質,是自己在以後的途中無論經歷什麼樣的困難,都立於不敗之地。通過實訓老師的課堂講解與企業文化標準的培訓,使我加深了對自己專業的認識,從而確定自己以後的努力方向,要想在短暫的實訓時間內盡多的學到東西,就需要我們跟老師或同學進行良好的溝通,加深彼此的瞭解,只有我們跟老師多溝通,讓老師更瞭解我們,才能更真切的對我們進行培訓工作。由此,班級的文化“共享”就在生活中慢慢形成了。

“紙上得來終覺淺,絕知此事要躬行!”在這短短的時間裏,讓我深深的感覺到自己在實際應用中所學來專業知識的匱乏。讓我真真領悟到“學無止境”這句話的涵義。而老師在專業認識周到中所講的,都是課本上沒有而對我們非常有實際意義的。這又給我們的實訓增添了濃墨淡彩的光輝。我懂得了實際生活中,專業知識是怎樣應用與實踐的。在這些過程中,我不僅知道了職業生涯所需具備的專業知識,而且讓我深深體會到一個團隊中的各個成員合作的重要性,要善於團隊合作,善於利用別人的智慧,這才是大智慧。靠單一的力量是很難完成一個大項目的,在進行團隊合作的時候,還要耐心聽取每一個成員的意見,是我們的組合達到更加完美。

這次實訓除了讓我明白工作中需要能力,素質,知識之外,更重要的是學會了如何去完成一個任務,懂得了享受工作。當遇到問題,冷靜,想辦法一點一點的排除障礙,到最後獲取成功,一種自信心就由然而生,這應該就是工作的樂趣。有時候不懂的就需要問別人了,虛心請教,從別人的身上真的能學到自己沒有的東西,每一次的挫折都會使我更接近成功。還有學會了在工作中與人的合作與交流,同樂同累,合作互助,這是團體的精神,也是必須學習的東西。

經過之前的學習,對程序設計有了一定的認識與理解。在校期間,一直都是學習理論知識,沒有機會去參與項目的開發。所以説實話,這次實訓,軟件項目開發對我來説是比較抽象的,一個完整的項目要怎麼分工以及完成該項目所要的步驟也不是很明確。而經過這次實訓,讓我明白了一個完整項目的開發,必須由團隊來分工合作,並在每個階段中進行必要的總結與論證。

一個完整項目的開發它所要經歷的階段包括:遠景範圍規劃和用例説明、項目結構和風險評估、業務功能説明書、詳細設計説明書、代碼實現、測試和安裝包等等。一個項目的開發所需要的財力、人力都是很多的,如果沒有一個好的遠景規劃,對以後的開發進度會有很大的影響,甚至會出現在預定時間內不能完成項目或者完成的項目跟原來預想的不一樣。一份好的項目結構、業務功能和詳細設計説明書對一個項目的開發有明確的指引作用,它可以使開發人員對這個項目所要實現的功能在總體上有比較明確的認識,還能減少在開發過程中出現不必要的麻煩。代碼的實現是一個項目開發成功與否的關鍵,也就是説,前期作業都是為代碼的實現所做的準備。

我深刻的認識到要成為一名優秀的軟件開發人員不是一件容易的事情,不僅要有足夠的幹勁和熱情,還要有紮實的編寫代碼基礎,必須要有事先對文檔進行可靠性報告,功能説明書,詳細設計説明書等的編寫和一些風險評估的編寫的能力。

除了圖書館,最能讓我感覺到身在大學的就是實訓機房,在匆匆過去的兩個月內,我往返於實訓機房與宿舍之間,使我享受了一個充實的學習時期,讓我感受到了大學的魅力,對自己充滿信心,對大學充滿信心,以積極的心態迎接明天挑戰。

實訓中要求有紮實的理論基本知識,操作起來才順心應手,我這時才明白什麼是“書到用時方恨少”。這就激發了學習的慾望。 “學以致用”,就是要把學來的知識能運用到實際操作當中,用實踐來檢驗知識的正確性。我想,這是實訓的最根本目的。

最初在實訓時自己就有一些不自信,但隨着項目的進展,我慢慢的找到了自己的位置,找到自己的目標,雖然自己與好的同學還有差距,這也給了我很大壓力,但是我相信沒有壓力就沒有動力,所以在整個實訓過程中我都在不斷地努力。

實訓期間讓我學到很多東西,不僅在理論上讓我對IT領域有了全新的認識,在實踐能力上也得到了很大的提高,真正的學到了學以致用,更學到很多做人的道理,對我來説受益匪淺。我意識到自己知識的缺少,這激勵我在以後的學習、工作、生活中要不斷了解信息技術發展動態以及信息發展中出現的新的技術。

除此之外,我還學到了如何與人相處,如何和人更好的交流,我們組成一個團隊大家一起開發一個項目,大家的交流溝通顯得尤為重要,如何將自己的想法清楚明白的告訴隊友,如何提出自己想法的同時又不傷害其他的隊友的面子,這些在我的實訓生活中都有一些體會。可是説,第一次親身體會理論與實際相結合,讓我大開眼界。也是對以前學習的一個初審吧,相信這次實訓多我以後的學習、工作也將會有很大的影響,在實訓的這段時間裏這些寶貴的經驗將會成為我以後工作的基石。

作為即將畢業走出校園的學生,經過3年的在校學習,對程序設計有了一些基本的理性的認識和理解。在校期間一直忙於理論的學習,沒有機會也沒有經驗來參與我們項目的開發,所以在實習之前軟件按開發對我來説是非常抽象的,一個完整的項目要怎麼來分工以及完成該項目所需要的基本步驟也不明確,通過這次實訓讓我明白一個完整項目的完成必須團隊分工合作,並在每個階段進行必要的總結和檢查。在我們項目的開發過程中我們項目的步驟:詳細設計、詳細設計review、編碼、編碼。在項目開發過程中我也深刻的體會到詳細設計對一個項目開發有明確的指引作用,它可以使開發人員對這個項目所要實現的功能在總體上有具體的認識,並能減少在開發過程中出現不必要的脱節。

這次實訓是對我們學習的一個檢驗,雖然項目中很多知識我們在日常的學習中都沒有遇到,這同時提醒我:要想成為一個合格的程序員就有具備一種自學能力,在工作中會遇到很多從未接觸過的問題,當有了問題時要去解決,在你不斷努力,尋找答案的過程中,自己的能力也在潛移默化的提升。有時遇到問題時可能有很多想法但卻不知道那個正確,這就讓我們不斷地去探索,不斷地嘗試。

軟件工程學習心得體會範文 篇6

時間過的很快,轉眼間已經實習將近5個月,其中有2個月是屬於完全被流放的。 最先在內部系統組參與內部管理系統開發(struts+mysql+spring+hibernate),之後是去做網絡交換機軟件的腳本測試。現在又迴歸內部系統,雖然在腳本組期間,編碼能力被別人甩在後頭,但至少具有了一些測試經驗。

至少自己做的東西,是真正交付到了客户手上,到也稍微有些成就感。

1、淺談測試

一直以來,我都認為測試是脱離了軟件工程範圍的工作,不以為屑。但在實際情況中,測試是既重要且難以精湛的.其真正的壓力,在於找不到bug,責任在你,而不在於編碼人員。一般的測試人員不懂編碼,他們靠的是日以累計的經驗總結和想象力。而要做到高級測試工程師,則一定要懂編碼,因為這是你完全掌握整個系統的方方面面具體運作的前提。但占主導地位的,還是大型系統的集成測試經驗。實際項目中,編碼時間一般只佔30%左右,真正耗費時間的是IT階段的找 bug與對應bug,此階段基本評定了coder的編碼質量。

2、程序員的困惑

有些人,以為教學視頻和代碼看多,自己就懂的多,實際做起來,卻不知從何下手,問題在那?如何定位?如何解決?通通跟一樣能力有關,debug追蹤能力,也稱調試。在項目組工作不愁源碼資源,但問題是蛋糕擺在面前,你如何去消化?

有位同事告訴我:代碼看幾遍都沒用,要去抄,例如一個查詢模塊,在此基礎上去做具體記錄的歷史記錄查詢模塊,你可能會覺得很簡單,但實際情況卻往往報一堆異常,配置問題涉及到方方面面,以及數據庫字段,傳值問題等等,一大堆對於新人來説很鬱悶的問題。但不用怕,只要學會調試,一個個問題去追蹤,一個個去解決,自然而然,那段“源碼”才真正屬於你。

3、如何調試追蹤

如果你能在短短的時間內就看到問題點在那,放下斷點去追蹤,出去找工作,絕對沒問題。出現問題的時候,不要光看代碼,要用實際行動去追蹤運行期間的具體值,那是最好途徑。eclipse是個很爽的ide,這點做的很好。例如頁面內容顯示不是自己想要的數據,我們要先從數據庫查詢語句去下手,設置斷點,一步一步step over,讓sql字段(存取最終sql語句的字符串)運行到有值,inspect進去看,如果還看不出來,就點擊它,copy後在sql客户端去實際運行,看看實際查詢出來的表是什麼,如果是對的,有可能就是頁面調用的錯誤或者action邏輯的傳值問題。

頁面錯誤的調試,基本方法是用右鍵點擊實際網頁查看源代碼,copy到editplus,就能看到具體錯誤發生在那幾行。通常有幾種常見的錯誤,例如:缺少對象這種很多時候是有些被你調用的字段有可能為空的情況出現的,可以加if(=null)語句加保護。追蹤的方法基本就是用alert語句,放在有可能出錯的地方。

4、一些習慣

遇到問題先自己思考,無從下手再找高手幫忙看看,注意他幫你看的思路,別在一旁閒着,看多了自己也會了,不然你一輩子都停留在那種水平,從人身上學到的東西遠遠比書多的多。

解決了一個問題後,要去究根問底去找到問題產生的起因,以防你下次遇到類似的問題再浪費同樣的時間。

把代碼寫的漂亮,註釋、空行、規範一樣不能少,可讀性是放在第一位。曾經看過一個高手寫的代碼,真的一看就是不同水平的人寫的,幾乎很完美,讀起來很流暢,方便自己也方便別人。

任務完後不要呆着,去要求經理給你更有挑戰性的任務,只要你肯去嘗試,他們就會對你另言相看,把三天的任務一天加班搞定,效率和忠誠都有了,路也比較好走了。

軟件工程學習心得體會範文 篇7

經過長時間對國貿軟件的的使用,在不斷練習操作的過程中,我對國貿軟件的最深刻感覺是:學以致用、有趣、必須細心耐心反應迅速。

1.學以致用

作為國貿專業,經過長時間的理論學習,急需通過實際操作或某種近似於實際操作的平台對所學的理論知識加以實踐,以求進一步掌握和鞏固,而國貿軟件正提供了這樣一種平台。該軟件涉及了及出口貿易的各個方面和環節,從外貿公司的經營運作到實際的進出口業務流程,都能進行模擬實訓。在使用過程中,會遇到很多國貿的基礎理論知識和實務技能,這是對國貿理論掌握程度的最好考察。眼過千遍不如手過一遍,相對於理論部分而言,國貿實務更注重實際操作,通過這種理論結合實踐的方式,鞏固基礎知識,查找理論學習的不足,以前學習的實物理論基礎知識會更加的具體和直觀。同時,該軟件的實務操作部分與報關員報關實務所涉及的知識基本一致,這對於我的報關員考試複習提供了很大的幫助。

2.有趣

該軟件通過“實戰”方式訓練,會在操作過程中遇到很多難題和挑戰,這些必須自己想辦法解決。由於大家進行了角色劃分,形成了一個虛擬市場,所以大家之間相互的競爭是必不可少的,大家會從各個方面進行競爭。競爭在現在是無法避免的,意識正是現代社會生存發展所需要的。正是這種競爭,使得我(相信大家)對該軟件產生了濃厚的興趣。

3.細心、耐心、反應迅速

國貿軟件涉及大數據計算的繁瑣的單證填寫,所以必須做到細心耐心,例如,在填制外貿合同時,一個小小的數據錯誤或是貨物裝運、指運港名稱的錯誤都會是合同填寫失敗;填寫保險單或是報關單證,沒有嚴格按照合同數據填制就會導致填寫出現錯誤,無法進行下一步驟,影響實驗效率。

在操作過程中,除了複習、鞏固所學國貿理論外,另一個重要任務就是想辦法“賺錢”,提高自己企業的盈利水平和生存能力,這就要求必須反應迅速、判斷準確,否則會覺得企業經營的舉步維艱。

以上就是經過一段時間對國貿軟件的操作使用產生的心得體會。

aaa篇2

我們是20xx年3月7號進入宏天實訓公司參加軟件開發實訓的,在此次實訓中,除了讓我明白工作中需要能力,素質,知識之外,更重要的是學會了如何去完成一個任務,懂得了享受工作。當遇到問題,冷靜,想辦法一點一點的排除障礙,到最後獲取成功,一種自信心就由然而生,這應該就是工作的樂趣。有時候不懂的就需要問別人了,虛心請教,從別人的身上真的能學到自己沒有的東西,每一次的挫折都會使我更接近成功。還有學會了在工作中與人的合作與交流,同樂同累,合作互助,這是團體的精神,也是必須學習的東西。

經過之前的在校學習,對程序設計有了一定的認識與理解。在校期間,一直都是學習理論知識,沒有機會去參與項目的開發。所以説實話,在實訓之前,軟件項目開發對我來説是比較抽象的,一個完整的項目要怎麼分工以及完成該項目所要的步驟也不是很明確。 而經過這次實訓,讓我明白了一個完整項目的開發,必須由團隊來分工合作,並在每個階段中進行必要的總結與論證。

一個完整項目的開發它所要經歷的階段包括:遠景範圍規劃和用例説明、項目結構和風險評估、業務功能説明書、詳細設計説明書、代碼實現、測試和安裝包等等。一個項目的開發所需要的財力、人力都是很多的,如果沒有一個好的遠景規劃,對以後的開發進度會有很大的影響,甚至會出現在預定時間內不能完成項目或者完成的項目跟原來預想的不一樣。一份好的項目結構、業務功能和詳細設計説明書對一個項目的開發有明確的指引作用,它可以使開發人員對這個項目所要實現的功能在總體上有比較明確的認識,還能減少在開發過程中出現不必要的麻煩。代碼的實現是一個項目開發成功與否的關鍵,也就是説,前期作業都是為代碼的實現所做的準備。

我深刻的認識到要成為一名優秀的軟件開發人員不是一件容易的事情,不僅要有足夠的幹勁和熱情,還要有紮實的編寫代碼基礎,必須要有事先對文檔進行可靠性報告,功能説明書,詳細設計説明書等的編寫和一些風險評估的編寫的能力。

除了圖書館,最能讓我感覺到身在大學的就是實訓機房,在匆匆過去的兩個月內,我往返於實訓機房與宿舍之間,使我享受了一個充實的學習時期,讓我感受到了大學的魅力,對自己充滿信心,對大學充滿信心,以積極的心態迎接明天挑戰。

實訓中要求有紮實的理論基本知識,操作起來才順心應手,我這時才明白什麼是“書到用時方恨少”。這就激發了學習的慾望。

“學以致用”,就是要把學來的知識能運用到實際操作當中,用實踐來檢驗知識的正確性。我想,這是實訓的最根本目的。

“紙上得來終覺淺,絕知此事要躬行!”,在短暫的實訓過程中,讓我深深感受到自己在實際運用中專業知識的匱乏。以前總以為自己學的還不錯,一旦應用到實際就大不一樣了,這時才真正領悟“學無止境”的含義。

經過為期兩個月的電子政務服務平台系統開發的實訓,我對Visual 軟件開發平台有了更深一步的瞭解,對微軟基礎類庫的認識與使用也有了大大的提高。以及如何使用SQL Server數據庫進行連接操作方面有了本質的提高。

短短的實訓結束了,為我將來的就業打下了良好的基礎,也提高了我的軟件開發的水平,今後我將會更加努力的學習,不斷提高自身素質,開拓創新,與時俱進,做一個優秀的軟件開發工程師。

aaa篇3

這學期學習了軟件工程實踐這門課,我覺得這是對上學期的軟件工程課程學習的檢驗,上學期學習軟件工程只是我們淺顯的認識,相比之下,這學期就更加全面的説明了開發一個項目所需要的步驟以及開發項目過程中所需要注意的諸多細節。如果説上學期的課程注重理論基礎的話,那麼這學期的軟工實踐,顧名思義,就是側重我們動手操作的能力。

原來我認為開發一個項目最重要的就是寫代碼,似乎整個軟件都是編代碼,因為自己動手能力不強所以就很排斥做項目。可是經過我們學習軟工課程到團隊做項目再到學習軟件工程實踐課程之後,我才真正意識到實施一個軟件工程項目並不是説簡單的會編碼就能夠解決問題的,因為一個軟件的生命週期分為三個時期:軟件定義時期、開發時期、維護時期,而這三個時期整體又分為七個階段,他們分別是:問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試,由此可看出,當我們開發一個項目時,更多的精力不是放在編碼上,編碼只是一個很小的模塊,而是項目的整體結構上。

在寫軟工實踐體會之前,我想在這裏總結一下上學期三人團隊做 項目的相關事宜。上學期我們三人團隊根據軟件開發的步驟開發一個名為“西大老鄉‘薈’”的社交系統,主要是為西大學子提供一個找老鄉的平台。雖然只進行到詳細設計階段,沒有進一步實現,但是我還是從中學到很多東西的。首先要先確定項目主題,也就是這個項目用來做什麼,可以解決什麼問題。接着就是這個項目是否有研究的必要以及是否有解決的辦法,針對我們的項目,我們對西大的一些學生做了問卷調查,並從調查中繼續完善系統本身的做用户。第三步根據我們確定的項目主題進行需求分析,這一步驟當時做的不是很好,比如所畫E-R圖、數據流圖等都有考慮不周的問題,導致接下來的概要設計、詳細設計進行的很困難,有些步驟甚至還需要返工。

從我們在需求分析中出現的問題,使我們明白了軟件定義階段對於一個項目的開發是至關重要的,當軟件定義階段完成時必須要用正式的文檔準確的地記錄目標系統的需求。只有前期的準備工作做得好,後面的工作才能順利進行。雖然項目最後沒有完全實現,但是起碼我們已經初步體會到軟件項目開發的步驟,以及每一步所需要完成的文檔等內容。

這學期的軟件工程實踐雖然不是親自動手開發一個系統,但是張元平老師以“物聯網物流倉儲管理系統”為主給我們講解了一個真實系統的開發過程,從計劃到項目系統的發佈實施,以及每一步必須生成的文檔。我主要從以下五個方面談一下我的心得體會。

第一、行業背景説明方面

對於一個軟件系統的開發,第一步就是問題定義,瞭解所開發系統的行業背景,制定計劃。當我們計劃確定以後就要對項目系統本身進行可行性研究,主要從技術可行性、經濟可行性和操作可行性三個方面着手。就比如《物聯網物流倉庫管理系統》的行業背景説明文檔中非常詳細地分析了當下物聯網物流行業的整體業務説明、應用背景、未來發展趨勢以及相關應用案例等四個方面,項目團隊中系統分析員就可以根據這份文檔以及相關的調查資料對將要開發系統的進行定義等工作。

原來我們寫這類文檔的時候就是草草了事,不會做得這麼詳細,而這次看到大型項目的行業背景説明也是這麼詳細,也讓自己認識到不管是軟件開發的那個階段都要認真對待,這些瑣碎的文檔都是後期開發項目的支撐,只要它們做的透徹,後面的開發工作才能更順利的進行。

第二、項目需求説明方面

這部分項目需求説明就是軟件定義時期中需求分析階段,而該階段的主要目的就是了解用户的需要,根據用户的需要確定系統必須完成那些工作,並對目標系統提出完整、準確、清晰、具體的要求。在需求分析結束之前系統分析人員要寫出一份需求規格説明,即為《物聯網物流倉儲管理系統》項目需求説明文檔。我們可以看出該文檔也是非常詳細,相比之下我們之前做項目時寫的需求規格説明書就非常不合格,不僅格式不正確內容也是少之又少。

在這方面,這篇文檔給我啟發很大。首先就是文檔的格式,要美觀整齊,讓人看着舒服方便。其次就是文檔的內容,原來它不是很重要,寫文檔的時候也不知道怎麼寫就借鑑下網上的內容,結果根本就沒有把自己項目的需求寫明白,以至於自己最後都有些糊塗,所以根據以前的經驗教訓我會對這部分更加重視。

第三、系統概要設計方面

這部分內容分説的是軟件設計時期的概要設計階段,該階段的主要目的就是實現系統的功能、設計軟件的結構、模塊組成以及模塊之間的關係。在概要設計階段,我們可以站在全局的高度上,花較少的成本,從抽象的層次上分析對比多種可能的系統實現方案和軟件結構,從中選出最佳方案和最合理的結構。在這個階段還會具體畫出E-R圖、數據流圖等方面的設計。

比如《物聯網物流倉庫管理系統》的系統概要設計從項目概述、設計約束、功能單元與功能模塊設計、數據E-R圖設計、總體設計、界面設計等六個方面介紹,通過讀這個文檔,我覺得最重要的還是總體設計,分別從邏輯架構設計、物理架構設計、技術架構設計設計系統。在這個階段中模塊要做到高內聚低耦合,這樣開發出來的系統才會具有更高的獨立性。

在原來做項目時沒有編寫過這類文檔,在該階段只是畫了結構圖、層次圖以及相關的模塊劃分,對該類文檔尚未重視。通過張老師的講解和自己的學習,我相信在以後做項目的時候一定會注意到這類文檔的編寫。

第四、詳細設計與分析方面

詳細設計階段就是把概要設計階段的每個模塊進一步設計,確定每個模塊所需要的算法和數據結構。在這個階段還是需要我們設計出程序的詳細規格説明,而不是編寫程序。在詳細設計階段,系統設計人員可以通過使用程序流程圖、盒圖、PAD圖等過程設計的工具和Jackson圖等面向數據結構的設計工具進一步設計系統相關接口,主要包括界面設計接口、業務單設計接口、單元模塊設計接口等,這些對於以後的編碼工作都是極其重要的。

第五、編碼和測試方案方面

關於編碼,我認為編碼要想做的完美必備條件就是前面的軟件定義和軟件設計時期要按部就班的做,文檔一定要按要求書寫,不能偷懶也不能草草書寫。對於編碼也要有相應的文檔書寫規範,要使源程序代碼的邏輯簡明清晰、易讀易懂。這樣儘管我們不是設計系統的人員,當看到源程序代碼的時候也能容易讀懂代碼的意思。

其次就是測試的內容,從測試的文檔中我們可以得出,其實測試在軟件開發中同樣佔據了重要的地位,它主要就是儘可能多的找到問題並排除其中的潛藏的錯誤,最終把一個高質量的軟件系統交給用户使用。它要求測試人員也要有很高的技術水平。

軟件工程學習心得體會範文 篇8

時間飛逝,不知不覺間《軟件工程》的學習已經過了大半了。在這將近半學期的學習中,雖然我不能説我將《軟件工程》學習的有多麼的好,但是通過學習,我還是受益良多。

在以前,我一直對軟件存在一些偏見或則是誤解,認為軟件就是程序,軟件的開發就是編寫程序,只要編完了程序,一切也就ok了,而且我還片面的認為只要我掌握了時下最新的語言和工具,那麼我就能寫程序了。一個人,只要會編程,就能寫軟件,就是程序員;一個公司,只要招聘一些程序員,就能開發好的軟件產品。只要有幾個有經驗的程序員,再找些兼職的大學生,就能組成一個軟件公司。

但是通過了《軟件工程》這門課的學習,使我認識到了我以前的錯誤。軟件其實不僅僅是程序,軟件開發其實也不僅僅是編寫程序,軟件是思想在硬件上的載體和體現,處理的是邏輯和信息。唯有對軟件和軟件的開發過程,有充分的認識,才能更好的開發出,過程受控、質量受控的軟件產品。

而且在以前,我一直以為軟件的開發其實是一件很輕鬆快樂的事情,只要一天坐在電腦旁敲敲鍵盤,那麼一切就可以了,但是現在我才發現,我以前的很多的思想是多麼的膚淺可笑。編程其實是一種樂趣和苦惱共存的一項創造性活動。因為編程不僅能夠滿足我們內心深處進行創造的渴望,而且還能愉悦我們內在的情感。

而且通過學習《軟件工程》,我還學到了很多其他的東西。比如通過學習《軟件工程》,特別是老師每次用實際的軟件現場的講解,為我提供了一個儘早接觸世界工作和真實項目的機會。讓我知道如何在以最小的成本中,訓練自己的基本工程素質和能力,如何激發自己的積極性等。而且通過學習《軟件工程》,還讓我認識和培養了我的團隊協作能力,特別是對於我們這些在校的學生來説,這種學習更是能讓我在以後工作中少走很多的彎路。

所以,通過《軟件工程》的學習,我是真的學習到了很多有用的東西,讓我明白了很多的道理。在此我對老師的辛勤教育表示感謝,因為是你讓我學習到了這些,是我獲益良多。

軟件工程學習心得體會範文 篇9

在這次軟件工程課程中,我學到了很多東西,第一次深刻的體會到了什麼叫做用工程化的思想來編寫軟件,以前自己也寫過一些小型軟件,沒有做過大型的項目,直到這次課堂我擔任組長並組織組員共同完成“個人圖書管理系統”這個項目,第一次和別人合作,才發現運用工程化的思想來做是如此的有必要。

從這裏,我才真正的意識到實施一個軟件工程並不是説簡單的會編碼就能夠解決問題的,我們更多的精力不是放在編碼上,編碼只是一個很小的模塊,只佔到那麼小的一個部分。這個事實在很大程度上顛覆了我以前的思想,在我以前的認識中,似乎整個軟件就是編碼,除此無它,還好有老師的指導,不然真的會出現老師所説的,撞得頭破血流之後才想起來用軟件工程的思想來完成這個工作。

剛真正開始工作之前,我們費了很多的時間來完成一些前端工作,如需求分析和可行性分析,這塊工作在別人看來可能是相對無關緊要,甚至是多於的,其實,換做在以前,我也會這麼認為。可是,我現在算是深深地明白了磨刀不誤砍柴工的道理,這些工作的完成太有必要了,太重要了,要想你的軟件有用有市場,能被別人接受和認可,在進行過程中不會出現崩潰性的問題,這些工作缺一不可。

還有就是接下來的一些設計模塊,此模塊與軟件編碼涉及比較緊密,主要是解決一些參數傳遞和接口通訊的問題,此模塊對我的觸動遠沒有上兩個模塊對我的影響大,因此再次也不做過多的介紹。

在整個活動的完成過程中,作為組長,我收穫很多,我發現,要是組裏有個人不怎麼想做事情時,他對於整個組織的影響是毀滅性的,正所謂“一顆老鼠屎,能壞一倉谷”,以後我的組織裏要是出現這樣的人,我絕不會給他繼續留下來的機會,我會在第一時間將他清除出去。還有就是,作為組長,你要做的最重要的事情,不是發揮自己的聰明才智,而是創造出一個平台,讓別人去發揮,你所要做得,出了保證這個平台的完整性和公平性外,還有就是協調好各組員之間的關係。

  • 文章版權屬於文章作者所有,轉載請註明 https://wjfww.com/xinde/xuexi/wevxew.html
專題