總結，漢語詞語，讀音為zǒng jié，意思是總地歸結， 以下是為大家整理的關于軟件項目總結報告6篇 , 供大家參考選擇。
軟件項目總結報告6篇
第一篇: 軟件項目總結報告
軟件項目實施總結報告
篇一：軟件項目實施報告模板 XXX項目實施報告 項目名稱： 項目負責人： 填報時間： 目錄 （一）項目實施概況 ------------------------------------------------------ 2 （二）系統實施物理拓撲圖 ---------------------------------------------- 3 （三）系統功能簡介 ------------------------------------------------------ 4 （四）安裝操作 ----------------------------------------------------------- 5 （五）項目實施工作量統計 ---------------------------------------------- 6 （六）下次實施安排計劃 ------------------------------------------------- 7 （七）實施過程中發現問題、常見故障及解決方法 ------------------- 7 （八）其他實施說明 ------------------------------------------------------ 7 （一）項目實施概況 （二）系統實施物理拓撲圖 （三）系統功能簡介 （四）安裝操作 篇二：軟件系統項目總結 “題庫系統”項目分析 XXXXXX 項目描述： 這是我自身參與的一個項目。XXXXX學院的學生規模從最初的千人級迅速增加到近十萬人級。在學生人數不多的情況下，學生作業及在線考試可以通過手工方式完成。學生規模快速增長后，手工方式周期長、容易出錯、也不易統計。如何快捷方便地讓學生完成作業及在線，以及如何快捷方便地批改作業及在線考試題，迅速反饋給學生，提在技術的首要日程。“題庫系統”項目就是基于以上背景，是將常規的書面作業及考試系統化成絡化作業及考試，從而大幅縮短學生作業及考試到教師批改作業及考試的周期，也方便學生和老師隨時隨地完成作業及考試任務，也方便管理人員對組織的作業級考試進行統計分析，提供下一次作業考試的決策。“題庫系統”項目已經上線，基本上完成了預計目標。但上線后經過幾次大規模的修改，才使用戶較為滿意。 項目分析： 第一、清楚的需求 1) 業務部門（需求方）因為IT知識缺乏，對自己需要什么樣的題庫系統沒有明確的概念，走一步算一步，甚至于今天的需求跟昨天的需求是南轅北轍的。 2) 業務部門的業務流程不是規范的，固化的，在系統準備上線后，業務流程還有變化。 3) 未能與業務部門進行充分有效地溝通、引導業務部門清楚具體有效的梳理需求。 第二、高層管理者的支持 高層領導對信息系統的不理解，對信息化的作用沒有深刻的認識。對技術部門的支持不夠，導致在項目需求界定、項目開發、實施上線過程中業務部門占了主導地位。 第三、項目計劃 1) 工作量估算過少 ，由于業務部門和高層領導的壓力在工數估算上予以妥協。 趕工趕進度，項目節點項目質量相應下降。 2) 項目組織過小 ，人手不足，項目組人員不夠造成以下問題： 工作分擔（責任范圍）不明確，工作分割結構與項目組織結構不明確或者不相對應，各成員之間的接口不明確，導致有一些工作根本無人負責。 每個開發階段的提交結果定義不明確，中間結果是否已經完成，完成了多少模糊不清，結果是到了項目后期堆積了大量工作。 開發中沒時間去按指定里程碑或檢查點檢查完成情況。 篇三：軟件項目實施總結報告 實施總結報告 項目名稱：北京市順義區第一中學數字校園建設政府采購項目 合同編號：TC140V6A6 本表一式三份，承建單位、監理單位、建設單位各一份 篇四：軟件項目總結 本項目從今年3月份啟動，到系統上線一共歷經7個月的時間，綜合項目歷程，本人有如下感想： (一) 調研階段。 1. 調研的時間充分是系統設計成功的關鍵。 本系統的前期調研工作一共用了一個月的時間，在這一個月的時間內，項目組成員每天都與客戶進行詳細的調研工作，調研工作的詳細使得系統在設計階段沒有發生重大的邏輯錯誤。 2. 調研工作要詳細，耐心。由于項目在售前階段已經進行過粗略的調研，在調研時對于有些問題客戶會顯得不耐煩，對于這種情況，要耐心與客戶做好溝通，讓客戶理解我們調研工作的重要性。 (二) 設計階段。 1. 數據庫設計是極其重要的一個環節，要特別重視，數據庫設計完成要進行細致的論證和審核。本系統在這方面應該有所教訓，在前期數據庫設計完成之后，論證得不夠詳細，導致在編程階段走了很多彎路，不得不修改數據庫設計。一定要在滿足關系范式的前提下做設計，不要隨便為了一時便利而引入表，要在遇到問題時審視原來的設計。 (三) 編碼階段。 1. 本項目部分設計工作與編碼是同時進行的，造成了邊設計邊編碼的情況，影響了開發的效率，所以系統設計工作時間一定要充分，編碼工作不要急于提前。 2. 每個模塊的需求都是不同的，不能考慮“批量生產”模塊。編碼初期認為編寫好了一個模塊，其它模塊都可以利用，會省很多時間，結果是每個模塊的需求都是有差別的，利用批量復制的代碼會造成邏輯混亂，并會含有潛在缺陷，往往會事倍功半。 (四) 測試階段。 1. 測試計劃一定要詳細，客戶方負責人也就可以按計劃安排各部門人員做測試，計劃要考慮提前性，因為一些不確定性的問題（例如客戶本身的突發事件）會使計劃延遲，并且要安排好備選的測試計劃，如遇突發情況，就可安排另外的測試。本系統的兩次測試都是由于有較為詳細的測試計劃使得現場測試工作有條不紊。 2. 與客戶確定的需求要有字為證，在現場測試過程中，客戶會提一些需求，對于這種情況，我們每天都整理到《測試處理結果表中》，并且每天都要給客戶發郵件確認。這樣，對于這樣的需求我們就能夠保證開發的準確性。而且客戶如果再提出不合理的需求我們就能夠做到有據可查。 (五) 其它。 1. 定期向客戶方領導做項目進度報告。項目開工后，我們每半月都向**部**經理和**部**經理做進度匯報，使得客戶方領導很認可我們的工作，在推進項目進展方面給我們很大的支持。 2. 始終把客戶方關鍵用戶作為項目組的成員來看待，遇到問題，可讓他們協助做解決方案，這樣不但增加了關鍵用戶的成就感，而且在遇到問題的時候客戶會主動幫我們解決問題，而不是急著催促我們解決問題。 3. 項目組成員要密切配合，肯吃苦耐勞。本次由于項目時間較緊，遇到難以解決的問題，項目組成員都是主動想盡辦法以最快的時間解決，保證了項目的按期上線。 篇五：XX年軟件開發項目總結報告 XX年軟件開發項目總結報告 隨著市場經濟的進一步完善及全球經濟一體化進程加快，企業面臨著激烈的市場競爭，企業內部、外部信息交流已成為企業發展、參與市場經濟競爭的迫切需要。企業引入先進的信息處理技術，增加信息共享程度，不僅提高了工作效率、降低成本，而且也提高企業管理的科學性和自動化程度。信息已成為企業生存與發展的基礎，在原有系統的基礎上，計算機中心于XX年開始加大信息管理系統的開發，已到年底，開發項目也基本上完成了； 為了總結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、項目概述 簡要介紹項目的目標及總體完成情況。（不超過500字） 2、項目技術實施情況 詳細介紹項目關鍵技術的研究過程，解決的關鍵技術難點及有關試驗和檢測情況。 3、項目經費到位及使用情況 （1）項目總體經費到位情況 （2）科技經費使用情況（3）自籌經費到位及使用情況 注：科技專項經費的支出應符合《長沙市科技發展專項資金及科技計劃項目管理辦法》中第二十七條的相關規定。 4、項目合同指標完成情況 （1）技術指標完成情況對照表 （2）經濟指標完成情況對照表 （3）社會效益指標完成情況對照表 （4）預期成果完成情況對照表 （5）項目取得的其他成效 項目實施過程中取得的合同指標之外的其他成果，可以是新產品（新品種）、知識產權、科技成果鑒定、科技進步獎勵、行業資質、產品標準等。 篇七：軟件項目階段性總結報告 xxx Xxxxx 階段性總結報告 有限公司 xxxCO., LTD 項目階段性總結報告 1. 引言 a) 編寫目的 說明編寫這份項目開發總結報告的目的，指出預期的閱讀范圍。 b) 背景 本項目的名稱和所開發出來的軟件系統的名稱 此軟件的任務提出者、開發者、用戶及安裝此軟件的計算中心 c) 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組 d) 參考資料 列出要用到的參考資料，如： 本項目的已核準的計劃任務書或合同、上級機關的批文； 屬于本項目的其他已發表的文件； 本文件中各處所引用的文件、資料，包括所要用到的軟件開發標準。列出這些文件 的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源 2. 實際開發結果 a) 產品 說明最終制成的產品，包括： 程序系統中各個程序的名字，它們之間的層次關系，以千字節為單位的各個程序的 程序量、存儲媒體的形式和數量； 程序系統共有哪幾個版本，各自的版本號及它們之間的區別； 每個文件的名稱； 所建立的每個數據庫。如果開發中制訂過配置管理計劃，要同這個計劃相比較 b) 主要功能 逐項列出本軟件產品所實際具有的主要功能和性能，對照可行性研究報告、項目開發計劃、功能需求說明書的有關內容，說明原定的開發目標是達到了、未完全達到、或超過了 c) 基本流程 用圖給出本程序系統的實際的基本的處理流程 d) 進度 列出原定計劃進度與實際進度的對比，明確說明，實際進度是提前了、還是延遲了，分析主要原因 e) 費用 列出原定計劃費用與實際支出費用的對比，包括： 工時，以人月為單位，并按不同級別統計 計算機的使用時間，區別CPU時間及其他設備時間； 物料消耗、出差費等其他支出。 明確說明，經費是超出了、還是節余了，分析其主要原因 3. 開發工作評價 a) 對生產效率評價 給出實際生產效率，包括： 程序的平均生產效率，即每人月生產的行數； 文件的平均生產效率，即每人月生產的千字數； 并列出原訂計劃數作為對比 b) 對產品質量評價 說明在測試中檢查出來的程序編制中的錯誤發生率， 即每干條指令（或語句）中的錯誤指令數（或語句數） 。如果開發中制訂過質量保證計劃或配置管理計劃，要同這些計劃相比較 c) 對技術方法評價 給出對在開發中所使用的技術、方法、工具、手段的評價 d) 錯誤原因分析 給出對于開發中出現的錯誤的原因分析 4. 經驗與教訓 出從這項開發工作中所得到的最主要的經驗與教訓及對今后的項目開發工作的建議 篇八：軟件項目總結報告7p
第二篇: 軟件項目總結報告
xxx系統
項目開發總結報告
任務分配：
缺陷上傳，基本信息維護（,,,）
分配缺陷（,,）
解決缺陷，測試缺陷（,,）
登錄，權限設置，統計圖繪制（,,）
2.2、基本流程分析……………………………………………………………………………4
3.1. 主要功能及性能…………………………………………………………………………3
3.2. 數據庫結構及設計………………………………………………………………………4
3.1、開發進度…………………………………………………………………………………4
5、參考文獻………………………………………………………………………………………6
1引言1.1開發目的隨著社會的發展與進步，計算機的應用已深入到了社會的各個領域，軟件的作用和影響也越來越廣泛。同時，軟件出錯的范圍和可能性也越來越大。如何有效的進行軟件錯誤的跟蹤、控制和管理，已成為提高軟件質量，保證系統正常運行的一個重要手段。
BUG管理系統的研發與應用，是為控制和減輕潛在的不利因素對軟件項目的影響而采取的一項活動。它用于集中管理和控制軟件測試過程中發現的錯誤，并進行版本控制。通過該系統，將幫助我們更好的收集、跟蹤、反饋軟件系統在測試、運行過程中的錯誤和問題。缺陷管理系統作為項目管理的一個重要方法和手段，能有效的幫助人們建立科學的、規范化的項目管理機制。
1.2開發背景在WINDOWS操作系統下運行。使用Microsoft Visual Studio 2005開發環境和SQL數據庫進行編譯和運行。
2系統分析BUG管理信息系統是開學初老師給我們提出的項目，由于我們對這個項目很陌生，所以分析階段持續了長達一個多月的時間，先后改進了6個版本。設計了系統的業務流程圖，數據流程圖以及數據項和數據流。
2.1需求分析一個BUG管理系統，需要實現幾部分的功能：
1、缺陷上傳，當缺陷被發現后，測試人員可以通過系統進行提交、記錄。
2、缺陷錄入系統后，項目經理應該可以通過系統進行瀏覽并進行分配。
3、項目經理將缺陷問題報告通過系統轉交給開發人員，開發人員可以通過系統知道自己負責的修正的缺陷問題報告。
4、缺陷問題的修正處理，當開發人員修復缺陷后，可以通過系統，通知測試人員缺陷已修復。
5、對于開發人員無法完成的修改任務，開發人員可以拒絕后并將缺陷問題返回至項目經理重新處理。
6、測試人員對開發人員修復的缺陷進行測試，對于沒有修復成功的缺陷重新返回給開發人員修復，對于修復成功的缺陷則關閉存入檔案。
2.2基本流程分析
通過管理信息系統的自頂向下分析和設計，自底向上逐步實施的思路，我們先將整個軟件bug管理系統分為四個業務處理功能：上傳、分配、修改、測試；且四個業務處理功能涉及到了測試人員、項目經理、開發人員三個業務處理單位。詳細的業務處理過程如下：
2.2.1上傳缺陷
2.2.2分配缺陷
2.2.3解決缺陷
2.2.4缺陷測試
word/media/image5.gif
3系統設計設計階段是在分析階段成熟之后進行的，真正進入設計階段畫數據流程圖的過程中遇到了很多問題，同時也發現了之前分析階段考慮的很多不足之處。先后改進了3個版本。繪制了SC圖，設計了數據庫表結構。
3.1基本功能3.1.1登錄功能
實現與服務器的鏈接配置，在用戶的服務器信息發生變動時可以進入配置，配置一次即可，以后可以直接登錄使用。根據用戶輸入的用戶名密碼，判斷是否有權進入，若無權，判斷是因為用戶名不存在，還是因為密碼輸錯。登錄成功后，獲取用戶的權限，進入主菜單后顯示相應權限的菜單項。不擁有權限的菜單項不顯示。
3.1.2基本信息維護功能
對基本信息如環境配置，人員信息，優先級別，嚴重級別，模塊，角色信息進行管理。
3.1.3權限管理功能
當模塊、權限或者角色發生變動時，可以根據不同的角色進行相關模塊的授權與釋權。權限設置模塊的操作權歸管理員所有。
3.1.4報表統計功能
根據不同的項目繪制某個項目在某個時間段發現的BUG數量的柱狀圖。
3.2數據庫結構及設計項目組表（pro_group）：
項目表（project）：
權限表（authority）：
角色表（roles）：
測試環境表（environment）：
嚴重級別表（severity_level）：
優先級別表（priority_level）：
分配表（share）：
缺陷信息表（bugs）：
用戶表（users）：
4系統實現4.1開發進度4.2實現過程的錯誤分析
1、開始上傳界面環境、項目、嚴重級別等選擇時顯示的是編號，后來發現，編號對于用戶來說并不懂其中的含義，需轉換成具體的名稱。所以將其關聯到對應的環境表，項目表，嚴重級別表等，讓用戶可讀取到其名稱。
2、由于編號都是“0001”，“0002”這樣以“0”開頭的字符串，而不是數字，不能直接自增。通過網上查了相關資料，參考了其他人的代碼，發現可以用right函數，選擇右面的非空位，然后再加上“1”，編寫這樣的存儲過程，完成編號的自增。還有老師要求數據庫中的表得是英文，而前臺的表得是中文，最開始我們不懂在C#環境下如何把列名從英文轉換成中文，后來發現拉數據源后，可在其SQL的“select”語句中，添加“as”字段，將其列名轉化成漢語，顯示在dbgrild中。
3、在任務分配界面上忽略了一些細節，查詢缺陷時，沒有顯示項目經理要分配的所有項目，當項目經理分配完一個項目后，表中則刪除掉一條，這樣看起來更加直觀。而在這次專周所做的實驗，剛開始并沒有考慮到這些，僅以個人的觀點去看待，沒有以項目經理的角度去，所以整個界面還不夠完善。由于運用到臨時表，剛開始分配的缺陷保存在臨時表中時，如果再次選擇跟臨時表中一樣的缺陷時，依然可以實行，為了解決這個問題，在分配的存儲過程中又加以修改，將查詢選中的缺陷是否存在在臨時表中，如果存在則出現提示框，保證缺陷分配給指定的人員。
4、解決缺陷和缺陷測試的實現過程中時間數據考慮的不周，忽略了時間的設定，應該限制修改時間遲于分配時間；bug描述、解決方案不應該用textbox控件，信息查看不方便；用于選擇查詢的類型太少。
5、繪制統計圖模塊因為以前都沒有接觸過，所以這方面的知識完全是全新的，通過學習后知道ZedGraphClass控件在繪制二位柱狀圖時需要獲得兩列多行的數據，理清思路后使用臨時表暫時儲存查詢統計的數值，在對臨時表進行查詢，將結果返回給控件進行顯示。在操作過程中在時間的換算上不知道該如何更進，通過百度，知道時間更進只需進行簡單的加減運算就可以達到效果了。
6、在授權模塊中，由于讀取角色的字符串后使用str.length獲得字符串的長度，通過長度進行循環訪問authority表，但是循環結果與預期的并不一樣，后來通過查找才發現原來str.length獲得的字符串長度是整個字段長度，而不是實際存放的字符串長度，于是通過增加if語句進行控制循環。
4.3后期完善1、在答辯前，密碼是通過自定義的函數實現加密，經過分析發現這種加密方式并不安全，改換成使用SQL自帶的加密函數pwdencrypt()進行加密，在進行登錄的密碼匹配時使用pwdcompare()函數。在操作上更加簡便，而且加密效果更加安全。
2、在對表進行增刪改查時，很多字段用戶是不能更改的。例如編號等主碼，這時應該將其用來顯示的text的屬性改成只讀，而不能是可讀可寫。還有，在上傳時，沒添加一個bug，其text和combobox等填寫框都應該清空，這樣可以盡可能的減少誤操作。否則用戶可能添加只有編號不同，內容卻相同的bug。
5參考文獻6小組總結為期一周的專周結束了，在答辯過后，我們小組開了小會，討論了這次專周的收獲和不足。總的來說這次的專周完成得還是比較順利的，雖然BUG管理系統的開發對我們來說是比較陌生的，但是由于一學期的分析設計，我們掌握了業務流程，數據流程，以及模塊劃分的思路，所以大家在開發過程中整體流程和目的都比較明確。
不過有一點，由于在專周之前是考試周，所以大家都沒有對專周進行提前研究，項目計劃沒有很詳細的安排出來。在第一天專周的時候還是比較亂的，后面及時的設計了項目計劃，表結構，分配了各個成員的任務。后期因為命名的規范不是很嚴格，導致后來代碼拼接以及結尾工作時遇到了一些問題，消耗了部分時間。不過大家一起交流討論，問題也很順利的得到了解決。以后在進行系統開發的時候會更加的注意前期項目開發計劃的制定，以及制定并嚴格的執行代碼規范。
這是第一次以小組的形式進行的專周，在開發過程中不僅加深了我們對上學期管理信息系統這門課所學知識的理解和認識，同時也加強了我們的團隊協同合作能力，通過大家的一起交流也開拓了思路。希望以后可以有更多這種小組合作的機會，
Welcome To
Download !!!
歡迎您的下載，資料僅供參考！
第三篇: 軟件項目總結報告
附件
產品研制技術總結報告（參考提綱）
一、 產品研制的目的和意義：從產品與國家產業、技術、行業政策的相符性，對促進產品結構與產業結構優化升級的重要性，對主要應用領域需求的迫切性來闡述。
二、 產品研制的技術路線：產品研制過程中采取了哪些技術原理、方法、工藝等內容，以獲取該產品的核心技術。切不用產品加工制作過程中，具體的工藝步驟或流程順序等工藝路線來描述。
三、 產品的功能特點及主要技術性能指標（列表并說明）
四、 技術關鍵及解決途徑
1、技術關鍵
2、解決途徑
五、 產品的創新性和先進性
1、 產品的創新性（應說明產品在新設計構思、新技術、新結構、新材質、新工藝、新配方等某幾個方面的創新點、創新程度（首創、重大改進、較大改進）以及創新范圍（國際首次或首批，國內首次或首批、本市首次或首批）；
2、 先進性（指與同類典型產品比較說明時，首先要同國內同類先進產品比較；若屬國際領先或國際先進，還需與國外同類典型產品相比較。）同國內、外同類典型產品比較需列表提供企業名稱、國別和公司及主要技術性能指標比較。
六、 產品知識產權狀況
1、專指該產品的專利、軟件著作權等狀況（列表）；進展情況欄填受理或授權，專利范圍欄填中國或國際專利；
2、技術標準狀況：采用何種標準，是否是標準的制訂者，標準的先進性在哪里？
3、產品商標、品牌狀況。
七、結論
通過上面6個方面的論述扼要的總結產品創新的經驗，并從企業管理創新的角度出發，進一步提高產品質量和性能，應所采取哪些措施。
八、 產品主要研制人員表
單位: （蓋章）
第四篇: 軟件項目總結報告
xxxxx服務平臺
總結報告
xxxx（北京）科技有限公司
2017年12月
一引言1.1 編寫目的XXX有限公司（以下簡稱“xxxx”）2017年4月25日接受xxxx（以下簡稱“xxxxx”）委托對三個微信公眾號進行升級改造，至今三個公眾號的開發任務已經完美完成。寫此項目總結報告，首先是為了向xxxx展示xxxx的開發成果，其次是對雙方合作工程的一個總結，讓我們在以后的合作中能更加順利、更加完美的完成委托方交給我們的任務。
1.2 背景項目名稱：XXXX創新創業服務平臺
系統名稱：XXXX服務管理平臺
委托方：
承建方：
二 開發成果展示2.1 XXXXXX開發成果功能主要包括：
功能模塊
功能名稱
功能描述
信息發布
文章管理
管理平臺對微信公眾號上展示的文章進行管理，可對文章進行增刪改查。發布后即可在公眾號中進行查閱
文章分類
對文章分類進行維護，創建文章時選擇分類，公眾號中按照分類類別進行展示。
公眾號群發
已發布的文章，可選擇在公眾號中推送給用戶，可多條推送。
活動管理
活動管理
該功能對活動進行增、刪、改、查，審核活動報名人員是否能夠參見此次活動。
活動報名項管理
在創建活動的時候選擇用戶需要填寫的報名項，該功能是對報名項進行動態的維護。
活動出勤統計
按照時間段內所有活動的出勤統計，可對查詢出的活動列表導出excle表格。
問卷調查
問卷管理
該功能對問卷進行增、刪、改、查，結束后可查看調查結果，能夠導出excle表格。
項目申報
項目內容
對可申報的項目進行增、刪、改、查維護，發布后在公眾號中可查看。
留言管理
留言列表
可設定在一定時間段查詢平臺留言，對留言進行回復后可在公眾號中進行展示，可刪除留言。
基礎信息
會員管理
會員管理實現對登錄系統后臺的用戶的用戶名，密碼，部門，聯系方式以及其他屬性的管理功能，密碼采用MD5方式進行加密，以保證較高的安全性。對注冊會員進行審核。
會員導入
下載導入模板后，根據模板填寫導入會員信息，進行批量導入。
參數設定
對各部門聯系電話，人才框架圖進行維護。
2.2 XXXX功能模塊
功能名稱
功能描述
信息發布
文章管理
管理平臺對微信公眾號上展示的文章進行管理，可對文章進行增刪改查。發布后即可在公眾號中進行查閱
文章分類
對文章分類進行維護，創建文章時選擇分類，公眾號中按照分類類別進行展示。
公眾號群發
已發布的文章，可選擇在公眾號中推送給用戶，可多條推送。
活動管理
活動管理
該功能對活動進行增、刪、改、查，審核活動報名人員是否能夠參見此次活動。
活動報名項管理
在創建活動的時候選擇用戶需要填寫的報名項，該功能是對報名項進行動態的維護。
活動出勤統計
按照時間段內所有活動的出勤統計，可對查詢出的活動列表導出excle表格。
年度活動學時統計
按照年度統計年度內活動學時，可導出
單位活動學時統計
按照單位統計一定時間段內各活動學時，可導出
學員活動學時統計
按照學員統計一定時間段內各活動學時，可導出
考試管理
考試管理
創建關聯活動的考試，考試結束后可進行查看成績、發布成績。
題庫管理
該功能滿足對考試題庫的增、刪、改、查，可進行批量導入試題
試題管理
對題庫中試題進行增、刪、改、查維護。
問卷調查
問卷管理
該功能對問卷進行增、刪、改、查，結束后可查看調查結果，能夠導出excle表格。
項目申報
項目內容
對可申報的項目進行增、刪、改、查維護，發布后在公眾號中可查看。
留言管理
留言列表
可設定在一定時間段查詢平臺留言，對留言進行回復后可在公眾號中進行展示，可刪除留言。
基礎信息
單位管理
可對科委各單位進行增、刪、改、查維護。
會員管理
會員管理實現對登錄系統后臺的用戶的用戶名，密碼，部門，聯系方式以及其他屬性的管理功能，密碼采用MD5方式進行加密，以保證較高的安全性。對注冊會員進行審核。
會員導入
下載導入模板后，根據模板填寫導入會員信息，進行批量導入。
參數設定
對各部門聯系電話，人才框架圖進行維護。
2.3XXXXXXX功能模塊
功能名稱
功能描述
信息發布
文章管理
管理平臺對微信公眾號上展示的文章進行管理，可對文章進行增刪改查。發布后即可在公眾號中進行查閱
文章分類
對文章分類進行維護，創建文章時選擇分類，公眾號中按照分類類別進行展示。
公眾號群發
已發布的文章，可選擇在公眾號中推送給用戶，可多條推送。
活動管理
活動管理
該功能對活動進行增、刪、改、查，審核活動報名人員是否能夠參見此次活動。
活動報名項管理
在創建活動的時候選擇用戶需要填寫的報名項，該功能是對報名項進行動態的維護。
活動出勤統計
按照時間段內所有活動的出勤統計，可對查詢出的活動列表導出excle表格。
年度活動學時統計
按照年度統計年度內活動學時，可導出
單位活動學時統計
按照單位統計一定時間段內各活動學時，可導出
學員活動學時統計
按照學員統計一定時間段內各活動學時，可導出
考試管理
考試管理
創建關聯活動的考試，考試結束后可進行查看成績、發布成績。
題庫管理
該功能滿足對考試題庫的增、刪、改、查，可進行批量導入試題
試題管理
對題庫中試題進行增、刪、改、查維護。
問卷調查
問卷管理
該功能對問卷進行增、刪、改、查，結束后可查看調查結果，能夠導出excle表格。
項目申報
項目內容
對可申報的項目進行增、刪、改、查維護，發布后在公眾號中可查看。
留言管理
留言列表
可設定在一定時間段查詢平臺留言，對留言進行回復后可在公眾號中進行展示，可刪除留言。
基礎信息
單位管理
可對科委各單位進行增、刪、改、查維護。
會員管理
會員管理實現對登錄系統后臺的用戶的用戶名，密碼，部門，聯系方式以及其他屬性的管理功能，密碼采用MD5方式進行加密，以保證較高的安全性。對注冊會員進行審核。
會員導入
下載導入模板后，根據模板填寫導入會員信息，進行批量導入。
參數設定
對各部門聯系電話，人才框架圖進行維護。
三 項目總結狀態3.1 進度進度按期完成，因本項目涉及三個公眾號不同的業務功能點較多，項目組克服了時間緊，任務重的不利因素，圓滿的完成了任務。
3.2 工作量因項目組人員有限，時間緊，工作量比較飽和，另外在開發的過程中存在需求的變更，無形中也增加了不少的工作量，實際的工作量超出了計劃預期，后通過趕工的方式趕上了進度。
3.3 成本工作量的增加使時間成本和人員成本都增加了不少，但尚在可控范圍內。
3.4 規模代碼和文檔規模總體上和計劃相當，略有增長。
3.5 風險風險主要是需求不明確或需求發生變更所引起的。在項目開發過程中，各部門隨著業務的變更，使得系統需求發生變更構成了一定的技術風險，這些風險在相當程度上影響了項目的進度。本項目的風險主要表現在：
? 需求不斷擴充和變更引起的風險
3.6 KPA狀態3.6.1 需求管理
需求管理的好壞往往決定這項目的成敗。項目開始時，項目組首先建立了需求管理計劃。經過和用戶的多次溝通和討論，獲取了用戶的需求，形成了需求基線，并納入了版本管理。在設計階段，用戶提出了一些需求方面的變更，經過項目組CCB討論，同意變更，于是項目組成員進行了相應變更。后經過CCB驗證，變更符合要求，變更有效。
3.6.2 里程碑評審
需求階段的評審：需求分析完成后，需求規格說明書提交到后，項目組相關專家進行了評審。
設計階段的評審：系統設計階段完成后，項目組組織有關專家對系統設計進行了評審。
測試階段的評審：系統開發階段完成后，項目測試組對系統進行了是否按照需求文檔進行開發的評審。
3.7 其他項目部署期間出現的問題，有些是程序的原因，有些則是數據的原因，在導入到數據庫之前，整理和規范數據是必要的前提。
四 經驗教訓原型是用來獲取需求的工具，但不應當成需求。
需求要盡可能的明確，不能把問題留到編碼階段。
在需求徹底了解的前提下，盡可能為設計和開發、測試多留時間，才不至于出現前松后緊的現象。
五 建議在項目需求調研階段應注重對用戶業務的理解，加強需求的把握，增強和用戶的溝通。項目設計開發階段要考慮增加必要的系統冗余，以保證日后的需求變更和系統升級。
六 結論項目總體比較成功，工期和成本控制上基本符合預期，開發過程中，團隊合作緊密，加班加點，有效保證了交付工期。雖然有很多不是很完美需要改進的地方，但相對于時間緊、任務急，人力有限的實際情況，項目的實施應該還算順利，這也要得益于客戶的積極配合。雖非盡善盡美，但經過用戶內測和一系列的優化，爭取能最大程度上讓客戶滿意。
第五篇: 軟件項目總結報告
軟件項目總結報告文
軟件項目總結報告文
1引言
1.1編寫目的
XXX公司業務管理系統的開發已經基本完成。寫此項目開發總結報告，以方便我們在以后的項目開發中來更好的實施項目的訂制開發; 讓我在今后的項目開發中有更多的有據的資料來規我們的開發過程和提高我們的開發效率,從而創造更多公司效益。
1.2背景
項目名稱：XXX業務管理系統
軟件名稱：XXX業務系統
客戶：XXX
用戶：XXX員工
1.3參考資料
項目開發文檔：
１．軟件開發數據模型：PDM_OperationSystem20070831.pdm
２．數據庫開發文檔： XXX業務管理系統數據庫設計說明書2.0.doc
３．軟件業務流程參考：XXX業務管理系統流程說明.doc
４．軟件使用手冊參考：XXX業務管理系統功能說明3.0.doc
５．軟件業務流程參考：XXX業務管理系統流程說明.doc
６．軟件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar ７．軟件中使用的安全Ikey驅動：Ikey Driver.rar
以上參考資料是截止2007-08-31是最新的資料文檔。如有修改，即使修改此處的參考文檔名稱。
2開發工作評價
2.1對生產效率的評價
１． 系統開發已歷時快１年的時間了
２． 開發的反復性比較多。
３． 對客戶的需求理解不是很透徹。
綜合以上，此項目的開發效率不是很高，相反有相當一定時間的浪費。
2.2對產品功能的評價
經過我們公司各位同事的共同努力協作，XXX業務管理系統已經很好的完成了客戶的業務流需求。經過對客戶使用過程的觀察，此項目開發的還是比較成功，但是還是存在著一些問題，造成這些問題的原因是多方面的。如：前期系統數據庫的設計缺陷和部分代碼的構建缺陷、客戶需求的理解上也存在一定問題，這就需要我們用一定的時間來維護客戶使用過程中提出的新問題和存在的debug。總的來說，此系統的功能開發還是一個比較成功的案例。
2.3對技術方法的總結
在此項目中使用到技術和工具：
１． 使用代碼生成器：使用代碼生成器 [動軟.Net代碼自動生成器],此工具在很大程度上提高了編碼效率，從而加快了項目的開發進程。在以后的項目中，我們要盡量的來使用一些類似的工具來在最短的時間完成工作。在今后的項目開發中，我們最好是能開發出適合自己的代碼生成工具，更大限度的節省開發周期和開發費用。
２． 使用數據庫建模工具；PowerDesigner 工具來建立系統數據庫模型，以方便程序員很好的理解業務流和掌握系統架構者的架構思想，更好的滿足客戶的功能需求。在今后的項目開發中，我們要更好的來完成系統的前期數據庫模型的建立，最大的來優化系統功能。
３． 使用第三方控件：此系統中使用了ComponentArt Web.UI 第三方控件。此控件在很大程度上滿足了客戶對軟件界面的需求，從而也給軟件的操作帶來了方便。本項目中只使用了ComponentArt Web.UI一種第三方控件，在今后的項目開發過程中，要繼續使用第三方的控件。這樣以來，無論是針對軟件界面的美觀性、友好性來說、易操作性而言，還是針對系統開發效率而言，這都是很好途徑。但需要意的是：在是使用第三方控件時，要謹慎的選擇一些網絡中的比較常見的第三方控件。
４． 使用自定義控件：此系統中使用了自定義控件(GhdGridView),此自定義控件可以很好的統一系統中的所有信息顯示表格樣式。如客戶對數據顯示樣式有什么新的意見，我就不需要修改每一個頁面的表格樣式，我們只需要修改GhdGridView控件的樣式，系統中的所有繼承自GhdGridView的表格樣式都可以改變。
５． 系統開發框架：此系統的框架使用的是簡單三層結構，此框架在開發一些中小軟件是比較實用的。但是我們要是可以開發出自己的框架，把一些通用的功能開發到框架中。這樣以來，在以后的系統開發中，針對系統中一些通用的功能就不需要再開發，從而也可以很好的提高我們的開發效率；減少很多維護費用。使我們的技術不斷的更加成熟。
６． 系統安全加密：此系統中針對客戶提出的系統安全問題，我們采用了Ikey加密硬件鑰匙來驗證客戶端登陸客戶的合法性，此Ikey鑰匙可以綁定到一個系統使用用戶，也可以讓多個用戶來使用一個加密鑰匙來驗證登陸系統的合法性。這樣以來，即使用戶的密碼不慎丟失，或者被不法人員取得（不法人員他也是無法登陸到我們的系統中來），這樣就最大的提高了我們系統的安全性。Ikey加密鑰匙是很好的加密B/S架構軟件的硬件工具，在以后的軟件安全方面可以借鑒。
3項目經驗總結
3.1簽定合同
一個項目的開發成敗或者說項目開發帶來效益的大小，在很大程度上是受項目合同簽定的影響的。往往，很多一部分公司與客戶簽定的項目合同都是很模糊的，也很難簽定的比較清楚，這樣以來就會導致在項目的開發后期，工作兩會越來越大，影響項目的竣工周期；而且，項目的開發費用一般是不會變的。這樣以來，我們就大大的降低了我們的開發效益。雖然需求圍很難簽定的明確，但是我們在簽定合同時，要盡量的去把合同功能邊界和添加新功能的條件簽定。
3.2開發團隊
在項目確立后，要盡快的建立起項目開發團隊。
項目團隊成員的團結合作、相互溝通是非常重要的，團隊成員之間要相互學習彼此的優點和技術，使團隊的能力不斷的提高。這樣，在項目的開發過程中，團隊才不會被難題困住不動。另外，團隊中要有一個項目負責人，這個人無論是在與客戶的溝通上，還是在技術上都要是很出眾的人，此項目負責人要能很好的溝通客戶與開發成員之間，以此來更好的理解客戶的功能需求。人的記憶力總是有限的，所以就要求開發團隊成員要盡量的書寫一些開發文檔，這些文檔往往是我們在項目開發后期要用到的可尋資料。項目團隊士氣是項目成功的一個因素,我們需要不斷的來培養我們的團隊氣勢，使我們的團隊不斷的壯大。
3.3需求的調研
在項目確立后，就到了需求調研分析階段。
１． 項目組對客戶的整體組織結構、公司有關人員的關系、職責等如果沒有一個很好、足夠的了解掌握，這樣項目組就無法很好的完整的整理到客戶的需求、或者說客戶真實的功能需求，如此以來我們就為自己埋下了地雷,影響項目的開發周期，這就要求我們要與客戶搞好無論是工作上的還是生活上的朋友關系,要深入的去了解客戶需求。
２． 我們要盡量的讓客戶也參與到項目的開發團隊中來，也就是說我們要使客
戶把自己也納入到項目的開發團隊中來，如此一來，我們掌握客戶需求的真實性、可靠性就會大大的提高,也就不會為項目的后期功能開發埋下陷阱
３． 在需求調研過程中，如果缺乏足夠用戶參與，這樣的需求調研也是失敗的。很多程序員不愿參與到客戶的需求調研中去，為什么呢？很簡單，與客戶溝通不如與代碼溝通容易有意思。盡管這樣，我們還是必須用足夠多的時間去和客戶進行溝通，了解他們真實的需求。很多用戶也是如此，他們自己也不愿意參與到項目的需求調研中來，為什么呢？需求調研有出去和朋友一塊爛漫對嗎。。。雖然現狀如此，我們還是要努力的使客戶參與到需求的調研中來。
４． 模糊需求，也就是模棱兩可是需求規格說明中最為可怕的問題。一是指諸多客戶對需求說明產生了不同的理解；一是指單個讀者能用不止一個方式來解釋某個需求說明。針對對這種情況，就要求我們的調研人員要能夠從多個角度來分析客戶的不同需求，整理出最終的需求與客戶確認，定出最終真實可靠的需求，我們絕不能憑借我們自己的單面理解來定立客戶的最終需求。
５． 在一個項目的開發中，文檔的書寫是極為中要的一項工作。因為，某些文檔就是我們在開發后期與客戶溝通的可尋依據、也是我們程序員在編碼過程中要用到的重要文檔。我們絕對不能認為，憑借我們的大腦來記錄所有的開發需求。。。；即使，你說你是天才，你要用你那顆愛因斯坦的大腦來記錄所有的開發需求，那也是不可能的，人的精力總是有限的。這就要求我們在需求調研中做好需求文檔的記錄和整理。
６． 需求調研工具選擇，客戶一般對圖形還是比較感興趣的，所以我們在調研過程中，我要盡量的采用圖形化界面來和客戶溝通需求。比如可以采用Rose工具，把客戶的意思轉換為用例圖、時序圖、協作圖、狀態圖、類圖等，使表達的意思更加直觀。這樣客戶會更快的進行問題的實質。
[ 軟件項目總結報告文]
第六篇: 軟件項目總結報告
軟件項目總結報告
XXXXXXXXXXXXXXXXXXXXXXX系統
項目總結報告
XXXXXXXXX
2017/7/27
1項目概要信息
XXXXXXXXXXXXXXXXXXXXXXX系統的技術團隊由11人組成，其中項目經理1人，需求分析師1人，UI設計師1人，開發人員6人，測試人員2人。
本項目的前期工作從2017年5月19日開始，歷時16個工作日，于6月9日完成需求分析等準備工作。開發階段從2017年6月12日開始，歷時22個工作日，于7月10日完成全部開發工作，進入外部業務人員驗證測試階段，目前，可使用XXXXXXXXXXXXXXXXXXXXXXX的二級域名進行訪問，詳細信息如下：
用戶資助申報地址：XXXXXXXXXXXXXXXXXXXXXXX
用戶審核管理地址：XXXXXXXXXXXXXXXXXXXXXXX
本項目的開發過程有5個關鍵的里程碑，具體時間及內容如下：
2017年06月21日：項目初次全新功能開發完成；
2017年06月29日：項目初次內部功能測試、安全測試、性能測試完成；
2017年07月04日：需求變更，準備進行二次開發；
2017年07月10日：項目二次開發全部完成；
2017年07月11日：項目二次內部測試完成，等待外部業務人員驗證測試。
2項目經驗
因為是初次擔任項目經理的角色，我最初找不到切入點，領導和同事在整個的過程中給了我很多的指導和建議。實際的項目管理工作使我對自己已學的理論知識有了更深刻的體會。所謂理論指導實踐，實踐驗證理論，回想整個項目開發過程，至少可以總結了以下幾點經驗：
2.1 溝通討論 信息交換要及時
溝通討論是貫穿整個項目生命周期的活動，團隊成員間信息交換是否及時，更是項目成功的關鍵。雖然不同角色承擔不同工作，但都是以達成項目目標為指導的，團隊成員只有始終保持溝通討論，保證接收到最新的、一致的項目需求信息，才能使得開發工作順利進行，避免出現信息交換不及時而導致的返工。
對于溝通，結合實際來說，如果需求分析師不能將變更的需求信息及時傳遞給UI設計人員，就會導致不符合用戶需求的設計，更會使開發人員寫出無用的代碼，這必然導致重設計、重編碼，甚至會延誤整體項目進度。
對于討論，尤其是像我這樣缺少經驗的項目經理，不論是制定計劃，還是工作量識別，都必須向有經驗的同事請教，接受正確的建議，才能得到合理的安排。
2.2 項目范圍 功能邊界要清晰
項目經理以需求文檔為依據，將項目范圍及邊界清晰羅列，是把控項目開發進度的先決條件。
對于XXXXXXXXXXXX系統來說，其功能并不復雜，且開發周期短，所以在確定項目范圍并進行任務細化時，可精確到接口、頁面。把一個大任務分解成一個個的小任務的好處是，可以幫助我們更加精確的估計出它們的工作量，并暴露出很多可能一時無法想到的工作量，也可以保證后續進行項目開發過程的狀態跟蹤，更加精確。
2.3 時間計劃 人員分配要合理
以前總認為寫計劃比寫代碼容易的多，其實恰恰相反。一份合理的項目計劃需要經過思考、溝通、權衡、詢問、傾聽的過程，要知道，用來分析解決問題需要花費的時間，遠遠大于單純的寫代碼時間。
項目進度計劃必須將分解出來的小任務，綜合考慮時間、難易程度、人員能力，估出工作量并進行合理分配。
2.4 代碼開發 功能驗證要同步
當日的開發任務結束后，作為項目經理應該對現有開發成果做驗證，即對已完成的功能做驗證，及時發現缺陷或其他問題，次日找對應的開發人員做修復。
因此，代碼開發和功能驗證的同步進行，既可以保證軟件質量，同時也可以保證項目進度。當然，應該根據實際情況同步調整項目進度計劃，預留處理缺陷的時間。
2.5 進度執行 問題修復要反饋
項目成員必須及時反饋當日任務完成情況，及前一天遺留缺陷的修復情況，才可以保證項目經理對整體進度的把控，準確跟蹤項目狀態。
2.6 需求變更 文檔修改要記錄
開發過程中的任何變更，都應做記錄，作為項目成員之間溝通交流的依據，也可以避免重復修改，增加無謂的工作量。
3項目教訓
3.1 計劃應當先于執行
項目計劃必須要盡可能周全，并且在項目經理的可控范圍內，可以根據實際情況及時做調整，但一定要保證，具體工作的開展是在計劃范圍內，因為沒有計劃直接執行會直接導致項目進度不可控，狀態無法跟蹤。
3.2 溝通應當注意技巧
高效溝通是項目成功的決定因素。因缺乏高效的溝通技巧。對內，在與開發人員進行需求溝通、代碼實現方式設計等方面溝通時，并不能快速準確表達自己意圖；對外，在與業務人員協商問題時，會不自覺的使用技術術語等業務人員不易理解的詞匯，導致雙方無法在較短時間內達成一致意見。希望自己以后有更多的鍛煉機會，學習彌補這方面的欠缺。
