平邊界以下，程式變成測試、修復和擴充套件的程式。它可以執行在多種作業系統平台上，供多套資料使用。要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須擴充套件，以適用於所有可以合理使用的基本演算法。接著，對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這就意味著必須準備、執行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和範圍。此外，要將程式提公升為程式產品，還需要有完備的文件，每個人都可以加以使用、修復和擴充套件。經驗資料表明，相同功能的程式設計產品的成本，至少是已經過測試的程式的三倍。
回到圖中，垂直邊界的右邊，程式變成程式設計系統（programming system）中的乙個構件單元。它是在功能上能相互協作的程式集合，具有規範的格式，可以進行互動，並可以用來組裝和搭建整個系統。要成為系統構件，程式必須按照一定的要求編制，使輸入和輸出在語法和語義上與精確定義的介面一致。同時程式還要符合預先定義的資源限制——記憶體空間、輸入輸出裝置、計算機時間。最後，程式必須同其它系統構件單元一道，以任何能想象到的組合進行測試。由於測試用例會隨著組合不斷增加，所以測試的範圍非常廣。因為一些意想不到的互動會產生許多不易察覺的 bug，測試工作將會非常耗時，因此相同功能的程式設計系統構件的成本至少是獨立程式的三倍。如果系統有大量的組成單元，成本還會更高。
右下部分代表程式設計系統產品（programming systems product）。和以上的所有的情況都不同的是，它的成本高達九倍。然而，只有它才是真正有用的產品，是大多數系統開發的目標。
系統程式設計的進度安排背後的第乙個假設是：。 一切都將運作良好，每一項任務僅花費它所「應該」花費的時間。
在單個的任務中，「一切都將運轉正常」的假設在時間進度上具有可實現性。因為所遇的延遲是乙個概率分布曲線，「不會延遲」僅具有有限的概率，所以現實情況可能會像計畫安排的那樣順利。然而大型的程式設計工作，或多或少包含了很多任務，某些任務間還具有前後的次序，從而一切正常的概率變得非常小，甚至接近於無。
寒假閱讀人月神話3
本書作者作為乙個經驗豐富的軟體專案管理者提供給我們很多發人深省的觀點。先從書名 人月神話 開始 人月即早期用來度量軟體開發工作量的乙個單位。具體為將每個人每月的工作量作為乙個基本單位。用人月的量來衡量整個專案的規模與工作量。並且早期認為人月的模式簡單符合線性關係。即 10人 月的專案等價於5人 2月...
人月神話閱讀筆記（1）
第一章 焦油坑 程式設計產品是簡單程式通過通用化，測試，文件，維護等產生的。保證是乙個完整的程式 程式設計系統是簡單程式符合規範，功能上相互協作，並能與系統在互動上不出錯。保證能與系統配合 程式設計系統產品 程式設計系統 程式設計產品。程式設計系統產品才是大多數系統開發的目標。程式設計系統產品的成本...
人月神話閱讀筆記1
今天開始閱讀人月神話這本書 筆記如下 人月神話 作為軟體工程的經典著作，曾被坊間譽為程式設計師的聖經，但實際上，它並不是教人如何去做好乙個程式設計師，而是 了專案經理或者系統架構師的工作。書中大量舉證了作者開發作業系統 os 360時的專案經驗，其間觀點和論斷大多已經成為當今軟體開發的常識。布魯克斯...