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