系統(tǒng)分析師考試歷年試題分析與解答(案例分析與論文篇)

1、系統(tǒng)分析師考試歷年試題分析與解答（案例分析與論文篇）第 1 章 軟件開發(fā)方法案例分析試題 軟件開發(fā)方法是指軟件開發(fā)過程所遵循的辦法和步驟，系統(tǒng)分析師考試大綱規(guī)定，考生要“熟練掌握信息系統(tǒng)開發(fā)過程和方法”。也就是說，系統(tǒng)分析師要能夠根據(jù)項目的實際情況，選擇恰當?shù)能浖_發(fā)方法。1.1  案例分析試題在2004年至2013年的考試試題中，共有6道試題和軟件開發(fā)方法有關(guān)，本節(jié)主要分析這6道試題。在本節(jié)的試題中，其考查范圍如表1-1所示。表1-1  軟件開發(fā)方法試題分布表1.1.1 2004年上半年試題52004年上半年試題5某公司要在現(xiàn)場開發(fā)一個網(wǎng)站應(yīng)

2、用系統(tǒng)，該系統(tǒng)的特點是：規(guī)模不大；工期短；用戶需求不明確；沒有大的技術(shù)風險；系統(tǒng)中的一些模塊可以外包給其他的公司開發(fā)。在選擇開發(fā)過程時，項目組內(nèi)產(chǎn)生了分歧。王工提出采用XP（eXtreme Programming，極限編程），理由是XP方法簡潔，能減輕開發(fā)人員的負擔、快速適應(yīng)市場、縮短投資回收期。李工認為采用XP在項目開發(fā)中存在一些問題，建議考慮原型開發(fā)方法。雙方就上述的問題展開了激烈的爭論。項目組最后決定采用XP，但同時針對李工提出的XP中存在的問題采取了相應(yīng)的措施?！締栴}1】小規(guī)模發(fā)布（small release）是XP的基本元素之一。請用200字以內(nèi)文字分別闡明：（1）原型系統(tǒng)和XP小規(guī)

3、模發(fā)布的系統(tǒng)的主要差別？（2）為什么該項目組沒有采用原型開發(fā)方法？【問題2】請用200字以內(nèi)文字，簡要說明采用XP方法可能會存在哪些問題?！締栴}3】在項目組的后續(xù)討論中，李工提出，如果項目規(guī)模擴大，XP將不再適用。王工對此表示贊同，但同時提出可以將XP方法和傳統(tǒng)軟件開發(fā)過程相結(jié)合。請用200字以內(nèi)的文字簡要地說明如何將XP方法和傳統(tǒng)軟件開發(fā)過程相結(jié)合。一、試題分析在我們面臨“軟件危機”所帶來的挑戰(zhàn)之時，曾經(jīng)通過采用嚴格的規(guī)范、詳盡的文檔來約束開發(fā)過程，以保證開發(fā)的質(zhì)量與效果，獲得了突出的成就。但是隨著時代的進一步發(fā)展，業(yè)務(wù)周期越來越短、變化越來越快，甚至在軟件開發(fā)的過程中，業(yè)務(wù)邏輯和需求已經(jīng)悄

4、然變化，這給本來還不成熟的軟件產(chǎn)業(yè)帶來了新的挑戰(zhàn)。正在這種情況下，敏捷方法論應(yīng)運而生。2001年這些方法論的創(chuàng)始人走到一起，成立了敏捷聯(lián)盟，發(fā)表了頗具影響力的敏捷宣言：個體和交互勝過過程和工具、可工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應(yīng)變化勝過遵循計劃。比較有影響力的敏捷方法論包括XP（極限編程）、FDD（特征驅(qū)動開發(fā)）、Crystal Method（水晶方法）、DSDM（動態(tài)系統(tǒng)開發(fā)方法）、ASD（自適應(yīng)開發(fā)）、Scrum等。本題主要考查考生對軟件開發(fā)過程的掌握情況，要求能夠了解各種不同的過程方法論，跟蹤其發(fā)展的趨勢，并且根據(jù)實際的情況和需求來正確地選擇合適的過程方法論。近幾

5、年來，由于以XP為代表的敏捷方法論的討論、實踐越來越多，也取得了較好的成效，因此對于從事軟件工程管理方面的考生來說，也成為一個重要的知識內(nèi)容?！締栴}1】當客戶有一個合理的要求，但對細節(jié)則沒有任何線索時，原型法開發(fā)是一個十分常用的方法。由于本題中所涉及的項目就是屬于需求不明確的，因此能夠有效利用原型法進行解決。原型法開發(fā)將從需求收集開始，開發(fā)者和客戶在一起定義軟件的總體目標，標識出已知的需求，并規(guī)劃出需要進一步定義的區(qū)域。然后就是“快速設(shè)計”，快速設(shè)計集中于軟件中那些對用戶/客戶可見的部分的表示（如輸入方式和輸出格式）?？赏ㄟ^快速設(shè)計來創(chuàng)建原型。原型由用戶/客戶評估并進一步精化待開發(fā)軟件的需求。

6、逐步調(diào)整原型使其滿足客戶的要求，而同時也使開發(fā)者對將要做的事情有較好的理解，這個過程是迭代的。理想情況下，原型可以作為標識軟件需求的一種機制。如果建立了可運行原型，開發(fā)者就可以在其基礎(chǔ)上試圖利用已有的程序片斷或使用工具（如報表生成器、窗口管理器）來盡快生成可運行的程序。原型開發(fā)方法在實施時，存在的問題主要包括以下兩個方面：（1）客戶似乎已經(jīng)看到了軟件的工作版本，卻無法理解，原因在于為了使原型能夠很快使用，開發(fā)者沒有考慮軟件的總體質(zhì)量和長期的可維護性。（2）開發(fā)者常常需要實施上的折中使原型能夠盡快工作。因此，通常采用原型法都會在客戶和開發(fā)者之間達成協(xié)議：構(gòu)建原型僅是為了定義需求，之后就被拋棄了（

7、至少是部分拋棄），實際的軟件在充分考慮了質(zhì)量和可維護性之后才被開發(fā)。這種原型開發(fā)方法也稱為“拋棄型原型開發(fā)”。當然，也可以采用逐漸演進的方式進行原型開發(fā)，即以逐步增加功能的方式進行開發(fā)，以便于隨時根據(jù)客戶或最終用戶的反饋來修正系統(tǒng)。大多數(shù)漸進原型都是從一個用戶界面原型開始逐步演化出整個系統(tǒng)的。不過采用原型開發(fā)可能出現(xiàn)的風險是：不切實際的進度和預(yù)算、項目可控性降低、缺乏最終用戶或客戶的反饋（這是因為，容易讓客戶的目標陷入界面，而忽略本質(zhì)，反而造成問題）、產(chǎn)品性能不佳、不切實際的性能期望、設(shè)計不佳、可維護性差、目標偏移，而且還有一個最重要的就是原型開發(fā)階段效率一般都較低。由于XP認為“客戶確切地知

8、道需求，而且當你實現(xiàn)其需求后，他仍然認同”這種現(xiàn)象幾乎不存在。因此，在XP方法論中最重要的一件事情就是盡早、盡量頻繁地發(fā)布。如果可能，第一次發(fā)布時間不應(yīng)超過兩個月，此后每兩個月發(fā)布一次。要注意的是，XP中每次發(fā)布的內(nèi)容不是演示版，而是實用版。也就是說，并不是僅僅將其演示給客戶看，讓其評論，最后放到一邊，繼續(xù)等待最后的開發(fā)結(jié)果，而是交付使用的子集，讓客戶每一天都在使用。另外，為了保證開發(fā)出來的結(jié)果與客戶的預(yù)想接近，XP方法論認為最重要的是需要將客戶請到開發(fā)現(xiàn)場。在項目中有客戶在現(xiàn)場明確用戶需求，并做出相應(yīng)的業(yè)務(wù)決策對于XP項目而言有著十分重要的意義。這時因為，僅靠簡單的用戶需求描述是不充分的，還

