MARCO TEÓRICO

Bases Teóricas

Calidad del software

     Los profesores de enseñanza secundaria en su libro informática volumen IV plantean "El desarrollo de cualquier proyecto viene limitado por los recursos disponibles. Si dispusiéramos de recursos ilimitados todos los proyectos serian abordables. Sin embargo la realidad nos impone restricciones, por lo que necesitamos producir software de calidad en un tiempo limitado.

Precisemos un poco mas y veamos que elementos debemos incluir para conseguir un software de Calidad:

ü        El software esta sujeto a cambios, por lo que debe estar documentado de modo, de modo que se faciliten los cambios.

ü        Debe ser fiable, es decir tolerante a fallas

ü        Debe ser eficiente, o sea, efectuar su tarea según lo esperado y en un tiempo razonable

ü        Debe tener una interfaz adecuada que facilite la comunicación con el usuario.

     La calidad del software es un concepto que parece intuitivo y, sobre todo, deseable. Todo desarrollados se esmera para que sus productos tengan una alta calidad, pero ¿Cómo podemos medir la calidad de nuestro software?, ¿Qué es la calidad del software?, ¿Cómo podemos aumentar la calidad?

     La calidad del software es un término bastante difícil de definir, es un concepto un poco escurridizo. Cada autor lo enfoca en forma diferente, en general todos coinciden en que no es sólo un factor el que indica la calidad del mismo, sino que es una mezcla de muchos factores.

Se puede considerar que un software es de  calidad si cumple los siguientes objetivos:

1.       Concordancia del software con los requerimientos: el cliente desea que el software satisfaga una serie de requerimientos o metas iniciales, y si ni siquiera alcanzamos estos objetivos, nuestro software carecerá por completo de calidad.

2.       Desarrollo coherente, aplicando correctamente los criterios de de la ingeniería del software: uno de los objetivos de la ingeniería del software es mejorar la calidad. Luego esta claro que debemos seguir una metodología correcta y apropiada a nuestro proyecto, si queremos aumentar la calidad del resultado final.

3.       Desarrollo de requerimientos implícitos al proyecto: siempre existen una serie de requerimientos que nuestro cliente no especifica. Pero son deseables. Por ejemplo que nuestro software sea fácil de mantener, que sea fácil de usar, etc. Si no se alcanzan estos requerimientos nuestro software carecerá de calidad."

Sistema de control de calidad de software

     La enciclopedia en línea wikipedia lo define Un sistema de control de calidad de software es la estructura que organiza evaluaciones, inspecciones, auditorias y revisiones que aseguren que se cumplan las responsabilidades asignadas, se utilicen eficientemente los recursos y se logre el cumplimiento de los objetivos del producto. Tiene la intención de mantener bajo control un proceso y eliminar las causas de los defectos en las diferentes fases del ciclo de vida de un producto.

     Para considerar un software como un producto de alta calidad se deben establecer normas mínimas a cumplir:

ü        Procedimientos en el desarrollo y en el control en cada fase del ciclo de vida del producto.

ü        Estructura organizacional del proyecto.

ü        Tareas y responsabilidades especificas del personal encargado de llevar a cabo las pruebas.

ü        Documentación a preparar para revisar la constancia del producto.

ü        Técnicas para llevar acabo auditoria y pruebas requeridas.

ü        Estándares, normas y especificaciones a usuario.

ü        Criterios de aceptación del producto.

     Las personas encargadas de llevar a cabo el trabajo anterior deberán ser aquellas que conozcan profundamente cada una de las partes del proyecto tanto teóricas como prácticas.

     La calidad debe aplicarse a todos los niveles de la organización, sin embargo es necesario que sea adoptada una estructura organizacional, la cual ayudará a evitar el desperdicio de esfuerzo y de recursos.

Factores que determinan la calidad del software

Cueva Lovelle, Juan Manuel, profesor de la Universidad de Oviedo España, adscrito al Departamento de Informática. En la Conferencia de 21 de Octubre de 1999, llevada a cabo en la Universidad Nacional de la Pampa. Plantea lo siguiente:

Se clasifican en tres grupos:

ü         Operaciones del producto: características operativas

– Corrección (¿Hace lo que se le pide?)

• El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente

– Fiabilidad (¿Lo hace de forma fiable todo el tiempo?)

• El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida

– Eficiencia (¿Qué recursos hardware y software necesito?)

• La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados

– Integridad (¿Puedo controlar su uso?)

• El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado

– Facilidad de uso (¿Es fácil y cómodo de manejar?)

• El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados

ü        Revisión del producto: capacidad para soportar cambios

– Facilidad de mantenimiento (¿Puedo localizar los fallos?)

• El esfuerzo requerido para localizar y reparar errores

– Flexibilidad (¿Puedo añadir nuevas opciones?)

• El esfuerzo requerido para modificar una aplicación en funcionamiento

– Facilidad de prueba (¿Puedo probar todas las opciones?)

• El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos

ü        Transición del producto: adaptabilidad a nuevos entornos

– Portabilidad (¿Podré usarlo en otra máquina?)

• El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo

– Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?)

• Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones

– Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?

• El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas

Métricas para determinar los factores de calidad

Cueva Lovelle, Juan Manuel, profesor de la Universidad de Oviedo España, adscrito al Departamento de Informática. En la Conferencia de 21 de Octubre de 1999, llevada a cabo en la Universidad Nacional de la Pampa. Plantea lo siguiente:

ü        Facilidad de auditoria

ü        Exactitud

ü        Normalización de las comunicaciones

ü        Completitud

ü        Concisión

ü        Consistencia

ü        Estandarización de los datos

ü        Tolerancia de errores

ü        Eficiencia de la ejecución

ü        Facilidad de expansión

ü        Generalidad

ü        Independencia del hardware

ü        Instrumentación

ü        Modularidad

ü        Facilidad de operación

ü        Seguridad

ü        Autodocuemntación

ü        Simplicidad

ü        Independencia del sistema software

ü        Facilidad de traza

ü        Formación

Pruebas de Software

     El Ing. Alexander Oré B.  en su articulo publicado en el site calidad y Software.com las define “El Software testing o como se conoce en español las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la mayoría de  empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad el software testing se ha convertido en una de las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologías.

     En la actualidad el software testing se hace más complicado ya que debe hacer frente a una gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc.

      Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de software testing, la administración y seguimiento de errores, la administración de los casos de prueba, automatización de pruebas etc.”

Modelo de Pruebas

     Weitzenfeld Alfredo (2006, P.41) El modelo de pruebas es el responsable de revisar la calidad del sistema. Este modelo consiste en la validación del sistema o prueba de especificación y la verificación o prueba de resultado. De manera adicional, el modelo de pruebas combina pruebas de unidad y pruebas de integración.

ü        Validación: se prueba si la funcionalidad del sistema corresponde a la especificación del cliente. Se cuestiona si se esta construyendo el sistema "correcto", en contraste con la verificación, donde se cuestiona si se esta haciendo el sistema "correctamente". Durante el diseño e implantación, se revisa es sistema de acuerdo con las especificaciones de los modelos de análisis y requisitos.

ü        Verificación: se prueba si se esta construyendo el sistema "correctamente" la verificación debe comenzar lo antes posible, desde el nivel mas bajo.

Fundamentos de la prueba de software

     Weitzenfeld Alfredo (2006, P.129) La prueba de software representa un factor critico para determinar la calidad del software producido además de representar una revisión final de las especificaciones, del diseño y la codificación

.

     Los fundamentos de la prueba de software definen los objetivos que se consideran esenciales en la prueba de software. El diseño de casos de pruebas se centra en un conjunto de técnicas para la creación de pruebas que sastifagan los objetivos globales de la prueba.

Objetivos de la prueba

Weitzenfeld Alfredo (2006, P.129) Debemos tener en cuenta las siguientes consideraciones

ü        el objetivo de la prueba es descubrir algún error.

ü        Un caso de prueba decimos que es bueno cuando su ejecución conlleva una probabilidad elevada de encontrar un error que hasta el momento no fue detectado.

ü        El éxito de la prueba se mide en función de la capacidad de detectar un error que estaba oculto.

Flujo de información de la prueba

El Flujo de información de la prueba sigue en esquema descrito en la siguiente figura.

     Se aportan dos conjuntos de datos a la entrada: (1) la configuración del software que incluye la especificación de requisitos del software, las especificaciones del diseño lógico y el código fuente; (2) una configuración de prueba que incluye un plan y procedimiento de prueba, alguna herramienta de prueba que se vaya a utilizar, casos de pruebas y resultados que se espera obtener. De esta manera, se llevan a cabo las pruebas y se evalúan los resultados. Es decir, se contrastan los resultados obtenidos de la prueba con los que se esperaban. La depuración comienza cuando se descubre que existe un error. Este proceso de depuración es bastante complicado por tener que localizar la fuente del error. Una vez más, dependiendo de lo modular que haya sido el software construido, la detección del origen del problema será más o menos rápida.

