• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clase 4, 29/8/2007
 

Clase 4, 29/8/2007

on

  • 1,804 views

 

Statistics

Views

Total Views
1,804
Views on SlideShare
1,785
Embed Views
19

Actions

Likes
0
Downloads
92
Comments
0

4 Embeds 19

http://ici313-2-2007.blogspot.com 16
http://www.ici313-2-2007.blogspot.com 1
http://www.slideshare.net 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike 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

    Clase 4, 29/8/2007 Clase 4, 29/8/2007 Presentation Transcript

    • Metodologías de Análisis Clase 4 – 29/8/2007 Christian Sifaqui
    • Modelos de ciclos de vida
      • Modelo de ciclo de vida (o modelo del proceso)
      • El desarrollo de software, las actividades operativas y su ordenamiento temporal
      • - requerimientos
      • - especificación
      • - diseño
      • - implementación
      • - integración
      • - mantención
      • - retiro
    • Proceso
      • Un proceso define QUIÉN hace QUÉ, CUÁNDO y CÓMO en el desarrollo de un sistema de software
      • - roles y workflows
      • - productos
      • - hitos
      • - guías
      • - etc.
      Requerimientos nuevos o cambiados Sistema nuevo o cambiado Proceso de ingeniería de software
    • Proceso vs. Producto Participantes Resultado Herramientas Modelo del proceso Proyecto Personas Producto Automatización Template
    • Proceso Herramientas y equipamiento Personas con habilidades, entrenamiento y motivación Proceso Procedimientos y métodos que definen las relaciones de las tareas
    • Proceso efectivo
      • - Provee guías para desarrollo eficiente de software de calidad
      • - Reduce riesgo e incrementa predictibilidad
      • - Captura y presenta “best practices”
      • - Promueve una visión común y cultura
      • - Provee un mapa para usar herramientas
      • - Entrega información en línea
    • Procesos livianos vs. pesados Pesados (por ejemplo, Proceso-V) Ágiles , livianos (por ejemplo, programación extrema XP) Framework customizable (por ejemplo, RUP) Orientado al documento Elabora definiciones de workflow Muchos roles diferentes Muchos chequeos Sobrecarga alta de administración Altamente burocrático Enfocado al código en vez que a la documentación Enfocado en comunicación directa (entre desarrolladores y desarrolladores y los clientes) Baja sobrecarga de administración
    • Elección de proceso
      • - El proceso usado debería depender del tipo de producto que se desarrollará
      • para sistemas grandes, la administración es usualmente el principal problema, por lo que se necesita un proceso administrado estrictamente. Para sistemas pequeños, se permite mayor informalidad
      • - Se podría incurrir en costos altos si se fuerza un proceso inapropiado a un equipo de desarrollo
    • Otros ciclos de vida
      • Codificar-y-arreglar
      • Cascada
      • Prototipo rápido
      • Programación extrema y procesos ágiles
      • Sincronizar-y-estabilizar
      • Espiral
      • Híbrido
    • Codificar-y-arreglar
      • - sin diseño
      • - sin
      • especificaciones
      •  ¿mantención?
      Implementar la primera versión Modificar hasta que el cliente quede satisfecho Mantención post-entrega Retiro Desarrollo Mantención
    • Codificar-y-arreglar
      • la manera más fácil de desarrollar software
      • de la forma más cara
    • Cascada Requerimientos Análisis Diseño Implementación Mantención post-entrega Requerimientos cambiados Retiro Desarrollo Mantención
    • Cascada
      • Caracterizada por:
      • ciclos de retroalimentación
      • guiado por documentación
      • Ventajas
      • documentación
      • mantención es más fácil
      • Desventajas
      • documento de especificación
    • Prototipo rápido
      • - modelo lineal
      • - “rápido”
      Prototipo rápido Análisis Diseño Implementación Mantención post-entrega Requerimientos cambiados Retiro Desarrollo Mantención
    • Open-source
      • Dos fases informales
      • Primera fase : una persona construye una versión inicial
      • que publica vía Internet (por ejemplo, SourceForge.net)
      • Si hay suficiente interés en el proyecto:
      • - se baja masivamente la versión inicial
      • - usuarios se convierten en co-desarrolladores
      • - el producto se extiende
      • OBS: los individuos trabajan por lo general en forma voluntaria en sus tiempos libres
    • Open-source
      • Segunda fase :
      • Se reportan y corrigen defectos (mantención correctiva)
      • Se agrega funcionalidad adicional (mantención perfectiva)
      • Se porta el programa a nuevos ambientes (mantención adaptativa)
      • La segunda fase informal consiste solamente de mantención post-entrega
    • Open-source
      • Modelo de mantención post-entrega
      Implementar la primera versión Mantención post-entrega correctiva, perfectiva y adaptativa Retiro Desarrollo Mantención
    • Open-source
      • Software cerrado se mantiene y testea por empleados de la organización
      • Open-source generalmente es mantenido por voluntarios
      • OBS: Linus’s Law
      • complejidad ciclomática de McCabe
    • Open-source
      • Grupo core:
      • - pequeño número de mantenedores dedicados
      • responsables de administrar el proyecto
      • - tienen la autoridad de instalar parches
      • Grupo periférico:
      • usuarios que deciden enviar reportes de errores de vez en cuando
    • Open-source
      • Nuevas versiones de software propietario se entregan, por lo general, una vez al año, después de una revisión del grupo SQA
      • El grupo core libera una nueva versión del producto open-source tan pronto como esté lista:
      • - quizás un mes o días después de la versión anterior
      • - el grupo core hace test mínimos
      • - el testing extenso lo realiza el grupo periférico usando el software
      • - “release early and often”
    • Open-source
      • Una versión inicial se produce al usar:
      • - el modelo de “prototipo rápido”
      • - el modelo “codificar-y-arreglar”
      • - el modelo “Open-source”
      • Y después:
      • - modelo de “prototipo rápido”
      • la versión inicial se descarta
      • -modelo “codificar-y-arreglar” y “Open-source”
      • la versión inicial se convierte en el producto
    • Open-source
      • Por lo tanto en un proyecto open-source, por lo general no hay especificación ni diseño
      • ¿Cómo estos proyectos open-source han sido tan exitosos al no tener especificación ni diseño?
    • Open-source
      • La producción de software open-source ha atraído a algunos de los mejores expertos de software en el mundo
      • (ellos pueden funcionar efectivamente sin especificación ni diseño)
      • Sin embargo, se podría llegar a un punto en que el proyecto open-source no sea mantenible
    • Open-source
      • el modelo open-source tiene sus restricciones
      • pero ha sido extremadamente exitoso para proyectos de infraestructura:
      • - sistemas operativos (GNU/Linux, OpenBSD, Mach, Darwin)
      • - navegadores (Firefox, Netscape)
      • - compiladores (gcc)
      • - servidores web (apache, zope)
      • - administradores de bases de datos (MySQL, PostgreSQL)
    • Open-source
      • no puede haber desarrollo open-source de un producto de software para ser usado en una sola organización
      • (los miembros del grupo core y periférico son los usuarios del software que se desarrolla)
      • el modelo open-source es inaplicable a menos que el producto sea visto por un gran número de usuarios como útil
    • Open-source
      • al menos la mitad de los proyectos open-source disponibles no han atraído a un equipo para trabajar en éste
      • incluso si el trabajo se inicia, puede que no se complete el trabajo
      • pero donde el modelo open-source ha funcionado, ha mostrado ser extremadamente exitoso
      • (los proyectos mencionados anteriormente son usados por millones de usuarios)
    • Procesos ágiles
      • una nueva aproximación controversial
      • historias (muestra lo que quiere el cliente)
      • - estimar duración y costo de cada historia
      • - elegir historia para la siguiente construcción
      • - cada construcción se divide en tareas
      • - casos de test para una tarea se diseñan primero
      • Programar de a par
      • Integración continua de tareas
    • Procesos ágiles
      • “ Programación extrema (XP)”
      • los computadores se ponen al centro de una oficina larga alineada con cubículos
      • un representante del cliente está siempre presente
      • profesionales del software no pueden hacer horas extras más de dos semanas consecutivas
      • no hay especialización
      • refactoring (modificación al diseño)
    • Procesos ágiles
      • “ Programación extrema (XP)”
      • YAGNI (you aren’t gonne need it)
      • DTSTTCPW (do the simplest thing that could possibly work)
      • un principio de XP es minimizar el número de características
      • (no hay necesidad de construir un producto que hace más que lo que el cliente necesita)
    • Procesos ágiles
      • “ Programación extrema (XP)”
      • XP es sólo una de un nuevo conjunto de paradigmas llamados procesos ágiles
      • en febrero de 2001 se redactó el manifesto for Agile Software Development
      • la Agile Alliance no receta un modelo de ciclo de vida específico
      • (sólo expone un grupo de principios subyacentes)
    • Procesos ágiles
      • Los procesos ágiles son una colección de nuevos paradigmas caracterizados por:
      • - menor énfasis en análisis y diseño
      • - implementaciones tempranas (el software funcionando es considerado más importante que la documentación)
      • - proactivo al cambio
      • - colaboración cercana con el cliente
    • Procesos ágiles
      • un principio del Manifesto es
      • - entregue software frecuentemente
      • - idealmente cada 2 ó 3 semanas
      • una manera de lograr esto es usar timeboxing
      • (usado por muchos años como una técnica de administración del tiempo)
      • se asigna una cantidad específica de tiempo a una tarea:
      • - típicamente 3 semanas para cada iteración
      • - los miembros del equipo hacen su mejor trabajo durante ese tiempo
    • Procesos ágiles
      • entrega al cliente la confianza de saber que una nueva versión con funcionalidad llegará cada 3 semanas
      • los desarrolladores saben que tendrán 3 semanas (y no más) para entregar una nueva iteración
      • (sin interferencia del cliente)
      • si es imposible entregar la tarea completa en el tiempo, el trabajo podría ser reducido (descoped)
      • (procesos ágiles demandan tiempo fijo, no características fijas)
    • Procesos ágiles
      • otro rasgo común de los procesos son las reuniones de pie
      • - reuniones cortas que se efectúan a una hora cada día
      • - se requiere asistencia
      • los participantes están en un círculo
      • - no se sientan en una mesa
      • - para asegurar que la reunión no dure más de 15 minutos
    • Procesos ágiles
      • En una reunión de pie, cada miembro del equipo se turna para responder 5 preguntas
      • ¿Qué hice desde la reunión de ayer?
      • ¿En qué estoy trabajando hoy?
      • ¿Qué problemas tengo para alcanzar esto?
      • ¿Qué hemos olvidado?
      • ¿Qué aprendí que podría compartir con el equipo?
    • Procesos ágiles
      • el objetivo de una reunión de pie es:
      • - detectar problemas
      • - no de resolverlos
      • las soluciones se encuentra en reuniones de continuación, que se efectúan directamente después de la reunión de pie
    • Procesos ágiles
      • procesos ágiles han tenido algún éxito en desarrollo de software a pequeña escala:
      • (sin embargo, desarrollo de software mediano y grande es muy diferente)
      • la clave: el impacto de los procesos ágiles en mantención post-entrega:
      • - refactoring es una componente esencial en procesos ágiles
      • - refactoring continúa durante la mantención
      • - ¿incrementa el refactoring el costo de post-mantención, como lo indica la investigación preliminar?
    • Procesos ágiles
      • procesos ágiles son buenos cuando los requerimientos son vagos o cambiantes
      • es muy pronto para evaluar procesos ágiles:
      • (no hay suficientes datos)
      • incluso si los procesos ágiles fueran decepcionantes
      • (algunas características –como la programación de a pares- podría ser adoptada por prácticas comunes de ingeniería de software)
    • Procesos ágiles Redactar tests Planificación Test Programación de a par + Refactoring Integración Mínimo diariamente cada 2-3 semanas Release
    • Sincronizar-y-estabilizar
      • modelo de ciclo de vida de Microsoft
      • análisis de requerimientos – entrevistar clientes potenciales
      • redactar especificaciones
      • dividir el proyecto en 3 ó 4 construcciones
      • cada construcción se lleva a cabo por pequeños equipos trabajando en paralelo
    • Sincronizar-y-estabilizar
      • al final del día – sincronizar (test y debug)
      • al final de la construcción – estabilizar (congelar la construcción)
      • componentes siempre trabajan juntos
      • (se obtienen vistas tempranas de la operación de producto)
    • Espiral
    • Espiral
      • si no se pueden mitigar todos los riesgos, el proyecto se termina inmediatamente
    • Espiral
      • preceder cada fase con:
      • - alternativas
      • - análisis de riesgo
      • continuar cada fase con:
      • - evaluación
      • - planificación de la siguiente fase
      • dimensión radial: costo acumulado a la fecha
      • dimensión angular: progreso a través de la espiral
    • Espiral
      • Fortalezas:
      • - es fácil decidir cuánto testear
      • - no hay distinción entre desarrollo y mantención
      • Debilidades:
      • - sólo para software de gran escala
      • - sólo para software interno (in-house)
    • Modelos de ciclos de vida
      • Criterios para decidir por un modelo:
      • - la organización
      • - su administración
      • - las habilidades de los empleados
      • - la naturaleza del producto
    • Híbrido
      • Probar mezclar modelos
      • - Sistemas grandes están hechos de algunos sub-sistemas
      • - El mismo modelo no necesita ser aplicado en todos los sub-sistemas
      • - Prototipado para especificaciones altamente riesgosas
      • - Modelo cascada para desarrollos claros
      • - Adaptar el proceso al problema
    • Otros
      • - RUP
      • - V-Modell XT
      • - …
      • Adicionalmente
      • - PSP (Personal Software Process)
      • - TSP (Team Software Process)
      • Finalmente
      • - CMMI
      • - Model IDEAL
    • Modelos de ciclos de vida Guiada por documentos Producto entregado podrían no satisfacer las necesidades del cliente Aproximación disciplinada Cascada Insatisfactorio para programas no triviales Bueno para pequeños programas que no requieren mantención Codificar-y-arreglar Subyacente al proceso unificado Modela cercanamente la producción de software del mundo real Iterativo-e-incremental Equivalente al modelo iterativo-e-incremental Modela cercanamente la producción de software del mundo real Árbol de evolución Debilidades Fortalezas Modelo de ciclo de vida
    • Modelos de ciclos de vida No ha sido probado fielmente Asegura que el producto entregado concuerda con las necesidades del cliente Prototipo rápido Desarrolladores deben ser competentes en análisis de riegos y evolución del riesgo Puede ser usado sólo en producto internos de gran escala Orientada al riesgo Espiral Asegura que las componentes se puedan integrar exitosamente No ha usado en otra parte distinta a Microsoft Necesidades futuras de los usuarios se satisfacen Sincronizar-y-estabilizar Parece funcionar sólo en proyectos de pequeña escala Funciona bien si los requerimientos del cliente son vagos Procesos ágiles Usualmente no funciona Aplicación limitada Ha funcionado muy bien en un pequeño número de instancias Open-source Debilidades Fortalezas Modelo de ciclo de vida