TAREA DOS “CONCEPTOS DE CALIDAD”

Consultar, analizar, sintetizar y definir con sus propios conceptos

CONCEPTOS DE CALIDAD
CALIDAD.- La calidad es una propiedad medible de un elemento que se puede comparar con estándares conocidos. En cambio en el software ya que es un producto intelectual es más difícil de caracterizar sus atributos.

Pero existen medidas que caracterizan a un software, estas son: Complejidad Ciclomática, Cohesión, Número de puntos de función, líneas de código, etc.

Cuando se examina software surgen 2 tipos de calidad:

Calidad de Diseño: Se refiere a las características que especifican los ingenieros en software para un elemento. Algunos elementos como el grado de materiales, tolerancias y especificaciones de rendimiento contribuyen a la calidad de diseño.

Calidad de concordancia: Es el grado de cumplimiento de las especificaciones de diseño durante su realización osea la implementación.

CONTROL DE CALIDAD.- EL control de Calidad es un conjunto de revisiones y pruebas para que el software cumpla con los requerimientos para los que fue construido.

Las actividades del control de calidad pueden ser manuales, automáticas o una combinación de ambas.

GARANTIA DE CALIDAD.- La garantía de calidad consiste en la auditoria y las funciones de información de la gestión. Su objetivo es proporcionar la gestión para informar los datos necesarios sobre la calidad del producto.

Estos datos mediante la garantía de calidad identifican problemas y la gestión es responsable de solucionar esos problemas de calidad.

COSTE DE CALIDAD.- En el coste de calidad están todos los costes que están en la búsqueda de la calidad o en la obtención de esta. Se hacen estudios del coste de calidad, para establecer una línea bases del coste actual e identificar maneras de reducir el coste.
Los costes de calidad se dividen en: costes de prevención, costes de evaluación, costes de fallos.

Costes de Prevención: En estos se incluyen:
• Planificación de la Calidad
• Revisiones Técnicas Formales
• Equipo de Pruebas
• Formación

Costes de Evaluación: En estos costes están las actividades para tener una visión más profunda del producto.
Costes de Fallos: Son costes que no serían necesarios sino aparecieran defectos antes de la entrega del producto a los clientes. Los costes de fallos se dividen en:
Internos: Estos se dan cuando se detecta un error en el producto antes de la entrega.
Externos:Se dan cuando se detecta un error en el producto una vez entregado al cliente.

TENDENCIA DE LA CALIDAD
La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W. Edwards Deming y se hizo la primera verificación en Japón. Mediante las ideas de Deming, los japoneses han desarrollado un enfoque sistemático para la eliminación de las causas raíz de defectos en productos.

Normalmente se trata de una serie de 4 pasos que son la esencia de cualquier software (Gestión Total de Calidad).

Primer Paso: Este llamado Kuizen y se refiere a un sistema de mejora continua del proceso. Su objetivo es desarrollar un proceso que se visible, repetible y medible.
Segundo Paso: Llamado aturimaehinshitsu es invocado sólo una vez, en este paso examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el proceso.
Tercer Paso: Este se llama Kansei y se centra en el usuario del producto, examina la forma en que el usuario aplica el producto.
Cuarto Paso: Llamado miryokutekihinshitsu y amplía la preocupación de la gestión más allá del producto inmediato.

GARANTÍA DE LA CALIDAD DEL SOFTWARE
Dentro de este punto son importantes 3 aspectos:
1.- Los requisitos del software son base de las métricas de calidad. La discordancia con los requisitos es una falta de calidad.
2.- Los estándares definidos establecen un conjunto de criterios de desarrollo que indican la forma de aplicar la ingeniería del software. Si no se utilizan estos estándares habrá una falta de calidad.
3.- Hay un conjunto de requisitos implícitos que no se mencionan, si no se aplican bien estos requisitos, la calidad no será la adecuada.

