第一篇：軟件工程心得

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

在上課的時候我還是很認真地去聽老師所講述的內容的，我覺得他的思想和我一向而來的培養計算機學生綜合素質的理解還是在一定程度上不謀而合了，所謂的需求獲取，那就是一個談判，辯論，交流的過程，已經不是單純的編編程序就能解決的問題了。從我所看到的聽到的來說，我最怕的就是計算機系的學生被別人說成是個帶著厚眼鏡的，只能夠在電腦前編編程序的，在交際場上不知道說什么而一個字都說不出來的人。我覺得這樣的人進入社會之后是沒有什么前途的，起碼他們缺乏了與人溝通交流的能力。而這門課程在一定程度上給了我們這些學生一個機會來鍛煉自己在另一方面的能力，設想一下，一個又有技術又能夠與人交流合作的人所取得的成就自然要比一個單單只會編程序的人要大得多。

其次，這門課程教給了我們在完成一個實際項目時的一般程序及過程，我認為這是一份非常具有實際意義的教學內容。當我們在畢業之后，這是我們實際要運用的一項非常有用的技能，而且不僅僅局限于軟件工程的范疇，我們即使是從事與其它行業，不也是要從需求獲取開始，一直有條有理地到最后成品的出爐嗎？應該說這就是這門課的價值所在。無論是在上課，還是在學生會里面做學生工作，我都深深地感覺到，技術性的工作就好比變魔術，其實原理是非常簡單的，甚至可以說簡單的可笑，但是當你就是做出這么一個簡單的東西出來之后，一些外行們有時候會用崇拜的眼光看著你，覺得你很厲害，很高深莫測。但是制作的過程他們卻不知道，也許知道之后他們只是會啞然失笑，原來這個東西的制作過程是如此的簡單。這個可以說就是技術的魅力了，而作為需求獲取及之后的一系列過程則是類似于魔術揭秘的過程，但是作為這個秘密我們并不需要一揭到底，至于揭的程度如何那就是我們那就是我們學出的程度如何了，我們要讓對方知道我們在做什么？以及如何去做？這些東西需要我們以一定的技巧敘述出來，所起到的作用就是能夠讓對方了解自己的進度，卻又能夠不讓對方來干涉自己的工作過程。因為我們是技術員，對方只是外行，即使對方知道了這個魔術的操作過程，也并不代表他們就能夠向變著魔術的我們來隨便修改這個魔術的變法，況且我們能夠用不同的過程來得出一個同樣的結果，這個過程的得出的主動權如何掌握在我們的手上，就看我們如何以高明的方式來揭開這個魔術的謎底了。

當然了，在純粹的理論上，我覺得開設這樣一門課程是很成功的。但是畢竟現實里有太多的不確定的因素。最重要的因素就是授課的老師和聽課的學生。這兩個可以說是這門課成與敗的決定性的因素。

作為老師方面來說，我覺得給我們上試驗課的老師非常的優秀，作為一名了有十幾年工作經驗的老船長，看問題的確是有他自己獨特的一套方法，我的話對他也是非常崇拜的。但是周日晚上的課程我還是有比較大的意見，首先，作為學生來說，最不希望上課的時間就是周五的晚上和周日的晚上，因為這是個我們進行調整的時候，前者的調整是為了假期的到來，后者的調整是為了準備學習的開始，這個時候的上課一般來說都是學生比較反感的。其次，對于我來說，原來小的時候非常崇拜那些有著高學歷的人才，什么碩士，博士，博士后都是被放在神壇上的人物，覺得他們很厲害，走路都會散發光環。但是在我上了他們這些人的課之后我發覺我真的是很失望。作為一個具有高學歷的人來說，他能夠自己迅速的吸收知識這點的確是令人敬佩，但是他能不能夠把自身所吸收的知識傳授給他的學生，那就是一個未知之數了，雖然的確這是一門枯燥的課程，但是并不代表老師就可以在講臺上講課沒有一點激情，或者說沒有一點能夠讓我們想聽下去的欲望，這個不得不說是一件非常諷刺的事情。子不教，父之過；教不嚴，師之惰。雖然學生們也有一部分的責任，但是把一切責任都推到學生們的身上那也是非常的不公平的。

