Los prototipos son una visin preliminar del sistema futuro que se implantara.

La elaboracin de prototipos de un sistema de informacin es una tcnica valiosa para la recopilacin rpida de informacin especfica a cerca de los requerimientos de informacin de los usuarios.

Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinacin de requerimientos. En esta forma el analista est buscando las reacciones iniciales de los usuarios y de la administracin hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisin que detallan que parte del sistema necesita realizarse primero. Tipos de Informacin que busca el Analista durante la Elaboracin de Prototipos. Reacciones del usuario. Innovaciones. Sugerencias del usuario. Plan de revisin. Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de retroalimentacin, diseadas para recoger la opinin de cada persona acerca del prototipo cuando interacta con l. Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema. Sugerencias: El analista tambin est interesado en las sugerencias de los usuarios y la administracin acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo especfico. Las sugerencias son el producto de la interaccin de los usuarios con el prototipo. Estas sugerencias deben apuntar ala analista hacia formas de refinacin, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios. Innovaciones: Son parte de las informaciones buscada por el equipo de anlisis de sistema. Son capacidades nuevas del sistema que no haban sido pensadas antes de la interaccin con el prototipo. Van ms all de las caractersticas prototpicas actuales aadiendo algo nuevo e innovador. Plan de Revisin: Ayuda a identificar prioridades para lo que se debe construir un prototipo a continuacin. En situaciones donde estn involucradas muchas ramas de la organizacin, los planes de revisin ayuda a determinar para cules hay que construir un prototipo a continuacin. La informacin recolectada en esta fase permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mnimo de ruptura. La elaboracin de prototipo y la planeacin van mano a mano.

TIPOS DE PROTOTIPO Prototipo Parchado: Es un sistema que tiene todas las caractersticas propuesta pero es realmente un modelo bsico que eventualmente ser mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante. Prototipo no Operacional: La segunda concepcin de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseo. Este puede ser hecha cuando la codificacin requeridas por las aplicaciones es muy amplia para hacerse el prototipo y, sin embargo se puede obtener una idea til del sistema por medio de la elaboracin de prototipos de la entrada y salida solamente. Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podra no ser realizado, sim embargo se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo. Prototipo Primero de una Serie: Una tercera concepcin de la elaboracin de prototipos involucrados la creacin de un primer modelo o escala completa de un sistema, llamado tambin piloto. Este tipo de prototipo es til cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interaccin realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente. Prototipo de Caractersticas Seleccionadas: Un prototipo de caractersticas seleccionada permite que el sistema sea puesto en su lugar mientras otras caractersticas pueden ser aadidas en fecha posterior. Se refiere a la construccin de un modelo operacional que incluye algunas, pero no todas, de las caractersticas que tendr el sistema final. Cuando se construye este tipo de prototipo, el sistema se va construyendo por mdulos, de modo que si las caractersticas reciben una evaluacin satisfactoria, stas puedan incorporarse en el sistema final, mucho ms grande sin tener que hacer un trabajo inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta. 3. MODELO DE PROTITIPO El objetivo de la Ingera de Software es optimizar la calidad de los productos de software para ampliar la productividad y facilitar el trabajo de los ingenieros proporcionndoles las bases necesarias para construir software de alta calidad en forma eficiente, existen diversas etapas y procedimientos a las que se las denomina ciclo de vida en el cual se definen parmetros como el tiempo y las caractersticas necearas para que el software sea considerado confiable y completo. El modelo de prototipos: Permite que todo el sistema, o algunos de sus partes, se construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el

