MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS

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

Download "MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS"

Transcripción

1 MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS Esta guía contiene orientaciones para la implementación del nivel C del Modelo de Referencia MR-MPS. VIGENCIA Y TRANSICIÓN: La Guía General:2011 entra en vigor el 30 de junio de Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Sin embargo, queda definido un período de transición, de 30 de junio a 31 de diciembre de 2011, durante el cual pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011 o la versión anterior MR-MPS:2009. A partir del 1º de enero de 2012 solo serán válidas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Las implementaciones a ser realizadas utilizando esta Guía de Implementación deberán llevar en cuenta estas vigencias. Julio de 2011 Copyright SOFTEX Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN

2 Índice 1 Prefacio Introducción Objetivo Evolucionando del nivel D al nivel C Desarrollo para Reutilización (DRU) Propósito Fundamentación teórica Resultados esperados Gestión de Decisiones (GDE) Propósito Fundamentación teórica Resultados esperados Gestión de Riesgos (GRI) Propósito Fundamentación teórica Resultados esperados Los atributos de proceso del nivel C Referencias bibliográficas Lista de colaboradores de la Guía de Implementación Parte 5: Lista de colaboradores de la Guía de Implementación Parte 5: Lista de colaboradores de la Guía de Implementación Parte 5 versión Julio/ Lista de colaboradores de la Guía de Implementación Parte 5 versión Diciembre/ MPS.BR Guía de Implementación Parte 5:2011 2/37

3 1 Prefacio El MPS.BR 1 es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID). El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del Software, para lograr dos metas a mediano y largo plazo: a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) certificados para prestar servicios de consultoría de adquisición de software y servicios asociados; b) meta de mercado, teniendo como objetivo la propagación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYMEs (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años). El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento. Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA); (ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS. Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops. 1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada al programa MPS.BR Mejora del Proceso de Software Brasileño y la sigla MPS está asociada al modelo MPS Mejora del Proceso de Software. MPS.BR Guía de Implementación Parte 5:2011 3/37

4 La creación y el perfeccionamiento de esta Guía de Implementación son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS: Guía General [SOFTEX, 2011a]; Guía de Implementación (partes 1 a 11); Guía de Evaluación [SOFTEX, 2011b]; y Guía de Adquisición [SOFTEX, 2011c]. Esta Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. La Guía de implementación está subdividida en once partes, contemplando respectivamente, los siguientes niveles de madurez: Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS; Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS; Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS; Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS; Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS; Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS; Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS; Parte 8: Implementación del MR-MPS (Niveles G a A) en organizaciones que adquieren software; Parte 9: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Software; Parte 10: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas; y Parte 11: Implementación y Evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV. Los cambios de esta Guía de Implementación en relación a la versión 2009 se deben a: cambios realizados en la versión 2009 de la Guía General; corrección ortográfica y gramatical; adecuación de las referencias bibliográficas; inclusión de notas explicativas contenidas en las partes 8, 9 y 10 de la Guía de Implementación; inclusión de comentario sobre dominios de aplicación y aclaración sobre el resultado esperado DRU7. MPS.BR Guía de Implementación Parte 5:2011 4/37

5 2 Introducción Los cambios que están sucediendo en los ambientes de negocios han motivado a las empresas a modificar sus estructuras organizacionales y procesos productivos, saliendo de la visión tradicional basada en áreas funcionales hacia redes de procesos centrados en el cliente. La competitividad depende, cada vez más, del establecimiento de conexiones en estas redes, creando vínculos esenciales en las cadenas productivas. Lograr competitividad por la calidad, para las empresas de software, implica tanto la mejora de la calidad de los productos de software y servicios asociados, así como la de los procesos de producción y distribución de software. De esta forma, así como para otros sectores, la calidad es un factor crítico de éxito para la industria de software. Para que se tenga un sector de software competitivo nacional e internacionalmente, es esencial que los emprendedores del sector se concentren en la eficiencia y la eficacia de sus procesos, buscando ofrecer productos de software y servicios asociados conforme estándares internacionales de calidad. Se busca que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas. También se espera que el modelo MPS sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles. De esta forma, tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y atiende a la necesidad de implantar los principios de Ingeniería de Software de manera adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para la definición, evaluación y mejora de procesos de software. El Modelo MPS se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y servicios asociados. Dentro de ese contexto, el MPS.BR posee tres componentes: Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). El Modelo MPS está descrito por medio de documentos en forma de guías: Guía General: contiene la descripción general del modelo MPS y detalla el Modelo de Referencia (MR-MPS), sus componentes y las definiciones comunes necesarias para su entendimiento y aplicación. Guía de Adquisición: describe un proceso de adquisición de software y servicios asociados. Está descrito de modo que apoye a las instituciones que quieran adquirir productos de software y servicios asociados. Guía de Evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA); y Guía de Implementación: serie de once documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS. MPS.BR Guía de Implementación Parte 5:2011 5/37

6 3 Objetivo La Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. Este documento corresponde a la parte 5 de la Guía de Implementación y aborda la implementación del nivel de madurez C. Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS para mejora de sus procesos de software e Instituciones Implementadoras (II). El contenido de este documento es informativo, o sea, no se espera que una organización implementando el MR-MPS cumpla todos los elementos citados en la explicación referente a los resultados esperados. Las observaciones presentes en este documento buscan apenas explicitar elementos importantes en la interpretación de los resultados esperados. Durante una evaluación MPS, solo es requerido el cumplimiento de los resultados esperados definidos en la Guía General. Los evaluadores MPS deben analizar si la implementación de los procesos de la organización cumple cada resultado, con abertura a múltiples formas válidas de implementación. 4 Evolucionando del nivel D al nivel C La evolución del nivel D al nivel C no presenta novedades en términos de los procesos y atributos de proceso ya implantados en el nivel D. La evolución hacia el nivel C del MR-MPS implica, por lo tanto, apenas en la definición e implementación de tres nuevos procesos con la misma capacidad de los procesos ya implantados: Gestión de Decisiones (GDE), Desarrollo para Reutilización (DRU) y Gestión de Riesgos (GRI). En este nivel, se permiten exclusiones de resultados esperados apenas del proceso Desarrollo para Reutilización (DRU) conforme definido en la sección Desarrollo para Reutilización (DRU) 5.1 Propósito El propósito del proceso Desarrollo para Reutilización es identificar oportunidades de reutilización sistemática de activos en la organización y, si es posible, establecer un programa de reutilización para desarrollar activos a partir de ingeniería de dominios de aplicación. La Reutilización de Software es la disciplina responsable por la creación de sistemas de software a partir de software pre-existente [KRUEGER, 1992]. Diferentemente de la reutilización ad hoc, que usualmente se concretiza con copia de trechos de artefactos preexistentes, la disciplina de Reutilización de Software busca sistematizar y difundir prácticas de reutilización en la organización. El proceso Desarrollo para Reutilización es uno de los mecanismos utilizados por la disciplina de Reutilización de Software para ese fin. El Desarrollo para Reutilización busca aplicar técnicas de ingeniería de dominio para definir el alcance, especificar la estructura y construir activos reutilizables para una clase de sistemas, subsistemas o aplicaciones [IEEE, 2004]. Esos activos MPS.BR Guía de Implementación Parte 5:2011 6/37

