TACH

INGENIERIA DE SISTEMAS
ESCUELA MILITAR DE INGENIERÍA

Mcal. Antonio José de Sucre
BOLIVIA
Modalidad: trabajo final

presentado como requisito parcial
para la aprobación de la
asignatura de Ingeniería Web
ESTUDIANTES: Erika Sossa Poma

Jonathan Mamani Bueno
Ramiro Cuevas Choque
SEMESTRE: Octavo
La Paz - Bolivia
2018
Índice
Capítulo 1 Generalidades ................................................................................................................ 1

1.1. Introducción .................................................................................................................... 2
1.2. Antecedentes ........................................................................................................................ 3
1.3. Planteamiento Del Problema................................................................................................ 4
1.3.1. Problema Principal. ....................................................................................................... 5
1.3.2. Problema Secundarios ................................................................................................... 5
1.4. Objetivos .............................................................................................................................. 5
1.4.1. Objetivo General ........................................................................................................... 5
1.4.2. Objetivos Específicos.................................................................................................... 6
1.5. Alcances ............................................................................................................................... 6
1.5.1. Alcance Temático ......................................................................................................... 6
1.5.2. Alcance Geográfico ...................................................................................................... 6
1.5.3. Alcance Temporal ......................................................................................................... 6
1.5.4. Alcance Institucional .................................................................................................... 6
1.6. Limites ................................................................................................................................. 7
1.7. Justificación ......................................................................................................................... 7
1.7.1. Justificación Tecnológica.............................................................................................. 7
1.7.2. Justificación Institucional ............................................................................................. 7
1.7.3. Justificación Económica ............................................................................................... 8
Capítulo 2 Marco Teórico ............................................................................................................... 9
2.1 Ingeniería de Software ........................................................................................................ 10
2.1.1 El Arte de la Ingeniería de Software ............................................................................ 10
2.1.2 Definición de Ingeniería de Software .......................................................................... 10
2.1.3 El Producto y el Proceso de la Ingeniería de Software. ............................................... 11
2.1.3.1 El Producto................................................................................................................ 11
2.1.3.2 El Proceso ................................................................................................................. 12
2.1.4 Modelos de Desarrollo del Software............................................................................ 13
2.4 Metodología SCRUM ......................................................................................................... 14
2.4.1 Forma de Trabajo ......................................................................................................... 14
2.4.1.1. Características .......................................................................................................... 15
2.4.1.2. Principios ................................................................................................................. 16
2.4.1.3. Elementos de SCRUM ............................................................................................. 16
2.4.1.4. Roles del SCRUM.................................................................................................... 17
2.4.1.5. Reunión de Planificación del Sprint. ....................................................................... 18
2.4.1.6. Documentos ............................................................................................................. 18
2.4.2. Proceso de Desarrollo de la Metodología SCRUM. ................................................... 19
2.4.2.1. Modelo de Desarrollo del Trabajo. .......................................................................... 19
2.4.3 Fases de la Metodología SCRUM................................................................................ 23
2.4.3.1 Pre-juego ................................................................................................................... 23
2.4.3.2 Juego ......................................................................................................................... 23
2.4.3.3 Post-juego ................................................................................................................. 23
ii
2.4.3.4 Pasos de cada fase ..................................................................................................... 24
2.5 Herramientas Case .............................................................................................................. 28
2.5.1 Historia......................................................................................................................... 28
2.5.2. Tecnología Case .......................................................................................................... 29
2.5.3 Componentes de una Herramienta Case ...................................................................... 30
2.5.4 Estructura General de una Herramienta Case ............................................................. 30
2.5.5 Características De Una Case ........................................................................................ 31
2.5.6 Herramienta Case: Enterprise Architect ...................................................................... 33
2.5.6.2 Interfaz de usuario intuitiva ...................................................................................... 33
2.5.6.3 Documentación flexible y comprensible. ................................................................. 33
2.5.6.4 Ingeniería de código directa e Inversa ...................................................................... 34
2.5.6.5 Modelado de base de datos ....................................................................................... 35
2.5.7 Herramienta Case: Smartsheet ..................................................................................... 35
2.5.8 Herramienta Case: ScrumDo ....................................................................................... 37
2.5.8.1 Características ............................................................Error! Bookmark not defined.
Capítulo 3 Analisis de Factibilidad ............................................................................................... 38
3.1. Factibilidad Operativa ........................................................................................................ 39
3.2. Factibilidad Técnica. .......................................................................................................... 40
3.2.1. Hardware ..................................................................................................................... 40
3.2.1.1. Requerimientos de Hardware de desarrollo ............................................................. 40
3.2.1.2. Requerimientos de Hardware del Usuario. .............................................................. 41
3.2.1.3. Requerimientos de Hardware Del Servidor ............................................................. 42
3.2.2. Software ...................................................................................................................... 42
3.2.2.1. Requerimientos de Software de Desarrollo. ............................................................ 43
3.2.2.2. Requerimientos de Software del Usuario. ............................................................... 43
3.2.2.3. Requerimientos del Software del Servidor. ............................................................. 44
3.3. Factibilidad Económica. .................................................................................................... 44
3.3.1. Hardware ..................................................................................................................... 44
3.3.1.1. Requerimientos de Hardware de desarrollo ............................................................. 45
3.3.1.2. Requerimientos de Hardware del Usuario. .............................................................. 46
3.3.2. Software ...................................................................................................................... 46
3.3.2.1. Requerimientos de Software de Desarrollo. ............................................................ 47
3.3.2.2. Requerimientos de Software del Usuario. ............................................................... 47
Capítulo 4 Plan de Desarrollo de Software ................................................................................... 49
4.1 Plan de Desarrollo de Software en Base a la Metodología SCRUM .................................. 50
Pre- juego .................................................................................................................................. 53
4.2. Concepción ........................................................................................................................ 53
4.2.1. Identificación de procesos actuales. ............................................................................ 53
4.2.1.1. Proceso de recepción del Paciente. .......................................................................... 53
4.2.1.2. Ingreso del Paciente. ................................................................................................ 53
4.2.1.3. Consulta médica. ...................................................................................................... 53
4.2.1.4. Fin de Consulta en Recepción.................................................................................. 54
4.3. Indagación. ......................................................................................................................... 54
4.3.1. Lista de Involucrados. ................................................................................................. 54
iii
4.4. Elaboración. ....................................................................................................................... 55
4.4.1. Identificación de Actores en el Sistema. ..................................................................... 55
4.4.2. Tabla de Requerimientos. ........................................................................................... 57
4.4.2.1. Requerimientos Funcionales. ................................................................................... 57
4.4.2.2. Requerimientos No Funcionales. ............................................................................. 60
4.5. Product Backlog ................................................................................................................. 61
iv
Capítulo 1
Generalidades
1
1.1. Introducción
Hoy en día las empresas e instituciones manejan cantidades de información

exorbitantes, y en el ámbito de salud los hospitales, clínicas, centros de salud, etc. no
se quedan atrás. Estos interactúan con una gran cantidad de personas diariamente,
entre personal, doctores y pacientes. La seguridad y legitimidad de esta información
es esencial en cualquiera de estos establecimientos para lo cual hoy en día es
imprescindible que cuenten con servicios informáticos.
Es así que la tecnología apoya al ser humano al momento de satisfacer necesidades

propias o laborales tanto así que, en establecimientos de salud, una de las mejoras
que sean incorporado para el progreso del mismo como la posibilidad de reducir el
esfuerzo en el trabajo de las enfermeras o recepcionistas es el pasar de una actividad
manual como lo era, el programar citas médicas para un paciente que así lo solicite
(esta actividad requería de un llenado de información personal de pacientes en una
agenda y alguna información adicional detallada para así poder armar un tipo de
historial clínico básico), a tener la oportunidad de que los mismos usuarios puedan
realizar esta operación desde sus propios hogares sin tener que perder tiempos en
esperas para consultas o para obtener información.
Si una persona presenta síntomas de alguna enfermedad, o aqueja de dolores lo que

generalmente hace es acudir a algún centro de salud o clínica, en el cual reciba
atención médica especializada.
En la actualidad lo que hacen los pacientes para poder recibir atención médica, es ir a
los centros de salud y esperar a ser atendidos conforme van llegando a la fila, lo que
ocasión que los pacientes en muchos casos tengan que esperar un tiempo mayor al
que fue planificado, lo cual hace notar la importancia de que en estos centros de salud
o clínicas cuenten con un sistema de citas médicas, para así poder establecer tiempos
específicos de atención ya programados a través de las citas médicas .
2
1.2. Antecedentes
De acuerdo con lo investigado se pudo encontrar los siguientes antecedentes de

proyectos similares realizados:
El Tema:
“Desarrollo de un sistema web de control de citas, para un hospital del día”.
Desarrollado por: Marcelo Alejandro Aguilera Dagnino en el año: 2013. Técnica por
Objetivos: El presente trabajo de investigación se lo realizo en Quito para un hospital
el cual cuenta con un sistema de atención a los pacientes.
La historia clínica es el documento fundamental de una consulta. Además, tiene gran
importancia desde un punto de vista legal. Por todo ello resulta fácil comprender la
importancia que tiene el disponer de una buena historia clínica, entendiendo por
"buena" una historia clínica en la que la información sea lo más clara posible y lo más
accesible posible. Gracias a los datos informatizados de Admisión, podremos tener la
relación entre número de historia clínica y nombre y apellidos del paciente por el
Fichero Maestro de Pacientes. Con ello conseguimos la 'localización cruzada de la
historia clínica por apellidos y nombre y número de historia clínica', que suelen pedir
las normas de acreditación hospitalaria. La diferencia principal con respecto al
proyecto que planteamos es que el proyecto está realizado en .NET así como está
elaborado en base a la metodología ágil Extreme Programming.
El Tema:
“Sistema de Información Hospitalaria Caso: Centro Médico Nacional 20 de noviembre”
desarrollado por: Jesús Sánchez en el Año: 1995 Técnica por Objetivos: Jesús
Sánchez conjuntamente con un equipo de informáticos han desarrollado un sistema
integral en esa institución. su sistema tiene un ambiente gráfico y se conforma de 40
módulos. El proyecto era incorporar directamente las imágenes obtenidas del
tomógrafo computarizado al sistema, como parte de la base de datos que el médico
puede consultar y trabajar para el diagnóstico y tratamiento del paciente. También se
3
podíamos utilizar un scaner como segunda opción. El propósito era integrar las
imágenes al sistema con la interface. La diferencia con respecto al proyecto planteado
es que además de establecer consultas el sistema se centraba en poder colaborar el
diagnóstico y el tratamiento que se daría a paciente.
El Tema:
“Sistema de Registro - Control de Citas del Hospital General del Tigre Luis Felipe
Guevara Rojas”. Desarrollado por: Analía Valenzuela en el año: 2007 Técnica por
Objetivos: Este proyecto se realizó con el propósito de investigar cómo funciona los
sistemas de información en una unidad hospitalaria, partiendo desde el área de control
de citas médicas en el Hospital General del Tigre que se encuentra en un proceso de
crecimiento y reconocimiento en la ciudad de El Tigre, lo que los llevo a encontrar
ciertas deficiencias en su operación diaria ya que todos sus procesos de creación,
diagnostico, asignación de citas se viene realizando manualmente; con el fin de
plantear un nuevo sistema que mejore y agilicen los procesos de atención; asignándole
a cada usuario hospitalidad y confort.
1.3. Planteamiento Del Problema
Actualmente en el centro clínico “BIOCLINIC” existe una deficiencia en su operación

diaria ya que todos sus procesos de asignación de citas y el control de las mismas se
viene realizando manualmente, ocasionando pérdida de tiempo tanto para el personal
que lleva acabo la tarea de registro, asignación y control como para los pacientes que
al ser una actividad manual estos deben dirigirse al establecimiento para ser atendidos
o ver si pueden obtener un cita médica además pueden representar perdidas
económicas para el centro clínico “BIOCLINIC” dado que si la persona no cumple con
su cita el tiempo se llega a perder pudiendo haber sido asignado a otra persona que lo
requiriese.
4
1.3.1. Problema Principal.
El control y manejo de la información de las citas en el centro clínico “BIOCLINIC’S” se

encuentran registradas de forma manual lo que llega a ocasionar, pérdidas de tiempo
para el paciente en ir hasta la clínica a sacar una reservación para la cita o estar
restringido a poder realizar las citas mediante teléfono en horarios de atención
disponible.
1.3.2. Problema Secundarios
 El seguimiento de los controles médicos de los pacientes requiere más trabajo,

debido a que la información se encuentra realizada en agendas médicas en las
cuales se las elabora a mano.
 Las cancelaciones de las citas requieren de tiempo por parte del paciente para
poder realizarlas, debido a que deben dirigirse hasta la clínica para realizarlas.
 Control más efectivo, para con pacientes que no llegan a cumplir sus citas
causando no poder atender a otro paciente en ese tiempo reservado para la
cita.
1.4. Objetivos
Para dar solución al problema planteado anteriormente es necesario llegar a una

situación deseada, la misma expresada en el objetivo general, los objetivos específicos
1.4.1. Objetivo General
Desarrollar un sistema asignación y control de citas médicas, que permita agilizar el

proceso de reservas en línea, así como tener la oportunidad de poder establecer con
mayor calma la fecha y hora de la cita consultando la disponibilidad que se tiene.
5
1.4.2. Objetivos Específicos
 Implementar un módulo que permita realizar una búsqueda según el nombre,
apellido o código de los diferentes pacientes para verificar los controles
médicos.
 Brindar la oportunidad de que los pacientes puedan llegar a cancelar las citas
con anticipación de una manera sencilla para ellos sin tener que perder el
tiempo en ir hasta la clínica o esperar a que contesten el teléfono en la misma.
 Implementar una forma más eficaz de llevar acabo el control sobre los pacientes
que no asisten a sus citas programadas de manera repetitiva, por lo cual se le
puede restringir la opción de realizar reservas de citas médicas por un tiempo.
1.5. Alcances
1.5.1. Alcance Temático
 Ingeniería Web.
 Base de Datos.
 Programación.
 Reutilizacion.
1.5.2. Alcance Geográfico
El desarrollo del presente proyecto se realizará para la clínica de especialidad

BIOCLINIC'S ubicada en Av. Libertadores N° 21.
1.5.3. Alcance Temporal
El desarrollo del presente proyecto se realizará en el espacio de tiempo de 2 meses.
1.5.4. Alcance Institucional
El desarrollo del sistema para el control de citas médicas para la clínica de especialidad
BIOCLINIC’S será solamente para que el usuario que requiera de atención medica
6
realice cita en el dicho centro médico. La misma realizara citas según horarios
establecidos y de acuerdo con la especialidad elegida.
1.6. Limites
- El sistema no emitirá Historias Clínicas dado que solo se centrará en el

Establecimiento y control de las Citas Médicas.
- El sistema no tendrá habilitado la opción de reservas de citas las 24 horas dado
que estas deben ser realizadas con anticipación.
- El sistema no brindara información sobre medicamento recetado dado que no
estar relacionado con la farmacia del hospital.
- No toda persona se podrá registrar al sistema para realizar citas, puesto que
solo lo harán quienes ya tengan una clave familiar por ser pacientes del mismo
y para tal situación por lómenos se requiere haber sido atendido una vez en el
lugar o estar asegurado.
- No se podrán realizar el cancelamiento de una cita a menos que se lo realicen
con un mínimo de 3 horas de anticipación a la hora programada.
1.7. Justificación
1.7.1. Justificación Tecnológica

Actualmente el establecimiento cuenta con los equipos básicos necesarios para poder
implementar el sistema propuesto, los cuales no son aprovechados como tal siendo
los sistemas operativos de las computadoras windows 8.1, cuenta con una red interna
para realizar algunas operaciones, dispone de acceso a Internet, además de tener toda
la disponibilidad de adquirir un servidor en el cual se pueda almacenar todo lo que será
la base de datos del lugar.
1.7.2. Justificación Institucional

La implementación de sistema propuesto realizará cambios significativos en la entidad
como un mayor control de las citas programadas dando la oportunidad de ver si existen
pacientes que no cumplen de manera reiterada con las citas que establecen, dando
7
así la oportunidad de poder sancionar de alguna manera esta situación. Así como
evitar lo más que se pueda tener filas largas que en ocasiones únicamente llegan a
molestar a los pacientes que podrían ya no querer volver a la clínica. También brindara
a los pacientes la oportunidad de que sean ellos los que escojan el horario y la fecha
para su atención siempre y cuando el doctor con el cual quieran ser atendidos tengan
disponibilidad de horario.
(imagen del establecimiento por buenas críticas).
1.7.3. Justificación Económica
Con la implantación del sistema se pretende lograr que los tiempos de espera por parte
de los pacientes ya no sean largos, dando de esa manera la seguridad a los pacientes
de que su tiempo es igual de importante para el establecimiento como para ellos.
También se pretende cuidar los ingresos económicos dado diferentes aspectos:
- Si un paciente es atendido correctamente y además no pierde demasiado
tiempo en lo que es la espera con seguridad este volverá cuando requiera
atención médica.
- Con un control más dedicado a lo que son los pacientes incumplidos se podrá
cuidar de que no realicen más citas médicas de manera inmediata, dando la
oportunidad de que el tiempo sea utilizado para atender a otro que realmente lo
podría llegar a necesitar.
8
Capítulo 2 Marco
Teórico
9
2.1 Ingeniería de Software
Ingeniería de software es el área de la ingeniería que ofrece métodos y técnicas para

desarrollar y mantener software. Existen varias definiciones sobre esta ciencia de la
computación que permiten describir este proceso.
2.1.1 El Arte de la Ingeniería de Software
La Ingeniería del Software trata con áreas muy diversas de la Informática y de las
ciencias de la computación, tales como construcción de compiladores, sistemas
operativos o desarrollos de Intranet/Internet, abordando todas las fases del ciclo de
vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una
infinidad de áreas tales como: negocios, científica, medicina, producción, logística,
banca, control de tráfico, meteorología, el mundo del derecho, la red de redes Internet,
redes Intranet y Extranet, etc.
2.1.2 Definición de Ingeniería de Software
Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo,
se pueden citar las enunciadas por algunos de los más prestigiosos autores:
 Ingeniería de software es el estudio de los principios y metodologías para el

desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
 Ingeniería de software es la aplicación práctica del conocimiento científico al
diseño y construcción de programas de computadora y a la documentación
asociada requerida para desarrollar, operar y mantenerlos. Se conoce también
como desarrollo de software o producción de software (Bohem, 1976).
 Ingeniería de software trata del establecimiento de los principios y métodos de
la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje
en máquinas reales (Bauer, 1972).
10
 Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento del software; es decir, la aplicación de la
ingeniería al software (IEEE, 1993).
2.1.3 El Producto y el Proceso de la Ingeniería de Software.
Las definiciones del producto y el proceso en Ingeniería de Software son:
2.1.3.1 El Producto
El software de computadora se ha convertido en el alma máter. Es la máquina que

conduce a la toma de decisiones comerciales. Sirve para la investigación científica
moderna y de resolución de problemas de ingeniería. Es el factor clave que diferencia
los productos y servicios modernos. Está inmerso en sistemas de todo tipo: de
transportes, médicos, de telecomunicaciones, militares, procesos industriales,
entretenimientos, productos de oficina, la lista es casi interminable.
El software de computadora es el producto que diseñan y construyen los ingenieros

del software. Esto abarca programas que se ejecutan dentro de una computadora de
cualquier tamaño y arquitectura, documentos que comprenden formularios virtuales e
impresos y datos que combinan números y texto y también incluyen representaciones
de información de audio, vídeo e imágenes.
Los ingenieros de software lo construyen, y virtualmente cualquier persona en el

mundo industrializado lo utiliza, bien directa o indirectamente. Es importante porque
afecta muy de cerca cualquier aspecto de la vida y está muy extendido en el comercio
y en las actividades cotidianas.
Los pasos son construir software de computadora como construimos cualquier otro
producto satisfactorio, aplicando un proceso que conduce a un resultado de alta
11
calidad, que satisface las necesidades de las personas que usarán el producto. Debes
aplicar un enfoque de ingeniería de software.
Desde el punto de vista de un ingeniero de software, el producto obtenido son los

programas, documentos y los datos que configuran el software de computadora. Pero
desde el punto de vista de los usuarios el producto obtenido es la información
resultante que de algún modo mejora el mundo de los usuarios.
2.1.3.2 El Proceso
Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que

el conocimiento está inicialmente disperso, el desarrollo del software implícito, latente
e incompleto en gran medida, es un proceso social de aprendizaje.
El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software.

El proceso proporciona una interacción entre los usuarios y los diseñadores, entre los
usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas
de desarrollo [tecnología]. Es un proceso interactivo donde la herramienta de
desarrollo se usa como medio de comunicación, con cada iteración del diálogo se
obtiene mayor conocimiento de las personas involucradas.
Cuando se trabaja para construir un producto o un sistema, es importante seguir una

serie de pasos predecibles, un mapa de carreteras que le ayude a obtener el resultado
oportuno de calidad. El mapa de carreteras a seguir es llamado proceso del software.
Lo construyen los ingenieros del software y sus gestores adaptan el proceso a sus
necesidades y entonces lo siguen. Además, las personas que han solicitado el
software tienen un papel a desempeñar en el proceso del software. Es importante
porque proporciona estabilidad, control y organización a una actividad que puede, si
no se controla, volverse caótica.
12
Los pasos son a un nivel detallado, el proceso que adoptemos depende del software
que estamos construyendo. Un proceso puede ser apropiado para crear software de
un sistema de aviación, mientras que un proceso diferente por completo puede ser
adecuado para la creación de un sitio web.
Desde el punto de vista de un ingeniero de software, los productos obtenidos son

programas, documentos y datos que se producen como consecuencia de las
actividades ingenieriles definidas por el proceso.
Hay una cantidad de mecanismos de evaluación del proceso de software que permiten
a las organizaciones determinar la madurez de su proceso. Sin embargo, la calidad,
oportunidad y viabilidad a largo plazo del producto que se está construyendo, son los
mejores indicadores de la eficiencia del proceso que estamos utilizando.
2.1.4 Modelos de Desarrollo del Software.
Existen varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya

la ingeniería de software para la construcción del software, entre ellos se puede citar:
 Modelo en cascada (modelo tradicional).

 Modelo de prototipos.
 Modelo Espiral.
 Desarrollo por etapas.
 Desarrollo iterativo y creciente o Iterativo e Incremental.
 Modelo de desarrollo rápido de aplicaciones (Rapid Application Development,
RAD o DRA).
 Desarrollo concurrente.
 Proceso Unificado de Desarrollo RUP (Proceso Unificado de Rational).
13
2.4 Metodología SCRUM
En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de

costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.
Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por
otra parte, es que esos ciclos sean lo más cortos posibles. Scrum es una metodología
ágil y obedece a las necesidades anteriormente citadas, y no responde a ninguna
moda.
2.4.1 Forma de Trabajo
Se puede definir como un conjunto de prácticas y roles que definen, esto lo podemos
tomar como punto de partida para definir el proceso de desarrollo del proyecto. Los
roles a definir son:
 ScrumMaster: es el encargado del desarrollo del proyecto, se le puede tomar
como el gerente del proyecto.
 ProductOwner: son los patrocinadores del proyecto o StakeHolders.
 Team: equipo de analistas, programadores, etc. Miembros del proyecto.
El algoritmo de trabajo es el siguiente:
Durante cada Sprint (periodo de aproximadamente cuatro semanas) se genera un

