White Paper Una Introducción a CMMI

Tamaño: px
Comenzar la demostración a partir de la página:

Download "White Paper 2006. Una Introducción a CMMI"

Transcripción

1 White Paper 2006 Una Introducción a CMMI White Paper 2006

2 Contenidos INTRODUCCIÓN... 4 NIVELES DE MADUREZ Y ÁREAS DE PROCESO...4 UN MODELO DE REFERENCIA NO ES LA DESCRIPCIÓN DE UN PROCESO...7 PROCESOS ESTADÍSTICAMENTE CONTROLADOS... 7 ESTABILIDAD DEL PROCESO...9 LOS CINCO NIVELES DE MADUREZ ARQUITECTURA DEL MODELO OBJETIVOS Y PRÁCTICAS GENÉRICAS...12 OBJETIVOS Y PRÁCTICAS ESPECÍFICAS...13 DISCIPLINAS...13 ÁREAS DE PROCESO DE NIVEL ADMINISTRACIÓN DE REQUERIMIENTOS (REQM)...15 PLANIFICACIÓN DEL PROYECTO (PP)...17 MONITOREO Y CONTROL DEL PROYECTO (PMC)...18 MEDICIÓN Y ANÁLISIS (MA)...19 ASEGURAMIENTO DE LA CALIDAD DE PRODUCTOS Y PROCESOS (PPQA)...19 ADMINISTRACIÓN DE LA CONFIGURACIÓN (CM)...21 ADMINISTRACIÓN DE ACUERDOS CON PROVEEDORES (SAM)...22 ÁREAS DE PROCESO DE NIVEL DESARROLLO DE REQUERIMIENTOS (RD)...24 SOLUCIÓN TÉCNICA (TS)...25 INTEGRACIÓN DEL PRODUCTO (PI)...26 VERIFICACIÓN (VE)...26 VALIDACIÓN (VA)...29 ENFOQUE ORGANIZACIONAL EN EL PROCESO (OPF)...29 DEFINICIÓN ORGANIZACIONAL DEL PROCESO (OPD)...31 ENTRENAMIENTO ORGANIZACIONAL (OT)...32 GESTIÓN DEL RIESGO (RSKM)...33 ANÁLISIS Y TOMA DE DECISIONES (DAR)...34 ADMINISTRACIÓN INTEGRADA DEL PROYECTO (IPM)...35 GESTIÓN INTEGRADA DE PROVEEDORES (SS) (ISM)...36 AMBIENTE ORGANIZACIONAL PARA LA INTEGRACIÓN (IPPD) (OEI)...37 EQUIPO INTEGRADO (IPPD) (IT)...38 ÁREAS DE PROCESO DE NIVEL DESEMPEÑO DEL PROCESO DE LA ORGANIZACIÓN (OPP)...39 ADMINISTRACIÓN CUANTITATIVA DE PROYECTOS (QPM)...40 ÁREAS DE PROCESO DE NIVEL INNOVACIÓN ORGANIZACIONAL Y DESPLIEGUE (OID)...42 ANÁLISIS Y RESOLUCIÓN DE CAUSAS DE DEFECTOS/PROBLEMAS (CAR)...43 DEFINIENDO LOS PROCESOS DE LA ORGANIZACIÓN

3 OTROS ESTÁNDARES Y MODELOS DE REFERENCIA ISO 9001: COBIT...47 ITIL...48 ESCM...49 INTEGRANDO LOS MODELOS...51 CONCLUSIONES GLOSARIO REFERENCIAS

4 Figuras y Tablas Fig. 1: Niveles de Madurez...5 Fig. 2: Áreas de Proceso por Nivel de Madurez...6 Fig. 3: Áreas de Proceso por Categoría...7 Fig. 4: Un ejemplo de gráfico de control...8 Fig. 5: Variación debida a causas comunes...10 Fig. 6: Variación debida a causas especiales...10 Fig. 7: Estructura de la representación por niveles...13 Fig. 8: Técnica de inspección...28 Fig. 9: Un diagrama de Pareto...44 Fig. 10: Un diagrama de causa-efecto o de Ishikawa...45 Fig. 11: Relación entre CMMI e ISO 9001: Fig. 12 Dominios y procesos de CobIT...48 Fig. 13: Procesos de ITIL...49 Fig. 14: Fases y áreas de capacidad de escm...50 Tabla 1: Comparación entre CMMI, ISO 9001, CobIT, ITIL y escm

5 Introducción El Capability Maturity Model Integration (CMMI SMi de aquí en adelante) 1 es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University, CMMI es la nueva generación de una línea de modelos de madurez que se inició a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for Software Engineering) 2, 3, ii Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby, Deming y Juran, estos modelos proponen un conjunto de prácticas que las organizaciones pueden adoptar para implantar procesos productivos más efectivos. Son llamados modelos de madurez porque proponen adoptar dichas prácticas en forma gradual: primero deben ponerse en práctica áreas de proceso pertenecientes a un nivel determinado, para luego, sobre esta base, introducir las correspondientes al nivel siguiente. Niveles de Madurez y Áreas de Proceso Al igual que los restantes modelos de la familia, CMMI plantea que las organizaciones pueden ubicarse en alguno de cinco posibles niveles de madurez, dependiendo del grado de sofisticación de sus procesos (ver Fig. 1) A su vez, cada nivel de madurez -con excepción del inicial- queda caracterizado por un conjunto de áreas de proceso que agrupan prácticas que, al ser ejecutadas colectivamente, permiten cumplir con algún objetivo que es considerado importante para el modelo. i CMMI es servicio registrado de Carnegie Mellon University. ii Otros modelos de madurez son: SA-CMM (Software acquisition), P-CMM (People CMM), SE-CMM (Systems Engineering). 4

6 Fig. 1: Niveles de Madurez Como puede apreciarse en la Fig. 2, antes de introducir prácticas de un nivel determinado deben estabilizarse las prácticas del nivel anterior. Es así que, por ejemplo, antes de introducir el área de proceso RSKM-Administración de Riesgos (perteneciente al nivel 3 ó definido) deben estabilizarse las relacionadas con la gestión del proyecto (PP-Planificación del Proyecto y PMC-Monitoreo y Control del Proyecto, pertenecientes al nivel 2 ó administrado). 5

7 Fig. 2: Áreas de Proceso por Nivel de Madurez iii Además de poder ver las áreas de proceso por nivel de madurez, el modelo propone una vista alternativa (llamada continua) en donde las áreas están agrupadas por categoría (ver Fig. 3) Esta es una diferencia sustancial respecto a los modelos anteriores, que sólo permitían una vista u otra (Por ejemplo, CMM-SW proponía una vista por niveles de madurez, mientras que el CMMI-SE lo hacía por categorías). iii Para facilitar la referencia al modelo, hemos dejado en el gráfico las áreas de proceso con sus iniciales y nombres en inglés. 6

8 Fig. 3: Áreas de Proceso por Categoría Un modelo de referencia no es la descripción de un proceso Llegados a este punto, es importante hacer una aclaración: CMMI, como su nombre lo indica, es un modelo que propone un conjunto de best practices que pueden emplearse para evaluar y mejorar procesos; de ninguna manera debe suponerse que estamos ante la descripción de un proceso. Será nuestro trabajo definir el proceso productivo de nuestra organización que seguramente tendrá una estructura completamente diferente a la de CMMI- de manera tal que cumpla con los atributos y mejores prácticas propuestos por el modelo. Procesos Estadísticamente Controlados Uno de los principios fundamentales de la calidad total sobre los cuales está basado este modelo- es el de control estadístico de procesos. Según él, la variabilidad de un proceso puede ser controlada y, por consiguiente, sus resultados pueden ser 7

9 predecibles 4. Que los resultados de un proceso sean predecibles no quiere decir que sean idénticos, sino que estos variarán dentro de límites conocidos. Veamos un ejemplo tomado de Practical Software Measurement. Un grupo de trabajo es responsable del desarrollo de una nueva versión de una aplicación, mientras que al mismo tiempo debe dar soporte a los usuarios de la vieja versión. El proyecto ha sido planificado bajo el supuesto de que serían necesarias 40 horas-hombre diarias de soporte. Luego de finalizado el proyecto, y con la información de la cantidad real de horas incurridas diariamente en actividades de soporte, se realiza el siguiente grafo de control (ver Fig. 4), en el que podemos observar su evolución a lo largo de las dieciséis semanas del periodo. Fig. 4: Un ejemplo de gráfico de control No es nuestro propósito en adentrarnos en el detalle de cómo construir este tipo de gráficos; por el momento diremos que, luego de realizado el análisis, podemos afirmar que el esfuerzo aplicado a actividades de soporte durante las dieciséis semanas que duró el proyecto estuvo en torno a las horas-hombre por día (la línea punteada identificada en el gráfico como CL=45.03). Mediante un cálculo que forma parte de esta técnica podemos, además, determinar los límites inferior y superior del proceso (LCL=40.66 y UCL=49.41, respectivamente), los que corresponden a +/- 3 desviaciones estándar iv. Para determinar si el proceso se encuentra estadísticamente controlado debemos iv La desviación estándar (sigma) es la dispersión de una distribución normal. Por regla sabemos que el 99.74% de superficie por debajo de la curva normal debería estar dentro de +/- 3 veces sigma. 8

