Hola Diego,

>Lo que vos llamás, "los resultantes de las metodologías", en realidad
> creo que son los resultantes de lo que las personas hacen diciendo
> que "aplican dicha metodología".

Si, exacto, "la metodología" no es nada, es solo un modelo (dado
por una instrucción).

>Me parece que si un profesional se lava las manos, no pasa por si
> es ingeniero, astronauta o smalltalker; sino por una cuestión
> de falta de ética/experiencia.

Justo eso es lo que decía.
Tomando como ejemplo los resultantes de la labor de los ingenieros,
no pasa solo con los ingenieros; pero los incluye.

Mi motivante es poder tener este diálogo en un nivel apropiado
para esta lista, en términos de ambientes, sistemas o cibernética;
por eso no me entusiasma que mis palabras sean entendidas
(o usadas) para intentar hablar de ingeniería.

un cordial saludo,
Ale.


----- Original Message -----
From: "Diego Alvaro Pereira" <pianobarsnm@...>
To: <smalltalking@...>
Sent: Saturday, July 30, 2005 7:19 AM
Subject: Re: [objetos] Ingenieria de Soft


Alejandro, retomo momentaneamente unas cosas medias viejas, pero ya que
estoy escribiendo...

>Simplemente allí en el límite... 1 + 1 no es 2.
>Las reglas no se cumplen; luego los resultantes de las metodologías
>divergen de lo planeado.
>En ese punto (de divergencia) el ingeniero, quien está mas instruido,
>emparcha, ata con alambre, y sale del paso, en lo que a él le concierne
>y queda afuera de los "efectos colaterales", que obviamente
>pensarán sobre los no instruidos, los mas débiles

Lo que vos llamás, "los resultantes de las metodologías", en realidad creo
que son los resultantes de lo que las personas hacen diciendo que "aplican
dicha metodología".
Me parece que si un profesional se lava las manos, no pasa por si es
ingeniero, astronauta o smalltalker; sino por una cuestión de falta de
ética/experiencia.

La metodología no tiene resultados, no viene con un librito que te dice "vos
hacé esto así, agarrás dos 1's y te va a dar 2", sino que podríamos decir
que más o menos te plantea un camino para llegar con dos 1's lo más cerca a
un 2 basándose en la experiencia pasada.

Es como utilizar patrones cuando construimos, depende del criterio
elegirlos, utilizarlos, adaptarlos completamente a nuestras necesidades.

En todo caso, en ingeniería, utilizás herramientas y metodologías
convenientemente que te ayudan a construir.
Está en vos elegir las herramientas, combinarlas, adaptarlas, y seguir los
pasos que creas necesarios para llegar a tu objetivo.

Podrías tranquilamente elegir trabajar en un ambiente, y no dejás de ser
ingeniero ni de aplicar la ingeniería de software.

Si elegís seguir un ciclo "iterativo incremental", simplemente encontrarás
una idea/guia de cómo es ese proceso en algún que otro libro o paper.
El ingeniero que lo aplica tal cual está en el dibujo sin adaptarlo a la
realidad de su problema, es un ingeniero falto de criterio.

Entonces, creo que hay una confusión muy grande, y muchas veces no queremos
abrir la cabeza y pensar que los demás no son todos tontos, y se dan cuenta
que tienen que aplicar las cosas con criterio y como les conviene según el
problema, sin casarse con ninguna metología, sino haciendo uso de ellas para
el beneficio del grupo/proyecto.

En ingeniería nunca se plantea que 1 + 1 = 2; sino que tenés que llevar la
ciencia a la práctica para lograr ese resultado que vos esperás de la mejor
manera posible (aquí juega la subjetividad y el criterio).

En este marco, creo completamente conveniente el uso de la ingeniería en los
sistemas, como una aproximación valiosa sin descartar ningún otro tipo de
práctica.
Saludos,
_________________________________________
Diego Alvaro Pereira
----- Original Message -----
From: Alejandro F. Reimondo
To: smalltalking@...
Sent: Thursday, July 21, 2005 3:21 AM
Subject: Re: [objetos] Ingenieria de Soft


Hola Pablo,

>Otro elemento necesario: las metodologías. Se las usa, pero aún no
>en forma madura. En otro e-mail mencioné que uno tiene que adaptar --o
>crear-- la metodología al proyecto, y hoy en día se pretende lo
contrario:
>adaptar el proyecto a la metodología... Esto está mal desde el vamos y
hace
>agua por donde lo analices... Esto, en parte, tal vez responda otra de
las
>preguntas que hiciste, la segunda sobre elementos de ingeniería.

Pero pensas que hay que seguirle agregando piezas a "la teoría"?
Es decir, que solo faltan mas objetos/reglas/metodologías...

