Modelo Lineal o de Cascada Presentan:

- Itzel Aylin Rodríguez Rincón

- María Fernanda Salamanca Alejandro

- Jorge Iván Márquez García

EQUIPO 1

MODELO LINEAL SECUENCIAL (CASCADA)

• También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en el "Modelo de cascada" ingeniado por Winston Royce, aunque omite los muchos bucles de este último. El Modelo Lineal Secuencial sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

GRÁFICO DEL MODELO LINEAL SECUENCIA "CASCADA"

Análisis de los requerimientos del software

• Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.

Diseño

• Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software.

Generación del código

• Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.

Pruebas

• Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.

Mantenimiento

• Debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios.

• El Modelo Lineal Secuencial es el paradigma de desarrollo de software más antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de él basada en los siguientes errores reales:

• Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.

• A menudo es difícil que el cliente exponga exactamente todos los requisitos.

• El cliente debe tener paciencia.

• Los responsables del desarrollo de software siempre se retrasan innecesariamente. Todo lo anteriormente expuesto es cierto pero este paradigma tiene un lugar bien definido e importante en el trabajo de la Ingeniería de Software aparte de proporcionar una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento. Con todo y sus errores, sigue siendo el paradigma más utilizado en el desarrollo del software, siendo mucho mejor que un enfoque al azar.

Características del modelo

• Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico y modelo lineal secuencial.

• Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre al modelo.

• Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada.

• Una fase no comienza hasta que la anterior ha terminado.

• Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.

• Se disponga de unos requisitos completos y consistentes al principio del desarrollo.

• Sea un proyecto pequeño, en el que el período de congelación de los requisitos es corto, o un proyecto con unos requisitos bastante estables.

Ventajas

• Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.

• Facilita la gestión del desarrollo.

Desventajas

• En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable, Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema funcionando.

• Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia.

• El usuario debe esperar mucho tiempo hasta ver los resultados

• Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve.

• Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y éste recae, en su mayor parte.

Ejemplos

• Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran tamaño, en especial en el Departamento de Defensa de los Estados Unidos (DOD).

• Es utilizado en la NASA.

¿Por qué a veces falla el modelo Lineal?

• Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.

• A menudo es difícil que el cliente exponga explícitamente todos los requerimientos.

• El cliente debe tener paciencia. Un grave error puede ser desastroso

• Cada uno de estos errores es real. Sin embargo el paradigma del ciclo de vida clásico tiene lugar definido e importante trabajo de la ingeniería del software.

Conclusión

• La metodología de cascada ordena rigurosamente las etapas del ciclo del software, es decir en este modelo se tienen que terminar las fases en un orden, Lo que puedo mencionar es que el modelo cascada es un modelo que al llevarse a cabo se debe de llevar fase por fase para poder pasar a la siguiente etapa.

• El modelo de cascada es exitoso cuando se tienen bien especificados los requerimientos del software y se conozcan las herramientas a utilizar, este modelo también nos permite realizar una organización más fácil de comprender tratando de no mezclar las diferentes fases del modelo y así nos permite organizar el tipo de proyecto que pretende solucionar es decir donde se conozcan todos los requisitos especificados durante su ejecución

Modelo Lineal

MODELO PROTOTIPO Francisco Amador Lazcano

Julio Andrei Claudio Domínguez

Oscar Edgar Teutli López

Maria Fernanda Cano Romero

EQUIPO 2

DEFINICION

• Conocido como desarrollo con prototipación o modelo de desarrollo evolutivo se inicia con la definición de los objetivos globales para el software, posteriormente se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición.

• Este modelo se utilizan para dar al usuario una vista preliminar de parte del software.

https://www.ecured.cu/index.php?title=Prototipaci%C3%B3n&action=edit&redlink=1https://www.ecured.cu/Softwarehttps://www.ecured.cu/Usuariohttps://www.ecured.cu/Software

ETAPAS DEL MODELO

• Recolección y refinamiento de requisitos

• Modelado, diseño rápido

• Construcción del Prototipo

• Desarrollo, evaluación del prototipo por el cliente

• Refinamiento del prototipo

• Producto de Ingeniería

https://www.ecured.cu/index.php?title=Requisitos&action=edit&redlink=1https://www.ecured.cu/Clientehttps://www.ecured.cu/Ingenier%C3%ADa

Representación física

Cómo se lleva a cabo

• Se elabora un prototipo del producto final: qué aspecto tendrá, cómo funcionará.

• Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final.

• Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina.

https://www.ecured.cu/Interfaceshttps://www.ecured.cu/Usuariohttps://www.ecured.cu/Dibujohttps://www.ecured.cu/Hardwarehttps://www.ecured.cu/Cauchohttps://www.ecured.cu/Cart%C3%B3nhttps://www.ecured.cu/Cartulina

VENTAJAS

• No modifica el flujo del ciclo de vida.

• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.

• Reduce costo y aumenta la probabilidad de éxito.

• Exige disponer de las herramientas adecuadas.

• Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

• También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

https://www.ecured.cu/index.php?title=Ciclo&action=edit&redlink=1https://www.ecured.cu/Riesgohttps://www.ecured.cu/index.php?title=Costo&action=edit&redlink=1https://www.ecured.cu/Herramientashttps://www.ecured.cu/Softwarehttps://www.ecured.cu/Algoritmohttps://www.ecured.cu/Sistema_operativo

Para que sea efectivo

• Debe ser un sistema con el que se pueda experimentar.

• Debe ser comparativamente barato(menor que el 10%).

• Debe desarrollarse rápidamente.

• Énfasis en la interfaz de usuario.

• Equipo de desarrollo reducido.

• Herramientas y lenguajes adecuadas.

https://www.ecured.cu/Sistemahttps://www.ecured.cu/Interfazhttps://www.ecured.cu/Usuariohttps://www.ecured.cu/index.php?title=Lenguajes&action=edit&redlink=1

DESVENTAJAS DEL MODELO

• Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.

• El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente

https://www.ecured.cu/Softwarehttps://www.ecured.cu/Sistema

TIPOS DE MODELO DE PROTOTIPOS

• Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.

• Modelo de Prototipos reutilizable: Conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real.

Mayormente es utilizado en el desarrollo de software, si bien determinados productos de hardware pueden hacer uso del prototipo como la base del diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles.