10 verificar si en el gráfico se cumplen o no una serie de reglas. Para ello será necesario identificar tres zonas en el gráfico, llamadas A, B y C. Cada una de las zonas representa, respectivamente, la distancia entre la media y +/- una, dos y tres desviaciones estándar (o sea, deberíamos dividir en tres zonas iguales la distancia entre la media y los límites inferior y superior) Un proceso estará fuera de control si se cumple alguna o varias de las siguientes reglas: Dos de tres puntos consecutivos están en la zona C Cuatro de cinco puntos consecutivos al mismo lado de la línea central en las zonas B y C. Nueve puntos consecutivos están por encima o por debajo del promedio. Hay seis puntos consecutivos crecientes o decrecientes. Hay catorce puntos consecutivos alternándose arriba y abajo del promedio. Hay quince puntos consecutivos dentro de la zona A. De acuerdo a lo que podemos observar, el gráfico de la Fig. 4 no cumple con ninguna de estas reglas, con lo cual estamos en condiciones de afirmar que se encuentra estadísticamente controlado. En otras palabras, la estimación de 40 horas-hombre fue más que aceptable. Estabilidad del proceso Las características de todos los procesos y productos presentan algún tipo de variación cuando las medimos a lo largo del tiempo. Dicha variación puede tener dos fuentes: la misma naturaleza del proceso (la variación normal o natural del proceso, relacionada con la interacción entre sus distintos componentes personal, maquinaria, materiales, métodos y ambiente-) por un lado, y las causas relacionadas con alguna causa específica por el otro (las variaciones especiales). v La variación normal del proceso (llamada causa común de variación) tiene un comportamiento al azar, pero con un patrón estable y dentro de ciertos límites (ver Fig. 5 [reproducida de Practical Software Measurement]) Si un proceso presenta únicamente este tipo de variación estaremos ante un proceso estadísticamente controlado. v Ver la sección Glosario para una definición formal de causas especiales y comunes. 9

11 Fig. 5: Variación debida a causas comunes La variación especial, por el contrario, no tiene un patrón de comportamiento que pueda ser identificado (ver Fig. 6, reproducida de la misma obra) El impacto de este tipo de variaciones en la performance del proceso y en las características del producto son importantísimos, a tal punto que es imposible predecir los resultados. Fig. 6: Variación debida a causas especiales Las variaciones especiales no tienen su origen en el proceso, sino en causas externas tales como el medio ambiente, el material de input al proceso, personal no capacitado, métodos o herramientas incorrectamente usados, etc. Una vez que las variaciones originadas en causas especiales sean removidas, nos encontraremos con un proceso estable (estadísticamente controlado) Una vez alcanzado este estado, podremos optimizar el proceso, reduciendo la variabilidad o corriendo la media. Como veremos en las próximas secciones, las organizaciones de nivel de madurez 5 de CMMI se esfuerzan en remover las causas comunes, mientras que las de nivel 4 se enfocan en remover las especiales. 10

12 Los Cinco Niveles de Madurez En general, los niveles de madurez suelen explicarse en orden creciente; tomaremos aquí una dirección distinta y los explicaremos exactamente al revés: desde el nivel cinco al nivel uno. Imaginémonos por un momento que estamos en una organización de nivel cinco. En este tipo de organizaciones, como dijimos en la sección anterior, los procesos son analizados para eliminar las causas comunes de variación, o sea, aquellas que tienen que ver con la misma naturaleza del proceso, no atribuibles a causas externas. Las variaciones en las salidas de los procesos son al azar, pero se encuentran controladas estadísticamente (podemos predecir los resultados de los procesos con cierto nivel de confiabilidad) Para poder haber arribado a este nivel, la organización debería primero haber eliminado las causas especiales de variación, aquellas que tienen que ver con causas externas, como por ejemplo falta de entrenamiento del personal, problemas con las herramientas, etc. Este tipo de causas no son aleatorias: Si examináramos los resultados podríamos ver las tendencias que claramente nos indicarían que las variaciones tienen un origen concreto. En una organización de nivel cuatro, entonces, las causas especiales de variación son identificadas y eliminadas. Para poder llegar a identificar causas de variación necesitamos tener un proceso estándar: difícil sería poner bajo control estadístico un proceso que no se encuentre mínimamente formalizado. Así llegamos al nivel tres, en el cual los proyectos emplean un proceso productivo adaptado del proceso estándar de la organización. Las actividades técnicas y de gestión son realizadas de acuerdo a políticas, procesos y procedimientos formalizados en algún tipo de estándar organizacional profundamente arraigado en la cultura. La gente está entrenada y dispone de recursos para poder hacer su trabajo. También hay una infraestructura básica (personal, herramientas, etc.) para definir y mejorar el proceso productivo. Pero para poder arribar a semejante situación es necesario pasar por una etapa previa: difícilmente podamos introducir en una organización prácticas estándar relacionadas con la ingeniería del producto (análisis, diseño, etc.) si no ofrecemos un contexto en donde ellas puedan ser correctamente ejecutadas. Ese es el foco del nivel dos: poner en orden las prácticas relacionadas con el manejo elemental de los proyectos. En el nivel dos, los proyectos de la organización siguen algún tipo de proceso para realizar las actividades relacionadas con la gestión del proyecto (planificación, control), para administrar los requerimientos y las configuraciones, y para medir y analizar la calidad de los productos y el desempeño de los procesos. También hay prácticas de aseguramiento de la calidad que permiten garantizar que cada proyecto sigue sus propios estándares. 11

13 En el nivel dos no importan tanto las técnicas y los métodos que empleemos para desarrollar y construir nuestros productos y servicios: Lo importante es que podamos tener un mínimo de capacidad de gestión de proyectos. Y así llegamos al nivel uno: La situación aquí es caótica. No tenemos procesos (no al menos en el sentido del modelo) y la performance de los proyectos depende profundamente de la buena voluntad y la capacidad de la gente. Arquitectura del Modelo En la representación por niveles (ver Fig. 7), cada nivel de madurez contiene varias áreas de proceso, las que a su vez quedan definidas por uno o varios objetivos específicos y un objetivo genérico. Cada uno de ellos tiene vinculado un conjunto de prácticas, llamadas específicas y genéricas respectivamente. Objetivos y Prácticas Genéricas Los objetivos y prácticas genéricas tienen que ver con el grado de institucionalización de los procesos (compromiso con la ejecución, capacidad para ejecutar, dirección de la ejecución, verificación de la ejecución) Son llamados así porque son los mismos en todas las áreas de proceso (aunque hay aspectos específicos para cada una de ellas). Cumplir con un objetivo genérico de un área de proceso determinada implica tener un mayor control de la planificación e implementación de los procesos vinculados a esa área de proceso. En el nivel 2, el objetivo (GG) y las prácticas genéricas (GP) son los siguientes: GG 2 Institucionalizar un proceso administrado > GP 2.1 Establecer políticas organizacionales > GP 2.2 Planificar el proceso > GP 2.3 Proveer Recursos > GP 2.4 Asignar responsabilidades > GP 2.5 Entrenar al personal > GP 2.6 Administrar la configuración > GP 2.7 Identificar e involucrar a los interesados > GP 2.8 Monitorear y controlar los procesos > GP 2.9 Evaluar adhesión objetivamente > GP 2.10 Revisar el estado con la alta gerencia En los niveles 3, 4 y 5, a los anteriores se agregan los siguientes: GG 3 Institucionalizar un proceso definido > GP 3.1 Establecer un proceso definido > GP 3.2 Recolectar información para mejoras 12

14 Fig. 7: Estructura de la representación por niveles Objetivos y prácticas específicas Los objetivos y prácticas específicas están vinculados a un área de proceso determinada. Son considerados elementos que deben ser satisfechos para implementar exitosamente los procesos relacionados con un área de proceso en particular. Por ejemplo, en el área Administración de Requerimientos (REQM), los objetivos y prácticas son las siguientes: Objetivo Específico SG 1 Administrar Requerimientos Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto. Prácticas Específicas SP 1.1 Comprender el significado de los requerimientos SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos SP 1.3 Administrar cambios a los requerimientos SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto Disciplinas El modelo incluye cuatro cuerpos de conocimiento distintos: ingeniería de software, ingeniería de sistemas, desarrollo integrado de productos y procesos, y adquisición de 13

15 productos. Si bien el modelo es esencialmente el mismo para las cuatro disciplinas, en algunas de ellas se agregan áreas de proceso o prácticas puntuales. También pueden aparecer comentarios particulares que clarifican su aplicación en el contexto de alguna de las cuatro disciplinas (amplificaciones) Las disciplinas de ingeniería de software e ingeniería de sistemas (SW y SE son sus siglas en inglés) no merecen mayor aclaración (en cierta manera, cubren el alcance del SW-CMM y de SE-CMM, respectivamente); la recomendación que da el modelo es que se use la segunda, ya que toda pieza de software forma parte de un sistema mayor. Adquisición de productos (SS, por supplier sourcing) es un cuerpo de conocimiento que debe ser aplicado siempre que el proyecto dependa de actividades críticas que deban realizar proveedores. El modelo agrega un área específica para esta disciplina, Gestión Integrada de Proveedores (ISM). Por último, desarrollo integrado de productos y procesos (IPPD, por su denominación en inglés) es una disciplina aplicable en aquellas situaciones en donde sea necesario desarrollar, en forma concurrente, no sólo el producto sino también los procesos a emplear para diseñarlo, construirlo y mantenerlo (incluyendo el soporte a los usuarios). Se agregan dos áreas de proceso específicas, Equipo Integrado (IT) y Ambiente Organizacional para la Integración (OEI). IPPD debe ser usada junto a alguna de las otras disciplinas disponibles. vi vi Para mayor información respecto a IPPD puede consultarse 14

16 Áreas de Proceso de Nivel 2 En una organización que haya alcanzado este nivel de madurez encontraremos que hay una disciplina para la gestión de proyectos que se mantiene aún en periodos de estrés. Los recursos estarán capacitados para hacer su trabajo, y habrá políticas organizacionales formalmente establecidas, cuyo cumplimiento será monitoreado. Habrá visibilidad de las actividades realizadas, y los proyectos se ejecutarán siguiendo un plan y de acuerdo a un proceso formalmente establecido. Si bien el establecimiento de estándares organizacionales recién es contemplado en el siguiente nivel, aquí nos encontraremos con procesos definidos en el contexto de cada proyecto. Por supuesto que pueden definirse procesos más o menos generales (que puedan ser usados por más de un proyecto), pero el modelo no lo prescribe por la sencilla razón de que primero es necesario poner orden dentro de cada proyecto para luego ordenar el resto de la organización (el foco de nivel 3). Las áreas de proceso del nivel 2 son siete en total, las cuales describimos rápidamente en las próximas secciones. Administración de Requerimientos (REQM) Esta área de proceso tiene como propósito mantener bajo control los requerimientos que el producto a desarrollar deberá satisfacer. Las prácticas incluidas aquí apuntan a que los requerimientos no solo estén claramente identificados, sino también que todos los involucrados en el proyecto (el cliente, el equipo de proyecto, etc.) estén de acuerdo en su significado. Adicionalmente, los requerimientos deben ser la entrada a las actividades de planificación (ver Planificación del Proyecto (PP)) y a las técnicas incluidas en nivel 3. Un tema fundamental planteado en esta área de proceso es que cualquier cambio realizado a los requerimientos se efectúe de manera controlada (por ejemplo, solamente un grupo reducido de personas debería proponer cambios) y que el resto de los artefactos del proyecto (planes, especificaciones, diseño, etc.) se mantengan consistentes. Otro aspecto importante incluido en esta área es el de trazabilidad bidireccional. Cuando los requerimientos son correctamente administrados deberíamos estar en condiciones de relacionar cuál ha sido el origen de los requerimientos, cuál es la relación entre los requerimientos de bajo nivel y los de alto nivel (por ejemplo, cuáles son derivados y de cuál requerimiento), cuáles son los artefactos relacionados con los requerimientos (por ejemplo, especificaciones, documentos de diseño o planes), y cuáles componentes del producto implementan cada requerimiento. Esta práctica es sumamente importante para poder realizar un buen análisis de impacto ante posibles cambios, y fundamental para poder determinar si el alcance del proyecto ha sido cubierto o no ( han sido satisfechos todos los requerimientos?). En esta área hay solamente un objetivo específico SG 1 Administrar Requerimientos-y 15

17 cinco prácticas: Objetivo Específico SG 1 Administrar Requerimientos Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto. Prácticas Específicas SP 1.1 Comprender el significado de los requerimientos SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos SP 1.3 Administrar cambios a los requerimientos SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto Desde el punto de vista práctico, el área de proceso se satisface poniendo en marcha algún tipo de mecanismo o sistema que: Identifique quienes son las fuentes oficiales de requerimientos; Identifique cuáles son los canales válidos para ingresar requerimientos al proyecto; Controle los cambios (no cualquiera estaría en condiciones de generar un cambio a un requerimiento); Permita determinar si todos los involucrados tienen la misma visión respecto al significado de los requerimientos (por ejemplo, mediante la aprobación de algún tipo de documento formal); Mantenga la trazabilidad entre los requerimientos y otros artefactos (incluyendo al producto y sus componentes) Si bien a esta altura no es necesario definir ninguna técnica de especificación en particular (tema atacado recién en el nivel 3), lo más usual es que se avance en esa dirección para poder tener efectivamente requerimientos para administrar. Vale aclarar que para este modelo, los requerimientos se clasifican en tres categorías: los del usuario (aquellos que formula el usuario y que, por ejemplo, pueden ser documentados en una minuta de reunión), los del producto (derivados a partir de los primeros; generalmente descriptos en un lenguaje más cercano al equipo de proyecto), y los de las componentes del producto (derivados de los anteriores) En algunas organizaciones los usuarios suelen volcar sus necesidades en algún tipo de herramienta (por ejemplo, en un workflow), las que posteriormente serán elaboradas por el equipo de proyecto y formalizadas en algún tipo de documento con un nivel de detalle suficiente para poder conducir las actividades técnicas y de gestión (por ejemplo, una Visión o un Acuerdo de Proyecto) 16

18 Planificación del Proyecto (PP) Esta área de proceso tiene como propósito establecer y mantener el plan que será empleado para ejecutar y monitorear el proyecto. El plan se desarrolla sobre la base de los requerimientos administrados por el área REQM (ver sección anterior) Dentro de esta área de proceso se incluyen todas las actividades necesarias para determinar el alcance del proyecto (funcionalidad a desarrollar, actividades incluidas y excluidas, etc.), estimar esfuerzo y costos, establecer el cronograma, identificar riesgos, y obtener el compromiso de todos los involucrados respecto al plan de proyecto. Sus objetivos y prácticas específicas son las siguientes: Objetivos Específicos SG 1 Establecer estimaciones Se realizan y mantienen estimaciones de las magnitudes del proyecto. SG 2 Desarrollar el plan de proyecto Se establece y mantiene un plan de proyecto que es empleado para administrar el proyecto. SG 3 Obtener el compromiso de los interesados acerca del plan de proyecto Los compromisos con el plan están formalmente establecidos y son mantenidos a lo largo del proyecto. Prácticas Específicas SP 1.1 Estimar el alcance del proyecto SP 1.2 Estimar atributos de las tareas y de los productos del proyecto SP 1.3 Definir el ciclo de vida del proyecto SP 1.4 Estimar esfuerzo y costo del proyecto SP 2.1 Establecer el cronograma y el presupuesto del proyecto SP 2.2 Identificar los riesgos del proyecto SP 2.3 Planificar la administración de datos del proyecto SP 2.4 Planificar recursos necesarios para el proyecto SP 2.5 Planificar la adquisición de conocimiento y habilidades SP 2.6 Planificar la participación de los interesados en el proyecto SP 2.7 Establecer el plan del proyecto SP 3.1 Revisar todos los planes que puedan afectar al proyecto SP 3.2 Ajustar el plan de proyecto para reflejar recursos estimados vs. disponibles SP 3.3 Obtener compromisos respecto al plan Las actividades de esta área suelen implementarse mediante la combinación de varios elementos. Por un lado, será necesario establecer algún tipo de mecanismo de estimación que emplee como input los requerimientos del proyecto. También será necesario formalizar el plan de proyecto (que no es solamente el cronograma), el ciclo de vida a emplear (por lo menos, fases e hitos), y los mecanismos de aprobación. Si bien no está explícitamente indicado en el modelo, el establecimiento de una función tipo PMO (Project Management Office) podría actuar como facilitador de la implementación de esta área de proceso y de la siguiente (Monitoreo y Control del 17

19 Proyecto (PMC)) Monitoreo y Control del Proyecto (PMC) No tiene sentido formular planes para algo que no se tiene intenciones de gestionar. Esta área de proceso es complementaria y una consecuencia- de Planificación del Proyecto (PP): su propósito es monitorear la ejecución del proyecto empleando para ello el plan- y gestionar acciones correctivas en el caso de detectarse desvíos. Objetivos Específicos SG 1 Monitorear el Proyecto El avance y la performance del proyecto se monitorean respecto a lo establecido en el plan de proyecto. Prácticas Específicas SP 1.1 Monitorear los parámetros de planificación del proyecto SP 1.2 Monitorear los compromisos SP 1.3 Monitorear los riesgos del proyecto SP 1.4 Monitorear la administración de datos del proyecto SP 1.5 Monitorear la participación de los interesados SP 1.6 Conducir revisiones de avance SP 1.7 Conducir revisiones de cumplimiento de hitos SG 2 Gestionar Acciones Correctivas Cuando los resultados o la performance del proyecto se desvian significativamente del plan se gestionan acciones correctivas. SP 2.1 SP 2.2 SP 2.3 Analizar temas pendientes Ejecutar acciones correctivas Administrar acciones correctivas Para poder cumplir con estos objetivos será necesario implementar prácticas de seguimiento, tales como el reporte de horas trabajadas en el proyecto, el informe de avance periódico, revisiones en puntos particulares del proyecto (por ejemplo, al final de cada fase), etc. Si bien esto suena sencillo, conseguir cambiar la cultura (que en general favorece la no-visibilidad de los proyectos) es una tarea durísima. La PMO (Project Management Office) también puede jugar un papel importante aquí, realizando el seguimiento a alto nivel- de los proyectos en ejecución, y generando los indicadores correspondientes (ver Medición y Análisis (MA)). Por supuesto que, al igual que el área de proceso anterior, es imprescindible identificar personas dentro de la organización que puedan cubrir el rol de líder o gerente de proyecto. Esto puede sonar redundante, pero es bastante habitual encontrar organizaciones que ni siquiera reconocen la existencia del rol. 18

20 Medición y Análisis (MA) Una premisa presente en todos los movimientos de calidad es que lo que no puede medirse no puede mejorarse. Esta área de proceso apunta, justamente, a desarrollar y mantener capacidades de medición que permitan satisfacer las necesidades de información de la organización. Sus objetivos y prácticas son las siguientes: Objetivos Específicos SG 1 Alinear actividades de medición y análisis Las actividades de medición y análisis están alineadas con los objetivos y necesidades de información. Prácticas Específicas SP 1.1 Establecer objetivos de las mediciones SP 1.2 Especificar métricas SP 1.3 Especificar procedimientos de recolección y almacenamiento de datos SP 1.4 Especificar procedimientos de análisis SG 2 Proveer los resultados de la medición Se proveen mediciones que satisfacen necesidades y objetivos de información. SP 2.1 SP 2.2 SP 2.3 SP 2.4 Recolectar datos Analizar datos Almacenar datos y resultados Comunicar resultados Estos objetivos pueden satisfacerse básicamente mediante la puesta en marcha de un programa de métricas que defina: Objetivos de la organización (por ejemplo, aumentar la productividad un X% o disminuir los defectos en producción un Z%); Métricas que permitan determinar si se cumplen o no con los objetivos (por ejemplo, productividad, densidad de defectos, etc.); Mecanismos de obtención de las métricas (procedimientos manuales, aplicaciones, orígenes de datos) Usualmente, los indicadores pueden agruparse en dos: por un lado, los empleados para monitorear cada proyecto (valor ganado, densidad de defectos, etc.), y por el otro los más generales (porcentaje de proyectos finalizados en fecha, desvío promedio, etc.) Un enfoque muy interesante que puede emplearse para implementar los indicadores del segundo grupo es el balanced scorecard propuesto por Kaplan y Norton. 5 Aseguramiento de la Calidad de Productos y Procesos (PPQA) Una vez establecidos procesos y estándares será necesario evaluar su aplicación. El objetivo de esta área es justamente ese: proveer una evaluación objetiva de los procesos y de los artefactos producidos. Es importante aclarar que las prácticas de esta área implican: 19

21 Evaluar los procesos ejecutados, los artefactos producidos y los servicios provistos versus los estándares y descripciones de proceso aplicables; Identificar no conformidades, comunicarlas a los responsables, y asegurar su resolución; Informar a los interesados (básicamente, el equipo de proyecto y la gerencia) el resultado de las actividades de aseguramiento de la calidad. De ninguna manera debe confundirse esta área con la de Verificación (VE) incluida en el nivel 3, cuyo propósito es garantizar que se satisfagan los requerimientos. El foco aquí está puesto en garantizar que se apliquen los estándares y que los procesos se ejecuten de acuerdo a lo previsto (ver el Glosario para una definición de control y aseguramiento de la calidad). Un tema importante es el de la objetividad. Debe garantizarse un nivel apropiado de independencia entre los productores y los evaluadores (aquellos que ejecuten actividades de aseguramiento de la calidad). Un canal de reporte con la gerencia también es importante para comunicar las no conformidades y garantizar que se resuelvan. Los objetivos y prácticas específicas del área son lo siguientes: Objetivos Específicos Prácticas Específicas SG 1 Evaluar objetivamente procesos y artefactos vii Se evalúa objetivamente la adhesión de los procesos y artefactos a los estándares y descripciones de proceso vigentes. SP 1.1 SP 1.2 Evaluar procesos objetivamente Evaluar productos y servicios objetivamente SG 2 Proveer realimentación objetivamente El no cumplimiento de los estándares y descripciones de proceso es objetivamente comunicado y su resolución asegurada. SP 2.1 Comunicar y asegurar la resolución de cuestiones de calidad SP 2.2 Establecer y mantener registros de las actividades de aseguramiento de la calidad Estas prácticas suelen implementarse mediante la creación de un rol (no necesariamente full-time) encargado de estas actividades, y, por supuesto, de los procesos y estándares correspondientes. Algunas actividades de aseguramiento de la calidad podrán estar embebidas en el proceso de producción (por ejemplo, como una actividad en el plan de proyecto), mientras que otras podrán ejecutarse independientemente y tener su propio plan (más en el estilo de una auditoría). vii Hemos adoptado el término artefacto para traducir lo que en el original figura como workproduct. Un artefacto es todo aquello producido por un proceso (el producto final, los productos intermedios). 20

22 Es sumamente importante que el nivel de management adecuado reciba los informes de no-conformidad y facilite su regularización. Por supuesto que su postura no debe ser coercitiva. Administración de la Configuración (CM) Esta área de proceso tiene como propósito mantener la integridad de todos los artefactos (entregables o no ) producidos por el proyecto, lo cual implica identificar los ítems de configuración, realizar sobre ellos cambios de manera controlada, generar y mantener líneas base, y proveer información precisa acera del estado del estado de la configuración a todos los interesados. Los objetivos y prácticas incluidas son los siguientes: Objetivos Específicos SG 1 Establecer líneas base Se establecen líneas base de los artefactos puestos bajo administración de la configuración. Prácticas Específicas SP 1.1 Identificar ítems de configuración SP 1.2 Establecer un sistema de administración de la configuración SP 1.3 Crear o liberar líneas base SG 2 Monitorear y controlar cambios Los cambios a los artefactos son monitoreados y controlados. SP 2.1 SP 2.2 Monitorear pedidos de cambio Controlar ítems de configuración Esta área de proceso es, probablemente, una de las más difíciles de implementar de todas las incluidas en este nivel. Además de tener problemas para planificar y ejecutar sus actividades de acuerdo a esos planes, las organizaciones de nivel 1 suelen tener serias complicaciones para identificar y mantener las versiones correctas de sus productos y artefactos asociados. Es bastante común encontrarse con organizaciones que tienen múltiples versiones activas de una misma aplicación, sin poder llegar a controlarlas del todo e invirtiendo ingentes recursos en arreglar los mismos problemas una y otra vez. Estas prácticas apuntan, justamente, a resolver este tipo de problemas. Cómo se implementan? En general, será necesario contar con algún tipo de sistema (preferiblemente, total o parcialmente automatizado) que permita realizar las actividades típicas de administración de la configuración: Identificar ítems de configuración y mantener sus relaciones con otros ítems; Crear, extraer (checkout) e ingresar (checkin) ítems de configuración del/al sistema de administración de la configuración; Generar líneas base en determinados hitos del proyecto; 21

