Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Elaboración de prototipos, RAD y programación extrema (página 2)




Enviado por Yoldany



Partes: 1, 2

Prototipo no funcional El segundo tipo de prototipo es
un modelo no
funcional a escala
configurado para probar ciertos aspectos del diseño.
Un ejemplo de este enfoque es un modelo a escala completa de un
automóvil que se usa para pruebas en un
túnel de vientos. El tamaño y forma del
automóvil son precisos, pero el automóvil no es
funcional. En este caso solo se incluyen las
características del automóvil que son fundamentales
para la prueba

En el túnel de viento. Un modelo no funcional a
escalas de un sistema de
información podría producirse cuando la
codificación requerida por las aplicaciones
es demasiado extensa para incluirse en el prototipo pero cuando
se puede conseguir una idea útil del sistema a tal vez
de la elaboración de un prototipo de la entrada y la
salida. En este caso, el procedimiento,
debido al excesivo costo y el
tiempo
requerido, no podía incluirse en el prototipo. Sin
embargo, aun se podrían tomar algunas decisiones sobre la
utilidad con
la base en la entada y la salida incluidas en el
prototipo.

Primer prototipo de una serie Un tercer tipo de
prototipos involucra la creación de un primer modelo a
escala completa de un sistema, con frecuencia llamado piloto. Un
ejemplo es la elaboración de un prototipo del primer
avión de una serie. El prototipo es completamente
funcional y es una materialización de lo que el
diseñador espera será una serie de aviones con
características idénticas.

Este tipo de elaboración de prototipos es
útil cuando se planean muchas instalaciones del sistema de
información. El modelo funcional a escala
completa permite a los usuarios experimentar la interacción real con el nuevo sistema, pero
minimiza el costo de superar cualquier problema que se presente.
La creación de un modelo funcional es uno de los tipos de
elaboración de prototipos que se hace con RAD, tratado mas
adelante en este capitulo.

Por ejemplo, cuando una cadena de tiendas de abarrotes
minoristas considera el uso del EDI (intercambio
electrónico de datos) para
comprobar los envíos de los proveedores a
varias tiendas, se podría instalar un modelo a escala
completa en una tienda para resolver cualquier problema antes de
que el sistema se implemente en todas las demás tiendas.
Otro es el de las instalaciones bancarias para la transferencia
electrónica de fondos. Primero, se instala
un prototipo a escala completa en una o dos sucursales con base
en los patrones de uso de los clientes y en
otros factores importantes.

Prototipo de características seleccionadas Una
cuarta concepción de la elaboración de prototipos
involucra la creación de un modelo funcional que incluya
algunas, pero no todas, de las características que
tendrá el sistema final. Una analogía seria que un
nuevo centro comercial minorista abriera antes de que se
terminara la construcción de todas las tiendas. Cuando
se elaboran prototipos de los sistemas de
información de esta manera, se incluyen algunas de las
características principales, aunque no todas. Por ejemplo,
en la pantalla podría aparecer un menú del sistema
que muestre seis características: agregar un registro
(característica 1), eliminar un registro
(característica 3) y listar un registro
(característica 5). Cuando se recurre a este tipo de
elaboración de prototipos se evalúan exitosamente,
se pueden incorporar en el sistema final más grande sin
nesecidad de realizar demasiado esfuerzo en la
interacción. Los prototipos hechos de esta forma son parte
del sistema real. No son solo un modelo como en el caso de los
prototipos no funcionales que se describieron antes.

ELABORACIÓN DE PROTOTIPOS COMO
UNA

ALTERNATIVA AL CICLO DE VIDA
DEL DESARROLLO DE
SISTEMAS

Algunos analistas argumentan que la elaboración
de prototipos se debe considerar como una alternativa para el
ciclo de vida del desarrollo d sistemas (SDLC).
Recuerde que el SDLC, tratado en el capitulo 1, es un enfoque
lógico y sistemático que se sigue en el desarrollo
de sistemas de información.

Las quejas relativas al proceso del
SDLC se centran en dos preocupaciones interaccionadas. La primera
preocupación es todo el tiempo que se requiere para pasar
por el ciclo de vida del desarrollo. Conforme aumenta la inversión de tiempo del analista, el costo
del sistema entregado se incrementa proporcionalmente.

La segunda preocupación sobre el uso del SDLC es
que los requerimientos del usuario cambian a través del
tiempo. Los requerimientos del usuario evolucionan durante el
considerable intervalo existente entre el análisis de los requerimientos del usuario
y la fecha en que se entrega el sistema final. Por lo tanto,
debido al extenso ciclo del desarrollo, el sistema resultante
podría ser crítico por abordar deficientemente los
requerimientos de información del usuario
actual.

Un corolario al problema de mantenerse al tanto de los
requerimientos de información es la teoría
de que los usuarios realmente no saben lo que hacen o no lo
desean sino hasta que vean algo tangible .en el SDLC tradicional,
una vez que se entrega un sistema, con frecuencia es demasiado
tarde para modificarlo.

Para resolver estos problemas,
algunos analistas proponen la elaboración de prototipos
como una alternativa al ciclo de vida del desarrollo de sistemas.
Cuando la elaboración de prototipos se usa de esta forma,
el analista reduce efectivamente el tiempo entre la
determinación de los requerimientos de información
y la entrega de un sistema funcional. Además, el uso de
elaboración de prototipos en lugar de SDLC tradicional
podría resolver algunos problemas como el de identificar
con presicion los requerimientos de información del
usuario.

Ente las desventajas de sustituir el SDLC por la
elaboración de prototipos esta la de configuración
prematura de un sistema antes de que el problema u oportunidad en
cuestión se entienda completamente. También, el uso
de la elaboración de prototipos como una Alternativa
podría producir un sistema aceptado por grupos
específicos de usuarios pero inadecuados para las
necesidades globales del sistema.

El enfoque que apoyamos aquí es usar la
elaboración de prototipos como una parte del SDLC
tradicional. Desde esta perspectiva, la elaboración de
prototipos se considera como un método
adicional y especializado para determinar los requerimientos de
los usuarios.

COMO DESARROLLAR UN
PROTOTIPO

Los lineamientos de esta sección para desarrollar
un prototipo son avanzados. El termino elaboración de
prototipos
se interpreta en el sentido de la ultima
definición que se explico, es decir, un prototipo de
características seleccionadas que incluirá algunas
pero no todas no todas las características., uno que, si
tiene éxito.,
será parte del sistema final que se entregue .

Como se ilustra en la figura 6.2, la elaboración
de prototipos es una excelente forma de obtener retroalimentación sobre el sistema
propuesto y sobre la facilidad con que esta cumpliendo las
necesidades de información de su usuario.

El primer paso de la elaboración de prototipos es
estimar los costos necesarios
para la construcción de un modulo del sistema.

Si los costos del tiempo de programadores y analistas y
los del equipo que utilizaran están dentro del presupuesto, se
puede proceder a la elaboración del prototipo. La
elaboración de prototipos es una excelente forma de
facilitar la integración del sistema de
información con el sistema principal de la
organización.

LINEAMIENTOS PARA
DESARROLLAR UN PROTOTIPO

Una vez que se ha tomado la decisión de elaborar
un prototipo, se deben observar cuatro lineamientos principales
al integrar la elaboraron de prototipos con la fase de
determinación de requerimientos del SDLC.

  1. Trabajar en módulos manejables.
  2. Construir rápidamente el prototipo
    .
  3. Modificar el prototipo en interacciones
    sucesivas.
  4. Poner énfasis en la interfaz de
    usuario.

Como puede ver, los lineamientos sugieren acciones
relativas al prototipo que necesariamente se interrelacionan
.Cada uno de los lineamientos se explica en las sucesiones
siguientes .

El trabajo en
módulos manejables- Cuando el prototipo de algunas de las
características de un sistema se integra para formar un
modelo funcional, es indispensable que el analista trabaje en
módulos manejables. Una ventaja evidente de la
elaboración de prototipos es que no es necesario ni
deseable construir un sistema operativo
completo para los propósitos del prototipo. Un
módulo manejable es aquel que permite a los usuarios
interactuar con sus características clave pero que se
puede contruir de forma separada de otros módulos de
sistemas. Las características del módulo que se
juzgan de menor importancia se omiten intencionalmente en el
prototipo inicial.

Construcción rápida del prototipo- La
rapidez es esencial para la elaboración exitosa del
prototipo de un sistema de información. Recuerde que unas
de las quejas expresadas en contra de el CDLC tradicionales es
que el intervalo entre la discriminación de requerimientos y la
entrega de un sistema completo es demasiado largo para satisfacer
eficazmente las cambiantes necesidades del usuario.

Los analistas pueden usar la elaboración de
prototipos con el fin de reducir esta brecha utilizando las
técnicas tradicionales de
recopilación de información para determinar con
presión
los requerimientos de infomación que surjan sobre la
marcha, y a continuación tomar rápidamente las
decisiones que den lugar o un modelo funcional. De hecho, el
usuario de y utiliza el sistema muy temprano en el SDLC en lugar
de esperar hasta que el sistema se termine para practicar con
él.

