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 método BOOCH

El método de Booch

DSN_XP en su versión 1.0 encuentra en el estudio de UML los modelos técnicos que eran utilizados por las metodologías que dieron soporte al lenguaje de modelado universal.

Metodología Booch

Fuente de conocimientos DSN_XP

El Método de Booch y su Influencia en DSN_XP 1.0

El desarrollo de software ha evolucionado a lo largo de los años, buscando siempre metodologías que permitan crear sistemas más eficientes, robustos y adaptables. En este contexto, el Método de Booch, con su enfoque en la orientación a objetos, ha dejado una huella significativa. En este artículo, exploraremos este método y su relevancia en el desarrollo de DSN_XP 1.0.

¿Qué es el método de Booch?

El Método de Booch es una metodología de desarrollo de software orientado a objetos creados por Grady Booch en Rational Software Corporation (posteriormente adquirido por IBM). Se centra en cuatro pilares fundamentales:

  • Abstracción: Simplificar la complejidad del sistema mediante la identificación de los aspectos esenciales.
  • Encapsulamiento: Ocultar los detalles de implementación y exponer solo las interfaces necesarias.
  • Modularidad: Dividir el sistema en componentes independientes e interconectados.
  • Jerarquía: Organizar los componentes en una estructura jerárquica para facilitar la comprensión y el mantenimiento.

Componentes Clave del Método

El método se compone de tres elementos principales:

  • Notación: Un lenguaje para representar los modelos del sistema (como UML).
  • Proceso: Las actividades que guían la construcción ordenada de los modelos.
  • Herramientas: Los artefactos que automatizan tareas y ayudan a detectar errores e inconsistencias en los modelos.

Modelos en el Diseño Orientado a Objetos

El diseño orientado a objetos, promovido por Booch, busca crear software resistente al cambio y con una expresión concisa. Se basa en la creación de varios modelos:

  • Modelo Lógico: Representa la estructura conceptual del sistema.
  • Modelo Físico: Describe la implementación física del sistema, incluyendo hardware y software.
  • Modelo Estático: Muestra la estructura del sistema en un momento dado.
  • Modelo Dinámico: Describe el comportamiento del sistema a lo largo del tiempo.

Filosofía y Principios del Diseño según Booch

Booch enfatiza la importancia de una etapa de análisis seguida por una de diseño. El diseño se define como una aproximación disciplinada para resolver un problema, guiando desde los requerimientos hasta la implementación.

Principios clave del diseño:

  • Crear una arquitectura interna clara y sencilla.
  • Equilibrar los requisitos en conflicto.
  • Utilizar modelos para razonar sobre las estructuras y facilitar la toma de decisiones.

Los modelos permiten simular y probar el sistema en condiciones controladas, identificando posibles fallos y realizando ajustes antes de la implementación.

Valores en la Construcción de Sistemas

La construcción de un sistema implica:

  • Satisfacer los requisitos funcionales.
  • Adaptarse a las limitaciones del entorno.
  • Cumplir con los requisitos implícitos y explícitos sobre la forma del artefacto.
  • Respetar las restricciones del proceso de diseño, como el tiempo, el coste y las herramientas disponibles.

El Ciclo de Vida Iterativo e Incremental

Booch recomienda el modelo iterativo e incremental para el ciclo de vida del software. Este enfoque permite refinar la arquitectura a través de iteraciones sucesivas y entregar incrementos funcionales del sistema.

DSN_XP 1.0 y la influencia del método de Booch

DSN_XP 1.0 reconoce la importancia de los modelos técnicos utilizados en las metodologías que dieron origen a UML. Se opone a dos extremos: la anarquía (falta de un ciclo de vida definido) y la dictadura (exceso de rigidez que sofoca la creatividad).

