Mostrando entradas con la etiqueta DSN_XP. Mostrar todas las entradas
Mostrando entradas con la etiqueta DSN_XP. Mostrar todas las entradas

DSN_XP y Tales de Mileto

Filosofía natural


Tales de Mileto fue un pensador revolucionario que, a través de su búsqueda de un principio único y su confianza en la razón, sentó las bases del pensamiento científico. Su legado perdura hasta nuestros días y nos recuerda la importancia de la observación, la razón y la búsqueda de leyes universales para comprender el mundo que nos rodea.

DSN_XP realiza esta investigación en su afán por entender al método y la necesidad de experimentar con las diversas herramientas y los distintos artefactos que se utilizan para tal objetivo.

El arjé: El origen de todo

Tales de Mileto propuso que el agua era el _arjé_ , es decir, el principio originario de todas las cosas. Esta idea, aunque hoy parezca simplista, fue revolucionaria para su época. Al buscar un principio único, Tales estaba dando los primeros pasos hacia una explicación racional del universo, alejándose de las mitologías dominantes.

DSN_XP conceptúa que, al tratar de sistematizar el todo, se requieren estructuras mentales que permitan capturar los detalles del escenario observado, en este caso, la idea de un principio único comienza a ser descartada por la presencia de la noción de perspectivas, razón por la cual se ve la necesidad de un pensamiento inverso como principio de observación para el diseño de la herramienta o artefacto que se utilizará para lograr describir los detalles del escenario desarmado.

La observación de la naturaleza

Tales de Mileto era un gran observador de la naturaleza. Sus conocimientos en astronomía le permitieron predecir un eclipse solar, lo cual era un logro impresionante para su tiempo. Su interés por los fenómenos naturales lo llevó a buscar explicaciones racionales, sentando las bases del método científico.

DSN_XP comienza a experimentar con estos conceptos, de forma específica con el proceso de observación que más tarde daría paso a la idea de Perspectivas DSN_XP

La importancia de la razón

Tales de Mileto valoraba la razón como la herramienta para comprender el mundo. Creía que a través del pensamiento lógico se podían encontrar las respuestas a las grandes preguntas sobre la naturaleza.

Esta confianza en la razón es un pilar fundamental del pensamiento científico.

Relación con el pensamiento científico

Ruptura con la mitología

Tales de Mileto fue uno de los primeros en intentar explicar el mundo a través de la razón, en lugar de recurrir a mitos y dioses. Esta ruptura con la mitología es un paso esencial para el desarrollo del pensamiento científico.

Búsqueda de leyes universales

Al proponer que el agua era el principio de todo, Tales estaba buscando una ley universal que explicara la diversidad de la naturaleza. Esta búsqueda de leyes universales es un rasgo característico del pensamiento científico.

Importancia de la observación y la experimentación

Aunque no se tiene mucha información sobre sus métodos, es evidente que Tales se basaba en la observación de la naturaleza para formular sus teorías.

La observación y la experimentación son fundamentales para el método científico.

DSN_XP concuerda con este argumento y lo transforma en el corazón de su método dual para la observación de diversos escenarios, lo que más tarde, daría paso a la necesidad de una estructura mental triple o triada que pueda contextualizar el resultado de la perspectiva aplicada a la observación en curso.

Legado 

Padre de la filosofía natural

Tales de Mileto es considerado el primer filósofo natural, ya que fue uno de los primeros en intentar explicar el mundo a través de la razón y la observación.  Su trabajo sentó las bases para el desarrollo de la filosofía y la ciencia en Grecia.

para DSN_XP, su legado consiste en reconocer tanto a la observación como a la experimentación, como los componentes base para la definición de una técnica o artesanía, que utilizaríamos tanto en el estudio del método o en el estudio de la Ingeniería de Software.


DSN_XP y René Descartes

Desentrañando el Método Detrás del Método

Introducción

René Descartes, el filósofo y matemático francés, revolucionó la forma en que concebimos el conocimiento con su _Discurso del Método_. Al proponer un método de duda metódica y análisis riguroso, Descartes sentó las bases de la filosofía moderna y el pensamiento científico. Pero, ¿Qué relevancia tiene este método en el contexto actual de la innovación y el desarrollo de metodologías como DSN_XP?

Descartes y su Búsqueda de la Verdad


Descartes, insatisfecho con las verdades establecidas de su época, emprendió una búsqueda incansable por un conocimiento fundamentado. Su método se basó en cuatro reglas fundamentales:

  1. Evidencia: Solo aceptar como verdadero aquello que se presenta a la mente con claridad y distinción.
  2. Análisis: Dividir las dificultades en tantas partes como sea necesario para resolverlas mejor.
  3. Síntesis: Proceder de lo más simple a lo más complejo, reconstruyendo el conocimiento paso a paso.
  4. Enumeración: Realizar revisiones exhaustivas para asegurar que nada se ha omitido.

Descartes y el Escenario de su Tiempo

Descartes vivió en un momento de grandes cambios intelectuales. La Reforma protestante, la invención de la imprenta y el desarrollo de las ciencias naturales desafiaban las creencias y los métodos tradicionales. En este contexto, Descartes buscó un método universal que permitiera alcanzar la certeza en cualquier campo del conocimiento.

El Proceso de Argumentación de Descartes

Descartes comenzó dudando de todo lo que podía ser puesto en duda, incluso de la existencia del mundo exterior. Sin embargo, llegó a la conclusión de que la duda misma era una prueba de su existencia como ser pensante: "Pienso, luego existo". A partir de este principio fundamental, reconstruyó su conocimiento de manera sistemática.

DSN_XP: Un Método para Estudiar Métodos

DSN_XP en su versión 0.1, como marco metodológico, se presenta como un meta-método, es decir, un método para estudiar y comparar otros métodos. Al igual que Descartes, DSN_XP busca establecer principios fundamentales y reglas claras para guiar la investigación y el desarrollo.

¿Cómo se relaciona DSN_XP con el método cartesiano?

  • Duda metódica: DSN_XP fomenta la crítica y la evaluación constante de las metodologías existentes.
  • Análisis: DSN_XP descompone los métodos en sus componentes básicos para comprender su funcionamiento.
  • Síntesis: DSN_XP permite construir nuevas metodologías a partir de la combinación de elementos de diferentes enfoques.
  • Enumeración: DSN_XP promueve la exhaustividad en la revisión y comparación de métodos.

Conclusión

DSN_XP y el método cartesiano comparten una misma aspiración: la búsqueda de la verdad a través de un método riguroso y sistemático. Al estudiar y aplicar DSN_XP, los profesionales pueden desarrollar una comprensión más profunda de los métodos que utilizan y, en última instancia, mejorar la calidad de sus resultados.

DSN_XP y Sprint cero

DSN_XP y el Sprint Cero: Una combinación potencialmente efectiva

