jueves, 5 de febrero de 2015

Pruebas de integración y pruebas de sistema

Introducción

El siguiente paso después de hacer pruebas unitarias (pruebas de caja negra y caja blanca) es hacer pruebas de integración, que es correr y testear todos los módulos en grupo y no individualmente como se hacía anteriormente. Luego se procede a realizar las pruebas de sistema, que consisten en verificar que todo el programa se ejecute correctamente y además que se cumpla lo establecido en la documentación.

Desarrollo


Pruebas de integración

Las pruebas de integración es la fase en pruebas de software en el que los módulos de software individuales se combinan y se ensayaron como un grupo. Se produce después de que las pruebas unitarias y antes de las pruebas de validación. Las pruebas de integración buscan probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto.

Este tipo de pruebas es útil para ver como se comunican los servlets con las páginas de HTML, por ejemplo.

Hay diferentes tipos de pruebas de integración, pero sólo haremos énfasis en 2 de ellos:

  • Big Bang: En este enfoque, todos o la mayoría de los módulos desarrollados están acoplados juntos para formar un sistema de software completa o la mayor parte del sistema y luego se usa para las pruebas de integración.
  • De abajo hacia arriba y de arriba hacia abajo: En este enfoque, los componentes de más bajo nivel se prueban primero, después se utiliza para facilitar la prueba de los componentes de más alto nivel. El proceso se repite hasta que se prueba el componente en la parte superior de la jerarquía.

Pruebas de sistema

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la intefración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de los sistemas de información con los que se comunica.

Siempre tienen como guía los requerimientos establecidos por el cliente y se busca analizar si los satisfacen, tanto en los requerimientos positivos (qué se deseaba que haga) como en las limitaciones (qué se deseaba que no hiciera).

Las pruebas realizadas por el desarrollador a veces se dividen en alfa y beta. Las primeras se realizan en las instalaciones del desarrollador, mientras que las segundas se efectúan en las instalaciones del cliente, pero bajo control del desarrollador. Las pruebas que realiza el cliente por su cuenta se conocen a veces como pruebas de aceptación.

Para realizar las pruebas de sistema pueden prepararse los casos de prueba de forma similar a las pruebas de integración, guiándose por los casos de uso, pero es más común que las pruebas las inicie un operador humano.

Conclusiones

Como hemos visto, la fase de pruebas de integración y pruebas de sistema son las más importantes ya que en ellas se prueban todos los módulos juntos y se da la primera impresión de cómo se ejecutará el proyecto en su versión final. Es de suma importancia hacer estas pruebas antes de presentar la primera versión al cliente porque, en la posterior fase de pruebas que es la de aceptación, el usuario sólo verifica si el programa se ejecuta correctamente. Ahí ya no interviene en gran medida el tester.

Bibliografía


Gutiérrez, J. (2013). Introducción al proceso de pruebas. febrero 5, 2015, Sitio web: http://www.lsi.us.es/~javierj/cursos_ficheros/02.SR.pdf

González, J. M. (2012). Guía mínima de prueba de software orientado a objetos. febrero 5, 2015, Sitio web:http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Integracion.pdf

Hernández, J. (2011). Ingeniería del software, febrero 5, 2015, Sitio web: http://ocw.uc3m.es/ingenieria-informatica/ingeniera-del-software-iii/materialclase/ISIII_09_PRUE.pdf

Torres, C (2011). Pruebas. febrero 5, 2015, Sitio web: http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/torres_c_fr/capitulo7.pdf

viernes, 16 de enero de 2015

Diagrama de flujo y grafo

Diagrama de flujo




Grafo



Posibles caminos:
  • Inicio-P1-P2-Fin
  • Inicio-P1-P3-Fin
  • Inicio-P4-Fin
  • Inicio-P4-P5-Fin
  • Inicio-P4-P6-Fin

Pruebas de caja blanca y de caja negra

Introducción

En esta entrada se definirán dos tipos de pruebas: las pruebas de caja blanca y de caja negra. Se enlistarán sus principales características, funciones, así como para qué nos sirven cada una de ellas.

Desarrollo


Pruebas de caja blanca

Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones.

