閱讀以下關(guān)于信息系統(tǒng)項目管理過程中項目質(zhì)量管理方面問題的敘述，回答問題1至問題3。

    信息技術(shù)有限公司(CSAI )曾經(jīng)為K公司開發(fā)過一套信息系統(tǒng)，該系統(tǒng)涉及了K公司的所有主要業(yè)務(wù)。該系統(tǒng)中關(guān)于組織機構(gòu)的業(yè)務(wù)規(guī)則如下：

    (1)組織機構(gòu)樹通過部門編碼體現(xiàn)層級和隸屬關(guān)系。即部門0001的下屬部門包括00010001、00010002,依次類推，根據(jù)代碼中包含的層級關(guān)系確定某  個部門在組織機構(gòu)樹中的確切位置，該編碼由公司統(tǒng)一制定。

    (2)任意一條業(yè)務(wù)數(shù)據(jù)隸屬于某個特定的部門。

    (3)部門之間存在友好和互斥的關(guān)系。關(guān)系為友好的部門可以共享業(yè)務(wù)數(shù)據(jù)，關(guān)系為互斥的部門互相不能訪問對方的業(yè)務(wù)數(shù)據(jù)。

    后來，K公司需要調(diào)整部門的組織結(jié)構(gòu)，因此對系統(tǒng)提出了升級的要求：

    (1)系統(tǒng)中的部門編碼需要更新為最新的企業(yè)標(biāo)準(zhǔn)。

    (2)組織機構(gòu)根據(jù)最新的企業(yè)標(biāo)準(zhǔn)重新生成。

    (3)組織結(jié)構(gòu)調(diào)整是不能丟失業(yè)務(wù)數(shù)據(jù)。、

    (4)系統(tǒng)中可以保留組織機構(gòu)調(diào)整的痕跡，業(yè)務(wù)數(shù)據(jù)可以追蹤除原屬于哪個部門，機構(gòu)調(diào)整后屬于哪個部門。

    (5)部門間友好和互斥的關(guān)系可能會被重新定義。

    (6)升級后的系統(tǒng)需要能夠適應(yīng)再次的組織機構(gòu)調(diào)整而不需要再次升級。

    項目經(jīng)理張工接受了這個項目，經(jīng)過細致的調(diào)研和分析，發(fā)現(xiàn)原系統(tǒng)存在如下缺陷：

    (1)原系統(tǒng)中將企業(yè)對部門的標(biāo)準(zhǔn)編碼設(shè)計為部門主鍵，修改起來難度很大，容易發(fā)生數(shù)據(jù)不一致的問題。

    (2)新的企業(yè)標(biāo)準(zhǔn)沒有考慮到原有企業(yè)標(biāo)準(zhǔn)，同是一個部門張工在原標(biāo)準(zhǔn)中為00010001，在新標(biāo)準(zhǔn)中為00010005,部門的層次也可能發(fā)生變化。

    (3)業(yè)務(wù)數(shù)據(jù)中保存了隸屬部門編碼，系統(tǒng)已經(jīng)使用近兩年，保存了大量的歷史業(yè)務(wù)數(shù)據(jù)。

    (4)原系統(tǒng)在設(shè)計時將部門間的友好與互斥關(guān)系硬編碼在系統(tǒng)代碼中，且涉及面很廣，原系統(tǒng)中80％以上的程序存在這樣的硬編碼。

    (5)不少業(yè)務(wù)邏輯和工作流程是根據(jù)特定的部門編碼進行判斷的，部門編碼的變化會造成業(yè)務(wù)混亂。

    (6)原系統(tǒng)在設(shè)計時沒有考慮到組織機構(gòu)調(diào)整的可能，也沒有對保留部門變革歷史的功能進行設(shè)計。

 　 張工認為，需求已經(jīng)非常明確，對于這個項目的關(guān)鍵是設(shè)計的質(zhì)量，其中包括解決方案的設(shè)計和業(yè)務(wù)系統(tǒng)的改造兩部分。一旦設(shè)計出現(xiàn)偏差，返工的工作量會非常巨大，反之，整個項目還是容易控制的。但張工在如何提高設(shè)計質(zhì)量方面卻犯了愁。

    【問題1】(8分)

    試以300字內(nèi)回答，張工可以采取哪些措施提高設(shè)計的質(zhì)量？

    【問題2】(9分)

    試以300字內(nèi)回答，除設(shè)計外，張工還需要特別注意哪些工程活動。

    【問題3】 (8分)

    試以300字內(nèi)回答，如何提高這些工程活動的質(zhì)量。

    這是一個開放式的案例分析題，案例中僅粗略地描述了項目背景的目標(biāo)，針對如何提高項目質(zhì)量進行發(fā)問，難度相對較大，需要仔細的分析。

    前面一部分對項目背景和目標(biāo)的描述無非是為了說明這么幾個問題：

    (1)這是一個系統(tǒng)改造的項目。

    (2)原系統(tǒng)中存在設(shè)計缺陷，沒有考慮過組織機構(gòu)改革的可能性。

    (3)需要大量更改原系統(tǒng)的程序，消除硬編碼。

    (4)需要更改已有的業(yè)務(wù)數(shù)據(jù)，同時增加部門變革歷史的功能。

    基于這些問題，案例的后半部分給出了張工的觀點：設(shè)計質(zhì)量是項目的關(guān)鍵，需要提高設(shè)計的質(zhì)量。結(jié)合案例后的問題，我們不難發(fā)現(xiàn)，案例的前半部分是引子，后半部分才是關(guān)鍵，也是該案例的題眼：如何提高項目的質(zhì)量，顯然需要用項目質(zhì)量管理的知識作答。

    質(zhì)量管理是項目管理中的一個知識域，但在PMBOK中并沒有給出具體的質(zhì)量管理的方法，需要結(jié)合軟件開發(fā)和項目的特點給出特定的質(zhì)量管理策略和方法。這也正是這個案例的用意所在，考察考生在面對實際的項目問題時需要采取哪些措施解決項目的質(zhì)量問題。

    我們首先從軟件工程的角度考慮一下軟件質(zhì)量的問題。軟件的質(zhì)量一直是軟件界近幾十年致力解決的問題，針對使用軟件提高軟件質(zhì)量提出了很多的方法和理論。首先是軟件工程的理論，需要使用工程活動的方法進行軟件開發(fā)，從系統(tǒng)定義與分析開始，經(jīng)過設(shè)計、實現(xiàn)，最終到驗證。在軟件工程中，人們提出了多種軟件開發(fā)模式和工程活動方法。在開發(fā)模式中，有瀑布模型、螺旋模型、迭代模型、噴泉模型等；在工程活動方法中，有自頂向下、結(jié)構(gòu)化分析、面向?qū)ο蠓治?、架?gòu)風(fēng)格，等等。除此之外，還有一系列的軟件驗證方法，如軟件復(fù)審與軟件測試?？v觀這些林林總總的模式與方法，人們無非是想解決兩個問題：一是通過恰當(dāng)?shù)墓こ袒顒犹岣吖ぷ鳟a(chǎn)品的質(zhì)量；二是在工作產(chǎn)品完成后通過恰當(dāng)?shù)墓こ袒顒觼肀ＷC該產(chǎn)品的質(zhì)量。因為在軟件開發(fā)過程中，還有一個很明顯的特點，就是在分析、設(shè)計、實現(xiàn)和測試這些過程中，每一步都可能引入缺陷，且難以發(fā)現(xiàn)，而這些缺陷暴露得越晚，造成的后果就越嚴(yán)重，修改的代價就越高昂。開發(fā)活動需要盡量提前發(fā)現(xiàn)潛在的缺陷，驗證手段必不可少。

    題目中問的是如何提高設(shè)計的質(zhì)量，設(shè)計是承接分析、指導(dǎo)開發(fā)的一個關(guān)鍵環(huán)節(jié)，在這個環(huán)節(jié)中很容易引入難以發(fā)現(xiàn)的缺陷，而這些缺陷往往又會造成嚴(yán)重的后果。因此提高設(shè)計的質(zhì)量是每個軟件項目都會遇到的問題，也是每個項目經(jīng)理都會思考的問題。提高設(shè)計質(zhì)量包括兩個層面的工作：在設(shè)計過程中提高設(shè)計的質(zhì)量；在設(shè)計完成后對設(shè)計結(jié)果的質(zhì)量檢查。在答題中需要分別給出相應(yīng)的策略。

    設(shè)計工作在分析工作之后，因此，充分的分析是保證設(shè)計質(zhì)量的前提。對于這種改造型項目，原系統(tǒng)的功能、設(shè)計和實現(xiàn)的情況直接影響了設(shè)計的結(jié)果，原系統(tǒng)的情況就是要解決的問題域，’如果對原系統(tǒng)了解不足必然導(dǎo)致設(shè)計上的偏差。因此要想提高設(shè)計的質(zhì)量，首先要充分了解原系統(tǒng)。

    在設(shè)計時還應(yīng)該選擇恰當(dāng)?shù)脑O(shè)計方法，如有可能可以考慮復(fù)用已有的解決案例，如分析模式與設(shè)計模式等。不過在這方面，案例中給出的信息甚少，顯然不是答題的重點。

    根據(jù)項目背景的描述，這個設(shè)計工作并不簡單，需要論證的過程，設(shè)計方案的討論也是必需的。因此張工需要制定出相應(yīng)的溝通計劃，組織必要的會議進行方案討論，若有必要還需要客戶和原系統(tǒng)的開發(fā)者參加。

    在設(shè)計完成后還需要對設(shè)計結(jié)果進行質(zhì)量檢查，對應(yīng)這類活動，我們通常采用評審和走查的方式。評審和走查可以比測試更早地找出工作產(chǎn)品中的缺陷，用來檢查設(shè)計質(zhì)量非常合適，可以避免缺陷在系統(tǒng)測試階段才被發(fā)現(xiàn)，降低修正缺陷的成本。

    除了評審和走查外，對設(shè)計過程進行迭代也可以提前暴露設(shè)計的缺陷，并將這些缺陷反饋到后續(xù)的設(shè)計過程中，從總體上減少缺陷數(shù)，提高設(shè)計的質(zhì)量。例如在可以將整個項目根據(jù)系統(tǒng)模塊進行劃分，首先升級一個模塊，然后把這個過程中發(fā)現(xiàn)的問題反饋到后續(xù)的迭代過程中。

    如果能夠做好上述工作，設(shè)計就不會產(chǎn)生重大的偏差，保證設(shè)計的質(zhì)量。

    對于第二個問題，除設(shè)計外，張工還需要特別注意哪些工程活動。

    在分析第一個問題是我們已經(jīng)找到了一部分答案—分析。分析是設(shè)計活動的基礎(chǔ)，在錯誤的分析上不可能產(chǎn)生正確的設(shè)計。因此充分、細致地分析原系統(tǒng)是保證設(shè)計質(zhì)量的前提。

    除此之外，對于系統(tǒng)改造的項目，測試的工作顯得非常重要。同原系統(tǒng)開發(fā)相比，系統(tǒng)改造的總工作量相對較少，但測試的工作量卻應(yīng)該超過原系統(tǒng)開始時的測試工作量。根據(jù)案例中的描述，超過80％的程序都存在硬編碼的問題，都需要修改。這些程序在修改后首先需要滿足同原系統(tǒng)功能一致，可以通過原系統(tǒng)測試用例的測試；其次還要保證與系統(tǒng)升級的目標(biāo)一致，能夠滿足設(shè)計的  要求，這就需要開發(fā)新的測試用例進行測試。因此，如何規(guī)劃、組織、展開測試工作，也是張工需要特別注意的方面。

    除了分析和測試外，其余的工程活動也是不可或缺的，不過相比之下，分析和測試工作更具特殊性，是張工必須特別注意的。

    第三個問題與第二個問題是關(guān)聯(lián)的。有了第二個問題的答案，第三個問題就比較容易了。

    如何提高分析活動的質(zhì)量呢？對于案例中的項目來說，系統(tǒng)要解決的是原系統(tǒng)中的缺陷，原系統(tǒng)本身就是問題域，提高分析活動的質(zhì)量也就是充分地分析原系統(tǒng)。對原系統(tǒng)的分析可以包括對原有業(yè)務(wù)功能、原設(shè)計方案和原程序的分析。對原系統(tǒng)中業(yè)務(wù)功能的分析需要同客戶一起進行，通過同客戶的溝通來把握原系統(tǒng)所實現(xiàn)的業(yè)務(wù)功能。對原設(shè)計方案的分析出了參考設(shè)計文檔外，最好能夠同原系統(tǒng)的開發(fā)者進行溝通