2da Entrega Proyecto Grupal

MODELOS DE PROCESOS Y LEVANTAMIENTO
DE REQUISITOS DEL SISTEMA
PRESENTADO POR:
KEWUIN DAVID YATE QUESADA

JUAN DAVID CRISTANCHO CASTAÑEDA
JEAN KHALO LOZANO RUIZ
VICTOR MANUELARIAS MORALES
PARA:
DIANA ANGELICA CRUZ ORTEGA
MODULO:
INGENIERIA DE SOFTWARE I
INSTITUCION UNIVERSITARIA POLITECNICO GRAN COLOMBIANO

INGENIERIA DE SOFTWARE
MEDELLIN-2020
1
Contenido
1. INTRODUCCION. .................................................................................................... 1
2. PROPOSITO Y ALCANCE ....................................................................................... 2
2.1. Propósito ............................................................................................................. 2
2.2. Alcance ................................................................................................................ 2
3. OBJETIVOS .............................................................................................................. 3
3.1. Objetivo General ..................................................................................................... 3
3.2. Objetivos Específicos........................................................................................... 3
4. DESCRIPCION DEL PROBLEMA ........................................................................... 4
5. JUSTIFICACION ...................................................................................................... 5
6. MODELOS DE PROCESOS...................................................................................... 6
7.MODELO SELECCIONADO: MODELO DE PROCESOS INCREMENTAL ............... 8
7.1 Ventajas del modelo de proceso incremental .......................................................... 10
7.2 Desventajas del modelo de procesos incremental .................................................... 10
7.3 Riesgos asociados al aplicar el modelo de procesos incremental. ............................ 11
7.3.1 ¿Cómo mitigar los riesgos?.................................................................................. 12
7.3.2 ¿Por qué la elección del modelo de procesos incremental? ................................... 13
7.3.3¿Por qué no elegimos otros modelos de procesos de desarrollo? ........................... 14
8. ACTIVIDADES A DESAROLLAR ............................................................................ 15
8.1 Metodología Scrum ................................................................................................ 15
8.1.1 Roles ............................................................................................................... 15
8.1.2 Scrum Master – Líder del proyecto .................................................................. 15
8.1.3 ProductOwner – cliente ................................................................................... 15
8.1.4 Team – equipo de trabajo (desarrolladores) ...................................................... 16
8.1.5 Users – Usuarios finales .................................................................................. 16
8.2 Artefactos ............................................................................................................... 16
8.2.1 Product Backlog – Lista general de actividades del sistema ............................. 16
8.2.2 Sprint Backlog – Lista de actividades a desarrollar específicas en el Sprint ...... 16
8.2.3 Burndown – Incremento .................................................................................. 17
8.3 Ceremonias ............................................................................................................ 17
8.3.1 Sprint Planning ................................................................................................ 17
8.3.2 Daily Scrum .................................................................................................... 18
8.3.3 Sprint Review .................................................................................................. 18
8.3.4 Retrospective – Retrospectiva del sprint .......................................................... 18
8.4 Herramientas .......................................................................................................... 19
2
8.4.1 Diagrama de Gantt. .......................................................................................... 19
8.4.2 Herramienta Online Trello ............................................................................... 19
9. LEVANTAMIENTO DE REQUISITOS DEL SISTEMA ........................................ 20
9.2 Requerimientos funcionales.................................................................................... 20
9.2 Requerimientos no funcionales observables vía ejecución ...................................... 24
9.3 Especificación de los casos de uso de requerimientos funcionales........................... 29
9.3.1 Registrar profesional........................................................................................ 29
9.3.2 Registrar cliente a través del portal web. .......................................................... 29
9.3.3 Autenticación del usuario. ............................................................................... 30
9.3.4 Buscar profesional de la salud. ......................................................................... 30
9.3.5 Consultar agenda del profesional. .................................................................... 31
9.3.6 Seleccionar agenda disponible del profesional y reservar. ................................ 32
9.3.7 Pagar sesión en línea........................................................................................ 33
9.3.8 Cambiar fecha de la sesión............................................................................... 33
9.3.9 Registro de servicios y agenda del profesional. ................................................ 34
9.3.10 Consultar sesiones agendadas. ....................................................................... 35
9.3.11 Consulta información de clientes agendados. ................................................. 35
9.3.12 Genera reportes.............................................................................................. 36
10. DIAGRAMA DE CLASES .................................................................................... 38
CONCLUSIÓN................................................................................................................ 39
Bibliografía .................................................................................................................. 40
3
LISTA DE TABLAS
Tabla numero 1……………. Pág.6
Tabla numero 2……………. Pág. 7
Tabla numero 10…………. Pág. 32
Tabla numero 13…………. Pág.35
4
LISTA FIGURAS
Figura numero 1……………. Pág. 8
Figura numero 2……………. Pág. 38
5
1. INTRODUCCION.
Gracias a los diferentes aportes que se han dado para el mejoramiento en la calidad del
software, hoy en día se cuenta con diferentes modelos, metodologías, herramientas que
permiten desarrollar un software de calidad, bien estructurados, con sus requerimientos
funcionales y no funcionales definidos y es así como surgen los modelos de procesos
tradicionales y las metodologías de desarrollo ágiles.
En el siguiente proyecto se abordará la necesidad que presenta un cliente en la que requiere
contar con una herramienta que le permita registrar una serie de profesionales de la salud
que ofrecen diferentes servicios de acuerdo con una agenda definida y permitir a los
usuarios en línea buscar el profesional que más se adapta a sus necesidades y agendar una
cita con esta profesional una vez ha realizado el respectivo pago del servicio.
De acuerdo al requerimiento planteado por el cliente se escogerá un modelo de procesos, en
el cual se mencionan algunas de sus características, sus desventajas al compararlo con otros
modelos, se explicarácómo se mitigarán sus riesgos y se justificara su elección.
1
2. PROPOSITO Y ALCANCE
2.1. Propósito
Se creará un software de gestión de profesionales de la salud, proyecto para la
sistematización de registro de profesionales y gestión de servicios de este, en donde se
podrá gestionar su agenda de acuerdo a su disponibilidad horaria del día a día, generar
reportes, administrar datos y realizar pagos de las consultas o servicios que se tomen con
cada profesional.
El propósito del desarrollo de un sistema tal como este es la necesidad de tener la
información de un profesional de manera digital en donde cada proceso que gestione el
profesional sea de manera fácil y rápida de gestionar.
Adicional controlar sus tiempos de disponibilidad para prestar sus servicios de manera
autónoma en donde es el sistema el encargado de realizar estas labores, sin tener que
preocuparse por llevar una agenda el día a día.
2.2. Alcance
El sistema deberá ser capaz de administrar toda la información que lo nutre y generar
reportes de usuarios y profesionales.
Contará con filtros adecuados para mejorar la usabilidad del mismo, y así facilitar la
búsqueda de usuarios y profesionales. Gestionará la agenda del profesional para evitar que
un profesional cuente con citas de pacientes cruzadas.
2
3. OBJETIVOS
3.1. Objetivo General
Investigar y profundizar acerca del modelo incremental para analizar sus beneficios y
contras con el fin de mitigar los problemas que este puede presentar a lo largo del proceso
del desarrollo del software buscando como solucionar y afrontar cada aspecto y/o caso que
se presente para así brindar la mejor solución en el caso expuesto.
3.2. Objetivos Específicos
• Analizar el modelo de proceso más conveniente para el caso presentado.
• Mitigar los problemas que se tienen en la elección del modelo.
• Conocer las ventajas y desventajas del modelo.
• Proponer acciones de mejora que permitan desarrollar software de calidad.
3
4. DESCRIPCION DEL PROBLEMA
Se necesita una herramienta tecnológica que permita registrar una serie de profesionales de
la salud que ofrecen diferentes servicios de acuerdo con una agenda definida y permitir a
los usuarios en línea buscar el profesional que más se adapta a sus necesidades y agendar
una cita previa con esta profesional una vez realizado el respectivo pago del servicio, para
ello se deberá analizar y planificar que se necesitará en el desarrollo de la herramienta
pasando desde un claro análisis con argumentos válidos para concluir cuál es el mejor
modelo a desarrollar y cómo este se relaciona con la metodología scrum para afrontar el
desarrollo del proyecto.
4
5. JUSTIFICACION
Se analizará el comportamiento de los modelos de procesos más comunes en el desarrollo
de software en los que se comparara cual es el mejor y ayudara afrontar el desarrollo de la
idea de negocio, en la que buscamos llegar a concluir y argumentar el por qué es el mejor,
que ventajas y desventajas encontramos en este proyecto con la implementación de este,
igualmente se tendrá en cuenta cómo se relaciona con la metodología scrum. También se
analizará y se propondrá como mitigar estos problemas con el fin de encontrar las mejores
soluciones en caso de llegar a cruzarnos con estas falencias, sin embargo con este
documento lo que más se buscará es argumentar porque el modelo seleccionado es el mejor
para desarrollar, esto necesitará de bastante análisis antes de comenzar a programar ya que
el ingeniero de software deberá analizar, calcular y planificar en un proyecto en presente y
futuro para lograr evidenciar con mayor facilidad que percances encontrará en el desarrollo.
Este proyecto tendrá un equipo de cuatro ingenieros los cuales implementaran la
metodología scrum esto para estar en constante comunicación, pero en una comunicación
asertiva para proponer sus ideas y unir cada una de ellas para tomar una decisión y concluir
cuál es el mejor modelo de procesos en otras palabras cuál es el más conveniente esto como
resultado obtendrá un trabajo colaborativo en el que se aprenderán nuevas maneras de
analizar un proceso claro esto influirá mucho la experiencia en el área de la tecnología y en
caso de no llegar a tenerse experiencia obtendremos nuevos puntos de vista y aportes.
Esta investigación es muy importante para no cometer errores comunes en la planificación
de un software ya que se cree que simplemente es comenzar a programar, sin pensar en que
puede llegar a pasar en un futuro y así mismo se busca hacer notar la importancia de un
ingeniero de software en este tipo de proyectos.
5
6. MODELOS DE PROCESOS
Modelo Descripción
Modelo en ● Ordena exactamente las etapas del ciclo de vida del software, esto significa que
cascada en el inicio de una etapa debe esperar a la finalización de la anterior.
● Su desempeño es factible en proyectos con requisitos claros o cuando se trabaja
con herramientas técnicas.
Modelo en V ● Su representación gráfica que proviene del M. Cascada, solo que establece una
correlación entre los resultados de las actividades de especificación y las de
validación de las mismas.
Modelo Iterativo ● Su objetivo es un crecimiento progresivo de la funcionalidad. Esto quiere decir

Incremental que el producto va evolucionando con las entregas previstas hasta que se
evidencia el modelo de negocio requerido por el cliente.
Modelo Espiral ● Las etapas de este modelo se conforman en una espiral, en la que cada una
representa un conjunto de actividades.
Tabla No. 1 Descripción de los modelos de procesos. Elaboración propia.
En la siguiente tabla se puede analizar algunas ventajas y desventajas que presentan los
diferentes modelos tradicionales, por lo que una vez analizados se elegirá una de ellos para
el desarrollo del proyecto.
Modelo Ventajas Desventajas
Modelo en ● Se basa en la organización de las fases ● Al tener que pasar si o si por el proceso
cascada para que estas no se mezclen en el de prueba ponerle a operar es
ciclo de vida del. demorado ya que este debe estar
● la división de features se facilita en completo.
roles (Personas) independientes.
● Cuando se tienen la totalidad de los
requisitos específicos y las
herramientas a utilizar es totalmente
perfecto para el desarrollo.
Modelo ● Es un modelo útil cuando el cliente ● El usuario puede generar sobre

Prototipos conoce los objetivos generales, pero no expectativas en base a prototipos que
puede definir los detalles finos del tienen poca funcionalidad, pero mucha
sistema. “estética”.
● Favorece la adaptabilidad de un ● El desarrollador podría tomar
sistema en cuanto a usabilidad e decisiones erróneas en cuanto al
interacción persona-computadora. diseño, por implementar versiones
parciales, que serían difíciles de
modificar a futuro
● Los tiempos se minimizan en su ● No es aconsejable su uso para casos de
6
ejecución inicial ya que su procesos de tiempo real, de un gran
Modelo implementación es parcial. nivel de seguridad y/o de alto índice de
Iterativo ● Los modelos iterativos e incrementales riesgos.
Incremental bajan en gran proporción los riesgos. ● Solicita una gran demanda de
Ya que se basan en la planificación, administrativa y técnica.
retroalimentación sobre los avances. ● Sus metas deben ser claras para poder
● Resulta más sencillo acomodar saber sobre el estado del proyecto.
cambios al acotar el tamaño de los
incrementos
● Tiene en cuenta las mejoras y nuevos ● Se necesita de bastante tiempo en el

requerimientos sin desviarse de la desarrollo del proyecto.
Modelo Espiral metodología, ya que este ciclo de vida ● Es costoso –Requiere de un gran
no es rígido ni estático. análisis en la detección de riesgos.
Tabla No. 2 Ventajas y Desventajas de los modelos de procesos. Elaboración propia.
7
7.MODELO SELECCIONADO: MODELO DE PROCESOS INCREMENTAL
Según el blog de programación estructurada dice: “El modelo incremental fue propuesto
por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una
forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de
retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.
Este modelo se conoce también bajo las siguientes denominaciones:
• Método de las comparaciones limitadas sucesivas.

