Paradigmas o cilos de vida de desarrollo de software.pdf

Contenido 1. CICLO DE VIDA CLSICO (CASCDA) ............................................................. 4

1.1 Concepto y caractersticas ............................................................................. 4

1.2 Tamao de proyecto ...................................................................................... 4

1.3 Tiempo que utiliza este paradigma ................................................................ 4

1.4 Ventajas y desventajas .................................................................................. 4

1.5 Representacin grfica .................................................................................. 5

2. MODELO ESPIRAL WIN WIN ............................................................................. 5






3. DESARROLLO DE APLICACIONES RPIDAS (RAD) ....................................... 6






4. PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (PUDS) .............. 8






5.- TCNICA DE CUARTA GENERACIN ............................................................. 9


5.2 Tamao de proyecto .................................................................................... 10

5.3 Tiempo que utiliza este paradigma .............................................................. 10

5.4 Ventajas y desventajas ................................................................................ 10

5.5 Representacin grfica ................................................................................ 10

6. RECURSIVO PARALELO ................................................................................. 11

6.1 Concepto y caractersticas ........................................................................... 11



7. SECUENCIAL ................................................................................................... 12




8. PROTOTIPO ..................................................................................................... 13




9. PROCESO UNIFICADO DE RATIONAL (RUP) ................................................ 15




10. PARADIGMA INCREMENTAL ........................................................................ 16

10.1 Concepto y caractersticas ......................................................................... 16

10.4 Ventajas y desventajas .............................................................................. 17

10.5 Representacin grfica .............................................................................. 17

11. PARADIGMA FRAMEWORK .......................................................................... 17

11.1 Concepto y caractersticas ......................................................................... 17

11.4 Ventajas y desventajas .............................................................................. 18

11.5 Representacin grfica .............................................................................. 18

1. CICLO DE VIDA CLSICO (CASCDA)

1.1 Concepto y caractersticas

Es el enfoque metodolgico 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

finalizacin de la etapa anterior.

Un ejemplo de una metodologa de desarrollo en cascada es:

1. Anlisis de requisitos. 2. Diseo del Sistema. 3. Diseo del Programa. 4. Codificacin. 5. Pruebas. 6. Implantacin. 7. Mantenimiento. De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce

necesariamente al rediseo y nueva programacin del cdigo afectado,

aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la

metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un

cambio en las fases ms avanzadas de un proyecto.

1.2 Tamao de proyecto

Est orientado a proyectos pequeos, medianos y grandes, es uno de los

paradigmas que sirven de modelo para el resto.

1.3 Tiempo que utiliza este paradigma

El proceso de creacin 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.

1.4 Ventajas y desventajas

Ventajas

Descompone y organiza el sistema en elementos que puedan elaborarse por

separado, aprovechando las ventajas del desarrollo en equipo. Como resultado

surge el SDD (Documento de Diseo del Software), que contiene la descripcin de

la estructura relacional global del sistema y la especificacin de lo que debe hacer

cada una de sus partes, as como la manera en que se combinan unas con otras.

Hace nfasis en cada una de las fases en la proyeccin de la trayectoria de un ciclo

de vida.

Desventajas

Ha quedado desfasado, obsoleto y no se puede utilizar por los nuevos paradigmas

que han empezado a existir en el desarrollo de software.

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala

implementacin del modelo, lo cual hace que lo lleve al fracaso.

Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente

al rediseo y nueva programacin del cdigo afectado, aumentando los costos del

desarrollo.

1.5 Representacin grfica

2. MODELO ESPIRAL WIN WIN


El modelo en espiral WIN WIN de Boehm, define un conjunto de actividades de

negociacin al principio de cada paso alrededor de la espiral. Ms que una simple

actividad de comunicacin con el cliente se definen las siguientes actividades:

- Identificacin del sistema o subsistemas clave de los directivos.

- Determinacin de las condiciones de victoria de los directivos.

