Universidad Politécnica de Aguascalientes.

EGEL

Unit 2

Juan Pablo Rodríguez Serna

ID: UP200512

Teacher: Luis Humberto Cruz Aguilar

Group: ISC09A

Aguascalientes, México, October 2nd, 2023

1. Seleccionar técnicas o herramientas (diagrama de secuencia, de colaboración,
entidad-relación, de clases, entre otros) para el modelado de una solución de
software.
Existen diferentes formas de presentar aspectos de un sistema de software, dichas
formas ayudan a comprender de mejor manera, visualizar y comunicar los diferentes
aspectos de un sistema de software antes de realizar su implementación.
• Diagrama de casos de uso:

o Descripción: El diagrama de casos de uso representa las interacciones entre

los actores (usuarios u otros sistemas) y un sistema de software. Muestra los
diferentes escenarios de uso del sistema y cómo los actores interactúan con él.

o Propósito: Se utiliza para identificar y documentar los requisitos funcionales

de un sistema desde una perspectiva de usuario.

o Ejemplo de uso: En un sistema de gestión de biblioteca, un caso de uso

podría ser "Prestar libro", donde el actor principal es el bibliotecario. El diagrama
mostraría cómo el bibliotecario interactúa con el sistema para llevar a cabo el
proceso de préstamo.

• Diagrama de secuencia:

o Descripción: El diagrama de secuencia representa la interacción entre objetos

a lo largo del tiempo. Muestra la secuencia de mensajes entre objetos y cómo
responden a esos mensajes.

o Propósito: Se utiliza para modelar el comportamiento dinámico de un sistema

y cómo los objetos colaboran en un escenario específico.

o Ejemplo de uso: En un sistema de reservas de vuelos, el diagrama de

secuencia puede mostrar cómo un cliente busca vuelos disponibles, selecciona uno
y realiza una reserva, interactuando con objetos como el motor de búsqueda y el
sistema de reservas.

• Diagrama de colaboración:

o Descripción: El diagrama de colaboración muestra cómo los objetos

interactúan entre sí en un sistema, centrándose en la estructura de la comunicación
entre objetos y la secuencia de mensajes.
o Propósito: Se utiliza para visualizar cómo los objetos colaboran para lograr un
objetivo y cómo se comunican en un escenario específico.

o Ejemplo de uso: En un sistema de reserva de habitaciones de hotel, el

diagrama de colaboración podría representar cómo un cliente interactúa con objetos
como "Habitación Disponible," "Reserva" y "Factura" para realizar una reserva.

• Diagrama de clases:

o Descripción: El diagrama de clases representa la estructura estática de un

sistema, incluyendo las clases, sus atributos, métodos y relaciones entre ellas.

o Propósito: Se utiliza para visualizar la estructura de un sistema y las

relaciones entre sus componentes.

o Ejemplo de uso: En un sistema de gestión de estudiantes, el diagrama de

clases podría representar clases como "Estudiante," "Profesor," "Curso," y mostrar
cómo se relacionan entre sí a través de asociaciones.

• Diagrama de componentes:

o Descripción: El diagrama de componentes representa los componentes

físicos o lógicos de un sistema y sus dependencias. Puede incluir bibliotecas,
módulos, subsistemas, etc.

o Propósito: Se utiliza para diseñar y visualizar la arquitectura de un sistema y

cómo sus componentes se relacionan y dependen entre sí.

o Ejemplo de uso: En un sistema de gestión de hospital, el diagrama de

componentes podría representar componentes como "Registro de Pacientes,"
"Sistema de Laboratorio" y "Sistema de Facturación" y sus dependencias.

• Diagrama de actividad:

o Descripción: El diagrama de actividad modela el flujo de actividades o

procesos dentro de un sistema. Representa tareas, decisiones y ramificaciones en
un proceso.

o Propósito: Se utiliza para modelar procesos de negocio, flujos de trabajo y el

comportamiento de un sistema en términos de actividades.
o Ejemplo de uso: En un sistema de gestión de pedidos en línea, el diagrama
de actividad puede representar el proceso desde la selección de productos hasta el
pago, mostrando las actividades involucradas y las decisiones tomadas.

• Diagrama de estados:

