domingo, 22 de julio de 2018

DSN_XP.Nucleo.CVDS.Codefix

DSN_XP.Nucleo.CVDS.Code_fix feb2006



Modelo: Codificar y corregir
Recomendación: El más utilizado

Ventajas de aplicar el modelo CVDS codificar y corregir


DSN_XP soporta por su filosofía de diseño basada en la ingeniería inversa el modelo codificar y corregir <<Code_fix>> esto significa que DSN_XP está dirigida o <driver by> por el código fuente.

Ahora bien, concluir que un modelo es erroneo es incorrecto, el modelo por concepto es correcto pues representa bajo el proceso de abstracción una realidad y nadie discute si la realidad es incorrecta o si_???

Cuando nosotros (DSN_XP) aplicamos la ingeniería inversa en la creación de nuestros modelos, tenemos muy en claro la concepción del error como elemento fundamental para el análisis, el diseño está omnipresente a lo largo del desarrollo de un producto software bajo la noción del prototipado.

Este modelo representa si se lo entiende muy bien, la gran ventaja de que el programador sabe lo que quiere programar, investiga al lenguaje y a la vez investiga la arquitectura además de la estructura.

La falencia de conocimientos teóricos respecto al cómo utilizar un modelo es resuelta por la experiencia, la práctica, la definición de un método. Bajo este razonamiento, un modelo no es una metodología, por lo tanto no puede decirse de este modelo <<Code_fix>> es una metodología :o)

En cuanto al desorden, este puede presentarse al aplicar otros modelos CVDS, por lo que no es culpa del modelo sino de la metodología asociada al explicar el uso tanto de métodos y artefactos, así como el uso asistido por computadora (RAD)

Finalmente levante la mano entre el público lector, aquel que no ha utilizado este modelo o lo sigue utilizando hasta lograr confiar en él como un modelo certero pues hasta ahora sigue dando resultados.

La teoría responde que este modelo incluye todas las fases por las cuales debe pasar el proceso de desarrollo, la investigación, planificación, etc, etc, pueden ser representadas en un orden secuencial solo con fines académicos.

Estas fases son:


  • Codificar: definir la estructura interna con objetivos reutilizables.
  • Corregir: Implementar el sistema mediante el registro de errores para la definición de patrones reutilizables.

domingo, 15 de julio de 2018

DSN_XP y el diseño de software

DSN_XP.Arquitectura.FAQs.Metodología feb2004


Durante el diseño de nuestro marco de trabajo (considerado como una tesis para la obtención de la ingeniería), era necesario responder sobre la practicidad de nuestro método de investigación para el desarrollo, diseño y sustento de un marco de trabajo.

Durante esta primera etapa, teníamos que desarrollar la capacidad de responder si era necesario o no utilizar una metodología para desarrollar software, de serlo, ¿cuál sería la mejor metodología?...

Responder a esta pregunta, nos motivó a que en foros de discusión, crucemos ideas con otros sobre este mismo tema y otros más relacionados con la ingeniería de software y la gestión de proyectos software.


¿Es DSN_XP una metodología de investigación científica? <<Resumido>> <<Diferido>>

</OffTopic>

Mil disculpas al grupo de discusión, en especial al señor moderador, por utilizar este canal de retroalimentación para fines personales :o)

La temática del grupo reza así:

“Comunidad virtual de profesionales y/o estudiantes de habla castellana para discutir, por ejemplo: ciclo de vida;técnicas, metodologías y tecnólogos/metodólogos —como Boëhm, Booch, Chen, Coad, De Marco,Humphrey, Jacobson, Jacopini, Martin, Mellor, Nassi, Pressman, Rumbaugh, Shlaer, Yourdon y más—; Ingeniería de Sistemas Asistida por Computadora —Computer-Aided Systems Engineering (CASE)—; proyectos; planificación; requerimientos; análisis, procesos, viabilidad/factibilidad; modelado de datos —entidad-relación (E/R), IDEF1X, etc.—; diseño de sistemas, bases de datos, interfaces de usuario; implantación, despliegue, soporte y mantenimiento; etc.” [*SI]

</OffTopic>

<Temática>

Estimado Osvaldo, felices días para ti y para cada uno de los miembros del grupo SI :o)

Me he tomado la libertad de utilizar este canal de retroalimentación para sostener el debate planteado, en vista de que otros miembros no se han manifestado y tampoco ha existido una sugerencia de parte del moderador del grupo.  Como miembro del mismo, puedo comenzar el debate de tan importante tema para la ingeniería software.

Sin embargo, por la amplitud de la temática, me gustaría sugerir una estrategia común entre tu forma de razonamiento y el mío.  Tu nivel de cultura informática es muy avanzado <<Lejano>> (lejos de ver claramente) para mi estructura de pensamiento actual ¿Por qué?

La observación demuestra que en un intercambio de ideas, cada interlocutor tiende a llevar la información hacia su estructura de pensamiento (esto lo demostró Turing con su test de Turing).


Esta información es transmitida en forma paralela y bidireccionalmente a través del canal de retroalimentación establecido entre el emisor y el receptor. <<OffTopic: por no pensar en esferas>> <<Diferido>>

Para poder ponernos de acuerdo, es necesario resaltar un punto común de perspectivas, este punto lo denomino el de mayor perspectiva de información <<Perspectiva de ubicación>> <<Diferido>> [DSN_XP]

</Temática>

<Preguntas>

El diccionario es uno de los artefactos más importantes del diseño, en este caso solo me interesa la definición de metodología de desarrollo del software. Las siguientes preguntas son consideradas como frecuentes:

<FAQs>

¿Qué es metodología?, ¿Qué es método?, ¿Qué es modelo?

<<Esta preguntas fueron planteadas en el foro del señor Rodolfo Quispe , miembro de esta comunidad [*Ingenieríadelsoftware]>> <<Referido>> <<Recomendado>>

</FAQs>

</Preguntas>

Sin embargo, contestar sobre una metodología de desarrollo de software, es muy difícil ¿Por qué?

Estas fueron las evidencias que encontré al plantear mi metodología: <<Diferido>>

¿Cómo puedo aplicar el método científico en la concepción de DSN_XP?

El estudio de la ingeniería software como método para la concepción del software cae necesariamente en una investigación intelectual, ésta es diferente con la física que planteas, que es más material. Ahora que, para ponernos de acuerdo debo manifestar que mi estructura de pensamiento esta regida por el pensamiento dialéctico, por lo tanto materialista <<Discutible>> <<Diferido>>

Investigaciones al respecto en mi base de conocimiento, hacen referencia a la Universidad Rey Juan Carlos de España y el proyecto Kybele [*Kybele] <<Enlace HTML>>

Este estudio manifiesta que no son aplicables los métodos científicos tradicionales al estudio del software, lo cual comparto como evidente desde mi experiencia.

El proceso cognoscitivo de la concepción de software se vuelve entonces en mi objeto de estudio, para lo cual es preciso aplicar un método científico de investigación (¿Cuál es el más apropiado?), la segunda evidencia refleja que la teoría dialéctica se acopla de mejor forma al proceso del diseño del software y su estudio, por un simple hecho, su carácter objetivo.

Existe una interesante observación al comparar el método científico de investigación y el método de diseño y desarrollo del software, por ejemplo:

  • La fase de captura de requisitos e investigación del negocio se asemejan en concepto al proceso de abstracción del método científico.
  • La fase de diseño y codificación del software se asemeja a la estructura de pensamiento para obtener el razonamiento correcto (experimentar).
  • Los métodos diferentes a la dialéctica consideran un solo paso en el proceso de abstracción, pero este paso queda incompleto si no se vuelve al objeto con conocimiento de causa (concretación), esto es ingeniería inversa. <<Diferido>>

</Temática>

“Moviéndonos hacia el lado de la Ciencia y dejando la Filosofía de lado entramos de lleno en la lógica la modelización y la resolución de problemas. Este si es el campo de mi interés” [*Osvaldo]

Al igual que el mío.

“Si me concentro en la Resolución de Problemas llegará a la conclusión que solo puedo resolver un problema en tanto haya realizado un Modelo de Información del Problema, Contexto, Dominio y Medio” [Ibíd.] 
Este primer paso en la concepción del software es el límite del software, por lo tanto como evidentemente razonas entramos en la discusión de la forma y el contenido.

“La relación de Problema y Contexto ha quedado patentizada en la Física Teórica , sobre todos en la teorías de Simetrías” [Ibíd.]

Añado que este dilema está presente todo el tiempo y es una característica del desarrollo (Dialéctica, lucha de contrarios).

“Y brevemente indican que muchas veces cambiando el punto de enfoque lo que parecía un problema, ya no lo es decir al reencuadrar el problema en un contexto diferente desaparece” [Ibíd.]

Este proceso se conoce como un “salto”, sin embargo debo aclarar que no desaparece, persiste pero en condiciones diferentes (Dialéctica, salto de lo cuantitativo a lo cualitativo y viceversa).

“El Dominio está relacionado en mucho con lo que nos ha enseñado la metodología orientada a objetos, es decir considera a todos aquellos elementos (objetos) que están relacionados de alguna forma con nuestro problema y con nuestro contexto. Y luego nos queda el medio que es lo que excede a nuestro 'ambiente'” [Ibíd.]

Totalmente de acuerdo, sin embargo este es el aspecto de más riesgo en el proceso productivo (¿evidencia una falla en el diseño?) <<Crisis del software>>

“Desde otro punto de vista, se debe buscar la relación entre fondo, forma y función, y cuanto más cercana este esta relación a los valores estéticos de una cultura mas apetecible la solución será” [Ibíd.]

Esto es la definición de un modelo o patrón, sin embargo refiere al marketing como campo de acción en la actualidad <<La nueva crisis del software>> <<Diferido>>

“Teniendo en claro esto como Objetivo o Modelo de Conocimiento pasamos a considerar que tipo de lógica tiene la capacidad para resolver problemas y luego que tipo de problemas pueden ser resueltos por dicha lógica” [Ibíd.]

La investigación refleja que las metodologías se preocuparon primero por el proceso de diseño para luego enfocarse en el proceso de análisis, lo que evidencio con mi experiencia.

“En mi caso mi óptica cambió cuando pasé de la lógica binaria convencional (la cual se inicia con Descartes), (tesis-Antítesis) a una lógica trinaria que es propia del Unicismo” [Ibíd.]

Pues aquí aparece el punto de fuga entre tu perspectiva y la mía <<Pensamiento dialéctico>>

“No ahondaré a.C. en esta lógica trinaria, pero si puedo decirle que es de un orden superior a la binaria” [Ibíd.]
<<Sin comentarios>> estoy de acuerdo :o)

“Si Ud logra darse cuenta de cuales son los problemas que tienen solución con la lógica que Ud utiliza y cuales no, entonces podrá darse cuenta de cuales son las limitaciones de su Modelo y por ende de la Metodología que se deriva de dicho Modelo” [Ibíd.]

Completamente de acuerdo y si no me equivoco se denominan esenciales [*Bohem]

“Este fue justamente el caso de Eisntein, una persona con tal claridad mental llego a encontrar las limitaciones de la teoría física de su tiempo y a generar un Modelo alternativo mucho más abarcativo” [Ibíd.]

<<Sin comentarios>>

“Generado el modelo pasó a diseñar una nueva Teoría y Metodología asociada” [Ibíd.]

Esta es la parte que impactó en mi razonamiento por la siguiente razón:

Hace poco hice una pregunta en dos foros sobre el modelo del ciclo de vida del software CVDS y si debe ser considerado como metodología de desarrollo. <<Diferido>>

La investigación refleja que no es tan descabellada la idea (aunque no son lo mismo), es decir ¿es un modelo una metodología? Justamente se presenta este punto de fuga por existir una sola metodología asociada <<Parte de tu razonamiento>> <<Diferido más adelante>>

“Pero dado que los 'problemas terrenales no le interesaban, allí dejo su teoría. Otras personas más cercanas a los problemas terrenales, diseñaron experimentos y comprobaron que la Teoría se convalidaba con la práctica, por lo cual la metodología debería ser valida. Ya que no soy físico, dejemos el tema para ellos, pues hasta aquí llega mi conocimiento sobre el particular” [Ibíd.]

Hace poco observé un programa por cable (Discovery) en el que los físicos astrónomos reconocieron que los modelos que diseñaban para entender la configuración del Cosmos, no les servían porque contínuamente fracasaban en la experimentación.

Esta verdad evidencia necesariamente al “fallo” como un dato importante en el proceso de diseño (uso de prototipos)

“Llegado a este punto Ud posee una Metodología la cual, por fuerza, deberá aglutinar a un conjunto de Métodos que operan en la práctica. Queda ahora validarla (o falsarla, como diría Popper)” [Ibíd.]

Lo siento no tengo definido “falsarla” pero asumo como evidenciar un fallo <<Asumido>>

“Siguiendo a Popper, hasta que no la pueda falsar la premisa, sigue siendo válida. Por lo cual en tanto y en cuanto funcione no la debería abandonar. El camino contrario es el del crítico, pues siempre resta una prueba mas para estar seguro, para estar seguro de que nunca la podrá validar en un 100 %” [Ibíd.]

Efectivamente esto es así y para mi criterio personal descansa necesariamente en la ingeniería inversa del modelo, es decir desarmarlo nuevamente.

“Si se producen discrepancias, sucede lo que comente en mi email anterior.
  1. Se aplicó en forma correcta el método (check list)
  2. Los instrumentos funcionaron correctamente o eran defectuosos (retroalimentación)
  3. No se produjo ningún error humano. (variable de mayor riesgo)
  4. Dadas las mismas condiciones se producen los mismos resultados (discrepancias) (Bitácora de trabajo)” [Ibíd.]
“Entonces el Modelo no es Completo, pues no se condice con la realidad” [Ibíd.]

Efectivamente, DSN_XP considera que el modelo debe estar sujeto a continuo perfeccionamiento, no es estático, debe reflejar al menos ligeras modificaciones, la manifestación de un fallo se expresa por la presencia de ruido en el canal de retroalimentación, el software no es estático es dinámico y mutable maleable.

Un cambio cualitativo se presenta en la idea de “The Matrix” lo cual es posible gracias a la nanotecnología y al conocimiento parcial del manejo del genoma humano. <<Diferido>> <<OffTopic>>

“Aquí debe tener presente el término Completo y no Erróneo” [Ibíd.]

Estoy muy claro de ello :o)

“La Física de Newton no es Errónea, solo es más incompleta que la Física de Einstein, pero dentro del contexto adecuado la física de Newton sigue siendo válida” [Ibíd.]

Esta es la respuesta a un dilema que pretendía abordar como segunda fase al dilema del CVDS, y que consiste en:

¿Un modelo puede entrar en caducidad? <<Diferido>>

Sin embargo debo manifestar nuevamente que esto lo concluí como premisa de mi metodología por la razones explicadas en el párrafo anterior.

“Ahora si tenemos un problema. Algo no encaja en el Modelo con lo cual quedan dos problemas. O cambiamos el Modelo o cambiamos la lógica” [Ibíd.]

<<Sin comentarios>> :o)

“Ninguna de las dos cosas es algo que se pueda resolver en forma rápida, y pueden necesitarse muchos años antes de que a alguien se le ocurra un nuevo modelo o una nueva lógica” [Ibíd.]

<<Experimentación>> :o)

“Por ejemplo y yendo a Sistemas” [Ibíd.]

<Importante> :o)

“ La Programación Procedural nos indica como hacer procedimientos, lo cual en principio parece lo más natural del mundo” [Ibíd.]

No “parece” mi estimado Osvaldo, ¡es! un proceso natural del pensamiento humano, esta es la concepción del software como herramienta, y se conoce bajo mi metodología como la “Perspectiva de los procesos”.

“Entonces poseo un Procedimiento para cocinar un huevo, pero luego si quiero cocinar el huevo de otra forma debo escribir otro procedimiento y luego si en lugar de un huevo quiero cocinar un pollo, necesito otro procedimiento y así sucesivamente” [Ibíd.] <<Top_down>>

Efectivamente lo que has descrito lo conozco como “polimorfismo”

“Podría tener la mala idea de poner a todos los procedimientos juntos en un mismo programa y entonces empezar a modificar todo el conjunto” [Ibíd.]

Esto mi estimado Osvaldo es aplicable a los dos métodos OO y no OO o a cualquiera, ¿es una falla en el diseño? :o)

“Cuando a alguien se le ocurre cambiar el proceso para rostizar al pollo o cuando a alguien se le ocurre agregar la cocción de una torta, y así sucesivamente debiendo 'toquetear' el código anterior para incorporar el nuevo procedimiento” [Ibíd.]

Esto mi estimado Osvaldo me parece muy interesante, por un lado estoy 100% de acuerdo contigo, esto implica necesariamente en considerar a la arquitectura software como una herramienta más en el proceso del diseño del software (ingeniería software).

Por otro lado de ser inmutable esta premisa del modelo centralizado, ¿cómo se explica que justamente el modelo inverso, es decir aceptar que tienes que “toquetear el código fuente” (que debe ser abierto por consecuencia y aplicable a la ingeniería inversa) puede considerar seriamente en rehacer completamente el modelo? <<Open source>>

Y por otro lado, esta es la idea que se quiere conseguir en el diseño de los denominados “Agentes” <<diferido>> o sistemas expertos.

“Pero si cambiamos de enfoque, la cosa cambia” [Ibíd.]

Esto lo conozco como el uso de perspectivas (Arquitectura DSN_XP)

“Consideremos que tenemos un ambiente denominado Cocina en donde existen una cantidad de objetos” [Ibíd.] <<Límite del sistema>>
“Cocina, Batidora, Mezcladora, Refrigerador, etc.” <<Diagramas de clases>>
“Y que definimos las clases y hacemos interacturar los alimentos con los elementos de cocción” <<Perspectiva dinámica: Casos de uso y escenarios, modelo por contrato>>
“Podríamos entonces generar métodos específicos e individuales para diversas comidas” <<Diferido: Top_down>>
“De la misma forma en que un Cocinero adapta su experiencia cuando debe cambiar de Cocina o de Receta” (base de conocimientos) <<Necesidad de una arquitectura interna más robusta y sujeta al cambio>>
“Pero en nuestro ambiente no existía ni Freezer, ni Horno a Microndas, estas son nuevas Clases que se han incorporado a nuestro ambiente” <<nótese que se referencia a la influencia del hardware y a un cambio en el entorno>>
¿Cambia esto en algo a nuestros procedimientos?

Efectivamente que sí; se reconoce que la “Visión de los procesos” es más inestable que la de los datos. :o)

Los procesos del negocio tienden a cambiar. <<Factor de riesgo>>

“¿Podrá haber ahora nuevos `procedimientos' (métodos) para las viejas recetas?” [Ibíd.]

Efectivamente que sí ¿no entiendo la pregunta? A menos que se trate de indicar que no es posible modificar la estructura interna de los datos con la presencia de nuevos atributos, lo cual puede permitirse con un nuevo tratamiento a la vista de los datos según la arquitectura ANSI-SPARC :o) o a la capa del manejo de los datos.

Entonces la pregunta es ¿Es correcto utilizar la visión de los datos para el diseño del software?

“¿Podremos incluir nuevas recetas?” [Ibíd.]

Nuevamente me he perdido, me parece que evidentemente que sí, si el enfoque de tu pregunta va por el lado nuevamente de los datos, la respuesta es que efectivamente es muy crítico depender en el diseño de la representación de la estructura física de los datos (problema Y2K) lo cual pone en evidencia al uso del diagrama Entidad/Relación y sus derivados como UML. :o) <<¿Modelo incompleto?, ¿falla en el diseño? => ¿metodología errónea?>>

(Message over 64 KB, truncated)

domingo, 2 de julio de 2017

DSN_XP y el ENEAGRAMA

DSN_XP.FRAMEWORK.1.0