人月神話讀書筆記

人月神話讀書筆記人月神話這本書幾年前就聽別人說是本很經(jīng)典的軟件開發(fā)方面的書，這本書的成功之處在于他思想的前衛(wèi)性，以至于不只是軟件行業(yè)的人在讀?，F(xiàn)在終于找到讀他的理由了，可以感受一下大師的杰作。在讀之前我已經(jīng)讀過了軟件工藝和極限編程，為什么留到最后讀人月神話呢？主要是因為我覺得一本能夠流傳30年還被人們津津樂道的書，肯定是本學要好好細讀的書，所以留到了最后。按照前兩篇讀書筆記的慣例，前面幾段是一些我讀書時的感受和收獲，還有一些對內(nèi)容的。從這本書的內(nèi)容來看，對于一個工程經(jīng)理來說肯定會有更大的收獲，這本書主要是針對軟件開發(fā)管理方面的內(nèi)容，這主要原因可能是因為作者以前就是工程的管理者，他是站在管理者的角度寫的。即便這樣，對于一個從來沒有參與過真實工程開發(fā)，更沒有領導過團隊的我還是有一定的吸引力，這本書中我最喜歡的就是前四章（焦油坑、人月神話、外科手術隊伍、貴族專制、民主政治和系統(tǒng)設計）和沒有銀彈這章。這本書里面為了論證某一觀點，會舉出許多實際的工程作為證據(jù)，這一點非常好，事實勝于雄辯嘛！這些例子也許對于作者那個年代的人來說很好理解，但是放在30年后來看這些例子又有些陳舊和難懂了。另外，從文中我發(fā)現(xiàn)作者非常注重文檔，一個優(yōu)質(zhì)的文檔就是工程成功的保證，這一點與傳統(tǒng)的軟件工程很相似，但是卻與極限編程的觀點相悖。下面就是一些讀書的總結(jié)了。焦油坑1.編程系統(tǒng)產(chǎn)品開發(fā)的工作量是供個人使用的、獨立開發(fā)的構件程序的九倍。2.編程行業(yè)的一些內(nèi)在固有苦惱：l將做事方式調(diào)整到追求完美，是學習編程的最困難局部。l由其他人來設定目標，并且必須依靠自己無法控制的事物。l真正的權威于每次任務的完成。l任何創(chuàng)造性活動都伴隨著枯燥艱苦的勞動，編程也不例外l人們通常期望工程在接近結(jié)束時（bug、工作時間）能收斂得快一些，然而軟件工程的情況卻是越接近完成，收斂得越慢。l產(chǎn)品在即將完成時總面臨著陳舊過時的威脅。人月神話1.缺乏合理的時間進度是造成工程滯后的最主要原因，它比其他所有因素加起來影響還大。2.良好的烹飪需要時間，某些任務無法在不損害結(jié)果的情況下加快速度。3.我們的構思是有缺陷的，因此總會有bug。4.我們圍繞本錢核算的估計技術，混淆了工作量和工程進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數(shù)量和時間是可以相互替換的。5.在假設干人員中分解任務會引發(fā)額外的溝通工作量--培訓和相互溝通。6.關于進度安排，作者的經(jīng)驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統(tǒng)測試。7.因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。8.brook法那么：向進度的工程中增加人手，只會使進度更加。9.向軟件工程中增派人手從三個方面增加了工程必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。外科手術隊伍1.同樣有兩年經(jīng)驗而且在受到同樣的培訓的情況下，優(yōu)秀的專業(yè)程序員的工作效率是較差程序員的十倍。關于這一條我在極限編程里看到，sackman和humphrey分別做了實驗發(fā)現(xiàn)優(yōu)秀程序員工作效率比擬差程序員的工作效率最高要高達28倍。2.小型、精干隊伍是最好的。這一點在軟件工藝和極限編程里都得到了充分的表達。3.兩個人的團隊，其中一個工程經(jīng)理，常常是最正確的人員使用方法。4.對于真正意義上的大型系統(tǒng)，小型精干的隊伍太慢了。5.實際上，絕大多數(shù)大型編程系統(tǒng)的經(jīng)驗顯示出，一擁而上的開發(fā)方法是高本錢、速度緩慢、不充分的，開發(fā)出的產(chǎn)品無法進行概念上的集成。6.一位首席程序員、類似于外科手術隊伍的團隊架構提供了一種方法，既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性，又能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量。圖1是10人的程序開發(fā)隊伍溝通模式。圖110人程序開發(fā)隊伍溝通模式貴族專制、民主政治和系統(tǒng)設計1.概念完整性是系統(tǒng)設計中最重要的考慮因素。2.為了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊來完成。3.對于非常大型的工程，將設計方法、體系結(jié)構方面的工作與具體實現(xiàn)相別離是獲得概念完整性的強有力方法。4.紀律、規(guī)那么對行業(yè)是有益的。外部的體系結(jié)構規(guī)定實際上是增強，而不是限制實現(xiàn)小組的創(chuàng)造性。5.體系結(jié)構、設計實現(xiàn)、物理實現(xiàn)的許多工作可以并發(fā)進行。畫蛇添足1.盡早交流和持續(xù)溝通能使結(jié)構師有較好的本錢意識，以及使開發(fā)人員獲得對設計的信心，并且不會混淆各自的責任分工。2.結(jié)構師如何成功地影響實現(xiàn)：i.牢記是開發(fā)人員承當創(chuàng)造性的實現(xiàn)責任；結(jié)構師只能提出建議。ii.聽取開發(fā)人員在體系結(jié)構上改進的建議。3.第二個系統(tǒng)是人們所設計的最危險的系統(tǒng)，通常的傾向是過分地進行設計。關于這一點也許是正確的，但是這是一個回避不了的問題，如果沒有開發(fā)第二個系統(tǒng)經(jīng)驗的人，就不可能有開發(fā)第三個系統(tǒng)經(jīng)驗的人了。貫徹執(zhí)行1.即使是大型的設計團隊，設計結(jié)果也必須由一個或兩個人來完成，以確保這些決定是一致的。2.必須明確定義體系結(jié)構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。3.出于精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。4.允許體系結(jié)構師對實現(xiàn)人員的詢問做出應答解釋是非常重要的，并且必須進行日志記錄和發(fā)布。5.工程經(jīng)理最好的朋友就是他每天要面對的敵人--獨立的產(chǎn)品測試機構/小組。為什么巴比倫塔會失??？1.巴比倫塔工程的失敗是因為缺乏交流，以及交流的結(jié)果的組織。2.因為左手不知道右手在做什么，從而進度災難、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)。由于對其他人的各種假設，團隊成員之間的理解開始出現(xiàn)偏差。3.團隊應該以盡可能多的方式進行相互之間的交流：非正式、常規(guī)工程會議，會上進行簡要的技術陳述、共享的正式工程工作手冊。胸有成竹1.僅僅通過對編碼局部的估計，然后乘以任務其他局部的相對系數(shù)，是無法得出對整項工作的精確估計的。2.構建獨立小型程序的數(shù)據(jù)不適用于編程系統(tǒng)工程。3.程序開發(fā)與程序規(guī)模成指數(shù)增長趨勢。4.當使用適當?shù)母呒壵Z言時，程序編制的生產(chǎn)率可以提高5倍。削足適履這一章主要是要解決工程投資與磁盤空間和內(nèi)存之間的矛盾，但是這個矛盾在電腦硬件開展到現(xiàn)在的層次已經(jīng)可以忽略掉了。提綱挈領1.軟件工程的要求：目標、用戶手冊、內(nèi)部文檔、進度、預算、組織機構圖和工作空間分配。2.即使是小型工程，工程經(jīng)理也應該在工程早期規(guī)范化上述的一系列文檔。這一章強調(diào)文檔重要性，但并沒有將一些教條主義的道理讓你相信文檔的重要性，而是給工程經(jīng)理給出了實實在在的操作步驟。未雨綢繆1.對于大多數(shù)工程，第一個開發(fā)的系統(tǒng)并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。系統(tǒng)的丟棄和重新設計可以一步完成，也可以一塊塊地實現(xiàn)。這是個必須完成的步驟，如果將開發(fā)的第一個系統(tǒng)丟棄原型發(fā)布給用戶，可以獲得時間，但是它的代價很高。對于用戶，使用極度痛苦；對于重新開發(fā)的人員，分散了精力；對于產(chǎn)品，影響了聲譽，即使最好的再設計也難以名聲。2.用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化。3.軟件產(chǎn)品易于掌握的特性和不可見性，導致了它的構建人員面臨著永恒的需求變更。4.目標和開發(fā)策略上的一些正常變化無可防止，事先為它們做準備總比假設它們不會出現(xiàn)要好得多。5.對于一個廣泛使用的程序，其維護總本錢通常是開發(fā)本錢的40％或更多。6.維護本錢受用戶數(shù)目的嚴重影響。用戶越多，所發(fā)現(xiàn)的錯誤也越多。7.campbell指出了一個顯示產(chǎn)品生命期中每月bug數(shù)的有趣曲線，它先是下降，然后攀升。8.缺陷修復總會以（20－50）%的機率引入新的bug。9.在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統(tǒng)不會以更隱蔽的方式被破壞。10.同樣，設計實現(xiàn)的人員越少、接口越少，產(chǎn)生的錯誤也就越少。11.所有修改都傾向于破壞系統(tǒng)的架構，增加了系統(tǒng)的程度。即使是最熟練的軟件維護工作，也只是放緩了系統(tǒng)退化到不可修復的進程。干將莫邪工程經(jīng)理應該制訂一套策略，以及為通用工具的開發(fā)分配資源，與此同時，他還必須意識到專業(yè)工具的需求。禍起蕭墻1.一天一天的進度比起重大災難，更難以識別，更不容易防范和更加難以彌補。2.根據(jù)一個嚴格的進度表來控制工程的第一個步驟是制訂進度表，進度表由里程碑和日期組成。3.里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。4.如果里程碑定義得非常明確，以致于無法自欺欺人時，程序員很少會就里程碑的進展弄虛作假。另外一面1.對于軟件編程產(chǎn)品來說，程序向用戶所呈現(xiàn)的面貌與提供給機器識別的內(nèi)容同樣重要。2.即使對于完全開發(fā)給自己使用的程序，描述性文字也是必須的，因為它們會被用戶和作者所遺忘。3.文檔能在整個軟件開發(fā)的生命周期對程序員克服懶惰和進度的壓力起促進激勵作用，但向編程人員成功地灌輸對待文檔的積極態(tài)度是一件困難的事情。4.為了使文檔易于維護，將它們合并至源程序是至關重要的，而不是作為獨立文檔進行保存。沒有銀彈人狼的傳說可能有人聽過也可能沒聽過，人狼是一種具有人和狼兩種特征的恐怖生物，而銀彈是消滅它的一種最有效的子彈，如果看過《吸血鬼傳說》也許就能和容易的理解這一點。作者將軟件開發(fā)比作人狼，而將提高軟件開發(fā)效率的方法比作銀彈。作者預言未來十年，想要試圖通過尋找一種有效地銀彈將軟件開發(fā)效率提高一個甚至幾個數(shù)量級，這種銀彈不可能出現(xiàn)。沒有銀彈這篇文章里作者列舉出了當時一些非常先進的技術或思想理念，例如ada和其他高級編程語言、面向?qū)ο缶幊?、人工智能、專家系統(tǒng)、"自動"編程、圖形化編程、程序驗證、環(huán)境和工具、工作站等。雖然這些先進技術在一定程度上提高了軟件開發(fā)的效率，但是始終沒有到達銀彈的效果。距離作者的預言已經(jīng)過去有20多年了，縱觀現(xiàn)在的軟件開發(fā)領域，雖然新技術層出不窮，但是還是沒有一種銀彈能夠讓軟件開發(fā)產(chǎn)生一次革命。焦油坑依然存在軟件工程的焦油坑在將來很長一段時間內(nèi)會繼續(xù)困擾著人們。由于軟件系統(tǒng)多變性和錯綜復雜性，這個行業(yè)只能是一步一個臺階的往上爬，而出現(xiàn)銀彈的希望在我們可以想象的時間范圍內(nèi)是非常渺茫的。我們將長期與焦油作斗爭。第1章焦油坑這一章分成兩個局部：?程序（program）、程序產(chǎn)品（programmingproduct）、編程系統(tǒng)（programmingsystem）、編程系統(tǒng)產(chǎn)品（programmingproductsystem）的概念?程序員的工作性質(zhì)比擬有意思的是第一局部的四個概念。在作者的眼中，程序就是一堆代碼，任何人可以宣稱自己會編程，但是編程得到的只是程序，而不是產(chǎn)品。程序要成為程序產(chǎn)品，需要有明確的輸入、功能和輸出，經(jīng)過完備的測試，具備合格的文檔，使之功能可靠，維護易行。編程系統(tǒng)是從系統(tǒng)的角度來看待功能完整的程序模塊，要求程序要具備語法和語義精確的接口，能夠與其他的程序進行流暢的交互。相比程序產(chǎn)品來說，不僅僅要嚴格測試程序自身的輸入、處理、輸出，還要測試與不同程序之間的交互，因為很多bug其實是隱含在不同功能模塊的交互過程中。另外編程系統(tǒng)還要考慮程序之外的軟硬件運行環(huán)境。呵呵，只有經(jīng)過了集成測試之后才能稱之為編程系統(tǒng)。最高級的形式是編程系統(tǒng)產(chǎn)品，從書中的表述來看，就是編程系統(tǒng)+各類文檔，文檔是為了后續(xù)維護和升級方便而準備的。智力產(chǎn)品如果沒有說明書真是一場噩夢啊，之前我們經(jīng)歷過的不少系統(tǒng)到了后續(xù)維護的時候發(fā)現(xiàn)文檔補齊，維護人員真是傷透腦筋，最后問題太多了索性就提議推倒重做?？梢哉f如果是文檔齊備一點，我們公司很多系統(tǒng)的壽命是可以更長的。第2章人月神話人月神話讀書筆記(一)第一章焦油坑外表上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和積累在一起的時候，團隊的行動就會變得越來越慢。對問題的麻煩程度，每個人似乎都會感到驚訝，并且很難看清問題的本質(zhì)。不過，如果我們想解決問題，就必須試圖先去理解它。--清楚地解釋系統(tǒng)開發(fā)的困難所在。這，就是編程。一個許多人痛苦掙扎的焦油坑以及一種樂趣和苦惱共存的創(chuàng)造性活動。對于許多人而言，其中的樂趣遠大于苦惱。而本書的剩余局部將試圖搭建一些橋梁，為通過這樣的焦油坑提供一些指導。--本書的目的第二章人月神話1.在眾多軟件工程中，缺乏合理的時間進度是造成工程滯后的最主要原因，它比其他所有因素加起來的影響還大。導致災難的原因是：首先，我們對估算技術缺乏有效的研究。第二，我們采用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆第三，由于對自己的估算缺乏信心，軟件經(jīng)理通常不會有耐心持續(xù)地進行估算這項工作。第四，對進度缺少跟蹤和監(jiān)督。第五，當意識到進度的偏移時，下意識（以及傳統(tǒng)）的反響是增加人力。2.系統(tǒng)開發(fā)過程中，樂觀主義并不應該是理所應當?shù)?。在單個任務中，“一切都將運轉(zhuǎn)正常”的假設在時間進度上具有可實現(xiàn)性。因為所遇的延遲是一個概率分布曲線，“不會延遲”僅具有有限的概率，所以現(xiàn)實情況可能會像計劃安排的那樣順利。然而大型的編程工作，或多或少包含了很多任務，某些任務間還具有前后的次序，從而一切正常的概率變得非常小，甚至接近于無。3.本錢確實隨開發(fā)產(chǎn)品的人數(shù)和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規(guī)模是一個危險和帶有欺騙性的神話。它暗示著人員數(shù)量和時間是可以相互替換的。因為軟件開發(fā)本質(zhì)上是一項系統(tǒng)的工作--錯綜復雜關系下的一種實踐--溝通、交流的工作量非常大，它很快會消耗任務分解所節(jié)省下來的個人時間。從而，添加更多的人手，實際上是延長了，而不是縮短了時間進度。4.在時間進度中，順序限制所造成的影響，沒有哪個局部比單元測試和系統(tǒng)測試所受到的牽涉更徹底。對于任務的進度安排，以下是作者使用了很多年的經(jīng)驗法那么：1/3計劃1/6編碼1/4構件測試和早期系統(tǒng)測試（單元測試）1/4系統(tǒng)測試5.如果發(fā)現(xiàn)工程的實際進度滯后于預計的進度，工程經(jīng)理最好的方法是重新安排進度，而不是增加工程人手。6.工程的時間依賴于順序上的限制，人員的數(shù)量依賴于單個子任務的數(shù)量。從這兩個數(shù)值可以推算出進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產(chǎn)品可能過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表?？傊诒姸嘬浖こ讨?，缺乏合理的時間進度是造成工程滯后的最主要原因，它比其他所有因素加起來的影響還要大。第三章外科手術隊伍1.對于效率和概念的完整性來說，最好由少數(shù)干練的人員來設計和開發(fā)，而對于大型系統(tǒng)，那么需要大量的人手，以使產(chǎn)品能在時間上滿足要求。如何調(diào)和這兩方面的矛盾呢？--本章要解決的問題2.mills的建議：外科醫(yī)生（首席程序員）：定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書寫技術文檔。副手：主要作用是作為設計的思考者、討論者和評估人員。管理員：控制財務、人員、工作地點安排和機器，充當組織中其他管理機構的接口。：根據(jù)外科醫(yī)生的草稿或者口述的手稿，進行分析和重新組織，提供各種參考和書目，對多個版本進行維護以及監(jiān)督文檔生成的機制。兩個秘書程序職員：維護編程產(chǎn)品庫中所有團隊的技術記錄。工具維護人員：保證所有基本服務的可靠性，以及承當團隊成員所需要的特殊工具（特別是交互式計算機服務）的構建、維護和升級責任。測試人員：各個功能設計系統(tǒng)測試用例的對頭，同時也是日常調(diào)試設計測試數(shù)據(jù)的助手。負責計劃測試的步驟和為測試搭建測試平臺。語言專家：尋找一種簡潔、有效的使用語言的方法來解決復雜、晦澀或者棘手的問題。3.當進行大系統(tǒng)開發(fā)時：要有一個系統(tǒng)結(jié)構師從上至下地進行所有的設計。要使工作易于管理，必須清晰地劃分體系結(jié)構設計和實現(xiàn)之間的界線，系統(tǒng)結(jié)構師必須一絲不茍地專注于體系結(jié)構。第四章貴族專制、民主政治和系統(tǒng)設計1.概念一致性在系統(tǒng)設計中，概念完整性應該是最重要的考慮因素。也就是說為了反映一系列連貫的設計思路，寧可省略一些不規(guī)那么的特性和改進，也不提倡獨立和無法整合的系統(tǒng)，哪怕它們其實包含著許多很好的設計。2.功能與理解上復雜程度的比值才是系統(tǒng)設計的最終測試標準。但是功能本身或者易于使用都無法成為一個好的設計評判標準。3.簡潔和直白概念的完整性。每個局部必須反映相同的原理、原那么和一致的折衷機制。在語法上，每個局部應使用相同的技巧；在語義上，應具有同樣的相似性。因此，易用性實際上需要設計的一致性和概念上的完整性。4.概念的完整性要求設計必須由一個人，或者非常少數(shù)互有默契的人員來實現(xiàn)。5.系統(tǒng)的體系結(jié)構(architecture)指的是完整和詳細的用戶接口說明。體系結(jié)構必須同實現(xiàn)仔細地區(qū)分開來。6.作者不認為只有結(jié)構師才有好的創(chuàng)意。新的概念經(jīng)常實現(xiàn)者或者用戶。然而系統(tǒng)的概念完整性決定了使用的容易程度。不能與系統(tǒng)基本概念進行整合的良好想法和特色，最好放到一邊，不予考慮。如果出現(xiàn)了很多非常重要但不兼容的構想，就應該拋棄原來的設計，對不同基本概念進行合并，在合并后的系統(tǒng)上重新開始。7.概念的完整性確實要求系統(tǒng)只反映唯一的設計理念，用戶所見的技術說明來自少數(shù)人的思想。實際工作被劃分成體系結(jié)構、設計實現(xiàn)和物理實現(xiàn)，但這并不意味著該開發(fā)模式下的系統(tǒng)需要更長的時間來創(chuàng)立。經(jīng)驗顯示恰恰相反，整個系統(tǒng)將會開發(fā)得更快，所需要的測試時間將更少。同工作的水平分割相比，垂直劃分從根本上大大減少了勞動量，結(jié)果是使交流徹底地簡化，概念完整性得到大幅提高。第五章畫蛇添足1.本章的目標：結(jié)構設計師要防止向系統(tǒng)中添加很多不實際的功能（防止畫蛇添足）。2.盡早交流和持續(xù)溝通能使結(jié)構師有較好的本錢意識，以及使開發(fā)人員獲得對設計的信心，并且不會混淆各自的責任分工。3.面對估算過高的難題，結(jié)構師有兩個選擇：削減設計或者建議本錢更低的實現(xiàn)方法--挑戰(zhàn)估算的結(jié)果。后者是固有的主觀感性反響。此時，結(jié)構師是在向開發(fā)人員的做事方式提出挑戰(zhàn)。想要成功，結(jié)構師必須牢記是開發(fā)人員承當創(chuàng)造性和創(chuàng)造性的實現(xiàn)責任，所以結(jié)構師只能建議，而不能支配；時刻準備著為所指定的說明建議一種實現(xiàn)的方法，同樣準備接受其他任何能到達目標的方法；對上述的建議保持低調(diào)和平靜；準備放棄堅持所作的改進建議。4.一個可以開闊結(jié)構師眼界的準那么是為每個小功能分配一個值：每次改進，功能x不超過m字節(jié)的內(nèi)存和n微秒。這些值會在一開始作為決策的向?qū)?，在物理實現(xiàn)期間指南和對所有人的警示。5.工程經(jīng)理必須堅持至少擁有兩個系統(tǒng)以上開發(fā)經(jīng)驗的結(jié)構師的決定。同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原那么上的概念和目標在詳細設計中得到完整的表達。第六章貫徹執(zhí)行1.問題：工程經(jīng)理如何確保每個人聽從、理解并實現(xiàn)結(jié)構師的決策？對于有多個結(jié)構師的小組如何保持系統(tǒng)概念上的完整性。2.手冊、或者書面規(guī)格說明，是一個非常必要的工具。手冊是產(chǎn)品的外部規(guī)格說明，它描述和規(guī)定了用戶所見的每一個細節(jié)；同樣的，它也是結(jié)構師主要的工作產(chǎn)物。手冊不但要描述包括所有界面在內(nèi)的用戶可見的一切，它同時還要描述用戶看不見的事物。后者是編程實現(xiàn)人員的工作范疇，而實現(xiàn)人員的設計和創(chuàng)造是不應該被限制的。體系結(jié)構設計人員必須為自己描述的任何特性準備一種實現(xiàn)方法，但是他不應該試圖支配具體的實現(xiàn)過程。規(guī)格說明的風格必須清晰、完整和準確。用戶常常會單獨提到某個定義，所以每條說明都必須重復所有的基本要素，所以所有文字都要相互一致。3.規(guī)格說明中，形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更快地完成。但是形式化定義的缺點是不易理解。記敘性文字那么可以顯示結(jié)構性的原那么，描述階段上或?qū)哟紊系慕Y(jié)構，以及提供例子。應同時包括形式化和記敘性定義兩種方式。4.通過會議的方式，開發(fā)人員進行溝通和討論問題。5.不同實現(xiàn)之間嚴格要求相互兼容。如果起初至少有兩種以上的實現(xiàn)，那么定義會更加整潔和規(guī)范。6.對于存有疑問的實現(xiàn)人員，應鼓勵他們打詢問相應的結(jié)構師，而不是一邊自行猜測一邊工作。一種有用的機制是由結(jié)構師保存日志。日志中，他記錄了每一個問題和相應的回答。每周，對假設干結(jié)構師的日志進行合并，重新，并發(fā)布給用戶和實現(xiàn)人員。這種機制很不正式，但非?？旖莺鸵子诶斫?。7.在最后的分析中，用戶是獨立的監(jiān)督人員。在殘酷的現(xiàn)實使用環(huán)境中，每個細微缺陷都將無從遁形。產(chǎn)品測試小組那么是顧客的代理人，專門尋找缺陷。不時地，細心的產(chǎn)品測試人員總會發(fā)現(xiàn)一些沒有貫徹執(zhí)行、設計決策沒有正確理解或準確實現(xiàn)的地方。出于這方面的原因，設立測試小組是使設計決策得以貫徹執(zhí)行的必要手段，同樣也是需要盡早著手，與設計同時實現(xiàn)的重要環(huán)節(jié)。第七章為什么巴比倫塔會失敗1.工程人員之間的交流和溝通是工程能否順利和成功的一個重要因素。2.缺乏交流引起進度災難、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)。隨著工作的進行，許多小組慢慢地修改自己程序的功能、規(guī)模和速度，他們明確或者隱含地更改了一些有效輸入和輸出結(jié)果用法上的約定。團隊如何進行相互之間的交流溝通：清晰定義小組內(nèi)部的相互關系和充分利用，能鼓勵大量的溝通，從而到達對所書寫文檔的共同理解。常規(guī)工程會議。會議中，團隊一個接一個地進行簡要的技術陳述。這種方式非常有用，能澄清成百上千的細小誤解。在工程的開始階段，應該準備正式的工程工作手冊。3.工程工作手冊不是獨立的一篇文檔，它是對工程必須產(chǎn)出的一系列文檔進行組織的一種結(jié)構。工程所有的文檔都必須是該結(jié)構的一局部。這包括目的、外部規(guī)格說明、接口說明、技術標準、內(nèi)部說明和管理備忘錄。4.使用工程工作手冊的原因：技術說明幾乎是必不可少的。如果某人就硬件和軟件的某局部，去查看一系列相關的用戶手冊。他發(fā)現(xiàn)的不僅僅是思路，而且還有能追溯到最早備忘錄的許多文字和章節(jié)，這些備忘錄對產(chǎn)品提出建議或者解釋設計。正確的文檔結(jié)構非常重要。事先將工程工作手冊設計好，能保證文檔的結(jié)構本身是規(guī)范的。另外，有了文檔結(jié)構，后來書寫的文字就可以放置在合適的章節(jié)中?？刂菩畔l(fā)布，確保信息能到達所有需要它的人的手中。5.團隊組織的目的是減少不必要的交流和合作的數(shù)量。減少交流的方法是人力劃分和限定職責范圍。當使用人力劃分和職責限定時，樹狀管理結(jié)構所映出對詳細交流的需要會相應減少。第八章胸有成竹1.問題：系統(tǒng)編程需要花費多長時間？需要多少工作量？如何進行估計？2.工作量是規(guī)模的冪函數(shù)。portman的數(shù)據(jù)：工作花費的時間大約是估計的兩倍。aron、harr、os/360的數(shù)據(jù)：生產(chǎn)率會根據(jù)任務本身的復雜度和困難程度表現(xiàn)出顯著差異。carbato的數(shù)據(jù)：對常用的編程語句而言。生產(chǎn)率似乎是固定的。這個固定的生產(chǎn)率包括了編程中需要注釋，并可能存在錯誤的情況。使用適當?shù)母呒壵Z言，編程的生產(chǎn)率可以提高5倍。第九章削足適履1.系統(tǒng)的空間規(guī)模：規(guī)模是軟件系統(tǒng)產(chǎn)品用戶本錢中如此大的一個組成局部，開發(fā)人員必須設置規(guī)模的目標，控制規(guī)模，考慮減小規(guī)模的方法。同任何開銷一樣，規(guī)模本身不是壞事，但不必要的規(guī)模是不可取的。2.對工程經(jīng)理而言，規(guī)模控制既是技術工作的一局部，也是管理工作的一局部。必須研究用戶和他們的應用，以設置將開發(fā)系統(tǒng)的規(guī)模。接著，把這些系統(tǒng)劃分成假設干局部，并設定每個局部的規(guī)模目標。由于規(guī)模--速度權衡方案的結(jié)果在很大的范圍內(nèi)變化，規(guī)模目標的設置是一件頗具技巧的事情，需要對每個可用方案有深刻的了解。聰明的工程經(jīng)理還會給自己預留一些空間，在工作推行時分配。僅對核心程序設定規(guī)模目標是不夠的，必須把所有的方面都編入預算。在指明模塊有多大的同時，確切定義模塊的功能。培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)，面對用戶的態(tài)度。3.在速度不變的情況下，更多的功能意味著需要更多的空間。其中一個技巧是用功能交換尺寸。設計人員必須決定用戶可選工程的精細程度。4.考慮空間--時間的折衷。對于給定的功能，空間越多，速度越快。工程經(jīng)理可以做兩件事來幫助他的團隊取得良好的空間--時間折衷。一是確保他們在編程技能上得到培訓，而不僅僅是依賴他們自己掌握的知識和先前的經(jīng)驗。特別是使用新語言或者新機器時，培訓顯得尤其重要。另一種方法是認識到編程需要技術積累，需要開發(fā)很多公共單元構件。5.戰(zhàn)略上的突破常數(shù)據(jù)或表的重新表達--這是程序的核心所在。數(shù)據(jù)的表現(xiàn)形式時編程的根本。第十章提綱挈領1.文檔的跟蹤維護是工程監(jiān)督和預警的機制。文檔本身可以作為檢查列表、狀態(tài)控制，也可以作為的數(shù)據(jù)基礎。2.軟件工程文檔的內(nèi)容：目標。待完成的目標、迫切需要的資源、約束和優(yōu)先級。軟件開發(fā)網(wǎng)產(chǎn)品技術說明。進度表。資金預算。工作空間分配。人員組織。3.為什么要有正式的文檔首先，書面記錄決策是必要的。人們能從令人迷惑的現(xiàn)象中得到清晰、確定的決策。第二，文檔能作為同其他人溝通的渠道。工程經(jīng)理的基本職責是使每個人都向著相同的方向前進，所以他的工作主要是溝通，而不是做出決定。文檔能極大地減輕他的負擔。最后，文檔可以作為數(shù)據(jù)基礎和檢查列表。通過周期性的回顧，他能清楚工程所處的狀態(tài)，以及哪些需要重點進行更改和調(diào)整。工程經(jīng)理的任務是制訂計劃，并根據(jù)計劃實現(xiàn)。只有書面計劃是精確和可以溝通的。通過遵循文檔開展工作，工程經(jīng)理能更清晰和快速地設定自己的方向。第十一章未雨綢繆1.對于大多數(shù)工程，第一個開發(fā)的系統(tǒng)并不合用。可能太慢、太大，而且難以使用，或者三者兼而有之。要解決所有的問題，除了重新開始以外，沒有其他的方法--即開發(fā)一個更靈巧或者更好的系統(tǒng)。系統(tǒng)的丟棄和重新設計可以一步完成，也可以一塊塊地實現(xiàn)。所有大型系統(tǒng)的經(jīng)驗都顯示，這是必須完成的步驟。--構建一個試驗性的系統(tǒng)，然后拋棄它。2.一旦認識到實驗性的系統(tǒng)必須被構建和丟棄，具有變更思想的重新設計不可防止。3.為變化設計系統(tǒng)，包括細致的模塊化、可擴展的函數(shù)、精確完整的模塊間接口設計、完備的文檔。另外，還可能會采用包括調(diào)用隊列和表驅(qū)動技術。最重要的措施是使用高級語言和自文檔技術，以減少變更引起的錯誤。采用編譯時的操作來整合標準說明，在很大程度上幫助了變化的調(diào)整。變更的階段化是一種必要的技術。每個產(chǎn)品都應該有數(shù)字版本號，每個版本都應該有自己的日程表和凍結(jié)日期。在此之后的變更屬于下一個版本的范疇。4.為變更計劃組織架構和團隊。5.程序維護中的一個基本問題是--缺陷修復總會以(20%--50%)的機率引入新的bug。整個過程是前進兩步，后退一步。作為引入新bug的一個后果，程序每條語句的維護需要的系統(tǒng)測試比其他編程要多，本錢非常高。缺陷不能被徹底修復的原因：首先，看上去很輕微的錯誤，似乎僅僅是局部操作上的失敗，實際上卻是系統(tǒng)級別的問題。其次，維護人員通常不是編寫代碼的開發(fā)人員。5.使用能消除、至少是能指明副作用的程序設計方法，會在維護本錢上有很大的回報。設計實現(xiàn)的人員越少、接口越少，產(chǎn)生的錯誤也就越少。6.維護工作破壞系統(tǒng)的架構，增加了系統(tǒng)的程度。隨著時間的推移，系統(tǒng)變得越來越無序，無法再成為下一步進展的基礎。這時，系統(tǒng)的重新設計完全是必要的。系統(tǒng)軟件開發(fā)是減少度的過程，軟件維護是提高度的過程，即使是最熟練的軟件維護工作，也只是放緩了系統(tǒng)退化的進程?！盾浖こ虒д撟x書心得》隨著it行業(yè)的迅速開展，計算機使用越來越普及，越來越多的領域使用了計算機，特別是一些重要領域如國防、銀行、金融、通訊、航天等，他們對軟件質(zhì)量要求很高。同時一些重大事故的發(fā)生，也引發(fā)了人們對軟件質(zhì)量的關注。如xx年歐洲載重10噸的阿麗亞娜5型火箭發(fā)射失敗，最后證實是軟件質(zhì)量問題；還有國內(nèi)的一些銀行金融系統(tǒng)，因軟件質(zhì)量問題不得不暫停營業(yè)。毋庸置疑，在經(jīng)歷了長期的不為人知和可有可無后，軟件測試目前已變的炙手可熱。隨著中國軟件市場的開展，越來越多的國外資金投向中國軟件行業(yè)。據(jù)報道，中國軟件外包市場的潛力和機會已遠遠超過軟件王國印度，不過由于軟件人才的嚴重缺乏致使我國軟件開展遭遇“瓶頸”。國家為了大力培養(yǎng)軟件人才，不斷采取積極有效的措施。在這里，我我總結(jié)了一學期來的上課聽課心得，在我腦海里反響最為頻繁的同時讓我比擬趕興趣的內(nèi)容就是老師在第七章章節(jié)講到的《實現(xiàn)》，在這章節(jié)里，講述了軟件的實現(xiàn)需要的是以測試為基礎，從而確保在交付之前保證軟件的可靠性。關于軟件測試，軟件測試是軟件開發(fā)過程中必不可少的一個步驟，是用來確認一個軟件的品質(zhì)和性能的好與環(huán)。所謂軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試，甚至根據(jù)需要編寫不同的測試工具，設計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。執(zhí)行測試用例后，需要跟蹤故障，以確保開發(fā)的產(chǎn)品適合需求。軟件測試是個需求高，就職機會大的職業(yè)。目前，我國具備軟件測試能力的人員數(shù)量和市場需求相差巨大，巨大的市場空缺，使軟件測試工程師從初級到高級，只需要1年甚至更短的時間來完成。所以軟件測試行業(yè)，未來的開展空間是非常廣闊的。隨著軟件測試技術的開展，測試方法更加多樣化，針對性更強；選擇合適的軟件測試方法可以讓我們事半功倍。從測試是否針對系統(tǒng)的內(nèi)部結(jié)構和具體實現(xiàn)算法的角度來看，可分為：白盒測試和黑盒測試。從是否需要執(zhí)行被測軟件的角度，可分為：靜態(tài)測試和動態(tài)測試。在測試的過程中，我們一定要碰到的就是bug！有人說，軟件測試就是在尋找軟件中的bug，那么我么有必要搞清楚什么是bug。bug，在英語中是指“小蟲子”的意思，現(xiàn)在泛指計算機中硬件和軟件的錯誤。硬件錯誤有兩個原因：一是設計錯誤，而是硬件老化失效。軟件的錯誤全是廠家的錯誤雖然知道軟件測試這個名詞，但知其然不知其所以然，通過課后的自我復習，讓我明白了什么是軟件測試，作為一個合格的軟件測試人員應當具備的軟件測試知識有哪些，比方說一個完整的測試流程應該是：單元測試—>集成測試—>聯(lián)調(diào)—>系統(tǒng)預測試—>系統(tǒng)測試，當然作為軟件測試人員還應知道常用的軟件測試的工具，軟件測試工具的作用是用來發(fā)現(xiàn)bug并處理，一個好的軟件測試工具和測試管理工具結(jié)合起來使用將會使軟件測試效率大大的提高，對些軟件測試工具的了解讓我明白一個好的軟件真的是來之不易。通過寫這門課程的心得，讓我明白任何知識只要你肯去了解，肯去鉆研，你肯定會得到你想要的結(jié)果，所以我感謝老師給了我們這么好的一個機會再一次的去深層次接觸軟件知識，讓我受益匪淺！軟工專升本一班：黃偉強09670xx0人月神話讀后感二十九年前(1975)﹐ibm大型電腦之父──fredbrooks出版一本書﹕"themythicalman-month"。收集了他在1960年代領導1000多人共同開展os/360大型軟件系統(tǒng)的心得和經(jīng)驗。該書是集﹐其中有一篇文章叫"themythicalman-month"﹐他就以此作為書名。在1956~1965之間﹐brooks實際領導ibm360大型電腦的開發(fā)計劃﹐包括硬體結(jié)構及龐大的os/360作業(yè)系統(tǒng)在內(nèi)﹐因之他具有ibm大型電腦之父的尊稱。由于os/360是多達1000位程式師共同合作的大型軟件開發(fā)工作﹐讓他深刻了解到大型軟件開發(fā)的技術和管理上所面臨的種種困難和挑戰(zhàn)。于是﹐他就將其領導開發(fā)os/360軟件系統(tǒng)的經(jīng)驗心得收集在這本書里。人們常拿man-month（多少人﹐做多少個月）來計算軟件的工作量﹐但是brooks發(fā)現(xiàn)軟件的開發(fā)工作是需要人與人之間密切溝通的﹐使得設計工作不易分割﹐所以man-month為單位的計算方法是有問題的(mythical)。也就得出著名的brooks法那么──「對于進度已的軟件開發(fā)計劃而言﹐假設再增加人力﹐只會讓其更加?！?addingmanpowertoalatesoftwareprojectmakesitlater)這是該書名稱的涵義?？赐甏藭螅野l(fā)現(xiàn)人月神話無處不在，其實在我們做軟件工程來說，此書已經(jīng)滲透進去了。本書作者為人們管理復雜工程提供了頗具洞察力的見解，既有很多發(fā)人深省的觀點，也有大量的軟件工程實踐。本書對我觸動最大的，一是保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作為一個軟件，一個系統(tǒng)，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創(chuàng)新開展都必須與基本的概念相吻合。具體的實現(xiàn)人員可以細化概念，但只有總設計者才有否認與開展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認為理所當然的規(guī)那么或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。概念的完整性，對于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經(jīng)理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對于大規(guī)模的軟件系統(tǒng)，那么必須通過樹狀組織結(jié)構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。二是“一個拿2倍工資的人，生產(chǎn)率可能是其他人的10倍?！辈恢榔渌镜某绦騿T們?nèi)绾慰?。我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。組建一個團隊，最好的就是那種精英團隊。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難。三是進度與增加人力。記得當年看《c＋＋編程思想》，bruce說“十個婦女不能在一個月內(nèi)生下小孩”（大意），于我心有戚戚焉。而本書作者brooks得出的結(jié)論是對我是震撼性的：“向進度的工程中增加人手，只會使進度更加”。以前，增加人手基本是挽救進度工程的主要方法。這個方法行不通的話，難道只有“加班”一條路了？如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么。。。。。唯一的方法還是只有….加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比擬強大的設計者）。那么，就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續(xù)向者目標前進。不同的社會經(jīng)驗，不同的思想狀態(tài)，對讀本書的心得也不一樣。在此我說說書中許多非常好的觀點。1.外科手術隊伍thesurgicalteam工程經(jīng)理在工程的初期必須清楚的估計工程的人月運作模式（時間、人力在工程各階段的分配），例如什么時候需要出什么樣成果，決定了什么時候需要什么樣的人加入工程，這是工程經(jīng)理的責任。2.貴族專制，民主政治aristocracy,democracy,system要獲得概念的完整性，設計必須由一個人或具有共識的小組來完成。3.畫蛇添足thesecond-systemeffect講述的基本都是基于ibm360操作系統(tǒng)以及編譯程序等方面的經(jīng)驗，講述如何防止開發(fā)第二個系統(tǒng)的風險，作者認為開發(fā)第二個系統(tǒng)的設計師設計出來的系統(tǒng)是最危險的,因此要求他們自律。4.貫徹執(zhí)行passingtheword印象比擬深刻的是"體系結(jié)構設計人員必須為自己描述的任何特性準備一種實現(xiàn)方法，但他不應該支配具體的實現(xiàn)過程。"5.巴比倫塔會失敗whydidthetowerofbabelfail?講述巴比倫塔會失敗的原因是缺乏交流。6.胸有成竹callingtheshot主要講述如何計算編程時間，以及提出幾個人的經(jīng)驗算法。講述的各種算法可能都不太適合與現(xiàn)在的高級語言，但portman的觀點仍然適合現(xiàn)在，即編程人員實際的編程時間只有50%，其他的時間都花在了無關的瑣碎事情上。