Decanato de Ingeniería e Informática  

Escuela de Informática

 
Materia  
  GESTION DE CALIDAD DE SOFTWARE

Tema
Actividad Evaluativa #3

Alumna
Diomaris Durán García   2018-1848

 
 
  Período académico 
   Enero – Abril 2021 

Clase    
ISO800-41083-001

Profesor  
Luis Gabriel Nuñez Acosta
 
 

 Santo Domingo D.N., Rep. Dom. 

Fecha: 31 de Enero del 2021
Calidad de software
“La calidad del software es el grado con el que un sistema, componente o proceso cumple
los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.
(IEEE, Std. 610-1990).
La calidad de un software se evalúa de acuerdo con el número de defectos por cada mil líneas de
código. Se evalúan factores como la corrección, la fiabilidad, la eficiencia, la integridad, la
facilidad de uso, la facilidad de mantenimiento, la flexibilidad, la facilidad de prueba, la
portabilidad, la reusabilidad y la interoperabilidad.
Algunos principios de calidad que contribuyen a la calidad, pero no la aseguran son los
principios tecnológicos, los administrativos y los ergonómicos.

Standard de Calidad ISO/IEC 9126 (Características de calidad para productos de

software).

El estándar ISO-9126 establece que cualquier componente de la calidad del software puede ser
descrito en términos de una o más de seis características básicas, las cuales son: funcionalidad,
confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las cuales se
detalla a través de un conjunto de sub características que permiten profundizar en la evaluación
de la calidad de productos de software.

Es importante mencionar, que dependiendo de los distintos tipos de aplicaciones las métricas
podrán variar, ya que aunque las características expuestas son comunes a la totalidad de los
productos, cada software particular requiere una evaluación específica.

Norma ISO/IEC 25000:2014

ISO/IEC 25000 conocida como SQuaRE (Software Product Quality Requirements and
Evaluation). Su objetivo es la creación de un marco de trabajo común para evaluar la calidad del
producto software, sustituyendo a las anteriores ISO/IEC 9126 e ISO/IEC 14598 y
convirtiéndose, de esta manera, en la piedra angular de esta área de la Ingeniería del Software.
Entre los motivos más destacados por los que una organización puede interesarse en evaluar su
producto según la ISO/IEC 25000 se pueden incluir:

• Diferenciarse de los competidores, asegurando tiempos de entrega y reducción de fallos

en el producto tras su implantación en producción.
• Establecer acuerdos en el ámbito del servicio, definiéndose determinados parámetros de
calidad que el producto debe cumplir antes de ser entregado.
• Detectar los defectos en el producto software y proceder a su eliminación antes de la
entrega, lo que supone un ahorro de costes en la fase de mantenimiento posterior.
• Evaluar y controlar el rendimiento del producto software desarrollado, asegurando que
podrá generar los resultados teniendo en cuenta las restricciones de tiempo y recursos
establecidas.
• Asegurar que el producto software desarrollado respeta los niveles necesarios para las
características de seguridad (confidencialidad, integridad, autenticidad, no-repudio, etc.).
• Comprobar que el producto desarrollado podrá ser puesto en producción sin poner en
compromiso el resto de los sistemas y manteniendo la compatibilidad con las interfaces
necesarias.

Las normas que forman este apartado definen todos los modelos, términos y definiciones
comunes referenciados por todas las otras normas de la familia 25000. Actualmente esta división
se encuentra formada por:
  ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de SQuaRE, la
terminología de la familia, un resumen de las partes, los usuarios previstos y las partes
asociadas, así como los modelos de referencia.
 ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones
para gestionar la evaluación y especificación de los requisitos del producto software.

Padre de la Calidad del Software

Jakob Nielsen. Es una de las personas más respetadas en el ámbito mundial sobre usabilidad en
la web.

Nacido el 5 de octubre de 1957, en Copenhague, Dinamarca. Es una de las personas más

