SCRUM
SCRUM
UNIVERSIDAD SAN MARTIN DE PORRESFACULTAD DE INGENIERIA Y
ARQUITECTURA
CALIDAD DE SOFTWARE
METODOLOGA GIL SCRUM
Tabla de ContenidoCAPTULO 1 : SCRUM31.Introduccin32.La Esencia
de SCRUM43.Elementos de SCRUM63.1.Roles63.2.Poda de
Requerimientos73.3.Product Backlog73.4.Sprint83.5.Valores9
CAPTULO 2 : METODOLOGA...102.Proceso de Desarrollo....102.1.
Introduccin.102.2. Proceso Iterativo e Incremental....102.3. Etapas
del Proceso de Desarrollo.112.3.1. Planificacin....112.3.2.
Anlisis....112.3.3. Diseo..112.3.4. Construccin y Pruebas112.3.5.
Implementacin...112.4. EDT Del Proceso de Desarrollo..122.5.
Herramientas...122.5.1.Tcnicas de relevamiento.132.5.2. Work
Breakdown Structure (WBS).132.5.3. Casos de uso132.5.4. Diagrama de
actividades..142.5.5. Diagrama de Entidad Relacin (DER..142.5.6.
ScrumWorks142.5.7. Burndown chart...152.5.8. Clarion
5.5..153.1.Planificacin Inicial163.1.1.Solicitud del
proyecto.163.1.2. El porqu de la solicitud del proyecto.163.1.3.
Evaluacin de la informacin deseada.163.1.4. Situacin actual173.1.5.
Estructura de Divisin del Trabajo (EDT.173.1.6.Conformacin del
equipo humano...183.1.7.Estimacin del plazo de entrega y
precio.193.1.8.Gestin de Riesgo193.1.9.Propuesta comercial.21
: SCRUM
1. Introduccin
Scrum es una metodologa gil de gestin de proyectos cuyo objetivo
primordial es elevar al mximo la productividad de un equipo. Reduce
al mximo la burocracia y actividades no orientadas a producir
software que funcione y produce resultados en periodos muy breves
de tiempo. Como mtodo, Scrum enfatiza valores y prcticas de gestin,
sin pronunciarse sobre requerimientos, prcticas de desarrollo,
implementacin y dems cuestiones tcnicas. Ms bien delega
completamente en el equipo la responsabilidad de decidir la mejor
manera de trabajar para ser lo ms productivos posibles.
Esta metodologa esta basada en un proceso constructivo iterativo
e incremental donde las iteraciones tienen duracin 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 ncleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeas carreras
llamadas Sprints. Cada Sprint es guiado por una lista de
funcionalidades priorizadas, que son planificadas con anterioridad.
Dentro de cada Sprint nunca se efecta nada que no sea necesario
para cumplir los requerimientos del mismo.
Scrum no implica mayor complejidad, pero que s necesita de un
gran aporte colaborativo por parte de los integrantes del equipo.
Esto es debido a que esta metodologa no se centra en seguir un plan
pre elaborado, sino en adaptarse de manera contina a las
situaciones que se vayan presentando durante el proyecto.
En pocas palabras, el hecho de que sea una metodologa gil no
implica que carezca de buenas prcticas o que genere un manejo
desordenado del proyecto. Por eso, en el presente trabajo, se
explicar sobre la metodologa, cmo est conformada, qu roles
participan, la forma de trabajo de Scrum, y varios puntos ms.
Asimismo, se dar un ejemplo prctico de un proyecto realizado con la
metodologa.
2. La Esencia de SCRUM
La metodologa SCRUM no se basa en un desarrollo clsico, esta
metodologa rompe con el clsico esquema de pre planificar un
proyecto e ir siguiendo la estructura trazada, maneja de una manera
emprica y adaptable la forma cmo va evolucionando el proyecto, es
decir, tiene unas prcticas que hacen que esta tenga una gestin
gil.
Caractersticas: Ms que una metodologa de desarrollo es para
gestionar proyectos, no contiene definiciones en reas de ingeniera.
Con visin de que el trabajo es efectuado por equipos auto
organizados y auto-dirigidos, logrando motivacin, responsabilidad y
compromiso. Est basada en un proceso constructivo iterativo e
incremental donde las iteraciones tienen duracin fija. Contiene
definicin de roles, prcticas y productos de trabajo escritas de
forma simple. Est soportada en un conjunto de valores y
principios.
Revisin de las IteracionesEn la metodologa, las iteraciones son
conocidas como sprint. Al final de cada sprint, siempre se realiza
una revisin del proyecto con todo el equipo del proyecto. Estas son
las reuniones donde, como mximo se determinar algn cambio
significativo en el producto final.
Desarrollo Incremental y EvolutivoNo hay un diseo pre elaborado
para el proyecto. El hecho que sea incremental quiere decir que al
final de cada iteracin tenemos una parte del producto final
complemente funcional, lista para ser probada y evaluada. Esto
ayuda a reducir la incertidumbre y adecuarse a los eventuales
cambios que se produzcan. Si se desea tratar de hacer una
planificacin a futuro, tal como la duracin del proyecto, se tendr
que confiar en la experiencia de un miembro del equipo que pueda
estimar el tiempo de las iteraciones y el desarrollo del producto
en general. Sin embargo, no es recomendable pre estimar tiempos, ay
que el constante cambio va a variar el tiempo inicial calculado.
Hay que tener en cuenta que este no es un desarrollo por fases;
esto mismo es lo que hace de la metodologa, gil.
Auto-OrganizacinEn las metodologas giles, la pre-planificacin
del proyecto recae sobre un rol. Este rol ser el que participe en
la toma de decisiones a lo largo del proyecto. En cambio, en Scrum,
los equipos, al ser auto-organizados, pueden tomar decisiones como
equipo sin esperar la autorizacin de algn otro rol.
ColaboracinLa naturaleza gil de la metodologa hace fcil que los
integrantes del equipo colaboren entre s, ya que si se realiza de
manera abierta, se pueden compartir los conocimientos de cada
integrante, independientemente de su responsabilidad en el
proyecto, lo que enriquece al proyecto y se puede manejar eventos
ms fcilmente al existir 100% de comunicacin.
3. Elementos de SCRUM
3.1. RolesLa dimensin del equipo total de Scrum no debera ser
superior a veinte personas. Si hay ms, lo ms recomendable es formar
varios equipos. No hay una tcnica oficial para coordinar equipos
mltiples, pero se han documentado experiencias de hasta 800
miembros, divididos en Scrums de Scrum, definiendo un equipo
central que se encarga de la coordinacin, las pruebas cruzadas y la
rotacin de los miembros.
Scrum tiene una estructura muy simple. Todas las
responsabilidades del proyecto se reparten en 3 roles:
Product owner (Dueo del producto)Se le considera como el rol que
va a determinar los requerimientos. Este rol normalmente lo cumple
una persona de parte del cliente que conozca a fondo las
necesidades y pueda proporcionar la informacin necesaria en el
momento preciso.
Representa a todos los interesados en el producto final. Sus
reas de responsabilidad son: Financiacin del proyecto Requisitos
del sistema Retorno de la inversin del proyecto Lanzamiento del
proyecto
Es el responsable oficial del proyecto, gestin, control y
visibilidad de la lista de acumulacin 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 (Lder del proyecto)Responsable del proceso Scrum,
de cumplir la meta y resolver los problemas. As como tambin, de
asegurarse que el proyecto se lleve a cabo de acuerdo con las
prcticas, valores y reglas de Scrum y que progrese segn lo
previsto.
Interacta con el cliente y el equipo. Coordina los encuentros
diarios, y se encarga de eliminar eventuales obstculos. Debe ser
miembro del equipo y trabajar a la par.
Team (Equipo)Est conformado por todas las personas que son parte
del proyecto. En esta metodologa no existen diseadores, analistas,
programadores. Si bien cada persona cumple una funcin de acuerdo a
las actividades requeridas, todos son parte del equipo y deben ser
capaces de saber todo acerca del proyecto.
Responsable de transformar el Backlog de la iteracin en un
incremento de la funcionalidad del software. Tiene autoridad para
reorganizarse y definir las acciones necesarias o sugerir remocin
de impedimentos.
Auto-gestionado Auto-organizado Multi-funcional
La dimensin del equipo total de Scrum no debera ser superior a
veinte.
El nmero ideal es diez, ms o menos dos. Si hay ms, lo ms
recomendable es formar varios equipos. No hay una tcnica oficial
para coordinar equipos mltiples, pero se han documentado
experiencias de hasta 800 miembros, divididos en Scrums de Scrums,
definiendo un equipo central que se encarga de la coordinacin, las
pruebas cruzadas y la rotacin de los miembros.
Poda de RequerimientosLa primera actividad es armar una lista
exhaustiva de los requerimientos originales del sistema. Luego se
procede a ver qu requerimientos son realmente necesarios, cules
pueden posponerse y cules eliminarse.
Para ello debe identificarse un representante con capacidad de
decisin, priorizar los requerimientos en base a su importancia y
acordar cules son los prioritarios para la fecha de entrega.
La poda de requerimientos es una buena prctica implcita en
modelos giles, se hace lo que el cliente realmente desea, no
ms.Product BacklogCon 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 dinmico que incorpora
constantemente las necesidades del sistema. Por lo tanto, nunca
llega a ser una lista completa y definitiva. Se mantiene durante
todo el ciclo de vida (hasta la retirada del sistema) y es
responsabilidad del Product Owner.Este documento est en constante
cambio (se le llama Documento Vivo) ya que con cada sprint, va
cambiando y creciendo, de acuerdo a los requisitos. Este documento
es solo manipulado por el product owner, pero todos los miembros
del equipo del proyecto.SprintUn Sprint es el periodo de tiempo
durante el que se desarrolla un incremento de funcionalidad.
Constituye el ncleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeas carreras.
Duracin mxima del Sprint: 30 das. Durante el Sprint no se puede
modificar el trabajo que se ha acordado en el Backlog. Slo es
posible cambiar el curso de un Sprint, abortndolo, y slo lo puede
hacer el Scrum Master si decide que no es viable por alguna de las
razones siguientes: La tecnologa acordada no funciona. Las
circunstancias del negocio han cambiado. El equipo ha tenido
interferencias.
Valores
Foco Los individuos y sus interacciones son ms importantes que
el proceso y las herramientas. La gente es el principal factor de
xito de un proyecto de software.
Comunicacin Scrum pone en comunicacin 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
da a da, 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 tambin 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 difciles.
Reparar un error cuando se detecta. Mejorar el cdigo siempre que el
feedback y las sucesivas iteraciones se manifiesten susceptibles de
mejora.
: Metodologa
Proceso de Desarrollo
La metodologa SCRUM basa sus soluciones en que el desarrollo de
un Proyecto se realice de una manera informal pero simple, explcita
y flexible para gestionar el desarrollo del software basando todas
sus actividades envueltas en procesos iterativos e incrementales y
adems de contar con un equipo que trabajen teniendo un objetivo
claro, hacindolo todos juntos y en la misma direccin.
Se utiliza un proceso gil iterativo e incremental que respeta
las cinco etapas tradicionales de un proyecto que facilitan su
gestin y control; ellas son: planificacin, anlisis, diseo,
construccin y prueba, e implementacin.
Cmo el objetivo final de la metodologa 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 planificacin de
todas las tareas involucradas.
Proceso Iterativo e Incremental
Este tipo de proceso de desarrollo permite hacer entregas
parciales que se van complementando segn avanza el proyecto. De
esta manera se reducen los riesgos y a la vez el cliente va
experimentando los resultados de su proyecto.
Dado que los proyectos de software son largos es comn dividir el
trabajo en mini proyectos. Cada mini proyecto es una iteracin que
resulta en un incremento. Para ser ms 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
realimentacin de informacin y de requisitos una vez iniciado el
desarrollo, as como la validacin continua del sistema. Esto permite
que cada iteracin contemple ciclos de desarrollos completos y
cortos, y obtener as rpidamente una nueva versin con mejoras.
Se ha propuesto un proceso incremental en el sentido de aadir
capacidades y funcionalidades al software de acuerdo con el
crecimiento de las necesidades; con el propsito de obtener el
sistema final tras la realizacin de diferentes ciclos. El final de
cada ciclo proporciona adems, una versin estable del software. Esto
permite entregas al cliente de forma rpida y gil.Al entregar partes
de la aplicacin a tiempo y regularmente, el equipo de desarrollo
tambin gana y establece credibilidad en su entorno y aumenta su
auto-estima. A la vez que este tipo de estrategia se enfoca ms en
las necesidades de los usuarios, instndolos a identificar sus
prioridades en cada etapa del proyecto.
ETAPAS DEL PROCESO DE DESARROLLO
PlanificacinObjetivo: Es la etapa ms importante de todas, ya que
se define el proyecto propiamente dicho.Tareas: Relevamiento
preliminar de los procesos del negocio, definicin y secuenciamiento
de actividades, definicin del alcance, estimacin de tiempos,
definicin de recursos, anlisis de riesgos, estimacin de
costos.Entregables: Documento de definicin del proyecto o del
Sprint.
En esta etapa es importante aclarar que, al comienzo, la
planificacin se realiza en forma general para determinar el
alcance, la duracin y el precio del proyecto, una vez que el
cliente decide llevarlo a cabo, las siguientes planificaciones son
a nivel de iteracin, se planifica el Sprint.
AnlisisObjetivo: Obtener todas las definiciones y
especificaciones funcionales para poder llevar adelante las fases
de Diseo y Construccin. Es una etapa clave ya que el alcance y las
caractersticas de la solucin quedan acordados, lo cual permite
mitigar los principales riesgos de un proyecto.Tareas:
Afianzamiento de las definiciones funcionales, definicin de los
requisitos a travs de casos de uso, planificacin de las etapas
posteriores y ajuste de los tiempos prestablecidos.Entregable:
Documento de alcance, casos de uso y sus respectivas
descripciones.
DiseoObjetivo: Generar el modelo de datos para que la solucin
cumpla con los requerimientos definidos. El diseo generado deber
contemplar las posibles modificaciones futuras, crecimiento de la
solucin, mayor carga e incorporacin de nuevas
funcionalidades.Tareas: Diagrama Entidad Relacin (DER), diseo de
las interfaces de usuario, diseo de las integraciones a realizar.
Durante esta etapa tambin se realizan pruebas para puntos crticos
del proyecto.
Entregables: Entre los entregables tpicos de esta etapa se
encuentran: DER, esqueleto del software armado, gua de diseo, diseo
de la infraestructura, y la planificacin ajustada con la evolucin y
avances obtenidos.
Construccin y PruebaObjetivo: Construir la solucin del Release
(Sprint), cumpliendo con las definiciones y especificaciones de los
documentos de alcance. Generalmente es la etapa de mayor duracin y
con mayor dinmica de trabajo.Tareas:
Programacinydesarrollodetodosloscomponentesy funcionalidades.
Implementacin de las estructuras de datos, y sus procedimientos,
elaboracindedocumentacin tcnicayajustes funcionales, implementacin
de las integraciones y todas las actividades necesarias para poner
en marcha la solucin. En esta etapa se realizarn las pruebas de
usabilidad, funcionalidad y carga de datos.Entregables: El
entregable principal es el incremento de software funcionando.
ImplementacinObjetivo: Disponer del sistema productivo con sus
ambientes de produccin, metodologa de trabajo y manuales
operativos. Se incluye, de ser necesario, el personal operativo
capacitado. Obtencin de nuevas funciones a agregar o posibles
errores a reparar.Tareas: Puesta en marcha de la aplicacin en el
ambiente de produccin, elaboracin de manuales operativos, y todas
las actividades relacionadas al xito del lanzamiento como la
integracin del ambiente de produccin con terceras partes,
etctera.Entregables: El sistema productivo con sus manuales
operativos, de mantenimiento y de procedimientos. Esquemas de
auditoria y seguridad. Integraciones con terceras partes
operativas.
EDT del proceso de DesarrolloPresentamos nuestro proceso de
desarrollo a travs de una Estructura de Divisin del Trabajo para
verlo grficamente:
HERRAMIENTASTcnicas de RelevamientoEntrevistas con el cliente y
los usuarios; revisin de registros, y observacinWork Breakdown
Structure WBSConocida como Estructura de Descomposicin de Trabajos
(EDT). Es un organigrama que despliega la estructura de un proyecto
y muestra su organizacin 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 comprobacin, y
determina el alcance general. As como tambin, define los
entregables del proyecto. Los entregables pueden ser etapas o
procesos del proyecto (plan del proyecto, documentacin de diseo,
etc.) o partes del producto final (pantallas, ventanas,
documentacin). 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 tcnicas de relevamiento mencionadas
anteriormente se utilizan en las dos primeras etapas, o sea para la
Planificacin y el Anlisis.Casos de UsoSon un mtodo prctico 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 comunicacin con el cliente.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
anlisis para definir los requisitos.Diagrama de ActividadesSirven
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 aparecern 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 estn claramente asociadas a un caso de
uso. Tambin se utilizan en la etapa del anlisis.Diagrama de Entidad
RelacinUn modelo de datos describe de una forma abstracta cmo se
representan los datos, sea en una empresa, en un sistema de
informacin o en un sistema de base de datos. Los DER son una
herramienta para el modelado de datos de un sistema de informacin.
Estos diagramas expresan entidades relevantes y sus
inter-relaciones. Formalmente, son un lenguaje grfico para
describir conceptos. Informalmente, son simples dibujos o grficos
que (si se saben interpretar) describen la informacin que trata un
sistema de informacin y el software que lo
automatiza.ScrumWorksPermite llevar a cabo el seguimiento del
proyecto. Es una herramienta de automatizacin de procesos giles que
admite a los equipos autoorganizarse y aumentar la productividad.
Esta herramienta, de acceso libre y fcil de utilizar, es una
aplicacin Web que permite compartir la informacin entre todo el
equipo. Esta herramienta para la administracin del proyecto
permite: Manejar dinmicamente el Backlog de Producto haciendo una
estimacin inicial del esfuerzo de cada requerimiento identificado
hasta el momento. Definir las tareas y arrastrarlas al Sprint
apropiado, donde se irn restimando diariamente. Observar un grfico
por cada Sprint que nos indica la velocidad con la que avanza el
proyecto.Estos grficos llamados burndown no slo permiten observar
el estado de avance del proyecto, sino tambin analizar sus
comportamientos e ir aprendiendo para mejorar los Sprints que
restan.Burndown chartEn Scrum se planifica y se mide el esfuerzo
restante necesario para desarrollar el producto. Esta grfica suele
utilizarse en lugar de un diagrama de PERT debido a que el camino
crtico en un desarrollo gil cambia diariamente. Esto hara obsoleto
el diagrama de PERT cada da. Es por esto que no es til una
herramienta que modele el camino crtico a partir de actividades. La
solucin es utilizar una tcnica que permita medir la velocidad de
desarrollo, para ello se utiliza el criterio del equipo a partir
del cual se calcula diariamente el camino crtico. Esto permite
recalcular el plan y la velocidad en que se realiza el trabajo. En
funcin de esto el equipo puede trabajar para acelerar o desacelerar
el trabajo para cumplir con la fecha de entrega.
Clarion 5.5Herramienta capaz de crear programas de 32 bits para
Windows 9x, NT, 2000, y XP y para la Internet / Intranet / Extranet
desde un nico cdigo y con un diseador 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).
El generador de aplicaciones junto con una serie de Templates
(plantillas) predefinidos y personalizables y las Clases ABC
(Application Builder Class), trabajan para producir cdigo OOP
(Programacin Orientada a Objetos) pre-testeado.
La base dela productividades el Lenguaje 4GL, que est
especficamente creado para construir aplicaciones de negocios con
bases de datos propias o centralizadas. Se puede acceder
virtualmente a cualquier tipo de datos a travs de una combinacin de
ODBC/ADO y los drivers nativos de las bases.
CAPTULO 3: DESARROLLO DE INGENIERA
3. Proyecto trazabilidad
3.1 Planificacin Inicial3.1.1 Solicitud de Proyecto
El presente proyecto surge de una solicitud realizada por los
usuarios de las reas que operan con el SIAF (RPG-AS400) y el
Gerente de TI de la cooperativa ABACO, quienes han pedido que el
proceso de gestin de solicitudes de Requerimientos se automatice
para que facilite la tarea de elevar solicitudes al rea de TI, y
ser evaluadas por el Gerente del rea de sistemas, y se puedan
asignar tareas y recursos a dichas solicitudes. Se requiere
realizar un sistema que lleve el control de las solicitudes para
poder tener un histrico de solicitudes, aprobacin y asignacin de
recursos.
3.1.2 El porqu de la solicitud del proyecto
La solucin planteada es crear un Sistema de Gestin de
Requerimientos TI que permitir automatizar la atencin de los
requerimientos y/o cambios que los usuarios soliciten teniendo un
control ms adecuado para los requerimientos solicitados, evitndose
as confusin por los documentos que se presentan para que se pueda
llevar a cabo los procesos y soluciones de manera rpida y
eficiente. Se requiere tambin que el sistema lleve el control de
las solicitudes para poder tener un histrico de solicitudes,
aprobacin y asignacin de recursos para dichas solicitudes.
3.1.3 Evaluacin de la informacin deseada
Para el desarrollo de esta solucin se debe conocer el
procedimiento del registro de requerimientos, y el ciclo de vida
que cumple durante el proceso de gestin de Solicitud de
Requerimientos, identificar los recursos que realizaran dichas
tareas, as como los criterios que tiene el gerente TI para la
aprobacin o no aprobacin de las solicitudes.El software deber
mantener un registro de los requerimientos, identificando para cada
una de ellos sus tareas y actividades, y para cada actividad la
distribucin de los recursos que contempla: Formulario de
solicitudes. Reporte de solicitudes. Estado de Aprobaciones.
Reporte de los recursos vs solicitudes encargadas.
3.1.4 Situacin actual
Actualmente, el rea de TI no cuenta con un sistema adecuado para
poder atender a las reas de la cooperativa, implicando que los
responsables del rea, atiendan de manera individual como si fuera
un proceso fsico, basndose dicha atencin en documentos que los
usuarios presentan solicitando la atencin y aprobacin de cada
requerimiento por parte del rea tcnica o del rea de sistemas, segn
requiera el caso. Los procesos actuales para poder llevar a cabo la
gestin de Requerimientos, desde la solicitud hasta la asignacin de
recursos, son ineficientes debido a que hay mucha perdida de
informacin, por lo tanto la atencin de los requerimientos se vuelve
ms lenta y engorrosa, limitando as el nmero de requerimientos
atendidos y/o usuarios insatisfechos con la atencin, y por lo tanto
no cumplen con una gestin de alta calidad de recursos y tiempo.
3.1.5 Estructura de Divisin del Trabajo (EDT)
La EDT mostrada a continuacin est elaborada en un formato de
alto nivel para poder tener una visin general del alcance del
proyecto.
3.1.6 Conformacin 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 Sistema de Gestin de Requerimientos TI, estar
conformado solamente por dos personas cumpliendo los roles:
programador, Producto Owner, Cliente y Usuario final del sistema.
Uno de los miembros del equipo har las veces de programador y Scrum
Master. En este caso el rol de Scrum Master lo cumplir el gerente
del rea de TI.Por lo tanto, hay dos persona s disponible para
trabajar en el desarrollo del software. El tiempo que se dedicar al
mismo es una jornada de medio da, 20 horas a la semana
aproximadamente.
3.1.7 Estimacin del plazo de Entrega y Precio
En base al EDT se arma una tabla para obtener una primera
estimacin general del proyecto, y poder as determinar su duracin 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.
Los gastos que deben tenerse en cuenta es que el ambiente de
trabajo son las instalaciones de la Cooperativa ABACO ubicadas en
el distrito de San Isidro, lo cual significa que no se incurriran
en gastos de alquiler de local, consumos de energa elctrica e
internet, y equipos, se estima que el proyecto podra durar 6
meses.
3.1.8 Gestin de riesgo
Todos los proyectos, sin excepcin, tienen implcito algn tipo de
riesgo. Y steno tiene relacin algunacon el tamao del proyecto. La
administracin 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 segn su importancia.Los
criterios de puntuacin 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).Identificacin. Anlisis
cualitativo y cuantitativo del riesgo
Se ha definido la siguiente poltica para la seleccin de
estrategias:
Una vez que los riesgos han sido identificados, calculados y
priorizados, se concibe un plan de respuesta para dichos
riesgos.Plan de respuesta al riesgo:
3.1.9 Propuesta Comercial
Con toda la informacin recaudada y analizada hasta el momento se
elabora la propuesta comercial que se entrega a nuestro posible
futuro cliente. En resumen, el presupuesto arroj los siguientes
valores: Precio por programador (2) mensual: S/.4000. Precio total:
S/.24000.
1