7 reutilizables, por ser producidos a partir de la ingeniería de dominio, son denominados activos de dominio. De esta forma, el principal resultado de la aplicación del proceso Desarrollo para Reutilización es la especificación, diseño e implementación de activos de dominio que atiendan a familias de aplicaciones o a dominios de conocimiento específicos. El Desarrollo para Reutilización se inicia en la identificación del potencial de reutilización y de la capacidad de reutilización de la organización. En esa etapa se busca minimizar el riesgo de implantación de un programa de reutilización. En situaciones donde el Desarrollo para Reutilización se aplica, la etapa siguiente consiste en el análisis, diseño e implementación de activos de dominio previamente definidos. A partir de ese momento, los activos de dominio pueden ser objeto de propuestas de reutilización, de acuerdo con procesos de ingeniería de aplicación [JACOBSON et al., 1997]. Como puede ser constatado, el Desarrollo para Reutilización no se propone a definir cuándo y cómo los activos de dominio deben ser reutilizados, rol este reservado al propio proceso de desarrollo de software. Su actuación ocurre en la creación y evolución de esos activos de dominio, llevando en consideración la demanda existente en los diversos proyectos de la organización. De esta forma, es posible percibir que el proceso Desarrollo para Reutilización actúa tanto a nivel organizacional, en lo que se refiere a la creación de los activos de dominio, así como en proyectos específicos, en lo que se refiere a solicitaciones de reutilización de los activos de dominio. El proceso Desarrollo para Reutilización está íntimamente relacionado a otros procesos del MR-MPS. Por ejemplo, el proceso Gestión de Proyectos apoya en la planificación del proceso Desarrollo para Reutilización y del programa de reutilización; el proceso Gestión de Decisiones apoya en la decisión sobre la implantación o no de un programa de reutilización en la organización; el proceso Gestión de Riesgos apoya en la evaluación de la capacidad de reutilización de la organización; el proceso Verificación apoya la revisión del programa de reutilización y de los activos de dominio; el proceso Adquisición apoya en la adquisición de activos de dominio en el mercado; el proceso Gestión de Configuración apoya en la evolución de los activos de dominio producidos durante la ejecución del proceso Desarrollo para Reutilización. Por otro lado, el proceso Desarrollo para Reutilización puede apoyar al proceso Gestión de Reutilización, suministrando activos para colocarlos a disponibilidad para reutilización en la organización, y el proceso Diseño y Construcción del Producto, cuando se decide por reutilizar componentes del producto. MPS.BR Guía de Implementación Parte 5:2011 7/37

8 Exclusiones de resultados esperados de este proceso son permitidas de acuerdo con lo definido en la Tabla 5.1. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de procesos o de resultados esperados deben estar identificadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado da Evaluación. Tabla 5.1 Exclusiones de los Resultados de DRU. Oportunidades (DRU1) Capacidad (DRU2) Solución Si Si Los demás resultados del DRU son obligatorios Si No No Excluido Debe ejecutar acciones correctivas para generar capacidad Debe comprobar que esas acciones correctivas están en curso Los demás resultados pueden ser excluidos de esa evaluación Para la próxima evaluación, con un plazo de 3 años, debe obligatoriamente haber construido la capacidad Debe demostrar, vía proceso formal de toma de decisión, que no existen oportunidades de reutilización Los demás resultados pueden ser excluidos mientras haya ausencia de oportunidades de reutilización (en esa y en las próximas evaluaciones) Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) Las exclusiones de resultados de este proceso permitidas están definidas en la tabla arriba y no difieren de las permitidas para otro tipo de organización. Como no existen especificidades para organizaciones adquirentes, no fueron incluidos comentarios en los resultados esperados. Las exclusiones de resultados de este proceso permitidas están definidas en la tabla arriba y no difieren de las permitidas para otro tipo de organización. Para el caso de una organización del tipo Fábrica de Software, por restricciones contractuales, muchas veces no es permitido reutilizar componentes entre proyectos y/o clientes diferentes. Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios en los resultados esperados. MPS.BR Guía de Implementación Parte 5:2011 8/37

9 Fábrica de Pruebas (Parte 10) Las exclusiones de resultados de este proceso permitidas están definidas en la tabla arriba y no difieren de las permitidas para otro tipo de organización. La aprobación de las exclusiones es responsabilidad del evaluador líder, dependiendo del tipo de Prueba a ser efectuada. Productos típicamente reutilizables para el caso de una Fábrica de Pruebas son los scripts de Prueba o las Pruebas automatizadas. Sin embargo, para el caso de una organización del tipo Fábrica de Pruebas, por restricciones contractuales, muchas veces no es permitido reutilizar componentes entre proyectos y/o clientes diferentes. Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios en los resultados esperados. 5.2 Fundamentación teórica La Reutilización de Software surgió en 1968, a partir de la constatación de que sistemas de software podrían ser construidos a partir de componentes preexistentes [MCILROY, 1968]. En aquel momento, componentes eran considerados apenas rutinas de código, y los dominios de aplicación sugeridos para la creación de componentes eran de infraestructura (por ejemplo, rutinas de aproximación numérica, conversión de entrada/salida, geometría 2D y 3D, procesamiento de texto y persistencia). Desde entonces, fue posible notar una gran evolución en la disciplina de Reutilización de Software: los componentes reutilizables, que eran considerados como rutinas de código, hoy en día son tratados en diferentes niveles de abstracción; los dominios de aplicación, que se concentraban básicamente en infraestructura, hoy están migrando cada vez más para dominios de negocio, donde se pueden observar ganancias mayores con la aplicación de reutilización; y los procesos de apoyo se tornaron cada vez más maduros. Bajo la dimensión de procesos, el proceso de Reutilización de Software puede ser descompuesto en dos procesos principales [MOORE e BAILIN, 1991]: Desarrollo para Reutilización y Desarrollo con Reutilización. El proceso Desarrollo para Reutilización utiliza técnicas de ingeniería de dominio para la creación de activos reutilizables para un dominio específico. El proceso Desarrollo con Reutilización utiliza técnicas de ingeniería de aplicación para la incorporación de activos reutilizables preexistentes en nuevas aplicaciones. De forma análoga al desarrollo convencional de software, la ingeniería de dominio puede ser subdividida en tres sub-actividades principales: análisis, diseño e implementación. El principal producto del análisis es el modelo de dominio. A su vez, el principal producto del diseño es la arquitectura de dominio. Finalmente, el principal producto de la implementación son los activos de dominio. No obstante, para que el proceso Desarrollo para Reutilización tenga éxito, aspectos técnicos y organizacionales deben ser considerados. En lo referente a los aspectos técnicos, diversos métodos fueron propuestos para apoyar en la creación de los activos de dominio. Por otro lado, en lo referente a aspectos organizacionales, MPS.BR Guía de Implementación Parte 5:2011 9/37

10 diferentes cuestiones también son importantes, tales como: composición de los equipos, certificación de los componentes, responsabilidad de mantenimiento, aspectos legales, aspectos económicos, etc. Como el objetivo del proceso Desarrollo para Reutilización no es la construcción de una única aplicación, sino más bien de activos de dominio que atiendan a familias de aplicaciones, es necesario que esos activos de dominio tengan un grado adecuado de generalidad. Para eso, la ingeniería de dominio hace uso de recursos usualmente utilizados en el análisis de sistemas convencional, acrecidos de funcionalidades especiales para especificar elementos obligatorios u opcionales, comunes o variantes, dependencias y restricciones. Una característica obligatoria de un dominio representa algo que debe estar presente en todas las aplicaciones para aquel dominio. Por otro lado, una característica opcional de un dominio representa algo que puede o no estar presente en aplicaciones del dominio. De forma perpendicular, una característica común del dominio tiene el mismo comportamiento en todas las aplicaciones del dominio. Ya una característica variante del dominio puede tener comportamientos diferenciados para diferentes aplicaciones del dominio. Además de eso, pueden existir relaciones específicas entre las diversas características de un dominio [KANG et al., 1990]. Esas relaciones son usualmente divididas en dos categorías: dependencia y exclusión mutua. La relación de dependencia indica que una característica solo puede ser reutilizada de forma correcta en caso de que otras características también sean reutilizadas en conjunto (por ejemplo: la característica A requiere la característica B). Por otro lado, la relación de exclusión mutua indica que una característica solo puede ser reutilizada de forma correcta en caso de que otras características no sean reutilizadas en conjunto (por ejemplo: la característica A excluye la característica B). Usualmente son utilizados otros operadores lógicos en conjunto con esas relaciones para aumentar el poder de expresión del modelo de dominio. De esta forma, un modelo de dominio describe en un alto nivel de abstracción las diversas familias de aplicaciones de un dado dominio. A partir del detalle de ese modelo de dominio, es obtenida la arquitectura de dominio, que sirve como base para la priorización de los activos de dominio que serán posteriormente adquiridos o desarrollados. Vale resaltar que, un elemento clave en ese escenario es la rastreabilidad entre las representaciones de los activos de dominio en diferentes niveles de abstracción. Con base en esa rastreabilidad, es posible seleccionar determinadas características en el modelo de dominio (recorte del modelo de dominio) e identificar cuáles son los activos de dominio que deben ser reutilizados para proveer las características seleccionadas. MPS.BR Guía de Implementación Parte 5: /37

