PROCESO DE CREACION DE PROTOTIPOS DE SOFTWARE

PRESENTADO POR: VICTOR BARRIOS ALVAREZ ALVARO CRUZ TEJEDA FELIX ESCOBAR CALVETE

GRUPO: AD

PRESENTADO A: MSC. OSVALDO PUELLO

ASIGNATURA: PARADIGMAS DE PROGRAMACION

CORPORACION UNIVERSITARIA DE LA COSTA FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS

BARRANQUILLA COLOMBIA 2011

INTRODUCCION.
Es muy importante que en la actualidad, el ingeniero de software deba saber a profundidad, las necesidades de un cliente, para poder saber que quiere hacer con un determinado software, como funcionara y los requisitos que necesitara dicho software para funcionar excelentemente. Pero para ello debemos recurrir a ciertas normas o directrices para tener un modelo que nos permita realizar un software de calidad. Estos son los prototipos de software. Mas adelante se hablara sobre este concepto, el cual es un tema muy importante en el proceso de la creacion de un software, ya que es de aqu , que parte si el software funcionara o no.

QUE ES UN PROTOTIPO DE SOFTWARE? Por lo general los clientes y usuarios finales del software encuentran muy difcil expresar sus requerimientos reales. Es casi imposible predecir la manera en que un sistema afectar el trabajo diario, como interactuar con otros sistemas y qu operaciones del usuario se deberan automatizar. Sin embargo es posible probar el sistema si est disponible un prototipo de l. De aqu deducimos que un prototipo de software es una versin inicial de un sistema de software que se utiliza para demostrar los conceptos, probar las opciones de diseo y entender mejor el problema y su solucin. En el siguiente ejemplo presentamos un prototipo de software de un programa de registro de clientes. Vea con detalles sus campos:

Un prototipo de software apoya dos actividades del proceso de ingeniera de requerimientos: 1. Obtencin de requerimientos: los usuarios experimentan como el sistema ayudar su trabajo.

2. Validacin de requerimientos: el prototipo puede revelar errores u omisiones en los requerimientos propuestos. LA CREACION DE PROTOTIPOS DE SOFTWARE. Para la creacin de un prototipo de software, hay que hacer un anlisis profundo del problema que se desea resolver. Este anlisis hay que hacerlo independientemente del paradigma que deseamos utilizar. Pero tambin hay que tener en cuenta las limitaciones de dicho paradigma y establecer un modelo o patrn que nos permita crear un prototipo de calidad, que sea valorado tanto por el cliente, como por el mismo desarrollador. Hay ocasiones, en que hay que construir el prototipo antes de hacer el anlisis, pues se presenta el caso en que el paradigma presenta ciertas limitaciones que no cumplen con ciertas soluciones al problema, ejemplo: Un botn que acumule las ventas acumuladas del da, haciendo referencia a una base de datos, es algo que algunos paradigmas de programacin no pueden hacer. SELECCIN DE ENFOQUE DE CREACION DE PROTOTIPOS. El modelo de creacin de prototipos de software puede ser cerrado o abierto. Un modelo cerrado o tambin llamado prototipo desechable, es aquel que hace una basta demostracin de los requisitos, es decir, muestra si el programa va a servir o no, pero nada mas. En este caso, el prototipo se desecha, y se realiza con el paradigma que va a solucionar el problema de forma radical. El modelo abierto, o tambin llamado prototipo evolutivo, emplea el prototipo como la primera parte del anlisis del problema, que seguir con su diseo y su construccin. Ahora nos planteamos una pregunta: Que debemos mirar para determinar si un prototipo es o no una alternativa viable? Antes de elegir un enfoque abierto o cerrado, es necesario saber si se puede crear un prototipo del sistema a construir, por ejemplo: Una base de datos de ventas de un almacn de ropa, es algo que se puede crear un