DSN_XP 1.0 promueve un proceso iterativo e incremental, donde se refina la arquitectura orientada a objetos a través de iteraciones sucesivas, incorporando la experiencia de cada iteración. Este enfoque permite converger hacia una solución que cumpla con los requisitos del usuario, siendo a la vez simple, confiable y adaptable.

DSN_XP.1.0.

Estudio avanzado de la ingeniería de software 

DSN_XP como arquitectura
En nuestra versión 1.0 el objetivo central es el definir un marco de trabajo para el diseño de software por experimentación, mediante ingeniería inversa de toda la codificación realizada para abstraer un diseño lógico.

Arquitectura 

Para poder esquematizar la versión 1.0 era necesario distinguir la presencia de la perspectiva que se dedica a investigar a la ingeniería del software desde sus inicios.  A esta perspectiva la denominamos como Software View y se encarga de analizar justamente a la ingeniería del software.

Ahora bien, la ingeniería de software en sus inicios se ve altamente influenciada por el desarrollo del hardware y su proceso de industrialización, sin embargo, la parte abstracta que es justamente la que caracteriza al software y en especial, a su característica programable, debía ser entendida dentro de la cobertura que se establece para el estudio del software o software View.

La idea de una máquina programable

Iniciar conforme la historia del desarrollo de la electrónica, ha motivado a superar muchas de las limitaciones que se tuvieron en un principio para lograr establecer lo que ahora, gracias a la tecnología y a la ciencia, se puede visualizar con un poco de mayor claridad.

Dentro de la perspectiva basada en el estudio del hardware, los intentos de la humanidad por abstraer el proceso de cálculo se remontan a las nociones matemáticas y de cálculo aplicado, razón por la cual se concluye que es la actividad humana productiva la que ha impulsado este proceso de abstracción que es motivo de nuestro estudio de la ingeniería de software.

Una vez que se ha establecido el método y con ello, se han establecido los principios, artefactos, técnicas y herramientas necesarias para poder profundizar en la investigación, arranca su base de conocimientos con aquellos conocimientos previos que han sido capturados en varios aspectos experimentados como proyectos de terceros para el desarrollo de software, bajo el apoyo y recomendaciones de DSN_XP.

Para cuando desarrollamos esta versión, en el mercado existía la programación estructurada y aparecieron ya algunos libros con referencias a una nueva escuela de diseño de software basada en la concepción de objetos, esto implicó para nosotros lograr profundizar en aquellos aspectos académicos del software y en especial el lograr desarmar la estructura rígida de la planificación anticipada.

DSN_XP y el proyecto BONO

Sistema de control y facturación de gas licuado 



BONO

Año: 2008
Localidad: Quito
Institución: Edwin Vargas Consultores

Descripción:

Uno de los problemas que tiene un alto impacto en la economía del Ecuador es el tema relacionado con el subsidio que se establece al consumo de gas licuado. Un problema adicional consistía en la forma en la cual se puede contar con datos mucho más certeros del nivel de consumo en Ecuador.

Edwin Vargas desarrolla un sistema que permite generar esa información detallada, gracias a la genialidad de sus ideas de sistematización y adaptación a tecnologías adicionales al software.

BONO es un proyecto para determinar la distribución de gas licuado por parte del Estado mediante el uso de dispositivos RFID para el control de la demanda territorial de consumo y la forma de cancelación mediante un bono popular de subsidio.

DSN_XP:

Se requiere el  modelado tanto a los aspectos de despliegue de la solución, así como una narración técnica de las posibles aplicaciones que pueden darse al considerar este proyecto en la magnitud de su implementación a nivel nacional.




Para lograr la abstracción del proyecto, se recurre a las perspectivas técnicas de diseño propuestas por el modelo arquitectónico de  Kruchten y su estándar UML.

La característica especial de poder implementar componentes lógicos de control como los dispositivos remotos y los protocolos de comunicación fueron posibles por las nociones de interfaz y de nodos de procesamiento y control.