9、需要大量地與客戶溝通。在本題中所列舉的項目是在現(xiàn)場開發(fā)，因此現(xiàn)場客戶是有保證的?！締栴}2】XP的核心是其總結(jié)的溝通、簡單、反饋、勇氣四大價值觀。它包括12種最佳實踐：計劃游戲、小型發(fā)布、隱喻、簡單設(shè)計、測試先行、重構(gòu)、結(jié)對編程、集體代碼所有制、持續(xù)集成、每周工作40小時、現(xiàn)場客戶，以及編碼標準。從XP方法論本身來說，首先第一類潛在問題是精神和觀念上的，即是否能夠得到開發(fā)人員、管理者，以及客戶三方面的支持與理解。簡單設(shè)計、測試先行、重構(gòu)、集體代碼所有制、編碼標準、持續(xù)集成都從某種意義上違背了程序員的傳統(tǒng)習慣；而小型發(fā)布、結(jié)對編程、每周工作40小時，經(jīng)常會讓管理者不可理解，以致認為XP是黑客文化，

10、是為開發(fā)人員謀福利而來的；而現(xiàn)場客戶實踐則經(jīng)常無法得到客戶的理解和滿足，另外許多客戶在接受每一次小規(guī)模發(fā)布時，也會提出異議。另外，由于XP方法論屬于輕量級，也就是文檔量少，遵從“代碼就是文檔”的思想。因此雖然XP方法論中是有“當非要文檔時才編寫”的說法，但卻容易使團隊忽視文檔，從而降低系統(tǒng)的可維護性、易用性，以及其他的一些問題。除了培訓(xùn)教育之外，通常還可以采用的解決方案是利用諸如“敏捷建?！辈呗?，在兩個極端中間取一個合理的閾值。結(jié)合本題，還有一個十分重要的信息，那就是該項目將部分外包。由于XP方法論強調(diào)人的作用，團隊之間通過集體代碼制、結(jié)對編程等方式來提升交流與合作，從而提升生產(chǎn)率的。但是如果

11、項目有部分外包的話，將會破壞這種結(jié)構(gòu)，甚至可能影響到發(fā)布計劃?！締栴}3】XP方法論的創(chuàng)始人Kent Beck在其擁抱變化：解析極限編程一書中明確指出了：“XP是適合于中小型團隊在需求不明確或者迅速變化的情況下進行軟件開發(fā)的輕量級方法學(xué)”。它與傳統(tǒng)的方法論最大的不同在于：擁有短周期內(nèi)的早期、具體和持續(xù)的反饋。它遞增地進行計劃編制，也就是在項目的一開始迅速提供一個總體計劃，然后在項目的整個生命周期內(nèi)不斷地發(fā)展它。它針對不斷變化的業(yè)務(wù)需求靈活地對功能的實現(xiàn)進行計劃的能力。它依賴于由程序員或客戶編寫的自動測試來監(jiān)控開發(fā)進度。它依賴于口頭交流、測試和源代碼來溝通系統(tǒng)的結(jié)構(gòu)和意圖。它依賴于整個系統(tǒng)存在期間

12、一直持續(xù)的進化式設(shè)計過程。它依賴于技術(shù)水平一般的程序員之間的緊密協(xié)作。它依賴于能夠同時滿足程序員的短期本能和項目的長期利益的實踐。因此，我們可以發(fā)現(xiàn)它并不是與傳統(tǒng)的方法論有著“不共戴天”的變化，是存在很多的結(jié)合點，能夠有效地在傳統(tǒng)方法論中結(jié)合XP開發(fā)方法的。集中式方法是傳統(tǒng)的軟件工程方法的共同特點，它的優(yōu)點在于：具有共同的、清晰確定的目標，而且是一個結(jié)構(gòu)化的過程，領(lǐng)導(dǎo)團隊貫穿各個軟件開發(fā)階段。而它們最大的缺點是：缺乏負責員工的參與，而且客戶的反饋也很少，導(dǎo)致解決方案的接納度降低。XP方法與員工/客戶了解十分緊密，可以保證較高的解決方案接納度。不過把其運用到幾個局部問題上往往不能產(chǎn)生與多個團隊一

13、起共享的改進，加上XP方法無結(jié)構(gòu)，因此一個必須包含幾個人的復(fù)雜問題不能用它來產(chǎn)生一個全面的概念。（1）層次化結(jié)合?；谏鲜鱿敕?，可以提出層次化的管理，具體地說就是：在上層，建立一種面向目標的項目管理，它通過產(chǎn)生一個大致概念來把問題組織成一種高級結(jié)構(gòu)。將目前有局部化問題的每個部分都通過定義一個自身的XP團隊來用一種極限編程的方法予以解決。XP團隊主要在獨立的基礎(chǔ)上發(fā)揮功能。同時，他們通過跟蹤全局目標和衡量局部改進的頂層管理團隊以一種松散的方式被了解起來。（2）實踐引入式結(jié)合。另外一種結(jié)合的方式是仍然按照傳統(tǒng)過程方法論進行過程的管理，引入XP的實踐，實現(xiàn)優(yōu)勢互補。其中比較典型的包括如下幾點?，F(xiàn)場客

14、戶：這個實踐是對傳統(tǒng)過程方法論缺乏客戶參與的最好補充。簡單設(shè)計：“只為今天設(shè)計，不過多地考慮明天的需要，因為現(xiàn)在的假設(shè)可以是錯誤的，也許明天還有更好的實現(xiàn)方式”，這是XP所提倡的簡單原則，它也可以無縫地借用到用傳統(tǒng)過程方法論進行管理的項目中。小型發(fā)布：每次迭代都實現(xiàn)一次小型的發(fā)布，提交一個能夠讓用戶開始投入使用的小型版本，可以有效地加強反饋，縮短開發(fā)進程，提高軟件質(zhì)量。其中還可結(jié)合每日構(gòu)建進行持續(xù)集成，予以保障與支持。測試先行、重構(gòu)：這是保持“小步快走”的關(guān)鍵實踐，對于軟件質(zhì)量的提高有很大的幫助。除此之外，XP方法論中的其他實踐也能夠有效地在傳統(tǒng)的開發(fā)過程中發(fā)揮作用。二、參考答案【問題1】（1

15、）原型系統(tǒng)和XP小型發(fā)布的系統(tǒng)的主要差別是功能。采用原型系統(tǒng)主要是讓用戶確認需求，或者用來測試關(guān)鍵的技術(shù)，但是它展示的功能并不是實際系統(tǒng)的功能，不能用來評價實際的系統(tǒng)；XP小型發(fā)布的系統(tǒng)考試時不包括足夠的功能，但是每個功能和可發(fā)布的產(chǎn)品的定義是一樣的。在完整性上，它配備了一系列實用的功能集；在質(zhì)量上，它可以健壯地運行。（2）在該項目中，不需要開發(fā)原型系統(tǒng)。由于項目沒有大的技術(shù)風險，所以不需要用原型系統(tǒng)來測試關(guān)鍵技術(shù)。網(wǎng)站系統(tǒng)的開發(fā)和原型系統(tǒng)的開發(fā)在工作量上是相當?shù)?，在時間要求短的情況下，直接開發(fā)系統(tǒng)可以節(jié)省時間。對于用戶需求經(jīng)常發(fā)生變化的情況，可以采用XP開發(fā)方法的代碼重構(gòu)、持續(xù)集成和小型發(fā)布

