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.

...