The Basic of Software Engineering

1. The Basic of Software Engineering

2. The joy of programming(coding) 為什麼寫程式很有趣呢？寫程式的人期望從中得到什麼樣的樂趣呢？　　首先，是創造的趣味，就好像小孩子快樂地用泥巴做成一個派。大人們也一樣，從創造中可以得到十足的快樂，特別是自己設計的東西。我想這樣的樂趣一定是映自於上帝創造萬物的樂趣，你看每一片樹葉、每一片雪花的獨特與新奇，不正顯示了這種創造的樂趣嗎？　　其次，令人感到愉快的，是我們所創造出來的東西竟然對別人有用。在我們的內心深處，都希望別人用我們做出來的東西，並且發現這東西對他很有幫助。從這點看來，軟體系統跟小孩子第一次為「父親辦公專用」所做的黏土筆筒沒有什麼不同。　　第三，是那種打造精巧機制時，類似推理、解謎的過程，令人迷戀。把彼此聯動的零件組合起來，眼看著成果真的按照了我們原先所設想的方式微妙地在運作，受程式操控的那台電腦不但擁有彈珠台或自動點唱機的迷人魅力，並且將之發揮到淋漓盡致。　　第四，是持續學習的樂趣。這種工作具有不重複的特質，也不知為什麼所要解決的永遠是全新的問題，而解決問題的人總是可以從中學到些東西：有時是在實務方面，有時是在理論方面，或兩者都有。　　最後，是在如此易於操控的介質（tractable medium）上工作的快樂。程式設計師就像詩人一樣，只動動腦筋就可以做事，運用想像力，便可以憑空造一個城堡出來，很少創造性工作的介質是如此富於彈性、如此方便地讓你修修改改，並輕易地就可以把一個偉大的構想實現出來。（當然在後面我們會看到，這樣的易操控性也有它伴隨而來的問題。）　　然而，程式又跟詩人所用的字詞不同，程式本身是沒什麼，但它可以製造出看得到的效果，讓你真實感受到它活生生地在動、在做事。它能夠列印、畫圖、發出聲響、移動機械手臂，只要在鍵盤上敲入適當的咒文，整個螢幕的畫面就生氣蓬勃起來，顯現出我們未曾見過、或在現實生活中不可能見到的事物，神話和傳說中的魔法在我們有生之年實現了。　　所以寫程式實在很有趣，因為它滿足了我們潛藏於內心創造事物的渴望，並且激發了我們每個人原本就擁有的快樂感受

3. The pain of coding 然而，並不是樣樣都是有趣的，它也有天生的難處，了解這些，可以讓你在遭遇困難的時候，更容易坦然面對。　　首先，你必須表現得非常完美。電腦在這方面也跟魔法一樣，咒文中的一個字或一個停頓，只要稍有差池，魔法就施展不出來。人類並不習慣做到這麼完美，人類的活動也很少需要做到這麼完美，我認為，調適自己習於追求完美是學習軟體工程最困難的部分。1　　其次，由別人設定目標，由別人供給資源，由別人提供相關的資訊，你很少能夠自行安排自己的工作細節與工作目標，套句管理上的術語，你所擁有的權力並不足以承擔你所扛下的責任，不過，好像在任何領域中，真正能把事情做好的職位都未曾在名義上得到與責任相稱的權力。實際上的情況是：你得先把工作做成功，才會得到越多實質上的（相對於名義上應得的）權力。　　還有一點，就是得依賴別人才能成事，對系統程式設計師而言，這種獨特的情況也非常令人痛苦。他得依賴別人所寫的程式，可是別人的程式往往是個不良的設計，程式寫得很菜，移交也不完整（缺程式碼或測試案例），文件錯誤百出，於是他必須花很多時間去找出錯誤並加以修正，在理想的世界裡，這些東西都應該是完整的、隨手可得、隨即適用的。　　雖說為了偉大的構想而從事設計是份樂趣，但尋找多如牛毛的臭蟲（bug）就只能算是份差事，這是另一個苦難。任何創作活動的背後都免不了附帶枯燥、沉悶、耗時的辛勤工作，寫程式也不例外。

