軟件開(kāi)發(fā)外文翻譯

1、<p>　　Requirements Phase</p><p>　　The chances of a product being developed on time and within budget are somewhat slim unless the members of the software development team agree on what the software prod

2、uct will do. The first step in achieving this unanimity is to analyze the client’s current situation as precisely as possible. For example, it is inadequate to say, “ They need a computer-aided design system because they

3、 claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong wit</p><p>　　A commonly held misconception is that , during the requirements phase, the developers

4、 must determine what software the client wants. On the contrary, the real objective of the requirements phase is to determine what software the client needs. The problem is that many clients do not know what they need. F

5、urthermore, even a client who has a good idea of what is needed may have difficulty in accurately conveying these ideas to the developers, because most clients are less computer literate than the</p><p>　　To

6、 elicit the client’s needs, the members of the requirements team must be familiar with the application domain, that is, the general area in which the proposed software product is to be used. For example, it is not easy t

7、o ask meaningful questions of a banker or a nurse without first acquiring some familiarity with banking or nursing. Therefore, one of the initial tasks of each member of the requirements analysis team is to acquire famil

8、iarity with the application domain unless he or she alread</p><p>　　One way to solve the problem with terminology is to build a glossary. The initial entries are inserted while the team learns the applicatio

9、n domain. Then the glossary is updated whenever the members of the requirements team encounter new terminology. Not only does such a glossary reduce confusion between client and developers, it also is useful in lessening

10、 misunderstandings between members of the development team.</p><p>　　Once the requirements team have acquired familiarity with the domain, the next step is for them to start to determine the client’s needs,

11、that is, requirements elicitation. Elicitation technique as follows: </p><p>　　1. Interviews.</p><p>　　The members of the requirements team meet with members of the client organization until the

12、y are convinced that they have elicited all relevant information from the client and future users of the product. There are two basic types of interview, structured and unstructured. In a structured interview, specific,

13、preplanned, close-ended questions are posed. In an unstructured interview, open-ended questions are asked, to encourage the person being interviewed to speak out. Some of these facts might </p><p>　　Conducti

14、ng a good interview is not always easy. First, the interviewer must be familiar with the application domain. Second, there is no point in interviewing a member of the client organization if the interviewer already has ma

15、de up his or her mind regarding the client’s needs. No matter what he or she previously has been told or learned by other means, the interviewer must approach every interview with the intention of listening carefully to

16、what the person being interviewed has to say while f</p><p>　　2. Scenarios.</p><p>　　A scenario is a way a user might utilize the target product to accomplish some objective. A scenario can be d

17、epicted in a number of ways. One technique is simply to list the actions comprising the scenario .Another technique is to set up a storyboard, a series of diagrams depicting the sequence of events.</p><p>　　

18、They can demonstrate the behavior of the product in a way that is comprehensible to the user. This can result in additional requirements coming to light, as in the weight-loss planner example. Because scenarios can be un

19、derstood by users, the utilization of scenarios can ensure that the client and users play an active role throughout the requirements analysis process. After all, the aim of the requirements analysis phase is to elicit th

20、e real needs of the client, and the only source of this info</p><p>　　3. To send a questionnaire to the relevant members of the client organization.</p><p>　　This technique is useful when the op

21、inions of, say, hundreds of individuals need to be determined. Furthermore, a carefully thought-out written answer may be more accurate than an immediate verbal response to a question posed by an interviewer. However, an

22、 unstructured interview conducted by a methodical interviewer who listens carefully and poses questions that expand on initial responses usually yields far better information than a thoughtfully worded questionnaire. Bec

23、ause questionnaires are </p><p>　　4. To examine the various forms used by the client.</p><p>　　For example, a form in a print shop might reflect press number, paper roll size, humidity, ink temp

24、erature, paper tension, and so on. The various fields in this form shed light on the flow of print jobs and the relative importance of the steps in the printing process. Other documents, such as operating procedures and