Sprint Cero
Si estás leyendo esta entrada, entonces asumimos que conoces sobre DSN_XP, si no lo haces, este es un pequeño resumen de nuestro marco de trabajo para la adquisición de conocimientos.

¿Qué es DSN_XP?


DSN_XP, o Diseño de Soluciones a Necesidades por Experimentación, es un marco de trabajo que busca simplificar el diseño de un esfuerzo durante un ciclo de tiempo destinado para lograr un objetivo, enfocándose en soluciones claras y fáciles de entender. Combina los principios del diseño simple con las prácticas de Extreme Programming (XP) para crear diseños de alta calidad de manera ágil.

Características clave de DSN_XP:

Simplicidad: Prioriza diseños claros y concisos, evitando la complejidad innecesaria.
Adaptabilidad: Se adapta a los cambios de los requisitos del proyecto a medida que avanzan.
Colaboración: Fomenta la comunicación y la colaboración entre los miembros del equipo.
Pruebas continuas: Incorpora pruebas unitarias y de aceptación para asegurar la calidad del código.

¿Qué es el Sprint Cero?

El Sprint Cero es un concepto que, aunque no está definido formalmente en Scrum, se utiliza a menudo para referirse a un período de tiempo antes del primer Sprint oficial. Durante este período, se realizan actividades de preparación y planificación fundamentales para el éxito del proyecto.

Objetivos del Sprint Cero:

Configuración del entorno: Se establece el entorno de desarrollo, las herramientas y los procesos necesarios.
Definición de la arquitectura: Se establece una arquitectura inicial para el proyecto.
Refinamiento del Product Backlog: Se definen y priorizan las primeras historias de usuario.
Planificación: Se crea un plan inicial para los primeros Sprints.

Combinando DSN_XP y Sprint Cero

La combinación de DSN_XP y Sprint Cero puede ser especialmente beneficiosa en proyectos ágiles, ya que ambas se centran en la simplicidad, la adaptabilidad y la colaboración.

Beneficios potenciales:

Inicio más sólido: El Sprint Cero proporciona una base sólida para el proyecto, asegurando que el equipo esté preparado para comenzar a desarrollar el proyecto.
Diseño más simple: DSN_XP ayuda a mantener el diseño de la solución de manera simple y fácil de entender, lo que facilita los cambios y las mejoras a lo largo del proyecto.
Mayor calidad: Las prácticas de XP, como las pruebas continuas y la refactorización, ayudan a garantizar la alta calidad del diseño.
Mayor eficiencia: Al enfocarse en las tareas más importantes y evitar la complejidad innecesaria, el equipo puede ser más eficiente.

Cómo combinarlas:

  • Utilizar el Sprint Cero para establecer los principios de DSN_XP: Durante el Sprint Cero, se pueden definir los principios de diseño simple y natural que se seguirán en el proyecto.
  • Aplicar las prácticas de XP en todos los Sprints: Las prácticas de XP, como las pruebas unitarias, la programación en parejas y la integración continua, se pueden aplicar desde el primer Sprint para asegurar la calidad del diseño.
  • Refactorizar regularmente: El diseño se debe refactorizar regularmente para mantenerlo simple y fácil de entender.
  • Fomentar la colaboración: La comunicación y la colaboración entre los miembros del equipo son fundamentales para el éxito de DSN_XP.

En Conclusión

La combinación de DSN_XP y Sprint Cero puede ser una estrategia eficaz para desarrollar proyectos de alta calidad de manera ágil. Al simplificar el diseño, enfocarse en las tareas más importantes y fomentar la colaboración, los equipos pueden entregar acciones de mayor valor a sus clientes.

En la práctica, utilizamos Sprint Cero al inicio de año, de manera específica entre la fase de transición del 31 de diciembre al primero de enero del siguiente año, esto nos permite:
  • Mapear todas las actividades repetitivas del año y definirlas en la calendarización del año por planificar.
  • Mapear todas las restricciones de carácter obligatorio que se deben considerar el mitigar o controlar durante el nuevo año.
  • Facilitar la transición de aquellos esfuerzos que no fueron realizados en el período anterior y su integración al nuevo esfuerzo de la planificación anual.
  • Capacitar e igualar ideas y conocimientos sobre el objetivo y  posibles metas a realizarse durante el ciclo del nuevo esfuerzo.
¡SI! Debemos tener la meta final en mente. Pero no pospongamos el inicio hasta comprender el final. Inspección y Adaptación. Sea que sea lo que hagamos, la meta va a cambiar por todo lo que aprenderemos en el camino.

DSN_XP y el proyecto ALEPH

 ALEPH_XP

Proyecto de desarrollo de software en modalidad Open Source
DSN_XP necesitaba ser implementada para lograr adaptar sus artefactos hacia la condición principal de uso que trataba sobre el desarrollo de tesis de grado que implican a su vez el desarrollo de un producto de software.

Desarrollo de software como tesis de grado

Este es un proyecto que no logró concretarse pero implicó un esfuerzo previo de nuestra parte para lograr determinar el contexto de usabilidad de nuestra metodología como marco de referencia teórico para el desarrollo de nuestra segunda propuesta de tesis de grado.

Dado que estábamos teniendo experiencia en el diseño de estudios de ingeniería para la solicitud de frecuencias ante la Superintendencia de Telecomunicaciones del Ecuador, pensamos en compartir este conocimiento para convocar a otros para que se sumen al desarrollo de la versión básica de uso como un aplicativo disponible para la comunidad.
Propuesta inicial del desarrollo de tesis

El modelo Open Source

Una de las rebeldías que nos quedó de la no autorización a nuestra primera propuesta de desarrollo de tesis, fue el confrontar la propiedad intelectual de código fuente entre la universidad y nuestra empresa, la cual patrocinaba los estudios superiores para la ingeniería en sistemas.
Pero no teníamos la remota idea de cómo lograr desarrollar nuestro código y a la vez aplicar nuestro método de investigación para el desarrollo de software en Ecuador.
Sabíamos hasta ese momento que las metodologías no eran consideradas dentro del modelo de desarrollo de software a la hora de realizar las tesis de grado, en segunda instancia, se consideraban los criterios de diseño que se aplican a un lenguaje de programación para el desarrollo de una aplicación programada mediante la tecnología para la implementación del software.

Si usábamos código fuente de terceros, existía la posibilidad de ser encarados como faltos de criterio de diseño, que era una de las cualidades a ser consideradas a la hora de evaluar el desarrollo del aplicativo como tesis.

El término de código abierto se refiere a la capacidad de modificar y compartir el código mediante un acceso público para su reutilización por terceros.

DSN_XP había estudiado en su base de conocimientos a varios modelos de desarrollo de software y había observado de primera mano al modelo codificar y corregir, pues lo habíamos experimentado durante nuestra formación académica.

