Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

IDEAL step by step

on

  • 8,533 views

UTPL ESPOL October 2007 Course

UTPL ESPOL October 2007 Course
www.utpl.edu.ec
www.espol.edu.ec

Statistics

Views

Total Views
8,533
Views on SlideShare
7,596
Embed Views
937

Actions

Likes
6
Downloads
920
Comments
3

5 Embeds 937

http://nopiedra.wordpress.com 920
http://www.slideshare.net 13
http://webcache.googleusercontent.com 2
https://nopiedra.wordpress.com 1
url_unknown 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

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

IDEAL step by step IDEAL step by step Presentation Transcript

  • Herramientas de Mejora de Procesos de Sofware Tutorial: IDEAL Framework for Software Process Improvement Projects Escuela Politécnica del Litoral Universidad Técnica Particular de Loja C bnla www.utpl.edu.ec www.espol.edu.ec 4 y 5 de octubre del 2007
  • ... para empezar • Este tutorial describe un modelo para un programa de mejora de procesos de software, SPI (Software Process Improvement), que puede ser usado para guiar su desarrollo: planear, iniciar y manejar un programa de SPI. • Se provee a los gerentes una descripción genérica de un secuencia recomendada de pasos para efectuar un SPI.
  • Agenda • Introducción • Contexto • Overview • Fase de Inicio • Fase de Diagnóstico • Fase de Establecimiento • Fase de Acción • Fase de Aprendizaje • Preguntas & Respuestas
  • ¿En qué sector trabaja? • Gobierno • Contratistas del gobierno • Industria • Academia • Investigación • etc.
  • ¿Quienes estamos aquí? • “Sponsors” • “Agents” • “Championes” • Participantes • Interesados • Curiosos • Otros
  • Objetivos del Tutorial • El objetivo de este taller es comunicar un camino de acciones que constituyan una iniciativa SPI (Software Process Improvement), basado en las experiencias del Software Engineering Institute (SEI). • Nosotros esperamos que las organizaciones personalicen los pasos que se señalarán en este taller, de acuerdo a sus recursos, visión y objetivos de negocio.
  • Contribuciones del SEI • IDEAL es fruto del trabajo del SEI con el Departamento de Defensa, gobierno de USA, y los clientes industriales. • SEI, ha contribuido directa e indirectamente en: Software Maturity Model, Software Process Assessment, Software Capability Evaluation, Organization capability Development, Software Process Measurement, and Software Process Definition
  • Descripción general • El modelo IDEAL divide en 5 fases a un SPI • Es un proceso iterativo continuo de pasos para un SPI • La longitud de tiempo de una iteración depende de cada organización. • Dependiendo de los recursos disponibles, muchas actividades pueden ser hechas paralelamente, así mismo las actividades se pueden realizar en fases diferentes. • En la práctica, las fronteras entre las fases de IDEAL no son tan claramente definidas como se presentan en el modelo
  • SPI exitoso & infraestructura • La infraestructura necesaria para un proyecto de SPI juega un rol significativo en el éxito o fracaso de una iniciativa de SPI. • Entender roles y responsabilidades no puede ser subestimado
  • IDEAL VS PDCA
  • Orígenes • Madurez de proyectos de Software Process Improvement SPI • Las adopciones de SPI demandaron información y guía de cómo hacer la mejora • Experiencia equipos multidisciplinarios formó la síntesis de conocimiento y experiencia • El tutorial desarrollado por el equipo se presentó en 1993, en el Software Engineering Symposium • El roadmap se publicó en 1996
  • dificultades frente a proyectos de SPI dificultad al seleccionar entre diferentes posibilidades de mejora Technology Adopters no usar las mejores prácticas de transición para introducir las mejoras seleccionadas tienen dificultad de entender las dificultades de la adopción Technology no proveen suficiente información en los servicios clave Developers que permitan soportar los procesos de adopción no consiguen tecnologías para soportar las prácticas, tan rápido como ellos quisieran
  • IDEAL Overview
  • Inicio • Se define el objetivo general del programa de SPI • Se establece la infraestructura de mejora inicial • Se definen inicialmente los roles y responsabilidades para la infraestructura • Se asignan los recursos iniciales • Se crea un plan de SPI que guiará las siguientes fases de la mejora: inicio, diagnóstico y establecimiento. • El programa de SPI es aprobado y quedan confirmados los recursos que se requieran más adelante • Se establecen un Management Steering Group (MSG) y un Software Engineering Process Group (SEPG) • Se comunica el inicio del SPI y se sugiere evaluación organizacional para levantar una línea de base
  • Diagnóstico • La organización arranca el camino hacia la mejora continua de los procesos de desarrollo de software. • Se inicia el plan de acción, SPI action plan, de acuerdo a la visión de la organización, planes estratégicos del negocio, lecciones aprendidas en esfuerzos previos de mejora, claves organizacionales, y objetivos. • Se ejecutan actividades de evaluación que permitan establecer la línea base del estado actual de la organización. • Los resultados y recomendaciones de la evaluación son alineados con los planes de esfuerzo de mejora que constan en el plan de acción.
  • Establecimiento • Se priorizan las cosas que la organización decida mejorar • Se desarrollan las estrategias que permitan alcanzar las soluciones • El SPI action plan draft se completa de acuerdo a la visión de la organización, planes estratégicos del negocio, lecciones aprendidas en esfuerzos previos de mejora, claves organizacionales, y objetivos. • Se desarrollan los objetivos medibles a partir de los objetivos generales que se definieron en la fase de inicio, éstos objetivos medibles son incluidos en la versión final del SPI action plane. • Se definen las métricas para monitorear el progreso. Se asignan recursos y entrenamiento al technical working group (TWG) • El plan de acción desarrollado guiará las actividades de SPI, priorizando hallazgos y recomendaciones encontrados en el Diagnóstico. • Se crean los templates de los planes de acción táctico y se entregan al TWG para que sean completado y seguidos
  • Acción • Las Soluciones que se aplican a la áreas de mejora, determinadas en la fase de diagnóstico, son creadas, piloteadas, y deployadas en la organización. • Los planes se desarrollan para que se ejecuten pilotos de test y se pueda evaluar el nuevo proceso o el proceso mejorado. • Después de que el pilotaje del nuevo proceso haya sido exitoso se inicia la adopción, deployment, e institucionalización; a partir de esto se desarrollan y ejecutan los planes de rollaup.
  • Liberación/aprendizaje • El objetivo es que el siguiente ciclo de IDEAL se más efectivo • Las soluciones han sido desarrolladas, las lecciones han sido aprendidas, las métricas de rendimiento y objetivos alcanzados son documentados. • Es importante recolectar toda la información posible, para que se puedan evaluar las estrategias, métodos e infraestructura que se utilizaron en el programa de SPI ejecutado. Se debe tener en cuenta que en ocasiones es necesario corregir y/o ajustar estrategia, métodos e infraestructura.
  • Fase de INICIO
  • Propósito • Reconocer y entender el estímulo de mejora • Establecer contexto y establecer sponsorship para el programa SPI • Lanzar el programa SPI teniendo conocimiento sobre los costos y beneficios • Comprometer la disponibilidad de recursos necesarios • Establecer la infraestructura inicial necesaria para implementar y manejar el programa
  • Objetivos • Desarrollar el conocimiento, habilidad e inteligencias iniciales para iniciar el SPI • Determinar si se tiene un OK para proceder • Crear el propósito del programa de SPI, establecer las necesidades del SPI, el ámbito del programa, y los requerimientos de recursos • Recomendar un plan e infraestructura para manejar el programa de SPI
  • Educación/habilidades MSG: Master Steering Group SEPG: Software Engineering Process Group
  • Compromisos del Senior Management: • Permitir al equipo de descubrimiento (discovery team) formar y explorar los aspectos del SPI y desarrollar el propósito del SPI; dotarles de recursos/facilidades. • Confirmar el propósito del SPI • Asignar recursos al SEPG • Crear y asignar recursos para la infraestructura del SPI
  • Compromisos de la línea de Stakeholders gerente: • Comprometer el tiempo y esfuerzo de su participación en SPI • Estructurar y comprometer el tiempo del MSG • Estructurar y comprometer recursos para SEPG Software Engineering Process Group. • Planear la gestión del programa de SPI y desarrollar la estrategia de los siguientes pasos • Comprometer el tiempo de los técnicos (practitioners) para participar en el technical working groups (TWGs).
  • Criterios de Entrada • Las organizaciones debe iniciar un programa de SPI para mantener y mejorar sus ventajas competitivas. • Criterios clave de entrada: • Deben existir y ser cuidadosamente entendidos los procesos de desarrollo de software que mejoren las necesidades críticas del negocio • Deben estar identificados los Champions que impulsarán el SPI
  • Criterios de Salida • Se ha establecido la infraestructura inicial del SPI, establecido/reforzado los sponsors y se promueven los conceptos y actividades del SPI • La organización ha enlazado la iniciativa de SPI con las estrategias organizacionales. • Inicial el organization communication plan para que la iniciativa de SPI
  • Actividades Fase de Inicio • Estímulo para el cambio • Establecer contexto • Construir Sponsorship • Diagramar infraestructura
  • Estímulo para el cambio • La naturaleza del estímulo puede variar ampliamente: • Reacción a eventos/circunstancias • Orden • Una respuesta proactiva • El estímulo puede tener influencia en el cambio de visibilidad del esfuerzo, conducir y alcanzar el éxito
  • Establecer contexto • Establecer claramente sobre lo que se va a cambiar dentro de la organización • Requiere estar alineado con: • La misión de la organización • Metas y objetivos organizacionales • La visión de futuro, ser coherente • La estrategia trazada para alcanzar la visión • Modelos referentes • El contexto e implicaciones serán más claros.
  • Construir “Sponsorship” • Sponsorhip es obtener el soporte a nivel senior • Los sponsors son más efectivos si ellos: • Dan personal atención al esfuerzo • Brindan apoyo cuando el cambio atraviesa por tiempos dificiles • Direccionan los recursos necesarios hacia el esfuerzo de mejora • Cambian su propio comportamiento para ser consistentes con los cambios que están siendo implementados • Modifican el sistema establecido • Es un elemento crítico que contribuye hacia el éxito • Debe ser sostenido
  • Establecer Infraestructura • Implementar el cambio frecuentemente requiere de estructuras organizacionales. • La infraestructura debe incluir: • Un grupo de apoyo (senior level people) • Un grupo agente del cambio • Uno o más grupos de trabajo técnicos (TWGs, Technical Working Groups) • Establecer estos grupos implica desarrollar un acuerdo escrito en el que se expliciten las responsabilidades de cada uno. • Usualmente no es posible establecer el TWGs durante la fase de inicio.
  • Fase de DIAGNÓSTICO
  • Actividades Fase DIAGNÓSTICO • Estímulo para el cambio • Establecer contexto • Construir Sponsorship • Diagramar infraestructura
  • Errores clásicos en la Industria del Software
  • Sobre nuestros proyectos • Dos tercios de los proyectos se realizan fuera de coste y plazo • Grandes proyectos suelen tener un retraso de entre el 25% y el 50% • Cuanto mayor es el proyecto mayor probabilidad de cancelación • Si se hace un encuesta es altamente probable que el 40% de las empresas encuestadas tuvieran un proyecto fuera de control en un año
  • que explicaciones tenemos... • Dificultad para planificar costes y plazos • Rota la planificación no se recupera el tiempo perdido • Calidad insuficiente de los productos • Prestaciones inadecuadas • Grandes dificultades de mantenimiento • Se pierden concursos por no conocer el cliente y/o la competencia
  • ... cómo evitar esto • Las dificultades técnicas pueden evitarse con buenas prácticas de ingeniería. • Pero... • Muchos de estos problemas tienen el origen en la gestión • Los problemas de gestión no pueden solucionarse técnicamente • Sin embargo, tienen graves efectos en el plano técnico
  • Los 36 errores clásicos de la gestión de proyectos Mc Connell
  • Personas Producto Tecnología Proceso Evitar los errores clásicos elimina muchos problemas Cometer un sólo error clásico genera muchos problemas
  • 1 Personas • Motivación débil • Motivación: es el primer factor sobre la productividad y la calidad • Personal mediocre • El segundo factor más importante • Contratar rápido para empezar rápido • Diferencias de productividad de 1 a 10 • Empleados problemáticos incontrolados • Hazañas • No se deben premiar actitudes de tipo “ser capaz de”Premiar progresos consistentes e informes realistas • Las actitudes “ser capaz de”convierten pequeños contratiempos en grandes desastres
  • 2 Personas • Añadir personal a un proyecto retrasado • El error más clásico • Oficinas repletas y ruidosas • Fricciones entre clientes y los desarrolladores del proyecto • El desarrollador no acepta el plan de trabajo • El cliente cambia los requisitos • Conflictos de personalidad • Todo ello lleva a la mala comunicación • internos (StandishGroup, 1994)
  • 3 Personas • Expectativas poco realistas • Causa frecuente de fricciones cliente/desarrollador • Si no hay razones para pensar que un plazo es realista, entonces no lo es • Presupuestar / competir basándose en estimaciones deliberadamente optimistas • Expectativas realistas: uno de los 5 factores principales para el éxito de proyectos • Falta de un promotor efectivo del proyecto • Si no, se forzarán plazos poco realistas • La falta de promotor lleva al fracaso casi asegurado del proyecto
  • 4 Personas • Falta de participación de los implicados (stakeholders) • Deben implicarse promotores, comerciales, usuarios, clientes, etc • Falta de participación del usuario • Mal entendimiento de los requisitos • Tiempo empleado en requisitos innecesarios • Política antes que desarrollo (sustancia) • Equipos: políticos, investigadores, aislacionistas, generalistas • Primar política sobre resultados: malo para desarrollo rápido • Ilusiones • Cerrar los ojos y esperar que todo funcione, sin razón para ello • Problema fundamental y extremadamente frecuente
  • 1 Proceso • Planificación insuficiente • Insuficiente esfuerzo de estimación • Insuficiente esfuerzo al determinar tareas • Abandono de la planificación bajo presión • El problema no es abandonar un plan ... • ...el problema es no adoptar otro • Pérdida de tiempo en el inicio difuso • Escatimar en las actividades iniciales • “No hemos tenido tiempo para hacer un buen diseño” • Coste: de 10 a 100 veces superior
  • 2 Proceso • Planificación excesivamente optimista • El proyecto fracasará • Hay que estropear la planificación • Ahorrar en análisis / diseño / calidad • Presión sobre los desarrolladores (moral, productividad) • Gestión de riesgos insuficiente • Muchas veces no se realiza • Fallos del contratista • Requisitos cambiantes • Diseño Inadecuado • Controles de gestión insuficiente
  • 3 Proceso • Escatimar en aseguramiento de calidad • Eliminando revisiones, pruebas, ... • 1 día menos de QC (Control de calidad) al principio lleva de 3 a 10 días de QC al final (CapersJones, 1994) • Convergencia prematura o excesivamente frecuente • Omitir tareas necesarias en la estimación • Aumento del plan entre el 20% y el 30% (según Van Genuchten, 1991) • Planificar ponerse al día más adelante • Nunca se llega a dar • La respuesta adecuada es replanificar
  • Producto • Exceso de requisitos • Con frecuencia se pide más de lo que se necesita • Cambio de requisitos • Un proyecto sufre una media de 25% de cambios durante el desarrollo (CapersJones, 1994) • Desarrolladores meticulosos • Desarrollo/tecnología innecesaria • Tiras y aflojas en la negociación • Te permito que acabes más tarde de los previsto ... • ...pero a cambio quiero que me añadas estas prestaciones • Desarrollo orientado a la investigación
  • Tecnología • Síndrome de la panacea (de la bala de plata) • Esta tecnología es buenísima ...y vale para todo • Sobreestimación de las ventajas de las herramientas o métodos • Con esta herramienta podemos hacer ... • Cambiar de herramientas a mitad del proyecto • Vamos a cambiar a ...que es mucho mejor • Falta de manejo automatizado de código fuente
  • Universidad Técnica Particular de Loja Escuela de Ciencias de la Computación Nelson Piedra http://nopiedra.wordpress.com nopiedra@utpl.edu.ec C bnla www.utpl.edu.ec www.espol.edu.ec 4 y 5 de octubre del 2007