- Negociacin de las condiciones de victoria de los directivos para reunirlas

en un conjunto de condiciones para todos los afectados (incluyendo el equipo del

proyecto de software).El modelo en espiral WIN WIN introduce tres hitos en el

proceso, llamados puntos de fijacin que ayudan a establecer la completitud de un

ciclo alrededor del espiral y proporcionan hitos de decisin antes de continuar el

proyecto de software. El modelo espiral de Win Win acenta ciclos de la elaboracin

concurrente.




Ventajas

El impacto que tiene esta tcnica entre otras es que con ella se puede realizar un

desarrollo de Software ms rpidamente de acuerdo a las voluntades de

cooperacin de los stakeholders (poseedores de apuestas).

Se aplica en el anlisis de requerimientos, calendario, caractersticas, etc. Adems

sirve para separar las personas del problema, enfocarse en los intereses.

Desventajas

La dificultad de esta tcnica ocurre cuando entre los stakeholders ocurre Win-Lose

esto conlleva a Lose-Lose (perder y perder).


3. DESARROLLO DE APLICACIONES RPIDAS (RAD)


El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de

software, que implica el desarrollo iterativo y la construccin de prototipos. El

desarrollo rpido de aplicaciones es un trmino originalmente utilizado para

describir un proceso de desarrollo de software introducido por James Martin en

1991.

Principios bsicos:

- Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en

un sistema de relativamente bajo coste de inversin.

- Intenta reducir los riesgos inherentes del proyecto partindolo en segmentos

ms pequeos y proporcionar ms facilidad de cambio durante el proceso de

desarrollo.

- Orientacin dedicada a producir sistemas de alta calidad con rapidez,

principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de

desarrollo), promueve la participacin de los usuarios y el uso de herramientas de

desarrollo computarizadas. Hace especial hincapi en el cumplimiento de la

necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia son de

menor importancia.

- Control de proyecto implica el desarrollo de prioridades y la definicin de los

plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la

reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite.

- En general incluye Joint application development (JAD), donde los usuarios

estn intensamente participando en el diseo del sistema, ya sea a travs de la

creacin de consenso estructurado en talleres, o por va electrnica.

- La participacin activa de los usuarios es imprescindible.

- Iterativamente realiza la produccin de software, en lugar de enfocarse en un

prototipo.

- Produce la documentacin necesaria para facilitar el futuro desarrollo y

mantenimiento.




Ventajas

Comprar puede ahorrar dinero en comparacin con construir.

Los entregables pueden ser fcilmente trasladados a otra plataforma.

El desarrollo se realiza a un nivel de abstraccin mayor.

Visibilidad temprana.

Mayor flexibilidad.

Menor codificacin manual.

Mayor involucramiento de los usuarios.

Posiblemente menos fallas. Desventajas

Comprar puede ser ms caro que construir.

Costo de herramientas integradas y equipo necesario.

Progreso ms difcil de medir.

Menos eficiente.

Menor precisin cientfica.

Riesgo de revertirse a las prcticas sin control de antao.

Ms fallas (por sndrome de "codificar a lo bestia").

Prototipos pueden no escalar, un problema maysculo.


4. PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (PUDS)


El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto

de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada

una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo

consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como

resultado un incremento del producto desarrollado que aade o mejora las

funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que

recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de

requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen

incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una

de ellas vara a lo largo del proyecto.




Ventajas

Las iteraciones y construcciones proporcionan reducir la proporcin de las tareas,

grupos de trabajo y permiten un constante control de riesgos y realimentaciones.

Permite un lenguaje comn como lo es UML, convirtiendo al desarrollo de software

una disciplina de ingeniera en vez de meramente escribir cdigo.

Al emplear las tecnologas de componentes, se puede emplear la reutilizacin,

reduciendo el tiempo y los costes de desarrollo.

Desventajas

Todo el proceso como tal, se encuentra muy ligado al mtodo, lo que puede