Al profundizar esta observación, teníamos que cotejar este modelo con el modelo propuesto para el desarrollo de tesis, ya que, efectivamente, casi todos los estudiantes que formaron parte de nuestro estudio de acompañamiento para el desarrollo del software de sus tesis y el marco teórico de las mismas, utilizaban el modelo codificar y corregir usualmente en el desarrollo personalizado de la tesis.

Esto significaba otro descubrimiento, ya que al codificar se supone se interponen en un proceso de diseño mental, tanto el análisis como el diseño base aprendido en clases, para poder replicar el algoritmo y los controles y eventos que son capturados en el proceso de abstracción de la solución planteada a un problema específico de desarrollo.

Por otro lado, al poner en ejecución el código programado, se encontraban errores tanto en el algoritmo por no lograr entender el escenario técnico proyectado a codificar y el dominio del lenguaje de programación y la algoritmia de solución de problemas por pasos sucesivos.

DSN_XP y REDD

REDD+ Ecuador

Proyecto de ingeniería inversa al modelo propuesto para Ecuador

Ministerio de Ambiente EC

Este es un proyecto pequeño para el entendimiento de la plataforma tecnológica para el soporte de programas de política pública como parte de un proceso INCEPTION que se deseaba establecer con el Ministerio de Ambiente del Ecuador.

Contexto de uso

La idea consistía en poder entender a un nivel mayor de profundidad al proyecto REDD+ para la integración a la plataforma tecnológica para soporte de programas de política pública. 

Par lograr este nivel de profundidad, era necesario establecer una investigación temática para ubicar en el contexto de mayor perspectiva que permita comprender a un nivel macro (debido a la coyuntura regional del programa de política pública), el escenario de uso en el cual se invertirán una serie de esfuerzos para efectos de cumplir con la política pública y los compromisos internacionales.

Ahora bien, por tratarse de un tema tecnológico que involucra el desarrollo de esfuerzos locales para lograr integrarse tanto a nivel del programa de política pública como a nivel de tecnología aplicada para transferencia de reportes de avance del programa de política pública.
Diseño conceptual de integración de competencias organizacionales participantes

Monitoreo de bosques

DSN_XP aplica conceptos de permacultura en sus diseños relacionados con la naturaleza y los contextos de la política pública para los recursos naturales.
Dado que no se trataba de un proyecto de consultoría específica en el cual aplicar DSN_XP, nuestro trabajo consistía en modelar mediante un portafolio técnico documental, todos aquellos aspectos relacionados con el monitoreo de bosques y su integración con los macro esfuerzos de la FAO, quien brinda apoyo a más de 40 países para la creación y evaluación del solidez del Sistema Nacional de Seguimiento Forestal (SNSF), con el fin de generar los recursos informativos forestales, cuya fiabilidad pueda ser referida en el diseño de las acciones que dan soporte a los diversos componentes del programa de política pública del Ecuador.
Los sistemas nacionales deben apoyar a la planificación sostenible del programa y sus proyectos, de tal forma que su desarrollo incluya funciones de medición, notificación y la producción de un conjunto de datos fiables y de alta calidad sobre los bosques, incluyendo estimaciones de carbono forestal, quie son críticas en la batalla contra el cambio climático derivado dela deforestación y de la degradación de los bosques.

Sistema Nacional de monitoreo de bosques

El Código Orgánico Ambiental establece que el Ministerio tiene las competencias sobre el monitoreo de la deforestación, de los ecosistemas y la actualización del inventario nacional forestal, el cual reglamenta esta competencia a través del capítulo sobre el monitoreo y evaluación del patrimonio forestal nacional.

Existe un reglamento en el cual se esclarecen tanto el:
  • Alcance y objetivos.
  • Ámbito y principios de acción
  • Componentes del sistema de monitoreo
    • Políticas públicas y Actores
    • Componentes 
    • Metodologías y procesos
Es a través de este esquema que se genera, recopila, analiza y reporta información del tipo espacial, biofísica y socioeconómica relacionada con los bosques, otros ecosistemas naturales y su biodiversidad asociada.

DSN_XP y su prototipo conceptual

Escenario macro que contextualiza la visión del diseño requerido por la FAO
Nota: Los detalles de menor nivel del diseño no son mostrados en esta entrada debido a criterios de propiedad intelectual y criterios de respeto para nuestros clientes.

DSN_XP y las perspectivas

 Enfoque basado en perspectivas

El uso de perspectivas en la aplicación de DSN_XP

DSN_XP entra en contacto con la noción de perspectivas cuando estábamos estudiando el paso desde la ingeniería de software hacia la arquitectura de software. Luego fuimos notando que, por cada nuevo escenario de investigación y por ende por cada actor y patrocinador que colaboraba en ese escenario se podía establecer un conjunto de múltiples perspectivas para lograr mapear el objetivo que investigábamos.

Tres perspectivas en un mismo enfoque 

DSN_XP en el estudio del desarrollo de software en Ecuador, logró identificar que en un posible escenario de uso, tres fuerzas participaban dentro de dicho contexto y que a cada fuerza le correspondía un enfoque específico de uso que lo diferenciaba de los otros dos.
Perspectivas DSN_XP
Bajo el enfoque de perspectivas múltiples, la perspectiva técnica (T) estaría representada por el SoftwareView, mientras que la perspectiva organizacional (O) estaría representada por el BusinessView y finalmente el proceso creativo y de transferencia tecnológica sería cubierto por el TeamView representado la perspectiva personal (P).
El concepto de perspectiva múltiple por Harold A. Linstone

Historia del método

Las raíces del enfoque de perspectiva múltiple tienen dos vertientes: los veinte años de experiencia del autor en la industria aeroespacial, específicamente en la planificación corporativa y el libro de Graham Allison de Harvard, Essence of Decision: Explaining the Cuban Missile Crisis.[1]

El poder y el éxito de la visión "técnica" del mundo y su valor para producir percepciones notables y predicciones excelentes en ciencia e ingeniería siguen siendo incuestionables. Su extensión más allá de sus fronteras es, por tanto, comprensible. 

La economía y las ciencias sociales se han esforzado por adoptar los mismos paradigmas. Las impresionantes herramientas desarrolladas, particularmente desde la Segunda Guerra Mundial, bajo etiquetas tales como investigación de operaciones, análisis de sistemas; Linstone había visto que su análisis y modelado para la toma de decisiones corporativas solo tomaba en cuenta algunos de los factores vitales en el proceso de decisión corporativa y el trabajo de Allison examinaba la crisis de los misiles desde tres puntos de vista diferentes, actor racional, proceso organizacional y política burocrática. Cada uno proporcionó conocimientos que no se pueden obtener con los demás.

A partir de 1977, el desarrollo de este enfoque y aplicación a la gestión de la tecnología condujo eventualmente al libro Multiple Perspectives for Decision Making en 1984.[2] 

