DSN_XP y Alistair Cockburn en gratitud constante

 Metodología del software

Metodólogo Alistair Cockburn
DSN_XP entra en contacto con las ideas de Alistair mediante su familia de esquemas estratégicos para equipos de desarrollo de software o CRYSTAL CLEAR

Fuente de conocimientos

Metodología centrada en el potencial humano

Alistair se convierte en una fuente de conocimientos importantes para DSN_XP al poder tener como ejemplo a un investigador del software y metodólogo, todo un estudios de varios artefactos que ha ido estudiando y experimentando en su blog personal. 

Advanced Use Case

Alistair también se vuelve un referente como metodólogo en el uso avanzado de los casos de uso para el diseño de software. DSN_XP venía desarrollando una mirada similar desde nuestro método de modelando avanzado basado en casos de uso y el poder de abstracción que nos brindaba UML.

Manifiesto Agile

Alistair es uno de los mentores del manifiesto agile, de hecho, nuestros registros sobre la concepción del manifiesto y las fotografías que adornan nuestro blog fueron liberadas por el propio Alistair a la comunidad.

IC Agile y el modelado de competencias

Alistair promovió un modelo de certificación que respondía a las necesidades de la comunidad internacional en base a un diseño muy interesante sobre formación de sus estudiantes.

Scrum

Alistair abandona al equipo IC Agile y comienza su gira internacional mediante su capacitación  en Scrum

Corazón de la agilidad

El último esfuerzo metodológico realizado por Alistar se denomina el Corazón de la Agilidad y sintetiza todo el proceso observado a lo largo del tiempo y hasta la fecha, tanto del proceso de capacitaciones como el material pedagógico de entrenamiento.

DSN_XP y la investigación científica

Investigación Científica

Investigación aplicada al concepto de software
DSN_XP debía empezar a realizar una serie de investigaciones técnicas con el objetivo de ir poblando su base de conocimientos, con el criterio de usabilidad de las herramientas y modelos que habíamos encontrado hasta ese momento en el estudio del os fundamentos del software.

Investigaciones DSN_XP

Como DSN_XP, debíamos explicar la razón fundamental del aporte de nuestras ideas a la academia en Ecuador, esto implicaba ya un esfuerzo mayor que debía ser registrado para efectos de entender y definir un método personalizado para desarrollar software, el mismo que utilizamos en cada una de las actividades académicas requeridas para la obtención del título de Ingeniero en Sistemas.

Búsqueda del método

En este contexto espacio tiempo, frente a la rigidez de un método científico aplicado al desarrollo de la tesis de grado por un lado y por el otro, a la necesidad de un método ágil para el desarrollo evolutivo de soluciones en base al prototipado y la mejora continua, nuestra línea de investigación era más que necesaria, sin embargo, no encontramos en otras universidades investigaciones al respecto.

Habíamos visto tesis que mencionaban a SPICE como marco de trabajo pero ninguna realizaba un análisis profundo al aspecto académico de la ingeniería de software y la necesidad de marcos de trabajo especializados para el desarrollo de software en Ecuador.

Norma SPICE ISO/IEC 15504 - EQA
Habíamos visto tesis que decían (al igual que nosotros) aplican la metodología de programación extrema XP, sin embargo, dichas tesis tampoco lograban observar la necesidad de emplear un marco de trabajo más allá de un método (o el conjunto de buenas prácticas para aplicarse en entornos de desarrollo de software).

Comprender esto es ya tener una mirada profunda hacia el proceso de desarrollar software en Ecuador y su impacto como una nueva carrera que se insertaba en la matriz cognitiva de las mallas curriculares de los institutos superiores y universidades y la carrera de sistemas como tal.

Nuevamente, dado que no existían registros en la academia del Ecuador que estudien este aspecto, nos parecía de vital importancia el profundizar dicho estudio y con ello plantear un conocimiento nuevo (respecto al contexto ecuatoriano) sobre la ingeniería de software y su estructura como ingeniería.

Para resolver esto, se requería necesariamente de un método de investigación y este necesariamente debía ser histórico mediante la lectura misma de la base de conocimientos de la ingeniería de software, entonces... el primer dilema a resolver era demostrar que la lectura como método de investigación era más que evidente para la naturaleza de nuestra investigación y que el método que puede ser empleado para estudiar un fenómeno en movimiento era justamente el método histórico. 

Luego tuvimos la oportunidad de encontrar un documento muy importante de investigación en español que se realizaba justamente aplicado a la ingeniería de software, esta investigación nos permitió dar un paso gigante en el desarrollo de nuestro método y en consecuencia en su prueba en un campo específico como dentro del estudio del método o metodología.

DSN_XP y Mario Bunge en gratitud

 Filosofía en español


Fuente de conocimiento en filosofía
DSN_XP entra en contacto con este actor, cuando profundizamos en la filosofía como fuente de conocimiento en la búsqueda de argumentos que nos permitan sostener teóricamente la maleabilidad del software (como la capacidad de poder manipular su estructura y su comportamiento en tiempo de ejecución).

Mario Bunge

Es fundador de la Sociedad para la Filosofía Exacta que procura emplear solamente conceptos exactos, definidos mediante la lógica o la matemática a fin de evitar la ambigüedad y la imprecisión características de otros estilos filosóficos, entre ellos el fenomenológico, el postmoderno (especialmente el hermenéutico) y provoca (a la vez que estimula) el tratamiento de problemas no triviales como contraste con la gigantesca producción filosófica libresca que interpreta recursivamente las opiniones de otros filósofos o que juega con objetos ideales o mundos posibles.

La concepción sistemista de Mario Bunge tiene dos aspectos principales, uno ontológico y otro gnoseológico. El sistemismo ontológico que Bunge defiende y postula que el mundo es un sistema de sistemas, es decir que toda cosa concreta es un sistema o un componente de algún sistema. 

Un sistema es, en efecto, un objeto complejo estructurado, cuyas partes están relacionadas entre sí por medio de vínculos (estructura) pertenecientes a un nivel determinado. ​Además, puesto que un sistema se caracteriza por poseer propiedades que sus componentes no poseen (vale decir, propiedades globales o emergentes), el sistemismo de Bunge es también emergentista. En otras palabras, la ontología bungeana es monista con respecto a la sustancia y pluralista respecto de las propiedades.

Bunge y la tecnología

Bunge indica que pueden presentarse una serie de «candidatos» plausibles al estatus de generalización sobre el desarrollo tecnológico:
  • Toda cosa o proceso artificial puede ser mejorado, pero solo hasta cierto punto: hay límites naturales y sociales.
  • Toda innovación tecnológica tiene efectos colaterales impredecibles e indeseables.
  • En principio, cada uno de estos defectos puede reparase con la ayuda de más conocimiento o bien de una reforma social.
  • Todo adelanto importante en la alta tecnología explota algún descubrimiento científico.
  • Solo una pequeña fracción de la ciencia básica llega a aplicarse y solo una pequeña fracción de la ciencia aplicada encuentra uso en la tecnología.
  • Habitualmente hay un retraso de varios años entre los hallazgos científicos y su uso tecnológico.
  • La mayoría de las invenciones nunca se llevan a la práctica.
  • La tecnología militar redunda únicamente en mínimos productos secundarios de uso civil y hace más lento el progreso de la tecnología civil porque desvía cerebros, recursos naturales y fondos.
  • En las naciones en desarrollo la tecnología comienza siendo imitativa.
  • La innovación tecnológica como función del tamaño de una empresa es una "u invertida" (∩): en un principio crece y luego declina.

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 atenció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 estudio del ciclo

El ciclo y la variable tiempo


El ciclo es un concepto que involucra la noción de tiempo, en este estudio, es una variable auxiliar que se requiere para la planificación.
DSN_XP inicia su estudio del ciclo basado en tiempo cuando, como marco de trabajo aplicado al estudio del desarrollo de software, se nos plantea responder sobre aspectos relacionados con la efectividad de nuestro método para administrar la complejidad para poder estimar el esfuerzo necesario para cumplir con un requerimiento que usualmente está relacionado con un contrato legal y la entrega del objeto de contratación de desarrollo de software.

Nota: Para una lectura formativa sobre el estudio del método visita esta entrada.

Tiempo