ocasionar inconvenientes al tratar de combinar con otras metodologas.

A pesar de su desarrollo, el mtodo an no incluye una metodologa totalmente

explcita para el control de las actividades de gestin.


5.- TCNICA DE CUARTA GENERACIN


Las tcnicas de cuarta generacin son un conjunto muy diverso de mtodos y

herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan

al que desarrolla el software la propiedad de especificar algunas caractersticas del

mismo a alto nivel, ms tarde, la herramienta genera automticamente el cdigo

fuente a partir de esta especificacin.

Los tipos ms comunes de generadores de cdigo curen uno o varios de los

siguientes aspectos:

- Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.

- Generadores de cdigos: a partir de una especificacin de los requisitos se

genera automticamente toda la aplicacin.

- Generacin de pantallas: permitiendo disear la pantalla dibujndola

directamente, incluyendo adems el control del cursor y la gestin de los errores de

los datos de entrada.

- Gestin de entornos grficos.

- Generacin de informes.




Ventajas

La evolucin de los lenguajes tiende cada vez ms a alejarnos de la maquina o

hardware, creando una mayor abstraccin de los problemas a resolver, esto es

beneficioso pues genera un ahorro significativo de recursos como el tiempo que es

tan valioso actualmente.

Los Lenguajes de Cuarta Generacin tienden a ser muy compatibles entre sus

mismas evoluciones lo que nos permite crear aplicaciones con la confianza de que

el trabajo realizado no ser desechado ms adelante.

Desventajas

El cdigo fuente que produce es ineficiente, al estar generado automticamente no

pueden hacer uso de los trucos habituales para aumentar el rendimiento, que se

basan en el buen conocimiento de cada caso en particular.

Slo son aplicables al software de gestin, la mayora de las herramientas de cuarta

generacin estn orientadas a la generacin a partir de grandes bases de datos,

pero ltimamente estn surgiendo herramientas que generan esquemas de cdigos

para aplicaciones de ingeniera y de tiempo real.


6. RECURSIVO PARALELO


El modelo recursivo paralelo funciona de la siguiente forma:

-Realizar los anlisis suficientes para aislar las clases del problema y las conexiones

ms importantes.

-Realizar un pequeo diseo para determinar si las clases y conexiones pueden ser

implementadas de manera prctica.

-Extraer objetos reutilizables de una biblioteca para construir un prototipo previo.

-Conducir algunas pruebas para descubrir errores en el prototipo.

-Obtener realimentacin del cliente sobre el prototipo.

-Modificar el modelo de anlisis basndose en lo que se ha aprendido del prototipo,

de la realizacin del diseo y de la realimentacin obtenida del cliente.

-Refinar el diseo para acomodar sus cambios.

-Construir objetos especiales (no disponibles en la biblioteca)

-Realizar pruebas para descubrir errores en el prototipo.

Este enfoque continua hasta que el prototipo evoluciona hacia una aplicacin en

produccin.


El progreso se produce iterativamente. Lo que hace diferente al modelo

recursivo/paralelo es el reconocimiento de que:

-El modelo de anlisis y diseo para sistemas orientado a objetos no puede

realizarse a un nivel uniforme de abstraccin.

-El anlisis y diseo pueden aplicarse a componentes independientes del sistema

de manera concurrente.


7. SECUENCIAL


- Definicin del Problema: Esta fase est dada por el enunciado del problema,

el cual requiere una definicin clara y precisa. Es importante que se conozca lo que

se desea realizar, mientras esto no se conozca del todo no tiene mucho caso

continuar con la siguiente etapa.

- Anlisis del Problema: En la etapa de anlisis es importante establecer los

lmites de la solucin que se va a entregar y acotar al mximo la funcionalidad, tratar

de cubrir demasiado es uno de los ms grandes errores que se cometen al momento

de comenzar a analizar un problema.

Diseo de un algoritmo: Al momento de comenzar a disear un algoritmo es

importante cumplir ciertas caractersticas.