En 1999 se publicó una versión actualizada, Toma de decisiones para ejecutivos de tecnología: uso de múltiples perspectivas para mejorar el rendimiento.[3]
Nota: DSN_XP todavía no analiza estos libros referenciados.

Descripción del método

Este método considera tres tipos de perspectivas utilizadas en este enfoque:

Perspectiva Técnica

La ciencia y la tecnología representan la "religión" más exitosa de los tiempos modernos. Desde Galileo hasta el alunizaje tripulado del Apolo, desde Darwin hasta el ADN recombinante, sus métodos han arrojado triunfos deslumbrantes. 

Forman el paradigma de la perspectiva técnica. La visión del mundo T se caracteriza por las siguientes características:
  • Los problemas se simplifican mediante la abstracción, la idealización y el aislamiento del mundo real que nos rodea. Existe el supuesto implícito de que los procesos de reducción y simplificación permiten la "solución" de los problemas
  • Los datos y los modelos comprenden los componentes básicos de la investigación. Se presuponen igualmente la lógica y la racionalidad, así como la objetividad. Se busca el orden, la estructura y la cuantificación siempre que sea posible. La observación y la construcción de modelos, la experimentación y el análisis suelen estar destinados a mejorar la capacidad predictiva. Se espera la validación de hipótesis y replicabilidad de observaciones y experimentos. Se valora especialmente la consecución de modelos elegantes y soluciones mejores u óptimas.
El enfoque funciona bien para aquellos problemas más allá de la ciencia y la ingeniería que son dóciles o bien estructurados. Algunos ejemplos son la gestión de inventario de fábricas o bancos de sangre, la ubicación óptima del sitio de la estación de bomberos urbana, la programación de líneas aéreas y el precio de los asientos y el análisis económico de entrada y salida. Sin embargo, tropieza con graves problemas cuando se aplica a sistemas sociotécnicos donde los seres humanos, individual y colectivamente, juegan papeles importantes. 

Un ejemplo clásico es la conocida aplicación de Jay Forrester del MIT de su dinámica de sistemas a la corporación (Industrial Dynamics), la ciudad (Urban Dynamics) y el mundo (World Dynamics). Las propias palabras de Forrester reflejan el autoengaño de los ingenieros:
Todos los sistemas que cambian a lo largo del tiempo se pueden representar usando solo niveles y tasas. Los dos tipos de variables son necesarios, pero al mismo tiempo suficientes, para representar cualquier sistema.[4]
El modelo de dinámica mundial usó cinco variables: población, producción industrial, recursos naturales, producción agrícola y contaminación, ¡para construir un modelo de computadora y ejecutarlo hasta el año 2100!
Siendo humanos, los modeladores sucumben al fenómeno Pigmalión. El rey escultor de la mitología griega creó una hermosa estatua de una niña y luego se enamoró de ella. En respuesta a su súplica, la diosa Afrodita le dio vida a la estatua y Pigmalión se casó con su modelo.
Los modeladores de hoy, hipnotizados por la capacidad de las computadoras modernas para dar vida a sus modelos, también se enamoran de sus creaciones. Los modelos se han convertido en realidad para ellos.

Tal vez la manifestación más llamativa de los últimos años sea la seducción generalizada de Wall Street por parte de los “quants”, matemáticos que construyen modelos informáticos sofisticados para administrar el dinero con el fin de obtener el máximo beneficio.
Una forma obvia de evitar tomar un solo modelo demasiado en serio es usar varios modelos en lugar de uno. 
Esto también ayuda a superar las limitaciones siempre presentes en cualquier modelo, como límites artificiales, suposiciones injustificadas y simplificaciones excesivas. 

Los modelos múltiples se usan comúnmente dentro del ámbito de la perspectiva T. En la física clásica, es de gran valor usar modelos de luz tanto de ondas como de partículas, tanto universos newtonianos como einsteinianos para la mecánica. En el desarrollo de aeronaves, el ingeniero de proyectos, el ingeniero aeronáutico, el ingeniero electrónico, el constructor de motores, el diseñador de interiores y el analista de mercado, todos miran la misma aeronave usando distintas perspectivas T. En representación de diferentes disciplinas, utilizan diferentes modelos y datos. Sin embargo, todos operan con los mismos paradigmas T.
Debemos distinguir claramente dos funciones de los modelos (una predicción; la capacidad de hacer predicciones a partir de un modelo matemático, y (b) explicación o comprensión; una ayuda de pensamiento abstracto, que revela o ilumina algún aspecto del comportamiento del sistema de una manera simple o desbloquea una idea.
Las habilidades de la ciencia en el modelado de sistemas se pueden ilustrar de la siguiente manera:
  • Excelente explicación y excelente predicción: mecánica celeste
  • Excelente explicación y mala predicción: biología evolutiva
  • Mala explicación y excelente predicción: mecánica cuántica
  • Mala explicación y mala predicción: economía. [5]
En el mundo práctico, con frecuencia nos interesa más un buen pronóstico que una buena explicación.
Pero, como explica Herbert Simon,
El rápido ascenso en la última década de la teoría del caos... ha mostrado las razones fundamentales por las que tal predicción puede ser imposible, ahora y para siempre. Estos están vinculados a la complejidad de muchos sistemas de interés. La naturaleza es capaz de construir, en una escala de microcosmos o macrocosmos o cualquier escala intermedia, sistemas cuya complejidad se encuentra mucho más allá del alcance de nuestras computadoras y supercomputadoras, presentes o futuras. [6]

O, como observa John Casti, la predicción requiere computabilidad y matemáticamente solo es computable un pequeño subconjunto de todas las funciones posibles. Por lo tanto, es plausible que las descripciones matemáticas de muchos fenómenos naturales o humanos sean intrínsecamente incomputables. Cuanto más susceptible es un sistema a la influencia humana, menor es su previsibilidad.[5] 

Perspectiva Organizacional

Los seres humanos son animales sociales supremos. Desde los albores de su existencia, se han organizado en grupos sociales y sociedades. El individuo renuncia a algunos de sus derechos y acepta responsabilidades a cambio de los beneficios que ofrece la pertenencia a un grupo u organización. En su forma más generalizada, tenemos la institución.

En la perspectiva del actor racional de Allison, el analista considera a "Estados Unidos" y "la Unión Soviética" como tomadores de decisiones unitarios, cada uno con objetivos nacionales y alternativas para la acción y deseoso de una elección racional que maximice el valor.

Su perspectiva de proceso organizacional reconoce que un gobierno no es monolítico, sino que está compuesto por organizaciones, cada una con sus propias prioridades y percepciones parroquiales. Por ejemplo, en el caso de la crisis de los misiles en Cuba, al principio fue desconcertante por qué el movimiento de misiles hacia Cuba estaba encubierto en secreto: se utilizaron todos los barcos cubanos madereros y se despejó el puerto cubano donde descargaban, mientras que la preparación y construcción sin camuflar de los sitios de misiles fue fácilmente identificable en las fotografías aéreas obtenidas por los vuelos de vigilancia estadounidenses U-2 sobre Cuba. El misterio se resolvió cuando quedó claro que la responsabilidad de las dos tareas se asignó a diferentes organizaciones soviéticas. La responsabilidad de los arreglos de seguridad de la entrega se le dio a dos agencias que practican el secreto como un procedimiento operativo estándar (SOP): el envío a la GRU, la inteligencia militar soviética y la autorización de seguridad portuaria a la KGB. Sin embargo, la preparación del sitio fue responsabilidad de los equipos de construcción de misiles tierra-aire del Comando de Defensa Aérea Soviética y siguieron sus propios SOP. Los sitios de misiles nunca habían sido camuflados en la Unión Soviética, por lo que no se pensó en cambiar el procedimiento en este caso. [1]
En ingeniería, encontramos que el riesgo tecnológico no puede entenderse puramente en términos técnicos, como el tiempo medio de falla del equipo y el análisis de probabilidad. 
La Comisión Kemeny sobre el accidente nuclear de Three Mile Island reconoció el papel central de los problemas humanos en la operación, gestión y supervisión gubernamental en la anatomía del accidente. El caso del derrame de petróleo de Alaska, discutido a continuación, ofrece evidencia abrumadora de la necesidad de ir más allá de la perspectiva T en la gestión del riesgo tecnológico.

La perspectiva organizacional se enfoca en el proceso más que en el producto, en la acción más que en la resolución de problemas. Las preguntas críticas son "¿hay que hacer algo y, de ser así, qué?" y "¿quién necesita hacerlo y cómo?" en lugar de "¿cuál es la solución óptima?" Debe haber un reconocimiento de que la imposición de soluciones de arriba hacia abajo bien puede fallar si no hay un apoyo "de abajo hacia arriba". En su estudio patrocinado por las Naciones Unidas sobre la degradación ambiental en el Himalaya, Thompson y Warburton concluyen que el enfoque de desarrollo clásico ha sido hacer sonar la alarma y luego decirle al país cuál es la solución, en otras palabras, el enfoque T.
No ha funcionado... porque ha ignorado (como si fuera un simple detalle de implementación) la estructura política, económica y cultural de fondo... Lo que se necesita es un enfoque más sensible, un enfoque que coloque "meros detalles" ––las instituciones que constituyen la estructura profunda––en el mismo centro del escenario... Hay, admitimos, una ruptura considerable entre el enfoque tradicional de problema único/solución única y el que hemos desarrollado aquí. Hay muchas maneras de caracterizar esta ruptura, pero quizás la mejor sea en términos del cambio que hace del pensamiento de producto al pensamiento de proceso. El marco de sistemas ya no es un modelo del problema sino simplemente un mecanismo de evaluación... Necesitamos más de una perspectiva. El abordaje a través de instituciones plurales y percepciones divergentes responde a esta necesidad. [7]
En la perspectiva O tratamos con el poder. No hay una búsqueda intensiva de herramientas analíticas; de hecho, a menudo se desconfía de las "técnicas académicas". Se las considera poco realistas o impredecibles e incontrolables. Puede sorprender al analista orientado a T que el organigrama típico es una guía deficiente con respecto al lugar geométrico de poder en las organizaciones.

El poder real no reside en los documentos y memorandos que describen sus términos de referencia y área de jurisdicción: reside en lo que puede lograr en la práctica el del jefe. El secretario puede ejercer un gran poder, como la amante del rey, sin ninguna autoridad en absoluto o al menos no del tipo que puedes mostrarle a cualquiera. [8]

En organizaciones que operan con tecnologías potencialmente peligrosas, una crisis puede cambiar instantáneamente la estructura de una organización jerárquica a una plana en la que el poder de los niveles anteriormente "bajos" se mejora y se iguala con el de los niveles anteriormente "altos".

El enfoque dialéctico característico de la perspectiva organizacional se refleja en la historia de los pronósticos de recursos energéticos en los Estados Unidos.[9] La profunda división entre los intereses industriales y los conservacionistas de los recursos de petróleo y gas ya era evidente a principios del siglo XX.  En 1908, el Servicio Geológico de EE. UU. (USGS, por sus siglas en inglés) pronosticó recursos petroleros totales de EE. UU. entre 10 y 24,5 mil millones de barriles e indicó que nos quedaríamos sin petróleo entre 1935 y 1943. En 1974, el USGS estimó reservas de petróleo entre 200 y 400 mil millones de barriles. Cada lado aprovechó estas estimaciones para confirmar su postura política. Se han hecho muchos pronósticos desde entonces y, excepto en los períodos de la Primera y Segunda Guerra Mundial, cada facción acusa habitualmente a la otra de manipular los pronósticos para sus propios fines. 

Perspectiva Personal

La perspectiva personal ve el mundo a través de un individuo único. Abarca aspectos que relacionan a los individuos con el sistema y no son captados por las perspectivas técnicas y organizacionales. El individuo puede hacer una diferencia crucial. Un líder efectivo puede imponer su perspectiva sobre la de sus seguidores y la organización, cambiando una corporación o una sociedad. El artista creativo y el líder carismático, el emprendedor y el inconformista están motivados principalmente por su propia perspectiva única.

Desde Pericles hasta Churchill, desde Lincoln hasta Martin Luther King, desde Thomas Watson de IBM hasta Bill Gates de Microsoft, las personas han proporcionado liderazgo. Desde Sócrates y su amor por la sabiduría hasta Rachel Carson y su enfoque en el medio ambiente, las personas han dado ejemplos. 
Las perspectivas de los líderes tienen cualidades únicas: son previsores y tienen una visión del futuro; son capaces de comunicar esa visión de manera efectiva a los demás y así obtener su apoyo; están dispuestos a asumir "apuestas difusas" y riesgos considerables.
Hace doscientos años, Adam Smith observó:

El hombre de sistema... parece imaginar que puede ordenar a los diferentes miembros de una gran sociedad con tanta facilidad como la mano coloca las diferentes piezas sobre el tablero de ajedrez; no considera que las piezas sobre el tablero de ajedrez no tengan otro principio de movimiento que el que la mano imprime sobre ellas; pero que, en el gran tablero de ajedrez de la sociedad humana, cada pieza individual tiene un principio de movimiento propio completamente diferente del que la legislatura podría decidir imprimirle.[10]

Causa y efecto es un paradigma explicativo fundamental de la perspectiva T. Como nos dice el cibernético Heinz von Foerster, es inoperante para explicar el comportamiento de los sistemas sociales. 
La ley que transforma la causa pasada en el efecto presente es cambiada por el mismo efecto que produce. Por lo tanto, no es muy predecible. De hecho, debemos aprender a ver cosas que no podemos explicar. Además, tenemos un punto ciego: no vemos que no vemos.[11]
Un rasgo singularmente personal es la intuición. Al discutir las invenciones en matemáticas, Jacques Hadamard escribe:
Ya es evidente que esas súbitas iluminaciones que pueden llamarse inspiraciones no pueden producirse por la sola casualidad... no cabe duda de la necesaria intervención de algún proceso mental previo desconocido para el inventor, es decir, de uno inconsciente. [12]

Más recientemente, el premio Nobel Herbert Simon y sus asociados exploraron las diferencias entre expertos y novatos en la resolución de problemas de física. Descubrieron que el experto se  guía mentalmente por un gran número de patrones que sirven como índice de partes relevantes del  almacén de conocimientos. Estos patrones son esquemas ricos que pueden guiar la interpretación y solución de un problema y agregar información crucial. Esta capacidad de usar esquemas indexados por patrones es probablemente una gran parte de lo que llamamos intuición física. [13]

Cada individuo tiene un conjunto único de patrones que informan su intuición. Al invocar la perspectiva P, estamos aumentando el proceso T consciente y lógico abriéndonos a los niveles mentales más profundos que almacenan patrones de gran valor potencial. Salk enfatiza específicamente la necesidad de cultivar los reinos intuitivo y de razonamiento, por separado y juntos.

De hecho, la evolución de la mente humana depende de esta relación binaria. [14] Por supuesto, los líderes empresariales siempre han apreciado el valor de la intuición.

Esta es una referencia utilizada por DSN_XP para el fortalecimiento de la versión 0.1 

Método de investigación DSN_XP

DSN_XP y la experimentación

 La experimentación en DSN_XP

Experimentación base
Un principio del método que dirige el proceso de diseño para DSN_XP radica en la experimentación con el modelo que fue diseñado para poder abstraer un contexto de usabilidad.

Experimentación

Nuestro contexto de experimentación, está íntimamente relacionado con el proceso de codificación y la racionalización mediante la algoritmia, para efectos de lograr crear una solución como sistema, utilizando los principios de cálculo y de modelado que el lenguaje de programación lo permita.

Fue la experimentación la única forma que encontramos para lograr desarrollar nuestras habilidades de programación, ya que no todos teníamos acceso al hardware necesario para un aprendizaje continuo.  

Debido a que, los programas que codificábamos eran sencillos en base a nuestra limitada comprensión de la semántica que se sujetaba al lenguaje de programación escogido para el efecto.

Parte del proceso de aprendizaje radica en la observación del código realizado por una fuente de conocimiento que estudiamos (tutor o libros o videos u observaciones al proceso de codificar de un tercero), por ello, es nativo para DSN_XP el pensamiento inverso o la capacidad de leer código de terceros para efectos de establecer un modelo de solución a problemas específicos por experimentación.

Prototipar

DSN_XP entiende por prototipar justamente al concepto que deseamos expresar como experimentación, ya que parte de la comprensión del lenguaje de programación radicaba justamente en trabajar con las ventajas que determinan la usabilidad de un lenguaje de programación, esto es programar una abstracción y la capacidad del dominio de la sintaxis del lenguaje de programación.

Ahora bien, el prototipado para nosotros podía tener varios contextos de uso y uno de ellos era justamente el utilizar el lenguaje de programación para generar una secuencia de eventos y así lograr un comportamiento por parte del sistema programado.

DSN_XP y Lean Inception

 Lean Inception


DSN_XP adopta como artefacto para la planificación de esfuerzos, a la noción de INCEPTION como aquel primer esfuerzo realizado en el proceso creativo de diseño de soluciones a necesidades mediante un producto o un proyecto.

Inception

Puede ser traducida como "comienzo" y es la etapa inicial que propone RUP para abordar un proyecto de desarrollo conforme al entendimiento mutuo de las partes por los objetivos y metas a ser alcanzados mediante un esfuerzo continuo en una  jornada de tiempo.

Ahora bien, RUP propone en su método de gestión de proyectos, 4 fases base para efectos de completar un ciclo y en base a la repetición del ciclo lograr abordar de forma incremental los diversos criterios necesarios para definir una arquitectura de software que pueda satisfacer las demandas esperadas del desarrollo de un proyecto para la entrega de un producto funcionando en base a la ingeniería del software.
Esquema estratégico de RUP por fases

Adoptamos el modelo de gestión de proyectos de TI propuesto por RUP para poder negociar con terceros el esfuerzo requerido para comprender la industria y la problemática del cliente y con ello poder realizar una aproximación al esfuerzo que puede ser encapsulado en una propuesta comercial, aunque el producto final no sea software o una solución basada en la ingeniería del software.

RUP como propuesta del proceso de un producto

DSN_XP en su versión 1.0 solo podía cubrir las etapas de diseño y análisis requeridas para desarrollar una tesis de grado que implique la ingeniería de software, como tal, estas fases debían ser sintetizadas y adoptadas como propuesta para el reglamento del régimen académico.

Adicionalmente, se requería adoptar UML como la herramienta de modelado que permitiría sintetizar la documentación requerida o una gran cantidad de texto que sería referido como marco teórico para efectos de plantear el modelo de gestión para el desarrollo del producto de tesis mediante las recomendaciones de un método de desarrollo reconocido en el mercado ecuatoriano.

Tomamos prestado entonces el esquema planteado y decidimos adoptar el enfoque LEAN para lograr controlar nuestra capacidad productiva durante una iteración en una jornada de tiempo corta para el desarrollo de soluciones en base a la experimentación.

Dicho esto, los flujos de trabajo que dan soporte a la propuesta INCEPTION y su configuración son:
  • Estudio del entorno de desarrollo dependiente de la capacidad del cliente y su participación en la industria.
  • Planteamiento de un esquema para la gestión del proyecto que determinará la propuesta comercial a ser revisada por el cliente.
  • La capacidad de delimitar al mínimo la gestión de cambios desde el cliente cuando no existe una visión profunda aceptada por las partes.
Ahora bien el proceso de desarrollo del producto o servicio requiere analizar las siguientes disciplinas, a saber:
  • Modelado del negocio y su cadena de valor para comprender su capacidad productiva.
  • Entendimiento de los requerimientos que configuran la negociación por entregables cubierta por la propuesta comercial.
  • Análisis y diseño base de la arquitectura inicial que dará soporte a todo el proceso productivo a ser implementado en fases posteriores.
  • Definición de los criterios de implementación y las pruebas de su acoplamiento.
  • Desarrollo de informes sobre el esfuerzo realizado durante la jornada contratada.

DSN_XP y la perspectiva interna

MYSELF

MINDSET

El denominado MINDSET es incompleto sin la presencia del sentido de estar aquí  y éste sólo es posible gracias a la noción de ahora, el resto del tiempo es procrastinar....

Un esfuerzo justo para estar presente pide una fuerza que sea consciente de la dirección que quiere tomar y que tenga la voluntad de actuar.  La atenión viene de todos los centros y debe estar aquí en una proporción justa y quedarse comprometida en tanto que se manifieste la Presencia consciente.

Pero esta atención de uno mismo (MySelf), está constantemente interrumpida por lo que la atrae hacia el exterior.  Es menester tomar consciencia de esta acción, de este deseo de moverse, de crear, de actuar...  Existe además el deseo de ser movido, de ser atraído, de obedecer...

Estas dos fuerzas están allí constantemente en nosotros, su confrontación voluntaria, en un punto determinado, puede producir una concentración de energía que tiene su propia vida independiente.
Es en la fricción entre esas dos fuerzas que se desarrolla la calidad que las reúne
Detrás de todas las vicisitudes, detrás de todas mis preocupaciones, mis penas o alegrías, hay algo más grande que puedo sentir, algo que me da un sentido..., pues siento que existo en relación con esa grandeza...

DSN_XP y el tablero de ideas

DSN_XP.Tablero



Necesitábamos un tablero de ideas para organizar formalmente los lineamientos propuestos por DSN_XP como escuela de pensamiento sobre el diseño de software en Ecuador.

Decidimos aplicar DSN_XP para hacer ingeniería inversa a DSN_XP como metodología de investigación científica del software.

La idea de crear un tablero como blog fue posible gracias a las sugerencias de varias personas que desean seguir nuestras ideas ya sea por curiosidad, porque les parece interesante, porque necesitan referencias, etc.

Tablero

  • Este blog está escrito en español porque toda la información técnica acerca del software usualmente suele estar escrita en inglés y es necesario para América Latina propagar el conocimiento en español :o)
  • Este blog está dedicado a publicar nuestras investigaciones (desde el año 2003) sobre la ingeniería de software y recopila todos aquellos comentarios teóricos que hemos publicado en varios sitios de la Internet, esperamos que nuestras investigaciones sean de apoyo para nuestros lectores y usuarios.

