Publications

Software Engineering

Jonathan Lee

PublishedOctober, 2024
Binding平裝 / 26*19 / 400pages / 單色（黑） / 中文
Publisher國立臺灣大學出版中心
SeriesEducation－Textbooks
ISBN978-986-350-864-9
GPN1011301191
Price NT$600
Paper Books San Min Books / wunan / books.com.tw / National Books / iRead / eslite / TAAZE /
Preview
Google Books

The four essences, complexity, changeability, invisibility, and conformality, are deeply rooted and inherited in the software. Software engineering is a discipline that has been specially developed to address these essential difficulties. Software processes play a crucial role in helping software engineers improve their development and maintenance in a more systematic fashion to face the challenges brought by the software wolf.

This book is the brainchild of Professor Jonathan Lee’s lifetime efforts in research and teaching of software engineering, which he teaches in the Department of Computer Science & Information Engineering at National Taiwan University. The book's contents include software processes, requirements engineering, project management, software design, software testing, software quality, capability maturity model integration (CMMI), etc.

It is Professor Lee’s hope that readers of the book can gain a better understanding of software design, development, maintenance, and management, and meanwhile, develop their software processes and gradually improve their processes to enjoy the cheerfulness of discovering something new under the sun.

Jonathan Lee

Professor of Department of Computer Science & Information Engineering, National Taiwan University

序：軟體工程的新思維與契機
第1章　軟體危機與流程
　　1.1　軟體危機
　　1.2　基本的軟體開發活動
　　1.3　軟體流程模式
第2章　需求工程
　　2.1　需求的種類
　　2.2　需求工程流程
　　2.3　需求管理
第3章　物件導向軟體開發
　　3.1　物件導向的基本概念
　　3.2　需求塑模
　　3.3　物件導向分析
　　3.4　物件導向設計
　　3.5　物件導向實作
　　3.6　目標導向使用案例
第4章　軟體設計
　　4.1　軟體設計概論
　　4.2　軟體架構設計與架構樣式
　　4.3　軟體設計策略與方法
　　4.4　軟體設計規畫
　　4.5　進階軟體設計
第5章　軟體專案計畫與管理
　　5.1　專案執行計畫書
　　5.2　專案範圍
　　5.3　專案時間排程
　　5.4　專案成本管理
　　5.5　資源管理
　　5.6　風險管理
　　5.7　專案監控
　　5.8　專案其他計畫
第6章　軟體測試
　　6.1　軟體測試的基本概念
　　6.2　軟體測試規畫
　　6.3　軟體靜態分析
　　6.4　軟體動態測試方法
　　6.5　軟體動態測試策略
第7章　軟體品質管理與保證
　　7.1　軟體品質管理
　　7.2　軟體品質保證
　　7.3　運用品質模式提升軟體品質
第8章　軟體建構管理
　　8.1　軟體建構管理計畫書與建構識別
　　8.2　軟體基準建置
　　8.3　軟體建構控制
　　8.4　軟體建構狀態報告
　　8.5　軟體建構稽核
第9章　軟體正規方法論
　　9.1　正規方法的基本概念
　　9.2　正規化規格技術的分類
　　9.3　軟體工程的數學理論
　　9.4　正規化規格語言
　　9.5　正規化與非正規化規格語言之整合
第10章　軟體流程改善
　　10.1　以模式為基礎的流程改善
　　10.2　能力成熟度整合模式的歷史演變
　　10.3　能力成熟度整合模式的組成與表達
　　10.4　能力成熟度整合模式的流程領域
　　10.5　從CMMI 2006到CMMI v3.0
　　10.6　持續整合與部署
附錄　軟體工程個案研究──需求管理
　　A.1　投票系統簡介
　　A.2　開發單位開發背景概況
　　A.3　開發流程的導入
　　A.4　新投票系統的開發
參考文獻
詞彙說明與索引

第1章　軟體危機與流程（摘錄）

1.1 軟體危機

著名的研究機構Standish Group曾在1995年針對全美國8000個軟體專案作了一項調查，發現超過30%的專案被取消，並且專案的預算平均超出189%。這項調查結果相當驚人，它忠實地呈現出當時的軟體專案所面臨的問題。經歸納分析，造成此種情況的主要原因有：(1)軟體公司總是在不合理的期限（Unrealistic Deadline）壓力下進行開發；(2)客戶在專案結束前要求增加新功能，或是給予不明確的需求（Vague Requirement）；(3)軟體本身非常複雜（Complex Structure）；(4)專案開發過程中具有許多不確定因素（Numerous Uncertainties）。

早期軟體專案發生嚴重問題的情況比比皆是。舉例來說[HRPL1999]，1982年美國銀行（Bank of America）想要進入信託生意的領域，因此花了18個月深入地研究及分析信託軟體系統，最後規畫以2000萬美元的預算，開發時程9個月，也就是在1984年12月底前完成該系統。然而此系統直到1987年3月都未完成，並且已耗費了6000萬美元，同時還失去了原先規畫的6億美元信託生意。最後因為此系統並不穩定，不得不放棄此系統，並將340億美元的信託帳戶轉移出去。除此之外，像是1996年發生的亞利安五號原型爆炸及波音Delta III火箭爆炸等事件，皆肇因於軟體問題。

軟體之所以會造成這些嚴重的問題，可以從Fredrick Brooks最經典的一篇論文[Bro1987]──No Silver Bullet中，得到部分的解答。他在該文中提到，軟體與生俱來的四種困境（Essential Difficulty）是造成即使到今日仍然無法找到「銀色子彈」的原因，同時也是造成軟體危機的主因：

1. 複雜性（Complexity）：軟體與現實生活中所接觸到的任何事物相比，有個很大的不同點，即軟體與生俱來的複雜性。當發展大型的軟體系統時，程式設計師動輒撰寫小至數百行程式碼的軟體元件，大至數萬行程式碼的系統關鍵模組，因此，軟體的複雜程度往往隨著程式的大小及軟體元件個數，以非線性甚至是等比級數的方式遞增。如此一來，往往導致一同發展的專案成員間溝通困難度提高、成本花費超出預算、發展時程延遲、系統進入非預期的狀態而當機，造成無法彌補的損失。

2. 易變性（Changeability）：軟體的易變性，更是所有軟體設計師的夢魘。我們很少聽說一棟大樓剛落成，屋主就隨興之所至要再大興土木來變動外觀或設計，因為這樣的調整勢必得付出相當大的代價。軟體的變動卻是大大相反，其相對於房子、車子、手機、電視等硬體的變動來得容易且快速，也因此軟體有比較大的彈性容許客戶提出調整的需求，以致軟體系統從開發到完成、從產品交付到營運維護，隨時都有可能要作變更。

3. 隱藏性（Invisibility）：軟體本身是看不到、摸不著的。人們習慣以幾何或是圖像化的方式呈現複雜或是無形的事物，幫助彼此進行溝通及思考。例如對於房子的設計，設計師會透過設計圖及模型與客戶作說明、討論；對於旅遊行程景點間的複雜路線規畫，導遊可以透過地圖幫助團員釐清方向與確認行程。軟體系統的確也可以透過圖像化的方式來表達它運作的資料流程、控制流程、系統架構、系統狀態、資料結構……等，但是軟體終究是看不見的，在溝通上無可避免地會遇到問題或阻礙，往往造成客戶的需求被誤解，或是疏漏之處不容易被發現。

4. 一致性（Conformity）：物理學家與數學家相信，宇宙中的萬物能夠如此井然有序，其背後一定有其亙古不變的規則、定律在主宰這一切的運行。然而在軟體世界中，每個軟體工程師都猶如各自軟體系統的神，他們各自創造屬於自己的系統模組及元件，如此一來，當多個軟體工程師共同協作發展軟體系統時，介面跟介面間、模組跟模組間、系統跟系統間的介接，或多或少都存在著不一致的地方，因此需要透過各種方式來轉換、處理這些有關一致性的問題。

過去幾十年來，為了解決軟體發展與品質方面的問題，人們不斷致力革新各種軟體開發技術，例如：從早期的機器語言（Machine Code）至Fortran、Pascal、Cobol、C等結構化的程式語言，再到C++、JAVA等物件導向（Object Orientation）的程式語言；或是從傳統的功能模組設計演變至物件導向設計等。除了這些技術上的努力與突破外，人們同時意識到，軟體開發流程其實對軟體的品質有舉足輕重的影響，因此許多學者提出不同的流程模式，試圖解決軟體開發常會遇到的問題。