White Paper Una Introducción a CMMI

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

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

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

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

Procesos Críticos en el Desarrollo de Software

Procesos Críticos en el Desarrollo de Software Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine

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

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

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

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

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

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

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

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

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

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

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

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

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

Enginyeria del Software III

Enginyeria del Software III Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad

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

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

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

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

DE VIDA PARA EL DESARROLLO DE SISTEMAS

DE VIDA PARA EL DESARROLLO DE SISTEMAS MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso

Más detalles

0. Introducción. 0.1. Antecedentes

0. Introducción. 0.1. Antecedentes ISO 14001:2015 0. Introducción 0.1. Antecedentes Conseguir el equilibrio entre el medio ambiente, la sociedad y la economía está considerado como algo esencial para satisfacer las necesidades del presente

Más detalles

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA con destino a GORE DE ATACAMA ELIMCO SISTEMAS Alfredo Barros Errázuriz 1954

Más detalles

Tecnología de la Información. Administración de Recursos Informáticos

Tecnología de la Información. Administración de Recursos Informáticos Tecnología de la Información Administración de Recursos Informáticos 1. Recursos informáticos: Roles y Responsabilidades 2. Áreas dentro del Departamento de Sistemas 3. Conceptos asociados a proyectos

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

Unidad VI: Supervisión y Revisión del proyecto

Unidad VI: Supervisión y Revisión del proyecto Unidad VI: Supervisión y Revisión del proyecto 61. Administración de recursos La administración de recursos es el intento por determinar cuánto, dinero, esfuerzo, recursos y tiempo que tomará construir

Más detalles

Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO Dante Guerrero Piura, 2013 FACULTAD DE INGENIERÍA Área Departamental de Ingeniería Industrial y de Sistemas Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL

Más detalles

Operación 8 Claves para la ISO 9001-2015

Operación 8 Claves para la ISO 9001-2015 Operación 8Claves para la ISO 9001-2015 BLOQUE 8: Operación A grandes rasgos, se puede decir que este bloque se corresponde con el capítulo 7 de la antigua norma ISO 9001:2008 de Realización del Producto,

Más detalles

Implementando un ERP La Gestión del Cambio

Implementando un ERP La Gestión del Cambio Artículos> Implementando un ERP - La Gestión del Cambio Artículo Implementando un ERP La Gestión del Cambio 1 Contenido Sumario Ejecutivo 3 Los sistemas ERP flexibilizan la gestión de la empresa y su cadena

Más detalles

Para poder controlar se tiene que medir! Por qué desarrollar una cultura de la medición en la empresa?

Para poder controlar se tiene que medir! Por qué desarrollar una cultura de la medición en la empresa? EL CONTROL DE LA GESTION EMPRESARIAL BASADA EN INDICADORES manuelponce@partnerconsulting.com.pe El control de la gestión empresarial es cada vez una preocupación latente en las organizaciones. Preguntados

Más detalles

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

Gestión de la Configuración

Gestión de la Configuración Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de

Más detalles

GESTION OPERATIVA. Niveles de gestión

GESTION OPERATIVA. Niveles de gestión GESTION OPERATIVA La gestión deja de ser una tarea aislada para constituirse en una herramienta que sirve para ejecutar las acciones necesarias que permitan ordenar, disponer y organizar los recursos de

Más detalles

Implementación de Paquetes

Implementación de Paquetes Project Management Caso Particular: Implementación de Paquetes Fases de Project Management Visión Proyecto Aprobado Inicio (Alcance) Alcance Aprobado Organización Planificación Aprobada Ejecución y Control

Más detalles

Seis Sigma. Nueva filosofía Administrativa.

Seis Sigma. Nueva filosofía Administrativa. Seis Sigma. Nueva filosofía Administrativa. GIN. Filosofía de Calidad. El Seis Sigma es un parámetro cuya base principal es la desviación estándar y su enfoque es reducir la variación y/o defectos en lo

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