Lo que se hace es escoger distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. Su objetivo es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo) aunque también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

Las principales técnicas de diseño de pruebas de caja blanca son:
  • Pruebas de flujo de control
  • Pruebas de flujo de datos
  • Pruebas de bifurcación
  • Pruebas de caminos básicos
Pruebas de caja negra

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas ignoramos la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

La prueba de caja negra no sustituye a la prueba de caja blanca, sino es un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la caja blanca.

Con este tipo de pruebas podemos detectar:
  • Funciones incorrectas o ausentes.
  • Errores de interfaz
  • Errores en estructuras de datos o en accesos a las bases de datos externas.
  • Errores de rendimiento.
  • Errores de inicialización y terminación. 
Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la función se está desempeñando correctamente por el sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y contrastar con la especificación.

Conclusiones

Cuando estamos creando un proyecto, una fase muy importante es la fase de pruebas. Su objetivo es encontrar los posibles errores que podamos encontrar en nuestro software. Por eso es indispensable saber qué tipos de pruebas hay. Los dos más importantes son los de caja blanca y los de caja negra. En el primero, podemos ver cómo se procesan los datos y en el segundo sólo los enfocamos en las entradas y las salidas de los datos.

Bibliografía


Carabati, M. (2013). Pruebas de caja negra y caja blanca. enero 16, 2015, Sitio web: https://prezi.com/sjwfwmix7slk/pruebas-de-caja-negra-y-caja-blanca/

Torres, M. (2011). Técnicas de prueba. enero 16, 2015, Sitio web: http://indalog.ual.es/mtorres/LP/Prueba.pdf

Montes, L. (2010). Casos de prueba. Caja blanca, Sitio web: http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.2%20prb-cal-mant.pdf

domingo, 31 de agosto de 2014

Norma de calidad ISO 9126

Introducción

En esta entrada se describirá lo que es calidad, y cómo ésta influye en la creación de un sistema. Asímismo, se hará mención de la norma de calidad ISO 9125 con todas sus características y sus subcaracterísticas

Desarrollo


Calidad

Existen varias definiciones de "calidad". Una de ellas es que es el conjunto de características de una entidad, que permiten satifacer con necesidades establecidas. Otra menciona que calidad se refiere al grado en el que un conjunto de características que cumple con requisitos. Estas 2 definiciones tienen 2 cuestiones en común: una de ellas es que calidad es un conjunto de normas, y la otra es que son establecidas para cumplir con ciertos requisitos o necesidades para ofrecer un producto con la mejor calidad posible.

Norma de calidad ISO 9126

Antes de pasar a este tema, primero debemos definir lo que es una norma de calidad. Una norma de calidad es un conjunto de estándares que tienen como objetivo conseguir un grado óptimo de orden en la calidad de un producto. Estas normas, en su gran mayoría, son internacionales, es decir, que se aplican en cualquier parte del mundo.

Ahora, sabiendo esto, podemos hablar de la norma ISO 9126. El ISO 9126 es un estándar internacional que se aplica en la industria del software. Fue desarrollado en 1991 y su principal objetivo es proporcionar un esquema para la evaluación de la calidad de un sistema informático.

En esta norma, para cumplir el estado óptimo de calidad, se proponen 6 características con el que todo software debe cumplir.

Funcionalidad

En este apartado están el conjunto de atributos que permiten saber si un software maneja de forma adecuada el conjunto de funciones que satisfagan las necesidad para las cuales fue diseñado, es decir, que cumpla con lo establecido en los requisitos.
  • Adecuación - Presencia de un conjunto de funciones para tareas especificas.
  • Exactitud - Disposición de resultados correctos.
  • Interoperabilidad -Habilidad para la interacción con sistemas especificados.
  • Seguridad - Habilidad para prevenir acceso no autorizado a programas y datos, ya sea accidental o deliberado.
  • Cumplimiento funcional - Capacidad del software para apegarse a normas relacionadas con la funcionalidad.
Confiabilidad

Aquí se refiere a la capacidad del software para mantener su integridad bajo condiciones normales en un cierto periodo de tiempo.
  • Madurez - La frecuencia de falla por fallas en el software.
  • Recuperabilidad - Capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectados en caso de falla.
  • Tolerancia a fallos - Habilidad para mantener un nivel especificado de desempeño en casos de fallas de software.
  • Cumplimiento de fiabilidad - Capacidad del software para apegarse a normas relacionadas con la fiabilidad.
Facilidad de uso (Usabilidad)

En este apartado están el conjunto de atributos que permiten evaluar el esfuerzo necesario que necesita invertir el usuario para poder usar el software.
  • Aprendizaje- Reconocer el concepto lógico y sus aplicaciones.
  • Comprensión - Entender el concepto lógico y sus aplicaciones.
  • Operatividad -Operación y control del software.
  • Atractividad - Que el software le llame la atención al usuario a través de las interfaces.
Eficiencia

En este apartado se ve la relación entre el nivel de funcionamiento del software y la cantidad de recursos usados.
  • Comportamiento en el tiempo - Son los tiempos de respuesta y procesamiento y en las tasas de rendimientos en desempeñar su función.
  • Comportamiento de recursos - Son las cantidades y tipos de recursos necesarios cuando el software lleva a cabo su función bajo ciertas condiciones.
Facilidad de mantenimiento

En este apartado están el conjunto de atributos que permiten saber el esfuerzo necesario para poder modificar el softare, ya sea para corregir errores o para incrementar la funcionalidad.
  • Estabilidad - es evitar comportamientos anormales en el software..
  • Facilidad de análisis - Es el esfuerzo necesario para el diagnóstico de deficiencias o causas de fallos.
  • Facilidad de cambio - Es el esfuerzo necesario para corregir la falla detectada en el punto anterior.
  • Facilidad de pruebas - Es el esfuerzo necesario para validar el software modificado.
Portabilidad

Aquí se ve la capacidad del software para ser transferido de una computadora a otra sin mayor problema.
  • Capacidad de instalación - Es el esfuerzo necesario para instalar el software en un ambiente determinado.
  • Capacidad de reemplazamiento - Que se pueda usar el software en lugar de otro software especificado en el ambiente de dicho software especificado.
  • Adaptabilidad - Que se pueda adaptar a distintos ambientes, en este caso, sistemas operativos.
  • Co-Existencia - Que pueda existir otro software independiente, en un entorno común, compartiendo recursos comunes con el software evaluado.
Conclusiones

La norma de calidad ISO 9126 nos permite llevar un control de calidad en el sistema que estemos desarrollando, ya que, como son normas establecidas e internacionales, nos garantiza que el producto final sea lo que esperamos y que cumpla con los requisitos establecidos. Sin embargo, su cumplimiento es un tanto dificil, ya que estas normas, como cualquier otra, son muy estrictas y se deben cumplir casi a la perfección.

Bibliografía


Cataldi, Z. (2000). Calidad en la industria del software. agosto 31, 2014, de UNLP Sitio web: http://recursosbiblioteca.utp.edu.co/tesisd/textoyanexos/0053L864e_anexo.pdf

Soto, M. (2012). Concepto de calidad. agosto 31, 2014, Sitio web: http://fabetsia.dmpa.upm.es/solo_alumnos/sp2/Tablon_sp2/TransparenciasCALIDAD06.pdf

Fernandez, A. (2010). Normas de calidad. agosto 31, 2014, Sitio web: http://www.apmarin.com/download/691_cal1.pdf

domingo, 24 de agosto de 2014

Ingeniería de Pruebas

Introducción

En esta entrada se describirá lo que es una prueba, en qué consiste, y qué elementos se necesita para realizarla. Así mismo, se definirá la ingeniería de pruebas, los tipos de pruebas de software, y los elementos del ciclo de vida de un software. Todo, con el fin de dar a conocer la importancia de hacer pruebas a la hora de realizar un sistema informático

Desarrollo


¿Qué es una prueba?

Según la Real Academia Española, una prueba consiste en "experimentar las cualidades de alguien o algo". Sin embargo, una definición más apegada a las cuestiones del software sería "una prueba es la dinámica de la verificación del comportamiento de un programa en un conjunto de casos de prueba contra la del comportamiento esperado". Su objetivo es encontrar los posibles fallos de implementación, calidad o usabilidad de un programa.