23 Auditar ítems, líneas base y el sistema de administración de la configuración; Elevar, analizar y aprobar pedidos de cambio. La introducción de una herramienta de este tipo tendrá un impacto importantísimo en el trabajo diario de todos los miembros del proyecto (o de la organización, dependiendo de su alcance), sobre todo en la de los desarrolladores. Administración de Acuerdos con Proveedores (SAM) Esta área de proceso apunta a resolver otro de los problemas habituales en muchas organizaciones: el de la tercerización. Si bien está originalmente pensada para todo lo relacionado con la adquisición de productos que vayan a ser incorporados en la solución a entregar al cliente, las prácticas incluidas aquí también sirven para todo aquello que sea necesario comprar pero que no será finalmente entregado al cliente, como por ejemplo herramientas de desarrollo. Los objetivos y prácticas del área son las que se indican en el siguiente cuadro: Objetivos Específicos Prácticas Específicas SG 1 Establecer acuerdos con proveedores Se establecen y mantienen acuerdos con proveedores. SG 2 Satisfacer acuerdos con proveedores Los acuerdos con los proveedores son satisfechos por el proyecto y por los proveedores. SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 SP 2.3 SP 2.4 Determinar tipo de adquisición Seleccionar proveedores Establecer acuerdos con proveedores Revisar productos adquiridos Ejecutar acuerdos con proveedores Aceptar el producto adquirido Transicionar productos Para poner en práctica esta área de proceso será necesario definir los mecanismos mediante los cuales: Se seleccionarán los potenciales proveedores (por ejemplo, mediante un proceso que implique le creación de RFIs y RFPs); Se elegirán los proveedores que suministrarán al proyecto los productos/servicios necesarios; viii Se formalizarán los acuerdos con los proveedores (por ejemplo, mediante un contrato o mediante un acuerdo de nivel de servicio); viii En el nivel 3 existe un área de proceso llamada Análisis y Toma de Decisiones (DAR) que propone un enfoque formal para la toma de decisiones, el cual podría ser empleado para seleccionar proveedores seguramente, una vez arribados a dicho nivel-. 22

24 Se formalizará la entrega de los requerimientos al proveedor; Se formalizará la recepción del producto/servicio solicitado al proveedor, y los correspondientes criterios de aceptación. Es importante aclarar que: Los proveedores de los que habla el área de proceso no necesariamente pertenecen a otra empresa u organización; todo grupo que deba suministrar productos y servicios al proyecto (inclusive, otros proyectos) puede ser considerado un proveedor. Será necesario, entonces, formalizar con ellos el acuerdo. Si la solución a entregar al cliente necesitará de algún tipo de producto COTS ix (por ejemplo, un motor de base de datos o algún tipo de componente puntual), también será necesario formalizar el acuerdo con el proveedor correspondiente. ix Ver el Glosario. 23

25 Áreas de Proceso de Nivel 3 Para alcanzar este nivel de madurez deben ser formalizadas las actividades de ingeniería del producto (diseño, desarrollo, verificación, etc.) y ser adoptadas prácticas de gestión de proyectos más avanzadas (por ejemplo, gestión de riesgos) También deben definirse procesos, procedimientos y estándares más detallados que, a diferencia del nivel anterior, tendrán alcance organizacional-. Adicionalmente, tienen que ser establecidas las estructuras y los mecanismos necesarios para instrumentar la mejora continua de procesos (por ejemplo, el SEPG, los TWGs, etc.) x En este nivel de madurez hay un total de catorce áreas de proceso, dos de ellas específicas para IPPD y una puntualmente necesaria para SS. Desarrollo de Requerimientos (RD) En el nivel anterior nuestra preocupación pasaba más por administrar los requerimientos que por tener una manera estándar para identificarlos y especificarlos. Justamente es esta área de proceso la encargada de producir y analizar los requerimientos del cliente, del producto, y de las componentes del producto. El área incluye tres objetivos específicos y diez prácticas específicas: Objetivos Específicos Prácticas Específicas SG1 Desarrollar Requerimientos del Cliente Se relevan las necesidades, expectativas, restricciones e interfaces y se traducen en requerimientos del cliente. SP 1.1 SP 1.2 Relevar Necesidades Desarrollar los Requerimientos del Cliente SG2 Desarrollar los Requerimientos del Producto Los requerimientos del cliente son refinados y elaborados para obtener los requerimientos del producto y sus componentes. SP 2.1 Establecer Requerimientos del Producto y sus Componentes SP 2.2 Asignar Requerimientos a las Componentes del Producto SP 2.3 Identificar Requerimientos de Interfaz SG3 Analizar y Validar Requerimientos Los requerimientos son analizados y validados, y se desarrolla una definición de la funcionalidad requerida. SP 3.1 Desarrollar Concepto de Operación y Escenarios SP 3.2 Desarrollar una Definición de la Funcionalidad Requerida SP 3.3 Analizar Requerimientos SP 3.4 Analizar Requerimientos para Balancear Necesidades y Restricciones SP 3.5 Validar Requerimientos x Estos dos últimos puntos la definición más detallada de procesos y el establecimiento de la mejora continua- están soportados por el objetivo GG3 y las prácticas genéricas GP 3.1 y 3.2, correspondientes a este nivel. 24

26 Esta área suele implementarse mediante la adopción de técnicas de relevamiento y análisis de requerimientos, como por ejemplo prototipado, escenarios de operación, casos de uso, etc. Más allá de las técnicas elegidas es importante que se formalice: Cómo se obtendrán los requerimientos del usuario; Cómo se refinarán dichos requerimientos hasta obtener los del producto y los correspondientes a sus componentes; Cómo se especificarán, analizarán y validarán los requerimientos. Solución Técnica (TS) En el nivel 2 no importaba tanto formalizar el diseño y la construcción del producto; una vez que la organización ha arribado a este nivel necesitaremos hacerlo. Esta área de proceso incluye todas las actividades necesarias para: Identificar y seleccionar una solución a los requerimientos; Desarrollar el diseño del producto; Implementar el diseño y obtener el producto. Los objetivos y prácticas del área son las siguientes: Objetivos Específicos Prácticas Específicas SG1 Seleccionar Soluciones Soluciones para el producto o para sus componentes son seleccionadas. SG2 Desarrollar el Diseño Se diseñan el producto y sus componentes. SG3 Implementar el Diseño del Producto Las componentes del producto y la documentación de soporte son desarrolladas a partir del diseño. SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 SP 2.3 SP 2.4 SP 3.1 SP 3.2 Desarrollar Soluciones Alternativas y Criterios de Selección Evolucionar Conceptos Operacionales y Escenarios Seleccionar Soluciones Diseñar el Producto y las Componentes Desarrollar un Paquete Técnico de Datos Diseñar Interfaces Realizar Análisis de Construir, Reusar o Comprar Implementar el Diseño Desarrollar la Documentación de Soporte La implementación de las actividades aquí descriptas es bastante compleja. En parte, los objetivos específicos quedarían satisfechos de poner en práctica alguna técnica o método de diseño y programación particular (diseño orientado a objetos, patrones de diseño, etc.) que permitan obtener el producto deseado a partir de los requerimientos y respetando el plan de proyecto. Hay que ser muy cuidadoso para no formalizar la 25

27 práctica más allá de lo recomendable. También será necesario formalizar la evaluación de las posibles alternativas de solución a los requerimientos (ver Análisis y Toma de Decisiones (DAR) para un enfoque formal de toma de decisiones) Integración del Producto (PI) El propósito de esta área de proceso es ensamblar el producto a partir de sus componentes, garantizando que su funcionamiento sea el previsto. Tiene tres objetivos y ocho prácticas específicas: Objetivos Específicos Prácticas Específicas SG1 Preparar la Integración del Producto Se prepara la integración del producto a partir de sus componentes. SG2 Garantizar la Compatibilidad de las Interfaces Las interfaces internas y externas son compatibles. SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 Determinar la Secuencia de Integración Establecer el Ambiente de Integración Establecer Procedimientos y Criterios de Integración Revisar las Descripciones de las Interfaces Administrar Interfaces SG3 Ensamblar las Componentes y Liberar el Producto Las componentes verificadas son ensambladas y el producto integrado, verificado y validado es entregado. SP 3.1 Confirmar Aptitud de Componentes para la Integración SP 3.2 Ensamblar las Componentes del Producto SP 3.3 Evaluar los Componentes Ensamblados SP 3.4 Empaquetar y Entregar el Producto o Componente Esta área se puede implementar mediante la definición de procedimientos para mantener bajo control las interfaces internas y externas (probablemente, uno de los problemas más habituales en el desarrollo de software) y para integrar periódicamente el producto (las prácticas de daily build y smoke test propuestas por Microsoft son un ejemplo típico de integración progresiva). Quizás el aspecto más complicado de poner en marcha sea el de disponer de un ambiente de integración estable; sin embargo, de contar con un buen sistema de administración de la configuración que permita identificar distintos ambientes (desarrollo, integración, prueba, etc.), la implementación se facilita notablemente. Verificación (VE) Esta área de proceso tiene como objetivo garantizar que los artefactos seleccionados cumplan con los requerimientos asignados. Similar en ciertos aspectos a Validación (VA) esta área de proceso apunta a evaluar si el producto final y los productos intermedios del proyecto cumplen con los requerimientos del cliente, del producto, y 26

28 de las componentes del producto. Sus objetivos y prácticas son las siguientes: Objetivos Específicos Prácticas Específicas SG1 Preparar la Verificación Se prepara la verificación de los artefactos. SG2 Realizar Revisiones de Pares Se realizan revisiones de pares sobre artefactos seleccionados. SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 SP 2.3 Seleccionar Artefactos para su Verificación Establecer el Ambiente de Verificación Establecer Procedimientos y Criterios de Verificación Preparar la Revisión de Pares Conducir la Revisión de Pares Analizar Datos de la Revisión de Pares SG3 Verificar Artefactos Seleccionados Artefactos seleccionados son verificados versus los requerimientos especificados. SP 3.1 Realizar la Verificación SP 3.2 Analizar los resultados de la Verificación e Identificar Acciones Correctivas Las técnicas empleadas para realizar la verificación pueden ser similares a las utilizadas en la validación (inspecciones, revisiones, pruebas, etc.); sin embargo, el propósito de esta área es determinar si estamos construyendo el producto correctamente. La verificación siempre es progresiva: a lo largo del ciclo de vida del proyecto tendremos varios momentos en los cuales revisaremos los resultados de las actividades con el propósito de comprobar si cumplen o no con los requerimientos que les han sido asignados (por ejemplo, si la salida de la actividad de diseño cumple con los requerimientos asignados a dicha actividad). De esta manera se detectan problemas tempranamente y se evita que lleguen al producto final. Uno de los mecanismos para realizar verificaciones que propone el modelo es el de revisión de pares. En este tipo de revisiones, pares del productor o autor de un artefacto lo revisan con el propósito de identificar defectos o cambios. Una técnica de revisión de pares muy popular es la de inspecciones (ver Fig. 8). 27

29 Fig. 8: Técnica de inspección Para implementar esta área de proceso es necesario identificar puntos clave en donde realizar las revisiones, y las técnicas correspondientes para hacerlo. También será necesario disponer de un ambiente para realizar la verificación (esto se ve muy claro cuando la verificación involucre algún tipo de testing). Aquí van algunos ejemplos: Al final de la primer fase del proyecto, en donde se define el alcance y se establece el plan, inspeccionar los artefactos relacionados con la funcionalidad a desarrollar (acuerdo de proyecto, visión, especificación de requerimientos, etc.); Revisar el modelo de datos y la especificación de diseño al final de las actividades de diseño; Inspeccionar el código fuente de componentes de software clave; Realizar pruebas de software durante la construcción; Inspeccionar manuales de usuario y material de entrenamiento; Etc. 28

30 Validación (VA) A diferencia del área de proceso anterior, ésta está enfocada en demostrar si el producto (o sus componentes) satisface las necesidades de uso en el ambiente deseado. Así como Verificación se focaliza en determinar si lo construimos bien, Validación se ocupa de evaluar si construimos el producto correcto. Los objetivos y prácticas específicas del área son los siguientes: Objetivos Específicos Prácticas Específicas SG1 Preparar la Validación Se realiza la preparación de la validación. SG2 Validar el Producto o sus Componentes El producto o sus componentes son validados para garantizar que ellos son adecuados para ser usados en el ambiente operativo deseado. SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 Seleccionar Productos para Validación Establecer el Ambiente de Validación Establecer Procedimientos y Criterios de Validación Realizar la Validación Analizar los Resultados de la Validación Verificación y validación suelen ocurrir simultáneamente y usar el mismo ambiente. A menudo, los usuarios están involucrados. Esta área de proceso se implementa mediante la inclusión de actividades de validación en lugares clave del proceso productivo. Las técnicas y métodos a emplear podrán ser similares a los utilizados en las actividades de verificación (pruebas, revisiones, inspecciones, etc.). Son varios los aspectos importantes que deben ser contemplados antes y durante la validación: Ambientes para realizar la validación (por ejemplo, procesadores, redes, datos, infraestructura, etc.); Herramientas para realizar la validación; Personal capacitado. Enfoque Organizacional en el Proceso (OPF) Una organización de nivel 3 debe tener un enfoque formal y disciplinado para continuamente mejorar sus procesos. Esta área junto a Definición Organizacional del Proceso (OPD) y Entrenamiento Organizacional (OT)- contribuye a alcanzar dicho 29

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

CMMI : mejora del proceso en Fábricas de Software

CMMI : mejora del proceso en Fábricas de Software CMMI : mejora del proceso en Fábricas de Software Cecilia Rigoni Brualla Caelum, Information & Quality Technologies Introducción Introducción Idea / Necesidad Investigación Diseño Inversión PRODUCTO Introducción

Más detalles

Capability Maturity Model Integration CMMI - Overview I

Capability Maturity Model Integration CMMI - Overview I Capability Maturity Model Integration CMMI - Overview I CAPIS Centro de Ingeniería del Software e Ingeniería del Conocimiento Junio 2004 Objetivo de la presentación Brindar una visión general del CMMI

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Capítulo 3. Áreas de Proceso

Capítulo 3. Áreas de Proceso Capítulo 3. Áreas de Proceso Tal como lo vimos en el capitulo anterior, las áreas de proceso son un grupo de prácticas que se realizan colectivamente con el fin de alcanzar determinadas metas. Existen

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad Robin Alberto Castro Gil rcastro@icesi.edu.co Geovany Trejos Salas gtrejos@icesi.edu.co Monitoreo y control de proyectos

Más detalles

Gestión de proyectos siguiendo practicas del PMI.

Gestión de proyectos siguiendo practicas del PMI. Gestión de proyectos siguiendo practicas del PMI. Identificación de las mejores prácticas aplicadas a la gestión de proyectos. Proceso de Desarrollo de Software de Codes S.A. alineado a CMMI Nivel 3 en

Más detalles

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

SW-CMM (CMM for Software)

SW-CMM (CMM for Software) Sinopsis de los modelos SW-CMM y CMMI Juan Palacio 1.0 Abril - 2006 Síntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software. CMMI (y previamente CMM) puede emplearse

Más detalles

Uso de la representación continua de CMMI para la Mejora de Negocio

Uso de la representación continua de CMMI para la Mejora de Negocio Uso de la representación continua de CMMI para la Mejora de Negocio III Semana del CMMI Casimiro Hernández Parro 1 de Marzo 2007 Capability Maturity Model and CMMI are registered in the U.S. Patent and

Más detalles

Programa de Desarrollo Profesional en Mejora del Proceso de Software

Programa de Desarrollo Profesional en Mejora del Proceso de Software Programa de Desarrollo Profesional en Mejora del Proceso de Software - Inicio: 3 de Mayo - El Programa de Desarrollo Profesional (PDP) propone soluciones concretas a los problemas de definición de procesos,

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El CMMI El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo.

Más detalles

SW-CMM Capability Maturity Model for Software

SW-CMM Capability Maturity Model for Software SW-CMM Capability Maturity Model for Software Introducción 1986 Comienzan Estudios. SEI (Software Engineering Institute - UCM). 1991 Nace CMM v1.0 1994 CMM v1.1 P-CMM SE-CMM SW-CMM CMMs IPD-CMM CMMI SA-CMM

Más detalles

Definición de un Proceso de Implantación de Sistemas

