1. DIFERENCIA ENTRE UNA APLICACIÓN WEB Y UN SITIO WEB.

Sitio Web Aplicación Web

Conjunto de páginas estáticas que Plataformas interfecticas para que los
entregan información usuarios realicen acción (servicios de
banco, Google dos, sitios de ventas,
netflix)
Fuentes de información Se centran en realizar acciones
Dentro de un sitio web puede haber Dentro de una aplicación no puede haber
aplicaciones web sitios web
Pueden ser mayormente informativas Son el negocio

2. QUÉ ES FRONTEND Y BACKEND

FRONTEND:
-Es la parte de una aplicación que interactúa con los usuarios, es conocida como el lado del
cliente. Básicamente es todo lo que vemos en la pantalla cuando accedemos a un sitio web
o aplicación: tipos de letra, colores, adaptación para distintas pantallas, los efectos del
ratón, teclado, movimientos, desplazamientos, efectos visuales y otros elementos que
permiten navegar dentro de una página web.
-Un desarrollador frontend debe conocer los siguientes lenguajes de
programación: HTML5, CSS3, JavaScript, JQuery, Ajax.
BACKEND:
-Es interior de las aplicaciones que viven en el servidor y al que a menudo se le denomina
“el lado del servidor”. El back end del sitio web consiste en un servidor, una aplicación y
una base de datos. Se toman los datos, se procesa la información y se envía al usuario. 

-Un desarrollador Back end debe tener amplios conocimientos de los siguientes lenguajes,

frameworks y los tipos de base de datos: ASP.NET, PHP, Python, Ruby, Node.js, Java,
MySQL, SQL Server, PostgreSQL, Oracle y MongoDB

3. CICLO DE VIDA DEL SOFTWARE.

Es la estructura que contiene los procesos, actividades y tareas relacionadas con el
desarrollo y mantenimiento de un producto de software, abarcando la vida completa del
sistema, desde la definición de los requisitos hasta la finalización de su uso.

Su origen radica en que es muy costoso rectificar los posibles errores que se detectan tarde
en la fase de implementación. Con una buena estructura de ciclo de software se podría
detectar a tiempo para que los programadores puedan centrarse en la calidad del software,
cumpliendo los plazos y los costes asociados.
Las fases de un ciclo de vida del software son:

-Planificación: algunas de las tareas de esta fase incluyen actividades como la

determinación del ámbito del proyecto, la realización de un estudio de viabilidad, el análisis
de los riesgos asociados, la estimación del coste del proyecto, su planificación temporal y la
asignación de recursos a las diferentes etapas del proyecto.

-Análisis: corresponde al proceso a través del cual se intenta descubrir qué es lo que
realmente se necesita y se llega a una comprensión adecuada de los requerimientos del
sistema.

-Diseño: en esta fase se estudian posibles opciones de implementación para el software que
hay que construir, así como decidir la estructura general del mismo. El diseño es una etapa
compleja y su proceso debe realizarse de manera iterativa. Es posible que la solución inicial
no sea la más adecuada, por lo que en tal caso hay que refinarla. No obstante, hay catálogos
de patrones de diseño muy útiles que recogen errores que otros han cometido para no caer
en la misma trampa.

-Implementación: en esta fase hay que elegir las herramientas adecuadas, un entorno de
desarrollo que facilite el trabajo y un lenguaje de programación apropiado para el tipo de
software a construir. Esta elección dependerá tanto de las decisiones de diseño tomadas
como del entorno en el que el software deba funcionar.

-Pruebas: acá se busca detectar los fallos cometidos en las etapas anteriores para
corregirlos. Por supuesto, lo ideal es hacerlo antes de que el usuario final se los encuentre.
Se dice que una prueba es un éxito si se detecta algún error.

-Instalación o despliegue: la siguiente fase es poner el software en funcionamiento, es

posible que haya componentes que funcionen correctamente por separado, pero que al
combinarlos provoquen problemas. Por ello, hay que usar combinaciones conocidas que no
causen problemas de compatibilidad.

-Uso y mantenimiento: acá se busca: eliminar los defectos detectados durante su vida útil
(mantenimiento correctivo), adaptarlo a nuevas necesidades (mantenimiento adaptativo) y
añadirle nuevas funcionalidades (mantenimiento perfectivo). Aunque suene contradictorio,
cuanto mejor es el software más tiempo hay que invertir en su mantenimiento. La principal
razón es que se usará más (incluso de formas que no se habían previsto) y, por ende, habrá
más propuestas de mejoras.
TIPOS DE MODELO DE CICLO DE VIDA DE SOFTWARE

-Modelo en cascada: en el modelo de ciclo de vida en cascada las fases anteriores