NORMA ISO 9001. Estos cinco apartados no siempre están definidos ni son claros en una empresa.

NORMA ISO 9001. Estos cinco apartados no siempre están definidos ni son claros en una empresa. NORMA ISO 9001 0. Concepto de Sistema de Gestión de la Calidad. Se define como el conjunto de normas interrelacionadas de una empresa u organización por los cuales se administra de forma ordenada la calidad

Más detalles

Términos definiciones

Términos definiciones Términos y definiciones 3Claves para la ISO 9001-2015 Términos y definiciones: ISO9001 utiliza una serie de definiciones ligadas a la gestión de la calidad, que también deben ser comprendidas por la organización

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

GERENCIA DE INTEGRACIÓN

GERENCIA DE INTEGRACIÓN GERENCIA DE INTEGRACIÓN CONTENIDO Desarrollo del plan Ejecución del plan Control de cambios INTRODUCCIÓN La gerencia de integración del proyecto incluye los procesos requeridos para asegurar que los diversos

Más detalles

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS Los clientes compran un servicio basandose en el valor que reciben en comparacion con el coste en el que incurren. Por, lo tanto, el objetivo a largo plazo

Más detalles

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000 1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas

Más detalles

Unidad 1. Fundamentos en Gestión de Riesgos

Unidad 1. Fundamentos en Gestión de Riesgos 1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.

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

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

Normas chilenas de la serie ISO 9000

Normas chilenas de la serie ISO 9000 Normas chilenas de la serie ISO 9000 Hernán Pavez G. Director Ejecutivo del Instituto Nacional de Normalización, INN, Matías Cousiño N 64, 6 Piso, Santiago, Chile. RESUMEN: en nuestro país las empresas

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

ISO 9001:2015 Cuestionario de autoevaluación

ISO 9001:2015 Cuestionario de autoevaluación ISO 9001:2015 Cuestionario de autoevaluación Qué tan preparado estás para la norma ISO 9001: 2015? Este documento ha sido diseñado para evaluar la preparación de su empresa para un Sistema de Gestión Calidad

Más detalles

Señor A/P. Lino Bessonart FEMI Presente Ref.: 181/2009

Señor A/P. Lino Bessonart FEMI Presente Ref.: 181/2009 1 Montevideo, 11 de marzo de 2009 Señor A/P. Lino Bessonart FEMI Presente Ref.: 181/2009 De nuestra consideración, De acuerdo a vuestra solicitud, tenemos el agrado de poner a su consideración la presente

Más detalles

Master en Gestion de la Calidad

Master en Gestion de la Calidad Master en Gestion de la Calidad 3. La Calidad en la Actualidad La calidad en la actualidad 1 / 9 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer la calidad en la actualidad. La familia

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

Política de Gestión Integral de Riesgos Compañía Sud Americana de Vapores S.A.

Política de Gestión Integral de Riesgos Compañía Sud Americana de Vapores S.A. de Riesgos Compañía Sud Americana de Vapores S.A. Elaborado Por Revisado Por Aprobado por Nombre Cargo Fecha Claudio Salgado Comité de Directores Contralor Comité de Directores Diciembre 2015 21 de diciembre

Más detalles

ISO 9001:2000 DOCUMENTO INFORMATIVO DOCUMENTO ELABORADO POR CHRISTIAN NARBARTE PARA EL IVECE

ISO 9001:2000 DOCUMENTO INFORMATIVO DOCUMENTO ELABORADO POR CHRISTIAN NARBARTE PARA EL IVECE ISO 9001:2000 DOCUMENTO INFORMATIVO DOCUMENTO ELABORADO POR CHRISTIAN NARBARTE PARA EL IVECE MARZO 2007 Este documento contesta las preguntas más frecuentes que se plantean las organizaciones que quieren

Más detalles

MANEJO DE QUEJAS Y RECLAMOS

MANEJO DE QUEJAS Y RECLAMOS MANEJO DE QUEJAS Y RECLAMOS Derechos reservados ICONTEC- 1 OBJETIVO GENERAL Proponer una metodología para la planeación, diseño, operación, mantenimiento y mejora de un proceso para el manejo de los reclamos

Más detalles

MANUAL DE CALIDAD ISO 9001:2008

MANUAL DE CALIDAD ISO 9001:2008 Página 1 de 21 MANUAL DE CALIDAD ISO 9001:2008 EMPRESA DE DISTRIBUCION DE ALUMINIO Y VIDRIO ELABORADO POR: APROBADO POR: REPRESENTANTE DE LA ALTA DIRECCIÓN GERENTE PROPIETARIO Página 2 de 21 CONTENIDO

Más detalles

COMPILACION BIBLIOGRAFICA PMBOK, OPM3 JHON FREDY GIRALDO. Docente: Carlos Hernán Gomez Asignatura: Auditoria de Sistemas

COMPILACION BIBLIOGRAFICA PMBOK, OPM3 JHON FREDY GIRALDO. Docente: Carlos Hernán Gomez Asignatura: Auditoria de Sistemas COMPILACION BIBLIOGRAFICA PMBOK, OPM3 JHON FREDY GIRALDO Docente: Carlos Hernán Gomez Asignatura: Auditoria de Sistemas UNIVERSIDAD DE CALDAS FACULTAD DE INGENIERIA INGENIERIA EN SISTEMAS Y COMPUTACION

Más detalles

Orientación acerca de los requisitos de documentación de la Norma ISO 9001:2000

Orientación acerca de los requisitos de documentación de la Norma ISO 9001:2000 Orientación acerca de los requisitos de documentación de la Norma ISO 9001:2000 Documento: ISO/TC 176/SC 2/N 525R Marzo 2001 ISO Traducción aprobada el 2001-05-31 Prólogo de la versión en español Este

Más detalles

Proceso: AI2 Adquirir y mantener software aplicativo

Proceso: AI2 Adquirir y mantener software aplicativo Proceso: AI2 Adquirir y mantener software aplicativo Se busca conocer los estándares y métodos utilizados en la adquisición de y mantenimiento del software. Determinar cuál es proceso llevado a cabo para

Más detalles

+ Cómo ahorrar dinero con Software Quality

+ Cómo ahorrar dinero con Software Quality + Cómo ahorrar dinero con Software Quality Qué es Software Quality Assurance? Porqué facilita el ahorro de dinero? Introducción El objetivo de este documento es explicar qué es Software Quality Assurance,

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

Traducción del. Our ref:

Traducción del. Our ref: Traducción del Documento: Our ref: Secretaría del ISO/TC 176/SC 2 Fecha: 15 de octubre de 2008 A los Miembros del ISO/TC 176/SC 2 - Gestión de la Calidad y Aseguramiento de la Calidad/ Sistemas de la Calidad

Más detalles

Gestión de Configuración del Software

Gestión de Configuración del Software Gestión de Configuración del Software Facultad de Informática, ciencias de la Comunicación y Técnicas Especiales Herramientas y Procesos de Software Gestión de Configuración de SW Cuando se construye software

Más detalles

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC CALIDAD DE SOFTWARE Guía para Examen Segundo Parcial Grupo 6501

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC CALIDAD DE SOFTWARE Guía para Examen Segundo Parcial Grupo 6501 1. Qué incluye la ingeniería del software con SQA? Entrenamiento, soporte al consumidor instalación. 2. Menciona algunas características del software: Elemento lógico. Desarrollado no fabricado. No se

Más detalles

Sede Escazú, Plaza Tempo 4031-0999 40310991 E-mail: cit@ulacit.ac.cr

Sede Escazú, Plaza Tempo 4031-0999 40310991 E-mail: cit@ulacit.ac.cr 16-0079 / 29-0952 FORMULACIÓN PROYECTOS Descripción General: Provee una introducción que abarca el ciclo de vida completo del desarrollo de un proyecto, desde que se concibe en los niveles más altos de

