lunes, 14 de mayo de 2012

Análisis comparativo entre la Norma ISO 29119 y el libro de Pressman (cap. 17 y 18)

Pressman Capítulos 17 y 18

En el capitulo 17 "Técnicas de prueba del software" se describen las distintas técnicas para realizar las pruebas.

Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación.
La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

Existen distintas técnicas como ser las pruebas de caja blanca (camino básico, estructuras de control), caja negra (basados en grafos, de comparación, de tabla ortogonal), de entornos especializados, arquitecturas y aplicaciones (de interfaz gráfica, de arquitectura).

En el capitulo 18 "Estrategias de pruebas del software" se habla de cual es la mejor manera de realizar las pruebas, siguiendo una estrategias para su ejecucion. 
El proceso de ingeniería del software se puede ver como una espiral. 
También se puede ver la estrategia para la prueba del software en el contexto de la espiral.que se desarrolla de la siguiente manera: 
  • La prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. 
  • La prueba de integración, donde el foco de atención es el diseño y la construcción de la arquitectura del software. 
  • La prueba de validación, donde se validan los requisitos establecidos como parte del análisis de requisitos del software.
  • La prueba del sistema, en la que se prueban como un todo el software y otros elementos del sistema. 
Se habla también del perfil psicológico que implican el desarrollo del software y las pruebas, es decir, los desarrolladores deben ser personas constructivas, mientras por el contrario quienes realizan las pruebas deben ser destructivos. sin embargo esto no quiere decir que los desarrolladores no deban de participar en las pruebas sino todo lo contrario, ellos son los primeros en probar el software y seguidamente un grupo imparcial(GIP) también realiza pruebas.

ISO/IEC 29119

Este estándar, cuya elaboración comenzó en 2007 tiene como objetivo cubrir todo el ciclo de vida de las pruebas de sistemas software incluyendo los aspectos relativos a la organización, gestión, diseño y ejecución de las pruebas.

La norma reemplazará a un número de los actuales estándares IEEE BSI para las pruebas de software:
  • IEEE 829 Documentación de prueba
  • IEEE 1008 Unidad de Pruebas
  • BS 7925-1 Vocabulario de términos en pruebas de software
  • BS 7925-2 de componentes estándar de pruebas de software
Define el vocabulario, los procesos, la documentación, las técnicas y un modelo de evaluación del proceso de pruebas de software que se puede utilizar dentro de cualquier ciclo de desarrollo de software.

La estructura de ISO/IEC 29119 consta de cuatro partes:

Análisis

La nueva norma iso es la prueba viviente del avance que han tenido las pruebas en el software al pasar del tiempo.

Los conceptos, definiciones, etc que ofrece Pressman siguen siendo validos solo que ahora se tiene mas herramientas y técnicas para tener una mayor efectividad en las pruebas


REFERENCIAS
  • Ingeniería del Software: Un Enfoque Práctico                                                                            Rogger S. Presuman - Quinta Edición

domingo, 13 de mayo de 2012

Ciclo de Vida Orientado a Objetos VS Tradicionales

El tiempo de desarrollo y uso del software, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado se denominan ciclo de vida del software.
Un ciclo de vida usualmente consta de las siguientes etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento.
Cada etapa consta de diversas tareas; la documentación es una tarea que se realiza en todas las etapas.

Los ciclos de vida tradicionales más conocidos son:
  • Ciclo de vida en cascada
  • Ciclo de vida en cascada incremental
  • Ciclo de vida en espiral
  • Ciclo de vida en espiral Win Win
  • Ciclo de vida Prototipo
  • Ciclo de vida Recursivo Paralelo
  • Ciclo de vida DRA
  • Ciclo de vida Evolutivo
  • etc.
A continuacion se describe brebemente alguno de estos ciclos de vida.

Ciclo de vida en cascada

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:
  • Especificación de requisitos
  • Diseño del software
  • Codificación
  • Pruebas (o validación)
  • Despliegue (o instalación)
  • Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

Ventajas

  • La planificación es sencilla. 
  • La calidad del producto resultante es alta. 
  • Permite trabajar con personal poco calificado. 
  • Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.
  • Es mejor que no seguir ningún ciclo de vida.

Inconvenientes

  • Es difícil obtener todos los requisitos al comienzo. 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. Al cambiar alguna de las etapas se debe revisar todas las etapas subsiguientes.
  • Es comparativamente más lento que los demás y el coste es mayor también.
  • Se tarda mucho en disponer del software.
  • 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%).
  • El mantenimiento se realiza en el código fuente
  • Impone una estructura de gestión de proyectos

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. 
  • Como el modelo en cascada ha sido muy popular ha generado algunas variantes.

Ciclo de vida en espiral

La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
  • Crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
  • Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
  • La implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto.

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. 

Inconvenientes

  • 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.

Ciclo de vida Prototipo


Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombremáquina.

En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
  • Escuchar al Cliente: El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. 
  • Construir/Revisar la maqueta: Entonces aparece un «diseño rápido». El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. 
  • El Cliente Prueba la maqueta: El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

Ventajas

  • Ayuda a identificar los requisitos del software. 
  • Hace el software amigable al usuario.
  • El cliente estará seguro de que el producto final reflejara lo que él desea.

Inconvenientes

  • Primera versión de un producto es construido con poca funcionalidad y poca fiabilidad.
  • El cliente ve lo que parece ser una versión de trabajo del software, y piensa que el trabajo esta hecho.
  • Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. 
  • No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es más inteligente, y construir una versión rediseñada en la que se resuelvan estos problemas

