PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD

Transcripción

1 PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD ANA MERCEDES DÍAZ UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA Barquisimeto, Julio 2013

2 PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD Por Ana Mercedes Díaz Trabajo de Ascenso presentado para optar a la categoría de Asociado en el escalafón del Personal Docente y de Investigación UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO Decanato de Ciencias y Tecnología Barquisimeto, Julio 2013

3 PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD Por Ana Mercedes Díaz Trabajo aprobado Barquisimeto, de Julio del 2013

4 PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD ANA MERCEDES DÍAZ UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA Barquisimeto, Julio 2013

5 DEDICATORIA A mi hermosa hija Ana Paula.DIOS te Bendiga, sabes que eres mi más grande amor. Te Amo!!! A mi madre Justa Pastora (Tori), por todo el amor y el apoyo que me ha dado. A la memoria de mi padre, Luís Beltrán Linarez Cortéz, por todas las enseñanzas que me dio durante toda su vida.que DIOS lo tenga en la gloria.

6 AGRADECIMIENTOS. A María Angélica, mi tutora de la Universidad Simón Bolívar, por apoyarme en todo lo referente a mi trabajo en Investigación. A los profesores: Ninfa Barón, Miriam Alvarado, José Antonio Gándara, Alfredo Ynfante y Darwin Romero, por sus valiosas recomendaciones. A todos. Gracias

7 PROPUESTA DE UN MÉTODO PARA EL DISEÑO DE VISTAS ARQUITECTURALES DE UN SISTEMA BAJO UN ENFOQUE DE CALIDAD RESUMEN x Prof. Ana Mercedes Díaz La creciente complejidad del mundo empresarial de hoy en día hace que las organizaciones incorporen tecnología de información y comunicaciones para apoyar todos sus procesos de negocio, así es como los sistemas de información deben ajustarse siempre a las estrategias de la empresa con el objetivo de generar ventajas competitivas que le permitan a las organizaciones permanecer en el campo productivo. Esta necesidad de tener sistemas de información que vayan de la mano de la empresa ha hecho que el desarrollo de éstos se haya visto también afectado, es por eso que la ingeniería del software tiene el reto de generar procesos de desarrollo, métodos, notaciones y herramientas que contribuyan a la creación de sistemas de calidad y que verdaderamente satisfagan las necesidades de sus clientes o usuarios. La calidad de un sistema como producto final, es consecuencia de la calidad de su proceso de desarrollo, es por eso que se debe cuidar la calidad de todos los procesos técnicos que se encuentran orquestados dentro de una metodología de desarrollo de sistemas. El proceso de diseño es uno de los procesos al cual se le debe prestar una importante atención, puesto que es allí donde se traducen todos los requisitos tanto funcionales como no funcionales en los planos de lo que será el sistema a desarrollar. Tomando en cuenta la sensibilidad del proceso de diseño y de los productos que se generan en él; este trabajo de investigación se ha fijado como objetivo principal proponer un método de diseño de vistas arquitecturales de un sistema bajo un enfoque de calidad, el cual contendrá la definición de un proceso de diseño de vistas arquitecturales, la instanciación del proceso para ser utilizado por metodologías tradicionales, ágiles e híbridas y un modelo de calidad que permita evaluar tanto el proceso de diseño como los productos de diseño. Este trabajo ha sido realizado bajo un enfoque metodológico proyectivo. Entre los aportes más importantes de esta investigación se tiene: MeDiSis o método de diseño de vistas arquitecturales de un sistema compuesto por ProDiVAS o proceso de diseño de vistas arquitecturales, el mecanismo de instanciación del ProDiVAS, el modelo de calidad para evaluar el ProDiVAS, un modelo conceptual de todo el MeDiSis y un conjunto de pasos que se recomiendan para usar el MeDiSis. Es importante mencionar que este método propuesto esta en concordancia con lo establecido por el cuerpo de conocimiento de la ingeniería del software SWEBOK, el estándar internacional ISO/IEC y lo establecido en el código de ética de los ingenieros de software o encargados de desarrollar aplicaciones. Palabras Clave: Método de Diseño, vistas arquitecturales, instanciación, modelo de calidad, diseño de sistemas.

8 ÍNDICE GENERAL ÍNDICE DE FIGURAS ÍNDICE DE TABLAS RESUMEN INTRODUCCIÓN 1 CAPÍTULO I EL PROBLEMA 4 Planteamiento del Problema 4 Objetivo General 32 Objetivos Específicos 32 Justificación 32 Importancia 34 Alcance 34 II MARCO TEÓRICO 35 Procesos de Desarrollo de Sistemas 35 El Proceso de Desarrollo de Sistemas 37 Modelos de Procesos de Software 40 Metodologías de Desarrollo de Sistemas 48 El Diseño de Sistemas 71 El Proceso de Diseño 73 Fundamentos del Diseño 74 Evolución del Diseño de Sistemas 78 Principios del Diseño de Sistemas 78 Arquitecturas de Software 80 Definiciones de Arquitectura 80 Evolución Histórica de la Arquitectura del Software 82 Importancia de la Arquitectura del Software 85 Estilos y Patrones Arquitecturales 87 Vistas Arquitectónicas 94 Diferencias entre Arquitectura y Diseño 98 Norma IEEE Calidad del Software 104 III MARCO METODOLÓGICO 109 Naturaleza de la Investigación 109 Diseño de la Investigación 111 Procedimiento Aplicado 112 IV PROPUESTA 114 Estructura de la Propuesta 114 Proceso de Diseño de las Vistas Arquitecturales 116 Proceso Técnicos del Proceso de Diseño Propuesto 120 Proceso Gerenciales y de Apoyo del Proceso de Diseño 150 Propuesto Relación del Proceso de Diseño de Vistas Arquitecturales 167 Propuesto con el SWEBOK Y EL ISO/IEC Instanciación del Proceso de Diseño de Vistas Arquitecturales 169 Propuesto Propuesta de Modelo de Calidad para Evaluar Productos y 172 Procesos de Diseño V CONCLUSIONES Y RECOMENDACIONES 187 vii

