某財稅軟件開發(fā)項目質(zhì)量管理的魚骨圖分析案例目錄TOC\o"1-3"\h\u6835某財稅軟件開發(fā)項目質(zhì)量管理的魚骨圖分析案例 1245441.1.1A公司某財稅軟件需求階段問題分析 1263001.1.2A公司某財稅軟件開發(fā)階段問題分析 3236011.1.3A公司某財稅軟件測試階段問題分析 4通過4.1章節(jié)的QFD分析已經(jīng)能夠看到一些主要影響系統(tǒng)質(zhì)量的影響因素，這些因素分布在某財稅軟件開發(fā)項目的各個階段。在需求分析與設(shè)計階段，需求文檔、設(shè)計圖的評審及管理的缺失都會引起質(zhì)量問題；開發(fā)階段的架構(gòu)設(shè)計為整體系統(tǒng)“打地基”，一旦出了問題，整體系統(tǒng)的質(zhì)量后續(xù)或多或少會受到影響；測試及驗收階段，如果測試用例的評審及管理不夠完善，后續(xù)測試可能會出現(xiàn)漏洞，影響整體的質(zhì)量?；谝陨先齻€階段，通過產(chǎn)品部門、開發(fā)部門、系統(tǒng)實施部門、市場部門的各個同事運用頭腦風(fēng)暴及因果圖法進行更進一步的質(zhì)量問題分析，以此來得到影響A公司某財稅軟件開發(fā)項目三個階段質(zhì)量管理的魚骨圖。A公司某財稅軟件需求階段問題分析通過召集各部門相關(guān)成員至同一會議室中，列出需求分析與設(shè)計階段質(zhì)量管理所存在的問題，針對這些問題產(chǎn)生的原因進行思維發(fā)散，即頭腦風(fēng)暴，得到A公司某財稅軟件開發(fā)項目在需求分析與設(shè)計階段的質(zhì)量管理問題魚骨圖分析，如圖4.2所示。圖4.2需求階段魚骨圖根據(jù)魚骨圖，可以得出以下幾個結(jié)論：（1）需求分析不足、邏輯不嚴(yán)謹(jǐn)、變更頻繁A公司的需求收集與分析基本是由產(chǎn)品經(jīng)理獨立完成，由于產(chǎn)品經(jīng)理本身的專業(yè)技能差異，在和客戶及其他相關(guān)干系人進行需求的溝通收集之后，進行需求分析的過程出現(xiàn)了需求分析不足的情況，導(dǎo)致需求文檔不夠全面；同時由于對需求本身的理解度不足，或本身專業(yè)素質(zhì)的問題，會在需求分析過程中產(chǎn)生邏輯漏洞，對開發(fā)階段造成一定的影響；同時A公司某財稅軟件項目與公司內(nèi)部其他項目是有一定的關(guān)聯(lián)度的，由于產(chǎn)品經(jīng)理對于關(guān)聯(lián)項目的了解缺失，導(dǎo)致在進行需求分析時，忽略掉了與其他項目的關(guān)聯(lián)設(shè)計，造成需求變更。另外，對于客戶或上級領(lǐng)導(dǎo)為了讓項目交付時價值更高而直接提出的功能修改或增加，也會造成頻繁的需求變更。軟件實現(xiàn)是一個細(xì)致的工作。產(chǎn)品經(jīng)理在編寫需求文檔的時候?qū)τ行┬枨笾皇沁M行了簡單的功能定義，沒有進行細(xì)化的邏輯思考，導(dǎo)致最終實現(xiàn)的需求與原有產(chǎn)品預(yù)期存在偏差或邏輯、功能相背離，不得不重新設(shè)計，影響最終項目的質(zhì)量。（2）設(shè)計圖不規(guī)范、與原型不符需求分析完成之后，產(chǎn)品經(jīng)理將原型交付給設(shè)計師進行設(shè)計的過程中，由于項目涉及到的頁面較多，是經(jīng)由多位設(shè)計師一起來完成整體設(shè)計圖的交付工作的，這期間由于UI的規(guī)范沒有完全制定，整體的色值及色域規(guī)劃沒有標(biāo)準(zhǔn)，造成UI不統(tǒng)一的情況；同時，由于設(shè)計師本身是有自己的思維邏輯的，產(chǎn)品經(jīng)理將原型同步給設(shè)計人員之后，溝通不到位，導(dǎo)致某位設(shè)計師對于整個產(chǎn)品理解不到位，對某些功能點或頁面出具設(shè)計圖時與產(chǎn)品經(jīng)理的原型圖產(chǎn)生偏差；由于后期開發(fā)人員也是多名同時進行，在開發(fā)過程中按照設(shè)計圖的樣式進行開發(fā)，最終的項目結(jié)果產(chǎn)生了返工或質(zhì)量問題。（3）人員能力欠缺參與本項目的產(chǎn)品經(jīng)理基本都是非技術(shù)出身，也沒有技術(shù)背景。這就導(dǎo)致產(chǎn)品經(jīng)理只關(guān)注產(chǎn)品的實現(xiàn)邏輯，只要邏輯順暢即可，忽視產(chǎn)品的技術(shù)實現(xiàn)，從而導(dǎo)致需求難以實現(xiàn)而引起需求變更，或者實現(xiàn)復(fù)雜，影響整個軟件項目的性能；同時由于財稅軟件相比于一般軟件，對于業(yè)務(wù)熟知度的要求要高很多，比如表間的勾稽關(guān)系、稅務(wù)的減免要求等，產(chǎn)品經(jīng)理對于業(yè)務(wù)的了解程度較低，會導(dǎo)致有時需求傳達給技術(shù)時出現(xiàn)偏差，無法進行技術(shù)實現(xiàn)或者實現(xiàn)后會導(dǎo)致服務(wù)體驗降低等問題。（4）評審機制不完善由于本項目的產(chǎn)品經(jīng)理能力參差不齊，因此在交付開發(fā)前為了保障需求輸出的質(zhì)量會進行評審工作，但由于評審機制的不完善，導(dǎo)致評審工作并沒有嚴(yán)格的標(biāo)準(zhǔn)，且在輸入所有需求文檔及設(shè)計圖給到開發(fā)人員之前，只有一次簡單評審流程，參與人員也比較隨機，導(dǎo)致需求階段的質(zhì)量產(chǎn)生質(zhì)量問題；同時針對產(chǎn)品人員的能力問題，對技術(shù)的基礎(chǔ)了解缺失的問題，沒有統(tǒng)一的機制來鼓勵及監(jiān)督大家提升。A公司某財稅軟件開發(fā)階段問題分析通過召集各部門相關(guān)成員，列出開發(fā)階段質(zhì)量管理所存在的問題，針對這些問題產(chǎn)生的原因進行頭腦風(fēng)暴，得到A公司某財稅軟件開發(fā)項目在開發(fā)階段的質(zhì)量管理問題魚骨圖分析，如圖4.3所示。圖4.3開發(fā)階段魚骨圖（1）編碼規(guī)范不統(tǒng)一、思考較簡單、設(shè)計易出缺陷在項目開發(fā)階段首先要進行項目整體架構(gòu)的設(shè)計，在此階段就要對代碼進行整體的規(guī)范化，否則容易造成架構(gòu)上的缺陷，導(dǎo)致后期開發(fā)的工作變得極其復(fù)雜，且針對某一點出現(xiàn)bug的次數(shù)較多；同時在安全方面也容易出現(xiàn)漏洞，對整體項目的質(zhì)量產(chǎn)生影響。A公司內(nèi)部沒有統(tǒng)一的軟件編碼規(guī)范，負(fù)責(zé)A公司某財稅軟件項目的開發(fā)工程師也是有不同的學(xué)習(xí)經(jīng)歷及工作經(jīng)歷的，這些不同導(dǎo)致了每個人都有自己獨特的編碼規(guī)范，在沒有統(tǒng)一標(biāo)準(zhǔn)規(guī)范的情況下，每個人按照自己的習(xí)慣進行編碼實現(xiàn)；同時為了更快地完成需求的實現(xiàn)，軟件開發(fā)工程師只是簡單的完成項目需求，不會再進行深一步的探索，尋求更優(yōu)的實現(xiàn)方式。不同的軟件開發(fā)工程師負(fù)責(zé)的模塊中保留著濃重的個人風(fēng)格，這些都導(dǎo)致一個人離職或者不在，其他人解決起來比較困難，增加了代碼維護的難度和復(fù)雜度。（2）人員能力不足、對業(yè)務(wù)不夠熟悉只是實現(xiàn)產(chǎn)品的需求是很簡單的，但是想要進行可擴展、易維護、高性能的產(chǎn)品需求編碼實現(xiàn)，則往往需要較高的技術(shù)功底，由于A公司參與本項目的開發(fā)工程師的技能參差不齊，有些工程師的能力還有待提高，導(dǎo)致整體項目在某個模塊的缺陷率較高。同時開發(fā)人員在進行開發(fā)的過程中，需要對業(yè)務(wù)有一定的熟知度才可以更好地了解項目內(nèi)部的邏輯，尤其對于財稅類軟件來說，會計的記賬報稅流程是比較繁瑣且專業(yè)度較高的，每個模塊之間的關(guān)聯(lián)關(guān)系會比較大，比如報稅模塊的數(shù)據(jù)是基于記賬模塊的基礎(chǔ)進行取值的，同時會根據(jù)行業(yè)政策針對不同類型的客戶存在不同的取數(shù)規(guī)則；比如存貨模塊的暫估沖銷與票據(jù)模塊的關(guān)聯(lián)性極大，根據(jù)票據(jù)的上傳先后順序存在不同的邏輯等。對業(yè)務(wù)不夠了解，就很容易在代碼編寫的過程中出現(xiàn)漏洞，導(dǎo)致出現(xiàn)缺陷。（3）代碼審核機制、自測機制欠缺，缺乏培訓(xùn)機制在人員技能分支中已經(jīng)提到，參與本項目的開發(fā)工程師的技能參差不齊，也存在著個別能力較弱的工程師。在這種情況下，由于項目的人員配置中缺少專門的代碼評審人員，代碼的可靠性和質(zhì)量不能得到完全的保證，也在一定程度上導(dǎo)致軟件代碼缺陷一直居高不下；而軟件工程師當(dāng)前只能在項目中來成長，成長空間因人而異，缺少內(nèi)部培訓(xùn)機制；同時軟件開發(fā)工程師對于自測的重視程度偏低，單元測試覆蓋率低，項目的最終質(zhì)量完全依靠測試及驗收環(huán)節(jié)，而此環(huán)節(jié)是由不專業(yè)的測試人員，即實施人員及產(chǎn)品人員進行控制的。作為一個合格的軟件開發(fā)工程師，應(yīng)做到對自我實現(xiàn)的軟件代碼的質(zhì)量進行負(fù)責(zé)，保證所實現(xiàn)功能模塊的正確性，通過自測發(fā)現(xiàn)缺陷并盡早修復(fù)，避免造成不必要的人力資源和時間的浪費。A公司某財稅軟件測試階段問題分析通過召集各部門相關(guān)成員，列出測試與驗收階段質(zhì)量管理所存在的問題，針對這些問題產(chǎn)生的原因進行頭腦風(fēng)暴，得到A公司某財稅軟件開發(fā)項目在測試與驗收階段的質(zhì)量管理問題魚骨圖分析，如圖4.4所示。圖4.4測試階段魚骨圖（1）測試用例不全面、文檔更新不及時測試與驗收階段的測試用例是測試文檔中很重要的一項內(nèi)容，是進行項目整體驗收的依據(jù)。由于測試用例在撰寫過程中會出現(xiàn)用例的細(xì)節(jié)描述不夠、用例不全面等問題，會導(dǎo)致后續(xù)根據(jù)測試用例進行測試時導(dǎo)致測試不全面的情況；且目前A公司并沒有統(tǒng)一的文檔管理制度，當(dāng)出現(xiàn)需求變更需要返工時，經(jīng)常采用口頭通知的方式，產(chǎn)品經(jīng)理直接告之開發(fā)人員及測試人員進行需求改動，并沒有修改需求文檔，而測試人員對于測試用例也沒有及時更新，這樣就提高了后期測試的測試難度，嚴(yán)重影響后期項目的維護。（2）測試人員不夠?qū)I(yè)、測試工具實操困難由于公司內(nèi)部沒有專門的測試團隊，因此普遍存在產(chǎn)品經(jīng)理和實施部門的人員兼職軟件測試情況，大部分人員只懂得黑盒測試，只能夠?qū)浖M行簡單的功能測試。目前公司針對開發(fā)人員雖然有要求自測，但由于重視程度不夠，沒有統(tǒng)一的規(guī)范，也沒有相應(yīng)的制度，導(dǎo)致自測有時會變成敷衍了事。同時沒有專門的測試人員，不會使用一些專業(yè)的測試工具，有些專業(yè)的測試并不能很好地展開，比如性能測試、安全性測試等。這些問題都阻礙了A公司某財稅軟件質(zhì)量管理的提升。（3）溝通不充分、缺乏評審機制測試人員和開發(fā)人員之間的有效溝通可以提高軟件缺陷的修復(fù)效率，減少測試時間，反之則會增加對缺陷定位分析的難度，進而增加缺陷的修復(fù)難度和測試時間，影響項目的質(zhì)量。同理，測試人員同產(chǎn)品經(jīng)理的溝通也是前期必不可少的一環(huán)，溝通越充分，對于需求理解越透徹，在進行測試時更容易把控住測試節(jié)奏。同時由于A公司本身對于測試專業(yè)團隊的缺失，更需要在測試用例出現(xiàn)后加強評審工作，確保測試用例的準(zhǔn)確性及全面性。綜上所述，A公司的某財稅軟件項目質(zhì)量管理問題分析總結(jié)如下:（1）不充分的項目需求分析、產(chǎn)品與設(shè)計的溝通不足導(dǎo)致設(shè)計圖的缺陷都會直接引起需求缺陷，還可能會直接導(dǎo)致項目需求的不斷更新，致使對軟件設(shè)計的不斷修改，增加了軟件項目代碼的開發(fā)實現(xiàn)的復(fù)雜度、維護的復(fù)雜性和難度，降低了軟件代碼實現(xiàn)的效率及其質(zhì)量；評審制度的不完善也在一定程度上給開發(fā)階段造成了不必要的麻煩；需求變更難以控制，不僅僅是產(chǎn)品經(jīng)理單方面的問題，還會涉及到關(guān)鍵需求方以及上級領(lǐng)導(dǎo)；產(chǎn)品經(jīng)理對于技術(shù)的了解程度不足，且缺少系統(tǒng)性的培訓(xùn)。（2）由于缺乏代碼編碼規(guī)范，導(dǎo)致軟件開發(fā)過車用中各個模塊代碼實現(xiàn)風(fēng)格迥異，從而影響了軟件開發(fā)的工作效率及其可維護性；由于項目代碼提交時存在代碼審核管理制度的缺失，導(dǎo)致不能對軟件工程師提交的項目代碼進行很好的編碼質(zhì)量控制，也讓員工喪失了一次很好的進行自我提升的機會；軟件開發(fā)過程中缺乏自測的嚴(yán)謹(jǐn)流程，對于自測本身重視度不高，導(dǎo)致大量的軟件缺陷在測試與驗收階段才被發(fā)現(xiàn)，修復(fù)復(fù)雜的同時將必然引起一定程度的直接改變原有的軟件項目架構(gòu)設(shè)計，使得軟件交付延期，使得軟件的可靠性大大降低、軟件性能降低、響應(yīng)延遲不斷增大，致使軟件的客戶體驗感不斷降低，進而導(dǎo)致客戶滿意度降低。由于項目團隊中某些開發(fā)人員自身能力的問題，也導(dǎo)致缺陷率較高，缺失專業(yè)性的培訓(xùn)制度。（3）軟件項目測試過程測試用例的不完善或缺失會導(dǎo)致一些問題難以發(fā)現(xiàn)，造成發(fā)布上線后的質(zhì)量問題。軟件測試本身就是鑒定軟件的正確性、完整性、安全性和質(zhì)量的過程。是一種實際輸出與預(yù)期輸出之間的審核或者比較的過程。由于公司缺乏專業(yè)的軟件測試團隊，測試用例很容易出現(xiàn)需求覆蓋不全面的情況，會造成