o Descripción: El diagrama de estados modela el comportamiento de un objeto

en diferentes estados y cómo cambia de un estado a otro en respuesta a eventos.

o Propósito: Se utiliza para representar el comportamiento dinámico de un

objeto o entidad a lo largo de su ciclo de vida.

o Ejemplo de uso: En un sistema de control de acceso, el diagrama de estados

de un usuario podría incluir estados como "Desconectado," "Conectado" y
"Bloqueado," mostrando las transiciones entre ellos en función de eventos como
"Inicio de sesión exitoso" o "Cierre de sesión."

• Diagrama de despliegue:

o Descripción: El diagrama de despliegue representa cómo los componentes y

artefactos de software se distribuyen en nodos físicos (como servidores) en un
entorno de implementación.

o Propósito: Se utiliza para diseñar la infraestructura técnica de un sistema y

cómo los componentes se despliegan en el hardware.

o Ejemplo de uso: En un proyecto de desarrollo web, el diagrama de

despliegue puede mostrar cómo los componentes del servidor web, la base de datos
y la aplicación se distribuyen en servidores físicos y virtuales.

• Diagrama entidad-relación:

o Descripción: El diagrama ER se utiliza para modelar la estructura de una

base de datos, incluyendo entidades, atributos y relaciones entre ellas.

o Propósito: Se utiliza para diseñar y representar la estructura de una base de

datos y cómo los datos se relacionan.

o Ejemplo de uso: En un sistema de gestión de inventario, el diagrama ER

podría representar entidades como "Producto," "Proveedor," "Pedido" y sus
relaciones, mostrando cómo se almacenan y gestionan los datos.

• Diagrama de flujo de datos:

o Descripción: El DFD modela cómo los datos fluyen a través de un sistema,
identificando procesos, flujos de datos y almacenamiento de datos.

o Propósito: Se utiliza para comprender cómo se procesan y transforman los

datos en un sistema.

o Ejemplo de uso: En un sistema de gestión de biblioteca, un DFD podría

representar cómo los datos fluyen desde la entrada de un nuevo libro en el sistema
hasta la generación de informes de inventario, identificando los procesos
involucrados y los datos que se manejan.

2. Identificar herramientas de ajuste al modelo de solución.

• Entornos de Desarrollo Integrados (IDE):

o Ejemplos: Visual Studio, IntelliJ IDEA, Eclipse, PyCharm.

o Propósito: Facilitan el desarrollo de código fuente proporcionando

herramientas de edición, depuración, compilación y administración de proyectos en
un solo entorno.

• Herramientas de Gestión de Proyectos:

o Ejemplos: Jira, Trello, Asana, Microsoft Project.

o Propósito: Ayudan a planificar, supervisar y controlar el progreso del

proyecto, asignar tareas, gestionar el flujo de trabajo y colaborar en equipo.

• Sistemas de Control de Versiones:

o Ejemplos: Git, Subversion (SVN), Mercurial.

o Propósito: Permiten el seguimiento de cambios en el código fuente, la

colaboración en equipo y la gestión de ramas de desarrollo.

• Herramientas de Automatización de Despliegue:

o Ejemplos: Jenkins, Travis CI, CircleCI.

o Propósito: Automatizan la compilación, pruebas y despliegue de código,

facilitando la integración continua y la entrega continua (CI/CD).

• Gestión de Configuración y Cambios:

o Ejemplos: Ansible, Puppet, Chef.

o Propósito: Automatizan la configuración y gestión de servidores y sistemas,

asegurando que los entornos sean consistentes y reproducibles.

• Herramientas de Monitoreo y Gestión de Rendimiento:

o Ejemplos: Nagios, New Relic, Splunk.

o Propósito: Monitorean el rendimiento de aplicaciones y sistemas en

producción, generan alertas y proporcionan información para la solución de
problemas.

• Herramientas de Pruebas Automatizadas:

o Ejemplos: Selenium, JUnit, Appium.

o Propósito: Facilitan la ejecución de pruebas funcionales, pruebas unitarias y

pruebas de rendimiento de manera automatizada.

• Herramientas de Seguridad de Aplicaciones:

o Ejemplos: OWASP ZAP, Nessus, Burp Suite.

