Proceso de Arquitectura Flashcards
Que aspectos deben ser tratados en el desarrollo de una arquitectura?
En el desarrollo de una arquitectura los requerimientos funcionales (el “Que”) y los requerimientos no funcionales (los “Qualities” del sistema) no deberian ser tratados aisladamente. Deben ser refinados durante el ciclo de vida del proyecto.
Que son los requerimientos funcionales?
- Son las capacidades requeridas por los usuarios para cumplir con sus resectivos trabajos.
- Responden al “que” es lo que el cliente quiere (pero no al cómo)
Mencione los dos tipos de requerimeintos no funcionales que hay, y expliquelos.
Qualities (Atributos de calidad)
* Definen laas expectativas y caracteristicas que el sistema deberia soportar.
* Pueden ser runtime (por ejemplo performance o disponibilidad) op non-runtime (por ejemplo escalabilidad y/o mantenibilidad)
Contraints
* Elementos dados que no pueden ser cambiados en el proyecto.
* Otros factores como deiniones de tecnologia, skillls disponibles y presupuesto.
Para que sirve un diagrama de contexto?
- Clarificar el entorno en el que tiene que operar el sistema.
- Delimitar la frontera del sistema.
- Identificar las interfaces externas (usuarios y sistemas)
Imagen ejemplo aqui
Menciona algunas de las formas de documentar los requerimientos funcionales
- Los procesos de negocio son una de las formas de documentar los requerimientos funcionales.
- Los casos de uso tambien son una de las formas de documentar los requerimeintos funcionales.
Explique que es un proceso de negocio.
- Un proceso de negocio muestra cmo el trabajo es encominado a traves de la organizacion, mostrando la intervencion de diferentes actores ubicados en una o mas ubicaciones.
- Primeramente nos interesa trabajar con los proceso o partes de estos que estan cienso automatizados.
Ejemplo aqui
Porque los casos de uso don una de las formas de documentar los requerimentos funcionales?
Cada caso de uso define la interaccion entre un actor y el sistema.
Eplique que son las Épicas, las User Stories y los temas.
Epicas: Las épicas son historias grandes que normalmente representan requerimientos complejos que necesitan ser dividos antes de desarrollarlos.
User Stories Una user story es la descripcion de una requermientos del sistema desde el punto de vista del usuario o la perspectiva del stakeholder.
Temas: Los temas son colecciones de User Stories agrupados para propositos de priorizacion y planificacion.
Diagrama ejemplo aquí
Como tienden a definirse los requerimientos funcionales bajo varios metodos agiles?
Los requerimeintos funcionales bajo varios metodos agiles tienden a definirse enterminos de Épicas, User Stoires y Temas.
Mencione caracteristicas de las Casos de uso vs User Stories
- No hay un acuerdo de cuendo aplicar una u otra tecnica, o ambas.
- Sin embargo, podemos argumentar que:
-Las User Stoires son una manera de describir los requermientos.
-Los Casos de Uso pueden ser una manera de detallar user stories.
Que son los requerimientos funciones arquitecturalemente significativos.
- Son los procesos que afectan la arquitectura del sistema .
- Pueden identificarse verificanmdo que presenten o se relacionen con:
-Funciones con alto retorno de negocio
-Operaciones críticas de negocio
-Funcionalidades esenciales del sistemas
-Usuarios influyentes
-Usuarios móviles
-Tener una cobertura amplia y que utilizan varios elementos de la arquitectura
-Requerimientos de seguridad
-Complejidad (por ejemplo reglas de negocio complejas)
-Demanda exigente de la arquitectura (requerimientos de performance y disponibilidad)
-Con alto potencial de cambio
-Sincronización y comunicación con sistemas externos
-Los que presentan riesgos o issues identificados
Cual es la regla del 80/20?
El 20% de los requermientos cubren el 80% de la actividad de los usuarios.
Que definen los requermientos no funcionales?
Los requerimientos no funcionales definen los atributos de calidad (“qualities”) del sistema y las restricciones bajo las cuales el sistema debe ser construido.
* Los qualities definen las expectativas y carateristicas que el sistema deberia soportar.
* Las restricciones son las limitaciones y especificaciones impuestas a la solucion.
Como se dividen los atributos de calidad?
Los atributos de calidad se dividen en: Runtime y Non-Runtime
Mencione los atributos de calidad Runtime
- Capacity and Performance
- Availability
- Security
- System Managment
- Integration Services
Mencione los atributos de calidad Non-Runtime
- Portability
- Maintainability
- Scalability
- Data Integrity
- Safety
Mencione algunas restricciones de negocio.
- Regulatory
- Organisational
- Risk Wilingness
- Marketplace Factors
- Schedule and Budget
Mencione algunas restricciones tecnicas.
- Legacy Integration
- Development Skills
- Existing Infrastructure
- Technology State of te Art
- IT Standars
En que se basan las deciones de Arquitectura?
Con frecuencia, hay más de una solución posible para un problema de arquitectura.
Esto involucra componentes y sus relaciones, elecciones de tecnología, asignación de funcionalidades a los diferentes componentes, tomando decisiones de ubicación de componentes en los diferentes nodos. Cada alternativa tienen costos diferentes, satisfacen un conjunto de requerimientos o restricciones, y presentan diferentes maneras de balancear intereses que pueden competir entre sí.
Que permiten las decisiones de Arquitectura?
Permiten:
* Documentar formalmente las elecciones críticas que tomaron en la creación de la solución.
* Entender y acordar por qué la solución es lo que es.
Para que sirven las deciciones de Arquitectura?
- Explicitan la razón y la justificación de la decisión que se tomó
- Ayudan a asegurar que la solución cumplan con los requerimientos funcionales y no-funcionales, y si no lo hacen, ayudan a hacerlo explícito para los stakeholders.
- Previenen retrabajo innecesario a través del ciclo de vida del Proyecto.
Que elementos deberia contener la documentacion de las deciciones de Arquitectura?
Las decisiones de arquitectura deben ser correctamente documentadas, preferentemente usando un template estándar. Los elementos que debiera contener son:
- La decisión de arquitectura: Escrita como una declaración, por ejemplo “El Sistema usará el patrón de integración por mensajería para comunicarse con la aplicación XYZ”
- Identificador único: Un Código único que identifica la decisión sin ambigüedad, por ejemplo: “AD-065”
- Problema o Issue: Una descripción de la situación en la cual una decisión debe ser tomada, por ejemplo “´¿Cómo el Sistema debiera integrarse con la aplicación XYZ?”
- Supuestos: ¿Qué es lo que entendemos debe ser cierto sobre el contexto del problema, restricciones de la solución, etc…? por ejemplo: “La aplicación XYZ soporta un interfaz de mensajería”
- Alternativas: Si no hay alternativas entonces no puede haber una decisión de arquitectura. Es una lista de alternativas y explicaciones. Ejemplo 1- Transferencia de archivos 2-Mensajería
- Decisiones: La decisión tomada, por ejemplo: “Se elige la alternativa 2”
- Justificación: Porqué la decisión fué tomada, por ejemplo: “Mensajería provee comunicación programa a programa confiable, asincrónico”
- Implicancias: Las consecuencias y los impactos de la decisión tomada sobre los otros aspectos de la solució. Por ejemplo: 1. Un nodo de integración es requerido 2. Una nueva capa existirá que deberá considerarse para el modelado de performance, y disponibilidad.
Cual es el proposito del AOD (Diagrama General de Arquitectura)?
- Comunicar a los sponsors y stakeholders un entendimiento conceptual del sistema que se está pensando
Pueden existir más de un AOD, orientado a los diferentes stakeholders - Proveer una visión de alto nivel de la arquitectura y alcance del sistema a desarrollar
- Explorar y evaluar alternativas técnicas
- Facilitar el reconocimiento y validación temprana del enfoque
- Facilitar orientación de las nuevas personas que entran al proyecto
Que contiene y que provee un AOD (Diagrama General de Arquitectura)?
- Un AOD contiene diagramas que representan las principales ideas que gobiernan la solución y los building blocks candidatos de un sistema de IT.
- Provee una visión de los principales elementos conceptuales y las relaciones en una arquitectura de IT, que con frecuencia incluye subsistemas candidatos, componentes, nodos, conexiones, almacenamientos, y sistemas externos.
Que es un componente, y que tipos de componentes hay?
Componente: Una parte encapsulada de un sistema de software que tiene una interfaz claramente definida a través de la cual se pueden acceder a sus servicios.
Tipos de Componentes:
* De aplicación
* Técnicos
* De Hardware
Porque un modelo de componentes?
- Los sistemas complejos y ricos en software de hoy en día no pueden ser comprendidos sin modelos.
- Los modelos descomponen sistemas complejos en partes más pequeñas, componentes, que tienen responsabilidades funcionales bien entendidas. Esto nos ayuda a visualizar y entender el sistema.
De que es una representacion formal el modelo de componentes?
- La estructura interna de la solución (las relaciones entre los componentes que conforman la solución), es decir, la Vista Estática, y el comportamiento de la solución, es decir, la Vista Dinámica.
- Un paso siguiente al Diagrama de Contexto del Sistema que se alinea con el principio de Ingeniería de la Caja Negra hacia el principio de la Caja Blanca, en el cual los arquitectos examinan “qué hay dentro de la solución”.
- Proporciona la entrada necesaria para el modelo operativo para tomar decisiones adecuadas sobre varios aspectos de los componentes:
¿Dónde deberían ejecutarse los componentes?
¿Dónde deberían residir los datos de los componentes?
¿Dónde deberían instalarse los componentes?
¿Cómo se comunicarán entre sí los componentes?
Que es un componente?
Un componente es un concepto fundamental utilizado para describir el aspecto funcional de la arquitectura de TI.
* Un componente es una unidad modular de funcionalidad.
* Un componente pone su funcionalidad y estado (la informacion manejada por el componente) a disposición a través de una o más interfaces.
* Un componente no es solamente un concepto a nivel de programación, como un componente Oracle® EJB o .NET.
Dime ejemplos de componentes
Ejemplos de componentes son:
* En el nivel de aplicación del modelo de componentes:
Componentes de procesamiento de negocios (como el componente de Procesamiento de Clientes)
Componentes de servicios empresariales (como el componente de Administrador de Cuentas)
* En el nivel técnico del modelo de componentes:
Componentes técnicos (servicios de seguridad o middleware, como mensajería o software de transacciones)
Componentes de software del sistema (como un sistema operativo)
Componentes de hardware (como un dispositivo de encriptación)
