|
軟件創(chuàng)建的先決條件 3.1 先決條件重要性 優(yōu)秀程序員的一個突出特點是他們采用高質(zhì)量的過程來創(chuàng)建軟件。這種過程在計劃的開始、中間和末尾都強調(diào)高質(zhì)量。 3.1.1 造成不足的原因 1、一些程序員并不作準(zhǔn)備工作，因為他們抵制不了立刻開始進行編碼工作的渴望。 2、管理人員往往不理解那些在創(chuàng)建先決條件上花費時間的程序員。 3.1.2 準(zhǔn)備工作的論據(jù) 計劃的作用： 從管理人員的角度來看，
計劃是指確定一個項目所需要的時間、人力、物力和財力。 從技術(shù)人員的觀點來看，計劃是指
弄清楚你想要干什么，以免做出錯誤的工作而徒耗精力與錢財。 錯誤在軟件食物鏈中存留的時間越
長，它的危害也就傳播得越遠。-------這說 明我們應(yīng)該盡早地發(fā)現(xiàn)并消除錯誤。 3.2問題定義先決條件 在進行創(chuàng)建工作之前你要滿足的第一個先決條件，便是必須弄清楚你想要解決的問題是什么。 問題定義只描述要解決的問題是什么，根本不涉及解決方法。 問題定義的工作是在需求分析之前進行，后者是對問題的更為詳盡的分析。 問題定義應(yīng)該從用戶的觀點出發(fā)，使用用戶的語言進行定義。 3.3 需求分析先決條件 需求詳細描述了一個軟件系統(tǒng)需要解決的問題。 3.3.1 明確的需求是很重要的 明確的需求可以保證是由用戶而不是程序員決定系統(tǒng)的功能。明確的需求防止程序員對用戶需求進行猜測。 3.3.2 需求的變化 變化需求所付出的代價是“時間進度”和“成本”的代價。 建立一套更改控制過程監(jiān)控需求的變化化。 用開發(fā)的方法來容納需求的變化。 3.3.4 需求表 需求內(nèi)容 (輸入輸出的定義、硬件軟件接口、通信協(xié)議、用戶界面、處理時間等） 需求的完善性 需求的質(zhì)量 3.4 結(jié)構(gòu)設(shè)計的先決條件（詳細設(shè)計） 軟件結(jié)構(gòu)設(shè)計是較高級意義上的軟件設(shè)計，它是支持詳細設(shè)計的框架。 3.4.1 典型的結(jié)構(gòu)要素 一個系統(tǒng)結(jié)構(gòu)首先需要一個總體上的概括性描述。 在結(jié)構(gòu)設(shè)計中，你應(yīng)該能找出最終組織形式的幾種方案。 在結(jié)構(gòu)設(shè)計中，應(yīng)該在程序中定義主要模塊。 一個模塊是一個能完成某一高級功能的子程序的組合。 在需求定義中列出的每一項功能，都應(yīng)該有至少一個模塊覆蓋這項功能。如果一項功能由兩個或更多的模塊覆蓋，那 么它們之間應(yīng)該是互補的而不是相互沖突。 結(jié)構(gòu)設(shè)計應(yīng)該清晰地描述系統(tǒng)應(yīng)付變動的策略。結(jié)構(gòu)設(shè)計中應(yīng)該說明用于延緩變動的策略。 結(jié)構(gòu)設(shè)計應(yīng)該給出使用的主要文件、表和數(shù)據(jù)結(jié)構(gòu)。 不應(yīng)該允許一個以上的模塊訪問數(shù)據(jù)結(jié)構(gòu)，除非是通過訪問子程序，以使得這種訪問是抽 象的而且是可控的。 數(shù)據(jù)守恒定律：每一個進入的數(shù)據(jù)都應(yīng)該出去，或者與其它數(shù)據(jù)一道出去，如果它不出去，那它就沒有必要進來。 3.4.2 檢查表 3.5 選擇編程語言選擇條件 C 是一種中級通用語言，本來是和 UNIX 操作系統(tǒng)相關(guān)的。C 有某些高級語言的特點，例 如，結(jié)構(gòu)化數(shù)據(jù)、結(jié)構(gòu)化控制流、對于機器的獨立性、豐富的操作指令等。它也被稱作“可移 植的匯編語言”，因為它廣泛地使用了指針和地址，具有某些低級組成部分，如位操作，而且是 弱類型的。 3.6 編程約定 在高質(zhì)量軟件中，你可以發(fā)現(xiàn)結(jié)構(gòu)設(shè)計的概念完整性與較低層次實現(xiàn)之間的密切聯(lián)系。這 種聯(lián)系必須與指導(dǎo)它的結(jié)構(gòu)設(shè)計保持一致，而且，這種一致應(yīng)該是內(nèi)在的。這就是實現(xiàn)時在給 變量和子程序命名、進行格式約定和注釋約定時的指導(dǎo)方針。 小結(jié)： · 如果想開發(fā)一個高質(zhì)量的軟件，必須自始至終重視質(zhì)量問題。在開始階段強調(diào)質(zhì)量往 往比在最后強調(diào)質(zhì)量更為有效。 · 如果問題定義工作做得不好，那么在創(chuàng)建階段，所解決的問題可能并不是用戶真正要 解決的問題。 · 如果需求分析工作做得不好，很可能因此而漏掉要解決問題中的重要細節(jié)。 |
|
|
