Actividad Semana 2

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 3

SERGIO DAVID BOTERO MULCUE

ACTIVIDAD SEMANA 2.

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

La empresa “SoftSena”, 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 un plan de SQA, donde se reflejen:

1. Las evaluaciones a realizar.

 Revisión de cada producto presente:


Es importante definir las 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, 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.

 Revisión del ajuste al proceso:


Se debe validar 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.

 Revisión Técnica Formal (RTF):


En este punto 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:


Para este caso se trabajará con la norma ISO 25000 que 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:

o Métricas de exactitud: aportan 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.
o Métricas de rendimiento: se consigue medir el desempeño del software,
tanto de cada uno de sus módulos, como del sistema al completo.
o 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.
o 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.
o 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 añadiendo una visión mucho más completa de la solución.

3. Los productos a realizar.

Se realizará un registro distinto acorde a las diferentes funciones que solicita la clínica,
como lo son:
● Ingreso u hospitalización del paciente a la clínica.
● Información del paciente.
● Información de la habitación y cama ocupada.
● Materiales utilizados.
● Medicamentos utilizados.

4. Los procedimientos a seguir en el desarrollo del sistema de información para la


clínica.

 Prácticas de Aseguramiento de la calidad: Adecuadas herramientas de desarrollo,


técnicas, métodos y estándares, definidos y disponibles para realizar las revisiones.
Software para la evaluación del plan de proyecto.
 Evaluación de requerimientos: Se revisa si los requerimientos son realmente
compatibles, si se están llevando a cabo en el sistema y se busca añadir más
requerimientos, con el fin de complementarlo lo mejor posible.
 Evaluación del diseño: Se verifica que este sea acorde al contexto clínico, además
de que cumpla con los requerimientos.
 Evaluación de la codificación: Verificar que el sistema cumpla correctamente con el
procedimiento de redireccionamiento a diferentes funciones establecidas.
 Evaluación de los procesos de integración y pruebas: Controlar que se esté
cumpliendo con el Plan de Testing.

5. Los procedimientos para informar a sus responsables de los defectos detectados


y para realizar el seguimiento de los mismos hasta su corrección.

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 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

También podría gustarte

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy