UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

UNTELS
FACULTAD DE INGENIERIA DE SISTEMAS Y ADMINISTRACION
DE EMPRESAS
CARRERA PROFESIONAL INGENIERIA DE SISTEMAS

TESIS
SISTEMA DE GESTION PARA HISTORIAS CLINICAS BAJO LA
METODOLOGIA SCRUM PARA LA CLINICA VETERINARIA MIS MASKOTAS

PRESENTADO POR
HERRERA MORALES PIERO CRISTIAN
PARA OPTAR EL TTULO PROFESIONAL DE
INGENIERO DE SISTEMAS
LIMA PER
2016
ndice

INTRODUCCIN.3
CAPTULO I: PLANTEAMIENTO DEL PROBLEMA
1.1. Descripcin de la realidad problemtica.5
1.2. Justificacin del problema.5
1.3. Delimitacin del proyecto..6
1.4. Formulacin del problema.7
1.4.1. Problema principal7
1.4.2. Problemas especficos7
1.5. Objetivos..7
1.5.1. Objetivo general7
1.5.2. Objetivos especficos...7
CAPTULO II: MARCO TERICO
2.1. Antecedentes de la Investigacin8
2.2. Bases tericas..12
2.2.1. Sistema de gestin....12
2.2.2. Metodologas agiles..15
2.2.3. El Manifiesto gil. Valores y Principios..17
2.2.4. Scrum: una metodologa gil...19
2.2.5. Base de datos............27
2.3. Marco conceptual.....30
2.3.1. El Sprint...30
2.3.2. Historias de usuario...31
2.3.3. Historia clnica veterinaria.32

BIBLIOGRAFA...34

INTRODUCCION
2

Los avances tecnolgicos siguen evolucionando considerablemente sobre

todo en los sistemas gestin, en la actualidad son de vital importancia en las
empresas grandes medianas o pequeas que se dedican a diversas
actividades de negocio, mismas que manejan gran cantidad de informacin as
como para uso interno y/o externo, informacin que se lograra gestionar
correctamente, hoy en da ha venido a ser una necesidad la administracin,
almacenamiento, gestin y control de la informacin en las empresas por ms
pequeas que sean, para sistematizar sus procesos, siendo en este caso la
clnica veterinaria Mis Maskotas.
El presente proyecto a desarrollar se titula Sistema de gestin para las
historias clnicas bajo la metodologa Scrum para la clnica veteria Mis
Maskotas., donde consiste en aprovechar los beneficios que ofrece y
desarrolla la tecnologa actual con respecto al software, hardware y
comunicaciones y de esta manera, automatizar los procesos que se lleven a
cabo dentro de la clnica veterinaria, dar un correcto seguimiento a los datos
generados y crear una interface para que la informacin sea disponible, con la
implementacin del sistema.
En los ltimos aos las metodologas de desarrollo gil estn adquiriendo
gran popularidad. La mayora de las empresas lderes en el rea de la
informtica estn comenzando a utilizarlas: Google, Yahoo, Symantec,
Microsoft, y una amplia lista ms de organizaciones siguen el modelo gil. Las
metodologas

giles

aparecen

como

una

opcin

atractiva

pues,

en

contraposicin con las metodologas convencionales que actan basadas en

principios de estabilidad y control del contexto, las metodologas giles no se
centran en habilidades de prediccin, ni pretenden tener un sistema
3

perfectamente definido como paso previo a su construccin, sino que perciben

cada respuesta al cambio como una oportunidad para mejorar el sistema e
incrementar la satisfaccin del cliente, considerando la gestin de cambios
como un aspecto inherente al propio proceso de desarrollo software y,
permitiendo de este modo, una mejor adaptacin en entornos turbulentos.
En este contexto, Scrum se ha convertido en una de las metodologas agiles
ms populares en el mercado, por lo que ha sido la elegida para el desarrollo e
implementacin del presente proyecto.

CAPITULO I
4

PLANTEAMIENTO DEL PROBLEMA

1.1.

Descripcin de la realidad problemtica

La importancia de los sistemas de gestin informticos radica en que son de

gran ayuda tanto para los clientes y los dueos de las veterinarias, ya que
necesitan de un permanente control de sus mascotas en caso de los clientes, o
ya sea de los veterinarios ya que necesitan llevar el control de sus pacientes, el
inventario, entre otros y que en la actualidad toda la informacin se debera
llevar registrada en un sistema y no en forma manual, lo que hace dificultoso
localizar historias clnicas, datos de inters de los usuarios y tener estadsticas
confiables para la toma de decisiones.
Ya que no se cuenta con un registro eficaz el veterinario pierde la relacin
estrecha con su paciente desde el punto de vista evolutivo de sus
enfermedades haciendo que en cada cita tenga que pedirle un recuento de
observaciones al paciente perdiendo tiempo, de aqu radica la importancia de
contar con una herramienta que se pretende implementar con este proyecto,
que le permita organizar la agenda de las citas y a su vez conocer sobre los
pacientes que est atendiendo, con informacin clara de la historia clnica
1.2.

Justificacin del problema

La presente investigacin fue motivada al ver que los encargados de brindar

atencin en la clnica veterinaria Mis Maskotas, no cuentan con herramientas
tiles para registrar, controlar y administrar las historias clnicas de sus
pacientes, que son indispensables para la labor que profesionalmente realizan,
que es la de procurar el bienestar fsico de las mascotas. Un aspecto
fundamental de este problema es que los encargados no cuentan con el tiempo
5

suficiente para ponerse al da con la realidad de sus pacientes por el hecho de