Tipos de Pruebas de Software

    Ralph M. Stair, George W. Reynolds (2000, P.601)  “Se utilizan  varios tipos de pruebas: las de cada uno de los programas: (pruebas unitarias), del sistema de programas completos (pruebas de sistema), de la aplicación con gran volumen de datos (pruebas de volumen), las de todos los sistemas relacionados (pruebas de integración), así como las requeridas por el usuario (pruebas de aceptación) el orden en que se realizan las pruebas, por lo general, estas actividades de pruebas se muestran en la figura 2.

     Las pruebas unitarias se realizan al crear datos de prueba que fuerzan la ejecución de cada instrucción del programa. Además, cada programa se prueba con datos anormales para indagar como maneja los problemas. Las pruebas de sistema requieren verificar conjuntamente todos los programas. Es hasta cierto punto frecuente que la salida de un programa sea la entrada de otro. En tales casos,  las pruebas de sistema garantizan que las salidas puedan usarse como entrada de otro programa del sistema. Las pruebas de volumen garantizan que el sistema considerado como unidad pueda manejar un gran volumen de datos en condiciones de operación normales. Las pruebas de integración sirven para verificar que los nuevos programas puedan interactuar con otras aplicaciones importantes. Además, permiten comprobar que los datos fluyan con eficiencia y sin error a las otras aplicaciones. Por ejemplo, una nueva aplicación de control de inventarios podría requerir la captura de datos de una antigua aplicación de procesamiento de apellidos. Las pruebas de integración se realizan para cerciorarse del flujo uniforme de datos entre las aplicaciones  nuevas y las ya existentes. Por último, las pruebas de aceptación permiten tener la certeza de que el sistema nuevo y modificado funciona según se pretendía. En esta fase se verifican los tiempos de ejecución, cantidad de memoria necesaria, métodos de acceso a disco y otros parámetros. Las pruebas de aceptación garantizan la satisfacción de todos los objetivos de rendimiento definidos para el sistema o aplicación. Hacer que los usuarios participen en las pruebas de aceptación puede ayudar a que comprendan mejor el nuevo sistema e interactúen en forma eficaz con él. Las pruebas de aceptación son la verificación final del sistema antes del arranque.”

     Así mismo La enciclopedia en línea wikipedia las clasifica:

ü        En función de qué conocemos:

–         Pruebas de caja negra: no conocemos la implementación del código, sólo la interfaz. Tan sólo podemos probar dando distintos valores a las entradas y salidas.

–         Pruebas de caja blanca: conocemos el código (la implementación de éste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del código.

ü        Según el grado de automatización:

–         Pruebas manuales: son las que se hacen normalmente al programar o las que ejecuta una persona con la documentación generada durante la codificación (P. ej.- comprobar cómo se visualiza el contenido de una página Web en dos navegadores diferentes).

–         Pruebas automáticas: se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas (P. ej.- verificar un método de ordenación).

ü        En función de qué se prueba:

–         Pruebas unitarias: se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una función, una clase, una librería, etc. En nuestro caso, generalmente hablaremos de una clase como componente de software.

–         Pruebas de integración: consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados. Estas pruebas deben realizarse progresivamente.

–         Pruebas funcionales: sobre el sistema funcionando se comprueba que cumple con la especificación (normalmente a través de los casos de uso).

–         Pruebas de rendimiento: los tres primeros tipos de pruebas de los que ya se ha hablado comprueban la eficacia del sistema. Las pruebas de rendimiento se basan en comprobar que el sistema puede soportar el volumen de carga definido en la especificación, es decir, hay que comprobar la eficiencia (P. ej.- Se ha montado una página Web sobre un servidor y hay que probar qué capacidad tiene estado de aceptar peticiones).

–         Pruebas de aceptación: son las únicas pruebas que son realizadas por los usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo. Podemos distinguir entre dos pruebas:

–         Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una máquina preparada para tal fin.

–         Pruebas beta: las realiza el usuario después de que el equipo de desarrollo les entregue una versión casi definitiva del producto.

Antecedentes de Estudio

Tomando como referencia las opiniones de algunos investigadores en relación al tema en estudio, citamos:

     M. Ing. Diez Eduardo (2003), en su investigación basada en el "ASEGURAMIENTO DE LA CALIDAD EN LA CONSTRUCCIÓN DE SISTEMAS BASADOS EN EL CONOCIMIENTO UN ENFOQUE PRÁCTICO" de la "ESPECIALIZACION EN INGENIERÍA DE SISTEMAS EXPERTOS"  plantea "La función de aseguramiento de la calidad del software (SQA) se debe basar en un planificado y sistemático diseño de acciones y métodos, requeridos para garantizar la calidad del mismo. El alcance de la responsabilidad del aseguramiento de la calidad, en el desarrollo de software, abarca a muchos constituyentes de una organización, tales como ingenieros de software, líderes de proyecto, clientes, comerciales y personas que trabajan dentro del equipo de SQA" así mismo formula algunas interrogantes que serán decisivas en la calidad del software desarrollado "El equipo de SQA debe analizar el software desde diversos puntos de vista, respondiendo a algunas de estas preguntas:

ü        ¿Satisface el software, de forma adecuada los principales factores de calidad?

ü        ¿Se ha realizado el desarrollo del software de acuerdo con estándares preestablecidos?

ü        ¿Se han aplicado las técnicas y métodos apropiados para el desarrollo del software?"

     Prof. Luís Eduardo Mendoza M. (s/f),  profesor de la Universidad Simón Bolívar adscrito al departamento de Procesos y Sistemas, facilitador de la cátedra Sistemas de Información III, plantea "En la definición de la calidad del software pueden estar involucrados aspectos como la ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de especificaciones. Sin embargo, hay algo importante que se debe tener presente: la calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después. Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad."

Definición de Conceptos

MARCO METODOLÓGICO

Tipo de Investigación

     La investigación que se llevara a cabo para solucionar el problema detectado y objeto de estudio en esta fase, se enmarca dentro de un proyecto documental y de campo (descriptivo). Según Pinal Mora, Karla (s/f, P.13) la clasificación de los tipos de investigación es como se plantea a continuación.

Características de la investigación documental:

1.       Se recopila información documental que se encuentra dispersa sobre el tema.

2.       Se realiza una lectura detenida y analítica.

3.       se compara información que ofrecen diferentes fuentes.

4.       Se exponen los antecedentes del tema, se analizan y se elabora un nuevo planteamiento.

5.       se observan y buscan contradicciones, así como puntos en común.

6.       se localizan lagunas de información.

7.       se plantean reflexiones críticas basadas en el pensamiento de diversos autores.

8.       Se presenta un análisis complejo sobre el objeto de estudio, con un nuevo juicio documentado.

Investigación de campo. Características generales

ü        Explorativos. Recopilan información de un tema poco estudiado, realizando investigación de campo.

ü        Descriptivos. Identifican variables, es decir, atributos o conceptos aún no estudiados que serán descritos o medidos. Muestran cómo son, cómo se manifiestan, es que condiciones.

ü        Evaluativos. Parten de un paradigma para evaluar si el fenómeno se apega o no a éste. Construye escalas y plantea consideraciones finales.

ü        Proposititos. Parten de un supuesto, elaboran un diagnostico y terminan con una propuesta especifica para mejorar o solucionar el problema planteado.

ü        Comparativos. Estudian diferencias entre dos o más grupos acerca del fenómeno que se estudia.

ü        Correlaciónales. Miden el grado de relación entre dos o más variables que se supone están conectadas. Proporciona una explicación parcial de los hechos.

ü        Explicativos. Relacionan dos o más variables (las llamadas independientes y dependientes), con el fin de explicar por qué ocurren los fenómenos, es decir, encontrar las causas y las condiciones en que ocurren, posee un nivel de complejidad mayor que los anteriores y exige un nivel de investigación muy riguroso y controlado.

Diseño de Investigación

      El proyecto de investigación que se llevara a cabo en Cantv, específicamente en el área de calidad de pruebas y tiene como objeto garantizar la calidad de CRM peoplespft cliente único, se perfila como un proyecto documental y de campo, basado en la definición del autor citado a continuación.

     Fidias G. Arias (2006, P.27) el diseño de investigación es la estrategia general que adopta el investigador para respondes al problema planteado. Es atención al diseño, la investigación se clasifica en:

ü        Documental: Es un proceso basado en la búsqueda, recuperación, análisis, crítica e interpretación de datos secundarios, es decir, los obtenidos y registrados por otros investigadores en fuentes documentales: impresas, audiovisuales o electrónicas. Como toda investigación el propósito de este diseño es el aporte de nuevos conocimientos.

ü        De campo: Es aquella que consiste en la recolección de datos directamente de los sujetos investigados, o de la realidad donde ocurren los hechos (datos primarios), sin manipular o controla variable alguna, es decir, el investigador obtiene la información pero no altera las condiciones existentes. De allí su carácter de investigación no experimental.

ü        Experimental: Es un proceso que consiste en someter a un grupo de individuos a determinadas condiciones, estímulos o tratamientos (variable independiente), para observar los efectos o reacciones que se producen (variable dependiente).

Universo de Estudio

     La Red Nacional Escolar en su sitio Web define en el año 2005 la población como sigue "Una población está determinada por sus características definitorias. Por lo tanto, el conjunto de elementos que posea esta característica se denomina población o universo. Población es la totalidad del fenómeno a estudiar, donde las unidades de población poseen una característica común, la que se estudia y da origen a los datos de la investigación. Entonces, una población es el conjunto de todas las cosas que concuerdan con una serie determinada de especificaciones. Un censo, por ejemplo, es el recuento de todos los elementos de una población. Desde luego, es de fundamental importancia comenzar el estudio definiendo la población a estudiar. Las poblaciones suelen ser muy numerosas, por lo que es difícil estudiar a todos sus miembros; además de que esto no es posible, no es necesario."

     La empresa Cantv esta dividida en gerencias acordes a sus necesidades de negocio, para el control del desarrollo tecnológico cuenta con la Gerencia de Proyectos mayores, que es la encargada de garantizar la calidad tecnológica da la organización, entra las gerencias adscritas a estas, encontramos la gerencia de proyectos mayores, quien actualmente es la encargada del proyecto CRM Peoplesoft cliente único de Cantv, esta gerencia esta conformada por un aproximado de 125 personas que representan la población en este trabajo de investigación.

La Muestra

     Para el análisis de los datos y la formulación de resultado en todo proyecto de investigación, la muestra seleccionada de la población en estudio debe agruparse al azar tomando en cuenta las características similares. Arkin y Colton. (1995) define muestra de la siguiente manera "Una porción representativa de la población, que permite generalizar los resultados de una investigación. Es la conformación de unidades dentro de un subconjunto que tiene por finalidad integrar las observaciones (sujetos, objetos, situaciones, instituciones u organización o fenómenos), como parte de una población. Su propósito básico es extraer información que resulta imposible estudiar en la población, porque esta incluye la totalidad". (p.78).

     La muestra en esta investigación estará constituida por 20 personas de la gerencia de Integración técnica, de los cuales 11 conforman el equipo de Pruebas da Calidad y el resto serán integrantes del proyecto CRM adscritos a otras unidades que participen directamente con el proyecto CRM Peoplesoft cliente único de Cantv, los mismos serán tomados al azar. 

Instrumentos de Recolección de Información

     Las técnicas e instrumentos a emplear en esta investigación serán las siguientes: análisis de contenido, observación, entrevista y entrevista. Fidias G. Arias (2006, P.27) sintetiza la información en el siguiente cuadro.

Cronograma de actividades

Bibliografía

Garzón Villar Ma Luisa – Cortés, Esteban Leyva, Tinoco, Ignacio Prieto. Informática: Volumen III. Publicado por MAD-Eduforma 2006

Weitzenfeld Alfredo. Ingeniería de software orientada a objetos con Java e Internet. Publicado por Cengage Learning Editores 2006

Ralph M. Stair, George W. Reynolds. Principios de sistemas de información: enfoque administrativo. Publicado por Cengage Learning Editores 2000

Pinal Mora, Karla. APUNTES DE METODOLOGÍA Y REDACCIÓN (Investigación para la Docencia No 9). Publicado por Publicaciones Cruz O., S

Arias Fidias G. El proyecto de investigación introducción a la metodología científica. Publicado por Editorial Episteme 2006

Referencias Electrónicas

http://es.wikipedia.org/wiki/Sistema_de_control_de_calidad_de_software

http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF.

http://www.calidadysoftware.com/testing/introduccion_software_testing.html

http://isg2.pbwiki.com/Pruebas+del+Software

http://www.itba.edu.ar/capis/epg-tesis-y-tf/diez-trabajofinaldeespecialidad.pdf

http://www.rena.edu.ve/cuartaEtapa/metodologia/Tema6.html