25、job descriptions, also can be powerful tools for finding out exactly what is done and how. Such comprehensive information regarding how the client currently does business can be ext</p><p>　　5. To set up vid

26、eotape cameras within the workplace to record (with the prior written permission of those being observed) exactly what is being done.</p><p>　　One difficulty of this technique is that it can take a long time

27、 to analyze the tapes. In general, one or more members of the requirements analysis team has to spend an hour playing back the tape for every hour that the cameras record. This time is in addition to what is needed to as

28、sess what was observed. More seriously, this technique has been known to backfire badly because employees may view the cameras as an unwarranted invasion of privacy. It is important that the requirements analysis tea<

29、/p><p>　　An initial set of requirements has been elicited, the next step is to refine them, a process called requirements analysis. The members of the requirements team discuss the list of requirements with the

30、 various individuals interviewed to determine if anything has been omitted. Then, because the most accurate and powerful requirements analysis technique is rapid prototyping, a rapid prototype is built.</p><p&

31、gt;　　A rapid prototype is hastily built software that exhibits the key functionality of the target product. The client and intended users of the product now experiment with the rapid prototype, while members of the devel

32、opment team watch and take notes. Based on their hands-on experience, users tell the developers how the rapid prototype satisfies their needs and, more important, identify the areas that need improvement. The developers

33、change the rapid prototype until both sides are convinced that th</p><p>　　An important aspect of the rapid prototyping model is embodied in the word rapid. The whole idea is to build the prototype as quickl

34、y as possible. After all, the purpose of the rapid prototype is to provide the client with an understanding of the product, and the sooner, the better. It does not matter if the rapid prototype hardly works, if it crashe

35、s every few minutes, or if the screen layouts are less than perfect. The purpose of the rapid prototype is to enable the client and the developers t</p><p>　　One difficulty with rapid prototyping is that the

36、 ease with which changes generally can be made to a rapid prototype may encourage the client to request all sorts of major changes to the delivered operational-quality version of the product. Furthermore, the client may

37、expect the changes to be implemented as rapidly as changes to the rapid prototype. A related challenge is having to explain to the client that the rapid prototype is not of operational quality and the client will have to

38、 wait for t</p><p>　　As with the introduction of any new technology, before an organization introduces the rapid prototyping model it is vital that management be aware of the advantages and disadvantages of

39、rapid prototyping. In all fairness, although the case for rapid prototyping is strong, it has not yet been proven beyond all doubt.</p><p>　　Testing during the requirements phase</p><p>　　Althou

40、gh the aim of the requirements phase is to establish the client’s real needs, usually the client will not be the primary user of the target product. It therefore is essential to give the users the opportunity to experime

41、nt with the rapid prototype and suggest changes that, when approved by the client, will be implemented in the delivered version of the software product.</p><p>　　Therefore, the role of the software quality a

42、ssurance group during the rapid prototyping phase is to ensure that the relevant individuals in the client organization have the opportunity to interact with the rapid prototype and their suggestions actually reach the c

43、lient or, perhaps, a committee of client managers responsible for analyzing the suggestions of the users.</p><p>　　Form the viewpoint of testing during the phases that are to come, it is essential that the r

44、equirements be traceable. To achieve this, the statements of the requirements need to be numbered to enable the SQA to trace them through the subsequent phases. The numbering should appear in the rapid prototype in the f

45、orm of comments adjacent to the group of statements that implements each item in the requirements.</p><p><b>　　外文翻譯</b></p><p><b>　　需求階段</b></p><p>　　將一個(gè)軟件產(chǎn)品