no llevar un detalle especfico de cada uno de ellos y mantener esta
informacin en forma aislada en archivos electrnicos o libros carentes de
organizacin.
Los profesionales de la salud animal se beneficiaran al contar con una
herramienta confiable y eficaz que les brindar mejores resultados y agilizar
sus funciones ofreciendo un mayor desempeo y organizacin de su tiempo
para cada una de las citas que se le presente sin descuidar el aspecto
tecnolgico que hoy en da es necesario y predominante.
1.3.
a)
b)
c)
d)
e)

Delimitacin del problema

Campo: Carrera Profesional Ingeniera de Sistemas.
rea: Software.
Lnea de investigacin: Desarrollo de Software.
Sublnea de Investigacin: Aplicaciones de escritorio
Espacial: El presente proyecto de investigacin est dirigido a los
encargados de brindar atencin en la clnica veterinaria Mis Maskotas
ubicada en Alameda Sur 702 - Bello Horizonte perteneciente al distrito

Chorrillos de la ciudad de Lima.

f) Temporal: Seis meses

1.4.

Formulacin del problema

1.4.1. Problema principal

Qu caractersticas tendr un sistema de gestin implementado en la

clnica veterinaria Mis Maskotas para mejorar el control de la informacin
y el registro de las historias clnicas de los pacientes?
1.4.2. Problemas especficos
a) Cules son los procesos que intervienen en el resgistro de
historias clnicas de los pacientes en la clnica veterinaria Mis
Maskotas?
b) El desarrollo e implementacin de un sistema informtico de
gestin permitir gestionar apropiadamente la informacin de la
clnica veterinaria Mis Maskotas?
1.5. Objetivos
1.5.1. Objetivo general
Implementar un sistema de gestin informtico de historias clnicas
bajo la metodologa Scrum para la clnica veterinaria Mis Maskotas.
1.5.2. Objetivos especficos
a) Analizar los procesos aplicados en el registro de historias clnicas
en la clnica veterinaria Mis Maskotas.
b) Gestionar la informacin de la clnica de forma en que esta sea
convenientemente

clasificada

se

tenga

la

necesaria

disponibilidad sobre la misma, mejorando as la atencin que se

da a los pacientes y facilitando la labor de cada uno de los
empleados.

CAPITULO II
MARCO TEORICO
2.1.

Antecedentes de la investigacin

Villarruel (2015) elabor la investigacin: Sistema de gestin para historias

clnicas bajo la plataforma Android orientado a los mdicos del condominio del
hospital Millennium, llegando a las siguientes conclusiones:
a) La aplicacin de gestin de historias clnicas para los mdicos del
condominio del hospital Millennium, resulta ser una herramienta
confiable al momento de realizar la administracin, los mdicos que
disponen dispositivos Android se benefician al contar con esta aplicacin
que les permite tener portabilidad y efectividad con respecto a la
informacin.
b) Android Studio es la herramienta de programacin para aplicaciones
mviles que resulto ser la mejor opcin para desarrollar la aplicacin
para la gestin de historias clnicas, y al de ser de cdigo libre da la
posibilidad de desarrollar sin tener que pagar por licencias tanto en el
entorno de desarrollo como la utilizacin del gestor de base de datos
SQLite que tambin es de libre distribucin.
c) El realizar una aplicacin para los mdicos del condominio del Hospital
Millennium fue un acierto ya que los mdicos se benefician al poder
registrar sus citas, historias clnicas y modificar la informacin de los
pacientes en cualquier momento y en cualquier lugar donde se
encuentre de una manera fcil y agradable.
d) La metodologa que se utiliz hizo posible que se pueda elaborar este
proyecto y garantizar su funcionamiento, la metodologa XP resulto ser
una herramienta clave a la hora de resolver las diferentes dificultades
que surgen al realizar este tipo de aplicaciones.

El aporte de esta investigacin es la implementacin de un sistema de

gestin desarrollado con una metodologa gil, que en este caso es XP. Nos
muestra directrices sobre cmo llevar a cabo el presente proyecto.
La Rosa y Diaz (2011) elaboraron la investigacin: Sistema de gestin de
reportes de oportunidad de mejora, llegando a las siguientes conclusiones:
a) La arquitectura orientada al servicio permiti enfocar la solucin de
software en una posicin privilegiada de cara a futuras adecuaciones,
ya que permite desarrollar una lgica verstil en lo que a su
adaptabilidad

se

refiere,

obteniendo

un

producto

final

de

caracterstica modular.
b) Un enfoque de negocio del producto aporta funcionalidades CORE,
en lo que a seguridad industrial se refiere.
c) Antes de comenzar a modelar el negocio es necesario investigar y
conocer los procesos involucrados dentro del mismo y establecer
claramente los lmites para poder llegar a tener una solucin acorde
con lo que el cliente desea.
d) Los mtodos giles de programacin han sido de gran ayuda para
lograr soluciones rpidas, ntegras y oportunas para el producto
obtenido como solucin.
e) Los fundamentos tericos del negocio y las tecnologas y tendencias
propuestas

se

complementan,

ya

que

permitirn

generar

transferencia de informacin sin importar el lugar fsico conde se

encuentre ubicado el personal.
f) Las fases de un proyecto logran un orden bsico, primordial, de cara
al desarrollo de una solucin de software.
g) La aplicacin de las reas de conocimiento en los distintos enfoques
del proyecto permiten un manejo formal de cada etapa del proyecto,
as como de los futuros cambios que son parte de su ciclo de vida.
9

h) La metodologa RUP ha servido como referencia en la elaboracin de