4. 還有，你會發現除錯工作應該是呈線性緩慢地收斂，或者更糟，但不知怎麼的，我們都會期待除錯能以二次函數的收斂速度快快結束，其實，最後出現的錯誤才最難纏，也會比早期發現的錯誤花費更多的時間才能找到，所以測試的工作也就拖拖拉拉沒完沒了。　　最後一項苦難，常常也是壓死駱駝的最後一根稻草，那就是你所投入心血進行的工作可能要花上許多時日，等產品做出來的時候（或之前），卻發現它就要落伍了。你的同行或競爭對手早就在如火如荼地開發更先進的產品，所以你那智慧結晶即將面臨淘汰的命運已不僅僅是個可能，而是既定並且可以預期的事情。　　不過實際上應該不會那麼糟，通常一項產品完成後，更新更棒的產品並未備妥（available），只是說說罷了，它也需要時間去開發才能具體落實的，除非真有實際上的用途，否則想像中的真老虎絕對敵不過現成的紙老虎（The real tiger is never a match for the paper one），已經做出來的東西擺在那裡就是優勢，單憑這點就很令人滿意了。　　當然，我們所倚賴的技術基礎是不斷地在進步，當設計完成的那一剎那，從該設計所代表的概念來看，它就已經落伍了。但是，一個實實在在的產品從無到有，需要經過許多階段來將之具體化，做出來的東西是不是落伍，應該跟其他已經存在的實物來比較，而不是跟那些尚未實現的概念相比。軟體工作的任務和挑戰就是以現有的資源並在時效之內，找到實際的方法去解決現實的問題。 • 　　這就是軟體工程，在發揮創意之餘，又得在焦油坑裡頭奮鬥，有樂，也有苦。對大部分的人而言，樂還是遠多於苦，而這本書接下來的部分，便是企圖在焦油坑上鋪上一條走道。（摘自《人月神話》第一章）

7. 摘錄自

8. 開發軟體很簡單? • 寫程式真的很簡單! • 很多人國中就會寫程式了! • 很多人熬個夜就趕的出數千行的程式了! • Internet 到處都有程式可以抄! • 錯了可以馬上改! • 有新的 idea可以馬上try!

9. 實際的現狀–要“成功的開發軟體”可不容易 Survey of 30000 software projects • 23 % of projects fail or are cancelled. • 49 % finished but were late, over budget • 28 % of projects were delivered on time, on budget, and within spec. Standish Group Report [Johnson 2001]

10. Why are they so STUPID?

11. 殘酷的現實 --- 要開發“成功的軟體產品”更不容易 • 贏者通吃 • 市場變化快 • 開發成本與風險高 • 技術障礙低 • 團隊合作 : 要有創意,技術,開發能力,行銷能力,服務能力. 缺一不可.

12. 開發應用軟體和寫學校作業真的很不同 Real Software • User • 軟體是寫給人用的. 軟體的價值決定於它的實用性 • 給誰用？ 如何用? 作什麼用? • Specification • Part of the work is defining the spec. • To change, or not to change: that is the question • 彈性? 變化? 修改? • Quality • 正確, 一致, 穩定: Do as you said. • Life Time of Years • Write, Read, Rewrite, Read, Rewrite .. Programming in School • User • Only yourself . • Specification • Fixed. Well defined. • Few Constraints • Quality • Nobody cares at all • Life Time of one semester • Write Once, Never Read • Developer = Maintainer

13. 另一個大差別 : Size does matter! 樹大招風 夜長夢多 人多手雜 節外生枝 備多力分 歧路亡羊 一個小程式 一個大軟體

14. 大 大 的 頭 痛 !

15. 開發軟體  寫程式

16. Mar – 2002 1,592 Others 196 Sales, Marketing Technical Support 546 315 Research, Development 535 13 團隊的合作 – 研發,行銷, 服務 Trend Micro Inc. 40% developers 40% QA engineers 5% Software Process 5% UI, localization 10% Anti-virus experts

