Your SlideShare is downloading. ×
0
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Porque probar #esvs2010
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Porque probar #esvs2010

598

Published on

Presentación en Madrid en el lanzamiento de Visual Studio 2010. …

Presentación en Madrid en el lanzamiento de Visual Studio 2010.
Sin hablar de Visual Studio

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
598
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Porqué?Probarel Código<br />rido abr2010<br />
  • 2. DemostraciónEmpírica<br />MétodoFáctico<br />Veríficación<br />contrastación por medio de la percepción<br />Esautocorrectivo y progresivo<br />No considera sus conclusiones infalibles o finales<br />
  • 3. Hecho nº1<br />¿Queés lo másimportante en un proyecto de Software?<br />Documentación<br />Requisitos<br />Arquitectura<br />DiseñoDetallado<br />Fuentes<br />Plan de Pruebas<br />Binario<br />
  • 4. Lines Of Code<br />
  • 5. Hecho nº2<br />¿Cuánto cuesta terminar el código?<br />Teclear<br />Compilar<br />Depurar<br />Cambiar<br />Ejecutar<br />Integrar<br />Adaptar<br />Probar<br />Leer<br />
  • 6. Se gastamástiempo<br />leyendo/depurando /probando<br />que<br />escribiendo<br />
  • 7. Hecho nº3<br />Las tres B-ariables*<br />(*)Bueno-Bonito-Barato (Escoge2)<br />Tiempo<br />Alcance<br />Q<br />Recursos<br />
  • 8. BBB<br />
  • 9. Hecho nº4<br />Siempre hay cambios<br />Requisitos<br />Errores<br />Clientes<br />Entornos<br />No Funcionales<br />Tendencias<br />Tecnologías<br />Integrar<br />
  • 10. Asume el Cambio<br />
  • 11. ¿Dóndeestáes el problema?<br />Lines Of Code<br />BBB<br />Se gastamástiempo<br />leyendo/depurando /probando<br />que<br />escribiendo<br />Asume el Cambio<br />
  • 12. El Problema<br />
  • 13. Productividad<br />
  • 14. Tácticas<br />
  • 15. Táctica nº1<br />Nunca a la primera, mejoraprogresiva<br />KISS<br />YAGNI<br />DRY<br />
  • 16. Táctica nº2<br />¿Mejortécnica de diseño?<br />Lines Of Code<br />
  • 17. Táctica nº3<br />Invertir en la Calidad<br />SourceControl<br />Builds<br />Unit<br />Refactor<br />TDD<br />BVT<br />CodeAnalysis<br />Coverage<br />CI<br />Tests<br />
  • 18. Táctica nº4<br />Domain Driven Design<br />SoC<br />Entidades<br />Agregados<br />LenguajeUbicuo<br />Repositorios<br />IoC<br />Persistence Ignorance<br />Technology Agnostic<br />
  • 19. Nueva Productividad<br />Nueva Productividad<br />
  • 20. La Solución<br />
  • 21. Refactor<br />Test<br />Lines Of Code<br />De-<br />Test-e-able<br />
  • 22. Gracias<br />

×