Modelo Cascada, Espiral,incremental

INSTITUTO TECNOLOGICO SUPERIOR DE CENTLA ING. SISTEMAS COMPUTACIONALES FUNDAMENTOS DE DESARROLLO DE SISTEMAS MAESTRO: ALUMNA:

WILVER POTENCIANO MORALES

CHRISTIAN JOVANA TZEC HERNANDEZ 1

INDICE • • • •

• • • • • • • • • • • •

INTRODUCCION=======================• MODELO EN CASCADA================= • DESCRIPCION======================== • ESTRUCTURA=========================• CARACTERISTICA===================== • VENTAJAS============================ • DESVENTAJAS======================== • MODELO ESPIRAL===================== • DESCRIPCION======================== • ESTRUCTURA======================== • CARACTERISTICAS==================== • VENTAJAS============================ • DESVENTAJAS======================== • MODELO INCREMENTAL=============== • DESCRIPCION ======================= • ESTRUCTURA======================== •

4 5 6 7 10 11 12 13 14 15 19 20 21 22 23 24 2

• •

• • • • • • • • • • • •

VENTAJAS============================ • PROCESO DEL DESARROLLO UNIFICADO==== • DESCRIPCION======================== • ESTRUCTURA=========================• CARACTERISTICAS==================== • PROCESO DEL SOFTWARE PERSONAL=== • DESCRIPCION======================== • PRINCIPIOS========================== • OBJETIVOS ========================== • DESVENTAJAS======================== • VENTAJAS============================ • NIVELES============================= • CONCLUSION========================= • BIBLIOGRAFIA======================== •

25 26 27 28 32 33 34 36 37 38 39 40 42 43

3

INTRODUCCION Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

4

5

DESCRIPCION

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.

6

Estructura Modelo en Cascada(Bennington 1956) El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento

7

•

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.

8

•

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.

9

CARACTERISTICAS •

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. 10

VENTAJAS •

La planificación es sencilla.

•

La calidad del producto resultante es alta.

•

Permite trabajar con personal poco cualificado.

11

DESVENTAJAS •

No refleja realmente el proceso de desarrollo del software

•

Se tarda mucho tiempo en pasar por todo el ciclo

•

Perpetua el fracaso de la industria del software en su comunicación con el usuario final

•

El mantenimiento se realiza en el código fuente

•

Las revisiones de proyectos de gran complejidad son muy difíciles

•

Impone una estructura de gestión de proyectos

12

13

DESCRIPCION Propuesto inicialmente por Boehm en 1988.

•

Desarrollo cíclico (iterativo) donde en cada ciclo se llevan a cabo 4 tareas:

– Determinación de objetivos, alternativas y restricciones – Evaluación de alternativas, análisis y control de riesgos. – Desarrollo y verificación del producto.

– Planificación del siguiente ciclo (fase).

•

Cada ciclo corresponde a una fase del proyecto.

. 14

Un representación típica de esta estructura:

15

16

En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

•

Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.

•

Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos

puntos de vista – Características del producto. – Formas de gestionar el proyecto.

•

Restricciones: – Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc. – Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

17

•

Riesgos: Lista de riesgos identificados.

•

Resolución de riesgos: La técnica más usada es la construcción de prototipos.

•

Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.

•

Planes: Lo que se va a hacer en la siguiente fase.

•

Compromiso: Decisiones de gestión sobre como continuar.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

18

CARACTERISTICAS •

En cada giro se construye un nuevo modelo del sistema completo.

•

Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo)

•

Mejor modelo para el desarrollo de grandes sistemas.

•

El análisis de riesgo requiere la participación de personal con alta cualificación.

19

VENTAJAS •

No necesita una definición completa de los requisitos para empezar a funcionar.

•

Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.

•

El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos

invertidos en una iteración (las anteriores iteraciones están bien). •

El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

20

DESVENTAJAS •

Es difícil evaluar los riesgos.

•

Necesita de la participación continua por parte del cliente.

•

Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y

esto lleva tiempo.

21

22

DESCRIPCION •

Combina elementos del modelo lineal con la filosofía de creación de prototipos.

•

El primer incremento a menudo es un producto esencial (núcleo).

•

A partir de la evaluación se planea el siguiente incremento y así sucesivamente.

•

Es interactivo por naturaleza

•

Es útil cuando el personal no es suficiente

•

para la implementación completa

23

Representación grafica:

24

VENTAJAS •

Se puede financiar el proyecto por partes

•

Apropiado para proyectos grandes de larga duración

•

