跳去內容

軟件工程

出自維基百科，自由嘅百科全書
一位軟件工程師喺度寫源碼，整自己想要嗰隻軟件。佢可以用好多技巧等自己第時做嘢（或者第位工程師接手隻軟件）嗰陣輕鬆啲。

軟件工程jyun5 gin2 gung1 cing4（英文：software engineering）係電腦科學下嘅一門學科，涉及研究點樣去規範噉開發同維護電腦軟件：電腦軟件泛指一隻或者一柞程式，能夠教部電腦做出特定嘅運算嚟達到用家想要嘅功能[1][2]。例如電子遊戲就係一種廿一世紀初常見嘅電腦軟件，一隻電子遊戲會包含一大柞程式，會教部遊戲機內置嘅電腦做出「對玩家撳嘅掣俾反應」同「顯示啲圖像喺個熒光幕嗰度」等嘅工作，並且靠呢啲嘢嚟達到「令玩家開心過癮」呢種功能[3]。

軟件工程係一樣好有技巧嘅嘢：例如喺寫一隻軟件嘅源碼嗰陣，軟件工程師會特登喺啲碼嗰度留低啲注釋（comment；指個程式行嗰陣部電腦會忽略嘅碼）嚟解釋段碼係要嚟做乜嘅，等自己第時再想改或者返用段碼嗰時可以一眼就睇得出邊段碼係做啲乜嘅，變相等自己第時做嘢冇咁撈絞－「記得要落注釋」就係軟件工程師成日用嘅一種技巧[4][5]；除此之外，軟件工程上亦都有講軟件測試（指搞掂咗隻原型之後試吓隻軟件行起上嚟有冇問題）[1]同埋軟件維護（指喺隻軟件出咗街之後執同改良隻軟件）[6]等嘅工作上要用嘅技巧。

廿一世紀初嘅軟件工程係一門專業：軟件工程師同電腦科學家甚至仲會有專門嘅軟件工程期刊用嚟發表學術文，喺呢啲文嗰度討論軟件工程上用嘅技巧同新諗法，而一個從事軟件工程相關工作嘅人通常都或多或少噉會睇呢啲期刊嘅文，嘗試令自己做軟件工程嘅技術係噉進步[7]。

定位

[編輯]
2015 年一個細路喺度打機；隻遊戲軟件起到「俾玩家玩得過癮」嘅功能。
内文：電腦軟件
睇埋：電腦科學同工程學

軟件工程係專門整電腦軟件嘅工程學：一隻電腦軟件由一個或者一柞電腦程式組成，存在嘅意義係要提供某啲功能；例如一隻 Hello World 嘅程式除咗攞嚟教入門嘅程式編寫之外冇咩功能可言，但[8]

... 如此類推。軟件好多時仲會因為佢哋嘅強大功能而有相當嘅經濟價值，即係可以攞去賣嚟賺取利潤[註 1]，而且一隻軟件仲可以掕埋拉臣同埋說明書等相關嘅文件[1]；而工程學就係泛指用知識嚟設計同建造一啲有用嘅物品嘅過程，並且喺途中盡可能令成本效益有咁高得咁高（花費最少嘅資源嚟做到最多嘅嘢），例如電子工程專門設計智能電話等嘅電子架生噉，會用到物理學上有關電同磁嘅知識[10]。

－軟件工程就係工程學嘅一門，專門用知識嚟設計同建造電腦軟件，尤其係會用到電腦科學上嘅知識[11][12]。

軟件需求

[編輯]
内文：軟件需求、軟件質素同功能需求
睇埋：需求分析同KISS 原則

無論係開發咩軟件都好，軟件工程工作嘅第一步都係要搞清楚「隻軟件應該要係點嘅樣」。「預想中隻軟件應該要有嘅特徵」就係所謂嘅軟件需求（software requirements），軟件需求可以係由啲客明文噉提出嘅，但軟件工程師有陣時又要理解啲客有冇啲冇講出口嘅需求。軟件需求可以分做功能同非功能兩大種。

功能需求比較簡單直接，係指終端用家（指最後會用隻軟件嘅人）想隻軟件做得到嘅功能。功能需求係隻軟件起碼實要達得到嘅需求，會明確噉講出隻軟件應該要有咩 input 同 output，仲有係有啲咩必要嘅運算要做；如果隻軟件係由一個客主動要求開發嘅，噉個客通常會講明嗮佢對隻軟件嘅功能需求，而且寫合同嗰陣會講明呢啲需求；例－個客想要軟件工程師幫佢手整一隻數據庫管理系統，個系統要做到多種功能，包括係記住啲數據、俾用家摷記住咗嗰啲數據同埋用密碼學等嘅技術保護啲數據... 呀噉[13][14]。

非功能

[編輯]
内文：非功能需求
睇埋：容錯能力

每隻軟件都會有佢獨特嘅功能方面嘅需求（詳情可以睇返功能需求），不過無論一隻軟件係攞嚟做乜嘅，軟件工程師一般都會希望隻軟件具有以下嘅特性。呢啲响功能以外、但一隻軟件需要有嘅特性就係所謂嘅非功能需求（NFR）[15][16]：

  • 軟件內部：
    • 可測試度（testability）：指一隻軟件要容易做測試－喺整好咗隻軟件嘅原型之後就要做測試搵吓隻軟件有冇錯處；舉個簡單例子，軟件工程師可以要隻軟件記低啲 log（要隻軟件記住自己行嗰陣喺邊個時間點發生咗咩事），而呢點會幫軟件工程師手搵出錯處喺邊[17]。
      紀錄咗隻軟件行嗰陣發生咗嘅事嘅 log，當中每件事都掕住個時間；喺軟件工程師測試隻軟件嗰陣，呢啲資訊可以幫到手估計隻軟件行起上嚟到底係乜嘢出咗錯。
    • 可維護度（maintainability）：指嗰個程式有幾易可以俾現時或者將來嘅編程員攞去改良、執錯或者調較。高嘅可維護度對於普通嘅用家嚟講重要性唔係咁明顯，但就對一個程式長遠嘅命運同價值嚟講就好緊要－具有高可維護度嘅程式往往會俾人攞去改完又改，因而有一個更活躍嘅用家群[18][19]。
    • 可移植度（portability）：指嗰個程式嘅源碼可以喺幾廣泛嘅電腦硬件同作業系統上面行，一個完美可移植嘅程式能夠喺任何電腦（無論係個人電腦定係手機等）上面行。可移植度由好多因素話事，例如係有啲程式可能用咗一啲比較專業嘅指令，而呢啲指令專業得滯，未必部部電腦都有安裝呢啲指令－噉就會搞到個程式喺某啲電腦上面行唔到[20]。
    • 可返用度（reusability）：指隻軟件或者隻軟件啲組成部份可以攞去返用－喺軟件工程師做嘢嗰時，佢哋要設計完一隻軟件跟住去設計下一隻，而事實表明咗，有好多演算法同子程序都係唔同嘅軟件都會用到嘅，所以一位軟件工程師做嘢嗰陣成日都會諗起而家整緊嗰隻軟件可以用返某啲打前整過嘅軟件用過嘅嘢；因為噉，軟件工程師通常都會特登將隻軟件整到裏面啲嘢可以輕易噉攞去返用[21]。例子可以睇吓電子遊戲製作當中嘅遊戲資產（game asset）。
  • 軟件外部：
    • 效率（efficiency）：指個程式用咗幾多資源。呢度嘅「資源」包括咗時間、電腦記憶、同埋係網絡頻寬等等。一個理想嘅程式能夠好好噉管理佢有嘅資源，例如係唔好俾漏記憶嘅情況發生，並且用最少嘅資源做最多嘅嘢。可以睇埋運算複雜度方面嘅內容[22]。
    • 可靠度（reliability）：指個程式有幾常會俾到啱嘅結果，一個完美可靠嘅程式係每次行嗰陣都會成功俾到正確輸出嘅， [註 2]；可靠度取決於啲演算法喺概念上嘅正確同寫程式嘅過程當中有冇出錯，唔可靠嘅程式成日會有競爭危害（race condition；指個程式嘅最終輸出會受一啲唔受控制嘅時間差影響）或者緩衝區溢位（buffer overflow）等嘅問題－即係話如果有呢類問題出現，噉通常表示個程式寫得唔好[23]。
    • 頑健度（robustness）：指個程式有幾能夠預測同應對一啲佢自身以外嘅差錯，包括輸入嘅資料唔啱款（例如係輸入需要係浮點數但用家俾咗個字符）、要用嘅資源（好似係記憶體）唔夠用以及係用家方面嘅出錯呀噉。一個強健嘅程式能夠喺佢自己以外嘅嘢出錯嗰陣有方法應對－簡單講可以想像成「if 有問題，then 用噉噉噉嘅步驟嚟應對」，至少唔會搞到輕機[24]。
      一部 iMac 輕機；一般認為，一隻寫得好嘅軟件係應該唔會搞到部電腦輕機嘅。
    • 易用度（usability）：指一個普通嘅用家有幾易可以正確噉運用呢個程式。一個易用嘅程式會寫得好清楚、冇啲唔等使嘅指令、仲會有好多附加嘅內文嚟解釋每段指令係為乜而存在嘅；呢啲因素令到經驗冇咁豐富嘅編程員或者冇份寫嗰個程式嘅編程員能夠一睇就知嗰個程式做緊啲乜嘢，第時有其他人接手隻軟件嗰陣就冇咁撈絞。人機互動（human-computer interaction，HCI）呢門專係研究點樣令電子架生更加易用嘅電腦科學領域對易用度有詳細嘅研究[25]。
