24 Capítulo II Estado del Arte En el siguiente capítulo se dará una descripción de las metodologías y herramientas utilizadas en el desarrollo del sistema, esto con el fin de familiarizarse con dichos conceptos ya que en capítulos siguientes será necesario tener conocimiento de ellos.
22
Embed
Capítulo IIrepositorio.upsin.edu.mx/Fragmentos/Capitulo2CapituloII...Se estima que el 50% de todos los procesos de desarrollo de software deberían ser evaluados. Los errores pueden
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
24
Capítulo II Estado del Arte
En el siguiente capítulo se dará una descripción de las metodologías y herramientas
utilizadas en el desarrollo del sistema, esto con el fin de familiarizarse con dichos
conceptos ya que en capítulos siguientes será necesario tener conocimiento de ellos.
25
2.1 Antecedentes de la Inteligencia Artificial
Antes de continuar con esta investigación es de suma importancia el conocer a
gran medida los antecedentes principales, que fueron de gran ayuda al momento de
acentuar las bases de la Inteligencia Artificial e Inteligencia Cognitiva.
Originalmente el Término de Inteligencia artificial fue acuñado en 1956 durante
una conferencia en la universidad Dartmouth College, ubicada en Hanover, Nuevo
Hampshire (Estados Unidos), dicha conferencia era Titulada: Dartmouth Summer
Research Project on Artificial Intelligence. [12]
2.1.1 Griegos
Las ideas más básicas se remontan a los griegos, antes de Cristo. Aristóteles (384-
322 a. C.) fue el primero en describir un conjunto de reglas que describen una parte del
funcionamiento de la mente para obtener conclusiones racionales, y Ctesibio de
Alejandría (250 a. C.) construyó la primera máquina auto controlada, un regulador del
flujo de agua (racional pero sin razonamiento). [12]
2.1.2 Siglo XlV
En 1315 Ramon Llull en su libro Ars magna tuvo la idea de que el razonamiento podía
ser efectuado de manera artificial. [12]
2.1.3 Siglo XX
En 1936 Alan Turing diseña formalmente una Máquina universal que demuestra la
viabilidad de un dispositivo físico para implementar cualquier cómputo formalmente
definido. [12]
En 1943 Warren McCulloch y Walter Pitts presentaron su modelo de neuronas
artificiales, el cual se considera el primer trabajo del campo, aun cuando todavía no
existía el término. Los primeros avances importantes comenzaron a principios del año
1950 con el trabajo de Alan Turing, a partir de lo cual la ciencia ha pasado por diversas
situaciones. [12]
En 1955 Herbert Simon, Allen Newell y J. C. Shaw, desarrollan el primer lenguaje de
programación orientado a la resolución de problemas, el IPL-11. Un año más tarde
desarrollan el LogicTheorist, el cual era capaz de demostrar teoremas matemáticos.
[12]
En 1956 fue inventado el término inteligencia artificial por John McCarthy, Marvin
Minsky y Claude Shannon en la Conferencia de Dartmouth. [12]
Dentro del desarrollo de software se llevan a cabo un conjunto de tareas las cuales
están agrupadas en etapas, dichas etapas son conocidas como ciclo de vida del
desarrollo de software.
2.2.2 Ciclo de vida del Desarrollo de Software
Como se menciona anteriormente el Ciclo de vida del desarrollo de software
comprende un conjunto de tareas agrupadas en etapas bien definidas las cuales
ayudan a desarrollar un producto de software deseado.
El ciclo de vida del desarrollo de software aporta una serie de pasos a seguir con la
finalidad de diseñar y desarrollar un producto software de manera eficiente [14]. El
borrador del Ciclo de vida del desarrollo de software incluye los pasos que veremos a
continuación:
Comunicación
Requisitos del sistema
Estudio de factibilidad
Análisis del sistema
Diseño de Software
Codificación
Pruebas
Integración
Implementación
Mantenimiento
Disposición
A continuación de describirá con mayor detalle cada una de los pasos anteriormente mencionados. 2.2.2.1 Comunicación
Este es el primer paso donde el usuario inicia la petición de un producto software
determinado. Contacta al proveedor de servicios e intenta negociar las condiciones.
Presenta su solicitud al proveedor de servicios aportando la organización por escrito.
[14]
2.2.2.2 Requisitos del Sistema
A partir de este paso y en adelante el equipo de desarrollo software trabaja para
llevar adelante el proyecto. El equipo se reúne con varios depositarios de dominio del
problema, e intentan conseguir la máxima cantidad de información posible sobre lo que
requieren. Los requisitos se contemplan y agrupan en requisitos del usuario, requisitos
funcionales y requisitos del sistema [14]. La recolección de todos los requisitos se lleva
a cabo como se especifica a continuación
Estudiando el software y el sistema actual u obsoleto,
29
Entrevistando a usuarios y a desarrolladores de Software,
Consultando la base de datos o recogiendo respuestas a través de cuestionarios.
2.2.2.3 Estudio de Factibilidad
Después de la recolección de requisitos, el equipo idea un plan para procesar el
software. En esta fase, el equipo analiza si el software puede hacerse para cubrir todos
los requisitos del usuario y si hay alguna posibilidad de que el software ya no sea
necesario. Se investiga si el proyecto es viable a nivel financiero, práctico, y a nivel
tecnológico para que la organización acepte la oferta. Hay varios algoritmos
disponibles, los cuales ayudan a los desarrolladores a concluir si el proyecto software
es factible o no. [14]
2.2.2.4 Análisis del Sistema
En esta pasa los desarrolladores trazan su plan e intentan crear el mejor y más
conveniente modelo de software para el proyecto. El análisis del sistema incluye el
entendimiento de las limitaciones del producto Software; el aprendizaje de los
problemas relacionados con el sistema; los cambios que se requieren en sistemas ya
existentes con antelación, identificando y dirigiendo el impacto del proyecto a la
organización y al personal, etc. El equipo del proyecto analiza las posibilidades del
proyecto y planifica la temporalización y los recursos correspondientes. [14]
2.2.2.5 Diseño de Software
El siguiente paso es diseñar el producto software con la ayuda de toda la
información recogida sobre requisitos y análisis. Los inputs (aportaciones) de los
usuarios y los resultados de la recogida de información hecha en la fase anterior serán
las aportaciones base de la fase actual. El output (o resultado) de esta etapa toma la
forma de 2 diseños; El diseño lógico y el diseño físico. Los ingenieros crean meta-data
(Metadatos), Diagramas dilógicos, diagramas de flujo de datos, y en algunos casos
pseudocódigos. [14]
2.2.2.6 Codificación
Esta fase también se puede denominar 'fase de programación'. La
implementación del diseño de software empieza con el lenguaje de programación más
conveniente, y desarrollando programas ejecutables y sin errores de manera eficiente.
[14]
30
2.2.2.7 Pruebas
Se estima que el 50% de todos los procesos de desarrollo de software deberían
ser evaluados. Los errores pueden arruinar el software tanto a nivel crítico y hasta el
punto de ser eliminado. Las pruebas de Software se hacen mientras se codifica y
suelen hacerlo los desarrolladores y otros expertos evaluadores a varios niveles. Esto
incluye evaluación de módulos, evaluación del programa, evaluación del producto,
evaluación interna y finalmente evaluación con el consumidor final. Encontrar errores y
su remedio a tiempo es la llave para conseguir un software fiable. [14]
2.2.2.8 Integración
El Software puede necesitar estar integrado con las bibliotecas, Bases de datos o
con otro u otros programas. Esta fase del Ciclo de vida del desarrollo de software se
focaliza en la integración del software con las entidades del mundo exterior. [14]
2.2.2.9 Implementación
Aquí se instala el software en máquinas de clientes. A veces, el software
necesita instalar configuraciones para el consumidor final con posterioridad. El Software
se evalúa por su adaptabilidad y su portabilidad, en cuanto a las cuestiones
relacionadas con la integración y conceptos asociados, se resuelven durante la
implementación. [14]
2.2.2.10 Mantenimiento
Esta fase confirma el funcionamiento del software en términos de más eficiencia
y menos errores. Si se requiere, los usuarios se forman, o se les presta documentación
sobre como operar y como mantenerlo en funcionamiento. El software se mantiene de
forma temprana actualizando el código en acorde a los cambios que tienen lugar en
entornos del usuario o tecnológicos. Esta fase puede que tenga que encarar retos
originados por virus ocultos o problemas no identificados del mundo real. [14]
2.2.2.11 Disposición
Con el paso del tiempo, puede que el software falle en su ejecución. Puede que
se vuelva totalmente obsoleto o que necesite actualizaciones. De ahí surge una
necesidad urgente de eliminar una parte importante del sistema. Esta fase incluye
archivar datos y componentes software requerido, cierre del sistema, planificación de la
actividad de disposición y terminación de sistema en el momento final del sistema. [14]
31
2.3 Paradigmas del Desarrollo de Software
El paradigma de desarrollo de Software ayuda al desarrollador a escoger una
estrategia para desarrollar el software. El paradigma de desarrollo software tiene su
propio set de herramientas, métodos y procedimientos, los cuales son expresados de
forma clara, y define el ciclo de vida del desarrollo del software [14]. Algunos
paradigmas de desarrollo de software o modelos de proceso se definen a continuación:
2.3.1 Modelo de Cascada
El modelo de cascada es el modelo de paradigma más simple en desarrollo de
software. Sigue un modelo en que las fases del Ciclo de vida del desarrollo de software
funcionarán una detrás de la otra de forma lineal. Lo que significa que solamente
cuando la primera fase se termina se puede empezar con la segunda, y así
progresivamente.
Este modelo asume que todo se lleva a
cabo y tiene lugar tal y como se había
planeado en la fase anterior, y no es
necesario pensar en asuntos pasados
que podrían surgir en la siguiente fase.
Este modelo no funcionará
correctamente si se dejan asuntos de
lado en la fase previa. La naturaleza
secuencial del modelo no permite volver
atrás y deshacer o volver a hacer
acciones.
Este modelo es recomendable cuando el desarrollador ya ha diseñado y desarrollado
software similar con anterioridad, y por eso está al tanto de todos sus dominios. [14]
Imagen 2.1: Modelo Cascada
32
2.3.2 Modelo Repetitivo
Este modelo guía el proceso de desarrollo de software en repeticiones. Proyecta
el proceso de desarrollo de forma cíclica repitiendo cada paso después de cada ciclo en
el proceso del Ciclo de vida del desarrollo de software.
El software primero se desarrolla en
menor escala y se siguen y tienen en
consideración todos los pasos. Entonces,
por cada repetición, más módulos y
características son diseñados,
codificados, evaluados y añadidos al
software. Cada ciclo produce un software
completo, con más características y
capacidad que los previos.
Después de cada repetición, el equipo directivo puede concentrarse en la gestión de
riesgos y prepararse para la siguiente repetición. Como el ciclo incluye pequeñas
porciones de la totalidad del proceso software, es más fácil gestionar el proceso de
desarrollo, pero a la vez se consumen más recursos. [14]
2.3.3 Modelo en espiral El modelo en espiral es una combinación de ambos modelos, el repetitivo y uno
del modelo Ciclo de vida del desarrollo de software. Se puede ver como si se combina
un modelo de Ciclo de vida del desarrollo de software combinado con un proceso cíclico
(modelo repetitivo).
Este modelo considera el riesgo, factor que otros
modelos olvidan o no prestan atención en el proceso.
El modelo empieza determinando los objetivos y las
limitaciones del software al inicio de cada repetición.
En la siguiente etapa se crean los modelos de
prototipo del software. Esto incluye el análisis de
riesgos. Luego un modelo estándar de Ciclo de vida
del desarrollo de software se usa para construir el
software. En la cuarta etapa es donde se prepara el
plan de la siguiente repetición. [14]
Imagen 2.2: Modelo Repetitivo
Imagen 2.3: Modelo Espiral
33
2.3.4 Modelo V El mayor inconveniente del modelo de cascada es que solo se pasa a la
siguiente fase cuando se completa la anterior, por tanto, no es posible volver atrás si se
encuentra algún error en las etapas posteriores. El Modelo V aporta opciones de
evaluación del software en cada etapa de manera inversa.
En cada etapa, se crea la planificación de las
pruebas y los casos de pruebas para verificar y
validar el producto según los requisitos de la
etapa. Por ejemplo, en la etapa de recogida de
requisitos, el equipo de evaluadores prepara las
pruebas de caso correspondientes a los
requisitos. Más tarde, cuando el producto se
desarrolla y está preparado para ser evaluado,
las pruebas de caso en esta etapa verifican el
software y su validez según sus requisitos.
Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo
también se conoce como modelo de validación y verificación. [14]
2.3.5 Modelo Big Bang
Este modelo es el modelo con la forma más simple. Requiere poca planificación,
mucha programación y también muchos fondos. Este modelo se conceptualiza
alrededor de la teoría de creación del universo 'Big Bang'. Tal como cuentan los
científicos, después del big bang muchas galaxias, planetas y estrellas evolucionaron.
De la misma manera, si reunimos muchos fondos y programación, quizá podemos
conseguir el mejor producto de software.
Para este modelo, se requiere poca
planificación. No sigue ningún proceso
concreto, y a veces el cliente no está seguro de
las futuras necesidades y requisitos. Por tanto,
la entrada o input respecto a los requisitos es
arbitraria.
Este modelo no es recomendable para grandes proyectos de software, pero es bueno
para aprender y experimentar. [14]
Imagen 2.4: Modelo V
Imagen 2.5: Modelo Big bang
34
2.3.6 Paradigma Tradicional
Es uno de los principales paradigmas que surgieron al inicio de los modelos de
desarrollo. Nació con la necesidad de mejorar los procesos de desarrollo de software, y
en un principio tuvo un gran impacto, puesto que ayudó a mejorar los procesos de
desarrollo y permitió que estos fueran entregados en una alta calidad; sin embargo, con
el paso del tiempo estas se volvieron poco flexibles, muy robustas y muy lenta para
poder dar solución al desarrollo de software.
Se centraban en el control de procesos, mediante una rigurosa definición de roles,
actividades, artefactos, herramientas y notaciones para el modelado y documentación
detallada. No se adaptan adecuadamente a los cambios, y resulta complicado el que se
agreguen nuevas actividades o que se realicen cambios de última hora. [14]
2.3.7 Paradigma de Desarrollo Ágil
El desarrollo ágil surge en respuesta a los problemas que comenzaron a
aparecer con los modelos de desarrollo que seguían orientados al paradigma
tradicional. Está basado en procesos ágiles, los cuales intentan evitar el tedioso
proceso que tienen las metodologías tradicionales.
Se apoya en el valor de construir software, haciendo que el cliente forme parte de
desarrollo e incorporando cambios continuos que ayuden a mejorarlo. Estos métodos
están justificados en el desarrollo iterativo e incremental, donde las soluciones y los
requisitos cambian con el tiempo según la necesidad del proyecto.
Toda metodología se considera ágil si cumplen con el manifiesto ágil, que corresponde a una serie de principios que se agrupan en 4 valores, los cuales son:
Individuos y su interacción, por encima de los procesos y las herramientas El software que funciona, frente a la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan. Algo que hay
que aclarar es que la metodología ágil no es mejor que la tradicional, y de igual manera la tradicional no es mejor que la ágil; todo esto depende del tipo de proyecto en el que se aplique. [14]
35
2.3.7.1 Design Thinking
Es un método para generar ideas innovadoras que
centra su eficacia en entender y dar solución a las
necesidades reales de los usuarios. Proviene de la
forma en la que trabajan los diseñadores de producto.
De ahí su nombre, que en español se traduce de forma
literal como "Pensamiento de Diseño".
Se empezó a desarrollar de forma teórica en la Universidad de Stanford en California
(EEUU) a partir de los años 70, y su primera aplicabilidad con fines lucrativos como
"Design Thinking" la llevó a cabo la consultoría de diseño IDEO, siendo hoy en día su
principal precursora. [15]
2.3.7.2 Scrum Es un modelo de referencia que define un conjunto de prácticas y roles, y que
puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutará durante un proyecto. Los roles principales en Scrum son el 'Scrum Master,
que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que
representa a los stakeholders (interesados externos o internos), y el Team (equipo) que
ejecuta el desarrollo y demás elementos relacionados con él. [16]
2.4 Desarrollo Web
Es un término que define la creación de sitios web para Internet o una intranet.
Para conseguirlo se hace uso de tecnologías de software del lado del servidor y del
cliente que involucran una combinación de procesos de base de datos con el uso de un
navegador web a fin de realizar determinadas tareas o mostrar información. [17]
Dentro del desarrollo web, las tecnologías se dividen en dos, las cuales se conocen
como Front-end y Back-end. Front-end es quien trabaja con el lado del cliente mientras
que el Back-end trabaja con el lado del servidor.
2.4.1 Front-end
Trabaja del lado Cliente, en el navegador, en el lado de lo que se ve.
Principalmente se ocupa de los componentes externos del sitio web o de la aplicación
web. Como consecuencia, deben dominar obligatoriamente:
Imagen 2.6: Design Thinking
36
HTML: HyperText Markup Language, es el
componente estructural clave de todas las webs de
internet. Sin él las páginas web no pueden existir.
CSS: Cascading Style Sheets, es lo que le
proporciona estilo a HTML.
JavaScript: Usando solo HTML y CSS tus webs
serían páginas estáticas, con JS tus páginas web
son interactivas.
En general se asocia a los desarrolladores front-end
con los principios de diseño y de estructura de páginas. Sin embargo, un desarrollador
web va más allá que un diseñador. Obviamente tiene que tener en cuenta la
usabilidad y la legibilidad de la página o de la aplicación web, pero como buen
programador es consciente de que su trabajo se ejecutará en el lado Cliente, en la
mayoría de los casos, en el navegador. Y la información no se almacena en el lado
Cliente. [18]
2.4.2 Back-end
El desarrollador back-end trabaja del lado Servidor, detrás del escenario,
permitiendo con su trabajo que el usuario disfrute de su experiencia. Sin él, el desarrollo
llevado a cabo por su anterior compañero no se sostendría.
Para ser programador del lado Servidor, son numerosos los lenguajes y frameworks
entre los que elegir, todo dependerá de la empresa en la que caigas. A día de hoy, los
más comunes son:
ASP.NET: es la plataforma de desarrollo web de
Microsoft. Muy utilizada en las empresas. Tiene las
variantes Web Forms y MVC, y ahora también
ASP.NET Core MVC.
PHP: por ejemplo, el famoso gestor de contenidos
WordPress usa por detrás PHP. Laravel es uno de
los frameworks usados con este lenguaje.
Ruby: junto con su framework Ruby on rails.
Python: fácil de aprender. Usado a menudo con
Django como framework
Node.js: se está haciendo cada vez más popular
debido a que usa el mismo lenguaje que en el lado
cliente: JavaScript.
Imagen 2.7: Herramientas Front-end
Imagen 2.8: Herramientas Back-end
37
Sin embargo, no es suficiente con dominar un lenguaje y un framework. Toda aplicación
web debe almacenar datos de alguna manera. Por lo tanto, un desarrollador back-end
también debe estar familiarizado con las bases de datos. Entre las más comunes
destacan:
SQL Server
MySQL
Oracle
PostgreSQL
MongoDB, que es un almacén de
datos no-relacional o NoSQL.
Al igual que hemos comentado antes el entorno en el que trabajes te obligará a
especializarte en una u otra. [18]
2.5 Herramientas Usadas
En este apartado se hablará de las herramientas y/o aplicaciones utilizadas en el
desarrollo del sistema de análisis de posts de redes sociales, dichas herramientas y/o
aplicaciones se describirán a continuación:
2.5.1 Lenguajes de Programación Como lenguajes de programación serán utilizados nodejs y Python.
2.5.1.1 NodeJs
Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa
del servidor basado en el lenguaje de programación ECMAScript, asíncrono, con I/O de
datos en una arquitectura orientada a eventos y basado en el motor V8 de Google. Fue
creado con el enfoque de ser útil en la creación de programas de red altamente
escalables, como, por ejemplo, servidores web. [19]
NodeJs será utilizado para el desarrollo de una aplicación
web capaz de mostrar los datos procesados por IBM Watson,
se optó por el uso de NodeJs ya que es no de los lenguajes
dentro del catálogo del PAAS utilizado en este proyecto (IBM
Es un lenguaje de programación interpretado cuya filosofía hace hincapié en una
sintaxis que favorezca un código legible.
Se trata de un lenguaje de programación multiparadigma, ya que soporta orientación a
objetos, programación imperativa y, en menor medida, programación funcional. Es un
lenguaje interpretado, usa tipado dinámico y es multiplataforma. [20]
Python será utilizado en la programación de scripts dentro del robot
humanoide de la serie Nao llamada Minerva, la cual será capaz de
interpretar los datos analizados por IBM Watson.
2.5.2 Herramientas que se utilizan en el Back-end 2.5.2.1 Atom
Es un editor de código de fuente de código abierto para macOS, Linux, y Windows con soporte para plug-ins escritos en Node.js y control de versiones Git integrado, desarrollado por GitHub. Atom es una aplicación de escritorio construida utilizando tecnologías web. [21]
2.5.2.2 IBM Watson
Es un sistema informático de inteligencia artificial que
es capaz de responder a preguntas formuladas en
lenguaje natural, desarrollado por la corporación
estadounidense IBM. Forma parte del proyecto del
equipo de investigación DeepQA, liderado por el
investigador principal David Ferrucci. Lleva su nombre
en honor del fundador y primer presidente de IBM,
Thomas J. Watson. [22]
Imagen 2.11: Logotipo Atom
Imagen 2.10: Logotipo Python
Imagen 2.12: Logotipo IBM Watson
39
2.5.2.3 Cloud Foundry
Es una plataforma como servicio (PaaS) código
abierto originalmente desarrollado por VMware
y ahora poseído por Pivotal Software un join
venture entre EMC, VMware y General Electric.
Cloud Foundry fue inicialmente diseñada y
desarrollada por un equipo pequeño de Google
dirigido por Derek Collison y era un proyecto
llamado originalmente B29. [23]
2.5.2.4 IBM Bluemix
Es un entorno de plataforma como servicio
desarrollado por IBM. Soporta varios lenguajes
de programación y servicios, así como la
metodología de desarrollo DevOps de forma
integrada para crear, ejecutar, desplegar y
gestionar aplicaciones en la nube.
Bluemix está basado en la tecnología abierta de Cloud Foundry y corre sobre la
Es un paradigma que permite ofrecer servicios de computación a través de
Internet. [31]
2.6.1 Características de Cloud Computing
La computación en nube presenta las siguientes características clave:
Agilidad: Capacidad de mejora para ofrecer recursos tecnológicos al usuario por
parte del proveedor. [32]
Costo: los proveedores de computación en la nube afirman que los costos se
reducen. Un modelo de prestación pública en la nube convierte los gastos de
capital en gastos de funcionamiento. Ello reduce barreras de entrada, ya que la
infraestructura se proporciona típicamente por una tercera parte y no tiene que
ser adquirida por una sola vez o tareas informáticas intensivas infrecuentes. [32]
Escalabilidad y elasticidad: aprovisionamiento de recursos sobre una base de
autoservicio casi en tiempo real, sin que los usuarios necesiten cargas de alta
duración. [32]
Independencia entre el dispositivo y la ubicación: permite a los usuarios
acceder a los sistemas utilizando un navegador web, independientemente de su
ubicación o del dispositivo que utilice (por ejemplo, PC, teléfono móvil). [32]
La tecnología de virtualización permite compartir servidores y dispositivos de
almacenamiento y una mayor utilización. Las aplicaciones pueden ser fácilmente
migradas de un servidor físico a otro. [32]
Rendimiento: Los sistemas en la nube controlan y optimizan el uso de los
recursos de manera automática, dicha característica permite un seguimiento,
control y notificación del mismo. Esta capacidad aporta transparencia tanto para
el consumidor o el proveedor de servicio. [32]
Seguridad: puede mejorar debido a la centralización de los datos. La seguridad
es a menudo tan buena o mejor que otros sistemas tradicionales, en parte
porque los proveedores son capaces de dedicar recursos a la solución de los
problemas de seguridad que muchos clientes no pueden permitirse el lujo de
abordar. El usuario de la nube es responsable de la seguridad a nivel de
aplicación. El proveedor de la nube es responsable de la seguridad física.
Mantenimiento: en el caso de las aplicaciones de computación en la nube, es
más sencillo, ya que no necesitan ser instalados en el ordenador de cada usuario
y se puede acceder desde diferentes lugares. [32]
43
2.6.2 Servicios de Cloud Computing 2.6.2.1 SAAS (Software As A Service – Software como servicio) El software como servicio se encuentra en la capa más alta y caracteriza una aplicación
completa ofrecida como un servicio, por demanda, vía multitenencia que significa una
sola instancia del software que corre en la infraestructura del proveedor y sirve a
múltiples organizaciones de clientes.
Las aplicaciones que suministran este modelo de
servicio son accesibles a través de un navegador web
o de cualquier aplicación diseñada para tal efecto y el
usuario no tiene control sobre ellas, aunque en algunos
casos se le permite realizar algunas configuraciones.
Esto le elimina la necesidad al cliente de
instalar la aplicación en sus propios computadores,
evitando asumir los costos de soporte y el
mantenimiento de hardware y software. [33]
2.6.2.2 PAAS (Platform As A Service – Plataforma como servicio)
La capa del medio, que es la plataforma como servicio, es la encapsulación de
una abstracción de un ambiente de desarrollo y el empaquetamiento de una serie de
módulos o complementos que proporcionan, normalmente, una funcionalidad horizontal
(persistencia de datos, autenticación, mensajería, etc.). De esta forma, un arquetipo de
plataforma como servicio podría consistir en un entorno conteniendo una pila básica de
sistemas, componentes o APIs preconfiguradas y listas para integrarse sobre una
tecnología concreta de desarrollo. Las ofertas de PaaS pueden dar servicio a todas las
fases del ciclo de desarrollo y pruebas del software, o pueden estar especializadas en
cualquier área en particular, tal como la administración del contenido.
Ejemplos comerciales son Google App Engine, que
sirve aplicaciones de la infraestructura Google;
Microsoft Azure, e IBM Bluemix una plataforma en la
nube que permite el desarrollo y ejecución de
aplicaciones codificadas en varios lenguajes y
tecnologías como Node Js, Java y PHP. Servicios
PaaS como estos permiten gran flexibilidad, pero puede ser restringida por las
capacidades disponibles a través del proveedor.
Imagen 2.22: PAAS
Imagen 2.21: SAAS
44
En este modelo de servicio al usuario se le ofrece la plataforma de desarrollo y las
herramientas de programación por lo que puede desarrollar aplicaciones propias y
controlar la aplicación, pero no controla la infraestructura. [34]
2.6.2.3 IAAS (Infrastructure As A Service – Infraestructura como servicio)
La infraestructura como servicio se encuentra en la
capa inferior y es un medio de entregar
almacenamiento básico y capacidades de cómputo
como servicios estandarizados en la red. Servidores,
sistemas de almacenamiento, conexiones,
enrutadores, y otros sistemas se para manejar tipos
específicos de cargas de trabajo desde procesamiento
en lotes hasta aumento de servidor/almacenamiento
durante las cargas pico. [35]
2.7 Tipos de Nubes 2.7.1 Nube Publica
Es una nube computacional mantenida y gestionada por
terceras personas no vinculadas con la organización. En
este tipo de nubes tanto los datos como los procesos de
varios clientes se mezclan en los servidores, sistemas de
almacenamiento y otras infraestructuras de la nube. Los
usuarios finales de la nube no conocen qué trabajos de
otros clientes pueden estar corriendo en el mismo servidor,
red, sistemas de almacenamiento, etc. Aplicaciones,
almacenamiento y otros recursos están disponibles al
público a través del proveedor de servicios, que es
propietario de toda la infraestructura en sus centros de
datos; el acceso a los servicios solo se ofrece de manera remota, normalmente a través
de internet. [36]
2.7.2 Nube Privada
Son una buena opción para las compañías que necesitan alta
protección de datos y ediciones a nivel de servicio. Las nubes
privadas están en una infraestructura bajo demanda,
gestionada para un solo cliente que controla qué aplicaciones
debe ejecutarse y dónde. Son propietarios del servidor, red, y
disco y pueden decidir qué usuarios están autorizados a utilizar
Imagen 2.24: Nube Publica
Imagen 2.25: Nube
Privada
Imagen 2.23: IAAS
45
la infraestructura. Al administrar internamente estos servicios, las empresas tienen la
ventaja de mantener la privacidad de su información y permitir unificar el acceso a las
aplicaciones corporativas de sus usuarios. [36]
2.7.3 Nube Hibrida
Combinan los modelos de nubes públicas y privadas. Un
usuario es propietario de unas partes y comparte otras,
aunque de una manera controlada. Las nubes híbridas
ofrecen la promesa del escalado, aprovisionada
externamente, a demanda, pero añaden la complejidad de
determinar cómo distribuir las aplicaciones a través de estos
ambientes diferentes. Las empresas pueden sentir cierta
atracción por la promesa de una nube híbrida, pero esta
opción, al menos inicialmente, estará probablemente
reservada a aplicaciones simples sin condicionantes, que no
requieran de ninguna sincronización o necesiten bases de
datos complejas. Se unen mediante la tecnología, pues permiten enviar datos o
aplicaciones entre ellas. Un ejemplo son los sistemas de correo electrónico empresarial.
[36]
2.7.4 Nube Comunitaria
Aquel que se organiza con la finalidad de servir a una
función o propósito común (seguridad, política…), las