UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN

FACULTAD DE INGENIERA

Escuela acadmico profesional de ingeniera en informtica y

sistemas

Desarrollo de software basado en metodologa SCRUM para la

implementacin de un sistema de un consultorio obsttrico

Curso: Ingeniera de Software II

Estudiantes:

Chipana Huarcusi, Jhon Kevin

Joaquin Ramirez, Giancarlo
Ordoo Musaja, Kilmer Romario
Choque Cuyo, ngel Salvador
Colque Condori, Brenda
Quinto Apaza, Yulisa
Tuyo Bernal, Fernando
Coillo Chambilla, Alex
Maquera Sacaca, Abel

DOCENTE: Ing. Gianfranco Mlaga Tejada

Ao: Cuarto

TACNA - PER
2017
Contenido

1. Introduccin ............................................................................................................................... 3

2. Descripcin General de la Metodologa .................................................................................. 3

2.1. Fundamentacin .................................................................................................................. 4
2.2. Valores de trabajo ............................................................................................................... 4

3. Personas y roles del proyecto. ................................................................................................ 5

4. ELEMENTOS .............................................................................................................................. 8
4.1. Sprint 8
4.2. Incremento ........................................................................................................................... 9
4.3. Sprint Backlog ..................................................................................................................... 9
4.4. Product Backlog ................................................................................................................ 10
4.5. Reunin de inicio de sprint ................................................................................................ 11
4.6. Seguimiento del Sprint ...................................................................................................... 11
4.7. Reunin de cierre de sprint y entrega del incremento. ..................................................... 12
4.8. Incremento funcional potencialmente entregable ............................................................. 13
4.9. Definicin de Hecho ........................................................................................................ 13
4.10. Variaciones con la metodologa Scrum ......................................................................... 14
4.11. Herramientas ................................................................................................................. 15
4.11.1. Grafica Burn Up ..................................................................................................................... 15
4.11.2. Grafica Burn Down ................................................................................................................ 16

5. Aplicacin en el proyecto ....................................................................................................... 16

5.1. Product Backlog ................................................................................................................ 16
5.2. Grafica Burn Up ................................................................................................................. 18
5.3. Iteracin 1 .......................................................................................................................... 19
5.3.1. Sprint Backlog ........................................................................................................................ 20
5.3.2. Burt Down Chart .................................................................................................................... 21
5.3.3. Seguimiento del Sprint .......................................................................................................... 22
5.4. Iteracin 2 usuarios ........................................................................................................... 24

6. Requisitos funcionales y no funcionales ............................................................................. 24

6.1. Para el usuario .................................................................................................................. 24
6.2. Requisitos no funcionales ................................................................................................. 25

7. Conclusiones ........................................................................................................................... 25
 Descripcin de la metodologa de trabajo

1. Introduccin

Se describe la implementacin de la metodologa de trabajo basada

en Scrum con el objetivo de disear un modelo de base de datos y desarrollar
un modelo de software para las reas de atencin, inventario y servicio de
administracin de la clnica Siempre mujer con el propsito de mejorar y
agilizar sus procesos principales de negocio

Incluye junto con la descripcin de este ciclo de vida iterativo e

incremental para el proyecto, los artefactos o documentos con los que se
gestionan las tareas de adquisicin y suministro: requisitos, monitorizacin y
seguimiento del avance, as como las responsabilidades y compromisos de
los participantes en el proyecto.

2. Descripcin General de la Metodologa

El desarrollo se realiza de forma iterativa e incremental, trabajando con

transparencia inspeccin y adaptacin al cambio con un equipo auto
organizado basado la metodologa gil, obteniendo como resultado una
versin del software con nuevas prestaciones listas para ser usadas.

Se trabaja siguiendo el manifiesto del desarrollo gil:

Individuos e interacciones priman sobre procesos y herramientas

Software funcionando sobre documentacin extensiva

Colaboracin con el cliente sobre negociacin contractual

Respuesta ante el cambio sobre seguir un plan

2.1. Fundamentacin

El principal valor que otorga la metodologa Scrum es que permite que

la implementacin del proyecto sea basada en entregas parciales y regulares
del producto final, los cuales requieren rapidez en los resultados. De manera
particular, se opt por aplicar esta metodologa en el proyecto por las razones
expuestas a continuacin:

Sistema modular. Las caractersticas del sistema permiten desarrollar

una base funcional mnima y sobre ella ir incrementando las
funcionalidades o modificando el comportamiento o apariencia de las
ya implementadas.

Entregas frecuentes y continuas al cliente de los mdulos terminados,

de forma que puede disponer de una funcionalidad bsica en un
tiempo mnimo y a partir de ah un incremento y mejora continua del
sistema.

Para el cliente resulta difcil precisar la dimensin completa del

sistema, y su crecimiento variar (Previsible inestabilidad de requisitos).

2.2. Valores de trabajo

Los valores que deben ser practicados por todos los miembros
involucrados en el desarrollo y que hacen posible que la metodologa
Scrum tenga xito son:

o Autonoma del equipo.

o Respeto en el equipo.

o Responsabilidad y auto-disciplina.

o Enfoque en la tarea.
3. Personas y roles del proyecto.

El equipo se focaliza en construir software de calidad. La gestin de

un proyecto Scrum se centra en definir cules son las caractersticas que
debe tener el producto a construir (qu construir, qu no y en qu orden) y
en vencer cualquier obstculo que pudiera entorpecer la tarea del equipo de
desarrollo.

El equipo Scrum est formado por los siguientes roles:

EL SCRUMMASTER: Jhon Kevin Chipana Huarcusi

Representa al lder del proyecto y es el encargado de asegurarse que

el proyecto se lleve a cabo de acuerdo con las prcticas, valores y reglas de
Scrum. Gestiona la reduccin de impedimentos del proyecto y trabaja con el
Product Owner para la entrega de requerimientos.

EL PRODUCT OWNER: El cliente

Representante de los accionistas y clientes que usan el software. Se

focaliza en la parte de negocio, traslada la visin del proyecto al equipo,
formaliza las prestaciones en funcionalidades a incorporar en el Product
Backlog, en el caso particular de este proyecto es la duea de la empresa
quien representa este rol.

TEAM
Equipo auto organizado encargado tanto del anlisis, diseo,
desarrollo, pruebas y documentacin de manera conjunta llevando a cabo las
historias a las que se comprometen al inicio de cada sprint. Dentro del equipo
de trabajo est:
El analista: Jhon Chipana, Fernando Tuyo, Alex Coillo y Brenda Colque

El analista es alguien que es responsable de entender las necesidades

del cliente, y asegurarse de que la solucin que est siendo desarrollada se
ajusta a esas necesidades.

El arquitecto de Software: Kilmer Ordoo, Alex Coillo, Yulisa Quinto y Abel

Maquera

El papel del arquitecto de software es traducir los requisitos, tal como

se define por el analista, en una solucin tcnica. l puede crear un diseo
tcnico, o simplemente algunos bocetos a mano alzada, de cmo el sistema
va a estar estructurado.

El arquitecto del sistema: Jhon Chipana, Yulisa Quinto y Kilmer Ordoo

Al igual que el arquitecto de software, el Arquitecto del Sistema es

responsable de pensar el sistema antes de Construirlo. As como el arquitecto
de software es responsable para el software, un arquitecto del sistema es
responsable del hardware.

El desarrollador del software: Alex Coillo, Brenda Colque, Angel Choque y

Fernando Tuyo

El desarrollo efectivo de una aplicacin es hecho por los

desarrolladores del equipo. Pero un desarrollador tiene ms
responsabilidades que solo escribir cdigo. l es a menudo responsable de
hacer el seguimiento de su propio progreso, e informar al jefe de proyecto de
los problemas a los que se enfrenta. l es tambin quien implementa las
ideas del arquitecto, y como tal, puede tener que discutir las (in) posibilidades
de la implementacin con el arquitecto.

El jefe de desarrolladores: Fernando Tuyo

 Un desarrollador lder, que tiene las mismas responsabilidades que los
otros desarrolladores, pero tambin tiene aadidas algunas ms. Un
desarrollador lder debe entrenar a los otros desarrolladores, y ayudarles a
resolver los problemas que puedan enfrentar

El diseador grfico: Abel Maquera y Angel Choque

"Lo de dentro es lo que cuenta", es tan cierto, como que tambin la

percepcin de los usuarios depende mucho de la mirada y la sensacin que
le produce una aplicacin o sitio Web. No importa lo buena que la aplicacin
sea, si la interfaz es inconsistente. Se sentir menos robusto

El tester: Giancarlo Joaquin Ramirez y Kilmer Ordoo

Las pruebas son una parte importante para asegurar que el software funciona
de la manera que debera. El papel de tester se realiza a menudo por los
desarrolladores para los aspectos tcnicos y los usuarios para los aspectos
funcionales.

El Capacitador: Giancarlo Joaqun y Jhon Chipana

Cuando un proyecto se haya completado, los usuarios pueden

necesitar ser capacitados, en particular si en el proyecto se ha desarrollado
una aplicacin.
 Tabla 1. Cuadro de roles

4. ELEMENTOS

4.1. Sprint

Cada una de las iteraciones del ciclo de vida iterativo Scrum. La

duracin de cada sprint varia de 1 a 4 semanas.
 El primer Sprint supone una mayor demora al ser el prototipo
por el cual partir, los dems sern de actualizacin dependiendo de
los requisitos y cambios sugeridos por el Product Owner.

4.2. Incremento

Parte o subsistema que se produce en un sprint, ajustando la

funcionalidad ya construida y se entrega al gestor del producto
completamente terminado y operativo.

4.3. Sprint Backlog

Las funcionalidades tomadas del backlog se vuelven el

compromiso de desarrollo del equipo a entregar al final del Sprint, no
puede incluir ms tareas si estas atentan contra el alcance del sprint.

Se indica el tiempo de trabajo que se estima, o el que an falta

para terminar; es til porque divide el proyecto en tareas de tamao
adecuado, Se registrar lo correspondiente a cada incremento en el
sprint.

Responsabilidades del gestor de producto

Presencia en las reuniones en las que el equipo elabora el Sprint

Backlog. Resolucin de dudas sobre las historias de usuario que se
descomponen en el Sprint Backlog.
Responsabilidades del Scrum Manager

Supervisin y asesora en la elaboracin el Sprint Backlog.

Responsabilidades del equipo tcnico

Elaboracin del Sprint Backlog.

 Resolucin de dudas o comunicacin de sugerencias sobre las
historias de usuario con el gestor del producto.

4.4. Product Backlog

Conjunto de todos los requisitos de proyecto, el cual contiene

descripciones genricas de funcionalidades deseables. Representa
el qu va a ser construido en su totalidad. Es abierto y solo puede ser
modificado por el product owner. y sus elementos estn estimados
(mediante su coste de desarrollo) y priorizados.

Podemos encontrar las funcionalidades, mejoras, tecnologa y

correccin de errores que se incorporaran mediante las iteraciones del
desarrollo, cabe mencionar que no es un documento de
requerimientos, sino una herramienta de referencia para el equipo de
trabajo.

El product backlog nunca se da por completado y est en

continuo crecimiento y evolucin

Responsabilidades del gestor de producto

Registrar en la lista del product backlog de las historias de

usuario que definen el sistema.
Mantenimiento actualizado del product backlog en todo
momento durante la ejecucin del proyecto.
Orden en el que desea quiere recibir terminada cada historia
de usuario.
Incorporacin/eliminacin/modificaciones de las historias o de
su orden de prioridad.

Responsabilidades del Scrum Manager

Supervisin del product backlog, y comunicacin con el gestor

 del producto para pedirle aclaracin de las dudas que pueda
tener, o asesorarle para la subsanacin de las deficiencias que
observe.
Responsabilidades del equipo tcnico

Conocimiento y comprensin actualizado del product backlog

Resolucin de dudas o comunicacin de sugerencias con el
Scrum Manager

4.5. Reunin de inicio de sprint

Reunin para determinar las funcionalidades o historias de

usuario que se van a incluir en el prximo incremento. Tomando como
punto de partida las necesidades del cliente, se genera el Sprint
Backlog.

Responsabilidades del gestor de producto

Asistencia a la reunin.
Exposicin y explicacin de las historias que necesita para la
prxima iteracin y posibles restricciones de fechas que pudiera
tener.