16、等技術(shù)。【問題2】（1）開發(fā)團隊、管理層，以及客戶的不理解，阻礙XP方法論實施。（2）導(dǎo)致開發(fā)團隊忽視文檔，以XP為借口拒絕編寫甚至是必須的文檔。（3）XP是針對單一團隊設(shè)計的，外包方的參與將會為有效的組織帶來很大的困難。（4）缺乏客戶的參與，導(dǎo)致用戶故事編寫、優(yōu)先級確認等工作遇到困難。（5）項目規(guī)模擴大后，XP方法論將不適應(yīng)。（6）對客戶、開發(fā)人員和管理者的素質(zhì)要求較高?！締栴}3】（1）可以將XP和傳統(tǒng)軟件開發(fā)過程中的增量式開發(fā)過程相結(jié)合。（2）將大規(guī)模項目劃分為若干個具有共同目標的小規(guī)模項目，用XP方法論組織小項目開發(fā)，用傳統(tǒng)軟件過程方法論監(jiān)控全局。（3）在此基礎(chǔ)上，建立面向目標的項目管理

17、。1.1.2 2004年下半年試題52004年下半年試題5希賽公司是一家中等規(guī)模的計算機企業(yè)，專業(yè)從事網(wǎng)絡(luò)安全防護軟件系統(tǒng)的開發(fā)。從最初僅開發(fā)基于Windows的個人防火墻產(chǎn)品開始，現(xiàn)在，已經(jīng)延伸到基于Linux、Windows系列、MAC操作系統(tǒng)的個人防火墻、企業(yè)防火墻、入侵檢測系統(tǒng)、病毒掃描系統(tǒng)、安全掃描系統(tǒng)等多種產(chǎn)品。公司原來的產(chǎn)品都是一個一個地開發(fā)，為每個軟件對應(yīng)地組織一個項目組。為了適應(yīng)快速變化的市場，降低開發(fā)成本，公司想引入產(chǎn)品線方法。然而，由于軟件產(chǎn)品線方法涉及了一個軟件開發(fā)企業(yè)的多個產(chǎn)品，所以，公司的王總決定在弄清楚以下三個問題之后再做決定：首先就是本公司的業(yè)務(wù)范圍是否適合使用

18、產(chǎn)品線方法，其次是如何在原有產(chǎn)品的基礎(chǔ)上建立產(chǎn)品線，最后是成功實施產(chǎn)品線的主要因素是什么？【問題1】請用100字以內(nèi)文字，說明希賽公司是否適合采用產(chǎn)品線方法，并說明理由。【問題2】請用400字以內(nèi)文字，說明在原有產(chǎn)品的基礎(chǔ)上建立軟件產(chǎn)品線的方式，并作簡要評價?！締栴}3】請用150字以內(nèi)文字，說明成功實施產(chǎn)品線的主要因素。一、試題分析軟件產(chǎn)品線（software product line）是一個十分適合專業(yè)的軟件開發(fā)組織的軟件開發(fā)方法，能有效地提高軟件生產(chǎn)率和質(zhì)量、縮短開發(fā)時間、降低總開發(fā)成本；它也是一個新興的、多學(xué)科交叉的研究領(lǐng)域，研究內(nèi)容和范圍都相當廣泛?？突仿〈髮W(xué)軟件工程研究所（CMU

19、/SEI）對產(chǎn)品線和軟件產(chǎn)品線的定義，比較能夠體現(xiàn)軟件產(chǎn)品線的特征：“產(chǎn)品線是一個產(chǎn)品集合，這些產(chǎn)品共享一個公共的、可管理的特征集，這個特征集能滿足選定的市場或任務(wù)領(lǐng)域的特定需求。這些系統(tǒng)是遵循一個預(yù)描述的方式，在公共的核心資源（core assets）基礎(chǔ)上開發(fā)的?！避浖a(chǎn)品線開發(fā)有四個基本技術(shù)特點：過程驅(qū)動、特定領(lǐng)域、技術(shù)支持和架構(gòu)為中心。與其他軟件開發(fā)方法相比，軟件開發(fā)組織選擇軟件產(chǎn)品線的宏觀上的原因有：對產(chǎn)品線及其實現(xiàn)所需的專家知識領(lǐng)域的清楚界定，對產(chǎn)品線的長期遠景進行了策略性規(guī)劃。【問題1】產(chǎn)品線的起源可以追溯到1976年P(guān)arnas對程序族的研究。軟件產(chǎn)品線的實踐早在20世紀80年

20、代中期就出現(xiàn)了。最著名的例子是瑞士CelsiusTech公司的艦艇防御系統(tǒng)的開發(fā)，該公司從1986年開始使用軟件產(chǎn)品線開發(fā)方法，使得整個系統(tǒng)中軟件和硬件在總成本中所占比例從使用軟件產(chǎn)品線方法之前的65:35下降到使用后的20:80，系統(tǒng)開發(fā)時間從約需要9年下降到不到3年。據(jù)HP公司1996年對HP、IBM、NEC、ATT等幾個大型公司分析研究，他們在采用了軟件產(chǎn)品線開發(fā)方法后，使產(chǎn)品的開發(fā)時間減少1.52倍，維護成本降低25倍，軟件質(zhì)量提升510倍，軟件重用達50%80%，開發(fā)成本降低12%15%。雖然軟件工業(yè)界已經(jīng)在大量使用軟件產(chǎn)品線開發(fā)方法，但是正式的對軟件產(chǎn)品線的理論研究到20世紀90年

21、代中期才出現(xiàn)，并且早期的研究主要以實例分析為主。到了20世紀90年代后期，軟件產(chǎn)品線的研究已經(jīng)成為軟件工程領(lǐng)域最熱門的研究領(lǐng)域。得益于豐富的實踐和軟件工程、軟件架構(gòu)、軟件重用技術(shù)等堅實的理論基礎(chǔ)，軟件產(chǎn)品線的研究發(fā)展十分迅速，目前軟件產(chǎn)品線的發(fā)展已經(jīng)趨向成熟。很多大學(xué)已經(jīng)鎖定軟件產(chǎn)品線，將其作為一個研究領(lǐng)域，并有大學(xué)已經(jīng)開設(shè)軟件產(chǎn)品線相關(guān)的課程。一些的國際著名學(xué)術(shù)會議也設(shè)立了相應(yīng)的產(chǎn)品線專題學(xué)術(shù)討論會，第一次國際產(chǎn)品線會議于2000年8月在美國Denver召開等。與軟件架構(gòu)的發(fā)展類似，軟件產(chǎn)品線的發(fā)展也很大地得益于軍方的支持。如美國國防部支持的兩個典型項目：關(guān)于基于特定領(lǐng)域軟件架構(gòu)的軟件開發(fā)方

22、法的研究項目（DSSA），關(guān)于過程驅(qū)動、特定領(lǐng)域和基于重用的軟件開發(fā)方法的研究項目（STARS）。這兩個項目在軟件架構(gòu)和軟件重用兩個方面極大地推動了軟件產(chǎn)品線的研究和發(fā)展?？梢哉f軟件產(chǎn)品線方法是軟件工程領(lǐng)域中軟件架構(gòu)和軟件重用技術(shù)發(fā)展的結(jié)果。與軟件架構(gòu)一樣，目前，軟件產(chǎn)品線沒有一個統(tǒng)一的定義，常見的定義有：（1）將利用了產(chǎn)品間公共方面、預(yù)期考慮了可變性等設(shè)計的產(chǎn)品族稱為產(chǎn)品線。（2）產(chǎn)品線就是由在系統(tǒng)的組成元素和功能方面具有共性（commonality）和個性（variability）的相似的多個系統(tǒng)組成的一個系統(tǒng)族。（3）軟件產(chǎn)品線就是在一個公共的軟件資源集合基礎(chǔ)上建立起來的，共享同一個特性