46、及時(shí)而又不超出預(yù)算地開(kāi)發(fā)出來(lái)的機(jī)會(huì)有時(shí)是很小的，除非軟件開(kāi)發(fā)小組的成員對(duì)軟件產(chǎn)品將做什么都一致理解。要達(dá)到這種全體一致首先是盡可能精確地分析客戶當(dāng)前的狀態(tài)形勢(shì)，例如，這樣說(shuō)是不合適的：“因?yàn)樗麄儽г顾麄兊娜斯ぴO(shè)計(jì)系統(tǒng)很糟，所以他們需要一個(gè)計(jì)算機(jī)輔助設(shè)計(jì)系統(tǒng)?！背擒浖_(kāi)發(fā)小組明確地知道當(dāng)前人工系統(tǒng)有什么問(wèn)題，否則，很有可能新的計(jì)算機(jī)系統(tǒng)將會(huì)在許多方面一樣地糟。同樣，如果一個(gè)個(gè)人計(jì)算機(jī)制造商正打算開(kāi)發(fā)一個(gè)新的操作系統(tǒng)，第一步是評(píng)價(jià)企業(yè)單前

47、的操作系統(tǒng)，并認(rèn)真準(zhǔn)確地分析為什么它不能令人滿意?；蛘咴摬僮飨到y(tǒng)的用戶是否完全不認(rèn)同它的功能和可靠性？?jī)H當(dāng)對(duì)于當(dāng)前情形有了一個(gè)清晰的認(rèn)識(shí)之后，軟件開(kāi)發(fā)小組才能夠試圖回答關(guān)鍵的問(wèn)題，即新的軟件產(chǎn)品必須能夠做什么？回答這個(gè)問(wèn)題的過(guò)程在需求分析階段完成。</p><p>　　人們通常持有的一個(gè)錯(cuò)誤概念是，在需求分析階段，開(kāi)發(fā)者必須客戶想要什么樣的軟件。與此相反，需求分析階段真正的目標(biāo)是確定客戶需要什么樣的軟件。問(wèn)題在于

48、許多客戶不知道他們需要什么，更進(jìn)一步說(shuō)，即使一個(gè)客戶對(duì)什么是他們所需要的有一個(gè)好的想法，他也可能難于準(zhǔn)確地將這些想法傳達(dá)給開(kāi)發(fā)者，因?yàn)榇蠖鄶?shù)客戶的計(jì)算機(jī)知識(shí)比起軟件開(kāi)發(fā)小組成員來(lái)講要少得多。</p><p>　　為了獲取客戶的要求，需求小組的成員必須熟悉應(yīng)用領(lǐng)域，即提議中的軟件產(chǎn)品通常要在哪些領(lǐng)域使用。例如，如果沒(méi)有首先對(duì)銀行業(yè)或護(hù)理專(zhuān)業(yè)有某種程度的熟悉，就不太容易向一個(gè)銀行家或護(hù)士問(wèn)出有意義的問(wèn)題。因此，每個(gè)需

49、求小組成員最初的任務(wù)之一就是熟悉應(yīng)用領(lǐng)域，除非他或她已經(jīng)在那個(gè)領(lǐng)域有過(guò)一些經(jīng)歷。當(dāng)與客戶和目標(biāo)軟件的可能用戶交流時(shí)，特別重要的一點(diǎn)是使用正確的術(shù)語(yǔ)。畢竟，這一點(diǎn)很難引起工作在某一特定領(lǐng)域的人的重視，除非訪談?wù)呤褂眠m于該領(lǐng)域的術(shù)語(yǔ)。更重要的是，使用一個(gè)不合適的術(shù)語(yǔ)可能會(huì)導(dǎo)致曲解，甚至?xí)斐砂l(fā)行一個(gè)有錯(cuò)誤的軟件產(chǎn)品的結(jié)果。如果需求小組成員不理解該領(lǐng)域術(shù)語(yǔ)的細(xì)微差別，可能會(huì)產(chǎn)生同樣的問(wèn)題。</p><p>　　解決術(shù)語(yǔ)

