COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE"

Transcripción

1 COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase, para que a la persona responsable de ejecutarla, le quede claro el cómo debe funcionar el sistema a diseñar, sus funciones y los entregables a generar para el proyecto. Responsables: Arquitecto de Software (AS), Líder de Proyecto (LP) y Gerente (GTE). Descripción del Diagrama de Flujo Inicio. La Arquitectura de Software inicia una vez que el Líder de Proyecto ha asignado una petición al Equipo de Proyecto. El Arquitecto de Software verificará diariamente las actividades a realizar en la herramienta de Administración de Proyectos, en caso de tener dudas sobre las tareas asignadas o no tener actividades planificadas para ese día en la herramienta antes mencionada, le notifica a su Líder de Proyecto. Nota: El responsable de ejecutar la fase de Arquitectura y Diseño participa en actividades que corresponden a otras fases dentro del proyecto, como lo son la fase de análisis, codificación, pruebas y actividades propias de la administración de proyectos. 1.- AS revisa petición. Una vez que el Líder de Proyecto ha asignado una petición a todo el Equipo de Proyecto para trabajar, el Arquitecto de Software revisa el contenido de la petición que obtiene de la herramienta Administrador de Peticiones de Sistemas (APS). 2.- AS identifica REQ iniciales y genera lista con las dudas y/o propuestas. Arquitecto de Software analiza las necesidades que el Solicitante plasmó en la petición e identifica los requerimientos iniciales, a su vez listará todas las dudas que tenga en relación a los requerimientos generados por el Solicitante, finalmente, listará las propuestas que representen una solución válida, todo lo antes mencionado será presentado por el Arquitecto de Software durante la reunión de inicio de proyecto. Nota: El Arquitecto de Software deberá llevar documentadas la lista de dudas y/o propuestas a la reunión de inicio de proyecto. También deberá llevar documentadas las necesidades iniciales, con el objetivo de que el Analista de Requerimientos las verifique y genere los requerimientos funcionales y no funcionales que sean necesarios para generar un producto que satisfaga las necesidades del Solicitante. 3.- AS asiste a la reunión de inicio. Arquitecto de Software asiste a la reunión de inicio, para lo cual deberá de iniciar la actividad por medio de la huella en la herramienta Administrador de Proyectos. 4.- AS expone las dudas o aporta propuestas al proyecto en la reunión de inicio. Durante la reunión de inicio, el Arquitecto de Software expone las dudas a los integrantes del Equipo de Proyecto con el objetivo de verificar si alguno de los integrantes del equipo puede aclararlas, en caso contrario, será responsabilidad del Analista de Requerimientos anotarlas para revisarlas con el Solicitante. A su vez el Arquitecto de Software presentará propuestas de solución para resolver las necesidades del Solicitante, mismas que serán debatidas durante la reunión para determinar su factibilidad. 5.- AS acepta minuta. Una vez que el Líder de Proyecto ha generado la minuta de la reunión de inicio de proyecto, el Arquitecto de Software revisará el contenido y firmará la minuta a través de su huella en

2 la herramienta Administrador de Proyectos. Nota: Durante la reunión de inicio, el Equipo de Proyecto debe asegurarse de identificar el hardware, software, así como identificar a las áreas que será necesario solicitar datos como: configuraciones, periféricos y otros, mismos que deberán quedar plasmados en la minuta de la reunión de inicio que genera el Líder de Proyecto, con el objetivo de que los mismos estén listos antes de generar los entregables de cada una de las fases del proceso de desarrollo. 6.- AS recibe parcial o total del contrato. Arquitecto de Software recibe parcial o total del contrato, el cual contiene n requerimientos que ya han sido aprobados por todos los integrantes del Equipo de Proyecto. 7.- AS tiene dudas sobre el contenido del contrato? Nos hacemos esta pregunta para verificar si el Arquitecto de Software tiene alguna duda sobre los requerimientos plasmados en el contrato parcial o total, en caso de no tener ninguna duda continúa en la Actividad 10 AS entrega estimación y determina complejidad, en caso contrario continúa en la siguiente actividad. 8.- AS revisa dudas con AR o EQP. Arquitecto de Software revisa las dudas sobre el contenido del contrato con el Analista de Requerimientos u otra duda con algún integrante del Equipo de Proyecto. 9.- Se resolvieron las dudas? Nos hacemos esta pregunta para verificar si se resolvieron las dudas al Arquitecto de Software, en caso de que las dudas no hayan sido aclaradas, se regresa a la Actividad 8 AS revisa dudas con AR o EQP, en caso contrario continua en la siguiente actividad AS entrega estimación y determina complejidad. Arquitecto de Software toma el parcial o total del Contrato y en base a las especificaciones de funcionalidad (requerimientos) realiza un análisis técnico y dimensiona el impacto que se tendrá en las diferentes funcionalidades del sistema y en otros sistemas, es decir, determina la complejidad, la cual servirá para realizar la estimación de cada una de las actividades que se realizarán durante la fase de Diseño y Arquitectura, dicha estimación deberá ser entregada al Líder de Proyecto, quien se encargará de registrarlas en el Cronograma del Proyecto. Es importante mencionar que en la fase de Arquitectura se va a estimar por cada uno de los requerimientos, quedando establecidas las siguientes complejidades: Notas: Requerimiento bajo = 2 horas. Requerimiento medio = 4 horas. Requerimiento alto = 8 horas. El impacto consiste en identificar los componentes de código que será necesario crear y/o modificar para cumplir con la funcionalidad plasmada en el parcial o total del Contrato. En esta actividad, el Arquitecto de Software consulta toda la documentación que haya resultado del Análisis de Requerimientos y en caso de que tenga dudas sobre lo plasmado en la documentación, las revisará con el Analista de Requerimientos asignado al proyecto y le informará a su Líder de Proyecto. En caso de que el Líder de Proyecto considere que se deban realizar ajustes a las actividades y tiempos que el Arquitecto de Software propone, se negociará entre ambos para llegar a un acuerdo que más convenga al proyecto AS genera / actualiza parcial o total de los entregables de arquitectura. El Arquitecto de Software genera / actualiza la Arquitectura de Software que consiste en plasmar en un nivel técnico la interacción de los componentes de código necesarios para cumplir con la funcionalidad del sistema, por lo tanto, el Arquitecto de Software elabora los entregables dependiendo de las necesidades del proyecto y comienza con los Entregables Iniciales que son los que deben estar listos para iniciar con la fase de codificación. Finalmente, existen Entregables Finales que se generarán conforme el

