ASEGURAMIENTO DE CALIDAD. ING. DE SOFTWARE

UNIVERSIDAD TECNOLOGICA DE SANTIAGO

- U T E S A -

ING. DE SOFTWARE II      PROF. LUIS SANTANA

PABEL DIONICIO LOPEZ MENA        1-10-0722

JOAN MANUEL CESPEDES PEÑA        2-11-1424

TAREA 1.- ASEGURAMIENTO DE CALIDAD (SQA)

I.- Fuente: Ing. De Software – Un Enfoque Práctico (Pressman), 5ta. Ed.

1. Elabore un esquema gráfico que contenga los diferentes costes de calidad, sus componentes y un ejemplo de una actividad que se incluya en estos últimos para cada uno

[pic 1]

1. Elabore un esquema gráfico que resuma las actividades de SQA y sus objetivos.

[pic 2]

1. Conteste las preguntas 8.1 – 8.11 y 8.14 – 8.15.

• 8.1 – Al principio del capítulo se señaló que “el control de variación está en el centro del control de calidad”. Como todos los programas que se crean son diferentes unos de otros, ¿Cuáles son las variación que se buscan y cómo se controlan?

Mayormente las variaciones que se buscan son aquellas que hacen diferente un software de algún otro, ya que estos variaran dependiendo de los requerimientos exigidos por el cliente. Por lo tanto se pretende que la variación entre estos sea mínima ya que aumentaría la solidez  y estabilidad entre procesos.

Especialmente estas variaciones pueden controlarse siguiendo estándares establecidos para el desarrollo de software. Un ejemplo de esto sería la norma ISO 9001 que persigue que se cumplan ciertas normas para crear software de calidad.

• 8.2 - ¿Es posible evaluar la calidad del software si el cliente no se pone de acuerdo sobre lo que se supone que ha de hacer?

No, porque mayormente según lo expresado en el libro, la calidad de un software puede medirse por el grado de cumplimiento de los requisitos del cliente, por lo tanto si el cliente no determina lo que ha de hacer, no se podría crear un software que cumpla con los requisitos necesarios para la empresa.

• 8.3 – La calidad y la fiabilidad son conceptos relacionados, pero son fundamentalmente diferentes en varias formas. Discútalas.

En mi opinión la calidad hace referencia a que un producto sale de la empresa hacia el cliente en buenas u óptimas condiciones, pero la fiabilidad se refiere a que un producto determinado permanezca en condiciones óptimas durante un tiempo moderado, o bien, un producto con una mínima taza de fallos durante un tiempo determinado.

• 8.4 - ¿Puede un programa ser correcto y aun así no ser fiable? Explique por qué.

Sí, porque el programa puede ser creado de una manera adecuada, cumpliendo con los mayores requisitos planteados por el cliente, pero este a medida que el cliente le saca provecho puede dar errores y fallas lo cual se traduce en un software no fiable ya que presento una cantidad considerable de errores durante su utilización.

• 8.5 - ¿Puede un programa ser correcto y aun así no exhibir una buena calidad? Explique por qué.

Sí, porque el programa puede ser creado para satisfacer las necesidades del cliente, pero puede darse el caso que no se hayan comprendido bien los requerimientos que debía cumplir el software, entonces no sería un software apto para ese cliente específico y por lo tanto no tendría la calidad adecuada necesaria. Por otra parte, puede darse el caso de que no se hayan realizado las pruebas y revisiones pertinentes lo que concebiría que el software pueda contener errores.

• 8.6 - ¿Por qué a menudo existe fricciones entre un grupo de ingeniería del software y un grupo independiente de garantía de calidad del software? ¿Es esto provechoso?

No es provechoso, ya que muchas veces esto se traduce en re trabajo, lo que implica que se utilice mucho tiempo no planificado en esta actividad. Estos problemas se dan ya que existe muchas veces falta de comunicación entre ambos grupos y por ende tienden a chocar en opiniones y hasta contradecirse.

• 8.7 – Si se le da la responsabilidad de mejorar la calidad del software en su organización. ¿Qué es lo primero que haría? ¿Qué sería lo siguiente?

Lo primero es determinar si el software de mi empresa tiene todos los requerimientos definidos anteriormente, esto se podría observar en la documentación del software. Por tanto si no cumple con estos requerimientos lo que haría sería implementar las solicitudes de usuario o cliente que hacen falta en el software para que se complete.

• 8.8 – Además de los errores, ¿Hay otras características claras del software que impliquen calidad? ¿Cuáles son y cómo se pueden medir directamente?

La fiabilidad y disponibilidad del software. Para saber que tan fiable es un software se hace una medida del Tiempo Medio Entre Fallos (TMEF) a través de la siguiente fórmula: [TME F= TMDF (Tiempo Medio de Fallo) + TMDR (Tiempo Medio de Reparación)]. La disponibilidad se mide con la fórmula siguiente: [TMDF/(TMDF+TMDR)]*100%. Otra característica importante es la seguridad, que se mide haciendo una serie de análisis y modelado para identificar los errores que puedan hacer que el sistema completo se caiga.

• 8.9 – Una revisión técnica formal solo es efectiva si todo el mundo se la prepara por adelantado. ¿Cómo descubriría que uno de los participantes no se le ha preparado? ¿Qué haría si fuera el jefe de revisión?

El participante que no se ha preparado tendría falta de participación una vez iniciado el proceso de revisión, también ese participante podría estar un poco perdido durante la reunión y siempre preguntar en el inicio de la reunión si están preparados. Yo le pediría a esa persona que se retire o si es una persona cuya participación es muy importante, posponer la reunión para más tarde.

• 8.10 – Algunas personas piensan que una RTF debe evaluar el estilo de programación al igual que la corrección. ¿Es una buena idea? ¿Por qué?

Considero que si es necesario porque en una RTF se busca que los proyectos sean más manejables. Incluso si el código está bien organizado, talvez está empleando una clase u otro archivo que haga el proyecto más incómodo de manejar.

• 8.11 – Revise la tabla 8.1 y seleccione las cuatro causas vitales de errores serios y moderados. Sugiera acciones correctoras basándose en la información presentada en otros capítulos.

Graves.

• Especificación incompleta o errónea (EIE). Volver hacer otra reunión TFEA.
• Error en la presentación de datos (ERD). Recurrir a la herramienta CASE.
• Error en la traducción del diseño al lenguaje de programación (TLP).
• Error en la lógica del diseño (ELD).

Moderados.

• Especificación incompleta o errónea (EIE). Volver hacer otra reunión TFEA.
• Mala interpretación de la comunicación del cliente (MCC). Llevar a cabo cuidadosamente la reunión TFEA, donde se definen los objetivos, procesos y restricciones del software.
• Error en la presentación de datos (ERD). Recurrir a la herramienta CASE.
• Prueba incompleta o errónea (PIE).

• 8.14 – El concepto de TMEF del software sigue abierto a debate. ¿Puede pensar en algunas razones para ello?

El TMEF es una herramienta para medir los fallos del sistema, pero no es la más indicada para medir su fiabilidad partiendo de esta. La tasa de fallo varía en cada programa por lo que no es un buen dato para medir la fiabilidad e incluso si se corrigen todos los fallos, no tendrá un gran impacto en la fiabilidad del software. Esto sucede porque el usuario de enfrenta a los fallos, no al número total de ellos. Medir la disponibilidad del software (probabilidad de que funcione bien) es más factible.

• 8.15 – Considere dos sistemas de seguridad crítica que estén controlados por una computadora. Liste al menos tres peligros para cada uno de ellos si se puedan relacionar directamente con los fallos del software.

Un sistema de seguridad para que los empelados accedan a ciertas áreas de la empresa usando su huella digital. Incumplimiento en los estándares de programación (IEP); Pruebas incompletas o errónea (PIE) y Error en la traducción del diseño al lenguaje de programación (TLP). Estos pueden causar el acceso de un empleado no autorizado a una planta, que el sistema le niegue el acceso a todo el mundo por un tiempo indefinido, etc.

Un sistema de alarmas en una casa o negocio. Interfaz del módulo inconsistente (IMI); Pruebas incompletas o erróneas (PIE) y Error en la traducción del diseño al lenguaje de programación (TLP).

...