11 5.3 Resultados esperados DRU1 - Dominios de aplicación en que serán investigadas oportunidades de reutilización de activos o en los cuales se pretende practicar reutilización son identificados, detectando los respectivos potenciales de reutilización Con la intención de viabilizar la decisión de implantación de un programa de reutilización, es necesario verificar si las ganancias proporcionadas por esa implantación son mayores que sus costos. Para eso, los dominios de actuación de la organización deben ser identificados. Esa identificación, que usualmente se basa en proyectos pasados, debe estar alineada con los objetivos organizacionales y las metas de medio y largo plazo de la organización. Con eso, además de percibir en cuales dominios la organización actuó hasta entonces, es posible inferir dominios en que la organización pretende actuar en un futuro próximo. Los dominios de aplicación de una organización son aquellos relacionados al área de negocio de ella, por ejemplo, banquera, automatización comercial, médica etc. En otro ejemplo, si la empresa es desarrolladora de sistemas de administración de banco de datos (SGBD), tiene sentido que el dominio de aplicación de ella sea almacenamiento, caso contrario, no. Para cada dominio identificado, se debe analizar el potencial de reutilización, llevando en consideración los activos de dominio preexistentes en la organización y la posibilidad de adquirir activos de dominio en el mercado. El potencial de reutilización debe llevar en consideración la importancia del dominio para la organización en términos de proyectos futuros que la organización pretende ejecutar en el dominio en cuestión y el nivel de madurez y estabilidad del dominio. O sea, un dominio en que existe una gran oferta de activos de dominio, pero que la organización no pretende actuar más, es considerado de bajo potencial de reutilización bajo el punto de vista de la organización. De la misma forma, el potencial de reutilización de un dominio inmaduro, con alto grado de inestabilidad, es usualmente considerado bajo, debido a la dificultad de mantener un conjunto razonable de activos de dominio disponible y consistente. La no existencia de dominios con potencial de reutilización en la organización puede justificar la no adopción de un programa de reutilización. No obstante, para justificar esa falta en la adopción, es fundamental la utilización de mecanismos formales de toma de decisión, de acuerdo con el proceso Gestión de Decisiones DRU2 - La capacidad de reutilización sistemática de la organización es evaluada y acciones correctivas son tomadas, caso necesario Otro factor de gran importancia para el éxito de implantaciones de programas de reutilización es la capacidad de la organización para ejecutar ese programa. Ejemplos de criterios relevantes para evaluación en ese contexto incluyen recursos humanos, financieros, de infraestructura y culturales. Bajo el punto de vista de recursos humanos, personas capacitadas para la ejecución sistemática del programa de reutilización pueden asegurar una mayor efectividad del programa. En relación a recursos financieros, es importante de que la organización esté consciente que el retorno de las inversiones en un programa de reutilización se obtiene a largo plazo. En lo que se refiere a la infraestructura, un programa de reutilización demanda, como cualquier otro proyecto de desarrollo de software, recursos apropiados para su ejecución. Finalmente, aspectos culturales también deben ser MPS.BR Guía de Implementación Parte 5: /37

12 considerados, pues, con la adopción de un programa de reutilización, los equipos pasarán a utilizar activos de dominio construidos y mantenidos por otros equipos dentro de la organización. La evaluación de la capacidad de reutilización sistemática de la organización puede ser apoyada por un proceso de Gestión de Riesgos, donde el objetivo es minimizar los riesgos de fracaso del programa de reutilización a ser implantado. En el caso de que la evaluación de la capacidad de la organización no tenga resultados positivos, la organización debe tomar acciones correctivas buscando crear las condiciones necesarias para la adopción del programa de reutilización. De esta forma, una evaluación negativa de capacidad de reutilización sistemática no justifica la no adopción de un programa de reutilización, pero si la postergación de esa adopción hasta que un nivel adecuado de capacidad sea logrado con la ejecución de las acciones correctivas DRU3 - Un programa de reutilización, incluyendo propósitos, alcance, metas y objetivos, es planificado con la finalidad de atender las necesidades de reutilización de dominios Escenarios donde la organización tiene capacidad de reutilización sistemática y existen dominios con potencial de reutilización son propicios para el éxito de un programa de reutilización. Después de la aplicación de mecanismos formales para la toma de decisión (por ejemplo, por medio del proceso Gestión de Decisiones), en caso de que sea comprobado este escenario, la organización está apta para iniciar un programa de reutilización. Caso contrario, la adopción de un programa de reutilización se debe suspender temporariamente. No obstante, se debe repetir periódicamente la evaluación formal para verificar si se está logrando crear el escenario propicio para la adopción de un programa de reutilización. El programa de reutilización debe establecer el propósito y las metas a ser logradas con la adopción de Reutilización de Software en la organización. Además de eso, para que esas metas puedan ser logradas, una información relevante son los recursos necesarios y disponibles. De esta forma, los elementos comunes en la planificación de un programa de reutilización son: los estados intermediarios a ser logrados durante la implantación; las actividades a ser ejecutadas, juntamente con los procedimientos, el cronograma y los responsables por la ejecución; los recursos disponibles; los indicadores a ser utilizados para la supervisión del programa; y el alcance en que el programa será conducido. Ese alcance puede ser definido en diferentes dimensiones: toda la organización o unidades organizacionales específicas; todos los dominios en que la organización actúa o dominios específicos; para todos los tipos de activos de dominio o para tipos de activos de dominio específicos, etc. Note que tanto las metas como os objetivos orientan y reflejan las condiciones deseadas para mejora del desempeño global de la organización. Mientras que los objetivos son más amplios, las metas son más específicas, siendo más apropiadas para orientar las tomas de decisión y actividades cotidianas de la organización [VILLELA, 2004]. MPS.BR Guía de Implementación Parte 5: /37

13 5.3.4 DRU4 - El programa de reutilización es implantado, supervisado y evaluado El programa de reutilización se debe implantar de acuerdo con lo planificado, como descrito en el DRU3. Además de eso, el programa de reutilización es supervisado llevando en consideración los indicadores previamente planificados. Esa supervisión debe comparar lo planificado con lo realizado. Las no-conformidades detectadas deben ser reportadas, analizadas, evaluadas y tratadas. Finalmente, el programa de reutilización es evaluado periódicamente, con el objetivo de verificar su efectividad y motivar mejoras en su planificación, ejecución e infraestructura disponible DRU5 - Propuestas de reutilización son evaluadas de modo que se asegure que el resultado de la reutilización sea apropiado para la aplicación a la que se destina Siempre que proyectos específicos demanden activos de dominio, esas demandas deben ser encaminadas en la forma de propuestas de reutilización. Las propuestas de reutilización pueden ocurrir tanto en la forma de solicitaciones de reutilización de activos de dominio existentes, como en la forma de solicitaciones para la construcción o adquisición de nuevos activos de dominio. Esas propuestas de reutilización deben ser analizadas, buscando medir el esfuerzo de adaptación de los activos de dominio existentes. En caso de no existir en la biblioteca de activos reutilizables ningún activo de dominio que atienda a la necesidad relatada, el análisis tiene como objetivo medir el esfuerzo para construir el activo de dominio o el costo para adquirir el activo de dominio en el mercado. A partir de los laudos de los análisis, las propuestas de reutilización deben ser evaluadas, buscando asegurar que la reutilización esté alineada con las necesidades y expectativas de la organización. Esa evaluación debe, además de aprobar o no la propuesta de reutilización, indicar cómo la reutilización será viabilizada. O sea, vía adaptación de activos de dominio preexistentes, construcción de nuevos activos de dominio o adquisición de activos de dominio en el mercado. En caso de adaptaciones sobre activos de dominio preexistentes, es de gran importancia mantener la rastreabilidad entre el activo de dominio base de la adaptación y el activo de dominio adaptado DRU6 - Formas de representación para modelos de dominio y arquitecturas de dominio son seleccionadas Para que el conocimiento relacionado con un dominio específico pueda ser difundido por la organización, es importante que notaciones adecuadas de representación de los modelos de dominio y de las arquitecturas de dominio sean adoptadas. Esas notaciones deben ser capaces de representar dominios y familias de aplicaciones en diferentes niveles de abstracción. Para los modelos de dominio, se espera que la notación adoptada sea capaz de representar la frontera entre dominios y capturar características que forman parte de todas las aplicaciones desarrolladas para un dado dominio, características que pueden o no ser de determinadas aplicaciones y características que pueden asumir diferentes formas en diferentes aplicaciones. Además de eso, la notación debe ser MPS.BR Guía de Implementación Parte 5: /37