informacin y el uso de los artefactos nos ha facilitado el desarrollo
del proyecto, permitindonos identificar los requerimientos de los
usuarios y disear un sistema que pueda suplir las necesidades de
los usuarios y facilitar el manejo de muchas actividades realizadas en
el negocio.
i) Para todo proyecto es necesario controlar y administrar las tareas y/o
actividades del mismo para esto se deben de usar herramientas
como el WBS el cronograma de ejecucin del proyecto.
j) Las lecciones aprendidas durante las retrospectivas en las fases del
desarrollo del producto servirn como base para los proyectos
futuros.
k) La implementacin de nuevos proyectos, adems de asumir
estndares ya conocidos, promueve nuevas estandarizaciones. Esto
est directamente relacionado al grado de madurez del rea de TI de
la organizacin.
Esta investigacin confirma que el uso de una metodologa gil como
Scrum aporta un panorama claro sobre las necesidades de los involucrados
en el desarrollo de un aplicativo.
Ruiz y Telaya (2014) elaboraron el proyecto de tesis que lleva como ttulo:
Implementacin de una red social usando metodologas agiles para mejorar
el proceso de participacin estudiantil en la Universidad Autnoma del Per,
llegando a las siguientes conclusiones:
a) Se comprueba que, el haber implementado la red social, usando
metodologas giles, mejor la participacin estudiantil en la
Universidad Autnoma del Per.
10

b) Se observa, que la implementacin de la red social aument el

nmero de eventos por semana.
c) Se aprecia, que la implementacin de la plataforma aument el
nmero de contenidos por semana.
d) Se comprueba, el desarrollo exitoso de la red social aument el
nmero de posts compartidos por semana.
e) Es notorio, que la red social trajo como beneficio el aumento de
participantes por evento.
f) Se observa, que el uso adecuado de Scrum gener
retroalimentaciones constantes en cada sprint.
g) Se aprecia, que la red social permiti crear y compartir contenido
generado por estudiantes.
h) Se comprueba, que las historias de usuario dieron a conocer de
manera sencilla y simple las tareas por hacer durante el sprint
planificado
Este proyecto aporta pautas y recomendaciones sobre el uso adecuado de
la metodologa Scrum, y confirma la retroalimentacin continua que habr
en el proceso de desarrollo del sistema de gestin .

2.2.

Bases tericas

2.2.1. Sistema de gestin

2.2.1.1.

Sistema

Para Peralta (2008, p. 5) un sistema es conjunto de elementos que

interactan entre s con el fin de apoyar las actividades de una empresa o
negocio.
2.2.1.2.

Gestin
11

Segn guila (1999, p. 7), define gestin como una prctica de la

reutilizacin de procesos y soluciones que se han adquirido a travs de la
experiencia, informacin, conocimientos o habilidades del personal de la
empresa o por bsqueda en fuentes externas.
La gestin es el proceso mediante el cual se formulan objetivos y luego se
miden los resultados obtenidos para finalmente orientar la accin hacia la
mejora permanente de los resultados. Hernndez (1998).
Por gestin se entiende, la direccin de las acciones que contribuyan a
tomar decisiones orientadas a alcanzar los objetivos trazados, medir los
resultados obtenidos, para finalmente, orientar la accin hacia la mejora
permanente del sistema.
2.2.1.3.

Sistema de gestin: definicin

Un sistema de gestin es un conjunto de procesos, comportamientos y

herramientas que permite optimizar recursos, reducir costes y mejorar la
productividad de la empresa.
El sistema de gestin es la herramienta que permite controlar los efectos
econmicos y no econmicos de la actividad de la empresa. El control, en este
caso, se define como aquella situacin en que se dispone de conocimientos
ciertos y reales de lo que est pasando en la empresa, tanto internamente
como en su entorno y permite planificar, en cierta manera, lo que pasar en el
futuro. Mide el aprovechamiento eficaz y permanente de los recursos que
posee la empresa para el logro de sus objetivos. (Ogalla, 2005, p. 1).

12

Los sistemas de gestin estn basados en normas internacionales que

permiten controlar distintas facetas en una empresa, como la calidad de su
producto o servicio, los impactos ambientales que pueda ocasionar, la
seguridad y salud de los trabajadores, la responsabilidad social o la innovacin.
Un sistema de gestin est especialmente recomendado a cualquier tipo de
organizacin o actividad orientada a la produccin de bienes o servicios, que
necesiten de la gestin de sistemas una herramienta til para mejorar la
rentabilidad de la empresa.

2.2.1.4. Importancia de los sistemas de gestin

La implementacin de un sistema de gestin eficaz puede ayudar a:
a)
b)
c)
d)
e)
f)
g)
h)
i)
2.2.1.5.

Gestionar los riesgos sociales, medioambientales y financieros.

Mejorar la efectividad operativa.
Reducir costos.
Aumentar la satisfaccin de clientes y partes interesadas.
Proteger la marca y reputacin.
Lograr mejoras continuas.
Potenciar la innovacin.
Eliminar las barreras del comercio.
Aporta claridad al mercado.
Etapas de los sistemas de gestin

Se establece cuatro etapas en este proceso, que hacen de este sistema, un

proceso circular virtuoso, que son:
a) Etapa de ideacin. El objetivo de esta etapa es trabajar en la idea que
guiar los primeros pasos del proceso de creacin que se logra con el
sistema de gestin propuesto.
b) Etapa de planeacin. Dentro del proceso, la planificacin constituye
una etapa fundamental y el punto de partida de la accin directiva, ya
que supone el establecimiento de sub-objetivos y los cursos de accin

13

para alcanzarlos. En esta etapa, se definen las estrategias que se

utilizarn, la estructura organizacional que se requiere, el personal que
se asigna, el tipo de tecnologa que se necesita, el tipo de recursos que
se utilizan y la clase de controles que se aplican en todo el proceso.
c) Etapa de implementacin. En su significado ms general, se entiende
por gestin, la accin y efecto de administrar. Pero, en un contexto
empresarial, esto se refiere a la direccin que toman las decisiones y las
acciones para alcanzar los objetivos trazados. Es importante destacar
que las decisiones y acciones que se toman para llevar adelante un
propsito,