respetadas en el ámbito mundial sobre usabilidad en la web. Este ingeniero de interfaces obtuvo
su doctorado en diseño de interfaces de usuario y ciencias de la computación en la Universidad
Técnica de Dinamarca. Su andadura profesional le ha hecho pasar por empresas como Bellcore,
IBM y Sun Microsystems. Actualmente figura como co-fundador de Nielsen Norman Group con
Donald Norman, otro experto en usabilidad.

Su trayectoria se inició en 1997 cuando escribió dos breves artículos sobre cómo preparar los
textos. Los títulos de estos artículos fueron "¡Sea breve! (escribir para la web)" y "Cómo leen los
usuarios en la web". Las ideas de los artículos de Nielsen se citan en muchos otros artículos que
ofrecen pautas sobre cómo escribir para la web y mejorar su usabilidad.

Principios de Calidad según Jakob Nielsen

1. Visibilidad del estado del sistema: el sistema siempre debe mantener informados a los
usuarios sobre lo que está sucediendo, a través de comentarios apropiados dentro de un
tiempo razonable.
2. Relación entre el sistema y el mundo real: el sistema debe hablar el idioma de los
usuarios, con palabras, frases y conceptos familiares para el usuario, en lugar de términos
orientados al sistema. Siga las convenciones del mundo real, haciendo que la información
aparezca en un orden natural y lógico.
3. Libertad y control por parte del usuario: hay ocasiones en que los usuarios elegirán las
funciones del sistema por error y necesitarán una “salida de emergencia” claramente
marcada para dejar el estado no deseado al que accedieron, sin tener que pasar por una
serie de pasos. Se deben apoyar las funciones de deshacer y rehacer.
4. Consistencia y estándares: los usuarios no deberían cuestionarse si acciones, situaciones
o palabras diferentes significan en realidad la misma cosa; siga las convenciones
establecidas.
5. Prevención de errores: mucho mejor que un buen diseño de mensajes de error es
realizar un diseño cuidadoso que prevenga la ocurrencia de problemas.
6. Reconocimiento antes que recuerdo: se deben hacer visibles los objetos, acciones y
opciones, El usuario no tendría que recordar la información que se le da en una parte del
proceso, para seguir adelante. Las instrucciones para el uso del sistema deben estar a la
vista o ser fácilmente recuperables cuando sea necesario.
 7. Flexibilidad y eficiencia de uso: la presencia de aceleradores, que no son vistos por los
usuarios novatos, puede ofrecer una interacción más rápida a los usuarios expertos que la
que el sistema puede proveer a los usuarios de todo tipo. Se debe permitir que los
usuarios adapte el sistema para usos frecuentes.
8. Estética y diseño minimalista: los diálogos no deben contener información que es
irrelevante o poco usada. Cada unidad extra de información en un diálogo, compite con
las unidades de información relevante y disminuye su visibilidad relativa.
9. Ayudar a los usuarios a reconocer: diagnosticar y recuperarse de errores: los mensajes
de error se deben entregar en un lenguaje claro y simple, indicando en forma precisa el
problema y sugerir una solución constructiva al problema.
10. Ayuda y documentación: incluso en los casos en que el sistema pueda ser usado sin
documentación, podría ser necesario ofrecer ayuda y documentación. Dicha información
debería ser fácil de buscar, estar enfocada en las tareas del usuario, con una lista concreta
de pasos a desarrollar y no ser demasiado extensa.

Los 10 errores comunes en diseño de software según Jakop Nielsen

1. La mala búsqueda
2. Los archivos PDF para lectura en línea
3. No cambiar el color de los enlaces visitados
4. Texto no escaneable
5. Tamaño de fuente fijo
6. Títulos de página con baja visibilidad en los motores de búsqueda
7. Todo lo que parezca un anuncio
8. Violación de las convenciones de diseño
9. Abrir nuevas ventanas del navegador
10. No responder a las preguntas de los usuarios