Problemas de fondo: La garantía de calidad del software (SQA) es un patrón de acciones planificado y sistemático que se requiere para asegurar la calidad del software.
El grupo de SQA sirve como representación del cliente en casa. Se utiliza el SQA para mirar el software desde el punto de vista del cliente.

Actividades del SQA: Comprende una gran variedad de tareas asociadas con 2 puntos importantes:
– Ingenieros de software realizan trabajo técnico.
– Grupo SQA, planifican garantía de calidad, supervisión, mantenimiento de registros, análisis e informes.

Estos ingenieros afrontan la calidad aplicando métodos técnicos y medidas, realizando revisiones técnicas formales y llevando a cabopruebas de software bien planificadas.
Las reglas del Grupo del SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad.
• Establecimiento de un plan de SQA para un proyecto:
o El plan identifica:
-Evaluaciones a realizar.
-Auditorías y Revisiones a realizar
-Estándares que se pueden aplicar al Proyecto.
-Procedimientos para información y seguimiento de errores.
-Documentos producidos por el grupo SQA.
-Realimentación de información proporcionada al equipo de proyecto del software
• 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 de 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 documenta y se manejan de acuerdo con procedimiento establecido.
• Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

REVISIONES DEL SOFTWARE
Son un filtro para el proceso de ingeniería del software. Las revisiones del software sirven para purificar las actividades de ingeniería del software que suceden como resultado del análisis, el diseño y la codificación.

REVISIONES TECNICAS FORMALES

Es una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software. Los Objetivos de las RTF (Revisiones Técnicas Formales):
• Descubrir errores en la función del software
• Verificar que el software bajo revisión alcanza sus requisitos
• Garantizar que el software ha siso representado de acuerdo con ciertos estándares predefinidos.
• Conseguir un software desarrollado de forma uniforme
• Hacer que los proyectos sean más manejables.

Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si está bien planificada, controlada y atendida.

Reunión de Revisión: La RTF, cualquier revisión debe acogerse a las siguientes restricciones:
– Deben convocarse para la revisión (3-5 personas)
– Debe preparar por adelantado, pero sin que requiera más de 2 horas.
– La duración de la reunión de revisión debe ser menor de 2 horas
El centro de atención de la RTF es un producto de trabajo. El individuo desarrollador del producto informa al jefe del proyecto de que el producto informa al jefe del proyecto de que el producto está terminado.

El jefe del proyecto contacta con un jefe de revisión; este jefe de revisión evalúa la disponibilidad del producto, genera y distribuye copias a los revisores. Cada revisor estará entre una y 2 horas revisando.

El jefe de revisión revisa el producto y establece una agenda para la reunión siguiente.

Registro e informe de la revisión: Los revisores registran todas las pegas que vayan aparecieron. Al final de la reunión, se resumen todas las pegas y genera una lista de sucesos de revisión.
Se elabora un informe sumario de la revisión técnica formal. Con este informe se responde a tres preguntas:
– ¿Qué fue revisado?
– ¿Quién lo reviso?
– ¿Qué se descubrió y cuáles son las conclusiones?
Es importante establecer un procedimiento de seguimiento que asegure que los puntos de la lista de sucesos son corregidos adecuadamente.Un enfoque consiste en asignar la responsabilidad del seguimiento al revisor jefe.

Directrices para la revisión: Se deben establecer de antemano directrices para conducir las revisiones técnicas formales, distribuyéndolas después entre los revisores para ser consensuadas y, finalmente seguidas.
El conjunto mínimo de directrices para las revisiones técnicas formales:
1. Revisar el producto, no al productor
2. Fijar una agenda y mantenerla.
3. Limitar el debate y las impugnaciones
4. Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.
5. Tomar notas escritas
6. Limitar el número de participantes e insistir en la preparación anticipada
7. Desarrollar una lista de comprobación para cada producto que hayade ser revisado.
8. Disponer recursos y una agenda para las RTF
9. Llevar a cabo un buen entrenamiento de todos los revisores
10. Repasar las revisiones anteriores.

