ssd10_MCQ
.docx
|
|
|
(a) the
use case view describes how the system's critical use cases are
realized by the design model
(b) the
use case view is entirely static
(c) the
use case view must describe every use of the system
(d) the
use case view cannot be abstracted at all
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See section 7.2, pages 112-13 in the textbook. |
|
|
|
4. |
|
Software architecture |
|
|
|
|
(a) has
very fuzzy guidelines
(b) is
a very exact science
(c) is
a paper-only exercise and can't be demonstrated
(d) can
be performed by inexperienced people
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See chapter 7, page 109 in the textbook. |
|
|
|
5. |
|
An architecture baseline |
|
|
|
|
(a) is
the ultimate goal of the construction phase
(b) is
a paper document
(c) is
a collection of information across all the engineering
sets
(d) is
extracted from requirements models
|
|
Correct answer is |
(c) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See chapter 7, page 9, Key Points in the textbook. |
|
|
|
6. |
|
Architectural descriptions |
|
|
|
|
(a) are
different depending on the type and size of a project
(b) should
always be the same within a company
(c) do
not vary widely depending on the type and size of a
project
(d) should
always be standard or corners will be cut
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See section 7.2, page 115 in the textbook. |
|
|
|
7. |
|
Architecture-first development |
|
|
|
|
(a) is
critical to project success and software management
(b) is
a relatively straightforward and not particularly difficult
undertaking
(c) relies
on project management's understanding of all technical details of
architectural description
(d) is
less critical to project success in modern project management
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See section 7.2, page 115 in the textbook. |
|
|
|
8. |
|
Stable software architectures |
|
|
|
|
(a) can
never be changed
(b) are
developed only in the inception phase after a few
iterations
(c) must
be developed before the project is started
(d) are
developed iteratively
|
|
Correct answer is |
(d) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See section 7.1, page 115 in the textbook. |
|
|
|
9. |
|
Software architecture may be defined as |
|
|
|
|
(a) the
significant structure and behavior of a system, including all the
engineering specifications necessary to determine a complete bill
of materials with a high level of confidence
(b) a
system's objects, instances, methods, and the relations between
these components
(c) a
system's design, less the engineering specifications and system
behavior descriptions
(d) components
and connectors
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See Glossary, page 395 in the textbook. |
|
|
|
10. |
|
The UML Architecture Description Document is an organized and abstracted view into the design models. Therefore |
|
|
|
|
(a) it
cannot have supplementary material
(b) it
is not complete unless it contains all design models
(c) it
does not require effort beyond preparing models, which are
prepared as part of the process
(d) it
encompasses a design view, a process view, a use case view, a
component view, and a deployment view
|
|
Correct answer is |
(d) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See section 7.2, page 113 in the textbook. |
|
|
|
Go to top of assessment. |
|
|
Total score: 60.00 |
|
|
© Copyright 2008 iCarnegie, Inc. All rights reserved. |
Конец формы
Начало формы
|
|
|
|
|
|
1. |
|
The waterfall model |
|
|
|
|
(a) surfaces
risk early
(b) allows
you to correct early errors with insights gained later
on
(c) focuses
on documents and review meetings
(d) discourages
functional decomposition
|
|
Correct answer is |
(c) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See section 1.1.2, page 11 in the textbook. |
|
|
|
2. |
|
The waterfall model |
|
|
|
|
(a) is
hard to understand
(b) is
so old fashioned that no one should pay any attention to
it
(c) does
not require consulting the customer
(d) has
sometimes produced good results when applied properly and
supported by modern technologies
|
|
Correct answer is |
(d) |
|
|
Your score on this question is: |
20.00 |
|
|
Feedback: |
See section 1.1, page 6 in the textbook. |
|
|
|
3. |
|
You can tell when a software process is immature when |
|
|
|
|
(a) a
project is more than 10 percent over budget and misses its target
date
(b) the
process takes more time than coding
(c) no
one likes the process
(d) scrap
and rework rates are high
|
|
Correct answer is |
(d) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See chapter 1, page 5 in the textbook. |
|
|
|
4. |
|
Software development is unpredictable because |
|
|
|
|
(a) users
are usually not fully cognizant of their needs
(b) managers
are very unpredictable
(c) software
by its nature is highly flexible
(d) programmers
are very unpredictable
|
|
Correct answer is |
(c) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See chapter 1, page 5 in the textbook. |
|
|
|
5. |
|
The success rate for software projects is very low because |
|
|
|
|
(a) project
management has more to do with project success than do
programmers
(b) technology
improvements are not used
(c) software
development is often a tedious and time-consuming
endeavor
(d) software
development relies on antiquated processes
|
|
Correct answer is |
(a) |
|
|
Your score on this question is: |
0.00 |
|
|
Feedback: |
See chapter 1, page 5 in the textbook. |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Your score on this question is: 10.00
Feedback: See section 3.6, page 53 in the textbook. 1.
A 10,000-line software solution will cost less per line than a 100,000-line software solution because
|
|
|
|
(a) only
happens when a product is released just once
(b) only
happens when a project is in one line of
business
(c) increases
as a project is repeated
(d) can't
happen with multiple iterations
(a) are
generally less accurate than an individual manager's
estimate
(b) are
too inaccurate to be useful except in the most extreme
cases
(c) produce
inaccurate but consistent predictions that can be adjusted to
make them useful
(d) produce
such high estimates that teams are not motivated to work hard
(a) are
easy for most organizations to learn
(b) eliminate
language differences in cost estimation
(c) are
usually inferior to subjective cost estimates
(d) are
incompatible with most modern cost models
(a) applies
only to small systems
(b) requires
mature iterative process
(c) always
depends on investment in architecture
(d) never
depends on process automation
(a) are
always more efficient at run-time
(b) are
often inexpensive
(c) make
team communication easier
(d) can
be introduced at any time
(a) don't
require a particular process
(b) are
not dependent on modeling
(c) require
a strong architectural vision
(d) are
independent of organizational culture
(a) comes
from balance and coverage in the skill of the
team
(b) doesn't
depend on the project manager
(c) is
diminished when team members are average performers
(d) is
better when all members of the team have superior programming
skills
(a) development
environments are more sophisticated
(b) fewer
lines of human-generated code are required to solve problems
nowadays than were required 20 years ago
(c) modern
languages are less labor intensive
(d) projects
cost less than they used to
(a) increase
predictability and avoid expensive downstream scrap and
rework
(b) put
priority on early delivery to increase stakeholder
confidence
(c) cannot
address all stakeholder concerns
(d) are
easier for inexperienced managers to apply
(a) is
only important at baselines
(b) only
applies to project management
(c) is
independent of process and is applied directly to evolving
artifacts
(d) requires
well-defined measures derived directly from evolving
artifacts
(a) Good
management is more important than good technology.
(b) The
customer is always right.
(c) Balancing
the needs of all stakeholders is a manager's
responsibility—as long as managers do what customers
specify, they have met their responsibility.
(d) It
is possible that the customer will tolerate 90 percent of
the functionality delivered late if they can have 10 percent
of it on time.
(a) implies
that balance must be achieved among driving design
requirements, design decisions, and life-cycle plans before
resources are committed for full-scale development
(b) has
little impact on project planning
(c) only
applies to the first two iterations of a project
(d) keeps
projects from being done concurrently
(a) only
apply to the waterfall method
(b) are
addressed through modern software process
principles
(c) have
no impact on cost, quality, and schedule
(d) no
longer are of concern
(a) have
a one-to-one relationship with cost model
parameters
(b) map
directly to cost model parameters
(c) have
no economic implications for software development
costs
(d) have
no relationship with cost model parameters
(a) hiring
the best candidates
(b) a
very structured environment
(c) successful
early iterations and trustworthy management
(d) giving
most of the responsibility to a project's average performers
(a) eliminate
the need for use cases
(b) demonstrate
an evolving understanding of system requirements
(c) are
only required for baselines
(d) have
nothing to do with use cases
(a) involves
design and integration first, then production and
test
(b) involves
object-oriented methods, rigorous notations, and visual
modeling
(c) involves
metrics, trends, and process instrumentation
(d) emerges
from test results over a couple of "spirals"
(a) The
iterative life-cycle process addresses risk
management.
(b) Component-based
development addresses technology elements of the spiral
method.
(c) The
architecture-first approach addresses the central design
element of the spiral method.
(d) Change
management is the manual element of modern process.
(a) eliminate
the need for use cases
(b) have
nothing to do with use cases
(c) are
only required for baselines
(d) demonstrate
an evolving understanding of system requirements
(a) are
only important for baselines
(b) are
too expensive for small projects
(c) require
objectively controlled baselines
(d) rely
on guidelines derived from the experience of experts
(a) giving
most of the responsibility to a project's average
performers
(b) successful
early iterations and trustworthy management
(c) hiring
the best candidates
(d) a
very structured environment
(a) involves
design and integration first, then production and
test
(b) emerges
from test results over a couple of "spirals"
(c) involves
metrics, trends, and process instrumentation
(d) involves
object-oriented methods, rigorous notations, and visual
modeling
(a) requires
object-oriented methods and rigorous notation
(b) requires
visual modeling and risk control
(c) requires
visual modeling and round-trip engineering
(d) requires
complementary tools and integrated environments
(a) only
applies to project management
(b) requires
well-defined measures derived directly from evolving
artifacts
(c) is
independent of process and is applied directly to evolving
artifacts
(d) is
only important at baselines
(a) violate
the 80/20 rule
(b) hardly
ever yield a return on the effort expended
(c) mean
that a common process spirit, extensive process automation,
and architectural patterns and components can be
reused
(d) mean
that the process chosen must work for all contemplated
projects
(a) The
iterative life-cycle process addresses risk
management.
(b) The
architecture-first approach addresses the central design
element of the spiral method.
(c) Component-based
development addresses technology elements of the spiral
method.
(d) Change
management is the manual element of modern process.
(a) is
any collection of modules
(b) is
a cohesive set of preexisting lines of code with defined
interface and behavior
(c) renders
ideas of coupling and cohesion obsolete
(d) must
always exist when a design is contemplated
(a) keeps
projects from being done concurrently
(b) has
little impact on project planning
(c) implies
that balance must be achieved among driving design
requirements, design decisions, and life-cycle plans before
resources are committed for full-scale
development
(d) only
applies to the first two iterations of a project
(a) has
more predictable but larger teams
(b) has
less predictable and larger teams
(c) has
less predictable but smaller teams
(d) has
more predictable and smaller teams
(a) happens
only once in the lifetime of a software project
(b) avoids
interactions with end user stakeholders to produce a good
test
(c) is
the fourth phase of the life cycle and focuses on the
transition of the product to the user community
(d) is
trivial compared to other phases
(a) the
construction phase
(b) the
inception phase
(c) the
transition phase
(d) the
elaboration phase
(a) is
an iteration-focused event conducted to review the content
of a given iteration in detail and to authorize continued
work
(b) does
not involve end-user stakeholders, though it necessarily
involves managers and developers
(c) is
a relatively unimportant, iteration-focused event conducted
after the authorization to continue work has been
given
(d) is
a relatively unimportant review that can be skipped if time
is short
(a) I,
II, and III
(b) III
only
(c) I
and III only
(d) I
and II only
(a) II
and III only
(b) II
only
(c) I,
II, and III
(d) I
and III only
(a) is
the first phase of the life cycle and focuses on the
inception of a product vision and its corresponding business
case
(b) is
the first phase of the first life cycle and happens only
once in the lifetime of a software
project
(c) concentrates
on engineering aspects of a project
(d) always
requires the same percentage of effort
(a) consists
of one iteration only and a technical capability must be
demonstrated
(b) consists
of one or more iterations in which some technical capability
is produced in demonstrable form
(c) has
only major milestones
(d) does
not always have to have demonstrations
(a) is
one feature the modern and conventional processes have in
common and is used to verify that the goals of the previous
phase have been achieved
(b) requires
that progress be reconciled to paper artifact
deliverables
(c) is
a system-wide event held at the end of each phase of
development in order to provide visibility to system-wide
issues, synchronize the management and engineering
perspectives, and verify that the goals of the phase have
been achieved
(d) rarely
is given much importance in the modern software process
until later iterations
(a) if
there is no conflict
(b) if
the architecture is prototyped
(c) if
stakeholders agree on scope definition and cost and schedule
estimates
(d) if
stakeholders agree on scope but not the architecture
(a) has
highly consistent content
(b) should
be driven by the users
(c) provides
a necessary basis for test plans and test cases and for
construction of automated test suites
(d) should
be written early in the life cycle for embedded systems
(a) are
useful no matter how they are structured
(b) are
almost never used to track project costs
(c) are
too old-fashioned to be useful in object-oriented
projects
(d) can
be used for budgeting and cost data collection
(a) cannot
be used to determine whether the project is worth investing
in
(b) is
not useful unless it is succinct
(c) should
be very accurate at the beginning of a project
(d) is
cost, revenue, schedule, and profit expectations
(a) is
a failure if it cannot be machine analyzed
(b) will
always be analyzed by human effort
(c) must
be analyzed by human effort
(d) can
only be evaluated subjectively
(a) is
best created in text only
(b) includes
organized text and models of the problem space
(c) is
in the language of the development team
(d) should
trace to code
(a) provide
an indispensable forcing function
(b) must
be at regularly scheduled intervals
(c) should
be limited because of preparation time required to get
data
(d) should
focus only on major milestone plans and results
(a) insisting
on single source documentation (i.e., not translating visual
models to text)
(b) minimizing
electronic documentation in favor of paper, since it is
harder to change
(c) restricting
access to tools necessary to view documentation
online
(d) being
very succinct, establishing a glossary of code
(a) includes
machine-processible languages and associated
files
(b) requires
no stakeholder involvement in review
(c) cannot
be comprehended by end-user stakeholders or
managers
(d) should
be traced 100 percent from the requirements set
(a) I
and II only
(b) II
only
(c) I,
II, and III
(d) I
and III only
(a) is
probably of dubious quality if frequent revisions are
made
(b) should
have multiple versions for multiple audiences
(c) is
most understandable to managers
(d) elaborates
the process framework into a fully detailed plan
(a) has
highly consistent content
(b) should
be driven by the users
(c) provides
a necessary basis for test plans and test cases and for
construction of automated test suites
(d) should
be written early in the life cycle for embedded systems
(a) are
useful no matter how they are structured
(b) are
almost never used to track project costs
(c) are
too old-fashioned to be useful in object-oriented
projects
(d) can
be used for budgeting and cost data collection
(a) cannot
be used to determine whether the project is worth investing
in
(b) is
not useful unless it is succinct
(c) should
be very accurate at the beginning of a project
(d) is
cost, revenue, schedule, and profit expectations
(a) is
a failure if it cannot be machine analyzed
(b) will
always be analyzed by human effort
(c) must
be analyzed by human effort
(d) can
only be evaluated subjectively
(a) is
best created in text only
(b) includes
organized text and models of the problem space
(c) is
in the language of the development team
(d) should
trace to code
(a) provide
an indispensable forcing function
(b) must
be at regularly scheduled intervals
(c) should
be limited because of preparation time required to get
data
(d) should
focus only on major milestone plans and results
(a) insisting
on single source documentation (i.e., not translating visual
models to text)
(b) minimizing
electronic documentation in favor of paper, since it is
harder to change
(c) restricting
access to tools necessary to view documentation
online
(d) being
very succinct, establishing a glossary of code
(a) includes
machine-processible languages and associated
files
(b) requires
no stakeholder involvement in review
(c) cannot
be comprehended by end-user stakeholders or
managers
(d) should
be traced 100 percent from the requirements set
(a) I
and II only
(b) II
only
(c) I,
II, and III
(d) I
and III only
(a) is
probably of dubious quality if frequent revisions are
made
(b) should
have multiple versions for multiple audiences
(c) is
most understandable to managers
(d) elaborates
the process framework into a fully detailed plan
(a) developed
once, then changed only with change management
(b) a
remnant of the conventional software process
(c) usable
only by the development team
(d) a
discrete, cohesive collection of information, typically
developed and reviewed as a single entity
(a) is
in the language of the user
(b) is
linearly traceable from the requirements set
(c) contains
more text than visual models
(d) includes
models of the solution space
(a) includes
human-readable programming language and associated source
files
(b) needs
only to be verified by technical personnel
(c) can
never be reviewed by nontechnical personnel
(d) should
be under tight security
(a) design
models, test model, and software architecture
description
(b) UML
models without text
(c) test
model, design mode, source code, and software
architecture description
(d) vision
document, design models, test model, and software
architecture description
(a) is
best created in text only
(b) includes
organized text and models of the problem space
(c) is
in the language of the development team
(d) should
trace to code
(a) should
have multiple versions for multiple audiences
(b) is
most understandable to managers
(c) elaborates
the process framework into a fully detailed plan
(d) is
probably of dubious quality if frequent revisions are
made
(a) II
and III only
(b) I,
II, and III
(c) I
only
(d) III
only
(a) artifacts
may be at different levels of detail, depending on the
phase the project is in
(b) artifacts
must be carefully baselined in order to prevent changes
to them in subsequent phases
(c) artifacts
evolve concurrently, at approximately the same level of
detail, and change with each phase
(d) plans
are dependent on a fixed design and the flexibility
afforded by prototyping
(a) should
be traced 100 percent from the requirements
set
(b) requires
no stakeholder involvement in review
(c) cannot
be comprehended by end-user stakeholders or
managers
(d) includes
machine-processible languages and associated files
(a) are
almost never used to track project costs
(b) are
too old-fashioned to be useful in object-oriented
projects
(c) are
useful no matter how they are structured
(d) can
be used for budgeting and cost data collection
(a) is
consistent with release specifications, vision statement,
and requirements models
(b) is
completely structured and, in the modern process, is
easiest to create in the transition phase of a
project
(c) permits
no changes in requirements once it has been
drafted
(d) may
be unstructured and, therefore, may not be consistent
with release specifications, vision statement, and
requirements models
(a) has
highly consistent content
(b) provides
a necessary basis for test plans and test cases and for
construction of automated test suites
(c) should
be driven by the users
(d) should
be written early in the life cycle for embedded systems
(a) component
executables, compile-time files, and software
architecture description
(b) source
code baselines, associated compile-time files, and
component executables
(c) UML
class association models, test models, and source code
baselines
(d) design
models, source code baselines, and component executables
(a) design
models, source code baselines, and component
executables
(b) component
executables, compile-time files, and software architecture
description
(c) UML
class association models, test models, and source code
baselines
(d) source
code baselines, associated compile-time files, and component
executables
(a) is
cost, revenue, schedule, and profit
expectations
(b) should
be very accurate at the beginning of a project
(c) cannot
be used to determine whether the project is worth investing
in
(d) is
not useful unless it is succinct
(a) vision
document and Java code
(b) vision
document and very high-level design models
(c) vision
document and software architecture description
(d) vision
document and requirements model
(a) is
in the language of the development team
(b) is
best created in text only
(c) should
trace to code
(d) includes
organized text and models of the problem space
(a) insisting
on single source documentation (i.e., not translating visual
models to text)
(b) being
very succinct, establishing a glossary of
code
(c) restricting
access to tools necessary to view documentation
online
(d) minimizing
electronic documentation in favor of paper, since it is
harder to change
(a) III
only
(b) II
and III only
(c) I,
II, and III
(d) I
only
(a) a
work breakdown structure, a business case, release
specifications, and design model(s)
(b) a
work breakdown structure and requirements
model(s)
(c) planning
artifacts and operational artifacts
(d) release
descriptions, a vision document, a software change order
database, and deployment documents
(a) the
inception phase
(b) the
elaboration phase
(c) the
transition phase
(d) the
construction phase
(a) the
construction phase
(b) the
transition phase
(c) the
elaboration phase
(d) the
inception phase
(a) has
less predictable but smaller teams
(b) has
more predictable but larger teams
(c) has
more predictable and smaller teams
(d) has
less predictable and larger teams
(a) have
to balance research and production
(b) have
to balance research and production but conventional
processes do not
(c) never
do paper studies
(d) have
continuous hacking
(a) develops
the architecture
(b) has
nothing to do with the engineering stage
(c) emphasizes
construction only
(d) depends
on the result of the engineering stage
(a) the
elaboration phase
(b) the
inception phase
(c) the
construction phase
(d) the
transition phase
(a) concentrates
on engineering aspects of a project
(b) always
requires the same percentage of effort
(c) is
the first phase of the first life cycle and happens only
once in the lifetime of a software project
(d) is
the first phase of the life cycle and focuses on the
inception of a product vision and its corresponding business
case
(a) a
failure to find a balance between research and
production
(b) a
jump right to coding
(c) conventional
software processes
(d) too
much analysis
(a) the
phases can be mapped to Boehm's conceptual spiral
model
(b) the
phases are named after the kind of work done
(c) the
phases don't match the spiral model
(d) the
size of the system stays the same in each phase
(a) emphasizes
inspection and analysis
(b) emphasizes
schedule and technical feasibility
(c) has
more predictable but larger teams
(d) emphasizes
resolving diseconomies of scale
(a) hiring
skills, customer interface skills, and decision-making
skills
(b) respect
for stakeholders, respect for team members, and process design
skills
(c) coding
skills, testing skills, and team-building skills
(d) selling
skills, technical skills, and object-oriented experience
(a) composed
of domain experts rather than quality control
specialists
(b) eliminated
since quality is everyone's responsibility
(c) independent
of the architecture and development team
(d) independent
of the testing team
(a) technical
biases are less important on a big project
(b) more
bugs will be found in the 100,000-line solution
(c) the
100,000-line solution is a bad solution
(d) communications
overhead is less for a smaller team
(a) Complexity,
number of contractors to employees, process, CASE tools, and
required quality
(b) Size,
process, personnel, environment, and required
quality
(c) Source
lines of code, function points, methodology, personnel, and
quality
(d) Size,
process, personnel, CASE tools, and purchased components
(a) cannot
satisfy users unless the approaches are developed entirely for
them
(b) are
always one-of-a-kind efforts
(c) changed
from emphasizing craftsmanship in the 1960s and 1970s to
emphasizing engineering discipline in the 1980s and
1990s
(d) are
not research intensive and do not demand a lot of creativity
(a) are
based mostly on historical project databases using older
processes
(b) reflect
a more production-intensive approach than they once
did
(c) allow
estimates to be obtained easily
(d) are
currently difficult to use successfully
(a) written
responses from stakeholders
(b) treating
each iteration separately to generate fresh
ideas
(c) prototyping,
design models, and executable models
(d) walkthroughs
rather than coding
(a) object-oriented
methods
(b) the
use of Java or ADA
(c) hardware
investments
(d) component-based
development
(a) independent
of the architecture and development team
(b) independent
of the testing team
(c) eliminated
since quality is everyone's responsibility
(d) composed
of domain experts rather than quality control specialists
(a) the
100,000-line solution is a bad solution
(b) more
bugs will be found in the 100,000-line
solution
(c) communications
overhead is less for a smaller team
(d) technical
biases are less important on a big project
(a) produce
inaccurate but consistent predictions that can be adjusted
to make them useful
(b) produce
such high estimates that teams are not motivated to work
hard
(c) are
too inaccurate to be useful except in the most extreme
cases
(d) are
generally less accurate than an individual manager's
estimate
(a) always
depends on investment in architecture
(b) applies
only to small systems
(c) requires
mature iterative process
(d) never
depends on process automation
(a) can't
substitute for Source Lines of Code
(b) are
only good for COBOL and C
(c) require
very little training
(d) allow
different projects to be compared to each other
(a) eliminate
the need for software quality control
(b) allow
use of commercially developed components
(c) eliminate
the need for highly skilled personnel
(d) enable
improvements in software technology
(a) have
difficulty keeping artifacts synchronized as changes
occur
(b) reap
the benefit of having simpler tools
(c) do
not suffer much since early artifacts are rarely referred to
as a project enters later stages
(d) are
less expensive
(a) make
team communication easier
(b) are
always more efficient at run-time
(c) can
be introduced at any time
(d) are
often inexpensive
(a) treating
each iteration separately to generate fresh
ideas
(b) prototyping,
design models, and executable models
(c) written
responses from stakeholders
(d) walkthroughs
rather than coding
(a) some
tools have an extremely high payback
(b) it
allows areas of the life cycle to be improved that couldn't
be improved otherwise
(c) all
software development activities and tools are
interrelated
(d) iterative
development means each iteration will be completely
independent
(a) the
power of visualized software abstractions eliminates the
need for data dictionaries
(b) an
improvement in inter-team communication eliminates the need
for so much integration
(c) rigorous
notation such as the Universal Modeling Language captures
and allows visualizations of software
abstractions
(d) rigorous
notation allows architectural concerns to be deferred until
the end of a project
(a) rigorous
notation such as the Universal Modeling Language captures and
allows visualizations of software abstractions
(b) an
improvement in inter-team communication eliminates the need for
so much integration
(c) rigorous
notation allows architectural concerns to be deferred until the
end of a project
(d) the
power of visualized software abstractions eliminates the need
for data dictionaries
(a) increases
as a project is repeated
(b) can't
happen with multiple iterations
(c) only
happens when a product is released just once
(d) only
happens when a project is in one line of business
(a) communications
overhead is less for a smaller team
(b) more
bugs will be found in the 100,000-line solution
(c) the
100,000-line solution is a bad solution
(d) technical
biases are less important on a big project
(a) are
subject to misinterpretation
(b) must
be defined and counted consistently
(c) can't
be used to compare projects implemented in different
languages
(d) cannot
be counted by the computer
(a) novel
technology being introduced into the process
(b) real
time systems
(c) the
increase in required communications as teams become
larger
(d) depending
on only one person
(a) projects
cost less than they used to
(b) development
environments are more sophisticated
(c) modern
languages are less labor intensive
(d) fewer
lines of human-generated code are required to solve problems
nowadays than were required 20 years ago
(a) eliminate
the need for highly skilled personnel
(b) eliminate
the need for software quality control
(c) enable
improvements in software technology
(d) allow
use of commercially developed components
(a) should
focus on achieving adequate solutions in a minimal number of
iterations with a minimum of scrap and rework
(b) yield
better returns if managers eliminate process
steps
(c) always
give greatest return on investment if managers improve each
step of the process
(d) are
not often accomplished by concurrency
(a) software
technology keeps changing
(b) software
systems are each unique
(c) software
professionals have different backgrounds and
education
(d) no
one agrees on measurements and everyone exaggerates his or
her own bias
(a) the
use of Java or ADA
(b) component-based
development
(c) object-oriented
methods
(d) hardware
investments
(a) are
more effective in embedded platforms
(b) are
always better because they are simpler
(c) can
degrade performance and consume bandwidth because of
abstraction
(d) are
clearly more cost effective
(a) quality
of the software product
(b) project
size
(c) management
process
(d) project
personnel
(a) changed
from emphasizing craftsmanship in the 1960s and 1970s to
emphasizing engineering discipline in the 1980s and
1990s
(b) are
not research intensive and do not demand a lot of
creativity
(c) cannot
satisfy users unless the approaches are developed entirely
for them
(d) are
always one-of-a-kind efforts
(a) cannot
be counted by the computer
(b) can't
be used to compare projects implemented in different
languages
(c) are
subject to misinterpretation
(d) must
be defined and counted consistently
(a) depending
on only one person
(b) real
time systems
(c) the
increase in required communications as teams become
larger
(d) novel
technology being introduced into the process
(a) are
good for discovering real performance bottlenecks
(b) are
cost effective since participants are
interchangeable
(c) rarely
catch significant architectural problems
(d) are
the only way to catch problems with dynamic interactions
(a) should
focus on achieving adequate solutions in a minimal number of
iterations with a minimum of scrap and rework
(b) yield
better returns if managers eliminate process
steps
(c) always
give greatest return on investment if managers improve each
step of the process
(d) are
not often accomplished by concurrency
(a) minimizing
the resources spent for developing visual
models
(b) traceability
of requirements early in the life-cycle
(c) staying
within the original budget for life-cycle
environments
(d) critical
use cases early in the life-cycle
(a) can
be purchased from any vendor
(b) are
rich in functionality
(c) often
have better performance
(d) undergo
frequent upgrades
(a) coding
skills, testing skills, and team-building
skills
(b) selling
skills, technical skills, and object-oriented
experience
(c) hiring
skills, customer interface skills, and decision-making
skills
(d) respect
for stakeholders, respect for team members, and process
design skills
(a) hardware
investments
(b) object-oriented
methods
(c) component-based
development
(d) the
use of Java or ADA
(a) software
systems are each unique
(b) no
one agrees on measurements and everyone exaggerates his or her
own bias
(c) software
technology keeps changing
(d) software
professionals have different backgrounds and education
(a) depend
on iterative development
(b) don't
have much to do with development of tools
(c) eliminate
the need for skilled people
(d) show
that the five cost parameters of cost estimation are related