DSN_XP


  • DSN_XP es un marco de trabajo que originalmente fue creado para aplicar ingeniería inversa al diseño y desarrollo de software (esto es ingeniería de software)
  • Como el software se ha convertido en una herramienta fundamental para los negocios, por extensión también probamos que DSN_XP puede aplicarse para la ingeniería inversa al mundo de los negocios
  • Una vez que aplicamos DSN_XP tanto al diseño de software como al diseño de procesos del negocio, pudimos aplicar DSN_XP al estudio del comportamiento humano y el proceso del pensamiento en base al diseño de modelos (a esto lo denominamos como perspectivas)
DSN_XP como metodología (estudio del método) tiene la capacidad de adoptar cualquier artefacto definido en otros métodos y recomendar su aplicación en cierto contexto de uso. DSN_XP utiliza un marco de trabajo basado en los principios propuestos por el manifiesto ágil.

DSN_XP es un producto Ecuatoriano y por lo tanto en espíritu es libre por lo cual recomendamos su utilización para consultas o soporte teórico en la ingeniería de software.

DSN_XP y las triadas o la Ley del 3

Triadas

Tres dimensiones en una

DSN_XP inicialmente como metodología (estudio del método) profundizó el método científico como la herramienta necesaria para poder sostener todos los argumentos requeridos para la concepción filosófica de nuestro marco de trabajo, en especial en la versión 1.0

