聯(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è)試。
您可能感興趣的試卷
- 2009年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2009年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年下午試卷
- 2010年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2011年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2012年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2013年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2014年計(jì)算機(jī)技術(shù)與軟件專(zhuān)業(yè)技術(shù)資格高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
你可能感興趣的試題
最新試題
RMO公司銷(xiāo)售區(qū)域?qū)⒃谖磥?lái)5年大面積擴(kuò)展,其潛在客戶(hù)數(shù)量也會(huì)因此大幅度增加,所以良好的可擴(kuò)展性是CRSS系統(tǒng)所必需的質(zhì)量屬性。請(qǐng)分別說(shuō)明在集中式和分布式數(shù)據(jù)架構(gòu)下,可以采用哪些方法提升系統(tǒng)的可擴(kuò)展性。
李工接到任務(wù)后,認(rèn)為本項(xiàng)目比較簡(jiǎn)單,很快就安排3名技術(shù)人員分別負(fù)責(zé)數(shù)據(jù)采集/輸出模塊、數(shù)據(jù)處理模塊和比較監(jiān)控模塊的編寫(xiě)??偣こ處熉?tīng)到匯報(bào)后,認(rèn)為李工的方案和安排不妥,理由是李工忽視了系統(tǒng)的可靠性要求,對(duì)系統(tǒng)需求的理解不夠深入。為實(shí)現(xiàn)系統(tǒng)關(guān)于可靠性方面的需求:①你認(rèn)為在組織結(jié)構(gòu)、人員分工、設(shè)計(jì)開(kāi)發(fā)等方面應(yīng)做出哪些安排和規(guī)定?②請(qǐng)寫(xiě)出關(guān)于余度表決算法的考慮。
在架構(gòu)評(píng)估過(guò)程中,質(zhì)量屬性效用樹(shù)(UtilityTree)是對(duì)系統(tǒng)質(zhì)量屬性進(jìn)行識(shí)別和優(yōu)先級(jí)排序的重要工具。請(qǐng)給出合適的質(zhì)量屬性,填入圖12-24中(1)、(2)空白處;并選擇題干描述的(a)~(m),填入(3)~(6)空白處,完成該系統(tǒng)的效用樹(shù)。
在架構(gòu)評(píng)估過(guò)程中,需要正確識(shí)別系統(tǒng)的架構(gòu)風(fēng)險(xiǎn)、敏感點(diǎn)和權(quán)衡點(diǎn),并進(jìn)行合理的架構(gòu)決策。請(qǐng)用300字以?xún)?nèi)的文字給出系統(tǒng)架構(gòu)風(fēng)險(xiǎn)、敏感點(diǎn)和權(quán)衡點(diǎn)的定義,并從題干(a)~(m)中各選出一個(gè)對(duì)系統(tǒng)架構(gòu)風(fēng)險(xiǎn)、敏感點(diǎn)和權(quán)衡點(diǎn)最為恰當(dāng)?shù)拿枋觥?/p>
在劉工建議的基礎(chǔ)上,為了避免CRSS系統(tǒng)的單點(diǎn)故障,請(qǐng)用200字以?xún)?nèi)文字簡(jiǎn)要說(shuō)明如何建立CRSS的數(shù)據(jù)庫(kù)系統(tǒng);對(duì)于數(shù)據(jù)的讀取、添加、更改和刪除操作分別如何實(shí)現(xiàn)
發(fā)揮信息系統(tǒng)效益的關(guān)鍵是信息資源的有機(jī)共享,請(qǐng)給出該市政務(wù)信息資源共享的建議(200字以?xún)?nèi))。
針對(duì)李工的設(shè)計(jì)缺陷,請(qǐng)用300字以?xún)?nèi)的文字說(shuō)明本項(xiàng)目應(yīng)如何進(jìn)行正確設(shè)計(jì)。
請(qǐng)用300字以?xún)?nèi)文字,分析公司向備份中心備份數(shù)據(jù)的時(shí)間間隔的選取、公司日常業(yè)務(wù)系統(tǒng)的運(yùn)行性能,以及在災(zāi)難發(fā)生時(shí)數(shù)據(jù)損失情況三者之間的關(guān)系。
一個(gè)大型電子商務(wù)項(xiàng)目正處于建設(shè)方案征集、論證階段,某系統(tǒng)集成商為了贏得客戶(hù)的信任,需要提供一份建議方案文檔,對(duì)客戶(hù)的需求進(jìn)行響應(yīng)(包括問(wèn)題1、問(wèn)題2和問(wèn)題3所涉及的內(nèi)容)。高質(zhì)量的建議方案能夠顯示出集成商在處理客戶(hù)RFP(Request For Proposal)方面的能力、實(shí)力和專(zhuān)業(yè)性,而創(chuàng)建一個(gè)高質(zhì)量的建議方案,需要調(diào)配眾多的資源,按照計(jì)劃執(zhí)行。請(qǐng)用300字以?xún)?nèi)文字簡(jiǎn)要敘述如何創(chuàng)建一份高質(zhì)量的建議方案文檔。
性能是Web應(yīng)用系統(tǒng)的一個(gè)重要質(zhì)量屬性。請(qǐng)用200字以?xún)?nèi)的文字說(shuō)明3個(gè)主要影響Web應(yīng)用系統(tǒng)性能的因素,針對(duì)每個(gè)因素提出解決方案以提高系統(tǒng)性能。