o Propósito: Detectan y corrigen vulnerabilidades de seguridad en aplicaciones

y sistemas.

• Herramientas de Gestión de Base de Datos:

o Ejemplos: MySQL Workbench, Microsoft SQL Server Management Studio,

MongoDB Compass.

o Propósito: Facilitan el diseño, desarrollo y administración de bases de datos.

• Herramientas de Documentación:

o Ejemplos: Confluence, WikiMedia, Doxygen.

o Propósito: Ayudan a crear y mantener documentación técnica, manuales de

usuario y documentación de diseño.
3. Aplicar herramientas de ajuste al modelo de solución.
• Jira:

o Aplicación: Utiliza Jira para crear un tablero de proyecto que incluya historias
de usuario, tareas de desarrollo y tareas de prueba.

o Proceso: Asigna tareas a los miembros del equipo, establece fechas de

vencimiento y realiza un seguimiento del progreso del proyecto en tiempo real.

o Beneficio: Facilita la colaboración en equipo, permite la priorización de tareas

y proporciona visibilidad en el estado del proyecto.

• Git:

o Aplicación: Crea un repositorio Git para el código fuente de tu proyecto.

o Proceso: Los desarrolladores pueden confirmar cambios en el código en el

repositorio y crear ramas para nuevas características o correcciones de errores.

o Beneficio: Controla la versión del código, permite la colaboración simultánea

de múltiples desarrolladores y facilita la gestión de cambios.

• Jenkins:

o Aplicación: Configure Jenkins para automatizar la construcción y despliegue

de la aplicación.

o Proceso: Configure trabajos de construcción que se ejecuten

automáticamente después de cada confirmación en el repositorio Git, y configure
despliegues automáticos en entornos de prueba y producción.

o Beneficio: Acelera la entrega de software, reduce errores de implementación

y garantiza una integración continua.

• Nagios:

o Aplicación: Implementa Nagios para supervisar los servidores y servicios

críticos.
o Proceso: Configure reglas de supervisión para verificar el estado de los
servidores y servicios, y configure alertas para notificar a los equipos de
operaciones sobre problemas.

o Beneficio: Detecta y responde rápidamente a problemas de rendimiento o

disponibilidad, minimizando el tiempo de inactividad.

• Selenium:

o Aplicación: Utiliza Selenium para automatizar pruebas funcionales en tu

aplicación web.

o Proceso: Crea scripts de prueba que simulan interacciones de usuario, como

completar formularios y hacer clic en botones, y verifica que las funciones de la
aplicación funcionen correctamente.

o Beneficio: Mejora la calidad del software al automatizar pruebas repetitivas y

asegurarse de que las características críticas funcionen como se espera.

• MySQL Workbench:

o Aplicación: Utiliza MySQL Workbench para diseñar y administrar la base de

datos del proyecto.

o Proceso: Diseña el esquema de la base de datos, crea tablas, define

relaciones y escribe consultas SQL para interactuar con la base de datos.

o Beneficio: Facilita la administración de la base de datos y garantiza que los

datos se almacenen y recuperen correctamente.

4. Identificar las diferentes arquitecturas de diseño.

Una arquitectura de diseño es la estructura fundamental de un sistema de software,
que define sus componentes, sus relaciones y su interacción. La arquitectura de
diseño es un componente importante del proceso de desarrollo de software, ya que
proporciona una visión general del sistema y ayuda a garantizar que el sistema
cumpla con sus requisitos.
Arquitecturas de diseño con acoplamiento alto: Las arquitecturas de diseño con
acoplamiento alto son aquellas en las que los componentes están estrechamente
relacionados. Los cambios en un componente pueden tener un impacto en otros
componentes.
● Arquitectura monolítica: En una arquitectura monolítica, todos los
componentes del sistema están integrados en una sola unidad.(Supongamos que
estás desarrollando una pequeña tienda en línea. En este caso, podrías optar por
una arquitectura monolítica en la que todos los componentes de la aplicación, como
la gestión de usuarios, catálogo de productos, carrito de compras y procesamiento
de pedidos, estén integrados en una sola unidad. Esto significa que todos estos
módulos se ejecutan en un solo servidor o contenedor de aplicaciones. Si bien esto
puede ser adecuado para una tienda en línea de tamaño pequeño o mediano,
puede volverse complicado a medida que la aplicación crece, ya que todos los
cambios y actualizaciones se deben realizar en la misma base de código
monolítica.)
● Arquitectura de capa: En una arquitectura de capa, los componentes están
organizados en capas, con cada capa proporcionando una función
específica.(Imagina que estás desarrollando una aplicación más grande y compleja
de comercio electrónico. En este caso, podrías utilizar una arquitectura de capa.
Podrías tener una capa de presentación para la interfaz de usuario, una capa de
lógica de negocio para el procesamiento de pedidos y la gestión de productos, y una
capa de acceso a datos para interactuar con la base de datos. Cada capa se
encargaría de una función específica, lo que facilitaría la escalabilidad y el
mantenimiento de la aplicación a medida que crece y evoluciona.)
● Arquitectura orientada a objetos: En una arquitectura orientada a objetos, los
componentes están organizados en clases, con cada clase representando un tipo de
objeto.(Supongamos que deseas desarrollar una aplicación altamente modular y
reutilizable para el comercio electrónico. En este caso, podrías optar por una
arquitectura orientada a objetos. Podrías crear clases para representar diferentes
objetos en tu aplicación, como "Usuario", "Producto", "Carrito de Compras" y
"Pedido". Cada clase encapsularía su funcionalidad y datos relacionados. Esto
facilitaría la reutilización de código y la creación de nuevas características al
extender las clases existentes.)
Arquitecturas de diseño con acoplamiento bajo: Las arquitecturas de diseño con
acoplamiento bajo son aquellas en las que los componentes están relativamente
independientes. Los cambios en un componente no suelen tener un impacto en
otros componentes.
● Arquitectura cliente-servidor: En una arquitectura cliente-servidor, los
componentes se dividen en clientes y servidores. Los clientes realizan las peticiones
y los servidores proporcionan los servicios.(Supongamos que estás desarrollando
una aplicación de redes sociales como Facebook. En esta arquitectura, los clientes
serían las aplicaciones o navegadores utilizados por los usuarios para acceder a la
plataforma. Los clientes envían solicitudes al servidor central, que es responsable
de gestionar la autenticación de usuarios, almacenar y recuperar publicaciones,
gestionar la privacidad y proporcionar datos a los clientes. Los clientes realizan
peticiones para ver el feed de noticias, publicar actualizaciones, enviar mensajes,
etc. El servidor procesa estas solicitudes y devuelve la información correspondiente
a los clientes.)
● Arquitectura en capas: En una arquitectura en capas, los componentes se
organizan en capas, con cada capa proporcionando una función específica. Sin
embargo, las capas están desacopladas entre sí, lo que facilita la modificación o el
mantenimiento del sistema.(En una aplicación de redes sociales más grande y
compleja, podrías utilizar una arquitectura en capas. Podrías dividir la aplicación en
varias capas, como la capa de presentación (interfaz de usuario), la capa de lógica
de negocio (gestión de amistades, publicación de contenido, notificaciones) y la
capa de almacenamiento de datos (bases de datos para usuarios, publicaciones,
fotos, etc.). Cada capa tendría una función específica, y estarían desacopladas
entre sí. Esto significa que puedes modificar o mantener una capa sin afectar las
otras, lo que facilita la gestión y escalabilidad de la aplicación.)
● Arquitectura orientada a servicios: En una arquitectura orientada a servicios,
los componentes se basan en servicios. Los servicios son unidades de código que
proporcionan una función específica. Los componentes se comunican entre sí
mediante la invocación de servicios.(En una arquitectura orientada a servicios para
una aplicación de redes sociales, podrías diseñar la plataforma en torno a servicios
individuales. Por ejemplo, podrías tener servicios separados para la autenticación, el
almacenamiento de publicaciones, la gestión de notificaciones y la búsqueda de
usuarios. Cada servicio proporcionaría una función específica y se comunicaría con
otros servicios a través de solicitudes de API. Por ejemplo, cuando un usuario hace
una publicación, la aplicación invocaría el servicio de almacenamiento de
publicaciones para guardar la publicación en la base de datos. Esto permite una
mayor modularidad y reutilización de servicios en toda la aplicación.)
Selección de una arquitectura de diseño
● Los requisitos del sistema: La arquitectura de diseño debe cumplir con los
requisitos del sistema, como el rendimiento, la seguridad y la escalabilidad.
● Las restricciones del sistema: La arquitectura de diseño debe cumplir con las
restricciones del sistema, como el presupuesto, el tiempo y las habilidades del
equipo.
● Las preferencias del equipo: El equipo de desarrollo debe estar familiarizado
con la arquitectura de diseño elegida.
● El presupuesto del sistema
5. Seleccionar la arquitectura de diseño.
Requisitos del sistema
Los requisitos del sistema son las características y el comportamiento que el
sistema debe tener. La arquitectura de diseño debe cumplir con estos requisitos
para garantizar que el sistema funcione como se espera.
● El rendimiento: La arquitectura de diseño debe ser capaz de proporcionar el
rendimiento necesario para el sistema.
● La seguridad: La arquitectura de diseño debe proteger el sistema de accesos
no autorizados y ataques.
● La escalabilidad: La arquitectura de diseño debe ser capaz de adaptarse al
crecimiento del sistema.
● La disponibilidad: La arquitectura de diseño debe garantizar que el sistema
esté disponible cuando sea necesario.
Restricciones del sistema
Las restricciones del sistema son los límites que se imponen al desarrollo del
sistema. La arquitectura de diseño debe cumplir con estas restricciones para
garantizar que el sistema pueda desarrollarse y mantenerse dentro del presupuesto
y el tiempo disponibles.
● El presupuesto: La arquitectura de diseño debe ser factible dentro del
presupuesto disponible.
● El tiempo: La arquitectura de diseño debe poder desarrollarse y mantenerse
dentro del tiempo disponible.
● Los recursos: La arquitectura de diseño debe ser compatible con los recursos
disponibles, como el hardware, el software y el personal.
Preferencias del equipo
● La experiencia: El equipo debe estar familiarizado con la arquitectura de
diseño elegida para facilitar el desarrollo y el mantenimiento del sistema.
● Las habilidades: El equipo debe tener las habilidades necesarias para
implementar la arquitectura de diseño elegida.
● Las preferencias personales: El equipo puede preferir una arquitectura de
diseño que sea fácil de entender y mantener.