17. 1 2 GM FCS BPD 2 2 Beta MRD 1 Beta Checkpoint 2 2 3 Launch PRD Implementation Plan SRS v1 3 3 TOI 3 Construction 3 3 Prototyping Endorsement SRS v0 3 Alpha Testing TOI 3 1 Test Plan User Documentation 6 NT Solaris Linux 5 Japanese Korean T/S Chinese = Ports = Eng = HIE = QA = HC assigned = L10N 5 = Marketing 一個實際的專案開發過程

18. (m USD) (Broadband) Appliances 200 (99.9% Reliability) eManager HouseCall 160 Carrier Class (TVCS) eDoctor 120 (on the fly) InterScan Internet Service (Macro Trap) PC-cillin 95 80 (Real time scan) LAN Protect Enterprise (Virus Trap) PC-cillin 40 Package 0 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 Systematic Innovation (連續的‘不連續創新’) Customer Insight + Technical Innovation

20. 賣軟體好像在賣電影

21. 殺很大

22. What is software product? • People heard such kind of story • two programmers in a garage complete a wonderful program, even supersede a big teams ability • many would believe such kind of story • A formal team can only produce thousand lines of code per year. • The fact: formal team is never replaced by 車庫二人組

23. x3 軟體系統 （介面，系統整合） 程式 x3 軟體產品 PROGRAMMING PRODUCT （通用，測試完成，文件齊全 可維護） 軟體系統產品

24. 成為軟體產品(PROGRAMMING PRODUCT) • The system can be executed, tested, modified, and extended by any one • 適用於各種操作環境，不同的資料 • 以通用的style來編寫 • 測底的測試，豐富的test case 資料庫 • 完整的文件，─指引別人使用與擴充

25. 成為軟體系統 (programming system) • 軟體系統 ─ 彼此交互運作的一組程式集合 • 程式之間 ─有律定共同的資料格式與合作模式 • 程式間必須定義出明確的介面(interface) • 每個程式的輸出入都要符合介面的語法(syntax)與語意(semantics) • 每個程式必須經過設計以滿足資源限制─記憶體大小，輸出入裝置，執行速度 • Components 都在一起時會引發意外的交互作用errors 通常很棘手

26. 成為軟體系統產品 • 9X甚至更多 • 卻是真正有用的

27. 100 Hardware 80 Development 60 40 Software 20 Maintenance 0 Time 作好應用軟體的維護 • 生小孩不容易, 養小孩更難 ! • 不只是 debug, 更是服務 !

28. Analog • 土木工程裡，蓋了橋，可以用幾十年，有標準工程圖，有基本建造的元件（如磚頭） • 電子產品出產之後，基本上功能已經 fixed。很難進行修改。有新的需求，通常採用的是將舊的機器報廢掉。少有機會可以在既有的機器基礎上做翻修。有標準電子路圖，有基本建造元件。 • 軟體呢？ • 幾乎產品一 released 就會有立即的修改 • Requirement 是個 moving target • 只能又舊有的軟體基礎上進行維護與更新。 • 沒有標準工程圖 • 新的技術如UML 不像其他的工程具備有幾何關係，也就是說軟體的藍圖不能靠單一的圖形表示方式來展示

29. How difficult?

30. Analog • Software engineering 的研究學者已經發現 • 想要與任何工程領域類比，都會遇到相當的困難 • 軟體開發具有非常獨特的工程性質

31. 軟體的困難本質 • Complexity • Conformity • Changeability • Invisibility （抽象化）

32. Complexity • 非其他創作能比擬 • 沒有兩個部分是一樣的 • However, in hardware, building, automobile construction, they can 大量的重複使用零件 • Digital computer 比大部分人們建造的東西要更複雜 • 有一大堆狀態 • 使得理解，描述，測試都非常困難 • 軟體系統的狀態又比 digital computer 多出幾個數量級

33. When scaling up • 雖然有少數同樣的元素可以重複使用 • 不同元素的數量也勢必增加 • 彼此的交互作用成指數性成長