冇縮排冇注釋： 有縮排有注釋： 
def find_max (L):                                   
max = 0
for x in L:
if x > max:
max = x
return max

# 入嘅嘢：一列冧巴，叫佢做「L」。
# 出嘅嘢：L 入面最大嘅冧巴。

def find_max (L):  # 定義乜嘢係「去搵 L 嘅最大值」。
   max = 0         # 設最大值做 0。
   for x in L:     # 為咗 x 喺 L 入面。
      if x > max:       # 如果 x 大過最大值。
         max = x         # 設最大值做 x。
   return max      # 俾返個最大值出嚟。
# 有縮排有注釋嘅程式易睇好多，
# 對第時接手嘅編程員嚟講會易用啲。

... 等等。

涉及工序

[編輯]
内文：軟件開發同軟件項目管理
睇埋：工程學設計過程同寫程式架生

一般嚟講，軟件工程嘅第一步係「理解隻軟件要達到啲乜嘢目的」（詳情睇返軟件需求）。除咗呢樣工作之外，軟件工程涉及嘅主要工序有以下呢啲：

可行度研究

[編輯]
内文：可行度研究

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

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

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

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

五大因素

[編輯]

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

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

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

成本估計

[編輯]
睇埋：構造成本模型

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

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

，當中
  • 係「要用幾多精力」；
  • 係估計個軟件項目有幾多千行碼（睇返大細估計）；
  • 係一個佢哋有特定方法評估嘅因子，數值取決於隻軟件嘅複雜度、記憶體限制同埋工程師嘅能力等多個因素；
  • 係參數，數值係由班研究者憑啲數據估算出嚟嘅，數值會視乎軟件項目嘅種類而有異，最基本嘅可以係 。然後
  • 係成場開發要花嘅時間（以月計）；
  • 係參數，數值又係會視軟件項目嘅種類而有異，最基本嘅可以係 。

設計同建造

[編輯]
内文：軟件設計、軟件建造同程式編寫
睇埋：系統設計

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

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

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

測試

[編輯]
一位軟件工程師喺度測試緊一隻佢有份設計嘅軟件。佢要試吓隻軟件有幾易用。
内文：軟件測試
睇埋：Debug同分析癱瘓

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

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

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

... 呀噉。

維護

[編輯]
内文：軟件維護