FIABILIDAD DEL SOFTWARE
La fiabilidad de un programa de computador es un elemento importante de su calidad general. Esta fiabilidad puede ser medida o estimada mediante datos históricos o desarrollo.
La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa en un entorno determinado y durante un tiempo específico.
El falloes cualquier falta de concordancia con los requisitos del software. Los fallos pueden ser simplemente desconcertantes o ser catastróficos.

La corrección de un fallo puede llevar a encontrar nuevos errores que a la final lleven a mas fallos.

Medidas de fiabilidad y de disponibilidad: La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al desgaste físico. Para los fallos del software, se producen por problemas de diseño o de implementación.
Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es el tiempo medio entre fallos (TMEF), donde:
TMEF= TMDF + TMDR
TMDF: Tiempo Medio de Fallo
TMDR: Tiempo Medio de Reparación

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)]*100%

Seguridad del Software: Cuando se utiliza el software como parte del sistema de control, la complejidad puede aumentar en un orden de magnitud o más.

La seguridad del software es una actividad de garantía de calidad del software se centra en la identificación y evaluación de los riesgos potenciales que pueden producir un impacto negativo en el software y hacer que falle el sistema completo.

La seguridad del software, se puede dirigir un proceso de análisis y modelado. Inicialmente, se identifican los riesgos y se clasifican por su importancia y su grado de riesgo. Una vez identificados y analizados los riesgos, se pueden especificar los requisitos relacionados con la seguridad para el software.

Fiabilidad y Seguridad no son lo mismo:
• La fiabilidad del software utiliza el análisis estadístico para determinar la probabilidad de que pueda ocurrir un fallo de software.
• La seguridad del software examina los modos según los cuáles los fallos producen condiciones que pueden llevar a accidente.

PRUEBA DE ERRORES PARA SOFTWARE
En los años sesenta, un ingeniero industrial Japonés Shigeo Shingo que trabajaba en Toyota, desarrolló una técnica de garantía de calidad que conducía a la prevención o corrección temprana de errores en el proceso de fabricación llamado poku – yoke (Prueba de errores).

En la vida cotidiana hay muchos dispositivos de poku –yoke. Estos dispositivos presentan un conjunto de características comunes:
• Es simple y barato. Si es complicado y caro no es recomendable en cuanto a costo.
• Es parte del proceso, esto es, el dispositivo poku – yoke, está integrado en una actividad de ingeniería.
• Esta localizado cerca de la tarea del proceso donde están ocurriendo los errores.

El poku – yoke fue originalmente desarrollado por su uso en control de calidad cero para el hardware fabricado, puede ser adaptado para su uso en ingeniería del software.

ESTANDAR DE CALIDAD ISO 9001
El estándar que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software.

Se ha realizado muchos documentos que relacionan el estándar con la industria del software. Para la industria del software los estándares relevantes son:
ISO 9001: Quality Systems Model For Quality Assurance in Design, Development, Production, Installation and Servicing.Estees un estandar 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 of the development, Supply and Maintainante of software.Es un documento específico que interpreta el ISO 9001 para el desarrollador de software.
ISO 9004-2: QualityManagement and QualitySystemElements – Part 2 – Este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

Los requisitos se agrupan bajo 20 títulos:
• Responsabilidad de la gestión
• Inspección, medición y equipo de pruebas
• Sistema de Calidad
• Inspección y estado de pruebas
• Revisión de Contrato
• Acción correctiva
• Control de diseño
• Control de producto no aceptado
• Control de documento tratamiento, almacenamiento, empaquetamiento y entrega
• Compras
• Producto proporcionado al comprador
• Registros de calidad
• Identificación y posibilidad de seguimiento del producto
• Auditorías internas de Calidad.
• Formación
• Control del proceso
• Servicios
• Inspección y estado de prueba
• Técnicas estadísticas.

Esta entrada fue publicada en Sin categoría. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s