34. 其他科學的突飛猛進緣由 • 數學與物理學的三世紀的突飛猛進 • 由複雜現象─> model 簡單的模型 • 這種方式之所以行的通，是因為模型中所排除掉的複雜性非現象的本質，如果這些複雜性是屬與本質上的特性，就行不通了 • 軟體的老問題來自於複雜的本質以及複雜性隨著軟體規模呈非線性成長的特性 • 我們對付的問題是複雜性本身 • 功能上的複雜性 • 結構上的複雜性 • 使程式擴充新功能時，難保不會產生副作用

35. Conformity (配合性） • 面對複雜性 we are not alone. • 物理的粒子世界 • 但是背後總是能化約成一種簡單都理論 • 很不幸，軟體開發沒有這種信仰與化約 • 軟體要配合的東西是由不同的人所設計，而非上帝 • 更多的複雜性是來自於必須配合其他領域的介面所致 • 這部分難以簡化

36. Changeability • 其他製造業的產品雖然必須面對改變的壓力，不過量產之後很少更動，只有會背後來的新型產品所取代 • 產品回收，現場變更(field change),頻率都比軟體來的非常非常低

37. Invisibility • You cannot see • You cannot touch • A building blue print 可以幫助建築師與客戶一起評估空間動線與景觀 • 機械零件比例圖，化學粒子棒線圖模型都達到類似的效果 • 軟體的本質與空間沒有關係，所以沒有什麼幾何表示法可用

38. Software 的表示圖 • 可能是許多 directed graphs • 這些圖可表現control flow, data flow, relation, temporal relation, namespace … etc. • 通常不是2D，也少有階層性 • 由於軟體開發少了強大的概念性工具的意圖，不僅阻礙了一個人腦袋所進行的設計過程，更會嚴重阻礙不同大腦之間的溝通 • How about UML?

39. OK，now what? • 軟體有抽象的本質 • 軟體有看不到的本質 • 軟體有難以描述的本質 • 請問軟體開發有藝術的成分在嗎？

40. OK.. Now what? • What is in real world? • Or, specifically, in TAIWAN’s industry?

42. Manufacturing in other discipline • 在製造業的世界裡面 • 產品品質(quality)是很重要的一個因素 • 當你投入非常多成本與原物料時你永遠希望你生產出來100個產品有100個都是可以賣的 • QC (Quality Control) 品質控管 • 製造過程從設計到生產可能有數十道到幾百道程序 • 每一道程序都可能影響到後面的品質 • 如何透過製造流程的改善(process improvement)來提高良率，一直都是製造工業的重要課題

43. How to improve quality? • During manufacturing If it can be done by machine, the best way to improve quality is 自動化。機器不容易犯錯而且可以不斷地重複單調無聊的工作。機器會出錯的時候通常是由於製造機器的磨損，必須重新校正。 • Ex. 日本的步進馬達精確度超高的秘密。 • Question • 當某部分的工作不能由機器來做的時候，製造過程如何做到品質控管？

44. Assembly line in manufacturing

45. In assembly line • Each person is doing one thing that is simple enough, which is not easy to make errors • A labor does not need to be smart to do the task in the assembly line • Assembly line decomposes the work into many smaller tasks which can be done by a labor in a short time and minimum skills • Discovering the cause of defect is not a difficult task.

46. Again, let’s review the engineering process of other engineering fields. • Idea • Marketing analysis (Requirement Analysis) • Analysis and Design • Manufacturing (QC) • Testing (QA) • Release product • Guess, who get the higher pay?

47. Software engineering • Idea • Requirement analysis and specification (100% design) • Design and analysis (100% design, QC here?) • Implementation (95% design?, QC here?) • Manufacturing (compilation –no cost manufacturing) • Testing

48. Question? • Is coding a design process or a manufacturing process • Is Code a design or a product? • Again, the analog breaks More questions • If coding is not a design process, we should be able to hire many 生產線女工 to control our quality • If coding is a design process, bad news, errors are inevitable because programmers are always doing complicated design jobs, not simple and easy job.

49. If you are hired to build a dog house, what ability you should Have?

50. Different Scale of Software Development If you are hired to build a Taipei 101 • What skills and talent do you need to have?