Juan Palacio Rev. 1.0Mayo 2014 Compendio de Ingeniera del Software Tabla de contenido Prlogo Introduccin a la ingeniera del software Gestin de proyectos predictiva Produccin basada en procesos Ingeniera de procesos de software Modelo de procesos CMMI Modelo de procesos ISO IEC 15504 Ciclo de vida del software Ciclos de desarrollo y patrones de gestin de proyectos Los requisitos del software Diseo del software Documentacin de usuario Verificacin y validacin Mantenimiento Gestin de la configuracin Agilidad Conocimiento Sntesis entre procesos y agilidad Scrum: el marco Scrum: Mtricas Scrum: prcticas Kanban Gestin en organizaciones giles Este Compendio de Ingeniera del Software recopila apuntes preparados por el autor para formacin, que resumen aspectos pragmticos de Ingeniera del Software. Se comparten con una licencia abierta1 para su uso en autoformacin, o en foros que requieran la exposicin de alguna de las reas de la Ingeniera del Software que cubren, con un enfoqueejecutivo o general, sin la densidad propia del texto acadmico: Formacin de Ingeniera del Software como asignatura complementaria en programas de estudio tcnicos. Formacin continua de gestores intermedios o directivos de empresas de software. Presentaciones de asesora y formacin profesional durante la implantacin de procesos de mejora. Etc. Este no es un trabajo completo, y por su carcter general no pretende cubrir todos los modelos, tcnicas o lneas de trabajo de la Ingeniera del Software, sino las ms pragmticas para la industria del software. Si resulta posible, en futuras versiones, adems de la revisin de este contenido, se incluirn temas que por razones de tiempo y prioridad se quedan fuera. Prlogo 3 Juan Palacio (1) Para consultar los usos autorizados de este trabajo o contactar con el autor: http://www.safecreative.org/work/1401289956290 Introduccin a la Ingeniera del Software 1.0 4 1952 Introduccin Ingeniera del Software 5 1965 Introduccin Ingeniera del Software 6 1950196019701980199019902000 Crisis del Software ? Introduccin Ingeniera del Software 7 Crisis del software Este problema se identific por primera vez en 1968, ao en el que la organizacin NATO desarroll la primera conferencia sobre desarrollo de software, y en la que se acuaron los trminos crisis del software para definir a los problemas que surgan en el desarrollo de sistemas de software, e ingeniera del software para describir el conjunto de conocimientos que existan en aquel estado inicial. Algunas referencias tiles para comprender cules eran los conocimientos estables para el desarrollo de software en 1968 son: En 1962 se public el primer algoritmo para bsquedas binarias. C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la eliminacin de GoTo y la creacin de la programacin estructurada. En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi su famosa carta GoTo Statement Considered Harmful en 1968. La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb. El primero sobre anlisis de requisitos apareci en 1979 Introduccin Ingeniera del Software Crisis del software 8 9 LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE INGENIERA DEL SOFTWARE INGENIERA DE PROCESOS GESTIN DE PROYECTOS Aplicacin de un enfoque sistemtico, disciplinado y cuantificable en el desarrollo, operacin y mantenimiento de software. (Produccin basada en procesos / mejora continua del proceso) Aplicacin del principio de calidad de Jurn empleado en la produccin industrial a la produccin de sotware: La calidad del resultado depende de la calidad del proceso-> modelos de procesos: CMMI, ISO 15504Aplicacin de procesos de planificacin, ejecucin y control para alcanzar un objetivo final en un plazo de tiempo determinado con el coste y nivel de calidad previstos (Aplicacin del modelo de gestin de proyectos predictivoen los proyectos de software) Introduccin Ingeniera del Software 1980 Introduccin Ingeniera del Software 10 1986 Introduccin Ingeniera del Software 11 1990 Introduccin Ingeniera del Software 12 2000 Introduccin Ingeniera del Software 13 2005 Introduccin Ingeniera del Software 14 2010 Introduccin Ingeniera del Software 15 2000 1998 1995 1994 28%23%49% 26%28%46% 27%40%33% 16%31%53% xitoProblemticoFracaso Proyectos para desarrollo de sistemas de software 2004 29%19%53% Fuente: Standish Group Survey, 2009 32%24%44% Crisis del software Introduccin Ingeniera del Software 16 2000 1998 1995 1994 28%23%49% 26%28%46% 27%40%33% 16%31%53% xitoProblemticoFracaso Proyectos para desarrollo de sistemas de software 2004 29%19%53% Fuente: Standish Group Survey, 2009 32%24%44% Crisis del software Introduccin Ingeniera del Software 17 Definicin original: Establecimiento y uso de principios de ingeniera para obtener software econmico que trabaje de forma eficiente en mquinas reales. Fritz Baver, 1968 (conferencia NATO) Otras definiciones Disciplina para producir software de calidad desarrollado sobre las agendas y costes previstos y satisfaciendo los requisitos. S. Schach 1990, Software Engineering (1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el desarrollo, operacin y mantenimiento de software; esto es, la aplicacin de la ingeniera al software. (2) El estudio de (1). IEEE 1993 Introduccin Ingeniera del Software Ingeniera del software 18 Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informtica de las universidades, y por organismos de estandarizacin (SEI, IEEE, ISO) para identificar las causas del problema y definir pautas estndar para la produccin y mantenimiento del software. Los esfuerzos se han encaminado en tres direcciones principales. Identificacin de los factores clave que determinan la calidad del software. Identificacin de los procesos necesarios para producir y mantener software. Acotacin, estructuracin y desarrollo de la base de conocimiento necesaria para la produccin y mantenimiento de software. El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y operacin de los sistemas de software, introduciendo mtodos y formas de trabajo sistemticos, disciplinados y cuantificables. La forma de trabajo de programadores individuales surgida por la necesidad de los primeros programas, ha creado una cultura de la programacin heroica, para el desarrollo de software que es la principal causa de los problemas apuntados, y en la actualidad una de las principales resistencias a la implantacin de tcnicas de ingeniera para el desarrollo de sistemas Introduccin Ingeniera del Software Ingeniera del software 19 La Ingeniera del Software es una ingeniera muy joven que necesitaba: Definirse a s misma: Cules son las reas de conocimiento que la comprenden? Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del software De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para evitar los problemas de la crisis del software Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la configuracin, etc. Introduccin Ingeniera del Software Ingeniera del software 20 Los estndares son tiles porque: Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de software. Engloban los conocimientos. Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas. Desde la identificacin del fenmeno crisis del software, han sido muchas las organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores garantas de xito. Han sido muchos los departamentos de universidades, organismos de normalizacin o investigacin nacionales o internacionales, sociedades de profesionales, departamentos de defensa, departamentos de calidad y procesos de empresas los que han ido generando normas y estndares. Este compendio considera como entidades de mayor reconocimiento internacional, por sus trabajos y esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a: ISO, IEEE- Computer Society y SEI. Introduccin Ingeniera del Software Ingeniera del software 21 ISO Organizacin Internacional para la Estandarizacin. Fundada en 1947 Son miembros 87 pases. En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y equipos. Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software: ISO/IEC 12207 ISO/IEC TR 15504 SEI Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la Universidad Carnegie Mellon. Los trabajos y aportaciones realizadas por el Instituto de Ingeniera del Software a la Ingeniera del software son tambin referente mundial de primer orden, siendo la aportacin ms significativa los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi 15 aos de implantacin efectiva en entornos de produccin de software han demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de resultados previsibles de una organizacin de software. Introduccin Ingeniera del Software Ingeniera del software 22 IEEE Computer Society IEEE Es el Instituto de Ingenieros en electricidad y electrnica (Institute of Electrical and Electronics Engineers). Su misin es preservar, investigar y promover la informacin de las tecnologas elctricas y electrnicas. Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) y el Instituto de Ingenieros de Radio (IRE). La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en la actualidad por ms de 100.000 miembros en todo el mundo. Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares. Estndares para la Ingeniera del Software IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software son: IEEE Std. 830 Prcticas recomendadas para las especificaciones de software. IEEE Std. 1362 Gua para la especificacin del documento de requisitos ConOps IEEE Std. 1063 Estndar para la documentacin de usuario de software. IEEE Std. 1012 Estndar para la verificacin y validacin de software. IEEE Std. 1219 Estndar para el mantenimiento del software Introduccin Ingeniera del Software Ingeniera del software 23 La Ingeniera del Software es una ingeniera muy joven que necesitaba: Definirse a s misma: Cules son las reas de conocimiento que la comprenden? Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del software De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para evitar los problemas de la crisis del software Definir estndares menores para dibujar criterios unificadores en requisitos, pruebas, gestin de la configuracin, etc. SWEBOK: Software Engineering Body of knowledge ISO/IEC 12207: Procesos del ciclo de vida del software CMM / CMMI ISO/IEC TR 15504 IEEE 830- IEEE 1362-ISO/IEC 14764 Introduccin Ingeniera del Software Ingeniera del software 24 El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de manera efectiva dentro del SWECC1 en 1997 (aunque el comit SWECC se cre en 1993). En el proyecto tambin estn representados: los dos principales organizaciones de estandarizacin en Ingeniera del Software: IEEE e ISO/IEC JTC1/SC/. Los autores de las tres principales obras de Ingeniera del Software: Steve Mc Connell, Roger Pressman e Ian Sommerville. Universidad de Qubec (Montreal) Empresas y organizaciones como: Rational, SAP, Boeing, Construx, MITRE, Raytheon,En 2001 el proyecto public ya una definicin consensuada del cuerpo de conocimiento aceptado en la ingeniera del software (http://www.swebok.org). Las fuentes de informacin para la identificacin de las reas de conocimiento han sido los ndices de textos genricos sobre la Ingeniera del Software, los curricula para licenciatura y postgrado en Ingeniera de Software, y los criterios de admisin que se utilizan en el postgrado. Todos estos datos se han organizado siguiendo el estndar ISO/IEC 12207. 1 Software, Engineering Coordinating Comitee, Comisin creada por IEEE Computer Society y ACM (Association for Computer Machinery) para definir el cuerpo de la Ingeniera del SoftwareEl cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio ms relevante y como la referencia de ms autoridad en toda la comunidad informtica para la acotacin y descripcin de los conocimientos que configuran la Ingeniera del software. Introduccin Ingeniera del Software SWEBOK 25 SWEBOK da el primer paso necesario para constituir a la Ingeniera del Software como profesin: la delimitacin del cuerpo de conocimiento que comprende la profesin. Sin esta delimitacin no es posible validar de forma universal exmenes de licenciatura, no es posible la preparacin para acceder a la profesin, y no hay un consenso sobre el contenido de su currculo.El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento que deben conocer los ingenieros del software, y en su desarrollo ha agrupado este conocimiento en 10 reas Es importante resaltar que estas reas no incluyen aspectos importantes de las tecnologas de la informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes o tecnologa de redes y comunicaciones. Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un enfoque de ingeniera. Por supuesto que un Ingeniero de Software debe conocer las tcnicas de cada momento, pero la definicin de procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el rea de conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos son indistintos del hardware o lenguaje de programacin empleado. Eran los mismos hace dos dcadas que ahora, y todo nos hace suponer que seguirn siendo idnticos dentro de otros cuatro lustros. Requisitos Diseo Construccin Pruebas Mantenimiento Gestin de la configuracin Gestin Procesos Herramientas y mtodos Calidad Introduccin Ingeniera del Software Ingeniera del software 26 Establecer un estndar para evitar una situacin de Torre de Babel en la gestin e ingeniera del software, proporcionando un marco y un lenguaje comn en la disciplina del software Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software, y termina cuando este se retira y deja de funcionar. Ciclo de vida del software Introduccin Ingeniera del Software ISO 12207: PROPSITO 27 Establece un marco comn para el ciclo de vida del software para Adquisicin, suministro, desarrollo, operacin y mantenimiento del software Gestionar, controlar y mejorar el marco Como base de referencia para el trabajo e intercambio entre organizaciones de software Define el QU, no el CMO. Dice cules son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y operacin de los sistemas de software, asentando un marco estndar de referencia internacional, pero no se ocupa ni prescribe tcnicas especficas. El estndar sirve de referencia desde dos perspectivas diferentes: Para la adquisicin de sistemas y servicios de software. Para el suministro, desarrollo, mantenimiento y operacin de productos de software. El estndar no cubre el desarrollo de productos de software para distribucin comercial masiva (productos en caja). No se trata de un estndar de certificacin, tipo ISO 9000, sino de un estndar para la normalizacin. Introduccin Ingeniera del Software ISO 12207: PROPSITO 28 El estndar no prescribe: Que deba emplearse ningn tipo de documentacin especfica. Que deba emplearse un tipo especfico de ciclo de desarrollo. Mtodos concretos para el desarrollo, mantenimiento u operacin del software. 5. Procesos primarios6.- Procesos de soporte 7. Procesos organizacionales 5.1 Adquisicin 5.2 Suministro 5.3Desarrollo 5.3Operacin 5.3Mantenimiento 6.1 Documentacin 6.2 Gestin de la configuracin 6.3 Control de calidad 6.4 Verificacin 6.5 Validacin 6.6 Reuniones 6.7 Auditora 6.8 Resolucin de problemas 7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin Introduccin Ingeniera del Software ISO 12207 (20051): PROCESOS 29 (1) La versin actual de este estndar ha modificado el esquema de procesos. Para el mbito de estos apuntes se mantiene esta versin de 2005 por ofrecer una estructura ms comprensible. Introduccin Ingeniera del Software ISO 12207 (20081): PROCESOS 30 (1)Para el mbito y finalidad de estos apuntes, manejamos mejor la versin previa de 2005 por ofrecer una estructura ms comprensible Ciclo de vida Concepto Retirada Proceso 1 Proceso N Actividad 1 Tarea 1 Tarea 2 Tarea n Actividad n Tarea 1 Tarea 2 Tarea n Introduccin Ingeniera del Software ISO 12207 ISO 1227 define los procesos que componen el ciclo de vida del software 31 ACTIVIDAD 1 TAREA 1TAREA 1TAREA X PROCESO ACTIVIDAD n Un proceso est compuesto por actividades. Una actividad est compuesta de tareas. La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora) PLAN Tareas,agenda, asignaciones CHECK Evaluacin y medicin DO Ejecicin de planes y tareas ACT Problemas y acciones correctivas PROCESO INICIO FIN Introduccin Ingeniera del Software ISO 12207 32 ISO 12207 establece un nexo con la Ingeniera de sistemas al considerar al software como parte de un sistema. Desde esta perspectiva se establece a la Ingeniera de sistemas como fundamento de la Ingeniera del Software. Qu es un sistema? Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones especficas. IEEE Standard 610.12-1990 Elemento del sistema Elemento del sistema Elemento del sistema Elemento del sistema Sistema de Entrada Sistema de Salida Sistema Coleccin de elementos relacionados de forma que puedan realizar un objetivo tangible. Pressman 1982 Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 33 conjunto de elementos de hardware, software, personas, procedimientos, herramientas y otros factores organizativos, organizados para llevar a cabo un objetivo comn. Sistema Sistema de software Sistema o sub-sistema formado por una coleccin de programas y documentacin que de forma conjunta satisfacen unos determinados requisitos. Un sistema de software puede ser en s mismo un sistema independiente que, por ejemplo, realiza su objetivo en un ordenador independiente. A este tipo de sistemas se les denomina tambin sistema intensivo de software, porque el sistema es prcticamente software. Un sistema de software puede ser tambin una parte de un sistema mayor. En cuyo caso se trata en realidad de un sub-sistema de software. Por ejemplo, el sistema de software de un avin de combate es en realidad el sub-sistema de software del avin. Ingeniera de sistemas El trmino Ingeniera de sistemas surgi por primera vez en 1956, y fue propuesto por H. Hitch, presidente del departamento de Ingeniera Aeronatica de la Universidad de Pensilvania, para intentar desarrollar una disciplina de ingeniera que pudiera abarcar el desarrollo de grandes sistemas que empleaban diversas disciplinas de ingenieras especficas: construccin de bombarderos, submarinos, etc. Los principios de Ingeniera de sistemas desarrollados en los 60 y 70 se aplicaron en programas como el Apolo, o el programa de misiles balsticos USAF/USN. Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 34 Algunas definiciones Ingeniera de sistemas comprende la funcin de gestionar todo el esfuerzo de desarrollo para conseguir un balance ptimo entre todos los elementos del sistema. Es el proceso que transforma la necesidad operacional en la descripcin de los parmetros del sistema, e integra esos parmetros para mejorar la eficiencia general del sistema. Defense Systems Management College, 1989 Los procesos de ingeniera de sistemas integran las secuencias de actividades y decisiones que transforman la definicin de una necesidad en un sistema, que con un ciclo de vida optimizado, consigue un balance ptimo de todos sus componentes. USAF, 1985 La principal funcin de la ingeniera de sistemas es garantizar que el sistema satisface los requisitos durante todo el ciclo de vida. Todas las dems consideraciones se alinean sobre esta funcin. Wymore 1993 La ingeniera de sistemas define el plan para gestionar las actividades tcnicas del proyecto. Identifica el ciclo de desarrollo y los procesos que ser necesario aplicar. Desde la Ingeniera de sistemas se desarrolla la lnea base tcnica para todo el desarrollo, tanto de hardware como de software. Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 35 Funciones de la Ingeniera de sistemas Definicin del problema: Determinacin de las expectativas hacia el producto, necesidades y restricciones obtenidas y analizadas en los requisitos del sistema. Trabaja cerca del cliente para establecer las necesidades operacionales. Anlisis de la solucin: Determinar las opciones posibles para satisfacer los requisitos y las restricciones. Estudiar y analizar las posibles soluciones. Seleccionar la mejor, sopesando las necesidades inmediatas, opciones de implementacin, utilidad, evolucin del sistema Planificacin de los procesos: Determinar los grupos de tareas tcnicas que se deben realizar, el esfuerzo requerido para cada una, su prioridad y los riesgos que implican para el proyecto. Control de los procesos: Determinar los mtodos para controlar las actividades tcnicas del proyecto y los procesos; la medicin del progreso, revisin de los productos intermedios y ejecucin de las acciones correctivas, cuando corresponda. Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a travs de evaluaciones, pruebas, anlisis, inspecciones Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 36 Ingeniera de sistemas Ingeniera de sistemas de software Ingeniera del softwareCodificacin Pruebas unitarias Diseo detallado del software Pruebas del sub-sistema de softw. Diseo de la ar-quitectura del sw Pruebas del sistema de sw Anlisis de requisitos del sw Pruebas de integracin del sw Diseo del sistema Anlisis del sistema Pruebas de integracin del sis Pruebas del sistema Ingeniera de sistemas Ingeniera de sistemas de software Ingeniera del softwareIngeniera del software Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 37 Ing. de sistemas Gestin de proyectos predictiva Ing. del SoftwareGestin de proyectos predictiva Planificacin Organizacin Personal Direccin Control Ingeniera del software Diseo del software Codificacin Pruebas unitarias Integracin del subsistema de software Ingeniera de sistemas Definicin del problema Anlisis de la solucin Planificacin de procesos Control de procesos Evaluacin del producto Introduccin Ingeniera del Software INGENIERA DE SISTEMAS 38 1950196019701980199019902000 Crisis del Software Introduccin Ingeniera del Software 39 Ingeniera de sistemas Gestin de proyectos Ingeniera del software Desarrollo basado en procesos LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE 40 LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE INGENIERA DEL SOFTWARE INGENIERA DE PROCESOS GESTIN DE PROYECTOS Aplicacin de un enfoque sistemtico, disciplinado y cuantificable en el desarrollo, operacin y mantenimiento de software. (Produccin basada en procesos / mejora continua del proceso) Aplicacin del principio de calidad de Jurn empleado en la produccin industrial a la produccin de sotware: La calidad del resultado depende de la calidad del proceso-> modelos de procesos: CMMI, ISO 15504Aplicacin de procesos de planificacin, ejecucin y control para alcanzar un objetivo final en un plazo de tiempo determinado con el coste y nivel de calidad previstos. (Aplicacin del modelo de gestin de proyectos predictivoen los proyectos de software) Introduccin Ingeniera del Software Gestin de proyectos predictiva 1.0 41 Conjunto nico de actividades necesarias para producir un resultado definido, en un rango de fechas determinado y con una asignacin especfica de recursos PROYECTOS Gestin de proyectos predictiva 42 Gestin basada en PLANIFICACIN 1 Qu hacer? 2 Planificacin del trabajo 3 Ejecucin y control SEGUIMIENTO GESTIN DE PROYECTOS (predictiva) Gestin de proyectos predictiva 43 1965.- IPMA 1969.- PMI 1989.- PRINCE 2 PROYECTOS Gestin de proyectos predictiva 44 A tiempo En costes Calidad XITO PROYECTOS Gestin de proyectos predictiva 45 Profesionalizacin del cuerpo de conocimiento para desarrollo de proyectos NUEVA PROFESIN Gestin de proyectos predictiva 46 cc-by: LizMarie PRCTICA: GESTIN PREDICTIVA Gestin de proyectos predictiva 47 A tiempo En costes Lo previsto 15 Turnos PRCTICA: GESTIN PREDICTIVA Gestin de proyectos predictiva 48 A tiempo En costes XITO Lo previsto PRCTICA: GESTIN PREDICTIVA Gestin de proyectos predictiva 49 Gestin basada en PLANIFICACIN 1 Qu hacer? 2 Planificacin del trabajo 3 Ejecucin y control La forma ms eficiente de hacer un trabajo es hacerlo bien a la primera Watts S. Humphrey SEGUIMIENTO PRCTICA: GESTIN PREDICTIVA Gestin de proyectos predictiva 50 LA FORMA MS EFICIENTE DE HACER UN TRABAJO, ES HACERLO BIEN A LA PRIMERA WattsS. Humphrey Creador de los modelos CMM - CMMI GESTIN PREDICTIVAPRODUCCIN BASADA EN PROCESOS Gestin de proyectos predictiva 51 Requisitos Diseo Codificacin Pruebas Integracin Mantenim. WattsS. Humphrey Creador de los modelos CMM - CMMI LA FORMA MS EFICIENTE DE HACER UN TRABAJO, ES HACERLO BIEN A LA PRIMERA GESTIN PREDICTIVAPRODUCCIN BASADA EN PROCESOS Gestin de proyectos predictiva 52 53 Las empresas y las organizaciones en general llevan a cabo su trabajo bajo la forma de proyectos o de operaciones. Son realizados por personas Disponen de recursos limitados Su ejecucin se controla y responde a una planificacin. Caractersticas comunes a las operaciones y los proyectos Los proyectos son temporales y nicos, mientras que las operaciones realizan siempre los mismos procesos de forma continua. Diferencias entre operaciones y proyectos Gestin de proyectos predictiva OPERACIONES Y PROYECTOS 54 Son realizados por personas Disponen de recursos limitados Su ejecucin se controla y responde a una planificacin. Tienen un inicio y fin definidos Tienen como finalidad producir un producto o servicio nico Ciclo de vida planificado Caractersticas de los proyectos Temporalidad Cada proyecto tiene un inicio y fin definidos. El fin se alcanza cuando se consiguen los objetivos del proyecto por razones objetivas se decide abortar su ejecucin. Producto nico La finalidad del proyecto es realizar algo que no se piensa repetir de forma sistemtica. Ciclo de vida planificado Caracterstica derivada de la temporalidad y el objetivo nico. El producto o servicio se lleva a cabo de forma incremental siguiendo unos pasos planificados que constituyen el ciclo de vida del desarrollo.Gestin de proyectos predictiva PROYECTOS 55 Gestin de la integracin del proyecto Desarrollo del plan de proyecto Ejecucin del plan de proyecto Control integrado del cambio Gestin del mbito del proyecto Inicio Planificacin del mbito Definicin del mbito Verificacin del mbito Control de cambio del mbito Gestin de agenda Definicin de la actividad Secuencia de la actividad Estimacin de tiempos Desarrollo de la agenda Control de la agenda Gestin de costes Plan de recursos Estimacin de costes Presupuesto Control de costes Gestin de la calidad del proyecto Plan de calidad Aseguramiento de la calidad Control de calidad Gestin de los recursos humanos del proyecto Plan de organizacin Incorporacin de personas Desarrollo del equipo Gestin de las comunicaciones del proyecto Plan de comunicaciones Distribucin de la informacin Informes de eficiencia Cierre administrativo Gestin de riesgos delproyecto Plan de riesgos Identificacin de riesgos Anlisis cuantitativo de riesgos Anlisis cualitativo de riesgos Plan de exposicin de riesgos Monitorizacin y control de ries. Gestin de compras Plan de necesidades Plan de compras Compras Seleccin de proveedores Contratacin administrativa Cierre de contrato Fuente: PMBOK Gestin de proyectos predictiva reas de conocimiento de la gesdtin de proyectos 56 Gestin de proyectos Gestin y administracin Negocio del proyecto El principal conocimiento que se necesita para gestionar proyectos es exclusivo de la gestin de proyectos, pero para llevar a cabo la gestin debe complementarse con conocimientos que pertenecen al rea de management en general y con conocimientos especficos del negocio al que va a servir el proyecto. Gestin de proyectos predictiva Relacin de la G. de proyectos con otras reas de gestin 57 WBS Work Breakdown Structure: Estructura de las tareas en las que se descompone el proyecto. Planificando el proyecto: Tipos de dependencias entre tareas FC (de Fin a Comienzo) la ms habitual CC (de Comienzo a Comienzo) FF (de Fin a Fin) CF (de Comienzo a Fin) suele ser problemtica Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 58 Tipos de dependencias entre tareas Anlisis Diseo Web Diseo Admin Desarrollo Web Desarrollo Admin IntegracinImplantacin Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 59 Asignacin de recursos y personas a las tareas Optimizacin Conceptos clave para la optimizacin del proyecto Paso adelante Paso atrs Ruta crtica Reasignacin de recursos Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 60 Paso adelante Estimar la fecha ms temprana para comenzar y terminar cada tarea Comenzando por la fecha de inicio del proyecto Estima la fecha de fin ms optimista Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 61 Paso atrs Estimar cuales pueden ser las fechas mas retrasadas para el inicio y fin de cada tarea sin causar retrasos en el proyecto. Se puede estimar con la fecha de entrega calculada por paso adelante, o con la fecha de entrega deseada Al calcular con la fecha de entrega por paso adelante se debe obtener a la misma fecha de inicio. Al calcular con la fecha de entrega esperada se obtiene la fecha lmite para comenzar el proyecto Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 62 Demora total Diferencia entre las fechas calculadas con paso adelante y paso atrs para cada tarea Retraso mximo para una tarea sin retrasar sin afectar a la fecha de entrega del proyecto La demora total se comparte entre las tareas en una cadena. Si se emplea en una tarea ya no queda disponible para otras. Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 63 Demora permisible Tiempo que puede retrasarse una tarea sin afectar a la agenda del proyecto Algunos programas como MS Project pueden hacer los clculos de forma automtica Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 64 Ruta crtica Es la ruta ms larga en el plan del proyecto, y delimita la fecha de entrega ms temprana posible Actividades crticas Actividades que estn en la ruta crtica y que no tienen demora permisible. Sus retrasos afectan al proyecto Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 65 Optimizacin de agenda 1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crtica 2.- Revisar la asignacin de personas Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 66 Optimizacin de agenda 3.- Modificar la asignacin 4.- Redistribuir a las personas Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 67 Optimizacin de agenda Nueva ruta crtica Asignacin mas eficiente Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas 68 Optimizacin de agenda Reduccin de la demora total Recomendaciones Duplicar la asignacin de personas no significa la mitad de tiempo Menos tiempo de entrega no significa menor presupuesto Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado Usar el sentido comn Gestin de proyectos predictiva Gestin de proyectos: principales conceptos y prcticas cc-by: Betsy Fletcher Vdeo:Construccin Plaza Carso y Museo Soumaya (Mexico) GESTIN DE PROYECTOS PREDICTIVA Gestin de proyectos predictiva 69 Gestin de la integracin del proyecto Desarrollo del plan de proyecto Ejecucin del plan de proyecto Control integrado del cambio Gestin del mbito del proyecto Inicio Planificacin del mbito Definicin del mbito Verificacin del mbito Control de cambio del mbito Gestin de agenda Definicin de la actividad Secuencia de la actividad Estimacin de tiempos Desarrollo de la agenda Control de la agenda Gestin de costes Plan de recursos Estimacin de costes Presupuesto Control de costes Gestin de la calidad del proyecto Plan de calidad Aseguramiento de la calidad Control de calidad Gestin de los recursos humanos del proyecto Plan de organizacin Incorporacin de personas Desarrollo del equipo Gestin de las comunicaciones del proyecto Plan de comunicaciones Distribucin de la informacin Informes de eficiencia Cierre administrativo Gestin de riesgos delproyecto Plan de riesgos Identificacin de riesgos Anlisis cuantitativo de riesgos Anlisis cualitativo de riesgos Plan de exposicin de riesgos Monitorizacin y control de ries. Gestin de compras Plan de necesidades Plan de compras Compras Seleccin de proveedores Contratacin administrativa Cierre de contrato GESTIN DE PROYECTOS PREDICTIVA Gestin de proyectos predictiva 70 GESTIN DE PROYECTOS PREDICTIVA Gestin de proyectos predictiva 71 GESTIN DE PROYECTOS PREDICTIVA Gestin de proyectos predictiva 72 A tiempoEn costesCalidad OBJETIVO GESTIN DE PROYECTOS PREDICTIVA Gestin de proyectos predictiva 73 GESTIN DE PROYECTOS CARACTERSTICAS Gestin de proyectos predictiva 74 AGENDA YCOSTESONRESULTADO DE LA PLANIFICACIN GESTIN DE PROYECTOS CARACTERSTICAS Gestin de proyectos predictiva 75 Obra nica Inicio y fin definidos Caractersticas de los proyectos Objetivo de la gestin de proyectos Realizar la obra definida, en la fecha prevista y por el coste estimado Puntos de apoyo de la gestin de proyectos Definir qu hacer Planificar el trabajo Gestionar el cumplimiento Necesita requisitos estables La agenda y los costes son clculos realizados sobre el plan del proyecto CONCLUSIONES Gestin de proyectos predictiva 76 77 IDENTIFICACIN ANLISIS TRATAMIENTO GESTIN DE RIESGOS Plan de gestin de riesgos Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas 78 Principales estndares para gestin de riesgos Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas EstndarDescripcin ISO 31000Estndar publicado por ISOBritish Standard BS 31100 Estndar publicado por el instituto britnico de estandarizacin COSO ERM Marcopara riesgos corporativos desarrollado por el Comitee ofSponsoring Organizations of the Treadway Commission (coso.org) ISO IEC 73Glosario estndar para la gestin de riesgos. 79 Principios de la gestin de riesgos Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas PrincipioDescripcin Proporcional La gestin de riesgos debe ser proporcional al nivel de criticidad del proyecto. Exhaustiva Para que resulte no debe dejar reas generadoras de riesgos sin cubrir. Institucionalizada Las actividades de gestin de riesgos deben formar parte de las prcticas propias de la organizacin. Dinmica Las actividades de gestin de riesgos deben estar incluidas en ciclos institucionalizados de actualizacin y mejora continua. Alineada Las actividades de gestin de riesgos en los proyectos deben estar alineadas con la cultura y madurez de la organizacin. 80 Trminos incluidos en ISO IEC 73 Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas COMMUNICATION & CONSULTATION CONSEQUENCE CONTROL ESTABLISHING THE CONTEXT EVENT EXPOSURE EXTERNAL CONTEXT FREQUENCY HAZARD INTERNAL CONTEXT LEVEL OF RISK LIKELIHOOD MONITORING PROBABILITY RESIDUAL RISK RESILIENCE REVIEW RISK RISK ACCEPTANCE RISK AGGREGATION RISK ANALYSIS RISK APPETITE RISK ASSESSMENT RISK ATTITUDE RISK AVERSION RISK AVOIDANCE RISK CRITERIA RISK DESCRIPTION RISK EVALUATION RISK FINANCING RISK IDENTIFICATION RISK MANAGEMENT RISK MANAGEMENT AUDIT RISK MANAGEMENT FRAMEWORK RISK MANAGEMENT PLAN RISK MANAGEMENT POLICY RISK MANAGEMENT PROCESS RISK MATRIX RISK OWNER RISK PERCEPTION RISK PROFILE RISK REGISTER RISK REPORTING RISK RETENTION RISK SHARING RISK SOURCE RISK TOLERANCE RISK TREATMENT STAKEHOLDER VULNERABILITY 81 Identificacin de los riesgos Anlisis y clasificacin Tratamiento (evitar, prevenir, aceptar, proteger) Plan de riesgos y recursos Operacin Y registro de informacin Experiencia Informacin Gestin de riesgos: principales conceptos y prcticas Gestin de proyectos predictiva Gestin de riesgos 82 Anlisisclasificacin MTODOS CUALITATIVOS MTODOS CUANTITATIVOS MTODOS SEMICUANTITATIVOS Gestin de proyectos predictiva Los ms utilizados cuando: El nivel de riesgo es bajo y no justifica el esfuerzo de realizar anlisis completos. Los datos numricos (anlisis cuantitativos) resultan inapropiados. Alguinos mtodos cualitativos: Tormenta de ideas, what if, cuestionarios y entrevistas estructuradas, juicio de expertos (Tcnica Delphi), checklists Permiten asignar valores objetivos de probabilidad y ocurrencia para realizar anlisis de probabilidades, consecuencias o simulaciones computacionales. Utilizan rangos de estimacin como alto medio bajo en una escala apropiada para estimar el nivel de riesgo o sus consecuencias. Gestin de riesgos: principales conceptos y prcticas 83 Identificacin Mtodo sistemtico y organizado para descubrir los riesgos Pueden identificarse directa o indirectamente. DIRECTA: Identificando los orgenes (causas) que pueden ser: Programacin: agendas impuestas, excesivas restricciones contractuales, riesgos polticos Requisitos: inconsistencias, TBDs, crecientes Tcnicos: requisitos de rendimiento, seguridad, plataforma tecnolgica Calidad: deficiencias en las prcticas de desarrollo Logsticos: mantenibilidad, operacin, disponibilidad (el impacto se produce cuando el sistema est en uso. Despliegue: integracin, instalacin, distribucin INDIRECTA: Identificando el impacto y buscando las causas. Las reas de impacto son: Agenda Coste Calidad Operacin Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas 84 Identificacin: ejemplos Los principales factores que influyen en los riesgos de costes son: Incertidumbre en los requisito Estimacin incorrecta de costes Requisitos crecientes Presin de agendas Costes irrazonables Las principales causas de riesgo por los requisitos son: Requisitos incorrectos Requisitos incompletos Requisitos inconsistentes Requisitos de dificultad imprevista Requisitos imposibles Requisitos ambiguos Volatilidad Riesgos de costes Riesgos de requisitos Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas 85 Anlisis Examen de los riesgos para determinar sus dos caractersticas principales: Probabilidad Impacto El anlisis de los riesgos es una tarea de ejecucin cclica que debe realizarse y revisarse peridicamente de forma adecuada a las caractersticas del proyecto. El resultado del anlisis se plasma en un registro de los riesgos con la identificacin de su descripcin y caractersticas, con apoyo de herramientas para su consulta, revisin, priorizacin, etc. Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas 86 Gestin de proyectos predictiva Gestin de riesgos: probabilidad e impacto Gestin de riesgos: principales conceptos y prcticas 87 Tratamiento El tratamiento de los riesgos es el tercer paso del proceso de gestin de riesgos y comprende la implementacin de mtodos y tcnicas para reducir el impacto o la probabilidad. Las tcnicas se clasifican en 5 categoras en funcin de su finalidad: 1.- Evitar. No proceder con esa actividad o escoger una alternativa. Para riesgos con ratio probabiliad / impacto no admisible. 2.- Prevenir.Para reducir los parmetros de probabilidad y/o impacto. Actividades ms utilizada: Formacin / informacin, mantenimiento preventivo, disminucin del nivel de exposicin, 3.- Aceptacin o asuncin del riesgo. Puede resultar suficiente para riesgos de escaso impacto y probabilidad no usar medidas preventivas, si se dispone de reactivas en el caso de que se produzca, y su uso estadstico global supone menor coste global que la prevencin. 4.- Proteger. Medidas que reducen La probabilidad(Discos redundantes, sistemas elctricos redundantes, SAI) Reducen las consecuencias (Backup, extintor) 5.- Transferencia del riesgo. Se traspasa el riesgo a otra compaa, departamento o mbito. ejemplo: contratacin de un seguro, outsourcing Gestin de proyectos predictiva Gestin de riesgos: principales conceptos y prcticas 88 Gestin de proyectos predictiva ALTO RELEVANTE RELEVANTE MEDIO MEDIO BAJO Extrema Alta Moderada Escasa Mnima BajoMnimoMediaGraveMuy grave PROBABILIDAD DEL RIESGO IMPACTO DE LAS CONSECUENCIAS Gestin de riesgos: principales conceptos y prcticas cc-by: LizMarie PRCTICA: ANLISIS DE RIESGOS Produccin basada en procesos 89 Produccin basada en procesos 1.0 90 1950196019701980199019902000 Crisis del Software ? EL PROBLEMA Produccin basada en procesos 91 Gestin de proyectos predictiva Produccin basada en procesos LAS PRIMERA SOLUCIN: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 92 LA CALIDAD DEL RESULTADO DEPENDE DE LA CALIDAD DE LOS PROCESOS TQM - CMM - CMMI Jurn / Humphrey ESCENARIO DE LOS 80: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 93 PROCESOS Eficiencia Calidad Repetibilidad ESCENARIO DE LOS 80: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 94 cc-by: LizMarie PRCTICA: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 95 LA CALIDAD DEL RESULTADO DEPENDE DE LA CALIDAD DE LOS PROCESOS TQM - CMM - CMMI Jurn / Humphrey ESCENARIO DE LOS 80: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 96 PROCESOS Eficiencia Calidad Repetibilidad ESCENARIO DE LOS 80: PRODUCCIN BASADA EN PROCESOS Produccin basada en procesos 97 1959 MIL-Q 9858 1979 BS 5750 1987 ISO 9000 1997 TickIT 1991 ISO 9000-3 Adaptaciones para softw. 1995 ISO 12207 1995 Proy. SPICE 1993 CMM-SW Modelos especficos para software. 2003-05 ISO 15504 2001 CMMI Modelos CMM TR 15504 Modelos genricosModelos para software Trillium Bootstrap MODELOS DE PROCESOS Produccin basada en procesos 98 CMM-SW CMMI PMBOK ISO/IEC 12207 ISO 9000-3 ISO/IEC 15504 ESTNDARES PARA LA INGENIERA DEL SOFTWARE REFERENTES DE LA PRIMERA SOLUCIN Ingeniera del software ngeniera de procesos Gestin Predictiva Produccin basada en procesos 99 1950196019701980199019902000 LA PRIMERA SOLUCIN A LA CRISIS DEL SOFTWARE Ingeniera del software Ingeniera de procesosGestin de proyectos predictiva Produccin basada en procesos 100 1959 MIL-Q 9858 1979 BS 5750 1987 ISO 9000 1997 TickIT 1991 ISO 9000-3 Adaptaciones para softw. 1995 ISO 12207 1995 Proy. SPICE 1993 CMM-SW Modelos especficos para software. 2003-05 ISO 15504 2001 CMMI Modelos CMM TR 15504 Modelos genricosModelos para software Trillium Bootstrap POSTERIOR ANTTESIS A LOS MODELOS DE PROCESOS: AGILIDAD Produccin basada en procesos DSDM SCRUM CRYSTAL XP ASD PP AM ISD 1995 2000 Manifiesto gil AGILIDAD PROCESOS 101 Ingeniera de procesos de software 1.0 102 103 Conjunto repetitivo ... De actividades interrelacionadas ... Que se realizan sistemticamente ... Mediante las cuales ... Un entrada se convierte en una salida o resultado, ... despus de aadirle valor Qu es un proceso? Ingeniera de procesos de software PROCESOS: CONCEPTOS GENERALES 104 Facilitar el entendimiento y comunicacin Dar soporte a la gestin y mejora de procesos Proporcionar un soporte / gua automatizado Finalidad de los procesos de Ingeniera del Software Los procesos deben ser adecuados a la organizacin y tipo de proyectos Naturaleza del trabajo (Mto. / Desarrollo) Dominio de aplicacin Estructura del proceso de entrega (incremental, evolutivo, cascada...) Madurez de la organizacin Ingeniera de procesos de software: definicin Ingeniera de procesos de software 105 ACTIVIDAD 1 TAREA 1TAREA 1TAREA X PROCESO ACTIVIDAD n Un proceso est compuesto por actividades. Una actividad est compuesta de tareas. La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora) PLAN Tareas,agenda, asignaciones CHECK Evaluacin y medicin DO Ejecicin de planes y tareas ACT Problemas y acciones correctivas PROCESO INICIO FIN Ejemplo: estructura de procesos en ISO 12207 Ingeniera de procesos de software 106 Hay diferentes MODELOS para definir y documentar procesos: Diferentes niveles de abstraccin - Diferentes tipos de definicin Modelos de marco del ciclo de vida del software Los ms comunes son: evolutivo / incremental, cascada, prototipado, prototipado evolutivo, espiral, software reutilizable. Modelos de proceso del ciclo de vida del software Las principales referencias son: o ISO/IEC 12207 IT Software Life Cycle Processes o ISO/IEC 15504 IT Software Process Assesment Modelos de documentacin de procesos Ingeniera de procesos de software 107 Lenguajes de modelado grfico que sirven para representar a los procesos. Diagramas de flujo: Tcnica para especificar los detalles de un proceso en trminos de actividades, tareas, entradas, salidas, condiciones. IDEF0: Estndar para desarrollar representaciones grficas estructuradas de un sistema o entorno empresarial. Permite la construccin de modelos que comprenden funciones del sistema (actividades, acciones, operaciones, procesos), relaciones y datos. UML... Notaciones Ingeniera de procesos de software 108 El proceso de ingeniera del software puede examinarse en 2 niveles: Actividades tcnicas y de gestin ejecutadas durante la adquisicin, desarrollo, mantenimiento y retirada Meta-nivel concerniente a la definicin, implementacin, medicin y mejora de los procesos Ingeniera de procesos del software Niveles del proceso de Ingeniera del Software Proceso de ingeniera del software Ingeniera de procesos de software 109 Modelos genricos Basados en ciclos de mejora continua Tienen similitudes PDCA IDEALSM ISO 15504, Parte 7 ISO 9004:2000 Modelos ms relevantes de ingeniera de procesos Ingeniera de procesos del software (del ciclo de vida del software) Ingeniera de procesos de software 110 PLAN Identificar el problema Analizar el problema DO Desarrollar soluciones Implementar una solucin CHECK Evaluar los resultados ACT Determinar los siguientes pasos PDCA Ingeniera de procesos del software (del ciclo de vida del software) Ingeniera de procesos de software 111 Fase Inicial Fase de Diagnstico Fase de establecimiento Fase de accin Fase de aprendizaje IDEAL Ingeniera de procesos del software (del ciclo de vida del software) Ingeniera de procesos de software 112 1.Examineneeds2. Initiateimprov.3.Conductassess.OrganizationsneedsScopePreliminaryplanResultsActionplanImprovementsConfirmedimprovementsInstituc.gainsQuantifiedresultsReassessmentrequest4. Planimprov.5.Implementimprov.6. Confirmimprov.8. Monitorperform.7. SustaingainsISO / IEC 15504 Ingeniera de procesos de software 113 Base Experiencia Establecer infraestructura Planificar implementacin y cambio de procesos Implementacin y cambio de procesos Evaluacin del proceso Medicin Definicin Anlisis cualitativo Medicin Anlisis cualitativo Implementacin y cambio Implementacin y cambio PATRONES COMUNES Ingeniera de procesos de software 114 DEFINICIN MEDICIN IMPLEMENTACIN Y CAMBIO ANLISIS INGENIERA DE PROCESOS: Patrones comunes Ingeniera de procesos de software 115 Obtener, analizar e interpretar informacin CUANTITATIVA para: CARACTERIZAR Entender el proceso actual, entorno, etc. Disponer de informacin de la situacin anterior al cambio EVALUAR Determinar la consecucin de objetivos Identificar fortalezas y debilidades del proceso PREDECIR Entender las relaciones entre procesos y productos Establecer objetivos alcanzables de calidad, costes y agendas MEJORAR Identificar causas y oportunidades de mejora Seguir el rendimiento de los cambios y compararlo con lneas base Medicin Ingeniera de procesos de software 116 Se puede medir la calidad del proceso (en si mismo) o la calidad desus salidas. PROCESO SALIDAS (resultado) CONTEXTO Medicin Ingeniera de procesos de software 117 La forma de identificar qu medir y cmo hacerlo ms eficiente es basndose en los objetivos del proceso (goal-oriented / goal driven) 1) Empezar por especificar las necesidades de informacin2) Despus, identificar las medidas que satisfacen esas necesidades Fiabilidad: Margen de error de la medicin Validez: Capacidad de medir realmente lo que creemos que mide Qu medir Medicin Ingeniera de procesos de software 118 ANALTICO/A ANLISIS COMPARATIVO (Benchmarking) Evidencias cuantitativasde la necesidad de mejoras y del xito de iniciativas de mejoras Comparacin conorganizacin excelente enun campo y documentar sus practicas y herramientas Paradigmas Medicin Ingeniera de procesos de software 119 El modelo ANALTICO consiste en: ENTENDER REVISARCONSOLIDAR Ejemplos: Estudios experimentales y de observacin Simulacin de procesos Clasificacin ortogonal de defectos Control estadstico de procesos Medicin Ingeniera de procesos de software 120 El modelo ANLISIS COMPARATIVO consiste en medir: La madurez de una organizacin o la capacidad de sus procesos Los modelos de evaluacin de procesos recogen lo que se consideran best practices SW-CMM y CMMI CBA IPI y SCAMPI ISO 15504 ISO 15504, Part 8 ISO 9001 2 arquitecturas generales con distintas asunciones en cuanto al orden en el que medir los procesos: continua y escalonada Medicin Ingeniera de procesos de software 121 OBJETIVO Cada mtrica debe esta dirigida a cubrir / medir un objetivo. La idea es que debemos tener buenas razones para recoger datos. REQUISITO Cada objetivo debe contestarse con uno o varios requisitos (preguntas). El requisito debe establecerse de forma que la mtrica pueda responderlo claramente. MTRICA INDICADOR El indicador debe ser una entidad cuantitativa que de respuesta a un requisito especifico. Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software 122 Resumen de los pasos de GQM 1. Establecer los objetivos / expectativas de la coleccin de datos 2. Desarrollar una lista derequisitos / criterios de inters3. Establecer los indicadores4. Disear los medios para recoger los datos 5. Recoger y validar los datos 6. Analizar los datos Objetivosnegocio Qu tengo que conseguir? Qu quiero conocer? Indicador Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software 123 Ayuda para identificar requisitos: listar entidades y cuestiones relacionadas con los objetivos. Entidad 1 Entidad 2 ... Descartar segn sean comprensibles, cuantificables, conscientes, coherentes. Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software 124 Ejemplos de requisitos: Entidad FinancieraFiabilidad Sin cargos o abonos improc. Conformidad importe p- importe c ... Fabricantes de coches Sin averas Sinreparacin no accidental antes de 2 aos ...Establecimiento hotelero Rapidez Recepcin de mensajes < 15 min. Chequeo inmediato ... Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software 125 G1G2 Q1Q2Q3 I1I2I3I4 M1M2M3 Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software 126 Medicin Orientada a Objetivos (GQM) (Goal Question Metric) Ingeniera de procesos de software Modelo de procesos CMMI 1.0 127 128 Deficiencias en las metodologas Incapacidad para manejar el proceso de software En 1986, SEI (Software Engineering Institute): marco de trabajo sobre madurez de procesos En 1991, SEI desarroll Capability Maturity Model (CMM) Conjunto de prcticas recomendadas en determinadas reas clave de proceso Mejora la capacidad del proceso de software Gua en la seleccin de estrategias de mejora de proceso Establecer la madurez de los procesos Determina cuestiones crticas para la calidad y la mejora del proceso CMM (Capabiliti Maturity Model) Modelo de procesos : CMMI 129 Idea principal: distincin entre empresas maduras/inmaduras En una organizacin inmadura: - Procesos de software: improvisados o no respetados (si existen) - Planificacin en funcin de los problemas - Presupuestos y planificacin incumplidos - Sin base objetiva para evaluar la calidad o para resolver problemas - Inexistencia o reduccin de las actividades de mejora de la calidad En una organizacin madura: - Capacidad de gestin: desarrollo de software y procesos de mantenimiento - Proceso de software difundido al equipo y planificado - Procesos modificables: pruebas piloto controladas y anlisis de coste/beneficio - Roles y responsabilidades establecidos en el proyecto y la organizacin - Gestores: monitorizacin la calidad de los productos y de los procesos - Planificaciones y presupuestos realistas: rendimientos histricos - Proceso disciplinado en el que todos los participantes entienden su valor, existiendo adems la infraestructura necesaria para soportar el proceso Organizaciones de software maduras / inmaduras Modelo de procesos : CMMI 130 DoD (Departamento de Defensa de los Estados Unidos), SEI (Software Engineering Institute) y NDIA (National Defense Industrial Association). Ms de 100 organizaciones involucradas U.S. Army, Navy, Air Force Federal AviationAdministration National Security Agency Software Engineering Institute ADP, Inc. AT&T Labs BAE Boeing Computer Sciences Corporation EER Systems Ericsson Canada Ernst and Young General Dynamics Harris Corporation Honeywell KPMG Lockheed Martin Motorola Northrop Grumman Pacific Bell Q-Labs Raytheon Reuters Rockwell Collins SAIC Software Productivity Consortium Sverdrup Corporation TeraQuest Thomson CSF TRW Proyecto CMMI Modelo de procesos : CMMI 131 Modelo combinadoSystem Engineering/Software Engineering Aplicable: Slo a proyectos de software engineering Slo a proyectos de system engineering Ambos Ambas incluyen el mismo contenido y consiguen idnticos objetivos La representacin continua centra su actuacin en la CAPACIDAD DE LOS PROCESOS La representacin escalonada centra su actuacin en la MADUREZ DE LA ORGANIZACIN Continua o escalonada? Modelos CMMI Modelo de procesos : CMMI 132 Heredado de los modelos de origen. Software CMM--Escalonado SECM--Continuo IPD CMM--Hbrido En el del equipo de desarrollo de CMMI haba defensores dede cada una de las representaciones. Seleccionar una nica representacin se planteaba como algo too hard. Compromiso: Inicialmente soportar dos representaciones del modelo con contenidos equivalentes. Por qu dos representaciones del modelo? Modelo de procesos : CMMI 133 . . .para un conjunto dereas de proceso establecido Escalonado ML 1 ML2 ML3 ML4 ML5 . . .para un rea de procesoo un conjunto de reas de proceso Continuo PAPA Capacidad PA Un modelo, dos representaciones Modelo de procesos : CMMI 134 Capacidad es un atributo que se aplica a los procesos y define la eficacia del mismo para conseguir los objetivos previstos. Madurez es un atributo que se aplica a la organizacin y define su potencial de calidad en la produccin. ML 1 ML2 ML3 ML4 ML5

