¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?
 

He seguido al hilo saber si un año es biciesto... y se me vino a la mente una pregunta... ¿Hasta que nivel de ramificaciones se estaría dispuesto a llegar para hacer una funcionalidad?
He notado como estas funciones y muchas otras... hacen llamadas tras llamadas... y más llamadas...
Veamos:
A -> B -> C -> D ->....

Si bien ya se ha respondido a la duda de JM75... y se he encontrado al culpable (IsLeapYear). Mi duda va por una cuestión de diseño: ¿Hasta que nivel estarían disupesto a declarar unidades y funciones para "simplificar la vida"?

La VCL está llena de ejemplos de estos tipos... me parece bárbaro que haya cantidad y variedad de funciones para hacer más fácil la vida de un programador. Pero me abruma un poco la cantidad de volteretas que se puede armar... en especial cuando uno se inicia, porque empieza a declarar funciones a lo loco y después descubre que si existían... a mi me sigue pasando...

¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?

No se si se hacen estas preguntas o el loco soy yo... A ver que opinan, escucho opiniones, sugerencias...

Saludos,

Bueno, yo en esta cuestión soy bastante "básico"; Si ya se ha "inventado la rueda" y la fuente del invento es fiable, no hay porqué reinventarla.
Considero el código de Borland como muy fiable; Puede ser que haya alguna función que no esté optimizada al máximo, pero seguro que el 98% del código puede ser tan fiable y eficiente que el que pueda hacer yo.

La experiencia me dice que los "cuellos" de botella de una aplicación (al menos por las que yo me muevo) no "suelen" estar en una función como IsLeapYear (por muy ineficiente que sea), sino en sitios muy diferentes (índices, consultas, listas, busquedas, repintados,...). Así que salvo que sea necesario no suelo "pelearme" a este nivel.
Sí lo he hecho alguna vez (la última con la unit SysUtils y el procedimiento InitializePackage), pero como digo es algo muy excepcional.

Creo que la Modularidad a la larga añade complejidad (en el sentido de llamadas como las que comenta Seoane), pero aporta otras cosas.
Es la discusión de siempre;
Lo más eficiente: Programar en ENSAMBLADOR. :D ....discutible.....;)

Yo es que no entiendo esta pregunta. Me parece que se están mezclando dos cosas: modularización y reuso.

En el caso del año bisiesto el problema es que se crea una modularización innecesaria debido el reuso incorrecto de funciones.

Y bueno, aunque no se trata de abusar, creo que a hoy en día, unos cuantos elementos más en el stack no presupondrán un grave problema, sobre todo si lo comparamos con la claridad que puede ganarse al modularizar una rutina. Creo que mientras la modularización no devenga en pulverización, no hay problema.

// Saludos

Yo también no estoy del todo convencido con este debate y por una simple razón.

Todo depende del tiempo y de las circunstancias, (siempre me ha gustado esta frase :D), bueno, quiero decir que depende mucho de quien se este hablando porque no es lo mismo mi estilo de programar (por cierto considero que no lo hago nada bien, pero intento hacerlo) y el estilo de roman o de seoane, neftali, etc que son muy diestros para hacerlo.

Para esto también hay niveles de conceptualización muy personal.

Sin embargo, si puedo decir que lo mejor es lo que dijo Neftali, no tratar de inventar la rueda pero agrego que si podemos intentar mejorarla.

Salud OS.

No tienes abuela, ¿verdad? :D :p :D

Saludos

Programación atómica
 

¡Hola a todos!

Soy partidario de la atomización del código, es decir, de dividir rutinas en sus fragmentos funcionales más elementales. Esto maximiza el aprovechamiento del código (reutilización), además de permitir un mantenimiento menos invasivo, más preciso y menos riesgoso (no es lo mismo tomar una simple llave de 3/8 y apretar con ella una tuerca perfectamente accesible e identificada, que ponerse un traje de buzo para bajar a donde está el submarino nuclear, buscar la tuerca floja de su casco, abrir la caja de herramientas...).

Con ciertos lenguajes y compiladores, atomizar el código supone limitaciones importantes. Por ejemplo, algunas versiones de FoxPro no soportan más de cinco niveles de llamadas (una verdadera vacilada). Herramientas como Delphi están más preparadas para eficientar el código y con la nueva característica In-line de las versiones más recientes del compilador, la atomización ya no supone un mayor consumo de recursos en el ejecutable (de por sí, dicho consumo extra casi nunca resultaba significativo).