Creatividad y el pensar

Cuando empezamos a investigar sobre los factores de la creatividad que existían en los diseños codificados de los programadores, pudimos observar la presencia de lo que denominamos como estructuras mentales de pensamiento conocidas como systematics o el estudio de las dimensiones del pensamiento para DSN_XP.

Al buscar los componentes filosóficos que sintetizan el procedimiento de utilizar un lenguaje de programación para estructurar ideas abstractas y con ello poder captar un escenario y luego procesarlo mediante la relación software/hardware, exigía la presencia de nuevas herramientas para la comprensión del fenómeno ya que implicaba por defecto, el estudio de la mente y el proceso cognitivo más un conjunto de marcos de trabajos relacionados con algoritmos, modelizados, estructuras de control, dependencia de fenómenos no conocidos previamente, etc.

El software como artesanía o receta

Un primer acercamiento al modelo científico fue desplegado gracias a las investigaciones del grupo KYBELE, este hecho nos puso de frente a la necesidad de buscar raíces más profundas en la filosofía para comprender justamente los principios del método de razonamiento y la experimentación, dos momentos dentro del proceso de la creatividad del programador y el denominado modelo básico de programación que nos fuera enseñado en las aulas y que se trataba del modelo codificar y corregir.

Al entrar de lleno entonces en el mundo de la filosofía, entendíamos que definir un marco de trabajo para desarrollar software se volvía un tema más complejo que la definición de un modelo del ciclo de vida del desarrollo de software, esto es así porque desde los inicios de la ingeniería del software, los artefactos de diseño fueron tomados prestados desde otras ciencias y adaptados en conjunto con otras tecnologías.

La raíz del mirar DSN_XP

Teníamos como DSN_XP el objetivo el determinar la eficiencia de la experimentación, como uno de los procesos naturales que sostienen la creatividad y el diseño básico soportado por nuestro modelo, esto nos ponía como método de desarrollo de software, entre las escuelas de diseño más criticadas en la década de transición hacia el 2000, ya que se exigía de la industria del software la predictibilidad del software que fue demostrada en su proceso de inserción gracias a la revolución tecnológica y las supercomputadoras para el cálculo estadístico.
La experimentación, como método intuitivo y personalizado del programador era el resultado de todo un proceso de transformación y avance de la tecnología electrónica aplicada al procesamiento de datos, este proceso de diseño se puede comprender cuando se profundiza en el estudio del software como tecnología y no como ciencia, nuevamente, esta observación ya fue estudiada por KYBELE, pero no resuelve el proceso de aprendizaje basado en el error que implica el modelo de codificar y corregir que se vuelve experimental para el programador.
Esta observación de separar la parte blanda del diseño del software de su parte dura por implementación, implica dentro del estudio filosófico del diseño del software a aquellos conceptos de diseño como la ocultación de información y el encapsulado, fenómenos que la ciencia y sus métodos no soportan por concepto de la presencia del cambio en el modelo (falsación) que pondría en evidencia la robustez de la teoría producto resultante del método científico.
Dada esta restricción en nuestro proceso de investigación del software, recurrimos a la lógica dialéctica para el estudio del diseño de software, en especial, del proceso de impacto en el diseño debido al cambio como producto de un aprendizaje en el proceso de abstracción del problema y su solución. 

Más allá de una dualidad

DSN_XP estudia a las triadas como una estructura mental que permite el proceso de abstracción de forma diferente al proceso dual; el ser humano constantemente recurre a la dualidad para abarcar un concepto o evento, esto es así ya que pensamos en extremos para cuantificar diferencias como medio de abstracción, ejemplo: bueno y malo, día y noche, arriba y abajo, si y no, etc., 

En cualquier cosmología o sistema total, existe una diada básica de lo Absoluto y lo Relativo, donde hay manifestación, lo relativo es triple. Por lo tanto, siempre podemos hablar de cuatro mundos o de tres mundos inmanentes en un mundo.  En la tradición hindú esto está de acuerdo con la doctrina Samkhya de las tres gunas, En cosmología de Bennett, las tres gunas corresponden a función, ser y voluntad.

Sólo existen pocos modelos en los cuales de forma natural se recurren a tres (3) dimensiones en una, por ejemplo: largo, ancho y profundidad, ayer, hoy y mañana y sólido, líquido y gaseoso como los únicos ejemplos de triadas, lejos de este punto se concluye que la mayor parte de abstracciones son de tipo dual o basadas en imágenes, fotografías o registros que no pueden incluir la tercera dimensión porque no es visible para este razonamiento 

El estudio de las estructuras mentales del pensamiento como elemento fundamental para el uso de [Perspectivas] dentro del #TEAMVIEW.

Las triadas permiten obtener el pensamiento inverso que se requiere para modelar algo, en la Ingeniería Software existen varios artefactos basados en la noción de triadas, esta sección justamente se dedica a identificar y analizar dichos artefactos con el pensamiento basado en triadas :o)

El sistema basado en triadas relaciona la acción, la relación misma y el escenario de vida en el que se manifiesta, la orientación a objetos contempla también este aspecto al abstraer un acción como el resultado de un procesamiento de acuerdo a un evento en particular, es por esta razón que preferimos al esoterismo sobre el método tradicional en la investigación científica para el diseño del software, ya que es en base al esoterismo que nos es más transparente explicar los conceptos de la orientación a objetos de forma académica, esto es DSN_XP.


El primer acercamiento formal antes del esoterismo que DSN_XP contactó fue una acercamiento sobre ingeniería de software en un foro de discusión, en el cual preguntábamos sobre una nueva forma de aplicar un método basado en triadas al estudio del software.


Descubrimos que la escuela de pensamiento que soportaba los argumentos de mi compañero de foro denominada Unicismo utiliza una muy interesante combinación sobre las triadas que se explicarán en otro post a futuro, también esto nos llevó a conocer las fuentes de la sabiduría ZEN y el Cuarto Camino :o) 

El unicismo aplica el concepto de triada para describir y comprender un sistema, ya que cualquier sistema está integrado por un propósito, una función activa y una función de conservación de energía para asegurar los resultados. 

Ejemplos triádicos aplicados al estudio ontogenético funcional o enfoque funcionalista:
  • La función activa y la función de conservación de energía de la inteligencia de un árbol impulsan su crecimiento y supervivencia. 
  • La elevación y propulsión hacen que los aviones despeguen y vuelen.
  • La música y la letra de una canción definen su estética.

La naturaleza del software y su triada de computo



La naturaleza del desarrollo de software y su triada de uso



El uso de las triadas en la gestión de proyectos de desarrollo de software


Existen tres fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la calidad del producto final.

Cada fuerza es asociada a una variable de cálculo, el tiempo se convierte en cronograma, los recursos en costos y el alcance en funcionalidades, la resultante se mide en el éxito o fracaso del proyecto.

El equipo de desarrollo es responsable del alcance, el tiempo y los recursos son asignados al cliente, el proceso creativo del software tiene que ser transformado en retorno de inversión de acuerdo al esfuerzo aplicado a una funcionalidad específica.


Existen tres fuerzas básicas detrás del diseño de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la demanda del producto final.

Cada fuerza es asociada a una variable de cálculo, el producto se convierte en esfuerzo, el mercado en ingresos y las administración en costos, la resultante se mide en el éxito o fracaso del producto.

El equipo de desarrollo es responsable del producto, la administración y el mercado son asignados al cliente, el costo de fabricación del software tiene que ser transformado en la optimización de recursos de acuerdo al esfuerzo aplicado a una funcionalidad específica.


Existen tres fuerzas básicas detrás de un proyecto software, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina el entorno de trabajo.

Cada fuerza es asociada a una perspectiva de interés en el éxito del proyecto, el software determina la usabilidad, el business determina el factor de oportunidad y el team determinan el compromiso de cada uno de los miembros del equipo multidisciplinar.

El adecuado proceso de estimación de esfuerzos tiene que ser equilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que un equipo cansado y no motivado repercute en el entorno de trabajo, en la calidad del producto y en la entrega a tiempo de las funcionalidades.


Existen tres fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la usabilidad del producto final.

Cada fuerza es asociada a una fuente de información, el stakeholder provee las necesidades de requerimientos para la toma de decisiones, el usuario provee el conocimiento y el proceso que se desea abstraer, el desarrollador provee las mejoras al proceso y la simplicidad de la herramienta.

Es responsabilidad del equipo de desarrollo el comprender y balancear estos requerimientos en funcionalidades y servicios para el uso correcto del producto.


Existen tres fuerzas básicas detrás de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la calidad del producto final.

Cada fuerza es asociada a un factor de diseño, las historias de usuario capturan las necesidades del producto por parte de los usuarios (retorno de inversión), los criterios de aceptación capturan las necesidades del stakeholder principal (priorización) y las sentencias de trabajo definen sin ambigüedades las especificaciones del software (esfuerzo).

Es responsabilidad del equipo de desarrollo el verificar que cada historia posea los tres indicadores para una adecuada gestión del proyecto.

La triada de la permacultura

Tenemos el cuidado de la tierra, el cuidado de la gente y la repartición justa

La triada de la actitud

Tenemos el pienso, el quiero y el hago

La triada de la ética

Tenemos el crecer por mi, el crear por los demás y el cocrear por el mundo

La triada de la calidad

Procesos, entendiéndose como el conjunto de actividades en cierta secuencia que permiten alcanzar un objetivo, usualmente si el proceso no se encuentra bien definido o diseñado, estos aspectos tienen su impacto en la medición de la calidad del software.

Personas, es tal vez el elemento más complicado del desarrollo del software ya que son las personas las que interactúan con el producto software y determinan el conjunto de atribuciones externas que en conjunto definen la calidad del producto.

Producto, entendiéndose este como el objeto de análisis de los factores de la calidad de acuerdo a la injerencia de los otros dos elementos a todo el proceso de desarrollo de software.

La triada de los lenguajes en la solución de problemas

Este es un material que hemos tomado prestado de la base de conocimientos de LeanSight y hace referencia a las tres perspectivas que existen en el desarrollo de soluciones y casi de forma específica en el desarrollo de software.

La triada de la planificación ágil

Este es un material que hemos tomado prestado de Roman Picher respecto al Rol de Product Owner y que contempla la perspectiva táctica o el conjunto de actividades para concretar algo para luego contemplar la perspectiva estratégica de la situación y finalmente contemplar la perspectiva de una visión compartida para la organización.