問(wèn)答題

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

假設(shè):①整個(gè)開(kāi)發(fā)實(shí)施兩輪迭代。②每個(gè)任務(wù)都被劃分為2個(gè)子任務(wù)(例如,實(shí)現(xiàn)可以劃分為實(shí)現(xiàn)1和實(shí)現(xiàn)2),對(duì)應(yīng)兩輪迭代。③完成每個(gè)子任務(wù)需要花費(fèi)24人天。④整個(gè)系統(tǒng)的集成測(cè)試、改正錯(cuò)誤及驗(yàn)證需要花費(fèi)48人天。⑤第一輪迭代結(jié)束時(shí),形成版本v0.5;第二輪迭代結(jié)束時(shí),整個(gè)系統(tǒng)的開(kāi)發(fā)任務(wù)全部完成,形成版本v1.0。根據(jù)上述假設(shè),給出采用迭代模型開(kāi)發(fā)的各里程碑及其完成時(shí)間(標(biāo)出在第幾天完成)與交付產(chǎn)品。

你可能感興趣的試題

1.問(wèn)答題

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

請(qǐng)用300字以內(nèi)文字簡(jiǎn)要說(shuō)明JRP的基本思想及保證JRP順利實(shí)施的基本原則。
2.問(wèn)答題

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

用150字以內(nèi)的文字,說(shuō)明張工給小劉提出的提高問(wèn)卷返還率的可能措施。
3.問(wèn)答題

結(jié)構(gòu)化軟件系統(tǒng)建模
博學(xué)公司擬開(kāi)發(fā)一個(gè)商業(yè)情報(bào)處理系統(tǒng),使公司能夠及時(shí)針對(duì)市場(chǎng)環(huán)境的變化及時(shí)調(diào)整發(fā)展戰(zhàn)略,以獲取最大的商業(yè)利益。項(xiàng)目組 經(jīng)過(guò)討論,決定采用結(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ù)處理過(guò)程及數(shù)據(jù)的輸入和輸出。
②小李提出先構(gòu)建系統(tǒng)數(shù)據(jù)流圖(Data Flow Diagrams),來(lái)展現(xiàn)系統(tǒng)的處理過(guò)程和定義業(yè)務(wù)功能邊界,并給出了情報(bào)分類(lèi)子系統(tǒng)的0層和1層數(shù)據(jù)流圖,后者如圖12-1所示。
項(xiàng)目組經(jīng)討論確定以數(shù)據(jù)流圖作為本階段的建模手段。工程師老王詳細(xì)說(shuō)明了流程圖和數(shù)據(jù)流圖之間的區(qū)別與聯(lián)系,并指出了圖12-1所示的數(shù)據(jù)流圖中存在的錯(cuò)誤。

高質(zhì)量的數(shù)據(jù)流圖是可讀的、內(nèi)部一致的并能夠準(zhǔn)確表示系統(tǒng)需求。請(qǐng)用300字以內(nèi)說(shuō)明在設(shè)計(jì)高質(zhì)量的數(shù)據(jù)流圖時(shí)應(yīng)考慮的3個(gè)原則。
4.問(wèn)答題

結(jié)構(gòu)化軟件系統(tǒng)建模
博學(xué)公司擬開(kāi)發(fā)一個(gè)商業(yè)情報(bào)處理系統(tǒng),使公司能夠及時(shí)針對(duì)市場(chǎng)環(huán)境的變化及時(shí)調(diào)整發(fā)展戰(zhàn)略,以獲取最大的商業(yè)利益。項(xiàng)目組 經(jīng)過(guò)討論,決定采用結(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ù)處理過(guò)程及數(shù)據(jù)的輸入和輸出。
②小李提出先構(gòu)建系統(tǒng)數(shù)據(jù)流圖(Data Flow Diagrams),來(lái)展現(xiàn)系統(tǒng)的處理過(guò)程和定義業(yè)務(wù)功能邊界,并給出了情報(bào)分類(lèi)子系統(tǒng)的0層和1層數(shù)據(jù)流圖,后者如圖12-1所示。
項(xiàng)目組經(jīng)討論確定以數(shù)據(jù)流圖作為本階段的建模手段。工程師老王詳細(xì)說(shuō)明了流程圖和數(shù)據(jù)流圖之間的區(qū)別與聯(lián)系,并指出了圖12-1所示的數(shù)據(jù)流圖中存在的錯(cuò)誤。

請(qǐng)分析指出圖12-1所示的數(shù)據(jù)流圖中存在的錯(cuò)誤及其原因,并針對(duì)圖12-1所示的l層數(shù)據(jù)流圖繪制出情報(bào)分類(lèi)子系統(tǒng)的0層數(shù)據(jù)流圖。
5.問(wèn)答題

