當前位置:工程項目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關(guān)系統(tǒng) > 房地產(chǎn)項目管理軟件
軟件項目管理:質(zhì)量先行
提到軟件產(chǎn)品開發(fā),我們的腦海里總是浮現(xiàn)出這樣的情景:開發(fā)組的每一位成員都在辛苦地工作,加班加點,甚至通宵達旦。雖然項目經(jīng)理一次又一次地修改了進度計劃,而實際的開發(fā)情況卻總是令人擔憂,以至于每次向領(lǐng)導(dǎo)匯報工作的時候,總是覺得以前制定的計劃沒有很好完成,總是覺得人力資源不夠,總是覺得沒有太多的時間。等到代碼終于開發(fā)完成了,測試進度同樣非常令人擔憂,每一個小BUG都要花很長的時間去查找,改了某一個小錯誤卻又引起了很多新的錯誤,結(jié)果產(chǎn)品發(fā)布遙遙無期,而項目組里的每一位成員已經(jīng)筋疲力盡。
怎樣擺脫這樣的困境?為何軟件開發(fā)項目管理這么困難?為何我們做的計劃總是不能按時完成?為何軟件開發(fā)不能像硬件開發(fā)那樣可以控制?
軟件開發(fā)是完全依靠人的大腦思維產(chǎn)生出產(chǎn)品,而每個人的大腦思維是不一樣的,因此在軟件開發(fā)過程中有太多不確定、可變化的因素。那么我們怎樣把握住這些變化因素呢?
軟件項目管理——質(zhì)量先行,如果我們能夠控制軟件生命周期每一個階段的質(zhì)量,就能很好地控制了軟件開發(fā)的整個過程。
軟件產(chǎn)品的質(zhì)量是個很大的概念,因為軟件產(chǎn)品完全是人們大腦思維的產(chǎn)物,是將大腦里無形的思維變成可以解決實際問題的一組界面或者組件。在這樣一個復(fù)雜的過程中,應(yīng)該如何保證質(zhì)量呢?有人想到了ISO9000、CMM,也有人提出反對意見,認為應(yīng)該用敏捷開發(fā)。其實,不管用什么樣的開發(fā)過程,關(guān)鍵是找到這些過程的本質(zhì)。
有人說,ISO和CMM到中國來怎么就變了味了?其實,我們只學(xué)到了怎樣去做,但是不知道為什么要這樣做。大家都知道在產(chǎn)品立項之前要寫市場分析報告,但不了解為什么要寫,市場分析報告的重要性有多高?不是資深開發(fā)人員很難理解其重要性,如果是簡單地去寫一篇形式上的文檔,那么,除了負擔之外就沒有其它用途了。
有些人又想到了測試,覺得是我們測試的力度不夠,所以產(chǎn)品質(zhì)量不過關(guān)。
其實,軟件開發(fā)的質(zhì)量保證從最初就應(yīng)該開始了,如果到了測試階段才重視就已經(jīng)晚了。軟件產(chǎn)品開發(fā)過程,不管采用瀑布式模型還是迭代式模型,都離不開需求、設(shè)計、編碼、測試這幾個階段。在迭代式開發(fā)中,這幾個階段也是周期性出現(xiàn)的。
怎樣把握好每個階段的質(zhì)量,確實不是一件容易的事。對于軟件產(chǎn)品的測試,不管是單元測試還是集成、系統(tǒng)測試,這方面的介紹已經(jīng)很多了,因此筆者重點介紹一下需求、設(shè)計和編碼階段的質(zhì)量保證。
讓我們開始一次質(zhì)量之旅吧,第一站就是需求分析。
在需求分析過程中,如何進行質(zhì)量保證呢?我們平時可能更多地關(guān)注需求本身,卻忽視了一個很重要的因素,那就是市場。因為我們開發(fā)出來的產(chǎn)品是直接面向市場的,如果費了很多的人力物力開發(fā)出來一個沒有市場前景,缺乏競爭力的產(chǎn)品,那么所有的努力都是白費。如何充分考慮市場因素,具體可以從以下幾個方面進行。
首先,判斷需求是否符合愿景目標,所謂愿景目標就是我們開發(fā)出來的產(chǎn)品能夠給我們的用戶帶來什么樣的好處?如果有些需求沒有被包含在愿景目標里,那么這樣的需求其實就背離了我們開發(fā)產(chǎn)品的初衷。其次,判斷產(chǎn)品需求能夠給企業(yè)帶來多大的利潤,如果某個需求只是代表個別用戶的需求,并不能給企業(yè)帶來較大的利潤,但又花費甚高,就可以考慮刪除。最后,與競爭對手相比核心競爭力有哪些?如果核心競爭力不夠,就應(yīng)該考慮重新進行需求分析,因為如果沒有核心競爭力,開發(fā)出來的產(chǎn)品就沒有市場。
在排除了市場因素產(chǎn)生的風(fēng)險之后,我們應(yīng)該保證需求描述的質(zhì)量。人與人的交流總會存在一些誤會,同樣一句話,心情不好與心情好的時候聽起來可能會截然相反,正是因為人們之間存在著理解上的偏差,在描述需求的語言上就應(yīng)該注意盡量避免歧義的產(chǎn)生。如果對UML比較熟悉的話,需求分析可以利用UML工具進行,這樣可以減少一些自然語言引起的歧義,但是并不是所有的用戶都了解UML各種圖形的意思,與用戶溝通起來存在障礙,除了工具之外,我們可以從以下幾個方面來保證需求描述的質(zhì)量。
首先,看句子和段落是否簡短。長句子看起來會非常困難,很難弄懂真正的需求:另外,過長的句子和段落容易讓人忽視一些需求。所以,如果一個句子不能完全描述清楚需求,應(yīng)該將其拆分成多個小句子。
其次,句子是否有語法錯誤,還要注意標點符號,有時,標點符號點錯了就完全成了另外一個意思。再次,是否存在模糊不清的需求,出現(xiàn)“可能,大概,或者”等詞匯表述。
最后,注意是否存在形容詞及比較性詞語,比如:容易的、快速的、方便的、有效的、許多、很少、簡單、復(fù)雜、最新的、界面友好的、減少、擴大,不小于等等,需要將描述性詞語進行量化,并且給出具體值或者范圍。
另外,保證需求質(zhì)量的一個很重要的因素就是需求是否細化,如果需求不細化就很容易造成代碼的返工,出現(xiàn)程序員盡管加班加點卻總是不能如期完成任務(wù)的情景。怎樣才能判斷需求細化的程度呢?需求細化程度確實很難把握,什么樣的需求可以算是比較細了,不用再進行細化了呢?
答案是:是否可以將需求寫出相應(yīng)的測試用例,如果寫不出來,就說明需求還不是很細,還需要進一步進行細化。
把握住了需求分析這一關(guān),下一站我們就可以進行設(shè)計了。
軟件架構(gòu)設(shè)計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置,我們開發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色。
例如:用戶、項目管理人員、程序員、測試員、維護人員等等。不同的角色對架構(gòu)設(shè)計的要求也不相同。對于程序員來說更關(guān)注模塊是否清晰,類的功能是否單一等等,對于測試人員來說,關(guān)注的是系統(tǒng)的可測試性。對于維護人員來講,系統(tǒng)的擴展性、可維護性如何?
一個高質(zhì)量的軟件架構(gòu),應(yīng)該最大限度的考慮并滿足不同角色的不同要求。因此我們在進行軟件設(shè)計的時候,應(yīng)該進行全面的考慮。一般用來衡量軟件設(shè)計質(zhì)量的標準可以從以下幾個方面來考慮:
◆功能性
包括完全性、正確性、安全性、兼容性、互用性。
◆效率
產(chǎn)品運行的時間效率和利用的硬件資源兩方面。
◆維護性
包括架構(gòu)的可改正性,可擴充性以及可測試性。如果用戶的一個很小的需求變更會引起架構(gòu)設(shè)計很大的變化,那么這樣的架構(gòu)設(shè)計的可改正性和可擴充性就比較差。
◆可移植性
包括硬件的獨立性、軟件獨立性、可安裝性、可重用性。軟件設(shè)計是否模塊化、可復(fù)用性都是應(yīng)該考慮的因素。
◆可靠性
包括無缺陷性、容錯性、可用性。
◆使用性
包括可理解性、易學(xué)習(xí)性、可操作性、易溝通性。我們軟件的最終目的是讓用戶來使用的,如果易用性不好,可操作性不好都會影響用戶對軟件的接納程度。因此軟件的可用性也是非常重要的。
完成了設(shè)計之后,接下來就要進行編碼了。在編碼階段,應(yīng)該怎樣保證我們的編碼質(zhì)量呢?兩個比較有效的方法就是代碼走查和單元測試。
代碼走查可以以組為單位進行,代碼走查可以發(fā)現(xiàn)代碼是否符合代碼規(guī)范,是否存在拼寫錯誤,是否具有可讀性,類和方法是否過于冗長,類之間是否存在高耦合性。
代碼質(zhì)量的一個很重要的標準就是代碼的可讀性,可讀性不一定是簡單的代碼,而是容易理解的代碼,因為過于復(fù)雜的代碼難以測試和維護,同時出錯的幾率也會更高。
如果一個方法內(nèi)部的代碼很長,而且使用了很多令人難以理解的數(shù)據(jù)集,就會帶來代碼維護的困難,因為很少有人能夠有效地分析它們,因此也就最容易出現(xiàn)缺陷和錯誤。類之間的耦合度會造成類與類之間的相互關(guān)聯(lián),當一個類發(fā)生改變時會使其他的類發(fā)生意想不到的變化,一般從導(dǎo)入類的個數(shù)判斷類之間的耦合度,如果導(dǎo)入類的個數(shù)很多,或者該類的public方法太多都會導(dǎo)致類之間的高耦合性增加。
編碼階段另一個非常重要的手段就是單元測試。單元測試是一個模塊的功能及常規(guī)錯誤測試,單元測試是由程序員進行的,一般單元測試能夠捕獲80%的bug。因此單元測試對保證代碼質(zhì)量方面占有很重要的地位,由于這方面內(nèi)容比較多,我們這里就不做具體闡述了。
好了,經(jīng)過了這樣一次質(zhì)量旅行,我們對軟件開發(fā)是否增加了很多信心呢?當然軟件項目管理還有很多其他的因素,但是如果每個階段都能夠很好的控制質(zhì)量,就會在產(chǎn)品開發(fā)初期減少很多風(fēng)險,從而使我們的軟件開發(fā)在一個可以控制的范圍內(nèi)進行,這樣我們才能夠避免過多的沒有必要的人力物力的浪費,從而使我們的產(chǎn)品更快更好的投入市場。
- 1安全工程師考試《安全生產(chǎn)管理知識》全真習(xí)題(11)
- 2時評:擁擠與空曠間的平衡術(shù)
- 3平剛:從未建成邁入建成
- 4ERP實施項目建立項目管理制度的重要性
- 5朱锫:在建筑中發(fā)現(xiàn)那些平常卻又重要的道理
- 62015年安全工程師考試《管理知識》模擬題1
- 7王小根:做改變別人想法的設(shè)計
- 8北京某大型220KV變電站創(chuàng)優(yōu)規(guī)劃(創(chuàng)國網(wǎng)優(yōu)質(zhì)工程)
- 9Andrew Laidlaw:為公園設(shè)計加入童趣創(chuàng)意
- 10于金合:體驗始終是實體商業(yè)的王道
- 112015年安全工程師考試《生產(chǎn)管理知識》習(xí)題(11)
- 12吐槽集中營|被"點開全文"轟炸的朋友圈,造價人hold住嗎?
- 13施工圖最容易出錯的地方,不得不看!
- 14楊玉成:養(yǎng)老度假地產(chǎn)房地產(chǎn)市場最后一塊金礦?
- 15安全工程師《法律法規(guī)》第四講習(xí)題精選(10)
- 16秦皇島建筑節(jié)能專項驗收資料(實例)
- 17呂舟:別讓歷史成為古城的道具
- 18全球及中國照明市場的現(xiàn)狀和發(fā)展趨勢
- 192015安全工程師考試《安全生產(chǎn)管理知識》備考測試22
- 20馬輝:面子轉(zhuǎn)為里子,家具設(shè)計越發(fā)務(wù)實
- 21Marshall Strabala:中國最高樓背后的學(xué)問大
- 22項目經(jīng)理“拍馬屁”的功底
- 23張金峰:石家莊商業(yè)地產(chǎn)局部區(qū)域過量 發(fā)展不平衡
- 24朱建松:卓爾不群,建瓴高屋
- 252015年安全工程師考試《安全生產(chǎn)管理知識》(23)
- 26北京市某銀行業(yè)務(wù)營運中心創(chuàng)優(yōu)策劃(創(chuàng)魯班獎)
- 27廣東省建筑工人平安卡申請登記表
- 28時評:把“空城”“鬼城”歸結(jié)為大城市化不妥
- 29分析:瞄準高端消費市場 智能衛(wèi)浴才是未來主流
- 30時評:單元樓讓人變成“擁擠難民”?
成都公司:成都市成華區(qū)建設(shè)南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