El tiempo se mide en unidades de tiempo, pero estas unidades tienen un costo asociado a su consumo que es de mucho interés para el cliente y para la sociedad también.

Se entiende que, la dimensión de negociación del proyecto a cargo del desarrollo de software, implica el cambiar de cualidad en el objeto de estudio (antes de implantar el software) desde una situación inicial, hasta una situación final (una vez puesto en producción el software), si el cambio es imperceptible para el observador, significa que la unidad de medida del ciclo de tiempo es muy lenta o demasiado rápida como para ser percibida.

La negociación del software

Dentro de los aspectos que este estudio requiere sobre el tiempo, es necesario establecer el escenario en el cual se desarrollan las actividades durante el período de desarrollo, en el estudio del software se presenta entonces la noción de proyecto de desarrollo de software y como tal, se supone que la metodología contempla, además del modelo de desarrollo de software, aquellos aspectos administrativos que fueron el dolor de cabeza de la industria durante la crisis metodológica que daría paso a la presencia de los métodos ligeros de desarrollo de software.

El ciclo es un concepto que involucra la noción de tiempo, el tiempo en este estudio es una variable auxiliar que se requiere para la planificación del esfuerzo.

Nota: Para una profundización sobre los aspectos del modelo de ciclo de vida, visita esta entrada

Ciclo de vida del desarrollo de software

La introducción teórica anterior era necesaria para poder comprender la noción de ciclo y en este caso en particular comprender los modelos de desarrollo de software propuesto por las diferentes escuelas de diseño, en concreto, nos interesa la escuela orientada a objetos y sus modelos arquitectónicos de componentes, paquetes hasta los denominados "building blocks".

DSN_XP tomó como referente para los aspectos administrativos que se encuentran englobados en la gestión de proyectos, a una de las herramientas propuesta por MSF o Microsoft Solution Framework 

DSN_XP y el método OOSE

Método OOSE

Método OOSE
Dentro del estudio de UML para el modelado de los proyectos de desarrollo de tesis y sus registros con DSN_XP,  bajamos a las raíces de sus artefactos y esto implicó el desarmar el método propuesto por Jacobson para el Análisis y Diseño orientado a objetos como uno de sus precursores.

Ingeniería de software orientada a objetos

Como DSN_XP, no encontramos registros de proyectos que aplicasen este método como referencia para el desarrollo de software, usualmente, el empleo de los casos de uso se hacía referencia al empleo de UML en lugar de ser artefactos adoptados por OOSE para su sustentación metodológica.

Sin embargo, DSN_XP reconoce a OOSE como una de sus fuentes de conocimiento y adopta algunas de sus observaciones tanto para el proceso de desarrollar un método como para lograr documentar técnicamente los proyectos de software.

Acerca de Ivar Jacobson

Nos interesó de sobremanera el artefacto denominado como caso de uso (Use Case) porque nos pareció genial la capacidad de modelado ágil con el cual se podía abstraer la complejidad de los sistemas, comparado con otras metodologías de corte clásico y estructurado que nos fueron enseñadas en aulas para lograr capturar la esencia del algoritmo de solución.
Nota: Nuestro método 1.0 adopta como estrategia el modelado avanzado con casos de uso para representar los intereses de los estudiantes ante el desarrollo de sus tesis de grado.

CVDS: 

Desarrollo iterativo e incremental, orientado al análisis, diseño y codificación por componentes.

ESCUELA DE DISEÑO: 

Orientación a objetos, orientación a componentes, los casos de uso originan el método

FECHA: 1992 (OBJECTORY)

FLUJOS DE TRABAJO: 

Arquitectura, análisis y diseño orientado a objetos, codificación orientada a componentes e implementación.

MÉTODO: 

El método se divide en 2 procesos una macro y otro micro, ambos procesos incluyen las etapas mencionadas pero se diferencian por el nivel de abstracción requerido de los objetos.

El proceso micro propone:

Una vez realizada la captura de requerimientos y el entendimiento del problema mediante los casos de uso, se define una arquitectura que soporte como guía al proceso de análisis y diseño debido a la noción de componentes como unidades modulares independientes que contienen objetos relacionados entre sí por su razón de uso (use case), el proceso de análisis y diseño se preocupa por definir los objetos, organizarlos, describirlos en sus relaciones y establecer su estructura interna (tipo y atributos), el proceso de construcción contempla objetos propios de la implementación diferentes del análisis y diseño con el objetivo de mantener intacto el diseño inicial, el proceso se repite y se refina continuamente hasta lograr el objetivo planteado por la arquitectura que dirige todo el proceso en sí.

Artefactos y/o Diagramas:

Los artefactos utilizados por OOSE son bastante parecidos a los propuestos por OMT, la diferencia fundamental radica en los denominados casos de uso que se convierten en el corazón del método y de los cuales se realiza los demás artefactos. OOSE potencia el uso de diagramas de interacción, diagramas de secuencia, diagramas de estados, diagramas de clases, diagramas de componentes.

DSN_XP y el método OMT

El Método OMT 

Dentro del estudio de UML como lenguaje para el modelado de soluciones basadas en el diseño de software, como DSN_XP 1.0 bajamos a las raíces gráficas de sus artefactos para modelar y esto implicó el desarmar el método propuesto por Rumbaugh para el Análisis y Diseño orientado a objetos como uno de sus precursores.

Object Modeling Technique (OMT)

CVDS: 

Desarrollo iterativo y secuencial, OMT sólo identifica los flujos de trabajo de análisis y diseño y no contempla los demás flujos.

ESCUELA DE DISEÑO: 

Orientación a objetos

FECHA: 1991 (GENERAL ELECTRIC LABS)

FLUJOS DE TRABAJO: 

Análisis del dominio del problema, diseño del sistema, diseño de objetos, implementación.

MÉTODO: 

El análisis comienza con el descubrimiento del problema y su modelado bajo entidades básicas del dominio (lenguaje apropiado para el negocio), este previo análisis permite definir el comportamiento deseado de las entidades y se define el alcance del sistema; para lograr modelar el sistema, se utiliza la técnica TOP-DOWN (describir la complejidad en partes sencillas) y se definen los subsistemas desde el punto de vista arquitectónico logrando así establecer una estrategia de descomposición; el diseño de objetos considera la estructura de datos de las entidades y los algoritmos necesarios para implementar el comportamiento deseado de las clases principales, se consideran las relaciones entre las entidades (modelo E/R orientado a las clases) y se construye un diccionario de entidades, la herencia se puede usar para generalizar los aspectos comunes de las clases existentes construyendo una superclase o para refinar una clase en subclases especializadas, finalmente se comprueba el diseño de objetos mediante las asociaciones establecidas para responder a inquietudes del negocio (aspectos de consumo y construcción de información sobre data básica de entrada) El proceso de implementación de la solución considera el uso adecuado de lenguajes de programación (sean o no orientados a objetos) y la capacidad de persistencia en bases de datos.

Artefactos y/o Diagramas:

El método utiliza 3 perspectivas: (1) Estática (Modelo de objetos = diagrama del modelo de objetos + diccionario de datos), (2) Dinámica (diagramas de estados + diagrama global de trazado de eventos ) y (3) Funcional (diagramas de flujo de datos + restricciones) 

Nota: se requieren modelos comunes durante el desarrollo desde las 3 perspectivas y se verifican, iteran y refinan las tres perspectivas continuamente.

Perspectiva Metodológica de DSN_XP

El Método OMT proporcionó a DSN_XP un marco robusto, especialmente en la perspectiva de datos, que fue clave para proyectos con alta complejidad transaccional (como el sistema AMBAR).

DSN_XP adopta la naturaleza iterativa (como Booch) y utiliza sus conceptos de análisis como base para el Software View. La escuela de Diseño Orientada a Objetos es objeto del estudio central de DSN_XP , priorizando la estructura sobre la funcionalidad.

Clave de Flujos Análisis del Dominio, Diseño del Sistema, Diseño de Objetos, Implementación. La separación rigurosa entre Dominio (Negocio) y Diseño de Objetos (Software) refuerza la necesidad de nuestras Perspectivas (Views).

Técnica Central TOP-DOWN (Descomposición de complejidad). Complementa el movimiento drillDown() de nuestra herramienta "El Taladro" para la profundización en la abstracción.

