Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

GARANTÍA DE CALIDAD DE SOFTWARE

No description
by

Anibal Hernández Sierra

on 30 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of GARANTÍA DE CALIDAD DE SOFTWARE

GARANTÍA
DE CALIDAD
DE SOFTWARE DEFINICIÓN CALIDAD CALIDAD DE DISEÑO CONTROL
DE CALIDAD CALIDAD DE CONCORDANCIA COSTO
DE CALIDAD Garantía de calidad de software es una actividad de protección que se aplica a lo largo de todo el proceso del software. La SQA engloba:
Característica o atributo de algo». Como un atributo de un elemento, la calidad se refiere a las características mensurables -cosas que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos. Se refiere a las características que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto grado y se especifican tolerancias más estrictas y niveles más altos de rendimiento, la calidad de diseño de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones. Es el grado de cumplimiento de las especificaciones de diseño durante su realización. Una vez más, cuanto mayor sea el grado de cumplimento, más alto será el nivel de calidad de concordancia.

El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados. incluye todos los costes acarreados en la búsqueda de la calidad o en las actividades relacionadas en la obtención de la calidad. Se realizan estudios sobre el coste de calidad para proporcionar una línea base del coste actual de calidad, para identificar oportunidades de reducir este coste, y para proporcionar una base normalizada de comparación. 1) Un enfoque de gestión de calidad .
2) Tecnología de ingeniería del software efectiva (métodos y herramientas)
3) Revisiones técnicas formales que se aplican durante el proceso del software
4) Una estrategia de prueba multiescalada
5) El control de la documentación del software y de los cambios realizados
6) Un procedimiento que asegure n ajuste a los estándares del desarrollo del software (cuando sea posible) Software Quality Assurance
(Aseguramiento de Calidad de Software) CALIDAD CONTROL
DE CALIDAD Entre los costos de evaluación se incluyen actividades para tener una visión más profunda de-la condición del producto «la primera vez a través de» cada proceso. A continuación se incluyen algunos ejemplos de costos de evaluación: (1)inspección en el proceso y entre procesos.
(2)calibrado y mantenimiento del equipo.
(3)pruebas.
Los costos de calidad se pueden dividir en costos asociados con la prevención, la evaluación y los fallos. Entre los costos de prevención se incluyen: (1)planificación de la calidad,
(2)revisiones técnicas formales,
(3)equipo de pruebas,
(4)formación.
Los costos de fallos son los costos que desaparecerían si no surgieran defectos antes del envío de un producto a los clientes. Estos costes se pueden subdividir en costes de fallos internos y costes de fallos externos. Los internos se producen cuando se detecta un error en el producto antes de su envío. Entre estos se incluyen: (1)retrabajo (revisión),
(2)reparación,
(3)análisis de las modalidades de fallos
Los costos de fallos externos son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. A continuación se incluyen algunos ejemplos de costos de fallos externos: (1)resolución de quejas,
(2)devolución y sustitución de productos,
(3)soporte de línea de ayuda,
(4)trabajo de garantía.
LA TENDENCIA
DE LA
CALIDAD Kuizen y se refiere a un sistema de mejora continua del proceso. El objetivo de Kuizen es desarrollar un proceso (en este caso, proceso del software) que sea visible, repetible y mensurable. Aturimae Hinshitsu. Este paso examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el proceso. Por ejemplo, el proceso de software se puede ver afectado por la alta rotación de personal que ya en sí mismo se ve afectado por reorganizaciones dentro de una compañía. kansei (traducido como «los cinco sentidos») se centra en el usuario del producto (en este caso, software). En esencia, examinando la forma en que el usuario aplica el producto, kunsei conduce a la mejora en el producto mismo, y potencialmente al proceso que lo creó. Finalmente, un paso llamado Miryokuteki Hinshitsu amplía la preocupación de la gestión más allá del producto inmediato. Este es un paso orientado a la gestión que busca la oportunidad en áreas relacionadas que se pueden identificar observando la utilización del producto en el mercado. GARANTÍA DE
CALIDAD DE SOFTWARE
GARANTÍA DE CALIDAD DE SOFTWARE

se define como: Concordancia con los requisitos 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.
La anterior definición sirve para hacer hincapié en tres puntos importantes:

1.Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2.Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
La implicación para el software es que muchos de los que constituyen una organización tienen responsabilidad de garantía de calidad del software -ingenieros de software, jefes de proyectos, clientes, vendedores, y aquellas personas que trabajan dentro de un grupo.

El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.
ALGUNAS PREGUNTAS
QUE HACE LA SON: ¿Satisface de forma adecuada el software?
¿Se ha realizado el desarrollo del software de acuerdo con estándares preestablecidos?
¿Han desempeñado apropiadamente sus papeles las disciplinas técnicas como parte de la actividad de SQA?
El grupo de SQA intenta responder a estas y otras preguntas para asegurar que se mantiene la calidad del software. ACTIVIDADES DE Tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad.
POR EJEMPLO: Establecimiento de un plan de SQA para un proyecto. El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son gobernadas por el plan. El plan identifica: (1)evaluaciones a realizar,
(2)auditorías y revisiones a realizar,
(3)estándares que se pueden aplicar al proyecto,
(4)procedimientos para información y seguimiento de
(5)documentos producidos por el grupo SQA,
(6)realimentación de información proporcionada al
(7)errores,
(8)equipo de proyecto del software.
REVISIONES
DE
SOFTWARE Son un «filtro» para el proceso de ingeniería del software. Esto es, las revisiones se aplican en varios momentos del desarrollo del software y sirven para detectar errores y defectos que puedan así ser eliminados.
el diseño
para la codificación. Freedman y Weinberg argumentan de la siguiente forma la necesidad de revisiones:

1.señalar la necesidad de mejoras en el producto de una sola persona o un equipo;
2.confirmar las partes de un producto en las que no es necesaria o no es deseable una mejora;
3.conseguir un trabajo técnico de una calidad más uniforme, o al menos más predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico.
IMPACTOS DE LOS
DEFECTOS DE SOFTWARE El IEEE Standard Dictionary of Electrical and Electronics
Terms define un defecto como una «anomalía del producto». La definición de «fallo» en el contexto del hardware se puede encontrar en IEEE
Un defecto en un dispositivo de hardware o componente

Dentro del contexto del proceso del software, los términos defecto y fallo son sinónimos. Ambos 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 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.
AMPLIFICACIÓN Y ELIMINACIÓN
DE DEFECTOS Se puede usar un modelo de amplificación de defectos para ilustrar la generación y detección de errores durante los pasos de diseño preliminar, diseño detallado y codificación del proceso de ingeniería del software.
REVISIONES DE
TÉCNICAS FORMALES Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software (y otros). Los objetivos de la RTF son:
(1) descubrir errores en la función, la 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 y (5) hacer que los proyectos sean más manejables.
Además, la RTF sirve como campo de entrenamiento, permitiendo que los ingenieros más jóvenes puedan observar los diferentes enfoques de análisis, diseño e implementación del software.
LA REUNIÓN DE LA REVISIÓN
Independientemente del formato que se elija para la RTF, cualquier reunión de revisión debe acogerse a las siguientes restricciones:
deben convocarse para la revisión (normalmente) entre tres y cinco personas;
* se debe preparar por adelantado, pero sin que requiera más de dos horas de trabajo a cada persona; y la duración de la reunión de revisión debe ser menor de dos horas.
Registro e informe de la revisión
Durante la RTF, uno de los revisores (el registrador)
procede a registrar todas las pegas que vayan surgiendo.
Al final de la reunión de revisión, resume todas las
pegas y genera una lista de sucesos de revisión. Además,
prepara un informe sumario de la revisión técnica
formal. El informe sumario de revisión responde a tres
preguntas:
1. ¿Qué fue revisado?
2. ¿Quién lo revisó?
3. ¿Qué se descubrió y cuáles son las conclusiones? 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.
Conjunto mínimo de directrices para las revisiones técnicas formales:
Revisar el producto, no al productor.
Revisar el producto, no al productor.
Limitar el debate y las impugnaciones.
Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.
Tomar notas escritas
Limitar el número de participantes e insistir en la preparación anticipada.
Desarrollar una lista de comprobación para cada
producto que haya de ser revisado.
Disponer recursos y una agenda para las RTF.
Llevar a cabo un buen entrenamiento de todos los revisores.
Repasar las revisiones anteriores 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 (por ejemplo, no concordancia con la especificación, error de diseño, incumplimiento de los estándares, pobre comunicación con el cliente).
3. Mediante el principio de Pareto (el 80 por 100 de los defectos se pueden encontrar en el 20 por 100 de todas las posibles causas), se aísla el 20 por 100 (los «POCOS vitales»).
4. Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas que han producido los defectos.
FIABILIDAD DE
SOFTWARE La fiabilidad del software puede ser medida o estimada mediante datos históricos o de desarrollo. La fiabilidad del software se define en términos estadísticos como «la probabilidad de operación libre de fallos de un programa de computadora en un entorno determinado y durante un tiempo específico»
Medidas de fiabilidad y de disponibilidad

La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a fallos debidos al desajuste que a los fallos debidos efectos de diseño. En el hardware, son más probables los fallos debidos al desgaste físico (por ejemplo:
de la temperatura, de la corrosión y los fallos relativos al diseño. Seguridad del software
Antes de que se usara software en sistemas críticos de seguridad, normalmente éstos se controlaban mediante dispositivos electrónicos y mecánicos convencionales (no programables).
Las técnicas de seguridad de sistemas se diseñaban para hacer frente a fallos aleatorios en esos dispositivos [no programables]. Los errores humanos de diseño no se consideraban porque se suponía que todos los defectos producidos por los errores humanos se podían evitar o eliminar completamente antes de su distribución y funcionamiento.
PRUEBA DE
ERRORES DE 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 y/o a la temprana corrección de errores en el proceso de fabricación. Denominado poku-yoke (prueba de errores), el concepto de Shingo hacía uso de dispositivos poku-yoke -mecanismos que conducen a la prevención
de un problema de calidad potencial antes de que éste ocurra, o a la rápida detección de problemas de calidad si se han introducido ya, nosotros encontramos dispositivos poka-yoke en nuestra vida cotidiana

Full transcript