聯(lián)合需求分析會(huì)議
某軟件公司接受A公司委托開發(fā)一個(gè)軟件任務(wù)，該任務(wù)由張工負(fù)責(zé)。張工預(yù)計(jì)在4周內(nèi)完成對(duì)系統(tǒng)的需求分析，并形成需求規(guī)格說明書。張工委派了項(xiàng)目組的小劉來負(fù)責(zé)需求信息的獲取。
兩周后，小劉向張工匯報(bào)了他進(jìn)行需求分析的過程及結(jié)果。小劉采用問卷調(diào)查的方式向A公司的50名工作人員搜集信息。他首先準(zhǔn)備了問卷的初稿，并請(qǐng)A公司的相關(guān)管理人員進(jìn)行了測(cè)試和修正；然后將問卷分發(fā)給A公司的每位工作人員，并要求他們?cè)谝恢軆?nèi)返還問卷。但到目前為止，小劉只收回了7份問卷。小劉認(rèn)為自己是完全按照問卷調(diào)查的步驟和要求實(shí)施的，而問卷的返還率仍然很低。張工聽完后，給小劉分析了失敗的原因，并提出了一些能夠提高問卷返還率的建議。
但是為了不耽誤項(xiàng)目的進(jìn)度，張工決定采用JRP（Joint Requirements Planning）的方法再次進(jìn)行需求調(diào)查，張工作為JRP的主持人。最終在第4周完成了需求規(guī)格說明書，并決定了系統(tǒng)后續(xù)階段的開發(fā)計(jì)劃，如圖12-3所示。
該項(xiàng)目組除了張工之外，還有2名全職的開發(fā)人員，可以承擔(dān)項(xiàng)目中的任何任務(wù)，并且承擔(dān)同一任務(wù)的開發(fā)人員總是在一起工作。預(yù)計(jì)的開發(fā)時(shí)間中已經(jīng)包含了編寫文檔的時(shí)間。張工決定采用迭代模型，在160天內(nèi)完成這3個(gè)模塊的設(shè)計(jì)、實(shí)現(xiàn)與測(cè)試。

聯(lián)合需求分析會(huì)議
某軟件公司接受A公司委托開發(fā)一個(gè)軟件任務(wù)，該任務(wù)由張工負(fù)責(zé)。張工預(yù)計(jì)在4周內(nèi)完成對(duì)系統(tǒng)的需求分析，并形成需求規(guī)格說明書。張工委派了項(xiàng)目組的小劉來負(fù)責(zé)需求信息的獲取。
兩周后，小劉向張工匯報(bào)了他進(jìn)行需求分析的過程及結(jié)果。小劉采用問卷調(diào)查的方式向A公司的50名工作人員搜集信息。他首先準(zhǔn)備了問卷的初稿，并請(qǐng)A公司的相關(guān)管理人員進(jìn)行了測(cè)試和修正；然后將問卷分發(fā)給A公司的每位工作人員，并要求他們?cè)谝恢軆?nèi)返還問卷。但到目前為止，小劉只收回了7份問卷。小劉認(rèn)為自己是完全按照問卷調(diào)查的步驟和要求實(shí)施的，而問卷的返還率仍然很低。張工聽完后，給小劉分析了失敗的原因，并提出了一些能夠提高問卷返還率的建議。
但是為了不耽誤項(xiàng)目的進(jìn)度，張工決定采用JRP（Joint Requirements Planning）的方法再次進(jìn)行需求調(diào)查，張工作為JRP的主持人。最終在第4周完成了需求規(guī)格說明書，并決定了系統(tǒng)后續(xù)階段的開發(fā)計(jì)劃，如圖12-3所示。
該項(xiàng)目組除了張工之外，還有2名全職的開發(fā)人員，可以承擔(dān)項(xiàng)目中的任何任務(wù)，并且承擔(dān)同一任務(wù)的開發(fā)人員總是在一起工作。預(yù)計(jì)的開發(fā)時(shí)間中已經(jīng)包含了編寫文檔的時(shí)間。張工決定采用迭代模型，在160天內(nèi)完成這3個(gè)模塊的設(shè)計(jì)、實(shí)現(xiàn)與測(cè)試。

結(jié)構(gòu)化軟件系統(tǒng)建模
博學(xué)公司擬開發(fā)一個(gè)商業(yè)情報(bào)處理系統(tǒng)，使公司能夠及時(shí)針對(duì)市場(chǎng)環(huán)境的變化及時(shí)調(diào)整發(fā)展戰(zhàn)略，以獲取最大的商業(yè)利益。項(xiàng)目組 經(jīng)過討論，決定采用結(jié)構(gòu)化分析和設(shè)計(jì)方法。在系統(tǒng)分析階段，為了更好地對(duì)情報(bào)數(shù)據(jù)處理流程及其與外部角色的關(guān)聯(lián)進(jìn)行建模，項(xiàng)目組成員分別給出了自己的設(shè)計(jì) 思路：
①小張?zhí)岢鱿葮?gòu)建系統(tǒng)流程圖(System Flowcharts)，以便更精確地反映系統(tǒng)的業(yè)務(wù)處理過程及數(shù)據(jù)的輸入和輸出。
②小李提出先構(gòu)建系統(tǒng)數(shù)據(jù)流圖(Data Flow Diagrams)，來展現(xiàn)系統(tǒng)的處理過程和定義業(yè)務(wù)功能邊界，并給出了情報(bào)分類子系統(tǒng)的0層和1層數(shù)據(jù)流圖，后者如圖12-1所示。
項(xiàng)目組經(jīng)討論確定以數(shù)據(jù)流圖作為本階段的建模手段。工程師老王詳細(xì)說明了流程圖和數(shù)據(jù)流圖之間的區(qū)別與聯(lián)系，并指出了圖12-1所示的數(shù)據(jù)流圖中存在的錯(cuò)誤。

結(jié)構(gòu)化軟件系統(tǒng)建模
博學(xué)公司擬開發(fā)一個(gè)商業(yè)情報(bào)處理系統(tǒng)，使公司能夠及時(shí)針對(duì)市場(chǎng)環(huán)境的變化及時(shí)調(diào)整發(fā)展戰(zhàn)略，以獲取最大的商業(yè)利益。項(xiàng)目組 經(jīng)過討論，決定采用結(jié)構(gòu)化分析和設(shè)計(jì)方法。在系統(tǒng)分析階段，為了更好地對(duì)情報(bào)數(shù)據(jù)處理流程及其與外部角色的關(guān)聯(lián)進(jìn)行建模，項(xiàng)目組成員分別給出了自己的設(shè)計(jì) 思路：
①小張?zhí)岢鱿葮?gòu)建系統(tǒng)流程圖(System Flowcharts)，以便更精確地反映系統(tǒng)的業(yè)務(wù)處理過程及數(shù)據(jù)的輸入和輸出。
②小李提出先構(gòu)建系統(tǒng)數(shù)據(jù)流圖(Data Flow Diagrams)，來展現(xiàn)系統(tǒng)的處理過程和定義業(yè)務(wù)功能邊界，并給出了情報(bào)分類子系統(tǒng)的0層和1層數(shù)據(jù)流圖，后者如圖12-1所示。
項(xiàng)目組經(jīng)討論確定以數(shù)據(jù)流圖作為本階段的建模手段。工程師老王詳細(xì)說明了流程圖和數(shù)據(jù)流圖之間的區(qū)別與聯(lián)系，并指出了圖12-1所示的數(shù)據(jù)流圖中存在的錯(cuò)誤。

閱讀以下信息系統(tǒng)可靠性問題的說明，在答題紙上回答問題1至問題3。
某軟件公司開發(fā)一項(xiàng)基于數(shù)據(jù)流的軟件，其系統(tǒng)的主要功能是對(duì)輸入數(shù)據(jù)進(jìn)行多次分析、處理和加工，生成需要的輸出數(shù)據(jù)。需求方對(duì)該系統(tǒng)的軟件可靠性要求很高，要求系統(tǒng)能夠長時(shí)間無故障運(yùn)行。該公司將該系統(tǒng)設(shè)計(jì)交給王工負(fù)責(zé)。王工給出該系統(tǒng)的模塊示意圖如圖20-5所示。王工解釋：只要各個(gè)模塊的可靠度足夠高，失效率足夠低，則整個(gè)軟件系統(tǒng)的可靠性是有保證的。
李工對(duì)王工的方案提出了異議。李工認(rèn)為王工的說法有兩個(gè)問題：第一，即使每個(gè)模塊的可靠度足夠高，但是整個(gè)軟件系統(tǒng)模塊之間全部采用串聯(lián)，則整個(gè)軟件系統(tǒng)的可靠度明顯下降。假設(shè)各個(gè)模塊的可靠度均為0.99，則整個(gè)軟件系統(tǒng)的可靠度為0.99⁴≈0.96：第二，軟件系統(tǒng)模塊全部采用串聯(lián)結(jié)構(gòu)時(shí)，一旦某個(gè)模塊失效，則意味著整個(gè)軟件系統(tǒng)失效。
李工認(rèn)為，應(yīng)該在軟件系統(tǒng)中采用冗余技術(shù)中的動(dòng)態(tài)冗余或者軟件容錯(cuò)的N版本程序設(shè)計(jì)技術(shù)，對(duì)容易失效或者非常重要的模塊進(jìn)行冗余設(shè)計(jì)，將模塊之間的串聯(lián)結(jié)構(gòu)部分變?yōu)椴⒙?lián)結(jié)構(gòu)，來提高整個(gè)軟件系統(tǒng)的可靠性。同時(shí)，李工給出了采用動(dòng)態(tài)冗余技術(shù)后的軟件系統(tǒng)模塊示意圖，如圖20-6所示。
劉工建議，李工方案中M1和M4模塊沒有采用容錯(cuò)設(shè)計(jì)，但是M1和M4發(fā)生故障有可能導(dǎo)致嚴(yán)重后果。因此，可以在M1和M4模塊設(shè)計(jì)上采用檢錯(cuò)技術(shù)，在軟件出現(xiàn)故障后能及時(shí)發(fā)現(xiàn)并報(bào)警，提醒維護(hù)人員進(jìn)行處理。
注：假設(shè)各個(gè)模塊的可靠度均為0.99。