Una vez más que DSN_XP y sus artefactos de diseño estaban en la capacidad de abstraer hasta este momento cualquier tipo de proceso, procedimiento, actividad, tarea, etc.

DSN_XP y su framework

DSN_XP Framework

Estructura conceptual del framework DSN_XP
DSN_XP fue inicialmente conceptuado como método de investigación, luego se amplió su cobertura de aplicación a un conjunto de: herramientas, buenas prácticas, artefactos y modelos que fueron tomados de nuestra investigación sobre metodologías de desarrollo de software, hasta considerarnos como una metodología de análisis y diseño (postergando la implementación y su desarrollo a proyectos experimentados con terceros).

Base de conocimientos

"Un framework es un diseño abstracto para una clase de aplicación en particular y usualmente consiste de un número de clases, las cuales puedes ser tomadas desde una librería de clases o pueden ser específicas de la aplicación." R. Johnson, B. Foote.

Conocimientos base de DSN_XP

Al respecto, el método se enfoca en el ¿Cómo? mientras que el marco de trabajo se enfoca en resolver una necesidad específica de uso mediante los componentes del framework. 

Componentes del framework

Al mirar que podíamos extender el uso de DSN_XP como método a otros contextos fuera del desarrollo de software, tuvimos la visión de emplear registros para analizar la eficacia del método y de sus componentes, ya sean estos propios o prestados de otros métodos, marcos de trabajo, buenas prácticas, etc. 

  • "Un framework ayuda a los desarrolladores a proveer soluciones a problemas de un dominio y mejorar el mantenimiento para dichas soluciones. 
  • Un framework provee una infraestructura bien diseñada y pensada que cuando se crean nuevas piezas, las mismas pueden ser sustituidas con un impacto mínimo en las otras piezas del framework." C. Nelson

Para poder adaptar otros artefactos, dentro del conjunto de herramientas de análisis y diseño requeridas por DSN_XP, realizamos de forma intuitiva (y reutilizable si fuese posible el contexto), comparaciones buscando un uso común, las metas las propiedades y la estructura que debe cumplir un marco de trabajo para ser considerado como tal. 

"Un framework es un diseño reutilizable para un sistema de software o subsistema, esto se expresa como el conjunto de clases abstractas y la forma en que sus casos colaboran para un tipo específico de software"  Gamma, E et al

 Experimentación

Para poder comprender la estructura de un marco de trabajo, analizamos otro marco de trabajo y debido al proyecto que participamos codirigiendo, fue posible aplicar SCRUM y con ello, comenzar a entender los aspectos que teníamos que reforzar para crear la versión 3.0 como marco de trabajo DSN_XP para contextos que soporten los principios LEAN y Agile.

Inverse Refactoring

DSN_XP 3.0 REFACTORING

Mejora continua de DSN_XP

Kernel(3.0).Método.Drill()
Toda metodología contiene en principio una filosofía de diseño, DSN_XP desde su versión 0.1 ha trabajado con la ingeniería inversa como driver para el diseño de su marco de trabajo documental.

El kernel que estamos desarmando en estos momentos contiene en su interior los artefactos necesarios para comprender a otros métodos y replicarlos mediante experimentación para descubrir las capacidades del artefacto investigado.

Kernel(3.0).Método.Drill()

DSN_XP y Twitter

Twitter como canal de expresión de ideas


Agradecemos (mientras realizamos una investigación) a Twitter por permitirnos un medio en el cual podemos expresar nuestras ideas, inferencias, conclusiones, etc.

Muchos de nuestros seguidores [@DSN_XP] en twitter nos recomendaron que hagamos un blog en el cual podamos plasmar toda aquella información que habíamos manifestado mediante nuestros tweets para seguirnos adecuadamente en nuestras investigaciones.

Les manifestamos entonces que utilicen una lista o filtren nuestros mensajes por #DSN_XP para un adecuado seguimiento, pese a esta indicación, insistieron en la idea de un blog.

