UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN

FACULTAD DE INGENIERA
ESCUELA ACADMICO PROFESIONAL DE INGENIERA EN INFORMTICA Y
SISTEMAS

TRABAJO ENCARGADO

PROTOTIPO DE SISTEMA UNIDAD DE CAJA DE UNA

FARMACIA
CURSO: ANLISIS DE SISTEMAS I
DOCENTE: Ing. GIANFRANCO MLAGA TEJADA
ESTUDIANTES:
ALANOCA ANAHUA, ZARITA GLORIA
LINARES ROJAS, CATHERINE
AGUIRRE VARGAS, MARVIN ANTONY
PROVEEDORES:
- MAMANI SIA ARACELY
- HERNADEZ RAMOS ALEXANDER
CAHUANA MAQUERA GALO
AO: SEGUNDO | TURNO: TARDE | GRUPO: A
FECHA DE ELABORACIN: 28/09/2015
FECHA DE ENTREGA: 29/09/2014
TACNA PER

2015

METODOLOGAS GILES
MARCO TERICO
Las metodologas giles son una serie de tcnicas para la gestin de proyectos que han
surgido como contraposicin a los mtodos clsicos de gestin.
Surgieron en el mbito del desarrollo de software, y han sido exportadas a otro tipo de
proyectos.
Todas las metodologas que se consideran giles cumplen con el manifiesto gil que no es
ms que una serie de principios que se agrupan en 4 valores:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
La gente es el principal factor de xito de 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.
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.
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.
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.
Con las metodologas giles lo que se desea es minimizar el impacto de las tareas que no
son totalmente imprescindibles para conseguir el objetivo del proyecto. Se pretende
aumentar la eficiencia de las personas involucradas en el proyecto y, como resultado de
ello, minimizar el coste.
Las principales metodologas giles
En cada proyecto podemos adoptar una, o varias, en funcin de las caractersticas del
propio proyecto y del equipo.

Entre las metodologas giles ms usadas se encuentran:

SCRUM. Es un marco de trabajo que nos proporciona una serie de herramientas y roles
para, de una forma iterativa, poder ver el progreso y los resultados de un proyecto.
KANBAN. Se basa en una idea muy simple. sta es que el trabajo en curso (Work In
Progress, WIP) debera limitarse y slo deberamos empezar con algo nuevo cuando un
bloque de trabajo anterior haya sido entregado o ha pasado a otra funcin posterior de la
cadena.
En el presente trabajo daremos a conocer una metodologa que combina las mejores
caractersticas de SCrum y Kanban, que se denominar Scrumban.

https://es.wikiversity.org/wiki/Metodolog%C3%ADas_%C3%A1giles_de_desarrollo_software
http://www.carlosfau.com.ar/nqi/nqifiles/XP_Agil.pdf
http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/
SCRUMBAN
Scrum se centra en pequeos equipos de autoorganizacin multifuncionales, que requieren
los miembros del equipo para dividir el trabajo en una lista de pequeos resultados
concretos, y estimar el esfuerzo relativo de cada elemento.
Scrum se basa en iteraciones cortas de longitud fija (generalmente 1-4 semanas), con el
cdigo potencialmente entregable demostrado despus de cada iteracin, y el uso
retrospectivo para optimizar el proceso despus de cada iteracin.
Kanban es una herramienta para visualizar el flujo de trabajo mediante la divisin del trabajo
en pedazos, escribiendo cada elemento en una tarjeta y ponerlo en la pared. Utiliza
nombrado columnas (de tareas pendientes, en proceso y terminado) para ilustrar donde
cada elemento est en el flujo de trabajo. Limitar el trabajo en curso ayuda a limitar
explcitamente el nmero de elementos puede ser en cada estado del flujo de trabajo.
Scrumban ayuda a aumentar la calidad, el trabajo justo a tiempo, reducir el tiempo de plomo
y tambin ayuda a mejora continua de procesos, reduciendo al mnimo los residuos debido
a la eliminacin de todo lo que no est agregando valor al cliente.

http://intland.com/blog/agile/scrum-kanban-scrumban/

CARACTERSTICAS
En este caso, tener ambos proyectos mezclados introduce ms complejidad.
La estrategia es dividir el enfoque y trabajar dos metodologas:
SCRUM para Mantenimiento.
KANBAN para Soporte.
Scrumban al ser una metodologa derivada de los mtodos de desarrollo Scrum y Kanban,
posee ciertas caractersticas de ambos modelos
De Scrum
Roles: Cliente, equipo (con los diferentes perfiles que se necesiten).
Reuniones: reunin diaria.
Herramientas: pizarra
De Kanban
Flujo visual
Hacer lo que sea necesario, cuando sea necesario y solo la cantidad necesaria.
Limitar la cantidad de trabajo (WIP)
Optimizacin del proceso.

Scrumb vs Scrumban
Esta metodologa es adecuada para proyectos en los que los usuarios cambian
constantemente los requerimientos de software, produciendo as muchos errores
inesperados durante todo el ciclo de desarrollo de produccin.

En estos casos los sprints (periodos de duracin constante en los cuales se lleva a cabo un
trabajo en s) de la metodologa Scrumb no es factible dado que los errores que ocurrirn a
lo largo de la tarea son difciles de determinar, por ende, no es posible determinar el tiempo
de cada historia. Siendo ms factible adoptar un flujo de trabajo continuo propio del modelo
Kanban.
https://uvadoc.uva.es/bitstream/10324/1495/1/TFG-B.117.pdf

PROCEDIMIENTO
En el panel Scrum, metemos las historias priorizadas.Dichas historias se subdividen en
tareas y se estiman en puntos de historia en la reunin de planificacin de sprint (iteraciones
de un mes natural y hasta de dos semanas). Adems se puede separar por colores en
funcin del proyecto, con los que nos queda un panel ordenado verticalmente por prioridad
y horizontalmente por proyecto. Las columnas como es habitual, trazan el flujo de las
tareas.

En el panel Kanban, al contrario, entran directamente las tareas sin estimar, es decir, las
tareas de este panel no se estiman al inicio, sino que cuantifican en horas al final. Eso si, se
priorizan teniendo en cuenta 3 filas de urgencia:
FIRE: Una tarea en esta fila significa Deja todo lo que ests haciendo y atiende esta tarea.
A eso le llamamos bala de plata, y est establecida la limitacin de que solo puede haber
una a la vez.

PRIO: Esta tarea significa Tan pronto como acabes lo que ests haciendo, por favor ponte
a hacer esta tarea
ASAP: Y esta ltima significa: Deberas hacer esta tarea, pero solo si no se compromete el
objetivo del sprint

http://es.slideshare.net/akobashikawa/mini-scrumban-gua-rapida
http://agiland.pe/blog/scrumban-evolucion-de-scrum-con-kanban/
En Soporte se implementa KANBAN con prcticas de SCRUM.
En Mantenimiento se usa SCRUM pero no es posible cumplir todas sus prescripciones.
El hecho de compartir ambos proyectos lleva a tener implementaciones giles hbridas SCRUMBAN.

ROLES
Un miembro especializado en Mantenimiento.
Dos miembros encargados del Soporte.
Rotacin semanal.
Difcil transicin entre roles.
Un miembro especializado en Mantenimiento.
Un miembro especializado en Soporte.
Un miembro dividido entre ambos proyectos.
Produce mejores resultados.
No se comparte el conocimiento.
Todos los miembros atienden ambos proyectos.
Las historias de mantenimiento tienen un responsable, pero las tareas se reparten.
Se asegura la transferencia constante de conocimiento.

RESULTADOS
Mayor visibilidad del rea de Arquitectura en la organizacin.
Mejor apoyo del rea a los proyectos de desarrollo.
Retroalimentacin desde otras reas hacia las aplicaciones transversales.
Generacin de valor en las aplicaciones transversales de la compaa.
Difusin de la metodologa para equipos de caractersticas similares.
Generacin de iniciativas para el equipo de Implementacin de Metodologas giles.

RELACIN CON LA USABILIDAD

Tenemos entendido que esta metodologa es de retroalimentacin (tomando en cuenta

mejoras y sugerencias del cliente), por lo que repetimos el ciclo n veces.
El problema surge al momento de implementar ya que hasta la evaluacin tcnica la idea
podra estar en lo cierto, pero generalmente estas modificaciones son para optimizar el
proceso ya presente. Por lo que el querer mejorar su funcionamiento a la hora de
implementar sugiere cambiar parmetros en:
La recoleccin de datos
Uso de recursos
Jerarqua de operacin
Modificacin de interfaz
Posible reestructuracin del algoritmo(si hemos utilizado una estructura rgida o no es
eficiente con las nuevas caractersticas)
Es decir, nuestra usabilidad se vera afectada en el 3 paso del ciclo, ya sea que esta haya
mejorado (si logramos adaptarlo correctamente) o que haya empeorado la eficiencia y/o
eficacia (si forzamos a adaptarlo a nuestra estructura ya planteada y esta no es la
adecuada).