第一篇：軟件工程課程總結

課程總結

本課程是一門介紹應用軟件開發的概述性的課程，系統講授了應用軟件的相關開發過程，和所應用的技術。課程講授了9章的內容，包括產品、軟件工程與軟件過程，軟件需求工程、分析建模、設計工程、軟件體系結構設計、用戶界面設計、構件級設計和軟件測試技術等。

1、軟件產品

計算機軟件是一種特殊的邏輯產品，其為在計算機上運行的各種程序、數據及其說明程序的各種文檔；軟件承擔著雙重角色，軟件是一個產品，同時又是產品交付使用的載體；軟件是邏輯的而不是有形的，軟件是基于計算機的系統元素，因此軟件具有與硬件完全不同的特征；軟件產品有著特有的產品分類方法；在計算機軟件開發中所遇到的一系列無法完全解決的問題，導致了軟件危機或軟件苦惱的產生；在軟件開發過程中，由于軟件產品開發的特性導致了一些神話的產生，這些軟件神話誤導了人們，對軟件項目管理者、客戶和開發人員都帶來了嚴重的問題，了解相關情況可以使我們能以正確的態度對待軟件開發工作；由于軟件產品的特殊性，軟件工程從業人員的職業道德和行為準則顯得更加重要。

2、軟件工程與軟件過程

軟件工程是由有創造力的、有組織的人在定義成熟的軟件過程中進行的，該過程適合于軟件開發人員建造的產品和產品的市場需求；軟件工程的定義：建立和使用一套合理的工程原則，以便獲得經濟的軟件，這種軟件是可靠的，可以在實際機器上高效地運行。

軟件工程過程是一個為建造高質量軟件所需要完成的任務的框架，是建造軟件產品的一組活動及其結果。通用過程框架目的：

交流-----項目啟動、需求獲取及其任務集合計劃-----項目評估、進度安排、項目跟蹤等

建模-----分析模型和設計模型

構造-----代碼生成和軟件測試

部署-----產品交付、技術支持、用戶反饋等及其相應的任務集合。

3、軟件工程過程模型，是指能夠覆蓋軟件工程的過程、方法和工具以及軟件工程的一般階段的開發策略。過程模型的選擇待建造軟件的特點、所采用的方法與工具、以及需要的控制和交付的產品。

瀑布模型，增量過程模型——增量模型、RAD模型，演化過程模型——原型模型、螺旋模型，面向對象軟件工程過程模型——統一軟件開發過程。

4、需求工程

基于計算機的系統工程：在了解系統之前，匆忙建造技術元素，無疑將導致使客戶失望的錯誤。在關注樹木之前，先了解森林；基于計算機的系統：元素的集合或排列，這些元素在一起通過處理信息完成某些預定義的目標；系統元素——軟件、硬件、人員、數據庫、文檔和規程；啟動一個系統工程 ——發現領域過程、領域分析、識別協作系統、發現系統需求、將結果提交給客戶；系統建模：評估系統構件及其相互關系。

5、軟件工程實踐

理解問題（交流和分析）、計劃解決方案（計劃與建模——軟件設計）；實施解決方案（構造——代碼生成）；檢查結果的精確度（構造成部暑——軟件測試、質量保證、用戶技術支持）

6、軟件需求收集與分析

構建一個軟件系統最困難的部分是確定構建什么。其他的軟件開發工作，不會像這部分工作一樣，在出錯之后如此嚴重地影響隨后實現和系統，并且導致在以后進行的修補會如此困難；“我知道你相信你已經理解了你認為我所說的內容，但是我并不能肯定你已認識到你所聽到的并不是我所想要的”。

7、軟件需求分析的工作活動

起始——建立對擬開發軟件（待解決的問題）的基本理解

導出——問題的范圍、問題的理解、問題的變化；

精化——開發精確的技術模型，說明軟件的功能、行為和約束

協商——確定合理的系統目標和需求優先級

規格說明——給出對軟件系統功能和性能的描述，給出影響系統開發的約束；

確認

需求管理

8、軟件的需求誘導——需求誘導原則

需求定義——需求是關于系統（軟件系統）將要完成什么工作的一段描述語句，它們必須經過所有相關人員的認可，其目的是徹底解決客戶的問題；

需求誘導原則（與客戶的交流溝通活動）——傾聽、有準備的溝通、需要有人推動、最好當面溝通、記錄所有決定、保持通力協作、聚焦并協調話題、采用圖形表示、繼續前進原則、談判雙贏原則；

軟件需求的過程啟動——首次提問、一組加深理解并使客戶能夠表達其關于解決方案的感覺的問題、關于效率的“元”問題。

9、軟件需求的導出

質量功能部署——正常的需求、期望的需求、令人興奮的需求。

功能性需求和非功能性需求——功能性需求，描述系統為用戶或其他系統提供的服務；非功能性需求，系統開發過程必須遵守的約束。

10、用戶場景與分析建模

用戶場景（use—case）

構建分析模型——數據模型、功能模型、行為模型

11、需求確認與規約

12、分析建模

分析建模使用文檔和圖表形式的組合，以相對容易理解的方式描繪數據、功能和行為的需求，并直接評審其正確性、完整性、一致性。

分析建模原則：

原則1：必須描述和理解問題的信息領域

原則2：必須定義軟件將實現的功能

原則3：作為外部事件的結果，必須描述軟件的行為

原則4：描述信息、功能和行為的模型必須通過問題的劃分，以層次的方式揭示細節 原則5：分析過程應從要素信息移向實現細節

13、分析建模的任務集合評審需求

擴展和細化用戶場景

信息建模（數據對象描述與數據建模）

功能建模

行為建模

用戶接口分析和建模

評審所有模型，考察其正確性、完整性和一致性

14、用戶場景建模：開發用例；場景建模

數據建模：數據對象描述——數據字典，數據建模——數據對象、屬性和關系，數據模型——實體——關系圖（ERD）

功能建模和信息流：信息流模型（DFD），信息流與功能建模

行為建模——狀態變遷圖（STD）

15、設計的原則與概念

設計是將要建造的某種事物的有意義的工程表示。軟件設計創建軟件的表達或模型，提供了軟件數據結構、體系結構、接口和軟件構件的設計細節——提供了軟件系統實現所必須的工作基礎。

對設計良好的軟件而言，堅固是指程序不應含有任何妨礙其功能的缺陷；適用則是程序符合開發目標；賞心悅目意味著使用程序的體驗是愉快的。

設計原則

設計過程不應該受“隧道視野”的限制；

設計對于分析模型應該是可跟蹤的；

設計不應該從頭做起；

設計應該縮短軟件和現實世界中問題的“智力距離”；

設計應表現出一致性和集成性

設計的構建應該適應變更

設計的構建，應該使得即使遇到異常的數據、事件或操作條件時也能夠平滑、輕巧地降級；

設計不是編碼，編碼也不是設計；

在創建設計時就應該能夠評估質量，而不是在事情完成以后；

應該評審設計以減少概念性（語義性）錯誤。

16、設計的概念——抽象、求精、模塊化

設計文檔——描述設計工作的整體范圍、說明數據設計、體系結構設計、接口設計、構件設計、需求交叉引用、軟件測試、設計約束、補充說明

17、軟件體系結構設計

設計建模原則

原則1：設計可追溯到分析模型

原則2：經常關注待構建系統的框架

原則3：數據設計與功能設計同等重要

原則4：設計接口（內部接口和外部接口）

原則5：用戶界面必須符合最終用戶要求

原則6：功能獨立的構件級設計

原則7：構件之間、構件與外部環境之間松散耦合原則8：設計模型應易于理解

原則9：設計以迭代方式進行，每一次迭代，設計者應盡力簡化問題。

體系結構設計為軟件開發提供了系統的整體視圖，并保證系統開發人員能正確地得到需要的系統；軟件體系結構設計涉及兩個方面——數據設計：表示體系結構的數據構件，程序體系結構：關注于軟件程序結構、構件的性質以及交互表示。