se

sustentan

en

los

mecanismos

instrumentos

administrativos (estrategias, tcticas, procedimientos, presupuestos,

etc.), que estn sistmicamente relacionados y que se obtienen del
proceso de planificacin.
d) Etapa de control. El

control

es

una

funcin

administrativa,

esencialmente reguladora, que permite verificar (o tambin constatar,

palpar, medir o evaluar), si el elemento seleccionado (es decir, la
actividad, proceso, unidad, sistema, etc.), est cumpliendo sus objetivos
o alcanzando los resultados que se esperan. Es importante destacar que
la finalidad del control es la deteccin de errores, fallas o diferencias, en
relacin a un planteamiento inicial, para su correccin y/o prevencin.
Por tanto, el control debe estar relacionado con los objetivos inicialmente
definidos, debe permitir la medicin y cuantificacin de los resultados, la
deteccin de desviaciones y el establecimiento de medidas correctivas y
preventivas.
2.2.2. Metodologas giles

14

Segn Cans, Letelier y Penads (2003), en la ltima dcada se ha creado

modelos de desarrollo agiles que prometen ser mejor que los modelos antiguos
solucionando el primer factor que es el tiempo de desarrollo e implementacin,
creando roles especficos aplicando un dicho de divide y vencers con lo que
se busca segmentar tareas y actividades por tiempos cortos a los que se
llaman iteraciones donde se construye un demo o prototipo funcional que poco
a poco va tomando forma, con esto se busca reducir errores lo ms que se
pueda con cada iteracin, as como llevar una documentacin conjunta que
ayude al proceso de desarrollo y la posterioridad.
En febrero de 2001, tras una reunin celebrada en Utah, EEUU, nace el
trmino gil aplicado al desarrollo de software. En esta reunin participan un
grupo de 17 expertos de la industria del software, incluyendo algunos de los
creadores o impulsores de metodologas de software. Su objetivo fue esbozar
los valores y principios que deberan permitir a los equipos desarrollar software
rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas.
(Cans, et al., 2003, p. 2)
La siguiente Tabla 1 muestra la diferencia de emplear una metodologa
tradicional a una gil.
Metodologas giles
Basadas en heursticas provenientes de
prcticas de produccin de cdigo
Especialmente preparados para cambios
durante el proyecto

Metodologas Tradicionales
Basadas en normas provenientes de
estndares seguidos por el entorno de
desarrollo
Cierta resistencia a los cambios

15

Impuestas internamente (por el equipo)

Proceso menos controlado, con pocos
principios
El cliente es parte del equipo de
desarrollo
Grupos pequeos (<10 integrantes) y
trabajando en el mismo sitio
Pocos artefactos
Pocos roles
Menos nfasis en la arquitectura del
software

Impuestas externamente
Proceso mucho ms controlado, con
numerosas polticas/normas
El cliente interacta con el equipo de
desarrollo mediante reuniones
Grupos
grandes
y
posiblemente
distribuidos
Ms artefactos
Ms roles
La arquitectura del software es esencial y
se expresa mediante modelos

Tabla 1. Diferencias entre metodologas giles y no giles

Fuente: Cans, Letelier y Penads (2003, p.4)

2.2.3. El Manifiesto gil. Valores y principios

Para Qumer y Henderson-Sellers (2007), citados por Rodriguez (2008, p.
12), definen el trmino agilidad como un comportamiento persistente o
habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a
cambios, esperados o inesperados, rpidamente; persigue la duracin ms
corta en tiempo; usa instrumentos econmicos, simples y de calidad en un
ambiente dinmico; y utiliza los conocimientos y experiencia previos para
aprender tanto del entorno interno como del externo.
Por tanto, el desarrollo gil no especifica unos procesos o mtodos que
seguir, aunque bien es cierto que han aparecido algunas prcticas asociadas a
este movimiento. El desarrollo gil es ms bien una filosofa de desarrollo
software. El punto de partida se establece en las ideas emanadas del
Manifiesto gil tras la reunin de Utah, un documento que resume la filosofa
gil estableciendo cuatro valores y doce principios.
Segn el Manifiesto se valora:
a) Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas. La gente es el principal factor de xito de
16

un proyecto software. Es ms importante construir un buen equipo que

construir el entorno. Muchas veces se comete el error de construir
primero el entorno y esperar que el equipo se adapte automticamente.
Es mejor crear el equipo y que ste configure su propio entorno de
desarrollo en base a sus necesidades.
b) Desarrollar software que funciona ms que conseguir una buena
documentacin. La regla a seguir es no producir documentos a menos
que sean necesarios de forma inmediata para tomar un decisin
importante. Estos documentos deben ser cortos y centrarse en lo
fundamental.
c) La colaboracin con el cliente ms que la negociacin de un
contrato. Se propone que exista una interaccin constante entre el
cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la
que marque la marcha del proyecto y asegure su xito.
d) Responder a los cambios ms que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determina tambin el xito o fracaso del mismo. Por lo tanto, la
planificacin no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son
caractersticas que diferencian un proceso gil de uno tradicional. Los dos
primeros principios son generales y resumen gran parte del espritu gil. El
resto tienen que ver con el proceso a seguir y con el equipo de desarrollo,
en cuanto metas a seguir y organizacin del mismo. Los principios son:
I.

La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.

17

II.

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

III.

cliente tenga una ventaja competitiva.

Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible

IV.

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

V.

largo del proyecto.

Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos para conseguir

VI.

finalizar el trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para

VII.
VIII.

comunicar informacin dentro de un equipo de desarrollo.

El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberan ser capaces de

IX.

mantener una paz constante.

La atencin continua a la calidad tcnica y al buen diseo mejora la

X.
XI.

agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos

XII.

organizados por s mismos.

En intervalos regulares, el equipo reflexiona respecto a cmo llegar a
ser ms efectivo, y segn esto ajusta su comportamiento

2.2.4. Scrum: una metodologa gil

La palabra Scrum proviene del nombre de una jugada que ocurre en los
partidos de rugby (Pressman, 2010). Segn Sims y Johnson (2011) definen
Scrum como una metodologa gil en la cual se llevan a cabo una serie de
prcticas iterativas cuyo objetivo es que el grupo de desarrolladores trabaje
unido, contribuyendo con sus habilidades individuales para la obtencin de un
18

software de buena calidad. Una de las caractersticas de Scrum es la entrega

de porciones incrementales del producto final al trmino de cada iteracin; de
esta manera el cliente puede ir haciendo modificaciones o continuar con el
desarrollo del software tal como se tena previsto originalmente. Scrum es una
metodologa diseada para el desarrollo de productos en ambientes complejos
en donde se requiere un producto funcional rpidamente, con cambios
constantes o con especificaciones ambiguas.
Scrum es un proceso para la gestin y control del producto que trata de
eliminar la complejidad en estas reas para centrarse en la construccin de
software que satisfaga las necesidades del negocio. Es simple y escalable, ya
que no establece prcticas de ingeniera del software sino que se aplica o
combina, fcilmente, con otras prcticas ingenieriles, metodologas de
desarrollo o estndares ya existentes en la organizacin. Rodriguez (2008, p.
17)
Scrum se concentra, principalmente, a nivel de las personas y equipo de
desarrollo que construye el producto. Su objetivo es que los miembros del
equipo trabajen juntos y de forma eficiente obteniendo productos complejos y
sofisticados. Podramos entender Scrum como un tipo de ingeniera social que
pretende conseguir la satisfaccin de todos los que participan en el desarrollo,
fomentando la cooperacin a travs de la auto-organizacin. De esta forma se
favorece la franqueza entre el equipo y la visibilidad del producto. Pretende que
no haya problemas ocultos, asuntos u obstculos que puedan poner en peligro
el proyecto. Los equipos se guan por su conocimiento y experiencia ms que
por planes de proyecto formalmente definidos. La planificacin detallada se
realiza sobre cortos espacios de tiempo lo que permite una constante
19

retroalimentacin que proporciona inspecciones simples y un ciclo de vida

adaptable. As, el desarrollo de productos se produce de forma incremental y
con un control emprico del proceso que permite la mejora continua. Schwaber
y Beedle (2006).
Independientemente del tipo de metodologa que se utilice, cualquier
desarrollo software parte siempre de un mismo problema: conocer las
necesidades de los clientes. Scrum, al igual que el resto de metodologas
giles, pretende no centrar las tareas de desarrollo en un conjunto de requisitos
formalmente definidos sino que aboga por la incorporacin del cliente como un
miembro ms del equipo de desarrollo. De este modo, no se considera el
proceso de definicin de requisitos como un fin dentro del desarrollo del
proyecto, sino que los requisitos aparecen implcitamente dentro del contenido
de las denominadas historias de usuario, que son breves descripciones
textuales de cada una de las funcionalidades que tendr el producto.
2.2.4.1.

El proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y

fijos (iteraciones de un mes natural y hasta de dos semanas, si as se
necesita). Cada iteracin tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el
mnimo esfuerzo al cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto,
que acta como plan del proyecto. En esta lista el cliente prioriza los objetivos
balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas.
20

Las actividades que se llevan a cabo en Scrum son las siguientes:

a) Planificacin de la iteracin (Sprint Planning)
La planificacin de las tareas a realizar en la iteracin se divide en dos
partes:

Primera parte de la reunin. Se realiza en un bloque de tiempo de cmo

mximo 4 horas :

El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteracin (de
manera que ayude a tomar decisiones durante su ejecucin) y
propone los requisitos ms prioritarios a desarrollar en ella.

El equipo examina la lista, pregunta al cliente las dudas que le

surgen, aade ms condiciones de satisfaccin y selecciona los
objetivos/requisitos ms prioritarios que se compromete a
completar en la iteracin, de manera que puedan ser entregados
si el cliente lo solicita.

Segunda parte de la reunin. Se realiza en un bloque de tiempo de

cmo mximo 4 horas. El equipo planifica la iteracin, elabora
la tctica que le permitir conseguir el mejor resultado posible con el
mnimo esfuerzo. Esta actividad la realiza el equipo dado que ha
adquirido un compromiso, es el responsable de organizar su trabajo y es
quien mejor conoce cmo realizarlo.

21

Define las tareas necesarias para poder completar cada

objetivo/requisito, creando la lista de tareas de la iteracin (Sprint
Backlog) basndose en la definicin de completado.

Realiza una estimacin conjunta del esfuerzo necesario para

realizar cada tarea.

Cada miembro del equipo se autoasigna a las tareas que puede

realizar.

b) Ejecucin de la iteracin (Sprint)

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos
(iteraciones de un mes y hasta de dos semanas). Cada iteracin tiene que
proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable,
Owner) lo

solicite slo

producto

est

sea

disponible

de

manera que cuando

necesario
para

el cliente