A mi a veces me da la sensación que si están muuuuy desarrolladas;
que están desarrolladas al máximo y rindiendo al máximo.
Llegando a su limite.

>Pero es cierto que, hasta que no haya madurez en la disciplina, las
>empresas --y me refiero por "empresas" a sus capitalistas-- seguirán
>suponiendo que es más sencillo y efectivo trabajar y dominar una única
>metodología para todo lo que hagan y, mientras los ingenieros no lo
tengan
>claro, no se les podrá negar esta forma de pensar por falta de elementos
>para refutarla...

Es decir.. pienso que las personas hacen las cosas bien,
lo mejor que pueden.
Simplemente allí en el límite... 1 + 1 no es 2.
Las reglas no se cumplen; luego los resultantes de las metodologías
divergen de lo planeado.
En ese punto (de divergencia) el ingeniero, quien está mas instruido,
emparcha, ata con alambre, y sale del paso, en lo que a él le concierne
y queda afuera de los "efectos colaterales", que obviamente
pensarán sobre los no instruidos, los mas débiles
[donde dice ingeniero, podes poner cualquier título que
implique haber tenido una instrucción metódica]

En sistemas esto se ve comúnmente, por ejemplo, en equipos de trabajo,
donde el trabajo mas difícil (por lo poco modelable) queda en manos de
gente que hace cosmética o mantenimiento... que no es la gente mas
instruida.

No creo que esto sea porque la gente es mala, :-)
sino porque lo que nos dan los métodos son instrumentos
para ser exitosos SOLO en los puntos de nuestro interés.
Y sobre lo demás... se nos enseña a pensar que siempre
habrá otro a quien le interese juntar el cartón...

>Hay, también, otros temas relacionados con los métodos.
>Por ejemplo, veo bien usar prueba y error en donde corresponde,
> habiéndolo predefinido, estando planeado. Pero esta disciplina
> está tan inmadura que se usa este
> método para todo y sin querer, como en forma inevitable...

Porque pensas en que siempre es necesario aplicar un método?
Veo que hasta prueba y error, lo llamás "método"...
No nos estaremos excediendo al usar la palabra método?

Si todas las alternativas las podemos formalizar en un método...
todas son el mismo método (todas palabras del mismo lenguaje).
Creo que es valioso encontrar un punto de vista más amplio,
que nos permita "escapar al método".

>Con tu comentario, muy acertado para mí, "... aparece la idea que
>faltaba, se agrega, y se sigue contento hasta la próxima. Objetando así,
>siempre a las personas y evitando la reflexión sobre esas iteraciones y
sus
>consecuencias"... te estás respondiendo, también en parte, lo de los
>elementos de la ingeniería... ¡La reflexión sobre las iteraciones y sus
>consecuencias ES algo que la ingeniería DEBE hacer! Bien, eso falta y nos
>muestra una rama inmadura.

Creo que no muestra una rama inmadura.
Creo que muestra un limite en el método,
límite insalvable, insuperable.
Nunca alcanzará el alambre para atarlo todo
y las consecuencias de su aplicación...

>>>No importa cómo se desarrolle, ni con
>>> qué lenguaje o herramienta,sino
>>> hacerlo bien y con método
>>> --valga esta redundancia.
>>Oops!, perdón. Dónde está la redundancia?
>Hablando de ingeniería, "hacerlo bien y con método" es algo
>redundante... Si dijéramos "hacerlo bien" basta... :o)

Puede ser con método y no estar bien.
Pero peor aún, puede estar bien y causar daño.

Allí es dónde esta el problema principal de la formula de
la "eterna superación incremental".
No reconoce el daño.
Nos pone a los humanos en el mismo orden de los animales,
casi te diría en el orden de los objetos.

Te preguntaba sobre los "elementos que faltan" en la ingeniería,
pues creo que por mas que le pongan será lo mismo.

El limite no presente hoy se revela en la falta de ética.
Ese componente distintivo de los humanos, ese carácter reflexivo
que nos permite sentirnos pecadores.
Allí es donde esta el regulador no formulable por una teoría (pues
es del espacio del lenguaje, y no del espacio humano).
Quienes han sido muy bien instruidos, por lo general
han sido pobremente educados en lo que concierne
a la atención de los consecuentes de sus acciones.

Por esta razón es muy importante el disponer de medios
que permitan a las personas experimentar la sensación
de culpa sobre lo que hacen.
Un ambiente de objetos virtual, es un medio que permite
experimentar con sensaciones que no son posibles
usando lenguajes (o actividades formales). Permite
realizar actividades en dónde en todo momento
la persona esta guiando un sistema (su sistema)
a través del tiempo de una forma ESTABLE
y que produzca satisfacción.
Tanto la estabilidad como el goce son componentes
principales de la interacción hombre/ambiente (valga
la imprecisión).

