第一篇：軟體專案設計個人工作總結
西安石油大學
《軟體專案設計》個人工作總結
班級：學號：姓名：
一、個人工作詳細說明
本次軟體專案設計的題目是場地預約系統，它是基於b/s模式實現的用於體育城場地管理預約的web應用軟體。為使用者提供並接受使用者提出的需求資訊，同時通過資料庫管理系統儲存資料，給場地的管理帶來很大的方便。本專案的實現分為前臺與後臺。其中前臺，使用者可以瀏覽場地所提供的可預訂場地的資訊，同時可以對需要的場地進行預訂；後臺主要是針對管理員，管理員可以通過後臺對場地的相應資訊進行增添修改等操作。
我基本參與了本專案的全部實現過程，涉及專案的需求分析，概要設計，詳細設計，程式碼編寫，除錯與執行。在需求分析階段和小組其他成員認真分析討論了本專案各方面的需求，主要是功能方面的需求，基本確定了本場地預約系統應該具有的基本功能。概要設計階段通過討論分析確定了所需表結構。詳細設計階段參與部分程式碼的編寫，其中包括頁面與資料庫互動的實現，還有相應jsp頁面程式碼的實現幾佈局的調整，修改。
在資料庫設計實現階段，通過和我們組其他成員的共同討論，確定了場地資訊、使用者資訊等表結構的詳細資訊，並實現了其資料庫的建立和相應表的具體資訊的設計實現。同時針對個別表結構完成了相應程式碼的編寫與實現。
在後臺，實現了使用者的資訊的瀏覽檢視，修改及刪除等功能，同時完成了足球場等場地資訊的瀏覽、增添、修改、刪除等功能。
前臺參與了主介面的設計與實現，通過查詢資料庫得到主介面顯示所需場地的相關資訊，通過這樣，使用者可以很清楚的獲知所有可預訂場地的資訊，其主介面上的所有關於場地的資料都是動態從資料庫獲取的，這樣當場地增添或刪除時通過修改資料庫可以很方便的實現介面呈現給使用者的場地資訊，能夠很好的使實際情況跟提供給使用者的資訊保持同布，非常利於場地資訊的管理和釋出。
二、個人工作體會
西安石油大學
時間過得真快，不知不覺中近一個月的課程設計就要結束了。本次課程設計我們組做的題目是場地預約系統，先前選題的時候以為它實現起來應該比較簡單，在通過後邊的具體分析之後才發現它並不是我所想象的那樣簡單，其中涉及許多問題我當時並沒有想清楚。
經過我們小組的共同努力，最終基本上完成了場地預約系統的實現。雖然做的不是很完美，不是特別有創意，但這是我們共同努力的結果，當我們看著自己親自完成的專案覺得很欣慰。
通過這次課程我對前邊多學的知識有了進一步的認識與掌握，使我進一步認識到課本所學知識與實際應用是不一樣的，在實際應用中需要你去針對具體的問題去靈活的變通處理，而並不總是和課本上的知識一樣。同時，我深感只有通過具體專案的實踐，才能更好的掌握所學知識，並進一步的融會貫通。
這次課程設計使我深刻認識到了一個專案的實現最重要的還是需求分析而不是程式碼的實現。在此次場地預約管理系統的實現過程中，我們就是因為期初對本系統的需求分析工作沒有做到位致使表結構的建立存在不少問題，進而導致後邊在程式碼的實現過程中又重新回來修改資料庫的表結構。這樣就不得不對已經實現的程式碼進行修改，這個過程將會是一個相當讓人頭疼的過程。一個系統的實現關鍵的不是程式碼的編寫，而是設計，只有設計合理了，在後邊程式碼實現的過程中才不會遇到問題，才不會像我們這次那樣需要反覆的修改。
本次課程設計使我再次認識到了團隊協作的重要性，一個人的能力畢竟是有限的，而大家的力量無窮的，有時候一個很小的問題，自己怎麼也看不出來，叫別人來幫著看一下可能馬上就能得到解決。團隊成員之間的互相合作可以使問題得到更好的解決，並且在其過程中能夠進一步的相互學習到更多的知識。當然，通過本次我也深知道自己相關專業知識掌握的還很不夠，在程式碼的實現過程也存在諸多問題，對很多的語句語法瞭解不是很到位，不能很好地運用，需要進一步的學習與掌握。
總的來說，本次課程設計使我對軟體開發有了進一步的認識，學到了很多知識。這將對我以後的工作學習產生重要的意義！
第二篇：軟體專案年終工作總結
我一直在跟進xx銀行w-xxnd1s2.0專案的測試工作，至此為止已近6個月時間， 從公司內部系統測試、驗收測試，再到uat測試，以及投產前的系統壓力測試等等。從開始到專案即將結束，一步步走過來。本次專案中，我作為測試環節的主力 人員之一，僅對此專案中測試工作進行總結。
一、專案測試進度控制。專案的測試進度主要是按照專案計劃進行的，完全按照專案組計劃要求完成測 試任務、提交測試類相關文件，包括測試案例的完善、制定測試計劃、執行測試、缺陷跟蹤以及bug迴歸測試等。協調專案的內部測試工作，本此專案中測試小組 一共組織了四輪次系統全面測試工作，認真配合專案工作，共同保證專案質量。專案測試的問題跟蹤及處理採用每日進行修改問題迴歸測試工作，每日同步更新問題 跟蹤單的模式，按照規劃時間完成系統更新測試。
二、專案組內部成員關係處理。在專案工作的這幾個月裡大家相處融洽，專案組內部共同探討解決 問題的方法，向各模組負責人學習模組功能處理方式，向業務人員瞭解系統中涉及的業務知識點，兩者結合起來進行模組功能測試。鑑於之前轄內對公交易系統和中 行對公專案的經驗，也向專案組提出了一些完善性意見。
三、協呼叫戶測試方面。使用者驗收測試是專案測試工作的重要組成部分之一，是專案驗收階 段的最終把關階段，業務人員結合日常業務處理情況對系統進行的嘗試性使用過程。本次專案客戶測試方面也是我個人覺得不夠安全感一個主要方面，客戶測試介入 力度太小，儘管我們已經很多次電話催促業務人員測試，每次聯絡相關業務人員進行測試，他們來到專案組開發現場測試，也僅僅一兩個小時時間，簡單的進行驗證 操作即可。xx銀行利用兩批系統培訓的時間安排了兩次分行集中測試，也算給專案進行了一次全面的測試，從中也暴露出不少系統存在的問題，目前專案組均已解 決。
四、 測試成效方面。中信x-funds2.0系統測試中，共記錄問題及客戶新增需求825個，其中bug數量512個、系統完善類問題225個，新增需求類問 題88個。組織了四輪次內部系統全面測試工作，兼顧日常系統更新測試工作，最大限度的進行了內部質量把關。配合外包公司一同進行系統壓力測試及穩定性測 試，測試結果符合客戶要求。現中信x-funds2.0系統臨近投產實施工作，測試組還將繼續配合配合專案投產工作及投產後的補丁更新測試工作。
四、 個人得失方面。作為此次專案測試的負責人，對於日常的測試流程、測試任務分配、測試執行、缺陷跟蹤、協調內部測試及協調客戶測試方面能力均得到了進一步提 高，理清了專案整個過程中測試小組的工作過程以及後期的專案移交工作。同時也對各子系統相應的業務知識有了更進一步認知。相關業務知識方面還需要進一步加 強，測試技能及測試管理方面還需要進一步完善學習。更好的吸收專案經驗，做好以後的補丁測試工作及其他專案的測試工作。
第三篇：軟體專案工作總結2篇
自2月份開始，我一直在跟進xx銀行w-xxnd1s2.0專案的測試工作，至此為止已近6個月時間， 從公司內部系統測試、驗收測試，再到uat測試，以及投產前的系統壓力測試等等。從開始到專案即將結束，一步步走過來。本次專案中，我作為測試環節的主力 人員之一，僅對此專案中測試工作進行總結。
一、專案測試進度控制。專案的測試進度主要是按照專案計劃進行的，完全按照專案組計劃要求完成測 試任務、提交測試類相關文件，包括測試案例的完善、制定測試計劃、執行測試、缺陷跟蹤以及bug迴歸測試等。協調專案的內部測試工作，本此專案中測試小組 一共組織了四輪次系統全面測試工作，認真配合專案工作，共同保證專案質量。專案測試的問題跟蹤及處理採用每日進行修改問題迴歸測試工作，每日同步更新問題 跟蹤單的模式，按照規劃時間完成系統更新測試。
二、專案組內部成員關係處理。在專案工作的這幾個月裡大家相處融洽，專案組內部共同探討解決 問題的方法，向各模組負責人學習模組功能處理方式，向業務人員瞭解系統中涉及的業務知識點，兩者結合起來進行模組功能測試。鑑於之前轄內對公交易系統和中 行對公專案的經驗，也向專案組提出了一些完善性意見。
三、協呼叫戶測試方面。使用者驗收測試是專案測試工作的重要組成部分之一，是專案驗收階 段的最終把關階段，業務人員結合日常業務處理情況對系統進行的嘗試性使用過程。本次專案客戶測試方面也是我個人覺得不夠安全感一個主要方面，客戶測試介入 力度太小，儘管我們已經很多次電話催促業務人員測試，每次聯絡相關業務人員進行測試，他們來到專案組開發現場測試，也僅僅一兩個小時時間，簡單的進行驗證 操作即可。xx銀行利用兩批系統培訓的時間安排了兩次分行集中測試，也算給專案進行了一次全面的測試，從中也暴露出不少系統存在的問題，目前專案組均已解 決。
四、 測試成效方面。中信x-funds2.0系統測試中，共記錄問題及客戶新增需求825個，其中bug數量512個、系統完善類問題225個，新增需求類問 題88個。組織了四輪次內部系統全面測試工作，兼顧日常系統更新測試工作，最大限度的進行了內部質量把關。配合外包公司一同進行系統壓力測試及穩定性測 試，測試結果符合客戶要求。現中信x-funds2.0系統臨近投產實施工作，測試組還將繼續配合配合專案投產工作及投產後的補丁更新測試工作。
四、 個人得失方面。作為此次專案測試的負責人，對於日常的測試流程、測試任務分配、測試執行、缺陷跟蹤、協調內部測試及協調客戶測試方面能力均得到了進一步提 高，理清了專案整個過程中測試小組的工作過程以及後期的專案移交工作。同時也對各子系統相應的業務知識有了更進一步認知。相關業務知識方面還需要進一步加 強，測試技能及測試管理方面還需要進一步完善學習。更好的吸收專案經驗，做好以後的補丁測試工作及其他專案的測試工作。
軟體專案工作總結（2）：
1引言
1.1編寫目的 xx網站建設
說明編寫這份專案開發總結報告的目的，指出預期的閱讀範圍。
1.2背景
說明：
a． 本專案的名稱和所開發出來的軟體系統的名稱；
b． 此軟體的任務提出者、開發者、使用者及安裝此軟體的計算中心。
1.3定義
列出本檔案中用到的專門術語的定義和外文首字母組詞的原片語。
1.4參考資料
列出要用到的參考資料，如：
a． 本專案的已核准的計劃任務書或合同、上級機關的批文；
b． 屬於本專案的其他已發表的檔案；
c． 本檔案中各處所引用的檔案、資料，包括所要用到的軟體開發標準。列出這些檔案的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的來源。
2實際開發結果
2.1產品
說明最終制成的產品，包括：
a． 程式系統中各個程式的名字，它們之間的層次關係，以千位元組為單位的各個程式的程式量、儲存媒體的形式和數量；
b． 程式系統共有哪幾個版本，各自的版本號及它們之間的區別；
c． 每個檔案的名稱；
d． 所建立的每個資料庫。 如果開發中制訂過配置管理計劃，要同這個計劃相比較。
2.2主要功能和效能
逐項列出本軟體產品所實際具有的主要功能和效能，對照可行性研究報告、專案開發計劃、功能需求說明書的有關內容，說明原定的開發目標是達到了、未完全達到、或超過了。
2.3基本流程
用圖給出本程式系統的實際的基本的處理流程。
2.4進度
列出原定計劃進度與實際進度的對比，明確說明，實際進度是提前了、還是延遲了，分析主要原因。
2.5費用
列出原定計劃費用與實際支出費用的對比，包括：
a. 工時，以人月為單位，並按不同級別統計；
b. 計算機的使用時間，區別cpu時間及其他裝置時間；
c. 物料消耗、出差費等其他支出。
明確說明，經費是超出了、還是節餘了，分析其主要原因。
3開發工作評價
3.1對生產效率的評價
給出實際生產效率，包括：
a． 程式的平均生產效率，即每人月生產的行數；
b． 檔案的平均生產效率，即每人月生產的千字數；
並列出原訂計劃數作為對比。
3.2對產品質量的評價
說明在測試中檢查出來的程式編制中的錯誤發生率，即每幹條指令（或語句）中的錯誤指令數（或語句數）。如果開發中制訂過質量保證計劃或配置管理計劃，要同這些計劃相比較。
3.3對技術方法的評價
給出對在開發中所使用的技術、方法、工具、手段的評價。
3.4出錯原因的分析
給出對於開發中出現的錯誤的原因分析。
4經驗與教訓
列出從這項開發工作中所得到的最主要的經驗與教訓及對今後的專案開發工作的建議。
第四篇：軟體開發部個人工作總結
本文由好範文小編輯收集整理，提供一篇軟體開發部個人工作總結，為您提供幫助！
又到了辭舊歲，迎新年的時候了，回望即將過去的20xx，展現在我們面前的是一年深淺不一的腳印，不管在時間這條巨大的畫面上，留下了是優美的還是些許凌亂的印記，我們總能驕傲地說，我們走過來。
20xx年是一個特殊的年份，金融危機席捲了全球各個經濟體，在中國，製造業受到了不可估量的影響，在這種背景下，百麗提出了“節約成本”的口號，將成本開銷，資源利用控制到最優化，提升實力，迎接挑戰。
1.工作彙報與總結
資訊部在整個一年圍繞著“節約成本”的宗旨，配合各個部門，本著“服務公司”的理念，根據各個部門提出的需求，新開發了質量管理系統，數字化管理系統，各個事業部m3外掛上線等，以及完善改進已有的系統：消費管理系統，人事管理系統，整合管理系統等。藉此契機，我有幸能參與其中相關係統的開發。以下是我根據時間和子系統的分類，彙報總結20xx年的工作情況。
（新m3報表子系統）
m3外掛的成功上線，絕對是對管理部提出的“節約成本”的理念的最好詮釋。企業發展部對整個流程的重新梳理，規範各個環節的銜接與控制以及我們資訊部的全力配合開發實現功能都是這一宗旨的具體體現。我依然很清晰地記得xx年初，那時候我剛進部門不久，因為m3外掛的上線，整個部門如火如荼的進行著，我看到是全體同事的齊心合力，協調合作。我印象深刻的是，那時在部門例會上直接分配報表開發到個人，每人4-5個，雖然對m3取數不是很理解，但終究是在分析測試組的幫助引導下，完成了分配的報表。也實現了我也是部門的一份子，為部門出一份力的願望。
（整合管理系統）
整合管理子系統是對整個管理系統各個模組全域性的控制，在盧成的指導下，我得以完成編碼管理中編碼欄位，規則，方案維護模組的開發，以及後續多語言維護模組的開發和dbmoto工具重啟模組的開發。
（人事管理系統）
在人事管理系統中，涉及不多，主要是前期為鍛鍊提高能力而開發的操作證列印模組。
（消費管理系統）
在隨後的任務分配上，我更多的精力是放在消費系統的熟悉和開發上，消費系統設計到的業務雖不如人事系統那麼複雜，但把業務來龍去脈理清，以及程式碼的熟悉也頗需要時間。對各個模組的作用以及程式碼如何編寫成了我前期的主要任務，主管也是想借此提高我的業務理解能力和程式設計能力。“磨刀不誤砍柴工”，只有把刀磨得鋒利了，砍起柴來才能做到遊刃有餘。期間也練習過開發一些簡單的消費報表，最初的消費卡自動充值統計報表的開發也確實夯實了業務的瞭解。在後續的工作中，對卡片管理中因為業務的需要增加了外來員工髮卡，外來員工卡號轉換，離職退卡。裝置管理中完成對消費機裝置餘額限制等的程式修改，以及黑名單自動下載模組的開發。獎金收支平衡中增加每日卡餘額的儲存過程用於結算每日卡餘額以及充值退款補貼模組（新）的修改。在查詢管理中，完成因增加外來員工和其他補貼型別的報表的開發和修改。
（數字化管理系統）
與m3外掛系統晚一些啟動的還有數字化管理系統，數字化管理系統對公司鞋類開發部的開發效率以及設計理念上起到了革命性的作用，這年公司從國外買了一套專業的製鞋軟體，但是這套軟體自帶的材料資料庫根本無法滿足公司開發部的要求，公司決定由我們資訊部開發一組完成數字化管理系統的開發。我因而參與了數字化系統前期部分基礎模組的開發。在後續的需求提出後，完成了成品管理中成品設計資訊關聯模組的開發，以及鞋楦管理中鞋楦設計工作表的開發。
（質量管理系統）
質量管理系統開發需求的到來也加快了我的成長，最先是產品製程這一部分：返工率維護，錄入模組的開發讓我初步地全新開發自己的模組。期間也著實遇到不少困難，在同事和自己的努力下都一一解決，這一個過程對我來說就是成長鍛鍊的過程。隨後面部返工率報表的開發數量之多和取數之複雜也讓我學到了如何編寫更好的優化儲存過程。第二部分是實驗室抽檢：在其中和同組的成員聯合完成開發皮料，絲帶，鋼勾心等材料的實驗室抽檢模組的開發。第三部分是原材料檢驗：這個專案是我和馮振才聯合開發，徵對不同材料型別完成了檢驗模組的開發以及相關報表的開發。
2.個人總結
這一年給我的東西我想用有形的和無形的兩部分概敘，有形的當然就是技術水平的長進，雖然其中肯定有很多的不足，但縱向對比20xx年，我得到了鍛鍊，對於不足的部分，我希望在20xx年繼續努力加快彌補。無形的就是人性的成長，在社會大學的摔打遠比在養老院式的大學校園更能讓人成長，對社會的看法，對人際關係的看法，對價值的看法，不再是以前一種近乎浪漫的眼光審視著這一切。社會的現實讓你更加學會提高，人際關係的複雜讓你更加學會斡旋，價值的體現讓你更加學會抉擇。
3.結語
在20xx年，有喜悅也有淚水。有輝煌也有遺憾，輝煌也好遺憾也罷，20xx已經過去，在新的20xx年我堅信我們資訊部將團結一心面對更多的挑戰和機遇。作為資訊部的一份子，我將以更好的狀態去迎接它們，和大家共同打造屬於資訊部的輝煌。
第五篇：2014年政府軟體專案總結
2014年政府軟體專案總結
一個專案之所以能成功，能讓客戶滿意，領導放心的原因可能大多都差不多，大多都是老生長談的那幾條。但是一個專案失敗的原因卻各有各的不
同。下面再根據自己的體會寫一些專案總結，一為了總結不足，積累經驗，二為了以後專案中避免犯同樣的錯誤。
一.要和客戶有足夠有效的溝通
和客戶的溝通要貫穿整個專案開發的始終，從立項調研，需求獲取到最後的驗收測試，後期維護。
1.要儘量多的主動跟客戶溝通
客戶一般工作都很忙，所以要通過多種方式和客戶保持溝通，電子郵件，電話，座談，調查，會議等。最初的需求儘量保證有幾次所有與專案相關的部門和人員都能參加的討論會，把他們的各自的工作都描述一下，儘量不要遺漏，都羅列出來，因為這是原始需求。這往往不容易做到
，因為政府部門很難抽出時間把各部門人員集中在一起來做這些事情的，但是我們必須得這樣要求他們，要求他們把這個看成一項工作來抓，因為前期工作做不充分，後面的開發會不會很成功。在對某個功能或者需求不能確定的情況下，最好能整理成列表文件發給客戶，讓客戶以電子版
的形式重新描述一下發過來，儘量不要經常打電話騷擾客戶，要集中把要了解東西發給客戶，以便他們集中精力來處理你問的問題。
2.要儘量保證有效的溝通
每次溝通要有一定的目的性，把溝通交流的結果用文件的形式儲存下來；需求制訂出來要得到客戶的確認，在經過幾次反覆之後會得到一個相對比較穩定的需求，雖然客戶的需求不可能一直不變，這也是很多人搞專案頭疼的地方，但是我認為客戶的需求實際上是很少改變的，改變的
是你對客戶需求的理解。對客戶的每一個要求都要重視，尤其是客戶後來提到的一些改動建議，要讓他們以書面的形式發過來，必要的時候要求負責人蓋章簽字，我們不能為了下面的下面的一個小辦事員隨便打個電話就對程式做出大的改動。再改動比較大的情況下，我們可以要求客戶對
合同的變更追加費用，前提是把需求做為合同的附件加進去，防治最後驗收的時候造成爭執。
3.和客戶溝通要找準物件
一般企業或者政府都有專門負責資訊的人員，而且最好要求客戶那邊找一個人專門負責這個專案。這樣找對方瞭解需求的時候就不會出現不知道找誰的情況，客戶那邊有專人負責會帶來很多好處，這個專案就是因為客戶那邊負責這個專案的人員經常更換而為我們專案的開發造成了很
多的不變。
二.提高開發效率和保證專案質量
政府的專案一般都是開始的時候不著急，你催他們準備資料他們也不著急，但是一旦他們把資料準備全了，都交給你了就著急了，要求對方在很短的時間內保證質量的把專案交付。所以如何提高開發效率和保證專案質量是確保專案成功的關鍵。
1.保證良好充分的測試
當然軟體測試的範疇很大，但是為了趕進度我們往往不能不保證進行所有的軟體測試。軟體的測試也是遍佈整個專案開發週期的，我瞭解了一下tdd，tdd的思想很好，很適合開發中小型的專案，實施起來也很方便，但是不能純粹的用敏捷開發的理論，必要的文件還是需要的。我認為
程式碼模組的單元測試，開發最後階段的整合測試和部署後的整體功能測試和使用者驗收測試是必不可少的。專案進度再緊張也要進行單元測試，只要保證單元測試能通過，以後程式碼可以慢慢重構。整合測試保證專案各個模組能良好的協作共同完成複雜的任務，這點不能保證的話，展示給客
戶的最終功能就不能保證。而功能測試和使用者驗收測試是純粹的黑盒測試，自己內部人員先對照原始客戶的需求進行功能測試，列出bug列表，經過幾次反覆修改後給客戶一個可以進行驗收測試的系統。
2.保證相對必要的文件以及保證文件的可用性
每個模組的文件要獨立起來，要實現的目標，測試的結果，模組所用的資料庫的結構，儲存過程，設計思路，呼叫的介面等這些是必須的。我也不建議面面俱到的文件，但必要的需求文件，模組文件，測試文件是必須的，我們的專案小的不足以讓我們去學習龐大的rup什麼的。
3.迭代開發
剛開始可以根據客戶的需求弄出一個藍圖來，交給客戶看，以便讓客戶能儘量早的知道最終的開發出來的系統是什麼樣子的，這個藍圖要儘量直觀，一般在需求整理完畢後一週就能出來，這也是指導以後開發工作的東西，要完整的包含所有的域模型，便於開發人員對問題域的理解。
然後把優先順序最高的一系列功能完整後出一個demo版給客戶，要讓客戶儘量早的發現正在製作的專案和使用者想要的結果的之間的偏離和差距，告訴你後以便你儘早的調整，別等你的正式版出來後用戶發現這個功能你做的不對，你就傻了，那時候要改動的地方就太多了。然後再弄完善一下
給使用者個beta版，這時候就已經接近最終版本了，可能還有一些小bug。最後把小bug完善修復一下給客戶正式版1.0讓客戶驗收。至於二期專案以後再說，先把一期專案的餘款結了再說，對吧。
4.制訂開發規範
開發規範訂的太死會限制程式設計師，每個開發人員都會有一些習慣，但是為了協作，制訂
一個相對通用的規範是有必要的。包括文件的規範，資料庫設計規範，編碼規範以及各種命名規則。儘量用一些業界通用的規範，網上都有，我csdn的部落格上也整理了一些，msdn的類庫開發人員指
南里面也有一些。儘管某些規範很有爭議，我感覺你也得選擇其中一種來做為你的專案開發規範。
5.建立開發基礎
保證機器和軟體的可用，儘量大的記憶體，儘量快的處理器，作業系統，開發工具都要到位，該想到的就得想到，還要給開發人員一個相對安靜舒適的環境，最好能很方便的喝到冰箱裡的可樂，而且能在累的時候有綠色的植物看。再一個就是建立一個開發基礎結構，這個也頗有爭議，
幾乎每個公司都有自己的系統類庫，開發框架以及配套的程式碼生成工具，這都很好，在開始可以對員工做適當的培訓，讓他們都能體驗自底向上設計的好處，都能用的上這個架構，你可以在架構中要求開發人員以指定的方式實現某些通用的任務，比如說日誌記錄和錯誤處理等，而不是讓
他們使用自己習慣的方式去處理問題，因為的靈活性讓實現一個任務有很多中方案和手段。
小節：雖然這個帖子沒有討論具體技術，而且都是一些空話套話，並且這些空話套話可能別人也都說的不帶說了，但我感覺還是有必要自己總結一下的。