INTRODUCCION

Desarrollar un proyecto de software es un proceso que merece todo el cuidado y

discriminación en cuanto al proceso de desarrollo y la ejecución de las actividades que pueda

contener. Por consiguiente, es de considerar la metodología o modelo de proceso de

desarrollo de software que más se adapte a la propuesta de desarrollo, considerando los

requerimientos, el tipo de software, ya que de ello va a depender la planeación y la

determinación de las actividades a desarrollar en el tiempo.

Teniendo como base el requerimiento de un cliente: “Necesito contar con una herramienta

que me 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”, el modelo de proceso de desarrollo de

software que elige el grupo para llevar a cabo esta tarea es: modelo de proceso por prototipo.

Se toma como requerimiento los puntos del cliente:

Los requerimientos detallados (desde el punto de vista del cliente) son:

 Todos los usuarios deben tener una cuenta con login y contraseña e identificar si es un

profesional proveedor de servicios o un cliente.

 De las profesiones se debe conocer: nombre completo, tipo de servicio que ofrece,

Dirección, costos de los servicios que ofrece, el horario y la agenda que ofrece que incluye

cuánto tiempo dura una sesión de su servicio y si puede atender varios usuarios a la vez o no,

identificación como personas natural y jurídica si es necesario.

 De los clientes se desea conocer: nombre completo, género, edad, dirección de

Residencia, correo electrónico.

Cada cliente puede realizar las siguientes actividades:

 Buscar profesionales de la salud por nombre, tipo de servicio y ubicación.

 Seleccionar de un profesional y consultar su agenda.

 Seleccionar una sesión disponible y reservarla.

 Hacer el pago en línea de la sesión.

 Modificar la fecha y hora de la sesión.

 Un cliente no puede agendar más de una sesión a la vez.

Cada profesional proveedor debe poder:

 Registrar los servicios que ofrece y la agenda que dispone.

 Consultar las sesiones que tiene agendadas.

Consulta la información de los usuarios que han solicitado sus servicios.

 El sistema debe permitir generar consultas como las siguientes:

 Reporte de profesionales de la salud registrados.

 Reporte de usuarios registrados.

 Agenda un profesional específico.

 Agenda de un usuario específico.

 Consultar cuáles son los servicios más solicitados.

 DESARROLLO DE LA ACTIVIDAD

JUSTIFICACION DE LA ELECCION

Según el modelo que elegimos para el desarrollo del sistema, definimos que para la fase o

actividad de comunicación que representa el inicio del ciclo de vida de la construcción del

sistema, optamos por el modelo de proceso de desarrollo por prototipo por las siguientes

razones:

 Los requerimientos del usuario son claros, representando como actores del sistema y

las funciones que va a realizar cada uno de ellos, por lo tanto es posible desarrollar una vista

y prototipo visual de lo solicitado.

 Actuamos en el desarrollo del proyecto teniendo en cuenta la participación del cliente.

 buscando la participación activa del cliente con lo que podemos reducir el riesgo de

no construir un producto que no satisfaga la necesidad del usuario, aumentar la probabilidad

de éxito, presentando muestras del entregable y buscar ajustes en base al prototipo para

mejorar y aplicar en los próximos niveles y actividades correspondientes.

Con el modelo de desarrollo por prototipo ya podemos presentar al cliente un prototipo o

muestra de lo sería el sistema una vez contemplado los requerimientos en la fase de

comunicación con el cliente:

Una vez contamos con los requerimientos del cliente procedemos a realizar el prototipo

y/o vista para presentación al cliente; boceto vista de aplicación, de funcionamiento, de base

de datos. Resaltamos que el diseño de la base de datos está sujeto a los requerimientos de
entidades involucradas inicialmente: estos son las tablas que y relaciones que conformaran la

base de datos y fuente de las funciones propias a realizar con cada una de ellas.

DIAGRAMA ENTIDAD-RELACION (BD):

Con los datos del requisito suministrado por el cliente se establece el Diagrama Entidad-

Relación con el fin de estructurar el contenedor de los registros del sistema a desarrollar.

ACTORES DEL PROCESO:

En el siguiente esquema se presenta los actores principales del proceso o sistema que

