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.

DSN_XP y su base de conocimientos

Base de conocimientos DSN_XP

DSN_XP.BaseKnow

Nuestra base de conocimientos se establece gracias a las siguientes fuentes de información DSN_XP que son:

  • Biblioteca que contiene todos los libros que se han buscado en la red sobre un contexto específico de apoyo teórico para una investigación DSN_XP.
  • Investigaciones que son aquellos temas que debemos consultar para lograr definir un contexto apropiado para una intervención en la cual aplicaremos DSN_XP en cualquiera de sus versiones.
  • Actores que son aquellos personajes que hemos investigado como proponentes de una teoría o escuela de pensamiento que estamos consultando para describir un escenario de uso o experimentación con DSN_XP.

Conocimiento base

El primer nivel de conocimiento describe los principios básicos de un arte, ciencia o técnica, esto nos llevó a profundizar en aquellos aspectos académicos con los cuales podíamos contar como plataforma de conocimientos en aquel entonces.  

El conocimiento científico

Estudio inverso del método con DSN_XP
DSN_XP es una metodología para desarrollar conocimiento, como metodología posee la facultad de estudiar el método, por lo tanto, dicho estudio implica el uso de la técnica de observación y experimentación, este razonamiento es la fuente principal de conocimiento que aplica DSN_XP para conceptuar un modelo como artefacto, bajo esta premisa, DSN_XP está en la capacidad de definir lineamientos para una lectura adecuada y un uso apropiado del modelo.

Academia

Nuestra base de conocimientos estaba determinada tanto por nuestra formación académica como analista programador para pasar luego a formarnos como ingeniero en sistemas y finalmente como consultor técnico.

Nuestra base de conocimientos se conformaría inicialmente entre:

  • Técnicas de modelado, modelos y métodos en la historia del software. 
  • Herramientas y buenas prácticas referidas en los contextos de desarrollo de software.

Base de conocimientos DSN_XP

Conocimientos académicos

DSN_XP conceptúa como núcleo de su marco de trabajo, al desarrollo de una base de conocimientos que fueron obtenidos durante nuestra formación como Tecnólogo analista programador y luego como Ingeniero en sistemas.  

Estos conocimientos que forman nuestra base de conocimientos académicos, junto con las investigaciones temáticas desarrolladas, son referidos en cualquier intervención técnica que requiera de las recomendaciones de DSN_XP, así como el estudio y actualización constante de nuestros propios conocimientos para el modelado avanzado de software y el desarrollo de investigaciones temáticas

Escuelas de pensamiento

La información está disponible en cualquier parte, es preciso entonces su interpretación para comenzar a definir un conocimiento como la facultad de entender y juzgar una cosa. Bajo este razonamiento, se entiende entonces que son necesarias diversas áreas de conocimiento para conceptuar de forma holística todo el proceso de desarrollar software.

SWEBOK (IEEE)

Base de conocimientos sobre la ingeniería software


Las diversas áreas de conocimiento que estudiamos del SWEBOK son:
  • Requisitos del software
  • Diseño de software
  • Construcción de software
  • Pruebas de software (testing)
  • Mantenimiento de software
  • Administración de la configuración del software
  • Administración de la ingeniería software
  • Procesos de ingeniería software
  • Herramientas y métodos de la ingeniería software
  • Calidad del software

PMBOK (PMI)

Base de conocimientos sobre gestión de proyectos


Las diversas áreas de conocimiento que estudiamos del PMBOK son:
  • Gestión de la integración
  • Gestión del alcance
  • Gestión del tiempo
  • Gestión de la calidad
  • Gestión de costos
  • Gestión del riesgo
  • Gestión de recursos humanos
  • Gestión de la comunicación
  • Gestión de las compras y adquisiciones

BABOK (IIBA)

Base de conocimientos sobre el análisis de negocios


Las diversas áreas de conocimiento que soporta el BABOK son:
  • Análisis empresarial
  • Planificación de requerimientos y gestión
  • Elicitación de requerimientos
  • Análisis de requerimientos y documentación
  • Aseguramiento de la solución y validación

AGILE/LEAN/ADAPTIVE 

Base de conocimientos sobre gestión de proyectos ágiles

DSN_XP reconoce que todo proyecto software intrínsecamente contiene un factor de riesgo el cual debe ser gestionado adecuadamente, por ello, adopta la filosofía propuesta por el movimiento ágil.
Valoramos al equipo y su interacción, por encima de los procesos y las herramientas.
(TeamView)

El software que funciona, por encima de la documentación exhaustiva. 
(SoftwareView)

La colaboración con el cliente, por encima de la negociación contractual. 
(BusinessView)

La respuesta al cambio, por encima del seguimiento de un plan.
(Adaptive Framework)
El marco adaptativo requiere necesariamente de stakeholders participativos e involucrados en el proyecto, el riesgo al igual que el éxito o el fracaso de un proyecto es de responsabilidad compartida entre los miembros del equipo asignado a este. Pese a ello, el fracaso de un proyecto es de utilidad para el entorno ya que genera un aprendizaje de la cultura y el proceso se mejora continuamente.