3 proyecto vaya avanzando y deben estar terminados antes de que finalice el proyecto. A continuación se mencionan los entregables, los cuales dependerán de los siguientes criterios: Sistemas o módulos nuevos y reingeniería de sistemas Modelo de Secuencia (entregable final). Modelo de Clases (entregable inicial). Modelo de Componentes (entregable final). Modelo de Despliegue (entregable final). Modelo de Datos (entregable inicial). Mantenimiento de sistemas existentes con documentación Modelo de Secuencia * (entregable final) Modelo de Clases * (entregable inicial). Modelo de Componentes * (entregable final). Mantenimiento de sistemas existentes sin documentación Diagrama Técnico de Proceso (DTP) * (entregable inicial). Modelo de Componentes * (entregable final) Documento de liberación (entregable final). Es importante mencionar que los entregables marcados con un (*) estarán sujetos a actualizaciones (sistemas con documentación) o se generarán (sistemas sin documentación) dependiendo del resultado que se obtiene de la aplicación del Check list Entregables de Arquitectura, el cual se aplica en todos los proyectos que se trabajen bajo el tratamiento de Mantenimiento. Dicho check list se encuentra en el repositorio de proceso que corresponde a la versión vigente del proceso de Arquitectura de Software. Nota: Una vez que un determinado rol ha terminado los entregables (iniciales y finales) que corresponden a su fase en una parcialidad, el mismo puede continuar con la generación de otra sin necesidad de que se hayan ejecutado todas las fases del proceso de desarrollo en una parcialidad anterior, es decir, no es necesario que el resto de los roles hayan culminado los entregables que le corresponden para esa parcialidad El EQP valida que se entreguen parciales o total de entregables? Nos hacemos esta pregunta para verificar si el parcial o total que generó el Arquitecto de Software se podrá trabajar en el resto de las fases que conforman el proceso de desarrollo, en caso de que no se valide el parcial o total se regresa a la Actividad 8.- AS revisa dudas con AR o EQP., en caso contrario continúa en la siguiente actividad AS entrega parcial o total de entregables de arquitectura. Una vez que el Equipo de Proyecto ha validado el contenido del parcial o total, el Arquitecto de Software proporciona los Entregables Iniciales necesarios al Programador y al resto de los integrantes del Equipo de Proyecto.

4 14.- PG tiene dudas? Nos hacemos esta pregunta para verificar si el Programador tiene alguna duda durante el transcurso de la generación de sus entregables basado en la documentación generada por el Arquitecto de Software, en caso de que el programador no tenga dudas continua en la Actividad 17 Se ha generado el último parcial del proyecto?, en caso contrario continúa en la siguiente actividad AS puede resolver? Nos hacemos esta pregunta para verificar si el Arquitecto de Software puede resolver las dudas planteadas por el Programador, en caso de no poder resolver las dudas se regresa a la Actividad 8.- AS revisa dudas con AR o EQP., en caso contrario continúa en la siguiente actividad AS resuelve dudas. Arquitecto de Software resuelve las dudas relacionadas al contenido del parcial o total de los Entregables Iniciales de Arquitectura al Programador Se ha generado el último parcial del proyecto? Nos hacemos esta pregunta para verificar si el Arquitecto de Software ha generado el último parcial del proyecto, es decir, la etapa de elicitación ha finalizado, ya que el Arquitecto de Software en conjunto con el Equipo de Proyecto ha aclarado todas las dudas sobre el contenido de la petición y tiene claro el objetivo, requerimientos y entregables esperados por el Solicitante. En caso de no haber generado el último parcial se regresa a la Actividad 6 AS recibe parcial o total del contrato, en caso contrario continúa en la siguiente actividad EQP termina elicitación. Arquitecto de Software coloca su huella para finalizar la etapa de Elicitación una vez que el Analista de Requerimientos ha detonado la terminación de la etapa antes mencionada por medio de la huella en la herramienta Administrador de Peticiones de Sistemas (APS) AS recibe documentación de contrato y modelos. Arquitecto de Software recibe del Analista de Requerimientos la documentación generada en dicha fase una vez que el contrato ha sido autorizado por el Solicitante AS genera / actualiza estimación y complejidad del proyecto. Arquitecto de Software basado en las especificaciones de funcionalidad (requerimientos) realiza el análisis técnico para determinar el impacto del proyecto, es decir, determina la complejidad del proyecto considerando los n parciales que se generaron para posteriormente realizar la estimación total de las actividades del proyecto que se ejecutarán durante la fase de Diseño y Arquitectura, la cual será entregada al Líder de Proyecto, quien se encargará de registrarlas en el Cronograma del Proyecto. Es importante mencionar que en la fase de Arquitectura se va a estimar por cada uno de los requerimientos, quedando establecidas las siguientes complejidades: Requerimiento bajo = 2 horas. Requerimiento medio = 4 horas. Requerimiento alto = 8 horas. Nota: Cuando no se generen parcialidades, es decir, cuando se genera el Contrato Total, esta actividad se cumple en la Actividad 10 AS entrega estimación y determina complejidad AS actualiza entregables de arquitectura. El Arquitecto de Software concluye la elaboración de los Entregables Finales de la fase de Arquitectura de Software que consiste en plasmar en un nivel técnico la interacción de los componentes de código necesarios para cumplir con la funcionalidad del sistema. A continuación se mencionan los entregables, los cuales dependerán de los siguientes criterios: Sistemas o módulos nuevos y reingeniería de sistemas Modelo de Secuencia (entregable final). Modelo de Clases (entregable inicial).

