METODOLOGÍA DE GESTION DE PROYECTOS

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

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

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

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

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

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

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

Planificación de Sistemas de Información

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

Más detalles

Planificación de Sistemas de Información

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

Más detalles

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

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

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

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

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

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

[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

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

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

PFC- Aplicaciones Web para trabajo colaborativo:

PFC- Aplicaciones Web para trabajo colaborativo: PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

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

Calidad de Software Trabajo Práctico Integrador. CACIC 2012 XVI Escuela Internacional de Informática

Calidad de Software Trabajo Práctico Integrador. CACIC 2012 XVI Escuela Internacional de Informática Calidad de Software Trabajo Práctico Integrador CACIC 2012 XVI Escuela Internacional de Informática INDICE 1. Consignas del Trabajo Práctico... 3 1.2 Pautas generales... 3 2.2 Consignas... 3 2. Presentación

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

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

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

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 RESUMEN EJECUTIVO Herramientas y Metodologías Herramientas de Desarrollo o Desarrollo de aplicaciones Oracle Designer Oracle Software Configuration Manager (SCM) Oracle

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

Análisis de la gestión de configuración de software aplicada al modelo de espiral

Análisis de la gestión de configuración de software aplicada al modelo de espiral Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito (540 475 A.C.)- Grecia Fernandez, Sebastian Osso, Mariano

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

RESUMEN de la GESTIÓN de PROYECTOS

RESUMEN de la GESTIÓN de PROYECTOS RESUMEN de la GESTIÓN de PROYECTOS Basado en la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK ) Contenidos Introducción...2 PMI...2 Objetivos...2 PMBOK...2 Proyecto...3 Concepto...3

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

Análisis del Sistema de Información

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

Más detalles

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

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

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

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

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

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

La clara definición de los procesos de elaboración de software, nos permite brindar un servicio predecible y de la más alta calidad.

La clara definición de los procesos de elaboración de software, nos permite brindar un servicio predecible y de la más alta calidad. Software Factory Presentación Concepto Dada la necesidad de las compañías de concentrarse en las actividades propias del negocio; y en tren de bajar costos, mejorar los tiempos de desarrollo o de no montar

Más detalles

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

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

Más detalles

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

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

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración Seguridad del documento La clasificación de seguridad de la información de este documento, se ha establecido como bajo. Se ha creado y organizado con la expectativa de que esté a disposición de las unidades

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

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] Caso de Desarrollo Universidad Técnica del

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

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

CMMI : mejora del proceso en Fábricas de Software

CMMI : mejora del proceso en Fábricas de Software CMMI : mejora del proceso en Fábricas de Software Cecilia Rigoni Brualla Caelum, Information & Quality Technologies Introducción Introducción Idea / Necesidad Investigación Diseño Inversión PRODUCTO Introducción

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

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

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

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

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

<TITULO DEL PROYECTO DE DESARROLLO DE SW >

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

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

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

Más detalles

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

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 SISTEMA DE GESTION DE REQUERIMIENTOS DE SOFTWARE PROYECTO

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

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

mope PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS Página 0 PASEO GENERAL MARTINEZ CAMPOS 20 28010 MADRID 91 752 79 59 www.mope.es info@mope.

mope PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS Página 0 PASEO GENERAL MARTINEZ CAMPOS 20 28010 MADRID 91 752 79 59 www.mope.es info@mope. DENOMINACIÓN: Código: IFCT0609 Familia profesional: Informática y Comunicaciones Área profesional: Sistemas y telemática Nivel de cualificación profesional: 3 Cualificación profesional de referencia: IFC303_3

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

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

Transición del Servicio

Transición del Servicio Fundamentos de ITIL V3 Transición del Servicio Operaciones y Servicio al Cliente Ing. Paul Ernesto Luque Ybaceta Setiembre de 2011 Agenda Visión General del Diseño del Servicio Metas, Objetivos y Retos

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

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

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

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

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

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

Guía Presentación DIPAC-3.0

Guía Presentación DIPAC-3.0 Código:GP-001 Edición: 2 8 de marzo de 2014 8 de marzo de 2014 INDICE GENERAL INTRODUCCION... 3 OBJETIVOS... 3 ALCANCE... 3 ESTRUCTURA DEL DOCUMENTO... 3 PRESENTACIÓN... 4 INTRODUCCIÓN... 4 ORIGEN Y MOTIVACIONES...

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

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

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

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

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS 1 ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS INTRODUCCIÓN La realización de trabajos utilizando los medios informáticos de una empresa requiere una cierta organización y destreza relativa tanto a los equipos,

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

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

CAPITULO I. MARCO TEORICO

CAPITULO I. MARCO TEORICO 1 CAPITULO I. MARCO TEORICO 1.1 DEFINICIÓN DEL PROYECTO. Para la definición del proyecto nos basaremos en una metodología de gestión de proyectos, para esto compararemos las características de tres de

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

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

Plan estratégico de sistemas de información

Plan estratégico de sistemas de información Resumen ejecutivo Plan estratégico de sistemas de información Resumen ejecutivo Resumen ejecutivo La planificación estratégica de los sistemas de información, o equivalentemente la redacción del plan director

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

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

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

Plan de Gestión de Configuración Librería CEI

Plan de Gestión de Configuración Librería CEI Plan de Gestión de Configuración Este documento describe todas las actividades de Gestión de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto. El mismo nos proporciona

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

K2BIM Plan de Configuración Versión 0.9

K2BIM Plan de Configuración Versión 0.9 K2BIM Plan de Configuración Versión 0.9 Historia de revisiones Fecha VersiónDescripción Autor 21/08/2009 0.1 Modificado el punto 2.2 Yasim Zeballos 23/08/2009 0.9 Completados la mayoría de los puntos.

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

CICLO DE VIDA DEL SOFTWARE

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

Más detalles

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