Entrega Final Ingenieria de Software en colombia PDF

Preview

Summary

Download Entrega Final Ingenieria de Software en colombia PDF

Description

1

INGENIERIA DE SOFTWARE I

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

PROFESORA: Peña Erika Jazmín

INTEGRANTES DEL GRUPO: Valery Hoyos Arrieta COD: 279595 Ardila Quiñonez Andrés Atila COD: 100241405 Gartner Muñoz Cristian COD: 1088277348 William García Bedoya COD: 2011025911

ESCUELA DE TECNOLOGÍAS DE INFORMACIÓN Y TELECOMUNICACIONES

INGENIERÍA DE SOFTWARE

INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN

2

Entrega Final Semana 7 Resumen Se debe analizar el requerimiento expuesto para seleccionar e implementar un modelo de desarrollo justificando su elección e incluyendo las razones por las que otros modelos no serían los mejores para desarrollar el ejercicio. El fin del Modelo de Proceso de Desarrollo de Software es entregar una herramienta de software enfocada en la prestación de servicios de salud con unas necesidades: 1) registrar profesionales de la salud. 2) diferentes servicios. 3) agendar cita. 4) realizar el pago del servicio, y unos requerimientos específicos. Necesidad del producto 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. Justificación Descripción de la metodología SCRUM y su aplicación al proyecto en todas las fases del ciclo de vida del software para el producto que nos solicitan y relacionándolo con otras metodologías para el levantamiento de requerimientos, con el objetivo registrar en la plataforma 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

3

el profesional que más se adapta a sus necesidades y agendar una cita con este profesional una vez ha realizado el respectivo pago del servicio. Modelo de Proceso de Desarrollo de Software El modelo de procesos de desarrollo de software o también llamado “Ciclo de Vida del Software” define las actividades que se van a desarrollar para construir un software y cuenda con unas etapas básicas como son: Comunicación, Planeación, Modelado, Construcción y Despliegue. Metodología SCRUM Es una metodología ágil de desarrollo, un marco de trabajo en el que se define una estructura, se planifica adecuadamente y se controlan los procesos que tienen lugar en el desarrollo de un proyecto de software. En la metodología ágil, se procura conservar una buena organización en el proceso de construcción del producto, por lo cual en una parte de las llamadas historias de usuario donde se detalla en complemento cada requerimiento, estas harán parte de la primera etapa de SCRUM: Product Backlog, cuyo único responsable es el Product Owner. Una vez se calcula esto, se pueden utilizar métodos de estimación como Planning Póker, lo que ayudará posteriormente a formar el Sprint Backlog, es decir, las tareas que se van a ejecutar dentro de cada intervalo de tiempo designado. También se debe recordar que dentro de cada iteración se poseen tres estados diferentes para “categorizar” un requerimiento: ToDo (Tareas por hacer), Doing (Tareas en progreso) y Done (Tareas que ya se han finalizado).

4

Una de las superioridades de la metodología SCRUM, es el constante seguimiento del proyecto con las reuniones Daily’s en las que el equipo de desarrollo presenta lo realizado, lo que se efectuará y las dificultades que se presentaron. Para el registro del progreso cada día se lleva una supervisión, se poseen los gráficos BurnDown y Burn-Up los cuales, bajo algunos parámetros, manifiestan la gestión y progreso del proyecto en cada sprint. En el primero resulta una estimación del momento de finalización del trabajo, y el segundo le permite al Product Owner obtener una visión sobre el trabajo real que se está estableciendo. Al finalizar cada SPRINT, para valorar el desarrollo del equipo con esta metodología, se efectúa una revisión de éste y a continuación, se hace una retrospectiva sobre lo entregado para corregir los errores que el equipo ha cometido, revisar posibles riesgos y mostrar una evolución de trabajo para el siguiente sprint que se va a proyectar. Para llevar esto a cabo correctamente se necesita la figura de Scrum Máster, el cual vela por el desempeño correcto de las tareas. La metodología SCRUM, brinda una mayor flexibilidad y eficiencia para el ejercicio descrito que puede llegar a ser mucho más versátiles y cambiantes, pues los requerimientos dados por el cliente a futuro pueden cambiar en el entendido que establecer ciertas funciones para el cliente, otras para los profesionales proveedores de servicios de salud y otras enfocadas a generar consultas. Siguiendo con la metodología de SCRUM el cliente nos acompañara en este proceso desde el principio hasta, el final de este desarrollo de software.

