SlideShare une entreprise Scribd logo
1  sur  20
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
VICERRECTORADO ACADEMICO
COORDINACIÓN GENERAL DE INVESTIGACIÓN Y POSTGRADO
MAESTRÍA EN TECNOLOGÍAS DE LA INFORMACIÓN
GESTIÓN DE LA CALIDAD
Profesor:
GUEVARA, Carlos
Realizado por
APONTE, Marcel
CABRERA, Ransney
CORTEZ, Ramón
HERNANDEZ, Yonel
Ciudad Bolívar, Junio 2015
1
INDICE
INTRODUCCION 3
DEFINICIONES 4
CALIDAD 4
CONTROL DE CALIDAD 4
GARANTIA DE CALIDAD 4
COSTO DE CALIDAD 5
GESTION DE LA CALIDAD 5
CALIDAD DEL SOFTWARE 6
GARANTÍA DE LA CALIDAD DEL SOFTWARE (SQA, Software Quality Assurance) 6
REVISIONES DEL SOFTWARE 7
IMPACTO DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTO 8
GARANTIA DE CALIDAD ESTADISTICA 8
FIABILIDAD DEL SOFTWARE 9
MODELOS DE CALIDAD DEL SOFTWARE 10
1. CMMI 10
2. NORMA ISO 9000 11
3. ISO 15504 12
PLAN SQA 14
CONFIGURACIÓN DE PROYECTO DE SOFTWARE 14
USO DE HERRAMIENTAS 16
LAS SIETE HERRAMIENTAS CLÁSICAS DE CONTROL Y GESTIÓN
DE LA CALIDAD 17
CONCLUSIONES 19
2
INTRODUCCIÓN
La palabra “Calidad” tiene múltiples significados y/o valores, pero de manera básica, se
refiere al conjunto de características o propiedades inherentes a un objeto que le
confieren capacidad para satisfacer necesidades relacionadas al mismo. Por otro lado, la
calidad de un producto o servicio es la percepción que el cliente tiene del mismo, es una
fijación mental del consumidor que asume conformidad con dicho producto o servicio y la
capacidad del mismo para satisfacer sus necesidades.
En el mundo del software, los sistemas no escapan de esta realidad, ya que como todo
“producto” el mismo debe satisfacer las necesidades de los usuarios. La obtención de un
software con calidad implica la utilización de técnicas, metodologías y/o procedimientos
estándares para el análisis, diseño, programación y pruebas que permitan uniformar la
filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad
de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como
para el control de la calidad del software.
En esta investigación se describirán los aspectos de gestión y las actividades específicas
del proceso que permite a los programadores de software asegurar que se hace bien el
trabajo y que el producto cumple con las normas de calidad necesarias.
3
DEFINICIONES
Calidad
La calidad se puede definir como "una característica o atributo de una cosa". De esta
forma se podría decir que la calidad de los productos puede medirse como una
comparación de sus características y atributos. Así, este concepto puede aplicarse a
cualquier producto. Sin embargo el software en su gran extensión, como una entidad
intelectual, es más difícil de caracterizar. No obstante, si existen las medidas de
caracterización de un programa, entre estas destacan la complejidad ciclomatica,
cohesión, número de puntos de fusión, líneas de código, entre otras.
Pressman (2005)
Control de Calidad
Es una seria de inspecciones, revisiones y pruebas utilizados a los largo del proceso del
software para asegurar que cada producto cumple con los requisitos que se han
asignados. Este incluye un feedback del proceso que creo el producto donde la
combinación de medición y retroalimentación permiten afinar el proceso cuando los
productos de trabajo creados fallan al cumplir sus especificaciones. Existen 2 enfoques
complementarios que se utilizan para comprobar la calidad de un proyecto:
1. Revisiones de la calidad donde el software, su documentación y procesos
utilizados en su desarrollo son revisados por un grupo de personas. Se toma nota
de las desviaciones de los estándares y se comunican a gestor de proyecto.
2. Valoración automática del software. Esta comprende una medida cuantitativa de
algunos atributos del software.
Pressman (2005)
Garantía de Calidad
La garantía de la calidad es el proceso que define cómo lograr la calidad del software y
cómo la organización de desarrollo conoce el nivel de calidad requerido en el software.
Dentro del proceso de garantía de calidad se definen dos tipos de estándares como parte
del proceso:
4
1. Estándares de producto: Se aplican sobre el producto software que se comienza a
desarrollar. Incluyen estándares de documentación, como cabecera de comentarios
estándar para definición de clases, y estándares de codificación.
2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo
del software. Pueden incluir definiciones de procesos de especificación, diseño y
validación, así como una descripción de los documentos que deben escribirse en el curso
de estos procesos.
Sommerville (2005)
Esta consiste en la auditoría y las funciones de información de la gestión, donde su
objetivo es proporcionar la gestión para informar de los datos necesarios sobre la calidad
del producto, por lo que se va adquiriendo una visión más profunda y segura de que la
calidad del producto cumple sus objetivos.
Pressman (2005)
Costo de Calidad
El Costo de Calidad consiste en identificar y cuantificar todos los costos derivados del
esfuerzo de una compañía hacia la planeación de la calidad, los costos de verificar que
los parámetros de calidad están siendo logrados, los costos de las fallas en proceso y los
rechazos de los clientes.
Feigenbaum (1999)
Gestión de la Calidad
Es el conjunto de normas correspondientes a una organización, vinculadas entre sí y a
partir de las cuales es que la empresa u organización en cuestión podrá administrar de
manera organizada la calidad de la misma. La misión siempre estará enfocada hacia la
mejora continua de la calidad.
Pressman (2005)
5
Calidad del Software
Pressman (Pressman, 2005) define la calidad del software como: “la concordancia con los
requerimientos funcionales y de rendimiento explícitamente establecidos, con los
estándares de desarrollo explícitamente documentados y con las características implícitas
que se espera de todo software desarrollado profesionalmente”.
En la definición de la calidad del software pueden estar involucrados aspectos como la
ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de
especificaciones. Sin embargo, hay algo importante que se debe tener presente: la
calidad del software debe ser construida desde el comienzo, no es algo que puede ser
añadido después. Para que el producto final sea de calidad, el proceso por medio del cual
éste es elaborado debe ser también de calidad
Para poder determinar la calidad de un software hay que hacer hincapié en tres puntos
importantes. El primero habla sobre los requisitos del software, ya que estos son la base
de las medidas de calidad, la falta de concordancia con los requisitos es una falta de
calidad. El segundo punto trata sobre los estándares específicos los cuales definen un
conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del
software, y por ultimo tenemos los requisitos implícitos del software, estos son un conjunto
de requisitos que ha menudo no se mencionan pero son importantes para la calidad del
software.
GARANTÍA DE CALIDAD DEL SOFTWARE (SQA, Software Quality Assurance)
La historia de la garantía de calidad en el desarrollo del software es paralela a la historia
de la calidad en la creación del hardware. Durante los primeros años de la informática, la
calidad era responsabilidad únicamente del programador. Años después y a raíz de los
contratos militares de los años setenta se introdujeron estándares de garantía de calidad
para el software desarrollado en esa época.
La garantía de calidad del software comprende una gran variedad de tareas, asociadas
con dos grupos diferentes como lo son los ingenieros de software que realizan el trabajo
técnico y un grupo SQA que tiene la responsabilidad de la planificación de garantía de
calidad, de la supervisión, del mantenimiento de registros, del análisis e informes. El
grupo SQA debe realizar las siguientes actividades:
• Establecimiento de un plan SQA para un proyecto.
6
• Participación en el desarrollo de la descripción del proceso de software del
proyecto.
• Revisión de las actividades de ingeniería del software para verificar su ajuste al
proceso del software definido.
• Auditoría de los productos de software designados para verificar el ajuste con los
definidos como parte del proceso del software.
• Asegurar que las desviaciones del trabajo y los productos del software se
documentan y se manejan de acuerdo con unos procedimientos establecidos.
Además de estas actividades, el grupo SQA coordina el control y la gestión de cambios y
ayuda a recopilar y analizar las métricas del software.
REVISIONES DEL SOFTWARE
Las revisiones del software son un filtro para el proceso de ingeniería del software. Estas
se aplican en varios momentos del desarrollo y sirven para detectar errores y defectos
que pueden así ser eliminados. Existen muchos tipos de revisiones que se pueden llevar
adelante como parte de la ingeniería del software, cada una tiene su lugar. Entre estas
destacan la Revisión Técnica Formal (RTF) la cual es llevada a cabo por los ingenieros
del software. Entre sus objetivos destacan:
1. Descubrir en la función, lógica o la implementación de cualquier representación del
software.
2. Verificar que el software bajo revisión alcanza sus requisitos.
3. Garantizar que el software ha sido representado de acuerdo con ciertos
estándares predefinidos.
4. Conseguir un software desarrollado de forma uniforme.
5. Hacer que los proyectos sean más manejables.
La RTF son revisiones que incluyen recorridos, inspecciones, revisiones cíclicas y otro
pequeño grupo de evaluaciones técnicos del software. Cada RTF se lleva a cabo
mediante una reunión y solo tendrá éxito si es bien planificada, controlada y atendida.
7
Impacto de los Defectos del Software sobre el Costo
Un defecto es una anomalía del producto. En el contexto del hardware se encuentra:
“Un paso incorrecto, proceso o definición de datos en un programa de
computadora”
IEEE (1990)
Un defecto o un fallo implican un problema de calidad que es descubierto después de
entregar el software a los usuarios finales (o a otra actividad del proceso del software).
El objetivo primario de las revisiones técnicas formales (RTF) es encontrar errores durante
el proceso, de forma que se conviertan en defectos después de la entrega del software. El
beneficio obvio de estas revisiones técnicas formales es el descubrimiento de errores al
principio para que no se propaguen al paso siguiente del proceso del software.
GARANTÍA DE CALIDAD ESTADÍSTICA
La garantía de calidad estadística refleja una tendencia creciente en toda la industria, a
establecer la calidad más cuantitativamente. Para el software, la garantía de calidad
estadística implica los siguientes pasos:
1. Se agrupa y se clasifica la información sobre los defectos del software.
2. Se intenta encontrar la causa subyacente de cada defecto.
3. Mediante el principio de Pareto (el 80% de los defectos se pueden encontrar en el
20% de todas las posibles causas) se aísla el 20%.
4. Una vez que se han identificados los defectos vitales, se actúa para corregir los
problemas que han producidos los defectos.
Este concepto relativamente sencillo representa un paso importante hacia la creación de
un proceso de ingeniería del software adaptativo en el cual se realiza cambios para
mejorar aquellos elementos del proceso que introducen errores.
Entre las causas que agrupan los errores que se descubren mientras se desarrolla el
software, encontramos:
• Especificación incompleta o errónea (EIE).
• Mala Interpretación de la Comunicación con el Cliente (MCC).
• Desviación deliberada de la especificación (DDE).
8
• Incumplimiento de los estándares de programación (IEP).
• Error en la representación de los datos (ERD).
• Interfaz de módulo inconsistente (IMI).
• Error en la lógica de diseño (ELD).
• Prueba incompleta o errónea (PIE).
• Documentación imprecisa o incompleta (DII).
• Error en la traducción del diseño al lenguaje de programación (TLP).
• Interfaz hombre-maquina ambigua o inconsistente (IHM).
FIABILIDAD DEL SOFTWARE
Este es un elemento importante en la calidad del software, ya que si un programa falla
frecuentemente en su funcionamiento, no importa si el resto de los factores de calidad son
aceptables. La fiabilidad del software, a diferencia de otros factores de calidad, puede ser
medida o estimada mediante datos históricos o de desarrollo y se puede definir en
términos estadísticos.
Los primeros trabajos sobre fiabilidad intentaron explotar las matemáticas de la teoría de
fiabilidad del hardware a la predicción de la fiabilidad del software. La mayoría de los
modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al
desajuste, que a los fallos debido a defectos del diseño. En el hardware, son más
probables los fallos debidos al desgaste físico que los fallos relativos al diseño.
Desgraciadamente para el software lo que ocurre es lo contrario. De hecho todos los
fallos del software, se producen por problemas de diseño o de implementación; el
desajuste no entra en este panorama.
Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es
el tiempo medio entre fallos (TMEF), donde:
TMEF = TMDF + TMDR
TMEF: Tiempo Medio Entre Fallos. TMDF: Tiempo Medio De Fallo.
TMDR: Tiempo Medio De Reparación.
Además de una medida de fiabilidad, debemos obtener una medida de la disponibilidad.
La disponibilidad del software es la probabilidad de que un programa funcione de acuerdo
con los requisitos en un momento dado, y se define como:
Disponibilidad = [TMDF/(TMDF+TMDR)] x 100%
9
La medida de fiabilidad TMEF es igualmente sensible al TMDR que al TMDF. La medida
de disponibilidad es algo más sensible al TMDR, una medida indirecta de la facilidad de
mantenimiento del software.
MODELOS DE CALIDAD DEL SOFTWARE
1. CMMI: Diseñado por el Carnegie Mellon Software Engineering Institute.
El CMMI: es un modelo de calidad del software que clasifica las empresas en niveles de
madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan
para producir software.
Los niveles CMMI son 5:
• Inicial o Nivel 1: Este es el nivel en donde están todas las empresas que no tienen
procesos. Los presupuestos se disparan, no es posible entregar el proyecto en
fechas, los empleados si tienen que quedar durante noches y fines de semana
para terminar un proyecto. No hay control sobre el estado del proyecto, el
desarrollo del proyecto es completamente opaco, no se sabe que pasara con él.
• Nivel 2: Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La
principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y
controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede
saber el estado del proyecto en todo momento.
• Nivel 3: alcanzar este nivel significa que la forma de desarrollar proyectos (gestión
e ingeniería) está definida, por definida quiere decir que está establecida,
documentada y que existen métricas (obtención de datos objetivos) para la
consecución de objetivos concretos.
• Nivel 4: Los proyectos usan objetivos medibles para alcanzar las necesidades de
los clientes y la organización. Se usan métricas para gestionar la organización.
• Nivel 5: Los procesos de los proyectos y de la organización están orientados a la
mejora de las actividades. Mejoras incrementales e innovadoras de los procesos
que mediante métricas son identificadas, evaluadas y puestas en práctica.
10
Ventajas:
• Compromiso asegurado.
• Automatizar lo más posible las actividades de control y gestión de los procesos de
los proyectos.
• Comenzar a documentar los procesos implícitos, en la medida de lo posible 0
plantillas en office, implementación de sistemas de gestión.
• Utilización de sistemas libres para minimizar los costos de implementación.
Desventajas:
• Requiere mucho esfuerzo, compromiso de toda la organización.
• Comenzar a diseñar y/o documentar procesos, luego desplegarlos y ponerlos en
práctica.
• Requiere un mínimo de cantidad de personal.
• Fuerte inversión económica
2. Norma ISO 9000: Diseñada por la International Organization for
Standardization.
Norma ISO 9000: es un conjunto de estándares internacionales que se pueden utilizar en
el desarrollo de un sistema de gestión de calidad de todas las industrias. Las series de
ISO 9000 son un grupo de 5 individuales, pero relacionadas, estándares internacionales
de administración de la calidad y aseguramiento de calidad.
• ISO 9001:2000 - Sistemas de Gestión de la Calidad – Requisitos.
• ISO 9004:2000 - Sistemas de Gestión de la Calidad - Guía de mejoras del
funcionamiento.
• ISO 9000:2000 contiene las definiciones de los términos que se utilizan en las
otras dos normas. Es decir que si alguien necesita conocer qué se entiende por
"sistema de gestión de la calidad", "no conformidad", "producto", por ejemplo, debe
referirse a esta norma.
11
ISO 9000 no es un estándar específico para el desarrollo del software, pero define los
principios primordiales que pueden aplicarse. Este describe varios aspectos del proceso
de calidad y define que estándares y procedimientos deben existir en una organización, la
definición del proceso debe incluir una descripción de la documentación requerida, donde
se demuestre que los procesos definidos han sido seguidos desde el desarrollo del
producto.
Ince (Ince 1994) y Oskarsson y Glass (Oskarsson y Glass 1995), dan detalles de como se
puede utilizar el estándar para desarrollar procesos de gestión de calidad del software.
El estándar ISO 9001 ha sido adoptado por mas de 130 países para su uso y se esta
convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de
un desarrollador de software
Para la industria del software los estándares relevantes son:
• ISO 9001. Quality systems – model for quality assuance and servicing. Este es un
estándar que describe el sistema de calidad utilizado para mantener el desarrollo
de un producto que implique diseño.
• ISO 9000-3. Guidelines for application of ISO 9001 to the Develoment, supply and
Maintainance of software. Este es un documento especifico que interpreta el ISO
9001 para el desarrollador del software
• ISO 9004-2. Quality Management and quality system element. Este documento
proporciona las directrices para el servicio de facilidades del software como
soporte de usuarios.
3. ISO 15504: Modelo para la mejora y evaluación de los procesos de desarrollo
y mantenimiento de sistemas y productos de software.
Norma ISO 1554: Es un modelo para la mejora y evaluación de los procesos de desarrollo
y mantenimiento de sistemas y productos de software.
Características:
• Establece un marco para métodos de evaluación, no es un método o modelo en sí.
12
• Comprende: evaluación de procesos, mejora de procesos, determinación de
capacidad.
• Está alineado con el estándar ISO/IEC 12207 que define los procesos del ciclo de
vida del desarrollo, mantenimiento y operación de los sistemas de software.
• Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del
modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con
15504.
Arquitectura Norma ISO 15504.
La norma tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad
de proceso. Desde la dimensión de proceso agrupa a los procesos en tres grupos que
contienen cinco categorías de acuerdo al tipo de actividad:
1. Procesos Primarios:
2. Procesos de Soporte:
3. Procesos Organizacionales:
Para todos los procesos se definen los componentes: Identificador, Nombre, Tipo,
Propósito, Salidas y Notas. Desde la dimensión de capacidad el modelo define una escala
de 6 niveles para determinar la capacidad de cualquier proceso:
• Nivel 0: Incompleto.
• Nivel 1: Realizado.
• Nivel 2: Gestionado.
• Nivel 3: Establecido.
• Nivel 4: Predecible.
• Nivel 5: En optimización.
13
PLAN SQA
Un plan SQA proporciona un mapa para institucionalizar la garantía de la calidad de SW
en una empresa. Este plan sirve como modelo para actividades de SQA instituidas para
cada proyecto de software que desarrolle la empresa.
Según IEEE un plan de calidad SQA debe contemplar:
• Un propósito (Por qué se hace?).
• Un alcance (Qué áreas cubre?)
• Unos documentos referentes (requeridos).
• Unos estándares a usar.
• Una gestión del plan. (Doc. Del proyecto, modelos, Doc. Técnicos, Doc. De
Usuarios).
• Estándares, prácticas y convenciones, utilizados en procesos de SW.
• Pruebas (plan de pruebas de software, problemas y acciones tomadas).
• Herramientas y métodos que soportan tareas y actividades SQA.
CONFIGURACIÓN DE PROYECTO DE SOFTWARE
Uno de los aspectos fundamentales del software con respecto a otro tipo de producto de
ingeniería, es que es sabido que el software está en continuo cambio bien sea para
evolucionar su funcionalidad o para reparar un determinado defecto, entre otros posibles
escenarios de cambio. La gestión de configuración del software mediante la identificación
y control de cambios permite garantizar la correcta ejecución del cambio e informar del
cambio a los afectados.
Podemos definir que la gestión de la configuración de software es el proceso que tendrá
lugar a lo largo del proyecto a desarrollar, es decir desde que se inicia el proyecto hasta
que el software se deja de comercializar, en este lapso de tiempo se realizará un estudio
con el fin de controlar los cambios acaecidos, así como aprobar dichos cambios y
14
asegurar que los integrantes/participantes del proyecto disponen de las versiones
adecuadas de los productos generados durante el proyecto.
El proceso de Gestión de la Configuración tiene lugar durante toda la vida del proyecto y
por ello se divide en una serie de fases las cuales están asociadas a las distintas partes o
fases del proyecto.
• Gestión del Código Fuente: Se analiza la estructura del código fuente del proyecto,
los roles, la plataforma donde es alojado el código, etc...
• Gestión de la Construcción: Se indica las herramientas utilizadas para la
construcción del proyecto, cómo se utilizan, etc...
• Gestión de los Entregables: Qué entregables se contemplan en el proyecto y cómo
se realiza su entrega. Estos son el propio código fuente, liberado como entregable
con cada nueva versión, y la documentación que no sigue una política establecida
más allá de su dependencia con el código fuente.
• Gestión del Despliegue: Como se realiza el despliegue, que herramientas se
utiliza, cuando se realiza.
• Gestión de Incidencias y Depuración: Se explica el proceso de reporte de
incidencias y cómo se realiza la depuración.
• Gestión de la Variabilidad
• Integración y Despliegue Continuos: A modo de facilitar las tareas de pruebas se
recurre a herramientas de integración y despliegue continuo. Estas herramientas
nos proporciona mecanismo para recopilar los distintos proyectos involucrados,
dependencias, incorporar los cambios realizados, etc. Una vez reunido se
construye el proyecto y ejecutan las pruebas incorporadas, si pasa las pruebas se
puede publicar de manera automática o desplegar directamente en un servidor.
• Las Pruebas: Se describen los tipos de pruebas que se realizan en el proyecto y el
procedimiento para ejecutarlas.
• Mapa de Herramientas: Se describen las herramientas necesarias para trabajar
con el proyecto en las diferentes actividades de la Gestión de la Configuración, y la
relación que tienen entre ellas.
15
El estándar ISO/IEC 12207 ([ISO 12207]) para procesos del ciclo de vida del software,
establece el proceso de gestión de configuración como uno de los procesos de soporte
del ciclo de vida. Un proceso de soporte “apoya” a otro proceso como una parte integral,
con un propósito distinto, y contribuye al éxito y a la calidad del proyecto de software.
Este proceso consiste de las siguientes actividades:
• Implementación del Proceso: Se desarrolla un plan de gestión de configuración
que describe las actividades de gestión de configuración, los procedimientos y el
cronograma para su realización, y los responsables de dichas actividades. Dicho
plan debe ser documentado e implementado.
• Identificación de la Configuración: Se establece un esquema de identificación de
los elementos de software y sus versiones a ser controlados por el proyecto.
• Control de la Configuración: Se identifican y registran las solicitudes de cambio, se
analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa,
verifica y distribuye el elemento de software modificado.
• Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y
reportes de estado que muestren el estado e historia de los elementos de software
controlados, incluyendo líneas base.
• Evaluación de la Configuración: Se determina y asegura que los elementos de
software sean funcionalmente (versus sus requerimientos) y físicamente
completos (es decir, si su diseño y Código reflejan una descripción técnica
actualizada).
• Gestión de actualización y distribución: Se controla formalmente la actualización y
distribución de los productos de software.
USO DE HERRAMIENTAS
Estas herramientas son las denominadas «Siete Herramientas del Control de la Calidad o
herramientas estadísticas básicas, y abarcan la hoja de recogida de datos, el histograma,
el diagrama de Pareto, el diagrama de espina, la estratificación, el diagrama de
correlación y los gráficos de control.
16
En general, estas herramientas pueden ser utilizadas para detectar y solucionar la
inmensa mayoría de los problemas que surgen en la organización. Según Ishikawa
(1994), aplicadas e utilizadas correctamente permiten la resolución del 95 % de los
problemas de los puestos de trabajo, quedando sólo un 5 % de los casos en que se
necesitan otras herramientas con utilización de métodos estadísticos mucho más
complejos y avanzados.
Funciones Herramientas
Fundamentos .- Recoger los datos
.- Interpretar los datos
Hoja recogida de datos,
Histogramas
Pilares .- Estudiar las relaciones causa – efecto.
.-Fija Prioridades
Diagramas de espina y de
pareto.
Instrumentos
Auxiliares
.- Estratificar los datos
.- Determinar las correlaciones
.- Determinar si un proceso esta bajo
control
Diagrama de correlación,
grafico de control y
estratificar
Las siete herramientas clásicas de control y gestión de la calidad:
1. Hoja de recogida de datos: La hoja de recogida de datos sirve para recoger los
datos necesarios y poder realizar un posterior análisis de éstos. Su principal
utilidad proviene del empleo de datos objetivos a la hora de examinar un fenómeno
determinado. Como sirven de base para adoptar decisiones, es importante que el
método de recogida y el análisis de los propios datos garanticen una interpretación
correcta del fenómeno estudiado.
2. Histograma: Los histogramas son diagramas de barras que muestran el grado y la
naturaleza de variación dentro del rendimiento de un proceso. El histograma
muestra la distribución de frecuencias de un conjunto de valores mediante la
representación con barras.
3. El diagrama de Pareto: El diagrama de Pareto es una herramienta de
representación gráfica que identifica los problemas más importantes, en función de
su frecuencia de ocurrencia o coste (dinero, tiempo), y permite establecer las
prioridades de intervención.
4. El diagrama de espina: El diagrama de espina se utiliza para recoger de manera
gráfica todas las posibles causas de un problema o identificar los aspectos
necesarios para alcanzar un determinado objetivo (efecto).
17
5. El diagrama de correlación: El diagrama de correlación o diagrama de dispersión
sirve para determinar si existe relación entre dos variables, normalmente de causa
y efecto.
6. La estratificación: La estratificación consiste en dividir los datos recogidos en
grupos homogéneos para facilitar una mejor comprensión del fenómeno estudiado.
A cada grupo homogéneo se lo denomina estrato. Esta técnica permite investigar
los aspectos más significativos o las áreas más importantes donde es necesario
centrar la atención.
7. Gráfico de control: El gráfico de control es una herramienta gráfica que se utiliza
para medir la variabilidad de un proceso. Consiste en valorar si el proceso está
bajo control o fuera de control en función de unos límites de control estadísticos
calculados.
18
CONCLUSIONES
La calidad del software no se puede medir de una manera correcta u objetiva debido a su
naturaleza, sin embargo la certificación se le da a los procesos, técnicos y/o metodologías
que permiten diseñar, documentar y desarrollar el software, la correcta consecución de los
mismos garantizaría un buen software. Por otro lado la gestión de calidad del software es
una actividad de protección que se aplica a cada paso del proceso y que permite señalar
si este tiene un escaso número de defectos y si alcanza los estándares requeridos de
mantenibilidad, fiabilidad, portabilidad, etc. Dichas actividades comprenden la garantía de
la calidad que establecen los estándares para el desarrollo del software, la planificación
de la calidad y el control de la calidad que comprueba el software con respecto a los
estándares requeridos.
La capacidad para garantizar la calidad es la medida de la madurez de la disciplina de la
ingeniería, cuando se sigue de forma adecuada esa guía mencionada anteriormente, lo
que se consigue es la madurez de la ingeniería del software.
BIBLIOGRAFÍA
19
Roger S. Pressman, Ingeniería del Software – Un enfoque practico. 5ta edición. Mc Graw
Hill, 2002.
Ian Sommerville, María Isabel Alfonso Galipienso. Ingeniería del Software. Pearson
Educación, 2005.
César Camisón; Sonia Cruz; Tomás González, Gestión de la Calidad: Conceptos,
Enfoques, Modelos y Sistemas. Pearson Educación, 2006.
20

Contenu connexe

Tendances (20)

Calidad software
Calidad softwareCalidad software
Calidad software
 
Calidad software
Calidad softwareCalidad software
Calidad software
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
SQA
SQASQA
SQA
 
Calidad de Software
Calidad de SoftwareCalidad de Software
Calidad de Software
 
Calidad Del Software
Calidad Del SoftwareCalidad Del Software
Calidad Del Software
 
Actividad de aprendizaje 2
Actividad  de aprendizaje 2Actividad  de aprendizaje 2
Actividad de aprendizaje 2
 
Calidad de software Unidad 1
Calidad de software Unidad 1Calidad de software Unidad 1
Calidad de software Unidad 1
 
Conceptos basicos calidad software
Conceptos basicos calidad softwareConceptos basicos calidad software
Conceptos basicos calidad software
 
Calidad Del Producto Software
Calidad Del Producto SoftwareCalidad Del Producto Software
Calidad Del Producto Software
 
Ra semana 16
Ra semana 16Ra semana 16
Ra semana 16
 
Unidad 5
Unidad 5Unidad 5
Unidad 5
 
Calidad de software ii
Calidad de software iiCalidad de software ii
Calidad de software ii
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
SEGUNDA PARTE - Gestion de la calidad del software
SEGUNDA PARTE - Gestion de la calidad del softwareSEGUNDA PARTE - Gestion de la calidad del software
SEGUNDA PARTE - Gestion de la calidad del software
 
Aseguramiento de la Calidad del Software II
Aseguramiento de la Calidad del Software IIAseguramiento de la Calidad del Software II
Aseguramiento de la Calidad del Software II
 
Unidad 1_calidad del software
Unidad 1_calidad del softwareUnidad 1_calidad del software
Unidad 1_calidad del software
 
1 u3 aseguramiento_calidadsoftware
1 u3 aseguramiento_calidadsoftware1 u3 aseguramiento_calidadsoftware
1 u3 aseguramiento_calidadsoftware
 
Fundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y EstándaresFundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y Estándares
 
Calidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open SourceCalidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open Source
 

Similaire à Gestión de la Calidad

Calidad de software septimo semestre
Calidad de software septimo semestreCalidad de software septimo semestre
Calidad de software septimo semestrerodrigoarriagasalinas
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del softwareDarleneperalta
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del softwarenaviwz
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del softwareEmily Moncada
 
Calidad
CalidadCalidad
Calidadgmjuan
 
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalyActividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalynataly duque
 
Calidad de software ii
Calidad de software iiCalidad de software ii
Calidad de software iiCamilo Andres
 
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx .pptx
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx  .pptxCalidad_en_el_SoftwareCalidad_en_el_Software.pptx  .pptx
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx .pptxgabrielguillen23
 
Grupo de exposicion # 4 introduccion a ingenieria de software semestre 1 - ...
Grupo de exposicion # 4   introduccion a ingenieria de software semestre 1 - ...Grupo de exposicion # 4   introduccion a ingenieria de software semestre 1 - ...
Grupo de exposicion # 4 introduccion a ingenieria de software semestre 1 - ...ronnygomez4
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software3134267271
 
Fundamentos de la calidad del software
Fundamentos de la calidad del softwareFundamentos de la calidad del software
Fundamentos de la calidad del softwareJonathan
 

Similaire à Gestión de la Calidad (20)

Calidad de software septimo semestre
Calidad de software septimo semestreCalidad de software septimo semestre
Calidad de software septimo semestre
 
Gestion De Calidad Cap 26
Gestion De Calidad Cap 26Gestion De Calidad Cap 26
Gestion De Calidad Cap 26
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Calidaddelsoftware
CalidaddelsoftwareCalidaddelsoftware
Calidaddelsoftware
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del software
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del software
 
Calidad
CalidadCalidad
Calidad
 
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalyActividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
 
Activida 2
Activida 2Activida 2
Activida 2
 
Calidad de software ii
Calidad de software iiCalidad de software ii
Calidad de software ii
 
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx .pptx
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx  .pptxCalidad_en_el_SoftwareCalidad_en_el_Software.pptx  .pptx
Calidad_en_el_SoftwareCalidad_en_el_Software.pptx .pptx
 
Gestión De Calidad
Gestión De CalidadGestión De Calidad
Gestión De Calidad
 
GestióN De Calidad
GestióN De CalidadGestióN De Calidad
GestióN De Calidad
 
Unidad 5
Unidad 5Unidad 5
Unidad 5
 
S1-CDSQA.pptx
S1-CDSQA.pptxS1-CDSQA.pptx
S1-CDSQA.pptx
 
Grupo de exposicion # 4 introduccion a ingenieria de software semestre 1 - ...
Grupo de exposicion # 4   introduccion a ingenieria de software semestre 1 - ...Grupo de exposicion # 4   introduccion a ingenieria de software semestre 1 - ...
Grupo de exposicion # 4 introduccion a ingenieria de software semestre 1 - ...
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Fundamentos de la calidad del software
Fundamentos de la calidad del softwareFundamentos de la calidad del software
Fundamentos de la calidad del software
 
Calidad del Software
Calidad del SoftwareCalidad del Software
Calidad del Software
 

Plus de Marcel Aponte

Instructivo de Laboratorios - Telemática - UNEG
Instructivo de Laboratorios - Telemática - UNEGInstructivo de Laboratorios - Telemática - UNEG
Instructivo de Laboratorios - Telemática - UNEGMarcel Aponte
 
Instructivo Wireless (Laboratorio 1)
Instructivo Wireless (Laboratorio 1)Instructivo Wireless (Laboratorio 1)
Instructivo Wireless (Laboratorio 1)Marcel Aponte
 
Propuesta Microsoft.NET
Propuesta Microsoft.NETPropuesta Microsoft.NET
Propuesta Microsoft.NETMarcel Aponte
 
Microsoft .NET Propuesta
Microsoft .NET PropuestaMicrosoft .NET Propuesta
Microsoft .NET PropuestaMarcel Aponte
 
Sistemas Orientados a Objetos
Sistemas Orientados a ObjetosSistemas Orientados a Objetos
Sistemas Orientados a ObjetosMarcel Aponte
 
Análisis de Requerimientos
Análisis de RequerimientosAnálisis de Requerimientos
Análisis de RequerimientosMarcel Aponte
 
Plan de Recuperación de Desastres - TI
Plan de Recuperación de Desastres - TIPlan de Recuperación de Desastres - TI
Plan de Recuperación de Desastres - TIMarcel Aponte
 
Construcción de un Mapa Conceptual de la Ingeniería del Software
Construcción de un Mapa Conceptual de la Ingeniería del SoftwareConstrucción de un Mapa Conceptual de la Ingeniería del Software
Construcción de un Mapa Conceptual de la Ingeniería del SoftwareMarcel Aponte
 
Ingeniería del Software Libre (ISL)
Ingeniería del Software Libre (ISL) Ingeniería del Software Libre (ISL)
Ingeniería del Software Libre (ISL) Marcel Aponte
 

Plus de Marcel Aponte (10)

Instructivo de Laboratorios - Telemática - UNEG
Instructivo de Laboratorios - Telemática - UNEGInstructivo de Laboratorios - Telemática - UNEG
Instructivo de Laboratorios - Telemática - UNEG
 
Instructivo Wireless (Laboratorio 1)
Instructivo Wireless (Laboratorio 1)Instructivo Wireless (Laboratorio 1)
Instructivo Wireless (Laboratorio 1)
 
Propuesta Microsoft.NET
Propuesta Microsoft.NETPropuesta Microsoft.NET
Propuesta Microsoft.NET
 
Microsoft .NET Propuesta
Microsoft .NET PropuestaMicrosoft .NET Propuesta
Microsoft .NET Propuesta
 
Sistemas Orientados a Objetos
Sistemas Orientados a ObjetosSistemas Orientados a Objetos
Sistemas Orientados a Objetos
 
Análisis de Requerimientos
Análisis de RequerimientosAnálisis de Requerimientos
Análisis de Requerimientos
 
Grafos Ponderados
Grafos PonderadosGrafos Ponderados
Grafos Ponderados
 
Plan de Recuperación de Desastres - TI
Plan de Recuperación de Desastres - TIPlan de Recuperación de Desastres - TI
Plan de Recuperación de Desastres - TI
 
Construcción de un Mapa Conceptual de la Ingeniería del Software
Construcción de un Mapa Conceptual de la Ingeniería del SoftwareConstrucción de un Mapa Conceptual de la Ingeniería del Software
Construcción de un Mapa Conceptual de la Ingeniería del Software
 
Ingeniería del Software Libre (ISL)
Ingeniería del Software Libre (ISL) Ingeniería del Software Libre (ISL)
Ingeniería del Software Libre (ISL)
 

Dernier

redes informaticas en una oficina administrativa
redes informaticas en una oficina administrativaredes informaticas en una oficina administrativa
redes informaticas en una oficina administrativanicho110
 
Guia Basica para bachillerato de Circuitos Basicos
Guia Basica para bachillerato de Circuitos BasicosGuia Basica para bachillerato de Circuitos Basicos
Guia Basica para bachillerato de Circuitos BasicosJhonJairoRodriguezCe
 
investigación de los Avances tecnológicos del siglo XXI
investigación de los Avances tecnológicos del siglo XXIinvestigación de los Avances tecnológicos del siglo XXI
investigación de los Avances tecnológicos del siglo XXIhmpuellon
 
How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.FlorenciaCattelani
 
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptxEVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptxJorgeParada26
 
Avances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estosAvances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estossgonzalezp1
 
Avances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanaAvances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanamcerpam
 
Buenos_Aires_Meetup_Redis_20240430_.pptx
Buenos_Aires_Meetup_Redis_20240430_.pptxBuenos_Aires_Meetup_Redis_20240430_.pptx
Buenos_Aires_Meetup_Redis_20240430_.pptxFederico Castellari
 
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...JohnRamos830530
 
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxPROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxAlan779941
 
Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21mariacbr99
 

Dernier (11)

redes informaticas en una oficina administrativa
redes informaticas en una oficina administrativaredes informaticas en una oficina administrativa
redes informaticas en una oficina administrativa
 
Guia Basica para bachillerato de Circuitos Basicos
Guia Basica para bachillerato de Circuitos BasicosGuia Basica para bachillerato de Circuitos Basicos
Guia Basica para bachillerato de Circuitos Basicos
 
investigación de los Avances tecnológicos del siglo XXI
investigación de los Avances tecnológicos del siglo XXIinvestigación de los Avances tecnológicos del siglo XXI
investigación de los Avances tecnológicos del siglo XXI
 
How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.
 
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptxEVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
 
Avances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estosAvances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estos
 
Avances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanaAvances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvana
 
Buenos_Aires_Meetup_Redis_20240430_.pptx
Buenos_Aires_Meetup_Redis_20240430_.pptxBuenos_Aires_Meetup_Redis_20240430_.pptx
Buenos_Aires_Meetup_Redis_20240430_.pptx
 
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
 
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxPROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
 
Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21
 