No se necesita tanto personal al principio como para una implementación completa

25

26

DESCRIPCION El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad.

El proceso de desarrollo constituye un marco metodológico que define en términos de metas

estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo. Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas.

27

Estructura del ciclo de vida del proceso de desarrollo unificado: Fases Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.

28

Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

29

Disciplinas

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada.

30

Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba.

31

CARACTERISTICAS  Es iterativo e incremental  Dirigido por los casos de uso  Centrado en la arquitectura

 Enfocado en los riesgos

32

33

DESCRIPCION •

En el año de 1995 el PSP fue propuesto por Watts Humphrey, este inicialmente estaba dirigido para estudiantes.

•

Para 1997 con el lanzamiento del libro "An Introduction to the Personal Software Process" el PSP ya

estaba destinado a los ingenieros. •

PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual.

•

El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000

líneas de código.

34

•

El PSP sirve para producir software de calidad, donde cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.

•

El PSP se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.

•

El PSP busca proporcionar un marco de trabajo para el personal involucrado en el proceso de desarrollo

de software. •

PSP demuestra cómo manejar la calidad desde el principio del trabajo.

35

PRINCIPIOS DEL PSP •

Cada ingeniero es esencialmente diferente (Cada uno se encarga de su trabajo).

•

Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos.

•

Los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos, esto mejorará la calidad.

•

Cuanto antes se detecten y corrijan los defectos menos esfuerzo será necesario.

•

Es mas efectivo evitar los defectos que detectarlos y corregirlos.

•

Trabajar bien es siempre la forma más rápida y económica de trabajar.

36

OBJETIVOS DE PSP •

Lograr una disciplina de mejora continua en el proceso de desarrollo.

•

Medir, estimar, planificar, seguir y controlar el proceso de desarrollo.

•

Mejorar la calidad del proceso de desarrollo.

•

En general, PSP provee calidad y productividad. – El tiempo ahorrado en el testeo en base a una mejor calidad ahorra entre un 20 a 40 % del desarrollo…

37

DESVENTAJAS DE APLICAR PSP •

El tiempo requerido para conocerlo

•

El costo emocional por mantener una disciplina

•

El ego del cambio en las costumbres

38

VENTAJAS DE APLICAR PSP •

La idea de que ganamos en talento y habilidad

•

La estimulación por nuevas ideas

•

Una estructura de trabajo de mejoramiento personal

•

Tomar control del propio trabajo

•

La sensación de logro

•

Una base mejorada para el trabajo en grupo (TSP)

•

La convicción de que es lo mejor que se puede hacer

39

NIVELES PSP •

El PSP define cinco actividades del marco de trabajo:

– PLANEACIÓN.

– DISEÑO DE ALTO NIVEL – REVISIÓN DEL DISEÑO DE ALTO NIVEL – DESARROLLO – ANÁLISIS DE RESULTADOS

40

NIVELES PSP PSP 3 PSP 2.1 PSP 2 -Revisión del diseño -Revisión del código

Plantillas de diseño (Marco de trabajo y listas) Verificación de tareas de diseño

PSP 1.1

PSP 1 -Aptitud para estimar tamaño.

-Planeación de tareas -Planeación de tiempos

-Informe de pruebas

PSP 0.1 PSP 0 -Practicas actuales desarrollo. -Mantener registros de tiempo trabajado en un proyecto. -Registrar defectos encontrados -Registrar tipos de defectos.

-Establecer estándares de código (Definir “Líneas de código”) -Proponer maneras de mejorar proceso desarrollo -Realizar mediciones

41

CONCLUSION Después de explicar algunos de los modelos de ciclo de vida mas utilizados, ha de surgir una pregunta a la cual daré una respuesta precisa y concreta. ¿Qué modelo de ciclo de vida elegir? y mi conclusión o mi respuesta seria que debemos de elegir el modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar para guiarnos al momento de elegir , la complejidad del problema, el tiempo que disponemos para hacer la entrega final, o si el usuario o cliente desea entrega parciales, la comunicación que existe entre el equipo de desarrollo y el usuario y por ultimo que certeza tenemos que los requerimientos dado por el usuario son correctos o complejos.

42

BIBLIOGRAFIA www.slideshare.net www.lsi.ugr.es/~mvega/docis/respsp.pdf www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10 www.es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3 www.biblioteca.co.cr/pdf/unidad12-4.pdf www.alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf www.pdfcoke.com/doc/11468082/CICLO-DE-VIDA-Y-MODELO-EN-CASCADA -

43