16

Modelo

Embed Size (px)

Citation preview

Page 1: Modelo
Page 2: Modelo

INTRODUCCION

En ingeniería de software el desarrollo

en cascada también llamado modelo en

cascada es el enfoque metodológico

que ordena rigurosamente la etapas del

ciclo de vida del software.

Page 3: Modelo

DESARROLLO EN CASCADA

Ingeniería y Análisis

del Sistema

Análisis de los

Requisitos

Diseño

Codificación

Prueba

Mantenimiento

Page 4: Modelo

INGENIERIA Y ANALISIS 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

Page 5: Modelo

ANALISIS DE REQUISITOS

el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software.

De esta fase surge una memoria llamada SRD(Documento de especificación de requisitos ) contiene especificación completa de lo que debe hacer el sistema.

El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

Page 6: Modelo

Utilidad de la Especificación

Requisitosdel Software

Documentode Especificación

de Requisitos

Contrato conel Cliente

Guía para losdesarrolladores

Page 7: Modelo

Cualidades y Principios

La especificación de

requisitos debe

tener las siguientes

cualidades:

comprensible,

precisa, completa y

consistente,

no ambigua.

Los principales

principios a aplicar:

separación de intereses

○ distintos puntos de

vista,

abstracción

○ de lo general a los

detalles,

modularización

○ datos, funciones y

control

Page 8: Modelo

DISEÑO

Como resultado surge el SDD(Documento de Diseño de Software)

El diseño describe cómo hará el sistema para satisfacer sus requisitos.

Es la descomposición del sistema en componentes.

Arquitectura del sistema:

¿qué hacen las componentes?

¿cómo interactúan?

Las componentes más grandes son divididas iterativamente en sub-componentes:

diseño de alto nivel,

diseño detallado.

Page 9: Modelo

CODIFICACION

El diseño debe traducirse en una forma

legible para la maquina. El paso de

codificación realiza esta tarea.

Si el diseño se realiza de una manera

detallada la codificación puede

realizarse mecánicamente.

Se crean librerías ,componentes y

bibliotecas.

Page 10: Modelo

PRUEBA

una vez que se ha generado el código

comienza la prueba del programa. 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.

Page 11: Modelo

Las empresas pueden establecer estándares de pruebas:

definición de un plan de pruebas,

criterios de pruebas (caja negra, caja blanca),

criterios de fin de las pruebas,

administración de los casos de prueba.

La depuración (“debugging”) es parte de esta etapa.

Es el control de calidad llevado a cabo en esta etapa.

Inspecciones para comprobar adhesión a los estándares.

Page 12: Modelo

• Existen varios tipos de

Pruebas:

1. Pruebas de unidad

2. Pruebas de integración

3. Pruebas de sistema.

4. Pruebas de aceptación

Page 13: Modelo

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.

Page 14: Modelo

Tipos de mantenimientos:

Mantenimiento Preventivo y Perfectivo

Mantenimiento Correctivo

Mantenimiento Evolutivo

El análisis de requisitos es una fuente de problemas, especialmente para los usuarios finales: los requisitos son difíciles de especificar,

los requisitos cambian con el tiempo.

Muchos errores no son resueltos hasta después de instalar el software en el cliente: es más caro corregir errores cuanto más tarde se

detectan.

Los cambios son (casi) siempre posibles pero también (casi) siempre muy difíciles

Page 15: Modelo

VENTAJAS

Se tiene todo bien organizado y no se

mezclan las fases.

Es perfecto para proyectos rígidos y

además donde se especifiquen bien los

requerimientos y conozca muy bien las

herramientas a utilizar.

Page 16: Modelo

Críticas al Modelo de

Cascada El modelo de Cascada tiene dos grandes

aportes: debe aplicarse disciplina, planificación y

administración al proceso de desarrollo de software,

la construcción del sistema en sí se pospone hasta que los objetivos del sistema sean suficientemente comprendidos.

Pero tiene también serias desventajas: lineal

rígido