Read without ads and support Scribd by becoming a Scribd Premium Reader.
See Premium Plans
 
Modelo de prototipos
EnIngeniería de software
El Modelo de construcción de prototipos
que pertenece a los
modelos de desarrolloevolutivo
, El prototipo debe ser construido en poco tiempo, usando los programasadecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobadonosotros podemos iniciar el verdadero desarrollo del software.
Etapas
y
 
C
omunicación
y
 
P
lan rápido
y
 
M
odelado, diseño rápido
y
 
C
onstrucción del
P
rototipo
y
 
D
esarrollo, 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 objetivosglobales para el software, identifican los requisitos conocidos y las áreas del esquemaen donde es necesaria más definición.
Entonces se plantea con rapidez
esto es el plan rrapido, es cuando después dehablar del uso general del prototitpo se empieza con una iteración de construcción deprototipos y se
presenta el modelado (en la forma de un diseño rápido
). El diseñorápido se centra en una representación de aquellos aspectos del software que seránvisibles 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 laretroalimentación se refinan los requisitos del software que se desarrollará.
El desarrollo la entrega y la retroalimentación
ocurre cuando el prototipo se ajustapara satisfacer las necesidades del cliente. Esto permite que al mismo tiempo eldesarrollador entienda mejor lo que se debe hacer.
 
V
entajas
y
 
Este modelo es útil cuando el cliente conoce los objetivos generales para elsoftware, pero no identifica los requisitos detallados de entrada, procesamiento osalida.
y
 
T
ambién ofrece un mejor enfoque cuando el responsable del desarrollo delsoftware está inseguro de la eficacia de un algoritmo, de la adaptabilidad de unsistema operativo o de la forma que debería tomar la interacción humano-máquina.La construcción de prototipos se puede utilizar como un modelo del procesoindependiente, se emplea más comúnmente como una técnica susceptible deimplementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
 
I
nconvenientes
y
 
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara alsistema final. A causa de la intención de crear un prototipo de forma rápida, sesuelen desatender aspectos importantes, tales como la calidad y elmantenimiento a largo plazo, lo que obliga en la mayor parte de los casos areconstruirlo una vez que el prototipo ha cumplido su función.
C
onclusiones
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 acuerdoen:
y
 
Q
ue el prototipo se construya y sirva como un
mecanismo para la definiciónde requisitos
.
y
 
Q
ue el prototipo se
descarte
, al menos en parte.
y
 
Q
ue después se desarrolle el software real con un enfoque hacia la
calidad
.
 
Modelo Desarrollo Rápido Aplicaciones RAD en inglesEl modelo de
desarrollo rápido de aplicaciones
o
RA
D
(acrónimoen inglés de
rapid application development 
)
es un proceso de desarrollo desoftware, desarrolladoinicialmente porJames Martinen1980  Definición de RAD
P
roceso de desarrollo de software que permite construir sistemas utilizables en pocotiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.
y
 
En ciertas situaciones, una solución utilizable al 80% puede producirse en el20% de tiempo que se hubiera requerido para la solución completa.
y
 
En ciertas situaciones, los requisitos de negocio de un sistema puedensatisfacerse aun cuando algunos de sus requisitos operacionales no sesatisfagan.
P
roblemas atendidos por RAD y que se sulucionan« son los sig.
y
 
C
on los métodos convencionales pasa un gran lapso de tiempo antes de que elcliente vea resultados..
y
 
C
on los métodos convencionales el desarrollo llega a tardar tanto que paracuando el sistema está listo para utilizarse los procesos del cliente hancambiado radicalmente.
y
 
C
on los métodos convencionales no hay nada hasta que el 100% del proceso dedesarrollo se ha realizado, entonces se entrega el 100% del software.
Algunas razones de el por qué utilizar RAD?
Primero las Malas razones
y
 
P
revenir presupuestos rebasados (RAD necesita un equipo disciplinado enmanejo de costos).
y
 
P
revenir incumplimiento de fechas (RAD necesita un equipo disciplinado enmanejo de tiempo).
Bu
enas razones
y
 
C
onvertir tempranamente en un diseño aceptable para el cliente y posible paralos desarrolladores.
y
 
L
imitar la exposición del proyecto a las fuerzas de cambio.
y
 
Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidaddel producto.
N
egociar algo que no sea el programa de trabajo
y
 
RAD tiene una mejor posibilidad de éxito si el cliente está dispuesto a negociarprecio y calidad.
y
 
N
egociar la calidad no significa una mayor tasa de fallas sino un producto conmenos funciones o menos eficiente.
Search
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
    • Notes
    Load more