La preparación de un prototipo operacional, con
rapidez y en las etapas tempranas del SDLC , permite al analista
comprender mejor cómo desarrollar el resto del proyecto. Al
mostrar a los usuarios en las primeras etapas del proceso como se
ejecutan en la realidad algunas partes del sistema, la
elaboración rápida de prototipos evita que se
dediquen demasiados recursos a un
proyecto que a la larga podría ser imposible de concretar.
Más adelante, cuando se explique el RAD, usted verá
nuevamente la importancia de la construcción rápida
de sistemas.

Modificación del prototipo. Un tercer
lineamiento para desarrollar el prototipo es que su
construcción debe soportar modificaciones. Hacer un
modificable el prototipo significa crearlo en módulos que
no sean demasiado interdependientes. Si se observa este
alineamiento, se encontrará menos resistencia
cuando sea necesario realizar cambios al prototipo. Generalmente,
el prototipo se modifica varias veces al pasar por diversas
interacciones.

Los cambios en el prototipo deben propiciar que el
sistema se acerque cada vez más a lo que los usuarios
consideren importante. Cada modificación necesita otra
evaluación por parte de los
usuarios.

El prototipo no es un sistema terminado. Abordar la face
de elaboración de prototipos con la idea de que el
prototipo requerirá modificaciones es una actitud
positiva que demuestra a los usuarios cuán necesaria es
una retroalimentación para mejorar el sistema.

EL PAPEL DEL
USUARIO EN LA ELABORACIÓN DE PROTOTIPOS

El papel del usuario en la elaboración de
prototipo se puede resumir en dos palabras: intervención
honrada. Sin la intervención del usuario hay poca
razón para elaborar el prototipo los comportamientos
precisos y necesarios para interactuar con un prototipo pueden
variar pero el usuario es fundamental en el proceso de la
elaboración del prototipo comprendida la importancia que
tiene el usuario en el éxito del proceso, los miembros del
equipo del análisis del sistema deben propiciar y recibir
de buena manera la retroalimentación y deben evitar su
propia resistencia y cambiar el prototipo.

INTERACCIÓN DEL PROTOTIPO

Hay tres formas principales en la que un usuario pude
ayudar en la elaboración de un prototipo

  1. Experimentando en el prototipo.
  2. Dando reacciones sinceras sobre el
    prototipo.
  3. Sugiriendo adiciones o eliminaciones al
    prototipo.

Los usuarios deben tener libertad para
experimentar con el prototipo. En contraste con una simple lista
de características del sistema, el prototipo permite a los
usuarios la interacción real. Una forma de facilitar esta
interacción es instalar un prototipo en un sitio Web
interactivo

Enfoques pioneros de Martín para el RAD En
la figura 6.5 usted puede ver nuestra conceptualizacion de la
fases originales del RAD de James Martin; en la primera fase
Martin explica la planeación
de requerimiento. Aquí los usuarios de alto nivel deciden
qué funciones deben
incluir la aplicación.

En la segunda fase, llamada fase de diseño de
usuarios, Martin caracteriza a los usuarios como ocupados en
discutir los aspectos no técnicos del diseño del
sistema, con la ayuda de los analistas. La fase del taller del
diseño del RAD incorpora la fase del usuario y la de
construcción es una, debido a que la naturaleza muy
interactiva y visual del proceso de diseño y
refinación está ocurriendo de una forma interactiva
y participativa.

En la fase de construcción se realizan muchas
actividades diferentes. Cualquier diseño que se cree en la
fase anterior se mejora más con la herramienta del RAD.
Tan pronto como las nuevas funciones están disponibles, se
muestran a los usuarios para la interacción, comentarios y
revisión. Con las herramientas
del RAD, los analistas pueden hacer cambios continuos en el
diseño de las aplicaciones.

La cuarta y última fase de Martin, la fase de
cierre, la aplicación recientemente desarrollada
reemplazará a la anterior. Mientras está
ejecutándose en paralelo con la aplicación
anterior, la nueva prueba, los usuarios son entrenados y los
procedimientos
de la organización se cambian antes de que ocurra
el cierre.

Herramientas de software para el RADComo
usted podía esperar, por lo regular las herramientas de
software para el RAD son las mas nuevas, con frecuencias
orientadas a objetos. Algunos ejemplos son programas muy
conocidos como Microsoft
Acces, Microsoft Basic, visual
C++Microsoft. Net. (Véase el capítulo 18 para
una explicación más detallada del enfoque orientado
a objetos.)

