篇一：軟件項目開發總結
一． 引言
1．編寫目的
本項目開發總結報告，主要是總結本軟件的開發經驗和總結所學到的知識，以及對一個系統的大型的軟件設計的總體感悟，并將軟件設計過程中遇到的問題加以闡述和說明。
讀者對象：開發人員、大賽評委
2．項目背景
系統名稱：3D旅游咨詢員
任務提出者：山東省齊魯軟件設計大賽委員組
開發者：
面向用戶：游客
開發時間：2010年9月1號到2010年9月19號
該軟件運行系統：單機版計算計
3．參考資料
A、軟件項目開發總結報告書（GB856T—88）國家標準
B、齊魯軟件設計大賽手機游戲創意與實現項目的文檔要求
C、互聯網上的各類相關資料
二.開發結果
1． 產品
名稱：3D旅游咨詢員
存儲媒體的形式：光盤
數量：3份；
D 、產品文檔名稱：
軟件開發文檔：《需求需求說明書》、《概要設計說明書》、《詳細設計說明書》、《軟件測試計劃》、《軟件測試報告》
項目管理文檔：《軟件項目計劃》、《項目進度報告》、《項目開發總結報告》
產 品 文 檔：《用戶手冊》、《演示文件》
2．主要功能：
這是一款關于3d旅游的軟件，3D為本軟件的一大特色。
模擬現實世界場景，做到真實逼真的效果，增加了視覺沖擊力。可以像現實的人物一樣隨意走動，想到那就到那，想看到那就看那，而且操作簡單易行，
很方便用戶的使用，帶給用戶一種全新的設計。設計一個以岱廟為背景的軟件，軟件界面以紅色、灰藍色和土黃色為主，為游客展現一個立體的三維場景，展現岱廟的建筑群和總體的設計，幫助游客大體的了解岱廟的基本信息，更好的完成游覽觀光的功能。分為四個模塊,即操作介紹、查詢、推薦信息、進入3D景區。
采用了3D模型建立的技術，碰撞檢測技術，數據庫連接技術
性能：
A、可靠性
在從設計、開發到使用的全過程中，為提供滿足用戶使用要求的高有效性，軟件所采取了提高可靠性的一切措施、方法和活動。
B、可用性
本游戲具有很高的實用性，采取文本和語音同時輸出，適合于任何的年齡段人使用，界面簡潔，操作簡單，很容易上手，幫助用戶了解岱廟的知識，并且對岱廟有一個具體的了解。
C、可維護性
此維護是軟件周期的最后階段，維護人員可以簡單的對此軟件進行維護。
3．所用時間
3周，100多個小時
三． 評價
1． 技術方案評價
我們小組開發的是3D旅游咨詢員，具有一定的難度，我們通過開源游戲引擎直接控制，可以說是減少了一定的難度，使得軟件的實行更有可靠性和完善性。
軟件的需求分析階段嚴格按照先設計后實現的功能，需求由于進行了比較嚴格的分析和策劃，所以后期的實現相對而言，改動較少，提高了開發效率；
軟件的場景采取三維立體效果，體現了3D的主題，所以提供較好的視覺效果，是人們有身歷其境的感覺。
軟件采取文本和語音同時輸出，實現人機交互的功能，讓用戶比較強烈的感受軟件的好處。
3D場景可以加入音樂和實現全屏等具體的功能，增加了軟件的可實現性，完善了軟件的功能。
2．產品質量評價
整個軟件系統比較穩定，進行過比較嚴密的測試。
可用性：此游戲具有很好的實用效果，適合于任何的人用。
可維護性：此游戲系統比較穩定。維護是游戲軟件設計周期的最后階段。可轉移/轉換性：此軟件運用c++語言和irrlicht開源引擎，在windows系統的基礎上，實現軟件功能。軟件的移植性比較強，只要是裝了操作系統的pc機，都可以使用。
四． 總結
通過這次大賽，培養了我們的創新精神，競爭意識，克服困難、堅持不懈的毅力以及團隊合作精神。開發的這款軟件，從設計到開發都經過了細致摸索和推敲和實地考察，做到了作品的原創性。這是一款獨立研發且具有成品性質的軟件，是我們大家共同努力的結果。游戲開發中，大家的能力，諸如大家的合作，個人的協作能力，策劃能力，以及時間觀念都有一定的提高。希望軟件的設計能給大家耳目一新的感覺，豐富多彩的視聽效果，能給用戶以視聽享受，希望成為廣受用戶的歡迎。
通過參加“齊魯軟件設計大賽”，得到了許多經驗和教訓：
一個成功的設計應該是以用戶為出發點，始終在考慮“用戶需要什么”， 軟件策劃并不是典型的用戶，我們不是真正的旅游觀光者，但是我們也進行旅游，我們制作的游戲是游客使用的，而不是自娛自樂用的。一味從自我考慮，只做符合自己的軟件，你會發現它的需求是如此的不足，功能有很大的缺失，最后會發現做出來的軟件連你自己的愿望。
篇二：軟件項目開發總結
隨著市場經濟的進一步完善及全球經濟一體化進程加快，企業面臨著激烈的市場競爭，企業內部、外部信息交流已成為企業發展、參與市場經濟競爭的迫切需要。企業引入先進的信息處理技術，增加信息共享程度，不僅提高了工作效率、降低成本，而且也提高企業管理的科學性和自動化程度。信息已成為企業生存與發展的基礎，在原有系統的基礎上，計算機中心于2003年開始加大信息管理系統的開發，已到年底，開發項目也基本上完成了；
為了總結03年所有開發項目的整個開發及管理過程，我們選取2個比較大的軟件項目來分析，項目為：出口技術支持網站管理系統、模具管理系統；在這兩個具有代表性的項目中，我們清晰的看到了我們在項目開發過程中的成果及所存在的不足和應該改進的地方，總的說來，設計開發的功能基本上達到了用戶需求的75%，用戶也能夠開始使用我們開發的系統來達到其管理目的。如出口技術網站為國外的客戶提供了方便快捷的了解到我們公司的空調產品及技術信息、空調配件信息等等。
模具管理系統最大程度的實現了模具信息的共享，各使用部門可以方便的查詢模具的位置、進度、狀態、申請單、試模、驗收、合格、模具的調撥、報廢等等信息；查詢模具的相關信息信息由原來的1-2天縮短為10分鐘之內。產品型號、零件圖號統一維護，規范管理，出錯比例大大下降。而且在更改零件圖號的情況下，基礎數據更改，其它相關文件的同一數據會隨之更改，減少系統維護量提高了生產部編制模具生產任務單的工作效率，縮短了模具制造任務傳遞時間，查詢新的開模單更方便快速，由原來的至少半天縮短為10分鐘之內匯總改模單情況由原來的多人每日手工填寫改進為階段一次匯總，時間僅須20分種左右，大大提高了效率。
模具臺賬能顯示所有的模具匯總及分配情況； 雖然相關項目基本上達到了預期的目的，但是，反思在整個項目的需求提出、項目評估、需求分析、項目計劃、總體設計、詳細設計、測試計劃、實施的各個環節，我們都有工作不足之處，特別是某些關鍵控制點上面，我們有一些失誤，當然，原因是多方面的，有果必有其因。下面我們從關鍵控制點上面來分析我們在項目開發過程中存在的問題、原因分析及改進措施：
一、從用戶提出需求，到需求響應時間，我們需要9天時間，而需求評估完成時間需要15天左右，這就是我們存在的一些問題，導致需求響應時間及評估完成時間比較長的原因有如下幾方面：
(1)、由于計算機中心軟件開發人員不夠：各應用系統的支持人員及軟件開發人員加起來才8個，公司各子應用系統有幾十個，ERP的各個子系統及模塊就有將近20個，一個員工要支持5到6個功能子系統的維護；
(2)、分工不明確：軟件開發人員往往身兼數職，跨多個職能領域，應用用戶習慣找誰就認定那個人，什么事都找該員工；工作效率就相對低下；
二、關鍵用戶訪談率及關鍵用戶對需求的認同率都比較低，關鍵用戶訪談率只有70%，而關鍵用戶對需求的認同率只有68%；為什么會有這樣的結果了，分析原因如下：
(1)、由于計算機中心人員緊張：有時沒有辦法訪談所有的關鍵用戶，只能找幾個評估時認為特關鍵的用戶；
(2)、被訪談用戶原因：由于被訪談用戶事情太多，往往在提出需求以后，抽不出時間來接受訪談；另外有些用戶只局限于本部門或者本崗位來考慮問題，不愿意從公司層面或者大局來考慮；
(3)、用戶不重視：有些需求是由于用戶部門領導要求，跟得比較緊，但是如果部門領導沒有跟得緊的情況下，用戶就不那么急了，就算立了項，也不能很好的配合；
(4)、軟件需求分析人員原因：由于需求分析人員經驗不足，導致需求不夠明確，不能了解到用戶需求背后的真正目的；
三、設計功能滿足率比較低，只有75%，功能點BUG數比較多，每個功能模塊平均的BUG數有15個之多，函數注釋率只有10%左右，各功能點的測試覆蓋率只有40%，分析原因如下：
(1)、用戶需求不明確：有些用戶在接受訪談時說的需求，及在需求確認時都沒有問題，但是到軟件功能設計出來以后，卻完全不是這么回事，用戶就會解釋說當時沒想清楚；
(2)、軟件開發工具的原因：軟件開發人員使用的開發工具不夠實用，很多工發工具能檢查出來的BUG，沒有辦法檢查出來，需要開發人員自已檢查；
(3)、軟件開發人員的原因：由于軟件人員緊張，項目任務多，交期短，所以在開發時，沒有多少時間去寫程序代碼的注釋，況且有些開發人員也根本沒有注釋的習慣，沒有多少時間去完整的測試各個功能點；把測試的任務有時就直接交給用戶了；
四、系統架構變更次數過多，一個項目平均下來變更6次之多，原因如下：
(1)、系統設計人員的原因：由于系統設計人員在架構設計時，沒有考慮到系統架構的靈活性；不易于擴展；一旦用戶的需求有變化，系統架構就必須重新修改；
(2)、用戶需求變更太頻繁：由于用戶的需求很隨意變更的，加大了系統設計的難度，導致了系統架構變更；
五、項目的按時完成率比較低，平均下來只有60%，分析原因如下：
(1)、用戶需求變更太頻繁：由于用戶需求變更太隨意，太頻繁，導致有些開發工作完成，又必須推倒重來，做了很多無用工作；另外有些用戶只局限于本部門或者本崗位來考慮問題，不愿意從公司層面或者大局來考慮；造成重復工作，重復設計；
(2)、軟件開發人員的原因：由于軟件開發人員不夠，項目多，任務緊，一個人身兼數職，也是造成軟件開發項目推遲的直接原因；另外，軟件開發人員專業技術水平不夠，有些功能開發要花太多的時間去研究，尋找解決方案，也導致了項目的延遲；
(3)、系統架構變更太多：導致有些程序開發工作無用，必須重新開發；
(4)、軟件需求分析設計人員的原因：由于設計的不合理，分析用戶需求不夠透徹和全面，架構設計不合理，導致軟件開發變更及錯誤多，也導致了軟件項目的開發延遲；
(5)、軟件開發工具及開發方法落后：由于軟件開發人員沒有太多的時間去研究使用新的，先進的開發工具，也沒有太多時間去學習新的開發方法，導致軟件的開發速度慢，開發出來的程序BUG多，程序沒有多少可重用性，也導致了軟件項目的開發延遲；
綜上所述，為了配合公司的發展，滿足公司對信息化建設的要求，順利實現計算機中心04年目標，我們必須針對軟件開發項目中存在的問題采購行之有效的改進方案，計劃改進措施提議分為內部及外部：
六、內部的改進措施提議如下：
1、增加人員配置，解決人手嚴重不夠的問題；
2、明確分開，重新劃分業務小組；
3、明確崗位職責，細分軟件項目開發所需要的各個崗位；
4、制定崗位知識能力模型，對每個崗位要求的能力必須定義清楚，要求嚴格達標；不達標的必須重新培訓；做到合適的人在合適的位置做合適的事；
5、加強專業技能培訓；
6、加強軟件開發管理，培養團隊合作精神，加強軟件過程控制；
7、優化設計開發方法：加強設計標準化、模塊化；提高軟件開發效率；
8、加強業務培訓，更實際的了解業務需求；
七、外部的改進措施提議如下：
1、加強業務部門對系統了解；
2、培養用戶需求的分析能力；
3、加強與用戶的互動及雙向溝通，讓用戶參與到設計中來；
4、引導用戶的軟件需求，培養用戶從公司層面或者大局來提出需求；
篇三：軟件項目開發總結
1.引言
自助旅游的定義，簡單地講，就是吃、住、行、游、購、娛，基本上全由游客自己決定。自助旅游的新概念，也叫背包旅行，起源于發達國家，在英語里面叫“backpacker’s travel”，或“budget travel”，即背包旅行，省錢的旅行。
隨著中國進入第一次消費升級階段，居民可支配收入和消費水平不斷提高，發達地區居民旅游逐步從奢侈品蛻變為必需品。全球旅游業的散客化趨勢影響著中國，自助旅游席卷而來，給我國的一系列旅游產業及其相關制造產業帶來了挑戰。它的主要特點之一就是利用互聯網技術，旅游者通過網絡自由組團和選擇參加者，自由選擇路線等。
自助旅游最終實現需要一個漸進的過程，拓寬信息渠道、加強對自助旅游的研究和建立自助旅游的完善體系三個方面是很重要的，因為設計此旅游自助系統以期向計劃出行的人們提供豐富的旅游自助信息及其它相關信息，進一步完善現有的旅游自助體系。
1.1 編寫目的
隨著科學技術的高速發展，我們已步入數字化、網絡化的時代。旅游自助系統是一個管理信息系統，目標是使旅游資源信息化，方便旅游公司及游客便捷地得到需要的旅游信息。
1.2項目背景
隨著社會信息量的與日俱增，圖書作為主要的傳統信息載體，在某一層面上已不能滿足現代這樣一個知識爆炸時代對信息的需求，這也體現在人們的出行與旅行方面，人們不可能隨身帶一本厚厚的旅游百科全書去爬青藏高原；同時旅游管理部門希望避免由于筆誤或者記錄丟失等人工疏忽帶來的行政失誤，他們也需要更系統更嚴謹的管理手段，從而做到依法管理，有據可查；而對旅游公司而言，高效的經營管理手段是獲取最大利益的關鍵。在計算機日益普及的今天，一套行之有效的旅游自助管理系統，是大家最好的一個選擇，他是人們出行旅行的貼心小助手，是旅游公司負責盡心的大管家，是旅游管理部門安全可靠的檔案室與嚴謹的助理秘書。他將對人們的出行旅游方式產生時代性的影響。
旅游自助系統軟件是一套功能比較完善的數據管理軟件，具有數據操作方便高效迅速等優點。該軟件采用功能強大的數據庫軟件開發工具進行開發，具有很好的可移植性，可在應用范圍較廣的簡體中文、英文 Windows98/2000/ME/XP等操作系統上使用。除此以外，該軟件可通過訪問權限控制以及數據備份功能，確保數據的安全性。
建議開發軟件名稱：旅游自助系統 項目的提出者：軟件工程課程
開發者：艾菁、張虹、周軍、李驍、胡寶雷 用戶：旅游公司及游客
1.3 定義
該旅游自助系統是基于Internet/Intranet 及Web技術，建立以Browser/Server 為結構模式、以數據庫為后臺核心應用、以服務為目的信息平臺。
文檔中采用的專門術語的定義及縮略詞簡要如下： TTS：Travel Self-help System，旅游自助系統。
SQL（Structured Query Language）:結構化數據庫查詢語言 JSP：JAVA Server Page
1.4 參考資料
《軟件工程》 原書第八版 程成、陳霞譯 機械工業出版社 2007.3。 鄭人杰，殷人昆，陶永雷。《實用軟件工程》（第二版）。北京：清華大學出版社，1997。
金勇華，曲俊生。《JAVA網絡高級編程》。北京：人民郵電出版社，2001。 Borland Software Corporation。《JBUILDER培訓教程》北京：機械工業出版社，2002。
2.實際開發結果
2.1 產品
可包括列出各部分的程序名稱,源程序數(包括注釋行)或目標程序字節數及程序總計數量,存儲形式;產品文檔名稱等.
2.2 主要功能及性能
功能：
對旅游公司及旅游局輸入信息進行管理； 用戶的信息檢索； 性能：
數據庫的錄入； 后臺信息維護；
不同條件下的信息檢索；
旅游服務預約及預約是否成功的反饋； 輸出：
信息；（包括景點介紹、物理位置、開放時間、參觀費用等） 旅游線路信息；（包括日程安排、食宿交通、手續價格、聯系方式等） 預約結果反饋；（是否成功） 輸入：
旅游景點名稱； 旅游線路名稱；
旅游者自定義的查詢條件的搭配；（包括希望的時間安排、旅游的費用預算、行程的旅游景點等）
安全保密：
用戶退出系統時，自動清空查詢記錄；
2.3 運行環境要求
運行環境：
操作系統：Windows2000； 數據庫類型：SQL server。
篇四：軟件項目開發總結
一、軟件開發個人體會：
1. 軟件領域中的知識在于積累。
2. 做軟件開發，就類似算數學題和世界杯足球賽一樣：重在結果，而不在乎過程。
3. 軟件服務于人類，軟件是在解決一些生活中的問題和錯誤，問題決定解決方案。
二、做軟件開發我覺得要明白：
1. 職業的樂趣：
(A) 用自己的智慧去創建新事物的快樂
(B) 開發對別人有用的東西
(C) 不斷學習來充實自己
2. 職業的苦惱:
(A) 總是追求完美
(B) 所有要實現的功能由他人而定
(C) 概念設計計是有趣的，但找Bug總是很苦惱的
三、在開發中遇到問題應該怎么去解決？
1. 不明白就多問，不要自已一直去琢磨。 一個問題如果30分鐘還沒有解決就應該考慮是不是問問別人。 一個問題在沒有用過3種以上的方法解決過就不要去問別人。 解決問題思路是關鍵：
相信問題總歸有解決的辦法，就算連技術上都沒法實現的問題，相信通過良好的溝通終究也會有解決的方法。
2. 解決問題的前提是：理解別人的意思，理解別人的需求，多溝通，及時給客戶反饋信息。
四、怎么樣才能提高自身的能力？
1. 程序員怎么樣進步最快？ － 理論結合實踐
2. 不要怕出錯，不怕遇到錯誤，有錯誤就有挑戰，這樣才可以進步，但不要讓同一個石頭
把你絆倒2次。
五、怎么樣才能做好軟件開發？
1. 首先要明白解決的問題是什么，理解問題，其次再決定怎么解決這個問題
2. 碰到很復雜的問題，我們就簡單想，把問題簡單化，細化到能夠實現為止
3. 出了問題，我們要先分析問題，然后知道引起問題的原因，最后并想出問題的解決辦法
4. 我們應該從2個方面去把握一個項目：從業務角度和項目的關鍵問題上去把握一個項目
(A) 從不同的系統場景
(B) 從不同的用戶角色（充當什么角色）
(C) 從不同的系統使用角度（擁有那些權限）
5. 其實我覺得開發人員說實在應該要比使用系統的人更了解系統需求，只有真正徹底的了
解了項目的業務需求，我們才能做真的做好這個項目
六、文檔的重要性
記得我當初剛開發項目的時候都是寫個大致的需求說明書，做一個E-R圖，畫幾個大致的數據流程圖，然后建立數據字典和表結構關系。 再接著搭建一個開發環境，配置幾臺服務器，劃分一下模塊，分工，我們就可以Coding了，一直到項目結束了，也沒有完整的設計文檔，更沒有完整的測試文檔，雖然這樣的確是很快的完成了Coding工作，感覺上好像節省了好多成本和開發時間，但后期的維護和Bug 就是經常出現的事。
小項目沒有文檔關系不大，但如果遇到一個大項目的時候，那這樣的開發方式就很有問題很危險的。
大項目沒有文檔： 首先維護就很麻煩，也很亂，寫的代碼，過幾天都不知道它是完成什么功能的了，其次系統的穩定性和可靠性也讓人懷疑，擴展性就不用說了。
七、我的收獲
A.程序員大多都不喜歡寫文檔,我們以前也是特討厭,記得以前都是系統開發完了，為了應付項目驗收，就匆匆忙忙的一組人在那里補文檔。在我們的思想里,所謂的文檔就是一些廢話,一句話硬是用十句話來代替的無聊透頂。
B.代碼風格要規范
以前做項目，我們都是不怎么去注意代碼風格和寫代碼的規范，都是稍微想一下就直接開始寫代碼了。注釋也很少用，總感覺我們自己寫的代碼，我們怎么會不知道它做了些什么事呢 ？總覺得我們自己寫的代碼我們怎么會不知道它是用來做什么的呢。一直都不相信這是個事實，但事實上，項目驗收后，系統剛開始使用的人少，也就不會出現潛在的錯誤，隨著時間的增加，久而久之，當大量用戶并發訪問的時候，系統的Bug 就暴漏出來了，那時你再用熟悉的Eclipse打開整個項目的源碼時，再去看自己寫的代碼的時候，真的發現，我們定義的這個變量名是什么意思啊 ？ 我們的這個Flag 是用來判斷什么的啊 ？我們的if（）中條件不知道是判斷什么？ Function （） 也忘記是什么功能了？ 想想好可怕啊。 難道真的都忘記了嗎 ？回答是肯定的： 真的忘了。
C.心得體會:
通過做該網盤項目，在這2年的鍛煉中，我們才真的體會到，良好的文檔是正規研發流程中非常重要的環節,一個好的程序是先寫好設計文檔再進行編程的，在設計文檔的指導下，才能寫出安全的代碼。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，就容易混亂.
剛開始我們還很不習慣這一系列的編程風格，很多的規范，尤其是命名，方法和注釋，都有這著很多限制，讓我們覺得真羅唆，寫個程序完成功能不就可以了嗎，明明1小時做完的事情非得讓人用3、4個小時去做，我們現在真的明白這樣做的好處了，我們已經習慣這樣的編程風格了，這也養成了我們的一個編程習慣了，深有體會啊。
最忙的時候就是我們成長和收獲最多的時候。
八、網盤項目開發的最大體會
我們覺得項目開發的開始時候，應該由項目負責人很好的對項目是什么項目，具體大概做什么事情，是誰提出來的，目的是解決什么問題，以及里面用到的很多專有名詞做個細致的說明，而不是從一開始就分幾本式樣書，給個靜態Html 的Demo看看，然后搭建好開發環境就按照式樣設計書來開發。
九、軟件測試（單體測試和連接測試）
我們首先認為，編寫程序的時候不要想出了問題再解決，而是要想如何不會出現問題，要根據經驗來預測可能出現的問題，然后避免出現。
測試，說的直接點就是給軟件找錯誤。
很多人認為發現錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上我們不這么認為。
我們覺得對開發人員來說，我們要把測試出來的Bug都應該做個分析，知道錯的原因之后，我們就應該在下個項目中防止類似的錯誤發生，而真正來提高我們開發的效率。