FASES: En líneas generales, el proceso y etapas por la que transita todo el proyecto, son:
Análisis Diseño Codificación Prueba Instalación Mantenimiento En la etapa del análisis se lleva a cabo un estudio de las necesidades, requisitos, restricciones técnicas-operativas y legales. Se busca dimensionar la complejidad del problema y determinar la viabilidad del mismo. En Diseño se llevan a cabo los primeros bocetos, diagramas, o como se dice vulgarmente: planos, de la solución planteada. planteada. La idea de empezar a elaborar los diagramas diagramas es contar con una representación representación visual de la magnitud magnitud en general del sistema. Ayuda a comprender comprender el problema, problema, detectar las áreas débiles, e incluso los requisitos con más riesgos, o conflictivos. En Codificación se empieza a llevar el código fuente... en pocas: la programación. Prueba consiste en diseñar los planes de prueba y someter al sistema a las mismas. Se busca explotar el sistema en busca de vulnerabil vulnerabilidades, idades, fallos fallos y errores. Si Si se detectan detectan problemas, problemas, se procede procede con las mejoras. mejoras. Una vez comprobado que no posee errores, (en realidad nunca se sabe si han eliminado todos errores, que no se hayan detectado detectado no implica implica la ausencia de los mismos) se procede con la Instalación Instalación 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 líneas generales y de forma breve. Como he dicho, es en líneas generales. Existen varios modelos, o paradigmas paradigmas de desarrollo desarrollo que estructuran estructuran a esas etapas de una u otra forma. El más sencillo de todos es el Secuencial, Cascada, o Clásico. Los más 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 DiseñO Y Analisis De Datos
• 1. DISEÑO DISEÑO DE SISTEMA SISTEMAS S El diseño diseño de sistema sistemass evalúa las solucione solucioness alternativ alternativas as y especifi especifica ca la solución solución detallada de tipo informático. También recibe el nombre de diseño físico. Éste es llevado a cabo por varios diseñadores de sistemas, entre los que se incluye el analista de sistemas. En otras situaciones el analista debe elegir o complementar la tecnología. Sea como sea, el diseño de sistemas se basa en el conocimiento extraído de la planificación planificación de sistemas sistemas y el el análisis del del sistema sistema para ponerlo ponerlo en práctica. práctica. • 2. Esta fase tiene por finalidad finalidad elegir elegir un objetivo objetivo de diseño diseño viable. viable. Implícit Implícitaa esta la necesida necesidadd de identif identifica icar, r, primero, las soluciones de diseño candidatas. candidatas. Para saber diseñar el sistema se deben realizar realizar las siguientes siguientes preguntas: preguntas: ¿Qué proporción proporción del sistema debería informatizarse? informatizarse? ¿Habría que comprar el software o elaborarlo elaborarlo dentro de la empresa? Si se decide hacer el sistema ¿debería diseñarse en forma batch (por lotes) u on-line? Debería diseñarse el sistema por un ordenador principal, un mini ordenador, microordenador o una combinación de estos tipos? ¿Qué tecnología de información podrían usarse para la aplicación? Fase 1 del diseño: elegir un objetivo de diseño • 3. Después Después de diseñar diseñar las soluciones soluciones candida candidatas tas,, se evaluará evaluará cada una de ellas ellas de acuerdo a los siguient siguientes es criterios: Viabilidad técnica: ¿Es práctica la solución desde un punto de vista técnico? ¿Tienen las personas que participan participan los conocimientos conocimientos técnicos suficientes suficientes para diseñar y llevar a término esta solución? Viabilidad Viabilidad operativa: operativa: ¿Satisfará la solución las necesidades de los usuarios? ¿En que medida? ¿Qué opinan los usuarios de la solución? Viabilidad económica: ¿En rentable la solución en lo que se refiere a costes? Viabilidad de fechas: ¿Puede la solución diseñarse e implantarse implantarse en un plazo aceptable aceptable de tiempo? tiempo? Fase 1 del diseño: elegir un objetivo de diseño • 4. Las solucione solucioness no viables viables no se tomarán tomarán más en cuenta cuenta en el futuro futuro del proyect proyecto, o, sin embargo embargo son factibles factibles varias alternativas del proyecto. Posteriormente el propietario del negocio decide cual será la mejor solución. Específicamente Específicamente los propietarios del sistema pueden elegir una de las siguientes opciones: Aprobar y financiar la propuesta propuesta de sistema. sistema. Aprobar o financiar financiar una de las propuestas. propuestas. Rechazar todas las propuestas propuestas y cancelar cancelar el proyecto proyecto o reiniciarlo reiniciarlo con nuevas recomendaciones. recomendaciones. Aprobar una versión de ámbito ámbito reducido para el sistema propuestas. propuestas. Fase 1 del del diseño: elegir elegir un objetivo objetivo de de diseño
• 5. Si suponemos que se aprueba al menos una solución de diseño, la decisión requerirá del analista que realice alguna de las acciones siguientes: Adquirir el hardware y/o el software necesario Diseñar un sistema y su software Una combinación de ambas opciones Contratar otra empresa que lo haga Si se decide comprar los componentes del nuevo sistema, deberán 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 diseño apropiadas. Fase 1 del diseño: elegir un objetivo de diseño • 6. Esta es una fase que no aplica en muchos CVDS y metodologías; también es llamada fase de adquisición. La razón 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 también 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 diseño: 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 análisis adicional considerando cuestiones relativas a la distribución 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 análisis de datos se puede desplazar el foco de atencion a los procesos, organizando la distribución que los datos van a tomar en el sistema a desarrollar logrando que con la participación de diseñadores y usuarios se incorporen y reflejen las necesidades presentadas durante el diseño del sistema. 3. La siguiente fase se encarga de las especificaciones de deseño de archivos y bases de datos poniendo especial cuidado en un diseño que se pueda adaptar a futuros requisitos y posibles aplicaciones, también toman en cuenta la menera en que accederán los programas a los datos con el fin de mejorar el rendimiento. • 8. 4. Utilizando nuevamente la interacción de los desarrolladores con los directivos y los usuarios se van a diseñar 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 diseñan interfaces interactivas con el usuario facilitando su comprensión donde se omiten muchos detalles para su rápida modificación, en caso de necesitarlo. 6. Para finalizar se presenta y revisa el diseño utilizando toda la información recopilada en las fases y pasos anteriores. En este paso las especificaciones finales de la redacción de diseño técnico se organizan clásicamente en forma de un informe técnico o un manual de trabajo partiendo del diccionario de proyectos que se inició durante el análisis del sistema. • 9. El análisis de datos es una técnica para estructurar los datos en su forma más simple y flexible. La principal herramienta utilizada son los diagramas de Entidad – Relación 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 análisis hasta el diseño como tal del sistema. • 10. Para efectos de evitar redundancia e inconsistencia de los datos, se aplican técnicas de normalización. 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 sólo 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. Análisis de Datos • 11. La salida del proceso de análisis de datos es un modelo de datos que sirve como base para generar un modelo físico 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 información. Análisis de Datos • 12. Es una técnica 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 técnica asegura la integridad de los datos. ANÁLISIS 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: Creación, Lectura, Actualización, o borrado de una entidad. ANÁLISIS DE SUCESOS • 14. Método paso a paso para el análisis de sucesos: Identificar los sucesos de las entidades fundamentales. Identificar los sucesos de las entidades asociativas. Agrupar los sucesos comunes. ANÁLISIS DE SUCESOS • 15. El modelo de procesos esencial (DFD lógico) elaborado en la fase de análisis 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 implantación real; a través del análisis de sucesos. ANÁLISIS DE SUCESOS Etapas del proceso La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:
Análisis 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 ingeniería de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación 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 aún no está formalizada, ya se habla de la Ingeniería de requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería del software" titulados "Requerimientos del software" y "Procesos de la Ingeniería de Requerimientos". La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requerimientos de software (Software Requirements Specification). Especificación La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software. Entre las técnicas utilizadas para la especificación de requisitos se encuentran: Caso de uso, Historias de usuario, Siendo los primeros más rigurosos y formales, los segundas más ágiles e informales. Arquitectura La integración 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 añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software. La arquitectura de software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación 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 mínimos 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 diseño y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran: Enterprise Architect Microsoft Visio for Enterprise Architects • • • •
• •
Programación Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado. Prueba Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica 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 evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera
puede entenderlos y el software hace las cosas tal y como están 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 aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. Documentación Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito 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 más 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 pequeña 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 evolución. Modelos y filosofías de desarrollo de software La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede citar: Modelo en cascada o Clásico (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) • • • • • • • • •
DISEÑO DEL PROTOTIPO Esta etapa toma los requerimientos y especificaciones de la etapa de análisis y determina la mejor manera de satisfacerlos, según las apreciaciones del Usuario y del que lo desarrolla. Bosquejo. Después de haber definido el proyecto y haber planeado el desarrollado del mismo es necesario hacer una presentación a los Usuarios, de lo que se espera obtener, esto puede ayudar a hacer más eficiente el prototipo antes de su diseño definitivo. La finalidad de este bosquejo es establecer, a partir del trabajo con los Usuarios, las líneas básicas del proyecto, principalmente en lo que respecta a funcionalidad y estructura del prototipo. Este “diseño rápido” 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 página 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 diseño y desarrollo, el contenido de la página-prototipo, la interfaz y las potencialidades. Una vez realizada la presentación, el Coordinador podrá determinar si la idea ha sido correcta, o si se ha presentado algun desvío con respecto a las metas fijadas, pudiendo en este momento corregir y “repensar” sin ninguna dificultad el modelo a desarrollar. Diseño detallado. Una vez que el Usuario ha autorizado el “bosquejo” presentado, es el momento de diseñar la página-prototipo, tomando para ello en cuenta los siguientes aspectos: a. Alojamiento del prototipo: Definir el lugar “hosting” donde será colocado el prototipo para su publicación, de forma que los Usuarios puedan tener acceso a él a través 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 información tiene que ser clara y concisa, de acuerdo al tipo de Usuario. El prototipo debe estructurarse de manera que la información esté siempre Localizable, el usuario debe saber en todo momento dónde está y dónde puede ir, pero sin que resulte recargada” (Depto. de Marketing y Servicios Internet de Iuris.doc, 2005). c. Contenido: Determinar cuál y de que tipo es la información que se va a mostrar, con qué recursos materiales y herramientas se cuenta (se van a realizar especialmente para el proyecto o se usarán algunas ya existentes), las bases que albergarán los datos, el o los idiomas en que se presentarán los contenidos, contendrá la página información de
impacto (¿cuál sería?), 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 información debe tener una organización 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 navegación sea directa. Es necesario organizar la información, dividirla en áreas (lógicas) y ligar a cada una de éstas los documentos correspondientes, construyendo una estructura jerárquica, estableciendo niveles y relaciones; la definición correcta de esta estructura permitirá al Usuario encontrar “las cosas” más fácilmente. d. Datos generales de la página-prototipo: Establecer el nombre de la página, el autor, contadores, correos para contactos, copyright, logotipos, colores, emblemas, e. Estandarización: El Depto. de Marketing y Servicios Internet de la compañía “Iuris.doc” recomienda: Tener cuidado en respetar el contenido y no tomar como base para el diseño de la página lo atrayente de los elementos gráficos, 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 resolución de pantalla estándar (actualmente 800x600) que permita a una mayoría de usuarios visualizar correctamente la información, así como usar diferentes tipologías y versiones de navegador. f. Esquema de navegación: Realizar un gráfico que muestre la página de acceso principal al prototipo, los documentos clasificados, y la relación entre ellos. g. Hardware: Detallar las características de las computadoras para el desarrollo del prototipo, así como las del servidor. h. Integración: Conservar la integración de cada uno de los elementos, es decir, que el diseño de los logotipos, e incluso el lenguaje utilizado, se mantengan homogéneos en cada sección del prototipo. Esta integración se debe mantener también 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 compañía “Iuris.doc” señala que la interactividad es el elemento primordial que “hace la diferencia” entre Internet y otros medios de comunicación, por lo que es importante aprovechar estos elementos interactivos para conocer a los usuarios y atraerlos a la consulta permanente de la página (foros, chats, cuestionarios, juegos, etc.) j. Interfaz: El formato gráfico debe estar centrado en el usuario y su accesibilidad, debe ser atractivo para él, creándolo con una lógica visual que represente y optimice la lógica de la estructura de los contenidos, y que sea coherente con los objetivos del proyecto y de la página establecidos inicialmente. Carlos Dorado en su artículo “El diseño del interfaz y la navegación” señala: “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 organización de la interfaz, combinando Información, elementos de interacción y la información interactiva, y prestando especial atención a el color, la tipografía, y la integración de recursos multimedia. k. Software: Es necesario definir el software a utilizar para el desarrollo del prototipo, especificando a detalle sus características (precio, disponibilidad en el país, facilidad de uso, potencialidad, etc.) l. Usabilidad: Realizar un análisis de la usabilidad del prototipo, para prevenir errores futuros, comprobar si el prototipo propuesto es el adecuado, y si realmente es fácil de usar por los Usuarios. Para determinar la usabilidad del producto, se pueden usar las siguientes técnicas: • Detectar páginas similares, que efectúen su objetivo de la mejor manera posible, analizándolas para identificar que puede servir como referencia para llevar a cabo acciones parecidas en el prototipo a diseñar. • 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 Ingeniería 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 diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción
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 Véase también Etapas
Plan rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación 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. También 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 debería tomar la interacción humano-máquina. • • • • •
•
•
La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica 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 construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más 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 intención de crear un prototipo de forma rápida, 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 función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón 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 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 acuerdo en: Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos. Que el prototipo se descarte, al menos en parte. Que después se desarrolle el software real con un enfoque hacia la calidad. •
•
• • •