El realizar actividades formales e informales en un ambiente,
no implica que luego de un tiempo podamos/deseemos
definir un formalismo para ponerla toda dentro de una
metodología...
No porque no podamos hacerlo, sino porque solo
tendríamos una reducción de lo que hacíamos.
Es decir, porque implica una perdida.

hasta pronto,
Ale.


----- Original Message -----
From: "Pablo Fernando Sanchez" <p.sanchez@...>
To: <smalltalking@...>
Sent: Tuesday, July 19, 2005 1:27 AM
Subject: RE: [objetos] Ingenieria de Soft


Estimado Alejandro:

Hola, tanto tiempo. Espero que estés bien.

Respondo...

> Que elementos/características de valor
> podemos esperar de una "ingeniería
> de software madura" ?

Muchos... por ejemplo y en primera instancia, que la gente de
Computación sepa de lo que habla cuando habla de Software, que no lo
confundan constantemente con Sistemas --como ocurre--, que se entienda que
son dos ramas de la ingeniería distintas englobadas, junto a otras, dentro
de la Computación.

Otro elemento necesario: las metodologías. Se las usa, pero aún no
en forma madura. En otro e-mail mencioné que uno tiene que adaptar --o
crear-- la metodología al proyecto, y hoy en día se pretende lo contrario:
adaptar el proyecto a la metodología... Esto está mal desde el vamos y
hace
agua por donde lo analices... Esto, en parte, tal vez responda otra de las
preguntas que hiciste, la segunda sobre elementos de ingeniería.

Pero es cierto que, hasta que no haya madurez en la disciplina, las
empresas --y me refiero por "empresas" a sus capitalistas-- seguirán
suponiendo que es más sencillo y efectivo trabajar y dominar una única
metodología para todo lo que hagan y, mientras los ingenieros no lo tengan
claro, no se les podrá negar esta forma de pensar por falta de elementos
para refutarla...

Entonces, podríamos preguntarnos cómo se logra la madurez si las
empresas encaran las cosas de tal forma que juega en contra de dicha
madurez. Pues... en realidad no todas... siempre hay algún que otro loco
que, en esto o en cualquier otra cosa, hace girar la rueda y revoluciona
el
mundo. O sea, es cuestión de animarse nomás... :o)

Hay, también, otros temas relacionados con los métodos. Por ejemplo,
veo bien usar prueba y error en donde corresponde, habiéndolo predefinido,
estando planeado. Pero esta disciplina está tan inmadura que se usa este
método para todo y sin querer, como en forma inevitable...

Con tu comentario, muy acertado para mí, "... aparece la idea que
faltaba, se agrega, y se sigue contento hasta la próxima. Objetando así,
siempre a las personas y evitando la reflexión sobre esas iteraciones y
sus
consecuencias"... te estás respondiendo, también en parte, lo de los
elementos de la ingeniería... ¡La reflexión sobre las iteraciones y sus
consecuencias ES algo que la ingeniería DEBE hacer! Bien, eso falta y nos
muestra una rama inmadura.

>>No importa cómo se desarrolle, ni con
>> qué lenguaje o herramienta,sino
>> hacerlo bien y con método
>> --valga esta redundancia.
>
>Oops!, perdón. Dónde está la redundancia?

Hablando de ingeniería, "hacerlo bien y con método" es algo
redundante... Si dijéramos "hacerlo bien" basta... :o)

El resto, de acuerdo contigo. Saludos cordiales.

_________________________________
Pablo Fernando Sanchez, MIEEE
The Institute of Electrical and Electronics Engineers
IEEE Región 9, América Latina y el Caribe
Editor en Jefe del NoticIEEEro
p.sanchez@...
http://www.noticieeero.org/

Móvil: +57 3 315 644 9678
Fax: +1 240 255 7572
Skype: pfsanchez
MSN Messenger: p.sanchez@...
Yahoo! Messenger: p_f_sanchez
ICQ: 8703027
AIM: ChanzesKland



-----Mensaje original-----
De: smalltalking@...
[mailto:smalltalking@...]
En nombre de Alejandro F. Reimondo
Enviado el: Lunes 18 de Julio de 2005 12:38
Para: smalltalking@...
Asunto: Re: [objetos] Ingenieria de Soft


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005




Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo
en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm

Enlaces de Yahoo! Grupos








Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm




----------------------------------------------------------------------------
--
Enlaces de Yahoo! Grupos

a.. Para visitar el sitio web del grupo, andá a:
http://ar.groups.yahoo.com/group/smalltalking/

b.. Para cancelar tu suscripción a este grupo, enviá un mensaje a:
smalltalking-unsubscribe@...

c.. El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio
de Yahoo!.