Metodo agil scrum

UNIVERSIDAD DE MENDOZA

Facultad de Ingeniería

Ingeniería en Informática

“MÉTODO ÁGIL SCRUM APLICADO AL DESARROLLO DE UN

SOFTWARE DE TRAZABILIDAD”

María Laura Citón

2006

Asesora: Ing. Graciela Sevilla

Coasesor: Ing. Fabián Contigliani

AGRADECIMIENTOS

En primer lugar, deseo agradecer al Dr. Ing. Salvador Navarria, Decano

de la Facultad de Ingeniería de la Universidad de Mendoza, y por su

intermedio al cuerpo docente y no docente de dicha prestigiosa

institución, que me acompañaron durante toda la carrera.

Deseo brindar un especial agradecimiento a la Ing. Graciela Sevilla y

al Ing. Fabián Contigliani, por su ayuda y dedicación durante la realización

del presente Trabajo Final.

Al Cdor. Mario Gobbi por la información brindada, asesoramiento y buena predisposición a las consultas realizadas.

A mi familia, a mi novio David y a mis amigos, por sus opiniones y

consejos, que fueron una guía y optimismo estos últimos años.

Y principalmente quiero dedicar este trabajo a mis padres, Dora y Luis, y

a mi hermano Alejandro; gracias a ellos y al gran amor que me brindan,

yo pude realizar y finalizar mi carrera.

RESUMEN

El presente Trabajo Final consiste en aplicar el método ágil Scrum al

desarrollo de un Software de Trazabilidad. La idea del mismo surge a raíz

de la percepción de lo complejo de gestionar eficientemente un proyecto,

con los métodos tradicionales de desarrollo de software, en un ambiente

tan cambiante y turbulento como el de la actualidad.

Como alternativa a las metodologías tradicionales nacen las ágiles, y

dentro de éstas escogimos a Scrum como método ágil para gestionar

nuestro proyecto. Scrum se basa en la adaptabilidad a los cambios como

medio para aumentar las posibilidades de éxito de los proyectos. Su

mayor objetivo es simplificar y minimizar el proceso de desarrollo y

apuntar a lo que realmente importa, la verdadera necesidad del cliente

realizando entregas frecuentes y continuas de software funcional. Tal es

su enfoque hacia la gestión, que deja un vacío metodológico en el área

del proceso.

Para poder implementarlo, entonces, elaboramos un proceso de

desarrollo propio que si bien contiene las cinco etapas habituales del

desarrollo de software, no deja de cumplir con los principios y valores de

las metodologías ágiles. Las etapas del proceso son: planificación,

análisis, diseño, construcción y prueba, e implementación; que para

llevarlas a cabo utilizamos una combinación de diferentes herramientas

de la ingeniería del software.

Haber transitado con Scrum el desarrollo de un proyecto real ha resultado

una experiencia enriquecedora. A través de él se ha logrado controlar la

velocidad de avance del proyecto eficientemente. El cual se terminó

entregando con un retraso admisible de una semana posterior a la fecha

pactada con el cliente.

El hecho de haber terminado el trabajo obteniendo como resultado un

producto funcionando muestra que los objetivos planteados en un

principio se cumplieron. Pero lo más importante, es que se incrementaron

los conocimientos por lo que el trabajo implicó una gran satisfacción

personal.

Método Ágil Scrum Aplicado al desarrollo de un software de Trazabilidad

María Laura Citón Universidad de Mendoza

1

ÍNDICE

INTRODUCCIÓN ------------------------------------------------------------------------3 PRIMERA PARTE: MARCO TEÓRICO 1. MÉTODOS ÁGILES-------------------------------------------------------------- 9

1.1. INTRODUCCIÓN ---------------------------------------------------------------------- 9 1.1.1. El dilema del software -------------------------------------------------------------------- 9 1.1.2. El surgimiento de la agilidad -----------------------------------------------------------10

1.2. ¿QUÉ ES UNA METODOLOGÍA ÁGIL? --------------------------------------10 1.2.1. La Alianza Ágil-----------------------------------------------------------------------------11 1.2.2. El Manifiesto Ágil -------------------------------------------------------------------------12 1.2.3. Metodologías ágiles vs. tradicionales------------------------------------------------16

2. SCRUM-----------------------------------------------------------------------------19 2.1. INTRODUCCIÓN ---------------------------------------------------------------------19 2.2. LA ESENCIA DE SCRUM ---------------------------------------------------------20 2.3. ELEMENTOS DE SCRUM---------------------------------------------------------21

2.3.1. Roles-----------------------------------------------------------------------------------------22 2.3.2. Poda de requerimientos-----------------------------------------------------------------25 2.3.3. Product Backlog---------------------------------------------------------------------------25 2.3.4. Sprint-----------------------------------------------------------------------------------------26 2.3.5. Valores --------------------------------------------------------------------------------------35

SEGUNDA PARTE: METODOLOGÍA 3. PROCESO DE DESARROLLO ----------------------------------------------38

3.1. INTRODUCCIÓN ---------------------------------------------------------------------38 3.2. PROCESO ITERATIVO E INCREMENTAL ----------------------------------38 3.3. ETAPAS DEL PROCESO DE DESARROLLO------------------------------40

3.3.1. Planificación--------------------------------------------------------------------------------40 3.3.2. Análisis --------------------------------------------------------------------------------------40 3.3.3. Diseño ---------------------------------------------------------------------------------------41 3.3.4. Construcción y Prueba ------------------------------------------------------------------41 3.3.5. Implementación ---------------------------------------------------------------------------42

3.4. EDT DEL PROCESO DE DESARROLLO ------------------------------------43 3.5. HERRAMIENTAS --------------------------------------------------------------------44

3.5.1. Técnicas de relevamiento --------------------------------------------------------------44 3.5.2. Work Breakdown Structure (WBS) ---------------------------------------------------44 3.5.3. Casos de uso ------------------------------------------------------------------------------44 3.5.4. Diagrama de actividades----------------------------------------------------------------45 3.5.5. Diagrama de Entidad Relación (DER)-----------------------------------------------45 3.5.6. ScrumWorks -------------------------------------------------------------------------------46 3.5.7. Burndown chart ---------------------------------------------------------------------------47 3.5.8. Clarion 5.5----------------------------------------------------------------------------------47



2

TERCERA PARTE: DESARROLLO DE INGENIERÍA 4. PROYECTO TRAZABILIDAD ------------------------------------------------50

4.1. PLANIFICACION INICIAL ---------------------------------------------------------50 4.1.1. Solicitud del proyecto --------------------------------------------------------------------50 4.1.2. El porqué de la solicitud del proyecto------------------------------------------------50 4.1.3. Evaluación de la información deseada ----------------------------------------------52 4.1.4. Situación actual ---------------------------------------------------------------------------55 4.1.5. Estructura de División del Trabajo (EDT)-------------------------------------------56 4.1.6. Conformación del equipo humano----------------------------------------------------57 4.1.7. Estimación del plazo de entrega y precio-------------------------------------------57 4.1.8. Gestión de riesgo -------------------------------------------------------------------------60 4.1.9. Propuesta comercial ---------------------------------------------------------------------61

4.2. HERRAMIENTAS EXISTENTES EN EL MERCADO----------------------62 4.3. COMENZANDO CON SCRUM---------------------------------------------------65

4.3.1. Primer Sprint -------------------------------------------------------------------------------67 4.3.2. Segundo Sprint----------------------------------------------------------------------------71 4.3.3. Tercer Sprint -------------------------------------------------------------------------------74 4.3.4. Cuarto Sprint-------------------------------------------------------------------------------76 4.3.5. Quinto Sprint -------------------------------------------------------------------------------78 4.3.6. Sexto Sprint --------------------------------------------------------------------------------81

ANEXOS ANEXO A--------------------------------------------------------------------------------84

PROPUESTA COMERCIAL ----------------------------------------------------------------84 ANEXO B--------------------------------------------------------------------------------87

INVESTIGACIÓN-------------------------------------------------------------------------------87 ANEXO C------------------------------------------------------------------------------ 116

ANÁLISIS DEL SISTEMA -----------------------------------------------------------------116 ANEXO D------------------------------------------------------------------------------ 141

DISEÑO DEL SISTEMA--------------------------------------------------------------------141 CONCLUSIONES ------------------------------------------------------------------- 149 BIBLIOGRAFÍA ---------------------------------------------------------------------- 151



3

INTRODUCCIÓN

En el actual contexto económico, los profesionales en el área de las

tecnologías de la información se encuentran con la responsabilidad de

conducir eficientemente proyectos de gran envergadura, simples o

complejos, cortos o de larga duración, en ambientes cambiantes y

turbulentos.

Todo proyecto tiene una meta: la combinación de recursos de todo tipo,

reunidos en una estructura temporal para cumplir con un objetivo

predeterminado, adaptándose a los cambios que surgen, dentro de los

costos preestablecidos y respetando las especificaciones técnicas que

aseguran la calidad de los resultados.

Este nuevo concepto de lo que se considera hoy en día un proyecto

exitoso, nos lleva a reflexionar acerca de que el esquema “tradicional”

para abordar el desarrollo de software ha demostrado ser efectivo y

necesario en proyectos de gran tamaño (respecto a tiempos y recursos),

donde por lo general se exige un alto grado de formalidad en el proceso.

Sin embargo, este enfoque no resulta ser el más adecuado para muchos

de los proyectos actuales donde el entorno del sistema es muy

cambiante, y se exige reducir drásticamente los tiempos de desarrollo

manteniendo una alta calidad.

A raíz de este planteo surge la inquietud de ahondar en las metodologías

ágiles que nacieron, precisamente, como una alternativa a las

tradicionales. Por estar las metodologías ágiles especialmente orientadas



4

a proyectos pequeños, constituyen una solución a medida para ese

entorno, aportando una elevada simplificación que, a pesar de ello, no

renuncia a las prácticas esenciales para asegurar la calidad del producto.

Se basan en la adaptabilidad de cualquier cambio como medio para

aumentar las posibilidades de éxito de los proyectos.

Las metodologías más características de esta familia son XP (Extreme

Programming), Scrum y Cristal; siendo Scrum la que hemos elegido para

desarrollar en detalle en este trabajo.

Scrum está basado en un proceso constructivo iterativo e incremental

donde las iteraciones tienen duración fija pero corta y el resultado final de

cada una de ellas es un producto funcional que contiene un subconjunto

de los requerimientos del proyecto. Constituyen el núcleo de Scrum, que

divide de esta forma el desarrollo de un proyecto en un conjunto de

pequeñas “carreras” llamadas Sprints. Cada Sprint es guiado por una lista

de funcionalidades priorizadas, que son planificadas con anterioridad.

Dentro de cada Sprint nunca se efectúa nada que no sea necesario para

cumplir los requerimientos del mismo.

Los principales motivos que nos han llevado a la elección de Scrum son:

Es uno de los métodos de gestión de proyectos más innovadores de los

denominados ágiles, ya que se destaca por una gran descentralización

como medio para alcanzar la mayor productividad posible.



5

Es mucho menos conocido que otros métodos ágiles. Posiblemente una

de las causas es la escasa documentación existente, lo que lleva a

pensar que este trabajo puede resultar en un aporte significativo.

No está concebido como un método independiente, sino que se promueve

como complemento de otras metodologías. Enfatiza valores y prácticas de

gestión, sin pronunciarse sobre requerimientos, implementación y demás

cuestiones técnicas; de allí su deliberada insuficiencia y

complementariedad.

Por lo tanto, para el caso del desarrollo de software Scrum necesita ser

completado con algún otro método o procedimiento. A tal fin, se elabora

un proceso de desarrollo propio para llenar ese vacío metodológico. El

proceso es iterativo e incremental para que permita hacer entregas

parciales que se van complementando según avanza el proyecto. Nuestro

proceso respeta las cinco etapas tradicionales de un proyecto pero no

deja de cumplir con los principios y valores de las metodologías ágiles.

Las etapas son: planificación, análisis, diseño, construcción y prueba, e

implementación.

Para llevar a cabo las etapas mencionadas en el párrafo anterior se utiliza

una combinación de diferentes herramientas de la ingeniería del software,

entre las que podemos mencionar: las Estructuras de División del Trabajo

(EDT), los Casos de uso, los Diagramas de Actividades, los Diagramas de

Entidad Relación (DER), ScrumWorks para llevar adelante el seguimiento

del proyecto y Clarion 5.5 que es el lenguaje de programación.



6

A continuación presentamos los objetivos generales que se han planteado

para el desarrollo del presente Trabajo Final.

Ø Conocer el método ágil Scrum para su posterior aplicación a un

proyecto real.

Ø Elaborar un proceso de desarrollo que lo complemente.

Ø Aplicar Scrum al desarrollo de un Software de Trazabilidad.

El porqué de la elección de desarrollar un Software de Trazabilidad y no

de cualquier otra temática se explica a continuación.

A raíz de que comienza a regir a partir del 1º de Mayo de 2005 una

normativa para la comercialización de productos con la Unión Europea -

Reglamento (CE) N° 178/2002; surge la posibilidad de desarrollar un

Software de Trazabilidad para un productor de uva de la zona de Lavalle.

La oportunidad de abordar esta temática de tanto auge en la actualidad

ha resultado de mucho interés, ya que se considera que el marco social,

económico y político de nuestro país hace muy importante a esta práctica

puesto que pretendemos exportar nuestra agroproducción desde un

contexto político observado y hasta a veces cuestionado por el mundo.

Este problema viene a ser asistido por las normas de calidad en general y

por la trazabilidad en particular. Se puede producir alimentos bajo normas

de calidad custodiadas internacionalmente que certifican que los

productos son elaborados bajo un estándar que no depende de la

situación país.



7

Los productores agrarios deberían comenzar a responder a este requisito

de la UE. Es por ello que se desarrollará un Proyecto Trazabilidad que

comprenderá desde la solicitud del cliente hasta la entrega al mismo del

producto terminado.

Se explica a continuación la manera en la que se ha organizado el

Trabajo Final.

Primera Parte: Marco Teórico

Se presenta el contexto en el que surgen las metodologías ágiles, sus

valores, principios, comparaciones con las metodologías tradicionales y

se describe con detalle Scrum.

Segunda Parte: Metodología

Se explica el proceso de desarrollo elaborado para complementar Scrum;

etapas definidas y herramientas utilizadas.

Tercera Parte: Desarrollo de Ingeniería

Se despliega el desarrollo del proyecto, aplicando la metodología y el

proceso de desarrollo explicados en los capítulos anteriores, para

alcanzar el producto final, el Software de Trazabilidad.

Luego, se presentan 4 Anexos que forman parte del desarrollo del

proyecto y que se invita a consultarlos para conocer en detalle el mismo.

PRIMERA PARTE

MARCO TEÓRICO



9

1. MÉTODOS ÁGILES

1.1. INTRODUCCIÓN

1.1.1. El dilema del software Cualquiera que alguna vez haya sido responsable de conducir un

proyecto de desarrollo de software sabe que no es para nada fácil.

Coordinar y negociar exitosamente con las partes implicadas en el

proyecto desafía al más experimentado líder.

Y si bien, hoy en día, el software es una parte crítica de todo negocio, aún

los proyectos de desarrollo de software sufren de problemas en su gestión

que los pueden llevar directo al fracaso. Los problemas más frecuentes

son:

§ No se adaptan a los cambios.

§ Calidad insuficiente y muy variable.

§ Proyectos que exceden sus tiempos y costos.

Con base en lo anterior se ha llegado a un acuerdo de lo que significa un

proyecto de software exitoso, en tres dimensiones:

ü A tiempo.

ü En presupuesto.

ü Cumpliendo el alcance definido (incluye adaptabilidad a los

cambios y calidad).



10

No es novedad que una forma de resolver los problemas de calidad, y

otros, de un producto es mejorando la forma de construir tales productos.

O sea.... mejorando los procesos.

En una actividad humana como es el desarrollo de software, esto es casi

equivalente a mejorar la metodología que se sigue para construir los

productos.

1.1.2. El surgimiento de la agilidad Durante el transcurso de los años 90 el ambiente cambiante y turbulento

era cada vez más la regla que la excepción. Por lo tanto surgió la

necesidad de desarrollar metodologías livianas y maniobrables que

pudieran operar en ese ambiente turbulento. Estas metodologías son

conocidas colectivamente hoy en día como “metodologías ágiles”.

1.2. ¿QUÉ ES UNA METODOLOGÍA ÁGIL? Lo ágil se define (por los mismos agilistas) como la habilidad de

responder de forma versátil al cambio para maximizar los beneficios. Las

metodologías ágiles varían en su forma de responder al cambio, pero en

general comparten las siguientes características:

ü Los individuos y sus interacciones son más importantes que los

procesos y las herramientas.

ü El software que funciona es más importante que la documentación

exhaustiva.



11

ü La colaboración con el cliente en lugar de la negociación de

contratos.

ü La respuesta al cambio en lugar de aferrarse a un plan.

Los valores y principios compartidos por toda la metodología ágil fueron

enunciados en el “manifiesto ágil”, por la “alianza ágil”.

1.2.1. La Alianza Ágil En una reunión celebrada en febrero de 2001 en Utha (EEUU), nace el

término “ágil” aplicado al desarrollo de software. En esta reunión

participaron un grupo de 17 expertos de la industria del software. Su

objetivo fue esbozar los valores y principios que debían permitir a los

equipos desarrollar software rápidamente y respondiendo a los cambios

que pueden surgir a lo largo del proyecto. Se pretendía ofrecer una

alternativa a los procesos de desarrollo de software tradicionales,

caracterizados por ser rígidos y dirigidos por la documentación que se

genera en cada una de las actividades desarrolladas.

Tras esta reunión se creó The Alliance, una organización dedicada a

promover los conceptos relacionados con el desarrollo ágil de software y

ayudar a las organizaciones para que los adopten. El punto de partida fue

