Mejora de la Calidad del Software: Inspección, Validación y Gestión de Requerimientos

Inspección, Validación, Completitud, Detección de Conflictos e Inconsistencias de Requerimientos

1.1. Introducción

El proceso de requerimientos no es fácil, no es simplemente “tomar nota” de las necesidades del cliente; es un proceso de comunicación, es necesario entender qué es lo que quiere el cliente. Es un proceso de negociación, es necesario determinar qué cosas podemos comprometernos a hacer.

Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad. Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el código. ¡Grave error! La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software. El aseguramiento de la calidad del software (Software Quality Assurance, SQA) engloba:

• Un enfoque de gestión de calidad.
• Tecnología de Ingeniería de Software efectiva (métodos y herramientas).
• Revisiones técnicas formales que se aplican durante el proceso de desarrollo del software.
• Una estrategia de prueba multiescalada.
• Un control de la documentación del software y de los cambios realizados.
• Un procedimiento que asegure un ajuste a los estándares de desarrollo de software.
• Mecanismos de medición y de generación de informes.

El control de la calidad es una serie de revisiones y pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.

La garantía de calidad o aseguramiento de la calidad consiste en la auditoría y las funciones de información de la gestión. El objetivo de la garantía de la calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Es de esperar, que si los datos proporcionados mediante la garantía de la calidad identifican problemas, la gestión afronte los problemas y aplique los recursos necesarios para resolverlos.

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes: los ingenieros de software, que realizan trabajo técnico, y un grupo de calidad (SQA), que tiene la responsabilidad de la planificación de garantía de calidad.

En este marco podemos ver a las inspecciones como una implementación de las revisiones formales del software, las cuales representan un filtro para el proceso de ingeniería de software. Estas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden así ser eliminados. Freeman y Weinberg argumentan de la siguiente forma la necesidad de revisiones:

El trabajo técnico necesita ser revisado por la misma razón que los lápices necesitan gomas: errar es humano. La segunda razón por la que necesitamos revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan más fácilmente al que los origina que a otras personas. El proceso de revisión es, por lo tanto, la respuesta a la plegaria de Robert Burns:

¡Qué gran regalo sería poder vernos como nos ven los demás!

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

• Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo.
• Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.
• Conseguir un trabajo de mayor calidad maximizando los criterios de correctitud y completitud principalmente.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos. Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal técnico es una forma de revisión. Sin embargo, en esta unidad nos concentraremos en una revisión técnica formal, que llamaremos Inspección de Software.

1.2. Evolución de los Requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar. Por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones. Las más frecuentes son:

• Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.
• Porque cambió el problema que se estaba resolviendo.
• Porque los usuarios cambiaron su forma de pensar o sus percepciones.
• Porque cambió el ambiente de negocios.
• Porque cambió el mercado en el cual se desenvuelve el negocio.

Los cambios en los requisitos involucran modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones.

Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto.

Entre algunos de los beneficios que proporciona el control de versiones están:

• Prevenir cambios no autorizados.
• Guardar revisiones de los documentos de requerimientos.
• Recuperar versiones previas de los documentos.
• Administrar una estrategia de entregas (releases).
• Prevenir la modificación simultánea a los requisitos.

En vista de que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

1.3. ¿Cómo solucionar el problema?

Un proceso disciplinado que busque determinar y solucionar los diferentes problemas de los requerimientos. Un sistema de especificaciones que posibilite comunicar y negociar los requerimientos eficientemente con los usuarios.

1.4. Inspección de Requerimientos

Dentro del contexto de desarrollo de software, los términos "defecto" y "fallo" son sinónimos. Ambos implican un problema de calidad descubierto después de entregar el software a los usuarios finales.

El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno).

Una serie de estudios en varias empresas que desarrollan software (TRW, Nippon Electric y Mitre Corp.) entre otras, indican que las actividades del diseño introducen entre el 50% y 65% de todos los errores (y en último lugar, todos los defectos), durante el proceso de desarrollo del software. Sin embargo, se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores.

Con la detección y la eliminación de un gran porcentaje de errores, el proceso de inspección reduce substancialmente el costo de los pasos siguientes en las fases de desarrollo y mantenimiento.

Para ilustrar el impacto sobre el costo de la detección anticipada de errores, consideremos una serie de costos relativos que se basan en datos de costos, realmente recogidos en grandes proyectos de software. Supongamos que un error descubierto durante el diseño cuesta corregirlo 1,0 unidad monetaria. De acuerdo a este costo, el mismo error descubierto justo antes de que comience la prueba costará 6,5 unidades monetarias; durante la prueba 15 unidades; y después de la entrega, entre 60 y 100 unidades monetarias.

1.5. Validación de Requerimientos

La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

En este punto es necesario recordar que la especificación de requerimientos del sistema debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación, se presentan varios ejemplos:

• ¿Están incluidas todas las funciones requeridas por el cliente? (completa).
• ¿Existen conflictos en los requerimientos? (consistencia)
• ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
• ¿Está cada requerimiento claramente representado? (entendible).
• ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible).
• ¿Está la especificación de requerimientos del sistema escrita en un lenguaje apropiado? (clara).
• ¿Existe facilidad para hacer cambios en los requerimientos? (modificable).
• ¿Está claramente definido el origen de cada requisito? (rastreable).
• ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable).

La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado. Estas características serán estudiados más adelante en detalle, en la unidad 3, sobre métricas de los requerimientos del software.

1.6. Verificación de Requisitos

En esta fase, el usuario final añade criterios de aceptación para cada requisito. Además, apoya el hecho de que los requisitos han de ser correctos antes de que sean entregados a los diseñadores y desarrolladores.

La puerta de calidad es un punto por el que pasan cada uno de los requisitos antes de formar parte de la especificación.

Una de las tareas de las puertas de calidad es asegurarse de que cada requisito cumple con el criterio que tiene asignado. Este criterio es una medida del requisito que le hace entendible y con capacidad para ser probado.

Otra razón por la que el proyecto tiene puertas de calidad es para prevenir posibles fugas de requisitos. Los requisitos, algunas veces, aparecen en las especificaciones sin que nadie realmente sepa de dónde vienen o qué valor añaden al producto. Asegurándose de que la única forma de que los requisitos entren a formar parte de las especificaciones sea a través de las puertas de calidad, el equipo del proyecto tiene un total control de los requisitos.

1.7. Revisión de Especificación

Cuando un requisito pasa por una puerta de calidad, se puede tener confianza acerca de la corrección y viabilidad de los requisitos. ¿Pero qué ocurre con la especificación en conjunto? En este punto se sabe que los requisitos son correctos, pero ¿se puede asegurar que todos estos requisitos, en conjunto, describen la ‘historia’ completa?

El término especificación de requisitos hace referencia a la colección de requisitos especificados y definidos previamente. Una vez que la especificación de los requisitos está completa (documento de especificación de requerimientos del software – ERS), se tendrá un conocimiento preciso del alcance y funcionalidad del producto. Este es el momento de llevar a cabo la revisión de la especificación. En esta revisión final se valida que no falta ningún requisito.

Otro punto muy importante a tener en cuenta es asegurarse de que los requisitos tengan consistencia, y en caso contrario, que cualquier conflicto entre los requisitos ha sido resuelto. Dos requisitos están en conflicto si no pueden implementarse juntos, es decir, si la solución a un requisito impide la implementación de otro.

Cuando las expectativas del cliente son altas, la fecha de entrega y los recursos son limitados, es importante asegurarse de que las funciones más importantes del producto sean entregadas y además tan pronto como sea posible. Otro problema que se puede plantear es que haya demasiados requisitos.

La solución a los problemas anteriores es la priorización de los requisitos.

1.8. Factores en la Calidad del Software

La construcción de software de calidad requiere el cumplimiento de numerosas características:

• Eficiencia: La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula.
• Transportabilidad (portabilidad): La transportabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
• Verificabilidad: La verificabilidad es facilidad de verificación de un software; es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
• Integridad: La integridad es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso.
• Fácil de utilizar: Un software es fácil de utilizar si se puede comunicar con él de manera cómoda.
• Corrección: Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
• Robustez: Capacidad de los productos software de funcionar incluso en situaciones anormales.
• Extensibilidad: Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esto: diseño simple y descentralización.
• Reutilización: Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
• Compatibilidad: Facilidad de los productos para ser combinados con otros.

Gestión de Requisitos

2.1. Definición

La gestión de requisitos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Es decir, la gestión de requisitos consiste en gestionar los cambios de los requisitos, las relaciones entre ellos, las dependencias entre la especificación de requisitos y otros documentos producidos por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los requisitos y el sistema construido.

Por lo tanto, los objetivos principales del proceso de gestión de requisitos serán:

• Gestionar la recogida de requisitos.
• Obtener la aprobación de los participantes del proyecto.
• Gestionar los cambios (trazabilidad).

La gestión de requisitos es un proceso que se desarrolla a lo largo de toda la vida del producto.

2.2. Gestión de Cambios

Los requisitos cambian durante todo el ciclo de vida de desarrollo del producto como se vio en apartados anteriores. Los cambios deben controlarse y documentarse, es decir, hay que convivir con ellos y por ello la gestión de cambios es esencial para tratar dichos cambios.

En definitiva, podríamos destacar tres importantes actividades dentro del proceso de gestión de cambios:

2.2.1. Evaluar el Impacto

La primera tarea a realizar tras recibir una petición de cambio es valorar el impacto del mismo. Para ello se deberá ir recorriendo todo el árbol de requisitos viendo como les afecta el cambio, y aquí es donde entra la trazabilidad de los requisitos.

2.2.2. Aceptación del cambio

Una vez analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el cambio, tras negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.

2.2.3. Implementación del cambio

Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que resulten afectados por dicho cambio (si el cambio es mínimo algunos productos como el plan del proyecto, puede que no sea necesario modificar). Además, se deberá generar un nuevo punto de partida (línea base) de requisitos.

2.3. Trazabilidad

Un concepto clave en el proceso de gestión de cambios es la trazabilidad. Los requisitos deben ser trazables, es decir, “rastreables”. Se podría decir que un requisito es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requisito. Todos los requisitos deberían ser trazables para mantener consistencia entre los distintos documentos de un proyecto.

Es importante conocer aspectos de los requisitos tales como:

• Su origen (Quién los propuso).
• Necesidad (Por qué existe).
• Relación con otros requisitos (Dependencias).
• Relación con otros elementos (Dependencias).

El uso de matrices o algún otro método de trazabilidad es una buena técnica para llevar a cabo esta actividad de forma eficiente.

Métricas y Herramientas para la Ingeniería de Requisitos

3.1. Amplificación y Eliminación de Defectos

Se puede usar un modelo de ampliación de defectos para ilustrar la generación y detección de errores durante los pasos de diseño preliminar, diseño detallado y codificación del proceso de ingeniería del software. La inspección puede fallar en descubrir nuevos errores y errores de pasos anteriores, produciendo un mayor número de errores que pasan inadvertidos. En algunos casos, los errores que pasan inadvertidos desde pasos anteriores se amplifican (factor de ampliación x) con el trabajo actual.

En la tabla 1, se presentan los errores detectados en un proyecto específico, su costo unitario y total en cada fase del desarrollo donde fue evaluado. Se puede ver que el costo total para el desarrollo y el mantenimiento cuando se realizan inspecciones es de 783 unidades. Cuando no hay inspecciones, el costo total es de 2.177 unidades (ver tabla 2), lo que representa (2.177 / 783 = 2,8); casi 3 veces más caro.

Para llevar a cabo inspecciones, el equipo de desarrollo debe dedicar tiempo y esfuerzo, y la organización de desarrollo debe gastar dinero. Sin embargo, los resultados del ejemplo anterior no dejan duda de que hemos encontrado el síndrome de "pague ahora o, pague después mucho más". Las inspecciones producen un beneficio en costo demostrable, si se cuenta con los recursos para llevarse a cabo.

A partir de lo expuesto, podríamos resumir los beneficios comprobados al aplicar Inspecciones en:

• Reducción de los defectos en el uso del software.
• Reducción de los recursos de desarrollo, sobre todo en las etapas de codificación y prueba.
• Reducción en los costos de mantenimiento correctivo.

3.2. Métricas

3.2.1. Introducción

En la mayoría de los desarrollos de software, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorar, el producto se mide para intentar aumentar su calidad.

Al principio, podría parecer que la necesidad de la medición es algo evidente. Después de todo es lo que nos permite cuantificar y, por consiguiente, gestionar de forma más efectiva. Pero la realidad puede ser muy diferente. Frecuentemente la medición conlleva una gran controversia y discusión.

1. ¿Cuáles son las métricas apropiadas para el proceso y para el producto?
2. ¿Cómo se deben utilizar los datos que se recopilan?
3. ¿Es bueno usar medidas para comparar gente, procesos o productos?

Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo que no se ha medido en el pasado. La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos, por mencionar algunos aspectos. Desgraciadamente, la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre qué medir y cómo evaluar las medidas.

Hay varias razones para medir un producto:

1. Para indicar la calidad del producto.
2. Para evaluar la productividad de la gente que desarrolla el producto.
3. Para evaluar los beneficios en términos de productividad y de calidad, derivados del uso de nuevos métodos y herramientas de la ingeniería de software.
4. Para establecer una línea de base para la estimación.
5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas.

Medidas Directas: En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, la velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.

Medidas Indirectas: Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.

3.2.2. Tipos de Métricas del Software

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.

1. Métricas Técnicas: Se centran en las características de software, por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.
2. Métricas de Calidad: Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir, cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.
3. Métricas de Productividad: Se centran en el rendimiento del proceso de la ingeniería del software. Es decir, qué tan productivo va a ser el software que voy a diseñar.
4. Métricas Orientadas a la Persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y, sobre todo, el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que hará el sistema.
5. Métricas Orientadas al Tamaño: Es para saber en qué tiempo voy a terminar el software y cuántas personas voy a necesitar.

3.2.3. Métricas de los Requerimientos del Software