作為我們學生來說，當然也應該負起比較主要的責任。在大學里有了太多的基礎課程，基礎課程大多都比較枯燥無味，也許在第一個學期里我們還能夠保持著新鮮感，但是在5個學期之后，可以說再有新鮮感就是一件比較困難的事情了，我們都已經開始變得遲鈍了，現在出現了一門新鮮的課程，可能同學們比較難把那樣不好的狀態一下子改變過來。其次的，學生們沒有認識到這門課程的價值。這門課的價值我已經在上面說過了，是不言而喻的。但是并不是每個同學畢業之后都回從事計算機行業，也不是每個同學都知道這門課程的意義已經不僅僅局限于計算機這個范疇，但是他們不知道，無知者無畏也。既然和我沒什么關系，那我就不聽，反正聽了也沒什么用，很多同學報著的就是這么個心態。對于這樣的心態，我表示理解，也表示悲哀。在沒有徹底了解一件事物的本質之前，我們是沒有資格向這件事物隨便的指手畫腳的。最怕的就是在沒有了解之前就把這件事物否定。如果有了這樣先入為主的思想，那就比較沒救了。所以作為我們來說，還是更需要得深入了解下這門課所起到的作用之后再下結論也不遲。只是有一點我還是覺得比較奇怪，現在被人嗤之以鼻的傳銷在當時能夠吸引如此大的一批人，而且那些受害者明知道這件事情是不好的但是還會去做，就是因為“洗腦者”的口才說服了他們，那作為老師來說，如何來說服學生們來上一門正確的課程應該說是要相對的容易很多吧，但是我覺得這樣的過程在我們的大學課程里真的是少之又少啊。今天在這里寫了很多，算是我對軟件工程這門課程的一點點心得體會，也許是正確的，也許在一定的程度上存在著觀點的偏激錯誤，但是起碼這些東西是我覺得存在著的一些問題，但愿軟件工程這門課程能夠開的越來越好，讓更多的學生們能夠從這門課程中受益，在以后社會殘酷的競爭之中存活下來！

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

軟件工程項目總結

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

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

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

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

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

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

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

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

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

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

第三篇：軟件工程試驗心得

心得體會

學了一個學期的軟件工程課，終于知道了個軟件工程的大概。學的時候總覺得很抽象，理解起來好像不難，但總是摸不著頭腦一種很茫然的感覺。學習的過程中和一個宿舍的同學一起做了個小型管理系統的開發，覺得還是有點收獲的，對于開設這門課的意義也有所領悟，現在就將我對這門課的體會以及在項目開發過程中遇到的一些問題簡單的歸納一下。希望在以后的學習中不斷的提高吧。

曾經以為程序就是軟件，軟件就是程序。現在知道了二者的不同之處，這是學習這門課程第一個收獲。事實上在軟件開發的早期階段這也不能說是錯誤的。那個時候開發的軟件都比較簡單。當然可以把軟件理解成程序，直到軟件作坊的出現，使軟件在程序的基礎上加了個說明。以前做過的一些小型的軟件比如加密軟件，也只是在程序旁邊附上一個軟件的說明，看來已經很接近作坊了。不過大的項目沒有接觸過，用軟件工程的方法還是第一次。我想也是程序的不斷復雜化導致了軟件危機的發生，使得人們不得不探索新的解決方法。這個時候軟件工程應運而生了。

掌握軟件工程化的思想，對于負責軟件開發的管理人員（領導）更為重要。曾經看到過這么一句話，“坐在指揮臺上，如果什么也看不見，就不能叫領導。軟件工程將有能力的人團結在一起，然后把他們變成工人，因為工業化的生產是效率最高的。這就是根本所在。沒有軟件工程管理，簡直就是亂來，就好象缺乏宏觀控制的國家一樣，會亂七八糟。

軟件除了程序還要有使用和維護該程序所需要的全部文檔。包括需求文檔、設計文檔、測試文檔、維護文檔以及使用手冊。

軟件開發特別是大型軟件是一項浩大的工程,需要幾個人、十幾個人、幾十個人甚至幾百個人合作開發幾個月、十幾個月甚至幾年。要保證系統的協調性、統一性和連續性,就需要在開發之前制定嚴格、詳細的開發規范。開發規范的制定需要花費一定的時間和精力,但是“磨刀不誤砍柴功”,它相當于把今后開發過程中開發人員都要遇到的問題提前做了一個考慮。有了開發規范,在后續的開發過程中,設計人員就不必每次考慮如何為一個字段命名,編程人員也不必去想某個程序的結構和布局應當 怎樣,測試人員也有了判斷程序對錯的標準。它約束開發人員的行為和設計、編程風格,使不同子系統和模塊的設計、編程人員達成默契,以便形成整個系統的和諧步調和統一風格,也便于今后的系統維護和擴展工作。

第四篇：軟件工程實踐心得

軟件工程（SE）

