软件开发外文翻译

软件开发外文翻译 Requirements Phase 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 product 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 claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong with the current manual system, there is a high probability that aspects of the new computerized system will be equally “lousy. “ Similarly, if a personal computer manufacturer is contemplating development of a new operating system, the first step is to evaluate the firm’s current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example, it is vital to know whether the problem exists only in the mind of the sales manager, who blames the operating system for poor sales, or whether users of the operating system are thoroughly disenchanted with its functionality and reliability. Only after a clear picture of the present situation has been gained can the team attempt to answer the critical question, What must the new product be able to do? The process of answering this question is carried out during the requirements phase. A commonly held misconception is that , during the requirements phase, the developers 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. Furthermore, 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 members of the development team. To 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 to 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 familiarity with the application domain unless he or she already has experience in that general area. It is particularly important to use correct terminology when communicating with the client and potential users of the target software. After all, it is hard to be taken seriously by a person working in a specific domain unless the interviewer uses the nomenclature appropriate for that domain. More important, use of an inappropriate word may lead to a misunderstanding, eventually resulting in a faulty product being delivered. The same problem can arise if the members of the requirements team do not understand the subtleties of the terminology of the domain. One way to solve the problem with terminology is to build a glossary. The initial entries are inserted while the team learns the application 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 misunderstandings between members of the development team. Once the requirements team have acquired familiarity with the domain, the next step is for them to start to determine the client’s needs, that is, requirements elicitation. Elicitation technique as follows: 1 1. Interviews. The members of the requirements team meet with members of the client organization until they 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, 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 not have come to light had the interview been more structured. At the same time, it is not a good idea if the interview is too unstructured. Therefore, questions should be posed in such a way as to encourage the person being interviewed to give wide-ranging answers but within the context of the information needed by the interviewer. Conducting 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 made 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 what the person being interviewed has to say while firmly suppressing any preconceived notions regarding the client company or the needs of the clients and potential uses of the software product to be built. 2. Scenarios. A scenario is a way a user might utilize the target product to accomplish some objective. A scenario can be depicted 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. 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 understood 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 the real needs of the client, and the only source of this information is the client and the users. Scenarios(or more precisely, use cases) play an important role in object-oriented analysis. 3. To send a questionnaire to the relevant members of the client organization. This technique is useful when the opinions 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 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. Because questionnaires are preplanned, there is no way that a question can be posed in response to an answer. 4. To examine the various forms used by the client. For example, a form in a print shop might reflect press number, paper roll size, humidity, ink temperature, 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 job descriptions, also can be powerful tools for 2 finding out exactly what is done and how. Such comprehensive information regarding how the client currently does business can be extraordinarily helpful in determining the client’s needs. Therefore, careful perusal of client documentation should never be overlooked as a source of information that can lead to an accurate assessment of the client’s needs. 5. To set up videotape cameras within the workplace to record (with the prior written permission of those being observed) exactly what is being done. One difficulty of this technique is that it can take a long time 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 assess 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 team have the full cooperation of all employees; it can be extremely difficult to obtain the necessary information if people feel threatened or harassed. The possible risks should be considered carefully before introducing cameras or, for that matter, taking any other action that has the potential to anger employees. 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 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. 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 development 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 change the rapid prototype until both sides are convinced that the needs of the client are accurately encapsulated in the rapid prototype. The rapid prototype then is used as the basis for drawing up the specifications. An important aspect of the rapid prototyping model is embodied in the word rapid. The whole idea is to build the prototype as quickly 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 crashes 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 to agree as quickly as possible on what the product is to do. Therefore, any imperfections in the rapid prototype may be ignored, provided they do not seriously impair the functionality of the rapid prototype and thereby give a misleading impression of how the product will behave. One difficulty with rapid prototyping is that the 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 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 wait for the operational-quality version, even though the rapid prototype appears to do everything needed. Before rapid prototyping is used, it is 3 essential that the managers responsible for developing the product discuss these and related issues with the client. 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 rapid prototyping. In all fairness, although the case for rapid prototyping is strong, it has not yet been proven beyond all doubt. Testing during the requirements phase Although 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 experiment with the rapid prototype and suggest changes that, when approved by the client, will be implemented in the delivered version of the software product. Therefore, the role of the software quality assurance 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 client or, perhaps, a committee of client managers responsible for analyzing the suggestions of the users. Form the viewpoint of testing during the phases that are to come, it is essential that the requirements 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 form of comments adjacent to the group of statements that implements each item in the requirements. 4 外文翻译 需求阶段 将一个软件产品及时而又不超出预算地开发出来的机会有时是很小的，除非软件开发小组的成员对软件产品将做什么都一致理解。要达到这种全体一致首先是尽可能精确地分析客户当前的状态形势，例如，这样说是不合适的:“因为他们抱怨他们的人工设计系统很糟，所以他们需要一个计算机辅助设计系统。”除非软件开发小组明确地知道当前人工系统有什么问，否则，很有可能新的计算机系统将会在许多方面一样地糟。同样，如果一个个人计算机制造商正打算开发一个新的操作系统，第一步是评价企业单前的操作系统，并认真准确地分析为什么它不能令人满意。或者该操作系统的用户是否完全不认同它的功能和可靠性,仅当对于当前情形有了一个清晰的认识之后，软件开发小组才能够试图回答关键的问题，即新的软件产品必须能够做什么,回答这个问题的过程在需求分析阶段完成。 人们通常持有的一个错误概念是，在需求分析阶段，开发者必须客户想要什么样的软件。与此相反，需求分析阶段真正的目标是确定客户需要什么样的软件。问题在于许多客户不知道他们需要什么，更进一步说，即使一个客户对什么是他们所需要的有一个好的想法，他也可能难于准确地将这些想法传达给开发者，因为大多数客户的计算机知识比起软件开发小组成员来讲要少得多。 为了获取客户的要求，需求小组的成员必须熟悉应用领域，即提议中的软件产品通常要在哪些领域使用。例如，如果没有首先对银行业或护理专业有某种程度的熟悉，就不太容易向一个银行家或护士问出有意义的问题。因此，每个需求小组成员最初的任务之一就是熟悉应用领域，除非他或她已经在那个领域有过一些经历。当与客户和目标软件的可能用户交流时，特别重要的一点是使用正确的术语。毕竟，这一点很难引起工作在某一特定领域的人的重视，除非访谈者使用适于该领域的术语。更重要的是，使用一个不合适的术语可能会导致曲解，甚至会造成发行一个有错误的软件产品的结果。如果需求小组成员不理解该领域术语的细微差别，可能会产生同样的问题。 解决术语问题的一个办法是建立术语，当需求分析小组成员开始学习应用领域知识时，将初始的词条插入到术语表中，然后，每当需求分析小组成员遇到新的术语时就更新该术语表。这样的术语表不仅减少了客户和软件开发者之间的误解，而且在减轻开发小组成员之间的误解方面也是很有用的。 一旦需求分析小组成员熟悉了该应用领域之后，下一步就是由他们来开始确定客户的要求，即进行需求获取。需求获取技术如下: 1(访谈。 需求小组成员会见客户组织的成员，直到他们确信已经从客户和该产品未来的用户处获取了所有相关信息。有两种基本的访谈类型，程式(structured)和非程式化的 5 (unstructured)。在一个程式化的访谈中，提出特定的、预先计划好的、受限回答的(close-ended)问题。在一个非程式化的访谈中，会提出可自由回答的(open-ended)问题，以便鼓励受访人畅所欲言。要是访谈过于程式化了，有些事实可能就发现不了。与此同时，如果访谈太过于非程式化，这也不是一个好注意。因此，应当以一种这样的方式提出问题:他能够鼓励受访者给出范围广泛的回答，但该回答又不要超出访谈者所需信息的范围。 进行一个好的访谈有时并不容易。首先，访谈者必须熟悉应用领域;其二，如果访谈者已经决意尊重客户需求的话，访谈客户组织的成员时是没有访谈要点的。不管他或她先前被告知什么或通过其他方式了解过什么，访谈者必须带着认真倾听受访者的目的着手开始每一次访谈，与此同时，坚决地克制任何预先固有的成见，尊重客户公司的意见或客户的要求以及要构建的产品的潜在用途。 2(情景。 一个情景是用户可能利用目标产品完成某些目的的一种方式。可以用多中方式描述情景。一种技术是简单地列出组成情景的行为。另一种技术是建立情景板(story board)，它是描述事件序列的一系列图表。 它们能够以一种用户可以理解的方式说明软件产品的行为，这会促使发现额外的需求。因为情景能够被用户所理解，情景的使用可以确保客户和用户在整个需求分析过程中自始至终发挥积极作用。毕竟，需求分析阶段的目标是获取用户的真正要求，并且信息的惟一来源是客户和用户。情景(或更精确地说是用例(user case))在面向对象的分析中发挥着重要作用。 3(向相关的客户组织成员发放问卷调查表(questionnaire)。 这个技术在需要考虑比如说几百个个体的需求意见时很有用。进一步说，一个经过认真思考的书面可能比一个随口而出的口头回答更准确。然而，有一个很有办法的访谈人进行的非程式化的访谈，由于他能够认真倾听受访者的意见并提出进一步的问题，从而将起初得到的响应大大扩展了，这样的比一个经过深思熟虑的纸面上的问卷调查表通常揭示出更多的信息。因为问卷调查表是预先计划好的，所以就没有办法根据某一个回答再提出一个问题。 4(检查客户所使用的各种表格(form)。 例如，印刷厂的一张表格可能反映了印刷号、纸张轧压尺寸、湿度、油墨温度、纸张张力等等。这个表格中的各种域显示了印刷工作的流程以及印刷过程，它也可以是准确找出“已做了什么”和“是如何做的”等的强有力工具。这些辅助理解的信息关心的是客户眼下是如何从业的，它在决定客户需求方面是特别有用的。因此，认真研读客户文档绝不应当仅仅被小看为一个信息源，它能够导致准确地把握客户的要求。 5.在公共场所内设立摄象机以准确地录下(当然事先要得到被观察方的书面许可)正在做的事情。 6 这项技术的难点之一是它可能花费很长时间去分析录像带。通常，需求分析小组的一个或多个成员需要花上一个小时回放录像机录下的每个小时的磁带。这个时间对于评估所观察到的东西而言是额外增加的，更严重的是，这一技术据说已经产生了严重的适得其反的结果，因为雇员可能将摄像机看做是对他们个人隐私的一种不当的入侵。重要的是需求分析小组要与雇员进行全面的合作，如果人们感到受威胁或受打扰，他们就很难获得必要的信息。在引入摄像机或者采用任何其他有可能激怒雇员的行动前，可能的危险必须仔细考虑到。 获取了最初的一系列需求之后，下一步就是提炼它们，这是一个称为需求分析(requirements analysis)的过程。需求小组成员与各个受访者讨论需求清单，决定是否忽略了什么;然后因为最精确和有力的需求分析技术是快速原型开发，因此，要建立快速原型。 快速原型是仓促建立的软件，该软件展示了目标软件产品的主要功能。客户和该产品预定的用户对快速原型进行实验的同时，开发小组成员观察并做记录。根据他们丰富的实践经验，用户告诉开发人员快速原型是否能够满足他们的要求，而且更重要的是，指出需改进的地方。随后，开发人员改进快速原型，直至双方确认客户的要求已准确地包含在快速原型中，然后快速原型就作为拟订规格说明的基础。 快速原型开发模型的一个重要方面包含在”快速”一词中，全部的要旨是尽可能快速地建立原型。说到底，快速原型的目的是向客户提供对软件产品的理解，并且是尽可能快、尽可能好的理解。如果快速原型难以工作，如果它每隔几分钟就崩溃，或者如果屏幕布局不很完美，这些都不要紧。快速原型的意图是使客户和开发者能够在该产品做哪些事情方面尽可能快速地达成一致意见，因此，快速原型中的任何不完美之处都可以忽略不计，前提是它们没有严重损害快速原型的功能并让人对产品的行为产生误解。 快速原型开发的一个困难是，快速原型改变起来的容易性可能鼓励客户要求对所交付产品的工作级版本做各种主要的改变。进一步地，客户可能期望实现的改变尽可能与对快速原型的改变一样快。有关的问题是不得不向客户结实快速原型不具有工作质量，客户将要等待具有工作质量的版本，即使快速原型看起来做了要求做的每件事。在使用快速原型开发之前，负责开发该产品的管理者与客户讨论这些相关问题是必须的。 至于新技术的引入，在一个组织提议使用快速原型开发模型前，至关重要的是管理者要意识到快速原型开发的优缺点。公平地说，尽管快速原型开发的事例强有说服力，但还没有证明他是无懈可击的。 需求分析阶段测试 尽管需求分析阶段的目标是确定客户的真正要求，通常客户不是该目标产品的最终用户，于是有必要给用户试验快速原型并提出改进建议的机会，在征得客户同意后，在软件产品的交付版本中完成这种改变。 因此，在快速原型开发阶段，软件质量保证小组的任务是确保客户组织中的有关人 7 员有机会与快速原型交互，并且保证让他们的建议确实送达负责分析用户建议的客户(也可能是一个客户管理者委员会)。 在将要到来的那个阶段，从测试的观点来看需求是可跟踪的，这一点非常重要。要达到这个要求，应当将需求的说明编号，从而使SQL能够在随后的阶段中跟踪它们。在快速原型中，编号应当以注释的形式在需求中每一组说明之后出现。 8