Definición de un Proceso de Implantación de Sistemas Definición de un Proceso de Implantación de Sistemas Alicia Mon, Marcelo Estayno, Fernando López Gil, Eduardo De María 1 1 Grupo de Ingeniería de Software (G.I.S.) / Departamento de Sistemas / Universidad

Más detalles

Taller de Fundamentos de Mejora de Procesos

Taller de Fundamentos de Mejora de Procesos Taller de Fundamentos de Mejora de Procesos Capability Maturity Model, CMM and CMMI are registered in the U.S. Patent and Trademark Office Process Consulting - 22052009 Módulo 01 Diapositiva 1 Expectativas

Más detalles

COMPILACION BIBLIOGRAFICA CMMI - escm-sp

COMPILACION BIBLIOGRAFICA CMMI - escm-sp COMPILACION BIBLIOGRAFICA CMMI - escm-sp Presentado Por Luz Marina López Gómez UNIVERSIDAD DE CALDAS FACULTAD DE INGENIERIAS Ingeniería de Sistemas Y Computación Octubre 06 de 2010 Manizales COMPILACION

Más detalles

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización.

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Anexo 1 CMMI - Capability Maturity Model Integration Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Modelos y Normas Disponibles de Implementar

Modelos y Normas Disponibles de Implementar Modelos y Normas Disponibles de Implementar AmericaVeintiuno tiene capacidad para asesorar a una organización en base a diferentes modelos o normativas enfocadas al mercado informático. A partir de determinar

Más detalles

Mejora de procesos desde el ámbito de la innovación. Santiago, 20 de agosto 2014

Mejora de procesos desde el ámbito de la innovación. Santiago, 20 de agosto 2014 Mejora de procesos desde el ámbito de la innovación Santiago, 20 de agosto 2014 Presentación Paulina Dixiana Valenzuela Sánchez, PMP, Mg. Banco Falabella Jefe de Gestión de Proyectos, Calidad de Software

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS

UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS ÁREA DE PROYECTOS DE INGENIERÍA TRABAJO FIN DE MÁSTER METODOLOGÍA PARA LA EVALUACIÓN DE LA MADUREZ DEL SISTEMA DE GESTIÓN DE LA I+D+I

Más detalles

Relación de ITIL con los procesos de aseguramiento de la Calidad del Software.

Relación de ITIL con los procesos de aseguramiento de la Calidad del Software. Relación de ITIL con los procesos de aseguramiento de la Calidad del Software. Introducción. Desde 1996 IECI ha venido desarrollando actividades de prueba, muy orientadas al negocio que desarrolla. En

Más detalles

Describir el CMMI para el desarrollo de software, evolución, alcance y representación

Describir el CMMI para el desarrollo de software, evolución, alcance y representación Unidad 6: Introducción a CMMI Objetivo terminal de la Unidad Describir el CMMI para el desarrollo de software, evolución, alcance y representación Temas: Acerca del Modelo Capacidad Madurez Evolución de

Más detalles

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software CMMI SERVICIOS María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software AGENDA 1.- Qué es CMMI servicios? 2.- En qué nos puede ayudar

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS

GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS Diciembre 2008 AVISO LEGAL CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon Las distintas normas

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: QUÉ ES CALIDAD? ENFOQUES DE CALIDAD: DEMING, JURAN, CROSBY E ISHIKAWA PLANIFICACIÓN, CONTROL Y ASEGURAMIENTO DE LA CALIDAD AUDITORÍA DE CALIDAD GERENCIA DE LA CALIDAD TOTAL Y LA ORGANIZACIÓN

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

Hoja Informativa ISO 9001 Comprendiendo los cambios

Hoja Informativa ISO 9001 Comprendiendo los cambios Revisiones ISO Hoja Informativa ISO 9001 Comprendiendo los cambios Cambios que se aproximan ISO 9001 de un vistazo Cómo funciona ISO 9001? ISO 9001 puede ser aplicado a todo tipo de organizaciones de cualquier

Más detalles

Modelo de calidad IT Mark

Modelo de calidad IT Mark Modelo de calidad IT Mark Agenda de Trabajo 1. Área de Calidad 2. Introducción IT Mark 3. Proceso del Negocio 3.1 Ten Square. 3.2 Evaluación 3.3 Evidencias 3.4 Presentación de resultados. 4. Proceso de

Más detalles

Catálogo de Formación SEI

Catálogo de Formación SEI Catálogo de Formación SEI ESI lleva 15 años ofreciendo servicios de formación en diferentes tecnologías. En este tiempo ha formado a más de 4.000 profesionales de más de 800 organizaciones, en más de 30

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs

Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs del Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs Jose A. Calvo-Manzano, UPM I. García y M. Arcilla, UPM y UNED Introducción: Fracaso de los Proyectos Crisis del

Más detalles

Introducción. Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los Procesos

Introducción. Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los Procesos CobiT 75.46 Administración i ió y Control de Proyectos II Abril de 2008 Agenda Presentación Introducción Pi Principios ii dl del Modelo dl Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

Curso. Introducción a la Administracion de Proyectos

Curso. Introducción a la Administracion de Proyectos Curso Introducción a la Administracion de Proyectos Tema 5 Procesos del área de Integración INICIAR PLANEAR EJECUTAR CONTROL CERRAR Desarrollar el Acta de Proyecto Desarrollar el Plan de Proyecto Dirigir

Más detalles

Calidad de Software - CMM

Calidad de Software - CMM Calidad de Software - CMM Herramientas y Procesos de Software Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales Lic. Cecilia Palazzolo Año 2008 1 Qué es un modelo de procesos?

Más detalles

EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000

EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000 Examen tipo EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000 Edición Noviembre 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced,

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2 UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA GESTIÓN DE SOFTWARE INFORME SOBRE Evaluación de Productos Grupo 2 Marcelo Caponi 3.825.139-0 Daniel De Vera 4.120.602-3 José Luis Ibarra 4.347.596-3

Más detalles

COBIT - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012

COBIT - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012 - Control Objectives for Information and related Technology (Objetivos de Control para la Información y la Tecnología relacionada) Mayo de 2012 Antecedentes Ante la necesidad de crear y fortalecer el ambiente

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles

Capítulo 3 - Aseguramiento de la calidad del software

Capítulo 3 - Aseguramiento de la calidad del software Capítulo 3 - Aseguramiento de la calidad del software 3.1 Introducción La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar su valor. Está cuantificada por el valor que

Más detalles

Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en

Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en el Centro Informático del INSS Técnico superior de Informática INSS María Isabel Vicente Hernández Técnico medio de Informática

Más detalles

Evolución de los modelos CMMI

Evolución de los modelos CMMI Evolución de los modelos CMMI Enrique Morey Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University ESI 2009 1 Pregunta Qué entendemos como

Más detalles

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL Teniendo en cuenta que este trabajo tiene como objetivo el mostrar la metodología de evaluación del modelo de Capacidad de Madurez, es necesario antes de profundizar

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

TESIS DE MÁSTER. Implantación de CMMI en pequeñas empresas de desarrollo de software UNIVERSIDAD POLITÉCNICA DE VALENCIA

TESIS DE MÁSTER. Implantación de CMMI en pequeñas empresas de desarrollo de software UNIVERSIDAD POLITÉCNICA DE VALENCIA UNIVERDAD POLITÉCNICA DE VALENCIA TES DE MÁSTER Implantación de CMMI en pequeñas empresas de desarrollo de software Presentado por: Sergio Sanz Moyano Dirigido por: Juan Sánchez Díaz Valencia, 2009 2 Esta

Más detalles

LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA CMMI.

LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA CMMI. LA CALIDAD SE TOMA EL GIDIS, EMPIEZA LA EXPERIENCIA DESDE ISO9001 HASTA. Grupo de Investigación y Desarrollo de Ingeniería del Software. Departamento de Sistemas e Informática, Universidad Francisco de

Más detalles

Modelo de Procesos para la Industria de Software

Modelo de Procesos para la Industria de Software MoProSoft Modelo de Procesos para la Industria de Software Modelo MoProSoft 2 Perspectiva Histórica 2002 2003 2004 2005 AMCIS Círculo de Calidad 1996 Creación 1997 Emisión NMX-I-059 EvalProsoft Pruebas

Más detalles

1. PROCESOS DEL PROJECT MANAGEMENT

1. PROCESOS DEL PROJECT MANAGEMENT INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT

Más detalles

ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez

ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez ARANDA SOFTWARE: EXPERIENCIA DE IMPLEMENTACION DE CMMI SERVICIOS EN UNA ORGANIZACIÓN QUE CUENTA CON IMPLEMENTACION DE CMMI DEV María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Implementando COBIT. Por: Víctor Julio Zúñiga.MBA

