2018軟件設計師考試(英語部分)

2018年上半年上午卷

Creating a clear map of where the project is going is an importnt first step. It lets you identfy risks, clarify objectives, and determine if the project even makes sense. The only thing more imortant than the release plan is not to take it too seriously.
Please planning is creating a game plan for your Web project (71) \color{red}{outlining } what you think you want your Web site to be. The plan is a guide for the content, design elements, and functionality of a Web site to be released to the public, to partners, or internally. It also (72) \color{red}{estimates } how long the project will take and how much it will cost. What the plan is not is a functional (73) \color{red}{specification } that defines the project in detail or that produces a budget you can take to the bank.
Basically you use a release Plan to do an initial sanity check of the project's (74) \color{red}{feasibility } and worthiness. Release Plans are useful road maps, but don't think of them as guides to the interstate road system. Instead, think of them as the (75) \color{red}{guidant } used by early explorers-half umor and guess and half hope and expectation.
It's always a good idea to have a map of where a project is headed.

創(chuàng)建項目進展地點的清晰地圖是重要的第一步。它可以讓您識別風險,明確目標,并確定項目是否有意義。唯一比發(fā)布計劃更重要的是不要太認真。
請計劃為您的Web項目創(chuàng)建一個游戲計劃(71),概述您認為您希望您的Web站點是什么。該計劃是向公眾,合作伙伴或內(nèi)部發(fā)布的網(wǎng)站的內(nèi)容,設計元素和功能的指南。它還(72)計算項目將花費多長時間以及花費多少。計劃不是一個功能性(73)規(guī)范,它詳細定義項目或產(chǎn)生可以帶到銀行的預算。
基本上,您使用發(fā)布計劃對項目(74)的可行性和價值進行初步的健全性檢查。發(fā)布計劃是有用的路線圖,但不要將它們視為州際公路系統(tǒng)的指南。相反,把它們想象成早期探險家使用的(75)指導者 - 一半的猜測和一半的希望和期望。
擁有一個項目所在的地圖總是一個好主意。

(71)
A. constructing 建設
B. designing 設計
C. implementing 實施
D. \color{red}{outlining } 概述
(72)
A. defines 定義
B. calculates 計算
C. \color{red}{estimates } 估計
D. knows 知道
(73)
A. \color{red}{specification } 規(guī)格
B. structure 結構體
C. requirement 需求
D. implementation 履行
(74)
A. correctness 正確性
B. modifiability 可修改
C. \color{red}{feasibility } 可行性
D. traceability 可追溯性
(75)
A. navigators 導航儀
B. maps 地圖
C. \color{red}{guidant } 蓋丹特
D. goals 目標


2018年下半年上午卷

The project workbook is not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway.
All the documents of the project need to be part of this (71)\color{red}{structure }. This includes objectives ,external specifications , interface specifications , technical standards , internal specifications and administrative memoranda(備忘錄).
Technical prose is almost immortal. If one examines the genealogy ( Ff ) of a customer manual for a piece of hardware or software , one can trace not only the ideas , but also many of the very sentences and paragraphs back to the first (72)\color{red}{memoranda } proposing the product or explaining the first design. For the technical writer, the paste-pot is as mighty as the pen.
Since this is so, and since tomorrow's product-quality manuals will grow from today’s memos, it is very important to get the structure of the documentation right. The early design of the project (73)\color{red}{workbook } ensures that the documentation structure itself is crafted, not haphazard. Moreover, the establishment of a structure molds later writing into segments that fit into that structure.
The second reason for the project workbook is control of the distribution of (74)\color{red}{information }. The problem is not to restrict information, but to ensure that relevant information gets to all the people who need it.
The first step is to number all memoranda, so that ordered lists of titles are available and h worker can see if he has what he wants. The organization of the workbook goes well beyond this to establish a tree-structure of memoranda. The (75)\color{red}{tree-structure} allows distribution lists to be maintained by subtree, if that is desirable.

項目工作簿不是一個單獨的文檔,因為它是對項目將要生成的文檔施加的結構。
項目的所有文件都必須是這個(71)結構的一部分,包括目標,外部規(guī)范,接口規(guī)范,技術標準,內(nèi)部規(guī)范和行政備忘錄(備忘錄)。
技術散文幾乎是不朽的。如果檢查一個硬件或軟件的客戶手冊的系譜(Ff),人們不僅可以追蹤這些想法,而且可以追溯許多句子和段落回到提出產(chǎn)品或解釋的第一(72)份備忘錄。第一個設計。對于技術作家來說,粘貼罐就像筆一樣強大。
既然如此,并且由于明天的產(chǎn)品質(zhì)量手冊將從今天的備忘錄中增長,因此正確掌握文檔結構非常重要。項目(73)工作手冊的早期設計確保了文檔結構本身的精心設計,而不是偶然的。此外,建立結構模具后來寫入適合該結構的部分。
項目工作簿的第二個原因是控制(74)信息的分布。問題不是限制信息,而是確保相關信息傳遞給所有需要它的人。
第一步是對所有備忘錄進行編號,以便有序的標題列表可用,并且工人可以看到他是否有他想要的東西。工作簿的組織遠遠超出了這個范圍,以建立備忘錄的樹形結構。 (75)樹結構允許通過子樹維護分發(fā)列表,如果需要的話。

(71)
A. \color{red}{structure } 結構
B. specification 規(guī)范
C. standard 標準
D. objective 目標
(72)
A. objective 目標
B. \color{red}{memoranda } 備忘錄
C. standard 標準
D. specification 規(guī)范
(73)
A. title 標題
B. list 清單
C. \color{red}{workbook } 工作簿
D. quality 質(zhì)量
(74)
A. product 產(chǎn)品
B. manual 手冊
C. document 文件
D. \color{red}{information } 信息
(75)
A. list 列表
B. document 文檔
C. \color{red}{tree-structure} 樹結構
D. number 數(shù)字

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容