METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL

Transcripción

1 ! METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA INFORMACIÓN MARCO ANTONIO RIBÓ COLELLA PROFESOR GUÍA: CECILIA BASTARRICA MIEMBROS DE LA COMISIÓN: LUIS GUERRERO BLANCO AGUSTÍN VILLENA MOYA MARCELLO VISCONTI ZAMORA SANTIAGO DE CHILE AGOSTO 2009

2 RESUMEN DE LA TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA INFORMACIÓN POR: MARCO ANTONIO RIBÓ COLELLA PROF. GUIA: CECILIA BASTARRICA METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL Esta tesis busca elaborar para una empresa PYME que construye software para la industria de RETAIL, una metodología que permite definir un modelo de proceso para el desarrollo de software de calidad, como también permita evaluar y demostrar que el proceso metodológico respalda el crecimiento organizacional. FIDCOM tiene una perspectiva y apuesta de crecimiento para el mediano plazo focalizada en el mercado Latinoamericano. Para ello ha diseñado un plan de expansión y éste debe estar soportado por productos de calidad e innovadores. Sin embargo, se han detectado algunos problemas recurrentes en el proceso de desarrollo de software, tales como: recursos limitados, mantenciones crecientes, desarrollos a última hora y requisitos incumplidos. Se elaboró entonces una metodología que permite contar con un proceso definido y de mejoramiento continuo que guía a FIDCOM en la obtención de productos de calidad mediante un proceso de calidad, respaldando así su crecimiento organizacional. Esta metodología está basada en las buenas prácticas de la industria y estándares definidos, con el fin de aplicarla internamente. Para esto, se realizó la evaluación interna de las capacidades del proceso de desarrollo a la luz de las prioridades de la industria de Retail, y se ha puesto en marcha la metodología de desarrollo de software, potenciando las fortalezas y apoyando a FIDCOM en su apuesta de crecimiento regional. Se ha realizado una adaptación de la metodología UP, por tratarse de una metodología de desarrollo de software orientada a conducir el proceso de desarrollo de forma eficaz, basada en un conjunto de buenas prácticas probadas en la industria del software, y muchas de las cuales son conocidas dentro de FIDCOM. El trabajo se inició con un diagnóstico de la empresa en general y un análisis de los procesos de implantación de software de POS. También se realizó la implantación en FIDCOM y su posterior evaluación de resultados obtenidos. La evaluación de resultados fue basada en el crecimiento organizacional y la mejora en calidad de software. La medición del crecimiento organizacional se determina en base al crecimiento permanente obtenido en: ventas, clientes, empleados, proyectos y productos. Adicionalmente, se demuestra que la percepción de la obtención de productos de calidad por parte de los clientes ha mejorado en un periodo de 12 meses. Por lo tanto, los resultados permiten comprobar que la metodología implantada resuelve los problemas enunciados, permitiendo obtener productos de mejor calidad, como también se sustenta el crecimiento organizacional planeado. "

3 Dedicado a mi madre, María Mercedes Colella Rodríguez. Por su soporte ilimitado y total en mi desarrollo personal. Dedicado a mi compañera y madre de mis hijos, Lorena Adriana Valenzuela Gambi. Por su apoyo incondicional, absoluto y necesario en el cumplimiento de mis metas profesionales. #

4 CONTENIDO 1 Introducción Objetivos Objetivo General Objetivos Específicos Procedimiento General de Trabajo Etapa de Recopilación y Análisis de Información Etapa de Evaluación del Proceso de FIDCOM a la Luz de la Información Etapa de Propuesta de una Metodología Etapa de Evaluación de la Metodología Etapa de Retroalimentación Cliente y Conclusiones Marco Conceptual Proceso Unificado de Desarrollo de Software Fase de Inicio en UP Fase de Elaboración en UP Fase de Construcción en UP Fase de Transición en UP Organización de Disciplinas según UP Marco de Desarrollo del UP Conceptos Claves en UP Iterativo e Incremental Centrado en la Arquitectura Conducido por los Casos de Uso Enfocado al Riesgo Retail Software y Servicios para Retail Software de Calidad FIDCOM $

5 4 Definición del Problema Problema Por qué UP es un buen Punto de Partida? Por qué No usar UP tal cual? Qué cosas de UP se mantienen tal y como están definidas en el modelo? Cuáles son las Adaptaciones Necesarias? Ámbito de Adaptación Adaptaciones a las Fases de UP Metodología Desarrollo de Software para FIDCOM Descripción de Metodología para FIDCOM Fases de Proyecto para FIDCOM Procedimiento General de implementación para FIDCOM Diagrama General Descripción de actividades por Fases Evaluación de la Propuesta Metodológica Aplicada para FIDCOM Identificación de Variables Evaluación del Crecimiento Organizacional Evaluación de la Calidad de Software El Cuestionario de Calidad de Software Aplicación Cuestionario a Clientes Análisis de Resultados del Cuestionario a Clientes Evaluación a la Resolución de Problemas Recurrentes en Desarrollo Conclusiones y Proyecciones Conclusiones Punto de Vista Conceptual Punto de Vista Personal Punto de Vista Metodológico Punto de Vista de Negocio %

6 8.2 Proyecciones Comentarios Finales Condiciones de Implementación Riesgos a Considerar Limitaciones Observadas Anexo 1 Definición de Roles de Implementación Anexo 2 Definición de Artefactos de Implementación Referencias &