nuevo incremento en el desarrollo del software el cual es un potencial entregable.
14
El criterio de lo que se debe de generar en dicho sprint se llama Product Backlog, más
detalladamente se puede definir como “el conjunto de requisitos de alto nivel
priorizados que definen el trabajo a realizar”.
Los Product Backlog que componen cada Sprint son definidos en un conjunto de
reuniones llamadas Sprint Planning.
Durante estas reuniones el ProductOwner hace saber a los miembros del equipo los
elementos que desea tener listos para el próximo entregable, entonces el equipo hace
saber que trabajo es capaz de realizar para el siguiente entregable, y durante el sprint
los requisitos del sprint backlog no pueden ser alterados para no generar cambios
importantes en la línea de desarrollo del entregable.
Uno de los pilares del Scrum es el entender que siempre se van a encontrar desafíos
con respecto a las necesidades del cliente (cambios, alcance, requerimientos extras
etc.), por lo cual adopta una tendencia de maximizar la capacidad del equipo de
entregar rápidamente y enfocarse en la resolución de los problemas emergentes. Una
de las grandes ventajas de la implementación del método Scrum es que es fácil de
aprender y requiere poco esfuerzo para iniciar su implementación.
2.4.1.1. Características
 Manejo de Roles para simplificar la identificación de cada uno de los

participantes del proyecto.
 Creación de entregables bien definidos para disminuir la probabilidad de
cambios sobre la línea establecida.
 De darse un cambio se agilizará la finalización del entregable para encarar el
problema.
 Fácil de entender.
 Requiere poco esfuerzo para iniciar su implementación.
15
2.4.1.2. Principios
Se basa en los principios ágiles:

 Privilegiar el valor de la gente sobre el valor de los procesos.
 Entregar software funcional lo más pronto posible.
 Predisposición y respuesta al cambio.
 Fortalecer la comunicación y la colaboración.
 Comunicación verbal directa entre los implicados en el proyecto.
 Simplicidad; supresión.
2.4.1.3. Elementos de SCRUM
 Roles.
 Product Owner.
 Scrum Master.
 Team (Equipo).
 Poda de Requerimientos.
 Product Backlog.
 Sprint.
 Planificación.
 Sprint Backlog.
 Scrum.
 Estimaciones.
 Builds continuos.
 Revisión del Sprint.
 Reunión retrospectiva.
 Valores.
 Foco.
 Comunicación.
 Respeto.
16
 Coraje.
 n de artefactos innecesarios en la gestión del proyecto.
2.4.1.4. Roles del SCRUM
Product Owner: El Product Owner representa la voz del cliente.

Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva
del negocio.
ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo

trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el
objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-
organizan), sino que actúa como una protección entre el equipo y cualquier influencia
que le distraiga.
Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un

pequeño equipo de 3 a 9 personas para realizar el trabajo (análisis, diseño, desarrollo,
pruebas, documentación, etc.).
“Roles Auxiliares: Los roles auxiliares en los "equipos Scrum" son aquellos que
no tienen un rol formal y no se involucran frecuentemente en el "proceso
Scrum", sin embargo, deben ser tomados en cuenta.”
Stakeholders (Clientes, Proveedores, Vendedores, etc.): Se refiere a la gente que

hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado
que justifica su producción. Sólo participan directamente durante las revisiones del
sprint.
Administradores (Managers): Es la gente que establece el ambiente para el

desarrollo del producto.
17
2.4.1.5. Reunión de Planificación del Sprint.
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint”
se lleva a cabo.
 Seleccionar qué trabajo se hará.
 Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que
tomará hacer el trabajo.
 Identificar y comunicar cuánto del trabajo es probable que se realice durante el
actual Sprint.
 Ocho horas como límite.
 Al final del ciclo Sprint, dos reuniones se llevarán a cabo: la “Reunión de
Revisión del Sprint” y la “Retrospectiva del Sprint”.
 Reunión de Revisión del Sprint (Sprint Review Meeting).
 Revisar el trabajo que fue completado y no completado.
 Presentar el trabajo completado a los interesados (alias “demo”).
 El trabajo incompleto no puede ser demostrado.
 Cuatro horas como límite.
2.4.1.6. Documentos
El product backlog: es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.
priorizadas según su retorno sobre la inversión (ROI). Es el que va a ser construido.
Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto
del valor para el negocio, como del esfuerzo de desarrollo requerido.
El sprint backlog: es un documento detallado donde se describe el cómo el equipo

va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en
horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16
horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son
18
asignadas, son tomadas por los miembros del equipo del modo que les parezca
oportuno.
2.4.2. Proceso de Desarrollo de la Metodología SCRUM.
2.4.2.1. Modelo de Desarrollo del Trabajo.
Es una metodología de desarrollo de software basada en el modelo iterativo

incremental, la cual es implementada en entornos de desarrollo de software ágil.
Figura. 2.1. Modo de Trabajo de la Metodología SCRUM
Los procesos de Scrum corresponden a todas aquellas actividades y al flujo de las

mismas dentro de un proyecto Scrum. En total la metodología desarrolla 19 procesos
que se agrupan en 5 fases. Cada fase describe cada proceso en detalle, incluyendo
sus entradas, herramientas y salidas asociadas. En cada proceso, algunas entradas,
herramientas y salidas son obligatorias, y existen otras que son opcionales, cuyo uso
dependerá de la naturaleza del proyecto.
 Iniciación (6 procesos).
 Planificación y Estimación (5 procesos).
 Implementación (3 procesos).
 Revisión y Retrospectiva (3 procesos).
19
 Lanzamiento (2 procesos).
Elige un responsable de producto: Esta persona es la que tiene la visión clara de lo

que se necesita, se va a hacer, fabricar o conseguir. Tendrá en cuenta riesgos y
compensaciones, qué es posible y qué es factible.
Elige un equipo: ¿Quién va a hacer el trabajo real? Este equipo necesita tener las
habilidades necesarias para convertir en realidad la visión del responsable de
producto. Los equipos tienen que ser pequeños: entre 3 y 9 personas es lo normal.
Elige un Scrum Master: Es la persona que conducirá a todos los demás por el sistema
de trabajo Scrum ayudando al equipo a eliminar todo aquello que les frene.
Elabora y prioriza una lista de objetivos o backlog: El Backlog no es más que una
lista de todo lo que debe hacerse para convertir la visión en realidad. Esta lista existe
y evoluciona a lo largo del proceso, es el mapa o la hoja de ruta del producto.
En cualquier momento del proyecto, la lista de objetivos pendientes es la única y
definitiva vista panorámica «de todo lo que el equipo podría hacer, por orden de
prioridades». Existe una sola lista de objetivos pendientes.
Debería consultar con todos los interesados y con el equipo para asegurarse de que
representan tanto lo que quiere el cliente como lo que es factible construir.
Haz una estimación afinada de la lista de objetivos pendientes: Es crucial que las
personas que realmente van a llevar a cabo los ítems enumerados en la lista, calculen
el esfuerzo que les llevará cada uno. El equipo deberá ir ítem por ítem para decidir si
realmente es factible hacerlo.
¿Hay información suficiente para llevar a cabo cada uno? ¿Es lo suficientemente
pequeño para poder calcular? ¿Hay una definición de “hecho”? ¿Todo el mundo está
de acuerdo en los requisitos que hay que cumplir para considerar que una cosa está
“hecha”? ¿Ofrece un valor visible?
20
Cada ítem tiene que poder presentarse, tiene que estar listo para, idealmente, poder
ser puesto en marcha.
Planificación de sprints: Ésta es la primera reunión Scrum. El equipo, el Scrum

Master y el responsable de producto se sientan a planificar el sprint.
Los sprints siempre duran una cantidad determinada de tiempo, que es menos de un
mes. Habitualmente, casi todo el mundo hace sprints de una o dos semanas. El equipo
mira el principio de la lista de objetivos pendientes y hace una previsión de cuánto
pueden tener terminado en este sprint. Si el equipo ya ha hecho algún sprint, deberían
tener en cuenta los puntos que hicieron en el último. Ese número se conoce como la
velocidad del equipo. El Scrum Master y el equipo deberían estar siempre intentando
aumentar esa cifra en cada sprint. También es el momento para que el equipo y el
responsable de producto se aseguren de que todo el mundo entiende exactamente
cómo estos ítems van a lograr crear la visión. Además, en esta reunión todos deben
ponerse de acuerdo en la meta, lo que todos quieren lograr en ese sprint.
Hacer que el trabajo sea visible: La forma más habitual de hacer esto es con una
pizarra de Scrum y sus tres columnas: Pendiente, En proceso, Hecho. Los post-it
representan los ítems que hay que completar y el equipo los cambia de sitio en la
pizarra, a medida que se van terminando, uno por uno.
Otra forma de hacer que el trabajo sea visible es crear un diagrama burn down o de
trabajo pendiente. En uno de los ejes está el número de puntos que el equipo ha
llevado al sprint y en el otro el número de días. Cada día el Scrum Master registra el
número de puntos que se han completado y los anota en el diagrama de trabajo
pendiente. Lo ideal sería que hubiera una curva descendente que llegara a cero puntos
en el último día del sprint.
Scrum Diario. Reunión Diaria de pie: Éste es el pulso vital del Scrum. Cada día a la
misma hora, durante no más de quince minutos, el equipo y el Scrum Master se ven y
responden a tres preguntas:
21
 ¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?
 ¿Qué vas a hacer mañana para ayudar al equipo a terminar el sprint?
 ¿Qué obstáculos se interponen en tu camino o el del equipo?
Ya está. En eso consiste la reunión. Si dura más de quince minutos usted está
haciendo algo mal. Esto ayuda al equipo a saber exactamente en qué punto está cada
ítem del sprint.
¿Se van a terminar todas las tareas a tiempo? ¿Existe la posibilidad de ayudar a otros
miembros del equipo a superar obstáculos? Las tareas no se asignan desde arriba, el
equipo es autónomo; son ellos los que deciden. No hay que despachar detalladamente
con los directivos. El Scrum Master es el responsable de eliminar los obstáculos que
impiden que el equipo avance.
Revisión o demostración del sprint: Ésta es la reunión en la que el equipo muestra

lo que ha construido durante el sprint. Puede estar presente cualquiera, no sólo el
responsable de producto, el Scrum Master y el equipo, sino los directivos de la
empresa, los jefes, los clientes, todo el que quiera. Es una reunión abierta en la que el
equipo explica lo que han podido pasar a la columna de «hecho» durante el sprint.
El equipo debería mostrar únicamente lo que se ajuste perfectamente a la definición
de «hecho». Aquello que esté completamente terminado y que se puede entregar
porque no necesita más trabajo. Puede no ser un producto terminado, pero debería
ser una característica del mismo, que está lista para empezar a funcionar.
Retrospectiva del sprint: Después de que un equipo haya mostrado lo que ha

conseguido durante el último sprint se sientan a reflexionar sobre lo que ha ido bien,
lo que podría hacerse mejor y lo que se podría perfeccionar en el siguiente sprint. ¿Qué
mejora puede incorporar el equipo al proceso de forma inmediata?
Al final de la reunión, el equipo y el Scrum Master deberían haberse puesto de acuerdo
en una mejora del proceso que incorporarán en el siguiente sprint. Ese proceso de
mejora, que se conoce también como kaizen, debería incluirse en la lista de objetivos
22
pendientes del siguiente sprint, con tests de aceptación. Así, será fácil para el equipo
ver si realmente han implementado la mejora y qué efecto ha tenido en la velocidad.
Empieza inmediatamente el siguiente ciclo de SPRINT: Teniendo en cuenta la

experiencia anterior del equipo con obstáculos y la incorporación de mejoras.
2.4.3 Fases de la Metodología SCRUM
SCRUM comprende las siguientes fases:
2.4.3.1 Pre-juego
Planificación: Definición de una nueva versión basada en la pila actual, junto con una
estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto
la visión como el análisis. Si se trata de la mejora de un sistema existente comprende
un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase
incluye la modificación de la arquitectura y diseño generales.
2.4.3.2 Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto

continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con
estas variables define el final de esta fase. El sistema va evolucionando a través de
múltiples iteraciones de desarrollo o sprints.
2.4.3.3 Post-juego
Preparación para el lanzamiento de la versión, incluyendo la documentación final y

pruebas antes del lanzamiento de la versión.
23
2.4.3.4 Pasos de cada fase
a) Pasos de la planificación
 Desarrollo de un backlog completo.

 Determinación de la fecha de entrega y la funcionalidad de una o más versiones.
 Selección de la versión más adecuada para desarrollo inmediato.
 Trazado de los “paquetes del producto” (objetos) sobre los elementos del
backlog de la versión elegida.
 Selección del equipo o equipos para desarrollar la nueva versión.
 Evaluación y control adecuado de los riesgos.
 Estimación del coste de la versión, incluyendo desarrollo, material, marketing,
formación y despliegue.
 Conformidad de la dirección y financiación del proyecto.
b) Pasos de diseño y arquitectura
 Revisión de los elementos del backlog incluidos en la versión.

 Identificación de los cambios necesarios para implementar el backlog.
 Análisis del dominio para incluir los requisitos que incluye el desarrollo mejora
o actualización.
 Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades.
 Identificar problemas del desarrollo o modificaciones.
 Reunión de revisión de diseño. Cada equipo presenta los cambios para
implementar los elementos del backlog, e identificar posibles reasignaciones.
c) Pasos del desarrollo (Sprint)
La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el

cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido
también como ingeniería concurrente.
24
El desarrollo consiste en los siguientes macro-procesos:
 Reunión con los equipos para revisar los planes de lanzamiento de versión.
 Distribución, revisión y ajuste de los estándares de conformidad para el
producto.
 Sprints iterativos hasta que el producto se considera listo para su distribución.
Un sprint es un conjunto de actividades de desarrollo llevado a cabo durante un periodo

predefinido, por lo general entre una y cuatro semanas. Duración basada en la
complejidad del producto, evaluación de riesgos y grado de supervisión deseado.
El tiempo determinado para el sprint establece su velocidad e intensidad.
El riesgo se evalúa de forma continua a través de las respuestas a los controles
adecuados establecidos.
Cada sprint consiste en uno o varios equipos realizando:

 Desarrollo: Definición de los cambios necesarios para la implementación de
los requisitos del backlog en módulos, la apertura de los módulos, análisis del
dominio, diseño, desarrollo, implementación, pruebas y documentación de los
cambios. El Desarrollo consiste en el micro proceso de descubrimiento,
invención e implementación.
 Envoltura: Cierre de los módulos, creación de una versión ejecutable con los
cambios que implementas los requisitos del backlog.
 Revisión: Reunión de todos los equipos para presentar el trabajo y revisar el
progreso, identificando y resolviendo posibles cuestiones y añadiendo nuevos
elementos al backlog. Se revisan los riesgos y las respuestas apropiadas.
 Ajuste: Consolidación de la información de la revisión de los módulos
afectados.
Cada sprint es seguido de una revisión cuyas características son:

 Está presente y participa el equipo al completo.
25
 La revisión puede incluir a clientes, personal de ventas y otros.
 La revisión cubre los sistemas funcionales y ejecutables abarcados por el
equipo e incluye los cambios que se han realizado para implementar los
elementos del backlog.
 En la revisión se pueden evidenciar cambios en la forma en la que se han
implementado los elementos del backlog.
 La revisión también puede introducir elementos nuevos en el backlog,
cambiando de esta forma los contenidos y dirección de las versiones previstas.
 Se determina la fecha de la siguiente revisión en base al progreso y
complejidad. La duración normal de los sprints es de 1 a 4 semanas.
Figura. 2.2. Proceso de la Metodología SCRUM
d) Cierre
Cuando el equipo de gestión siente que las variables de tiempo, parte completada,
requisitos, coste y calidad están alineadas para producir una nueva versión, declaran
cerrada la versión, dando paso a esta fase.
En esta fase se prepara el producto generado para producir una nueva versión. Entre
las tareas de cierre se encuentran: integración, pruebas del sistema, documentación
de usuario, preparación del material de formación y marketing.
26
e) Controles de SCRUM
Al trabajar bordeando el caos (complejidad e imprevisibilidad) se requiere la gestión

de controles que eviten la caída en el caos.
La metodología SCRUM incorpora estos controles generales para evitar la pérdida de
control, utilizando las técnicas de Orientación a Objetos para la construcción de las
entregas.
El principal control es el del riesgo. La gestión de riesgos da lugar a cambios en los
controles y respuestas del equipo.
Los controles de la metodología SCRUM Son:

 Backlog: Requisitos que el producto en su versión actual no gestiona de forma
adecuada. Errores, defectos, peticiones del cliente, incorporación de mejoras
competitivas o tecnológicas son elementos del backlog.
 Los elementos del backlog que comprenden una nueva versión comprenden
variables de fechas, calidad y funcionalidad viables.
 Paquetes: componentes del producto que deben cambiarse para implementar
la nueva versión.
 Cambios: cambios que deben producirse en un paquete para implementar una
nueva versión.
 Problemas: problemas técnicos presentes que deben resolverse para
implementar un cambio.
 Riesgos: Para lograr el éxito del proyecto se revisan de forma continua los
riesgos y las respuestas previstas. La gestión de riesgos afecta a otros
controles.
 Soluciones: respuestas a problemas y riesgos, que suelen ser cambios.
 Temas: Cuestiones generales del proyecto que no se definen en términos de
paquetes.
27
Estos controles se emplean en diversas fases de SCRUM. La dirección los emplea
para gestionar el backlog. Los equipos los usan para gestionar cambios y problemas.
Ambos, dirección y equipos, gestionan los temas, riesgos y soluciones. Estos controles
son revisados, modificados y consolidados en la revisión de cada Sprint.
2.5 Herramientas Case
De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es

la aplicación de tecnología informática a las actividades, las técnicas y las
metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han
sido diseñadas, en el caso de CASE para automatizar o apoyar una o más fases
del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida
de las aplicaciones de bases de datos, también se puede escoger una herramienta
CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de
tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:
 Un diccionario de datos para almacenar información sobre los datos de la aplicación

de bases de datos.
 Herramientas de diseño para dar apoyo al análisis de datos.
 Herramientas que permitan desarrollar el modelo de datos corporativo, así como los
esquemas conceptual y lógico.
 Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de

una aplicación de bases de datos.
2.5.1 Historia
En la década de los setenta el proyecto ISDOS desarrolló un lenguaje llamado

"Problem Statement Language" (PSL) para la descripción de los problemas de
28
usuarios y las necesidades de solución de un sistema de información en un diccionario
computarizado. Problem Statement Analyzer (PSA) era un producto asociado que
analizaba la relación de problemas y necesidades.
Pero la primera herramienta CASE como hoy la conocemos fue "Excelerator" en 1984,
era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos
por ejemplo el EASYCASE o WINPROJECT. (Monografías.com)
2.5.2. Tecnología Case

La tecnología CASE supone la automatización del desarrollo del software,
contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de
información y se plantean los siguientes objetivos:
 Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser

realizadas con una herramienta se consigue agilizar el trabajo.
 Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
 Simplificar el mantenimiento de los programas.
 Mejorar y estandarizar la documentación.
 Aumentar la portabilidad de las aplicaciones.
 Facilitar la reutilización de componentes software.
 Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilización de gráficos.
Automatizar:
 El desarrollo del software.

 La documentación.
 La generación del código.
 El chequeo de errores.
 La gestión del proyecto.
29
Permitir:
 La reutilización del software.

 La portabilidad del software.
 La estandarización de la documentación.
2.5.3 Componentes de una Herramienta Case

De una forma esquemática podemos decir que una herramienta CASE se compone de
los siguientes elementos:
 Repositorio (diccionario) donde se almacenan los elementos definidos o creados

por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de
Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
 Meta modelo (no siempre visible), que constituye el marco para la definición de
las técnicas y metodologías soportadas por la herramienta.
 Carga o descarga de datos, son facilidades que permiten cargar el repertorio de
la herramienta CASE con datos provenientes de otros sistemas, o bien generar a
partir de la propia herramienta esquemas de base de datos, programas, etc. que
pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio
de comunicación con otras herramientas.
 Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la
exactitud, integridad y consistencia de los esquemas generados por la herramienta.
 Interfaz de usuario, que constará de editores de texto y herramientas de diseño
gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y
menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las
distintas metodologías.
2.5.4 Estructura General de una Herramienta Case

La estructura CASE se basa en la siguiente terminología:
30
 CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases
finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación
de sistemas, el análisis de sistemas y el diseño de sistemas.
 CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases
finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la
implantación de sistemas y el soporte de sistemas.
 CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan
actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen
actividades como la gestión de proyectos y la estimación.
2.5.5 Características De Una Case

Deberes de una herramienta CASE Cliente / servidor:
 Proporcionar topologías de aplicación flexibles. La herramienta debe

proporcionar facilidades de construcción que permita separar la aplicación (en
muchos puntos diferentes) entre el cliente, el servidor y más importante, entre
servidores.
 Proporcionar aplicaciones portátiles. La herramienta debe generar código

para Windows, OS/ 2, Macintosh, Unix y todas las plataformas de servidores
conocidas. Debe ser capaz, a tiempo de corrida, desplegar la versión correcta
del código en la máquina apropiada.
 Control de Versión. La herramienta debe reconocer las versiones de códigos

que se ejecutan en los clientes y servidores, y asegurarse que sean
consistentes. También, la herramienta debe ser capaz de controlar un gran
número de tipos de objetos incluyendo texto, gráficos, mapas de bits,
documentos complejos y objetos únicos, tales como definiciones de pantallas y
de informes, archivos de objetos y datos de prueba y resultados. Debe
mantener versiones de objetos con niveles arbitrarios de granularidad; por
ejemplo, una única definición de datos o una agrupación de módulos.
31
 Crear código compilado en el servidor. La herramienta debe ser capaz de
compilar automáticamente código 4GL en el servidor para obtener el máximo
performance.
 Trabajar con una variedad de administradores de recurso. La herramienta debe

adaptarse ella misma a los administradores de recurso que existen en varios
servidores de la red; su interacción con los administradores de recurso debería
ser negociable a tiempo de ejecución.
 Trabajar con una variedad de software intermedios. La herramienta debe

adaptar sus comunicaciones cliente / servidor al software intermedio existente.
Como mínimo la herramienta debería ajustar los temporizadores basándose en,
si el tráfico se está moviendo en una LAN o WAN.
 Soporte multiusuarios. La herramienta debe permitir que varios diseñadores

trabajen en una aplicación simultáneamente. Debe gestionarse los accesos
concurrentes a la base de datos por diferentes usuarios, mediante el arbitrio y
bloqueos de accesos a nivel de archivo o de registro.
 Seguridad. La herramienta debe proporcionar mecanismos para controlar el

acceso y las modificaciones a los que contiene. La herramienta debe, al menos,
mantener contraseñas y permisos de acceso en distintos niveles para cada
usuario. También debe facilitar la realización automática de copias de seguridad
y recuperaciones de las mismas, así como el almacenamiento de grupos de
información determinados, por ejemplo, por proyecto o aplicaciones.
Desarrollo en equipo, repositorio de librerías compartidas. Debe permitir que grupos

de programadores trabajen en un proyecto común; debe proveer facilidades de check-
in/ check-out registrar formas, widgets, controles, campos, objetos de negocio, DLL,
etc.; debe proporcionar un mecanismo para compartir las librerías entre distintos
realizadores y múltiples herramientas; Gestiona y controla el acceso multiusuario a los
datos y bloquea los objetos para evitar que se pierdan modificaciones
inadvertidamente cuando se realizan simultáneamente.
32
2.5.6 Herramienta Case: Enterprise Architect
Enterprise Architect es una herramienta CASE que aborda el diseño BPM y análisis
UML, cubre el desarrollo de software desde la captura de requerimientos a lo largo de
las etapas de análisis, diseño, pruebas y mantenimiento. EA es una herramienta multi-
usuario, diseñada para ayudar a construir software robusto y fácil de mantener.
Además, permite generar documentación e informes flexibles.
2.5.6.1 Soporte Comprensivo para UML
Soporta los 14 diagramas de UML 2.3.