5 Modelo de Componentes (entregable final). Modelo de Despliegue (entregable final). Modelo de Datos (entregable inicial). Mantenimiento de módulos nuevos y reingeniería Modelo de Secuencia * (entregable final) Modelo de Clases * (entregable inicial). Modelo de Componentes * (entregable final). Mantenimiento de sistemas existentes sin documentación Diagrama Técnico de Proceso (DTP) * (entregable inicial). Modelo de Componentes * (entregable final) Documento de liberación (entregable final). Es importante mencionar que los entregables marcados con un (*) estarán sujetos a actualizaciones (sistemas con documentación) o se generarán (sistemas sin documentación) dependiendo del resultado que se obtiene de la aplicación del Check list Entregables de Arquitectura, el cual se aplica en todos los proyectos que se trabajen bajo el tratamiento de Mantenimiento. Dicho check list se encuentra en el repositorio de proceso que corresponde a la versión vigente del proceso de Arquitectura de Software. Notas: Definición de Mantenimiento de Producto (DMP): es un documento que contempla las especificaciones técnicas que debe contener el sistema a generar. Será utilizado en los proyectos de Mantenimiento para describir el cambio o la modificación del sistema, es importante mencionar que en dicho documento no se debe de incluir código fuente, además la información capturada en el DMP es complementada con los requerimientos y reglas de negocio definidas por el Analista de Requerimientos. El DMP electrónico permitirá realizar liberación por componente afectado con la finalidad de ir avanzando con el desarrollo Los diagramas de Arquitectura de Software se crean sobre el archivo de diagramas generado en la fase de Análisis de Requerimientos correspondiente al mismo sistema. Documento de Liberación: El arquitecto de Software genera el Documento de Liberación, mismo que será complementado en fases posteriores del proceso de desarrollo por el Programador, Tester e Implementador, por lo antes mencionado, el Arquitecto se Software llenará los apartados de: Introducción, Datos de la solicitud, Datos de la versión. Además es importante mencionar que en la fase de Arquitectura se identificarán los componentes de código que se necesitan para llevar a cabo lo especificado en la petición del Solicitante que se especificará en el apartado Descripción breve del proyecto y en el campo "componente" del apartado "Componentes de código"; también plasmará la secuencia de instalación del producto en el apartado Requerimientos de instalación y/o ejecución y llenará el apartado de "Dependencias externas". Es importante mencionar que el Arquitecto puede asignar la ruta

6 donde se encontrará almacenado el componente en el campo URL del apartado de Componentes de código a pesar de que es responsabilidad del Programador, quien se encargará de verificar que se haya asignado la ruta correcta. La plantilla del documento DMP, Modelos y Documento de Liberación se encuentran en el repositorio de proceso que corresponda a la versión vigente del proceso de Arquitectura de Software. En el apartado de Aclaraciones se hace una breve descripción de cada uno de los modelados. 22- AS genera línea base junto con LP. Una vez que el Arquitecto de Software ha finalizado todos los entregables de la fase de Diseño y Arquitectura genera la Línea Base de Arquitectura, misma que realiza por medio de la herramienta Enterprise Architect (modelados). Aclaraciones: A continuación se hace una breve descripción del contenido de cada uno de los modelos generados durante la fase de Arquitectura: Modelo de Datos: El modelo de datos se elabora siempre que en un proyecto sufra cambios la estructura de la base de datos lo cual se define con la aplicación del check list. Un modelo de base de datos puede contener lo siguiente: tablas, campos y relaciones entre tablas, funciones, procedimientos almacenados, llaves primarias y llaves foráneas. Es importante mencionar que cuando se diseñan tablas por primera vez, éstas deben de estar apegadas a las reglas de estandarización de Base de Datos. El modelo de datos se diseñará con la participación del Administrador de Base de Datos, quien deberá validar el diseño final así como tomar la responsabilidad en conjunto con el Arquitecto de Software sobre el diseño propuesto. Modelo de Clases: Es un diagrama el cual debe ser elaborado antes de iniciar la fase de Codificación y lo mínimo que debe contener son los nombres de clases a desarrollar con sus relaciones, las clases deben de estar bien documentadas con la funcionalidad para la que será creada. En el caso de que se identifique necesaria la implementación de un patrón de diseño se deberá hacer mención de éste para que sea codificado de acuerdo al estándar que define el diagrama del patrón. El Arquitecto de Software en conjunto con el Programador podrá definir los nombres de los métodos de cada una de las clases, parámetros, tipos de datos, etc. A medida que avanza la codificación. Al finalizar el proyecto el Arquitecto de Software debe dejar documentación completa de todas las clases afectadas o creadas ya sea aplicando ingeniería inversa o diseño directo sobre la herramienta utilizada para realizar el diseño (Enterprise Architect). Modelo de Secuencia: El diagrama de secuencia se realiza de manera general sin definir métodos de clases a detalle, se definen los flujos principales sin llegar a detalle de describir estructuras de control, este diagrama se puede generar durante el proceso de desarrollo del proyecto a medida como se avance la fase de Codificación, el Arquitecto de Software deberá estar en constante comunicación con el Programador para asegurarse que se esté siguiendo el diseño preestablecido. Modelo de Componentes: Es un diagrama de componentes con todas las relaciones que existen entre cada una de ellas, los componentes se refieren a componentes de sistema de archivos, ejemplo (archivos binarios, ejecutables, librerías, etc.). Modelo de Despliegue: Se realizará la identificación inicial de servidores o hardware necesario para desarrollo/pruebas, ésta información se podrá plasmar en el documento de liberación con el siguiente contenido: versiones del DBMS, IP/DNS, puertos. Durante el proceso de desarrollo del proyecto se va a elaborar el diagrama de despliegue con la información ya identificada y con nuevos requerimientos de infraestructura, protocolos, puertos y servicios detectados.

7 Los entregables que se generan al finalizar el proceso de Arquitectura de Software son: Proyecto de Desarrollo Nuevo: Modelo de Arquitectura de Software del Sistema (incluye Diagrama Técnico de Proceso). Documento de Liberación. Proyecto de Mantenimiento: Definición de Mantenimiento de Producto (DMP) Modelo de Arquitectura de Software del Sistema en caso de aplicar. Diagrama Técnico de Proceso para proyectos de Mantenimiento sin documentación en caso de aplicar. Documento de Liberación. Y con esto se da por terminado el proceso de Arquitectura de Software.

Proceso de administración del tiempo del proyecto/programa

Proceso de administración del tiempo del proyecto/programa Proceso de administración del tiempo del proyecto/programa Proyecto Control del documento Información del documento Identificación del documento Responsable del documento Fecha de emisión Fecha de última

Más detalles

REQ. Fundamento Institucional. Objetivos

REQ. Fundamento Institucional. Objetivos REQ INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de REQUERIMIENTOS para el desarrollo de software en el cual se debe apoyar para la ejecución de sus

Más detalles

Detalles del Subproceso. Registro de Oferta de Vivienda

Detalles del Subproceso. Registro de Oferta de Vivienda Detalles del Subproceso Registro de Oferta de Modelo de Operación Modelo de Operación de Crédito Macro Proceso Otorgamiento de Crédito Proceso Oferta de Fecha de Impresión viernes 10 de enero de 2014 Tabla

Más detalles

PROCEDIMIENTO 082: AUTORIZACIÓN PARA LA INTEGRACIÓN O ACTUALIZACIÓN DE PÁGINAS WEB AL PORTAL ELECTRÓNICO DEL GOBIERNO

PROCEDIMIENTO 082: AUTORIZACIÓN PARA LA INTEGRACIÓN O ACTUALIZACIÓN DE PÁGINAS WEB AL PORTAL ELECTRÓNICO DEL GOBIERNO Página 219 de 266 PROCEDIMIENTO 082: AUTORIZACIÓN PARA LA INTEGRACIÓN O ACTUALIZACIÓN DE PÁGINAS WEB AL PORTAL ELECTRÓNICO DEL GOBIERNO Objetivo Ampliar la imagen y difusión de información, programas y

Más detalles

GUÍA PARA LA MIGRACIÓN DE BASES DE DATOS

GUÍA PARA LA MIGRACIÓN DE BASES DE DATOS MINISTERIO DE SALUD Y PROTECCIÓN SOCIAL BOGOTÁ, AGOSTO DE TABLA DE CONTENIDO I. PROPÓSITO... 3 II. ALCANCE... 3 III. DOCUMENTOS DEL SIGI ASOCIADOS A LA GUÍA... 3 IV. DEFINICIONES... 3 V. NORMATIVA Y OTROS

Más detalles

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

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

Más detalles

Procedimiento para el Monitoreo y Control de Tecnologías de Información

Procedimiento para el Monitoreo y Control de Tecnologías de Información Procedimiento para el Monitoreo y Control de Tecnologías de Información DIRECCIÓN DE COORDINACIÓN TÉCNICA Y PLANEACIÓN DICIEMBRE DE 2009 PR-DCTYP-15 Índice 1. INTRODUCCIÓN.... 3 2. OBJETIVO.... 3 3. ALCANCE....

Más detalles

UNIDAD DE NEGOCIO ENERJUBONES

UNIDAD DE NEGOCIO ENERJUBONES UNIDAD DE NEGOCIO ENERJUBONES PÁGINA 1 DE 19 CONTENIDO 1. OBJETO... 3 2. ALCANCE... 3 3. IDENTIFICACIÓN... 3 4. REFERENCIAS... 3 5. RESPONSABILIDAD Y AUTORIDAD... 3 6. DEFINICIONES... 4 7. DESCRIPCIÓN

Más detalles

Syllabus. www.techeraperu.com cursos@techeraperu.com

Syllabus. www.techeraperu.com cursos@techeraperu.com Syllabus www.techeraperu.com cursos@techeraperu.com Este curso está dirigido para los Encargados de Desarrollar los Sistemas de Información y personas encargada de los Proyectos de Sistemas, donde podrás

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 2.0 Página 1 de 13 1. OBJETIVO: Establecer las etapas que se siguen en el desarrollo y mantenimiento evolutivo y adaptativo de sistemas de información, definiendo el flujo de actividades que se

Más detalles

ANEXO I CONDICIONES PARTICULARES

ANEXO I CONDICIONES PARTICULARES REGISTRO ELECTRONICO DE CONSTRUCTORAS DE OBRA PÚBLICA 1. OBJETO ANEXO I CONDICIONES PARTICULARES La presente contratación directa tiene por objeto la obtención de los servicios Análisis, Desarrollo e Implantación

Más detalles

PROCEDIMIENTO PLANEACION DE PROYECTOS PROCESO GESTION DE PROGRAMAS Y PROYECTOS

PROCEDIMIENTO PLANEACION DE PROYECTOS PROCESO GESTION DE PROGRAMAS Y PROYECTOS Página: 1 de 10 1. OBJETIVO: Establecer las actividades para identificar los parámetros iniciales y para constituir las bases de un nuevo proyecto o fase de un proyecto existente que garanticen el cumplimiento

Más detalles

PROCEDIMIENTO VERSION: 01 ADMINISTRACIÓN DE COPIAS DE SEGURIDAD FECHA: 18-08-2009 PROCESO GESTION DE LA EDUCACIÓN

PROCEDIMIENTO VERSION: 01 ADMINISTRACIÓN DE COPIAS DE SEGURIDAD FECHA: 18-08-2009 PROCESO GESTION DE LA EDUCACIÓN PROCESO GESTION DE LA EDUCACIÓN PAGINA: 1 de 6 1 OBJETIVO Planear, desarrollar y controlar las actividades relacionadas con las copias de seguridad de la información de los EE en caso requerido, que permitan

Más detalles

DESCRIPCIÓN Y PERFIL DE PUESTOS 4. RELACIONES INTERNAS Y EXTERNAS INTERFAZ. Tiempo de Experiencia: Especificidad de la experiencia:

DESCRIPCIÓN Y PERFIL DE PUESTOS 4. RELACIONES INTERNAS Y EXTERNAS INTERFAZ. Tiempo de Experiencia: Especificidad de la experiencia: Código: 0.00.00.3.03.01.01.0 Denominación: Asistente de Tecnologías de la Información Ejecución de procesos de apoyo y tecnológico Grupo Ocupacional: Personal de la Institución, Unidades internas, Director

Más detalles

Implantación y Aceptación del Sistema

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

Más detalles

Verificación de la Calidad en los Productos de Software Desarrollados

Verificación de la Calidad en los Productos de Software Desarrollados Página 1 de 7 1. Objetivo y Alcance Verificar que el aplicativo o módulo a ser entregado al área de Soporte Tecnológico cumpla con las exigencias del usuario y con los parámetros de calidad definidos por

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

copia no controlada ACUERDO DE SERVICIO Sistemas-Gestión de los Servicios Informáticos AS-T-01 Rev. 46 1. OBJETIVO

copia no controlada ACUERDO DE SERVICIO Sistemas-Gestión de los Servicios Informáticos AS-T-01 Rev. 46 1. OBJETIVO Páginas 1 de 10 1. OBJETIVO Brindar el marco normativo que fije las condiciones en que deben prestarse los Servicios de Tecnologías de Información a los procesos de la organización, estableciendo criterios

Más detalles

Programa Instruccional de Asignatura

Programa Instruccional de Asignatura DuocUC Vicerrectoría Académica Programa Instruccional de Asignatura ASO4461 Administración de sistemas operativos Créditos:8 Horas: 72 Requisitos: Fecha Actualización: 22 de Mayo de 2013 ESCUELA DE INFORMÁTICA

Más detalles

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS DESARROLLO DE UNA SOLUCION GENERAL DE INTEGRACION DE

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

ANEXO XII. Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes.

ANEXO XII. Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes. ANEXO XII I. IDENTIFICACIÓN DEL CERTIFICADO DE PROFESIONALIDAD Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes.

Más detalles

Implementación de una Plataforma de Gestión de Documentos Digitales. INFORME FINAL Provincia de Tucumán TOMO I DE I

Implementación de una Plataforma de Gestión de Documentos Digitales. INFORME FINAL Provincia de Tucumán TOMO I DE I Implementación de una Plataforma de Gestión de Documentos Digitales INFORME FINAL Provincia de Tucumán TOMO I DE I FECHA DICIEMBRE 2013 Índice... I. Presentación... 3 II. Glosario... 4 III. Resumen...

Más detalles

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones Sistema de Administración de Farmacias Plan de SQA Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 29/08/2014 1.0 Realización del documento Resp. SQA Plan de SQA Página 1 de 15 ÍNDICE

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática Pág: 1 de 6 DEPARTAMENTO DE INGENIERÍA INFORMÁTICA (DII): LS4118: Ingeniería del Software I Documento de DISEÑO Proyecto: XXXXXX Autor/es: YYYYY Pág: 2 de 6 Contenido 1. Introducción 3 2. Diagrama de despliegue

Más detalles

PROCEDIMIENTO VERSION: 03 ELABORACION Y CONTROL DE DOCUMENTOS PROCESO DE PLANIFICACION DEL SISTEMA INTEGRADO DE GESTION

PROCEDIMIENTO VERSION: 03 ELABORACION Y CONTROL DE DOCUMENTOS PROCESO DE PLANIFICACION DEL SISTEMA INTEGRADO DE GESTION PAGINA: 1 de 14 1 OBJETIVO Establecer las disposiciones para la elaboración, revisión, aprobación, actualización, distribución y preservación de los documentos del Sistema Integrado de Gestión (CALIDAD-

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

MANUAL DE PROCEDIMIENTOS. Dirección de Administración y Finanzas. 47. Procedimiento para revisar e instalar software y hardware autorizado.

MANUAL DE PROCEDIMIENTOS. Dirección de Administración y Finanzas. 47. Procedimiento para revisar e instalar software y hardware autorizado. Hoja: 1 de 12 47.- PROCEDIMIENTO PARA REVISAR E INSTALAR SOFTWARE Y HARDWARE AUTORIZADO Hoja: 2 de 12 1.0 Propósito 1.1 Mantener en óptimas condiciones el software y hardware permitido en los equipos propiedad

Más detalles

PROCEDIMIENTO DE PASE A PRODUCCIÓN DE SISTEMAS DE INFORMACIÓN

PROCEDIMIENTO DE PASE A PRODUCCIÓN DE SISTEMAS DE INFORMACIÓN Aprobado por: Manuel Cok Aparcana Jefe de la Oficina de Informática del MED PROCEDIMIENTO DE PASE A PRODUCCIÓN DE SISTEMAS DE INFORMACIÓN 1 Objetivo El presente procedimiento tiene como objetivo establecer

Más detalles

PROCEDIMIENTO DE GESTIÓN DE LA DOCUMENTACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD

PROCEDIMIENTO DE GESTIÓN DE LA DOCUMENTACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD 1. CARACTERIZACIÓN DEL PÁGINA: 1 NOMBRE: Gestión de la Documentación del Sistema de Gestión de Calidad OBJETIVO: Garantizar la unificación de la información y actualización de los para el s.g.c. de tal

Más detalles

8.0. DESCRIPCIÓN DE LA ACTIVIDAD / ACCIÓN: Unidad Responsable / Funcionario Dirección de Servicios Generales (Técnico)

8.0. DESCRIPCIÓN DE LA ACTIVIDAD / ACCIÓN: Unidad Responsable / Funcionario Dirección de Servicios Generales (Técnico) N de Página: 2/7 8.0. DESCRIPCIÓN DE LA ACTIVIDAD / ACCIÓN: Unidad Responsable / Funcionario Dirección de Servicios Generales (Técnico) Dirección de Servicios Generales (Almacenista) Dirección de Servicios

Más detalles

LINQ TO AMAZON PLAN DE PROYECTO. Versión 1.2

LINQ TO AMAZON PLAN DE PROYECTO. Versión 1.2 LINQ TO AMAZON PLAN DE PROYECTO Versión 1.2 Historia de revisiones Fecha Versión Descripción Autor 23/08/2008 1.0 Creación del documento. Martín Rivadavia 20/08/2008 1.1 Correcciones. Martín Rivadavia

Más detalles

Solución de No conformidades

Solución de No conformidades Solución de No conformidades Documento de Construcción Solución de No conformidades 1 Tabla de Contenido Diagrama Del Proceso... 2 Sub Proceso Acción Correctiva... 3 Ejecutar Plan De Acción... 4 Proceso

Más detalles

Examen de Fundamentos de ITIL

Examen de Fundamentos de ITIL Examen de Fundamentos de ITIL Ejemplo A, versión 5.1 Selección tipo test Instrucciones 1. Debe intentar contestar las 40 preguntas. 2. Marque sus respuestas en lápiz en la hoja anexa 3. Usted tiene 60

Más detalles

MANUAL DE PROCEDIMIENTOS. Dirección de Administración y Finanzas. 48. Procedimiento para Otorgar Soporte Técnico.

MANUAL DE PROCEDIMIENTOS. Dirección de Administración y Finanzas. 48. Procedimiento para Otorgar Soporte Técnico. Hoja: 1 de 7 48. PROCEDIMIENTO PARA OTORGAR SOPORTE TÉCNICO Hoja: 2 de 7 1.0 Propósito 1.1 Que los equipos de cómputo estén en óptimas condiciones para que los usuarios mejoren las labores en cumplimiento

Más detalles

PROCEDIMIENTO DE EVALUACIÓN Y ACREDITACIÓN DE LAS COMPETENCIAS PROFESIONALES CUESTIONARIO DE AUTOEVALUACIÓN PARA LAS TRABAJADORAS Y TRABAJADORES

PROCEDIMIENTO DE EVALUACIÓN Y ACREDITACIÓN DE LAS COMPETENCIAS PROFESIONALES CUESTIONARIO DE AUTOEVALUACIÓN PARA LAS TRABAJADORAS Y TRABAJADORES MINISTERIO DE EDUCACIÓN SECRETARÍA DE ESTADO DE EDUCACIÓN Y FORMACIÓN PROFESIONAL DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES PROCEDIMIENTO DE EVALUACIÓN Y ACREDITACIÓN

Más detalles

AG-IN-02 Instructivo para la elaboración de diagramas de flujo

AG-IN-02 Instructivo para la elaboración de diagramas de flujo AG-IN-02: Instructivo para la elaboración de s de flujo 1. Propósito Definir los lineamientos que se deben aplicar para elaboración de los s de flujo de los procesos de la ARESEP. 2. Alcance Aplica de

Más detalles

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

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

Más detalles

BOLETÍN OFICIAL DEL ESTADO

BOLETÍN OFICIAL DEL ESTADO Núm. 185 Martes 4 de agosto de 2015 Sec. I. Pág. 69634 ANEXO XV Cualificación profesional: Administración y Programación en Sistemas de Planificación de Recursos Empresariales y de Gestión de Relaciones

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

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

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

Más detalles

IBM Managed Security Services para Redespliegue y Reactivación del Agente

IBM Managed Security Services para Redespliegue y Reactivación del Agente Descripción de los Servicios IBM Managed Security Services para Redespliegue y Reactivación del Agente EN ADICIÓN A LOS TÉRMINOS Y CONDICIONES ESPECIFICADOS ABAJO, ESTA DESCRIPCIÓN DE SERVICIOS INCLUYE

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

Registro y Seguimiento a las Solicitudes en el Centro de Asistencia Técnica (CAT)

Registro y Seguimiento a las Solicitudes en el Centro de Asistencia Técnica (CAT) Página 1 de 5 1. Objetivo y Alcance Establecer los lineamientos necesarios para registrar las solicitudes técnicas y realizar el seguimiento adecuado en el. Este instructivo comprende desde la Asignación

Más detalles

Manual adhoc System. apoyotecnico@calidad.com.mx

Manual adhoc System. apoyotecnico@calidad.com.mx Av Montevideo No 172- A1 apoyotecnico@calidadcommx Av Montevideo No 172- A1 Col Lindavista CP 07300 México, D F 1 Contenido FUNCIONAMIENTO GENERAL DEL SOFTWARE 3 LOG IN 3 TAREAS PENDIENTES 3 DOCUMENTOS

Más detalles

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO n Objetivo

Más detalles

PLAN DE DESARROLLO DEL PROYECTO SOFTWARE

PLAN DE DESARROLLO DEL PROYECTO SOFTWARE PAGINA 1-5 PLAN DE DESARROLLO DEL PROYECTO SOFTWARE ELABORO REVISO AUTORIZO PAGINA 2-5 Plan de Desarrollo del Proyecto Proyecto: Sistema de información para hoteles y demás establecimientos del sector

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE UNIVERSIDAD DEL CAUCA FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

Más detalles

MS_10748 Deploying System Center 2012, Configuration Manager

MS_10748 Deploying System Center 2012, Configuration Manager Deploying System Center 2012, Configuration Manager www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso describe cómo planificar

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Cuarta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

IES Lloixa. Índice de contenido

IES Lloixa. Índice de contenido Departamento: Informática Etapa: Bachillerato Asignatura: Tecnologías de la información y la comunicación II Curso: 2º Nº horas/sem.: 4 Legislación: Currículo: Ord. 17/6/2009 DOGV nº 6051 de 7/7/2009 pá.

Más detalles

ANEXO N 11 PASE A PRODUCCION

ANEXO N 11 PASE A PRODUCCION ANEXO N 11 PASE A PRODUCCION Versión 1.0 84 Tabla de Contenidos 1 Finalidad 86 2 Alcance 86 3 Base legal 86 4 Responsable 86 5 Roles 86 6 Normas generales 87 7 Procedimiento. 88 8 ANEXO 11.1 91 85 1 Finalidad

Más detalles

[Clave Proyecto] - Plan de Administración de la Configuración del Proyecto

[Clave Proyecto] - Plan de Administración de la Configuración del Proyecto [Clave Proyecto] - Plan de Administración de la Configuración del Proyecto Contenido 1. Historial de Cambios... 3 1.1. Cambios de Contenido... 3 1.2. Aprobación de Cambios... 3 1.3. Cambios de Plantilla...

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

Project 2013. Ing. Christian Ovalle

Project 2013. Ing. Christian Ovalle 2013 Ing. Christian Ovalle PROJECT Antes de comenzar un proyecto se necesitan definir los objetivos de un proyecto y luego determinado, cuales son las tareas que necesita realizar para alcanzar ese objetivo.

Más detalles

C O N T E N I D O. 1. Propósito. 2. Alcance. 3. Responsabilidad y autoridad. 4. Normatividad aplicable. 5. Políticas

C O N T E N I D O. 1. Propósito. 2. Alcance. 3. Responsabilidad y autoridad. 4. Normatividad aplicable. 5. Políticas C O N T E N I D O 1. Propósito 2. Alcance 3. Responsabilidad autoridad 4. Normatividad aplicable 5. Políticas 6. Diagrama de bloque procedimiento 7. Glosario 8. Anexos 9. Revisión Histórica 1/12 1. Propósito

Más detalles

Capacidades y criterios de evaluación:

Capacidades y criterios de evaluación: UNIDAD FORMATIVA DATOS IDENTIFICATIVOS DE LA UNIDAD FORMATIVA GESTIÓN Y CONTROL DE LOS SISTEMAS DE INFORMACIÓN. DURACIÓN 70 Específica Código UF1643 Familia profesional INFORMÁTICA Y COMUNICACIONES Área

Más detalles

6.6 CONTROLAR EL CRONOGRAMA PROYECTO TÉCNICO

6.6 CONTROLAR EL CRONOGRAMA PROYECTO TÉCNICO 6.6 CONTROLAR EL CRONOGRAMA PROYECTO TÉCNICO Documento redactado por Documento revisado por Documento aprobado por Alberto Arnáez Jordi Labandeira 14-08-12 Joaquín de Abreu 02-09-12 David Naranjo 29-08-12

Más detalles

ÁREA DE RECURSOS HUMANOS Servicio Técnico de Coordinación y Planificación de Recursos Humanos

ÁREA DE RECURSOS HUMANOS Servicio Técnico de Coordinación y Planificación de Recursos Humanos ÁREA DE RECURSOS HUMANOS Servicio Técnico de Coordinación y Planificación de Recursos Humanos PLIEGOS DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA CONTRATACIÓN DEL SERVICIO DE MANTENIMIENTO CORRECTIVO

Más detalles

Certificados de Profesionalidad Catálogo Modular

Certificados de Profesionalidad Catálogo Modular Nivel 1, INFORMÁTICA Y TELECOMUNICACIONES CERTIFICADOS DE PROFESIONALIDAD MÓDULOS FORMATIVOS UNIDADES DE COMPETENCIA IFCT0108: Operaciones auxiliares de montaje y mantenimiento de sistemas microinformáticos

Más detalles

MANUAL TIPO DE POLÍTICAS Y PROCEDIMIENTOS:

MANUAL TIPO DE POLÍTICAS Y PROCEDIMIENTOS: MANUAL TIPO DE POLÍTICAS Y PROCEDIMIENTOS: ADMINISTRACIÓN DE AUDIENCIAS ADMINISTRACIÓN DE CARPETAS JUDICIALES NOTIFICACIONES ELABORACIÓN DE TRANSCRIPCIONES ADMINISTRACIÓN DE AUDIENCIAS DE SEGUIMIENTO DE

Más detalles

Servicio HP StoreOnce Catalyst Solution

Servicio HP StoreOnce Catalyst Solution Datos técnicos Servicio HP StoreOnce Catalyst Solution Servicios HP Ventajas del servicio Este servicio comprende la implementación del software HP StoreOnce Catalyst en su entorno de almacenamiento, según

Más detalles

PROCEDIMIENTO RED Y COMUNICACIÓN DE DATOS

PROCEDIMIENTO RED Y COMUNICACIÓN DE DATOS P-06-05 Marzo 2009 03 1 de 7 1. OBJETIVO Asegurar el funcionamiento eficiente y seguro de la Local Area Network (LAN) y de las telecomunicaciones en la Comisión Nacional de los Salarios Mínimos (CONASAMI),

Más detalles

PROCEDIMIENTO OPERATIVO TOMA FISICA DE INVENTARIOS DE ACTIVO CIRCULANTE EN LOS ALMACENES DE LAS UNIDADES MÉDICAS Y DEPARTAMENTO DE ALMACENES

PROCEDIMIENTO OPERATIVO TOMA FISICA DE INVENTARIOS DE ACTIVO CIRCULANTE EN LOS ALMACENES DE LAS UNIDADES MÉDICAS Y DEPARTAMENTO DE ALMACENES Autorización Este documento entra en vigor a partir del 15 de Febrero de 2007, a través de la autorización por parte del Lic. Jorge Cruz Medrano, Coordinador de Administración del Instituto de Seguridad

Más detalles

14 pasos para lograr la calidad en construcción

14 pasos para lograr la calidad en construcción 14 pasos para lograr la calidad en construcción 1. Junta para analizar requerimientos del Proyecto 2. Benchmark (Estándar de Calidad) 3. Calibración de herramientas de inspección 4. Pruebas de laboratorio

Más detalles

Gestión de la Configuración

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

Más detalles

1. CAPÍTULO III ANÁLISIS DEL SISTEMA

1. CAPÍTULO III ANÁLISIS DEL SISTEMA 37 1. CAPÍTULO III ANÁLISIS DEL SISTEMA 3.1. FACTIBILIDAD DEL PROYECTO. Se ha desarrollado un estudio de factibilidad el cual incluye la parte técnica, operacional y financiera; para determinar si se podrá

Más detalles

DOCUMENTO DE CONSTRUCCIÓN SOLUCIÓN DE NO CONFORMIDADES ISO 9000 Bizagi Process Modeler

DOCUMENTO DE CONSTRUCCIÓN SOLUCIÓN DE NO CONFORMIDADES ISO 9000 Bizagi Process Modeler SOLUCIÓN DE NO CONFORMIDADES ISO Bizagi Process Modeler Copyright 2011 - bizagi Contenido 1. DIAGRAMA DEL PROCESO... 3 Sub proceso Acción Correctiva... 4 Ejecutar Plan de Acción... 5 2. PROCESO ACCIÓN

Más detalles

M-SARE-01 Manual. Titular de la COFEMER.

M-SARE-01 Manual. Titular de la COFEMER. Febrero 2013 Datos del Documento Código del documento: Tipo de documento: del documento: Versión: 02 Revisado por: Aprobado por: M--01 Manual Titular de la COFEMER. HISTORIAL DE CAMBIOS: Versión Fecha

Más detalles

Procedimiento de Paso a Producción de un Nuevo Sistema

Procedimiento de Paso a Producción de un Nuevo Sistema SERVICIO NACIONAL PARA LA PREVENCIÓN Y REHABILITACIÓN DEL CONSUMO DE DROGAS Y ALCOHOL Procedimiento de Paso a Producción de un Nuevo Sistema Sistema de Gestión de la Seguridad de la Información Código:

Más detalles

MACROPROCESO GESTIÓN TECNOLÓGICA

MACROPROCESO GESTIÓN TECNOLÓGICA Versión 1.0 Página 1 de 5 1. OBJETIVO Suministrar las fases para la puesta en producción de aplicaciones y sistemas de información desarrollados o adquiridos por el Instituto Colombiano de Bienestar Familiar

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

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

Más detalles

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0 Especificación de requisitos de software Proyecto: (Sistema de Información de Seminarios WEB) Revisión 1.0 Tania Isadora Mora Dorance Moreno Luis Yovany Romo Septiembre 2007 Realizado Por: Tania I. Mora

Más detalles

Touring y Automóvil Club del Perú

Touring y Automóvil Club del Perú 15/04/15 Versión: 08 Pág. 1 de 5 1. OBJETIVO 2. ALCANCE Establecer las actividades a seguir para realizar el correcto mantenimiento de las Bases de Datos del TACP. Este procedimiento es de aplicación para

Más detalles

1º CFGS ASIR IMPLANTACIÓN DE SISTEMAS OPERATIVOS

1º CFGS ASIR IMPLANTACIÓN DE SISTEMAS OPERATIVOS 1º CFGS ASIR IMPLANTACIÓN DE SISTEMAS OPERATIVOS OBJETIVOS La formación del módulo contribuye a alcanzar los objetivos generales de este ciclo formativo que se relacionan a continuación: a. Analizar la

Más detalles

DESCRIPCIÓN FUNCIONAL API XBRL-PGC2007

DESCRIPCIÓN FUNCIONAL API XBRL-PGC2007 DESCRIPCIÓN FUNCIONAL API XBRL-PGC2007 ADAPTACIÓN DEL MÓDULO DE SOFTWARE DE TRATAMIENTO DE INFORMES XBRL A LA NUEVA VERSIÓN DE LA TAXONOMÍA PGC2007 (V1.4.1) Noviembre 2011 ÍNDICE 1. INTRODUCCIÓN 2. DESCRIPCIÓN

Más detalles

PEDRO ALFONSO DUARTE FUENTES

PEDRO ALFONSO DUARTE FUENTES Nombre: PEDRO ALFONSO DUARTE FUENTES Profesión: Ingeniero de Sistemas- Especialista en Construcción de software. Especialista en Seguros y Seguridad Social. M. Profesional No: 25255202569CND Fecha de Nacimiento:

Más detalles

1. OBJETIVO Establecer los mecanismos para realizar copias de seguridad y restauración de los servicios o servidores del Senado de la Republica.

1. OBJETIVO Establecer los mecanismos para realizar copias de seguridad y restauración de los servicios o servidores del Senado de la Republica. 1. OBJETIVO Establecer los mecanismos para realizar copias de seguridad y restauración de los servicios o servidores del Senado de la Republica. 2. ALCANCE Este procedimiento aplica a todos los servicios

Más detalles

Certificado de Profesionalidad CONTROL DE PROYECTOS Y OBRAS DE CONSTRUCCIÓN [Nivel 3]

Certificado de Profesionalidad CONTROL DE PROYECTOS Y OBRAS DE CONSTRUCCIÓN [Nivel 3] EDIFICACIÓN Y OBRA CIVIL Certificado de Profesionalidad CONTROL DE PROYECTOS Y OBRAS DE CONSTRUCCIÓN [Nivel 3] 2 EDIFICACIÓN Y OBRA CIVIL Certificado de Profesionalidad Control de proyectos y obras de

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

Análisis y Diseño de Soluciones de Software

Análisis y Diseño de Soluciones de Software Página 1 de 5 1. Objetivo y Alcance Identificar a los stakeholders, definir el límite del sistema, e identificar los apremios impuestos ante el sistema, para posteriormente transformar esos requerimientos

Más detalles

B.2.2. Principios para la gestión de proyectos

B.2.2. Principios para la gestión de proyectos B.2.2. Principios para la gestión de proyectos La gestión de proyectos es la aplicación de conocimientos, conocimiento técnico, herramientas y técnicas para planificar actividades a fin de satisfacer o

Más detalles

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes TIC-1-1 Analista de monitoreo de redes Monitorear y controlar las redes del GCABA con el fin de detectar incidentes y reportarlos. Analizar las métricas utilizadas para el monitoreo de la red, la configuración

Más detalles

Procedimiento de Sistemas de Información

Procedimiento de Sistemas de Información Procedimiento de Sistemas de Información DIRECCIÓN DE COORDINACIÓN TÉCNICA Y PLANEACIÓN VIEMBRE DE 2009 PR-DCTYP-08 Índice. 1. INTRODUCCIÓN.... 3 2. OBJETIVO.... 4 3. ALCANCE.... 4 4. MARCO LEGAL.... 4

Más detalles

Programa de Apoyo a la Gestión del Clima y la Convivencia Escolar. Documento para la Asesoría Técnico Pedagógica

Programa de Apoyo a la Gestión del Clima y la Convivencia Escolar. Documento para la Asesoría Técnico Pedagógica 2013 Programa de Apoyo a la Gestión del Clima y la Convivencia Escolar Documento para la Asesoría Técnico Pedagógica 2013 Programa de Apoyo a la Gestión del Clima y la Convivencia Escolar Documento para

Más detalles

PROCEDIMIENTO PARA EL CONTROL DE DOCUMENTOS Y REGISTROS

PROCEDIMIENTO PARA EL CONTROL DE DOCUMENTOS Y REGISTROS . PROCEDIMIENTO PARA EL CONTROL DE DOCUMENTOS Y REGISTROS Página 1 de 18 APROBACIÓN DEL DOCUMENTO ELABORA: REVISA: APRUEBA: CONTROL DE CAMBIOS VERSIÓN DESCRIPCION DE LA MODIFICACION FECHA 6 Se reemplaza

Más detalles

Automatizacion Industrial

Automatizacion Industrial Este documento tiene por finalidad presentar nuestro esquema de trabajo asociado a las tareas de suministro de equipos y programación-configuración de un sistema de control incluidas sus pruebas, comisionamiento,

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

IMPLEMENTACIÓN DE UN SISTEMA DE CALIDAD EN LABORATORIOS DE CALIBRACIÓN Y ENSAYO. BASADO EN LA ISO/IEC 17025 MP-22D-V1

IMPLEMENTACIÓN DE UN SISTEMA DE CALIDAD EN LABORATORIOS DE CALIBRACIÓN Y ENSAYO. BASADO EN LA ISO/IEC 17025 MP-22D-V1 IMPLEMENTACIÓN DE UN SISTEMA DE CALIDAD EN LABORATORIOS DE CALIBRACIÓN Y ENSAYO. BASADO EN LA ISO/IEC 17025 1 Duración 12 horas ISO 9000:2000 Tecnología Aplicada Guía 17025 IMPLEMENTACIÓN DE UN SISTEMA

Más detalles

PROCEDIMIENTO SERVICIO DE COMUNICACIÓN DE VOZ

PROCEDIMIENTO SERVICIO DE COMUNICACIÓN DE VOZ P-06-06 Marzo 2009 00 1 de 6 1. OBJETIVO Asegurar el funcionamiento eficiente del servicio de comunicación de voz en la Comisión Nacional de los Salarios Mínimos (CONASAMI), a través de la Red Privada

Más detalles

10 Cuáles de las siguientes afirmaciones acerca de la Biblioteca Definitiva de Medios (DML) son CORRECTAS? 1. La DML incluye un almacén físico

10 Cuáles de las siguientes afirmaciones acerca de la Biblioteca Definitiva de Medios (DML) son CORRECTAS? 1. La DML incluye un almacén físico 1 De cuáles procesos la Gestión de Niveles de Servicios podría tomar en cuenta entradas de información para cuando esté negociando Acuerdos de Nivel de Servicio (SLA)? a) De todos los demás procesos de

Más detalles

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

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

Más detalles

Manual de usuario del módulo DEM Cliente

Manual de usuario del módulo DEM Cliente Manual de usuario del módulo DEM Cliente Febrero, 2012 Manual de usuario del módulo DEM Cliente INTRODUCCIÓN... 3 OBJETIVO... 3 REQUERIMIENTOS... 4 Equipo... 4 Software... 4 Conocimientos del usuario...

Más detalles

Fecha: Julio 2009. A nivel externo, este procedimiento es aplicable al proveedor del sistema informático.

Fecha: Julio 2009. A nivel externo, este procedimiento es aplicable al proveedor del sistema informático. 1 de 8 1.- OBJETIVO. Atender las peticiones solicitadas por los con motivo de una mejora al sistema informático, corrección de un posible error o para cubrir una necesidad generada durante la operació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

Manual de Procedimientos

Manual de Procedimientos 1 de 34 5.0 Mayo de 2010 Elaborado por: Revisado por: Aprobado por: Oficina de Planeación y Desarrollo Institucional -Área de Calidad y Mejoramiento- Coordinador del Área de Calidad y Mejoramiento Jefe

Más detalles

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto ADMINISTRACIÓN DE PROYECTO GESTOR DE LICITACIONES Empresa KOOMONI Memoria que como parte de los requisitos para obtener el título de: INGENIERIO

Más detalles

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

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

Más detalles