llamamos “REGISTRO_SERVICIO_PRESTADOS”.
El anterior es un esquema no convencional para representar la interacción de los actores

principales del proceso:

ADMINISTRADOR:

 Control total del sistema

 Agendar un profesional especifico

 Agendar un usuario especifico.

 Consultas de estadísticas.

PROFESIONAL:

 Control de sus datos personales y perfil

 Consultar su agenda de citas y validación del estado de las mismas.

 Las demás acciones establecidas en el requerimiento inicial.

CLIENTE:

 Registrar información inicial de acceso y tener control de su perfil

 Separar citas con el profesional

 Actualizar los estados de las citas con anticipación.

 Las demás acciones establecidas en el requerimiento inicial.

PROFESIONAL – USUARIO:

 La relación entre estos actores del proceso es estrecha y dependiente uno del otro.

CARACTERISTICA DEL SISTEMA:

El sistema será de tipo online, montado en un hosting y apuntando a un dominico

comercial, incorporando la tecnología ssl para permitir los pagos de las citas en línea.

Una segunda opción online para la puesta en marcha de la aplicación y para mantener en

nuestras manos la seguridad de la información de la base de datos, es tener nuestro sistema en

un servidor propio de la empresa y hacer uso del medio ip público para ponerlo en

funcionamiento.

BASE DE DATOS:

La gestión de la información del sistema estará administrada por el SMBD mysql server

LENGUAGE DE PROGRAMACION:
 Teniendo en cuenta que el sistema será online, haremos uso del lenguaje de programación

PHP 7 , lenguaje de maquetación HTML5, lenguaje de estilos CC3 y lenguaje de

programación JAVASCRIPT.

PORQUE NO UTILIZAMOS ALGUNO DE LOS OTROS MODLEO DE PROCESO

DE SOFTWARE

MODELO EN CASCADA:

Una de las razones principales para no elegir este modelo de desarrollo es debido a la

estructura del modelo que si damos como definitivo los requerimientos brindados podríamos

hacer uso de ella obteniendo una procedimiento lineal de actividades en el orden cronológico,

sin embargo vemos que el cliente no podría saber o poner a prueba el sistema hasta la fase

final de la actividad de despliegue. Teniendo en cuenta esta dinámica, si el cliente decidiera

agregar o modificar alguna acción o condición, tendríamos que regresar a la actividad de

comunicación y actualizar los requerimientos del sistema para incorporarlo. Luego afecta a la

actividad o fase de planeación, modelado, construcción y despliegue.

MODELO INCREMENTAL:

El modelo incremental sería una de las opciones a considerar para este proyecto de

software debido a la combinación del flujo lineal y paralelo que representaría la construcción

del sistema al mismo tiempo en diferentes etapas. Sin embargo, el cliente podría ver una

muestra del software en la etapa de construcción y podría hacer sus observaciones,

sugerencia, cambios, actualización en este punto, lo que conlleva a realizar las iteraciones

necesarias hasta lograr el objetivo final.

Cabe mencionar que una vez el cliente de sus observaciones, el proceso empieza desde la

primera etapa o fase nuevamente, lo que se diferencia con el modelo por prototipo que provee

una muestra del sistema desde la primera etapa, permitiendo tomar las consideraciones antes

de planear, modelar, construir.

MODELO ESPIRAL:

El modelo en espiral también sería un opción a considerar para el desarrollo del proyecto,

debido a que es un modelo que permite tantas iteraciones y en cada una de ellas presenta un

prototipo que se va robusteciendo o creciendo hasta llegar el producto final. Sin embargo el

proyecto que necesitamos desarrollar necesita una vista de prototipo al momento de iniciar

las etapas del proceso de desarrollo no al final, lo que sucedería al finalizar cada iteración al

utilizar este modelo.

PRINCIPALES RIESGOS ASOCIADOS AL MODELO SELECCIONADO

Dados los requerimientos del cliente y la puesta en escena de un prototipo donde se aprecie la

solicitud encomendada, empezamos validando u observando el producto final, y el cliente

tiene la oportunidad de verificar la adición o supresión de funciones o datos básicos.

Entonces podemos decir que empezamos con una validación de los primeros requerimientos

y esto puede significar que el equipo vuelva a la actividad de comunicación y consolide

nuevamente la información de requerimiento.