metodologias cascada vs v
Descargar como PPTX, PDF0 recomendaciones2,633 vistas
1. El modelo en V es conocido como el modelo de cuatro niveles y representa el proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. 2. Las cuatro etapas son análisis de requisitos y especificación, análisis funcional, arquitectura del sistema e implementación. 3. La parte izquierda de la V representa la definición de especificaciones mientras que la parte derecha representa la verificación contra las especificaciones definidas.
metodologias cascada vs v
- 1. { ESCUELA SUPERIOR POLITECNICA DE CHIMBORAZO FACULTAD DE MECANICA ESCUELA DE INGENIERIA INDUSTRIAL CATEDRA DE PROGRAMACION ING. Luis vaca lema ch juan Carlos 2014-04-03 Metodología de desarrollo de software. El modelo en cascada vs El Modelo en V
- 2. El Modelo en V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo. La figura que aparece a continuación presenta el Modelo en V, o Modelo de Cuatro Niveles, del ciclo de vida de un proyecto de desarrollo de software. Las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto. Es el más conocido, está basado en el ciclo convencional de una ingeniería, Es un modelo sencillo (para explicar al cliente). También llamado ciclo de vida clásico, sugiere un enfoque sistemático secuencial en el desarrollo del software. Requiere que los requerimientos estén bien definidos y estables en forma razonable. Es el paradigma más antiguo para la Ingeniería del Software.
- 3. Ingeniería y Análisis del Sistema Análisis de los Requisitos Diseño Codificación Prueba Mantenimiento
- 4. ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DETALLADO IMPLEMENTACION DE PROGRAMAS Y PRUEBA UNITARIA PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO PRUEBA DE INTEGRACION Plan de Pruebas de Integración Verificar diseño Plan de Pruebas del Sistema Validar requerimientos Plan de Pruebas de Aceptación Los planes de prueba son el nexo entre el desarrollo y la verificación
- 5. Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. Análisis de los requisitos del software: El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz.
- 6. Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Prueba: La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren Mantenimiento: El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
- 7. La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema. La parte derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas en la parte izquierda). La parte de abajo, donde se encuentran ambas partes, representa la corriente de desarrollo.
- 8. 1. El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones. 2. El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional. 3. El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema. 4. El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.
- 9. Es el más utilizado. Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. Para que el proyecto tenga éxito deben desarrollarse todas las fases. Las fases continúan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final será de inferior calidad El modelo en V. es conocido como el modelo de cuatro niveles 1. Análisis de requisitos y especificación 2. Análisis funcional 3. Arquitectura del sistema 4. Implementación
- 10. La planificación es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco cualificado Se trata de un proceso ideal, por su robustez, para proyectos pequeños, con equipos de una a cinco personas. También es ideal, por su claridad, para toda esa gente que nunca ha programado siguiendo una metodología. Para el proyecto final de carrera o para ese cliente que te ha conseguido un amigo que te lo pide a ti y no se dirige a una empresa por mayor comodidad
- 11. No refleja realmente el proceso de desarrollo del software Se tarda mucho tiempo en pasar por todo el ciclo El mantenimiento se realiza en el código fuente Las revisiones de proyectos de gran complejidad son muy difíciles Cada fase tiene que estar respaldada por su documento correspondiente y test, se habla de una amplia documentación, se debe realizar dos procesos al mismo tiempo, es difícil que el cliente exponga explícitamente todos los requisitos, el cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida, las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas, el producto final obtenido puede que no refleje todos los requisitos del usuario.