2.4.3: The level of deference
Chapter 3: Developing Alexy: institutional sensitivity and the structural model of proportionality and deference
3.5. HISTORIAS DE USUARIO 25 Uso de las Tecnolog´ıas de la Informaci´on y la Comunicaci´on (TIC), como herramienta para la gesti´on de requerimientos en la organizaci´on.
Procesos y funciones m´as relevantes en la administraci´on del flujo de trabajo de los requerimientos.
Problemas presentados en la administraci´on del flujo de trabajo de los requerimientos. En la siguiente fase de investigaci´on se llevar´a a cabo el completo an´alisis de la informaci´on obtenida en la entrevista, se describir´an casos de estudio, se realizar´a el dise˜no y formulaci´on de los procedimientos para la validaci´on de los datos obtenidos. Dicha informaci´on ser´a la base para el an´alisis que permitir´a generar u obtener los requisitos funcionales y no funcionales del desarrollo planteado.
3.5.
Historias de Usuario
A continuaci´on mostraremos cada una de las historias de usuario que hicieron parte del desarrollo del prototipo y fueron una guia para lograr cumplir el objetivo:
Figura 3.4: Historia de Usuario 1
Figura 3.6: Historia de Usuario 3
Figura 3.7: Historia de Usuario 4
3.5. HISTORIAS DE USUARIO 27
Figura 3.9: Historia de Usuario 6
Figura 3.10: Historia de Usuario 7
Figura 3.12: Historia de Usuario 9
Figura 3.13: Historia de Usuario 10
Parte II
Arquitectura
Cap´ıtulo 4
ADM
4.1.
Introducci´on
A la hora de empezar un negocio se tienen bastantes dificultades, en la actualidad cuando nos encontramos en la era de la informaci´on se debe pensar en que la estructura de una organizaci´on sea inteligente, bien hecha, respete a las personas, perdure en el tiempo y lo mas importante que las futuras generaciones hereden lo que se ha hecho y lo mantengan; lograr todo esto no es tarea f´acil, por este motivo naci´o la arquitectura de negocio.
Muchas empresas se pueden comparar con castillos de arena, ya que funcionan por un tiempo pero despu´es se caen, para no llegar a esto debemos hacer un profundo an´alisis de lo que deseamos crear, tener la informaci´on correcta y con esto construir bases solidas para que nuestro negocio se mantenga al pasar los a˜nos.
La Arquitectura Empresarial o arquitectura de negocio (AN) busca hacer mas productiva y competitiva una organizaci´on a trav´es del uso de la tecnolog´ıa como su principal herramienta de ejecuci´on e integraci´on de sus procesos, para que esto sea posible es necesario seguir una serie de pasos que abarquen desde el diagnostico hasta la gu´ıa de implementaci´on de los nuevos sistemas de informaci´on; por esta raz´on existen una serie de metodolog´ıas est´andar que ayudan a las organizaciones en su proceso de adopci´on de esta arquitectura.
Para el negocio del software existe una de las m´etodos mas populares para desarrollar la arquitectura empresarial ADM que es el resultado de las contribuciones de numerosos profesionales de la arquitectura y constituye el n´ucleo de TOGAF. Es un m´etodo para obtener Arquitecturas Empresariales que son espec´ıficas para la organizaci´on, y est´a especialmente dise˜nado para responder a los requerimientos del negocio.
La arquitectura empresarial describe el producto y las estrategias de servicio de la orga- nizaci´on incluyendo informaci´on sobre las dimensiones geogr´aficas del negocio, debe mostrar como una organizaci´on alcanzara las metas, que roles van a tener las personas dentro de la organizaci´on, mostrar el proceso de negocio y la relaci´on entre el proceso del negocio y las personas de la organizaci´on, el objetivo de todo esto es desarrollar la arquitectura empresarial realizando una descripci´on detallada que permita crear un punto de referencia de como la empresa alcanzara los objetivos del negocio, llevar a cabo un an´alisis de las diferencias del punto de referencia de las arquitecturas y sus objetivos.
El conocimiento pleno y solido de la arquitectura de negocio de una organizaci´on es un prerrequisito para llevar a cabo la declaraci´on de trabajo en los dem´as dominios de la arqui-
tectura empresarial, si esta se aplica de la mejor forma nuestra compa˜n´ıa va a perdurar.
4.2.
M´etodo
El M´etodo de Desarrollo de la Arquitectura (ADM) describe:
Un modo confiable y probado para desarrollar y utilizar una Arquitectura Empresarial Un m´etodo para desarrollar arquitecturas en diferentes niveles (negocio, aplicaciones, datos, tecnolog´ıa) que permiten al arquitecto asegurar que un conjunto complejo de requerimientos se aborden adecuadamente
Un conjunto de gu´ıas y t´ecnicas para el desarrollo de arquitectura
Las actividades en ADM son de forma iterativa y se basanen los requisitos establecidos, llegando a cumplir los objetivos planteados en la transformaci´on de la empresa.
Este m´etodo proporciona las siguientes fases:
Fase Preliminar: En esta etapa se define el ´ambito de la organizaci´on afectado por la iniciativa de la arquitectura empresarial, as´ı como su equipo y los principios de la arquitectura aplicables. Por ´ultimo, deben implementarse las herramientas necesarias para el desarrollo de la arquitectura.
Fase A – Visi´on de Arquitectura: Se deben identificar las partes interesadas, sus inquietudes y requerimientos de negocio. En esta fase, es el momento en el que tambi´en se deben confirmar los principios de arquitectura y desarrollar el documento de visi´on de arquitectura para poder proporcionar una visi´on general de los cambios que se llevar´an a cabo en la organizaci´on como resultado de la iniciativa de la arquitectura empresarial.
Fase B – Arquitectura de Negocios - Fase C – Arquitectura de Sistemas de Informaci´on - Fase D – Arquitectura de Tecnolog´ıa: En estas tres fases, se desarrolla la l´ınea base de arquitectura (AS-IS Architecture) y la arquitectura final (es decir, la arquitectura objetivo de la iniciativa de la arquitectura empresarial, TO- BE Architecture) para cada dominio de arquitectura (negocio, datos, aplicaciones y tecnolog´ıa).
Tras realizar las arquitecturas AS-IS y TO-BE, se debe realizar el gap analysis entre am- bos para producir la hoja de ruta de arquitectura (Roadmap Architecture) para llegar a la arquitectura objetivo. El entregable principal de esta etapa es el documento de de- finici´on de arquitectura. Este documento contiene los artefactos arquitect´onicos b´asicos creados durante el proyecto y toda la informaci´on importante relacionada. El documen- to de definici´on de arquitectura abarca todos los dominios de la arquitectura (negocios, datos, aplicaciones y tecnolog´ıa), tambi´en examina todos los estados relevantes de la arquitectura (l´ınea base AS-IS, transici´on y destino TO-BE).
Fase E – Oportunidades y Soluciones: En esta fase, se define la planificaci´on inicial para la puesta en marcha de la arquitectura objetivo, se identifican y agrupan los prin- cipales paquetes de trabajo necesarios, as´ı como las posibles arquitecturas de transici´on
4.2. M ´ETODO 33 (es decir, arquitecturas intermedias hacia la arquitectura objetivo). Adem´as, debe defi- nirse la estrategia de alto nivel para la implementaci´on y la migraci´on a la arquitectura TO-BE.
Fase F – Planificaci´on de Migraci´on: En esta fase, los proyectos de migraci´on identificados en la etapa anterior son priorizados. Para ello, se debe realizar la evaluaci´on coste/beneficio, an´alisis de riesgo y la asignaci´on del valor para el negocio que se obtiene con ellos. Adem´as, la hoja de ruta de arquitectura debe ser confirmada, el documento de definici´on de arquitectura debe ser actualizado y el plan de implementaci´on y migraci´on debe ser finalizado.
Fase G – Gobernanza de la Implementaci´on:En esta fase, se confirma y supervisa el alcance y las prioridades de los proyectos de implementaci´on. Tambi´en, se realizan las revisiones de cumplimiento de arquitectura empresarial, as´ı como las revisiones de post-implementaci´on para validar cualquier proyecto respecto a la arquitectura definida.
Fase H – Gesti´on de Cambios de Arquitectura: En esta fase, “se revisa que la arquitectura resultante alcanza el valor para el negocio que se hab´ıa establecido como objetivo. Adem´as, tambi´en deben estar establecidos los procedimientos necesarios para poder gestionar el cambio, tanto el proceso para la implementaci´on del mismo como el seguimiento y la gesti´on de riesgos”
Cada unas de las fases que hacen parte de AMD van relacionadas en varios procesos de la vida empresarial incluso en el ciclo de vida del desarrollo en V unas a otras de forma iterativa, como lo muestra la siguiente imagen:
Cap´ıtulo 5
Archimate
5.1.
Introducci´on
Archimate es un lenguaje arquitect´onico que proporciona los elementos de informaci´on necesarios para mostrar la funcionalidad dentro de un proyecto de arquitectura empresarial. Archimate tiene la ventaja como lenguaje que lo puede usar un experto del dominio y un experto t´ecnico. Archimate define que la arquitectura empresarial es la identificaci´on de unos problemas y el desarrollo que hace un grupo de personas para resolverlos utilizando tecno- log´ıas de informaci´on. Este representa los conceptos de las capas mediante grafos, algunos tomados del lenguaje unificado de modelado del ingl´es Unified Modeling Language (UML) y los presenta en distintos colores. Los colores son para generar conceptos similares en las capas y su trazabilidad.
Es una de las capas m´as importantes debido a que el lenguaje que se utiliza, permite hablar en terminos de las entidades del negocio, por lo que es importante distribuir adecuadamente la semantica. Esta capa gira en torno a tres dimensiones de comportamiento: procesos, servicios y producto (centro del negocio). La indagaci´on que uno hace al modelar esta capa es convertirla en software. Las capas agregan conceptos que soportan las etapas del ADM de TOGAF en las fases B, C y D que se encuentran relacionadas con el negocio, aplicaci´on o datos e infraestructura.
Cap´ıtulo 6
Empresa
6.1.
Introducci´on
ASReq S.A. ofrece conocimiento, ingenier´ıa, informaci´on e imaginaci´on para dar servi- cios tecnol´ogicos de vanguardia, ofreciendo productos para que permitan llevar una mejor organizaci´on y control de los procesos en el desarrollo de software.
Nuestra compa˜n´ıa ofrece sistemas inform´aticos para gestionar todo el flujo de trabajo de cualquier proyecto.
6.2.
Nombre
La empresa donde se pondr´a en practica el proyecto se llama: ASReq S.A. (Acceso, Soft- ware y Requerimiento)
Figura 6.1: Logo Empresa ASReq
6.3.
Misi´on
Nuestra misi´on es proveer servicios y soluciones de TI; para todo tipo de organizaciones especialmente en el ´area de desarrollo de software, presentando a nuestros clientes las mejores alternativas de soluci´on: eficientes, pr´acticas, innovadoras, con tecnolog´ıa de punta, y que les
permita incrementar la productividad, eficiencia y competitividad. Apoyados en el talento humano comprometido y de un alto nivel profesional.
6.4.
Visi´on
ASReq se proyecta a 5 a˜nos para consolidarse como la empresa l´ıder en soluciones tecnol´ogi- cas, prestando nuestros mejores servicios, con herramientas de alto valor a˜nadido, fortaleciendo nuestros productos en America Latina; contemplando planes de expansi´on internacional.
6.5.
Organigrama
Figura 6.2: Organigrama ASReq
6.6.
Funciones
Generar un software comercial que permita su uso sin ninguna restricci´on por un per´ıodo limitado de tiempo
Tener un buen desempe˜no en cuanto a la competencia con otras empresas de nuestro sector.
Poseer los mejores ingenieros de sistemas del pa´ıs para garantizarle la buena calidad, eficiencia y eficacia en el producto.
Generar un software din´amico y adaptable a toda organizaci´on que requiera control de sus requerimientos.
6.7. PROCESOS 39
6.7.
Procesos
En un mercado cada vez m´as globalizado y competitivo, s´olo las empresas m´as fuertes y con mayor capacidad de adaptaci´on a las nuevas circunstancias pueden sobrevivir. Esta fortaleza se consigue lanzando al mercado productos y servicios nuevos o mejorados, que permitan a las empresas diferenciarse de la competencia. Para ello, la apuesta por la investigaci´on, desarrollo e innovaci´on (I+D+i) es una garant´ıa de ´exito.
En ASReq contamos con un ´area de I+D+i que se encarga de investigar nuevos m´etodos y conocimientos, desarrollo de aplicaciones y productos singulares e innovaci´on en procesos, que nos conviertan en una empresa puntera en el sector.
6.8.
Productos y Servicios
Servicios de desarrollo de software de clase mundial, combinando la flexibilidad y dina- mismo al flujo de trabajo de requerimientos ofreciendo soluciones ´optimas para todo tipo de industria.
REGADMIN WEB: Aplicativo web para la gesti´on de requerimientos.
REGADMIN MOVIL: Aplicativo M´ovil para la actualizaci´on de estados y consulta de un requerimiento.
Flexibilidad para su empresa: Configure sus requerimientos de manera totalmente flexi- ble y programable
Cap´ıtulo 7
Negocio
7.1.
Introducci´on
La arquitectura de negocio es el resultado de la definici´on de la estrategia de la organiza- ci´on, de sus procesos de negocio y su funcionalidad. Es la base para identificar los requisitos de los sistemas de informaci´on que apoyan a las actividades del negocio, provee una vista sim- plificada de la estructura y comportamiento del negocio que nos permitir´a mejorar e innovar en el negocio.
A continuaci´on mostraremos cada punto de vista que hace parte del negocio, su modelo y el respectivo caso que aplica para nuestra organizaci´on.