CALIDAD EN EL DESARROLLO DEL SOFTWARE

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

Wilmer Hernández Ávila

Servicio nacional de aprendizaje

Formación virtual
CALIDAD EN EL DESARROLLO DE SOFTWARE (1991472)
 Taller. Características de los modelos de calidad de software

La empresa “Soft Sena”, especializada en desarrollo de software, ha sido requerida por una
clínica de salud, para responder al siguiente requerimiento: “Se desea desarrollar un
sistema de información modular en ambiente web, que registre el ingreso 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 de hospitalizació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 hacen
parte del plan de SQA:

1. Actividades del SQA: Las evaluaciones a realizar.

● Revisar cada producto: En esta actividad se revisan los productos que se

propusieron y definieron como claves para verificar en el plan 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, la remisión de a los diferentes
procedimientos requeridos al paciente sea autorizada, por medio de la interfaz que
ofrece el sistema. Revisar si el costo asociado a cada procedimiento corresponde a
los verdaderos, 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 real.

● Revisar el ajuste al proceso: Revisión de que las diferentes interfaces

correspondan a lo establecida en cada uno de los procedimientos del caso de uso
definido por el hospital y que al final del ejercicio, coincidan los valores realizados
tanto offline como en el sistema

● Realizar Revisión Técnica Formal (RTF):se 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.
2. Los estándares a aplicar.
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 Requirements 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.

De esta forma, evaluando el software a través de diferentes ópticas y en base a continuas

mediciones, se puede ganar en alineación con el objetivo de calidad que, poco a poco, se
irán sofisticando y para lograr alcanzar cotas superiores.

3. Los productos a realizar: Se debe especificar la organización

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 ejecutar
y mejorar los procesos que hacen parte de su objeto social.
4. Procesos a seguir: revisiones y auditorías

● 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 la interfaz, 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.
5. Procedimientos para los responsables
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 DEL RESPONSABLE

Administrador Plan de Proyecto

Administrador Plan de Iteración

Administrador Gestión de Riesgos

Analista Alcance del Sistema

Analista Modelos de Casos de Uso

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

Responsable de SCM Informe de la Línea Base del Proyecto