Sistema Telemático para la estimación de esfuerzo de proyectos de software

Texto completo

(1)SISTEMA TELEMATICO PARA LA ESTIMACION DE ESFUERZO DE PROYECTOS DE SOFTWARE. ALEXANDER ESCAMILLA VILLARRAGA NELLY YURANI MARTÍNEZ ZAMUDIO. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERIA TELEMÁTICA BOGOTÁ 2017.

(2) SISTEMA TELEMATICO PARA LA ESTIMACION DE ESFUERZO DE PROYECTOS DE SOFTWARE. ALEXANDER ESCAMILLA VILLARRAGA Código: 20152678122 NELLY YURANI MARTÍNEZ ZAMUDIO Código: 20152678028. Trabajo de grado para optar el título de INGENIERO EN TELEMÁTICA. Tutor: Ing. NORBERTO NOVOA TORRES. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERIA TELEMÁTICA BOGOTÁ 2017.

(3) Nota de aceptación. ___________________________________ ___________________________________ ___________________________________ ___________________________________ ___________________________________ ___________________________________. ___________________________________ Firma del Jurado. ___________________________________ Firma del Tutor.

(4) TABLA DE CONTENIDO INTRODUCCIÓN. 8. RESUMEN. 9. ABSTRACT. 10. 1. FASE DE PLANEACIÓN. 11. 1.1.. Titulo. 11. 1.2.. Tema. 11. 1.3.. Planteamiento del problema. 11. 1.3.1.. Descripción. 11. 1.3.2.. Pregunta de investigación. 12. 1.4.. Objetivos. 12. 1.4.1.. Objetivo general. 12. 1.4.2.. Objetivo especifico. 12. 1.5.. Alcances. 13. 1.6.. Delimitaciones. 13. 1.6.1.. Técnica. 13. 1.6.2.. Espacial. 13. 1.6.3.. Temporal. 13. 1.7.. Recursos. 14. 1.7.1.. Humanos. 14. 1.7.2.. Físicos. 14. 1.7.3.. Tecnológicos (software). 14. 1.7.4.. Financieros. 15. Marco de referencia. 15. 1.8.. 1.8.1.. Marco teórico. 17. 1.8.2.. Marco metodológico. 36. 1.9.. Cronograma de actividades. 40. 1.10.. Propuesta metodológica. 41. 2. Análisis, diagnóstico y levantamiento de requerimientos 2.1.. Descripción. 2.1.1. 2.2.. Portafolio de servicios. Análisis. 43 43 43 43.

(5) 2.3.. Diagnostico. 3. Requisitos, elementos y restricciones el sistema. 44 46. 3.1.. Requisitos. 46. 3.2.. Características operacionales. 48. 3.3.. Elementos del sistema. 48. 3.4.. Restricciones del sistema. 49. 4. Diseño módulos del sistema telemático. 50. 4.1.. Modelo de procesos. 50. 4.1.1.. Administración de usuarios. 50. 4.1.2.. Crear estimación. 52. 4.1.3.. Consultar estimación. 53. 4.2.. Desarrollo de módulos. 54. 4.2.1.. Módulos aplicación. 54. 4.2.2.. Microservicio. 56. 4.2.3.. PostgreSQL. 56. 4.2.4.. Node.js. 56. 4.2.5.. Arquitectura. 57. 4.2.5.1.. Análisis de protocolos de comunicaciones. 57. 4.2.5.2.. Conclusiones de protocolos. 60. 4.2.5.3.. Diseño general del sistema telemático. 60. 5. Pruebas. 62. 5.1.. Login. 62. 5.2.. Crear nueva estimación. 64. 5.3.. Evidencias pruebas. 68. 5.4.. Conclusiones pruebas. 70. 6. Propuesta de nuevo proceso de estimación. 71. 7. Evaluación de la solución. 73. 8. CONCLUSIONES. 74. 9. Referencias Bibliográficas. 75. ANEXOS. 76.

(6) LISTA DE TABLAS. Tabla 1: Recursos financieros........................................................................... 15 Tabla 2: Clasificación de los actores................................................................. 32 Tabla 3: Clasificación de los casos de uso ....................................................... 32 Tabla 4: Cálculo de factores técnicos ............................................................... 34 Tabla 5: Peso factores de entorno o ambientales ............................................. 35 Tabla 6: Requisitos iniciales para el sistema telemático ................................... 47 Tabla 7: Set pruebas funcionalidad de login ..................................................... 62 Tabla 8: Set pruebas crear nueva estimación ................................................... 64 Tabla 9: Evidencias Pruebas Login................................................................... 68 Tabla 10: Evidencias Pruebas Crear Estimación .............................................. 69.

(7) LISTA DE ILUSTRACIONES. Ilustración 1: Sistema Telemático ..................................................................... 19 Ilustración 2: Ejemplo aplicación con arquitectura monolítica ........................... 21 Ilustración 3: Ejemplo aplicación arquitectura de microservicios ...................... 22 Ilustración 4: Imagen alegórica del sistema operativo ...................................... 25 Ilustración 5: Pasos básicos en el método de estimación Puntos Caso de Uso 31 Ilustración 6: Cronograma ................................................................................. 40 Ilustración 7: Diagrama Flujo Creación Usuarios .............................................. 51 Ilustración 8: Diagrama Flujo Creación Nueva Estimación ............................... 52 Ilustración 9: Diagrama Flujo Consultar Estimación .......................................... 53 Ilustración 10: Diagrama de clases sistema telemático .................................... 54 Ilustración 11: Diagrama de componentes del sistema telemático ................... 55 Ilustración 12: Capas Modelo TCP/IP ............................................................... 59 Ilustración 13: Diseño general sistema telemático ............................................ 61 Ilustración 14: Flujo proceso general sistema telemático .................................. 61 Ilustración 15: Diagrama Flujo Propuesta Nuevo Proceso Estimación ............. 71.

(8) INTRODUCCIÓN Todas las organizaciones basan su funcionamiento en el desarrollo de actividades, que se nutren de procesos que permiten alcanzar un objetivo específico. Dicha gestión de procesos debe ser optima y apoyada de tecnología, buscando así alcanzar los mejores resultados, que beneficien a la compañía en su participación competitiva y comercial, en cada uno de los escenarios que se presentan en el día a día. Para las empresas dedicadas al desarrollo de software, es también necesario ayudar a optimizar todos los procesos de cada uno de los grupos de interés que la componen, y que benefician la organización tanto interna como externamente. Dentro de la primera etapa (planificación), una de las principales actividades, es la estimación del producto a desarrollar, tarea que puede ser compleja puesto que al principio se conoce muy poco acerca de la solución que necesita determinado cliente y elaborar una propuesta se convierte en algo intuitivo (juicio de experto) y riesgoso, a eso debe sumarse que a causa de las presiones de la competencia y demanda del mercado, es necesario dar una propuesta rápida que incluya tiempos y costos del proyecto. Para mitigar el impacto de las malas estimaciones, las empresas han usado el concepto de Punto de Función para realizar esta actividad, puesto que éste representa una medida independiente de la tecnología de software (por ejemplo, de los frameworks o librerías particulares a utilizar) que se utilice en el desarrollo del software. El Punto de Función (PF) es una unidad de medida base para un requerimiento de usuario, caracterizada a través de un conjunto de tipos de componentes, como por ejemplo entradas y salidas de datos, archivos, consultas, etc. Para abordar la anterior situación, el presente trabajo tiene como propósito desarrollar un sistema telemático para la estimación de esfuerzo de proyectos de software, el cual se integre y comunique con microservicios por medio de una API rest, para ayudar en el proceso de estimación de la empresa BITS Américas S.A.S.. 8.

