軟件開發(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>　　將一個軟件產品

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

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

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

49、求小組成員最初的任務之一就是熟悉應用領域，除非他或她已經在那個領域有過一些經歷。當與客戶和目標軟件的可能用戶交流時，特別重要的一點是使用正確的術語。畢竟，這一點很難引起工作在某一特定領域的人的重視，除非訪談者使用適于該領域的術語。更重要的是，使用一個不合適的術語可能會導致曲解，甚至會造成發(fā)行一個有錯誤的軟件產品的結果。如果需求小組成員不理解該領域術語的細微差別，可能會產生同樣的問題。</p><p>　　解決術語

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

51、lt;p><b>　　訪談。</b></p><p>　　需求小組成員會見客戶組織的成員，直到他們確信已經從客戶和該產品未來的用戶處獲取了所有相關信息。有兩種基本的訪談類型，程式（structured）和非程式化的（unstructured）。在一個程式化的訪談中，提出特定的、預先計劃好的、受限回答的（close-ended）問題。在一個非程式化的訪談中，會提出可自由回答的（open-

52、ended）問題，以便鼓勵受訪人暢所欲言。要是訪談過于程式化了，有些事實可能就發(fā)現(xiàn)不了。與此同時，如果訪談太過于非程式化，這也不是一個好注意。因此，應當以一種這樣的方式提出問題：他能夠鼓勵受訪者給出范圍廣泛的回答，但該回答又不要超出訪談者所需信息的范圍。</p><p>　　進行一個好的訪談有時并不容易。首先，訪談者必須熟悉應用領域；其二，如果訪談者已經決意尊重客戶需求的話，訪談客戶組織的成員時是沒有訪談要點的。

53、不管他或她先前被告知什么或通過其他方式了解過什么，訪談者必須帶著認真傾聽受訪者的目的著手開始每一次訪談，與此同時，堅決地克制任何預先固有的成見，尊重客戶公司的意見或客戶的要求以及要構建的產品的潛在用途。</p><p><b>　　情景。</b></p><p>　　一個情景是用戶可能利用目標產品完成某些目的的一種方式?？梢杂枚嘀蟹绞矫枋銮榫?。一種技術是簡單地列出組成

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

55、向對象的分析中發(fā)揮著重要作用。</p><p>　　向相關的客戶組織成員發(fā)放問卷調查表(questionnaire)。</p><p>　　這個技術在需要考慮比如說幾百個個體的需求意見時很有用。進一步說，一個經過認真思考的書面答案可能比一個隨口而出的口頭回答更準確。然而，有一個很有辦法的訪談人進行的非程式化的訪談，由于他能夠認真傾聽受訪者的意見并提出進一步的問題，從而將起初得到的響應大大擴

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

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

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

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

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

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

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

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

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