FASES: En lneas generales, el proceso y etapas por la que transita todo el proyecto, son: Anlisis Diseo Codificacin Prueba

Instalacin Mantenimiento En la etapa del anlisis se lleva a cabo un estudio de las necesidades, requisitos, restricciones tcnicas-operativas y legales. Se busca dimensionar la complejidad del problema y determinar la viabilidad del mismo. En Diseo se llevan a cabo los primeros bocetos, diagramas, o como se dice vulgarmente: planos, de la solucin planteada. La idea de empezar a elaborar los diagramas es contar con una representacin visual de la magnitud en general del sistema. Ayuda a comprender el problema, detectar las reas dbiles, e incluso los requisitos con ms riesgos, o conflictivos. En Codificacin se empieza a llevar el cdigo fuente... en pocas: la programacin. Prueba consiste en disear los planes de prueba y someter al sistema a las mismas. Se busca explotar el sistema en busca de vulnerabilidades, fallos y errores. Si se detectan problemas, se procede con las mejoras. Una vez comprobado que no posee errores, (en realidad nunca se sabe si han eliminado todos errores, que no se hayan detectado no implica la ausencia de los mismos) se procede con la Instalacin del sistema en el ambiente o lugar en que interactuar. Y por ltimo el Mantenimiento, que consiste en llevar las mejoras, y/o ampliaciones al sistema. Eso es en lneas generales y de forma breve. Como he dicho, es en lneas generales. Existen varios modelos, o paradigmas de desarrollo que estructuran a esas etapas de una u otra forma. El ms sencillo de todos es el Secuencial, Cascada, o Clsico. Los ms comunes son Prototipado, Espiral, UP/USDP/RUP. En las corrientes o rama de los giles, se puede hallar a XP, Scrum, entre otros. Fase De DiseO Y Analisis De Datos 1. DISEO DE SISTEMAS El diseo de sistemas evala las soluciones alternativas y especifica la solucin detallada de tipo informtico. Tambin recibe el nombre de diseo fsico. ste es llevado a cabo por varios diseadores de sistemas, entre los que se incluye el analista de sistemas. En otras situaciones el analista debe elegir o complementar la tecnologa. Sea como sea, el diseo de sistemas se basa en el conocimiento extrado de la planificacin de sistemas y el anlisis del sistema para ponerlo en prctica. 2. Esta fase tiene por finalidad elegir un objetivo de diseo viable. Implcita esta la necesidad de identificar, primero, las soluciones de diseo candidatas. Para saber disear el sistema se deben realizar las siguientes preguntas: Qu proporcin del sistema debera informatizarse? Habra que comprar el software o elaborarlo dentro de la empresa? Si se decide hacer el sistema debera disearse en forma batch (por lotes) u on-line? Debera disearse el sistema por un ordenador principal, un mini ordenador, microordenador o una combinacin de estos tipos? Qu tecnologa de informacin podran usarse para la aplicacin? Fase 1 del diseo: elegir un objetivo de diseo 3. Despus de disear las soluciones candidatas, se evaluar cada una de ellas de acuerdo a los siguientes criterios: Viabilidad tcnica: Es prctica la solucin desde un punto de vista tcnico? Tienen las personas que participan los conocimientos tcnicos suficientes para disear y llevar a trmino esta solucin? Viabilidad operativa: Satisfar la solucin las necesidades de los usuarios? En que medida? Qu opinan los usuarios de la solucin? Viabilidad econmica: En rentable la solucin en lo que se refiere a costes? Viabilidad de fechas: Puede la solucin disearse e implantarse en un plazo aceptable de tiempo? Fase 1 del diseo: elegir un objetivo de diseo 4. Las soluciones no viables no se tomarn ms en cuenta en el futuro del proyecto, sin embargo son factibles varias alternativas del proyecto. Posteriormente el propietario del negocio decide cual ser la mejor solucin. Especficamente los propietarios del sistema pueden elegir una de las siguientes opciones: Aprobar y financiar la propuesta de sistema. Aprobar o financiar una de las propuestas. Rechazar todas las propuestas y cancelar el proyecto o reiniciarlo con nuevas recomendaciones. Aprobar una versin de mbito reducido para el sistema propuestas. Fase 1 del diseo: elegir un objetivo de diseo

 5. Si suponemos que se aprueba al menos una solucin de diseo, la decisin requerir del analista que realice alguna de las acciones siguientes: Adquirir el hardware y/o el software necesario Disear un sistema y su software Una combinacin de ambas opciones Contratar otra empresa que lo haga Si se decide comprar los componentes del nuevo sistema, debern transmitirse las necesidades de paquetes de hardware y/o software apropiadas; si se decide hacer los componentes del nuevo sistema, deben transmitirse las necesidades de diseo apropiadas. Fase 1 del diseo: elegir un objetivo de diseo 6. Esta es una fase que no aplica en muchos CVDS y metodologas; tambin es llamada fase de adquisicin. La razn en que se agrega esta fase al ciclo de vida, es que buena parte del tiempo que transcurre es realizando el pedido y la entrega del mismo; este lapso debe cifrarse en el ciclo de vida con el fin de planificar las fases posteriores. En esta fase el analista de sistema sigue siendo el personaje mas importante, sin embargo tambin participan los vendedores, analistas medios, y responsables de compras. El trabajo de analistas es entonces, evaluar las propuestas y los presupuestos para determinar cuales cumplen las necesidades y las especificaciones, as como cual de ellas es la mas rentable. Fase 2 del diseo: adquirir el hardware y el software necesarios. 7. 1. Analizar y distribuir los datos, para llevar a cabo esta actividad se se lleva a cabo un anlisis adicional considerando cuestiones relativas a la distribucin de los datos, trabajando estrechamente con el usuario para generar un buen modelo de datos que permita el desarrollo de soluciones de archivos y bases de datos. 2. Luego de el anlisis de datos se puede desplazar el foco de atencion a los procesos, organizando la distribucin que los datos van a tomar en el sistema a desarrollar logrando que con la participacin de diseadores y usuarios se incorporen y reflejen las necesidades presentadas durante el diseo del sistema. 3. La siguiente fase se encarga de las especificaciones de deseo de archivos y bases de datos poniendo especial cuidado en un diseo que se pueda adaptar a futuros requisitos y posibles aplicaciones, tambin toman en cuenta la menera en que accedern los programas a los datos con el fin de mejorar el rendimiento. 8. 4. Utilizando nuevamente la interaccin de los desarrolladores con los directivos y los usuarios se van a disear y especificar las entradas y salidas del sistema, definiendo su estructura y el formato logrando asegurar la precision en los datos de entrada, disminuyendo as el margen de error posible y para finalizar establecer un registro de dichas entradas y salidas. 5. Luego se presenta un avance de lo realizado anteriormente se disean interfaces interactivas con el usuario facilitando su comprensin donde se omiten muchos detalles para su rpida modificacin, en caso de necesitarlo. 6. Para finalizar se presenta y revisa el diseo utilizando toda la informacin recopilada en las fases y pasos anteriores. En este paso las especificaciones finales de la redaccin de diseo tcnico se organizan clsicamente en forma de un informe tcnico o un manual de trabajo partiendo del diccionario de proyectos que se inici durante el anlisis del sistema. 9. El anlisis de datos es una tcnica para estructurar los datos en su forma ms simple y flexible. La principal herramienta utilizada son los diagramas de Entidad Relacin que expresan a que entidades pertenecen los datos y sus relaciones. Este proceso se lleva a cabo y se van refinando sus productos desde la fase de anlisis hasta el diseo como tal del sistema. 10. Para efectos de evitar redundancia e inconsistencia de los datos, se aplican tcnicas de normalizacin. Generalmente se manejan las 3 primeras formas normales a saber: 1ra Forma Normal : las entidades no contienen grupos repetidos de atributos. 2da Forma Normal : las entidades no contienen atributos que sean slo parcialmente dependientes de su clave primaria. 3ra Forma Normal : las entidades no contienen atributos que puedan deducirse de los valores de otros atributos de la misma entidad. Al normalizar los datos se puede modificar el DER para incluir nuevas entidades y/o relaciones, eliminar atributos o entidades innecesarias o trasladar atributos a entidades nuevas. Anlisis de Datos 11. La salida del proceso de anlisis de datos es un modelo de datos que sirve como base para generar un modelo fsico que sea implementado por un sistema gestor de base de datos y que se integra y sirve de soporte a los procesos que llevar a cabo el sistema de informacin. Anlisis de Datos 12. Es una tcnica que estudia las entidades de un modelo de datos totalmente normalizado con el fin de identificar los sucesos de empresa y las condiciones que hacen que los datos creen, se modifiquen o se borren. Esta tcnica asegura la integridad de los datos. ANLISIS DE SUCESOS 13. Un suceso de empresa es algo que ocurre y que origina cambios en los datos de la empresa. Los sucesos requieren procesos para utilizar o mantener los datos, entre esos: Creacin, Lectura, Actualizacin, o borrado de una entidad. ANLISIS DE SUCESOS 14. Mtodo paso a paso para el anlisis de sucesos: Identificar los sucesos de las entidades fundamentales. Identificar los sucesos de las entidades asociativas. Agrupar los sucesos comunes. ANLISIS DE SUCESOS 15. El modelo de procesos esencial (DFD lgico) elaborado en la fase de anlisis aparecen los almacenes de datos (Entidades de datos) no normalizados; los cuales son usados y mantenidos por los procesos. Por lo tanto, el modelo de procesos son ahora incompletos. El objetivo es refinar o preparar los modelos de procesos para su implantacin real; a travs del anlisis de sucesos. ANLISIS DE SUCESOS Etapas del proceso La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Anlisis de requerimientos Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del anlisis de requerimientos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de requerimientos, por ejemplo en dos captulos del libro de Sommerville "Ingeniera del software" titulados "Requerimientos del software" y "Procesos de la Ingeniera de Requerimientos". La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requerimientos de software (Software Requirements Specification). Especificacin La especificacin de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requisitos del software. Entre las tcnicas utilizadas para la especificacin de requisitos se encuentran: Caso de uso, Historias de usuario, Siendo los primeros ms rigurosos y formales, los segundas ms giles e informales. Arquitectura La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El arquitecto de software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La arquitectura de sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de software. La arquitectura de software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe en general el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo: Diagramas de clases Diagramas de base de datos Diagrama de despliegue Diagrama de secuencia Siendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qu diagramas elaborar. Las herramientas para el diseo y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran: Enterprise Architect Microsoft Visio for Enterprise Architects Programacin Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado. Prueba Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera

puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara. Documentacin Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. Mantenimiento Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto4 est dedicado a su mantenimiento. Una pequea parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolucin. Modelos y filosofas de desarrollo de software La ingeniera de software dispone de varios modelos, paradigmas y filosofas de desarrollo, en los cuales se apoya para la construccin del software, entre ellos se puede citar: Modelo en cascada o Clsico (modelo tradicional) Modelo de prototipos Modelo en espiral Desarrollo por etapas Desarrollo iterativo y creciente o Iterativo e Incremental RAD (Rapid Application Development) Desarrollo concurrente Proceso Unificado RUP (Proceso Unificado de Rational) DISEO DEL PROTOTIPO Esta etapa toma los requerimientos y especificaciones de la etapa de anlisis y determina la mejor manera de satisfacerlos, segn las apreciaciones del Usuario y del que lo desarrolla. Bosquejo. Despus de haber definido el proyecto y haber planeado el desarrollado del mismo es necesario hacer una presentacin a los Usuarios, de lo que se espera obtener, esto puede ayudar a hacer ms eficiente el prototipo antes de su diseo definitivo. La finalidad de este bosquejo es establecer, a partir del trabajo con los Usuarios, las lneas bsicas del proyecto, principalmente en lo que respecta a funcionalidad y estructura del prototipo. Este diseo rpido normalmente se har de manera sencilla (diagramas o presentaciones en la pantalla de la computadora), pero dar una idea clara al Usuario del tipo de pgina Web con que puede contar y sus alcances. Este bosquejo deber exponer claramente el prototipo, sus alcances, tipo de modelo a desarrollar, el equipo de trabajo, un cronograma, los requerimientos para el diseo y desarrollo, el contenido de la pgina-prototipo, la interfaz y las potencialidades. Una vez realizada la presentacin, el Coordinador podr determinar si la idea ha sido correcta, o si se ha presentado algun desvo con respecto a las metas fijadas, pudiendo en este momento corregir y repensar sin ninguna dificultad el modelo a desarrollar. Diseo detallado. Una vez que el Usuario ha autorizado el bosquejo presentado, es el momento de disear la pgina-prototipo, tomando para ello en cuenta los siguientes aspectos: a. Alojamiento del prototipo: Definir el lugar hosting donde ser colocado el prototipo para su publicacin, de forma que los Usuarios puedan tener acceso a l a travs de Internet. Este alojamiento puede ser: virtual (se alquila o regala, pero no se tiene control sobre l), un servidor propio (el control sobre l es total, pero es caro), y servidor dedicado (se alquila, y es de uso exclusivo). b. Claridad: La informacin tiene que ser clara y concisa, de acuerdo al tipo de Usuario. El prototipo debe estructurarse de manera que la informacin est siempre Localizable, el usuario debe saber en todo momento dnde est y dnde puede ir, pero sin que resulte recargada (Depto. de Marketing y Servicios Internet de Iuris.doc, 2005). c. Contenido: Determinar cul y de que tipo es la informacin que se va a mostrar, con qu recursos materiales y herramientas se cuenta (se van a realizar especialmente para el proyecto o se usarn algunas ya existentes), las bases que albergarn los datos, el o los idiomas en que se presentarn los contenidos, contendr la pgina informacin de

