瞭解平臺過檢35658檢測週期
為什麼部標平臺的開發週期長？
1。首先對於交通部部標標準文件的閱讀、理解和消化需要很長時間，你面對的是冷冰冰的交通部資訊中心頒發的GB/T 35658-2017、808、809協議文件，面對文字的歧義，這個消化、曲解、走彎路的時間成本，伴隨在整個軟體開發週期當中，一直到你進京趕考，進行部標檢測，終過檢。所以這個時間是無法估計的，理解完畢，將理解的文件轉化成開發團隊必須要完成的功能用例，中間的誤差極大，這也是很多開發者容易自信、樂觀冒進的原因。
你必須需要閱讀和理解的協議文件有四份：GB/T 35658-2017文件、808協議文件、809協議文件、GB19056文件。參見交通部道路運輸車輛衛星定位系統部標JTT808、809、GB/T 35658-2017標準大全
2。對於標準的嚴酷性準備不足，正常自己公司開發一個系統，功能標準是自己的寫的，差不多，八九不離十就行了。很多開發者用這種習慣開發部標平臺，很多功能看似都是八九不離十，結果到後，結局就是通不過。在檢測中心，檢測人員進行檢測主要是依靠檢測工具和檢測用例文件，特別是測試用例文件，比自己公司測試部門寫的黑盒測試用例都寫的細緻和充分，可惜你看不到這個文件，開發人員就像一個瞎子不斷的拿著自己腦袋硬碰才找到門在那裡。
3。聯調難度大考不容易開發出來一個東西，需要測試，從客戶端到伺服器再到gps終端這樣一個雙向聯調測試，伺服器有伺服器的問題，客戶端有客戶端的問題，網路通訊有網路通訊的問題，合在在一起聯調，就像一群壞孩子集中在一個班裡，亂成一鍋粥了。由於互相影響，耽誤的時間都是疊加在一起的，而不是並行開發所能解決的了得。
4。前面問題，是部標平臺開發不同於常規的資訊化軟體開發之處，這些不同之處加大或者惡化了計劃失真的問題，就是無知者無畏，容易樂觀、輕視、冒進、準備不足，反而更容易拖延整個開發交付的週期。我增經見過一個激進的部標監控平臺的開發計劃，整個平臺計劃50多天完成，設計一週時間，部標808gps伺服器一個月完成，web客戶端20多天就要完成，809運管平臺接入10多天就完成，留給測試的時間就5天。當時我就震驚了。估計是領導根據市場情況強加的，這簡直是要人命的。專案經理很據領導或自己的意志寫專案計劃，反正計劃歸計劃，讓寫幾天就寫幾天吧，到時間完不成，就繼續延期唄，難不成還開除不成？
5。企業在運作過程中，刻舟求劍的靜態思維往往低估軟體專案開發的複雜性，待到專案開發週期超出原來的樂觀估計的時候，往往溫水煮青蛙，原來的3個月變成6個月，6個月變成年底，年底變成過完春節，這個時候進退兩難，停止開發又難以交代，繼續開發，還要繼續投入成本。企業的目的並不是為了要開發一款軟體產品，而是要用這款軟體產品進行運營或者做某種業務，但是往往軟體還沒開發完，已經元氣大傷，後面的事情就不用說了，就算開發出來，十幾個月都過去了，黃花菜都涼了。