Son muchos los informes que apuntan en la línea de que el requisito debería ser el activo al que dediquemos una mayor atención durante todo el ciclo de vida de desarrollo de software; sin embargo, muchas veces no se hace así. Se obtienen innumerables métricas de nuestro software, pero casi siempre relacionadas con el código fuente o la planificación, y nunca en relación a nuestros requisitos.

Por otro lado, contar con herramientas que permiten la correcta gestión de nuestros requisitos, que indiquen si el nivel de calidad de nuestras especificaciones es correcto, así como alertar de los posibles puntos de mejora y, en definitiva, aumentar la calidad de nuestro software.

Existen algunas herramientas en el mercado, que permiten realizar esta tarea, uno de ellos es el analizador de calidad para la ingeniería de requerimientos (IRQA Quality Analyzer). Para ello, se ha efectuado un mapeo entre aquellas cualidades deseables de cualquier documento de especificación de requisitos (completa, consistente, verificable, no ambigua…) y una serie de indicadores y métricas de fácil medida mediante técnicas de procesamiento de lenguaje natural (Natural Languaje Proccesing-NLP):

• Tamaño del requisito: con la intención de evitar tanto requisitos muy breves, como aquellos muy extensos y complejos. Este tamaño puede medirse en caracteres, en palabras, en párrafos, en número de conceptos propios del dominio tratado...
• Uso de verbos en tiempo imperativo: este tiempo verbal debería predominar sobre el resto
• Uso de verbos en tiempo condicional: toda SRS debe evitar especulaciones, de ahí el hecho de evitar sentencias condicionales
• Uso de términos ambiguos: términos como "bastante", "suficiente", "seguro", "usable"… son difíciles de medir
• Uso de frases no completas: "más adelante", "en un futuro"… hacen que cada requisito no sea completo
• Presencia o ausencia de términos del dominio: evitando en la medida de lo posible términos no concernientes con el problema a modelar; pero también intentando acotar el número de conceptos tratados en un único requisito para conseguir requisitos atómicos
• Presencia o ausencia de verbos del dominio: por la misma razón que el anterior
• Legibilidad del texto: requisitos no legibles (frases demasiado extensas y palabras demasiado complicadas, frases que carecen de signos de puntuación...) complicarán el resto de actividades del proyecto
• Uso de un único verbo por requisito: lo que permite comprobar la existencia de una única necesidad en cada requisito
• Reducción del número de acrónimos y tecnicismos: lo que garantiza requisitos claros
• Inclusión de términos relativos al diseño: p.e. base de datos, objeto, campo… que no deberían aparecer en especificaciones de alto nivel
• Inclusión de términos propios de un pseudo-código: términos como SI, SINO, FIN-SI, MIENTRAS... pueden implicar que el cuerpo del requisito incluye un pseudo-código
• Uso de frases especulativas: p.e. usualmente, generalmente, típicamente…
• Localización de conceptos condicionales:p.e. quizá, probablemente…, lo que permite también la reducción de especulaciones
• Abuso de negaciones:Demasiadas negaciones en un requisito (como en cualquier otra frase) puede implicar dificultados a la hora de leer y entender el requisito
• Abuso de conectores:del mismo modo, demasiados conectores en un mismo requisito puede implicar bien la mezcla de dos o más necesidades en el mismo requisito, o bien un exceso de detalle en el mismo
• Empleo de estructuras de frase subjetivas:frases del estilo "en mi opinión", "pienso que" no deben ser aceptadas en ningún requisito
• Abuso de pronombres:está demostrado que el abuso de pronombres en un requisito puede implicar que, algún stakeholder pueda malinterpretar alguno de dichos pronombres, dándole un significado contrario al requisito
• Número de dependencias: entre cada requisito y otros activos del proyecto, lo que permitirá comprobar si cada requisito de usuario tiene asociado un requisito de sistema, pruebas…
• Volatilidad: Número de versiones generadas tras la aceptación de un requisito

Junto con todas estas métricas que permiten analizar la calidad de requisitos de forma individual (aunque existan vistas e informes de conjunto), hay otros Indicadores Semánticos que permiten analizar una especificación en su conjunto.

Ejemplo de estas métricas pueden ser las siguientes:

• Análisis semántico de solapamiento:que permite medir cuándo dos o más requisitos de una proyecto puedan solaparse, teniendo en cuenta que este solapamiento es la principal fuente de inconsistencias
• Empleo de unidades de medida inconsistentes:lo que permite la rápida detección de requisitos que, por ejemplo, mezclen kilómetros y millas en una misma especificación, hecho que puede ser frecuente en equipos procedentes de múltiples localizaciones y costumbres

A través de estas métricas puede identificarse, de forma clara, qué requisitos no tienen la calidad esperada y han de ser redefinidos.

Tomar métricas de su software es la única forma de mejorarlo y, si puede recibir métricas de todos sus activos y de forma temprana, el éxito está asegurado.