METODOLOGÍA DE GESTION DE PROYECTOS

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

Download "METODOLOGÍA DE GESTION DE PROYECTOS"

Transcripción

1 METODOLOGÍA DE GESTION DE PROYECTOS

2 CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO ETAPA 0: INICIACIÓN...5 FASE DE INICIO ETAPA 1: PLANEAMIENTO...6 FASE DE PLANIFICACIÓN DEL PROYECTO ETAPA 2: EJECUCIÓN...6 FASE DE DISEÑO Y DESARROLLO...6 FASE DE INTEGRACIÓN...6 FASE DE VALIDACIÓN Y VERIFICACIÓN...6 FASE DE IMPLEMENTACIÓN MONITOREO Y CONTROL DEL PROYECTO ETAPA 3: CIERRE...7 ESTRUCTURA Y EQUIPO, ROLES Y RESPONSABILIDADES ROLES Y RESPONSABILIDADES PROJECT MANAGER CLIENTE (O INTERLOCUTOR FORMAL) PROJECT MANAGER PBS BOARD ARQUITECTO SOLUCIÓN ANALISTA FUNCIONAL DESARROLLADOR ANALISTA TESTER ADMINISTRADOR DE LA CONFIGURACIÓN...10 ENTREGABLES ENTREGABLES POR ETAPA DETALLE DE ENTREGABLES POR FASE DESCRIPCIÓN DE ENTREGABLES...12 PROPUESTA DE SERVICIO...12 ESPECIFICACIÓN DE REQUERIMIENTOS...13 ARQUITECTURA Y DISEÑO ALTO NIVEL...13 PLAN GENERAL DE PROYECTO...13 CRONOGRAMA...13 DISEÑO DETALLADO...14 VERSIÓN DESARROLLO (CARÁCTER INTERNO PBS)...14 VERSIÓN CANDIDATA (CARÁCTER INTERNO PBS)...14 VERSIÓN FINAL...14 VERSIÓN PRODUCCIÓN...15 CASOS DE PRUEBA (CARÁCTER INTERNO PBS)...15 REPORTE DE PRUEBA (CARÁCTER INTERNO PBS)...15 MANUALES...15 INFORME DE AVANCE...15 Página 2 de 19

3 SOLICITUD DE CAMBIO...16 DOCUMENTOS ACTUALIZADOS...16 LECCIONES APRENDIDAS (DOCUMENTO DE CARÁCTER INTERNO PBS)...16 ANEXO CONTROL DE CALIDAD EL MODELO V METODOLOGÍA DE VERIFICACIÓN Y VALIDACIÓN...18 ACTIVIDADES DE VALIDACIÓN Y VERIFICACIÓN...18 Página 3 de 19

4 ALCANCE Este documento contiene una descripción resumida de la Metodología de Gestión de Proyectos, PBSTRES, utilizada por Pampa Business Solutions SRL (en adelante PBS) MARCO METODOLÓGICO PBSTRES es el la Metodología de Gestión de Proyectos creada por PBS como marco metodológico a los proyectos que administra. PBSTRES está basada en un estándar mundialmente reconocido en la gestión de proyectos, Metodología de Project Management del PMI (Project Management Institute). En aspectos relacionados con el desarrollo de Software PBSTRES toma como base el Modelo de calidad CMMI (Capability Maturity Model Integration) del SEI (Software Engeenering Institute). Asimismo se encuentra alineada, en aspectos relacionados con la gestión de la calidad, al Standard ISO 9001:2000. PBS cuenta en su equipo con skills de Project Manager Professional (Credencial PMP del PMI), consultor CMMI (Curso Oficial del SEI y Experiencia en implementación del Modelo) y Auditor interno ISO 9001:2000 quienes trabajaron en la creación este marco. Página 4 de 19

5 ETAPAS DEL PROCESO PBSTRES divide al proyecto en las siguientes grandes Etapas: INICIACIÓN PLANEAMIENTO EJECUCIÓN CIERRE Y una Etapa cross a todo el proyecto denominada MONITOREO Y CONTROL (En el gráfico puede verse bajo los puntos de Control que acompañan a las Fases del Proyecto) Cada una de las Etapas contiene una o más Fases del ciclo de Vida del Proyecto Esta metodología representa un modelo/guía a seguir en la gestión de nuestros proyectos, basada en buenas prácticas del mercado. Su aplicación puede ser adaptada al tipo, tamaño de proyecto y demás características respetando una de nuestras fortalezas que resulta ser la flexibilidad de PBS. 1. ETAPA 0: INICIACIÓN El objetivo de esta Etapa es dar por comienzo a un nuevo Proyecto ó Fase del mismo. Dentro de esta etapa se incluye la elaboración de la propuesta y su refinamiento hasta aprobación para dar inicio a la siguiente etapa de Planeamiento. Esta Etapa puede iniciarse por un requerimiento de un cliente o bien por una iniciativa interna para la incorporación de un nuevo producto o servicio al portfolio de PBS. En esta instancia el estudio de factibilidad del proyecto se supone ya ha sido superado. FASE DE INICIO PBS asigna un Project Manager. Definir los requerimientos del producto. Identificar grandes riesgos y alternativas de respuesta. Identificar alternativas y realizar recomendaciones a ser tenidas en cuenta a lo largo del proyecto. Generar documento de propuesta para aprobación. Identificar interlocutores por parte del Cliente y de PBS. Generar Plan Preliminar del proyecto (puede ser o no parte de la misma propuesta). Obtener aprobación. Página 5 de 19

