1.1.1 Modelo Incremental
Construct
a partial implementation of a total system
Then
slowly add increased functionality
The
incremental model prioritizes requirements of the system and then implements
them in groups.
Each
subsequent release of the system adds function to the previous release, until
all designed functionality has been implemented.
Forças:
·
Develop
high-risk or major functions first
·
Each
release delivers an operational product
·
Customer
can respond to each build
·
Uses “divide and conquer” breakdown of tasks
·
Lowers
initial delivery cost
·
Initial
product delivery is faster
·
Customers
get important functionality early
·
Risk
of changing requirements is reduced
Fraquezas:
·
Requires
good planning and design
·
Requires
early definition of a complete and fully functional system to allow for the
definition of increments
·
Well-defined
module interfaces are required (some will be developed long before others)
·
Total
cost of the complete system is not lower
Quando
usar:
·
Risk,
funding, schedule, program complexity, or need for early realization of
benefits.
·
Most
of the requirements are known up-front but are expected to evolve over time
·
A
need to get basic functionality to the market early
·
On
projects which have lengthy development schedules
·
On
a project with new technology
1.1.2 Modelo Waterfall
•
Requirements –
defines needed information, function, behavior, performance and interfaces.
•
Design –
data structures, software architecture, interface representations, algorithmic
details.
•
Implementation – source code, database, user documentation, testing.
Forças:
•
Easy
to understand, easy to use
•
Provides
structure to inexperienced staff
•
Milestones
are well understood
•
Sets
requirements stability
•
Good
for management control (plan, staff, track)
•
Works
well when quality is more important than cost or schedule
Deficiencias:
•
All
requirements must be known upfront
•
Deliverables
created for each phase are considered frozen – inhibits flexibility
•
Can
give a false impression of progress
•
Does
not reflect problem-solving nature of software development – iterations of
phases
•
Integration
is one big bang at the end
•
Little
opportunity for customer to preview the system (until it may be too late)
Quando
usar:
•
Requirements
are very well known
•
Product
definition is stable
•
Technology
is understood
•
New
version of an existing product
•
Porting
an existing product to a new platform.
1.1.3 Espiral
·
Adds
risk analysis, and 4gl RAD prototyping to the waterfall model
·
Each
cycle involves the same sequence of steps as the waterfall process model
·
Typical
activites:
o
Create
a design
o
Review
design
o
Develop
code
o
Inspect
code
o
Test
product
Forças
·
Provides
early indication of insurmountable risks, without much cost
·
Users
see the system early because of rapid prototyping tools
·
Critical
high-risk functions are developed first
·
The
design does not have to be perfect
·
Users
can be closely tied to all lifecycle steps
·
Early
and frequent feedback from users
·
Cumulative
costs assessed frequently
Fraquezas:
·
Time
spent for evaluating risks too large for small or low-risk projects
·
Time
spent planning, resetting objectives, doing risk analysis and prototyping
may be excessive
·
The
model is complex
·
Risk
assessment expertise is required
·
Spiral
may continue indefinitely
·
Developers
must be reassigned during non-development phase activities
·
May
be hard to define objective, verifiable milestones that indicate readiness to
proceed through the next iteration
Quando
usar:
·
When
creation of a prototype is appropriate
·
When
costs and risk evaluation is important
·
For
medium to high-risk projects
·
Long-term
project commitment unwise because of potential changes to economic priorities
·
Users
are unsure of their needs
·
Requirements
are complex
·
New
product line
·
Significant
changes are expected (research and exploration)
Nenhum comentário:
Postar um comentário