Los diagramas de comportamiento incluyen: Casos de Uso, Actividades, Estado,
Descripción de la interacción, Secuencia y Comunicación.
Los diagramas de estructurales incluyen: Paquetes, Clases, Objetos, Composición,
Componentes y Despliegue.
Soporte para los perfiles de estilo UML 2.0
2.5.6.2 Interfaz de usuario intuitiva
 Amplio rango de barras de herramientas, ventanas acoplables, y estilos

visuales.
 Guarda y restaura disposiciones de ventanas personalizadas.
 Modifica y personaliza las barras de herramientas y menús.
 Crea sus propios aceleradores.
 “Desplaza" las ventanas acopladas para maximizar el espacio de las ventanas
y mejorar la eficiencia de su trabajo.
 Amplio sistema de menús para tener control de su modelo.
 Los accesos rápidos permiten la creación de elementos de diagramas y
conexiones sensibles al contexto.
2.5.6.3 Documentación flexible y comprensible.
 Generador RTF conducido por plantillas completas WYSIWYG.
33
 Las plantillas soportan todas las características de los elementos del modelo
de EA y los datos extendidos (tales como Pruebas, Riesgos, Recursos,
Cambios, etc.)
 Las plantillas soportan encabezados, pies, tablas de contenidos, imágenes
embebidas, índices, títulos de páginas, tablas jerarquizadas y más.
 Salida en formato de texto enriquecido.
 Opciones de salida flexibles con filtros y criterios de selección.
 Guarda las plantillas reportadas para una reutilización posterior.
 Documentación compatible de Word para editar posteriormente y vincular a los
documentos maestros de Word.
 Generador de reporte HTML adicional para crear reportes HTML detallados.
Fije sus modelos en Internet o en su Intranet usando el generador de reportes
HTML.
 Reportes adicionales incluyendo para métricas de casos de uso, pruebas y
más.
Los documentos en texto enriquecido se pueden vincular a los elementos del
modelo y editados directamente usando el editor de texto enriquecido
incorporado.
2.5.6.4 Ingeniería de código directa e Inversa
 Generador de código dirigido por plantillas completas - modifique las plantillas

incorporadas o escriba sus propias plantillas desde el inicio.
 Agrega lenguajes de destino adicionales.
 Editor del código fuente seleccionado de sintaxis con capacidad para "guardar
y sincronizar" con rapidez.
 Soporte incorporado para código fuente C++, Java, C#, VB.Net, Visual Basic,
Delphi, PHP, Python y ActionScript.
 Soporte para Corba también disponible como un "plug-in" libre.
34
2.5.6.5 Modelado de base de datos
 Ingeniería Inversa para muchos de los sistemas populares DBMS, incluyendo

Oracle 9i y 10g, SQL Server, My SQL, Access, PostgreSQL y otros.
 Modela tablas de base de datos, columnas, claves, claves foráneas, y
relaciones complejas usando UML y perfiles de modelado de datos
incorporados.
 Generación directa de los scripts DDL para crear las estructuras de base de
datos.
2.5.7 Herramienta Case: Smartsheet
Smartsheet es una aplicación de software onlineque facilita la gestión de proyectos de

forma colaborativa y en tiempo real. Es de pago y funciona por subscripción, con
diferentes paquetes de funcionalidades posibles. Compatible con Google Apps y con
el CRM SalesForce, se integra también con Box. Al ser online, funciona con cualquier
sistema operativo que se tenga instalado en el ordenador, sea éste Windows, MacOS
o Linux. Se puede trabajar también desde dispositivos móviles y tabletas.
Este software es idóneo para administrar y controlar muchos tipos de proyectos, en

especial los que requieren de un trabajo en equipo, pero también para crear listas de
tareas, manejar información de clientes, elaborar previsiones de venta, planificar
eventos o controlar procesos de negocio en general. El diseño de diagramas de
Gantt es una de sus funciones más destacadas. Los gráficos representan la
programación de las tareas de forma visual, clara y sencilla. Se puede partir de una
plantilla predeterminada o crearlos desde cero. Sus características interactivas hacen
fácil la personalización, y el uso de formatos condicionales para resaltar tareas o
niveles de estado con diferentes colores también contribuyen a ello.
Las relaciones de dependencia entre actividades y el porcentaje de ejecución del

proyecto son datos que se observan en tan solo un golpe de vista. Una vez que ya se
ha creado un diagrama de Gantt, es también sencillo modificarlo, ya que muchas de
35
las funciones se basan en movimientos del ratón del tipo “arrastrar y soltar”. Por
ejemplo, para variar las fechas de inicio y fin, para marcar los hitos o para construir
dependencias entre tareas. Esta sencillez la hace muy accesible a todo tipo de público.
También con un clic del ratón o un toque sobre la pantalla se pueden ajustar los
diagramas. Las vistas, con sus tareas clave y sus fechas de inicio y fin, son fácilmente
intercambiables: vista de cuadrícula, vista de calendario y vista de Gantt. Permite
insertar el diagrama en un PowerPoint, exportarlo en formatos de archivo PNG o PDF,
y también adjuntarlo a un mensaje de correo electrónico.
Smartsheet facilita la colaboración de varias personas en tiempo real y el estar al día

de cualquier avance o cambio en el proyecto. La edición online, la reprogramación de
tareas, el ajuste de plazos, los mensajes de correo para notificaciones y la posibilidad
de compartir archivos son utilidades valiosas. Incluso, a través de un sistema de
alertas, avisa cuando se ha producido algún reajuste en el proyecto. Al ser un web
construido con HTML5 es amigable para cualquier usuario y compatible con Google
Drive. Sin embargo, es una herramienta que también presenta algunos
inconvenientes.
Los más importantes se relacionan con una orientación más enfocada en las tareas
que en los recursos, en primer lugar y, en segundo término, con el hecho que no
presenta la posibilidad de marcar las líneas de base del proyecto. En consecuencia,
no ofrece una visión comparativa de los cambios que se van produciendo en el
diagrama de Gantt. Smartsheet combina funcionalidades potentes de gestores de
proyectos clásicos como Microsoft Project, con la facilidad de uso de una hoja de
cálculo online, varias capas de permisos para la colaboración en equipo, y una
automatización de funciones que supone un gran ahorro de tiempo.
36
2.5.8 Herramienta Case: ScrumDo
2.5.8.1 Planificación
Crea historias de usuario y planea carreras rápidas con nuestras herramientas de

planificación flexibles. uno es libre de elegir su marco de trabajo: Scrum, Kanban,
Scrumban, SAFe.
2.5.8.2 Mapa de usuario de historia
Crea historias de usuario y planea sprints con la función Mapa de historias de usuario.
2.5.8.3 Alertas Inteligentes
Aprovecha las alertas inteligentes de ScrumDo se mantiene al tanto de todo lo que

está sucediendo en su organización. Las alertas de imagen general, las notificaciones
de Bandeja de entrada y Slack aseguran que no se pierda nada.
2.5.8.4 Herramienta que se adapta a su proceso
Diseñado para la escala, ScrumDo ayuda a ver el panorama general de la organización

y lo personaliza a su manera de trabajar con nuestras tablas flexibles y soporte para
marcos múltiples, como Scaled Agile Framework (SAFe), Enterprise Scrum, Kanban y
Scrumban.
37
Capítulo 3 Analisis
de Factibilidad
38
3.1. Factibilidad Operativa
Con la finalidad de garantizar el buen funcionamiento del sistema y que este impactara
en forma positiva a los usuarios, se desarrollara con una interfaz amigable al usuario,
lo que la convierte en una herramienta de fácil manejo y comprensión, que no requiere
de personal especializado para su funcionamiento.
Tabla 3.1. “Conocimientos mínimos que deben tener los distintos usuarios para
operar y cumplir sus funciones dentro del sistema”
Fuente: Elaboración Propia.
Nro. USUARIO CONOCIMIENTOS MINIMOS
 Conocimiento del proceso de asignación de citas.

(Actual)
 Manejo de dispositivos móviles (celulares, Tablets)
Recepcionista
1  Manejo basico de Computadoras.
y/o Enfermera
 Capacitación de Funcionamiento del Sistema
Implementado.
 Conocimientos básicos de internet
 Conocimiento del proceso de asignación de citas.
(Actual)
 Manejo de dispositivos móviles (celulares, Tablets).
2 Doctor  Manejo básico de Computadoras.
 Conocimientos básicos de internet.
 Capacitación de Funcionamiento del Sistema
Implementado.
 Conocimientos básicos de Internet.
3 Pacientes  Manejo de dispositivos móviles (Celulares, Tablets).
 Manejo de Básico de Computadoras.
39
3.2. Factibilidad Técnica.
Factibilidad técnica es una evaluación que debe demostrar la facultad del sistema para
ponerse en marcha y mantenerse durante el tiempo, además debe demostrar que la
planeación del sistema ha sido desarrollada cuidadosamente contemplando todas las
restricciones y objetivos, aprovechando los recursos que entrega la organización.
3.2.1. Hardware
Con respecto a los requerimientos de hardware, existe en el mercado los equipos

requeridos para el cumplimiento del objetivo. Los requerimientos del hardware para un
correcto funcionamiento del sistema son los siguientes:
3.2.1.1. Requerimientos de Hardware de desarrollo
Tabla 3.2. “Requerimientos del Hardware de desarrollo”

HARDWARE CARACTERISTICAS CARACTERISTICAS
MINIMAS RECOMENDADAS
Intel Core i3-7100/AMD Intel Core i5 tercera generación
Microprocesador Athlon 64 X2 (procesador de /AMD FX 4300 o mayor
64 bits) (procesador de 64 bits)
Memoria RAM 4GB 8GB
Disco Duro 500GB Sin limite
Adaptador de Red Realtek PCi GBE Realtek PCi GBE

Monitor 15” 15”
Teclado Estándar Estándar
Mouse 2 botones 2 botones
40
3.2.1.2. Requerimientos de Hardware del Usuario.
Tabla 3.3. “Requerimientos mínimos del Hardware del usuario”
Nro. DESCRIPCION CARACTERISTICAS
1 Microprocesador Intel® Pentium D 2,66 GHz o superior
2 Memoria RAM 2 GB
3 Tarjeta Madre Tarjeta Madre Asrock N68-vs3 cket

Am3+
4 Tarjeta de Red TP-LINK TL-WN881ND 300MB
5 Monitor Samsung LED SD300F
6 Disco Duro Samsung 300gb sata modelo hd502hi
7 Case Dell
8 Teclado Genius KB06XE
9 Mouse USB Genius Optico
41
3.2.1.3. Requerimientos de Hardware Del Servidor
Tabla 3.4. “Requerimientos mínimos del Hardware del Servidor”
NRO. DESCRIPCION CARACTERISTICAS
1 Core 4 núcleos
2 Microprocesado A8-7410 2.5 GHz

r
3 Disco Duro (HD) SATA II de 3,5 (a 7.200 rpm): 80 GB,160 GB, 250
GB,500 GB
4 Memoria RAM Hasta 32 GB , con 4 pastillas de 8 GB de memoria
marca HyperX
5 Tarjeta Madre PESC1435 (velocidad) — 1333 MHz, 1600 MHz,
Frecuenciash313m
1866MHz, DDR3
6 Tarjeta de Video ATI R5 integrada con memoria de 4 Gb
7 Tarjeta de Red Tarjetas duales NIC Broadcom Gigabit2

integradas compatibles con compensación de
carga y recuperación ante fallos
8 Quemador de LG 52x
CD
9 Case 600 W; Auto-switching universal 90-264 V
Fuente: Elaboración Propia
3.2.2. Software
En cuanto al software se puede desarrollar un sistema que se adapte a las

