• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Buenas practicas para el desarrollo de software
 

Buenas practicas para el desarrollo de software

on

  • 10,587 views

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

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

Statistics

Views

Total Views
10,587
Views on SlideShare
8,813
Embed Views
1,774

Actions

Likes
0
Downloads
170
Comments
0

12 Embeds 1,774

http://blog.jmerinoh.com 1521
http://gbonalde.blogspot.com 218
http://static.slidesharecdn.com 8
http://gbonalde.blogspot.mx 8
http://www.linkedin.com 5
http://gbonalde.blogspot.de 4
http://gbonalde.blogspot.com.es 3
http://feeds.feedburner.com 2
http://gbonalde.blogspot.com.ar 2
http://webcache.googleusercontent.com 1
http://cc.bingj.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Buenas practicas para el desarrollo de software Buenas practicas para el desarrollo de software Presentation Transcript

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