UNIDAD 3 EL PROCESO DE EDUCCIÓN

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

Download "UNIDAD 3 EL PROCESO DE EDUCCIÓN"

Transcripción

1 UNIDAD 3 EL PROCESO DE EDUCCIÓN 3. EL PROCESO DE EDUCCIÓN DEFINICIONES EL PROCESO DE EDUCCIÓN PARTICIPANTES PROBLEMAS DE LA EDUCCIÓN Definiciones En los últimos años la complejidad de las actividades humanas ha aumentado, producto de la sofisticación tecnológica y la globalización e integración de las condiciones de trabajo. Esta situación ha provocado que aparezcan problemas y necesidades más complicadas que a su vez requieren soluciones más complejas. Esta creciente complejidad de los problemas o actividades descansa en fuentes, principalmente humanas, que sin ser expertos han adquirido habilidades y conocimientos importantes de una organización o sistema. Así, la construcción exitosa de sistemas software delega gran responsabilidad en el proceso de Ingeniería de Requisitos que debe realizarse de forma sistemática y satisfaciendo necesidades de calidad que benefician al resto de los procesos. Como se ha explicado en la unidad anterior, la Ingeniería de Requisitos contempla varias actividades que tienen por finalidad última la Especificación de Requisitos del Sistema Software. Entre estas actividades la más importante, y a la vez más complicada, es la de obtención de la información que finalmente permita definir los requisitos, donde el analista debe educir el conocimiento acerca de algún dominio de problema y, en alguna medida, llegar a ser un experto en el dominio [Loucopoulos and Karakostas 1995]. Esta actividad recibe diveresos nombre como captura, determinación, adquisición, obtención de requisitos. Sin embargo la denominación más aceptada es la de Educción. La educción de requisitos se define como el proceso de identificar necesidades y acercar las disparidades entre las comunidades envueltas con el propósito de definir requisitos [SEI 1991]. [Saiedian and Dale 2000] definen la educción de requisitos como el proceso específico de obtención, determinación, extracción o exponer los requisitos software. Según [Jitnah et al. 1995] la educción es llevar a la luz los requisitos, y análisis es llevar a la luz las características de estos requisitos Para [Loucopoulos and Karakostas 1995] es el proceso de adquirir todo el conocimiento relevante necesario para producir un modelo de requisitos de un problema de un dominio. Asignatura: Educción de Requisitos 1

2 3.2. El proceso de educción Al igual que en el proceso de Ingeniería de Requisitos, hay bastante ambigüedad y diferencias de enfoques sobre las actividades del proceso (o subproceso) de educción. Este proceso tiene como objetivo identificar información que determine las características deseadas del sistema software. Para ello es necesario considerar la información acerca del dominio de aplicación y de los usuarios del sistema software [Jitnah et al. 1995]. El conocimiento del dominio ayuda al analista a obtener un grado común de entendimiento del mundo del usuario y facilita el proceso de captura y especificación de requisitos pues este conocimiento puede ser reutilizado en futuras especificaciones significando ahorros de tiempo y costos [Bolton et al. 1993]. [Chatzoglou and Macaulay 1996c] describen cuantitativamente el proceso: El tiempo del proceso de Captura y Análisis de Requisitos (CAR) es más del 15% del tiempo del proceso total. El costo del proceso CAR es entre el 5 y el 15% del costo del proceso total. El esfuerzo gastado en el proceso CAR es, normalmente, menor a 36 hombre-mes. Menos de 5 personas están envueltas normalmente en el proceso CAR. La distribución de recursos es de hasta un 60% para la primera iteración, de hasta un 40% para la segunda y tercera iteración, y de hasta un 20% para la cuarta iteración. En los proyectos donde se ejecutan dos iteraciones, se asigna más recursos a la primera iteración pero se capturan todos sus requisitos en ambas iteraciones. Los proyectos donde tres iteraciones ocurren, se asigna más recursos a la primera y segunda iteración y se capturan la mayoría de sus requisitos en estas dos primeras iteraciones. Los proyectos donde más de tres iteraciones ocurren, se asigna más recursos a la segunda y tercera iteración y se capturan la mayoría de sus requisitos en estas iteraciones. Pero también se han detectado algunas prácticas no deseadas. [Chatzoglou and Macaulay 1996a] encontraron que cerca de la mitad de los proyectos (47%) no usan metodologías (quizás sí utilicen técnicas aisladas). Mientras que la mayoría de los académicos, empresas de desarrollo de software y consultores usan metodologías (incluido el proceso CAR), la industria lo hace sólo en un tercio. El bajo uso de metodologías parece deberse a la actitud de la gente implicada en el proceso o a las restricciones organizacionales donde trabajan. Solo un 29% de los proyectos usan una herramienta de planificación en la etapa de CAR; un 62% la usa para el resto del proyecto. Los jefes de proyecto consideran que el proceso de CAR es demasiado informal y no estructurado como para que sea posible su planificación y su control. En cuanto a su estructura, para [Loucopoulos and Karakostas 1995] el Proceso de Educción de Requisitos tiene como propósito obtener conocimiento relevante del dominio del problema para producir una especificación formal del software que resuelve el problema. El proceso comprende: Entradas: o Expertos del dominio. o Literatura acerca del dominio. o Aplicaciones software similares en otros dominios. o Estándares nacionales e internacionales que condicionan el desarrollo de software en ese dominio. o Otras directivas de la organización que albergará el sistema software. Asignatura: Educción de Requisitos 2

3 Actividades: o Identificar todas las fuentes de requisitos. o Adquirir el conocimiento. o Decidir sobre la relevancia del conocimiento del problema. o Entender el significado del conocimiento elicitado y su impacto sobre los requisitos del software. Entregables (productos): o Modelos formales del dominio del problema. Para [Christel and Kang 1992], el proceso de educción comprende cinco pasos en forma de cascada, con posibilidad de volver a etapas anteriores, tal como se muestra en la Figura 1. Encontrando Hechos Obtención y Clasificación de Requisitos Evaluación y Fundamentación Priorización Integración y Validación Figura 1. Proceso de Educción de Requisitos [Christel and Kang 1992]. Encontrando Hechos: o Un examen de la organización destino. o Declaración de alto nivel de la misión del sistema. o Determinación de algunas restricciones de la arquitectura. o Determinación de la existencia de sistemas similares. Obtención de requisitos: Captura de información a través de vistas multidisciplinarias. Evaluación y fundamentación: Expone inconsistencias en la información obtenida. Justifica la determinación de cada requisito. Priorización: Determina la importancia relativa de los requisitos. Integración y Validación: Integra el conjunto de requisitos determinados y valida si concuerdan con las metas del sistema. Asignatura: Educción de Requisitos 3

4 Los autores [Chatzoglou and Macaulay 1995b] denominan el proceso como Captura y Análisis de Requisitos (CAR) y lo dividen en tres fases, mostradas en la Figura 2: obtener información, examinar y asimilar la información (para identificar requisitos) y verificar si se ha obtenido suficiente información y requisitos identificados. Una iteración de CAR puede ser considerada como una ejecución de estas fases. El modelo del proceso sigue un enfoque de espiral y se basa en encontrar cuántas iteraciones deben ocurrir y qué recursos se necesitan para cada iteración [Chatzoglou and Macaulay 1997a]. Información/Requisitos R3 R2 Fase III: Validación de Requisitos O R1 Salida de CAR Fase I: Obtención Información C1 T1 T2 C2 T3 Costo C3 Fase II: Identificar Requisitos Tiempo Figura 2. Proceso de Captura y Análisis de Requisitos, según [Chatzoglou and Macaulay 1997a]. Este modelo presenta la idea que el tiempo y el costo para obtener requisitos puede ser diferente en cada iteración o mejor dicho, el costo y tiempo marginal gastado en obtener información extra no es el mismo en diferente iteraciones. Por el contrario, para el SWEBOK o, lo que es prácticamente lo mismo, para [Kotonya and Sommerville 1998], el subproceso de educción es mucho más simple; tan simple que no se distingue estructura interna alguna. No obstante, implícitamente el subproceso de educción según el SWEBOK comprende dos tareas: 1. La obtención de información de los distintos participantes en la actividad de requisitos y 2. La identificación de requisitos. Nótese que las citadas tareas están en perfecta correspondencia con [Loucopoulos and Karakostas 1995] y además coinciden con las dos primeras tareas de las propuestas de [Christel and Kang 1992] y [Chatzoglou and Macaulay 1995b]. También coincide el SWEBOK con los citados autores al concebir el subproceso de educción como evolutivo, esto es, desarrollado mediante múltiples iteracciones, en cada una de las cuales se obtiene nueva y mejor información de los distintos Asignatura: Educción de Requisitos 4