Capacidad y madurez Modelo de procesos : CMMI 135 0 Incompleto Los procesos no se realizan, o no consiguen sus objetivos 1 Ejecutado Los procesos se ejecutan y se logran los objetivos especficos del rea 2 Gestionado Los procesos que adems de considerarse ejecutados son tambin planificados, revisados y evaluados para comprobar que cumplen los requisitos 3 Definido Los procesos que adems de considerarse gestionados se ajustan al conjunto de procesos estndar conforme a las lneas directivas de la organizacin 4 Gestin cuantificada Procesos definidos que son controlados utilizando tcnicas estadsticas u otras tcnicas cuantitativas 5 Optimizado Procesos gestionados cuantificadamente que son cambiados y adaptados para conseguir objetivos relevantes de negocio Niveles de capacidad Modelo de procesos : CMMI 136 Los valores describen cmo de bien se realiza el proceso (nivel de capacidad del proceso). Capacidad Procesos AreaProceso 1 Area Proceso n AreaProceso 2 Area Proceso 3 Proceso bien ejecutado ymejorado continuamente Proceso no ejecutado Dimensin de la capacidad Modelo de procesos : CMMI 137 1 Inicial Control deficiente e impredecibilidad de los resultados 2 Gestionado Es posible obtener niveles de calidad previamente alcanzados 3 Definido Los procesos realizados se encuentran normalizados, son conocidos y comprendidos 4 Gestionado cuantitativamente Los procesos incluyen indicadores de medicin y control 5 Optimizado Centralizacin en la mejora de los procesos Niveles de madurez Modelo de procesos : CMMI 138 Proceso imprevisible, poco controlado y reactivo Proceso caracterizado para los proyectos y a menudo reactivo Proceso caracterizado para la organizacin y proactivo Proceso medidoy controlado Centrado en la mejora de procesos Optimizado Gestionado cuantitativamente Definido Inicial Gestionado 12 3 45Dimensin de la madurez Modelo de procesos : CMMI 139 CMMI recoge prcticas para 22 reas de procesos Las reas de procesos agrupan a las actividades necesarias para la ejecucin de los proyectos de ingeniera de sistemas y de software El modelo en su representacin escalonada clasifica a las 22 reas de proceso en aquellas cuya gestin es necesaria para lograr cada nivel de calidad El modelo en su representacin continua las clasifica segn a la categora que pertenecen: Gestin de proyectos, ingeniera, soporte y gestin de procesos reas de procesos Modelo de procesos : CMMI 140

1 INICIAL 2 GESTIONADO 3 DEFINIDO 4 GESTIONADO CUANTITATIVAMENTE 5 OPTIMIZADO Gestin de requisitos Planificacin de proyecto Monitorizacin y control de proyectos Gestin y acuerdo con suministradores Medicin y anlisis Gestin de la calidad de procesos y productos Gestin de la configuracin Desarrollo de requisitos Solucin tcnica Verificacin Validacin Integracin de producto Procesos orientados a la organizacin Definicin de los procesos de la organizacin Formacin Gestin integrada de proyecto Gestin de riesgos Anlisis y resolucin de decisiones Gestin cuantificada de proyectos Rendimiento de los procesos de la organizacin Innovacin y desarrollo NIVEL DE MADUREZREAS DE PROCESO reas de procesos en la representacin escalonada Modelo de procesos : CMMI 141

GESTIN DE PROCESOS INGENIERA SOPORTE GESTIN DE PROYECTOS Definicin de los procesos de la organizacin Procesos orientados a la organizacin Formacin Rendimiento de los procesos de la organizacin Innovacin ydesarrollo Desarrollo de requisitos Gestin de requisitos Soluciones tcnicas Integracin de producto Verificacin Validacin Gestin de la configuracin Gestin de la calidad de procesos y productos Medicin y anlisis Anlisis y resolucin de decisiones Anlisis y resolucin de problemas Planificacin de proyecto Monitorizacin y control de proyecto Gestin y acuerdo con proveedores Gestin integrada de proyecto Gestin de riesgos Gestin cuantificada de proyecto CATEGORAREAS DE PROCESO reas de procesos en la representacin continua Modelo de procesos : CMMI 142 rea de proceso Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos. Componentes requeridos Los objetivos genricos asociados a un nivel de capacidad establecen lo que una organizacin debe alcanzar en ese nivel de capacidad.El logro de cada uno de esos objetivos en un rea de proceso significa mejorar el control en la ejecucin del rea de proceso Objetivo genrico Objetivo especfico Los objetivos especficos se aplican a una nica rea de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propsito del rea de proceso Cmo usar el modelo Modelo de procesos : CMMI 143 Componentes esperados Una practica genrica se aplica a cualquier rea de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso. Prctica genrica Prctica especfica Una practica especfica es una actividad que se considera importante en la realizacin del objetivo especifico al cual est asociado.Las prcticas especficas describen las actividadesesperadas para lograr la meta especfica de un rea de proceso. Componentes informativos Propsito Notas introductorias Referencias Las referencias son indicadores de otras reas de proceso relacionadas que pueden aportar informacin adicional o ms detallada Nombres Tablas de relaciones prctica-objetivo Prcticas Cmo usar el modelo Modelo de procesos : CMMI 144 Componentes informativos Propsito Notas introductorias Referencias Las referencias son indicadores de otras reas de proceso relacionadas que pueden aportar informacin adicional o ms detallada Nombres Tablas de relaciones prctica-objetivo Prcticas Productos tpicos Subprcticas Una subpractica es una descripcin detallada que sirve como gua para la interpretacin de una practica genrica o especifica Ampliaciones de disciplina Las ampliaciones contienen informacin relevante de una disciplina particular y relacionada con una practica especifica. Elaboraciones de prcticas genricas Una elaboracin de una practica genrica es una gua de cmo la practica genrica debe aplicarse al rea de proceso. Cmo usar el modelo Modelo de procesos : CMMI 145 rea de proceso Propsito Notas Referencias Objetivos especficos Objetivos genricos Mapa del documento Modelo de procesos : CMMI 146 R. Metas-Practicas Practicas especificas Nombres Mapa del documento Modelo de procesos : CMMI 147 Productos de trabajo Practicas genericas Elaboraciones Notas Subpracticas Mapa del documento Modelo de procesos : CMMI 148 CMMI SE/SW incluye 22 reas de proceso Las reas de proceso son iguales en ambas representaciones del modelo En la representacin continua, las reas de proceso se agrupan por categoras: Gestin de proyectos, Ingeniera, Soporte y Gestin de procesosProcess areas by capability En la representacin escalonada, las reas de proceso se agrupan por niveles de madurez (2 5) Process areas by maturity level reas de proceso Modelo de procesos : CMMI 149 Gestin de proyecto El modelo CMMI SE/SW incluye seis reas de proceso en gestin de proyectos: Planificacin de proyecto Monitorizacin y control de proyecto Gestin y acuerdos con proveedores Gestin integrada de proyecto Gestin de riesgos Gestin cuantificada de proyecto Las reas de procesos de gestin de proyectos cubren las actividades relacionadas con la planificacin, monitorizacin y control del proyecto. reas de proceso Modelo de procesos : CMMI 150

PP Que construir Que hacer SAM PMC Quecontrolar Replanificar Planes Estado, cuestiones,resultados de progreso y revisiones de hitos Requisitos de componente de producto Cuestiones tcnicas Revisiones y test de aceptacin reas de procesoSoporte e Ingeniera Estado, cuestiones, resultadosde evaluaciones de producto,Medidas y anlisis Necesidades de medicin Acciones Correctivas Proveedor Acuerdos Proveedor Acciones Correctivas Gestin de proyecto: reas bsicas reas de proceso Modelo de procesos : CMMI 151 Datos Planificacin Establecer Estimaciones Obtener Compromisos con el Plan Desarrollar Plan de Proyecto Planes de Proyecto PMC Gestin de proyecto: planificacin de proyecto Propsito: establecer y mantener planes que definan las actividades del proyecto reas de proceso Modelo de procesos : CMMI 152 Gestin de proyecto: monitorizacin y control Propsito: Proporcionar informacin sobre el progreso del proyecto que permita tomar acciones correctivas cuando la ejecucin del proyecto se desva significativamente del plan. Planes de Proyecto Monitorizar Riesgos Monitorizar Compromisos Analizar Cuestiones Tomar Acciones correctivas Conducir Revisiones Monitorizar Gestin Datos Monitorizar Parmetros Planificacin Gestionar AccionesCorrectivas Monitorizar Proyecto contra Planes Conducir Revisiones de Progreso Monitorizar Implicacin Stakeholder Gestionar Acciones correctivas PP reas de proceso Modelo de procesos : CMMI 153 Gestin de proyecto: gestin y acuerdos con proveedores Propsito: Gestionar la adquisicin de productos a proveedores segn un acuerdo formal existente. Producto Lista de productos Establecer Acuerdos Acuerdo Proveedor Revisar Productos COTS Determinar Tipo Adquisicin Transicin Productos Aceptar Producto Seleccionar Proveedores Requisitos Proveedor Ejecutar Acuerdos Establecer Acuerdos con Proveedores SatisfacerAcuerdos Proveedor reas de proceso Modelo de procesos : CMMI 154 Ingeniera El modelo CMMI SE/SW incluye seis reas de proceso en ingeniera: Desarrollo de requisitos Gestin de requisitos Soluciones tcnicas Integracin de producto Verificacin Validacin Las reas de proceso de ingeniera cubren las practicas de desarrollo y mantenimiento compartidas por diferentes disciplinas como ingeniera de software e ingeniera de sistemas. reas de proceso Modelo de procesos : CMMI 155

Ingeniera: reas bsicas VER Componentes de producto, productos del trabajo,informes de verificacin y validacin RD PI VAL CLIENTE TS REQM Requisitos Necesidades del cliente Requisitos de producto &Componente de producto Componentes Producto Soluciones Alternativas Requisi- tos Producto reas de proceso Modelo de procesos : CMMI 156 Ingeniera: gestin de requisitos Propsito: Gestionar los requisitos del producto y de componentes del producto del proyecto e identificar inconsistencias entre los requisitos, los planes del proyecto y los resultados del trabajo. Requisitos Entender losRequisitos Obtener compromisos a Requisitos Identificar Inconsistencias entreProyecto yRequisitos Matriz Trazabilidad Mantener Trazabilidad Requisitos Gestin de Requisitos Gestionar Cambios Requisitos reas de proceso Modelo de procesos : CMMI 157 Ingeniera: desarrollo de requisitos Propsito: Producir y analizar los requisitos del cliente, del producto y de los componentes de producto. Desarrollar Requisitos del Cliente Requisitos Cliente Requisitos Producto Desarrollar Requisitos del Producto Analizar yValidar Requisitos Requisitos Validados reas de proceso Modelo de procesos : CMMI 158 Ingeniera: solucin tcnica Propsito: Desarrollar, disear e implementar soluciones a los requisitos. Seleccionar Soluciones Producto-Comp. Requisitos Validados Diseo detallado & Documentacion Producto Entregado DesarrollarDiseo ImplementarProducto Diseos alternativos y Criterios de evaluacin reas de proceso Modelo de procesos : CMMI 159 Ingeniera: integracin de producto Propsito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto. EnsamblarComp. Producto y Entregar Producto Plan Integracin Preparar Integracin Producto Solucin Tcnica DAR Garantizar Interfaces Compatibles Assemblies Sub-assemblies reas de proceso Modelo de procesos : CMMI 160 Ingeniera: verificacin Propsito: Asegurar que los resultados del trabajo seleccionados cumplen los requisitos especificados. Plan Verificacin Preparar paraVerificacin Acciones Correctivas Verificar Productos Seleccionados Ejecutar Peer Reviews reas de proceso Modelo de procesos : CMMI 161 Ingeniera: validacin Propsito: Demostrar que un producto o componente de producto satisface su uso previsto en el entorno previsto. - Requisitos Cliente - Requisitos Producto - Productos - Validacin de Requisitos Preparar para Validacin - Plan Validacin Requisitos - Plan Validacin Producto - Procesos y necesidades de Soporte Validar Producto o Componentes Producto -Conformidad -Deficiencias reas de proceso Modelo de procesos : CMMI 162 Soporte El modelo CMMI SE/SW incluye cinco reas de proceso en soporte: Gestin de la configuracin Gestin de la calidad de procesos y productos Medicin y anlisis Anlisis y resolucin de decisiones Anlisis y resolucin de problemas Las reas de procesos de soporte cubren las practicas que sirven de base para el desarrollo del producto y su mantenimiento. reas de proceso Modelo de procesos : CMMI 163

Soporte: reas bsicas PPQA MA CM Todas las reas de proceso Medidas, anlisis Informacinnecesaria Elementos deconfiguracin; peticiones decambio Lneas base; informes de auditoria Procesos y resultados; estndares y procedimientos Calidad y no conformidades reas de proceso Modelo de procesos : CMMI 164 Soporte: gestin de la configuracin Propsito: Establecer y mantener la integridad de todos losproductos de trabajo, utilizando identificacin de la configuracin, control de la configuracin, informes de estado de configuracin y auditorias de la configuracin. Elementos Accin Resultados Auditoria Estado Establecer Integridad BBDD Peticiones de cambio Sistema Gestin Configuracin Peticiones de cambio Seguir y controlar cambios Establecer Lneas Base reas de proceso Modelo de procesos : CMMI 165 Soporte: aseguramiento de la calidad de procesos y producto Propsito: Proporcionar un entendimiento objetivo de los procesos y los productos del trabajo asociado. Productos trabajo Informes y Registros

Evaluacin ObjetivaProcesos Evaluacin Objetiva P. Trabajoy Servicios Evaluar objetivamente procesos y productos de trabajo Establecer Registros Comunicary GarantizarResolucin de No Conformidades Proporcionar entendimiento objetivo reas de proceso Modelo de procesos : CMMI 166 Soporte: medicin y anlisis Propsito: Desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las necesidades de informacin de la gerencia. Indicadores Medicin Proporcionar resultados de mediciones Personal Medicin Repositorio Medicin Objetivos Medicin Procedimientos,Herramientas Ajustar actividades de medicin y anlisis reas de proceso Modelo de procesos : CMMI 167 Gestin de procesos El modelo CMMI SE/SW incluye cinco reas de proceso en gestin de procesos: Definicin de procesos Enfoque de procesos ala organizacin Formacin Rendimiento de los procesos Innovacin y desarrollo Las reas de procesos de soporte cubren las actividades de definicin, planificacin, recursos, desarrollo, implementacin, monitorizacin, control, evaluacin, medicin y mejora de procesos.reas de proceso Modelo de procesos : CMMI 168

Gestin de procesos: reas bsicas

OPF OPD Recursos yCoordinacin OT Procesos Estndares yPropios Formacin en procesos Necesidadesy objetivos de procesos ProcesosEstndares y Propios SeniorManagement Objetivos Negocio reas de proceso de gestin de proyecto, soporte e ingeniera NecesidadesFormacin Informacin de mejora (e.j., lessons learned, datos) Propsitos de mejora de procesos; Participacin en definir, evaluar, y desarrollar procesos reas de proceso Modelo de procesos : CMMI Modelo de procesos ISO / IEC 15504 1.0 169 170 En enero de 1993 la comisin ISO/IEC JTC1 aprob un programa de trabajopara el desarrollo de un modelo que fuera la base de un futuro estndarinternacional para la evaluacin de los procesos del ciclo de vida del software. Este trabajo recibi el nombre de proyecto SPICE (Software ProcessImprovement and Capability dEtermination), y en junio de 1995, con lapublicacin de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados. Proyecto SPICE Proyecto -> Instruccin Tcnica -> Estndar En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pas a la fase de informe tcnico con la denominacin ISO/IEC TR 15504. La instruccin tcnica consta de 9 apartados, recogidos en volmenes independientes, que se han ido publicando como redaccin definitiva del estndar internacional ISO/IEC 15504 durante el periodo 2003-2005. mbito de aplicacin Cualquier organizacin de software que quiera establecer y mejorar su capacidad en adquisicin, suministro, desarrollo, operacin evolucin y soporte de software. Independientemente de estructuras, filosofas de gestin, modelos de ciclo de vida de software, tecnologas o metodologas de desarrollo. ISO/IEC 15504: Origen Modelo de procesos : ISO / IEC 15504 171 Conceptos y gua deintroduccin Guia para det. capacidad de proveedores Realizacin de evaluacin Gua deevaluacin Guia de capacitacin de evaluadores Vocabulario Gua para mejora de procesos Modelo de ref. para procesos y capacidad Modelo de evaluacin y gua de indic. P1 P9 P7 P8 P6 P3 P4 P2 P5 Estructura Modelo de procesos : ISO / IEC 15504 172 Marco para mtodos de evaluacin, no es un mtodo o modelo en s. Comprende: Evaluacin de procesos Mejora de procesos Determinacin de capacidad Alineado con ISO/IEC 12207 Information Technology Software Life Cycle Processes Dimensiones del modelo El modelo tiene una arquitectura basada en dos dimensiones: Dimensin de proceso Caracterizada por las declaraciones del propsito de un proceso, que son objetivos esenciales mensurables de un proceso. Dimensin de capacidad de proceso Caracterizada por una serie de atributos de proceso, aplicables a cualquier proceso, que representan caractersticas mensurables necesarias para gestionar un proceso y mejorar su capacidad. Caractersticas Modelo de procesos : ISO / IEC 15504 173 Dimensin de proceso Agrupa los procesos en tres grupos correspondientes a los procesos del ciclo de vida que contienen cinco categoras de acuerdo al tipo de actividad. Procesos primarios CUS: Cliente Proveedor ENG: Ingeniera Procesos organizacionales MAN: Gestin ORG: Organizacin Procesos de soporte SUP: Soporte Caractersticas Modelo de procesos : ISO / IEC 15504 174 CUS: Cliente - proveedor CUS.1 Proceso de adquisicin CUS.1.1 Proceso de preparacin de la adquisicin CUS.1.2 Proceso de seleccin de proveedor CUS.1.3 Procesos de seguimiento de proveedor CUS.1.4 Proceso de aceptacin del cliente CUS.2 Proceso de suministro CUS.3 Proceso de obtencin de requisitos CUS.4 Proceso de operacin CUS.4.1 Proceso de uso operacional CUS.4.2 Proceso de soporte al cliente La categora CUS est formada por procesos que afectan directamente al cliente, soportan el desarrollo y la transicin del software al cliente y permiten la correcta operacin y uso del producto y/o servicio de software. Dimensin de proceso Modelo de procesos : ISO / IEC 15504 175 ENG: Ingeniera La categora ENG est formada por procesos que directamente especifican, implementan o mantienen el producto de software, su relacin con el sistema y documentacin. ENG.1 Proceso de desarrollo ENG.1.1 Proceso de anlisis y diseo de requisitos de sistema. ENG.1.2 Proceso de anlisis de requisitos de software. ENG.1.3 Procesos de diseo de software. ENG.1.4 Proceso de construccin de software. ENG.1.5 Proceso de integracin de software. ENG.1.6 Proceso de prueba de software. ENG.1.7 Proceso de integracin y prueba de sistema. ENG.2 Proceso de mantenimiento de software Dimensin de proceso Modelo de procesos : ISO / IEC 15504 176 SUP: Soporte La categora SUP est formada por procesos que dan soporte al resto de procesos (incluidos los SUP), en distintos puntos del ciclo de vida del software. SUP.1 Proceso de documentacin SUP.2 Proceso de gestin de configuracin SUP.3 Proceso de aseguramiento de calidad SUP.4 Proceso de verificacin SUP.5 Proceso de validacin SUP.6 Proceso de revisin conjunta SUP.7 Proceso de auditora Dimensin de proceso Modelo de procesos : ISO / IEC 15504 177 MAN: Gestin La categora MAN est formada por procesos utilizados en la gestin de cualquier tipo de proyecto o proceso en el ciclo de vida del software. MAN.1 Proceso de gestin MAN.2 Proceso de gestin de proyecto MAN.3 Gestin de calidad MAN.4 Gestin de riesgos Dimensin de proceso Modelo de procesos : ISO / IEC 15504 178 ORG: Organizacin La categora ORG est formada por procesos que establecen los objetivos de negocio de la organizacin. ORG.1 Proceso de alineacin organizacional. ORG.2 Proceso de mejora ORG.2.1 Proceso de definicin de proceso. ORG.2.2 Proceso de evaluacin de proceso. ORG.2.3 Proceso de mejora de proceso. ORG.3 Proceso de gestin de RR.HH. ORG.4 Proceso de infraestructura ORG.5 Proceso de medicin ORG.6 Proceso de reutilizacin Dimensin de proceso Modelo de procesos : ISO / IEC 15504 179 Componentes de proceso IdentificadorIdentifica la categora del proceso y el n de secuencia en la categora. Distingue entre procesos de primer y segundo nivel. NombreFrase descriptivo del contenido del proceso Tipo Hay 5 tipos de proceso. 3 de primer nivel (bsico, extendido y nuevo) y 2 de segundo nivel (componente, componente extendido) Propsito Prrafo que establece el propsito del proceso indicando los objetivos globales de su ejecucin. Salidas Lista de resultados observables de la implementacin exitosa del proceso Notas Dimensin de proceso Modelo de procesos : ISO / IEC 15504 180 Define una escala de medida para determinar la capacidad de cualquier proceso Consta de seis niveles de capacidad Nivel 0 Incompleto Nivel 1 RealizadoNivel 2 Gestionado Nivel 3 EstablecidoNivel 4 Predecible Nivel 5 En optimizacin ...y un conjunto de atributos de procesos asociados al nivel de capacidad Capacidad de proceso: rango de resultados que espera obtenerse al seguir el proceso. Dimensin de capacidad Modelo de procesos : ISO / IEC 15504 181 Niveles de capacidad y atributos Nivel 0: Proceso Incompleto Nivel 1: Proceso Realizado Nivel 2: Proceso Gestionado PA 2.1 Gestin de realizacin PA 2.2 Gestin productos Nivel 3: Proceso Establecido PA 3.1 Definicin de proceso PA 3.2 Recursos de proceso Nivel 4: Proceso Predecible PA 4.1 Medicin PA 4.2 Control de proceso Nivel 5: Proceso en optimizacin PA 5.1 Cambio de proceso PA 5.2 Mejora continua Dimensin de capacidad Modelo de procesos : ISO / IEC 15504 182 Medicin de atributos Los atributos de un proceso se evalan con N (Not), P (Partially), L (Largely) y F (Fully), siendo: N No alcanzado (0% a 15%). Escasa o ninguna evidencia de la consecucin del atributo. P Parcialmente alcanzado (16% a 50%). Evidencia de un enfoque sistemtico y de la consecucindel atributo. Algunos aspectos de la consecucin pueden ser impredecibles. L Ampliamente alcanzado (51% a 85%). Evidencia de un enfoque sistemtico y de una consecucin significativa del atributo. La realizacin del proceso puede variar en algunas reas. F Totalmente alcanzado (86% a 100%). Evidencia de un enfoque completo y sistemtico y de la consecucin plena del atributo. Dimensin de capacidad Modelo de procesos : ISO / IEC 15504 Ciclo de vida del software 1.0 183 En este tema se tratan los siguientes conceptos: Ciclo de vida del software. Procesos del ciclo de vida. Modelos de ciclo de vida. El marco del ciclo de vida del software cubre desde la conceptuacin de las ideas iniciales del producto hasta el fin de su uso (retirada). ISO/IEC 12207 1995 Desde el punto de vista del estndar (v. Introduccin a la Ingeniera del Software) un proceso es un conjunto de actividades y tareas relacionadas, que al ejecutarse de forma conjunta transforman una entrada en una salida. Introduccin Ciclo de vida del software Ciclo de vida del software 184 12207 define los siguientes procesos primarios en el ciclo de vida del software: ADQUISICIN Proceso global que sigue el adquiriente para obtener el producto. SUMINISTRO Proceso global que sigue el suministrador para proporcionar el producto. DESARROLLO Proceso empleado por el suministrador para el diseo, construccin y pruebas del producto. OPERACIN Proceso seguido por el operador en el da a da para el uso del producto. MANTENIMIENTO Proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio producto como en su entorno de operacin. Procesos primarios del ciclo de vida del software Ciclo de vida del software 185 El estndar 12207 identifica los procesos de soporte que pueden ser utilizados desde un proceso primario, o incluso desde otro proceso de soporte. Los procesos de soporte son: DOCUMENTACIN Actividades empleadas para registrar informacin especfica empleada por otros procesos. GESTIN DE LA CONFIGURACIN Actividades empleadas para mantener un registro de los productos generados en la ejecucin de los procesos. ASEGURAMIENTO DE LA CALIDAD Actividades empleadas para garantizar de forma objetiva que el producto y los procesos asociados son conformes a los requisitos documentados y a las planificaciones. VERIFICACIN Actividades empleadas para verificar el producto. VALIDACIN Actividades empleadas para validar el producto. Procesos de soporte del ciclo de vida del software Ciclo de vida del software 186 REUNIONES DE REVISIN Reuniones empleadas por las dos partes para evaluar el estado del producto y de las actividades. AUDITORAS Actividades para determinar que el proyecto cumple con los requisitos, planes y contratos. RESOLUCIN DE PROBLEMAS Actividades para analizar y resolver problemas relativas al proyecto, sea cual sea su fuente y naturaleza. Procesos de soporte del ciclo de vida del software Ciclo de vida del software 187 El estndar 12207 identifica los procesos que deben realizarse en el contexto de la organizacin que va a ejecutar el proyecto.Normalmente estos procesos se aplican de forma comn sobre mltiples proyectos. De hecho las organizaciones ms maduras los identifican e institucionalizan. GESTIN Describe las actividades de gestin de la organizacin, incluyendo tambin la gestin de proyectos. INFRAESTRUCTURA Actividades necesarias para que puedan realizarse otros procesos del ciclo de vida. Incluye entre otros el capital y el personal. MEJORA Actividades realizadas para mejorar la capacidad del resto de procesos. FORMACIN Procesos organizacionales Ciclo de vida del software 188 189 AdquirientePROCESO DE ADQUISICIN PROCESO DE SUMINISTRO PROCESO DE OPERACIN PROCESO DEMANTENIMIENTO PROCESO DE DESARROLLO Suministrador Operador Usuario Desarrollador Mantenedor Usuario del proceso de soporte Gestor P R O C E S O S D E S O P O R T E Documentacin Gestin de la configuracin Aseguramiento calidad Verificacin Validacin Reuniones de seguimiento Auditora Resolucin de problemas Gestin Infraestructura Mejora Formacin ROL ADQUISICIN ROL SUMINISTRO OPERACIN ROL INGENIERA ROL SOPORTE ROL ORGANIZACIONAL ROL usa emplea contrato empleaemplea usa emplea emplea emplea emplea Ciclo de vida del software VISIN GENERAL DE LOS PROCESOS, RELACIONES Y ROLES Ciclos de desarrollo y patrones de gestin de proyectos 1.0 190 Fases 123456 Fases 123456 SECUENCIAL (cascada) CONCURRENTE Se puede realizar de forma o El trabajo Ciclos de desarrollo y patrones de gestin de proyectos 191 Los procesos y tecnologa Las personas INGENIERA DE PROCESOS AGILIDAD o know how necesario se encuentra dividido en mayor o menor % en: El conocimiento Ciclos de desarrollo y patrones de gestin de proyectos 192 COMPLETA INCREMENTAL o Se realiza de forma El desarrollo Ciclos de desarrollo y patrones de gestin de proyectos 193 CONTINUAITERATIVA Las entregas se pueden producir con secuencia: En un DESARROLLO INCREMENTAL Ciclos de desarrollo y patrones de gestin de proyectos 194 Con un flujo continuo de trabajoSin empaquetartareas en timeboxing (sprints) Son apropiadas las tcnicas de gestin visual kanban para evitar los cuellos de botella y los tiempos muertos.Ajustndolas con criterios de flexibilidad a las circunstancias de nuestro trabajo y equipo Secuencial EquipoTrabajo Libre Polivalente Especialistas Para gestionar un DESARROLLO INCREMENTAL Ciclos de desarrollo y patrones de gestin de proyectos 195 EstrategiaTctica Completo Incremental Incremento Iterativo Incremento continuo TRABAJO Cascada Fases solapadasPersonas Procesos CONOCIMIENTO AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto DESARROLLO Gestin de proyectos: diagrama de conceptos Ciclos de desarrollo y patrones de gestin de proyectos 196 Completo Incremental Incremento Iterativo Incremento continuo Cascada Fases solapadasPersonas Procesos AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto EstrategiaTctica TRABAJOCONOCIMIENTODESARROLLO Gestin predictiva Ciclos de desarrollo y patrones de gestin de proyectos 197 Completo Incremental Incremento Iterativo Incremento continuo Cascada Fases solapadasPersonas Procesos AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto EstrategiaTctica TRABAJOCONOCIMIENTODESARROLLO Ingeniera concurrente Ciclos de desarrollo y patrones de gestin de proyectos 198 Completo Incremental Incremento Iterativo Incremento continuo Cascada Fases solapadasPersonas Procesos AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto EstrategiaTctica TRABAJOCONOCIMIENTODESARROLLO Agilidad Ciclos de desarrollo y patrones de gestin de proyectos 199 Completo Incremental Incremento Iterativo Incremento continuo Cascada Fases solapadasPersonas Procesos AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto EstrategiaTctica TRABAJOCONOCIMIENTODESARROLLO Prcticas Scrum Ciclos de desarrollo y patrones de gestin de proyectos 200 Completo Incremental Incremento Iterativo Incremento continuo Cascada Fases solapadasPersonas Procesos AGILIDAD INGENIERA CONCURRENTE INGENIERA SECUENCIAL GESTIN PREDICTIVA GESTIN EVOLUTIVA o Prcticas giles Prcticas PMBOK Plan de proyecto EstrategiaTctica TRABAJOCONOCIMIENTODESARROLLO Prcticas kanban Ciclos de desarrollo y patrones de gestin de proyectos 201 Al iniciar el proyecto, el responsable de la arquitectura de procesos debe realizar los siguientes pasos: Anlisis de las circunstancias ambientales del proyecto. Diseo del modelo especfico de ciclo de vida para el proyecto (sobre las bases de los diseos ms apropiados, para el desarrollo y la evolucin del sistema de software. Mapeo de las actividades sobre el modelo. Desarrollo del plan para la gestin del ciclo de vida del proyecto. Debe considerar aspectos como: Posibilidad de descomposicin del sistema en subsistemas de software, con agendas y entregas diferenciadas. Estabilidad esperada de los requisitos. Novedad del proceso o procesos gestionados por el sistema en el entorno del cliente. Criticidad de las agendas y presupuestos. Grado de complejidad del interfaz de operacin, criticidad de la usuabilidad. Grado de conocimiento y familiaridad con el entorno de desarrollo, componentes externos empleados, etc. Eleccin del modelo de gestin y ciclo de desarrollo Ciclos de desarrollo y patrones de gestin de proyectos 202 Los requisitos del software en la gestin de proyectos predictiva 1.0 203 Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseado o codificado que est un programa, si se ha analizado y especificado pobremente, decepcionar al usuario y desprestigiar al que lo ha desarrollado. Roger S. Pressman Ingeniera del Software Mc Graw Hill 1995 La parte ms difcil en la construccin de sistemas software es decidir precisamente qu construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con humanos,mquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto el resultado final si se realiza de forma errnea. Ninguna otra parte es tan difcil de rectificar posteriormente. Frederick P. Brooks, Jr., The Mythical Man-Month,Addison-Wesley, 1995. Importancia de los requisitos Los requisitos del software en la gestin de proyectos predictiva 204 Un estudio realizado por Standish Group analiz el desarrollo de 8000 proyectos de software, realizadospor 350 empresas diferentes y concluy que slo el 16% de los proyectos de software se realizan con xito. El estudio identific como principales causas de los problemas: Requisitos deficientes La planificacin de agendas y estimaciones de costes no se realizaron en base a los requisitos Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto Los criterios para determinar el xito de un proyecto son: Sin desviaciones en las fechas previstas. Sin desviaciones en los costes estimados. Que el producto final cubra las expectativas y necesidades del cliente. Que funcione correctamente. Qu porcentaje de proyectos concluyen con xito? Importancia de los requisitos 205 Los requisitos del software en la gestin de proyectos predictiva Porqu fracasan los proyectos? Requisitos incompletos: 13% Cambios en requisitos: 9% No implicacin de usuarios: 12% Expectativas no realistas: 10% Producto no necesario: 8% TOTAL: 52% Importancia de los requisitos 206 Los requisitos del software en la gestin de proyectos