• Ciencia de salir del paso.
• Método de atacar el problema por ramas”
Figura 1: Tomado de: Librado, Bonifacio. Gervacio. (Septiembre 2013). Sistema de seguimiento al crédito(Tesis). Santiago
de Queretaro: Tesis. www.uteq.edu.mx/tesis/ITIC/0303.pdf.
El modelo de procesos que se elegirá para el desarrollo del requerimiento del cliente es el
incremental, ya que se basa en varios ciclos de cascada, pero realimentados, es decir, con
cada ciclo se implementan nuevas funcionalidades al proyecto, lo que permitirá no solo al
equipo de desarrolladores tener un avance en la ejecución del proyecto, sino que permite al
cliente analizar su funcionamiento y en algunas ocasiones operarlo, aunque se tengan
algunas limitaciones.
8
Para que en el desarrollo de un proyecto en cual se utilice el modelo de proceso incremental
es indispensable que sus requerimientos funcionales estén plenamente identificados, lo que
permitirá que en cada incremento se llegue al producto deseado por el cliente.
El modelo incremental permite realizar actividades en paralelo, por ejemplo se puede
realizar el diseño en su primer incremento y a su vez se puede ir realizando el análisis del
segundo, lo que permitirá tener versiones funcionales o no funcionales del software en
desarrollo.
Gracias a que el cliente utiliza partes básicas funcionales del software, este puede ir
aportando retroalimentaciones de uso, lo que hará que el incremento (versión) siguiente se
adapte más a la necesidad real del proyecto.
Un ejemplo del modelo de procesos incremental es el desarrollo de una hoja de cálculo, ya
que al principio permitirá solo almacenar datos en una tabla. En un segundo incremento
permitirá relacionar los datos de cada tabla, graficar datos, realizar operaciones básicas
como sumas, restas, filtros, insertar fórmulas, ecuaciones, por lo que en cada incremento se
irá llegando al producto final.
Una de las cosas más importantes que nos llevó a tomar la decisión de trabajar con el
proceso incremental es el poder trabajar con la metodología Scrum ya que es uno de los
métodos ágiles más populares. ¿Pero qué es scrum? Es un framework adaptable, iterativo,
rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma eficiente a lo
largo del proyecto.
Se puede garantizar una transparencia en la comunicación y se crea un ambiente de
responsabilidad colectiva y de progreso continuo.
9
Partiendo de que el método seleccionado es el incremental, esta metodología nos permitirá
cumplir adecuadamente con los requerimientos y el mínimo valor producto para la entrega.
Al trabajar con esta metodología llevaremos un control de la gestión del proyecto, esto
mediante un cronograma o diagrama de Gantt por Sprint.
7.1 Ventajas del modelo de proceso incremental
Este modelo tradicional presenta las siguientes ventajas que lo hacen más robusto e
iterativo en comparación con los demás.
● Este modelo es muy útil cuando no se cuenta con buen personal para su desarrollo.
● permite realizar evaluaciones en cada incremento.
● Si hay disponibilidad para la entrega se pueden realizar varios incrementos que
permitirán desarrollar un software de calidad.
● Este tipo de proyectos se pueden financiar por partes.
● Es apropiado para proyectos de larga duración.
● Al construir un software pequeño es menos riesgoso, lo que permite corregir los
errores progresivamente.
● Se realizan incrementos en su desarrollo como en su vida operativa.
7.2 Desventajas del modelo de procesos incremental
Las desventajas que encontramos son:

● No es recomendable para proyectos en los que no se cuenta con bastante tiempo.
● Requiere gestores experimentados.
● Requiere tiempo del cliente en cada incremento.

10
7.3 Riesgos asociados al aplicar el modelo de procesos incremental.
El modelo de procesos de desarrollo incremental al igual que, cualquier otro modelo,
cuenta con ciertos riesgos que vienen directamente asociados a las desventajas de este, y a
su vez, a las necesidades que el cliente describe con respecto al producto de software del
sector salud que él requiere, por lo tanto, teniendo en cuenta la necesidad descrita para este
proyecto de software, podemos encontrar los siguientes riesgos:
● Al ser un modelo tan versátil, se puede incurrir en tiempos mayores a los esperados
para la culminación y entrega de este proyecto.
● Al no contar con tiempos definidos se puede incrementar los costos previstos para el
proyecto.
● Si se incrementan los costos previstos en cuanto a tiempo y recursos, las ganancias
podrían ser mínimas o nulas.
● Teniendo en cuenta que, el alcance del proyecto es ambiguo con respecto a los
requisitos del cliente, y siendo que no se puede medir con exactitud, podría resultar
en cobros exorbitantes o demasiado inferiores.
● El cliente no siempre está disponible para las reuniones agendadas, lo cual atrasaría
el avance del proyecto y generaría cuellos de botella.
● La mala planeación de un incremento puede incurrir en reprocesos.
● No se cuenta con un panorama macro de las especificaciones técnicas del proyecto,
por lo tanto, no se puede controlar los avances e incrementos de este.
11
7.3.1 ¿Cómo mitigar los riesgos?
El hecho de que existan riesgos en la planificación del proyecto al aplicar el modelo
de proceso incremental, no quiere decir que, no existan formas de reducir o limitar
el impacto que este pueda generar en la ejecución del proyecto de software, por lo
cual las acciones propuestas para mitigar el impacto que estos riesgos podrían
generar, son las siguientes:
1. Concertar una reunión con el equipo de trabajo, para exponer las necesidades del
cliente, buscar ambigüedades y recomendaciones que se le puedan sugerir.
2. Organizar entrevistas con las partes interesadas, contando con el aval del cliente,
para conocer en detalle su trabajo, con respecto a las necesidades expuestas.
3. Acordar una reunión con el cliente para despejar las dudas relacionadas al
proyecto, teniendo en cuenta las recomendaciones y ambigüedades encontradas.
Al tener claridad en el alcance, se puede ser más preciso en tiempos y costos del
proyecto de software.
4. Programar reuniones semanales siendo flexibles con el cliente, para que este
pueda agendar cualquier día de la semana, generando incrementos constantes en
el proyecto y no se produzcan cuellos de botella. Se debe establecer una persona
como contacto con el cliente, que esté disponible para reuniones extraordinarias.
5. Establecer un equipo experimentado, para que diseñen con exactitud los
artefactos y sean capaces de transmitir los requerimientos al resto del equipo.
También debe saber interpretar al cliente, para que con cada incremento no se
12
generen re-procesos.
6. Asignar el proyecto a un equipo de trabajo hábil, con experiencia y buena
comunicación, logrando así ser más precisos con los tiempos y costos que se
generaran al diseñar y desarrollar el producto.
7. Aplicar una metodología ágil, como por ejemplo scrum, que, aplicada al modelo
incremental, puede dar un control más preciso de las tareas, avances e
incrementos del proyecto.
7.3.2 ¿Por qué la elección del modelo de procesos incremental?
La elección del modelo de procesos incremental, para este proyecto de software, se debe a
que este se ajusta más a la caracterización de la necesidad del cliente, y a nosotros como
empresa de software nos beneficia para brindar un mejor servicio. Este modelo también
aporta más ventajas que desventajas, puesto que de todas las desventajas que puede tener el
modelo, muy pocas afectan al proyecto, al contrario de las ventajas que sí aplican en su
mayoría e impactan de manera positiva, para que este sea exitoso. Además, las estrategias
que hemos analizado para mitigar los riesgos asociados a nuestra elección son efectivas,
para que el porcentaje de éxito sea mayor con relación al de fracaso, culminando así en un
producto funcional, ajustándose realmente a las necesidades del cliente, y siendo la mejor
herramienta para los stakeholders (partes interesadas) en su proceso día a día.
Consideramos que, con relación a los otros modelos que deben tener todos los
requerimientos para empezar a desarrollar, este nos permite ser flexibles e iniciar sin la
totalidad de estos, permitiéndonos terminar el proyecto en menor tiempo, lo cual beneficia
a ambas partes.
13
7.3.3¿Por qué no elegimos otros modelos de procesos de desarrollo?
Los otros modelos, desde nuestro análisis, no tuvieron la viabilidad suficiente para
aplicarlos a nuestro proyecto de software, ya que estos generarían mayores desventajas. La
razón principal, es que los posibles riesgos serían mayores, y difíciles de mitigar, generando
así, mayor tiempo y costo, encaminándonos hacia el fracaso, lo cual no beneficiaría ni al
cliente, ni a la empresa desarrolladora.
El modelo en cascada no es funcional, para este proyecto, porque el cliente es ambiguo y
poco específico al describir sus necesidades, en cambio el modelo tiende a ser muy rígido
en sus fases, podríamos incurrir en mayores tiempos y costos, al tener que realizar algún
cambio durante la ejecución del proyecto.
El modelo de procesos por prototipos tampoco nos funcionaria al aplicarlo a este proyecto,
ya que este se basa en mostrar mockups (prototipos) sin funcionalidad al cliente, este podría
malinterpretar el alcance o las dificultades al diseñar y desarrollar el producto, lo que
podría conllevar a concertaciones fallidas o conflictos con el cliente, corriendo el riesgo de
que se cancele el proyecto.
El modelo de procesos en espiral al ser basada en flujo de procesos evolutivos, tampoco nos
resultó como la mejor opción, ya que además de requerir prototipos, al igual que el modelo
anterior, requiere interacciones frecuentes, lo que conlleva a agendar reuniones constantes
con el cliente, esto podría ser molesto y poco eficiente, pues se debe contar con el tiempo
de este, y no es factible asumir que siempre tendrá la disponibilidad para múltiples
reuniones.
14
8. ACTIVIDADES A DESAROLLAR
Para la implementación y puesta en marcha de la aplicación que permita al cliente
administrar las citas médicas dentro de una clínica; se realizará una integración de algunos
aspectos de la metodología ágil de Scrum, junto con algunos aspectos de RUP, por lo que
se obtendrá un producto con de gran calidad al combinar estas dos metodologías dentro de
un mismo proyecto.
Ahora explicaremos algunos aspectos de la metodología Scrum en nuestro proyecto.
8.1 Metodología Scrum
8.1.1 Roles
La metodología ágil Scrum dará como garantía una correcta planificación y gestión del
proyecto, usando esta metodología se pondrá un orden a las entregas y avances del
proyecto. Para sacar un producto de calidad es indispensable que cada persona tome foco
en sus actividades y así beneficiar el negocio, algunos de los roles que usaremos serán los
siguientes:
8.1.2 Scrum Master – Líder del proyecto
Será la persona encargada de agilizar el trabajo del equipo quitando bloqueos, negociando
con el cliente, esta persona mantendrá un buen ánimo al equipo y así mismo evitando que
un tercero pida cosas extras del scope inicial. A su vez deberá provocar que el equipo auto
gestione actividades.
8.1.3 ProductOwner – cliente
Será el cliente, velará por sus beneficios de empresa, decidirá funcionalidades, será la
persona encargada de revisar en cada iteración y proponer mejoras, priorizando historias.

