Está en la página 1de 44

Arquitectura Empresarial de EsferaTech

(Área de desarrollo de Software)

Johan Agustin Bayona


Leonardo Garcia Amortegui

Especialización en Arquitectura de software


Principios de Arquitectura
Universidad Javeriana
2019
Objeto para el desarrollo de la Arquitectura Empresarial

Organización Objetivo

Empresa: EsferaTech
Dirección: Calle 126 #49-41 Edf Almarial 2, Ofc 10, Bogota Colombia
Telefono: (031) 7215445
Rubro: Desarrollo de Hardware y Software

Descripción: Empresa que surgió por la necesidad de EsferaColor (empresa de distribución de


pinturas para vehículos) por buscar alternativas a la inminente caída de la venta de pinturas por la
conducción autónoma y equipamiento de los vehículos de nueva generación, que disminuirá
notablemente los accidentes de tránsito y por tanto la venta y distribución de pinturas para
vehículos, y por la cercanía y conocimiento de los concesionarios de vehículos, quisieron estructurar
un área para desarrollar productos que dieran solución a temas asociados a los concesionarios de
vehículos. Encabeza de Juan Manuel Gutiérrez Gerente de esfera Color, quien en asociación con
Johan Bayona Desarrollador de Hardware y Software se asociaron para crear el área de desarrollo
que empezó con una solución de gestión de tiempos y comunicación con los clientes llamada
SysTime, emprendiendo un camino de investigación y desarrollo de hardware para el
posicionamiento en tiempo real RTLS y software para gestión y administración, la cual duro unos 4
años, donde se fueron fortaleciendo en el camino con profesionales y herramientas lo cual resulto
en una patente en Colombia y Estados Unidos y en la primera versión de SysTime, después mediante
la necesidad de desarrollo de GCA empresa que se mueve en el área de tránsito y transporte del
país, encabezada por Guillermo Corredor, quien necesitaba un área de desarrollo de software para
productos para la secretarias de tránsito y policía se unió como cliente principal de la sociedad
EsferaTechnology, y actualmente además de haber desarrollado diferentes productos para
compañías como FASECOLDA entre otras se sigue desarrollando y fortaleciendo 3 productos
internos SysTime, Traces y Ubicar.

Descripción de productos:

Desarrollo a la medida
EsferaTechnology ofrece Desarrollo de soluciones a la medida que contengan un componente de
hardware y o Software de interés y alineado a los principios de EsferaTechnology, pero
principalmente se dedica el desarrollo comercialización de sus productos principales, SysTime,
Traces y Ubicar.

SysTime
Desarrollo de una Herramienta (Hardware) Rtls (posicionamiento en tiempo real) de vehículos y
operarios dentro de un concesionario de vehículos, desarrollando los tags o etiquetas para rastrear
en tiempo real, las antenas que recopilan dicha información y un motor de localización que se
encarga de traducir toda la información recogida por los sensores y transformarla para el software
de gestión.
Generando una Herramienta móvil (Software) en UWP (Universal Windows Platform) de gestión
monitoreo de tiempos y procesos productivos dentro de un concesionario de vehículos y sus
diferentes departamentos (Colisión, Mecánica, Usados y Nuevos), generando la información para el
control y administración del estado de los vehículos en cualquier parte del proceso, control de carga
de trabajo, tablero de control, seguimientos entre otros.

Servicios SOAP para la comunicación interne entre concesionarios y los dispositivos de localización
en tiempo real, así como Servicios REST para lo centralización de la información en la nube y
comunicación con el cliente.

Centralización de la información sensible a Big Data de todos los vehículos que pasa por los
concesionarios que usen nuestro sistema

Ubicar
Herramientas móviles en Android y iOS para la gestión de los vehículos por parte del usuario
(Dueños de vehículos) donde pueden administrar temas legales del vehículo, Mantenimientos
preventivos, Reparaciones, recordatorios entre otros, comunicado en tiempo real con el vehículo y
los concesionarios.

Servicios REST para las aplicaciones móviles y la administración de sus vehículos, así como la
comunicación constante con los concesionarios cuando dichos vehículos se encuentran en
reparación, o para la cotización y/o agendamientos, así como para búsqueda y compra de productos
relacionado a los vehículos, como SOAT, Accesorios entre otros.

Centralización de la información sensible a Big Data de todos los vehículos.

Traces
Solución de software para le levantamiento digitalización, centralización y administración de la
información de los IPATs (Informe Policial de Accidentes de Tránsito) para las secretarías del país.
Generando una herramienta móvil en Android para levantamiento de accidentes quien permite
registrar el accidente de forma fácil, eficiente y rápida mediante con módulo de dibujo para el
croquis, vinculación de levantamiento mediante escaneo en 3D con un scanner láser 3d y
comunicación y control de drones para el levantamiento mediante Photogrametría (Renderizado 3D
mediante fotografías).

Servicios para el tránsito de la información segura respetando la cadena de custodia y asegurando


la información con técnicas de BlockChain.

Herramientas web para la administración de los IPATs, visualización de los mismos por parte de los
interesados como involucrados (conductores), abogados, agentes, administración de usuarios,
agente, dispositivos, Rangos, Evidencias entre otros.

Centralización de información sensible a Big Data de las diferentes secretarias respetando la


información confidencial y cadena de custodia de cada una de ellas.
Misión y Visión

Organigrama

Objetivos:

A continuación, se describe brevemente los roles indicados en el organigrama:

Junta de Socios

Junta de socios de la compañía compuesta por 3 Socios, con una distribución de las sociedades
establecidas mayoritariamente por el socio #1 EsferaColor, y en partes iguales para el socio #2 Juan
Manuel Gutiérrez y el socio #3 Johan Agustín Bayona Camargo, son los encargados de las decisiones
importantes en términos de la compañía, las estrategias, inversiones y presupuestos a los proyectos.

CEO
El CEO (Chief Executive Officer) es el encargado de los temas de negocios, relaciones con los clientes
en gran parte del marketing y la penetración que tiene la empresa en el mercado
CTO
El CTO (Chief Technology Officer) quien se encarga de todos los procesos tecnológicos de la empresa
y a la vez actúa como arquitecto y líder de desarrollo de los proyectos,

CFO
CFO (Chief Financial Officer) Encargados de todos los temas financieros, de recursos humanos y
legales, esta se tercerista y es ejecutada por las áreas correspondientes de la empresa EsferaColor
quien es socio mayoritario de la compañía,

Área de Investigación y Desarrollos, esta es usada cuando los proyectos requieren resolver
problemas no comunes y desarrollar nuevas tecnologías, como fue el caso del Rtls para SysTime.

Hardware

Todos los temas de Investigación y desarrollo de dispositivos electrónicos.

Software

Todo lo relacionado a nuevas herramientas técnicas o soluciones de software.

Di Diseño
Área de Diseño de soluciones o productos que se encargan de establecer qué y cómo se
desarrollaran los proyectos o productos.

Analista

Es la persona encargada de analizar el problema a solucionar analizar en el entorno y hacer un


levantamiento de Historias. Y convertir este en requerimientos y un listado de PBIs, así como de las
pruebas de las nuevas funcionalidades desarrolladas

Arquitecto

Es el encargado de plantear y diseñar la solución en términos tecnológicos para el Hardware y el


Software.

Diseñador Gráfico

