-
NO ESTÁ PERMITIDO PUBLICAR
Acerca de José Antonio Rojas Delgado:
- Analista-Programador | Diseñador Web | Formador Ocupacional | Webmaster - SEO - Community Manager
- Almería (España)
- +034 629 62 70 84
+034 629 62 70 84- joseantonio@rojasdelgado.com
-
José Antonio Rojas Delgado (http://www.rojasdelgado.com)
23/11/2025 13:43:53
domingo, 23 de noviembre del año de N.S. 2025jard: ATENCION, CONTENIDO PARA ADULTOS
CAPERUCITA ROJA EN 2025
UNA HISTORIA DE AMOR GENERADA POR INTELIGENCIA ARTIFICIAL
-
José Antonio Rojas Delgado (http://www.rojasdelgado.com)
22/11/2025 07:44:17
sábado, 22 de noviembre del año de N.S. 2025jard:La mentira del "Data-Driven": Cuando el análisis mata la decisión.
Nos dicen que la mentalidad analítica traduce el ruido en decisiones. ¿Y si a veces hace lo contrario? 🤔
Como estudiante, veo a menudo cómo buscamos "el dato perfecto" y acabamos en parálisis por análisis. He investigado cómo autores como Nate Silver y Kahneman explican esta tensión.
¿En vuestros trabajos, más datos os dan seguridad o ansiedad? Os comparto mi análisis crítico 👇
¿Tu análisis elimina el ruido o paraliza la decisión? 🧠📊
El pensamiento analítico como filtro de incertidumbre:
El pensamiento analítico actúa operacionalmente como un sistema de decodificación que procesa grandes volúmenes de datos no estructurados ("ruido") para identificar patrones coherentes ("señal").
Según la teoría de la predicción de Nate Silver, este proceso es fundamental porque el cerebro humano tiende a percibir patrones donde no existen;
por tanto, una mentalidad analítica disciplinada aplica lógica y estadística para separar la variabilidad aleatoria de la información causalmente relevante, permitiendo fundamentar estrategias.
Fuentes: Nate Silver (Signal/Noise) [Confianza: Alta]
https://www.supersummary.com/the-signal-and-the-noise/summary/
...pero...
Sin embargo, asumir que el análisis conduce invariablemente a la decisión es una falacia lógica conocida como "la trampa de la racionalidad".
En psicología organizacional, se documenta el fenómeno de la Parálisis por Análisis, donde el exceso de procesamiento de información aumenta la ansiedad y detiene la toma de decisiones en lugar de facilitarla.
Además, como señalan Daniel Kahneman y sus colaboradores, el propio juicio analítico humano es ruidoso;
dos expertos analizando los mismos datos pueden llegar a conclusiones opuestas debido a factores circunstanciales, lo que implica que el "traductor" analítico no es ni infalible ni neutro.
Fuente: Analysis Paralysis [Confianza: Alta]
https://en.wikipedia.org/wiki/Analysis_paralysis
Fuente: Kahneman (Noise) [Confianza: Alta]
https://lamenteesmaravillosa.com/ruido-fallo-nuestros-juicios-impide-tomar-buenas-decisiones/
De la información a la acción ejecutiva:
En última instancia, el objetivo de la analítica no es la certeza absoluta, sino la reducción del margen de error hasta un nivel aceptable para actuar.
La "decisión" surge cuando el analista transforma insights probabilísticos en compromisos ejecutables, asumiendo conscientemente el riesgo residual.
Fuente: Data Driven Pitfalls [Confianza: Media]
https://marriott.byu.edu/magazine/feature/the-seven-pitfalls-of-data-driven-decision-making-and-how-to-avoid-them
Epitafio de Verificación:
Informe ...pero... generado el 22/11/2025 mediante agente GPT especializado, y verificado por José Antonio Rojas Delgado, https://rojasdelgadocom.sserver.es
-
José Antonio Rojas Delgado (http://www.rojasdelgado.com)
19/11/2025 09:08:53
miércoles, 19 de noviembre del año de N.S. 2025jard: La arquitectura de conjunto de instrucciones complejo (CISC), como las implementaciones modernas de x86, utiliza típicamente una unidad de control microprogramada. En esta configuración, las instrucciones complejas en lenguaje ensamblador se traducen internamente, mediante un decodificador, a una secuencia de múltiples microinstrucciones o micro-operaciones (μops) antes de su ejecución.
Fuente 1: Patterson, D.A. & Hennessy, J.L. (2014). Computer Organization and Design MIPS Edition: The Hardware/Software Interface. Elsevier, p. 302-303. URL: https://www.youseficlass.ir/wp-content/uploads/2023/07/Computer_Organization_and_Design_5th_Edition_David_A_Patterson_John_watermark.pdf
Fuente 2: Intel Corporation (2024). Intel® 64 and IA-32 Architectures Software Developer’s Manual, Vol. 1. URL: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
...pero...
...pero... esta no es una regla universal para todas las instrucciones. Las arquitecturas CISC modernas han adoptado muchas características RISC (Reduced Instruction Set Computer) en su núcleo de ejecución. En los procesadores contemporáneos (como Intel Core), las instrucciones más sencillas y de uso frecuente (como MOV o ADD de registro a registro) a menudo se decodifican directamente a una única μop e incluso pueden omitir la etapa de microcódigo, pasando a una ejecución cableada (hardwired). Esto se hace para mejorar la velocidad y la eficiencia de la canalización (pipelining), especialmente en un contexto de ejecución fuera de orden (out-of-order execution).
Fuente 3: Stallings, W. (2018). Computer Organization and Architecture: Designing for Performance. Pearson. URL: https://os.ecci.ucr.ac.cr/ci0114/material/Stallings/Computer-Organization-Architecture-11th.pdf
Epitafio de Verificación:
Otra verificación de José Antonio Rojas Delgado mediante la Gem ...pero..., que busca todos los peros de todos los enunciados recibidos y los justifica mediante referencias. (Fecha del análisis: 19 de Noviembre de 2025)
-
José Antonio Rojas Delgado (http://www.rojasdelgado.com)
22/09/2024 08:06:38
domingo, 22 de septiembre del año de N.S. 2024jard: ¿Cuánto es 1+1?
En esta era de la desinformación del 2024 me enfrento a una pregunta de mi sobrino Toni, que en el verano de 2024 solo contaba con 6 años. Sencilla donde las haya, la pregunta puede requerir unas aptitudes para ser respondida cualificadamente que no poseen la mayoría de los adultos. No la considero, en todo caso, una pregunta, sino un problema, ya que la respuesta no es simple, sino una solución (al problema).
Trataré de explicarlo en estas líneas con ejemplos de lo que quiero decir, aunque no estoy muy seguro del modo más didáctico de hacerlo. En fin, es solo un esbozo de artículo de blog, no un ensayo.
El 1 es la unidad matemática, de modo que si nos quedamos en las matemáticas podríamos argumentar que la única respuesta es 2 (dos). Esta es la solución matemática *1. Pero las matemáticas no son una forma natural de describir el mundo, son solo una forma artificial de verlo. Con esto no estoy despreciando a las matemáticas, cuyas soluciones son ampliamente utilizadas en física y química para modelar fenómenos reales y ayudan a entender el mundo real. Solo estoy afirmando que, por sí solas, no ayudan a entender el mundo. Y en efecto el 1, por sí solo, no ayuda a entenderlo, si no se le asignan unidades de medida.
Por ej, imaginemos que 1 significa “un pimiento”. Entonces “un pimiento más un pimiento” son “dos pimientos”. Esta es la solución natural *2, lo que parece reforzar a la solución *1.
Si imaginamos que el primer 1 significa “un pimiento” y el segundo 1 significa “un tomate”, la respuesta de “un pimiento más un tomate”, en el mejor de los casos, podría valer “una ensalada”, y, si además de trocearlos los pones en una olla y los cueces, podría valer “una menestra”, o un “pisto” (no es “una enfritada”, porque no lleva aceite). Esta es la solución natural *3, que es una evidencia de que 1+1=1, en total desacuerdo con la disciplina matemática al tiempo que debilita la solución *1.
Ahora, por ej. Imaginemos que el primer 1 significa “un pimiento” y que el segundo 1 significa “una cafetera”. La respuesta a la pregunta “un pimiento más una cafetera” no es una solución natural, ya que no existe nada en la naturaleza que sea equivalente a la suma de un pimiento más una cafetera. Igual pasa con “un pimiento más un melón”, “un pimiento más un jamón”, “un pimiento más un grano de arroz”, más allá de una serie de recetas sin interés gastronómico. Lo que demuestra que existen unidades de medida que desembocan en problemas sin solución.
Digo sin solución, aparte de la obvia o canónica, que es la de dejar la operación indicada y sin efectuar, tipificada en general como “una unidad de A más una unidad de B”, con A ampliamente distinto de B. Lo de “ampliamente” es para conseguir una amplia distinción y evitar que este problema sin solución tenga una solución del tipo amalgama-menestra-pisto.
Para no extenderme más, ya puedo concluir que 1+1, en realidad, no está totalmente definido.
O dicho de otro modo, 1+1 no es nada. Aquí es donde me viene el recuerdo de la película Cortocircuito, más datos, ... más datos....
-
José Antonio Rojas Delgado (http://www.rojasdelgado.com)
08/05/2024 18:17:34
miércoles, 08 de mayo del año de N.S. 2024jard: MIS CONVERSACIONES CON UNA INTELIGENCIA ARTIFICIAL: REQUERIMIENTOS VS REQUISITOS
Usted
requerimientos vs requisitos
.- "Requerimientos" y “requisitos” son dos términos que a menudo se utilizan en contextos similares, pero tienen significados distintos:
Requisito: Se refiere a una 'circunstancia o condición necesaria para algo’1. En el contexto del desarrollo de software, los requisitos son una descripción de lo que debe hacer un software
Requerimiento: Es la acción de requerir, que a su vez es ‘intimar, avisar o hacer saber algo con autoridad pública’, ‘reconocer o examinar el estado en que se halla algo’ o ‘necesitar’, entre otras cosas
En el contexto del desarrollo de software, los requerimientos son una especificación de cómo debe hacerse el software
En resumen, los requisitos describen el ‘qué’, mientras que los requerimientos describen el 'cómo’
Usted
cuando una autoridad pública de la Administración del Estado envía al ciudadano administrado un requerimiento no le está diciendo cómo tiene que hacer algo, sino que le está demandando un documento, que tiene que conseguir el administrado, y que tiene que enviar el administrado como subsanación al requerimiento, para que el procedimiento administrativo continue. Por tanto esto que se llama formalmente REQUERIMIENTO en la ley del procedimiento administrativo, no describe ningún CÓMO
.- Tienes toda la razón. En el contexto de la administración pública y la ley del procedimiento administrativo, un requerimiento es una solicitud formal hecha por una autoridad a un ciudadano para que proporcione cierta información o documentos necesarios para el procedimiento administrativo. No describe el ‘cómo’, sino que es una demanda de ‘qué’ se necesita para continuar con el procedimiento. Mis disculpas por cualquier confusión anterior y gracias por tu aclaración.
Usted
por tanto la diferencia entre requerimiento y requisito no está basada en qué o en cómo. Vuelve a responder a la pregunta: "requerimiento vs requisito"
.- Mis disculpas por la confusión anterior. Tienes razón, la diferencia entre “requerimiento” y “requisito” no se basa en el ‘qué’ o el ‘cómo’. Aquí te dejo una explicación más precisa:
Requisito: Es una 'circunstancia o condición necesaria para algo’. Es decir, es algo que se necesita o se exige para poder realizar o conseguir algo.
Requerimiento: Es la acción de requerir, que puede ser ‘intimar, avisar o hacer saber algo con autoridad pública’, ‘reconocer o examinar el estado en que se halla algo’ o ‘necesitar’, entre otras cosas
En el contexto de la administración pública, un requerimiento es una solicitud formal hecha por una autoridad a un ciudadano para que proporcione cierta información o documentos necesarios para el procedimiento administrativo.
Por lo tanto, un “requisito” es algo que se necesita o se exige, mientras que un “requerimiento” es la acción de pedir o solicitar algo2. Espero que esta explicación sea más clara. ¡Gracias por tu paciencia!
Usted
define qué es un requerimiento en el contexto de la administración pública, empleando para ello la palabra "requisito"
.- En el contexto de la administración pública, un requerimiento es una solicitud oficial emitida por una autoridad a un ciudadano para cumplir con un requisito específico. Este requisito puede ser la presentación de ciertos documentos o información necesaria para continuar con un procedimiento administrativo. Por lo tanto, el requerimiento es el medio por el cual se comunica la necesidad de cumplir con un requisito. Espero que esto aclare tu duda. ¡Gracias por tu pregunta!
Usted
cuando preguntaba "requerimiento vs requisito" esperaba que tu respuesta fuera: REQUERIMIENTO ES EL MEDIO FORMAL POR EL QUE SE COMUNICA LA NECESIDAD DE CUMPLIR UN REQUISITO.
.- Mis disculpas por la confusión anterior. Tu definición es precisa y concisa. Entonces, para aclarar:
Requerimiento es el medio formal por el que se comunica la necesidad de cumplir un requisito.
Gracias por tu paciencia y por ayudarme a proporcionar una definición más precisa.
Usted
Todo correcto y de acuerdo hasta aquí, deduciéndolo dentro del contexto de la administración pública, ya que en la ley del procedimiento administrativo aparece explícitamente el concepto de Requerimiento. Ahora, sabiendo lo anterior, quiero que respondas a "requerimiento vs requisito" en el contexto de desarrollo de software.
.- En el contexto del desarrollo de software, “requerimiento” y “requisito” a menudo se utilizan de manera intercambiable, pero pueden tener matices diferentes dependiendo del contexto:
Requisito: En el desarrollo de software, un requisito es una característica que debe cumplir un producto1. Los requisitos del software son las funciones, características y restricciones que el sistema debe cumplir para satisfacer las necesidades de los usuarios y las partes interesadas. Los requisitos pueden ser funcionales (lo que el software debe hacer) o no funcionales (cómo debería funcionar el software).
Requerimiento: En el desarrollo de software, un requerimiento puede referirse a una función que debe realizar el producto1. Los requerimientos pueden dividirse en requerimientos de usuario (las funciones que el usuario final espera que el software realice) y requerimientos de sistema (las funciones que el software debe realizar para satisfacer los requisitos no funcionales).
Por lo tanto, en el desarrollo de software, un “requisito” generalmente se refiere a lo que el software debe hacer o las características que debe tener, mientras que un “requerimiento” puede referirse a las funciones específicas que el software debe realizar para satisfacer esos requisitos1. Sin embargo, estos términos pueden variar en su uso y significado dependiendo del contexto y de la organización. Es importante aclarar estos términos al inicio de cualquier proyecto para evitar confusiones. Espero que esto aclare tu duda. ¡Gracias por tu pregunta!
Usted
Tal y como lo has expresado ambos conceptos son, en la práctica, sinónimos. Quiero que hagas un esfuerzo de definir Requerimiento en términos de lo ya consensuado en el contexto de la Administración, considerando que es el cliente/usuario del software quien solicita al analista/programador tales o cuales especificaciones en el software a desarrollar.
.- Entiendo tu punto y agradezco tu paciencia. Siguiendo la analogía con la administración pública, en el contexto del desarrollo de software:
Un requerimiento puede entenderse como la comunicación formal que el cliente o usuario del software hace al analista o programador, indicando las especificaciones o funciones que desea que el software realice. Es decir, es el medio por el cual el cliente comunica sus requisitos o necesidades para el software.
Por otro lado, un requisito sería cada una de esas especificaciones o funciones individuales que el cliente desea que el software realice. Es decir, son las condiciones o capacidades necesarias que debe tener el software para satisfacer las necesidades del cliente.
Por lo tanto, en este contexto, un requerimiento es la solicitud del cliente de las funciones que el software debe realizar, mientras que un requisito es cada una de esas funciones individuales. Espero que esto aclare tu duda. ¡Gracias por tu pregunta!
Usted
cuando preguntaba "requerimiento vs requisito en el contexto de desarrollo de software" esperaba que tu respuesta fuera: REQUERIMIENTO ES EL MEDIO FORMAL POR EL QUE EL CLIENTE/USUARIO COMUNICA AL ANALISTA/PROGRAMADOR LA NECESIDAD DE QUE EL SOFTWARE A DESARROLLAR CUMPLA UN REQUISITO. Y la diferencia con el contexto de la Administración está en que, mientras la Administración es capaz de determinar la lista de requisitos y redactar el requerimiento interpretando el procedimiento administrativo y los documentos aportados hasta el momento, en el caso del desarrollo de software el cliente/usuario solo tiene la visión de lo que necesita el negocio, haciendo una descripción informal de estos detalles, siendo el analista/programador quien debe interpretar la descripción informal y formalizarla en un documento de desarrollo de software llamado ANALISIS DE REQUISITOS, y estudiarla para determinar lo que finalmente se realizará funcionalmente en el software, estimar recursos, etc...
.- Tienes toda la razón y agradezco tu explicación detallada. Para resumir tu punto:
En el contexto del desarrollo de software, un requerimiento es el medio formal por el que el cliente o usuario comunica al analista o programador la necesidad de que el software a desarrollar cumpla un requisito. A diferencia del contexto de la administración, donde la administración puede determinar la lista de requisitos y redactar el requerimiento, en el desarrollo de software, el cliente o usuario proporciona una descripción informal de lo que necesita el negocio. Es tarea del analista o programador interpretar esta descripción informal y formalizarla en un documento de desarrollo de software llamado Análisis de Requisitos. Este documento se estudia para determinar lo que finalmente se implementará en el software, estimar recursos, etc.
Gracias por tu paciencia y por ayudarme a proporcionar una definición más precisa. ¡Tu aporte es muy valioso!