14 capaz de representar dependencia entre características y exclusión mutua de características. Para las arquitecturas de dominio, se espera que la notación adoptada sea capaz de representar, con respecto al diseño, las restricciones definidas en los modelos de dominio. El objetivo de las arquitecturas de dominio es proporcionar detalles de diseño para familias de aplicaciones que tuvieron sus características analizadas por medio de modelos de dominio. La notación adoptada debe permitir la concretización de las características definidas en los modelos de dominio en una arquitectura que describa la relación entre posibles activos de dominio, incluyendo aspectos tecnológicos y de infraestructura, siempre que sea pertinente DRU7 - Un modelo de dominio es desarrollado y sus límites y relaciones con otros dominios son establecidos y mantenidos. Este modelo debe ser capaz de capturar características, capacidades, conceptos y funciones comunes, variantes, opcionales y obligatorios Para cada dominio en el cual existe un potencial de reutilización, se debe establecer sus fronteras con dominios asociados, de acuerdo con la notación previamente establecida. Esa frontera define claramente el contexto del programa de reutilización y permite identificar dominios asociados, que pueden venir a ser parte del programa de reutilización en el futuro. El modelo de dominio desarrollado debe ser capaz de captar características, capacidades, conceptos y funciones, conforme pertinente. Se debe, también, identificar cuales elementos son comunes, variantes, opcionales u obligatorios. Modelos de dominio deben ser definidos para todos los dominios que están en el alcance del programa de reutilización, de acuerdo con la notación previamente establecida. Esos modelos de dominio producidos, a pesar de situarse en un alto nivel de abstracción, ya deben ser considerados activos reutilizables y colocados en una biblioteca de activos reutilizables. Además de eso, esos modelos de dominio son objeto de un proceso formal de Gestión de Configuración, visto que los activos de dominio construidos a partir de ellos serán utilizados por diferentes proyectos de la organización. Cambios no controlados sobre los modelos de dominio pueden traer graves consecuencias en esos proyectos DRU8 - Una arquitectura de dominio describiendo una familia de aplicaciones para el dominio es desarrollada y mantenida durante todo su ciclo de vida El detalle de los modelos de dominio permite identificar familias de aplicaciones para un dado dominio. Esas familias de aplicaciones deben ser representadas vía arquitectura de dominio utilizando la notación previamente establecida. Esa arquitectura de dominio posibilita identificar cuáles son los activos de dominio y cómo ellos se relacionan. Con el objetivo de percibir su importancia para la organización, se debe analizar cada activo de dominio perteneciente a la arquitectura de dominio. A partir de ese análisis, se debe establecer una priorización para la especificación de los activos de dominio. De forma análoga a los modelos de dominio, la arquitectura de dominio también se debe considerar como un activo reutilizable y se debe colocar en una biblioteca de MPS.BR Guía de Implementación Parte 5: /37

15 activos reutilizables. Para viabilizar la Gestión de Configuración sobre la arquitectura de dominio, es de suma importancia el mantenimiento de la rastreabilidad entre las características existentes en los modelos de dominio y los activos de dominio descritos en la arquitectura de dominio que proporcionan esas características. Así, cambios en los modelos de dominio pueden ser fácilmente propagados para los demás niveles de abstracción DRU9 - Activos del dominio son especificados, adquiridos o desarrollados, y mantenidos durante todo su ciclo de vida Los activos de dominio identificados en la arquitectura de dominio son especificados conforme estrategia definida por la organización, por ejemplo, siguiendo la priorización previamente definida. Esa especificación busca detallar las funcionalidades del activo de dominio, lo que viabilizaría tanto su desarrollo como su adquisición. Con esa especificación detallada, aún siguiendo la priorización definida en la arquitectura de dominio, puede hacerse un análisis de costo x beneficio en relación al desarrollo o adquisición del activo de dominio. Ese análisis, juntamente con La especificación del activo de dominio, servirá de base para la toma de decisión de desarrollo o adquisición. Vale resaltar que, el desarrollo del activo de dominio puede ser acelerado en caso de que proyectos anteriores tengan funcionalidades semejantes a las funcionalidades especificadas para el activo de dominio. En esos casos, procesos de refactoración pueden ser aplicados con la intención de generalizar esas funcionalidades y encapsularlas en el activo de dominio. De modo general, los procesos de ingeniería de la organización son aplicables caso el activo de dominio venga a ser desarrollado. Por otro lado, en caso de que el activo de dominio sea adquirido en el mercado, se debe aplicar el proceso Adquisición. Después de desarrollados o adquiridos en el mercado, los activos de dominio son colocados a disponibilidad en una biblioteca de activos reutilizables. Mecanismos establecidos en la organización son indicados para asegurar que los activos cumplen los requisitos mínimos de calidad deseados y si funcionarán como se pretende que sea en el ambiente de uso. Además de eso, los activos están bajo proceso formal de Gestión de Configuración, que permite la identificación de todos sus casos de utilización para notificación siempre que una nueva versión del activo de dominio sea colocada a disponibilidad en la biblioteca. MPS.BR Guía de Implementación Parte 5: /37

16 6 Gestión de Decisiones (GDE) 6.1 Propósito El propósito del proceso Gestión de Decisiones es analizar posibles decisiones críticas usando un proceso formal, con criterios establecidos, para evaluación de las alternativas identificadas Este proceso se debe aplicar en la toma de decisión relacionada a una cuestión crítica que se juzgue como objeto de un proceso de evaluación formal, pudiendo ocurrir tanto en el ámbito de los proyectos como organizacional. De esa forma, ese proceso es iniciado a cualquier momento a partir de la identificación de una cuestión de este tipo en la ejecución de cualquiera de los procesos del MR-MPS. Un proceso de evaluación formal es un abordaje estructurado para evaluar soluciones alternativas en relación a criterios establecidos para determinar la solución a ser utilizada para resolver un problema. El principal motivo para utilizar este proceso es que él reduce la subjetividad de la decisión y, de esta forma, se tiene una mayor probabilidad de seleccionar una solución que atienda las múltiples demandas de los involucrados. 6.2 Fundamentación teórica La Ingeniería de Software, como diversas áreas de conocimiento, también requiere el uso de técnicas de gestión, pues decisiones necesitan ser tomadas a lo largo de todo el proceso de desarrollo y evolución de los sistemas. Cuestiones como tipos de tecnologías, procesos, recursos y herramientas son fundamentales para el aseguramiento de la calidad de productos y servicios. RUHE [2003a] comenta que la toma de decisiones afecta significativamente a todas las fases del ciclo de vida de un proyecto y que procesos y sistemas de apoyo a la decisión son fundamentales para aumentar la eficiencia, la calidad y la relación costo/beneficio de sistemas. RUHE [2003b] también destaca el hecho de que el apoyo a la toma de decisiones es un nuevo paradigma para organizaciones que buscan un aprendizaje continuo en desarrollo de software, pues: Facilita la estructuración de problemas bajo investigación; Auxilia la comprensión de informaciones necesarias a la toma de decisiones eficientes; Posibilita el acceso a datos que, de otra forma, no estarían disponibles o serian difíciles de ser obtenidos; Genera y evalúa alternativas de soluciones; Prioriza alternativas por medio de modelos explícitos. Según KLEIN [1999] existen dos perspectivas en las cuales los seres humanos toman decisiones: la natural y la racional. En la primera, los decisores están, normalmente, involucrados con problemas u objetivos mal definidos y las decisiones se basan en la experiencia, por la intuición, simulaciones mentales, etc. Ya en la decisión Racional, existe un proceso formal de toma de decisión, o línea de MPS.BR Guía de Implementación Parte 5: /37

17 raciocinio a ser seguida donde paso a paso, el decisor es llevado a lograr el objetivo propuesto por el proceso. Problemas bien definidos son aquellos donde los objetivos, caminos y obstáculos están claros y basados en informaciones confiables. A la vez que, problemas mal definidos son caracterizados por la ausencia de un camino claro que lleve a la solución. Los objetivos bien definidos son aquellos que proporcionan al solucionador una línea clara de acción en su dirección como, por ejemplo, el objetivo de adquirir el producto de menor precio. Ya en los objetivos mal definidos, las metas a ser logradas no son claras. Diversos estudios discuten las ventajas y las desventajas tanto del abordaje natural, como del racional, tales como [SCHANK e OWENS, 1987; KLEIN e WEITZENFELD, 1978; LIPSHITZ e BAR-ILAN, 1996; GIGERENZER e SELTEN, 2002]. A pesar de las controversias existentes entre las perspectivas natural y racional, no hay como negar que informaciones cuantitativas estén en todos los lugares en el mundo de los negocios y la tendencia parece ser: medir y cuantificar todo lo que se pueda. Sin embargo, el problema pasa a ser: qué hacer con esa cantidad masiva de informaciones. Cómo debemos usarlas para auxiliar a los tomadores de decisión a ayudar a las organizaciones a tratar los problemas y las presiones que enfrentan [WISNIEWSKI, 2002]? Aliado a eso, otros factores tienden a llevar el proceso de toma de decisión en el contexto de la Ingeniería de Software hacia la perspectiva racional: La Ingeniería de Software es parte de un contexto financiero y es una actividad económica como cualquier otra, donde, además de los beneficios introducidos por los sistemas, organizaciones buscan ampliar sus lucros, aumentar la expectativa de ganancia futura o minimizar perjuicios en un mercado dinámico, cada vez más competitivo y repleto de incertidumbre. En este sentido, tanto gerentes como técnicos necesitan, en muchos casos, basar y justificar sus decisiones de manera formal [COSTA et al., 2004]; Durante un proceso de desarrollo de software, generalmente hay tiempo suficiente para tomar decisiones basadas en un análisis más detallado, como la sugerida por la perspectiva racional, diferentemente de decisiones que implican riesgo de vida o urgencia absoluta como en el caso de médicos, militares, bomberos y otros profesionales altamente presionados por el tiempo; Permite que el registro de los procesos sea reutilizado en futuras decisiones, facilitando la generación de conocimiento, el aprendizaje organizacional, el perfeccionamiento del proceso y la mejora de los parámetros de decisión; y Modelos de Referencias de Procesos y normas internacionales, tales como el CMMI [SEI, 2010], la ISO/IEC [ISO/IEC, 2008] y la ISO/IEC [ISO/IEC, 2003] - exigen procesos formales de toma de decisión, sea para obtener una certificación o para lograr determinados niveles de madurez y capacitación en procesos de software. MPS.BR Guía de Implementación Parte 5: /37

18 Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones adquirientes, no fueron incluidos comentarios a los resultados esperados. No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios a los resultados esperados. Fábrica de Pruebas (Parte 10) No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios a los resultados esperados. 6.3 Resultados esperados GDE1 - Guías organizacionales para la gestión de decisiones son establecidas y mantenidas El proceso Gestión de Decisiones (GDE) puede ser utilizado para tratar problemas con riesgo medio o alto o que afectan la posibilidad de lograr los objetivos del proyecto, así como cuando el impacto de la decisión envuelve una cantidad determinada del presupuesto, alteración significativa del cronograma o calidad, decisiones técnicas no triviales, etc. Así, él podrá ser usado tanto para problemas técnicos (como la decisión del tipo de arquitectura a ser utilizada) así como para problemas no técnicos (como cuál es el mejor proveedor de un producto). Sin embargo, se debe observar atentamente el hecho de que el costo de ejecutar un proceso de evaluación formal debe ser razonable cuando comparado al impacto de la decisión. Guías organizacionales deben, entonces, ser establecidos y mantenidos conteniendo descripciones de los criterios para inicio obligatorio del proceso Gestión de Decisiones (GDE) en la organización. Sin embargo, diversas otras situaciones no previstas pueden evocar la ejecución del proceso formal de decisión. No existe una lista completa sobre cuando usar un proceso formal de decisión, pues su utilización es extremamente dependiente del tipo de organización, del proyecto o inclusive del producto. Sin embargo, algunos ejemplos de situaciones donde su utilización seria posible incluyen: Definición de componentes; Decisión sobre construir o adquirir un producto; Definición de herramientas; Definición de estrategias de contingencias de riesgos; Priorización de recursos; MPS.BR Guía de Implementación Parte 5: /37

19 Contratación de personal; Plataformas de sistemas. Sin embargo, el proceso formal de decisión puede estar asociado a la ejecución de cualquier otro proceso, sin haber una relación directa entre ellos. Así, si durante el proceso Gestión de Configuración, por ejemplo, hay la necesidad de determinar cuál herramienta CASE será utilizada y, si es necesario formalizar esta decisión, el proceso GDE podrá ser iniciado GDE2 - El problema o cuestión a ser objeto de un proceso formal de toma de decisión es definido El primer paso en el proceso de toma de decisión es definir exactamente cuál es el problema que se desea resolver, pues esta definición es decisiva sobre las posibles soluciones adoptadas. En este sentido, definir un problema erróneamente puede conducir a un camino que no llevará a la solución del problema real. Esta actividad busca asegurar que se pretende resolver el problema correcto. Algunos de los principales puntos a ser observados en la definición de problema son [GOMES et al., 2003]: No confundir un problema con su solución; Formular el problema como pregunta; Describir el problema de forma clara y precisa; Verificar si el problema no tiene base exclusivamente subjetiva; Verificar si el problema es susceptible de solución; Definir el alcance del problema; No concentrar la atención en los síntomas sino más bien en el problema raíz; Listar los objetivos a ser logrados para solucionar el problema; Listar las restricciones y premisas existentes para posibles soluciones GDE3 - Criterios para evaluación de las alternativas de solución son establecidos y mantenidos en orden de importancia, de modo que los criterios más importantes tengan más influencia en la evaluación En muchos casos, más de una variable puede influenciar en la elección de la mejor solución. Esas variables se llaman criterios. De esa forma, los criterios de evaluación deben ser priorizados y/o ponderados para que puedan ser aplicados y la mejor solución pueda ser escogida, así como los parámetros de aceptación de cada criterio. La priorización o la ponderación de los criterios podrá ser hecha por una o más personas. Es interesante que se registre el resultado del trabajo con los motivos que llevaron a la elección de los criterios y su priorización y/o ponderación. Se puede, también, registrar los motivos que llevaron al rechazo de algunos criterios. Para asegurar la objetividad, los criterios escogidos no deben ser tendenciosos, y deben ser escogidos apenas aquellos que colaboran para que el objetivo sea logrado. En la priorización o ponderación de criterios, estos deben ser ordenados de tal forma que el criterio con mayor grado de prioridad sea el que realmente tiene mayor influencia en el proceso de decisión. MPS.BR Guía de Implementación Parte 5: /37

20 Un ejemplo de definición y priorización de criterios sería el caso donde alguien está intentando definir cuál es la mejor impresora a ser adquirida, siendo que los criterios para la selección son la velocidad, la calidad y el costo de impresión, que en este caso, pueden estar priorizados de la siguiente forma: velocidad (20%), calidad (30%) y costo (50%), siendo estos porcentajes los pesos utilizados en la priorización de los criterios GDE4 - Alternativas de solución aceptables para el problema o cuestión son identificadas La identificación de alternativas de solución debe ser realizada de modo que sea posible hacer una buena evaluación y una implementación correcta. Siempre que sea posible, los principales involucrados en el problema deben estar presentes en la ejecución de esta actividad, así como especialistas y personas que serán afectados por el problema o por la(s) solución(es). Una buena práctica para la identificación de las posibles soluciones es realizar un trabajo de grupo o reuniones de brainstorming, así como la búsqueda de datos históricos, donde, además de las alternativas de solución, son levantados los riesgos, problemas, ventajas y desventajas de las referidas alternativas, así como posibles premisas y restricciones para la implementación de una solución. Es importante, en este momento, la evaluación (cuantitativa) de los riesgos de implementación de cada solución, pues caso alguna solución sea considerada inviable, debido a su riesgo, probablemente ésta no deberá ser llevada para la próxima fase del proceso. Esta evaluación considera la probabilidad de ocurrencia, el impacto y si la implementación de esta solución afectará el proceso de desarrollo, el producto final o cualquier otra actividad en alguna fase futura. Se debe levantar el mayor número posible de alternativas de solución y, si, a cualquier momento del proceso formal de decisión, otra alternativa de solución fuese identificada, esta también se deberá registrar GDE5 - Los métodos de evaluación de las alternativas de solución son seleccionados de acuerdo con su viabilidad de aplicación No existe un consenso sobre cuál es el mejor método a ser utilizado en un proceso formal de decisión, pues ellos dependen directamente de varios factores, tales como el nivel de precisión requerido en la respuesta, el tiempo disponible para la toma de decisión, los recursos a ser empleados, el grado de conocimiento del equipo en la aplicación de un método específico, la complejidad del problema, las informaciones disponibles para la toma de decisión, etc. Mientras algunos problemas pueden necesitar del uso de apenas un método de evaluación, otros problemas pueden requerir diversos métodos para determinar cuál es la alternativa de solución que se aplica mejor al problema definido. Se debe dar una atención especial a la capacidad del método en enfocar el problema en cuestión y no ser influenciable por problemas secundarios. Así, los métodos a ser usados para evaluación pueden variar desde una simple reunión a simulaciones, al uso de modelos probabilísticos complejos, llegando al desarrollo de sistemas especialistas para situaciones más específicas. El nivel de detalle, sofisticación o complejidad de un método puede variar de acuerdo con la MPS.BR Guía de Implementación Parte 5: /37

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS Esta guía contiene orientaciones para la implementación del nivel

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS Esta guía contiene orientaciones para la implementación del nivel

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS MPS.BR - Mejora de Proceso del Brasileño Guía de Implementación Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS Esta guía contiene orientaciones para la implementación del nivel D del Modelo

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño. Guía General MPS de Software

MPS.BR - Mejora de Proceso del Software Brasileño. Guía General MPS de Software MPS.BR - Mejora de Proceso del Software Brasileño Guía General MPS de Software Esta guía contiene la descripción general del Modelo MPS y detalla el Modelo de Referencia MPS para Software (MR-MPS-SW) y

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño: resultados logrados y lecciones aprendidas (2004-2008)

MPS.BR - Mejora de Proceso del Software Brasileño: resultados logrados y lecciones aprendidas (2004-2008) l MPS.BR - Mejora de Proceso del Software Brasileño: resultados logrados y lecciones aprendidas (2004-2008) RESUMEN 1. Introducción 2. Modelo MPS 3. Programa MPS.BR: Resultados Esperados x Logrados (2004-2008)

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS Esta guía contiene orientaciones para la implementación del nivel

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

POLÍTICAS DE CALIDAD, SEGURIDAD, MEDIO AMBIENTE Y SALUD DE PETROBRAS CHILE

POLÍTICAS DE CALIDAD, SEGURIDAD, MEDIO AMBIENTE Y SALUD DE PETROBRAS CHILE POLÍTICAS DE CALIDAD, SEGURIDAD, MEDIO AMBIENTE Y SALUD DE PETROBRAS CHILE POLÍTICA DE CALIDAD Petrobras Chile asume el compromiso de suministrar productos y servicios de calidad, con un estilo innovador

Más detalles

En el desarrollo tecnológico se distinguen cuatro fases: planificación, innovación y adaptación, asimilación y optimización.

En el desarrollo tecnológico se distinguen cuatro fases: planificación, innovación y adaptación, asimilación y optimización. TEMA 5: ASIMILACIÓN DE LA TECNOLOGÍA 5.1 Definición de la asimilación de la tecnología La asimilación tecnológica es un proceso de aprovechamiento racional y sistemático del conocimiento por medio del

Más detalles

Project and Portfolio Management [PPM] Sustainable value creation.

Project and Portfolio Management [PPM] Sustainable value creation. Project and Portfolio Management [PPM] Sustainable value creation. SoftExpert Project and Portfolio Management [PPM] Suite es la solución más robusta, funcional y fácil para priorizar, planificar, gestionar

Más detalles

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS-SW:2012

MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS-SW:2012 MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS-SW:2012 Esta guía contiene orientaciones para la implementación

Más detalles

MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN

MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN OBJETIVO GENERAL El alumno analizará, la importancia de brindar productos y servicios con calidad; así como estudiar los fundamentos, autores y corrientes

Más detalles

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras

Más detalles

Presentación de COBIT 5. Alfredo Zayas. ISACA Capítulo Cd. de México

Presentación de COBIT 5. Alfredo Zayas. ISACA Capítulo Cd. de México Presentación de COBIT 5 Alfredo Zayas ISACA Capítulo Cd. de México Legal Notice This product includes COBIT 5, used by permission of ISACA. 2012 ISACA. All rights reserved. COBIT is a registered trademark

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

POLÍTICA DE TECNOLOGÍA DE INFORMACIÓN

POLÍTICA DE TECNOLOGÍA DE INFORMACIÓN TABLA DE CONTENIDO 1. OBJETIVO... 1 2. ALCANCE... 1 3. CONTENIDO DE LA POLÍTICA... 1 3.1 Premisas generales para el cumplimiento de la política... 2 3.2 Contenido de la política... 3 3.2.1 Responsabilidades

Más detalles

Este dominio consta de 7 procesos que se describen a continuación.

Este dominio consta de 7 procesos que se describen a continuación. Dominio: Adquirir e Implementar. Este dominio consta de 7 procesos que se describen a continuación. AI1 Identificar soluciones automatizadas La necesidad de una nueva aplicación o función requiere de análisis

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

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

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

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

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

PERFILES OCUPACIONALES

PERFILES OCUPACIONALES PERFILES OCUPACIONALES A continuación se presenta la relación de los diferentes cargos que un ingeniero de sistemas de la Universidad de Lima puede desempeñar durante su vida profesional. También se presentan

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

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

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

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

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

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

Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Conceptos básicos Qué es un portafolio? Es una colección de proyectos, programas y otras actividades

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

Autoevaluación Institucional con fines de Acreditación. Guía para la elaboración del Plan de Mejoramiento

Autoevaluación Institucional con fines de Acreditación. Guía para la elaboración del Plan de Mejoramiento Autoevaluación Institucional con fines de Acreditación Guía para la elaboración del Plan de Mejoramiento Contenido 1. Introducción... 4 2. Objetivo de la guía... 4 3. Aspectos a considerar... 4 3.1 Autoevaluación...5

Más detalles

RESOLUCIÓN. Por medio de la cual se modifica la resolución No. 511-004064 de 2012 EL SUPERINTENDENTE DE SOCIEDADES,

RESOLUCIÓN. Por medio de la cual se modifica la resolución No. 511-004064 de 2012 EL SUPERINTENDENTE DE SOCIEDADES, RESOLUCIÓN Por medio de la cual se modifica la resolución No. 511-004064 de 2012 EL SUPERINTENDENTE DE SOCIEDADES, En uso de sus atribuciones legales, reglamentarias, y en especial las conferidas por el

Más detalles

MANUAL DE POLITICAS DE RIESGO ESTRATEGICO

MANUAL DE POLITICAS DE RIESGO ESTRATEGICO MANUAL DE POLITICAS DE RIESGO ESTRATEGICO REGISTRO DE CAMBIOS Y REVISIONES Fecha Descripción del cambio o revisión Versión Responsable 26.05.2014 Manual de Políticas de Riesgo Estratégico 1.0 Carlos Zapata

Más detalles

Una estructura conceptual para medir la efectividad de la administración

Una estructura conceptual para medir la efectividad de la administración Una estructura conceptual para medir la efectividad de la administración Tópico especial para gestión del mantenimiento La necesidad de un sistema de medición de la efectividad Mediante el uso de una o

Más detalles

SISTEMA NACIONAL DE CUALIFICACIONES DE FORMACION PROFESIONAL. Regula el Catálogo Nacional de Cualificaciones Profesionales.

SISTEMA NACIONAL DE CUALIFICACIONES DE FORMACION PROFESIONAL. Regula el Catálogo Nacional de Cualificaciones Profesionales. SISTEMA NACIONAL DE CUALIFICACIONES DE FORMACION PROFESIONAL. Regula el Catálogo Nacional de Cualificaciones Profesionales. MINISTERIO PRESIDENCIA BOE 17 septiembre 2003, núm. 223, [pág. 34293] SUMARIO

Más detalles

Guía para implementar mejores prácticas ambientales en organizaciones