閱讀以下信息系統(tǒng)可靠性問(wèn)題的說(shuō)明,在答題紙上回答問(wèn)題1至問(wèn)題3。
某軟件公司開(kāi)發(fā)一項(xiàng)基于數(shù)據(jù)流的軟件,其系統(tǒng)的主要功能是對(duì)輸入數(shù)據(jù)進(jìn)行多次分析、處理和加工,生成需要的輸出數(shù)據(jù)。需求方對(duì)該系統(tǒng)的軟件可靠性要求很高,要求系統(tǒng)能夠長(zhǎng)時(shí)間無(wú)故障運(yùn)行。該公司將該系統(tǒng)設(shè)計(jì)交給王工負(fù)責(zé)。王工給出該系統(tǒng)的模塊示意圖如圖20-5所示。王工解釋:只要各個(gè)模塊的可靠度足夠高,失效率足夠低,則整個(gè)軟件系統(tǒng)的可靠性是有保證的。
李工對(duì)王工的方案提出了異議。李工認(rèn)為王工的說(shuō)法有兩個(gè)問(wèn)題:第一,即使每個(gè)模塊的可靠度足夠高,但是整個(gè)軟件系統(tǒng)模塊之間全部采用串聯(lián),則整個(gè)軟件系統(tǒng)的可靠度明顯下降。假設(shè)各個(gè)模塊的可靠度均為0.99,則整個(gè)軟件系統(tǒng)的可靠度為0.994≈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),來(lái)提高整個(gè)軟件系統(tǒng)的可靠性。同時(shí),李工給出了采用動(dòng)態(tài)冗余技術(shù)后的軟件系統(tǒng)模塊示意圖,如圖20-6所示。
劉工建議,李工方案中M1和M4模塊沒(méi)有采用容錯(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。

請(qǐng)給出檢錯(cuò)技術(shù)的優(yōu)缺點(diǎn),并說(shuō)明檢測(cè)技術(shù)常見(jiàn)的實(shí)現(xiàn)方式和處理方式。

最新試題

請(qǐng)用300字以內(nèi)的文字,說(shuō)明張工和劉工提出的數(shù)據(jù)架構(gòu)的基本思想。 

題型:?jiǎn)柎痤}

請(qǐng)給出檢錯(cuò)技術(shù)的優(yōu)缺點(diǎn),并說(shuō)明檢測(cè)技術(shù)常見(jiàn)的實(shí)現(xiàn)方式和處理方式。

題型:?jiǎn)柎痤}

王工提出,根據(jù)用戶要求,本嵌入式系統(tǒng)應(yīng)具有高速并行處理能力,采用多處理器結(jié)構(gòu)比較適合,主要理由是多處理器結(jié)構(gòu)設(shè)計(jì)簡(jiǎn)單、可支持多個(gè)進(jìn)程在不同處理器上并發(fā)處理:而張工提出,必須分清"多處理器結(jié)構(gòu)"與"多核結(jié)構(gòu)"的優(yōu)點(diǎn)和缺點(diǎn),多處理器結(jié)構(gòu)雖然支持多進(jìn)程的并發(fā)處理,但沒(méi)有直接實(shí)現(xiàn)多線程并發(fā)執(zhí)行;多核結(jié)構(gòu)可以直接實(shí)現(xiàn)多線程并發(fā)執(zhí)行。要提高應(yīng)用的并行性就必須利用多個(gè)硬件資源的并行工作,建議采用超線程技術(shù)的多核結(jié)構(gòu)的處理器。請(qǐng)?zhí)顚?xiě)圖12-20(f)中的(1)~(8),并用300字以內(nèi)的文字對(duì)上述6種處理器結(jié)構(gòu)的工作原理進(jìn)行簡(jiǎn)要描述。

題型:?jiǎn)柎痤}

請(qǐng)用300字以內(nèi)文字,分析公司向備份中心備份數(shù)據(jù)的時(shí)間間隔的選取、公司日常業(yè)務(wù)系統(tǒng)的運(yùn)行性能,以及在災(zāi)難發(fā)生時(shí)數(shù)據(jù)損失情況三者之間的關(guān)系。

題型:?jiǎn)柎痤}

如圖12-23所示是李工在設(shè)計(jì)方案中給出的智能設(shè)備工作狀態(tài)轉(zhuǎn)換圖。①請(qǐng)指出圖中的兩處錯(cuò)誤(在圖中圈出)并用200字以內(nèi)的文字說(shuō)明理由。②給出正確的狀態(tài)轉(zhuǎn)換圖。

題型:?jiǎn)柎痤}

發(fā)揮信息系統(tǒng)效益的關(guān)鍵是信息資源的有機(jī)共享,請(qǐng)給出該市政務(wù)信息資源共享的建議(200字以內(nèi))。

題型:?jiǎn)柎痤}

請(qǐng)用150字以內(nèi)的文字說(shuō)明什么是系統(tǒng)失步,系統(tǒng)失步后應(yīng)如何處理。

題型:?jiǎn)柎痤}

為什么專家組一致認(rèn)為王工的實(shí)施方案切實(shí)可行?請(qǐng)用200字以內(nèi)文字簡(jiǎn)要說(shuō)明。

題型:?jiǎn)柎痤}

性能是Web應(yīng)用系統(tǒng)的一個(gè)重要質(zhì)量屬性。請(qǐng)用200字以內(nèi)的文字說(shuō)明3個(gè)主要影響Web應(yīng)用系統(tǒng)性能的因素,針對(duì)每個(gè)因素提出解決方案以提高系統(tǒng)性能。

題型:?jiǎn)柎痤}

在實(shí)現(xiàn)Mashup應(yīng)用時(shí),進(jìn)行內(nèi)容聚合的物理位置是一個(gè)十分重要的因素。目前很多Mashup站點(diǎn)都選擇在客戶端機(jī)器上進(jìn)行內(nèi)容聚合,構(gòu)成所謂的胖互聯(lián)網(wǎng)應(yīng)用程序(Rich Internet Application,RIA)。請(qǐng)你用200字以內(nèi)的文字說(shuō)明在客戶端進(jìn)行內(nèi)容聚合的優(yōu)點(diǎn)。

題型:?jiǎn)柎痤}