Equipo 11 -Enríquez Chávez Jocelyn -Martínez Arvallo Diana Berenice

Slides:



Advertisements
Presentaciones similares
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Advertisements

PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
NORMA INTERNACIONAL DE AUDITORÍA 300
CÓMO REALIZAR UN PROYECTO
Enrique Masias Mario Panuera Mario Miranda Edward Cornejo
TOGAF.
Proceso de Originación de Crédito: Banco de los Alpes
CONCEPTOS Y PRINCIPIOS DE DISEÑO
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Ingeniería del Software
Sistema de Gestión de la Calidad
Republica Bolivariana de Venezuela U.G.M.A 7mo semestre Ing. Sistema
Yeimi Constanza Patiño
Ciclo de formulación del proyecto.
HERRAMIENTAS CASE.
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
Sistemas de gestión de la calidad en empresas que desarrollan con Genexus Amalia Álvarez Balbi Gastón Mousqués
Las etapas de un proyecto
Redes II M. C. Nancy Aguas García. Redes Planeación Análisis y Diseño Instalación Evaluación Administración de software Mantenimiento de hardware.
REQUERIMIENTOS DE SOFTWARE
Planeación con Planning Tool y DotProject Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Rubby Casallas, Andrés Yie.
Contexto Proyecto consolidado dentro de la línea de investigación de Sistemas de Información en el Dpto. de Ingeniería en Sistemas de Información de la.
Ingeniería de Software
Plan de Sistemas de Información (PSI)
Architecture Development Method (ADM)
UML 2.0 Integrantes: Diana Carolina Valencia M. Jhon Fernando Lopez T. Carlos Alberto Castillo.
Ximena Romano – Doris Correa
Diseño del servicio ITIL..
Importancia en la efectividad del:
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Estudio de Viabilidad del Sistema (EVS)
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
Especialización en Desarrollo de Software
1.17 Implementación del gobierno de la seguridad—Ejemplo
Ciclo de vida de un sistema
FACTIBILIDAD DE LOS SISTEMAS DE INFORMACIÓN
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.
IDENTIFICACIÓN DEL CICLO DE VIDA DEL SOFTWARE. POLITÉCNICO COLOMBIANO JAIME ISAZA CADAVID.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
MAPEO ENTRE LOS PROCESOS DE TI Y LAS ÁREAS FOCALES DE GOBIERNO DE TI, COSO, LOS RECURSOS TI DE COBIT Y LOS CRITERIOS DE INFORMACIÓN DE COBIT APÉNDICE.
FASE B ARQUITECTURA DE NEGOCIO
Introducción al proceso de verificación y validación.
INSTITUTO POLITECNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS EQUIPO: 8 INTEGRANTES: Chávez.
Carlos Alberto Hernández Nava Alejandro Octavio Hernández Romero Efrén Dolores Romero C APITULO 6: F ASE P RELIMINAR I NGENIERÍA A DMINISTRATIVA 7NM1.
TOGAF De Jesús Córdova Esaú García Gamboa Jazmín Elizabeth
Capítulo 5: Introducción
Actividades en el Proceso de desarrollo de Software
Proyecto Master - Alberto Salgado - (C) Creative Commons V3.0 Master en Dirección y Gestión de las TIC Proyecto DETI Marco de trabajo para la evaluación.
Licda Josefina Arriola
Estructurar tus ideas para hacerlas realidad
Ciclo de Vida del Software
MÓDULO INTRODUCCIÓN AL CICLO DE VIDA DEL SOFTWARE
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
SOLUCIONES EMPRESARIALES
CONCEPTO DE CICLO DE VIDA 1 En los departamentos de Sistemas se debe definir un marco de referencia común que debe ser:  Pueda ser empleado por todos.
PARÁMETROS PARA LA PRESENTACIÓN DE PROYECTOS EN SISTEMAS
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
Procesos de negocio a los que apoya COBIT y ITIL
Las fases del ciclo de la vida de desarrollo de sistemas
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
RAPID APPLICATION DEVELOPMENT RAD. Proceso de RAD Involucrar en todos los aspectos al usuario en el desarrollo del sistema Uso continuo y repetitivo de.
Modelo de procesos de software
Planificación de Sistemas de Información
Procesos de Planeación
Entregables del Proyecto
Arquitectura de Negocio ARQUITECTURA EMPRESARIAL (AE)
Fase de Inicio Proceso Unificado de Desarrollo de Software.
Junio, 2013.
Transcripción de la presentación:

FASE C: Sistema de información, Arquitecturas–Arquitectura de aplicación Equipo 11 -Enríquez Chávez Jocelyn -Martínez Arvallo Diana Berenice -Martínez Campuzano Octavio -Montesinos Hernández Jesús Alfredo -Ríos Villaseñor Cristina

Objetivo Definir los principales tipos de sistemas de aplicación necesarias para procesar el datos y soporte al negocio. Lo importante es definir qué tipos de sistemas de aplicación son relevantes para la empresa con el fin de administrar los datos y presentar información de los recursos humanos y actores de un ordenador en la empresa.

Repositorio Arquitectura Modelos genéricos de negocio: Modelos de aplicación pertinentes a las funciones de negocio de alto nivel comunes, tales como el comercio electrónico, gestión de la cadena de suministro, etc. -El TeleManagement Forum (TMF) ha desarrollado detalladas aplicaciones de los modelos relacionados con la industria de las telecomunicaciones. -El Object Management Group (OMG) - tiene una serie de verticales, de trabajo de dominio en desarrollo de modelos software relacionados con dominios verticales específicos como la salud, Transporte, Finanzas, etc.

Repositorio Arquitectura The Open Group cuenta con un modelo de referencia para la Infraestructura de la Información Integrada que se centra en los componentes y servicios a nivel de aplicación. La iniciativa ebXML tiene como objetivo proporcionar una infraestructura abierta, basado en XML que permite el uso global de la información de comercio electrónico de una manera inter operable, segura y consistente.

Entradas Arquitectónicas Modelo de Organización de Arquitectura empresarial incluyendo: - Alcance de las organizaciones de afectados. - Evaluación de Madurez, lagunas, y el enfoque de resolución. - Roles y responsabilidades de equipo de arquitectura(s). - Restricciones en la obra de arquitectura. - Necesidades presupuestarias. - Estrategia de Gobierno y apoyo.

Entradas Arquitectónicas Marco de Arquitectura Adaptado incluyendo: - Método de arquitectura adaptada - Contenido de la arquitectura adaptada (entregables y artefactos) - Herramientas de configuración e implementación. Arquitectura repositorio incluyendo: - Bloques de construcción reutilizables - Modelos de referencia disponibles al público - Modelos de referencia específicos de la organización - Normas de la Organización

Entradas Arquitectónicas Proyecto de Arquitectura definición de documento incluyendo: - Línea de Base Arquitectura negocios. - Arquitectura de datos de línea de base. - Arquitectura de datos de destino. - Arquitectura de aplicaciones de línea de base. - Arquitectura de Tecnología de línea de base. Proyecto de Arquitectura de la especificación de requisitos incluyendo: - Los resultados de análisis de lagunas (de Arquitectura de Negocios y Arquitectura de datos, si están disponibles) - Los requisitos técnicos pertinentes que se aplicarán a esta fase.

Pasos Fase C Dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. Los pasos en la Fase C (Arquitectura de la aplicación) son los siguientes: -Seleccionar modelos de referencia, puntos de vista y herramientas -Desarrollar Base de Arquitectura de aplicaciones (Descripción) -Desarrollar Target Aplicación Arquitectura (Descripción) -Realizar análisis de brecha -Definir los componentes de la hoja de ruta -Resolver los impactos en la Arquitectura del Paisaje -Conducta para mal interesados ​​revisión -Finalizar la arquitectura de la aplicación -Crear Arquitectura (definición de documento)

Seleccionar modelos de referencia puntos de vista y herramientas Revisar y validar o generar, si es necesario el conjunto de principios de aplicación. Normalmente, éstas formarán parte de un conjunto global de principios de arquitectura. Seleccionar los recursos Arquitectura de Aplicación correspondientes (modelos de referencia, patrones, etc.) desde el repositorio de Arquitectura, sobre la base de los impulsores del negocio, las partes interesadas y sus preocupaciones.

Seleccionar modelos de referencia puntos de vista y herramientas Considere el uso de descripciones independientes de la plataforma de la lógica de negocio. Por ejemplo, la OMG de Model Driven Architecture (MDA) Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico requerido, utilizando la herramienta o método seleccionado.

Seleccionar modelos de referencia puntos de vista y herramientas Identificar Catálogos obligatorios de los bloques de construcción de aplicaciones. La organización del portafolio de aplicaciones se captura como un catálogo dentro de la Arquitectura Repositorio y los catálogos son de naturaleza jerárquica. Identificar Matrices requeridas Las matrices muestran las relaciones básicas entre las entidades del modelo relacionado.

Seleccionar modelos de referencia puntos de vista y herramientas Identificar esquemas obligatorios Los diagramas presentan la información arquitectura de la aplicación de un conjunto de diferentes perspectivas de acuerdo con los requisitos de las partes interesadas. Identificar los tipos de requisitos que deben recogerse Una vez que la arquitectura de aplicaciones, matrices y diagramas han sido desarrollados, se completa mediante la formalización de los requisitos de aplicaciones enfocadas a la aplicación de la arquitectura.

Desarrollo de aplicaciones de línea de base (Arquitectura Descripción) Desarrollar una línea de base Descripción de la arquitectura de aplicaciones existente, en la medida necesaria para apoyar la arquitectura de la aplicación de destino. El alcance y el nivel de detalle que se define dependerán de la medida en que son susceptibles, de ser transportado en la arquitectura de la aplicación de destino y de si existen descripciones de la arquitectura

Desarrollar Target Aplicación Arquitectura Desarrollar una descripción del objetivo de la arquitectura de la aplicación, en la medida necesaria para apoyar la Arquitectura Visión, Arquitectura “Target” negocios y datos de destino. El alcance y el nivel de detalle que se define dependerá de la pertinencia de los elementos de las aplicaciones a la consecución de la Visión Arquitectura “Target”, y en si existen descripciones arquitectónicas.

Realizar análisis de brecha En primer lugar, verificar los modelos de arquitectura para la consistencia interna y la precisión. Identificar las diferencias entre la línea base y meta: - Crear matriz de brecha - Identificar los bloques de construcción para ser prorrogados, clasificar, ya sea modificado o no modificado - Identificar los bloques de construcción eliminados - Identificar nuevos bloques de construcción - Identificar y clasificar las lagunas como las que debe desarrollarse y los que deben ser adquiridos

Definir los componentes de la hoja de ruta Después de la creación de una arquitectura de línea de base, Arquitectura Target, y análisis de las deficiencias, se requiere un plan de aplicación para dar prioridad a las actividades en las próximas fases. Esta hoja de ruta inicial de Arquitectura de aplicaciones se utilizará como materia prima para apoyar la definición más detallada de un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y la fase Solución.

Resolver los impactos en la Arquitectura del Paisaje En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: ¿Esta arquitectura de aplicaciones creara un impacto en las arquitecturas preexistentes? ¿Se han hecho los cambios recientes que afectan a la arquitectura de aplicaciones? ¿Hay algunas oportunidades para aprovechar el trabajo de la Arquitectura de la aplicación de otros áreas de la organización? ¿Tiene este impacto Arquitectura de aplicaciones otros proyectos (incluyendo los previstos, así como los actualmente en curso)? ¿Esta arquitectura de aplicaciones se vera afectado por otros proyectos (incluyendo los previstos, así como los actualmente en curso)?

Conducta para mal interesados ​​revisión Compruebe la motivación original para el proyecto de arquitectura y de la Declaración de Arquitectura Trabajo en contra de la arquitectura de la aplicación propuesta. Llevar a cabo un análisis de impacto, para identificar las áreas donde las arquitecturas de negocio y los datos (por ejemplo, las prácticas comerciales) pueden necesitar cambiar a atender a los cambios en la arquitectura de la aplicación (por ejemplo, sistemas de aplicaciones o sistemas de base de datos).

Finalizar la arquitectura de la aplicación -Seleccione las normas para cada uno de los bloques de construcción. -Documentar completamente cada bloque de construcción -Realizar última comprobación cruzada de la arquitectura general de los requerimientos del negocio -Documento del informe final trazabilidad requisitos -Finalizar todos los productos de trabajo, tales como análisis de las deficiencias

Salidas Arquitectónicas Los resultados de la Fase C incluyen: -Versiones refinado y actualizado de la arquitectura entregables fase Visión - Declaración de la arquitectura de trabajo - Principios de aplicación validados, o nuevos principios de aplicación

Salidas Arquitectónicas Proyecto de Arquitectura definición de documento incluyendo: - Arquitectura de aplicaciones de línea de base - Target Application Architecture - Modelo de sistemas de proceso - Modelo de sistemas Place - Modelo de sistemas Tiempo

Salidas Arquitectónicas Proyecto de Arquitectura de la especificación de requisitos incluyendo: -Requisitos arquitectura de aplicaciones -Los resultados del análisis -Aplicaciones requisitos de interoperabilidad -Los requisitos técnicos pertinentes que se aplicarán a esta evolución de la arquitectura (ciclo de desarrollo) -Restricciones en la arquitectura de la tecnología al ser diseñados -Actualización requerimientos del negocio -Actualización requisitos de datos