Quien se encarga de establecer la UI y UX de la solución.

Diseño Electrónico

Quien diseña las soluciones electrónicas de componentes, tecnologías y/o circuitos.


Diseño de PCBs

Encargado del diseño de circuitos electrónicos PCBs, gestiona los insumos de componentes y envía
a fabricación y ensamble que se realiza con terceros.

De Desarrollo
Área de Desarrollo de Producto, codificación de software.

Inf estructura Redes

Rol que determina, configura y establece todo lo relacionado a comunicaciones y redes dentro de
cada uno de los proyectos, así como de mantener los ambientes de desarrollo y el correcto
funcionamiento de los equipos e infraestructura que soporta la operación

Desarroll Backend

Programador de Backend, servicios o lógica de negocio que corre en los servidores inside o en la
nube.

Desarroll FrontEnd

Programador encargado de desarrollar los clientes (Windows, Android, iOS) y conectarse a los
servicios establecidos en el Backend.

Electrónico

Programador de microcontroladores, drivers de conexión, dispositivos embebidos entre otros.

DBA

Encargado de diseñar y desarrollar y mantener las Bases de Datos.

Tester

Es el rol que prueba todos los desarrollos y/o productos para aprobar las nuevas funcionalidades
antes de ser implementadas o pasadas a producción.

Soporte Técnico

Quienes dan soporte de Segundo Nivel de desarrollo a las soluciones que tienen problemas o errores
en el cliente, durante la implementación los pilotos o uso cotidiano.

Im Implement
Área de Implementación de las soluciones en el cliente.
Backend

Quien implementa y despliega las soluciones en los servidores de la nube o inside en los clientes.

FrontEnd

Los encargados de instalar configurar las aplicaciones en los clientes.

Capacitación

Encargados de capacitar a los usuarios de las aplicaciones desarrolladas e implementadas en los


clientes.

Seguimiento

Quienes están en acompañamiento del cliente viendo los resultados arrojados por la aplicación
ayudándoles a resolver problemas tomar decisiones con KAISEN, y detectando nuevos
requerimientos.

Soporte

Son los encargados de dar soporte de Primer Nivel al cliente.

Fi Financiero
Área encargada de todos los temas financieros, Presupuesto, inversiones etc.

Contador

Personal encargado de los temas contables de la compañía.

Th Talento Hum
de Recursos Humanos, Legales y de Reclutamiento.

Jefe Talento Hum

En encargado de todos los temas de contratación, retención de talento Humano legales.

Reclutador

Encargado de las entrevistas y reclutamiento de nuevos talentos.


Me Mercadeo

Área de comercialización, búsqueda de nuevos clientes y posicionamiento de los productos.

Vendedores

Encargados de buscar Clientes, agendar pilotos, nuevos proyectos y espacios para mostrar los
productos.

Objetivos estratégicos

Valores:

HONESTIDAD
- Es preferible decir “me equivoqué” a mentir y esperar que haya problemas. Reconocer los
errores que cometemos y mostrarse dispuestos a repararlos.
- Expresemos lo que sentimos o pensamos sin temor, pero con respeto.

TOLERANCIA
- Reaccionemos con calma, serenidad y firmeza frente a las agresiones.
- Antes de actuar, pongámonos en el lugar de los demás para tratar de entender sus
problemas y su manera de actuar.
- Escuchar sin interrumpir y darle a los demás la oportunidad de expresarse.
- Duro con el problema, suave con la gente.

RESPONSABILIDAD
- No comprometerse con cosas que no pueda realizar o que tengan alto riesgo de no
cumplirse. Si yo no cumplo con mis compromisos y la otra parte tampoco, no tengo cómo
reclamar.
- Antes de culpar a los demás, examinar nuestra responsabilidad y asumir las consecuencias
de nuestros actos.
- No llegar tarde a las citas y si voy a llegar tarde, es obligatorio avisar.
- Si el trabajo que estoy haciendo se ve interrumpido por alguna razón, debo avisar para que
el que está esperando los resultados conozca los inconvenientes. (No esperar a que
pregunten para avisar que no se tienen los resultados).

RESPETO
- Tratemos a los demás con la misma consideración con la que nos gustaría ser tratados.
- Si voy a regañar, reprender o amonestar a alguien, debo procurar no hacerlo en público.
- Conciliar nuestros intereses y prioridades con los intereses y prioridades de los demás.

PRUDENCIA
- Siempre pensar antes de actuar.
- No desautorizar a nuestros compañeros frente al cliente. Manejar internamente el tema
antes de hacer quedar mal a nuestros compañeros y la empresa. Lavemos la ropa sucia en
casa.
Introducción:

En el presente documentos se desarrolla una propuesta de arquitectura empresarial siguiendo el


método propuesto el framework establecido en clase por el profesor de Principios de Arquitectura
denominado Javeriana Framework el cual toma por referencia el framework de TOGAF. En este se
describe cómo lograr una arquitectura específica para la organización de manera que responda a las
necesidades del negocio, para la empresa seleccionada (EsferaTechnology).

Alcance:

Amplitud La empresa Esfera Technology es una compañía de tecnología de información que


desarrolla soluciones tecnológicas de Hardware y/o Software a terceros que pueden ser
implementados y explotados como productos a gran escala por la compañía o que alimentes las
capacidades de y generen retos tecnológicos para la compañía, También desarrolla soluciones
tecnológicas a ideas de negocio propias, con el fin de construir productos que se pueden implementar
en diferentes clientes y ofrecer como servicios.

Profundidad El nivel de detalle que se abordará será hasta el diseño de la arquitectura, no se cubrirán
detalles de implementación. Este nivel será constante para cada dominio de la arquitectura y podrá
ser estructurada para una futura adaptación o extensión.

Periodo de Tiempo Se espera que la visión de arquitectura propuesta se incorpore a la empresa de


manera gradual y se actualice de acuerdo a los cambios de las necesidades del negocio. Las mejoras
en los procedimientos del negocio se podrían empezar a adoptar durante los próximos meses. Todo
este proceso puede tomar alrededor de 5 años alineándose y apoyando la misión y objetivos de la
empresa.

Dominios de Arquitectura La propuesta de arquitectura abarcará la arquitectura del negocio, ya que


se establecerán procedimientos que permitirán mejorar los procesos seleccionados. También incluirá
la arquitectura de datos y de aplicación por medio de la propuesta del uso de software, estándares y
buenas prácticas que servirá de apoyo a los procesos del negocio. Por ello, las arquitecturas de
negocio, aplicación y datos se verán afectadas. La arquitectura de tecnología no tendrá cambios
grandes más allá de la adopción de entornos de desarrollo y pruebas y producción por este proyecto.

Visión:
El desarrollo de la arquitectura supone, en primer lugar, el compromiso de alta dirección para lleva
a cabo los objetivos. El diseño iniciará una vez el proceso de definición de arquitectura esté
terminado, y será implementado gradualmente según el mapa de ruta.

La arquitectura ir de la mano con la visión de la empresa implementados en su principal producto


SysTime para después de validar el éxito de los resultados de la arquitectura poder migrar dicha
implementación al resto de productos y servicios, así como con las recomendaciones brindadas y
que deberían responder a

- Mejorar los procesos de levantamiento y análisis de requerimientos


- Mejorar los procesos de diseño de las soluciones implementando arquitectura de soluciones
- Mejorar el desarrollo de software y hardware implementando arquitectura de software
- Mejorar los procesos de Pruebas unitarias y pruebas automatizadas
- Implementar una integración continua
- Implementar un despliegue continuo
- Mejorar los procesos de gestión mediante DevOps y metodologías agiles

Requerimientos

- Establecer buenas prácticas buenas prácticas de desarrollo, uso de estándares y políticas de


desarrollo y control de código estático
- Mejorar los procesos de Análisis, Diseño, Desarrollo, Pruebas, e Implementación de
hardware y software tomando como modelo el producto SysTime.
- Mejorar la gestión y administración de proyectos productos y servicios
- Mejorar y asegurar la calidad del desarrollo de soluciones.
- Mejorar los procesos de mantenimiento y reutilización de código fuente diseños
electrónicos y arquitecturas, generando activos para la empresa.
- Mejorar la visualización del cliente durante los procesos de producción.
- Asegurar la generación de valor agregado al cliente y a los productos de forma periódica y
rápida y efectiva
- Asegurar el camino correcto para el cumplimiento de los objetivos de la empresa
mencionado anteriormente.

Objetivos
- Una arquitectura e implementación de la misma que tenga un impacto positivo en la
empresa.
- Establecer los puntos críticos que se deben atacar y las posibles soluciones a los mismos
dentro de cada uno de los dominós de la arquitectura.
- Reducir el tiempo de respuesta ante los nuevos desarrollos.
- Reducir tiempos de repuesta bajo la demanda de SysTime, con una implementación rápida,
limpia y en paralelo a diferentes clientes.
- Definir las herramientas y procesos correctos que aporten en el alcance de la Misión de la
empresa.
- Establecer estándares y prácticas que mejoren la calidad de los productos.
- Encontrar las decisiones correctas de negocio para fortalecer y hacer crecer la empresa.
- Mejorar la satisfacción y expectativas de todos los interesados.
- Llegar al punto de equilibrio de forma rápida y generar ingresos que den oportunidad de
crecimiento y rentabilidad del negocio.

Metas a Lograr
Implementación rápida limpia y eficiente en los clientes que están demandado SysTime y
en este momento no han podido ser atendidos, así como disminuir los tiempos de
producción.
Actores Humanos
- Personal de levantamiento de requerimientos, implementación y
acompañamientos.
- Personal de producción como analistas, diseñadores, desarrolladores.
- Personal de Marketing y ventas
Actores Informáticos
- Aplicación UWP SysTime
- Sistema de Posicionamiento en tiempo real Rtls
- Servidor (BD, Servicios) que se encargan de conectar todo el ecosistema
- Conectores quienes se encargan de comunicar SysTime con los Erps de cada
Concesionario.

BENEFICIOS TANGIBLES

- Maximizar la capacidad de atención de proyectos.


- Reducir los tiempos muertos del personal.
- Reducción de los costos generados en la ejecución de los proyectos.
- Reducción de la diferencia entre el tiempo estimado y tempo real de ejecución de los
proyectos de software.

BENEFICIOS INTANGIBLES

- Mejorar la ejecución del proceso de delivery y gestión de recursos.


- Mejorar la calidad de la información y su confiabilidad.
- Mejorar el seguimiento y control del avance de los proyectos.
- Permitir un acceso más rápido a la información, para así, poder tomar decisiones oportunas.
- Lograr la satisfacción los clientes por los servicios brindados.
Fase Preliminar

PRINCIPIOS DE ARQUITECTURA

Acá se quiere detallar los principios de la arquitectura a la EsferaTechnology se adhiere. Su propósito


es definir los principios de la arquitectura para los cuatro dominios de la arquitectura: negocio,
aplicaciones, datos y tecnología; con el objetivo de informar y dar soporte a la forma en que la
organización se ajusta sobre el cumplimiento de su misión. Estos principios son enunciados según
la plantilla sugerida por TOGAF.

Dominio de Negocio Domino de Aplicaiones / Dominio de Información / Principios de Infraestructura


Integraciones Datos Técnica
Seguimiento de estándares y políticas Aplicaciones fáciles de usar Seguridad de la información Tecnología madura

Convergencia con la arquitectura empresarial Seguimiento de estándares Información accesible Infraestructura escalable

Alineación entre TI y el negocio Homogeneidad de la tecnología Copia de seguridad de datos Seguimiento de auditoría

Enfoque en el cliente Reutilización y simplicidad Información relevante Reevaluar la seguridad

Principios de Negocio

Nombre Seguimiento de estándares y políticas

Referencia BP01

Los estándares, Herramientas y políticas mínimos para el desarrollo de software y procesos de calidad
Declaración que beneficien los productos finales.

Razón Se mejorará la gestión y procesos de todo el ciclo de vida del software, facilitando estandarizando y
fundamental mejorando los procesos y como resultado generando un producto con alto valor para el cliente.

Se deberán tener mejores procesos de gestión, análisis de requerimiento, diseño y arquitectura,


programación, pruebas, y Mantenimiento, del software, estandarización de procesos, implementación
Trascendencia de patrones, estándares, técnicas en todos los procesos de ALM, escoger las herramientas correctas que
nos ayuden en todo el proceso.
Nombre Convergencia con la arquitectura empresarial

Referencia BP02

La convergencia asegurara un camino o RoadMap que siempre esté alineado a la visión y objetivos de
Declaración la empresa en nuestros productos, ante nuestros clientes y en el sector.

Se debe garantizar un buen diseño y arquitectura empresarial que establezca una dirección siempre
Razón
alineada a la misión y objetivos de la empresa, así como las estrategias de gestión y procesos que
fundamental garanticen que dicha arquitectura se implemente a través del tiempo.

No solo se debe mejorar y establecer un buen proceso de arquitectura empresarial, deberemos


establecer ppolíticas responsabilidades y dedicar recursos para garantizar su buena implementación,
Trascendencia entendimiento y ejecución, así como las capacidades suficientes para reaccionar a nuevos
requerimientos, adaptando la arquitectura para soportar los cambios e imprevisto que puedan suceder
en el sector o sobre nuestros clientes.

Nombre Alineación entre TI y el negocio

Referencia BP03

Declaración Cada proyecto de TI debe estar alineado con los objetivos del negocio y la estrategia.

Razón Este principio permite que la tecnología cambie según las necesidades de la empresa. De esta manera
fundamental se asegura que los cambios propuestos sirvan como soporte de las operaciones del negocio.

Solo se financiarán cambios o mejoras en los sistemas cuando esté justificado por una necesidad del
Trascendencia negocio. Se revisarán los cambios propuestos en los sistemas bajo el contexto de los objetivos del
negocio.

Nombre Enfoque en el cliente

Referencia BP04

Declaración Las decisiones arquitectónicas buscarán maximizar el valor para el cliente.

Razón
Las decisiones arquitectónicas buscarán maximizar el valor para el cliente.
fundamental

Se revisarán los requerimientos de manera que estén acorde a lo que el usuario espera. Se dedicarán
Trascendencia más esfuerzos en el control de calidad.
Principios de Aplicaiones/
Integraciones
Nombre Aplicaciones fáciles de usar

Referencia AP01

Declaración Las interfaces de usuario deberán ser fáciles de usar e intuitivas.

Razón Este principio ayuda a que el usuario realice sus tareas con un menor esfuerzo. Se reduce el esfuerzo
fundamental necesario en capacitar al usuario. Las tareas se realizan de forma más sencilla y rápida.

Se deberá invertir un mayor esfuerzo al momento de diseñar las aplicaciones a fin de que las tareas que
Trascendencia ejecuten sean más simples de realizar por el usuario.

Nombre Seguimiento de estándares

Referencia AP02

Las aplicaciones deberán cumplir con los estándares establecidos, convenciones, acuerdos, procesos,
Declaración prácticas y métodos.

Razón Este principio permite que el código y la estructura de las aplicaciones sea ordenado, fácil entender y
fundamental de mantener.

Se deberá revisar los estándares de programación existentes y hacer las modificaciones necesarias . Se
Trascendencia deberá capacitar al equipo de desarrollo para que adopten los estándares establecidos.

Nombre Homogeneidad de la tecnología

Referencia AP03

Declaración Las aplicaciones deben soportan estándares de las tecnologías usadas.

Razón Este principio fomenta que las aplicaciones sean construidas con tecnologías conocidas dentro de la
fundamental organización. Hay una disminución en la curva de aprendizaje y los costos son menores.

Las aplicaciones que solo funcionen con un fabricante en particular deberán ser migradas hacia el uso
Trascendencia de software libre.
Nombre Reutilización y simplicidad

Referencia AP04

Declaración Las aplicaciones serán diseñadas para maximizar la reutilización en toda la empresa .

Ayuda a reducir el esfuerzo en la construcción de software con la reutilización de librerías compartidas


Razón con varias aplicaciones. Se usan componentes que ya han sido probados y por lo tanto tienen menor
fundamental probabilidad de error. Evita que no se repita el código de las aplicaciones y asegura que la lógica este
en un solo lugar al momento de darle mantenimiento. Reduciendo el tiempo de desarrollo.

Se deberá revisar el código fuente de las aplicaciones e identificar la duplicidad de código. Se deberá
Trascendencia diseñar componentes reutilizables y hacer cambios en las aplicaciones para que estas los utilicen.

Principios de
Información / Datos

Nombre Seguridad de la información

Referencia DP01

Declaración Los datos son un activo que debe ser protegido.

Razón Este principio permitirá que la información, que es valiosa para el negocio, solo pueda ser accedida por
fundamental personas autorizadas.

Se deberá revisar la configuración de seguridad de las aplicaciones para identificar alguna


Trascendencia vulnerabilidad que deba ser corregida.
Nombre Información accesible

Referencia DP02

Declaración La información debe estar abierta y disponible para apoyar la productividad y la innovación.

Razón
Este principio permite tener acceso a la información a fin de poder tomar decisiones de manera optima.
fundamental

Se revisará los accesos de los usuarios a las aplicaciones y se les dará acceso a toda información que le
Trascendencia sea útil en sus tareas.

Nombre Copia de seguridad de datos

Referencia DP03

Declaración Todos los datos tendrán una copia de respaldado.

Razón Este principio garantiza que la información se mantenga a salvo en caso de algún error, ataque
fundamental informático o desastre.

Se deberá implementar rutinas de creación de copias de seguridad de la información registrada en la


Trascendencia base de datos. Se deberá gestionar la adquisición de servidores para mantener la información de
respaldo.

Nombre Información relevante

Referencia BP04

Declaración Los datos deben ser relevantes al negocio y tener un valor.

Razón Este principio evita los costos innecesarios que conlleva mantener información que no tiene valor para
fundamental el negocio. Se tendrá un modelo de datos más simple y fácil del mantener.

Se deberá revisar la base de datos con la finalidad de identificar atributos que no sean útiles o ya no
Trascendencia utilicen para eliminarlos. Se revisarán aplicaciones que utilicen esa información eliminada y se harán
los cambios necesarios para que no se vean afectadas.
Principios de
Infraestructura Técnica
Nombre Tecnología madura

Referencia IP01

Las tecnologías de experimentales o tempranas no se utilizarán a menos que sean críticos para la
Declaración ventaja competitiva.

Razón Este principio mitiga el riesgo que puede implicar adquirir tecnología que aun no se encuentra en un
fundamental etapa madura. Las tecnologías probadas tienen la ventaja de contar con soporte en casos de error.

Se deberá identificar las aplicaciones que se basen en nuevas tecnologías y migrarlas a otras que ya
Trascendencia hayan alcanzado madurez en el mercado.

Nombre Infraestructura escalable

Referencia IP02

Declaración La infraestructura debe ser capaz de ampliar mediante la adición de dispositivos .

Razón Este principio permite que los sistemas se puedan construir de manera que se pueda adaptar a los
fundamental cambios que se puedan presentar en un futuro. El sistema podrá crecer según sea necesario.

Se deberá revisar las aplicaciones y hacer cambios de manera que su rendimiento crezca de manera
Trascendencia proporcional al incremento de la capacidad del hardware.

Nombre Seguimiento de auditoría

Referencia IP03

Declaración Todas las acciones del usuario y del sistema significativo deben dejar un rastro de auditoría.

Este principio permitirá que se tenga un seguimiento de las acciones de los usuarios a fin de detectar
Razón
algún comportamiento que pueda afectar la integridad de la información. Esto permitirá a la vez dar
fundamental con el origen de los defectos que de otra manera sería más difícil de encontrar.

Se revisará el uso de log en el sistema. Se revisará el uso de campo de auditoria en las tablas de la base
Trascendencia de datos.
Nombre Reevaluar la seguridad

Referencia IP04

Declaración La seguridad no es una actividad de una sola vez debe ser reevaluado periódicamente .

Razón Este principio ayuda a mantener de forma constante la seguridad debido a que siempre pueden aparecer
fundamental nuevas amenazas.

Trascendencia Se deberán revisar, modificar y evaluar los aspectos de la seguridad de manera continua.
SOLICITUD DE TRABAJO DE ARQUITECTURA

Esta sección es la petición de trabajo de arquitectura para el proyecto de propuesta de la


arquitectura empresarial del modelo de delivery. Su propósito es describir un plan de como las
soluciones serán abordadas a través del proceso de arquitectura.
Limitaciones financieras La organización es una compañía multinacional que cuenta con una solida
condición financiera. Anualmente se asigna un presupuesto a HPE Perú para llevar a cabo los
proyectos y lograr los objetivos establecidos.
59

Descripción de la situación actual del negocio

La empresa intenta llevar un proceso enmarcado en un framework Ágil con SCRUM el cual han ido
adaptando a sus necesidades por lo cual el proceso de gestión es el proceso principal y consta de
cuatro subprocesos, los cuales se describen a continuación:

Proceso de estimación
Se encarga de estimar el tiempo y los recursos necesarios para llevar a cabo un requerimiento o
proyecto de software. Se inicia cuando el cliente solicita la estimación. Se estima la cantidad de los
recursos, los roles necesarios y el tiempo de ejecución. Finaliza cuando el cliente recibe el
documento de estimación.

Proceso de ejecución
Comprende la planificación y ejecución del proyecto de software. Se inicia cuando el cliente solicita
la ejecución. Se realiza la planificación y ejecución. Finaliza cuando se entrega al cliente el software
y la documentación correspondiente.

