SlideShare una empresa de Scribd logo
Ciclo de vida del
software
joan sebastián ramírez pérez
2016
Agenda
• ¿Qué es una metodología?
• Etapas ciclo de vida del software
• Clasificación de las metodologías
• Ciclos de vida existentes
¿Qué es una metodología de
desarrollo de software?
• La metodología para el desarrollo de software es un
modo sistemático de realizar, gestionar y administrar
un proyecto para llevarlo a cabo con altas
posibilidades de éxito.
• Sistematizar hace referencia a dividir el proyecto en
etapas. La normalización de estas etapas ayuda a la
administración y control del proyecto.
• Son los procesos a seguir sistemáticamente para
idear, implementar y mantener un producto software
desde que surge la necesidad del producto hasta que
cumplimos el objetivo por el cual fue creado.
ETAPAS DEL CICLO
DE VIDA
etapas del ciclo de vida
• Expresión de necesidades
• Especificaciones
• Análisis
• Diseño
• Implementación
• Debugging
• Validación
• Evolución
Expresión de necesidades
• Esta etapa tiene como objetivo elaborar un
documento en el cual se reflejan los
requerimientos y funcionalidades que ofrecerá
al usuario el sistema a implementar (qué, y no
cómo, se va a implementar).
Especificaciones
• Se formalizan los requerimientos; el
documento obtenido en la etapa anterior se
tomará como punto de partida para esta
etapa.
Análisis
• Se identifican los elementos que intervienen
en el sistema a desarrollar, su estructura,
relaciones, evolución temporal,
funcionalidades.
• Resultado de lo anterior se tendrá una
descripción clara de qué producto vamos a
construir, qué funcionalidades aportará y qué
comportamiento tendrá.
Diseño
• Ya se identificó qué hacer, ahora se debe
determinar cómo hacerlo (¿cómo debe ser
construido el sistema en cuestión?
• Se debe definir en detalle: entidades y
relaciones de las bases de datos,
seleccionamos el lenguaje que vamos a
utilizar, el Sistema Gestor de Bases de Datos,
etc.).
Implementación
• Se empiezan a codificar algoritmos y
estructuras de datos, definidos en las etapas
anteriores, en el correspondiente lenguaje de
programación o para un determinado sistema
gestor de bases de datos.
Debugging
• El objetivo de esta etapa es garantizar que nuestro
programa no contiene errores de diseño o
codificación.
• En esta etapa no se busca saber si nuestro programa
realiza lo que solicitó el usuario, esa tarea le
corresponde a la etapa de implementación. En ésta
se desea encontrar la mayor cantidad de errores.
• Todos los programas contienen errores: encontrarlos
es cuestión de tiempo. Lo ideal es encontrar la
mayoría, si no todos, en esta etapa. También se
pueden agregar pruebas de rendimiento.
Validación
• Esta etapa tiene como objetivo la verificación
de que el sistema desarrollado cumple con los
requerimientos expresados inicialmente por el
cliente.
• En muchos proyectos las etapas de validación
y debugging se realizan en paralelo por la
estrecha relación que llevan. Sin embargo,
tenemos que evitar la confusión: podemos
realizarlas en paralelo, pero no como una
única etapa.
Evolución
• En la mayoría de los proyectos se considera esta
etapa como mantenimiento y evolución, y se le
asigna, no sólo el agregado de nuevas
funcionalidades (evolución); sino la corrección de
errores que surgen (mantenimiento).
• En la práctica esta denominación no es del todo
errónea, ya que es posible que aún, luego de una
etapa de debugging y validación exhaustiva, se
filtren errores.
CLASIFICACIÓN DE
LAS METODOLOGÍAS
Metodologías estructuradas
• La orientación de estas metodologías se
dirige hacia los procesos que intervienen en el
sistema a desarrollar, es decir, cada función a
realizar por el sistema se descompone en
pequeños módulos individuales.
• Es más fácil resolver problemas pequeños, y
luego unir cada una de las soluciones, que
abordar un problema grande.
Metodologías orientadas a
objetos
• Ésta no comprende los procesos como
funciones sino que arma módulos basados en
componentes, es decir, cada componente es
independiente del otro.
• Esto nos permite que el código sea
reutilizable. Es más fácil de mantener porque
los cambios están localizados en cada uno de
estos componentes.
Ciclos de vida
Ciclos de vida
• Ciclo de vida Lineal
• Ciclo de vida en V
• Ciclo de vida Cascada
Puro
• Ciclo de vida Cascada
con Subproyectos
• Ciclo de Vida Iterativo
• Ciclo de Vida por
Prototipos
• Ciclo de vida
Evolutivo
• Ciclo de vida
Incremental
• Ciclo de vida en
Espiral
• Ciclo de vida
Orientado a Objetos
• Metodologías Ágiles
Ciclo de vida Lineal
• Se descompone el proyecto en
etapas que se ejecutan una
tras otra.
• Cada etapa es independiente y
no hay retroalimentación entre
ellas.
• Se facilita la gestión y
administración.
• No apta para proyectos en los
cuales se requiere
retroalimentación entre sus
etapas.
Ciclo de vida cascada puro
• Creada en 1970 por Winston Royce.
• Permite iteraciones y retroalimentación
entre sus etapas.
• Es rígido, poco flexible y restrictivo.
• Apoya a la planificación “simple” y calidad
del producto.
• Los resultados solo se ven en etapas
finales, se requieren todos los requisitos
desde el principio y un error en una etapa
suele ser costosa para el proyecto.
• Debido a las criticas que recibió en los 90,
se considera un modelo teórico con poca
aplicación en la industria.
Ciclo de vida en v
• Diseñado por Alan Davis,
contiene las mismas
etapas del cascada puro
solo que añade etapas de
validación y verificación.
• Goza de las mismas
fortalezas y falencias que
el cascada puro.
Ciclo de vida Cascada con
Subproyectos• Se sigue el cascada puro
pero se divide el proyecto
en sub-etapas
independientes que se
pueden elaborar en
paralelo.
• La posibilidad de tener
más personas surge
como fortaleza. Como
desventaja aparece las
dependencias que se
pueden dar entre sub-
etapas.
Ciclo de Vida Iterativo
• Variación del cascada cuyo fin es
minimizar el riesgo entre las necesidades
del usuario y el producto final derivados
de malos entendidos en la etapa de
licitación de requisitos.
• Cada iteración se realiza un cascada cuya
entrega es una versión mejorada del
producto.
• El resultado de la interacción es evaluado
por el cliente y sometido a mejoras hasta
conseguir un producto que satisface las
necesidades.
• Se usa en proyectos en los cuales los
requerimientos no están claros o en los
que el cliente puede poner partes del
software en producción.
Ciclo de Vida por Prototipos
• Basado en prototipos como el ciclo
de vida iterativo.
• Se usa cuando no se conoce el
producto o no se tiene certeza sobre
las necesidades por parte del cliente.
Es común en ideas de innovación o
para usar tecnologías nuevas o poco
probadas.
• Es el modelo preciso cuando se
tiene incertidumbre sobre el producto
o las tecnologías a usar.
• Por su naturaleza se hace difícil la
administración de costos y tiempos.
Ciclo de vida Evolutivo
• Acepta que los requisitos
del usuario pueden
cambiar en el tiempo.
• Afronta la variación de los
requisitos en un esquema
requerimientos-desarrollo-
evaluación.
• Es útil cuando
desconocemos los
requerimientos iniciales o
los tenemos incompletos.
Ciclo de vida Incremental
• Busca construir incrementando las
capacidades del software.
• Se construye el software por
módulos.
• Se aplican modelos cascadas por
modulo del sistema, lo que permite
hacerle entregas al cliente antes de
finalizar el proyecto.
• En caso de equivocación en la
definición se desecha la iteración, sin
afectar etapas posteriores.
• Es útil cuando el usuario necesita
entregas parciales del software.
Ciclo de vida en Espiral
• Diseñado por Boehm en 1988 como evolución
del modelo por prototipos.
• Se basa en ciclos repetitivos que se alimentan
de la experiencia obtenida hasta llegar al
producto final.
• Toma los beneficios del incremental y
prototipos, pero tiene en cuenta los riesgos
asociados a la incertidumbre de los
requerimientos.
• Cada ciclo que se cumple (avance de espiral)
genera prototipos que satisfacen al usuario o
al cliente.
• Como ventajas presenta que convive con
proyectos con alto grado de incertidumbre,
bajo riesgo de retraso por detección de
errores.
• Como desventaja tiene costo en tiempo, costo
para evaluar riesgos y alta dependencia con el
cliente.
Ciclo de vida Orientado a
Objetos
• Data de la década del 90.
• Cada funcionalidad se considera un
objeto, las propiedades del
requerimiento o funcionalidad se
consideran atributos y el
comportamiento de los atributos se
denomina método.
• Los requerimientos son abstractos lo
cual le da flexibilidad.
• Se favorece la reducción de la
complejidad del problema ayudando al
perfeccionamiento del producto.
• El modelo aplica independiente si el
lenguaje que se usará es o no es
orientado a objetos.
Metodologías Ágiles
• Alistar Cockburn resume
la agilidad en: entrega
continua, colaboración,
adaptación y mejora
continua.

Más contenido relacionado

PPTX
Desarrollo iterativo e incremental
DOCX
Plan de gestion de la calidad del software
PPTX
PDF
Modelos de desarrollo del software
PPT
Sesion 3 2 modelo de analisis
PPT
PPTX
Metodología tradicional
PDF
Cuadro comparativo
Desarrollo iterativo e incremental
Plan de gestion de la calidad del software
Modelos de desarrollo del software
Sesion 3 2 modelo de analisis
Metodología tradicional
Cuadro comparativo

La actualidad más candente (20)

PPTX
Modelo V
PDF
Modelo de Ciclo de Vida de Prototipado Evolutivo
PPT
TOGAF - Fase A
PDF
Metodologia del rup
PPTX
Modelos de Ciclos de Vida
PPTX
Analisis y Diseños de Sistemas 2-Metodologia OOSE
PPTX
Modelo Cascada y Espiral
PPTX
Ciclo Vida del Software
PPTX
medolos tradicionales de desarrollo de software ( cascada - espiral)
PPT
Proceso Unificado De Rational
DOCX
Casos De Uso
PPT
Presentacion PMBOK
PPTX
Ingenieria de requerimientos
PDF
Cuadro comparativo modelos para el desarrollo de software
PDF
Modelo de desarrollo de software
PPTX
Modelos de software ventajas y desventajas
PPT
13 Clase Flujo De Analisis
PPTX
MODELO COCOMO (INGENIERA DE SOFTWARE)
PDF
Pruebas de software
PPTX
Desarrollo de software basado en lineas de productos
Modelo V
Modelo de Ciclo de Vida de Prototipado Evolutivo
TOGAF - Fase A
Metodologia del rup
Modelos de Ciclos de Vida
Analisis y Diseños de Sistemas 2-Metodologia OOSE
Modelo Cascada y Espiral
Ciclo Vida del Software
medolos tradicionales de desarrollo de software ( cascada - espiral)
Proceso Unificado De Rational
Casos De Uso
Presentacion PMBOK
Ingenieria de requerimientos
Cuadro comparativo modelos para el desarrollo de software
Modelo de desarrollo de software
Modelos de software ventajas y desventajas
13 Clase Flujo De Analisis
MODELO COCOMO (INGENIERA DE SOFTWARE)
Pruebas de software
Desarrollo de software basado en lineas de productos
Publicidad

Similar a Ciclo devida (20)

PPTX
Ciclo de vida del software
PPTX
Analisis y Sistemas
PPT
Tp ciclos de vida
PPTX
CICLOS DE VIDA DEL SOFTWARE
PPTX
Noel barboza
PDF
slide_2.pdf
PPTX
Ciclo de vida del software
PPTX
Modelos de procesos del software
PPTX
Modelos de Procesos del Software
PPT
346785952-1-Ciclo-de-Vida-del-Desarrollo-de-Sistemas-ppt.ppt
PPT
346785952-1-Ciclo-de-Vida-del-Desarrollo-de-Sistemas-ppt.ppt
PPSX
Software Development Life Cycle
PPTX
metodologia
PPTX
Vida de un software
PPTX
software
PPT
MetodologíAs Y Ciclos De Vida
PPTX
introduccion metododologias de analisis y diseño de software
DOCX
CICLO DE VIDA DE UN SOFTWARE
PPTX
Grupo1
PDF
CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE
Ciclo de vida del software
Analisis y Sistemas
Tp ciclos de vida
CICLOS DE VIDA DEL SOFTWARE
Noel barboza
slide_2.pdf
Ciclo de vida del software
Modelos de procesos del software
Modelos de Procesos del Software
346785952-1-Ciclo-de-Vida-del-Desarrollo-de-Sistemas-ppt.ppt
346785952-1-Ciclo-de-Vida-del-Desarrollo-de-Sistemas-ppt.ppt
Software Development Life Cycle
metodologia
Vida de un software
software
MetodologíAs Y Ciclos De Vida
introduccion metododologias de analisis y diseño de software
CICLO DE VIDA DE UN SOFTWARE
Grupo1
CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE
Publicidad

Más de Joan Sebastián Ramírez Pérez (20)

