房地產(chǎn)項目管理軟件
當前位置：工程項目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關(guān)系統(tǒng) > 房地產(chǎn)項目管理軟件
《領(lǐng)導軟件開發(fā)團隊》-軟件項目流程管理(轉(zhuǎn)載)
需求獲取與分析
a)不要在需求獲取和分析過程中吝嗇你的時間，對需求的明確可以減少你以后設(shè)計和開發(fā)的改動，提高你所開發(fā)軟件的可用性。你對它的輕視只可能換來對你的產(chǎn)品修改、計劃延遲等方面的懲罰。
b)要使盡各種辦法，盡量多的獲取客戶的需求，主要的方法包括：仔細閱讀合同標書和市場資料、與客戶直接的談話交流、讓用戶觀看或使用原型界面提出意見。另外不要忽略內(nèi)部客戶的一些合理需求如測試人員等。
c)進行正規(guī)的需求管理，如建立需求文檔或使用需求管理數(shù)據(jù)庫等。在文檔或數(shù)據(jù)庫中要保留每個需求的詳細描述及其來源，最好還能記錄一些其他細節(jié)信息（如用戶的一些原始描述等），另外別忘了確定每個需求的優(yōu)先級。
d)在設(shè)計前組織你的設(shè)計人員開會進行需求理解和討論。由于閱讀文字性的信息容易造成一些誤解和歧義，最好讓需求制定者組織會議，給相關(guān)人員（如各子系統(tǒng)設(shè)計人員）講解需求并進行設(shè)計討論。這樣做有兩個好處，一是避免設(shè)計與需求出現(xiàn)偏差，二是激發(fā)設(shè)計人員產(chǎn)生初步的設(shè)計想法。
確定結(jié)構(gòu)及系統(tǒng)設(shè)計
a)頂層設(shè)計必須要有多人及專家參與。一個好的設(shè)計方案不可能完全出自一個人的腦袋，它往往是經(jīng)歷多次討論甚至爭論、多次改進與融合而最終形成的一個有創(chuàng)造性的妥協(xié)產(chǎn)物。但你要避免爭論的過分激烈而導致的負面效果。
b)一個好的設(shè)計應(yīng)包含簡單的框架，細節(jié)隱藏其下。組塊和模塊是一個好的設(shè)計所具有的特征，在頂層設(shè)計里人們看到的是簡捷的框架和功能明確的組快，在每個組快內(nèi)部又能發(fā)現(xiàn)一個簡單的框架和其他一些自包含的的組塊或模塊。
c)在系統(tǒng)設(shè)計時想想你的用戶將怎樣使用你的軟件工作。很多時候設(shè)計人員會習慣性地從技術(shù)角度考慮系統(tǒng)地布局和劃分，可這種技術(shù)上地合理有時可能跟使用上的合理是沖突的，所以此時考慮一下你的用戶將降低你今后修改的風險。
有關(guān)詳細設(shè)計
a)詳細設(shè)計沒有必要過于精細準確。目前對有關(guān)底層詳細設(shè)計是否需要以及它該詳細到何種程度還存在一定的爭論，但認為可以不要和必須寫得非常精確這兩種極端思想都是有害的。詳細設(shè)計的作用在于開發(fā)人員編碼前整理思路，同時讓別人通過審核詳細設(shè)計文檔檢驗?zāi)愕乃悸肥欠裾_，防止出現(xiàn)錯誤。
測試問題
a)繁雜但極富成效的單元測試。如果想將你的軟件質(zhì)量提高到一個新的檔次，對開發(fā)的軟件模塊進行完整的單元測試是一個很好的途徑，它能使開發(fā)者對自己的代碼成果更加有信心。雖然一些軟件項目單元測試做的很少甚至沒有，并且產(chǎn)品在最終測試后也運行的不錯，但它只能保證在與最終測試環(huán)境類似的環(huán)境中運行是安全的，超出這樣一種環(huán)境范圍則可能充滿雷區(qū)。
b)必不可少的最終測試。如果你的項目受時間、人力等資源影響沒法進行過多的單元測試，那最終測試就成了你軟件產(chǎn)品的唯一質(zhì)量保證，千萬別把這一保證也丟了，沒有它你的軟件產(chǎn)品就毫無質(zhì)量可言。最終測試的另一大用處是通過它可以發(fā)現(xiàn)一些單元測試的漏洞，完善單元測試用例。
c)根據(jù)你的軟件特性選擇自動測試。自動測試如果能在你的項目中使用上，將是個不錯的消息，雖然目前的自動測試工具對一些特殊情況和特殊數(shù)據(jù)的細節(jié)處理略顯笨拙，但用它來檢驗產(chǎn)品的基本可用性和代碼修改的影響卻是高效的。有時自動測試還可能幫你發(fā)現(xiàn)手工測試幾乎不可能出現(xiàn)的錯誤情況，例如極短時間內(nèi)觸發(fā)多個操作造成的沖突等。
有關(guān)重構(gòu)
a)頂層結(jié)構(gòu)的重新設(shè)計。通常當你的項目出現(xiàn)這種情況是非常不幸的，出現(xiàn)的原因一般是由于原來的結(jié)構(gòu)不能支持新補充的特性而不得不進行修改。這種重新設(shè)計要注意兩點，一是時機最好選擇在一個大的工作階段開始時，二是在新結(jié)構(gòu)中盡量移動原有代碼而不是編寫新代碼。
b)底層模塊的改進。由于當初編寫時的倉猝或考慮不周使得現(xiàn)有模塊存在這樣或那樣的問題并且難于理解，這種情況下進行重構(gòu)改進是很有必要的。修改的方法通常為對已有代碼進行整理和注釋，增加模塊的封閉性和穩(wěn)健性。
新技術(shù)的運用
a)評估新技術(shù)，確定它是否可以給項目帶來好處。合適的新技術(shù)可以提高產(chǎn)品開發(fā)效率和質(zhì)量，判斷某一新技術(shù)對你的項目是否合適通常需要派專人或一個小組進行小范圍考察和驗證。采用新技術(shù)的時機最好選擇在項目開始時或項目的某些重要階段開始時，另外千萬別忘了培訓你的開發(fā)人員使用它。
b)避免幾種使用新技術(shù)的動機。一是為了學習新技術(shù)而在項目中使用新技術(shù)，這樣只能使你的項目變成一個實驗田，項目產(chǎn)品最終也成了實驗產(chǎn)品。二是不要指望使用新技術(shù)能拯救陷入困境的項目，如果一個項目陷入困境，它通常需要的是清晰和穩(wěn)定，未知的新技術(shù)很可能導致更大的混亂。
a)不要在需求獲取和分析過程中吝嗇你的時間，對需求的明確可以減少你以后設(shè)計和開發(fā)的改動，提高你所開發(fā)軟件的可用性。你對它的輕視只可能換來對你的產(chǎn)品修改、計劃延遲等方面的懲罰。
b)要使盡各種辦法，盡量多的獲取客戶的需求，主要的方法包括：仔細閱讀合同標書和市場資料、與客戶直接的談話交流、讓用戶觀看或使用原型界面提出意見。另外不要忽略內(nèi)部客戶的一些合理需求如測試人員等。
c)進行正規(guī)的需求管理，如建立需求文檔或使用需求管理數(shù)據(jù)庫等。在文檔或數(shù)據(jù)庫中要保留每個需求的詳細描述及其來源，最好還能記錄一些其他細節(jié)信息（如用戶的一些原始描述等），另外別忘了確定每個需求的優(yōu)先級。
d)在設(shè)計前組織你的設(shè)計人員開會進行需求理解和討論。由于閱讀文字性的信息容易造成一些誤解和歧義，最好讓需求制定者組織會議，給相關(guān)人員（如各子系統(tǒng)設(shè)計人員）講解需求并進行設(shè)計討論。這樣做有兩個好處，一是避免設(shè)計與需求出現(xiàn)偏差，二是激發(fā)設(shè)計人員產(chǎn)生初步的設(shè)計想法。
確定結(jié)構(gòu)及系統(tǒng)設(shè)計
a)頂層設(shè)計必須要有多人及專家參與。一個好的設(shè)計方案不可能完全出自一個人的腦袋，它往往是經(jīng)歷多次討論甚至爭論、多次改進與融合而最終形成的一個有創(chuàng)造性的妥協(xié)產(chǎn)物。但你要避免爭論的過分激烈而導致的負面效果。
b)一個好的設(shè)計應(yīng)包含簡單的框架，細節(jié)隱藏其下。組塊和模塊是一個好的設(shè)計所具有的特征，在頂層設(shè)計里人們看到的是簡捷的框架和功能明確的組快，在每個組快內(nèi)部又能發(fā)現(xiàn)一個簡單的框架和其他一些自包含的的組塊或模塊。
c)在系統(tǒng)設(shè)計時想想你的用戶將怎樣使用你的軟件工作。很多時候設(shè)計人員會習慣性地從技術(shù)角度考慮系統(tǒng)地布局和劃分，可這種技術(shù)上地合理有時可能跟使用上的合理是沖突的，所以此時考慮一下你的用戶將降低你今后修改的風險。
有關(guān)詳細設(shè)計
a)詳細設(shè)計沒有必要過于精細準確。目前對有關(guān)底層詳細設(shè)計是否需要以及它該詳細到何種程度還存在一定的爭論，但認為可以不要和必須寫得非常精確這兩種極端思想都是有害的。詳細設(shè)計的作用在于開發(fā)人員編碼前整理思路，同時讓別人通過審核詳細設(shè)計文檔檢驗?zāi)愕乃悸肥欠裾_，防止出現(xiàn)錯誤。
測試問題
a)繁雜但極富成效的單元測試。如果想將你的軟件質(zhì)量提高到一個新的檔次，對開發(fā)的軟件模塊進行完整的單元測試是一個很好的途徑，它能使開發(fā)者對自己的代碼成果更加有信心。雖然一些軟件項目單元測試做的很少甚至沒有，并且產(chǎn)品在最終測試后也運行的不錯，但它只能保證在與最終測試環(huán)境類似的環(huán)境中運行是安全的，超出這樣一種環(huán)境范圍則可能充滿雷區(qū)。
b)必不可少的最終測試。如果你的項目受時間、人力等資源影響沒法進行過多的單元測試，那最終測試就成了你軟件產(chǎn)品的唯一質(zhì)量保證，千萬別把這一保證也丟了，沒有它你的軟件產(chǎn)品就毫無質(zhì)量可言。最終測試的另一大用處是通過它可以發(fā)現(xiàn)一些單元測試的漏洞，完善單元測試用例。
c)根據(jù)你的軟件特性選擇自動測試。自動測試如果能在你的項目中使用上，將是個不錯的消息，雖然目前的自動測試工具對一些特殊情況和特殊數(shù)據(jù)的細節(jié)處理略顯笨拙，但用它來檢驗產(chǎn)品的基本可用性和代碼修改的影響卻是高效的。有時自動測試還可能幫你發(fā)現(xiàn)手工測試幾乎不可能出現(xiàn)的錯誤情況，例如極短時間內(nèi)觸發(fā)多個操作造成的沖突等。
有關(guān)重構(gòu)
a)頂層結(jié)構(gòu)的重新設(shè)計。通常當你的項目出現(xiàn)這種情況是非常不幸的，出現(xiàn)的原因一般是由于原來的結(jié)構(gòu)不能支持新補充的特性而不得不進行修改。這種重新設(shè)計要注意兩點，一是時機最好選擇在一個大的工作階段開始時，二是在新結(jié)構(gòu)中盡量移動原有代碼而不是編寫新代碼。
b)底層模塊的改進。由于當初編寫時的倉猝或考慮不周使得現(xiàn)有模塊存在這樣或那樣的問題并且難于理解，這種情況下進行重構(gòu)改進是很有必要的。修改的方法通常為對已有代碼進行整理和注釋，增加模塊的封閉性和穩(wěn)健性。
新技術(shù)的運用
a)評估新技術(shù)，確定它是否可以給項目帶來好處。合適的新技術(shù)可以提高產(chǎn)品開發(fā)效率和質(zhì)量，判斷某一新技術(shù)對你的項目是否合適通常需要派專人或一個小組進行小范圍考察和驗證。采用新技術(shù)的時機最好選擇在項目開始時或項目的某些重要階段開始時，另外千萬別忘了培訓你的開發(fā)人員使用它。
b)避免幾種使用新技術(shù)的動機。一是為了學習新技術(shù)而在項目中使用新技術(shù)，這樣只能使你的項目變成一個實驗田，項目產(chǎn)品最終也成了實驗產(chǎn)品。二是不要指望使用新技術(shù)能拯救陷入困境的項目，如果一個項目陷入困境，它通常需要的是清晰和穩(wěn)定，未知的新技術(shù)很可能導致更大的混亂。