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

Save this PDF as:
 WORD  PNG  TXT  JPG

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 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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La integración de procesos

La integración de procesos El Grupo TQS ofrece soluciones Servicios avanzadas Profesionales de aplicación práctica gracias a la sinergia entre Consultores de Consultoría especializados en TIe Ingenieros & Ingeniería de Sistemas

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

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

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

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

RECTA FINAL PARA LA ISO 9001:2015

RECTA FINAL PARA LA ISO 9001:2015 23 RECTA FINAL PARA LA ISO 9001:2015 La Norma ISO 9001 afronta la recta final de su revisión, que tiene como objetivos fundamentales facilitar la integración de los distintos sistemas de gestión y adecuarse

Más detalles

ISO 9001:2015 Comprender los cambios clave. Lorri Hunt

ISO 9001:2015 Comprender los cambios clave. Lorri Hunt ISO 9001:2015 Comprender los cambios clave Lorri Hunt Exención de responsabilidad Si bien la información suministrada en esta presentación pretende explicar con precisión la actualización de la ISO 9001,

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

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

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

La evaluación del desempeño del personal es un punto muy delicado, ya que debe ser objetiva y justa para no generar conflictos

La evaluación del desempeño del personal es un punto muy delicado, ya que debe ser objetiva y justa para no generar conflictos Evaluación del desempeño y competencias Jack Fleitman La evaluación del desempeño del personal es un punto muy delicado, ya que debe ser objetiva y justa para no generar conflictos Para que exista un sistema

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

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

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

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

Técnicas de Auditoría BIENVENIDOS XIMENA BECHARA RAMÍREZ CONSULTORA EMPRESARIAL JUNIO 2008 OBJETIVOS DEL CURSO

Técnicas de Auditoría BIENVENIDOS XIMENA BECHARA RAMÍREZ CONSULTORA EMPRESARIAL JUNIO 2008 OBJETIVOS DEL CURSO BIENVENIDOS XIMENA BECHARA RAMÍREZ CONSULTORA EMPRESARIAL JUNIO 2008 OBJETIVOS DEL CURSO Proporcionar el conocimiento necesario de los métodos y técnicas para la preparación de auditoria interna. Desarrollar

Más detalles

Gestión del Servicio de Tecnología de la información

Gestión del Servicio de Tecnología de la información Gestión del Servicio de Tecnología de la información Comentario de la norma ISO 20000 bajo el enfoque de ITIL Autor: Francisco Tejera (ISO 20000 Practitioner) Agenda 1-2-3 INTRODUCCIÓN 4 5 REQUISITOS GENERALES

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

Las normas ISO en su versión actual proveen un sistema de calidad disciplinado que tiene como pilares básicos:

Las normas ISO en su versión actual proveen un sistema de calidad disciplinado que tiene como pilares básicos: LA SERIE DE ESTÁNDARES ISO 9000 Las normas ISO 9000 han cobrado mayor relevancia internacional en la última década y en la actualidad es utilizada en más de 120 países. Estas normas requieren de sistemas

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

Profunda comprensión de que valores son o podrían ser percibidos por los clientes.

Profunda comprensión de que valores son o podrían ser percibidos por los clientes. Estrategias de retención de clientes para servicios El valor concebido por el cliente de servicio se basa en una estrategia de conocimientos, ya que con el conocimiento que posee la empresa, puede emplear

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

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

RESUMEN Y CONCLUSIONES DE OHSAS 18.000

RESUMEN Y CONCLUSIONES DE OHSAS 18.000 RESUMEN Y CONCLUSIONES DE OHSAS 18.000 Durante el segundo semestre de 1999, fue publicada la normativa OHSAS18.000, dando inicio así a la serie de normas internacionales relacionadas con el tema Salud

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

I. Información General del Procedimiento

I. Información General del Procedimiento PR-DGSE-5 Octubre 211 I. Información General del Objetivo: Describir los pasos a seguir para la realización de las al Sistema de Gestión de Calidad de la, del MINERD. Alcance: Este procedimiento aplica

Más detalles

Guía Práctica para el Diseño de Proyectos Sociales

Guía Práctica para el Diseño de Proyectos Sociales Guía Práctica para el Diseño de Proyectos Sociales Marcela Román C. CIDE INTRODUCCION Las Políticas de focalización de la acción social del Estado y, en particular la educativa, están fundamentalmente

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

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

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

NORMA INTERNACIONAL DE AUDITORÍA 265 COMUNICACIÓN DE DEFICIENCIAS EN EL CONTROL INTERNO A LOS ENCARGADOS DEL GOBIERNO CORPORATIVO Y A LA

NORMA INTERNACIONAL DE AUDITORÍA 265 COMUNICACIÓN DE DEFICIENCIAS EN EL CONTROL INTERNO A LOS ENCARGADOS DEL GOBIERNO CORPORATIVO Y A LA NORMA INTERNACIONAL DE AUDITORÍA 265 COMUNICACIÓN DE DEFICIENCIAS EN EL CONTROL INTERNO A LOS ENCARGADOS DEL GOBIERNO CORPORATIVO Y A LA ADMINISTRACIÓN (En vigor para auditorías de estados financieros

Más detalles

Estándares de Información Primaria, Secundaria, Sistemas de Información. Estándares de Macroprocesos, Procesos y Procedimientos Diseñados.

Estándares de Información Primaria, Secundaria, Sistemas de Información. Estándares de Macroprocesos, Procesos y Procedimientos Diseñados. GUÍA 43 Diagnóstico Comunicación Institucional Descripción La comunicación Institucional se da al interior de la entidad y se orienta al cumplimiento de los principios de economía, eficiencia y eficacia,

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

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

nueva ISO 9001 Nuevas necesidades, La revisión de la norma de sistemas ISO/DIS 9001:2014

nueva ISO 9001 Nuevas necesidades, La revisión de la norma de sistemas ISO/DIS 9001:2014 12 /DIS :2014 Nuevas necesidades, nueva Análisis del contexto, gestión del cambio o consideración del riesgo son conceptos que aparecerán en la próxima versión de la. Desde el mes de julio, está disponible

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

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

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

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

Cómo gestionar proyectos en condiciones de riesgo

Cómo gestionar proyectos en condiciones de riesgo 1 de 8 CLAVES PARA EL ÉXITO DE LOS PROYECTOS Cómo gestionar proyectos en condiciones de riesgo Las empresas necesitan desarrollar proyectos que exigen estructuras y tratamientos distintos a los tradicionales.

Más detalles

GLOSARIO DE TERMINOLOGIA SOBRE SISTEMAS DE GESTIÓN DE LA CALIDAD

GLOSARIO DE TERMINOLOGIA SOBRE SISTEMAS DE GESTIÓN DE LA CALIDAD GLOSARIO DE TERMINOLOGIA SOBRE SISTEMAS DE GESTIÓN DE LA CALIDAD Terminología general: 1. Producto: resultado de un proceso. 2. Proceso: conjunto de actividades mutuamente relacionadas o que interactúan,

Más detalles

152. a SESIÓN DEL COMITÉ EJECUTIVO

152. a SESIÓN DEL COMITÉ EJECUTIVO ORGANIZACIÓN PANAMERICANA DE LA SALUD ORGANIZACIÓN MUNDIAL DE LA SALUD 152. a SESIÓN DEL COMITÉ EJECUTIVO Washington, D.C., EUA, del 17 al 21 de junio del 2013 Punto 7.3 del orden del día provisional CE152/INF/3

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS QUITO INGENIERIA MECANICA ADMINISTRACIÓN DE PROYECTOS JUAN MARCELO IBUJES VILLACÍS ADMINISTRACIÓN DE PROYECTOS Contenido tomado de referencia de la Guía de los Fundamentos para la Dirección de Proyectos

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

1. Objetivos: 2. Definiciones y Siglas: NORMA DE INTERCEMENT RESPONSABILIDAD SOCIAL CORPORATIVA NDC DRH 013

1. Objetivos: 2. Definiciones y Siglas: NORMA DE INTERCEMENT RESPONSABILIDAD SOCIAL CORPORATIVA NDC DRH 013 1. Objetivos: Garantizar un estándar único y replicable de acciones y gobierno de Responsabilidad Social Corporativa (RSC) en todas las operaciones de Camargo Corrêa Cimentos, independientemente de la

Más detalles

Ejemplo Manual de la Calidad

Ejemplo Manual de la Calidad Ejemplo Manual de la Calidad www.casproyectos.com ELABORADO POR: REPRESENTANTE DE LA DIRECCION APROBADO POR: GERENTE GENERAL 1. INTRODUCCIÓN Nuestra organización, nació en el año XXXXXXXXX, dedicada a

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

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

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

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M No. REQUISITOS EXISTE ESTADO OBSERVACIONES 4. SISTEMA DE GESTION DE LA CALIDAD 4.1 Requisitos Generales La organización debe establecer, documentar, implementar y mantener un S.G.C y mejorar continuamente

Más detalles

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Hugo F. Arboleda Jiménez. MSc. Docente-Investigador, Facultad de Ingenierías, Universidad de San

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

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

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.2 Elaboración de Ejercicio de Planeación Estratégica, que defina:

1.2 Elaboración de Ejercicio de Planeación Estratégica, que defina: PLAN DE NEGOCIOS I. Definición Documento de análisis con información ordenada para toma de decisiones sobre llevar a la práctica una idea, iniciativa o proyecto de negocio.tiene entre sus características

Más detalles

PROTECCIÓN DEL PATRIMONIO TECNOLÓGICO

PROTECCIÓN DEL PATRIMONIO TECNOLÓGICO PROTECCIÓN DEL PATRIMONIO TECNOLÓGICO Mtra. Mariela Osorio Domínguez El Modelo Nacional de Gestión de Tecnología considera la Protección del Patrimonio Tecnológico como la salvaguarda y cuidado del patrimonio

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

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

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

PE06. RESPONSABILIDAD SOCIAL

PE06. RESPONSABILIDAD SOCIAL Índice 1. Objeto 2. Alcance 3. Referencias/Normativa 4. Definiciones 5. Desarrollo de los procesos 6. Seguimiento y Medición 7. Archivo 8. Responsabilidades 9. Flujograma ANEXOS: No proceden Edición Fecha

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

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

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION. Los sistemas que el analista diseña día a día, la tecnología, las personas, que utilizan el

Más detalles

Como aporta COBIT 5 y gobernanza de TI a la gobernanza empresarial

Como aporta COBIT 5 y gobernanza de TI a la gobernanza empresarial Como aporta COBIT 5 y gobernanza de TI a la gobernanza empresarial Carlos Francavilla Socio ICG LATAM Agenda Qué es Gobierno Corporativo? Un poco de historia El marco COBIT 5 Principios de COBIT 5 Principios

Más detalles

ISO 9001:2008 Resumen de Cambios

ISO 9001:2008 Resumen de Cambios ISO 9001:2008 Resumen de Cambios La revisión de ISO 9001 fue liberada oficialmente el pasado 13 de Noviembre de 2008. Esta es una guía que enfatiza lo que se añadió, elimino y las aclaraciones. Lo que

Más detalles

MINISTERIO DE HACIENDA

MINISTERIO DE HACIENDA SECRETARIA DE ESTADO DE NORMA TECNICA PARA LA EVALUACION DE LA CALIDAD EN LAS AUDITORÍAS Y ACTUACIONES DE CONTROL FINANCIERO SECRETARIA DE ESTADO DE INDICE Página 1. Objeto de la norma 3 2. Organo competente

Más detalles

Guía EMPRESA INTELIGENTE 2.0 para la PYME

Guía EMPRESA INTELIGENTE 2.0 para la PYME Guía EMPRESA INTELIGENTE 2.0 para la PYME Consejos para desarrollar la gestión del cambio, tomar decisiones de manera ágil y eficaz y planificar estrategias atendiendo a los procesos como célula básica

Más detalles

Enfoque del Marco Lógico (EML)

Enfoque del Marco Lógico (EML) Enfoque del Marco Lógico (EML) Qué es el EML? Es una herramienta analítica que se utiliza para la mejorar la planificación y la gestión de proyectos tanto de cooperación al desarrollo como de proyectos

Más detalles

CAPITULO I GENERALIDADES

CAPITULO I GENERALIDADES Proyecto de Ley de Responsabilidad Social Empresaria para la Ciudad Autónoma de Buenos Aires La Legislatura de la Ciudad Autónoma de Buenos Aires sanciona con fuerza de Ley.. CAPITULO I GENERALIDADES Artículo

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

REACU. Red Española de Agencias de Calidad Universitaria RENOVACIÓN DE LA ACREDITACIÓN DE LOS TÍTULOS UNIVERSITARIOS OFICIALES DE GRADO Y MÁSTER

REACU. Red Española de Agencias de Calidad Universitaria RENOVACIÓN DE LA ACREDITACIÓN DE LOS TÍTULOS UNIVERSITARIOS OFICIALES DE GRADO Y MÁSTER REACU Red Española de Agencias de Calidad Universitaria RENOVACIÓN DE LA ACREDITACIÓN DE LOS TÍTULOS UNIVERSITARIOS OFICIALES DE GRADO Y MÁSTER Documento de trabajo Julio de 2011 1 1. PRÓLOGO El presente

Más detalles

CAPÍTULO IV. El Balanced Scorecard

CAPÍTULO IV. El Balanced Scorecard CAPÍTULO IV El Balanced Scorecard Desde hace algún tiempo se ha venido desarrollando un nuevo sistema de gestión estratégico denominado: "Balanced Scorecard". 4.1 Orígenes El Balanced Scorecard fue desarrollado

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

MODELOS DE GESTIÓN DE LA CALIDAD ORIENTADOS A LA CERTIFICACIÓN

MODELOS DE GESTIÓN DE LA CALIDAD ORIENTADOS A LA CERTIFICACIÓN MODELOS DE GESTIÓN DE LA CALIDAD ORIENTADOS A LA CERTIFICACIÓN MODELOS DE GESTIÓN DE LA CALIDAD ORIENTADOS A LA CERTIFICACIÓN NORMAS ISO 9000 : 2000 (CALIDAD) NORMAS ISO 14000 : 1996 (MEDIOAMBIENTE) NORMA

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

CCPA Costa Rica. Como establecer criterios para la evaluación de la Auditoría Interna. Michael Delgado Gerente de Riesgos EY.

CCPA Costa Rica. Como establecer criterios para la evaluación de la Auditoría Interna. Michael Delgado Gerente de Riesgos EY. CCPA Costa Rica Como establecer criterios para la evaluación de la Auditoría Interna Michael Delgado Gerente de Riesgos EY Mayo 2014 Contenido Marco de referencia - Normativa Evaluación del desempeño Aseguramiento

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

Innovación de procesos

Innovación de procesos Innovación de procesos Autor: MC Martín Hernández Valdez Aunque generalmente aceptamos que la innovación es esencial para la sustentabilidad de las organizaciones, y que resulta fundamental para incrementar

Más detalles

La innovación como valor diferencial. Las TIC, vehículo de transformación

La innovación como valor diferencial. Las TIC, vehículo de transformación Perfil corporativo La innovación como valor diferencial Informática El Corte Inglés es una compañía especializada en proveer servicios de consultoría tecnológica, soluciones TIC y outsourcing a grandes

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

LA IMPLANTACIÓN DEL PROCEDIMIENTO DE GESTIÓN DE QUEJAS Y SUGERENCIAS

LA IMPLANTACIÓN DEL PROCEDIMIENTO DE GESTIÓN DE QUEJAS Y SUGERENCIAS Página 1 de 1 Manual Guía para la Implantación del Procedimiento de Gestión de Quejas y Sugerencias Página 2 de 2 ÍNDICE Introducción pag. 3 PARTE I - Objetivos del Procedimiento pag. 4 PARTE II - Fases

Más detalles