50、問(wèn)題的一個(gè)辦法是建立術(shù)語(yǔ)表，當(dāng)需求分析小組成員開(kāi)始學(xué)習(xí)應(yīng)用領(lǐng)域知識(shí)時(shí)，將初始的詞條插入到術(shù)語(yǔ)表中，然后，每當(dāng)需求分析小組成員遇到新的術(shù)語(yǔ)時(shí)就更新該術(shù)語(yǔ)表。這樣的術(shù)語(yǔ)表不僅減少了客戶和軟件開(kāi)發(fā)者之間的誤解，而且在減輕開(kāi)發(fā)小組成員之間的誤解方面也是很有用的。</p><p>　　一旦需求分析小組成員熟悉了該應(yīng)用領(lǐng)域之后，下一步就是由他們來(lái)開(kāi)始確定客戶的要求，即進(jìn)行需求獲取。需求獲取技術(shù)如下：</p>&

51、lt;p><b>　　訪談。</b></p><p>　　需求小組成員會(huì)見(jiàn)客戶組織的成員，直到他們確信已經(jīng)從客戶和該產(chǎn)品未來(lái)的用戶處獲取了所有相關(guān)信息。有兩種基本的訪談?lì)愋?，程式（structured）和非程式化的（unstructured）。在一個(gè)程式化的訪談中，提出特定的、預(yù)先計(jì)劃好的、受限回答的（close-ended）問(wèn)題。在一個(gè)非程式化的訪談中，會(huì)提出可自由回答的（open-

52、ended）問(wèn)題，以便鼓勵(lì)受訪人暢所欲言。要是訪談過(guò)于程式化了，有些事實(shí)可能就發(fā)現(xiàn)不了。與此同時(shí)，如果訪談太過(guò)于非程式化，這也不是一個(gè)好注意。因此，應(yīng)當(dāng)以一種這樣的方式提出問(wèn)題：他能夠鼓勵(lì)受訪者給出范圍廣泛的回答，但該回答又不要超出訪談?wù)咚栊畔⒌姆秶?lt;/p><p>　　進(jìn)行一個(gè)好的訪談?dòng)袝r(shí)并不容易。首先，訪談?wù)弑仨毷煜?yīng)用領(lǐng)域；其二，如果訪談?wù)咭呀?jīng)決意尊重客戶需求的話，訪談客戶組織的成員時(shí)是沒(méi)有訪談要點(diǎn)的。

53、不管他或她先前被告知什么或通過(guò)其他方式了解過(guò)什么，訪談?wù)弑仨殠еJ(rèn)真傾聽(tīng)受訪者的目的著手開(kāi)始每一次訪談，與此同時(shí)，堅(jiān)決地克制任何預(yù)先固有的成見(jiàn)，尊重客戶公司的意見(jiàn)或客戶的要求以及要構(gòu)建的產(chǎn)品的潛在用途。</p><p><b>　　情景。</b></p><p>　　一個(gè)情景是用戶可能利用目標(biāo)產(chǎn)品完成某些目的的一種方式。可以用多中方式描述情景。一種技術(shù)是簡(jiǎn)單地列出組成

54、情景的行為。另一種技術(shù)是建立情景板（story board），它是描述事件序列的一系列圖表。</p><p>　　它們能夠以一種用戶可以理解的方式說(shuō)明軟件產(chǎn)品的行為，這會(huì)促使發(fā)現(xiàn)額外的需求。因?yàn)榍榫澳軌虮挥脩羲斫?，情景的使用可以確?？蛻艉陀脩粼谡麄€(gè)需求分析過(guò)程中自始至終發(fā)揮積極作用。畢竟，需求分析階段的目標(biāo)是獲取用戶的真正要求，并且信息的惟一來(lái)源是客戶和用戶。情景（或更精確地說(shuō)是用例（user case））在面

55、向?qū)ο蟮姆治鲋邪l(fā)揮著重要作用。</p><p>　　向相關(guān)的客戶組織成員發(fā)放問(wèn)卷調(diào)查表(questionnaire)。</p><p>　　這個(gè)技術(shù)在需要考慮比如說(shuō)幾百個(gè)個(gè)體的需求意見(jiàn)時(shí)很有用。進(jìn)一步說(shuō)，一個(gè)經(jīng)過(guò)認(rèn)真思考的書(shū)面答案可能比一個(gè)隨口而出的口頭回答更準(zhǔn)確。然而，有一個(gè)很有辦法的訪談人進(jìn)行的非程式化的訪談，由于他能夠認(rèn)真傾聽(tīng)受訪者的意見(jiàn)并提出進(jìn)一步的問(wèn)題，從而將起初得到的響應(yīng)大大擴(kuò)

56、展了，這樣的比一個(gè)經(jīng)過(guò)深思熟慮的紙面上的問(wèn)卷調(diào)查表通常揭示出更多的信息。因?yàn)閱?wèn)卷調(diào)查表是預(yù)先計(jì)劃好的，所以就沒(méi)有辦法根據(jù)某一個(gè)回答再提出一個(gè)問(wèn)題。</p><p>　　檢查客戶所使用的各種表格(form)。</p><p>　　例如，印刷廠的一張表格可能反映了印刷號(hào)、紙張軋壓尺寸、濕度、油墨溫度、紙張張力等等。這個(gè)表格中的各種域顯示了印刷工作的流程以及印刷過(guò)程，它也可以是準(zhǔn)確找出“已做了什

57、么”和“是如何做的”等的強(qiáng)有力工具。這些輔助理解的信息關(guān)心的是客戶眼下是如何從業(yè)的，它在決定客戶需求方面是特別有用的。因此，認(rèn)真研讀客戶文檔絕不應(yīng)當(dāng)僅僅被小看為一個(gè)信息源，它能夠?qū)е聹?zhǔn)確地把握客戶的要求。</p><p>　　5.在公共場(chǎng)所內(nèi)設(shè)立攝象機(jī)以準(zhǔn)確地錄下（當(dāng)然事先要得到被觀察方的書(shū)面許可）正在做的事情。</p><p>　　這項(xiàng)技術(shù)的難點(diǎn)之一是它可能花費(fèi)很長(zhǎng)時(shí)間去分析錄像帶。通常

58、，需求分析小組的一個(gè)或多個(gè)成員需要花上一個(gè)小時(shí)回放錄像機(jī)錄下的每個(gè)小時(shí)的磁帶。這個(gè)時(shí)間對(duì)于評(píng)估所觀察到的東西而言是額外增加的，更嚴(yán)重的是，這一技術(shù)據(jù)說(shuō)已經(jīng)產(chǎn)生了嚴(yán)重的適得其反的結(jié)果，因?yàn)楣蛦T可能將攝像機(jī)看做是對(duì)他們個(gè)人隱私的一種不當(dāng)?shù)娜肭?。重要的是需求分析小組要與雇員進(jìn)行全面的合作，如果人們感到受威脅或受打擾，他們就很難獲得必要的信息。在引入攝像機(jī)或者采用任何其他有可能激怒雇員的行動(dòng)前，可能的危險(xiǎn)必須仔細(xì)考慮到。 </p>

59、;<p>　　獲取了最初的一系列需求之后，下一步就是提煉它們，這是一個(gè)稱(chēng)為需求分析(requirements analysis)的過(guò)程。需求小組成員與各個(gè)受訪者討論需求清單，決定是否忽略了什么；然后因?yàn)樽罹_和有力的需求分析技術(shù)是快速原型開(kāi)發(fā)，因此，要建立快速原型。</p><p>　　快速原型是倉(cāng)促建立的軟件，該軟件展示了目標(biāo)軟件產(chǎn)品的主要功能?？蛻艉驮摦a(chǎn)品預(yù)定的用戶對(duì)快速原型進(jìn)行實(shí)驗(yàn)的同時(shí)，開(kāi)發(fā)