6 2. ETAPA 1: PLANEAMIENTO En esta Etapa se refinan las tareas de definición de alcance del proyecto y se elabora en detalle el Plan General del Proyecto FASE DE PLANIFICACIÓN DEL PROYECTO Asignar el equipo de proyecto. Identificar Stakeholders (partes interesadas) del proyecto. Formación del Board (Ver Estructura y Equipo, Roles y Responsabilidades 1.3BOARD). Refinar alcance del proyecto. Elaboración detallada de Plan General de proyecto que contempla aspectos tales como recursos, cronograma detallado, gestión de riesgos, plan de comunicación, de monitoreo y control y de transición entre otros aspectos. Seleccionar la alternativa técnica a implementar. Planificar tareas de Validación y Verificación. Obtener aprobación por parte del Board y generar Línea Base de Requerimientos. 3. ETAPA 2: EJECUCIÓN En esta Etapa se pone en marcha el Plan de Proyecto de manera de obtener como resultado el producto ó servicio dado. A continuación se enumeran las grandes tareas a realizar. De acuerdo al ciclo de vida de Desarrollo utilizado pueden implementarse mediante distintas iteraciones o bien en cascada. FASE DE DISEÑO Y DESARROLLO Refinar la Arquitectura planteada. Elaborar un diseño detallado. Desarrollar todos los componentes. Realizar pruebas unitarias a los componentes. Comenzar la etapa de administración de control de cambios. Integrar cada uno de los módulos. Generación de prototipos. Preparar los módulos para su testeo de integración. FASE DE INTEGRACIÓN Integración de los distintos módulos e interfaces. Integración con productos de terceros. Preparar la aplicación para las pruebas integrales y de sistemas. FASE DE VALIDACIÓN Y VERIFICACIÓN Esta fase acompaña a toda la construcción e integración mediante las tareas de Verificación y Validación. (Ver Anexo Control de Calidad). Verificar la documentación del proyecto (especificación de requerimientos, documentación de diseño) para asegurar consistencia. Preparación de los casos de prueba de acuerdo a los requerimientos de manera de asegurar que el producto cumple con las especificaciones. Ejecución de las pruebas integrales y de sistema. Reportar errores y seguimiento hasta su cierre. Página 6 de 19

7 FASE DE IMPLEMENTACIÓN Desplegar la solución en el ambiente de producción del cliente de acuerdo al plan de despliegue conjunto. Asegurar el correcto despliegue que permita realizar las Pruebas de Aceptación del Cliente. Realizar ajustes finales. Obtener Conformidad y aprobación por parte del Cliente. 4. MONITOREO Y CONTROL DEL PROYECTO El Monitoreo y Control del proyecto acompaña a todo el Ciclo de Vida del Proyecto. Formalmente se establecen puntos de Control al finalizar cada Fase en los cuales se solicita aprobación para pasar a la fase siguiente. Típicamente se genera algún reporte o informe de fin de Fase. De acuerdo a la complejidad, tamaño y características del proyecto el cliente puede participar de la aprobación para pasar a la siguiente fase o bien ser informado de la transición. Asimismo durante todo el ciclo de Vida del proyecto el Project Manager monitorea y controla las distintas restricciones: Alcance, Tiempo, Costos, Riesgos, Calidad y Satisfacción del Cliente. Esto lo hace a través del seguimiento de los planes, feedback que recibe del Equipo de Proyecto en las reuniones y seguimiento con el cliente generando así los distintos informes. Esta Etapa también contempla la Gestión de los Cambios del proyecto. Una vez definida y aprobada la Línea Base* de Requerimientos por ambas partes (Board), los Cambios que se introduzcan serán gestionados mediante Solicitudes de Cambio. Una Solicitud de Cambio puede ser generada por el cliente o bien por el Equipo de Proyecto al identificar algún cambio que se considera necesario para el cumplimiento de las distintas restricciones. Los Cambios son gestionados a través del Procedimiento de Administración de Cambios definido previamente en el Plan General de Proyecto. En líneas generales, se analiza el impacto, se requiere aprobación por parte del Board (o representantes del cliente y PBS) y, en caso de ser aprobado, se actualizan los planes. *Línea Base de Requerimientos: Conjunto de Requerimientos en un momento dado que definen el alcance del proyecto 5. ETAPA 3: CIERRE Esta Etapa comprende la transición que asegure la completa operatividad del producto en el ambiente de producción del cliente así como el cierre del Proyecto. Traspaso de Información Operativa: Traspaso de información necesaria referida a la Gestión de los Requerimientos, de manera tal que el Cliente pueda tomar la misma para la continuidad del servicio: Ej. backlogs de tareas pendientes, cumplidas, etc. Traspaso de los sistemas mantenidos por PBS: compuesto por tareas de asesoramiento sobre los sistemas e infraestructura necesaria para la correcta instalación de los mismos en las instalaciones que disponga el Cliente. Transferencia de documentación: Actualización de documentación con las últimas modificaciones. Obtener aprobación formal por parte del cliente. Asegurar la Garantía según contrato. Atender requerimientos de cambio (Mantenimiento). Cierre del proyecto: Lecciones Aprendidas. Página 7 de 19