9 REFERENCIAS BIBLIOGRÁFICAS 190 vii

10 ÍNDICE DE FIGURAS Figura Nº 1. El Modelo de Diseño es una jerarquía de subsistemas de diseño que 11 contienen clases de diseño, realizaciones de casos de uso diseño e interfaces. Figura Nº 2. Ciclo de Vida de SCRUM 17 Figura Nº 3. Mapa conceptual de los elementos que establece el SWEBOK, para el Diseño de Software Figura Nº 4. Estructura de Procesos de la ISO/IEC Figura N 5: Capas de la Ingeniería de Software. 36 Figura 6: proceso de desarrollo de software. 37 Figura N 7: Elementos del proceso del software 39 Figura N 8: Relación entre elementos del proceso del software 39 Figura N 9: Modelo de desarrollo en cascada. 41 Figura N 10: Modelo de desarrollo evolutivo. 42 Figura N 11: Paradigma de programación automática. 43 Figura N 12: Desarrollo basado en reutilización de componentes 44 Figura N 13: Modelo de desarrollo iterativo incremental. 45 Figura N 14: Modelo de desarrollo en Espiral 46 Figura N 15. Disciplinas y fases en RUP. 50 Figura N 16. Las prácticas se refuerzan entre sí 61 Figura Nº 17. Cadena de Valor del Blue Watch 65 Figura Nº 18. Relaciones entre ciclos de desarrollo 66 Figura Nº 19. Los ciclos de desarrollo y sus productos. 66 Figura Nº 20. Procesos relacionados con el Ciclo de la Aplicación 69 Figura Nº 21. Procesos del Ciclo de Versión (parte 1) y Procesos del Ciclo del 70 Incremento (parte 2) Figura Nº 22. Roles requeridos por el método Blue WATCH 71 Figura Nº 23. Importancia del diseño 72 Figura N 24. Modularidad y coste del software 76 Figura Nº 25 Relación de abstracción entre estilos y patrones 94 Figura Nº 26. Marco conceptual definido por la Norma IEEE. 103 Figura Nº 27. Estructura de MOSCA 106 Figura Nº 28. Aspectos metodológicos para desarrollar el Trabajo de 112 Investigación, siguiendo los estadios que propone Hurtado (Hurtado, 2010) para una investigación Proyectiva Figura Nº 29. Elementos del MeDiSis 115 Figura Nº 30. Niveles de la Propuesta del Método de Diseño de Sistemas MeDiSis Figura Nº 31. Cadena de Valor del Proceso de Diseño de las Vistas 118 Arquitecturales. Figura Nº 32. Modelo Gráfico de los Procesos Técnicos, Gerenciales y de Apoyo 120 del ProDiVAS Figura Nº 33. Diagrama de Procesos del Proceso: Generar la Vista Arquitectural 121 Funcional. Figura Nº 34. Diagrama de Actividad del Proceso: Generar la Vista Arquitectural 122 Funcional. Figura Nº 35. Ejemplo de Diagrama de Casos de Uso. 126 Figura Nº 36. Diagrama de Procesos del Proceso: Generar la Vista Arquitectural 128 de Datos. Figura Nº 37. Subprocesos del Proceso Generar la Vista Arquitectural de Datos 128 Figura Nº 38. Vista de un Diagrama de Clases 131 Figura Nº 39. Diagrama de Procesos del proceso Generar la Vista Arquitectural 133 viii

11 de Procesos Figura Nº 40: Diagrama de Actividad del Proceso Generar la Vista Arquitectural 133 de Procesos Figura Nº 41. Vista de un Diagrama de Estructura Compuesta. 137 Figura Nº 42. Vista de un Diagrama de Secuencia. 138 Figura Nº 43. Vista de un Diagrama de Actividad. 138 Figura Nº 44. Vista de un Diagrama de Estado. 139 Figura Nº 45. Diagrama de Procesos del Proceso Generar la Vista Arquitectural 140 de Implementación Figura Nº 46. Subprocesos del Proceso Generar la Vista Arquitectural de 141 Implementación Figura Nº 47. Vista de un Diagrama de Componentes. 143 Figura Nº 48. Vista Interna de un Componente 144 Figura Nº 49. Vista de la Especificación de las Interfaces de los Componentes 145 Figura Nº 50. Diagrama de Procesos del Proceso Generar la Vista Arquitectural 146 de Implantación Figura Nº 51. Subprocesos del Proceso Generar la Vista Arquitectural de 146 Implantación Figura Nº 52. Vista de un Diagrama de Despliegue 149 Figura Nº 53. Diagrama de Procesos del Proceso Gestión del Proceso de Diseño 151 Figura Nº 54. Diagrama de Actividades del Proceso Gestión del Proceso de 151 Diseño Figura Nº 55. Diagrama de Procesos del Proceso de Apoyo Verificación y 158 Validación Figura Nº 56. Diagrama de Actividades del Proceso de Apoyo Verificación y 158 Validación del Proceso de Diseño Figura Nº 57. Diagrama de Procesos del Proceso de Apoyo Aseguramiento de la 162 Calidad del Proceso de Diseño Figura Nº 58. Diagrama de Actividades de las Actividades del Proceso de apoyo 162 Aseguramiento de la Calidad del Proceso de Diseño Figura Nº 59. Diagrama de Procesos del Proceso de Apoyo Control de 164 Configuración y Cambios Figura Nº 60. Diagrama de Actividades de los Subprocesos del Proceso de 164 Apoyo Control de Configuración y Cambios Figura Nº 61: Estructura del Modelo de Calidad para el Proceso de Diseño de las 174 Vistas Arquitecturales del Sistema (MC-ProDiVAS) Figura Nº 62. Modelo Conceptual del MeDiSis a nivel del ProDiVAS 185 Figura Nº 63. Modelo Conceptual del MeDiSis a nivel de la Intanciación y a nivel 185 del Modelo de Calidad Figura Nº 64. Algoritmo para usar el MeDiSis 185 ix

12 INTRODUCCIÓN A medida que aumenta la complejidad de los sistemas de información y en consecuencia las aplicaciones que los soportan, surgen nuevos aspectos del desarrollo de aplicaciones que hasta ese momento no se habían tenido en cuenta, al menos de una forma explícita. De este modo, el proceso de desarrollo se ha ido convirtiendo gradualmente en una labor de ingeniería, en la que nuevas tareas, como la elaboración de especificaciones, el diseño del sistema, la construcción de prototipos, la integración y pruebas, la gestión de la configuración y otras muchas han ido cobrando importancia frente a las labores de programación que eran las que destacaban en un inicio. La Ingeniería del Software ha ido respondiendo a esta situación con el desarrollo de nuevos modelos, notaciones, técnicas y métodos. Dentro de esta tendencia se encuadra el creciente interés por los aspectos arquitectónicos del sistema de software del que somos testigos en los últimos tiempos. Estos aspectos se refieren a todo lo relativo a la estructura de alto nivel de los sistemas: su organización en subsistemas y la relación entre éstos; la construcción de aplicaciones vista como una actividad fundamentalmente composicional en la que se reutilizan elementos creados posiblemente por terceros; el desarrollo de familias de productos caracterizadas por presentar una arquitectura común; el mantenimiento y la evolución entendidos como sustitución de unos componentes por otros dentro de un marco arquitectónico, etc. En efecto, un aspecto crítico a la hora de desarrollar sistemas de software complejos es el diseño de su arquitectura, representada como un conjunto de elementos y de datos interrelacionados de un modo determinado. La arquitectura de software ha llegado a constituirse en una actividad vital para el desarrollo de sistemas a gran escala ya que es usada como referencia en la fase del diseño de un sistema de software. Dentro de una arquitectura de software se conjugan a los requisitos funcionales y a los requisitos de calidad, ya que en su modelado se toman en cuenta los intereses del espacio del problema y algunos de los intereses del espacio de la solución. No obstante, el campo de estudio de la Arquitectura del Software no es algo nuevo. Los sistemas de software han tenido arquitectura desde que el primer programa fue dividido en módulos, y los programadores han sido responsables de establecer las interacciones entre dichos módulos y lograr así determinadas propiedades globales para sus sistemas. Históricamente, la arquitectura de los sistemas ha sido desarrollada y utilizada de forma implícita, en muchos casos como mero accidente durante el proceso de implementación, o como herencia de sistemas anteriores. Los profesionales del desarrollo de software han adoptado a menudo uno o varios patrones arquitectónicos como estrategia para la organización de sus aplicaciones, pero han utilizado estos patrones de manera informal, sin reflejarlos de manera explícita en el sistema resultante. 1

13 De este modo, la descripción de los aspectos arquitectónicos del software ha estado tradicionalmente limitada al uso de ciertas expresiones, tales como arquitectura cliente/servidor, arquitectura en capas, etc., por lo general acompañadas con diagramas informales. Estas descripciones carecen de un significado preciso, lo que limita de manera drástica su utilidad, impidiendo, por ejemplo, cualquier análisis de las propiedades de los sistemas así descritos. Lógicamente, este tipo de representaciones no es el adecuado para dar a la Arquitectura del Software el rango que se merece. Existe una clara necesidad de notaciones de alto nivel, específicamente orientadas al problema de describir la arquitectura de los sistemas de software. La importancia de representar de forma explícita la arquitectura de los sistemas de software es evidente. En primer lugar, estas representaciones elevan el nivel de abstracción, facilitando la comprensión de los sistemas de software complejos. En segundo lugar, hacen que aumenten las posibilidades de reutilizar tanto la arquitectura como los componentes que aparecen en ella. Por ultimo, si la notación utilizada tiene una base formal adecuada, es posible analizar la arquitectura del sistema, determinando cuáles son sus propiedades aún antes de construirlo. Ahora bien, dentro de la Arquitectura de Software se establecen diferentes niveles de abstracción, estos niveles vienen representados por los estilos arquitecturales, los patrones arquitecturales y las vistas arquitectónicas. Los dos primeros niveles están relacionados con la arquitectura a nivel macro por ejemplo arquitectura en capas, cliente servidor, modelo vista controlador, etc. Mientras que las vistas arquitectónicas están referidas a los planos arquitectónicos de lo que será la futura aplicación o sistema. Cada vista agrupa a elementos que pertenecen a diferentes intereses, no obstante, se llegan a establecer relaciones de correspondencias entre los elementos de distintas vistas puesto que al formar parte de un mismo sistema de alguna manera se llegan a relacionar. Estas relaciones de correspondencia constituyen el adhesivo que mantiene enlace a las vistas que integran a la arquitectura del software. Las vistas arquitectónicas constituyen las estructuras fundamentales de la arquitectura, y hacen posible enfrentar su diseño desde diversas perspectivas reduciendo la complejidad presente en su desarrollo. El diseño de las vistas arquitectónicas implica establecer una sincronización entre sus elementos para conformar una arquitectura integrada, y poder ser capaz de mantener la consistencia entre sus elementos. En el presente trabajo de investigación se propone un Método de Diseño de Vistas Arquitecturales de un Sistema bajo un enfoque de calidad, el cual internamente estará formado por la definición de un proceso de diseño de vistas arquitecturales, la instanciación de este proceso para poder ser usado en metodologías de desarrollo de sistemas tradicionales, ágiles e híbridas y un modelo de calidad para evaluar el proceso de diseño y los productos del diseño. Este trabajo se encuentra estructurado de la siguiente manera: Capítulo I. El Problema: En este capítulo se realiza el planteamiento del problema, donde se hizo referencia a los antecedentes de la investigación, se analizaron y se compararon, de 2