Responsabilidades del Scrum Manager

Moderacin de la reunin

Responsabilidades del equipo tcnico

Auto-asignacin del trabajo.

4.6. Seguimiento del Sprint

 Puesta en comn del equipo con presencia del Scrum Manager
de duracin de entre 30 y 50 minutos con un intervalo de 2 a 7 das
para medir el avance del proyecto y documentar los cambios que se
actualizarn.

Los integrantes del equipo dicen las tareas en las que estn
trabajando, si se han encontrado o prevn encontrarse con algn
impedimento, para poder actualizar sobre el Sprint Backlog las tareas
realizadas o los tiempos de trabajo que les restan.

Responsabilidades del Scrum Manager

Supervisin de la reunin y gestin para la solucin de las

necesidades o impedimentos detectados por el equipo.
Actualizacin del avance del proyecto

Responsabilidades del equipo tcnico

Comunicacin individual del trabajo realizado y el previsto para el

da actual.
Notificacin de necesidades o impedimentos previstos u ocurridos
para realizar las tareas asignadas.

,
4.7. Reunin de cierre de sprint y entrega del incremento.

Reunin donde se realiza la revisin de los avances generados,

el equipo de trabajo prueba y entrega el incremento al gestor del
producto. De tiempo acotado entre 2 y 4 horas.

Responsabilidades del gestor de producto

Asistencia a la reunin.
Recepcin del producto o presentacin de reparos
 .
Responsabilidades del Scrum Manager

Moderacin de la reunin

Responsabilidades del equipo tcnico

Presentacin del incremento.

4.8. Incremento funcional potencialmente entregable

El resultado de cada Sprint debe ser un incremento funcional

potencialmente entregable. Incremento funcional; porque es una
caracterstica funcional nueva (o modificada) de un producto que est
siendo construido de manera evolutiva. El producto crece con cada
Sprint.

Potencialmente entregable; porque cada una de estas

caractersticas se encuentra lo suficientemente validada y verificada
como para poder ser entregada al usuario si as el negocio lo permite
o el cliente lo desea.

4.9. Definicin de Hecho

Los integrantes del equipo deben comprender lo que significa

que el trabajo est completado. La finalidad de cada Sprint es entregar
Incrementos operables altamente utilizables, que se ajustan a la
definicin de Hecho actual del Equipo Scrum. Cada Incremento es
una suma de todas las actividades presentadas en los Incrementos
anteriores y es iterativamente probado, asegurando que todos los
 incrementos funcionen en conjunto, Si un elemento no cumple con la
definicin de hecho no ser parte del incremento entregable.

4.10. Variaciones con la metodologa Scrum

La aplicacin de Scrum en el proyecto tuvo que ser

personalizada para el correcto desarrollo y aplicacin de la misma,
esto es debido a que, por la naturaleza del proyecto y sus integrantes,
los elementos han sido diferentes a los de una situacin ideal para la
aplicacin de la metodologa

Tabla 2. Comparacin entre el mtodo Scrum y el utilizado

Metodologa Scrum Metodologa aplicada

Se realiza el seguimiento diario mediante El seguimiento se hace en reuniones con un
reuniones diarias de 15 minutos como intervalo de 2 a 7 das, con duracin de 30 a
mximo 50 minutos por la coordinacin de horarios del
equipo de desarrollo
El equipo tendr una velocidad y se Fue muy complicado medir el trabajo en horas
manejar las historias en base a ese debido a que el personal de desarrollo est
nmero, cada tarea se estima en horas acostumbrado a trabajar bajo objetivos y se
decidi trabajar con la estimacin de esfuerzo
(Planning Poker) de las funcionalidades y
velocidad del equipo

El Product Owner prioriza las Las prioridades no fueron definidas por el

funcionalidades mediante su retorno de Product Owner, se dio por el Scrum Master y
inversin, para un reparto correcto de el equipo de desarrollo siguiendo las etapas
funcionalidades en los Sprints del desarrollo del software

Cada miembro del equipo inspecciona el La inspeccin es realizada por el Scrum