5

En esta metodología el desarrollo debe ser honesto y transparente, y cualquier integrante del grupo puede dar su opinión en cualquier tiempo, de su punto de vista, del desarrollo del sistema de software. Al final de cada Sprint se evaluará este y al comenzar el siguiente y se tratará de mejorar en tiempo y eficacia que el anterior. Eventos Sprint Planning Sprint Execution Daily Meeting Sprint Review Sprint Retrospective Refinement

Roles Scrum Master Product Owner Delevelopment Team

Artefactos Product Backlog Sprint Backlog

¿Qué roles van a ejecutar y quien lo hará? ROL Product Owner

ENCARGADO  William García Bedoya

Scrum Master



Valery Hoyos Arrieta

Developer Team



Andrés Atila Ardila Quiñonez Cristian Gartner Muñoz José Julián García Vargas

 

FUNCIÓN  Recoger y conocer los requisitos.  Decidir qué desarrollar y qué no.  Ordenar y priorizar el product backlog y hacer que éste sea visible para todo el mundo.  Definir el producto mínimo viable (MVP)  Encargado de optimizar y maximizar el valor del producto    

Gestionar el proceso SCRUM Ayudar a eliminar impedimentos Mentoring y formación Responsables de entender los requerimientos del negocio especificados por el Propietario del Producto, estimar Historias de Usuario y crear los Sprints del Proyecto.

Estrategia de Gestión del Riesgo

6

El desarrollo de software debe ser gestionado de manera eficaz con el objetivo de alcanzar un logro comúnmente relacionado a materia de negocios e intereses personales o colectivos, sin embargo en este camino tendremos posibilidades de sufrir pérdidas refiriéndose a posibles impactos que deterioren la calidad y seguridad del software, como consecuencias podemos tener aumentos en costos de operación, demoras en entregas y pérdida de capacidad comercial y de mercadeo, estos son grandes riesgos que se deben evitar si se desea desarrollar un programa informático idóneo. Como estrategia para la disminución del riesgo es importante identificar, analizar, evaluar, tratar y realizar el seguimiento del mismo, el cual revisaremos antes de cada SPRINT en nuestra metodología SCRUM para el ejercicio planteado.

Fuente: colibri.udelar.edu.uy Monitorear cada movimiento nos ayuda a recolectar información importante que posteriormente se puede observar y mitigar el riesgo, se debe controlar adecuadamente cada error en el proceso para corregir cada detalle y prevenir los errores que signifiquen una cantidad importante de tiempo, la comunicación también tiene un papel importante en la disminución del riesgo y si los integrantes del equipo están siempre documentados, nos permitirá prevenir percances. ¿Cuándo van a desarrollar esas actividades?

7

Fases

Comunicación y Planeamiento

Sprint Planning

Sema na

Observaciones

Planeamiento

1

Reunión de visión del proyecto entre el Product Owner, el cliente y Stakeholders

Levantamiento de requerimientos

2-3

Actividad

Product Backlog y su distribución en los Sprint

Sprint 1

Las tareas priorizadas como altas se realizarán en este primer Sprint

Sprint Review y Retrospective

Funcionamiento, Revisión, planes de mejora, lecciones aprendidas

3

4-8

9 - 10

Surgen los requerimientos funcionales y no funcionales Fase de Modelado. Se establece y define la planeación de los Sprint, con 15 requerimientos priorizados

Fase de Construcción. Se realiza la reunión diría siempre para informar avance y como seguimiento al Sprint Se realiza el análisis de riesgos y actividades de mejora Fase de Despliegue. Todos los integrantes del SCRUM realizan las revisiones y mejoras necesarias

Product Backlog: A partir de la fase de comunicación y planeamiento con el Product Owner, se realizó el levantamiento de requisitos con las premisas de organizarlos, documentarlos, rastrearlos y comunicarlos, generando 15 requerimientos que cumplen con las características de priorizables, necesarios, verificables, realizables y trazables. Requisito funcional define lo que esperamos que haga el sistema, son características que interactúan con el usuario Requerimientos Funcionales

Descripción

8 Acceder con cuenta y contraseña e identificar los profesionales proveedores de los clientes.

En la aplicación se debe permitir el acceso con cuenta y contraseña para identificar correctamente a cada usuario