14 esta manera se destacaron sus fortalezas y debilidades lo cual condujo al establecimiento de las interrogantes de la investigación, los objetivos perseguidos, la justificación, la importancia y el alcance. Capítulo II. Marco Teórico: Aquí se detallan los fundamentos teóricos que sustentan este trabajo. Capítulo III. Marco Metodológico: Durante este capítulo se describe la naturaleza de la investigación, el diseño de la investigación y el procedimiento utilizado. Capítulo IV. Propuesta: Se definen la estructura interna del Método de Diseño de Vistas Arquitecturales de un sistema bajo un enfoque de calidad, los fundamentos y los principios de la propuesta. Luego se describe en detalle cada elemento de la propuesta los cuales son: el proceso de diseño de vistas arquitecturales, la intanciación del proceso y el modelo de calidad para evaluar el proceso y los productos del diseño. Capítulo V. Conclusiones y Recomendaciones: Finalmente en este capítulo se exponen las principales conclusiones, destacando los aportes del trabajo; y se realizan las recomendaciones para trabajos futuros que se puedan realizar en el área de diseño de vistas arquitecturales. 3

15 CAPITULO I EL PROBLEMA Para nadie es desconocido que los Sistemas de Información han cambiado la forma en que operan las organizaciones actuales. Desde hace un tiempo que las organizaciones han sido consideradas en sí mismas sistemas de información y la información se ha posicionado como un elemento primordial dentro de los recursos que posee una empresa. A través del uso de los Sistemas de Información se logran importantes mejoras en la gestión empresarial, pues automatizan los procesos operativos, suministran una plataforma de información necesaria para la toma de decisiones y, lo más importante, su utilización encamina a las tan cotizadas ventajas competitivas. Es aquí donde juega un papel fundamental los Sistemas de Información, entendiéndose dicho concepto como: el conjunto formal de procesos que, operando sobre una colección de datos estructurada de acuerdo con las necesidades de una empresa, recopila, elabora y distribuye (parte de) la información necesaria para la operación de dicha empresa y para las actividades de dirección y control correspondientes, apoyando al menos en parte, la toma de decisiones necesarias para desempeñar las funciones y procesos de negocio de la empresa de acuerdo con su estrategia. (Andreu et. al., 2001) Cuando la organización decide gestionar y hacer uso de la información, el Sistema de Información a implementar (independiente del nivel de la organización en el cual se desea integrar el sistema) debe ser un fiel reflejo de las necesidades y requerimientos de la empresa. Es decir, no basta solamente con contar con la información sino que se requiere del diseño de un sistema integrado que relacione la información obtenida por las diversas aplicaciones de la empresa. Para ello, se requiere elegir la Tecnología de Información adecuada, como componente fundamental en la implementación de este sistema y como generador de ventajas estratégicas. La implementación de los Sistemas de Información entrelazados con la Tecnología de Información (TI) adecuada brinda múltiples beneficios que se ven reflejados en mejoras tales como: la optimización de la relación de la empresa con sus clientes, conocer cómo está respondiendo la empresa a las consultas y quejas (servicio al cliente), identificar quiénes son realmente sus clientes, conocer qué compran sus clientes, cómo y cuándo, detectar nuevas tendencias a partir de los hábitos de compra (marketing), el proveedor recibe la información de pedidos en un tiempo muy corto, eliminación de papeles y faxes ya que todo se hace por medio del software, reducción de costos, integración establecida de todas las funciones del negocio, facilidad de compartir amplia información de la empresa, proceso mejorado del trabajo, aumento en el acceso a los datos disponibles para la toma de decisiones, información oportuna y exacta, respuesta rápida a la operación de negocio y a las condiciones de mercado que cambian; dando por resultado ventajas competitivas mejoradas. 4

16 De lo dicho anteriormente surge la importancia de que dentro de los procesos de desarrollo de sistemas de información, existan los métodos, técnicas, procesos, herramientas y personal que conduzcan a la creación de productos de sistemas de software, que soporten de manera eficiente los sistemas de información dentro de las empresas u organizaciones que satisfagan las verdaderas necesidades de los clientes y del negocio. Ahora bien, de acuerdo con (Sommerville, 2005) la Ingeniería de Software es una disciplina que comprende todos los aspectos de la producción de sistemas desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. En esta definición existen dos frases claves: Disciplina de la Ingeniería: los ingenieros hacen que las cosas funcionen. Aplican teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir soluciones a los problemas, aún cuando no existan teorías y métodos aplicables para resolverlos. Los ingenieros también saben que deben trabajar con restricciones financieras y organizacionales, por lo que buscan soluciones tomando en cuenta estas restricciones. Todos los aspectos de producción de software: La ingeniería del software no solo comprende los procesos técnicos del desarrollo de software, sino también las actividades tales como la gestión de proyectos de sistemas y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software. Vale la pena destacar que el término Ingeniería de Software nace a finales de la década de los años 60, donde un grupo de personajes del área se reunieron en una conferencia de desarrollo de sistemas de software para conversar acerca de los problemas en cuanto a la construcción de sistemas para ese momento. A esta situación particular se le denominó la crisis del software. Según el (Standish, 1998), el cual hace una investigación acerca del estado de los proyectos de software, encontró que en 1998 en los Estados Unidos se gastaron más de $ millones de dólares por año en el desarrollo de aplicaciones de TI en aproximadamente proyectos. El costo promedio del desarrollo de un proyecto para una compañía grande es de $ dólares, para una compañía mediana es de $ dólares y para una compañía pequeña es de $ dólares. La investigación del Grupo Standish (1995) muestra que el 31.1% de los proyectos serán cancelados antes de que se completen. El 52.7% de los proyectos costarán 189% más de sus estimaciones originales. El costo de estas fallas y sobrecostos es sólo la punta del iceberg, ya que los costos de oportunidad perdidos son de miles de millones de dólares. Por ejemplo, el fracaso de producir software confiable para manejar el equipaje en el aeropuerto de Denver le costó a la ciudad $1.1 millones de dólares por día. Y como este proyecto hay muchos casos, desgraciadamente pocos han sido documentados. Standish (1995) cita que el 50% de los proyectos se consideraron operativos, pero no exitosos. El proyecto de software promedio se sobrepasa en su programación en la mitad o más. El 75 % de los productos de software grandes se entregaron a los clientes pero tienen fallas, son un fracaso porque no se usan o no cumplen los requerimientos del cliente. 5

17 En el año 2009, el director de Informática de la empresa The Standish Group, aseguró que estos números representan el porcentaje más alto de fracaso en una década. Esta situación se puede notar en el siguiente cuadro comparativo donde se detallan los resultados obtenidos en los estudios realizados por la empresa en los últimos años: citado por Domínguez (2009) en (Espinoza, 2012). Tabla Nº 1. Cuadro Comparativo de Resultados Obtenidos por los Estudios Realizados por Standish Group. Fuente: Domínguez (2009) De acuerdo con este estudio las causas por las cuales los proyectos fallaron obedecen a lo siguiente: 13% Requisitos Incompletos, 12% falta de compromiso del usuario, 11% recursos inadecuados, 10% expectativas no realistas, 9% falta de soporte gerencial, 9% requisitos cambiantes y 8% planeamiento inadecuado. Otro estudio hecho por Walraet, citado en (Zavala, 2003), encontró los siguientes porcentajes en cuanto al origen de los errores en el software: Fase de estudio y análisis (56%), fase de diseño (10%), fase de código (7%), y otros (27%). De acuerdo con (Zavala, 2004), en esta estadística se nota que las fases donde se generan más errores en el software son las fases de estudio, análisis y diseño, que al hacerse con vaguedad e imprecisiones provoca los problemas ya mencionados. Para (McManus 2003), los síntomas de una entrega deficiente de los sistemas de información son los siguientes: Solicitudes de cambio frecuentes por usuarios, los usuarios tienen un deficiente entendimiento de sus propias necesidades, tareas no consideradas, comunicación insuficiente, deficiencia en una metodología adecuada y lineamientos para estimación, deficiencia de coordinación del desarrollo de sistemas, tiempo insuficiente para pruebas, deficiencia en la preparación, alineación de la estrategia de negocios deficiente Ahora bien, (Zavala, 2004), plantea que gran parte de los enfoques que abordan la solución de la crisis del software básicamente se circunscriben a los siguientes enfoques: El producto, donde se debe mejorar el nivel de la calidad de los entregables del proyecto: modelos, documentos, código, etc. Tecnologías destacadas: UML (Lenguaje de Modelado Unificado), análisis y diseño orientado a objetos, programación orientada a objetos, entre las más importantes. El proceso de desarrollo mediante la adopción de modelos de ciclo de desarrollo y modelos de calidad que equivale a la administración de proyectos mediante el aprendizaje de técnicas de gestión por parte de los líderes de proyectos y administración de personal y el mejoramiento y predicibilidad de los resultados. 6

18 Tecnologías destacadas: Proceso Unificado, Capability Mature Model, ciclo de vida evolutivo, administración de proyectos, entre otras. El personal debe desarrollar un modelo de equipo de trabajo y procurar el uso de las técnicas, metodologías y herramientas de desarrollo necesarias para manejar la complejidad del sistema a desarrollar. Tecnologías destacadas: Team Software Process, Personal Software Process, organización de equipo, liderazgo, motivación, etc. De esta manera, estos estudios presentados ponen de manifiesto el hecho de que, a pesar de que las herramientas para construir sistemas de software han evolucionado enormemente, se sigue produciendo software que no satisface las necesidades para los clientes y-o usuarios, y los principales problemas residen en las etapas iniciales del desarrollo, cuando hay que decidir las características del producto software a desarrollar, y luego traducir esas características en especificaciones de diseño. De todo esto surge la preocupación por mejorar los métodos y técnicas que sostienen las primeras fases del desarrollo de un sistema de software como lo son: el modelado del negocio, la ingeniería de requisitos y el Diseño del Sistema. Este trabajo de investigación centra su atención en el Proceso de Diseño de Sistemas. Para (Pressman, 2010), la Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software. Una de las maneras para crear sistemas de forma sistemática y disciplinada es a través de los procesos o metodologías de desarrollo de sistemas. Para (Sommerville, 2005) un proceso de desarrollo de sistemas es un conjunto de actividades y resultados asociados que conducen a la producción de un producto software. Existen cuatro actividades fundamentales de procesos que son comunes a todos los procesos de desarrollo de sistemas: 1. Especificación del sistema: donde los clientes e ingenieros definen el sistema a producir y las restricciones sobre su operación. 2. Desarrollo del sistema: donde el software se diseña y programa. 3. Validación del sistema: donde el sistema se valida para asegurar que es lo que el cliente requiere. 4. Evolución del sistema: donde el sistema se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado. Por su parte (Jacobson, 2000), plantea que ningún proceso de desarrollo de sistemas es universal, los procesos varían porque tienen lugar en diferentes contextos, desarrollan diferentes tipos de sistemas y se ajustan a diferentes tipos de restricciones del negocio (plazos, costos, calidad y fiabilidad). Por consiguiente un proceso de desarrollo de sistemas del mundo real debe ser adaptable y configurable para cumplir con las necesidades reales de un proyecto y-o organización concreta. Una de las actividades que se deben ejecutar dentro de la aplicación de un proceso de desarrollo de sistemas es el diseño, en este sentido (Pressman, 2010), dice que el diseño 7

19 de un sistema se encuentra en el núcleo técnico de la Ingeniería del Software, y se aplica independientemente del modelo de diseño de sistemas que se utilice. Para (Pressman, 2010), la importancia del diseño del sistema se puede describir con una palabra - Calidad El diseño es el lugar donde se fomentará la calidad en la ingeniería del software. El diseño proporciona las representaciones del sistema que se pueden avaluar en cuanto a calidad. El Diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema finalizado. El Diseño del sistema sirve como fundamento para todos los pasos siguientes del soporte del sistema y de la ingeniería. Sin un diseño se corre el riesgo de construir un sistema inestable, un sistema que fallará cuando de lleven a cabo los cambios, un sistema que puede resultar difícil de comprobar, y un sistema cuya calidad no pueda evaluarse hasta muy avanzado el proceso, sin tiempo suficiente y con mucho dinero gastado en él. El Diseño de un Sistema es un proceso iterativo mediante el cual los requisitos se traducen en un plano para construir el sistema. Inicialmente el plano representa una visión holística del sistema. Es decir, el diseño se representa a un nivel alto de abstracción, un nivel que puede rastrearse directamente hasta conseguir el objetivo del sistema específico y según unos requisitos más detallados de comportamiento, funcionales y de datos. A medida que ocurren las iteraciones del diseño, el refinamiento subsiguiente conduce a representaciones de diseño a niveles de abstracción mucho más bajos. (Pressman, 2010). En este orden de ideas (Shaw y Garlan, 1995) plantean que la Arquitectura del Sistema alude a la estructura global del sistema y a las formas en que la estructura proporciona la integridad conceptual de un sistema. Para (Pressman, 2010), el objetivo del diseño del sistema es derivar una representación arquitectónica de un sistema. Esta representación sirve como marco de trabajo desde donde se llevan a cabo las actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permiten que el ingeniero reutilice los conceptos a nivel de diseño. Uno de los conceptos que se manejan en los niveles de abstracción de la arquitectura de un sistema, son las vistas arquitecturales, (Buschmann et al. 1996) establece que una vista arquitectónica representa un aspecto parcial de una arquitectura de software, que muestra propiedades específicas del sistema. Bass et al. (Bass et al. 1998), haciendo uso indistinto de los términos estructura y vista, proponen que las estructuras arquitectónicas pueden definirse agrupando los componentes y conectores de acuerdo a la funcionalidad del sistema, sincronización y comunicación de procesos, distribución física, propiedades estáticas, propiedades dinámicas y propiedades de ejecución, entre otras. Por su parte, (Kruchten 1999) define una vista arquitectónica como una descripción simplificada o abstracción de un sistema desde una perspectiva específica, que cubre intereses particulares y omite entidades no relevantes a esta perspectiva. Para la definición de una vista, Kruchten propone la identificación de ciertos elementos, que se mencionan a continuación: Punto de vista: involucrados e intereses de los mismos 8

20 Elementos que serán capturados y representados en la vista y las relaciones entre estos Principios para organizar la vista Forma en que se relacionan los elementos de una vista con otras vistas Proceso a ser utilizado para la creación de la vista Kruchten (1999) ha propuesto las 4+1 vistas arquitecturales, con una amplia aceptación, este autor plantea que los aspectos esenciales de la arquitectura del sistema se capturan en 4 vistas diferentes del sistema: la vista lógica o de datos, la vista de procesos, la vista de implementación y la vista de implantación o de despliegue. Todas estas vistas están integradas por una quinta vista, la vista de casos de uso. Cada una de estas vistas aborda diferentes aspectos de la arquitectura del sistema. De acuerdo con (Montilva et. al., 2009), el proceso de diseño de sistemas consta internamente de tres subprocesos los cuales son: el diseño de la arquitectura del sistema, el diseño de las interfaces usuario-sistema y el diseño de la base de datos. El diseño de la arquitectura debe incluir el diseño del estilo arquitectónico del sistema y el diseño de las vistas arquitecturales. Una vez que se ha definido la importancia que tiene el proceso de diseño en la construcción de un sistema para una organización que requiere soportar con TI sus procesos de negocio; y que se ha entendido que los planos dentro del diseño de un sistema se logran a través de las vistas arquitecturales, se hace necesario conocer como algunos de los procesos de desarrollo de sistemas más importantes abordan el tema de diseño. A continuación se revisará como Rational Unified Process mejor conocida por sus siglas RUP, una de las metodologías o procesos de desarrollo tradicionales que más aceptación ha tenido en el campo tanto académico como de la industria de desarrollo de sistemas y así lo respalda (Montilva et al, 2011) cuando dice el proceso RUP (Rational Unified Process) de IBM es uno de los métodos de desarrollo de software más conocido internacionalmente Veamos entonces como RUP define su proceso de diseño. Según (Jacobson et. al., 2000) en el Diseño se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los requisitos no funcionales y otras restricciones. Una entrada esencial en el diseño es el resultado del análisis, esto es, el modelo de análisis. El modelo de análisis según RUP proporciona una comprensión detallada de los requisitos; y lo que es más importante, impone una estructura del sistema que debe procurar conservar lo más fielmente posible cuando se de forma al sistema. Para estos autores los propósitos del Diseño son: Adquirir una comprensión en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y concurrencias, tecnologías de interfaz de usuario, tecnologías de gestión de transacciones, etc. 9