Guía para implementar mejores prácticas ambientales en organizaciones Guía para implementar en organizaciones Contenido Presentación... 2 Qué son las Mejores Prácticas Ambientales... 3 Características principales de las MPA... 4 Dimensiones de las Mejores Prácticas Ambientales...

Más detalles

INFORMACIÓN RELACIONADA

INFORMACIÓN RELACIONADA INFORMACIÓN RELACIONADA Solucionar problemas para empresas de la industria del gas y el petróleo Soluciones de gestión de cartera de proyectos Primavera ORACLE ES LA COMPAÑÍA DE INFORMACIÓN Lograr objetivos

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN

LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN Después de realizar la evaluación inicial se han detectado deficiencias en los procesos de reutilización del código, por lo que se van a integrar

Más detalles

PRESENTACIÓN DE LA NORMA ISO-IEC 17025 (NMX-EC-17025)

PRESENTACIÓN DE LA NORMA ISO-IEC 17025 (NMX-EC-17025) PRESENTACIÓN DE LA NORMA ISO-IEC 17025 (NMX-EC-17025) Ing. Erick René Alvarado Ureña Grupo Empresarial ACCE Av. Tecamachalco # 265 Col. Reforma Social México, D.F. Teléfono (01)-5520-9232, Fax (01)-5540-3206

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

PRINCE2 & TickIT. Jorge Armando Medina Morales. Código 1700321660. U n i v e r s i d a d D e C a l d a s. F a c u l t a d D e I n g e n i e r í a s

PRINCE2 & TickIT. Jorge Armando Medina Morales. Código 1700321660. U n i v e r s i d a d D e C a l d a s. F a c u l t a d D e I n g e n i e r í a s PRINCE2 & TickIT Jorge Armando Medina Morales Código 1700321660 U n i v e r s i d a d D e C a l d a s F a c u l t a d D e I n g e n i e r í a s I n g e n i e r í a D e S i s t e m a s O c t u b r e 2010

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

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección

Más detalles

Capítulo 4. ELECCIÓN DE ALTERNATIVAS Y FUNDAMENTACIÓN DE LA SOLUCIÓN ELEGIDA

Capítulo 4. ELECCIÓN DE ALTERNATIVAS Y FUNDAMENTACIÓN DE LA SOLUCIÓN ELEGIDA Capítulo 4. ELECCIÓN DE ALTERNATIVAS Y FUNDAMENTACIÓN DE LA SOLUCIÓN ELEGIDA 19. Consenso a todos los niveles Al término del proceso de revisión de las propuestas de los proveedores, y una vez conocidos

Más detalles

Metodología para la Evaluación del Desempeño del personal de nivel operativo del INIFAP 2013

Metodología para la Evaluación del Desempeño del personal de nivel operativo del INIFAP 2013 Coordinación de Administración y Sistemas Dirección de Desarrollo Humano y Profesionalización Metodología para la Evaluación del Desempeño del personal de nivel operativo Mayo 2013 El contexto general

Más detalles

1.1 Titulo Descriptivo del Proyecto

1.1 Titulo Descriptivo del Proyecto 1.1 Titulo Descriptivo del Proyecto Diseño de un Manual empleando Data Mining (Minería de Datos) para predecir el Potencial de Desarrollo de las empresas en la Zona Oriental asociadas a la Comisión Nacional

Más detalles

COLOMBIA. Nota Técnica: Análisis de Elegibilidad para la Preselección de Proyectos de APP. Noviembre 2010. Diciembre 2010.

COLOMBIA. Nota Técnica: Análisis de Elegibilidad para la Preselección de Proyectos de APP. Noviembre 2010. Diciembre 2010. COLOMBIA Público Privadas en Asociaciones Nota Técnica: Análisis de Elegibilidad para la Preselección de Proyectos de APP Noviembre 2010 Diciembre 2010 TABLA DE CONTENIDO NOTA TÉCNICA: ANÁLISIS DE ELEGIBILIDAD

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

Diseño de un Proyecto IV

Diseño de un Proyecto IV Diseño de un Proyecto IV El diseño del proyecto es el proceso de elaboración de la propuesta de trabajo de acuerdo a pautas y procedimientos sistemáticos como ya se mencionó, un buen diseño debe identificar

Más detalles

SISTEMA DE CONTROL INTERNO PARA LAS ENTIDADES REGIDAS POR LA LEY 87 DE 1993

SISTEMA DE CONTROL INTERNO PARA LAS ENTIDADES REGIDAS POR LA LEY 87 DE 1993 1 SISTEMA DE CONTROL INTERNO PARA LAS ENTIDADES REGIDAS POR LA LEY 87 DE 1993 1. INTRODUCCIÓN 1.1 GENERALIDADES Al Presidente de la República, con sujeción a lo dispuesto en las Leyes 87 de 1993 y 489

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE EVALUACIÓN DE DESEMPEÑO Versión 05 Diciembre 2008 INDICE 1 Definición

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

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

Sin embargo el proceso de gestión de riesgos aplicado a cualquier actividad consta de las siguientes etapas:

Sin embargo el proceso de gestión de riesgos aplicado a cualquier actividad consta de las siguientes etapas: EL PROCESO DE GESTIÓN DE RIESGO La gestión de riesgo se puede definir como el proceso de toma de decisiones en un ambiente de incertidumbre sobre un acción que va a suceder y sobre las consecuencias que

Más detalles

3.1. Concepto de Diseño y Planificación y Concepto de Estrategia Corporativa

3.1. Concepto de Diseño y Planificación y Concepto de Estrategia Corporativa Unidad III Diseño y Planificación de la Estrategia 3.1. Concepto de Diseño y Planificación y Concepto de Estrategia Corporativa Diseño El Diseño Estratégico es una actividad de proyectación, cuyo objeto

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

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo Página 11 5. Estructura del programa de evaluación con personal externo 5.1 Introducción Esta sección presenta la estructura del programa de evaluación con personal externo. Describe las funciones y responsabilidades

Más detalles

MODELO ESTÁNDAR DE CONTROL INTERNO PARA EL ESTADO COLOMBIANO MECI 1000:2005

MODELO ESTÁNDAR DE CONTROL INTERNO PARA EL ESTADO COLOMBIANO MECI 1000:2005 MODELO ESTÁNDAR DE CONTROL INTERNO PARA EL ESTADO COLOMBIANO MECI 1000:2005 SISTEMA DE CONTROL INTERNO PARA LAS ENTIDADES REGIDAS POR LA LEY 87 DE 1993 1. INTRODUCCIÓN 1.1 GENERALIDADES Al Presidente de

Más detalles

NORMAS GENERALES DE AUDITORÍA INTERNA Y DE GESTIÓN COLEGIO DE CONTADORES DE CHILE

NORMAS GENERALES DE AUDITORÍA INTERNA Y DE GESTIÓN COLEGIO DE CONTADORES DE CHILE ENERO 2013 NORMA Nº 4 NORMAS GENERALES DE AUDITORÍA INTERNA Y DE GESTIÓN EMITIDAS POR COLEGIO DE CONTADORES DE CHILE COMISION DE AUDITORÍA INTERNA Y DE GESTIÓN La Comisión de Auditoría Interna y de Gestión

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

BNV Plan Estratégico 2009-2012 VISIÓN, MISIÓN Y VALORES OBJETIVOS ESTRATÉGICOS ÁREAS DE RESULTADO CRÍTICO

BNV Plan Estratégico 2009-2012 VISIÓN, MISIÓN Y VALORES OBJETIVOS ESTRATÉGICOS ÁREAS DE RESULTADO CRÍTICO BNV Plan Estratégico 2009-2012 VISIÓN, MISIÓN Y VALORES OBJETIVOS ESTRATÉGICOS ÁREAS DE RESULTADO CRÍTICO Visión Ser la institución líder en el fomento de la vivienda y la producción, desarrollando instrumentos

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

Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles

Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles Este apartado describirá en qué consiste la gestión de riesgos, cómo se deben escoger los controles, se darán recomendaciones

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

MANUAL PARA PLANIFICAR Y REALIZAR UN PROYECTO

MANUAL PARA PLANIFICAR Y REALIZAR UN PROYECTO MANUAL PARA PLANIFICAR Y REALIZAR UN PROYECTO QUÉ ES PLANIFICAR?: Es elaborar planes con los elementos con que cuenta. Estos planes deberán ser fundamentados, definidos, orientados, evaluados y controlados.

