GJB2786A和GJB438B已經(jīng)對軟件的開發(fā)過程和開發(fā)過程中應該編寫的文檔類型進行了全面詳細的規(guī)定。然而，我們的一些客戶仍然要求我們編寫一些只由系統(tǒng)或設備編寫的文檔，如軟件方案報告、軟件可靠性大綱等。這種文檔不在我們前面提到的兩個標準范圍內(nèi)。那么他們真的有必要寫嗎？

讓我們試著弄清楚神圣的含義(如果把顧客當成上帝，上帝的話就是皇帝的旨意)。

當客戶要求審查軟件建議報告時，他的意圖應該是查看軟件是如何設計和實現(xiàn)的。這個初衷是正確的，應該得到我們開發(fā)者的支持。但是為什么看設計還要寫軟件項目報告呢？這不是軟件開發(fā)的標準輸出文檔。如前所述，我們應該記錄軟件開發(fā)過程和開發(fā)過程的兩個標準沒有“軟件方案報告”等輸出文檔。當客戶要求開發(fā)人員準備軟件方案報告時，必須借用系統(tǒng)或設備上“方案報告”的俗語。這可能是因為客戶對軟件開發(fā)過程和需求不太熟悉。他們更熟悉系統(tǒng)或設備的原始要求和實踐。

另一方面，對于軟件，軟件的設計方案在軟件設計規(guī)范中描述。在軟件設計規(guī)范中，軟件需求將被設計為實現(xiàn)了多少個軟件單元，將描述這些軟件單元形成穩(wěn)定和可擴展的軟件體系結構的方式，并將設計特定的單元以及它們之間的動態(tài)和靜態(tài)關系。

所以，如果用戶想看軟件的設計方案，為什么不讓開發(fā)者直接給出軟件的設計描述呢？

再來說說軟件可靠性大綱。

當客戶提出編制軟件可靠性大綱的要求時，也必須借鑒系統(tǒng)中“可靠性大綱”的說法。所以提出這個要求，說明客戶重視軟件的可靠性，希望軟件能夠可靠運行。在軟件的實際使用過程中，軟件零故障。

然而，系統(tǒng)和軟件的可靠性要求并不完全相同。就系統(tǒng)而言，它具有定量的可靠性指標和一套成熟的可靠性預測、分配和評估方法。對于軟件可靠性來說，系統(tǒng)的這種成熟方法可能并不適合。就可靠性指標而言，用平均故障間隔時間(MTBF)來衡量軟件可靠性仍有爭議，MTBF用于衡量系統(tǒng)可靠性?？煽啃允擒浖馁|量因素之一，也是軟件規(guī)劃中的一個關鍵要求，它也需要開發(fā)、設計、實現(xiàn)和驗證。因此，軟件的可靠性實際上已經(jīng)分散在一系列的軟件文檔中，比如軟件任務書、需求說明書、設計描述、測試計劃、測試描述、測試報告等。

客戶提出讓軟件開發(fā)人員在系統(tǒng)層面編譯這些常用文檔，可以說明兩個問題:一方面說明客戶對這些內(nèi)容的重視；另一方面，這也表明客戶對軟件開發(fā)過程沒有深刻的理解。客戶的這種做法可能會造成一些不良后果。一方面可能不利于系統(tǒng)更好的頂層設計，不利于軟硬件的有機結合，不利于系統(tǒng)的優(yōu)化；另一方面，這種做法給軟件增加了大量的文檔工作，占用了開發(fā)者大量的時間，并可能縮短軟件分析、設計和驗證的時間，不僅對軟件質量沒有幫助，還可能對其造成危害。

讓我們把我們的軟件開發(fā)回歸到原來正確的流程！即根據(jù)系統(tǒng)分配給軟件的功能，做好需求分析、架構設計、詳細設計、充分驗證、質量保證。沒有必要去做對這些工作沒有幫助的事情。