7 Ilustraciones Ilustración 3-1 Fases y Disciplinas según UP Ilustración 3-2 Representación Proceso Iterativo e Incremental Ilustración 5-1 Conceptualización Metodología para FIDCOM Ilustración 6-1 Procedimiento General para FIDCOM Tablas Tabla 1 - Artefactos de UP y Evolución Temporal Tabla 2 - Problemas Recurrentes en Desarrollo Tabla 3 - Comparativo de UP y Metodología para FIDCOM Tabla 4 - Adaptaciones de UP para FIDCOM Tabla 5 - Fases de Proyecto para FIDCOM Tabla 6 - Actividades por Fase Tabla 7 - Definición y Análisis de Variables de Valor en FIDCOM Tabla 8 - Evaluación del Crecimiento Organizacional en FIDCOM Tabla 9 - Cuestionario según atributos de Calidad de Software Tabla 10 - Resultados Aplicación del Cuestionario de Calidad a Clientes FIDCOM Tabla 11 - Roles de Implementación Tabla 12 - Artefactos de Implementación '

8 1 Introducción FIDCOM es una empresa PYME líder en su rubro que desarrolla software y servicios en el ambiente de Retail. Desarrolla software para Puntos de Venta, cuenta con un poco más de 10 años de experiencia y presencia en el mercado, ventas por US$3,2 millones, 45 empleados y de los cuales 65% del personal se encuentra en las áreas técnicas, un 20% en el área comercial y un 15% en Administración y Finanzas. Tiene una estructura muy plana, 3 niveles jerárquicos (socios, gerentes y colaboradores). Su perspectiva y apuesta de crecimiento para mediano plazo está focalizada en el mercado Latinoamericano. Para ello ha diseñado un plan de expansión y este debe estar soportado por productos de calidad, innovadores y oportunos. La metodología de trabajo usada para el desarrollo de software es no estructurada y flexible, soportada en el alto conocimiento y compromiso de cada uno de sus integrantes en la organización. En base a la recopilación de información, en la industria Retail, calidad de software se entiende como: gran flexibilidad de los proveedores de abordar requerimientos muchas veces difusos, el nivel de conocimiento del ámbito donde se desenvuelven, la entrega de soluciones sin defectos, la entrega de soluciones a tiempo, los tiempos de respuesta de los servicios de soporte en el menor tiempo posible y la amplia capacidad de cobertura horaria para sus demandas de servicios especializados. FIDCOM se encuentra con algunos problemas recurrentes en el proceso de desarrollo de software, tales como: recursos limitados, plazos sobrepasados, tiempos que no se cumplen, mantenciones crecientes, desarrollos a última hora, requisitos ambiguos, incompletos, no definidos y no cumplidos. Esto es una fuente de conflicto permanente en los Retailers, como también es fuente de insatisfacción de los integrantes de FIDCOM y conflicto interno de los equipos de desarrollo. FIDCOM no cuenta con una metodología de trabajo formalmente establecida. Se desea entonces desarrollar una metodología que permita contar con un proceso definido y de mejoramiento continuo que guíe a FIDCOM en la obtención de productos de calidad mediante un proceso de calidad. Con respecto a la calidad en las diversas industrias y, también en la del Retail, existen varios determinantes que contribuyen a la calidad de los productos y servicios de software, donde los orígenes posibles provienen de distintos aspectos de metodología, procesos y/o personas. Los procesos tienen una incidencia significativa en la calidad, y existe una alta correlación entre calidad de proceso y calidad de producto [6]. Por lo tanto, se puede inferir que para mejorar el producto se debe mejorar el proceso. Al mejorar el proceso la empresa responde a la necesidad de tener una guía para mejorar cada una de las etapas en el desarrollo y mantenimiento del software, así como también los servicios asociados, permitiendo la entrega de soluciones sin defectos, a tiempo y disminuyendo la dependencia de los recursos humanos. Es por esto que en FIDCOM se realizó la evaluación interna de las capacidades del proceso de desarrollo a la luz de las prioridades de la industria de Retail, y se puso en marcha una metodología de desarrollo de software (

9 que solucionó los problemas encontrados, potenciando las fortalezas y apoyando a FIDCOM en su apuesta de crecimiento a nivel regional. Se ha realizado una adaptación de UP, por tratarse de una metodología de desarrollo de software orientada a conducir el proceso de desarrollo de forma eficaz, basada en un conjunto de buenas prácticas probadas en la industria del software, y muchas de las cuales son conocidas dentro de FIDCOM. En FIDCOM se implantó un proyecto piloto usando la metodología definida. En él se necesitó contar con un proceso de desarrollo de software adaptado a las necesidades de Retail, estandarizado, basado en las buenas prácticas y de mejoramiento continuo. Luego, se sometió a evaluación los resultados en base al crecimiento organizacional y el desarrollo de software de calidad. 2 Objetivos Los objetivos planteados para la presente tesis se dividen en: objetivo general y los objetivos específicos a cumplir, los cuales se describen en el plan definido a continuación. 2.1 Objetivo General Elaborar una metodología fruto de adaptar el Proceso Unificado (UP) para el desarrollo de software de calidad, con el fin de aplicarla en una Pequeña y Mediana Empresa que desarrolla software para la industria de Retail, con el fin de mejorar la calidad de sus productos y apoyar su desarrollo organizacional. 2.2 Objetivos Específicos Formalizar la descripción de los procesos de desarrollo de software aplicados actualmente en FIDCOM. Elaborar un diagnóstico de la empresa FIDCOM y el proceso de desarrollo de software de POS en el ambiente de Retail. Definir una adaptación de un proceso unificado de desarrollo de software, adaptado a la realidad específica de FIDCOM e intentando mejorar los defectos identificados. Evaluar los nuevos procesos planteados a la luz de las necesidades, la misión de FIDCOM y los clientes. 2.3 Procedimiento General de Trabajo El procedimiento general de trabajo definido principalmente para llevar a cabo el desarrollo de la presente tesis está dividido en las siguientes seis etapas: 1. Etapa de recopilación y análisis de información 2. Etapa de evaluación del proceso de FIDCOM a la luz de la información )