Para realizar una prueba, necesitamos detectar defectos en el software, verificar la integración adecuada de los componentes y que todos los requisitos se han implementado correctamente para posteriormente asegurar que los defectos encontrados se han corregido.

¿Qué es la ingeniería de pruebas?

Primero, hay que definir qué es la ingeniería. La ingeniería es el arte de aplicar los conocimientos científicos a la invención, perfeccionamiento y utilización de la técnica industrial en todas sus determinaciones. Esto, con el fin de solucionar los diversas problemáticas de la vida diaria.

Ahora, sabiendo esto y lo que es una prueba, podemos definir a la ingeniería de pruebas como el conjunto de conocimientos que se aplican para determinar los fallos en los componentes y en el funcionamiento de un sistema informático.

Es de suma importancia realizar pruebas en el programa que estemos desarrollando, porque esto permite saber si nuestro producto funciona a la perfección, o si se le tiene que cambiar algunas características.

¿Cuáles son los tipos de pruebas que existen?

Hay 2 tipos principales de pruebas. Las de caja blanca, que se centran en los procesos del sistema, es decir, está enfocado en verificar el código fuente. Y las de caja negra consisten en verificar el exterior del sistema y la entrada de los datos, sin importarnos el proceso y la salida de éstos

Sin embargo, existen más tipos de pruebas de software, de los cuales hablaremos más adelante
  • Pruebas Unitarias
  • Pruebas de Aceptación de Usuario
  • Pruebas de Regresión
  • Pruebas Funcionales
  • Pruebas de Integración
  • Pruebas de Estress
  • Pruebas de Calidad de Código
Ciclo de vida de un software

Existen 5 etapas por las que todo sistema informático pasa en su proceso de desarrollo:
  • Análisis: En esta etapa definimos de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, para que así se obtenga la información necesaria y suficiente para diseñar su solución
  • Diseño: Aquí determinamos la estrategia que se va a utilizar para resolver el problema que hemos planteado en la etapa de análisis.
  • Desarrollo: Ya que nos hemos planteado la problemática y cómo la vamos a solucionar, es hora de desarrollar el sistema que satisfaga las necesidades de nuestro cliente. Aquí lo que se hace es escribir el código a la vez de que se diseña la base de datos y las interfaces gráficas
  • Pruebas: Después de desarrollar nuestro sistema, hay que hacerle sus respectivas pruebas, para así comprobar que no hayan errores lógicos o de interfaz.
  • Implementación: Ya que se le han hecho las correspondientes pruebas, es hora de entregar el producto final al cliente. Para esto, debemos estar asegurados de que nuestro sistema funcione a la perfección.


Conclusiones

La ingeniería de pruebas es de mucha utilidad a la hora de realizar nuestro software, ya que nos permite verificar si éste funciona correctamente o se le tiene que modificar algo para lograr lo mencionado. Sin embargo, también es importante seguir correctamente las etapas de desarrollo, ya que, de no hacerlo, podemos desarrollar nuestro producto de una manera muy desordenada e ineficaz.

Bibliografía


Jaramillo, E. (2011). De los problemas a los programas. agosto 24, 2014, de Universidad Nacional de Colombia Sitio web: http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm

Adán, V. (2012). Pruebas de caja negra. agosto 24, 2014, Sitio web: http://www.globetesting.com/2012/08/pruebas-de-caja-negra/

Mejía, F. (2008). Definiciones de ingeniería. agosto 24, 2014, de Escuela de ingeniería de Antioquia Sitio web: http://fluidos.eia.edu.co/lecturas/ingenieria.html

Montes, R. (2013). Pruebas de software. agosto 24, 2014, Sitio web: http://www.ecured.cu/index.php/Pruebas_de_software

viernes, 2 de mayo de 2014

Realidad aumentada y la base de datos

Introducción

En este trabajo se explicará la definición de realidad aumentada y cómo ésta puede cambiar nuestro estilo de vida. Asímismo, se explicará la relación que puede llegar a tener con las bases de datos y cómo esta relación puede facilitarnos la realización de ciertas tareas de la vida diaria.

Desarrollo