8 ESTRUCTURA Y EQUIPO, ROLES Y RESPONSABILIDADES El Equipo de Proyecto se conforma de acuerdo a la complejidad, tamaño y otras características del proyecto. Típicamente está conformado por los roles que se indican en 1ROLES Y RESPONSABILIDADES. Para proyectos pequeños, probablemente el mismo miembro del equipo realice más de un rol. Asimismo existen roles tales como Arquitecto de Software, Administración de la Configuración que tiene una asignación part time, especialmente el primero, que presta mayormente servicios de consultoría inicial. Estos son expresados como Soporte en el diagrama. Idealmente se piensa en una estructura en la cual se tiene un interlocutor del lado del cliente y un interlocutor del lado de PBS de manera de efectivizar las comunicaciones y agilizar las decisiones. Estas figuras conforman el Board que podría o no estar formalmente establecido. * Dentro de la subestructura Soporte se incluyen Roles tales como Arquitecto Solución, Administrador de la Configuración, etc. que prestan servicios a distintos proyectos. Esto es porque se considera óptima su agrupación en una subestructura especializada que concentre conocimientos específicos de Arquitectura, Tecnología, etc. 1. ROLES Y RESPONSABILIDADES 1.1. PROJECT MANAGER CLIENTE (O INTERLOCUTOR FORMAL) Con el objetivo de facilitar y efectivizar la comunicación y toma de decisiones PBS solicita que se nombre una persona que oficie como Representante del Cliente a quien se denomina Project Manager Cliente. Este rol es crucial en el éxito del proyecto. Representa la máxima autoridad por parte del cliente para el proyecto y su interrelación directa es con el Project Manager PBS Página 8 de 19

9 El Project Manager Cliente es responsable de: Monitorear el estado y avance del proyecto. Reflejar las necesidades de los Key Users. Gestionar la resolución de dudas o algún tipo de problema que vaya surgiendo a lo largo del proyecto sirviendo de nexo ente los Key Users y PBS. Aprobar los documentos relacionados con el proyecto. Establecer las prioridades en cuanto a los requerimientos PROJECT MANAGER PBS El Project Manager PBS es responsable de: Estimar el esfuerzo necesario para la realización del proyecto. Confeccionar la propuesta de Servicio. Generar el Plan General del Proyecto y planes subsidiarios. Administrar el Proyecto asignado y sus recursos, de manera que cumpla con las múltiples restricciones que tiene: alcance, costos, tiempos, calidad, manejo de riesgos y satisfacción de cliente. Liderar el Proyecto asignado y conducir los recursos humanos del grupo de Proyecto. Supervisar la gestión integral de los colaboradores propios y del cliente (que participan como referentes en el proyecto). Revisar y aprobar los documentos presentados por su equipo. Conocer los procesos de negocio en función del área de incumbencia. Comunicar aspectos del proyecto. Mantener informado a los distintos stakeholders del proyecto BOARD El Board es un Comité formado por un representante por parte del cliente y un representante PBS. Típicamente lo componen los Project Manager de ambos lados. El Board podría estar formalmente establecido o no. De todos modos es responsabilidad de ambos representantes el trabajo en conjunto en aspectos relacionados con la toma de decisiones, priorización, aprobación, etc. de manera de obtener consenso de ambas partes: Analizar y aprobar requerimientos, documentos y planes. Gestionar la aprobación de ambas partes. Aprobar la Línea Base de Requerimientos. Analizar y aprobar o rechazar las Solicitudes de Cambio. Priorizar las Solicitudes de Cambio o Nuevas iniciativas. Obtener consenso en casos de discrepancia, por ejemplo en estimaciones, análisis de impacto de algún cambio, etc ARQUITECTO SOLUCIÓN El Arquitecto de la Solución tiene como responsabilidad: Definir y diseñar la arquitectura para soportar la aplicación. Definir y diseñar la configuración de los componentes de las aplicaciones. Comprender los requerimientos del sistema. Poseer Dominio de Ingeniería del Software. Tomar decisiones técnicas claves en términos de arquitectura. Documentar los aspectos significativos de la arquitectura, incluyendo requerimientos y las vistas de diseño, implementación y despliegue. Participar en las estimaciones, principalmente en términos de arquitectura Página 9 de 19

10 1.5. ANALISTA FUNCIONAL El Analista Funcional es responsable de: Identificar y comprender las necesidades del cliente de manera de obtener una especificación de requerimientos. Realizar tareas de Análisis y diseño de una solución que satisfaga las expectativas del cliente. Adicionalmente, supervisión de la programación, documentación, actualización y mantenimiento de los sistemas informáticos. Conocer y aplicar la metodología de desarrollo definida para el proyecto. Generar la Especificación del Sistema que sirva para codificar: Diseñar las entradas, salidas, archivos y programas de cada sistema. Generar la documentación técnica y de calidad. Participar de las estimaciones de tiempo y esfuerzo así como en la evolución de impacto ante un cambio DESARROLLADOR El desarrollador es responsable de: Comprender los requerimientos Detallados, Diseños y Especificaciones realizados por el Analista. Realizar tareas de Programación de la aplicación. Realizar el testeo de cada componente desarrollado según la documentación especifica para asegurar su buen funcionamiento (testeo unitario). Implementación, documentación, actualización y mantenimiento de las aplicaciones. Generar la documentación técnica y de calidad. Documentar programas de acuerdo a los estándares de instalación. Participar de las estimaciones dando feedback a los analistas de tiempos y esfuerzos ANALISTA TESTER El Analista Tester es responsable de: Diseñar Plan de Verificación y Validación /Testing (Ambientes de prueba, criterios de aceptación, criterios de suspensión de pruebas, etc.). Verificar la documentación para asegurar consistencia. Diseñar Condiciones y Casos de Prueba (Test Cases). Crear datos de prueba teniendo en cuenta formatos definidos y especificaciones. Ejecutar las pruebas para comparar resultados con las especificaciones. Analizar resultados de pruebas y documentar y reportar defectos, errores, e inconsistencias en las funciones de los programas, salidas, pantallas, y su contenido ADMINISTRADOR DE LA CONFIGURACIÓN La Gestión de la Configuración de versiones es un proceso que establece y mantiene la integridad del los artefactos a través de su ciclo de vida. Contempla aspectos tales como versionado de todos los artefactos (fuentes, documentos, etc.), historial de cambios, gestión de la política de back up, etc. El Administrador de la Configuración tiene como responsabilidades: Identificar los recursos requeridos por cada aplicación para ser administrados. Dar soporte a las tareas de desarrollo del proyecto, asegurando la disponibilidad de un ambiente de trabajo apropiado para el Equipo de Proyecto. Proveer un ambiente apropiado para las actividades de Validación/Testing. Liberar las correctas versiones de los componentes. Asegurar la disponibilidad e integridad de los diferentes artefactos para ser incluidos en la Unidad de despliegue cuando fuera necesario. Liberar a producción las correctas versiones de los componentes. Página 10 de 19

11 ENTREGABLES 1. ENTREGABLES POR ETAPA Página 11 de 19

12 2. DETALLE DE ENTREGABLES POR FASE Como se mencionara anteriormente, la metodología así como los entregables pueden adaptarse al tipo y características de proyecto o necesidades particulares del cliente. En proyectos chicos posiblemente algunos entregables puedan ser unificados o simplificados. Los documentos o artefactos mencionados como de Carácter Interno PBS tienen una propósito de gestión del proyecto en fases intermedias y no son necesariamente presentados al cliente como entregables del proyecto. 3. DESCRIPCIÓN DE ENTREGABLES PROPUESTA DE SERVICIO Contiene una descripción del alcance, solución, presupuesto y condiciones de contratación. Asimismo puede contener un cronograma preliminar, equipo de trabajo preliminar, roles y responsabilidades. El nivel de detalle de la misma puede variar de acuerdo a lo que solicite el cliente o bien el tiempo asignado/urgencia por parte del cliente para obtener la misma, etc. En cuanto al presupuesto y tiempos, puede estar expresado en Orden de Magnitud (donde se acepta cierta variación) o bien ser un presupuesto final. Esto también depende de lo que el cliente solicite como propuesta, nivel de información disponible, etc. En casos donde el cliente requiera algún tipo de formato especial o información particular (ejemplo: pliegos) la misma puede adaptarse a dichas especificaciones. Nomenclatura: [PROP_Cliente_Nombre del Proyecto_PBS] Página 12 de 19

13 ESPECIFICACIÓN DE REQUERIMIENTOS Definición inicial del Requerimiento de Software. Este documento reúne la documentación de los requerimientos (funcionales y no funcionales) de software del proyecto. Asimismo sirve como base del acuerdo común entre todas las partes y formará el contenido de la línea base. Incluye una descripción Global, definición de tipo de usuarios, lista de actores, características de la solución, ambiente de operación, supuestos y restricciones, requerimientos funcionales y no funcionales, interfaces necesarias y criterios de aceptación. Asimismo puede incluir una Visión General de la Arquitectura. Este documento puede llegar a un nivel de detalle mayor incluyendo casos de uso en términos de negocio u otros diagramas o bien estas cuestiones ser incluidas directamente en los documentos de diseño. Nomenclatura: [ERS_Cliente_Nombre del Proyecto_Nombre Req_PBS] ARQUITECTURA Y DISEÑO ALTO NIVEL Contiene una descripción y representación de la arquitectura de la solución, supuestos y restricciones de la misma, así como características de seguridad. Asimismo incluye aspectos de diseño de alto nivel tales como un análisis para la identificación de actores, definición de casos de uso en términos de negocio, etc. Este documento puede ser parte de la Especificación de Requerimientos o bien tratarse como documento separado. Nomenclatura: [DAG_Cliente_Nombre del Proyecto_PBS] PLAN GENERAL DE PROYECTO Define cómo se va a planificar, ejecutar, medir y controlar el proyecto. El Plan General de Proyecto es un documento madre que reúne distintos aspectos relacionados con la planificación de las distintas variables que intervienen en el proyecto. Puede ser un único Plan o bien hacer referencia a distintos planes o documentos subsidiarios tales como alcance, cronograma del proyecto, gestión de riesgos, Plan de Calidad (Validación y Verificación) y Plan de Gestión de la Configuración*. Asimismo incluye la planificación del Equipo de proyecto, skills, roles y responsabilidades, recursos materiales necesarios y aspectos relacionados con la comunicación tanto interna como con el Cliente. El Plan es armado de acuerdo a cada proyecto, es posible que en proyectos chicos o de determinadas características algunos ítems sean no aplicables o bien su nivel de detalle sea menor. * En el Plan de Gestión de la configuración se especifica aquellos artefactos (documentos, fuentes, etc.) que serán controlados, cómo se controlará la integridad de los mismos, políticas de backup, etc. Nomenclatura: [PGP_Cliente_Nombre del Proyecto_PBS] CRONOGRAMA Contiene las actividades con su fecha de inicio y fin, duración, secuenciamiento etc. El cronograma también incluye los hitos del proyecto. Nomenclatura: [SCH_Cliente_Nombre del Proyecto_PBS] Página 13 de 19

14 DISEÑO DETALLADO Contiene una definición de mayor detalle de los requerimientos. Según la metodología de desarrollo que se aplique y características del proyecto es posible incluir diagramas tales como: o Diagrama de Clases o Diagrama de Objetos o Diagrama de Actividades o Diagrama de Casos de Uso y descripción de los mismos o Interfaces y diseños de pantalla Este documento puede considerarse un refinamiento de la Especificación de Requerimientos y/o documentos de diseño de alto nivel o bien entregarse como documento aparte. Nomenclatura: [DAD_Cliente_Nombre del Proyecto_PBS] VERSIÓN DESARROLLO (CARÁCTER INTERNO PBS) Son las versiones intermedias generadas en el ambiente de desarrollo con los componentes desarrollados (Build). Según la planificación, durante el desarrollo se generan distintas versiones que son liberadas al ambiente de testing como versiones de prueba (test). La nomenclatura de las versiones varía según el proyecto y componentes de versión. Una versión podría contener distintos paquetes (ejemplo: librerías, dll s etc.). La nomenclatura del paquete que los agrupa sigue los siguientes lineamientos Tipos Build: Versión desarrollo Test: Versión liberada a testing Nomenclatura: [Numero de Versión]-[Tipo]-[Número de realease + 1] VERSIÓN CANDIDATA (CARÁCTER INTERNO PBS) Versión generada en etapa de integración de los distintos módulos. La misma es sujeta a pruebas de integración por parte del equipo de testing. A lo largo de esta etapa se generan distintas instancias de esta versión producto de las correcciones hasta obtener la versión final. Tipos RC: Versión candidata Nomenclatura: [Numero de Versión]-[Tipo]-[Número de realease + 1] VERSIÓN FINAL Corresponde a la versión que recibe el cliente para sus pruebas de aceptación. Tipos R: Versión Release Nomenclatura: [Numero de Versión]-[Tipo]-[Número de realease + 1] Página 14 de 19