15
8.1.4 Team – equipo de trabajo (desarrolladores)
Serán los encargados de desarrollar las historias usando conocimientos técnicos; la
productividad se verá reflejada en cada sprint.
8.1.5 Users – Usuarios finales
Serán las personas que usarán lo que se desarrolló o se está realizando. Básicamente sus
actividades son disfrutar del sistema desarrollado.
8.2 Artefactos
Los artefactos son aquellos que van a garantizar la transparencia y organización de las
actividades a realizar en el desarrollo del sistema. A continuación, se relaciona una lista de
los diferentes artefactos a realizar
8.2.1 Product Backlog – Lista general de actividades del sistema
Será el documento de alto nivel para todo el proyecto, contendrá descripciones genéricas de
todos los requerimientos, funcionalidades etc. Se hará una lista ordenada del proyecto
general a desarrollar en donde especificaremos las necesidades del cliente de forma
prioritaria, este será el único canal para incluir más actividades. En esta lista estarán todas
las actividades a desarrollar según los requerimientos del cliente.
8.2.2 Sprint Backlog – Lista de actividades a desarrollar específicas en el Sprint
El sprint backlog será el documento detallado donde describiremos cómo el equipo va a
implementar los requisitos durante el sprint y así mismo tendremos el conjunto de
actividades que realizaremos durante el Sprint, haremos sprint de dos semanas, día a día
16
desmenuzamos estas actividades y así daremos una mayor garantía a terminar los ítems
especificados.
8.2.3 Burndown – Incremento
Se hará una gráfica que será mostrada públicamente en donde medirá la cantidad de
requisitos en el Backlog del proyecto, esta nos ayudará a identificar los requisitos
pendientes al comienzo de cada sprint, conectaremos los puntos de todos los Sprints
completados, y podremos ver el progreso del proyecto. Lo normal es que esta línea sea
descendente, hasta llegar a el eje horizontal, momento en el cual el proyecto se ha
terminado.
8.3 Ceremonias
8.3.1 Sprint Planning
Se hará un ciclo de 15 días 2 semanas por Sprint, el lunes de cada ciclo dará el lugar para
realizar esta reunión. En esta reunión se encargará de planificar el trabajo que se hará
durante el sprint, se analizará prioridades y se focalizará en estas. Una vez definidas las
actividades a realizar lo que se hará es puntuar estas actividades a nivel de equipo en donde
todos tendremos que estar de acuerdo para la asignación de tiempo a esa actividad en
concreto. Esto definirá la velocidad del sprint y lo que conseguiremos en ese ciclo. Se
tendrá un margen de contingencia por si algún integrante del equipo tiene alguna dificultad
para desarrollar la actividad no nos afecte la velocidad del sprint de cara al cliente.
17
8.3.2 Daily Scrum
Esta será la reunión que se ejecutará a diario y básicamente su función es mantener un
estatus del trabajo a nivel equipo, se hará a modo rápido y se responderán las siguientes 3
preguntas:
● ¿Qué has hecho desde ayer?
● ¿Qué es lo que estás planeando hacer hoy?
● ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
Esta reunión deberá iniciar puntualmente en la mañana antes de empezar la labor será
siempre en la misma ubicación y a la misma hora todos los días.
8.3.3 Sprint Review
Esta reunión tendrá una duración como máximo de 4 horas en donde se buscará un
feedback de los representantes tanto el productowner como el equipo de desarrollo, en esta
se comentará las actividades realizadas y veremos los avances del proyecto. También se
analizarán las actividades que no fueron realizadas o completadas, las actividades que no
están totalmente terminadas o completadas no pueden ser mostradas en esta reunión hasta
culminarlas.
8.3.4 Retrospective – Retrospectiva del sprint
Se busca analizar cómo fue en el Sprint terminado para dar más agilidad a los que vienen.
Como propósito es realizar una mejora continua del proceso. El tiempo límite será de 4H.
18
8.4 Herramientas
El hacer un plan de proyecto basándonos en una metodología nos ha llevado a buscar las
mejores herramientas para el desarrollo del software por lo cual a nivel de gestión usaremos
lo siguiente:
8.4.1 Diagrama de Gantt.
Este servirá para controlar tiempos de cara al cliente, si seguimos un planning de inicio a
fin el evolutivo se va ver reflejado correctamente, pero si el cliente llegase a pedir
requerimientos extra scope este documento nos será clave para que el cliente se dé cuenta
que hay prioridades en tiempos y sólo si él lo decide será uno primero que otro, el diagrama
nos servirá para reflejar estas alteraciones.
8.4.2 Herramienta Online Trello
Este tablero será clave para el flujo del desarrollo ya que tendremos los diferentes artefactos
expresado en columnas y nos será fácil gestionarlo en cada daily scrum ya que asignaremos
actividades a cada integrante del equipo y podremos ver el tiempo estimado vs el tiempo de
ejecución. De esta manera controlaremos que todo el equipo vaya a una velocidad
adecuada.
19
9. LEVANTAMIENTO DE REQUISITOS DEL SISTEMA
9.2 Requerimientos funcionales
ID Requerimiento Descripción
Con el rol de administrador ingresar al sistema,
y seleccionar la opción de registrar profesional,
los datos obligatorios que deben ir en el
formulario de registro son:
● Nombre completo.
● Tipo de servicios que ofrece.
● Dirección
● Teléfono
● Costo de los servicios.
Registrar profesional. ● Horario de atención.

RF001
● Agenda y tiempo por sesión.
● Si puede atender a varios usuarios a la
vez.
● Tipo Identificación,
● Número Identificación
● Número Identificación
Se guardan los datos, estos se crear con el rol
“Profesional en salud”, muestra al usuario “Los
datos se guardaron exitosamente”.
20
El cliente ingresa al portal web y selecciona la
opción registrar, cargará un formulario con los
siguientes datos obligatorios para el registro:
● Nombre completo.
● Género.
● Edad (fecha de nacimiento).
● Teléfono
● Dirección de residencia.
● Tipo de documento.
RF002 Registrar clientes.
● Número de documento.
● Correo electrónico.
Después de guardar los datos le mostrará el
siguiente mensaje “Los datos se guardaron
exitosamente”, y lo llevará a otra ventana donde
mostrará el mensaje valide su correo para
terminar con el registro.
También mostrará el link de volver a enviar
correo.
El usuario debe ingresar sus credenciales al
sistema, para que estos datos sean validados, y
RF003 Validar Usuario si tiene permisos ingresa al sistema o de lo
contrario le impide el acceso mostrando una
alerta de “Usuario y contraseña incorrecto”,
21
después debería redirigirlo a la vista pertinente
según su rol.
El cliente debe ingresar en los criterios de
búsqueda los datos requeridos:
● Nombres.
RF004 Buscar profesional
● Tipo de servicio.
● Ubicación.
Presiona buscar y encuentra las coincidencias.
Permite al cliente conocer la funcionalidad de la

Ver detalles de la
RF005 RF005, seleccionar un profesional y consultar
agenda del profesional.
su agenda, además de ver los detalles de esta.
En ver el detalle de la agenda del profesional

Seleccionar una sesión
RF006, seleccionar en las diferentes citas la que
disponible de la agenda
RF006 esté disponible y cliente poder reservar, el
del profesional y
sistema guarda la reserva y la bloquea para los
reservar.
demás clientes.
Con respecto a la RF007 permite pagar la sesión
reservada, selecciona el medio de pago, lo
RF007 Pagar la sesión en línea. redirige a la ventana del servicio de pago
seleccionado, realiza el pago y devuelve la
respuesta del sistema externo de pago y
22
confirma el pago en nuestro sistema.
De la sesión agendada en la RF007, consultar
las fechas disponibles por el profesional y poder
Cambiar fecha de la seleccionar alguna que esté disponible y

RF008
sesión agendada. reagendar, en el sistema, además el sistema
libera la sesión seleccionada primeramente por
el cliente.
El profesional ingresa al sistema ingresa la
opción de agenda y servicios, muestra el detalle
de su agenda, selecciona crear sesión y muestra

Registro de servicios y
RF 009 el formulario obligatorio para crear la sesión, si
agenda del profesional.
cumple con los criterios del formulario guarda
la sesión en un horario disponible, para evitar el
cruce de fechas.
Permite al profesional de la salud ver los
Consultar sesiones detalles de su agenda creadas en la RF010,

RF010
agendadas. selecciona la opción ver agenda, consulta la
agenda creada y la organiza por fecha.
Consultar la Al consultar la opción ver agenda de la RF011,
RF011 información de los también permite ver el detalle de cada sesión y
clientes agendados. verificar si la está ocupada por un cliente y ver
23
los detalles de esta.
El administrador o a quien competa, podrá
ingresar a la opción generar reportes, desde el
cual podrá tener una lista desplegable de
diversos reportes solicitados por el cliente,

