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)
o
u
t
l
i
n
i
n
g
\color{red}{outlining }
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)
e
s
t
i
m
a
t
e
s
\color{red}{estimates }
estimates how long the project will take and how much it will cost. What the plan is not is a functional (73)
s
p
e
c
i
f
i
c
a
t
i
o
n
\color{red}{specification }
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)
f
e
a
s
i
b
i
l
i
t
y
\color{red}{feasibility }
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)
g
u
i
d
a
n
t
\color{red}{guidant }
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.
创建项目进展地点的清晰地图是重要的第一步。它可以让您识别风险，明确目标，并确定项目是否有意义。唯一比发布计划更重要的是不要太认真。
请计划为您的Web项目创建一个游戏计划（71），概述您认为您希望您的Web站点是什么。该计划是向公众，合作伙伴或内部发布的网站的内容，设计元素和功能的指南。它还（72）计算项目将花费多长时间以及花费多少。计划不是一个功能性（73）规范，它详细定义项目或产生可以带到银行的预算。
基本上，您使用发布计划对项目（74）的可行性和价值进行初步的健全性检查。发布计划是有用的路线图，但不要将它们视为州际公路系统的指南。相反，把它们想象成早期探险家使用的（75）指导者 - 一半的猜测和一半的希望和期望。
拥有一个项目所在的地图总是一个好主意。
(71)
A. constructing 建设
B. designing 设计
C. implementing 实施
D.
o
u
t
l
i
n
i
n
g
\color{red}{outlining }
outlining 概述
(72)
A. defines 定义
B. calculates 计算
C.
e
s
t
i
m
a
t
e
s
\color{red}{estimates }
estimates 估计
D. knows 知道
(73)
A.
s
p
e
c
i
f
i
c
a
t
i
o
n
\color{red}{specification }
specification 规格
B. structure 结构体
C. requirement 需求
D. implementation 履行
(74)
A. correctness 正确性
B. modifiability 可修改
C.
f
e
a
s
i
b
i
l
i
t
y
\color{red}{feasibility }
feasibility 可行性
D. traceability 可追溯性
(75)
A. navigators 导航仪
B. maps 地图
C.
g
u
i
d
a
n
t
\color{red}{guidant }
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）
s
t
r
u
c
t
u
r
e
\color{red}{structure }
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）
m
e
m
o
r
a
n
d
a
\color{red}{memoranda }
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）
w
o
r
k
b
o
o
k
\color{red}{workbook }
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）
i
n
f
o
r
m
a
t
i
o
n
\color{red}{information }
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）
t
r
e
e
−
s
t
r
u
c
t
u
r
e
\color{red}{tree-structure}
tree−structure allows distribution lists to be maintained by subtree, if that is desirable.
项目工作簿不是一个单独的文档，因为它是对项目将要生成的文档施加的结构。
项目的所有文件都必须是这个（71）结构的一部分，包括目标，外部规范，接口规范，技术标准，内部规范和行政备忘录（备忘录）。
技术散文几乎是不朽的。如果检查一个硬件或软件的客户手册的系谱（Ff），人们不仅可以追踪这些想法，而且可以追溯许多句子和段落回到提出产品或解释的第一（72）份备忘录。第一个设计。对于技术作家来说，粘贴罐就像笔一样强大。
既然如此，并且由于明天的产品质量手册将从今天的备忘录中增长，因此正确掌握文档结构非常重要。项目（73）工作手册的早期设计确保了文档结构本身的精心设计，而不是偶然的。此外，建立结构模具后来写入适合该结构的部分。
项目工作簿的第二个原因是控制（74）信息的分布。问题不是限制信息，而是确保相关信息传递给所有需要它的人。
第一步是对所有备忘录进行编号，以便有序的标题列表可用，并且工人可以看到他是否有他想要的东西。工作簿的组织远远超出了这个范围，以建立备忘录的树形结构。 （75）树结构允许通过子树维护分发列表，如果需要的话。
（71）
A.
s
t
r
u
c
t
u
r
e
\color{red}{structure }
structure 结构
B. specification 规范
C. standard 标准
D. objective 目标
（72）
A. objective 目标
B.
m
e
m
o
r
a
n
d
a
\color{red}{memoranda }
memoranda 备忘录
C. standard 标准
D. specification 规范
（73）
A. title 标题
B. list 清单
C.
w
o
r
k
b
o
o
k
\color{red}{workbook }
workbook 工作簿
D. quality 质量
（74）
A. product 产品
B. manual 手册
C. document 文件
D.
i
n
f
o
r
m
a
t
i
o
n
\color{red}{information }
information 信息
（75）
A. list 列表
B. document 文档
C.
t
r
e
e
−
s
t
r
u
c
t
u
r
e
\color{red}{tree-structure}
tree−structure 树结构
D. number 数字
828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
