Análisis de sistemas en TI

From Systems analysis wiki
Jump to navigation Jump to search

Análisis de sistemas en TI (Systems Analysis and Design) es un enfoque para el diseño y desarrollo de sistemas de información, desde la concepción hasta la explotación, que incluye la identificación de necesidades, la formalización de requisitos, el modelado del dominio y los procesos, así como la evaluación de alternativas y riesgos. En otras palabras, el análisis de sistemas en TI es la etapa del desarrollo en la que los especialistas estudian un problema, definen qué debe hacer el sistema y diseñan soluciones para su creación.

El análisis de sistemas clásico abarca un amplio espectro de áreas de aplicación, no solo el desarrollo de software, sino también cambios organizacionales, estrategias y otros aspectos.[1] [2]

Objeto y tareas del análisis de sistemas en TI

El objeto del análisis de sistemas en TI es el sistema de información (producto de software y/o servicio) a lo largo de todo su ciclo de vida, desde la concepción y justificación hasta la implementación y explotación.

La tarea del análisis de sistemas es transformar las necesidades de negocio en un conjunto coherente y verificable de requisitos y soluciones arquitectónicas: identificar y documentar los objetivos y restricciones de los stakeholders, formalizar los requisitos, modelar el dominio y los procesos, evaluar la viabilidad y los riesgos de las alternativas y justificar la arquitectura seleccionada. Como resultado, se crean documentos coherentes y se establecen vínculos trazables entre los requisitos, las decisiones de diseño y las pruebas. Esto garantiza la gobernabilidad y el control sobre el proceso de desarrollo.

Las tareas del análisis de sistemas incluyen:

  • Identificación de las necesidades y objetivos de los stakeholders. El analista recopila y aclara las expectativas de los clientes, usuarios y otras partes interesadas; se utilizan entrevistas, encuestas, observación y análisis de los procesos actuales. El resultado es una especificación de requisitos preliminar, dividida en funcionales («qué debe hacer el sistema») y no funcionales (fiabilidad, rendimiento, seguridad, etc.).[1][2]
  • Formalización y documentación de requisitos. Las solicitudes se transforman en requisitos verificables. Un requisito bien formulado debe ser claro e inequívoco, completo, coherente, verificable y trazable a objetivos de nivel superior; el conjunto de requisitos debe ser consistente e íntegro.[3][4] En la práctica, se utilizan documentos estandarizados: SRS (Software Requirements Specification) según ISO/IEC/IEEE 29148, así como, en ciertos sectores, URS (User Requirements Specification) y especificaciones funcionales.[5][6][7]
  • Análisis y modelado del sistema. Para comprender cómo funcionará el sistema e interactuará con el mundo exterior, se construyen modelos: diagramas de casos de uso (Use Case) para escenarios de uso, DFD para flujos de datos y procesos de negocio, diagramas de clases/componentes, entre otros. Los modelos sirven como base para comparar soluciones y arquitecturas alternativas.[8][9][10]
  • Evaluación de la viabilidad y selección de la solución. Se realiza un feasibility study (viabilidad técnica, organizativa, económica y de cronograma) y una comparación de alternativas arquitectónicas (trade-off). Para evaluar la calidad de la arquitectura según sus atributos (p. ej., rendimiento, escalabilidad, modificabilidad), se utilizan métodos como ATAM (Architecture Tradeoff Analysis Method).[11][12] La elección entre, por ejemplo, una arquitectura monolítica y una de microservicios [3] se basa en compromisos explícitos (complejidad de operación vs. escalabilidad independiente y velocidad de entrega) según las guías de la industria.[13][14]
  • Preparación de artefactos de diseño. Como resultado del análisis, se generan:
    • la especificación de requisitos aprobada (con indicación de su importancia),
    • el modelo conceptual del sistema (diagramas/descripciones),
    • las decisiones de arquitectura y diseño (esquemas de datos, interfaces de sistemas externos),
    • el plan de implementación (etapas/módulos).
    • Es crucial asegurar la trazabilidad bidireccional (bidirectional traceability) de los requisitos a los elementos de diseño y las pruebas.[15][4]

El éxito de un proyecto de TI depende en gran medida de prácticas maduras en la gestión de requisitos y arquitectura. Un estudio realizado por McKinsey y Oxford demostró que los grandes proyectos de TI a menudo exceden su presupuesto y cronograma. Esta investigación también subrayó la importancia de gestionar adecuadamente la estrategia, interactuar con las partes interesadas y recopilar los requisitos de manera competente. Todo esto puede influir significativamente en el éxito o el fracaso de un proyecto.[16]

Enfoques y metodologías en el análisis de sistemas de TI

El análisis de sistemas en TI se basa en los principios del pensamiento sistémico y en metodologías adaptadas para el desarrollo de software. En la práctica, se combinan enfoques «duros» y «blandos», metodologías estructuradas, notaciones orientadas a objetos, así como lenguajes de modelado de procesos y requisitos.

  • Enfoques duros y blandos. En los proyectos de TI, el enfoque duro (hard systems) implica objetivos y requisitos formalizados de antemano, descomposición y diseño «de arriba hacia abajo». El enfoque blando (soft systems) se aplica cuando los objetivos son poco claros y existen múltiples puntos de vista: se utilizan elementos de la Soft Systems Methodology (SSM) (p. ej., rich picture, definiciones raíz, CATWOE) para alinear la comprensión del problema y los cambios deseados; luego, los resultados se traducen en requisitos formales.[17][18]
  • Metodología SSM (Soft Systems Methodology). Desarrollada originalmente por Peter Checkland para cambios organizacionales, SSM es útil en las etapas previas a los proyectos de TI: desde la investigación de la situación problemática y la formulación de definiciones raíz (incluido a través de CATWOE) hasta la comparación de modelos conceptuales con la realidad y el logro de un acuerdo entre los stakeholders.[19][20]
  • Metodologías estructuradas: SADT/IDEF0. SADT modela un sistema como una jerarquía de funciones; la notación estándar IDEF0 (IEEE 1320.1) define las funciones y sus interfaces I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Este método es conveniente para la descomposición funcional y la definición de los límites del sistema, independientemente de los algoritmos.[21][22]
  • Análisis orientado a objetos: UML y SysML (MBSE). UML se ha convertido en el lenguaje base para requisitos y diseño (diagramas de casos de uso, clases, secuencias, etc.) y facilita la validación de escenarios con los usuarios; SysML extiende UML para la ingeniería de sistemas (diagramas de requisitos, diagramas paramétricos) y se basa en el enfoque MBSE, donde el modelo es el artefacto central a través de las etapas, desde los requisitos hasta las pruebas.[23][24][25]
  • Modelado de procesos de negocio: BPMN. El estándar BPMN se utiliza para describir gráficamente procesos (pools, flujos de trabajo, eventos, compuertas), incluida la comparación as-is/to-be en las especificaciones de requisitos e integración.[26][27]
  • Relación con la ingeniería de requisitos. El proceso incluye las etapas de elicitation–analysis–specification–validation–change management; los criterios de un «buen requisito» y la estructura de un SRS están regulados por ISO/IEC/IEEE 29148. Para la priorización, se utilizan técnicas como MoSCoW (Must/Should/Could/Won’t) y métodos de elección multicriterio, como AHP. En procesos ágiles, la actividad de análisis de sistemas se refleja en el backlog refinement y la trazabilidad de los requisitos.[28][29][30][31]
  • Relación con la ingeniería de sistemas. Para sistemas complejos (ciberfísicos), se aplica el Modelo V: en la rama «izquierda» se encuentran el análisis de sistemas y la arquitectura, mientras que en la «derecha» están la integración, la verificación y la validación, vinculadas a los artefactos de la rama izquierda. Los métodos para evaluar la arquitectura según atributos de calidad incluyen ATAM (análisis de trade-off).[32][33]

El análisis de sistemas en TI combina enfoques probados, desde metodologías blandas para alinear la visión hasta notaciones y estándares formales. La elección de herramientas depende del grado de definición del problema: con alta incertidumbre, aumenta el papel de SSM y la facilitación; con límites claros, se utilizan modelos formales (UML/SysML, IDEF0, BPMN) y reglamentos.

Relación con la arquitectura de TI y la arquitectura empresarial

El análisis de sistemas en proyectos de TI está estrechamente relacionado con el diseño arquitectónico. Los roles de analista y arquitecto se superponen: el analista formula los requisitos y el modelo lógico, mientras que el arquitecto define la estructura objetivo de la solución y los compromisos técnicos; el trabajo se realiza de manera conjunta.

  • Arquitectura de sistemas de TI. En un sentido estricto, la arquitectura de software es la organización de componentes, sus relaciones y los principios que guían el diseño de la solución. Para el analista, es importante considerar los estilos arquitectónicos (en capas, cliente-servidor, microservicios, orientada a eventos, etc.), ya que los requisitos no funcionales (fiabilidad, escalabilidad, modificabilidad) a menudo determinan las decisiones arquitectónicas y sus compromisos.[34][35] En la etapa temprana del análisis, se forma una visión arquitectónica (high-level vision) y se elabora un borrador del diseño de la solución para verificar la viabilidad de los requisitos (la duración de las iteraciones y el nivel de detalle dependen de la metodología).[36]
  • Patrones y decisiones preliminares. Para satisfacer los requisitos no funcionales, se aplican patrones arquitectónicos (architectural patterns). Por ejemplo, para la interacción asíncrona y el bajo acoplamiento, se utiliza el patrón publish–subscribe a través de un bróker de mensajes en una arquitectura orientada a eventos.[37]
  • TOGAF (The Open Group Architecture Framework). Uno de los marcos de arquitectura empresarial más extendidos; incluye el método ADM (Architecture Development Method) y artefactos para la gestión de la arquitectura (repositorio, catálogos/matrices, principios). En TOGAF, la gestión de requisitos es un proceso transversal, integrado en todas las fases de ADM.[36] Para respaldar los requisitos y la trazabilidad, se utilizan catálogos y matrices (p. ej., requisitos ↔ servicios, funciones ↔ componentes), y se distinguen los Architecture Building Blocks y los Solution Building Blocks.[38][39] Los principios y estándares de la empresa se registran en los catálogos correspondientes y actúan como requisitos no funcionales externos para los equipos de proyecto.[40] La conformidad de las soluciones con la arquitectura objetivo se confirma mediante un procedimiento de cumplimiento arquitectónico (Architecture Compliance Review).[41] El enfoque TOGAF implica una Architecture Vision preliminar y una posterior detallado (datos/aplicaciones/tecnologías) con un plan de migración y gestión de cambios de requisitos.[42][43]
  • Zachman Framework. Una ontología temprana e influyente de artefactos de arquitectura empresarial, presentada como una matriz de 6×6 (perspectivas × aspectos «qué/cómo/dónde/quién/cuándo/por qué»). La fila «diseñador» se corresponde con el análisis y diseño de sistemas; las columnas definen la completitud en la consideración de datos, funciones/procesos, roles, ubicación y motivación. El marco sirve como una clasificación (y no como una metodología) y ayuda a asegurar una descripción completa de la solución en el panorama empresarial.[44]
  • Relación con la arquitectura empresarial (Enterprise Architecture, EA). El analista de sistemas trabaja en el contexto de la EA: los nuevos requisitos se trazan a las capacidades de negocio y al modelo operativo; se aplican estándares y restricciones de principios de la empresa (seguridad, compatibilidad, etc.).[45][36] En la fase de iniciación, se forma una Architecture Vision (objetivos/restricciones, requisitos de alto nivel), y luego el analista los detalla, manteniendo la trazabilidad con la visión y los estándares corporativos; el incumplimiento de los estándares se identifica en las revisiones de arquitectura y puede llevar a modificaciones de la solución.[36][46]

En resumen: el análisis de sistemas y el diseño arquitectónico forman un vínculo «requisitos → soluciones arquitectónicas → compromisos en atributos de calidad». La elección de métodos (estilos/patrones, artefactos de TOGAF, clasificación de Zachman) se determina por la naturaleza del proyecto y el marco de la arquitectura corporativa.

Procesos y prácticas

El análisis de sistemas se integra en todo el ciclo de vida del desarrollo y la explotación de software, conectando los objetivos de negocio, la arquitectura y la entrega. Incluye la investigación previa al proyecto, la selección del enfoque, la creación de artefactos verificables y los requisitos de fiabilidad, rendimiento, seguridad y mantenimiento. En el modelo en cascada, el análisis se realiza antes del diseño y la implementación; en los métodos ágiles, es una actividad continua a través de iteraciones; y en DevOps, se enfoca en los objetivos operativos. Independientemente del enfoque, el análisis garantiza la trazabilidad, la gestión de cambios y riesgos, la documentación de compromisos arquitectónicos y el cumplimiento de las normativas, haciendo que el desarrollo sea predecible y gestionable.

  • SDLC clásico (Cascada). La etapa de Análisis de Sistemas y Definición de Requisitos precede al diseño y la implementación; los requisitos se fijan en un SRS detallado como base para la planificación y los contratos. Es eficaz en dominios estables y regulados; los riesgos de «congelar» los requisitos se mitigan con SRR/revisiones y la gestión de cambios a través de un CCB.[47][48][49]
  • Metodologías ágiles (Agile). El análisis es continuo: en lugar de un SRS final, se mantiene un product backlog con user stories y criterios de aceptación, que se refina en sesiones de backlog refinement; se aplica BDD (Given–When–Then); el riesgo de perder una arquitectura coherente se compensa con un diseño arquitectónico temprano y una trazabilidad transparente de requisitos ↔ implementación/pruebas.[50][51][52]
  • DevOps y SRE. Los lanzamientos frecuentes requieren requisitos operativos «por defecto»: automatización, observabilidad y reversión. Los requisitos no funcionales se formulan como SLO/SLI y se gestionan con un error budget; al backlog se añaden tareas de logs/métricas/trazas/alertas; para lanzamientos sin tiempo de inactividad, se usan patrones como blue/green, etc.[53][54][55]
  • Gestión de requisitos y riesgos. Los requisitos en ALM tienen estados y vínculos con tareas/lanzamientos/defectos; son obligatorios el control de versiones, el análisis de impacto del cambio y la repriorización regular.[56][57]
  • Aseguramiento de la calidad (QA). La calidad se incorpora desde la etapa de requisitos: revisiones, «Three Amigos», un Acceptance Test Plan y pruebas automatizadas de los criterios de aceptación (BDD/ATDD).[58][59]
  • Observabilidad y fiabilidad. En los requisitos se incluyen SLA/SLO, MTTR y MTBF con objetivos medibles y métodos de control; los parámetros provienen del negocio/operaciones y se integran en la arquitectura y las pruebas de fiabilidad.[60][61]

Métricas y calidad de los artefactos

Para evaluar el trabajo de un analista de sistemas y la calidad de sus resultados, se aplican criterios comúnmente aceptados. Los requisitos y modelos de calidad son la base de un proyecto exitoso, por lo que se gestionan a lo largo de todo el ciclo de vida (elicitation → specification → verification/validation → change management). Los atributos básicos de calidad de los requisitos están establecidos en los estándares ISO/IEC/IEEE 29148 y (históricamente) IEEE 830.[3][62][1]

  • Corrección (Correctness) — el requisito refleja una necesidad genuina y está acordado con los expertos del dominio; se confirma mediante validación (review/inspection, prototipos, escenarios).[1][4]
  • Completitud (Completeness) — se han considerado los aspectos y condiciones esenciales.
    • Completitud de un requisito individual: se especifican los detalles necesarios (p. ej., «el indicador cambia a estado rojo en caso de fallo», en lugar de simplemente «se vuelve rojo»).
    • Completitud de la especificación: se cubren escenarios/roles, se definen los NFR; se logra mediante checklists y trazabilidad a los objetivos de negocio; una auditoría independiente de completitud es útil (QA/review).[3][63]
  • Claridad (Unambiguity) — las formulaciones se interpretan de una única manera; ayuda un glosario, plantillas como «el sistema debe hacer A, cuando B, si C», ejemplos; los diagramas se acompañan de una leyenda. La verificación se realiza mediante el principio de «cuatro ojos».[3][1]
  • Consistencia (Consistency) — los requisitos no se contradicen entre sí ni con las restricciones externas; se utiliza la estructuración, tablas de atributos, revisiones en equipo; se verifican las normativas/estándares.[3][63]
  • Verificabilidad/Testeabilidad (Verifiability) — su cumplimiento se confirma mediante una prueba/demostración/análisis; las formulaciones no verificables se reemplazan con criterios medibles; para los NFR, se definen métricas y se fijan los criterios de aceptación por adelantado.[3][63]
  • Modificabilidad y Trazabilidad (Modifiability & Traceability) — identificadores únicos, estructura lógica («una idea, un párrafo»), ausencia de duplicados; se mantienen los vínculos «requisito ↔ fuente/objetivo/diseño/prueba», se utiliza una matriz de trazabilidad (RTM).[64][3]
  • Clasificación y Priorización — calidad del conjunto de requisitos; se utilizan técnicas como MoSCoW y MCDM (p. ej., AHP); la priorización conjunta con el negocio influye en la planificación y los riesgos.[65][66]

Métricas de calidad de los requisitos (ejemplos):[63][1]

  • densidad de defectos en los requisitos (comentarios por cada 100 requisitos);
  • número de cambios después de la fijación de la línea base;
  • métricas de cobertura: porcentaje de requisitos con pruebas; porcentaje de requisitos trazables a objetivos de negocio;
  • estabilidad de los requisitos (relación de requisitos añadidos/eliminados respecto al total en un período);
  • tamaño/complejidad de la especificación (número promedio de requisitos por caso de uso, profundidad de la descomposición);
  • satisfacción de los stakeholders (encuesta).

En procesos maduros (p. ej., CMMI nivel 3+), existen regulaciones de calidad de requisitos: revisiones formales, auditorías de conformidad con plantillas, recopilación/análisis de métricas.[67] En dominios críticos (aviónica, espacio, etc.), se aplican métodos formales para aumentar la fiabilidad.[68]

Errores típicos

En los proyectos de TI, son frecuentes los errores de análisis de sistemas: requisitos incompletos y ambiguos, contradicciones, límites difusos, ignorar aspectos no funcionales, omitir la integración y una seguridad tardía. Esto conduce a retrabajos, retrasos, aumento de costos y defectos.

Problemas típicos, sus consecuencias y cómo prevenirlos.

  • Requisitos incompletos u omitidos. Se pasan por alto roles con permisos especiales, casos límite y NFR. Consecuencias: rediseño de la arquitectura y aplazamiento del lanzamiento. Cómo evitarlo: checklists, lluvias de ideas de tipo «qué pasaría si…», involucrar a los testers desde el principio, trazabilidad a los objetivos de negocio.[1][69]
  • Formulaciones poco claras o ambiguas. Consecuencias: los desarrolladores implementan «algo incorrecto», el cliente queda insatisfecho. Cómo evitarlo: criterios medibles, un glosario, plantillas del tipo «A, cuando B, si C», revisión por pares (peer‑review).[3][69]
  • Requisitos contradictorios. Consecuencias: retrasos por aclaraciones, retrabajos durante la integración. Cómo evitarlo: estructuración, verificación de reglas de negocio/regulaciones, sesiones para resolver conflictos, revisión de consistencia.[3][1]
  • Síndrome de la «placa de oro» (gold‑plating). Consecuencias: aumento del alcance, mayor complejidad, nuevos puntos de fallo. Cómo evitarlo: vincular cada requisito a un objetivo/métrica; en Agile, no incluir elementos innecesarios en el backlog; fijar el alcance; ver YAGNI.
  • Detalle excesivo donde no es necesario. Cómo evitarlo: separar el qué/por qué (requisitos) del cómo (diseño/implementación); usar design‑free requirements cuando sea apropiado.[3]
  • Pérdida de control sobre los requisitos. Consecuencias: confusión de versiones, implementación de «lo incorrecto». Cómo evitarlo: una única fuente de verdad en ALM, historial y estados, RTM y análisis de impacto de cambios; gestión de cambios a través de un CCB.[64][1]
  • Falta de participación de los usuarios. Cómo evitarlo: entrevistas, observación, prototipos, demostraciones regulares; validación explícita con los stakeholders.[3][1]
  • «Parálisis por análisis» demasiado prolongada. Cómo evitarlo: definir un umbral de suficiencia, iteratividad y timeboxing; lanzar un MVP/incrementos y ajustar según el feedback.[1]
  • Ignorar los requisitos no funcionales. Cómo evitarlo: identificar los NFR (p. ej., FURPS+), establecer criterios medibles, incluirlos en el plan de pruebas y en las decisiones arquitectónicas.[1][3]
  • Errores de comunicación y el «factor humano». Cómo solucionarlo: desarrollar habilidades de entrevista y facilitación, mantener la neutralidad, registrar las decisiones y las fuentes de los requisitos (trazabilidad a los objetivos).[1]

La mayoría de los problemas se reducen a la calidad de las formulaciones, la completitud y la gestión de los requisitos; la aplicación de estándares como ISO/IEC/IEEE 29148 y prácticas de SWEBOK (validación, trazabilidad, iteratividad) reduce significativamente el riesgo de incumplimiento de plazos y retrabajos.[3][1]

Limitaciones

A pesar de su eficacia para reducir la incertidumbre, el análisis de sistemas tiene sus limitaciones:

  • La realidad es cambiante y compleja. Es imposible tener en cuenta todos los factores, especialmente en proyectos a largo plazo. Algunos requisitos inevitablemente aparecerán después del lanzamiento del sistema. Es importante esforzarse por minimizar las sorpresas, pero hay que estar preparado para los cambios.
  • Los requisitos dependen de las personas. Las prioridades del negocio, las leyes y el mercado pueden cambiar. El análisis de sistemas captura el estado actual y no puede predecir todos los cambios externos. Para adaptarse, es necesario actualizar los requisitos regularmente y trabajar de forma iterativa.
  • Los usuarios no siempre saben lo que quieren hasta que lo ven. Esta es una limitación conocida. El prototipado y las metodologías ágiles, como Agile, ayudan a superar este problema. El análisis en papel tiene sus límites, y para obtener datos precisos se necesita retroalimentación de las implementaciones.
  • Equilibrio entre tiempo y calidad. Un análisis excesivamente detallado puede quedar obsoleto. En áreas innovadoras, es mejor crear rápidamente un producto mínimo viable (MVP) y obtener datos reales. El análisis de sistemas es eficaz en áreas estables, pero en proyectos de investigación y desarrollo (I+D), su papel es limitado.
  • El factor humano. Incluso las mejores metodologías no compensan la incompetencia del analista o la falta de disponibilidad del cliente. Es crucial que todos los participantes en el proceso estén involucrados y motivados.

Influencia de las tecnologías modernas en el análisis de sistemas en TI

El análisis de sistemas en TI evoluciona constantemente bajo la influencia de las innovaciones tecnológicas. El analista del siglo XXI trabaja en un entorno de crecimiento exponencial de datos, implementación generalizada de IA, ciclos de desarrollo rápidos y una mayor atención a la seguridad. Una práctica exitosa del análisis de sistemas requiere la adquisición de nuevos conocimientos (ciencia de datos, ciberseguridad, tecnologías en la nube) y flexibilidad en la aplicación de métodos.

  • Datos e IA/ML: qué se añade al análisis. Para sistemas con IA, desde el principio se definen los objetivos y el contexto de aplicación, los requisitos sobre las fuentes y la calidad de los datos, así como las métricas de confianza en las decisiones del modelo (fiabilidad, seguridad, explicabilidad, confidencialidad, equidad). Se planifican verificaciones TEVV (testing, evaluation, verification, validation), monitorización en producción y un apagado/retirada segura del modelo. Estos pasos se corresponden con las funciones GOVERN–MAP–MEASURE–MANAGE del marco NIST para la gestión de riesgos de IA; se reflejan en el SRS, la arquitectura y los planes de verificación/operación.[70]
  • DevSecOps: seguridad desde el principio y por defecto. Integrar la seguridad en cada etapa del CI/CD se está convirtiendo en la norma: verificaciones automáticas (SAST/DAST), escaneo de dependencias y contenedores, políticas de despliegue y observabilidad básica. Se utilizan registros de artefactos de confianza e imágenes estandarizadas y «reforzadas» (hardened); se aplican los principios de confianza cero. En el análisis de sistemas, se describen de antemano los puntos de control del pipeline (condiciones para pasar de etapa), la relación de los requisitos con los controles de seguridad y las reglas para la transición entre entornos (dev/test/stage/prod).[71]
  • Qué cambia en los documentos (artefactos). Qué sección aparece o se detalla en los documentos clave en presencia de Big Data e IA/ML y al trabajar con DevSecOps:
    • SRS / Especificación de requisitos: objetivos y contexto de aplicación de la IA; requisitos de datos (origen, calidad, restricciones éticas y legales); métricas del modelo (precisión, fiabilidad, tiempo de respuesta); plan TEVV (testing, evaluation, verification, validation); requisitos de transparencia/explicabilidad y privacidad; criterios para la desactivación/retirada del modelo de producción.[70]
    • Arquitectura y decisiones (Architecture, ADR): resultados del modelado de amenazas; medidas de «seguridad por defecto» (cifrado, control de acceso, gestión de secretos, principio de privilegio mínimo); restricciones sobre el uso de datos/modelos; registros ADR con evaluación de riesgos y compromisos.[71][70]
    • Plan de verificación y validación (V&V / TEVV): escenarios de prueba para modelos y datos; umbrales de aceptación para métricas de calidad; monitorización de la deriva de datos/modelo; procedimientos para la reevaluación periódica y la revalidación.[70]
    • Políticas de CI/CD y «puertas» del pipeline: verificaciones automáticas SAST/DAST, SCA (dependencias), escaneo de contenedores; firma y almacenamiento de artefactos en registros de confianza; reglas de promoción entre entornos (dev/test/stage/prod) y condiciones para bloquear la compilación si fallan las verificaciones; requisitos de observabilidad por defecto.[71]
    • Plan de gestión de datos y modelos: catálogo de fuentes y linaje; criterios de calidad y disponibilidad de datos; versiones de datasets/modelos; calendario de (re)entrenamiento y control de sesgos (bias); política de acceso y almacenamiento; plan para la desactivación segura del modelo y eliminación de datos si es necesario.[70]
    • Operación y observabilidad (Ops/Runbook): métricas de confianza en la IA y SLO; auditoría y registro; alertas sobre degradación/anomalías; plan de respuesta a incidentes; fallback/kill‑switch para componentes de IA; requisitos de informes y análisis post-incidente.[70][71]
    • Trazabilidad (end‑to‑end): vínculos explícitos «requisito ↔ control/verificación en el pipeline» y «requisito ↔ prueba/monitorización en producción», para poder verificar de manera demostrable la seguridad y la calidad a lo largo de todo el ciclo de vida.[71][70]
  • Rol del analista de sistemas.
    • gestiona el contexto y los riesgos de la IA (actores, escenarios de aplicación, suposiciones y limitaciones de los datos);
    • asegura la trazabilidad «requisito ↔ control de seguridad en el pipeline»;
    • formula requisitos no funcionales verificables (seguridad, transparencia, observabilidad) a lo largo de todo el ciclo de vida del sistema.[70][71]

Diferencias con el análisis de sistemas clásico

El término «Análisis de sistemas» es históricamente más amplio que el desarrollo de software. El análisis de sistemas clásico es un enfoque para resolver problemas complejos e interdisciplinarios (sociales, económicos, de gestión), basado en el pensamiento sistémico y métodos cuantitativos, generalmente para apoyar la toma de decisiones gerenciales. En TI, por análisis de sistemas se entiende una disciplina aplicada en el campo de la ingeniería de software, orientada a la creación de sistemas de información.

A continuación, las diferencias clave.

  • Objetivos y objeto de análisis. El análisis clásico resuelve problemas mal estructurados y «difusos», y mejora sistemas sociotécnicos ya existentes (una red de transporte urbano, la estrategia de una empresa, una política medioambiental). El objeto es un sistema real; la tarea es ayudar a los responsables de la toma de decisiones a elegir un curso de acción. Para el análisis de sistemas en TI, el objetivo es diseñar y crear un nuevo sistema de información o producto de software que cumpla con los requisitos. El objeto es el sistema que se está diseñando; el enfoque está en el comportamiento y las características que necesitan los usuarios.
  • Bases metodológicas. Las escuelas clásicas se basan en el pensamiento sistémico y, a menudo, en las matemáticas. El enfoque duro (hard systems) implica la formalización del problema, criterios cuantitativos y optimización (como en la investigación de operaciones). Las metodologías blandas (soft systems) reconocen la multiplicidad de puntos de vista; un ejemplo es la Soft Systems Methodology (SSM), donde a través de discusiones y modelos conceptuales se acuerdan los cambios deseados. En TI, la base son las disciplinas de ingeniería: ingeniería de requisitos, diseño de software, marcos de arquitectura. Se aplican procesos estandarizados (ISO/IEC/IEEE 15288, 12207, 29148), notaciones UML/SysML y prácticas de gestión de cambios.
  • Roles y artefactos. En el análisis clásico, el rol de «analista de sistemas» es a menudo informal; los resultados son un informe analítico, recomendaciones, modelos matemáticos, escenarios «qué pasaría si». En TI, el rol del analista (o analista de negocio) está formalizado; se producen especificaciones de requisitos, modelos del sistema (UML, ER), especificaciones de interfaces, user stories y backlog, artefactos utilizados directamente por desarrolladores y testers.
  • Ciclo de vida y proceso. El análisis clásico no tiene una plantilla única: los pasos dependen del problema (en SSM, desde el estudio de la situación hasta la implementación de los cambios). En TI, se adoptan ciclos de vida de desarrollo de software (SDLC) estándar: en el modelo en cascada hay una fase separada de análisis de requisitos; en los enfoques iterativos y ágiles, el análisis es una actividad constante en cada sprint. Las prácticas modernas (DevOps, CI/CD) amplían el alcance del análisis a la explotación: se tienen en cuenta los requisitos de mantenimiento, observabilidad y actualizabilidad. En otras palabras, el análisis de sistemas en TI está integrado en el ciclo de vida del desarrollo, mientras que el clásico se realiza más a menudo como una actividad de proyecto o consultoría.

Analista de sistemas

El analista de sistemas en TI es el especialista responsable del pensamiento sistémico en el diseño y desarrollo de sistemas de información: formulación y validación de requisitos, modelado (UML/BPMN), alineación de decisiones arquitectónicas y garantía de la integración. El rol y los requisitos de cualificación en la Federación Rusa están establecidos en el estándar profesional y en los Estándares Educativos Federales del Estado (FGOS).

Objetivo principal del tipo de actividad profesional: Asegurar la conformidad de un servicio de TI, sistema automatizado, sistema de información automatizado, sistema de gestión automatizado, producto o herramienta de software o información (en adelante, el Sistema) con su entorno, los requisitos y restricciones iniciales, y los objetivos de la automatización y la actividad automatizada, mediante el desarrollo y la entrega de soluciones de diseño de calidad e interconectadas a las partes interesadas, al iniciar y coordinar el trabajo de los ejecutores individuales a lo largo de todo el ciclo de vida del Sistema (Estándar Profesional «Analista de Sistemas» (Orden del Ministerio de Trabajo de la Federación Rusa del 27.04.2023 N.º 367н).[72]

Glosario de términos clave

Conceptos básicos y participantes

  • Análisis de sistemas en TI — disciplina cuyo objeto es un sistema de información a lo largo de todo su ciclo de vida, desde la concepción hasta la explotación.
  • Stakeholders — personas o grupos interesados en el proyecto o afectados por él (clientes, usuarios, gerentes).
  • Artefactos del proyecto — documentos y resultados creados durante el proceso del proyecto, como especificaciones, modelos, planes y decisiones.

Requisitos: tipos y documentación

  • Requisitos funcionales — describen lo que el sistema debe hacer; sus funciones y comportamiento.
  • Requisitos no funcionales — describen los atributos de calidad del sistema (fiabilidad, rendimiento, seguridad, usabilidad, escalabilidad, etc.).
  • Especificación de requisitos (preliminar) — documento que contiene el conjunto inicial de requisitos recopilados en las primeras etapas del proyecto.
  • SRS (Software Requirements Specification) — documento estandarizado que describe detalladamente los requisitos de un software según estándares internacionales (p. ej., ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — documento que describe los requisitos del usuario para un sistema desde la perspectiva de los procesos de negocio y las expectativas del usuario final.
  • Requisitos arquitectónicamente significativos (ASR) — requisitos que influyen sustancialmente en las decisiones y compromisos arquitectónicos.
  • Requisitos transversales (CFR) — sinónimo de requisitos no funcionales, que enfatiza su naturaleza transversal.
  • Criterios de aceptación (Acceptance Criteria) — condiciones verificables cuyo cumplimiento indica que el trabajo sobre un requisito se considera aceptado.
  • Definition of Ready (DoR) — acuerdo sobre cuándo un elemento del backlog está listo para ser desarrollado (claridad, estimación, criterios).
  • Definition of Done (DoD) — acuerdo sobre la «finalización» de un trabajo (código, pruebas, documentación, despliegue).
  • Restricción (Constraint) — condición estricta que limita las soluciones (plazos, plataformas, estándares, licencias).
  • Supuesto (Assumption) — conjetura aceptada sin pruebas que requiere validación posterior.
  • Calidad de los requisitos — propiedades según ISO 29148: claridad, completitud, consistencia, verificabilidad, atomicidad.

Formalización, trazabilidad y priorización de requisitos

  • Formalización de requisitos — proceso de transformar solicitudes informales en requisitos claros, verificables e inequívocos.
  • Trazabilidad de requisitos — capacidad de seguir el ciclo de vida de un requisito desde su origen hasta su implementación, prueba y despliegue.
  • Bidirectional traceability (trazabilidad bidireccional) — capacidad de seguir las conexiones entre requisitos, elementos de diseño y escenarios de prueba tanto hacia adelante como hacia atrás.
  • MoSCoW — técnica de priorización de requisitos que los clasifica como Must-have (debe tener), Should-have (debería tener), Could-have (podría tener) y Won't-have (no tendrá).
  • BDD (Behavior-Driven Development) — metodología de desarrollo en la que las pruebas se escriben en un lenguaje natural orientado al comportamiento del sistema desde la perspectiva del usuario (formato Given–When–Then).

Notaciones y modelado

  • UML (Unified Modeling Language) — lenguaje gráfico estandarizado para la especificación, visualización, construcción y documentación de los componentes de sistemas de software.
  • SysML (Systems Modeling Language) — extensión de UML para la ingeniería de sistemas, que apoya el modelado de diversos aspectos de sistemas complejos, incluidos requisitos, comportamiento, estructura y parámetros.
  • BPMN (Business Process Model and Notation) — estándar de notación gráfica para describir procesos de negocio, que permite visualizar flujos de trabajo, eventos, compuertas y pools.
  • MBSE (Model-Based Systems Engineering) — enfoque de la ingeniería de sistemas donde el modelo es el artefacto central en todas las etapas del ciclo de vida del sistema, desde los requisitos hasta las pruebas.
  • ArchiMate — notación para la arquitectura empresarial (negocio, aplicaciones, tecnologías) y sus relaciones.
  • DMN (Decision Model and Notation) — modelado de decisiones de negocio y tablas de reglas.
  • DFD (Data Flow Diagram) — diagramas de flujo de datos (contexto, niveles de descomposición).
  • ERD (Entity-Relationship Diagram) — modelo del dominio con entidades, relaciones y atributos.
  • Matriz CRUD — correspondencia de las operaciones Create/Read/Update/Delete con entidades y roles/funciones.

Estilos arquitectónicos y evaluación de soluciones

  • Arquitectura monolítica — enfoque arquitectónico en el que todo el sistema se desarrolla como un único módulo indivisible.
  • Arquitectura de microservicios — enfoque arquitectónico en el que el sistema se construye como un conjunto de servicios pequeños, desplegables y escalables de forma independiente.
  • Trade-off (compromiso) — elección entre características o decisiones mutuamente excluyentes o contradictorias, donde la mejora de una característica se produce a expensas del empeoramiento de otra.
  • ATAM (Architecture Tradeoff Analysis Method) — método para evaluar la arquitectura de software, utilizado para analizar los compromisos entre atributos de calidad (p. ej., rendimiento, escalabilidad).

Arquitectura empresarial y marcos de trabajo

  • TOGAF (The Open Group Architecture Framework) — uno de los marcos de arquitectura empresarial más comunes, que incluye el método ADM (Architecture Development Method) para desarrollar y gestionar la arquitectura.
  • Zachman Framework — ontología de artefactos de la arquitectura empresarial, presentada como una matriz de 6×6, que clasifica diferentes aspectos de la arquitectura desde diversas perspectivas.

Enfoques de análisis y procesos de desarrollo

  • Enfoque duro (Hard Systems) — metodología de análisis de sistemas que presupone objetivos y requisitos formalizados de antemano, descomposición y diseño «de arriba hacia abajo», eficaz para tareas claramente definidas.
  • Enfoque blando (Soft Systems) — metodología de análisis de sistemas aplicada cuando los objetivos no son claros y existen múltiples puntos de vista de los stakeholders, orientada a alinear la comprensión del problema y los cambios deseados.
  • SSM (Soft Systems Methodology) — una metodología específica del enfoque de sistemas blandos, desarrollada por Peter Checkland, que utiliza herramientas como rich picture, definiciones raíz y CATWOE.
  • Waterfall (modelo en cascada) — metodología clásica de desarrollo de software donde las etapas (análisis, diseño, implementación, pruebas, despliegue) se realizan de forma secuencial, completando una etapa antes de comenzar la siguiente.
  • Agile — grupo de metodologías de desarrollo de software flexibles, orientadas al desarrollo iterativo, la adaptación a los cambios, la colaboración con el cliente y la entrega continua de valor.

Métodos de elección y errores típicos

  • AHP (Analytic Hierarchy Process) — método de elección multicriterio que permite estructurar problemas complejos y evaluar alternativas basándose en una jerarquía de criterios.
  • Gold-plating (síndrome de la «placa de oro») — error en el análisis de sistemas que consiste en añadir funcionalidad no requerida por los stakeholders, lo que conduce a un aumento del alcance y la complejidad del proyecto.

Enlaces

Bibliografía

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5.ª ed.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Versión oficial gratuita.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Descarga oficial gratuita (bajo licencia).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4.ª ed.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3.ª ed.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2.ª ed.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5.ª ed.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3.ª ed.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4.ª ed.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11.ª ed.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8.ª ed.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7.ª ed.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3.ª ed.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2.ª ed.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4.ª ed.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4.ª ed.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2.ª ed.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Referencias

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Definición de «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (menciona URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — requisitos para la descripción de la arquitectura y los puntos de vista. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (overview). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (especificación). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (definición de EA como «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Reimpresión (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (estándar histórico). Copia de estudio (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (sobre problemas típicos en requisitos/trazabilidad). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Estándar Profesional «Analista de Sistemas» (Orden del Ministerio de Trabajo de la Federación Rusa del 27.04.2023 N.º 367н).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Análisis_de_sistemas_en_TI&oldid=9094"