lOMoAR cPSD| 7362199

AA1B. DOCUMENTO. CARACTERÍSTICAS DE LOS MODELOS DE CALIDAD DE SOFTWARE

APRENDIZ:
JEAN CARLOS ACOSTA PALACIO

DOCENTE:
JUAN JOSE BOTELLO CASTELLANOS

CARTAGENA – BOLIVAR

2022
 lOMoAR cPSD| 7362199

Taller: Características de los modelos de calidad de software.

La empresa “Softemma

”, especializada en desarrollo de software, ha sido requerida por unaclínica de salud,

para responder al siguiente requerimiento:

“Se desea desarrollar un sistema de información modular en ambiente web, que

registre elingreso u hospitalización del paciente a la clínica, la información del paciente, de
la habitación y cama ocupada, los materiales y medicamentos utilizados. Calcular el costo
dehospitalización en el momento de dar de alta al paciente.

Además, el proyecto debe permitir consultar las camas y habitaciones disponibles,

las camas y habitaciones ocupadas, y la caracterización del paciente que ocupa cada
cama.Por ello, la empresa solicita su asesoría en este campo dado su amplio
conocimiento”.

Para dar respuesta a este requerimiento, realizar los siguientes cinco puntos que
hacenparte del plan de SQA:

1. Gestión: Se debe especificar la organización

R/ La organización es una empresa de desarrollo de software que cuenta con 30
personas, cuya misión es construir software de alta calidad que ayude a las
organizaciones a ejecutary mejorar los procesos que hacen parte de su objeto social.

2. Actividades del SQA: Las evaluaciones a realizar.

R/ Ciclo de vida del software cubierto por el Plan:

Como empresa nos aseguraremos que durante el ciclo de vida de este proyecto, la Calidad
de Software (SQA) sea un proceso permanente y continuo que se desarrolla a través de las
siguientes fases:
 lOMoAR cPSD| 7362199

- Revisar cada producto:

En esta actividad se revisan los productos que se definieron como claves
para verificar en elPlan de calidad, tales como:

- Los formularios de registro de ingreso de los pacientes al hospital, se requiere que

toda la información ingresada sea validada y actualizada por operarios encargados.
Además de la hospitalización de dicho paciente.

- La remisión de los diferentes procedimientos requeridos al paciente sea autorizada

por personal calificado u área encargada, por medio de la interfaz que ofrece el
sistema.

- Revisar si el costo asociado a cada procedimiento corresponde a los valores

verdaderos establecidos por la ley, con el fin de poder realizar la consolidación de la
factura total.

- La opción de consulta que permite visualizar las camas y habitaciones disponibles

debe reflejar el estado a tiempo real.

- verificar las redes de información en las instalaciones del hospital si cumple con los
modelos de estándares de calidad.

- Revisar el ajuste al proceso:

Teniendo el cuenta que el Hospital requiere un sistema de información modular en
ambiente web, Se debe tener en cuenta la revisión de las diferentes interfaces utilizadas en
dicha weby que correspondan a lo establecida en cada uno de los procedimientos del caso
de uso definido por el hospital y al final del desarrollo, coincidan los valores realizados tanto
offline como en el sistema.

- Realizar Revisión Técnica Formal (RTF):

Aquí debemos entablar una reunión donde la participación de el responsable de SQA,

integrantes del equipo y involucrados en el desarrollo puedan realizan las diferentes
pruebas, tanto unitarias funcionales y de integración continua con el fin de asegurar que los
módulos desarrollados corresponden a las requisitos y especificaciones definidas con el
hospital.

- Asegurar que las desviaciones son documentadas:

Se debe chequear que los responsables de cada plan los modifiquen cada vez
que seanecesario, basados en las desviaciones encontradas.

Actividad Fecha

Las revisiones Periodicas

El análisis causal Periodicas

 lOMoAR cPSD| 7362199

El mantener una base de datos de los errores Periodicas

encontrados.

3. Los estándares a aplicar.

R/ Norma ISO/IEC 25000:
La norma ISO 25000 ha sido desarrollada por el subcomité SC 7 (Ingeniería de software y
sistemas) del Comité Técnico Conjunto ISO/IEC JTC 1 El objetivo general de la creación del
estándar ISO/IEC 25000 SQuaRE (Software Product Quality Requeriments and Evaluation)
es organizar, enriquecer y unificar las series que cubren dos procesos principales:
especificación de requerimientos de calidad del software y evaluación de la calidad del
software, soportada por el proceso de medición de calidad del software.

Las características de calidad y sus mediciones asociadas pueden ser útiles no solamente
para evaluar el producto software sino también para definir los requerimientos de calidad.La
serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126
(Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

Existen algunas métricas de calidad de software imprescindibles, como las que

tienen que ver con los cinco siguientes criterios:

- Métricas de exactitud:
intentan aportar información sobre la validez y precisión del software y su
estructura, incluyendo la etapa de despliegue, pero también la de pruebas y la función de
mantenimiento.

- Métricas de rendimiento:
a través de ellas se consigue medir el desempeño del software, tanto de
cada uno de sus módulos, como del sistema al completo.

- Métricas de usabilidad:
hay que descartar la complejidad y buscar una solución intuitiva y user- friendly. este tipo
de métricas de calidad de software ayudan a determinar si la solución cumple con dichos
requisitos.

- Métricas de configuración:
Las limitaciones, el estilo de código y todos los datos relativos al desarrollo y cualidades del
producto se verán evaluados en base a estas métricas.

- Métricas de eficiencia:
minimización de latencias, velocidad de respuesta, capacidad, es un enfoque similar al de la
productividad, pero con un matiz un poco distinto, que añadido a aquél, aporta una visión
mucho más completa de la solución.
 lOMoAR cPSD| 7362199

4. Responsables

R/ Los responsables de llevar a cabo los controles de calidad serán:

● Responsable de SQA
● Asistente de SQA
Además, se estará en contacto permanente con los responsables de las otras áreas
involucradas.
Ellos son:

Rol Actividad

Administrador Plan de Proyecto

Administrador Gestión de Riesgos

Administrador Plan de Iteración

Analista Modelos de Casos de Uso

Analista Alcance del Sistema

Analista Alcance del Sistema

Analista Pautas para la interfaz de Usuario

Analista Modelo de Dominio

Arquitecto Descripción de la Arquitectura

Responsable de Verificación y Validación Informe de Verificación Unitaria

Responsable de Verificación y Validación Plan de Verificación y Validación

Responsable de SCM Plan de Configuración de SCM

5. Revisiones y auditorías

R/

-
 lOMoAR cPSD| 7362199

- Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los requerimientos especificados
por el Cliente.

- Revisión de diseño preliminar

Esta revisión se realiza para asegurar la consistencia y suficiencia técnica del diseño
preliminar del software.

- Revisión de diseño crítico

Esta revisión se realiza para asegurar la consistencia del diseño detallado con la
especificación de requerimientos.

- Revisión del Plan de Verificación & Validación

Esta revisión se realiza para asegurar la consistencia y completitud de los métodos
especificados en el Plan de V & V.

- Auditoría funcional
Esta auditoría se realiza previa a la liberación del software, para verificar que todos los
requerimientos especificados en el documento de requerimientos fueron cumplidos.

- Auditoría física
Esta revisión se realiza para verificar que el software y la documentación son consistentes y
están aptos para la liberación.

- Auditorías internas al proceso

Estas auditorías son para verificar la consistencia: del código versus el documento de
diseño, especificaciones de interfase, implementaciones de diseño versus requerimientos
funcionales, requerimientos funcionales versus descripciones de testeo.

- Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las
actividades identificadas en este Plan. Deben realizarse por una persona ajena al grupo de
trabajo (en caso de que sea posible).

- Revisión del Plan de gestión de configuración

Esta revisión se realiza para asegurar la consistencia y completitud de los métodos
especificados en el Plan de gestión de configuración.

Bibliografía:

- https://iso25000.com/index.php/normas-iso-25000

- https://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/dvd02/experiencia2009/mate
rial/grupo5/sqa/inicial/iter1/SQAPLAG5v1.1.pdf