1

ANÁLISIS Y DISEÑO DE UN PRODUCTO DE SOFTWARE

Lyda P. Lara Dimate

Leidy X. Beltrán Biñez

Félix Pardo Rivera

Miguel A. Gutiérrez García

Yeison M. Noriega Amaya

Ingeniería de Software I

Institución Universitaria Politécnico Gran Colombiano

 2

INDICE

Introducción ............................................................................................................................................... 4
Proceso de Software .................................................................................................................................. 5
Modelos de proceso de Desarrollo de Software ................................................................................... 5
Metodología Scrum ............................................................................................................................... 6
¿Por qué escoger esta metodología? .................................................................................................... 6
Porque no se escogió otra metodología ................................................................................................ 7
Porque no usar el método Tradicional .................................................................................................. 7
Riesgos asociados a la metodología Scrum ........................................................................................... 8
Estrategias para gestionar dichos riesgos.............................................................................................. 9
Planteó las siguientes estrategias.......................................................................................................... 9
Requerimientos Funcionales ...................................................................................................................10
Información de Requerimientos funcionales ..........................................................................................10
Identificación del requerimiento RF-01 ...............................................................................................10
Especificación de Casos de Uso ...........................................................................................................10
Curso Normal .......................................................................................................................................11
Cursos Alternos ....................................................................................................................................11
Curso Normal .......................................................................................................................................11
Cursos Alternos ....................................................................................................................................12
Identificación del requerimiento RF-02 ...............................................................................................12
Curso Normal .......................................................................................................................................12
Cursos Alternos ....................................................................................................................................12
Identificación del requerimiento RF-03 ...............................................................................................13
Especificación de Casos de Uso ...........................................................................................................13
Curso Normal .......................................................................................................................................13
Cursos Alternos ....................................................................................................................................14
Especificación de Casos de Uso ...........................................................................................................14
Curso Normal .......................................................................................................................................14
 3

Cursos Alternos ....................................................................................................................................15

Identificación del requerimiento RF-04 ...............................................................................................15
Especificación de Casos de Uso ...........................................................................................................15
Curso Normal .......................................................................................................................................15
Cursos Alternos ....................................................................................................................................16
Identificación del requerimiento RF-05 ...............................................................................................16
Especificación de Casos de Uso ...........................................................................................................17
Curso Normal .......................................................................................................................................17
Cursos Alternos ....................................................................................................................................23
Requerimientos no funcionales ...............................................................................................................18
Diagrama de Clase .......................................................................................................................................19
Diagramas de Secuencia ..............................................................................................................................20
Csu 1 Registrar Usuario ........................................................................................................................20
Csu 2 Inicio de Sesion...........................................................................................................................21
Csu 3 Agendar Citas .............................................................................................................................22
Diagrama de Estado .....................................................................................................................................23
Csu 1 Registrar Usuario ........................................................................................................................23
Csu 3 Agendar Citas .................................................................................................................................24
Referencias ..................................................................................................................................................27
 4

Introducción
La ingeniería de Software es según Pressman una disciplina o área de la informática o ciencias
de la computación que ofrece métodos y técnicas para desarrollar y mantener software de
calidad que resuelven problemas de todo tipo. La ingeniería de software comprende 4 capas
que son: herramientas da el apoyo automatizado y semiautomatizado; Métodos: este
proporciona las herramientas o técnicas para elaborar el software definiendo las tareas como
Análisis de requerimientos, modelación de diseño, construcción del programa, pruebas y
mantenimiento. Procesos: son conjuntos de políticas, estructuras organizacionales
tecnológicas, procedimientos y artefactos. Compromiso con la calidad: Tiene que ver con una
cultura de mejora continua, esto hace que el desarrollo sea más eficaz.
Se puede decir entonces que la ingeniería de software es la capacidad de inventar solucionar
un problema o aprovechar una oportunidad a través de elaboración de software.
 5

Proceso de Software
Se define como el conjunto de tareas o actividades que transforma unas entradas en una salida
o resultado esperado usando una serie de recursos. Uno de los cuales es el programa o
software que se desea desarrollar, según el requerimiento del cliente. La idea principal del
proceso es mejorar el entendimiento del problema a solucionar, generar los canales de
comunicación adecuados entre los involucrados del proyecto, manteniendo y retroalimentación
del sistema.
Las preguntas fundamentales en la definición de un proceso que debemos tener en cuentas
son: ¿Qué? ¿Quien? ¿Por qué? ¿Donde? ¿Cuándo? ¿Y cómo? Esto nos ayudara a tener una
mejor visibilidad del proyecto y así definir cuál es el mejor modelo.