23、集合的系統(tǒng)集合。（4）一個軟件產(chǎn)品線由一個產(chǎn)品線架構(gòu)、一個可重用構(gòu)件集合和一個源自共享資源的產(chǎn)品集合組成，是組織一組相關(guān)軟件產(chǎn)品開發(fā)的方式。（5）產(chǎn)品線是一個產(chǎn)品集合，這些產(chǎn)品共享一個公共的、可管理的特征集，這個特征集能滿足選定的市場或任務(wù)領(lǐng)域的特定需求。這些系統(tǒng)遵循一個預(yù)描述的方式，是在公共的核心資源（core assets）基礎(chǔ)上開發(fā)的。根據(jù)CMU/SEI的定義，軟件產(chǎn)品線主要由兩部分組成：核心資源和產(chǎn)品集合。核心資源是領(lǐng)域工程的所有結(jié)果的集合，是產(chǎn)品線中產(chǎn)品構(gòu)造的基礎(chǔ)。也有組織將核心資源庫稱為“平臺（Platform）”。核心資源必定包含產(chǎn)品線中所有產(chǎn)品共享的產(chǎn)品線架構(gòu)，新設(shè)計開發(fā)的或者

24、通過對現(xiàn)有系統(tǒng)的再工程得到的、需要在整個產(chǎn)品線中系統(tǒng)化重用的軟件構(gòu)件。與軟件構(gòu)件相關(guān)的測試計劃、測試實例，以及所有設(shè)計文檔，需求說明書和領(lǐng)域模型還有領(lǐng)域范圍的定義也是核心資源，采用COTS的構(gòu)件也屬于核心資源。產(chǎn)品線架構(gòu)和構(gòu)件是軟件產(chǎn)品線中的核心資源中最重要的部分。從上述的描述中，我們可以發(fā)現(xiàn)公司是否適于使用軟件產(chǎn)品線開發(fā)方法，最主要的判斷點在于是否能夠抽取可以在所有產(chǎn)品集合中可系統(tǒng)化重用的軟件構(gòu)件，即核心資源。而在本題中，由于希賽公司是專業(yè)從事網(wǎng)絡(luò)安全防護軟件系統(tǒng)的開發(fā)，其個人防火墻、企業(yè)防火墻、入侵檢測系統(tǒng)、病毒掃描系統(tǒng)、安全掃描系統(tǒng)等產(chǎn)品都是屬于同一個領(lǐng)域，具有很多共性的地方，因此可以通

25、過領(lǐng)域模型來確定領(lǐng)域/產(chǎn)品線的共性和可變性，為產(chǎn)品線設(shè)計架構(gòu)。另外，由于對于各種系統(tǒng)而言，都需要處理不同操作系統(tǒng)平臺，但實現(xiàn)的還是同一個領(lǐng)域概念。因此該企業(yè)的情況是適合采用產(chǎn)品線開發(fā)方法的?！締栴}2】軟件產(chǎn)品線的建立需要希望使用軟件產(chǎn)品線方法的軟件組織有意識地、明顯地努力才有可能成功。軟件產(chǎn)品線的建立通常有四種方式。引入產(chǎn)品線開發(fā)過程采用的方式基于兩種考慮：演化方式（evolutionary）、革命方式（revolutionary），是基于現(xiàn)有產(chǎn)品還是開發(fā)全新的產(chǎn)品線。這四種方式基本特征如表1-2所示。下面對這幾種方式進行簡要分析。表1-2  建立軟件產(chǎn)品線的幾種方式（1）將現(xiàn)有產(chǎn)品

26、演化為產(chǎn)品線。在基于現(xiàn)有產(chǎn)品架構(gòu)設(shè)計的產(chǎn)品線架構(gòu)的基礎(chǔ)上，將特定產(chǎn)品的構(gòu)件逐步地、越來越多地轉(zhuǎn)化為產(chǎn)品線的共用構(gòu)件，從基于產(chǎn)品的方法“慢慢地”轉(zhuǎn)化為基于產(chǎn)品線的軟件開發(fā)。主要優(yōu)點是通過對投資回報周期的分解、對現(xiàn)有系統(tǒng)演化的維持使產(chǎn)品線方法的實施風險降到最小，但完成產(chǎn)品線核心資源的總周期和總投資都比使用革命方式要大。（2）用軟件產(chǎn)品線替代現(xiàn)有產(chǎn)品集?；就Ｖ宫F(xiàn)有產(chǎn)品的開發(fā)，所有努力直接針對軟件產(chǎn)品線的核心資源開發(fā)。遺留系統(tǒng)只有在符合架構(gòu)和構(gòu)件需求的情況下，才可以和新的構(gòu)件協(xié)作。這種方法的目標是開發(fā)一個不受現(xiàn)有產(chǎn)品集存在問題限制的、全新的平臺，總周期和總投資較演化方法要少，但因重要需求的變化導(dǎo)致的

27、初始投資報廢的風險加大。另外，基于核心資源的第一個產(chǎn)品面世的時間將會推后?，F(xiàn)有產(chǎn)品集中軟硬件結(jié)合的緊密程度，以及不同產(chǎn)品在硬件方面的需求的差異，也是產(chǎn)品線開發(fā)選擇采用演化還是革命方式的決策依據(jù)。對于軟硬件結(jié)合密切且硬件需求差異大的現(xiàn)有產(chǎn)品集因無法滿足產(chǎn)品線方法對軟硬件同步的需求，只能采用革命方式替代現(xiàn)有產(chǎn)品集。（3）全新軟件產(chǎn)品線的演化。當一個軟件組織進入一個全新的領(lǐng)域要開發(fā)該領(lǐng)域的一系列產(chǎn)品時，同樣也有演化和革命兩種方式。演化方式將每一個新產(chǎn)品的需求與產(chǎn)品線核心資源進行協(xié)調(diào)。好處是先期投資少，風險較小，第一個產(chǎn)品面世時間早。另外，因為是進入一個全新的領(lǐng)域，演化方法可以減少和簡化因經(jīng)驗不足造成

28、的初始階段錯誤的修正代價。缺點是已有的產(chǎn)品線核心資源會影響新產(chǎn)品的需求協(xié)調(diào)，使成本加大。（4）全新軟件產(chǎn)品線的開發(fā)。架構(gòu)設(shè)計師和工程師首先要得到產(chǎn)品線所有可能的需求，基于這個需求集來設(shè)計和開發(fā)產(chǎn)品線核心資源。第一個產(chǎn)品將在產(chǎn)品線核心資源全部完成之后才開始構(gòu)造。優(yōu)點是一旦產(chǎn)品線核心資源完成后，新產(chǎn)品的開發(fā)速度將非常快，總成本也將減少。缺點是對新領(lǐng)域的需求很難做到全面和正確，使得核心資源不能像預(yù)期的那樣支持新產(chǎn)品的開發(fā)。【問題3】從本質(zhì)上看，產(chǎn)品線開發(fā)包括核心資源庫的開發(fā)和使用核心資源的產(chǎn)品開發(fā)，這兩者都需要技術(shù)和組織的管理。核心資源的開發(fā)和產(chǎn)品開發(fā)可同時進行，也可交叉進行，例如，新產(chǎn)品的構(gòu)建以核

29、心資源庫為基礎(chǔ)，或者核心資源庫可從已存在的系統(tǒng)中抽取。有時，我們把核心資源庫的開發(fā)也稱為領(lǐng)域工程，把產(chǎn)品開發(fā)稱為應(yīng)用工程。圖1-1說明了產(chǎn)品線各基本活動之間的關(guān)系。每個旋轉(zhuǎn)環(huán)代表一個基本活動，三個環(huán)連接在一起，不停地運動著。三個基本活動交錯連接，可以以任何次序發(fā)生，且高度重疊。旋轉(zhuǎn)的箭頭表示不但核心資源庫被用來開發(fā)產(chǎn)品，而且已存在的核心資源的修訂甚至新的核心資源常?？梢詠碜援a(chǎn)品開發(fā)的過程。在核心資源和產(chǎn)品開發(fā)之間有一個強的反饋環(huán)，當新產(chǎn)品開發(fā)時，核心資源庫就得到刷新。對核心資源的使用反過來又會促進核心資源的開發(fā)活動。另外，核心資源的價值通過使用它們的產(chǎn)品開發(fā)來得到體現(xiàn)。產(chǎn)品線的開發(fā)包括資源開發(fā)

30、、產(chǎn)品計劃和產(chǎn)品開發(fā)幾個步驟，正如圖1-2所示，產(chǎn)品線分析是資源開發(fā)的一部分。圖1-1  產(chǎn)品線基本活動示意圖 圖1-2  產(chǎn)品線分析產(chǎn)品線分析是把對業(yè)務(wù)機遇的初步確認細化為需求模型，對正在開發(fā)的產(chǎn)品線，捕獲組織的業(yè)務(wù)目標和約束、包含在產(chǎn)品線中的產(chǎn)品、最終用戶和其他項目干系人的需求、大粒度重用的機會。分析能否為并行開發(fā)提供機會，對產(chǎn)品線開發(fā)來說是至關(guān)重要的。資源開發(fā)需要固定投資，特別是及時的投資，但產(chǎn)品線的成功卻往往取決于組織快速進入市場的能力。減少產(chǎn)品線進入市場時間的唯一途徑就是使資源開發(fā)并行進行。對產(chǎn)品線分析而言，這意味著要盡可能快地發(fā)現(xiàn)重大設(shè)計信息。因此，是

31、否進行了充分的產(chǎn)品線分析，對于軟件產(chǎn)品線的成功實施起著十分重要的作用。另外，要想有效地發(fā)揮軟件產(chǎn)品線的作用，還必須根據(jù)特定的情況選擇合適的過程模型（諸如雙生命周期模型、SEI模型、三生命周期模型），并根據(jù)其特點設(shè)立不同的部分和組織結(jié)構(gòu)來分別負責領(lǐng)域工程和應(yīng)用工程部分。二、參考答案【問題1】是否適合采用產(chǎn)品線開發(fā)方法關(guān)鍵在于企業(yè)是否存在擁有共性領(lǐng)域模型的產(chǎn)品集合。因為希賽公司的業(yè)務(wù)是在多平臺下開發(fā)一系列相關(guān)網(wǎng)絡(luò)安全防護軟件，因此適合采用產(chǎn)品線方法?！締栴}2】在原有的產(chǎn)品的基礎(chǔ)上建立軟件產(chǎn)品線主要有兩種方式。（1）演化方式：即將現(xiàn)有產(chǎn)品演化為產(chǎn)品線，也就是將特定產(chǎn)品的構(gòu)件逐漸轉(zhuǎn)化到產(chǎn)品線的共用構(gòu)件

32、。該方式分解了投資回報周期，最大程度地減少了實施產(chǎn)品線方法的風險，但完成軟件產(chǎn)品線核心資源的總周期和總投資都較大。（2）革命方式：即用軟件產(chǎn)品線替代現(xiàn)有產(chǎn)品集。這種方法將基本停止現(xiàn)有產(chǎn)品的開發(fā)，直接針對軟件產(chǎn)品線的核心資源開發(fā)。雖然該方法完成軟件產(chǎn)品線核心資源的總周期和總投資都會減少，但風險大大加大了。【問題3】（1）對該領(lǐng)域具備長期和深厚的經(jīng)驗。（2）一個用于構(gòu)建產(chǎn)品的好的核心資源庫。（3）好的產(chǎn)品線體系結(jié)構(gòu)。（4）好的管理（軟件資源、人員組織、過程）支持。1.1.3 2005年上半年試題42005年上半年試題4某軟件公司多年來開發(fā)的項目大都采用結(jié)構(gòu)化方法。但系統(tǒng)開發(fā)的實踐表明，盡管在許多情

33、況下使用了嚴格定義或預(yù)先說明的方法，但當系統(tǒng)建成以后，用戶仍然覺得建立的系統(tǒng)是不完全正確或不完備的，因此需要進行反復(fù)地修補。針對上述情況，公司的李總工程師提出，應(yīng)該引入原型法，以快速地確定用戶需求，提高開發(fā)過程中的生產(chǎn)率和最終系統(tǒng)的質(zhì)量。【問題1】請用400字以內(nèi)文字，分別論述原型法與嚴格定義法適用的場合?！締栴}2】原型生命周期提供了一種用原型法完成需求定義的完整方法。但對于一些特殊情況，如規(guī)模較小，完整性要求較弱的應(yīng)用，可以采取靈活的做法以適應(yīng)實際目標。請用300字以內(nèi)文字，說明改變原型生命周期約束的方法?！締栴}3】引入原型法后，需要對項目管理的過程加以適當修正。請用300字以內(nèi)文字，說明引

34、入原型法后，項目管理的基本內(nèi)容。一、試題分析【問題1】需求定義方法主要可以分為嚴格定義方法和原型化方法。嚴格定義（預(yù)先定義）是目前采用較多的一種需求定義方法。在采用嚴格定義的傳統(tǒng)的結(jié)構(gòu)化開發(fā)方法中，各個工作階段排列成一個理想的線性開發(fā)序列，在每一工作階段中，都用上一階段所提供的完整、嚴格的文檔作為指導(dǎo)文件。在傳統(tǒng)的結(jié)構(gòu)化開發(fā)中，需求的嚴格定義建立在以下的基本假設(shè)上：（1）所有需求都能夠被預(yù)先定義。（2）開發(fā)人員與用戶之間能夠準確而清晰地交流。（3）采用圖形模型/文字可以充分體現(xiàn)最終系統(tǒng)。（4）修改定義不完善的系統(tǒng)代價昂貴且實施困難。（5）嚴格方法的生命周期的各階段的劃分都是正確的。在使用嚴格定

35、義需求的開發(fā)過程中，開發(fā)人員與用戶之間交流、通信的主要工具是定義報告，包括敘述文字、圖形、邏輯規(guī)則和數(shù)據(jù)字典等技術(shù)工具。它們的一個共同特點，都是靜止的、被動的，不能實際表演，很難在用戶頭腦中形成一個具體的形象。因此，要用靜止的圖形/文字描述來體現(xiàn)一個動態(tài)的系統(tǒng)是比較困難的。除了所論述的情況外，上述基本假設(shè)還將導(dǎo)致嚴格定義的結(jié)構(gòu)化開發(fā)方法存在以下缺陷。首先是文檔量大，由于在結(jié)構(gòu)化方法的每個階段都必須寫出規(guī)范、嚴密的各種文檔，這些文檔雖然有助于開發(fā)人員之間、用戶與開發(fā)人員間的通信交流，有助于開發(fā)過程的規(guī)范化，但由于編寫文檔花費大量人力和時間，導(dǎo)致系統(tǒng)開發(fā)周期增長。其次是開發(fā)過程可見性差，來自用戶的