21 Crear una entrada apropiada y punto de partida para actividades de implementación subsiguientes capturando los requisitos o subsistemas individuales, interfaces y clases. Ser capaces de descomponer los trabajos de implementación en partes más manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo, teniendo en cuenta la posible concurrencia. Esto resulta útil en los casos en los que la descomposición no puede ser hecha basándose en los resultados de la captura de requisitos (incluyendo el modelo de casos de uso) o análisis (incluyendo el modelo de análisis). Un ejemplo podría ser aquellos casos en los que la implementación de estos resultados no es directa. o Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software. Esto ayuda cuando se hace reflexión sobre la arquitectura y cuando se utiliza interfaces como elementos de sincronización entre diferentes equipos de desarrollo. o Ser capaces de visualizar y reflexionar sobre el diseño utilizando una notación común. o Crear una abstracción sin costuras de la implementación del sistema, en el sentido de que la implementación es un refinamiento directo del diseño que rellena lo existente sin cambiar la estructura. Esto permite la utilización de tecnologías como la generación de código y la ingeniería de ida y vuelta entre el diseño y la implementación. Jacobson y sus compañeros hacen un cuadro donde comparan el modelo de análisis con el modelo de diseño generado en el proceso de diseño, dentro de su propuesta metodológica. Modelo de Análisis Modelo conceptual, porque es una abstracción del sistema y no permite aspectos de la implementación Genérico respecto al diseño (aplicable a varios diseños) Tres estereotipos conceptuales sobre las clases: control, entidad e interfaz. Menos formal Menos caro de desarrollar Menos capas Dinámico (no muy centrado en la secuencia) Bosquejo del diseño del sistema, incluyendo su arquitectura Creado principalmente como trabajo de a pie en talleres o similares Puede no estar mantenido durante todo el ciclo de vida del software Define una estructura que es una entrada esencial para modelar el sistema, incluyendo la creación del modelo de diseño. Modelo de Diseño Modelo físico, porque es un plano de la implementación. No genérico, específico para una implementación. Cualquier número de estereotipos (físicos) sobre las clases, dependiendo del lenguaje de implementación. Más formal Mas caro de desarrollar Más capas Dinámico (muy centrado en las secuencias) Manifiesto del diseño del sistema, incluyendo su arquitectura (una de sus vistas) Creado principalmente como programación visual en ingeniería de ida y vuelta; el modelo de diseño es realizado según la ingeniería de ida y vuelta con el modelo de implementación Debe ser mantenido durante todo el ciclo de vida del software Da forma al sistema mientras que intenta preservar la estructura definida por el modelo de análisis lo más posible. Tabla Nº 2. Comparación entre el Modelo de Análisis y el Modelo de Diseño. Fuente: (Jacobson, et al, 2000) 10

22 Seguidamente se presentan en detalle todos los artefactos que se generan con la aplicación del proceso de Diseño propuesto en RUP. Artefacto: Modelo de Diseño. El Modelo de Diseño es un modelo de objetos que describe la realización física de los casos de uso, centrándose en cómo los requisitos funcionales y no funcionales, junto con otras restricciones relacionadas con el entorno de implementación, tienen impacto en el sistema a considerar. Además, el Modelo de Diseño sirve de abstracción de la implementación del sistema y es, de ese modo, utilizada como una entrada fundamental de las actividades de implementación. El Modelo de Diseño define la jerarquía que se ilustra en la siguiente figura. Figura Nº 1. El Modelo de Diseño es una jerarquía de subsistemas de diseño que contienen clases de diseño, realizaciones de casos de uso diseño e interfaces. Fuente: (Jacobson et al, 2000) Nótese entonces que este artefacto viene a ser un compendio de otros artefactos que se deben construir, los cuales se describen a continuación. Artefacto: Clase del Diseño. Una Clase de Diseño es una abstracción sin costuras de una clase o construcción similar en la implementación del sistema. Esta abstracción es sin costuras en el siguiente sentido: El lenguaje utilizado para especificar una clase del diseño es el mismo que el lenguaje de programación. Consecuentemente, las operaciones, parámetros, atributos, tipos y demás son especificados utilizando la sintaxis del lenguaje de programación elegido. La visibilidad de los atributos y las operaciones de una clase de diseño se especifica con frecuencia. Las relaciones de aquellas clases de diseño implicadas con otras clases, a menudo tienen un significado directo cuando la clase es implementada. Por ejemplo, la generalización o algún estereotipo de generalización tiene una semántica que se corresponde con el significado de generalización o (herencia) en el lenguaje de programación. Esto es, las asociaciones y agregaciones a menudo se corresponden con variables (atributos) de clases en la implementación para proporcionar referencias entre objetos. Los métodos (o lo que es lo mismo, las realizaciones de operaciones) de una clase del diseño tienen correspondencia directa con el correspondiente método en la implementación de las clases (esto es, en el código). Si los métodos se especifican 11

23 en el diseño, se suelen especificar en lenguaje natural, o en pseudocódigo, y por eso pueden ser utilizados como comentarios en las implementaciones del método. Esto es una de las principales abstracciones entre diseño e implementación y es raramente necesario por lo que recomendamos que el mismo desarrollador diseñe e implemente una clase. Una clase de diseño puede posponer el manejo de algunos requisitos para las subsiguientes actividades de implementación, indicándolos como requisitos de implementación de la clase. Esto hace posible posponer decisiones que son inapropiadas de manejar en el modelo de diseño, como las que tienen que ver con el código de la clase. Una clase de diseño a menudo aparece como un estereotipo sin costuras que se corresponde con una construcción en el lenguaje de programación dado. Una clase de diseño puede realizar y por tanto proporcionar interfaces si tiene sentido hacerlo en el lenguaje de programación. Nótese que en la descripción de este artefacto no queda claro, si es un diccionario de clases de diseño, o si es un diagrama de clases con las clases de diseño especificadas dentro del diagrama. Artefacto: Realización de Casos de Uso Diseño. Una Realización de Caso de Uso Diseño es una colaboración en el modelo de diseño que describe cómo se realiza un caso de uso específico, y cómo se ejecuta, en términos de clases de diseño y sus objetos. Una Realización de Casos de Uso diseño proporciona una traza directa a una realización de casos de uso análisis en el Modelo de Análisis. Cuando el Modelo de Análisis no va a mantenerse a lo largo del ciclo de vida del software pero en cambio se utiliza solo para crear un buen diseño, no tendremos realización de casos de uso análisis. La dependencia de traza de una realización de casos de uso diseño irá en este caso directamente hasta el caso de uso en el modelo de casos de uso. La Realización de Casos de Uso Diseño tiene una descripción de flujo de eventos textual, diagramas de clases de diseño participantes, y diagramas de interacción que muestran la realización de un flujo o escenario concreto de un caso de uso en términos de interacción entre objetos del diseño. Para RUP la Realización de Casos de Uso Diseño también puede contener los Requisitos de la Implementación, estos requisitos son una descripción textual que recoge requisitos, tales como los requisitos no funcionales sobre una realización de caso de uso. Se refiere a requisitos que se capturan solo en la fase de diseño, pero que es mejor tratar en la implementación. Algunos de estos requisitos pueden haber sido identificados en flujos de trabajo anteriores y por tanto solo se cambian a una realización de caso de uso. Sin embargo, puede que algunos de ellos sean requisitos nuevos o derivados, que se identifican a medida que avanza el trabajo del diseño. (Jacobson et al, 2000). 12