necesidades propias del establecimiento. Los requerimientos del software para
trabajar en el hardware son los siguientes:
42
3.2.2.1. Requerimientos de Software de Desarrollo.
Tabla 3.5. “Requerimientos mínimos del Software de Desarrollo”
SOFTWARE REQUERIMIENTOS MINIMOS
Sistema Operativo Windows 8.1 o superior de 64 bits
 Php
Software de lenguaje  Html
 bootstrap
Navegador Google Chrome/Mozilla Firefox/Opera
3.2.2.2. Requerimientos de Software del Usuario.
Tabla 3.6. “Requerimientos mínimos del Software del usuario”
DESCRIPCION CARACTERISTICAS
Sistema Operativo Windows Vista SP1 de 32 bits
Navegadores  Chrome 38.0.21.25.104

 Firefox 52.0.2
 Internet Explorer 8
Acrobat Reader PDF Adobe Reader 8
43
3.2.2.3. Requerimientos del Software del Servidor.
Tabla 3.6. “Requerimientos mínimos del Software del Servidor”
Nro SOFTWARE DESCRIPCION
1 Lenguaje de Programación PHP
2 Gestor de Base de Datos MySQL
3 Servidor de Aplicaciones XAMPP
4 Sistema Operativo Windows Vista SP1 de 32

bits
3.3. Factibilidad Económica.
En esta etapa, hay que comprobar que el proyecto es sustentable económicamente,

se refiere a los recursos económicos y financieros necesarios para desarrollar o llevar
a cabo las actividades o procesos y/o para obtener los recursos básicos que deben
considerarse son el costo del tiempo, el costo de la realización y el costo de adquirir
nuevos recursos.
3.3.1. Hardware
Con respecto a los requerimientos de hardware, existe en el mercado los equipos

requeridos para el cumplimiento del objetivo. Los requerimientos del hardware para un
correcto funcionamiento del sistema y el costo de cada una de estas son los siguientes:
44
3.3.1.1. Requerimientos de Hardware de desarrollo
Tabla 3.2. “Requerimientos del Hardware de desarrollo”
EQUIPO O ESPECIFICACION COSTO $ COSTO

PRODUCTO Bs
Intel Core i3-7100/AMD 54.51 380

Microprocesador Athlon 64 X2 (procesador de
64 bits)
Memoria RAM 4GB 41.60 290
Disco Duro 500GB 47.34 330
Adaptador de Realtek PCi GBE 31.56 220

Red
Monitor 19” 83.21 580
Teclado Estándar 11.47 80
90
Mouse 2 botones 12.91
TOTAL 282.6 $ 1970 Bs
45
3.3.1.2. Requerimientos de Hardware del Usuario.
Tabla 3.3. “Requerimientos mínimos del Hardware del usuario”

DESCRIPCION ESPECIFICACION COSTO $ COSTO Bs
Microprocesad Intel® Pentium D 2,66 GHz o 54.51 380

or superior
Memoria RAM 2 GB 35.58 247
Tarjeta Madre Tarjeta Madre Asrock N68-vs3 55 383.35

cket Am3+
Tarjeta de Red TP-LINK TL-WN881ND 300MB 24.96 174
Monitor Samsung LED SD300F 83.21 580
Disco Duro Samsung 300gb sata modelo 45.91 320

hd502hi
Case Dell 55 383.35
Teclado Genius KB06XE 11.47 80
Mouse USB Genius Optico 12.91 90
TOTAL 378.35 $ 2637.7 Bs
3.3.2. Software
En cuanto al software se puede desarrollar un sistema que se adapte a las

necesidades propias del establecimiento. Los requerimientos del software para
trabajar en el hardware son los siguientes:
46
3.3.2.1. Requerimientos de Software de Desarrollo.
Tabla 3.5. “Requerimientos mínimos del Software de Desarrollo”

SOFTWARE REQUERIMIENTOS COSTO COSTO
MINIMOS $ Bs
Sistema Windows 8.1 o superior de 29.73 207.23
Operativo 64 bits
total 29.73 207.23
3.3.2.2. Requerimientos de Software del Usuario.
Tabla 3.6. “Requerimientos mínimos del Software del usuario”
DESCRIPCION CARACTERISTICAS COSTO COSTO

$ Bs
Sistema Windows Vista SP1 de 32 bits 6.80 47.40
Operativo
Acrobat Adobe Reader 8 34.69 241.85

Reader PDF
total 41.49 289.25
COSTO TOTAL DE HARDWARE Y SOFTWARE: 732.37 $ -- 5104.61 Bs
COSTO DEL DESARROLLO DEL SOFTWARE
Cantidad de líneas de código: 4 000

Salario por persona:3 000 bs
Personal: 2 programadores
47
𝑴𝑷 = 𝟑. 𝟎(𝟒)𝟏.𝟏𝟐 = 𝟏𝟒. 𝟏𝟕
𝑻𝑫𝑬𝑺 = 𝟐. 𝟓 ∗ 𝟏𝟒. 𝟏𝟕𝟎.𝟑𝟓 = 𝟔. 𝟑𝟐 𝒎𝒆𝒔𝒆𝒔
𝟏𝟒. 𝟏𝟕
𝑵= = 𝟐. 𝟐𝟒 𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔
𝟔. 𝟑𝟐
𝑺𝒂𝒍𝒂𝒓𝒊𝒐 = 𝟑𝟎𝟎𝟎 ∗ 𝟔. 𝟑𝟐 ∗ 𝟐 = 𝟑𝟕𝟗𝟐𝟎 𝒃𝒔

𝑺𝒂𝒍𝒂𝒓𝒊𝒐 𝒑𝒐𝒓 𝟔 𝒎𝒆𝒔𝒆𝒔 = 𝟓𝟒𝟒𝟖. 𝟐𝟕 $
Costo de desarrollo de software: 𝟓𝟒𝟒𝟖. 𝟐𝟕 $ 36448.92 Bs

Costo total del proyecto
costo de hardware y software: 732.37 $

+
costo de desarrollo de software: 𝟓𝟒𝟒𝟖. 𝟐𝟕 $
_______________________________________________________________
Costo total del proyecto: 𝟔𝟏𝟖𝟎. 𝟔𝟒$ 43079.06 Bs
48
Capítulo 4 Plan de
Desarrollo de
Software
49
4.1 Plan de Desarrollo de Software en Base a la Metodología SCRUM
Tabla Plan de Desarrollo de Software en Base a la Metodología SCRUM
Fases Sprint Actividades Entregables Responsable Fecha

Pre Sprint 0 - Planificación Plan de Jonathan y 23/09/2018
Juego de los Sprint desarrollo de Erika
Software.
- Concepción. Identificación 13/09/2018
de los procesos
actuales.
- Indagación. Tabla de 13/09/2018
Identificación
de los actores.
- Elaboración. Tabla de 20/09/2018
Requerimientos
del Sistema.
- Desarrollo Product 20/09/2018
del Product Backlog
Backlog
General del
Sistema.
Desarrollo de Planificación 23/09/2018
la del Proyecto.
planificación.
Diseñar la Diseño de la 23/09/2018
Base de Base de Datos.
Datos.
Elaboración Diagrama de
del diagrama Casos de Uso
de Casos de de Alto Nivel
Uso de Alto
Nivel.
Juego Sprint 1 Desarrollo del Product Erika 04/10/2018
Gestión de Product backlog jonathan
usuario backlog, para Especifico
el Sprint
Elaboración Historias de 24/09/2018
de las usuario
Historias de
usuario
Elaboración Diagrama de 25/09/2018
del Diagrama caso de uso
de caso de expandido
50
uso
expandido
Elaboración diseño de 26/09/2018
del diseño de interfaces
interfaces
Elaboración diagrama de 28/09/2018
del diagrama navegación
de
navegación
Desarrollo del Prototipo del
módulo de módulo.
Gestión de
Usuario.
Prueba Resultados de
Unitaria la Prueba.
Sprint2 Análisis del product Erika
auditoria product backlog jonathan
backlog
Historias de Historias de
usuario usuario
Diagrama de Diagrama de
caso de uso caso de uso
expandido expandido
Elaboración Diseño de
interfaces
Elaboración Diagrama de
de
navegación
módulo de módulo.
Auditoria
Unitaria la Prueba.
Sprint 3 Análisis del product Erika
citas product backlog jonathan
backlog
usuario usuario
expandido expandido
51
Elaboración diseño de
interfaces
Elaboración diagrama de
de
navegación
módulo de módulo.
Citas
Unitaria la Prueba.
Sprint 4 Análisis del product Erika
reportes product backlog jonathan
backlog
usuario usuario
expandido expandido
Elaboración diseño de
interfaces
Elaboración diagrama de
de
navegación
módulo de módulo
Reportes
Unitaria la Prueba.
Post- Despliegue - Realizar Documentación Erika
juego Pruebas de de la prueba. jonathan
Navegacion
- Elaboracion Manual de
de Manuales Usuario.
de Usuario.
- Pruebas de Documentacion
Integracion de la Prueba
52
Pre- juego
4.2. Concepción
Para la etapa de concepción del sistema se pudo notar la molestia de algunos

pacientes que requerían de atención médica en la clínica de especialidades
BIOCLINIC'S
Esta molestia se debía a que los pacientes en algunas ocasiones debían esperar
bastante tiempo para poder ser atendidos por un especialista en dicha entidad.
Este problema se debe a que la atención en la clínica es por orden de llegada y en

esto hace que los pacientes deban esperar su turno hasta recibir la atención.
4.2.1. Identificación de procesos actuales.
En esta sección se verán las actividades principales sobre cómo se realiza el proceso
para que un paciente pueda obtener la atención médica en el centro clínico.
4.2.1.1. Proceso de recepción del Paciente.

- Se debe ingresar al centro clínico BIOCLINIC'S y dirigirse hacia la recepcionista,
la cual anota el nombre del paciente en una lista para así poder llamarlo cuando
sea el momento de su atención.
4.2.1.2. Ingreso del Paciente.
- La recepcionista llamara al paciente que este en la fila y le indicara que es su

turno en ser atendido, inmediatamente lo direccionara para ingresar a su
consulta médica.
4.2.1.3. Consulta médica.
- Una vez que el paciente ingresa a la consulta el doctor procede a la atención el

paciente, realizando el procedimiento de revisión del paciente.
53
- Una vez terminado el proceso de revisión, el doctor programara una nueva cita,
si es que así lo requiera el paciente.
- La cita que se programa con el paciente la agenda el doctor, de tal forma que
la deja escrita en una nota que se la entrega al paciente.
4.2.1.4. Fin de Consulta en Recepción.
- Una vez terminada la consulta médica, el doctor indica a el/la recepcionista que
agente la próxima cita del paciente si es que esta se coordinó con el paciente
anteriormente.
4.3. Indagación.
Para el desarrollo del sistema se pudo identificar a todos involucrados que intervienen
en los procesos actuales de la atención medica que recibe el paciente. Se identificaron
los siguientes:
4.3.1. Lista de Involucrados.
Tabla Lista de Involucrados.
INVOLUCRADOS DESCRIPCION
Paciente Es la persona que se dirige a la clínica
para recibir atención médica
especializada.
Doctor Es el médico especialista quien realiza
el control, revisión y medicación del
paciente.
Así mismo realiza la programación de la

próxima cita médica.
Administrador Es la persona que se encarga de
realizar los registros de los doctores así
mismo tiene acceso a todo el sistema.
Registro de recepcionista y pacientes.

54
Recepcionista Es la persona que se encarga de anotar
el nombre del paciente a su llegada , de
igual manera agenda la fecha de su
próxima cita.
4.4. Elaboración.
Una vez que se detectaron los involucrados en el sistema y también los procesos que
tienen se notó algunas fallas y debilidades en dicho proceso que se tienen que tomar
en cuenta.
Partiendo de lo observado se pudo obtener algunos requerimientos que se clasificaran

en funcionales y no funcionales.
4.4.1. Identificación de Actores en el Sistema.
En la siguiente tabla se definirá a los actores que interactuarán con el sistema además
de las funciones que cumplirán.
INVOLUCRADOS FUNCIONES EN EL SISTEMA PROPUESTO
Administrador - Registrará a los diferentes tipos de usuarios

(Administrador, Recepcionista, Doctor y Pacientes).
- Modificar los datos de los tipos de usuarios (Administrador,
Recepcionista, Doctor y Pacientes).
- Podrá dar de baja a los diferentes usuarios.
- Agregará, modificar y eliminará Especialidades que tendrá
el centro clínico BIOCLINIC'S
- Podrá realizar búsqueda de los diferentes tipos de
usuarios registrados.
- Tendrá acceso a los diferentes tipos de reportes.
- Acceso a ver la información de Auditoria.
- Acceso a todo el sistema en general.
55
Doctor - Podrá ver la lista de pacientes que tiene programada en el
día.
- Vera los pacientes que ha atendido.
- Editar su perfil.
- Establecerá citas para los pacientes.
- Generar los reportes.
Recepción - Registrar a las personas que requieren de atención médica.
- Realizar las reservas en caso de que el paciente este en la

clínica.
- Realizar la activación de la penalización en caso de que el

paciente no se haga presente en la clínica.
- Tiene acceso de vista a las fechas y horarios disponibles

para la atención del paciente.
- Editar perfil.
- Ver lista de pacientes penalizados.
- Cancelación de Citas programadas.
Paciente - Tendrá la lista de fechas y horarios disponibles según la

especialidad que elija.
- Editar perfil.
- Podrá registrarse online, siempre que cuente con un código

familiar de algún responsable, caso contrario el primer
registro deberá realizarlo en el lugar por medio de recepción.
- Podrá realizar cancelación de sus citas.
- Realizar citas online.
56
- Lista de doctores según especialidad.
4.4.2. Tabla de Requerimientos.

Se definió 2 tablas: una para requerimientos funcionales y otra para requerimientos no
funcionales.
4.4.2.1. Requerimientos Funcionales.
Son aquellos que describen cualquier actividad que este deba realizar, en otras
palabras, el comportamiento o función particular de un sistema o software cuando se
cumplen ciertas condiciones. Por lo general, estos deben incluir funciones
desempeñadas por pantallas específicas, descripciones de los flujos de trabajo a ser
desempeñados por el sistema y otros requerimientos de negocio, cumplimiento,
seguridad u otra índole.
Tabla Requerimientos Funcionales.
Nº REQUISITO ESPECIFICACION
R1 Registrar a los usuarios que se Se podrán registrar a usuarios como

les permite según su rol. doctores recepcionistas y paciente y
administrador.
R2 Búsqueda y lista de los El administrador tendrá el privilegio de

pacientes registrados. tener el listado de paciente registrados y
poder tener información de los mismos
R3 Modificación de datos de El usuario podrá realizar cambios en sus

información según su rol. datos ya que podrían haber errores al
introducir los mismos
57
R4 Acceso a las fechas y horarios En esta sección el paciente podrá observar
disponibles de los Doctores. las fechas y horarios disponibles que se
tiene para poder realizar la cita medica
R5 Registrar la identidad de quien Se guardara los usuarios que registren

realiza el registro de los para así poder tener un control más óptimo
diferentes usuarios y la fecha en sobre los movimientos en el sistema
la cual se realiza.
R6 Registrar las modificaciones en Ser registrara si los usuarios realizaron

los datos de usuario. cambios en sus datos , teniendo así quien
hizo el cambio y la fecha en la que se
realizo
R7 Realizar la reserva de citas Los pacientes podrán realizar las reservas

médicas. de sus citas médicas mediante el portal
web
R8 Realizar la reserva de citas El paciente podrá realizar la reserva la cita

desde el mismo establecimiento. médica en la misma clínica,mediante la
ayuda de la recepcionista
R19 Lista de pacientes que tienen Al ingresar al sistema los doctores tendrán
citas en el día según su doctor. el listado de los pacientes que tiene en
espera a ser atendidos
R10 Lista de pacientes que tienen La lista de los pacientes deberá estar
citas en el día. disponible para el doctor la recepcionista y
el administrador
R11 Lista de pacientes penalizados Los pacientes que incumplan con las citas
por incumplimiento. realizadas, tendrán una penalización por el
incumplimiento de la misma , teniendo así
58
restricción en las citas médicas por un
cierto periodo de tiempo
R12 Lista de pacientes que han Se tendrá un listado de los pacientes que
cancelado por algún motivo. realizaron la cancelación mediante la
plataforma teniendo así el acceso normal
hacia una nueva cita
R13 Lista de Doctores y sus Los pacientes podrán ver el nombre de los
especialidades. doctores que atienden en la clínica así
como las especialidades de los mismos.
R14 Registrar información de la cita Se almacenará los cambios que tenga en

médica, las reservas de citas médicas así como
que tipo de operación. (Reserva,
Cancelada, Incumplida).
R15 Encriptar las contraseñas. Las contraseñas de los usuarios para el

acceso al sistema serán encriptadas, así
se tendrá mayor seguridad para la
información de lo usuarios en el sistema
R16 Restringir el accesos al sistema Se tendrá un registro de aquellos

a los pacientes incumplidos. pacientes que realicen citas y no lleguen a
dicha cita, estos no podrán hacer citas
mediante el portal web
R17 Reportes de pacientes no El administrador tendrá el reporte de los

atendidos, atendidos y pacientes se fueron atendidos en la clínica
penalizados. así como el reporte de los que realizaron
reserva y no llegaron as u cita ,también el
reporte de los pacientes que tiene en una
penalización por incumplir con su reserva
59
R18 Restringir la navegación según Cada usuario tendrá una navegación
el rol. diferente respecto al sistema, es decir el
doctor ni La recepcionista tendrán acceso
a todas las acciones. Poniendo así solo las
acciones que le competen en su rol de
usuario
R19 Inicio de sesión Iniciar sesión para poder acceder a las

diferentes funciones del sistema de
acuerdo al rol que desempeña en la clínica
R20 Portal del sistema Esta será la página de inicio para todos los
usuarios del sistema en el cual se verá
representación de la institución como tal .
Fuente elaboración propia.
4.4.2.2. Requerimientos No Funcionales.
Los requerimientos no funcionales representan características generales y

restricciones de la aplicación o sistema que se esté desarrollando. Suelen presentar
dificultades en su definición dado que su conformidad o no conformidad podría ser
sujeto de libre interpretación, por lo cual es recomendable acompañar su definición
con criterios de aceptación que se puedan medir.
Entre los ejemplos de requerimientos no funcionales presentados, tenemos los

referidos a atributos como la eficiencia, seguridad, dependencia y usabilidad del
sistema. También presentamos ejemplos de requerimientos no funcionales
organizacionales y externos.
60
Tabla Requerimientos no funcionales.
Nº REQUISITO
RNF 1 Funcionalidad en cualquier navegador
móvil.
RNF 2 Base de Datos de los pacientes,
doctores, recepcionistas y
administradores.
RNF 3 El sistema podrá generar la
desactivación de la penalización en
cuanto se haya cumplido el tiempo
establecido.
RNF 4 El sistema podrá operar con varios
usuarios loqueados a la vez
RNF 5 La interfaz gráfica garantiza la fácil
navegabilidad
RNF 6 El sistema será desarrollado para
dispositivos que tengan acceso a
internet.
RNF 7 El sistema funcionara solo con usuarios
que ingresen su usuario y contraseña
correcta.
RNF 8 El sistema no podrá operar sin conexión
a internet
4.5. Product Backlog
El equipo de desarrollo para este proyecto fue conformado de la siguiente manera:

Product Owner: Centro Clínico Bioclinic’s
Scrum Master: Ing. Cynthia Rodriguez
Scrum Team: Jonathan Mamani Bueno
Erika Sossa Poma
Definido los participantes de desarrollo comprometidos con la realización del proyecto

es que en la primera reunión que se realiza en el proyecto es que se definió la siguiente
lista de requerimiento priorizada:
61
Nº REQUISITO ESTIMACION PRIORIDAD RESPONSABLE
INICIAL
R1 Registrar de . 2 Alta Jonathan Mamani

usuarios
R2 Búsqueda y lista de 3 Media Erika sossa

los pacientes.
R3 Modificación de 1 Muy alta Jonathan Mamani

información
R4 Acceso a las fechas 1 Muy alta Jonathan Mamani

y horarios de los
Doctores.
R5 . Guardar el nombre 3 Media Erika sossa

del usuario que hace
registros
R6 Registrar las 2 Alta Erika sossa

modificaciones en la
información del
usuario.
R7 Realizar la reserva 1 Muy alta Jonathan Mamani

de citas médicas
R8 Hacer la reserva de 1 Muy alta Jonathan Mamani

citas en la clínica
R9 Lista de pacientes 2 Alta Erika sossa

que tienen el doctor.
R10 Lista de pacientes 3 Media Erika sossa

del día
62
R11 Lista de pacientes 2 Alta Erika sossa
penalizados por
incumplimiento.
R12 Lista de pacientes 3 Media Jonathan Mamani

que han cancelado
por algún motivo.
R13 Lista de Doctores y 2 Alta Jonathan Mamani

sus especialidades.
R14 Registrar 2 Alta Erika sossa

información de la cita
médica,
R15 Encriptar las 1 Muy alta Jonathan Mamani

contraseñas.
R16 Restringir el accesos 1 Muy alta Jonathan Mamani

al sistema a los
pacientes
incumplidos.
R17 Reportes de 2 Alta Erika sossa

pacientes no
atendidos, atendidos
y penalizados.
R18 Restringir la 1 Muy alta Jonathan Mamani

navegación según el
rol.
R19 Inicio de sesión 1 Muy alta Jonathan Mamani
63
R20 Portal de la clinica 2 alta Erika sossa
FUENTE: Elaboración propia

4.6. Especificación
En esta etapa como lo planteamos en nuestro plan desarrollaremos el Diagrama de
Caso de Uso del nuevo sistema propuesto.
4.6.1. Diagrama de caso de uso
Este diagrama muestra las diferentes acciones que el usuario puede realizar con el
sistema:
4.6.1.1. Diagrama de caso de uso de alto nivel
Figura 4.6.1 diagrama de caso de uso de alto nivel
64
En la representación del diagrama de casos de uso de alto nivel se describe el
significado de mismo, lo que permitirá a los usuarios y desarrolladores una visión
global del sistema.
Tabla 4.6.1 Especificación detallada de las acciones del usuario en cada caso de uso
Casos de Uso Tipo Actores Descripción

Gestión de usuario Principal administrador Permite a los usuarios crear una
Doctor identificación para poder acceder
Paciente a las funciones del sistema
Este acceso será de acuerdo al rol
y las actividades que desempeña
en la clínica
Auditorias Principal administrador Permite tener información de
todos los movimientos que se
realiza en el sistema de citas así
como el de las acciones que
realizan los pacientes
recepcionistas, administradores y
doctores en el mismo.
Citas Principal administrador Permite ver las especialidades
Doctor fecha y hora que tiene disponible
Paciente la clínica para la atención de los
pacientes
Reportes Secundario Administrador Permite al administrador tener el

reporte de las actividades en el
sistema, reportes diarios de los
pacientes ,las citas realizadas por
el portal web, asi como las citas
realizadas .
FUENTE: ELABORACION PROPIA
4.7 Planificación
En esta actividad se detallará la planificación que se hizo para llevar a cabo la
realización del presente proyecto detallando así las fechas de las tareas a realizar
65
4.7.1. Planificación de los sprint
En la siguiente se detallará la planificación de cada sprint
Figura planeación de los sprint
66
Fuente: Elaboración propia
4.8. diseño de la base de datos
Una base de datos correctamente diseñada le permite obtener acceso a información
actualizada y precisa. Como es esencial tener un diseño correcto para lograr sus
objetivos de trabajar con una base de datos, tiene mucho valor invertir el tiempo
necesario para obtener información sobre los principios de un buen diseño.
4.8.1. Diseño de la base de datos del sistema de citas de la clínica
67
Juego
Desarrollo de Sprint: se detallará el desarrollo de la funcionalidad de los sprint, los
mismo que fueron divididos en módulos para poder lograr un mayor enfoque más
específico para los requerimientos que presento la clínica
4.9. Sprin1
Este sprint está enfocado al módulo de GESTIÓN DE USUARIO del sistema, en el
cual se detallará el acceso al sistema, y las variaciones que presenta según el tipo de
usuario que ingrese al sistema.
4.9.1 .Product Backlog

