●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 （  ）. 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 （  ） 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 （  ） 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 （  ）. 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 （  ） allows distribution lists to be maintained by subtree, if that is desirable.

（71）A．structure

B.specification

C.standard

D.objective

（72）A．objective

B.memoranda

C.standard

D.specification

（73）A．title

B.list

C.workbook

D.quality

（74）A．product

B.manual

C.document

D.information

（75）A．list

B.document

C.tree-structure

D.number

● Creating a clear map of where the project is going is an important first step. It lets you identify risks， clarify objectives， and determine if the project even makes sense. The only thing more important than the release plan is not to take it too seriously.

Pelease planning is creating a game plan for your Web project (   ) 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(   ) how long the project will take and how much it will cost. What the plan is not is a functional (    )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 (    ) 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(    ) 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

（71）A． constructing

B. designing

C. implementing

D.outlining

（72）A． defines

B. calculates

C. estimates

D.knows

（73）A． specification

B. structure

C. requirement

D.implementation

（74）A． correctness

B. modifiability

C. feasibilit

D.traceability

（75）A． navigators

B. maps

C. guidant

D.goals

點擊進入>>>希賽軟考題庫 軟考各科目歷年真題在線自測！

想要了解更多軟考考試資訊，可以關注希賽網軟考頻道。