desarrollador, el usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo. Este modelo se encarga del desarrollo de diseos para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. Etapas para la elaboracin del Modelo de Prototipo. Lo podemos resumir en cuatro pasos Identificar requerimientos bsicos del usuario Desarrollar prototipo inicial Usar el prototipo Revisin y mejora del prototipo Etapas del Ciclo de Vida de un Sistema. Definicin del proyecto: En esta etapa se identifican problemas, oportunidades y objetivos, as mismo se determinan los requerimientos de informacin, de la manera ms objetiva posible. Adems analiza si es preciso implementar un nuevo sistema o modificar el existente, especifica los objetivos y el alcance del proyecto todo plasmado en un plan de proyecto estructurado. Anlisis de sistemas: Se procede a analizar los problemas cuidadosamente, las necesidades del sistema, utilizando algunas herramientas como los diagramas de flujo, adems de las entrevistas, los anlisis de documentos e informes, etc. asimismo se hace un anlisis inicial de la factibilidad de las posibles soluciones. Diseo: Una vez obtenida toda la informacin recopilada anteriormente se elabora un diseo lgico del sistema de informacin. Posteriormente se hacen las descripciones formales, que implica disear procedimientos precisos de captura de datos, accesos efectivos al sistema, la interfaz con el usuario, una base de datos eficiente. Programacin: Esta etapa es bsicamente tcnica, consiste en traducir las especificaciones de diseo en un cdigo de programacin. Instalacin: Consiste en comprobar el sistema, es decir se analiza la forma en que se implementar en la organizacin, se capacita el personal, as mismo se documenta el sistema y se le hacen las primeras evaluaciones. Post-implantacin: En este paso se evala constante del sistema despus de entrar en funcionamiento, incluye actualizacin y puede llegar a ser necesaria una auditora formal para ver si el sistema cumple con los objetivos. Ejemplo. Tomemos como referencia el desarrollo de un sistema, como se observa en la figura 4. puede iniciar con una serie de requerimientos que son proporcionados por el cliente y los usuarios, posteriormente se analizarn las distintas alternativas, pantallas, tablas, informes, entre otras salidas del sistema que sern utilizadas directamente por los usuarios y clientes, cuando el cliente y el usuario

estn en mutuo acuerdo en lo que desean, los desarrolladores proceden con la etapa de diseo que se centra en la representacin de los aspectos del software que sern visibles para el cliente o el usuario fina, este diseo nos conduce a la construccin de un prototipo, tambin se analizaran las alternativas del mismo hasta que el desarrollador y principalmente los usuarios y los clientes estn satisfechos con el resultado, suele presentarse el caso en el que los involucrados estn inconformes con el diseo, es por esto que se retorna a las actividades de requerimientos para que puedan ser reconsiderados y cambiados hasta lograr un acuerdo; el prototipo es evaluado por el cliente y el usuario y mediante al retroalimentacin figura 2. Se mejoran los requisitos del software que se desarrollar y mediante este proceso satisfacer las necesidades del cliente y al mismo tiempo lograr que el desarrollador entienda con ms claridad lo que debe hacer. Finalmente se construye el prototipo aplicando herramienta. Se analizan sus alternativas y puede darse el caso en el que se repita todo el proceso anterior. No obstante a los usuarios les agrada visualizar un sistema real, y a los desarrolladores les gusta construir algo de manera inmediata, analicemos estos casos. Los desarrolladores establecen compromisos de implementacin para lograr que el prototipo funcione con rapidez, utilizando lenguajes conocidos y porque estn disponibles pero que es inadecuado, puede darse el caso que el usuario se familiarice con dicha aplicacin y no considera que es inapropiado. La clave est en establecer las reglas desde el principio en las que el cliente y el desarrollador estn de acuerdo en que la elaboracin del prototipo sirva para el desarrollo de un software real con un enfoque hacia la calidad principalmente. Al utilizar este modelo las etapas del ciclo de vida pueden variar en: Anlisis del requisito del sistema Anlisis de requisitos del software Diseo desarrollo e implementacin del prototipo Prueba del prototipo Refinamiento interactivo del prototipo Refinamiento de las especificaciones del prototipo Diseo e implementacin del sistema final Explotacin y mantenimiento

Clasificacin del Modelo de Prototipo. Modelo de rendimiento Modelo bsico que ser perfeccionado posteriormente, el este tipo de prototipo los usuarios se adaptan a las aplicaciones aunque los procesos de recuperacin y almacenamiento de la informacin son ineficientes. Modelo a escala no funcional Permiten evaluar aspectos del diseo, pero en realidad no son funcionales, se lo construye en escala. Modelo a escala completa Se lo utiliza como referencia para distintas versiones que de l se hagan, este modelo se lo aplica al instalar un sistema en varias instalaciones.

