GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

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

Download "GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES"

Transcripción

1 GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

2 Tabla de contenido INTRODUCCIÓN AL MODELO... 4 OBJETO DE ESTA GUÍA Proceso de GESTIÓN DEL MODELO DE CICLO DE VIDA Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de SUMINISTRO Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de DEFINICIÓN DE REQUISITOS DE LAS PARTES INTERESADAS Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de ANÁLISIS DE LOS REQUISITOS DEL SISTEMA Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de PLANIFICACIÓN DEL PROYECTO Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME: Observaciones prácticas para la PYME Proceso de EVALUACIÓN Y CONTROL DE PROYECTOS Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME

3 6.4. Observaciones prácticas para la PYME Proceso de GESTIÓN DE LA CONFIGURACIÓN Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de MEDICIÓN Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones Prácticas para la PYME Proceso de ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones Prácticas para la PYME ANEXOS ANEXO 1. AUTOMATIZACIÓN DE LOS PROCESOS ANEXO 2. ESTRUCTURA DOCUMENTAL ANEXO 3. BIBLIOGRAFÍA

4 INTRODUCCIÓN AL MODELO El Modelo de Mejora y Evaluación de la Calidad del Ciclo de Vida del Software elaborado por AENOR acorde a la ISO 15504, tiene como objetivo principal proporcionar a las pequeñas y medianas factorías de software un marco de referencia para la mejora de los procesos de calidad internos relacionados con el desarrollo de software, para su posterior certificación según el referencial conocido como SPICE, en su nivel 2. Los procesos han sido seleccionados de la norma internacional ISO/IEC 12207:2008 Ingeniería de Sistemas y Software. Procesos del ciclo de vida del software y están definidos por y para las empresas o departamentos que desarrollan software. Si por una parte tenemos el marco de los procesos por el otro debemos contar con una norma, también de rango internacional, que establezca los criterios de evaluación de la madurez de las compañías. La norma ISO/IEC SPICE, en su parte número 7 y publicada en noviembre de 2008, permite evaluar por niveles de madurez las organizaciones, a partir de la capacidad de los procesos evaluados (gestión de la configuración, análisis de los requisitos, etc.) y así obtener el certificado de AENOR. En el siguiente gráfico se muestran los procesos de la norma ISO/IEC 12207:2008 que componen el modelo de procesos de AENOR y que serán evaluados según los criterios definidos en la norma ISO/IEC SPICE. 4

5 Gráfico 1: Procesos de la norma ISO/IEC 12207:2008, correspondientes al nivel 2, y que serán evaluados según los criterios definidos en la norma ISO/IEC SPICE. Las normas de referencia mencionadas anteriormente permitirán a las factorías de software mejorar sus procesos internos de desarrollo con independencia del tipo de tecnología existente, el entorno de programación utilizado o la organización jerárquica definida. Llegados a este punto es fundamental establecer una definición única de lo que es un proceso. Un proceso es un conjunto de actividades repetitivas y sistemáticas mediante las cuales se convierten las entradas en salidas, que serán los productos o servicios que reciba el cliente, ya sea este interno o externo. En la práctica, si se pide a un grupo de empleados o técnicos que describan gráficamente las actividades de su empresa, la mayoría de ellos, ya pertenezcan a grandes organizaciones multinacionales o a pequeñas empresas, dibujarían algo similar a un organigrama, con más o menos casillas y niveles, pero tratando siempre de 5

6 mostrar las relaciones jerárquicas entre las diferentes unidades organizativas (zonas, áreas, departamentos, divisiones) de la empresa. Esta representación no permite identificar y mejorar los procesos, ya que no muestra a los clientes ni los productos o servicios que se le ofrecen, ni los flujos de trabajo mediante los que se obtienen dichos productos o servicios o los elementos de control aplicados. 6

7 OBJETO DE ESTA GUÍA En la práctica diaria de las organizaciones no siempre están claramente identificados los procesos de desarrollo del software puesto que, a menudo, se identifican más con las personas o departamentos que con el flujo de las propias actividades. Esta dificultad inicial para identificar los procesos de una organización, provoca conflictos de competencias que inciden poderosamente en la gestión de procesos, poniendo en riesgo el alcanzar los resultados esperados. La solución pasa por identificar los procesos de forma transversal a la organización, trazando la secuencia de las actividades correspondientes sin detenerse en los departamentos o áreas. Solo después se asignarán los responsables de realizar cada una de las actividades. Para ayudar a las organizaciones, esta Guía analizará cada uno de los procesos que componen el modelo, indicando aquellos aspectos que son requeridos por la normativa y aportando la experiencia real adquirida en numerosas PYMES que superaron con éxito la certificación de nivel 2. La Guía tiene un enfoque a procesos por lo que para cada uno de ellos se definirán solo aquellos parámetros que sirvan para su identificación, conteniendo la suficiente información para posibilitar su gestión: Nombre: Identificación del proceso. Objetivo: Propósito o finalidad del proceso. Responsable: Persona encargada de definir y mejorar el contenido del proceso. Actividades: Secuencia, interrelaciones y responsables de las tareas que componen el proceso. Entradas: Los elementos necesarios para poder iniciar el proceso. Salidas: Los resultados del proceso (producto obtenido y registros generados) Recursos: Elementos físicos, humanos o tecnológicos necesarios para poder ejecutar correctamente el proceso. Indicadores u otro mecanismo de control del proceso. 7

8 Gráfico 2: Descripción de los componentes de un proceso. A continuación se definen cada uno de los diez procesos que forman el nivel 2 del Modelo de Calidad de Desarrollo de Software y que se encuentran definidos en la norma de referencia ISO/IEC 12207:2008. Antes de iniciar cualquier definición y análisis de los procesos de desarrollo de software es fundamental recordar que: 1) la norma ISO/IEC 12207:2008 no establece una relación de las actividades o tareas que obligatoriamente hay que realizar, sino que se limita a definir qué se debe conseguir con el proceso correctamente implantado, es lo que se conoce como resultados del proceso o outcomes. Por ejemplo, en el proceso de Suministro, entre otros aspectos, se establece la obligatoriedad de identificar al comprador (cliente) pero deja a criterio de cada empresa cómo hacerlo. Algunas compañías optarán por llevar esta identificación con un fichero individual, otras usarán un ERP y otras aplicaciones de software libre para la gestión comercial. Estas opciones, y cualquier otra, son válidas siempre y cuando permitan la identificación del comprador. 8

9 2) para superar con éxito la auditoría de certificación de nivel 2 según el modelo de evaluación de AENOR, la norma con la que se realiza la evaluación. ISO/IEC 15504, conocida como SPICE requiere que cualquier organización pueda dar evidencia de la implantación efectiva de los procesos, esto es: a. Los procesos se lleven a cabo y se consigan todos sus objetivos determinados. b. Existencia de un compromiso efectivo de la Dirección en el desarrollo, implantación de los procesos, asegurando la asignación adecuada de recursos y velando por la consecución de los objetivos de los procesos. c. Esté definida la gestión de cómo se llevan a cabo los procesos, es decir, que esté documentado el funcionamiento de cada uno de los procesos del modelo en la PYME, sus actividades y tareas, responsables, registros generados d. Se evidencia la existencia de mecanismos sólidos y continuados de medición y seguimiento de los procesos y sus resultados, permitiendo evaluar el cumplimiento con los objetivos determinados. e. El personal de la organización que participa en el diseño o ejecución de los procesos es consciente de la pertinencia e importancia de sus actividades y cómo contribuyen al logro de los objetivos de los procesos. f. Existe una sistemática para la detección, registro y eliminación de las desviaciones en el desempeño de los procesos, previniendo que vuelvan a ocurrir. g. Los elementos de trabajo (plantillas, formatos, documentos, formularios ) están definidos, controlados, versionados y actualizados en caso de ser necesario. La PYME deberá analizar y entender los objetivos y resultados esperados que se detallan en cada uno de los diez procesos del modelo. Posteriormente comparará sus procesos actuales con la normativa, evaluando el grado de cumplimiento existente y definiendo las acciones de mejora necesarias para alcanzar el pleno cumplimiento de 9

10 los procesos en su organización. En la presente guía se propondrá un conjunto de actividades, entradas, salidas y recursos que servirán como punto de partida a una PYME cualquiera para construir cada uno de los diez procesos. Estos deberán aplicarse a los proyectos de desarrollo existentes en la PYME. Lógicamente se trata de una propuesta de mínimos que deberá ser enriquecida y ajustada en función de la realidad de cada PYME. En cualquier caso, todas las propuestas, sugerencias e indicaciones que contiene este documento están basadas en la experiencia real en la implantación en PYMEs españolas de los procesos de desarrollo de software. Es fundamental remarcar que el modelo establece la necesidad de contar con evidencias documentales de todos los procesos ligados a la empresa. Es fundamental entender que cuando se habla de documentar una evidencia las opciones son muchas y variadas y no solo el documento en papel. La organización puede dar evidencia por un conjunto de documentos tales como: manuales de usuario y registros de las aplicaciones informáticas usadas para el desempeño de los procesos, actas de reunión, correos electrónicos, informes, fichas de trabajo, etc. y todos ellos en diferentes soportes: papel, digital, imagen, software o una combinación de éstos. Lo habitual es contar con un documento principal en el que se presenten las actividades de cada proceso y referenciar a aquellos otros documentos, aplicaciones o herramientas que amplían y detallan las tareas concretas. Aunque inicialmente puede ser una carga de trabajo adicional para los responsables de la mejora de los procesos internos, el beneficio a corto plazo es evidente, dado que al establecer procedimientos documentados, estos deberán ser aprobados y verificados por todos los miembros implicados en cada proceso (la redacción de la documentación como tarea colectiva y colaborativa puede ser una labor interesante para depurar y mejorar los procesos). El primer paso para mejorar los procesos pasa, inevitablemente, por su formalización. 10

11 También es interesante tener en cuenta el hecho de que la documentación de los procesos y actividades es un pilar fundamental para la formación interna. Al tener acceso a la documentación, el personal de la empresa toma conciencia de los procesos que deben aplicarse en la producción del software, sirviendo también para que los implicados en otros procesos conozcan actividades que no tienen una relación directa con su trabajo diario, contribuyendo al despliegue del conocimiento a toda la empresa. Otro punto importante es que sirve de base para la capacitación de las nuevas incorporaciones a la plantilla, así como servir de referente y preceptor cuando hay desviaciones entre la práctica diaria y los procesos documentados. El conocimiento deja de residir en la experiencia de unas pocas personas a formar parte de toda la organización. 11

12 1. Proceso de GESTIÓN DEL MODELO DE CICLO DE VIDA Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Realización de Proyectos Organizacionales Objetivo El propósito de este proceso es definir, mantener y asegurar la disponibilidad de políticas, procesos y modelos del ciclo de vida para que sean usados por la organización Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Existen políticas y procedimientos para la gestión y el despliegue de los modelos de ciclo de vida y los procesos. RP2) Se definen las responsabilidades, compromisos y la autoridad necesarios para la gestión del ciclo de vida. RP3) Se definen, mantienen y mejoran los procesos de ciclo de vida, modelos y procedimientos para el uso por la organización. RP4) Se priorizan las mejoras en los procesos. 12

13 Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 1.3 Propuesta de aplicación en la PYME Este proceso es el más genérico de todos los que componen el modelo y no puede igualarse al resto, puesto que es el marco común en el que documenta la secuencia de tareas que deberán realizarse desde el inicio al cierre de los proyectos, los diferentes participantes, responsables, documentación aplicable, y los entregables que serán generados. Este proceso es de aplicación a todas las personas que de una u otra forma participen en alguna de las fases de un proyecto software en aspectos tales como producción de software o gestión del proyecto y tendrá como finalidad determinar, dar a conocer y aplicar la metodología adoptada para dicho proyecto. Este ciclo de vida no podrá responder a todas las casuísticas y tipología de proyectos que normalmente se realizan. Es por eso por lo que el ciclo de vida deberá ajustarse en función de las necesidades, indicando las exclusiones en el ciclo de vida general. No es lo mismo el ciclo de vida asociado a un proyecto que requiere dos meses de trabajo que otro que necesita 10 o más meses. Aunque en ambos proyectos exista una fase de codificación y pruebas, el número y detalle de la documentación generada, los diferentes perfiles intervinientes y herramientas utilizadas puede que no sean los mismos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer una relación ordenada de las fases que son necesarias para producir el software: 13

