IDEAL step by step

7,457 views

Published on

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

Published in: Technology, Economy & Finance
3 Comments
8 Likes
Statistics
Notes
No Downloads
Views
Total views
7,457
On SlideShare
0
From Embeds
0
Number of Embeds
1,071
Actions
Shares
0
Downloads
968
Comments
3
Likes
8
Embeds 0
No embeds

No notes for slide

IDEAL step by step

  1. 1. 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 UNIVERSIDAD TECNICA PARTICULAR DE LOJA £. . . ».4 . ..A_. .< _. ‘.-. f,_. », L: _. www. u(pl. edu. ec www. espo| .edu. ec 4 y 5 de octubre del 2007
  2. 2. e HERR/ XMILNTAS PARA l A MEJOR/ DE PROCESOS DE SOFTWARE Vmvrrv 114- . m-- ‘ ~| |'vuln -w--; ~.u, . . Il! -vgvlav ru-«.1,-v. l'. on Ir-s , u was. “ Ur H. -u. . no 2 "I-mu v-mu: m.J. nn1.uN. 'I n; .;: ..y. m.». .m. ‘.. .u, ,r . ,.. . m, .L, .,. ..‘m, , _. ‘,, ,,. 1.11-tnp. -nnwmu . -r. rwh‘ 1,. ..-. .-, um. m-. -r M Eon fi; :vrIu444v. ,- , - .1’. pow-1>—HvI . .. wm» r| xw| v:d1": ' w L~; zs, x:: ¥**: ::: . ls. Nelx'n:1 Media 37” PW"“i"373[“5 lug. Marla Bclcn . lL>ra 5(’01’—”'-’d‘-““"~‘ Inteve>nL$m I-n mg: -.1r. :r: c m -‘A-' - ‘WJMLJMI: .1 V. »:u2?: '» u: - 226931)-1 E‘| V|.1'LAl‘n’I‘IrlDI'| : '1 < .2 cam : 1n~: u:xcn vnu<iu~I| espol. edu. ¢< ESCUELA SUPERIOR POUTECNICA DEL UTORAP Campus Gustavo Galindo, Prospenna. Km. 30.5 Via F’ef| m€"3‘ Guayaquil, Ecuador
  3. 3. para empezar 4* 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. 9 Se provee a Ios gerentes una descripcion genérica de un secuencia recomendada de pasos para efectuar un SPI.
  4. 4. Agenda Introduccion Contexto Overview Fase de lnicio Fase de Diagnostico Fase de Establecimiento Fase de Accién Fase de Aprendizaje Pregu ntas & Respuestas
  5. 5. gEn qué sector trabaja? Gobierno Contratistas del gobierno lndustria Academia Investigacién etc .
  6. 6. 1% '—1i . . . ,1: L »Il¢. IiIIl, '"‘flIl? i~. ‘: ‘ 7'= .li"TtTi~ifI; i*-. lIIi(; i.: ‘ inir. aa-'; m:n~: icx: ‘ ” ; I.I"’r 3.14: NZ" L‘
  7. 7. Objetivos del Tutorial ‘IF 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 Ios pasos que se sefialaran en este taller, de acuerdo a sus recursos, vision y objetivos de negocio.
  8. 8. Contribuciones del SEI ii 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
  9. 9. The IDEALSM Model Leaming Pro pr; se Future Actions Acting Ollmulusler set Build Chener Clllnge Context Sponsorship hfnstructure Initiating ‘W IDEAL I: a service mark of Cemegie Mellon University
  10. 10. Descripcion 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 iteracion depende de cada organizacion. Dependiendo de los recursos disponibles, muchas actividades pueden ser hechas paralelamente, asi mismo las actividades se pueden realizar en fases diferentes. En la practica, las fronteras entre las fases de IDEAL no son tan claramente definidas como se presentan en el modelo
  11. 11. SPI exitoso & infraestructu ra ii La infraestructura necesaria para un proyecto de SPI juega un rol significativo en el éxito o fracaso de una iniciativa de SPI. 4% Entender roles y responsabilidades no puede ser subestimado
  12. 12. IDEALVS PDCA r‘- CE Anmyzc Propose 3"“ Fmum Validate lmpmmm“ Actions Solution ». v , ,_ I, .1 II 3‘ J 1 . Refine solution stimulus for set Build Charter PIIOI/ '7'? !‘ “ N , Change Context Sponsorship Infrastructure 5°'”“°" -1 J Cmate Charactarlze sohmon Current 6 , I . Dashed pm" ‘Ill 5‘-‘"0’ Actions Develop Racommenw Develop atlons 3“ Approach Priorities
  13. 13. Origenes Madurez de proyectos de Software Process Improvement SPI Las adopciones de SPI demandaron informacién y guia de como hacer la mejora Experiencia equipos multidisciplinarios formé Ia sintesis de conocimiento y experiencia El tutorial desarrollado por el equipo se presento en I993, en el Software Engineering Symposium El roadmap se publico en I996
  14. 14. dificultades frente a proyectos de SPI dificultad al seleccionar entre diferentes posibilidades Technology Cle melora Ad°Pt°r5 no usar las mejores practicas de transicion para tienen diflcultad de entender las dificultades de la adopcion Technology Developers no provccn suficicntc information on Ios servicios clavc no consigucn tecnologias para soportar las practicas. tan rapido como ellos quisieran
  15. 15. IDEAL Overview
  16. 16. / C‘:1rv v , Zsonnorfio hi-xarunme . " Se define el objetivo general del programa de SPI Se establece la infraestructura de mejora inicial Se definen inicialmente Ios roles y responsabilidades para la infraestructura Se asignan Ios recursos iniciales Se crea un plan de SPI que guiara las siguientes fases de la mejora: inicio, diagnostico y establecimiento. El programa de SPI es aprobado y quedan confirmados Ios recursos que se requieran mas 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 linea de base
  17. 17. Diagnostico Diagnosing La organizacion arranca el camino hacia Ia mejora continua de Ios procesos de desarrollo de software. So inicia el plan dc accion. SPI action plan, dc acuerdo a la vision de la organizacion. planes estratégicos del negocio. lecciones aprendidas en esfuerzos previos de mejora. claves organizacionales, y objetivos. Se ejecutan actividades de evaluacion que permitan establecer Ia linea base del estado actual de la organization. Los resultados y recomendaciones de la evaluacion son alineados con Ios planes de esfuerzo de mejora que constan en el plan de accion.
  18. 18. Establishing Sc priorizan las cosas que la organizacion decida mcjorar Se desarrollan las estrategias que permitan alcanzar las soluciones El SPI action plan draft se completa de acuerdo a la vision de la organizacion, planes estratégicos del negocio, lecciones aprendidas en esfuerzos previos de mejora. claves organizacionales, y objetivos. Se desarrollan Ios objetivos medibles a partir de los objetivos generales que se definieron en la fase de inicio. éstos objetivos medibles son incluidos en la version final del SPI action plane. Se definen las métricas para monitorear el progreso. Se asignan recursos y entrenamiento al technical working group (TNG) El plan de accion desarrollado guiara las actividades de SPI, priorizando hallazgos y recomendaciones encontrados en el Diagnostico. Se crean Ios templates de Ios planes de accion tactico y se entregan al TWG para que sean completado y seguidos
  19. 19. 0 Las Soluciones que se aplican a la areas de mejora. determinadas en la fase de diagnostico. son creadas. piloteadas, y deployadas en la organizacion. 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 adopcion, deployment, e institucionalizacion; a partir de esto se desarrollan y ejecutan Ios planes de rollaup.
  20. 20. Learning Liberacion/ aprendizaje 0 El objetivo es que el siguiente ciclo de IDEAL se mas efectivo 0 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 informacion 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.
  21. 21. Fase de INICIO
  22. 22. Proposito Reconocer y entender el estimulo de mejora Establecer contexto y establecer sponsorship para el programa SPI Lanzar el programa SPI teniendo conocimiento sobre los costos y beneficios Comprometer Ia disponibilidad de recursos necesarios Establecer la infraestructura inicial necesaria para implementar y manejar el programa
  23. 23. Objetivos Desarrollar el conocimiento, habilidad e inteligencias iniciales para iniciar el SPI Determinar si se tiene un OK para proceder Crear el proposito del programa de SPI, establecer las necesidades del SPI, el ambito del programa, y Ios requerimientos de recursos Recomendar un plan e infraestructura para manejar el programa de SPI
  24. 24. Educacion/ habilidades Discovery Line Education/ Skills Team Managers Practitioners X X X 2-2 hange IX 2 Zj Zjjjj Z Zjj MSG: Master Steering Group SEPG: Software Engineering Process Group
  25. 25. .. L l! .ll-Flii. ’--I'l= _ii‘. j.~-" ‘TI<f—. i=. i'i'n‘l. iI 5i'«; ii"rir-. ll” ". -)3,-ll-9 ’r“-. l'r“ i-; ii~r2 1i; i:i; i:i'it«; i;‘: -; i;i| §iF’l éléiif’-J. ir"r’~: i.ll'g. l'r‘ ; il ? '_ll": '(. _lljl*.11K'El' -; i;il -TiF’l; ':3l'iY! i1.li"l; I?‘ iii: -: i"9l*:1!li"-ifie‘i»ll5lfllAl'lil5l! l9I: ;. CL iIlTli"'I'ir. Ii" all rIli"air-i~Ti. ~llitu i_l= Il ~'ii”l V'2'r'D]‘ a iviiginli’ i": l"1'. ll"'¢1>‘)~f} all uglr *; i'-—nii- ' : i.~l‘igniei° r'= i~‘. I.I"': i< xi pair‘: la Iiii; -': i=i: i:: ‘-'. _i~: r:. .i-'= :i= i 'i"l
  26. 26. Compromisos de la Iinea de Stakeholders gerente: Comprometer el tiempo y esfuerzo de su participacion en SPI Estructurar y comprometer el tiempo del MSG Estructurar y comprometer recursos para SEPG Software Engineering Process Group. - Planear la gestion 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).
  27. 27. Criterios de Entrada -vi Las organizaciones debe iniciar un programa de SPI para mantener y mejorar sus ventajas competitivas. it Criterios clave de entrada: -! Deben existir y ser cuidadosamente entendidos Ios procesos de desarrollo de software que mejoren las necesidades criticas del negocio is Deben estar identificados Ios Champions que impulsaran el SPI
  28. 28. Criterios de Salida '3 Se ha establecido la infraestructura inicial del SPI, establecido/ reforzado Ios sponsors y se promueven Ios conceptos y actividades del SPI 0 La organizacion ha enlazado la iniciativa de SPI con las estrategias organizacionales. '9 lnicial el organization communication plan para que la iniciativa de SPI
  29. 29. Actividades Fase de lnicio Estimulo para el cambio Establecer contexto Construir Sponsorship Diagramar infraestructura
  30. 30. ._A _, , 4%-- *. iiii'ii, -illr-. ii'ii; iii‘¢: -.r: F’: -as: -1-iiiéiii all ariami-: i;il-: :ii'-tiiiiisiitziiiicllw: ‘_'l”"; i?llIl him: i"§i~. 'i: |!| §I~_‘il_C? l g~i'r'-: n.ic: ifl'I: i ill '-, i~‘i'ZlnII. li= §". l=, l_. l‘v_ t: ;iii; i" 'lIiii. ‘_i‘-_lri*Tl= .i . ‘-in '-I I’-, IIIll[| '|f ll; ‘fl-, ‘l1:_'l‘"li/ I’-l_I . l§l ; I.‘ii, l;i"'_(~i. iiflllgfl. -,l flit ' : ii 1:: '. ‘-’. '-I = il 5-): -11:1:
  31. 31. Establecer contexto 45 Establecer claramente sobre lo que se va a cambiar dentro de la organizacion 1* Requiere estar alineado con: I La mision de la organizacion I Metas y objetivos organizacionales I La vision de futuro, ser coherente I La estrategia trazada para alcanzar la vision I Modelos referentes *9 El contexto e implicaciones seran mas claros.
  32. 32. Construir “Sponsorship” 0 Sponsorhip es obtener el soporte a nivel senior 0 Los sponsors son mas efectivos si ellos: 0 Dan personal atencion al esfuerzo 0 Brindan apoyo cuando el cambio atraviesa por tiempos dificiles Direccionan Ios recursos necesarios hacia el esfuerzo de mejora Cambian su propio comportamiento para ser consistentes con los cambios que estan siendo implementados 0 Modifican el sistema establecido 0 Es un elemento critico que contribuye hacia el éxito 0 Debe ser sostenido
  33. 33. Establecer infraestructu ra -1 implementar el cambio frecuentemente requiere de estructuras organizacionales. La infraestructura debe incluir: ii Un grupo de apoyo (senior level people) it Un grupo agente del cambio 4* Uno o mas grupos de trabajo técnicos (TWGs. Technica| 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 eITWGs durante la fase de inicio.
  34. 34. V 1 Br ii; hm! Ll Iemiw Inzr-euieeos Nllinxaii-rIPiI¢— ud ii-inn let horvm-vi I-own-H :3’! Mm-' I I Mimi: ml Iuin hum 1.5 Dimie App-mi Ii: sri rug-u Ind nrul Iueourue I I lsubmi IIIIYIII flux- huevuun hivwnrire bl Dd: GIQII SPI lid! 1 0 tie’ mm iiimng Pr-nmlle em-r Sn heyni Figure 1-1: Process Flow for initiating Phase
  35. 35. Fase de DIAGNOSTICO
  36. 36. Actividades Fase DIAGNOSTICO Estimulo para el cambio Establecer contexto Construir Sponsorship Diagramar infraestructura
  37. 37. 1 I luv-nc hm Inehdt) II held 1 1 Han I1 IM Xlhds) 2 J Cllfllci IIOII$l I 4 Prim! Fellip 2 5 hull Ii-i reebp he I-:1--elnem I-enn 1| cumin: hump eel Iguana-uni: Orprniihvi F lgure 2-1: Process Flow for Dlegnouing Phase
  38. 38. Errores clasicos en la Industria del Software
  39. 39. Sobre nuestros proyectos is Dos tercios de Ios 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 cancelacion I Si se hace un encuesta es altamente probable que el 40°/ o de las empresas encuestadas tuvieran un proyecto fuera de control en un afio
  40. 40. que explicaciones tenemos. .. —I Dificultad para planificar costes y plazos I Rota Ia planificacion no se recupera el tiempo perdido Calidad insuficiente de Ios productos - Prestacionesinadecuadas Grandes dificultades de mantenimiento I Se pierden concursos porno conocer el cliente y/ o Ia competencia
  41. 41. como evitar esto I Las dificultades técnicas pueden evitarse con buenas précticas de ingenieria. Pero. .. Muchos de estos problemas tienen el origen en la gestion Los problemas de gestion no pueden solucionarse técnicamente Sin embargo, tienen graves efectos en el piano técnico
  42. 42. Los 36 errores clasicos de la gestion de proyectos Mc Connell
  43. 43. Personas Producto Tecnologia Proceso Evitar Ios errores clasicos elimina muchos problemas Cometer un solo error clasico genera muchos problemas
  44. 44. I Personas 0 Motivacion débil 0 Motivacion: es el primer factor sobre la productividad y la Calidad 0 Personal mediocre 0 El Segundo factor mas importante 0 Contratar rapido para empezar rapido 0 Diferencias de productividad de 1 a 10 0 Empleados problematicos incontrolados 0 Hazafias 0 No se deben premiar actitudes de tipo “ser capaz de"Premiar progresos consistentes e informes realistas 0 Las actitudes “ser capaz de”convierten pequefios contratiempos en grandes desastres
  45. 45. 2 Personas 0 Afiadir personal a un proyecto retrasado 0 El error mas clasico 0 Oficinas repletas y ruidosas 0 Fricciones entre clientes y los desarrolladores del proyecto El desarrollador no acepta el plan de trabajo El cliente cambia Ios requisitos Conflicios de personalidad Todo ello lleva a la mala comunicacion internos (StandishGroup, 1994)
  46. 46. ?'l; i;l! I': I!I; i;lt= .li" risinipisillr . ‘ei. =.i; +;= Tiiis‘. iei, ~i: -i air ; i;lllIII§l! il! lII; i2“i ~: i=ilifai= ir= .io: i=. iuii= i.iii: .~ -i, -iliiiik-i‘t= .i: « Sill, -i= ioi”i= .iii~I= .i. w r= r.ili= i‘i= .i-i: Iiiiim «ii: lore: -‘L i= .ie“(-ir= i:r , IlilIl'il, 'P= .ll= i-‘« , -i= .il= .l = i| éziiiv-l -ii: _iIlI:1fl= lI'llIi. “. r"= .llt= . -‘la '. 'Il gil9liIl! Y(! Ir f-iialrliiilql -‘. ir. iI gIl9lYl? I!il9' ~51’ III. ‘ .71: i: ii':4'-. li! =‘. Ini @ll’= .[-(tic giiiitldi r= r-. lll-»‘1‘i= .is‘- i, :r kiln cl: girciiiiaiirir Iiavr; :11 ir: rm, i:i»: ~ mull €R1=U_| l|l: i:~‘lo ~'II= i : :ir ii, r:icii"
  47. 47. 4 Persmas is Falta de participacion de Ios implicados (stakeholders) e Deben implicarse promotores, comerciales, usuarios, clientes, etc * Falta de participacion del usuario ii Mal entendimiento de los requisitos El Tiempo empleado en requisiios innecesarios - Politica antes que desarrollo (sustancia) 1 Equipos: politicos, investigadores, aislacionistas, generalistas *5 Primar politica sobre resultados: malo para desarrollo rapido * llusiones it Cerrar Ios ojos y esperar que todo funcione, sin razon para ello it Problema fundamental y extremadamenie frecuente
  48. 48. I Proceso - Planificacion insuficiente It insuficiente esfuerzo de estimacion ii insuficiente esfuerzo al determinar tareas - Abandono de la planificacion bajo presion 1* El problema no es abandonar un plan fir . ..e| problema es no adoptar otro -3 Pérdida de tiempo en el inicio difuso -3 Escatimar en las actividades iniciales it “No hemos tenido tiempo para hacer un buen disefio” ii Coste: de 10 a 100 veces superior
  49. 49. 2 Proceso Planificacién excesivamente optimista 1 El proyecto fracasaré ° Hay que estropear Ia planificacién - Ahorrar en anélisis / disefio / calidad - Presién sobre Ios desarrolladores (moral, productividad) Gestién de riesgos insuficiente ¢ Muchas veces no se realiza Fallos del contratista - Requisitos cambiantes Disefio Inadecuado Controles de gestién insuficiente
  50. 50. 3 Proceso 4» Escatimar en aseguramiento de calidad * Eliminando revisiones, pruebas, # 1 dia menos de QC (Control de calidad) al principio Ileva de 3 a 10 dias 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% (segfm Van Genuchten, 1991) - Planificar ponerse al dia mas adelante - Nunca se llega a dar * La respuesta adecuada es replanificar
  51. 51. Producto - Exceso de requisitos - Con frecuencia se pide mas de lo que se necesita - Cambio de requisitos * Un proyecto sufre una media de 25% de cambios durante el desarrollo (CapersJones, 1994) '1 Desarrolladores meticulosos ~ Desarrollo/ tecnologiainnecesaria *1 Tiras y aflojas en la negociacién «Ii Te permito que acabes mas tarde de los previsto 4* . ..pero a cambio quiero que me afiadas estas prestaciones * Desarrollo orientado a la investigacién
  52. 52. Tecnologfa Sindrome de la panacea (de la bala de plata) * Esta tecnologia es buenisima . ..y vale para todo Sobreestimacion de las ventajas de las herramientas o métodos it Con esta herramienta podemos hacer Cambiar de herramientas a mitad del proyecto it Vamos a cambiar a . ..que es mucho mejor Falta de manejo automatizado de cédigo fuente
  53. 53. Universidad Técnica Particular de Loja Escuela de Ciencias de la Computacién Nelson Picdra t‘ttp: i'r'nopIedram/ ordpress com nopledra@utp| .edu. ec 3;‘; .4’ UNIVEIISIDAD TECNICA PARTICULAR DE LOJA L. u. ... ... .A. A l'4h~l. r4 44 L174 www. utgl. edu. ec www. esgoI. edu. ec 4 y 5 de octubre del 2007

×