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

[[Delphius]]

Gracias por tu enriquecedor aporte mamx, me has dejado sin palabras... bueno casi sin palabras.

Pensaba que esto no sería productivo ni enriquecedor, pero resulto todo lo contrario: aprendí de tus escritos algo que yo no veía: la práctica y la visión real. Lo que me ha pasado es que hasta el momento no tuve oportunidad de ver como es la actividad en una empresa/consultora en forma práctica, sino más bien en un ambiente controlado y simulado durante las horas de clases.

Dentro de poco tiempo tengo que ir a realizar una práctica laboral en una empresa muy reconocida en Salta (Argentina), y lo bueno del puesto (si es que me lo dan) es que voy a tener que ver cómo elaborar las políticas, ver el desarrollo de la actividad, controlar, analizar su ritmo, su cultura, etc... etc... en pocas: Analizar el proceso productivo.

Espero que en esta práctica pueda ver lo que tu brindaste a traves de este hilo. Veo que tu experiencia en el ámbito te ha permitido comprender muy bien a lo que me voy a enfrentar dentro de unos años (¡Que pensamiento tan optimista!).

He leído los enlaces que has expuesto y me gustó muchísimo su contenido. Me tomé el tiempo (obligadamente por cuestiones de salud) para analizar y comprender lo que es realmente la Ingeniería de Software, y me gusta mucho... y estoy más decido que nunca que quiero especializarme en ello.

Bueno, disculpa pero tengo algunas opiniones, que hacerte. Mas que opiniones son dudas:

Empezado por mamx

No deberia ser asi, lo se. Pero es la realidad. Una vez alguien tiene una idea (ej: Haz un software de facturacion) la gran mayoria inmediatamente nos sentamos a codificar sin hacer ninguno tipo de analisis serio, confiando en que en el camino se resolveran las cosas. Y digo "nos sentamos" porque en lineas generales es mi propia experiencia y de lo que conozco de la mayoria de la gente en varias empresas de software. De hecho, es la tendencia mundial.

Yo siempre, desde que tuve Lenguajes I, cada vez que se me ha dicho que "hagan este software", he buscado la manera de analizar y comprender muy bien lo que debe hacer y no lo que debo hacer antes de sentarme a programar. ¿Esto cambiará cuando entre a trabajar a alguna empresa?

Decir tendencia mundial, a mi me suena algo exagerado. No creo que en varios lugares sea así, para mí esto de "Programación sin análisis" sólo se produce en aquellos lugares en donde se valora (y por tanto tienen poder de mercado, de mano de obra, herramientas, conocimientos, y disponibilidades) la programación rápida y en donde el software tiene ciclos de ciclo de vida de entre tres y seis meses. Es decir que la tendencia a elaborar productos a la máxima velocidad y donde lo que vale es el tiempo ante del análisis es en países desarrollados: el Hemisferio Norte (y estoy siendo generoso). En el hemisferio sur no creo que sea así la cosa: ¡América del Sur apenas está entrando en el mercado!

Empezado por mamx

Precisamente, porque nadie lo hace y por eso Rational es una empresa que gana millones de dolares vendiendo un modelo, unas herramientas y consultorias.

Empezado por mamx

Es lo ideal, pero la mayoria del codigo ya esta hecho y se necesita comprenderlo. Sin una ayuda automatica, queda muy dicil documentar un desarrollo existente.

Por otro lado, si miras las ideas que propone la programacion extrema, el orden es codigo y si hay tiempo, UML. El UML no es absolutamente indispensable y se puede diseñar directamente en codigo... pero si es una excelente y mejor herramienta para hacerlo. Obvio que habra quienes piensen otra cosa y ese es el problema...

Rational es Rational, y no cualquier empresa tiene para pagar lo que ofrece Rational. ¿Que hay de aquellas empresas que apenas tienen lo necesario para sobrevivir? Si es muy difícil que éstas apliquen UML, pero si quieren tener un producto de calidad que pueda competir lo mas seguro es que busquen la manera de llegar a ello, ¿A que recurren si no tienen experiencia?Lo más seguro es que tiendan a usar algo comprobado: UML/USDP un poco de CMM o MSF, no creo que se las pasen intentando poner a diseñar un método propio ya que en definitiva esto les terminan perjudicando (tanto en dinero, como en tiempo).

¿Entiendes mi punto de vista? Lo que tu manifiestas, es muy aplicable (de hecho lo obvio es que sea así) para aquellas empresas que tienen dominio, experiencia y poder. ¿Que hay para las otras?¿A que recurren?

Empezado por mamx

Desafortunadamente la enseñanza al respecto no es muy buena. Y el punto es, estamos hablando de quienes, programadores o analistas o ingenieros o??? Si como es el caso de muchos, que iniciamos como programadores, si tenemos de forma caotica los procesos mas elementales, como la manera de mantener las versiones de nuestro propio codigo, de poco o nada sirve el UML.

Tienes razón, la enseñanza no es muy buena. Precisamente por ello, lo que mejor aprendí es lo que investigué por cuenta propia más que por lo que me enseñaron. ¿De quién es la culpa? Pues tanto del establecimiento educativo, de los profesores, de los alumnos, de todos. Si se desea que hayan PROFESIONALES, todos deben poner el 200% de su ganas y fuerzas para conseguirlo. El mayor problema no es que se enseña mal, sino que el estudiante aprende mal (sin olvidar de que es este quien debe poner el máximo empeño, el esfuerzo). No olvidemos también que son los estudiantes quienes deben exigir que se les enseñe bien. Te doy un ejemplo que yo he vivido: En la facultad de ingeniería e informática de mi universidad no se tenía un concurso de profesores desde hace años, y los mismos se limitaban a enseñar menos que lo básico. ¿Que hicimos? Exigimos que se llamen a concursos, que se cambien a los profesores, que las exigiencias sean más duras. Hoy, me siento orgulloso de ser parte del equipo que está haciendo que se enseñe como se debe en una universidad. Si muchos estudiantes (los ingresantes) se están quejando de las exigencias, pero es que hacía falta una mano dura.
Si no se pone orden a lo enseñado, obvio que no sirve de nada aplicar UML.

Empezado por mamx

Haciendo una analogia, es como construir una casa. Obvio que tener los planos es indispensable, pero si los albañiles no saben organizar las herramientas y cada cual tiene su "estilo" de pegar ladrillos, el beneficio de tenerlos se diluira.

Precisamente para ello está UML, para impedir que haya varios estilos. Que haya algo que todos entendamos. Volviendo a lo anterior, si los futuros profesionales han aprendido a organizarse como se debe, aplicar UML desde un principio resulta más útil.
Que existan las herramientas para obtener UML desde el código, se debió (a mi entender) a la falta de cohesión que yo ya he comentado, mas que a ayudar a la optimización/automatización. ¿Realmente es necesario buscar herramientas automáticas para desarrollar el análisis (obvio, descartando el Unit Testing)?

Empezado por mamx

A lo que voy con todo esto y apuntando al objetivo que tienes, es reconocer que el desarrollo de software es en general, muy caotico. No se cumplen los tiempos pactados, la mayoria no sabe como estimarlos, no se satisfacen los requerimientos del cliente y muchas veces, ni siquiera los tecnicos. La calidad de los desarrollos es variable pero no es muy comun un programa de buena calidad de primera vez, y asi por el estilo.

Obvio, Nadie dijo que es fácil, de hecho nada lo es. Yo nunca dije que sea fácil, es más la poca práctica que tuve me ha vastado para darme cuenta de que esto requiere de dedicación de equipo, tiempo, organización y muchas cosas más.

Empezado por mamx

El tener las herramientas es indispensable. Mantener:

- El codigo
- Lo que ese codigo debe hacer (requerimientos)
- El diseño del codigo, en otro lenguaje (UML)
- Lo que ese codigo no hace bien (bugs)
- Los archivos anexos, como manejo de los clientes
- etc...

de forma manual es muy tediosa...y ante el problema, la mayoria de los codificadores elegirian solo mantener el codigo. Agrava el hecho que muchas empresas se NIEGAN a "gastar" tiempo diseñando y se NIEGAN a tener requerimientos por ESCRITO y actualizar los mismos.

Entiendo bien que es tedioso, pero es NECESARIO. Si las empresas quieren tener productos de buena calidad, dentro de sus políticas DEBERÍAN figurar lo que tu expresas. ¿Entonces de que sirve que pongan ganas en buscar algo que no figuran dentro de sus planes?

Empezado por mamx

Y sabes? mi persona ha estado en varios simposios de esto, de ISO, de CMM y de calidad. Mi equipo de desarrollo sabe muy bien UML y todo lo demas. Y sin embargo.. no es suficiente.

Pero Delphius, eso es una gran oportunidad. El UML es parte de un proceso, y hacer que tengo un rol importante seria muy bueno, pero es dificil. De hecho Borland, MS e IBM esperan obtener GRANDES dividendos con sus respectivas plataformas que integran todo eso.

En mi opinion, el UML tiene una aplicacion limitada a la hora de diseñar... o sea, haciendo la analogia con la arquitectura, de hecho un plano no lo cuenta todo y hay varios tipos de planos necesarios para hacer un panorama mas completo y aun asi, se requiere de experiencia practica para unirlo todo.

¿No es suficiente o es que les cuesta sacarle provecho?
Claro que UML es parte de un proceso. La ingeniería de Software evoluciona, y si... UML es sólo una de las tantas herramientas que hay.
A lo que voy es que no es que UML no sirva, sino que hace falta sacarle mucho mas provecho. Por eso es que busco una metodología/lenguaje, ofrecer lo que UML no puede ofrecer al 100%. Lo que estan haciendo Borland, MS e IBM es dar una solución parcial y rápida al asunto: ¿Que crees que pase cuando se descubra que sus plataformas ya no sirvan?¿Haran otras?¿No crees que resulte mas barato hacer una metodología/lenguaje que sea mas sutil, flexible a los cambios, evolutiva y con la capacidad de ampliarse; antes que gastar más en diseñar plataformas?

Se que lo que pretendo es difícil, ¿imposible? no lo se. Otra cuestión es como hacer que lo que pretendo realizar sea reconocido y aceptado por todos.

[[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 Notevi]

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 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

[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,