15 VERSIÓN PRODUCCIÓN Versión productiva. Posiblemente tenga un número de release diferente a la versión de testing de aceptación debido a los ajustes finales que puedan surgir de estas pruebas. Tipos R: Versión Release Nomenclatura: [Numero de Versión]-[Tipo]-[Número de realease + 1] CASOS DE PRUEBA (CARÁCTER INTERNO PBS) Preparación estructurada de las pruebas a realizar sobre el software. Los casos de prueba se construyen de acuerdo a la especificación de requerimientos y son una enunciación de las distintas situaciones a probar. Los mismos contienen una descripción de la prueba, los datos de entrada, pasos a seguir y resultado esperado de la prueba. Nomenclatura: [TCS_Cliente_Nombre del Proyecto_Req_Nro Caso_PBS] REPORTE DE PRUEBA (CARÁCTER INTERNO PBS) Los defectos, mejoras, etc. identificados durante las pruebas son registrados e informados a desarrollo para su corrección través de los reportes de prueba. Los Analistas Tester realizan el seguimiento de los distintos defectos hasta la verificación de su cierre. Nomenclatura: [REP_Cliente_Nombre del Proyecto_Tipo Prueba_PBS] MANUALES Los manuales o documentación de usuario final constituyen un entregable más al cliente y resultan clave en el aprendizaje del uso del sistema. Típicamente se manejan los siguientes tipos de manual: Manual de Usuario (Orientación al usuario final. Enfoque desde la operación del software) Manual del Sistema (Orientación técnica) Manual de Instalación En general el manual de Usuario y Sistema se presentan de manera unificada. Nomenclatura: [MAN_Cliente_Nombre del Proyecto_Tipo Manual_PBS] INFORME DE AVANCE La Etapa de Monitoreo y Control del Proyecto acompaña a todo el ciclo de vida del mismo. Como producto del seguimiento de las distintas variables que intervienen en el proyecto se generan, según frecuencia predefinida, los Informes de Avance del proyecto. El objetivo es reflejar el status del proyecto, detectar algún desvío e implementar, de manera temprana, acciones correctivas. Estos informes surgen de las reuniones con el Equipo de trabajo, reuniones con el cliente y seguimiento de indicadores y son distribuidos a las partes involucradas según plan. Nomenclatura: [INF_Cliente_Nombre del Proyecto_Fecha_PBS] Página 15 de 19

16 SOLICITUD DE CAMBIO Este documento se genera con el objeto de documentar un Cambio solicitado. El mismo incluye una descripción del cambio solicitado, motivo del cambio, quién lo solicita, requerimiento al cuál afecta, análisis de impacto del cambio y circuito de aprobaciones (Board, PBS, Cliente, etc.) Nomenclatura: [SCA_Cliente_Nombre del Proyecto_Req_Nro Solicitud_PBS] DOCUMENTOS ACTUALIZADOS Comprende la entrega al cliente de los documentos/entregables actualizados en su última versión con todos los ajuste que pudieron haberse incorporado en las instancias previas al cierre. LECCIONES APRENDIDAS (DOCUMENTO DE CARÁCTER INTERNO PBS) En PBS creemos que una de las claves del crecimiento es la mejora continua de nuestros procesos, productos y servicios. En este sentido cuidamos cada uno de nuestros proyectos incorporando mejoras a partir del aprendizaje. Al cierre del proyecto o, eventualmente al cierre de una fase en proyectos largos, se lleva a cabo la reunión de Lecciones Aprendidas que involucra a todo el equipo de Proyecto PBS con el objeto de rescatar los aspectos positivos del proyecto, potenciarlos, explotarlos y mejorarlos, y aquellos aspectos sobre los que se identifican oportunidades de mejora. Estas conclusiones son volcadas en el Documento de Lecciones Aprendidas. Nomenclatura: [LL_Cliente_Nombre del Proyecto _PBS] Página 16 de 19

17 ANEXO CONTROL DE CALIDAD La Metodología de Validación y Verificación utilizada por PBS se encuentra alineada con las Áreas de Procesos VAL y VER del modelo CMMI nivel 3 utilizando el Modelo V como referencia. 1. EL MODELO V El modelo V considera al testing una actividad importante en lugar de pensarlo como una amenaza al proyecto. Este modelo surge en reacción a ciertos modelos cascada que muestran al testing como una fase singular posterior al análisis, diseño de alto nivel, diseño detallado y desarrollo. El Modelo V representa varios niveles de testing e ilustra como cada nivel se encuentra alineado con una etapa del ciclo de vida de desarrollo. La V muestra, del lado izquierdo, la típica secuencia de actividades de desarrollo y, del lado derecho, su correspondiente secuencia de actividades de testing. Del lado del desarrollo, se comienza definiendo los requerimientos de negocio, estos se traducen en alto y bajo niveles de diseño y finalmente se implementan en líneas de código. Del lado de la ejecución del testing, se comienza con las pruebas unitarias, seguidas por las de integración, sistema y aceptación. Este modelo es valioso porque destaca la existencia de varios niveles de testing y delinea cómo se relaciona cada uno con diferentes fases del desarrollo. Las pruebas unitarias focalizan en los tipos de fallas que ocurren mientras se escribe código, tales como los valores límite en la validación de la entrada de datos del usuario. Las pruebas unitarias son típicamente realizadas por el mismo desarrollador. Las pruebas de integración se focalizan en el diseño de bajo nivel, especialmente chequeando errores entre interfaces y unidades u otras integraciones. Las pruebas de sistema validan si, el sistema como un todo, implementa efectivamente el diseño de alto nivel, incluyendo adecuada performance en un ambiente similar a producción. Las pruebas de Aceptación son típicamente realizadas por los usuarios (cliente) para confirmar que el producto reúne los requerimientos de negocio. En cada etapa de desarrollo, tienden a ocurrir diferentes tipos de fallas, de este modo distintas técnicas se utilizan para identificarlas. Página 17 de 19

18 2. METODOLOGÍA DE VERIFICACIÓN Y VALIDACIÓN VALIDACIÓN: Confirma que el producto, tal como se lo ofrece, cumplirá con el uso que se pretende. Las actividades de Validación en el proceso de desarrollo de Software tienen como principal objetivo determinar si se está construyendo el producto correcto, según las especificaciones del Cliente. Para esta finalidad se planifican, preparan, y ejecutan diferentes pruebas sobre el producto de software para realizar una evaluación objetiva del mismo. VERIFICACIÓN: El objetivo principal de la Verificación en el proceso de desarrollo de Software consiste en determinar si se está construyendo el producto correctamente. Para tal fin es necesario analizar los entregables, documentos, etc. en las diferentes etapas del Ciclo de Vida de desarrollo (etapa de requerimientos, etapa de diseño, etapa de codificación). En ambos casos se apunta a la identificación temprana de defectos o inconsistencias de manera de asegurar un producto confiable y minimizar la aparición de defectos en etapas finales. En este sentido nos basamos en un principio que indica que el esfuerzo requerido en la corrección de un defecto, cuanto más temprano sea detectado, menor impacto tendrá en el proyecto. ACTIVIDADES DE VALIDACIÓN Y VERIFICACIÓN A. ASIGNACIÓN DE ANALISTAS TESTERS AL PROYECTO De acuerdo a las necesidades del Proyecto se asignan uno o más Analistas Testers. B. GENERACIÓN DE PLAN DE CALIDAD El Analista Tester asignado planifica las actividades de Control de Calidad en el Proyecto e instancia un Plan de Validación y Verificación (En general, las actividades de Validación y Verificación son incluidas en el mismo Plan). C. VERIFICACIÓN DE LA DOCUMENTACIÓN Las actividades de Verificación tienen como objetivo la revisión de la documentación de manera de identificar tempranamente inconsistencias o cuestiones de lógica en los requerimientos, documentos de diseño, etc. y que las mismas sean comunicadas evitando que sean trasladadas a lo largo de las etapas de desarrollo. Estas inconsistencias de Documentación deben ser resueltas por el Analista o Desarrollador. D. PREPARACIÓN DE CASOS DE PRUEBA Los Casos de Prueba se generan tomando como input la documentación de Casos de Uso o la documentación de los Requerimientos/Funcionalidad que maneje el Proyecto. Para su confección, se dispone de un template donde se vuelcan las distintas pruebas a realizar, las pre-condiciones, postcondiciones, paso a paso, los resultados esperados, etc. Los Casos de Prueba se agrupan por Módulo, Subsistema, etc. y se almacenan en un repositorio, así como también los diferentes resultados de las ejecuciones. E. EJECUCIÓN DE LAS PRUEBAS Para la Ejecución de las pruebas se definen diferentes Fases. Cada Fase comprende un tipo de Testing diferente y se desarrollan diferentes Ciclos de Prueba, antecedidos por un Smoke Test (Prueba de Humo) que permite determinar rápidamente, mediante la validación de distintos aspectos predefinidos, si se sigue adelante o no con el testing. La Ejecución comienza con las siguientes Fases: Página 18 de 19

19 Testing Unitario Testing de Integración Testing de Sistema Cada Ciclo finaliza con una revisión formal de los resultados obtenidos y de los defectos detectados con el Líder de cada Módulo, Paquete o Subsistema. F. REPORTE DE PRUEBAS A medida que se ejecutan las Pruebas, los defectos, mejoras, etc detectados son reportados. Estos son asignados al responsable de cada tema y se realiza un seguimiento de cada uno de los defectos, mejoras, etc. hasta su cierre. Página 19 de 19

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

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

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

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

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

Más detalles

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

Resumen del Contenido del Examen PMP

Resumen del Contenido del Examen PMP Resumen del Contenido del Examen PMP Tareas Dominio I Inicio del Proyecto - 13 % Realizar una valoración del proyecto basada en la información disponible, mediante reuniones con el patrocinador, el cliente,

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

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

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

I. Información General del Procedimiento

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

Más detalles

Metodología de Gestión de Proyectos

Metodología de Gestión de Proyectos Metodología de Gestión de Proyectos Rodolfo Azzam PMP PMO y Calidad Banco Central de Chile GERENCIA DE INFORMATICA BANCO CENTRAL DE CHILE 1 Introducción La motivación por desarrollar un proyecto tecnológico

Más detalles

Descripción de las posiciones del área de sistemas

Descripción de las posiciones del área de sistemas Descripción de posiciones del área de Sistemas Operador/Data Entry Entrar y verificar datos provenientes de distintas vías de ingreso. Monitorear procesos, programas y resultados. Seguir los formatos apropiados

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

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

