Trabajo Colaborativo 3 Ingenieria De Software UNAD

TRABAJO COLABORATIVO No. 3

Si Usted es contratado por una compañía de desarrollo de sistemas de información como Ingeniero de Software y le asignan como primera tarea establecer un modelo estándar para control de la calidad del software que la empresa produce:

1. ¿Qué métodos y herramientas establecería para garantizar la calidad del software? Describa y justifique su elección.

Cuando ocurre algún problema con la calidad del producto, debemos investigar para identificar las causas del mismo. Para ello nos sirven los Diagramas de Causa - Efecto, conocidos también como Diagramas de Espina de Pescado por la forma que tienen.

Solución:

Un diagrama de Causa-Efecto es de por si educativo, sirve para que la gente conozca en profundidad el proceso con que trabaja, visualizando con claridad las relaciones entre los efectos y sus causas. Sirve también para guiar las discusiones, al exponer con claridad los orígenes de un problema de calidad y permite encontrar más rápidamente las causas asignables cuando el proceso se aparta de su funcionamiento habitual.

Dentro de la gestión de la calidad del software para garantizarlo también podemos implementar la gestión de la calidad de software (ISO 9000) que consiste en el conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad; como también podríamos implementar la política de calidad (ISO 9000) donde consiste en la directrices y objetivos generales de una organización, relativos a la calidad, tal como se expresan formalmente por la alta dirección.

2. ¿Qué revisiones técnicas formales establecería para garantizar la calidad del software? Describa y justifique su elección.

Solución:

• Describir errores en la función, la lógica o la implementación de cualquier representación de los sistemas de información.

• Verificar que los sistemas bajo revisión alcancen sus requisitos.

• Garantizar que los sistemas han sido representados de acuerdo con ciertos estándares predefinidos.

• Conseguir un sistema desarrollado en forma uniforme.

• Hacer que los proyectos sean más manejables.

También se podría promover la seguridad y continuidad, ya que varias personas se familiarizarán con partes del sistema de información, que de otro modo, no hubieran visto. Es una clase de revisión que incluye recorridos, inspecciones, torneo de revisiones y otras tareas de revisión técnica de los sistemas. Esto se puede llevar a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida. Esta reunión podría apegarse a algunas restricciones como convocándose a la revisión entre tres y cinco personas, preparar todo por adelantado, pero sin que requiera más de dos horas de trabajo a cada persona y por último la duración de la reunión de revisión debe ser menor de dos horas.

Otros aspectos serían que en lugar de revisar un diseño completo, se hicieran inspecciones para cada módulo o grupos de módulos ya que la posibilidad de descubrir errores es mayor. Sería importante y de forma concurrente que el jefe de revisión revise el producto y establezca una agenda para la reunión de revisión.

3. ¿Qué técnicas de prueba del software establecería? Describa y justifique su elección.

Solución:

La técnica de prueba que utilizaría sería es la PRUEBA DE LA CAJA NEGRA porque permiten detectar un funcionamiento incorrecto o incompleto, errores de interface, errores de accesos estructuras de datos externas, problemas de rendimiento, errores de inicio y terminación. Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc.

El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos

...