Modelos de proceso de Desarrollo de Software

De acuerdo con las necesidades de diferentes proyectos se han definido distintos modelos del
proceso de software, también conocidos como “ciclos de vida del software”. Estos se clasifican
en dos:
1. Modelos de proceso predictivos o tradicionales: se enfatizan en la definición, la
identificación y la aplicación detallada de las actividades y tareas del proceso.
2. Modelos de procesos ágiles: Su énfasis está en la maniobrabilidad y la adaptabilidad,
son muchos más flexibles que los modelos tradicionales por lo que se adaptan con más
facilidad a las condiciones cambiantes.
Para iniciar nuestro Análisis y diseño del producto de software a desarrollar optamos por el
Modelo de Procesos ágiles, en este Modelo encontramos la Metodología Scrum.
 6

Metodología Scrum
Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para
trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera
de trabajar de equipos altamente productivos.
SCRUM propone una metodología donde el equipo debe trabajar en equipo, debe avanzar de
manera conjunta. De nada sirve tener partes de un software terminada, si no tenemos el
software entero terminado.
Scrum aparece como una práctica destinada a los productos tecnológicos y será en 1993
cuando realmente Jeff Sutherland aplique un modelo de desarrollo de Software en
Ease/Corporation.
Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5 fases que definen el
ciclo de desarrollo ágil:
1. Concepto
2. Especulación
3. Exploración
4. Revisión
5. Cierre

¿Por qué escoger esta metodología?

Scrum es una de las metodologías más utilizadas en la actualidad ya que es ágil y flexible para
gestionar el desarrollo del software, el cual maximiza principalmente el retorno de la inversión
para la empresa (ROI), con esta metodología el cliente se entusiasma y se compromete con el
proyecto dado que lo ve crecer iteración a iteración. A sí mismo le permite en cualquier
momento realinear el software con los objetivos de negocio de su empresa, ya que puede
introducir cambios funcionales o de prioridad en el inicio de cada nueva interacción. Esta
metodología de trabajo promueve la innovación, motivación y compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para
desarrollar sus capacidades. También define un marco para la gestión de proyectos, una
interacción la cual se denomina sprints con una duración de alrededor de 30 días, este
resultado es un incremento ejecutable que se muestra al cliente, en su construcción son de
importancia las reuniones a lo largo del proyecto, entre ellas destaca la reunión diaria de 15
minutos del equipo de desarrollo para coordinación e integración. Este es la metodología ágil
más popular en este momento, no sólo en la industria del software, sino en cualquier escenario
en el cual se desarrollen proyectos en los que se considera que las condiciones del proyecto
pueden variar rápida, frecuentemente y en que se puede generar una dinámica en los cuales
 7

presenta beneficios tales como: el cumplimento de expectativas, Reducción a la hora de

comprar, Mayor calidad del software, Mayor productividad, Maximiza el retorno de la inversión
(ROI), Predicciones de tiempos, Reducción de riesgos. En general esta metodología es apta
para el desarrollo de nuestro proyecto a desarrollar en el transcurso del módulo.
Scrum sirve para que equipos multidisciplinares trabajen en entornos complejos, donde los
requisitos son muy cambiantes, y los resultados se tienen que obtener en un plazo corto de
tiempo. Scrum es una metodología adecuada para grupos pequeños lo cual lo convierte en la
indicada para nuestro equipo de trabajo.

Porque no se escogió otra metodología

Las metodologías ágiles de desarrollo del software son muy utilizadas debido a sus ventajas
dentro de una organización, pues, permite adaptar las formas de trabajo a las necesidades o
requerimientos del proyecto para satisfacer al cliente y por supuesto a la población beneficiaria.
Sin embargo, luego de investigar y realizar cuadros comparativos, a manera de equipo de
trabajo se determina que las metodologías ágiles diferentes al modelo de desarrollo de
software, Scrum según sus descripciones no nos ofrecen las suficientes herramientas
necesarias para cumplir los requerimientos que exige el proyecto a diseñar e implementar,
teniendo en cuenta lo descrito por nuestro cliente y buscando atender de manera eficiente con
un trabajo altamente rápido y de calidad. SCRUM resalta e impulsa el trabajo en equipo, el
aprendizaje constante y una estructura que es flexible a los cambios que van sucediendo en la
fase de desarrollo, esta es una de sus grandes ventajas incluso frente a otras metodologías
ágiles más usadas además de esta. También se considera complementaria, la forma en que se
organizan las tareas visualmente en el modelo Kanban puede ser de ayuda para los equipos
auto gestionados de Scrum. En el caso de Extreme Programming es el hecho de que depende
de una participación activa del cliente. En diversos sectores, los clientes tienden a tercerizar
completamente los servicios o demandar el producto con rapidez, la gran mayoría de empresas
del mercado desean relacionarse muy poco con su proveedor, considerando que ellos son los
expertos que deben proveer a su empresa de soluciones de calidad. En cambio, Scrum al
aplicarse exclusivamente a la organización de equipos de trabajo autogestionado permite que
los expertos trabajan paralelamente y no dependan del cliente para el cumplimiento de
objetivos o realizar una tarea.