Una forma en que las herramientas difieren entre
sí está en sus capacidades para dar soporte a las
aplicaciones cliente/servidor (por
ejemplo, MS Access no da
soporte, Visual Basic si
lo da) así como también su facilidad de uso y el
nivel de conocimientos de programación que se requieren. La
mayoría de las aplicaciones del RAD se usan para
aplicaciones pequeñas basadas en PC, aunque su verdadero
poder
podría radicar en las aplicaciones cliente/ servidor que
necesitan ejecutarse otra vez de múltiples
plataformas.

Aunque hay identificadas casi tantas fases diferentes
del RAD así como hay analistas, las cuatros fases
propuestas por Martin –planeación de requerimientos,
diseño del usuario, la construcción y cierre
– son útiles. Examinemos cada una con más
detalle, comparándolas y contrastándolas con la
elaboración de las características de la
elaboración prototipos clásica y el SDLC
tradicional.

RAD EN
COMPARACIÓN CON EL SDLC

En la figura 6.6 se pueden comparar las fases del SDLC
con aquellas detalladas para el RAD al principio de esta
sección. Observe que el principal propósito del RAD
es acortar el SDLC de esta forma responder más
rápidamente a los requerimientos de información
dinámicos de las organizaciones.
El SDLC toma un enfoque mas metódico y sistemático
que asegura al integridad y exactitud y tiene como
propósito la creación de sistemas que se integran
en los procedimientos estándar de negocio y en la cultura. La
fase del taller del diseño del RAD difiere de las fases de
diseño estándar del SDLC, debido a que las
herramientas de software de RAD se usan para generar pantallas y
exhibir

Figura 6.6

El taller de diseño del RAD en
comparación con el enfoque del SDLC

 

El flujo global de funcionamiento de la
aplicación. Así, cuando los usuarios aprueban este
diseño, están conviviendo en una
representación del modelo visual, no solo en un
diseño conceptual representado en papel, como
tradicionalmente se hace.

La fase de implementación del RAD es, en muchas
formas, menos estresantes que otras debido a que los usuarios han
ayudado a diseñar los aspectos de negocios del
sistema y saben perfectamente que cambios se harán. Ay
pocas sorpresas, y el cambio es algo
a lo que se le da la bienvenida. Con frecuencia, cuando se
utiliza el SDLC y los analistas están separados de los
usuarios, ay mucho tiempo entre el desarrollo y el diseño.
Durante este periodo, los requerimientos pueden cambiar y los
usuarios se pueden sorprender si el producto final
es diferente del que se anticipo durante muchos meses.

Cuando utilizar el RAD En su función de
analista, necesita aprender tantos enfoques y herramientas como
sea posible que lo ayuden a hacer mejor su trabajo. Ciertas
aplicaciones y trabajo de sistemas darán lugar a ciertas
metodologías. Considere utilizar RAD cuando:

  1. su equipo incluya a programadores y analistas que
    tengan experiencia con el, y
  2. haya razones de negocio urgentes para acelerar una
    parte del desarrollo de la aplicación; o
  3. cuando esté trabajando con una nueva
    aplicación de comercio
    electrónico y su equipo de desarrollo crea que el
    negocio puede beneficiarse ampliamente sobre sus competidores
    siendo innovador si esta aplicación está entre la
    primera en aparecer en la Web; o
  4. cuando los usuarios sean maduros y estén
    altamente comprometidos con las metas
    organizacionales.

Desventajas del RAD Las dificultades con el RAD,
como con otras clases de elaboración de prototipos, se
originan debido a que los analistas de sistemas intentan
apresurar demasiado el proyecto. Suponga que se contratan dos
carpinteros parra construir dos cobertizos de almacenamiento
para dos vecinos. El primer carpintero sigue la filosofía del SDLC, mientras que el segundo
la del RAD.

El primer carpintero es sistemático, cataloga
cada herramienta, cada podadora y cada uno de los muebles del
patio para determinar el tamaño correcto del cobertizo,
diseña un plano del cobertizo y anota las especificaciones
para cada parte de madera y
hardware. El
carpintero construye el cobertizo con poca pérdida y tiene
la documentación precisa sobre cómo fue
construido el cobertizo por si cualquiera quisiera construir otro
parecido, repararlo o pintarlo del mismo color.

El segundo carpintero va directo al proyecto y calcula
el tamaño del cobertizo, consigue un camión de
madera y hardware, construye una estructura y
discute con el dueño de la propiedad las
modificaciones necesarias si no están disponibles ciertos
materiales y
hace un viaje para devolver la madera que no se usa. El cobertizo
se construye rápidamente, pero si no se hace un plano
nunca existe la documentación.