Finito: El algoritmo debe finalizar su ejecucin en un nmero finito de pasos.

Definido: Los pasos que ejecutar el algoritmo deben estar bien definidos y

no permitir dobles interpretaciones.

Entradas: Un algoritmo debe tener entrada de datos, ya sea desde alguna

ubicacin de memoria o ingresada por el usuario.

Salidas: Un algoritmo debe entregar un resultado, producto del proceso

ejecutado despus del ingreso de datos.

- Codificacin: Es la operacin de traspasar la solucin del problema que se

puede encontrar en un algoritmo grfico o no grfico a un lenguaje de programacin

de alto nivel que sea reconocido por un compilador o interprete y transforme el

cdigo fuente en un software o programa.

- Prueba y Depuracin: La etapa de pruebas de un algoritmo tienen como

objetivo verificar si el algoritmo sobrevive a las situaciones ms inusuales, esto se

logra verificando si existe un control sobre los datos que ingresan a nuestro

algoritmo, por otra parte la etapa de depuracin de un algoritmo incluye modificar el

algoritmo, para que logre sobrevivir a los eventos ms inusuales.

- Documentacin: La documentacin puede estar escrita en variadas formas,

ya sea en enunciados, procedimientos, dibujos o diagramas.

- Mantenimiento: La etapa de mantenimiento puede ser ejecutada por errores

encontrados en el programa o por mejoras que se deseen realizar, generalmente

es llevada a cabo, despus de haber finalizado el programa, tiene un gran nivel de

dificultad y es importante estudiar y planificar todos los cambios que se desean

realizar, ya que pueden afectar a otras reas del programa.


Ventajas

Suministra una plantilla en la que pueden colocarse los mtodos para cada

una de las fases

Pasos similares a los pasos genricos.

Modelo procedimental ms utilizado.

Desventajas

Gran nfasis en la produccin de documentos completamente elaborados,

producto de las fases de anlisis y especificacin de requerimientos y de

diseo.

No muy aplicable a productos de software altamente interactivos.

Es difcil tener todos los requerimientos, bien definidos al principio, como lo

requiere el modelo y adems presenta dificultades para acomodar posibles

incertidumbres existentes al comienzo de los proyectos.

Los productos de software raramente siguen el flujo secuencial que propone

el modelo. Siempre hay iteraciones y se crean problemas en la aplicacin del

paradigma.

Un error importante no detectado al principio puede ser desastroso.

Se requiere mucha paciencia por parte del cliente, porque solo hasta las

etapas finales del desarrollo podr tener una versin operativa del producto.


8. PROTOTIPO


El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de

desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los

programas adecuados y no se debe utilizar muchos recursos.

El diseo rpido se centra en una representacin de aquellos aspectos del software

que sern visibles para el cliente o el usuario final. Este diseo conduce a la

construccin de un prototipo, el cual es evaluado por el cliente para una

retroalimentacin; gracias a sta se refinan los requisitos del software que se

desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las

necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda

mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Sus etapas

son:

Plan rpido

Modelado, diseo rpido

Construccin del Prototipo

Desarrollo, entrega y retroalimentacin

Comunicacin


Ventajas

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.

Tambin 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 debera tomar la interaccin humano-mquina.

Desventajas

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al

sistema final. A causa de la intencin de crear un prototipo de forma rpida, 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 funcin. Es frecuente que el usuario se muestre

reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo

convertira en un prototipo evolutivo, pero partiendo de un estado poco

recomendado.


9. PROCESO UNIFICADO DE RATIONAL (RUP)


El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente

resumido como RUP) es un proceso de desarrollo de software desarrollado por la

empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje

Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para

el anlisis, diseo, implementacin y documentacin de sistemas orientados a

objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de

metodologas adaptables al contexto y necesidades de cada organizacin.

Tambin se conoce por este nombre al software, tambin desarrollado por Rational,

que incluye informacin entrelazada de diversos artefactos y descripciones de las

