Figure 12-1: Phase D: Technology Architecture
|
|
|
- Agustín Luna Ríos
- hace 7 años
- Vistas:
Transcripción
1 Fase de arquitectura de tecnología: Figure 12-1: Phase D: Technology Architecture Objetivos: Los objetivos de la Arquitectura de Tecnología son: Desarrollar la Arquitectura de Tecnología Objetivo que permite la Arquitectura Empresarial y la Visión de Arquitectura, direccionar la Solicitud de Trabajo Arquitectura y las necesidades de las partes interesadas. Identificar los componentes candidatos de la Arquitectura para la Hoja de Ruta sobre la base de las diferencias entre la línea de base y las arquitecturas de tecnología objetivo. ENFOQUE REPOSITORIO DE LA ARQUITECTURA
2 Como parte de esta fase D, el equipo de Arquitectura necesita considerar los recursos relevantes de la Arquitectura de Tecnología que están disponibles en el Repositorio de la Arquitectura. En particular: Servicios de IT existentes, tanto documentados en el repositorio de IT o en el catalogo de servicios de IT. TOGAF Modelo de referencia técnica (TRM). Modelos genéricos de tecnología relevantes a la industria de la organización. Modelos de tecnología relevantes a la Arquitectura de Sistemas en general. ENTRADAS MATERIAL DE REFERENCIA EXTERNO A LA EMPRESA ENTRADAS NO ARQUITECTURALES Solicitud de Trabajo Arquitectura. Evaluación de la capacidad. Plan de comunicaciones. ENTRADAS ARQUITECTURALES Modelo Organizacional de la Arquitectura Empresarial, que incluye: o Alcance del impacto en la organización. o La evaluación de la madurez, las brechas y el enfoque de resolución. o Roles y responsabilidades para el equipo de arquitectura (s). o Las restricciones sobre el trabajo de arquitectura. o Necesidades presupuestarias. o Gobernanza y estrategia de apoyo. Marco de Trabajo de la Arquitectura adaptado. o Método de la arquitectura adaptado. o Contenido de la arquitectura adaptado (Entregables y artefactos) o Herramientas de configuración e instalación. Principios de los Tecnología. Estatuto del trabajo de la arquitectura. Visión de la Arquitectura.
3 Repositorio de la Arquitectura. o Bloques de construcción reutilizables. o Modelos de referencia específicos a la organización. o Estándares de la organización. Documento borrador de la Definición de la Arquitectura, incluyendo: o Línea base de la Arquitectura de Negocios. Versión 1.0 (Detallada). o Arquitectura de Negocios objetivo. Versión 1.0 o Línea base de la Arquitectura de Datos. Versión 1.0 o Arquitectura de Datos objetivo. Versión 1.0 o Línea base de la Arquitectura de Datos. Versión 1.0 o Línea base de la Arquitectura de Aplicación. Versión 1.0 o Arquitectura de Aplicación objetivo. o Línea base de la Arquitectura de Tecnología. o Arquitectura de Tecnología objetivo. Borrador de la especificación de requerimientos de la Arquitectura. o Resultados del análisis de brechas. o Requerimientos técnicos relevantes que se pueden aplicar en la Fase C. Componentes de la Arquitectura de Negocios, datos, y de aplicación de la hoja de Ruta de la Arquitectura. PASOS El nivel de detalle en la Fase D dirigida dependerá del alcance y los objetivos de los esfuerzos de arquitectura global. Nuevos bloques de construcción de datos que se han presentado como parte de este esfuerzo será necesario definir en detalle durante la fase D. Los bloques de tecnología actual que puedan soportar en el ambiente destino deben ser refinados en la fase D. El orden de los pasos en esta fase, así como el tiempo en el que están formalmente iniciados y terminados debe adaptarse a la situación en cuestión de acuerdo con la Gobernanza de la arquitectura establecida. En particular, determinar si en esta situación, es conveniente llevar a cabo la descripción de línea base o desarrollar de la Arquitectura Objetivo primero.
4 Todas las actividades que se han iniciado en estos pasos deben estar cerrados durante el la Finalización de la Arquitectura de Aplicación. La documentación generada a partir de estos pasos deben ser publicados formalmente en el paso de crear el documento de definición de la Arquitectura. Los pasos en la Fase D (arquitectura de tecnología) son los siguientes: Selección de Modelos de referencia, puntos de vista y herramientas Desarrollo de al Descripción de la Línea de Base de la Arquitectura de Tecnología. Desarrollar la Descripción Arquitectura de Tecnología Objetivo. Realizar el Análisis de Brechas. Definir los componentes candidatos a la Hoja de ruta. Revisión de formal de las partes interesadas. Finalizar la Arquitectura de Tecnología Crear Documento de Definición de la Arquitectura de Tecnología. Selección de modelos de referencia, puntos de vista y herramientas Revisar y validar el conjunto de los principios de la tecnología. Normalmente, éstas pasarán a formar parte de un conjunto general de principios de arquitectura. Lineamientos para elaborar y aplicar los principios y un conjunto de muestras de los principios de la tecnología, se dan en la Parte III, Capítulo 23. Seleccione los recursos pertinentes Arquitectura Tecnología (modelos de referencia, patrones, etc.) desde el repositorio de arquitectura (ver Par t V, capítulo 41, página 479), sobre la base de los impulsores del negocio, las partes interesadas y sus preocupaciones. Seleccione los puntos de vista relevantes arquitectura tecnológica que permitan al arquitecto para demostrar cómo las preocupaciones de los interesados se están abordando en la arquitectura tecnológica. Identificar las herramientas y técnicas adecuadas para ser utilizadas para la captura, modelado y análisis, junto con los puntos de vista seleccionados. Dependiendo del grado de sofisticación requerido, éstos pueden comprender documentos simples y hojas de cálculo, o herramientas y técnicas de modelado más sofisticadas.
5 Determine proceso de modelado global Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico necesario, utilizando la herramienta seleccionada o método. Asegúrese de que todas las preocupaciones de los interesados están cubiertas. Si no es así, crear nuevos modelos para abordarlos, o aumentar los modelos existentes. El proceso para desarrollar una arquitectura tecnológica incorpora los siguientes pasos: Definir una taxonomía de los servicios de la plataforma y los componentes lógicos de tecnología (incluidas las normas) Identificar los lugares pertinentes donde la tecnología se implementa Llevar a cabo un inventor y físico de la tecnología de desplegado y extracto hasta encajar en la taxonomía Revisar los requisitos de tecnología de aplicación y negocio Está la tecnología en el lugar apto para el propósito de cumplir con los nuevos requisitos (es decir, permite atender requisitos funcionales y no funcionales)? o Acotar la taxonomía o Selección de productos (incluidos los productos dependientes) Determinar la configuración de la tecnología seleccionada Determinar impacto: o Dimensionamiento y cálculo del costo. o Planificación de la capacidad. o Instalación / gobierno /impacto de la migración. Las áreas donde la Arquitectura de Tecnología podría impactar podrían incluir las siguientes: Rendimiento: La granularidad del servicio tendrá un impacto en los requisitos de servicio de la plataforma. Mantenibilidad: Si granularidad servicio es demasiado amplia, entonces la introducción de cambios en el servicio se hace difícil y afecta el mantenimiento del servicio y la plataforma sobre la que se entrega. Ubicación y Latencia: Los servicios podrían interactuar entre sí a través de enlaces remotos y servicios de comunicación inter-vicio que tendrá incorporada la latencia. Dibujo límites del servicio y establecer la granularidad del servicio debe considerar el impacto de estas comunicaciones entre servicios.
6 Disponibilidad: Invocación del servicio está sujeto a fallos en la red y / o servicio. Tan alta disponibilidad comunicación es un factor importante durante la descomposición y definición del servicio. Desarrollando la descripción de la línea base de la Arquitectura de Tecnología Desarrollar una descripción de la línea base de la arquitectura de tecnología existente, para apoyar la arquitectura tecnológica objetivo. El alcance y el nivel de detalle que se define dependerán de la medida en la que los componentes ya existentes de tecnología son susceptibles de ser trasladado a la Arquitectura de la tecnología objetivo, y de si existen descripciones arquitectónicas. Identificar los componentes básicos relevantes de la Arquitectura de Tecnología, basándose en los artefactos encontrados en el Repositorio de Arquitectura. Si nada existe en el repositorio de Arquitectura, definir cada solicitud en línea con el catálogo de Portafolio de Tecnología. Desarrollando la descripción de la Arquitectura de Tecnología Destino Desarrollar una descripción para la Arquitectura de tecnología objetivo, en la medida necesaria para apoyar la visión de Arquitectura, Arquitectura de Negocios Objetivo, y Arquitectura de Sistemas de Información objetivo. El alcance y el nivel de detalle que se define dependerán de la pertinencia de los elementos de la tecnología a la consecución de la arquitectura objetivo y de si existen descripciones arquitectónicas. En la medida posible, las correspondientes bloques de construcción Arquitectura de Tecnología, basándose en el Repositorio de la Arquitectura. Un proceso clave en la creación de un modelo arquitectónico del sistema objetivo es la conceptualización de los bloques de construcción. Bloques de construcción (Arquitectura ABBS) describen la funcionalidad y la forma en que puede llevarse a cabo sin el detalle presentado por la configuración o diseño detallado. Ejecución del Análisis de Brechas Verifique la consistencia y precisión de los modelos de arquitectura: Realizar análisis de compensación para resolver conflictos (si existe) entre las diferentes vistas. Validar que los modelos son compatibles con los principios, objetivos y limitaciones.
7 Tenga en cuenta los cambios en el punto de vista representados en los modelos seleccionados desde el repositorio de Arquitectura, y la documentación. Modelos de prueba de arquitectura para la integridad frente a los requisitos Identificar las diferencias entre la línea base y la Arquitectura Objetivo, utilizando la técnica de análisis de brechas, como se describe en Parte III, Capítulo 27. Definir los componentes candidatos Hoja de ruta Después de la creación de una arquitectura de base, Arquitectura Objetivo, y el análisis de brechas, una Hoja de Ruta Tecnológica tiene la obligación de dar prioridad a las actividades en las fases siguientes. Esta hoja de ruta Tecnología Arquitectura inicial será utilizada como materia prima para apoyar definición más detallada de un plan general consolidado interdisciplinario y un plan general de la fase de Oportunidades y Soluciones. Resolver los impactos a través de la Arquitectura del Paisaje Una vez que la Arquitectura de la tecnología se ha finalizado, es necesario comprender los impactos más amplios o implicaciones. Realizar una revisión formal de las partes interesadas Compruebe la motivación original para el proyecto de arquitectura y la Declaración de Trabajo Arquitectura en contra de la Arquitectura de la tecnología propuesta, preguntando si es apto para el propósito de apoyar el trabajo posterior en los dominios de la arquitectura. Refinar la Arquitectura de la tecnología propuesta sólo si es necesario. Finalizar la arquitectura tecnológica Seleccione estándares para cada uno de los bloques de construcción, reutilizando tanto como sea posible a partir de los modelos de referencia seleccionados desde el repositorio Arquitectura. Documentar cada elemento Realizar final de una verificación cruzada de la arquitectura global con los objetivos de negocio, documento fundamento para la construcción de bloques de decisiones en el documento de arquitectura. Requisitos del documento de informe final trazabilidad.
8 Documento final de la cartografía de la arquitectura dentro de la arquitectura de repositorio, desde los bloques de construcción seleccionados, identificar las que podrían ser reutilizados (Métodos de trabajo, roles, relaciones de negocios, descripciones de puestos, etc.), y publicar a través del Repositorio de Arquitectura. Finalizar todos los productos de trabajo, tales como el análisis de la brechas. Crear el Documento de Definición de la Arquitectura Documentar la justificación para la construcción de bloques de decisiones en el documento de definición de la arquitectura. Preparar las secciones de tecnología del Documento de definición de la arquitectura, que comprende algunos o todos los siguientes: Funcionalidad Fundamental y atributos - semántico, sin ambigüedades de capacidad, incluida la seguridad y capacidad de gestión. Dependencias de los bloques de construcción con las interfaces necesarias. Interfaces - conjunto elegido, (API, los datos, protocolos, interfaces de hardware, estándares). SALIDAS Las principales salidas de la Fase D (Arquitectura de Tecnología) son: Versiones refinadas y actualizadas de los entregables de la Visión de la Visión, incluyendo: o Estatuto de Trabajo de Arquitectura. o Principios de Tecnología. Borrador de Documento de Definición de la Arquitectura. o Línea base de la Arquitectura de Tecnología. o Arquitectura de Tecnología Objetivo. Componentes tecnológicos y sus relaciones en el sistema de información. Plataformas de tecnología y su descomposición, mostrando las combinaciones de tecnología requerida para realizar una particular tecnología.
9 Ambientes y localizaciones. Comunicaciones físicas (redes). Especificaciones de equipo y redes. o Vistas correspondientes a los puntos de vistas seleccionados orientados a las necesidades de las partes interesadas. Borrador de la Especificación de Requerimientos. o Resultado del análisis de brechas. o Requerimientos de las fase B y C. o Requerimientos de tecnología actualizados. Componentes de la Arquitectura de Aplicaciones de la hoja de ruta de la Arquitectura. Contenido Fuente:
Figure 13-1: Phase E: Opportunities & Solutions
Fase E: Oportunidades y Soluciones Figure 13-1: Phase E: Opportunities & Solutions Objetivos Los objetivos de la Fase E son: Generar la primera versión completa de la Hoja de Ruta de la arquitectura, basado
Figure 14-1: Phase F: Migration Planning
FASE F PLAN DE MIGRACION Figure 14-1: Phase F: Migration Planning En este capítulo se aborda la planificación de la migración, es decir, cómo pasar de la línea de base a la Arquitectura Objetivo. Arquitecturas
Figure 17-1: ADM Architecture Requirements Management
Administración de los Requerimientos de la Arquitectura Figure 17-1: ADM Architecture Requirements Management Objetivos Los objetivos de la fase de gestión de requisitos son los siguientes: Asegúrese de
ANEXO TECNICO. Fábrica de Software
Contratar el servicio de desarrollo e implementación de sistemas de información para la ESAP mediante el modelo de fábrica de software, de acuerdo con las especificaciones técnicas definidas por la entidad.
5.7.2 DST - Desarrollo de soluciones tecnológicas de TIC Objetivos del proceso
5.7.2 DST - Desarrollo de soluciones tecnológicas de TIC 5.7.2.1 Objetivos del proceso General: Establecer el método a seguir para el desarrollo de soluciones tecnológicas de TIC, considerando la especificación
MANUAL DE PROCEDIMIENTOS. DES ACNF.- Proceso de Administración de la Configuración
Hoja:1 de 16 ACNF.- Proceso de Administración de la Configuración Hoja:2 de 16 1.0 PROPÓSITO 1.1. Establecer y actualizar un repositorio de configuraciones, en el que se integren las soluciones tecnológicas
Métodos para el diseño de soluciones
Sergio Sotelo IBM Software IT Architect [email protected] Agenda Unified Method Architecture Introducción a TOGAF 2 Método o Metodología? Método Modo de decir o hacer con orden una cosa Métodología Ciencia
Figure 9-1: Phase C: Information Systems Architectures
FASE C Figure 9-1: Phase C: Information Systems Architectures Objetivos Los objetivos de la Fase C son: Desarrollar la arquitectura de sistemas de información objetivo (datos y aplicaciones), que describe
Metodología propia del ERP de SAP
3 Metodología propia del ERP de SAP METODOLOGÍA 1.1.1. Metodología ASAP La metodología ASAP es una metodología por fases, orientada a entregables que agiliza los proyectos de aplicación, minimiza el riesgo
Planeador de Torneos y Competencias: PLATYCO. Documentación de la Arquitectura de Software
Planeador de Torneos y Competencias: PLATYCO Documentación de la Arquitectura de Software Daniel Santiago Vásquez Acero 22/08/2014 Tabla de figuras Ilustración 1: Modelo "4+1"[1]... 4 Ilustración 2: Servicio
Especificación de Requerimientos <Nombre del Proyecto> Nombre del Grupo de Desarrollo o Asignatura Nombre del Autor
Especificación de Requerimientos Nombre del Grupo de Desarrollo o Asignatura [Este documento es la plantilla base para elaborar el documento Especificación de Requerimientos. Los textos que aparecen entre
METRICA VERSION MÉTRICA versión 3. Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información
9.000 MÉTRICA versión 3 Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información 9.010 Enero 2000 borrador de metodología MÉTRICA v. 3 Ofrece a las organizaciones un instrumento
Nombre de la asignatura: Análisis y modelado de sistemas de información
Nombre de la asignatura: Análisis y modelado de sistemas de información Créditos: 3 2-5 Aportación al perfil Formular, gestionar y evaluar el desarrollo de proyectos informáticos en las organizaciones.
ARQUITECTURA EMPRESARIAL
ARQUITECTURA EMPRESARIAL 55959245 QUA TUM IT [email protected] www.quantumit.com.mx EEste servicio permite trasladar una visión y estrategia de negocio en un cambio efectivo, permite evaluar las
Diseño: Arquitectura de Software. IF 7100 Ingeniería del Software
Diseño: Arquitectura de Software IF 7100 Ingeniería del Software 1 Qué es arquitectura de software? Es la definición de una solución estructurada que cumpla todos los requerimientos técnicos y operacionales,
octubre de 2007 Arquitectura de Software
octubre de 2007 Arquitectura de Software Seis mejores Prácticas Desarrollo Iterativo Administrar Requerimientos Usar Arquitecturas basadas en Componentes Modelado Visual (UML) Verificar Continuamente la
CONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL
I. Datos Generales de la Calificación CINF0285.01 Título Análisis y diseño de sistemas de información Propósito Brindar los parámetros requeridos para evaluar la competencia en las funciones del análisis
Ingeniería de Software: Y eso qué es?
Ingeniería de Software: Y eso qué es? Definición: Estrategia para desarrollar software de alta calidad. A qué se le denomina Software de alta calidad? Al software que sea: Util (al cliente). Portable.
Introducción. Justificación
Introducción La Arquitectura Empresarial es una metodología que integra y alinea los procesos, los datos, las aplicaciones y la infraestructura tecnológica con la estrategia de la organización. Esta metodología
Reglamento de Gobierno Corporativo
JM-62-2016 Reglamento de Gobierno Corporativo JM-62-2016, JM-102-2011, COBIT 4.1 By JAV [email protected] - 08/2016 CAPÍTULO I: DISPOSICIONES GENERALES Artículo 2: Definiciones Sistema de control
AJUNTAMENT DE VALENCIA SERVICIO DE BOMBEROS, PREVENCIÓN E INTERVENCIÓN EN EMERGENCIAS E
E-01501-2011-422 PLIEGO DE CONDICIONES TECNICAS que ha de regir en la contratación del suministro e instalación de un software de gestión documental así como su integración en el sistema de información
Desarrollo del Módulo de Transportes para el Sistema de Gestión Académica RUTADEMIC
Gestión Académica RUTADEMIC DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE REQUISITOS FUNCIONALES Y NO FUNCIONALES Especificación de Requerimientos de Software DERS Historial de Revisión Fecha
Métrica v2.1 - Fase 0: Plan de Sistemas de Información. Enginyeria del Software. Curs 99/2000. Francisca Campins Verger
Métrica v2.1 - Fase 0: Plan de Sistemas de Información Fase 0: Plan de Sistemas de Información (PSI) Finalidad: Asegurar la adecuación entre los objetivos estratégicos de la organización y la información
Realización de Pruebas
Página 1 de 6 1. Objetivo y Alcance Establecer las pautas necesarias para ejecutar el proceso de pruebas de la versión de Software a liberar en el repositorio de Despliegue. Comprende desde la identificación
PROCESO DE AUDITORIA INTEGRAL. AudiLacteos S.A.S. Equipo Auditor EQUIPO 3 Blanca Duque. Yeimy L Escobar R. Pablo A. Molina R. Procesos auditados
PROCESO DE AUDITORIA INTEGRAL. Datos Generales Empresa Auditada AudiLacteos S.A.S Equipo Auditor EQUIPO 3 Blanca Duque. Yeimy L Escobar R. Pablo A. Molina R. Procesos auditados Firma Auditora Inicio de
MANUAL DE TALLERES INGENIERÍA DE SOFTWARE
MANUAL DE TALLERES INGENIERÍA DE SOFTWARE En el presente anual se encontrarán los talleres que se deberán realizar para lograr la consecución del proyecto final de la materia de Ingeniería de software.
Clasificación de las Herramientas CASE
Qué es una herramienta CASE? Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la
ÍNDICE INTRODUCCIÓN... 1 PERFIL DIRECTIVO... 2 PERFIL JEFE DE PROYECTO... 3 PERFIL CONSULTOR... 4 PERFIL ANALISTA... 5 PERFIL PROGRAMADOR...
ÍNDICE INTRODUCCIÓN... 1 PERFIL DIRECTIVO... 2 PERFIL JEFE DE PROYECTO... 3 PERFIL CONSULTOR... 4 PERFIL ANALISTA... 5 PERFIL PROGRAMADOR... 8 Participantes 1 INTRODUCCIÓN MÉTRICA Versión 3 ha sido concebida
TEMA 4. PROCESO UNIFICADO
TEMA 4. PROCESO UNIFICADO Definición El Proceso Unificado de Desarrollo Software es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura
Tecnología hardware y software
Denominación: Desarrollo de software Código : J62.05 Nivel: 4 Sector: Familia: Eje tecnológico: Programación informática, consultoría de informática y actividades conexas. Tecnología hardware y software
JM Reglamento de Gobierno Corporativo Capitulo 7. Auditoría Interna JM , JM , COBIT 4.1, COBIT 5 By Juan Antonio Vásquez
JM-62-2016 Reglamento de Gobierno Corporativo JM-62-2016, JM-102-2011, COBIT 4.1, COBIT 5 By Juan Antonio Vásquez CAPÍTULO I: DISPOSICIONES GENERALES Artículo 2: Definiciones Sistema de control interno:
ITIL PRACTICES FOR SERVICE MANAGEMENT ITIL FOUNDATION v3
TÍTULO ITIL PRACTICES FOR SERVICE MANAGEMENT ITIL FOUNDATION v3 CONTENIDO THE ITIL FOUNDATION CERTIFICATE IN IT SERVICE MANAGEMENT El propósito de la certificación de ITIL Foundation es para avalar que
BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA
BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA Contenido Una metodología para el desarrollo de software debe ser un instrumento que permita gestionar un proceso dado, existen hoy
PATRONES DE DISEÑO FRAMEWORKS
PATRONES DE FRAMEWORKS Definiciones Finalidades Características Diseño de software basado en patrones Descripción Utilización de los patrones en el diseño Clasificación FRAMEWORKS Basado en la reutilización
Los procesos de Iniciación
Los procesos de Iniciación Extracto de : Quesada, G. (2006). Metodología Integrada de PMI (Project Management Institute) y el PCM (Project Cycle Management) en la Dirección de Proyectos de Asistencia Humanitaria
MATRIZ DE VALORACIÓN O RÚBRICA. Actividad de evaluación:
10. Matriz de Valoración ó Rúbrica Siglema: ADSI-02 Nombre del Nombre del 1.1Realiza levantamiento de información y diagramado de datos, procesos, eventosrespuesta de la organización, mediante el apoyo
Diplomado Análisis de negocio, preparación para Certificación
Diplomado Análisis de negocio, preparación para Certificación Duración 104 horas Objetivo general: Enseñar los principales elementos, métodos y técnicas del análisis de negocio de una forma práctica y
INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ
INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ TEMA 3: PROCESO UNIFICADO DE DESARROLLO CONTENIDO 1. Proceso de Software 2. Proceso de Desarrollo de Software 3. Proceso Unificado de Desarrollo de Software
Índice. Introducción... 19
' Editorial UOC 9 Índice Índice Introducción... 19 Capítulo I. La gestión de proyectos. Conceptos básicos... 29 1. Qué es un proyecto... 32 2. Dimensiones de un proyecto. Definiciones... 35 3. Ciclo de
PROCEDIMIENTO DE EVALUACIÓN Y ACREDITACIÓN DE LAS COMPETENCIAS PROFESIONALES CUESTIONARIO DE AUTOEVALUACIÓN PARA LAS TRABAJADORAS Y TRABAJADORES
MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES
MARCO DE REFERENCIA ESTRATEGIA DE TI PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO
MARCO DE REFERENCIA PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO ESTRATEGIA DE TI ENTENDIMIENTO ESTRATÉGICO DE AE 1. Entendimiento estratégico: Las entidades y el sector deben formular una estrategia
El ciclo de vida de un sistema de información
El ciclo de vida de un sistema de información 1. Las etapas del proceso de desarrollo de software Planificación Análisis Diseño Implementación Pruebas Instalación / Despliegue Uso y mantenimiento 2. Modelos
Metodología Métrica v. 3.0
Metodología Métrica v. 3.0 Ingeniería del Software Escuela Superior de Informática Universidad de Castilla-La Mancha 16/01/2001 1 Estructura de la metodología PSI: Planificación de sistemas de información
NÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO
PACK FORMATIVO EN DESARROLLO DE APLICACIONES CON TECNOLOGÍA WEB NÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO - Identificar la estructura de una página web conociendo los lenguajes
TERMINOS DE REFERENCIA CONSULTORÍA NACIONAL EN SERIES ESTADÍSTICAS ECONOMICAS
TERMINOS DE REFERENCIA CONSULTORÍA NACIONAL EN SERIES ESTADÍSTICAS ECONOMICAS I. ANTECEDENTES El Instituto Nacional de Estadística e Informática (INEI) del Perú se encuentra en una fase de fortalecimiento
Técnicas de Pruebas de
Técnicas de Pruebas de Software Lecturas Pruebas de Unidades Pruebas Integración Docente Beatriz E. Florián [email protected] Mayo 3 de 2005 Pruebas Reglas de oro para pruebas Límites de Pruebas: Probar
4.2 ACTIVIDAD DE APRENDIZAJE 4.2: Diseñar el modelo relacional de la base de datos del sistema Descripción de la AA4.2:
4.2 ACTIVIDAD DE APRENDIZAJE 4.2: Diseñar el modelo relacional de la base de datos del sistema. 4.2.1 la AA4.2: Nombre de la Actividad de Aprendizaje 4.2: Resultado de aprendizaje relacionado al desarrollo
MANUAL DE ORGANIZACIÓN. DIRECCIÓN GENERAL Fecha: JUN 15 DESCRIPCIÓN Y PERFIL DE PUESTOS
Hoja: 1 de 5 Nombre del puesto: Coordinador de Infraestructura de Edificio Inteligente Área: Departamento de Gestión de Arquitectura e Infraestructura Tecnológica Nombre del puesto al que reporta directamente:
Nueva ISO 9001:2015. Una norma que se adapta a su tiempo La importancia de la planificación para el establecimiento de objetivos de calidad
Nueva ISO 9001:2015 Una norma que se adapta a su tiempo La importancia de la planificación para el establecimiento de objetivos de calidad Principales ejes de ISO 9001:2015 NUEVA ISO 9001: 2015 Podemos
CAPÍTULO 9. SEGURIDAD DE LA INFORMACIÓN CÓDIGO SEP
CAPÍTULO 9. SEGURIDAD DE LA INFORMACIÓN CÓDIGO SEP 1. Introducción Cualquiera sea el soporte de la información, siempre debe protegerse adecuadamente y por medio de procesos que deben comprender una política,
Visibilidad y control sobre tus procesos de negocio
Visibilidad y control sobre tus procesos de negocio Proyecto financiado por: Mayo 2016 Hacemos de sus necesidades nuestras inquietudes 1. Introducción Gestión de Procesos de Negocio(BPM) Conjunto de métodos,
Aseguramiento de Calidad en el Desarrollo de Software Libre
Aseguramiento de Calidad en el Desarrollo de Software Libre Marzo, 2014 N. Baez, V. Bravo y J. Alvarez Contenido de la Presentación Segunda versión de la Metodología de Desarrollo de Software Libre. Segunda
Universidad de Los Andes. Propuesta de Metodología de Arquitectura
Universidad de Los Andes Propuesta de Metodología de Arquitectura Febrero - 2011 El Método de Diseño Centrado en Arquitectura (ACDM) El ACDM es un método desarrollado por Anthony Lattanze de la Universidad
Beneficios de una Arquitectura Empresarial
Curso de The Open Group Architecture Framework (TOGAF) Alinear la tecnología con la estrategia de negocio no es imposible, se puede lograr con una Arquitectura Empresarial. Por qué necesito una Arquitectura
Grupo de procesos de Planificación
Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Quinta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje
Capítulo III: MARCO METODOLÓGICO
Capítulo III: MARCO METODOLÓGICO Tipo de Investigación El presente trabajo de investigación, tuvo como propósito el desarrollo de una aplicación experimental que permitió evaluar la operatividad y funcionalidad
Especialistas en Auditoría de TI, Gestión de Riesgos, Control Interno, Gobierno de TI
Resumen de indicadores básicos de COBIT Preparado por: T I AUDISEG S.A. Utiles en los s iniciales para impulsar proyectos de implementación de gobierno Nota: Cobit posee más indicadores, estos se han seleccionado
Ingeniería de Software II. SETEPROS Plan de pruebas. Versión 1.0
Ingeniería de Software II SETEPROS Versión 1.0 Historial de revisiones Date Version Description Author 1.0 Primera versión Marcos Duque Oviedo Ingeniería de Software II, 2010 Página 2 de 11 Tabla de contenidos
Manual del proceso. Gestión de Diseño, Desarrollo y Mantenimiento de Aplicaciones Tecnológicas
Manual del proceso Gestión de Diseño, Desarrollo y Mantenimiento de Aplicaciones Tecnológicas Versión 1.0 Noviembre, 2017 MANUAL MAN-GTI-DDS-13- Gestión de Diseño, Desarrollo y Mantenimiento de Aplicaciones
Nombre del Proyecto Patrocinador Cliente Director del Proyecto
ACTA DE CONSTITUCIÓN DE PROYECTO Nombre del Proyecto Patrocinador Cliente Director del Proyecto 1 OBJETIVO DEL PROYECTO Entregable final que se busca generar con la ejecución del proyecto. DESCRIPCIÓN
La Solicitud de Dictamen Técnico, deberá plasmar los siguientes puntos:
La Solicitud de Dictamen Técnico, deberá plasmar los siguientes puntos: Objetivo. Del sistema. Alcance. Del sistema en general y de cada módulo. Detalle que deberá alcanzar el Software a Desarrollar. Describir
Gestión de la Calidad en los Proyectos
Gestión de la Calidad en los Proyectos Áreas de conocimiento Alcance Comunicaciones Riesgos Calidad Tiempos Adquisiciones Integración Recursos Humanos Costos 1 Área de conocimiento Calidad Incluye todas
Especificación de requisitos de software
Pág. 1 Especificación de requisitos de software Proyecto: Revisión [1.2] Pág. 2 Ficha del documento Fecha Revisión Autor Verificado dep. calidad. Febrero 26 2013 1.4 SoftwareOne Documento validado por
La impresión de este documento se considera COPIA NO CONTROLADA.
Este documento NO debe imprimirse (Directiva Presidencial 04 de 2012), asegúrese de consultar la versión vigente en https://sig.unad.edu.co Página 1 de 8 1) Descripción del Procedimiento 1.1) Unidad Responsable:
Análisis de Requisitos Funcionales y No Funcionales. Análisis y Diseño de Sistemas de Información UNIDAD 3
Análisis de Requisitos Funcionales y No Funcionales Análisis y Diseño de Sistemas de Información UNIDAD 3 Requisitos Los requisitos o requerimientos son la descripción de las necesidades que debe satisfacer
ITILv3-Transición del Servicio de Información. Figuras basadas en material ITIL
ITILv3-Transición del Servicio de Información Figuras basadas en material ITIL Fundamentos de ITIL Edición 2011 Transición del Servicio Transición del Servicio Transición del Servicio Definición Terminología
1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:
Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas
MANUAL DE ORGANIZACIÓN. DIRECCIÓN GENERAL Fecha: JUN 15 DESCRIPCIÓN Y PERFIL DE PUESTOS
Hoja: 1 de 5 Nombre del puesto: Coordinador de Infraestructura de Voz y Cableado Estructurado Área: Departamento de Gestión de Arquitectura e Infraestructura de Tecnológica Nombre del puesto al que reporta
Arquitecturas Orientadas a Servicios: Service Oriented Modeling Framework SOMF
Arquitecturas Orientadas a Servicios: Service Oriented Modeling Framework SOMF ISIS 4707 Darío Correal ([email protected]) SOMF El modelado Orientado a Servicios es una prácica del desarrollo de
ESQUEMA DEL TRABAJO DE INVESTIGACIÓN (TI)
ESQUEMA DEL TRABAJO DE INVESTIGACIÓN (TI) Carátula Escuela Universitaria de Ingeniería Carrera de Ingeniería de Sistemas Modalidad de Titulación Titulo [Nombres y Apellidos Estudiante 1] [Nombres y Apellidos
Ingeniería del Software 2
Análisis de requisitos es la 1ª fase técnica del proceso de ing. del SW Éxito -> Comprensión total de los requisitos Análisis de requisitos -> Tarea de descubrimiento, refinamiento, modelado y especificación
TALLER DE ARQUITECTURA EMPRESARIAL ESTRATEGIA DE ACOMPAÑAMIENTO 2016
TALLER DE ARQUITECTURA EMPRESARIAL ESTRATEGIA DE ACOMPAÑAMIENTO 2016 Agenda 1. Reflexión 2. Terminología. 3. Introducción al concepto de Arquitectura Empresarial. 3. Beneficios de la Arquitectura empresarial.
