軟件開發

軟件開發係軟件工程嘅範疇，根據用戶去開發軟件系統嘅過程，涉及到程式設計、軟件文件、軟件測試、除Bug等過程。

可行性研究

内文：可行性研究

可行性研究（feasibility study）係指諗清楚啲軟件嘅需求之後，首先決定個項目係咪真係有得搞：好多時，啲客對於電腦軟件方面嘅嘢都唔係咁熟，會提出一啲冇可能達得到嘅要求；又或者係位軟件工程師想整一啲有返咁上下嶄新嘅功能，同時又因為呢啲功能嶄新得滯，唔肯定係咪真係有可能整到出嚟；可行性研究就係指

• 攞住手上嗰啲已知嘅軟件需求（input：軟件需求），
• 做一大輪嘅分析，再決定隻軟件係咪真係有可能整得成（output：去定唔去）。

可行性研究嘅過程會同時用到技術同經濟方面嘅考量－一個軟件開發計劃如果過唔到可行性研究，可以係因為現有嘅軟件技術做唔到啲需求，亦都可以係因為現時嘅技術係就係做到啲需求，但要用嘅成本極高，負責做呢個開發計劃嘅單位唔肯揼咁多本去做。

大細估計（sizing）通常係喺呢個階段做嘅。大細估計係指估計最後整出嚟嗰隻軟件會有幾大。大細估計喺軟件工程上係一個幾大嘅課題，到咗廿一世紀初都仲未有完全標準化嘅大細估計做法，不過軟件工程師可以憑經驗同幅圖則估算吓隻軟件會有幾多行碼，又或者係搵啲類似嘅軟件，睇吓佢哋係幾大左右... 呀噉。睇埋運算複雜性理論。

五大因素

可行性研究最常會考慮嘅因素有以下呢啲，英文興嗌呢五大考量做 TELOS（嚟自嗰五個因素分別嘅開頭英文字母）：

• T－Technical（技術）：隻預想中嘅軟件用現時嘅技術有冇可能整到出嚟？
• E－Economic（經濟）：隻預想中嘅軟件要使幾多成本？會唔會帶嚟利潤？
• L－Legal（法律）：隻預想中嘅軟件會唔會犯法？
• O－Operational（運作）：預想中隻軟件有幾能夠配合到周圍嘅商業環境？
• S－Scheduling（時程）：預想中隻軟件可唔可以喺限時之內搞掂？

度好嗮覺得個軟件計劃整得過，啲軟件工程師先會郁手做設計。

成本估計

睇埋：構造性成本模型

可行性研究等嘅設計前工序基本上實會涉及「估隻軟件要用揼幾多本先可以整到出嚟」噉嘅工作。成本估計有好多方法，例如構造性成本模型（COCOMO）就係廿一世紀初最常用嘅成本估計法之一，建基於對前人做軟件開發得到嘅數據嘅迴歸分析：迴歸分析（regression analysis）係一種統計學技術，喺最簡單嗰種情況下，攞若干個自變數 $x_{1},x_{2},x_{3}...$ 同一個應變數 $y$，而

$y=\beta _{0}+\beta _{1}x_{1}+\beta _{2}x_{2}+\beta _{3}x_{3}+...+\varepsilon _{i},\quad i=1,\dots ,n.\!$

迴歸分析做嘅就係攞一柞過往嘅數據，估算出啲參數－柞 $\beta$－嘅數值，最後得出一個迴歸模型。於是第時研究者就可以攞住個迴歸模型（知道咗柞 $\beta$ 嘅值），靠觀察啲 $x_{1},x_{2},x_{3}...$ 嘅數值嚟計 $y$ 嘅數值大致上會係幾多。喺 1970 年代尾，有美國嘅軟件工程研究者搵咗一大柞軟件工程師嘅開發項目嘅數據返嚟，每個項目做一個個案做迴歸分析，個項目啲特徵（例如係個項目嘅複雜度噉）做 $x_{1},x_{2},x_{3}...$，而「個項目要用嘅資源」做 $y$，建立咗迴歸模型，發現用噉嘅迴歸模型能夠大致噉估計一個軟件開發項目嘅成本－由呢個過程形成嘅就係 COCOMO 成本估計法。最基本嗰條 COCOMO 式係噉嘅：

$E=a_{i}({\text{KLoC}})^{b_{i}}({\text{EAF}})$，當中

• $E$ 係「要用幾多精力」；
• ${\text{KLoC}}$ 係估計個軟件項目有幾多千行碼（睇返大細估計）；
• ${\text{EAF}}$ 係一個佢哋有特定方法評估嘅因子，數值取決於隻軟件嘅複雜度、記憶體限制同埋工程師嘅能力等多個因素；
• $a_{i},b_{i}$ 係參數，數值係由班研究者憑啲數據估算出嚟嘅，數值會視乎軟件項目嘅種類而有異，最基本嘅可以係 $a_{i}=3.2,b_{i}=1.05$。然後

$D=2.5E^{c_{i}}$

• $D$ 係成場開發要花嘅時間（以月計）；
• $c_{i}$ 係參數，數值又係會視軟件項目嘅種類而有異，最基本嘅可以係 $c_{i}=0.38$。

設計同建造

内文：軟件設計、軟件建造同程式編寫