trabajo que el resto est realizando durante Master para ahorrar tiempo en los
los seguimientos diarios seguimientos de los Sprints
Se mencionan las tareas del Sprint Backlog El Scrum Master lidera el reparto de tareas
y el equipo de desarrollo se autogestiona entre el equipo de desarrollo mediante sus
en la eleccin de posibles funcionalidades roles y disposiciones.
a realizar

Cada funcionalidad se debe llevar a la Las funcionalidades no se documentan como

forma de historia de usuario y ser historias de usuario, son estimadas y
documentada priorizadas en el Product Backlog

Una funcionalidad se descompone en Las funcionalidades no se descomponen, se

tareas y son repartidas para el desarrollo trabajan como una sola y son estimadas en
del Sprint Backlog tiempo por el equipo de desarrollo

El reparto de tareas se da en el Se da reparto de funcionalidades, al inicio y

planeamiento de cada Sprint durante las reuniones de seguimiento del
Sprint para evitar desperdicios de tiempo

La participacin completa del Product Owner

El Product Owner participa en todas las no es posible, por lo tanto, mediante una serie
reuniones del Scrum de entrevistas se tiene comunicacin con l.

Cada miembro del equipo actualiza el La actualizacin de la grfica Burn Down es

sprint con lo realizado en el da anterior y lo tarea del Scrum Master, quien lo realizara a
que tiene previsto realizar hoy, as como partir del dialogo de la reunin de seguimiento
tambin si ya termino alguna de las tareas
del Sprint
y actualiza el esfuerzo en las que todava
tiene pendiente en la Grafica Burn Down

4.11. Herramientas

4.11.1. Grafica Burn Up

Herramienta de planificacin propia del Product Owner,

que presenta visualmente la evolucin previsible del
producto.

Proyecta en el tiempo la construccin del producto,

en base a la velocidad del equipo.

La proyeccin se realiza sobre un diagrama

cartesiano que representa en el eje de ordenadas el
esfuerzo estimado para construir las diferentes historias
 de la pila del producto, y en el de las abscisas el tiempo
medido en Sprints.

Se traza en el grfico la lnea que representa el

ritmo de avance previsto segn la velocidad media del
equipo (50 puntos) y se traza los ritmos de avance con
una previsin pesimista y otra optimista, estableciendo
un margen segn el criterio del equipo (+- 25%).

4.11.2. Grafica Burn Down

Grafico que actualiza el equipo en las reuniones

de seguimiento del sprint, para monitorizar el ritmo de
avance, y detectar de forma temprana posibles
desviaciones sobre la previsin que pudieran
comprometer la entrega al final de sprint, ser
actualizado por el Scrum Master

5. Aplicacin en el proyecto

5.1. Product Backlog

Tabla 3. Product Backlog en el proyecto

REQUERIMIENTO PRIORI ESTIMA RESPONSABLE OBS. SPRINT

DAD CION
Establecer los 1 1 Jhon 1
roles del proyecto
Anlisis de 1 3 Jhon, Fernando, 1
requerimientos Alex
Documentacin 1 3 Giancarlo, 1
del proyecto Kilmer, Angel
Elaboracin de 1 3 Kilmer 1
diagrama de
Casos de Uso
Diseo del 1 8 Yulisa, Brenda, 1
diagrama Alex,
relacional Fernando,Jhon
Entrevista en 1 1 Jhon, Yulisa, 1
clnica Alex,Brenda
Diseo de 2 8 Giancarlo, Jhon, 1
formularios Jhan
Diseo de la base 2 5 Angel, Brenda, Demora por 1
de Datos Alex, Kilmer, la
Jhon, Fernando complejidad
Configuracin de 2 5 Alex, Brenda, 1
conexin a la BD Fernando, Yulisa
Registro de 3 3 Fernando y 1
paciente Angel
Documentacin 3 5 ngel 1
(metodologa de
trabajo)
Registro de 3 3 Fernando y 1
atenciones Angel
Actualizacin y 3 5
eliminacin de
datos de paciente
Reporte de 3 3
pacientes
Reportes de 4 5
atenciones
Reserva de citas 4 5
Reporte de citas 4 3
Inventario de 4 8
insumos
Registro de 5 5
insumos en
atenciones
Administracin de 5 3
usuarios
Autentificacin de 5 3
usuarios (login)
Diseo de Interfaz 6 5
de Usuario
Consultar 6 5
estadsticas de
pacientes
Consultar 6 5
estadsticas de
atenciones
Mejora de diseo 7 3
grafico
Prueba de errores 7 5
Registro de control 7 5
de calidad
Manual de 8 8
instalacin
Manual de usuario 8 5