PROGRAMACIÓN EXTREMA

La programación extrema (XP) es un enfoque de
desarrollo de software (tratando el capítulo 3) que adopta
lo que generalmente designamos como práctica de desarrollo
de software aceptable y las lleva al extremo. Por ejemplo, la
retroalimentación es importante para los programadores,
analistas, diseñadores, usuarios y computadoras
(como verán en el capítulo 14). Así que la
programación extrema usa ciclo de retroalimentación
cada vez más rápido e intenso, que proporcionan
más información.

La administración de proyecto es importante (
como se vio en el capitulo 3), de tal manera que la
programación extrema intenta definir rápidamente un
plan global
del sistema, desarrollar y liberar rápidamente el software
y posteriormente revisarlo continuamente para incorporarles
características adicionales. Los programadores, analistas
y diseñadores ordinarios que trabajan independientemente y
luego integran su trabajo logran resultados sólidos; los
programadores extremos que trabajan en parejas pueden ser
excelentes. Pero la programación extrema no solo se basa
en los resultados. Se basa en los valores
principios y
prácticas. Ahora examinaremos como los valores y
Principios de XP dan forma al desarrollo de sistemas
extremos.

VALORES Y
PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA

Para la programación extrema es importante que se
declaren los valores y principios que crean el contexto para la
colaboración entre programadores y clientes. Para
considerarse analistas de XP se debe apegar a los siguientes
valores y principios desarrollados por Beck (2000).

Cuatro valores de XP Hay cuatro valores que crean
un entorno en el cual se pueden servir adecuadamente
diseñadores y negocios. Debido a que con frecuencia hay
una tensión entre lo que los diseñadores hacen a
corto plazo y lo que es comercialmente deseable a largo plazo, es
importante que esté consciente de apoyar valores que
formarán una base para colaborar juntos en un proyecto de
software. Como se muestra la figura
6.7, los cuatro valores son comunicación, sencillez y
retroalimentación y valentía.

Empecemos con la
comunicación. Cada esfuerzo humano tiene la
posibilidad de fallar en la comunicación. Los proyectos de los
sistemas que requieren una actualización constante y un
diseño técnico son especialmente propensos a dichos
errores. Agregue a este proyecto fechas límite ajustadas,
jerga especializada y el estereotipo de que los programadores
prefieren hablar con las máquinas
que con las personas, y usted tiene los ingrediente para algunos
problemas serios de comunicación. Los proyectos pueden ser
retrasados; se puede resolver el problema equivocado; se castiga
a los programadores incluso por mencionar a los gerentes que hay
problemas; las personas abandonan o se unen al proyecto a la
mitad sin estar al corriente; y así continua la
letanía.

Prácticas típicas de XP tal como la
programación en pareja (colaboración de dos
programadores, descrita mas adelante en el capitulo),
estimación de las tareas y las pruebas de software,
requieren de una buena comunicación. Los problemas se
resuelven rápidamente, los agujeros se tapan y la
opinión débil se fortalece rápidamente a
través de la interacción con otros en el equipo. Un
instructor de XP, como se describió en el capitulo 3, esta
presente para observar si alguien ha interrumpido la
comunicación y para reunirlos.

El segundo valor de la
programación extrema es la simpleza. Cuando estamos
trabajando en un proyecto de desarrollo de software, nuestra
primera reacción es

abrumarnos la complejidad y magnitud de la tarea. Sin
embargo, usted no puede correr si no sabe caminar, ni caminar si
no sabe ponerse de pie. La simpleza en el desarrollo de software
significa que empezaremos con la cosa más sencilla que
podemos hacer.

La simpleza lleva tiempo, y es algo en lo que el
instructor de XP podría ayudarle. El valor de XP de
simpleza nos pide que hoy hagamos la cosa más sencilla,
comprendiendo que mañana se podría cambiar un poco.
Esto quiere un enfoque claro de las metas del proyecto y
realmente es un valor básico.

La retroalimentación es el tercer valor
básico que es importante para tener un enfoque de la
programación extrema. Cuando piensa en la
retroalimentación en este contexto, es bueno considerar
que esta se relaciona con el concepto de
tiempo. Una retroalimentación buena y cocreta, que es
útil para el programador, analista y cliente puede ocurrir
en segundos, minutos, días, semanas o meses, dependiendo
de lo que se necesita, quien esta comunicando y lo que se
hará con dicha retroalimentación. Un colega
programador podría encontrar un caso de prueba que hiciera
que un código
que usted escribió fallara.

 

Realizado por:

Yoldany

profesorpepelo[arroba]hotmail.com

Politécnico de azua

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter