1.
Análisis comparativos de
los distintos ciclo de vida en el software.
Para
facilitar una metodología común entre el cliente y la empresa de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de
desarrollo involucradas y la documentación requerida, de manera que cada etapa
se valide antes de continuar con la siguiente etapa.
El ciclo
de vida permite que los errores se detecten lo antes posible, permite a los
desarrolladores concentrarse en la calidad del producto.
Comparación de los
modelos de ciclo de vida:
·
Ciclo de vida Cascada:
Se denomina modelo en
cascada porque su característica principal es que no se comienza con un paso
hasta que no se ha terminado el anterior.
El principal problema es
que no podemos esperar el que las especificaciones iniciales sean correctas y
completas y que el usuario puede cambiar de opinión sobre una u otra
característica. Además los resultados no se pueden ver hasta muy avanzado el
proyecto por lo que cualquier cambio debido a un error puede suponer un gran
retraso además de un alto coste de desarrollo. Si el usuario cambia de opinión
en algún aspecto tendremos que volver hacia atrás en el ciclo de vida.
·
Ciclo de vida Prototipo:
Consiste en iterar en la
fase de análisis tantas veces como sea necesario, mostrando prototipos al
usuario para que pueda indicarnos de forma mas eficiente los requisitos del
sistema. La iteración finalizará cuando el usuario de el visto bueno al
prototipo.
Ciclo de vida Evolutivo:
Se diferencia del modelo
por prototipos en que en prototipos se da por hecho que aunque se necesiten
varias iteraciones para lograrlo al final se llegará a tener una serie de
requisitos completos y sin errores, que no vayan a cambiar más.
En el modelo evolutivo se
asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida
y no solo en la etapa de análisis.
·
Ciclo de vida Incremental:
Es una aproximación muy
parecida a la evolutiva. En este modelo se desarrolla el sistema para
satisfacer un subconjunto de los requisitos especificados y en posteriores
versiones se incrementa el programa con nuevas funcionalidades que satisfagan
mas requisitos.
En el caso del modelo
evolutivo se desarrollaría una nueva versión de todo el sistema, en el
incremental se parte de la versión anterior sin cambios y le añadimos las
nuevas funciones.
·
Ciclo de vida Espiral:
Toma las
ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el
concepto de análisis de riesgo.
Se
definen cuatro actividades:
1.
Planificación, en la que se recolectan los requisitos iniciales o nuevos
requisitos a añadir en esta iteración.
2.
Análisis de riesgo, basándonos en los requisitos decidimos si somos capaces o no de
desarrollar el software y se toma la decisión de continuar o no continuar.
3.
Ingeniería, en el que se desarrolla un prototipo basado en los requisitos obtenidos
en la fase de planificación.
4.
Evaluación del cliente, el cliente comenta el prototipo. Si esta conforme con el se acaba
el proceso, si no se añaden los nuevos requisitos en la siguiente iteración.
·
Ciclo de vida RAD:
Es un
modelo de proceso de desarrollo de software lineal secuencial que enfatiza un
ciclo de desarrollo extremadamente corto.
1.
Modelado de gestión: flujo de información entre las funciones de gestión responde las
siguientes preguntas: ¿que información conduce al proceso de gestión?, ¿A dónde
va la información?, ¿Quién la procesa?
2.
Modelado de datos: flujo de información definido como parte de la fase del modelado
de gestión se refina como un conjunto de objetos y datos necesarios para apoyar
la empresa.
3.
Modelado de procesos: los objetos de datos definidos en la fase de modelado quedan
transformados para lograr el fin deseado.
·
Ciclo de vida XP:
Extreme
Programming (XP) surge como una nueva manera de encarar proyectos de software,
proponiendo una metodología basada en la simplicidad y agilidad. Las
metodologías de desarrollo de software tradicionales (ciclo de vida en cascada,
evolutivo, en espiral, iterativo, etc.) comparados con los nuevos métodos
propuestos en XP, como pesados y poco eficientes. La crítica más frecuente a
estas metodologías “clásicas” es que son demasiado burocráticas. Hay tanto que
hacer para seguir la metodología que, a veces, el ritmo entero del desarrollo
se retarda.
·
Ciclo de vida V:
El modelo
en V es un proceso que representa la secuencia de pasos en el desarrollo del
ciclo de vida de un proyecto. Describe las actividades y resultados que han de
ser producidos durante el desarrollo del producto.
La parte
izquierda de la V representa la descomposición de los requisitos y la creación
de las especificaciones del sistema. El lado derecho de la v representa la
integración de partes y su verificación. V significa “Validación y
Verificación”.
2. ISO para testing (testeo) de software.
El grupo de trabajo AEN/CTN 71/SC7/GT26 -
Pruebas de Software (GT26) fue constituido por AENOR, Organismo de Normalización en España,
para participar en la elaboración del futuro estándar ISO sobre
pruebas de software, denominado ISO/IEC 29119 Software Testing.
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, para remplazar varios estándares IEEE y
BSI sobre pruebas de software. La estructura de ISO/IEC 29119 consta de
cuatro partes, como se ve en la siguiente figura:
Parte 1: Definiciones y Vocabulario
Da una visión general de la norma y de los
conceptos generales de pruebas de software y para proporcionar un vocabulario
de términos de pruebas de software que cubren las pruebas de software de
todo el ciclo de vida.
Se prevé que esta parte se incluyan los
siguientes temas:
·
Introducción a las pruebas de software.
·
Pruebas de software en un contexto organizativo.
·
El proceso de prueba.
·
La relación entre las pruebas y el desarrollo.
·
Implicaciones de los modelos de
ciclo de vida de desarrollo software (por ejemplo, cascada, espiral, ágil).
·
Tipos de pruebas, pruebas técnicas y fases/niveles de prueba.
·
Pruebas basadas en el Riesgo.
·
Elementos de Pruebas.
·
Requisitos de verificación del sistema.
·
Requisitos de validación del sistema.
Parte 2: Proceso de Pruebas
Define un modelo de
proceso de pruebas genérico que se puede utilizar dentro de cualquier
desarrollo de software y pruebas de ciclo de vida. Dicho modelo de procesos tal
está formado por tres niveles:
·
Procesos de la organización.
·
Procesos de gestión.
·
Procesos "fundamentales"
Para un proyecto de pruebas se tienen los
niveles de procesos de gestión y procesos "fundamentales".
Estos procesos son la planificación,
monitorización y control,
y finalización de las pruebas. Los diferentes procesos de gestión se podrán
instanciar en uno o en varios dependiendo de la situación. Por ejemplo, en un
proyecto simple puede existir solamente un plan de
pruebas global (una sola instancia). En un proyecto más complejo puede existir
un plan maestro y otros planes subordinados a éste para cubrir diferentes
niveles de prueba (por ejemplo, pruebas de integración,
sistema o aceptación) o diferentes tipos de prueba. Cada uno de ellos sería una
instancia del proceso de gestión.
Los procesos fundamentales abarcan los aspectos
técnicos de las pruebas: diseño e implementación, puesta a punto del entorno,
ejecución de pruebas y la notificación de resultados de las pruebas. También se
incluirán variantes de los procesos para contemplar tanto pruebas dinámicas
como estáticas.
Parte 3: Documentación de Pruebas:
Cubre la documentación de las pruebas a través
del ciclo de vida completo del software. Esta parte contendrá plantillas de
todas las capas del modelo de proceso 29119, incluyendo:
·
Política organizacional del Proceso de prueba.
·
Estrategia organizacional del Proceso de prueba.
·
Proyecto de Gestión del Proceso de prueba.
·
Proceso de pruebas fundamentales
Parte 4: Técnicas de Pruebas:
Se está
elaborando una Parte 5 Evaluación del Proceso,
que será nombrada ISO/IEC 29119-5. La siguiente figura, ilustra la relación de
los procesos definidos en el estándar.
