¿Que metodologías usas para el analisis y diseño?

[[movorack]]

5 años despues... GRACIAS por compartir sus puntos de vista, experiencias y conocimientos en este tema.

me lo volveré a leer mañana con menos sueño...

[Casimiro Noteví]

No me había dado cuenta de la fecha
No recuerdo haber visto este tema, qué pena.
Pero por si acaso el amigo Delphius sigue todavía dándole vueltas al asunto, yo soy partidario de una metodología "propia". Cuando iniciamos un nuevo proyecto lo que hacemos es tomar notas muy claras y detalladas de TODO el programa, hablamos sobre cada cosa que pueda surgir, de cada campo, de qué tipo de ser, por qué, qué casos pueden darse que no sean "los normales", qué problemas y beneficios, etc.
O sea, el análisis y diseño es primordial, obligatorio, necesario, decisivo, capital, principal, básico, crucial, fundamental... a la hora de desarrollar un software, es como los planos de un arquitecto que tienen que estar listos antes de hacer el edificio.
En mi experiencia puedo poner un ejemplo de proyecto:
Anáilsis y diseño 3 meses
Desarrollo del programa hasta tener una versión funcional: 4 meses
Finalización y entrega del mismo: 2 meses.
O sea, de 9 meses total, los 3 primeros fueron de análisis y diseño.

Estoy de acuerdo en muchísimas cosas que ha comentado el amigo mamcx, salvo en uml, me parece que es un embrollo terrible y estoy convencido que desaparecerá.

[[Delphius]]

¡Hola!

Vaya que se han puesto a revivir un hilo viejo. Ya estaba acumulando polvo

Les comento que con el tiempo me di cuenta de que es inútil intentar buscar el modo de formar un nuevo lenguaje genérico... lo único que veía es que estaba reinventando la rueda.

En estos últimos años he cambiado la forma de ver esto, al comienzo iba con la idea de que se empleaban paradigmas puros como USDP pero luego empecé a darme cuenta que resulta mucho más valioso el conseguir un proceso que vaya madurando y que sea constante. Este proceso se establece y se desarrolla en base a la propia experiencia del equipo por tanto es un modelo único y propio.

Es mucho más probable un enfoque mixto de diversos paradigmas, y agregarle condimentos propios... a esa conclusión he llegado. Después de todo en realidad los paradigmas de desarrollo no establecen paso a paso como han de hacerse las cosas sino más bien que PROPONEN un esquema o marco de trabajo en general y en como han de ordenarse las macro-actividades. Las actividades reales se definen teniendo en cuenta cada proyecto en forma particular.

Las herramientas con que cuenten es de menos, mientras con ellas puedan llegar al producto final.

Disculpa que te lleve la contraria Casimiro, pero al igual que Mario considero que UML llegó para quedarse. No va a desaparecer... más bien evolucionará, de no ser ser así no existiría UML 2.0 y tengo entendido que ya están en proceso de borrador de 2.5.

UML está hecho para quienes deseen hacerlo. No a todos les gusta, ni les resulta. En lo particular considero que es una buena herramienta de trabajo.

No es fácil adoptar UML, sobre todo si uno lleva años sobreviviendo sin él. Debe haber una total puesta de conciencia: si vas a utilizarlo, utilízalo bien sino déjalo. Esta misma idea va para cualquier otra cosa: si vas a encarar un proceso de control de versión hazlo bien, no a medias... sino mejor ahórrate el trabajo.
El cambio no debe hacerse obligadamente brusco, puede ser gradual. Pero la idea tras esto es que si uno quiere adoptar una herramienta que la use, pero no porque quiera probar si con ello tendrá más suerte y logrará aumentar la productividad y la calidad... sino porque tiene la confianza suficiente de que con su uso su trabajo le resulta ventajoso.

Con el tiempo, consciente o inconscientemente, uno va desarrollando un proceso gradual y toma nota de las armas que les agrada y le resulta útil.

A mi me gusta UML, defiendo su uso. He estado llevando (y llevo) un proceso de aprendizaje y de maduración. Del mismo modo estoy en una fase en donde estoy aprendiendo y asimilando ideas de como ordenar la casa: en lo que hace a organización de actividades, de documentación, de testeo, etc.
No interesa si haces código o UML primero, eso dependerá de las necesidades y la forma en como uno encara el proyecto. El asunto está en que si utilizas UML, le saques el provecho.

Y no es para volverse loco haciendo mil diagramas, no... así no es... ¡haz lo que consideres que te ayudan a aclarar ideas! Ni más ni menos.

Al comienzo tenía la idea de que todo debía hacerse bien formal, estructurado, rígido, con pasos bien definidos... "que debía hacerse si o si de esa forma". Pero luego empecé a relajarme de esta idea... y entiendo que no necesariamente hay que hacer todo y de todo. Actividades más sueltas, ligeras, flexibles, dinámicas pueden ofrecer mejores resultados sin estar presionando demasiado. Lo importante es lograr un proceso que nos lleve a los resultados, empleando las herramientas que nos aporten utilidad.

Saludos,

[Casimiro Noteví]

Amigo Delphius, te aconsejo que leas esto (por qué uml no sirve) cuando puedas, es de Javier Smaldone, un paisano tuyo al que admiro bastante.
Yo también andaba con la idea de aprender a usar uml, lo pedían en todos los trabajos que veía, debe ser algo fabuloso... pensé. Pero estuve echándole un vistazo, haciendo pruebas, leyendo documentación, etc. y me parecia que algo no encajaba "con la vida real". La lectura de ese documento me hizo desistir de uml

[mamcx]

Bueno, desde entonces aplico casi al 80% todo lo que dije.

Ahora sigo mas bien las ideas de http://gettingreal.37signals.com/.

Para lo de los bugs/ideas estoy usando www.pivotaltracker.com y la verdad es muy intuitivo. Junto a la metodologia scrum (lo mas importante: Se planea a maximo 1/2 semanas al futuro).

Al iniciar estoy haciendo wireframing & sketchs basicos en un tablero de esos que se escriben con marcador.

Sin embargo, creo que este metodo funciona mas para quienes creamos productos que no son tomados de un cliente (o sea, creamos productos desde 0 sin consultar a nadie).

Para cuando es un desarrollo a la medida, no se que tan valido sea...

[[Delphius]]

Empezado por Casimiro Notevi

Amigo Delphius, te aconsejo que leas esto (por qué uml no sirve) cuando puedas, es de Javier Smaldone, un paisano tuyo al que admiro bastante.
Yo también andaba con la idea de aprender a usar uml, lo pedían en todos los trabajos que veía, debe ser algo fabuloso... pensé. Pero estuve echándole un vistazo, haciendo pruebas, leyendo documentación, etc. y me parecia que algo no encajaba "con la vida real". La lectura de ese documento me hizo desistir de uml

Me voy a poner a leer el enlace. No te prometo que cambie mi visión, estoy muy convencido de UML.
Se que no debería sacar conclusión apresurada pero me voy a aventurar el porqué UML no funciona (y es en parte algo de lo he dicho en el post anterior): UML, como cualquier otra herramienta de trabajo, funciona si uno le pone trabajo y le da valor agregado. Está consciente de ello, puede sacarle provecho.
Si uno no lo toma con total seguridad, seriedad y dedicación entonces... ¿de que manera puede llegar a sacar una buena conclusión?

Saludos,

[Casimiro Noteví]

Cuéntame cuando lo leas

[[Delphius]]

Hola,
Bueno, me he leído el artículo... es un tanto viejo.

Con todo respeto amigo, si yo fuera el profesor de Javier lo mando a primer año de la carrera.... ¡no pudo haber dicho lo que dijo! Confundir y mezclar UML con el Proceso Unificado es... no se, no se me ocurren palabras. Admito que es común equivocarse cuando uno recién está estudiando el tema... pero... de alguien que ya lo conoce y lo ha estudiado... ¡no tiene perdón!

De allí en adelante no tiene sentido seguir avanzando... el Mencino en sus comentarios lo ha puesto muy en claro. Quizá de una forma un tanto brusca, pero en fin... aclara todo... no tengo más que corregir porque el se encargó de explicar punto a punto los temas.

Hay que tener en cuenta que la carta del dichoso estudiante también se ha expresado teniendo como base a UML 0.8 y 0.9 cuando recién se estaba formalizando... inicialmente tuvo sus fallas, lo reconozco, pero en la 1.0 ya salio maduro y tuvo una amplia revisión en la 1.5. Al día de hoy quizá su opinión al respecto ha cambiado. El artículo de Javier es del año 2006... para ese entonces ya estaba la versión 1.5... Es totalmente incongruente que haya dicho semejante cosa.

Quizá Javier sepa mucho, pero en ese artículo orinó muy fuera del tarro, con todo respeto.

UML es muy bueno, si alguien lo usa y aprende a usarlo.

Habrá gusto para todo, si alguien lo usa y le sirve, perfecto... si alguien prefiere no utilizarlo y le va bien... perfecto. Esto vengo diciendo desde hace dos post. Pero de aquí no me venderán la idea de que no sirve.

Por ello digo, y sostengo, con toda seguridad, de que uno debe ir encontrando las herramientas que le sean de ayuda.

Admito que UML ofrece un amplio abanico de diagramas, una semántica rica y eso lo puede hacer parecer bastante complejo y amplio pero el propósito de ello es brindar la mayor posibilidades de expresión de las ideas. Ideas que nacieron para ayudar al programador. Luego queda en el programador en saber elegir cuando, como y cuanto utilizarlas.
Dicho sea de paso, UML es lo suficientemente flexible como para no indundar de redundancias a nuestros diagramas. Muchos elementos de los diagramas son opcionales, y se le deja la posibilidad al diseñador de utilizarlos cuando este lo crea conveniente para aclarar algunos puntos que pueden introducir ciertas ambiguedades.

UML quizá no sea perfecto, pero es una herramienta más que uno está en la absoluta libertad de usarla o no.

Si Javier, en el momento de escribir ese artículo no lo ha entendido, es problema suyo. Me falta terminar de leer los últimos comentarios, voy por el comentario de Sam del 25 de junio del 2008... voy a ver si ha respondido a sus críticas.

Lo siento Casi si te molesta que haya tirado algunos palos a esa persona que estimas amigo.

Saludos,