14 Nombramiento de un responsable o responsables de documentar, mantener y mejorar el ciclo de vida de desarrollo del software en la PYME. Se requiere que la persona asignada tenga una visión global y de conjunto del funcionamiento productivo de la compañía. El responsable asignado procederá a la definición, coordinación y seguimiento de las diferentes etapas y recursos necesarios para el desarrollo del software en el contexto de los requisitos y limitaciones de cada tipología de proyecto. Como resultado de la puesta en práctica del modelo de ciclo de vida, las mejoras identificadas serán priorizadas en función del coste, facilidad de implantación, recursos necesarios, etc. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección/Operaciones: responsable de documentar, mantener y mejorar el ciclo de vida de desarrollo de la compañía Resto de la organización: aplicar las actividades definidas en el documento y notificar posibles mejoras al mismo. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Tipología de proyectos SALIDAS Documento de Ciclo de Vida Organigrama funcional Con relación a los recursos, las organizaciones debería contar, al menos, con los siguientes: 14

15 Plantilla de documento de ciclo de vida. Aplicación de gestión documental o estructura de directorios en la red. Un indicador asociado a este proceso, y sencillo de aplicar, es el número de desviaciones o incumplimientos del ciclo de vida comparado con el número de total de proyectos a los que aplica. 1.4 Observaciones prácticas para la PYME - Este proceso tiene una baja dificultad de implantación. - El proceso documentado de ciclo de vida permite indicar el resto de documentos o procesos que aplican en cada una de las etapas definidas. - La finalidad del Ciclo de Vida del Software es recoger formalmente la secuencia de las actividades o fases que deben de realizarse en un proyecto genérico de la compañía. En cada proyecto se realizará una adecuación del mismo de acuerdo a los requisitos y complejidad del proyecto. Esto es fundamental hacerlo para reducir el riesgo de elaborar un documento demasiado general o tan detallado que pocos proyectos puedan cumplirlo. A modo de ejemplo se muestra un ciclo de vida genérico. - Tanto las Actividades Principales como los Entregables deberán ajustarse a la realidad de la PYME a la tipología de proyectos que apliquen. Por ejemplo, en la etapa 5. Codificación, no todos los proyectos requerirán la realización de pruebas unitarias, de integración y de sistema, pero lo que sí es evidente que se ejecutarán un conjunto de pruebas al código generado. 15

16 Gráfico 3: Ejemplo del Ciclo de Vida de Desarrollo del Software para un proyecto genérico. 16

17 2. Proceso de SUMINISTRO Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Acuerdo Objetivo El propósito de este proceso es proporcionar al cliente un producto o servicio que cumpla con los requisitos acordados. Nota: Se requiere establecer un mecanismo para responder a las peticiones y exigencias de los clientes de la organización, preparar y emitir propuestas, y confirmar la entrega e instalación satisfactorias a través del establecimiento de un contrato/acuerdo relevante Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se identifica el comprador de un producto o servicio. RP2) Se genera una respuesta a la solicitud del comprador. RP3) Se establece un acuerdo entre el comprador y el proveedor para el desarrollo, mantenimiento, operación, embalaje, la entrega e instalación del producto y/o servicio. RP4) Se desarrolla por parte del proveedor un producto y/o servicio que satisfaga los requisitos acordados. 17

18 RP5) El producto y/o servicio es entregado al comprador, de conformidad con los requisitos acordados. RP6) El producto está instalado de conformidad con los requisitos acordados. Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización Propuesta de aplicación en la PYME Desde el punto de vista del ciclo de vida de desarrollo del software, este proceso se centra en los vínculos con el cliente durante el proceso de definición y aprobación de la oferta y al final del ciclo, con la aceptación y aprobación de la entrega del software por parte del cliente. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Atender la solicitud del cliente, identificando los diversos canales y mecanismos que los clientes pueden utilizar. Registrar la oportunidad de negocio en el soporte existente (ficheros, aplicaciones informáticas de gestión comercial, ERPs, etc ) asegurando que permite mantener una identificación único, completa y suficiente de los clientes. Elaboración de la oferta sobre la base de plantillas corporativas. Elaborar la documentación asociada a la oferta en el caso de que fuese necesaria, como por ejemplo, prototipos, pantallazos, contratos 18

19 Presentar y negociar con el cliente la oferta según el canal establecido (correo electrónico, correo ordinario o presencial. Cerrar la oportunidad de negocio, quedando a la espera de la aceptación o rechazo de la oferta por parte del cliente. Registrar modificaciones a la oferta inicial, creando nuevas versiones de la propuesta. Una vez que la producción del software ha finalizado y se han pasado las pruebas oportunas, el equipo de proyecto genera el paquete de entrega para el cliente identificándolo con un código único. Un posible método es asociando el código de proyecto, la fecha de generación del paquete y la versión (x.y.z) del producto a entregar. El equipo de proyecto deposita el paquete de entrega dentro de la carpeta de distribución de paquetes del proyecto. El jefe de proyecto genera el documento de entrega al cliente en el que relaciona todos los elementos que serán proporcionados. Este listado deberá ser coherente con los compromisos adquiridos en la última versión de la oferta aprobada por el cliente. tanto la firma del cliente como la del jefe de proyecto que procede a la entrega. Por último, el jefe de proyecto procede a la entrega formal del producto al cliente y la obtención de la conformidad. Esta entrega formal se suele hacer de forma presencial (en la cual se hace entrega del paquete elaborado y se firma el documento de registro de entrega) o de forma telemática, solicitándose posteriormente un correo electrónico al interlocutor del proyecto del cliente confirmando la aceptación de la entrega. 19

20 Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Desarrollo de negocio/área Comercial: responsable del logro de oportunidades comerciales. Operaciones: responsable de la elaboración de la propuesta y validación del contenido técnico de la misma, así como de recabar la aceptación de la entrega por el cliente. Dirección/Financiero: responsable de validar la forma y el periodo de pago de la propuesta antes y después de la negociación. En todo momento se tratan perfiles dentro de la empresa, no puestos de trabajo concretos, por lo que cuando la PYME no cuenta con una estructura de personal suficiente normalmente se fusionan en un solo perfil las responsabilidades anteriores. Por ejemplo para empresas muy pequeñas es habitual que la Dirección asuma la labor financiera y comercial. Por el contrario, si la PYME cuenta con más personal seguramente las responsabilidades se desplegarán a diferentes personas. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Solicitud de oferta ENTRADAS Peticiones de modificación SALIDAS Registro de la solicitud de oferta Documentos de oferta almacenados Si procede, documentos de acuerdos de confidencialidad almacenados en repositorio del proyecto Registro de solicitudes de revisión de la 20

21 propuesta inicial mediante actas de reunión y/o correos electrónicos. Registro de las revisiones de la oferta mediante la creación de diferentes versiones del documento inicial. Registro de la aceptación de la oferta/propuesta mediante la firma del documento de oferta o correo electrónico indicando el código de oferta. Paquete de entrega al cliente (software, aplicaciones de instalación, documentación, manual de usuario, manual de administrador, manual de configuración ) Registro de entrega y aceptación Con relación a los recursos, es recomendable que las organizaciones cuenten con los siguientes: Plantilla de acta de reunión con cliente. Plantillas de hojas de cálculo con los sumarios ejecutivos que contemplan el análisis de los márgenes de beneficio y las valoraciones técnicas. Plantilla de documento de oferta. Plantilla de recepción y aceptación del producto. Aplicación o ficheros para la gestión comercial. En función de las necesidades la empresa puede fusionar las anteriores plantillas en una sola o, simplemente, no necesitarla. Los indicadores asociados a este proceso podrían ser 1) la tasa de peticiones de cambio de las ofertas, que permitiría identificar carencias en la descripción de los 21

22 servicios y detección de las necesidades de los clientes y 2) el número de entregas no aprobadas por el cliente respecto al número de entregas emitidas, con el fin de evaluar el grado de fiabilidad del desarrollo del software Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una baja dificultad de implantación. - Se debe documentar cómo realiza la empresa la gestión de las ofertas, la gestión de los contratos y la aceptación de la entrega por parte del cliente. - Este proceso tiene una baja dificultad de implantación, dado que las PYMEs en su gran mayoría disponen de una gestión del suministro más o menos evolucionada, contemplando al menos, la existencia de una oferta documentada, en el que se relacionan los elementos a desarrollar y los entregables mínimos esperados por parte del cliente. - Suelen presentarse dificultadas a la hora de documentar cuándo y cómo se generan las evidencias relativas a las peticiones de los clientes y más concretamente las relacionadas con cambios sobre los proyectos ya comenzados. - La entrega del software (con su correspondiente registro de entrega) no implica la aceptación formal por parte del cliente. Solo cuando el producto entregado sea el correcto y cumpla con los requisitos establecidos, se podrá requerir el registro formal de aceptación. En función del cliente y del proyecto que se 22

23 trate, en ocasiones el mismo registro de la entrega es, además, el registro de aceptación. - Para poder definir el proceso de suministro adecuadamente la PYME deberá recopilar las siguientes evidencias objetivas: solicitudes del cliente de nuevos proyectos y de cambios en los proyectos existentes, entregas de las ofertas, entregas del software, aceptación de fin de proyecto, etc. Estas evidencias suelen encontrarse en correos electrónicos, actas, documentos o contratos. - Como se verá en procesos siguientes, se deberá establecer un método formalizado de estimación del esfuerzo necesario para la realización del proyecto y que, aplicando variables económicas, establecerá el precio de los servicios incluidos en la oferta. 23

24 3. Proceso de DEFINICIÓN DE REQUISITOS DE LAS PARTES INTERESADAS Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Técnicos Objetivo El propósito de este proceso es definir los requisitos necesarios para que el sistema pueda proporcionar los servicios necesarios a las partes interesadas (usuarios y otros afectados) en un entorno definido Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se especifican las características requeridas y el contexto de uso de los servicios. RP2) Se definen las restricciones del sistema. RP3) Existe trazabilidad de los requisitos, entre las partes interesadas y sus necesidades. RP4) Se describen las bases para la definición de los requerimientos del sistema. RP5) Se define la base para validar de la conformidad de los servicios. RP6) Existe una base para la negociación y el acuerdo de entrega de los productos o servicios. 24

25 3.3. Propuesta de aplicación en la PYME Desde el punto de vista del ciclo de vida de desarrollo del software, este proceso permitirá identificar, agrupar, procesar y monitorizar las necesidades de los usuarios y clientes a lo largo del ciclo de vida del software, permitiendo establecer las líneas base iniciales y sucesivas de los productos resultantes. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Creación de un documento base que recoja el detalle de todos los requisitos funcionales y no funcionales (seguridad, capacidad, escalabilidad, etc.) que deberá incorporar el software. Este documento suele llamarse Catálogo de Requisitos. Normalmente se realiza la primera versión del Catálogo cuando se ha aprobado la oferta por parte del cliente y constituirá la línea base de requisitos sobre la que se irán incorporando las modificaciones que surjan a lo largo del proyecto. En el Catálogo se registrarán todos los requisitos contenidos en la oferta aprobada más aquellos otros que, aun no siendo solicitados expresamente por el cliente, son fundamentales para poder cumplir con sus expectativas. El Catálogo de Requisitos debe identificar cada requisito de manera independiente y única, de forma que pueda seguirse su traza, inequívocamente, a lo largo del proyecto y, además, se vincule a la prueba(s) correspondiente que permita su validación. Incorporación de requisitos partiendo de la versión inicial del catálogo. La incorporación de requisitos podrá ser de dos tipo: completando el listado, por medio de reuniones (presenciales o a distancia) con el cliente o por medio de peticiones de cambio. En ambos casos, la incorporación de los nuevos requisitos deberá estar documentada y aprobada tanto por la PYME como por el cliente. 25

