Atributos de calidad ISO 25000
Enviado por Richard Ruiz • 12 de Septiembre de 2021 • Tutoriales • 945 Palabras (4 Páginas) • 170 Visitas
Atributos de calidad ISO 25000
Adecuación Funcional (Equipo Blockchain)
Característica | Adecuación Funcional |
Subcaracterística | |
Escenario | |
Fuente del evento | Entidad que genera el evento (externa o interna) |
Estímulo | Condición a considerar |
Ambiente | Estado del sistema al momento que ocurre el evento |
Artefacto | Elemento de software afectado |
Respuesta | Actividad que se lleva a cabo como respuesta al estimulo |
Medición de la respuesta | Cuando la respuesta ocurra debe ser medible de manera que el requisito pueda ser probado |
Compatibilidad (Equipo Blockchain)
Característica | Compatibilidad |
Subcaracterística | |
Escenario | |
Fuente del evento | Entidad que genera el evento (externa o interna) |
Estímulo | Condición a considerar |
Ambiente | Estado del sistema al momento que ocurre el evento |
Artefacto | Elemento de software afectado |
Respuesta | Actividad que se lleva a cabo como respuesta al estimulo |
Medición de la respuesta | Cuando la respuesta ocurra debe ser medible de manera que el requisito pueda ser probado |
Fiabilidad (Equipo Base de datos)
Escenario 1. (Para este tengo duda porque para validar esta disponibilidad toca hacer diferentes escenarios como fallas en los servicios de aplicación, base de datos, etc).
Característica | Fiabilidad |
Subcaracterística | Disponibilidad |
Escenario | |
Fuente del evento | El sistema deberá facilitar una alta disponibilidad, el portal tendrá una disponibilidad el 99% del tiempo. |
Estímulo | Interacción de los usuarios. |
Ambiente | Sistema BlockChain |
Artefacto | Sistema (En general) |
Respuesta | Visualización e interacción con el portal permanente. |
Medición de la respuesta | Tratar de denegar el servicio del sistema el menor tiempo posible. (Tiempo disponible/Tiempo total requerido) *100. |
Escenario 2.
Característica | Fiabilidad |
Subcaracterística | Tolerancia a fallos |
Escenario | El servicio sigue prestándose a pesar de la caída de un nodo dónde estén desplegados los servicios. |
Fuente del evento | Interacción de los usuarios. |
Estímulo | Caída de cualquier contenedor u otro componente del servicio. |
Ambiente | Sistema BlockChain |
Artefacto | Sistema (En general) |
Respuesta | Servicio disponible y sin impacto en su performance. |
Medición de la respuesta | Sistema respondiendo correctamente en el tiempo estimado. |
Escenario 3.
Característica | Fiabilidad |
Subcaracterística | Capacidad de recuperación |
Escenario | El sistema podrá recuperar la información que tenía una hora antes, y podrá recuperarla una hora (RTO=RPO=1 hora). |
Fuente del evento | Interacción con la base de datos desde alguno de los servicios. |
Estímulo | Intentos de acceso a la información. |
Ambiente | Sistema BlockChain |
Artefacto | Sistema (En general) |
Respuesta | El sistema se recuperará en la siguiente hora. |
Medición de la respuesta | Tiempo de recuperación = 1 hora Data perdida <= 1 hora |
Desempeño (Equipo Backend)
Mantenibilidad (Equipo Frontend)
Característica | Mantenibilidad |
Subcaracterística | Modularidad |
Escenario | El Equipo de desarrollo debe modificar la aplicación y el impacto en el sistema debe ser menor al 20%. |
Fuente del evento | Equipo de desarrollo modificando la aplicación |
Estímulo | Ajustes en el código de la aplicación |
Ambiente | Sistema Blockchain |
Artefacto | Microservicio de la aplicación |
Respuesta | Al hacer el análisis de impacto del cambio a realizarse, el impacto sobre los otros microservicios del sistema debería nulo ser nulo y a lo sumo del 20% sobre la funcionalidad general del sistema. |
Medición de la respuesta | Alterar el funcionamiento del microservicio y verificar que, los otros microservicios no hayan sido impactados y que el 80% de las características del sistema sigan funcionando correctamente. |
...