5.2. Grafica Burn Up

Tabla 4. Tabla Burn Up

V. V.
Iteraciones Pesimista V. Prevista Optimista V. Real
Sprint 0 0 0 0 0
Reunin 1 4.5 6 7.5 3
Reunin 2 9 12 15 7
Reunin 3 13.5 18 22.5 11
Reunin 4 18 24 30 23
Reunin 5 24 32 40 28
Reunin 6 28.5 38 47.5 35
Reunin 7 31.5 42 52.5 43
Reunin 8 36 48 60 48
Sprint 1 36 48 60 48
Sprint 2 68.25 91 113.75 -
Sprint 3 100.5 134 167.5 -
 Burn Up Chart
180

160

140
Estimacion de trabakp

120

100

80

60

40

20

0
Sprint 0 R1 R2 R3 R4 R5 R6 R7 R8 Sprint 1Sprint 2Sprint 3
Iteraciones

V. Pesimista V. Prevista V. Optimista V. Real

Figura 1. Burn Up Chart

5.3. Iteracin 1

Sprint: 1
Duracin: 4 Semanas
Inicio: 24 abril 2017

Durante la primera iteracin del proyecto primordialmente se

busc el establecer una idea de desarrollo, dotarla de un contexto y
establecer un esquema general del sistema, es decir, en general,
alcanzar un pequeo prototipo con funciones bsicas. Como equipo,
esta iteracin sirvi para acoplarse a las prcticas de Scrum y en
general a comprender el proceso de desarrollo de un sistema de
atenciones.

Se estableci la velocidad del equipo como 50 en base a los

requerimientos aceptados para el primer Sprint

5.3.1. Sprint Backlog

Tabla 5. Sprint Backlog en el 1er Sprint

REQUERIMIENTO RESPONSABLE ESTADO ESTIMA OBSERVA

CION CIONES
Establecer los roles Jhon Cumplido 1
del proyecto
Anlisis de Jhon, Fernando, Cumplido 3
requerimientos Alex
Documentacin del Giancarlo, Cumplido 3
proyecto Capitulo 1 Kilmer, Angel
y2
Elaboracin de Kilmer Cumplido 3
diagrama de Casos
de Uso
Diseo del diagrama Angel, Yulisa, Cumplido 8
relacional Brenda, Alex,
Fernando
Entrevista en clnica Jhon, Yulisa, Cumplido 8
Alex,Brenda
Diseo de Giancarlo, Jhon, Cumplido 1
formularios Jhan
Diseo de la base Angel, Yulisa, Cumplido 8
de Datos Brenda, Alex,
Kilmer, Jhon,
Fernando
Configuracin de la Alex, Brenda, Cumplido 5
conexin a la Base Fernando, Yulisa
de Datos
Registro de paciente Fernando Cumplido 3
Documentacin Angel Cumplido 5
(metodologa de
trabajo)
Registro de atencin Fernando y Angel Cumplido 3
5.3.2. Burt Down Chart

Tabla 6.
Estimacin Estimacin
Fechas Real Prevista
24-abr 48 48.00
25-abr 47 46.29
26-abr 47 44.57
27-abr 46 42.86
28-abr 46 41.14
29-abr 45 39.43
30-abr 44 37.72
01-may 44 36.00
02-may 43 34.29
03-may 42 32.57
04-may 42 30.86
05-may 41 29.15
06-may 40 27.43
07-may 39 25.72
08-may 39 24.00
09-may 38 22.29
10-may 37 20.58
11-may 25 18.86
12-may 23 17.15
13-may 22 15.43
14-may 20 13.72
15-may 13 12.01
16-may 11 10.29
17-may 9 8.58
18-may 7 6.86
19-may 5 5.15
20-may 3 3.44
21-may 2 1.72
22-may 0 0
 Burn Down Chart
50
45
40
Esfuerzo Pendiente

