Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

CICLO DE VIDA Y MODELOS DE DESARROLLO DE SOFTWARE

No description
by

Hellen Rocio

on 4 June 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of CICLO DE VIDA Y MODELOS DE DESARROLLO DE SOFTWARE

Introducción
Durante esta presentación desarrollaremos conceptos relacionados a las metodologías que pueden emplearse a la hora de desarrollar un software, analizáremos los puntos a favor y en contra de cada una, a fin de ser capaces de elegir el método que se adecue más al reto que enfrentamos a la hora de desarrollar un software.
Ciclo de Vida del Software
Metodologías de desarrollo de software
CICLO DE VIDA Y MODELOS DE DESARROLLO DE SOFTWARE
Diferencias, Similitudes, Ventajas y Desventajas
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), es una secuencia estructurada y bien definida de las etapas en Ingeniería de software para desarrollar el producto software deseado.
El propósito es definir las distintas fases intermedias que se requieren para
validar
el desarrollo de la aplicación de modo que el software cumpla los requisitos para la aplicación y
verificar
los procedimientos de desarrollo para confirmar que estos sean apropiados.
Es importante conocer el ciclo de desarrollo de software ya que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación.
CICLO DE VIDA CLÁSICO DEL SOFTWARE
Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.
Análisis de requisitos.
Diseño del Sistema.
Diseño del Programa.
Codificación.
Pruebas.
Verificación.
Mantenimiento.
Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera óptima.
Es un modelo fácil de implementar y entender.
Está orientado a una mejor documentación.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que codificar.

Ventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.
Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.

Desventajas
DESARROLLO EN CASCADA
DESARROLLO EN V
Es una representación gráfica del ciclo de vida del desarrollo de sistemas. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación.

El
 Método-V
 define un procedimiento uniforme para el desarrollo de productos para las TIC. Es el estándar utilizado para los proyectos de
la Administración Federal alemana y de defensa
. Como está disponible públicamente muchas compañías lo usan.

Específica bien los roles de los distintos tipos de pruebas a realizar.
Hace explícito parte de la iteración y trabajo que hay que realizar.
Este método involucra chequeos de cada una de las etapas del método Cascada.
Es un método más robusto y completo que el método cascada y produce software de mayor calidad que con el modelo cascada.
Es un modelo sencillo de y de fácil aprendizaje.
Involucra al usuario en las pruebas.

Ventajas
Es difícil que el cliente exponga explícitamente todos los requisitos.
El cliente debe tener paciencia, ya que obtendrá el producto al final del ciclo de vida.
El modelo no contempla la posibilidad de retornara etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
Se pierde dinero, ya que si algún proceso fue mal desarrollado, este debe ser revisado de nuevo, lo que puede traer como consecuencia un "RollBack" de todo un proceso.
Las pruebas pueden ser caras y a veces no lo suficientemente efectivas.

Desventajas
RATIONAL UNITED PROCESS O PROCESO UNIFICADO RACIONAL
El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
• Es iterativo e incremental.
• Esta basado en los casos de usos.
• Verifica la calidad del software y gestiona sus requisitos.
FASES DE DESARROLLO

Inicio
(Modelado del negocio y los requisitos)

Elaboración
(Analisis y el diseño)

Desarrollo
(Implementacion y pruebas)

Cierre
(Despliegue)

Es el proceso de desarrollo más general de los existentes  actualmente. 
Es una forma disciplinada de asignar tareas y responsabilidades en  una empresa de desarrollo (quién hace qué, cuándo y cómo).
Progreso visible en las etapas tempranas.

Ventajas
Por el grado de complejidad puede ser no muy adecuado.

En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.

Desventajas
Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
DESARROLLO EN ESPIRAL
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
En la utilización de grandes sistemas a doblado la productividad.
Ventajas
Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identificación de riesgosLos pequeños cambios o errores que surgen en el software completo puede causar muchos problemas.
Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.
Desventajas
BIBLIOGRAGIA
http://quecomputadoracomprar.com/ventajas-y-desventajas-modelo-cascada/
https://es.wikipedia.org/wiki/Desarrollo_en_cascada
http://www.slideshare.net/edithcarreno33/modelos-de-software-39682893
http://www.antoniomartel.com/2013/05/ventajas-y-desventajas-de-scrum-i.html
https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)

DESARROLLO SCRUM
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986).

Tareas más pequeñas y abordables harán que nos parezca menos difícil el trabajo y que con cada entrega tengamos la sensación de estar dando un nuevo paso hacia la meta final.
Viendo crecer el producto poco a poco todos vamos a tener una idea de qué estamos haciendo con él y si nos va a ser útil o no.
Con el feedback de los usuarios podríamos darnos cuenta de que hay nuevas funcionalidades que son mucho más importantes que el 80% de las tareas que aún teníamos por hacer en la pila del producto. Alguien puede decirnos "pero si el borrador del nuevo decreto ya no exige la entrega de la autorización firmada" o "en realidad lo que necesitamos es un botón para poder cancelar el trámite" .

Ventajas
Puede surgir la tentación de resolver las tareas pendientes de cualquier manera y dejar 'deudas' técnicas en el trabajo.
¿Necesitas con mucha antelación fechas exactas de entrega? Esta es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al inicio del proyecto no puedes predecir cuando lo vas a acabar si estás facilitando que lo que se va a construir cambie y varíe en el tiempo.
Se necesita contar con un equipo auto-organizado y auto-gestionado, capaz de tomar decisiones que avancen el proyecto.

Desventajas
GENERALIDADES
SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con el.
METODOLOGÍA ÁGIL vs METODOLOGÍA TRADICIONAL
COMPARACIONES ENTRE METODOLOGÍAS
CONCLUSIÓN
Luego de recorrer esta presentación hemos desarrollado conocimientos que nos ayudarán a la hora de escoger la metodología adecuada para desarrollar
el software deseado, conociendo los riegos y factores que debemos tomar en cuenta, como lo son la claridad del cliente en cuanto al proyecto y el tiempo en que debe estar listo.
Francis Omar - 20150405
Kendys Acosta - 20150232
Josue Perez - 20150413
Hellen Valenzuela - 20130672
INTEGRANTES
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
UNIVERSIDAD APEC
Full transcript