Cinco reglas de sqa (pruebas de software)
El propósito del aseguramiento de la calidad del software es hacer que el proceso del software sea visible para los gerentes. Verifica el cumplimiento del software con los estándares mediante la revisión y auditoría de productos y actividades de software. El equipo de garantía de calidad del software participa en el establecimiento de planes, estándares y procesos al comienzo del proyecto. Estos permitirán que el proyecto de software cumpla con los requisitos de las políticas institucionales.
1. Objetivos básicos
Objetivo 1: Planificar el aseguramiento de la calidad del software.
Objetivo 2: Verificar objetivamente que los productos y el trabajo del proyecto de software siguen los estándares, procesos y requisitos adecuados.
Objetivo 3: Informar a grupos e individuos relevantes sobre los esfuerzos y resultados de control de calidad del software.
Objetivo 4: La alta dirección está expuesta a problemas de no conformidad que no se pueden resolver en el proyecto.
2. El origen del control de calidad
Sabemos que muchas grandes empresas extranjeras son responsables de las pruebas de control de calidad (principalmente pruebas de sistemas), como IBM, CA y PeopleSoft. De hecho, casi todas las empresas eran así cuando empezaron. Más tarde, debido a la falta de una planificación y gestión de proyectos efectivas, no quedaba mucho tiempo para las pruebas del sistema (nota: para un proyecto en el que trabajé antes, el gerente del proyecto me dijo claramente que las pruebas del sistema eran por un día, y no había necesidad de discutirlo). Además, los requisitos cambian demasiado rápido y, sin una documentación completa, los evaluadores solo pueden realizar pruebas basándose en su propia imaginación. De esta manera, es difícil garantizar la calidad del producto mediante pruebas y surge la función preventiva de control de calidad.
De hecho, la prevención temprana se basa en la TQM y también está en línea con el principio de la ingeniería de software de que "cuanto antes se descubran los defectos, antes se podrán modificar y más económicos serán". " El origen de estas ideas se remonta a antiguas alusiones chinas, como el salario de Qu Tuxi y la teoría de las habilidades médicas de Bian Que. Especialmente la alusión a la teoría de las habilidades médicas de Bian Que la vi accidentalmente en un artículo en el extranjero (y luego también la vi en un artículo escrito por Rui Lin). A menudo lamenté que nuestro pueblo casi haya perdido la herencia ideológica y cultural de nuestro país. ancestros. .
En tercer lugar, la situación actual del aseguramiento de la calidad
Actualmente, cada vez más empresas están implementando CMM. El modelo CMM requiere el establecimiento de roles de control de calidad. El control de calidad aquí es similar a la policía de procesos. Su principal responsabilidad es verificar si las actividades de desarrollo y gestión son consistentes con las estrategias, estándares y procesos de proceso establecidos, y si los productos de trabajo siguen el contenido y el formato especificados en la plantilla. En estas empresas, generalmente se requiere que el control de calidad sea independiente del equipo del proyecto para garantizar la objetividad de la evaluación. Desde una perspectiva nacional, la mayor parte del control de calidad no tiene conocimientos técnicos y la mayoría de las desviaciones detectadas son insignificantes. Además, no tienen antecedentes convincentes y la dirección no los apoya. Por supuesto, esto es difícil de hacer.
La falta de confianza y soporte es solo un aspecto, el control de calidad en sí es un gran desafío. Requiere que el control de calidad tenga conocimientos de ingeniería de software, desarrollo de software, experiencia en la industria, estadística matemática, gestión de proyectos, gestión de calidad, etc.
A menudo nos encontramos con este tipo de problemas y es difícil superarlos después de mejorar hasta cierto punto. Empezamos a sentirnos frustrados cuando sentimos que estamos dispuestos a hacer más de lo que somos capaces de hacer. Luego, a través del aprendizaje, el entrenamiento y la comunicación, mis pensamientos y habilidades se sublimaron, encontré la pieza más corta del barril, y luego comencé a mejorar, luego encontré un techo de cristal, y luego caí en un ciclo de depresión. .
Si domináramos todo el conocimiento y pudiéramos superar todos los techos de cristal, ¿el control de calidad sería fácil? La respuesta es no, la propia definición del rol de control de calidad tiene grandes limitaciones. El control de calidad es como un policía de procesos que hace cumplir arbitrariamente el proceso independientemente de su significado, lo que fácilmente puede generar hostilidad y rechazo en el equipo del proyecto, y la actitud de este policía también destruye el espíritu de equipo. De esta manera, el control de calidad también necesita habilidades interpersonales, como el equilibrio de calidad, ¿debería el control de calidad ser independiente del equipo del proyecto? ", maneje esta relación artísticamente.
En cuarto lugar, el futuro del control de calidad
Hasta cierto punto, el mecanismo de revisión de control de calidad independiente es producto del modelo en cascada. Con la evolución de La tecnología moderna de desarrollo de software y el aumento de los modelos en espiral y los modelos iterativos están cambiando silenciosamente. Este cambio es de control de calidad independiente a tiempo completo a control de calidad a tiempo parcial. ¿Ocurre este cambio? Ya sea XP, RUP u otras metodologías avanzadas, la arquitectura se genera primero y luego se desarrolla de forma incremental hasta su finalización.
En este modelo, los requisitos y los defectos de diseño se descubren y solucionan lo antes posible en cada ciclo de iteración, la calidad se integra en la arquitectura y el proceso, y el costo y el cronograma del proyecto están garantizados.
En ese momento, ¿dejará de existir el control de calidad independiente? Algunas empresas menos maduras todavía lo necesitan, principalmente para garantizar la eficacia de la ejecución de los procesos y la objetividad de la evaluación.
Exploración teórica del verbo (abreviatura de verbo) SQA
1. Comprensión del proceso
Todos sabemos que los contenidos principales de un proyecto son: costo. , cronograma y calidad; una buena gestión de proyectos consiste en integrar los tres factores, equilibrar los tres objetivos y, en última instancia, completar la tarea de acuerdo con los objetivos. Estos tres aspectos del proyecto se restringen e influyen entre sí. A veces, la estrategia de equilibrio de estos tres aspectos incluso se convierte en un requisito a nivel empresarial y determina el comportamiento de la empresa. Sabemos que el software de IBM es el objetivo más importante, y la estrategia de "software suficientemente bueno" de Microsoft es aún más familiar. Estos objetivos de calidad en realidad se basan en las metas estratégicas de la empresa. Por lo tanto, el trabajo de garantía de calidad de SQA también debe basarse en los objetivos estratégicos de la empresa, pensar en SQA desde esta perspectiva y formar una comprensión teórica de SQA.
La industria del software ha llegado a un consenso de que los principales factores que afectan el cronograma, el costo y la calidad de los proyectos de software son "las personas, los procesos y la tecnología". En primer lugar, hay que tener claro que entre estos tres factores, las personas son lo primero.
Actualmente, muchas personas que implementan CMM están obsesionadas con la teoría de CMM y enfatizan demasiado el "proceso". Esta es una tendencia muy peligrosa. Esta tendencia ideológica ha sido duramente criticada en el extranjero. En cierto sentido, la propuesta de varios métodos de proceso ágiles es un reflejo del énfasis en el proceso. Vale la pena pensar en un punto de "XP" de que "las personas son más importantes que el proceso". Mi opinión personal es adherirme a lo "orientado a las personas" y enfatizar la armonía entre el proceso y las personas en la mejora del proceso.
Según un estudio de muchos proyectos fallidos en la ingeniería de software moderna, se descubrió que la gestión es la principal razón del fracaso del proyecto. La importancia de este hecho es que "para asegurar que el proyecto no fracase, debemos prestar más atención a la gestión". Tenga en cuenta que este hecho no explica otro problema: "Una buena gestión puede garantizar el éxito del proyecto". En la actualidad, muchas personas infieren esta conclusión a partir de un hecho basado en una lógica aproximada, que es lógicamente incorrecta. Este error forma un enfoque aún más incorrecto, que se refleja profundamente en la comprensión de SQA.
Si examinamos la evolución histórica, debería ser más fácil entender la esencia del CMM. CMM apareció por primera vez como un "estándar de evaluación" para evaluar las capacidades de control de calidad de los proveedores del Departamento de Defensa de EE. UU. La producción de software en la que se centra CMM tiene las siguientes características:
(1) Problemas de calidad.
(2) Gran escala
Este es el motivo de la CMM. Se introduce la idea de gestión de la calidad total, especialmente el método de procesos en la gestión de la calidad total, y se introduce el método de control estadístico de procesos. Se puede decir que estas dos ideas son la base de CMM.
Estos contenidos forman mi comprensión básica del estado y el valor del proceso de software. Sobre esta base, podemos discutir SQA.
2. Metáfora de la línea de producción
Si comparas un producto de software con un producto de fábrica. Entonces, la línea de producción es el proceso y los productos se producen de acuerdo con el proceso especificado de la línea de producción. La responsabilidad de SQA es asegurar la ejecución del proceso, es decir, asegurar la normal ejecución de la línea de producción.
El modelo del sistema de gestión se resume de la siguiente manera. Este modelo muestra que un sistema de procesos debe incluir al menos tres aspectos importantes: toma de decisiones, ejecución y retroalimentación.
La responsabilidad de QA es garantizar la implementación efectiva del proceso y supervisar las actividades del proyecto de acuerdo con el proceso; no es responsable de supervisar la calidad del producto, proporcionar información del proyecto a la gerencia y administrar en nombre de la gerencia; Asegurar en nombre de la dirección la implementación del proceso.
3. Combinación de SQA y otros trabajos
En muchas empresas, el trabajo de SQA se mezcla con el trabajo de QC, SEPG y gerentes de proyectos organizacionales, a veces incluso más que el de El propio SQA trabaja más centrado en otros aspectos.
Según el punto de vista de hjhza, "hay básicamente tres tipos de control de calidad en China (según diferentes prioridades): uno es la mejora de procesos, otro es la gestión de la configuración y el otro son las pruebas". Personalmente creo que esto se debe a que el trabajo de SQA se combina con otros trabajos diferentes.
La siguiente es una explicación de la relación basada en mi experiencia.
4. Aseguramiento de la calidad y control de calidad
Responsabilidades básicas de ambos
QC: Verificar la calidad del producto para garantizar que el producto satisface las necesidades del cliente; inspector ;
QA: Revisar la calidad del proceso para garantizar la correcta ejecución del proceso; conviértase en un auditor de calidad del proceso;
Preste atención a la diferencia entre inspección y auditoría.
Inspección: Es lo que solemos llamar encontrar fallas, es decir, encontrar fallas.
Auditoría: confirmar las evidencias de que el proyecto se lleva a cabo según lo requerido; los términos utilizados por cada KPA en el CMM para inspeccionar SQA, el contenido de la revisión es principalmente el proceso de mirar el contenido de la revisión del gerente del proyecto y el gerente superior contra el CMM; Se centran más en contenidos específicos.
De acuerdo con el modelo de sistema de gestión anterior, el control de calidad lleva a cabo el control de calidad y envía información sobre la calidad a la gerencia; el control de calidad garantiza que el control de calidad lleve a cabo actividades de control de calidad de acuerdo con el proceso e informa los resultados de la inspección a la gerencia de acuerdo con el proceso. Esta es la relación entre QA y QC.
Bajo este principio de división del trabajo, el control de calidad solo necesita verificar si el proyecto ha llevado a cabo una actividad de acuerdo con el proceso y ha producido un producto; el control de calidad verificará si el producto cumple con los requisitos de calidad.
Si la empresa originalmente tenía personal de control de calidad pero no tenía suficiente personal de control de calidad, se puede determinar que el control de calidad también necesita realizar control de calidad. Pero sólo puede ser temporal. Debería haber personal de control de calidad independiente, porque el trabajo de control de calidad también debe seguir los requisitos del proceso y ser auditado. Esta situación mixta dificulta garantizar la calidad del proceso del trabajo de control de calidad.
5. Aseguramiento de la calidad y SEPG
Responsabilidades básicas de ambos
SEPG: establecer procesos e implementar mejoras en los procesos;
QA: Hacer asegurarse de que el proceso se ejecute correctamente.
SEPG debe proporcionar orientación sobre el proceso, ayudar al equipo del proyecto a formular el proceso del proyecto y ayudar al equipo del proyecto a hacer planes, ayudando así al equipo del proyecto a trabajar de manera efectiva y ejecutar el proceso. En caso de disputa sobre el entendimiento del proceso entre el proyecto y QA, SEPG actuará como árbitro final. Para realizar mejoras efectivas en los procesos, la SEPG debe analizar los datos del proyecto.
El control de calidad también necesita estandarizar el proceso, para que el control de calidad más experimentado y capaz pueda participar en SEPG, pero preste atención a la diferencia entre los dos.
Si los empleados de SEPG de la empresa tienen una profunda experiencia en desarrollo, pueden realizar SQA, lo que favorece la mejora continua del proceso; sin embargo, debido a la integración de la legislación y la aplicación de la ley, es fácil para SQA; ser demasiado fuerte y afectar la independencia del proyecto.
Para las empresas con procesos de gestión maduros, debido a la mejora de la cultura corporativa y los mecanismos de gestión, hay menos trabajo dentro del alcance de las responsabilidades de SQA y, a menudo, solo desarrollan planes de SQA con prioridades claras para proyectos específicos. De esta manera, SQA El trabajo de auditoría se reducirá considerablemente, permitiendo auditar más proyectos al mismo tiempo.
Por otro lado, debido a la detallada división del trabajo y la complejidad del sistema de gestión, a menudo se requiere personal de la SEPG a tiempo completo. Se requiere que estas personas comprendan todos los procesos de gestión y operaciones de la empresa y desarrollen un plan general para la mejora de procesos basado en esto. En este momento, el personal de SQA que comprende la situación general es el principal candidato para el SEPG a tiempo completo; este personal de SQA se convertirá gradualmente en personal de SEPG y tendrá una mejor comprensión del conocimiento de gestión, y el trabajo de SQA se convertirá gradualmente en su trabajo a tiempo parcial.
Esta situación es común en muchas empresas de CMM5. A veces, el personal de SQA no se ve o rara vez se ve en el equipo del proyecto. Esta integración de SEPG y SQA es particularmente beneficiosa para la mejora de los procesos organizacionales. SEPG determina el contenido de las mejoras de procesos y el plan SQA se centra en estas mejoras, lo que es particularmente útil para cumplir con los requisitos de CMM5 para garantizar mejoras efectivas. Desde esta perspectiva, no es difícil entender por qué el salario del personal extranjero de SQA es alto, lo que también determina la razón por la cual el personal nacional de SQA es relativamente despreciado en la actualidad porque el proceso de gestión es imperfecto y nuestro personal de SQA no genera tanto; ¡valor!
6. Aseguramiento de la calidad y supervisión y gestión a nivel organizacional
Para poder supervisar y gestionar mejor los proyectos, algunas empresas han establecido un rol, al que yo llamo "nivel de organización". gerente de supervisión”. Su responsabilidad es realizar un seguimiento, supervisar y gestionar todos los proyectos de forma unificada para garantizar la visibilidad de la gestión y la capacidad de gestión de todos los proyectos.
Para gestionar proyectos de forma eficaz, los "gerentes organizacionales" deben analizar los datos del proyecto.
Su función es realizar la función de "retroalimentación" respecto al modelo anterior.
El control de calidad en sí no proporciona retroalimentación, como mucho proporciona retroalimentación sobre la información de ejecución del proceso.
Es mejor no mezclar las responsabilidades de SQA con las responsabilidades de "gerente de proyectos organizacionales", de lo contrario es fácil tener un dilema de SAQ: por un lado, SQA no puede posicionar con precisión su propio trabajo, por otro lado, la ejecución de procesos. La gente desconfía del personal de SQA.
Si se establece un buen proceso de gestión, se mejorará la visibilidad del proyecto, asegurando que la empresa pueda gestionar mejor todos los proyectos y asegurando la calidad para asegurar el funcionamiento de este proceso de gestión;
Verbo (abreviatura de verbo) Contenido y métodos de trabajo de SQA
1 Plan
Desarrollar un plan de SQA para un proyecto específico para garantizar que el equipo del proyecto lo ejecute. el proceso correctamente. Se deben tener en cuenta los siguientes puntos al formular el plan SQA:
Enfoque: determine el enfoque de la auditoría en función de los objetivos corporativos y las condiciones del proyecto.
Borrar el contenido de la auditoría: Aclare las actividades y productos de la auditoría.
Aclarar el enfoque de la auditoría: Determinar cómo se realizará la auditoría.
Reglas claras para informar los resultados de la auditoría: ¿A quién se deben informar los resultados de la auditoría?
2. Auditoría/confirmación
Realizar una auditoría SQA de acuerdo con el plan SQA y emitir un informe de resultados de la auditoría según sea necesario.
Tenga en cuenta que la revisión debe ir acompañada de miembros del equipo del proyecto, y no se permiten sorpresas. Ambas partes deben ser abiertas y honestas.
Contenido de la auditoría: si las actividades correspondientes se llevan a cabo de acuerdo con los requisitos del proceso y si los productos correspondientes se producen de acuerdo con los requisitos del proceso.
3. Seguimiento de problemas
Requerir que el equipo del proyecto mejore los problemas descubiertos durante la auditoría y realizar un seguimiento hasta que se resuelvan.
Sexto, la calidad de SQA
Centrado en el proceso: considere los problemas desde una perspectiva de proceso. Mientras el proceso esté garantizado, QA cumplirá con su deber.
Espíritu de servicio: servir al equipo del proyecto y ayudar al equipo del proyecto a garantizar la correcta ejecución del proceso.
Comprender el proceso: Tener un conocimiento profundo de la ingeniería de la empresa y tener ciertos conocimientos teóricos sobre la gestión de procesos.
Comprender el desarrollo: Comprender la situación básica del trabajo de desarrollo y ser capaz de comprender las actividades del proyecto.
Habilidades de comunicación: Bueno en comunicación, capaz de crear un buen ambiente y evitar que las actividades de auditoría se conviertan en una actividad de búsqueda de fallas.
Siete. Actividades de SQA
El aseguramiento de la calidad del software (SQA) es una actividad que se aplica a todo el proceso del software, que incluye:
1. Un método de gestión de la calidad
2. Técnicas de ingeniería de software (métodos y herramientas)
3. Utilizar revisiones técnicas formales durante todo el proceso del software.
4. Estrategia de pruebas multinivel
5. Control de archivos y modificaciones de software
6. Asegurar que el software cumpla con los estándares de desarrollo de software.
7. Mecanismo de medición y presentación de informes
SQA está relacionado con dos participantes diferentes: los ingenieros de software que realizan el trabajo técnico y los que son responsables de planificar, supervisar, registrar, analizar e informar. el equipo SQA.
Los ingenieros de software consideran los problemas de calidad mediante el uso de métodos y medidas técnicas confiables, realizando revisiones técnicas formales y pruebas de software bien planificadas, y completando actividades de control y garantía de calidad del software.
La responsabilidad del equipo SQA es ayudar al equipo de ingeniería de software a obtener productos finales de alta calidad. El equipo de SQA completó:
(1) Preparar el plan de SQA para el proyecto. El plan estará finalizado cuando todas las partes interesadas desarrollen y revisen el plan del proyecto.
Auditorías y revisiones requeridas;
Estándares que el proyecto puede adoptar;
Procedimientos de seguimiento y notificación de errores;
Documentos elaborados por el equipo de SQA;
La cantidad de comentarios proporcionados al equipo del proyecto de software.
(2) Descripción del proceso de software involucrado en el proyecto de desarrollo. Revise las descripciones de los procesos para garantizar que el proceso sea coherente con las políticas organizacionales, los estándares internos de software, los estándares externos y otras partes del plan del proyecto.
(3) Revisar diversas actividades de ingeniería de software para verificar si se ajustan al proceso de software definido. Documentar y realizar un seguimiento de las desviaciones del proceso.
(4) Revisar los productos de trabajo de software designados para verificar si cumplen con los requisitos predefinidos. Revisar el producto para identificar, registrar y rastrear desviaciones; verificar que hayan sido corregidas; informar periódicamente los resultados del trabajo al director del proyecto.
(5) Garantizar que las desviaciones en el trabajo y los productos de software se hayan registrado y manejado de acuerdo con procedimientos predeterminados.
(6) Registrar todas las no conformidades e informar a la alta dirección.
Ocho. Revisión técnica formal (FTR)
La revisión técnica formal es una actividad de control de calidad del software realizada por ingenieros de software y otros.
1. Objetivos:
(1) Descubrir errores funcionales, lógicos o de implementación.
(2) Verificar que el software que se está revisando realmente cumpla con los requisitos.
(3) Asegúrese de que la representación del software se ajuste a los estándares predefinidos.
(4) Desarrollar software de manera consistente.
(5) Hacer que el proyecto sea más fácil de gestionar.
2. Reunión del jurado
3-5 participantes, no más de 2 horas, con la asistencia del presidente del jurado, jueces y productores, se debe tomar una de las siguientes decisiones:
p>
(1) Si el producto de trabajo puede aceptarse sin modificaciones;
(2) Rechazar el producto de trabajo debido a errores graves;
(3) El producto de trabajo aceptación provisional.
3. Revisa el informe resumido y responde
¿Qué juzgar? ¿Quién va a juzgar? ¿Cuál es la conclusión?
El informe resumido de revisión es parte del historial del proyecto e identifica áreas problemáticas en el producto y sirve como lista de verificación para gestionar el proyecto, guiando a los productores a realizar correcciones.
4. Pautas de revisión
(1) Revisar los productos, no los productores. Tenga cuidado de señalar los errores cortésmente y aligerar el ambiente.
(2) No te salgas del tema y limita tus argumentos. En lugar de discutir sobre desacuerdos, documentelos.
(3) Expresa tus opiniones sobre todos los temas. La resolución del problema debe ocurrir después de la reunión de revisión.
(4) Crear una lista para cada producto de trabajo a revisar. Se deben establecer listas de verificación para el análisis, diseño, codificación y documentación de prueba.
(5) Asignar recursos y tiempo. Las revisiones deben programarse como tareas de ingeniería de software.
(6) Revisar la reseña anterior.
9. Garantía de calidad del software estadístico
1. Clasificar y contar todos los errores.
El protocolo IES está incompleto o tiene especificaciones incorrectas.
MCC no comprende la intención del usuario.
IDS se desvía deliberadamente de la especificación
VPS viola los estándares de programación.
Error en la representación de datos EDR.
Las interfaces de los componentes ICI son inconsistentes.
Hay un problema con la lógica de diseño de EDL
La prueba IET está incompleta o es incorrecta.
Documentos con IID inexacto o incompleto
Errores de traducción de lenguajes de programación en el diseño PLT
Interfaz hombre-máquina poco clara o inconsistente
Errores varios de MIS
Estadísticas sobre el porcentaje de varios errores según la gravedad, los niveles promedio y menores, así como el número y porcentaje de todos los errores. Por ejemplo, cree una tabla similar a la siguiente.
Luego considere los "pocos indicadores de error importantes" y haga sugerencias para mejorarlos.
2. Calcular el índice de error en función de cada paso del proceso del software.
Ei = Número total de errores encontrados por primera vez.
Si = Número de errores graves
Mi = Número de errores promedio
Ti = Número de errores menores
PS = Primer Paso escala del producto (LOC, declaración de diseño, número de páginas del documento)
Ws, Wm y Wt son factores de ponderación para errores graves, normales y menores, respectivamente. Los valores recomendados son Ws=10, Wm. =3 y Peso =1.
En cada paso del proceso, Ingeniería del Software calcula el índice de etapa para cada etapa.
PIi = Ws(Si/Ei)+Wm(Mi/Ei)+Wt(Ti/Ei)
Índice de error
Ei= ∑(i ×PIi)/ PS
=(pi 1+2pi 2+3pi 3+…+I * PIi)/PS
Combinado con la información recopilada en la tabla anterior, puede utilice el índice de error para obtener Obtenga el índice de mejora general de la calidad del software. Siete. Control de calidad e inspección
Para garantizar la calidad de cada proceso de desarrollo y evitar que los errores de software se propaguen al siguiente proceso, el propósito de la inspección es doble:
1. Gestionar las etapas de desarrollo, verificando el aseguramiento de la calidad en cada etapa del desarrollo.
2. Evitar de antemano que los errores de software causen pérdidas a los usuarios.
Los tipos de inspecciones son:
1. Inspección de suministros: Inspección de componentes, especificaciones, productos semiacabados o productos que constituyan productos de software adquiridos o transferidos previa encomienda a otras unidades. el trabajo de desarrollo.
2. Inspección intermedia/revisión de etapa
El propósito es determinar si se puede pasar a la siguiente etapa para el desarrollo posterior y evitar propagar errores al trabajo posterior.
3. Inspección de aceptación:
Confirmar si el producto cumple con los requisitos de calidad de la inspección del producto.
4. Pruebas de productos:
Determinar si los productos de software proporcionados a los usuarios alcanzan un nivel satisfactorio.
Puedes echarle un vistazo a estos. ...