5 participantes de la actividad de requisitos. El esquema de iteracción propuesto por el SWEBOK se muestra en la Figura 3. Educción de Requisitos Análisis y negociación Validación de Requisitos Documentación de Requisitos Documento de Requisitos Gestión de Requisitos Figura 3. El subproceso de educción en el contexto del resto de subprocesos del SWEBOK. Es necesario señalar que existen ciertas diferencias entre las aproximaciones de [Christel and Kang 1992] y [Chatzoglou and Macaulay 1995b] y la propuesta del SWEBOK. Dichas diferencias están motivadas, fundamentalmente, por la estructura impuesta al proceso de Ingeniería de Requisitos por el SWEBOK, estructura inexistente en el momento en que [Christel and Kang 1992] y [Chatzoglou and Macaulay 1995b] publicaron sus trabajos. No debe entenderse, no obstante, que la propuesta del SWEBOK es peor o deficiente respecto a las otras citadas propuestas. Muy al contrario, se puede afirmar con certeza que son todas equivalentes. Lo que ocurre en realidad es que el SWEBOK asigna a distintas actividades o subprocesos del proceso de requisitos tareas que en las propuestas de [Christel and Kang 1992] y [Chatzoglou and Macaulay 1995b] se adscriben al subproceso de educción. Por ejemplo, [Christel and Kang 1992] incluyen como pertenecientes a la educción las tareas de clasificación, evaluación y fundamentación, priorización e integración. Dichas tareas se han asignado, en la propuesta del SWEBOK, a la actividad o subproceso de análisis. Asimismo, la tarea de validación indicada en [Christel and Kang 1992] y [Chatzoglou and Macaulay 1995b] se corresponde con la actividad o subproceso de validación en el SWEBOK. En conclusión, como ya se ha indicado en unidades anteriores, las distintas propuestas acerca de cómo llevar a cabo el proceso de requisitos son en esencia similares. No obstante, en el presente curso utilizaremos preferentemente la propuesta del SWEBOK por entender que ésta es la que tendrá más proyección en un futuro inmediato Participantes La actividad de obtención de información para especificar los requisitos de un sistema software involucra la determinación de quiénes son las personas que deben participar en dicho proceso. Aunque tradicionalmente se ha considerado al analista como el único responsable de la educción, normalmente realizando entrevistas, existe una gran variedad de participantes que pueden tener un rol importante: El proceso de Captura y Análisis no sólo es un proceso técnico para construir un sistema, sino también un proceso social que envuelve a diferentes personas [Chatzoglou and Soteriou 1999]. Entre los que pueden ser participantes de este proceso están todos aquellos que tienen algún interés en el cambio que está siendo considerado, que tienen algo que ganar o perder ; es decir, aquellos responsables de su diseño y desarrollo (jefes de proyectos, diseñadores de software, expertos Asignatura: Educción de Requisitos 5

6 técnicos); aquellos con interés financiero en su venta (analistas de negocios, expertos de mercados, responsables de venta o compra); aquellos responsables de su introducción y mantenimiento en la organización (personal de formación y apoyo a usuarios, personal de mantenimiento e instalación y administradores de usuarios); y aquellos que tienen un interés en su uso (administradores y usuarios) [Macaulay 1992]. [Kotonya and Sommerville 1998] definen entre los interesados en el proceso a ingenieros de software, usuarios finales del sistema, jefes de usuarios finales del sistema, reguladores externos, y expertos en el dominio. Otros autores, como [Sharp et al. 1999], proponen un enfoque para identificar los interesados del proceso de educción. Define cuatro grupos de participantes base: usuarios, desarrolladores, legisladores y responsables de la toma de decisión. El enfoque guía para establecer el resto de los participantes a partir de la línea base, es decir extiende una red de personas que pueden tener alguna relación con esta actividad. En los últimos años, y como consecuencia de la popularización del uso de las sesiones de workshops, se ha agregado el rol de facilitador, que ayuda a la identificación de información relevante [Macaulay and Roche 1998]. [Saiedian and Dale 2000] establecen participantes tanto del lado del cliente como del desarrollador. Respecto al lado del cliente, pueden participar los siguientes roles: Compradores: responsables de contratar y comprar el software. Usuario final: individuos que finalmente utilizarán el sistema desarrollado. Tienen que ver con la usabilidad, fiabilidad y disponibilidad del sistema. Expertos del dominio: individuos que entienden el entorno del sistema o dominio del problema. Personal de mantenimiento de software: para proyectos que serán mantenidos por el cliente. Son las personas responsables de la gestión de cambios futuros e implementación y resolución de anomalías. Los participantes claves del lado del desarrollador son: Jefes de proyecto: personas responsables de la venta y marketing del producto y también del desarrollo del proyecto. Ingenieros de requisitos: personas responsables de la identificación y documentación de los requisitos. Ingenieros de software: personas con experiencia en desarrollo técnico de software. Probadores: personas que realizan las pruebas de los productos del desarrollo. [El Emam and Madhavji 1995a] identifican algunas de las destrezas que deberian tener los participantes. En particular, los usuarios deberían tener las siguientes habilidades: Estar familiarizado y tener experiencia en sistemas de computación. Tener buen conocimiento del dominio de aplicación, los procesos de negocios y las necesidades de la organización. Tener buen conocimiento del proceso de desarrollo de sistemas (especialmente IR y técnicas de modelización) y sus productos. Tener buen conocimiento de gestión y planificación de implementación de sistemas de información. Tener habilidad para tratar y comunicarse con personas. Asignatura: Educción de Requisitos 6

7 Desde la perspectiva de los analistas, según [El Emam and Madhavji 1995a], un analista debe tener las siguientes destrezas: Buen conocimiento del dominio de aplicación y los procesos de negocios de la organización del usuario. Buen conocimiento de la tecnología hardware y software a ser utilizada en el sistema de información. Habilidad para tratar con personas y de comunicación verbal. Buen conocimiento y experiencia en el proceso de IR y sus productos. Buen conocimiento y experiencia en realizar análisis de costo/beneficio. Buen conocimiento y experiencia en implementación de sistemas y cambio organizacional. Buen conocimiento y experiencia en análisis y evaluación de paquetes de software Problemas de la educción La tarea de captura de los requisitos es compleja desde el mismo momento en que deben acceder a las fuentes de información [Chatzoglou and Macaulay 1997b]. [Davis 1993] decía Es trabajo de los analistas descubrir no sólo lo que los usuarios dicen que quieren sino lo que ellos realmente necesitan. El proceso de educción presenta varias dificultades entre las que se encuentran las siguientes, según [Browne and Rogich 2001]: Dificultades cognitivas, resultantes de las restricciones humanas como procesadores de información. Dificultades de estructuración, resultantes de la variedad y complejidad de los requisitos de información. Dificultades de comunicación, que se deben a la complejidad de la interacción entre usuarios y analistas al definir requisitos. Otra clasificación de los obstáculos de este proceso presenta tres tipos [Vasulek and Fryback 1987]: Obstáculos en. Se corresponde con las dificultades que provienen de limitaciones cognitivas o de comportamiento individual de los participantes. Obstáculos entre (varios). Referidos a aquellos obstáculos que representan inconsistencias o diferencias de prioridades o contenidos entre los usuarios. Obstáculos y entre (dos). Son las limitaciones psicológicas o de comunicación de la interacción analista-usuario. Algunos intentos de resolver estas limitaciones han arrojado propuestas de herramientas sin resultados conocidos [Valenti et al. 1998]. [Christel and Kang 1992] clasifican los problemas del proceso de educción en tres tipos: Problemas de alcance, relacionados con la obtención de poca o mucha información. Problemas de entendimiento, en o entre los grupos de usuarios y desarrolladores. Problemas de volatilidad, referidos a la naturaleza cambiante de los requisitos. Asignatura: Educción de Requisitos 7

8 La interacción entre usuario y analista provoca diversos problemas de comunicación que supeditan la calidad de los resultados a la habilidad del analista para instar al usuario a dar una descripción detallada y objetiva del dominio de aplicación [Cucchiarelli et al. 1994]. La participación del usuario es importante, pero también lo es determinar cuánto y cómo debe hacerlo [Saiedian and Dale 2000]. En muchos casos, la participación se torna perjudicial por la falta de cooperación, la abierta hostilidad y la indisponibilidad de los usuarios [El Emam and Madhavji 1995a]. Esta interacción analista-usuario presenta dificultades por la pobreza en la calidad de la comunicación, resistencias a expresarse, diferencia de terminología y diferencia de perspectivas [Saiedian and Dale 2000]. Otros autores como [Loucopoulos and Karakostas 1995] describen las siguientes dificultades del proceso: El conocimiento no está siempre disponible en la forma adecuada para ser usada por el analista. Los usuarios no tienen una idea clara de lo que ellos quieren del nuevo sistema software. Los usuarios encuentran dificultad al describir su conocimiento del dominio. Los conocimientos, experiencia y objetivos de los usuarios y analistas son diferentes. Los usuarios emplean su propia terminología orientada al dominio y los analistas usan un vocabulario orientado al computador. A los usuarios les disgusta la idea de tener que usar un nuevo sistema software por lo que están poco dispuestos a participar en el proceso de educción. Asignatura: Educción de Requisitos 8

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

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

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

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

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

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

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

LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN

LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN Después de realizar la evaluación inicial se han detectado deficiencias en los procesos de reutilización del código, por lo que se van a integrar

Más detalles

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

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar 1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

Índice. Introducción. Entrevista. Joint Application Design. Joint Requirements Planning. Brainstorming. Phillips 66. Daily Scrum Meeting.

Índice. Introducción. Entrevista. Joint Application Design. Joint Requirements Planning. Brainstorming. Phillips 66. Daily Scrum Meeting. Sesiones de trabajo Índice Introducción. Entrevista. Joint Application Design. Joint Requirements Planning. Brainstorming. Phillips 66. Daily Scrum Meeting. Introducción Introducción Nunca debe perderse

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

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

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA TRABAJO PRÁCTICO DE AUDITORIA INFORMATICA Profesor: Lic. Marco Antonio Leiva Fernández 5to

Más detalles

PERFIL DEL INGENIERO DE SISTEMAS FUSM

PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS DE LA FUSM El perfil del Ingeniero de Sistemas presencial de la Fundación Universitaria San Martín, Bogotá, está en capacidad de modelar

Más detalles

INGENIERÍA de REQUERIMIENTOS

INGENIERÍA de REQUERIMIENTOS INGENIERÍA de REQUERIMIENTOS Unidad IV Análisis de Requerimientos Verificación Validación Negociación - Trazabilidad Quality Function Deployment (QFD) 1 1 Análisis Verificación y Validación de Requerimientos

Más detalles

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay Gestión de Proyectos de desarrollo de software Ing. Rafael Bentancur Universidad ORT Uruguay Algunas definiciones Proyecto: emprendimiento temporario que debe crear un producto o servicio único (PMBOK)

Más detalles

Experto en Usabilidad

Experto en Usabilidad ! Perfiles de Competencias Europeos en Profesiones relacionadas con Internet Experto en Usabilidad e-jobs-observatory.eu 1 Experto en usabilidad 1. Descripción de funciones Título del perfil También conocido

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

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

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

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

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

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente.

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente. NOTAS ACLARATORIAS: Esta ficha de grado es la resultante de las dos reuniones celebradas (9 enero 2009 y 23 de febrero de 2009) por la subcomisión creada desde el MICIIN para debatir las fichas de Grado

Más detalles

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos.

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos. Competencias generales - Capacidad para concebir, redactar, organizar, planificar, desarrollar y firmar proyectos en el ámbito de la ingeniería en informática que tengan por objeto, de acuerdo con los

Más detalles

Mapa de Certificaciones en Dirección de Proyectos. Barcelona, 08 de octubre de 2012

Mapa de Certificaciones en Dirección de Proyectos. Barcelona, 08 de octubre de 2012 Mapa de Certificaciones en Dirección de Proyectos Barcelona, 08 de octubre de 2012 El Marco Europeo de las Cualificaciones se centra en los resultados de aprendizaje y no en datos básicos como la duración

Más detalles

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Vegega, C., Pytel, P., Ramón, H., Rodríguez, D., Pollo-Cattaneo, F.,

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Implementación de Sistemas de Información Departamento de Informática, UTFSM 2 Introducción La implementación de un sistema de

Más detalles

Tema 1 Introducción a los Sistemas Basados en el Conocimiento

Tema 1 Introducción a los Sistemas Basados en el Conocimiento Tema 1 Introducción a los Sistemas Basados en el Conocimiento Sistemas Basados en el Conocimiento Grado en Ingeniería Informática 1 Referencias Ingeniería del Conocimiento. A. Gómez, N. Juristo, C. Montes,

Más detalles

Aplicaciones de Ingeniería de Software