26 Aceptación del Catálogo de requisitos. Es condición básica contar con la aprobación del documento por parte del cliente dado que en él se recogen los compromisos y expectativas del software que será desarrollado. Lo que no está incluido en el Catálogo de requisitos vigente no será desarrollado por la empresa ni será esperado por el cliente. Esta aceptación deberá estar documentada (correo electrónico, acta de reunión o similar) Elaboración del plan de pruebas. El Jefe de Proyecto y el responsable de Calidad elaborarán los casos de prueba que deberán aplicarse al software antes de su entrega al cliente. En este plan de pruebas se podrán validar requisitos individuales o agrupaciones de requisitos gracias a la trazabilidad entre este documento y el catálogo de requisitos. En algunos casos los clientes pueden solicitar la aprobación del plan de pruebas que utilizará la PYME. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Desarrollo de negocio/área Comercial: responsable del cierre del catálogo de requisitos con el cliente. Operaciones: responsable de definir con detalle el catálogo de todos los requisitos (funcionales y no funcionales) así como participar en el diseño del plan de pruebas. Calidad: responsable de elaborar el plan de pruebas. En todo momento se tratan perfiles dentro de la empresa, no puestos de trabajo concretos, por lo que cuando la PYME no cuenta con una estructura de personal suficiente normalmente se fusionan en un solo perfil las responsabilidades anteriores. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: 26

27 ENTRADAS Oferta aprobada Listado de requisitos funcionales y no funcionales SALIDAS Documento de Catálogo de requisitos Actas/correos electrónicos de las reuniones de toma de requisitos con el cliente Peticiones de modificación de requisitos Registro de la aceptación del catálogo de requisitos por parte del cliente (en ocasiones será la propia oferta aprobada) Documento de Plan de Pruebas Con relación a los recursos, las organizaciones debería contar, al menos, con los siguientes: Plantilla de acta de reunión con cliente. Plantilla de documento de catálogo de requisitos. Plantilla de documento de plan de pruebas. Es posible fusionar en una sola plantilla las correspondientes a catálogo de requisitos y plan de pruebas. En el caso de utilizar una aplicación informática para la gestión de los requisitos o plan de pruebas, no es necesario utilizar plantillas independientes. Un indicador asociado a este proceso podrían ser la tasa de peticiones de cambio de los requisitos respecto a la versión aprobada del Catálogo de requisitos, que permitiría identificar deficiencias en la identificación y definición de requisitos por parte del equipo de proyecto de desarrollo de software. 27

28 2.4. Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - Es práctica habitual en las PYMEs que el contenido de la oferta se utilice como un Catálogo de servicios. Eso no es correcto a menos que el nivel de detalle sea suficiente para el equipo de desarrollo, incluya tanto requisitos funcionales como no funcionales y además, incorpore un mecanismo de identificación único para cada requisito facilitando su trazabilidad a lo largo de todo el proyecto. - Se recomienda elaborar un Catálogo de requisitos único, formalizando las actividades necesarias para su redacción y aprobación por las partes interesadas con el objeto de que sirva como 1) un documento independiente, cuya línea base son los requisitos presentados en la oferta y 2) Base para las pruebas validación a la finalización del proyecto - Una vez que se asume la importancia de formalizar la gestión de los requisitos, las empresas son conscientes de los beneficios de mantener, a lo largo de la vida del proyecto, el catálogo de requisitos de forma independiente a la oferta y generando diferentes versiones a medida que el cliente modifica los requisitos. - En este proceso las empresas deben establecer la diferencia entre requisitos funcionales y no funcionales. Por requisitos funcionales se entiende a aquellos que especifican los criterios que se deben utilizar para juzgar el funcionamiento 28

29 de un sistema, en lugar de un comportamiento específico. En general, los requisitos funcionales definen lo que el sistema debería de hacer, mientras que los requisitos no funcionales verifican cómo un sistema debería de ser. Una buena definición de requerimientos no funcionales es tan importante como los requisitos funcionales. Deben de ser definidos, analizados y trazados. - Cuando el cliente proporcione un documento con los requisitos del proyecto, con formato distinto del Catálogo de Requisitos de la organización, no será preciso realizar la adaptación del mismo, considerándose dicho documento como el catálogo de requisitos base del proyecto. - La trazabilidad entre los requisitos de sistema y de usuario es crítica para una implantación exitosa del proceso. Como se ha expuesto anteriormente este objetivo del proceso exige que los requisitos estén catalogados, priorizados y analizados para conocer sus implicaciones sobre el sistema (librerías, objetos, software...). Este concepto va más allá y también afecta a las pruebas que serán realizadas para validar los requisitos. Dicho de otra forma, gracias a la asignación de una codificación unívoca tanto del requisito como de la prueba, si partimos del Catálogo de Requisitos llegamos al Plan de Pruebas asociado y viceversa. 29

30 4. Proceso de ANÁLISIS DE LOS REQUISITOS DEL SISTEMA Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Técnicos Objetivo El propósito de este proceso es transformar los requisitos en un conjunto adecuado de requisitos técnicos del sistema que guiará el diseño del sistema Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se establece y define un conjunto de requisitos funcionales y no funcionales del sistema que describen el problema a resolver. RP2) Se aplican las técnicas apropiadas para optimizar la solución del proyecto seleccionado. RP3) Los requisitos del sistema son analizados para puedan ser corregidos y probados. RP4) Se comprende el impacto de los requisitos del sistema en el entorno de explotación. RP5) Los requisitos se priorizan, aprueban y actualizan cuando es necesario. RP6) Se establece la consistencia y trazabilidad entre los requisitos del sistema y la línea base de requisitos del cliente. 30

31 RP7) Los cambios en la línea base son evaluados frente al coste, planificación e impacto técnico. RP8) Los requisitos del sistema se comunican a todas las partes interesadas y se colocan en la línea base Propuesta de aplicación en la PYME Los objetivos de este proceso están íntimamente relacionados con los de definición de requisitos de las partes interesadas, por lo que las organizaciones podrán documentar ambos procesos de una forma única o por separado. Se elija uno u otro modelo, sí deberá asegurarse que todos los objetivos de ambos procesos han sido cubiertos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Identificar la solución más óptima. El jefe del proyecto o el analista estudiará los requisitos definidos en la versión vigente del Catálogo, con la finalidad de obtener un conjunto de soluciones adaptables a los requisitos del cliente. El equipo de proyecto evaluará las diferentes soluciones propuestas y elegirá la más óptima bajo los criterios de viabilidad técnica, rentabilidad económica y capacidad de la empresa. Una vez seleccionada la solución óptima se comprobará la precisión de los requisitos y su capacidad para ser probados. Elaborar el documento de análisis funcional de requisitos. Partiendo de una plantilla o de la aplicación informática utilizada para el diseño de desarrollo software y que se deberá mantener vivo el documento incorporando los cambios en los requisitos que vayan apareciendo a lo largo de la vida del proyecto. Este 31

32 documento de análisis será trasladado al equipo de desarrollo para el inicio de la codificación. Gestionar los cambios en los requisitos. Las peticiones de cambio deberán ser incluidas en el documento de análisis siempre y cuando hayan sido evaluados y aprobados por el equipo de proyecto. Toda petición del cliente se realizará a través de algún medio que permita ser registrado (correo electrónico, acta,...). Todo cambio aprobado será comunicado a las partes interesadas (cliente y equipo de proyecto) Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Operaciones: responsable de elaborar y mantener el documento de análisis de requisitos del proyecto. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Catálogo de requisitos SALIDAS Documento de Análisis Funcional de los requisitos Peticiones de modificación de requisitos Actas de reunión para la elaborar el análisis de los requisitos Registro de peticiones de cambio Documento actualizado del catálogo de requisitos (si se han producido cambios) Con relación a los recursos, las organizaciones podrán contar con los siguientes: Plantilla de documento de análisis de requisitos Plantilla de peticiones de cambio. 32

33 Técnicas de entrevistas y reuniones si fuese necesario Técnicas de para la representación de modelos de datos (diagramas Entidad- Relación) si fuese necesario Técnicas de descripción de estructuras de datos si fuese necesario Técnicas de Análisis Orientado a Objetos si fuese necesario Plantilla de actas de reunión Un indicador asociado a este proceso podría ser el número de peticiones de cambio aprobados y que han requerido de la modificación de la oferta o del plan de proyecto en cuanto a plazos de ejecución, recursos y/o presupuesto. Este método de control facilitará a la organización actualizar los riesgos asociados al proyecto de desarrollo de software y tomar las medidas oportunas, como por ejemplo, negociando una ampliación económica a la oferta Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - El análisis de requisitos es realizado, en general, por analistas sin un método, procedimiento o técnica determinado. Este punto no deja de ser siempre un problema en gran parte de las PYMEs dado que normalmente un analista/jefe de proyecto/consultor es el que tiene la responsabilidad y la potestad para evaluar en el análisis si los requisitos impactan de una determinada manera y cómo afecta esto al resto de la empresa. Esta evaluación, aunque haya muchas técnicas en el mercado del software siempre es similar y se basa en la experiencia de dicho perfil, en el histórico de proyectos y en la analogía de cada 33

34 tarea con respecto a una evaluada con anterioridad. Por lo tanto es vital que en el proceso de Suministro se haga una evaluación adecuada de los requisitos, haciendo hincapié en que cuanto mejor esté definido y evaluado el requisito y se consiga la aprobación del cliente, mejor van a ser los resultados y mejor se podrá medir las desviaciones sobre la línea base del proyecto a lo largo de su ciclo de vida. - Para proyectos de pequeña envergadura es muy difícil justificar el coste de elaboración y mantenimiento de un documento completo de análisis, por lo que es habitual que la plantilla utilizada para el análisis funcional de los requisitos tenga campos opcionales. 34

35 5. Proceso de PLANIFICACIÓN DEL PROYECTO Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyectos Objetivo El propósito este proceso es identificar, coordinar y monitorizar las actividades, tareas y recursos necesarios para producir un producto y/o servicio, en el contexto de los requisitos y limitaciones del proyecto Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se ha definido el alcance de los trabajos del proyecto. RP2) Se ha evaluado la viabilidad de la consecución de los objetivos del proyecto con los recursos disponibles y las limitaciones existentes. RP3) Se han estimado y clasificado las tareas y los recursos necesarios para completar el trabajo. RP4) Se han identificado las interfaces entre los elementos en el proyecto, y con otro proyecto y las unidades de organización. RP5) Se han diseñado los planes para la ejecución del proyecto. RP6) Se llevan a la práctica los planes para la ejecución del proyecto. 35

36 Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización Propuesta de aplicación en la PYME: Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para una correcta planificación de los proyectos de desarrollo. A continuación se proponen las siguientes: Definición del ámbito del trabajo y asignación de los recursos más adecuados. El responsable del departamento de producción asigna los recursos que van a formar parte del proyecto. Se recomienda que de esta notificación de responsabilidades se deje evidencia, ya sea a través de correo electrónico, acta de reunión interna o similar. En función del tipo del proyecto del que se trate, la compañía asignará diferentes perfiles (Director de Proyecto, Jefe de Proyecto, Analista Senior ) Dar de alta el proyecto en los sistemas corporativos de gestión. De esta forma se da conformidad al alcance del proyecto y a la asignación de los recursos necesarios. De esta forma los intervinientes podrán ir cargando las horas invertidas en el proyecto. Además se generará en los sistemas de control documental (directorios de red o aplicaciones informáticas) la estructura en la que residirá toda la información del proyecto y que estará formada por documentación, distribuciones, paquetes entregables, etc. Elaboración del Plan de Proyecto. El jefe de proyecto, a partir de una plantilla normalizada, genera la primera versión del documento de plan de proyecto en la que se tendrán en cuenta los recursos existentes, los plazos y compromisos adquiridos con el cliente, así como los condicionantes y riesgos del proyecto. Dado 36

37 que las organizaciones no ejecutan un solo proyecto y que los recursos suelen estar asignados a varios proyectos diferentes, el Jefe de Proyecto deberá tener en cuenta esta disponibilidad de recursos a la hora de planificar. La plantilla normalizada podrá estar en soporte papel, electrónico o ser aplicación informática para la gestión de proyectos. Dado que los planes de proyecto suelen actualizarse con frecuencia, se recomienda no usar el soporte papel. Estimación de esfuerzos. Para una correcta implantación del proceso es fundamental formalizar por escrito las actividades que permiten obtener la estimación del esfuerzo y dedicaciones requeridas para las diferentes tareas reflejadas en el Plan de Proyecto. Lanzamiento del Proyecto. Una vez validada la planificación se recomienda la comunicación al resto de intervinientes, especialmente a los analistas, programadores y testers, de los aspectos críticos del proyecto (datos del cliente, riesgos del proyecto, equipo de trabajo, tareas e hitos principales) Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección/Comercial: responsable de sincronizar las acciones de comunicación con el cliente y de otras acciones comerciales y de marketing. Operaciones: responsable de la gestión y desarrollo del proyecto. Calidad/Testing: responsable de la generación y ejecución del plan de pruebas a partir del listado de requisitos (funcionales y no funcionales) y responsable del aseguramiento del cumplimiento de los procesos de calidad. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: 37

38 ENTRADAS Oferta aprobada Listado de requisitos (funcionales y no funcionales) Listado de proyectos vivos y grado de ocupación del personal SALIDAS Documento de Plan de Proyecto Acta de reunión/correo electrónico asignación responsables de proyecto Acta de reunión/correo electrónico de inicio de proyecto Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Plantilla de documento de plan de proyecto. Un indicador asociado a este proceso y que permite evaluar la eficacia del mismo es el número de incumplimientos de los planes de proyecto vivos comparado con los contenidos y requerimientos establecidos en la plantilla Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - Habitualmente las PYMEs contemplan la definición del alcance y la planificación de los hitos del proyecto como una parte correspondiente al proceso de Suministro, sin embargo, una vez aceptada la propuesta por el cliente no se genera el correspondiente Plan de Proyecto. 38

39 - Tampoco se procede a formalizar internamente los arranques de los proyectos con las personas que participarán en su desarrollo. - El objetivo que condiciona el éxito de la implantación de este proceso es contar con un método documentado para la estimación de esfuerzos (horas o jornadas de dedicación) para cada tarea definida en el Plan de Proyecto. En la realidad el dimensionamiento y cálculo de los proyectos es realizado por personas concretas y en base a su experiencia profesional en proyectos similares, lo que le confiere un alto grado de subjetividad a la duración y coste de los proyectos. Lo ideal sería contar con un histórico de estimaciones pasadas agrupadas por fases del desarrollo, por componente o módulo. En caso contrario la PYME deberá establecer un método de trabajo que le permita, con el paso del tiempo, ir generando un histórico fiable de datos. - Este proceso está íntimamente relacionado con el de Evaluación y Control del Proyecto (que se analizará en el siguiente apartado) y por esa razón se recomienda definir un único proceso documentado que englobe ambos, ganando coherencia y eficiencia. 39

40 6. Proceso de EVALUACIÓN Y CONTROL DE PROYECTOS Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyectos. Este proceso y el anterior Planificación de Proyectos suele fusionarse en uno Objetivo El propósito de este proceso es determinar el estado del proyecto y asegurar que se realiza de acuerdo con los planes y el calendario establecido, presupuestos planificados y cumpliendo con los objetivos técnicos Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) El seguimiento del proyecto es monitorizado y reportado. RP2) Hay seguimiento de las interfaces entre los elementos del proyecto, y con otro proyecto y las unidades de organización. RP3) Cuando los objetivos del proyecto no se consiguen, se toman las acciones necesarias para corregir las desviaciones del plan y para prevenir la recurrencia de los problemas identificados en el proyecto. RP4) Los objetivos del proyecto son alcanzados y registrados. Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 40

41 6.3. Propuesta de aplicación en la PYME Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para un seguimiento y evaluación de la planificación de los proyectos de desarrollo. A continuación se proponen las siguientes: Según las necesidades del proyecto y con la finalidad de controlar la evolución de la planificación, el jefe de proyecto elaborará y emitirá informes o comunicados periódicos de su estado. Estos informes deberán estar accesibles y contener la información más importante (consecución de hitos, grado de avance, desviaciones con relación a las fechas ) permitiendo a otras áreas de la compañía (Dirección, Calidad) o a los clientes estar informados de la evolución. Como resultado del análisis de los informes o comunicados de seguimiento por parte de las áreas de control (Dirección o Calidad) se evaluará si los objetivos del proyecto se han alcanzado o no. En caso de ser necesario se realizarán reuniones de seguimiento tanto internas como con el cliente y se deberá dejar constancia de las conclusiones que impacten en la planificación del proyecto. Si tras el análisis de los informes o comunicados de seguimiento fuese necesario realizar acciones correctivas, el jefe de proyecto tomará las medidas oportunas para eliminar las desviaciones y prevenir su repetición. Del análisis de la información de seguimiento también se podrán identificar problemas a futuro, por lo que se deberán realizar los ajustes necesarios con carácter preventivo. Por ejemplo, si el jefe de proyecto detecta por adelantado la imposibilidad de cumplir con un hito de la planificación, deberá analizar la situación y tomar acciones encaminadas a incorporar nuevos recursos, negociar con el cliente un nuevo calendario, etc. En cualquiera de los casos se deberá generar una nueva versión de la planificación y guardar la que ha quedado obsoleta en el histórico documental. 41

42 Es habitual que el cliente solicite cambios una vez que el proyecto se ha puesto en marcha. Tiendo presente el enorme impacto que pueden tener estas modificaciones el jefe de proyecto siempre deberá evaluar los riesgos que los cambios introducen en el proyecto y ser aprobados, rechazados o aplazados. Como mínimo los cambios aprobados por la jefatura del proyecto deberán quedar por escrito y serán notificados a las partes interesadas (clientes, miembros del equipo de proyecto, comercial ) En el caso de que los cambios introduzcan cambios en la planificación del proyecto, se procederá a emitir y aprobar una nueva versión del mismo. A la finalización del proyecto se debería recabar las impresiones, comentarios y sugerencias de todas las partes interesadas, de forma que se puedan extraer conclusiones de mejora para futuros proyectos. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Operaciones: responsable de la gestión y desarrollo del proyecto. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Plan de Proyecto ENTRADAS Peticiones del cliente SALIDAS Informes de Seguimiento y Control Planes de proyecto actualizados Registro de conclusiones de la reunión de seguimiento del proyecto Informe de cierre del proyecto 42

43 Respecto a los recursos, las organizaciones debería contar, al menos, con los siguientes, tanto de forma individual como agrupada en uno solo: Plantilla de documento de informe de seguimiento y control del proyecto. Plantilla de reunión de seguimiento del proyecto. Plantilla de informe de cierre del proyecto. Existe gran cantidad de indicadores asociado al proceso de seguimiento y control de los proyectos. Se proponen dos que son de fácil aplicación y que proporcionan una información fundamental para el buen éxito de los proyectos. El primero es el número de desviaciones en los hitos del proyecto respecto a la planificación prevista. El segundo es el ratio de horas cargadas por los intervinientes en el proyecto respecto a las horas asignadas. Ambos indicadores proporcionan una valiosa información tanto a la jefatura del proyecto como a la Dirección de la compañía, dado que se trata de una medición de la eficiencia de los proyectos, o lo que es lo mismo, la rentabilidad económica de la empresa Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene un grado de implantación alto. - En general las compañías llevan a cabo un seguimiento no formalizado ni estructurado de los proyectos. Por ejemplo es habitual que se realicen reuniones de seguimiento con el cliente y que en el mejor de los casos se elaboren actas, sin embargo, no se cuenta con método documentado de 43

44 recopilación y análisis de la información de progreso del proyecto, ni de la toma de acciones para la corrección de las posibles desviaciones detectadas. - También es una práctica muy habitual iniciar los proyectos sin haber contemplado todos los aspectos mínimos que son necesarios para asegurar su éxito. Aunque pueda parecer burocrático es importante definir cómo se lleva a cabo la aceptación del plan de proyecto entre los miembros del equipo y con el cliente. De esta forma todas las partes asumen las mismas reglas de juego y conocen los canales establecidos para solicitar y realizar ajustes al proyecto. - De una forma más o menos sofisticada todas las compañías realizan un seguimiento de sus proyectos. Con la implantación de este proceso, aseguramos que el documento del plan de proyecto es la base para monitorizar las actividades, comunicar el estado y tomar decisiones correctivas. El progreso se determina comparando los actuales elementos de trabajo: tareas, horas realizadas, coste y calendario actual, con los estimados en el plan de proyecto. 44

45 7. Proceso de GESTIÓN DE LA CONFIGURACIÓN Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto Objetivo El propósito es este proceso es establecer y mantener la integridad de todos los productos de trabajo identificados de un proyecto o proceso y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se define una estrategia de gestión de configuración. RP2) Se definen los elementos que requieren la gestión de configuración. RP3) Se establecen las líneas base de configuración. RP4) Se controlan los cambios a los elementos bajo configuración. RP5) Se controla la configuración de los entregables. RP6) El estado de los elementos bajo gestión de la configuración está disponible a lo largo de todo el ciclo de vida. RP7) Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 45

46 7.3. Propuesta de aplicación en la PYME El propósito del proceso de Gestión de Configuración es asegurar la disponibilidad de las versiones consolidadas de cualquier documento que forma parte del ciclo de vida del proyecto. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración en los proyectos de desarrollo. A continuación se proponen las siguientes: La definición de una estrategia documentada para la gestión de la configuración en la compañía permitirá establecer qué recursos e infraestructura serán necesarios para realizar un adecuado tratamiento de los elementos que estarán bajo control de configuración. Las opciones más habituales se reducen a dos: generar un directorio de carpetas en la red con permisos de acceso o utilizar una aplicación de gestión de la documentación o de proyectos. En ambos casos se guardarán aquellos elementos que afecten al buen desarrollo del proyecto. Como elemento de seguridad se deberá asegurar la existencia de un método de generación de copias de seguridad mantenimiento básico del repositorio en caso de pérdida o eliminación de cualquiera de los documentos. Identificación de los elementos afectados (no software). En el proceso documentado se establecerán qué elementos estarán bajo control de configuración, como por ejemplo, procedimientos, procesos documentados, guías, manuales, planes, actas, cronogramas, informes, documentos técnicos, etc. La primera versión de estos elementos constituirá la línea base en el proyecto. Cualquier modificación posterior será un cambio en esta línea base. 46

47 Gestión de los elementos. La organización establecerá el flujo de trabajo para el control de estos elementos en sus diferentes estados: elaboración, revisión, aprobación, distribución e histórico. El sistema utilizado (directorios de red o aplicación de gestión documental) deben asegurar: o que siempre será de aplicación la última versión de cada elemento. o que se podrá generar una nueva versión de los documentos, registrando los cambios realizados, los responsables de los cambios y fechas de cambio. o que se puede obtener el estado de los elementos de configuración y los cambios realizados. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable aprobar la documentación de los procesos. Operaciones: responsable de aplicar las políticas de Gestión de configuración, estableciendo las líneas base de la documentación y gestionando los directorios de la red o las herramientas utilizadas para la gestión de la configuración. Calidad: responsable de establecer las políticas de Gestión de configuración y velar por su cumplimiento. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Elementos del proyecto que deben estar bajo control de configuración SALIDAS Repositorio de Líneas base de documentación actualizadas Copias de seguridad del repositorio Respecto a los recursos, las organizaciones debería contar, al menos, con: 47

48 Red corporativa / aplicación de gestión de la documentación, de proyectos o similar. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número de elementos definidos por el proyecto que deben ser configurados respecto al número real de elementos que están bajo control de configuración Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: Este proceso tiene un grado de implantación medio. - Aunque todas las empresas disponen, al menos, de carpetas compartidas en red con permisos para almacenar documentación de los proyectos, no ocurre lo mismo con la existencia de una estrategia documentada para la gestión de la configuración - El concepto Línea Base de la Configuración es muy importante que quede bien fijado en la organización, dado que es el punto de partida, la versión inicial sobre la que se realizarán modificaciones o actualizaciones. - En la formalización del proceso hay que hacer un especial énfasis en la descripción de la estructura de las carpetas compartidas o de la aplicación informática equivalente, la codificación de los documentos y el criterio de nombrado de las diferentes versiones de los documentos 48

49 - Es necesario definir una función dentro de la organización que se responsabilice de la terea de definir, mantener y supervisar las políticas definidas en el proceso de gestión de la configuración. Para alcanzar una sólida madurez en el ciclo de vida de los proyectos es condición obligatoria contar con una gestión estricta de la configuración y que esta requiere asumir un coste de horas asignadas y contar con un registro de su actividad. Aunque este pueda ser el proceso más extraño a la hora de implantarlo en la compañía, la mayoría de los casos ya lo está llevan a cabo en mayor o menor medida por parte de las compañías y que solamente requiere de su documentación, partiendo de los objetivos del proceso. 49

50 8. Proceso de GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Soporte del Software Objetivo El propósito es este proceso es establecer y mantener la integridad de los elementos que forman el producto software de un proceso o proyecto y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se desarrolla una estrategia para la gestión de la configuración del software. RP2) Los elementos generados por los proyectos son definidos, identificados y colocados en la línea base. RP3) Se controlan las modificaciones y las entregas de los productos. RP4) Las modificaciones y entregas están disponibles para las partes interesadas. RP5) Se registra e informa del estado de los productos y sus modificaciones. RP6) Se asegura la integridad y consistencia de los productos. RP7) Se controla el almacenamiento, la manipulación y entrega de los productos. 50

51 8.3. Propuesta de aplicación en la PYME El propósito del proceso de Gestión de Configuración del Software es asegurar la disponibilidad de las versiones consolidadas del software que forma parte del ciclo de vida del proyecto. Está enfocado a garantizar la integridad del código fuente del proyecto, así como para garantizar la correcta reproductibilidad y evolución de las aplicaciones software, tanto durante el desarrollo como en el mantenimiento. La finalidad es la misma que el anterior proceso por lo que es posible establecer un único proceso de gestión de la configuración en el que se incluyan los elementos software y no software. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: La definición de la estrategia documentada para la gestión de la configuración del software en la compañía permitirá establecer qué recursos e infraestructura serán necesarios para realizar un adecuado tratamiento del código fuente que estará bajo control de configuración. La opción más habitual es el uso de una herramienta automatizada para la generación de las versiones del código fuente, ya sea licenciataria o de código abierto. Al igual que ocurría en el proceso de gestión de la configuración, como elemento de seguridad se deberá asegurar la existencia de un método de generación de copias de seguridad mantenimiento básico del repositorio en caso de pérdida o eliminación de cualquiera de los códigos fuente. Identificación de los elementos afectados (software). En el proceso documentado se establecerán qué elementos software estarán bajo control de configuración, como por ejemplo, librerías, scripts, módulos, objetos. La primera 51

52 versión de estos elementos constituirá la línea base en el proyecto. Cualquier modificación posterior será un cambio en esta línea base. Gestión de los elementos software. La organización establecerá el flujo de trabajo para el control de estos elementos en sus diferentes estados: codificación, revisión, validación, check-in / check-out, distribución e histórico. La herramienta utilizada debe asegurar: o que siempre será de aplicación la última versión de cada elemento. o que se podrá generar una nueva versión de los elementos software, registrando los cambios realizados, los responsables de los cambios y fechas de cambio. o que se puede obtener el estado de los elementos de configuración y los cambios realizados. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable aprobar la documentación de los procesos. Operaciones: responsable de aplicar las políticas de Gestión de configuración, estableciendo las líneas base de la documentación y gestionando los directorios de la red o las herramientas utilizadas para la gestión de la configuración. Calidad: responsable de establecer las políticas de Gestión de configuración y velar por su cumplimiento. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Elementos software que deben estar bajo control de configuración SALIDAS Repositorio de Líneas base de los elementos software actualizadas Copias de seguridad del repositorio 52

53 Respecto a los recursos, las organizaciones es altamente recomendable contar los siguientes: Aplicaciones informáticas de gestión de la configuración del software (propias, comerciales o de código abierto). En el caso de no contar con una aplicación de gestión automática de versiones del software consultar el Anexo I de la presente Guía. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número de elementos software con su historial de modificaciones respecto al número total de elementos software configurado. Este control tiene mucho valor tanto para el responsable de validar el correcto estado de los elementos en la herramienta de gestión de la configuración como para el jefe de proyecto que le permite contar con una traza de todos los elementos que han sido modificados, antes de proceder a su entrega al cliente Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene un grado de implantación medio-alto. - Se debe documentar la estrategia de gestión de la configuración, líneas base, estrategia de ramas, nombrado de versiones, ramas de estabilización, control de accesos, herramientas de gestión de la configuración, disponibilidad, etc. 53

54 - Es necesario elaborar informes de gestión de la configuración donde se comunique el estado de los elementos de configuración y sus modificaciones. - Aunque pueda sorprender aún existen PYMEs sin ningún tipo de formalización por escrito de la gestión de la configuración del software. - Las compañías que implantan eficazmente este proceso han formalizado documentalmente la estrategia de gestión de la configuración del software mediante la definición de políticas de versiones del software y de seguimiento de errores. - Hay ciertas dificultades en implantar correctamente este proceso dado la incorporación de una herramienta de control de versiones del software obliga a modificar la forma de trabajar de los equipos de producción. - Por la misma razón suele haber resistencias internas en las organizaciones a la hora de implantar y utilizar alguna herramienta automatizada de seguimiento de errores de programación en el código fuente. 54

55 9. Proceso de MEDICIÓN Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto Objetivo El propósito es este proceso es recoger, analizar e informar sobre los datos relativos a los productos desarrollados y procesos implantados dentro de la organización, para apoyar una gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP) RP1) Se identifican las necesidades de información de los procesos técnicos y de gestión. RP2) Se identifican y/o desarrollan un conjunto de medidas, motivadas por las necesidades de información. RP3) Se identifican y planifican las actividades de medición. RP4) Los datos requeridos son recogidos, almacenados, analizados y los resultados se interpretan. RP5) La información de los productos se utiliza para apoyar la toma de decisiones y proporcionar una base objetiva para la comunicación. 55

56 RP6) Se evalúa el proceso de medición y las medidas. RP7) Las mejoras se comunican al responsable del Proceso de Medición 9.3. Propuesta de aplicación en la PYME El propósito del proceso de Medición es recolectar y analizar datos relacionados con los productos, procesos y proyectos implementados en la organización, con la intención de soportar una gestión eficiente de los procesos, demostrar la calidad de los productos objetivamente y dotar a los responsables de información fiable y objetiva para la toma de decisiones. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: Determinar las necesidades de información de los procesos y las medidas relacionadas. Al menos una vez al año se deberían establecer los objetivos de negocio que condicionará el funcionamiento de la organización. Estos objetivos pueden estar orientados a mejorar la productividad o la rentabilidad de los proyectos, reducir las horas dedicadas a corregir errores de programación, simplificar los métodos de trabajo En función de los objetivos de negocio definidos, se identificarán las métricas más viables a obtener durante la operación de los procesos del modelo. La obtención de las medidas se realizará según los intervalos establecidos (anualmente, a la finalización del proyecto, mensualmente ) La periodicidad de obtención se establecerá pensando en cada métrica y se registran en alguna herramienta que facilite su posterior análisis y tratamiento (hojas de cálculo, herramientas de gestión de indicadores. Los diferentes responsables implicados 56

57 obtendrán sus métricas asignadas y las remitirán a un último responsable que será el encargado de consolidarlas. El responsable de generar informe de medición de los procesos y los proyectos se basará en las métricas obtenidas, realizará una consolidación coherente de las mismas y remitirá sus conclusiones a los máximos responsables de la organización. Por último, la dirección y otros responsables implicados, realizan un análisis de los resultados obtenidos en los proyectos y procesos y extraerá conclusiones acerca de la información obtenida y se llevarán a cabo las acciones correctivas o preventivas que se consideren necesarias. Además se evaluará la validez de las medidas utilizadas, con la finalidad de comprobar que son las adecuadas para la valoración tanto estratégica como operativa de los procesos del ciclo de vida. Las conclusiones se registran en un acta de reunión o similar y se distribuye a las personas implicadas. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable de aprobar y revisar los objetivos y métricas asociadas. Operaciones: obtener, según los plazos establecidos, las métricas de los proyectos. Calidad: responsable de consolidar las métricas, realizar el análisis de tendencias y proponer posibles mejora en las métricas y procesos. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Objetivos de negocio y necesidades de SALIDAS Valores de las métricas información 57

58 Informe de interpretación de los resultados de las métricas Acta o similar de la revisión por la Dirección de los resultados Registro de notificación de las mejoras Acciones correctoras o preventivas Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Hola de cálculo, plantilla o software con la información consolidada de las métricas de los procesos y proyectos. Plantilla del Informe o Resumen de interpretación de los resultados de las métricas. Estas dos plantillas pueden fusionarse en una sola de modo que en una única plantilla se realice la recogida de métricas y se formalice las conclusiones que se deriven de su análisis. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número métricas que son modificadas o eliminadas después de la revisión por la dirección de los resultados obtenidos. Este elemento de control permite al responsable de este proceso de medición evaluar la calidad de las métricas Observaciones Prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: 58

59 - La implantación efectiva de este proceso se ha demostrado que tiene una dificultad alta. - Este es el apartado más débil de todas las PYME que, aunque suele recoger algunos datos mediante herramientas como el parte de horas o el seguimiento de incidencias y errores, estos datos no se analizan formalmente ni se genera ningún tipo de informe para ayudar a la toma de decisiones. - En este proceso se deben establecer métricas no solo para el ciclo de vida de los proyectos sino también para los diez procesos que componen el presente modelo de mejora. - Llevar a cabo una gestión de las métricas alineadas y son coherentes con los objetivos de la organización. Este es el punto que nos asegura que la PYME ha definido una estrategia de medición que le permitirá evaluar el grado de cumplimiento de los procesos desde una perspectiva de negocio. Aquí reside la dificultad de la implantación del proceso ya que: o supone una automatización o manual de la recopilación de datos, o requiere una sistemática en análisis de los resultados obtenidos, o necesita de la colaboración y concienciación de los empleados en las tareas de ingreso de métricas. - Las PYMEs que han implantado este proceso han identificado, al menos, las siguientes métricas. Medidas de rentabilidad de proyectos: o Número de horas ofertadas en los documentos de oferta. o Número de horas estimadas pendientes de ejecutar. o Número de horas dedicadas e imputadas semanalmente/mensualmente por todos los integrantes de los equipos asignados. 59

60 Medidas de incidencias en los proyectos: o Número total de incidencias detectadas en los proyectos y anotadas en la herramienta/hoja de cálculo de control de cambios. o Número de incidencias resueltas en los proyectos y anotadas en la herramienta/hoja de cálculo de control de cambios. Medidas de Calidad: o Número de elementos del catálogo de requisitos de los proyectos. o No conformidades internas en las pruebas de aceptación de los proyectos. o Desviación entre la fecha de entrega real y la fecha de entrega planificada. o No conformidades detectadas en las pruebas de aceptación de los proyectos. Medidas de la eficacia de los procesos: o No conformidades detectadas en las evaluaciones y auditoría de los procesos. Se evalúa la conformidad de las actividades y productos con relación los procesos, planes de proyecto y normas de referencia. o Peticiones o sugerencias de mejora a los procesos. - Y por último, sin medición y análisis de los procesos, no es posible mejorar la organización. 60

61 10. Proceso de ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Soporte del Software Objetivo El propósito es este proceso es establecer y mantener la integridad de los elementos que forman el producto software de un proceso o proyecto y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se ha desarrollado una estrategia para la realización del aseguramiento de la calidad. RP2) Se generan y se guardan las evidencias del aseguramiento de la calidad del software. RP3) Se identifican y registran los problemas y/o no conformidades con los requisitos. RP4) Se verifica la coherencia entre los productos, procesos y actividades con los estándares, procedimientos y requisitos aplicables. 61

62 10.3. Propuesta de aplicación en la PYME El proceso de Aseguramiento de Calidad tiene como objetivo asegurar a los clientes (tanto internos, como externos), la entrega de productos de la calidad acordada, proporcionando visibilidad a la línea jerárquica de la organización sobre los procesos seguidos para el desarrollo de los proyectos y los productos intermedios y finales obtenidos. El proceso define un modelo sistemático y planificado que permite garantizar que las actividades y productos son conformes a los estándares, procedimientos, planes de proyecto y normas de referencia. Además proporciona un mecanismo de obtención de información para mejorar los procesos que están siendo aplicados en los proyectos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: Determinar la estrategia para la realización del aseguramiento de la calidad. El proceso de Aseguramiento de la Calidad abarca las actividades de planificación y ejecución de controles, revisiones para garantizar el cumplimiento de la organización con los procesos definidos, así como la calidad final de los productos realizados. De esta actividad se podrá derivar un conjunto de No Conformidades (incumplimientos) que deberán ser resueltas por medio de la planificación, análisis y cierre de acciones correctivas), comunicando además los resultados obtenidos, a los implicados dentro de la organización o a los clientes, que así lo soliciten. Además de acciones correctivas se podrán crear acciones preventivas que permitirán eliminar la causa de una potencial no conformidad. La política es pública y se pone en conocimiento de toda la organización. 62

63 Revisiones de calidad de los proyectos, herramientas y plantillas de trabajo. Las revisiones de Calidad tienen el objetivo de asegurar que los productos (entendiendo producto como herramientas y plantillas de trabajo) y procesos planificados para los proyectos son implementados conforme a los estándares establecidos. En esta actividad se contempla tanto los pasos para la realización de dichas revisiones, como la identificación de las No Conformidades derivadas: Establecimiento de la agenda de revisiones: las revisiones abarcan tanto a los proyectos (el calendario de las revisiones estarán definidas en el Plan de Proyecto correspondientes) como a los procesos (su planificación estará definida anualmente). Realización de las revisiones de calidad, por medio de listas de verificación u otra herramienta similar. Identificación de problemas o no conformidades: se buscarán evidencias del correcto o incorrecto uso de los procesos de la organización en los proyectos. Las revisiones repasarán el ciclo de vida aplicable al proyecto. Se documentarán tanto las pruebas realizadas como los resultados obtenidos y en el caso de que se detecten no conformidades, se abrirán acciones correctivas. En la gestión de las acciones correctivas se procurará hacer partícipe a las personas más adecuadas y con mayor conocimiento sobre la materia para su pronta resolución. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable de generar y aprobar las políticas generales de aseguramiento de calidad y aplicar las acciones correctoras basadas en las tareas de auditoría llevadas a cabo por el Responsable de Calidad.. Operaciones: los Jefes de Proyecto y resto de miembros del equipo son responsables de aplicar la última versión de los procesos documentados que 63

64 han sido elaborados por la compañía, velando por su correcta aplicación y notificando al área de calidad cualquier desviación, incoherencia o incumplimiento que detecten. Calidad: responsable del aseguramiento del cumplimiento de los procesos y requerimientos de calidad, así como de realizar las auditorías y controles para el aseguramiento de la calidad en cada proyecto, en función de las políticas y actividades implantadas en la organización. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Planes de Proyectos ENTRADAS SALIDAS Listas de verificación o similar completadas Calendario de revisiones de calidad Registro de No Conformidades y Acciones Correctoras Comunicación de la resolución de las No Conformidades Nuevas versiones de los documentos de los procesos (si fuese necesario realizar una actualización) Informe de resultados de las revisiones de calidad Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Plantilla registro de no conformidades y acciones correctivas. Plantilla de informe de los resultados de las revisiones de calidad. Listas de verificación u otro similar para la comprobación de los requisitos definidos por la organización para sus proyectos y procesos. 64

65 Para controlar si este proceso se está ejecutando correctamente se puede aplicar el siguiente conjunto de indicadores que permiten evaluar la eficacia del proceso de aseguramiento de la calidad: Revisiones de Calidad realizadas: Número de revisiones realizadas por el equipo de Calidad en los proyectos. Número de NC detectadas: Número de No Conformidades detectadas en un proyecto. % Acciones correctoras fuera de plazo: Porcentaje de Acciones Correctoras realizadas fuera de plazo. Esfuerzo en Actividades de Calidad: Esfuerzo total incurrido en la realización de las actividades de calidad del proyecto. % Esfuerzo Calidad vs. Esfuerzo total del Proyecto: Esfuerzo dedicado a las actividades de calidad, respecto del esfuerzo global del proyecto Observaciones Prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - La implantación efectiva de este proceso se ha demostrado que tiene una dificultad alta. - A pesar de que las compañías entienden la importancia que tiene un proceso estructurado y sistemático orientado al aseguramiento de la calidad, carecen de una estrategia formal de aseguramiento de la Calidad del Software. 65

66 - Tener un proceso de aseguramiento de calidad conlleva, inevitablemente, la existencia de un perfil de responsable de calidad (a tiempo completo o parcial) y una revisión continua y planificada de procesos y proyectos. Dado que el proceso requiere de un perfil especializado, no todas las compañías cuentan en su organización y lo que se hace es asignar esta tarea a otro perfil (jefe de proyecto, programador, analista ) con lo que se pierde eficiencia a medio a largo plazo dado que se manifiestan diversos problemas como injerencia de tareas, priorización de otras tareas, falta de visión global del ciclo de vida del desarrollo, etc. Aunque las factorías de software tengan aspectos en común no son, ni mucho menos iguales, por lo que el grado de automatización será diferente y la cultura de gestión de los procesos internos diferirá. En el siguiente gráfico se muestra el grado de dificultad en la implantación de cada uno de los procesos en base a la experiencia real en PYMEs. 66

67 Gráfico 4: Grado de dificultad en la implantación de los procesos. 67

68 ANEXOS ANEXO 1. AUTOMATIZACIÓN DE LOS PROCESOS Como se ha ido perfilando a lo largo de esta guía cuanto más automatizado está el proceso de gestión y más herramientas de software se utilizan, mejor se adaptan los procedimientos internos a los procesos necesarios para poder alcanzar el nivel de madurez necesario. Por lo tanto, primera lección: las empresas deben orientar sus esfuerzos al uso de software para la gestión de sus procesos de desarrollo de software. La prioridad y los plazos deberán siempre estar determinados por las necesidades de la organización. Las herramientas más prioritarias son aquellas que inciden en los procesos nucleares del modelo: Herramienta de control de versiones Herramienta de control de acceso a la documentación Herramienta de control de errores / requisitos Herramienta de control y agrupamiento de métricas (partes de hora, etc.) Herramientas de seguimiento de incidencias (similar a la de errores, pero para la trazabilidad de requisitos y variaciones de la línea base) Herramienta de log de actividades (principalmente para gestión de la configuración) Sin menoscabo de otras herramientas sujetas a licencia tan válidas como cualquier otra, en la siguiente tabla se muestran soluciones de código abierto. Se han utilizado los siguientes criterios: Funcionalidades, Facilidad de integración con otras aplicaciones, facilidad de uso y puesta en producción. 68

69 Gráfico 5: Listado de aplicaciones de soporte a los procesos. Esta relación de aplicaciones no es única y puede ampliarse con otras existentes en el mercado. 69

70 ANEXO 2. ESTRUCTURA DOCUMENTAL El siguiente diagrama muestra la jerarquía documental habitual que se genera cuando se diseñan, documentan e implantan los diez procesos. Esta representación es solo una propuesta y cada empresa puede establecer su estructura y tipología de documentos como considere más oportuno: Gráfico 6: Ejemplo de estructura documental. Estos documentos son; - Política de Calidad de Desarrollo de Software Documento estratégico de la compañía que define los principios básicos que rigen la calidad de desarrollo de software - Políticas Organizativas 70

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

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

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

elastic PROJECTS INFORMACIÓN COMERCIAL PROJECTS

elastic PROJECTS INFORMACIÓN COMERCIAL PROJECTS PROJECTS elastic PROJECTS INFORMACIÓN COMERCIAL Inscripción Registro Mercantil de Pontevedra, Tomo 3116, Libro 3116, Folio 30, Hoja PO-38276 C.I.F.: B-36.499.960 contact@imatia.com 1 INTRODUCCIÓN Mediante

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

RECOMENDACIONES PARA EL DESARROLLO DE UNA PROCEMIENTO PARA LA GESTIÓN DE PROYECTOS

RECOMENDACIONES PARA EL DESARROLLO DE UNA PROCEMIENTO PARA LA GESTIÓN DE PROYECTOS CENTRO DE EXCELENCIA DE SOFTWARE LIBRE DE CASTILLA-LA MANCHA JUNTA DE COMUNIDADES DE CASTILLA LA MANCHA. RECOMENDACIONES PARA EL DESARROLLO DE UNA PROCEMIENTO PARA LA GESTIÓN DE PROYECTOS Autor del documento:

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

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

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

Aseguramiento de la Calidad

Aseguramiento de la Calidad ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-CAL 1: IDENTIFICACIÓN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA... 3 Tarea EVS-CAL 1.1: Constitución del Equipo

Más detalles

INICIO PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL CIERRE. Etapas de un proyecto. Conoce las 5 etapas por las que todo proyecto debe pasar.

INICIO PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL CIERRE. Etapas de un proyecto. Conoce las 5 etapas por las que todo proyecto debe pasar. 1 2 Etapas de un proyecto Conoce las 5 etapas por las que todo proyecto debe pasar. Etapas de un proyecto Todo lo que debes saber INICIO para gestionarlas de manera eficiente PLANIFICACIÓN 3 4 5 EJECUCIÓN

Más detalles

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

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

Más detalles

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 ISO 9001 CUATRO CAPÍTULOS BÁSICOS RESPONSABILIDADES DE LA DIRECCIÓN P D GESTIÓN DE RECURSOS REALIZACIÓN DEL PRODUCTO A C MEDICIÓN

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

PROCEDIMIENTO DE GESTIÓN DE ENTREGAS

PROCEDIMIENTO DE GESTIÓN DE ENTREGAS Página 1 de 16 PROCEDIMIENTO DE GESTIÓN DE ENTREGAS Rev. Fecha Descripción 01 09/03/2007 Primera versión del documento 02 22/09/2009 Actualización de logos y contenido en general 03 20/06/2010 Actualización

Más detalles

PROCEDIMIENTO DE AUDITORÍA INTERNA DE LA CALIDAD SGC.AIC

PROCEDIMIENTO DE AUDITORÍA INTERNA DE LA CALIDAD SGC.AIC DE AUDITORÍA INTERNA DE LA CALIDAD SGC.AIC Elaborado por Revisado por Aprobado por Nombre Cargo Fecha Firma Macarena Guzmán Cornejo Paulina Fernández Pérez Jimena Moreno Hernández Analista de Planificación

Más detalles

Mtro. Carlos Eugenio Ruíz Hernández Rector. Dr. José Radamed Vidal Alegría Secretario Académico

Mtro. Carlos Eugenio Ruíz Hernández Rector. Dr. José Radamed Vidal Alegría Secretario Académico Con fundamento en la Ley Orgánica de la Universidad Autónoma de Chiapas (Artículo 4 Fracción I, Artículo 18, Fracción III y V, Artículo 25, Fracción XIV), se expide el presente documento, el cual tiene

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

cumple y hay evidencias objetivas

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

Más detalles

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

Nota de Información al cliente ISO 9001 Proceso de auditoría

Nota de Información al cliente ISO 9001 Proceso de auditoría Nota de Información al cliente ISO 9001 Proceso de auditoría La presente Nota de Información al Cliente explica las principales fases del proceso de certificación y auditoría de Sistemas de Gestión de

Más detalles

PROPUESTA PARA LA IMPLANTACIÓN DE LA NORMA UNE- ISO 20000EN EL GRUPO TECNOCOM

PROPUESTA PARA LA IMPLANTACIÓN DE LA NORMA UNE- ISO 20000EN EL GRUPO TECNOCOM PROPUESTA PARA LA IMPLANTACIÓN DE LA NORMA UNE- ISO 20000EN EL GRUPO TECNOCOM Eduardo Álvarez, Raúl Blanco, Evelyn Familia y Marta Hernández. Pertenece el sector de la TI Es una de las cinco mayores compañías

Más detalles

El sistema ISO 9000 (1)

El sistema ISO 9000 (1) El sistema ISO 9000 (1) Orígenes Nace en la Unión Europea Organización internacional de normalización (Ginebra) La OIN se lo encarga al Comité 176 (1979) 1ª edición dela Norma ISO 9000 en 1987 En la actualidad

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

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

Sistemas de gestión de la calidad Requisitos

Sistemas de gestión de la calidad Requisitos Sistemas de gestión de la calidad Requisitos 1 Objeto y campo de aplicación 1.1 Generalidades Esta Norma Internacional especifica los requisitos para un sistema de gestión de la calidad, cuando una organización

Más detalles

ISO 17025: 2005. Requisitos generales para la competencia de los laboratorios de ensayo y calibración

ISO 17025: 2005. Requisitos generales para la competencia de los laboratorios de ensayo y calibración ISO 17025: 2005 Requisitos generales para la competencia de los laboratorios de ensayo y calibración El presente documento es la versión impresa de la página www.grupoacms.com Si desea más información

Más detalles

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

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

Más detalles

PROCESOS Y PROCEDIMIENTO METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC S.A.

PROCESOS Y PROCEDIMIENTO METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC S.A. 214 CORPORACIÓN PERUANA DE AEROPUERTOS Y AVIACIÓN COMERCIAL SA METODOLOGÍA PARA LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CORPAC SA Área de Organización y Métodos CORPORACIÓN PERUANA DE AEROPUERTOS Y AVIACIÓN

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

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

Nota de Información al cliente ISO 26000 Proceso de auditoría

Nota de Información al cliente ISO 26000 Proceso de auditoría Nota de Información al cliente ISO 26000 Proceso de auditoría La presente nota explica las principales fases del proceso de certificación y auditoría de Sistemas de Gestión de Responsabilidad Social según

Más detalles

PREGUNTAS FRECUENTES ISO 9001:2008

PREGUNTAS FRECUENTES ISO 9001:2008 PREGUNTAS FRECUENTES ISO 9001:2008 Recopilación de preguntas y dudas para la interpretación e implantación de la norma ISO 9001:2008 Sistemas de Gestión de Calidad. Requisitos. Ignacio Gómez http://hederaconsultores.blogspot.com

Más detalles

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

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

Más detalles

ENTRADAS PROCESO RECURSOS

ENTRADAS PROCESO RECURSOS Título: Conceptos básicos de la gestión de procesos en las empresas Autor: Ángel Ibisate, Jefe del Departamento de Calidad y Normativa (Red Eléctrica Española) Fecha: 20-05-2005 1. INTRODUCCIÓN El presente

Más detalles

Entendiendo los SGSI. De la norma a la obtención de beneficios. Entendiendo los SGSI_26032015.pptx 26 de Marzo de 2015

Entendiendo los SGSI. De la norma a la obtención de beneficios. Entendiendo los SGSI_26032015.pptx 26 de Marzo de 2015 Entendiendo los SGSI De la norma a la obtención de beneficios Entendiendo los SGSI_26032015.pptx 26 de Marzo de 2015 Índice 1. La nueva ISO27001:2013 2. El Proyecto 3. Proceso de Certificación 2 ISO27001

Más detalles

Servicios informáticos de soporte y mantenimiento de las Infraestructuras críticas del Banco de España.

Servicios informáticos de soporte y mantenimiento de las Infraestructuras críticas del Banco de España. Sistemas de Información Febrero 2015 Servicios informáticos de soporte y mantenimiento de las Infraestructuras críticas del Banco de España. Pliego Abreviado de Prescripciones Técnicas Sistemas de Información

Más detalles

Proyecto 20000-PYME. Introducción al SGSTI (Sistema de Gestión de Servicios TI)

Proyecto 20000-PYME. Introducción al SGSTI (Sistema de Gestión de Servicios TI) Proyecto 20000-PYME Introducción al SGSTI (Sistema de Gestión de Servicios TI) Introducción TI en los procesos nucleares del negocio Necesidad de objetivar la calidad de TI Referencias en el mundo Metodologías

Más detalles

MANUAL SISTEMA GESTIÓN DE CALIDAD

MANUAL SISTEMA GESTIÓN DE CALIDAD MANUAL SISTEMA GESTIÓN DE CALIDAD ÍNDICE 1.- PRÓLOGO... 4 2.- DEL SISTEMA DE GESTIÓN DE CALIDAD... 6 3.- PUNTOS DE EXCLUSIÓN A LA NORMA ISO 9001 2000... 7 4.- REQUISITOS DEL SISTEMA GESTIÓN DE CALIDAD

Más detalles

PROGRAMA DEL CURSO. SEGURIDAD EN EQUIPOS INFORMATICOS MF0486_3 90 horas MEDIO-AVANZADO DURACION:

PROGRAMA DEL CURSO. SEGURIDAD EN EQUIPOS INFORMATICOS MF0486_3 90 horas MEDIO-AVANZADO DURACION: PROGRAMA DEL CURSO ACCION: DURACION: NIVEL: SEGURIDAD EN EQUIPOS INFORMATICOS MF0486_3 90 horas MEDIO-AVANZADO OBJETIVOS: CE1.1 Identificar la estructura de un plan de implantación, explicando los contenidos

Más detalles

AUDITORÍA INTERNA. Revisó

AUDITORÍA INTERNA. Revisó Elaboró AUDITORÍA INTERNA Revisó P-8314-04 02 Aprobó Faber Andrés Gallego Figueroa Coordinador de Calidad Fecha 26-Ago-2013 1. DEFINICIÓN 1.1 OBJETIVO Alfredo Gómez Cadavid Representante de la Dirección

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI)

Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI) Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI) Referencia Guía para la elaboración del marco normativo- Creative common FINAL.doc Creación

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

TIPO DE PROCESO EVALUACION VERSIÓN 1 PROCEDIMIENTO AUDITORIAS INTERNAS PÁGINA: 1 de 7

TIPO DE PROCESO EVALUACION VERSIÓN 1 PROCEDIMIENTO AUDITORIAS INTERNAS PÁGINA: 1 de 7 PROCESO CONTROL INTERNO CÓDIGO SUBPROCESO CONTROL INTERNO 1.1.2-CI-001 TIPO DE PROCESO EVALUACION VERSIÓN 1 PROCEDIMIENTO PÁGINA: 1 de 7 1.OBJETIVO Proporcionar metodología para realizar las s internas

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

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

MANUAL DE CALIDAD MANUAL DE CALIDAD. Rev: 0 Página 1 de 18 COPIA NO CONTROLADA TABLA DE REVISIONES REVISIÓN FECHA DESCRIPCIÓN DE LA MODIFICACIÓN

MANUAL DE CALIDAD MANUAL DE CALIDAD. Rev: 0 Página 1 de 18 COPIA NO CONTROLADA TABLA DE REVISIONES REVISIÓN FECHA DESCRIPCIÓN DE LA MODIFICACIÓN Página 1 de 18 MANUAL DE CALIDAD COPIA CONTROLADA COPIA NO CONTROLADA Nº COPIA: TABLA DE REVISIONES REVISIÓN FECHA DESCRIPCIÓN DE LA MODIFICACIÓN 0 31/01/2014 Revisión inicial ELABORADO Y REVISADO: R.

Más detalles

AUDITORÍAS DE SISTEMAS DE GESTIÓN AMBIENTAL

AUDITORÍAS DE SISTEMAS DE GESTIÓN AMBIENTAL MÓDULO: GESTIÓN AMBIENTAL AUDITORÍAS DE SISTEMAS DE GESTIÓN AMBIENTAL CRISTINA REY ÍNDICE 1. REQUISITOS DEL SISTEMA DE GESTIÓN AMBIENTAL 2. DEFINICIÓN DE AUDITORÍAS DE SGA. NORMA ISO 19011: DIRECTRICES

Más detalles

NO CONFORMIDADES FRECUENTES EN AUDITORIAS ISO 9001

NO CONFORMIDADES FRECUENTES EN AUDITORIAS ISO 9001 NO CONFORMIDADES FRECUENTES EN AUDITORIAS ISO 9001 Ignacio Gómez hederaconsultores.blogspot.com NO CONFORMIDADES FRECUENTES EN AUDITORIAS ISO 9001 2 ÍNDICE 1. INTRODUCCIÓN...4 2. QUÉ ES UNA AUDITORÍA?...4

Más detalles

1.1. Sistema de Gestión de la Calidad

1.1. Sistema de Gestión de la Calidad 1.1. Sistema de Gestión de la Calidad ÁREA: GESTIÓN DE LA CALIDAD SISTEMA: GESTIÓN DE LA CALIDAD ETAPA I - OBJETIVOS REQUISITOS TÉCNICOS 2012 1. La institución realiza un diagnóstico del estado actual

Más detalles

POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN

POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN PÁGINA Nº1 POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN Versión 1.0 MINISTERIO DE OBRAS PÚBLICAS ELABORADO POR: Dirección General de Obras Públicas FECHA: 9/09/2012 REVISADO

Más detalles

COMISIÓN PARA EL SEGUIMIENTO DE LA CALIDAD EN LA PRESTACIÓN DE LOS SERVICIOS DE TELECOMUNICACIONES

COMISIÓN PARA EL SEGUIMIENTO DE LA CALIDAD EN LA PRESTACIÓN DE LOS SERVICIOS DE TELECOMUNICACIONES DIRECCIÓN GENERAL DE Y TECNOLOGÍAS DE LA INFORMACIÓN COMISIÓN PARA EL SEGUIMIENTO DE LA CALIDAD EN LA PRESTACIÓN DE LOS SERVICIOS DE COMISIÓN PARA EL SEGUIMIENTO DE LA CALIDAD EN LA PRESTACIÓN DE LOS SERVICIOS

Más detalles

MANUAL DE GESTIÓN DE PROCESOS

MANUAL DE GESTIÓN DE PROCESOS MANUAL DE GESTIÓN DE PROCESOS SISTEMA DE GESTIÓN DE CALIDAD UPV Octubre 2011 Versión 1 Elaborado por: Aprobado el 31 de octubre por: Servicio de Evaluación, Planificación y Calidad Gerencia UPV INDICE

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 INTEGRAL DE ATENCIÓN A CLIENTE(A)S, USUARIO(A)S Y BENEFICIARIO(A)S

Más detalles

TEMA 39 Código de buenas prácticas para la Gestión de la Seguridad de la Información. Norma UNE-ISO 17799.

TEMA 39 Código de buenas prácticas para la Gestión de la Seguridad de la Información. Norma UNE-ISO 17799. TEMA 39 Código de buenas prácticas para la Gestión de la Seguridad de la Información. Norma UNE-ISO 17799. Índice 1 Introducción... 1 2 La Norma UNED-ISO 27002... 2 2.1 Estructura de la norma...3 2.1.1

Más detalles

Norma Internacional ISO 9001:2000

Norma Internacional ISO 9001:2000 Norma Internacional ISO 9001:2000 Esta norma ha sido traducida por el Grupo de Trabajo "Spanish Translation Task Group" del Comité Técnico ISO/TC 176, Gestión y aseguramiento de la calidad, en el que han

Más detalles

GUÍA PARA LA ELABORACIÓN DE DOCUMENTOS DIRECCIÓN DE PLANEACIÓN

GUÍA PARA LA ELABORACIÓN DE DOCUMENTOS DIRECCIÓN DE PLANEACIÓN GUÍA PARA LA ELABORACIÓN DE DOCUMENTOS DIRECCIÓN DE PLANEACIÓN 1. Objetivo Establecer e implantar los criterios y características para la elaboración y codificación de los documentos del Sistema Integrado

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

Certificado de profesionalidad DIRECCIÓN Y PRODUCCIÓN EN COCINA ( Nivel 3. Apartado A: REFERENTE DE COMPETENCIA

Certificado de profesionalidad DIRECCIÓN Y PRODUCCIÓN EN COCINA ( Nivel 3. Apartado A: REFERENTE DE COMPETENCIA MÓDULO FORMATIVO DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO ADMINISTRACIÓN EN COCINA. Duración 90 Código MF1066_3 Familia profesional HOSTELERÍA Y TURISMO Área profesional Restauracióm Certificado de profesionalidad

Más detalles

Una Inversión en Protección de Activos

Una Inversión en Protección de Activos DERECHO A LA INTIMIDAD Le ayudamos a garantizar y proteger las libertades públicas y los derechos fundamentales de las personas físicas SEGURIDAD DE LA INFORMACION Auditoria Bienal LOPD Una Inversión en

Más detalles

El largo camino de un Plan Director de Seguridad de la Información

El largo camino de un Plan Director de Seguridad de la Información El largo camino de un Plan Director de Seguridad de la Información Dolores de la Guía Martínez Secretaría General Adjunta de Informática CSIC Presentación 1. Las expectativas 2. El pliego 3. El concurso

Más detalles

Proyecto de administración de sistemas informáticos en red (PI)

Proyecto de administración de sistemas informáticos en red (PI) Página 1 de 9 DEPARTAMENTO Informática y Comunicaciones CURSO 2014-2015 CICLO FORMATIVO Administración de Sistemas Informáticos en Red MÓDULO Proyecto de administración de sistemas informáticos en red

Más detalles

Ciclo de vida del Software

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

Más detalles

Política de Seguridad de la Información de la Universidad de Sevilla

Política de Seguridad de la Información de la Universidad de Sevilla Política de Seguridad de la Información de la Universidad de Sevilla 0. Aprobación y entrada en vigor Texto aprobado por Acuerdo del Consejo de Gobierno de fecha 26 de febrero de 2014. Esta Política de

Más detalles

SISTEMAS Y MANUALES DE LA CALIDAD

SISTEMAS Y MANUALES DE LA CALIDAD SISTEMAS Y MANUALES DE LA CALIDAD NORMATIVAS SOBRE SISTEMAS DE CALIDAD Introducción La experiencia de algunos sectores industriales que por las características particulares de sus productos tenían necesidad

Más detalles

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA Aprobando mediante Resolución de Gerencia General N 052-2015 de fecha 26 Junio 2015 ELABORADO POR: APROBADO POR: 1 de 82 ÍNDICE 1 INTRODUCCIÓN...

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

Se aportan, para la configuración de este anexo, las categorías profesionales más habituales según la definición del MRFI-C:

Se aportan, para la configuración de este anexo, las categorías profesionales más habituales según la definición del MRFI-C: A N E X O II DESCRIPCIÓN DE CATEGORÍAS PROFESIONALES EN LA CONTRATACIÓN DE LOS SERVICIOS DE SOPORTE TÉCNICO DE SISTEMAS PARA EL ENTORNO TECNOLÓGICO DEL TABACO S Página 1 de 16 El presente anexo detalla

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

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

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

Más detalles

POLÍTICA DE GESTIÓN DE SUMINISTRADORES

POLÍTICA DE GESTIÓN DE SUMINISTRADORES Página 1 de 12 Rev. Fecha 1 17/06/2010 procedimiento 2 17/01/2011 Modificación de la Política de Gestión de Suministradores 3 09/07/2013 Actualización apartados 5.1 y 5.3 : : Política de Gestión Suministradores.odt

Más detalles

PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO

PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO UNIDAD: TÉCNICOS DE LABORATORIOS DE DEPARTAMENTOS, CENTROS E INSTITUTOS DE INVESTIGACIÓN (UTLA). Fecha de realización: DICIEMBRE

Más detalles

Presión Positiva. Sistemas de gestión de calidad aplicables a los animalarios. Introducción. Magalí Neus. Ingecal

Presión Positiva. Sistemas de gestión de calidad aplicables a los animalarios. Introducción. Magalí Neus. Ingecal Magalí Neus Ingecal Introducción Presión Positiva Sistemas de gestión de calidad aplicables a los animalarios Uno de los sectores emergentes en cuanto a la implantación de sistemas de gestión de la calidad

Más detalles

PROGRAMACIÓN DE FCT. DEPARTAMENTO Informática y Comunicaciones CURSO 2014-2015 CICLO FORMATIVO Administración de Sistemas Informáticos en Red MÓDULO

PROGRAMACIÓN DE FCT. DEPARTAMENTO Informática y Comunicaciones CURSO 2014-2015 CICLO FORMATIVO Administración de Sistemas Informáticos en Red MÓDULO Página 1 de 11 DEPARTAMENTO Informática y Comunicaciones CURSO 2014-2015 CICLO FORMATIVO Administración de Sistemas Informáticos en Red MÓDULO FORMACIÓN EN CENTROS DE TRABAJO 1. Introducción. Este módulo:

Más detalles

LEGISLACION Y NORMATIVAS COMO FACTORES DETERMINANTES DE LA CALIDAD DEL SOFTWARE

LEGISLACION Y NORMATIVAS COMO FACTORES DETERMINANTES DE LA CALIDAD DEL SOFTWARE LEGISLACION Y NORMATIVAS COMO FACTORES DETERMINANTES DE LA CALIDAD DEL SOFTWARE 1. Introducción Una de los elementos más relevantes de la evolución de la economía en los últimos años ha sido su internacionalización

Más detalles

Procedimiento de gestión de auditorias internas de calidad

Procedimiento de gestión de auditorias internas de calidad Procedimiento de gestión de auditorias internas de calidad Procedimiento de gestión de auditorias internas de calidad Procedimiento de gestión de auditorias internas de calidad PROCEDIMIENTO DE GESTIÓN

Más detalles

LAS FAMILIA DE NORMAS ISO 30300 DE SISTEMAS DE GESTIÓN PARA DOCUMENTOS

LAS FAMILIA DE NORMAS ISO 30300 DE SISTEMAS DE GESTIÓN PARA DOCUMENTOS LAS FAMILIA DE NORMAS ISO 30300 DE SISTEMAS DE GESTIÓN PARA DOCUMENTOS RAMON ALBERCH i FUGUERAS MIEMBRO DEL COMITÉ TÉCNICO DE NORMALIZACIÓN DE AENOR (CTN50/SC1) DIRECTOR GENERAL DE LA ESCUELA SUPERIOR

Más detalles

GESTION OPERATIVA. Niveles de gestión

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

Más detalles

Las claves de un buen plan de marketing

Las claves de un buen plan de marketing Las claves de un buen plan de marketing 2 ÍNDICE Qué es un plan de marketing internacional y cuáles son sus utilidades.. 3 La finalidad de la elaboración de un plan de marketing internacional... 4 Cuestiones

Más detalles

BOLETÍN OFICIAL DEL ESTADO

BOLETÍN OFICIAL DEL ESTADO Núm. 300 Miércoles 14 de diciembre de 2011 Sec. I. Pág. 135721 No debe interpretarse que los diversos espacios formativos identificados deban diferenciarse necesariamente mediante cerramientos. Las instalaciones

Más detalles

Formación en Centros de Trabajo

Formación en Centros de Trabajo I.E.S. SAN SEBASTIÁN C.F.G.S ADMINISTRACIÓN DE SISTEMAS INFORMATICOS EN RED D E P A R T A M E N T O D E I N F O R M Á T I C A Formación en Centros de Trabajo C.F.G.M 2º ADMINISTRACIÓN SISTEMAS INFORMÁTICOS

Más detalles

PROCEDIMIENTO INTEGRADO PARA LA GESTIÓN DE LAS ACTIVIDADES DE FORMACIÓN

PROCEDIMIENTO INTEGRADO PARA LA GESTIÓN DE LAS ACTIVIDADES DE FORMACIÓN PROCEDIMIENTO INTEGRADO PARA LA GESTIÓN DE LAS ACTIVIDADES DE FORMACIÓN Hoja 1 de 11 PROCEDIMIENTO INTEGRADO PARA LA GESTIÓN DE LAS ACTIVIDADES DE FORMACIÓN Realizado por Revisado por Aprobado por Fco.

Más detalles

Ges3ón de Proyectos So9ware

Ges3ón de Proyectos So9ware Ges3ón de Proyectos So9ware Tema 2.1 Integración Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Ampliar los conocimientos básicos

Más detalles

SUPLEMENTO EUROPASS AL TÍTULO

SUPLEMENTO EUROPASS AL TÍTULO SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Gestión de Ventas y Espacios Comerciales --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

NORMA TÉCNICA NTC- ISO COLOMBIANA 9001

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

Más detalles

LA AUDITORÍA DE SEGURIDAD DEL ENS

LA AUDITORÍA DE SEGURIDAD DEL ENS LA AUDITORÍA DE SEGURIDAD DEL ENS La auditoría de Seguridad en el Esquema Nacional de Seguridad Índice Dónde se regula la auditoría del ENS Qué es una auditoría Cuál es la finalidad de la auditoría Quién

Más detalles

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

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

Más detalles

GESTIÓN DE PROYECTOS

GESTIÓN DE PROYECTOS GESTIÓN DE PROYECTOS Índice DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDADES DE INICIO DEL PROYECTO...2 ACTIVIDAD GPI 1: ESTIMACIÓN DE ESFUERZO...2 Tarea GPI 1.1: Identificación de Elementos a Desarrollar...3 Tarea

Más detalles

Servicio Nacional de Aprendizaje SENA CARACTERIZACION DE PROCESO

Servicio Nacional de Aprendizaje SENA CARACTERIZACION DE PROCESO C01-3030 / 12-08 Mejora Continua CARACTERIZACION DE PROCESO Versión: 3.0 Página 1 de 1 NOMBRE DEL PROCESO: INTELIGENCIA ORGANIZACIONAL RESPONSABLE DEL PROCESO: Coordinador Grupo de Inteligencia Organizacional

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

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES PARA LA CONTRATACIÓN DE

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES PARA LA CONTRATACIÓN DE VICECONSEJERÍA DE PRESUPUESTOS Y ADMINISTRACIÓN PÚBLICA PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES PARA LA CONTRATACIÓN DE LA ADECUACIÓN A LA LEY ORGÁNICA DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL

Más detalles

Plan operativo anual 2010

Plan operativo anual 2010 Plan operativo anual 2010 Objetivos estratégicos/operativos y de calidad del Servicio de Personal y Organización Docente [1] 15 de enero de 2010 0. INTRODUCCIÓN Los Estatutos de la Universidad de Jaén

Más detalles

NORMA TÉCNICA DE COMPETENCIA LABORAL

NORMA TÉCNICA DE COMPETENCIA LABORAL I.- Datos Generales Código: NURUR003.01 Título: Consultoría a empresas rurales Propósito de la Norma Técnica de Competencia Laboral: Servir como referente para la evaluación y certificación de las personas

Más detalles

Etapa de Implementación de la Ejecución del Plan

Etapa de Implementación de la Ejecución del Plan MINISTERIO DE OBRAS PÚBLICAS Gestión y Monitoreo de Planes de Obras Públicas Etapa de Implementación de la Ejecución del Plan Dirección de Planeamiento SUBDIRECCION DE PLANIFICACION ESTRATEGICA Noviembre

Más detalles

Política de Seguridad y Salud Ocupacional. Recursos. Humanos. Abril 2006

Política de Seguridad y Salud Ocupacional. Recursos. Humanos. Abril 2006 Endesa Chile Políticas de Índice 1. PRINCIPIOS 2. LINEAMIENTOS GENERALES 2.1 Organización 2.2 Identificación de Peligros y Evaluación de Riesgos 2.3 Planificación Preventiva 2.4 Control de la acción preventiva

Más detalles

IMPLANTACIÓN SISTEMA DE GESTIÓN

IMPLANTACIÓN SISTEMA DE GESTIÓN 5 IMPLANTACIÓN DE UN ENERGÉTICA A partir de la ratificación del Protocolo de Kyoto por España en el año 2002, se aprueba en el año 2003 la Estrategia Española de Eficiencia Energética 2004-2014 de la que

Más detalles