UNIVERSIDAD DE CARTAGENA

Facultad de ingeniería
Programa de ingeniería de sistemas

Ingeniería de Servicios de Internet

Ing. Julio C. Rodríguez Ribón

Proyecto de Aula: Comunidad de Ayuda

AyudenMePliz

Primera Iteración.

Presentado por:
Pico Flórez Fabián
Villafañe Castilla Mirania

Cartagena de Indias D.T. y C.

2017-2
 Tabla de Contenido

PROBLEMA ....................................................................................................................... 3
JUSTIFICACIÓN ............................................................................................................... 4
OBJETIVOS ....................................................................................................................... 4
General. ........................................................................................................................... 4
Específicos. ..................................................................................................................... 5
METODOLOGÍA ............................................................................................................... 5
DISEÑO DEL SERVICIO.................................................................................................. 6
MODELO DE DOMINIO ............................................................................................... 6
DIAGRAMA DE CASOS DE USO ............................................................................... 7
DESCRIPCIÓN DE CASOS DE USO ........................................................................... 7
DIAGRAMA DE SECUENCIA DEL SISTEMA ........................................................ 13
DIAGRAMA DE CLASE ............................................................................................. 15
CRONOGRAMA DE ACTIVIDADES ............................................................................... 16
PRESUPUESTO................................................................................................................... 17
 PROBLEMA

En la vida diaria se pueden presentar emergencias, situaciones que son imprevistas que
requieren la atención y solución lo más pronto posible. En estas situaciones no siempre
pueden ser solucionadas por el mismo afectado por lo es necesario pedir la ayuda, el auxilio
de las personas allegadas, que sean conocidas de la persona directamente afectada por lo
que se requiere tener una comunicación oportuna y eficaz con las personas cercanas
quienes pueden acudir para ayudar e informarse de la situación.

En ocasiones la persona que se le presenta una situación de emergencia en ese momento se

encuentra en un lugar con personas desconocidas o puede estar sin compañía, por lo que no
se le es prestada la ayuda que el afectado necesita o no se siente en confianza para
solicitarla.

La persona que sufre un altercado o un imprevisto son las más perjudicadas por que
requiere atención y la solución lo más pronto posible para solucionar su situación
emergente. Los seres más cercanos también se ven perjudicado de estas situaciones de
emergencia, pues una persona se interesa y se preocupa por el bienestar de sus seres
queridos.

Resulta importante si la persona dispuesta a ayudar al afectado sepa cuál puede ser la
solución al problema que aflige al afectado, que sepa cómo debe tratar a la persona y de qué
manera trabajar con él para llegar a una solución, por lo general los que suelen cumplir
estas condiciones son las personas cercanas al afectado.
 JUSTIFICACIÓN

Cuando se presenta la situación de emergencia se requiere una comunicación efectiva entre

el afectado y las personas a quien recurrirá para solicitarle la ayuda, para que así el afectado
este seguro de que recibirá la ayuda que necesita.

Las emergencias exigen flexibilidad y excelente rendimiento de los sistemas de

comunicación de emergencias. La priorización de mensajes, la automatización de la
comunicación, la entrega rápida de mensajes, es importante cuando se presenta una
emergencia para que la víctima se cerciore que la ayuda sea brindada en el momento que la
necesite.

La tecnología permite realizar soluciones de situaciones desventajosas de una forma más

sencilla para los usuarios. Para este caso la aplicación social permitirá a sus usuarios la
comunicación pronta y directa entre un afectado que tenga una emergencia y sus familiares
o personas cercanas para que puedan informarse del estado de la víctima y así poder actuar
a favor de la necesidad y tomar las decisiones en el momento preciso. De esta forma el
afectado podrá tener la tranquilidad de que su petición de ayuda sea respondida con interés
y en el menor tiempo posible.

Los usuarios que se benefician son las personas que se les presenta un caso de emergencia.
De igual manera, se benefician a muchas personas que necesitan o quieren estar informados
del estado sus familiares y personas queridas.

OBJETIVOS
General.
Implementar la tecnología de servicios de internet para desarrollar una aplicación social que
permita a los usuarios enviar una notificación de emergencia a otras personas que usen la
aplicación informándoles de una situación de emergencia en la que se puede encontrar un
familiar o persona cercana con el fin de que active un plan de ayuda.
Específicos.
 Realizar un análisis del problema identificado para diseñar la arquitectura de la
aplicación realizando diferentes modelos.
 Identificar los requisitos funcionales para que la aplicación cumpla su objetivo
 Implementar el software necesario para que el programa cumpla con los requisitos
funcionales.
 Realizar pruebas a la aplicación para identificar errores y realizar posibles mejoras

METODOLOGÍA

La metodología que se usará en el proyecto es el “Rational Unified Process” (RUP, Proceso

Racional Unificado). Que es un proceso de ingeniería de software, que hace una propuesta
orientada por disciplinas para lograr las tareas y responsabilidades de una organización que
desarrolla software. Su meta principal es asegurar la producción de software de alta
calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto
predecible. Por lo que se dividirá el proyecto en etapas que se llevaran acabo de la siguiente
forma.

1. Fase inicial, etapa donde se discutirá la propuesta de desarrollo y el enfoque que

tendrá.
2. Fase de elaboración, donde identificaremos las partes que conformarán el modelo,
su estructura; esta es la fase de modelado.
3. En la fase de desarrollo implementaremos los debidos entornos y lenguajes para
crear la herramienta informática en sí, además de anexos de funcionalidades.
4. En la fase de cierre se realizara pruebas a la aplicación se hará la documentación
para el manejo adecuado de la aplicación por parte del usuario final.
Para la parte de desarrollo de software se hará uso de los lenguajes y modelos de
programación Html5, Ajax, mysql, phonegap los cuales nos permitirá implementar los
diseños de los modelos realizados.
 DISEÑO DEL SERVICIO
MODELO DE DOMINIO
DIAGRAMA DE CASOS DE USO

DESCRIPCIÓN DE CASOS DE USO

Caso de uso: Registrarse.

Actor Principal: El Usuario

Personal Involucrado e Intereses:

Usuario: quiere registrarse en el sistema.

Pre-condiciones:
El usuario no debe haberse registrado con anteriormente.

Garantías de éxito:
El usuario se encuentra registrado en el sistema.
Flujo básico:
 1. El usuario accede al sistema.
2. El usuario solicita registrarse.
3. El sistema pide los datos básicos de registro.
4. El usuario ingresa los datos básicos de registro.
5. El sistema comprueba que el usuario no se haya registrado antes.
6. El sistema registra al usuario.

Flujos alternativos:
I. El usuario ya se ha registrado:
1. El usuario solicita registrarse.
2. El sistema pide los datos básicos de registro.
3. El usuario ingresa los datos básicos de registro.
4. El sistema encuentra que es un usuario ya existente.
5. El sistema muestra un mensaje a la persona diciendo que ya se ha
registrado este usuario.

Frecuencia de uso: Cada vez que una persona solicita registrarse.

Caso de uso: Iniciar sesión.

Actor principal: Usuario.

Pre-condiciones: El usuario debe encontrarse ya registrado en el sistema.

Garantías de éxito: El usuario tiene acceso a las funcionalidades del sistema.

Flujo básico:
1. El usuario accede al sistema
2. El usuario solicita iniciar sesión.
3. El sistema pide los datos requeridos de inicio de sesión.
4. El usuario da los datos requeridos de inicio de sesión.
5. El sistema comprueba que el usuario este registrado.
 6. El sistema permite el acceso a la cuenta al usuario.
Flujos alternativos:
I. El usuario no se ha registrado.
1. El usuario accede al sistema.
2. El usuario solicita iniciar sesión.
3. El sistema pide los datos requeridos de inicio de sesión.
4. El usuario ingresa los datos requeridos de inicio de sesión.
5. El sistema no tiene registro del usuario.
6. El sistema informa al usuario que no se ha registrado.
Frecuencia de uso: Cada vez que una persona solicita iniciar sesión.

Caso de uso: Agregar miembro a comunidad.

Actor Principal: El Usuario

Personal Involucrado e Intereses:

Usuario: quiere agregar miembro a su comunidad.

Pre-condiciones:
El usuario debe haberse registrado con anterioridad.
El usuario debe haber iniciado sesión con su cuenta.
El usuario a agregar debe haberse registrado con anterioridad.

Garantías de éxito:
El usuario agrega un nuevo miembro a su comunidad.
Flujo básico:
1. El usuario accede al sistema.
2. El usuario inicia sesión.
3. El usuario solicita agregar miembro a comunidad
4. El sistema pide información del usuario a agregar.
5. El usuario da la información del usuario a agregar.
6. El sistema identifica al usuario a agregar.
7. El sistema identifica la comunidad a la que se le va agregar el usuario.
 8. El usuario da información de la comunidad.
9. El sistema agrega al miembro a la comunidad.
10. El sistema muestra un mensaje de miembro agregado
Flujos alternativos:
I. El usuario a agregar no se encuentra registrado.
1. El usuario solicita agregar miembro a una de sus comunidades.
2. El sistema pide información de usuario a agregar.
3. El usuario ingresa la información del usuario a agregar.
4. El sistema no encuentra al usuario buscado.
5. El sistema informa que el usuario no se encuentra registrado.
Frecuencia: Cada vez que el usuario solicite agregar un miembro a una comunidad.

Caso de uso: solicitar ayuda.

Actor Principal: Afectado, comunidad

Personal Involucrado e Intereses:

Afectado: quiere enviar notificación de ayuda a su comunidad.

Comunidad: quiere recibir la notificación enviada por el afectado

Pre-condiciones:
El afectado debe haberse registrado con anterioridad.
El afectado debe haber iniciado sesión con su cuenta.
El afectado debe tener alguna comunidad con al menos 1 miembro.

Garantías de éxito:
El afectado envía su notificación de emergencia.
La comunidad recibe notificación de emergencia
Flujo básico:
1. El afectado accede al sistema.
2. El afectado inicia sesión.
3. El afectado solicita pedir ayuda
 4. El sistema muestra tipo de ayuda.
5. El afectado selecciona tipo de ayuda urgente
6. El sistema manda notificación a todos los miembros de la comunidad del afectado
con su ubicación.
7. El sistema muestra un mensaje de ayuda pedida

Flujos alternativos:
I. El afectado selecciona ayuda personalizada.
1. El sistema muestra cantidad de miembro a enviar notificación.
2. El afectado da cantidad de miembro a enviar notificación.
3. El sistema ofrece para dar la notificación en mensaje
4. El afectado da su mensaje
5. El sistema envía mensaje a la cantidad de miembros de la comunidad dados,
6. El sistema muestra un mensaje de éxito.
Frecuencia: Cada vez que el afectado envía notificación de ayuda.

Caso de uso: Ayudar Afectado.

Actor principal: Miembro de la comunidad.
Pre-condiciones:
El miembro de la comunidad debe haberse registrado con anterioridad.
El miembro de la comunidad debe haber iniciado sesión con su cuenta.
El miembro de la comunidad debe pertenecer a la comunidad que el afectado está
alertando.
Garantías de éxito: miembro de la comunidad brinda su ayuda al afectado.

Flujo básico:
1. El afectado hace el envió de notificación de ayuda
2. El sistema alerta a la comunidad de la emergencia.
3. La comunidad ve quien es el afectado, su localización y los detalles de la
emergencia.
4. El miembro de la comunidad toma la responsabilidad del afectado.
 5. El sistema informa a la comunidad que miembro ha tomado responsabilidad
del afectado.
6. El miembro de la comunidad acude a ayudar al afectado.

Flujo alternativo:
I. Otro miembro de la comunidad se hace responsable del afectado.
1. El afectado hace el llamado de emergencia.
2. El sistema alerta al miembro de la comunidad de la emergencia.
3. El miembro de la comunidad ve quien es el afectado, su localización y
los detalles de la emergencia.
4. El sistema informa de que otro miembro se hizo responsable del
afectado.
5. El miembro de la comunidad decide si va o no al lugar donde se
encuentra el afectado.

II. El miembro de la comunidad no puede acudir a ayudar al afectado.

1. El afectado hace el llamado de emergencia.
2. El sistema alerta al miembro de la comunidad de la emergencia.
3. El miembro de la comunidad ve quien es el afectado, su localización y
los detalles de la emergencia.
4. El miembro de la comunidad decide no tomar responsabilidad del
afectado.
Frecuencia: Cada vez que un afectado alerte a la comunidad a la que pertenece el actor
principal.
DIAGRAMA DE SECUENCIA DEL SISTEMA

Registrar Usuario.

Iniciar sesión.
Ayudar Afectado.

Agregar miembro a comunidad.

Solicitar ayuda.

DIAGRAMA DE CLASE
 CRONOGRAMA DE ACTIVIDADES

Actividades Iteración 1 Iteración 2 Iteración 3

Semana 1 2 3 4 1 2 3 4 1 2 3 4
Análisis de la
Propuesta
Modelado de la
Propuesta (Modelo
de dominio, casos de
uso y diagrama de
secuencia del
sistema)
Entrega de primera
parte, 1 iteración
Revisión y
Replanteamiento del
modelo
Estudio de
funcionalidades
adicionales
Documentación sobre
los lenguajes
empleados
Programación de la
herramienta
informática
Anexo de
funcionalidades
adicionales
Entrega de segunda
parte, 2 iteración
Revisión de los
resultados.
Adición de partes de
la documentación
faltante
Revisión del
producto terminado
Presentación final del
proyecto
 PRESUPUESTO

Mes Mes Mes Mes Costo Costo

Componente cantidad
1 2 3 4 unitario total

Mano de obra
Analista de software 60 h 60 h 30 h 30 h 180 h 3000000
Desarrollador de software 0h 80 h 80 h 100 h 260 h 4000000
Hardware

Depreciación o uso informático

60 h 60 h 30 h 30 h 180 h 160000
de computadora del analista

Depreciación o uso informático

de computadora del 0h 80 h 80 h 100 h 260 h 120000
desarrollador

Depreciación o uso informático

de equipo móvil del 0h 80 h 80 h 100 h 260 h 420000
desarrollador

Software
Ajax 0 0 0 0 1 0 0
Brackets 0 0 0 0 1 0 0
Phone App 0 0 0 0 1 0 0
Star UML 0 0 0 0 1 0 0
HTML5 0 0 0 0 1 0 0
My SQL 0 0 0 0 1 0 0
PHP My Admin 0 0 0 0 1 0 0
Servicios
Energía eléctrica 158000 632000
1 1 1 1
Internet 4 100200 400800
plan plan plan plan
26 26 26 26
Transporte 104 4000 416000
días días días días

Sub total 9’148800

Imprevistos 100000
Total 9’248800