(Product

un esfuerzo mnimo para que el

ser utilizado. Para

ello,

durante

la

iteracin el equipo colabora estrechamente y se llevan a cabo las siguientes

dinmicas:

Cada da el equipo realiza una reunin de sincronizacin, donde

cada miembro inspecciona el trabajo de los otros para poder
hacer las adaptaciones necesarias, comunica cuales son los
impedimentos con que se encuentra, actualiza el estado de la lista
de tareas de la iteracin (Sprint Backlog) y los grficos de trabajo
pendiente (Burndown charts).

22

El Facilitador (Scrum Master) se encarga de que el equipo pueda

cumplir con su compromiso y de que no se merme su

productividad.
Elimina los obstculos que el equipo no puede resolver por s

mismo.
Protege al equipo de interrupciones externas que puedan afectar

su compromiso o su productividad.
c) Demostracin de requisitos completados (Sprint Review)
Reunin

informal donde el equipo presenta al cliente los requisitos

completados en la iteracin, en forma de incremento de producto preparado

para ser entregado con el mnimo esfuerzo, haciendo un recorrido por ellos
lo ms real y cercano posible al objetivo que se pretende cubrir.
En funcin de los resultados mostrados y de los cambios que haya habido
en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de
manera objetiva, ya desde la primera iteracin, replanificando el proyecto.
Se realiza en un bloque de tiempo de cmo mximo 4 horas.
d) Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua su productividad y la
calidad del producto que est desarrollando, el equipo analiza cmo ha sido
su manera de trabajar durante la iteracin, por qu est consiguiendo o no
los objetivos a que se comprometi al inicio de la iteracin y por qu el
incremento de producto que acaba de demostrar al cliente era lo que l
esperaba o no:

Qu cosas han funcionado bien.

23

Cuales hay que mejorar.

Qu cosas quiere probar hacer en la siguiente iteracin.

Qu ha aprendido.

Cules son los problemas que podran impedirle progresar

adecuadamente. El Facilitador se encargar de ir eliminando los
obstculos identificados que el propio equipo no pueda resolver
por s mismo.

Notar que esta reunin se realiza despus de la reunin de demostracin

al cliente de los objetivos conseguidos en la iteracin, para poder incorporar
su retroalimentacin y cumplimiento de expectativas como parte de los
temas a tratar en la reunin de retrospectiva
Se realiza en un bloque de tiempo de cmo mximo 3 horas (si la
iteracin es mensual).

2.2.4.2.

Roles en Scrum

En Scrum intervienen 3 roles fundamentalmente:

a) El Product Owner es la nica persona encargada de la direccin y

control del Product Backlog, es decir, de las historias de usuario que
debe cumplir el sistema. Se trata de una persona fsica (solamente una
persona para eliminar las posibles confusiones o interferencias), no una
organizacin o comit. Bien puede ser el propio cliente in situ en el lugar
de desarrollo u otra persona que tenga el conocimiento suficiente sobre
24

el producto o pueda estar en continuo contacto con el cliente para

marcar las prioridades del proyecto. Es, por tanto, la persona
oficialmente responsable del proyecto que de forma visible, vocal y
objetiva debe tomar todas las decisiones de negocio para el producto.
Para que el Product Owner tenga xito, el resto del equipo de la
organizacin tiene que respetar sus decisiones. En cuanto a su
implicacin debe estar en contaste interaccin con el equipo de
desarrollo. Debe asistir, al menos, a las reuniones de planificacin y de
revisin de cada sprint y estar en continuo contacto con el equipo para
proporcionar detalles sobre las historias de usuario y constante

b)

retroalimentacin que dirija el desarrollo del sprint.

El Scrum Master es la persona responsable del xito al aplicar la
metodologa SCRUM en el desarrollo del proyecto o producto,
asegurando que los valores, prcticas y reglas son seguidos por el resto
del equipo. En concreto, es la persona que asegura el seguimiento de la
metodologa guiando las reuniones, ayudando al equipo ante cualquier
problema que pueda aparecer y controlando que el trabajo sigua el ritmo
adecuado. Por tanto debe tomar decisiones inmediatas y eliminar los
impedimentos que vayan surgiendo en el momento, aunque en
ocasiones

no

cuente

con

toda

la

informacin

necesaria.

Su

responsabilidad es entre otras, la de hacer de paraguas ante las

presiones externas y motivar al resto del equipo. Por tanto, la labor de
Scrum Master requiere una fuerte personalidad ya que debe facilitar el
trabajo del equipo sin imponer autoridad. Las personas que ejercen este
role deben ser capaces de hacer cualquier cosa por ayudar al equipo de
desarrollo, incluso aunque estas acciones estn enfrentadas con sus
25

propios intereses. Deben ser personas poco conformistas y con mucha

c)

iniciativa. Eliminar impedimentos requiere determinacin y tenacidad.

El Scrum Team lo conforman las personas responsables de
implementar la funcionalidad o funcionalidades elegidas por el Product
Owner. Debe ser un conjunto de personas motivadas con habilidades y
capacidades complementarias que estn comprometidos por un
propsito comn, cumplir el objetivo del sprint. El equipo tiene plena
autoridad para tomar todas las decisiones que consideren adecuadas en
el desarrollo del proyecto, auto-organizndose y auto-disciplinndose.
As, por ejemplo, en las reuniones de planificacin el Product Owner y el
Scrum Team deben llegar a un acuerdo realista sobre las historias de
usuario que se van a completar en el siguiente sprint y si en algn
momento el Scrum Team considera que algunas de las prioridades del
Product Owner no es razonable dispone de libertad absoluta para
resear esta circunstancia y obligar al propietario del producto a variar
sus prioridades. Tericamente, se estima que debera estar formado por
un nmero de entre 7 u 8 miembros como mximo y 2 como mnimo.

Existe otro rol secundario, el cliente es o son los beneficiarios finales del
producto, y quienes viendo los progresos, pueden aportar ideas, sugerencias o
necesidades. Su participacin es importantsima e imprescindible en esta
metodologa.
2.2.5. Base de datos
Segn Connlly (2005, p. 14), en su obra sistemas de bases de datos
menciona que: una base de datos es un repositorio centralizado, posiblemente
de gran tamao, compuestos por datos que pueden ser utilizados
26

simultneamente por mltiples departamentos y usuarios. En lugar de disponer

de una serie de archivos desconectados con datos redundantes, todos los
elementos de datos estn integrados, mantenindose al mnimo las
posibilidades de duplicaciones.
De acuerdo con Luque (2002, p. 14), menciona que: una base de datos es
un repositorio centralizado, posiblemente de gran tamao, compuestos por
datos que pueden ser utilizados simultneamente por mltiples departamentos
y usuarios. La base de datos no almacena solo los datos operacionales de la
organizacin, sino tambin una descripcin de dichos datos. Por esta razn, a
veces se suele describir a las bases de datos como una coleccin auto
descriptiva de registros integrados.
Para el grupo de investigadores una base de datos es una serie de datos
organizados que se relacionan entre s, los mismos que son recolectados
controlados y gestionados para que puedan ser utilizados posteriormente por
los sistemas de informacin de una empresa, institucin o negocio en
particular.
2.2.5.1.

Caractersticas de las bases de datos

La informacin que forma parte de una base de datos puede organizase de

mltiples formas pero con independencia de la arquitectura de la base de
datos, esta debe cumplir con una serie de caractersticas para ser considerada
como tal, algunas de las cuales se describirn a continuacin:
a) Versatilidad para la presentacin de la informacin: si bien la informacin
que forma parte del dominio de un problema es nica y caracteriza a ese

27

problema o sistema, pueden existir diferentes visiones de esa

informacin.
b) Desempeo: las bases de datos deben asegurar un tiempo de respuesta
adecuado en la comunicacin hombre-mquina, permitiendo el acceso
simultneo al mismo o distinto conjunto de tems de datos para el mismo
o distinto procedimiento.
c) Mnima Redundancia: una de las principales razones por las que surgi
la tecnologa de las bases de datos fue el evitar la alta redundancia que
se presentaba en los sistemas de procesamientos de la informacin
debido al uso de archivo con estructuras planas.
d) Capacidad de acceso: una base de datos debe ser capaz de responder,
en un tiempo aceptable, a cualquier consulta sobre la informacin que
mantiene, sin restricciones graves en cuento a los tems, relaciones,
etc., solicitados en la misma, y respondiendo al usuario rpidamente.
e) Simplicidad: las bases de datos deben estar basadas en
representaciones lgicas simples que permita la verificacin en la
presentacin del problema que representa y ms an, la modificacin de
requisitos en el mismo.
f) Integridad: hace referencia a la veracidad de los datos almacenados con
respecto a la informacin existente en el dominio del problema que trata
la misma.
g) Seguridad y privacidad: hace referencia a la capacidad de esta para
proteger los datos su prdida total o parcial por fallos del sistema o por
accesos accidentales o intencionados a los mismos.
2.2.5.2. Modelo de bases de datos
a) Modelo de Bases de datos orientados a objetos
Para Luque (2002, p. 45), una base de datos orientada a objetos es
una coleccin de objetos en los que su estado, comportamiento y
relaciones son definidas de acuerdo con un modelo de datos orientado a
28

objetos, y un sistema de base de datos orientado a objetos (SGBDOO) es

un sistema de base de datos que permite la definicin y manipulacin de
una base de datos orientada a objetos.
Segn Connlly (2005, p. 39), los sistema de gestin de base de datos
orientados a objetos (SGBD), combinan caractersticas de orientacin a
objetos y lenguajes de programacin orientados a objetos con
capacidades de bases de datos. Estos sistemas estn basados en la
arquitectura de un lenguaje de programacin de bases de datos. Las
aplicaciones son escritas en una extensin de un lenguaje de
programacin existente, y el lenguaje y su implementacin (compilador,
preprocesador, entorno de ejecucin) han sido extendidos para incorporar
funcionalidad de base de datos.
El objetivo de estos sistemas es llegar a integrarse con mltiples
lenguajes, aunque esto puede suponer un problema debido a lo cercano
de la asociacin que se requiere entre el sistema SGBD.
b) Modelo de Base de datos de red
Una base de datos de red es una base de datos conformada por una
coleccin o set de registros, los cuales estn conectados entre s por
medio de enlaces en una red. El registro es similar al de una entidad
como las empleadas en el modelo relacional.

2.3. Marco conceptual

2.3.1. El Sprint

29

De acuerdo a Shwaber y Sutherland (2013) definen el sprint como el corazn

de Scrum, es un bloque de tiempo (time-box) de un mes o menos durante el
cual

se

crea

un

incremento

de

producto

Terminado,

utilizable

potencialmente desplegable. Es ms conveniente si la duracin de los Sprints

es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint
comienza inmediatamente despus de la finalizacin del Sprint previo.
Los Sprints contienen y consisten de la Reunin de Planificacin del Sprint
(Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de
desarrollo, la Revisin del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective).
Durante el Sprint:

No se realizan cambios que puedan afectar al Objetivo del Sprint

(Sprint Goal);
Los objetivos de calidad no disminuyen; y,
El alcance puede ser clarificado y renegociado entre el Dueo de
Producto y el Equipo de Desarrollo a medida que se va aprendiendo
ms.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor de

un mes. Al igual que los proyectos, los Sprints se usan para lograr algo. Cada
Sprint tiene una definicin de qu se va a construir, un diseo y un plan flexible
que guiar la construccin y el trabajo y el producto resultante.
Los Sprints estn limitados a un mes calendario. Cuando el horizonte de un
Sprint es demasiado grande la definicin de lo que se est construyendo podra
cambiar, la complejidad podra elevarse y el riesgo podra aumentar. Los
Sprints habilitan la predictibilidad al asegurar la inspeccin y adaptacin del
30