funcionarán una detrás de la otra de manera lineal. De este modo, solo cuando una fase
termine se podrá continuar con la siguiente, y así progresivamente.

-Modelo en espiral: el modelo se comienza fijando los objetivos y las limitaciones al

empezar cada repetición. En la etapa siguiente se crean los modelos de prototipo del
software, que incluye el análisis de riesgo. Posteriormente se usa un modelo estándar para
construir el software y finalmente se prepara el plan de la próxima repetición.

-Modelo en V: uno de los grandes problemas del modelo en cascada es que solo se pasa a la
siguiente fase si se completa la anterior y no se puede volver atrás si hay errores en etapas
posteriores. Así, el modelo en V da más opciones de evaluación del software en cada etapa.

En cada fase se crea la planificación de las pruebas y los casos de pruebas para verificar y
validar el producto en función de los requisitos de la misma. De esta manera, verificación y
validación van en paralelo.

-Modelo Iterativo: Consiste en la iteración de varios ciclos de vida en cascada. Al final de

cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades
del producto. El cliente es quien, después de cada iteración, evalúa el producto y lo corrige
o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga
las necesidades del cliente.

-Modelo de desarrollo Incremental: Se basa en la filosofía de construir incrementando las

funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software. Este modelo se centra en la entrega de un producto operativo con cada
incremento. Los primeros incrementos son versiones incompletas del producto final, pero
proporcionan al usuario la funcionalidad que precisa y también una plataforma para la
evaluación.

4. TIPOS DE PRUEBAS DE SOFTWARE.

-Pruebas de integración: las pruebas de integración implican probar diferentes módulos de

una aplicación de software como grupo. El propósito de las pruebas de integración es
validar la integración de diferentes módulos juntos e identificar los errores y problemas
relacionados con ellos. Por ejemplo, la unión del módulo de pago con el carrito de compras.

-Pruebas no funcionales: las funciones se prueban bajo carga para el rendimiento de los
observadores, fiabilidad, usabilidad, escalabilidad, etc. Las pruebas no funcionales, como
las pruebas de carga y esfuerzo, normalmente se llevan a cabo mediante herramientas y
soluciones de automatización, como LoadView. Además de las pruebas de rendimiento, los
tipos de pruebas no funcionales incluyen pruebas de instalación, pruebas de confiabilidad y
pruebas de seguridad.
-Performance Testing: las pruebas de rendimiento son un tipo de pruebas no funcionales,
realizadas para determinar la velocidad, estabilidad y escalabilidad de una aplicación de
software. Como su nombre indica, el objetivo general de esta prueba es comprobar el
rendimiento de una aplicación con respecto a los diferentes puntos de referencia del sistema
y de la red, como la utilización de la CPU, la velocidad de carga de la página, el control de
tráfico máximo, la utilización de recursos del servidor, etc. Por ejemplo, evaluar el
rendimiento de una página de ventas en temporada decembrina.
-Pruebas funcionales: Se centran en los requerimientos del negocio. Registro, inicio de
sesión, agregar al carrito, pago, procesamiento de pagos, entradas de base de datos, son
algunos ejemplos.
-Pruebas unitarias: son a bajo nivel, cercanas al código fuente de nuestra aplicación. Este
tipo de testing consiste en probar de forma individual las funciones y/o métodos, de las
clases, componentes y/o módulos que son usados por nuestro software. Debido a lo
específicas que son, generalmente son las pruebas automatizadas de menor coste, y pueden
ejecutarse rápidamente por un servidor.

-Pruebas end to end: replican el comportamiento de los usuarios con el software, en un

entorno de aplicación completo.
-Pruebas de regresión: verifican un conjunto de escenarios que funcionaron correctamente
en el pasado, para asegurar que continúen así.

5. METODOLOGÍAS DE DESARROLLO
Son un conjunto de técnicas y métodos organizativos que se aplican para diseñar soluciones
de software informático. El objetivo de las distintas metodologías es el de intentar organizar
los equipos de trabajo para que estos desarrollen las funciones de un programa de la mejor
manera posible.
Metodologías tradicionales (ciclos de desarrollos poco flexibles y no permiten realizar
cambios)
- Cascada: es una metodología en la que las etapas se organizan de arriba a abajo, cada
etapa es diferenciada y se lleva un riguroso orden. No se puede pasar a la etapa siguiente si
la anterior no se completado en su totalidad. Los requisitos y especificaciones iniciales no
están predispuestos para cambiarse, por lo que no se pueden ver los resultados hasta que el
proyecto ya esté bastante avanzado.
-Prototipado: se basa en la construcción de un prototipo de software que se construye
rápidamente para que los usuarios puedan probarlo y aportar feedback. Así, se puede
arreglar lo que está mal e incluir otros requerimientos que puedan surgir. Es un modelo
iterativo que se basa en el método de prueba y error para comprender las especificidades
del producto.