6. Identificar los modelos de datos de diseño.

Los modelos de datos son representaciones abstractas de los datos que se
almacenarán en un sistema de software. Se utilizan para comunicar los requisitos de
datos del sistema y para ayudar a los desarrolladores a implementar la estructura de
datos del sistema.
Modelos de datos conceptuales: Los modelos de datos conceptuales representan
los datos a un nivel general. Son útiles para comunicar los requisitos de datos del
sistema a los usuarios y a los desarrolladores.

Modelos de datos lógicos: Los modelos de datos lógicos representan los datos a un
nivel más detallado que los modelos de datos conceptuales. Son útiles para definir
la estructura de datos del sistema.

Modelos de datos físicos: Los modelos de datos físicos representan los datos a un
nivel muy detallado. Son útiles para definir la implementación de la estructura de
datos del sistema.

Elección del modelo de datos

La elección del modelo de datos adecuado para un proyecto de software depende
de una serie de factores, que incluyen:
● El tipo de sistema que se está desarrollando: Los sistemas orientados a
objetos suelen utilizar modelos de datos conceptuales y lógicos basados en clases.
Los sistemas orientados a datos suelen utilizar modelos de datos lógicos y físicos
basados en relaciones.
● Los requisitos del sistema: Los requisitos de datos del sistema pueden influir
en la elección del modelo de datos adecuado.
● El nivel de detalle requerido: El nivel de detalle requerido para el modelo de
datos puede influir en la elección del modelo de datos adecuado.
● Las habilidades y experiencia del equipo de desarrollo: Las habilidades y
experiencia del equipo de desarrollo pueden influir en la elección del modelo de
datos adecuado.

6. Identificar los modelos de datos de diseños:

Diseño de casos de usos
Esta actividad aplica para el modelo orientado a objetos, se especifica el
comportamiento del sistema mediante caso de uso, se definen los objetos, las
operaciones de las clases e interfaces.
Asimismo, de ser necesario se complementan los escenarios de los casos de uso;
en este caso se diseñarán las interfaces correspondientes.
El objetivo es identificar las clases que intervienen en cada caso de uso, las cuales
se identifican a partir de las clases del análisis y de aquellas clases adicionales
necesarias para el escenario que
se está diseñando.
Se deberá generar como parte de esta actividad lo siguiente:
• Diagrama de interacción de objetos
• Diagrama de transición de estados
• Prototipos

Diseño de clases
Esta actividad se realiza para el modelo orientado a objetos. Se transforma el
modelo de clases lógico, que proviene del análisis, en un modelo de clases de
diseño, especificando los atributos, operaciones, métodos y relaciones entre ellos,
consignando los métodos de agregación, asociación o jerarquía.
Para esta actividad se debe realizar:
-Identificación de atributos de la clase
-Identificación de las operaciones de las clases

Diseño de módulos del sistema

Esta actividad se realiza para el modelo de diseño estructurado, se definen los
módulos del sistema y la manera en que van a interactuar unos con otros,
intentando que cada módulo trate total o parcialmente un proceso.
Se efectúa una descomposición modular de los subsistemas, se diseñan los
módulos de consulta, que en ocasiones no se describen en el modelo de procesos,
pero sí se mencionan en la lista de requerimientos.
Se analiza el alcance y características de cada proceso a fin de determinar el
acceso a la información de bases de datos, implementación de reglas del negocio;
se define la presentación de información en los dispositivos de interface con los que
el usuario va a interactuar. Este análisis permite identificar los procesos propios del
sistema y los servicios comunes.
Posteriormente, se detalla la lógica de negocio del sistema, mediante pseudocódigo;
se definen las interfaces entre los módulos de cada subsistema, entre subsistemas y
con el resto de los sistemas de información, incluyendo la comunicación de control
como los datos propios del sistema.

Diseño físico:
Se desarrolla el modelo físico de datos a partir del modelo lógico de datos
normalizado o del modelo de clases, en el caso del modelo orientado a objetos.
Previo a la elaboración del modelo físico se evalúa el gestor de base de datos por
considerar, la proyección de crecimiento de las entidades, las necesidades de
migración y el volumen de datos.
Esta información es necesaria para una mejor implementación del modelo lógico de
datos / modelo de clases. Asimismo, para efectuar una estimación del
almacenamiento a nivel de hardware.
El objetivo de identificar los caminos de acceso a los datos persistentes del sistema,
que son utilizados por los principales módulos / clases de acuerdo con el modelo
físico de datos, es de optimizar el rendimiento de los gestores de datos y el
consumo de recursos. También, disminuir los tiempos de respuesta en el sistema.

Aplicar el modelo de datos:

Los modelos de datos de diseño se pueden aplicar en tres fases principales:

Fase 1: Recopilación de requisitos

En esta fase, se recopilan los requisitos de datos del sistema. Esto se puede hacer
mediante entrevistas con los usuarios, encuestas o análisis de documentos.

Fase 2: Modelado conceptual

En esta fase, se crea un modelo conceptual de datos que representa los conceptos
del mundo real que se almacenan en la base de datos. Se utilizan diagramas de
entidad-relación (ER) para representar los datos conceptuales.

Fase 3: Modelado lógico

En esta fase, se crea un modelo lógico de datos que representa la estructura de los
datos y las relaciones entre ellos. Se utilizan diagramas de clases o diagramas de
objetos para representar los datos lógicos.

Implantación de software desarrollado

¿Cómo es el proceso de implementación de aplicaciones?

El proceso de implementación de aplicaciones consta de nueve pasos principales:

Planificación. En esta etapa, los equipos de desarrollo y operaciones unifican

criterios. También se asigna el calendario de implementación, se evalúa la
infraestructura actual y, si es necesario, se hacen cambios.
Creación y lanzamiento de la automatización. Activar la automatización es
fundamental para el éxito del proceso de implementación de aplicaciones, ya que es
necesario reducir al máximo la posibilidad de que se produzcan errores humanos. El
desarrollo de servidores robustos y scripts facilitará la posterior implementación en
la red.
Desarrollo de la integración y distribución continuas (CI/CD). Los esfuerzos
dedicados a reducir el grado de cambio en cada actualización de la aplicación
ayudarán a los equipos a detectar fallos en el futuro. Cuando las implementaciones
tengan un efecto mínimo, al sistema le resultará más sencillo llevar a cabo otras
más frecuentes.
Creación y pruebas de scripts. Identifique los cambios y las diferencias en el
entorno ejecutando scripts de prueba en una copia de seguridad del canal de
producción antes de pasar a la versión final.
Identificación de los parámetros clave. Asegúrese de que su equipo tenga claros
los indicadores clave de rendimiento (KPI) de cada aplicación. Este paso es sencillo:
confirme que los KPI estén configurados, la visibilidad esté activada y los posibles
errores en el conjunto de aplicaciones se solucionen rápidamente.
Pruebas. Configure pruebas de transacciones sintéticas y asegúrese de que los
elementos principales, como las páginas de inicio de sesión, funcionen
correctamente. Inicie la implementación con total confianza.
Desarrollo del seguimiento de la implementación. Facilite e implemente servicios
de seguimiento para garantizar que a los equipos de operaciones les resulte fácil
hacer un seguimiento de cuándo se producen las implementaciones (o cuándo
están programadas) y para identificar de inmediato cuándo se producen errores y
tratar de corregirlos.
Envío de alertas a usuarios y compañeros de trabajo. Este es un paso que se
suele pasar por alto, pero llegado el caso, avise a todas las partes necesarias sobre
cuándo se espera que se implemente una aplicación. Esta información ayudará a
coordinar todo el proceso, establecer expectativas y dar marcha atrás en caso de
que hubiera algún error.
Supervisión e iteración. Una vez implementada la aplicación, será tan importante
supervisar la implementación como corregirla según corresponda.

Metodología de implementación de aplicaciones

En lo que respecta a la implementación de aplicaciones, se pueden utilizar

numerosas técnicas. Algunas se pueden aplicar a través de balanceadores de
carga, que se han convertido en esenciales para el desarrollo de aplicaciones
modernas basadas en contenedores de Kubernetes y microservicios. Se suelen
utilizar las siguientes estrategias:

Recreación: se completa la versión A y, a continuación, se implementa la versión B.

Optimización: la versión B se implementa lentamente y reemplaza a la versión A.
En la sombra: la versión B recibe tráfico del mundo real junto con la versión A, pero
el tráfico enviado a la versión B no afecta a la respuesta.
Implementación azul-verde: la versión B se publica junto con la versión A y, a
continuación, el tráfico se cambia a la versión B.
Pruebas A/B: la versión B se publica para un subconjunto particular de usuarios
bajo condiciones específicas.
Implementación de prueba: la versión B se publica para un subgrupo de usuarios
y, a continuación, se pasa a una implementación completa.

Opera el sistema desarrollado.

El término "operar el sistema desarrollado" se refiere a poner en funcionamiento y

ejecutar el software desarrollado en un entorno de producción o en el entorno real
donde será utilizado por los usuarios finales. Esta etapa sigue a la fase de desarrollo
y pruebas del software y es un paso crucial en el ciclo de vida del desarrollo de
software.

Operar el sistema desarrollado implica varios pasos y consideraciones:

Preparación del entorno de producción: Asegurarse de que el entorno en el que

se ejecutará la aplicación esté listo y sea adecuado para su funcionamiento. Esto
incluye la configuración de servidores, redes, bases de datos y otros componentes
necesarios.

Despliegue: Instalar y configurar la aplicación en el entorno de producción. Esto

puede incluir la configuración de servidores, bases de datos y otros recursos
necesarios. El despliegue puede ser manual o automatizado, dependiendo de las
prácticas y herramientas utilizadas.

Pruebas de operación: Realizar pruebas específicas para asegurarse de que la

aplicación funciona correctamente en el entorno de producción. Esto puede incluir
pruebas de rendimiento, pruebas de escalabilidad, pruebas de seguridad y pruebas
de carga para garantizar que la aplicación sea capaz de manejar la demanda del
usuario.

Monitoreo y gestión: Establecer sistemas de monitoreo para supervisar el

rendimiento y el comportamiento de la aplicación en tiempo real. Esto ayuda a
detectar problemas y anomalías rápidamente y tomar medidas para abordarlos.

Respaldo y recuperación: Implementar políticas de respaldo y recuperación para

proteger los datos y la funcionalidad del sistema en caso de fallos o desastres.

Documentación y capacitación: Proporcionar documentación adecuada para los

usuarios finales y los administradores del sistema. Asegurarse de que el personal
esté capacitado para operar y mantener la aplicación de manera efectiva.

Soporte continuo: Proporcionar soporte técnico y mantenimiento continuo para

solucionar problemas, aplicar actualizaciones y mejoras, y garantizar que la
aplicación siga funcionando de manera óptima.

Evaluación y mejora continua: Evaluar regularmente el rendimiento y la eficiencia

de la aplicación en producción y realizar mejoras según sea necesario para
satisfacer las necesidades cambiantes de los usuarios y las demandas del negocio.

En resumen, operar el sistema desarrollado implica asegurarse de que el software

esté listo y funcionando en un entorno de producción real, y que sea capaz de
satisfacer las necesidades y expectativas de los usuarios de manera efectiva y
confiable. Esto es esencial para garantizar el éxito a largo plazo de un proyecto de
desarrollo de software.
 Realizar pruebas de operación y validez de la aplicación.

Realizar pruebas de operación y validez de una aplicación es una parte fundamental

del proceso de desarrollo de software. Estas pruebas ayudan a asegurarse de que
la aplicación funcione correctamente y cumpla con los requisitos especificados. Aquí
tienes una guía general sobre cómo llevar a cabo pruebas de operación y validez:

Planificación de pruebas:

Definir los objetivos de las pruebas: ¿Qué aspectos específicos de la aplicación se

van a probar? ¿Cuáles son los resultados esperados?
Crear casos de prueba: Desarrollar una serie de casos de prueba que cubran
diferentes funcionalidades y escenarios de uso de la aplicación.
Asignar recursos: Determinar quiénes serán los responsables de llevar a cabo las
pruebas y asignar recursos, como hardware y software de prueba.

Preparación del entorno de prueba:

Configurar un entorno de prueba aislado que sea lo más similar posible al entorno
de producción.
Instalar y configurar la aplicación en el entorno de prueba.
Asegurarse de que los datos de prueba estén disponibles y sean relevantes para los
casos de prueba.

Ejecución de pruebas:

Ejecutar los casos de prueba de acuerdo con el plan de pruebas.

Registrar los resultados de las pruebas, incluyendo cualquier error o anomalía que
se encuentre.

Seguimiento y corrección de errores:

Si se encuentran errores durante las pruebas, registrarlos detalladamente en un

sistema de seguimiento de problemas (bug tracker).
Priorizar y asignar recursos para corregir los errores encontrados.
Realizar pruebas adicionales para verificar que las correcciones se han aplicado
correctamente.

Validación de la funcionalidad:

Verificar que la aplicación cumple con los requisitos funcionales especificados en la

fase de diseño.
Asegurarse de que todas las funcionalidades principales funcionen según lo
previsto.
Comprobar que los flujos de trabajo de usuario se ejecuten sin problemas.

Validación de datos:

Verificar que los datos ingresados en la aplicación sean procesados y almacenados

correctamente.
Asegurarse de que los datos se recuperen correctamente cuando sea necesario.
Realizar pruebas de manipulación y validación de datos.

Validación de seguridad:

Realizar pruebas de seguridad para identificar posibles vulnerabilidades y

amenazas.
Comprobar la autenticación, autorización y protección contra ataques comunes,
como inyecciones SQL o ataques de denegación de servicio.

Validación de rendimiento:

Evaluar el rendimiento de la aplicación bajo diferentes cargas de trabajo.

Identificar posibles cuellos de botella y optimizar el rendimiento según sea
necesario.

Documentación de resultados:

Documentar los resultados de las pruebas, incluyendo los casos de prueba

ejecutados, los resultados obtenidos y cualquier problema detectado.
Generar informes de pruebas que resuman los hallazgos y las acciones tomadas.

Aprobación y entrega:

Una vez que todas las pruebas hayan sido exitosas y los problemas corregidos,
obtener la aprobación para la implementación de la aplicación en el entorno de
producción.