(9) RESUMEN Actualmente la empresa BITS Américas S.A.S, realiza el proceso de estimación de proyectos de software mediante el juicio de experto, el cual de acuerdo a su criterio y experiencia diligencia un formato Excel, en el que establece los casos de uso y la complejidad que va a tener cada uno, y de esta forma lograr dar al cliente el tiempo y esfuerzo que tendrá el desarrollo de la necesidad. Dicha actividad no cuenta con un sistema que facilite el cálculo ágil de la estimación de tiempo y esfuerzo requeridos para el desarrollo de un proyecto de software, y que a este soportado por una metodología reconocida y fiable que reduzca el margen de error en las estimaciones de la empresa como lo es el método de Puntos de Casos de Uso. Es por ello que surge la necesidad de un sistema telemático basado en arquitectura de micro servicios, que permita un acceso rápido y eficiente al histórico de todas las estimaciones de la empresa, y también la creación de nuevas estimaciones, en donde se pueda obtener el tiempo y el esfuerzo que se necesita para un nuevo proyecto. El sistema y el documento se basan en lo definido por las fases de la metodología de mejoramiento continua PHVA, con ella pudo establecerse claramente el alcance y limitaciones, como también el orden en el que debía trabajarse el proyecto. Siguiendo lo planteado por la metodología implementada, se realiza un análisis, diagnóstico de la necesidad de la empresa para el tema de las estimaciones de nuevos proyectos de software, identificados se evalúan las características y restricciones que tendrá el sistema telemático y lo que se va a desarrollar para poder optimizar el proceso de la empresa. Como posible solución, para mejorar el proceso interno de TI, se crea un prototipo que permite realizar el cálculo de estimación de esfuerzo y tiempo soportado bajo lo que define el método de Puntos por casos de uso, cuando ya esté terminado el sistema, se realizarán pruebas de aceptación para validar la funcionalidad de todos los módulos y que permitan identificar si la solución satisface las necesidades del usuario final. Por último, se dan a conocer las conclusiones del proyecto.. 9.

(10) ABSTRACT Currently the company BITS Americas SAS, carry out the process of estimating software projects by the evaluation expert, who according to his criteria and experience diligently an Excel format, which establishes the use cases and the complexity that will have each one, and in this way achieve the client the time and effort that have the development of the need. This activity does not have a system that facilitates the calculation of the estimation of time and effort necessary for the development of a software project, and that is supported by a recognized and reliable methodology that reduces the margin of error in the estimates of the company such as the Use Point Points method. That is why the need arises for a telematic system based on a micro services architecture, which allows a fast and efficient access to the history of all the company's estimates, as well as the creation of new estimates, where you can get the time and effort that is needed for a new project. The system and the document are based on the phases of the continuous improvement methodology. PHVA, with the same meaning as the scope and limit, also did. Following the proposed methodology, an analysis, the diagnosis of the need of the company for the state of the new software projects, is carried out, the characteristics and restrictions that the telematic system will be assessed and what will be developed to be able to optimize the process of the company. As a possible solution, to improve the internal IT process, a prototype is created that allows calculation of the time and effort estimation supported under which the method of Points of use can be defined, when the system is finished , acceptance tests will be performed to validate the functionality of all the modules and that allow to identify if the solution satisfies the needs of the end user. Finally, the best conclusions of the project are given.. 10.

(11) 1. FASE DE PLANEACIÓN 1.1.. Titulo. Sistema telemático para la estimación de esfuerzo de proyectos de software.. 1.2.. Tema. Uso de un prototipo de sistema telemático que sirva como apoyo al proceso de estimación de desarrollo de software para la empresa BITS Américas S.A.S.. 1.3.. Planteamiento del problema. 1.3.1. Descripción Bits Américas S.A.S, es una empresa que se dedica al desarrollo de software tanto a nivel nacional como internacional, llevando en el mercado de TI ya más de 9 años. Actualmente para planificar un proyecto de software, la compañía realiza las tareas de estimación de tiempos de forma tradicional, es decir, basados en el juicio o Criterio de Experto, en donde el medidor usa su perspectiva y experiencia para realizar dicha actividad. Después de la experiencia propia y de la observación de los procesos de planificación que usa la empresa para los proyectos de software, se identificó que la estimación de tiempos resulta ser una labor compleja y generalmente poco realista, que conduce a pronosticar valoraciones imprecisas, debido a factores como: no disponer de información detallada del proyecto precisando un tamaño equivocado, basarse en información histórica de proyectos anteriores (todos los proyectos no son iguales), determinar una complejidad sin tener en cuenta los recursos que se van a utilizar, incertidumbre estructural, no contar con un experto de negocio o un individuo que conozca las plataformas o solución que el cliente necesita de acuerdo a la función de su negocio, y no tener un método ágil para la estimación. A continuación, se listan algunas consecuencias o impactos negativos que tiene una incorrecta definición de estimación de un proyecto: ● Inconformidad en los clientes pues estos requieren respuestas inmediatas. 11.

(12) ● Desfase de los tiempos y costos del proyecto. ● Problemas gerenciales y de administración del proyecto. ● Incumplimiento en fechas de entrega, atrasando el cronograma del proyecto. ● Impactos negativos en el ciclo de vida de desarrollo del software. ● Baja calidad en el producto final entregado. ● Reputación de la empresa 1.3.2. Pregunta de investigación ¿Cómo mejorar el proceso de estimación de esfuerzo de los proyectos de software en Bits Américas S.A.S?. 1.4.. Objetivos. 1.4.1. Objetivo general Crear un sistema telemático que busque estimar el esfuerzo de proyectos de software aplicando la metodología puntos por casos de uso y arquitectura de micro servicios que se comuniquen a través de una API basada en el protocolo HTTP para Bits Américas S.A.S.. 1.4.2. Objetivo especifico ● Planear un nuevo proceso para la actividad de estimación que permita establecer el esfuerzo de un proyecto de software dentro de la compañía Bits Americas S.A.S. ● Implementar un nuevo proceso que se apoye en un sistema telemático realizando la integración y comunicación con microservicios por medio de una API. ● Analizar los resultados obtenidos para verificar que soportan y están alineados al alcance definido para el nuevo proceso de estimación. ● Evaluar los resultados obtenidos del nuevo proceso de estimación de esfuerzo para la compañía Bits Américas con el fin de identificar las posibles mejoras que pueden aplicarse.. 12.

(13) 1.5.. Alcances. El prototipo de software será responsive, además de ser desarrollado con tecnologías y herramientas libres (open source), por ello no representará en un gasto económico grande. Por otro lado, la parte lógica estará apuntando directamente a lo que define la métrica de estimación de software de puntos función. Este prototipo contará con las siguientes características: ● ● ● ●. Servicio de login. Registro de nuevos usuarios. Registro de nuevas estimaciones. Consulta de histórico de estimaciones y detalle de cada una.. 1.6.. Delimitaciones. 1.6.1. Técnica ● Este proyecto está enfocado hacia el desarrollo de un prototipo de sistema telemático responsive como herramienta de apoyo para líderes de proyecto y otros interesados de la empresa Bits Américas S.A.S para realizar el proceso de estimación de software. ● Las tecnologías usadas para el desarrollo de este prototipo son: PostgreSQL, JavaScript, frameworks AngularJs y LoopBack. 1.6.2. Espacial El prototipo que se pretende desarrollar con este proyecto está dirigido a proporcionar una posible solución para la empresa Bits Américas S.A.S.. 1.6.3. Temporal La duración de los procesos correspondientes al desarrollo integral del proyecto está contemplada dentro del cronograma (ver página 39) de trabajo que está previsto para este por 13 semanas. 13.

(14) 1.7.. Recursos. 1.7.1. Humanos ● 2 ingenieros telemáticos. ● 1 tutor. 1.7.2. Físicos •. PC Intel Cpre i5-5200U CPU 2.20 GHz RAM 12.0 GB Disco Duro: 600 GB. •. Sony Xperia T2. 1.7.3. Tecnológicos (software) ● ● ● ● ● ●. Microsoft Word 2015 Microsoft Project 2015 Node.Js Angular 2.0 Loopback Ubuntu 16.04.03 LTS. 14.