Modelo E/R orientado a Clases y Diccionario de Entidades . Proporciona una base sólida para el diseño de la Persistencia de Datos, un aspecto que a menudo se simplifica en otras metodologías OO puras.

Artefactos OMT: La Base de las Perspectivas

El mayor aporte del Método OMT a la filosofía de la Arquitectura DSN_XP es su estructuración del modelado en tres perspectivas esenciales y comunes, que deben verificarse y refinarse continuamente:
  • Modelo de Objetos (Perspectiva Estática): Captura la estructura de las clases, la herencia y las asociaciones (análogo a un diagrama de clases con su diccionario de datos).
  • Modelo Dinámico (Perspectiva Comportamiento): Describe el comportamiento del sistema a lo largo del tiempo utilizando Diagramas de Estados y Trazado de Eventos .
  • Modelo Funcional (Perspectiva Procesos/Flujo): Muestra la transformación de valores (datos) mediante Diagramas de Flujo de Datos (DFDs) y restricciones.
La diferenciación explícita de estas tres perspectivas (Objetos, Dinámica, Funcional) fue un precursor directo de las vistas arquitectónicas que DSN_XP adoptó y refinó posteriormente (ej. Software View , Business View ), asegurando que el diseño fuera completo desde Múltiples ángulos. 

OMT fue especialmente valorado por su solidez en el análisis de sistemas de información con gran cantidad de datos.

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 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 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 en gratitud a Ivar Jacobson

 Actores fuente de conocimiento

Casos de Uso y diseño por componentes
DSN_XP entra en contacto con la fuente de conocimientos escrita por Jacobson, al iniciar nuestros estudios del modelado avanzado con Casos de uso.

Ivar Jacobson

En 1967 propuso la utilización de componentes de software en el desarrollo de la nueva generación de conmutadores telefónicos controlados, que Ericsson estaba desarrollando. Para ello inventó diagramas de secuencia y desarrolló diagramas de colaboración. También aplicó diagramas de transición de estado para describir el flujo de mensajes entre los componentes.

Pensó que era necesario hacer planes de desarrollo de software y fue uno de los desarrolladores originales de SDL (lenguaje de descripción y especificación). En 1967, SDL se convirtió en un estándar en la industria de las telecomunicaciones.

También inventó casos de uso como una forma de especificar los requisitos funcionales de software.

En abril de 1987, dejó Ericsson y fundó la empresa Objective Systems. Una mayoría de las acciones de la compañía fue adquirida por Ericsson en 1991, y la compañía fue renombrada Objectory AB.

Ivar Jacobson desarrolló el proceso de software OOSE en Objectory AB alrededor de 1992.

DSN_XP y el modelado con UML

Los criterios de modelado


Los primeros "modelos" desarrollados por DSN_XP como tal, surgen en base a nuestro conocimiento de una escuela de modelado de software que se presenta madura y ordenada e incluso introduce el concepto de arquitectura sobre la ingeniería que veníamos desarrollando.

UML


El Lenguaje Universal de Modelado (UML) es independiente del proceso de desarrollo, lo que significa que como lenguaje, no está ligado a ningún modelo del ciclo de vida del desarrollo de software (CVDS) en particular.

Para DSN_XP como metodología, todo método sobre desarrollo de software, requiere por defecto definir un modelo CVDS, es decir, la forma en la cual se va a gestionar el proceso de desarrollo del software.
UML puede representar este modelo CVDS mediante un diagrama estereotipado de actividades.

Las escuelas de diseño y el modelado del sistema

La forma en la cual se diseñe el software del sistema, depende de las guías de diseño definidas para ello, UML no es una guía de diseño para desarrollar software; pero proporciona un lenguaje de modelado que soporta tanto la orientación a objetos como otros paradigmas de desarrollo. 
UML no posee un modelo para representar modelos, solventa este problema por la noción de paquetes estereotipados.

 La ingeniería del software como tal, utiliza los modelos y los métodos para desarrollar software e impone una estructura a la ingeniería detrás del software con el objetivo de hacer que esta actividad sea sistemática, en lo posible, repetible y en como fin, que esté orientada a cumplir una necesidad de cálculo o control de forma adecuada al contexto en el cual se la aplica.

La necesidad de utilizar perspectivas en el modelado