Aplicaciones de Ingeniería de Software Aplicaciones de Ingeniería de Software Administración de la Calidad del Producto de Software Qué es la gestión de la calidad? Es una actividad protectora o de sombrilla que se aplica a lo largo del proceso

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

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

EL PROCESO DE DESARROLLO DE SOFTWARE: UNA TAREA SOCIAL DE MEJORA CONTINUA

EL PROCESO DE DESARROLLO DE SOFTWARE: UNA TAREA SOCIAL DE MEJORA CONTINUA EL PROCESO DE DESARROLLO DE SOFTWARE: UNA TAREA SOCIAL DE MEJORA CONTINUA Dra. Pilar Gómez Gil Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE). Coordinación de Ciencias Computacionales

Más detalles

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

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

Más detalles

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

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 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

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

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

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

Más detalles

PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN

PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN Paola Britos 1,2, Enrique Fernandez 1,2, Ramón García-Martinez 1,2 Centro de Ingeniería del Software e Ingeniería

Más detalles

Carrera : SATCA 1 2-2-4

Carrera : SATCA 1 2-2-4 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Ingeniería de Software Carrera : Clave de la asignatura : TIC-1014 SATCA 1 2-2-4 Ingeniería en Tecnologías de la Información y Comunicaciones 2.- PRESENTACIÓN

Más detalles

SATCA 1 2-2-4. En la primera unidad, el estudiante conocerá los fundamentos de la Ingeniería de Software y los sistemas de información.

SATCA 1 2-2-4. En la primera unidad, el estudiante conocerá los fundamentos de la Ingeniería de Software y los sistemas de información. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Ingeniería de Software Ingeniería en Tecnologías de la Carrera : Información y Comunicaciones Clave de la asignatura : TIC-1014 SATCA 1 2-2-4 2.- PRESENTACIÓN

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Conceptos de Metodología y Modelo. Relaciones

Conceptos de Metodología y Modelo. Relaciones Conceptos de Metodología y Modelo. Relaciones CRITERIOS orientan Se compone PRODUCTOS ASPECTOS DEL SISTEMA DE INFORMACION describe MODELO soportan HERRAMIENTAS Se compone METODOLOGIA De Complejidad del

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

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Modelo de calidad IT Mark

Modelo de calidad IT Mark Modelo de calidad IT Mark Agenda de Trabajo 1. Área de Calidad 2. Introducción IT Mark 3. Proceso del Negocio 3.1 Ten Square. 3.2 Evaluación 3.3 Evidencias 3.4 Presentación de resultados. 4. Proceso de

Más detalles

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

Normas de Auditoría de Tecnologías de la Información y la Comunicación

Normas de Auditoría de Tecnologías de la Información y la Comunicación Normas de Auditoría de Tecnologías de la Información y la Comunicación Resolución CGE/094/2012 27 de agosto de 2012 NE/CE-017 N O R M A D E C O N T R O L E X T E R N O NORMAS DE AUDITORÍA DE TECNOLOGÍAS

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

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

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE CAPACITACIÓN Versión 05 Diciembre 2008 INDICE Introducción... 3

Más detalles

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título 3. OBJETIVOS 3.1. Objetivos Objetivos generales del título De acuerdo con lo establecido en el Libro Blanco y el acuerdo del plenario de la Conferencia de Directores y Decanos de Informática (Zaragoza,

Más detalles

3. ANÁLISIS SITUACIÓN ACTUAL ÁREA DE DESARROLLO DE APLICACIONES 3.1 VISIÓN GENERAL

3. ANÁLISIS SITUACIÓN ACTUAL ÁREA DE DESARROLLO DE APLICACIONES 3.1 VISIÓN GENERAL 3. ANÁLISIS SITUACIÓN ACTUAL ÁREA DE DESARROLLO DE APLICACIONES EMPRESA DE CONTACT-CENTER EMTELCO S.A. 3.1 VISIÓN GENERAL Emtelco S.A es una sociedad mixta del orden municipal que hace parte del grupo

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

Metodología Pedagógica.

Metodología Pedagógica. Master in Business Administration (MBA) El programa Master in Business Administration - MBA se desarrolla desde la perspectiva de la integración del directivo o empresario en el rol de los negocios de

Más detalles

MINISTERIO DE EDUCACIÓN SUBSECRETARÍA DE FUNDAMENTOS EDUCATIVOS DIRECCIÓN NACIONAL DE CURRÍCULO

MINISTERIO DE EDUCACIÓN SUBSECRETARÍA DE FUNDAMENTOS EDUCATIVOS DIRECCIÓN NACIONAL DE CURRÍCULO MINISTERIO DE EDUCACIÓN SUBSECRETARÍA DE FUNDAMENTOS EDUCATIVOS DIRECCIÓN NACIONAL DE CURRÍCULO GUÍA PARA LA IMPLEMENTACIÓN DEL PROYECTO DE GRADO EN INSTITUCIONES EDUCATIVAS QUE OFERTAN BACHILLERATO TÉCNICO

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

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

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

Grado en Ingeniería Informática

Grado en Ingeniería Informática Grado en Ingeniería Informática Competencias Generales y trasversales De acuerdo con la resolución del Consejo de Universidades de fecha 3 de marzo de 2009, para obtener este título de grado en ingeniería

Más detalles

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8 Documento de Competencias Grado en INGENIERÍA INFORMÁTICA Facultad de Informática, UPV/EHU 1 Estructura general del Grado 1.1 Fundamentos de Tecnología de los Principios de Diseño de Sistemas Digitales

Más detalles

PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING.

PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING. PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING. UNIDAD 6. LA SATISFACCIÓN Y LEALTAD DEL CLIENTE OBJETIVO: Este tema tiene como meta comprender y entender los principios y valores que las empresas deben

Más detalles

Desarrollo de SBC. cbea (LSI - FIB) Sistemas Basados en el Conocimiento IA - Curso 2008/2009 1 / 41

Desarrollo de SBC. cbea (LSI - FIB) Sistemas Basados en el Conocimiento IA - Curso 2008/2009 1 / 41 Desarrollo de SBC Ingeniería de los SBC Desarrollo de SBC El punto más importante del desarrollo de SBC es la extracción del conocimiento Requiere la interacción entre el Ingeniero del Conocimiento y el

Más detalles

Gestión de Requisitos ULPGC

Gestión de Requisitos ULPGC Gestión de Requisitos ULPGC Gestión de Requisitos Consiste en gestionar los cambios de los requisitos, las relaciones entre ellos, las dependencias entre la especificación de requisitos y otros documentos

Más detalles

Carrera: SCD-1011 SATCA 1 2-3-5

Carrera: SCD-1011 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Ingeniería de Software Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1011 2-3-5 2.- PRESENTACIÓN Caracterización

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

1.2 Alcance. 1.3 Definición del problema

1.2 Alcance. 1.3 Definición del problema 1. INTRODUCCIÓN El avance de Internet y las comunicaciones de los últimos años ha provocado un interés creciente por el desarrollo de propuestas metodológicas que ofrezcan un marco de referencia adecuado

Más detalles

Normas chilenas de la serie ISO 9000

Normas chilenas de la serie ISO 9000 Normas chilenas de la serie ISO 9000 Hernán Pavez G. Director Ejecutivo del Instituto Nacional de Normalización, INN, Matías Cousiño N 64, 6 Piso, Santiago, Chile. RESUMEN: en nuestro país las empresas

Más detalles

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

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

Más detalles

ANALES DEL XVIII CONGRESO ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN CACIC. 8 al 12 de octubre de 2012. Bahía Blanca, Buenos Aires, Argentina

ANALES DEL XVIII CONGRESO ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN CACIC. 8 al 12 de octubre de 2012. Bahía Blanca, Buenos Aires, Argentina ANALES DEL XVIII CONGRESO ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN XVIII CACIC 2012 8 al 12 de octubre de 2012 Bahía Blanca, Buenos Aires, Argentina XIII Workshop Agentes y Sistemas Inteligentes (WASI)

Más detalles

LOS INDICADORES DE GESTIÓN

LOS INDICADORES DE GESTIÓN LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Cómo gestionar proyectos en condiciones de riesgo

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

Más detalles

Aseguramiento de la Calidad

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

Más detalles

Universidad de Tarapacá Investigación de Mercados Internacionales

Universidad de Tarapacá Investigación de Mercados Internacionales Universidad de Tarapacá Investigación de Mercados Internacionales Capítulo II: El proceso de la Investigación de Mercados Internacionales. Tema 2: El Diseño de la Investigación de Mercados Internacionales

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

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

Examen de Fundamentos de ITIL

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

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

TECNOLOGÍA DE LA INFORMACIÓN PARA EL APRENDIZAJE DE LA ADMINISTRACIÓN DE PROYECTOS

TECNOLOGÍA DE LA INFORMACIÓN PARA EL APRENDIZAJE DE LA ADMINISTRACIÓN DE PROYECTOS TECNOLOGÍA DE LA INFORMACIÓN PARA EL APRENDIZAJE DE LA ADMINISTRACIÓN DE PROYECTOS Domingo Vega T. Facultad de Ingeniería, Departamento de Ingeniería Industrial, Universidad de La Serena dvega@userena.cl

Más detalles

6.4 ESTRATEGIAS DE PRUEBA

6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

Autoevaluación Institucional con fines de Acreditación. Guía para la elaboración del Plan de Mejoramiento

Autoevaluación Institucional con fines de Acreditación. Guía para la elaboración del Plan de Mejoramiento Autoevaluación Institucional con fines de Acreditación Guía para la elaboración del Plan de Mejoramiento Contenido 1. Introducción... 4 2. Objetivo de la guía... 4 3. Aspectos a considerar... 4 3.1 Autoevaluación...5

Más detalles

CAPÍTULO VI CONCLUSIONES Y RECOMENDACIONES

CAPÍTULO VI CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES Y RECOMENDACIONES 6.1. Conclusiones. 6.2. Recomendaciones. 6.1. CONCLUSIONES Informática forense La Informática Forense en la actualidad ha tomado gran importancia porque permite encontrar

Más detalles

Contextualizacion. La Actividad de Requisitos. La actividad de requisitos. Contextualización, gráficamente. Introducción

Contextualizacion. La Actividad de Requisitos. La actividad de requisitos. Contextualización, gráficamente. Introducción Contextualizacion La Actividad Requisitos Introducción Supongamos que este curso fuese un proyecto sarrollo software real. En qué estadio nos encontraríamos? Hemos finido el molo ciclo vida e instanciado

Más detalles

Guía Docente. Tipo: Obligatoria Créditos ECTS: 6. Curso: 3 Código: 3626

Guía Docente. Tipo: Obligatoria Créditos ECTS: 6. Curso: 3 Código: 3626 Guía Docente DATOS DE IDENTIFICACIÓN Titulación: Ingeniería Informática Rama de Conocimiento: Ingeniería y Arquitectura Facultad/Escuela: Escuela Politécnica Superior Asignatura: Desarrollo e Integración

Más detalles

: Desarrollo de Sistemas de Información CODIGO : 620191

: Desarrollo de Sistemas de Información CODIGO : 620191 UNIIVERSSIIDAD DELL BIIO--BIIO VIICERRECTORIIA ACADEMIICA DIIRECCIION DE DOCENCIIA ASIGNATURA : Desarrollo de Sistemas de Información CODIGO : 620191 I. IDENTIFICACION 1.1 CAMPUS : CONCEPCIÓN 1.2 FACULTAD

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito.

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito. Tomado de: La inteligencia de negocios desde la perspectiva cubana: retos y tendencias. Informe publicado en TodoBI. Autora: MSc. Ivette Marrero Antunez Consultora de inteligencia empresarial. E-mail:

Más detalles

El Gerente de Proyecto. 3: El Gerente de Proyecto. Analogía - Responsabilidades. Liderazgo del Proyecto. Responsabilidades Implícitas

El Gerente de Proyecto. 3: El Gerente de Proyecto. Analogía - Responsabilidades. Liderazgo del Proyecto. Responsabilidades Implícitas 3: El Gerente de Proyecto El Gerente de Proyecto Selección del Gerente de Proyecto Habilidades Requeridas Criterios aplicables a la Selección. Descripción de Tareas. Project Charter 1 2 Responsabilidades

Más detalles

INGRESO DE ESTUDIANTES (SELECCIÓN PSICOMETRICA Y DE CONOCIMIENTOS)

INGRESO DE ESTUDIANTES (SELECCIÓN PSICOMETRICA Y DE CONOCIMIENTOS) UNIVERSIDAD AUTONOMA CHAPINGO UNIDAD REGIONAL UNIVERSITARIA DE ZONAS ARIDAS COORDINACION DE POSGRADO MAESTRIA EN CIENCIAS EN RECURSOS NATURALES Y MEDIO AMBIENTE EN ZONAS ARIDAS INGRESO DE ESTUDIANTES (SELECCIÓN

Más detalles