維護（maintenance）係指喺隻軟件出咗街（啲客俾咗錢攞到手）之後再改隻軟件。軟件工程師會想維護自己整嘅軟件可以有好多原因，包括係想改良隻軟件，例如廿一世紀初嘅電子遊戲就係噉－啲遊戲開發者成日都會喺隻遊戲出咗街之後加啲新嘅內容落隻遊戲嗰度，等啲玩家玩得耐啲過癮啲；除此之外，做軟件維護嘅原因仲可以包括[40][41]：

  • 想改正啲响開發過程當中冇發現到嘅 bug；
  • 啲客對隻軟件提出咗新嘅要求，工程師想加新功能應對；
  • 想令隻軟件可以同更多嘅軟件、硬件或者電訊功能相容；
  • 工程師預想到可能將會出現一啲問題，所以改定隻軟件；
  • 引退一啲過時嘅舊軟件

... 呀噉。軟件維護呢家嘢可以好撈絞－現實嘅軟件好多時都複雜得好交關，喺開發期間想改經已好容易搞到出 bug，而想改一隻複雜得嚟仲要係有客喺度用緊嘅軟件，就更加難搞，而且對有返咁上下舊嘅軟件做維護可能會有「隻軟件同現時嘅軟硬件唔相容」等嘅問題。

開發模型

[編輯]
睇埋：軟件開發過程

基本模型

[編輯]
内文：瀑布模型

軟件開發過程（software development process）係軟件工程上最重要嘅概念之一，指由「開始諗隻軟件」到「真係整咗隻軟件出嚟」之間嗰一大柞工序（設計同建造呀噉）先後要點排[42]。喺最簡單嗰種情況下，軟件開發過程會用到所謂嘅瀑布模型（waterfall model；下圖），啲軟件工程師會跟以下呢啲步驟嚟做[43]：

  • 搞清楚隻軟件嘅要求係啲乜；
  • 郁手設計隻軟件；
  • 實行（implement），即係實際噉寫隻軟件嘅源碼出嚟；
  • 驗證（verification），即係做測試等嘅工作睇吓隻軟件係咪真係達到啲要求；
  • 維護（maintenance），即係執隻軟件啲錯處，甚至改吓隻軟件，等佢能夠應付隨時間而出現嘅新要求；

－即係好似瀑布噉由上面直落。

瀑布模型係一個好理想嘅模型，但現實係唔理想嘅－喺現實嘅應用上，通常啲軟件工程師會整隻軟件會整整吓發現新嘅要求，所以喺出街之前要返去「搞清楚要求」嗰一步嗰度，而且好多時一隻軟件整起上嚟會有好多個唔同嘅部份，唔同部份處於唔同階段。因為噉，廿一世紀初嘅軟件工程都唔會靠瀑布模型嚟做，不過進階嘅軟件開發過程模型－專業嘅軟件工程師做嘢嗰時實際會用嘅－好多時都係建基於瀑布模型之上嘅，簡單嘅例子有喺呢個模型之上添加「喺邊個階段發現到有錯，就返去之前嗰個階段嗰度」噉[44][45]。

螺旋模型

[編輯]
内文：螺旋模型

螺旋模型（spiral model）係一種喺 1980 年代尾興起嘅軟件開發方法，指成場開發過程涉及咗若干次嘅迴轉（loop），每一次迴轉都會涉及以下嘅步驟[46][47][48]：

  1. 決定目標：由「啲客嘅意見」同「距離想要嘅產品爭幾遠」等嘅資訊來源嗰度評估隻軟件需求達到啲咩要求，從而知道隻軟件喺呢一次迴轉當中要達到啲咩目的（例：想整一隻電子遊戲，決定咗第一步係想成功造出隻遊戲入面嗰一個虛擬世界先）；喺呢個階段，軟件工程師會諗一柞可能嘅解決方案出嚟（例：諗吓要用啲乜嘢演算法同遊戲資產）；睇返軟件需求。
  2. 諗同解決風險：班軟件工程師睇勻嗮柞可能嘅解決方案，由啲方案當中揀出佢哋覺得最掂嗰個，然後佢哋就會度吓採取呢個方案會引起啲乜嘢風險同埋要點樣應對（例：隻電子遊戲想用一款好創新嘅遊戲機制，但因為前人冇用過呢種機制，班工程師擔心整咗件原型出嚟先發現根本完全唔好玩）。睇返軟件設計。
  3. 郁手整件原型：揀咗方案之後，就郁手寫源碼，整件原型，整好咗就要做測試，知道件原型達唔達得到想要嗰啲要求（例：揀好咗方案之後，就郁手寫個遊戲程式嘅源碼嘅原型，寫好就試行吓，睇吓件原型行起上嚟點，達唔達到想要嘅效果）。
  4. 計劃下次迴轉

同瀑布模型等嘅大多數開發模型比起嚟，螺旋模型最大嘅好處係有效噉應付風險：軟件開發通常都係有風險嘅－要整出一個行得嘅原型要用好耐時間，而且好多時都擔心辛苦整咗件原型出嚟先發覺有問題（例如一個創新嘅遊戲機制，做完試玩先至知冇想像中咁好玩）；相比之下，螺旋模型每次迴轉都整一嚿細嘅原型出嚟，每一次迴轉都會令件原型更加接近最後嘅成品－好似條螺線噉愈轉愈大，而且喺每次郁手整原型之前就諗好嗮有乜可能會出錯嘅地方同點應對[47][48]。喺廿一世紀初，螺旋模型係某啲軟件工程子領域（例如電子遊戲製作[46]）嘅業界標準，尤其常用於大型項目嘅開發。

第啲模型

[編輯]

除咗瀑布模型同螺旋模型之外，廿一世紀初嘅軟件開發上仲有好多種做法：

... 呀噉。

起源

[編輯]
睇埋：電腦科學史

軟件工程呢家嘢始於 1960 年代：早喺廿世紀中，電腦嘅使用喺科學同工程學上經已相當之普遍；但當時啲電腦程式俾好多人詬病話佢哋成日都出錯，跟唔上電腦硬件嘅進展，頻密噉出現超支、喺最後限期前交唔到貨、要求大量嘅 debug 工作、滿足唔到啲客嘅需求、甚至係根本成個開發項目完成唔到胎死腹中[52]。於是當時嘅北大西洋公約組織（NATO）就郁手揼本想改善電腦軟件嘅質素，開始有電腦科學工作者喺度研究點樣改善整軟件嘅過程。

到咗 1965 年，經已有人喺度用英文 software engineering 一詞嚟描述呢班人做緊嘅嘢[53][54]；打後响 1968 年，北約搞咗人類史上第一個講軟件工程嘅學術研討會，一般認為此舉算係正式奠定咗軟件工程作為一個工程領域嘅地位[52]。到咗廿一世紀初，軟件工程經已俾人視為電腦科學最重要嘅部份之一[55][56]。

註釋

[編輯]
  1. ↑ 不過都有啲軟件嘅創造人會俾其他人隨便攞隻軟件去用，甚至連隻軟件嘅源碼都公開埋嘅都有。
  2. ↑ 喺數學上， 係指「事件 發生嘅機會率」。
  3. ↑ 法律嘅嘢可以因國家同地區而有異。

睇埋

[編輯]

文獻

[編輯]
  • Bruegge, Bernd; Dutoit, Allen (2009). Object-oriented software engineering: using UML, patterns, and Java (3rd ed.). Prentice Hall. ISBN 978-0-13-606125-0.
  • Jalote, Pankaj (2005) [1991]. An Integrated Approach to Software Engineering (3rd ed.). Springer. ISBN 978-0-387-20881-7.
  • Oshana, Robert (2019-06-21). Software engineering for embedded systems: methods, practical techniques, and applications (2nd ed.). Kidlington, Oxford, United Kingdom. ISBN 978-0-12-809433-4.
  • Pressman, Roger S. (2009). Software Engineering: A Practitioner's Approach (7th ed.). Boston, Mass: McGraw-Hill. ISBN 978-0-07-337597-7.
  • Sommerville, Ian (2010) [2010]. Software Engineering (9th ed.). Harlow, England: Pearson Education. ISBN 978-0-13-703515-1.

攷

[編輯]
  1. ↑ 1.0 1.1 1.2 1.3 Abran, Alain; Moore, James W.; Bourque, Pierre; Dupuis, Robert; Tripp, Leonard L. (2004). Guide to the Software Engineering Body of Knowledge. IEEE.
  2. ↑ Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC.
  3. ↑ Zackariasson, P., & Wilson, T. L. (Eds.). (2012). The video game industry: Formation, present state, and future. Routledge.
  4. ↑ Keyes, Jessica (2003). Software Engineering Handbook. CRC Press. discusses comments and the "Science of Documentation" p. 256.
  5. ↑ James L. Elshoff, Michael Marcotty, Improving computer program readability to aid modification (PDF), Communications of the ACM, v.25 n.8, p.512-521, Aug 1982.
  6. ↑ Definition of 'Software Maintenance'. The Economics Times.
  7. ↑ Journal of Software Engineering.
  8. ↑ Lawrence, Snyder (2017). Fluency with information technology : skills, concepts, & capabilities ([Seventh edition] ed.). NY, NY.
  9. ↑ Deitel, Harvey M.; Deitel, Paul; Choffnes, David (25 December 2015). Operating Systems. Pearson/Prentice Hall.
  10. ↑ Blockley, David (2012). Engineering: a very short introduction. New York: Oxford University Press
  11. ↑ Oettinger, A. G. (1966). "President's Letter to the ACM Membership". Commun. ACM. Association for Computing Machinery. 9 (8): 545–546.
  12. ↑ Pressman, R. S. (2005). Software engineering: a practitioner's approach. Palgrave macmillan.
  13. ↑ Fulton R, Vandermolen R (2017). "Chapter 4: Requirements - Writing Requirements". Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254. CRC Press. pp. 89-93.
  14. ↑ Loucopoulos, P. (2005). "Chapter 4: Requirements Engineering". In Clarkson J, Eckert C (eds.). Design Process Improvement: A Review of Current Practice. Springer-Verlag. pp. 116-139.
  15. ↑ Software Engineering | Introduction to Software Engineering. GeeksforGeeks.
  16. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45.
  17. ↑ Shalloway, Alan; Trott, Jim (2004). Design Patterns Explained, 2nd Ed. p. 133.
  18. ↑ Foreman, John T.; Gross, Jon; Rosenstein, Robert; Fisher, David; Brune, Kimberly (January 1997). "Maintainability Index Technique for Measuring Program Maintainability". C4 Software Technology Reference Guide: A Prototype (PDF). Software Engineering Institute. p. 231.
  19. ↑ "Programming 101: Tips to become a good programmer - Wisdom Geek". Wisdom Geek.
  20. ↑ Mooney, J. D. (2004). Developing portable software. In Information Technology (pp. 55-84). Springer, Boston, MA.
  21. ↑ Lombard Hill Group (October 22, 2014). "What is Software Reuse". www.lombardhill.com. Lombard Hill Group.
  22. ↑ Arora, Sanjeev; Barak, Boaz (2009), Computational Complexity: A Modern Approach, Cambridge University Press.
  23. ↑ Institute of Electrical and Electronics Engineers (1990) IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY.
  24. ↑ 1990. IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 defines robustness as "The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions".
  25. ↑ Wegge, K. P., & Zimmermann, D. (2007, July). Accessibility, usability, safety, ergonomics: concepts, models, and differences. In International Conference on Universal Access in Human-Computer Interaction (pp. 294-301). Springer, Berlin, Heidelberg
  26. ↑ 26.0 26.1 James Hall (23 August 2010). Information Technology Auditing. Cengage Learning. p. 188.
  27. ↑ P. M. Heathcote (April 2005). 'A' Level Computing. Payne Gallway. p. 176.
  28. ↑ Guidelines on how to choose an FSM Method (PDF).
  29. ↑ McLeod, S. (2021). Interrelated Attributes of Project Feasibility: Visualizing the TELOS Framework. ScienceOpen Posters.
  30. ↑ Bentley, L & Whitten, J (2007). System Analysis & Design for the Global Enterprise. 7th ed. (p. 417).
  31. ↑ Krämer, W., & Sonnberger, H. (2012). The linear regression model under test. Springer Science & Business Media.
  32. ↑ Kemerer, Chris F. (May 1987). "An Empirical Validation of Software Cost Estimation Models" (PDF). Communications of the ACM. 30 (5): 416–42.
  33. ↑ Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995). Cost models for future software life cycle processes: COCOMO 2.0. Annals of software engineering, 1(1), 57-94.
  34. ↑ Software Engineering | Software Design Process. GeeksforGeeks.
  35. ↑ Software Configuration Management in Software Engineering. Guru99.
  36. ↑ Kainda, R., Flechais, I., & Roscoe, A. W. (2010, February). Security and usability: Analysis and evaluation (PDF). In 2010 International Conference on Availability, Reliability and Security (pp. 275-282). IEEE.
  37. ↑ Software Engineering | Seven Principles of software testing. GeeksforGeeks.
  38. ↑ Seven Principles of Software Testing | Software Testing Material. Software Testing Material.
  39. ↑ 7 Principles Of Software Testing: Defect Clustering And Pareto Principle. Software Testing Help'.
  40. ↑ Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons.
  41. ↑ April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE.
  42. ↑ Geoffrey Elliott (2004). Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.
  43. ↑ Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). "The Waterfall Model in Large-Scale Development". Product-Focused Software Process Improvement. Lecture Notes in Business Information Processing. Berlin, Heidelberg: Springer: 386–400.
  44. ↑ Royce, Winston (1970), "Managing the Development of Large Software Systems 互聯網檔案館嘅歸檔，歸檔日期2020年10月2號，." (PDF), Proceedings of IEEE WESCON, 26 (August): 1-9
  45. ↑ McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press
  46. ↑ 46.0 46.1 Schell, J. (2014). The Art of Game Design: A book of lenses. AK Peters/CRC Press. p. 82 - 86.
  47. ↑ 47.0 47.1 Boehm, B (May 1988). "A Spiral Model of Software Development and Enhancement 互聯網檔案館嘅歸檔，歸檔日期2021年6月24號，." (PDF). IEEE Computer. 21 (5): 61-72.
  48. ↑ 48.0 48.1 Boehm, B (July 2000). "Spiral Development: Experience, Principles, and Refinements" (PDF). Special Report. Software Engineering Institute. CMU/SEI-2000-SR-008.
  49. ↑ Pressman, Roger (2010). Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. pp. 41-42.
  50. ↑ Larman, Craig (June 2003). "Iterative and Incremental Development: A Brief History". Computer. 36 (6): 47–56.
  51. ↑ Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison-Wesley.
  52. ↑ 52.0 52.1 Peter, Naur; Randell, Brian (7-11 October 1968). Software Engineering: Report of a conference sponsored by the NATO Science Committee (PDF). Garmisch, Germany: Scientific Affairs Division, NATO. Retrieved 2008-12-26.
  53. ↑ Oettinger, A. G. (1966). "President's Letter to the ACM Membership". Commun. ACM. Association for Computing Machinery. 9 (8): 545–546.
  54. ↑ "The origin of "software engineering"". Retrieved 17 November 2017.
  55. ↑ Williams, N.S.W. (19–21 February 2001). "Professional Engineers Ontario's approach to licensing software engineering practitioners". Software Engineering Education and Training, 2001 Proceedings. 14th Conference on. Charlotte, NC: IEEE. pp. 77–78.
  56. ↑ McConnell, Steve (July 10, 2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers.

拎

[編輯]
維基同享有多媒體嘅嘢：
Software engineering
由「https://zh-yue.wikipedia.org/w/index.php?title=軟件工程&oldid=1996800」收