前言

　　最近由於工作的感悟和需要，希望能夠成體系得重新思考研發部門的實施方案以及與之配到的人員分工、結構層次、績效考核以及協作流程等內容。於是就想起了軟體工程這個學科，希望藉助重新閱讀《軟體工程——實踐者的研究方法（第8版）》一書，能夠理通我這條路，讓我能夠找到合適的思路和落地的方案。
　　已經讀了兩章，第一章：軟體的本質，第二章，軟體工程。說實話，我的內心是很震驚的。因為，在十年前，我剛開始讀軟體工程這個專業的時候，因為我爸的問題，他問我說：軟體工程是什麼呀，和電腦科學與技術那個專業有什麼區別呀。我一個高中畢業生懂什麼嘛，所以，就帶著問題來上大學。剛入學拿到課程表，發現，沒人說這事，也沒哪提到了，但是，聽說軟體工程，是門課，於是我就去圖書館借了兩本講軟體工程書回來讀了讀，隱約記得叫軟體工程導論。說實話，沒讀完，讀到後面就讀不懂了。但是，我瞭解了軟體工程的歷史，以及他要解決的問題，和他的基本方法論。由於軟體危機，人們希望用工程化的方法解決軟體開發不可控的問題，使用的過程模型是以瀑布式模型為出發，逐漸深入的迭代和螺旋模型啥的，要達到的目標分為穩定性、可擴充套件性、健壯性、可維護性等等。後面工作後發現，人們都拿這些東西當笑話看，說這些是對的，但是並不會執行。隨著工作的深入，認識到為什麼，也開始接觸敏捷等方法論，也有過部分的實踐。但是，我還是覺得我沒法分析這個問題，甚至無法描述我要解決的問題。當我再尋求答案讀到這兩章的時候，第一次在書中感慨，時代在進步，軟體工程的方法論已經如此落地和成熟了。

什麼是軟體

　　教科書上的定義如下：
　　1、指令的集合（計算機程式），通過這些指令可以滿足預期的特性、功能和效能需求。
　　2、資料結構，使得程式可以合理利用資訊
　　3、軟體描述資訊，它以硬拷貝和虛擬形式存在，用來描述程式的操作和使用。
　　但是更完整的解釋或許還是無法讓我們對軟體有感覺，而如果我們說軟體和硬體的區別是：軟體不會“磨損”，不知道大家是不是有醍醐灌頂的感覺，反正我是感覺豁然開朗。
　　但是，軟體雖然不會磨損，但是會退化，因為需求在變化，因為軟體在迭代，一個軟體會逐漸退化解決不了預期的問題，從而不再被人們所使用。

軟體的應用領域

　　書中列舉了七個，我這裡僅作記錄：系統軟體、應用軟體、工程/科學軟體、嵌入式軟體、產品線軟體、web/移動App、人工智慧軟體

遺留軟體

　　遺留軟體一向是一個老大難問題，而其根本原因是需求變了，技術變了。而我們必須承認的一個事實就是，這兩個一定會變的，有變化是正確的，不可阻擋的，所以，我們要讓自己適應變化。

軟體工程

　　　先給定義吧：
　　　1、將系統化的、規範的、可量化的方法應用於軟體的開發、執行和維護，即將工程化方法應用於軟體。
　　　2、對1中所述方法的研究。
　　　可以看到軟體工程大概分兩部分，一部分是使用工程化的方法開發軟體，一部分是研究和改進這些方法。

方法

　　記得不管是上課的時候還是在公司的時候，一提到軟體工程的方法，大家想到的就是一大堆的流程節點和一大堆的規範的文件。而這些，大家之所以抵觸，是因為這些方法成為了團隊的負擔。而這裡也指出了，這些方法也需要可適應性和靈活性。而這種性質，似乎是通過將它的方法論變成一個層次化的技術，來進行的。

質量關注點

　　質量關注點，是根基。怎麼理解呢？任何工程方法（包括軟體工程）必須構建在質量承諾的基礎之上。這又怎麼說呢？我是這麼認為的，我們開發軟體，是為了解決問題，能否在解決問題，解決到什麼程度，是衡量我們的質量的最終標準，而如果沒有這個關注點，一切方法都是空談。我對這個根基的理解，就是這樣了。

過程

　　過程，是軟體工程的基礎。軟體過程將各個技術層次結合在一起，從而使得合理、及時地開發計算機軟體成為可能。，構成了軟體專案管理控制的基礎，建立了工作環境以便於應用技術方法、提交工作產品（模型、文件、資料、報告、表格等）、建立里程碑、保證質量及正確的管理變更。
　　過程，是工作產品構建時所執行的一系列活動、動作和任務的集合。

活動：主要實現寬泛的目標（如與利益相關者進行溝通），與應用領域、專案大小、結果複雜性或者實施軟體工程的重要程度沒有直接關係。
動作：包含了工作產品（如體系結構設計模型）生產過程中的一系列任務。
任務：關注小而明確的目標，能夠產生實際產品（如構建一個單元測試）

　　過程不是對如何構建計算機軟體的嚴格的規定，而是一種具有可適應性的調整方法，以便於工作人員（軟體團隊）可以挑選適合的工作動作和任務集合。其目標通常是及時、高質量地交付軟體，以滿足軟體專案資助方和終端使用者的需求

過程框架

　　如果說 上述過程的定義，給了我們軟體的生產流程核心概念的定義，那麼，過程框架，就是生產流程中，必經環節的詮釋或者說，必須解決的重大問題。
　　溝通 我很詫異這會列在軟體過程之中，也很遺憾，我們一直沒有明確這是一個重要的步驟。在技術工作開始之前，和客戶（及其他利益相關者）的溝通與協作，極其重要，目的是理解利益相關者的專案目標，並收集需求以定義軟體特性與功能。在軟體構建的過程中，我們往往只注意了需要的需求，而遺忘了利益相關者想要解決什麼問題，甚至忘了問，這很可怕，不，這太可怕了。
　　策劃 理解了目標，瞭解了需求，就需要策劃如何落地。值得注意的是，策劃，不是設計或者建模，它是軟體專案計劃，它定義和描述了軟體工程工作，包括需要執行的技術任務、可能的風險、資源需求、工作產品和工作進度計劃。其產出可能是你們的一個專案計劃文件，但是，那個文件，僅僅是這些工作的結果，而不是敲字打出那個文件就可以的，探索清楚這些事項，是需要工作量的。
　　建模 這個環節，大家都比較瞭解，或者，比較熟悉。但是，這也不是為了編寫概要設計文件或者詳細設計文件，而是為了更好地理解問題並找到解決方案，我們需要畫一張草圖來輔助理解整個專案大的構想——體系結構、不通的構建如何結合，以及其他一些特性。我們還可以把草圖不斷細化，以便更好地達到上述目標。這是必要的，如果尚未建立模型，就開始構建，很多時候，我們就可以開始準備下次重新再來了。
　　構建 包括編碼和測試。這是一個誰都不會忽略的環節，但是這也是一個經常被我們放大的環節。為什麼說放大呢？因為前幾步做的不好，所以這一步就不太走得動，或者說會走很多彎路，那麼，就都在這一步買單了。於是，這裡機會做溝通的活，因為我們還沒了解目標或者不是很清晰，所以有些需求不是很明確；我們會做策劃的活，因為當時沒有想得很全；還會做些建模的事，因為發現當初建立的模型串不起來，或者說不通。
　　部署 軟體（全部或者部分增量）交付給使用者，使用者對其進行測評並給出反饋意見。這個步驟，我見過最多的是，收不到反饋意見，也就是沒有使用者測評，只有使用者抱怨，很明顯，是這一步沒有想清楚。
　　上述過程說實話，還是會讓我想到瀑布模型。但是，當時我就有一個思考：其實，瀑布模型是對的，只是我們太死板了。而現在的螺旋模型，敏捷模型以至於測試驅動和極限程式設計，其實，都是這個模型的變種，理論過程並未發生改變，只是經過思考後的不同落地。

普適性活動

　　過程框架定義了軟體生產的基本流程，而普適性活動，則定義實現落地這些過程的活動。
　　軟體專案跟蹤和控制 專案組根據計劃來評估專案進度，並且採取必要的措施保證專案按進度計劃進行。如何保證專案按進度計劃進行，這就是個大問題了，加班？強壓？加人？估計身處這個行業的都會動穿，這些都不是推進軟體進度的好方法。那怎麼做呢？歡迎探討。
　　風險管理 對可能影響專案成果或者產品質量的風險進行評估。這裡，我所經歷的團隊一般都有，但是，問題是，管理者自認為可控的風險是否還是風險？我個人的意見是，是風險，只是危險程度的高低不同罷了。
　　軟體質量保證 確定和執行保證軟體質量的活動。這個就很抽象了，我理解的也不是很具象，歡迎討論，另外，我看看後面的章節是否可以解答我的疑惑。
　　技術評審 評估夫案件工程產品，儘量在錯誤傳播到下一個活動之前發現並清除錯誤。這個活動，我也經常見到，但是，大多數都是走過場。專案組完成概要設計或者什麼，把一幫人叫到會議室講一遍，然後評審的人說通過，然後就完事。看似很正常，不正常的是，我沒見過不通過的。直到我開始做評審的人我才知道為什麼。評審的有效性，是我的責任，但是，專案的按時上線也是我的責任，如果我說評審不通過，那等下次評審，整個專案計劃就會拖後，最後我是一定要倒黴的，但如果通過了，我說點簡單的意見，那就沒我啥事了，因為，最後這件事是可以讓專案組買單的，或者說根本就可以矇混過關，那就你好我好大家好，何必找不自在和所有人作對呢？那為什麼要這樣設定我的責任呢，為什麼要把上限的責任也綁上我呢？無非就是怕中間我支援的不盡心嘛。所以，這件事，領導些要想清楚呀，你們想要的到底是什麼？時間？還是質量？都要？如果只能保一個的時候，你選哪個？
　　測量 定義和收集過程、專案以及產品的度量，以幫助團隊在釋出軟體是滿足利益相關者的要求。同時，測量還可以與其他框架活動和普適性活動配合使用。說實話，我不是很理解該活動，希望後面的章節可以讓我理解，也歡迎討論。
　　軟體配置管理 在整個軟體過程中管理變更帶來的影響。這個，說實話，我不知道怎麼做。但是，從其作用來說，是我們現在的團隊很需要的事情，很期待後續的章節。
　　* 可複用管理*定義工作產品服用的標準（包括軟體構件），並且建立構建複用機制。可複用的構建，其實每個設計者或者開發者都想實現，但是，卻發現每次構建出來的都不會被複用。有的是需求變了，有的是你複用的單元不合適，當然還有一個很重要的東西，沒有納入管理。沒有納入管理，就意味著沒有人知道，沒有人認可，這樣就不會有人探討他的正確性也不會有人思考它是否可以重用，等真到要來用的時候，要麼不用你的重新寫，要麼用你的發現要改很多，所以，納入管理，很重要。
　　工作產品的準備和生產 包括生產產品（如建模、文件、日誌、表格和列表等）所必須的活動。這裡我們就經常性的問題是，認為這些都是順帶著出來的，但是，這些是需要正式的活動的，也就是說，這些東西的產出是需要不低的成本的，否則，你就只能拿到一個應付差事的東西，但那又有什麼用呢。畢竟，我們的根基是質量關注點。

軟體工程實踐

　　這裡我就只列一下書中的提綱吧。
　　實踐的精髓：

1、理解問題（溝通和分析）
2、策劃解決方案（建模和軟體設計）
3、實施計劃（程式碼生成）
4、檢查結果的正確性（測量和質量保證）

　　通用原則：

第一原則：存在價值
第二原則：保持簡潔
第三原則：保持願景
第四原則：關注使用者
第五原則：面向未來
第六原則：提前計劃複用
第七原則：認真思考

方法

　　為構建軟體提供技術上的解決方法（如何做）。也就是過程中的活動具體的落地的解決方案，這裡說的，就不只是編碼的事情了，而是方方面面的技術，比如，如何溝通、如何策劃等。

工具

　　為過程和方法提供自動化或半自動化的支援。如果一件事情做起來成本越低，我們就會更加頻繁得使用。如果迴歸測試是自動的而不是拿人填出來，那我們就可以每天執行，從而得到更高質量的軟體。由此看來，工具很重要。而這些過程、方法、工具中也體現出來了一個觀點，高技術含量可以帶來質的改變，它是無法通過低技術含量的工作相加來達到等同的效果的。

軟體開發神話

　　軟體開發神話，即關於軟體及其開發過程的一些被人盲目相信的說法。下面我就只列舉下吧，解釋的話，篇幅太多，而且，基本就是抄原文了。

• 像所有領域的經理一樣，承擔著軟體職責的專案經理肩負著維持預算、保證進度和提高質量的壓力。就像溺水的人抓住稻草一樣，軟體經理經常依賴軟體神話中的信條，只要它能減輕以上的壓力（即使是暫時性的）。

• 我們已經有一本寫滿軟體開發標準和流程的寶典，難道不能提供我們需要了解的所有資訊嗎。

• 如果我們未能按時完成計劃，我們可以通過增加程式設計師人數而趕上進度（即所謂的“蒙古遊牧”概念）
• 如果決定將軟體外包給第三方公司，就可以放手不管，完全交給第三方公司開發。
• 軟體產品的客戶可能是隔壁的某個人、樓下的一個技術團隊、市場/銷售部門或者簽訂軟體合同的某個外部公司。多數情況下，客戶之所以相信所謂的軟體神話，是因為專案經理和從業人員沒有及時糾正他們的錯誤資訊。軟體神話導致客戶錯誤的期望，最終導致對開發者的不滿。
• 有了對專案目標的大概瞭解，便足以開始編寫程式，可以在之後的專案開發過程中逐步充實細節。
• 雖然軟體需求不斷變更，但是因為軟體是彈性的，因此可以很容易地適應變更。
• 在60多年的程式設計文化的滋養下，軟體開發人員依然深信著各種神話。在軟體業發展早期，程式設計被視為一種藝術。舊有的方式和態度根深蒂固
• 當我們完成程式並將其交付使用之後，我們的任務就完成了。
• 直到程式開始執行，才能評估其質量
• 對於一個成功的軟體專案，可執行程式是唯一可交付的工作成果。
• 軟體工程將導致我們產生大量無用文件，並因此降低工作效率。
  　　嘿嘿，是不是有些分不清上面的是事實還是我們不應該相信的軟體神話？歡迎討論。以上都是我們不應該依靠的軟體神話，否則，你將會為此付出非常大的代價。