impacto (cul sera?), estar resumida o completa, de que naturaleza es el contenido, cual se imprimir, que hay que resaltar, ayudas, etc. Una vez, enlistado lo anterior, hay que considerar que la informacin debe tener una organizacin que facilite su acceso y la presente como un todo, considerando que la lectura en la Web no es secuencial, debe tenerse especial cuidado en suministrar formas adecuadas para que la navegacin sea directa. Es necesario organizar la informacin, dividirla en reas (lgicas) y ligar a cada una de stas los documentos correspondientes, construyendo una estructura jerrquica, estableciendo niveles y relaciones; la definicin correcta de esta estructura permitir al Usuario encontrar las cosas ms fcilmente. d. Datos generales de la pgina-prototipo: Establecer el nombre de la pgina, el autor, contadores, correos para contactos, copyright, logotipos, colores, emblemas, e. Estandarizacin: El Depto. de Marketing y Servicios Internet de la compaa Iuris.doc recomienda: Tener cuidado en respetar el contenido y no tomar como base para el diseo de la pgina lo atrayente de los elementos grficos, es importante que el prototipo no est cargado facilitando de esta manera la descarga en el momento de visualizarla. Es recomendable utilizar un formato de resolucin de pantalla estndar (actualmente 800x600) que permita a una mayora de usuarios visualizar correctamente la informacin, as como usar diferentes tipologas y versiones de navegador. f. Esquema de navegacin: Realizar un grfico que muestre la pgina de acceso principal al prototipo, los documentos clasificados, y la relacin entre ellos. g. Hardware: Detallar las caractersticas de las computadoras para el desarrollo del prototipo, as como las del servidor. h. Integracin: Conservar la integracin de cada uno de los elementos, es decir, que el diseo de los logotipos, e incluso el lenguaje utilizado, se mantengan homogneos en cada seccin del prototipo. Esta integracin se debe mantener tambin respecto a la estrategia general del Usuario y su imagen hacia el exterior. i. Interactividad: Al respecto el Depto. de Marketing y Servicios Internet de la compaa Iuris.doc seala que la interactividad es el elemento primordial que hace la diferencia entre Internet y otros medios de comunicacin, por lo que es importante aprovechar estos elementos interactivos para conocer a los usuarios y atraerlos a la consulta permanente de la pgina (foros, chats, cuestionarios, juegos, etc.) j. Interfaz: El formato grfico debe estar centrado en el usuario y su accesibilidad, debe ser atractivo para l, crendolo con una lgica visual que represente y optimice la lgica de la estructura de los contenidos, y que sea coherente con los objetivos del proyecto y de la pgina establecidos inicialmente. Carlos Dorado en su artculo El diseo del interfaz y la navegacin seala: Podemos definir el interfaz como: el conjunto de trabajos y pasos que seguir el Usuario, durante todo el tiempo que se relacione con el prototipo, detallando lo que ver y escuchar en cada momento, y las acciones que realizar, as como las respuestas que el sistema le dar. Se tendr especial cuidado en la organizacin de la interfaz, combinando Informacin, elementos de interaccin y la informacin interactiva, y prestando especial atencin a el color, la tipografa, y la integracin de recursos multimedia. k. Software: Es necesario definir el software a utilizar para el desarrollo del prototipo, especificando a detalle sus caractersticas (precio, disponibilidad en el pas, facilidad de uso, potencialidad, etc.) l. Usabilidad: Realizar un anlisis de la usabilidad del prototipo, para prevenir errores futuros, comprobar si el prototipo propuesto es el adecuado, y si realmente es fcil de usar por los Usuarios. Para determinar la usabilidad del producto, se pueden usar las siguientes tcnicas: Detectar pginas similares, que efecten su objetivo de la mejor manera posible, analizndolas para identificar que puede servir como referencia para llevar a cabo acciones parecidas en el prototipo a disear. Que el prototipo sea revisado por un grupo de expertos en usabilidad, mediante una serie de criterios generales previamente definidos, conocidos y aceptados por la comunidad de expertos en el rea Modelo de prototipos El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin

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 y el cliente vea resultados a corto plazo. Contenido 1 Etapas 2 Ventajas 3 Inconvenientes 4 Conclusiones 5 Vase tambin Etapas Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin Comunicacin Ventajas 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 humano-mquina. La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el producto. Inconvenientes El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, 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 funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final... Conclusiones A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma efectivo para la ingeniera 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: Que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos. Que el prototipo se descarte, al menos en parte. Que despus se desarrolle el software real con un enfoque hacia la calidad.