METODOLOGÍA DESARROLLO DE SOFTWARE ... - Universidad de...
49
! 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
Transcript of METODOLOGÍA DESARROLLO DE SOFTWARE ... - Universidad de...
��������������� �
��������������������������� ���� ������
�������� ��� ��������������� � ������!�
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
"
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.
#
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.
$
CONTENIDO
1 Introducción ...................................................................................................................................................7
2 Objetivos .........................................................................................................................................................8
2.1 Objetivo General ....................................................................................................................................8
2.2 Objetivos Específicos ...........................................................................................................................8
2.3 Procedimiento General de Trabajo ......................................................................................................8
2.3.1 Etapa de Recopilación y Análisis de Información ...............................................................................9
2.3.2 Etapa de Evaluación del Proceso de FIDCOM a la Luz de la Información ........................................9
2.3.3 Etapa de Propuesta de una Metodología ...........................................................................................9
2.3.4 Etapa de Evaluación de la Metodología .............................................................................................9
2.3.5 Etapa de Retroalimentación Cliente y Conclusiones ....................................................................... 10
3 Marco Conceptual ....................................................................................................................................... 11
3.1 Proceso Unificado de Desarrollo de Software ................................................................................ 11
3.1.1 Fase de Inicio en UP ........................................................................................................................ 11
3.1.2 Fase de Elaboración en UP ............................................................................................................. 11
3.1.3 Fase de Construcción en UP ........................................................................................................... 11
3.1.4 Fase de Transición en UP ............................................................................................................... 11
3.2 Organización de Disciplinas según UP ............................................................................................ 12
3.3 Marco de Desarrollo del UP .............................................................................................................. 13
3.4 Conceptos Claves en UP ................................................................................................................... 14
3.4.1 Iterativo e Incremental ..................................................................................................................... 14
3.4.2 Centrado en la Arquitectura ............................................................................................................. 15
3.4.3 Conducido por los Casos de Uso .................................................................................................... 15
3.4.4 Enfocado al Riesgo .......................................................................................................................... 16
3.5 Retail .................................................................................................................................................... 16
3.6 Software y Servicios para Retail ....................................................................................................... 16
3.7 Software de Calidad ........................................................................................................................... 17
3.8 FIDCOM ............................................................................................................................................... 17
%
4 Definición del Problema ............................................................................................................................. 19
4.1 Problema ............................................................................................................................................. 19
4.2 ¿Por qué UP es un buen Punto de Partida? .................................................................................... 20
4.3 ¿Por qué No usar UP tal cual? .......................................................................................................... 20
4.4 ¿Qué cosas de UP se mantienen tal y como están definidas en el modelo? .............................. 21
4.5 ¿Cuáles son las Adaptaciones Necesarias? ................................................................................... 21
4.5.1 Ámbito de Adaptación ...................................................................................................................... 22
4.5.2 Adaptaciones a las Fases de UP ..................................................................................................... 24
5 Metodología Desarrollo de Software para FIDCOM ................................................................................. 25
5.1 Descripción de Metodología para FIDCOM ..................................................................................... 25
5.2 Fases de Proyecto para FIDCOM ...................................................................................................... 26
6 Procedimiento General de implementación para FIDCOM ..................................................................... 29
6.1 Diagrama General ............................................................................................................................... 29
6.2 Descripción de actividades por Fases ............................................................................................. 31
7 Evaluación de la Propuesta Metodológica Aplicada para FIDCOM ....................................................... 33
7.1 Identificación de Variables ................................................................................................................ 33
7.2 Evaluación del Crecimiento Organizacional ................................................................................... 34
7.3 Evaluación de la Calidad de Software .............................................................................................. 35
7.3.1 El Cuestionario de Calidad de Software .......................................................................................... 35
7.3.2 Aplicación Cuestionario a Clientes .................................................................................................. 37
7.3.3 Análisis de Resultados del Cuestionario a Clientes ........................................................................ 39
7.4 Evaluación a la Resolución de Problemas Recurrentes en Desarrollo ........................................ 40
8 Conclusiones y Proyecciones ................................................................................................................... 41
8.1 Conclusiones ...................................................................................................................................... 41
8.1.1 Punto de Vista Conceptual .............................................................................................................. 41
8.1.2 Punto de Vista Personal .................................................................................................................. 41
8.1.3 Punto de Vista Metodológico ........................................................................................................... 42
8.1.4 Punto de Vista de Negocio .............................................................................................................. 42
&
8.2 Proyecciones ...................................................................................................................................... 42
8.3 Comentarios Finales .......................................................................................................................... 43
8.3.1 Condiciones de Implementación ...................................................................................................... 43
8.3.2 Riesgos a Considerar ...................................................................................................................... 43
8.3.3 Limitaciones Observadas ................................................................................................................. 44
9 Anexo 1 – Definición de Roles de Implementación ................................................................................. 45
10 Anexo 2 – Definición de Artefactos de Implementación ......................................................................... 46
11 Referencias .................................................................................................................................................. 48
'
Ilustraciones
Ilustración 3-1 Fases y Disciplinas según UP. ...................................................................................................... 12
Ilustración 3-2 Representación Proceso Iterativo e Incremental. .......................................................................... 14
Ilustración 5-1 Conceptualización Metodología para FIDCOM. ............................................................................ 25
Ilustración 6-1 Procedimiento General para FIDCOM ........................................................................................... 30
Tablas
Tabla 1 - Artefactos de UP y Evolución Temporal ................................................................................................ 13
Tabla 2 - Problemas Recurrentes en Desarrollo ................................................................................................... 19
Tabla 3 - Comparativo de UP y Metodología para FIDCOM ................................................................................. 22
Tabla 4 - Adaptaciones de UP para FIDCOM. ...................................................................................................... 24
Tabla 5 - Fases de Proyecto para FIDCOM .......................................................................................................... 26
Tabla 6 - Actividades por Fase .............................................................................................................................. 31
Tabla 7 - Definición y Análisis de Variables de Valor en FIDCOM........................................................................ 33
Tabla 8 - Evaluación del Crecimiento Organizacional en FIDCOM ...................................................................... 34
Tabla 9 - Cuestionario según atributos de Calidad de Software ........................................................................... 35
Tabla 10 - Resultados Aplicación del Cuestionario de Calidad a Clientes FIDCOM ............................................ 37
Tabla 11 - Roles de Implementación ..................................................................................................................... 45
Tabla 12 - Artefactos de Implementación .............................................................................................................. 46
(
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
)
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
*
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.
2.3.1 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.
2.3.2 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.
2.3.3 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.
2.3.4 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.
"+
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.
2.3.5 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.
""
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.
3.1.1 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.
3.1.2 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.
3.1.3 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.
3.1.4 Fase de Transición en UP Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado
(instalado).
"#
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.
"$
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
Iteraciones:
Inicio Elaboración Construcción Transición
Modelado del
negocio
Modelo del dominio C
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
proyecto
Plan de desarrollo C R R R
Pruebas Modelo de Pruebas C R
Entorno Marco de desarrollo C R
Donde:
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)
o R = Refinamiento del artefacto (ampliación, corrección).
"%
3.4 Conceptos Claves en UP
3.4.1 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.
"&
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.
3.4.2 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.
3.4.3 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
"'
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].
3.4.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.
"(
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.
")
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$5.000.
"*
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 Esto dado el nivel de especialización de los recursos
y la baja documentación de las plataformas de
desarrollo en Retail.
Plazos Sobrepasados Esto dado las exigencias del negocio, el cambio
permanente y las escases de recursos.
Mantenciones Crecientes Esto dado el nivel de cambios permanente y
adaptaciones requeridas, de acuerdo a las
necesidades de negocio.
Desarrollos a Última Hora Esto dado las exigencias de negocio por satisfacer las
necesidades para enfrentar la competencia
permanente.
Requisitos Ambiguos,
Incompletos, No Definidos
y No cumplidos.
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.
#+
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.
#"
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.
##
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
#$
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.
#%
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
riesgos técnicos.
Se generan
prototipos.
Levantamiento del
100% de los
requisitos.
Se define los
criterios de
aceptación.
Se realiza plan
preliminar.
Se define la
arquitectura.
Se realiza propuesta
comercial.
Se depuran los criterios de
aceptación.
Se depuran los requisitos.
Se realiza inicio proyecto
interno.
Se inicia construcción del
plan de pruebas.
Se mitigan complejidades
técnicas.
Se refinan compromisos
con cliente.
Se refina la arquitectura.
Se genera entregable
temprano.
Desarrollo por
iteraciones.
Se construye
documentación
preliminar.
Se realiza
capacitación
parcial.
Se concluye con
la entrega del
100% de la
funcionalidad
acordada.
Se entrega Setup
al cliente.
Capacitación
completa.
Documentación
final.
Certificación.
Implantación
piloto.
Se concluye con
la aprobación del
piloto.
Garantía.
Mantenimiento
correctivo.
Implantación de
todas las tiendas
Mantenimiento
adaptativo (contrato).
Soporte y
continuidad
operacional.
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.
#&
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.
#'
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).
#(
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).
Fase de Elaboración
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.
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
Fase de construcción
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
100% de los
requisitos
implementados
Todos los casos de
pruebas pasados
(validados)
#)
implementados 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. Están desarrollados con las pruebas unitarias y las pruebas realizadas por el área de validación en forma satisfactoria.
Aquí lo fundamental es:
1. Definir estrategia de entregas parciales para desarrollar e implementar el 100% de los requisitos.
2. Implantar en ambiente de laboratorio todas las funcionalidades requeridas.
3. Validar la versión entregada por cada iteración que se genera.
4. Construir la documentación requerida en cada entregable.
Versión completa entregada al Cliente (para certificar)
Fase de Transición
Corresponde a permitir hacer seguimiento al producto implantado en el Cliente.
En la fase de transición lo fundamental es:
1. La entrega de versión final en laboratorio cliente da inicio a esta fase.
2. Se realiza la certificación formal.
3. Se realizan actividades de implantación piloto.
4. Se desarrolla el material de documentación y capacitación. Se realizan actividades de capacitación a cajeros y operadores. Se realiza “transfer Skill” al personal técnico, personal de Sistemas del cliente (ingenieros, analistas, operadores y soportes); Capacitación a: Personal de Gerencia de la empresa y Personal de Tienda (cajeros y operadores de sistemas).
5. Se formaliza carta de aceptación y cierre.
Aquí es posible realizar mantenimiento correctivo de defectos.
Certificación en el
Cliente.
Implantación Piloto.
Material de
capacitación y
manuales.
Capacitación
Fase de Evolución
La fase de evolución permite hacer seguimiento al producto implantado en el Cliente. Aquí es posible realizar mantenimiento correctivo de defectos e implantación en todas las tiendas el sistema.
Garantía del producto.
Mantenimiento correctivo.
#*
6 Procedimiento General de implementación para FIDCOM El procedimiento general de implementación para FIDCOM permite representar las actividades definidas según la metodología de desarrollo de software. Se representa a continuación por medio de un diagrama general y la descripción de cada una de las actividades.
6.1 Diagrama General El diagrama general permite representar las actividades de trabajo, comienzo, fin, entradas, salidas y secuenciación de actividades, como también los roles y fases definidas. Por lo tanto se representa de forma grafica todos los elementos que forman parte del procedimiento.
La notación está basada en UML1. En este lenguaje se utiliza el diagrama de actividad que permite representar las actividades de trabajo, roles y fases por las cuales evoluciona un proyecto de desarrollo de software. La notación utilizada en este texto corresponde a la propuesta de Sparx Systems [14].
En la ilustración 6-1 se muestra el procedimiento modelado del proceso de desarrollo de software definido para FIDCOM. Las consideraciones son:
1. Los roles se representan por medio de Swimlanes.
2. Se representa cada una de las fases del proyecto. Las fases de inicio y construcción se representan
por medio de Boundary.
" ��,��-���������.�����!�/�������������������� ����� �� 0-�� �1�� �������,��-���� ����� ��.����
,��������2������������� ����!�,��.������������������ ��� ��0������ ����������� �3��.���� �� � � ��� �
�� 1
$+
Ilustración 6-1 Procedimiento General para FIDCOM
La información relativa a roles y artefactos construidos en las diferentes fases se encuentra disponible en los anexos 1 y 2, respectivamente.
$"
6.2 Descripción de actividades por Fases La siguiente tabla describe cada una de las actividades realizadas en la fase de inicio.
Tabla 6 - Actividades por Fase
Actividad Descripción Rol
FAS
E IN
ICIO
Realizar Levantamiento
Funcional
Para analizar los alcances del proyecto, es necesario que el analista
funcional realice un primer levantamiento, donde se entrevista con el
cliente para documentar los requerimientos y formalizar los deseos.
Analista
Funcional
Analizar Deseos de
Usuario
El analista de oportunidad analiza los deseos de usuario para verificar
su factibilidad de implementación.
Arquitecto
Aprobar Propuesta El cliente entrega su aprobación a la propuesta comercial. Cliente
Realizar Propuesta El Responsable comercial genera la propuesta comercial para
conseguir la aprobación del cliente.
Comercial
Analizar y Diseñar
Configuración
El arquitecto debe entender los requerimientos y diseñar un plano
grueso del sistema.
Arquitecto
Definir Negocio Corresponde a la definición y justificación de negocio. Analista
FAS
E E
LAB
OR
AC
ION
Depurar Criterios de
Aceptación
Corresponde a la actividad de revisar y acordar con el cliente el
entendimiento de cada uno de los criterios de aceptación.
Analista
Funcional
Mitigar Riesgos
Tempranos
En el Plan de Proyecto se listan los principales riesgos que tiene el
proyecto, según la experiencia.
Analista
Funcional
Diseñar Plan de Pruebas Se debe diseñar un plan que especifique la forma en que se realizarán
las pruebas.
Arquitecto
Diseñar Casos de Prueba De acuerdo a los casos de uso, se diseña los casos de prueba que
utilizará posteriormente el tester.
Analista
Funcional
Analizar Casos de Uso Para obtener las especificaciones del sistema se debe entender en
primer lugar los casos de uso, y revisar la arquitectura de este. Las
especificaciones las puede generar el arquitecto, si se trata de un
sistema desconocido por el desarrollador. En cambio si es un sistema
conocido, las puede generar el desarrollador.
Arquitecto
Generar Ambiente de
Desarrollo
Se genera ambientes, configuraciones, requerimientos sobre los cuales
trabajarán en la implementación de la solución. Los ambientes se
Desarrollador
$#
generan de acuerdo a las especificaciones entregadas por el Jefe de
Proyecto.
Generar Ambiente de
Validación
Se genera ambientes, configuraciones, requerimientos sobre los cuales
se realiza la validación de la solución.
Analista
Generar Ambiente
Temprano
Se genera un ambiente para implantar un entregable temprano
(ambiente de certificación). Corresponde a diseñar los ambientes,
configuraciones, requerimientos sobre los cuales se realiza la
implantación del modulo entregable (temprano) y posterior certificación
en el Cliente.
Servicios
Aprobar SAD Corresponde al cliente la aprobación del documento SAD, incluyendo
arquitectura candidata, el 100% de los requisitos con sus escenarios y
los alcances técnicos del proyecto.
Cliente
FAS
E C
ON
STR
UC
CIO
N
Implementar Se implementan los casos de uso, se genera una aplicación que cubra
el requerimiento. También debe corregir defectos de setup generados
anteriormente, los defectos vienen especificados en una plantilla de
defectos.
Desarrollador
Ejecutar Casos de Prueba El tester sigue cada paso de lo indicado en el documento de Casos de
Prueba. Ingresa el input indicado, y distingue el output obtenido, de
esta forma puede compararlo con el previsto.
Tester
Integrar en el Cliente Se integran las aplicaciones realizadas en los sistemas del cliente. Servicios
Construir CDP
Certificación
El cliente debe construir los casos de prueba y criterios de aceptación
del proceso de certificación. Con esto se compromete al cliente, se
participa en el proceso y se consigue formalizar las expectativas.
Cliente
FAS
E T
RA
NS
ICIO
N
Confeccionar Manuales Se confecciona un documento de instalación y configuración del setup. Desarrollador
Realizar capacitación Se realiza capacitaciones de instalación destinadas a los encargados
de soporte del cliente y usuarios.
Analista
Funcional
Certificar en el cliente Realizar la validación de producto en el cliente según los casos de
prueba.
Analista
Funcional
Implantar Piloto Se instala el sistema completo en una tienda piloto. Se realizan
actividades de instalación, capacitación y puesta en marcha piloto.
Servicios
$$
7 Evaluación de la Propuesta Metodológica Aplicada para
FIDCOM La evaluación nos permite determinar si la propuesta metodológica es razonable para FIDCOM. Se identifican las variables de crecimiento organizacional y calidad, como también la capacidad de resolver los problemas detectados en el proceso de desarrollo.
7.1 Identificación de Variables La siguiente tabla describe las variables de crecimiento organizacional, calidad y variables de problemas recurrentes en FIDCOM, a evaluar en base al trabajo realizado.
Tabla 7 - Definición y Análisis de Variables de Valor en FIDCOM
Variables de Valor
Descripción
1. Crecimiento organizacional
El crecimiento puede ser abordado desde distintas perspectivas, pero en términos de negocio, los aspectos e indicadores de interés son: el aumento de la cuota de mercado, el número de nuevos productos que oferta, el número de nuevos clientes que capta, el aumento de venta y principalmente el número de empleados, la cobertura geográfica y la cantidad de proyectos.
2. Calidad del software
De acuerdo a la terminología de la IEEE [9], la calidad de un sistema, componente o proceso de desarrollo de software, se obtiene en función del cumplimiento de los requerimientos iníciales especificados por el Cliente o usuario final. Según Pressman [8], es la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente. La importancia de cada característica de calidad varía dependiendo del tipo de software y del contexto [8].
3. Resolver problemas recurrentes en desarrollo.
FIDCOM desarrolla soluciones de software y en su proceso de desarrollo de software se ha encontrado con problemas recurrentes, tales como: recursos limitados, plazos sobrepasados, mantenciones crecientes, desarrollos a última hora y requisitos ambiguos, incompletos, no definidos y no cumplidos.
Por lo tanto, se elaboró 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.
El crecimiento organizacional desde el punto de vista metodología de desarrollo de software para hacerlos sustentable en FIDCOM se requiere contar con: una guía, un proceso de desarrollo, una metodología de trabajo replicable, exportable; es decir, contar con una guía que permita el desarrollo de proyectos replicables y de calidad. Todo esto considerando que existe una alta correlación entre calidad de proceso y calidad de producto, donde la opción es mejorar el proceso.
Todo lo anterior, es requerido para el crecimiento organizacional; esto, dado que: se tiene una mayor estructura; mayores costos, en especial aumento en el costo fijo. Por lo tanto, se requiere un aumento en las ventas y
$%
generar flujo de efectivo constante. La estrategia definida es contar con proyectos, productos y/o servicios de calidad, y replicables.
La calidad de software para FIDCOM está dada por: conformidad con los requerimientos explícitos, funcionales y de rendimiento, cumplidos, cobertura (%); entrega de soluciones a tiempo; Confiabilidad, grado de confianza esperado por parte del usuario en la operación adecuada del sistema al utilizarlo; Fiabilidad, comportamiento de las fallas, el tiempo de arribo de fallos, el número de fallos ocurrido en un tiempo determinado, la media del tiempo de ocurrencia de fallas, capacidad/tiempo de remoción; Mantenibilidad, tiempo medio entre cambios; Reusabilidad, facilidad de usar partes; interoperabilidad, esfuerzo de acoplamiento. Se considera que la variable más importante para medir la calidad de software está dada por la satisfacción del usuario.
7.2 Evaluación del Crecimiento Organizacional El crecimiento organizacional ha permitido determinar en un periodo de 12 meses un aumento favorable a FIDCOM lo cual se representa en la siguiente tabla.
Tabla 8 - Evaluación del Crecimiento Organizacional en FIDCOM
Variables Resultados
Número de Nuevos Productos
Aumento en el número de productos 2 por año.
Número de Nuevos Clientes.
Aumento en el número de clientes 10% por año.
Ventas Anuales Registradas.
US$4 millones. Crecimiento promedio anual del 25%.
Número de Empleados.
45 empleados. Crecimiento de un 20% anual. De estos empleados, el 65% del personal se encuentra en las áreas técnicas, un 20% en el área comercial y un 15% en Administración y Finanzas.
Cobertura Geográfica a Nivel Regional.
Aumento en la cobertura geográfica con presencia regional Latinoamericana en 6 países.
Cantidad de Proyectos en 12 meses.
Aumento en la cantidad de proyectos de un 20% anual.
También se debe considerar que para conseguir los resultados propicios anteriormente enunciados se ha requerido en FIDCOM lo siguiente: una mayor estructura, más clientes y más proyectos. Esto ha implicado mayores costos -en especial aumento en el costo fijo, y se requiere un flujo mayor de efectivo de forma constante.
.
$&
7.3 Evaluación de la Calidad de Software La evaluación de la calidad de los productos de software se ha basado en la construcción de un cuestionario. El cuestionario permite proporcionar una manera sistemática de valorar la calidad, desde el punto de vista de la satisfacción del cliente, basándose en un conjunto de reglas claramente definidas.
7.3.1 El Cuestionario de Calidad de Software El cuestionario de calidad de software permite medir la satisfacción del cliente, considerando atributos de calidad, los cuales son: funcionalidad, eficiencia, confiabilidad, facilidad de uso, mantenibilidad, portabilidad, tolerancia a fallos, capacitación, documentación, soporte y número de defectos; cumplimiento en plazo, y la cobertura requerida.
La tabla siguiente enuncia las preguntas asociadas a cada atributo de calidad.
Tabla 9 - Cuestionario según atributos de Calidad de Software
Atributo Preguntas a resolver
Funcionalidad ¿El producto cumple con los requisitos funcionales (explícitos)?
¿El producto cumple con los requisitos implícitos esperados?
(Si el producto cumple con sus requisitos explícitos pero falla en los implícitos, la calidad del software no será fiable.)
Eficiencia ¿El producto tiene la capacidad de entregar un desempeño apropiado, en relación con la cantidad de recursos utilizados, bajo las condiciones establecidas?
Confiabilidad ¿Tiene capacidad el producto para evitar fallas como resultado de errores?
¿El uptime del producto es por sobre el 95% requerido?
Facilidad de uso ¿Es el producto fácil de comprender, aprender y usar por el usuario y ser atractivo para él, bajo las condiciones específicas de uso definidas?
Comprensibilidad (Facilidad de comprensión) ¿El producto permite al usuario entender si el software es adecuado, y cómo éste puede ser usado para tareas y condiciones de uso particulares?
(Facilidad de Aprendizaje) ¿Es el producto capaz de permitir al usuario aprender su aplicación?
(Operatividad) ¿Es el producto capaz de permitir al usuario operarlo y controlarlo?
¿Es el producto capaz de adherirse a los estándares, convenciones, guías de estilo o reglamentos relacionados con facilidad de uso?
Mantenibilidad ¿El producto puede ser modificado?
¿Estas modificaciones pueden incluir correcciones, mejoras o
$'
adaptaciones del a los cambios en el ambiente Retail, en requisitos y en especificaciones funcionales?
¿El tiempo de respuesta para incorporar cambios es el esperado por el usuario?
¿Se cuenta con un producto estable? (Es la capacidad del producto para prevenir efectos imprevistos a partir de modificaciones).
(Facilidad de Prueba) ¿El producto es capaz de permitir que el software modificado sea validado?
Portabilidad (Instalabilidad) ¿Es el producto capaz de ser instalado en un ambiente específico definido?
(Coexistencia) ¿Es el producto capaz de coexistir con otros software independientes, en un ambiente común y compartiendo recursos del ambiente definido?
Tolerancia a fallas ¿Es el producto capaz de continuar a pesar de los errores encontrados?
Requerimientos ¿Existe flexibilidad del proveedor en la incorporación de requerimientos nuevos al proyecto?
Dominio Retail ¿El servicio prestado refleja un nivel de conocimiento apropiado de acuerdo a las necesidades del Retail?
Soluciones sin defectos ¿Se entrega el producto con calidad de entregable, es decir, con un mínimo de defectos encontrados; aceptables?
Plazo ¿Se cumple la entrega del producto en los plazos acordados?
Soporte ¿Se cuenta con un tiempo de respuesta de soporte (contacto) inferior a 30 minutos?
¿Se cuenta con un soporte en terreno (presencial) inferior a 4 horas?
Cobertura ¿Se cumple con las definiciones de soporte en horario definido?
Documentación ¿En la entrega final del producto, se cuenta con la documentación completa; de: usuario, instalación y configuración del producto?
Programas ¿Se cuenta con los entregables propuestos y acordados?
Capacitación ¿Una vez concluido el proceso de entrega del producto, se siente entrenado para operar el producto?
El esquema de puntuación para efectos de evaluar el cuestionario se propone en una escala del 0 (bajo) al 10 (alto) para percibir el grado de satisfacción de los clientes.
$(
7.3.2 Aplicación Cuestionario a Clientes El cuestionario se desarrolla y evalúa en base al procedimiento definido anteriormente. Sin embargo, se debe considerar que el cuestionario para determinar el grado de satisfacción del cliente está basado en las siguientes características:
- Aplicado en 2 clientes, representando los promedios.
- La evaluación se realiza en dos instancias en el tiempo, sin metodología y con la metodología definida, evaluación 1 y 2 respectivamente.
- El perfil del encuestado es de nivel ejecutivo de la empresa Retail (Gerente Proyecto y/o Gerente Informática), el cual es el responsable de las áreas técnicas, soporte, servicios y proyectos internos, como también es el responsable e interlocutor válido de las diferentes áreas del negocio (usuarios).
- Los proyectos definidos son cortos (2 a 4 meses) y de similares características.
La tabla siguiente presenta los resultados de la evaluación promedio de clientes, evaluación 1 y evaluación 2, con los resultados obtenidos y asociados a cada atributo de calidad.
Tabla 10 - Resultados Aplicación del Cuestionario de Calidad a Clientes FIDCOM
Atributo Pregunta Evalua1 Evalua2
Funcionalidad ¿El producto cumple con los requisitos funcionales (explícitos)?
10 10
¿El producto cumple con los requisitos implícitos esperados?
9 8
Eficiencia ¿El producto tiene la capacidad de entregar un desempeño apropiado, en relación con la cantidad de recursos utilizados, bajo las condiciones establecidas?
7 7
Confiabilidad ¿Tiene capacidad el producto para evitar fallas como resultado de errores?
6 7
¿El uptime del producto es por sobre el 95% requerido?
10 10
Facilidad de uso ¿Es el producto fácil de comprender, aprender y usar por el usuario y ser atractivo para él, bajo las condiciones específicas de uso definidas?
5 5
$)
Comprensibilidad ¿El producto permite al usuario entender si el software es adecuado, y cómo éste puede ser usado para tareas y condiciones de uso particulares?
5 5
¿Es el producto capaz de permitir al usuario aprender su aplicación?
5 5
¿Es el producto capaz de permitir al usuario operarlo y controlarlo?
10 10
¿Es el producto capaz de adherirse a los estándares, convenciones, guías de estilo o reglamentos relacionados con facilidad de uso?
5 5
Mantenibilidad ¿El producto puede ser modificado? 5 5
¿Estas modificaciones pueden incluir correcciones, mejoras o adaptaciones del a los cambios en el ambiente Retail, en requisitos y en especificaciones funcionales?
10 10
¿El tiempo de respuesta para incorporar cambios es el esperado por el usuario?
5 8
¿Se cuenta con un producto estable? (Es la capacidad del producto para prevenir efectos imprevistos a partir de modificaciones).
8 8
(Facilidad de Prueba) ¿El producto es capaz de permitir que el software modificado sea validado?
6,5 5
Portabilidad (Instalabilidad) ¿Es el producto capaz de ser instalado en un ambiente específico definido?
8 8
(Coexistencia) ¿Es el producto capaz de coexistir con otros software independientes, en un ambiente común y compartiendo recursos del ambiente definido?
5 5
Tolerancia a fallas ¿Es el producto capaz de continuar a pesar de los errores encontrados?
7 7
Requerimientos ¿Existe flexibilidad del proveedor en la incorporación de requerimientos nuevos al proyecto?
5 7
Dominio Retail ¿El servicio prestado refleja un nivel de conocimiento apropiado de acuerdo a las necesidades del Retail?
8 7
Soluciones sin defectos
¿Se entrega el producto con calidad de entregable, es decir, con un mínimo de defectos encontrados; aceptables?
5 8
$*
Plazo ¿Se cumple la entrega del producto en los plazos acordados?
5 8
Soporte ¿Se cuenta con un tiempo de respuesta de soporte (contacto) inferior a 30 minutos?
10 10
¿Se cuenta con un soporte en terreno (presencial) inferior a 4 horas?
10 10
Cobertura ¿Se cumple con las definiciones de soporte en horario definido?
10 10
Documentación ¿En la entrega final del producto, se cuenta con la documentación completa; de: usuario, instalación y configuración del producto?
5 8
Programas ¿Se cuenta con los entregables propuestos y acordados?
10 10
Capacitación ¿Una vez concluido el proceso de entrega del producto, se siente entrenado para operar el producto?
10 10
7.3.3 Análisis de Resultados del Cuestionario a Clientes La aplicación del cuestionario fue realizada a dos clientes representativos, donde se aplicó el cuestionario a los dos clientes de una vez y se obtuvo el promedio, en dos instancias de tiempo, sin y con metodología, evaluación 1 y evaluación 2 respectivamente, por medio de entrevista con Gerentes de Sistemas y/o Proyectos. Por consiguiente, los resultados obtenidos representan el promedio entre los dos clientes, para cada una de las evaluaciones realizadas, evaluación 1 y evaluación 2.
Por lo tanto, el resultado es que en su conjunto los clientes han mejorado su percepción de calidad, con respecto el grado de satisfacción, comparado entre la evaluación 1 y evaluación 2, cuando no se usa y usa la metodología respectivamente. Por ende, los resultados permiten suponer que la percepción de calidad ha mejorado en lo referente a la confiabilidad, mantenibilidad y documentación, como también se percibe que ha mejorado la calidad del entregable con menores defectos y una mejora en los plazos. No obstante, se refleja un leve deterioro en atributos de calidad tales como: funcionalidad y dominio retail. Consiguientemente, no se percibe diferencias en atributos de calidad tales como: eficiencia, comprensibilidad, facilidad de uso, portabilidad, tolerancia a fallas, soporte, cobertura y capacitación.
Se debe considerar que este cuestionario sólo entrega una pauta general de las características fundamentales que se requieren para cada atributo de calidad pero no verifica en forma explícita que las características planteadas hayan sido realmente cumplidas por el cliente. Por consiguiente, después de aplicar el cuestionario, se deben proporcionar las instancias necesarias para que la o las personas que lideren cada proyecto, validen su cumplimiento real, ya sea a través de la forma visual en las áreas aplicadas a la organización, o que la información otorgada sea la correcta y que no existan errores.
%+
7.4 Evaluación a la Resolución de Problemas Recurrentes en Desarrollo Los problemas recurrentes en el proceso de desarrollo de software en FIDCOM (capitulo 4.1) se han mitigado y/o absorbido al aplicar la nueva metodología. Esto basado en el análisis de las variables de proyectos en los últimos 12 meses, las cuales se demuestran en la siguiente tabla.
Problema Evaluación de Resolución, Mitigación o Absorción al aplicar la
metodología
Recursos Limitados Se cuenta con un proceso definido y de mejoramiento continuo que guía a
FIDCOM en la obtención de una mejor documentación, mantenibilidad y
confiabilidad de los proyectos. Queda huella de los trabajos realizados. Esto
ha permitido la entrega de soluciones de mejor calidad, en un esquema de
mejoramiento continuo y disminuyendo la dependencia de los recursos
humanos.
Plazos
Sobrepasados
Se cuenta con un proceso definido, conocido por FIDCOM y el cliente. Se
demuestra que se requiere mayor involucramiento del cliente en el proyecto.
Esto permite la transparencia en los procesos de desarrollo, por consiguiente,
los plazos son acordados con el cliente y monitoreados permanentemente.
Mantenciones
Crecientes
Se ha cambiado desde el desarrollo de proyectos a la medida a un enfoque de
productos. Las mantenciones y liberaciones son generalmente programadas.
Desarrollos a
Última Hora
Esto dado las exigencias de negocio por satisfacer las necesidades para
enfrentar la competencia permanente. Se ha detectado que aún existe este
tipo de casos. Sin embargo, el cliente ha ido entendiendo los riesgos que
implica esta modalidad de trabajo.
Requisitos
Ambiguos,
Incompletos, No
Definidos y No
cumplidos.
Este problema recurrente se ha mitigado en más del 90% de los casos, con un
mínimo grado de rigor, donde la exigencia es requerir que los requisitos deben
ser por escrito, aprobados por el cliente y validados por el arquitecto. A pesar
de lo anterior, de existir ambigüedad, se acuerda con el cliente tratar estas
situaciones por medio de controles de cambio.
%"
8 Conclusiones y Proyecciones
8.1 Conclusiones El desarrollo de las conclusiones se realiza en base a diferentes puntos de vista.
- Punto de Vista Conceptual
- Punto de Vista Personal
- Punto de Vista Metodológico
- Punto de Vista de Negocio
A continuación se describe cada uno de ellos.
8.1.1 Punto de Vista Conceptual El sustentar el crecimiento organizacional definido y planeado con productos de calidad, requiere tener procesos de calidad, armonizados, estandarizados y uniformes, que permitan contar con procesos replicables y exportables.
La metodología de desarrollo de software definida permite presumir que se tiene una mejora en el software entregado a los clientes. Se confirma así la correlación entre calidad de software y la calidad del proceso que lo produce; detectando la percepción de mejora en la confiabilidad, mantenibilidad y documentación de los entregables en clientes. En la empresa al mejorar el proceso se responde a la necesidad de tener una guía para perfeccionar cada una de las etapas en el desarrollo y mantenimiento del software, así como también los servicios asociados. Esto ha permitido la entrega de soluciones de mejor calidad, en un esquema de mejoramiento continuo y disminuyendo la dependencia de los recursos humanos.
Finalmente podemos afirmar que se han cumplido los objetivos propuestos y se ha elaborado una metodología fruto de adaptar UP para el desarrollo de software de calidad para soluciones en Retail y que está apoyando el crecimiento organizacional de FIDCOM.
8.1.2 Punto de Vista Personal La satisfacción por el desarrollo del tema elegido y con la obtención de los objetivos propuestos, y las motivaciones que lo incitaron son el principal logro que ha permitido ampliar la experiencia profesional y aplicar los conocimientos adquiridos con la capacidad de utilizar los conocimientos teóricos y prácticos. La motivación ha sido trabajar en una empresa mejor, ser reconocido por nuestros Clientes por la calidad de nuestros productos y servicios entregados; el contar con soluciones en tiempos y costos predecibles; el mejorar la satisfacción personal de los integrantes en la obtención de resultados; el disminuir las sobrecargas de trabajo, disminuyendo en un 40% los sobre tiempo, como también las jornadas de trabajo adicional los fines de semana y días festivos.
Este trabajo permitió converger en términos prácticos las disciplinas centrales del Programa de Magister en Tecnologías de Información, en lo que respecta a la adopción, uso y gestión de tecnologías de información, en el ámbito de: gestión y desarrollo de proyectos de TI, ingeniería de software, calidad de software y mejoramiento del proceso de software.
%#
8.1.3 Punto de Vista Metodológico Desde el punto de vista metodológico y con respecto a la metodología de desarrollo de software presentada, esto debe ser entendido como una primera versión de la solución a la implantación de una metodología que permite definir un modelo de proceso para el desarrollo de software de calidad en organizaciones que construyen software para la industria del Retail, específicamente para el Front Office.
Este modelo metodológico ha permitido verificar que los procesos satisfacen condiciones que la industria ha definido como apropiadas y ayuda a examinar la efectividad de nuestros procesos. Nos permite responder a exigencias del mercado y contar con un marco de trabajo que describe los elementos claves para un efectivo proceso de software, es decir evolucionar desde un estado con fines específicos a un proceso disciplinado. El tener un proceso organizacional que permite tener calidad consistente en el tiempo y nos permite medirnos contra indicadores que son usados por la industria, nos permite mejorar la calidad de nuestros productos a través de la mejora de la calidad de nuestros procesos para establecer un plan de mejoramiento del proceso de software.
Finalmente se puede afirmar que un modelo de proceso para el desarrollo de software de calidad basado en las buenas prácticas de la industria y estándares definidos permite una mejora en la eficiencia organizacional de empresas desarrolladoras de software y apoyan el crecimiento futuro.
8.1.4 Punto de Vista de Negocio Desde el punto de vista de negocios se ha conseguido mostrar que debido al cambio de metodología se ha logrado soportar el crecimiento organizacional, en términos de ventas, clientes, empleados, productos y proyectos, como también entregar la cobertura geográfica presupuestada. Esto basado en asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles, consiguiendo demostrar la mejora en la percepción de satisfacción de Clientes. Esto con la meta de mantener clientes, mejorar la calidad de productos, reducir los tiempos al mercado y contar con personal altamente calificado.
Se han mejorado los procesos internos de desarrollo, guiados con una visión común, permitiendo disminuir riesgos en planificación de desarrollo, como también mejorando la comunicación entre personas y se ha implementado un proceso de mejora continua. Esto ha permitido mejorar la satisfacción personal en la obtención de resultados, disminuyendo las sobrecargas de trabajo y disminuyendo los tiempos para realizar los trabajos. Esto se ha basado en contar con una metodología que nos permite realizar nuestros procesos de desarrollo de software de calidad; al contar con una comunicación más eficaz en las áreas técnicas; dar visibilidad, inicialmente, internamente a los proyectos, y de ser necesario a nuestros clientes. Así hemos podido compartir con nuestros clientes nuestro nivel de eficiencia y eficacia en la administración de los proyectos.
8.2 Proyecciones El trabajo presentado permite un sinnúmero de posibilidades de estudio potencial y futuro dentro de los cuales destacan el desarrollar un modelo de proceso de software para otras industrias, no sólo Retail. Además se debe incluir proceso de mejora continua y generar el vínculo entre la gestión de proyectos, procesos de desarrollo de software y las unidades de comercial, administración y finanzas y el área de servicios.
Esencialmente se debe considerar que UP es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos y permite representar la temporalidad de los proyectos de desarrollo de software a través de fases de trabajo. Sin embargo, un proyecto de desarrollo de la más alta calidad requiere ser administrado, donde se supone: Planificación, Supervisión, Control, Predictibilidad, Riesgos, entre otros. Para esto, se sugiere integrar una metodología que permita administración de los proyectos de desarrollo de software.
%$
8.3 Comentarios Finales Para finalizar las conclusiones se presenta a continuación algunos comentarios en torno a la temática propia de la metodología de desarrollo de software de calidad, basado en los siguientes tres aspectos:
1. Condiciones de Implementación
2. Riesgos a Considerar
3. Limitaciones Observadas
8.3.1 Condiciones de Implementación Se recomienda comenzar con un plan estratégico, definiendo la misión, visión, motivaciones y objetivos, basado en objetivos de negocio reales y objetivos de calidad, como también iniciar con una fase de inducción, capacitación y entrenamiento; fomentar la participación de las personas involucradas en el proyecto y aceptar objetivamente las sugerencias y propuestas de los usuarios involucrados; tener metas medibles de corto, mediano y largo plazo, las cuales deben ser conocidas periódicamente a nivel organizacional.
Se requiere un involucramiento de la dirección ejecutiva superior de la empresa, así como de los usuarios claves, esto basado en los objetivos de negocio identificados. Es preciso que se defina quiénes van a evaluar el éxito de la implantación, sus alcances y prioridades; no necesariamente habrá acuerdos, ya que lo normal es que existan oposiciones de intereses u objetivos que pueden colisionar, especialmente a nivel operativo (áreas operativas y personas).
Se debe definir los principios de priorización del proyecto, identificando el nivel de prioridad y tiempo de asignación de los recursos en relación a los otros proyectos que se desarrollan en la empresa. Se debe asignar el tiempo del personal ejecutivo e intermedio, que a la vez constituye una señal pública de la relevancia del proyecto. Todos los gerentes e involucrados en el proceso deben saber de calidad de software y los beneficios para la empresa. Además, el generar los indicadores adecuados que puedan expresar los beneficios (aumento de productividad, mejoramiento de clima organizacional, entre otros) y problemas (aumento de conflictos interpersonales, entre otras) que se generarán, permitirá evaluar y reevaluar el estado actual de los proyectos implantados y en proceso de implementación, para así estar orientándolos en la dirección adecuada.
Se debe plantear un proyecto piloto previo al proceso de institucionalización organizacional. Determinar alternativas de acción y la mejor manera de hacer las cosas. Se debe establecer los límites del proyecto de implantación, el impacto financiero, objetivos, cronogramas de actividades y la determinación de indicadores para medir la productividad del equipo de trabajo.
La calidad debe involucrar a toda la organización. Es un proyecto de la organización, no de la unidad de desarrollo, no es un tema técnico. Debe existir un responsable líder de calidad para toda la organización. El responsable debe tener entre sus responsabilidades básicas organizar al grupo de trabajo, dar visibilidad al proyecto, seleccionar en consenso los puntos a desarrollar y la metodología de trabajo, analizar la información recabada y los resultados obtenidos.
8.3.2 Riesgos a Considerar Los riesgos a considerar con su correspondiente plan de mitigación deben responder a los siguientes aspectos identificados:
1. La falta de aptitud y actitud del personal para llevar la adaptación a los nuevos procedimientos, roles y funciones.
2. Que no exista un liderazgo bien definido.
%%
3. Comunicación inadecuada de los contenidos.
4. Incapacidad de la gerencia de resolver conflictos debido a los cambios organizacionales.
5. Falta de experiencia y capacidad en la implementación del proyecto.
6. Contradicciones intrínsecas al modelo de referencia a utilizar.
7. Se debe contar con personas flexibles que pueden y quieren trabajar con procesos definidos.
8. Guiarse por un plan.
9. Centrarse en el proceso, no en el producto, ni en la tecnología, ni en las personas (desde el punto de vista individual).
10. El punto de vista debe ser interno.
11. Visibilidad permanente. Destacar logros y avances.
12. Mejoramiento continúo.
13. Contar con el Líder de mejoramiento de calidad idóneo.
Los riesgos deben ser tratados, identificados y mitigados de acuerdo a los alcances del plan del proyecto de implantación.
8.3.3 Limitaciones Observadas El implementar metodologías de desarrollo de software puede generar retraso en la presentación de soluciones debido a la falta de orientación y definición de lineamientos. Lo anterior puede traer como consecuencia el enfrentamiento y discusiones no relacionadas con los objetivos planteados, generando malas prácticas en el proceso (“pavimentar la ineficiencia”).
El comportamiento de los miembros del grupo puede afectar la productividad del equipo: arrogancia, dificultad para levantar las indefiniciones, juicios automáticos y sin base, percepción de que es difícil o imposible el trabajo que se hace, inhabilidad para manejar errores, apatía, impaciencia o poca tolerancia, entre otros.
El visualizar el valor que tiene la metodología de desarrollo de software en la organización, donde el rol es la generación de valor y construcción de software de calidad, muestran un entorno favorable. Sin embargo, el proceso de implantación requiere de una gran cantidad de esfuerzo, recursos, tanto financiero como humano, y un proceso iterativo de corto, mediano y largo plazo, el cual presente resultados que permitan visualizar los logros y falencias de la implementación.
Sin embargo, el modelo muestra que las PYME deberán considerar sus propias limitaciones a la hora de establecer las inversiones proyectadas en los planes de implementar metodologías de desarrollo de software, basado en estándares y sus buenas prácticas.
%&
9 Anexo 1 – Definición de Roles de Implementación
Tabla 11 - Roles de Implementación
Rol Descripción
Analista Funcional
Es el actor encargado del levantamiento funcional con lo que diseña y mantienen los casos de uso. En base a los casos de uso se diseña el plan de pruebas y los casos de prueba. El analista funcional también participa en el proceso de certificación con el cliente, realiza la documentación y capacitación necesaria. El analista funcional participa en todo el proceso de desarrollo de software.
Arquitecto Es el actor encargado y responsable técnico del proyecto, toma decisiones de diseño y mantiene el documento de análisis y diseño de arquitectura preliminar y candidata. También construye las especificaciones para el Desarrollador, y plan de pruebas para el Analista Funcional.
Cliente Es el actor que entrega los requerimientos de usuario de acuerdo a sus necesidades. También aprueba la propuesta comercial y genera la orden de compra, lo que es el punto de inicio del trabajo. Se requiere, en lo posible, su participación permanente.
Tester Es el actor encargado de realizar las pruebas. Recibe el setup desde desarrollo, ejecuta los casos de prueba, si encuentra defectos los reporta desde la plantilla de defectos al desarrollador. Al recibir el setup desde desarrollo con los defectos corregidos, debe replicarlos para aprobarlos y generar la liberación del setup para integrar en el cliente.
Comercial Es el actor responsable que mantiene la relación comercial con el cliente. El responsable comercial interactúa en primera instancia con el cliente y realiza la propuesta comercial. Entre sus responsabilidades esta el hacer seguimiento a las expectativas del cliente y velar por el cumplimiento.
Desarrollador Es el actor responsable de las implementaciones en el proceso de desarrollo. El desarrollador recibe las especificaciones técnicas desde el arquitecto del proyecto, implementa especificaciones y realiza las pruebas unitarias. Genera setup para validación y construye la documentación interna de instalación e integración. Una vez que se realizan las pruebas y se detectan hallazgos, recibe la plantilla de hallazgos (defectos), los resuelve y envía nuevamente un setup con las especificaciones revisadas y resueltas. Así sucesivamente hasta lograr un entregable de calidad esperada.
Finanzas Es el actor responsable de verificar la recepción de la correspondiente orden de compra, despachos y facturación, como también la construcción y legalización de contratos.
Integrador Es el actor que integra el setup liberado en el ambiente del cliente. Esto se realiza al recibir un setup desde el proceso de validación.
Servicio Es la o las personas que realizan los servicios de implantación, capacitación y puesta en marcha de piloto. La unidad de Servicios es responsable del primer contacto con el cliente, filtrar el reporte del cliente y registrarlo. La unidad de servicio (soporte primer nivel) es responsable de verificar que el problema se replique en ambiente de validación y registrar la incidencia para su resolución.
%'
10 Anexo 2 – Definición de Artefactos de Implementación
Tabla 12 - Artefactos de Implementación
Artefactos Descripción
Acuerdo Cliente Este artefacto corresponde a los alcances del proyecto como complemento a la propuesta comercial y permite formalizar los entendimientos.
Casos de Uso Este artefacto permite plasmar los deseos de usuarios, basado en técnica utilizada para levantar requerimientos.
Manuales Manuales de instalación e integración interna, como también manuales de usuario. La construcción de Manuales se inicia en la fase de construcción y se concluye en la fase de transición.
Panel de Control Corresponde a la representación de la información del monitoreo y control que se realiza en el proyecto.
Plan de Proyecto El plan incluye estimación de los elementos y tareas, recursos necesarios, negociación de compromisos, establecimiento de un calendario, e identificación y análisis de los posibles riesgos que pueda tener el proyecto.
Plan de Pruebas Cada prueba debe tener especificados los requerimientos del ambiente requerido para la validación, restricciones y técnicas que debe ocupar el analista para la realizar los Casos de Prueba.
Plantilla de Defectos e Incidentes
Esta plantilla indica los defectos encontrados en el setup. De esta forma se informa al desarrollador para que realice las correcciones y/o aclaraciones correspondientes.
Propuesta Comercial
Este documento/propuesta es la que se le entrega al cliente, con las estimaciones realizadas por la persona encargada del proyecto. Estas estimaciones son de tiempos requeridos por una unidad de trabajo y el costo que esto tiene.
Setup Corresponde al paquete de instalación liberado:
1. El setup es la versión generada y liberada por desarrollo. Se considera de entrada a validación.
2. El setup es la versión generada para hacer un entregable a Cliente. Es la versión probada con casos de pruebas conocidos y liberada por área de validación. Cada vez que el área de validación realiza pruebas conocidas. El setup es la salida de validación y la entrada en el proceso del cliente. Se realizan pruebas con usuarios reales.
3. Es la versión aprobada (certificada) por el cliente, en ambiente del cliente, con usuarios reales y lista para implantar en el local piloto.
%(
4. Es la versión aprobada en piloto y lista para implantar en todas las tiendas.
SAD Corresponde al artefacto que contiene la documentación de la arquitectura.
Casos de Prueba Este artefacto mantiene los casos de prueba formales de criterios para el proyecto. Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada, los cuales son formulados antes de que se ejecute la prueba.
La entrada conocida debe estar de acuerdo con una precondición y la salida esperada debe probar la poscondición.
Especificaciones Las especificaciones se refieren a cómo se implementará los requisitos a nivel de código.
Plan de Mitigación
Corresponde al artefacto que contiene el plan de mitigación a cada uno de los riesgos conocidos y tratados. Al listar los posibles riesgos del proyecto en una tabla, ésta es ordenada por probabilidad y por impacto. Los riesgos de alta probabilidad y de alto impacto pasan a lo alto de la tabla y para estos se analiza una estrategia de mitigación.
%)
11 Referencias [1] Ivar Jacobson, Grady Booch y James Rumbaugh. The Unified Software Development Process. Rational
Software Corporation. Addison-Wesley, 1999.
[2] IBM, Retail, http://www.ibm.com/ar/businesscenter/solutions/industry_retail.phtml, Diciembre 2007.
[3] USA Foreign Agricultural Service. Distribution Services.
http://www.fas.usda.gov/info/factsheets/China/distribution.html, Retrieved on 2006-04-04.
[4] Craig Larman. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso
unificado. Pearson Prentice Hall. Año 2003.
[5] Craig Larman. Agile & Iterative Development: A Manager's Guide. Pearson Education. Año 2004.
[6] USA, SEI – Software Engineering Institute – Carnegie Mellon, http://www.sei.cmu.edu/ Año 2008.
[7] Scott W. Ambler, Best Practices for Software Development, http://www.ambysoft.com, Año 2006.
[8] R. Pressman, Ingeniería del Software - un enfoque práctico, Mc Graw Hill, Quinta Edición, España, Año
2002.
[9] A.C. Gillies. Software Quality, Theory and Management. Thomson Computer Press. 1999.
[10] R. Kopelman. Administración de la Productividad en las Organizaciones,Traducción de la Primera Edición
en Inglés, Editorial Mc Graw Hill, México, 1986.
[11] F. Kast y J. Rosenzweig, Administración en las Organizaciones – Enfoque de Sistemas y Contingencia, Mc
Graw Hill, Segunda Edición en Español, México, 1998.
[12] I. Sommerville, Ingeniería del Software, Editorial Addison Wesley, Sexta Edición, México, 2002.
[13] H. Van Vliet. Software Engineering, Principles and Practice, Second Edition. John Wiley and Sons, 2001.
[14] Sparx Systems, Database Modeling, http://www.sparxsystems.com.au/resources/uml_datamodel.html, 2007.
