雖然通訊院搞的電報資料通訊機是用DJS60D作為控制計算機，這個東西現在並不能出口，但是軟體用到DJS59上還是能配套的。
大洋公約國家也許打不進去，但是經助會國家、一些其他零散的國家還是能試試的。
至於電子郵件，看起來和電報資料通訊機差不多，但其實區別挺大，這個在這個階段更多用於機構工作人員之間的通訊，還是挺好用的。老外工作喜歡發email的習慣，其實就是普及email比較早，慢慢養成的。
防工委的領導把這兩個東西介紹完，而且也說了，這兩個軟體，沒有任何保密需要，儘管賣，能賣多少算多少，能賣哪兒賣哪兒。
甚至如果有需要，能做專門的固化程式的DJS59，只用於這個功能。
這個能力，運算所這些單位還是有的。
對於這個事情，其他幾個部門非常有興趣。
對於外事，是可以擴大影響力的一種手段，尤其是這種高科技產品。雖然很微弱，不過老話說得好，不積跬步無以至千里，不積小流無以成江海，路都是要一步一步走的，沒有那麼多一蹴而就的事情。
嗯，除了高振東那種掛壁。
對於外商部來說，那就更簡單了，賣小錢錢還債！
特別是知道“賣軟體”的概念之後，對於這種出售一盤兩盤小磁帶就能賺回比較大額外匯的事情，那就更感興趣了。
幾人當場拍板，這東西，賣了賣了，馬上加上清單去，都不用開論證會。
外商部領導還開了個玩笑：“老X啊，十七機部這個寶貝疙瘩，你可要看好了，別出什麼意外。”
防工委領導一邊點頭，一邊心想，這還用你說，我早就安排咯。
——
高振東花了1天時間，把GB 8567裡面該改的地方給改過來，這東西也就幾十頁，改起來不麻煩。
然後兩個電話，請來了運算所和通訊院的兩位總工。
兩位總工見面，頗有些較著勁的微妙，好嘛，要不是你，我可就獨吞了。
不過這種良性競爭，也算不上什麼壞事，高振東假裝沒看見，你們鬥你們的，我穩坐釣魚臺，而且絕不會空軍。
高振東一邊在心裡陰陽著釣魚佬，一邊拿出自己改好的《軟體開發檔案編制指南》，分成兩半，遞給了二人，二人也顧不上鬥雞了，連忙接過來翻開。
GB 8567是一份涵蓋了計算機軟體開發從可行性研究報告到專案開發總結報告全過程的，一共14個文件編制說明的標準，對於軟體的整個生命週期都進行了定義。
其章節組織，是根據軟體生命週期的整個流程，從前往後寫的，對於開發人員來說，非常容易看懂和掌握。
這一點，是88和2006最大的不同，2006裡面擴充套件了一些東西，拆分和重新組織了一些東西，一共是25個軟體開發的文件。
詳細是詳細了，可是要說到檔案的組織順序，說一句雜亂無章並不為過。
總的說來，88版用於瀑布開發模型非常合適，而2006版就頗有些一言難盡了，好像是更偏向敏捷開發，可是卻又不是那麼太敏捷的樣子，總之突出一個擰巴。
在高振東看來，如果要開發專案型的軟體，那用88版做總綱合適一點，如果要搞持續快速迭代的軟體，那從2006裡面拆東西出來用合適。
其實把2006融進88的各個階段文件裡面，是一個不錯的搞法，不過以當前的環境條件，這個步子略大，容易讓開發人員陷入為了文件而文件的窘境。
對於這時候的開發人員來說，拿著88搞傻瓜式操作，跟著標準一路把文件落實下來，是大概能把一個專案管好的。
而2006版的話，就要花費一些心思了，2006的更先進，某些東西更詳細，但是系統性卻是不如88版的，一個沒有比較成形的專案管理思維的人，看著2006那一大堆東西，直接懵掉的機率不低。
這也就是高振東沒有選擇2006版的原因，本來開發流程對於這個時候的軟體開發人員們來說，就已經夠亂了，再來一個亂糟糟的2006，那無異於讓開發人員本不清晰的思路，更加雪上加霜。