Tracol Ingeniria

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

UNAD

TRABAJO COLABORATIVO 3

INGENIERÍA DE SOFTWARE

CODIGO 301404

JAIRO MARTÍNEZ BANDA

TUTOR

DIEGO ARMANDO PERDOMO PERDOMO

CÓDIGO 1078776038

VI SEMESTRE

VIERNES 27 DE MAYO DE 2011

INTRODUCCIÓN

En el presente trabajo colaborativo se estudiarán las temáticas vistas en la tercera unidad del módulo de ingeniería de software profundizando en temas como evaluación y mejoramiento de software, directrices de la reunión técnica formal y la prueba de validación. La metodología a seguir consiste en discutir con los compañeros las respuestas dadas a las preguntas planteadas y asignando roles a cada uno de los participantes para construir de manera dinámica el informe final.

La prueba del software contabiliza el mayor porcentaje del esfuerzo técnico del proceso de desarrollo de software. Todavía estamos comenzando a comprender las sutilezas de la planificación sistemática de la prueba, de su ejecución y de su control.

El objetivo de la prueba de software es descubrir errores. Para conseguir este objetivo, se planifica y se ejecutan una serie de pasos; pruebas de unidad, de integración, de validación y del sistema. Las pruebas de unidad y de integración se centran en la verificación funcional de cada módulo y en la incorporación de los módulos en una estructura de programa. La prueba de validación demuestra el seguimiento de los requisitos del software y la prueba del sistema valida el software una vez que se ha incorporado en un sistema superior.

Cada paso de prueba se lleva a cabo mediante una serie de técnicas sistemáticas de prueba que ayudan en el diseño de casos de prueba. Con cada paso de prueba se amplía el nivel de abstracción con el que se considera el software.

DESARROLLO DE ACTIVIDADES

1. ¿Es posible evaluar la calidad del software si el cliente no se pone de acuerdo sobre lo que se supone que ha de hacer? Justifique su respuesta y argumente.

De acuerdo a la terminología de la IEEE, la calidad de un sistema, componente o proceso de desarrollo de software, se obtiene en función del cumplimiento de los requerimientos iniciales especificados por el cliente o usuario final.

Hay varios enfoques que pueden hacerse sobre el proceso de desarrollo de software el del cliente y el del diseñador son los dos más típicos y la elección de una u otra perspectiva tiene un efecto muy grande sobre los análisis que se llevan a cabo. Por ejemplo, si un cierto proceso como una revisión de requisitos está siendo analizada con respecto al coste, la perspectiva del diseñador, es la del que desea reducir el coste del proceso en términos de hacerlo más eficiente en cuanto a la detección de errores; sin embargo, si después examinamos el mismo propósito pero desde el punto de vista del cliente, concretamente sobre si su personal puede emplear o no una gran cantidad de tiempo en dichas revisiones, entonces la perspectiva podría involucrar el plantearse un uso más eficiente de dicho tiempo empleado en las revisiones.

Ambas perspectivas son válidas a veces se solapan y a veces son antitéticas existe, por ejemplo, una necesidad natural en el diseñador de maximizar el beneficio a la vez que el objetivo del cliente es la corrección máxima del producto y la entrega dentro del plazo. Un punto importante a recalcar es que del examen de la perspectiva del producto, el desarrollador está en una mejor posición para evaluar un proceso de software y un producto de software y también la mejora de los mismos.

2. 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?

El primer paso se llama 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.

El segundo paso, invocado sólo una vez que se ha alcanzado kuizen, se llama 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. Puede ser que una estructura organizativa estable haga mucho para mejorar la calidad del software. Aturimue hinshitsu llevaría a la gestión a sugerir cambios en la forma en que ocurre la reorganización.

Mientras que los dos primeros pasos se centran en el proceso, el paso siguiente llamado 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. En el mundo del software, miwokuteki hinshitsu se podría ver como un intento de detectar productos nuevos y beneficiosos, o aplicaciones que sean una extensión de un sistema ya existente basado en computadora.

3. Una reunión de revisión técnica formal sólo es efectiva si todo el mundo se prepara por adelantado. ¿Cómo descubriría que uno de los participantes no se ha preparado? ¿Qué haría si fuera el jefe de divisió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. A menudo, una revisión incontrolada puede ser peor que no hacer ningún tipo de revisión. A continuación se muestra un conjunto mínimo de directrices para las revisiones técnicas formales:

• Revisar el producto, no al productor. Una RTF involucra gente y egos. Conducida adecuadamente, la RTF debe llevar a todos los participantes a un sentimiento agradable de estar cumpliendo su deber. Si se lleva a cabo incorrectamente,

...