RF012 Generar reportes.
después de seleccionado presionar generar
reporte, y mostrará en la vista el reporte
solicitado, además habilita la opción de
descargar reporte.
Tabla 3. Fuente de elaboración: Propia
9.2 Requerimientos no funcionales observables vía ejecución
Atributo de calidad Descripción
El sistema contará con una disponibilidad del 99.9% las 24/7,
porque es necesario que se pueda ejecutar cualquier operación en
cualquier momento por parte del administrador, profesional de la
Disponibilidad salud o cliente.
El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 10
minutos.
El promedio de duración de fallas no podrá ser mayor a 20 minutos.
El sistema contará con altos estándares de seguridad, y esta no podrá

Confidencialidad
ser accedida por cualquier persona sin autorización.
24
El sistema será desarrollado por un excelente equipo el cual aplicará
Funcionalidad las mejores prácticas en su código y esto evitará los bugs en la
aplicación.
Se realizarán pruebas estrictas de calidad y estrés para determinar
que el software cuente con la mejor optimización posible.
Toda funcionalidad del sistema y transacción de negocio debe
responder al usuario en menos de 5 segundos.

Desempeño
El sistema debe ser capaz de operar adecuadamente con hasta
10.000 usuarios con sesiones concurrentes.
Los datos modificados en la base de datos deben ser actualizados
para todos los usuarios que acceden en menos de 2 segundos.
El sistema contará con la mejor infraestructura y además con una
garantía de 5 años, lo cual asegura que el software a pesar de los
años funcionará en las mejores condiciones.
El tiempo de aprendizaje del sistema por un usuario deberá ser
Confiabilidad menor a 4 horas.
El sistema debe contar con manuales de usuario estructurados
adecuadamente.
El sistema debe proporcionar mensajes de error que sean
informativos y orientados al usuario final.
25
Se realizará una copia de seguridad constante de la información en
una Base de Datos secundaria, también conocida como datos espejo,
que realizará una copia programada diaria en las horas de menos
tráfico de información, para asegurar que la información sea
mantenida con un lapso de 24 horas, y está se realizará en un lugar
diferente al del almacenamiento principal.
El nuevo sistema y sus procedimientos de mantenimiento de datos

Seguridad externa
deben cumplir con las leyes y reglamentos de protección de datos
médicos.
Las páginas web a ser desarrolladas deben cumplir con la ley de
tratamiento en condiciones de igualdad para personas con
discapacidad.
El sistema no revelará a sus operadores otros datos personales de los
clientes distintos a nombres y números de referencia.
El software contará con la mejor encriptación de información de
punta a punta para asegurar que no haya filtros de información y
adicionalmente evitar el acceso no autorizado de personas indebidas.
Los permisos de acceso al sistema podrán ser cambiados solamente

Seguridad interna
por el administrador de acceso a datos.
Si se identifican ataques de seguridad o brecha del sistema, el
mismo no continuará operando hasta ser desbloqueado por un
administrador de seguridad.
26
Atributo de calidad Descripción
Se contará con personal capacitado en administración de bases de
datos, con permisos para realizar cambios permitidos en esta, para

Configurabilidad
dar soporte a las solicitudes del cliente, lo cual permitirá hacer
ajustes en caliente.
Ya que la aplicación estará desarrollada a base de contenedores, se
tendrá en cuenta la integración de cada contenedor que tendrá por

Integralidad
separado base de datos, servidor de aplicaciones, motor de indexado,
etc., esto con el fin de controlar el software de la mejor manera.
La integridad de la información se maneja con los mejores estándares
de encriptado de información y la base de datos contará con los

Integridad
estándares de campos y estructura para mantener integra la
información.
El sistema será desarrollado multiplataforma, por lo tanto, este se
podrá ejecutar en diferentes sistemas operativos, que cuenten con los

Interoperabilidad
diferentes navegadores del mercado, además que la interfaz será
responsiva, para que se ajuste hasta dispositivos móviles.
El sistema será desarrollado por profesionales en desarrollo de
software que apliquen las mejores prácticas, además que
Modificabilidad implementen la POO y los principios SOLID, de esta manera
podemos asegurar de que la aplicación reciba cambios sin ser
traumáticos a la hora de realizarlos.
27
El sistema será desarrollado por profesionales en desarrollo de
software que apliquen las mejores prácticas, además que
implementen la POO y los principios SOLID, de esta manera
Mantenibilidad podemos asegurar de que la aplicación reciba cambios sin ser
traumáticos a la hora de realizarlos, por consiguiente, se reducirán
costos al realizar cualquier cambio, este podrá evolucionar y además
estos se podrán hacer de manera rápida.
El sistema podrá ejecutarse en cualquier sistema operativo que
cuente con un navegador cualquiera del mercado, adicionalmente la

Portabilidad
interfaz de usuario será diseñada responsiva para que en dispositivos
móviles se pueda adaptar.
El sistema será desarrollado implementando las mejores prácticas la
POO y los principios SOLID, lo cual asegura que de esta se pueda

Reusabilidad
tomar fragmentos de código que pueden ajustarse a otro software
similares.
El modelo de datos del sistema será creado de tal manera de que, si a
futuro requiere algún ajuste por datos faltantes, o que a futuro sean
Escalabilidad
exigidos por ley, estos se pueden agregar si afectan el
funcionamiento actual del sistema.
Durante el desarrollo del software se realizarán pruebas unitarias y
Capacidad de automatizadas para determinar que el producto que se vaya a
pruebas desplegar a producción cuente con los mejores estándares de calidad
y sus fallas sean mínimas o nulas.

28
9.3 Especificación de los casos de uso de requerimientos funcionales.
9.3.1 Registrar profesional.

ID: Registrar Profesional
R.F 001
Registrar profesional – Crear cuenta
de Usuario.
Caso de Uso
Actores Administrador, Profesional en salud.
Propósito Crear una nueva cuenta de usuario
Precondición 1. El administrador tiene la sesión iniciada.

2. Ingresar datos obligatorios.
1. Los datos se han guardado exitosamente.
2. Se ha presentado un error al momento de guardar los datos.
Postcondición
Descripción El administrador del sistema crea una cuenta de usuario.
Flujo Básico 1. Los datos se guardaron exitosamente
Flujo 1. La cuenta Usuario ya existe.

Alternativo 2. Ya existe una cuenta asociada al mismo correo electrónico.
9.3.2 Registrar cliente a través del portal web.

ID: Registrar Cliente R.F
002
Registro del cliente a través del portal
web
Caso de Uso
Actores Administrador – Cliente.
Propósito Registrar un nuevo cliente a través del portal web.
Precondición 1. El administrador tiene la sesión iniciada.

2. Ingresar los datos obligatorios exigidos por el portal web.
Postcondición 1. Los datos se guardaron exitosamente
29
2. Valide su mensaje para continuar con el registro.
Descripción El cliente crea su cuenta de registro al sistema.
Flujo Básico 1. Los datos se guardaron exitosamente
Flujo 1. La cuenta Usuario ya existe.

