除設計選型,還有一個容易被忽視的問題,就是公共類開發。公共類開發可以減少工作中的重復工作,降低開發成本。這要求我們再設計階段通過對用戶需求的仔細研究,盡可能的識別出公共類,并進行定義指定專人負責設計通知其它設計人員,以減少重復工作。對于項目組提供的設計文檔,由質保小組組織技術專家、項目組設計人員、開發人員和測試人員對其設計文檔的評審,檢測設計文檔對其下一階段工作的可行性,及時發現設計中可能存在的錯誤,降低項目開發風險,同時確保設計文檔能為開發人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發,提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。
c、實現
實現也就是代碼的生產過程。這里不僅包括代碼的產生,同時也包括測試用例的產生。針對上一階段提供詳細設計,程序員開始編碼并且調試程序,測試人員則根據設計進行測試用例的設計,設計出來的用例需要得到項目組成員認可由項目經理審核通過才能進入配置庫。同時程序員調試完程序提交測試人員進行程序正確性檢測。
d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。
內部文檔包括: 項目開發計劃; 需求分析; 體系結構設計說明; 詳細設計說明; 構件索引; 構件成分說明; 構件接口及調用說明; 組件索引; 組件接口及調用說明; 類索引; 類屬性及方法說明; 測試報告; 測試統計報告; 質量監督報告; 源代碼; 文檔分類版本索引; 軟件安裝打包文件。
外部文檔主要包括: 軟件安裝手冊; 軟件操作手冊; 在線幫助; 系統性能指標報告; 系統操作索引。
如何保證文檔的全面性,使其真正為項目的進度提供保證,又不因為文檔的寫作而耽誤項目的進度,這仍然是一個比較難解決的問題。解決此問題,其核心仍然是個"度"的問題。在本項目的開發中,配置管理小組的一個非常重要的任務還是書寫文檔規范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作,從某種意義上講,書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成,則該文檔即交由他人完成,但此時文檔并不算被正式提交,當他人書寫完畢之后,必須由文檔的初寫者進行復審,復審通過后方可以正式提交,進入軟件配置管理的循環中。
配置管理小組真正核心的工作是對文檔的組織管理。根據文檔的不同,文檔的來源也不同,有些是通過質量保證小組經過復審之后轉交給配置管理小組,有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個非常煩瑣的工作,但是長遠來看它不僅使項目的開發對單個主要人員的依賴減少,從而減少人員流動給項目的帶來的風險,更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。
從以往做大項目的經驗來看,寫作文檔在項目開發的早期可能會使項目的進度比起不寫文檔要稍慢,但隨著項目的進展,各個部門需要配合越來越多,開發者越來越需要知道其他人員的開發思路和開發過程,才能使自己的開發向前推進。一個明顯的例子就是系統整合,或者某些環節是建立在其他環節完成的基礎之上時,就更顯現出文檔交流的準確性和高效性。
3、系統維護質量保證
在我們公司,維護小組的任務一方面是保證對項目客戶的跟蹤服務,另一方面是確保該項目其它的開發人員從項目中盡快的解脫出來以便投入到下一個項目的開發中。所以通常項目維護小組成員主要由項目組的少部分開發人員承擔完成。他們不僅了解軟件的核心內容,而且與客戶也不陌生,以便能夠以最快的速度修正錯誤。對于一般性的錯誤,如操作不當等引起的問題,全部由維護小組執行完成,但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程,用戶或者維護人員填寫變更申請,經專家會議討論分析可行方案在由維護小組實施,通過測試后方可提交用戶。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時,在維護小組有較多的人員進行跟進,隨軟件的穩定,跟進的人逐步減少,并轉移到其它項目中去。
文章來源于領測軟件測試網 http://www.kjueaiud.com/