el Manifiesto Ágil, un documento que resume la filosofía ágil.



12

1.2.2. El Manifiesto Ágil El Manifiesto comienza enumerando los principales valores del desarrollo

ágil. Se valora:

Al individuo y a las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de

un proyecto de software. Si se sigue un buen proceso de desarrollo, pero

el equipo falla, el éxito no está asegurado; sin embargo, si el equipo

funciona, es más fácil conseguir el objetivo final, aunque no se tenga un

proceso bien definido. Así mismo, las herramientas (compiladores,

depuradores, control de versiones) son importantes para mejorar el

rendimiento del equipo, pero el disponer de más recursos de los

estrictamente necesarios también puede afectar negativamente.

Desarrollar software que funciona más que conseguir una buena documentación. Aunque se parte de la base de que el software sin

documentación es un desastre, la regla a seguir es “no producir

documentos a menos que sean necesarios de forma inmediata para tomar

una decisión importante”. Estos documentos deben ser cortos y centrarse

en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se

incorpora al equipo de desarrollo, se considera que los dos elementos que

más le van a servir para ponerse al día son: el propio código y la

interacción con el equipo.

La colaboración con el cliente más que la negociación de un contrato. Las características particulares del desarrollo de software

hacen que muchos proyectos hayan fracasado por intentar cumplir plazos



13

y costes preestablecidos al inicio del mismo, según los requisitos que el

cliente manifestaba en ese momento. Por ello, se propone que exista una

interacción constante entre el cliente y el equipo de desarrollo. Esta

colaboración entre ambos será la que marque la marcha del proyecto y

asegure su éxito.

Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a lo largo del

proyecto (en los requisitos, la tecnología, el equipo) determina también el

éxito o fracaso del mismo. Por lo tanto, la planificación debe ser flexible

para poder adaptarse a los cambios que puedan surgir. Una buena

estrategia es hacer planificaciones detalladas para unas pocas semanas y

planificaciones mucho más abiertas para unos pocos meses.

Los valores anteriores inspiran los doce principios del manifiesto. Éstas

son las características que diferencian un proceso ágil de uno tradicional.

Los dos primeros son generales y resumen gran parte del espíritu ágil.

I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporten un valor. Un proceso es ágil si a

las pocas semanas de empezar ya entrega software que funcione

aunque sea rudimentario. El cliente decide si pone en marcha dicho

software con la funcionalidad que ahora le proporciona o

simplemente lo revisa e informa de posibles cambios a realizar.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que

el cliente tenga una ventaja competitiva. Los cambios en los registros

deben verse como algo positivo. Les va a permitir aprender más, a la

vez que logran una mayor satisfacción del cliente. Este principio



14

implica además que la estructura del software debe ser flexible para

poder incorporar los cambios sin demasiado coste agregado.

Luego existen una serie de principios que tienen que ver directamente con

el proceso de desarrollo de software a seguir.

III. Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo

posible entre entregas. Las entregas al cliente se insiste en que sean

software, no planificaciones, ni documentación de análisis o de

diseño.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto. El proceso de desarrollo necesita ser guiado por

el cliente, por lo que la interacción con el equipo es muy frecuente.

V. Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir

finalizar el trabajo. La gente es el principal factor de éxito, todos los

demás (proceso, entorno, gestión) queda en segundo plano. Si

cualquiera de ellos tiene un efecto negativo sobre los individuos debe

ser cambiado.

VI. El diálogo cara a cara es el método más eficiente y efectivo para

comunicar información dentro de un equipo de desarrollo. Los

miembros de equipo deben hablar entre ellos, éste es el principal

modo de comunicación. Se pueden crear documentos pero no todo

estará en ellos.



15

VII. El software que funciona es la medida principal de progreso. El

estado de un proyecto no viene dado por la documentación generada

o la fase en la que se encuentre, sino por el código generado y el

funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el

50% de los requisitos ya están en funcionamiento.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los

desarrolladores y usuarios deberían ser capaces de mantener el

ritmo de desarrollo durante toda la ejecución del proyecto,

asegurando en todo momento que la calidad es máxima.

Finalmente los últimos principios están más directamente relacionados

con el equipo de desarrollo, en cuanto metas a seguir y organización del

mismo.

IX. La atención continua a la calidad técnica y al buen diseño mejora la

agilidad. Producir código claro y robusto es la clave para avanzar

más rápidamente en el proyecto.

X. La simplicidad es esencial. Tomar los caminos más simples que

sean consistentes con los objetivos perseguidos. Si el código

producido es simple y de alta calidad será más sencillo adaptarlo a

los cambios que puedan surgir.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los

equipos organizados por si mismos. Todo el equipo es informado de

las responsabilidades y éstas recaen sobre todos sus miembros. Es

el propio equipo el que decide la mejor forma de organizarse, de

acuerdo a los objetivos que se persigan.



16

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a

ser más efectivo, y según esto ajusta su comportamiento. Puesto

que el entorno está cambiando continuamente, el equipo también

debe ajustarse al nuevo escenario de forma continua. Puede cambiar

su organización, sus reglas, sus convenciones, sus relaciones, etc.,

para seguir siendo ágil.

Los conceptos subyacentes no son nuevos, aunque toman nueva

importancia a partir del momento que se usan combinados.

1.2.3. Metodologías ágiles vs. tradicionales A continuación vamos a enumerar las principales diferencias respecto de

las metodologías tradicionales (no ágiles).

El siguiente cuadro recoge esquemáticamente estas diferencias que no se

refieren sólo al proceso en sí, sino también al contexto de equipo y

organización que es más favorable a cada una de estas filosofías de

desarrollo de software.



17

Metodologías Ágiles Metodologías Tradicionales La planificación del trabajo sólo comprende el ciclo en el que se está trabajando (normalmente 30 días).

Trabajo y gestión guiada por un plan general del proyecto que comprende todo su ciclo de desarrollo.

Descubrimiento progresivo de requisitos, e incorporación de cambios en cualquier iteración del desarrollo.

Conocimiento detallado de los requisitos antes de comenzar el diseño del proyecto.

“Refactorización” de código como modelo de trabajo compatible con el punto anterior.

“Hacerlo bien a la primera”. Evitar la re-codificación y el re-trabajo que supone una pérdida de eficiencia.

Comunicación directa entre los integrantes del equipo (incluidos cliente y usuarios) prefiriendo la verbal directa.

Comunicación formal según el plan de comunicación del proyecto.

Equipos auto-gestionados.

Gestión de equipos y personas centralizada en el gestor del proyecto.

No existe contrato tradicional o al menos es bastante flexible.

Existe un contrato prefijado.

El cliente es parte del equipo de desarrollo.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos pequeños (hasta 20 integrantes) y trabajando en el mismo sitio.

Grupos grandes y posiblemente distribuidos.

Pocos artefactos. Más artefactos. Pocos roles. Más roles. Menos énfasis en la arquitectura del software.

La arquitectura del software es esencial y se expresa mediante modelos.

Diferencias entre metodologías ágiles y no ágiles.

Las metodologías ágiles están revolucionando la manera de producir

software, y a la vez generando un amplio debate entre sus adeptos y

quienes por prejuicio no las ven como alternativa a las metodologías

tradicionales.

Aunque los creadores de las metodologías ágiles han suscrito el

manifiesto ágil, y todas ellas coinciden con los principios enunciados

anteriormente, cada una tiene características propias y hace hincapié en

algunos aspectos más específicos.



18

Las metodologías ágiles más populares son: XP (Extreme Programming –

Programación Extrema), Cristal y Scrum. Por ser esta última la elegida

para desarrollar el presente trabajo mencionamos los tres principales

motivos que nos llevaron a su elección.

§ Sirve para gestionar proyectos de cualquier tipo, no solamente

tecnológicos.

§ Deja un vacío en la parte de definiciones del área de ingeniería lo

que permite una elaboración propia para completarla.

§ Tiene escasa documentación por lo que se piensa que este trabajo

puede resultar en un aporte significativo.

A continuación, en el próximo capítulo, de desarrolla en detalle Scrum.



19

2. SCRUM

2.1. INTRODUCCIÓN Scrum es una metodología ágil de gestión de proyectos cuyo objetivo

primordial es elevar al máximo la productividad de un equipo. Reduce al

máximo la burocracia y actividades no orientadas a producir software que

funcione y produce resultados en periodos muy breves de tiempo. Como

método, Scrum enfatiza valores y prácticas de gestión, sin pronunciarse

sobre requerimientos, prácticas de desarrollo, implementación y demás

cuestiones técnicas. Más bien delega completamente en el equipo la

responsabilidad de decidir la mejor manera de trabajar para ser lo más

productivos posibles.

La palabra Scrum procede de la terminología del juego de rugby, donde

designa al acto de preparar el avance del equipo en unidad pasando la

pelota a uno y otro jugador. Igual que el juego, Scrum es adaptable, ágil,

auto-organizante y con pocos tiempos muertos.

Scrum fue desarrollado por Jeff Sutherland y elaborado más formalmente

por Ken Schwaber. Poco después Sutherland y Schwaber se unieron para

refinar y extender Scrum. Se la ha llegado a conocer como una

herramienta de hiperproductividad. Schwaber se dio cuenta entonces de

que un proceso necesita aceptar el cambio, en lugar de esperar

predictibilidad. Se enfoca en el hecho de que procesos definidos y

repetibles sólo funcionan para atacar problemas definidos y repetibles con

gente definida y repetible en ambientes definidos y repetibles. Toma el

cambio como una forma de entregar al final del desarrollo algo más



20

cercano a la verdadera necesidad del Cliente. Puede ser aplicado

teóricamente a cualquier contexto en donde un grupo de gente necesita

trabajar junta para lograr una meta común.

Se basa en los principios ágiles:

ü Privilegiar el valor de la gente sobre el valor de los procesos.

ü Entregar software funcional lo más pronto posible.

ü Predisposición y respuesta al cambio.

ü Fortalecer la comunicación y la colaboración.

ü Comunicación verbal directa entre los implicados en el proyecto.

ü Simplicidad; supresión de artefactos innecesarios en la gestión del

proyecto.

2.2. LA ESENCIA DE SCRUM § Más que una metodología de desarrollo es para gestionar

proyectos, no contiene definiciones en áreas de ingeniería.

§ Con visión de que el trabajo es efectuado por equipos auto-

organizados y auto-dirigidos, logrando motivación, responsabilidad

y compromiso.



21

§ Está basada en un proceso constructivo iterativo e incremental

donde las iteraciones tienen duración fija.

§ Contiene definición de roles, prácticas y productos de trabajo

escritas de forma simple.

§ Está soportada en un conjunto de valores y principios.

El flujo de Scrum

2.3. ELEMENTOS DE SCRUM § Roles

Ø Product Owner

Ø Scrum Master

Ø Team (Equipo)

Nueva funcionalidad Sprint Backlog

Product Backlog seleccionado

Product Backlog Requisitos priorizados

Visión: ROI – versiones

hitos



22

§ Poda de requerimientos

§ Product Backlog

§ Sprint

Ø Planificación

Ø Sprint Backlog

Ø Scrum

Ø Estimaciones

Ø Builds continuos

Ø Revisión del Sprint

Ø Reunión retrospectiva

§ Valores

Ø Foco, comunicación, respeto y coraje.

2.3.1. Roles La dimensión del equipo total de Scrum no debería ser superior a veinte

personas. Si hay más, lo más recomendable es formar varios equipos. No

hay una técnica oficial para coordinar equipos múltiples, pero se han

documentado experiencias de hasta 800 miembros, divididos en Scrums

de Scrum, definiendo un equipo central que se encarga de la

coordinación, las pruebas cruzadas y la rotación de los miembros.

Scrum tiene una estructura muy simple. Todas las responsabilidades del

proyecto se reparten en 3 roles:



23

Ø Product owner (Dueño del producto) Representa a todos los interesados en el producto final. Sus áreas de

responsabilidad son:

• Financiación del proyecto

• Requisitos del sistema

• Retorno de la inversión del proyecto

• Lanzamiento del proyecto

Es el responsable oficial del proyecto, gestión, control y visibilidad de la

lista de acumulación o lista de retraso del producto (Product Backlog).

Toma las decisiones finales de las tareas asignadas al registro y convierte

sus elementos en rasgos a desarrollar.

Ø Scrum Master (Líder del proyecto) Responsable del proceso Scrum, de cumplir la meta y resolver los

problemas. Así como también, de asegurarse que el proyecto se lleve a

cabo de acuerdo con las prácticas, valores y reglas de Scrum y que

progrese según lo previsto.

Interactúa con el cliente y el equipo. Coordina los encuentros diarios, y se

encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo

y trabajar a la par.



24

Ø Team (Equipo) Responsable de transformar el Backlog de la iteración en un incremento

de la funcionalidad del software. Tiene autoridad para reorganizarse y

definir las acciones necesarias o sugerir remoción de impedimentos.

• Auto-gestionado

• Auto-organizado

• Multi-funcional

La dimensión del equipo total de Scrum no debería ser superior a veinte.

El número ideal es diez, más o menos dos. Si hay más, lo más

recomendable es formar varios equipos. No hay una técnica oficial para

coordinar equipos múltiples, pero se han documentado experiencias de

hasta 800 miembros, divididos en Scrums de Scrums, definiendo un

equipo central que se encarga de la coordinación, las pruebas cruzadas y

la rotación de los miembros.

Roles: gallinas y cerdos

El nombre de los miembros del equipo y los externos se deriva de una

típica fábula agilista: un cerdo y una gallina discutían qué nombre ponerle

a un nuevo restaurante; la gallina propuso “Jamón y Huevos”. “No,

gracias”, respondió el cerdo, “Yo estaré comprometido, mientras tú sólo

implicada”.

Scrum diferencia claramente entre estos dos grupos para garantizar que

quienes tienen la responsabilidad tienen también la autoridad necesaria



25

para poder lograr el éxito, y que quienes no tienen la responsabilidad, los

observadores externos, no produzcan interferencias innecesarias.

Comprometido en el proyecto Implicados en el proyecto

§ Dueño del producto § Equipo § Scrum Master

§ Marketing § Comercial § Etc.

2.3.2. Poda de requerimientos La primera actividad es armar una lista exhaustiva de los requerimientos

originales del sistema. Luego se procede a ver qué requerimientos son

realmente necesarios, cuáles pueden posponerse y cuáles eliminarse.

Para ello debe identificarse un representante con capacidad de decisión,

priorizar los requerimientos en base a su importancia y acordar cuáles son

los prioritarios para la fecha de entrega.

La poda de requerimientos es una buena práctica implícita en modelos

ágiles, se hace lo que el cliente realmente desea, no más.

2.3.3. Product Backlog Con los requerimientos priorizados y podados armamos el Backlog de

Producto. Este es una forma de registrar y organizar el trabajo pendiente

para el producto (actividades y requerimientos).

Es un documento dinámico que incorpora constantemente las

necesidades del sistema. Por lo tanto, nunca llega a ser una lista



26

completa y definitiva. Se mantiene durante todo el ciclo de vida (hasta la

retirada del sistema) y es responsabilidad del Product Owner.

2.3.4. Sprint Scrum está basado en el control empírico de procesos. Se utiliza cuando

la capacidad de predicción es vaga, la incertidumbre alta o el proceso es

demasiado complejo para ser modelado y definido.

En el enfoque empírico de control de procesos se establecen reglas

simples y se crea una disciplina de inspección frecuente para adaptarse

rápidamente a situaciones imprevistas o problemas.

Un Sprint es el periodo de tiempo durante el que se desarrolla un

incremento de funcionalidad. Constituye el núcleo de Scrum, que divide

de esta forma el desarrollo de un proyecto en un conjunto de pequeñas

“carreras”.

PROCESO E S

C

Entrada: Backlog de producto seleccionado

Salida: Nuevo incremento del producto

Control: Inspección diaria y resolución de problemas

Proceso: Sprint con sus prácticas y reglas



27

• Duración máxima del Sprint : 30 días.

• Durante el Sprint no se puede modificar el trabajo que se ha

acordado en el Backlog.

• Sólo es posible cambiar el curso de un Sprint, abortándolo, y sólo

lo puede hacer el Scrum Master si decide que no es viable por

alguna de las razones siguientes:

- La tecnología acordada no funciona.

- Las circunstancias del negocio han cambiado.

- El equipo ha tenido interferencias.



28

Ø Planificación Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que

los objetivos no van a cambiar durante el mismo. De esta manera se

atenúa el riesgo.

Aspectos a tener en cuenta sobre la planificación de un Sprint:

• Una determinación general de alcance, frecuentemente basada en

una EDT (Estructura de División del Trabajo).

• Estimaciones de esfuerzo de alto nivel realizadas durante la etapa

de concepción del proyecto.

• Esfuerzo dedicado a labores de soporte o de preparación de los

ambientes requeridos por el proyecto.

• Esfuerzo asociados a las reuniones diarias, de planificación y de

revisión.

• Requerimientos de recursos de infraestructura o logísticos

(máquinas, redes, licencias, papel, pizarras, etc.).

• Habilidades presentes y necesarias en el equipo.

• Restricciones asociadas al conocimiento del negocio, la tecnología

o externas (legales, reglamentarias, estándares, etc.).



29

Rol del Scrum Master durante la planificación:

ü Dirige la planificación.

ü Es vínculo entre el equipo y el Product Owner del proyecto.

ü Registra problemas y riesgos detectados durante la planificación.

ü Registra las tareas, asignaciones y estimaciones.

ü Inicia el Backlog del Sprint.

Ø Sprint Backlog Trabajo o tareas determinadas por el equipo para realizar en un Sprint.

• Tareas a convertir en producto funcional.

• Las tareas se estiman en una duración entre 1 a 20 horas de

trabajo. Las de mayor duración deben intentar descomponerse en

sub-tareas de ese rango de tiempo.

• La estimación se actualiza día a día.

Ø Scrum diario Scrum asume que el proceso es complejo y que es necesario