diversas actividades. Est incluido en el Rational Method Composer (RMC), que

permite la personalizacin de acuerdo con las necesidades.

Originalmente se dise un proceso genrico y de dominio pblico, el Proceso

Unificado, y una especificacin ms detallada, el Rational Unified Process, que se

vendiera como producto independiente.


Ventajas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,

cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e

incremental, estar centrado en la arquitectura y guiado por los casos de uso.

Incluye artefactos (que son los productos tangibles del proceso como por ejemplo,

el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea

una persona en un determinado momento, una persona puede desempear

distintos roles a lo largo del proceso).


10. PARADIGMA INCREMENTAL


En este modelo se desarrolla el sistema para satisfacer un subconjunto de requisitos

especificados y en posteriores versiones se incrementa el sistema con nuevas

funcionalidades que satisfagan ms requisitos.

Combina elementos del modelo de cascada con la filosofa interactiva de

construccin de prototipos.

Cada secuencia lineal produce un producto operacional con cada incremento

de la misma forma que progresa el tiempo en el calendario.

El primer incremento es a menudo el ncleo.

Como un resultado de evaluacin y/o utilizacin se desarrolla un plan para el

incremento siguiente, este proceso se repite hasta llegar al producto

completo.

Este modelo es particularmente til cuando la dotacin de personal no es

suficiente para una implementacin completa.

Los primeros incrementos se pueden implementar con menos recursos

Si es muy riesgoso desarrollar el sistema completo de una sola vez, entonces

debera considerar este modelo.


Ventajas

Construir un sistema pequeo es siempre menos riesgoso que construir un

sistema grande.

Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si

los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser

descartada y utilizar el incremento previo.

Desventajas

Se presupone que todos los requisitos se han definido al inicio.

Se requiere de una experiencia importante para definir los incrementos de

forma de distribuir en ellos las tareas en forma proporcional

Si el sistema a desarrollar es de gran magnitud y se cuenta con un nico

grupo para construirlo se corre el riesgo que el desarrollo se prolongue

demasiado en tiempo


11. PARADIGMA FRAMEWORK


En el desarrollo de software, un framework o infraestructura digital, es una

estructura conceptual y tecnolgica de soporte definido, normalmente con artefactos

o mdulos de software concretos, con base a la cual otro proyecto de software

puede ser ms fcilmente organizado y desarrollado. Tpicamente, puede incluir

soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras

herramientas, para as ayudar a desarrollar y unir los diferentes componentes de un

proyecto.

Representa una arquitectura de software que modela las relaciones generales de

las entidades del dominio, y provee una estructura y una especial metodologa de

trabajo, la cual extiende o utiliza las aplicaciones del dominio.


Ventajas

El desarrollo rpido de aplicaciones. Los componentes incluidos en un

framework constituyen una capa que libera al programador de la escritura de

cdigo de bajo nivel.

La reutilizacin de componentes software al por mayor. Los frameworks son

los paradigmas de la reutilizacin.

El uso y la programacin de componentes que siguen una poltica de diseo

uniforme. Un framework orientado a objetos logra que los componentes sean

clases que pertenezcan a una gran jerarqua de clases, lo que resulta en

bibliotecas ms fciles de aprender a usar.

Desventajas

La dependencia del cdigo fuente de una aplicacin con respecto al

framework. Si se desea cambiar de framework, la mayor parte del cdigo

debe reescribirse.

La demanda de grandes cantidades de recursos computacionales debido a

que la caracterstica de reutilizacin de los frameworks tiende a generalizar

la funcionalidad de los componentes. El resultado es que se incluyen

caractersticas que estn "de ms", provocando una sobrecarga de recursos

que se hace ms grande en cuanto ms amplio es el campo de reutilizacin.


Paradigmas o cilos de vida de desarrollo de software.pdf

Documents

Transcript of Paradigmas o cilos de vida de desarrollo de software.pdf