建構之法閱讀筆記06

 這段時間閱讀了《建構之法》的剩餘章節。

第14章承接前文軟體測試，講了軟體品質保障需要做的工作。作者先介紹了軟體品質的衡量可利用CMMI,又講了保障品質所需付出的成本（預防、評審、内部故障、外部故障），軟體測試與品質保障是不同的。軟體品質保障包含測試。

第15章——穩定和釋出階段，作者把代碼釋出時可能遇到的問題列出，也講訴了按時釋出的招數DCR、ZBB，最後項目的總結與回顧。可見，軟體工程不光是完成代碼即可，作為一個項目，它的生命周期還沒有結束。

第16章——IT行業的創新，創新是時下熱門的詞語，天天都能聽到看到，抓住創新的時機很重要，而創新受到很多因素的制約。

第17章——人、效績和職業道德。軟體團隊中存在3種人，豬、雞和鹦鹉。豬全身心投入工作，而雞隻投入了一部分精力，鹦鹉則是動動嘴皮。其實在生活工作中大部分人都想做鹦鹉，但隻想不勞而獲是不對的，在學校時可以靠朋友，但未來工作時沒有實力，工作可能就沒有了。希望我們團隊可以憑自己努力做好程式。軟體團隊的合作階段有萌芽、磨合、規範、創造等。個個行業都有其職業道德，軟體工程師也不例外。

讀完《建構之法》對軟體工程方面有了更深的了解，鄒欣老師這本書，寫的不像一般課本那樣死闆，舉了和多課外的執行個體與軟體工程的知識相結合。書的内容從介紹“軟體=程式+軟體工程”開始，先是個人程式設計再到兩人合作及團隊合作。也講了軟體工程的方方面面，如需求分析、設計實作、測試等。軟體發展産生的過程離不開人，程式員及使用者是這過程中重要的參與者。

最後，在閱讀計劃中我曾提出如下問題：http://www.cnblogs.com/a1397240667/p/5247236.html

1.怎樣确定一個軟體“足夠好”，并且可以釋出了？

很顯然，軟體釋出受到方方面面制約，不是程式員覺得技術上很完美就可以稱得上“足夠好”，實際要考慮工期、預算以及客戶的需求。在滿足客戶最重要的需求的同時，還要趕得上多變的市場。有舍必有得，我們隻可以完成相對不錯的軟體。

2.個人軟體開發流程PSP是依靠工程師自己收集資料分析，那麼這個過程中確定資料的真實性？

就我自身而言，很難一直堅持下去。是以實施過程中自覺性很重要。

3.團隊合作有多種模式，如何确定自己的團隊所适合的模式?

需要團隊的管理者對隊員的特點有清晰的認識，在合作過程中摸索。

4.現代軟體工程方法論大緻可以分為重方法論和靈活方法論兩大陣營,如何選擇适合的軟體工程方法論？

重方法論更加強調前期設計，為未來設計；而靈活方法論則更加強調隻為現在設計，未來再重構它，而就是這個最為本質的差別才是根據項目實際特點進行正确選擇的基礎。需求分析員應該基于對業務領域的了解，正确地評判項目的特點，為開發團隊選擇适合的軟體工程方法論提出建議。而鄒欣老師的部落格也給了确定方法的建議http://www.cnblogs.com/xinz/p/3852390.html

5.MSF适合大學裡面的團隊嗎？

随着課程的學習，我認為MSF這一模型不錯，但在團隊中實作不容易。當下的學生對學習的态度多是“應付”為主，而到了程式設計時，多半還是一人程式設計，其他人看着。