Más detalles

Caso Particular: 75.46 - Administración y Control de Proyectos II. Planificación Aprobada. Ejecución y Control. Administración del Cambio

Caso Particular: 75.46 - Administración y Control de Proyectos II. Planificación Aprobada. Ejecución y Control. Administración del Cambio Project Management Caso Particular: Implementación de Paquetes Fases de Project Management Visión Aprobado Alcance Alcance Aprobado Organización Planificación Aprobada Ejecución y Control Finalizado Cierre

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

Planificación, Gestión y Desarrollo de Proyectos

Planificación, Gestión y Desarrollo de Proyectos Planificación, Gestión y Desarrollo de Proyectos Conceptos básicos Planificación de un proyecto Gestión de un proyecto Desarrollo de un proyecto 1 Conceptos básicos: Proyecto Conjunto de actividades que

Más detalles

PROCEDIMIENTO DE AUDITORIAS INTERNAS. CALIDAD INSTITUCIONAL Versión: 02

PROCEDIMIENTO DE AUDITORIAS INTERNAS. CALIDAD INSTITUCIONAL Versión: 02 1. OBJETIVO Realizar la planificación, estructuración y ejecución de las auditorías internas, con el objeto de garantizar el cumplimiento de los requisitos de la Norma ISO 9001:2008 y los fijados por la

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

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

ITIL FOUNDATION V3 2011

ITIL FOUNDATION V3 2011 ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la

Más detalles

EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P. DIRECCIÓN CONTROL INTERNO PROYECTO NORMALIZACIÓN ACTIVIDAD DE AUDITORÍA INTERNA

EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P. DIRECCIÓN CONTROL INTERNO PROYECTO NORMALIZACIÓN ACTIVIDAD DE AUDITORÍA INTERNA DCI-PN-EA-01 VERSIÓN 02 Página 2 de 12 TABLA DE CONTENIDO 1. INTRODUCCIÓN... 3 2. ROL... 3 3. PROFESIONALIDAD... 3 4. AUTORIDAD... 4 5. ORGANIZACIÓN... 4 6. INDEPENDENCIA Y OBJETIVIDAD... 5 7. ALCANCE...

Más detalles

PROCEDIMIENTO AUDITORÍA INTERNA

PROCEDIMIENTO AUDITORÍA INTERNA PROCEDIMIENTO AUDITORÍA INTERNA CONTENIDO 1. OBJETO... 2 2. ALCANCE... 2 3. DEFINICIONES... 2 5. PROCEDIMIENTO... 4 5.1 Planificación de la Auditoría... 4 5.2 Calificación de Auditores... 4 5.3 Preparación

Más detalles

Lista de la Verificación de la Gestión de la Seguridad y Salud Ocupacional 1

Lista de la Verificación de la Gestión de la Seguridad y Salud Ocupacional 1 Lista de la Verificación de la Gestión de la Seguridad y Salud Ocupacional 1 Sección Punto de Control Cumplimiento 4. Requisitos del Sistema de gestión de la seguridad y salud ocupacional 4.1 Requisitos

Más detalles

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

Más detalles

Norma ISO 14001: 2015

Norma ISO 14001: 2015 Norma ISO 14001: 2015 Sistema de Gestión Medioambiental El presente documento es la versión impresa de la página www.grupoacms.com Si desea más información sobre la Norma ISO 14001 u otras normas relacionadas

Más detalles

Figure 16-1: Phase H: Architecture Change Management

Figure 16-1: Phase H: Architecture Change Management Fase H Administración del cambio en la Arquitectura Figure 16-1: Phase H: Architecture Change Management Objetivos Los objetivos de la Fase H son: Asegurarse de que el ciclo de vida de arquitectura se

Más detalles

Principales Cambios de la ISO 9001:2015

Principales Cambios de la ISO 9001:2015 INTRODUCCIÓN La nueva versión disponible de ISO 9001:2015, actualmente en su versión DIS, muestra una gran cantidad de cambios respecto de su predecesora. Muchos de estos cambios están en línea con otros

Más detalles

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Sergio Valero Orea, svalero@utim.edu.mx, UTIM, Izúcar de Matamoros, Puebla. Resumen El desarrollo de sistemas

Más detalles

Sistema de Gestión de la Seguridad de la Información, UNE-ISO/IEC 27001

Sistema de Gestión de la Seguridad de la Información, UNE-ISO/IEC 27001 Sistema de Gestión de la Seguridad de la Información, UNE-ISO/IEC 27001 Aníbal Díaz Gines Auditor de SGSI Certificación de Sistemas Applus+ Sistema de Gestión de la Seguridad de la Información, UNE-ISO/IEC

Más detalles

CAS-CHILE. Líder en Software de Gestión Pública

CAS-CHILE. Líder en Software de Gestión Pública Líder en Software de Gestión Pública CONSTRUCCIÓN E IMPLEMENTACIÓN DE UN SISTEMA DE ADMINISTRACIÓN ESTRATÉGICA UTILIZANDO EL BALANCED SCORECARD: NUEVE PASOS PARA EL ÉXITO -Balanced Scorecard Institute

Más detalles

Procedimiento para el Manejo de No Conformidades, Acciones Preventivas y Correctivas del Sistema de Gestión Integral

Procedimiento para el Manejo de No Conformidades, Acciones Preventivas y Correctivas del Sistema de Gestión Integral Página: 1 de 1 Hoja de Control de Emisión y Revisiones. N de Revisión Páginas Afectadas Motivo del Cambio Aplica a partir de: 0 Todas Generación de documento 01-Agosto-2009 1 Todas Mejora del documento

Más detalles

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE SOFTWARE Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE AUTOS Entrada Salida Autos FÁBRICA DE SOFTWARE Entrada Salida Información

Más detalles

Sistemas de Gestión de Calidad. Control documental

Sistemas de Gestión de Calidad. Control documental 4 Sistemas de Gestión de Calidad. Control documental ÍNDICE: 4.1 Requisitos Generales 4.2 Requisitos de la documentación 4.2.1 Generalidades 4.2.2 Manual de la Calidad 4.2.3 Control de los documentos 4.2.4

Más detalles

Plan de Administración del Proyecto

Plan de Administración del Proyecto L México 2002 Atención Ciudadana y Gestión de Programas Sociales Plan de Administración del Proyecto Introducción: El Plan de Administración del Proyecto provee información de cómo el proyecto debe ser

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

Capítulo IV. Manejo de Problemas

Capítulo IV. Manejo de Problemas Manejo de Problemas Manejo de problemas Tabla de contenido 1.- En qué consiste el manejo de problemas?...57 1.1.- Ventajas...58 1.2.- Barreras...59 2.- Actividades...59 2.1.- Control de problemas...60

Más detalles

PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores

PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores Martha Alicia Alles Es contadora pública nacional, doctora por la Universidad de Buenos Aires en la especialidad

Más detalles

GESTIÓN DEL SISTEMA DE MEDICIÓN ANÁLISIS Y MEJORAMIENTO

GESTIÓN DEL SISTEMA DE MEDICIÓN ANÁLISIS Y MEJORAMIENTO GESTIÓN DEL SISTEMA DE MEDICIÓN ANÁLISIS Y MEJORAMIENTO Derechos reservados ICONTEC- 1 MEDICIÓN, ANÁLISIS Y MEJORAMIENTO DEL SISTEMA DE GESTIÓN DE LA MEDICIÓN. Normas Aplicadas NTC-ISO 10012. Duración

Más detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT PC0901 - Proceso de control de cambios en software de aplicación provisto por Organismos Gobierno de la Ciudad Autónoma de Buenos Aires PC0901 - Proceso de control de cambios en software

Más detalles