軟件是計算機系統中與硬件相互依存的另一部分，它包括程序、相關數據及其說明文檔。軟件工程（Software Engineering,簡稱為SE）是針對軟件這一具有特殊性質的產品的工程化方法。SE涵蓋了軟件生命周期的所有階段，并提供了一整套工程化的方法，來指導軟件人員的工作。任何事物都是從無到有的，軟件當然也不例外。上世紀中期，軟件產業從零開始起步，經過半個多世紀的發展，其大致經歷的3個階段：程序設計階段、軟件設計階段和軟件工程時代，現已成為推動人類社會發展的龍頭產業，隨著信息化時代的發展，軟件對人類社會也將越看來越重要。人們對軟件的認識自然經歷了一個由淺入深的過程，在得到巨大需求的同時，也遇到了一系列嚴重問題，即軟件危機。所謂軟件危機，是指在計算機軟件的開發和維護過程中所遇到的一些嚴重問題，其實質是軟件產品的供應趕不上需求的增長。概括的說包含兩方面的問題：

一、如何開發軟件，以滿足不斷增長，日趨復雜的要求；

二、如何維護數量不斷膨脹的軟件產品。為研究和解決軟件危機，一門新興的學科——軟件工程，應運而生。

軟件工程的概念是為了有效地控制軟件危機的發生而被提出來的，它的中心目標就是把軟件作為一種物理的工業產品來開發，要求“采用工程化的原理與方法對軟件進行計劃、開發和維護”，它的主要對象是大型軟件，它的最終目的是擺脫手工生產軟件的現狀，逐步實現軟件開發和維護的自動化。軟件工程的概念自提出來后，經過幾

十年的發展，雖然軟件危機沒有得到徹底的解決，但在軟件開發方法和技術方面已經有了很大的進步，提出了軟件工程知識體系、軟件工程三段論、軟件工程生存期模型、服用原則等等。

軟件開發過程大致經過7個階段：可行性分析、需求分析、概要設計、詳細設計、編碼、測試、提交與維護。接下來逐一分析本人見解：

一、可行性分析：顧名思義，就是看項目究竟“能不能做”。有3個方面：技術可行性、經濟可行性和操作可行性。要確定項目，首先要客觀的、科學的了解項目的規模、難度和時間限制，才可以確定應該投入多少人力、物力和財力去做這個項目，必須準確的估計項目的規模與難度。看項目是否有價值去做，如果沒有價值，就放棄；如果有價值，就要看目前的資源是否能滿足項目的開發。如果項目有價值，且有必需的資源，那么就可以確定能做這個項目了。

二、需求分析階段：解決“做什么、不做什么”的問題。圍繞兩個核心問題開展需求分析：應該了解什么？通過什么方式去了解？

一、了解什么：應該先了解宏觀的問題，再了解細節的問題。最好為每個需求注釋“為什么”，這樣可以讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。同時，需求說明不可有額二義性，更不能前后矛盾，如果有二義性貨前后相矛盾，則要重新分析此需求。然后，選擇合適的生存周期，建立合適的需求模型；

二、通過什么方式去了解：直接與客戶交談；有些需求客戶講不清楚，分析人員又猜不透，這是就要請教行家。需求分析是非常重要的階段，如果做不好 的話，后果很麻煩。

三、概要設計：解決“怎么做”的問題。將需求描述的“做什么”問題變為一個實施方案的創造性過程，使得整個項目在邏輯上和物理上能夠得意實現。概要設計是第一個開發活動，也是最重要的活動，是軟件項目實現的關鍵階段。設計質量的高低直接決定了軟件項目的成敗，缺乏或者沒有軟件設計的過程會產生一個不穩定的、甚至是失敗的軟件系統。一個良好的軟件設計是進行快速軟件開發的根本，沒有良好的設計，會將時間花在不斷的調試上，無法添加新功能，修改時間越來越長，隨著給程序打上一個有一個的補丁，新的功能需要更多的代碼實現，就變成一個惡性循環了。概要設計是軟件設計級別中的高級設計，是從需求出發，描述了總體上系統架構應該包含的要素。概要設計盡可能模塊化，因此描述了各個模塊之間的關聯，主要是根據需求規格或規格定義，合理、有效地實現產品規格中定義的各項需求，完成軟件模塊的劃分并描述模塊之間的關系，并不斷分解系統模塊，從高層分解到低層分解。它注重框架設計、總體結構設計、數據庫設計、接口設計、網絡環境設計等，將產品分割成一些可以獨立設計和實現的部分并保證各個部分可以和諧的工作。此過程中畫數據流圖、IPO圖、E-R圖、界面設計等。

四、詳細設計：解決“具體做什么”的問題，將解決問題的辦法進行具體化。軟件設計的低級設計，亦即詳細設計，主要描述實現各個模塊的算法和數據結構以及用特定計算機語言實現的初步描述，是針對程序開發部分來說的，但這個階段不是真正編寫程序，而是設計

出程序的詳細規格說明，這種規格說明類似于其他工程領域中工程師經常使用的工程藍圖，程序員根據其中所包含的必要的細節寫出實際的程序代碼。用另一種方式說就是，詳細設計是將概要設計的框架內容具體化、明細化，將概要設計轉化為 可以操作的軟件模型，但在實際項目進行過程中，依據項目的具體情況和項目要求，這個過程可能可以省略（邏輯上沒有省略，表現在概要設計階段或者編碼階段），直接按照概要設計進行編碼；不過，個人認為最好有，有詳細設計可以更好的保證編碼順利的進行，可以預先掃清編碼過程中的障礙，提高代碼的質量和編碼的效率。主要包括模塊描述、算法描述、數據描述，可以采用圖形、表格或者文字描述等方式表達出來。

五、編碼：實現項目。由項目的概要設計和詳細設計，將設計變為代碼需要通過編碼過程來完成。實現設計有很多種選擇，有很多實現語言、工具等可供選擇，但一般而言，在設計中會直接或間接地確定了實現語言。編碼過程的一個主要標準時變成與設計的對應性和統一性。如果編碼沒有按設計的要求進行，設計就失去意義了。設計過程中的算法、功能、接口、數據結構都應該在編碼過程中體現。如果需求發生變更，設計業對應地發生變更，同時代碼也應該一致地發生變更，這可以通過配置管理配置控制。可見，如果編碼和設計不一致，很容易“跑偏”，走火入魔。編碼時要嚴格遵循編碼標準和規范，并提供必要的程序注釋，增加可讀性。另一個就是重構的理解，所謂重構是對軟件內部的一種調整，目的是在不改變軟件基本功能和性能的前提下，提高其可理解性，降低成本，當添加功能、修改代碼和復查

代碼的時候，更不要錯過重構，另外，重構可以和設計互補。還有一點值得注意，要在必要的時候部署編碼文檔。

六、測試：看軟件是否符合標準。軟件編碼完成之后，將軟件提交給用戶之前，需要對軟件進行測試，這是保證軟件產品質量的一個重要標準，也是評估產品質量的主要手段。軟件測試是從軟件工程中演化出來的一個分支，有著非常廣泛的內容，并且隨著軟件產業的發展，它已經變得越來越重要。軟件與生俱來就可能存在缺陷，為了防止和減少這些可能存在的缺陷，進行軟件測試是有必要的，測試是最有效的的排錯和防止缺陷和故障的手段。最原始的測試莫過于直接運行軟件了，后來測試手段逐漸多樣化。測試手段有靜態測試、動態測試面向對象的測試、自動化測試等等之分。靜態測試或稱靜態分析是指一種不通過執行程序來進行測試的一種技術，主要是檢查軟件的表示和描述是否一致，覆蓋程序的編碼格式、程序語法、檢查獨立語句的結構和使用等，主要包括代碼檢查、靜態結構分析、代碼質量等等，可以通過人工進行，亦可借助工具（如：語法分析器）自動進行。動態測試是運行被測試的程序，通過輸入測試用例，對其運行情況進行分析，以達到檢測的目的，顯然動態測試封像我們通常意義上的“測試”。動態測試主要包括白盒測試、黑盒測試、灰盒測試（介于黑盒和白盒之間）。其他測試不再一一介紹。

七、提交與維護：測試完之后，就要把軟件交給用戶使用了。提交不是剪裁，給人家就行了，還要教會客戶怎么使用這個系統。如果用戶不會使用系統，就會不滿意系統的性能，那之前的努力就白費了，打水漂了。為了保證成功地將我們開發的軟件提交給用戶，我們需要對用戶進行培訓，同時提交必要的文檔及用戶手冊軟件。維護就不用多說了，就是售后服務了。維護需要分析人員、編碼人員和設計人員等角色的參與，有糾錯行維護、適應性維護、完善性維護、預防性維護等。維護后，要寫軟件維護過程文檔，至少提交一個軟件維護記錄。

以上是軟件工程及其幾個階段的介紹，知道怎樣開發軟件只是軟件工程的一部分，搞好團隊合作也是很重要的。項目是一個很大的工程，需要一個團隊的統籌規劃，團結協作，集思廣益，舉一反三，才能夠按預期完成。

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

軟件工程設計總結

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

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

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

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

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