Implementando COBIT. Por: Víctor Julio Zúñiga.MBA Implementando COBIT Por: Víctor Julio Zúñiga.MBA 1 LOS MODELOS DE MEJORES PRÁCTICAS Y LAS METAS DE TI tiempo 2 Alineado Soporte al Negocio Controlados Mejor seguros Calidad del Servicio Riesgos De TI tiempo

Más detalles

Sistema para auditar el cumplimiento de CMMI-SW nivel 2.

Sistema para auditar el cumplimiento de CMMI-SW nivel 2. Sistema para auditar el cumplimiento de CMMI-SW nivel 2. César Gabriel Vargas 1 Germán Biagioli 2 Trabajo final para obtener el grado de Licenciado en Informática / Licenciatura en Sistemas De la Facultad

Más detalles

EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000

EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000 Examen de muestra EXIN IT Service Management Foundation Bridge based on ISO/IEC 20000 Edición Noviembre 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced,

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process CMMI SM -SE/SW/IPPD, V1.02

CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process CMMI SM -SE/SW/IPPD, V1.02 CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process Development,, Versión n 1.02 CMMI SM -SE/SW/IPPD, V1.02 Indice - Procesos integrados - El concepto CMMI - Introducción

Más detalles

Pasando de ISO 9001:2008 a ISO 9001:2015

Pasando de ISO 9001:2008 a ISO 9001:2015 ISO 9001 Transition guide Revisiones ISO Pasando de ISO 9001:2008 a ISO 9001:2015 El nuevo estándar internacional para los sistemas de gestión de la calidad ISO 9001 Sistemas de Gestión de Calidad- Guía

Más detalles

Qué es el Modelo CMMI?

Qué es el Modelo CMMI? El principal problema que tienen las empresas en sus áreas de tecnología, así como las empresas desarrolladoras de software al iniciar un proyecto, radica en que el tiempo de vida del proyecto y el presupuesto

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

MANUAL DE LA CALIDAD ISO 9001 Julio 2008

MANUAL DE LA CALIDAD ISO 9001 Julio 2008 ISO 91 Julio 28 Fecha: 31/07/28 REVISION Y APROBACION DEL MANUAL Revisado por: Aprobado por: Fecha: Nro. de Revisión AUGUSTO TOSI JULIO RODRIGUEZ 31/07/28 Nombre y firma Nombre y firma SECCION 1: Tabla

Más detalles

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM CMM - Capability Maturity Model Estructura de CMM... Es un marco que describe los elementos claves de un proceso de software efectivo. Describe un camino de mejora evolutivo desde un proceso ad hoc inmaduro

Más detalles

Las Normas ISO 9000. Puede ser un producto material, un producto informático, servicio, información, etc.

Las Normas ISO 9000. Puede ser un producto material, un producto informático, servicio, información, etc. Las Normas ISO 9000 La serie de Normas ISO 9000 son un conjunto de enunciados, los cuales especifican que elementos deben integrar el Sistema de Gestión de la Calidad de una Organización y como deben funcionar

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

Más detalles

cumple y hay evidencias objetivas

cumple y hay evidencias objetivas Lista de Verificación ISO :2008 LISTA DE VERIFICACIÓN ISO :2008 Sistemas de Gestión de la Calidad Pliego Objeto y campo de aplicación Esta lista de verificación tiene como objetivo conocer con mayor detalle

Más detalles

Enginyeria del Software III

Enginyeria del Software III Enginyeria del Software III Sessió 2. El model CMM El model CMMi 1 El modelo CMM El modelo Capability Maturity Model (CMM), también denominado CMM-SW, fue desarrollado por el SEI como marco de referencia

Más detalles

Introducción. Por lo que existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad.

Introducción. Por lo que existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Introducción En la actualidad, el software se encuentra en muchos campos de la actividad humana: la industria, el comercio, las finanzas, gobierno, salud, educación, etc. Por lo que existe una creciente

Más detalles

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación CMMI DEV Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación Cecilia Rigoni Gerente de Caelum, Information & Quality Technologies. Vocal del Comité CSTIC de la AEC El modelo CMMI DEV,

Más detalles

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA TRABAJO PRÁCTICO DE AUDITORIA INFORMATICA Profesor: Lic. Marco Antonio Leiva Fernández 5to

Más detalles

Las Normas ISO 9000 del 2000

Las Normas ISO 9000 del 2000 Las Normas ISO 9000 del 2000 La serie de Normas ISO 9000 son un conjunto de enunciados, los cuales especifican que elementos deben integrar el Sistema de Gestión de la Calidad de una Organización y como

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration)

De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration) De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration) Preparado por: Amelia Soriano Alguna Bibliografía Carnagie Mellon - Software Engineering Institute, Capability Maturity

Más detalles

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión Alfredo Zayas 0 Alfredo Zayas 1. ISO/IEC 20000 Consultant por ITSMf 2. Auditor interno de ISO 9001:2000 por INLAC 3. Certified Information

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Parte informativo. ISO 9001:2015 Proyecto de Norma Internacional

Parte informativo. ISO 9001:2015 Proyecto de Norma Internacional Parte informativo ISO 9001:2015 Proyecto de Norma Internacional Índice 2 2 Creando la Cimentación para la Gestión de Calidad en una Nueva Era de Negocios 5 Otras revisiones principales en ISO 9001:2015

Más detalles

NORMA ISO 9001:2008 Sistemas de Gestión de la Calidad - ÍNDICE. 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación.

NORMA ISO 9001:2008 Sistemas de Gestión de la Calidad - ÍNDICE. 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación. TEMA ÍNDICE PÁGINA 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación. 3 2 Referencias normativas. 3 3 Términos y definiciones.. 3 4 Sistema de gestión de la calidad. 4 4.1 Requisitos

Más detalles

NORMA TÉCNICA NTC- ISO COLOMBIANA 9001

NORMA TÉCNICA NTC- ISO COLOMBIANA 9001 NORMA TÉCNICA NTC- ISO COLOMBIANA 9001 2008-11-14 SISTEMA DE GESTIÓN DE LA CALIDAD. REQUISITOS E: QUALITY MANAGEMENT SYSTEMS. REQUIREMENTS CORRESPONDENCIA: esta norma es idéntica (IDT) a la norma ISO 9001:2008

Más detalles

ESCUELA POLITÉCNICA NACIONAL

ESCUELA POLITÉCNICA NACIONAL ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS MARCO DE TRABAJO PARA LA GESTIÓN DE LA CALIDAD EN PROYECTOS DE DESARROLLO DE SOFTWARE BASADO EN PMBOK Y CMMI DEV. TESIS PREVIA A LA OBTENCIÓN

Más detalles

Cómo Comprar Software de Calidad. Pablo Straub Consultor

Cómo Comprar Software de Calidad. Pablo Straub Consultor Cómo Comprar Software de Calidad Pablo Straub Consultor El Problema Testimonio de un comprador de software a medida Nos entregaron el sistema informático mucho después de la fecha original y nos costó

Más detalles

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ETB requiere que el CONTRATISTA cumpla los lineamientos para la Dirección y Gestión de proyectos, éstos últimos definidos a nivel corporativo

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

ISO 9001,9002,9003,9004

ISO 9001,9002,9003,9004 Capitulo 06 ISO 9001,9002,9003,9004 Que es ISO 9001? Es una de las normas para la gestión y el aseguramiento de la calidad. Esta norma forma parte de un conjunto de tres normas sobre los sistemas de la

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

Eduardo Blanco, PMP Ingeniería de Desarrollo Software, Grupo SATEC. Universidad de Salamanca

Eduardo Blanco, PMP Ingeniería de Desarrollo Software, Grupo SATEC. Universidad de Salamanca Eduardo Blanco, PMP Ingeniería de Desarrollo Software, Grupo SATEC Agenda Caso práctico Introducción Una metodología CMMI Una empresa SATEC 2 Introducción De la Universidad a la Empresa En la Universidad

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL

GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL Consultor Senior de Calidad SW Métodos y Tecnología Responsable de Área Ingeniería y Calidad SW Métodos y Tecnología 1 Palabras clave ITIL,

Más detalles

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD COMISION DE REGLAMENTOS TECNICOS - CRT COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD SUB COMITÉ SECTOR EDUCACION NORMAS APROBADAS NTP 833.920-2003 Guía de aplicación de la Norma

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles