Claire's Blog

在人月神話裡，花了兩章的篇幅說明在軟體開發上， 不會有類似銀彈這種，可以快速解決開發時程延誤或發生重大錯誤的捷徑 他們提出了三個原因： (1) 複雜性： 軟體開發的複雜度與規模大小並非線性的關係，整個複雜度增加情況也會遠遠超過線性預估的結果。也因為結構上的複雜性，當軟體在擴充新功能時，難保不會產生新的副作用。程式裡的狀態難以一一列舉，也更加難以明瞭整個產品也會變的更不可靠。另外因為複雜性關係，開發時也容易遇到溝通困難、時程落後、成本超支的困難。 (2) 配合性： 軟體必須配合其他的領域，例如電腦、不同語言、不同介面等等….。 (3) 易變性： 1. 時常面臨修改，因為軟體是純思考的產物，有無限延展性，修改容易，也因此特別容易面臨修改 2. 成功的軟體生命周期會比硬體來的長，因此時常會需要配合硬體環境上去修改。 (4) 隱匿性：過於抽象、難以理解。 在這邊他們也提出了幾項過去曾讓軟體界有所突破的重大發展，但這些突破都是屬於附屬性的，沒辦法突破軟體工程本質上的複雜性： (1) 高階語言：高階語言的發行的確是最強而有力的一次突破，對生產力而言至少有五倍以上的提升。並伴隨得到可靠度、簡潔性、理解力上的增益。它把和程式內涵一點關係都沒有的那一整層複雜性給去除了。 (2) 分時技術：分時技術對於程式設計師的生產力及產品品質有了重大的提升。因為分時確保了即時性，使我們得以持續保持住腦子裡對複雜的概觀。但緩慢的回復時間是附屬難題。 ps: 分時系統：作夜系統依中央處理器排程(CPU Scheduling)，將中央處理器的時間切割為極小的時間片段(Time Slice) (3) 統一的軟體開發環境：Unix和Interlisp是第一個得到廣泛使用的整合開發環境，藉由提供完整的程式庫、統一的檔案格式、管道和過濾器，以促成軟體的共用。 (4) 物件導向程式設計：抽象資料型別和階層式型別的使用。允許介面可以用次一層級的型別去做進一步的細緻化，隱藏類別裡面的實際操作，讓開發者可以在開發時專注於設計該類別的邏輯，排除掉許多附屬性困難。 (5) 人工智慧：ex語音辨識、圖形辨識 (6) 專家系統：一支具有廣義推理引擎與知識庫的軟體程式，被設計成可接收輸入資料和假設條件的軟體程式，然後藉由知識庫來推導出邏輯上的結果。這項技術所帶來最重要的進步，是將應用領域的複雜性從程式中區隔出來。 (7) 『自動化』程式設計：換句話說是用更高階的語言來編寫程式。未來可能我們會是用『建構』的方式來寫程式，也就是更完備的函式庫，可以讓寫程式的複雜度更加的降低。 (8)  圖形化程式設計(graphical programming)：一個博班論文提出的新想法，但本書覺得要有成果應有些困難。 (9)…

花了很多天終於看完了著名的專案管理聖經─『人月神話』在此整理一下大致的重點 1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間，設計整合測試又是三倍時間，這兩方面的成本計算基本上是獨立的。 2. 以成本會計為基礎的時程預估方式，使我們誤把工作量和專案進度混為一談，人月是一個危險並容易遭到誤解的迷思，因為他假設人力和工時可以互換。 在此本書裡面，提到，專案管理人員不應該把人/月這樣的標準來做為專案規劃的標準，因為當人員多起來後，整個專案的運行會需要花更多的時間在溝通、管理、協調上，人月之間的關係並非線性關係。 並且勿忽略掉新的程式師要學習上手的開發時間，以及要耗費掉的老手的教育時間。因此，在一個已經延遲的專案中增加人手，只會讓它更加的落後，這邊較建議的方式是重新安排時程、或者刪減工作。 在這一章裡，也提出建議的專案軟體時程安排方法 1/3 規劃 1/6寫程式 1/4組件測試和早期系統測試 1/4系統測試和完成所有的組件 3. 從第三章到第七章，都是在討論保有『整體概念性』的重要。 一個專案的規劃必需出由同一人之手，也就是說，一個專案不應該有兩個領導者。我們必須選出一個能力強的人，來帶領整個專案的開發及方向，我們寧可忽略掉一些可能新奇、或很棒的想法，也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書所一直提及的整體概念性。 在第三章裡，此本書提出了一個外科手術團隊的做法，來解釋該如何去達到這個整體概念性的目的。 (1) 首席程式設計師：也就是整體概念性裡所提到的做決策的主腦。負責定義功能、設計程式、測試程式並撰寫文件。ps: 此本書也提到，真正優秀的專案管理人員，也應該要寫程式，沒有真正去撰寫一些程式的PM，是無法做好專案管理的工作的。 (2) 副手：外科醫生的分身，可以做所有首席設計師所做的事，或提出想法，但是首席設計師不一定要接納他的想法。 (3) 行政助理：幫忙處理首席程式設計師的所有庶務。一位行政助理可同時處理兩個以上團隊的工作。 (4) 文件撰寫人員、秘書(負責專案協調事宜及產品無關文件)、程式助理、測試員、語言專家、工具專家。 4. 第五章的地方，提到了第二系統效應，這個效應是指說，最容易失敗的專案，反而是我們第二個設計的系統，原因是加入了太多不相關功能。我們要慎防在設計第二個系統的時候過度設計(自律)。 5. 第六章在說意念的傳達，設計必須出於同一人之手，那些有規範那些沒有應定義清楚。溝通方式包括：將定義(指規格書裡的定義)直接融入實作、開會(分為每週召開的會議、和公開大會，討論一些重大議題及無法預見的瑣碎事項)、多重實作(當規格與程式衝突時兩方都有可能要更改)、電話紀錄(現在可用email)、產品測試(專案經理最好的朋友) 6. 在第七章探討了巴別塔失敗的原因 (1) 充分的溝通十分重要 (2) 工作手冊的結構十分的重要，且每一位成員都應看到全部的文件內容 (3) 專案管理的權力結構應該要是樹狀的，也就是第三章所講的整體概念性，任何人都不能同時聽命於兩個老闆。而組織內的溝通結構則應該是網狀的 7.  第八章是在討論專案時程預估要注意的點…