Más detalles

Auditoría que agrega valor

Auditoría que agrega valor International Organization for Standardization International Accreditation Forum Auditoría que agrega valor Que es una auditoría que agrega valor? Escuchamos mucho a cerca de la importancia de agregar

Más detalles

VALORACIÓN, SEGUIMIENTO Y DIFUSIÓN DE ACCIONES DE MEDIACIÓN

VALORACIÓN, SEGUIMIENTO Y DIFUSIÓN DE ACCIONES DE MEDIACIÓN VALORACIÓN, SEGUIMIENTO Y DIFUSIÓN DE ACCIONES DE MEDIACIÓN ÍNDICE DEL MÓDULO FORMATIVO VALORACIÓN, SEGUIMIENTO Y DIFUSIÓN DE ACCIONES DE MEDIACIÓN Procesos de evaluación del programa o servicio de mediación.

Más detalles

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito.

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito. Tomado de: La inteligencia de negocios desde la perspectiva cubana: retos y tendencias. Informe publicado en TodoBI. Autora: MSc. Ivette Marrero Antunez Consultora de inteligencia empresarial. E-mail:

Más detalles

Project and Portfolio Management [PPM] Sustainable value creation. Conocimiento + Experiencia + Imaginación

Project and Portfolio Management [PPM] Sustainable value creation. Conocimiento + Experiencia + Imaginación Project and Portfolio Management [PPM] Sustainable value creation. Conocimiento + Experiencia + Imaginación SoftExpert Project and Portfolio Management [PPM] Suite es la solución más robusta, funcional

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

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

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

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

CAPÍTULO 4 DETERMINACIÓN DE LA ESTRATEGIA DE SOLUCIÓN

CAPÍTULO 4 DETERMINACIÓN DE LA ESTRATEGIA DE SOLUCIÓN CAPÍTULO 4 DETERMINACIÓN DE LA ESTRATEGIA DE SOLUCIÓN En el capítulo dos de este Estudio de Caso, se presentaron una serie de necesidades de la Coordinación de Cómputo Académico (CCA) del Departamento

Más detalles

Evaluación de Gestión, Resultados e Impactos de Programas Públicos

Evaluación de Gestión, Resultados e Impactos de Programas Públicos Curso internacional PLANIFICACION ESTRATÉGICA Y POLÍTICAS PÚBLICAS La Antigua, Guatemala, mayo 2010 Evaluación de Gestión, Resultados e Impactos de Programas Públicos Eduardo Aldunate Experto ILPES/CEPAL

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

Introducción. ISO /IEC 27001: Gestión de la seguridad. Actualización ISO/IEC27001 2005 -> 2013

Introducción. ISO /IEC 27001: Gestión de la seguridad. Actualización ISO/IEC27001 2005 -> 2013 Introducción ISO /IEC 27001: Gestión de la seguridad Desde la publicación inicial de norma internacional ISO/IEC 27001 en el año 2005 el número de implantaciones de los Sistemas para la Gestión de la Seguridad

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

ANEXO 2 Programa de Trabajo. Fecha:

ANEXO 2 Programa de Trabajo. Fecha: ANEXO 2 Programa de Trabajo DEL CONVENIO DE CONCERTACIÓN PARA LA REALIZACIÓN DE LAS ACCIONES DERIVADAS DEL PROGRAMA LIDERAZGO AMBIENTAL PARA LA COMPETITIVIDAD, QUE CELEBRAN POR UNA PARTE EL EJECUTIVO FEDERAL

Más detalles

Al final de este curso usted estará en disposición de:

Al final de este curso usted estará en disposición de: Fundamentos de ITIL 1. Definición El curso de Fundamentos de ITIL introduce el concepto de Gestión de Servicio TI (IT Service Management o ITSM) y un marco para identificar e interrelacionar las diferentes

Más detalles

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA Hospital Nacional de Maternidad UNIDAD DE INFORMATICA 87 Introducción Página: I INTRODUCCION Para el propósito de este manual el Hospital Nacional de Maternidad puede ser referido también como El Hospital,

Más detalles

EQUIPO CONSULTOR Y EQUIPO DE MEJORA CONTINUA PREPARADO POR: REVISADO POR: APROBADO POR: VERSIÓN Nº: 1 FECHA DE EMISIÓN: 05/01/09 VALIDADO POR :

EQUIPO CONSULTOR Y EQUIPO DE MEJORA CONTINUA PREPARADO POR: REVISADO POR: APROBADO POR: VERSIÓN Nº: 1 FECHA DE EMISIÓN: 05/01/09 VALIDADO POR : DE DESARROLLO SOCIAL MINISTERIO DE SALUD Y DESARROLLO SOCIAL DE COSTA RICA - NIVEL INSTITUCIONAL ÁREA DE GESTIÓN: IMPACTO DE LA RECTORÍA SOBRE EL SISTEMA DE PRODUCCIÓN DEL DESARROLLO SOCIAL PREPARADO POR:

Más detalles

Minimice los riesgos para la migración de red del centro de datos

Minimice los riesgos para la migración de red del centro de datos Minimice los riesgos para la migración de red del centro de datos Optimice su arquitectura e inversión de TI y, al mismo tiempo, reduzca la complejidad y los riesgos Los Servicios de migración de centros

Más detalles

PREPARADO POR: FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05

PREPARADO POR: FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05 3. MONITORÍA Y EVALUACIÓN DE LA GESTIÓN SS-UPEG-3 PREPARADO POR: EQUIPO CONSULTOR FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05 VERSIÓN Nº: 1 Secretaría de Salud de Honduras - 2005 PÁGINA 2

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

PERFIL DEL INGENIERO DE SISTEMAS FUSM

PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS DE LA FUSM El perfil del Ingeniero de Sistemas presencial de la Fundación Universitaria San Martín, Bogotá, está en capacidad de modelar

Más detalles

ISO 9001:2015 Estado de la Revisión

ISO 9001:2015 Estado de la Revisión ISO 9001:2015 Estado de la Revisión DQS-UL MSS Argentina S.R.L Ing. Rafael Griffi (Managing Director) 1 Índice de temas Desarrollo general de ISO 9001 Aspectos relativos a la revisión Principales cambios

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

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título 3. OBJETIVOS 3.1. Objetivos Objetivos generales del título De acuerdo con lo establecido en el Libro Blanco y el acuerdo del plenario de la Conferencia de Directores y Decanos de Informática (Zaragoza,

Más detalles

PLM Software. La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes

PLM Software. La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes Siemens PLM Software La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes www.siemens.com/nx I n f o r m e t é c n i c o La

Más detalles

MONITOREO Y EVALUACIÓN

MONITOREO Y EVALUACIÓN Monitoreo y Evaluación de Proyectos Sociales Profesor: Héctor Fuentes C. El monitoreo y evaluación de proyectos es una herramienta de gestión usada para mejorar el desempeño de los proyectos, proveyéndole

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

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

11 Preguntas para su Auditoría del Balanced Scorecard

11 Preguntas para su Auditoría del Balanced Scorecard 11 Preguntas para su Auditoría del Balanced Scorecard 11 Preguntas para su Auditoria del Balanced Scorecard Está encaminado. Solucione algunos asuntos para prevenir problemas a futuro. Algunos problemas

Más detalles

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay Gestión de Proyectos de desarrollo de software Ing. Rafael Bentancur Universidad ORT Uruguay Algunas definiciones Proyecto: emprendimiento temporario que debe crear un producto o servicio único (PMBOK)

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE CAPACITACIÓN Versión 05 Diciembre 2008 INDICE Introducción... 3

Más detalles

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO Programa de Gobierno en Línea Oficina de Coordinación de Investigación, Política y Evaluación. RESUMEN La seguridad de la información

Más detalles

Elección de un Sistema de Remuneraciones y Recursos Humanos. Según su modo de operar.

Elección de un Sistema de Remuneraciones y Recursos Humanos. Según su modo de operar. Elección de un Sistema de Remuneraciones y Recursos Humanos. Según su modo de operar. Introducción En la elección de un sistema de remuneraciones para reemplazar a la modalidad actualmente en uso en la

Más detalles