Porque no usar el método Tradicional

Es un método con muchas limitaciones, está hecho para proyectos que son bastante sencillos y
de menor escala, los enfoques tradicionales son más adecuados. No se prefieren los cambios
repentinos, ya que la mayor parte del tiempo el equipo podría tener que comenzar todo el
proyecto de cero. Para los proyectos tradicionales, los objetivos y la forma en que se llevará a
cabo el proyecto están definidos y detallados. Una de las posibles razones para no hacer uso
de este tipo de gestión son las que enumeramos a continuación:
 8

I. Es difícil responder a los cambios de los requerimientos del cliente ya que cualquier cambio
afecta a todo el proyecto y en el mundo real es muy difícil encontrar un proyecto en donde se
pueda asegurar que los requerimientos se pueden identificar y no van a sufrir variaciones.
II. Pasar por cada etapa de manera estrictamente secuencial puede hacer que se pierda tiempo
en el proceso ya que parte del equipo puede estar esperando a que otros terminen
determinada etapa para poder continuar a la siguiente.
III. Las revisiones de proyectos de gran complejidad son muy difíciles.
IV. Entre más tarde se detecte un error más costoso resulta su corrección.
V. El usuario no podrá tener una versión funcional sino hasta en las etapas finales del proceso.
VI. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre
hay iteraciones y se crean problemas en la aplicación del paradigma.
VII. Normalmente, es difícil para el cliente establecer explícitamente al principio todos los
requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará
disponible una versión operativa del programa. Un error importante no detectado hasta que el
programa esté funcionando puede ser desastroso.
● Resultados más lentos
● limitaciones de tiempo
● presupuesto.
● No hay lugar para cambios
● Costos elevados si el proyecto debe reiniciarse
● Adecuado para proyectos más pequeños

Riesgos asociados a la metodología Scrum

La metodología scrum es muy exigente en tiempo y dedicación ya que ella requiere realizar
procesos los cuales en algunas ocasiones se vuelven muy “repetitivos” con el fin de mejorar el
producto según el requerimiento del cliente. La metodología es muy eficaz en los casos ya
mencionados. El riesgo que puede traer al proyecto son varios:
• No sectorizar adecuadamente el trabajo: Scrum funciona muy bien en equipos
pequeños, en los grandes puede variar su eficacia ya que puede llegar a ser compleja la
distribución equitativa de tareas e identificar los roles de cada persona.
• Falta de experiencia en los integrantes: La metodología necesita un grupo de
desarrolladores con experiencia, personas que tengan el suficiente conocimiento en su área.
 9

Específicamente para tener un rendimiento óptimo en el equipo, es necesario que todos tengan
un nivel adecuado de conocimientos, ya que si alguno no lo tiene puede retrasar el trabajo de
los demás.
• Aumento en los tiempos de desarrollo.
• Falta de optimización en la etapa temprana en el desarrollo del producto.
• Adaptación al modelo de trabajo por parte del equipo.

para evitar errores hay que tener presente que Scrum no es sólo un conjunto de técnicas, sino
un marco de trabajo que, como tal, tiene que ser moldeado en la forma que cada proyecto
precisa

Estrategias para gestionar dichos riesgos

Este es la metodología ágil más popular en este momento, no sólo en la industria del software,
sino en cualquier escenario en el cual se desarrollen proyectos en los que se considera que las
condiciones del proyecto pueden variar rápida y frecuentemente y en que se puede generar
una dinámica más ágil de trabajo en equipo.

Planteó las siguientes estrategias

