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.

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)