36、反饋太遲。由于在需求定義、系統(tǒng)設(shè)計階段都不能在用戶終端顯示新系統(tǒng)的實際效果，一直到系統(tǒng)實現(xiàn)階段結(jié)束，用戶才有機會通過對新系統(tǒng)的實際操作和體會，來提出他們對新系統(tǒng)的看法和意見，但此時整個開發(fā)已近尾聲，若想修改前幾段的工作或修改需求定義，都將付出較大的代價，有時這種修改甚至會導(dǎo)致整個系統(tǒng)的失敗。綜上所述，需求的嚴格定義的基本假設(shè)在許多情況下并不成立，傳統(tǒng)的結(jié)構(gòu)化方法面臨著一些難以跨越的障礙。為此，需要探求一種變通的方法。原型化方法以一種與嚴格定義法截然不同的觀點看待需求定義問題。原型化的需求定義過程是一個開發(fā)人員與用戶通力合作的反復(fù)過程。從一個能滿足用戶基本需求的原型系統(tǒng)開始，允許用戶在開發(fā)過程中

37、提出更好的要求，根據(jù)用戶的要求不斷地對系統(tǒng)進行完善，它實質(zhì)上是一種迭代的循環(huán)型的開發(fā)方式。需求定義的原型化方法基于以下假設(shè)：（1）并非所有的需求都能在系統(tǒng)開發(fā)前都被準確地說明。（2）項目參加者之間通常都存在交流上的困難，原型為克服該困難提供了一種手段。（3）需要實際的、可供用戶參與的系統(tǒng)模型。（4）有合適的系統(tǒng)開發(fā)環(huán)境和快速的系統(tǒng)建造工具。這些工具主要包括集成的數(shù)據(jù)字典、高適應(yīng)性的數(shù)據(jù)庫管理系統(tǒng)、非過程的報告書寫器、非過程查詢語言、屏幕生成器、超高級語言、自動文檔編排、原型人員工作臺。（5）反復(fù)是完全需要和值得提倡的，但需求一旦確定，就應(yīng)遵從嚴格的方法?！締栴}2】原型生命周期由10個步驟組成，

38、分別是合適的選擇、識別基本需求、開發(fā)工作模型、模型驗證修正和改進、判定原型完成、判別細部說明、嚴格說明細部、判定原型效果、整理原型和提供文檔。對于一些有特殊要求或特殊情況的應(yīng)用，如規(guī)模較小，完整性要求較弱的應(yīng)用，為了獲得較高的效益，可以采取靈活的做法，以適應(yīng)實際目標。原型生命周期意味著對自身的以下若干約束：（1）建立一個完整的模型。（2）原型人員要建立初始模型。（3）原型化要從定義階段開始。（4）實際系統(tǒng)將用自己的資源來建立。改變原型生命周期約束的方法有：（1）僅對屏幕的原型化。（2）使用購買的應(yīng)用系統(tǒng)作為初始模型。（3）子系統(tǒng)原型化。（4）原型與需求建議。（5）最終用戶進行原型化。【問題3】

