Diseño e implementación de software

Texto completo

(1)Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. UNIVERSIDAD NACIONAL DE TRUJILLO FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. ESCUELA ACADEMICO-PROFESIONAL DE INFORMATICA. TITULO:. “DISEÑO E IMPLEMENTACION DE SOFTWARE”. B. IB. LI. O. T. E. INFORME DE TESINA PARA OPTAR EL TITULO DE: INGENIERO INFORMATICO. AUTOR: BR. DAISY MARIANA RUBIO AMES. ASESOR: MG. CARLOS CASTILLO DIESTRA. TRUJILLO – PERU 2012. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(2) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. DEDICATORIA. Dedico esta Tesina a mi familia, por su constante apoyo a lo largo. B. IB. LI. O. T. E. de mis años de estudio.. 2 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(3) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. ÍNDICE Resumen. 8. I. Introducción. 9 10. 2. Determinación del Tema de Estudio. 10. 3. Objetivos. 11. 4. Métodos. 11. 5. Alcances. 11. S. 1. Contextualización Temática. III. Modelos de Procesos del Ciclo de Vida del Software. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. 1. Modelo en Cascada. S. II. Antecedentes. IC. A. 6. Justificación. 13 14 14. 1.1 Descripción. 14. 1.2 Actividades del Modelo. 15. 1.3 Critica del Modelo. 17. 2. Desarrollo Basado en Componentes. 17. 2.1 Descripción. 17. 2.2 Actividades del Modelo. 18. 2.3 Crítica del Modelo. 20. 3. Proceso Unificado del Software. 20. 3.1 Descripción. 20. 3.2 Actividades del Modelo. 21. 3.3 Crítica del Modelo. 23. T. E. IV. Estándar IEEE Desarrollo del Proceso del Ciclo de Vida del Software. O. V. Diseño e Implementación de Software. LI. 1. Actividades del Diseño de software. IB. 1.1 Diseño Arquitectónico. B. 12. 23 25 26 26. 1.1.1. Objetivos de la Iteración. 27. 1.1.2. Casos de Uso. 28. 1.1.3. Esquema del Sistema. 29. 1.1.4. Identificar Riesgos. 32. 1.1.5. Arquitecturas Candidatas. 32. 1.2 Diseño de Base de Datos. 33. 1.2.1. Diseño del Modelo Conceptual. 34. 1.2.2. Diseño del Modelo Lógico. 35. 1.2.3. Diseño del Modelo Físico. 35. 1.3 Diseño de la Interfaz de Usuario. 36 3. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(4) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1.3.1. Análisis de Usuario. 39. 1.3.2. Diseño de Interfaz. 40. 1.3.3. Implementación. 40. 1.3.4. Validación de Interfaz. 41. 1.4 Diseño Detallado. 42. Planificación del Diseño Detallado. 44. 1.4.2. Creación del Diseño Detallado. 44. 1.4.3. Documentación y Comunicación del Diseño. 45. 1.4.4. Planificación del Desarrollo. A. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. 2.2 Documentación. IC. 2.1 Codificación. S. 2. Actividades de Implementación. S. 1.4.1. 2.3 Integración. 45 45 45 48 53 55. VII. REFERENCIAS BIBLIOGRÁFICAS. 56. B. IB. LI. O. T. E. VI. CONCLUSIONES. 4 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(5) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. ÍNDICE DE FIGURAS 15. Fig. 2: Desarrollo Basado en Componentes. 18. Fig. 3: Actividades de RUP. 21. Fig. 4: Actividades del Diseño Arquitectónico. 27. Fig. 5: Aplicaciones según su arquitectura. 34. Fig. 6: Proceso Diseño de Interfaz de Usuario. 38. S. Fig. 1: Modelo en Cascada. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Fig. 10: Arquitectura del Sistema de Mantenimiento. IC. Fig. 9: Etapas de la Codificación. S. Fig. 8: Implementación de Software. A. Fig. 7: Validación de la Interfaz de Usuario. 42 43 48 55 57. Fig. 12: Interfaz Sistema de Mantenimiento. 58. Fig. 13: Tecnologías de acceso ERP Datcorp. 60. Fig. 14: Interfaz Principal ERP Datcorp. 61. Fig. 15: Pantallas Modulos ERP Datcorp. 62. B. IB. LI. O. T. E. Fig. 11: Interfaz Modulo Intranet. 5 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(6) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. ÍNDICE DE TABLAS 25. Tab. 2: Estándar IEEE Actividades Diseño e Implementación. 25. Tab. 3: Aplicaciones según su arquitectura. 30. Tab. 4: Aspectos del sistema y Estilos Arquitecturales. 31. B. IB. LI. O. T. E. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. Tab. 1: Estándar IEEE Ciclo de Vida del Software. 6 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(7) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. RESUMEN La presente Tesina se centra en el estudio del Ciclo de Vida del Software, específicamente en lo referente a las actividades del Diseño e Implementación de Software.. A. S. Inicialmente se describen tres modelos principales del Ciclo de Vida, estos son:. S. características, ventajas y desventajas.. IC. Cascada, Desarrollo Basado en Componentes y RUP, detallando sus principales. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Como modelo base para el estudio del tema central, se ha tomado el estándar IEEE del Ciclo de Vida del Software.. De esta manera, se define el conjunto de actividades dentro del proceso de Diseño e Implementación, considerando el tipo de aplicación que se desarrolla y además con el. B. IB. LI. O. T. E. objetivo de construir un software de calidad.. 7 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(8) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. ABSTRACT This Thesis focuses on the study of Life Cycle Software, specifically in relation to the activities of the Design and Implementation of Software. Initially described three main models Lifecycle, these are: Cascade, Component-Based. A. S. Development and RUP, describing its main features, advantages and disadvantages.. activities defined within the Design and Implementation process,. S. Thus, this set of. IC. Basic model for studying the central theme is taken from IEEE Software Life Cycle.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. considering the type of application that is developed and also with the goal of building. B. IB. LI. O. T. E. quality software.. 8 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(9) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. I. INTRODUCCION En el contexto de la Ingeniería de Software, un tema fundamental de estudio se centra en el proceso de construcción del software, debido a la complejidad que conlleva la entrega de un producto de calidad, atendiendo las necesidades del mercado.. S. Entendemos como un proceso de software al conjunto de actividades (pueden ser. IC. A. automatizadas) para construir un producto software. La estructura de estas actividades. S. es elegida por los responsables del proyecto, teniendo en cuenta los requerimientos y. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. limitaciones tanto del cliente como de la tecnología a emplear.. Aunque existen muchos procesos diferentes de software, algunas actividades fundamentales son comunes para todos ellos:. a. Especificación del software: Se debe definir la funcionalidad del software y las restricciones en su operación.. b. Diseño e implementación del software: Se debe producir software que cumpla su especificación.. T. E. c. Validación del software: Se debe validar el software para asegurar que hace lo que. O. el cliente desea.. IB. LI. d. Evolución del software: El software debe evolucionar para cubrir las necesidades. B. cambiantes del cliente. Cada actividad tiene un impacto en el producto final.. Este trabajo se centra en las fases del Diseño e Implementación dentro del ciclo de vida genérico a todo producto software. Para ello se toma como base el estándar de la IEEE del Desarrollo del Ciclo de Vida de Software.. 9 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(10) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1. Contextualización Temática En Ciencia de la Computación, la rama de la Ingeniería de Software trata sobre los temas de producción de software, desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. Existen diversos enfoques para elegir un conjunto de procesos adecuado, lo que se denomina Ciclo. S. de Vida del Software..  Análisis.  Pruebas. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ.  Diseño e Implementación. S. IC. A. Un modelo de Ciclo de Vida está compuesto básicamente de las siguientes fases:.  Mantenimiento. Cada una de estas fases está compuesta por sus propias actividades y un conjunto de resultados esperados al final de cada fase.. 2. Determinación del Tema de estudio. El Diseño e Implementación de Software es una fase dentro del Ciclo de Vida del. E. Software, generalmente es precedida por otras fases como Análisis y Definición de. T. Requerimientos.. LI. O. La fase de Diseño e Implementación define los procesos para la construcción del. IB. software. Algunas tareas en esta etapa son: Diseño arquitectónico, diseño de Base. B. de Datos, diseño de interfaces de usuario, etc. Al terminar esta etapa, el software está listo para las pruebas iniciales de su funcionamiento y revisión por parte del usuario.. 10 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(11) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 3. Objetivos 3.1 Objetivo General Establecer un marco de referencia para los responsables del proceso de Ingeniería de Software para tomar decisiones adecuadas en las etapas de Diseño e. A. S. Implementación y de esta manera la entrega de un producto software de calidad.. IC. 3.2 Objetivos específicos. S.  Describir las generalidades de todo proceso de Ingeniería del Software.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ.  Describir las actividades dentro del proceso de Diseño de Software.  Describir las actividades dentro de proceso de Implementación de Software.  Explicar la importancia de aplicar un proceso definido dentro del desarrollo de software.. 4. Métodos.  Recopilación de información.  Investigación bibliográfica.. E.  Revisión y análisis de la bibliografía.. LI. O. T.  Clasificación de la Información. B. IB. 5. Alcances Esta Tesina comprende la descripción y análisis de cada una de las actividades dentro del Diseño e Implementación de Software tomando como base el estándar de la IEEE del Ciclo de Vida del Software.. 11 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(12) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 6. Justificación Dado que el proceso de construcción de software, es un proceso complejo, los profesionales de Ingeniería de Software tienen retos constantes tales como: enfrentarse con la creciente diversidad de aplicaciones, las demandas para reducir los tiempos de entrega, los avances tecnológicos, etc. Todo esto con el objetivo del. IC. A. S. desarrollo de software fiable.. S. En ese sentido, conocer las mejores prácticas dentro del Ciclo de Vida del Software,. calidad.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. es un punto fundamental para cumplir con la entrega de un producto software de. Actualmente existen diversos modelos de procesos de software, los cuales pueden ser aplicados según el tipo de proyecto, en base a la experiencia o considerando el punto de vista del profesional responsable. Entre los diversos modelos, se comparten actividades comunes, como es el caso de las actividades de Diseño e Implementación.. T. E. Según lo descrito, este trabajo tiene el propósito de servir como guía a los. O. profesionales de software, dando nuevos alcances y actualización de sus. IB. LI. conocimientos en el área. De esta manera el desarrollador de software puede. B. convertir el sistema implementado en un producto de calidad, acorde con los requisitos del usuario.. 12 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(13) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. II. ANTECEDENTES Presentamos como antecedentes las siguientes investigaciones realizadas sobre los ciclos de vida del software:. Investigación: “Tecnologías de Información: Procesos del Ciclo de Vida del. . S. Software”. IC. A. Autor: APESOFT. . Tesis:. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. Año: 2006. “Mejora. del. Proceso. de. Software. de. una. Pequeña. Empresa. Desarrolladora: Caso Competisoft-Peru Lambda” Autor: Dianne Britt Vergara González Año: 2008. Tesis: “Metodología de diseño, desarrollo y evaluación de software¨. . Autor: Ing. Zulma Cataldi. B. IB. LI. O. T. E. Año: 2000. 13 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(14) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. III.. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Modelos de Procesos del Ciclo de Vida del Software Un modelo de proceso en Ingeniería de Software define un conjunto estructurado y ordenado de actividades secuenciales para un proceso de software. Existen diversos modelos de procesos, cada uno responde a diferentes abstracciones hechas sobre el proceso en sí, de manera que algunos ponen énfasis en diferentes actividades y. IC. A. S. organizan el proceso de construcción de software en base a sus propias reglas.. S. La elección del modelo de proceso a aplicar en un proyecto software, depende de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. varios factores tales como: la naturaleza del producto a desarrollar, tiempos de entrega, el equipo y ambiente de trabajo. Finalmente es decisión de los responsables de cada proyecto y sus jefes, escoger el modelo de proceso y adecuarlo a sus restricciones. [01]. A continuación se describen tres modelos de procesos de ingeniería de software, los cuales proponen diversos enfoques, pero que en la actualidad son muy empleados. E. por los jefes de proyectos de software.. O. T. 1. Modelo en Cascada. B. IB. LI. 1.1 Descripción. Este modelo fue propuesto por Royce en 1970 [05], se toma de base para otros modelos de proceso e incluso como el típico ciclo de vida del software. Tiene la característica de funcionar muy bien en aquellos proyectos donde se conocen los requisitos desde el inicio o cuando se presentan pequeños cambios en programas ya implementados.. 14 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(15) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1.2 Actividades del Modelo Una de las características de este modelo es que cada actividad es el inicio o entrada de la actividad siguiente. En la Fig. 1 se describe el conjunto de fases del modelo, ha sido quizás el modelo más útil para ayudar a la estructura, personal, y gestionar grandes. S. proyectos de desarrollo de software en entornos organizativos complejos,. IC. A. que fue uno de los principales objetivos. [08]. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. Requerimientos del Sistema Requerimientos del Software. Análisis. Diseño del Programa. Codificación. Mantenimiento. Fig. 1: Modelo en Cascada [05]. B. IB. LI. O. T. E. Pruebas.  Requerimientos del Sistema Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software..  Requerimientos del Software El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe. 15 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(16) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas..  Análisis Se centra en conocer las necesidades específicas de los usuarios,. S. recopilando los requisitos para involucrarlos como especificación inicial del. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ.  Diseño del Programa. S. IC. A. sistema.. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación..  Codificación. El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.. T. E.  Pruebas. B. IB. LI. O. Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren..  Mantenimiento El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo. 16 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(17) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.. 1.3 Crítica del Modelo Este modelo de proceso del Ciclo de Vida se presenta como un punto de. A. S. referencia para otros modelos de la actualidad, tiene ventajas como por. IC. ejemplo la facilidad para documentar cada etapa del proceso, además se. S. adapta a los proyectos con requerimientos fijos como son los que nacen de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. cambios con menor complejidad en sistemas ya implantados.. Su diseño original contempla iteraciones en el flujo del proceso, pero por lo general el modelo en cascada es difícil de adaptar a cambios de una etapa a otra. En la práctica, un proyecto software no es un modelo lineal que pueda definirse en etapas secuencialmente rígidas.. Esto conlleva que al ocurrir cambios en los requerimientos o problemas encontrados en la etapa de codificación, regresar a etapas iniciales tenga. E. un costo elevado de desarrollo o de lo contrario evitar el cambio lo que. T. provocaría un producto software que no cumple con todas las necesidades. IB. LI. O. de los usuarios.. B. 2.. Desarrollo basado en Componentes 2.1 Descripción El modelo basado en componentes considera una similitud en el desarrollo de software con la construcción de equipos físicos, donde el producto final es el resultado del ensamblaje de piezas ya existentes. Adecuando ese modelo al proceso del software, los programadores, analistas y diseñadores tienen piezas que pueden ser reutilizables en 17. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(18) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. nuevos proyectos tales como código, documentación, casos de pruebas, interfaces, etc. Entonces el proceso se enfoca en hacer coincidir las piezas con los nuevos requisitos del producto a entregar. Como consecuencia de este enfoque, a finales de los 90 surge la denominada Ingeniería de Software Basado en Componentes (CBSE) la. S. cual define los lineamientos para aplicar el desarrollo basado en. S. IC. A. componentes. [01]. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Actividades del Modelo. 2.2. Las actividades del modelo basado en componentes se presentan en la Fig. 2.. Dentro del modelo, las actividades de Especificación de requerimientos y Validación del sistema son genéricas, en el cuerpo del modelo se han insertado actividades específicas del desarrollo basado en componentes, las cuales se definen a continuación [01].. Análisis de componentes. Modificación de requerimientos. B. IB. LI. O. T. E. Especificación de requerimientos. Desarrollo e integración. Diseño con Reutilizacion. Validación Del sistema. Fig. 2: Desarrollo Basado en Componentes [01]. 18 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(19) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática.  Análisis de Componentes En base a los requerimientos, se analizan los componentes que se pueden reutilizar. Se debe buscar los componentes disponibles pueden ser externos (proveedores) o de una lista de componentes propios. Los componentes seleccionados se deben validar para asegurarnos que. S.  Modificación de Requerimientos. IC. A. S. cumplan con los requerimientos iniciales.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. En esta etapa, los componentes seleccionados se deben evaluar en función de los requerimientos. Para muchos casos no existirá una relación perfecta entre grupos de componentes y grupos de requerimientos, ante esto es posible que sea necesario volver a la etapa anterior, con el fin de escoger la combinación que satisfaga mejor las restricciones del proyecto..  Diseño con Reutilización. En esta fase el diseñador deberá integrar los componentes seleccionados. E. y validados en el marco de trabajo del proyecto. Las actividades que. T. pueden seguir en esta fase son: definir las estructuras de datos estándar,. arquitectura del programa.. B. IB. LI. O. establecer los protocolos y el diseño de interfaces, seleccionar la.  Desarrollo e Integración Para crear el sistema, el software que no se puede adquirir externamente se desarrolla, y los componentes y los sistemas se integran. En este modelo, la integración de sistemas es parte del proceso de desarrollo, más que una actividad separada.. 19 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(20) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 2.3 Crítica del Modelo Empleando el modelo de desarrollo basado en componentes se obtiene rapidez en los tiempos de codificación, sistemas más fiables y reducción de costos, esto porque se usan elementos ya validados como parte del software. [09]. S. Por otro lado, podrían ocurrir dificultades de acoplamiento con las. IC. A. características propias del sistema, lo que ocasionaría que no se logren. S. satisfacer plenamente los requerimientos de los usuarios.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Si se escogen componentes desarrollados por proveedores, y nacen nuevos requerimientos, se pierde en cierta medida el control sobre la posibilidad de modificaciones de estos componentes o cambios en el propio sistema.. Es tarea de los responsables de cada actividad enfrentar las ventajas y dificultades del modelo logrando un buen producto software.. 3.. Proceso Unificado de Rational (RUP). E. 3.1 Descripción. T. El modelo RUP fue propuesto por tres investigadores en metodologías de. B. IB. LI. O. software, Ivar Jacobson, Grady Booch y James Rimbaugh a mediados de la década de los 90, como un modelo unificado de sus propuestas individuales. [01] Como. resultado,. se. propone. un. proceso. hibrido. incorporando. características del modelo en cascada y el desarrollo iterativo, además de buenas prácticas en la especificación y diseño. RUP a diferencia de otros modelos, mantiene más cercanía con el punto de vista del negocio. [02]. 20 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(21) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 3.2 Actividades Las actividades dentro del RUP se conforman por fases centrales del proceso que se desarrollan a partir de varias iteraciones de un subconjunto de actividades por fase, y al término de cada fase un entregable o hito.. S. Todo el modelo se puede definir en varias vistas: vista dinámica (fases),. IC. A. vista estática (actividades por iteración) y vista práctica (hitos).. S. Añadido a esto el modelo se describe mediante el UML (Lenguaje. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Unificado de Modelado) y por ende contempla conceptos del modelado orientado a objetos. [10]. La representación grafica del modelo se presenta en la Fig. 3. Objetivos del ciclo de vida. Hito. Fase. Arquitectura ciclo de vida. Elaboración. Versión del producto. Construcción. Transición. O. Iter 1. R. A. D. I. Iter 2. Iter 3. Iter 4. Iter 5. Iter 6. P. Fig. 3: Actividades de RUP [10]. B. IB. LI. Iteraciones. T. E. Inicio. Posibilidad operacional inicial. Las fases que componen la vista dinámica están dadas por:.  Inicio Se define el ámbito del proyecto a implementar, detallando el contexto, flujos de información, usuarios. Se pueden crear prototipos iniciales. Se resume el modelado mediante un diagrama de casos de uso. 21 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(22) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática.  Elaboración Es la fase más crítica porque en base al resultado de esta fase, se especifican todas las demás actividades posteriores del desarrollo. Se espera un diseño de la arquitectura del sistema en función de la. IC. A. primeras versiones como línea del proyecto (no prototipos). S. especificación del Inicio. Al fin de esta fase puede entregar ejecutables de. S.  Construcción. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Dentro de esta fase se desarrolla propiamente el modelo de arquitectura de la Elaboración, se ponen operativos todos los requerimientos de los usuarios y se realizan pruebas sobre los programas. Se espera tener al final de esta fase un producto software beta y su documentación..  Transición. En esta fase se termina el proceso de la prueba Beta, corrigiendo las observaciones finales. Se espera realizar la implementación del software. E. con los usuarios, dar soporte para el uso. Se deben rastrear los posibles. B. IB. LI. O. T. requerimientos para cambios.. La. vista. estática. la. conforman. actividades. se. que. desarrollan. iterativamente, estas actividades son: Requisitos, Análisis, Diseño, Implementación, Pruebas. Al final de cada fase se considera un producto entregable o hito, estos definen la vista práctica del modelo:. 22 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(23) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática.  Objetivos del Ciclo de Vida Es el primer hito del proyecto, está relacionado a los entregables que definen las actividades preliminares del equipo de trabajo. Algunos entregables son: Un documento que indique los requisitos principales, características y. S. restricciones del proyecto.. IC. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. Un documento inicial de arquitectura. A. Un modelo inicial de casos de uso.  Arquitectura del Ciclo de Vida. El hito se refiere a las actividades de la definición de la arquitectura del sistema. Se ha creado una línea base ejecutable de la arquitectura que demuestra que se han identificado riesgos importantes. Algunos entregables son:. Un documento de Análisis de riesgo actualizado. Un modelo de la arquitectura ejecutable.. T. E.  Posibilidad Operacional. B. IB. LI. O. Este hito es muy sencillo, el sistema de software está terminado para una prueba beta en el sitio del usuario. Algunos entregables son: Manuales de usuarios, descripción de esta versión. Plan de proyecto..  Entrega del Producto: Este es el último hito: prueba beta, prueba de aceptación y reparación de defectos está terminado y se lanza el producto en la comunidad de usuarios. Algunos entregables son:. 23 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(24) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. El producto de software. Plan de soporte de usuario, manuales de usuario actualizados.. 3.3 Critica del Modelo Al final de cada fase se considera un producto entregable o hito, estos. S. definen la vista práctica del modelo.. IC. A. Aplicando la metodología RUP como proceso para la construcción de un. S. sistema de software, permite lograr de una manera rápida, eficiente,. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. ordenada y con el menor número de defectos el desarrollo del sistema deseado.. IV.. Estándar IEEE Desarrollo del Ciclo de Vida del Software El estándar IEEE 1074-1997 para los procesos de vida del software describe el conjunto de actividades y procesos obligatorios para el desarrollo y mantenimiento de software. Tiene como objetivo establecer un marco común para el desarrollo de modelos para el proceso de construcción y proporciona algunos ejemplos de situaciones típicas. El estándar IEEE 1074 lista cinco grupos de procesos para el. B. IB. LI. O. T. E. desarrollo de software a través de 17 procesos [03]. 24 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(25) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Selección de un Modelo de Ciclo de Vida. Modelado del Ciclo de Vida A.1. Pre Desarrollo. A.2. Desarrollo. A.3. Post Desarrollo. A.4. Inicio del proyecto. Supervisión y control del proyecto. Administración de calidad del Software Exploración de conceptos. Asignación del Sistema Requerimientos. Diseño. Implementación. Instalación. Operación y Soporte. Mantenimiento. Retiro Verificación y validación. Administración de la configuración de software. Desarrollo de la documentación. Entrenamiento. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. Administración del Proyecto. A.5. Procesos Integrales. Tab. 1: Estándar IEEE Ciclo de Vida del Software [03]. Clausula. Proceso. A.3.2.1 A.3.2.2 A.3.2.3 A.3.2.4 A.3.3.1 A.3.3.2 A.3.3.3. Actividades. Selección de un Modelo del Ciclo de Vida. Selección de un Modelo del Ciclo de Vida. Diseño. Realizar el diseño arquitectónico. Diseño de la Base de Datos Diseño de Interfaces Diseño Detallado Codificación Documentación Ejecutar la Integración. E. Implementación. Diseño e Implementación de Software. IB. V.. LI. O. T. Tab. 2: Estándar IEEE Actividades Diseño e Implementación [03]. B. La etapa del Diseño e Implementación, recibe como información de entrada la Especificación de los Requisitos del Sistema. Es propiamente en esta etapa subsecuente donde se crea la estructura arquitectónica y la codificación de la aplicación, el resultado es una versión del software ya ejecutable.. Según el Estándar de la IEEE las actividades dentro del diseño e implementación, son las siguientes [03]:. 25 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(26) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1. Actividades del Diseño de Software 1.1 Diseño Arquitectónico El proceso del diseño arquitectónico identifica y define como se deben interrelacionar los diversos componentes del software: programas externos,. S. módulos, funciones, reglas, objetos. El resultado es una descripción de la. S. IC. A. arquitectura del software. [06]. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. El responsable de ejecutar el proceso es el Arquitecto del Software y debe establecer:. Si el diseño cumple con los requisitos funcionales y no funcionales del. . software . Reducir los posibles riesgos derivados de la implementación.. . Elegir el diseño adecuado o modificaciones al modelo existente.. Un buen diseño arquitectónico debe considerar:. El tipo de aplicación a construir (WEB, escritorio, RIA, etc.). . Estructura lógica de la aplicación (capas, componentes, objetos, etc.). T. E. . Estructura física de la aplicación (cliente servidor, N-Tier). LI. O. . B. IB. . Riesgos que conlleva el sistema (seguridad, rendimiento, mantenimiento,. etc.) . Tecnología del software.. Como información de entrada, esta etapa necesita: . Datos de la interacción de procesos (casos de uso). . Requerimientos funcionales o no funcionales.. . Restricciones tecnológicas y del diseño en general.. 26 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(27) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Entorno de despliegue propuesto.. . Entre las principales ventajas de una definición arquitectónica tenemos: Brinda un modelo, que permite la comunicación entre todas las partes. . interesadas en el desarrollo del software. Es el punto de partida de todo el diseño, por ello tiene un impacto en las. . S. etapas siguientes y en la calidad del producto final La arquitectura del sistema frecuentemente es la misma para sistemas con. IC. A. . S. requerimientos similares y, por lo tanto, pueden soportar reutilización del. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. software a gran escala [11].. Se puede ver la ejecución de esta etapa como un ciclo iterativo (ver Fig. 4) : Casos de Uso. Objetivos de Iteración. Esquema del Sistema. Requisitos. Arquitecturas Candidatas. Identificar Riesgos. Fig. 4: Actividades del Diseño Arquitectónico [06]. B. IB. LI. O. T. E. Software. 1.1.1 Objetivos de Iteración Determinar los Objetivos de Iteración es el primer paso para dar forma a la arquitectura del sistema. En este punto lo importante es analizar las restricciones que tiene el sistema según: tecnologías, topología de despliegue, uso del sistema, etc.. 27 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(28) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. También se deben determinar los objetivos de la arquitectura: construcción de un prototipo, realizando un diseño completo o probando posibles vías de desarrollo de la arquitectura. Realizar la documentación de la arquitectura, de acuerdo a las personas para quienes va dirigido: arquitectos, desarrolladores o usuarios sin. IC. A. S. conocimientos técnicos.. S. El objetivo de esta fase del proceso de diseño de la arquitectura es. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. entender por completo el entorno que rodea a nuestro sistema. Esto nos permitirá decidir las actividades centrales en las siguientes fases del diseño y determinará el alcance y el tiempo necesarios para completar el desarrollo. Al término de esta fase se debe tener una lista de los objetivos de la iteración, preferiblemente con planes para afrontarlos y métricas. para. determinar. el. tiempo. y. esfuerzo. que. requerirá. completarlos. Tras esta fase es imprescindible tener una estimación del tiempo que invertiremos en el resto del proceso.. B. IB. LI. O. T. E. 1.1.2 Casos de Uso. Esta etapa comprende la selección de los Casos de Uso de más importancia para la arquitectura del sistema. La funcionalidad y gestión de riesgos se priorizan según:  Caso de uso dentro de la Lógica del Negocio.  Caso de uso de mayor implicancia en la arquitectura.  Caso de uso relacionado a atributos de calidad del sistema: seguridad, disponibilidad o tolerancia a fallos.  Caso de uso contemplado en los Objetivos de Iteración. 28 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(29) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Con. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. el subconjunto seleccionado de casos de uso, se definen los. primeros aspectos de la arquitectura según el detalle que se obtiene del usuario, esto es la funcionalidad especial que se debe integrar en el sistema. Otros puntos relevantes de la arquitectura se separan para. S. posteriores iteraciones.. IC. A. 1.1.3 Esquema del Sistema. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. desarrollar, el siguiente paso es el diseño.. S. Una vez que están claros los objetivos de la iteración y la funcionalidad a. Dependerá del tipo de aplicación por ejemplo: dispositivos móviles, aplicaciones de escritorio, RIA (Rich Internet Applications), servicios, aplicaciones web. Se presentan las características de las aplicaciones según su arquitectura en la Tabla 3.. En base al tipo de aplicación, luego se debe diseñar la arquitectura de la infraestructura, es decir la topología de despliegue. Dependerá. B. IB. LI. O. T. E. directamente de las restricciones impuestas por el cliente, de las necesidades de seguridad del sistema y de la infraestructura disponible para desplegar el sistema. La arquitectura de la infraestructura definida en niveles de despliegue se relacionarán con las capas lógicas de la aplicación. Existen dos grandes tipos de topologías [11]:. . No distribuidas: es el modelo más simple, se caracteriza porque las. llamadas son locales. Es limitado, porque no permite que varias aplicaciones utilicen la misma lógica del negocio al mismo tiempo. Los. 29 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(30) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. recursos de la maquina son compartidos por todas las capas produciéndose saturación.. Distribuidas: permite separar las capas lógicas en distintos niveles. . físicos. el sistema puede aumentar su capacidad añadiendo servidores. S. donde se necesiten y se puede balancear la carga para maximizar la. Ventajas. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Tipo de Aplicación. S. IC. A. eficiencia. Son sistemas más complejos y caros.. Consideraciones. Aplicaciones para. - Sirven en escenarios con. Limitaciones para. dispositivos. restricciones de conectividad.. interactuar con la. móviles. - Transportabilidad.. aplicación.. Aplicaciones de. - Aprovechan mejor los recursos de. Despliegue complejo.. escritorio. los clientes.. Poca interoperabilidad.. - Mejor respuesta a la interacción,. Control de versiones.. - Disponibilidad y accesibilidad.. interfaz poderosa y mejor experiencia del usuario.. Aplicaciones. - Proporcionan una interfaz muy. Carecen de interfaz. orientadas a. desacoplada entre cliente y. grafica.. servicios. servidor.. Necesitan conexión a. - Pueden ser consumidas por. E. varias aplicaciones sin relación. -Interoperatibilidad. T O LI IB B. internet. Aplicaciones web. - Todo tipo de usuario, tienen una. Dependen de la. interfaz de usuario estándar y. conectividad a la red. multiplataforma. -Fácil de desplegar y actualizar.. Tab. 3: Aplicaciones según su arquitectura [06]. La siguiente actividad tiene que ver con la elección del modelo lógico de arquitectura: Diseñar la arquitectura lógica de la aplicación. Esto es definir el estilo arquitectónico. Para ello emplearemos en la medida de lo posible un conjunto de estilos arquitecturales conocidos, los estilos. 30 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(31) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. arquitecturales son patrones de nivel de aplicación que definen un aspecto del sistema que estamos diseñando y representan una forma estándar. de. definir. o. implementar. dicho. aspecto.. Los. estilos. arquitecturales se pueden agrupar según el aspecto que definen como muestra la Tab. 4:. Filtros.. A. SOA, Message Bus, Tuberias y. IC. Comunicaciones. Estilo Arquitectural. S. Aspecto. Cliente/Servidor, 3-Niveles, N-. S. Despliegue. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Niveles. Dominio. Modelo de Dominio, Repositorio.. Interacción. Presentación separada.. Estructura. Componentes, Orientado a objetos, Arquitectura en Capas. Tab. 4: Aspectos del sistema y Estilos Arquitecturales [06]. De esta manera se determina al sistema como un conjunto de estilos. E. arquitecturales y su relación.. punto se decide las tecnologías a emplear. Por ejemplo en una aplicación de escritorio escogeremos WPF o Silverlight 3, o si la aplicación expone funcionalidad como servicios web, se emplearía WCF.. B. IB. LI. O. T. El paso siguiente es la implementación propiamente del diseño, en este. Esta etapa se concluye con un esquema arquitectónico del sistema que refleje la estructura de la aplicación, las principales restricciones y decisiones de diseño tomadas. Esto permitirá establecer un marco para el sistema y discutir la solución propuesta. 31 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(32) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1.1.4 Identificar Riesgos Un buen diseño es aquel que cumple correctamente con los requisitos funcionales y además mitiga los riesgos que pudieran presentarse. Para identificar los riesgos del sistema, podemos tomar como referencia la lista de requerimientos no funcionales, los cuales tienen impacto sobre. S. el comportamiento del sistema en situaciones clave, como por ejemplo:. IC. A. la autenticación y a autorización, el cacheo de datos y el mantenimiento. S. del estado, las comunicaciones, la composición, la concurrencia y las. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. transacciones, la gestión de excepciones, el registro de eventos, la experiencia de usuario, la validación de información y el flujo de los procesos de negocio del sistema.. 1.1.5 Arquitecturas Candidatas. Una vez realizados los pasos anteriores, tendremos una arquitectura candidata que podremos evaluar. Si no es así, es que la arquitectura todavía no está bien definida o no hemos concretado alguno de los anteriores.. Si. tenemos. varias. arquitecturas. candidatas,. E. pasos. B. IB. LI. O. T. realizaremos la evaluación de cada una de ellas e implementaremos la arquitectura mejor valorada.. Cualquier arquitectura candidata debería responder a las siguientes preguntas: ¿Qué funcionalidad implementa? ¿Qué riesgos mitiga? ¿Cumple las restricciones impuestas por el cliente? ¿Qué cuestiones deja en el aire?. Para medir la validez del modelo elegido, se definen métricas cualitativas y cuantitativas. Las métricas cuantitativas evaluaran un aspecto de nuestra arquitectura candidata y nos darán un índice que compararemos. 32 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(33) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. con el resto de arquitecturas candidatas y un posible mínimo requerido. Las métricas cualitativas evaluaran si la arquitectura candidata cumple o no con un determinado requisito funcional o de calidad del servicio de la solución. Generalmente serán evaluadas de forma binaria como un sí o. S. un no.. IC. A. 1.2 Diseño de la Base de Datos. S. Según el estándar de la IEEE [03], la actividad del Diseño de Base Datos se. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. aplica cuando una base de datos es creada o modificada como parte del proyecto. En algunas situaciones debe diseñarse y construirse una base de datos específicamente para un nuevo sistema. Sin embargo, en otras, se emplean una o más bases de datos existentes.. Esta actividad debe especificar la estructura de la información guiada por los requerimientos y las características del sistema.. El diseño de una base de datos consiste en definir la estructura de los datos que debe tener la base de datos de un sistema de información determinado.. T. E. Para el caso del diseño relacional, la estructura será un conjunto de. O. esquemas de relación con sus atributos, dominios de atributos, claves. B. IB. LI. primarias, claves foráneas, etc. [12] La definición de la estructura de la base datos comprende tres modelos: modelo de diseño conceptual, modelo de diseño lógico y modelo diseño físico. Los modelos conceptuales, están más próximos al usuario y son independientes de la tecnología que se vaya a utilizar, los modelos lógicos dependen del tipo de gestor de bases de datos, y los modelos físicos dependen de los sistemas comerciales particulares.. 33 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(34) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. En la siguiente figura observamos el esquema de interacción de los modelos conceptual, lógico y físico de una base de datos.. Esquema Conceptual. Esquema Canónico. Esquema Interno. BD. Modelo Lógico. IC. Modelo Conceptual. A. S. Mundo real. Modelo Físico. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. Manejador BD Fig. 5: Aplicaciones según su arquitectura [07]. 1.2.1 Diseño del Modelo Conceptual. En esta etapa se obtiene una estructura de la información de la futura BD independiente de la tecnología que hay que emplear. No se tiene en cuenta todavía qué tipo de base de datos se utilizará (relacional, orientada a objetos, jerárquica, etc.) en consecuencia, tampoco se tiene en cuenta con qué Sistema Gestor de Base de Datos. E. (SGBD) ni con qué lenguaje concreto se implementará la base de. B. IB. LI. O. T. datos. Así pues, la etapa del diseño conceptual nos permite concentrarnos únicamente en la problemática de la estructuración de la información, sin tener que preocuparnos al mismo tiempo de resolver cuestiones tecnológicas.. El resultado de la etapa del diseño conceptual se expresa mediante algún modelo de datos de alto nivel. Uno de los más empleados es el modelo Entidad Relación (entity-relationship), que abreviaremos con la sigla ER.. 34 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(35) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1.2.2 Diseño del Modelo Lógico En esta etapa se parte del resultado del diseño conceptual, indicando la composición y distribución teórica de la base de datos, adaptada a la tecnología que se debe emplear, pero sin tomar en cuenta la forma de almacenar los datos.. S. Esta etapa parte del hecho de que ya se ha resuelto la problemática. IC. A. de la estructuración de la información en un ámbito conceptual, y. S. permite concentrarnos en las cuestiones tecnológicas relacionadas. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. con el modelo de base de datos. Más concretamente, es preciso que se ajuste al modelo del SGBD con el que se desea implementar la base de datos.. Por ejemplo, si se trata de un SGBD relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, claves primarias y claves foráneas, etc. que realmente no tienen presencia real en la física del sistema. Por ello para acceder a los datos tiene que haber una. E. posibilidad de traducir la estructura lógica en la estructura física.. B. IB. LI. O. T. 1.2.3 Diseño del Modelo Físico. En esta etapa se transforma la estructura obtenida en la etapa del diseño lógico, con el objetivo de conseguir una mayor eficiencia; además, se completa con aspectos de implementación física que dependerán del SGBD. Los aspectos de implementación física que hay que completar consisten normalmente en la elección de estructuras físicas de implementación de las relaciones, la selección del tamaño de las memorias intermedias (buffers) o de las páginas, etc.. 35 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(36) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. En la etapa del diseño físico, con el objetivo de conseguir un buen rendimiento de la base de datos, se deben tener en cuenta las características de los procesos que consultan y actualizan la base de datos, como por ejemplo los caminos de acceso que utilizan y las frecuencias de ejecución. También es necesario considerar los. S. volúmenes que se espera tener de los diferentes datos que se quieren. S. IC. A. almacenar.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. La correspondencia entre la estructura lógica y la física se almacena en la base de datos (en los metadatos).. Diccionario de datos: Un diccionario de datos es una lista de nombres ordenada alfabéticamente incluida en los modelos del sistema. El diccionario debería incluir, además del nombre, una descripción asociada de dicha entidad con nombre y, si el nombre representa un objeto compuesto, una descripción de la composición. Se puede incluir otra información, como la fecha de creación, el creador y la. esté desarrollando.. IB. LI. O. T. E. representación de la entidad dependiendo del tipo de modelo que se. B. 1.3 Diseño de la Interfaz de Usuario Un proceso de diseño, no está completo hasta que se define como el usuario va a interactuar con el sistema y como se debe presentar la información del sistema, lo que se traduce en el diseño de la Interfaz de Usuario. Como es una actividad en relación directa con el usuario final, debemos conocer las limitaciones, grupos de usuarios los cuales van a usar el sistema.. 36 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(37) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Los diseñadores y analistas deben plasmar un adecuado modelo de interfaz para el sistema, una estrategia de buen diseño es aquella que se guía de estos principios [01]:.  Familiaridad del usuario: La interfaz debe utilizar términos familiares para. S. los usuarios, incorporando elementos de la experiencia de trabajo diario.. IC. A. Además se debe ocultar toda información relacionada con el manejo de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. archivos, datos internos de funcionamiento..  Uniformidad: en lo posible, los comandos y menús del sistema deben tener el mismo formato. Por ejemplo las teclas de acceso rápido, los iconos del sistema y mensajes deben referirse a la misma operación. Las interfaces uniformes reducen el tiempo de aprendizaje del usuario. Por lo tanto, el conocimiento aprendido en un comando o aplicación es aplicable en otras partes del sistema o en aplicaciones relacionadas..  Mínima sorpresa: se refiere al comportamiento inesperado del sistema. T. E. para el usuario. Se espera, que las mismas acciones en contextos. B. IB. LI. O. similares tengan los mismos efectos. Si sucede algo completamente diferente, el usuario se sorprende y confunde. Por ello, los diseñadores de interfaces deben intentar asegurar que las acciones comparables tengan efectos comparables. Se minimiza el factor sorpresa en la interfaz si se incluye ayudas o indicadores para el usuario..  Recuperabilidad: aun cuando se minimice los posibles errores de usuario, un buen diseño de interfaz debe contemplar mecanismos para que los usuarios se recuperen de esas situaciones. Se debe incluir pasos de confirmación de acciones destructivas, por ejemplo mensajes o alertas. 37 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(38) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Proporcionar recursos para deshacer, el usuario puede restablecer algún cambio efectuado. Establecer puntos de control, se guardan características del sistema para poder restaurar a un estado anterior..  Guía de usuario: incluir documentación relacionada a los procesos del. S. usuario dentro del sistema, de tal manera que sea accesible y oriente el. S. IC. A. trabajo.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ.  Diversidad de usuario: para un mismo sistema, pueden existir diferentes tipos de usuarios. Esta diversidad está referida a las funciones de cada usuario como a las posibles limitaciones que se encuentren, en ambos casos la interfaz debe adaptarse para un aprendizaje rápido y varios mecanismos de uso.. El proceso de diseño de la interfaz de usuario, se puede tratar como un. Validación de la Interfaz. Análisis del Usuario. Implementación. Diseño de Interfaz. B. IB. LI. O. T. E. proceso iterativo. Ver Fig. 6. Fig. 6: Proceso Diseño de Interfaz de Usuario [01]. 38 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(39) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 1.3.1 Análisis de Usuario El primer paso es entender las características de los usuarios involucrados y el entorno general del sistema, para que el diseño de la interfaz soporte esas características. Se realizan las siguientes. S. actividades [01]:. IC. A.  Comprensión del usuario: los diversos usuarios tienen esquemas. S. mentales distintos del sistema, la tarea es comprender quienes son. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. los usuarios finales, que los motiva y complace, como se agruparían en grupos o perfiles de acceso y además las características de la interfaz según sus requerimientos.. Para conseguir estos objetivos, se usan técnicas de recopilación de información como: entrevistas con el usuario, preguntas claves. Además existen usuarios base para recopilar información: usuarios. E. de ventas y del área de soporte.. B. IB. LI. O. T.  Análisis de las tareas del usuario: en esta actividad se debe establecer el flujo de trabajo del usuario, las tareas y subtareas, los objetos que intervienen para realizar estas tareas. Siguiendo las técnicas de análisis, el diseñador debe elaborar: casos de uso, descomposición funcional, modelo de objetos y el análisis del flujo de trabajo..  Contenido de la interfaz: según el análisis previo, se define el tipo de presentación de la interfaz. Entonces en esta etapa el diseñador puede determinar: ubicación de elementos clave en la pantalla, el 39 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(40) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. grado de personalización del contenido, la distribución del contenido, la cantidad de información disponible, selección de los colores y fuentes de texto, presentación de los mensajes de error y avisos.. S.  Análisis del entorno de trabajo: esta actividad analiza las. IC. A. características físicas del ambiente donde se desempeña el sistema. S. y sus limitaciones para la interacción del usuario con la interfaz.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Además también comprende otros atributos como: la rapidez transaccional es un requisito importante, usuarios comunes en los procesos, que clase de soporte necesitaran los usuarios, etc.. 1.3.2 Diseño de la Interfaz. Luego de analizar las características que debe reunir la interfaz, se procede a diseñar iterativamente el modelo de pantallas y sus interacciones.. Este proceso puede describirse inicialmente como una maqueta de. B. IB. LI. O. T. E. diseños, siguiendo el flujo de trabajo del análisis. Terminada la maqueta se procede al diseño real el cual implica: elaborar el diseño grafico, establecer los iconos de la aplicación, definición del texto descriptivo en pantalla, especificación y asignación de nombres a las ventanas, definir los elementos del menú.. 1.3.3 Implementación Luego del diseño en papel y maquetas de las interfaces de usuario del sistema, el proceso de implementación comienza. Los desarrolladores y diseñadores trabajan en conjunto para la construcción propiamente. 40 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(41) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. dicha de la interfaz de software. Para las pruebas de usuario, se deben simular las funcionales requeridas en pantalla.. Se pueden seguir las siguientes técnicas de implementación de interfaz:. S.  Secuencias de comandos: sirve cuando únicamente se muestran. IC. A. ideas para la interacción con el usuario sin intervenir funcionalidad. S. lógica subyacente. Cuando el usuario interactúa con estas. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. pantallas, se ejecuta la secuencia de comandos y se presenta la siguiente pantalla. que les muestra los resultados de sus acciones..  Lenguajes de programación visuales: el uso de los lenguajes de programación proporcionan alta funcionalidad para el uso de los objetos de la interfaz..  Prototipos basados en internet: existen componentes para internet con modelos funcionales que cargan con los navegadores, se. B. IB. LI. O. T. E. deben tomar en cuenta las restricciones propias de la tecnología.. 1.3.4 Validación de la Interfaz Para comprobar que la interfaz de usuario cumple correctamente su funcionalidad, se debe evaluar su implementación midiendo criterios de usabilidad tales como: aprendizaje, velocidad de funcionamiento, robustez, recuperación, adaptación. La validación de la interfaz es un proceso complejo que puede incluir numerosas técnicas estadísticas y sesiones de simulación con. 41 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(42) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. usuarios modelos para evaluar la velocidad de funcionamiento, por ejemplo. Existen. técnicas. sencillas. y. menos. costosas. de. validación:. cuestionarios de información, observación del uso de la interfaz, implementar el uso de sugerencias en línea.. S. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Diseño preliminar. IC. A. S. El proceso de validación se resume en la siguiente figura:. Construcción de la Interfaz. Prototipo modificado. Modificar el diseño. Diseño completo. Evaluación de la Interfaz. Analizar resultados. Fig. 7: Validación de la Interfaz de Usuario [01]. T. E. 1.4 Diseño Detallado. O. La etapa final del proceso de diseño se condensa en la fase del Diseño. B. IB. LI. Detallado, donde se reciben todos los modelos y análisis realizados con el propósito de obtener una definición clara del sistema. El diseño detallado transforma alternativas de conceptos, arquitecturas físicas preliminares, especificaciones de diseño y requisitos técnicos en definiciones de diseño finales e interdisciplinares. Estos diseños se ajustan más y se elabora toda la documentación que les acompaña y que se necesita para el desarrollo con el fin de entregar puntualmente al cliente un producto completo y totalmente definido [02].. 42 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.