我很烦Model Summary

2021年1月19日发(作者：brush怎么读)
Summary
The process models presented above are not the only possible models, and they
need
not
be
followed
rigidly.
They
are
simply
particular
examples.
It
is
to
be
stressed that according to the project being undertaken, and the areas of risk and
uncertainty
within
it,
some
blend
of
process
models
would
be
necessary.
Whatever the process model, planning & tracking, reviews, SCM and Traceability
are essential.

It is also worth noting that the different process models can be viewed as different
unwinding of the spiral model. For example, V model is a single unwinding; VP
model is a single unwinding in which each prototyping activity is a separate cycle
to
resolve
some
risks/uncertainties;
Evolutionary
model
unwinds
to
allow
a
reassessment
of
the
system
at
the
end
of
each
cycle;
Incremental
model
has
an
unwinding to each increment.
2.4.1
Process Model Selection
Here we present two tables -- the process model evaluation criteria table and the
process
model
selection
matrix
table.
The
process
model
selection
is
predominantly based on criteria assessment.

2.4.1.1
Evaluation Criteria
Table
1
gives
typical
criteria
of
a
project
that
can
impact
the
selection
of
the
Software
Life-Cycle
Model
used.
The
description
of
the
criteria
and
the
terms
used to characterize the criteria shall be the reference of using the follow process
model selection matrix. (See Table 1 and Table 2)

Table 1: Evaluation Criteria Table

Criteria
Description of the Criteria
Description of Terms
Availability of
Resources
include
time,
people,
Some
: The resources either cannot
Resources
money, and tools.
be estimated or are not all
available.
ALL
: The resources can be
identified and are available.
Complexity of
The number of sub-systems, the
Low
: All criteria of complexity
Project
number of disciplines and the
low.
Medium
: Complexity
novelty of technology in the
characteristics are mixed, i.e. one
system.
or two are high, and one or two are
low.
High
: All criteria of complexity
are high.
Cost of Application
Each organization has its own cost
Low
: Cost is less than a specific
criteria from high-to-low-cost
dollar value.
projects.
Med
: Cost is a specific dollar

1
amount.
High
: Cost is over a specific dollar
value.

Discrete
Discrete changes occur if a group
Small
: The discrete change
Requirement
of related functions change at one
integrates with the system at less
Changes
time.
than 5 interfaces and has a total
number of less than 10 processes.
Large
: The large change integrates
with the system at greater than or
equal to 5 points and has 10 or
more processes.

Ease of Use
This relates to the ability to use the
Simple
: The phases are intuitive.
life-cycle model.
The deliverables are straightford.
The process focuses on
development and not on the
support processes.
Complex
: The support processes,
like SQA and SCM, require
control in addition to the
development.

Functional Needs of
Definition of the functional needs
Vague
: Functional needs are
the Application
of the application(what the system
difficult to define.
must do).
Specific
: The functional needs of
the system are well defined if they
are measurable and testable.

Longevity of
Time from system creation
Short
: System is a short term
Application
through the time it is replaced.
solution.
Intermediate
: Longevity
of 2-4 years.
Long
: Longevity of >
4 years.
Product
Whether development technology
Existing
: Up-to-date technology
Development
is current and familiar to
that developers have used
Technology
developers or is new.
previously in developing systems.
New
: Technology not applied by
the project team.
Productivity of
This is reflected in the cost-benefit
Low
: The cost-benefit analysis is
Application
analysis performed for the project
less than a designated value, or the
if the benefits are tangible.
benefits are intangible.
High
: The cost-benefit analysis is
greater than a designated value.

Requirements
The degree to which requirements
Low
: Requirements well defined
Volatility
change during the development
initially and stable.
cycle.
Medium
: Requirements subject to
minimal change
High
: Requirements highly
volatile.
Building over
Building over existing components
Low
: Opportunity to reuse product

2