Modelo con caractersticas esenciales En este modelo se incluyen algunas, no todas las caractersticas que tendr el sistema final. Ventajas del Modelo de Prototipo. 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 hdumano-mquina. Desventajas del Modelo de Prototipo. El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con plastilina y alambres, y puede desilusionarse al decirle que el sistema an no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.
Mtodos y herramientas para el desarrollo de prototipos Tcnicas de cuarta generacin : Estas comprenden una amplia gama de lenguajes de consulta y de otros lenguajes ideales para la creacin rpida de prototipos. Componente de software reutilizables: El ensamblar ms que el construir, es un prototipo mediante software existente. Un componente de software puede ser una estructura de datos o un componente arquitectnico. En pocas palabras un software existente que cumpla con los requisitos del cliente. Especificaciones formales y entornos para prototipos: Durante las pasadas dos dcadas, se han desarrollado varios lenguajes formales de especificacin y herramientas como sustitutos de las tcnicas de especificacin con lenguaje natural. Hoy en da los desarrolladores de estos lenguajes formales estn desarrollando entornos interactivos que: Permitan al analista crear interactivamente una especificacin basada en lenguaje de un sistema o software. Invoque herramientas automticas que traducen la especificacin basada en el lenguaje de cdigo ejecutable. Permitan al cliente usar el cdigo ejecutable del producto para refinar los requisitos formales. Mtodos y herramientas para el desarrollo de los prototipos, para la seleccin de un enfoque apropiado de creacin de prototipo.

Paradigmas del proceso de desarrollo de software

Un paradigma o modelo del proceso de desarrollo de software, es una descripcion de las actividades que se llevan a cabo en la elaboracion de un producto de software. Al proceso completo de desarrollo, tambien se le conoce como ciclo de vida del software, debido a que en l se detalla la vida de un sistema desde su concepcion, implementacion, entrega, utilizacion y hasta su mantenimiento. En la literatura de Ingeniera de Software existe una variedad de modelos o paradigmas de desarrollo. Los modelos mas utilizados se describen a continuacin.

Modelo de desarrollo en cascada

El modelo en cascada , define un enfoque secuencial del proceso de desarrollo, separando en etapas y cada etapa es fundamental en el desarrollo (figura 2.2). Cada etapa debe completarse antes de comenzar la siguiente etapa. El problema que presenta este modelo es debido a la separaci on de las actividades en etapas, en cada fase el resultado es uno o ms documentos aprobados. En la practico estas actividades del desarrollo de un producto de software estn entrelazadas y requieren de continuas iteraciones, adem as si un error no es detectado al principio de la etapa, puede ser desastroso encontrarlo en etapas posteriores. Es dif cil dejar definidos los requerimientos en la primera etapa del desarrollo, como lo expresa el modelo, esto podr a generar problemas a la hora de encontrar nuevos requerimientos en las ultimas etapas y no fuera posible regresar a la primera etapa para agregarlos. Para el modelo en cascada el cliente podr a tener una versi on operativa del sistema s olo hasta alcanzar las etapas finales del desarrollo [24].

Desarrollo Evolutivo
Este paradigma recomienda el desarrollo de una implementacin inicial del sistema, que debe ser presentada al cliente para su negociacin, y posteriormente refinada mediante versiones hasta alcanzar el desarrollo completo del sistema. Este modelo de desarrollo es m as conocido como prototipado, en donde las actividades son llevadas a cabo en forma concurrente y tienen retroalimentaci on en todo el proceso.

Existen dos tipos de desarrollos evolutivos: 1. Desarrollo Exploratorio. En este tipo de desarrollo se trabaja con el cliente para encontrar sus requerimientos y entregar un sistema final. El sistema es mejorado cada vez que existan nuevas propuestas del cliente. 2. Prototipos Desechables. El objetivo de los prototipos desechables es comprender los requerimientos del cliente. Una vez logrado el objetivo se desecha el prototipo actual para construir otro que permita comprender mejor los requerimientos. La principal ventaja de este enfoque se basa en que la especificacin puede desarrollarse en forma creciente, conforme los usuarios adquieran un mayor conocimiento de su problema. Sin embargo, este enfoque tambin presenta algunas deficiencias: El proceso no es visible. Se tienen que realizar entregas regulares de versiones del sistema para medir el progreso, y es muy costoso producir documentos para cada versin del sistema.

Generalmente se tiene una estructura deficiente. Los cambios continuos en el software tienden a descomponer la estructura del sistema, adems su aplicacin es una tarea difcil y costosa. Se requieren herramientas y tecnicas especiales que permitan un desarrollo rpido y que no presenten incompatibilidades entre s.

Modelo de desarrollo Incremental e Iterativo

