Avance Conceptos
8
Click here to load reader
Transcript of Avance Conceptos
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Avance 1
Ingeniera Victoria Eugenia Ospina B.
Recolecta de Información.
Conceptos claves.
Para nosotras poder dar inicio a nuestro proyecto de grado “ESPECIFICACION DE
REQUERIMIENTOS A PARTIR DE LA ARQUITECTURA EMPRESARIAL. Es
necesario entender algunos conceptos.
Arquitectura empresarial
La Arquitectura Empresarial es el esquema mediante el cual se representan todos los
componentes, procesos y políticas que maneja una determinada organización a través
de modelos que permiten alinear las reglas del negocio y las tecnologías de
información existentes. La implementación de una Arquitectura Empresarial apoya en
la toma de decisiones estratégicas y efectivas que mejoran la calidad, eficacia y
responsabilidad del negocio y ayuda a responder de manera rápida y positiva a las
oportunidades y desafíos del mercado, consolidaciones del sector y avances
tecnológicos.
Algunos elementos claves para asegurar una adecuada implantación de una
Arquitectura Empresarial son:
Los objetivos del Negocio deben estar bien definidos y acordados antes de
iniciar la implantación de cualquier solución de TI.
Agregar valor al negocio a través de la tecnología de Información es la razón
primaria al tomar decisiones de inversión.
Las decisiones de arquitectura de TI deben maximizar la interoperabilidad y
reusabilidad.
Las decisiones de arquitectura de TI deben potenciar la agilidad y la eficiencia
empresarial.
El marco arquitectónico debe establecer estándares para satisfacer
necesidades comunes de los clientes interno y externo de la empresa.
Los requerimientos de TI y de negocio deben adoptar soluciones tecnológicas
comerciales en vez de soluciones propias o personalizadas, que respondan a
los principios arquitectónicos en su nivel.
La identificación, integración e implantación de servicios es la clave para
asegurar la flexibilidad y la adaptación del negocio.
El marco arquitectónico debe ser consistente con las políticas y objetivos
estratégicos de la organización.
Referencia:
www.corporacionsybven.com/.../index.php?...arquitectura-empresari...
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
¿Qué es un requerimiento?
El concepto fundamental para entender los elementos que componen este trabajo de
grado, es el concepto de requerimiento. La definición más general alrededor de esta
noción es la que brinda el Instituto de Ingeniería Electrónica y Eléctrica (IEEE)9:
(1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
(2) Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal.
(3) Una representación documentada de una condición o capacidad
documentada como las descritas en (1) y (2).
Esta definición expresa la perspectiva clásica de los requerimientos como elementos
de un producto, o criterios para acuerdos. Los requerimientos son una especificación
de lo que debe ser implementado.
El análisis de requerimientos puede dividirse en cuatro áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.
Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de
proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los
programas que se usó para generar las estimaciones de la planificación. A
continuación, debe establecerse la comunicación necesaria para el análisis, de forma
que se asegure el reconocimiento del problema.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de
trabajo del análisis. El analista debe evaluar el flujo y estructura de la información,
refinar en detalle todas las funciones del programa, establecer las características de la
interface del sistema y descubrir las ligaduras del diseño, cada una de las tareas
sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o
solución global.
Que es la especificación de requerimientos: son los datos obtenidos durante la
recopilación de hechos que se analizan para desarrollar la descripción de las
características del nuevo sistema. Esta actividad tiene tres partes relacionadas entre
sí, a saber:
3.1 Análisis de datos basados en hechos reales.
3.2 Identificación de requerimientos esenciales.
3.3 Selección de estrategias para satisfacer los requerimientos.
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Todo sistema de información posee un conjunto de requerimientos básicos y un
conjunto de requerimientos específicos dependiendo de si, el sistema será de soporte
para transacciones o para la toma de decisiones.
Seguido se presentará un grupo de preguntas que al dárseles respuesta
proporcionarán un conjunto de hechos de los que posteriormente se obtendrá una
especificación de requerimientos lo más apegada posible a las necesidades de
cualquier organización.
Para llegar a obtener unos requerimientos básicos es necesario realizarnos las
siguientes preguntas:
¿Cuál es el proceso básico de la empresa?
¿Qué datos utiliza o produce este proceso?
¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
¿Qué controles de desempeño utiliza?
¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del
sistema?
¿Existen manuales de procedimientos, políticas o lineamientos de desempeño
documentados oficial o no oficialmente?. Si los hay, ¿Se cumplen en forma
cabal en el 100% de las ocasiones?, es decir, ¿se respetan dichos
procedimientos?
¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
¿Qué áreas necesitan un control específico?
¿Qué criterios se emplean para medir y evaluar el desempeño?
¿Existen actividades que considere podrían mejorarse?, ¿De qué manera?
¿Tiene alguna idea de actividades que podrían implementarse para mejorar el
rendimiento del sistema en general?
En la siguiente imagen se va a determinar que existen diferentes tipos de
requerimientos pero sin importar todos tienen su propia especificación de
requerimientos.
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Referencia:
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4100010/Lecciones/Cap3/Reqm
tos.htm
En la anterior imagen se mostraba un ejemplo de los requerimientos, la plantilla
VOLERE nos da una definición de los tipos de requerimientos que se pueden definir.
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Requerimientos funcionales, son los “objetos” o “sujetos” fundamentales o
esenciales que constituyen la base del producto. ¿Qué tiene que hacer el
producto? ¿Cómo lo debe hacer?
Requerimientos no funcionales, son las propiedades que las funciones deben
tener, tales como desempeño y capacidad de uso.
Las Restricciones de Diseño, imponen restricciones sobre cómo debe
diseñarse el producto.
Las Guías del Proyecto, son las fuerzas relacionadas con el negocio, como el
propósito del proyecto, es una guía del proyecto.
Los Aspectos del Proyecto, definen las condiciones bajo las cuales se hará el
proyecto. ¿Por qué?
Para una buena construcción de requisitos es necesario:
Comprobar los requisitos tan pronto como se comiencen a escribir. Se hace a un
requisito comprobable agregándole criterios de aceptación. Estos criterios de
aceptación miden el requisito, haciendo posible el determinar si una solución dada es
cónsona con el requisito. Todos los requisitos pueden ser medidos. Por eso es
importante crear una guía para la construcción de los mismos, con el fin de buscar un
orden y un esquema común, como lo es la propuesta por VOLERE (ver imagen).
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Referencia:
http://www.volere.co.uk/pdf%20files/template_es.pdf
Para comprender más a fondo por que la obtención de requisitos es costosa, y el
porqué el hacer el proyecto seria provechoso para las empresas e intentado responder
a uno de los objetivos en el que estaba enfocado el proyecto, de si era posible hacer
que las empresas gastaras menos recursos en este proceso, se encontró algunas
razones del porque es tan costoso la construcción de los mismo.
• Problemas de alcance.
El límite del sistema está mal definido o los detalles técnicos innecesarios, que han
sido aportados por los clientes/usuarios, pueden confundir más que clarificar los
objetivos del sistema.
• Problemas de comprensión.
Los clientes no están completamente seguros de lo que necesitan, tienen una pobre
comprensión de las capacidades y limitaciones de su entorno de computación, no
existe un total entendimiento del problema, etc.
• Problemas de volatilidad.
Los requisitos cambian con el tiempo.
Con el fin de darle solución a estos problemas, es necesario tener claridad e intentar
aproximarse de una manera organizada a la definición de los mismos, partiendo de las
bases de conocer el negocio y mejor aun a sus miembros involucrados.
Referencia:
http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos
TOGAF
The Open Group Architecture Framework
Es un esquema (o marco de trabajo) de Arquitectura Empresarial que proporciona un
enfoque para el diseño, planificación, implementación y gobierno de una arquitectura
empresarial de información. Esta arquitectura es modelada por lo general con cuatro
niveles o dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones; basándose en
un modelo de proceso iterativo soportado por buenas prácticas y un conjunto reusable
de activos arquitecturales existentes.
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Referencias:
http://arquitecturaempresarialcali.wordpress.com/ea-frameworks/togaf/
http://www.slideshare.net/carlos5paloma/togaf-7008349 (ejemplo de TOGAF)
e-Tom
Enhanced Telecomunication Operations Map
Es un marco referencial de procesos para la industria de las telecomunicaciones.
El eTOM se encuentra organizado en tres áreas de procesos:
1. Estrategia, Infraestructura y Producto, que cubre la planificación y la gestión de
los ciclos de vida. El eTOM agrega esta área al mapa de procesos, con el
propósito de destacar los procesos de planificación y desarrollo, de los
operacionales, que están más relacionados con el día a día del negocio.
2. Operaciones, que cubre el núcleo de la gestión operacional. El eTOM recoge
los procesos operacionales establecidos por el TOM, los cuales constituyen los
procesos end-to-end fundamentales de Aprovisionamiento, Aseguramiento, y
Facturación, agrupándolos en el área de Operaciones del nuevo mapa.
3. Gestión Empresarial, que cubre la gestión corporativa o de soporte al negocio.
En esta área se concentran los procesos que toda empresa debe tener para su
normal funcionamiento.
Referencias:
http://www.iptotal.com/s_etom.html (ejemplo de e-Tom)
http://www.multilingualarchive.com/ma/enwiki/es/ETOM
Zachman
Es un marco para la arquitectura empresarial , que proporciona una manera formal y
altamente estructurada de la visión y la definición de una empresa. Se compone de
una matriz de clasificación de dos dimensiones basado en la intersección de las seis
preguntas de comunicación (qué, dónde, cuándo, por qué, quién y cómo) con seis filas
de acuerdo a la reificación transformaciones.
Referencia:
http://test.zachmaninternational.com/index.php
Nombres: Febrero 3 - 2012 Claudia Marcela Martínez Monroy. Laura Alexandra Ochoa Cortes.
Al comprender en gran medida, de lo que componían la definición de estor tres marcos
para la definición de la arquitectura surgió la pregunta de si TOGAF y Zachman
definían arquitecturas empresariales en general, entonces ¿en que se diferenciaban?,
después de leer comprendimos que:
Zachman claramente dice que su Framework no es una metodología, que es
una estructura. TOGAF concibe su framework, como un método.
Zachman describe a la empresa en una matriz, a través de unos puntos de
vista, y unos interrogantes, TOGAF se centra más en los procesos de la
empresa, y la describe a través de 4 vistas o Arquitecturas.
Con Zachman no existe una dirección establecida en el proceso para la
aplicación de la arquitectura. El objetivo es asegurarse de que todos los
aspectos de una empresa estén cubiertos y mostrar las relaciones que
asegurarán un sistema completo sin importar el orden en el cual se establecen.
Mientras que con TOGAF si tienes requisitos previos para trabajar en la
arquitectura.
Será el Arquitecto de Empresa y los directivos de la organización quienes
decidan en consenso el que decida cuál Framework desea utilizar, como
referencia para desarrollar la Arquitectura Empesarial dentro de su
organización, según la estructura que la empresa posea.
