Cuadro Comp 1P + Agregados para final Flashcards
Timebox development
6
2
Kanban
Aplicar cuando
• Proyectos inestables. Domino/entorno caótico y complejo.
• La prioridad de los requerimientos cambia constantemente.
• Hay demasiado trabajo con poca productividad.
• Nos abrumamos de tareas.
• Perdemos el foco cambiando de tarea.
• Hay demasiado trabajo con poca productividad.
• Hay problemas de comunicación en el equipo provocando esfuerzos duplicados, defectos, retrabajos, etc.
Objetivo principal: Detectar cuellos de botella que representan estancamiento para avanzar. Evitar abrumación. Mejorar comunicación, evitando duplicación y retrabajo.
Scrum
- Proyecto donde hay mucha incertidumbre.
- Cuando tenemos un contexto complejo.
Lean
- Se basa en los principios de mejora continua.
- Objetivo: crear valor para satisfacer al cliente.
- En IT, se puede aplicar desde requerimientos hasta mantenimiento.
- Involucra el 100% de los colaboradores de IT.
Planning Poker
Ventajas Planning Poker (técnicas de estimación ágiles)
- Promueve la participación y la colaboración.
- Abstrae el concepto del tiempo, las estimaciones se hacen por puntos (medida proporcional a tareas simples).
- Aumenta el compromiso, si la historia del usuario entra en el sprint estamos comprometidos por participar en la estimación.
- No está bueno para proyectos sin historia porque no vas a tener con qué comparar.
- No es bueno para un proyecto corto.
- Sin un mínimo conocimiento es difícil estimar basado en puntos (estimar tamaño).
Wideband Delphi
“Wideband Delphi” es un método de estimación rudimentario, basado en el juicio experto en grupos.
Cada equipo dice porqué llegó al valor x (sin decir x), las razones de porqué llegó a esa estimación. La idea es que hay un moderador y después de rondas, se termina teniendo un x común. Se llega a un consenso entre varias personas.
- Para grupos grandes y que no se tenga mucha idea.
- Cuando no haya experiencia previa.
- Cuando no haya datos históricos en este tipo de estimaciones.
- Es fácil de implementar.
- Se puede utilizar en etapas tempranas del proyecto.
Function Points
- Los Function Points miden el tamaño del SW en base a la funcionalidad capturada en los requerimientos.
- El método “Puntos por Función” da como salida puntos de función que luego deben ser convertidas a Lines of Code (LOC).
- El método Function Points se lo puede ajustar a través de factores de ajustes, pero no son distintos métodos sino que es el mismo método ajustado.
- Requiere un análisis de requerimientos avanzados.
- No se puede utilizar en una etapa temprana de análisis.
- Es independiente a las tecnologías a utilizar.
- Busca no invertir el tiempo desmedidamente.
- Es difícil de aprender y perfeccionar.
Object Points
- El Objects Points considera como factor de ajuste el porcentaje de reutilización de código.
- OPs son muy adecuados para estimar proyectos de mantenimiento de SW porque tiene en cuenta la reusabilidad del código, entre otros.
- Estima esfuerzo.
- A diferencia de FP se puede utilizar en una etapa temprana del análisis.
- Carece de una tabla de ajustes técnicos o de entorno.
Métricas de Testing
- Productividad Diseño - que capacidad tiene mi tester de crear condiciones por unidad de tiempo , sirve cuando hay que hacer alguna estimación
Ej.: Condiciones Construidas x Unid. Tiempo” - Productividad Ejecución . cuántos casos puede ejecutar por unidad de tiempo (sirve para ver si es susceptible de automatización o no)
Ej.: Casos Ejecutados x Unid. Tiempo - Eficacia (Pre Release) - cuantos incidentes de los que reporte fueron finalmente son aceptados y declarados como defecto (que NO sean falsos positivos)
Ej.: ( Incidentes Reportados Aceptados / Total Incidentes Reportados x 100 )
Es interesante medir también la eficacia en la resolución de defectos - Eficacia (Post Release) - cuantas de las fallas son relevantes
Ej.: [ Fallas Reportadas / (Fallas Reportados + Fallas Rep. User ]x 100 - “Calidad” del Desarrollo
Ej.: Índice de Severidad por Defectos Reportados - Release Readiness - cuan listo estoy para salir a producción
Ej.: Índice de Severidad por Defectos Abiertos.
Definición de Incidente de Testing.
- Toda ocurrencia de un evento que sucede durante la ejecución de una prueba de software que requiere investigación.
- Todo lo que termina reportando el tester termina reportando al equipo de desarrollo para que sea revisado y trate de encontrar el DEFECTO- lo que origina la falla- (y de confirmarlo, se convierte en una falla).
- No toda incidencia es una falla.
- Cuando el resultado esperado es distinto al obtenido.
Ejemplos: Defectos en los casos/ Equivocaciones al ejecutar las pruebas/Interpretaciones erróneas/Dudas
Definición de Equivocación.
- Acción humana que produce un resultado incorrecto, origen del defecto.
- 1 equivocacion => 1 o + defectos presentes en el código.
Definición de Defecto.
- Paso, proceso o definición de dato incorrecto.
- Ausencia de cierta característica.
- No solo estan en el código, en tablas de datos, etc.
- El tester ve la manifestación del defecto y lo reporta, el desarrollador debe buscar el defecto
- Es lo que genera fallas.
- 1 defecto => 0 o + fallas.
Ejemplo- olvidarse de validar algo en un campo de input.
todo new: chequear que no haya otra def mas linda
Definición de Falla.
- Resultado de ejecución incorrecto. Es el producido por el SW. Es cuando el resultado obtenido es distinto al resultado esperado.
- 1 falla tiene que ver con 1 o + defectos.
Definición de Condiciones de prueba.
- Son descripciones de situaciones que quieren probarse ante las que el sistema debe responder.
- Crear condiciones es un proceso “creativo”.
Definición de Partición - clases de equivalencia.
- Todos los posibles casos de prueba los dividimos en clases
- La identificación de clases de equivalencia se hace dividiendo cada condición de entrada en dos tipos de grupos: clases válidas y clases inválidas
- Todos los casos de una clase son equivalentes entre sí - Detectan los mismos defectos
- Con solo ejemplos de cada clase cubrimos todas las pruebas
- El éxito está en la selección de la partición !!!