Estudio de artefactos y métodos

Base de conocimientos sobre metodologías y marcos de trabajo

DSN_XP como metodología estudia al método, artefacto, modelo, etc., que es recomendado como buena práctica para el desarrollo de software. Esto involucra el estudio en la práctica de las siguientes escuelas de diseño:
  • Ciclos de vida para el desarrollo de software.
  • Modelos para la abstracción de diseños.
  • Técnicas de comunicación entre equipos.
  • Patrones de diseño y marcos de trabajo para el desarrollo de software.
  • Aspectos legales detrás del diseño y propiedad intelectual.
  • Documentación del software

Estudio de escuelas de diseño

Base de conocimientos sobre diseño de software

DSN_XP por principio adopta los lineamientos de la escuela de orientación a objetos, sin embargo puede adaptarse a otras escuelas de diseño bajo su noción de perspectivas de uso y escenarios.
  • Programación orientada a objetos.
  • Programación orientada a aspectos.
  • Diseño de base de datos.
  • Diseño por contrato.
  • Diseño de código abierto.
  • Arquitecturas software y lenguajes de programación.

Estudio de personal humano

Base de conocimientos sobre la interacción con personas

DSN_XP como metodología estudia al ser humano y su comportamiento, para lo cual recurre a las siguientes escuelas de pensamiento:
  • Cuarto camino (integración del pensamiento fragmentado)
  • Filosofía (definición de modelos de pensamiento)
  • Psicología (definición del posible comportamiento humano)
  • Danzas y movimientos (para el equilibrio del ser humano)
  • Neurolingüística (para el uso adecuado del lenguaje corporal y hablado)
  • Mentoring, coaching, training de equipos multidisciplinares.

Estudio del entorno y la naturaleza

Base de conocimientos sobre la interacción entre el producto y su entorno

DSN_XP como metodología estudia al entorno para respetar su estatus, para ello recurre a las siguientes escuelas de pensamiento:
  • Permacultura (como adaptarse al entorno natural con cultura permanente)
  • Marco de trabajo adaptativo (para adaptarse al entorno del negocio).
  • Comportamiento organizativo (para la definición de un lenguaje apropiado para el entorno)
  • Marketing (para alinearse a los objetivos comerciales del cliente)
  • Bases de conocimientos (para el continuo aprendizaje del entorno)
  • Administración de riesgos (para el uso adecuado de los recursos del entorno)

DSN_XP y su versión 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 estándar para tesis de grado en sistemas

Metodología para el desarrollo de tesis en la facultad de sistemas de la UTECI

Año: 2004
Localidad: Quito
Institución: Universidad Tecnológica Israel

Descripción: 

Elaboración de un marco de trabajo para los egresados de la facultad de sistemas cuyo tema de tesis consiste en el desarrollo de una aplicación software, dicho marco de trabajo se realiza como una propuesta para la estandarización de contenidos y formatos que se requerían en la facultad de sistemas acorde a los lineamientos propuestos por la Universidad Tecnológica Israel

DSN_XP: 

Participó diseñando un modelo del ciclo de vida para el desarrollo de software considerando aspectos de documentación del proyecto, criterios de ingeniería de software recomendados para la elaboración del marco teórico y un manejo adecuado de los tiempos destinados para el desarrollo de la aplicación software considerada como tesis. 

DSN_XP considera a este proyecto (tesis de Francisco Toscano Morales) como el primer acercamiento formal para la estructuración de nuestra metodología (DSN_XP)


Modelo del ciclo de vida para el desarrollo de software en tesis por DSN_XP


Fase de visionar adaptada por DSN_XP bajo los lineamientos de MSF


Fase de planificación adaptada por DSN_XP bajo los lineamientos de MSF


Fase de desarrollo adaptada por DSN_XP bajo los lineamientos de MSF


Fase de estabilización adaptada por DSN_XP bajo los lineamientos de MSF

Nota: En este ciclo de vida propuesto por DSN_XP no se considera la etapa conocida como de "mantenimiento del software" debido a que una vez que fue presentada una tesis, el egresado no realizaba mejoras al producto (entendidas como mantenimiento) ya que dejaba de formar parte de la comunidad activa de la universidad. 

Esta propuesta fue presentada al consejo directivo de la universidad pero no tuvo acogida favorable por desarrollar desde esta época ideas que años más tarde se verían reflejadas como resultado del manifiesto por el Movimiento para el Desarrollo Ágil de Software :o)

Resultado experimentado:

  • La evolución de DSN_XP: De una fase exploratoria a una fase de consolidación y estandarización.
  • El objetivo principal del proyecto: Establecer un marco de trabajo para el desarrollo de tesis de grado.
  • La importancia de la estandarización: Garantizar la calidad y la coherencia de los proyectos.
  • La naturaleza innovadora del proyecto: Primera tesis de investigación científica aplicada a la ingeniería de software en Ecuador.
  • Lecciones aprendidas:

    • Contenido del marco de trabajo: Detallar los elementos clave del marco de trabajo, como las fases del desarrollo de software, los artefactos a producir, los criterios de evaluación, etc.
    • Impacto en la formación de los estudiantes: Analizar cómo el marco de trabajo contribuyó a mejorar la formación de los estudiantes en ingeniería de software.
    • Difusión de los resultados: Describir cómo se difundieron los resultados del proyecto a nivel institucional y nacional.
    • Relación con los estándares internacionales: Se podría analizar cómo el marco de trabajo se alinea con los estándares internacionales de desarrollo de software, como el Modelo de Madurez de la Capacidad de Ingeniería de Software (CMMI) o el estándar ISO/IEC 12207.
    • Sostenibilidad del marco de trabajo: Se podría discutir cómo se garantizó la sostenibilidad del marco de trabajo en el tiempo y cómo se adaptó a los cambios en las tecnologías y las metodologías de desarrollo de software.

    DSN_XP y su primera evolución

    La Evolución de la Arquitectura DSN_XP

    De la Práctica Experimental al Estándar Académico

    Introducción: El Nacimiento de un Método en la Práctica

    La Arquitectura DSN_XP no surgió en un vacío teórico, sino como una respuesta directa a desafíos concretos en el desarrollo de software en el contexto académico ecuatoriano de principios de los años 2000. Su evolución está intrínsecamente ligada a tres proyectos clave en la Universidad Tecnológica Israel (UTECI) y DESSINE: SITEDI , ALEPH_XP y la Estandarización de Tesis . Estos proyectos, combinados, forjaron la versión 1.0 de la metodología.

    1. SITEDI (2003): El Piloto Experimental y la Crisis de la Cascada

    El proyecto SITEDI (Sistema de Tesis Dirigidas) puso de manifiesto la necesidad urgente de una metodología unificada. La baja tasa de culminación de tesis y la inconsistencia en el desarrollo del software eran problemas evidentes.

    • Aplicación de DSN_XP: Se actuó como consultoría externa, introduciendo el concepto de un ciclo de vida iterativo e incremental frente al modelo tradicional en cascada del reglamento académico.

    • Aporte Clave: Demostró la viabilidad práctica de un enfoque estructurado y orientado a objetos, enfatizando el Principio de Ocultación de Información para gestionar el acoplamiento.

    • Resultado: Solo los equipos guiados por DSN_XP lograron defender sus tesis con éxito, validando el método en un entorno de desarrollo colaborativo a gran escala.

    2. ALEPH_XP (2004): La Confrontación Teórica y la Investigación Formal

    Mientras SITEDI probaba la eficacia del método, ALEPH_XP, aunque no se concretó como un desarrollo Open Source de herramientas de Ingeniería FM, sirvió como un catalizador teórico fundamental.

    • Desafío Clave: La necesidad de desarrollar software como tesis de grado forzó a DSN_XP a confrontar el modelo prevalente de "Codificar y Corregir" y la ausencia de metodologías formales en la academia.

    • Aporte Clave: Permitió a DSN_XP profundizar en la investigación de las metodologías de desarrollo de software en Ecuador y establecer su marco de referencia teórico basado en una concepción arquitectónica por perspectivas , justificando el diseño más allá de la simple programación.

    • Resultado: El proyecto guio la adaptación de los artefactos de DSN_XP para ser un marco teórico robusto capaz de soportar tanto el producto software como el documento de tesis.

    3. Asesoría y Régimen Académico (2003-2005): La Consolidación y el Estándar 1.0

    Las lecciones de SITEDI y la investigación impulsada por ALEPH_XP convergieron en el programa de asesoría a egresados, lo que llevó directamente al proyecto de Régimen Académico.

    • Aplicación de DSN_XP: Se impartieron talleres técnicos intensivos (UML, modelado, análisis y diseño) a estudiantes que no encontraban una metodología apropiada. DSN_XP funcionó como un soporte personalizado y una plataforma de investigación de la ingeniería de software .

    • El Gran Hito (DSN_XP 1.0): El éxito de la asesoría liderada al proyecto "Régimen académico y tesis de grado" en 2004. Aquí, DSN_XP 1.0 fue establecido como el marco de trabajo estandarizado para el desarrollo de tesis en la Facultad de Sistemas.

    • Legado: Este proceso no solo generó las mejores tesis de la época, sino que también se considera la primera tesis de investigación científica aplicada a la ingeniería de software en Ecuador , elevando la calidad académica a un nuevo nivel de estandarización.

    Conclusión

    La Arquitectura DSN_XP evolucionó desde un experimento de consultoría ( SITEDI ) a un objeto de profunda investigación metodológica ( ALEPH_XP ), hasta convertirse en el Estándar 1.0 que transformó la manera en que se desarrollaron las tesis de software en la UTECI.