Una vez creado el blog, comprendemos que tenían mucha razón en su demanda y por ello dedicamos este post para agradecer su gentileza y adoptar esta mejora en el manejo del contenido acerca de DSN_XP.

Informamos también a nuestros seguidores y usuarios, que pese a que existe este blog, seguimos requiriendo los servicios de un micro blog como Twitter, pues necesitamos expresar nuestras ideas durante una investigación para registro público y propiedad intelectual de su contenido :o)

ARQUITECTURA DSN_XP

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.

DSN_XP y Fail Fast de Chile Ágil

Fail Fast y Chile Ágil

Estimados Chile Ágil (@ChileAgil) agradecemos la oportunidad que nos dieron de poder expresar nuestras ideas como DSN_XP en el portal FAIL FAST de su dominio.


Agradecemos a Agustín Villena por la confianza depositada en DSN_XP y ponemos a su disposición este blog para transmitir las ideas expresadas por Chile Ágil sobre el movimiento ágil en Chile.

Nuestra intención es también formar la comunidad ágil en Ecuador por lo que estaremos modificando este post con los avances hacia este objetivo.



DSN_XP y las redes sociales

Nuestras redes sociales



Nota: desde el 11 de abril del 2021 cerramos nuestros canales oficiales tanto en facebook como en twitter por temas internos relacionados con el uso de nuestro datos y la manipulación del algoritmo base de estos dos canales.

Queremos dejar constancia de aquellas personas que nos aconsejaron utilizar herramientas sociales para la difusión de nuestras ideas :o)

Twitter: @jlsandovaln @byriton @edwinvargaslara, @runakawsai, @jorgegamba, @agustinvillena
Facebook: Centro el Pungu

DSN_XP está en constante evolución y aprendizaje, paradójicamente, este comportamiento también lo sufren los codificadores mientras adquieren experiencia en el desarrollo de software, esta observación nos permitió poder realizar ingeniería inversa de las redes sociales.

Para comprender las redes sociales debemos por principio desarmar su contexto de uso y de allí la necesidad de forzar el modelo para identificar los límites de la abstracción, es por esta causa, que la forma en la cual nosotros utilizamos tanto Facebook como Twitter rompen los esquemas o estereotipos comúnmente aceptados para estas redes sociales.

DSN_XP había publicado cientos de conceptos en la Internet pero no tenía la gobernanza de su contenido, la idea de aceptar el reto y experimentar con las redes sociales (en estos momentos con herramientas para un blog) nos ha permitido captar en nuestros registros una cultura alrededor de este fenómeno denominado "Redes sociales".

Por lo tanto el contenido de este post u otros se irá modificando mientras más afinado se encuentre el modelo de la idea que deseamos transmitir para una mejor comprensión sobre DSN_XP.

DSN_XP y su herramienta Taladro

Herramientas DSN_XP


Principio básico del Observador es confrontar las nociones de adentro y afuera de sí 
Las metodologías en el estudio del método, requieren para efectos de su operatividad de un conjunto de herramientas como artefactos y modelos que permiten en su aplicación, la obtención de la información.
Cuando iniciamos nuestro estudio del software y su proceso de creación, este esfuerzo requería de investigación tanto a nivel de la ingeniería de software como a nivel de su desarrollo localmente en Ecuador y desde una mirada como academia dentro de la formación profesional en universidades de quienes crearían este software.

El método de investigación temática


DSN_XP diseñó este artefacto para poder realizar prototipos mentales sobre el conocimiento de una cosa o de un evento.  El proceso de investigación científica aplicado al diseño del software utilizado por DSN_XP, requiere de una apropiada herramienta que nos permita realizar una minería de información en el vasto contenido publicado en la Internet. 

