Buenas practicas para el desarrollo de software

13,010 views
12,595 views

Published on

Buenas prácticas a nivel metodológico en el desarrollo de software. Parte de un curso que dicto de Rational Unified Process.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
13,010
On SlideShare
0
From Embeds
0
Number of Embeds
1,930
Actions
Shares
0
Downloads
244
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Buenas practicas para el desarrollo de software

  1. 1. Mejoresprácticas en el desarrollo de software<br />Gustavo Bonalde, PMP<br />IBM RUP Certified<br />
  2. 2. Fundamentos RationalUnifiedProcess<br />ModeloCascadavsModeloIterativo<br />Gerencia de los Requerimientos<br />Componentesbasado en la Arquitectura<br />Modelado Visual<br />Verificación continua de la calidad<br />Gerencia del Cambio<br />
  3. 3. Requerimientos<br />Análisis<br />Diseño<br />Codificación<br />Pruebas<br />Modelo Cascada<br /><ul><li>Se crea retrasos en la identificación de riesgos
  4. 4. Dificulta el manejo de indicadores de progreso
  5. 5. Con frecuencia surgen importantes resultados en iteraciones imprevistas
  6. 6. Imposibilita el despliegue temprano</li></li></ul><li>Modelo Iterativo<br />Requerimientos<br />Análisis &<br />Diseño<br />Planificación<br />Implementación<br />Pruebas<br />Cada iteración,<br />significa una <br />mini-versión<br />funcional<br />Evaluación<br />Despliegue<br />
  7. 7. Riesgo en <br />Iterativo<br />Modelo Cascada vs. Iterativo<br />Riesgo<br />en Cascada<br />Riesgo<br />Reducción del riesgo<br />Tiempo<br />
  8. 8. Gerencia de los Requerimientos<br /> Uno de los principales factores que inciden en la baja tasa de éxito de los proyectos de software es una incorrecta definición de los mismos o un pobre manejo de ellos <br />Se debeasegurar:<br /><ul><li>Resolver el problemacorrecto
  9. 9. Construir el sistemacorrecto</li></ul>Sistemáticamente se debe:<br /><ul><li>elicitar
  10. 10. organizar
  11. 11. documentar
  12. 12. manejar</li></ul>Los cambios de requerimientos del software.<br />
  13. 13. Aspectos de la Gerencia de los Requerimientos<br />Análisis del problema<br />Comprensión de las necesidades de los usuarios<br />Definición del sistema<br />Manejo del alcance<br />Refinamiento de la definición del sistema<br />Gerencia del cambio en los requerimientos<br />
  14. 14. Registrar<br />subasta<br />vendedor<br />comprador<br />Traza de los Requerimientos<br />Problema u Oportunidad<br />+Abstracto<br />NECESIDAD<br />CARACTERÍSTICAS<br />REQUERIMIENTOS<br />
  15. 15. Componentes basado en la Arquitectura<br />Se trata de un nuevo proceso de arquitectura empresarial para proveer aplicaciones. Propone un enfoque de “plug & play” para enfrentar las soluciones<br />En lugar de una orientación de soluciones a la medida, propone una metodología de “diseño, codificación y prueba”<br />Tiempos más cortos, menores riesgos y sistemas modulares y adaptativos<br />Permite seleccionar de componentes <br /> comerciales disponibles<br />
  16. 16. Modelado Visual<br />Captura la estructura y el comportamiento del sistema<br />Muestra como se engranan todos los elementos del sistema<br />Mantiene consistencia entre el diseño y la implementación<br />Evita la ambigüedad en la comunicación<br />Forward and Reverse Engineering<br />
  17. 17. Verificación continua de la calidad<br />Conseguir y reparar los problemas de software luego de su puesta en producción,<br />Es de 100 a1000 veces más costoso<br />Costo<br /><ul><li>Costo de reparación de fallas
  18. 18. Costo de pérdida de oportunidades
  19. 19. Costo de pérdida de clientes</li></ul>Fases del Desarrollo<br />
  20. 20. Verificación continua de la calidad<br />La calidad se toma en cuenta a los largo de todo el proyecto<br />Las pruebas se planifican para cada iteración<br />Cada caso de uso se acompaña de un caso de prueba<br />El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente<br />
  21. 21. Gerencia del Cambio<br />Manejo de las requisiciones de cambio<br />Gerencia de la configuración<br />Traza de los cambios<br />Selección de versión<br />Manufactura de software<br />
  22. 22. Resumen<br />Existen un conjunto de síntomas asociados a los problemas que se generan comúnmente en el desarrollo de software, los cuales se pueden observar como resultados de unas causas principales<br />Seis mejores prácticas en el desarrollo de software, probadas comercialmente, atacan estas causas:<br />Desarrollar de manera iterativa<br />Administrar Requerimientos<br />Usar Arquitecturas basadas en componentes<br />Modelar visualmente el software<br />Verificación continua de la calidad del software<br />Controlar los cambios hechos al software<br />
  23. 23. Gustavo Bonalde, PMP<br />PROJECT MANAGEMENT PROFESSIONALPMI<br />IBM Certified Solution Designer Rational Unified Process v 7.0<br />IBM Certified Specialist Rational Requirements Management w/Use Cases v2003<br />IBM Certified Specialist for Rational Unified Process v2003<br />http://gbonalde.blogspot.com/<br />gustavo.bonalde@gmail.com<br />

×