交通部796部標平臺開發索引如何提升生產力(一) -養成交換的習慣

時間 2019-12-11

標籤交通部部標平臺開發索引如何提升生產力養成交換習慣简体版

原文原文鏈接

1.爲何部標平臺的開發週期長？html

1）首先對於交通部部標標準文檔的閱讀、理解和消化須要很長時間，你面對的是冷冰冰的交通部信息中心頒發的jt/t 79六、80八、809協議文檔，面對文字的歧義，這個消化、曲解、走彎路的時間成本，伴隨在整個軟件開發週期當中，一直到你進京趕考，進行部標檢測，最終過檢。因此這個時間是沒法估計的，理解完畢，將理解的文檔轉化成開發團隊必需要完成的功能用例，中間的偏差極大，這也是不少開發者容易自信、樂觀冒進的緣由。web

你必須須要閱讀和理解的協議文檔有四份： 796文檔、808協議文檔、809協議文檔、GB19056文檔。參見-》交通部道路運輸車輛衛星定位系統部標JTT80八、80九、796標準大全算法

2）對於標準的嚴酷性準備不足，正常本身公司開發一個系統，功能標準是本身的寫的，差很少，八九不離十就好了。不少開發者用這種習慣開發部標平臺，不少功能看似都是八九不離十，結果到最後，結局就是通不過。在檢測中心，檢測人員進行檢測主要是依靠檢測工具和檢測用例文檔，特別是測試用例文檔，比本身公司測試部門寫的黑盒測試用例都寫的細緻和充分，惋惜你看不到這個文檔，開發人員就像一個瞎子不斷的拿着本身腦殼硬碰才找到門在那裏。服務器

3）聯調難度大網絡

考不容易開發出來一個東西，須要測試，從客戶端到服務器再到gps終端這樣一個雙向聯調測試，服務器有服務器的問題，客戶端有客戶端的問題，網絡通信有網絡通信的問題，合在在一塊兒聯調，就像一羣壞孩子集中在一個班裏，亂成一鍋粥了。因爲互相影響，耽誤的時間都是疊加在一塊兒的，而不是並行開發所能解決的了得。架構

4）前面問題，是部標平臺開發不一樣於常規的信息化軟件開發之處，這些不一樣之處加大或者惡化了計劃失真的問題，就是無知者無畏，容易樂觀、輕視、冒進、準備不足，反而更容易拖延整個開發交付的週期。另外就是容易忽視測試，我增經見過一個最激進的部標監控平臺的開發計劃，整個平臺計劃50多天完成，設計一週時間，部標808gps服務器一個月完成，web客戶端20多天就要完成，809運管平臺接入10多天就完成，留給測試的時間就5天。當時我就震驚了。估計是領導根據市場狀況強加的，這簡直是要人命的。項目經理很據領導或本身的意志寫項目計劃，反正計劃歸計劃，讓寫幾天就寫幾天吧，到時間完不成，就繼續延期唄，難不成還開除不成？框架

5) 企業在運做過程當中，刻舟求劍的靜態思惟每每低估軟件項目開發的複雜性，待到項目開發週期超出原來的樂觀估計的時候，每每溫水煮青蛙，原來的3個月變成6個月，6個月變成年末，年末變成過完春節，這個時候進退兩難，中止開發又難以交代，繼續開發，還要繼續投入成本。企業的目的並非爲了要開發一款軟件產品，而是要用這款軟件產品進行運營或者作某種業務，可是每每軟件還沒開發完，已經元氣大傷，後面的事情就不用說了，就算開發出來，十幾個月都過去了，黃花菜都涼了。工具

2.如何快速開發部標監控平臺？post

坦白的說，就是購買個人源碼，進而得到個人技術支持和經驗，少走彎路。有兩個路徑能夠走：性能

1）結合本身團隊的狀況，購買個人部標808GPS服務器、部標809GPS服務器源碼，大幅縮短本身在協議理解、開發、性能調試上的時間，在此基礎上集中精力開發網頁客戶端或者CS客戶端。極大減輕的進度壓力，畢竟沒有誰願意頂着壓力作事，從從容容得作事，是一件很幸福的事情，對於公司來說，也會節省掉幾個月的開發費用支出。固然轉變思惟也不是件容易的事，雖然花的是公司的錢，免得也是公司的錢。

參見個人博客文章：

如何提升生產力(一) -養成交換的習慣

如何提升生產力(二)、軟件的開發與採購

如何提升生產力(三)、軟件服務的價值

2）購買完整部標平臺的源碼（包含部標808服務器、809服務器、網頁客戶端和安卓客戶端）

公司或團隊購買後，直接過檢或者在此基礎上，集中精力開發有行業競爭力的差別化客戶需求功能，開發週期從之前的一年多的時間縮短爲一個月的時間，一年多的開發費用是多少，會數學應該能算出來，劃不划算，更應該能算清楚。

3.開發文章索引

1）C#版的808GPS服務器開發-》基於部標JT/T 808協議及數據格式的GPS服務器

C#版的模擬終端開發-》部標808協議模擬終端的設計和開發

2）Java版的808GPS服務器開發-》基於Netty構建高性能的部標808協議的GPS服務器

基於Java Mina框架的部標808服務器設計和開發

3）C#版的809GPS服務器開發-》基於JT/T809-2011的(已過檢)GPS平臺數據交換及轉發服務器