60、小組成員觀察并做記錄。根據(jù)他們豐富的實(shí)踐經(jīng)驗(yàn)，用戶告訴開(kāi)發(fā)人員快速原型是否能夠滿足他們的要求，而且更重要的是，指出需改進(jìn)的地方。隨后，開(kāi)發(fā)人員改進(jìn)快速原型，直至雙方確認(rèn)客戶的要求已準(zhǔn)確地包含在快速原型中，然后快速原型就作為擬訂規(guī)格說(shuō)明的基礎(chǔ)。</p><p>　　快速原型開(kāi)發(fā)模型的一個(gè)重要方面包含在”快速”一詞中，全部的要旨是盡可能快速地建立原型。說(shuō)到底，快速原型的目的是向客戶提供對(duì)軟件產(chǎn)品的理解，并且是盡可能快

61、、盡可能好的理解。如果快速原型難以工作，如果它每隔幾分鐘就崩潰，或者如果屏幕布局不很完美，這些都不要緊?？焖僭偷囊鈭D是使客戶和開(kāi)發(fā)者能夠在該產(chǎn)品做哪些事情方面盡可能快速地達(dá)成一致意見(jiàn)，因此，快速原型中的任何不完美之處都可以忽略不計(jì)，前提是它們沒(méi)有嚴(yán)重?fù)p害快速原型的功能并讓人對(duì)產(chǎn)品的行為產(chǎn)生誤解。</p><p>　　快速原型開(kāi)發(fā)的一個(gè)困難是，快速原型改變起來(lái)的容易性可能鼓勵(lì)客戶要求對(duì)所交付產(chǎn)品的工作級(jí)版本做各種

62、主要的改變。進(jìn)一步地，客戶可能期望實(shí)現(xiàn)的改變盡可能與對(duì)快速原型的改變一樣快。有關(guān)的問(wèn)題是不得不向客戶結(jié)實(shí)快速原型不具有工作質(zhì)量，客戶將要等待具有工作質(zhì)量的版本，即使快速原型看起來(lái)做了要求做的每件事。在使用快速原型開(kāi)發(fā)之前，負(fù)責(zé)開(kāi)發(fā)該產(chǎn)品的管理者與客戶討論這些相關(guān)問(wèn)題是必須的。</p><p>　　至于新技術(shù)的引入，在一個(gè)組織提議使用快速原型開(kāi)發(fā)模型前，至關(guān)重要的是管理者要意識(shí)到快速原型開(kāi)發(fā)的優(yōu)缺點(diǎn)。公平地說(shuō)，盡管

63、快速原型開(kāi)發(fā)的事例強(qiáng)有說(shuō)服力，但還沒(méi)有證明他是無(wú)懈可擊的。</p><p><b>　　需求分析階段測(cè)試</b></p><p>　　盡管需求分析階段的目標(biāo)是確定客戶的真正要求，通?？蛻舨皇窃撃繕?biāo)產(chǎn)品的最終用戶，于是有必要給用戶試驗(yàn)快速原型并提出改進(jìn)建議的機(jī)會(huì)，在征得客戶同意后，在軟件產(chǎn)品的交付版本中完成這種改變。</p><p>　　因此，在

64、快速原型開(kāi)發(fā)階段，軟件質(zhì)量保證小組的任務(wù)是確?？蛻艚M織中的有關(guān)人員有機(jī)會(huì)與快速原型交互，并且保證讓他們的建議確實(shí)送達(dá)負(fù)責(zé)分析用戶建議的客戶(也可能是一個(gè)客戶管理者委員會(huì))。</p><p>　　在將要到來(lái)的那個(gè)階段，從測(cè)試的觀點(diǎn)來(lái)看需求是可跟蹤的，這一點(diǎn)非常重要。要達(dá)到這個(gè)要求，應(yīng)當(dāng)將需求的說(shuō)明編號(hào)，從而使SQL能夠在隨后的階段中跟蹤它們。在快速原型中，編號(hào)應(yīng)當(dāng)以注釋的形式在需求中每一組說(shuō)明之后出現(xiàn)。</p