UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN FACULTAD DE INGENIERÍA ESCUELA ACADÉMICO ACADÉMICO PROFESIONAL DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS
TRABAJO ENCARGADO
“PROTOTIPO DE SISTEMA UNIDAD UNIDAD DE CAJA DE UNA FARMACIA” CURSO: ANÁLISIS DE SISTEMAS I DOCENTE: Ing. GIANFRANCO MÁLAGA TEJADA ESTUDIANTES: ✔ ALANOCA ANAHUA, ZARITA GLORIA ✔ LINARES ROJAS, CATHERINE CATHERINE ✔ AGUIRRE AGUIRRE VARGAS, VARGAS, MARVIN ANTONY ANTONY
PROVEEDORES: MAMANI SI!A ARACELY HERNADE" RAMOS ALE#ANDER CAHUANA MA$UERA GALO A!O: SEGUNDO % TURNO: TARDE % GRUPO: A FECHA DE ELABORACI&N: '()*+)'*,FECHA DE ENTREGA: '+)*+)'*, TACNA / PER0
'*,-
METODOLOGÍAS ÁGILES MARCO TE&RICO Las metodologías ágiles son una serie de técnicas para la gestión de proyectos que han surgido como contraposición a los métodos clásicos de gestión. Surgieron en el ámbito del desarrollo de software, y han sido exportadas a otro tipo de proyectos. odas las metodologías que se consideran ágiles cumplen con el manifiesto ágil que no es más que una serie de principios que se agrupan en ! "alores# ➔
➔
➔
➔
$l indi"iduo 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. %s más importante construir un buen equipo que construir el entorno. &uchas "eces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. %s me'or crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. (esarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es )no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante*. %stos documentos deben ser cortos y centrarse en lo fundamental. La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. %sta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. +esponder a los cambios más 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 tecnología, en el equipo, etc.- determina también el éxito o fracaso del mismo. or lo tanto, la planificación no debe ser estricta sino flexible y abierta. /on las metodologías ágiles lo que se desea es minimi0ar el impacto de las tareas que no son totalmente imprescindibles para conseguir el ob'eti"o del proyecto. Se pretende aumentar la eficiencia de las personas in"olucradas en el proyecto y, como resultado de ello, minimi0ar el coste. L12 345n6531782 98;<;7;g=12 >g5782 %n cada proyecto podemos adoptar una, o "arias, en función de las características del propio proyecto y del equipo.
%ntre las metodologías ágiles más usadas se encuentran# 1 S/+2&. %s un marco de traba'o que nos proporciona una serie de herramientas y roles para, de una forma iterati"a, poder "er el progreso y los resultados de un proyecto. 1 3$45$4. Se basa en una idea muy simple. 6sta es que el traba'o en curso 7or8 9n rogress, 79- debería limitarse y sólo deberíamos empe0ar con algo nue"o cuando un bloque de traba'o anterior haya sido entregado o ha pasado a otra función posterior de la cadena. %n el presente traba'o daremos a conocer una metodología que combina las me'ores características de S/rum y 3anban, que se denominará Scrumban.
https#::es.wi8i"ersity.org:wi8i:&etodolog;/<;$(as=;/<;$>giles=de=desarrollo=software http#::www.carlosfau.com.ar:nqi:nqifiles:?=$gil.pdf http#::blog.leanmonitor.com:es:que@son@las@metodologias@agiles: SCRUMBAN Scrum se centra en pequeAos equipos de autoorgani0ación multifuncionales, que requieren los miembros del equipo para di"idir el traba'o en una lista de pequeAos resultados concretos, y estimar el esfuer0o relati"o de cada elemento. Scrum se basa en iteraciones cortas de longitud fi'a generalmente >@! semanas-, con el código potencialmente entregable demostrado después de cada iteración, y el uso retrospecti"o para optimi0ar el proceso después de cada iteración. 3anban es una herramienta para "isuali0ar el flu'o de traba'o mediante la di"isión del traba'o en peda0os, escribiendo cada elemento en una tar'eta y ponerlo en la pared. 2tili0a nombrado columnas de tareas pendientes, en proceso y terminado- para ilustrar donde cada elemento está en el flu'o de traba'o. Limitar el traba'o en curso ayuda a limitar explícitamente el nBmero de elementos puede ser en cada estado del flu'o de traba'o. Scrumban ayuda a aumentar la calidad, el traba'o 'usto a tiempo, reducir el tiempo de plomo y también ayuda a me'ora continua de procesos, reduciendo al mínimo los residuos debido a la eliminación de todo lo que no está agregando "alor al cliente.
http#::intland.com:blog:agile:scrum@8anban@scrumban:
CARACTERÍSTICAS %n este caso, tener ambos proyectos me0clados introduce más comple'idad. La estrategia es di"idir el enfoque y traba'ar dos metodologías# CS/+2& para &antenimiento. C3$45$4 para Soporte. Scrumban al ser una metodología deri"ada de los métodos de desarrollo Scrum y 3anban, posee ciertas características de ambos modelos (e Scrum C +oles# /liente, equipo con los diferentes perfiles que se necesiten-. C +euniones# reunión diaria. C Derramientas# pi0arra (e 3anban C Elu'o "isual C Dacer lo que sea necesario, cuando sea necesario y solo la cantidad necesaria. C Limitar la cantidad de traba'o 79C Fptimi0ación del proceso.
Scrumb vs Scrumban
%sta metodología 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 producción.
%n estos casos los sprints periodos de duración constante en los cuales se lle"a a cabo un traba'o en sí- de la metodología Scrumb no es factible dado que los errores que ocurrirán a lo largo de la tarea son difíciles de determinar, por ende, no es posible determinar el tiempo de cada historia. Siendo más factible adoptar un flu'o de traba'o continuo propio del modelo 3anban. https#::u"adoc.u"a.es:bitstream:>G
!IJ:>:EK@5.>>.pdf
PROCEDIMIENTO %n el panel Scrum, metemos las historias priori0adas.(ichas historias se subdi"iden en tareas y se estiman en puntos de historia en la reunión de planificación de sprint iteraciones de un mes natural y hasta de dos semanas-. $demás se puede separar por colores en función del proyecto, con los que nos queda un panel ordenado "erticalmente por prioridad y hori0ontalmente por proyecto. Las columnas como es habitual, tra0an el flu'o de las tareas.
%n el panel 3anban, 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 f inal. %so si, se priori0an teniendo en cuenta < filas de urgencia# FIRE: 2na tarea en esta fila significa )(e'a todo lo que estés haciendo y atiende esta tarea*. $ eso le llamamos bala de plata, y está establecida la limitación de que solo puede haber una a la "e0.
PRIO: %sta tarea significa )an pronto como acabes lo que estás haciendo, por fa"or ponte a hacer esta tarea* ASAP: M esta Bltima significa# )(eberías hacer esta tarea, pero solo si no se compromete el ob'eti"o del sprint*
?3:))82.275<82?148.n8)1@;12?5@11)95n526491ng14135<1 ?3:))1g571n<.38)7;g)26491n8;765;n<826496;n@1n1n) C%n Soporte se implementa 3$45$4 con prácticas de S/+2&. C%n &antenimiento se usa S/+2& pero no es posible cumplir todas sus prescripciones. C%l hecho de compartir ambos proyectos lle"a a tener implementaciones ágiles híbridas @ S/+2&5$4.
1 1 1 1 1 1 1 1 1 1 1 1
ROLES 2n miembro especiali0ado en &antenimiento. (os miembros encargados del Soporte. +otación semanal. (ifícil transición entre roles. 2n miembro especiali0ado en &antenimiento. 2n miembro especiali0ado en Soporte. 2n miembro di"idido entre ambos proyectos. roduce me'ores resultados. 4o se comparte el conocimiento. odos los miembros atienden ambos proyectos. Las historias de mantenimiento tienen un responsable, pero las tareas se reparten. Se asegura la transferencia constante de conocimiento.
1 1 1 1 1 1
RESULTADOS &ayor "isibilidad del área de $rquitectura en la organi0ación. &e'or apoyo del área a los proyectos de desarrollo. +etroalimentación desde otras áreas hacia las aplicaciones trans"ersales. Keneración de "alor en las aplicaciones trans"ersales de la compaAía. (ifusión de la metodología para equipos de características similares. Keneración de iniciati"as para el equipo de 9mplementación de &etodologías Ngiles.
RELACI&N CON LA USABILIDAD
@ @ @ @ @
enemos entendido que esta metodología es de retroalimentación tomando en cuenta me'oras y sugerencias del cliente-, por lo que repetimos el ciclo )n* "eces. %l problema surge al momento de implementar ya que hasta la e"aluación técnica la idea podría estar en lo cierto, pero generalmente estas modificaciones son para optimi0ar el proceso ya presente. or lo que el querer me'orar su funcionamiento a la hora de implementar sugiere cambiar parámetros en# La recolección de datos 2so de recursos Oerarquía de operación &odificación de interfa0 osible reestructuración del algoritmosi hemos utili0ado una estructura rígida o no es eficiente con las nue"as características%s decir, nuestra usabilidad se "ería afectada en el