La realidad aumentada, podríamos decir, es una mezcla entre lo real y lo virtual. A menudo es confundido con la realidad virtual; sin embargo, es un término muy diferente que diferencia a la realidad aumentada con el hecho de que la realidad virtual se aisla de lo real.

El objetivo de la realidad aumentada es ampliar, mejorar o resaltar la realidad del mundo físico mediante la aplicación de tecnología, por lo general video o imagen.

Actualmente la realidad aumentada está presente en varios aspectos de la vida cotidiana, tales como educación, entretenimiento, navegación y medicina. Por ejemplo, en la arquitectura se puede usar para visualizar un futuro edificio; o en la navegación puede ser usada para simular vuelos o trayectos.

Un proyecto muy conocido que utiliza esta tecnología son los Google Glass. Estos lentes, básicamente, funcionan como un smartphone, con la diferencia de que es controlado mediante acciones de voz (aunque también tiene un sensor que detecta gestos). Actualmente se puede adquirir, con un costo de 1500 dólares (aproximadamente unos 18000 pesos). Sin embargo, debido a la alta demanda, esta venta se hace bajo pedido y sólo en ciertos periodos del año.

Ya explicado esto, podemos comenzar a describir la relación que puede tener la realidad aumentada con las bases de datos. Recordemos, antes que nada, que las bases de datos son aquellas plataformas que almacenan datos y que pueden ser consultados o modificados en cualquier momento.

Como se mencionó anteriormente, la realidad aumentada consiste en mejorar nuestra visión del mundo a través de aplicaciones y piezas de hardware. Estas piezas de software pueden ser una cámara o un sensor de movimiento, por ejemplo.

Sabiendo esto, se puede crear una aplicación que despliegue información acerca de un cierto lugar con tan sólo enfocar la cámara hacia él. Algo así como las aplicaciones que detectan códigos QR, pero sin necesidad de tal. ¿Cómo se obtendría, entonces, esa información? A través de una base de datos, la cual, es usada por la aplicación.

Otra aplicación que se acaba de desarrollar es una de reconocimiento facial que asocia las caras a una base de datos mediante una tecnología de realidad aumentada, tiene un gran potencial para los anunciantes. Sin embargo, esta aplicación podría ser usada para fines maliciosos, ya que detecta cualquier rostro y, además, interfiere en la privacidad de la gente por la obtención de datos personales.

También las bases de datos pueden estar presentes en aplicaciones para navegación. Pongamos un ejemplo. Si combinaramos el uso de los Google Glass y la famosa aplicación Google Maps, sería de muchisima utilidad el resultado, porque podríamos visualizar el camino que debemos tomar para llegar a algún destino sin necesidad de voltear a ver nuestro dispositivo GPS, así como información en tiempo real de las condiciones del camino, el clima, la máxima velocidad permitida, etc.

Conclusión

Como podemos ver, las aplicaciones que implican el uso de una cámara forzosamente dependen de una base de datos, ya que en ellas se almacena la información del objeto al que se esté enfocando. Sin embargo, la implementación de esta tecnología sin la seguridad suficiente, podría ser un gravísimo error ya que, entonces, podríamos obtener datos de cualquier cosa, ya sea domicilio o persona. Es cuestión de esperar, quizás, algunos años para que se perfeccione esta tecnología y pueda ser implementada sin problema alguno,

Referencias

jueves, 10 de abril de 2014

Diccionario de datos

Introducción

Para especificar las tablas de una base de datos usamos un diccionario de datos. Éste nos describe el nombre de los atributos, el tipo de dato que acepta y sus modificaodres (clave primaria, foránea, auto incrementa, etc.). El diccionario de datos sirve para que cualquier persona pueda entender cómo está compuesta nuestra base de datos.

Desarrollo

Base de datos 1 "Seguros"

Base de datos 2 "Agencia"

Base de datos 3 "Partidos"

Base de datos 4 "Fábrica"

Base de datos 5 "Tienda"

Base de datos 6 "Viaje"

Base de datos 7 "Olimpiadas"

Base de datos 8 "Torneo Grand Slam"

Base de datos 9 "Cine"

Base de datos 10 "Muebles"