prototipo. Se pueden definir varios factores candidatos a la creacin de prototipos: rea de aplicacin Complejidad Caractersticas del cliente Caractersticas del proyecto Cualquier aplicacin que cree pantallas visuales dinmicas, interacte intensamente con el usuario y realice los algoritmos de una manera sencilla y rpida, es un buen candidato para la creacin de un prototipo de software. Sin embargo, estas reas de aplicacin deben estar acorde con la complejidad de la aplicacin, por ejemplo: si una aplicacin candidata, con las caractersticas puestas anteriormente, va a requerir el desarrollo de decenas de miles de lneas de cdigo, antes de realizar cualquier funcin demostrable, es muy probable que sea demasiado compleja para crear un prototipo con las caractersticas mencionadas anteriormente. MTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS. Para que la creacin del prototipo de software sea efectiva, debe desarrollarse rpidamente, para que el cliente pueda valorar los resultados y recomendar los cambios a tiempo. Hay disponibles 3 clases genricas de mtodos y herramientas: Tcnicas de cuarta generacin (T4G): comprenden una amplia gama de lenguajes de consulta e informes de bases de datos, generadores de programas, y aplicaciones de otro nivel. Como las tcnicas T4G permiten al ingeniero de software generar cdigo ejecutable rpidamente, son los ideales para la creacin rpida de prototipos. Componentes de software reutilizables: consiste en tomar un software que cumpla con los objetivos parecidos y hacer una especie de reutilizacin de el, creando un nuevo y mejorado producto competitivo.

A continuacin se muestra una tabla que muestra cual es la seleccin de enfoque apropiado para la creacin de un prototipo:

ESPECIFICACION En muchas reas como la ingeniera el trmino especificacin representa un documento tcnico oficial que establezca de forma clara todas las caractersticas, los materiales y los servicios necesarios para producir componentes destinados a la obtencin de productos. Estos incluyen requerimientos para la conservacin de dichos productos, su empaquetamiento, almacenaje y marcado as como los procedimientos para determinar su obtencin exitosa y medir su calidad. ESPECIFICACION EN LA CREACION DE PROTOTIPOS DE SOFTWARE Como se haba dicho anteriormente la especificacin hace referencia a la calidad de la solucin, ahora se estudiara la especificacin orientada a la creacin de prototipos de software. Los ingenieros de software en diversos casos se ven obligados a trabajar con especificaciones incompletas, inconscientes o engaosas. Todo esto en la gran mayora de casos se ven reflejados en la calidad, la fecha de entrega y el alcance del software.

PRINCIPIOS DE LA ESPECIFICACION La especificacin independientemente del modo en cmo se realice puede verse como un proceso de representacin. Los requisitos se representan de manera que como fin ltimo lleven al xito de la implementacin del software. A continuacin se presentan estos principios bsicos:

Establecer el contenido y la estructura de una especificacion de manera que acepte cambios

Separar la funcionalidad de la implementacion

Reconocer que la especificacion debe ser tolerante a un posible crecimiento si no es completa

Desarrollar un modelo del comporatamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estimulos del entorno

Crear un modelo intuitivo en vez de un diseo o modelo de implementacion

Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactuan con el

Definir el entorno en que va a operar el sistema

REPRESENTACION Ya hemos observado que los requisitos del software pueden de varias maneras. Sin embargo si al momento de presentarlos se hacen mediante un documento escrito o un medio electrnico, se hace necesario seguir

unas series de pautas o directrices. Esto es lo que llamamos representacin. PAUTAS PARA REPRESENTAR LOS REQUISITOS El formato de la representacin y el contenido deberan estar relacionados con el problema: se puede desarrollar un esbozo general del contenido de la especificacin de los requisitos de software. Sin embargo las formas de representacin contenidas en la especificacin pueden llegar a variar con el rea de aplicacin. La informacin contenida dentro de la especificacin debera estar escalonada: las representaciones deberan revelar capas de informacin de manera que el lector se pueda mover en el nivel de detalle requerido. La numeracin de prrafos y diagramas deberan indicar el nivel de detalle que se muestra. Los diagramas y otras formas de notacin deberan restringirse en nmeros y ser consientes en su empleo: las notaciones confusas o inconscientes tanto graficas como simblicas degradan la comprensin y fomentan errores. Las representaciones deben permitir revisiones.

