Atributos de calidad ISO 25000
Richard RuizTutorial12 de Septiembre de 2021
945 Palabras (4 Páginas)211 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. |
Característica | Mantenibilidad |
Subcaracterística | Reusabilidad |
Escenario | El equipo de desarrollo debe diseñar la aplicación |
Fuente del evento | Equipo de desarrollo diseñando la aplicación |
Estímulo | Diseño de los componentes aplicación |
Ambiente | Sistema Blockchain |
Artefacto | Componente de la aplicación |
Respuesta | Un componente del sistema debería poder ser utilizado en otros sistemas gracias a las interfaces expuestas para su utilización. |
Medición de la respuesta | El 90% de los componentes del sistema deben ser reusables. La reusabilidad de un componente se medirá con base a la aplicación de reglas de codificación y la documentación de la funcionalidad de cada componente y de cada una de las interfaces expuestas. La documentación de las interfaces deberá detallar el flujo de datos y el tipo de éstos. |
...