軟件體系結構設計將需求分析中的數據、功能和行為模型中的元素，以及軟件數據體系結構的設計，最終映射為軟件系統的構件組織結構。

18、構件級設計

構件級設計也稱為過程設計，它在數據設計、體系結構設計和接口設計之后進行，其意圖是將設計模型翻譯為可以運行的軟件。

構件級設計是使用某些能夠易翻譯成源代碼的中間表示（如，圖形的，表格的或基于文本的）來表示過程設計。

構件級設計的目標是要保證不僅能夠完成翻譯任務，而且能夠不在開始時引入錯誤，即在過程設計中避免錯誤的產生。

19、用戶界面設計

用戶界面可以說是基于計算機的系統或產品的最重要的元素。如果界面的設計很糟糕，可能會嚴重地阻礙用戶使用系統的計算處理能力。

一個弱的界面可能導致一個很好和可靠實現的應用的失敗

三個重要的原則指導有效的用戶界面設計，置系統于用戶控制之下，減少用戶的記憶負擔，保持界面一致。

20、軟件測試技術

軟件測試的目的，就是在系統交付客戶之前能夠發現（和改正）盡可能多的錯誤。白盒測試又稱“玻璃盒測試”，白盒測試注重于程序控制結構

黑盒測試也稱為行為測試，黑盒測試注重于確認功能需求

第二篇：軟件工程課程總結

軟件工程課程總結

學習軟件工程這門課程已經有一個學期了，整整一個學期下來，應該說還是有許多值得肯定的地方的。其實在我看來，軟件工程與其說是一門課程，不如說是一門思想，是一個如何去分析和處理問題的過程，應該說其范疇已經遠遠不止局限于該門課程，成為了一個綜合的能夠解決問題的思想集合。

學習軟件工程能夠加強人的整體思維能力，對人的綜合素質有所提高，培養良好的分析規劃和團隊意識。學習了軟件工程，我們可以在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的軟件產品。追求這些目標有助于提高軟件產品的質量和開發效率，減少維護的困難。

在這學期的軟件工程課上，我每次都認真聽老師講課，跟著老師的腳步，領悟老師的思想，學習態度還算認真。一剛開始還覺得這門課有點枯燥乏味，但后來靜下心來看這本書感覺書上的知識對以后無論是在生活、學習還是在工作上都有很大的好處，對自身也是一種完善，因為這里面的思想博大精深，值得學習。從此我就認真地學習這門課程。盡管在學習的過程中遇到了很多困難，但經過與老師和同學的積極交流終于把問題解決了，從中學到了更深層次的知識，而這些知識又是對書本知識的補充，對學習書本知識有很大的好處。當然，學習理論知識就是用來指導實踐的，也只有把理論知識運用到實踐才能充分發揮理論的作用。所以在業余時間，我們嘗試著把所有知識串起來，并根據自身的實踐經驗完成了相關的系統分析報告，讓知識能更加駐留我心。

在本學期的軟件工程課程的學習中，我們學習了十章的內容。第一章軟件工程概述，這一章主要講解的是一些概念性和基礎性的內容，例如軟件的概念、特性，軟件危機的主要表現。了解軟件工程的的工作對象、發展背景、內容、目標。還介紹了三個常用的軟件工具Microsoft Visio、PowerDesigner和Rational Rose。第二章軟件開發過程模式，這一章主要讓我們了解軟件生存周期，認識到了軟件開發過程，熟悉了幾種常用的軟件過程模式的特點與用途。此章介紹了6種模式：瀑布模式、原型進化模式、增量模式、螺旋模式、迭代模式和組件復用模式。第三章軟件項目管理，本章詳細介紹了項目管理內容（對項目的管理、對項目成果的管理），讓我們學會如何制定項目計劃，并學習使用甘特圖、任務網絡圖（由Microsoft Project創建）制定項目計劃。第四章計算機系統工程，這一章讓我們熟悉如何從全局的計算機系統角度考察軟件問題，熟悉如何對軟件項目做可行性分析。該章還涉及系統初步建模，其中的系統框架圖、系統流程圖，可由Microsoft Visio中的基本流程圖創建。第五需求分析，這一章重點講解了需求分析任務及過程，讓我們學會如何獲取業務需求、建立業務模型、進行需求驗證。可通過Microsoft Visio中的組織圖創建業務樹，通過Rational Rose創建業務用例、業務活動。第六章結構化分析建模，這一章重點講解了使用變換型映射方法和事務型映射方法生成初始的模塊結構以及模塊結構的改進。說明了建立分析建模的原因和方法。我們可通過PowerDesigner創建實體聯系圖，通過Microsoft Visio創建數據流圖，通過Rational Rose創建事件狀態圖。第七章基于UML的面向對象分析建模，本章詳細介紹了UML的基本模式、事物、關系及建模時用到的各種圖進行了介紹。可通過Rational Rose進行面向對象分析建模。第八章概要設計，這一章主要講解了概要設計任務及過程，介紹了系統構架、數據結構、程序結構等概要設計內容。第九章結構化設計建模，本章介紹了結構化設計建模的工具，讓我們學會如何基于數據流進行程序結構映射和如何對程序結構進行優化。該章中的程序結構圖由Microsoft Visio創建。第十章基于UML的面向對象設計建模，本章講解了面向對象設計建模內容，讓我們學習使用UML建立面向對象設計模型（邏輯結構、動態過程、物理裝配與部署）。通過Rational Rose進行設計建模。

學習了這門課程之后，我發現無論是在上課，還是在學校里面做學生工作，技術性的工作就好比變魔術。其實原理是非常簡單的，甚至可以說簡單的可笑，但是當你就是做出這么一個簡單的東西出來之后，一些外行們有時候會用崇拜的眼光看著你，覺得你很厲害，很高深莫測。但是制作的過程他們卻不知道，也許知道之后他們只是會啞然失笑，原來這個東西的制作過程是如此的簡單，這個可以說就是技術的魅力了。就比如說軟件工程中所謂的需求獲取，從字面上來看好像是一件很難的事，而其實就是一個談判，辯論，交流的過程，只不過這個交流過程可能針對性比較強。所以說軟件工程就是對生活的平凡小事的升華，它來自于生活卻高于生活。當我們在畢業之后，軟件工程是我們實際要運用的一項非常有用的技能，而且不僅僅局限于軟件工程的范疇，即使我們是從事其它行業，不也是要從需求獲取開始，一直有條有理地到最后成品的出爐嗎？應該說這就是這門課的價值所在，它讓我們既學會了管理又學會了技術。

在整個學期的學習過程中，我收獲了不少，能夠解決一些較為簡單的問題，在建模方面的能力有所加強。原來一直以為學好這門課程最重要的是會編寫程序，其實則不然。我了解到軟件并非是一些代碼這么簡單，在開發軟件的過程中，編寫代碼的工作量其實只占不到所有工程量的30%，而后期的管理和維護更是占了60%到80%之多。一個完整的項目規劃須包括：軟件的定義、可行性分析報告、項目開發計劃、軟件需求說明書、概要設計說明書、詳細設計說明書、用戶操作手冊、測試計劃、測試分析報告、開發進度報告、項目開發總結報告、軟件維護手冊、軟件問題報告、軟件修改報告等多個文檔，每個文檔都要上級驗收審查，而文檔數量眾多，要做好這點真的不是很容易，而恰恰寫好文檔正能保證完成軟件工程其中一個目的的關鍵，既研究如何用最小的開銷做出生存期較長的軟件，再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排，且各階段要據具體情況不斷的反復才能達成，所以代碼只是開發軟件這個浩大的工程的一個小小的過程。當然自己也有很多的不足之處，比如自己動手操作能力比較弱，實踐經驗匱乏，思維不緊密，不注重細節，耐心不夠，每次遇到問題就去問老師，實戰精神不強，所以導致很多知識學得也只是模模糊糊的。所以在以后的學習中我要加強自身綜合素質的培養，要注意多看多練要注意結合實際，更要多思考，面對錯誤不要一范就問，要嘗試自己去解決，這樣才能學到這門課程的精華。我覺得學好軟件工程首先要明白自己的學習目標究竟是什么，根據自己的實際工作出發，有針對性地在相應的學習方向上進行提高，制定出詳細的學習規劃。還要注意與其他科目的相輔相成，就像我們在學習語言時，要看看與C語言的聯系，多思多想，把從各個科目學到的知識融匯貫通。

在本學期我們班每位同學都做了管理信息系統分析報告，其中就用到了軟件工程中的不少知識。比如項目來源，項目任務，項目規劃，系統需求分析，系統結構設計，系統詳細設計，系統測試，系統維護等等。而我做的是酒店客房管理信息系統的分析報告，其中涉及到了以上幾個方面，需要明確任務目標，準備相應的項目資源，對項目實施合理的規劃，進行業務需求和功能需求分析，制定出數據字典，設計出軟件結構，并對其進行詳細設計，比如算法設計，數據庫設計和界面設計。畫出進度安排表，組織結構圖，業務流程圖，數據流圖，利用UML建模畫出圖形，通過這些圖形能更直觀地看出各個實體之間的關系，對系統有個比較整體的體現。

總之，在今后的學習中要注意多讀書、多思考、多練習、多討論，不斷熟悉書本的基礎，并以此為基礎將其擴散開來，應用于今后的實踐。不斷鍛煉自己，成為社會的可用之才，回饋社會。

第三篇：軟件工程課程

軟件工程專業本科生課程設置

時間：2009-03-22 08:47 來源： 作者： 點擊：1059

學院在課程體系制定、課程計劃安排上制定了嚴格的規定與規范的操作程序。課程體系、教學計劃由學院主管院長負責，對國內外大學、大型IT企業進行調研、分析，確定社會對人才的需求和人才知識、能力、素質的構成，而后由主管院長召集相關教師起草方案，再經學院教學指導委員會專家和企業專家進行論證，并報學校教務處審核、批準，由此形成本科生、碩士研究生的培養方案。同時，根據學科發展和社會需求的變化，學院通過增加或變更選修課、開設講座等方式動態調整。目前，軟件學院主要課程設置按課程體系關鍵域分類如下。

1)數學基礎(本科)：大學數學I、概率論與數理統計、數值分析、離散數學等。

2)軟件基礎(本科)：數據結構、匯編語言程序設計、面向對象編程與設計、可視化程序設計基礎、操作系統、數據庫系統、C/C++程序設計、算法分析與設計、編譯原理、軟件工程等。

3)硬件基礎(本科)：數字電子技術、計算機系統基礎、數字通信原理、微機原理與技術、計算機網絡原理等。

4)專業技術(本科)：大型數據庫技術、軟件體系結構、系統級編程技術、數據挖掘、嵌入式系統、J2EE應用開發、.NET架構軟件開發、設計模式、建模與測試、信息安全、軟件開發案例分析、并行程序設計、多媒體技術及應用、網絡與分布式計算、計算機圖形學等。

5)工程管理(本科)：軟件開發項目管理、軟件質量管理與控制、企業管理、網絡營銷、商務談判技巧、軟件度量及應用、心理學、商務英語等。

6)數學基礎(雙證碩士)：應用統計、組合數學、應用數學方法等。

7)軟件理論基礎(雙證碩士)：現代軟件工程、面向對象與構件技術、高等計算機算法、移動計算等。

8)數學基礎(工程碩士)：運籌學、工程數學基礎、應用數學方法等。

9)軟件理論基礎(工程碩士)：分布式系統、現代軟件工程、軟件重用與構件技術、軟件工程實例分析等。

第四篇：軟件工程課程心得

軟件工程項目總結

在我們整個軟件工程過程中，我體會到了許多，也學到了許多。

在項目要進行自由分組后，我們的項目小組便誕生了。我們小組由七個成員組成，在相互商量后我們也確定了我們組的項目，是做一個校園 b2c電子商務網站。我們也隨即做了分工，由于我們團隊只有我和另一名成員有類似的項目開發經驗，所以我們便要擔負起更重的任務。最后由于在整個團隊中，對于界面開發這一塊只有我的開發經驗較深，所以我便擔任了主要的界面設計人員。我們的項目也正式開始了。