LA ESPECIFICACIN DE LOS REQUISITOS DEL SOFTWARE La especificacin de los requisitos del software se produce con la culminacin de la tarea de anlisis. La funcin y rendimiento asignados al software como parte de la ingeniera de sistemas se retinan estableciendo una completa descripcin de la informacin. Una descripcin completa de la funcin y comportamiento, una indicacin de los requisitos del rendimiento y restricciones de diseo, criterios de validacin apropiados y otros datos pertinentes a los requisitos. Las partes de la especificacin de los requisitos del software son: INTRODUCCIN: en esta parte se establece las metas y objetivos del software, describindolo dentro del contexto computacional, de hecho la introduccin no es ms que el alcance del software dentro del documento de planificacin.

LA DESCRIPCIN DE LA INFORMACIN: proporciona una detallada descripcin del problema que el software va a resolver. Se documentan el contenido de la informacin y sus relaciones, flujo y estructura, en esta parte se describen las interfaces, hardware, software y humanas para los elementos externos del sistema y para las funciones internas del software. DESCRIPCIN FUNCIONAL: se describen todas las funciones requeridas para solucionar el problema. En esta parte se da una descripcin detallada del proceso de cada funcin, se establecen y justifica las restricciones de diseo; se establecen las caractersticas del rendimiento, y se incluyen uno o ms diagramas para representar grficamente la estructura global del software y otros elementos del sistema. DESCRIPCIN DEL COMPORTAMIENTO: en esta parte se examina la operativa del software como consecuencia de acontecimientos externos y como caractersticas de control generadas internamente. CRITERIOS DE VALIDACIN: esta seccin es ignorada porque para completarla se necesita una profunda compresin de los requisitos del software, algo que a menudo no se posee llegados a esta etapa. Sin embargo, la especificacin de los criterios de validacin acta como una revisin implcita de todos los dems requisitos. Bibliografa y apndices. En muchos casos la especificacin de los requisitos del software suele estar acompaada de un prototipo ejecutable, un prototipo en papel o un manual de usuario preliminar. El manual de usuario preliminar presenta al software como una caja negra. Es decir se pone gran nfasis en las entradas de usuario y las salidas obtenidas. El manual puede ayudar como una herramienta para descubrir problemas en la interfaz hombremquina.

REVISIN DE LA ESPECIFICACIN La revisin de la especificacin del software es llevada a cabo por el desarrollado y el cliente. Como la especificacin forma el fundamento para el diseo y las subsiguientes actividades de la ingeniera del software, en necesario poner extremo cuidado al realizar la revisin. Inicialmente la revisin se lleva a cabo a nivel macroscpico. A este nivel, los revisores hacen el intento de asegurar de que la especificacin sea completa, consiente y correcta en cuanto a la informacin general, funcional y de los dominios del comportamiento son considerados. Una exploracin completa de cada uno de estos dominios, la revisin profundiza en el detalle, examinando no solo las descripciones superficiales, sino la va en que los requisitos son expresados. Una vez que se ha completado la revisin, se firma la especificacin de requisitos del software por el cliente y el desarrollador. La especificacin se convierte en un contrato para el desarrollo del software. Las peticiones de cambio en los requisitos una vez que se ha finalizado la especificacin no se eliminaran, pero el cliente debe tener en cuenta que cada cambio posterior significa una ampliacin del mbito del software y por lo tanto puede aumentar los costos y prolongar los plazos de la planificacin temporal del proyecto.

BIBLIOGRAFIA CONSULTADA

Ingenieria del software Roger S. Pressman, 5 edicion editorial: Mc Graw Hill.