deadline同義詞的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列問答集和資訊懶人包

架構之道：軟件構建的設計方法

為了解決deadline同義詞的問題，作者（美）居瓦·洛瑞 這樣論述：

本書展示了著名架構師Juval Lowy在世界各地實踐和教授的經過檢驗的、結構化和高度工程化的軟體設計方法。儘管各種各樣的公司已經成功地在數百個系統中實現了他最初的設計思想，但這些見解從未出現在正式出版的技術圖書中。Lowy的方法論基於軟體工程的基本原理以及一整套匹配的工具和技術，將系統設計和專案設計結合起來。首先，他描述了許多軟體架構師失敗的主要領域，並展示了如何基於易變性將系統分解成更小的構建塊或服務。 接下來，他展示了如何在系統設計中進行有效的專案設計，如何準確計算項目持續時間、成本和風險，以及如何設計多個執行選項。無論你的專案和公司規模、技術、平臺或行業如何，本書中的方法和原則都適用

。作者通過展示如何設計正確的軟體系統和專案來指導讀者應對當今軟體發展的關鍵挑戰，軟體專業人士、架構師、專案負責人或經理在職業生涯的任何階段都將從本書中受益。 前言 幾乎沒有人是被逼著進入軟體發展行業的。相反，許多人愛上了程式設計並決定以此謀生。然而，大多數人所希望的職業生涯與軟體發展那黑暗且令人沮喪的現實之間存在著巨大的差距。整個軟體行業正處於一場深刻的危機之中。因為軟體發展是多維的，所以導致了非常嚴重的危機，而軟體發展的每個方面都被打破了： 成本。一個專案的預算與實際開發該系統的成本之間的相關性很弱。許多組織甚至不願意解決成本問題，可能是因為它們根本不知道如何解決，也

可能是因為它們認識到根本承擔不起系統的高昂成本。即使新系統的第一個版本的成本是合理的，但由於設計不當和無法適應變化，整個生命週期的系統成本也往往會遠高於預期。隨著時間的推移，維護成本變得非常高，以至於公司通常會決定從頭開始，新系統很快就會像之前一樣陷入同樣甚至更糟糕的局面。而其他任何行業都不會選擇“定期從頭開始”，因為這樣做沒有經濟意義。航空公司維護大型噴氣式飛機幾十年，而一棟房子可能維護整整一個世紀。 進度。最後期限（deadline）的設定通常是武斷的、無法實現的，因為它與實際開發系統所需的時間幾乎沒有關係。對於大多數開發人員來說，最後期限是無用的東西，它會在團隊努力工作的時候“呼嘯而過

”。如果開發團隊確實在最後期限之前完成了任務，那麼每個人都會感到驚訝，因為沒有人指望它能按時完成。這也是一個糟糕的系統設計的直接結果，它會導致系統的變更和新工作的連鎖反應，並使以前完成的工作失效。而且，這是一個非常低效的開發過程的結果，它忽略了活動之間的依賴關係和構建系統的最快、最安全的方式。不僅整個系統的上市時間相當長，而且單個功能的上市時間也可能很誇張。當專案的進度出現延誤時，情況已經很糟了；當管理層和客戶都不知道這個延誤時，情況就更糟了，因為沒有人知道這個項目的真實狀況。 需求。開發人員往往最終解決了錯誤的問題。終端客戶或其內部環節參與者（如市場行銷人員）與開發團隊之間的溝通始終存在問

題。大多數開發人員也無法適應他們未能捕獲需求的情況。即使需求被完美地傳達下去，它們也可能隨著時間的推移而改變。此變更將使設計無效，並破壞團隊試圖構建的所有內容。 人員配備。即使是普通的軟體系統也非常複雜，超出了人腦的理解能力。內部和外部的複雜性是系統架構不良的直接結果，這反過來又導致複雜的系統很難維護、擴展或重用。 維護。大多數軟體系統不是由開發它們的人員來維護的。新員工不瞭解系統是如何運行的，因此他們在試圖解決舊問題時不斷地引入新問題。這很快就拉高了維護成本，推遲了上市時間，甚至導致工作停頓或專案取消。 品質。也許沒有任何其他東西可以像品質那樣破壞軟體系統。軟體有缺陷，“軟體”這個詞本

身就是“缺陷”的同義詞，開發人員無法想像沒有缺陷的軟體系統。修復缺陷通常會增加缺陷數，添加功能或簡單維護也會增加缺陷數。品質差是由不易測試、理解或維護的系統架構直接導致的。同樣重要的是，大多數項目沒有考慮到基本的品質控制活動，也沒有為每項活動分配足夠的時間，使其可以無可挑剔地完成。 幾十年前，業界開始開發解決世界問題的軟體。今天，軟體發展本身就是一個的問題。軟體發展中的問題往往以非技術性的方式表現出來，如工作環境壓力大、人員流動率高、工作倦怠、缺乏信任、自卑，甚至身體疾病等。 軟體發展中的所有問題都不是新問題，甚至，有些人在其軟體發展的整個職業生涯中都沒有經歷過一次正確的軟體發展過程。這使

他們相信這根本不可能做到，他們對任何試圖解決這些問題的嘗試都不屑一顧，因為“事情就是這樣的”。他們甚至可能會與那些試圖改進軟體發展的人抗衡。他們已經得出結論，這個目標是不可能實現的，所以任何嘗試取得更好結果的人，都是在試圖做不可能的事，這侮辱了他們的智商。 我自己的過往經歷是一個反例，表明開發人員可以成功地開發軟體系統。我負責的每個專案均按時、按預算、零缺陷地交付。在創建IDesign之後，我繼續保持了這一紀錄，我們在該領域一次又一次地説明客戶兌現了他們的承諾。 這種持續、可重複的成功紀錄絕非偶然。我在系統工程領域（包含物理系統和軟體系統）接受了培訓和教育，這使我很容易地認識到這兩個系統的

相似之處。將實踐原則應用到軟體設計中，其他工程領域的常識在軟體系統中也是有意義的。我從來沒有想過不把軟體發展當作工程來對待，或者不經過設計或計畫就開發一個系統。我認為沒有必要在我的信念上妥協，也沒有必要屈服於權宜之計，因為做正確的事情才行得通，而不這樣做的可怕後果是顯而易見的。我很幸運，能有出色的導師，在正確的時間、正確的地點看到哪些有效、哪些無效，並有機會在早期參與了一些重大而關鍵的項目，使之成為優秀案例的一部分。 近年來，我注意到該行業的問題越來越嚴重。越來越多的軟體專案失敗了。在時間和金錢上失敗成本都變得越來越高，甚至已經完成的項目也往往偏離了最初的承諾。這場危機加劇不僅僅是因為系統越

來越大或者雲計算的發展，也可能是激進的□後期限或者更高的變更率。但我懷疑真正的原因是，開發隊伍中越來越缺乏如何設計和開發軟體系統的知識。之前大多數團隊中都有一位資深人士，他指導年輕人並傳授知識。如今，這些導師已經或即將退休。在他們缺席的情況下，普通人只能獲得無限的資訊，卻得不到有用的知識。 我多希望有一個你做了就能解決軟體危機的方法，比如使用過程、開發方法、工具或技術。不幸的是，要解決多維問題，就需要多維解決方案。在這本書中，我提供了一個統一的補救方法：軟體架構之道（righting software）。 總之，我所建議的是使用工程原理來設計和開發軟體系統。好消息是沒有必要重新發明輪子，其

他的工程學科是相當成功的，因此軟體行業可以借用它們的關鍵通用設計思想並使其適用於軟體。你將在本書中看到一套軟體工程的基本原理，以及一套完整應用於軟體系統和專案的工具與技術。要獲得成功，我們必須從工程的角度出發，基於時間和風險方面的考慮，確保軟體系統是可維護的、可擴展的、可重用的、可負擔的和可行的，這些都是工程方面的問題，而不是技術方面的問題，而且可以直接追溯到系統和專案的設計環節。由於“軟體工程師”通常指軟體發展人員，所以出現了術語“軟體架構師”來描述團隊中負責專案所有設計方面的人。因此，我假定本書的讀者是軟體架構師。 本書中的一些想法並不是你要正確認識的事情，但它們肯定是一個良好的開端，因

為它們觸及了前面提到的問題的根源。根本原因是設計不當，無論是軟體系統本身還是用於構建該系統的專案。你將看到，按計劃、按預算交付軟體以及設計滿足所有可能需求的系統是完全可能的，開發出來的系統也是易維護、易擴展和易重用的。希望通過實踐這些想法，你不僅能夠學會軟體系統構建之道，還能助力自己的職業生涯，並重新點燃對軟體發展的熱情。