Un modelo es una abstracción de un sistema; un subsistema representa una partición de los elementos de un sistema más grande en partes independientes, los subsistemas y el sistema global pueden modelarse desde muy diferentes puntos de vista. 

Una vista es una proyección de la organización y estructura de un sistema centrada en un aspecto particular del mismo. 
UML posee la noción de paquetes que contienen todas las abstracciones pertinentes para esa vista

El uso de modelos proporciona un enfoque al problema de resolución, una notación y procedimientos para el modelo de construcción y su análisis. Como método, proporciona un enfoque de la especificación sistemática, diseño, construcción, prueba y verificación del producto final del software y los productos de trabajo asociados.

Modelado de la arquitectura de un sistema

Cuando se modela la arquitectura de un sistema, se capturan las decisiones sobre los aspectos estructurales y de comportamiento de los sistemas y los patrones que configuran estas vistas.
UML posee diversos artefactos para soportar las vistas requeridas para modelar la arquitectura del sistema (4+1), los patrones de diseño se modelan como colaboraciones.

Modelo conceptual de UML

El modelo conceptual de UML está conformado por los bloques básicos de construcción UML, (elementos, relaciones y diagramas), las reglas que dictan cómo se pueden combinar los bloques básicos (reglas semánticas para nombres, alcance, visibilidad, integridad, etc.) y algunos mecanismos comunes que se aplican a través de UML (especificaciones, adornos, divisiones comunes, mecanismos de extensibilidad)

Apuntes DSN_XP sobre UML 

UML: Lenguaje de modelado para visualizar, especificar, construir, documentar software

UML como lenguaje de modelado provee 5 vistas para modelar toda la arquitectura software, posee la vista de diseño, la vista de procesos, la vista de implementación la vista de despliegue y la vista de casos de uso.

DSN_XP no reconoce a los casos de uso como un artefacto orientado a objetos y no recomienda utilizar la noción de relaciones en los diagramas de clases ya que las relaciones en base a asociaciones no son tampoco recomendadas por DSN_XP en el diseño orientado a objetos.

Inicios de UML como lenguaje de modelado

El método de Booch era particularmente expresivo durante las fases de diseño y construcción de los proyectos, OOSE proporcionaba un soporte excelente para los casos de uso como forma de dirigir la captura de requisitos, el análisis y el diseño de alto nivel y OMT era principalmente útil para el análisis y para los sistemas de información con gran cantidad de datos.
“Como creadores principales de los métodos de Booch, OOSE y OMT, nos sentimos motivados para crear un lenguaje unificado de modelado por 3 razones. En primer lugar, cada uno de nuestros métodos ya estaba evolucionado independientemente hacia los otros dos. Tenía sentido hacer continuar esa evolución de forma conjunta en vez de hacerlo por separado, eliminando la posibilidad de cualquier diferencia gratuita e innecesaria, en segundo lugar, al unificar nuestros métodos, podríamos proporcionar cierta estabilidad al mercado orientado a objetos, permitiendo que los proyectos se pusieran de acuerdo en un lenguaje de modelado maduro y permitiendo a los constructores de herramientas que centraran en proporcionar más características útiles. En tercer lugar, esperábamos que nuestra colaboración introduciría mejoras en los tres métodos anteriores, ayudándonos a capturar lecciones aprendidas y a cubrir problemas que ninguno de nuestros métodos había manejado bien anteriormente” [UML]

Metas propuestas por UML

  1. Modelar sistemas, desde el concepto hasta los artefactos ejecutables utilizando técnicas orientadas a objetos.
  2. Cubrir las cuestiones relacionadas con el tamaño inherentes a los sistemas complejos y críticos.
  3. Crear un lenguaje de modelado utilizable tanto por las personas como por las máquinas.
Curiosamente, un montón de empresas de desarrollo de software comienzan queriendo construir rascacielos pero enfocan el problema como si estuvieran enfrentándose a la caseta de un perro :o)
Las ventajas del modelado son:
  1. Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema.
  2. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema.
  3. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema.
  4. Los modelos documentan las decisiones que hemos adoptado.

Principios de modelado

  • La elección de qué modelos crear tiene una profunda influencia sobre cómo se enfrenta un problema y cómo se da forma a una solución.
  • Todo modelo puede ser expresado a diferentes niveles de precisión.
  • Los mejores modelos están ligados a la realidad.
  • Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.
