• No results found

Additional Features

QoS Architecture

4.4 Additional Features

BACKGROUND

Cron Services y Task

Queues Job Schedulling

ESCALABILIDAD Escalabilidad automática Escalabilidad manual y

programática

Portal Web Si Si

54

CAPÍTULO 7 CASO DE ESTUDIO

En este capítulo se planteará un caso de estudio para unificar los conceptos vistos en los capítulos anteriores.

INTRODUCCIÓN

El caso de estudio se enfocará desde el punto de vista de un proveedor ficticio, que necesita realizar una propuesta comercial y técnica para construir una solución SaaS para uno de sus clientes. Este proveedor no tiene experiencia construyendo aplicaciones SaaS sobre plataformas como servicio, por lo que necesita realizar un análisis técnico que le permita saber si está en condiciones de construir este tipo de soluciones, el esfuerzo que le demandará y contar con lineamientos de diseño que le permitan armar una propuesta consistente y factible. El presente capítulo oficiará del análisis técnico que necesita este proveedor ficticio para armar su propuesta.

Con el aporte del análisis técnico, el proveedor estará en condiciones de:

 Minimizar los riesgos de construcción, ya que contará con alternativas de diseño de los puntos críticos del sistema.

 Estimar tiempo y esfuerzo de construcción.

 Elegir correctamente una plataforma como servicio de acuerdo a las necesidades del proyecto y del cliente.

 Implementar ciertas características específicas del proyecto en diferentes plataformas como servicio.

El caso de estudio no solo mostrará cómo se implementan en una plataforma como servicio los requisitos técnicos de una solución SaaS descriptos en los capítulos anteriores, sino que también mostrará cómo se pueden implementar ciertas

características específicas del proyecto que van más allá de los requisitos técnicos propios de las soluciones SaaS.

A continuación se presenta el sistema que necesita el cliente del proveedor ficticio.

SISTEMA DE ALERTA DE NOTICIAS Descripción general

Una empresa de análisis de medios necesita desarrollar un sistema de alerta de noticias para sus clientes. Los clientes son empresas u organismos que necesitan ser alertados sobre las noticias que se publican en los distintos medios online cuyos temas estén relacionados con diferentes pautas definidas por el cliente.

55

Una pauta es un conjunto de reglas de concordancia, que pueden incluir temas (política, economía, salud), palabras claves (estado, gobierno, unlp), medios (clarín, la nación, página 12) y otros datos relevantes para refinar la búsqueda.

Las noticias que coincidan con las pautas serán enviadas por email a los diferentes destinatarios dentro de la misma organización.

Este sistema debe presentar una interfaz web de modo tal de permitir al cliente acceder desde sus oficinas. Los destinatarios pueden acceder a la web y ver las noticias online. Cada cliente u organización puede personalizar el sitio web asociado a su cuenta según sus necesidades. Por cada cliente u organización habrá un usuario administrador que será el encargado de la personalización del sitio, la definición de pautas y palabras claves, la definición los diferentes destinatarios dentro de la misma organización.

La extracción de la información online se realizará utilizando un proceso automático de scrapping a los diferentes medios de internet.

El proceso completo de extracción debe generar una única base de datos con las noticias. Se debe tener en cuenta que el motor de base de datos elegido debe soportar

mecanismos de full text search.

La facturación a cada organización dependerá de la cantidad de medios a analizar, por la cantidad de noticias enviadas, frecuencia de búsqueda, por lo que la aplicación deberá registrar estos datos y tener un proceso mensual para generar esta información de facturación.

Requerimientos de la aplicación

A continuación se enumeran los requerimientos del proyecto, de acuerdo a las necesidades del cliente:

 Debe ser una aplicación web.

 Debe ser una aplicación multi-tenant para maximizar la utilización de recursos.

 La aplicación debe ser escalable y flexible, ya que inicialmente serán pocos clientes, pero si la aplicación tiene éxito debe poder adaptarse fácilmente a cientos y miles de clientes.

 Se debe utilizar una base de datos transaccional con soporte multi-tenant para almacenar la información del sistema.

 Debe soportar la ejecución de procesos en background.

 Debe poder descargar páginas completas de los medios en internet.

 Se debe utilizar un motor de full text search para la búsqueda de las noticias.

 Debe poder contabilizarse el uso de ciertas partes del sistema con el fin de poder realizar una facturación mensual.

 Se debe contar con un servicio de envío de emails confiable.

 Se debe poder monitorear en todo momento la performance y el grado de utilización de los recursos del sistema.

 El portal web para cada tenant debe ser configurable.

 Diseñar la solución de modo que se puedan aprovisionar recursos a medida que se incremente la cantidad de clientes.

56 El análisis técnico estará dividido en dos secciones. La primera sección abordará

requerimientos técnicos de base que conformarán la arquitectura de la aplicación, relacionados específicamente con los requisitos técnicos de una solución SaaS, como configurabilidad, escalabilidad, etc. La segunda sección abordará requerimientos técnicos relacionados con funcionalidad crítica del sistema de alertas, como el envío de emails, mecanismos de full text search, etc.