IDEAL step by step

50 %
50 %
Information about IDEAL step by step
Technology

Published on October 17, 2007

Author: nopiedra

Source: slideshare.net

Description

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

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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Step by Step Schulranzen ideal für Grundschulkinder ...

Rückenfreundliche Ausstattung, Sicherheit auf dem Schulweg & bunte Designs das sind Step by Step Schulranzen. Wählen Sie gemeinsam mit Ihrem Kind aus.
Read more

Step by Step Touch ab 46,53 € | Preisvergleich bei idealo.de

Bereits ab 46,53 € Große Shopvielfalt Testberichte & Meinungen | Jetzt Step by Step Touch Schultasche & Ranzen günstig kaufen bei idealo.de
Read more

Ideal & Ideal Step - mott: Home

Ideal & Ideal Step Stage coverings Ideal & Ideal Step ... in a wide range of materials for interior and exterior areas 18000 Beech - blackboard medium ...
Read more

Step Waschtisch-Unterschrank von Ideal Standard | Architonic

Step Waschtisch-Unterschrank von Ideal Standard auf Architonic! Hier finden Sie Bilder & Informationen sowie Händler, Kontakt- und Anfrageoptionen für ...
Read more

Step | Möbel von Ideal Standard | Step ..

Ausführliche Informationen über das Produkt Step, Möbel von Ideal Standard mit Angaben über Bezugsquellen, grosser Bildergalerie und vielen ..
Read more

Relationship Corner: Step by Step, The Ideal Way to Get a ...

Relationship Corner: Step by Step, The Ideal Way to Get a Girlfriend ... A Step-by-Step Guide to Turning Random 'Acquaintances' into Friends ...
Read more

Klappbühne "Ideal Step" | Mott Metallwaren und Bühnenbau ...

Klappbühne wie Ideal – aber mit stufenlos, verstellbaren Fußhöhen. Für den Innen- und Außenbereich stehen die unterschiedlichsten Bühnenböden zur ...
Read more

Rockport Step Collection - Ideal Concrete Block Co

IDEAL CONCRETE BLOCK CO. STEPS WITH STYLE ™ PAVERS BY IDEAL Rockport ™ Step Collection
Read more