今天下午參加了公司的 軟件工程 培訓。由于所在部門(mén)前不久過(guò)了CMMI 3 級，所以有些東西也是結合CMMI 3的原則來(lái)說(shuō)的。由于才從學(xué)校出來(lái)，沒(méi)有太多的經(jīng)驗，一些理論也是似懂非懂。不過(guò)還是記錄了一些目前就覺(jué)得有些用處，可以為以后的一些軟件開(kāi)發(fā)活動(dòng)提供參考的東西。
- 每一個(gè)活動(dòng)都必須有明確的啟動(dòng)準則和離開(kāi)（結束）準則。比如，必須明確的規定只有當《需求說(shuō)明書(shū)》通過(guò)了客戶(hù)的審核并簽了字，才可以說(shuō)目前需求的調研結束了。
- 對過(guò)程的剪裁。CMMI 對整個(gè)軟件開(kāi)發(fā)過(guò)程的每一個(gè)階段都有著(zhù)明確的規定。但是這樣的規定對于規模比較小的項目可能就顯得繁瑣，沒(méi)有必要了，這種情況就需要對模型進(jìn)行必要的裁減，不能拘泥不變。
- 對于重復的活動(dòng)一定要注重經(jīng)驗的積累。體現的最主要的地方是一些審查的地方，比如代碼規范性審核，由于重復的錯誤總是屢屢犯過(guò)，所以可以形成一個(gè)CheckList，里面列舉了所有常見(jiàn)的代碼規范的條款。這樣檢查人員不必再絞盡腦汁的去想要檢查哪些規范，而是可以全面的對代碼的規范性進(jìn)行檢查。其實(shí)這種經(jīng)驗的積累和知識庫的建立用的地方很多，我原來(lái)看到一篇關(guān)于提高ASP.NET應用程序的性能的文章，文章的最后就列舉了所有可能提高系統性能的條目，供開(kāi)發(fā)人員對自己的程序進(jìn)行檢查。效果非常的好。
- 對需求確定優(yōu)先級別。不是所有的需求都是一樣重要的，要對需求的重要性進(jìn)行排序，甚至要理清需求之間的關(guān)系。因為有些需求之間的依賴(lài)性很強，要么就一起完成，要么就都不要做。然后針對優(yōu)先級別高的需求進(jìn)行開(kāi)發(fā)優(yōu)先開(kāi)發(fā)工作。
- 原型的作用是用來(lái)直觀(guān)的表達業(yè)務(wù)流程的。用戶(hù)可能沒(méi)有耐心去看你精心制作的需求說(shuō)明書(shū)。用原型演示與客戶(hù)進(jìn)行交流，已確定開(kāi)發(fā)人員和客戶(hù)之間的理解是否存在偏差。
- 比較小的功能需求粒度。一般是頁(yè)面級別一下，比如一個(gè)頁(yè)面上有一個(gè)按鈕，點(diǎn)擊這個(gè)按鈕可以把頁(yè)面的信息保存到指定的數據庫中。那么這個(gè)保存功能就應該單獨的作為一個(gè)功能需求點(diǎn)。因為這樣的語(yǔ)言更加的準確，為以后的開(kāi)發(fā)，針對需求的集成測試都會(huì )帶來(lái)便利。
- 設計系統時(shí)，系統所有實(shí)現的功能，在需求說(shuō)明書(shū)中都應該有明確的“文字說(shuō)明”來(lái)對應。
- 對于如同《需求跟蹤矩陣》這樣的文檔，可能在不同的階段，項目經(jīng)理，系統設計工程師，系統開(kāi)發(fā)工程師都會(huì )對其進(jìn)行填寫(xiě)，那么這樣就很可能產(chǎn)生不一致性。此時(shí)就需要設立專(zhuān)門(mén)的組織，或者有人兼職進(jìn)行定期的檢查，保證文檔的一致性。
- 對于任何任務(wù)都必須有明確的責任人，而且這些責任的對應關(guān)系應該有專(zhuān)門(mén)的文檔進(jìn)行記錄。這樣可以在出現問(wèn)題的時(shí)候，有明確的依據進(jìn)行處理。
- 系統發(fā)布的時(shí)候，除了源代碼，用戶(hù)手冊等部分外。還需要有一個(gè)《系統說(shuō)明文檔》，其中應該包含的內容是：此軟件的版本信息，此版本較上一版本修正了哪些缺陷， 此版本較上一版本添加了哪些新的功能， 此版本的軟件可能會(huì )有哪些局限（可能的解決方法）， 此版本的Q&A。我們看到很多軟件都在安裝的目錄下有一個(gè)文本文件，里面列舉了此軟件所有版本的歷史。其實(shí)就是《系統說(shuō)明文檔》
