P. 1
Modelo de prototipos

Modelo de prototipos

|Views: 1.233|Likes:
Publicado porlic. samuel

More info:

Published by: lic. samuel on Nov 17, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/11/2013

pdf

text

original

Modelo de prototipos

En Ingeniería de software El Modelo de construcción de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.

Etapas
y y y y y

Comunicación Plan rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación
El paradigma de construcción de prototipos se inicia con la Comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez esto es el plan rrapido, es cuando después de hablar del uso general del prototitpo se empieza con una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final. El diseño rápido conduce a la Construcción de un prototipo. el prototipo lo evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. El desarrollo la entrega y la retroalimentación 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.

Ventajas
y

y

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 humanomáquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.

Inconvenientes
y

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.

Conclusiones
A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:
y y y

Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos. Que el prototipo se descarte, al menos en parte. Que después se desarrolle el software real con un enfoque hacia la calidad.

Modelo Desarrollo Rápido Aplicaciones RAD en ingles El modelo de desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980 Definición de RAD Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.
y y

En ciertas situaciones, una solución utilizable al 80% puede producirse en el 20% de tiempo que se hubiera requerido para la solución completa. En ciertas situaciones, los requisitos de negocio de un sistema pueden satisfacerse aun cuando algunos de sus requisitos operacionales no se satisfagan.

Problemas atendidos por RAD y que se sulucionan« son los sig.
y y

y

Con los métodos convencionales pasa un gran lapso de tiempo antes de que el cliente vea resultados.. Con los métodos convencionales el d esarrollo llega a tardar tanto que para cuando el sistema está listo para utilizarse los procesos del cliente han cambiado radicalmente. Con los métodos convencionales no hay nada hasta que el 100% del proceso de desarrollo se ha realizado, entonces se entrega el 100% del software.

Algunas razones de el por qué utilizar RAD?
Primero las Malas razones
y y

Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos). Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo).

Buenas razones
y y y

Convertir tempranamente en un diseño aceptable para el cliente y posible para los desarrolladores. Limitar la exposición del proyecto a las fuerzas de cambio. Ahorrar tiempo de desarrollo, posiblemente a ex pensas de dinero o de calidad del producto.

Negociar algo que no sea el programa de trabajo
y y

RAD tiene una mejor posibilidad de éxito si el cliente está dispuesto a negociar precio y calidad. Negociar la calidad no significa una mayor tasa de fallas sino un producto con menos funciones o menos eficiente.

Una o más metas pueden ser inalcanzables
y y y

El menor número posible de fallas: los desarrolladores pueden no tener la posibilidad de corregir fallas en algunos componentes de terceros. Nivel más alto de satisfacción del cliente: algunos requisitos secundarios pueden ser sacrificados en aras del calendario. El menor costo de desarrollo: comprar herramientas y componentes puede ser más caro que desarrollarlos.

Características de RAD
y y y

Equipos Híbridos Herramientas Especializadas Prototipos Iterativos y Evolucionarios.

Equipos Híbridos
y

y

Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

Herramientas Especializadas
y y y y y y y y y

Desarrollo "visual" Creación de prototipos falsos (simulación pura) Creación de prototipos funcionales Múltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Interfaces estándares (API) Control de versiones

Prototipos Iterativos y Evolucionarios
y

y

Reunión JAD o Se reunen los usuarios finales y los desarrolladores. o Lluvia de ideas para obtener un borrador inicial de los requisitos. Iterar hasta acabar: o Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. o Los diseñadores revisan el prototipo. o Los clientes prueban el prototipo, depuran los requisitos . o Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

y

Notas:
o o

Cada iteración dura entre un día y tres semanas. Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

Ventajas de RAD
1. Comprar puede ahorrar dinero en comparación con construir. 2. Los entregables pueden ser fácilmente trasladados a otra plataforma. 3. El desarrollo se realiza a un nivel de abstracción mayor. 4. Visibilidad temprana. 5. Mayor flexibilidad. 6. Menor codificación manual. 7. Mayor involucramiento de los usuarios. 8. Posiblemente menos fallas. 9. Posiblemente menor costo. 10. Ciclos de desarrollo más pequeños. 11. Interfaz gráfica estándar.

Desventajas de RAD
1. Comprar puede ser más caro que construir. 2. Costo de herramientas integradas y equipo necesario. 3. Progreso más difícil de medir. 4. Menos eficiente. 5. Menor precisión científica. 6. Riesgo de revertirse a las prácticas sin control de antaño. 7. Más fallas (por síndrome de "codificar a lo bestia"). 8. Prototipos pueden no escalar, un problema mayúsculo. 9. Funciones reducidas 10. Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales. 11. Requisitos que no convergen. 12. Interfaz gráfica estándar. 13. Difícil de repetir experiencias exitosas. 14. Funciones no deseadas.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->