Alternativo 2. Ya existe una cuenta asociada al mismo correo electrónico.
9.3.3 Autenticación del usuario.

ID: Autenticar Usuario R.F
003
Caso de Uso Autenticación de usuario
Actores Usuarios o Clientes.
Propósito Verificación de autenticación de ingreso usuario.
Precondición Contar con un nombre de usuario y contraseña.
Postcondición 1. La sesión se inició en el sistema.

2. Se validaron los datos de ingreso al sistema y son
incorrectos.
Descripción El usuario o cliente utiliza sus credenciales de autenticación para dar
inicio a sesión en el sistema.
Flujo Básico La validación de usuario es correcta.
Flujo Las credenciales son incorrectas

Alternativo
9.3.4 Buscar profesional de la salud.

ID: Buscar Profesional R.F
004
Caso de Uso Buscar profesionales de la salud
30
Actores Cliente.
Propósito El cliente o usuario al momento de agendar su cita debe de buscar al

profesional de la salud disponible.
Precondición 1. Estar registrado en el portal web.
Postcondición 1. Los datos ingresados no tienen coincidencias.
Descripción El cliente o usuario debe de ingresar los datos del profesional

asignado: Nombres, tipo de servicio y ubicación. Dar clic en buscar
y aparecerán las coincidencias.
Flujo Básico Los datos del profesional de salud ingresados coincidieron con la
búsqueda.
Flujo No se encontraron coincidencias.

Alternativo
9.3.5 Consultar agenda del profesional.

ID: Agendar Profesional
R.F 005
Caso de Uso Consultar agenda del profesional
Actores Cliente _ Profesional _ Administrador.
Propósito Consultar agenda del profesional de la salud.
1. Cliente registrado.
31
2. Inicio de sesión.
3. Que el cliente o usuario realice la búsqueda del profesional,
primeramente.
4. Coincidencias de búsqueda del profesional.
Precondición
Postcondición 1. Se consulta la agenda del profesional de la salud.
Descripción Consultar un profesional de la salud, ver su agenda y detalles de la

misma.
Flujo Básico 1. La cita ha sido agendada, en la fecha y profesional indicado.
Flujo N.A.
Alternativo
9.3.6 Seleccionar agenda disponible del profesional y reservar.

ID: Seleccionar Agenda por
profesional. R.F 006
Seleccionar agenda disponible de la

profesional y reservar
Caso de Uso
Actores Cliente Administrador.
El cliente selecciona la agenda del profesional de la salud

disponible, escoge un horario y reserva. Este automáticamente se
Propósito bloquea para los demás clientes.
Precondición 1. Inicio de sesión.

2. Escoger profesional de la salud.
Postcondición 1. Cita reservada.
2. Se obtuvieron los datos solicitados.
Descripción El portal web debe mostrar la agenda completa del profesional de la
salud.
Flujo Básico 1. Reserva Guardada y Bloqueada para los demás clientes.

Flujo N. A
32
Alternativo
9.3.7 Pagar sesión en línea.

ID: Pagó Sesión R.F 007
Caso de Uso Pagar sesión en línea
Actores Cliente - Administrador.
Propósito Pagar la sesión a través del portal web
Precondición 1. Inicio de sesión.

2. Escoger profesional de la salud.
3. Reservar cita
4. Seleccionar medio de pago.
Postcondición 1. Cita reservada.
2. Pago
Descripción El cliente una vez tenga la reserva con el profesional de la salud en
el horario indicado, procede a pagar la sesión por medio del portal
web.
Flujo Básico 1. Pago confirmado en nuestro sistema
Flujo 1. Pago rechazado.

Alternativo
9.3.8 Cambiar fecha de la sesión.

ID: Cambiar Fecha sesión.
R.F 008
Caso de Uso Cambiar fecha de sesión
Actores Cliente – Administrador.
Propósito Cambiar la fecha de sesión de un cliente.
33
Precondición 1. El usuario debe de estar registrado en el sistema
2. Iniciar sesión.
Postcondición N. A
Descripción El portal web debe permite cambiar la hora de la cita de un paciente

o eliminarla
1. El cliente desea realizar el cambio de fecha de una sesión.

2. Detallar la agenda del profesional asignado.
Flujo Básico 3. Modificar fecha, Reagendar.
Flujo 1. El cliente cancela la opción.
Alternativo 2. El sistema no puede realizar cambio de horario, existe un
conflicto, con la fecha y hora del nuevo registro.
9.3.9 Registro de servicios y agenda del profesional.

ID: Registro de Servicios.
R.F 009
Registro de servicios y agenda del
profesional
Caso de Uso
Actores Profesional de la salud
Propósito El profesional de la salud debe autorizar registro de servicios y

agenda.
Precondición 1. Inicio de sesión por parte del profesional de la salud.

2. Debe seleccionar la opción agenda y servicios.
3. selecciona crear sesión y muestra el formulario obligatorio
para crear la sesión.
Postcondición 1. sí cumple con los criterios del formulario guarda la sesión en
un horario disponible, para evitar el cruce de fechas.
Descripción El portal web deberá de mostrar la agenda completa y los servicios
asignados al profesional de la salud.
Flujo Básico Si cumple con los requisitos, guardar formulario en el horario

disponible
34
Flujo N. A
Alternativo
9.3.10 Consultar sesiones agendadas.

ID: Consultar Sesión
Agendada. R.F 010
Caso de Uso Consultar sesiones agendadas
Actores Profesional de la salud.
Propósito Permite consultar al profesional las sesiones agendadas.
1. Profesional registrado en el sistema

2. Inicie sesión.
Precondición 3. Contar con agenda programada.
Postcondición 1. Permitir ver los detalles de la agenda creada.
Descripción Consultar sesiones agendadas del profesional de la salud.
Flujo Básico Ver los detalles de las sesiones, consultar la agenda y organizar por
fecha.
Flujo N. A
Alternativo
9.3.11 Consulta información de clientes agendados.

ID: Consultar Clientes Agendados.
R.F 011
Caso de Uso Consultar la información de

clientes agendados
35
Actores Profesional de la salud – Administrador.
Propósito Consultar información de clientes.
Precondición 1. Registro en el sistema

2. Inicio de sesión por parte del profesional de la salud.
Postcondición N. A
Descripción El sistema permite consultar la información de los clientes

agendados.
Flujo Básico Detallar en el informe generado la información de los clientes

agendados.
Flujo Cancelar la operación.

Alternativo
9.3.12 Genera reportes.

ID: Generar Reportes. R.F
012
Caso de Uso Generar Reportes
Actores Profesional de la salud – Administrador.
Propósito Generar los reportes de las sesiones realizadas a clientes.
Precondición 1. El Usuario debe estar autorizado en el sistema
Postcondición N. A
Descripción El sistema debe generar entregar información de todas las sesiones