Dentro de este proceso se implementan los Sprints que constan de los Sprint Planning donde se
estableces que PBIs son seleccionados para ejecutar y se establecen las tareas por desarrollador
para cada siguiente Sprint, la Implementación donde los desarrollador crean las nuevas
funcionalidades se testean, documentan en código, todo bajo un control de versiones, El Sprint
Review donde entregan y revisan los resultados con el Product Owner, y Nuevamente se entra en
un Sprint Planing.

Proceso de soporte
Se encarga de corrección de defectos en las aplicaciones. Se inicia cuando el cliente solicita la
corrección de defectos. Se corrigen defectos encontrados. Finaliza cuando se entrega al cliente la
aplicación corregida.

Proceso de Acompañamiento
Es donde se acompaña al cliente revisando resultados analizando estrategias detectando errores y
analizando nuevos requerimientos que ayuden a mejorar los procesos los resultados y los KPIs.

Los principales problemas encontrados son:


- La técnica utilizada para realizar la estimación es el juicio del desarrollador. La desventaja
de este método es que muchas veces el tiempo estimado difiera del tiempo real, lo que
puede ocasionar malestar en el cliente ya que no se cumple con las fechas establecidas.
- Aunque tratan de seguir un framework como Scrum los han adaptado tanto a lo que
creyeron que eran sus necesidades que algunas etapas o lineamientos no son seguidos de
forma correcta, como los Daily (Revisiones diarias), los Sprints no se están ejecutando en los
tiempos correctos alargándolos o acortándolos según las dificultades, no se están esta
ejecutando la retrospectiva correctamente, de manera que se retroalimente ni revisando
las prioridades en el ProductBackLog (Lista de deseos), no se está cumpliendo con el
Definición of Done, lo que hace que algunos terminan la tarea pero no queda bien
documentada ni testeada, generando errores en producción, entre otros.
- En el proceso de ejecución se ha encontrado que con frecuencia no se hace un análisis
detallado de los procesos impactados, lo que se ve reflejado en la calidad del entregable ya
que este de esta con errores.
- No se estable un proceso de integración continua que ayude a mejorar los tiempos y
minimizar los Errores.
- No se implementa un proceso de despliegue continuo generando muchas demoras,
problemas y errores a la hora de llevar los desarrollos a los clientes, agotando los pocos
recursos de Implementación.
- En el proceso de soporte, como generalmente es la última fase de en un proyecto, muchos
de los recursos empiezan a ser asignados a otros proyectos o requerimientos, lo que deja
este proceso con poca capacidad de respuesta en caso de que se presenten muchos
defectos por resolver.
- Los pocos recursos como desarrolladores o personal calificado en ciertas tareas hacen que
pocos hagan las tareas de muchos, y al no ser especializados siempre están bajo curvas de
aprendizaje prueba y error.

Descripción de la situación actual de la arquitectura TI

Las aplicaciones que actualmente se utilizan para dar soporte a los procesos de la fábrica de
software son las siguientes:

Visual Studio Online En algún momento gestionaban los PBIs mediante esta herramienta y el avance
de las tareas con un tablero canvas, pero en algún momento desistieron de usarlo para llevar una
gestión con Poptsis,

Excel para el registro de algunas tareas cronogramas.

TFS para el control de versionamiento de código.

IDES para el desarrollo de software como (Visual Studio, Android Studio, Micro C entre otros).

Los principales problemas encontrados son los siguientes:


- El principal problema es que la información de los procesos relacionados está aislada y por
ello es difícil saber de forma rápida el avance de cada recurso y si se está cumpliendo con lo
planificado.
- No existe una aplicación para el registro de la información del conocimiento técnico y
habilidades de los recursos.
- Dejar de usar una herramienta para la gestión de los PBIs lo cual trajo algunos beneficios en
la visibilidad de las tareas, pero perjudico al no continuar con un listado de ProductBakLog
y un históricos de la ejecución ni medición de tiempos.
- Excel funciono bien hasta cierto número de clientes, pero es un problema ya que les es muy
difícil ahora gestionar los compromisos y las entregas.
- No hay una persona especializada en el control de versiones y uso de la herramienta TFS.
- No usan herramienta de Devops.
- No se está usando ninguna herramienta para la Integración continua.
- No se está usando ninguna herramienta para el despliegue continuo.
VISION DE LA ARQUITECTURA

DECLARACIÓN DE TRABAJO DE ARQUITECTURA

Solicitud de proyecto de arquitectura y antecedentes Se presenta la siguiente solicitud de proyecto


de arquitectura para mejorar la arquitectura de empresarial de la EsferaTechnology enfocados en
el desarrollo de productos nuevos y el producto SysTime.

La fábrica de software entró en operación en el 2011. Durante este tiempo se ha definido un modelo
de trabajo cuyo proceso principal es el desarrollo de funcionalidades y la búsqueda de un equilibrio
en el producto SysTime. Actualmente, sus clientes principales son los concesionarios de vehículos.
En este tiempo se ha ido incrementando la cantidad de clientes que empezó con un solo taller que
se prestó para piloto y el desarrollo de la aplicación, por lo tanto, y no estamos pudiendo atender la
demanda y el proceso de implementación es muy lento no solo haciendo que la cola de clientes en
espera crezca si no que aumenta el tiempo de espera, por lo que los procedimientos adoptados en
un principio no son los más óptimos. Por ello, se solicita el presente proyecto de arquitectura cuyo
objetivo es de optimizar los procesos de delivery y gestión de recursos, con el propósito de dar un
mejor servicio al cliente, mejorar la capacidad de atención de los clientes en cola de espera los
requerimientos demandados, lograr el punto de equilibrio en el menor tiempo posible y asegurar el
cumplimiento de los objetivos establecidos por la empresa.

Descripción del proyecto de arquitectura y alcance El presente proyecto de arquitectura es una


propuesta de arquitectura empresarial para la fábrica de software de la empresa Hewlett Packard
Enterprise. En esta se abordará los procesos de delivery y gestión de recursos.
Procedimientos específicos para cambios de alcance

El procedimiento para el control de cambios se realizará de la siguiente manera:

Mapa de procesos

Planificación Mejora
estratégica Continua
Requerimientos del cliente, o del producto Nuevo

Satisfacción del Cliente

Delivery Testing Release Managment

Gestión de Recursos

Gestión Gestión de Gestión Gestión


Financiera Proveedores de Personal de Venta
Flujo de procesos

Roles, responsabilidades y entregables

En la siguiente matriz se muestra la relación entre los entregables y los roles que intervienen en el
proyecto:
Responsables Rol Arquitecto de Aplicaciones

Arquitecto de Tecnología
Arquitecto de Negocio

Arquitecto de Datos
Project Manager

Arquitecto Líder

Principios de Arquitectura I R C C C C
Solicitud de Arquitectura I R
Declaración de Arquitectura I R
Visión de la Arquitectura I R C C C C
Documento de Definición

Arquitecto de Negocio I A R
Arquitectura de Aplicación I A R
Arquitectura de Datos I A R
Arquitectura de Tecnología I A R
Plan de Implementación y Migración I R C C C C

R Responsable A Aprovador C Consultar I Informar


Criterios de aceptación

Los criterios de aceptación de los entregables antes mencionados son los siguientes:

- Se debe garantizar que exista trazabilidad entre los elementos considerados,


actividades, clases, etc., contra los principios de arquitectura definidos, los cuales a
su vez deberán estar alineados con los objetivos estratégicos de la organización.
- Desarrollar las secciones obligatorias de los documentos propuestos según el marco
de trabajo de Javeriana.
- Cumplir con las fechas establecidas por el Profesor de Principios de Arquitectura

Los entregables deben contener:

- Por lo menos un diagrama para cada uno de los dominios como se menciona a
continuación.

- Dominio de Negocio
Organizacional
Capa -> Organigrama
Procesos -> Diagrama de procesos

- Dominio de Datos
Estructura de la información
Comportamiento

- Dominio de Aplicaciones
Estructura
Comportamiento

- Dominio de Tecnología
Estructura
Comportamiento

- Diagrama de Capas integrando los 4 dominios


- Análisis de Brechas por cada dominio
- Mapa de ruta por cada dominio
Cronograma tentativo
VISIÓN DE ARQUITECTURA

Interesados y sus preocupaciones


El principal interesado es JOHAN BAYONA CAMARGO, actual CTO, debido a que es la persona a
cargo de la gestión de los procesos tecnológicos y líder de desarrollo.

Su preocupación principal es resolver los problemas identificados en el proceso, así como


optimizar los mismos a fin de que se realicen de mejor manera posible.
ARQUITECTURAS (AS IS / TO BE)

DOCUMENTO DE DEFINICIÓN DE ARQUITECTURA

Alcance
El alcance del presente proyecto abarcará los cuatro dominios de la arquitectura:

Arquitectura de Negocios, la cual se define la estructura de la organización, el mapa de procesos y


los procesos claves para la organización objetivo.

Arquitectura de Datos, la cual describe la estructura de los datos lógicos en la organización.

Arquitectura de Aplicaciones, la cual describe los componentes y el panorama de aplicaciones.

Arquitectura Tecnológica, la cual describe la estructura física de los componentes el esquema de


hardware y redes.

Los procesos que se abarcarán en este análisis serán los que intervienen en la producción de
software, desde el análisis, diseño, desarrollo, implementación enfocados en el producto SysTime y
los nuevos desarrollos.

Metas, objetivos

- Mejorar los procesos de levantamiento y análisis de requerimientos


- Mejorar los procesos de diseño de las soluciones implementando arquitectura de soluciones
- Mejorar el desarrollo de software y hardware implementando arquitectura de software
- Mejorar los procesos de Pruebas unitarias y pruebas automatizadas
- Implementar una integración continua
- Implementar un despliegue continuo
- Mejorar los procesos de gestión mediante DevOps y metodologías agiles

Limitaciones

- Limitación de tiempo para el desarrollo de la arquitectura ya que tiene que cumplirse en los
tiempos establecidos en el semestre por el profesor de principios de arquitectura que se
detallan en el cronograma de actividades y que se establecen en cuatro semanas.
- Limitación de recursos ya que el grupo para el desarrollo de la arquitectura está compuesto
por dos personas Johan Bayona y Leonardo Garcia quienes tienen que ejecutar los diferentes
roles que se establecieron en el diagrama RACI.
- Esfera Technology es una empresa pequeña y muy nueva, por lo cual no tiene establecido
ni documentado ninguno de los recursos que son necesarios para el desarrollo correcto de
la arquitectura obligándonos a tener que construir desde cero algunos todos los recursos
como la visión, misión, objetivos, estrategias entre muchos otros.
- Limitación de recursos en cuanto a personal de la empresa ya que son pocas personas
ejecutando muchos roles los cual no limita al momento de establecer el TO-BE ya que no
contamos con el suficiente talento Humano ni los recursos económicos para nuevas
contrataciones.
Principios de arquitectura

Después de un análisis y revisan del cronograma y metas y limitaciones se decidió acortar los
principios que no aportaban al proceso de arquitectura o que de una u otra forma interferían o
expandían el proceso y los recursos para poder finalizar el proceso correcto de llevar a término la
definición de la arquitectura.

Y los principios por cada dominio quedaron de la siguiente manera.

Dominio de Negocio Domino de Aplicaiones / Dominio de Información / Principios de Infraestructura


Integraciones Datos Técnica
Seguimiento de estándares y políticas Seguimiento de estándares Información accesible Tecnología madura

Convergencia con la arquitectura empresarial Información relevante Infraestructura escalable

Principios de Negocio

Nombre Seguimiento de estándares y políticas

Referencia BP01

Los estándares, Herramientas y políticas mínimos para el desarrollo de software y procesos de calidad
Declaración que beneficien los productos finales.

Razón Se mejorará la gestión y procesos de todo el ciclo de vida del software, facilitando estandarizando y
fundamental mejorando los procesos y como resultado generando un producto con alto valor para el cliente.

Se deberán tener mejores procesos de gestión, análisis de requerimiento, diseño y arquitectura,


programación, pruebas, y Mantenimiento, del software, estandarización de procesos, implementación
Trascendencia de patrones, estándares, técnicas en todos los procesos de ALM, escoger las herramientas correctas que
nos ayuden en todo el proceso.
Nombre Convergencia con la arquitectura empresarial

Referencia BP02

La convergencia asegurara un camino o RoadMap que siempre esté alineado a la visión y objetivos de
Declaración la empresa en nuestros productos, ante nuestros clientes y en el sector.

Se debe garantizar un buen diseño y arquitectura empresarial que establezca una dirección siempre
Razón
alineada a la misión y objetivos de la empresa, así como las estrategias de gestión y procesos que
fundamental garanticen que dicha arquitectura se implemente a través del tiempo.

No solo se debe mejorar y establecer un buen proceso de arquitectura empresarial, deberemos


establecer ppolíticas responsabilidades y dedicar recursos para garantizar su buena implementación,
Trascendencia entendimiento y ejecución, así como las capacidades suficientes para reaccionar a nuevos
requerimientos, adaptando la arquitectura para soportar los cambios e imprevisto que puedan suceder
en el sector o sobre nuestros clientes.

Principios de Aplicaiones/
Integraciones

Nombre Seguimiento de estándares

Referencia AP02

Las aplicaciones deberán cumplir con los estándares establecidos, convenciones, acuerdos, procesos,
Declaración prácticas y métodos.

Razón Este principio permite que el código y la estructura de las aplicaciones sea ordenado, fácil entender y
fundamental de mantener.

Se deberá revisar los estándares de programación existentes y hacer las modificaciones necesarias . Se
Trascendencia deberá capacitar al equipo de desarrollo para que adopten los estándares establecidos.
Principios de
Información / Datos

Nombre Información accesible

Referencia DP02

Declaración La información debe estar abierta y disponible para apoyar la productividad y la innovación.

Razón
Este principio permite tener acceso a la información a fin de poder tomar decisiones de manera optima.
fundamental

Se revisará los accesos de los usuarios a las aplicaciones y se les dará acceso a toda información que le
Trascendencia sea útil en sus tareas.

Nombre Información relevante

Referencia BP04

Declaración Los datos deben ser relevantes al negocio y tener un valor.

Razón Este principio evita los costos innecesarios que conlleva mantener información que no tiene valor para
fundamental el negocio. Se tendrá un modelo de datos más simple y fácil del mantener.

Se deberá revisar la base de datos con la finalidad de identificar atributos que no sean útiles o ya no
Trascendencia utilicen para eliminarlos. Se revisarán aplicaciones que utilicen esa información eliminada y se harán
los cambios necesarios para que no se vean afectadas.
Principios de
Infraestructura Técnica

Nombre Tecnología madura

Referencia IP01

Las tecnologías de experimentales o tempranas no se utilizarán a menos que sean críticos para la
Declaración ventaja competitiva.

Razón Este principio mitiga el riesgo que puede implicar adquirir tecnología que aun no se encuentra en un
fundamental etapa madura. Las tecnologías probadas tienen la ventaja de contar con soporte en casos de error.

Se deberá identificar las aplicaciones que se basen en nuevas tecnologías y migrarlas a otras que ya
Trascendencia hayan alcanzado madurez en el mercado.

Nombre Infraestructura escalable

Referencia IP02

Declaración La infraestructura debe ser capaz de ampliar mediante la adición de dispositivos .

Razón Este principio permite que los sistemas se puedan construir de manera que se pueda adaptar a los
fundamental cambios que se puedan presentar en un futuro. El sistema podrá crecer según sea necesario.

Se deberá revisar las aplicaciones y hacer cambios de manera que su rendimiento crezca de manera
Trascendencia proporcional al incremento de la capacidad del hardware.
Arquitectura de línea base
Arquitectura del negocio

Estructura de la Organización
Para el organigrama no se atacaron las zonas que se muestran en gris solo se atacó la zona de
producción que se ve en color.
Junta de Socios

CEO

CTO CFO

Id I+D Di Diseño De Desarrollo Im Implement Fi Financiero Th Talento Hum Me Mercadeo

Hardware Analista Requeri Desarroll Backend Tec de Instalación Contador Jefe Talento Hum Vendedores

Software Arquitecto Softw Desarroll FrontEnd Soporte Nivel 1 Reclutador

Diseñador Gráfico Desarr Electrónico Soporte técn Niv 2

Diseño Electrónico DBA Exp en Kaisen

Tester Capacitación

Config Managment

Junta de Socios

Junta de socios de la compañía compuesta por 3 Socios, con una distribución de las sociedades
establecidas mayoritariamente por el socio #1 EsferaColor, y en partes iguales para el socio #2 Juan
Manuel Gutiérrez y el socio #3 Johan Agustín Bayona Camargo, son los encargados de las decisiones
importantes en términos de la compañía, las estrategias, inversiones y presupuestos a los proyectos.

CEO
El CEO (Chief Executive Officer) es el encargado de los temas de negocios, relaciones con los clientes
en gran parte del marketing y la penetración que tiene la empresa en el mercado

CTO
El CTO (Chief Technology Officer) quien se encarga de todos los procesos tecnológicos de la empresa
y a la vez actúa como arquitecto y líder de desarrollo de los proyectos,

Área de Investigación y Desarrollos, esta es usada cuando los proyectos requieren resolver
problemas no comunes y desarrollar nuevas tecnologías, como fue el caso del Rtls para SysTime.

Hardware

Todos los temas de Investigación y desarrollo de dispositivos electrónicos.


Software

Todo lo relacionado a nuevas herramientas técnicas o soluciones de software.

Di Diseño
Área de Diseño de soluciones o productos que se encargan de establecer qué y cómo se
desarrollaran los proyectos o productos.

Analista Requeri

Es la persona encargada de analizar el problema a solucionar analizar en el entorno y hacer un


levantamiento de Historias. Y convertir este en requerimientos y un listado de PBIs, así como de las
pruebas de las nuevas funcionalidades desarrolladas

Arquitecto Softw

Es el encargado de plantear y diseñar la solución en términos tecnológicos para el Software.

Diseñador Gráfico

Quien se encarga de establecer la UI y UX de la solución.

Diseño Electrónico

Quien diseña las soluciones electrónicas de componentes, tecnologías además del diseño de
circuitos electrónicos PCBs, gestionar los insumos de componentes y envía a fabricación y ensamble
que se realiza con terceros.

De Desarrollo
Área de Desarrollo de Producto, codificación de software.

Desarroll Backend

Programador de Backend, servicios o lógica de negocio que corre en los servidores inside o en la
nube.

Desarroll FrontEnd

Programador encargado de desarrollar los clientes (Windows, Android, iOS) y conectarse a los
servicios establecidos en el Backend.

Desarr Electrónico
Programador de microcontroladores, drivers de conexión, dispositivos embebidos entre otros.
DBA

Encargado de diseñar y desarrollar y mantener las Bases de Datos.

Tester

Es el rol que prueba todos los desarrollos y/o productos para aprobar las nuevas funcionalidades
antes de ser implementadas o pasadas a producción.

Config Managment

Encargado de los temas de infraestructura redes ambientes de producción aplicaciones, todo lo que
tiene que ver con mantener la operación en términos de infraestructura y aplicaciones.

dan soporte de Segundo Nivel de desarrollo a las soluciones que tienen problemas o errores en el
cliente, durante la implementación los pilotos o uso cotidiano.

Im Implement
Área de Implementación de las soluciones en el cliente.

Tec de Instalación

Quien se encarga de instalar redes configurar equipos y dar soporte a la instalación de Servicios
Servidores y aplicaciones Cliente.

Capacitación

Encargados de capacitar a los usuarios de las aplicaciones desarrolladas e implementadas en los


clientes.

Exp en Kaisen

Quienes están en acompañamiento del cliente viendo los resultados arrojados por la aplicación
ayudándoles a resolver problemas tomar decisiones con KAISEN, y detectando nuevos
requerimientos.

Soporte Nivel 1

Son los encargados de dar soporte de Primer Nivel 1 al cliente.

Soporte técn Niv 2

Son los encargados de dar soporte de Primer Nivel 2 al cliente.


Mapa de Proceso de Negocios

En el mapa de procesos de negocios se modificó la zona de productivos dejando las zonas marcadas
en gris intactas.

Planificación Mejora
estratégica Continua
Requerimientos del cliente, o del producto Nuevo

Satisfacción del Cliente


Acompañamiento,
Marketing y ventas Logística de entrada Operaciones Logística de salida mantenimiento y
mejoras

Gestión de Recursos

Gestión Gestión de Gestión Gestión


Financiera Proveedores de Personal de Venta

Cadena de Valor
Se construyó desde cero ya que no se tenía identificada ni documentada. Are de contabilidad, temas legales,
administración de recursos, gestión
de talento humano entre otros, que
se encargan de todos los temas
operativos que no tiene que ver con
Contabilidad y Recursos Humanos el Core del negocio pero que son
necesarios para operar y funcionar
I + D investigación de tecnologías Investigación y Desarrollo correctamente
nuevas para el desarrollo de
soluciones no comunes a
problemas de nuestros clientes o
de nuevos productos
Acompañamiento,
Marketing y ventas Logistica de Entrada Operaciones Logistica de salida
mantenimiento y mejoras

Fortalecer la comunicación y Como punto de partida existe una Gestión de proyectos para Producto o solución (Hardware y/o Capacitación a los usuarios en el
satisfacción del cliente. solicitud inicial para el desarrollo de planificar, realizar seguimiento, Software) construidos a partir de correcto uso de los productos o
una solución a un problema control y cierre a los proyectos. los requerimientos validado con el servicios.
Búsqueda de nuevos posibles mediante tecnología (Hardware y/o cliente e implementado y
clientes nuestros productos. Software, teniendo como entrada Análisis de los requerimiento para funcionando, que dé solución a las Proceso en el que se acompaña a
los requerimientos definidos por el entender los requerimientos preocupaciones y aporte valor al cliente en la adopción y uso
Visitas y demostración del Cliente.) funcionales y del sistema, por todo cliente. correcto de la solución, validación
funcionamiento de nuestros el equipo de desarrollo. de los resultados y corrección de
productos y servicios, (demos, Para el Hardware la solicitud Implementación de la solución posibles errores.
pilotos etc.). gestión y administración de los Diseño y arquitectura donde en (Instalación, despliegue y puesta a
componentes electrónicos base a los requerimientos se punto) de equipos, software y Periódicamente se acompaña al
necesarios en la producción elaboran la arquitectura y diseños servicios en cada uno de nuestros cliente para evaluar los datos
necesarios para la solución. clientes. arrojados por la solución,
Compra y administración de ayudándoles en la toma de
equipos de electrónica y de Codificación del software, aplicando decisiones para mejorar sus
computo necesarios en la estándares de programación y procesos, así como detectando
implementación en nuestros mejores prácticas definidas por la nuevos requerimientos o cambios
clientes (Tvs, Tablets, empresa. sobre la solución que puedan
Computadores etc). aportar nuevas herramientas,
Verificación y control de calidad del garantizando una mejora continua
producto y validaciones con el sobre el producto.
cliente.
Roles del negocio:

Matriz RACI Para poder mostrar la responsabilidad que asume cada área de la organización contra
los objetivos del negocio, se desarrolla una matriz RACI, para asegurar que cada uno de los procesos
mapeados.

Matriz de procesos contra roles:

Responsables Rol

Analista de Requerimien
CTO o Líder de Proyecto

Arquitecto de Software

Ing. De Mant y soporte


Diseñador Gráfico

Téc de Instalación
Desarrolladores

Testers
Gestión de proyecto A I I I I I I I
Requerimientos A R
Diseño A R R
Desarrollo A R I
Pruebas A I I R I
Despliege A I R I
Soporte I I R

R Responsable A Aprovador C Consultar I Informar

Skill Recurso

Servicio Proyecto Área

Gestión de recursos Dicisión del negocio

Modelo de datos del proceso de gestión de recursos


Diagrama de gestión de nuevas solicitudes de servicio

Diagrama de proceso de desarrollo de una solución


Arquitectura de Datos

Modelo de Datos

Cliente

CP IdCliente

Nombre

Descripción

&
&
Proyecto

CP IdProyecto
Propuesta Proyecto_Recurso_R
FK IdFase ol Rol
CP IdPropuesta
FK IdEstado CE IdProyecto CP IdRol
1 1

&

&
1

&
Nombre
Nombre FK IdRecurso NombreRol
Descripcion
Descripcion FK IdRol Descripcion
&

&
Avance

Precio

Recurso
1
&

CP IdRecurso

Nombre

1
&

Perfil

CP IdPerfil

NombrePerfl

Descripcion

Diagrama lógico de Gestión

Equipo
1
1
CP ID

FK IdProyecto
Skateholder ProductOwner Proyectos EquipoImplicado
1 1 1
&

NombreEquipo
CP ID CP ID CP ID CE IdEquipo
&

FechaCreacion
Nombre Empresa Proyecto FK IdImplicado
Area
Apellido NIT Descripcion
Especialidad Persona
Empresa NombreContacto FK IdProductOwner BackLog
1
&

Observaciones CP ID
1
&

FK IdProductOwner ApellidoContacto FK IdProyectoImplicado CP ID


1 Nombre
Correo Email Fecha de Inicio FK IdProyecto
&

Apellido
Telefono Dirección Costo HistoriaCorta
Sprint Cargo
Observaciones Ciudad Notas Enunciado
1
CP ID 1 Especialidad
Telefono TipoProyectp
&

Estado
FK IdBackLog FK IdEquipo
Observaciones FrchaEntrega Prioridad TareasSprint
&

Tarea e-mail
CP ID
FechaIngreso
&

Estado
FK IdSprint
Responsable Observaciones
Tarea
Implicados Valoracion
Nombre
Fechainicio
Descripción
DeilyScrum FechaFin
FK IdResponsable
&

CP ID Objetivo
Horas
Hora ScrumDeScrum SprintReviewMeeting
FechaInico
Participantes CP ID CP ID
&

FechaFin
&

Preguntas FK IdSprint FK IdSprint


Dificultad
&

FK IdSprint Fecha Fecha


Observaciones
Fecha Hora Hora

Hora Lugar Lugar

Lugar Observaciones Observaciones

Duracion ProblemaDetectado ProblemaDetectdo

Diagrama lógico del Scrum


Arquitectura de aplicación

Listado de aplicaciones:

Herramienta de ofimática para cronogramas documentos etc. (Word, Power Point, Excel)
Motores de Bases de Datos (SqLite, SqlServer, Oracle)
Herramientas de Gestión (Visual Studio Online, Excel, Trello)
Herramientas de Software IDEs para el Desarrollo (Visual Studio, Android Studio, Azure, Code,
Mikro C)
Herramientas de Diseño gráfico Adobe (Illustrator, PhotoShop, XD)
Herramientas de diseño de PCB Altium Designer
Herramientas para el control de versiona miento de código fuente (TFS, Git, GitHub)

Gestión de la capacidad Ofimática

Visual Studio Online Trello


Word Excel Power Point

Producción

Diseño Gráfico

Adobe Adobe Adobe


Illustrator Photoshop XD

Motores de BD

SqLite SqlServer Oracle

||

IDEs

Visual Studio Azure g Android Studio Xamarin

Control de Versiones Desarrollo de Elctrónica

TFS Git AltiumDesigner Mikro C

Diagrama de arquitectura de aplicaciones


Arquitectura de Tecnología

Servidor de Desarrollo Microsoft Servers

Manag
ment tcp
SQL

Office
http
Studio
Visual

http

http

TFS
Usuario

Equipos de trabajo

Online
Studio
Visual
http
Adobe

local

Azure
http
local
Studio
Visual

Diagrama de Componentes
Especificación de Hardware y de Red

Servidores SysTime
en Azure

Balanceador

Firewall Servidor
de Desarrollo

http

INTERNET

Cliente 1 Firewall Equipo del


Desarrollo o Pruebas

Firewall Servidor
de Pruebas

Cliente 2 Balanceador

Servidor Servidor Erp


SysTime Inside

Diagrama de Hardware y de Red


Face C

- Introducción

Doc declaración de arquitectura


- Propósitos
- Alcances
- Principios

- Dominio de Negocio
Organizacional
Capa -> Organigrama
Procesos -> Diagrama de procesos

- Dominio de Datos
Estructura de la información
Catálogo de entidades
Datos Conceptos
Generalización

Componentes
Flujo de la información

- Dominio de Aplicaciones
Estructura
Panorama de aplicaciones ejemplo Apple (Catalogo y diagrama de Aplicaciones)

Componentes
Componentes
- Dominio de Tecnología
Estructura
Catálogo de componentes de tecnología
Diagrama de componentes físicos donde están, Servicios, sistemas Operativos etc.

Componentes

Diagrama de Capas integrando los 4 dominios (Como esta y como va a quedar en el futuro)
Análisis de Brechas por cada dominio
Mapa de ruta por cada dominio (Works Package)
Riesgos de la Implementación: Cuando se termina la arquitectura

Procesos sin análisis de impacto