● La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
● Dar la bienvenida a los cambios: se capturan los cambios para que el cliente tenga una
ventaja competitiva.
● Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
● La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
● Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
● El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
● El software que funciona es la medida principal de progreso.
● Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
● La atención continua a la calidad técnica y al buen diseño mejora la agilidad. La
simplicidad es esencial
● Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por
sí mismos.
 10

En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según
esto ajusta su comportamiento.

Requerimientos Funcionales
Un requerimiento funcional de un sistema, son aquellos que describen cualquier actividad
que este debe realizar en el sistema cuando se cumplen unas condiciones.
Por lo general estos deben incluir funciones desempeñadas en pantallas específicas,
descripciones de los flujos de trabajo a ser ejecutadas por el sistema.
El documento de requerimientos de software, es el lugar donde se da la descripción a las
características y requisitos de un producto de software, producto, programa o conjunto de
programas.

Información de Requerimientos funcionales

Identificación del requerimiento RF-01
Nombre de la especificación
Registro de Usuarios

Código del RF-01

Requerimiento
Descripción El sistema debe permitir el registro de usuarios con clave en la base
del de datos
Requerimiento

Especificación de Casos de Uso

Caso de Uso Registrar Usuarios Identificador: CU-1

Actores Sistema, usuario
Tipo Primario
Referencias RF-01
Precondición Cargar el formulario de registro de usuario
El usuario no debe estar registrado
Postcondición Usuario registrado exitosamente
Usuario ya registrado
Descripción Registrar usuarios
Resumen El usuario diligencia el formulario de registro llenando los campos
solicitados por el sistema
 11

Curso Normal
Nro. Ejecuto Paso o Actividad
r
1 Usuario Abrir el aplicativo
2. Registrarse en el sistema
Usuario
3. Usuario Ingresar el Tipo de Usuario
4. Sistema Validar el tipo de usuario
5. Usuario Ingresar Nombre completo, Genero, edad, direccion de residencia,
correo Electronico
6. Usuario Guardar los datos registrados
7. Sistema Almacenar los datos registrados en la base de datos

Cursos Alternos
Nro. Descripción de acciones alternas
3.1 Si el tipo de usuario es Proveedor de servicio se debe activar los siguientes
campos
Tipo Tercero natural o Juridica, tipo de servicio
6.1 Si los campos no estan completos se mostrara un mensaje “Falta campos por
completar”

Caso de Uso Registrar Usuarios Identificador: CU-2

Actores Usuario
Tipo Primario
Referencias RF-01
Precondición Haber completado el formulario de registro
Postcondición Contraseña creada exitosamente
Descripción Creación de contraseña
Resumen Una vez completado el registro de usuario el sistema solicitara la
creación de la contraseña

Curso Normal
Nro. Ejecuto Paso o Actividad
r
1. Sistema Habilitar campos de contraseña Nueva
2. Usuario Ingresar contraseña nueva
3. Sistema Solicitar confirmacion de contraseña
4. Usuario Ingresar nuevamente la contraseña
5. Sistema Guardar la contraseña
6. Sistema Envia codigo de verificacion al correo
 12

Cursos Alternos
Nro. Descripción de acciones alternas
3.1 Si las contraseñas no coinciden se mostrara el siguiente mensaje “La contraseña
ingresada no coinciden con la inicial”
6.1 Se mostrara un mensaje en pantalla informando que el codigo de verificacion a
sido enviado al correo.

Identificación del requerimiento RF-02

Nombre de la especificación
Inicio de sesión

Código del RF-02

Requerimiento
Descripción El sistema debe permitir el ingreso de Usuarios una vez estén
del registrado en la base de datos
Requerimiento

Especificación de Casos de Uso

Caso de Uso Inicio de Sesión Identificador: CU-3
Actores Cliente, Proveedor de servicio
Tipo Primario
Referencias Logearse
Precondición Estar registrado en el sistema
Tener credenciales de ingreso
Postcondición Inicio de Sesión exitoso
Contraseña incorrecta
Descripción En este caso de uso determinaremos como será el ingreso al aplicativo
Resumen Para el ingreso al aplicativo se debe contar con credenciales de acceso
Curso Normal
Nro. Ejecuto Paso o Actividad
r
1. Usuario Ingresar al aplicativo
2. Usuario Ingresar credenciales de acceso usuario contraseña
3. Sistema Validacion de usuario y contraseña en la base de datos
Cursos Alternos
Nro. Descripción de acciones alternas
3.1 Al no estar registrado el sistema mostrara mensaje de “Usuario No registrado o
contraseña incorrecta”
 13

Identificación del requerimiento RF-03

Nombre de la especificación
Agendar citas

Código del RF-03

Requerimiento
Descripción El sistema permitirá a cada cliente agendar cita por servicio
del
Requerimiento

Especificación de Casos de Uso

Caso de Uso Agendar citas Identificador: CU-4

Actores Cliente
Tipo Secundario
Referencias RF-04
Precondición Haberse logeado en el sistema con el rol de cliente
Solo se mostrarán los profesionales con agendas disponibles
Postcondición Cita Agendada
Descripción Permite que el cliente pueda agendar sus citas
Resumen El cliente ingresara al aplicativo y desde el módulo de citas podrá
agendar la cita con el profesional que desee

Curso Normal
Nro. Ejecuto Paso o Actividad
r
1. Cliente Se logea en el sistema
2. Sistema Da el acceso al cliente.
3. Cliente Ingreso al modulo de citas
4. Sistema Muestra el listado de profesionales
5. Sistema Muestra agenda por profesional
6. Cliente Selecciona al profesional
7. Cliente Selecciona el tipo de servicio con el que cuenta el profesional
8. Cliente Ve la agenda del profesional
9. Sistema Muestra las fechas,horarios disponibles y costo del servicio
seleccionado
10. Cliente Agenda cita
11. Sistema Almacena la cita agendada en base de datos
12. Sistema Valida el tipo de servicio seleccionado
 14

13. Sistema Redirecciona al sistema de pago en linea

Cursos Alternos

Nro. Descripción de acciones alternas

10.1. Al no haber disponibilidad de agenda el sistema mostrara el siguiente mensaje
“No hay citas disponibles con este profesional”
11.1 Cuando la cita sea agendada el sistema generara un mensaje de alerta “ Desea
realizar el pago”

Especificación de Casos de Uso

Caso de Uso Agendar citas Identificador: CU-5

Actores Cliente
Tipo Secundario
Referencias RF-03
Precondición Tener agendada una cita
No haber realizado el pago en linea
Postcondición Registro actualizado exitosamente
No se puede realizar el cambio de Fecha ya se realizó el pago
Descripción Permite que el cliente pueda realizar modificaciones en las citas
agendadas solo en los campos de fecha y hora, siempre y cuando no
se haya efectuado el pago.
Resumen El cliente ingresara al módulo de citas y consultara las citas que agendo,
allí podrá modificar las citas que aún no se les haya generado el pago.

Curso Normal

Nro. Ejecuto Paso o Actividad

r
14. Cliente Se logea en el sistema
15. Sistema Da el acceso al cliente.
16. Cliente Ingreso al modulo de citas
17. Sistema Muestra el listado de citas agendadas por el cliente
18. Sistema Muestra las citas agendadas en estado sin pagar
19. Cliente Solo podra ingresar a la citas que estan en estado sin pagar
20. Cliente Realiza la modificacion
21. Sistema Habilitara los campos fecha y hora
22. Cliente Realiza el cambio
23. Sistema Almacena la cita agendada en base de datos
24. Sistema Valida el tipo de servicio seleccionado
 15

25. Sistema Redirecciona al sistema de pago en linea

Cursos Alternos

Nro. Descripción de acciones alternas

21.1 La fecha y hora seleccionada ya estan ocupadas el sistema no realizara el cambio
y mostrara el siguiente mensaje “Fecha y hora no disponible, por favor validar
nuevamente la agenda”.
22.1 El sistema arrojara el siguiente mensaje “Esta seguro de actualizar esta cita,
recuerde una vez realizado el cambio, no podra reasignarla”

Identificación del requerimiento RF-04

Nombre de la especificación
Consultar Profesionales de la salud

Código del RF-04

Requerimiento
Descripción El sistema permitirá al usuario realizar la búsqueda de los
del profesionales registrados en la base de datos
Requerimiento

Especificación de Casos de Uso

Caso de Uso Consultar Profesionales de Salud Identificador: CU-6

Actores Cliente
Tipo Secundario
Referencias RF-04
Precondición El profesional debes estar registrado en el sistema.
Postcondición Búsqueda exitosa
Descripción Permite la búsqueda directa del profesional
Resumen El cliente ingresará al módulo de Proveedores de Servicio y desde allí
también podrá agendar cita

Curso Normal
Nro. Ejecuto Paso o Actividad
r
1. Cliente Ingresa al modulo de proveedores de servicio
 16