DSN_XP como método de investigación científica, obtiene su base de conocimientos académicos tanto de libros especializados como de la Internet (incluyendo sus redes sociales), DSN_XP por el principio de ingeniería inversa, requiere además del conocimiento académico, del conocimiento experimental que no necesariamente se basa en la opinión de alguien muy versado en tema o concepto investigado conocido como "Gurú", sino que recoge en sí mismo la noción de fallar como premisa del método y su modelo "codificar y corregir", actividad que denominamos en sintaxis como desarmar() y armar().

Proceso de abstracción en la definición del requerimiento


Por asociación, llamamos "El taladro" al artefacto que posee dos movimientos (BottomUp / TopDown) en el proceso de abstracción para el diseño de software y lo implementamos en su sintaxis como drillUp() y drillDown() 

Ahora bien, ¿pueden funcionar de forma independiente entre sí estos dos movimientos?... 

La respuesta es "depende" del contexto de uso en el cual estamos trabajando, sin embargo, hemos descubierto que para un mejor diseño, se requiere inevitablemente aplicar los dos movimientos pues se complementan entre sí.

El Taladro by DSN_XP

Esta herramienta propuesta por DSN_XP es un "taladro" cuyos dos movimientos permitidos son la profundización o drillDown() y la abstracción o drillUp(). Nos dió el principio de los posibles movimientos del taladro y que puede aplicarse en cualquier dirección y de forma directa o drillDown() o de forma inversa o drillUp().
  • drillDown() significa que el lector desea conocer más sobre el contenido de un post en especial, por lo cual tiene que profundizar sus lecturas hacia los orígenes de las fuentes (DSN_XP.Source), para ello dispone de una base de conocimientos de referencia.
  • drillUp() significa que el lector está en la capacidad de generar un modelo y poner a prueba DSN_XP, registrando todos los puntos e inquietudes que pueda tener al respecto en la base de conocimientos.
Estos dos movimientos son básicos en el método científico aplicado al estudio del diseño de software.

DSN_XP y la mindset comunitario

El estudio de la comunidad 

DSN_XP estudia dentro de su perspectiva TEAM VIEW, todos aquellos aspectos relacionados con el ser humano y su proceso formativo y colaborativo.

Mindset

Este es uno de los tantos términos que tenemos que abarcar para poder igualar lenguaje con terceros que generan contenido que es utilizado por la comunidad para discutir ideas.  Dentro de nuestros estudios, habíamos tenido acercamientos con el concepto de "Cosmovisión" siendo esta la palabra que describía la forma de contemplar al mundo desde un rol de observador.

Para contextos LLM, la definición de Mindset es:

El mindset se refiere a la mentalidad fija o de crecimiento que influye en cómo las personas abordan los desafíos, el fracaso y el éxito. No es solo una creencia sobre uno mismo, sino una forma de ver el mundo.

La psicóloga estadounidense Carol S. Dweck acuñó y popularizó el término "mindset" en su libro de 2006, "Mindset: The New Psychology of Success" . Dweck, una de las principales investigadoras mundiales en los campos de la personalidad, la psicología social y del desarrollo, ha dedicado su carrera a estudiar por qué algunas personas prosperan frente a los reveses y otras se desmoronan. Su trabajo en la Universidad de Stanford sentó las bases para la comprensión de que la mentalidad no es una cualidad innata, sino algo que se puede cultivar.

Ahora bien, todos los aspectos relacionados con el uso del lenguaje para el entendimiento del ser humano tanto como individuo como colectivo, nos motivaron a estudiar estos aspectos desde varias áreas del conocimiento como la filosofía, la psicología, la política y el desarrollo social, por lo que tuvimos que adaptar un nuevo componente de estudio al marco de trabajo DSN_XP 

Comunidad

Cuando comenzamos a experimentar con la metodología propuesta por XP o Programación Extrema, la parte que nos llamó mucho la atención fue la necesidad implícita de una disciplina interna mental para la mejora continua del programador y su colectivo asociado o equipo de desarrollo, si deseabas que la palabra extremo sea apropiada para definir al más apto para la codificación de la solución buscada.