(15) 1.7.4. Financieros Tabla 1: Recursos financieros. Actividad de Descripción costo. Cantidad. Papelería. Tiempo del tutor Tiempo del estudiante Transporte Otros. Fotocopias Resma de papel Impresiones Medios magnéticos de almacenamiento Medida en horas Medida en meses Días Acceso a internet y luz por mes Eventualidades. Valor total en pesos. 50 2 450 3. Valor unitario en pesos $150 $13.000 $150 $1.000. 40. $35.000. $1’400.000. 3. $500.000. $1’500.000. 30. $4.000. $120.000 $225.000. $7.500 $26.000 $67.500 $3.000. $600.000 VALOR A PAGAR $3’949.000 Fuente: Propia. 1.8.. Marco de referencia. En el sector del mercado de desarrollo de software, la creciente competitividad en el mercado hace que las empresas no sean ajenas al hecho de requerir sistematizar procesos y actividades, esto con el fin de ser más productivos y eficaces, y a su vez eliminar costos y tiempo en cuanto a las tareas que se ejercen diariamente en su cadena de producción. Es por ello que implementar una herramienta de apoyo de estimación (que es una de las bases más importantes para poder planificar correctamente el proyecto) que sirva a todos los miembros del equipo de trabajo que se involucra en el desarrollo del proyecto, reduzca la subjetividad e índices de errores y otorgue un criterio de acierto alto en el proceso respectivo es de utilidad. En la actualidad existen varios métodos de estimación de software, como lo son: por puntos función: IFPUG, NESMA, Mk-II, COSMIC, FiSMA y Karner (puntos por casos de uso); basados en el conocimiento empírico de los expertos (líderes de proyectos y/o gerentes); por analogía, que se basa en experiencias 15.

(16) documentadas; COCOMO -(Constructive Cost Model) II- y SLIM (Software LIfecycle Management)1. Algunos de los criterios para la estimación son: 1.. Clasificar cada interacción entre actor y caso de uso según su complejidad y asignar un peso en función de ésta. La complejidad de los actores puede corresponderse con una de las tres categorías posibles: a. Simple, representa a otro sistema con una API definida. Se le asigna un peso de valor 1. b. Medio, representa a otro sistema que interactúa a través de un protocolo de comunicaciones. Por ejemplo, TCP/IP o a través de un interfaz por línea de comandos. Se le asigna un peso de valor 2. c. Complejo, la interacción se realiza a través de una interfaz gráfica. Se le asigna un peso de valor 3.. 2. 3.. 4.. 5.. 6.. Calcular la complejidad de cada caso de uso según el número de transacciones (incluyendo caminos alternativos) o pasos del mismo. Calcular los Puntos Casos de Uso No Ajustados (UUCP) del sistema. Se obtienen sumando los Puntos Casos de Uso de todos y cada uno de los actores y casos de uso que se han identificado y catalogado en función de su complejidad. Cálculo de los Factores Técnicos (TCF). A cada uno de los Factores Técnicos de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media. Cálculo de los Factores de Entorno. A cada uno de los Factores de Entorno de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media. Obtención de los Puntos Casos de Uso Ajustados. Una vez calculados los dos factores calculamos el valor ajustado de Puntos Casos de Uso.. Lo anterior da una visión general de las pautas a tener en cuenta dentro del sistema de estimación y explícitamente sobre algunos criterios utilizados para realización de esta tarea. Ahora bien, como se ha expresado anteriormente hacer un sistema de estimación que ayude y satisfaga las necesidades prioritarias de BITS Americas S.A.S, cuyas operaciones para este proceso actualmente son manejados de forma tradicional, es decir, por medio del juicio u opinión de un experto, presenta inconsistencias, pérdida de tiempo y costos que se ven reflejados en la puesta en marcha de cada proyecto y que podría ser mejorado con la implementación de una herramienta que realice un cálculo con base a ciertos criterios. 16.

