

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Métricas de desarrollo relacionadas con el acceso a la red para las ofertas de SaaS
<a name="assessment-engineering-dev"></a>

**Topics**
+ [Frecuencia de despliegue, tiempo de despliegue y velocidad de sprint](#assessment-engineering-dev-velocity)
+ [Flexibilidad y entrega de funciones](#assessment-engineering-dev-features)
+ [Cambie la tasa de fallas](#assessment-engineering-dev-failure-rate)
+ [La calidad del código y el rendimiento del equipo de ingeniería](#assessment-engineering-dev-performance)
+ [Reducción técnica de la deuda](#assessment-engineering-dev-debt-reduction)
+ [Escalabilidad, capacidad y rendimiento](#assessment-engineering-dev-scalability)

## Frecuencia de despliegue, tiempo de despliegue y velocidad de sprint
<a name="assessment-engineering-dev-velocity"></a>

Para optimizar la eficiencia del ciclo de desarrollo, es esencial que comprenda la influencia del aprovisionamiento de pilas de red en la velocidad de los sprints.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-velocity-high-score-criteria"></a>

El aprovisionamiento de la pila de redes está optimizado y automatizado, y requiere una intervención manual mínima. No afecta significativamente a la velocidad del sprint. Cualquier miembro del equipo puede realizar el aprovisionamiento y la redistribución de la pila de redes. Esto reduce los cuellos de botella y la dependencia de los recursos especializados.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-velocity-low-score-indicators"></a>

Se necesita una gran cantidad de argumentos para aprovisionar la red. Esto sugiere un proceso complejo y lento que dificulta el desarrollo de nuevas funciones. La redistribución frecuente de la red implica gastos generales considerables de tiempo y costes. Las tareas de aprovisionamiento de redes requieren conocimientos de ingeniería especializados, lo que crea cuellos de botella y ralentiza el ciclo de desarrollo.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-velocity-self-assessment-questions"></a>
+ Qué pasos manuales, si los hay, están involucrados en el proceso de implementación. ¿Cómo afectan a la frecuencia y el tiempo de despliegue?
+ ¿Cómo se gestionan las reversiones en caso de errores en la implementación? ¿Cuál es su impacto en la frecuencia de implementación y el tiempo de recuperación?
+ ¿Cuántos argumentos se necesitan para aprovisionar la red cuando se configuran nuevos entornos?
+ ¿Cuáles son los costes adicionales y la sobrecarga de tiempo que conlleva la redistribución frecuente de la pila de red durante el proceso de desarrollo?
+ ¿El aprovisionamiento de la red depende de la experiencia en ingeniería especializada o se trata de una tarea que puede gestionar cualquier miembro del equipo?

## Flexibilidad y entrega de funciones
<a name="assessment-engineering-dev-features"></a>

El enfoque de acceso a la red puede influir en la capacidad del equipo de ingeniería para innovar e implementar nuevas funciones de manera eficiente.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-features-high-score-criteria"></a>

El enfoque de acceso a la red ofrece la flexibilidad necesaria para un despliegue de funciones rápido y fluido. Es compatible con una amplia gama de protocolos de comunicación, comunicaciones unidireccionales y bidireccionales y tamaños de mensajes. No impone restricciones significativas a los procesos de desarrollo ni a la innovación.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-features-low-score-indicators"></a>

El enfoque de acceso a la red restringe la capacidad del equipo para implementar nuevas funciones debido a la falta de protocolos de comunicación compatibles, a la inflexibilidad en el tamaño de los mensajes o a la dependencia de tecnologías específicas y recursos especializados relacionados. Esto puede provocar ciclos de desarrollo más lentos y obstaculizar la evolución del servicio.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-features-self-assessment-questions"></a>
+ ¿Cómo afecta el enfoque de acceso a la red a la agilidad del equipo a la hora de desarrollar e implementar nuevas funciones?
+ ¿Existen limitaciones en el enfoque de acceso a la red que restrinjan la compatibilidad con determinados protocolos o tecnologías de comunicación?
+ ¿Cómo facilita o limita este enfoque la integración de nuevas tecnologías e innovaciones en el servicio?
+ ¿Cómo afecta el enfoque de acceso a la red a los plazos de desarrollo y a la hoja de ruta del producto?

## Cambie la tasa de fallas
<a name="assessment-engineering-dev-failure-rate"></a>

El enfoque de acceso a la red que elija puede afectar a la tasa de errores de los cambios al implementar nuevos servicios o funciones. Un mayor control a menudo implica una mayor flexibilidad, pero también aumenta la posibilidad de que se produzcan errores de configuración, como cuando se administra una configuración de enrutamiento compleja.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-failure-rate-high-score-criteria"></a>

Puede implementar cambios en la red con un riesgo mínimo de fallo. Existen suficientes mecanismos de prueba, mecanismos de reversión eficientes y una supervisión eficaz le ayuda a identificar y resolver los problemas rápidamente.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-failure-rate-low-score-indicators"></a>

El enfoque de acceso a la red es propenso a fallar durante los cambios. Las opciones de prueba son limitadas, las estrategias de implementación son complicadas o las capacidades de supervisión y solución de problemas son insuficientes. Se requiere la participación de varias partes en las sesiones de solución de problemas. Esto puede provocar un aumento del tiempo de inactividad y reducir la disponibilidad de la oferta de SaaS.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-failure-rate-self-assessment-questions"></a>
+ ¿Qué medidas se han adoptado para mitigar el riesgo de que los cambios no se produzcan al actualizar el conjunto de redes?
+ ¿Existen procesos exhaustivos de prueba y validación?
+ ¿Con qué rapidez puede el sistema recuperarse de un cambio fallido? ¿Existe un proceso de reversión eficiente?
+ ¿Existen sistemas proactivos de monitoreo y alerta para detectar y abordar los problemas con rapidez durante y después de los cambios en la red?
+ ¿Cuál es la tasa de errores por cambios históricos en las implementaciones de pilas de red? ¿Qué lecciones se han aprendido de los incidentes pasados?
+ ¿Cómo facilita o limita el enfoque de acceso a la red la implementación de los cambios? ¿El enfoque minimiza la interrupción del servicio?
+ ¿Cuál es el riesgo de afectar a la disponibilidad de la oferta de SaaS en el entorno de producción cuando se implementan cambios que implican el enfoque de acceso a la red?

## La calidad del código y el rendimiento del equipo de ingeniería
<a name="assessment-engineering-dev-performance"></a>

Los enfoques de acceso a la red pueden afectar indirectamente a la calidad del código de las ofertas de SaaS. La falta de estandarización en el acceso a la red puede obligar al equipo de ingeniería a admitir múltiples enfoques de integración, lo que puede llevar a una base de código sobrecargada. Esto, a su vez, puede dificultar la capacidad del equipo para desarrollar la profundidad y el control sobre la calidad del código necesarios para mantener un alto rendimiento de los equipos de ingeniería.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-performance-high-score-criteria"></a>

El equipo de ingeniería se mantiene concentrado gracias a la modularidad del código y a la reutilización en todos los enfoques de acceso a la red compatibles. Los enfoques de acceso a la red son compatibles con los procesos de despliegue y las estrategias de pruebas automatizadas existentes.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-performance-low-score-indicators"></a>

El rendimiento del equipo de ingeniería se reduce debido a la sobrecarga asociada a la integración y el mantenimiento de demasiados enfoques de acceso a la red. Algunos enfoques aumentan significativamente la complejidad, generan deuda tecnológica o requieren el desarrollo de soluciones alternativas para abordar las capacidades faltantes o insuficientes.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-performance-self-assessment-questions"></a>
+ ¿Cómo gestiona el enfoque de acceso a la red la variabilidad de la red?
+ ¿Necesita desarrollar un código adicional para gestionar las interrupciones en la conectividad?
+ ¿Un nuevo enfoque de acceso a la red se integra perfectamente con los enfoques existentes o requiere un desarrollo personalizado significativo?
+ ¿Cuál es el alcance del cambio necesario para adoptar un nuevo enfoque de acceso a la red? ¿Se pueden utilizar eficazmente la base de código existente y las pruebas automatizadas?
+ ¿Qué tan fácil o difícil es implementar o volver a implementar el servicio con el enfoque de acceso a la red seleccionado? ¿Se puede hacer esto con frecuencia? ¿Existe alguna dependencia de los recursos de expertos?
+ ¿El enfoque de acceso a la red facilita o complica el cumplimiento de los estándares de codificación y las mejores prácticas?
+ ¿Cómo afecta este enfoque a time-to-market las nuevas funciones o correcciones?

## Reducción técnica de la deuda
<a name="assessment-engineering-dev-debt-reduction"></a>

Una evaluación del impacto de un enfoque de acceso a la red en la deuda técnica debería considerar sus capacidades de escalabilidad, observabilidad y seguridad.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-debt-reduction-high-score-criteria"></a>

El enfoque agiliza de manera efectiva la administración de la infraestructura a medida que la base de clientes se expande. Ofrece sólidas capacidades de observabilidad. out-of-the-box Esto promueve una supervisión y un mantenimiento eficientes.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-debt-reduction-low-score-indicators"></a>

El enfoque de acceso a la red protege inadecuadamente los canales de comunicación y carece de herramientas suficientes para la observación métrica cualitativa. También puede requerir un desarrollo adicional para la administración de la infraestructura a medida que aumenta la base de clientes, o puede necesitar soluciones alternativas para los problemas de confiabilidad.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-debt-reduction-self-assessment-questions"></a>
+ ¿Cómo influye el enfoque de acceso a la red en la escalabilidad a largo plazo de la infraestructura? ¿Facilita un crecimiento continuo con una inversión adicional mínima?
+ ¿Qué tan completas son las herramientas de observabilidad incluidas? ¿Permiten una supervisión proactiva y la resolución de problemas?
+ ¿Cuál es el impacto previsto del enfoque de acceso a la red en el mantenimiento y la evolución del código base a lo largo del tiempo?
+ ¿El enfoque se integra bien con la infraestructura existente y planificada? ¿Requiere cambios o adiciones importantes?

## Escalabilidad, capacidad y rendimiento
<a name="assessment-engineering-dev-scalability"></a>

Para determinar la idoneidad de un enfoque de acceso a la red para una oferta de SaaS, es esencial analizar cómo mantiene un rendimiento óptimo a medida que aumenta la demanda.

### Criterios de puntuación alta
<a name="assessment-engineering-dev-scalability-high-score-criteria"></a>

El enfoque de acceso a la red facilita la expansión sin problemas. Mantiene una latencia baja durante el procesamiento de las solicitudes y gestiona de forma eficiente los picos de tráfico. Proporciona un rendimiento uniforme independientemente del aumento de los niveles de tráfico y no impone límites operativos al crecimiento.

### Indicadores de puntuación baja
<a name="assessment-engineering-dev-scalability-low-score-indicators"></a>

El enfoque de acceso a la red no se escala de manera eficaz, posiblemente debido a las limitaciones inherentes del ancho de banda o a una capacidad de infraestructura insuficiente. El aprovisionamiento y la administración de recursos aumentan la complejidad o crean dependencias. El rendimiento del servicio se deteriora debido al aumento de la latencia, la fluctuación y la variabilidad del rendimiento, especialmente en condiciones de red congestionadas.

### Preguntas de autoevaluación
<a name="assessment-engineering-dev-scalability-self-assessment-questions"></a>
+ ¿Cómo se adapta el enfoque de acceso a la red a un número cada vez mayor de inquilinos y sus volúmenes de datos?
+ ¿Es inherentemente escalable para cumplir con las demandas del futuro?
+ ¿Qué medidas existen para garantizar que el rendimiento sea uniforme, incluso durante los períodos de mayor tráfico o los eventos de escalamiento rápido?
+ ¿Cómo gestiona el enfoque la latencia y la fluctuación de la red? ¿Existen mecanismos para optimizar el rendimiento de los datos y minimizar los retrasos?
+ ¿Puede el enfoque de acceso a la red adaptarse a las diferentes condiciones de la red? ¿Puede proporcionar una experiencia de usuario único para cada cliente?
+ ¿Cuál es el impacto del enfoque de acceso a la red en la infraestructura subyacente? ¿Requiere actualizaciones o cambios significativos en los sistemas existentes?