我們得到了一些心得體會以后，應該馬上記錄下來，寫一篇心得體會，這樣能夠給人努力向前的動力。大家想知道怎么樣才能寫得一篇好的心得體會嗎？下面我幫大家找尋并整理了一些優秀的心得體會范文，我們一起來了解一下吧。
軟件工程實踐總結軟件工程專業實訓心得體會篇一
在這次軟件工程課程中，我學到了很多東西，第一次深刻的體會到了什么叫做用工程化的思想來編寫軟件，以前自己也寫過一些小型軟件，沒有做過大型的項目，直到這次課堂我擔任組長并組織組員共同完成“個人圖書管理系統”這個項目，第一次和別人合作，才發現運用工程化的思想來做是如此的有必要。
從這里，我才真正的意識到實施一個軟件工程并不是說簡單的會編碼就能夠解決問題的，我們更多的精力不是放在編碼上，編碼只是一個很小的模塊，只占到那么小的一個部分。這個事實在很大程度上顛覆了我以前的思想，在我以前的認識中，似乎整個軟件就是編碼，除此無它，還好有老師的指導，不然真的會出現老師所說的，撞得頭破血流之后才想起來用軟件工程的思想來完成這個工作。
剛真正開始工作之前，我們費了很多的時間來完成一些前端工作，如需求分析和可行性分析，這塊工作在別人看來可能是相對無關緊要，甚至是多于的，其實，換做在以前，我也會這么認為。可是，我現在算是深深地明白了磨刀不誤砍柴工的道理，這些工作的完成太有必要了，太重要了，要想你的軟件有用有市場，能被別人接受和認可，在進行過程中不會出現崩潰性的問題，這些工作缺一不可。
還有就是接下來的一些設計模塊，此模塊與軟件編碼涉及比較緊密，主要是解決一些參數傳遞和接口通訊的問題，此模塊對我的觸動遠沒有上兩個模塊對我的影響大，因此再次也不做過多的介紹。
在整個活動的完成過程中，作為組長，我收獲很多，我發現，要是組里有個人不怎么想做事情時，他對于整個組織的影響是毀滅性的，正所謂“一顆老鼠屎，能壞一倉谷”，以后我的組織里要是出現這樣的人，我絕不會給他繼續留下來的機會，我會在第一時間將他清除出去。還有就是，作為組長，你要做的最重要的事情，不是發揮自己的聰明才智，而是創造出一個平臺，讓別人去發揮，你所要做得，出了保證這個平臺的完整性和公平性外，還有就是協調好各組員之間的關系。
這就是我的實習感想。
軟件工程實踐總結軟件工程專業實訓心得體會篇二
這學期學習了軟件工程實踐這門課，我覺得這是對上學期的軟件工程課程學習的檢驗，上學期學習軟件工程只是我們淺顯的認識，相比之下，這學期就更加全面的說明了開發一個項目所需要的步驟以及開發項目過程中所需要注意的諸多細節。如果說上學期的課程注重理論基礎的話，那么這學期的軟工實踐，顧名思義，就是側重我們動手操作的能力。
原來我認為開發一個項目最重要的就是寫代碼，似乎整個軟件都是編代碼，因為自己動手能力不強所以就很排斥做項目。可是經過我們學習軟工課程到團隊做項目再到學習軟件工程實踐課程之后，我才真正意識到實施一個軟件工程項目并不是說簡單的會編碼就能夠解決問題的，因為一個軟件的生命周期分為三個時期：軟件定義時期、開發時期、維護時期，而這三個時期整體又分為七個階段，他們分別是：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試，由此可看出，當我們開發一個項目時，更多的精力不是放在編碼上，編碼只是一個很小的模塊，而是項目的整體結構上。
在寫軟工實踐體會之前，我想在這里總結一下上學期三人團隊做項目的相關事宜。上學期我們三人團隊根據軟件開發的步驟開發一個名為“西大老鄉‘薈’”的社交系統，主要是為西大學子提供一個找老鄉的平臺。雖然只進行到詳細設計階段，沒有進一步實現，但是我還是從中學到很多東西的。首先要先確定項目主題，也就是這個項目用來做什么，可以解決什么問題。接著就是這個項目是否有研究的必要以及是否有解決的辦法，針對我們的項目，我們對西大的一些學生做了問卷調查，并從調查中繼續完善系統本身的做用戶。第三步根據我們確定的項目主題進行需求分析，這一步驟當時做的不是很好，比如所畫e-r圖、數據流圖等都有考慮不周的問題，導致接下來的概要設計、詳細設計進行的很困難，有些步驟甚至還需要返工。
從我們在需求分析中出現的問題，使我們明白了軟件定義階段對于一個項目的開發是至關重要的，當軟件定義階段完成時必須要用正式的文檔準確的地記錄目標系統的需求。只有前期的準備工作做得好，后面的工作才能順利進行。雖然項目最后沒有完全實現，但是起碼我們已經初步體會到軟件項目開發的步驟，以及每一步所需要完成的文檔等內容。
這學期的軟件工程實踐雖然不是親自動手開發一個系統，但是張元平老師以“物聯網物流倉儲管理系統”為主給我們講解了一個真實系統的開發過程，從計劃到項目系統的發布實施，以及每一步必須生成的文檔。我主要從以下五個方面談一下我的心得體會。
第1、行業背景說明方面
對于一個軟件系統的開發，第一步就是問題定義，了解所開發系統的行業背景，制定計劃。當我們計劃確定以后就要對項目系統本身進行可行性研究，主要從技術可行性、經濟可行性和操作可行性三個方面著手。就比如《物聯網物流倉庫管理系統》的行業背景說明文檔中非常詳細地分析了當下物聯網物流行業的整體業務說明、應用背景、未來發展趨勢以及相關應用案例等四個方面，項目團隊中系統分析員就可以根據這份文檔以及相關的調查資料對將要開發系統的進行定義等工作。
原來我們寫這類文檔的時候就是草草了事，不會做得這么詳細，而這次看到大型項目的行業背景說明也是這么詳細，也讓自己認識到不管是軟件開發的那個階段都要認真對待，這些瑣碎的文檔都是后期開發項目的支撐，只要它們做的透徹，后面的開發工作才能更順利的進行。
第2、項目需求說明方面
這部分項目需求說明就是軟件定義時期中需求分析階段，而該階段的主要目的就是了解用戶的需要，根據用戶的需要確定系統必須完成那些工作，并對目標系統提出完整、準確、清晰、具體的要求。在需求分析結束之前系統分析人員要寫出一份需求規格說明，即為《物聯網物流倉儲管理系統》項目需求說明文檔。我們可以看出該文檔也是非常詳細，相比之下我們之前做項目時寫的需求規格說明書就非常不合格，不僅格式不正確內容也是少之又少。
在這方面，這篇文檔給我啟發很大。首先就是文檔的格式，要美觀整齊，讓人看著舒服方便。其次就是文檔的內容，原來它不是很重要，寫文檔的時候也不知道怎么寫就借鑒下網上的內容，結果根本就沒有把自己項目的需求寫明白，以至于自己最后都有些糊涂，所以根據以前的經驗教訓我會對這部分更加重視。
第3、系統概要設計方面
這部分內容分說的是軟件設計時期的概要設計階段，該階段的主要目的就是實現系統的功能、設計軟件的結構、模塊組成以及模塊之間的關系。在概要設計階段，我們可以站在全局的高度上，花較少的成本，從抽象的層次上分析對比多種可能的系統實現方案和軟件結構，從中選出最佳方案和最合理的結構。在這個階段還會具體畫出e-r圖、數據流圖等方面的設計。
比如《物聯網物流倉庫管理系統》的系統概要設計從項目概述、設計約束、功能單元與功能模塊設計、數據e-r圖設計、總體設計、界面設計等六個方面介紹，通過讀這個文檔，我覺得最重要的還是總體設計，分別從邏輯架構設計、物理架構設計、技術架構設計設計系統。在這個階段中模塊要做到高內聚低耦合，這樣開發出來的系統才會具有更高的獨立性。
在原來做項目時沒有編寫過這類文檔，在該階段只是畫了結構圖、層次圖以及相關的模塊劃分，對該類文檔尚未重視。通過張老師的講解和自己的學習，我相信在以后做項目的時候一定會注意到這類文檔的編寫。
第4、詳細設計與分析方面
詳細設計階段就是把概要設計階段的每個模塊進一步設計，確定每個模塊所需要的算法和數據結構。在這個階段還是需要我們設計出程序的詳細規格說明，而不是編寫程序。在詳細設計階段，系統設計人員可以通過使用程序流程圖、盒圖、pad圖等過程設計的工具和jackson圖等面向數據結構的設計工具進一步設計系統相關接口，主要包括界面設計接口、業務單設計接口、單元模塊設計接口等，這些對于以后的編碼工作都是極其重要的。
第5、編碼和測試方案方面
關于編碼，我認為編碼要想做的完美必備條件就是前面的軟件定義和軟件設計時期要按部就班的做，文檔一定要按要求書寫，不能偷懶也不能草草書寫。對于編碼也要有相應的文檔書寫規范，要使源程序代碼的邏輯簡明清晰、易讀易懂。這樣盡管我們不是設計系統的人員，當看到源程序代碼的時候也能容易讀懂代碼的意思。
其次就是測試的內容，從測試的文檔中我們可以得出，其實測試在軟件開發中同樣占據了重要的地位，它主要就是盡可能多的找到問題并排除其中的潛藏的錯誤，最終把一個高質量的軟件系統交給用戶使用。它要求測試人員也要有很高的技術水平。
軟件工程實踐總結軟件工程專業實訓心得體會篇三
這次實習的目的是提高我的專業技能、實踐能力，讓我了解一些實際的工作情況。正式工作前對我意義重大。在實踐中對專業技能、綜合素質、人際關系有更深的體會，這給了我正式工作前的寶貴經驗。
這次實習的主要任務是了解整個軟件制作流程，以及各個環節的細節。學完這些環節，就可以用學到的知識去完成一個公司安排的項目。我分配的項目名稱是診所管理系統。我們將以小組的形式共同完成這個項目，模擬實際的軟件制作過程，最大限度地將學到的知識轉化為實踐能力。為真正的項目做好充分的準備，這樣實習后才能在正式工作中面對。
公司的最終目的是希望能了解實際的項目制作，初步了解各個環節的意義。讓我們將項目用于實際生產，這樣我們可以更好地理解項目生產中每個過程的意義，以及團隊在項目生產過程中是如何合作的。
我的實習單位是埃森哲信息技術（大連）有限公司軟件開發部，校企合作。該部門的主要職能是外包服務工作，根據客戶需求制作相應的軟件。因此，我們需要熟悉整個軟件開發過程，這樣才能處理客戶的各種問題，做出更好的軟件來滿足客戶的需求。
因為實習的原因，我的職位是軟件助理工程師。具體的時間安排是實際的項目制作和專業知識的學習。實習時間8周。本來實習的地方是在公司。后來因為公司內部原因，我們實習的地方改成了學校內部實習，每天的時間和正式工作一樣。上午8點和5點，每周六周日休息。
整個實習的實際過程前面已經講過了，包括八周的實際項目制作和專業知識學習。具體每周任務、實際工作內容、專業知識和技能的實際應用會根據不同環節而有所不同。但總體目標是讓我們了解實際工作中的軟件生產流程，以及每個流程需要的技術和注意點，讓我們用實際的項目去實踐。
整個實習的任務和目的上面已經介紹過了。下面將詳細介紹整個實習過程，并詳細講解每個過程的細節。
具體時間安排如下：
第一周：這個項目需要的知識將被集中整理和復習。鞏固一些不熟悉的知識，以防項目出現意外需求。實習的第一天，企業的經理向我們詳細解釋了軟件工程科學對軟件生產的重要性，并在此基礎上給了我們大致的實習過程。
第二周：直接進行項目的需求分析。因為已經給出了項目名稱，可行性分析就取消了。分配給我們小組的項目是“門診管理系統”，去診所實地調查是必然的。在實際調研過程中發現，需求分析的過程非常非常重要，需求分析文檔的制作決定了項目的各項功能以及軟件是否滿足用戶的需求。本周的收獲是軟件需求分析的文檔化，這是軟件工程中非常重要的一步，這個環節是整個軟件生成過程中最重要、最關鍵的一環。
第三周：這一周由于臨時變動，將概要設計和詳細設計合并成一周。根據調查結果，進行概要設計。因為是第一次制作軟件概要分析文檔，所以有很多不規范的地方，比如數據流圖的制作，很多小細節都忽略了，所以像這樣的問題還是很多的。但這些問題經過組員的積極討論和修改，以及老師的指導，都得到了解決。然后，根據概要設計，進行軟件的詳細設計。詳細設計相比于概要設計能感覺簡單一點，不知道感覺對不對。因為在概要設計模塊中，我們已經設計了需要實現的模塊、接口、類、函數，所以我們只需要考慮每個類的函數都可以用代碼來實現，而不是寫在代碼上，而是用流程圖、偽代碼等相關技術來表達。正式的編碼在這個階段生產完成時開始。到目前為止，準備工作終于完成了，差不多花了我們一半的實習時間。這一周的時間，我們不知不覺就在忙碌中度過了！下周我們將進入這個項目的實際編碼，這也是我們最熟悉的地方。感覺終于有地方投稿了，期待下周的到來。
第四周：根據詳細設計對項目進行編碼。本周，我們進行了實際的編碼。我最大的感受就是按照詳細設計的編碼很清晰，偽代碼等轉換過程可能有點困難。和我們過去直接編碼相比，流暢度不言而喻。
第五周：這周本來是要測試的，但是編碼后企業老師指出了很多問題，說我們寫的代碼太粗糙了，要小心處理代碼，把測試推到下周。這一周我們受益匪淺，對代碼標注和編碼格式有了更深入的了解。
第六周：根據完成的項目測試項目。這一周是軟件測試，分為幾個階段，從最基礎一節課內的方法測試到整個項目的綜合測試。與之前的測試不同，這次我們先寫測試文檔，待測試文檔通過檢驗后，再逐步測試文檔。我想，這可能是我們未來工作的大方向，基于文檔的項目制作。因為測試文檔的制作進度太慢，我們這周忙于測試文檔的制作，其他什么都沒做，所以測試只能等到下周。我希望下周的考試會很有效率。期待嘗試一下，感覺很想拿著測試文檔測試一下。
第七周：拿著測試文檔，按照上述要求逐一測試，確認項目的正確性。順利的考試讓我精神煥發。拿著測試文檔直接查代碼就行了。幾乎沒有必要考慮程序內部的測試流程，因為文檔已經為你寫得很清楚了。在這里，我有一種感覺，在埃森哲這樣的大公司，文檔的重要性比編碼本身更重要。我想這就是為什么企業派來的老師沒有直接給我們技術培訓，而是讓我們了解軟件工程的流程。當然，根據企業文化的不同，軟件工程的生命周期也會有細微的差異。他們會選擇最適合自己公司的方法進行整個軟件生命周期，而不是一成不變的。
第八周：這一周，我們沒有任何與技術相關的任務，只需要準備個人演示。但是不要小看這個人的發揮，因為他會占你整個實習成績的50%，這是本周一企業老師告訴我們的。我們之前都不知道有實習結果。項目總結，我們會花一個星期的時間總結整個實習的收獲，這個星期的周五呈現自己，匯報收獲。至此，實習生涯就告一段落。這一周，我們從收獲、總結、經驗等方面對整個實習的精髓進行了思考、沉淀、總結、提煉。基于ppt，我們進行了10分鐘的個人陳述和項目答辯。在這方面，我們的實習徹底結束了。
項目的制作和難題的解決，會讓我們熟悉大學即將遺忘的知識，對代碼有更深的理解。代碼的重用，類與類之間的調用，對象的創建，數據庫的連接以及各種專業知識的使用，讓我們能夠更好的將這些各種知識合理的整合在一起。
如果專業知識收獲很多，那么下面的專業技能就是整個實習過程中最大的收獲。我很少關注代碼的標注和編碼的規范，也沒有太多關注。但這一次，我意識到了他的重要性：這是一個軟件開發人員必須具備的能力，或者說應該特別注意的能力。因為我們的代碼沒有太多的注釋，很多地方的編碼很不規范，企業老師寧愿讓我們多花一周時間修改，也不急于下一次測試。在這一周的復習中，通過自己的經歷和老師的強調，對代碼編碼規范和代碼標注有了更深入的了解。通過這次實習，個人認為代碼標注和編碼規范比個人技能更重要。
這次實習的最終目的是希望能夠了解軟件生產的全過程，也就是軟件工程的科學。這次實習，中間做文檔的時間大概是編碼的幾倍，甚至因為我們的修改，編碼時間也只有兩周，而其他大部分時間都在做文檔。個人覺得進公司后，文檔制作比個人技能更重要。因為有了文檔，我們的項目制作非常流暢，規定非常明確，邏輯非常流暢。這些文檔在做軟件的過程中起著重要的作用，所以我覺得軟件工程可能是我未來的方向。
最后，總結一下這段時間實習的收獲，真的讓我受益匪淺。實習期間不僅學到了技術上的收獲，還學到了生活中的人際交往以及很多其他的經驗。這些都將作為我進入社會的基礎。我會以此為基礎，以一顆勇敢無畏的心迎接即將到來的工作。
動詞（verb的縮寫）實習經歷
這次實習給了我深刻的體會，不僅是專業上的收獲，還有團隊之間的合作，讓我明白了團隊的意義。工作快到了，期待工作的到來。我會努力把學到的知識運用到實際工作中，迎接一個又一個挑戰。前面的路上會有很多困難等著我，但我并不害怕，因為我堅信，只要我努力，我最終會克服這些困難。路就在我腳下，我會帶著堅定的信念前進，不怕挫折！
軟件工程實踐總結軟件工程專業實訓心得體會篇四
實踐時間：xx年7月1日-----xx年7月31日共31天
一、實踐目的：綜合利用所學的專業知識，培養軟件開發的技能;掌握android操作系統的編程技巧，體會企業軟件開發與學習過程中編寫軟件的不同;提高自身的創新意識與創新能力，促進團隊之間的溝通協作，為早日踏上工作崗位打下堅實基礎。
二、實踐內容及感悟：
a) 實踐前準備：自xx年清明節前后，我和我的組員就開始接受山西西太行信息有限公司的公開課的培訓，當時經電子與計算機技術學院于一老師介紹由陳川老師主要帶領我們重新溫習了一遍關于java語言的基本知識，在這將近一個月的學習過程中我們逐漸重新拾起了即將被遺忘的java 知識，走出了以前認識上的誤區，使我在java這一塊又有了一定的的優勢，為以后我們用java語言做開發打下了很好的基礎。
自xx年5月1日，我們開始了真正的基于android操作系統的軟件開發，雖然我們是利用課余時間進行學習，但是學習的效果真的很好，我們基本上晚上都會學到很晚才回宿舍。剛開始的時候我感到很不適應，感到學習的java語言不能夠充分的的到利用，只能夠用一些和系統相關的東西，但是隨著學習的深入，我發現android操作系統也是一個很強大的手機操作系統，它有著很好的發展前景。并且移動互聯網在在中國有著大的市場，所以我對我正在從事的android手機軟件開發給予了很大的希望。這一個月的培訓我們主要學習了android操作系統的五大系統組件：activity、service、sqlite、content provider、intent、broadcastrecever，同時我也學到了一些課堂上學不到得東西，對外面的市場的情況也有了更深刻的了解。
我們一行十六個人，大三的十一人大二的六人。我們被分了兩個小組，每個小組八個人，上課時間一般是下午兩點到五點半或者下午五點半到晚上八點半，其余的時間是我們自己寫代碼的時間。每天的任務量都有所不同，有時候把自己的任務做完了剩下的時間就自由支配。這一個月我們的主要任務是做一個騰訊微博android手機客戶端，每天陳老師都會給我們傳授一些做軟件的經驗和一些新的知識點,然后我們根據具體的要求編寫文檔,編寫代碼,第二天交由陳老師點評。
1) 可惡的文檔：剛開始的時候感覺很不適應，以前上課就是學習關于編程的知識，但是做項目的第一天陳老師要求我們寫文檔，我們用的是gb8568—88格式的文檔，第一次寫即感覺很枯燥又感覺不會寫。對于寫文檔我們都有想通的反應，就是莫名奇妙的反感，但是陳老師還是不依不饒的要求我們寫要我們查資料，我們也很沒辦法只能按照要求寫文檔。但是由于我們不知道在文檔上寫些什么，陳老師看我們很為難也有所讓步，帶領我們寫了軟件需求說明書，后來我們依次寫了概要設計說明書、詳細設計說明書，后來又寫了測試計劃、用戶手冊。當時的感覺就是知道的知識太少，對著文檔一個詞一個詞的硬擠，但是當文檔寫完的時候還是很有成就感的。
其實在寫文檔的過程中我們也漸漸的明白了文檔的重要性，我們只是
在學校編寫程序的時間久了習慣了上來就寫代碼的壞習慣，忽略了軟件工程中的很重要的部分-----分析階段和設計階段。可能是因為以前做的軟件都很小，一旦項目稍微大一點，那在編寫代碼階段將付出不可估量的代價甚至最終將以失敗告終。其實我們都學過軟件工程，而且在考試的時候成績還不是很差，但是到真正需要這些知識的時候我感覺卻忘記了如何下手，這也就是所謂的紙上談兵吧，所以我感覺大學生缺少的正是一種動手能力。知識本身沒有價值，有價值的是運用知識解決問題。
2) 該死的bug:寫完文檔感覺寫代碼就輕松了，但是事與愿違啊。由于以前沒做過開放平臺的客戶端，中間涉及到同騰訊公司微博開放平臺接洽的問題，開始真的很不適應，不知道怎么下手。當知道下手的時候不免出現了各種各樣的bug：騰訊服務器故障啦、實驗室斷網啦、模擬器連不上網啦、代碼錯誤啦等等。為了弄好這些bug有時真是忙的焦頭爛額，因為可能因為自己寫的代碼有問題導致大家的代碼都不能運行，作為團隊的一員誰都不想拖后腿。但有時候我也找不到問題所在，只能請高手指教或者找老師為我排憂解難。只可惜我當時掌握的排錯方式只有打印輸出和查看日志，根本沒接觸過單元測試。
其實多遇到一些bug還真不是壞事情，我現在開始明白編寫代碼最重要的是快速查找資料和排除錯誤的能力。首先我們不可能記住java語言或者android操作系統中所有的類和方法，所以能夠快速找到我們所需要功能的類或者方法是很重要的。其次對于程序工作者來說遇到bug是很正常的事情，遇到不能解決的問題也是很常見的，重要的是能夠正確的處理這些問題，并總結經驗為以后的開發做好鋪墊。遇到問題是要保持好的心態，千萬不能焦躁，細心的一點點的分析問題，必的時候可以去網絡上查找一些資料。但是不要遇到問題就上網查找，我感覺現在自己動手處理題很重要，上網查與吃現成飯沒有本質的區別。網絡可以幫我們開闊視野，但不要讓網絡阻礙了我們自我發展的機會。編寫軟件過程中要及時記錄，這既可以讓我們總結更多的經驗，也可以為后來者提供一些寶貴的資料。畢竟都有成長的時候。
3) 痛苦的合并：這是我第一次這么正式的和這么多的人一起開發軟件，更何況還有不認識的人在一個組，這給我們的溝通帶來了很大的不便，尤其是最后代碼合并的時候，很多的問題都一擁而上。我們當時用了一個軟件visualsvn，這是一款團隊開發的軟件，當代碼寫的可以組合的時候我們就用這個軟件在eclipse下共同開發。但開始的時候我們也會為了自己的代碼正確而被迫修改別人的代碼，最后弄得大家的代碼不能夠正確的運行，然后所有人都會停下來共同尋找錯誤，改正錯誤。這是團隊開發時候很忌諱的問題，并且大家還都不好意思開口說誰錯了，畢竟都不是很熟悉。直到大家開始慢慢適應這種團隊開發之后，這樣的情況才慢慢的被避免，效率也有所提高。
這次的團隊開發讓我明白，在團隊開發中根本不存在自我，你所做的任何事情都應從整個團隊出發，以團隊的利益為重，不能自私。尤其是在團隊中千萬不能應付，你的應付很可能會給他人帶來很多不便，甚至造成更大的損失。因此teamwork很重要，必須謹慎!
冗余度太大，有時候時代碼不夠安全，有時候是技術上不是很完善。對我們來說目標就是編寫的軟件能用，只要大家寫的軟件合并后能夠正常運行，一切就ok了。但是這些是遠遠不夠的，面向對象的思想和軟件工程的一些常識我們都沒涉及到，異步加載圖片在陳老師講之前我們也從來沒有想到過，這些問題讓我深深的體會到我們的創新能力的要求遠遠不夠，我們對完美的渴求度遠遠不夠。
沒有最好，只有更好。這句話真是非常經典，作為軟件開發者永遠沒有標準答案，沒有最好的軟件，只有不斷的學習不斷的追求才能發現好的東西，找到更好的創意。雖然最后騰訊微博客戶端能夠成功的運行了，但是我意識到我所掌握的知識遠遠不夠，在這個實踐中卻是暴露了很多的問題。但愿天天能做到更好!
三、實踐總結：
1、一個假期結束了，留下了很多的回憶，因為這個暑假是很有意義的。在這三十一天里每天都學到了新的知識，每天都遇到了新的問題，每天都在進步這，也讓我有時間更加清晰的認識了軟件工程這門課程和設計模式在軟件開發中的重要性，編寫代碼知識軟件開發的一小部分，只有真正的這種開發才能體會到軟件工程的意義。
2、團隊的凝聚力關系著每一個軟件開發人員的發展前途，每一個人的努力都會得到回報，同樣一個人的失誤也會影響到整個團隊，因此正確處理好人際關系是很重要的。
3、注重產品的價值，做好市場調研是成敗的決定性因素。4、掌握好一門技術你可以吃飽，但是你要想很富有，必須懂得很多。隊友可以幫助你一時幫不了一世，要注重個人能力發展!
軟件工程實踐總結軟件工程專業實訓心得體會篇五
綜合利用所學的專業知識，培養軟件開發的技能;掌握android操作系統的編程技巧，體會企業軟件開發與學習過程中編寫軟件的不同;提高自身的創新意識與創新能力，促進團隊之間的溝通協作，為早日踏上工作崗位打下堅實基礎。
a) 實踐前準備：
自xx年清明節前后，我和我的組員就開始接受山西西太行信息有限公司的公開課的培訓，當時經電子與計算機技術學院于一老師介紹由陳川老師主要帶領我們重新溫習了一遍關于java語言的基本知識，在這將近一個月的學習過程中我們逐漸重新拾起了即將被遺忘的java 知識，走出了以前認識上的誤區，使我在java這一塊又有了一定的的優勢，為以后我們用java語言做開發打下了很好的基礎。
自xx年5月1日，我們開始了真正的基于android操作系統的軟件開發，雖然我們是利用課余時間進行學習，但是學習的效果真的很好，我們基本上晚上都會學到很晚才回宿舍。剛開始的時候我感到很不適應，感到學習的java語言不能夠充分的的到利用，只能夠用一些和系統相關的東西，但是隨著學習的深入，我發現android操作系統也是一個很強大的手機操作系統，它有著很好的發展前景。
并且移動互聯網在在中國有著大的市場，所以我對我正在從事的android手機軟件開發給予了很大的希望。這一個月的培訓我們主要學習了android操作系統的五大系統組件：activity、service、sqlite、content provider、intent、broadcastrecever，同時我也學到了一些課堂上學不到得東西，對外面的市場的情況也有了更深刻的了解。
b) 實踐過程：
xx年7月1日到xx年7月31日是我正式暑假實踐的時間段，
我們一行十六個人，大三的十一人大二的六人。我們被分了兩個小組，每個小組八個人，上課時間一般是下午兩點到五點半或者下午五點半到晚上八點半，其余的時間是我們自己寫代碼的時間。每天的任務量都有所不同，有時候把自己的任務做完了剩下的時間就自由支配。這一個月我們的主要任務是做一個騰訊微博android手機客戶端，每天陳老師都會給我們傳授一些做軟件的經驗和一些新的知識點,然后我們根據具體的要求編寫文檔,編寫代碼,第二天交由陳老師點評。
1) 可惡的文檔：剛開始的時候感覺很不適應，以前上課就是學習關于編程的知識，但是做項目的第一天陳老師要求我們寫文檔，我們用的是gb8568—88格式的文檔，第一次寫即感覺很枯燥又感覺不會寫。對于寫文檔我們都有想通的反應，就是莫名奇妙的反感，但是陳老師還是不依不饒的要求我們寫要我們查資料，我們也很沒辦法只能按照要求寫文檔。但是由于我們不知道在文檔上寫些什么，陳老師看我們很為難也有所讓步，帶領我們寫了軟件需求說明書，后來我們依次寫了概要設計說明書、詳細設計說明書，后來又寫了測試計劃、用戶手冊。當時的感覺就是知道的知識太少，對著文檔一個詞一個詞的硬擠，但是當文檔寫完的時候還是很有成就感的。
其實在寫文檔的過程中我們也漸漸的明白了文檔的重要性，我們只是
在學校編寫程序的時間久了習慣了上來就寫代碼的壞習慣，忽略了軟件工程中的很重要的部分-----分析階段和設計階段。可能是因為以前做的軟件都很小，一旦項目稍微大一點，那在編寫代碼階段將付出不可估量的代價甚至最終將以失敗告終。其實我們都學過軟件工程，而且在考試的時候成績還不是很差，但是到真正需要這些知識的時候我感覺卻忘記了如何下手，這也就是所謂的紙上談兵吧，所以我感覺大學生缺少的正是一種動手能力。知識本身沒有價值，有價值的是運用知識解決問題。
2) 該死的bug:寫完文檔感覺寫代碼就輕松了，但是事與愿違啊。由于以前沒做過開放平臺的客戶端，中間涉及到同騰訊公司微博開放平臺接洽的問題，開始真的很不適應，不知道怎么下手。當知道下手的時候不免出現了各種各樣的bug：騰訊服務器故障啦、實驗室斷網啦、模擬器連不上網啦、代碼錯誤啦等等。為了弄好這些bug有時真是忙的焦頭爛額，因為可能因為自己寫的代碼有問題導致大家的代碼都不能運行，作為團隊的一員誰都不想拖后腿。但有時候我也找不到問題所在，只能請高手指教或者找老師為我排憂解難。只可惜我當時掌握的排錯方式只有打印輸出和查看日志，根本沒接觸過單元測試。
其實多遇到一些bug還真不是壞事情，我現在開始明白編寫代碼最重要的是快速查找資料和排除錯誤的能力。首先我們不可能記住java語言或者android操作系統中所有的類和方法，所以能夠快速找到我們所需要功能的類或者方法是很重要的。其次對于程序工作者來說遇到bug是很正常的事情，遇到不能解決的問題也是很常見的，重要的是能夠正確的處理這些問題，并總結經驗為以后的開發做好鋪墊。遇到問題是要保持好的心態，千萬不能焦躁，細心的一點點的分析問題，必的時候可以去網絡上查找一些資料。但是不要遇到問題就上網查找，我感覺現在自己動手處理題很重要，上網查與吃現成飯沒有本質的區別。網絡可以幫我們開闊視野，但不要讓網絡阻礙了我們自我發展的機會。編寫軟件過程中要及時記錄，這既可以讓我們總結更多的經驗，也可以為后來者提供一些寶貴的資料。畢竟都有成長的時候。
3) 痛苦的合并：這是我第一次這么正式的和這么多的人一起開發軟件，更何況還有不認識的人在一個組，這給我們的溝通帶來了很大的不便，尤其是最后代碼合并的時候，很多的問題都一擁而上。我們當時用了一個軟件visualsvn，這是一款團隊開發的軟件，當代碼寫的可以組合的時候我們就用這個軟件在eclipse下共同開發。
但開始的時候我們也會為了自己的代碼正確而被迫修改別人的代碼，最后弄得大家的代碼不能夠正確的運行，然后所有人都會停下來共同尋找錯誤，改正錯誤。這是團隊開發時候很忌諱的問題，并且大家還都不好意思開口說誰錯了，畢竟都不是很熟悉。直到大家開始慢慢適應這種團隊開發之后，這樣的情況才慢慢的被避免，效率也有所提高。
這次的團隊開發讓我明白，在團隊開發中根本不存在自我，你所做的任何事情都應從整個團隊出發，以團隊的利益為重，不能自私。尤其是在團隊中千萬不能應付，你的應付很可能會給他人帶來很多不便，甚至造成更大的損失。因此teamwork很重要，必須謹慎!
冗余度太大，有時候時代碼不夠安全，有時候是技術上不是很完善。對我們來說目標就是編寫的軟件能用，只要大家寫的軟件合并后能夠正常運行，一切就ok了。但是這些是遠遠不夠的，面向對象的思想和軟件工程的一些常識我們都沒涉及到，異步加載圖片在陳老師講之前我們也從來沒有想到過，這些問題讓我深深的體會到我們的創新能力的要求遠遠不夠，我們對完美的渴求度遠遠不夠。
沒有最好，只有更好。這句話真是非常經典，作為軟件開發者永遠沒有標準答案，沒有最好的軟件，只有不斷的學習不斷的追求才能發現好的東西，找到更好的創意。雖然最后騰訊微博客戶端能夠成功的運行了，但是我意識到我所掌握的知識遠遠不夠，在這個實踐中卻是暴露了很多的問題。但愿天天能做到更好!
1、一個假期結束了，留下了很多的回憶，因為這個暑假是很有意義的。在這三十一天里每天都學到了新的知識，每天都遇到了新的問題，每天都在進步這，也讓我有時間更加清晰的認識了軟件工程這門課程和設計模式在軟件開發中的重要性，編寫代碼知識軟件開發的一小部分，只有真正的這種開發才能體會到軟件工程的意義。
2、團隊的凝聚力關系著每一個軟件開發人員的發展前途，每一個人的努力都會得到回報，同樣一個人的失誤也會影響到整個團隊，因此正確處理好人際關系是很重要的。
3、注重產品的價值，做好市場調研是成敗的決定性因素。4、掌握好一門技術你可以吃飽，但是你要想很富有，必須懂得很多。隊友可以幫助你一時幫不了一世，要注重個人能力發展!
軟件工程實踐總結軟件工程專業實訓心得體會篇六
; 《軟件工程實踐》報告 ——機票預定系統 院系：
專業班級：
報告人：
指導教師：
實驗地點：
完成起止日期：
學號 姓名 角色 成績 組長 完成工作 主要：寫論文、資料整合、概要設計、指導畫圖、編碼調試。
參與：討論、可行性分析、測試、作圖 評語 組員 完成工作 主要：經濟可行性分析、用例分析、詳細設計作圖、編碼調試、實行測試和運行。
參與：討論、收集資料 評語 組員 完成工作 主要：收集資料、需求分析作圖、詳細設計作圖、測試作表 參與：討論、可行性分析、概要設計、 評語 目錄 第一章 可行性分析 5 1.1引言 5 1.1.1 編寫目的 5 1.1.2 項目背景 5 1.2可行性研究的前提 6 1.2.1要求 6 1.2.2目標 6 1.2.3條件，假定和限制 6 1.2.4決定可行性的主要因素 6 1.3技術可行性分析 6 1.3.1系統簡要描述 6 1.3.2處理流程和數據流程 7 1.4經濟可行性分析 7 1.4.1支出 7 1.4.2效益 7 1.4.3 收益/投資比 8 1.4.4投資回收周期 8 1.4.5敏感性分析 8 1.5法律因素 8 1.6其他可供選擇的方案 8 1.7結論意見 8 第二章需求分析 9 2.1求規格說明 9 2.1.1系統概貌 9 2.1.2功能需求 9 2.1.3性能需求 9 2.1.4運行需求 10 2.2數據流圖分析 10 2.2.1數據流圖 10 2.2.2數據描述? 11 2.2.3數據詞典? 11 2.3用例分析 12 2.3.1系統基本用例 12 2.3.2 用況描述 13 2.3.3系統業務邏輯描述 15 第三章 概要設計 16 3.1系統的結構化設計 16 3.1.1軟件體系結構圖 16 3.1.2軟件結構流程圖? 17 第四章 詳細設計 19 4.1 機票預訂管理系統體系結構設計 19 4.1.1面向旅客的界面包的類圖 20 4.1.2面向管理員的界面包的類圖 21 4.1.3機票預訂系統的體系結構圖 22 4.1.4機票預訂系統的體系結構圖描述 23 4.2 機票預訂管理系統子系統設計 23 4.2.1用戶查詢航班及機票信息 23 4.2.2旅客訂票及退票 24 4.2.3機票預訂系統統計分析 26 4.3數據庫結構設計 26 4.4數據庫表創建? 27 第五章測試 29 5.1定義 29 5.2主界面模塊 29 5.2.1用戶注冊 29 5.2.2用戶登錄 31 5.2.3管理員登錄 33 5.3查詢機票模塊 35 5.4 航班管理模塊 37 5.5用戶訂票模塊 39 第六章 結束語 42 第一章 可行性分析 1.1引言 隨著社會發展的不斷進步，航空事業不斷壯大，人們生活水平不斷提高，乘坐飛機的人也越來越多，隨著消費者的不斷增多，飛機預訂系統在各地預訂網點作用也愈顯重要。目前，我國還有相當一部分地區酒店的機票預訂還未進入智能處理階段，和發達地區比較工作效率較低。在計算機技術快速發展的今天，有必要引進高效的計算機系統來協助機票預訂工作。因此開發一套具有完整的存儲，查詢，核對，打印機票功能的實時機票預訂系統勢在必行。機票預定系統應克服存儲乘客信息少，查詢效率低下等問題外，更重要的是其安全性，可靠性，這關系到航班和乘客的安全及準確，本系統因面向廣大機票預定網點，因此要能在售票網點中普及，則需要開發一個功能全，價格能被顧客所接受的系統。? 機票預訂系統是為了機場工作人員和客戶提供訂票退票等與機票相關內容和管理的系統，它具有開放的系統結構，易擴充的，易維護的，具有良好人機界面的優點。它克服了存儲客戶信息少，查詢效率低等問題，更重要的是其安全性，可靠性，實現航空公司的機票銷售的自動化，為乘客出行提供方便，便于機場人員信息管理，提高了機場人員對機票管理的工作效率。
1.1.1 編寫目的 可行性研究的目的是為了對問題進行研究，以最小的代價在最短的時間內確定問題是否可解。
經過對此項目進行詳細調查研究，初擬系統實現報告，對軟件開發中將要面臨的問題及其解決方案進行初步設計及合理安排。明確開發風險及其所帶來的經濟效益。本報告經審核后，交軟件經理審查。
1.1.2 項目背景 開發軟件名稱：機票預訂系統。
項目任務提出者：航空公司及旅游開發公司。
項目開發者：
a++開發小組。
用戶：航空公司及旅游開發公司。
實現軟件單位：旅游開發公司及廈門理工學院 項目與其他軟件，系統的關系：
本項目采用客戶機/服務器原理，客戶端的程序是建立在windows xp 系統上以microsoft visual c++為開發軟件的應用程序。
1.2可行性研究的前提 1.2.1要求 主要功能：為游客提供機票預定服務，方便旅游局的售票工作，提高旅游局的服務質量和服務效率 。
性能要求：機場提供的信息必須及時的反映在旅游局的工作平臺上。售票系統的定單必須無差錯的存儲在機場的主服務器上。對服務器上的數據必須進行及時正確的刷新。
輸出要求：數據完整，詳實。
輸出要求：簡捷，快速，實時。
安全與保密要求：服務器的管理員享有對機場航班信息庫及機票信息庫和定票信息庫的管理與修改。售票員只享有對訂票信息庫的部分修改（寫入與讀出）。
完成期限：預計兩個月。
1.2.2目標 系統實現后，大大提高旅游局的機票預定服務效率。降低售票服務中的錯誤發生率，減少信息交流的煩瑣過程及其帶來的開銷。
1.2.3條件，假定和限制 建議軟件壽命：5 年。
經費來源：中國國際旅游開發公司。
硬件條件：終端為pc 機。
運行環境：windosxp 1.2.4決定可行性的主要因素 成本/效益分析結果，效益 成本。
技術可行，現有技術可完全承擔開發任務。
操作可行，軟件能被原有工作人員快速接受。
1.3技術可行性分析 1.3.1系統簡要描述 在旅游局中的終端是安裝了windows xp的pc機，主要目的是向機場的服務器傳遞數據。當顧客在旅游局進行咨詢時，終端向服務器發出查詢請求，服務器根據航班信息庫的實時數據，向終端發送數據，顯示在終端的屏幕上。當顧客向售票員定票時，終端向服務 器發出詳盡的一份定單，服務器核對后，存入定票信息庫，并修改機票信息庫。當顧客再次 來取票時，終端向服務器發出查詢定票請求，服務器接收后，查詢定票信息庫，核對后，傳送機票確認表單，終端打印出機票。
1.3.2處理流程和數據流程 圖1－1 數據流程圖 1.4經濟可行性分析 1.4.1支出 基礎投資：
終端pc 機5臺：6000*5 = 3 萬 網絡設備和輔助配置：4 萬 共計：7萬 其他一次性投資：
mysql : 0元 windows xp: 2 萬 操作員培訓費：3萬 共計：5 萬 經費：
人工費用: 2(月)*5(人)*4000(元)=4 萬 其他不可知額外支出: 4 萬 共計: 8萬 支出共計:20 萬 1.4.2效益 一次性收益 0元 經常性收益 （按銀行利率：1%）；
減少員工5 人(100 元/人)五年收益: 100*（1/1.01+1/(1.01)2+1/(1.01)3+1/(1.01)4+1/(1.01)5）*5*12*5=170000 工作效率提高收益（工作效率提高20%）: 20000*（1/1.01+1/(1.01)2+1/(1.01)3+1/(1.01)4+1/(1.01)5）*（20%）*5 = 117000 經常性收益共計:28.7萬 不可定量收益 因服務質量提高增加收益：3000*12*5＝180000 收益共計: 46.7萬 1.4.3 收益/投資比 46.7 萬/20 萬=233.5% 1.4.4投資回收周期 2.54年 1.4.5敏感性分析 設計系統周期為五年, 估計最長可達7 年 處理速度: 一般查詢速度4 秒 關鍵數據查詢速度: 2 秒 1.5法律因素 所有軟件都選用正版；
所有技術資料都由提出方保管；
合同制定確定違約責任。
1.6其他可供選擇的方案 端與服務器端聯系在一起，在旅游局中只設立終端，在機場設立服務器，數據輸入由終端輸入，所有數據都由服務器處理，只在終端上顯示數據結果。此設計簡化了數據處理，但加重了服務器的數據處理。而使用客戶端/服務器機理， 簡化數據流量，加快數據處理。
1.7結論意見 由于投資效益比遠大于100%, 技術、經濟、操作都有可行性，可以進行開發。
第二章需求分析 2.1求規格說明 2.1.1系統概貌 航空公司為方便旅客，需開發一個機票預定系統。為便于旅客由旅行社代替航空公司負責為旅客定票，旅行社把預定機票的旅客信息，包括姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地，輸入機票預定系統的客戶端程序，系統經過查詢航空公司內的航班數據服務器后，為旅客安排航班，印出取票通知。旅客在飛機起飛前一天憑取票通知和賬單交款后取票，系統校對無誤后即印出機票給旅客。
2.1.2功能需求 1. 航空公司工作人員登錄及注銷? ?? 要求合法的管理員才可以登錄系統，防止系統被無關人員動用，使用字符串匹配對 用戶名和密碼進行判斷。在不使用時進行注銷，下次使用時需要重新登陸，由于目標客戶 的層次較低，建議用輸入檢測確保輸入準確無誤。??? 2. 機票信息輸入和查詢? ?? 在系統中，要求可以輸入每日航班次數。可以通過航班號、目的地、起飛日期、起飛地點查詢航班，輸出該次航班的起飛時間和所剩票數和票的價格等信息。?? 3. 訂票，取票和退票? ?? 把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼（護照號碼）、旅行時間、旅行始發地和目的地，航班艙位要求等）輸入到系統中，系統為旅客安排航班。當旅客交付了預訂金后，系統打印出取票通知和帳單給旅客。，旅客在飛機起飛前一天憑取票通知和帳單交款取票，系統對旅客有關證件合法性（如身份證、取票通知和交款發票）等進行驗證，系統核對無誤即打印出機票給旅客。對于已取機票應在未售出機票中減去。對于以下情況要求退票者，給予50%金額退款：（1）旅客延誤取票時間；
（2）旅客臨時更改航班處理；
（3）因私人原因需要退票。對于因特殊情況下（如天氣不適合飛機起降、飛機延誤超過30分鐘）等給予全額退票。對于退訂機票要在未售出機票中重新體現。
2.1.3性能需求 為了保證系統能夠長期、安全、穩定、可靠、高效的運行，機票預訂系統應該滿足以下的性能需求：? 1. 系統處理的準確性和及時性? 系統處理的準確性和及時性是系統的必要性能。在系統設計和開發過程中，要充分考慮系統當前和將來可能承受的工作量，使系統的處理能力和響應時間能夠滿足企 業對信息處理的需求。在系統開發過程中，必須采用一定的方法保證系統的準確性。? 2. 系統的開放性和系統的可擴充性? 機票預訂系統在開發過程中，應該充分考慮以后的可擴充性。要實現這一點，應通過系統的開放性來完成，即系統應是一個開放系統，只要符合一定的規范，可以簡單的加入和減少系統的模塊，配置系統的硬件。通過軟件的修補、替換完成系統的升級和更新換代。? 3.系統的易用性和易維護性? 機票預訂系統是直接面對使用人員的，而使用人員往往對計算機并不時非常熟悉。這就要求系統能夠提供良好的用戶接口，易用的人機交互界面。
4.系統的標準性? 系統在設計開發使用過程中都要涉及到很多計算機硬件、軟件。所有這些都要符合主流國際、國家和行業標準。同時，在自主開發本系統時，要進行良好的設計工作，制訂行之有效的軟件工程規范，保證代碼的易讀性、可操作性和可移植性。? 5.系統的先進性? 目前計算機系統的技術發展相當快，做為機票預訂系統工程，應該保證系統在一段時間內是先進的，在系統的生命周期盡量做到系統的先進，充分完成企業信息處理的要求而不至于落后。這一方面通過系統的開放性和可擴充性，不斷改善系統的功能完成。另一方面，在系統設計和開發的過程中，應在考慮成本的基礎上盡量采用當前主流并先進且有良好發展前途的產品。? 2.1.4運行需求 系統軟件：windows?xp 數據庫管理系統：mysql?? 硬件要求：奔四?1.6ghz????512m?ram???10g?hd 2.2數據流圖分析 2.2.1數據流圖 圖2－1本系統的頂層數據流圖 圖2－2 0層數據流圖 圖2－3 本系統的二層數據流圖 2.2.2數據描述? 1.靜態數據?：訂票單、取票通知單、帳單、機票 2.動態數據?：旅客姓名、身份證、航班時間 2.2.3數據詞典? 1.旅客信息? 名字：旅客信息? 別名：passenger?information? 描述：旅客的個人信息，用于對旅客的確認? 定義：旅客信息=姓名+性別+工作單位+身份證號碼+旅行時間+旅行目的地? 位置：輸入到旅行社端（client端）
2.訂票旅客清單? 名字：訂票旅客清單? 別名：list? 描述：已訂票的旅客的記錄? 定義：訂票旅客清單=旅客信息的合集? 位置：輸入到旅行社端（client端）
3.訂票信息? 名字：訂票信息? 別名：booked?information? 描述：旅客的旅行時間和目的地，用于確定旅客的航班? 定義：訂票信息=旅客旅行時間+旅客旅行目的地? 位置：傳輸到航空公司端（server端）
4.航班機票信息? 名字：航班機票信息 別名：bill?information? 描述：旅客的航班信息，根據旅客的旅行時間和目的地確定? 定義：航班機票信息=旅客機票時間+旅客機票班次? 位置：傳輸到旅行社端（client端）? 5.取票通知? 名字：取票通知? 別名：?notification? 描述：旅客領取機票的憑證? 定義：取票通知=旅客姓名+領票時間 位置：輸出到打印機? 6.售出機票信息? 名字：售出機票信息? 別名：saled? 描述：旅客的航班機票的信息? 定義：售出機票信息=旅客的航班機票? 位置：輸出到打印機? 7.旅客訂票記錄? 名字：旅客訂票記錄 別名：record? 描述：已訂票的旅客在航空公司的記錄? 定義：旅客訂票記錄=旅客姓名+航班機票信息? 位置：輸出到航空公司端（server端）
2.3用例分析 2.3.1系統基本用例 本系統的邊界是：機票預定系統服務平臺。
系統的參與者有：航空公司管理員、旅行設、旅客。用例圖如下：
圖2－4 系統用例圖 1.航空公司管理員通過系統實現以下使用需求：
登錄、預訂機票、退訂機票、取票管理、航班查詢、 航班信息管理、訂票信息管理、旅客信息管理 2.旅客通過系統實現以下使用需求：
登錄、預訂機票、退訂機票、航班查詢 3.旅行社通過系統實現以下使用需求：
航班查詢、旅客信息管理 2.3.2 用況描述 1.用例名：登錄。
主要執行者：旅客。
目標：可以查詢和修改旅客的基本信息。
范圍：機票預訂系統。
基本互交動作：
1）.旅客登錄。
2）.旅客輸入姓名、證件類型、證件號碼及電子郵件地址。
2.用例名：預訂機票。
主要執行者：旅客。
目標：預訂機票。
范圍：機票預訂管理系統 基本互交動作：
1）.旅客查詢航班及機票 2）.旅客選取信息表中的一個航班，輸入姓名、證件及號碼。
3）.顯示總票款。
4）.旅客確認預訂信息、總票款。
3.用例名：退訂機票。
主要執行者：旅客。
目標：取消此前預訂的機票。
范圍：機票預訂系統。
基本互交動作：
1）.用戶登錄。
2）.系統顯示旅客此前預訂但并未登機的機票；
旅客選取欲退訂的機票。
3）.系統按照退票費計算規則計算退票費，顯示欲退訂機票的總票款及總退費。
4）.旅客確認退票請求、總票款。
4.用例名：查詢航班。
主要執行者：旅客及旅行社。
次要執行者：航空公司。
目標：查詢航班時刻表、機票等信息。
范圍：機票預訂管理系統。
基本互交動作：
1）.用戶登錄。
2).用戶輸入出發地、目的地、出發日期、起飛或者到達時間的范圍。
3).系統從航空公司的機票管理系統中獲取航班及機票信息，顯示符合旅客要求的 所有航班及剩余機票數量。
5.用例名：航班信息管理 主要執行者：航空公司。
目標：提供最新的航班信息。
范圍：機票預訂系統。
基本互交動作：
1).更新航班信息（每5秒）。
2).提供航班信息。
6.用例名：取票管理 主要執行者：航空公司。
目標：及時通知旅客取票時間及方式。
范圍：機票預訂系統。
基本互交動作：
1).獲取已定機票信息并打印機票。
2).通知旅客取票的時間及方式。
7.用例名：旅客信息管理 主要執行者：航空公司、旅行社。
目標：儲存旅客信息。
范圍：機票預訂系統。
基本互交動作：
1).對旅客填寫的個人信息進行保存以便于管理。
2).定時更新旅客的信息。
8.用例名：報表及分析。
主要執行者：定時器（每周一00:00）
次要執行者：管理員。
目標：匯總前一周的訂票、退票情況。
范圍：機票預訂系統。
基本互交動作：
1).系統匯總自上次生成周報表至此刻發生的所有訂票、退票情況。
2.3.3系統業務邏輯描述 本系統的業務邏輯是這樣的：旅客登錄系統，使用客戶端進行訂 票、查詢、退票的操作，旅行社通過查詢和旅客信息管理與航空 公司進行數據交流與業務往來。
第三章 概要設計 3.1系統的結構化設計 3.1.1軟件體系結構圖 圖3－1 系統的軟件體系結構圖 1.旅客用戶模塊：本模塊主要功能，是旅客可登錄系統進行機票信息查詢，并根據需求預訂機票，在支付預定金后系統打印取票清單。
2.航空公司模塊：該模塊主要功能，是對航班及機票信息進行管理更新，并根據用戶提供的取票清單和付款單進行驗證和打印機票。
3.系統管理員模塊：本模塊主要功能，是管理員對系統的軟硬件進行維護，并對航空公司產生的業務進行編制報表和分析。
4. 旅行社模塊：本模塊主要功能，是旅行社可登錄系統進行機票信息查詢和管理旅客信息。
3.1.2軟件結構流程圖? 圖3－2 軟件結構流程圖 1.各功能詳細描述? 本系統主要用于機票預訂，所以提供了以下幾個子功能：機票預訂，取票通知，查詢航班，查詢機票，退票，打印機票，取消航班，機票的生成，以及航班的查詢等后臺功能。? 1).機票預訂功能：旅行社和機場管理員有權力進行該項功能。首先通過查詢得到旅客所需的航班，確定該航班還有沒有被預訂的座位，然后選擇座位的等級，填寫旅客的詳細信息之后就可進行網上預訂機票。? 2).票通知：該項功能只有旅行社和機場管理員有權力進行操作，在機票預訂功能成功完成之后，系統會自動給瀏覽器端發送一條取票信息以及所需繳納的費用。旅行社可以利用特定設備將該取票信息打印出來，這就是取票通知。? 3).查詢航班：可以通過輸入出發地，目的地，日期和時間選定自己航班。? 4).查詢機票：該項功能三方都可以操作，可以通過自己的身份證號以及取票通知上的機票號查詢自己的機票信息。? 5).退訂機票：該功能只有旅行社和機場管理員有權力操作，利用身份證號和對應的機票號就可以查詢到機票信息，然后就可以退訂機票。? 6).打印機票：該功能只有機場管理員有權力操作，只有當管理員確認旅客已經付款后才予以打印機票，可以通過身份證號和對應的取票信息上的機票號查詢機票信息，然后服務器返回機票信息，管理員就可以打印該機票信息，交給旅客。? 7).后臺的取消航班：該項功能只有機場管理員才能操作，先通過航班號和航班日期查詢到航班信息后，取消航班就可以將該航班從數據庫中刪除。? 8).后臺的航班查詢：該項功能只有機場管理員才能操作，通過航班號和航班日期查詢到航班信息。? 9).后臺的機票生成：該項功能只有機場管理員才能操作，可以通過該項功能給剛添加的航班生成對應的飛機票號紀錄。? 第四章 詳細設計 4.1 機票預訂管理系統體系結構設計 本系統包圖主要包括：用戶界面包、航空公司業務邏輯包及與外部系統的接口。其中業務邏輯中還包含訂票及退票包、客戶管理包、統計分析包。
圖4－1 機票預定管理系統之包圖 4.1.1面向旅客的界面包的類圖 圖4－2 面向旅客的界面包的類圖 4.1.2面向管理員的界面包的類圖 圖4－3 面向管理員的界面包的類圖 4.1.3機票預訂系統的體系結構圖 圖4－4機票預訂系統的體系結構圖 4.1.4機票預訂系統的體系結構圖描述 1.在ticketservice構件的對外接口中，quertflights負責查詢航班及尚余機票booktickets和returntickets分別負責訂票和退票，通過ticketsaleagent向航空公司的機票銷售管理系統發出訂票和退票請求，通過datapersistenceserviceinterface在數據庫中記錄客戶的訂票和退票情況。querysaletickets和queryreturntickets負責查詢客戶的訂票和退票情況。
2.在customermanager構件的對外接口中，register和unregister分別負責客戶信息的記錄和注銷。getcustomerinfo和setcustomerinfo分別負責獲取和修改客戶信息。
3.在statandanalyser子系統的對外接口中，statsaledtickets和statreturntickets借助于ticketserviceinterface中的querysaletickets和queryreturntickets分別統計在某一時段售票和退票的情況。
4.2 機票預訂管理系統子系統設計 4.2.1用戶查詢航班及機票信息 圖4－5 機票預定系統之查詢航班及機票信息類圖 圖4－6 查詢航班及機票用例順序圖 4.2.2旅客訂票及退票 圖4－7機票預訂管理系統之“訂票及退票”包的類圖 圖4－8 訂票用例順序圖 圖4－9 退票用例順序圖 4.2.3機票預訂系統統計分析 圖4－10 機票預訂系統之統計分析包的類圖 圖4－11 生成統計分析報表的順序圖 4.3數據庫結構設計 根據總的結構圖設計各表結構如下：
表4－1 旅客信息表 表4－2航班信息表 表4－3機票信息表 4.4數據庫表創建? create?table?旅客信息表? ( 姓名?char(50)?not?null?primary?key,?? ? 性別?char(50)?not?null,? 年齡?int?not?null,? 用戶密碼char(50)?not?null,? 證件號?int?notnull) create?table?航班信息表? ( 航班號?int?not?null,??primary?key,? 出發時間?char(30)?not?null,?? 出發地?char(20)?not?null,?? 目的地?char(20)?not?null， 票數?int?not?null, 票價?int?not?null）
create?table?機票信息表? ( 姓名?varchar(50)?not?null?primary?key,?? 座位號int?not?null, 航班號?int?not?null, 登機口?int?not?null,?? 票價?int?not?null,? ? 時間?char(30)?not?null,? 出發地?char char(50)not?null,? 目的地 char(50)not?null）? 第五章測試 5.1定義 黑盒測試：
黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測 試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關系出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
白盒測試：
白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。
這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。
5.2主界面模塊 主界面與注冊界面和登錄界面（航空公司管理員登錄、用戶登錄）。
通過主界面可以進入注冊界面和登錄界面，由登錄界面分別進入航空公司管理系統和用戶預訂機票系統。
5.2.1用戶注冊 1.輸入項 表5－1 測試用戶注冊輸入項 字段名稱 數據類型 長度 允許空 字段描述 name char 50 否 用戶真實姓名 sex char 50 否 用戶性別 age int 35 否 用戶年齡 password char 50 否 用戶密碼 credential int 35 否 用戶身份證號 2.輸出項 1顯示注冊成功，按任意鍵返回主頁；
2提示該身份證號已注冊，重新輸入。
3.算法 點擊主界面2入口中的一個，可進入相應的注冊界面。
內部處理 if 用戶身份證號注冊過， 提示錯誤信息: 該身份證號已注冊，請重新輸入！ else 顯示注冊成功，按任意鍵返回主頁。
4.流程邏輯 圖5－1 用戶注冊流程邏輯圖 5.編碼和界面 圖5－2 用戶注冊界面 圖5－3 用戶注冊錯誤測試結果 6.測試用例 對輸入參數查驗，檢測數據庫數據異常時能否判斷并給予適當處理。
表5－2用戶注冊測試用例 測試用例 預期結果 錯誤的身份證號 提示：身份證已注冊 正確的用戶信息 提示：注冊成功 5.2.2用戶登錄 1.輸入項 表5－3 測試用戶登錄輸入項 字段名稱 數據類型 長度 允許空 字段描述 username char 50 否 用戶真實姓名 password char 30 否 登錄密碼 2.輸出項 1顯示登陸成功，按任意鍵進入機票預訂系統；
2提示用戶或密碼錯誤，重新輸入請按y,退出請按n。
3.算法 點擊主界面2入口中的一個，可進入相應的登錄界面。在用戶 登錄界面輸入用戶名與密碼，點擊確定按鈕：
內部處理 if 用戶名或密碼不正確 提示錯誤信息: 用戶或密碼錯誤，請重新輸入！ else 登陸成功并轉入相應頁面 點擊0確認：返回主界面。
4.流程邏輯 圖5－4 用戶登錄流程邏輯圖 5.編碼和界面 圖5－5 登錄界面 圖5－6 用戶登錄成功 圖5－7 用戶登錄錯誤測試 6.測試用例 對輸入參數查驗，檢測數據庫數據異常時能否判斷并給予適當處理。
表5－4 用戶登錄測試用例 測試用例 預期結果 錯誤的用戶名 提示：用戶名錯誤 錯誤的密碼 提示：密碼錯誤 正確的用戶名、密碼 提示：登陸成功進入機票預訂系統 5.2.3管理員登錄 1.輸入項 表5－5 管理員登錄測試輸入項 字段名稱 數據類型 長度 允許空 字段描述 manager char 50 否 管理員姓名 password char 30 否 登錄密碼 2.輸出項 1顯示登陸成功，按任意鍵進入機票調整系統；
2提示姓名或密碼錯誤，重新輸入請按y,退出請按n。
3.算法 點擊主界面2入口中的一個，可進入相應的登錄界面。在管理者 登錄界面輸入姓名與密碼，點擊確定按鈕：
內部處理 if 姓名或密碼不正確 提示錯誤信息: 用戶或密碼錯誤，請重新輸入！ else 登陸成功并轉入相應頁面 點擊0確認：返回主界面。
4.流程邏輯 圖5－8 管理員登錄流程邏輯圖 5.編碼和界面 圖5－9 管理員登錄成功 圖5－10 管理員登錄錯誤測試結果 6.測試用例 對輸入參數查驗，檢測數據庫數據異常時能否判斷并給予適當處理。
表5－6管理員登錄測試用例 測試用例 預期結果 錯誤的姓名 提示：姓名錯誤 錯誤的密碼 提示：密碼錯誤 正確的姓名、密碼 提示：登陸成功進入機票調整系統 5.3查詢機票模塊 用戶或管理員進入查詢機票界面，可以通過查找航班信息來選擇自己要乘坐的航班。
1. 輸人項 表5－7 查詢機票測試輸入項 字段名稱 數據類型 長度 默認值 允許為空 字段描述 flight_num string 是 飛機班次 2. 輸出項 表5－8 查詢機票測試輸出項 字段名稱 數據類型 長度 默認值 允許為空 字段描述 flight_num string 是 飛機班次 origion string 是 旅行始發地 destination string 是 旅行目的地 leave_time string 是 旅行初始時間 3.算法 顯示查詢界面 case1 航班號 輸入查詢的航班號；
break; 根據所輸出的內容，連接數據庫開始搜索 if 找到符合條件的機票 顯示輸出 else 沒有找到符合要求的機票 4.流程邏輯 選擇航班號 查詢 檢索數據庫 顯示結果 y n 圖5－11查詢機票流程邏輯圖 5.編碼和界面 圖5－12 查詢機票錯誤測試結果 圖5－13 查詢機票成功 6.測試計劃 輸入數據：輸入參數合法，數據庫出現異常的處理。數據的共享與獨立性，一致性與完整性。
7. 測試用例 表5－9 查詢機票測試用例 測試用例 預期結果 輸入合法參數 顯示正確的航班信息 輸入非法參數 數據庫出現異常處理結果 （違背數據的一致性或者完整性）
5.4 航班管理模塊 航空公司管理員登錄成功后進入航空公司管理系統， 添加航班。
1. 輸人項 表5－10 航班管理測試輸入項 字段名稱 數據類型 長度 默認值 是否允許空 字段描述 flight_num string 否 飛機班次 price int 4 否 機票價格 leave_time datatime 否 發機時間 cout int 否 票數 origin string 否 始發地 destination string 否 目的地 2.輸出項 1).成功轉入相應頁面；
2).提示輸入錯誤，重新輸入。
3.算法 進入航班管理信息界面，可返回主界面。
選擇航班管理信息界面的添加航班界面以及返回主界面。
添加航班：
依次輸入數據 if 輸入數據格式錯誤或內容不對 提示錯誤，重新輸入 else 將數據存入數據庫 提示添加成功 返回航班管理信息界面 在管理員登錄系統 4.流程邏輯 選擇航班管理操作 添加航班信息 n 填寫信息正確 成功添加航班 返回 圖5－14添加航班流程邏輯圖 5.編碼和界面 圖5－15 航班添加界面 圖5－16 添加成功界面 6.測試用例 表5－11 航班添加測試用例 測試用例 預期結果 重復輸入的航班信息 提示：該航班已存在，重新輸入 正確的航班信息 提示：是否繼續添加 5.5用戶訂票模塊 用戶登錄成功后進入航空公司管理系統，選擇瀏覽航班后進入訂票系統。
1. 輸人項 表5－12 訂票測試輸入項 字段名稱 數據類型 長度 默認值 是否允許空 字段描述 flight_num string 否 飛機班次 cout int 否 票數 2.輸出項 1).航班信息，開始訂票及訂票成功；
2).沒有您要的航班信息，余票不足，請出入有效票數。
3.算法 進入航班管理信息界面，可返回主界面。
選擇航班管理信息界面的訂票界面以及返回主界面。
訂機票：
輸入數據 if 輸入數據不對 提示錯誤，重新輸入 else 顯示航班信息 繼續查找or開始訂票 if 輸入票數有誤 提示錯誤，重新輸入 else 顯示訂票成功 航班管理信息界面 4.流程邏輯 選擇訂票操作 查詢航班信息 n 顯示航班信息 開始訂票 輸入訂票數 n 輸入票數正確 訂票成功 返回 圖5－17訂票流程邏輯圖 5.編碼和界面 圖5－18 訂票錯誤測試結果 圖5－19 訂票成功結果 6.測試用例 表5－13 訂票測試用例 測試用例 預期結果 輸入錯誤的航班號 提示：該航班不存在，重新輸入 正確的航班號 提示：是否繼續查找或開始訂票 錯誤的機票數 提示：余票不足，重新訂票 正確的機票數 提示：訂票成功 第六章 結束語 經過兩周的努力，我們終于完成了《軟件工程》的課程設計。從開始接到題目到系統的完成，每走一步對我們來說都是新的嘗試與挑戰。我們從對軟件工程的技術不熟悉的狀態開始了課程設計，查看相關資料和書籍，讓自己頭腦中模糊的概念逐漸清晰，使自己非常稚嫩的作品一步步完善起來，每一次改進都是學習的收獲，每一次試驗的成功都是辛勞的成果。
此次課程設計中，本小組根據軟件工程實行過程完成了機票預定系統的大部分功能，包括用戶（旅客、旅行社）注冊，管理員登錄系統進行航班添加查詢功能，用戶（旅客、旅行社）登錄系統進行查詢訂票功能。
雖然我們的作品不是很成熟，還有很多不足之處，但我們可以自豪的說，這里面的每個細節都有我們的辛勤付出。兩周的時間過去了，我們的課程設計也將告一段落，點擊運行程序，也基本達到預期的效果。心中不由得也會冒出小小的成就感。由于時間和精力的關系，做出來的程序中仍有許多不盡人意的地方。例如：功能不夠完善，界面不夠美觀等。對于這些遺憾我們只能以人們常說的，“做一件事，不必過于在乎最終的結果，可貴的是過程中的收獲”來聊以自慰。但在以后的時間里我們仍會再接再厲把這個程序做的更加完美。
在本次軟件工程設計過程中，我們不免遇到很多的困難但是在老師的精心指導和自己的不斷努力下基本上完成了此次的設計并達到了預期的要求，而且自己在程序設計方面也有不少的收獲，更加堅定了自己在編程中的信心。在此，衷心感謝胡老師的認真授課和精心指導！ 參考資料：
[1]吳潔明等，《軟件工程實例教程》，清華大學出版社。
[2]錢樂秋等，《軟件工程》，清華大學出版社。
相關熱詞搜索：;