Sistema para InAlpes inmobiliaria

Documento de Análisis
del software inmobiliaria
InAlpes

1
 Histórico de Revisiones

Fecha Versión Descripción Autor

25/10/2016 <1.0> Versión inicial (proporcionaba al Jair prada, Alexander

usuario la página inicial con su Romero,Johan
menú pero sin ninguna función ) Romero
07/11/2016 <1.0> Revisión (proporcionaba al usuario Jair prada, Alexander
la página inicial con su menú , Romero,Johan
además de dar la opción de Romero
registrarse como usuario nuevo )
07/11/2016 <1.1> Ajustes (Proporciona las opciones Jair prada, Alexander
de registrar ,eliminar y editar los Romero,Johan
siguientes parámetros: Romero
Usuario,Inmueble
)

2
Tabla de Contenido

3
1. INTRODUCCIÓN

En este documento se presenta el análisis del Sistema Altamente Escalable (en adelante SAE),
el objetivo es presentar los reportes e información que será publicada en el SAE, los sistemas
externos y sus respectivos mecanismos de integración, los mucus y diseño de interfaz gráfica
de usuario, el proceso de desarrollo de software e implementación en el proyecto.

Los reportes e información que será publicada para el público en general, corresponde a los
Eventos de Amenaza Geológica (en adelante EAG), de sismos, volcanes y movimientos en
masa, en la sección 5.7 del documento se amplía la información.

Los sistemas externos con lo que el SAE debe interactuar, corresponden a las fuentes de
datos, de las cuales el SAE debe extraer información de sismos, imágenes de volcanes, una
biblioteca SharePoint de donde extrae información de publicaciones y otra de donde extrae
una copia del Home del portal principal. Adicionalmente, interactúa con las redes sociales
como Twitter y Facebook.

A nivel de interfaz gráfica de usuario se presenta el respectivo diseño para temas como
configuración del SAE, usuario, sedes, publicaciones, reportes, tablero de control y
presentación de EAG.

Para el desarrollo del SAE (Sistema Altamente Escalable), se propone utilizar SCRUM como
metodología de desarrollo software. Se presenta una visión general del proceso de desarrollo
de software y una descripción de la implementación de Scrum en el proyecto.

En la sección de implementación de Scrum en el proyecto, se define: las reuniones, los

elementos como la pila del producto, la pila del sprint y los roles. La pila del producto,
relaciona todos los requerimientos funcionales del producto. La pila del sprint, relaciona los
requerimientos agrupados por cada sprint. Los requerimientos, presentados como historias
de usuario, no incluyen un detalle excesivo, si no, el detalle suficiente para su ejecución.

1.1 PROPOSITO Y AUDIENCIA (espesificacion a nivel funcional para la inmobliaria ,

esta dirigido a todas las personas que influyen )

El objetivo principal de este documento es plasmar de forma clara y concisa las necesidades
del cliente en términos del software que se va a realizar. La documentación será guía para
validar e inspeccionar la construcción del software en cada una de sus etapas………………

El documento está dirigido al cliente, al equipo de desarrollo……….. Adicionalmente también

puede ser usado por los usuarios que utilizarán el software y que necesiten definir nuevos
requerimientos, en este caso …………………………

4
1.2 CONTEXTO Y ALCANCE

La inmobiliaria Inalpes es una empresa líder del mercado inmobiliario, con más de 40 años de
experiencia y solidez, Miembros de la Lonja de Propiedad Raíz de Bogotá. Su objetivo es
ofrecer un excelente servicio, respaldo, transparencia y comercializar ágilmente su propiedad
en materia de Arriendos, Ventas y Avalúos. Cuentan con un excelente equipo humano, red
comercial a través de nuestras sucursales y oficinas del Grupo. Han construido su prestigio a
través de un servicio transparente, una sólida experiencia, cumplimiento, conocimiento y un
constante liderazgo en el sector el cual ponemos a su disposición. La filosofía de Inalpes se
basa en comprometernos en conservar, proteger y fortalecer su patrimonio. Estamos
dispuestos a solucionar todas sus necesidades en el sector inmobiliario.

Alcance :

•El nuevo sistema de apoyar la reducción de costos operativos y disminuir el tiempo total del
proceso de arrendamiento

• Se desea aumentar los 500 clientes con los que se cuenta en el momento. Se espera
contar con al menos 3,000 nuevos usuarios registrados por año. Se espera llegar
igualmente a realizar 50,000 transacciones al año.

• El nuevo sistema debe apoyar de manera rápida y con mínimo esfuerzo las estrategias
comerciales de la empresa. Como primera medida se creará un nuevo sistema basado en
la idea de subastas, de tal forma que cada inmueble sea subastado para
arrendamiento en un periodo de 48 horas

• La intervención humana en el proceso debe minimizarse

• Se debe buscar favorecer el autoservicio por parte de los clientes

• La información consolidada del país debe estar en línea y disponible de manera inmediata

• La liquidación de comisiones para los comerciales debe ser flexible y configurable con
mínimo esfuerzo

• La comunicación con entidades de riesgo y consultas de entidades de crédito debe hacerse

de forma automática

5
• El pago por conceptos de estudio de solicitudes debe hacerse con un botón de
pagos electrónicos. Inicialmente PSE pero posteriormente cualquier otro botón sin que esto
implica un desarrollo adicional.

• La confidencialidad de la información de los clientes es fundamental, así como la seguridad

en los pagos electrónicos

• Según un análisis de mercado, existen cerca de 150 empresas similares a InAlpes, por lo que
estas también son un cliente potencial en el nuevo esquema de negocio. InAlpes desea
que su portal se convierta en el sitio referencia en la comunidad de finca raíz,
ofreciendo y arrendando su plataforma a otras pequeñas inmobiliarias, cobrando una comisión
por cada negocio realizado a través del portal de InAlpes.

• El portal debe permitir registrar opiniones sobre los otros participantes, bien sean
propietarios o arrendatarios. Por ejemplo, un arrendatario puede opinar sobre las
condiciones de una oficina o sobre el trato recibido por parte de una inmobiliaria o
un arrendador

• El nuevo sistema debe proveer agilidad a los comerciales, quienes deben utilizar la
tecnología móvil para minimizar el tiempo de proceso de ventas y arrendamientos

• El portal deberá ofrecer la funcionalidad para que el propio usuario ingrese fotos y videos de
los inmuebles

• El sistema debe ofrecer diferentes mecanismos de búsqueda de inmuebles. El

tiempo de respuesta de una búsqueda debe ser
mínimo.

• El sistema debe permitirle a una persona subscribirse a categorías de inmuebles en los que
está interesado y cuando se publique un inmueble con dichas características se le debe
notificar a todos los interesados

• El sistema debe poderse configurar para diferentes estilos de negocio. Inicialmente subastas
sobre inmuebles y propuestas directas pero con la posibilidad definir nuevas estrategias

• Se debe contar con un potente motor de búsqueda que cumpla con criterios sobre
los inmuebles en los que un usuario está interesado

• El sistema debe soportar la inicialmente la venta y arrendamiento de inmuebles pero debe

poder ser extendido a venta y alquiler de fincas, casas de recreo, vehículos o cualquier otro
tipo de bien con costo mínimo

6
• La generación de reportes e indicadores de cómo va el negocio debe ser instantánea

• Cuando un cliente solicita una cita para ver un inmueble se debe buscar en la agenda del
primer comercial disponible en ese espacio y asignar la cita. El usuario debe recibir una
respuesta en menos de 2 segundos

• Una vez el sitio se vuelva conocido es posible que se venda publicidad, por lo que el sistema
debe poder ser configurado para manejar las pautas comerciales sin que esto implique
desarrollos adicionales. En este sentido se espera que la adición de una nueva pauta
publicitaria no tome mas de 10 minutos

• Se espera la publicidad ofrecida se determine de acuerdo al perfil del usuario que visita la
página

• Se espere que el portal sea utilizado para ofrecer servicios de terceros, como electricidad,
plomería, construcción y arreglos locativos, Estos servicios ofrecidos por terceros a través del
portal deben poderse integrar con el sistema de InAlpes rápidamente, para lo cual
se ofrecerá un API a los comercios que paguen una mensualidad. El sistema debe validar que
los servicios ofrecidos por terceros sean visibles si el comercio está al día en sus pagos

• Se requiere que la arquitectura y diseño del sistema se termine en 4 meses

• El desarrollo del sistema deberá estar a cargo del grupo de desarrollo de InAlpes (5
ingenieros de desarrollo con experiencia en Java)

• El sistema deberá ser implementado y probado en 4 meses calendario

• La organización desea minimizar los costos de mantenimiento y administración del sistema

por lo que la solución debe ser Web y basada principalmente en JEE

• Una vez el sistema entre en producción no se realizarán inversiones adicionales en

desarrollo, por lo que el sistema debe escalar fácilmente con el ingreso de nuevos servicios
y usuarios.

• El sistema debe estar disponible todo el día, dado los tipos de clientes que se busca captar.

• Actualmente se aprobó la compra de un aplicativo para manejar la contabilidad de

organización. Se desea que la interoperabilidad entre el sistema a desarrollar y la nueva
contabilidad sea completo, aunque aún no se ha decidido cuál software contable comprar.

7
Los componentes que se van a realizar son los siguientes

• El sistema debe ofrecer la opción de registra eliminar usuario de distintos tipos (cliente,
administrador).

• El sistema debe ofrecer la opciones de registrar editar y eliminar inmuebles.

• La generación de reportes e indicadores de cómo va el negocio debe ser instantánea.

• La liquidación de comisiones para los comerciales debe ser flexible y configurable con
mínimo esfuerzo

• La comunicación con entidades de riesgo y consultas de entidades de crédito debe hacerse

de forma automática

• El pago por conceptos de estudio de solicitudes se hará con un botón de pagos

electrónicos. Inicialmente PSE, pero posteriormente cualquier otro botón sin que esto implica
un desarrollo adicional.

• La confidencialidad de la información de los clientes es fundamental, así como la seguridad

en los pagos electrónicos

• El sistema debe soportar la inicialmente la venta y arrendamiento de inmuebles, pero debe

poder ser extendido a venta y alquiler de fincas, casas de recreo, vehículos o cualquier otro
tipo de bien con costo mínimo

• El sistema debe soportar el registro de inmobiliarias es decir registra diferentes sucursales.

• El sistema debe soportar la petición de avaluó de inmuebles.

• El sistema debe soportar la conexión con un buscador de inmuebles reportados en la lista

Clinton

• El sistema debe soportar la conexión con un sistema de que evaluación de certificado de

tradición y libertad de los inmuebles registrados.

• El sistema debe soportar la conexión con un sistema de central de riesgos para la evaluación
de los posibles clientes que determinara la viabilidad del negocio.

8
1.3 ORGANIZACIÓN DEL DOCUMENTO

El presente documento se organiza por secciones. En la primera sección se comienza por

introducir las generalidades del proyecto, describiendo el propósito del documento, al igual
que las convenciones, términos y referencias bibliográficas del mismo. Posteriormente, la
segunda sección aborda la problemática de interés y describe brevemente el sistema que se
desea diseñar, los objetivos de la arquitectura solución y los “Stakeholders” del proyecto. En
la tercera sección se documentan los motivadores arquitecturales: atributos de calidad,
motivadores de negocio, restricciones tecnológicas, escenarios de calidad y vistas
arquitecturales.

1.4 TERMINOLOGIA 3

TERMINO DESCRIPCIÓN
Usuario Cualquier persona registrado en el
sistema

Administrador Usuario registrado con permisos

especiales generalmente estos
usuarios son empleados de la empresa
Cliente Usuario registrado en el sistema de la
empresa con permisos limitado tienen
acceso a comprar,vender,alquilar etc.
Inmueble Edificio o casa destinados a vivienda u otro
fin y que son propiedad de alguien

Reporte Noticia , informe o suceso reciente, sobre

una situación variable de un negocio ,
cliente, inmueble
Avaluó Estimación del valor comercial de un
inmueble o artículo reflejado en cifras
monetarias por medio de un dictamen
técnico imparcial
Comisión Liquidación que reciben los comerciales
gracias a negocios satisfactorios

9
Perito Experto reconocido como una fuente
confiable encargado de evaluar el valor de
los inmuebles
Registrar Escribir en un registro los datos de un
inmueble, en especial cuando es de
carácter oficial
Eliminar Eliminar en un registro los datos de un
inmueble, en especial cuando es de
carácter oficial
Editar Modificar en un registro los datos de un
inmueble, en especial cuando es de
carácter oficial
Índex Página principal del sistema

1.5 REFERENCIAS DEL DOCUMENTO //documento que espesifica (ventas, historia

de la empresa,de los reportes etc…)

[1] Bruegge B, Dutoit AH. Ingeniería de Software orientada a objetos. 1st ed. Trujano G.
México: Prentice Hall; 2002. Página [97, 108].

[2] IEEE (Institute of Electrical and Electronics Engineers), IEEE Recommended Practice
for Software Requirements Specificacitions, IEEE-SA Standards Board, Junio 1998.

2. GENERALIDADES DEL PROYECTO

2.1 Problema a resolver 1

La gerencia de InAlpes está preocupada pues la empresa tiene unos altos costos operativos y
los clientes cada vez utilizan menos los servicios de la empresa, lo que la ha llevado a una
crisis económica de la empresa. Los clientes utilizan cada vez mas servicios en Internet que
ofrecen tiempos de respuesta mas cortos y cobran menos comisiones a los clientes.

10
InAlpes funciona con un sistema básico de negocio. Cuando un cliente desea registrar
un bien inmueble con InAlpes, se comunica telefónicamente con la empresa y se concreta
una cita con un comercial de la compañía. Esta primera cita se da entre 4 y 6 días hábiles
luego del primer contacto. Durante la cita, el comercial hace un avalúo del bien, llena un
formato de registro con al descripción del sitio y una descripción de los alrededores del
inmueble. En paralelo se llena la información personal y comercial del dueño del bien.
Cuando el comercial regresa a la empresa hace una análisis tanto de las probabilidades de
éxito del negocio como del dueño del inmueble. Este análisis se hace para evitar arrendar
propiedades que estén en procesos legales o comprometidas en lavados de dinero. Para esto,
se investiga en la lista Clinton al propietario, así como en centrales de riesgo y se verifica el
certificado de libertad del inmueble. Este proceso puede durar unos 8 días. Este proceso se
hace siempre, así el propietario ya sea cliente de InAlpes. Si todos los pasos anteriores se
cumplen sin novedades, el comercial regresa al inmueble, toma fotos del sitio y pega uno o
dos avisos en sitios visibles con los teléfonos de la inmobiliaria. Toda la información del
inmueble se consigna en una hoja de Excel que se distribuye por correo electrónico a las
diferentes sucursales del país, con los datos del comercial a cargo. Si un cliente llama
interesado en un inmueble, la secretaría de cada sucursal toma la llamada y pregunta por la
ubicación del inmueble. Busca el inmueble en el archivo Excel y trata de identificar el sitio por
el barrio y la dirección aproximada. Cuando se tiene un candidato se le pasa la llamada al
comercial a cargo. Si este no se encuentra en la oficina se toman los datos de quien llama y
se le envían por correo electrónico al comercial a cargo. Si el comercial esta en la oficina,
contesta la llamada y suministra la información del inmueble al interesado. De esta
entrevista se puede concretar una visita para conocer el inmueble, lo que típicamente ocurre 3
días después del primer contacto.
Si surge una persona interesada, se le pide que llene un formato con información personal y
comercial. El interesado debe consignar una suma por concepto de estudio de solicitud en
una cuenta de la empresa y llevar el formulario, los documentos anexos y el comprobante de
consignación a las oficinas de InAlpes. Los documentos son analizados cada miércoles por
un analista de InAlpes en la oficina principal. El analista estudia los documentos y si
considera que el negocio es viable y el interesado clasifica como un cliente sin riesgo, da luz
verde al negocio. Finalmente, InAlpes contacta al propietario y concreta una cita para
presentarle al interesado. Si el propietario aprueba al interesado, el negocio se cierra. De lo
contrario el inmueble continúa en demostración y el proceso se repite. Cuando un negocio
se cierra, el comercial le notifica por correo a la secretaría de la respectiva sucursal, quien
cada lunes actualiza los listados en Excel y los hace circular entre las oficinas. Al final del mes,
la secretaria notifica a la gerencia de los negocios cerrados con sus respectivos montos y el
nombre del comercial encargado. Con base en esta información se liquidan las
comisiones para los comerciales. En otra hoja de Excel, se ingresa la nueva
información de alquileres y se generan manualmente las cuentas de cobro a los inquilinos
(en el caso de arrendamiento). Esta labor la realiza la secretaría de cada oficina.

11
2.2 Descripción del sistema a desarrollar /agruparlos por modulos voy a desarrollar
una ap web enfoque mbc (modelo vista controlador ) donde anivel funcional estará
compuesto por los modulos de gestión de clientes , usuario reposrtes)

XXXX es una aplicación que va orientada a niños sordos entre ocho y doce años a los cuales
se les están realizando terapias de XXXX. La aplicación tiene como propósito ser un
mecanismo que favorezca la inclusión de estos niños sordos en la adquisición de la lengua del
español incrementando su inmersión en la lengua.

De manera general la aplicación tiene tres módulos principales en los cuales se van a distribuir
los requerimientos del cliente. A continuación se hace una breve descripción de cada uno de
los módulos:
• Módulo de trabajo: En este módulo se implementan todas las características y
funcionalidades relacionadas con el nivel 1 de XXXX.
• Módulo de actividades: Este módulo está enfocado en la creación de nuevas actividades
relacionadas con los niveles 2 y tres que no están implementados en la aplicación.
• Módulo de administración: Este módulo tiene relación con la gestión de las cuentas de
usuario y de las estadísticas que se manejan por cada una de esas cuentas.

3. SISTEMAS EXTERNOS

Los sistemas externos del Inalpes obedecen a las fuentes desde donde el sistema extrae
información y los sistemas a través de los cuales se lanzan las notificaciones. Dentro de los
sistemas que se extrae información se encuentran, Pasarela de pagos (PSE) donde la
plataforma única y exclusivamente realiza el proceso de pago de alguno de los servicios
ofrecidos por Inalpes , Lista Clinton (Infolaft) se conectara con los datos de alguno de los
inmuebles para verificar que este no este reportado por lavado de activos ,Centrales de
riesgo(MiDatacredito)accede a los datos de un cliente en específico y realiza una búsqueda en
su base de datos para así retornar la calificación del usuario estudiado, Certificado de tradición
y libertad(SNR) accede a los datos de los inmuebles para realizar una búsqueda y verificar
que no exista ningún embargo sobre la propiedad

En total son cuatro sistemas externos, donde el se extrae información se realizan consultas y
como paso final se hace uso de una notificación

12
4. PROTOCOLOS Y MECANISMOS DE INTEGRACIÓN CON LOS
SISTEMAS EXTERNOS

Los protocolos utilizados para la integración con los sistemas externos PSE, MiDatacredito,
Infolaf y SNR todos están regidos por sus respectivas APPI en donde se especifican los
protocolos usados por las mismas para establecer conexión con nuestro servicio.

5. HERRAMIENTAS DE DESARROLLO

El sistema se está desarrollando sobre el ambiente de programación Netbeans 8.0.1

En el servicio de computo de aplicación web, las tecnologías a utilizar en el desarrollo, de los

componentes funcionales son: , HTML, CSS, JavaScript, Apache 2.4.20

En el servicio de almacenamiento de datos relacional se puede utilizar un motor de base de

datos MySQL 5.7

El sistema manejara un administrador de las distintas versiones por las que pasa el código
fuente a lo largo del desarrollo. El control de versiones del código fuente del proyecto se
realizará con GitHub.

6. MOCKUPS Y DISEÑO DE INTERFAZ GRÁFICA DE USUARIO

En este capítulo se presentan los mockups y su respectiva descripción de acuerdo con cada
uno de los módulos funcionales que el sistema debe…………………………

13
La zona bordeada en verde tiene el nombre de la empresa Inalpes con su respectivo logo en
esta mismas se encuentra en la parte superior derecha el menú donde tenemos estas opciones
Crear persona, Usuario, Lista Clinton , Contáctenos Servicios.

La zona bordeada de amarillo será la que cambiará según la opción elijamos del menú en este
caso nos encontramos con la opción de usuario y dentro de esta opción tenemos un formulario
con los cuadros de texto de Nombre, Apellidos, Correo electrónico, Numero celular, Numero
Cedula y Que te interesa

14
7. ANALISIS DE REQUERIMIENTOS

Crear Usuario
Eliminar Usuario
Editar Información de Usuario
Crear Inmueble
Eliminar Inmueble
Editar Información de Inmueble
Crear Reporte
Eliminar Reporte
Editar Información del Reporte
Crear Inmobiliaria
Eliminar Inmobiliaria
Editar Información de Inmobiliaria
Crear Avaluó
Eliminar Avaluó
Editar Información de Avaluó
Consultar Lista Clinton
Consultar Central de riesgos
Consultar Certificado de tradición y libertad

15
7.1 STAKEHOLDER (gerentes y lo que proponen)
A continuación se describen………… Descripcion
Nombre Descripción
Gerente General
Gerente Sistema
Gerente Comercial
Ejecutivo Comercial
Cliente

16
7.2 REQUERIMIENTOS FUNCIONALES
A continuación se especifican………….

7.3 Lista de requerimientos

Lista nombres de los requerimientos

7.4 Especificación

7.5 REQUERIMIENTOS NO FUCNIONALES

A continuación se especifican…………….
Ejemplo 1
17
Ejemplo 2

7.6 RESTRICCIONES TECNOLOGICAS

A continuación se describen……………………..

18
19
<<<<<<<<<<<<EJEMPLO UTILIZANDO SCRUM>>>>>>>>>>>>>>>>>

PROCESO DE DESARROLLO DE SOFTWARE: SCRUM (como se aplica el

proyecto en base a mi metodologia)

Scrum es un proceso de desarrollo de software, que fue seleccionado para la implementación

del SAE, por ser una metodología de desarrollo ágil que permite una adaptación y evolución
continua del proyecto bajo condiciones de surgimiento de nuevos requerimientos o cambios
en los requerimientos durante todo el proceso de desarrollo. Scrum principalmente utiliza una
estructura incremental fundamentada en iteraciones y revisiones periódicas. Para mayor
información sobre Scrum ver el Anexo N° 1.

SCRUM EN EL PROYECTO DEL SAE

De acuerdo a las prácticas de gestión ágiles descritas en el proceso de desarrollo SCRUM, se

definen para el proyecto del SAE los elementos de desarrollo de la siguiente forma:

LAS REUNIONES

La duración de un sprint se definió en 1 semanas y las reuniones que se realizan son:

● Una primera reunión de lanzamiento del sprint donde se determina las historias de
usuario que se deben trabajar para cumplir con el objetivo del sprint.
● Una segunda reunión que se realiza 1 semana después de iniciar el sprint, con el objeto
de hacer seguimiento del avance y tomar correctivos si es necesario.
● Una tercera reunión donde se ejecuta el post mortem del sprint y se hace el
lanzamiento de un nuevo sprint.

20
LOS ELEMENTOS

Pila del producto (Product Backlog)

La pila del producto que corresponde a las historias de usuarios definidas en el proyecto se
pueden ver a continuación:

LISTA DE HISTORIAS DE USUARIO

HISTORIA
DE CRAWLER HOME-PORTAL
USUARIO
HU-001 EXTRAER COPIA DEL HOME DEL PORTAL
HU-002 EXTRAER IMÁGENES
HU-003 EXTRAER ARCHIVOS DE PUBLICACIONES
HU-004 EXTRAER ARCHIVOS JSON

HISTORIA
DE ADMINISTRACIÓN DE CUENTAS DE CORREO Y REDES SOCIALES
USUARIO
HU-117 REGISTRAR CUENTAS DE TWITTER
HU-118 REGISTRAR CUENTAS DE FACEBOOK
HU-119 EDITAR CUENTAS DE TWITTER
HU-120 EDITAR CUENTAS DE FACEBOOK
HU-121 REGISTRAR CUENTAS (TIPO LISTA) DE CORREO INSTITUCIONAL
HU-122 CREAR GRUPOS DE CUENTAS DE REDES SOCIALES
HU-123 CONSULTAR GRUPOS DE CUENTAS DE REDES SOCIALES
HU-124 EDITAR GRUPOS DE CUENTAS DE REDES SOCIALES
HU-125 ASOCIAR CUENTAS DE REDES SOCIALES POR EAG
HU-126 ASOCIAR CUENTAS DE CORREO POR EAG

21
ESPECIFICACIÓN DE HISTORIAS DE USUARIO

HU-013 GENERAR NOTIFICACIÓN DE CORREO POR

Narrativa
PUBLICACIÓN DE SISMOS
Escenario
EO-14
Operacional
Como Sistema SAE
Que el sistema genere de forma automática una notificación a una lista
Yo Quiero de correo institucional del SGC, si el estado de la notificación se
encuentra activa (A).
De Forma Cada vez que se realice una publicación de sismos, automática o manual,
que se genere una notificación.

CRITERIOS DE ACEPTACION
Escenario Cuando existe una lista de correo configurada
Dado Que se desea generar una notificación.

Se realiza la publicación de un nuevo sismo y existe una lista de correo

Cuando configurada.
Se debe tomar la descripción de la publicación que viene en el JSON y
Entonces enviarla en el cuerpo del correo que se genera como notificación a la lista
de correo configurada.

Escenario Cuando NO existe una lista de correo configurada

Dado Que se desea generar una notificación.

Cuando Se realiza la publicación de un nuevo sismo y NO existe una lista de correo

configurada.
Se debe generar una notificación al administrador del SAE notificando la
Entonces falta de la lista de correo.

22
Narrativa HU-001 EXTRAER COPIA DEL HOME DEL PORTAL
Escenario
EO-12
Operacional
Como Sistema SAE
Que el Sistema realice la extracción de la copia del home del portal, a
través de un proceso automático tipo crawler si el estado de ejecución
Yo Quiero del crawler es activo (A). El crawler tiene configurado en los parámetros
de configuración el estado de ejecución por defecto Activo (A).

De acuerdo con los parámetros de ejecución previamente configurados

De Forma tome la copia del home desde el origen y la persista en el
que almacenamiento en blob.

CRITERIOS DE ACEPTACION
Escenario Sistema SAE
que el sistema SAE requiere realizar la copia del home del portal, a
Dado través del crawler

Cuando
La copia del home del portal se encuentra en una fuente de datos externa.
El crawler debe extraer una copia del home del portal y persistirla en el
Entonces almacenamiento en blob.

Escenario No existe archivo html

23
 que el sistema SAE realiza la copia del home del portal, a través del
Dado crawler

Cuando NO existe un archivo html en la fuente de datos externa.

Se debe generar una notificación al administrador del SAE.
Entonces

Escenario No se puede establecer conexión con la fuente de datos

que el sistema SAE realiza la copia del home del portal, a través del
Dado crawler

Cuando No se puede establecer conexión con la fuente de datos

Se debe generar una notificación al administrador del SAE.
Entonces

Narrativa HU-005 VERIFICAR ESTADO DEL CRAWLER HOME-PORTAL

Escenario
EO-09
Operacional
Como Sistema SAE
A través de un proceso automático y un servicio RESTful, revisar
Yo Quiero periódicamente el estado del crawler.

Cuando el componente monitor envíe un mensaje de verificación, el

De Forma crawler debe responder el mensaje verificando así, que se encuentra
que activo. En el caso que no responda, se toma como indicador para
determinar que el crawler no está funcionando.

CRITERIOS DE ACEPTACION
Escenario El crawler responde el mensaje de verificación
Dado Que se desea revisar el estado del crawler.

Cuando El crawler se encuentra funcionando correctamente

24
 Debe responder con un valor "A", confirmando así el estado activo. Si
Entonces responde con un valor "P", confirma el estado pasivo.

Escenario El crawler no responde el mensaje de verificación

Dado Que se desea revisar el estado del crawler

Cuando El crawler no se encuentra funcionando y no responde el mensaje de

verificación
Se lanza una acción de reinicio del servicio de computo donde se
encontraba el crawler; los crawler se reinician en estado pasivo.
Adicionalmente, se escribe la falla en los logs, se lanza un mensaje de
Entonces activación del crawler que se encuentra en estado pasivo en el servicio
de cómputo de respaldo y se lanzan las notificaciones a las cuentas pre
configuradas del administrador del SAE.

Los roles

Para el proyecto se definieron los siguientes roles que se muestran en la Tabla 8

ROLES PERSONAS
Propietario del SGC Paola Maecha
producto
SaucoTech Juan Pablo Ortiz,
Scrum master
Nixon Duarte A.
Equipo de SaucoTech
desarrollo
Otros interesados1 OVS y MM

1
Otros interesados hace referencia a los Observatorios
25