ssd10_MCQ
.docxView Assessment Result: Multiple-Choice Quiz 6
Начало формы
|
|
|
|
Your performance was as follows: |
|
|
1. |
|
The component view |
|
|
|
|
(a) is
based on the deployment set
(b) is
based on the implementation set
(c) is
based on the management set
(d) is
only static in nature
|
|
Correct answer is |
(b) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See section 7.2, page 114 in the textbook. |
|
|
|
2. |
|
The design view |
|
|
|
|
(a) is
dynamic only
(b) is
static only
(c) must
use state charts
(d) describes
the architecturally significant elements of the design model
|
|
Correct answer is |
(d) |
|
|
Your score on this question is: |
10.00 |
|
|
Feedback: |
See section 7.2, page 114 in the textbook. |
|
|
|
3. |
|
View Assessment Result: Multiple-Choice Quiz 6 Начало формы
Конец формы
|
|
(a) communicate
equally well to all types of stakeholders
(b) help
the project manager since they remove the need for constant
explanations to stakeholders
(c) are
a failure if they have to be supplemented with briefings and
narratives
(d) are
crucial to the communication of the purpose of a system and
need to be supplemented with briefings and narratives
(a) is
a paper-only exercise and can't be demonstrated
(b) has
very fuzzy guidelines
(c) can
be performed by inexperienced people
(d) is
a very exact science
(a) the
use case view cannot be abstracted at all
(b) the
use case view describes how the system's critical use cases are
realized by the design model
(c) the
use case view is entirely static
(d) the
use case view must describe every use of the system
(a) is
only static in nature
(b) is
based on the deployment set
(c) is
based on the implementation set
(d) is
based on the management set
(a) abstract
diagrams, critical use cases, verbal narrative and definitions,
vision statement
(b) critical
use cases, relationships of significant classes and components,
source code inventory, and executable components
(c) verbal
narrative and definitions only
(d) diagrams
and critical use cases only
(a) Shaw
and Garlan's architectural definition is closer to a view than
a model.
(b) Shaw
and Garlan's view is not particularly abstract.
(c) Shaw
and Garlan's architectural definition is closer to a model than
a view.
(d) Shaw
and Garlan's architectural approach has nothing to do with a
view or a model.
(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
(a) the
use case view is entirely static
(b) the
use case view cannot be abstracted at all
(c) the
use case view must describe every use of the
system
(d) the
use case view describes how the system's critical use cases
are realized by the design model
(a) must
use state charts
(b) describes
the architecturally significant elements of the design
model
(c) is
dynamic only
(d) is
static only
(a) components
and connectors
(b) a
system's design, less the engineering specifications and
system behavior descriptions
(c) a
system's objects, instances, methods, and the relations
between these components
(d) 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
(a) It
should always be represented in Unified Modeling Language
constructs as long as what is being created is
object-oriented software.
(b) The
concept of "architecture" isn't very precise, so
system components can be represented in any way that is
convenient.
(c) Almost
everyone agrees that the Unified Modeling Language
definition of software architecture is the best.
(d) Not
everyone agrees on the definition of or notation for
software architecture.
(a) help
the project manager since they remove the need for constant
explanations to stakeholders
(b) are
crucial to the communication of the purpose of a system and
need to be supplemented with briefings and
narratives
(c) are
a failure if they have to be supplemented with briefings and
narratives
(d) communicate
equally well to all types of stakeholders
(a) is
a collection of information across all the engineering
sets
(b) is
the ultimate goal of the construction phase
(c) is
extracted from requirements models
(d) is
a paper document
(a) it
is not complete unless it contains all design
models
(b) it
cannot have supplementary material
(c) it
encompasses a design view, a process view, a use case view,
a component view, and a deployment view
(d) it
does not require effort beyond preparing models, which are
prepared as part of the process
(a) are
different depending on the type and size of a
project
(b) do
not vary widely depending on the type and size of a
project
(c) should
always be the same within a company
(d) should
always be standard or corners will be cut
(a) can
never be changed
(b) are
developed iteratively
(c) must
be developed before the project is started
(d) are
developed only in the inception phase after a few iterations
(a) is
only concerned with interprocess communication
(b) is
concerned with run-time issues
(c) is
modeled dynamically using class association
diagrams
(d) is
modeled statically using use cases
(a) The
phases are defined in terms of the artifact sets that have
to be produced rather than in terms of activities.
(b) The
phases can be executed in any order, as opposed to the
sequential order of the conventional process.
(c) The
phases include management activities, which are not
considered in the conventional process.
(d) The
phases represent states of the project rather than a
sequence of activities.
(a) Documentation
and maintenance
(b) Testing
and maintenance
(c) Testing
and quality assurance
(d) Documentation
and quality assurance
(a) Setting
the conditions for future system maintenance
(b) Planning
and control of the life-cycle process to ensure win
conditions for all stakeholders
(c) Organizing
the production of artifacts
(d) Analyzing
the problem from a management point of view
(a) The
workflows are not related to the demonstration-based
approach.
(b) The
implementation and assessment workflows start from the
inception phase, which includes the activities for
developing and assessing prototypes.
(c) The
way the workflows are set, the demonstrations must take
place before other workflows can start.
(d) The
workflows guarantee that a group of people will be in charge
of these demonstrations only.
(a) The
development of prototypes that demonstrate a broad spectrum
of the product's features without extensive functionality
behind each function
(b) The
development of prototypes that are developed by multiple
teams working concurrently
(c) The
development of prototypes that cover a branch of the system,
showing the complete functionality behind each
function
(d) The
development of prototypes that only consider user interface
aspects
(a) the
set of all software process workflows
(b) the
phases that make up the life-cycle process
(c) the
effort involved in each phase of the process
(d) a
distinct sequence of activities within a phase, resulting in
a release
(a) The
design workflow takes care of the architecture and then
other workflows can start.
(b) The
workflows follow a certain order, which guarantees that the
architecture is complete before going into other
workflows.
(c) The
workflows are not related to the architecture-first
approach.
(d) The
work on the requirements and design workflows is greater
before the construction phase and starts from the inception
phase.
(a) The
development of prototypes that start from the user interface
and work their way down into the system
(b) The
development of prototypes that include stubs for the parts
of the system not yet implemented
(c) The
development of prototypes layer by layer
(d) The
development of prototypes that demonstrate the exact
functionality of a product for only a small section of the
entire product
(a) Demonstration
of user interfaces when the actual working functions haven't
yet been implemented
(b) Demonstration
of proper communication between two
systems
(c) Demonstration
of the complete "move" features of a graphics
editor
(d) Demonstration
and testing of all the file conversion features of a text
editor
(a) testing
components
(b) modeling
the solution and evolving the architecture
(c) planning
the content of the release
(d) maintaining
the software change-order database
(a) To
assess the completion of the software and its transition to
the support organization, if any
(b) To
demonstrate an executable architecture to all
stakeholders
(c) To
present to all stakeholders a recommendation on how to
proceed with development
(d) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(a) The
transition from the inception phase to the elaboration
phase
(b) The
transition from the construction phase to the transition
phase
(c) The
transition from the transition phase into the next
iteration
(d) The
transition from the elaboration phase to the construction
phase
(a) With
a final product
(b) With
an artifact baseline
(c) With
a demonstration of a technical capability
(d) With
a release specification and description
(a) With
a release specification and description
(b) With
an artifact baseline
(c) With
a final product
(d) With
a demonstration of a technical capability
(a) To
demonstrate an executable architecture to all
stakeholders
(b) To
assess the readiness of the software to begin the
transition to customer-user sites and to authorize the
start of acceptance testing
(c) To
assess the completion of the software and its transition
to the support organization, if any
(d) To
present to all stakeholders a recommendation on how to
proceed with development
(a) They
do not involve stakeholders.
(b) They
are performed at the end of each iteration.
(c) They
are conducted in an informal way.
(d) They
are performed at the end of each phase.
(a) It
uses stakeholder-approved evaluation criteria.
(b) It
is captured with a release specification and a release
description.
(c) It
provides visibility to system-wide issues.
(d) It
is performed at the end of a phase.
(a) Major
milestones, minor milestones, and status
assessments
(b) Client
acceptance tests, major milestones, and status
assessments
(c) Client
acceptance tests, minor milestones, and status
assessments
(d) Client
acceptance tests, major milestones, and minor milestones
(a) I,
II, and III
(b) II
and III only
(c) I
only
(d) I
and II only
(a) The
transition from the inception phase to the elaboration
phase
(b) The
transition from the construction phase to the transition
phase
(c) The
transition from the elaboration phase to the construction
phase
(d) The
transition from the transition phase into the next
iteration
(a) There
should be more than one for every phase, regardless of
the type of project.
(b) They
should be performed whenever a stakeholder makes a
request.
(c) There
should be one for every phase.
(d) There
is no need for one for every phase, regardless of the
type of project.
(a) Developers
(b) Maintainers
(c) Customers
(d) Users
(a) There
should always be two for every iteration.
(b) They
should be performed whenever a stakeholder makes a
request.
(c) Usually
they are not necessary.
(d) The
number depends on the complexity of the project and the
length of the iteration.
(a) They
do not involve stakeholders.
(b) They
are performed at the end of each iteration.
(c) They
are performed at the end of each phase.
(d) They
are conducted in an informal way.
(a) Client
acceptance tests, minor milestones, and status
assessments
(b) Major
milestones, minor milestones, and status
assessments
(c) Client
acceptance tests, major milestones, and status
assessments
(d) Client
acceptance tests, major milestones, and minor milestones
(a) II
only
(b) I,
II, and III
(c) II
and III only
(d) I
and II only
(a) Users
(b) Developers
(c) Maintainers
(d) Customers
(a) I
and II only
(b) I,
II, and III
(c) II
and III only
(d) I
and III only
(a) I
and III only
(b) II
and III only
(c) I
and II only
(d) I,
II, and III
(a) II
and III only
(b) I,
II, and III
(c) I
and II only
(d) I
only
(a) To
assess the readiness of the software to begin the
transition to customer-user sites and to authorize the
start of acceptance testing
(b) To
demonstrate an executable architecture to all
stakeholders
(c) To
present to all stakeholders a recommendation on how to
proceed with development
(d) To
assess the completion of the software and its transition
to the support organization, if any
(a) I,
II, and III
(b) I
and II only
(c) II
and III only
(d) I
and III only
(a) There
is no need for one for every phase, regardless of the
type of project.
(b) There
should be more than one for every phase, regardless of
the type of project.
(c) There
should be one for every phase.
(d) They
should be performed whenever a stakeholder makes a
request.
(a) There
should always be two for every iteration.
(b) Usually
they are not necessary.
(c) The
number depends on the complexity of the project and the
length of the iteration.
(d) They
should be performed whenever a stakeholder makes a request.
(a) To
review the results of previous iterations
(b) To
review the detailed iteration plan and the evaluation
criteria
(c) To
determine the impact that the iteration will have on future
iterations
(d) To
determine the amount of work to be done in the iteration
(a) II
and III only
(b) I
only
(c) I,
II, and III
(d) I
and II only
(a) To
assess the completion of the software and its transition to
the support organization, if any
(b) To
demonstrate an executable architecture to all
stakeholders
(c) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(d) To
present to all stakeholders a recommendation about how to
proceed with development
(a) II
and III only
(b) I,
II, and III
(c) II
only
(d) I
and II only
(a) With
a demonstration of a technical capability
(b) With
a release specification and description
(c) With
a final product
(d) With
an artifact baseline
(a) I
and II only
(b) I,
II, and III
(c) I
and III only
(d) II
and III only
(a) To
present to all stakeholders a recommendation about how to
proceed with development
(b) To
assess the completion of the software and its transition to
the support organization, if any
(c) To
demonstrate an executable architecture to all
stakeholders
(d) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(a) There
should be more than one for every phase, regardless of the
type of project.
(b) There
is no need for one for every phase, regardless of the type
of project.
(c) They
should be performed whenever a stakeholder makes a
request.
(d) There
should be one for every phase.
(a) It
uses stakeholder-approved evaluation criteria.
(b) It
provides visibility to system-wide issues.
(c) It
is captured with a release specification and a release
description.
(d) It
is performed at the end of a phase.
(a) With
a release specification and description
(b) With
a final product
(c) With
a demonstration of a technical capability
(d) With
an artifact baseline
(a) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(b) To
present to all stakeholders a recommendation on how to
proceed with development
(c) To
demonstrate an executable architecture to all
stakeholders
(d) To
assess the completion of the software and its transition to
the support organization, if any
(a) I,
II, and III
(b) I
and III only
(c) II
and III only
(d) I
and II only
(a) To
determine the impact that the iteration will have on future
iterations
(b) To
determine the amount of work to be done in the
iteration
(c) To
review the detailed iteration plan and the evaluation
criteria
(d) To
review the results of previous iterations
(a) An
artifact that contains the evaluation criteria for a
release
(b) An
artifact that contains the results of release
baselines
(c) An
artifact that represents a user manual for the
release
(d) An
artifact that contains the scope, plan, and objectives of
release baselines
(a) I
and II only
(b) I,
II, and III
(c) I
and III only
(d) II
and III only
(a) They
are conducted in an informal way.
(b) They
are performed at the end of each phase.
(c) They
do not involve stakeholders.
(d) They
are performed at the end of each iteration.
(a) I
and II only
(b) I,
II, and III
(c) II
and III only
(d) I
only
(a) To
demonstrate an executable architecture to all
stakeholders
(b) To
assess the completion of the software and its transition to
the support organization, if any
(c) To
present to all stakeholders a recommendation on how to
proceed with development
(d) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(a) Client
acceptance tests, minor milestones, and status
assessments
(b) Client
acceptance tests, major milestones, and status
assessments
(c) Major
milestones, minor milestones, and status
assessments
(d) Client
acceptance tests, major milestones, and minor milestones
(a) An
artifact that contains the results of release
baselines
(b) An
artifact that contains the evaluation criteria for a
release
(c) An
artifact that represents a user manual for the
release
(d) An
artifact that contains the scope, plan, and objectives of
release baselines
(a) To
present to all stakeholders a recommendation about how to
proceed with development
(b) To
assess the readiness of the software to begin the transition
to customer-user sites and to authorize the start of
acceptance testing
(c) To
demonstrate an executable architecture to all
stakeholders
(d) To
assess the completion of the software and its transition to
the support organization, if any
(a) Subcontractor
analysis
(b) Project
status
(c) Process
assessment
(d) Review
of artifacts
(a) An
artifact that contains the results of release
baselines
(b) An
artifact that contains the evaluation criteria for a
release
(c) An
artifact that represents a user manual for the
release
(d) An
artifact that contains the scope, plan, and objectives of
release baselines
(a) II
only
(b) I
and II only
(c) II
and III only
(d) I,
II, and III
(a) To
determine the amount of work to be done in the
iteration
(b) To
review the results of previous iterations
(c) To
review the detailed iteration plan and the evaluation
criteria
(d) To
determine the impact that the iteration will have on future
iterations
(a) The
transition from the inception phase to the elaboration
phase
(b) The
transition from the elaboration phase to the construction
phase
(c) The
transition from the construction phase to the transition
phase
(d) The
transition from the transition phase into the next iteration
(a) is
only concerned with interprocess communication
(b) is
modeled statically using use cases
(c) is
modeled dynamically using class association diagrams
(d) is
concerned with run-time issues
(a) Almost
everyone agrees that the Unified Modeling Language definition
of software architecture is the best.
(b) Not
everyone agrees on the definition of or notation for software
architecture.
(c) It
should always be represented in Unified Modeling Language
constructs as long as what is being created is object-oriented
software.
(d) The
concept of "architecture" isn't very precise, so
system components can be represented in any way that is
convenient.
(a) can
never be changed
(b) are
developed iteratively
(c) are
developed only in the inception phase after a few
iterations
(d) must
be developed before the project is started