progreso al menos en cada mes calendario. Los Sprints tambin limitan el

riesgo al costo de un mes calendario.
2.3.2. Historias de usuario
Segn Cohen (2004), las historias de usuario son el elemento base que
utiliza SCRUM para describir las caractersticas que el usuario espera que
tenga el software que se va a desarrollar. Por lo tanto, pueden incorporar tanto
cuestiones relacionadas con las funciones del sistema como con cualquier otro
aspecto del mismo (restricciones, rendimiento, etc.). Las historias de usuario se
presentan desde la perspectiva del usuario. As, no se describen utilizando una
terminologa tcnica sino que se escriben utilizando un lenguaje cercano al
dominio de la aplicacin que se est desarrollando de forma que sea
comprensible por los clientes y por los desarrolladores. Las historias de usuario
se construyen bajo un mismo esqueleto que centra el foco de las
caractersticas del producto.
-Primero se determina quin propone la historia de usuario,
-luego se describe la caracterstica que se cubre con la historia de usuario
y,
-finalmente se especifica la razn por la que dicha caracterstica es
necesaria.

2.3.3. Historia clnica veterinaria

La historia clnica es toda informacin proveda por una persona que
realmente conviva con la mascota, estos datos no son cuestiones tcnicas,
31

se pregunta acerca de lo ms comn, del da a da de la mascota, mientras

ms detallada sea, existen ms posibilidades de encontrar rpidamente la
solucin.
Segn Llanio (1992), citado por Barreto (2000) seala que:
La historia clnica sirve para realizar una recoleccin ordenada de datos de
identidad, sntomas, signos y otros elementos que permitan al mdico
plantear un diagnstico clnico sindrmico y nosolgico, que puede ser
provisional en su primera etapa, y se afirmar o negar con el anlisis del
resultado de las investigaciones de laboratorio clnico, radiogrficas,
endoscpicas o de otro tipo.
El mdico veterinario, por obvias razones, no pueden preguntarles a sus
pacientes cules son sus malestares, por lo que el sistema de diagnstico
es por eliminacin, con base en la informacin dada por el propietario y el
examen que realiza al perro, a partir de aqu propone los diagnsticos
posibles y determina si requiere estudios tales como rayos x, ultrasonido,
pruebas de laboratorio, etc., con toda esa informacin, determina la causa
del problema. En ocasiones, los tratamientos son indicados antes de saber
el diagnstico exacto para proteger a la mascota.

32

BIBLIOGRAFIA
Pressman, R. (2010). Ingeniera del Software: un enfoque prctico. Mxico,
D.F.: McGrawHill.
Sims, C., y Johnson, H. (2011). Elements of Scrum. Foster City, California:
Dymaxicom
Cans, J. H., Letelier, P., y Penads, M. (2003). Metodologas giles en el
desarrollo de software. Universidad Politcnica de Valencia, Valencia.
Rodriguez Gonzalez, Pilar (2008). Estudio de la Aplicacin de Metodologas
giles para la Evolucin de Productos Software. Tesis de maestra, Facultad
de Informtica, Universidad Politcnica de Madrid, Madrid, Espaa.
Schwaber, K., Beedle, M. (2006): Agile Software Development with SCRUM.
En: Conchango. ISBN: 0130676349
Cohen, M. (2004). User Stories Applied for Agile Software Development. The
Addison Wesley Signature Series. ISBN: 0321205685
Beck, K., et al. (2001). Principios del Manifiesto gil. En: Manifiesto por el
Desarrollo gil de Software. Consultado el 14 de junio del 2016. Disponible en
http://www.agilemanifesto.org/iso/es/principles.html
La Rosa, C. y Diez, J. (2011). Sistema de gestin de reportes de oportunidad
de mejora. Tesis de licenciatura, Facultad de Ingeniera, Universidad Peruana
de Ciencias Aplicadas, Lima, Per.
Ruiz, C. y Telaya, L. (2014). Implementacin de una red social usando
metodologas giles para mejorar el proceso de participacin estudiantil en la
Universidad Autnoma del Per. Tesis de licenciatura, Facultad de Ciencias de
Gestin, Universidad Autnoma del Per, Lima, Per.

33

Villarruel, M. (2015). Sistema de gestin para historias clnicas bajo la

plataforma Android orientado a los mdicos del condominio del hospital
Millennium. Tesis de licenciatura, Facultad de Ingeniera en Sistemas
Electrnica e Industrial, Universidad Tcnica de Ambato, Ambato, Ecuador.
Ogalla, F. (2005). Sistema de Gestin: Una gua prctica. Barcelona: Daz de
Santos.
Barreto, J. (2000). La historia clnica: documento cientfico del mdico.
Ateneo, 1(1), 50-5.
K. Schwaber y J. Sutherland (2013). La gua de Scrum. En: Scrum Guides.
Consultado
el
12
de
junio
del
2016.
Disponible
en
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide
ES.pdf#zoom=100.
Hernndez, M. (1998). Procedimiento de diagnstico para el control de gestin
aplicado en una industria farmacutica. Tesis de doctorado, Instituto Superior
Politcnico Jos Antonio Echeverra, La Habana, Cuba.
Peralta, M. (2008). Sistema de Informacin.
guila, J. (1999). La Gestin del Conocimiento.
Connlly, T. (2005). Sistemas de Bases de Datos. Madrid Espaa.
Luque, I. (2002). Base de Datos desde Chen hasta Codd con Oracle.

34