DSN_XP soporta varios lenguajes de modelado pero usualmente recurre a UML por estándar y lenguaje de modelado más conocido.

Referencias

El lenguaje unificado de modelado, Booch et al, Addison Wesley, 1999, ISBN:84-7829-028-1

DSN_XP y el diseñar inversamente

Reverse Engineering

Reverse engineering is the process of discovering the technological principles of a human (or non-human) made device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g., a mechanical device, electronic component, or software program) apart and analyzing its workings in detail to be used in maintenance, or to try to make a new device or program that does the same thing without using or simply duplicating (without understanding) the original. 
Reverse engineering has its origins in the analysis of hardware for commercial or military advantage. 
The purpose is to deduce design decisions from end products with little or no additional knowledge about the procedures involved in the original production. The same techniques are subsequently being researched for application to legacy software systems, not for industrial or defence ends, but rather to replace incorrect, incomplete, or otherwise unavailable documentation.[Wikipedia]

La ingeniería inversa es el proceso de descubrir los principios tecnológicos de un dispositivo, objeto o sistema humano (o no humano) a través del análisis de su estructura, función y operación. A menudo implica desarmar algo (por ejemplo, un dispositivo mecánico, un componente electrónico o un programa de software) y analizar detalladamente su funcionamiento para usarlo en el mantenimiento, o intentar crear un nuevo dispositivo o programa que haga lo mismo sin usar o simplemente duplicando (sin entender) el original.

La ingeniería inversa tiene sus orígenes en el análisis de hardware para ventajas comerciales o militares. 
El propósito es deducir las decisiones de diseño de los productos finales con poco o ningún conocimiento adicional sobre los procedimientos involucrados en la producción original. Posteriormente, se están investigando las mismas técnicas para su aplicación a sistemas de software heredados, no para fines industriales o de defensa, sino para reemplazar la documentación incorrecta, incompleta o no disponible. [Wikipedia]

Pensamiento inverso

Para DSN_XP la ingeniería en reversa (al contrario que la ingeniería directa) se volvió el método que empleamos para lograr adaptarnos desde una escuela de programación estructurada, hacia una nueva escuela de programación orientada a objetos, ya que teníamos que comprender la forma en la cual se programaba, se compilaba, se ponía en producción y se le daba mantenimiento a estos nuevos sistemas basados en objetos.
Profesionalmente hablando, los proyectos en los que empezamos a participar promocionando DSN_XP requerían de un rol documentador que permitiese al equipo de desarrollo, conseguir todo el marco teórico que sostendría los diseños realizados por los codificadores.

La documentación como tal, formó parte de la cultura de desarrollo de software y a su vez fue el área de conocimiento menos atendida en las organizaciones debido a varios aspectos, el principal, por la característica de la tecnología de ir cambiando muy drásticamente en el tiempo y la necesidad de tener gobernanza en la tecnología  requería comprender los procesos automatizados y la algoritmia del software desarrollado.

Para lograr comprender todos los aspectos técnicos y no técnicos detrás del proceso de desarrollo de software profesional en el Ecuador, se requieren conocimientos suficientes sobre la ingeniería de software y estos conocimientos deben verse reflejados tanto en el código programable como en todo el proceso de su puesta en producción.

Conocimiento mínimo



Estos últimos conceptos requieren de un esfuerzo formidable por entender la tecnología aplicada al proceso de computación, implicando un estudio de:
  • Desarrollo de software a bajo nivel, estudiando el Lenguaje Assembler, teoría sobre compiladores, máquinas virtuales y bytecodes.
  • Sistemas operativos y su arquitectura de diseño y despliegue.
  • Perspectivas de alto nivel para módulos y constructores comunes codificados.
  • Administración de datos y el uso de variables, estructuras de datos definidos por el usuario, listas.
  • Flujos de control y estructuras de control y secuencia.
  • Lenguajes de programación como C, C++, Java, C#
  • Perspectivas a bajo nivel como registros, pilas, saltos y secciones de datos ejecutables.
Todo este marco teórico se encuentra respaldado en el estudio profundo de este libro disponible en nuestra biblioteca de conocimientos DSN_XP.