inspeccionarlo frecuentemente, por eso se realiza una reunión diaria de

seguimiento. El encuentro diario impide caer en el dilema señalado por

Fred Brooks: “¿Cómo es que un proyecto puede atrasarse un año? Un día

a la vez”.



30

El foco de la reunión es determinar el avance en las tareas y detectar

problemas o “bloqueos” que estén haciendo lento el progreso del equipo o

que eventualmente impidan a un equipo cumplir con la meta del Sprint. La

idea es que ningún problema quede sin resolver o, por lo menos, sin

iniciar alguna acción de respuesta dentro de las 24 horas después de su

detección.

La reunión es además un espacio definido para que cada miembro del

equipo comunique a los demás el estado de su trabajo y por lo tanto

reafirme el compromiso.

Tips para un buen Scrum diario:

• Todos los días en el mismo sitio y a la misma hora. Con una

duración máxima de 15 minutos.

• Se recomienda que sea la primera actividad del día.

• Deben acudir todos los miembros del equipo.

• Hacer un círculo, permitir que todos vean a todos.

• Mantener el foco.

• Solo habla una persona a la vez y los demás escuchan. No se

permiten interrupciones, entrar y salir, hablar por teléfono, etc.

• Sólo se habla de: ¿En que trabajé ayer? ¿En que voy a trabajar

hoy? ¿Que problemas impiden mi progreso?



31

• No iniciar discusiones muy largas sobre temas técnicos o sobre los

problemas, esto hay que registrarlo y manejarlo después de la

reunión.

• Si están permitidas las preguntas para aclarar el alcance de un

trabajo o de un problema.

• Cuando un miembro informa de algo de interés para otros, o

necesita ayuda de otros, estos se reúnen al terminar la revisión

diaria.

• Las gallinas no pueden intervenir ni distraer, y el Scrum Master

puede limitar el número de gallinas asistentes si lo considera

oportuno.

Rol del Scrum Master durante el Scrum:

ü Dirige la reunión y mantiene el foco.

ü Hace preguntas para aclarar dudas.

ü Registra (escribe o documenta) los problemas para su resolución

después de la reunión.

ü Se asegura que los miembros cuenten con el ambiente adecuado

para la reunión.

Ø Estimaciones Las estimaciones se realizan por primera vez en la reunión de

planificación al inicio del Sprint. Luego las tareas se re-estiman todos los

días y se registran sus cambios en el Backlog del Sprint; esta actividad

puede ser realizada inmediatamente antes o después del Scrum diario.



32

Algunas claves para la estimación:

• Siempre se realizan estimaciones de esfuerzo, no de duración.

• Siempre se estima el esfuerzo total pendiente para terminar la

tarea, no se estima el esfuerzo consumido.

• Se buscan unidades manejables, lo usual es que estén en un

mínimo de 2 horas y un máximo de 20. Si la tarea es muy corta se

trata de juntarla con otras relacionadas. Si la tarea es muy grande

se trata de descomponerla.

Ø Builds continuos y pruebas básicas La estrategia que generalmente se utiliza es la de Builds continuos y

“smoke test” (prueba básica para la funcionalidad del sistema).

El programador libera código.

Pasa a integración lo más pronto posible (diario al menos).

Se prueba que no se rompa el build.

Se itera por estas fases



33

Procedimiento de Builds continuos

• Los programadores desarrollan según el Backlog del Sprint, y al

finalizar, notifican al integrador.

• El integrador toma el código y lo integra con el resto del producto.

• Se compila el software y se prueba “por arriba” el producto, para

verificar que no se haya roto.

• Si se encuentran problemas se devuelve al desarrollador.

• Se notifica al equipo que hay una nueva versión “estable” del

código para usar como base.

Ø Revisión del Sprint El objetivo de la reunión de revisión es presentar el producto o porción del

producto desarrollada por el equipo a los usuarios. La reunión se utiliza

para detectar inconformidades mayores que se vuelven elementos del

Backlog de Producto y que eventualmente se resuelven en el siguiente

Sprint.

A la reunión asisten el equipo, el Scrum Master, el Product Owner y todas

las personas implicadas en el proyecto (gallinas).

Tips para una buena revisión:

• Duración máxima de la reunión: 4 horas.



34

• Preparar la presentación, teniendo en cuenta que lo único que se

presenta es el producto (no Power Point o similares).

• Mantener el foco durante la reunión de revisión, el foco es el

producto solamente.

• Finalidad: presentar al propietario del producto y a las gallinas las

nuevas funcionalidades implementadas.

• Las funcionalidades no implementadas no se presentan.

• Registrar todos los comentarios e inconformidades declaradas de

los usuarios sobre el producto para determinar cuales de ellas

formarán parte del Backlog.

Ø Reunión retrospectiva Scrum involucra el concepto de mejora continua a través de las reuniones

de retrospección. Las reuniones buscan detectar los puntos positivos y

negativos del Sprint para generar propuestas de mejora para futuros

Sprints.

Las reuniones de retrospección son el concentrador del aprendizaje

organizacional sobre el Scrum. Los puntos positivos y negativos se

registran y se definen ítems de acción para cada uno. Los ítems de acción

definidos se toman en cuenta en los siguientes Sprints.



35

Acuden el equipo y el Scrum Master, y opcionalmente el Product Owner

del Producto.

Tips para una buena retrospección:

• Todos los miembros del equipo responden a dos preguntas:

- ¿Qué cosas fueron bien en el último Sprint?

- ¿Qué cosas se podrían mejorar?

• El Scrum Master anota todas las respuestas.

• El equipo prioriza las mejoras posibles.

• El Scrum Master no proporciona respuestas, sino que ayuda al

equipo a encontrar la mejor forma de trabajar con Scrum.

• Las acciones de mejora localizadas que se puedan implementar en

el próximo Sprint deben introducirse en el Backlog como elementos

no funcionales.

2.3.5. Valores Foco à Los individuos y sus interacciones son más importantes que el

proceso y las herramientas. La gente es el principal factor de éxito de un

proyecto de software.



36

Comunicación à Scrum pone en comunicación directa y continua a

clientes y desarrolladores. El cliente se integra en el equipo para

establecer prioridades y resolver dudas. De esta forma ve el avance día a

día, y es posible ajustar la agenda y las funcionalidades de forma

consecuente.

Respeto à Scrum diferencia claramente entre dos grupos para garantizar

que quienes tienen la responsabilidad tienen también la autoridad

necesaria para poder lograr el éxito (cerdos), y que quienes no tienen la

responsabilidad, los observadores externos (gallinas), no produzcan

interferencias innecesarias.

Coraje à El coraje implica saber tomar decisiones difíciles. Reparar un

error cuando se detecta. Mejorar el código siempre que el feedback y las

sucesivas iteraciones se manifiesten susceptibles de mejora.

SEGUNDA PARTE

METODOLOGÍA



38

3. PROCESO DE DESARROLLO

3.1. INTRODUCCIÓN En este apartado se presenta el proceso de desarrollo elaborado para

complementar la metodología Scrum ya que esta no contiene definiciones

en cuestiones técnicas.

Se utiliza un proceso ágil iterativo e incremental que respeta las cinco

etapas tradicionales de un proyecto que facilitan su gestión y control; ellas

son: planificación, análisis, diseño, construcción y prueba, e

implementación. Cómo el objetivo final de la metodología es llegar al éxito

del proyecto se definen, en forma clara, los entregables de cada etapa y

el alcance global, reflejando estos puntos en la planificación de todas las

tareas involucradas.

Se considera que: etapas delimitadas, entregables definidos y tareas

acotadas son claves para el cumplimiento del plan.

3.2. PROCESO ITERATIVO E INCREMENTAL Este tipo de proceso de desarrollo permite hacer entregas parciales que

se van complementando según avanza el proyecto. De esta manera se

reducen los riesgos y a la vez el cliente va experimentando los resultados

de su proyecto.



39

Dado que los proyectos de software son largos es común dividir el trabajo

en mini proyectos. Cada mini proyecto es una iteración que resulta en un

incremento. Para ser más efectivas las iteraciones deben ser controladas,

es decir deben ser seleccionadas y llevadas a cabo de una forma

planeada.

Se ha propuesto un proceso iterativo para garantizar la realimentación de

información y de requisitos una vez iniciado el desarrollo, así como la

validación continua del sistema. Esto permite que cada iteración

contemple ciclos de desarrollos completos y cortos, y obtener así

rápidamente, una nueva versión con mejoras sobre las versiones

anteriores.

Se ha propuesto un proceso incremental en el sentido de añadir

capacidades y funcionalidades al software de acuerdo con el crecimiento

de las necesidades; con el propósito de obtener el sistema final tras la

realización de diferentes ciclos. El final de cada ciclo proporciona además,

una versión estable del software. Esto permite entregas al cliente de

forma rápida y ágil.

Al entregar partes de la aplicación a tiempo y regularmente, el equipo de

desarrollo también gana y establece credibilidad en su entorno y aumenta

su auto-estima. A la vez que este tipo de estrategia se enfoca más en las

necesidades de los usuarios, instándolos a identificar sus prioridades en

cada etapa del proyecto.



40

A continuación detallamos las etapas por las cuales transita nuestro

proceso de desarrollo y la combinación de herramientas utilizadas en él.

3.3. ETAPAS DEL PROCESO DE DESARROLLO 3.3.1. Planificación Objetivo: Es la etapa más importante de todas, ya que se define el

proyecto propiamente dicho.

Tareas: Relevamiento preliminar de los procesos del negocio, definición y

secuenciamiento de actividades, definición del alcance, estimación de

tiempos, definición de recursos, análisis de riesgos, estimación de costos.

Entregables: Documento de definición del proyecto o del Sprint.

En esta etapa es importante aclarar que, al comienzo, la planificación se

realiza en forma general para determinar el alcance, la duración y el

precio del proyecto, una vez que el cliente decide llevarlo a cabo, las

siguientes planificaciones son a nivel de iteración, se planifica el Sprint.

3.3.2. Análisis Objetivo: Obtener todas las definiciones y especificaciones funcionales

para poder llevar adelante las fases de Diseño y Construcción. Es una

etapa clave ya que el alcance y las características de la solución quedan

acordados, lo cual permite mitigar los principales riesgos de un proyecto.



41

Tareas: Afianzamiento de las definiciones funcionales, definición de los

requisitos a través de casos de uso, planificación de las etapas

posteriores y ajuste de los tiempos preestablecidos.

Entregable: Documento de alcance, casos de uso y sus respectivas

descripciones.

3.3.3. Diseño Objetivo: Generar el modelo de datos para que la solución cumpla con

los requerimientos definidos. El diseño generado deberá contemplar las

posibles modificaciones futuras, crecimiento de la solución, mayor carga e

incorporación de nuevas funcionalidades.

Tareas: Diagrama Entidad Relación (DER), diseño de las interfaces de

usuario, diseño de las integraciones a realizar. Durante esta etapa

también se realizan pruebas para puntos críticos del proyecto.

Entregables: Entre los entregables típicos de esta etapa se encuentran:

DER, esqueleto del software armado, guía de diseño, diseño de la

infraestructura, y la planificación ajustada con la evolución y avances

obtenidos.

3.3.4. Construcción y Prueba Objetivo: Construir la solución del Release (Sprint), cumpliendo con las

definiciones y especificaciones de los documentos de alcance.



42

Generalmente es la etapa de mayor duración y con mayor dinámica de

trabajo.

Tareas: Programación y desarrollo de todos los componentes y

funcionalidades. Implementación de las estructuras de datos, y sus

procedimientos, elaboración de documentación técnica y ajustes

funcionales, implementación de las integraciones y todas las actividades

necesarias para poner en marcha la solución. En esta etapa se realizarán

las pruebas de usabilidad, funcionalidad y carga de datos.

Entregables: El entregable principal es el incremento de software

funcionando.

3.3.5. Implementación Objetivo: Disponer del sistema productivo con sus ambientes de

producción, metodología de trabajo y manuales operativos. Se incluye, de

ser necesario, el personal operativo capacitado. Obtención de nuevas

funciones a agregar o posibles errores a reparar.

Tareas: Puesta en marcha de la aplicación en el ambiente de producción,

elaboración de manuales operativos, y todas las actividades relacionadas

al éxito del lanzamiento como la integración del ambiente de producción

con terceras partes, etcétera.



43

Entregables: El sistema productivo con sus manuales operativos, de

mantenimiento y de procedimientos. Esquemas de auditoria y seguridad.

Integraciones con terceras partes operativas. Sistema totalmente

probado.

3.4. EDT DEL PROCESO DE DESARROLLO Presentamos nuestro proceso de desarrollo a través de una Estructura de

División del Trabajo para verlo gráficamente.

Proceso de desarrollo

Planificación

Análisis

Diseño

Construcción y Pruebas

Estimación Alcance

Estimación Tiempo

Releases

Actividades

Requerimientos

Modelo de datos

Interfases

Implementación

Modelo de negocio

Objetivos

Procesos

Especificaciones funcionales

Ajuste de tiempos

Puesta en marcha

Revisión y Retrospección

Carga de datos

Integración y pruebas

Programar



44

3.5. HERRAMIENTAS 3.5.1. Técnicas de relevamiento Entrevistas con el cliente y los usuarios; revisión de registros, y

observación.

3.5.2. Work Breakdown Structure (WBS) Conocida como Estructura de Descomposición de Trabajos (EDT). Es un

organigrama que despliega la estructura de un proyecto y muestra su

organización por fases y niveles de detalle. Cada nivel de descenso

representa un aumento en el nivel de detalle de las descripciones de las

actividades, sirve de lista de comprobación, y determina el alcance

general. Así como también, define los entregables del proyecto. Los

entregables pueden ser etapas o procesos del proyecto (plan del

proyecto, documentación de diseño, etc.) o partes del producto final

(pantallas, ventanas, documentación).

Se irá comentando a lo largo de este punto en cuales de las etapas de

desarrollo se aplican las herramientas explicadas. Entonces, tanto el WBS

como las técnicas de relevamiento mencionadas anteriormente se utilizan

en las dos primeras etapas, o sea para la Planificación y el Análisis.

3.5.3. Casos de uso Son un método práctico para explorar requerimientos. Ayudan a describir

qué es lo que el sistema debe hacer desde el punto de vista del usuario.

Por lo tanto, consideramos que los casos de uso proporcionan un modo

claro y preciso de comunicación con el cliente.



45

Descripciones de casos de uso: detallan los casos de uso, en ellas se

explica la forma de interactuar entre el sistema y el usuario.

Tanto los casos de uso como las descripciones de los mismos se utilizan

en la etapa del análisis para definir los requisitos.

3.5.4. Diagrama de actividades Sirven fundamentalmente para modelar el flujo de control entre

actividades. La idea es generar una especie de diagrama en el que se

puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así

como las tareas concurrentes que pueden realizarse a la vez. El diagrama

de actividades sirve para representar el sistema desde otra perspectiva.

Desde un punto de vista conceptual, la actividad es alguna tarea que

debe ser realizada. Por este motivo, en un diagrama de actividades

aparecerán acciones y actividades correspondientes a distintas clases;

colaborando todas ellas para conseguir un mismo fin.

Los diagramas de actividad son similares a los diagramas de flujo

procesales, con la diferencia de que todas las actividades están

claramente asociadas a un caso de uso. También se utilizan en la etapa

del análisis.

3.5.5. Diagrama de Entidad Relación (DER) Un modelo de datos describe de una forma abstracta cómo se

representan los datos, sea en una empresa, en un sistema de información

o en un sistema de base de datos.



46

Los DER son una herramienta para el modelado de datos de un sistema

de información. Estos diagramas expresan entidades relevantes y sus

inter-relaciones. Formalmente, son un lenguaje gráfico para describir

conceptos. Informalmente, son simples dibujos o gráficos que (si se saben

interpretar) describen la información que trata un sistema de información y

el software que lo automatiza.

Los DER se aplican en la etapa de Diseño.

3.5.6. ScrumWorks Permite llevar a cabo el seguimiento del proyecto. Es una herramienta de

automatización de procesos ágiles que admite a los equipos auto-

organizarse y aumentar la productividad. Esta herramienta, de acceso

libre y fácil de utilizar, es una aplicación Web que permite compartir la

información entre todo el equipo.

Esta herramienta para la administración del proyecto permite:

§ Manejar dinámicamente el Backlog de Producto haciendo una

estimación inicial del esfuerzo de cada requerimiento identificado

hasta el momento.

§ Definir las tareas y arrastrarlas al Sprint apropiado, donde se irán re-

estimando diariamente.

§ Observar un gráfico por cada Sprint que nos indica la velocidad con la

que avanza el proyecto.



47

Estos gráficos llamados “burndown” no sólo permiten observar el estado

de avance del proyecto, sino también analizar sus comportamientos e ir

aprendiendo para mejorar los Sprints que restan.

3.5.7. Burndown chart En Scrum se planifica y se mide el esfuerzo restante necesario para

desarrollar el producto. Esta gráfica suele utilizarse en lugar de un

diagrama de PERT debido a que el camino crítico en un desarrollo ágil

cambia diariamente. Esto haría obsoleto el diagrama de PERT cada día.

Es por esto que no es útil una herramienta que modele el camino crítico a

partir de actividades.

La solución es utilizar una técnica que permita medir la velocidad de

desarrollo, para ello se utiliza el criterio del equipo a partir del cual se

calcula diariamente el camino crítico. Esto permite recalcular el plan y la

velocidad en que se realiza el trabajo. En función de esto el equipo puede

trabajar para acelerar o desacelerar el trabajo para cumplir con la fecha

de entrega.

3.5.8. Clarion 5.5 Herramienta capaz de crear programas de 32 bits para Windows 9x, NT,

2000, y XP y para la Internet / Intranet / Extranet desde un único código y

con un diseñador de diccionario de datos integrado. Incluye drivers

nativos a distintos formatos de bases de datos (Oracle, MS SQL, Informix,

Btrieve, Pervasive SQ, ASCII, DOS/Basic, xBase) y bases de datos multi-

usuarios propietarias (Clarion y Topspeed).



48

El generador de aplicaciones junto con una serie de Templates (plantillas)

predefinidos y personalizables y las Clases ABC (Application Builder

Class), trabajan para producir código OOP (Programación Orientada a

Objetos) pre-testeado.

La base de la productividad es el Lenguaje 4GL, que está

específicamente creado para construir aplicaciones de negocios con

bases de datos propias o centralizadas. Se puede acceder virtualmente a

cualquier tipo de datos a través de una combinación de ODBC/ADO y los

drivers nativos de las bases.

TERCERA PARTE

DESARROLLO DE INGENIERÍA



50

4. PROYECTO TRAZABILIDAD

4.1. PLANIFICACION INICIAL 4.1.1. Solicitud del proyecto El presente proyecto surge de una solicitud realizada por un productor de

uva y propietario de tres fincas ubicadas en el departamento de Lavalle,

quien ha pedido la construcción de un Software de Trazabilidad que le

facilite la tarea de registración de todas las operaciones realizadas

durante el proceso de producción de cada una de sus propiedades, que

permita optimizar el manejo de información en el campo y demostrar que

se cumple con la trazabilidad.

Como todo cliente, y es lógico que así sea, de las dos primeras preguntas

de las cuales espera obtener respuesta son:

¿Para cuándo va a estar listo?

¿Cuánto va a costar?

Para dar respuesta a ellas se decidió tener tres entrevistas con el

potencial cliente con el objetivo de comprender el porqué de la solicitud,

determinar más en detalle sus necesidades, y conocer su situación actual,

entonces, a partir de ello, elaborar la propuesta comercial.

4.1.2. El porqué de la solicitud del proyecto La solicitud del proyecto de desarrollar un Software de Trazabilidad para

la producción de uva nace a partir de las amenazas que han surgido en el



51

mundo en materia de seguridad que han llevado a EE.UU. y a la Unión

Europea (UE) a adoptar severas medidas en los procedimientos de

importación de productos, especialmente los alimentos para uso humano

y animal. La situación que se presenta en la actualidad parte de un

principio general de prohibición que establece que no se comercializarán

alimentos que no sean seguros, que por definición reglamentaria

comprende tanto aquellos que sean nocivos para la salud, como los que

no sean aptos para el consumo humano.

En el sector agroalimentario la calidad debe constituir, ante todo, una

garantía de protección de la salud humana y, en consecuencia, este

aspecto representa hoy el núcleo alrededor del cual se establecen las

exigencias para la producción y la comercialización de los alimentos.

Este problema viene a ser asistido por las normas de calidad en general y

por la trazabilidad en particular. El 1º de Mayo de 2005 entró en vigencia

la normativa para la comercialización de productos con la Unión Europea,

Reglamento (CE) N° 178/2002 que se refiere específicamente a la

trazabilidad en la producción.

La trazabilidad es un hecho, la UE la ha convertido en un requisito y

contempla distintos procedimientos a seguir. Inclusive, podemos esperar

que otros países le sigan en su requerimiento. La previsión es que la

nueva norma afecta a las etapas de producción, transformación,

elaboración, distribución y comercialización alimentaria.



52

Poco antes de su aplicabilidad, surgen las dudas sobre si todos los

operadores presentes a lo largo de la cadena alimentaria están

preparados para asumir las obligaciones que provienen de la normativa

comunitaria. La preocupación se ha instalado en algunos sectores,

especialmente en la producción primaria, que en algunos supuestos

concretos ya se han manifestado como incapaces de cumplimentarlos en

este breve espacio de tiempo, conocedores de la responsabilidad que

asumen cuando el resto de los eslabones ya han dispuesto medidas para

adaptarse a estos nuevos requisitos normativos.

La trazabilidad, sin embargo, no es la única causa de esta situación de

seguridad, aunque sí es un elemento que contribuye decisivamente y una

herramienta útil para los productores. Las empresas del sector

frutihortícola tienen un importante reto ante los consumidores y ante sí

mismos: pueden contemplar la nueva legislación como un problema o

como una oportunidad para lograr que sus productos sean mejor

valorados y compitan con ciertas ventajas con productos de otros países

que no aplican los estrictos criterios de los que se ha dotado la UE. Si,

además, la aplicación de la trazabilidad permite acceder a mercados

tradicionalmente exigentes como EEUU, las empresas empezarán a

obtener beneficios tangibles y más participación en el mercado.

4.1.3. Evaluación de la información deseada Una vez comprendido el porqué de la solicitud del proyecto, se

determinan las necesidades del cliente. Es decir, se establecen los

aspectos que debe abarcar el Software de Trazabilidad.



53

No obstante, previo al desarrollo del producto, se hará una pequeña

investigación sobre la producción de uva y vino, sus exportaciones a

países de la Unión Europea; así como también, las normativas vigentes

referentes a la trazabilidad, la importancia de la misma y alternativas para

aplicarla. Esta investigación será el primer entregable que se dará al

cliente.

Con respecto al Software de Trazabilidad debe permitir conocer la historia

de la uva a través del ciclo de producción; identificar el cómo, quién,

cuándo, dónde y por qué se hizo en cualquier etapa de la cadena

agrícola. Debe poder identificar los productos, hasta el momento en que el

operador realice su entrega al siguiente eslabón en la cadena.

El software deberá mantener un registro de las propiedades rurales,

identificando para cada una de ellas sus titulares y/o productores, y para

cada viñedo la distribución de sus cuarteles, origen de los mismos, el tipo

de conducción y las variedades de uva que contempla.

Administrar datos de titulares y/o productores, trabajadores, proveedores

y bodegas.

Administrar las maquinarias y camiones, con sus revisiones técnicas y

seguros de transportes correspondientes.



54

Permitir predefinir las tareas y tratamientos agrícolas habituales a fin de

simplificar su identificación en el momento de su aplicación e indicando,

para cada labor realizada, los insumos, agroquímicos, dosis y métodos

de aplicación utilizados. En todos los casos debe identificarse un

responsable, que se encargue tanto de la operación como de su

respectivo registro.

Registrar en forma rápida y sencilla cada uno de los partes de las tareas

agrícolas que se realizan en la finca, que contienen información como:

tarea que se realizó, duración, trabajador, máquinas y agroquímicos

utilizados.

Registrar en forma rápida y sencilla cada uno de los remitos de cosecha

que se efectúan durante la vendimia, que contienen información como:

finca, cuartel, cosechador, kilos, camión, bodega destino, etc.

Permitir la captura automática del peso de las cajas o bins proveniente de

la báscula. El sistema debe dar la opción de que la captura sea

automática o manual.

Ver la trazabilidad de los productos en ambos sentidos. Realizar consultas

sobre la cosecha de uva y las auditorias.

Administrar usuarios. Permitir diferentes niveles de acceso al sistema.



55

A esta altura ya se cuenta con una noción general de lo que el software

debe realizar, por lo tanto resta conocer realmente cual es la situación

actual del cliente y de sus propiedades.

4.1.4. Situación actual A continuación se describe la situación actual ante la cual se encuentra el

cliente, es decir, la forma en la que se manejan sus propiedades rurales

hasta el momento.

En dichas propiedades, nunca se ha contado con un sistema informático,

todo queda asentado en papel. Se lleva un registro completo y detallado

del personal. Pero, aparte de ello, son muy pocas la tareas de campo que

se registran, quedando éstas prácticamente reducidas a la etapa de la

vendimia, donde se deja asentada una información mínima de lo que se

ha cosechado. Dicha registración, que se realiza manualmente, queda en

planillas y también en lo que es denominado el Libro de Campo.

Esta manera de operar imposibilita llevar un control de las actividades

realizadas durante todo el proceso de producción y manifiesta la

incapacidad de contar con información rápida y precisa en el momento

que se solicite.

Debido a la época del año en la que nos encontramos (Octubre de 2005),

muy cercanos a la próxima cosecha; el cliente nos ha pedido que el

software esté listo para Marzo de 2006. Por lo tanto contamos con 6



56

meses (Octubre – Marzo) para entregar el software de Trazabilidad

terminado.

4.1.5. Estructura de División del Trabajo (EDT) Al inicio no se cuenta con mucha información o entendimiento de todos

los requisitos del proyecto para desarrollar un EDT completo. Por lo tanto,

desarrollaremos un EDT de alto nivel que permita obtener una visión

general del alcance del proyecto.

Software de Trazabilidad

Investigación

Datos

Comprobantes

Consultas

Producto

Trazabilidad

Cosecha

Parte agrario

Remito de cosecha

Administrador

Datos generales

Usuarios

Auditorias

Acciones de auditoria

Trazabilidad

Entidades



57

4.1.6. Conformación del equipo humano A la hora de elaborar un presupuesto y calcular la fecha de entrega del

producto final debemos conocer de cuanta gente se dispone para trabajar

en el proyecto.

El equipo de trabajo para llevar a cabo el Software de Trazabilidad estará

conformado solamente por dos personas que cumplen los diferentes

roles. Uno de los miembros del equipo (quien les escribe) hará las veces

de programador y Scrum Master. El otro miembro del equipo efectuará los

roles de Product Owner, Cliente y Usuario final del sistema.

Por lo tanto, hay a una sola persona disponible para trabajar en el

desarrollo del software. El tiempo que se dedicará al mismo es una

jornada de medio día, 20 horas semanales aproximadamente.

4.1.7. Estimación del plazo de entrega y precio En base al EDT se arma una tabla para obtener una primera estimación

general del proyecto, y poder así determinar su duración y precio. Como

podemos observar en la primera columna se listan las principales

actividades del proyecto y se establecen para cada una de ellas su

esfuerzo expresado en horas que demanda aproximadamente realizar

cada actividad.



58

Actividades Cantidad Esfuerzo (hs) Unitario

Esfuerzo (hs) Subtotal

Planificación 6 4 24

Investigación Producto 1 32 32

Investigación Trazabilidad 1 32 32

ABM de Datos generales 18 8 144

ABM de Entidades 5 12 60

Comprobante Parte Agrario 2 12 24

Comprob. Remito de Cosecha 2 12 24

Consulta de Cosecha 2 16 32

Consulta de Trazabilidad 2 16 32

Consulta de Auditoria 1 20 20

Implementación 5 8 40

Total (horas) 464

Vale la pena aclarar que para estimar las actividades se tuvo en cuenta

que cada una de ellas pasa por las etapas de análisis, diseño,

construcción y prueba. Las etapas de planificación e implementación se

realizan a nivel de Sprint al inicio y al final respectivamente.

Bien, ya sabemos que el proyecto completo demandará una duración

estimada de 464 horas, 64 para la etapa de investigación y 400 para el

desarrollo del software. Ahora falta conocer cual será nuestro costo de

desarrollo por hora y así, poder calcular el precio que se pasará en el

presupuesto.



59

Algunas consideraciones a tener en cuenta son que el software será

desarrollado en forma particular, por lo tanto no se incurrirán en gastos

del tipo alquiler de oficina, impuestos, traslados diarios, etc.

El costo de desarrollo por hora se calcula en base a:

§ Consumo eléctrico por hora: $0,038

§ Consumo de Internet por hora: $0,153

§ Desgaste del equipo: $0,211

Llegamos a la conclusión de que nuestro costo por hora de desarrollo es

de $0,40; lo que al mes equivale a $32,00 (con base en 80 hs

mensuales).

Otro gasto que debe tenerse en cuenta es el traslado cada vez que se

visiten las propiedades rurales, ubicadas aproximadamente a 70 km de la

Ciudad de Mendoza. Se supone que durante los 6 meses de duración del

proyecto se realizarán 8 viajes. Y que el costo de cada uno de ellos será

de $53,00. En el cálculo te tuvo en cuenta, además del combustible,

desgaste del vehículo, seguro, etc.

Podemos decir entonces que la suma de los gastos durante los 6 meses

de duración del proyecto ascenderá a $456,00 aproximadamente.



60

4.1.8. Gestión de riesgo Todos los proyectos, sin excepción, tienen implícito algún tipo de riesgo. Y

éste no tiene relación alguna con el tamaño del proyecto. La

administración del riesgo es necesaria y consiste en analizarlos y

controlarlos de manera efectiva. Para ello, se identifican los riesgos

potenciales, se valora su probabilidad de ocurrencia y su impacto y se

establece una prioridad según su importancia.

Los criterios de puntuación de riesgos que se han definido para la

probabilidad e impacto son los siguientes: Muy bajo (1); Bajo (2); Medio

(3); Alto (4); Muy alto (5).

Identificación. Análisis cualitativo y cuantitativo del riesgo Riesgo Probabilidad Impacto Puntaje Prioridad

Cliente no comprometido Media Alto 12 2º Insatisfacción del cliente Baja Muy Alto 10 3º Falta de comunicación (cliente) Media Alto 12 2º Estimación del tamaño baja Media Alto 12 2º Cambio en el alcance Alta Media 12 2º Fecha de entrega ajustada Muy alta Media 15 1º Falta de experiencia técnica y de proyectos

Alta Baja 8 4º

Se ha definido la siguiente política para la selección de estrategias: Puntaje del riesgo Estrategia

15 - 25 Evitar 6 - 14 Reducir 3 - 5 Aceptar activamente 1 - 2 Aceptar pasivamente

Una vez que los riesgos han sido identificados, calculados y priorizados,

se concibe un plan de respuesta para dichos riesgos.



61

Plan de respuesta al riesgo Riesgo Estrategia Acción

Fecha de entrega ajustada Evitar Renegociar alcance

Cliente no comprometido Reducir

Firmar los acuerdos de reuniones, planificación y aceptación de requerimientos. Fijar un responsable del proyecto por parte del cliente. Fijar un cronograma de reuniones.

Falta de comunicación con el cliente Reducir

Fijar un responsable del proyecto por parte del cliente. Fijar un cronograma de reuniones.

Estimación del tamaño baja Reducir Hacer re-estimar el proyecto a un colega.

Cambio en el alcance Reducir Especificación detallada y firmada por el cliente.

Insatisfacción del cliente Reducir Aumentar la comunicación. Desarrollar la relación.

Falta de experiencia técnica y de proyectos Reducir

Tomar capacitaciones sobre la administración de proyectos. Consultar a profesionales del medio.

Este será nuestro plan y las acciones que deberemos tomar para atenuar

los riesgos identificados.

4.1.9. Propuesta comercial Con toda la información recaudada y analizada hasta el momento se

elabora la propuesta comercial que se entrega a nuestro posible futuro

cliente. La misma se presenta en el Anexo A de esta obra. En resumen, el

presupuesto arrojó los siguientes valores:

§ Precio por hora: $25,00.-

§ Precio total: $11.600,00.-



62

4.2. HERRAMIENTAS EXISTENTES EN EL MERCADO En el presente apartado se exponen las características más importantes

de algunas de las herramientas que actualmente se encuentran en el

mercado, para ofrecerlas también como una alternativa.

Software: KontrolFrux - Empresa: Arkios (Argentina)

• Captura en tiempo real. Con colectoras de datos portátiles se registran

todos los movimientos de mercadería en la planta.

• Brinda información en tiempo real sobre producción, recursos,

controles de calidad, y analiza la integración del negocio desde las

unidades productivas hasta la llegada a destino del producto.

• Mediante la utilización de códigos de barra y lectores láser, se logra

tener la trazabilidad por unidad productiva.

• Parametrizable para lograr la integración con otros sistemas, tales

como los ERP, u otros desarrollos específicos de la empresa.

• Consulta en línea.

• Precio: $5.000 por cada lugar físico donde se instale el sistema.

Software: e-FLEXWARE Bodegas - Empresa: BEJERMAN (Argentina)

• Administra el trabajo realizado en la viña identificando y asociando los

elementos que intervienen en cada tarea.

• Efectúa un seguimiento estricto de la maduración de la uva.



63

• Permite efectuar comparaciones entre diferentes años.

• Refleja los ingresos a la Bodega indicando para caja viaje de uva su

procedencia.

• El módulo de Producción es uno más que se puede integrar al

Sistema e-Flexware ERP, es decir no es un módulo que pueda

venderse en forma independiente.

• Para un Sistema de gestión monousuario, hay que pensar en una idea

de inversión de aproximadamente $10.000.

Software: Packing - Empresa: COMPUAGRO (Chile)

• Software desarrollado para el control de producción, en línea (tiempo

real), donde la información es minuto a minuto y detallada.

• Control total de Trazabilidad (Caja, Pallet, Bins).

• Control de inventarios de materiales e integración con Agro2000 para

el pago de remuneraciones de acuerdo a la producción del día.

• Herramienta que le permite programar sus embarques, controlando el

cumplimiento del instructivo (el numero de pallet especifico).

• Emite los informes necesarios para las inspecciones SAG y otros.

• Etiquetado de cajas con la información que requiera.

• Cierre de proceso por productor o viñedo.



64

• Precio: $4.500 por cada lugar físico donde se instale el sistema.

Hay que tener en cuenta que a todos los sistemas que hagan captura en

tiempo real, al importe del software hay que sumarle la inversión en la

compra del equipamiento, colectores de datos, etc. para poder llevarla a

cabo.

Luego de haberse realizado un análisis sobre dichas herramientas, se

llega a la conclusión de que todas ellas están orientadas a satisfacer las

necesidades de grandes empresas. Pero la realidad es que existen más

empresas pequeñas que grandes, y las soluciones hasta ahora

presentadas están dirigidas a la parte superior de la pirámide.

Una vez comparadas estas alternativas con nuestro presupuesto, el

cliente decide aceptar la propuesta comercial por las siguientes razones:

ü Desea tener su propio software, elaborado a medida para él.

Considera que las alternativas existentes no se adaptan a lo que

necesita.

ü Quiere tener un software sencillo y fácil de manejar (solución

intermedia).

ü No quiere correr el riesgo de que se conozcan sus datos.



65

4.3. COMENZANDO CON SCRUM A esta altura nos encontramos en condiciones de comenzar con el

desarrollo del proyecto utilizando Scrum.

El primer paso es comenzar a armar el Backlog de Producto. Inicialmente

colocamos en él los requerimientos de la etapa de investigación, que será

la primera que llevaremos a cabo; luego colocamos los requerimientos

que fueron identificados a partir de los casos de uso en la planificación

inicial del proyecto (que forma parte del análisis) y que luego fueron

priorizados por el cliente.

Como se observa en el siguiente gráfico (leer de abajo hacia arriba), el

Backlog contiene inicialmente todos los requerimientos definidos hasta el

momento estimados en horas de esfuerzo.



66

Backlog del producto

Si bien toda la gestión del proyecto se lleva a cabo con ScrumWorks,

tanto el Backlog de Producto como los Backlogs de Sprints son

dinámicos. Los requerimientos colocados en el Backlog de Producto se

van pasando a los Backlogs de Sprints y las tareas detalladas en éstos se



67

re-estiman diariamente. Por lo tanto, se irán presentando de esta manera

las variaciones del Backlog de Producto y de los Backlogs de Sprints.

4.3.1. Primer Sprint Planificación Objetivo: El objetivo del primer Sprint es realizar la investigación sobre la

necesidad y la importancia de la trazabilidad en la producción agraria,

conocer el Reglamento que la define y también el producto sobre el que

se aplicará, más específicamente la producción de uva.

Alcance: El alcance abarca el módulo de Investigación previo al

desarrollo del software.

Como se puede observar en el siguiente gráfico se presenta el primer

Sprint con sus tareas definidas y estimadas en horas, vale aclarar que es

la estimación inicial y que este es el único de tres semanas; los Sprints

restantes serán de 4 semanas.

Como desarrollo de este primer Sprint se presenta el Anexo B. En el cual

se detalla el informe realizado que es el primer entregable del cliente.



68

Backlog de Sprint

Burndown chart



69

En la gráfica, que es el Burndown chart del primer Sprint, puede

observarse cómo se han ido reestimando diariamente las tareas. Entre los

días 14 y 24 de Octubre la línea se hace menos pronunciada, eso denota

un problema o un impedimento que está causando un leve retraso en el

Sprint. En este caso, el motivo de la demora fue tener que buscar y leer

mucha información, que en definitiva, hacían muy lento el avance de la

investigación. Para el día 25 se llevaban 4 días de atraso, por lo tanto, se

optó por trabajar el último fin de semana del Sprint para poder cumplir con

el objetivo del mismo.

Se ha mostrado la reestimación de las tareas aprovechando que es el

Sprint más corto de todos, para los próximos se presentará solamente la

gráfica.

A continuación volvemos a presentar el Backlog de Producto. En el cual

podemos observar que los requerimientos de la etapa de investigación ya

no están y solamente se encuentran los restantes, los del sistema

propiamente dicho. Se recuerda leer de abajo hacia arriba el Backlog de

Producto.

Como los requerimientos ya están priorizados, sólo falta definir cuáles de

ellos conformarán el segundo Sprint.



70

Backlog de Producto



71

4.3.2. Segundo Sprint Planificación Objetivo: Comenzar con el desarrollo de los primeros requerimientos que

se encuentran actualmente en el Backlog para obtener la primera versión

funcional del software.

Alcance: El alcance del segundo Sprint abarca parte del módulo de

Datos, se seleccionan las primeras 8 aplicaciones para carga de datos.

Backlog de Sprint

Como puede observarse en el siguiente gráfico se presenta el segundo

Sprint con sus tareas definidas y sus estimaciones iniciales en horas.

Debido a que todos los requerimientos tienen definidas las mismas tareas

(excepto Planificación e Implementación) y a los efectos de que el gráfico

no sea tan extenso se ha desplegado solamente el primer requerimiento.

Las tareas definidas para cada requerimiento transitan por todas las

etapas especificadas en nuestro proceso de desarrollo:

Describir el caso de uso à Análisis

Modelado de datos à Análisis y Diseño

Crear el formulario à Diseño y Construcción

Compilar y Probar à Construcción y Prueba



72

Para ver el análisis y el diseño del sistema se invita a consultar los

Anexos C y D respectivamente, que si bien se fueron construyendo de

forma iterativa, allí se encuentran completos.

Burndown chart



73

En esta gráfica vemos el ritmo al que fue avanzando el segundo Sprint. Al

haberse subestimado algunas tareas pero sobrestimado otras, se

compensaron las horas y se cumplió en tiempo y forma al final del Sprint.

A continuación volvemos a presentar el Backlog de Producto.

Backlog de Producto



74

4.3.3. Tercer Sprint Planificación Objetivo: Continuar con el desarrollo de los requerimientos para obtener

la segunda versión funcional del software.

Alcance: El alcance del tercer Sprint abarca parte del módulo de Datos,

se seleccionan 7 aplicaciones más para carga de datos.

Backlog de Sprint



75

Burndown chart

En este Sprint puede observarse que al haber aprendido del Sprint

anterior y tener éste el mismo tipo de requerimientos se logró cumplir con

el objetivo del Sprint sin dificultades.




76

4.3.4. Cuarto Sprint Planificación Objetivo: Continuar con el desarrollo de los requerimientos para obtener

la tercera versión funcional del software.

Alcance: El alcance del cuarto Sprint abarca parte del módulo de Datos,

se seleccionan 8 aplicaciones más para carga de datos.

Backlog de Sprint



77

Burndown chart

Como podemos ver, el ritmo de avance al comienzo de este Sprint se

presenta constante pero hacia la finalización del mismo la gráfica se hace

más irregular lo que significa que se presentaron inconvenientes en una

de las aplicaciones, de todas maneras se llevaron a cabo todas las tareas

planificadas.

En esta oportunidad luego de la implementación surgió un reclamo por un

error en la aplicación Agroquímicos, por lo tanto se incorporó como un

nuevo requerimiento al Backlog de Producto para su corrección. Será el

primer requisito con el que se inicie el siguiente Sprint.




78

Backlog de Producto

4.3.5. Quinto Sprint Planificación Objetivo: Continuar con el desarrollo de los requerimientos para obtener

la cuarta versión funcional del software.

Alcance: El alcance del quinto Sprint abarca, en primer lugar, la

corrección del error, la última aplicación del módulo Datos y el módulo

Comprobantes, son 6 aplicaciones.



79

Backlog de Sprint

Burndown chart



80

En este Sprint, al revés que en el anterior, el avance se hizo muy lento al

comienzo, debido a que llevó más tiempo de lo previsto corregir el error

de la aplicación Agroquímicos. Otro motivo de demora fue que el cliente,

debido al comienzo de la cosecha, no estaba disponible para despejar

dudas y realizar consultas; situación que se regularizó hacia el fin del

Sprint.

De todas maneras, una de las tareas Conocer la Trazabilidad por Tareas

no alcanzó a completarse, por lo tanto volvió como requerimiento al

Backlog. El cual se vuelve a presentar por última vez y los requerimientos

que figuran en él son los que integran el sexto Sprint.

Puede observarse que la suma del esfuerzo da 100 horas, lo que significa

que estamos retrasados aproximadamente 20 horas (1 semana). Se

decide por tal motivo renegociar con el cliente la fecha de entrega y se fija

como nueva fecha el día 7 de abril. Nuestro último Sprint será de 5

semanas para lograr cumplir con el objetivo.



81

4.3.6. Sexto Sprint Planificación Objetivo: Continuar con el desarrollo de los requerimientos para obtener

la quinta y última versión funcional del software.

Alcance: El alcance del sexto Sprint abarca, en primer lugar, completar la

tarea pendiente del Sprint anterior, y realizar el módulo de Consultas, son

5 aplicaciones.

Backlog de Sprint



82

Burndown chart

El último Sprint, como lo muestra la gráfica, sufrió de varias subas y bajas

que se lograron ir compensando para poder alcanzar el objetivo. Una vez

implementada la última versión funcional que completa el producto,

podemos reflexionar acerca del resultado de nuestro proyecto.

El proyecto que en sus inicios fue estimado en 464 horas consumió 488

horas, por lo tanto, la entrega al cliente del último Release se hizo una

semana después de lo presupuestado al comienzo del proyecto.

Pensamos que esta demora puede considerarse aceptable.

La experiencia de haber utilizado Scrum como método para gestionar y

llevar a cabo el seguimiento del proyecto a resultado muy grata. A través

de él se ha logrado controlar la velocidad de avance del proyecto de

forma eficaz. Esto permitió en el último Sprint detectar prontamente el

retraso y comunicarlo al cliente de inmediato para pactar una nueva fecha

de entrega. El hecho de estar organizado y saber lo que realmente

quedaba por delante causó un efecto positivo en el cliente, quien mientras

tanto tenía sobre que trabajar gracias a las entregas mensuales que se le

fueron realizando.

ANEXOS



84

ANEXO A

PROPUESTA COMERCIAL

Mendoza, 3 de Octubre de 2005.- Sr. Xxx Presente A través de la presente me dirijo a Ud. con el fin de hacerle llegar el presupuesto elaborado a partir de la planificación inicial del sistema. Producto: Software de Trazabilidad Objetivo del sistema El objetivo es desarrollar una solución específica para pequeños y medianos productores que permita registrar y controlar todas las actividades que se efectúan en la propiedad rural. Un sistema que tenga como premisa fundamental una precisa identificación de la producción desde el cultivo, los procesos asociados, la cosecha, así como también el transporte hasta su destino final, la bodega. Todo ello resuelto en un entorno gráfico y amigable que permita a quienes lo operen manejarse con absoluta solvencia desde el primer día. Alcance del sistema El alcance del sistema abarcará: desde la preparación de la tierra para el cultivo hasta el transporte del producto agrario en camiones después de la vendimia. El desarrollo del sistema comprenderá las siguientes aplicaciones: ü Administración de propiedades rurales. Datos sobre las mismas,

administración de cuarteles y titulares por propiedad.



85

ü Administración de titulares. Ver propiedades por titular. ü Administración de variedades de uva, tipos de conducción del

viñedo y enfermedades de la vid. ü Administración de personal y sus capacitaciones realizadas.

ü Administración de proveedores.

ü Administración de agroquímicos y métodos de aplicación de

agroquímicos. ü Administrar maquinarias y camiones con sus respectivas revisiones

técnicas. ü Administrar compañías de seguro y pólizas de seguro.

ü Administrar tipos de tareas agrarias.

ü Administrar bodegas (clientes) y delegaciones del INV.

ü Administrar usuarios para darles diferentes niveles de acceso al

sistema. ü Registro de la entrada de las materias primas. Una vez grabada

una nota de entrada no podrá modificarse y solamente el usuario administrador podrá eliminarla.

ü Registro de diario de tareas realizadas. Una vez grabado un parte

de tareas no podrá modificarse y solamente el usuario administrador podrá eliminarlo.

ü Registro de la cosecha. Una vez grabado un remito de cosecha no

podrá modificarse y solamente el usuario administrador podrá eliminarlo.

ü Consulta de cosecha.

ü Consulta de trazabilidad.

ü Consulta de auditoria.

ü Informes de cosecha, de trazabilidad y de auditoria.



86

Límite del sistema El software abarcará solamente la etapa de producción primaria dentro de la cadena agroalimentaria, su límite geográfico será la propiedad rural. Consideraciones técnicas El desarrollo se llevará acabo con el lenguaje de programación Clarion 5.5 utilizando el motor de base se datos Topspeed. Si bien son herramientas para operar en un entorno Windows, haciendo los ajustes necesarios, también se puede correr en Linux. Requisitos de hardware Estos son los requisitos mínimos de hardware que deberá tener cada equipo sobre el que se corra el sistema. • Intel Pentium lll o AMD K7 (Recomendado Pentium lV o Athlon) • 128 MB Memoria RAM (Recomendado 256MB de RAM) • 4 GB de Disco Rígido (Recomendado 8GB de Disco Rígido) • Resolución de pantalla 800 x 600 (Recomendado 1024 x 768)

Plazo de entrega A partir de la aceptación de la presente propuesta se realizará una entrega mensual por cada uno de los 6 meses de duración del proyecto. Aclaración: las fechas o los plazos pueden variar en caso de que surjan modificaciones imprevistas durante el desarrollo del sistema. Remuneración y Forma de pago Por el desarrollo e implementación del sistema en tres (3) puestos de trabajo se facturará el total de pesos once mil seiscientos ($11.600,00). Debido a que el software se irá implementando parcialmente, dicho monto se cobrará en 6 cuotas iguales de pesos mil novecientos treinta y tres con treinta y tres centavos ($1.933,33) cada una. Por estar los montos de la presente propuesta expresados en pesos su validez es de 14 días corridos a partir de la fecha de la misma. Sin otro particular, y a la espera de una respuesta, saluda muy atentamente. María Laura Citón



87

ANEXO B

INVESTIGACIÓN

INTRODUCCIÓN La presente investigación se desarrolla al comienzo del proyecto con el

objetivo de conocer el Reglamento que define la trazabilidad y también el

producto sobre el que se aplicará.

La investigación se divide en dos partes, en la primera de ellas se

describe la situación de la producción de uva y vino en nuestro país, y se

realiza un breve análisis sobre las exportaciones a los países que

actualmente exigen la trazabilidad en los productos que importan, entre

ellos, el vino Argentino.

En la segunda parte se detalla la normativa que define la trazabilidad y

sus características más importantes entre las que se encuentran: tipos de

trazabilidad, ventajas de tenerla, fases y alternativas para aplicarla.



88

PRODUCCIÓN DE UVA Y VINO EN ARGENTINA

PRODUCCIÓN DE UVA La cadena productiva vitivinícola está constituida por un conjunto de

eslabones o fases a partir de la producción de uva. Las uvas son el fruto

de la vid y suelen tener distintos destinos.

El destino más importante en el ámbito nacional e internacional se

canaliza hacia la producción de vinos y mostos. En la Argentina hay que

distinguir entre variedades para vinificar comunes y de alta calidad

enológica.

Otro destino de la uva es el deshidratado para la elaboración de pasas.

En Argentina hay cultivadas variedades de vid específicas para este

destino. Por último, hay un grupo de variedades que han sido

seleccionadas para ser consumidas en fresco, aunque

circunstancialmente pueden ser destinadas a la vinificación o a pasas.

Caracterización de las áreas implantadas con vid Argentina se posiciona como el principal corazón vitivinícola de América

del Sur. La mayoría de los cultivos se encuentran ubicados en las

provincias de Mendoza y San Juan, que integran la región de Cuyo, la

zona vitivinícola más importante del país.



89

Ubicación: Centro Oeste de la Argentina, al pie de la Cordillera de Los

Andes, entre los 30° a 50º de latitud sur y a una altitud promedio de 500 m

sobre el nivel del mar, en donde se presentan las mejores condiciones de

clima y suelo.

Superficie implantada con vid en Argentina La provincia de Mendoza es la principal productora de vid, con una

producción que representa el 70% del total nacional. Le sigue la provincia

de San Juan con una porcentaje menor, pero igualmente destacable,

llegando al 22% del total producido. Ambas provincias producen más del

90% del total nacional. Le siguen, La Rioja (4%), Río Negro (1,33%),

Catamarca (1,11%) y Salta (0.91%).

Superficie plantada - Año 2004 Distribución por provincias

22,72%

4,07%3,82%

69,39%

MendozaSan JuanLa RiojaResto

La transformación que ha sufrido el sector vitivinícola abarca todas las

etapas de la cadena productiva. En el plano de la producción primaria se

asiste a una contracción significativa de la superficie implantada, cantidad

de viñedos y producción de uva. Entre 1990 y 2004, la superficie

Fuente INV Fuente INV



90

implantada de uva se redujo de 320 mil hectáreas a 210 mil hectáreas y la

cantidad de viñedos pasó de 52.418 a 26.093.

Esta reducción se ve acompañada por una renovación de las

plantaciones, con un acentuado desplazamiento de la uva criolla por

distintas variedades de uvas finas, de superior valor enológico. Se

reconvirtió parte de la superficie implantada con avanzados sistemas de

conducción, tecnologías de riego y de protección y manejo de los cultivos,

además de capacitación de recursos humanos. El conjunto de las

modificaciones en la producción primaria apuntaló un incremento de la

productividad que se ha profundizado desde mediados de la última

década.

PRODUCCIÓN DE VINO La elaboración de vinos demanda casi la totalidad de la materia prima,

alcanzando casi el 97% en el año 2004.

Producción de uva - Año 2004Total país - Quintales métricos en %

1,84% 1,63%

96,53%

Consumo en frescoPasasVinificación

Fuente INV



91

Argentina en el mundo Uvas

ü Superficie cultivada de vid: 210.530 hectáreas (26.093 viñedos) - 10º

en el mundo.

ü Producción de uvas: 8º productor mundial.

ü Exportador de pasas de uva: 10º exportador mundial.

Vinos

ü Elaboración de vinos: 5º productor mundial.

ü Consumo de vinos per cápita: (33 litros anuales) - 6° en el mundo.

ü Exportación de vino: 11º exportador mundial.

ü Exportación de mosto: 1° exportador mundial.

Argentina ocupa una posición destacada entre los países de América del

Sur, aún frente a uno de sus competidores en el mercado externo, Chile.

PAIS Superficie con Vid

Producción de Uva

Elaboración de Vino

Consumo de Vino

ARGENTINA 52% 48% 61% 69%

CHILE 32% 32% 21% 10%

BRASIL 14% 17% 13% 14%

URUGUAY 2% 3% 5% 6%

PARAGUAY 0% 0% 0% 1% Fuente: SAGPyA.

Variedades de alta calidad enológica Como se mencionó anteriormente, la producción de uva fina en las

últimas dos décadas presenta una tendencia creciente. Esta tendencia



92

está motivada por una mayor demanda de uvas de alta calidad enológica

por parte de la industria vitivinícola, con motivo del aumento del consumo

de vinos finos y la disminución de vinos comunes tanto en el mercado

interno como en el externo.

Las variedades para elaborar vinos finos representan aproximadamente el

25% de la superficie con variedades de vinificar. Debido a las excelentes

condiciones agro-ecológicas que presenta Argentina, es posible producir

una amplia gama de estas variedades.

Identificación de la demanda En el plano internacional se asiste, desde hace ya varios años, a un

proceso de paulatina y persistente contracción en el consumo de vinos

comunes, caída que tiende a constituirse en un rasgo permanente del

sector. Pese a ello, paralelamente se ha verificado una expansión

acelerada en el crecimiento del consumo de vinos finos.

Los países que más participan en el consumo de vino son Luxemburgo

(63 litros al año per capita), Italia (57 litros), Francia (55 litros) y Portugal

(43 litros). Nuestro país 33 litros y ocupando el sexto lugar en el mercado

mundial y el primero en Sudamérica.

En general todos los países con tradición vitivinícola han experimentado

una leve, pero constante baja en el consumo a partir del comienzo de la

década de los noventa y continúa la tendencia, pese a que la calidad de



93

los vinos mejora notoriamente, sin embargo la caída de los valores está

concentrada en los consumidores jóvenes del mundo.

Consumo anual de v inos - Año 2004

0 10 20 30 40 50 60 70

Reino Unido

Paises Bajos

Australia

Alemania

Argentina

España

Portugal

Francia

Italia

Luxemburgo

Litros per capita

Análisis estadístico de destino Los principales países importadores de vinos, a nivel mundial, son

Alemania (20,96% del total de las importaciones internacionales) y Reino

Unido (16,32%). Por el contrario, los principales exportadores son Francia

(21% del total de las exportaciones internacionales), Italia (18%) y España

(17%), ubicándose Argentina en el puesto 11 del ranking (exporta el 4%

de la totalidad de las ventas mundiales).

Para establecer la teoría sobre la necesidad de la trazabilidad en la

vitivinicultura Argentina se ha realizado un análisis sobre las

exportaciones, llegando a la conclusión de que los países destinatarios de

nuestros vinos exigen el cumplimiento de la trazabilidad de los mismos.



94

En los últimos 10 años, Argentina experimentó un crecimiento en las

exportaciones de vinos. Tanto si se toman en cuenta los hectolitros

exportados como si se hace lo propio con las divisas pagadas por dichos

hectolitros. Argentina pasó de exportar 1.260.000 hectolitros en 1995 a

1.995.000 en el 2004 en todas sus variedades. Si se toman en cuenta los

valores monetarios, Argentina pasó de exportar U$S 49.000.000 en 1995

a U$S 190.000.000 en el 2004.

Exportaciones totales de vino (1995 - 2004)

0

500.000

1.000.000

1.500.000

2.000.000

2.500.000

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004$ 0

$ 50.000

$ 100.000

$ 150.000

$ 200.000HectolitrosMiles de dólares

Exportaciones Argentinas de Vinos - Año 2004Principales 12 paises

050.000

100.000150.000200.000250.000

EEUU

Paragu

ay

Reino U

nido

Rusia

Brasil

Canad

aJa

pon

Dinamarc

a

Paises

Bajos

Aleman

ia

Francia

Urugua

y010.00020.00030.00040.00050.000Hectolitros

Miles de dólares



95

Exportaciones Argentinas de Vinos - Año 2004 Paises de la UE

050.000

100.000150.000200.000250.000

Reino U

nido

Dinamarc

a

Paises

Bajo

s

Aleman

ia

Francia

Repúb

lica C

heca

Finlan

dia

Suecia

Irland

a

Bélgica

Polonia Ita

lia

Españ

a

05.00010.00015.00020.00025.00030.00035.000Hectolitros

Miles de dólares

Dirección Nacional de Alimentación, en base a datos del INV.

Tras analizar los datos expuestos podemos deducir que la trazabilidad es

más que importante, ya que el 32,57% de nuestras exportaciones de

vinos son a países de la Unión Europea (UE), dónde la trazabilidad es

obligatoria. Este porcentaje representa U$S 87.754.860, lo que es una

suma más que importante en el área de las exportaciones.

No podemos dejar de mencionar que a EEUU se exporta el 15.23% que

representa U$S 45.266.000.

Podemos decir, en base a estos números, que a partir de Mayo del 2005

una de cada dos botellas de vinos finos exportables a los mercados ya

conocidos por los productores de vinos argentinos deberá tener en orden

su trazabilidad y documentación que respalde sus actividades. De esta

manera, Argentina que ya tiene una fuerte presencia en mercados de

consumo exigente, al contar con la trazabilidad de sus vinos y mostos



96

podrá expandir tanto su oferta de productos como los mercados de

destinos. De allí la importancia de cumplir con este requerimiento de los

mercados.

En esta primera parte de la investigación llegamos a la conclusión que la

eficiencia en los procesos productivos hacen indispensable conocer la

trazabilidad de toda la producción para seguir siendo competitivo. Por

consiguiente, en la producción moderna no se concibe un producto sin

sus datos de trazabilidad. Es por ello que dedicaremos a este tema el

próximo apartado.

TRAZABILIDAD

CONCEPTO GENERAL Según la definición presente en la Norma ISO 9000:2000, trazabilidad es

“la capacidad para seguir la historia, la aplicación o la localización de todo

aquello que está bajo consideración.”

Para un producto esta relacionada a:

• El origen de los materiales y sus partes.

• La historia del procesamiento.

• La distribución y la localización del producto después de su entrega.



97

REGLAMENTO (CE) N° 178/2002 Esta normativa, que entró en vigencia en Febrero de 2002, pero que es

aplicable a partir del 1 de Mayo de 2005, establece los principios y los

requisitos generales de la legislación alimentaria, crea la Autoridad

Europea de Seguridad Alimentaria y fija los procedimientos relativos a la

seguridad alimentaria.

En el presente apartado se abordarán las siguientes cuestiones:

§ Definición (artículo 3 inciso 15);

§ Trazabilidad (artículo 18);

Definición El Reglamento 178/2002 del Parlamento Europeo y del Consejo, en su

artículo 3 inciso 15 presenta una definición más específica referida a

productos alimentarios, y expresa:

Trazabilidad es “la posibilidad de encontrar y seguir el rastro, a través de

todas las etapas de producción, transformación y distribución, de un

alimento, un pienso, un animal destinado a la producción de alimentos o

una sustancia destinados a ser incorporados en alimentos o piensos o

con probabilidad de serlo”.

En otras palabras podemos decir que la trazabilidad son aquellos

procedimientos preestablecidos y autosuficientes que permiten conocer el

histórico, la ubicación y la trayectoria de un producto o lote de productos a



98

lo largo de la cadena de suministros en un momento dado, a través de

herramientas determinadas.

Dicha trazabilidad consiste en asociar sistemáticamente un flujo de

información a un flujo físico de mercaderías de manera que se pueda

relacionar en un momento dado la información requerida relativa a los

lotes o grupos de productos determinados.

Artículo 18 – Trazabilidad 1. En todas las etapas de la producción, la transformación y la distribución

deberá asegurarse la trazabilidad de los alimentos, los piensos, los

animales destinados a la producción de alimentos y de cualquier otra

sustancia destinada a ser incorporada en un alimento o un pienso, o con

probabilidad de serlo.

2. Los explotadores de empresas alimentarias y de empresas de piensos

deberán poder identificar a cualquier persona que les haya suministrado

un alimento, un pienso, un animal destinado a la producción de alimentos,

o cualquier sustancia destinada a ser incorporada en un alimento o un

pienso, o con probabilidad de serlo.

Para tal fin, dichos explotadores pondrán en práctica sistemas y

procedimientos que permitan poner esta información a disposición de las

autoridades competentes si éstas así lo solicitan.

3. Los explotadores de empresas alimentarias y de empresas de piensos

deberán poner en práctica sistemas y procedimientos para identificar a las

empresas a las que hayan suministrado sus productos. Pondrán esta



99

información a disposición de las autoridades competentes si éstas así lo

solicitan.

4. Los alimentos o los piensos comercializados o con probabilidad de

comercializarse en la Comunidad deberán estar adecuadamente

etiquetados o identificados para facilitar su trazabilidad mediante

documentación o información pertinentes, de acuerdo con los requisitos

pertinentes de disposiciones más específicas.

5. Podrán adoptarse disposiciones para la aplicación de lo dispuesto en el

presente artículo en relación con sectores específicos de acuerdo con el

procedimiento contemplado en el apartado 2 del artículo 58.

La trazabilidad persigue diferentes objetivos y entre los más importantes

se destacan la seguridad alimentaria, el comercio justo entre

explotadores, y la fiabilidad de la información facilitada a los

consumidores.

Lo que se pretende con la trazabilidad es garantizar que se puede

proceder a retiradas o recuperaciones específicas y precisas de

productos, que es posible facilitar a los consumidores y a los explotadores

de empresas alimentarias información apropiada, que las autoridades de

control pueden llevar a cabo determinaciones del riesgo y que puede

evitarse una mayor perturbación innecesaria del comercio.

El artículo 18 exige a los explotadores de empresas alimentarias que:



100

á puedan identificar quién ha suministrado un producto y quién ha

sido su destinatario;

á pongan en práctica sistemas y procedimientos que permitan poner

esta información a disposición de las autoridades competentes si

éstas así lo solicitan.

Este requisito se basa en el planteamiento «un paso atrás y un paso

adelante», para los explotadores de empresas alimentarias, supone que:

á deberán poner en práctica un sistema que les permita identificar a

los proveedores y a los clientes inmediatos de sus productos;

á se establecerá un vínculo «proveedor-producto» (qué productos han

sido suministrados por qué proveedores);

á se establecerá un vínculo «cliente-producto» (qué productos han

sido suministrados a qué clientes); sin embargo, los explotadores de

empresas alimentarias no tienen que identificar a los clientes

inmediatos cuando éstos sean consumidores finales.

La redacción del artículo 18 hace incidencia en el objetivo y el resultado

previstos sin prescribir la forma de alcanzar ese resultado.

Usuario Usuario Usuario Usuario Usuario



101

Sin embargo, la exigencia de mantener un sistema de Trazabilidad surge

de la siguiente necesidad: cuando se produce un reclamo por inocuidad o

un daño en la salud de un consumidor, el proveedor de un producto debe

poder identificar y retirar (Recall) del mercado todas las unidades que

podrían presentar el mismo problema.

TIPOS DE TRAZABILIDAD Teniendo en cuenta las definiciones expuestas en el punto anterior, se

pueden describir tres ámbitos de trazabilidad existentes:

Trazabilidad hacia adelante o rastreabilidad: es la capacidad de seguir

el camino de un producto a través de la cadena de abastecimiento,

mientras éste se mueve entre las organizaciones. Los productos son

rastreados rutinariamente en busca de su obsolescencia, manejo de

inventario, propósitos logísticos y, conocer a partir de una materia prima el

producto final del que ha formado parte. Productor à Minorista.

Trazabilidad hacia atrás: es la capacidad de identificar el origen de una

unidad particular o de un lote de productos ubicados dentro de la cadena

de abastecimiento, de acuerdo a referencia de registros que tuvieron lugar

contracorriente en dicha cadena. Los productos se localizan con

propósitos tales como la anulación de los mismos, investigación de

reclamos, u obtener a partir de un producto intermedio o final la

información relevante asociada a un determinado producto hasta llegar al

origen de las materias primas. Minorista à Productor.



102

Trazabilidad interna o de procesos: es la capacidad de trazar a lo largo

del proceso de producción. Por lo tanto, desde el punto de vista de una

organización, la trazabilidad del proceso permitirá vincular los productos

que entran en una empresa con los que salen.

VENTAJAS QUE APORTA LA TRAZABILIDAD Un buen sistema de trazabilidad en la cadena alimentaria no sólo juega

un importante papel en la protección de los intereses del consumidor, sino

que, además, aporta grandes beneficios para las organizaciones.

ü Lograr un nivel elevado de protección de la vida y la salud de las

personas.

ü Cumplir con las normativas.

ü Obtener información de los proveedores.

ü Controlar la evolución de productos y procesos.

ü Establecer una ventaja competitiva.

ü Detectar, acotar y analizar problemas con gran celeridad.

ü Retirar selectivamente productos con alguna incidencia.

ü Minimizar costos de retiradas de productos.

TIPO DE INFORMACIÓN QUE DEBE REGISTRASE El artículo 18 no especifica el tipo de información que deben registrar los

explotadores de empresas de alimento. Sin embargo, para cumplir su

objetivo, se considera necesario que se registre la información que se

detalla a continuación. Esta información puede clasificarse en dos

categorías según su grado de prioridad:



103

La primera categoría de información incluye todos los datos que deberán

ponerse a disposición de las autoridades competentes en todos los casos:

§ Datos del proveedor y naturaleza de los productos que suministró.

§ Datos del cliente y naturaleza de los productos que se le

entregaron.

§ Fecha de la transacción / entrega.

La segunda categoría de información incluye otros datos cuyo registro se

recomienda encarecidamente:

§ Volumen o cantidad.

§ Número de lote.

§ Descripción detallada del producto (producto preenvasado o a

granel, variedad de fruta/verdura, producto crudo o transformado).

La información que vaya a registrarse se seleccionará atendiendo a la

actividad de la empresa (naturaleza y tamaño) y a las características del

sistema de trazabilidad.

FASES PARA LA IMPLANTACIÓN DEL SISTEMA El Artículo 18 del Reglamento 178/2002 impone una obligación genérica

de trazabilidad en cada una de las etapas de la cadena agroalimentaria.

Sin embargo, es importante destacar que el Artículo 18 no impone

específicamente de qué forma, ni a través de qué medios, los operadores

económicos de empresas alimentarias deben conseguir este objetivo.



104

Por ello, los operadores podrán elegir libremente entre una gran variedad

de sistemas y herramientas a su disposición, siempre que cumplan su

objetivo final. Se podrán utilizar desde procedimientos manuales sobre

papel hasta tecnologías con soportes informáticos, electrónicos, de radio

frecuencias etc. Los operadores pueden también elegir la forma de

identificar los productos y la forma de recoger y almacenar la información

citada.

A continuación, y a modo de orientación, se establecen unas pautas de

actuación que cada empresa deberá adaptar a sus circunstancias y

características. Las fases para la correcta implantación del sistema

pueden ser:

Estudiar los sistemas de archivos previos En primer lugar, se deberá estudiar detenidamente los procedimientos de

archivos (su contenido y sistemática) que este utilizando la organización,

que generalmente son libros o planillas de registro, y evaluar si con ellos

se cumple el objetivo de trazabilidad.

En algunos casos, las empresas pueden encontrarse con que ya están

haciendo todo lo necesario para conseguir la trazabilidad. En otros, podría

ser necesario generar nuevos archivos o adaptar los procedimientos

existentes.

Es importante destacar que un sistema de trazabilidad no tiene porqué ser

complicado. El mejor sistema de trazabilidad para una organización es



105

aquel que encaje con sus actividades de trabajo habituales y permita

registrar la información necesaria a la que luego se pueda acceder de

forma fácil y rápida. Estudiar detenidamente el sistema de trazabilidad de

la empresa permite sacar beneficio de la información que el sistema

genera.

Consultar con proveedores y clientes Previamente a la implantación del sistema es recomendable:

▬ Consultar con proveedores y clientes.

▬ Pedir consejo a otras partes implicadas: otras empresas,

consultoras, auditores, autoridades de control.

▬ Solicitar sus registros a proveedores y clientes, ya que éstos han

de ser coherentes y acordes entre operadores.

▬ Informarse de si existen recomendaciones o guías voluntarias de

trazabilidad para empresas del sector.

Definir el ámbito de aplicación El sistema de trazabilidad que se implante en cada empresa desde el

eslabón anterior hasta el eslabón posterior, debe ayudar a mantener la

trazabilidad en toda la cadena alimentaria. Dependiendo de la actividad

dentro de la cadena alimentaria, el sistema puede necesitar: trazabilidad hacia atrás, interna o de proceso, y/o hacia adelante.

El Artículo 18 sólo impone al operador económico de la empresa

alimentaria la obligación legal de identificar a su proveedor inmediato y a

su cliente inmediato. Sin embargo, debe hacerse la siguiente



106

consideración para que se cumplan los objetivos: en la mayoría de las

actividades desarrolladas por las empresas alimentarias, es necesario

vincular lo que entra con lo que sale o, lo que es lo mismo, disponer de

una trazabilidad interna de forma más o menos desarrollada.

A continuación se cita, a modo de ejemplo, el ámbito de aplicación de

trazabilidad para la producción primaria: requerirán un sistema de

trazabilidad basado en la trazabilidad hacia atrás (ej: recopilar información

sobre el vivero, productos fitosanitarios, biocidas, etc.), interna (ej.

información sobre las labores de cultivo realizadas, con especial

referencia a aquellas prácticas que puedan tener una repercusión sobre la

higiene y seguridad de los cultivos) y trazabilidad hacia adelante

(información del cliente al que se destina el producto agrario).

Definir criterios para la agrupación de productos Para poder aplicar cualquier sistema de trazabilidad, cada empresa debe

agrupar de alguna forma el conjunto de unidades que produce, fabrica,

envasa o, en términos amplios, maneja y, además, la agrupación debe ser

identificada.

El Real Decreto 1808/91 define lote como: “un conjunto de unidades de

venta de un producto alimenticio producido, fabricado o envasado en

circunstancias prácticamente idénticas”.



107

La composición del lote es un punto crítico en este proceso. Determina la

exactitud de todo sistema de trazabilidad. Cuanto más homogéneos son

los lotes, más exacto será el sistema de trazabilidad.

La empresa del sector primario puede configurar sus agrupaciones según

diferentes criterios, entre los que se pueden encontrar uno o varios de los

siguientes:

§ Periodo de tiempo: horario, diario, semanal

§ Línea de producción

§ Parcela o cuartel

§ Lugar y fecha de captura

En relación con la identificación, existe una gran variedad de sistemas

disponibles, desde etiquetas escritas a mano, hasta códigos de barras y

chip de radio frecuencia. La utilización de identificadores estandarizados,

tales como los códigos de barras EAN para materiales etiquetados que se

comercializan entre empresas, facilita la circulación de los datos a través

de la cadena alimentaria.

Ningún sistema de identificación es adecuado en todas y cada una de las

circunstancias. Y, hasta dentro de una misma empresa puede ser

conveniente utilizar diferentes tipos de identificación.



108

Establecer registros y documentación necesaria Es conveniente que la documentación del sistema de trazabilidad

implantado en una empresa incluya:

§ Ámbito de aplicación del sistema

§ Descripción y características del mismo

§ Registros de las operaciones efectuadas

§ Procedimiento de revisión y actualización del sistema

En el apartado 3.5 se especificó la información que conviene registrar y

que se señala a continuación a modo de recordatorio.

Trazabilidad hacia atrás:

De quién se reciben los productos / Qué se ha recibido exactamente /

Cuándo / Qué se hizo con los productos cuando se recibieron

Trazabilidad de proceso (interna):

Cuando los productos se dividen, cambian o mezclan / Qué es lo que se

crea / A partir de qué se crea / Cómo se crea / Cuándo / Identificación del

producto final

Trazabilidad hacia adelante:

A quién se entrega / Qué se ha vendido exactamente / Cuándo

Las acciones o la información del producto útil para la trazabilidad pueden

registrarse:



109

§ En hojas de datos sobre papel que acompañan a cada agrupación

a lo largo de todos los procesos con carácter interno dentro de una

misma empresa.

§ Mediante las Tecnologías de Información, que tienen gran

capacidad de archivo en menor espacio y que, además, pueden

incluir: recogida automática de datos y equipamiento, tal como

impresoras de etiquetas y lectores de códigos de barras, que llevan

consigo otras eficiencias operacionales.

Plazo de conservación de los registros El artículo 18 no prevé un período mínimo de tiempo en el que deberá

conservarse la información, pero se puede considerar que los

documentos comerciales han de conservarse, por lo general, durante

cinco años a efectos fiscales. Este período de cinco años, aplicado a la

información pertinente a efectos de trazabilidad, satisfaría probablemente

el objetivo del artículo 18.

Establecer mecanismos de validación / verificación por

parte de la empresa Conviene revisar habitualmente el sistema para comprobar que funciona

de forma efectiva y registrar que tal comprobación se ha producido. El

sistema debe evaluarse teniendo en cuenta:

ü la exactitud de la información almacenada,

ü el tiempo de respuesta, que deberá ser el mínimo posible, ya que

pueden existir riesgos para la salud de las personas.



110

Es útil hacer, regularmente, un simulacro de demanda de la información

sobre trazabilidad. Los inspectores, incluso los clientes, pueden participar

y sugerir “casos prácticos” para comprobar que la información de

trazabilidad puede recogerse de forma fiable y rápida.

Por ejemplo, se tomará un producto al azar y se comprobará si se pueden

conocer las materias primas y los procesos tecnológicos sufridos.

También se verá si, a partir de una documentación de una materia prima,

se puede conocer el producto del que ha formado parte y su distribución.

Establecer mecanismos de comunicación inter-empresas Conseguir la trazabilidad a lo largo de toda la cadena compete a todos los

eslabones. Es responsabilidad de cada uno evitar que se quiebre la

trazabilidad en el eslabón que representa, porque si ello ocurriese pueden

verse perjudicados operadores que estén cumpliendo suficientemente con

el desarrollo del sistema de trazabilidad en su establecimiento.

Muchas empresas ya piden que sus proveedores compartan con ellos la

información sobre trazabilidad. Resulta muy positivo establecer protocolos

o mecanismos comunes sobre cómo compartir la identificación y la

información. Por ello, es muy útil mantener conversaciones con los

proveedores y clientes para acordar entre todos qué información

(composición, origen, etc.), es crítica y para asegurar que se proporciona

de una forma clara y comprensible.



111

HERRAMIENTAS DE TRAZABILIDAD EAN.UCC La introducción de los estándares EAN.UCC puede mejorar la eficiencia

de registrar e intercambiar información entre los integrantes de la cadena

de abastecimiento. Cuando se los usa juntamente con bases de datos

que contienen registros exactos y puntuales, los estándares EAN.UCC

proporcionan a los participantes de la cadena la capacidad técnica para

ver el origen de un producto, en sus propias localizaciones y a través de

toda la cadena de abastecimiento.

Números Mundiales de Artículo Comercial EAN.UCC Mientras el aspecto más visible de la numeración del artículo es el código

de barra, ésta es solo una representación de un número, leído por una

máquina. El número es el elemento más importante en el sistema

EAN.UCC, porque identifica el artículo al cual ha sido asignado.

El sistema de numeración EAN.UCC proporciona una unidad mundial y

supera problemas de confusión, duplicaciones y mala interpretación,

porque todos los usuarios del sistema EAN.UCC siguen las mismas

reglas de código. Un número EAN.UCC puede reconocerse, no solo por

las empresas comerciales locales, sino también, por otras operando en el

exterior. Cada número EAN.UCC es único a lo ancho del mundo, por lo

tanto no hay posibilidad de confusión. El sistema de numeración

EAN.UCC también proporciona a los artículos la habilidad para

transportar, dentro de la convención numérica, información extra o de

atributos de los mismos.



112

Códigos de barra EAN.UCC

Los códigos de barra son transportadores de datos. El código de barra se

usa en el sistema EAN.UCC para representar los números EAN.UCC.

Los códigos de barra EAN.UCC permiten la captura automática de datos,

lo que significa una solución comercial clave, dentro de una eficiente

cadena de abastecimiento. La numeración EAN.UCC y el sistema de

codificación de barra, permiten la entrada rápida y exacta de los datos, a

los sistemas de computadora, automatizando el flujo de información

dentro de los procesos comerciales. También permiten la captura

mejorada de datos y la transferencia de información, al tiempo que se

reducen los costos.

El sistema EAN.UCC es la mejor práctica para implementar trazabilidad

porque este estándar es único, global, genérico, voluntario y esta

disponible para el uso de todas las compañías, facilitando la identificación

de productos y el intercambio de información. Si el estándar es utilizado

adecuadamente por todos los eslabones de la cadena de abastecimiento,

se logrará alinear el flujo de producto y el flujo de información, que es la

base del concepto de trazabilidad.

ALTERNATIVAS DE IMPLEMENTACIÓN Alternativas para implementar un sistema de trazabilidad:

Ø Manual sin sistema de información.

Ø Manual con sistema de información.

Ø Automatizado con código de barras.



113

Trazabilidad Manual (Sin Sistema de Información) • Se basa en el mantenimiento de registros físicos (por ejemplo planillas)

acerca de los lotes que la empresa produce.

• Implica un buen archivo físico de información para facilitar la búsqueda

cuando se requiere.

• Implica tiempo por parte de la mano de obra en el diligenciamiento de

las planillas y la administración del archivo.

• Cuando la empresa es grande, recuperar la información acerca de un

lote normalmente implica un tiempo significativo.

• Hay riesgo por errores de diligenciamiento de la información en las

planillas.

• Baja inversión de capital en el montaje del sistema.

Trazabilidad Manual (Con Sistema de Información) • Se basa en el mantenimiento de registros en un sistema de información


• Implica tramitar planillas físicas dentro del proceso, las cuales son

digitadas posteriormente en el sistema.

• Requiere tiempo en el diligenciamiento de las planillas y en la digitación

en el sistema.



114

• La velocidad de respuesta se incrementa dado que el sistema permite

tener información a mayor velocidad.

• Se mantiene el riesgo por errores en el diligenciamiento de las planillas y

por errores de digitación en el sistema.

• Requiere inversiones medianas de capital en el montaje del sistema.

Trazabilidad Automatizada (Con Código de Barras) • Se basa en el mantenimiento de registros en un sistema de información


• Implica contar con un sistema de información robusto que soporte la

generación y captura de información con código de barras y el

almacenamiento de la información de trazabilidad.

• El tiempo de llenado de planillas y la digitación en el sistema se reduce

por el proceso de captura.

• La velocidad de respuesta se incrementa dado que se puede tener

información en línea (por ejemplo: uso de radiofrecuencia).

• Se reduce el riesgo por errores de digitación, pero se mantiene el riesgo

de errores en el momento de la captura del código de barras.

• Requiere inversiones entre medianas y altas de capital en el montaje del

sistema, el etiquetado de productos y otros elementos del sistema.



115

Comparativa Alternativa Tiempo

(digitación) Velocidad /

Confiabilidad de respuesta

Riesgo errores (digitación /

captura)

Inversión

Manual Alto Baja Alto Baja

Manual + SI Alto Media Alto Media

Automatizada + CB Bajo Alta Medio Alta

¿Cuál es el mejor sistema para mi empresa? Alternativa ¿Para quién es adecuada?

Manual Empresas pequeñas con poca vocación exportadora, que manejan pocas referencias, pocos lotes de producción y tienen pocos clientes.

Manual + SI

Empresas pequeñas con capacidad de inversión en un sistema de información cuyo mercado exija algo de velocidad en la respuesta, que manejan varias referencias, varios lotes de producción y varios clientes.

Automatizada + CB Empresas medianas y grandes con vocación exportadora hacia mercados y clientes exigentes, con muchas referencias y lotes de producción.

Luego de analizar estas tres alternativas se optó por desarrollar la opción

intermedia, es decir, manual con sistema de información, ya es la más

acertada para el tipo de organización para la cual se construirá el

software.



116

ANEXO C

ANÁLISIS DEL SISTEMA

MODELO DE NEGOCIO

Objetivos estratégicos y procesos del negocio El objetivo de modelar el proceso de negocio es capturar el esquema

general y los procedimientos que gobiernan el negocio. Este modelo

provee una descripción de dónde se va a ajustar el sistema de software

considerado dentro de la estructura organizacional y de las actividades

habituales.

Como un modelo preliminar del negocio, permite al analista capturar los

eventos, las entradas, los recursos y las salidas más importantes

vinculadas con el proceso de negocio. Es posible construir un modelo

completamente trazable mediante la posterior conexión de elementos de

análisis (tales como los casos de uso) a través de conectores de

implementación, desde la generalidad del proceso de negocio a los

requisitos funcionales y eventualmente a los artefactos de software que se

construirán realmente.

El primer paso consiste en capturar los procesos de negocio a partir de

los objetivos principales de la organización. Teniendo en cuenta que éstos

van a ser muy complejos y de un nivel de abstracción muy alto, serán

descompuestos en subobjetivos más específicos. Para cada uno de ellos

se define un proceso de negocio que deberá dar soporte a dicho

subobjetivo. Lo recién expresado lo podemos observar en el siguiente

cuadro.



117

Objetivos estratégicos Subobjetivos Procesos

Cumplir con los requisitos legales

Realizar la trazabilidad de los productos

Registrar datos entrantes. Registrar proceso de producción. Registrar salida del producto.

Optimizar el manejo de la información en el campo

Minimizar los tiempos de retirada de productos

Identificar y ubicar eficientemente los productos dentro de la cadena.

Aumentar el control y la seguridad de la información

Realizar auditorias

Tener diferentes niveles de acceso al sistema. Conocer movimientos de auditorias.

A continuación se representa, a través de Diagramas de Actividades, los

tres primeros procesos anteriormente definidos, y que serán definitiva los

que nos permitirán llevar a cabo la trazabilidad del producto.

Diagramas de Actividades



118

Este primer diagrama de actividad es a nivel general. A continuación se

realizará la explotación de las actividades Explotación del viñedo y

Vendimia para analizarlas con detalle. Hemos utilizado los Diagramas de

Actividades para explicar el planteamiento funcional del sistema.



119

IDENTIFICACIÓN DE REQUERIMIENTOS Para llegar a obtener un listado exhaustivo de los requerimientos iniciales

del sistema comenzaremos identificando los casos de uso, se adoptó la

utilización de los mismos porque se considera que aportan una forma

sencilla de comunicación con el cliente.

Actores del sistema

Usuario: actor con ciertas restricciones sobre las

funcionalidades del sistema.

Administrador: actor sin restricciones sobre las

funcionalidades del sistema.

Relación entre actores: Herencia

Usuario

Administrador



120

Casos de uso Este diagrama de casos de uso de primer nivel permite tener una visión

general de los procesos de la organización, así como también permite

mostrar los límites y el entorno de la organización bajo estudio.

Explotación del caso de uso Logearse en el sistema.

Ingresar clave

Cambiar clave

Usuario

Registrar datos entrantes

Registrar proceso de producción

Registrar salida del producto

Identificar y ubicar efectiva/ los productos dentro de la cadena

Realizar auditorias

Logearse en el sistema


121

Manejar Agroquímicos

Manejar Maquinaria

Manejar Camiones

Administrar Fincas

Administrar Titulares

Administrar Proveedore

Administrar Personal Manejar

Bodegas

Administrar Cuarteles x finca

Conocer capacitaciones x

Administrar

Administrar Conducc. viñedo

Manejar Mét. apl.

Conocer Titulares x Finca

Manejar Cias. seguros

Conocer Rev. técnicas

Manejar Delegac. INV

Administrador

Usuario

Administrar Usuarios

Manejar Enferm. vid

Conocer Fincas x Titulares

Administrar acciones de auditoria

Manejar seguros

Administrar Tareas



122

Explotación del caso de uso Registrar proceso de producción.

Explotación del caso de uso Registrar salida del producto.

Explotación del caso de uso Realizar auditorias.

Conocer la Trazabilidad Registrar

tareas diarias

Usuario

Asentar remito de cosecha

Pesar cajas

Consultar mov. auditorias x


Consultar mov. auditorias x usuario

Consultar cosecha de

Usuario


Usuario



123

Lista exhaustiva de requerimientos Ítem Requisitos Orden 1 Ingresar clave 1 2 Cambiar clave 3 3 Administrar titulares 4 4 Administrar fincas 9 5 Administrar cuarteles por finca 10 6 Administrar tipos de conducción del viñedo 7 7 Administrar variedades de uva 6 8 Manejar enfermedades de la vid 8 9 Administrar personal 13 10 Conocer capacitaciones por personal 14 11 Conocer titulares por finca 11 12 Conocer fincas por titular 12 13 Manejar delegaciones del INV 5 14 Manejar bodegas 24 15 Manejar seguros de transportes 22 16 Manejar compañías de seguros 21 17 Manejar camiones 20 18 Conocer revisiones técnicas 23 19 Manejar maquinarias 19 20 Manejar métodos de aplicación de agroquímicos 18 21 Manejar agroquímicos 17 22 Administrar proveedores 15 23 Administrar tareas agrícolas 16 24 Administrar acciones de auditoria 25 25 Administrar usuarios 2 26 Registrar tareas diarias 26 27 Conocer la trazabilidad 33 28 Asentar remito de cosecha 27 29 Consultar cosecha de uva 28 30 Consultar movimientos de auditoria por usuarios 29 31 Consultar movimientos de auditoria por fecha 30 32 Consultar movimientos de auditoria por acción de auditoria 31 33 Consultar movimientos de auditoria por comprobantes 32

Esta lista, armada en conjunto con el cliente, contiene todos los requisitos

del sistema detectados hasta el momento. Se han priorizado según la

importancia que tienen para el cliente teniendo en cuenta la fecha de

entrega. Esto permite convertir un objetivo irrealizable en uno “difícil” pero

realista. Esta lista será en definitiva nuestro primer Backlog de Producto.



124

Descripciones de casos de uso

Id. requisito: R01 Nombre: Ingresar clave Fecha: 16/12/2005 Descripción: Permite el ingreso al sistema

Actores: Usuario / Administrador del sistema

Precondiciones: Usuario dado de alta en el sistema

Flujo normal: 1. El usuario ingresa su nombre de usuario 2. El usuario ingresa su contraseña 3. El sistema valida los datos introducidos y entra al sistema

Flujo alternativo: 3. El sistema comprueba la validez de los datos, si los datos no son los correctos,

avisa al actor de ello y cierra la ventana.

Poscondiones: El usuario ingresa al sistema

Referencias: R25 Id. requisito: R02 Nombre: Cambiar clave Fecha: 16/12/2005 Descripción: Permite cambiar la clave de ingreso al sistema


Precondiciones: Usuario logueado

Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El usuario ingresa su nombre de usuario y su contraseña actual 3. El usuario ingresa su nueva clave y la confirmación de ella 4. El sistema valida los datos introducidos y almacena el cambio


avisa al actor de ello y cierra la ventana.

Poscondiones: El cambio de clave es almacenado en el sistema

Referencias: R25



125

Id. requisito: R03 Nombre: Administrar titulares Fecha: 16/12/2005 Descripción: Permite altas, bajas y modificaciones de titulares de fincas



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de los titulares existentes y los botones Agregar,

Cambiar y Borrar 3. El usuario agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena


avisa al actor de ello permitiéndole que los corrija.

Poscondiones: El nuevo registro, el cambio o la eliminación queda almacenado en el sistema.

Referencias: R04, R17, R19 Id. requisito: R04 Nombre: Administrar fincas Fecha: 16/12/2005 Descripción: Permite altas, bajas y modificaciones de propiedades rurales


Precondiciones: Usuario logueado.

Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las propiedades rurales existentes y los botones

Agregar, Cambiar y Borrar 3. El usuario agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R03, R05, R13, R26, R28



126

Id. requisito: R05 Nombre: Administrar cuarteles x finca Fecha: 16/12/2005 Descripción: Permite altas, bajas y modificaciones de cuarteles



Flujo normal: 1. El usuario ingresa al ABM de fincas y selecciona una de ellas 2. El usuario pulsa el botón Cambiar y luego en la solapa Cuarteles 3. El sistema muestra un listado de los cuartes existentes y los botones Agregar,

Cambiar y Borrar 4. El usuario agrega, modifica, o borra el registro 5. El sistema valida los datos y almacena los cambios




Referencias: R04, R06, R07, R26, R28 Id. requisito: R06 Nombre: Administrar conducción del viñedo Fecha: 16/12/2005 Descripción: Permite altas, bajas y modificaciones de los tipos de conducción del viñedo



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de los tipos de conducción ya ingresados y los

botones Agregar, Cambiar y Borrar 3. El usuario agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R05



127

Id. requisito: R07 Nombre: Administrar variedades de uva Fecha: 16/12/2005 Descripción: Permite altas, bajas y modificaciones de variedades de uva



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las variedades de uva existentes y los botones





Referencias: R05, R26, R28 Id. requisito: R08 Nombre: Manejar enfermedades de la vid Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de enfermedades de la vid



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las enfermedades existentes y los botones





Referencias: R21



128

Id. requisito: R09 Nombre: Administrar personal Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones del personal



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado del personal existentes y los botones Agregar,





Referencias: R10, R26, R28 Id. requisito: R10 Nombre: Conocer capacitaciones por personal Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de las capacitaciones por personal



Flujo normal: 1. El usuario ingresa al ABM de Personal y selecciona un trabajador 2. El usuario pulsa el botón Cambiar y luego en la solapa Capacitaciones 3. El sistema muestra un listado de las capacitaciones existentes de ese trabajador

y los botones Agregar, Cambiar y Borrar 4. El usuario agrega, modifica, o borra el registro 5. El sistema valida los datos y almacena los cambios

Flujo alternativo: 5. El sistema comprueba la validez de los datos y los almacena.


Referencias: R09



129

Id. requisito: R11 Nombre: Conocer titulares por finca Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de los titulares por finca



Flujo normal: 1. El usuario ingresa al ABM de Fincas y selecciona una de ellas 2. El usuario pulsa el botón Cambiar y luego en la solapa Titulares 3. El sistema muestra un listado de los titulares existentes y los botones Agregar,

Cambiar y Borrar 4. El usuario agrega, modifica, o borra el registro 5. El sistema valida los datos y almacena los cambios




Referencias: R03, R04 Id. requisito: R12 Nombre: Conocer fincas por titular Fecha: 19/12/2005 Descripción: Permite conocer las fincas por titular



Flujo normal: 1. El usuario ingresa al ABM de Titulares y selecciona una de ellas 2. El usuario pulsa el botón Cambiar y luego en la solapa Fincas 3. El sistema muestra un listado de las propiedades existentes para dicho titular 4. El usuario sale con el botón Aceptar

Flujo alternativo: No se presenta

Poscondiones: El sistema vuelve a la pantalla principal del ABM.

Referencias: R03, R04



130

Id. requisito: R13 Nombre: Manejar delegaciones del INV Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de delegaciones del INV



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las delegaciones existentes y los botones





Referencias: R04, R14 Id. requisito: R14 Nombre: Manejar bodegas Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de bodegas



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las bodegas ya ingresadas y los botones








131

Id. requisito: R15 Nombre: Manejar seguros Fecha: 20/12/2005 Descripción: Permite altas, bajas y modificaciones de seguros de transporte



Flujo normal: 1. El usuario ingresa al ABM de Camiones y selecciona uno de ellos 2. El usuario pulsa el botón Cambiar 3. El sistema muestra un listado de los seguros existentes para dicho camión y los

botones Agregar, Cambiar y Borrar 4. El usuario agrega, modifica, o borra el registro 5. El sistema valida los datos y almacena los cambios




Referencias: R16, R17 Id. requisito: R16 Nombre: Manejar compañías de seguros Fecha: 19/12/2005 Descripción: Permite altas, bajas y modificaciones de compañías de seguros



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las compañías ya ingresadas y los botones


Flujo alternativo: 4.El sistema comprueba la validez de los datos, si los datos no son los correctos, avisa

al actor de ello permitiéndole que los corrija.


Referencias: R15



132

Id. requisito: R17 Nombre: Manejar camiones Fecha: 20/12/2005 Descripción: Permite altas, bajas y modificaciones de camiones



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las camiones existentes y los botones Agregar,





Referencias: R03, R15, R18, R28 Id. requisito: R18 Nombre: Conoce revisiones técnicas Fecha: 20/12/2005 Descripción: Permite altas, bajas y modificaciones de revisiones técnicas



Flujo normal: 1. El usuario ingresa al ABM de Maquinarias o al de Camiones y selecciona uno 2. El usuario pulsa el botón Cambiar 3. El sistema muestra un listado de las revisiones técnicas existentes y los botones

Agregar, Cambiar y Borrar 4. El usuario agrega, modifica, o borra el registro 5. El sistema valida los datos y almacena los cambios




Referencias: R17, R19, R22



133

Id. requisito: R19 Nombre: Manejar maquinarias Fecha: 20/12/2005 Descripción: Permite altas, bajas y modificaciones de maquinarias



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las maquinarias existentes y los botones





Referencias: R03, R18, R26 Id. requisito: R20 Nombre: Manejar métodos de aplicación de agroquímicos Fecha: 22/12/2005 Descripción: Permite altas, bajas y modificaciones de aplicación de agroquímicos



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de los métodos de aplicación ya ingresados y los

botones Agregar, Cambiar y Borrar 3. El administrador agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R26



134

Id. requisito: R21 Nombre: Manejar agroquímicos Fecha: 20/12/2005 Descripción: Permite altas, bajas y modificaciones de agroquímicos



Flujo normal: 1. El usuario ingresa a través de una opción del menú 2. El sistema muestra un listado de los agroquímicos ya ingresados y los botones

Agregar, Cambiar y Borrar 3. El usuario agrega, modifica o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R22, R26 Id. requisito: R22 Nombre: Administrar proveedores Fecha: 22/12/2005 Descripción: Permite altas, bajas y modificaciones de proveedores



Flujo normal: 1.El usuario ingresa por medio de una opción del menú 2.El sistema muestra un listado de los proveedores ya ingresados y los botones

Agregar, Cambiar y Borrar 3.El usuario agrega, modifica o borra el registro 4. El sistema valida los datos y los almacena

Flujo alternativo: 4.El sistema comprueba la validez de los datos, si los datos no son los correctos,



Referencias: R18, R19, R21



135

Id. requisito: R23 Nombre: Administrar tareas Fecha: 21/12/2005 Descripción: Permite altas, bajas y modificaciones de tareas agrícolas



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las tareas ya ingresadas y los botones Agregar,

Cambiar y Borrar 3. El usuario agrega, modifica o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R26 Id. requisito: R24 Nombre: Administrar acciones de auditoria Fecha: 21/12/2005 Descripción: Permite altas, bajas y modificaciones de acciones de auditoria



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un listado de las acciones de auditoria existentes y los

botones Agregar, Cambiar y Borrar 3. El usuario agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R25



136

Id. requisito: R25 Nombre: Administrar usuarios Fecha: 21/12/2005 Descripción: Permite altas, bajas y modificaciones de usuarios

Actores: Administrador del sistema


Flujo normal: 1. El administrador ingresa por medio de una opción del menú 2. El sistema muestra un listado de los usuarios ya ingresados y los botones

Agregar, Cambiar y Borrar 3. El administrador agrega, modifica, o borra el registro 4. El sistema valida los datos y los almacena




Referencias: R24 Id. requisito: R26 Nombre: Registrar parte agrario Fecha: 22/12/2005 Descripción: Permite altas de los partes agrarios



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra el botón Agregar y luego un parte de tareas en blanco 3. El usuario completa los datos solicitados 4. El sistema valida los datos y los almacena

Flujo alternativo: 4.El sistema comprueba la validez de los datos, si los datos no son los correctos,


Poscondiones: El nuevo registro queda almacenado en el sistema.

Referencias: R04, R05, R07, R09, R19, R20, R21, R23



137

Id. requisito: R27 Nombre: Conocer la trazabilidad Fecha: 21/12/2005 Descripción: Permite consultar por la trazabilidad de productos



Flujo normal: 1. El usuario ingresa por medio de una opción del menú 2. El sistema muestra un grupo de botones que permiten habilitar o deshabilitar

parámetros 3. El usuario completa los parámetros por los cuales se filtrará la información 4. El sistema valida los datos y muestra la consulta


borra el campo de datos para que sean ingresados nuevamente.

Poscondiones: La consulta es desplegada en pantalla.

Referencias: R04, R05, R07, R09, R21, R23, R26 Id. requisito: R28 Nombre: Asentar remito de cosecha Fecha: 22/12/2005 Descripción: Permite altas de los remitos de cosecha



Flujo normal: 1. El usuario ingresa al remito de cosecha 2. El sistema muestra el botón Agregar y luego un remito de cosecha en blanco. 3. El usuario completa los datos solicitados 4. El sistema valida los datos y los almacena



Poscondiones: El nuevo registro queda almacenado en el sistema.

Referencias: R03, R04, 05, R07, R09, R14, R17



138

Id. requisito: R29 Nombre: Consultar cosecha de uva Fecha: 22/12/2005 Descripción: Permite consultar cosecha de uva



Flujo normal: 1. El usuario ingresa a través del menú a la consulta de cosecha de uva 2. El sistema muestra un grupo de botones: Titular, Viñedo y Variedad 3. El usuario pulsa el botón elegido y completa los datos solicitados por el sistema 4. El usuario pulsa el botón Procesar


borra el campo de datos para que sean ingresados nuevamente.

Poscondiones: La consulta es desplegada en pantalla.

Referencias: R03, R04, R07, R28 Id. requisito: R30 Nombre: Consultar movimientos de auditoria por usuario Fecha: 22/12/2005 Descripción: Permite consultar movimientos de auditoria por usuario



Flujo normal: 1. El usuario ingresa a través del menú a la consulta de auditoria 2. El sistema muestra un grupo de botones 3. El usuario pulsa el botón Usuario y completa los datos solicitados por el sistema 4. El usuario pulsa el botón Procesar



Poscondiones: El sistema muestra el resultado de la consulta filtrada por usuario.




139

Id. requisito: R31 Nombre: Consultar movimientos de auditoria por fecha Fecha: 22/12/2005 Descripción: Permite consultar movimientos de auditoria por fecha



Flujo normal: 1. El usuario ingresa a través del menú a la consulta de auditoria 2. El sistema muestra un grupo de botones 3. El usuario pulsa el botón Fecha y completa los datos solicitados por el sistema 4. El usuario pulsa el botón Procesar



Poscondiones: El sistema muestra el resultado de la consulta filtrada por fecha.

Referencias: R24, 25 Id. requisito: R32 Nombre: Consultar movimientos de auditoria por acción Fecha: 22/12/2005 Descripción: Permite consultar movimientos de auditoria por acción



Flujo normal: 1. El usuario ingresa a través del menú a la consulta de auditoria 2. El sistema muestra un grupo de botones 3. El usuario pulsa el botón Acción y completa los datos solicitados por el sistema 4. El usuario pulsa el botón Procesar



Poscondiones: El sistema muestra el resultado de la consulta filtrada por acción.

Referencias: R24, 25



140

Id. requisito: R33 Nombre: Consultar movimientos de auditoria por comprobante Fecha: 22/12/2005 Descripción: Permite consultar movimientos de auditoria por comprobantes



Flujo normal: 1. El usuario ingresa a través del menú a la consulta de auditoria 2. El sistema muestra un grupo de botones 3. El usuario pulsa el botón Comprobante y completa los datos solicitados por el

sistema 4. El usuario pulsa el botón Procesar



Poscondiones: El sistema muestra el resultado de la consulta filtrada por los tipos de comprobantes seleccionados.




141

ANEXO D

DISEÑO DEL SISTEMA

MODELO DE DATOS En este apartado se presenta el esquema de la Base de Datos del

Software de Trazabilidad.



142



143



144



145

Presentadas todas las tablas de la BD y sus relaciones continuamos con

otros aspectos del diseño.

GUÍA DE DISEÑO

Estructura de layout Se presenta la estructura de layout de la pantalla principal del sistema. La

misma tiene una distribución muy simple cómo se puede observar en el

diseño siguiente. Donde se observa solamente la barra de menú principal

en la parte superior de la ventana.



146

Look&feel aplicado a la estructura de layout anterior



147

Menús Se elige este sistema de menú porque se considera que es claro e

intuitivo. Proporciona un mejor entendimiento por parte de los usuarios

quienes suelen estar acostumbrados a su utilización dado que el

desplegable vertical está presente en muchos programas, por ejemplo los

de ofimática.

Menú habilitado Menú deshabilitado Paleta de colores Se seleccionaron como colores principales el gris y el azul marino ya que

se considera que son tonos sobrios y elegantes, a la vez que no cansan

tanto la vista luego de varias horas de fijación ante la pantalla.

Textura Para fondo

Modelo de color: RGB Rojo: 0 Verde: 0 Azul: 128 Para Títulos de las aplicaciones



148

Tipografía La tipografía debe ser estándar para que pueda ser visualizada

correctamente en todo tipo de equipos. Se utiliza esta clase de tipografía

para no dificultar la edición de contenidos.

Títulos de aplicaciones: Tahoma negrita 16 pt Campos: Arial negrita 9 pt

Iconos Se presentan como ejemplo algunos de los íconos que se utilizan en las

aplicaciones para hacer más intuitiva y amigable la interacción con ellas.

Agregar

Borrar Procesa

Salir



149

CONCLUSIONES

Haber implementado el método Scrum para el desarrollo de un software

real ha resultado una experiencia gratificante y un aprendizaje constante

en todas las etapas del desarrollo del mismo. El hecho de haber

terminado el trabajo obteniendo como resultado un producto funcionando

muestra que los objetivos planteados en un principio se cumplieron. Pero

lo más importante, es que se incrementaron los conocimientos por lo que

el trabajo implicó una gran satisfacción personal.

El primer objetivo planteado fue adentrarse en las Metodologías Ágiles en

general y en Scrum en particular para conocer el método y poder aplicarlo

posteriormente. Luego de su estudio y análisis se llega a la conclusión de

que su simplicidad en el desarrollo es lo que evita perder de vista el

objetivo. Es sencillo, flexible, y muy enfocado a la verdadera necesidad

del cliente. Es muy amigable a la hora de implementarlo y se cree que es

ideal para los negocios y las actividades de la actualidad que son más

complejos, cambiantes y vertiginosos que antes.

Pero en Scrum no todo es color de rosas, debido a que es un método de

gestión de proyectos (permite gestionar proyectos de cualquier tipo, no

sólo tecnológicos) es que deja un vacío en el área del proceso y delega al

equipo de trabajo esa responsabilidad por completo.

Precisamente por este motivo fue que nos planteamos el segundo

objetivo, elaborar una metodología propia de desarrollo para

complementar esta insuficiencia de Scrum.



150

Nuestro proceso definido con las cinco etapas tradicionales del desarrollo

de software se adaptó muy bien a la filosofía ágil. Y de la combinación de

herramientas utilizadas cabe destacar a ScrumWorks que resultó una

excelente herramienta para hacer el seguimiento diario del proyecto e ir

midiendo constantemente la velocidad de desarrollo. Eso si, para ello hay

que ser perseverante y reestimar diariamente el esfuerzo pendiente de las

tareas.

El desarrollo del Proyecto Trazabilidad que derivó en un Software de

Trazabilidad como producto final se llevó adelante sin mayores

sobresaltos, y podemos arrojar los siguientes resultados sobre el mismo.

De las seis entregas programadas para el cliente, las cinco primeras se

cumplieron en tiempo y forma. Hay que reconocer que en las

estimaciones iniciales de esfuerzo se tuvo, la mayoría de las veces, una

visión un poco pesimista, tal vez por temor a la falta de experiencia se

prefirió holgar un poco los tiempos.

En el último Sprint, el sexto, se detectó al comienzo del mismo que iba a

haber un atraso lo que nos llevó de inmediato a renegociar con el cliente

la última fecha de entrega, la cual se corrió una semana. Esta ha sido

entonces, la demora total que sufrió el proyecto, una semana, creemos

que es un margen de atraso bastante aceptable.

Como conclusión final se quiere exponer que el hecho de ir haciendo

entregas constantes y frecuentes al cliente, no sólo lo mantiene contento,

sino que además aumenta la confianza y la autoestima del desarrollador.

Ir concretando etapas es una motivación para seguir adelante.



151

BIBLIOGRAFÍA

Metodologías ágiles y Scrum http://www.agilemanifesto.org http://www.agile-spain.org http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/hetero

dox.asp CIS. Juan Palacio Bañeres – http://www.navegapolis.net

Material brindado en Curso de Prácticas Ágiles. John Gómez. Dictado en

la UM.

Metodología y Desarrollo del Proyecto Ingeniería del Software. Un enfoque práctico. Roger S. Pressman

Claves para el Éxito de los Proyectos. Pablo Lledó, Gustavo Rivarola.

Producción de uva y Trazabilidad http://www.inv.gov.ar/ http://www.alimentosargentinos.gov.ar/ http://www.sagpya.mecon.gov.ar/

http://www.gestiontrazabilidad.com/ http://www.consumaseguridad.com/ Reglamento (CE) n° 178/2002 del Parlamento Europeo y del Consejo.

http://www.agilemanifesto.org

http://www.agile-spain.org

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/hetero

http://www.navegapolis.net

http://www.inv.gov.ar/

http://www.alimentosargentinos.gov.ar/

http://www.sagpya.mecon.gov.ar/

http://www.gestiontrazabilidad.com/

http://www.consumaseguridad.com/

Metodo agil scrum

Documents

Transcript of Metodo agil scrum