設計（design）係「知想要啲乜」（軟件需求）同埋「知隻軟件整得過」（可行性研究）之後嘅第一個工序，指軟件工程師喺度計劃隻軟件要點樣整。喺呢個階段，軟件工程師仲未郁手整隻軟件，不過都已經大把嘢要做：

• 介面設計：即係要知隻軟件同周圍嘅環境會有邊啲互動；喺呢個階段，位軟件工程師可以當隻軟件係個黑盒，即係唔使諗「隻軟件啲源碼係點」住，淨係諗清楚隻軟件有邊啲用家、每一位用家會俾啲乜嘢輸入俾隻軟件、同埋每位用家需要隻軟件俾咩輸出佢。
• 架構設計：即係要講明隻軟件有啲咩組成部份（睇埋模塊化編程），同埋每個部份負責做乜同有乜特徵，而且仲需要講明唔同部份之間要互傳乜嘢數據（架構），所以喺呢個階段，隻軟件唔應該再會係一個黑盒。喺做架構設計嗰陣，軟件工程師好多時都會畫返幅圖則，將自己嘅諗頭視覺化。
• 詳細設計：軟件設計嘅最後階段，軟件工程師攞住隻軟件嘅架構，就要開始詳細噉諗啲可以實際寫出嚟嘅細節，包括咗諗每個主要部份要包含啲乜嘢程式、啲程式要用乜嘢演算法同數據結構、以及係做用家介面設計（UI design）呀噉，最後得出一個可以跟住嚟郁手寫源碼嘅計劃。

一隻軟件嘅圖則；幅圖入面每個多邊形表示隻軟件嘅一個部份，而啲箭咀就係啲部份之間傳達嘅數據。

而建造（construction）就係指郁手（跟住軟件設計得出嗰個計劃）寫隻軟件嘅源碼。喺呢個過程當中，軟件工程師要一路寫一路做小型測試、debug 同埋配置管理（包括一路睇實隻軟件「喺邊個時間點改過嚟」同埋每次改咗之後「隻軟件嘅表現有咩變化」等嘅資訊）嘅工作，最後得出一件原型（prototype；指隻行得嘅軟件，但要測試所以仲未出街住）。有關寫程式嘅詳情，可以睇吓電腦程式編寫嘅嘢。

測試

一位軟件工程師喺度測試緊一隻佢有份設計嘅軟件。佢要試吓隻軟件有幾易用。

内文：軟件測試

睇埋：程式除錯

測試（testing）係指做一啲特定嘅程序嚟睇吓隻軟件係咪去到出得街嘅質素：最簡單嘅方法係工程師自己試吓行吓隻軟件，睇吓有冇乜嘢 bug；再唔係佢哋又可以索性搵班人返嚟試吓用隻軟件，並且收集場測試嘅數據，用數據嚟評估隻軟件掂唔掂，例如觀察吓班測試者平均要用幾耐先至用隻軟件用得上手－呢樣數據會反映隻軟件夠唔夠易用。

响廿一世紀初嘅軟件工程界，測試呢家嘢有好多技巧。以下係軟件工程師傾有關做測試嘅心得嗰陣成日會提到嘅要點：

• 「要完全徹底噉測試嗮所有可能性」係冇可能嘅：測試當中搵到錯處能夠證明隻軟件有錯，但測試搵唔到錯處唔能夠證明隻軟件完美無誤；現實應用上嘅軟件都會頗為複雜，閒閒哋會有成幾萬行源碼，所以「隻軟件行嗰陣有可能處於嘅狀態」呢個數值極之大，現實世界嘅軟件工程師唔會有咁多時間試嗮呢啲可能情況，做大量嘅測試都頂櫳只係能夠減低隻軟件有意外甩漏嘅機率。軟件工程師通常淨係會揀最有可能出現嗰啲情況，再試吓呢啲情況下會唔會有 bug，如果冇，佢哋就會假設隻軟件喺其餘嘅情況下都唔會有問題。睇埋歸納。
• 要盡早做測試：軟件工程師通常會有咁早得咁早開始做測試，喺寫隻軟件嘅源碼嗰時就經已喺度做啲小型嘅測試，行吓隻軟件啲細部份睇吓有冇問題；一般認為，bug 呢家嘢係愈早發現愈好嘅，遲發現嘅 bug 好多時都會搞到工程師損失慘重。
• 錯誤聚埋一齊：有啲軟件工程師指「80% 嘅錯處都係由 20% 嘅模塊嗰度嚟嘅」；現實嘅經驗表明咗，好多時一隻軟件嘅錯誤都係源自其中一兩個部份嘅錯，而同時淨低嗰啲部份查實冚唪唥都冇問題。
• 農藥悖論（pesticide paradox）：重複噉用同一個個案嚟做測試係唔會搵到新嘅 bug 嘅，做測試嗰陣有必要用一大堆唔同樣嘅個案嚟做測試，先至可以全面噉搵到唔同嘅 bug。
• 無錯謬論（absence of errors fallacy）：如果一隻軟件係 99% 冇 bug 但滿足唔到啲功能性需求，噉隻軟件係完全冇用嘅；「測試冇 bug」只不過係一隻軟件要出街嘅必要條件，唔係出得街嘅充分條件。

... 呀噉。

睇埋

• 軟件工程