Ingeniería inversa

La ingeniería inversa o en reversa, en el desarrollo de software puede ser increíblemente útil para los codificadores.  Por ejemplo, los codificadores de software pueden emplear las técnicas de reversado para descubrir cómo interoperar con software total o parcialmente indocumentado.  En otros casos, el poder reversar puede ser utilizado para determinar la calidad del código de un tercero, tal como una librería o inclusive aún, un sistema operativo.

Finalmente, es posible a veces el utilizar técnicas de reversado para extraer información valiosa desde un producto de la competencia con el propósito de mejorar las propias tecnologías. 

Diseño inverso de software 

La aplicación de la ingeniería inversa en el estudio y documentación del desarrollo de software en Ecuador es discutida por DSN_XP bajo los siguientes escenarios de uso:

  • Lograr la interoperabilidad con el software propietario, la interoperabilidad es la situación de mayor uso de la ingeniería inversa a diario, cuando se trabaja con una librería de software propietaria o una API del sistema operativo, la documentación usualmente en la mayoría de casos es insuficiente.
  • Desarrollar software competitivo, en la mayoría de industrias es por lo menos la aplicación más popular de la ingeniería inversa.  El software, tiende a ser más complejo que la mayoría de productos, de tal forma que, desarmar por entero un producto software para crear un producto competitivo parece no tener sentido.  Es más fácil el diseñar y desarrollar un producto desde la nada o simplemente licenciar con terceros los más grandes componentes que desarrollarlos localmente.
  • Evaluar la calidad de software y su robustez, se requieren conceptos de ingeniería inversa para evaluar la seguridad y vulnerabilidad del software, usualmente solo basta una porción del código para evaluar y estimar la calidad general del código y sus prácticas de codificación de todo el producto.

Enfoque de la ingeniería inversa ontológica


Esta es una síntesis de los resultados obtenidos de la investigación sobre la ontología de la Ingeniería Inversa liderada por Peter Belohlavek.

La ingeniería inversa ontológica es el proceso de descubrir los principios ontológicos de un objeto, sistema o realidad a través del análisis de su estructura ontológica, función y operación.

La ingeniería inversa ontológica es el proceso mecánico unicista para descubrir o redescubrir la naturaleza de un objeto de la realidad que se investiga. Es un enfoque tecnológico que se hace necesario cuando se trata de la naturaleza de los problemas.

Es la herramienta básica para la resolución de problemas complejos. Sin poder lidiar con el proceso de ingeniería inversa, no se puede abordar la naturaleza de los problemas. Este es el límite real de los problemas que un individuo puede resolver.

Copyright Instituto de investigación Unicista

Todo el mundo puede utilizar este enfoque en algún nivel. La cuestión es aceptarlo y entrenarlo para expandir los límites de su aplicación.

El proceso de ingeniería inversa ontológica

La ontointeligencia define la capacidad de los individuos para hacer frente a problemas complejos. La ontointeligencia está integrada por la inteligencia estratégica de los individuos, su tipo de pensamiento lógico y su inteligencia ética.

Esto define el enfoque de la actividad de un individuo, el valor que agrega al medio ambiente, la capacidad de pronosticar el futuro y el campo en el que un individuo es naturalmente exitoso.

La inteligencia evoluciona cuando un individuo madura. La madurez permite a un individuo alcanzar el máximo nivel de influencia en la realidad. 

Pensar hacia atrás implica ser capaz de pensar desde el final hasta el principio. Considere una línea de montaje. Es la capacidad de un individuo para descomponer el "producto" final en sus componentes.

Copyright Instituto de investigación Unicista

Cuando hablamos de ingeniería inversa ontológica significa que en este proceso el individuo es capaz de encontrar la naturaleza de una realidad específica. Para hacerlo, un individuo tiene que ser capaz de descubrir la estructura de la naturaleza de esa realidad.

El proceso de ingeniería inversa ontológica es el enfoque básico para redescubrir los conceptos de una realidad que ha sido descubierta. Y para hacer esto, los individuos necesitan descubrir los componentes de la “línea de montaje” que definen la realidad final hasta encontrar los objetos que integran esa realidad.