需求調研和分析對于軟件開發過程至關重要。我們在開發時如果不進行調研和分析，那么對于后來的項目進展將產生致命的后果。我們在項目的開發中便遇到了這樣的問題。老師作為我們的客戶，他對這個校園 b2c電子商務網站的要求便是我們必須了解的，我們也必須以客戶的要求為根本構建我們的這個系統。我們開始自己隨意的計劃整個網站的設計，然后報給老師，老師作為一個客戶并不是全部認同，隨后我們也必須按著客戶的要求更改我們的設計報告。我也明白了，再做一個系統時，必須隨時和客戶保持溝通，隨時了解他們需要什么，他們想要什么功能。如果我們不去和客戶溝通，不去調研客戶的需求，做出來的系統即使在我們看來是一個很好，很完美的產品，但是如果客戶不認同，那么我們所做的一切都是徒勞，還要返工去修改，費時費力。所以在做任何一個項目時，前期的需求調研和需求分析都是必須的，這是在做一個項目的基本，是關系成敗的重要一環。

對于一個項目，它的需求設計也非常重要。在我們的校園 b2c電子商務網站開發的過程中，遇到了一些問題，如客戶提交購買確認后，我們如何確定應該以什么方式將貨物給客戶，還有以什么確定貨物的送達地點，客戶的訂單在哪里處理，訂單以什么方式驚醒處理，在管理員應該實現的功能上反復增刪等，這些問題很多都是由于設計不夠清晰，不夠完善而導致的。出現的這些問題很多都是非常棘手的，我們為了解決這些棘手的問題浪費了大量的時間，我們不得不在工程代碼上改了又改，在數據庫里增表、刪表、加數據、減數據，當然，在文檔里也要做出相應的修改以適應新的功能。還好，我們能及時地發現問題，通過相互

溝通討論，問題也得到了解決。通過總結，我們也意識到，我們大家在做需求分析和進行需求了解時僅僅考慮了一些基本的功能，而至于管理員和客戶之間的聯系，以及具體的一些流程我們都沒有深究，而導致我們到后期花費了大量的時間用于修復之前沒有考慮周全而帶來的問題。如果我們的需求設計能夠比較清晰和完善，那么我們在開發過程中便會很明白的知道我們應該實現什么樣的功能，在數據庫里應該怎樣建表，以什么方式插入數據，從而可以避免反復修改工程的問題，也能避免出現可能毀壞整個工程的問題。整個工程的需求設計對于一個項目的順利進展至關重要。

對于文檔在軟件工程中的作用，我在這次項目開發過程中有了更加深刻的理解。文檔在軟件開發過程中是很有用的，文檔是一項必不可少的東西，但文檔也不能太多，太過繁瑣，如果是那樣就不太好了。首先我們要明確開發過程中為什么要寫這些文檔，文檔的最根本的作用是為了更好的溝通。一個項目或產品可能需要延續很長的時間，開發過程中可能需要很多的環節，可能會遇到很多的問題和很多的解決的方法，這時，我們需要文檔的幫助，我們需要有一個東西來記錄，我們需要有一個共同的聲音。文檔只不過是一個準繩，將開發中的各個樹枝樹葉扶正。如果，這個準繩太多太緊，大樹可能會發育的很高很直，但是就是有些畸形，如果這個準繩太少太松，大樹可能就會變成灌木叢。文檔的多少、繁簡是有度的，絕對不能說越多越好。我覺得，文檔需要說明解決問題的方法而不是解決問題的理論，因為解決問題的理論是在文檔形成中做到的。文檔完整即可，每一份文檔說明一個問題，無需將多個文檔的內容放在一個文檔的里面。除了重要階段形成文檔，其它部分都只是討論或者說是想法。不要讓文檔成為累贅，如果真是這樣，我認為就是該考慮寫這些文檔的必要性的時候了。我們在文檔的時候，一定要明白為什么要寫這些。