(17) Por otro lado, al centrarse en la investigación de antecedentes que hablen sobre métodos y herramientas de estimación de software a nivel nacional, no se encuentran sistemas telemáticos que apoyen o sean una base para la solución propuesta, por lo cual es tal vez el primer acercamiento al problema planteado identificando los elementos y características que pueden usarse para resolverse y que se espera sirvan como base para la realización de nuevas investigaciones para otros autores. Ya por último, a la hora de implementar cualquier metodología o referencia guía dentro de la realización del proyecto, es necesario poder comparar requerimientos y necesidades similares; además de tener en cuenta los posibles escenarios que se puedan presentar a lo largo de la implementación, uno de los factores importantes es tener en cuenta las fórmulas o criterios que hacen parte del cálculo de la estimación, incluyendo un trabajo con calidad y con ayuda de tecnologías al alcance y sistematización de información que puede disminuir tiempos dedicados a la actividad y principalmente costos dentro del proceso.. 1.8.1. Marco teórico Telemática Etimológicamente el término telemática o teleinformática proviene del vocablo griego “tele” que significa “lejos o distancia” y del vocablo de origen latín “matica” que significa información (fuente http://conceptodefinicion.de/telematica/). Y hace referencia a la conjunción de telecomunicaciones e informática se refiere a la disciplina que trata la comunicación entre equipos de computación distantes. El nombre Telemática se genera de la palabra telecomunicaciones, y la palabra Informática. La Telemática cubre un campo científico y tecnológico de una considerable amplitud, englobando el estudio, diseño, gestión y aplicación de las redes y servicios de comunicaciones, para el transporte, almacenamiento y procesado de cualquier tipo de información (datos, voz, vídeo, etc.), incluyendo el análisis y diseño de tecnologías y sistemas de conmutación. Es por esto que los sistemas telemáticos en su mayoría forman parte de sistemas informáticos, es decir, son subsistemas de los sistemas informáticos o sistemas de información. La telemática también incluye servicios como el e-learning, comercio electrónico, TV digital, etc. La Telemática abarca entre otros conceptos los siguientes planos funcionales:. 17.

(18) El plano de usuario, donde se distribuye y procesa la información de los servicios y aplicaciones finales; ● El plano de señalización y control, donde se distribuye y procesa la información de control del propio sistema, y su interacción con los usuarios; ● El plano de gestión, donde se distribuye y procesa la información de operación y gestión del sistema y los servicios, y su interacción con los operadores de la red. ●. Cada uno de los planos se estructura en subsistemas denominados entidades de protocolo, que a su vez se ubican por su funcionalidad en varios niveles. ¿Qué es la telemática? La Telemática es una disciplina científica y tecnológica que surge de la evolución y fusión de la telecomunicación y de la informática. El término Telemática se acuñó en Francia (télématique) Ahora bien, el concepto, como se indica en este informe, también puede ligarse a un origen estadounidense: compunication, o como se utiliza más habitualmente Computer and Communications. No obstante, no es casualidad la diferencia entre los términos: responden a contextos diferentes, en efecto, hay matices claves a distinguir. La Telemática cubre un campo científico y tecnológico de una considerable amplitud, englobando el estudio, diseño, gestión y aplicación de las redes y servicios de comunicaciones, para el transporte, almacenamiento y procesado de cualquier tipo de información (datos, voz, vídeo, etc.), incluyendo el análisis y diseño de tecnologías y sistemas de conmutación. Se la define como "la ciencia que estudia el conjunto de técnicas que es necesario usar para poder transmitir datos dentro de un sistema informático o entre puntos de él situados en lugares remotos o usando redes de telecomunicaciones”1.. _______________________ 1 Salazar, Fernando (2013), Dudas informáticas ¿Qué es la telemática? ¿Para qué sirve?, recuperado el 14 de octubre del 2017, en http://dudasinformaticass.blogspot.com.co/. 18.

(19) Sistema telemático Un sistema telemático se encarga de interconectar ordenadores, terminales, switch, router…..usando algún medio adecuado como el cable del teléfono, coaxial, fibra, etc. Cada vez que conectamos dos equipos informáticos separados por una distancia y realizamos una transmisión de datos, estaremos hablando de un sistema telemático. No solo se compone de un ordenador y un cable o WiFi sino que, detrás de todo eso, hay una información codificada que hay que convertir y los dispositivos que realizan esas funciones, también están dentro de la definición 2. Consta de los siguientes elementos: Información, emisor, receptor y un canal; desde otro punto de vista distinguimos elementos de software y hardware. Ilustración 1: Sistema Telemático. Fuente: https://juleninforma.wordpress.com/2011/10/19/%C2%BFque-es-un-sistema-telematico/. _______________________ 2 Rodriguez, Julen (2011), Que es un sistema telemático, recuperado el 14 de octubre del 2017, en https://juleninforma.wordpress.com/2011/10/19/%C2%BFque-es-un-sistema-telematico/. 19.

(20) Microservicios Una “arquitectura de microservicios” es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno ejecutándose de forma autónoma y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus API3. Normalmente hay un número mínimo de servicios que gestionan cosas comunes para los demás (como el acceso a base de datos), pero cada microservicio es pequeño y corresponde a un área de negocio de la aplicación. Además, cada uno es independiente y su código debe poder ser desplegado sin afectar a los demás. Incluso cada uno de ellos puede escribirse en un lenguaje de programación diferente, ya que solo exponen la API (una interfaz común, a la que le da igual el lenguaje de programación en la que el microservicio esté programado por debajo) al resto de microservicios. No hay reglas sobre qué tamaño tiene que tener cada microservicio, ni sobre cómo dividir la aplicación en microservicios, pero algunos autores como Jon Eaves caracterizan un microservicio como algo que a nivel de código podría ser reescrito en dos semanas.. _______________________ 3 García Oterino, Ana M. Del Carmen (2015), ¿Qué son los microservicios?, recuperado el 14 de octubre del 2017, en http://www.javiergarzas.com/2015/06/microservicios.html. 20.

(21) Comparativa Enfoque Monolítico vs Enfoque Microservicios ● Visión Monolítica Ilustración 2: Ejemplo aplicación con arquitectura monolítica. Fuente: http://www.javiergarzas.com/2015/06/microservicios.html. En una arquitectura monolítica, la aplicación se desarrolla como una única unidad que no necesitará de ningún componente externo para funcionar, todos los “ciclos de cambio” están vinculados unos a otros, por lo que la más mínima modificación en una remota sección de la app conllevaría a la creación y despliegue de una versión completamente nueva. Se puede por ejemplo acceder a la página web de una tienda, realizar compras, etc., gracias a un servidor, una máquina que está ejecutando el código de la aplicación, en forma de archivo war, que eventualmente se conecta a una base de datos para recuperar información. Cuando un usuario compre un producto vía web, mostremos los productos disponibles, etc., la aplicación responderá de una forma u otra, según la hayamos programado, pero el código de las distintas lógicas de negocio (inventario, pagos, envíos) aunque puede estar separado en distintos módulos del código, finalmente se empaqueta en un único archivo ejecutable. Por eso la llamo arquitectura monolítica.. 21.

(22) Si hago un cambio en el módulo de pagos, tendré que subir a producción de nuevo todo el código, incluido los módulos de inventario y envíos, a pesar de no haberlos cambiado. Además, para escalar la aplicación (por ejemplo, dar servicio a muchos usuarios) tendré que ir ejecutando copias de mi aplicación bajo balanceadores de carga, que vayan redireccionando a los usuarios hacia un sitio u otro, en función de si el sistema está muy saturado. En este caso, tendré que replicar toda la aplicación, aunque solo sea el módulo de pagos el que concentre la sobrecarga. Pero, por otra parte, si mi aplicación no es muy compleja, la subida será sencilla y fácil de gestionar, ya que en este caso hablamos de un único archivo ejecutable.. Visión Microservicios. Ilustración 3: Ejemplo aplicación arquitectura de microservicios. Fuente: http://www.javiergarzas.com/2015/06/microservicios.html. En vez de tener un único ejecutable, cada componente es un ejecutable por sí mismo, y los servicios se comunican entre sí a través de llamadas.. 22.

(23) En este caso también tenemos un microservicio que implementa la interfaz web con la que interactúan los usuarios y cierta lógica por debajo para llamar al microservicio de pagos, inventario y envíos cuando sea necesario. Como beneficios con respecto al anterior enfoque tenemos que: ● Cada microservicio se puede desplegar de forma independiente: un cambio en el módulo de inventario no afectará a los demás, solo tendremos que subir ese módulo. ● Es fácil de entender, ya que la lógica de negocio está bien separada. ● Facilita la gestión de equipos multifuncionales y autónomos. Por sí mismo, cada microservicio es multifuncional: tiene una parte de base de datos, de backend, etc., además de ser independiente de los demás. Podemos formar equipos multifuncionales que se encarguen de varios microservicios, escalando el proceso de desarrollo de forma más sencilla (recuerda el post de la ley de Conway, tu arquitectura es reflejo de la organización de tu equipo y al revés, y puede llegar a facilitar o dificultar la gestión técnica). ● Es más fácil de escalar a nivel de software, ya que en lugar de replicar toda la aplicación y gestionarlo con balanceadores, replicaremos los microservicios que tengan más carga. Ventajas de uso A continuación, se listan algunas de los pros que tiene el uso de arquitectura de microservicios4: ● ● ● ● ● ● ●. Otorga a los desarrolladores libertad de desarrollar y desplegar servicios de forma independiente. Un microservicio se puede desarrollar con un equipo de trabajo mínimo. Se pueden usar diferentes lenguajes de programación en diferentes módulos. Fácil integración y despliegue automático (por ejemplo, con Jenkins). Fácil de entender y modificar, por lo que la integración de nuevos miembros al equipo de desarrollo será muy rápida. Los desarrolladores podrán hacer uso de las tecnologías más actuales. El uso de contenedores hará el desarrollo y despliegue de la app mucho más rápido.. _______________________ 4 A, Esaú (2016), ¿Qué son los microservicios?, https://openwebinars.net/blog/microservicios-que-son/. recuperado. el. 14. de. octubre. del. 2017,. en. 23.

(24) Funcionalidad modular, con lo que la modificación de un módulo no afectará al funcionamiento del resto. ● Fácil de escalar e integrar con aplicaciones de terceros. ●. JavaScript Es un lenguaje de programación que se utiliza principalmente para crear páginas web dinámicas. Una página web dinámica es aquella que incorpora efectos como texto que aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario. Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios. Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas4 aunque existe una forma de JavaScript del lado del servidor(Server-side JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo5. Loopback Es un framework open-source (licencia MIT) para Node.js que permite crear aplicaciones de forma sencilla6: ● Creación de APIS REST con un wizard CLI. ● Creación de modelos. ● API Explorer.. _______________________ 5 Wikipedia, (2017), JavaScript, recuperado el 14 de octubre del 2017, recuperado https://es.wikipedia.org/wiki/JavaScript 6 García, Luis Miguel (2016), Mi primera aplicación con StrongLoop LoopBack, recuperado https://unpocodejava.com/2016/04/05/mi-primera-aplicacion-con-strongloop-loopback/. en en. 24.

(25) ● Configuración de la autenticación y autorización. ● Conexión con diversos Data Stores: MySQL, Oracle, MongoDB, Postgresql, entre otras. ● SDK para Android, Java, iOS y Javascript. ● Addons, por ejemplo para soportar notificaciones Push, login social,… ● StrongLoop Arc que es una UI para construir, desplegar, gestionar y monitorizar aplicaciones LoopBack. GNU/Linux Es un sistema operativo: un conjunto de programas que le permiten interactuar con su ordenador y ejecutar otros programas. Un sistema operativo consiste en varios programas fundamentales que necesita el ordenador para poder comunicar y recibir instrucciones de los usuarios; tales como leer y escribir datos en el disco duro, cintas, e impresoras; controlar el uso de la memoria; y ejecutar otros programas. La parte más importante de un sistema operativo es el núcleo. En un sistema GNU/Linux, Linux es el núcleo. El resto del sistema consiste en otros programas, muchos de los cuales fueron escritos por o para el proyecto GNU. Dado que el núcleo de Linux en sí mismo no forma un sistema operativo funcional, preferimos utilizar el término “GNU/Linux” para referirnos a los sistemas que la mayor parte de las personas llaman de manera informal “Linux”7.. Ilustración 4: Imagen alegórica del sistema operativo. Fuente: https://es.wikipedia.org/wiki/GNU/Linux. 25.

(26) Linux está modelado como un sistema operativo tipo Unix. Desde sus comienzos, Linux se diseñó para que fuera un sistema multi tarea y multi usuario. Estos hechos son suficientes para diferenciar a Linux de otros sistemas operativos más conocidos. Sin embargo, Linux es más diferente de lo que pueda imaginar. Nadie es dueño de Linux, a diferencia de otros sistemas operativos. Gran parte de su desarrollo lo realizan voluntarios de forma altruista. En 1984 comenzó el desarrollo de lo que más tarde sería GNU/Linux cuando la Free Software Foundation (Fundación de software libre, N. del t.) comenzó a desarrollar un sistema operativo libre de tipo Unix, llamado GNU. El proyecto GNU ha desarrollado un conjunto de herramientas de software libre para ser utilizados por Unix™ y sistemas operativos tipo Unix como Linux. Estas herramientas permiten a los usuarios desarrollar tareas que van desde las mundanas (como copiar o eliminar ficheros del sistema) a las arcanas (como escribir y compilar programas o hacer edición sofisticada en una gran variedad de formatos de documento). Aunque hay muchos grupos e individuos que han contribuido a Linux, la Free Software Foundation ha sido quien más ha contribuido. No sólo creó la mayor parte de las herramientas que se utilizan en Linux sino también la filosofía y comunidad que hizo que Linux fuera posible. El núcleo Linux apareció por primera vez en 1991, cuando un estudiante de informática finlandés llamado Linus Torvalds anunció en el grupo de noticias de USENET comp.os.minix, una primera versión de un núcleo de reemplazo para Minix. Para más referencias consulte la página de historia de Linux en Linux Internacional. Linus Torvalds sigue coordinando el trabajo de varios cientos de desarrolladores con la ayuda de cierto número de responsables de subsistemas. Existe una página oficial del núcleo Linux. Se puede encontrar un excelente resumen semanal de las discusiones en la lista de correo linux-kernel en Kernel Traffic. Puede encontrar más información sobre la lista de correo linux-kernel en el documento PUF de la lista de correo «linux-kernel». Los usuarios de Linux tienen una gran libertad al elegir sus programas. Por ejemplo, un usuario de Linux puede elegir entre docenas de distintos intérpretes de línea de órdenes y entre distintos entornos de escritorio. Tantas opciones confunden a veces a los usuarios de otros sistemas operativos que no están _______________________ 7 Debian Org (2017), ¿Qué es GNU/Linyx?, recuperado https://www.debian.org/releases/stable/arm64/ch01s02.html.es. el. 14. de. octubre. del. 2017,. en. ht. 26.

(27) acostumbrados a poder modificar el intérprete de línea de órdenes o el entorno de escritorio. Es menos probable que un sistema Linux se colapse, además tiene mejor capacidad para ejecutar múltiples programas al mismo tiempo y es más seguro que muchos otros sistemas operativos. Debido a estas ventajas, Linux es el sistema operativo que ha experimentado mayor crecimiento en el mercado de los servidores. Últimamente, Linux está empezando a ser popular entre los usuarios domésticos y en empresas.. AngularJS Es un framework de JavaScript de código abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles. La biblioteca lee el HTML que contiene atributos de las etiquetas personalizadas adicionales, entonces obedece a las directivas de los atributos personalizados, y une las piezas de entrada o salida de la página a un modelo representado por las variables estándar de JavaScript. Los valores de las variables de JavaScript se pueden configurar manualmente, o recuperados de los recursos JSONestáticos o dinámicos. AngularJS está construido en torno a la creencia de que la programación declarativa es la que debe utilizarse para generar interfaces de usuario y enlazar componentes de software, mientras que la programación imperativa es excelente para expresar la lógica de negocio.1 Este framework adapta y amplía el HTML tradicional para servir mejor contenido dinámico a través de un data binding bidireccional que permite la sincronización automática de modelos y vistas. Como resultado, AngularJS pone menos énfasis en la manipulación del DOM y mejora la testeabilidad y el rendimiento8.. Objetivos de diseño: ●. Disociar la manipulación del DOM de la lógica de la aplicación. Esto mejora la capacidad de prueba del código.. ●. Considerar a las pruebas de la aplicación como iguales en importancia a la escritura de la aplicación. La dificultad de las pruebas se ve reducida drásticamente por la forma en que el código está estructurado. 27.

(28) ●. Disociar el lado del cliente de una aplicación del lado del servidor. Esto permite que el trabajo de desarrollo avance en paralelo, y permite la reutilización de ambos lados.. ●. Guiar a los desarrolladores a través de todo el proceso del desarrollo de una aplicación: desde el diseño de la interfaz de usuario, a través de la escritura de la lógica del negocio, hasta las pruebas.. Angular sigue el patrón MVVM (Model View View-Model) de ingeniería de software y alienta la articulación flexible entre la presentación, datos y componentes lógicos. Con el uso de la inyección de dependencias, Angular lleva servicios tradicionales del lado del servidor, tales como controladores dependientes de la vista, a las aplicaciones web del lado del cliente. En consecuencia, gran parte de la carga en el backend se reduce, lo que conlleva a aplicaciones web mucho más ligeras8.. Postgresql PostgreSQL es una de las opciones más interesantes en bases de datos relacionales open-source. Michael Stonebraker inició el proyecto bajo el nombre Post Ingres a mediados de los 80’s con la idea de solucionar problemas existentes en las bases de datos en esa época. MySQL fue por mucho tiempo el motor más popular; pero hoy es propiedad de Oracle y esto limita su evolución. Es gratuito y libre, además de que hoy nos ofrece una gran cantidad de opciones avanzadas. De hecho, es considerado el motor de base de datos más avanzado en la actualidad. (Y Platzi tiene un Curso de PostgreSQL) Una característica interesante de PostgreSQL es el control de concurrencias multiversión; o MVCC por sus siglas en inglés. Este método agrega una imagen del estado de la base de datos a cada transacción. Esto nos permite hacer transacciones eventualmente consistentes, ofreciéndonos grandes ventajas en el rendimiento. En Postgres no se requiere usar bloqueos de lectura al realizar una transacción lo que nos brinda una mayor escalabilidad. También PostgreSQL tiene HotStandby. Este permite que los clientes hagan búsquedas (sólo de lectura) en los servidores mientras están en modo de recuperación o espera. Así podemos hacer tareas de mantenimiento o recuperación sin bloquear completamente el sistema. _______________________ 8 Wikipedia (2017), Angular Js, recuperado el 14 de octubre del 2017, en https://es.wikipedia.org/wiki/AngularJS. 28.

(29) Algunas de sus principales características son, entre otras9: ● Alta concurrencia Mediante un sistema denominado MVCC (Acceso concurrente multi versión, por sus siglas en inglés) PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una visión consuntiva. ● Amplia variedad de tipos nativos PostgreSQL provee nativamente soporte para: Números de precisión arbitraria. Texto de largo ilimitado. Figuras geométricas (con una variedad de funciones asociadas). Direcciones IP (IPv4 e IPv6). Bloques de direcciones estilo CIDR. Direcciones MAC. ● Arrays. ●. Adicionalmente los usuarios pueden crear sus propios tipos de datos, los que pueden ser por completo indexables gracias a la infraestructura GiST de PostgreSQL. Algunos ejemplos son los tipos de datos GIS creados por el proyecto PostGIS.. Node.js Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación ECMAScript, asíncrono, con I/O de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google. Fue creado con el enfoque de ser útil en la creación de programas de red altamente escalables, como por ejemplo, servidores web. Fue creado por Ryan Dahl en 2009 y su evolución está apadrinada por la empresa Joyent, que además tiene contratado a Dahl en plantilla. Dentro de sus características encontramos: •. Concurrencia: Node.js funciona con un modelo de evaluación de un único. _______________________ 9 Wikipedia (2017), Angular Js, recuperado el 14 de octubre del 2017, en https://platzi.com/blog/que-es-postgresql/. 29.

(30) hilo de ejecución, usando entradas y salidas asíncronas las cuales pueden ejecutarse concurrentemente en un número de hasta cientos de miles sin incurrir en costos asociados al cambio de contexto. Este diseño de compartir un único hilo de ejecución entre todas las solicitudes atiende a necesidades de aplicaciones altamente concurrentes, en el que toda operación que realice entradas y salidas debe tener una función callback. ● V8: es el entorno de ejecución para JavaScript creado para Google Chrome. Es software libre desde 2008, está escrito en C++ y compila el código fuente JavaScript en código de máquina en lugar de interpretarlo en tiempo real. Node.js contiene libuv para manejar eventos asíncronos. Libuv es una capa de abstracción de funcionalidades de redes y sistemas de archivo en sistemas Windows y sistemas basados en POSIX como Linux, Mac OS X y Unix. El cuerpo de operaciones de base de Node.js está escrito en JavaScript con métodos de soporte escritos en C++. ● Módulos: Node.js incorpora varios "módulos básicos" compilados en el propio binario, como por ejemplo el módulo de red, que proporciona una capa para programación de red asíncrona y otros módulos fundamentales, como por ejemplo Path, FileSystem, Buffer, Timers y el de propósito más general Stream. Es posible utilizar módulos desarrollados por terceros, ya sea como archivos ".node" pre compilados, o como archivos en javascript plano. Los módulos Javascript se implementan siguiendo la especificación CommonJS para módulos,8 utilizando una variable de exportación para dar a estos scripts acceso a funciones y variables implementadas por los módulos.9 Los módulos de terceros pueden extender node.js o añadir un nivel de abstracción, implementando varias utilidades middleware para utilizar en aplicaciones web, como por ejemplo los frameworks connect y express. Pese a que los módulos pueden instalarse como archivos simples, normalmente se instalan utilizando el Node Package Manager (npm) que nos facilitará la compilación, instalación y actualización de módulos así como la gestión de las dependencias. ● Desarrollo homogéneo entre cliente y servidor: puede ser combinado con una base de datos documental (por ejemplo, MongoDB o CouchDB) y JSON lo que permite desarrollar en un entorno de desarrollo JavaScript 30.

(31) unificado. Con la adaptación de los patrones para desarrollo del lado del servidor tales como MVC y sus variantes MVP, MVVM, etc. Node.js facilita la reutilización de código del mismo modelo de interfaz entre el lado del cliente y el lado del servidor. Puntos de caso de uso El método de Punto de Caso de Uso (UCP – Use Case Point), está basado en los tradicionales Puntos Función. Es un método originado de la tesis de master de Gustav Karner (Karner, 1993), desarrollada mientras trabajaba en Objectory AB, bajo supervisión de Ivar Jacobson (creador de los casos de uso)10. Ilustración 5: Pasos básicos en el método de estimación Puntos Caso de Uso. Fuente: http://233gradosdeti.com/articulos/metodo-de-estimacion-de-puntos-de-caso-de-uso/. Cálculo de los Puntos Caso de Uso sin ajustar (UUCP – UNADJUSTED USE CASE POINTS) •. Clasificar cada interacción entre actor y caso de uso según su complejidad y asignarle un peso: Para clasificar la complejidad de los actores se debe determinar la forma en la que cada actor interactúa con el sistema que se va a desarrollar. En concreto, los actores se clasifican en 3 categorías diferentes, simple, medio y complejo. Un actor simple. _______________________ 10 Garzas, Javier (2016), Método de estimación de Puntos de Caso de Uso, recuperado el 14 de octubre del 2017, en http://233gradosdeti.com/articulos/metodo-de-estimacion-de-puntos-de-caso-de-uso/. 31.

(32) representa otro sistema con una API definida, un actor medio es otro sistema que interactúa a través de un protocolo como por ejemplo TCP/IP o es una persona interactuando a través de una interfaz por línea de comandos, y un actor complejo interactúa a través de una interfaz gráfica.Una vez clasificado cada actor según su tipo de interacción, se le asigna el peso correspondiente asociado a dicha interacción. En la Tabla 1, se presenta un resumen del procedimiento de clasificación de los actores. Tabla 2: Clasificación de los actores. Tipo de interacción Simple (a través de una API) Medio (a través de un protocolo) Complejo (a través de una interfaz gráfica). Peso 1 2 3. Fuente: http://233gradosdeti.com/articulos/metodo-de-estimacion-de-puntos-de-caso-de-uso/. •. Calcular la complejidad de cada caso de uso según el número de transacciones o pasos del mismo: Para realizar el cálculo de la complejidad de un caso de uso se debe determinar el número de transacciones, incluyendo los caminos alternativos. Una transacción es un conjunto de actividades atómicas, donde se ejecutan todas ellas o ninguna. En este contexto, cada caso de uso se debe clasificar en una de las siguientes categorías: “simple”, “medio” o “complejo”. En concreto, un caso de uso simple tiene 3 o menos transacciones, un caso de uso medio de 4 a 7 transacciones, y un caso de uno complejo más de 7 transacciones. Una vez clasificado cada caso de uso, según el número de transacciones, se le asigna el peso asociado a dicho número de transacciones. En la Tabla 2 se presenta un resumen del procedimiento de clasificación de los casos de uso. Tabla 3: Clasificación de los casos de uso. Tipo de caso de uso Simple Medio Complejo. Número de transacciones 3 o menos De 4 a 7 7 o más. Peso 5 10 15. Fuente: http://233gradosdeti.com/articulos/metodo-de-estimacion-de-puntos-de-caso-de-uso/. 32.

(33) •. Calcular los Puntos Caso de Uso no ajustados (UUCP – Unadjusted Use Case Points): Los UUCP se calculan sumando la dificultad de las interacciones y la complejidad de los casos de uso, es decir, sumando el total de los pesos de los actores (clasificados en el paso 1) y el total de los pesos para los casos de uso (clasificados en el paso 2). Ejemplo: 2 interacciones por Web: 2 * 3 = 6 4 UCP complejos: 4 * 3 = 12 UUCP = 6 + 12 = 18. Cálculo de los factores técnicos (TCF) Para ajustar los UUCP (Puntos Caso de Uso no ajustados) calculados en los pasos anteriores, se deben tener en cuenta factores de ajuste, tanto factores técnicos, como factores de entorno. En el caso de los factores técnicos (TCF), a cada factor definido en la Tabla 3 (Ri) se le asigna un valor entre 0 y 5, dependiendo de su influencia en el proyecto. En este sentido, asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3 es promedio y un valor 5 significa que el factor es esencial. Una vez que todos los factores técnicos tienen asignado el valor de la influencia, se procede al cálculo de los resultados de cada factor, es decir, se realiza una multiplicación entre la influencia del factor y su peso asociado, ver en la Tabla 3 la columna “Resultado”. Cuando se han calculado los resultados de cada uno de los factores técnicos, se aplica la expresión descrita a continuación, donde el sumatorio se corresponde a la suma de los resultados de los factores técnicos. TCF= 0,6 + (0,01 * Sumatorio).. 33.

(34) Tabla 4: Cálculo de factores técnicos. Actor T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13. Descripción Sistema distribuido. Objetivos de performance o tiempo de respuesta. Eficiencia del usuario final. Procesamiento interno complejo. El código debe ser reutilizable. Facilidad de instalación. Facilidad de uso. Portabilidad. Facilidad de cambio. Concurrencia. Incluye objetivos especiales de seguridad. Provee acceso directo a terceras partes. Se requiere facilidades especiales de entrenamiento a usuario.. Peso 2 1 1 1 1 0.5 0.5 2 1 1 1 1 1. Fuente: https://es.wikipedia.org/wiki/Puntos_de_caso_de_uso. Cálculo de los factores de entorno (EF) Además de tener en cuenta los factores técnicos para el ajuste de los UUCP (Puntos Caso de Uso no ajustados), en segundo lugar se deben contabilizar los factores de entorno. Para ello, a cada factor de entorno definido en la Tabla 4 (Ri) se le asigna un valor entre 0 y 5 dependiendo de su influencia en el proyecto. Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3 es promedio y un valor 5 significa que el factor es esencial. Una vez que todos los factores de entorno tienen asignado el valor de la influencia, se procede al cálculo de los resultados de cada factor, es decir, se realiza una multiplicación entre la influencia del factor y su peso asociado, ver en la Tabla 4 la columna “Resultado”. Cuando se han calculado los resultados de cada uno de los factores, se aplica la expresión descrita a continuación, donde el sumatorio se corresponde a la suma de los resultados de los factores de entorno. EF= 1,4 + (- 0,03 * Sumatorio).. 34.

(35) Tabla 5: Peso factores de entorno o ambientales. Factor E1 E2 E3 E4 E5 E6 E7 E8. Descripción Familiaridad con el modelo de proyecto utilizado. Experiencia en la aplicación. Experiencia en orientación a objetos. Capacidad del analista líder. Motivación. Estabilidad de los requerimientos Personal part-time Dificultad del lenguaje de programación. Peso 1.5 0.5 1 0.5 1 2 -1 -1. Fuente: https://es.wikipedia.org/wiki/Puntos_de_caso_de_uso. Cálculo de los puntos de caso de uso ajustados (UCP) Finalmente, para obtener los Puntos Caso de Uso fajustados (UCP) se utilizan los datos obtenidos en los pasos anteriores, Puntos Caso de Uso fno ajustados (UUCP) y factores de ajuste (TCF y EF), haciendo uso de la expresión que se presentan a continuación. UCP = UUCP * TCF * EF Se debe tener en cuenta que a través del cálculo de esta expresión obtenemos una estimación del tamaño y no del esfuerzo. Estimación del esfuerzo Como ocurre en otros métodos de estimación, una vez obtenido el tamaño, se puede obtener el esfuerzo. Para ello, se utiliza la siguiente expresión: Esfuerzo = UCP * Factor de Productividad El método originario propone usar un factor de ajuste (Factor de Productividad) similar al que se usa en el método de Puntos Función clásico, si bien Karner propone concretamente 20 personas – hora por cada Punto Caso de Uso (UCP). Otras propuestas son las de Barnerjee que propone un rango entre 15 y 30 horas, o la de Scheider y Winters, que sugiere un refinamiento de los factores de entorno (EF), en concreto, proponen seguir el procedimiento que se presenta a continuación: Contar los factores de entorno entre T1 y T6 cuya influencia es inferior a 3 (influencia promedio) y los factores de entorno entre R7 y R8 que son superiores. 35.

(36) a 3. Ver Entonces:. “factores. de. entorno”. en. la. Tabla. 4,. pág.. 5.. 20 horas-hombre por UCP si el valor es =2 28 horas-hombre por UCP si el valor es =4 36 horas-hombre por UCP si el valor es =5, en este caso se debería replantear el proyecto. Se debe destacar, que el valor del esfuerzo estimado, calculado mediante la expresión presentada anteriormente, no cubre todas las fases del ciclo de vida del proyecto, sino que se refiere únicamente a las horas-hombre invertidas en el desarrollo de la funcionalidad especificada en los casos de uso (fase de codificación). La fase de codificación representa generalmente un 40% del esfuerzo total del proyecto (ISBSG, 2005; Wikipedia, 2009). En este sentido, para obtener el esfuerzo total del proyecto, se puede realizar un nuevo ajuste que consiste en sumar a la estimación de esfuerzo obtenida por UCP, las estimaciones de esfuerzo de las demás actividades relacionadas con el desarrollo del software, que se pueden distribuir de la siguiente forma: análisis 10%, diseño 20%, codificación 40%, pruebas 15% y sobrecarga 15%. 1.8.2. Marco metodológico El ciclo de Deming (de Edwards Deming), también conocido como círculo PDCA (del inglés plan-do-check-act, esto es, planificar-hacer-verificar-actuar), es una estrategia de mejora continua de la calidad en cuatro pasos, basada en un concepto ideado por Walter A. Shewhart. Es muy utilizado por los sistemas de gestión de la calidad (SGC) y los sistemas de gestión de la seguridad de la información (SGSI)11. Los resultados de la implementación de este ciclo permiten a las empresas una mejora integral de la competitividad, de los productos y servicios, mejorando continuamente la calidad, reduciendo los costos, optimizando la productividad, reduciendo los precios, incrementando la participación del mercado y aumentando la rentabilidad de la empresa u organización. Este ciclo es de fácil aplicación, por lo cual se adapta a la forma en la que se necesitan trabajar cada una de las actividades en el desarrollo de este proyecto: planificación, se establecen los objetivos o lo que se pretende hacer en el proyecto; hacer, consiste en la implementación de las acciones necesarias para realizar lo que se planeó; verificar, si lo que hacemos corresponde a lo 36.

(37) planificado; actuar, corregir lo que no resulto de acuerdo a lo planeado y tomar las medidas necesarias.. ¿Qué es planificar? Es donde se establecen objetivos y se identifican los procesos necesarios para lograr unos determinados resultados de acuerdo a las políticas de la organización. En esta etapa se determinan también los parámetros de medición que se van a utilizar para controlar y seguir el proceso. En esta etapa, es importante plasmarse las 7 preguntas claves, cuyas palabras en inglés empiezan con W y H (modelo 5W + 2H): ● ¿Qué se debe hacer? ● ¿Por qué se va a hacer? Razones que justifican por qué se va a realizar lo que se va a hacer. ● ¿Cómo lo voy a hacer? (actividades que permiten alcanzar los objetivos). ● ¿Cuándo se va a realizar? (cronograma de actividades). ● ¿Dónde se va a hacer? ● ¿Quién lo va a hacer? ● ¿Cuánto vale hacerlo? (recursos necesarios para la ejecución de cada actividad). Respondiendo las preguntas anteriores, permite planear de forma ordenada y siempre los elementos necesarios para el desarrollo del plan (objetivos y como lograrlos). Si se cuenta con una buena planificación, se dará paso a una correcta ejecución y verificación.. ¿Qué es la ejecución? Consiste en la implementación de los cambios o acciones necesarias para lograr las mejoras planteadas. Con el objeto de ganar en eficacia y poder corregir fácilmente posibles errores en la ejecución, normalmente se desarrolla un plan piloto a modo de prueba o testeo12.. _______________________ 11 (2017) Circulo de Deming, recuperado el 14 de octubre del 2017, https://es.wikipedia.org/wiki/C%C3%ADrculo_de_Deming 12 (2015) ¿En qué consiste el ciclo PHVA de mejora continua?, recuperado el 14 de octubre del 2017, https://www.isotools.org/2015/02/20/en-que-consiste-el-ciclo-phva-de-mejora-continua/. 37.

(38) ¿Qué es la verificación? Una vez se ha puesto en marcha el plan de mejoras, se establece un periodo de prueba para medir y valorar la efectividad de los cambios. Se trata de una fase de regulación y ajuste. En esta etapa se pueden aparecer 3ciclos: ● Ciclo de mantenimiento: Si lo que hacemos, si corresponde a lo planeado, es el momento de estabilizar el proceso, es importante definir claramente que hacemos, capacitar a la gente, definir los métodos, los mecanismos de operación y control y que sean claramente entendidos por la gente. ● Ciclos de corrección: Lo que se hace cuando lo que estaba previsto, no corresponde a lo planeado. Comprende dos tipos de acciones: la corrección, es decir, corregir el problema en ese instante; y la acción correctiva: hacer para que el problema no vuelva a ocurrir. ● Ciclo de mejoramiento: Pasado un cierto tiempo, en mis procesos debo pensar en qué puedo hacer para mejorar lo planeado. Aquí se pueden generar ideas, tratar de buscar datos, el ver un análisis de la competencia, el ver las potenciales tendencias, y determinar oportunidades de mejora. Esto corresponderá las acciones preventivas, me lleva un análisis de riesgos, y al mejoramiento continuo. Todo lo que hemos hecho en este tercer ciclo, debemos incorporar el nuevo ciclo en mi etapa del planear. Empieza entonces, a girar permanentemente el planear, hacer, verificar, actuar. ¿Dónde se puede utilizar este ciclo? En todas las operaciones y actividades diarias, podemos utilizarlo en la gerencia, empezando desde la parte de planificación estratégica, podemos utilizarlo en cada uno de los procesos que como organización ejecutamos. Podemos utilizarlo en nuestra gestión de recursos humanos, podemos hacerlo aún en las actividades del mejoramiento: qué mejoramiento planteamos, qué es lo que hemos hecho en las etapas de mejoramiento, verificar si corresponde a lo planeado para actuar para corregir o actuar para mejorar. Un ciclo constante de planear, hacer, verificar, actuar, será un ciclo que produce el mejoramiento en todos los rincones de la organización; a nivel personal, a nivel empresarial, a nivel aún familiar. Para finalizar debo preguntarme: ¿Qué hemos planificado el día de hoy, ¿qué hemos ejecutado, hemos verificado si lo que hicimos corresponde a lo planeado, ¿cómo vamos a actuar para corregir, o cómo vamos a actuar para mejorar?. 38.

(39) ¿Qué es actuar? Realizadas las mediciones, en el caso de que los resultados no se ajusten a las expectativas y objetivos predefinidos, se realizan las correcciones y modificaciones necesarias. Por otro lado, se toman las decisiones y acciones pertinentes para mejorar continuamente el desarrollo de los procesos.. 39.

(40) 1.9.. Cronograma de actividades Ilustración 6: Cronograma. Fuente: Propia. 40.

(41) 1.10. Propuesta metodológica Con la implementación de esta metodología, se buscó dar un mejoramiento al proceso de estimación de esfuerzo y tiempo que realiza la empresa para los proyectos de software, de esta forma, se puede optimizar dicha actividad y generar así una respuesta mucho más rápida a los clientes que tiene la compañía. Dentro de la propuesta, se busca implementar un sistema telemático que realice la estimación bajo el método de Puntos de Casos de uso. Dentro de las características del ciclo de mejoramiento PHVA, se ha encontrado lo siguiente:. PLANEAR: ● Fijar el alcance del sistema por medio de la recolección de la información disponible, en torno al método de estimación de esfuerzo por puntos de caso de uso. ● Determinar los procesos y lineamientos sobre los cuales se desarrollará el sistema de estimación. ● Análisis de las herramientas y tecnologías a usar para el desarrollo del sistema telemático. ● Identificar si los procesos satisfacen la necesidad a solucionar. ● Desarrollar el plan para el desarrollo del sistema propuesto. HACER •. •. Diseñar el proceso para estimación de esfuerzo y tiempo de software acorde a las necesidades de la empresa, implementando el método de estimación Puntos de casos de uso. Elaborar un prototipo el cual busca apoyar la actividad de estimación.. VERIFICAR ● Analizar el resultado obtenido en el desarrollo del sistema propuesto, de acuerdo al alcance y procesos fijados, con ello se podrá identificar si se ha cumplido con el resultado deseado. ● Identificar posibles desviaciones apoyándose en la verificación que haga Bits Américas S.A.S. ● Revisar los problemas y errores surgidos en el desarrollo del sistema telemático e identificar qué se aprendió de ellos. 41.

(42) ACTUAR •. Tomar acciones para mejorar el desempeño del proceso.. 42.

(43) 2. Análisis, diagnóstico y levantamiento de requerimientos En esta fase se lleva a cabo la captura y análisis de la necesidad que tiene la empresa BITS Américas S.A.S en cuanto al problema de estimación de proyectos de desarrollo de software, para ello se pretende hacer un levantamiento de requerimientos que ayude a especificar y comprender el propósito esperado para el sistema.. 2.1.. Descripción. BITS Américas S.A.S fue fundada en el año 2008 en Colombia, bajo el concepto de proporcionar Desarrollo de Software a la Medida y soluciones basadas en sitios Web para las empresas. La empresa, se ha consolidado en tres grandes líneas de negocio: Desarrollo de software a la medida, IT service y Soporte de sitios web. A su vez, la compañía ha logrado incursionar en diferentes segmentos de mercado tanto en Colombia como internacionalmente en países como Guatemala, Salvador, Costa Rica, Honduras, Bolivia, Paraguay y Uruguay, Ghana, Tanzania, Chad, Rwanda, Congo y Senegal.. 2.1.1. Portafolio de servicios Dentro de los servicios que ofrece BITS Américas a sus clientes se encuentra: ● Diseño y desarrollo de software basados en páginas web apoyando el Desarrollo web con Drupal y Desarrollo web con .Net. ● IT services: consultoría y asesoría en TI, pruebas (Testing), monitoreo y mantenimiento de software web para garantizar la calidad, eficiencia y funcionalidad de los sistemas de información.. ● Soporte a sitios web: soporte a sitios web con el fin de ayudar a mejorar los procesos TI, con la identificación oportuna. 2.2.. Análisis. Al estar en contacto con el área de TI de la empresa, por medio de trabajo directo con ellos, se observó que el proceso de estimación de software se realiza de las siguientes formas:. 43.

(44) ● Estimación por analogía: se realiza una comparación del proyecto que se va a tratar con proyectos similares finalizados por la empresa en el pasado, se toman datos históricos y donde la información coincida para poder estimar (esto generalmente lo realiza una persona del área comercial). ● Criterio de experto: se consultan a varios expertos por lo general arquitectos, líderes de desarrollo o líderes de proyectos, los cuales usan su experiencia y entendimiento del proyecto para lograr realizar la estimación. Ambos procesos, se nutren en su gran mayoría, de documentos de alto nivel realizados por personas que no cuentan con un dominio o conocimiento en la ingeniería de software, en los que se puede encontrar información no muy específica. Para realizar la estimación, no se observó un método o herramienta estándar que facilite la medición del tamaño del software, por ello se hace dificultoso, tener un valor aproximado al real en donde el desface sea pequeño, como consecuencias negativas se tienen perdidas económicas y mala relación con clientes, por este motivo se requiere implementar un método sistematizado que permita estimar de forma fácil y rápida.. 2.3.. Diagnostico. El desarrollo del proyecto se emprendió con una vista de la forma en la que se estima el software por cada una de las áreas implicadas en la empresa para esta actividad, enfocándose principalmente en Comercial y en TI (arquitectos, líderes de desarrollo y de proyectos) con el objetivo de tener clara la forma en la que se realiza el proceso dentro de la compañía. Las actividades identificadas fueron: a. Se remite al líder de proyectos un caso interno el cual contiene la información que se ha obtenido hasta el momento en un documento (por lo general un documento de alto nivel o blueprint). b. El caso interno se asigna a alguna persona idónea dentro del área de TI para que revise el documento de requisitos recibido. c. La persona quien tiene el caso realiza el análisis del documento que se encuentra en el caso interno y con base a este identifica el alcance del proyecto de software. d. Una vez identificado el alance del proyecto de software se diligencia el formato de estimación respectivo, dicho formato es un archivo en Excel. 44.

(45) Nota: Si la información del documentó proporcionado es insuficiente, se debe solicitar más información por medio del gestor del área comercial y se retorna a “b” una vez se recibe la nueva información. e. El arquitecto o líder de desarrollo, revisa documento de estimación y si es necesario ajusta el valor obtenido de acuerdo a su juicio de experto y asigna caso interno a gestor comercial. De la observación, algunas de las posibles casusas identificadas que están afectado el proceso fueron las siguientes: ● Deficiencia en una metodología o lineamientos adecuados para la estimación. ● En la estimación no siempre participan expertos para dar su opinión acerca de la complejidad del proyecto a desarrollar, casi siempre la actividad la hace una persona del área comercial. ● Competencia con otras empresas proveedoras, esto hace que las propuestas de BITS Américas deban ser rápidas, para ello se conforman únicamente con el documento de alto de nivel o el planteamiento de los requisitos que se haga por parte del cliente, que en la mayoría de ocasiones no sabe lo que necesita con claridad, o ha tomado mal los requisitos. ● No se tiene en cuenta la curva de aprendizaje del equipo técnico (analistas, desarrolladores backend, desarrolladores front) tanto en las tecnologías a usar como en la regla de negocio del proyecto. ● Comparación de proyectos pasados con los nuevos, y todos los proyectos no son iguales. ● Dificultades en la definición del alcance del proyecto, por lo cual no puede percibirse claramente el tamaño de este.. 45.

(46) 3. Requisitos, elementos y restricciones el sistema En esta etapa, se evalúan los principales requisitos, características y restricciones del sistema telemático, esto en busca de mejorar el proceso de estimación de software de la empresa.. 3.1.. Requisitos. De acuerdo con la observación de la actividad de estimación que se realiza en la compañía, se identificaron los siguientes requisitos:. 46.