1、在像我一樣沒有什麼基礎的人要怎麼學習好建構之法？
這本書讓我更加認識到實踐的重要性，要從做中學。隻有實踐了才能夠真正發現自己的不了解的知識，還能夠促進學習的效率。這個學期我自己寫代碼，做火車訂票系統，以前認為學會的知識，一開始做的時候，感覺實踐應用和己看書了解有出入。以前認為這樣做是對的，現在感覺那樣做更簡單，減少代碼量。比如通用函數的封裝，以前感覺沒有必要，現在自己寫代碼的時候，感覺封裝能大大簡化代碼。
2、軟體的需求分析我們應該從哪方面具體分析？
軟體需求分析就是把軟體計劃期間建立的軟體可行性分析求精和細化，分析各種可能的解法，并且配置設定給各個軟體元素。需求分析是軟體定義階段中的最後一步，是确定系統必須完成哪些工作，也就是對目标系統提出完整、準确、清晰、具體的要求
3、很重要的團隊合作我們要怎麼做起？并且書中提到‘靈活的團隊‘要怎麼實作？
靈活開發以使用者的uandui需求進化為核心，采用疊代、循序漸進的方法進行軟體開發。在靈活開發中，軟體項目在建構初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可內建和可運作使用的特征。換言之，就是把一個大項目分為多個互相聯系，但也可獨立運作的小項目，并分别完成，在此過程中軟體一直處于可使用狀态。
4、學習完建構之法，怎麼應用軟體工程這門課來為我服務？
《建構之法：現代軟體工程》，感覺對于軟體工程這門課程不再那麼的空洞，作者把軟體開發方法講得清晰有趣實用，對于許多對軟體開發有興趣的同學，又燃起了更大的興趣與熱情。不再是軟體工程所讨論的代碼量巨大，涉及人數衆多，項目需求多變，抛開軟體工程也能完成，甚至更快捷。絕大部分軟體都是由多人合作完成的，大家的工作互相有依賴關系。軟體的很多錯誤是來源于程式員對子產品功能的誤解，疏忽或者不了解子產品的變化。單元測試就是一個有效的解決方案。軟體開發流程不隻是團隊的流程，還包括個人開發流程。在軟體工程的語境裡，“靈活流程”是一系列價值觀和方法論的集合。從2001年開始，一些軟體界的專家開始倡導“靈活”的價值觀和流程。人們為了解決現實社會和生活中的各種問題，要求助于軟體。軟體團隊需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，不同的項目需要不同的手段。《建構之法：現代軟體工程》是理論和實踐相結合。講現代理論，同時講展現理論的工具。
5、團隊之中如果有拖後腿的人要怎麼辦？
在一個團隊裡面總有那麼一個人會不跟着團隊的腳走的 是以正視一下這個現象就好 要想解決這個問題的話 首先要了解這個人是因為什麼原因老是拖團隊的後腿 是因為個人能力問題還是因為個人的不配合 如果是個人的能力問題的話 那麼你可以配置設定給他一些他力所能及的事情讓他做 如果是因為個人态度問題的話 你可以和他好好聊聊 如果他實要不想做的話 你可以換人了
6、以往的項目開發有什麼經驗以及建議？
7、對學好軟體工程有什麼建議？
盡量讓自己多了解一些現實中的軟體開發過程，或者參與到一些簡單的軟體開發中，了解人們的方法與問題後，再與軟體工程中的理論相比較，你就會有意想不到的收獲！軟體工程的更高層次，會和其它管理學科一親友，回歸到哲學和人性本身上面來。不過這個高度需要時間和實踐的。
軟體工程心得體會未接觸軟體工程之前一直都很想學這門課程，因為覺得這門課很牛，是那些有工程師稱号的高手才擺弄的東西。學了一個學期的軟體工程課，終于知道了個軟體工程的大概。學的時候總覺得很抽象，了解起來好像不難，但總是摸不着頭腦一種很茫然的感覺。曾經以為程式就是軟體，軟體就是程式。學習這門課程第一個收獲是，知道了二者的不同之處。以前做過的一些小型的軟體比如加密軟體，我也隻是在程式旁邊附上一個軟體的說明，看來已經很接近作坊了。不過大的項目沒有接觸過，用軟體工程的方法還是第一次。我想也是程式的不斷複雜化導緻了軟體危機的發生，使得人們不得不探索新的解決方法。
經過馮老師的講解，了解了軟體工程，就是一套用于軟體的團隊開發，以提高軟體品質和程式員工作效率為目的的規範。其核心就是，對于軟體開發的5個重要組成部分：需求分析，設計，編碼，調試，維護，如何組織這5個部分的工作，以及如何完成每一個工作。吾生也有涯，而知也無涯，學習永無止境。起初，對軟體工程處于一知半解的狀态，分工比較混亂。
在劃分子產品後明确了各自分工，漸漸形成良性循環。在學習過程中，知道了團隊合作十分重要，争議固然存在，但通過讨論、協商，群策群力，在不斷磨合中能夠達成一緻與默契。團隊成員中能力各有高下，互相尊重，各取所長，不宜妄自菲薄。組長多加協調，組員積極配合，才能合作愉快。學習能力展現在能盡快接受新的知識，順應變化，學為所用。
上《軟體工程》這門課，我的收獲大概如下：我們為什麼需要軟體工程呢？上面已經給出了一些原因。專業點講，軟體工程最終是為了實作“軟體制造業”的社會化,工業化大生産,提高其勞動生産效率。隻有如此,軟體業才能實作社會化,工業化大生産,才能“做大做強”。沒有管理的設計是失敗和混亂的設計，沒有設計指導的程式設計是無序的忙碌的。根據開發的軟體的規模，應該适當程度的運用軟體工程化的思想，需要靈活，畢竟我們開發的軟體大多數是中小型的，大型的并不多見（我是這麼認為的）。但隻要涉及人員間的交流和溝通，或多或少都要需要軟體工程才能更有效率，工作成果更穩定。
其實開發軟體，就像是解決一個邏輯問題。想想自己平時是怎樣寫程式的。首先是要有一個想法，即我寫的這個程式是要幹什麼的；然後就是對要實作的核心功能大概構思一種或多種實作方法，并從中選出一種自認為是較好的；接下來就是将涉及的各種主要或次要功能分成各個子產品；最後就是分子產品來編碼和DEBUG。在我看來，除了第一步外，其餘的步驟應該是一個循環的過程。在編碼的過程中，你總是需要不斷地回過頭來修改原先的子產品設計，甚至最初標明的實作算法。具體到每一步的工作要怎樣完成，是非常靈活的，隻要把握住大體的方向就行。在進行分析，設計，編碼，調試，維護這幾部分的工作的時候，最核心的就是文檔的編寫。1.可行性分析就是關于目前項目能不能幹的分析結果。
2.項目描述這是在決定立項以後，對目前項目的一份扼要說明。
3.需求分析就是對客戶要求的功能的定義。
4.軟體設計這就是對程式的每一個子產品的詳細設計的說明文檔。
5.開發日志我一直都認為這是文檔中最有趣的部分。開發日志相當于編碼階段的文檔，它的形式可以很随意，主要是記錄一些在寫程式時突然萌發的靈感，或對代碼的一些微小的修改，或對程式結構的一些微小變動等，還要對上述這些修改變動作些說明。
6.測試分析用于指出程式存在或潛在的缺陷和錯誤，以及程式性能的數字描述