domingo, 13 de mayo de 2012

Comparacion de la ISO29119 vs las pruebas en el Software (Pressman cap 17 - cap 18)


En el libro de Roger Pressman en el cap. 17 nos hace entender que las pruebas son una fase importante para demostrar la calidad de nuestro software, para poder presentar la versión final de nuestro producto.
La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
Las pruebas deben ser planificadas, deberían ser realizadas por personas del grupo que se encuentren fuera del grupo de desarrollo. En el capítulo 17 también se habla de la aplicación de las pruebas de caja blanca y caja negra. 
                                                       
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 etc)

Pruebas de caja blanca, en estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de "probarlo todo".

En el capítulo 18 del libro de Roger Pressman se habla sobre las Estrategias de Prueba que se pueden realizar al software, dado que el software consta de partes críticas, se pueden emplear pruebas de unidad, pruebas de integración, pruebas de regresión, pruebas de validación y otras pruebas que nos ayudan a saber que clases de errores presenta nuestro software.

ISO 29119 es el estándar de pruebas de software, contiene una descripción de procesos que están presentes  durante el proceso de testeo.
Se basa en pruebas unitarias, de integración y pruebas de aceptación, las cuales se van realizando en su debido momento. Ofrece una manera de realizar pruebas Iterativas y Evolutiva.

La estructura de ISO/IEC 29119 consta de cuatro partes:
1. Conceptos y Vocabulario
2. Proceso de Pruebas
3. Documentación de Pruebas
4. Técnicas de Prueba

Ahora que sabemos algo general de lo que habla Roger Pressman en sus libros y sobre la ISO29119 podemos realizar una breve comparación.

En el libro de Roger Pressman nos ofrece la parte teorica de como realizar las pruebas, ya sean las pruebas de caja blanca o caja negra, como tambien las estrategias para realizar las pruebas como ser las pruebas unitarias, de integración entre otras, en la ISO 29119 se basa en estrategias de prueba como ser las pruebas unitarias, de integración de aceptación, pero esta vez con un formato de documentación ya que es un estándar para la realización de dichos testing. 

REFERNCIAS:
libro de Roger S. Pressman - Ingeniería del Software_ un enfoque práctico. V Edición
http://www.ati.es/IMG/pdf/Tuya.pdf
 

Ciclos de vida Orientado a Objetos

 

Existen diferentes ciclos de vida Orientado a Objetos, por lo que solo mencionaremos algunos como ser el Ciclo de Vida Fuente, Ciclo de Vida Remolino y Ciclo de Vida de Pinball.
En los ciclos de vida Orientados a Objetos se examina el dominio del problema como un conjunto de objetos que interactúan entre sí.
En las ciclos de vida tradicionales  son una subdivisión  entre funciones que llevan a cabo los programas y datos que se almacenan en bases de datos.

Ciclo de Vida Fuente. 
Claramente está divido en 3 fases, las cuales son
1. Planificación del negocio  
2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades  
  Planificación - Investigación  - Especificación  - Implementación  - Revisión  
3. Entrega

      Además de las 3 fases, existen 2 periodos: 
       1. Crecimiento: Es el tiempo durante el cual se construye el sistema.  
       2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. 

Ciclo de vida Remolino

El modelo remolino es algo similar al modelo cascada, pero en el modelo remolino también se toman en cuenta otros factores, los cuales son:
  1. Amplitud: toma el tamaño de desarrollo.
  2. Profundidad: nivel de abstracción
  3. Madurez: es el grado de compleción, corrección y elegancia.
  4. Alternativas: diferentes soluciones a un problema.
  5. Alcance: tomamos en cuenta los adjetivos del sistema, ya los requisitos van cambiando.
Ciclo de vida Pinball

En este modelo de ciclo de vida, la pelota representa un proyecto  y el jugador es el equipo de desarrollo.
Los pasos en ciclo de vida de pinpall pueden ocurrir de la aiguiente manera :     
       Se procede de forma iterativa a encontrar clases, atributos métodos e interrelaciones y definir   colaboraciones, herencia, agregación y subsistemas.  
       Por último se pasa a la programación, prueba e implementación.

     Conclusion
      En los ciclos de vida orientado a objetos, nos muetra una forma en la cual no existe limitaciones entre una fase y otra, ademas la utilizacion de  bibliotecas de clases y otros componentes reutilizables.

Referencias: