lunes, 14 de mayo de 2012

ANALISIS COMPARATIVO PRESSMAN E ISO/IEC 29119


Roger Humberto Uñoja Chungara

1.       Resumen.-
En los siguientes puntos veremos cómo y en qué forma aportan al proceso de realización de pruebas en el ciclo de vida de desarrollo de un determinado proyecto. Detallando algunas de sus características mas sobresalientes

2.       Ingeniería de software Cap. 17 y 18 (Roger Pressman)
Es interesante como Pressman hace una reflexión sobre el mito de los roles tanto de los que elaboran el software como constructivos, como de los que elaboran y hacen las pruebas como destructivos, desde un punto de vista mas psicológico.

Sin embargo Pressman en este capitulo de pruebas desmiente el mito de que las pruebas son usadas para desprestigiar a aquellos en los cuales es encotrado error. No somos perfectos cometemos errores, el éxito de una prueba es encontrar error que hasta el momento no se había encontrado.

Pressman define varios principios como operatividad y facilidad de pruebas para guiar las mismas. Tambien podemos ver que en ingeniería de software no se está dando la debida importancia que esta actividad debería tener que es de tener la mayor posibilidad de encontrar una falla.
Se pueden ver los diferentes tipos de realización de pruebas, unos con grafos, otros con pruebas en fin, pruebas como la de caja blanca para probar la estructura del control del programa y el de caja negra para validar los requisitos funsionales sin la necesidad de conocer su funcionamiento interno.
En el capitulo 18 podemos que esta vez Pressman pone mas énfasis en la planificación del proceso de realización de las pruebas. Aquí podemos observar claramente la preocupación por probar el funcionamiento interno del programa como lo hace las prueba de unida y de integridad.
Este escenario tendrá que contemplar todos los pasos necesarios para conseguir el fin mayor de la prueba que es de encontrar y repara los defectos de forma ordenada u efectiva.

3.       Norma ISO/IEC 29119.-
El estándar de calidad 29119 provee una guía para el testeo que cubre todos los aspectos del ciclo de vida del software.
-                     Propone una lista de  definiciones, procesos, procedimientos y técnicas de pruebas de software.
-                     Actualmente tiene la representación de más de 18 países y está siendo evaluada la unión mundial de                     profesionales de pruebas de software.
-           
      La estructura 29119 constade las siguiente partes:
-                       Conceptos y vocabularios
-                       Procesos y pruebas
-                       Documentación de pruebas
-                      Técnicas de pruebas


Los modelos de procesos como están formados por 3 procesos:
-          Procesos de la organización
-          Procesos de gestión
-          Procesos fundamentales
En un nivel superior se encuentran los procesos de la organización que son mas bien genéricos y no asi específicos a un determinado proyecto de pruebas. Pero ya tiene definidos las políticas y estrategias aplicables a toda la dirección o a una línea de  proyectos.
Para los proyectos de pruebas se definen los procesos de gestión y fundamentales así como los procesos genéricos para permitir flexibilidad y adaptación a diferentes contextos.

Conclusión.-
Podemos concluir que efectivamente ISO 29119 cubre absolutamente todos los aspectos en la realización de las pruebas desde los procesos que la compone hasta el flujo y orden en que se realizan tanto a nivel macro como específico. Potencialmente adecuado para grandes proyectos.
Pressman hace mas énfasis  a la forma y los tipos en los que se pueden realizar las pruebas tanto en la forma de su desenvolvimiento como conocer el funcionamiento del programa en detalle.
4.       Bibliografia.-
-          GIIS Software Engineering Group - http://giis.uniovi.es/
-          Javier Tuya - http://in2test.lsi.uniovi.es/gt26

-                    ISO/IEC 29119 Software Testing - http://softwaretestingstandard.org/

-          Roger Pressman – Ingenieria de software Un enfoque practico – quinta edicion

viernes, 4 de mayo de 2012

CICLOS DE VIDA ORIENTADOS A OBJETOS VS TRADICIONALES




Roger Humberto Uñoja Chungara


1.                  Resumen.-
Otra de las cuestiones a la hora de desarrollar software además de la elección de los procesos de desarrollo es la elección del ciclo de vida, muy importante ya que no es posible desarrollar software con cualquier ciclo de vida, la mala elección significaría cuantiosas pérdidas de tiempo y dinero a la vez.
A continuación vamos a realizar un análisis de los diferentes ciclos de vida existentes, aquellos que hoy por hoy son considerados obsoletos y aquellos que recientemente están siendo utilizados de acuerdo a los cambios en la forma de crear software y las necesidades del cliente.

Palabras Claves ¾ Ciclo de vida, OO, S.R.D., S.D.D.


2.                  Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así).

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:
  • Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
  • Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
  • Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
  • Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

Ventajas

  • La planificación es sencilla.
  • La calidad del producto resultante es alta.
  • Permite trabajar con personal poco cualificado.

Desventajas

  • Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
  • Si se han cometido errores en una fase es difícil volver atrás.
  • No se tiene el producto hasta el final, esto quiere decir que:
    • Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.
    • El cliente no verá resultados hasta el final, con lo que puede impacientarse.
  • No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).1.1
  • Es comparativamente más lento que los demás y el coste es mayor también.

Tipos de proyectos para los que es adecuado

  • Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería.
  • Se está desarrollando un tipo de producto que no es novedoso.
  • Proyectos complejos que se entienden bien desde el principio.
3.                  Ciclo de vida en V
Este ciclo fue diseñado por Alan Davis, y contiene las mimas etapas que el ciclo cascada puro, A diferencia de aquel, a este se le agregaron dos subetapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño y debubgging.



La ventajas y las desventajas de este modelo son las mismas del ciclo anterior, con el agregado de los controles cruzados entre etapas para lograr una mayor corrección.
Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples (pequeñas transacciones sobre base de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicación de facturación, en la que si bien los procedimientos vistos individualmente son de codificación e interpretación sencilla, la aplicación en su conjunto puede tener matices complicados.

4.                  Modelo de ciclo de vida en espiral

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, etc. 


En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:
  • Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
  • Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
    • Características del producto.
    • Formas de gestionar el proyecto.
  • Restricciones:
    • Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
    • Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
  • Riesgos: Lista de riesgos identificados.
  • Resolución de riesgos: La técnica más usada es la construcción de prototipos.
  • Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
  • Planes: Lo que se va a hacer en la siguiente fase.
  • Compromiso: Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

Ventajas

  • No necesita una definición completa de los requisitos para empezar a funcionar.
  • Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
  • El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
  • El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

Desventajas

  • Es difícil evaluar los riesgos.
  • Necesita de la participación continua por parte del cliente.
  • Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

Dónde es adecuado

  • Sistemas de gran tamaño.
  • Proyectos donde sea importante el factor riesgo.
  • Cuando no sea posible definir al principio todos los requisitos.

5.                  Ciclos de vida orientados a objetos.

Modelo fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto se divide en las fases:
Ø  Planificación del negocio
Ø  Construcción: Es la más importante y se divide a su vez en otras cinco actividades
o    Planificación
o    Investigación
o    Especificación
o    Implementación
o    Revisión
Ø  Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos 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, es decir, con las fases de Planificación del negocio, Construcción y Entrega.
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. La ventaja es que permite un desarrollo solapado e iterativo.


Ciclos de vida Tradicionales
Ciclos de vida orientados a objetos
Todos estos ciclos como el cascada y el modelo en V y el incremental están basados en el análisis y diseño estructurado.
Los ciclos basados en objetos tienen la particularidad de crear componentes que se relacionan entre ellos a través de interfaces.
Al ser de tipo estructurado es muy difícil dividirlos en subsistemas que puedan implementarse independientemente.
Al ser modulares se los puede dividir en mini proyectos de tal forma que no es muy restrictivo a la hora de escoger que proyecto realizar primero o incluso es posible realizarlo simultáneamente.
Los ciclos de vida tradicionales no aseguran un control de riesgos estable y con pocas facilidades de cambios
Reduce la cantidad de riesgos al ser un modelo que siempre ofrece prototipos de forma temprana debido a la facilidad de manipularlo en módulos.

Se hace mucho más difícil la detección y corrección temprana de errores debido a que para realizar una corrección se tiene que evaluar primero el impacto que el mismo tendrá sobre el sistema por su compleja estructura. .
Es mucho más fácil realizar cambios o correcciones debido a su modularidad.
Naturalmente la mayoría de los lenguajes de programación esta orientados a objetos.
Una buena forma de aprender nuevos lenguajes de programación debido a sus librerías de clases y la reutilización de componentes.


Los ciclos tradicionales difícilmente reutilizarían parte de algún proyecto anterior
La ventaja de usar componentes hace posible la reutilización de código para ahorrar tiempo y esfuerzo.



6.                  Conclusion.-
Si bien en un principio el desarrollo de software era orientado a las estructuras se debe a que los clientes estaban educados de forma que se pensaba que el producto se utilizaría por mucho tiempo y por tal motivo se invertiría más dinero y tiempo para realizar todas las tareas del ciclo de vida.
Sin embargo en estos, el mercado para el software es competitivo ya no es suficiente demostrar calidad en el producto, es importante además poder satisfacer las necesidades del cliente con la mayor calidad posible y en el menor tiempo gracias  a las nuevas tecnologías.


Referencias.-
Ø  Ciclo de vida del software – Jose Alvarez y Manuel Ariaz - http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html#tex2html394.

El Ciclo de Vidadel Software(ISG1-ITIG)- Jose Antonio Saenz - http://www.google.com.bo/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CGUQFjAA&url=http%3A%2F%2Fisg1-2009-test.googlecode.com%2Ffiles%2FDLSI-2008-9-ISG1-t2-v0.6.pdf&ei=oUykT4CmD8b1gAfonqTCAQ&usg=AFQjCNEq0L3I6SreXiPtQYAO3RNzkb4rEQ&