-Espiral: Se divide en cuatro etapas: planificación, análisis de riesgo, desarrollo de

prototipo y evaluación del cliente. El nombre de esta metodología da nombre a su
funcionamiento, ya que se van procesando las etapas en forma de espiral. Cuanto más cerca
del centro se está, más avanzado está el proyecto.

-Incremental: en esta metodología de desarrollo de software se va construyendo el producto

final de manera progresiva. En cada etapa incremental se agrega una nueva funcionalidad.
El software se puede empezar a utilizar incluso antes de que se complete totalmente y, en
general, es mucho más flexible que las demás metodologías.

Metodologías agiles (ciclo de desarrollo se van agregando nuevas funcionalidades a la

aplicación final. Sin embargo, los ciclos son mucho más cortos y rápidos, por lo que se van
agregando pequeñas funcionalidades en lugar de grandes cambios. permite construir
equipos de trabajo autosuficientes e independientes que se reúnen cada poco tiempo para
poner en común las novedades)
-Kanban: metodología de trabajo inventada por la empresa de automóviles Toyota. Consiste
en dividir las tareas en porciones mínimas y organizarlas en un tablero de trabajo dividido
en tareas pendientes, en curso y finalizadas. De esta forma, se crea un flujo de trabajo muy
visual basado en tareas prioritarias e incrementando el valor del producto.

-Lean: está configurado para que pequeños equipos de desarrollo muy capacitados elaboren
cualquier tarea en poco tiempo.

-Programación extrema (XP): es una metodología de desarrollo de software basada en las

relaciones interpersonales. Su principal objetivo es crear un buen ambiente de trabajo en
equipo y que haya un feedback constante del cliente. El trabajo se basa en 12 conceptos:
diseño sencillo, testing, refactorización y codificación con estándares, propiedad colectiva
del código, programación en parejas, integración continua, entregas semanales e integridad
con el cliente, cliente in situ, entregas frecuentes y planificación.

6. ¿QUÉ ES SCRUM?
Es una metodología de trabajo ágil que tiene como finalidad la entrega de valor en
períodos cortos de tiempo.
Se caracteriza por:
-La flexibilidad en la adopción de cambios y nuevos requisitos durante un proyecto
complejo.
-La colaboración e interacción con el cliente y el desarrollo iterativo como forma de
asegurar buenos resultados.
ROLES EN EL SCRUM
 -Product owner: El Product owner es el único perfil que habla constantemente con
el cliente, lo que le obliga a tener muchos conocimientos sobre negocio. Para
finalizar, un equipo Scrum debe tener solo un Product Owner y este puede ser parte
del equipo de desarrollo. 
-Scrum Master: es el responsable de que las técnicas Scrum sean comprendidas y
aplicadas en la organización. Es el manager de Scrum, un líder que se encarga de
eliminar impedimentos o inconvenientes que tenga el equipo dentro de un  sprint.
Dentro de la organización, el Scrum Master tiene la labor de ayudar en la adopción
de esta metodología en todos los equipos. 
-Equipo de desarrollo: son los encargados de realizar las tareas priorizadas por el
Product Owner. Es un equipo multifuncional y auto-organizado. Son los únicos
que estiman las tareas del product backlog, sin dejarse influenciar por nadie.
SUCESOS EN EL SCRUM

-Sprint: son todas las iteraciones que resultan en una entrega que tiene valor dentro
del proyecto. La duración máxima es de un mes, el tiempo se determina en base al
nivel de comunicación que el cliente quiere tener con el equipo. Los sprints largos
pueden hacer que se pierda feedback valioso del cliente y poner en peligro el
proyecto.
-Sprint planning: en esta reunión todo el equipo Scrum define qué tareas se van a
abordar y cuál será el objetivo del sprint. Acá se haces las siguientes preguntas:
¿Qué se va a hacer en el  sprint? En base a ello, se eligen tareas del Product
backlog.  ¿Cómo lo vamos a hacer? El equipo de desarrollo define las tareas
necesarias para completar cada ítem elegido del Product Backlog.
-Daily meeting: e s una reunión diaria corta dentro del sprint donde participan
el equipo de desarrollo y el Scrum Master. El Product Owner no tienen
necesidad de estar presente. Se las siguientes tres preguntas: ¿Qué hice  ayer?, ¿Qué
voy a hacer hoy?, ¿Tengo algún impedimento que necesito que me solucionen?
Esta reunión es la más oportuna para poder inspeccionar el trabajo y poder adaptarse
en caso de que haya cambio de tareas dentro de un sprint.

-Sprint review: es la única reunión donde puede asistir el cliente. En ella el Product
Owner presenta lo desarrollado al cliente y el equipo de desarrollo muestra su
funcionamiento. El cliente valida los cambios realizados y además brinda feedback
sobre nuevas tareas que el Product Owner tendrá que agregar al Product backlog.
-Sprint retrospective : es la reunión del equipo en la que se hace una evaluación de
cómo se ha implementado la metodología Scrum en el último sprint. Es una gran
oportunidad para el equipo Scrum de inspeccionarse a sí mismo, proponiendo
mejoras para el siguiente sprint.
HERRAMIENTAS DEL SCRUM
-Product Backlog: listado de tareas que engloba todo un proyecto. Cualquier cosa
que debamos hacer debe estar en el  product backlog y con un tiempo estimado por el
equipo de desarrollo.
-Sprint Backlog: Es el grupo de tareas del product backlog que el equipo de
desarrollo elige en el sprint planning junto con el plan para poder desarrollarlas.
VENTAJAS DESVENTAJAS
Fácil de aprender Difícil implementación
El cliente puede usar el producto Se necesita equipos multidisciplinares,
rápidamente equipos capaces de hacer todo el trabajo de
un equipo
Se agiliza el proceso con entregas Buscar la ruta más rápida para conseguir el
frecuentes sprint no siempre garantiza calidad
Menor probabilidad de imprevistos, gracias
a que el cliente ve el proyecto
frecuentemente

7. QUÉ ES UNA HISTORIA DE USUARIO Y QUÉ ES UN CASO DE USO.

DIFERENCIAS

CASO DE USO HISTORIA DE USUARIO

Es una técnica para capturar la Es un texto escrito en un lenguaje
funcionalidad deseada desde la perspectiva coloquial, que funciona a modo de
de como los usuarios interactúan con el recordatorio de una conversación con
sistema. Se utiliza en UML (Unified el cliente.
Modeling Language) en los diagramas de
casos de uso, un lenguaje de modelado que
se utiliza para describir un sistema desde
sus perspectivas estática y dinámica.
Un caso de uso proporciona una visión Es un sinónimo de "característica"
contextual de lo que se va a construir, de lo que se debía construir. Se podría
y sirve para unir a la organización, entre interpretar como una tarea para entregar en
otras cosas. un sprint.
Representa el “como” lo quiere el cliente. Representa el “que” quiere el cliente
El criterio de aceptación es una matriz de El criterio de aceptación es vale o no vale
evaluación definida.
Es la relación entre el usuario y el sistema Es la evidencia del valor que desea el
ante cierta especificación cliente para cierta función
Se representa generalmente por gráficos Se representa por medio de tablas con
palabras claves
8. QUÉ ES VERSIONAMIENTO DE CÓDIGO FUENTE. ¿POR QUÉ ES
IMPORTANTE?

También llamado control de versiones. Es lo que nos permite compartir el código fuente de
nuestros desarrollos y a la vez mantener un registro de los cambios por los que va pasando.
Es la práctica de rastrear y gestionar los cambios en el código de software
- Se basa en versionar archivos y carpetas, las cuales conforman un repositorio.
- El versionamiento permite obtener una copia local de repositorio y publicar cambios a un
repositorio.
- También permite revisar cambios, deshacer cambios, marcar una revisión, llevar un
histórico de modificación.
-SON IMPORTANTES porque permiten trabajar a los equipos de desarrollados de forma
más rápida e inteligente ya que permite llevar un control de todas las modificaciones hechas
como también crear algunas copias de seguridad del código. También porque permiten
regresar a un estado anterior del proyecto o conocer, incluso, toda su evolución en el
tiempo. Desde sus inicios hasta donde se encuentra actualizado.

9. ESTÁNDARES DE CODIFICACIÓN. ¿POR QUÉ ES IMPORTANTE?

Son un conjunto de convenciones establecidas de ante mano (denominaciones, formatos,
etc.) para la escritura de código. Estos estándares varían dependiendo del lenguaje de
programación elegido.
ES IMPORTANTE porque permite tener un código ordenado, con cierto formato que
permite tener más claro que hace cada línea de código además de permitir una mejor
trabajo y comunicación entre el equipo de desarrollo.
-Tabulación: Todo el código desarrollado tendrá una tabulación de 8 espacios. La razón
principal de tener una buena tabulación es que solo necesitas un primer vistazo para ver la
estructura general del código. Si el código comienza a extenderse a la derecha más de lo
debido, por ejemplo, por anidación de bucles o estructuras de control, probablemente esto
significa que debe rescribirse el código de una manera más legible.
-Nombre de funciones y de variables: deben ser descriptivos y precisos. Los métodos deben
ser acciones. Los argumentos también deben ser descriptivos.
-Comentarios: Hacer comentarios que hagan que el código pueda hacer entender que es lo
que quieres conseguir con esas líneas. Además de los comentarios para explicar
determinadas partes de tu código, también es recomendable utilizar bloques de
documentación en funciones, explicando parámetros, tipos esperados y lo que se persigue
conseguir.
-Legibilidad: Aplicar los formatos adecuados para que el código sea entendible.
10. DIFERENCIA ENTRE UNA APLICACIÓN MONOLÍTICA Y UNA
APLICACIÓN EN MICROSERVICIOS.

