篇一：軟件項目開發總結
一． 引言
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都應該做個分析，知道錯的原因之後，我們就應該在下個項目中防止類似的錯誤發生，而真正來提高我們開發的效率。