• Modelo de Prototipos Modular: También conocido como Prototipado Incremental (Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.

https://www.ecured.cu/Softwarehttps://www.ecured.cu/Hardwarehttps://www.ecured.cu/index.php?title=Fabricaci%C3%B3n&action=edit&redlink=1https://www.ecured.cu/Dise%C3%B1o

• Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.

• Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.

• Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar tests baratos.

• Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto, impresiones, interacción y tiempo.

INCONVENIENTES

• El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

Prototipo Operacional

• Es aquel prototipo iterativo que es progresivamente refinado hasta que se convierte en el sistema final.

• Combina las ventajas de los prototipos desechables y evolutivos.

• Resultados rápidos sin perder calidad.

• Se aplican bien en sistema de gran escala.

Utiliza p. desechables para obtener o clarificar requisitos poco definidos.

Utiliza p. evolutivo para implementar los requisitos bien definidos.

¿Cómo desarrollamos nuestro prototipo?

• Antes de acudir a alguien para que nos explique o ayude nosotros ya debemos de saber que es lo que queremos y que explicaciones deseamos tener, exactamente con todas las explicaciones y especificaciones posibles.

Debes de ser paciente, y educarte a ti mismo, ya que este es un proceso extenso, de tal manera de que lo entiendas y de qué habla la persona que se encuentra al otro lado de la bocina.

Preguntas al fabricante

• Una vez que identificaste a un buen proveedor, pide que te muestre su portafolios para que veas qué clase de trabajos ha hecho y quiénes han sido sus clientes. De esta manera, podrás verificar que tiene la experiencia y capacidad para realizar todo lo que requieres.

• Por ejemplo, una alarma para detección de humo no es un producto complicado, aunque tiene algunos aspectos complejos. Quizás encuentres un taller de prototipos en donde puedan elaborar la estructura externa, pero no sepan nada de electrónica o la manera en que ésta se interrelaciona con el armazón.

¿Qué podemos esperar en términos del tiempo y el costo de desarrollar un producto?

• Es difícil definir la estructura de un acuerdo porque depende de diferentes factores y de qué tan bien preparado estés. Por lo general, las compañías que se dedican a hacer prototipos establecen tarifas por hora o por proyecto. Mientras más complejo sea el trabajo y más asesoría y dirección requieras, más tiempo tomará desarrollarlo y más alto será el costo.

¿Qué pasa si tu prototipo no despega?

• Muchos emprendedores no superan esta etapa y sus prototipos terminan como una bonita pieza de decoración en el librero de su casa, en lugar de convertirse en un producto exitoso en el mercado. En cierto punto todos debemos caminar hasta el final del trampolín, saltar y esperar que haya agua en la alberca.

3º EQUIPO

INTEGRANTES:

Carlos Coyotl Coyotl

Omar González García

Monica Pérez Méndez

MODELO ESPIRAL

Propuesto en 1988 por Barry Boehm

Reconoce la naturaleza iterativa del desarrollo y combina actividades de desarrollo con gestión de riesgo, para minimizar y controlar el riesgo.

Proporciona el potencial para el desarrollo rápido de versiones incrementales del software.

CARACTERISTICAS

Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.

Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s.

La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.

Este es el enfoque más realista actualmente.

MODELO DE BEHM

ANÁLISIS DEL RIESGO

En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen

los pasos a seguir para reducir los riesgos y luego del análisis de estos

riesgos se planean estrategias alternativas.

DETERMINAR O FIJAR LOS OBJETIVOS:

En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software

PLANIFICAR. En este último paso es donde el proyecto se

revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la

espiral.

DESARROLLAR Y PROBAR

Después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.

MODELO DE SEIS REGIONES

PLANIFICACIÓN Esta tarea es necesaria aplicarla para pode definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.

COMUNICACIÓN CON EL CLIENTE

Esta es una tarea requerida para establecer comunicación entre el

desarrollador y el cliente.

ANÁLISIS DE RIESGOS

Esta es una de las tareas principales por lo que se aplica el modelo en espiral, es

requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.

INGENIERÍA: Esta es una tarea necesaria ya

que se requiere construir una o más representaciones de la

aplicación.

CONSTRUCCIÓN Y ENTREGA

Esta tarea es requerida en el modelo espiral porque se necesita construir,

probar, instalar y proporcionar soporte al usuario.

EVALUACIÓN EL CLIENTE

Esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.

ESPIRAL WIN-WIN

Es una adaptación del modelo de espiral y define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral.

Basado en la teoría W, que es una teoría de gestión de sistemas, se basa en el principio que el proyecto solo es exitoso si y solo si todos los implicados resultan ganadores.

El modelo “win-win”. deriva su nombre del objetivo de estas negociaciones, es decir, de "ganar-ganar".

ACTIVIDADES DE NEGOCIACION

Identificación del sistema o subsistemas clave de los directivos.

Determinación de las condiciones de victoria de los directivos.

Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados

VENTAJAS

No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.

En la terminación de un producto desde el final de la primera

iteración es muy factible aprobar los requisitos. Sufrir retrasos corre un riesgo menor, por que se comprueban los

conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.

DESVENTAJAS

Existe complicación cuando se evalúa los riesgos. Se requiere la participación continua por parte del

cliente. Se pierde tiempo al volver producir inicialmente una

especificación completa de los requerimientos cuando se modifica o mejora el software.

CONCLUSIÓN

El prototipo del modelo en espiral para la ingeniería de software es en la actualidad el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel del modelo en espiral. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

Programación Extrema Mario Alberto Duarte Zamora

Daniel Hernández Vega

Eduardo Antonio Pérez Rodríguez

Luis Roberto Andrade Galindo

EQUIPO

4

Formulado por Kent Beck

¿En que se basa esta metodología?

• Se basa en realimentación continua entre el cliente y el equipo de desarrollo

• comunicación fluida entre todos los participantes

• Simplicidad en las soluciones implementadas

• Coraje para enfrentar los cambios.

¿Qué es?

Metodología liviana de

desarrollo de software.

Conjunto de practicas y

reglas empleadas para

desarrollar software.

Basada en diferentes

ideas acerca de cómo

enfrentar ambientes

muy cambiantes.

Originada en el proyecto

C3 para Chrysler.

Hacer todo esto un poco

cada vez, a través de

todo el proceso de

desarrollo

Objetivos

• Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.

• Mejorar la productividad de los proyectos.

• Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Contexto

• Cliente bien definido.

• Los requisitos pueden (y van a) cambiar.

• Grupo pequeño y muy integrado (máximo 12 personas).

• Equipo con formación elevada y capacidad de aprender.

Desarrollo iterativo e incremental

• En cada iteración el equipo evoluciona el producto (hace una

entrega incremental) a partir de los resultados completados en las

iteraciones anteriores, añadiendo nuevos objetivos/requisitos o

mejorando los que ya fueron completados.

Pruebas unitarias continuas

• Esto sirve para asegurar que cada unidad funcione correctamente

y eficientemente por separado. Además de verificar que el código

hace lo que tiene que hacer, verificamos que sea correcto el

nombre, los nombres y tipos de los parámetros, el tipo de lo que

se devuelve, que si el estado inicial es válido entonces el estado

final es válido

Programación en parejas

• Se supone que la mayor calidad

del código escrito es de esta

manera, el código es revisado y

discutido mientras se escribe es

más importante que la posible

pérdida de productividad

inmediata.

Programar y probar es más rápido que sólo programar.

• Tendrás menos errores

• Tendrás que volver menos veces sobre el código

• Te costará menos localizar los errores,

• perderás menos tiempo escuchado como tus clientes te dicen que no funciona.

Corrección de errores

Hacer entregas

frecuentes.

Realizar

correcciones antes

de agregar una

nueva

funcionalidad.

Analizar el código

para asegurarse

de que todo

marche bien

Integración con el cliente

Alinear

tus equipos.

Entender a

tus clientes.

Cerrar tratos con

más rapidez.

Refactorización del código

• rescribir ciertas partes del código para aumentar su legibilidad y

mantenibilidad pero sin modificar su comportamiento.

• Las pruebas han de garantizar que en la refactorización no se ha

introducido ningún fallo.

Propiedad del código compartida

• En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto.

Las frecuentes pruebas de regresión

garantizan que los posibles errores serán

detectados.

Simplicidad

• La programación extrema apuesta que es más sencillo hacer algo

simple y tener un poco de trabajo extra para cambiarlo si se

requiere, que realizar algo complicado y quizás nunca utilizarlo.

La Simplicidad y la Comunicación son extraordinariamente

complementarias. Con más comunicación resulta más fácil identificar

qué se debe y qué no se debe hacer.

Ventajas y Desventajas

• Esta claro que las Ventajas que nos ofrece el utilizar metodologías ágiles, en especial y en este caso XP, están por arriba de las Desventajas.

• Como se podrá notar, realmente podemos tomar como “desventajas” solamente, el hecho de que tal vez no todos los proyectos se adapten a esta metodología.

Ventajas

• Da lugar a una programación sumamente organizada.

• Ocasiona eficiencias en el proceso de planificación y pruebas.

• Cuenta con una tasa de errores muy pequeña.

• Propicia la satisfacción del programador.

• Fomenta la comunicación entre los clientes y los desarrolladores.

• Facilita los cambios.

• Permite ahorrar mucho tiempo y dinero.

• Puede ser aplicada a cualquier lenguaje de programación.

• El cliente tiene el control sobre las prioridades.

• Se hacen pruebas continuas durante el proyecto.

• La XP es mejor utilizada en la implementación de nuevas tecnologías.

Desventajas

• Es recomendable emplearla solo en proyectos a corto plazo.

• En caso de fallar, las comisiones son muy altas.

• Requiere de un rígido ajuste a los principios de XP.

• Puede no siempre ser más fácil que el desarrollo tradicional.

Gracias por su atención

Modelo V José Javier Quiroga Méndez.

Jessica Guadalupe Santos Rodríguez.

Jesús Flores Cuautle.

Gustavo Pajarito Coyotecatl.

EQUIPO 5

•¿Qué es el modelo v?

• Representación grafica del ciclo de la vida del desarrollo de un sistema, variación del modelo de cascada.

• La codificación forma el vértice de la V, el análisis y el diseño están de lado izquierdo y las pruebas y el mantenimiento de lado derecho

• Relaciona la prueba del análisis y el diseño del proyecto.

• Describe las actividades y resultados que deben producirse.

¿Qué significa la V?

Lado izquierdo:

representa la descomposición de las necesidades, y la creación de las especificaciones del sistema.

Especificaciones

• Especificaciones de requerimiento de usuario.

• Especificaciones funcionales.

• Especificaciones de diseño.

Lado derecho:

Representa la integración de las piezas y su verificación.

Corriente de pruebas

• Calificación de instalación.

• Calificación de operación.

• Calificación de rendimiento.

Parte de abajo:

Representa la corriente de desarrollo.

Partes del método

Corrientes de especificación:

• Conceptos de operaciones.

• Requisitos del sistema y arquitectura del mismo diseño detallado.

Partes del método

La corriente de pruebas:

• Integración de las distintas partes , test y verificación de las mismas.

•Verificación y validación del sistema en conjunto.

•Mantenimiento del sistema.

Objetivos

• Minimizar los riesgos del proyecto.

• Mejorar y garantizar la calidad del proyecto.

• Reducir los costos totales a lo largo del ciclo de vida del proyecto.

• Mejorar la comunicación entre los stakeholders.

Niveles lógicos del 1 al 4

• Para cada fase debe existir un resultado verificable.

• En la misma estructura, se advierte que la proximidad entre una fase de desarrollo y su fase de verificación, va decreciendo a medida que aumenta el nivel dentro de la V.

NIVEL 1: orientado al cliente.

Nivel 2: dedicado a las características funcionales del

sistema propuesto.

Nivel 3: define los componentes hardware y software del

sistema final.

Nivel 4: implementación.

Fases de verificación

• Análisis de requisitos.

• Diseño del sistema.

• Diseño de modulo.

Fases de validación

• Prueba de unidas.

• Prueba de integración.

• Prueba del sistema.

• Prueba de aceptación de usuario.

Ventajas

• Modelo sencillo y de fácil aprendizaje.

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.

• Especifica los roles de los distintos tipos de pruebas a realizar.

• Involucra al usuario en las pruebas.

Desventajas

• El cliente debe tener paciencia.

• Las pruebas pueden ser caras.

• El producto final obtenido puede que no refleje todos los requisitos del usuario.

• No se puede repetir la secuencia de pasos si este no sale bien.

Retroalimentación

• ¿Para qué sirve el modelo V?

Regular el proceso de desarrollo de software. describe las actividades y los resultados que se producen durante su desarrollo

• ¿En qué casos los utilizo?

Por su robustez, para proyectos de una a cinco personas.

• ¿Cuál es su finalidad?

Los proyectos lleguen a ser exitosos desde los puntos de vista de objetivos de negocio, costo, funcionalidad sencillez y capacidad de soporte.

• ¿Se tiene qué hacer documentación de todo?

Por supuesto. Cada fase debe estar respaldada por su documento correspondiente y test.

• ¿Por qué usar una metodología?

Es mucho mas rápido y con un costo mas bajo.

Conclusión

• El modelo V fue desarrollado para regular el proceso de extensión de un proyecto, proporciona una guía para la planificación y realización de estos, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada, permite una detección temprana de las desviaciones y los riesgos, mejora la gestión de procesos, reduciendo así los riesgos del proyecto, reduce los gastos totales durante todo el proyecto y sistema de ciclo de vida.

MODELO POO Jesús Asdrid

David Techachal

Gabriela Rodríguez

Equipo Numero Seis

¿Qué es la programación orientada a objetos?

•La programación orientada a objetos es otra forma de descomponer problemas.

Este nuevo método de descomposición es la descomposición en objetos; vamos a fijarnos no en lo que hay que hacer en el problema, sino en cuál es el escenario real del mismo, y vamos a intentar simular ese escenario en nuestro programa.

¿QUÉ ES UN OBJETO?

Un objeto no es más que un conjunto de variables (o datos) y métodos (o

funciones) relacionados entre sí. Los objetos en programación se usan para

modelar objetos o entidades del mundo real.

EJEMPLO DE OBJETOS

Ventajas de POO

Capacidad de crear módulos:

•El código fuente de un objeto puede escribirse y mantenerse independiente del código fuente del resto de los objetos. De

esta forma, un objeto puede pasarse fácilmente de una parte a otra del

programa. Podemos dejar nuestra bicicleta a un amigo, y ésta seguirá funcionando.

Ventajas de POO

Protección de información:

Un objeto tendrá una interfaz pública perfectamente definida que otros objetos podrán usar para comunicarse con él. De esta forma, los objetos pueden mantener información privada y

pueden cambiar el modo de operar de sus funciones miembros sin que esto afecte a otros

objetos que usen estas funciones miembro.

Desventajas de POO

•No todos los programas pueden ser modelados con exactitud por el modelo de objetos. Si lo que deseas es leer algunos datos, hacerles algo simple y escribir de

nuevo, no tienes necesidad de definir clases y objetos. Sin embargo, en algunos

lenguajes de POO, puede que tengas que realizar este paso extra.

Desventajas de POO

si se fuerza el lenguaje en el concepto de programación orientada a objetos, se pierden algunas de las características de lenguajes útiles, como los "lenguajes funcionales"

Desventaja de POO

Otra desventaja el que concepto que un programador tiene de lo que

constituye un objeto abstracto puede no coincidir con la visión de otro

programador. Los objetos a menudo requieren una extensa

documentación

¿QUÉ ES UN MENSAJE?

un objeto aparece como un componente más de un programa o una aplicación que contiene otros

muchos objetos.

Los objetos de un programa interactúan y se comunican entre ellos por medio de mensajes. Cuando un objeto A quiere que otro objeto B

ejecute una de sus funciones miembro (métodos de B), el objeto A manda un mensaje al objeto B

¿QUÉ ES UNA CLASE?

Normalmente en el mundo real existen varios objetos de un mismo tipo, o como diremos enseguida, de una misma clase.

Una clase es una plantilla que define las variables y los métodos que son comunes para todos los objetos de un cierto tipo.

EJEMPLO

Mi bicicleta es una instancia de la clase de objetos conocida como bicicletas

EJEMPLO DE CLASE

HERENCIA

El mecanismo de herencia permite definir nuevas clases partiendo de otras ya existentes. Las clases que derivan de otras heredan automáticamente todo su comportamiento, pero además pueden introducir características particulares

propias que las diferencian.

EJEMPLO DE HERENCIA

ABSTRACCIÒN

Se define como las características especificas de un objeto, aquellas

que lo distinguen de los demás tipos de objetos y que logran definir límites conceptuales respecto a

quien está haciendo dicha abstracción del objeto.

TIPOS DE ABSTRACCIÒN

•Abstracción de Entidades: Es un objeto que representa un modelo útil de una entidad

que se desea.

•Abstracción de Acciones: Un objeto que representa un conjunto de operaciones y

todas ellas desempeñan funciones del mismo tipo.

TIPOS DE ABSTRACCIÒN 1.1

• Abstracción de Máquinas virtuales: Un objeto que agrupa operaciones, todas ellas virtuales, utilizadas por algún nivel superior de control u

operaciones (entre ellos podríamos hablar de un circuito).

• Abstracción de coincidencia: Un objeto que almacena un conjunto de operaciones que no

tienen relación entre sí.

POLIMORFISMO

•la capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su

invocación.

POLIMORFISMO 1.1

En algunos lenguajes, el término polimorfismo es también conocido como ‘Sobrecarga de parámetros’ ya que las características de los objetos permiten

aceptar distintos parámetros para un mismo método (diferentes implementaciones)

EJEMPLO POLIMORFISMO

FIN