Diferencia entre Prototipo y Producto Final

La diferencia entre prototipo y producto final es que el prototipo es eficiente y el producto final debe serlo y, que en el prototipo no están todos los detalles y, el producto final debe contenerlos.
Clases de prototipos:
  • Vertical: no recoge todas las funciones del sistema final.
  • Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

Ciclo de Vida Orientado a Objetos

Esta técnica fue presentada en la década de los 90, tal vez como una de las mejores metodologías a seguir para la creación de productos software.
Puede considerarse como un modelo pleno a seguir, como así también una alternativa dentro de los modelos anteriores.

Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto.

 Los ciclos de vida clásicos se centran en el proyecto, el desarrollo orientado a objetos se basa en el producto, no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro y se relacionan entre ellos a través de interfaces, son más modulares y se dividen en miniproyectos lo cual permiten que el código sea reutilizable. 

Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho mas fácil agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene.
Debido a todo esto se considera que el ciclo de vida orientado a objetos es iterativo e incremental.

Los ciclos de vida orientados a objetos son:
  • Modelo Fuente.
  • Modelo de Agrupamiento.
  • Modelo Remolino.
  • Modelo PinBall.
A continuacion veremos un tipo de ciclo de vida orientado a objetos mas conocidos, que es además el más representativo, el modelo fuente.

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:
  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
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:
  • Crecimiento: Es el tiempo durante el cual se construye el sistema
  • 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. En la figura se muestra un esquema de este tipo de ciclo de vida.

Modelo de Agrupamiento (Clúster)

Propuesto por Bertrand Meyer (Meyer, 1990). 
Concepto Clave: Agrupamiento, que es un conjunto de clases relacionadas con un objetivo común.
Clúster: Unidad organizativa básica. Es un grupo de clases relacionadas o, recursivamente, clústeres relacionados. El clúster es la unidad natural para el desarrollo por parte de un único desarrollador.
  • Evita el efecto todo-nada propio del modelo en cascada.

Tiene un componente secuencial y un componente concurrente.
  • Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo.
  • Se aplica al clúster no al sistema completo.
  • El miniciclo de vida que gobierna el desarrollo de un clúster está formado por Especificación, Diseño, Implementación, Verificación/Validación y Generalización.

Enfoque Ascendente.
La ocultación de la información posibilita la forma del modelo de clústeres de ingeniería concurrente.

Modelo Remolino

Definido por James Rumbaugh (Rumbaugh, 1992). Las metodologías de desarrollo no ofrecen una visión real del ciclo de vida en el desarrollo orientado al objeto. El ciclo de vida de un desarrollo orientado al objeto es desordenado, involucrando múltiples iteraciones interrelacionadas.
El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso.
Pueden Identificarse otras dimensiones:
  • Amplitud: tamaño del desarrollo, por ejemplo en número de elementos.
  • Profundidad: referida al nivel de abstracción o detalle.
  • Madurez: grado de complexión, corrección y elegancia.
  • Alternativas: Diferentes soluciones a un problema.
  • Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo largo del tiempo.
Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad - madurez – amplitud
Este proceso fractal (mas que lineal), consiste en un desarrollo multiciclo en forma de remolino en lugar de una cascada, de ahí su nombre.

Modelo PinBall

Propuesto por Ambler (Ambler, 1994). Modelo muy didáctico señala que el pinball refleja la forma que se desarrolla el software.
  • Pelota ====> Proyecto o subproyecto 
  • Jugador ====> Equipo de desarrollo

Se procede de forma iterativa a encontrar clases, atributos, métodos y relaciones (actividades que pueden englobarse en la fase de análisis) y definir colaboraciones, herencia, agregación y subsistemas (actividades de diseño), y por último se pasa a la programación, prueba e implementación.

Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea.

Existen dos estilos a la hora de jugar
  • A lo seguro ===> Con tecnologías y métodos probados 
  • Al límite ===> Con más riesgo (se pueden conseguir beneficios espectaculares) 
El autor destaca que al igual que en el juego del pinball, la habilidad es el factor mas importante.

Consideraciones sobre los Ciclos de Vida Orientado a Objetos

  • Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto.
  • Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.
  • Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.

Conclusiones

Los ciclos de vida tradicionales son estructurados lo que hace difícil dividirlos en subsistemas para ser implementados independientemente, en cambio los ciclos de vida orientado a objetos son modulares, es decir, se dividen en módulos formados por componentes, donde cada componente es independiente del otro y se relacionan a través de las interfaces; esta división eventualmente facilita la construcción del software, puesto que se puede avanzar en distintas partes del proyecto a la vez.

Los Ciclos de vida Orientados a Objetos tienen permiten la reutilización del código, algo con lo que no cuentan los tradicionales.

Los Ciclos de vida Orientados a Objetos son mas fáciles de mantener porque los cambios están localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho mas fácil agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene. En cambio los tradicionales tienen más complicaciones para detectar y corregir los errores a tiempo, mas aun la modificación o incremento de requerimientos ocasiona crisis en el proyecto pues no suelen ser muy flexibles al cambio.

Por todo esto es a mi parecer mucho mas conveniente realizar proyectos siguiendo un ciclo de vida orientado a objetos en lugar de utilizar uno tradicional, o bien también es factible utilizar alguna variante de los tradicionales con los orientados a objetos obteniendo como resultado un ciclo de vida hibrido

Referencias

Libros

Ingeniería del Software: Un Enfoque Práctico
Rogger S. Presuman - Quinta Edición

Páginas Web