FASE B ARQUITECTURA DE NEGOCIO

Slides:



Advertisements
Presentaciones similares
MODELOS ORIENTADOS A OBJETOS
Advertisements

El ciclo de vida de un proyecto
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Gestión de Proyectos Sesión Septiembre 5 de 2009.
Herramientas y metodologías de éxito para el manejo de proyectos TIC: Caso PYME CREATIVA Noviembre 2008.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Equipo 11 -Enríquez Chávez Jocelyn -Martínez Arvallo Diana Berenice
Enrique Masias Mario Panuera Mario Miranda Edward Cornejo
TOGAF.
Request for infomation – Solicitud de información
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Sistema de Gestión de la Calidad
Medición, Análisis y Mejora
Yeimi Constanza Patiño
Evaluación de Productos
Ciclo de formulación del proyecto.
Electivo Integración Normas de Calidad, Seguridad, Medio Ambiente y Riesgos en la Gestión de la Empresa. Profesor : Fernando Vargas Gálvez Ingeniero Civil.
Capacitación y desarrollo
Gung Ho! Gung Ho! Gestión de los Stakeholders
GESTIÓN INTEGRADA DE CALIDAD
CONFORMACIÓN DEL MANUAL DE PROCESOS Y PROCEDIMIENTOS
AUDITORIAS RESUMEN DE ASPECTOS RELEVANTE EN LA GESTION BASADO EN EL REFERENCIAL ISO 9001:2008.
Arquitectura Orientada a Servicios
GESTION DEL CAMBIO Los presencia continua de competencia, la internacionalización económica y la aparición de nuevas tecnologías de información e informática.
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.
Ciclo de vida de la administración de servicios de TI
Gestión de Calidad Ley 872 de 2003, Decreto 4110 de 2004,Decretos Departamentales 0025 y 0063 de 2005 (Decretos modificados con la reforma institucional.
©Copyright 2013 ISACA. Todos los derechos reservados Capacidades Las capacidades son habilitadores fundamentales del gobierno. Las capacidades.
Plan de Sistemas de Información (PSI)
Architecture Development Method (ADM)
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.
ESTUDIO ORGANIZACIONAL
1.17 Implementación del gobierno de la seguridad—Ejemplo
Términos y Conceptos Básicos
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
Proveedores de servicios externos
Ciclo de vida de un sistema
FACTIBILIDAD DE LOS SISTEMAS DE INFORMACIÓN
Roles de Open UP.
Elaborado por: Mayoral Cruz Matilde Morales Espinoza Anllhins
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Organización para la calidad.
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.
Procesos itil Equipo 8.
TOGAF De Jesús Córdova Esaú García Gamboa Jazmín Elizabeth
1 Módulo de Fundamentos 5 Incidencia. 2 Sección 1 Roles y tipos de incidencia en situaciones de emergencia Sección 2 Principios del enfoque de derechos.
Estructurar tus ideas para hacerlas realidad
Ciclo de Vida del Software
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Introducción a la Administración de Proyectos
LAR 145 Capítulo C.
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
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.
Planificación de Sistemas de Información
Procesos de Planeación
Nombre del campus Componente profesional
Verificación y Validación del Software
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Entregables del Proyecto
GESTIÓN DE PROYECTOS.
UNESCO ESTÁNDARES DE COMPETENCIAS EN TIC PARA DOCENTES - Los docentes han de tener recursos en materia de TIC - Tanto docentes como estudiantes han de.
Gestión del Alcance del Proyecto
Ing. Sanchez Castillo Eddye Arturo Escuela Académica Profesional de Ingeniería de Sistemas.
Junio, 2013.
Transcripción de la presentación:

FASE B ARQUITECTURA DE NEGOCIO CAPITULO 8 FASE B ARQUITECTURA DE NEGOCIO

8.1 Objetivos Describir las bases de la Arquitectura de Negocio Desarrollar una Arquitectura de Negocio objetivo describiendo la estrategia de producto o servicio y de los aspectos organizacionales, funcionales, de proceso, de información y geográficos del ambiente de negocio. Seleccionar las herramientas relevantes y técnicas usadas en asociación con los puntos de vista seleccionados.

8.2 Acercamiento 8.2.1 General La Arquitectura de Negocio es usada de forma frecuente para demostrar el valor de retorno de un negocio y del valor que se invierte en el negocio. El alcance de la fase B dependerá en gran medida del entorno de la organización. Una llave para el éxito de los objetivos es reusar material existente tanto como sea posible .

8.2.2 Desarrollando la Descripción de la Línea Base Si una empresa tiene documentación que hable de la descripción de la arquitectura debe de ser usada como base de la Descripción de Línea Base. Si no existe tal documentación, la información deberá ser recolectada sin importar el formato en el que se consiga. El arquitecto a cargo debe de documentar todo lo que concierne a la arquitectura de alto nivel. Algunos elementos como principios, modelos, estándares e inventario suelen no tomarse en cuenta pero deberán de serlo, ya que, en algún momento se puede dar la situación que se requieran valores con mucho detalle. Se debe de tener un panorama general de la empresa pero cuidando no exceder en detalle.

8.2.3 Modelado de Negocio Existen variedad de herramientas y técnicas de modelado para el Modelado de Negocio, algunas son: Modelos de Actividad Describe las funciones asociadas con las actividades de negocio de la empresa , los datos/información intercambiada entre las actividades. Captura las actividades realizadas en un proceso de negocio y las entradas, controles, salidas, y mecanismos usados en las mismas. Modelos de CU Describen tanto los procesos de negocio como las funciones de sistema. Modelos de clase Describe información estática y la relación entre esta información. También describe el comportamiento de la información. Puede representar entidades o clases del sistema.

8.2.4 Arquitectura de repositorio Que recursos se van a tomar del repositorio: Object Management Group (OMG) TeleManagement Forum (TMF) Resource Event Agent STEP Framework Open Application Groups RosettaNet

8.3.1 Materiales de referencia 8.3 Entradas 8.3.1 Materiales de referencia

Arquitectura de materiales de referencia El Repositorio de Arquitectura actúa como una zona de espera para todos los proyectos relacionados con la arquitectura. El repositorio permite a los proyectos gestionar sus prestaciones, localizar activos reutilizables y publicar los resultados a las partes interesadas.

8.3.2 Entradas no arquitectónicas

Solicitudes de trabajo de Arquitectura Es un documento que se envía desde la organización que patrocina a la organización de arquitectura para disparar el inicio de un ciclo de desarrollo de la arquitectura. Las solicitudes suelen incluir: Organización patrocinada Misión de la organización Los objetivos de negocio

Los planes estratégicos de la empresa Presupuesto de información Descripción del sistema de negocios Descripción de sistemas de TI

8.3.3 entradas de arquitectura

Modelo Organizacional para la Arquitetura de la empresa Tiene que ser compatible con la organización, las funciones y responsabilidades dentro de la empresa. De particular importancia es la definición de los límites entre los diferentes profesionales de la arquitectura

Típico modelo organizativo Alcance de las organizaciones de afectados en evaluación y el enfoque de resolución Funciones y responsabilidades de equipo de arquitectura Restricciones sobre el trabajo de la arquitectura Necesidades presupuestales

Adaptando Arquitectura TOGAF proporciona un marco para la arquitectura estándar de la industria que puede ser utilizado en una amplia variedad de organizaciones. Sin embargo, antes de TOGAF se puede utilizar eficazmente dentro de una arquitectura proyecto, la adaptación a dos niveles es necesario.

1.- Para adaptar el modelo TOGAF para la integración de la empresa. Esta adaptación incluirá la integración con los marcos de gestión de proyectos y procesos, personalización de terminología, el desarrollo de estilos de presentación, selección, configuración y despliegue de herramientas de arquitectura

Una vez que el marco se ha adaptado a la empresa, es necesario para adaptar el marco del proyecto de arquitectura específica para satisfacer las necesidades del proyecto

Declaración Aprobada del trabajo de Arquitectura Define el alcance y enfoque que se utiliza para completar un proyecto de arquitectura. La Declaración de Arquitectura es normalmente el documento contra el cual se medirá la correcta ejecución del proyecto de arquitectura y pueden, por medio de la base de un acuerdo contractual entre el proveedor y el consumidor de la arquitectura de servicios.

Repositorio de Arquitectura Incluye: 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

Visión de Arquitectura Se crea desde el principio del ciclo de vida del proyecto y proporciona un alto nivel, visión del producto arquitectura final. El propósito de la visión es estar de acuerdo en el principio el cuál será el resultado deseado, por lo que los arquitectos pueden entonces concentrarse en las áreas críticas para validar la viabilidad. La visión de la Arquitectura debe ser compatible con la comunicación con los interesados​​.

Incluye: Refinados requisitos de los interesados de alto nivel Línea de Base de Arquitectura de negocios Arquitectura de Tecnología Arquitectura de datos Arquitectura de aplicaciones Objetivo de Arquitectura de negocios Objetivo de la Arquitectura de la Tecnología Arquitectura de datos de destino

8. 4. Pasos para la Arquitectura de Negocios 8. 4 8.4 Pasos para la Arquitectura de Negocios 8.4.1 Selección de modelos de referencia, puntos de vista y herramientas Seleccionar los recursos de la Arquitectura de Negocio desde el repositorio de Arquitectura, sobre la base de los impulsores del negocio, y las partes interesadas y sus preocupaciones. Identificar las herramientas y técnicas adecuadas a ser utilizadas para la captura, modelado y análisis, junto con los puntos de vista seleccionados. Dependiendo del grado de sofisticación de la garantía, éstos pueden contener documentos u hojas de cálculo sencillas o herramientas más sofisticadas y técnicas de modelado, como los modelos de actividad, modelos de procesos de negocio, modelos de casos de uso, etc.

8.4.1.1 Determinar proceso de Modelado General Modelos de la actividad, los modelos de casos de uso, y los modelos de clase son técnicas que permiten la definición de la arquitectura de negocio de una organización. Análisis Estructurado: Identifica las funciones clave de negocio en el ámbito de la Arquitectura y los mapas de las funciones en las unidades de la organización dentro de la empresa. Análisis de casos de uso: El desglose de las funciones de nivel empresarial a través de actores y permite identificar los actores de una función y permite una interrupción en los servicios de apoyo / entrega de esa capacidad funcional. Modelado de Procesos: El detalle de una función o servicio de negocio a través de modelado de procesos permite identificar los elementos del proceso y permite la identificación de los servicios a las empresas de menor nivel o funciones.

8.4.1.2 Identificar servicio obligatorio con un nivel de granularidad, límites, y contrato El marco de contenido TOGAF diferencia entre las funciones de una empresa y los servicios de una empresa. Servicios a empresas son las funciones específicas que tienen límites explícitos, definidos que se rigen de manera explícita. Con el fin de permitir la flexibilidad arquitecto para definir los servicios de negocio a un nivel gradual que sea apropiado para y manejable por la empresa, las funciones se dividen de la siguiente manera: Funciones de nivel micro tendrán límites explícitos, definidos, pero no pueden ser gobernados de forma explícita .

8.4.1.3 Identificar Catálogos obligatorios de los bloques huecos de Negocios Los catálogos son de naturaleza jerárquica y capturan la descomposición de un bloque de construcción y también a través de descomposiciones bloques de construcción relacionados. Actúan como un recurso clave para la gestión de la cartera de negocios y la capacidad de TI. Los siguientes catálogos deben ser considerados para el desarrollo dentro de una arquitectura de negocios: Organización / Catálogo de Actor Manejador / Meta / Catálogo de Objetivo Catálogo de funciones Servicio de Empresas / Catálogo de Función Catálogo Ubicación Proceso / eventos / Control / Catálogo de productos Contrato / Catálogo de medidas

8.4.1.4 Identificar matrices requeridas Las Matrices muestran las relaciones básicas entre las entidades del modelo relacionado. Son la materia prima para el desarrollo de puntos de vista y también actúan como un recurso clave para la evaluación del impacto, llevado a cabo como parte del análisis de vacío. Las siguientes matrices deben ser considerados para el desarrollo dentro de una arquitectura de negocios: Matriz de Negocio de interacción (que muestra la dependencia y la comunicación entre organizaciones y actores) Matriz Actor / papel (mostrando los roles asumidos por cada actor)

8.4.1.5 Identificar esquemas obligatorios Diagramas presentan la información Arquitectura negocios de un conjunto de diferentes perspectivas (miradores) de acuerdo con los requisitos de las partes interesadas. Los siguientes diagramas deben ser considerados para el desarrollo dentro de una arquitectura de negocios: Diagrama de Huella de negocios Diagrama de Servicio / Información de contacto Diagrama de Descomposición Funcional Meta / Objetivo / diagrama de Servicio Diagrama de casos de uso Diagrama de descomposición Organización Diagrama de Flujo del Proceso Diagrama de Eventos

8.4.1.6 Identificar los tipos de requisitos que deben recolectarse En este paso, el arquitecto debe identificar los tipos de requisitos que deben ser cumplidos por la implementación de la arquitectura, entre ellos: Requisitos funcionales Requisitos no funcionales Supuestos Restricciones Principios de dominio específico Arquitectura Gente Políticas Normas Directrices Especificaciones

8.4.2 Desarrollar descripción de referencia de Arquitectura de Negocios El alcance y el nivel de detalle que se define dependerán de la medida en que son susceptibles de ser transportados en el punto de la Arquitectura de negocios, y de si existen descripciones de elementos. En la medida de lo posible, el tipo de arquitectura a bloques de construcción de negocios pertinentes, basándose en el Repositorio de Arquitectura

8.4.3 Desarrollar descripción de objetivos de la Arquitectura de Negocios Desarrollar una descripción del objetivo de la arquitectura de negocios, en la medida necesaria para apoyar la visión Arquitectura. El alcance y el nivel de detalle que se define dependerá de la pertinencia de los elementos de negocio para alcanzar la Visión Arquitectura de destino y de si existen descripciones arquitectónicas. En la medida de lo posible, el tipo de arquitectura bloques de construcción de negocios pertinentes, basándose en el Repositorio de Arquitectura.

8.4.4 Realizar análisis de vacíos En primer lugar, verificar los modelos de arquitectura para la consistencia interna y la precisión: Realizar análisis de negocio para resolver conflictos (si los hay) entre los diferentes puntos de vista. Verifica los cambios del punto de vista representado en los modelos seleccionados de la Arquitectura Repositorio y documentos Los modelos de arquitectura de prueba para la integridad frente a los requisitos Identificar las diferencias entre la línea base y objetivo: Crear matriz de separación. Identificar los elementos básicos que deben realizarse sobre la clasificación, ya sea modificado o no modificado Identificar los elementos básicos eliminados Identificar nuevos bloques de construcción Identificar y clasificar las lagunas como las que debe desarrollarse y las que se adquirirán

8.4.5 Definir componentes del plan de trabajo Después de la creación de una arquitectura de línea de base de la Arquitectura de destino y los resultados de análisis de carencias, se requiere un plan de negocios para las actividades en las próximas fases. Esta hoja de ruta de la Arquitectura de Negocios inicial se utiliza como materia prima para apoyar definición más detallada de un plan de trabajo interdisciplinario consolidado dentro de la fase de las Oportunidades y Soluciones.

8.4.6 Resolver los impactos en la arquitectura del paisaje Una vez que la arquitectura de la empresa se haya terminado, es necesario entender las repercusiones o consecuencias. En esta etapa de la arquitectura deben ser examinados para identificar: ¿Crea esta Arquitectura De negocio un impacto sobre alguna arquitectura preexistente? ¿Han sido hechos cambios recientes aquel impacto sobre la Arquitectura De negocio? ¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de negocio en otras áreas de la organización? ¿Afecta esta Arquitectura De negocio otros proyectos (incluyendo aquellos planificados así como aquellos actualmente en curso)? ¿Será afectada esta Arquitectura De negocio por otros proyectos (incluyendo aquellos planificados así como aquellos actualmente en curso)?

8.4.7 Realizar examen formal entre los participantes Compruebe la motivación original para el proyecto de arquitectura y de la Declaración de Arquitectura de Trabajo contra la arquitectura de negocio propuesto, preguntando si es apto para el propósito de apoyar el trabajo posterior en el resto de ámbitos de arquitectura. Acotar la arquitectura de negocio prevista si es necesario.

8.4. 8 Crear definición de arquitectura del documento Seleccione las normas para cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados desde el repositorio Arquitectura Documentar completamente cada bloque de construcción Llevar a cabo una verificación cruzada de la arquitectura global con los objetivos de negocio final; documento de justificación de la construcción de las decisiones del bloque en el documento de la arquitectura Documento final, reporte de trazabilidad de requisitos Documento de asignación definitiva de la arquitectura en el Repositorio de Arquitectura, a partir de los componentes básicos seleccionados, identificar aquellas que podrían ser reutilizados (prácticas de trabajo, roles, relaciones comerciales, descripciones de puestos, etc), y publicar a través del Repositorio de Arquitectura Finalizar todos los productos de trabajo, como los resultados de análisis de carencias

8.4.9 Crear definición de arquitectura del documento Documento de justificación para la construcción de las decisiones del bloque de la arquitectura de definición de documento Preparar las secciones de negocios de la Arquitectura de definición de documento, que comprende algunos o todos los siguientes: La huella de negocio Una descripción detallada de las funciones de negocio y sus necesidades de información La huella de gestión Normas, reglas y pautas que muestran las prácticas de trabajo, la legislación financiera Una matriz de habilidades y un conjunto de descripciones de puestos

8.5 Resultados Versiones refinado y actualizado de la arquitectura entregables fase Visión, donde aplicables, incluyendo: -Declaración de Arquitectura Trabajo, actualizado si es necesario -Principios validados actividades, objetivos de negocio, y los conductores de negocios, actualizan si es necesario -Principios de Arquitectura Documento de Definición de Arquitectura Preliminar incluyendo: -Arquitectura de base de negocio -Arquitectura objetivo de negocio -Vistas correspondientes a los puntos de vista seleccionados abordan las preocupaciones de partes interesadas clave Especificación de Exigencias de Arquitectura Preliminar, incluyendo tales exigencias de Arquitectura De negocio como: -Resultados de los análisis Gap -Requisitos técnicos -Actualizado de requerimientos de negocio Componentes de la arquitectura de negocios de una Hoja de Ruta de la Arquitectura