MONOLITICA MICROSERVICIOS
Es la arquitectura de software donde todos Es la arquitectura de software donde cada
los aspectos funcionales del software función responde de forma autónoma a las
quedas acoplados y sujetos en un mismo demás. Cada función, o proceso o
programa. microservicio es un elemento
independiente.
La información de estos softwares queda Se puede almacenar información en
alojada en un único servidor. distintos servidores
No hay separación de módulos Separación de módulos
Difícil actualización o corrección de bus Fácil actualización (si actualizo el módulo
de contabilidad, no sufre nada el módulo
de gestión de personal)

11. ¿QUÉ ES UNA .WAR, UN .JAR Y UN .EAR?

-JAR: Java ARchive. Es un tipo de archivo que permite ejecutar aplicaciones y

herramientas escritas en el lenguaje Java. Los archivos JAR están comprimidos con el
formato ZIP y cambiada su extensión a .jar. Existen tres operaciones básicas con este tipo
de archivos: ver contenido, comprimir y descomprimir.
ACA ESTAN LOS PUNTOS CLASS
-WAR: Web aplication ARchive. Es un archivo JAR utilizado para distribuir una colección
de JavaServer Pages, servlets, clases Java, archivos XML, bibliotecas de tags y páginas
web estáticas que juntos constituyen una aplicación web.
ACA ESTON LAS CLASSES Y LOS WEBS
-EAR: es un formato de archivo utilizado por Java EE para empaquetar uno o más módulos
en un solo archivo, de modo que la implementación de los distintos módulos en un servidor
de aplicaciones ocurra de manera simultánea y coherente.
Se utiliza la extensión ,ear para aplicaciones empresariales basadas en Java EE, .war para
aplicaciones web y .jar para aplicaciones Java independientes y bibliotecas vinculables.
Un archivo EAR requiere un servidor de aplicaciones totalmente compatible con la
plataforma Java, Enterprise Edition (Java EE) o Jakarta Enterprise Edition (EE), como
WebSphere o JBoss, para ejecutarse.
Un archivo WAR solo requiere un servidor de aplicaciones compatible con Java EE Web
Profile para ejecutarse.
Un archivo JAR solo requiere una instalación Java.
12. ¿QUÉ SON PATRONES DE DISEÑO DE SOFTWARE? Y ¿QUÉ PATRONES
DE DISEÑO EXISTEN Y CÓMO SE CLASIFICAN?

Son una solución general, reutilizable y aplicable a diferentes problemas de diseño de

software. Se trata de plantillas que identifican problemas en el sistema y proporcionan
soluciones apropiadas a problemas generales a los que se han enfrentado los desarrolladores
durante un largo periodo de tiempo.
Si la forma de solucionar ese problema se puede extraer, explicar y reutilizar en múltiples
ámbitos, entonces nos encontramos ante un patrón de diseño de software.

PATRONES CREACIONALES
Son los que facilitan la tarea de creación de nuevos objetos, de tal forma que el proceso de
creación pueda ser desacoplado de la implementación del resto del sistema.
-Abstract Factory: Nos provee una interfaz que delega la creación de un conjunto de objetos
relacionados sin necesidad de especificar en ningún momento cuáles son las
implementaciones concretas.
-Factory Method: Expone un método de creación, delegando en las subclases la
implementación de este método.
-Builder: Separa la creación de un objeto complejo de su estructura, de tal forma que el
mismo proceso de construcción nos puede servir para crear representaciones diferentes.
-Singleton: limita a uno el número de instancias posibles de una clase en nuestro programa,
y proporciona un acceso global al mismo.
-Prototype: Permite la creación de objetos basados en “plantillas”. Un nuevo objeto se crea
a partir de la clonación de otro objeto.