Tabla requisitos modulo gestión de usuario
Nº REQUISITO DESCRIPCION MODULO PRIORI NUMERO

DAD HISTORIA
R1 Registrar de El administrador GESTION DE Alta 7

usuarios registrara a doctores USUARIO
recepcionistas Y
pacientes. así mismo el
paciente podrá registrarse
por medio del portal web
de la clínica.
R3 Modificación El usuario podrá realizar GESTION DE Alta 7

de cambios en sus datos ya USUARIO
información que podrían haber errores
al introducir los mismos
R18 Restringir la Cada usuario un aves GESTION DE Muy alta 6

navegación ingresada al portal y USUARIO
según el rol. después del logueo, se
direccionara a una
interfaz diferente de
68
acuerdo a las funciones
que desarrolla con el
sistema.
R19 Inicio de Los usuarios deberán GESTION DE Muy alta 1

sesión ingresar un usuario y USUARIO
contraseña cuando
deseen ingresar al
sistema
R20 Portal de la El portal será la interfaz GESTION DE alta 5

clínica de presentación de la USUARIO
institución.
Así mismo será el medio

por el cual los usuarios
ingresaran al sistema
Figura Diagrama de Casos de Uso “gestión de usuario”
69
4.9.2.Historia de Usuario
Tabla. Historia de Usuario de “gestión de usuario”
HISTORIAS DE USUARIO
Numero: 1 Administrador, doctor, paciente,
recepcionista
Nombre Historia: Portal de sistema.
Prioridad del negocio: Alta Riesgo en desarrollo: Media
Puntos Estimados: Iteración Asignada: 1
Programadores Responsables: Erika y Jonathan
Descripción:
Se requiere de un portal el cual será de inicio al sistema
Esta interfaz deberá tener información de la clínica.
También será la página de inicio del sistema, por el cual todos los usuarios
ingresaran al sistema con su usuario y su contraseña al estar en la página de
logueo.
4.9.3. Interfaces del Módulo de Gestión de Usuario.
70
Figura5.1. diseño de la Interfaz del portal del sistema

Figura prototipo del portal del sistema
71
Fuente propia
4.9.3. Historia de Usuario
Tabla. Historia de Usuario de “gestión de usuario”
Numero: 2 Administrador, doctor, paciente, recepcionista
Nombre Historia: login.
Descripción:
Para la interfaz de logueo se deberá validar a los usuarios con su usuario y su
contraseña, esto se le permitirá una vez que el usuario haya sido registrado en
le sistema.
72
Figura diseño de la interfaz de la página de logueo
Figura prototipo de la interfaz de logueo
73
4.9.4.Diagrama de Navegación.
4.9.5 Historia de Usuario
Tabla. Historia de Usuario de “gestión de usuario” administrador
Numero: 3 Administrador
Nombre Historia: logueo admin .
74
Descripción:
El administrador deberá loguearse con su usuario y contraseña.
Al ser el administrador el sistema deberá direccionarlo a una interfaz la cual le permitirá
tener acceso a todas las acciones del sistema .
4.9.5.1. Interfaces del administrador.
Figura. diseño de la Interfaz del administrador
75
Figura. prototipo de la Interfaz del administrador

4.9.6 Diagrama de navegación

76
Tabla. Historia de Usuario de “gestión de usuario” doctor
Numero: 4 doctor
Nombre Historia: logueo doctor.
Descripción:
El doctor deberá loguearse con su usuario y contraseña.
Al ser el doctor el sistema deberá direccionarlo una interfaz la cual le permitirá tener un reporte
con el listado de los pacientes que tiene, también podrá agendar una nueva cita así también
podrá editar su perfil de usuario , es decir podrá corregir sus datos en caso de que algunos sean
erróneos.
También podrá cambiar de contraseña de usuario esto para poder tener mayor seguridad.
4.9.8. Interfaces del doctor

Figura. diseño de la Interfaz del doctor
77
Figura. prototipo de la Interfaz del doctor
4.9.9 diagrama de navegación
78

Tabla. Historia de Usuario de “gestión de usuario” recepcionista
Numero: 5 recepcionista
Nombre Historia: logueo recepcionista.

Descripción:
La recepcionista deberá loguearse con su usuario y contraseña.
Al ser la recepcionista el sistema deberá direccionarlo a una interfaz la cual le permitirá tener
el listado de los pacientes que deben ser atendidos así como registrar a nuevos pacientes, ver
las citas que ya se tiene registradas de otros pacientes.
4.9.11.Interfaces de la recepcionista
Figura diseño de la interfaz de la recepcionista
79
Figura prototipo de la interfaz de la recepcionista
4.9.12. Diseño de navegación
80
Tabla. Historia de Usuario de “gestión de usuario” paciente
Numero: 6 paciente
Nombre Historia: logueo paciente.
Descripción:
El paciente deberá loguearse con su usuario y contraseña.
Al ser el paciente el sistema deberá direccionarlo a una interfaz la cual le permitirá tener el
listado de las especialidades de la clínica así como las fechas disponibles y la reservación de
una cita médica.
4.9.14. Interfaces del paciente.

Figura. diseño de la Interfaz del paciente
81
Figura. prototipo de la Interfaz del paciente
82
4.9.15. Diagrama de navegación

REGISTROS DE USUARIOS

Tabla. Historia de Usuario de REGISTRO DE USUARIOS
Numero: 7 administrador
Nombre Historia: REGISTRO DE USUARIOS.
Descripción:
el administrador deberá ingresar el registro de los doctores que trabajan en la clínica así
como la recepcionista, una vez que estén registrados podrán tener acceso al sistema en
su rol de usuario.
los pacientes podrán registrarse mediante el portal web sin la necesidad que lo
haga el administrador
83
Figura diagrama de navegación admin Figura diagrama de navegación
navegación paciente
FUENTE: Elaboración propia FUENTE: Elaboración propia
Diseño de la interfaz de formulario de registro de usuarios
84
Figura prototipo de la interfaz de formulario de registro de recepcionista
Figura prototipo de la interfaz de formulario de registro de medicos

85
Figura prototipo de la interfaz de formulario de registro de paciente
Figura prototipo de la interfaz de formularios de registro

86
PRUEBAS DEL SPRINT 1
Las pruebas de este sprint consisten en la validación de los campos al momento de
ingresar sus datos, es decir que en los campos se ingresen los tipos de datos que
deben almacenar.
4.10 Sprint 2
Este sprint está enfocado al módulo de AUDITORIA del sistema, en el cual se
detallará los accesos que tiene el sistema.
Este módulo será desarrollado para el administrador el cual tendrá información de los
usuarios que ingresen al sistema, así como lo cambios realizados.
Nº REQUISITO DESCRIPCION MODULO PRIORIDAD NUMERO

DE
HISTOIA
R5 Guardar el Se guardara el AUDITORIA Media 8

nombre del nombre del
usuario que usuario que
registra realice el registro
de otros usuarios
R6 Registrar Si los usuarios AUDITORIA Alta 9

modificaciones realizan cambios
de la en su información
información del esta será
usuario. guardada.
R14 Registrar Se tendrá un AUDITORIA Alta 10

información de registro de las
la cita médica, fechas en las que
se hacen las
reservas y el
usuario que las
realiza
Diagrama de caso de uso

87
Figura Diagrama de caso de uso expandido
Fuente: elaboración propia
4.10.1. Historia de usuario
tabla historia de usuario AUDITORIA USUARIOS
Numero: 8 Usuario: ADMINISTRADOR

Nombre Historia: AUDITORIA USUARIOS
88
Descripción:
El administrador una vez que haya ingresado al sistema tendrá la opción de poder
observar los cambios que hacen los otros usuarios.
Se registrarán las fechas en las que se realizaron modificaciones, teniendo así el registro
de la operación que se hizo y el rol del usuario
4.10.2. Interfaces del módulo auditoria
Figura diseño de la interfaz auditoria
89
4.10.3 Prototipo de la interfaz del módulo auditoria
Figura prototipo de interfaz de módulo de auditoria
Figura prototipo de la interfaz del módulo auditoria usuario
90
91

TACH

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TACH

Cargado por

Copyright:

Formatos disponibles

INGENIERIA DE SISTEMAS

ESCUELA MILITAR DE INGENIERÍA

Modalidad: trabajo final

ESTUDIANTES: Erika Sossa Poma

Capítulo 1 Generalidades ................................................................................................................ 1

Hoy en día las empresas e instituciones manejan cantidades de información

Es así que la tecnología apoya al ser humano al momento de satisfacer necesidades

Si una persona presenta síntomas de alguna enfermedad, o aqueja de dolores lo que

De acuerdo con lo investigado se pudo encontrar los siguientes antecedentes de

1.3. Planteamiento Del Problema

Actualmente en el centro clínico “BIOCLINIC” existe una deficiencia en su operación

El control y manejo de la información de las citas en el centro clínico “BIOCLINIC’S” se

1.3.2. Problema Secundarios

 El seguimiento de los controles médicos de los pacientes requiere más trabajo,

Para dar solución al problema planteado anteriormente es necesario llegar a una

1.4.1. Objetivo General

Desarrollar un sistema asignación y control de citas médicas, que permita agilizar el

1.5.1. Alcance Temático

1.5.2. Alcance Geográfico

El desarrollo del presente proyecto se realizará para la clínica de especialidad

1.5.3. Alcance Temporal

El desarrollo del presente proyecto se realizará en el espacio de tiempo de 2 meses.

1.5.4. Alcance Institucional

- El sistema no emitirá Historias Clínicas dado que solo se centrará en el

1.7.1. Justificación Tecnológica

1.7.2. Justificación Institucional

1.7.3. Justificación Económica

Ingeniería de software es el área de la ingeniería que ofrece métodos y técnicas para

2.1.1 El Arte de la Ingeniería de Software

2.1.2 Definición de Ingeniería de Software

 Ingeniería de software es el estudio de los principios y metodologías para el

2.1.3 El Producto y el Proceso de la Ingeniería de Software.

Las definiciones del producto y el proceso en Ingeniería de Software son:

El software de computadora se ha convertido en el alma máter. Es la máquina que

El software de computadora es el producto que diseñan y construyen los ingenieros

Los ingenieros de software lo construyen, y virtualmente cualquier persona en el

Desde el punto de vista de un ingeniero de software, el producto obtenido son los

Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que

El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software.

Cuando se trabaja para construir un producto o un sistema, es importante seguir una

Desde el punto de vista de un ingeniero de software, los productos obtenidos son

2.1.4 Modelos de Desarrollo del Software.

Existen varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya

 Modelo en cascada (modelo tradicional).

En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de

2.4.1 Forma de Trabajo

El algoritmo de trabajo es el siguiente:

Durante cada Sprint (periodo de aproximadamente cuatro semanas) se genera un

 Manejo de Roles para simplificar la identificación de cada uno de los

Se basa en los principios ágiles:

2.4.1.3. Elementos de SCRUM

2.4.1.4. Roles del SCRUM

Product Owner: El Product Owner representa la voz del cliente.

ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo

Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un

Stakeholders (Clientes, Proveedores, Vendedores, etc.): Se refiere a la gente que

Administradores (Managers): Es la gente que establece el ambiente para el

El product backlog: es un documento de alto nivel para todo el proyecto. Contiene

El sprint backlog: es un documento detallado donde se describe el cómo el equipo

2.4.2. Proceso de Desarrollo de la Metodología SCRUM.

2.4.2.1. Modelo de Desarrollo del Trabajo.

Es una metodología de desarrollo de software basada en el modelo iterativo

Figura. 2.1. Modo de Trabajo de la Metodología SCRUM