24 Como puede observarse en la definición de Realización de Caso de Uso Diseño, está compuesta por: diagramas de clases, diagramas de secuencia, descripción literal del flujo de acciones del caso de uso, y los requisitos de implementación. Artefacto: Subsistema de Diseño. Los Subsistemas de Diseño son una forma de organizar los artefactos del modelo de diseño en piezas más manejables. Un Subsistema puede constar de clases de diseño, realizaciones de caso de uso, interfaces y otros subsistemas (recursivamente). Por otro lado un subsistema puede proporcionar interfaces que representan la funcionalidad que exportan en términos de operaciones. Un Subsistema debería ser cohesivo, es decir, sus contenidos deberían encontrarse fuertemente asociados. Además los subsistemas deberían ser débilmente acoplados; esto es, sus dependencias entre unos y otros, o entre sus interfaces, deberían ser mínimas. Los Subsistemas de Diseño también deberían poseer las siguientes características: Los Subsistemas pueden representar una separación de aspectos del diseño. Por ejemplo en un sistema grande, algunos subsistemas pueden desarrollarse por separado, y quizá de manera simultánea, por equipos de desarrollo diferentes con aptitudes de diseño distintas. Las dos capas de aplicación de más alto nivel y sus subsistemas dentro del modelo de diseño suelen tener trazas directas hacia paquetes y-o clases del análisis. Los Subsistemas pueden representar componentes de grano grueso en la implementación del sistema, es decir, componentes que proporcionan varias interfaces compuestas a partir de otros varios componentes de grano más fino, como los que especifican clases de implementación individuales, y que se convierten ellos mismos en ejecutables, ficheros binarios o entidades similares que pueden distribuirse en diferentes nodos. Los Subsistemas pueden representar productos software reutilizados que han sido encapsulados en ellos. Por tanto, pueden utilizarse los subsistemas en el modelo de diseño para representar la integración de productos software reutilizados. Subsistemas de este tipo residen en las capas intermedias y de software del sistema. Los Subsistemas pueden representar sistemas heredados (o parte de ellos) en capsulándoles. Por tanto, se puede utilizar subsistemas para incluir sistemas heredados en el modelo de diseño. Observe que esta definición de Subsistema de diseño es la definición de componente que hace el Lenguaje de Modelado Unificado. Artefacto: Interfaz. Las Interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del diseño. Una clase del diseño que proporcione una interfaz debe proporcionar también métodos que realicen las operaciones de la interfaz. Un subsistema que proporcione una interfaz debe contener también clases del diseño u otros subsistemas (recursivamente) que proporcionen la interfaz. 13

25 Las interfaces constituyen una forma de separar la especificación de la funcionalidad en términos de operaciones de sus implementaciones en términos de métodos. Esta distinción hace independiente de la implementación de la interfaz a cualquier cliente que dependa de ella. Se puede sustituir una implementación concreta de una interfaz, como puede ser una clase o un subsistema del diseño, por otra implementación sin tener que cambiar los clientes. Observe también que este artefacto se corresponde con las interfaces provistas o requeridas de los componentes de acuerdo con lo que establece el Lenguaje de modelado unificado. Artefacto: Descripción de la Arquitectura (vista del Modelo de Diseño). La Descripción de la Arquitectura contiene una vista de la Arquitectura del Modelo de Diseño, que muestra sus artefactos relevantes para la arquitectura. Suelen considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseño: La descomposición del Modelo de Diseño en Subsistemas, sus interfaces y las dependencias entre ellos. Esta descomposición es muy significativa para la arquitectura en general, debido a que los subsistemas y sus interfaces constituyen la estructura fundamental del sistema. Clases del Diseño fundamentales, como clases que poseen una traza con clases del análisis significativas. Realizaciones de Caso de Uso Diseño que describan alguna funcionalidad importante y crítica que debe desarrollarse pronto dentro del ciclo de vida del software, que impliquen muchas clases del diseño y por tanto tengan una cobertura amplia, posiblemente a lo largo de varios subsistemas, o que impliquen clases del diseño fundamentales. La definición de este artefacto no está clara, pareciera que este artefacto solo es una descripción literal del Modelo del Diseño. Artefacto: Modelo de Despliegue. El Modelo de Despliegue es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo. El Modelo de Despliegue se utiliza como entrada fundamental en las actividades de diseño e implementación debido a que la distribución del sistema tiene una influencia principal en su diseño. Se puede observar lo siguiente sobre el modelo de despliegue: Cada nodo representa un recurso de cómputo, normalmente un procesador o un dispositivo hardware similar. Los nodos poseen relaciones que representan medios de comunicación entre ellos, tales como Internet, intranet, bus, y similares. El modelo de despliegue puede describir diferentes configuraciones de red, incluidas las configuraciones para pruebas y para simulación. La funcionalidad (los procesos) de un nodo se definen por los componentes que se distribuyen sobre ese nodo. El modelo de despliegue en si mismo representa una correspondencia entre la arquitectura software y la arquitectura del sistema (hardware). 14