PPTX
PPTX
PPTX
Pruebas automaticas
PPTX
La nube. Cloud computting
PPTX
Control de versiones
PDF
Practicas técnicas
PPTX
PPTX
Roles desarrollo del software
PPTX
Refactor y deuda técnica
PPTX
Diagramas comportamiento
PPTX
Pruebas automaticas

Último (8)

PDF
DIMENSIONADO DE UNA INSTALACION FOTOVOLTAICA.pdf
DOCX
trabajo programacion.docxxdxxxddxdxxdxdxxxdxxdxdxd
PPTX
sistemas de informacion.................
PDF
Su punto de partida en la IA: Microsoft 365 Copilot Chat
PPTX
Derechos_de_Autor_y_Creative_Commons.pptx
PDF
simulacion de teoria de control para maquinas
PDF
modelos de control para sistemas digitales
PDF
AutoCAD Herramientas para el futuro, Juan Fandiño
DIMENSIONADO DE UNA INSTALACION FOTOVOLTAICA.pdf
trabajo programacion.docxxdxxxddxdxxdxdxxxdxxdxdxd
sistemas de informacion.................
Su punto de partida en la IA: Microsoft 365 Copilot Chat
Derechos_de_Autor_y_Creative_Commons.pptx
simulacion de teoria de control para maquinas
modelos de control para sistemas digitales
AutoCAD Herramientas para el futuro, Juan Fandiño

Ciclo devida

  • 1. Ciclo de vida del software joan sebastián ramírez pérez 2016
  • 2. Agenda • ¿Qué es una metodología? • Etapas ciclo de vida del software • Clasificación de las metodologías • Ciclos de vida existentes
  • 3. ¿Qué es una metodología de desarrollo de software? • La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. • Sistematizar hace referencia a dividir el proyecto en etapas. La normalización de estas etapas ayuda a la administración y control del proyecto. • Son los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado.
  • 5. etapas del ciclo de vida • Expresión de necesidades • Especificaciones • Análisis • Diseño • Implementación • Debugging • Validación • Evolución
  • 6. Expresión de necesidades • Esta etapa tiene como objetivo elaborar un documento en el cual se reflejan los requerimientos y funcionalidades que ofrecerá al usuario el sistema a implementar (qué, y no cómo, se va a implementar).
  • 7. Especificaciones • Se formalizan los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta etapa.
  • 8. Análisis • Se identifican los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal, funcionalidades. • Resultado de lo anterior se tendrá una descripción clara de qué producto vamos a construir, qué funcionalidades aportará y qué comportamiento tendrá.
  • 9. Diseño • Ya se identificó qué hacer, ahora se debe determinar cómo hacerlo (¿cómo debe ser construido el sistema en cuestión? • Se debe definir en detalle: entidades y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases de Datos, etc.).
  • 10. Implementación • Se empiezan a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación o para un determinado sistema gestor de bases de datos.
  • 11. Debugging • El objetivo de esta etapa es garantizar que nuestro programa no contiene errores de diseño o codificación. • En esta etapa no se busca saber si nuestro programa realiza lo que solicitó el usuario, esa tarea le corresponde a la etapa de implementación. En ésta se desea encontrar la mayor cantidad de errores. • Todos los programas contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar la mayoría, si no todos, en esta etapa. También se pueden agregar pruebas de rendimiento.
  • 12. Validación • Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente. • En muchos proyectos las etapas de validación y debugging se realizan en paralelo por la estrecha relación que llevan. Sin embargo, tenemos que evitar la confusión: podemos realizarlas en paralelo, pero no como una única etapa.
  • 13. Evolución • En la mayoría de los proyectos se considera esta etapa como mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades (evolución); sino la corrección de errores que surgen (mantenimiento). • En la práctica esta denominación no es del todo errónea, ya que es posible que aún, luego de una etapa de debugging y validación exhaustiva, se filtren errores.
  • 15. Metodologías estructuradas • La orientación de estas metodologías se dirige hacia los procesos que intervienen en el sistema a desarrollar, es decir, cada función a realizar por el sistema se descompone en pequeños módulos individuales. • Es más fácil resolver problemas pequeños, y luego unir cada una de las soluciones, que abordar un problema grande.
  • 16. Metodologías orientadas a objetos • Ésta no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro. • Esto nos permite que el código sea reutilizable. Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes.
  • 18. Ciclos de vida • Ciclo de vida Lineal • Ciclo de vida en V • Ciclo de vida Cascada Puro • Ciclo de vida Cascada con Subproyectos • Ciclo de Vida Iterativo • Ciclo de Vida por Prototipos • Ciclo de vida Evolutivo • Ciclo de vida Incremental • Ciclo de vida en Espiral • Ciclo de vida Orientado a Objetos • Metodologías Ágiles
  • 19. Ciclo de vida Lineal • Se descompone el proyecto en etapas que se ejecutan una tras otra. • Cada etapa es independiente y no hay retroalimentación entre ellas. • Se facilita la gestión y administración. • No apta para proyectos en los cuales se requiere retroalimentación entre sus etapas.
  • 20. Ciclo de vida cascada puro • Creada en 1970 por Winston Royce. • Permite iteraciones y retroalimentación entre sus etapas. • Es rígido, poco flexible y restrictivo. • Apoya a la planificación “simple” y calidad del producto. • Los resultados solo se ven en etapas finales, se requieren todos los requisitos desde el principio y un error en una etapa suele ser costosa para el proyecto. • Debido a las criticas que recibió en los 90, se considera un modelo teórico con poca aplicación en la industria.
  • 21. Ciclo de vida en v • Diseñado por Alan Davis, contiene las mismas etapas del cascada puro solo que añade etapas de validación y verificación. • Goza de las mismas fortalezas y falencias que el cascada puro.
  • 22. Ciclo de vida Cascada con Subproyectos• Se sigue el cascada puro pero se divide el proyecto en sub-etapas independientes que se pueden elaborar en paralelo. • La posibilidad de tener más personas surge como fortaleza. Como desventaja aparece las dependencias que se pueden dar entre sub- etapas.
  • 23. Ciclo de Vida Iterativo • Variación del cascada cuyo fin es minimizar el riesgo entre las necesidades del usuario y el producto final derivados de malos entendidos en la etapa de licitación de requisitos. • Cada iteración se realiza un cascada cuya entrega es una versión mejorada del producto. • El resultado de la interacción es evaluado por el cliente y sometido a mejoras hasta conseguir un producto que satisface las necesidades. • Se usa en proyectos en los cuales los requerimientos no están claros o en los que el cliente puede poner partes del software en producción.
  • 24. Ciclo de Vida por Prototipos • Basado en prototipos como el ciclo de vida iterativo. • Se usa cuando no se conoce el producto o no se tiene certeza sobre las necesidades por parte del cliente. Es común en ideas de innovación o para usar tecnologías nuevas o poco probadas. • Es el modelo preciso cuando se tiene incertidumbre sobre el producto o las tecnologías a usar. • Por su naturaleza se hace difícil la administración de costos y tiempos.
  • 25. Ciclo de vida Evolutivo • Acepta que los requisitos del usuario pueden cambiar en el tiempo. • Afronta la variación de los requisitos en un esquema requerimientos-desarrollo- evaluación. • Es útil cuando desconocemos los requerimientos iniciales o los tenemos incompletos.
  • 26. Ciclo de vida Incremental • Busca construir incrementando las capacidades del software. • Se construye el software por módulos. • Se aplican modelos cascadas por modulo del sistema, lo que permite hacerle entregas al cliente antes de finalizar el proyecto. • En caso de equivocación en la definición se desecha la iteración, sin afectar etapas posteriores. • Es útil cuando el usuario necesita entregas parciales del software.
  • 27. Ciclo de vida en Espiral • Diseñado por Boehm en 1988 como evolución del modelo por prototipos. • Se basa en ciclos repetitivos que se alimentan de la experiencia obtenida hasta llegar al producto final. • Toma los beneficios del incremental y prototipos, pero tiene en cuenta los riesgos asociados a la incertidumbre de los requerimientos. • Cada ciclo que se cumple (avance de espiral) genera prototipos que satisfacen al usuario o al cliente. • Como ventajas presenta que convive con proyectos con alto grado de incertidumbre, bajo riesgo de retraso por detección de errores. • Como desventaja tiene costo en tiempo, costo para evaluar riesgos y alta dependencia con el cliente.
  • 28. Ciclo de vida Orientado a Objetos • Data de la década del 90. • Cada funcionalidad se considera un objeto, las propiedades del requerimiento o funcionalidad se consideran atributos y el comportamiento de los atributos se denomina método. • Los requerimientos son abstractos lo cual le da flexibilidad. • Se favorece la reducción de la complejidad del problema ayudando al perfeccionamiento del producto. • El modelo aplica independiente si el lenguaje que se usará es o no es orientado a objetos.
  • 29. Metodologías Ágiles • Alistar Cockburn resume la agilidad en: entrega continua, colaboración, adaptación y mejora continua.