que se realizaron.
1. El administrador o usuario autorizado quiere obtener un

reporte.
36
2. El sistema presenta la opción de generar reporte dado por un
Flujo Básico rango de fecha.
3. El administrador generar el reporte.
4. El sistema solicita fecha de inicio y fecha final.
5. Genera el reporte del día, mes o años
Flujo 1. El administrador cancela la operación
Alternativo 2. El sistema muestra mensaje de error, por fechas no válidas.
37
10. DIAGRAMA DE CLASES
Figura 2. Fuente de elaboración: Propia
38
CONCLUSIÓN
El análisis del proyecto que realizamos ha contribuido de manera muy importante para
identificar y resaltar los requerimientos que hay que cubrir y considerar para llevar a cabo
una implementación exitosa del sistema de información.
Nos deja muchas cosas importantes que reflexionar y muchas otras se han ido reforzando
con una buena identificación del problema para llevar a cabo una buena implementación.
Adicional consideramos que una de las cosas más importantes de todas es llevar a cabo
antes que nada una planeación de lo que se quiere realizar y que se espera obtener cuando
se lleve a cabo un proyecto, por ende, se debe desarrollar una evaluación correcta de las
posibles alternativas que se tengan antes de iniciar cualquier cosa, tanto del producto que se
va a adquirir así como también de los posibles caminos para hacer la implementación del
mismo.
39
Bibliografía
1. Pressman, R. (2010). Ingeniería del software. (7a. ed.) McGraw-Hill
Interamericana. Tomado de https://www-ebooks7-24-
om.loginbiblio.poligran.edu.co/?il=686
2. https://sites.google.com/site/programacion1electronica/metodologias-de-desarrollo-
de-software/modelo-incremental-o-evolutivo
3. Librado, Bonifacio. Gervacio. (Septiembre 2013). Sistema de seguimiento al crédito
(Tesis). Santiago de Queretaro: Tesis. www.uteq.edu.mx/tesis/ITIC/0303.pdf.
4. Colaboradores de Wikipedia. (2020, 21 mayo). Desarrollo en espiral. Wikipedia, la
enciclopedia libre. https://es.wikipedia.org/wiki/Desarrollo_en_espiral
5. Características y fases del modelo incremental | OBS Business School. (2019). OBS
Business School. https://obsbusiness.school/int/blog-project-
management/metodologias-agiles/caracteristicas-y-fases-del-modelo-incremental
6. Tabla comparativa modelos. (s. f.). [Tabla comparativa acerca de los modelos de
procesos del ciclo de vida del software].
https://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is02b-
Tabla%20Comparativa%20Modelos.pdf.
7. https://sites.google.com/site/programacion1electronica/metodologias-de-desarrollo-
de-software/modelo-incremental-o-evolutivo) recuperado el 26/07/2020 14:10
40

2da Entrega Proyecto Grupal

Cargado por

Copyright:

Formatos disponibles

2da Entrega Proyecto Grupal

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

2da Entrega Proyecto Grupal

Cargado por

Copyright:

Formatos disponibles

MODELOS DE PROCESOS Y LEVANTAMIENTO

DE REQUISITOS DEL SISTEMA

KEWUIN DAVID YATE QUESADA

DIANA ANGELICA CRUZ ORTEGA

INSTITUCION UNIVERSITARIA POLITECNICO GRAN COLOMBIANO

Tabla numero 1……………. Pág.6

Tabla numero 2……………. Pág. 7

Tabla numero 3……………. Pág. 20

Tabla numero 4……………. Pág. 24

Tabla numero 5……………. Pág.29

Tabla numero 6……………. Pág. 30

Tabla numero 7……………. Pág. 30

Tabla numero 8……………. Pág. 31

Tabla numero 9……………. Pág.32

Tabla numero 10…………. Pág. 32

Tabla numero 11…………. Pág. 33

Tabla numero 12…………. Pág. 34

Tabla numero 13…………. Pág.35

Tabla numero 14…………. Pág. 35

Tabla numero 15…………. Pág. 36

Tabla numero 16…………. Pág. 37

Figura numero 1……………. Pág. 8

Figura numero 2……………. Pág. 38

permiten desarrollar un software de calidad, bien estructurados, con sus requerimientos

funcionales y no funcionales definidos y es así como surgen los modelos de procesos

tradicionales y las metodologías de desarrollo ágiles.

En el siguiente proyecto se abordará la necesidad que presenta un cliente en la que requiere

De acuerdo al requerimiento planteado por el cliente se escogerá un modelo de procesos, en

modelos, se explicarácómo se mitigarán sus riesgos y se justificara su elección.

Se creará un software de gestión de profesionales de la salud, proyecto para la

sistematización de registro de profesionales y gestión de servicios de este, en donde se

El propósito del desarrollo de un sistema tal como este es la necesidad de tener la

información de un profesional de manera digital en donde cada proceso que gestione el

profesional sea de manera fácil y rápida de gestionar.

preocuparse por llevar una agenda el día a día.

reportes de usuarios y profesionales.

un profesional cuente con citas de pacientes cruzadas.

3.1. Objetivo General

se presente para así brindar la mejor solución en el caso expuesto.

3.2. Objetivos Específicos

• Analizar el modelo de proceso más conveniente para el caso presentado.

• Mitigar los problemas que se tienen en la elección del modelo.

• Conocer las ventajas y desventajas del modelo.

• Proponer acciones de mejora que permitan desarrollar software de calidad.

ello se deberá analizar y planificar que se necesitará en el desarrollo de la herramienta

desarrollo del proyecto.

Se analizará el comportamiento de los modelos de procesos más comunes en el desarrollo

de software en los que se comparara cual es el mejor y ayudara afrontar el desarrollo de la

que ventajas y desventajas encontramos en este proyecto con la implementación de este,

igualmente se tendrá en cuenta cómo se relaciona con la metodología scrum. También se

documento lo que más se buscará es argumentar porque el modelo seleccionado es el mejor

el ingeniero de software deberá analizar, calcular y planificar en un proyecto en presente y

Este proyecto tendrá un equipo de cuatro ingenieros los cuales implementaran la

resultado obtendrá un trabajo colaborativo en el que se aprenderán nuevas maneras de

analizar un proceso claro esto influirá mucho la experiencia en el área de la tecnología y en

caso de no llegar a tenerse experiencia obtendremos nuevos puntos de vista y aportes.

Esta investigación es muy importante para no cometer errores comunes en la planificación

ingeniero de software en este tipo de proyectos.

Modelo Iterativo ● Su objetivo es un crecimiento progresivo de la funcionalidad. Esto quiere decir