35
30
25
20
15
10
5
0

06-may.

16-may.
01-may.
02-may.
03-may.
04-may.
05-may.

07-may.
08-may.
09-may.
10-may.
11-may.
12-may.
13-may.
14-may.
15-may.

17-may.
18-may.
19-may.
20-may.
21-may.
22-may.
24-abr.
25-abr.

27-abr.
28-abr.
29-abr.
30-abr.
26-abr.

Fecha

Real Previsto

Figura 2

5.3.3. Seguimiento del Sprint

1era Reunin (25 de abril):

o Establecer el reglamento: Todos tuvimos una participacin

directa dando nuevas ideas y aprobando cada una de ellas.

o Requerimientos del Software: El lder en una primera entrevista

con el cliente nos mostr a grandes rasgos algunos
requerimientos del software del cual empezaramos a desarrollar
el software.

o Identificar los roles para cada miembro: Definimos los grupos de

trabajo y repartir roles, para as desarrollar el software.

2da Reunin (29 de abril):

o Luego de la primera entrevista, el lder nos plante los
primeros requerimientos oficiales y el procedimiento que
bamos a seguir para desarrollar el software.

3era Reunin (5 de mayo):

o Se present y aprob las interfaces al cliente

o Conclusin de los Caso de Uso: Un grupo de trabajo
presento la conclusin de los Caso de Uso.

4ta Reunin (10 de mayo):

o Segunda entrevista: Los requerimientos aumentaron y se

estableci lo nuevo que se agregara en el software.
o Base de Datos: Se organiz al grupo de trabajo encargado
de realizar la arquitectura de la base de datos. Prxima
entrega en la siguiente reunin.

5ta Reunin (11 de mayo):

o Base de datos: El grupo encargado no pudo terminar la

estructura de la BD, por la complejidad del sistema, as que
se le agrego ms tiempo para la siguiente reunin.
o Implementacin de la aplicacin: Se dispuso del grupo de
trabajo para realizar el primero prototipo ejecutable. Con
plazo de conclusin para la siguiente reunin.

6ta Reunin (15 de mayo):

 o Se acab de desarrollar la Base de datos
o Se termin el desarrollo del entorno grafico del registro de
pacientes y registro de atencin

7ma Reunin (19 de mayo):

o Se acab la aplicacin en Netbeans y la conexin con la

base de datos
o Se organiz un grupo para el detallado de la Interfaz del
usuario
o Se acabar de detallar la documentacin escrita de la
metodologa de aplicacin del proyecto

5.4. Iteracin 2 usuarios

6. Requisitos funcionales y no funcionales

6.1. Para el usuario

- Verificar la autentificacin de ingreso al sistema por parte de los

autorizados.

- El sistema debe permitir el registro de nuevos pacientes.

- El sistema debe ser capaz de permitir a los usuarios poder actualizar

y eliminar informacin concerniente a los pacientes albergados en la
base de datos.

- El sistema debe ser capaz de obtener la informacin de cualquier

paciente.
 - El sistema deber permitir generar reportes diarios, mensuales y
anuales sobre las atenciones.

- El sistema debe permitir reservar citas prximas de los pacientes.

- El sistema debe mostrar las citas pendientes de todos los pacientes.

- El sistema debe poder mostrar reportes por cada tipo de atencin

(Planificacin Familiar, Papanicolau, Otros).

- El sistema debe contar con un inventario de insumos.

- El sistema debe ser capaz de descontar insumos utilizados por cada

atencin al inventario.

6.2. Requisitos no funcionales

- El sistema deber funcionar correctamente en los sistemas

operativos de Windows xp, windows 7, Windows 8.1.

- Se debe disponer de mouse y teclado.

7. Conclusiones
Hablando propiamente del desempeo de Scrum como metodologa para el
desarrollo de atenciones, podemos decir que:

Result ser una gran herramienta para el desarrollo del producto ya que
nos ayud totalmente a estructurar el proyecto con metas a corto y largo
plazo.
Sus herramientas como los Sprints, reuniones y backlogs, probaron ser
una eficaz manera de hacer un correcto seguimiento del proyecto y
tener la capacidad en todo momento de saber, en qu punto del
desarrollo estamos.