在整個項目開發過程中，我們也同時遇到了許多程序接口問題，頁面和功能相結合的問題，數據庫建表的問題，這些問題都是源于我們項目小組成員之間的溝通不足。我深刻認識到，在項目開發時，項目小組中各個成員之間的相互溝通是非常重要的。如果我們要在功能方面作出修改，那么程序人員和頁面人員及數據庫人員就必須相互溝通，共同對整個程序作出相應的修改，這樣才能避免最終整合時出現問題。

在這十個周里，我還對軟件工程有了新的理解。在我以前的理解當中，軟件工程，無非就是一個人或者幾個人或一個團隊集中在一起進行編寫代碼的工作，以實現開發出所用的軟件。但現在我明白了，軟件工程的作用，就是告訴人們怎樣去開發軟件和管理軟件。具體地講，它表現在與軟件開發和管理有關的人員和過程上。所以，軟件工程就不僅僅是單一的編程過程了。它包括了系統分析->建模->概要設計->詳細設計->編碼->測試->維護。編碼可以理解為編程，這個只占總時間的20％左右。編程只是其中的一小部分。

在這次項目里我完成了許多工作，在界面設計上我完成了，首頁、全部的商品頁面、全部的用戶頁面及部分管理員頁面的制作，在后期項目整合過程中修改了功能和界面結合時出現的bug，還有數據庫插入數據及解決數據庫集中整合時出現的問題。這些工作我都順利完成了，雖然并不能算是非常的出色，但也算是盡力了。現在看到自己辛勞的成果，我感到很欣慰。

當然，在這次項目過程中我也發現了自己的一些問題。如現在的網站開發技術還不夠強，在和小組成員相互溝通上還不夠積極等。我希望以此為契機，在將來的項目開發中能做得更好。

第五篇：軟件工程課程心得

軟件工程設計總結

在我們整個軟件工程過程中，我體會到了許多，也學到了許多。

在項目要進行自由分組后，我們的項目小組便誕生了。我們小組由七個成員組成，在相互商量后我們也確定了我們組的項目，是做一個圖書管理系統。我們也隨即做了分工，由于我們團隊只有我和另一名成員有類似的項目開發經驗，所以我們便要擔負起更重的任務。最后由于在整個團隊中，對于界面開發這一塊只有我的開發經驗較深，所以我便擔任了主要的界面設計人員。我們的項目也正式開始了。

對于文檔在軟件工程中的作用，我在這次項目開發過程中有了更加深刻的理解。文檔在軟件開發過程中是很有用的，文檔是一項必不可少的東西，但文檔也不能太多，太過繁瑣，如果是那樣就不太好了。首先我們要明確開發過程中為什么要寫這些文檔，文檔的最根本的作用是為了更好的溝通。一個項目或產品可能需要延續很長的時間，開發過程中可能需要很多的環節，可能會遇到很多的問題和很多的解決的方法，這時，我們需要文檔的幫助，我們需要有一個東西來記錄，我們需要有一個共同的聲音。文檔完整即可，每一份文檔說明一個問題，無需將多個文檔的內容放在一個文檔的里面。除了重要階段形成文檔，其它部分都只是討論或者說是想法。不要讓文檔成為累贅，如果真是這樣，我認為就是該考慮寫這些文檔的必要性的時候了。我們在文檔的時候，一定要明白為什么要寫這些。

在這一周里，我還對軟件工程有了新的理解。在我以前的理解當中，軟件工程，無非就是一個人或者幾個人或一個團隊集中在一起進行編寫代碼的工作，以實現開發出所用的軟件。但現在我明白了，軟件工程的作用，就是告訴人們怎樣去開發軟件和管理軟件。具體地講，它表現在與軟件開發和管理有關的人員和過程上。所以，軟件工程就不僅僅是單一的編程過程了。它包括了系統分析->建模->概要設計->詳細設計->編碼->測試->維護。編碼可以理解為編程，這個只占總時間的20％左右。編程只是其中的一小部分。

當然，在這次項目過程中我也發現了自己的一些問題。如現在的網站開發技術還不夠強，在和小組成員相互溝通上還不夠積極等。我希望以此為契機，在將來的項目開發中能做得更好。