10 3. Etapa de adaptación de una metodología 4. Etapa de evaluación de la Metodología 5. Etapa de retroalimentación cliente y conclusiones Cada una de las etapas mencionadas en el procedimiento general de trabajo se describe a continuación Etapa de Recopilación y Análisis de Información Esta etapa se fundamenta en la recopilación y revisión de información de UP a la luz de las prácticas habituales de FIDCOM y las necesidades de Retail. Las actividades se realizan a través de cuestionarios, entrevistas y bibliografía referente a procesos de desarrollo de software en FIDCOM, software y servicios en Retail y la información referente a UP. Se recopila y analiza información de los siguientes temas: a) UP b) Software de Calidad en Retail c) Prácticas de FIDCOM El objetivo de esta etapa es contar con una base de información conceptual sólida para dar inicio a la evaluación y adaptación de la información recopilada Etapa de Evaluación del Proceso de FIDCOM a la Luz de la Información Esta etapa se dedicará principalmente a la evaluación y revisión de la información recopilada en la etapa de recopilación y análisis de información, necesaria para crear una base teórica que fundamente el proyecto. El objetivo de esta etapa es tener identificados los conceptos, flujos de trabajo UP, roles, responsabilidades y artefactos generados, y definir los procesos según lo hallado Etapa de Propuesta de una Metodología En esta etapa se define un proceso para FIDCOM, basado en UP, adaptado de acuerdo a las necesidades de FIDCOM y las necesidades del ambiente de Retail. Se realiza la adaptación, agregando y modificando flujos y artefactos de trabajo. El objetivo es terminar la etapa de propuesta de una metodología y contar con una adaptación de UP que define un modelo de proceso para el desarrollo de software de calidad en FIDCOM Etapa de Evaluación de la Metodología En esta etapa se entregarán los resultados de la evaluación efectuada en la organización sobre la estructura propuesta en la etapa anterior y se concluirá en base a las adaptaciones realizadas, como también con los resultados obtenidos. Esta etapa tiene como fundamento la evaluación del proyecto en realización y conclusión de los beneficios encontrados. *

11 El objetivo de esta etapa de evaluación tiene como resultado la entrega de las conclusiones al modelo de proceso en FIDCOM basado en la evaluación en un cliente específico Etapa de Retroalimentación Cliente y Conclusiones En esta etapa se realizará una evaluación de los resultados en un cliente donde se han desarrollado a lo menos dos proyectos de software durante el periodo de tiempo de seis meses. Esta etapa tiene como fundamento la evaluación del proyecto basado en información recopilada de FIDCOM y directamente desde un cliente. El objetivo de esta etapa de retroalimentación del cliente tiene como resultado el desarrollo, evaluación de los resultados y conclusiones del modelo en la implantación en un cliente de FIDCOM. "+

12 3 Marco Conceptual 3.1 Proceso Unificado de Desarrollo de Software La metodología de UP ([1], [4]) es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria. El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh [1]. UP divide el trabajo de desarrollo de software en cuatro fases: inicio, elaboración, construcción y transición, las cuales se describen a continuación Fase de Inicio en UP En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visión y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definición de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. También se define la viabilidad del proyecto Fase de Elaboración en UP En la fase de elaboración se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo central de la aplicación, la resolución de los riesgos más altos, la identificación de nuevos requisitos y nuevos alcances, y estimaciones más ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad técnica Fase de Construcción en UP La fase de construcción es la implementación iterativa del resto de los requisitos de menor riesgo y elementos más sencillos. Es la evolución hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la dirección del proyecto han acordado. La mayoría de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase Fase de Transición en UP Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado). ""

13 3.2 Organización de Disciplinas según UP El cuadro siguiente representa cada una de las disciplinas utilizadas en el proceso de desarrollo de software y su nivel de participación en cada una de las fases definidas de UP [4]. Ilustración 3-1 Fases y Disciplinas según UP. Las disciplinas identificadas son modelado de: negocios, requisitos, análisis, diseño, implementación y pruebas, como también se identifican las disciplinas de apoyo, tales como: configuración y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por UP. "#

14 3.3 Marco de Desarrollo del UP El cuadro siguiente resume las disciplinas del UP y sus artefactos asociados, indicando también, para las siguientes fases, el grado aproximado de desarrollo de cada uno de estos artefactos [1]. Tabla 1 - Artefactos de UP y Evolución Temporal Componentes del UP Fases Disciplina Artefactos Inicio Elaboración Construcción Transición Iteraciones: Modelado del Modelo del dominio C negocio Requerimientos Modelo de Casos de Uso Visión y Análisis del Negocio Especificación Complementaria Glosario C C C C R R R R Diseño Modelo de Diseño Documento de Arquitectura Modelo de Datos C C C R R Implementación Modelo de implementación C R R Gestión del Plan de desarrollo C R R R proyecto Pruebas Modelo de Pruebas C R Entorno Marco de desarrollo C R Donde: o o C = Comienzo de la construcción del artefacto. (Si un artefacto tiene sólo una C significa que se comienza y termina en la misma fase) R = Refinamiento del artefacto (ampliación, corrección). "$

15 3.4 Conceptos Claves en UP Iterativo e Incremental El desarrollo de software iterativo e incremental corresponde a mantener permanentemente un enfoque de cambio en los proyectos de desarrollo. Los llamados ciclos por fases intentan poner en manos del usuario un sistema con prestaciones parciales, que se va completando con nuevas prestaciones en fases sucesivas. Así, el usuario tiene en producción algunas funcionalidades mientras se van desarrollando las otras. Por lo tanto, existen entonces al menos dos sistemas funcionando en paralelo: 1) El sistema operacional o sistema en producción, en uso por el cliente. Puede ser una implementación parcial, una implementación anterior con funcionalidades nuevas o sustituidas, una implementación nueva con partes de la anterior u otra variante coherente. 2) El sistema en desarrollo (la siguiente versión) que está siendo preparada para reemplazar la versión en producción, que puede aún conservar partes de implementaciones anteriores o faltarle funcionalidades. La representación de un proceso iterativo e incremental se realiza en la siguiente ilustración. Ilustración 3-2 Representación Proceso Iterativo e Incremental. "%

16 Por consiguiente, el proceso de desarrollo incremental genera versiones comenzando con un subsistema funcional pequeño, al cual se le va agregando funcionalidad con cada versión. Sin embargo, el desarrollo iterativo entrega un sistema completo desde el principio, y luego cambia la funcionalidad de algún subsistema en cada nueva versión. Ambos enfoques pueden combinarse en un desarrollo iterativo e incremental [1]. También se considera que el desarrollo iterativo es un método de construcción de productos cuyo ciclo de vida está compuesto por un conjunto de iteraciones, las cuales tienen como objetivo entregar versiones del software. Cada iteración se considera un proyecto que genera productos de software y no sólo documentación, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso continuo de pruebas y de integración desde las primeras iteraciones. Algunas características a enunciar según UP son: 1. Los proyectos se organización en una serie de mini-proyectos cortos de duración (2 a 6 semanas), llamados iteraciones, que incluyen un conjunto reducido de requerimientos a implementar. 2. El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final. 3. Rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado de lo realizado en cada iteración. 4. Se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto riesgo. 5. Si no se logra cumplir lo previsto dentro del plazo estipulado, se aconseja transferir tareas o requisitos para una iteración posterior, pero no modificar la fecha de entrega de la iteración actual. Por lo tanto, el proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente Centrado en la Arquitectura El enfoque de desarrollo de software centrado en la arquitectura permite mejorar la comunicación entre las personas involucradas. Brinda documentación temprana acerca de las decisiones de diseño. Indica la estructura del software. Brinda una abstracción transferible del sistema. Hace explicitas las decisiones de diseño. La mayoría de los requisitos de calidad pueden ser alcanzados, sólo si son considerados desde la arquitectura Conducido por los Casos de Uso UP sigue el proceso de desarrollo conducido por casos de uso siendo una de las prácticas más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con "&

17 otros paradigmas de programación. Un caso de uso especifica el comportamiento de un sistema o una parte del mismo. Es una descripción de un conjunto de secuencias de acciones, donde cada secuencia representa la interacción de los elementos externos del sistema (sus actores) con el propio sistema (donde típicamente produce un resultado útil para los actores externos). Un caso de uso representa un requerimiento funcional del sistema [4] Enfocado al Riesgo UP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Un proceso es orientado por el riesgo cuando intenta identificar y definir estrategias para enfrentar los riesgos más graves del proyecto, resolviendo primero los puntos más difíciles, elaborando planes de contingencia y tratando de anticipar las dificultades [4]. 3.5 Retail Retail corresponde a la industria de venta de productos o mercaderías al detalle desde un lugar fijo tal como supermercados, tiendas departamentales, farmacias o kioscos, o también lugares pequeños de consumo [2]. Retail incluye servicios adicionales, tales como: despacho, ventas virtuales, y ventas no presenciales, entre otros. Los compradores pueden ser individuales o empresas. En la compra y venta un Retailer compra mercancías y/o servicios en grandes cantidades a fabricantes o importadores y los vende en pequeñas cantidades a usuarios finales. Los establecimientos de los Retailer son llamados tiendas, almacenes o locales, los cuales se concentran y generan cadenas de distribución [3]. El entorno de negocios de la industria de Retail ha evolucionado hacia un modelo más restrictivo en términos de márgenes de operación así como de mayores esfuerzos en la captación y fidelización de clientes. También, la mayor concentración y consolidación en el mercado masivo ha obligado a todos los jugadores a diferenciarse a través de ventajas competitivas que trasciendan la sola oferta de productos, tales como los servicios de valor agregado como medio para la creación de experiencias positivas en sus clientes a través de soluciones de punto de venta [2]. 3.6 Software y Servicios para Retail En Retail se requiere alta especialización en el desarrollo de software y servicios. El desarrollo de software se refiere a desarrollo de soluciones de punto de venta, y servicios para Retail corresponde al proceso de certificación e implantación en las tiendas. Algunas prácticas habituales y consideraciones en el proceso de desarrollo de software para soluciones de punto de venta son: 1) Desarrollos en cascada. A pesar de que la buena práctica en general es el desarrollo iterativo e incremental, lo cual se practica y se entrega por porciones. Se debe considerar que en RETAIL la funcionalidad completa no estará disponible al usuario final mientras no se encuentre con el 100% desarrollado. "'

18 2) Las implantaciones se realizan en locales o tiendas que atienden a público. Las implantaciones de software cubriendo todas las tiendas de los Retail son extensos y riesgosos. 3) Los periodos de seguimiento de una tienda piloto son cortos (1 a 2 semanas). En general, dados los requerimientos y lo extenso de las implantaciones no es posible extender mucho tiempo el seguimiento de tiendas pilotos. 4) El "time to market" es crítico, donde generalmente es un esfuerzo grande el implantar las tiendas, dado que se requiere de procesos de certificaciones internas y externas, capacitaciones de cajeros, operadores y administrativos. 3.7 Software de Calidad Algunas prácticas o postulados en el desarrollo de software son: existe una estrecha correlación entre la calidad del software y la calidad del proceso que lo produce; el software de la más alta calidad contiene mínima cantidad de errores es liberado en el plazo y dentro del presupuesto. Un proceso de desarrollo de la más alta calidad supone: supervisión, control, predictibilidad, es conocido por todos los involucrados, es medible, evaluable y mejorable. Nunca se debe cometer el mismo error: diseminar las mejores prácticas; aprender de la experiencia de los demás; apuntar hacia las causas de los errores [6]. Además el mejor proceso de desarrollo depende del tipo de proyecto que se debe desarrollar y las características particulares de la empresa. UP permite de forma eficaz el proceso de desarrollo de software. 3.8 FIDCOM FIDCOM es una empresa especializada en software para puntos de venta y soluciones tecnológicas para la industria del Retail Latinoamericano. Sus habilidades se basan en la especialización en la industria del Retail, conocimiento, compromiso con sus clientes, capacidad innovadora y gran disposición a asumir desafíos. Actualmente FIDCOM, cuenta con 45 profesionales enfocados a la industria del Retail, cuenta con laboratorios altamente completos, servicios con horarios y cobertura Retail (16x7), investigación y desarrollo con equipos multidisciplinarios. Además cuenta con oficinas con operaciones locales en Chile, Perú y Colombia. Las operaciones locales se enmarcan dentro de una definición de acercamiento a los clientes y sus mercados de origen, para proveer servicios y soluciones, siendo esta la forma de lograr el éxito en un mercado cada vez más competitivo y en crecimiento. FIDCOM mantiene alianzas con compañías de categoría mundial y regional para otorgar y traspasar a sus clientes productos y servicios íntegros con respaldo internacional. Las principales áreas de especialización de FIDCOM son: Desarrollo de Software, Consultoría, Servicios de Ingeniería y Servicios Operacionales. "(

19 Las soluciones FIDCOM se enmarcan en las distintas estrategias de sus clientes como son: crecimiento, consolidación, reducción de costos y competencias cruzadas, permitiendo la interacción con las diferentes áreas de la empresa (Finanzas, Comercial, Contraloría, Operaciones y Otras). Algunas de las herramientas FIDCOM que contribuyen a estos objetivos o estrategias son: 1. Software para complementar programas de fidelización de clientes. 2. Sistemas de promociones en los puntos de venta. 3. Sistemas de monitoreo para la gestión automatizada y centralizada de las tiendas. 4. Aplicaciones para la recepción y aprobación de pagos en línea. 5. Herramientas de software para utilización de terminales móviles. FIDCOM es una empresa PYME que desarrolla software en el ambiente de Retail y siempre necesita mejorar la calidad del software que entrega a sus clientes. Donde la calidad del software es la clave del éxito en los negocios y cuyo desafío es: hacerlo mejor que la competencia en términos de calidad, costos, plazos y performance predecible, considerando que las nuevas tecnologías ponen mayores dificultades al desarrollo de software. La metodología de desarrollo es no estructurada y basada en equipos de trabajo reducidos con conocimiento técnico especializado y con comprensión de dominio del Retail. Las personas son el principal factor de éxito de un proyecto de software. El foco siempre ha sido desarrollar software que funciona más que conseguir una buena documentación para dar continuidad y/o mantenibilidad al sistema en el tiempo. La regla a seguir es no producir documentos a menos que sean obligatorios por el cliente, necesarios de forma inmediata para tomar una decisión importante. Se responde a los cambios, basado en contratos de mantenimiento, mas que seguir un plan. Se construyen pocos artefactos y existen pocos roles. Los procesos son menos controlados, especialmente expuestos a cambios de requisitos en el transcurso del proyecto, no existiendo contratos que determinen claramente los alcances de los proyectos con el cliente. Los grupos de trabajo son pequeños, de desarrollo 1 o 2 personas. Los proyectos son pequeños, 2 a 3 semanas, donde habitualmente son montos de facturación inferiores a US$ ")

20 4 Definición del Problema 4.1 Problema FIDCOM desarrolla soluciones de punto de venta y servicios en la industria de Retail y se encuentra con algunos problemas recurrentes en los procesos de desarrollo de software. La metodología de desarrollo de software es desestructurada con procesos menos controlados, especialmente expuestos a cambios de requisitos en el transcurso del proyecto, no existiendo contratos que determinen claramente los alcances de los proyectos con el cliente; grupos pequeños de desarrollo de 2 o 3 personas, con pocos artefactos y pocos roles; poco énfasis en la arquitectura de software. En la medida que FIDCOM ha ido permanentemente desarrollando sus estrategias comerciales y de crecimiento organizacional, la tecnología ha ido evolucionando, las complejidades técnicas y expectativas de los clientes han ido creciendo y han comenzado a presentarse algunos problemas recurrentes en los procesos de desarrollo de software, los cuales se describen a continuación. Tabla 2 - Problemas Recurrentes en Desarrollo Problema Observaciones Recursos Limitados Plazos Sobrepasados Mantenciones Crecientes Desarrollos a Última Hora Requisitos Ambiguos, Incompletos, No Definidos y No cumplidos. Esto dado el nivel de especialización de los recursos y la baja documentación de las plataformas de desarrollo en Retail. Esto dado las exigencias del negocio, el cambio permanente y las escases de recursos. Esto dado el nivel de cambios permanente y adaptaciones requeridas, de acuerdo a las necesidades de negocio. Esto dado las exigencias de negocio por satisfacer las necesidades para enfrentar la competencia permanente. Esto dado el nivel de improvisación con que muchas veces se abordan las necesidades de negocio. Esto es una fuente de conflicto permanente en los clientes, como también es fuente de insatisfacción personal y conflicto interno de los equipos de trabajo y desarrollo. "*

21 Desde el punto de vista de efectos negativos internos en la empresa se identifican algunos, tales como: se generan soluciones de mala calidad, altas tasas de fallo, re trabajo, no se puede demostrar si se cumplen o no los objetivos, insatisfacción del personal; se termina especificando medios y no fines, entre otros. Para el caso de los efectos negativos en Clientes, se identifican algunos, tales como: situaciones en que existe pérdida de imagen de la empresa y pérdida de confianza en los productos, como también se genera insatisfacción en los clientes. 4.2 Por qué UP es un buen Punto de Partida? UP es un buen punto de partida por tratarse de una metodología de desarrollo de software orientada a conducir el proceso de desarrollo de forma eficaz basado en un conjunto de buenas prácticas probadas en la industria del software y muchas de las cuales son conocidas dentro de FIDCOM, disminuyendo el costo de adopción. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh [1]. En otras palabras, es perfectamente posible definir el proceso de ingeniería de una organización sobre la base del UP, sin tener que pagar derechos. 4.3 Por qué No usar UP tal cual? Por tratarse de un meta modelo, un proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes, por tratarse de un marco de trabajo extensible de metodología de desarrollo de software que debe ser adaptado a organizaciones o proyectos específicos no es apropiado utilizar UP tal cual. UP es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos. Los flujos y productos de trabajo de UP no incluyen la administración del proyecto. Por lo tanto, se requiere también que los proyectos se encuentren en un dominio acotado y se requiere flexibilidad, la cual se obtiene con el tiempo. Algunas prácticas y consideraciones en el proceso de desarrollo de software para soluciones de punto de venta son: 1. Se genera sólo un entregable a la tienda piloto (similar al planteamiento desarrollo en cascada ). No aplica el entregar por porciones al usuario final (según planteamiento UP), dado que una vez que se libera el software a la tienda piloto, recién en ese momento es utilizado por los usuarios reales. Sin embargo, se generan entregables parciales (iteraciones de porciones de software) a las áreas de sistemas para efectos de certificar las funcionalidades en ambientes de laboratorio (simulaciones). 2. Las implantaciones de software y servicios se realizan en locales, almacenes o tiendas que atienden a público general. Esto limita los horarios de trabajo y el usuario final es un cajero y/o cliente. 3. Los periodos de seguimiento de una tienda piloto son cortos (1 a 2 semanas). Esto dificulta las posibilidades de identificar hallazgos. #+

22 4. La implantación en todas las tiendas son amplios y riesgosos. Todos los accesos son remotos y las coberturas regionales. 5. El "time to market" es crítico, generalmente, es un esfuerzo grande el implantar las tiendas, dado que se requiere de procesos de certificaciones internas y externas; capacitaciones de cajeros, operadores, administrativos, entre otros. 4.4 Qué cosas de UP se mantienen tal y como están definidas en el modelo? Por tratarse de un marco de trabajo extensible de metodología de desarrollo de software que debe ser adaptado a organizaciones o proyectos específicos no es apropiado usar UP tal cual. Sin embargo, algunos aspectos que se mantienen tal y como están definidos en el modelo son: 1. La estructuración y organización de los proyectos se realiza por fases y disciplinas. 2. El desarrollo es dirigido por casos de uso, centrado en la arquitectura y enfocado en el riesgo. 3. El desarrollo es iterativo e incremental. Se mantiene un enfoque de cambio en los proyectos. Se pone en manos del cliente (área de sistemas, no usuario final) un sistema de prestaciones parciales, que se complementa en fases sucesivas. Dependiendo de su tamaño, los proyectos se organizan en mini-proyectos hasta cumplir con el 100% de la funcionalidad y pasar a una tienda piloto. 4. Se construyen artefactos que identifican: el modelo de negocio, requerimientos, arquitectura preliminar y candidata, modelo de pruebas, entorno. 5. Se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alta complejidad. 6. Si no se logra cumplir lo previsto dentro del plazo estipulado, se negocia el transferir tareas o requisitos para una iteración posterior, pero no se modifica la fecha de entrega de la iteración correspondiente. 4.5 Cuáles son las Adaptaciones Necesarias? En base a la definición, las adaptaciones son referidas con respecto a los clientes Retail y las capacidades de FIDCOM. Se representan por medio de un ámbito de adaptación y según cada una de las fases identificadas por UP para el proceso de desarrollo. A continuación se describe el ámbito de cada adaptación y las adaptaciones realizadas en cada una de las fases para la metodología propuesta. #"

23 4.5.1 Ámbito de Adaptación El ámbito de adaptación se representa en base a las adaptaciones necesarias para la metodología de FIDCOM y la justificación correspondiente según la metodología de desarrollo UP. En el siguiente cuadro se presenta un comparativo entre UP y la metodología requerida por FIDCOM. Tabla 3 - Comparativo de UP y Metodología para FIDCOM Ámbito de Adaptación Según UP Según Metodología para FIDCOM Requisitos. UP propone que los requisitos significativos se tomen en la fase de inicio, posteriormente se desarrollan y refinan en las siguientes fases. Para el Retail en la fase de inicio se debe levantar el 100% de los requisitos, tanto funcionales, como no funcionales y requisitos de restricción. En la fase de elaboración se refinan los requisitos. Compromiso desde el Inicio. UP entrega alcances imprecisos al inicio del proyecto y existe una posibilidad de no factibilidad del proyecto. Para el cliente Retail, en la fase de inicio se consiguen el compromiso con el plan previo a la aprobación formal del proyecto. Por tanto, dependiendo del tamaño del proyecto se construye el contrato y se define el 100% de los criterios de aceptación del negocio y en términos generales se definen los criterios funcionales. En la fase de elaboración se depuran los criterios de aceptación del negocio y se refinan los criterios funcionales Mitigación de Riesgos. UP propone que en la fase de elaboración se resuelven los riesgos más altos. Dado el nivel de especialización de FIDCOM, en la fase de inicio, se identifican riesgos técnicos en forma temprana que permitan comprobar la factibilidad del proyecto, donde en algunos casos se implementan prototipos y se generan ambientes. En la fase de elaboración se resuelven las complejidades técnicas. Alcances del Proyecto. UP postula alcances imprecisos al inicio del proyecto. Según las necesidades de Retail, en la fase de inicio se deben explicitar los criterios de aceptación, se realiza la nivelación de expectativas, alcances del proyecto y ##

24 compromiso con el plan, presentando los alcances y criterios definitivos del proyecto. En la fase de elaboración se depuran, se habilitan los espacios de trabajo requeridos; se diseña el plan de pruebas; se generan los ambientes de desarrollo y validación; se realiza un entregable temprano. Desarrollo Iterativo e Incremental. UP postula poner en manos del usuario un sistema con prestaciones parciales. Así el usuario tiene algunas funcionalidades en producción mientras se van desarrollando otras. Según las características de los Retailer, donde los usuarios finales son los clientes en el POS, y la complejidad de implantar en producción, y la amplitud del negocio, se debe disponer del 100% de las prestaciones (requisitos) previo a implantar una tienda piloto. Sin embargo, se generan prestaciones parciales (entregables por iteraciones acordadas con el cliente) a las áreas de sistemas. Arquitectura Preliminar. UP se basa en arquitecturas preliminares que se mejoran en el tiempo. La arquitectura definitiva se resuelve en la fase de inicio y se depura en la fase de elaboración. El nivel de conocimiento técnico de FIDCOM y el dominio acotado sobre el cual se trabaja, permite entregar a los clientes arquitecturas basadas en experiencias exitosas y por lo tanto rara vez son modificadas una vez diseñados. Evolución del Producto. UP postula la madurez del producto en la fase de evolución. Según las necesidades de Retail y la temporización de actividades, en la fase de transición, se permite el paso a la implantación de todas las tiendas. En la etapa de garantía el cliente realiza requerimientos de ajustes, de acuerdo a las solicitudes generadas como consecuencia de la interacción. #$

25 4.5.2 Adaptaciones a las Fases de UP Las adaptaciones realizadas en UP en el presente trabajo, para efectos de usar UP como guía en un proceso de desarrollo de software en FIDCOM, son enunciadas a continuación según cada una de las fases de UP indicadas en la siguiente tabla. Tabla 4 - Adaptaciones de UP para FIDCOM. Fase Inicio Fase Elaboración Fase Construcción Fase Transición Fase Evolución Se resuelven los Se depuran los criterios de Desarrollo por Se entrega Setup Garantía. riesgos técnicos. aceptación. iteraciones. al cliente. Mantenimiento Se generan Se depuran los requisitos. Se construye Capacitación correctivo. prototipos. Levantamiento del Se realiza inicio proyecto interno. documentación preliminar. completa. Documentación Implantación de todas las tiendas 100% de los requisitos. Se define los criterios de aceptación. Se inicia construcción del plan de pruebas. Se mitigan complejidades técnicas. Se realiza capacitación parcial. Se concluye con la entrega del final. Certificación. Implantación piloto. Mantenimiento adaptativo (contrato). Soporte y continuidad operacional. Se realiza plan preliminar. Se define la Se refinan compromisos con cliente. Se refina la arquitectura. 100% de la funcionalidad acordada. Se concluye con la aprobación del piloto. arquitectura. Se genera entregable Se realiza propuesta temprano. comercial. La tabla anterior representa las adaptaciones de actividades a realizar y cumplir en cada una de las fases para efectos de consumar con la definición de la metodología propuesta para FIDCOM. #%

26 5 Metodología Desarrollo de Software para FIDCOM 5.1 Descripción de Metodología para FIDCOM La metodología de desarrollo de software adoptada y adaptada para FIDCOM se basa en UP y las necesidades de desarrollo para el Retail, considerando las buenas prácticas de FIDCOM. En el cuadro siguiente se representa la metodología propuesta. Ilustración 5-1 Conceptualización Metodología para FIDCOM. La metodología de desarrollo de software para FIDCOM es un marco de desarrollo basado en UP con un enfoque de cambio. Aporta un enfoque disciplinado a la asignación de tareas y responsabilidades en un proyecto de desarrollo de software, que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental. El enfoque de cambio, iterativo e incremental, con implementaciones parciales, permite que cada implementación se considere un proyecto que genera productos de software, donde cada entrega es una iteración, que resulta en un incremento, induciendo un proceso continuo de pruebas y de integración desde las primeras iteraciones, con calidad de producto final. Sin embargo, el usuario final (cajero, cliente en el POS) solo obtendrán la funcionalidad una vez aprobada en un 100% los requisitos. Las iteraciones se refieren a pasos en el flujo de trabajo, y los incrementos a un crecimiento en el producto. Las tareas a abordar en cada iteración parten de dos factores: la iteración maneja un grupo de casos de uso que extienden la utilidad del producto, además las iteraciones tratan siempre con los riesgos más altos en el estado actual del proyecto. El enfoque iterativo no es dividir, sino que las sucesivas iteraciones se construyen a partir de los artefactos en el estado en que fueron dejados en las iteraciones precedentes. Cada iteración se considerada como un mini-proyecto, a partir de los casos de uso y se aborda el análisis, diseño, implementación, documentación y capacitación interna, y el testing. #&

27 Si una iteración cumple sus objetivos el proceso sigue con la siguiente iteración, por contra, si una iteración no cumple sus objetivos el arquitecto debe revisar las decisiones previas e intentar una nueva aproximación. En cada iteración el arquitecto analiza los casos de uso relevantes, se crean la especificación correspondiente, utilizando como guía los requisitos y la arquitectura elegida. Luego, el desarrollador analiza la especificación, diseña e implementa el código correspondiente para entregar a testing. En el área de testing se ejecutan las pruebas en base al plan y casos de pruebas. La aprobación se realiza con el cumplimiento del plan definido. Una vez que el cliente acepta el entregable y la documentación correspondiente, se realiza la capacitación para posteriormente realizar la certificación. La aprobación de la certificación es en base a los criterios de aceptación, una vez obtenida la aprobación se permite la planificación real de la tienda piloto. En términos generales, el piloto se instala y capacita a los usuarios involucrados, y se mantiene en operación por periodo de tiempo definido, necesario para determinar el grado de satisfacción del cliente. La aprobación del piloto permite dar inicio al plan de instalación en todas las tiendas. En términos generales, esta metodología permite una rápida retroalimentación y asimilación de los cambios, disminuyendo riesgos en forma temprana. La metodología de desarrollo de software descrita se divide en fases, las cuales se explican en la siguiente sección. 5.2 Fases de Proyecto para FIDCOM Un proyecto desarrollado con la metodología propuesta para FIDCOM irá a través de cada una de las siguientes fases. Tabla 5 - Fases de Proyecto para FIDCOM Fases Propósito Criterios de Aceptación Fase de Inicio Corresponde definir el NEGOCIO. Se define la factibilidad del proyecto a realizar. Esta es la información base requerida para el desarrollo de una propuesta y plan de proyecto a realizar. Esta fase concluye con la aprobación formal del proyecto por parte del Cliente y permite el inicio al proyecto propiamente tal. En esta fase lo fundamental es: 1. Se levantan todos los requisitos (100%), funcionales, no funcionales y requisitos de restricción. 2. Se identifican y mitigan riesgos técnicos tempranos que permitan asegurar la continuidad del proyecto. En algunos casos se implementan prototipos y se generan ambientes. 3. Se realiza el análisis y diseño de la configuración (Arquitectura). 4. Se debe describir claramente las oportunidades de negocio a Formalización del proyecto por parte del Cliente (Orden de Compra y firma de contrato). #'

28 Fase de Elaboración Fase de construcción resolver. 5. Se elabora la propuesta comercial, por tanto dependiendo el tamaño del proyecto se construye el contrato y se define el 100% de los criterios de aceptación del negocio y en términos generales se definen los criterios funcionales. De aprobarse el proyecto por parte del cliente y como un complemento a la fase de inicio, se construye el contrato (legal). Se definen los criterios de aceptación para el Cliente y Proyecto (Documento de alcances del proyecto). Corresponde refinar y detallar la mayoría de los requerimientos (escenarios de casos de uso) y la arquitectura del sistema. Se examinan detalladamente los objetivos y alcances, la elección de la arquitectura, y la resolución de los principales riesgos con sus planes de mitigación. Se considera el armado de ambientes requeridos para el correcto desempeño del proyecto y mitigar las complejidades técnicas. Desde un punto de vista de implementación, de acuerdo a criterios de tamaño, esfuerzo y complejidad, algunos de los desarrollos e implementaciones identificadas se realizan en esta fase de elaboración y se mitigan complejidades técnicas. Se construye la funcionalidad más representativa para todas aquellas componentes riesgosas de implementar. Esto con el objetivo de dar visibilidad, mitigar complejidades y generar un entregable temprano al Cliente. Aquí en la fase de elaboración la cuestión fundamental es: 1. Se desarrolla el plan de la fase de elaboración. 2. Se Analiza el problema del dominio. Determinar Alcances reales del sistema. 3. Refinar la base arquitectónica. Se especifica en detalle la mayoría de los requerimientos y se diseña la arquitectura completa del sistema, obteniendo la línea base de la arquitectura. 4. Eliminar los elementos de riesgo, complejidad técnica y determinar planes de mitigación. 5. Habilitación de laboratorio en FIDCOM (desarrollo y validación) y preparar laboratorio en Cliente (certificación y Piloto). 6. Contar con herramientas y ambientes de pruebas. Al final de la fase de elaboración el Jefe de proyecto debe planificar las actividades restantes, estimando los recursos necesarios para terminar el proyecto. Corresponde a la evolución hasta convertirse en un producto preparado, incluyendo todos los requisitos (100%), para entregarse al Cliente. Sin embargo, se generan prestaciones parciales (entregables por iteraciones acordadas con el cliente) de forma previa a las áreas de sistemas. Dependiendo el tamaño del proyecto, y la estrategia de desarrollo adoptada en conjunto con el cliente, se genera un entregable, o también pueden ser entregas parciales. Sin embargo, al final de esta fase el sistema contiene todos los casos de uso Requisitos completos. Refinar el 100% de los requerimientos y conseguir aprobación formal del cliente. Generación de Ambientes (Desarrollo, validación, certificación, Piloto) Identificar todos los Riesgos y su correspondiente plan de mitigación Entregable temprano 100% de los requisitos implementados Todos los casos de pruebas pasados (validados) #(