Plan de Administración del Proyecto

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

Más detalles

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

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

MODELOS DE ESTRUCTURA PARA LAS DIRECCIONES DE INFORMÁTICA

MODELOS DE ESTRUCTURA PARA LAS DIRECCIONES DE INFORMÁTICA MODELOS DE ESTRUCTURA PARA LAS DIRECCIONES DE INFORMÁTICA OPCION 1: PEQUEÑA ENVERGADURA DIRECCIÓN DE INFORMÁTICA DEPARTAMENTO DE SISTEMAS DEPARTAMENTO DE INFRAESTRUCTURA Y ASISTENCIA A USUARIOS DIRECCIÓN

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

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

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

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

[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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

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

Más detalles

Modelo de Proceso de Desarrollo de Software

Modelo de Proceso de Desarrollo de Software Modelo de Proceso de Desarrollo de Software Documento de Actividades Gestión de Configuración (S.C.M.) Ingeniería de Software - Proyecto de Taller5 Andrea Delgado & Beatriz Pérez ÍNDICE ÍNDICE... 1 GESTIÓN

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

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

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

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

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

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

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

Aragonesa de Servicios Telemáticos

Aragonesa de Servicios Telemáticos (AMS) en el Ámbito de Diversos Departamento y Organismos Públicos de la Administración de la Comunidad Autónoma de Aragón Índice 1! FICHA...3! 2! SITUACIÓN INICIAL...5! 3! OBJETIVOS...6! 4! SOLUCIÓN...7!

Más detalles

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

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

Más detalles

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

Definición de PMO Características de una PMO

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

Más detalles

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

Microsoft Dynamics Sure Step Fundamentos

Microsoft Dynamics Sure Step Fundamentos Fundamentos 06-10-2015/Serie Microsoft Dynamics Sure Step Proyectos Ágiles / Octubre 2015 Rosana Sánchez CCRM: @rosana-sanchez-2 Twitter: @rosansasanchez6 Correo: ingrossanbar@hotmail.com ingrossanbar@gmail.com

Más detalles

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

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

Más detalles

Marco Normativo de IT

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

Más detalles

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

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

Análisis y Diseño de Aplicaciones

Análisis y Diseño de Aplicaciones Análisis y Diseño de Aplicaciones Ciclo de Vida Docente: T/RT Gonzalo Martínez CETP EMT Informática 3er Año Introducción En el desarrollo de sistemas, el ciclo de vida son las etapas por las que pasa un

Más detalles

SOLICITUD DE DESARROLLO Y ACTUALIZACIÓN DE APLICACIONES G OBIERNO D E L A CIUDAD DE BUENOS AIRES

SOLICITUD DE DESARROLLO Y ACTUALIZACIÓN DE APLICACIONES G OBIERNO D E L A CIUDAD DE BUENOS AIRES G OBIERNO D E L A CIUDAD DE BUENOS AIRES D irección General Adjunta de Sistemas Infor máticos SOLICITUD DE DESARROLLO Y ACTUALIZACIÓN DE APLICACIONES Página 1 de 16 Fecha de creación: 25/02/2009 Tabla

Más detalles

calidad brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION ISO 9001:2000

calidad brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION ISO 9001:2000 calidad 2009 brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION Software Quality Assurance Project Management Dos de los factores que más positivamente

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

Examen de certificación Objetivos: PK0-003

Examen de certificación Objetivos: PK0-003 Examen de certificación Objetivos: PK0-003 INTRODUCCIÓN El examen CompTIA Project + está diseñado para profesionales de negocios involucrados con proyectos. Este examen certificará que el candidato exitoso

Más detalles

Examen de Fundamentos de ITIL

Examen de Fundamentos de ITIL Examen de Fundamentos de ITIL Ejemplo B, versión 5.1 Selección Múltiple Instrucciones 1. Debe intentar contestar todas las 40 preguntas. 2. Marque sus respuestas en la hoja de respuestas entregada 3. Usted

Más detalles

6 Anexos: 6.1 Definición de Rup:

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

Más detalles

Aseguramiento de la Calidad, QA. Materia: Desarrollo Industrial de Software Alumno: David Alejandro González Díaz y Froylan Ruiz Cirilo.

Aseguramiento de la Calidad, QA. Materia: Desarrollo Industrial de Software Alumno: David Alejandro González Díaz y Froylan Ruiz Cirilo. Aseguramiento de la Calidad, QA Materia: Desarrollo Industrial de Software Alumno: David Alejandro González Díaz y Froylan Ruiz Cirilo. Definición El aseguramiento de la calidad (QA), se puede definir

Más detalles

Curso de Project Management Simulacro de Examen

Curso de Project Management Simulacro de Examen 1- Un líder de proyecto tiene mayor probabilidad de éxito si su equipo de proyecto percibe que: a. El líder de proyecto es un experto en la tecnología que se maneja b. El líder de proyecto es un experto

Más detalles

Proyecto Meta! Implementación SAP Fase 1 Metodología ASAP

Proyecto Meta! Implementación SAP Fase 1 Metodología ASAP Proyecto Meta! Implementación SAP Fase 1 Metodología ASAP ASUG Argentina Premio a la Innovación de Proyecto SAP 2015 Agosto 2015 El Mapa de Ruta contiene las siguientes 6 fases: 1. Preparación del proyecto

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

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

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE 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,

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

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Metodología para la Gestión de Proyectos de Tecnologías Informáticas

Metodología para la Gestión de Proyectos de Tecnologías Informáticas Universidad Técnica Nacional Dirección de Gestión de Tecnología de Información Metodología para la Gestión de Proyectos de Tecnologías Informáticas Capítulo 1. Normas de Aplicación General. Norma 1.5.

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

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Seamos parte de la solución!

Seamos parte de la solución! Seamos parte de la solución! María Carolina Vacas, PMP carolinavacas@outlook.com Septiembre 2012 Objetivo del Taller Difundir las buenas prácticas en Gestión de Riesgos que propone el PMI. Invitar a las

Más detalles

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 : 05 Marzo 2015 MANUAL DE ORGANIZACIÓN Y FUNCIONES DEPARTAMENTO DE INFORMÁTICA Aprobado mediante Resolución de Gerencia General EF/92.2000 N 020-2014, de fecha

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

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

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

Proyectos Informáticos

Proyectos Informáticos Proyectos Informáticos Administración y Control de Proyectos I Facultad de Ingeniería (UBA) - Seminario de Project Management - Contenido El Equipo de Trabajo Roles y Responsabilidades Planificación Seminario

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

Empresa Financiera Herramientas de SW Servicios

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

Más detalles

Earned Value Management

Earned Value Management Earned Value Management Implementado con Microsoft Project 9 a Edición Septiembre 2014 Presencial y On Line en tiempo real Earned Value Management Aplicado con Microsoft Project Un curso orientado a comprender

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Plan de iteraciones RUP Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes (miniproyectos)

Más detalles

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO Informazioaren Teknologien Saila Departamento de Tecnologías de la Información Herritarrentzako

Más detalles

Diseño, Desarrollo e Implementación de una Aplicación Web para el manejo Centralizado de la Información Corporativa en AGA Consultores

Diseño, Desarrollo e Implementación de una Aplicación Web para el manejo Centralizado de la Información Corporativa en AGA Consultores Propuesta de Pasantía Diseño, Desarrollo e Implementación de una Aplicación Web para el manejo Centralizado de la Información Corporativa en AGA Consultores Acerca de AGA Consultores Quienes somos? Somos

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 original del Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS Nº 574-2009,

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

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

Unidad III. Planificación del proyecto de software

Unidad III. Planificación del proyecto de software Planificación del proyecto de software Unidad III 3.1. Aplicación de herramientas para estimación de tiempos y costos de desarrollo de software: GANTT, PERT/CPM, uso de software para la estimación de tiempos

Más detalles

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

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

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión

ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión ISO/IEC 20000 Tecnologías de Información y la Alineación con la Gestión Alfredo Zayas 0 Alfredo Zayas 1. ISO/IEC 20000 Consultant por ITSMf 2. Auditor interno de ISO 9001:2000 por INLAC 3. Certified Information

Más detalles

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

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

Más detalles

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

Propuesta Matriz de Actividades para un Ciclo de Vida de Explotación de Datos

Propuesta Matriz de Actividades para un Ciclo de Vida de Explotación de Datos Propuesta Matriz de Actividades para un Ciclo de Vida de Explotación de Datos Britos, P. 1,2 ; Fernández, E. 2,1 ; García Martínez, R 1,2 1 Centro de Ingeniería del Software e Ingeniería del Conocimiento.

Más detalles

Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4

Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4 Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4 5. PROCEDIMIENTOS RELACIONADOS... 4 6. DOCUMENTOS RELACIONADOS... 4 7. PROCESO... 4 7.1.

Más detalles

PROCEDIMIENTO GESTIÓN TICS

PROCEDIMIENTO GESTIÓN TICS . OBJETIVO Asesorar, preservar y mantener toda la infraestructura en tecnologías de la información y de comunicaciones en equipos de programas informáticos y medios de comunicación para reunir, almacenar,

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Impala Risk. Simulación de Riesgo en Proyectos. Servicios. Capacitación. www.impalarisk.com

Impala Risk. Simulación de Riesgo en Proyectos. Servicios. Capacitación. www.impalarisk.com Simulación de Riesgo en Proyectos Servicios Capacitación www.impalarisk.com Software Simulador de Riesgo en Proyectos El peor riesgo es desconocer el riesgo Los actuales Gerentes de Proyectos se enfrentan

Más detalles

PROCEDIMIENTO DE CALIDAD. Auditoría Interna de Calidad. Edición 09

PROCEDIMIENTO DE CALIDAD. Auditoría Interna de Calidad. Edición 09 Auditoría Interna de Calidad 1 de 9 PROCEDIMIENTO DE CALIDAD Auditoría Interna de Calidad Auditoría Interna de Calidad 2 de 9 ÍNDICE 2. ALCANCE...3 3. ABREVIATURAS...3 4. RESPONSABILIDAD...3 5. DEFINICIONES...3

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

1.-- OBJETO DE LA LICITACIÓN 2.- PRESUPUESTO 3.- ALCANCE DE LA PROPUESTA 4.- DESCRIPCIÓN DE LOS TRABAJOS 4.1.- ETAPA I. LICITACIÓN Y ADJUDICACION 4.

1.-- OBJETO DE LA LICITACIÓN 2.- PRESUPUESTO 3.- ALCANCE DE LA PROPUESTA 4.- DESCRIPCIÓN DE LOS TRABAJOS 4.1.- ETAPA I. LICITACIÓN Y ADJUDICACION 4. PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE UNA EMPRESA DE CONSULTORÍA PARA ASESORAR A SEPI EN EL PROCESO DE LICITACIÓN DE LA EXTERIORIZACIÓN DE LA FUNCIÓN INFORMÁTICA INDICE 1.-- OBJETO

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

Ingeniería de Software

Ingeniería de Software Departamento de Informática Universidad Técnica Federico Santa María Pauta Plan de Proyecto Profesor: Dr. Marcello Visconti Zamora visconti@inf.utfsm.cl 0 Portadas El documento que se está generando corresponde

Más detalles

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA

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

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

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

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

Más detalles