Considero que en el futuro el estilo de la programación atómica estará altamente difundido y será común encontrar normativas de desarrollo que inviten al programador a no escribir funciones de más de 15 o 20 líneas. Llegará un momento donde las bibliotecas de rutinas y componentes estén tan atomizadas que sus diversas partes podrán acoplarse sin mayores problemas para construir nuevos elementos de software, aún en otros lenguajes y para propósitos muy distintos, y habrá tanto y tan variado y flexible código reutilizable que cualquier rutina nueva que se quiera escribir tendrá gran riqueza de átomos de dónde echar mano.

Se me ocurre que podríamos hacer un ejercicio a este respecto, pongamos aquí el código de una función Delphi con más de 20 líneas y atomicémosla explicando las ventajas del nuevo código resultante. Domingo, tú que eres aficionado a estos ejercicios, ¿tendrás alguna función así para compartir? :)

Un abrazo optimizado.

Al González. :)

:confused: Por curiosidad, ¿que llamadas comente?.

Por otro lado, ya que me meto, dejo mi opinion. Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas :p

Yo personalmente cuando estoy desarrollando un algoritmo complicado encuentro muy útil usar funciones para dividirlo en problemas mas sencillos y poder resolver cada uno por separado.

Hola
Yo ni opino.
Nada mas veo y aprendo.:D
Si no digo algo no me llega por correo.:D
Cuando los maestros se reunen hay que estar presente.:)
Saludos

Estoy de acuerdo con seoane, el maestro de seoane y también con Al González; pero, como dije antes, no hay tampoco que caer en la pulverización del código y separar en una función cada simple paso de la función original.

// Saludos

Y si no me lo digo yo ¿Quién me lo va a decir? ;)

Perdón, me refería a este tipo de llamadas:
A -> B -> C -> D ->....

...y fue Delphius quien la comentó... :(
(raise TIncorrectQuote.Create('Se equivoicó de persona');)

Debajo del boton Responder, en el menú herramientas, tienes la opción "suscribirse a este hilo", pero claro, si lo usas.... no aumentas tu contador de mensajes :p

Saludos

Neftali, no discuto el hecho de que hay que reinventar la rueda o no. Yo sólo estaba comentado que es muy común en los iniciados en declarar funciones que ya estan implementadas (y vamos... que no es por ignorancia... sólo es porque desconocían su implementación).
Un iniciado, por conseguir una buena modularidad empieza a repartir las funciones en módulos... y llega a cosas como:
A -> B -> C -> D -> E ->....

Es correcto lo que hace... pero uno llega a preguntarse: ¿Hasta que punto sería fiable? Hay métricas que determinan un valor en base al juicio del desarrollador, pero también existe un "grado de duda" al momento de estar diseñando.

No discuto de que sean fiables... de seguro que si. Creo en que lo que realizó Borland es un producto espectacular. Pero... me abruma un poco el hecho de los círculos viciosos que puede formarse por los encadenamiento de las funciones.

Totalmente de acuerdo que estos encadenamiento pueden añadir complejidad... pero también reconozco que tiene sus ventajas.

Disculpa roman si no me entiendes la pregunta... debí formularla de otra forma. No te enojes pero no coincido contigo en lo de modularización y reuso.
Si bien son dos palabras diferentes... son dos palabras que vienen mucho de la mano. Si yo he entendido bien el concepto para lograr una gran reusabilidad es necesario contar con un buen grado de modularización. Y a la inversa: una buena modularización permite un mejor uso. No se puede separar ambos conceptos totalmente, hay una línea delgada que los mantiene unido. Y creo que encontrar esa línea delgada es lo más complicado de hallar. Si estoy equivocado, avisenme... porque llevaría años equivocado.

Como tu comentas... es cierto que se consigue una modularización innecesaria por hacer uso de las funciones "incorrectas". Pero... volvamos al caso del novato (por ejemplo... yo). Un novato... declara y declara funciones... que ya vienen incorporadas... No se da cuenta de que puede evitar este comportamiento (no por ser ignorante... las buscó pero no bien). Le funciona... Por lo tanto sigue con su trabajo. Obedeciendo su instinto de que desea hacer un buen trabajo separa bien los módulos... y sigue haciendo su trabajo... al estilo del problema del año bisiesto. ¿Lo está haciendo mal? Si y No. Podría hacerlo mejor... si. No es una persona cerrada y empieza a armar un diseño rápido de todos los módulos... saca una cuantas hojas sábanas y arma una linda carta de estructura (por poner un ejemplo) y nota un gran despliegue de módulos.
Se pregunta: ¿Hasta que punto conviene llegar?
Y vamos.. que esto no sólo se consigue con las funciones "innecesarias", aún con las correctas se puede armar un buen lío.

Es cierto que esto es un tema subjetivo. No hay un único dictamen y es por ello que armo este debate. Quisiera ver sus opiniones en el asunto.
Pero también existen herramientas que la ingeniería del software han venido aportando. Hay métricas que permiten ofrecer una medida de lo bien que se tiene modularizado... se sabe que no es un valor rígido y que hay que obedecer pero es buen estimativo.

A ver... la pregunta que debí haber formulado sería algo así:
De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado?

Al, yo también soy partidario a particionar el código. Yo dentro de mi esquema de trabajo impongo esa actividad... pero tal como dicen otros... tampoco hay que decaer en el extremo (que ya me pasado) de partir una función en muchos pedazos que poco o nada hacían por si mismo.

Es buen criterio... yo como amante de las métricas me armé (aparte de usar la ya existentes) un juego de métricas y estimadores para decidir hasta que punto es recomendable.

Pero Caral, hombre, te invito a que dejes tu opinión en el tema. Que tienes experiencia, y puede ser enriquecedor tu aporte.

Bueno para finalizar... repito:
De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado?

Disculpen si el debate no tiene sentido... pero me pareció una buena idea, ver los aportes de grandes de estos foros. Yo lo hacía con el fin de aprender y comparar mi modo de entedimiento de lo que es este mundillo de la ingeniería del software.

Saludos,

¡Hola a todos!

Hubo un tiempo en que solía caer en el extremo y hasta pena me da ver algo de ese antiguo código. Pero, como empirista que soy, hube de llegar al extremo (tocar fondo) para apreciar las desventajas y entonces atomizar el código sin rebasar esa delgada línea donde un If se convierte en un IIf sin gran ahorro de código ni ganancia de inteligibilidad.

Insisto en que pongamos un ejemplo de función Delphi de más de 20 líneas de código nativo y hagamos el ejercicio de atomizarla. Nos permitiría acercar criterios en esta materia y establecer una norma teórica.

Un largo abrazo.

Al González. :)

Puesto que tienes la experiencia... ¿quien mejor que tú para buscar un ejemplo?.

Saludos insistentes :D

:) Hola a todos.
Estoy de acuerdo con seoane y su profesor:
Aunque no soy tan drástico al respecto. Yo también tengo bloques de programa un poco mas extensos que eso. Pero, por lo general, trato de resumir los algoritmos para aclarar mi panorama. A los módulos trato de darles nombres bien significativos. Siempre trato de usar parámetros, pero en poca cantidad. Y casi siempre reviso en forma rápida el código completo.
En conclusión (:rolleyes: y es mi modesta opinión):
chau...

Yo intento aplicar esta máxima en la programación porque, como dice seoane (más o menos) al dividir un problema grande en problemas más pequeños y fáciles de solucionar, el problema grande se hace más fácil de solucionar.

Aun así, cuando programo en C suelo unir esas rutinas pequeñas en una única más grande que después optimizo, pero antes he escrito y comprobado el sistema "atomizado".

Antes que nada, aclaro que yo en ningún momento me enojé, ¿por qué había de hacerlo? Solo dije que no entendía la pregunta y expresé mi opinión.

Ahora, estoy completamente de acuerdo con este párrafo tuyo:

Yo opiné que eran dos cosas distintas, nunca dije que no estuvieran relacionadas.

Pero sigo sin entender el sentido de tu duda.

Creo que todos tenemos más o menos claro y estamos de acuerdo en ello, en que la modularización promueve el reuso y sólo hay que tener cuidado de no caer en la pulverización de código, tal como sintetiza Al:

Sin embargo, si tal modularización produce llamadas en cadena

donde A' hace lo mismo que A, creo que todos concordaremos en que es incorrecto.

¿Es esto culpa de la modularización? ¿Tu duda va en ese sentido?

Quizá en algunos caso lo sea, pero eso no es óbice para modularizar, es sólo algo que debe revisarse y evitarse.

// Saludos

Coincido con todos en general, pero si hablamos como ya lo mencione de los estilos de programar y haciendo uso de lo dicho por Al

yo estoy convencido de que la modularización va de la mano con la experiencia y de las nuevas funciones que te permiten reducir código hasta lograr la optimización.

Les pondré un ejemplo de lo que hacia con Delphi 16 bits y lo que hago ahora con Turbo Delphi y aún creo que no es lo óptmo.

En uno de mis sistemas y que desarrolle su primera versión hace ya algunos años, requiero de calcular la duración desde dos variables de tipo string de fecha y dos variables de tipo string conteniendo la hora.

con Delphi 16 bits

Código Delphi [-]
Function TLector.CalculaDuracion(FI,FF:String10;HI,MI,SI,HF,MF,SF:String2):String8;
Begin
  FIDate := StrToDate(FI);
  FFDate := StrToDate(FF);
  If FFDate = FIDate Then
     begin
       val(HI,HT,Code);
       val(MI,MT,Code);
       val(SI,ST,Code);
       DurIni   := CalculaSegundos(HT,MT,ST);
       val(HF,HT,Code);
       val(MF,MT,Code);
       val(SF,ST,Code);
       DurFin   := CalculaSegundos(HT,MT,ST);
       DurTotal := DurFin - DurIni;
       ConvDuracion;
       CalculaDuracion := DurHrsS+':'+DurMinS+':'+DurSegS;
     end
  Else If (FFDate - FIDate) = 1 then
          begin
            val(HI,HT,Code);
            val(MI,MT,Code);
            val(SI,ST,Code);
            DurIni   := CalculaSegundos(HT,MT,ST);
            DurIni   := 86400 - DurIni;
            val(HF,HT,Code);
            val(MF,MT,Code);
            val(SF,ST,Code);
            DurFin   := CalculaSegundos(HT,MT,ST);
            DurTotal := DurFin + DurIni;
            ConvDuracion;
            CalculaDuracion := DurHrsS+':'+DurMinS+':'+DurSegS;
          end;
End;

con Turbo Delphi

Código Delphi [-]
function CalculaDuracion(FI,FF,HI,HF:String):String;
Var
   FechaHora : TDateTime;
begin
   if TryStrtoTime(TimetoStr(StrtoDateTime(FF+HF)-StrtoDateTime(FI+HI)),
              FechaHora) then Result := TimeToStr(FechaHora);
end;

Que pasó, bueno, resulta que mi inexperiencia me dictó en ese momento que así lo tenía que hacer y me bastaba, ahora con TD encontré que todo ese rollo lo podía resolver en una sola línea, yo me imagino que hay algo mejor que eso, pero siendo sinceros me falta mucho para poder optimizarlo.

Yo me declaro inconpetente en hablar o discutir eso de atomización, ni siquiera entiendo el concepto aún, pero vamos, la idea principal que quiero expresar es como determinar lo que Delphius inicia como debate.

De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado?

Mi sentido común me dice Tolerancia CERO entre Modularidad y Complejidad, mi experiencia (o mi inexperiencia) no puedo medirla, eso es lo que hoy se, el día de mañana y sobre todo aqui en el club me dira otra cosa.

Salud OS.

Yo creo que la atomizacion del código simplifica en mucho el mantenimiento poterior ya que a todos nos pasa que despues de cierto tiempo se nos olvida un poco como iba el algoritmo sobre el que trabajamos para hacer x cosa. >Con código atomizado podemos llegar a tener cosas como esta:

Muy entendible no?
Claro que tambien depende del estilo o "convenciones" que usemos en el código ya que si nombramos las funciones con nombres que no vienen al caso pues se pierde la utilidad de la atomización y se complica la cosa. En mis inicios en Pascal acostumbraba usar sintaxis en inglés para casi todo, posteriormente empece a revolver inglés con español y ahora solo uso español. A veces ponia nombres como "SeekFileNombres" o "BuscarFiles"...ahora me dan risa.

Otra práctica que de repente uso es la de hacer todo sucio y rápido y luego irlo partiendo, asi pues llego a tener funciones muy grandes que luego voy dividiendo y optimizando, asi por lo menos mis aplicaciones funcionan a a primera y las voy mejorando..

Asi es, ya lo veo claro, de hecho yo lo hago asi, genero funciones y procedimientos encapsulando codigo de la forma como lo planteas tu, pero esto mas por sentido practico que por conocimiento.

Salud OS.

Yo siempre uso el inglés (aunque mi lengua materna sea el castellano) lo encuentro mucho más compacto. Nunca recuerdo si he usado el infinitivo o un tiempo verbal (Busca / Buscarrr) en el nombre de un procedimiento. Lo mismo con el singular y plurar, o con los artículos y preposiciones, que son muy incómodos (De, Los, El, etc).

No mezclo jamás inglés con español en el nombre de una función solo con conceptos del propio Software, por ejemplo: IdToAlbaran o IdToFactura.

Por este lado del charco, Grilla es la hembra del Grillo [...] ¿las maquillas y las peinas :D :p ?. Yo, personalmente , prefiero algo así como "SetGridHeader"; en español sería "EstablecerCabecerasDelGrid". "Preparar" es abstracto, nunca identifico lo que hace y acabo mirando la función.

Por otro lado, uso propiedades (property) siempre que puedo [...] Pero creo que me estoy saliendo del hilo jejeje.

En cuanto a lo ocurrido con la función "CalculaDuracion" es muy normal. Yo usaba mi función "InsertBreakLine" para romper una cadena larga al llegar a XX caracteres, Ahora recién veo WrapText de la unidad SysUtils en BDS2006 que me hace sonrojar :D (muy posiblemente también esté en delphi 6... no sé).

Saludos

Crítica con ánimo de construir
 

Una pregunta:

Es correcto que cuando estemos frente a un problema complejo o enredado lo particionemos en otros más pequeños. Incomprensible sería no hacerlo. Y a todos nos pasa que hacemos algo que ya fue hecho o es nativo del lenguaje. Es parte del aprendizaje. Y cuanto más nos suceda, más conocimiento tendremos y más experiencia.


Decir:

es un sentimiento normal. La duda está; pero en la medida que se pueda, y con el tiempo, uno aprende a evitar esos círculos viciosos (ó prefiero decir fallas).


Yo creo que la modularización siempre ocurre antes que el uso o el reuso. Si separo un módulo es para usarlo posteriormente. Al menos una vez. Si lo uso más de una vez, significa que los estoy reusando. Varias cosas se logran con la modularización: uso, reuso, claridad al momento del desarrollo y claridad al momento del mantenimiento, disminución en el tamaño de código, entre otras.

Conviene llegar hasta el punto en que el problema sea legible. Con pocas líneas. Si el problema se torna engorroso hay que particionarlo en módulos que a su vez sean legibles.


El debate si tiene sentido... Gracias Delphius y saludos a todos.

Eso me recuerda:

Relacionado con el tema:

• Lo simple es mejor a lo complejo
• Deberia haber una forma obvia - y solo una - de resolver el problema
• Si la implementacion es dificil de explicar, es una mala idea...

La modularizacion es algo muy complicado, porque hay que entender que cada funcion, clase o unidad *aumenta* el vocabulario de un programa, y todo va sumando:

- El lenguaje +
- El framework basico +
- Componentes de terceros +
- Funciones externas del SO +
- Nuestro propio framework +
- El codigo especifico

Se vuelve muy enruedado. Adicionalmente, en los lenguajes imperativos y compilados no hay mucha flexibilidad y ha veces hay mas codigo del que es realmente necesario. No ayuda el que existan constantemente nuevos paradigmas en pugna que luchan por acaparar nuestro tiempo y atencion (como los zillones de frameworks de acceso a datos).

Actualmente, trato de :

- Si esta en el lenguaje o el framework basico, OK. A veces intento de escribir lineas mas largas - usando solo el lenguaje - que crear nuevas funciones, pero como alguien mas arriba, tambien caigo en tentaciones, como armar mi propio IIF ;)
- Limitar al minimo el # de componentes de terceros, lo que obliga a buscar y buscar el mejor
- Si un componente de terceros no me soluciona ampliamente una necesidad - y es open source - mejor muevo el codigo necesario a mi propio codigo
- Si es un desarrollo de prueba, hago lo que quiera. Si es algo serio, lo pienso mucho
- Hago un esfuerzo por reducir al maximo el numero de clases y funciones, en vez de aumentarlas. Para ello, es muy util las pruebas de unidad. Otro concepto es ver que tareas hay repetitivas, pero mucho, para reducirlas
- De cuando en cuando suplico que le metan cosas mas potentes al lenguaje de Delphi ;)

¡Hola a todos!

Rejilla.

Un abrazo sin grilla.

Al González. :)

El problema para mí, es que no se cómo expresar eso en palabras.
Creo que más o menos todos tenemos en la cabeza las mismas ideas sobre Modularización, pero ¿cómo cuantificarlo?

Hola
Despues de toda esta explicacion de los maestros, me gustaria dar una opinion autodidacta.
No todo esta inventado.
No creo que exista la funcion perfecta o ideal para todos los programas (Standard).
De acerdo a esto:
Para mi dependeria de la experiencia y del proyecto en si, no creo que se pueda generalizar.
Estoy de acuerdo con seoane en partir el problema para entenderlo mejor, pero mi poca experiencia dice que si no conoces la base no puedes partir nada, entonces partiriamos del conocimiento.
Para mi sencillamente se reduciria a lo dicho, Experiencia y deficinicion del proyecto.
Saludos

A como yo veo el asunto, esta muy bien ser organizado y partir los problemas en pedazos que puedan ser reutilizables.

Un problema es el que comenta Mamcx, todo crece en cuanto lo partes... yo veo librerias como la de "interfazGH" de Al Gonzalez y me parece de lo mejor... pequeñas funciones bien separadas en contexto y todo...

Donde yo veo el problema en tener tantas cosas tan chiquitas es que luego no te acuerdas que es lo que tienes y que es lo que no... y si te acuerdas que ya lo tienes, ahora ¿donde quedó al final?... es como tener una caja de herramientas como el dice pero tener cientos de ellas en la caja... cuando tienes muchas encontrar una en específico es bien dificil, y luego a lo mejor resulta que si tenías hecha la funcion pero le pusiste un nombre que en el momento no recordaste y la pasaste por alto y la volviste a hacer... tal como le paso a Lepe con la funcion esa del BDS2006...

La cuestión tambien no es solo partir sino como es que se documenta o se le hace para encontrar lo que se ocupa rápidamente. tampoco es la idea de leerse los encabezados de todas las funciones de la unidad para encontrar la que busco, ahi pierdo el tiempo que pude haberme ahorrado.

Bueno... esto lo que yo entiendo...
 

Yo empleo medidas como esas... me gustan los números y veo de que manera me pueden ayudar.

Mi intención es a futuro: que no te enojaras... a futuro.
Vale. Entendido... es que ya me ha pasado en otras ocasiones en que nadie me termina entendiendo y puede que en alguna de éstas le "salten los tapones" (espero que nunca suceda) por hacerme sentar cabeza.

Entendido. Vale. Mejor leo bien las cosas..

Casi: a los efectos inmediatos de esto. Tu bien lo resumes: "sólo algo que debe revisarse y evitarse".

Pues si. El arte de detectar la modularización y optimización se desarrolla con la experiencia.

Si. Se entiende... ahora ¿Cuál es la ganancia que obtuviste?O mejor ¿Cual es el costo asignado para llegar a eso? O ¿La relación entre entendimiento/costo? Ojo... este costo no es simplemente el valor subjetivo del esfuerzo... lleva implícito el valor monetario. Que de última es el precio de nuestro esfuerzo.

Lo de sintaxis en inglés, o en castellano, lo dejo a gusto de cada uno. Aunque yo me he acostumbrado a escribir en inglés (excepto al momento de ofrecerle resultados visuales al usuario: labels, edits, menues, etc).

No pienses que le hecho culpa a los iniciados. Sólo me he limitado a exponer un ejemplo que es típico, usual, común... y por supuesto: mio.

Es cierto... estoy de acuerdo.

Ya nos vamos acercando a lo que quiero tratar de discutir... ¿A que defines legible?¿Le podrías asginar un valor?

Gracias, uno más que considera que esto tiene sentido...

¡Eso es lo lindo de la ingeniería del software!Es una espada de doble filo... y hay que aprender a usarla. Tiene cosas buenas.. y malas...

A tener en cuenta... por lo menos para mi.

[Neftali]
El problema para mí, es que no se cómo expresar eso en palabras.
Creo que más o menos todos tenemos en la cabeza las mismas ideas sobre Modularización, pero ¿cómo cuantificarlo?
[/Neftali]
¡Bingo!

Si bien todos lo han dicho... y yo también... no hay una única manera de responder. Por eso inicié este debate: yo quiero saber ¡hasta que punto le podrían asignar un valor!

Sabía que tu podrías. Sabía que tu tendrías algo que aportar.

Se puede generalizar... hasta cierto punto. Hay técnicas de inferencia para determinarlo... y como ya se ha dicho... depende de la experiencia.
Veamos, una frase que decimos mucho:
Si se sabe que un producto realizado de una manera es similar a otro... pues... lo resolvemos de la misma manera.

¿Se me entiende a lo que quiero llegar?
Creo que este thead es el má largo que escribí... pero sigamos.
No se de que manera lo harán ustedes, yo por mi parte voy a compartir lo que mi pequeño, novato, e infantil cerebro me ha permitido elaborar:

Por cada función/procedimiento/método:
1. Calculo su complejidad ciclométrica
2. Calculo su complejidad computacional
3. Obtengo su ancho de banda: cantidad de parámetros de entrada y salida
4. Obtengo su ancho de operatividad: cantidad de variables y constantes
5. Obtengo las siguientes métricas:
5.1. Utilización de Banda: relación de banda de entrada respecto al ancho total.
5.2. Utilización procedimental: relación de uso de memoria (1- (Variables/Ancho de operatividad)). Cuanto más alto sea el valor se penaliza. En lo posible, tratar de que sea bajo.
5.3. Razonabilidad operacional: determina la relación de uso de memoria respecto al ancho de banda.

Ro = Ancho de Banda/Ancho de operatividad

Este valor lo utilizo para diagnosticar la cantidad de variables que podrían estar en exceso, o que podrían ser eliminadas. Claro está, que al final es un valor subjetivo... eliminar alguna variable intermedia tal vez dificulte el entendimiento del código. Y en ocasiones no se puede eliminar la/s variable/s.

6. Calculo la productividad:
6.1. Productividad de Banda: que determina el rendimiento de los parámetros con respecto a la complejidad ciclométrica.
6.2. Productividad Operacional: que determina el rendimiento de la memoria interna respecto a la complejidad ciclométrica.
6.3. Productividad General: el promedio entre las dos anteriores.

También se puede calcular la productividad en base a las líneas de código.

Cone esto trato de averiguar que "tanto se usa" los parámetros y las variables durante la ejecución del algoritmo. Trato en lo posible de que tener pocos parámetros y menos uso de memoria con el menor código posible.

7. analizo el diagrama de flujo de la función y determino los casos de prueba. Desarrollo los casos de prueba y determino los posibles errores y defectos que tiene la unidad.
8. Con estos datos, y la cantidad de líneas de código obtengo otras métricas.

9. Cuando finalizo con todas las funciones, saco un valor estimativo (media ponderada) para determinar el valor asociado al módulo. A nivel de módulos calculo un valor de la modularidad prediciendo el valor de cohesión. Una estimación que aplico es determinar la utilización que se da a los parámetros y variables que se "pasan" entre módulos. Aquel tipo que predomine... se le asigno al modulo a estos valores lo pondero entre todos los módulos.
Cuanto más bajo sea... es preferible.

También calculo la razón entre el ancho y largo de la carta de estructura. En lo posible trato de que el valor esté en el medio.

Yo me impongo que mi límite de esfuerzo sea del 80%, de modo que el otro 20% se lo dedicaré al posterior mantenimiento.

Con todos estos valores... los promedio (media ponderada y con pesos obtenidos de otros resultados anteriores) y lo normalizo con respecto al tiempo invertido. Por ejemplo si para toda la actividad me tomo 30 días y el valor ponderado es de 12, tengo que: 80% de 30 = 24. Por tanto: 12/24 = 0,5 o 50%. Este fué mi esfuerzo... podría haber mejorado.

A todos estos valores los voy registrando y haciendo cálculos estadísticos de tendencia y reajusto los pesos de las operaciones... y el ciclo comienza de nuevo.
Calculo otras métricas pero no viene al caso.

Si quieren saber quien tiene la culpa de que la locura por estos números: Roger S. Pressman, Yourdon, Craig Larman, y otros loquitos que andan sueltos. Y claro... yo... por hacerles caso.

Se que puede ser un poco extremo... no se... a veces me asusto a mi mismo por la obseción de saber que tan bien hago mi trabajo... Creo que me hace falta unas buenas vacaciones... bien lejos de una máquina.

Saludos, disculpen por el semejante rollo que me he escrito. Escucho comentarios, incluídos los del tipo: "estas loco man... "

[Lepero] Pa'mi que le dah muchah uuertah ar coco, en er tiempo de analizá to ezo, ya tendríah otro pograma echo[/Lepero]

:D :D

Hola delphius, si que te aventaste un buen rollo y si, puedes estar tranquilo "si estas loco" :D:D:D:D.

No, ya en serio.

Despues de leer tu exposición, que cabe señalar es interesante, lo que entiendo es que con esas mediciones estas tratando de encontrar el valor de la productividad en base a la simplificación de código, es decir, encontrar la relación esfuerzo/productividad y llegar a la optimizacion de procesos de producción.

Pienso que estas haciendo lo que se llama ciclo de vida del software, todos en este foro lo hemos hecho de una u otra forma, en pequeña o en gran escala. Algunos trabajando en empresas fuertes, otros en pequeñas y otros como yo de forma independiente.

Todos hemos llevado a cabo los pasos de este famoso ciclo de alguna forma

1. Recoleccion de necesidades
2. Analisis
3. Diseño
4. Implementación
5. Pruebas
6. Validación
7. Mantenimiento
8. Mejoramiento

Hasta aquí todo bien, ese es el ideal de cualquier desarrollador que se precie de ser digamos serio.

Ahora, que pasa en la vida real, aqui solo puedo hablar de mi poca experiencia en el desarrollo de sistemas. No se si tú ya has desarrollado algún sistema vendible, no quiero entrar en el terreno de privativo, digamos solo vendible.

En este momento estoy desarrollando un sistema hotelero, llevo 8 meses o un poco mas y ahora ya tengo una versión digamos BETA, el proceso de desarrollo lo he seguido de acuerdo al ciclo de vida que te menciono.

Sesiones de trabajo con la empresa que me solicitó el producto para ver factibilidad y segmento de mercado al cual se desea introducir el mismo.
Definición de las caracteristicas y alcances del producto
Diseño y desarrollo del producto
Pruebas del producto en su fase BETA

Hasta aquí he llegado, ahora estamos en la etapa de implementación donde hemos negociado con un "usuario final" la instalación del producto (GRATIS) bajo el esquema de retroalimentación con el fin de depurar y optimizar el producto.

Si entiendo bien tu conceptualización, hasta aqui podría comenzar a medir la relación esfuerzo/productividad, y que es lo que me va a dar esa medición, pues yo creo que ponerle precio a mi producto, o no?

Salud OS.

Egostar, tengo bien en claro lo del ciclo de vida, USDP, Espiral, Prototipado, etc...
A mi me gusta muchísimo la ingeniería de software. A pesar de que en el examen de esa materia fue bajo (7 por si quieren saber) a comparación con el resto... pero no me quejo.... me puse nervioso.

Trato en todo lo posible de hacer un buen software. Actualmente estoy trabajando sobre mi tesis. Y esto para mi es absoulta seriedad en lo que hago por varios motivos:
1. Tengo un sistema complejo.
2. Según me han notificado las principales autoridades de la facultad de Ingeniería e Informática de la universidad, hasta el momento es el único proyecto en el norte de mi pais que está tratando del tema(¡vaya presión!)
3. Tengo la intensión de venderlo (sin código fuente). Si... a más de uno tal vez no le guste la idea... pero de algo hay que vivir.
4. Es algo que vengo teniendo ganas de aplicar. Me he inspirado en un proyecto que vi en Discovery (creería que era mexicano) y fue llevado en Delphi.
5. Se trata de algo supuestamente "novedoso" en mi pais.

El máximo objetivo es aprender y compartir lo que yo entiendo sobre esto de la ingeniería del software. No se en que medida habrá gente que aplica estos conceptos pero para mi es muy importante.

Saludos,

Ahhh, que es para tu tesis... Ahora comprendo el por qué de tanta teoría [...] Pues quien sabe, quizás algún día, Delphi integre una opción en el menú Project -> "Detectar esfuerzo" gracias a tí.

No sería tan raro, Borland ya adoptó el VirtualTreeView por ser gratutio con fuentes ;).

Saludos.

Pues eso es lo que hace starteam y las demas herramientas de ciclo de vida...

Aunque una vez las probe,no me convencen (no me refiero a la herramienta,sino a la utilidad real de medir esas cosas....)

Y si la rueda esta mal hecha?
 

Desde mi punto de vista la relacion tiene que estar directamente proporcional al asunto de costo/beneficio, si queremos hacer algo por lo que nos pagaran bien, tenemos tiempo, nos gusta o es muy importante entonces (yo), analizo 100 veces mas uno la mejor forma de realizar lo necesitado, pero como ya expuse en otros sitios, la forma mas optima a la que llegarás sera solo con assembler, luego de haber comprobado que el código realizado es mejor a los tres anteriores realizados por tamaño y velocidad.

En lo de la rueda, mientras sea yo quien cree la rueda tendre el control que quiera sobre los sistemas que utilicen mi producto... talvez en este momento estas usando algo con un backdoor, o talvez lo hizo un "tapado" y esta hecho al huevo pero funciona! La decision debe ser (como todas) la mejor que se adecue al caso particular!

Acabo de ver, una de las tantas presentaciones sobre Delphi 2007 que hay (si recién ahora las estoy viendo... aprovechando banda ancha) cuando me topé con una que trataba sobre calidad. Ustedes saben como me gusta el tema de UML, métricas, y esos bichos raros:D

No pude evitar recordar este comentario mientras veía el video... y bueno...
¿Porqué c... llego siempre tarde para las ideas?:mad:

Hubiera sido lindo que toda esta charla hubiera sido hecha en el 2006 o el 2005... Podría tener una escusa para decirle a Borland/CodeGear: "Hey... la idea fue de Clubdelphi":)

Vine al hilo para sacarme la duda de la fecha en que fue tratado todo esto... pero como podran ver... fue posterior al lanzamiento...:o

Como que se me subió el ego (Dije ego... no Egostar. Hay que aclarar hoy en dia)... sería maravilloso leer en su acerca de: "Idea Original: Delphius":p:D:)

Bueno resucité el hilo solo para esto.
Son las 4:15 am en Argentina, quiere agarrarme el sueño. A ver... si esta vez me le adelanto, aunque sea en sueños:D

Saludos,