Sudoku
 Planeación
• Historias de usuario
• Reunión de la planeación del release
 Alcance, Recursos y Tiempo
• Rotación de recursos
 Diseño
• CRC
• Prototipos
• Refactor
 Codificación
 Testing
 Conclusiones
Se desea implementar un juego Beta de SUDOKU donde se
requieren las siguientes funcionalidades:
• Solo se pueden ingresar números entre 1-9
• No se pueden repetir números en las filas
• No se pueden repetir números en las columnas
• No se pueden repetir números en los tableros internos
• Tablero interno de 3X3
• Tablero global de 9X9
• Interfaz Gráfica de Usuario Amigable
• Nivel de SUDOKU Normal (Sugerir 40% de los números del tablero)
Se establecieron entregables (Hitos producto) de la siguiente manera:





Casos de Prueba
Pruebas de Usuario (JUnit)
Crear Prototipo de Interfaz y Aprobarla
Edición en interface gráfica
Validación de SUDOKU Exitoso
22 Abr.
23 Abr.
23 Abr.
23 Abr.
26 Abr.
Según los entregables propuestos se construirá el 100% de los
artefactos
Equipo de Trabajo:
4 Desarrolladores
1 Cliente
Prioridades:
Interfaz Gráfica
Validación SUDOKU
Para el trabajo se tuvieron en cuenta dos roles,
Desarrollador y Analista los cuales fueron
administrados de la siguiente manera:
• 2 Equipos compuestos de (1 Desarrollador, 1 Analista)
• Se realizo programación por pares (Como grupo nos
pareció muy bueno)
• Se cambiaron los roles cada vez que se cumplía un
Hito
class System
InterfazTablero
<Presentación>
<Pruebas>
Tablero
<Validación>
TableroTest
Para esta parte se utilizaron las siguientes técnicas de
codificación:
• Se utilizaron estándares de codificación para los objetos de interfaz y
•
•
•
•
•
firmas de métodos y clases.
Se construyeron primero las pruebas unitarias, basados en el set de
pruebas proveído por el usuario.
Toda la codificación se construyo bajo el esquema de pares.
Se utilizo un repositorio SVN de datos para realizar la integración en
línea de funcionalidades.
No se codifico tiempo extra. Los tiempos fueron muy exigentes y
estrictos.
Se utilizaron dos computadores para el desarrollo de la aplicación.
 Pruebas Unitarias:
• Creación de Escenarios basados en set de pruebas de
usuario
• Codificación de la secuencia de pruebas
• Ejecución de pruebas
• Integración de las pruebas al sistema
 Pruebas de usuario
• Pruebas funcionales
• Retroalimentación
• Correcciones
Programación por pares es eficiente
Historias de usuario más fáciles de manejar (lenguaje
natural).
 Elaborar pruebas como parte de la planeación da mejor
entendimiento del problema.
 Realizar entregas parciales (release) nos da la certeza
de saber que lo construido es lo requerido.
 Se hace parte integral de la construcción del producto
al usuario por intermedio de la historias y pruebas de
usuario.
 Como desventaja: A nuestro parecer aplica para
proyectos pequeños, pero NO a proyectos grandes,
debido a que se tienen personas trabajando sin
explotar todo su potencial.


Descargar

Diapositiva 1