Una manera de reducir el tiempo de entrega de un sistema, es mediante la utilizacion del desarrollo por fases. El sistema es disenado de tal forma que pueda ser entregado por mdulos, lo que permite que los usuarios dispongan de su parcial funcionalidad a medida que el sistema se encuentra en desarrollo. Los dos enfoques mas conocidos de este modelo son: 1. Desarrollo incremental. 2. Desarrollo iterativo. En el Desarrollo incremental el sistema es fragmentado en subsistemas de acuerdo a su funcionalidad y de como este definido en el documento de requerimientos. Las versiones son definidas iniciando con un mdulo funcional pequeo y con cada nueva versin se agrega funcionalidad al sistema total . Uno de los problemas que presenta este enfoque es la dificultad en la identificacin de los recursos comunes que requieren todos los incrementos. Esto se debe a que los requerimientos no se definen en detalles hasta que un incremento se implemente.

Figura 2.3: Modelo incremental. En el Desarrollo iterativo el sistema es entregado completo, aunque la funcionalidad sea Primitiva, es decir, que las partes del sistema no este funcionando totalmente. Posteriormente cada parte del sistema es reforzado con calidad e implementndose las funcionalidades faltantes en las versiones anteriores

Figura 2.4: Modelo iterativo.

Desarrollo en espiral
El modelo en espiral fue propuesto por Boehm en el ano de 1988. Este modelo representa el proceso de software como una espiral, examina el progreso de desarrollo de software tomando en consideracion los riesgos involucrados para minimizarlos y controlarlos, de esta forma combina las actividades del desarrollo con la gestion del riesgo . El espiral se divide en cuatro sectores que comprenden: la definicion de objetivos, la evaluacion y reduccion de riesgos, el desarrollo y validacion, y por ultimo la planeacion. El modelo del espiral se ajusta al avance de los proyectos, sin embargo requiere de una administracin mucho ms cuidadosa que la del modelo en cascada. El ciclo del espiral comienza con los requerimientos y un plan de desarrollo, agregando una evaluacion de riesgos y construye prototipos alternativos antes de escribir el documento de conceptos de operacion. El documento de conceptos de operacion describe en un alto nivel como debe trabajar el sistema, es decir, especifica un conjunto de requerimientos completos y consistentes. El principal producto de la primera iteracion es el concepto de operaciones, en la segunda iteracion son los requerimientos, en la tercera iteracion el diseno y de la cuarta son las pruebas. Para cada iteracion el analisisde riesgos pondera diferentes alternativas en base de los requerimientos y restricciones, el prototipo verifica el grado de factibilidad antes de elegir alguna alternativa de desarrollo en particular, si se identifican riesgos los lderes del equipo de desarrollo son los que deciden como eliminarlos o minimizarlos.

Modelos de Mtodos Formales

Comprenden un conjunto de actividades que conducen a la especificacin matematica delsoftware. Los metodos formales permiten a los ingenieros de software especificar, desarrollar y verificar un sistema, aplicando una notacion matematica. El enfoque mas conocido del proceso de desarrollo formal es la ingenier a de la sala limpia (clear room), desarrollado por IBM. A pesar de que estos metodos proporcionan mecanismos para reducir muchos de los problemas que son dif ciles de superar con otros enfoques de la Ingeniera de Software, existen situaciones en torno a su aplicabilidad. El desarrollo de modelos formales actualmente es caro y consume mucho tiempo. La mayor a de los desarrolladores no tienen antecedentes necesarios para aplicarlos. No son recomendables utilizarlos como mecanismos de comunicacion con los clientes del sistema, ya que no tienen conocimientos tcnicos.

CONCLUSIN Este modelo es utilizado bsicamente para facilitar a los ingenieros de software el desarrollo de un producto de software mediante la definicin de parmetros y requisitos que permitan satisfacer las necesidades del cliente y el usuario adems de facilitarle el trabajo al desarrollador. Consiste en la representacin de un diseo rpido el mismo que me permite establecer incluso el nivel de aceptacin que tendr el software a desarrollarse. Este modelo es fcil de utilizar y de modificar es utilizado para establecer aspectos del sistema que no son contemplados bien mediante la retroalimentacin , que consiste en analizar las alternativas y en caso de no cubrir las expectativas del usuario/cliente se procede a repetir las etapas para que el sistema a desarrollar sea de calidad. Administracin de Proyectos. 7

REFERENCIAS BIBLIOGRFICAS. Ingeniera de software. Teora y Prctica. Shari Lawrence Peleeger. Un enfoque prctico Roger S. Pressman Mc Graw Hill. Fuentes Consultadas. http://boyso.wordpress.com/2008/04/29/ciclo-de-vida-de-los-sistemas-modelo-por-prototipos/ http://scruz334.blogspot.es/i2007-10/ http://frios334.blogspot.es/i2007-04/ Administracin de Proyectos. 8