經過了乙個月的寒假時間，我大致將《構建之法》閱讀理解完成，發現這本書中有很多精妙有趣的地方，在讀完構建之法這本書後，對軟體開發的整個流程有了一定的認識。在典型的軟體開發流程中，從乙個專案的立項到最後專案的發布，其經過了多個步驟，以此來確保專案的順利進行。在典型開發流程瀑布模型中，為了獲取軟體需求，需要用常用的獲取需求的方法和步驟來。而對於競爭性需求，我們需要nabcd框架來分析和獲取，即需求、做法、好處、競爭和推廣。對於軟體功能的定位和優先順序，即殺手功能、外圍功能、必要需求和輔助需求，通常採用四象限方法。為了更加深入的理解使用者需求，通常需要採用典型使用者和場景的方法。在軟體開發過程中存在兩種型別的說明書：軟體功能說明書和軟體技術說明書，其中軟體功能說明書主要用來說明軟體的外部功能和使用者互動情況，而軟體技術說明書則用來說明軟體內部的設計規範。而為了將使用者的需求變成可以直接進行的開發工作並源源不斷地實現這些需求，需要功能驅動的設計。軟體開發的生命週期中，在不同階段需要使用不同的測試方法，比如在遠景和計畫階段進行測試計畫和測試設計說明書，同時收集使用者對非功能測試的需求，在開發階段需要單元測試，功能和場景測試，建立回歸測試基準，探索式測試，整合測試，同時開展非功能性的測試，在穩定階段需要進行驗收測試。為了讓整個軟體開發的工作更加高效，需要設定pm職位，以此來協調軟體開發工作中除了開發和測試之前的一切事情。而在軟體穩定和發布階段，可以使用軟體按時發布的招數：dcr與zbb，針對出現的不同問題，可以有不同的解決方案，以便於軟體的正常發布，rtw最終發布版本。而為了保證軟體的質量，需要達到一定的cmmi等級。在閱讀過程中，出現了一些困惑，具體如下：
1．對於軟體中相互獨立的幾個層次，進行單元測試時層次之間有無測試順序的問題。
2. 在實際工作中結對程式設計能否實現？如何分配結對程式設計兩個人的工作量？公司如何衡量結對程式設計兩個人的工作量。
3. 根據瀑布模型進行開發過程的後期中，如果相鄰兩步之間進行回溯時，之前的步驟是否需要做出改變？
4. 最終設計文件出現在程式設計、編碼和測試階段？
5. 在敏捷開發任務認領的階段，如果乙個任務比較困難，沒有團隊認領，該如何解決？
6. 軟體版本的發布和後續bug的修復之間應該如何取捨？
7. 在競爭性需求分析中，如果我方的輔助性優勢明顯弱於競爭產品，那麼為了持平這方面的弱勢，是參照競爭產品還是？如果參照競爭產品，會不會****？
8. pm在與開發團隊交流溝通時，需要具備什麼樣的技能？
9. 各種測試方法。單元測試過程中如何保證所測試模組的正確性，怎麼提高單元測試的正確率？單元測試用例什麼數目最優？在單元測試是否需要考慮極端情況？
構建之法讀後感
書中有提到一句名言 軟體 資料結構 演算法 但是，在真正進行軟體開發時，我們會發現 我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式，擴充套件...
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...
構建之法讀後感
第一章 軟體工程。寫軟體就是碼 寫出來，組合語句和演算法，實現需要的功能。但是軟體的開發需要一定步驟，有團隊合作精神，經過需求分析明白客戶需求，要什麼功能，並完成軟體的概要設計，再進行討論並與客戶溝通。然後進行軟體設計，然後程式 編寫，軟體測試debug，體驗版，後續維護等等。這樣才是乙個專案。軟體...