Gestión de la Calidad

  • 1. UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA VICERRECTORADO ACADEMICO COORDINACIÓN GENERAL DE INVESTIGACIÓN Y POSTGRADO MAESTRÍA EN TECNOLOGÍAS DE LA INFORMACIÓN GESTIÓN DE LA CALIDAD Profesor: GUEVARA, Carlos Realizado por APONTE, Marcel CABRERA, Ransney CORTEZ, Ramón HERNANDEZ, Yonel Ciudad Bolívar, Junio 2015 1
  • 2. INDICE INTRODUCCION 3 DEFINICIONES 4 CALIDAD 4 CONTROL DE CALIDAD 4 GARANTIA DE CALIDAD 4 COSTO DE CALIDAD 5 GESTION DE LA CALIDAD 5 CALIDAD DEL SOFTWARE 6 GARANTÍA DE LA CALIDAD DEL SOFTWARE (SQA, Software Quality Assurance) 6 REVISIONES DEL SOFTWARE 7 IMPACTO DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTO 8 GARANTIA DE CALIDAD ESTADISTICA 8 FIABILIDAD DEL SOFTWARE 9 MODELOS DE CALIDAD DEL SOFTWARE 10 1. CMMI 10 2. NORMA ISO 9000 11 3. ISO 15504 12 PLAN SQA 14 CONFIGURACIÓN DE PROYECTO DE SOFTWARE 14 USO DE HERRAMIENTAS 16 LAS SIETE HERRAMIENTAS CLÁSICAS DE CONTROL Y GESTIÓN DE LA CALIDAD 17 CONCLUSIONES 19 2
  • 3. INTRODUCCIÓN La palabra “Calidad” tiene múltiples significados y/o valores, pero de manera básica, se refiere al conjunto de características o propiedades inherentes a un objeto que le confieren capacidad para satisfacer necesidades relacionadas al mismo. Por otro lado, la calidad de un producto o servicio es la percepción que el cliente tiene del mismo, es una fijación mental del consumidor que asume conformidad con dicho producto o servicio y la capacidad del mismo para satisfacer sus necesidades. En el mundo del software, los sistemas no escapan de esta realidad, ya que como todo “producto” el mismo debe satisfacer las necesidades de los usuarios. La obtención de un software con calidad implica la utilización de técnicas, metodologías y/o procedimientos estándares para el análisis, diseño, programación y pruebas que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. En esta investigación se describirán los aspectos de gestión y las actividades específicas del proceso que permite a los programadores de software asegurar que se hace bien el trabajo y que el producto cumple con las normas de calidad necesarias. 3
  • 4. DEFINICIONES Calidad La calidad se puede definir como "una característica o atributo de una cosa". De esta forma se podría decir que la calidad de los productos puede medirse como una comparación de sus características y atributos. Así, este concepto puede aplicarse a cualquier producto. Sin embargo el software en su gran extensión, como una entidad intelectual, es más difícil de caracterizar. No obstante, si existen las medidas de caracterización de un programa, entre estas destacan la complejidad ciclomatica, cohesión, número de puntos de fusión, líneas de código, entre otras. Pressman (2005) Control de Calidad Es una seria de inspecciones, revisiones y pruebas utilizados a los largo del proceso del software para asegurar que cada producto cumple con los requisitos que se han asignados. Este incluye un feedback del proceso que creo el producto donde la combinación de medición y retroalimentación permiten afinar el proceso cuando los productos de trabajo creados fallan al cumplir sus especificaciones. Existen 2 enfoques complementarios que se utilizan para comprobar la calidad de un proyecto: 1. Revisiones de la calidad donde el software, su documentación y procesos utilizados en su desarrollo son revisados por un grupo de personas. Se toma nota de las desviaciones de los estándares y se comunican a gestor de proyecto. 2. Valoración automática del software. Esta comprende una medida cuantitativa de algunos atributos del software. Pressman (2005) Garantía de Calidad La garantía de la calidad es el proceso que define cómo lograr la calidad del software y cómo la organización de desarrollo conoce el nivel de calidad requerido en el software. Dentro del proceso de garantía de calidad se definen dos tipos de estándares como parte del proceso: 4
  • 5. 1. Estándares de producto: Se aplican sobre el producto software que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentarios estándar para definición de clases, y estándares de codificación. 2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el curso de estos procesos. Sommerville (2005) Esta consiste en la auditoría y las funciones de información de la gestión, donde su objetivo es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto cumple sus objetivos. Pressman (2005) Costo de Calidad El Costo de Calidad consiste en identificar y cuantificar todos los costos derivados del esfuerzo de una compañía hacia la planeación de la calidad, los costos de verificar que los parámetros de calidad están siendo logrados, los costos de las fallas en proceso y los rechazos de los clientes. Feigenbaum (1999) Gestión de la Calidad Es el conjunto de normas correspondientes a una organización, vinculadas entre sí y a partir de las cuales es que la empresa u organización en cuestión podrá administrar de manera organizada la calidad de la misma. La misión siempre estará enfocada hacia la mejora continua de la calidad. Pressman (2005) 5
  • 6. Calidad del Software Pressman (Pressman, 2005) define la calidad del software como: “la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”. En la definición de la calidad del software pueden estar involucrados aspectos como la ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de especificaciones. Sin embargo, hay algo importante que se debe tener presente: la calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después. Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad Para poder determinar la calidad de un software hay que hacer hincapié en tres puntos importantes. El primero habla sobre los requisitos del software, ya que estos son la base de las medidas de calidad, la falta de concordancia con los requisitos es una falta de calidad. El segundo punto trata sobre los estándares específicos los cuales definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software, y por ultimo tenemos los requisitos implícitos del software, estos son un conjunto de requisitos que ha menudo no se mencionan pero son importantes para la calidad del software. GARANTÍA DE CALIDAD DEL SOFTWARE (SQA, Software Quality Assurance) La historia de la garantía de calidad en el desarrollo del software es paralela a la historia de la calidad en la creación del hardware. Durante los primeros años de la informática, la calidad era responsabilidad únicamente del programador. Años después y a raíz de los contratos militares de los años setenta se introdujeron estándares de garantía de calidad para el software desarrollado en esa época. La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos grupos diferentes como lo son los ingenieros de software que realizan el trabajo técnico y un grupo SQA que tiene la responsabilidad de la planificación de garantía de calidad, de la supervisión, del mantenimiento de registros, del análisis e informes. El grupo SQA debe realizar las siguientes actividades: • Establecimiento de un plan SQA para un proyecto. 6
  • 7. • Participación en el desarrollo de la descripción del proceso de software del proyecto. • Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso del software definido. • Auditoría de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. • Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con unos procedimientos establecidos. Además de estas actividades, el grupo SQA coordina el control y la gestión de cambios y ayuda a recopilar y analizar las métricas del software. REVISIONES DEL SOFTWARE Las revisiones del software son un filtro para el proceso de ingeniería del software. Estas se aplican en varios momentos del desarrollo y sirven para detectar errores y defectos que pueden así ser eliminados. Existen muchos tipos de revisiones que se pueden llevar adelante como parte de la ingeniería del software, cada una tiene su lugar. Entre estas destacan la Revisión Técnica Formal (RTF) la cual es llevada a cabo por los ingenieros del software. Entre sus objetivos destacan: 1. Descubrir en la función, lógica o la implementación de cualquier representación del software. 2. Verificar que el software bajo revisión alcanza sus requisitos. 3. Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos. 4. Conseguir un software desarrollado de forma uniforme. 5. Hacer que los proyectos sean más manejables. La RTF son revisiones que incluyen recorridos, inspecciones, revisiones cíclicas y otro pequeño grupo de evaluaciones técnicos del software. Cada RTF se lleva a cabo mediante una reunión y solo tendrá éxito si es bien planificada, controlada y atendida. 7
  • 8. Impacto de los Defectos del Software sobre el Costo Un defecto es una anomalía del producto. En el contexto del hardware se encuentra: “Un paso incorrecto, proceso o definición de datos en un programa de computadora” IEEE (1990) Un defecto o un fallo implican un problema de calidad que es descubierto después de entregar el software a los usuarios finales (o a otra actividad del proceso del software). El objetivo primario de las revisiones técnicas formales (RTF) es encontrar errores durante el proceso, de forma que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas revisiones técnicas formales es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso del software. GARANTÍA DE CALIDAD ESTADÍSTICA La garantía de calidad estadística refleja una tendencia creciente en toda la industria, a establecer la calidad más cuantitativamente. Para el software, la garantía de calidad estadística implica los siguientes pasos: 1. Se agrupa y se clasifica la información sobre los defectos del software. 2. Se intenta encontrar la causa subyacente de cada defecto. 3. Mediante el principio de Pareto (el 80% de los defectos se pueden encontrar en el 20% de todas las posibles causas) se aísla el 20%. 4. Una vez que se han identificados los defectos vitales, se actúa para corregir los problemas que han producidos los defectos. Este concepto relativamente sencillo representa un paso importante hacia la creación de un proceso de ingeniería del software adaptativo en el cual se realiza cambios para mejorar aquellos elementos del proceso que introducen errores. Entre las causas que agrupan los errores que se descubren mientras se desarrolla el software, encontramos: • Especificación incompleta o errónea (EIE). • Mala Interpretación de la Comunicación con el Cliente (MCC). • Desviación deliberada de la especificación (DDE). 8
  • 9. • Incumplimiento de los estándares de programación (IEP). • Error en la representación de los datos (ERD). • Interfaz de módulo inconsistente (IMI). • Error en la lógica de diseño (ELD). • Prueba incompleta o errónea (PIE). • Documentación imprecisa o incompleta (DII). • Error en la traducción del diseño al lenguaje de programación (TLP). • Interfaz hombre-maquina ambigua o inconsistente (IHM). FIABILIDAD DEL SOFTWARE Este es un elemento importante en la calidad del software, ya que si un programa falla frecuentemente en su funcionamiento, no importa si el resto de los factores de calidad son aceptables. La fiabilidad del software, a diferencia de otros factores de calidad, puede ser medida o estimada mediante datos históricos o de desarrollo y se puede definir en términos estadísticos. Los primeros trabajos sobre fiabilidad intentaron explotar las matemáticas de la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software. La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al desajuste, que a los fallos debido a defectos del diseño. En el hardware, son más probables los fallos debidos al desgaste físico que los fallos relativos al diseño. Desgraciadamente para el software lo que ocurre es lo contrario. De hecho todos los fallos del software, se producen por problemas de diseño o de implementación; el desajuste no entra en este panorama. Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es el tiempo medio entre fallos (TMEF), donde: TMEF = TMDF + TMDR TMEF: Tiempo Medio Entre Fallos. TMDF: Tiempo Medio De Fallo. TMDR: Tiempo Medio De Reparación. Además de una medida de fiabilidad, debemos obtener una medida de la disponibilidad. La disponibilidad del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado, y se define como: Disponibilidad = [TMDF/(TMDF+TMDR)] x 100% 9
  • 10. La medida de fiabilidad TMEF es igualmente sensible al TMDR que al TMDF. La medida de disponibilidad es algo más sensible al TMDR, una medida indirecta de la facilidad de mantenimiento del software. MODELOS DE CALIDAD DEL SOFTWARE 1. CMMI: Diseñado por el Carnegie Mellon Software Engineering Institute. El CMMI: es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. Los niveles CMMI son 5: • Inicial o Nivel 1: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, los empleados si tienen que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no se sabe que pasara con él. • Nivel 2: Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. • Nivel 3: alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) está definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos. • Nivel 4: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización. • Nivel 5: Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica. 10
  • 11. Ventajas: • Compromiso asegurado. • Automatizar lo más posible las actividades de control y gestión de los procesos de los proyectos. • Comenzar a documentar los procesos implícitos, en la medida de lo posible 0 plantillas en office, implementación de sistemas de gestión. • Utilización de sistemas libres para minimizar los costos de implementación. Desventajas: • Requiere mucho esfuerzo, compromiso de toda la organización. • Comenzar a diseñar y/o documentar procesos, luego desplegarlos y ponerlos en práctica. • Requiere un mínimo de cantidad de personal. • Fuerte inversión económica 2. Norma ISO 9000: Diseñada por la International Organization for Standardization. Norma ISO 9000: es un conjunto de estándares internacionales que se pueden utilizar en el desarrollo de un sistema de gestión de calidad de todas las industrias. Las series de ISO 9000 son un grupo de 5 individuales, pero relacionadas, estándares internacionales de administración de la calidad y aseguramiento de calidad. • ISO 9001:2000 - Sistemas de Gestión de la Calidad – Requisitos. • ISO 9004:2000 - Sistemas de Gestión de la Calidad - Guía de mejoras del funcionamiento. • ISO 9000:2000 contiene las definiciones de los términos que se utilizan en las otras dos normas. Es decir que si alguien necesita conocer qué se entiende por "sistema de gestión de la calidad", "no conformidad", "producto", por ejemplo, debe referirse a esta norma. 11
  • 12. ISO 9000 no es un estándar específico para el desarrollo del software, pero define los principios primordiales que pueden aplicarse. Este describe varios aspectos del proceso de calidad y define que estándares y procedimientos deben existir en una organización, la definición del proceso debe incluir una descripción de la documentación requerida, donde se demuestre que los procesos definidos han sido seguidos desde el desarrollo del producto. Ince (Ince 1994) y Oskarsson y Glass (Oskarsson y Glass 1995), dan detalles de como se puede utilizar el estándar para desarrollar procesos de gestión de calidad del software. El estándar ISO 9001 ha sido adoptado por mas de 130 países para su uso y se esta convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software Para la industria del software los estándares relevantes son: • ISO 9001. Quality systems – model for quality assuance and servicing. Este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño. • ISO 9000-3. Guidelines for application of ISO 9001 to the Develoment, supply and Maintainance of software. Este es un documento especifico que interpreta el ISO 9001 para el desarrollador del software • ISO 9004-2. Quality Management and quality system element. Este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios. 3. ISO 15504: Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Norma ISO 1554: Es un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Características: • Establece un marco para métodos de evaluación, no es un método o modelo en sí. 12
  • 13. • Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. • Está alineado con el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. • Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504. Arquitectura Norma ISO 15504. La norma tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Desde la dimensión de proceso agrupa a los procesos en tres grupos que contienen cinco categorías de acuerdo al tipo de actividad: 1. Procesos Primarios: 2. Procesos de Soporte: 3. Procesos Organizacionales: Para todos los procesos se definen los componentes: Identificador, Nombre, Tipo, Propósito, Salidas y Notas. Desde la dimensión de capacidad el modelo define una escala de 6 niveles para determinar la capacidad de cualquier proceso: • Nivel 0: Incompleto. • Nivel 1: Realizado. • Nivel 2: Gestionado. • Nivel 3: Establecido. • Nivel 4: Predecible. • Nivel 5: En optimización. 13
  • 14. PLAN SQA Un plan SQA proporciona un mapa para institucionalizar la garantía de la calidad de SW en una empresa. Este plan sirve como modelo para actividades de SQA instituidas para cada proyecto de software que desarrolle la empresa. Según IEEE un plan de calidad SQA debe contemplar: • Un propósito (Por qué se hace?). • Un alcance (Qué áreas cubre?) • Unos documentos referentes (requeridos). • Unos estándares a usar. • Una gestión del plan. (Doc. Del proyecto, modelos, Doc. Técnicos, Doc. De Usuarios). • Estándares, prácticas y convenciones, utilizados en procesos de SW. • Pruebas (plan de pruebas de software, problemas y acciones tomadas). • Herramientas y métodos que soportan tareas y actividades SQA. CONFIGURACIÓN DE PROYECTO DE SOFTWARE Uno de los aspectos fundamentales del software con respecto a otro tipo de producto de ingeniería, es que es sabido que el software está en continuo cambio bien sea para evolucionar su funcionalidad o para reparar un determinado defecto, entre otros posibles escenarios de cambio. La gestión de configuración del software mediante la identificación y control de cambios permite garantizar la correcta ejecución del cambio e informar del cambio a los afectados. Podemos definir que la gestión de la configuración de software es el proceso que tendrá lugar a lo largo del proyecto a desarrollar, es decir desde que se inicia el proyecto hasta que el software se deja de comercializar, en este lapso de tiempo se realizará un estudio con el fin de controlar los cambios acaecidos, así como aprobar dichos cambios y 14
  • 15. asegurar que los integrantes/participantes del proyecto disponen de las versiones adecuadas de los productos generados durante el proyecto. El proceso de Gestión de la Configuración tiene lugar durante toda la vida del proyecto y por ello se divide en una serie de fases las cuales están asociadas a las distintas partes o fases del proyecto. • Gestión del Código Fuente: Se analiza la estructura del código fuente del proyecto, los roles, la plataforma donde es alojado el código, etc... • Gestión de la Construcción: Se indica las herramientas utilizadas para la construcción del proyecto, cómo se utilizan, etc... • Gestión de los Entregables: Qué entregables se contemplan en el proyecto y cómo se realiza su entrega. Estos son el propio código fuente, liberado como entregable con cada nueva versión, y la documentación que no sigue una política establecida más allá de su dependencia con el código fuente. • Gestión del Despliegue: Como se realiza el despliegue, que herramientas se utiliza, cuando se realiza. • Gestión de Incidencias y Depuración: Se explica el proceso de reporte de incidencias y cómo se realiza la depuración. • Gestión de la Variabilidad • Integración y Despliegue Continuos: A modo de facilitar las tareas de pruebas se recurre a herramientas de integración y despliegue continuo. Estas herramientas nos proporciona mecanismo para recopilar los distintos proyectos involucrados, dependencias, incorporar los cambios realizados, etc. Una vez reunido se construye el proyecto y ejecutan las pruebas incorporadas, si pasa las pruebas se puede publicar de manera automática o desplegar directamente en un servidor. • Las Pruebas: Se describen los tipos de pruebas que se realizan en el proyecto y el procedimiento para ejecutarlas. • Mapa de Herramientas: Se describen las herramientas necesarias para trabajar con el proyecto en las diferentes actividades de la Gestión de la Configuración, y la relación que tienen entre ellas. 15
  • 16. El estándar ISO/IEC 12207 ([ISO 12207]) para procesos del ciclo de vida del software, establece el proceso de gestión de configuración como uno de los procesos de soporte del ciclo de vida. Un proceso de soporte “apoya” a otro proceso como una parte integral, con un propósito distinto, y contribuye al éxito y a la calidad del proyecto de software. Este proceso consiste de las siguientes actividades: • Implementación del Proceso: Se desarrolla un plan de gestión de configuración que describe las actividades de gestión de configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado. • Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto. • Control de la Configuración: Se identifican y registran las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado. • Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base. • Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada). • Gestión de actualización y distribución: Se controla formalmente la actualización y distribución de los productos de software. USO DE HERRAMIENTAS Estas herramientas son las denominadas «Siete Herramientas del Control de la Calidad o herramientas estadísticas básicas, y abarcan la hoja de recogida de datos, el histograma, el diagrama de Pareto, el diagrama de espina, la estratificación, el diagrama de correlación y los gráficos de control. 16
  • 17. En general, estas herramientas pueden ser utilizadas para detectar y solucionar la inmensa mayoría de los problemas que surgen en la organización. Según Ishikawa (1994), aplicadas e utilizadas correctamente permiten la resolución del 95 % de los problemas de los puestos de trabajo, quedando sólo un 5 % de los casos en que se necesitan otras herramientas con utilización de métodos estadísticos mucho más complejos y avanzados. Funciones Herramientas Fundamentos .- Recoger los datos .- Interpretar los datos Hoja recogida de datos, Histogramas Pilares .- Estudiar las relaciones causa – efecto. .-Fija Prioridades Diagramas de espina y de pareto. Instrumentos Auxiliares .- Estratificar los datos .- Determinar las correlaciones .- Determinar si un proceso esta bajo control Diagrama de correlación, grafico de control y estratificar Las siete herramientas clásicas de control y gestión de la calidad: 1. Hoja de recogida de datos: La hoja de recogida de datos sirve para recoger los datos necesarios y poder realizar un posterior análisis de éstos. Su principal utilidad proviene del empleo de datos objetivos a la hora de examinar un fenómeno determinado. Como sirven de base para adoptar decisiones, es importante que el método de recogida y el análisis de los propios datos garanticen una interpretación correcta del fenómeno estudiado. 2. Histograma: Los histogramas son diagramas de barras que muestran el grado y la naturaleza de variación dentro del rendimiento de un proceso. El histograma muestra la distribución de frecuencias de un conjunto de valores mediante la representación con barras. 3. El diagrama de Pareto: El diagrama de Pareto es una herramienta de representación gráfica que identifica los problemas más importantes, en función de su frecuencia de ocurrencia o coste (dinero, tiempo), y permite establecer las prioridades de intervención. 4. El diagrama de espina: El diagrama de espina se utiliza para recoger de manera gráfica todas las posibles causas de un problema o identificar los aspectos necesarios para alcanzar un determinado objetivo (efecto). 17
  • 18. 5. El diagrama de correlación: El diagrama de correlación o diagrama de dispersión sirve para determinar si existe relación entre dos variables, normalmente de causa y efecto. 6. La estratificación: La estratificación consiste en dividir los datos recogidos en grupos homogéneos para facilitar una mejor comprensión del fenómeno estudiado. A cada grupo homogéneo se lo denomina estrato. Esta técnica permite investigar los aspectos más significativos o las áreas más importantes donde es necesario centrar la atención. 7. Gráfico de control: El gráfico de control es una herramienta gráfica que se utiliza para medir la variabilidad de un proceso. Consiste en valorar si el proceso está bajo control o fuera de control en función de unos límites de control estadísticos calculados. 18
  • 19. CONCLUSIONES La calidad del software no se puede medir de una manera correcta u objetiva debido a su naturaleza, sin embargo la certificación se le da a los procesos, técnicos y/o metodologías que permiten diseñar, documentar y desarrollar el software, la correcta consecución de los mismos garantizaría un buen software. Por otro lado la gestión de calidad del software es una actividad de protección que se aplica a cada paso del proceso y que permite señalar si este tiene un escaso número de defectos y si alcanza los estándares requeridos de mantenibilidad, fiabilidad, portabilidad, etc. Dichas actividades comprenden la garantía de la calidad que establecen los estándares para el desarrollo del software, la planificación de la calidad y el control de la calidad que comprueba el software con respecto a los estándares requeridos. La capacidad para garantizar la calidad es la medida de la madurez de la disciplina de la ingeniería, cuando se sigue de forma adecuada esa guía mencionada anteriormente, lo que se consigue es la madurez de la ingeniería del software. BIBLIOGRAFÍA 19
  • 20. Roger S. Pressman, Ingeniería del Software – Un enfoque practico. 5ta edición. Mc Graw Hill, 2002. Ian Sommerville, María Isabel Alfonso Galipienso. Ingeniería del Software. Pearson Educación, 2005. César Camisón; Sonia Cruz; Tomás González, Gestión de la Calidad: Conceptos, Enfoques, Modelos y Sistemas. Pearson Educación, 2006. 20