Agenda

• Cascada
Metodologías • RAD
Tradicionales • Iterativo
de Desarrollo • Modelo V
de Software • Espiral
• RUP

2
Tipos de Metodologías

3
 Cascada
• Easy to understand and implement
• It reinforces good habits such as define
before design, design before code
• It identifies deliverables and milestones
• Document driven
• Published documentation standards
• Works well on mature products and weak
teams

• Idealized doesn’t match reality well.

• It doesn’t reflect iterative nature of
exploratory development.
• It is unrealistic to expect accurate
requirements so early in project.
• Software is delivered late in project, delays
discovery of serious errors.
• It is difficult to integrate risk management.
• It is expensive to make changes to
documents
4
 V Model
• Simple and easy to use
• Each phase has specific deliverables
• Higher chance of success over the
waterfall model due to the early
development of test plans during the life
cycle
• Works well for small projects where
requirements are easily understood

• Very rigid like the waterfall model

• Little flexibility and adjusting scope is
difficult and expensive
• Software is developed during the
implementation phase, so no early
prototypes of the software are produced
• This model does not provide a clear path
for problems

5
RAD Rapit Application
Development
• In iterative model we are building and
improving the product step by step
• we can track the defects at early stages
• This avoids the downward flow of the
defects
• In iterative model we can get the reliable
user feedback
• In iterative model less time is spent on
documenting and more time is given for
designing

• Each phase of iteration is rigid with no

overlaps
• Requirement changes can cause over
budget.
• Project completion date not confirmed
because of changing requirements.
6
RAD Rapit Application
Development
• In iterative model we are building and
improving the product step by step
• we can track the defects at early stages
• This avoids the downward flow of the
defects
• In iterative model we can get the reliable
user feedback
• In iterative model less time is spent on
documenting and more time is given for
designing

• Each phase of iteration is rigid with no

overlaps
• Requirement changes can cause over
budget.
• Project completion date not confirmed
because of changing requirements.
7
RAD Rapit Application
Development
• Requirements can be changed at any time
• Encourages and priorities customer
feedback
• Reviews are quick
• Development time is drastically reduced
• More productivity with fewer people
• Time between prototypes and iterations is
short

• Needs strong team collaboration

• Cannot work with large teams
• Needs highly skilled developers
• Needs user requirement throughout the
life cycle of the product
• Only suitable for projects which have a
small development time
8
 Espiral

• High amount of risk analysis

• Good for large and mission critical projects
• Software is produced early in the software
life cycle

• Can be a costly model to use

• Risk analysis requires highly specific
expertise
• Project’s success is highly dependent on
the risk analysis phase
• It doesn’t work well for smaller projects

9
Rational Unified Process

• This is a complete methodology in itself

with an emphasis on accurate
documentation
• It is proactively able to resolve the project
risks associated with the client's evolving
requirements requiring careful change
request management
• Less time is required for integration as the
process of integration goes on throughout
the software development life cycle
• The development time required is less due
to reuse of components
• There is a lot of learning material available
for this process

10
Rational Unified Process
• The team members need to be expert in
their field to develop a software under this
methodology
• The development process is too complex
and disorganized
• On cutting edge projects which utilize new
technology, the reuse of components will
not be possible Hence the time saving one
could have made will be impossible to
fulfill
• Integration throughout the process of
software development, in theory sounds a
good thing But. on particularly big projects
with multiple development streams it will
only add to the confusion and cause more
issues during the stages of testing

11
Tipos de Metodologías

12
 Agilismo - Agile

Más que un proceso es el equipo

Software costoso El cliente es parte crucial del

desarrollo del producto
Poco mantenible

Poco utilizable Aceptar que los requerimientos

pueden cambiar

El software funcional e la mejor

medida de avance en el proyecto

13
 Agilismo - Agile

Agile plans are a baseline that we use to help us

control changes. Agile teams plan just as carefully
as traditional teams, but the plans are constantly
revising to reflect the things we learn during a
project.

Success is based on value delivered by the

software

Agile engineering sees software development as a

primarily human activity, where the people
Fowler, M. (n.d.). Agile Software Guide. Retrieved July 30, 2021, from involved and how they bond as a team are the
https://martinfowler.com/agile.html primary driver behind success. 14
 Agilismo - Agile

Agile Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and
helping others do it Through this work we have come to value:

• Individuals and interactions over processes and tool

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items
on the left more.

Fowler, M. (n.d.). Agile Software Guide. Retrieved July 30, 2021, from
https://martinfowler.com/agile.html
15
 Agilismo – Principios
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements even late in development. Agile processes harness change for the customer’s
competitive advantage.

Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter
timescale.

Business people and developers must work together daily throughout the project

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the
job done

The most efficient and effective method of conveying information to and within a development team is face to face
conversation

Working software is the primary measure of progress

Fowler, M. (n.d.). Agile Software Guide. Retrieved July 30, 2021, from
https://martinfowler.com/agile.html
16
 Agilismo – Principios
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely

Continuous attention to technical excellence and good design enhances agility

Simplicity the art of maximizing the amount of work not done is essential

The best architectures, requirements, and designs emerge from self organizing teams

At regular intervals, the team reflects on how to become more effective then tunes and
adjusts its behavior accordingly

Fowler, M. (n.d.). Agile Software Guide. Retrieved July 30, 2021, from
https://martinfowler.com/agile.html
17
En Resumen

18
Preguntas

19