los profesionales tengan información detallada, el nombre completo, tipo de servicio que ofrece, dirección, costos de los servicios que ofrece, el horario y la agenda que ofrece que incluye tiempo de duración y si puede atender varios usuarios a la vez o no, identificación como personas natural y jurídica si es necesario.

La aplicación debe permitir asociar a los usuarios como proveedores de servicio, además guardar información detallada para el correcto funcionamiento

clientes se desean conocer: nombre completo, género, edad, dirección de residencia, correo electrónico.

Se debe permitir información detallada del cliente para poder realizar correctamente la cita en la aplicación

Requerimientos no funcionales representan características generales y restricciones de la aplicación o sistema que se esté desarrollando. Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría ser sujeto de libre interpretación y es recomendable acompañar su definición con criterios de aceptación que se puedan medir. A nivel de eficiencia el sistema debe ser capaz de procesar muchas transacciones por cada segundo, el tiempo por cada request no debe ser mayor a 5 segundos, el soporte de usuarios conectados al mismo tiempo debe ser de al menos 50.000 sesiones, los datos modificados en la base de datos deben ser refrescados a los usuarios en un tiempo máximo de 2 segundos. A nivel de seguridad de hardware la plataforma deberá detenerse si el dispositivo eleva temperaturas exageradas. La usabilidad de la aplicación estará orientada al rápido e intuitivo aprendizaje y reducir errores cometidos por el usuario, el sistema debe contar con manuales de

9

usuario en formato texto y videotutoriales, la validación de formularios y mensajes de error son importantes para informar y orientar al usuario, es importante contar con un sistema de ayuda en línea con chat de soporte, la aplicación estará construida en un diseño responsivo para garantizar el acople en las diferentes medidas de dispositivos Estos requisitos cuentan con un tiempo, una prioridad y con sus pruebas que nos permitieran identificar si se llegan a presentar riesgos para analizar y evaluar. A continuación, se expone mediante uso de casos cada requisito. Id Req001

Titulo Pantalla Login y contraseña de usuario

Descripción Cliente: Todos los usuarios deben tener una cuenta con login y contraseña e identificar si es un profesional proveedor de servicios o un cliente

Tiempo 3 hrs

Prioridad Alta

Pruebas El sistema permitirá primero una pantalla para el login y contraseña e identificar si es cliente o proveedor de servicios.

Id Req002

Titulo Iniciar sesión

Descripción Cliente: nombre completo, tipo de servicio que ofrece, dirección, costos de los servicios que ofrece, el horario y la agenda que ofrece que incluye cuanto 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.

Tiempo 4 hrs

Prioridad Alta

Pruebas Se muestra la pantalla de inicio con los datos del proveedor de servicios, las profesiones, nombre, servicios, dirección, horario y agenda, especificar si es mono o multiusuario

Id Req003

Titulo Pantalla Cliente

Descripción Cliente: nombre completo, genero, edad, dirección de residencia, correo electrónico

Tiempo 3 hrs

Prioridad Normal

Pruebas Se muestra la pantalla de inicio con los datos del cliente

Id Req004

Titulo Pantalla Cliente

Descripción Cliente: buscar profesionales de la salud por su nombre, tipo de servicio y ubicación.

Tiempo 4 hrs

Prioridad Normal

Pruebas El sistema permitirá buscar profesionales de la salud, por su nombre, tipo de servicio y ubicación

10

Id Req005

Titulo Pantalla Cliente

Descripción Cliente: Seleccionar de un profesional y consultar su agenda

Tiempo 3 hrs

Prioridad Normal

Pruebas El sistema debe permitir selección del profesional y consultar en base de datos su agenda

Id Req006

Titulo Pantalla Cliente

Descripción Cliente: Seleccionar una sesión disponible y reservarla.

Tiempo 2 hrs

Prioridad Normal

Pruebas El sistema permite seleccionar la sesión disponible y reservarla

Id Req007

Titulo Pantalla Cliente

Descripción Cliente: Hacer el pago en línea de la sesión.

Tiempo 3 hrs

Prioridad Normal

Pruebas El sistema genera el pago online de la sesión a través de tarjeta de crédito o pago en puntos físicos.

Id Req008

Titulo Pantalla Cliente

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

Tiempo 2 hrs

Prioridad Normal

Pruebas El sistema no debe permitir más de una sesión a la vez.

Id Req009

Titulo Pantalla Profesional

Descripción Cliente: Cada Profesional debe poder: Registrar los servicios que ofrece y la agenda que dispone.

Tiempo 2 hrs

Prioridad Normal

Pruebas El sistema en su base de datos tendrá los servicios ofrecidos por los profesionales de salud y su agenda disponible

Id Req010

Titulo Pantalla Profesional

Descripción Cliente: Consultar las sesiones que tiene agendadas.

Tiempo 4 hrs

Prioridad Normal

Pruebas El sistema le mostrara al cliente las sesiones que tiene agendadas y pagas.

Id Req011

Titulo Pantalla Profesional

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

Tiempo 3 hrs

Prioridad Normal

Pruebas El sistema mostrara a los clientes la información de

11 usuarios que han solicitado ese servicio

Id Req012

Titulo Pantalla General

Descripción Cliente: El sistema debe permitir generar consultas como las siguientes: Reporte de usuarios registrados.

Tiempo 3 hrs

Prioridad Normal

Pruebas El sistema mostrara los reportes de usuarios registrados

Id Req013

Titulo Pantalla General

Descripción Cliente: Agenda un profesional especifico

Tiempo 2 hrs

Prioridad Normal

Pruebas El sistema muestra un profesional específico para la sesión buscada por el cliente

Id Req014

Titulo Pantalla General

Descripción Cliente: Agenda de un usuario especifico

Tiempo 4 hrs

Prioridad Normal

Pruebas El sistema mostrara el usuario específico para dicho servicio

Id Req015

Titulo Pantalla General

Descripción Cliente: Consultar cuales son los servicios más solicitados.

Tiempo 3 hrs

Prioridad Normal

Pruebas Se muestra la pantalla de inicio con el logotipo de la empresa y con los listados de médicos y sus especialidades

La integración de los casos de uso se puede observar en el diagrama. Donde se cuenta con 3 actores: Funcionario de la salud, el Usuario y el Administrador de la plataforma, entre los casos de uso se observan el login, las búsquedas, agendar y modificar consultas, realizar pagos y reportes.

12

Los 15 requerimientos identificados requieren de unas tareas específicas descritas a continuación en los siguientes casos de uso y que para el flujo de trabajo de ingeniería están a cargo del grupo de desarrolladores o Developer Team. Tareas Id Req01

Tarea Pantalla de Loguin y contraseña de usuario

Descripción Backend: Crear BD con MySQL e ingresar listado de servicios y agenda de Profesionales, y clientes. Fronted: Crear pantalla loguin con aviso de registrarse y loguearse y acceder por este medio a la base de datos del sistema, definir si es usuario o profesional de servicios para su posterior registro de nuevo usuario. Comprobar errores.

Tiempo 8 hrs

Prioridad Alta

Pruebas Se comprueba la conexión de la app con la base de datos creada a través de registros ficticios de nuevos usuarios.

Id Req02

Tarea Inicio de BD

Descripción Backend: En la BD del Sistema, crear los registros de las

Tiempo 8 hrs

Prioridad Alta

Pruebas Se comprueba la base de datos

13 profesiones se registra: nombre completo, tipo de servicio que ofrece, dirección, costos de los servicios que ofrece, el horario y la agenda que ofrece que incluye cuanto 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. Comprobar errores.

y su accesibilidad desde el exterior

Id Req03

Tarea Registros

Descripción Crear registros de clientes con nombre completo, genero, edad, dirección de residencia, correo electrónico, que quedan registrados en la base de datos, si los datos no son completos no deja registrarse Comprobar errores.

Tiempo 8 hrs

Prioridad Alta

Pruebas Se accede a la base de datos desde el servidor del sistema para comprobar la comunicación

Id Req04

Tarea Habilitar búsqueda

Descripción En el registro de servicios y listado de profesionales habilitar búsqueda de profesionales de la salud por su nombre, tipo de servicio y ubicación. Comprobar errores.

Tiempo 8 hrs

Prioridad Alta

Pruebas Se accede a la base de datos desde el servidor del sistema para comprobar la comunicación actualizada a la fecha.

Id Req05

Tarea Selección de servicio comprobar agenda

Descripción Cliente: Seleccionar de un profesional y consultar su agenda Mostrar el profesional seleccionado su horari...