UNIVERSIDAD SAN MARTIN DE PORRES

FACULTAD DE INGENIERIA Y ARQUITECTURA

CALIDAD DE SOFTWARE
METODOLOGA GIL SCRUM

SCRUM

Tabla de Contenido
CAPTULO 1 : SCRUM.........................................................................................................3
1.

Introduccin.................................................................................................................3

2.

La Esencia de SCRUM................................................................................................4

3.

Elementos de SCRUM.................................................................................................6
3.1.

Roles.....................................................................................................................6

3.2.

Poda de Requerimientos.......................................................................................7

3.3.

Product Backlog....................................................................................................7

3.4.

Sprint.....................................................................................................................8

3.5.

Valores..................................................................................................................9

CAPTULO 2 : METODOLOGA...10
2. Proceso de Desarrollo....10
2.1.Introduccin.10
2.2.Proceso Iterativo e Incremental....10
2.3.Etapas del Proceso de Desarrollo.11
2.3.1.

Planificacin....11

2.3.2.

Anlisis....11

2.3.3.

Diseo..11

2.3.4.

Construccin y Pruebas11

2.3.5.

Implementacin...11

2.4. EDT Del Proceso de Desarrollo..12

2.5. Herramientas...12
2.5.1. Tcnicas de relevamiento.13
2.5.2.

Work Breakdown Structure (WBS).13

2.5.3.

Casos de uso13

2.5.4.

Diagrama de actividades..14

2.5.5.

Diagrama de Entidad Relacin (DER..14

2.5.6.

ScrumWorks14
1

SCRUM
2.5.7.

Burndown chart...15

2.5.8.

Clarion 5.5..15

3.1.

Planificacin Inicial16

3.1.1. Solicitud del proyecto.16

3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.

El porqu de la solicitud del proyecto.16

Evaluacin de la informacin deseada.16
Situacin actual17
Estructura de Divisin del Trabajo (EDT.17
Conformacin del equipo humano...18

3.1.7. Estimacin del plazo de entrega y precio.19

3.1.8. Gestin de Riesgo19
3.1.9. Propuesta comercial.21

SCRUM
Captulo 1 : 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.

SCRUM
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.

SCRUM
Revisin de las Iteraciones
En 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 Evolutivo
No 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-Organizacin
En 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.
Colaboracin
La 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.

SCRUM
3. Elementos de SCRUM
3.1. Roles
La 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.

SCRUM
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.

3.2. Poda de Requerimientos

La primera actividad es armar una lista exhaustiva de los requerimientos originales del sistema.
Luego se procede a ver qu requerimientos son realmente necesarios, 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.

3.3. Product Backlog

Con los requerimientos priorizados y podados armamos el Backlog de Producto. Este es una
forma de registrar y organizar el trabajo pendiente para el producto (actividades y
requerimientos).
Es un documento 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.
7

SCRUM
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.

3.4. Sprint
Un 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.

SCRUM
3.5. 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.

SCRUM
Captulo 2 : 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.
10

SCRUM
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

Planificacin
Objetivo: 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.
Anlisis
Objetivo: 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.
Diseo
Objetivo: 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
11

SCRUM
del software armado, gua de diseo, diseo de la infraestructura, y la planificacin
ajustada con la evolucin y avances obtenidos.
Construccin y Prueba
Objetivo: 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: Programacin y
desarrollo de todos
los componentes
y
funcionalidades. Implementacin de las estructuras de datos, y sus procedimientos,
elaboracin
de
documentacin tcnica y
ajustes
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.

Implementacin
Objetivo: 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 Desarrollo
Presentamos nuestro proceso de desarrollo a travs de una Estructura de Divisin del
Trabajo para verlo grficamente:

12

SCRUM

HERRAMIENTAS
Tcnicas de Relevamiento
Entrevistas con el cliente y los usuarios; revisin de registros, y observacin
Work Breakdown Structure WBS
Conocida 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 Uso
Son 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.

13

SCRUM
Diagrama de Actividades
Sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es
generar una especie de diagrama en el que se puede ver el flujo de actividades que tienen
lugar a lo largo del tiempo, as como las tareas concurrentes que pueden realizarse a la vez.
El diagrama de actividades sirve para representar el sistema desde otra perspectiva. Desde
un punto de vista conceptual, la actividad es alguna tarea que debe ser realizada. Por este
motivo, en un diagrama de actividades 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 Relacin
Un 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.
ScrumWorks
Permite 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 chart
En 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
14

SCRUM
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.5
Herramienta capaz de crear programas de 32 bits para Windows 9x, NT, 2000, y XP y
para la Internet / Intranet / Extranet desde un nico 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 de la productividad es 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

15

SCRUM

3. Proyecto trazabilidad
3.1 Planificacin Inicial
3.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:
16

SCRUM

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.

17

SCRUM

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.

18

SCRUM
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 ste
no
tiene relacin alguna
con 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.

19

SCRUM
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:

20

SCRUM
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.

21