39、原型化并不會改變整個項目實施和項目管理的有效性和合理性，只是做一些適當?shù)恼{(diào)整。所以，像所有開發(fā)方法一樣，原型化方法一也需要項目管理，因而需要對項目管理的傳統(tǒng)方式和過程加以適當?shù)男拚蛊浼扔徐`活性又有可靠性。項目管理包括估計過程、費用重新分配、變化控制以及活動停止。（1）估計過程。這是估計原型的時間、成本和系統(tǒng)目標的方法。原型法的成本估計就是指由項目管理所要求的實際系統(tǒng)的建立和修改成本的估計。首先，用戶為滿足其要求而支付的時間和設(shè)備，這些成本是顯而易見的，它取決于每次重復(fù)周期的進展狀況。其次，在原型被接受后，立即可以做出一個靜態(tài)的成本估計。（2）費用重新分配。在開發(fā)模型中所帶來的所有費用都要記

40、在用戶的賬單上，原型的整理也帶來了占用機器的費用。費用分配對控制重復(fù)周期是最有效的，因為重復(fù)會多花錢。（3）變化控制。由誰來決定原型的改變是一個復(fù)雜的問題。探索這一問題的最佳解決方案是，對項目管理機制來說，做一個交互式的控制板，一個小型設(shè)計組根據(jù)目前掌握的資料做出變化或不變化的決定。在原型化項目管理的四項內(nèi)容中，最為復(fù)雜的內(nèi)容就是變化控制。（4）活動停止。在傳統(tǒng)的定義討論中，用戶的活動停止是以敘述圖解模型為基礎(chǔ)的。在原型化環(huán)境中活動停止就相當于已允許原型作為理想的系統(tǒng)。二、參考答案【問題1】嚴格定義方法適用的場合：（1）所有的需求都能夠被預(yù)先定義。（2）修改定義不完備的系統(tǒng)代價昂貴且實施困難。

41、（3）項目參加者之間能夠清晰而準確地進行通信。（4）靜態(tài)描述或圖形模型對應(yīng)用系統(tǒng)的反映是充分的。（5）嚴格方法的生命周期中各階段劃分都是正確的。原型法適用的場合：（1）并非所有的需求在系統(tǒng)開發(fā)以前都能準確地說明。（2）有快速的系統(tǒng)建造工具。（3）項目參與者之間經(jīng)常存在通信上的障礙。（4）需要實際的、可供用戶參與的系統(tǒng)模型。（5）需求一旦確定就可以遵從嚴格定義的方法。（6）大量的反復(fù)是不可避免的、必要的，應(yīng)該加以鼓勵。【問題2】改變原型生命周期約束的方法：（1）僅對屏幕的原型化。（2）使用購買的應(yīng)用系統(tǒng)作為初始模型。（3）子系統(tǒng)原型化。（4）原型與需求建議。（5）最終用戶進行原型化。【問題3】引

42、入原型法后，項目管理的基本內(nèi)容：（1）估計過程。（2）費用重新分配。（3）變化控制。（4）活動停止。1.1.4  2006年上半年試題32006年上半年試題3張工和李工分別是某公司信息系統(tǒng)項目組和系統(tǒng)開發(fā)組的負責人。下面是張工與李工討論信息系統(tǒng)項目組承接的新項目時的對話。張工：我們這次承接的新系統(tǒng)很具有挑戰(zhàn)性，在開發(fā)過程中不僅要使用一種新的數(shù)據(jù)庫管理系統(tǒng)，用戶所給的開發(fā)時間也比較短。我擔心使用傳統(tǒng)的SDLC（軟件開發(fā)生存周期）方法可能無法按期完成系統(tǒng)開發(fā)任務(wù)。李工：這個項目有什么特點嗎？張工：我不知道用戶是否確切地明白他們想要一個怎樣的新系統(tǒng)。他們提出了許多要求，但是我不敢確定他們是

43、否真正理解這個新系統(tǒng)的功能。而且，這個系統(tǒng)可能會相當復(fù)雜，因為它要與多個已有的系統(tǒng)進行交互。李工：我希望我們有更多使用RAD（Rapid Application Development，快速應(yīng)用開發(fā)）方法的經(jīng)驗。目前你所面臨的狀況可能比較適合使用這種方法。張工：我同意。但是這個項目的時限不允許我們?nèi)W(xué)習運用RAD方法的工具，以及即將要使用的新的RDBMS（關(guān)系數(shù)據(jù)庫管理系統(tǒng)）?！締栴}1】用100字以內(nèi)文字，分析使張工放棄采用傳統(tǒng)的SDLC方法的原因?！締栴}2】用200字以內(nèi)文字，說明RAD方法的基本思想。【問題3】如果張工采用RAD方法開發(fā)該項目，應(yīng)如何解決對RAD工具不熟悉，以及使用新數(shù)據(jù)庫

44、管理系統(tǒng)的問題？用150字以內(nèi)文字說明。一、試題分析快速應(yīng)用開發(fā)（Rapid Application Development，RAD）是一種比傳統(tǒng)生命周期法快得多的開發(fā)方法，它強調(diào)極短的開發(fā)周期。RAD 模型是瀑布模型的一個高速變種，通過使用基于構(gòu)件的開發(fā)方法獲得快速開發(fā)。如果需求理解得很好，且約束了項目范圍，利用這種模型可以很快開發(fā)出功能完善的信息系統(tǒng)。1. RAD的基本思想RAD的基本思想體現(xiàn)在以下四個方面：（1）讓用戶更主動地參與到系統(tǒng)分析、設(shè)計和構(gòu)造活動中來。（2）將項目開發(fā)組織成一系列重點突出的研討會，研討會要讓項目投資方、用戶、系統(tǒng)分析師、設(shè)計人員和開發(fā)人員一起參與。（3）通過一種

45、迭代的構(gòu)造方法，加速需求分析和設(shè)計階段。（4）讓用戶提前看到一個可工作的系統(tǒng)。2. RAD的開發(fā)流程RAD的流程從業(yè)務(wù)建模開始，隨后是數(shù)據(jù)建模、過程建模、應(yīng)用生成、測試與交付。（1）業(yè)務(wù)建模。確定驅(qū)動業(yè)務(wù)過程運作的信息、要生成的信息、如何生成、信息流的去向及其處理等，可以使用數(shù)據(jù)流圖來幫助建立業(yè)務(wù)模型。（2）數(shù)據(jù)建模。為支持業(yè)務(wù)過程的數(shù)據(jù)流查找數(shù)據(jù)對象集合、定義數(shù)據(jù)對象屬性，并與其他數(shù)據(jù)對象的關(guān)系構(gòu)成數(shù)據(jù)模型，可以使用E-R圖來幫助建立數(shù)據(jù)模型。（3）處理建模。將數(shù)據(jù)對象變換為要完成一個業(yè)務(wù)功能所需的信息流，創(chuàng)建處理以描述增加、修改、刪除或獲取某個數(shù)據(jù)對象，即細化數(shù)據(jù)流圖中的加工。（4）應(yīng)用生

46、成。利用第四代語言（4GL）寫出處理程序，復(fù)用已有構(gòu)件或創(chuàng)建新的可復(fù)用構(gòu)件，利用環(huán)境提供的工具自動生成并構(gòu)造出整個應(yīng)用系統(tǒng)。（5）測試與交付。因為RAD強調(diào)復(fù)用，許多構(gòu)件已經(jīng)是測試過的，這就減少了測試的時間。由于大量復(fù)用，所以一般只做總體測試，但新創(chuàng)建的構(gòu)件還是要測試的。3. RAD的特點RAD采用基于構(gòu)件的開發(fā)方法，復(fù)用已有的程序結(jié)構(gòu)（如果可能的話）或使用構(gòu)件，或者創(chuàng)建可復(fù)用的構(gòu)件（如果需要的話）。在所有情況下，均可以使用CASE工具輔助進行軟件構(gòu)建。如果一個業(yè)務(wù)能夠被模塊化使得其中每一個主要功能均可以在不到三個月的時間內(nèi)完成，那么，它就是RAD的一個候選者。每個主要功能可由一個單獨的RAD

47、組來實現(xiàn)，最后再集成起來，形成一個整體。所有RAD方法的主要目標是通過用戶參與系統(tǒng)開發(fā)的每一個階段來縮減開發(fā)時間和費用。由于RAD是一個連續(xù)的過程，因此隨著設(shè)計的進行，RAD允許開發(fā)小組迅速地做出必要的修改。當公司預(yù)算緊張時，對于發(fā)生在一個已制定好的長時期的進度表中的變化所帶來的花費進行限制尤為重要。與傳統(tǒng)的結(jié)構(gòu)化分析方法相比，RAD的主要優(yōu)點如下：（1）強調(diào)用戶參與，可以盡快明確需求，降低系統(tǒng)開發(fā)風險，縮短系統(tǒng)開發(fā)周期。（2）通過大量使用可復(fù)用構(gòu)件，加快了開發(fā)速度。但是，RAD也具有以下局限性：（1）RAD強調(diào)系統(tǒng)本身的結(jié)構(gòu)，系統(tǒng)可能在短時間內(nèi)工作很好，但是系統(tǒng)的整體和長期的目標可能得不到滿

48、足。（2）加速開發(fā)周期可能會導(dǎo)致沒有更多的時間提高項目質(zhì)量、連貫性和設(shè)計的標準化。（3）并非所有應(yīng)用軟件都適合于使用RAD。如果一個系統(tǒng)難以模塊化，那么建造RAD所需構(gòu)件就會有問題；如果需要高性能的指標，且該指標必須通過調(diào)整接口使其適應(yīng)系統(tǒng)構(gòu)件才能獲得，使用RAD方法就有可能失敗；RAD不適合技術(shù)風險很高的情況，當一個新應(yīng)用要采用很多新技術(shù)或新軟件要求與已有計算機程序有較高的可互操作性時，項目也可能會失敗。二、參考答案【問題1】（1）開發(fā)時間成為制約軟件開發(fā)的重要因素。（2）不明確的用戶需求。（3）必須使用不熟悉的開發(fā)技術(shù)?！締栴}2】（1）讓用戶更主動地參與到項目分析、設(shè)計和構(gòu)造活動中來。（2

49、）將項目開發(fā)組織成一系列重點突出的研討會，研討會要讓項目投資方、用戶、分析員、設(shè)計人員和構(gòu)造人員一同參與。（3）通過一種迭代的構(gòu)造方法加速需求分析和設(shè)計階段。（4）讓用戶提前看到一個可工作的系統(tǒng)?！締栴}3】（1）張工應(yīng)盡可能在項目啟動之前對項目組的部分成員進行RAD工具和相關(guān)技術(shù)，以及采用新的RDBMS的培訓(xùn)。（2）可以聘請一個專業(yè)顧問來指導(dǎo)項目組使用RAD工具和相關(guān)技術(shù)。1.1.5 2008年上半年試題22008年上半年試題2當前企業(yè)中的業(yè)務(wù)都是在全球化、快速變化的環(huán)境中運營的，傳統(tǒng)的軟件開發(fā)過程無法適應(yīng)由此產(chǎn)生的快速軟件開發(fā)需求。20 世紀 90 年代后期，一些軟件開發(fā)人員在“Agile

50、Allicance  2001”中系統(tǒng)地闡述了敏捷開發(fā)的原則，試圖強調(diào)靈活性在快速且有效地生產(chǎn)軟件中所發(fā)揮的作用。目前，眾多的軟件生產(chǎn)企業(yè)已經(jīng)在實際的軟件開發(fā)過程中接納并實踐了敏捷開發(fā)方法中的基本原則。 【問題1】 敏捷開發(fā)有許多典型方法，包括極限編程（eXtreme Programming）、Scrum、Crystal、DSDM等。請問這些方法共同的基本原則是什么？ 【問題2】 敏捷開發(fā)的支持者往往夸大該方法的優(yōu)點，但是在實踐中，敏捷方法的基本原則有時確實很難實施。請用200字以內(nèi)的文字說明敏捷方法中哪些原則在實踐中難以實施。 【問

51、題3】 敏捷開發(fā)方法中最有名的是極限編程。請說明極限編程中的結(jié)對編程（Pair Programming）的概念。 【問題4】敏捷開發(fā)方法在具體實踐過程中，往往需要開發(fā)環(huán)境或工具的支持，一般稱為快速應(yīng)用開發(fā)技術(shù)和可視化開發(fā)技術(shù)。請用150字以內(nèi)的文字說明快速應(yīng)用開發(fā)技術(shù)所包含的工具有哪些，并簡要說明可視化開發(fā)技術(shù)的基本概念和技術(shù)原理。 一、試題分析這是一道關(guān)于敏捷開發(fā)方法（主要是XP方法）的問答題，共4個問題。在系統(tǒng)分析師考試指定參考用書系統(tǒng)分析師技術(shù)指南（張友生、王勇主編，清華大學(xué)出版社）中，詳細介紹了敏捷開發(fā)方法和XP方法?！締栴}1】注重個體與交互，重點關(guān)注可以

52、工作的軟件，提高客戶參與度，以積極的心態(tài)響應(yīng)變化是敏捷方法論的核心價值觀。為了貫徹這四大價值觀，敏捷聯(lián)盟提出12條區(qū)別于重量級過程的原則。（1）盡早、持續(xù)交付有價值的中間軟件使客戶滿意。很多開發(fā)組織經(jīng)常會在時間期限上進行沒有原則地退讓，其結(jié)果卻是讓客戶一等再等，不僅沒有按承諾兌現(xiàn)，甚至是時間超過一倍，但仍然不見軟件的蹤跡。這種不守信的狀態(tài)，使得整個軟件業(yè)走入了一個負螺旋發(fā)展。敏捷方法論提出了一種新的邏輯，將盡早、持續(xù)地交付可運行的中間成果，有價值的中間結(jié)果，使得客戶能夠盡早地、持續(xù)地了解到軟件開發(fā)的進展，并且將需求的變化、系統(tǒng)的改進意見盡早地提出來，這會使得客戶的滿意度大大提高。（2）即使到了

53、開發(fā)后期，也歡迎需求變化，利用響應(yīng)變化創(chuàng)造競爭優(yōu)勢。敏捷方法論鼓勵團隊擁抱變化，通過應(yīng)用各種技術(shù)來提高軟件結(jié)構(gòu)的靈活性，本著簡單的原則進行設(shè)計，以響應(yīng)變化的能力作為團隊的核心競爭力。（3）經(jīng)常交付可工作的軟件，間隔時間可以是幾周到幾個月，間隔越短越好。由于敏捷方法論奉行“客戶合作”、“客戶參與”，而要讓客戶更加有效的參與，經(jīng)常性、頻繁地交付可工作的中間軟件，將可以有效地加強開發(fā)人員與客戶之間的溝通，從而將隱藏的需求變化及早觸動。（4）開發(fā)全過程，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。在開發(fā)中，不僅需要客戶參與開發(fā)，還應(yīng)該包括代表客戶的業(yè)務(wù)人員。因此在開發(fā)人員、客戶、業(yè)務(wù)人員等相關(guān)干系人之間建

54、立頻繁而且密切的交流與溝通，將是使項目保持高度靈活性的關(guān)鍵。（5）為開發(fā)人員提供環(huán)境和支持，給予信任，以人為本地構(gòu)建項目。敏捷方法論是崇尚“以人為本”精神的，認為項目成功的最關(guān)鍵因素是人，其意義超過過程和工具。建立一支優(yōu)秀的團隊，并在環(huán)境與精神上提供支持，給予信任，將是項目成功的關(guān)鍵。這也是與傳統(tǒng)的“過程”為主的管理思想的最大不同。（6）團隊內(nèi)部，最有效的溝通方式莫過于面對面的交談。在重量級方法論中，人們嘗試著通過編寫規(guī)范、精美的文檔進行交流。而在敏捷方法論中則更加重視的是開發(fā)團隊成員之間的面對面交談，大家坐在一起，用一塊白板，或是一張紙，一邊繪制草圖，一邊交談，這是最有效的溝通方式。（7）工

55、作的軟件是度量進度的最首要標準。要衡量工作進度，采用的基點不是文檔的完成情況，不是已完成的代碼行數(shù)，而是可以工作的軟件完成了多少功能、實現(xiàn)了多少用例。這是敏捷方法論的共同點，因為只有可工作的軟件才是有價值的。（8）提倡可持續(xù)的開發(fā)速度，責任人、開發(fā)者和用戶應(yīng)保持一個長期的、恒定的開發(fā)速度。軟件開發(fā)絕不是短跑，它更像一場挑戰(zhàn)耐力的馬拉松長跑。因此，過早的沖刺、在前期過度的工作，將不利于項目按照持續(xù)的開發(fā)速度進行下去。因此，敏捷方法論反對加班，因為這樣的行為會使得團隊的精力過早耗盡，過早地對項目失去興趣和信心，從而得到事與愿違的結(jié)果。（9）不斷關(guān)注好的技能和設(shè)計會增加敏捷能力。保持軟件高質(zhì)量、簡潔

56、、健壯，是實現(xiàn)快速軟件開發(fā)的重要途徑。因此只有大家都致力于編寫高質(zhì)量的代碼、不創(chuàng)造混亂，才能夠提升敏捷能力。（10）開發(fā)者本質(zhì)是簡單的使未完成的工作最大化的藝術(shù)。不管明天的需求，只采用符合今天需求的簡單設(shè)計。因為誰也不知道明天是怎么樣的？變化太快了，今天的設(shè)計考慮太多明天的需求，就有可能做了過多的無用功。（11）自組織的團隊才能夠做出最好的架構(gòu)設(shè)計和需求分析。最優(yōu)秀的團隊不是被強權(quán)管理下的團隊，而是形成了一個良好的協(xié)作，能夠內(nèi)部進行任務(wù)分解、協(xié)調(diào)的團隊。（12）團隊應(yīng)定期在如何更有效工作方面進行反省，然后對自己的行為做出改進。不斷地回顧、總結(jié)，并從中找到團隊未能最有效工作的瓶頸點和問題點，并且

57、通過細致的分析與討論，找到其要點，并做出相應(yīng)的改進是十分重要的。【問題2】問題2問敏捷方法的原則中哪些原則在實踐中難以實施，這與問題1是相關(guān)聯(lián)的。只要理解了這些基本原則，這個問題就好解答。因為問的是在“實踐中難以實施”，所以這個問題可以答得靈活些，只要說得有道理都可以得分?！締栴}3】問題3考查結(jié)對編程的概念，簡單地說，結(jié)對編程就是2個人坐在一起寫同一個程序。結(jié)對編程可以大大降低溝通成本，提高工作質(zhì)量?！締栴}4】問題4是關(guān)于快速開發(fā)工具和可視化開發(fā)的?？焖賾?yīng)用開發(fā)（RAD）目的是快速發(fā)布系統(tǒng)，RAD組合了5個方面的技術(shù)，分別是進化原型、CASE工具（可進行正向工程和反向工程）、擁有能使用先進工具

58、的專門人員（一個RAD開發(fā)小組）、交互式JAD、時間表。例如，VB、Delphi、PB等都屬于RAD工具?？梢暬_發(fā)就是在可視開發(fā)工具（例如，VB、Delphi、PB等）提供的圖形用戶界面上，通過操作界面元素（例如，菜單、按鈕等），由可視開發(fā)工具自動生成應(yīng)用軟件。這類應(yīng)用軟件的工作方式是事件驅(qū)動的。對每個事件，由系統(tǒng)產(chǎn)生相應(yīng)的消息，再傳遞給相應(yīng)的消息響應(yīng)函數(shù)。二、參考答案【問題1】（1）客戶參與。（2）增量式移交。（3）開發(fā)團隊的技術(shù)應(yīng)該得到承認和發(fā)揚。團隊成員應(yīng)該保持他們自己的工作風格，不落俗套。（4）接受變更。（5）保持簡單性。【問題2】（1）客戶的參與度往往依賴于客戶參與的意愿和客戶自身的代表性。 （2）團隊成員的性格可能不適合激烈的投入，可能無法做到與其他成員之間的良好溝通。（3）對系統(tǒng)中的變更作出優(yōu)先級排序可能是極端困難的。  （4）維護系統(tǒng)的簡潔性往往需要額外的工作，但迫于移交時間表的壓力