PATRONES ESTRUCTURALES
Son patrones que nos facilitan la modelización de nuestros softwares especificando la
forma en la que unas clases se relacionan con otras.
-Adapter: Permite a dos clases con diferentes interfaces trabajar entre ellas, a través de un
objeto intermedio con el que se comunican e interactúan.
-Bridge: Desacopla una abstracción de su implementación, para que las dos puedan
evolucionar de forma independiente.
-Composite: Facilita la creación de estructuras de objetos en árbol, donde todos los
elementos emplean una misma interfaz. Cada uno de ellos puede a su vez contener un
listado de esos objetos, o ser el último de esa rama.
-Decorator: Permite añadir funcionalidad extra a un objeto (de forma dinámica o estática)
sin modificar el comportamiento del resto de objetos del mismo tipo.
-Facade: Una facade (o fachada) es un objeto que crea una interfaz simplificada para tratar
con otra parte del código más compleja, de tal forma que simplifica y aísla su uso. Un
ejemplo podría ser crear una fachada para tratar con una clase de una librería externa.
-Flyweight: Una gran cantidad de objetos comparte un mismo objeto con propiedades
comunes con el fin de ahorrar memoria.
-Proxy: Es una clase que funciona como interfaz hacia cualquier otra cosa: una conexión a
Internet, un archivo en disco o cualquier otro recurso que sea costoso o imposible de
duplicar.

PATRONES DE COMPORTAMIENTO
En este último grupo se encuentran la mayoría de los patrones, y se usan para gestionar
algoritmos, relaciones y responsabilidades entre objetos.
-Command: Son objetos que encapsulan una acción y los parámetros que necesitan para
ejecutarse.
-Chain of responsibility: se evita acoplar al emisor y receptor de una petición dando la
posibilidad a varios receptores de consumirlo. Cada receptor tiene la opción de consumir
esa petición o pasárselo al siguiente dentro de la cadena.
-Interpreter: Define una representación para una gramática así como el mecanismo para
evaluarla. El árbol de sintaxis del lenguaje se suele modelar mediante el patrón Composite.
-Iterator: Se utiliza para poder movernos por los elementos de un conjunto de forma
secuencial sin necesidad de exponer su implementación específica.
-Mediator: Objeto que encapsula cómo otro conjunto de objetos interactúan y se comunican
entre sí.
-Memento: Este patrón otorga la capacidad de restaurar un objeto a un estado anterior
-Observer: Los objetos son capaces de suscribirse a una serie de eventos que otro objetivo
va a emitir, y serán avisados cuando esto ocurra.
-State: Permite modificar la forma en que un objeto se comporta en tiempo de ejecución,
basándose en su estado interno.
-Strategy: Permite la selección del algoritmo que ejecuta cierta acción en tiempo de
ejecución.
-Template Method: Especifica el esqueleto de un algoritmo, permitiendo a las subclases
definir cómo implementan el comportamiento real.
-Visitor: Permite separar el algoritmo de la estructura de datos que se utilizará para
ejecutarlo. De esta forma se pueden añadir nuevas operaciones a estas estructuras sin
necesidad de modificarlas

13. ¿QUÉ ES UNA BASE DE DATOS RELACIONAL Y CUÁLES EXISTEN EN EL

MERCADO? ¿QUÉ ES UNA BASE DE DATOS NOSQL Y CUÁLES EXISTEN EN
EL MERCADO (LAS MAS RECONOCIDAS)?

Una base de datos relacional es un tipo de base de datos que almacena y proporciona acceso
a puntos de datos relacionados entre sí. Las bases de datos relacionales se basan en el
modelo relacional, una forma intuitiva y directa de representar datos en tablas. En una base
de datos relacional, cada fila de la tabla es un registro con un ID único llamado clave. Las
columnas de la tabla contienen atributos de los datos, y cada registro generalmente tiene un
valor para cada atributo, lo que facilita el establecimiento de las relaciones entre los puntos
de datos.
En el mercado existen: MySQL, PostgreSQL, Oracle Database, SQL Server, SQLite, ,
Acces y MariaDB.

Las bases de datos no relacionales son un sistema de almacenamiento de información que

se caracteriza por no usar el lenguaje SQL para las consultas. Otra de sus principales
características es que no trabajan con estructuras definidas. Es decir, los datos no se
almacenan en tablas, y la información tampoco se organiza en registros o campos. Tienen
una gran escalabilidad y están pensadas para la gestión de grandes volúmenes de datos. Por
otro lado, a diferencia de las bases de datos relacionales no cumple con el estándar ACID
de atomicidad, consistencia, aislamiento y durabilidad.
En el mercado existen: MongoDB, Redis, Cassandra y CouchDB.

14. ¿QUÉ ES UN API?

Interfaz de programación de aplicaciones. Se trata de un conjunto de definiciones y

protocolos que se utiliza para desarrollar e integrar el software de las aplicaciones,
permitiendo la comunicación entre dos aplicaciones de software a través de un conjunto de
reglas.
Una API es como un módulo formal o una interfaz de como un software se comunica o
interactúa con otro para cumplir una o muchas funciones. Todo dependiendo de las
aplicaciones que las vayan a utilizar, y de los permisos que les dé el propietario de la API a
los desarrolladores de terceros.

15. ¿CUÁL ES LA DIFERENCIA ENTRE UNA LIBRERÍA Y UN FRAMEWORK?

LIBRERÍA FRAMEWORK
Es un conjunto de funcionalidades, que Es una plantilla o esquema conceptual que
resuelven necesidades específicas del sirve para organizar o desarrollar software
proyecto, empaquetadas y reutilizables. de forma más sencilla, automatizando
procesos en un proyecto.
El framework nos proporciona un marco de trabajo para desarrollar aplicaciones mientras
que las librerías solucionan un problema en concreto para que el código se más fácil de
leer.

16. ¿QUÉ FRAMEWORKS Y LIBRERÍAS MODERNOS EXISTEN PARA

DESARROLLAR FRONTEND?
LIBRERÍA FRAMEWORK
React AngularJS y Angular 2 (typescript)
JQuery Vue
Dojo Ember
Zepto Meteor

17. ¿QUÉ FRAMEWORKS MODERNOS EXISTEN PARA DESARROLLAR

BACKEND?
LIBRERÍA FRAMEWORK
Pchart, Upload (php) Django, Pyramid (pyton)
Requests, tqdm (python) Express, Koa2 (node js)
Redux Laravel, Symfony (php)
Spring, Dropwizard (java)
Ruby on rails, Sinatra (ruby)
18. TIPOS DE AMBIENTES DE APLICACIONES. AMBIENTE DE PRUEBAS,
AMBIENTE DE DESARROLLO, AMBIENTE DE PREPRODUCIÓN, AMBIENTE
DE PRODUCCIÓN. ¿HAY ALGÚN OTRO TIPO DE AMBIENTE?

Un ambiente refiere a hardware y software donde se ejecuta una aplicación. Dependiendo

del proceso de desarrollo la cantidad de ambientes por los cuales iremos propagando una
aplicación desde desarrollo hasta producción. Cada ambiente tiene su propia base de datos
y su copia de los binarios de la aplicación de forma que no haya interferencias en los
ambientes y entre los diferentes participantes en la construcción del software.

AMBIENTES DE PRUEBAS
Un ambiente de prueba es un término utilizado en el campo del software y desarrollo de
sitios web previo a la producción. Describe la ubicación en la que se ven previamente los
cambios en un sitio web o software y son ajustados antes de su publicación final. Los
ambientes de prueba pueden ser utilizados para actividades de pruebas de aceptación del
usuario. Se suelen utilizar configuraciones de hardware similares a las del entorno de
producción, con sujetos de prueba que proporcionan una previsión del rendimiento.

AMBIENTE DE DESARROLLO
Es el ambiente de creación del software. Este entorno puede ser manejado a nivel local en
el ordenador del programador o en un servidor local. Así mismo, puede ser procesado en
herramientas desarrolladas para este tipo de tareas. En este espacio de trabajo el
desarrollador codifica, realiza las pruebas iniciales y comprueba la ejecución del código.

AMBIENTE DE PREPRODUCCION
También llamado entorno de staging, permite trabajar en un entorno con una configuración
exactamente igual a la que existe en el entorno de producción. La finalidad de usar este tipo
de servidor es simular el entorno de producción para validar su usabilidad en un entorno
real. Del mismo modo permite el poder realizar pruebas de actualizaciones y minimizar las
causas que puedan generar caídas del sistema.

AMBIENTE DE PRODUCCION
Es el entorno donde finalmente se ejecuta el software, el cual es utilizado por el usuario
Este servidor, a diferencia del servidor de pre-producción, debería tener una mayor
infraestructura y mayor capacidad de manejo de tráfico o de conexiones recurrentes.
Si el entorno de producción está bien configurado, se han realizado pruebas automatizadas
y por parte del usuario. No debería existir ninguna incidencia en la ejecución del software
final.

AMBIENTE DE INTEGRACION
El entorno de integración facilita la unión de los diferentes desarrollos y permite comprobar
que los diferentes trabajos no interfieran entre sí.

AMBIENTE DE DESARROLLO INTEGRADO A LA NUBE

Cuando se trabaja con un entorno de desarrollo cloud no es necesario descargar el software,
el sistema no consume una gran cantidad de recursos informáticos y no hay que realizar
configuraciones locales. Todo esto tiene como consecuencia que el entorno de desarrollo se
pueda utilizar de forma inmediata y los desarrolladores puedan colaborar en los diferentes
proyectos de forma rápida.

19. ¿QUÉ SIGNIFICA DESPLEGAR UNA APLICACIÓN EN UN AMBIENTE?