2. Sistema Muestra listado de Proveedores de servicio

3. Cliente Selecciona al Proveedor de servicio
4. Sistema Muestra la agenda y los servicios que tiene el proveedor
5. Sistema Permite mirar el detalle del servicio

Cursos Alternos

Nro. Descripción de acciones alternas

Identificación del requerimiento RF-05

Nombre de la especificación
Pagos en Línea

Código del RF-05

Requerimiento
Descripción El sistema permitirá realizar al usuario el pago en línea una vez
del se agende la cita
Requerimiento

Especificación de Casos de Uso

Caso de Uso Pagos en Linea Identificador: CU-7

Actores Cliente
Tipo Primario
Referencias RF-05 CU-5
Precondición Tener citas agendadas
Contar con sistema de pagos en linea
Postcondición Transacción exitosa
Descripción Permite realizar el pago de las citas en linea
Resumen El sistema mostrara al usuario el icono de pago y lo redireccionara a la
página PSE

Curso Normal

Nro. Ejecuto Paso o Actividad

r
1. Cliente Realizar pago en linea
 17

2. Sistema Redireccionar al cliente a la pagina donde se realizara el pago

3. Cliente Insertar datos para realizar pago
4. Sistema Se realiza el pago en linea

Cursos Alternos
Nro. Descripción de acciones alternas
3.1 Envia al cliente a la página del banco elegido

Identificación del requerimiento RF-06

Nombre de la especificación
Registrar Agenda y Servicios

Código del RF-06

Requerimiento
Descripción El sistema permitirá al profesional crear sus agendas de
del acuerdo al tipo de servicio registrado
Requerimiento

Especificación de Casos de Uso

Caso de Uso Registrar Agenda Identificador: CU-8

Actores Profesionales de la Salud
Tipo Primario
Referencias RF-06
Precondición Estar logeado con rol de proveedor de servicio
Postcondición Agenda registrada
Descripción Permite registrar agendas
Resumen El profesional ingresara al sistema y creara sus propias agendas

Curso Normal
Nro. Ejecuto Paso o Actividad
r
1. Usuario Ingresa al sistema
2. Usuario Ingresa al servicio
3. Usuario Crea la agenda
4. Sistema Guarda la agenda creada
 18

Requerimientos no funcionales
✓ Disponibilidad 24/7
✓ Estructuración modelo de base datos de datos relacional
✓ Desarrollo en lenguaje de alto nivel
✓ Documentación del código fuente para mantenimiento
✓ Contar con diseño responsivo para adaptación a móviles
✓ Almacenamiento Ilimitado, para contar con un historial de citas médicas de cualquier
persona desde su primer registro
✓ Seguridad (hackeo, SQL injection entre otros)
✓ Revisar documentación del flujo del proceso
 19

Diagrama de Clase
 20

Diagramas de Secuencia
Csu 1 Registrar Usuario
 21

Csu 2 Inicio de Sesion

 22

Csu 3 Agendar Citas

 23

Diagrama de Estado
Csu 1 Registrar Usuario

Csu 2 Inicio de Sesion

 24

Csu 3 Agendar Citas

25
 26

Anexos

1. Enlace video de Sustentación https://poligran-

my.sharepoint.com/:v:/r/personal/lplara_poligran_edu_co/Documents/TRAB%20COLA%20ING
%20SOTWARE%20I%20SUBGRUPO%204/ACTIVIDAD%20SEMANA%207/SUSTENTACI
ON%20ECENARIO%207%20Y%208.mp4?csf=1&web=1&e=ipayqy
2.
 27

Referencias
Metodología Scrum para desarrollo de software - aplicaciones complejas
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-
scrum.html
Gestión ágil vs gestión tradicional de proyectos ¿cómo elegir?
https://www.escueladenegociosfeda.com/blog/50-la-huella-de-nuestros-
docentes/471-gestion-agil-vs-gestion-tradicional-de-proyectos-como-
elegir
Industria del Software
https://elibro.net/es/ereader/poligran/98183?page=10

https://mobilizaacademy.com/por-que-scrum/

https://www.obsbusiness.school/blog/los-riesgos-de-la-metodologia-scrum

Lectura fundamental escenario 1 y 2 Ingeniería de Software I Politécnico

Gran Colombiano

https://staruml.io/download

StartUML

http://www.pmoinformatica.com/2018/04/documento-de-requerimientos-de-
software_37.html
La oficina de proyectos de informatica