Aplicación de los atributos de calidad de Arquitectura Software
Anuncio
ESCUELA TÉCNICA SUPERIOR DE INGENIERIA (ICAI) INGENIERO SUPERIOR INFORMÁTICO Aplicación de los atributos de calidad de Arquitectura Software para el diseño de sistemas software basado en versiones AUTOR: Marcos Morosini Obregón DIRECTOR: Juan Antonio Pérez-Campanero MADRID, Mayo 2014 i UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ii UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO ABIERTO ( RESTRINGIDO) DE DOCUMENTACIÓN 1º. Declaración de la autoría y acreditación de la misma. El autor D. _____________________________________ , como _______________ de la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en relación con la obra____________________________________________________________________________ __________________________________________________________1, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra. En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente. 3º. Condiciones de la cesión. 1 Especificar si es una tesis doctoral, proyecto fin de carrera, proyecto fin de Máster o cualquier otro trabajo iii UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia, el repositorio institucional podrá: (a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así como incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua” o cualquier otro sistema de seguridad o de protección. (b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato. . (c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet.2 (d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 3 4º. Derechos del autor. El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a: a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento. b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio. c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación ([email protected]). d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN. 2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los siguientes términos: (c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional 3 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado. iv UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA e) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella. 5º. Deberes del autor. El autor se compromete a: a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro. b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros. c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión. 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: a) Deberes del repositorio Institucional: - La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas. - La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras. - La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. v UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas: - retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en caso de reclamaciones de terceros. Madrid, a ……….. de …………………………... de ………. ACEPTA Fdo…………………………………………………………… vi UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA vii UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Agradecimientos: Quiero mostrar mis agradecimientos a todo el mundo que ha estado junto a mi durante todos estos años de carrera haciéndome más fácil y llevadero el duro trabajo que conlleva llegar a ser ingeniero superior. Es una gran recompensa al esfuerzo y dedicación que ser ingeniero supone. En primer lugar agradecer a mis padres de todo corazón el esfuerzo económico al que han estado expuestos durante todos estos años para que pudiese estudiar en una de las mejores universidades posibles viviendo en una ciudad que no es la mía de origen, teniendo así un gasto mayor. Nunca me han faltado ni su apoyo ni su atención, ayudándome así a conseguir todos y cada uno de mis objetivos académicos. También agradecer al resto de familiares y amigos de toda la vida el estar junto a mi durante todos estos años ya que teniéndoles cerca han hecho que cada día que he pasado haya valido la pena. Por otra parte, mencionar con especial cariño a todas y cada una de las personas que he tenido a mi lado en la universidad, tanto profesores como compañeros, ya que se pasan muchas horas dentro de la universidad, y tener una gran relación con todos ellos han hecho que todo el tiempo que he pasado en ese edificio lo recuerde durante el resto de mi vida. Agradecer aquí a mi director de proyecto, Juan Antonio Pérez-Campanero, por ayudarme con sus conocimientos en la realización del proyecto y al coordinador Israel Alonso por mantenerme informado en todo momento de las mejoras que debía hacer para llegar a la consecución del mismo. Por último, no quiero terminar sin mencionar a mi novia, ya que es de las personas que más me ha apoyado en los momentos difíciles y que ha estado día tras día conmigo aguantándome en lo bueno y sobre todo en lo malo. Espero estar en todos los momentos importantes de su vida y que, por supuesto, ella esté en los míos. Muchísimas gracias, todos tenéis parte de culpa de haber conseguido que me convierta en ingeniero superior informático. viii I UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA APLICACIÓN DE LOS ATRIBUTOS DE CALIDAD DE ARQUITECTURA SOFTWARE PARA EL DISEÑO DE SISTEMAS SOFTWARE BASADOS EN VERSIONES. Autor: Morosini Obregón, Marcos Director: Pérez-Campanero, Juan Antonio. Entidad Colaboradora: ICAI – Universidad Pontificia Comillas RESUMEN DEL PROYECTO Introducción La aportación de este proyecto es unir los aspectos técnicos con los económicos teniendo como base la arquitectura software. Es algo innovador que aún no se encuentra en el mercado y resulta de gran utilidad para las empresas que quieran mejorar los sistemas que utilizan ya que no pierden ni tiempo ni dinero en buscar información o contratar personal que les haga el trabajo que esta aplicación puede hacer. Es un tema que está en el día a día de las empresas y que no se le presta la atención y dedicación que merece. Al tenerlo en cuenta se evitarían muchos problemas a la hora de incurrir en costes innecesarios o pérdida de tiempo en un proyecto. Si se estudia bien la arquitectura del software de un sistema, teniendo en cuenta principalmente los atributos de calidad que, en su conjunto, definen de alguna manera un sistema, se elabora una lista de requisitos necesarios para completar un proyecto cualquiera. Al tener claro lo que se va a necesitar hacer para conseguir la ejecución perfecta del mismo, se evita en un porcentaje muy alto que surjan imprevistos y problemas durante la elaboración del proyecto. Además de una lista de requisitos también se tienen en cuenta los costes en los que se va a incurrir al mejorar cada atributo por separado. Al unirlo se obtiene el coste total y ahí es cuando la empresa se da cuenta si es viable realizarlo o no dependiendo de lo que se esté dispuesto a pagar por dicho proyecto. En resumidas cuentas, este proyecto es un avance importante en el ámbito de la creación o modificación de proyectos. Propone estudiar todos y cada uno de los puntos a tener en cuenta para conseguir un resultado óptimo y ver cuánto esfuerzo económico va a suponer para la empresa. Permite saber aproximadamente cómo va a ser la realización de I UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA un proyecto antes de comenzarlo. Esto lleva a la empresa a decidir y prepararse para ello de dos maneras posibles: Darse cuenta que es inviable y pensar qué otros cambios pueden realizar o ver que es viable y teniendo la lista de requisitos comenzar a cumplir lo que hay en ella. Cualquier error cometido en una fase del desarrollo, se multiplica por 10 o 20 en fases posteriores, por lo que un error cometido en los requisitos del software llevará a un análisis incorrecto o con errores. En las fases de diseño y desarrollo será más grave, de ahí la importancia del Diseño de la Arquitectura del Software, que es anterior a cualquier fase del ciclo de vida del software. Esto además impediría iniciar proyectos que fueran inviables evitando importantes pérdidas de dinero, ya que precisamente la viabilidad o inviabilidad es uno de los aspectos que se detectarían antes ni siquiera de haber empezado el proyecto. Metodología Este proyecto se ha dividido en dos partes diferenciadas a la hora de su realización. En primer lugar se ha hecho un estudio teórico exhaustivo para tener claros todos los conceptos que se están tratando y así poder obtener un resultado que permita proponer una solución útil y avanzada para las empresas. Se estudia cómo está en la actualidad la arquitectura software y sus posibles avances pero sobre todo se centra en saber todo acerca de los seis atributos de calidad principales y las tácticas a utilizar para mejorarlos. Es la parte más importante ya que si conocemos bien toda la información relativa a estos atributos, más fácil resultará mejorarlos en un sistema. Esta basado también en poder realizarlo en diferentes versiones, por los que se manejan tres de las más importantes y utilizadas en la actualidad. Se trata de las aplicaciones móviles y las modalidades RIA Y WEB. La modalidad RIA (Rich Internet Applications) son aplicaciones web que tienen la mayoría de las características de las aplicaciones tradicionales. Utilizan navegador web y por medio de una máquina virtual se añaden características adicionales. Esta modalidad surge como la combinación de las ventajas de aplicaciones de escritorios y web. Mejoran la productividad y experiencia del II UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA usuario. Sólo se produce comunicación con el servidor cuando se necesitan datos externos ubicados en bases de datos o de otros ficheros externos, situación que rara vez pasa ya que desde el principio se carga toda la información en la aplicación. [RICH2007]. La modalidad WEB permite a los usuarios utilizar herramientas accediendo a un servidor web a través de Internet/Intranet mediante un navegador. Una página web puede contener elementos que permiten comunicación activa entre el usuario y la información que quiere así accede a los datos de modo interactivo respondiendo la página a cada acción deseada por el usuario. [CONS2014]. La aplicación móvil es una aplicación informática diseñada para ser utilizada por teléfonos inteligentes, tabletas y cualquier dispositivo móvil. Se encuentran disponibles a través de plataformas de distribución operadas por compañías propietarias de los sistemas operativos móviles. [DISE2011] Resuelta esta parte, también se realizará, como es lógico, un estudio intenso sobre aspectos económicos para poder relacionarlo con el aspecto descrito anteriormente ya que es el fundamento de este proyecto. Por último, combinando los dos estudios anteriores, se procederá a realizar una aplicación que los relacione y así de un soporte de gran utilidad a las empresas que quieran realizar cambios en su sistema y lo quieran utilizar. Resultado Obtenemos una aplicación que ofrece a las empresas unos resultados interesantes acerca de las relaciones existentes entre los atributos de calidad y la viabilidad del proyecto en sí. Ofrece información que puede ser muy útil para ayudar a tomar decisiones acerca de los cambios que se van realizar en un sistema. Se pueden hacer todas las simulaciones que se quiera para ver que cambios son los óptimos para ellos y, al introducir los costes previamente adquiridos con presupuestos, ver si es viable o no realizar ese proyecto sabiendo la inversión económica que se puede realizar. Sirve para nuevos proyecto o para introducir variaciones en uno ya existente. III UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Referencias [RICH2007] Modalidad RIA. http://searchsoa.techtarget.com/definition/Rich-InternetApplication-RIA [DISE2011] Modalidad WEB. http://www.bab- soft.com/es/diseno_desarrollo_aplicaciones_web.php [CONS2014] Aplicación móvil. http://www.siliconnews.es/2014/05/05/5-consejos- para-desarrollar-una-aplicacion-movil/ IV UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA APPLICATION OF QUALITY ATTRIBUTES OF SOFTWARE ARCHITECTURE FOR THE DESIGN OF SOFTWARE SYSTEMS BASED ON DIFFERENT VERSIONS. Author: Morosini Obregón, Marcos Director: Pérez-Campanero, Juan Antonio. Collaborating Entity: ICAI – Universidad Pontificia Comillas PROJECT SUMMARY Introduction The contribution of this Project is to link the engineering aspect with the economic one on the basis of the software architecture. It is something innovative that is not yet on the market and is useful for companies whose want to improve their systems. They don´t waste time and don´t spend money searching for information or hiring employees for doing the same as the application does. This subject it´s not given the attention and dedication it deserves because taking account of it, many problems would be avoided when incurring on unnecessary costs. Considering quality attributes we can develope a list of requirements for completing any project. When we know what we are going to need to get the perfect execution are avoided the problems in a very high percentage during the development of the project. In addition to a list of requirements, we also take account the costs of improving each attribute separetely. Joining it, we obtain the total cost and the company can know if this project is feasible or not depending on what they are willing to pay for it. Summarizing, this project is an important advance in the area of project creation and modification. It considers all the important points for having the best possible results and see the economic effort will mean for the company. It allows to know about the realization of the project before starting it. This make the company to prepare and decide in two different ways; Realice that it´s not feasible and think in other changes can be made or see that is feasible and, having the list of requirements, begin serving what is in it. Any mistake made in a developmental phase, it´s multiplied by 10 or 20 in later stages, so an error in software requirements will lead to an incorrect analysis or with errors. In the V UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA design and development phases will be more serious, hence the importance of Design Software Architecture, which is prior to any phase of the software lifecycle. This will also prevent the start of unfeasible projects, avoiding substantial losses of money. The feasibility or infeasibility is one of the aspects that would be detected before even having started the project. Methodology This project has been divided in two different parts on it realization. First, An exhaustive theorical study about all the concepts we are working with has been made in order to give a result as close as possible to perfection. We study how it is the software architecture now and it possible developments but mainly focused on knowing everything about the six main quality attributes and the tactics used to improve them. It´s the most important part because if we know well the information on these attributes, it will be easier to improve a system. It´s also able to do it in different versions, which are handled by three of the most important and used modalities today; RIA and WEB modalities and mobile app´s. A rich Internet application (RIA) is a Web application designed to deliver the same features and functions normally associated with deskop applications. RIAs generally split the processing across the Internet/network divide by locating the user interface and related activity and capability on the client side, and the data manipulation and operation on the application server side. An RIA normally runs inside a Web browser and usually does not require software installation on the client side to work. However, some RIAs may only work properly with one or more specific browsers. For security purposes, most RIAs run their client portions within a special isolated area of the client desktop called a sandbox. The sandbox limits visibility and access to the file and operating system on the client to the application server on the other side of the connection. [RICH2007]. A web application is any application software that runs in a web browser or is created in a browser-supported programming language. There is an active comunication between the server and the client with an interactive method where the server answering any question to the client. [CONS2014]. A mobile application is an application designed to run on smartphones or tablets. This applications are available through application distribution platforms. The VI UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA popularity of that is rising because it use has become increasingly prevalent across mobile phone users. Developing applications for mobile devices requires to consider the constraints of it. The power of the battery is less than the computers one. It´s important to consider that mobiles are not computers and it applications have to be adapted for them. [DISE2011] Resolved this part, an intensive study of economics aspects will be taken in order to link it with the aspect described above. This is the clue of the project. Finally, combining the two previous studies we proceed to program an application that support companies to make decisions about system changes. Results We obtain an application that offers companies some interesting results about the relationship between quality attributes and the viability of the project. It provides information than can be very useful in helping to make decisions about changes that can be made on a system. Multiple simulations can be made to see what changes are optimal for them and introducing costs estimated previosuly, see if it is viable or not knowing the finantial investment that the company can support. It´s useful to new projects or only for introducing changes in an existing one. VII UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA References [RICH2007] Modalidad RIA. http://searchsoa.techtarget.com/definition/Rich-InternetApplication-RIA [DISE2011] Modalidad WEB. http://www.bab- soft.com/es/diseno_desarrollo_aplicaciones_web.php [CONS2014] Aplicación móvil. http://www.siliconnews.es/2014/05/05/5-consejos- para-desarrollar-una-aplicacion-movil/ VIII UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Índice de la memoria CAPÍTULO 1. INTRODUCCIÓN ............................................................................................................... 1 CAPÍTULO 2. METODOLOGIAS BASADAS EN ARQUITECTURA SOFTWARE ............................ 5 2.1. LINEAS DE INVESTIGACIÓN DE LA ARQUITECTURA SOFTWARE ............................................. 7 2.2. MODELOS Y VISTAS ..................................................................................................................................... 10 2.3. LENGUAJES DE DESCRIPCIÓN ARQUITECTONICA ........................................................................ 13 2.4. PROCESOS Y METODOLOGÍAS ................................................................................................................ 15 2.5. ESCENARIOS ................................................................................................................................................... 16 2.6. MÉTODOS DE EVALUACIÓN DE ARQUITECTURAS SOFTWARE .............................................. 17 2.7. HERRAMIENTAS DE EVALUACIÓN DE ARQUITECTURAS SOFTWARE ................................. 18 CAPÍTULO 3. FUTURO DE LA ARQUITECTURA SOFTWARE ...................................................... 21 3.1. ARQUITECTURA SOFTWARE COMO CONCEPTO ............................................................................................. 21 CAPÍTULO 4. VALIDACIÓN DE LA ARQUITECTURA SOFTWARE ............................................. 23 4.1. ATRIBUTOS DE CALIDAD ................................................................................................................................... 23 4.2. LAS TÁCTICAS ..................................................................................................................................................... 29 CAPÍTULO 5. DISPONIBILIDAD .......................................................................................................... 31 5.1. TÁCTICAS ............................................................................................................................................................. 40 CAPÍTULO 6. MODIFICABILIDAD ...................................................................................................... 47 6.1. TÁCTICAS ............................................................................................................................................................. 49 CAPÍTULO 7. RENDIMIENTO ............................................................................................................... 53 7.1. TÁCTICAS ............................................................................................................................................................. 55 CAPÍTULO 8. SEGURIDAD .................................................................................................................... 59 8.1. TÁCTICAS ............................................................................................................................................................. 64 CAPÍTULO 9. USABILIDAD ................................................................................................................... 67 9.1. TÁCTICAS ............................................................................................................................................................. 76 CAPÍTULO 10. VERIFICABILIDAD ..................................................................................................... 79 10.1. TÁCTICAS .......................................................................................................................................................... 82 CAPÍTULO 11. MODELO COCOMO ..................................................................................................... 85 11.1. TIPOS DE MODELOS ......................................................................................................................................... 86 IX UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA CAPÍTULO 12. MODELO COPLIMO .................................................................................................... 91 CAPÍTULO 13. DESARROLLO DEL MODELO ................................................................................... 93 13.1. CASOS REALES DEL MODELO ....................................................................................................................... 118 CAPÍTULO 14. CONCLUSIONES ......................................................................................................... 125 BIBLIOGRAFIA ....................................................................................................................................... 127 ANEXO A. PLANIFICACIÓN DEL PROYECTO ................................................................................. 129 ANEXO B. ESTUDIO ECONÓMICO ..................................................................................................... 133 X UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Índice de figuras FIGURA 1. SISTEMA .................................................................................................................................. 4 FIGURA 2. KRUCHTEN 4+1 ..................................................................................................................... 7 FIGURA 3. DIAGRAMA DE CAJAS ........................................................................................................... 9 FIGURA 4. DIAGRAMAS DE CASO DE USO DE UML ....................................................................... 10 FIGURA 5. FLUJO CONTEXTUAL ATAM ............................................................................................ 17 FIGURA 6. RED DE PETRI ..................................................................................................................... 19 FIGURA 7. ATRIBUTOS DE CALIDAD INGLÉS ................................................................................. 23 FIGURA 8. ATRIBUTOS DE CALIDAD ESPAÑOL ............................................................................. 24 FIGURA 9. ESCENARIO EN EL MODELO DE KRUCHTEN 4+1 ..................................................... 27 FIGURA 10. REPRESENTACIÓN DEL ESCENARIO .......................................................................... 27 FIGURA 11. REPRESENTACIÓN DE TÁCTICA ................................................................................. 29 FIGURA 12. GRÁFICA DE MTBF, MTTR ............................................................................................ 37 FIGURA 13. ALGORITMO DE DECISIÓN ........................................................................................... 41 FIGURA 14. MONITORIZACIÓN .......................................................................................................... 44 FIGURA 15. CONCEPTOS DE LA USABILIDAD ................................................................................ 67 FIGURA 16. VENTANA PRINCIPAL .................................................................................................... 94 FIGURA 17. DISPONIBILIDAD ............................................................................................................. 95 FIGURA 18. MODIFICABILIDAD ......................................................................................................... 95 FIGURA 19. RENDIMIENTO ................................................................................................................. 96 FIGURA 20. SEGURIDAD ....................................................................................................................... 96 FIGURA 21. USABILIDAD ..................................................................................................................... 97 FIGURA 22. VERIFICABILIDAD ........................................................................................................... 97 FIGURA 23. MANUAL DE USO ............................................................................................................. 99 FIGURA 24. RELACIÓN ENTRE ATRIBUTOS ................................................................................. 100 XI UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA FIGURA 25. PARÁMETROS DISPONIBILIDAD .............................................................................. 101 FIGURA 26. PARÁMETROS MODIFICABILIDAD .......................................................................... 102 FIGURA 27. PARÁMETROS RENDIMIENTO .................................................................................. 102 FIGURA 28. PARÁMETROS SEGURIDAD ........................................................................................ 103 FIGURA 29. PARÁMETROS USABILIDAD ...................................................................................... 104 FIGURA 30. PARÁMETROS VERIFICABILIDAD ............................................................................ 105 FIGURA 31. RELACIONES ................................................................................................................... 106 FIGURA 32. MODELO ........................................................................................................................... 107 FIGURA 33. CÁLCULOS ........................................................................................................................ 108 FIGURA 34. ALMACENAMIENTOS .................................................................................................... 108 FIGURA 35. CONSULTAS ..................................................................................................................... 109 FIGURA 36. INFORMES ........................................................................................................................ 110 FIGURA 37. CÁLCULO DE COSTES .................................................................................................... 110 FIGURA 38. VIABILIDAD PROYECTO .............................................................................................. 111 FIGURA 39. RELACIONAR PARÁMETROS ..................................................................................... 112 FIGURA 40. MODIFICACIÓN PORCENTAJES ................................................................................. 112 FIGURA 41. PRESUPUESTO ............................................................................................................... 113 FIGURA 42. VIABILIDAD .................................................................................................................... 114 FIGURA 43. DISCOS RAID ................................................................................................................... 116 FIGURA 44. DIAGRAMA DE GANTT ................................................................................................. 130 FIGURA 45. TAREAS ............................................................................................................................. 131 FIGURA 46. RESUMEN TAREAS ........................................................................................................ 131 FIGURA 47. DIAGRAMA DE GANTT II ............................................................................................. 132 XII UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Índice de tablas TABLA 1. SIGLAS DE ABREVIACIÓN .................................................................................................. 25 TABLA 2. RELACIÓN ENTRE ATRIBUTOS DE CALIDAD .............................................................. 25 TABLA 3. DEFINICIÓN DE LOS ELEMENTOS DEL ESCENARIO .................................................. 28 TABLA 4. MTTR DEL HARDWARE ..................................................................................................... 35 TABLA 5. MTTR DEL SOFTWARE ...................................................................................................... 36 TABLA 6. TIEMPO DE INACTIVIDAD ................................................................................................ 37 TABLA 7. ESCENARIO PARA LA DISPONIBILIDAD ....................................................................... 39 TABLA 8. RESUMEN DE LAS TÁCTICAS PARA LA DISPONIBILIDAD ....................................... 44 TABLA 9. IMPACTO DE LAS TÁCTICAS PARA LA DISPONIBILIDAD ....................................... 45 TABLA 10. ESCENARIO PARA LA MODIFICABILIDAD ................................................................. 48 TABLA 11. RESUMEN DE LAS TÁCTICAS PARA LA MODIFICABILIDAD ................................. 51 TABLA 12. ESCENARIO PARA EL RENDIMIENTO ......................................................................... 54 TABLA 13. RESUMEN DE LAS TÁCTICAS PARA EL RENDIMIENTO ......................................... 58 TABLA 14. ESCENARIO PARA LA SEGURIDAD ............................................................................... 63 TABLA 15. RESUMEN DE LAS TÁCTICAS PARA LA SEGURIDAD .............................................. 66 TABLA 16. ESCENARIO PARA LA USABILIDAD ............................................................................. 75 TABLA 17. RESUMEN DE LAS TÁCTICAS PARA LA USABILIDAD ............................................. 77 TABLA 18. ESCENARIO PARA LA VERIFICABILIDAD .................................................................. 81 TABLA 19. RESUMEN DE LAS TÁCTICAS PARA LA VERIFICABILIDAD .................................. 82 TABLA 20. TARIFAS DEL PERSONAL .............................................................................................. 133 TABLA 21. TARIFAS DE SERVICIOS ................................................................................................ 134 TABLA 22. TABLA DE COSTES .......................................................................................................... 135 TABLA 23. COSTES TOTALES ............................................................................................................ 135 XIII UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA XIV UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 1. Introducción. La “ingeniería del software” es un término que mencionó por primera vez Fritz Bauer en 1968 y, como es lógico, desde ese momento hasta el día de hoy se han producido avances que hacen que se sepa cada vez más acerca de ello. Este proyecto es un avance más para conocer mejor acerca de este tema. [INTR2003] La base se compone principalmente de dos libros. El primero es “ The mitical man/month : Essays on software engineering” de Fred Brooks, y el segundo es “El modelo COCOMO” de Barry Boehm, siendo ambos libros de 1975 y 1970 respectivamente. Se consideran de los libros más influenciables debido a que fueron los que recogieron la información más importante acerca de este tema durante muchos años. La investigación en este área no ha cesado hasta el día de hoy y eso lleva a muchas teorías establecidas por aquellas personas que se han dedicado a realizar estudios exhaustivos, llegando cada uno de ellos a conclusiones diferentes, aportando su pequeño granito de arena para poder acercarse a la perfección en su conocimiento. Lo principal en lo que se ha trabajado ha sido en el desarrollo de metodologías de análisis, desarrollo y diseño del software. El objetivo no es otro que comprobar si el software a desarrollar es el aconsejable y poder determinar con la mayor certeza posible si va a ser correcto o no el desarrollo del sistema. Se combinan la estructura, el funcionamiento y el resultado, lo que nos lleva a una nueva definición : la arquitectura software. Unido esto a la evolución constante de las tecnologías y la necesidad de realizar ajustes económicos a la hora de comenzar un proyecto debido a la situación económica actual, se procederá a realizar dicho proyecto. La evolución tecnológica permitirá la posibilidad de escoger diferentes tipos de versiones, desde la modalidad web (cada vez utilizada por más gente gracias a que las personas tienen cada vez más información de cómo utilizar Internet), hasta las aplicaciones móviles cada vez más usadas en los teléfonos inteligentes o tabletas, que se han convertido en un foco de producción bastante importante. Una conclusión muy importante, sobre todo para las modalidades WEB y RIA es HTML5. Es la quinta versión del lenguaje básico 1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA HTML. Especifica dos variantes de sintaxis: el clásico HTML con la variante HTML5 y otra XHTML conocida como sintaxis XHTML5 que deberá ser servida como XML. Esta es la primera vez que HTML y XHTML se han desarrollado en paralelo. El consorcio internacional que produce recomendaciones para la Word Wide Web, conocido como W3C, indica que se encuentra aún en fase experimental, aunque ya es usado por múltiples desarrolladores web por las mejoras que incorpora. El consorcio, denominado W3C, regula el desarrollo con este lenguaje de marcado. Al no ser reconocido en viejas versiones de navegadores por sus nuevas etiquetas, se recomienda al usuario común actualizar a la última versión mejorada y así poder disfrutar de todo el potencial que provee HTML5. Algunas de las novedades que incorpora son: • Etiquetas (canvas 2D y 3D, audio, vídeo) con codecs para mostrar los contenidos multimedia. Actualmente hay una lucha entre imponer codecs libres (WebM + VP8) o privados (H.264/MPEG-4 AVC). • Etiquetas para manejar grandes conjuntos de datos: Datagrid, Details, Menu y Command. Permiten generar tablas dinámicas que pueden filtrar, ordenar y ocultar contenido en cliente. • Mejoras en los formularios. Nuevos tipos de datos (eMail, number, url, datetime…) y facilidades para validar el contenido sin Javascript. • Visores: MathML (fórmulas matemáticas) y SVG (gráficos vectoriales). En general se deja abierto a poder interpretar otros lenguajes XML. • Drag & Drop. Nueva funcionalidad para arrastrar objetos como imágenes. Económicamente hablando, hay que tener mucho cuidado en la actualidad con las inversiones o cambios que se realizen ya que se pueden producir pérdidas importantes que, incluso en una situación extrema, pueden llevar a la bancarrota a una empresa. Por ello, este proyecto supone un avance, ya que antes de comenzar con gastos en cualquier 2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA proyecto, se realiza una simulación sobre qué supondría la realización de dicho proyecto, y así analizar si conviene o no meterse en un proyecto de tal envergadura. Centrándonos en el proyecto en sí, sobre qué va a aportar y qué impacto va a tener en la industria, se puede comentar todo lo mencionado anteriormente, es decir, la gran ayuda que supone a la hora de afrontar un proyecto. Además de esto, después de todo el estudio necesario que se realizará, la programación de la aplicación es un gran avance ya que es fácilmente modificable según vayan surgiendo nuevos descubrimientos en el mundo de la tecnología y así, modificar dentro de la aplicación todo lo necesario, para seguir dando los resultados correctos según el punto en el que se encuentre la industria. El trabajo no termina una vez acabe el proyecto, ya que como acabamos de comentar, necesitarán actualizarse los valores. Según aumente la experiencia en el trabajo con los sistemas además del avance tecnológico, se ajustarán en mayor medida los valores que se muestran en el modelo como resultado (porcentajes como veremos durante el proyecto). Resumiento, el proyecto es una mezcla entre la ingeniería, la economía y la experiencia a la hora de trabajar con estos dos temas principales. Además supone el resurgir de un tema que se había dejado un poco abandonado dentro de la ingeniería y que como se va a demostrar a lo largo del proyecto, es de gran utilidad para todas las personas que trabajen en esta industria. Hay una serie de razones por las que se debe realizar este proyecto y no otro, las cuales voy a explicar a continuación. Lo primero y más importante es el interés por el tema de la ingeniería del software, el cual al estudiar una carrera relacionada totalmente con la informática, es clave a la hora de tener más conocimientos acerca de esta ciencia. La programación de código es una de las bases de esta ingeniería y por lo tanto, todo lo que se pueda profundizar en ello y mejorarlo día a día será beneficioso para este mundo. La otra razón de peso que ha llevado a elegirlo ha sido el interés por la economía y su relación con todos y cada uno de los ámbitos de la ingeniería. Es aplicable totalmente a muchas situaciones de la vida cotidiana, y por lo tanto, también lo es a la ingeniería informática, y en concreto a la parte relacionada con el software. 3 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA La unión de estas motivaciones da como resultado el proyecto que está comenzando. Una combinación entre la ingeniería del software y la economía que dará resultados muy interesantes y supondrá un avance en esta rama de la informática. Si a esto le añadimos la situación económica actual, resulta aún más importante tener en cuenta este aspecto, ya que para realizar planes de viabilidad y estudios de mercado, hay que tener en cuenta en que situación nos encontramos ya que esto nos puede limitar a la hora de poder ser aconsejable o no un proyecto. Figura 1. Sistema. 4 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 2. Metodologías basadas en arquitectura software. Su estado actual. La primera constancia que se tuvo acerca del término “arquitectura del software” fue cuando Dijkstra mencionó este termino a la hora de afirmar que se necesita una estructura firme antes de comenzar a desarrollar sin orden. Esta definición fue un primer acercamiento hacia este término, pero más adelante fue cuando de verdad se comenzó a profundizar en ello. Se veía que las metodologías existentes no conseguían resolver los problemas en los desarrollos de software, es decir, no podían eliminar todos los defectos existentes. “Arquitectura software” es un término que tiene un gran número de definiciones, dependiendo de quién lo defina se referirá a un ámbito o a otro dependiendo del autor en cuestión. Se denominó como estructura conceptual de un sistema desde la perspectiva del programador por parte de Brooks y Iverson. Después de los fallos que seguía teniendo el software, como hemos comentado anteriormente, se empezó a utilizar el diseño estructurado, teniendo más en cuenta el diseño cíclico eliminando así el diseño en cascada. Esto suponía una separación entre el diseño y la implementación. Fue muy importante la creación de técnicas, herramientas y lenguajes de modelado específicos. Para hacer el sistema más flexible, Parnas declaró que la modularidad era muy importante. Para verlo más claro, la utilización de funciones es clave para ello y para poder acceder a las variables, sólo se podía realizar a través de dichas funciones. La idea principal era el aislamiento de los módulos siendo cada uno visto como una caja negra desde fuera. Existe un punto en común entre todos los módulos al que hay que volver siempre que se quiera acceder de un módulo a otro. Se afirmaba que todos los módulos más cercanos al punto en común previamente mencionado eran los que más probabilidad tenían de ser cambiados y en cambio los que más alejados se encontraban, probablemente no tendrían la necesidad de ser modificados. Resumiendo, se comenzó a pensar en la 5 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA “arquitectura software” como un paso previo indispensable antes de comenzar con el desarrollo del software. Después de todos los avances sobre la definición de la “arquitectura software” se llegó a un punto importante en el que esta se basaba en tres componentes clave: -­‐ -­‐ -­‐ Elementos : de procesamiento, datos o conexión. Forma : propiedades y relación entre los elementos. Razón : restricciones del sistema, la base. Wolf y Perry fueron los que llegaron a esta conclusión, y veían a la arquitectura más cercana a la codificación que al diseño. La idea principal del término es la relación entre requisitos, costes y proceso. Se deben satisfacer todos los requisitos, realizar una estimación de costes tal que se llegue al mejor punto en relación calidad precio y llevar una buena administración del proceso. Posteriormente surge el concepto de diseño basado en patrones. Son ideas que principalmente surgieron para la arquitectura en el mundo de la edificación pero fácilmente trasladables al mundo de la informática. Christopher Alexander declaraba que el término de reutilización era muy importante. En la primera década de siglo, la arquitectura software se orientó hacia el análisis, definición de atributos y diseño basado en escenarios. 6 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 2.1. Líneas de investigación de la arquitectura software. En primer lugar cabe hablar de el diseño orientado a objetos. Aquí entran en juego los diagramas UML. La arquitectura en esta fase se centra en las fases iniciales del proceso referido a los niveles más altos de abstracción, tanta que no tiene relación con el posterior diseño. Es fundamental la abstracción de datos, es decir, el encapsulamiento en clases y objetos. En esta línea de investigación se hace referencia a decisiones importantes en la organización, selección de elementos estructurales, comportamiento, composición y estilo arquitectónico. Estas características pueden ser descritas mediante las cinco vistas clásicas del modelo 4+1 de Kruchten. [KRUC2014] Figura 2. Kruchten 4+1 Centrándonos en el modelo de Kruchten explicaremos en que se basa cada vista para entender como se pueden describir las anteriores características. [KRUC2011] -­‐ Vista Lógica: Aquí es donde se representa la funcionalidad que servirá para los usuarios finales. Se representa todo lo que el sistema debe hacer, es decir, sus funciones y servicios ofrecidos. 7 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Vista de despliegue: Se muestra la perspectiva del programador. Gestiona el software de manera que se observa cómo está dividido el sistema software en componentes y la relación entre ellos. -­‐ Vista de procesos: Como su propio nombre indica, se muestran los procesos que hay en el sistema y cómo se comunican entre ellos. Se representa el flujo de trabajo de negocio desde la perspectiva de un integrador de sistemas. -­‐ Vista física: Son todos los componentes físicos del sistema y su relación mostrados desde la perspectiva de un ingeniero de sistemas. -­‐ Vista de escenarios: Representado por los casos de uso de software cuya función es unir y relacionar las cuatro vistas anteriores. En segundo lugar analizaremos la arquitectura estructural, basada en modelos como el estático de estilos, ADL’s y vistas. Se trata de la corriente clásica de la disciplina que nació mayoritariamente en la Universidad Carnegie Mellon (Clements, Shaw, Allen...). Su uso se ha visto reducido al ámbito universitario. Existen tres modalidades principales en su formalización. Se trata de los diagramas de cajas, ADL y lenguajes formales de especificación como pueden ser CHAM y Z. [SIST2009] 8 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 3. Diagrama de cajas. El diseño arquitectónico es el de más alto nivel de abstracción. El principal problema es que no se sabe cómo podría integrarse en el ciclo de vida debido a que su diseño no tiene por qué coincidir con al configuración del sistema y entonces no se suele hablar de lenguajes de programación ni clases u objetos. Se ha evolucionado la arquitectura hasta hacerla más relacionada con procesos. En tercer lugar conoceremos el estructuralismo arquitectónico radical. Está relacionado con lo que acabamos de comentar, es decir, con la arquitectura estructural. Tiene dos ideas principales. Una es la de excluir la importancia del modelado orientado a objetos y la otra definir metamodelos y estereotipos de UML. En cuarto lugar hablaremos de la arquitectura basada en patrones. Los modelos son de más bajo nivel que las anteriores. Gustan las metodologías de programación extrema. La idea principal es identificar y articular patrones preexistentes. En quinto y último lugar tenemos la arquitectura basada en escenarios. Es la más reciente de todas y su idea base es la de volver a la unión entre la arquitectura software y los requisitos y funcionalidad del sistema. Los autores más importantes salieron de la Universidad Técnica de Eindhoven, Brije, Groningen y Phillips Research (Bosch, Ionita, Obbink…). Se considera este estilo una evolución de la arquitectura estructural, la cual 9 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA podemos decir que es la que ha tenido más influencia. Se utilizan diagramas de casos de UML como herramienta ocasional. Figura 4. Diagramas de caso de uso de UML Capítulo 2.2. Modelos y vistas. Son ayudas a la hora de tomar decisiones. Hay muchos estándares (ISO, OMG, CEN, IEEE) que han querido normalizar aspectos de la arquitectura software para homogeneizar la terminología, modelos y procedimientos. Se ordenan las diversas perspectivas de los modelos arquitectónicos en forma de vistas y marcos de trabajo (formados por hasta seis vistas). Con estas afirmaciones podemos decir que las vistas son el subconjunto resultante de realizar una abstracción de la realidad. Se necesita establecer relaciones entre las vistas ya que son fundamentales para poder describir el sistema completo. Los principales marcos que podemos encontrarnos son: 10 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Marco de referencia para la arquitectura empresarial : Creado por Zachman. Identifica 36 vistas basadas en 6 niveles (ámbito, empresa, sistema lógico, tecnología, representación detallada y funcionamiento empresarial) y aspectos (datos, función, red, personas, tiempo y motivación). Es demasiado rígido y obsoleto (aunque ha servido de ayuda para posteriores definiciones). -­‐ Marco de referencia para Procesamiento Distribuido Abierto : Estándar de ISO. Sirve para grandes sistemas distribuidos. Define 5 puntos de vista para el sistema y su entorno (empresa, información, computación, ingeniería y tecnología). El lenguaje Corba es el más recomendado, significando sus siglas “Common Object Request Broker Architecture” y siendo un estándar definido por el Object Management Group permitiendo que algunos componentes software escritos en múltiples lenguajes de programación y en diferentes computadores puedan trabajar juntos. El problema es que no proporciona soporte para el punto de vista empresarial. [CORB2014] -­‐ C4ISR Architecture Framework : Propuesto por el Departamento de Defensa de Estados Unidos. Sus vistas son la Operacional, de Sistemas y Técnica. -­‐ TOGAF : Cuatro componentes principales siendo uno el más importante y definiendo cuatro vistas. Arquitectura de negocios, de datos, de aplicación y tecnológica. -­‐ Modelo 4+1 de Kruchten : Ya descrito anteriormente. -­‐ Esquema de cinco vistas : Creado por Booch, Rumbaugh y Jacobson. Las vistas propuestas son la de casos de uso, diseño, procesos, implementación y despliegue. Las más relacionadas con el tema que nos concierne, es decir, con la arquitectura software son las de diseño (tiene las clases, interfaces y relaciones entre el 11 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA problema y la solución) y de proceso (hilos y procesos, valga la redundancia, que forman los mecanismos de sincronización y concurrencia). -­‐ Nueve vistas : Bass, Clements y Kazman, autores importantísimos en la historia de la arquitectura software, las crean pensando en el diseño y la implementación. Son la estructura de módulo (asignación de tareas), lógica (abstracciones de requisitos funcionales del sistema), procesos (threads), física, uso (procedimientos o módulos), llamadas a funciones (subprocedimientos), flujo de datos (módulos para envío de datos), flujo de control (programas) y clases (objetos). -­‐ IEEE 1471-2000 : Base común para describir la arquitectura software. Términos clave como la arquitectura, vista y punto de vista. La arquitectura es la organización fundamental del sistema, con sus componentes y sus relaciones. El punto de vista define un patrón para representar un conjunto de incumbencias. La vista es la representación concreta del sistema desde una única perspectiva. Éstas últimas se usan ya que ayudan a obtener una simplificación en la visualización de sistemas complejos, pero hay teorías que están en contra de su utilización debido a que al existir muchas vistas pueden, pueden llevar a problemas de integración y consistencia entre ellas. Todas las teorías que se sitúan en contra de las vistas se ven anuladas debido a su gran utilidad a la hora de dividir los diferentes aspectos existentes y tener una descomposición correcta del sistema para su mejor entendimiento. Las vistas fundamentales de las que podemos hablar son: -­‐ Estática: Define los componentes de la arquitectura. -­‐ Funcional: Describe qué hace cada componente. -­‐ Dinámica: Indica cómo se comportan los componentes en el transcurso del tiempo y su interacción. Para su mejor entendimiento se utilizan lenguajes desde el natural hasta el UML (lenguaje único para los modelos o vistas). 12 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Shaw y Garlan definieron distintos modelos muy importantes en este apartado: -­‐ Estructurales: Trabajo caracterizado por desarrollar lenguajes de descripción arquitectónica. (ADL’s). Son importantes los componentes que forman esta arquitectura, la conexión entre ellos y su configuración, propiedades, etc. -­‐ Framework: Parecido al anterior. Centrado en una única estructura del sistema completo. -­‐ Dinámicos: Atención a los cambios en la configuración del sistema y al proceso de datos e información. -­‐ De proceso: Construcción de la arquitectura y en sus pasos. -­‐ Funcionales: Proporcionan servicios. Capítulo 2.3. Lenguajes de descripción arquitectónica. Los lenguajes formales son una parte muy importante a la hora de representar la arquitectura software (basada en vistas). El UML es el más utilizado debido a una decisión unánime, pero los ADL, aunque sean más complejos, no tienen las carencias que poseen los lenguajes UML. Sin embargo, éste último está más extendido y entonces se tiene más experiencia a la hora de utilizarlo. Los problemas que surgen al utilizar UML como ADL son el basarse en conexión de objetos, semántica poco adecuada y relaciones entre vistas ocultas y poco claras. 13 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA A la par, las ventajas que poseen los lenguajes ADL son su forma de representación formal de la arquitectura, enfoque para buen entendimiento, sistema descrito al máximo nivel de abstracción, análisis de la arquitectura para saber si es completa y consistente y su fácil manera de generar automáticamente sistemas software. Aparte de estas ventajas, como todo, existen unos inconvenientes a la hora de utilizar el lenguaje ADL. No existe una clara especificación de qué se debe representar, sobre todo desde el punto de vista del comportamiento de la arquitectura. Representaciones difíciles de utilizar y no existe una herramienta que ayude a su uso. No está desarrollada más allá del nivel académico. Los tipos de ADL existentes son los siguientes: -­‐ ACME: Muy simple. Permite análisis sintáctico. Se estudia añadirle el componente del análisis de comportamiento de la arquitectura. Se sigue evolucionando. -­‐ Rapide: Especialidad en simulación. Su funcionamiento se basa en conjuntos de eventos ordenados. Fue desarrollado para aplicarlo al diseño de sistemas distribuidos grandes. Se comparan los resultados obtenidos en la simulación con los patrones establecidos de permisión o prohibición. Permite también el análisis en el tiempo. Una característica bastante importante es que se permite analizar, antes de comenzar con la producción del software, el rendimiento de sistemas sensibles al tiempo. Con los Posets (conjuntos de eventos) se consigue visualizar y analizarla ejecución del sistema. Es un lenguaje de simulación orientado a objetos y basado en eventos que permite expresar los requisitos del sistema como restricciones en el tiempo. Los componentes se ejecutan por separado esperando y generando eventos. Éstos pueden ser programados así controlándolos y sincronizándolos con un reloj. Es una arquitectura basada en interfaces y conexiones entre ellos de tipo básico, pipelines y agentes. La configuración define componentes, conexiones y restricciones. 14 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Wright: Lenguaje de propósito general con el objetivo de analizar protocolos de comunicaciones. Se utiliza una herramienta CPS, al ser derivado suyo, para el análisis. Similar sintácticamente a ACME y Aesop (del que hablaremos a continuación) . -­‐ Aesop: Mismo desarrollador que el anterior. Enfocado hacia estilos arquitectónicos. Cuenta con un conjunto de herramientas y un marco de trabajo específicos, cosa que Wright no tiene. También posee mucha facilidad en cuanto al intercambio e interoperabilidad con otros lenguajes de diseño arquitectónico. -­‐ MetaH: Enfocado al diseño de aplicaciones de navegación, guiado y control. Herramientas muy útiles. -­‐ C2 SADL: Facilita el diseño utilizando estilos basados en el dinamismo. -­‐ SADL: Especifica jerarquías de arquitectura software centrándose en el refinamiento de la arquitectura. También existen otros tipos de lenguajes como Lileanna o Modechart, pero hemos mencionado los más importantes. Capítulo 2.4. Procesos y metodologías. Desde 1998, el SEI (Software Engineering Institute) y otros organismos elaboraron métodos específicos de procesos de ingeniería que sistematizan el rol de la arquitectura en el proceso que concierne desde la elaboración de requisitos hasta la entrega del producto terminado. Podemos mencionar algunos métodos como son ABD (Architecture Based Design), SAAM (Software Architecture Analysis Method), QAW (Quality Attribute Workshops), QASAR (Quality Attribute Oriented Software Architecture Desing Method), 15 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ADD (Attribute Driven Design), ATAM (Architecture Tradeoff Analysis Method), ARID (Active Review for Intermediate Design), CBAM (Cost Benefits Analysis Method), FAAM (Family Architecture Analysis Method), ALMA (Architecture Level Modifiability Analysis), SACAM (Software Architecture Comparison Analysis Method). Esta gran variedad de métodos significa que es muy difícil llegar a un método estándar debido a diferencias a la hora de pensar y mostrar puntos de vista y diversos. Capítulo 2.5. Escenarios. Es la base de muchos métodos. Kruchten lo definió correctamente al dividirlos en dos categorías; casos de uso (secuencias de actuación o interacción entre elementos de la arquitectura) y casos de cambio (modificaciones del sistema). Pensar en cómo nace un proyecto es la idea clave. El cliente y diseñador piensan en las posibles situaciones y en el comportamiento futuro del sistema. Así surgen las especificaciones de requisitos para recoger el comportamiento esperado del sistema. Los requisitos del sistema se traducen así en posibles escenarios cómo herramienta muy útil a la hora de ver la utilización que queremos del sistema antes de su desarrollo. En resumen, un escenario es como un guión de cómo se debe comportar el sistema normalmente o en una situación anómala dada por un problema inesperado. Son descritos en lenguaje natural, pero se suele utilizar el UML al ser más conocido y formal. Permite comprender más sencillamente y ver más claramente el escenario. Los escenarios pueden involucrar a más de un módulo o componente del sistema, comprobando su interrelación y así detectar errores en la arquitectura antes de comenzar con el proceso de desarrollo. 16 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 2.6. Métodos de evaluación de arquitecturas software. Algunos de los métodos existentes los hemos mencionado anteriormente. En este apartado nos centraremos en uno de los considerados más importante y extendido. Se trata del método ATAM (Architecture Tradeoff Analysis Method). Fue desarrollado por el SEI para analizar los atributos que definen la arquitectura software. Se utiliza mayoritariamente en el ámbito de la industria y está en continuo desarrollo. Utilizándolo, la evaluación dura entre tres y cuatro días, y se obtienen las siguientes conclusiones: · Clarificación de los requisitos de los atributos de calidad. · Mejora de la documentación de la arquitectura. · Documentación de las decisiones que afectan a la arquitectura final. · Identificación de posibles riesgos en el software lo antes posible. · Aumento y mejora de la comunicación entre todos los participantes. Figura 5. Flujo contextual ATAM 17 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Los escenarios ayudan a evaluar y mejorar la arquitectura, y se toman decisiones para cada uno de los escenarios propuestos. De aquí salen los riesgos, puntos débiles, puntos fuertes y decisiones finales en cuanto a la arquitectura. Así se consiguen diferentes arquitecturas diferentes de la inicial, es decir, diversas posibilidades que mejoran la primera. Los aspectos más significativos de la evaluación realizada son normalmente el estilo, un modelo jerárquico de los requisitos de la arquitectura, todos los escenarios que se han creado y su aplicación a la arquitectura, atributos de calidad aplicables, riesgos y fortalezas. Capítulo 2.7. Herramientas de evaluación de arquitecturas software. Son pocas las herramientas existentes para la evaluación de arquitecturas software. Algunas de ellas son: -­‐ ArchKriti: Se encarga del diseño y evaluación de arquitecturas software. Ayuda al arquitecto en el proceso de desarrollo con la generación de atributos de calidad, ADD y evaluación y documentación de la arquitectura así creando nuevos estilos de arquitectura y vistas. -­‐ SAM: Son las siglas de “Software Architecture Modeling and Analysis”. Capturan el modelo de carga de trabajo y los objetivos de rendimiento. El arquitecto así podrá identificar una arquitectura adecuada. Construyendo una “ Layered Queuing Network “ (LQN) , dígase en español una red de enlocamiento, el arquitecto encontrará la arquitectura que tendrá las restricciones de rendimiento, y queda resuelto mediante la simulación de eventos discretos. Se permite así refinar la arquitectura hasta encontrar la definitiva que cumpla los requisitos buscados. Se han buscado formas de integrar esta herramienta con las Redes Petri para crear 18 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA marcos de trabajo unificados con el fin de especificar y analizar los aspectos de la arquitectura software. -­‐ Arche: Herramienta experimental, como las anteriores, pero basada en software libre y utilizando la plataforma de desarrollo Eclipse. Desarrollada en MySQL. Figura 6. Red de Petri 19 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 20 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 3. Futuro de la arquitectura software. El futuro del tema abordado se antoja complicado ya que ha estado, está y estará en fase de investigación. Es caso de estudio en muchos lugares, pero a la hora de ponerlo en funcionamiento no se utiliza, bien por desconocimiento o bien por no existir interés por parte de las empresas. Una razón importante puede ser la económica. El software debe ser rentable y asegurar eso es difícil. Las teorías que se han establecido se han centrado en la información ya existente acerca de este tema y eso no ayuda a avanzar, se necesita algo más innovador acerca de ello. La confusión de mucha gente en cuanto a la palabra “arquitectura” lleva a que no se entienda bien lo que es la “arquitectura software”, y esa dificultar a la hora de entenderlo lleva a que muchas personas no quieran entrar en ello por verlo demasiado complejo. Por ello este caso de estudio, para ver si se logra un mejor entendimiento de ello y se ve aprovechable el utilizarlo en la industria. Capítulo 3.1. Arquitectura software como concepto. Evaluar los sistemas que se van a desarrollar es una acción muy importante para tener controlados los aspectos de seguridad y calidad, ya que son dos características del sistema software muy importantes para los ingenieros y gestores de proyectos de este tipo. Uno de los objetivos principales siempre es el de tener el mínimo coste posible a la hora de desarrollar un sistema software, y por ello se realizan constantes pruebas para detectar los problemas lo antes posible y, por lo tanto, resolverlos antes para evitar costes extras. La posibilidad que presenta la arquitectura software. siendo un claro beneficio, es que permite encontrar y resolver los problemas antes de comenzar con el diseño del sistema. Identificar los aspectos fundamentales de la arquitectura software es un aspecto muy importante a la hora de evaluar las arquitecturas software. Se intenta alcanzar el máximo 21 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA nivel de fiabilidad y mantenimiento. Cumplir los requisitos de calidad exigidos es el punto final al que se debe llegar. La revisión de la arquitectura dará lugar a mejores arquitecturas, valga la redundancia, debido a que se han mejorado todos los errores o riesgos de las anteriores, y esto dará a su vez lugar a mejores sistemas. Por norma general, cuando hay que hacer un sistema para un cliente, a éste se le entrega de manera que, con el paso del tiempo, se da cuenta que el propio sistema tiene problemas de disponibilidad y seguridad. Esto es por culpa de no haber realizado las pruebas pertinentes de la arquitectura. Plantear todas las posibles soluciones y llegar a la más óptima (hay veces que llegar a la mejor solución no es posible por cualquier motivo) es lo que se debe hacer, y de esto se encargará este proyecto, de evaluar todas las soluciones posibles, teniendo en cuenta estos requisitos de calidad y también el gasto que supondría implantarlo. Una vez realizado esto, la negociación con el cliente es el siguiente paso para que decida cuánto está dispuesto a gastar y que solución le gusta más. Así sí se realiza correctamente el proceso y se evitan las situaciones previamente comentadas, es decir, los problemas que le surgen al cliente posteriormente. Las decisiones que se toman finalmente se denominan más técnicamente tácticas. [MANT2012] 22 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 4. Validación de la arquitectura software. Conocer cómo se puede evaluar la arquitectura y que se acerque lo más posible a los objetivos propuestos es clave. Los atributos de calidad nos permiten definir los propios requisitos del sistema y las decisiones necesarias a tomar. Estas tácticas sólo hará falta utilizarlas si el resultado de la evaluación es negativo. Capítulo 4.1. Atributos de calidad. Los más importantes y utilizados a la hora de validad una arquitectura software son seis. Son los necesarios para realizar dicha evaluación y así poder modificar y adaptar a la arquitectura software las opciones planteadas. El riesgo del proyecto disminuye notablemente así y permite corregir todo lo posible antes de comenzar con el ciclo de vida de desarrollo aplicaciones software. Tal y como hemos dicho, existes más atributos, pero los que marcan la diferencia son los definidos por Bass, Clements y Kazman. [ATRIB2014] Figura 7. Atributos de calidad inglés 23 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 8. Atributos de calidad español Como podemos comprobar en ambas fotos, existen distintas posibilidades a la hora de elegir los atributos de calidad que queramos. Los que utilizaremos nosotros serán los de la última foto, es decir, seguridad (security), rendimiento (performance), verificabilidad (testability), modificabilidad (modificability), uso (usability) y disponibilidad (disponibility). Estos atributos de calidad forman parte de la arquitectura por lo que es complicado añadirlos posteriormente. Dependiendo de lo que exija cada arquitectura, se decantarán más por un atributo o por otro. Existen complejidades como por ejemplo, si tomamos como referencia el atributo de disponibilidad con el objetivo de que un sistema funcione al 100% en una empresa, es decir las 24 horas de cada día, si se corta el suministro eléctrico por la noche para ahorrar, ¿Se puede decir que se cumple el objetivo? Hay que tener en cuenta el entorno en el que se trabaja. Si se está pensando en instalar paneles solares, lo que daría electricidad gratuita, pero con vistas al futuro, de nuevo podríamos hacernos la pregunta, ¿Se puede decir que se cumple el objetivo? 24 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA En los sistemas de gran tamaño, el que se cumplan los atributos de calidad, no dependen sólo del código, sino también de la arquitectura software definida. [PONC2014] Los atributos de calidad dependen unos de otros. Si decidimos mejorar algún atributo de calidad debemos tener en cuenta que podemos estar empeorando otro. Existen relaciones fijas entre los atributos de calidad, es decir, siempre que modifiquemos uno, siempre será el mismo o los mismos los que se podrán ver modificados. Los atributos de calidad afectan directamente a la funcionalidad del sistema. D DISPONIBILIDAD M MODIFICABILIDAD R RENDIMIENTO S SEGURIDAD U USABILIDAD V VERIFICABILIDAD Tabla 1. Siglas de abreviación D D M R S X X X X R S M X X X X U X X V X V X X X U X X X X X X Tabla 2. Relación entre atributos de calidad 25 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Como podemos observar en la tabla de relaciones entre los atributos de calidad, vemos cómo modificando el atributo que sea, se ven afectados otros. Hay afirmaciones erróneas que explicaremos a continuación por qué lo son. Los atributos de calidad sólo se deben tener en cuenta en la definición de la arquitectura ya que durante el desarrollo software no se verán afectados. Esto no es verdad debido a que no podemos considerar los atributos independientes de la arquitectura. Si el desarrollo es perfecto no quiere decir que la calidad del sistema se alcance sin tener en cuenta los atributos. Para entenderlo mejor, utilizando como referencia el atributo de usabilidad, es importante definirlo correctamente en el aspecto arquitectónico pero también es clave conseguir una interfaz clara para que el usuario tenga facilidad a la hora de usarlo. Esto último no se consigue en la definición de la arquitectura, se realiza posteriormente. Tomar unas decisiones u otras influye mucho en la calidad que percibe el usuario al final. [ESTA2012] Teniendo en cuenta todos estos aspectos se llegó a la definición de un término que ayuda a resolver los problemas que pudieran surgir. Se trata de los escenarios de atributos de calidad. Recordamos que un escenario es la definición de un requisito específico de un atributo de calidad que nos permitirá poder evaluar el sistema y ver claramente si se han cumplido los propios requisitos o no. Así podremos enumerar los requisitos del sistema y evaluarlos en la arquitectura que elijamos antes de comenzar a diseñar y desarrollar y, por lo tanto, antes de comenzar con la creación del sistema. Cada escenario consta de seis partes. Cada una de ellas tendrá un valor diferente concreto, independiente del sistema. Si vamos a definir un escenario específico, podremos elegir una de entre varias opciones y asignar el valor que queremos que sea evaluado. 26 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 9. Escenario en el modelo de Kruchten 4+1 RESPUESTA ESTÍMULO ENTORNO ARTEFACTO MEDIDA FUENTE Figura 10. Representación del escenario 27 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA En la siguiente tabla se explican los conceptos de los que se habla en la figura anterior: ELEMENTO DESCRIPCIÓN FUENTE ACTOR QUE ACTÚA SOBRE EL SISTEMA DEFINIDO. PUEDE SER HUMANO, MECÁNICO O INFORMÁTICO ESTÍMULO ACTO PRODUCIDO POR LA FUENTE. EVENTO A TRATAR POR EL SISTEMA. ENTORNO CONDICIONES EN LAS QUE SE PRODUCE EL ESTÍMULO. ARTEFACTO PARTE DEL SISTEMA QUE RECIBE EL ESTÍMULO. RESPUESTA ACTIVIDAD GENERADA AL RECIBIR EL ESTÍMULO. MEDIDA MEDICIÓN DE LA RESPUESTA PARA SU CORRESPONDIENTE EVALUACIÓN. Tabla 3. Definición de los elementos del escenario. 28 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Los estímulos recibidos pueden ser muchos y diversos dando lugar a acciones totalmente diferentes en el sistema. Es totalmente irrelevante cuántas fuentes del mismo tipo generen los estímulos. Basta solamente con modificar la tasa de producción de los mismos. Capítulo 4.2. Las tácticas. Si al realizar la evaluación salen resultados negativos, es cuando entran en juego las llamadas tácticas. Estas son las decisiones que habrá que tomar para lograr el alcance de los objetivos. Con dichas tácticas se deberá controlar el cumplimiento de los escenarios definidos. Bass, Clements y Kazman representan la táctica en un gráfico muy simple. Es lo que se realiza después de recibir el estímulo y por lo que podremos generar la respuesta. [SCAL2012] ESTÍMULO TÁCTICAS Figura 11. Representación de táctica. 29 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Cada táctica que tomamos es una opción de cambio o mejora de la arquitectura, y estará relacionada con un atributo, requisito o escenario específico. Es muy importante tener en cuenta que la implantación de estas tácticas además de mejorar lo que no funcionaba del todo bien, puede afectar a la evaluación de otros atributos. Los atributos, como ya sabemos, no son independientes, pero es más, tienen una fuerte relación entre sí. Por ello debemos tener especial cuidado en la evaluación de la arquitectura. Cuanto antes se resuelvan estos problemas, más rápido, más fiable y económico será el desarrollo posterior. Para el mismo atributo a estudiar, tenemos diferentes opciones a la hora de tomar decisiones, por ello, debemos establecer un orden de prioridad en cuando a todas las decisiones posibles. Se puede utilizar una o varias. Una vez hablado de todo esto, podemos centrarnos en los seis atributos de calidad que van a ser parte fundamental de este proyecto y por ello, vamos a entrar en profundidad y tomar cada uno como un capítulo aparte. 30 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 5. Disponibilidad (Availability). Es una de las medidas más estudiadas debido a que es una de las más importantes. Se mide mediante el factor de disponibilidad, es decir, cuánto tiempo está un sistema o equipo operativo respecto de la duración total que se pretendía en un principio. Normalmente este resultado viene expresado en forma de porcentaje. [FACT2014] Horas deseadas Factor de disponibilidad = -------------------------------------------------------------Hº deseadas + Tº inoperativo + Tº reparación Definimos la disponibilidad de otra manera como la capacidad de que el sistema esté parcial o totalmente operativo y a su vez que maneje eficazmente los fallos que puedan ocurrir y afecten a la disponibilidad del sistema. En la definición de disponibilidad entran en juego los conceptos de confiabilidad y recuperación. [DISP2008] La disponibilidad de estado estacionario es la medición del tiempo que está funcionando un sistema en un periodo suficientemente largo como para poder recoger datos fiables y válidos. A partir de esto se definen los requisitos de disponibilidad del sistema. La fórmula asociada es la siguiente, que tiene mucho que ver con la que se ha definido anteriormente de factor de disponibilidad. [DISP2014] Disponibilidad = MTBF / ( MTBF + MTTR) MTBF = Mean time before failures (tiempo entre fallos). MTTR = Mean time to repair (tiempo de reparación). 31 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Es considerada como alta disponibilidad siempre y cuando la fórmula anterior tenga un porcentaje de “cinco nueves” o superior, es decir, 99,999% o mejor. [ALTA2014] Existen una serie de definiciones bastante relacionadas con el concepto de disponibilidad. Algunos de los más importantes los mencionamos a continuación: -­‐ Tiempo de recuperación: Es el necesario para realizar un parón ya programado o uno inesperado. Si no fuese posible recuperar el sistema, este tiempo sería infinito. -­‐ Disponibilidad de datos: Teniendo en cuenta todas las transacciones realizadas en sistemas de bases o almacenamiento de datos, es el grado de copias realizadas correctamente. Es un concepto que va aparte ya que el sistema puede fallar pero por ello no significa que se incurra en una pérdida de datos. -­‐ SLA: “Service Level Agreement”. Se trata del Acuerdo de Nivel de Servicio para el mantenimiento de equipos y servicios. Existen dos tipos de definiciones que conviene aclarar ya que puede dar lugar a equívoco su relación. Se trata de los fallos, dícese de un error o evento producido en el sistema del que el propio usuario se da cuenta de su aparición; y de las faltas, error que pasa desapercibido en un principio y que si sigue su desarrollo, en un futuro se convertirá en un fallo. El tiempo de reparación de un fallo transcurre desde la aparición del fallo hasta que éste deja de ser visible por el propio usuario. Estamos desarrollando un proyecto centrado básicamente en la parte software, pero la parte hardware también está relacionada con ello por lo que también hay que cuidarla. Los fallos hardware que pueden existir tienen como principales causas las siguientes: -­‐ Fallos de diseño: Errores presentes en el propio diseño, y por ello, serán pocos. 32 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Fallos aleatorios: Pueden producirse en cualquier momento. La forma de llevar a cabo su resolución es la redundancia. -­‐ Fallos iniciales: Se producen en productos nuevos. Sus principales causas son las malas soldaduras -­‐ Fallos por envejecimiento: Se dan cuando el producto ya está llegando al final de su vida útil. El deterioro lógico de los componentes produce fallos. La única solución posible es el mantenimiento de los mismos de manera que cuanto mejor se cuiden más tiempo durarán. Otra solución es cambiar los módulos de manera que no se permite que un componente llegue al mal estado por envejecimiento. Los fallos software se determinan teniendo en cuenta los defectos encontrados en el sistema. Se obtienen calculando el historial de todos los fallos producidos en la vida del producto. La densidad de defectos se mide en errores por número de líneas de código. La dimensión de estos errores depende de: · El procedimiento para diseñar y programar el software (no revisar código, no compilarlo, no ejecutarlo…). · La complejidad del software. Dependiendo del tipo de sistema y sus conexiones con el exterior, interfaces y demás características, son las que hacen que un sistema sea más complejo o menos. Cuanto más complejo sea, más probabilidad de que se puedan producir fallos. También, cuantos más componentes tenga un sistema, más complejo será. Esto indica que habrán más puntos susceptibles de fallos, por lo que su disponibilidad disminuirá en caso de que se produzcan. 33 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA · El tamaño del software también es muy importante. Cuanto mayor sea el sistema, es decir, cuantos más componentes tenga, más difícil será su mantenimiento y así aumentarán las probabilidades de que falle. · El porcentaje del código que se ha reutilizado en otros proyectos. · La rigurosidad de las pruebas que se han llevado a cabo con el software antes de ponerlo en producción e instalárselo al cliente. Todos estos posibles fallos de los que hemos hablado son los que pueden hacer que el sistema se caiga y perder así porcentaje de disponibilidad. Las medidas de disponibilidad se pueden clasificar de manera que nos queda: -­‐ MTBF: Se trata del tiempo medio entre fallos suponiendo un funcionamiento normal del sistema. Así se da la estimación de tiempo que debe pasar antes de que se produzca un fallo. -­‐ MTTR: Es el tiempo medio de reparación de un sistema. Relacionado con esta definición, disponemos de una tabla en la que, teniendo en cuenta todo tipo de posibilidades, mostraremos el tiempo posible de reparación. Debemos pensar que son los hipotéticos casos que pueden darse ya que no todas las empresas son iguales y se dedican a las mismas cosas. 34 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Tipo de reparación de MTTR estimado Contrato mantenimiento 24 horas al día Directamente con el cliente Media hora Jornada normal de trabajo Catorce horas (7 días) Jornada normal de trabajo Tres días (5 días) Fallo notificado mediante A través del sistema Siete días un mediador Operador a distancia Sistemas remotos Catorce días MTTR del HARDWARE Tabla 4. MTTR del Hardware. El MTTR de un módulo software se calcula como el tiempo necesario para que vuelva a estar operativo tras detectarse un fallo. Por todo esto, el objetivo principal es mantener este parámetro lo más bajo posible. Los factores de los que depende el MTTR son: · El uso de técnicas de tolerancia a fallos. · El Sistema Operativo. · Las técnicas de descarga de imágenes de código. 35 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA de MTTR estimado Mecanismo de Mecanismo recuperación de puesta en marcha fallos tras un fallo Arranca sistema desde Treinta segundos ROM No se arranca el sistema de nuevo. Se lanzan Treinta segundos Fallo detectado mediante funciones paradas. un mecanismo Se arranca el SO desde especializado disco. También se lanzan Tres minutos aplicaciones. Se arranca el SO. Aplicaciones descargadas Diez minutos en remoto No soporta detección de Sistema fallos arrancado Desde manualmente treinta minutos hasta dos semanas MTTR del SOFTWARE Tabla 5. MTTR del Software. Como podemos observar, el MTTR varía dependiendo de lo que cojamos como referencia, es decir, la parte hardware o la parte software. 36 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 12. Gráfica de MTBF, MTTR. La disponibilidad se puede medir de otra manera teniendo en cuenta el cálculo del tiempo que está caído o que no funciona. Esto es lo que se llama el tiempo de inactividad por año. DISPONIBILIDAD TIEMPO DE INACTIVIDAD 90% Entendido como un nueve 36,5 días en un año 99% Entendido como dos nueves 3,65 días en un año 99,9% Entendido como tres nueves 8,76 horas en un año 99,99% Entendido como cuatro nueves 52 minutos en un año 99,999% Entendido como cinco nueves 5 minutos en un año 99,9999% Entendido como seis nueves 31 segundos en un año Tabla 6. Tiempo de inactividad. 37 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA La caída de un sistema puede producirse o bien por una planificación previa, o bien debido a un evento exterior inesperado. El primero de los casos bien puede ser por trabajos de mantenimiento que requieran que el sistema no esté operativo durante la realización de dichos trabajos. El segundo de los casos se deben normalmente a fallos hardware o software. Las caídas planificadas, es decir, el primero de los casos previamente comentados, no suelen tenerse en cuenta a la hora de contar el porcentaje de disponibilidad de un sistema, ya que se supone que serán cortas y no afectarán al servicio de manera importante. Esto se debe a que se elige el mejor momento posible para que el impacto sea el menor posible. En términos económicos, el precio de venta de un producto siempre será directamente proporcional a muchas características, y entre ellas, la disponibilidad del sistema. El precio de los módulos y sistemas en función de su grado de disponibilidad es otro factor importante. Cuanto mayor sea la disponibilidad, más caro será desde el punto de vista económico, así creciendo el coste de forma exponencial en relación con la disponibilidad. Anteriormente hemos hablado de los escenarios. Por ello podemos establecer un escenario diferente para cada atributo de calidad. En este caso, vamos a definir el de la disponibilidad. 38 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ELEMENTO DESCRIPCIÓN FUENTE Diferenciamos entre fallos y faltas. La respuesta del sistema será diferente tratándose de una o de otra. ESTÍMULO Los fallos o faltas que se pueden producir son omisión (módulo falla al responder a una entrada sin responder), caída (módulo sufre constantes faltas de omisión), tiempo (respuesta fuera del intervalo requerido), respuesta (incorrecta). ARTEFACTO Recurso necesario para ofrecer una alta disponibilidad. ENTORNO Estado en el que se encuentra el sistema al producirse un fallo o falta. RESPUESTA Reacciones al fallo del sistema. (Registrar el fallo, notificarlo..). MEDIDA Porcentaje de disponibilidad, el tiempo de reparación, el tiempo que el sistema debe estar operativo. Todo relacionado con la medida disponibilidad. Tabla 7. Escenario para la disponibilidad. 39 concreta de UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 5.1. Tácticas. La disponibilidad es un término que es fácilmente detectable por el usuario, debido a que su funcionamiento se muestra en forma de fallos del sistema, o bien porque hace que el sistema no funcione correctamente, o bien porque el sistema puede seguir funcionando pero no de la manera que se requiere. Aunque estemos hablando de la disponibilidad, estos fallos tienen que ver con los demás atributos de calidad de los que hablaremos posteriormente. Visto desde la posición del usuario, la disponibilidad es el tiempo en el que no pueden utilizar el sistema. El tiempo de reparación o recuperación está relacionado con ello. Siempre es conveniente implantar medidas que permitan mejorar la tolerancia a fallos de un sistema. Estas tácticas las puede ofrecer el sistema operativo o los gestores de bases de datos. Se deberían tener en cuenta a la hora de diseñar el sistema. Estas tácticas se dividen en dos tipos; las que se centran en el tiempo dedicado al diseño y las del tiempo de ejecución. Lo que nos interesa a nosotros son las dedicadas al sistema, para que funcione correctamente y ofrezca la tolerancia a fallos requerida. Las tácticas se centran en la detección, recuperación y prevención de fallos o faltas. Son una parte muy importante de los atributos ya que son los que permitirán, en su mayor parte, el buen funcionamiento de un sistema en conjunto. Para comenzar, vamos a centrarnos en las tácticas definidas para detectar los fallos. Están orientadas al tiempo de ejecución y son: -­‐ Ping: Enviar un mensaje al receptor para que éste lo devuelva en un tiempo determinado, de manera que si vemos que no lo devuelve, sabremos que el sistema receptor ha caído y está fuera de servicio. -­‐ Excepciones: Mecanismos que detectan errores que podrían impedir el normal funcionamiento del programa, y al resolverlo, evitamos un fallo del sistema. 40 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Mensajes: El envío periódico de mensajes nos permite saber si el sistema receptor está en servicio o no. Es una táctica muy parecida al Ping. Para recuperar las faltas existen otro tipo de tácticas. Están todas ellas basadas en redundancia: [REDU2014] -­‐ Votación: Los procesos ejecutados en procesadores redundantes reciben los mismos datos y devuelven un valor que envían a un servidor, el cual decide cual es el mejor en base a un algoritmo de decisión. Esto detectará fallos hardware, los software no. Para que pueda resultar bien esta táctica, habría que añadir un componente que reciba los valores de los procesos y decidir cual es el adecuado. Una posibilidad existente es instalar algoritmos o software diferente, así detectaría fallos en los algoritmos y permite el buen funcionamiento en los casos que la tolerancia a fallos sea un requisito fundamental. La sincronización no será un problema ya que está asegurada debido a que todos los componentes están activos al mismo tiempo y reciben los mismos datos de entrada. Figura 13. Algoritmo de decisión. 41 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Redundancia activa: Los componentes reciben los eventos en paralelo, así que todos ellos estarán en el mismo estado. Si uno falla, cualquiera de los otros puede ocuparse del trabajo que debía hacer el componente caído. Se suele utilizar esta táctica en los sistemas cliente/servidor. La sincronización también está garantizada. Es requisito fundamental que los algoritmos o protocolos estén preparados para recuperar los fallos. Se necesita que haya algún elemento que elija qué componente debe tomar el control. -­‐ Redundancia pasiva: Un componente estará activo en un momento dado. Los demás estarán realizando la función de back up. Si cae el componente activo, cualquiera de los otros podrá tomar el control. También aquí debe existir un elemento que indique que componente debe ponerse a funcionar en lugar del caído. La actualización de datos suele ser constante por lo que el componente del back up se actualizará también al momento siendo esto beneficioso para el sistema. La sincronización en esta situación corresponde al componente primario, que utilizará la difusión a todos los back up para asegurar la propia sincronización. -­‐ Recambio: Se asemeja a tener piezas de recambio por si fallase algún componente y así asegurar la disponibilidad del sistema. Es una plataforma que se activará al detectarse el fallo para sustituir el componente que se encuentra en fallo. Los sistema que suelen tener este tipo de táctica son aquellos que tienen varios componentes que comparten la carga y son semejantes entre sí. Todos los componentes deben estar actualizados y deben tener el mismo estado. También aquí se necesitará un árbitro que decida qué componente escoger. Estos sistema que tienen esta táctica no suelen tener requisitos importantes de tiempo, debido a que la sustitución del componente puede llevar un tiempo. 42 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Las tácticas existentes para volver a poner a funcionar el sistema después de recuperar un componente fallido son: -­‐ Sombra : Al fallar un componente, el sistema lo restaura pero aún así podría seguir trabajando en un segundo plano para ver si su funcionamiento es correcto o no para asegurarse que no habrá problemas a la hora de ponerlo en estado de operación normal. -­‐ Sincronización de estado: Al recuperar el componente, se sincroniza con el resto para volver a la actividad normal. Esto requiere de un elemento que le envíe los mensajes necesarios para que vuelva a sincronizarse. -­‐ Checkpoint y Rollback: El checkpoint es el registro de estado consistente ante la presencia de determinados eventos. Gracias a esto, el sistema podrá recuperarse devolviéndolo a un punto anterior en el tiempo. Otro tipo de tácticas son las empleadas para la prevención de fallos, y son las siguientes: -­‐ Eliminación: Se trata de quitar del servicio de forma temporal un componente con el objetivo de realizar operaciones que permitan anticiparse a futuros fallos. -­‐ Transacción: Se trata de poner en conjunto operaciones de modo que se puede deshacer de ellas con una operación muy simple a la hora de que surgiese un fallo. Se utiliza mucho en los gestores de bases de datos. -­‐ Monitor: Vigila el funcionamiento de los procesos. Al producirse un fallo de un proceso, crea una instancia del mismo inicializándolo a un estado concreto. Este proceso es el que se conoce comúnmente como monitorización. 43 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 14. Monitorización. ESTÍMULO TÁCTICA Detección RESPUESTA ·Ping ·Excepciones ·Mensajes Recuperación y ·Votación reparación ·Redundancia activa Fallos ·Redundancia Reparaciones pasiva realizadas ·Recambio Poner en ·Sombra funcionamiento ·Sincronización ·Rollback Prevención ·Eliminación ·Transacción ·Monitorización Tabla 8. Resumen de las tácticas para la disponibilidad. 44 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA CAMBIO DESCRIPCIÓN IMPACTO EN COMPONENTE EN RELACIONES En el propio Parte implementada Sólo cambia el componente en el componente, comportamiento del sin cambios externos IMPACTO Sin cambios componente. Fácil de implementar Réplicas Adición Se de duplica el Fácil de implantar relaciones componente, sin entre cambios su componentes de la en los comportamiento, arquitectura redundancia réplica Entra dentro de la Depende modificabilidad componente Nuevas y la de la y del entre Suele ser componentes de la arquitectura modificando la sistema. arquitectura fácil de implantar Nuevas demás relaciones los arquitectura demás y el nuevo Adición de componente sin Necesario cambiar Difícil de implantar los requisitos modificar la arquitectura Nuevas relaciones requiriendo cambios entre en componentes de la objetivos y requisitos los arquitectura demás y el nuevo CAMBIO Modificar DESCRIPCIÓN IMPACTO Cambio de estructura EN IMPACTO COMPONENTE RELACIONES Fácil o difícil Modificar componente EN relaciones Eliminar Eliminarlo componente arquitectura de la Cambios arquitectura en Eliminar relaciones y requisitos Figura 9. Impacto de las tácticas para la disponibilidad. 45 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 46 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 6. Modificabilidad (Modificability). Para comenzar a definir este atributo podemos hablar de muchos aspectos que están íntimamente relacionados con el propio atributo y que reflejan clarísimamente su relación con el mismo: -­‐ Facilidad de mantenimiento: Influye en la resolución de problemas. -­‐ Extensibilidad: Capacidad para añadir funcionalidades al software. -­‐ Reestructurabilidad y reusabilidad: Asignación de módulos y su utilización en funciones o proyectos. Definir los máximos escenarios posibles también es objetivo en este atributo, como lo va a ser también en los demás. La modificabilidad tiene íntima relación con el coste que supone el cambio, por ello cada vez que se defina un escenario debemos preguntarnos qué queremos cambiar, cuándo y quién. -­‐ Qué: Cambiar algo puede afectar al sistema entero o alguna parte, ya que pueden añadir nueva funcionalidad, cambiándola o eliminándola. Se puede ver afectada tanto la parte hardware como la software. Hay unas partes que son más susceptibles al cambio que otras (interfaz de usuario o hardware), por evolucionar más rápido que lo demás. -­‐ Cuándo: Hay que elegir un determinado momento que será justo en el que menos afecte al desarrollo normal. La ventaja existente es que la mayoría de cambios de código se pueden realizar durante el funcionamiento del sistema ya que no le 47 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA afectará. Resumiendo, se puede realizar cambios hoy en día en tiempo de compilación, construcción, ejecución y uso normal. -­‐ Quién: Los puede realizar el usuario final, el programador, el administrador o el propio sistema. Cualquier cambio que se realice consume tiempo y dinero por lo que hay que elegir bien si es realmente necesario realizar un cambio o no. También es fácilmente cuantificable un cambio para su evaluación. ELEMENTO DESCRIPCIÓN FUENTE Usuario final, programador o administrador del sistema ESTÍMULO Cambios a realizar. Funcionales, cualitativos o de capacidad del sistema ARTEFACTO El propio sistema recibe el estímulo ENTORNO Cuándo debe cambiarse, es decir, en tiempo de diseño, de compilación, arranque o ejecución RESPUESTA Cómo se debe hacer el cambio MEDIDA Tiempo y coste del cambio. Tabla 10. Escenario para la modificabilidad. 48 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 6.1. Tácticas. Existen tres puntos de vista desde los cuales podemos conocer las tácticas a tener en cuenta para el atributo de modificabilidad y son: · Limitar las modificaciones: Se trata de reducir el número de módulos afectados por un cambio ya que cuantos menos módulos se vean afectados, menor será el coste de la modificación. Asignando responsabilidades a los módulos durante el diseño se limita el alcance de los cambios. Cinco tácticas pertenecen a esta característica: -­‐ Coherencia semántica: Son las relaciones entre las responsabilidades dentro de un módulo. Lo que se quiere asegurar aquí es que estas responsabilidades no dependen de otros módulos. Para que esto se cumpla se deben elegir funciones que tengan coherencia semántica. -­‐ Anticipo: Ante posibles cambios, intentan predecirlos, aunque esto es complicado ya que saber lo que va a ocurrir en el futuro es complicado. Se pretende minimizar los efectos de los cambios. Normalmente se suele utilizar esta táctica junto con la anterior. -­‐ Generalización del modulo: Así podremos manejar un número mayor de entradas a funciones y más fácil se podrán realizar los cambios. -­‐ Limitar posibles opciones: Las modificaciones que se plantean podrían afectar a muchos módulos. Al restringir las opciones se reducen los efectos de las modificaciones. · Prevenir el efecto onda: Este efecto consiste en la necesidad de tener que realizar cambios en módulos debido a que ser vieron afectados por el cambio en otro módulo. Según la dependencia entre módulos tomaremos unas tácticas u otras y estas pueden ser: 49 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Ocultar información: Descomponer la función en partes más pequeñas y ahí decidir cuáles van a ser públicas y cuáles privadas. Así aislaremos los cambios en un módulo para que no afecten a otros. Tiene relación con la táctica de anticipación a cambios. -­‐ Mantener interfaces: Desarrollo de interfaces los más abstractos posibles para enmascarar modificaciones entre funciones. -­‐ Limitar rutas de comunicación: Restringir datos compartidos entre módulos. -­‐ Intermediarios: Inserción de una responsabilidad entre otras dos la cual gestionará la relación entre ellas. · Diferir el tiempo de entrega: El tiempo necesario para realizar el cambio y la posibilidad de que los usuarios realicen ese cambio son dos elementos que necesitan de tácticas diferentes de las anteriores. Existen bastantes posibilidades en forma de tácticas para tratar esto. Hay cambios que se pueden realizar en tiempo de ejecución. -­‐ Registro en tiempo de ejecución: El sistema estará preparado para realizar cambios mientras se está ejecutando. -­‐ Ficheros de configuración: Cada línea del fichero contiene una palabra clave con uno o más argumentos. -­‐ Polimorfismo: Posibilidad de enviar un mensaje a un grupo de objetos cuya naturaleza puede ser heterogénea. Los objetos deben responder al mensaje. [POLI2014] -­‐ Reemplazar componentes: Si algún componente deja de funcionar correctamente realizar su reemplazamiento sin afectar a los demás. 50 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Fijar protocolos: Métodos a realizar normalmente de la misma manera. ESTÍMULO TÁCTICA RESPUESTA ·Coherencia semántica Localizar ·Anticipar cambios cambios ·Generalización ·Limitar opciones ·Ocultar Presencia de cambios información Cambios realizados, Prevenir ·Mantener probados y desarrollados efecto onda interfaces en tiempo y presupuesto ·Restringir comunicaciones ·Usar intermediario ·Registro en tiempo de ejecución ·Ficheros de Diferir el configuración tiempo de ·Polimorfismo entrega ·Reemplazar componentes ·Fijar protocolos Tabla 11. Resumen de las tácticas para la modificabilidad. 51 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 52 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 7. Rendimiento (Performance). Es el atributo de calidad por excelencia utilizado como mejor herramienta de evaluación de un sistema. El resto de atributos eran considerados como complemento del rendimiento, pero a lo largo de los años esto ha ido cambiando y se ha entendido que el resto de atributos son importantes también y que pueden dar información que el rendimiento no puede dar. De hecho, la seguridad, modificabilidad y disponibilidad se consideran hoy en día más importantes. [REND2014] La información que nos da el rendimiento es el comportamiento del sistema o componente del mismo en el momento de su ejecución. Define la forma de reaccionar del sistema ante los eventos, los cuales deben ser atendidos más o menos rápido dependiendo del tipo de evento que sea. Por lo tanto, se evalúan en base a medidas de tiempo o eventos temporales que exigirán una respuesta del sistema. Un ejemplo relacionado con el rendimiento es Google. No han realizado inversiones en equipos de gran potencia de procesamiento. Han preferido invertir en arquitecturas más distribuidas centradas en la seguridad y la disponibilidad, es decir, controlando que haya el mínimo de fallos posible y que el propio sistema tenga la mayor disponibilidad posible con el mayor número de nueves a ser posible. Como hasta ahora, también existe un escenario explícito para el rendimiento y este se recogerá en la tabla siguiente: 53 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ELEMENTO DESCRIPCIÓN FUENTE Usuario, sistema, reloj, línea de comunicaciones…Cualquier actor que pueda producir un evento en el tiempo (sin tener en cuenta el número de actores que lo generen). Internas o externas. ESTÍMULO Tipo de estímulo y tasa de llegada al sistema (periódico, estocástico o esporádico). ARTEFACTO Recibe el estímulo el propio sistema, el cual lo gestionará. ENTORNO Condiciones en las que se produce el estímulo (normal, sobrecarga..). RESPUESTA Actividad a realizar para tratar el estímulo. MEDIDA Tiempo en procesar el estímulo recibido (latencia, tiempo máximo, número de estímulos al minuto para ser procesados, número de eventos que no han podido ser respondidos cualquier situación…). Tabla 12.Escenario para el rendimiento. 54 por UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Analizar este atributo de calidad a veces se antoja difícil ya que el número de estímulos o eventos que se pueden producir son muchos y diferentes. Para entender qué tipo de eventos pueden darse podemos mencionar respuestas de un usuario por pantalla, recepción de un mensaje por una línea de comunicaciones, un reloj que marca intervalos de tiempo…por lo que la respuesta del sistema será completamente diferente para cada uno de ellos. Desde el punto de vista del análisis de rendimiento del sistema, da igual el número de actores de igual tipo que generen los estímulos, ya que el efecto sería aumentar o disminuir el número total de estímulos y de su frecuencia. Esto se podría realizar modificando la tasa de producción de cada uno de ellos lo que quedaría reflejado en la mayor o menor presencia de actores productores de eventos. Capítulo 7.1 Tácticas. Están relacionadas con la capacidad de generar una respuesta del sistema en un tiempo determinado ante la presencia de un evento (mensaje, finalización de temporización…). Se controla el tiempo en el que se generan las respuestas. El tiempo que transcurre entre la generación del estímulo y la respuesta del sistema puede deberse a dos causas en principio: -­‐ Consumo de recursos: Procesador, almacenadores de datos, ancho de banda de líneas de comunicación o el tipo de memoria. A la hora de procesar los eventos se puede involucrar a varios de estos recursos. La gestión del software, drivers de entrada y salida, composición de mensajes, gestión de buffers o el algoritmo de tratamiento consumen tiempo y retardan la respuesta a los eventos. -­‐ Tiempo de bloqueo: En la utilización de dispositivos hardware. Aquí el tiempo es necesario para realizar operaciones de entrada y salida. Puede haber en cola operaciones que hagan que el evento deba esperar a ser tratado. Si el dispositivo no está disponible en el momento de tratar el evento o intentar acceder a datos que 55 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA están siendo utilizados o que un proceso deba esperar el resultado de la operación de otro proceso para poder empezar su cometido pueden ser otras causas posibles. Todo esto está relacionado con la concurrencia y los sistemas multiprogramados. En cuanto a las tácticas para mejorar la arquitectura teniendo en cuenta el rendimiento podemos hablar de: [DESF2014] ; [PROG2013] ; [OPTI2013] -­‐ Necesidad de recursos: Reducirlos es la idea. Para disminuir la latencia hay que disminuir también el número y tipo de recursos necesarios para el tratamiento del evento ya que debido a la concurrencia y a la gestión de los eventos por el sistema operativo, cada uno contribuye por separada a hacer más largo el tiempo de respuesta. Para conseguir esto existen diversas opciones: · Aumentar la eficiencia: Los tiempos de respuesta pueden ser más o menos largos dependiendo del diseño del algoritmo de tratamiento. Cuanto más mejoremos el algoritmo, menor será la latencia. · Reducir la sobrecarga: Eliminando intermediarios que puedan producir procesamiento innecesario en diversas situaciones. · Reducir el número de eventos: Revisando el diseño de la arquitectura se pueden realizar cambios que a la larga, generarán menor número de eventos. En esto mucho tienen que ver los datos, ya que a veces existen datos duplicados o innecesarios para el sistema. Si los reducimos, también se reducirá el tiempo de latencia con mejores tiempos de respuesta. -­‐ Gestión de recursos: Beneficia al sistema utilizar alguna de las tácticas que vamos a mencionar a continuación: 56 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA · Concurrencia: Puede beneficiar al rendimiento del sistema ya que permitirá ejecutar procesos o hilos al mismo tiempo además siendo estos especializados en el tratamiento de determinados tipos de eventos. · Copias: Mantener múltiples copias de datos o de las operaciones realizadas. La utilización de un sistema cliente/servidor permite tener clientes idénticos repartidos, de manera que esto contribuye a mejorar los tiempos de respuesta del sistema en general. La técnica de ‘catching’ nos permitirá llevar el contenido lo más cerca posible del sitio donde va a ser utilizado minimizando el tiempo. El coste así será menor. · Recursos: Aumentar el número de recursos. Existen varias características que contribuyen a que el tiempo de latencia sea menor como pueden ser procesadores más rápidos, sistemas multiprocesador, más memoria en el sistema que lleva a una menor paginación, más velocidad, discos más rápidos… Sencillo y eficaz. -­‐ Planificación de recursos: Al existir un recurso que tuviese que atender a múltiples peticiones a la vez, habrá que establecer mecanismos de planificación del mismo. Conocer las características de cada recurso es fundamental para la realización de un algoritmo de planificación correcto y adecuado a los requisitos de la arquitectura. Los principales son FIFO (First Input First Output), RR (Round Robin), por prioridad, SJF (Shortest Job First) y muchos más que podríamos mencionar. 57 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ESTÍMULO TÁCTICA RESPUESTA ·Incrementar eficiencia Necesidad de ·Disminuir sobrecarga recursos ·Reducir número de eventos ·Concurrencia Eventos Gestión de recursos ·Realizar copias Respuesta con restricción de ·Aumentar el número de recursos ·Algoritmos de planificación Tabla 13. Resumen de las tácticas para el rendimiento. 58 tiempo UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 8. Seguridad (Security). Hablamos de la seguridad como una medida del sistema para mostrar la capacidad del mismo a la hora de resistirse a un uso no autorizado. La seguridad se puede romper debido a ataques que pueden ser de distintos tipos (acceso no autorizado a datos, modificaciones, denegar acceso a usuarios autorizados…). La seguridad se caracteriza por tener las siguientes propiedades: -­‐ No repudiar: No negar una transacción, es decir, el acceso o modificación de datos. Un usuario no puede ocultar una operación si la ha realizado. -­‐ Confidencialidad: Protección de datos y servicios ante accesos no autorizados. -­‐ Integridad: No se cambian los datos o servicios entregados y se ejecutan como son. -­‐ Garantía: Se verifica que las partes de una transacción son las que son. -­‐ Disponibilidad: Un sistema estará disponible para su uso a los usuarios autorizados legítimamente. -­‐ Auditabilidad: Se registran las actividades ejecutadas para poder reconstruirlas si fuese necesario. Las vulnerabilidades son las que hacen posible que el sistema sea fácilmente atacable. La mayoría de ellas son vulnerabilidades software no resueltas y configuraciones software inseguras surgidas en diseño y codificación. Los fallos de seguridad pueden producirse durante todo el ciclo de vida del producto. Pueden producirse de manera involuntaria o provocados por acciones mal hechas del personal. Por estas razones, la seguridad del software debe ser vigilada en todo momento y concretamente: 59 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Desarrollo: El software puede corromperse por el desarrollador. En un futuro esto puede afectar a la fiabilidad del propio software y la confianza de cuando estaba en funcionamiento. -­‐ Despliegue: Involucra las actividades de distribución e instalación. Dependiendo del medio de distribución del software, éste quedará expuesto a posibles ataques. Para no ser vulnerable a ataques se debe configurar el software de manera segura y bloquear el hardware en el lugar de instalación. -­‐ Operación: Al estar el software operativo se debe actualizar periódicamente para que las vulnerabilidades queden eliminadas y no se puedan descubrir o publicar. Así el software será menos inseguro. La red de comunicaciones en la que se trabaje también será importante a la hora de que el software quede más o menos expuesto a ataques. Depende de que ésta sea pública o privada, conectada a Internet o que esté configurado para minimizar su exposición. Nunca se podrá garantizar una seguridad completa ya que obviamente habrá siempre personal que tenga acceso al sistema, y nunca se sabe si alguien lo usará con fines indeseados. -­‐ Logística: Los responsables de corregir los fallos de seguridad del sistema son piezas clave también, ya que si fallan cuando deben emitir actualizaciones o no encuentran y arreglan las causas que generan las vulnerabilidades, con el paso del tiempo el software será cada vez más dado a recibir ataques y así se hará más vulnerable. Estos serán los principales problemas siempre y cuando supongamos que los empleados de mantenimiento del software no añadan fallos ni trampas en las distintas versiones del código. Desde el punto de vista de la experiencia, se advierte que es muy aconsejable encontrar y solucionar las vulnerabilidades cuanto antes, y además si pudiese ser posible, poder preverlas antes de comenzar la etapa de desarrollo. Esto favorece desde el punto de vista 60 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA económico, ya que menor será el coste cuanto antes se hayan detectado y solucionado los problemas. Las propiedades fundamentarles que debe tener un software para ser seguro son las siguientes: -­‐ Fiabilidad: La ejecución debe estar controlada en todo momento y funcionar correctamente en cualquier condición del sistema, hasta sufriendo ataques. -­‐ Confiabilidad: Para tener el grado de confianza necesario, el software no debe tener elementos dañinos que impidan su correcto funcionamiento. Un software de confianza tendrá pocas vulnerabilidades. -­‐ Flexibilidad: El sistema debe resistir o tolerar los ataques más comunes y además hacerlo lo mejor posible con los nuevos. De los que no pueda resistir o tolerar, debe recuperarse lo mejor posible. Para un desarrollo seguro del software se debe diseñar, implementar, configurar y mantener sistemas en el que la seguridad es un atributo necesario desde el comienzo del ciclo de vida hasta el final. [PASO2012] ; [PASO2013] Existen esquemas que se dedican a la evaluación de la seguridad del software. Los hay de distintos tipos, desde los que garantizan la seguridad de los sistemas gubernamentales hasta los que van dedicados a productos y servicios con un coste y tiempo más eficientes. Algunos de todos ellos son los que mencionaremos a continuación: · FIPS-140 de Canada/US. · CESG Assisted Products Scheme (CAPS) de Reino Unido. · CESG System Evaluation (SYSn) · Fast Track Approach (FTA). · CESG Tailored Assurance Service (CTAS). · CESG Claims Tested Mark (CTT Mark). 61 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA · Common Criteria for Information Technology Security Evaluation (CC). Vamos a explicar solamente el que más repercusión tiene debido a la existencia de muchas de sus versiones. Estamos hablando del CESG. Las siglas significan Communications-Electronics Security Group Es un grupo que se encuentra dentro de la GCHQ (Government Communications Headquarters), lo que es el Cuartel General de Comunicaciones del Gobierno. CESG presta asistencia a los departamentos gubernamentales para la propia seguridad de las comunicaciones. Trabaja para el Reino Unido y es la Autoridad Nacional Táctica de allí. No fabrican equipos de seguridad pero trabaja con la industria para asegurar la disponibilidad de productos y servicios adecuados. La GCHQ les financia las investigaciones. Como hemos visto, existen diferentes tipos de programas. [COMM2014] ; [SEGU2013] ; [BUQU2013] 62 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ELEMENTO DESCRIPCIÓN FUENTE Puede ser un ser humano u otro sistema y además puede ser conocida o desconocida. Dependiendo de la fuente que sea, si es muy fuerte, da igual la medida que se tome ya que puede ser insuficiente. El ataque puede ser un acceso no autorizado, modificaciones de datos o no realización correcta del servicio. El proceso de identificación es suficiente para el problema de usuarios no autorizados. ESTÍMULO El ataque o acción de vulnerar la seguridad. ARTEFACTO Los servicios del sistema o sus datos. ENTORNO Ataque producido cuando el sistema está conectado o desconectado a la red de ordenadores. RESPUESTA Autorizar a usuarios legítimos, no autorizar a los ilegales. Registro de intento de modificación o acceso. MEDIDA Dificultades de protección ante ataques y dificultades de recuperación después de sufrir un ataque. Tabla 14. Escenario para la seguridad. 63 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 8.1. Tácticas. Las tácticas existentes para mejorar a seguridad de la arquitectura propuesta se pueden dividir en tres tipos diferentes: -­‐ Resistencia al ataque: Se dedican a intentar impedir que un elemento no autorizado pueda entrar en el sistema. Las tácticas pertenecientes a este tipo son las siguientes: · Autenticación de usuario: Asegura que un usuario es quien dice ser. Como ejemplo de esto son las contraseñas, firmas digitales, DNI electrónico… · Autorización de usuario: Derechos de acceso y modificación de un usuario autenticado. Para ello existen patrones de acceso. · Confidencialidad de datos: Protección de accesos no autorizados. La criptografía es una herramienta muy utilizada ya que cifrar datos es muy útil para acceder a ellos sólo por personal autorizado y con restricciones. · Mantenimiento de la integridad: Los datos no deben ser modificados y se deben poder recuperar cuando se quiera por parte del propietario. ·Limitación de recursos disponibles: Así se evita que un ataque pueda tener acceso a todo el sistema. · Limitación de acceso: Los cortafuegos realizan esta operación. Se limita el acceso a ciertos recursos. Hay mensajes que es posible limitarlos. 64 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Detección de ataques: Se basa en el estudio y comparación de patrones de tráfico por las líneas de comunicaciones. Así se puede reconocer si se está produciendo un ataque o no, y si es así, poder combatirlo. Los patrones están basados en ataques ya conocidos. Se filtran todos los paquetes de comunicaciones que llegan al sistema y se estudian los flags, direcciones del remitente y destinatario junto con el número de puerto. Cuando se detecta un ataque se actúa y se reporta al analista para que éste adopte las medidas necesarias si fuese requerido. -­‐ Recuperación tras un ataque: Básicamente se centra en devolver al sistema al estado anterior de sufrir el ataque. · Recuperar el estado correcto del sistema: Relacionado con las tácticas aplicables a la disponibilidad. Referido al buen funcionamiento del sistema después de un estado inconsistente, que lo más seguro es que no diese correctamente un servicio, que no estuviera disponible. · Identificar el atacante: Realizado gracias a un registro de auditoría que consiste en grabar una copia de cada transacción realizada en el sistema y por quién. Esto debe permitir devolver al sistema a un estado consistente, identificando al atacante. 65 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ESTÍMULO TÁCTICA RESPUESTA ·Autenticación de usuario ·Autorización de usuario ·Confidencialidad Resistencia al ataque de datos · Mantenimiento de la integridad · Limitación de recursos · Limitación de acceso Detección por el Ataque sistema. Resistencia o ·Detectar Detección de ataque recuperación. intrusiones en el propio sistema · Recuperar el estado correcto Recuperación de ataque del sistema · Identificar al atacante Tabla 15. Resumen de las tácticas para la seguridad. 66 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 9. Usabilidad (Usability). Es la facilidad con la que un usuario puede manejar y acceder al sistema de información con garantías de éxito. Para poder medir este atributo de calidad, se requiere establecer un método. Gracias a la usabilidad, se puede conocer mejor la claridad con la que se diseñó el sistema. El grado de usabilidad influye mucho en el grado de satisfacción del usuario, pero no debemos confundirlo ya que no es lo mismo. Además de éste, existen otros conceptos muy importantes relacionados con este atributo y son los siguientes: [PATR2014] -­‐ Eficacia: Exactitud con la que los usuarios pueden realizar la tarea que desean en un ambiente concreto. -­‐ Eficiencia: Recursos consumidos en relación a la eficacia (financieros, de tiempo y humanos). Figura 15. Conceptos de la usabilidad 67 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Como todo este tipo de conceptos, existen un gran número de definiciones diferentes dadas sobre el atributo. La que más se ha tenido en cuenta ha sido la dada por la organización llamada OSI, muy conocida en el mundo de la informática, que la define como “La extensión para la que un producto puede usarse por usuarios específicos, para lograr metas específicas con efectividad, eficacia y satisfacción en un contexto de uso específico”. Esta definición está dada en el estándar ISO 9241-11. ISO 9241 la define como calidad de trabajo de un sistema en estado normal. Otro estándar es el ISO/IEC 9126 [ISO 91] que refleja la usabilidad como un atributo de la calidad del software y lo define exactamente como “Un conjunto de atributos de software que se sostienen en el esfuerzo necesitado para el uso y en la valoración individual de tal uso, por un conjunto de usuarios declarados o implicados”. Esto hace referencia a la capacidad del sistema para ser usado fácilmente (comprensibilidad, operabilidad, facilidad de aprendizaje, calidad del interfaz…). También se considera muy importante la definición de Nielsen que indica que “La usabilidad es parte de la utilidad del sistema, la cual es parte de la aceptabilidad práctica y, finalmente, parte de la aceptabilidad del sistema”. Para esta definición ha tenido en cuenta las características del aprendizaje, eficiencia, memorización, prevención de error y satisfacción subjetiva. La complejidad de los sistemas de información van en aumento, y en el día a día podemos comprobarlo. Por esto la usabilidad es uno de los atributos más importantes y más cuidado ya que es clave en la distinción entre los fabricantes. Los sistemas de información se diseñan centrándose en el usuario, y así se establece la base. A partir de aquí se va desarrollando el sistema hasta cumplir el objetivo. Los sistemas pueden ser fáciles de aprender y usar siendo estas dos características muy importantes en el propio concepto de usabilidad. Se cree que las interfaces de usuario deben ser lo más intuitivas posible ya que, por ejemplo, los usuarios de páginas web presentan muy poca tolerancia a los sitios con un diseño complejo que complique el acceso o éste sea lento. [CLOU2013] 68 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA La usabilidad es tan simple como la percepción que tiene el usuario de la efectividad y eficiencia de la interfaz, es decir, que cumpla su propósito y haga lo que realmente tiene que hacer. No se puede definir como un atributo funcional ya que no se puede medir directamente, pero teniendo en cuenta otras medidas indirectas, se puede cuantificar. Unos ejemplos de estas medidas son el número de errores detectados o el ratio de operaciones ejecutadas respecto al número total de operaciones realizadas. El método de entrevista a los usuarios de un sistema es la mejor forma de desarrollar sistemas con una buena concepción de usabilidad. Se extraen conclusiones acerca de las entrevistas y a partir de ello se hacen las modificaciones convenientes. Para evaluar la usabilidad tenemos varios métodos diferentes, unos basados en información obtenida de los usuarios y otros basados en expertos. El coste y el tiempo son fundamentales para elegir un tipo de evaluación u otra. [MWEB2013] Vamos a estudiar a continuación, los métodos de evaluación de la usabilidad: -­‐ Métodos basados en el conocimiento: También llamados cognitivos. Requieren la creación de un modelo computacional para estimar el tiempo que le llevaría a alguien completar una tarea. Definen un modelo basado en la experiencia humana al utilizar los sistemas, describiendo el interfaz humano de los mismos. Es un método de revisión donde los especialista que evalúan construyen un prototipo inicial y a partir de ahí estudian la facilidad de aprendizaje desde el punto de vista del usuario. Así se permite evaluar el software en las etapas iniciales del desarrollo. A este método pertenecen tres tipos de información involucrados en la usabilidad de los sistemas. Son la descripción de los usuarios con su conocimiento de la experiencia, las tareas realizadas por los usuarios con el sistema y las acciones ejecutadas por los usuarios para realizar correctamente el trabajo requerido. El diseño paralelo, GOMS y el procesador humano son algunos de los métodos que pertenecen a este tipo. 69 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA · Diseño paralelo: Se crea un diseño inicial a partir del mismo conjunto de requisitos. Se realiza en grupo y cada integrante realiza su trabajo por separado y al acabar, se ponen en conjunto todas las ideas y entre todos intenta mejorar lo de cada uno para así llegar a la mejor idea posible. · GOMS: Son siglas de cuatro palabras de origen inglés. “Goal” que es el objetivo, “Operator” el operador, “Methods” los métodos y “Selection Rules” las reglas de selección. · Procesador humano: Utilizado al descomponer una tarea en componentes más pequeños y así poder analizarlos individualmente mejor. Así se detectan áreas de mejora. -­‐ Métodos de inspección formal: Estos métodos requieren tener evaluadores que examinen y realicen inspecciones sobre los principios relacionados con la usabilidad. Son utilizadas más como técnicas de evaluación. Cuantos más evaluadores haya más problemas se encontrar, en el caso que los haya, y así se solucionarán más rápido. Existe un guión de pruebas por el que se rigen los evaluadores. Los métodos de evaluación existentes serán descritos a continuación. · Evaluación heurística: Se prueban interfaces de una manera rápida y económica. Un experto examina cada elemento del interfaz de usuario para comprobar si se cumplen los principios de usabilidad establecidos. El objetivo es encontrar los problemas que pueda presentar el interfaz de usuario. Al diseñar un interfaz de usuario existen diez principios fundamentales, que más que tratarse de unas guías son unos principios creados basándose en el sentido común. Son la visibilidad del estado del sistema, la coincidencia entre el sistema y el mundo real, control por el usuario y libertad, consistencia y estándares, prevención de errores, no memorización, flexibilidad y eficiencia de uso, diseño minimalista y sin 70 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA estética, ayuda a usuarios y documentación. Nielsen realizó varios test de usabilidad a usuarios a lo largo de las distintas fases del desarrollo. U = 1 – (1-p) ^ n Donde la ‘p’ es la probabilidad de identificación de un problema y ‘n’ el número de personas que están realizando la evaluación. Esta teoría ha sido discutida y han surgido dos argumentaciones principales. Una trata sobre que la usabilidad está relacionada con un conjunto específico de usuarios, y por tanto la opinión de unos pocos no es tan representativa como se creía. La otra dice que no todos los problemas de usabilidad son iguales de detectar, por lo que la fórmula no valdría igual para todos. En resumen, se considera que siempre será mejor una muestra de unos pocos a no tener nada, pero si es posible, es mejor realizar una muestra más representativa. · Inspección pluralista: Se trata de una reunión en la que los usuarios, desarrolladores y expertos discuten cómo tratar la relación hombremáquina. Las características más importantes acerca de este método son los tipos de participantes (usuarios, desarrolladores y expertos), las pantallas impresas que aparecen en el sistema, la actuación de los participantes como usuarios del sistema, la escritura de cómo realizarían las acciones para ejecutar cada tarea por parte de los participantes y la discusión de las soluciones propuestas. · Inspección de consistencia: Utilizado cuando existen varios programadores o grupos de desarrollo en un mismo paquete. Este paquete será complejo y estará compuesto por varios productos. La finalidad es evaluar el interfaz de un nuevo producto para garantizar la consistencia de todo el paquete. Los expertos analizan el interfaz de los diferentes 71 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA desarrollos comprobando cómo implementa cada uno su función. Dependiendo de las conclusiones obtenidas, se procederá a la unificación del interfaz para todos. -­‐ Métodos basados en encuestas: Recogen datos cualitativos de los propios usuarios y los usan para evaluar la usabilidad. Los datos no dejan de ser subjetivos pero proporcionan información muy valiosa sobre lo que los usuarios quieren y esperan del sistema. La identificación de requisitos del usuario y del producto para satisfacer las necesidades del usuario será posible incluso antes del comienzo del desarrollo. Así se podrá realizar ajustándose a las necesidades del usuario con un uso fácil. El aprendizaje es clave para generar ideas nuevas de diseño. Las técnicas más usadas son: · Focus Group: Discusión manejada por un moderador que lidera el grupo de participantes utilizando preguntas sobre un tema en particular. Son reuniones grabadas en vídeo con el objetivo de poder repasar la reunión las veces que sea necesario y así elaborar un informe final lo mejor posible. · Encuestas: Menos coste económico sin necesidad de realizar pruebas. Es realizada individualmente a los usuarios con preguntas escogidas minuciosamente para que las respuestas tengan una validez en el futuro y sean de utilidad. -­‐ Métodos basado en prototipos: Utilizado en las fases iniciales del desarrollo para validar y refinar la usabilidad del sistema. 72 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA La usabilidad es tremendamente importante en la fase de diseño del software, y por ello se evalúa en la Arquitectura Software. Los requisitos deberían establecerse antes de empezar el desarrollo ya que a posteriori es muy difícil cambiar el interfaz, ya que se incurren en gastos más altos de lo normal además de lo costoso que es en términos ingenieriles. En resumen, cambiar el interfaz requeriría volver a definir la arquitectura. Hay que tener en cuenta de qué tipo van a ser los usuarios, la finalidad del proyecto y cómo van a utilizar el sistema los propios usuarios. A tener en cuenta también si los usuarios van a necesitar una formación previa a la utilización del sistema. [SOFT2006] La usabilidad se divide en las siguientes tareas: -­‐ Aprendizaje de las características del sistema: Si el usuario no está familiarizado con un sistema en concreto o con algo relacionado con él, el propio sistema debería proporcionar los medios necesarios para hacer el aprendizaje lo más fácil posible. -­‐ Uso del sistema lo más eficiente posible: El sistema también debe ofrecer facilidades para conseguir que el uso sea lo más eficiente posible. -­‐ Minimización del impacto de errores: Ofrecer medios para que el impacto de los errores sea el mínimo posible y recuperarlos cuando se necesite. -­‐ Adaptación del sistema a las necesidades del usuario: Permitir que el usuario pueda adaptar el sistema para facilitar la realización de las tareas. -­‐ Incremento de la confianza y satisfacción: Ofrecer medidas oportunas para que el usuario tenga la seguridad de que las acciones que realiza se ejecutan correctamente. 73 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA La usabilidad es un aspecto muy importante a tener en cuenta en el diseño de los sistemas, y por tanto, está incluido entre los atributos a valorar en la Arquitectura Software. Se puede ahorrar tiempo y dinero y ofrecer garantías de éxito si valoramos este atributo en el momento correcto. Se ha evolucionado últimamente en el conocimiento de este atributo de calidad y en cuanto a su relación con la Arquitectura Software se ha sacado en claro que la detección temprana de los errores de usabilidad implicará un menor coste a la hora de corregirlos. Al tener la usabilidad tanta relación con la estructura del sistema, la idea que acabamos de comentar afectará directamente a la propia estructura del sistema. Como en todos los atributos de calidad de los que hemos hablado anteriormente, la usabilidad tiene un escenario posible que estudiaremos a continuación en una tabla detallada en la que se especificará todo lo necesario para realizar una evaluación correcta de la usabilidad. 74 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ELEMENTO DESCRIPCIÓN FUENTE Para no repetir lo que se dice en cada escenario, la única fuente de estímulo es el propio usuario. ESTÍMULO Utilización concreta que realice el usuario del sistema. ARTEFACTO El sistema. ENTORNO Las acciones del usuario relacionadas con la usabilidad siempre se realizarán en tiempo de ejecución o en la configuración del sistema. RESPUESTA El sistema debe anticiparse a las necesidades del usuario. MEDIDA La respuesta se puede medir como tiempo para realizar la tarea, número de errores, número de problemas resueltos, satisfacción del usuario, aumento del conocimiento del usuario, ratio de operaciones correctas frente al total de operaciones, tiempo y datos perdidos al producirse un error… Tabla 16. Escenario para la usabilidad. 75 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 9.1. Tácticas. Existen dos tipos de usuarios concretos a los que puede afectar la usabilidad. Se trata de los desarrolladores o programadores y de los usuarios finales. Se debe tener en cuenta el colectivo de programadores, pero concretamente, para la descripción de las tácticas aplicables a la usabilidad es mejor centrarse en el estudio de los usuarios finales. Una de las posibles evaluaciones que veremos puede ser la facilidad de utilización de los comandos que debe teclear el usuario en pantalla y cómo soportan los errores en cuanto a la información que ofrecen al usuario sobre ellos, siendo en forma de avisos de error o del propio error y de cómo poder resolverlo. Las facilidades que soporta para que el usuario pueda seleccionar los comandos más utilizados y agruparlos bajo un menú es un claro ejemplo de las posibles opciones que existen en este atributo y que son de gran utilidad. El tiempo que tarda en reaccionar o responder el sistema ante la entrada de un nuevo usuario es otro factor que influye en la percepción del grado de usabilidad. Las distintas funciones del sistema que tienen interacción con el usuario y que tienen como requisito un determinado tiempo de respuesta ante una acción deben ser enumeradas por el arquitecto. En otras situaciones, el propio sistema toma la iniciativa y avisa al usuario de un evento o acción que deba realizar. Las tácticas deben identificar los modelos utilizados para predecir lo que va a ocurrir o para prever las intenciones del usuario y así poder anticiparse. Agrupar estos modelos sería lo ideal para hacer más fácil su evaluación y modificación. Los tres tipos de modelos a tener en cuenta por el arquitecto son: 76 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Modelo de tareas: Determinará el contexto, de forma que el sistema pueda tener una idea de las acciones que va a desarrollar el usuario y así le pueda suministrar diversos tipos de asistencia. Un buen ejemplo de esto sería el ajuste de las opciones de los menús que pueda ver. ESTÍMULO TÁCTICA RESPUESTA ·Interfaz de usuario separada. ·Soporte a las iniciativas del usuario; Petición del usuario Cancelación, Información y asistencia deshacer operaciones y añadir dadas al usuario opciones. ·Soporte a iniciativas del sistema; Modelos. Tabla 17. Resumen de las tácticas para la usabilidad. -­‐ Modelo de usuario: Determina el conocimiento que tiene el usuario del sistema y su comportamiento en cuanto a tiempo esperado de respuesta u otros, dependiendo del tipo de usuarios a los que va destinado, así como el tipo de trabajo que van a desarrollar al utilizar dicho sistema. -­‐ Modelo de sistema: Recoge el comportamiento esperado del sistema, lo que permitirá ofrecer al usuario la información necesaria. 77 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 78 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 10. Verificabilidad (Verificability). Este atributo permite evaluar la arquitectura para comprobar hasta qué nivel podemos comprobar el sistema o un componente perteneciente al mismo. No es una propiedad propiamente dicha del sistema en sí, si no que depende de las pruebas que deba soportar, los objetivos, los métodos utilizados y los recursos empleados para realizar las pruebas. Por ello no se puede medir directamente. Cuanto menor sea el resultado de la medida de verificabilidad, más esfuerzo hay que dedicar a la hora de realizar las pruebas. Este esfuerzo viene dado por factores como la concreción de los requisitos software, la complejidad del sistema, la documentación existente y la organización de las pruebas. Algunos conceptos interesantes relacionados con el atributo de verificabilidad son los siguientes: -­‐ Contingencia: Indica el estado del software. Los resultados de las pruebas no pueden ser sabidos con exactitud antes de ser realizadas. Estos resultados dependen de en qué momento se hagan, de las condiciones del entorno y del funcionamiento de los demás componentes relacionados. -­‐ Factibilidad: Informa que las pruebas deben ser reales para garantizar un correcto funcionamiento del software en el entorno y objetivo con el que se ha diseñado, sin fallos. Las pruebas deben ir dedicadas concretamente al sistema o a un elemento particular del mismo. Hay que tener en cuenta que existen componentes que trabajan en conjunto con otros, entonces se hace muy difícil realizar una prueba válida del componente en cuestión, ya que como realmente se ve si funciona bien es realizando la prueba individualmente. -­‐ Refutabilidad: Las pruebas deben realizarse para demostrar que el software es erróneo. Aunque se demuestre que existe un pequeño fallo, eso no demuestra que el sistema no realice el trabajo que se le pide correctamente. Esto se debe a que lo que realmente se quiere es que funcione bien y haga correctamente el objetivo que se le 79 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA pide. Si lo hace, aunque exista algún fallo, no se puede considerar que el sistema no sea bueno. Dadas estas características, vamos a ver que se debe cumplir para que un sistema sea verificable: · El sistema y todos sus componentes deben de estar debidamente documentados y con los requisitos perfectamente definidos y detallados, y poder medirse o comprobar su funcionamiento. Esto es necesario para poder realizarse las pruebas y que su coste no sea muy elevado. Los requisitos son consistentes, completos sin ambigüedades, cuantificados y verificables, por supuesto. · El estado de cada componente debe ser controlable en todo momento para poder asegurar que el resultado de las pruebas es correcto. · Observar los resultados y el funcionamiento de las pruebas del componente es fundamental para poder ver los resultados intermedios que se van dando y realizar una valoración. · Como hemos mencionado anteriormente, es importante poder realizar las pruebas a cada componente por separado. Realizarlas individualmente es la única manera de asegurar el correcto funcionamiento de un componente en concreto. · El objetivo de cada componente se debe especificar detalladamente. 80 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA ELEMENTO DESCRIPCIÓN FUENTE Prueba realizada por probadores, desarrolladores (en el caso de pruebas de diseño) o por el propio cliente. ESTÍMULO Hito alcanzado en el desarrollo del proyecto (final de diseño, análisis, codificación…). ARTEFACTO Componente a probar, pudiendo ser también el sistema completo. ENTORNO Pruebas realizadas en tiempo de diseño, de desarrollo, de integración o de producción. RESPUESTA Sistema controlado con realización y resultado de pruebas. MEDIDA Es el porcentaje de líneas de código ejecutadas en una prueba determinada. También la probabilidad de encontrar nuevos errores en el software. Tabla 18. Escenario para la verificabilidad. 81 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 10.1. Tácticas. Las tácticas correspondientes a este atributo de calidad están centradas en permitir realizar las pruebas necesarias que debe pasar el sistema de la manera más sencilla posible. No es de los atributos principales pero sí que hay que tenerlo en cuenta ya que su coste económico es muy elevado y conviene realizar cualquier táctica posible para poder disminuirlo. ESTÍMULO TÁCTICA RESPUESTA ·- Gestión de entrada/salida · Registro. Incremento del tamaño ·Rutas. del sistema Fallos detectados · Interfaz · Monitorización Tabla 19. Resumen de las tácticas para la verificabilidad. El objetivo de estas pruebas es descubrir fallos en el software. Esto requerirá software adicional que permita alimentar con datos a los componentes a probar y recoger los resultados de las pruebas para su correcta evaluación. Las tácticas aplicables son las siguientes: -­‐ Registro: También llamado reproducción. Es la recogida y grabación de los datos obtenidos en ejecución real por el sistema. Posteriormente podrán ser utilizados como datos de entrada en las pruebas. También se grabarán los resultados 82 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA obtenidos por un componente antes y después de realizar un cambio. Así se podrán realizar comparaciones y valoraciones de los resultados obtenidos. -­‐ Interfaz: Separar la interfaz de la implementación permitirá sustituir los componentes de procesamiento sin problemas y poder realizar pruebas sin interrumpir al resto de usuarios, ya que la interfaz seguirá siendo la misma. A veces hasta se puede eliminar un componente y el sistema seguir funcionando correctamente, aunque algún usuario se vería afectado. -­‐ Rutas: El acceso a través de interfaces o rutas permite particularizar las pruebas y cambiar los datos sin problema. Estas rutas deben quedar separadas de la operación normal y no ser accesibles, a no ser que se vayan a realizar pruebas. -­‐ Monitores: Utilizados para el seguimiento del comportamiento del componente bajo estudio. Hemos finalizado con la explicación teórica acerca de los inicios de la arquitectura software y sus características y con el detallado estudio de cada atributo de calidad fundamental en un sistema. A continuación introduciremos una breve explicación de los modelos existentes para poder hacer una aplicación práctica de lo ya explicado y ver cómo podemos mejorar un sistema real teniendo en cuenta un atributo de calidad en concreto, también aplicable a todos los demás. 83 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 84 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 11. Modelo COCOMO. Es un acrónimo del inglés “Constructive Cost Model” y fue diseñado por Barry W. Boehm hace aproximadamente 40 años. Es un modelo matemático de base empírica utilizado para estimación de costes de software. Está formado por tres submodelos, los cuales tienen cada uno su propio nivel de detalle y aproximación a medida que avanza el proceso de desarrollar el software. Este desarrollo se divide en tres partes: básico, intermedio y detallado. Este modelo pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas orientado al producto final, midiendo el tamaño del proyecto en líneas de código, sobre todo. [COCO2014] Los inconvenientes que tiene este modelo son los siguientes: · Resultados no proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas. · Si indicamos mal el porcentaje de líneas de comentarios en el código, el resultado se puede desviar de la realidad. · Es un modelo subjetivo. Dependiendo del analista que utilice el método, se basará en unas estimaciones o parámetros diferentes. · La productividad no se mide. · La medición no es válida para la orientación a objetos. · Es un modelo de uso ligeramente complicado. 85 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 11.1. Tipos de modelos. Los tres modelos de los que hemos hablado anteriormente utilizan las siguientes ecuaciones: E = a(Kl)b * m(X) , en persona-mes Tdev = c(E)d , en meses P = E/Tdev , en personas Donde tenemos que: E es el esfuerzo requerido por el proyecto, en persona-mes. Tdev es el tiempo requerido por el proyecto, en meses. P es el número de personas requerido por el proyecto. a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo. Kl es la cantidad de líneas de código, en miles. m(X) Es un multiplicador que depende de 15 atributos. En los modelos, existen modos que representan el tipo de proyecto, y son el modo orgánico (se desarrolla software por un grupo de pequeños programadores y el tamaño de código es pequeño), modo semilibre (el grupo de trabajo está formado por gente experimentada y no tan experimentada) y el modo rígido (un proyecto con restricciones debido a su dificultad). 86 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Ahora comencemos a hablar de los modelos existentes. En primer lugar está el modelo básico. · Modelo básico: Utilizado para obtener una primera aproximación rápida del esfuerzo realizado. Se utiliza una tabla con valores para calcular distintos aspectos de los costes: MODO A B C D Orgánico 2,4 1,05 2,5 0,38 Semilibre 3 1,12 2,5 0,35 Rígido 3,6 1,2 2,5 0,32 Valores utilizados para: Personas necesarias por mes para llevar adelante el proyecto : (MM) = a*(Klb) Tiempo de desarrollo del proyecto : (TDEV) = c*(MMd) Personas necesarias para realizar el proyecto : (CosteH) = MM/TDEV Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas. ·Modelo intermedio: Se trata del modelo básico con la adición de quince modificaciones opcionales para poder aplicarlas a un entorno de trabajo, así incrementando la precisión de la estimación. La parte que se modifica respecto al modelo básico es: 87 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA MODO A B Orgánico 3,2 1,05 Semilibre 3 1,12 Rígido 2,8 1,2 A este modelo se le pueden aplicar los atributos que se decidan. Hablaremos de ellos al terminar de detallar los tipos de modelos existentes. · Modelo detallado: Tiene dos mejoras importantes. Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Existen aspectos como la experiencia y la utilización que tienen mayor influencia en una fase que en otra y además varían de una etapa a otra. También establece una jerarquía de tres niveles de productos. Los aspectos que representan gran variación a bajo nivel (nivel de módulo) , los que representan pocas variaciones (nivel de subsistema) y los demás (nivel de sistema). Los atributos de los que hemos hablado en el modelo intermedio se cuantifican para un entorno del proyecto. La escala de los atributos se divide en: MUY BAJO – BAJO – NOMINAL – ALTO – MUY ALTO – EXTREMADAMENTE ALTO Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula. Por ejemplo, ALTO = x1000. Existen cuatro tipos de atributos, y tienen un significado diferente dependiendo del tipo. 88 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA · Software: RELY (garantía de funcionamiento requerida), DATA (tamaño de la base de datos en relación al tamaño del programa entero) y CPLX (complejidad del producto). · Hardware: TIME (limitaciones en el porcentaje de uso de la CPU), STOR (limitaciones en el porcentaje del uso de la memoria), VIRT (volatilidad de la máquina virtual) y TURN (tiempo de respuesta requerido). ·Personal: ACAP (calificación de los analistas), AEXP (experiencia del personal en aplicaciones), PCAP (calificación de los programadores), VEXP (experiencia del personal en máquina virtual) y LEXP (experiencia en el lenguaje de programación a usar). ·Proyecto: MODP (uso de prácticas modernas de programación), TOOL (uso de herramientas de desarrollo de software) y SCED (limitaciones en el cumplimiento de la planificación. El modelo COCOMO ha evolucionado y tiene distinas versiones. En la primera versión se calcula el esfuerzo y el coste del desarrollo en función del tamaño estimado del programa. Se utiliza para una aproximación rápida al ciclo de vida. En el modelo COCOMO II se permite estimar el coste, esfuerzo y tiempo cuando se planifica una nueva actividad de desarrollo software. Tiene tres submodelos, los cuales son el modelo de composición de aplicaciones, de diseño anticipado y de post-arquitectura. Analizando este modelo, encontramos unas ventajas y unas desventajas que comentamos a continuación: · Ventajas: Es un modelo transparente, se puede ver como trabaja con otros modelos. Los manejadores de costo ayudan al estimador a comprender el impacto de diferentes factores que afectan en el coste del proyecto. · Inconvenientes: La adaptación del modelo a las necesidades de la organización utilizando datos históricos es muy importante. Los datos pueden estar no disponibles. 89 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 90 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 12. Modelo COPLIMO. El modelo COPLIMO es un acrónimo del inglés “Constructive Product Line Investment Model” e investiga el efecto de los costes de calidad del software en el ROI. Existen dos fuentes de despliegue del modelo: [COPL2014] · RCWR: “The Relative Cost of Writing for Reuse” indica el coste adicional de escribir software a la hora de encontrar la mejor relación entre la efectividad y el coste reutilizada a través de la nueva aplicación de la familia de líneas de producto con el coste de escribir el software para usarlo en una aplicación. · RCR: “The Relative cost of Reuse” es el coste de reutilizar software en una nueva aplicación de la familia de líneas de producto relativo al desarrollo de software recién construido para la aplicación. Para las dos fuentes existen tablas con distintos valores, los cuales se utilizarán en un caso o en otro. Los multiplicadores de esfuerzo obtienen un valor diferente dependiendo de si es bajo o alto, teniendo en cuenta también valores intermedios. Es una variación del modelo COCOMO utilizado para las líneas de producción, pero la utilización de valores en tablas es casi similar. En la reutilización de activos de la organización común, la línea de productos software ofrece oportunidades de negocio importantes para reducir el coste unitario de los productos similares, la mejora de la productividad, reducir el tiempo de comercializar y mejorar la satisfacción de los clientes. Mediante la adopción de prácticas efectivas de líneas de producto, el ROI (Retorno de la Inversión) se vuelve más crítico en el proceso de toma de decisiones. La mayoría de estimaciones de coste y el ROI limitan su labor a los costes y ahorros del desarrollo de software. 91 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Descriptors None Across Across Across Across Project Program Product Multiple line Product line Rating low Nominal High Very High Extra high 0,95 1 1,07 1,15 1,24 levels Effort multiplier 92 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 13. Desarrollo del MODELO. Ahora comienza el desarrollo del modelo teniendo en cuenta los aspectos tecnológicos y los económicos, principalmente, ya que existen otros factores también pero menos importantes a la hora del desarrollo del modelo. Antes de comenzar a describir la aplicación por partes, hay que tener claro qué es lo que queremos aportar al cliente. Para ello, primero debemos estudiar en profundidad los atributos de calidad y ver qué parámetros son los mejores para mejorar dichos atributos. La adición, modificación o eliminación de hardware/software es algo fundamental en un sistema por lo que es útil para cualquiera de los atributos. El resto de parámetros dependen de los atributos, y se han escogido aquellos en los que, al introducirlos o modificarlos, tienen mayor impacto en los atributos de calidad. Esta aplicación está creada para ser utilizada por cualquier usuario, desde los que tienen un gran conocimiento sobre la arquitectura software hasta para los que se inician en la materia. Por ello, dentro de la propia aplicación, hay información detallada sobre todos los términos utilizados en ella. Tiene un uso el cual es muy útil para relacionar los conceptos vistos a lo largo del proyecto y el aspecto económico. A continuación se explicará cada parte de la aplicación y el porqué de los datos que se manejan. Las empresas podrán utilizar esta aplicación para introducir los cambios que van a querer hacer en los atributos de calidad de su sistema interno, indicando que parámetro han elegido mejorar de cada atributo y las consecuencias que tiene en el resto de atributos y en el coste relacionado. Inicialmente encontramos una ventana en la que más que nada se muestra información al usuario acerca de cómo utilizar la aplicación y acerca de los atributos de calidad, ya que gracias a esto se puede tener más claro los cambios que se quieren realizar en un sistema. 93 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 16. Ventana principal Existe una ventana emergente dedicada a cada uno de los atributos de calidad para conocer más acerca de ellos. Esta es la parte mencionada anteriormente que puede ayudar a cualquier empresa a saber qué le conviene modificar según sus intereses. Es la información más relevante acerca de los atributos de calidad descrita a lo largo de este documento. Puesto que ha sido determinante para conocer más acerca de ellos, se ha creído necesario que todos los avances teóricos sean mostrados en la aplicación para que los usuarios que la vayan a utilizar puedan acceder a los mismos conocimientos. La disposición de la ventana de información de cada uno de los atributos de calidad es la siguiente para cada uno de ellos: 94 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 17. Disponibilidad. Figura 18. Modificabilidad. 95 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 19. Rendimiento. Figura 20. Seguridad. 96 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 21. Usabilidad Figura 22. Verificabilidad. 97 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Existe una opción que es el manual de instrucciones de utilización del modelo. Aquí se describe cómo se deben introducir los datos en el propio modelo y cómo deben ser relacionados entre sí para obtener los datos correctos y en general, todas las opciones que están disponibles. La guía de utilización del modelo debe ser la siguiente para un correcto uso de la misma: -­‐ Acceder a las ventanas de información mostradas anteriormente para conocer más acerca de los atributos de calidad. Así se tendrá más claro qué es lo que se quiere cambiar en el sistema. -­‐ Acceder a la ventana donde se muestra la relación entre los atributos y la definición de lo que hace el parámetro en cuestión. Los parámetros vienen explicados en este documento más adelante. Con este punto y el anterior se tiene la información teórica necesaria para realizar los cambios. -­‐ Comenzar a utilizar el modelo para conocer cómo van a afectar los cambios entre sí a los atributos dependiendo del porcentaje de mejora que se desee. Dependiendo de qué se quiera mejorar en el sistema, se querrá mejorar más o menos un atributo u otro. -­‐ En el modelo, seguiremos los mismos pasos siempre para que quede toda la información ordenada y clara para el usuario. Primero introducimos el primer cambio, es decir, el primer parámetro que hemos decidido mejorar para el atributo de calidad deseado. Introducimos sus costes, divididos por costes hardware, de diseño, de desarrollo y de instalación y obtenemos el coste total del atributo. Guardamos siempre que términos de editar un atributo. Hacemos el mismo proceso con todos los atributos y cuando terminemos, procedemos a la generación de un informe inicial. En este punto comenzaremos a relacionar los atributos de calidad, uno a uno, con su correspondiente porcentaje de mejora. Lo hacemos con todos y a continuación, para finalizar, calculamos el coste total y así generamos el informe final con el coste total y las mejoras totales por cada atributo. 98 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Al tener claras las ideas acerca de qué cambios se van a realizar, la empresa en cuestión deberá pedir por su cuenta presupuestos acerca de lo que le va a costar realizar los cambios. Estos datos serán introducidos posteriormente en el modelo. También deberán estipular cuánto dinero están dispuestos a invertir en la creación del proyecto. Figura 23. Manual de uso. En esta ventana creada a partir de este botón, obtenemos toda la información relevante acerca de todos los parámetros de los atributos de calidad. En primer lugar vemos como, tanto los atributos como los parámetros, están dispuestos en dos menús desplegables para un manejo más fácil para el usuario. Por si la visualización de las imágenes no fuese correcta del todo, son: para la disponibilidad (redundancia activa, redundancia pasiva, sustitución, añadir/modificar componentes hardware/software), para la modificabilidad (añadir/modificar componentes hardware/software), para el rendimiento (velocidad del CPU/memoria/disco/comunicaciones, capacidad de discos, cambiar el SO, modificar componentes software), para la seguridad (configurar firewall, redundancia activa, redundancia pasiva, añadir/modificar componentes hardware/software), para la usabilidad 99 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA (añadir/modificar componentes hardware/software) y para la verificabilidad (monitor de funcionamiento, pruebas en tiempo de ejecución, manejo de fallos). Figura 24. Relación entre atributos. A continuación vamos a comentar brevemente cada uno de los parámetros de los atributos. De todas maneras, es una pequeña introducción ya que a partir de la página 114 habrá una explicación más extensa y detallada de qué significa cada parámetro y las posibilidades de cada uno de ellos. 100 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Parámetros de la disponibilidad: Figura 25. Parámetros disponibilidad. La redundancia activa utilizada de manera que teniendo varios componentes, si uno falla, cualquiera de los otros puede realizar el trabajo que debía hacer el componente caído. Los componentes estarán activos en todo momento. La redundancia pasiva realiza lo mismo que la activa con la única diferencia que sólo un componente estará activo en un momento dado y por ello, debe existir un elemento que indique qué componente debe ponerse a funcionar en lugar del caído. La sustitución consiste simplemente en el cambio de un elemento por otro en el sistema que ayude a aumentar la disponibilidad. Añadir o modificar hardware o software es para todos los atributos lo mismo, es cambiar componentes en el hardware o en el software para mejorar el atributo en cuestión. 101 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Parámetros de la modificabilidad: Figura 26. Parámetros modificabilidad. Parámetros del rendimiento: Figura 27. Parámetros rendimiento. 102 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Las velocidades referidas al rendimiento simplemente se quieren mejorar para una ejecución más rápida del CPU, los discos, la memoria o las comunicaciones. Cambiar el sistema operativo debido a que el nuevo a instalar tenga mejores prestaciones que el anterior. Aumentar la capacidad de los discos ya que cuanta más memoria tenga más rápido irá. Es un principio claro en al informática, cuanto más sobrecargado está el sistema, más lento irá. Parámetros de la seguridad: Figura 28. Parámetros seguridad. Configurar un cortafuegos que evite cualquier elemento que pueda dañar el sistema, como pueden ser los virus. Es un método fácil de implantar y con efectividad. 103 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Parámetros de la usabilidad: Figura 29. Parámetros usabilidad. Esto nos permite en cualquier momento disponer de la información que se necesite a la hora de elegir qué parámetro queremos elegir. Cuando se tenga claro, se eligen y accionando el botón “OK” nos aparece en el apartado explicación, de qué se trata la mejora de ese parámetro y en el siguiente apartado, los atributos que se ven afectados al efectuar dicho cambio. Estas explicaciones sobre qué significa cada parámetro vienen dadas al final de este capítulo ya que se entra en detalle para que queden claras. 104 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Parámetros de la verificabilidad: Figura 30. Parámetros verificabilidad. Monitor de funcionamiento para comprobar cómo funciona el sistema y así ver si está todo correcto o se deberían realizar cambios. Realizar pruebas en tiempo real como comprobación del funcionamiento del sistema. Manejar los fallos y los errores para arreglarlos y conseguir un sistema lo más cercano a la perfección. 105 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 31. Relaciones. Comenzando con la explicación de cómo utilizar el modelo, vemos cómo es la disposición de la ventana ya que su uso se puede dividir en tres partes bien diferenciadas (costes, relación entre atributos y viabilidad) antes de obtener el resultado final deseado formado por distintos datos. La primera parte es la introducción, por parte de la empresa, de los parámetros de los atributos que quiere mejorar con su porcentaje de mejora deseado, la versión en la que lo desea hacer y los costes que les va a suponer en hardware, diseño, desarrollo e implantación esa mejora. Los atributos, parámetros y versiones se encuentran en menús desplegables para un uso más fácil y rápido del modelo. [PEQU2014] 106 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Estos datos se introducen donde la señal roja en la siguiente imagen: Figura 32. Modelo. Introducimos los datos como en el ejemplo mostrado a continuación. Elegimos en los menús desplegables la versión que se desee (será la misma para todos los atributos), el atributo con su parámetro a mejorar y rellenamos las cajas de texto para el porcentaje de mejora deseado y los costes imputados del cambio. Una vez hecho para un atributo, pinchamos en “Calcular” (indicado en rojo en la siguiente imagen) para que calcule el coste total en ese atributo. 107 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 33. Cálculos. En cuanto a los costes, los cálculos realizados para cualquier atributo quedan reflejados en la parte derecha de la aplicación. El porcentaje de mejora queda almacenado temporalmente en la parte inferior del modelo ya que se verá modificado más adelante al realizar otros cálculos tan importantes como necesarios. 34. Almacenamientos. 108 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Cada vez que introducimos los datos de un cambio, los guardamos (botón “Guardar”) para más adelante poder recordar cuál fue la información que se introdujo para un atributo en particular. En el botón “Consultar” es dónde se puede ver esta información. Figura 35. Consultas. También, además de disponer de la información en manera de consulta individual, se puede generar un informe para tener una vista resumen de todos los datos introducidos cuando hayamos especificado todos los cambios. 109 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 36. Informes. Una vez realizado este proceso para todos los atributos, calculamos el coste total de todos los cambios realizados para el sistema. Es una variable que será fundamental para calcular posteriormente la viabilidad del proyecto. Figura 37. Cálculo de costes. 110 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 38. Viabilidad proyecto. Una parte muy útil de este modelo es esta última que vamos a mencionar. Los cambios en un atributo afectan al resto. Entonces esto se verá reflejado en el porcentaje final de mejora de cada atributo. Individualmente, cada atributo mejora en un porcentaje elegido previamente por el cliente, pero al modificar otros atributos, ese porcentaje inicial del que hablamos podrá aumentar o disminuir dependiendo de si los cambios en el resto de atributos le afectan positiva o negativamente. Esto se realiza en la zona indicada a continuación: 111 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 39. Relacionar parámetros. Figura 40. Modificación porcentajes. 112 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Por último, la última parte del modelo. Trata de que la empresa introduzca el presupuesto del que dispone para realizar este proyecto y, comparándolo con los costes totales de los cambios, se decide si el proyecto es viable o no para realizarlo. Pueden salir tres tipos de resultados dependiendo de la comparación entre cifras. Puede ser que el proyecto no sea viable, que si lo sea o que lo sea pero indicando que para el presupuesto del que se dispone supone un esfuerzo económico importante. Figura 41. Presupuesto. En el apartado económico es fácil de explicar su funcionamiento. Simplemente se almacenan los costes de cada uno de los atributos para, al finalizar, calcularlos en su conjunto y realizar la comparación con la inversión para ver si el proyecto es viable o no. 113 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 42. Viabilidad. Centrándonos en el contenido interno de la aplicación, es decir, en el porqué de todos los datos que forman el modelo, vamos a explicar qué significa cada uno de ellos. Para ello, vamos a ir por partes centrándonos inicialmente en cada uno de los parámetros de los atributos para explicar qué significan y más tarde el porqué de los cálculos realizados. Los parámetros de adición o modificación de hardware o software no hace falta explicarlo en profundidad ya que se trata simplemente en, como indica su propia descripción, en añadir, cambiar o eliminar partes del hardware o del software para mejorar el atributo al que pertenezcan. El resto son: -Redundancia activa/pasiva: se trata de repetir datos o hardware de carácter crítico para asegurar que no se pierdan en caso de fallo. Es una solución ante los problemas de protección y confiabilidad. Se realiza el mismo proceso en más de una estación, ya que si en algún momento dejara de funcionar o se colapsara el sistema, otro ocuparía su lugar inmediatamente para realizar las tareas del anterior y así no perder disponibilidad del sistema. Una base de datos replicada es un claro ejemplo de sistema distribuido redundante. Los dispositivos redundantes de un servidor son los discos duros, tarjetas de red y fuentes de alimentación. Los discos 114 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA RAID (Redundant Array of Independent Disk) son un conjunto de unidades de disco que están dispuestos como si fuesen uno, así los datos se dividen entre dos o más unidades. Esto incrementa el rendimiento pero sobre todo la disponibilidad de un sistema protegiéndose del fallo de un disco. Las tarjetas de red comunican al servidor con el cliente y para garantizar que no haya fallos en esta comunicación, los servidores suelen utilizar dos. Además de conseguir que no se note en caso de fallo, se utiliza para la técnica conocida como “bonding”, en la que las dos tarjetas suman sus capacidades y se utilizan como una sola. Siguiendo con los servidores, hoy en día traen al menos dos fuentes de alimentación proporcionando electricidad a la computadora. Las fuentes conectadas a diferentes sistemas eléctricos garantizan el suministro en caso de fallo afectando también a conmutadores, enrutadores y demás elementos. Centrándonos en los discos, que son la medida más utilizada en redundancia, vamos a ver gráficamente algunos discos RAID. La diferencia entre activa y pasiva es únicamente que los elementos esten activos todo el tiempo o solamente cuando se necesiten. [SRED2014] 115 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 43. Discos raid -­‐ Sustitución: Se trata de cambiar elementos que mejoren la disponibilidad del sistema, realizándolo en momentos que menos se note el tiempo de pérdida de disponibilidad que va a suponer el cambio. -­‐ Velocidad CPU, memoria, disco y comunicaciones: Mejorando la velocidad de procesamiento en estos elementos del sistema se mejora el rendimiento del sistema, ya que ejecutará las intrucciones a mayor velocidad. [VCPU2014] -­‐ Capacidad de discos: Aumentando la capacidad de los mismos se podrán almacenar más datos por lo que la memoria tardará más en llenarse y al estar el sistema más descargado seguirá trabajando a alta velocidad. -­‐ Cambiar SO: El realizar un cambio de sistema operativo puede mejorar un sistema ya que puede tener unas prestaciones mejores que el anterior. Se trabaja continuamente en mejorar todo lo posible para llegar a tener un sistema que funcione perfectamente y eso lleva a realizar actualizaciones con mejoras. 116 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Configurar un cortafuegos: También llamado “firewall”, diseñado para bloquear el acceso no autorizado al sistema. Permite, limita, cifra y descifra el tráfico de información entre el propio sistema y el resto. Protege el ordenador de ser dañado y es un elemento que ayuda mucho a la seguridad del sistema, pero como complemento y no como única solución. [CORT2014] -­‐ Monitorización: Utilizado para ver cómo funciona un sistema en cada uno de los momentos que se necesite y así poder comprobar cómo se comporta ante una situación en concreto. El resultado serán los datos obtenidos de esa monitorización y así verificar dónde el sistema funciona mejor y dónde peor. -­‐ Pruebas en tiempo de ejecución: Mientras el sistema está trabajando se realizan pruebas para ver cómo se comporta el mismo y así ver qué funciona mejor o peor. -­‐ Manejo de fallos: Se controlan los errores ocasionados durante la ejecución de programas informáticos. Así al ver los fallos que ocurren se pueden solucionar ya que para encontrar una solución primero hay que saber qué hay que solucionar. En cuanto a los porcentajes de los factores de mejora de los atributos, vemos como a la hora de mejorar un atributo afecta tanto positiva como negativamente a otros. La variaciones en los porcentajes es baja ya que está tratado sobre 100% que es la perfección, y la modificación afecta a un atributo en concreto para el que se ha pensado. Bien es cierto que tiene incidencia en otros atributos pero la variación no es muy alta. Dependiendo del porcentaje de mejora elegido para un atributo, variará más o menos el aumento o disminución de los atributos involucrados. Bajo experiencia personal cambiando discos duros a amigos o añadiendo memorias he elegido las variaciones de las que hablo. Seguramente se pueda precisar más por ello esta aplicación ofrece la posibilidad de ser mejorada en cualquier momento actualizándose cuando sea necesario. En cuanto a las relaciones porqué son así se ha decidido debido a la numerosa información obtenida acerca de la arquitectura software. En libros como el de Clements y Bass se explican conceptos sobre ello con claridad y juntando esa información más la 117 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA experiencia personal tanto propia como de informáticos conocidos o que han expuesto sus experiencias en la red, se acierta a saber qué relaciones existen entre los atributos. Esto también es actualizable como lo anterior ya que con todos los avances que existen en la tecnología pueden variar las relaciones y el porcentaje de incidencia en ellos. La propia experiencia es la que ha determinado que se escojan dichos valores. El ejemplo práctico que se ha llevado a cabo, además de opiniones de personas que han trabajado con ello, ha sido la mejora del rendimiento aumentando la velocidad de un disco. El disco interrumpía cada 512 bytes siendo la duración de la interrupción de 20 milisegundos. Se tomaron los datos del resto del sistema para comprobarlos posteriormente a ver cómo cambiaban. Hecho esto, con las reglas de tres oportunas, vimos que se producían mejoras en otros componentes del sistema pero de manera muy leve, en bajos porcentajes. Por este tipo de experiencias más opiniones de gente con experiencia en ello se han decidido realizar este tipo de modificaciones tan leves. Capítulo 13.1. Casos reales del modelo. Se van a realizar simulaciones del modelo para ver los tres tipos de situaciones que se pueden dar: 1º Situación: Una empresa quiere cambiar su sistema para que tenga unas prestaciones más altas. Quieren mejorar la modalidad WEB por lo que, haciendo un estudio de qué les viene mejor, han decidido mejorar la disponibilidad, modificabilidad, rendimiento y seguridad. Para esta mejorar, han decidido que no les interesa gastar ni en usabilidad ni en verificabilidad ya que por el momento les funciona bien según sus propios intereses. Sobre todo, quieren mejorar el rendimiento del sistema para que se ejecute más rápido, además de ofrecer garantías de seguridad. Al querer centrarse en la seguridad, se realizará una mejora en redundancia activa ya que, además de mejorar la disponibilidad, también tiene un impacto importante en la seguridad. Modificando el hardware se pretenden obtener 118 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA pequeñas mejoras en la modificabilidad y así el sistema tenga mejor tolerancia a los cambios. Por ello se han elegido los porcentajes de mejora que se mostrarán a continuación. Los costes van en relación al porcentaje de mejora elegido. Cuanto mayor sea el factor de mejora, mayores costes supondrá realizar ese cambio. Los costes divididos en hardware, diseño, desarrollo e instalación son calculados por la propia empresa, teniendo en cuenta qué van a necesitar cambiar por cada atributo, piden presupuesto a empresas que se dediquen a realizar dichos cambios, ya que ellos saben qué se va a necesitar para llevar a cabo el cambio. Mejoras: Disponibilidad: Factor de mejora del 25% en redundancia activa. Modificabilidad: Factor de mejora del 10% en modificación de hardware. Rendimiento: Factor de mejora del 40% en aumento de la velocidad CPU. Seguridad: Factor de mejora del 50% en configuración del firewall. Usabilidad: Intacta Verificabilidad: Intacta Costes: Disponibilidad: 350 Euros en hardware, 200 Euros en diseño, 150 Euros en desarrollo, 450 Euros en instalación. Hacen un total de 1150 Euros. Modificabilidad: 150 Euros en hardware, 50 Euros en diseño, 75 Euros en desarrollo, 175 Euros en instalación. Hacen un total de 450 Euros. Rendimiento: 550 Euros en hardware, 300 Euros en diseño, 250 Euros en desarrollo, 460 Euros en instalación. Hacen un total de 1560 Euros. Seguridad: 600 Euros en hardware, 400 Euros en diseño, 550 Euros en desarrollo, 750 Euros en instalación. Hacen un total de 2300 Euros. Usabilidad: 0 Euros. Verificabilidad: 0 Euros. Coste total: 5460 Euros. Inversión: 500000 Euros 119 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Comparando la inversión y el coste total, el resultado de la ejecución del modelo es un proyecto viable con un esfuerzo económico para la empresa (establecido en 500000 Euros). Después de relacionar los atributos entre sí nos queda una mejora total como la siguiente: Disponibilidad: 28,4%. Modificabilidad: 15,618% Rendimiento: 40,699% Seguridad: 55,96%. Usabilidad: 6,349% Verificabilidad: 1,92% Conclusión: Cómo se ha explicado a lo largo del proyecto, los atributos tienen relación entre sí. Por ellos quedan los porcentajes que vemos al final del caso. Aunque se decidió no mejorar ni la verificabilidad ni la usabilidad, se ve como se obtienen mejoras en dichos atributos, ya que se ven afectados por las mejoras del resto de atributos (la usabilidad en mayor medida que la verificabilidad). Vemos como en las mejoras realizadas, todos los atributos se han visto beneficiados por los cambios. La inversión para este proyecto es mayor que los costes generados pero no por mucha diferencia económica, por lo que el proyecto es viable para poder realizarse, pero sabiendo que merecerá la pena ya que supondrá un gran gasto para la empresa. 2º Situación: Se quiere modificar en el sistema, de inicio, una aplicación móvil para la empresa. Se requiere que tenga una buena disponibilidad para que el usuario pueda usarla el mayor tiempo posible sin caídas, un buen rendimiento para que quede contento con su utilización, y que tenga una modificabilidad muy alta ya que en las aplicaciones se pueden introducir mejoras continuamente. La usabilidad también será necesaria para que el usuario tenga mayor facilidad en su utilización y la verificabilidad se mejorará para monitorizar la aplicación y comprobar que funciona correctamente. Por el momento no se necesita 120 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA mejorar la seguridad ya que es buena y además no es un factor crítico en la aplicación que se utiliza. Mejoras: Disponibilidad: Factor de mejora del 50% en sustitución. Modificabilidad: Factor de mejora del 70% en modificación de software. Rendimiento: Factor de mejora del 40% en cambio del SO. Seguridad: Intacta. Usabilidad: Factor de mejora del 20% en modificación de hardware. Verificabilidad: Factor de mejora del 10% en monitorización. Costes: Disponibilidad: 1650 Euros en hardware, 3200 Euros en diseño, 3150 Euros en desarrollo, 4450 Euros en instalación. Hacen un total de 12450 Euros. Modificabilidad: 3150 Euros en hardware, 4050 Euros en diseño, 2175 Euros en desarrollo, 3175 Euros en instalación. Hacen un total de 12550 Euros. Rendimiento: 5550 Euros en hardware, 5300 Euros en diseño, 5250 Euros en desarrollo, 9460 Euros en instalación. Hacen un total de 25560 Euros. Seguridad: 0 Euros. Usabilidad: 250 Euros en hardware, 300 Euros en diseño, 250 Euros en desarrollo, 260 Euros en instalación. Hacen un total de 1060 Euros. Verificabilidad: 50 Euros en hardware, 100 Euros en diseño, 50 Euros en desarrollo, 460 Euros en instalación. Hacen un total de 1560 Euros. Coste total: 52280 Euros. Inversión: 50000 Euros Comparando la inversión y el coste total, el resultado de la ejecución del modelo es un proyecto inviable debido a que el coste es mayor que la inversión. 121 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Después de relacionar los atributos entre sí nos queda una mejora total como la siguiente: Disponibilidad: 52,2%. Modificabilidad: 75,579% Rendimiento: 42,449% Seguridad: 8,81%. Usabilidad: 25,819% Verificabilidad: 11,92% Conclusion: El coste total es muy alto debido a las modificaciones que se realizan relacionado con el dinero disponible por la empresa para realizar la inversión. Por ello, este proyecto no es viable, pero a partir de los resultados, si se quiere realizar algo así, modificando algunos datos (menos mejora en algún atributo) se tendrán menos costes y así se podrá llegar a un proyecto viable. 3º Situación: Se ha visto en una empresa, que la modalidad RIA no va lo rápido que se esperaba y que no es del todo segura por lo que los usuarios no están contentos con ello porque no es del todo fiable además de su lentitud. Por ello se ha decidido mejorar en gran medida el rendimiento y la seguridad. Además, se querrá comprobar que los cambios que se han realizado son correctos por lo que se mejorará la verificabilidad realizando pruebas en tiempo real para ver los resultados. Ya metidos a realizar cambios, se mejorará la usabilidad un poco para que sea más fácil su uso. Mejoras: Disponibilidad: Intacta. Modificabilidad: Intacta. Rendimiento: Factor de mejora del 70% en aumento de velocidad de discos. Seguridad: Factor de mejora del 40% en redundancia pasiva. Usabilidad: Factor de mejora del 5% en adición de software. Verificabilidad: Factor de mejora del 35% en prueba en tiempo real. 122 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Costes: Disponibilidad: 0 Euros. Modificabilidad: 0 Euros. Rendimiento: 3250 Euros en hardware, 3100 Euros en diseño, 4050 Euros en desarrollo, 7460 Euros en instalación. Hacen un total de 17860 Euros. Seguridad: 450 Euros en hardware, 700 Euros en diseño, 850 Euros en desarrollo, 960 Euros en instalación. Hacen un total de 2960 Euros. Usabilidad: 50 Euros en hardware, 40 Euros en diseño, 70 Euros en desarrollo, 100 Euros en instalación. Hacen un total de 260 Euros. Verificabilidad: 250 Euros en hardware, 200 Euros en diseño, 530 Euros en desarrollo, 360 Euros en instalación. Hacen un total de 1340 Euros. Coste total: 22420 Euros. Inversión: 1000000 Euros Comparando la inversión y el coste total, el resultado de la ejecución del modelo es un proyecto viable totalmente. Después de relacionar los atributos entre sí nos queda una mejora total como la siguiente: Disponibilidad: 4,5%. Modificabilidad: 4,96% Rendimiento: 67,25% Seguridad: 42,85%. Usabilidad: 8,78% Verificabilidad: 37,21% Conclusión: Debido a que esta empresa tiene un alto poder económico, el proyecto es viable totalmente además que si se quisiera mejorar algo más, se podría vistos los resultados. 123 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA 124 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Capítulo 14. Conclusiones (Know-How). Tras realizar este proyecto he adquirido unos conocimientos acerca del aspecto software de la ingeniería que antes no tenía. Al entrar en detalle en el tema, te das cuenta de lo importante que es este apartado de la informática a la hora de realizar proyectos de mejora en sistemas. El estudio de los atributos de calidad permite conocer más acerca de cómo mejorar las prestaciones de un sistema en cuanto a la disponibilidad, modificabilidad, rendimiento, seguridad, usabilidad y verificabilidad. Son características propias que dependiendo de ellas funcionará mejor o peor un sistema. También existe una relación directa entre ellas y conviene saberlo para no equivocarse, ya que queriendo mejorar un atributo podemos empeorar varios. Añadido a esto, el estudio de modelos económicos permite conocer más acerca de la economía en general y de la imputación de costes de un proyecto en particular. La mezcla de estos conocimientos es el tema tratado durante el proyecto y a la hora de involucrarse en un proyecto futuro sería de gran ayuda haber tratado todos estos temas durante la realización de este proyecto. Como en todo proyecto, han surgido errores a la hora de realizar la programación de la aplicación, con su correspondiente solución. En la teoría no suelen surgir errores, ya que se trata de buscar y contrastar información. Hay que encontrar fuentes fiables de información de gente experimentada y entendida en el tema ya que cualquiera puede dar su opinión acerca de algo sin tener mucha idea. Por lo tanto, teóricamente aportamos un proyecto con información valiosa sobre la arquitectura software. En la práctica, la creación del modelo es una innovación a la hora de relacionar la informática con la economía como bien hemos dicho anteriormente. Entonces a la hora de relacionar porcentajes y costes surgieron errores de cálculo hasta que se encontró la relación más óptima posible. Debido a la gran cantidad de datos que alberga la aplicación, se tuvieron que crear dos botones diferentes para relacionar los atributos por separado. Uno que tiene en cuenta la disponibilidad, la modificabilidad y la seguridad y otro que relaciona el rendimiento, la usabilidad y la verificabilidad. También en la creación del informe inicial surgieron problemas para que se generase correctamente hasta conseguir que mostrase la información. Un detalle que no tiene que ver con el proyecto pero sí con el 125 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA aspecto de programación es que el tamaño de las ventanas, dependiendo del monitor, se ve la ventana perfectamente o queda expandida de manera que hay que modificar las dimensiones para que aparezca correctamente. También a la hora de escribir texto en Windows o Mac, se modifican los caracteres extraños como la eñe, comas, tildes o porcentajes. Si se ha escrito en un sistema operativo alguno de esos caracteres, en el otro se cambian y por ejemplo, en vez de aparecer “añadir” escribe “a%adir”. Un gran acierto ha sido programar en lenguaje Java ya que ofrece múltiples opciones que otros no ofrecen además del conocimiento del lenguaje por haber programado en ello durante la carrera realizando prácticas de buen nivel. El código permite realizar cambios con gran facilidad sin afectar negativamente a lo programado anteriormente, ya que muchas actualizaciones serían numéricas por lo que sólo habría que cambiar las cifras en cuestión. Si fuese añadir algún componente más, se crea una nueva ventana en el modelo o directamente en la ventana principal se ejecuta el cambio añadiendo mejoras en las prestaciones del modelo. Además de este aprendizaje, existen futuras mejoras que podrán ser implantadas en un futuro de las que los conocimientos están adquiridos pero necesitando más tiempo para poder realizarlas. Al estar el proyecto dividido en dos partes bien diferenciadas como son el estudio teórico y la aplicación a la práctica, al buscar información constantemente se te ocurren más ideas para que salga un proyecto mejor, pero algunas de ellas son con vistas al futuro ya que formarían parte de un proyecto muy completo que podría llegar a ser utilizado por muchas empresas a la hora de realizar cambios o crear nuevos proyectos. En estas mejoras se incluyen mayoritariamente relaciones numéricas con menor porcentaje de error entre los atributos, generación de informes detallados a la hora de terminar de utilizar la aplicación y mejoras generales de la aplicación añadiendo pequeños detalles que hagan de ella un modelo referencia para las empresas en la relación software-economía. En un futuro, además de la aplicación en sí, se podría crear una herramienta del estilo de Arche (de la que hemos hablado durante el proyecto), que tiene en cuenta los atributos de calidad casi en su perfección. 126 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Bibliografía. [INTR2003] “Introducción a la arquitectura de software” Clements, Bass, Kazman. [KRUC2014] http://jarroba.com/modelo-“41”-vistas-de-kruchten-para-dummies/ [CORB2014] http://es.wikipedia.org/wiki/CORBA [SCAL2012] http://www.sciencedirect.com/science/article/pii/S0164121211000793 [ESTA2012] http://olgacarreras.blogspot.it/2012/03/estandares-formales-de-usabilidad-ysu.html [KRUC2011] http://alfa4.blogspot.it/2011/01/arquitectura-de-software-41-kruchten.html [FACT2014] http://es.wikipedia.org/wiki/Factor_de_disponibilidad [POLI2014] http://es.wikipedia.org/wiki/Polimorfismo_(informática) [COMM2014] http://en.wikipedia.org/wiki/CommunicationsElectronics_Security_Group#CESG [SIST2009] http://direccionylagestion.blogspot.it/2009_07_01_archive.html [MANT2012] http://apistarelli.com.ar/mantenibilidad.pdf [PASO2012] http://blog.optimyth.com/es/2012/12/4-pasos-para-mejorar-lamantenibilidad-de-nuestro-software [PASO2013] http://www.20minutos.es/noticia/1985292/0/ [SEGU2013] http://losapuntesdetux.blogspot.com.es/2013/10/bastille-linux-o-comomejorar-la_27.html [BUQU2013] http://www.ingenieros.es/noticias/ver/sistemas-para-mejorar-de-laseguridad-en-el-atraque-de-grandes-buques/4170 [DISP2008] http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y- como-se-logra/ [DISP2014]http://es.rockwellautomation.com/applications/gs/emea/gses.nsf/pages/at11020 3 [REDU2014] http://www.castelomega.com/index.php/Noticias/sistemas-de-servidoresredundantes-para-aumentar-la-disponibilidad.html [ALTA2014] http://www.d2soluciones.com/ad.asp 127 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA [REND2014]http://h10025.www1.hp.com/ewfrf/wc/document?cc=es&lc=es&dlc=es&doc name=c00844500 [DESF2014] http://www.bitdefender.es/support/¿cómo-puedo-mejorar-el-rendimientode-mi-sistema-1017.html [PROG2013] http://www.genbeta.com/windows/cinco-programas-para-mejorar-elrendimiento-de-tu-equipo-con-windows [OPTI2013] http://www.softzone.es/2013/09/18/consejos-para-optimizar-el- rendimiento-del-sistema-operativo/ [MWEB2013] http://www.10formas.com/10-formas-de-mejorar-la-usabilidad-de-un-sitioweb [PATR2014] http://www.willydev.net/descargas/prev/PatronesUsa.pdf [CLOU2013] http://www.qipu.es/noticias/r2-sistemas-mejora-usabilidad-r2-docuo-gestordocumental-cloud [SOFT2006] http://noticias.universia.es/ciencia-nntt/noticia/2006/11/14/594994/usabilidad-software-pensado-usuarios.html [ATRIB2014]http://sistemas.uniandes.edu.co/~csof5204/dokuwiki/lib/exe/fetch.php?medi a=principal:modulo3-atributosdecalidad.pdf [PEQU2014] http://es.wikipedia.org/wiki/Pequeña_y_mediana_empresa [PONC2014] http://ponce.inter.edu/vl/computing/hard6.html [EMPR2014]http://www.emprendia.org/faq.php?id=1&tema=42&f=36&lang=cas [SRED2014] http://es.wikipedia.org/wiki/Sistema_redundante [VCPU2014] http://www.ehowenespanol.com/mide-velocidad-del-cpu-como_170594/ [CORT2014] http://es.wikipedia.org/wiki/Cortafuegos_(informática) [COPL2014] http://www.sciencedirect.com/science/article/pii/S0957417412001273 [COCO2014] http://es.wikipedia.org/wiki/COCOMO 128 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Anexo A. Planificación del proyecto. Desde que se ha comenzado a realizar el proyecto hasta que se ha terminado, se ha pasado por muchas fases y refleja perfectamente el tipo de metodología que se ha llevado a cabo y que vamos a describir a continuación: -­‐ Estudio teórico: De este modo, adquirimos los conocimientos necesarios para poder tratar el tema de manera que todo lo que aparezca en el proyecto se acerque lo máximo posible a la realidad. La mayoría de temas a tratar vienen perfectamente expresados en el libro de Clements y Bass, llamado “Arquitectura Software”, y sumando a este libro otra información adicional hemos llegado a tener todos los conocimientos actuales. Es un proceso largo ya que hay que documentarse bien, contrastando para comprobar que las fuentes son fiables. Ha sido la etapa más larga del proyecto ya que además de buscar correctamente, hay que seleccionar que información es la más importante para el proyecto ya que la cantidad de datos recogidos es inmensa. -­‐ Planificación y análisis: Esta etapa también ha sido clave ya que se buscó cómo enlazar toda la información teórica con una aplicación práctica. Existían muchísimas posibilidades ya que el campo de la arquitectura software es extenso. Por lo tanto, esto conllevó a parar y pensar a ver cual era la mejor solución y así se llegó al punto de realizar la aplicación existente, no sin antes realizar cambios sobre qué mejoras podrían realizarse. -­‐ Diseño: Una vez llegado a la decisión de qué aplicación realizar, es cuándo se tuvo que comenzar a diseñar la aplicación, es decir, de qué partes iba a constar, qué servicios iba a ofrecer al cliente y, en resumen, todo lo relevante en ella. Bien es cierto, como hemos comentado anteriormente, que de la propuesta inicial de la aplicación a lo que ha salido finalmente han surgido variaciones ya que durante la programación de la misma, surgían nuevas ideas que mejoraban lo presente. 129 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA -­‐ Programación: Cuando se ha realizado el diseño de la aplicación, se lleva a la práctica programando todo según lo previsto. Esta etapa lleva su tiempo ya que surgen errores en el código o dudas acerca de cómo se programa algo que quieres hacer, por lo que es un periodo de paciencia y entrega. -­‐ Pruebas: Una vez terminado, se realiza el periodo de ‘tests’ para ver si funciona lo programado anteriormente. Debe cumplir los requisitos necesarios que se estipularon en el apartado de diseño. -­‐ Implantación: Al comprobar que todo funciona correctamente, se procede a su implantación para el entorno para el que se ha diseñado. En este caso, se ejecutará para un caso real de una empresa que quiera realizar cambios o crear un nuevo sistema con los requisitos que necesiten y ver el resultado como simulación de su implantación real física. -­‐ Documentación: Este proceso comienza al principio del proyecto y termina a la vez que termina el proyecto. Es dónde se refleja toda la información del proyecto. Es lo más importante ya que abarca todas y cada una de las partes de este proyecto. Para ver esta planificación gráficamente hemos realizado el siguiente diagrama de Gantt: Figura 44. Diagrama de Gantt. 130 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 45. Tareas Figura 46. Resumen tareas. 131 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Figura 47. Diagrama de Gantt II. 132 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA Anexo B. Estudio económico. Este proyecto requiere un equipo de trabajo en el cual cada persona se dedica a una parte específica: -­‐ Jefe de proyecto: Es el encargado de supervisar a las demás partes del equipo para comprobar que están realizando correctamente su trabajo. -­‐ Analista: Será la persona que estudie el ámbito en el que se está trabajando para intentar llegar a la mejor solución posible. Como el abanico de posibilidades es muy amplio, intentará llegar a la mejor solución. -­‐ Diseñador: Una vez tenga toda la información recopilada en el estudio teórico, procederá a diseñar la aplicación práctica relacionada con tal información. -­‐ Programador: Siguiendo las instrucciones dadas por el diseñador de la aplicación, el programador procederá a llevar ese diseño a cabo mediante la programación de la aplicación. -­‐ Tester: Es la persona que se encargará de ir probando todas y cada unas de las instrucciones que se van programando. TARIFAS DEL PERSONAL JEFE DE PROYECTO 50 €/h ANALISTA 40 €/h DISEÑADOR 35 €/h PROGRAMADOR 35 €/h TESTER 20 €/h Tabla 20. Tarifas del personal. 133 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA En cuanto al personal ya tenemos los costes establecidos que suponen, pero también hay que tener en cuenta todos los elementos necesarios para poder realizar el proyecto. Al no ser de un proyecto a gran escala, no se necesitarán demasiados elementos. Sabiendo que el proyecto en total ha llevado 20 meses tenemos: [EMPR2014] TARIFAS ESTACIÓN DE TRABAJO 1000 € CONEXIÓN ADSL 20 €/mes = 400 € ELECTRICIDAD 10 €/mes = 200 € TOTAL 1600 € Tabla 21. Tarifas de servicios. Relacionando estos costes con la planificación del proyecto previamente explicada, es cómo llegamos a obtener los costes finales del proyecto. Primero vamos a establecer una tabla en la que se recojan las horas totales que trabaja cada participante del equipo. Para ello hay que saber que, aunque la etapa dure esos meses, no se está trabajando las 24 horas del día y que para que finalicen las etapas, cada integrante del equipo debe terminar su parte de trabajo. Así es que llegamos a la siguiente conclusión reflejada en la tabla mostrada a continuación. Mencionar solamente que las siglas escritas en la tabla corresponden a jefe de proyecto, analista, diseñador, programador y tester siguiendo el orden de izquierda a derecha. 134 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INFORMÁTICA JP A D P T 50€ * 10h 40€ * 50h 0 0 0 y análisis 50€ * 1h 40€ * 100h 35€ * 1h 35€ * 1h 0 Diseño 50€ * 2h 40€ * 5h 35€ * 30h 35€ * 5h 0 Programación 50€ * 2h 40€ * 5h 35€ * 5h 35€ * 70h 20€ * 2h Pruebas 50€ * 1h 40€ * 1h 35€ * 1h 35€ * 1h 20€ * 10h Implantación 50€ * 1h 40€ * 1h 35€ * 1h 35€ * 1h 20€ * 1h Total 850€ 6480€ 1330€ 2730€ 260€ Estudio teórico Planificación Tabla 22. Tabla de costes. COSTES TOTALES EQUIPO SERVICIOS TOTAL 11650€ 1600€ 13250€ Tabla 23. Costes totales. Teniendo en cuenta los impuestos que se imponen, considerando el IVA del 21%, nos quedaría un presupuesto total de 16032,5€. 135