Significa llevar dicha aplicación o los cambios realizados en ella a lo largo del tiempo
desde el entorno de desarrollo (local) hasta el entorno de producción, pasando
habitualmente por otros entornos como pruebas, preparación (staging) o pre-producción etc.
El despliegue de aplicaciones consiste generalmente en recuperar el código del sistema de
control de versiones, copiarlo a la máquina o máquinas de destino y realizar ciertas tareas
como la instalación/actualización de dependencias, la preparación de recursos CSS y
Javascript, ejecución de migraciones de la base de datos etc. En un proyecto pequeño o que
no requiera despliegues de forma habitual, estas tareas pueden ser realizadas de forma
manual o semi-manual, por ejemplo con el uso de algunos scripts que automaticen parte de
las mismas.

20. INTEGRACIÓN CONTINUA. DESPLIEGUE CONTINUO. LIBERACIÓN

CONTINUA (CI,CD)

INTEGRACION CONTINUA
Es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los
cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan
versiones y pruebas automáticas. La integración continua se refiere en su mayoría a la fase
de creación o integración del proceso de publicación de software y conlleva un componente
de automatización. Los objetivos clave de la integración continua consisten en encontrar y
arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que
se tarda en validar y publicar nuevas actualizaciones de software.
Consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para
así poder detectar fallos cuanto antes. Entendemos por integración la compilación y
ejecución de pruebas de todo un proyecto.

DESPLIEGUE CONTINUO
El despliegue continuo o CD (continuous deployment) está relacionado estrechamente con
la entrega continua. Con el despliegue continuo se va un paso más allá de la entrega
continua, automatizando todo el proceso de entrega de software al usuario, eliminando la
acción manual o intervención humana necesaria en la entrega continua.

LIBERACION CONTINUA
Se refiere a un sistema de lanzamiento y actualizaciones constante del software. Esto, en
contraste con un modelo de desarrollo estándar de liberación que utiliza diferentes
versiones que deben reinstalarse sobre la versión anterior, genera un menor riesgo al
actualizar componentes importantes del programa, ya que son actualizados gradualmente.

21. ¿QUÉ ES DEVOPS?

El término DevOps, que es una combinación de los términos ingleses development y

operations, designa la unión de personas, procesos y tecnología para ofrecer valor a los
clientes de forma constante.
Permite que los roles que antes estaban aislados (desarrollo, operaciones de TI, ingeniería
de la calidad y seguridad) se coordinen y colaboren para producir productos mejores y más
confiables. Al adoptar una cultura de DevOps junto con prácticas y herramientas de
DevOps, los equipos adquieren la capacidad de responder mejor a las necesidades de los
clientes, aumentar la confianza en las aplicaciones que crean y alcanzar los objetivos
empresariales en menos tiempo.
Bajo un modelo de DevOps, los equipos de desarrollo y operaciones ya no están “aislados”.
A veces, los dos equipos se fusionan en uno solo, donde los ingenieros trabajan en todo el
ciclo de vida de la aplicación, desde el desarrollo y las pruebas hasta la implementación y
las operaciones, y desarrollan una variedad de habilidades no limitadas a una única función.
En algunos modelos de DevOps, los equipos de control de calidad y de seguridad también
se integran más con el desarrollo y las operaciones e intervienen durante todo el ciclo de
vida de la aplicación.
22. ¿QUÉ ES DOCKER Y KUBERNETES?

DOCKER
Docker es una plataforma de software que le permite crear, probar e implementar
aplicaciones rápidamente. Docker empaqueta software en unidades estandarizadas llamadas
contenedores que incluyen todo lo necesario para que el software se ejecute, incluidas
bibliotecas, herramientas de sistema, código y tiempo de ejecución.
Es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de
contenedores de software, proporcionando la automatización de virtualización de
aplicaciones en múltiples sistemas operativos. Docker utiliza características de aislamiento
de recursos del kernel Linux, tales como cgroups y namespaces para permitir que
"contenedores" independientes se ejecuten dentro de una sola instancia de Linux, evitando
la sobrecarga de iniciar y mantener máquinas virtuales.
CONTENEDOR: objeto que contiene otros objetos que pueden ser incluidos o eliminados
dinámicamente.

KUBERNETES
Es una plataforma de código abierto para automatizar la implementación, el escalado y la
administración de aplicaciones en contenedores.
Kubernetes es una plataforma portable y extensible de código abierto para administrar
cargas de trabajo y servicios. Facilita la automatización y la configuración declarativa.
Tiene un ecosistema grande y en rápido crecimiento. El soporte, las herramientas y los
servicios para Kubernetes están ampliamente disponibles.
Elimina muchos de los procesos manuales involucrados en la implementación y
escalabilidad de las aplicaciones en contenedores.
AMOBOS SON LINUX