QA&V Ciclo de vida del desarrollo de Software Parte - 2
(QA&V Software Development Life Cycle)
3.2.2.5 Modelo Prototipo:
Este modelo de desarrollo de software se basa en la creación de
prototipos con base en los requerimientos del cliente, este modelo está
constituido en 4 fases principales:
- Definición de los
requerimientos básicos.
- Creación del prototipo de
trabajo.
- Verificación del prototipo.
- Cambio o elaboración de los
requerimientos.
Todo esto para la creación de un método de trabajo rápido y aplicable al
proyecto donde los requerimientos del sistema no son del todo claros al inicio
o donde los desarrolladores no tienen bien establecidos los algoritmos o la
estructura del software. (Softtek, 2013)
Existen dos tipos principales de prototipos:
- Evolutivo: Donde el objetivo del prototipo es liberar y mostrar el trabajo a
los usuarios finales, esto es usado por sistemas donde las
especificaciones del proyecto no están del todo claras, y donde la
verificación es imposible debido a que no hay especificaciones.
- Desechables: El objetivo de los desechables es validar u obtener los
requerimientos del sistema. Los desechables o prototipos rápidos, hacen
referencia a la creación de un modelo que es eventualmente descartado
conforme se llega a la parte final del software. Después de que los
requerimientos preliminares fueron establecidos, un modelo simple del
sistema es construido para poder mostrar al cliente cómo es que los
usuarios verán la aplicación, y con ello ir definiendo poco a poco los
requerimientos finales a implementar para que se genere un proyecto de
calidad. (Society, 1998)
El ciclo del prototipo es:
- Identificar la base de los
requerimientos.
- Desarrollar el prototipo
inicial.
- Obtener una revisión de los
usuarios finales y clientes.
- Basado en esa revisión,
revisar la utilidad del prototipo y valorar si es lo que el cliente
necesita.
Fuente: Elaboración Propia.
·
Ventajas:
·
El modelo puede ser usado cuando los requerimientos están o no están
especificados.
·
El usuario puede experimentar con el sistema para mejorar los
requerimientos.
·
Desventajas:
·
El uso de este método es exploratorio, lo que genera tener siempre un
alto riesgo y por ello se necesita un manejo estricto de situaciones en las que
se encuentre el proyecto.
·
Este método puede ser usado incluyendo o no la documentación del diseño,
siempre que sean entendidos perfectamente.
3.2.2.6 Modelo V:
El modelo V es la evolución del modelo en cascada, es un modelo
secuencial y en cada paso finalizado se inicia el comienzo de la próxima fase,
y una vez que se llega al fondo del modelo (ver Ilustración 9) se vuelve a
subir simulando una V.
Las pruebas son mucho más exhaustivas en este modelo a comparación del
modelo en cascada, y las pruebas son más sencillas, así como también más
eficaces, mejorando la calidad en el desarrollo de los productos. (Ángel, 2013)
Fuente: Elaboración Propia.
·
Ventajas:
·
Simple y fácil de usar.
·
Para cada fase existe un entregable.
·
Tiene una gran probabilidad de que el proyecto sea terminado
satisfactoriamente.
·
El flujo de trabajo funciona muy bien cuando los requerimientos están
bien entendidos.
·
Desventajas:
·
Es poco flexible, como el modelo en cascada.
·
Ajustar los calendarios de trabajo es difícil y muy caro.
·
El modelo no está diseñado para un camino sencillo a la hora de
encontrar problemas durante la fase de desarrollo.
3.2.3 Modelos Ágil
El manifiesto de los modelos ágil
establece la diferencia con los modelos tradicionales, este manifiesto indica
lo siguiente:
·
Al individuo y las interacciones
del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor
de éxito de un proyecto de software. Es más importante construir un buen equipo
que construir el entorno. Muchas veces se comete el error de construir primero
el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el
equipo y que éste configure su propio entorno de desarrollo con base en sus
necesidades.
·
Se debe desarrollar software que
funciona más que conseguir una buena documentación. La regla a seguir es “no producir
documentos a menos que sean necesarios de forma inmediata para tomar una
decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
·
Buscar o preferir la colaboración
con el cliente más que la negociación de un contrato. Se propone que exista una
interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su
éxito. (Amaro Calderón, 2007)
·
Responder a los cambios más que
seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a lo largo
del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación
no debe ser estricta sino flexible y abierta.
Este manifiesto tiene doce puntos:
- La prioridad es satisfacer al cliente mediante tempranas y
continuas entregas de software que le aporte un valor.
- Dar la bienvenida a los cambios. Se capturan los cambios para que
el Cliente tenga una ventaja competitiva.
- Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible entre
entregas.
- La gente del negocio y los desarrolladores deben trabajar juntos a
lo largo del proyecto.
- Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo.
- El diálogo cara a cara es el método más eficiente y efectivo para
comunicar información dentro de un equipo de desarrollo.
- El software que funciona es la medida principal de progreso.
- Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
- La atención continua a la calidad técnica y al buen diseño mejora
la agilidad.
- La simplicidad es esencial.
- Las mejores arquitecturas, requisitos y diseños surgen de los
equipos organizados por sí mismos.
- En intervalos regulares, el equipo reflexiona respecto a cómo
llegar a ser más efectivo, y según esto ajusta su comportamiento. (Amaro Calderón, 2007)
3.2.3.1 XP- extreme Programming:
XP es la primera metodología ágil
y la que le dio conciencia al movimiento actual de metodologías ágiles, creada
a mediados de los 90 por Kent Beck, poniendo las 12 ideas anteriormente citadas
en el manifiesto como fundamentales en los principios de un desarrollo XP. (Amaro Calderón, 2007)
Fuente: (Amaro Calderón, 2007).
·
Ventajas:
·
Se construye el proyecto con base a la calidad.
·
Es simple.
·
Siempre se está programando.
·
El cliente siempre está al pendiente del desarrollo del proyecto.
·
Es una buena práctica de sinergia.
·
Desventajas:
·
Cuando el proyecto es muy largo, se vuelven más complejos los ambientes.
·
Se generan muchas situaciones críticas si no se lidera bien.
·
Demanda tener muy bien entendido los requerimientos del proyecto.
·
El cliente puede estar distante o no saber exactamente lo que desea.
3.2.3.2 Scrum:
Scrum es un marco de trabajo para desarrollar
productos y sistemas complejos, que son desarrollados bajo una teoría empírica,
el cual emplea un desarrollo de optimización iterativo incremental para
optimizar la predicción y el control de riesgos.
Scrum es un
método iterativo e incremental que enfatiza prácticas y valores de project management por sobre las demás disciplinas del desarrollo. Al
principio del proyecto se define el Product
Backlog, que contiene todos los
requerimientos funcionales y no funcionales que deberá satisfacer el sistema a
construir. Los mismos estarán especificados de acuerdo a las convenciones de la
organización ya sea mediante: features,
casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog será definido durante
reuniones de planeamiento con los stakeholders
(son los individuos que se relacionan directamente con el proyecto). A
partir de ahí se definirán las iteraciones, conocidas como Sprint en la jerga de Scrum, en las que se irá evolucionando
la aplicación evolutivamente. Cada Sprint
tendrá su propio Sprint Backlog que
será un subconjunto del Product Backlog con los requerimientos a ser
construidos en el Sprint
correspondiente. La duración recomendada del Sprint es de un mes. (Amaro Calderón, 2007)
Esta
metodología es susceptible a incertidumbres y riesgos sin embargo provee
técnicas específicas y prácticas para resolver estos riesgos, es muy similar al
modelo iterativo e incremental. En esta metodología se maneja el Sprint, el cual es un periodo aproximado
de 30 días donde se trabaja para sacar el producto entregable al cliente. En
cada fase de desarrollo se requiere una serie de Sprints para determinarlos, donde primero se planean las
prioridades y el tiempo de revisión de las actividades que se llevarán a cabo,
tratando de localizar el tiempo que se tomará para cada una de las actividades,
este tiempo es determinado en una junta con los administradores del proyecto. Se
trata de no gastar tiempo en detalles ya que se tiene un conocimiento previo de
lo deseado. El seguimiento se trata de monitorear a los involucrados en el
desarrollo del producto, en el caso de QA se busca observar los problemas
encontrados por el equipo de Testers
manuales y la comunicación con Automatización.
Estas
reuniones llevan el nombre de Scrum Meeting, y tienen la duración de 15 a 30
minutos con cada equipo, donde se habla de lo que se realizó en el anterior Scrum Meeting, cuáles fueron los problemas encontrados, si alguien no
logró terminar el trabajo en el tiempo asignado, y lo que se trabajará para el
siguiente Sprint.
Los
roles involucrados en el Scrum Meeting son:
·
Cliente.
·
Scrum Master.
·
Equipo QA.
Como se puede observar en la Ilustración 11. La metodología resulta
sencilla definiendo algunos roles y artefactos que contribuyen a tener un
proceso que maximiza el feedback para
mitigar cualquier riesgo que pueda presentarse.
Fuente: (Amaro
Calderón, 2007).
La intención de Scrum es la
de maximizar la realimentación sobre el desarrollo, pudiendo corregir problemas
y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más
dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras –
como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en
particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser
combinado con cualquiera de las metodologías mencionadas. (Amaro Calderón, 2007)
3.2.3.3 Ciclo de Vida de Scrum:
El ciclo de vida de Scrum es el siguiente:
1.
Pre-Juego: Planeamiento. El
propósito es establecer la visión, definir expectativas y asegurarse la
financiación. Las actividades son la escritura de la visión, el presupuesto, el
registro de acumulación o retraso (backlog)
del producto inicial y los ítems
estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los
prototipos. El registro de acumulación es de alto nivel de abstracción.
2. Pre-Juego: Montaje (Staging). El
propósito es identificar más requerimientos y priorizar las tareas para la
primera iteración. Las actividades son planificación, diseño exploratorio y
prototipos.
3. Juego o
Desarrollo. El
propósito es implementar un sistema listo para entrega en una serie de
iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son los planeamientos de corridas en cada
iteración, la definición del registro de acumulación de corridas y los
estimados, y encuentros diarios de Scrum.
4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las
actividades, documentación, entrenamiento, mercadeo y venta.
Usualmente los registros de acumulación se llevan en planillas de
cálculo comunes, antes que en una herramienta sofisticada de gestión de
proyectos. Los elementos del registro pueden ser prestaciones del software,
funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología.
Hay un registro total del producto y otro específico para cada corrida de 30
días. En la jerga de Scrum se llaman
“paquetes” a los objetos o componentes que necesitan cambiarse en la siguiente
iteración. (Ángel, 2013)
Fuente: (Amaro
Calderón, 2007).
La lista de Acumulación del Producto contiene todos los rasgos,
tecnología, mejoras y lista de bugs que,
a medida que se desenvuelven, constituyen las futuras entregas del producto.
Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se
tratarán de manera más sumaria. La lista se origina a partir de una variedad de
fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de
ventas genera elementos que harán que el producto sea más competitivo; los de
ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará
debilidades o problemas que deberán resolverse. El propietario de la
administración y el control del backlog
en productos comerciales bien puede ser el product
manager; para desarrollos in-house
podría ser el project manager, o alguien designado por él. Se
recomienda que una sola persona defina la prioridad de una tarea; si alguien
tiene otra opinión, deberá convencer al responsable. Se estima que priorizar
adecuadamente una lista de producto puede resultar dificultosa al principio del
desarrollo, pero deviene más fácil con el correr del tiempo. (Amaro
Calderón, 2007)
Te invito a dejar tus comentarios para mejorar la información.
