(03-03-2013 01:17)Imakuni escribió:  Si, pero no sobre el diseño, si no sobre que va a ser más conveniente/rapido o me va a traer una ventaja luego.

Si decido usar RUP porque el la cultura del cliente definitivamente no cuadra con una metodología agil, es más que claro que no es una decisión de diseño, ni sé como puede impactar en el mismo. Si tengo que sacar una release cada tres semanas, porque necesito agregarle valor rapido a un producto, porque si no al cliente no le sirve, estamos ante una desición comercial, y no sé como eso puede impactar en el diseño.

En el primer caso, si tenes muchas preguntas sin responder sobre los requerimientos del diseño, y la cultura de la empresa no te permite tener trato con los usuarios/product owner/quien te valide, es un hecho que el diseño va a estar basado tus suposiciones sin validación empírica. Ahí te enfrentas con una decisión, o encontras alguna forma de validar lo que haces, o seguís trabajando con suposiciones. Cada suposición va a ir tirando el diseño para diferentes lados, por ahí te conviene hacerlo lo más flexible posible. Probablemente implique más trabajo, porque flexibilidad generalmente implica que varias cosas van a tener que ser soluciones más genéricas, pero cuando logras un proceso de validación podes adaptarte al feedback con menos esfuerzo.

En el segundo caso, ¿no sabes como lo puede impactar en qué momento en el tiempo?. Si tenes que generar valor rápido, sabes que lo importante es validar el diseño "funcional", después dependerá de tu habilidad como programador sacar algo lo más robusto posible (y probablemente con muchas notas sobre como refactorizar a futuro, como IOU de deudas técnicas ).

Obviamente todo esto es muy en el aire, cada situación tendrá sus particularidades y sus limitaciones. Quizás en el primer caso tomas todas las decisiones correctas de diseño al boleo, avanzas sin considerar de que quizás le hayas pifiado, y te sale todo bien. Quizás en el segundo caso sos un programador excepcional, y sacas código que no solamente genera valor al toque, sino que está perfectamente organizado, con abstracciones intuitivas y reutilizables.

---

(03-03-2013 01:17)Imakuni escribió:  Si bien no hace mucho que estoy laburando (4 años creo), nunca oí que se elija una u otra metodología de desarrollo por un tema de diseño, si no más bien, por un tema de cultura empresarial, necesidades del cliente, cuestiones comerciales, conveniencia con el cliente, mayores posibilidades de captarlo, etc....

Convengamos que es raro seguir una metodología al pié de la letra. Si se elije una metodología por una característica particular que funciona en el contexto, se va a tratar de mantener la característica particular, pero si se percibe que se puede generar más valor modificando el resto de la metodología, probablemente se va a modificar. Y hay veces que generar más valor implica validar el diseño de forma diferente a como lo plantea la metodología.

No sé si es a eso a lo que te referís. Obviamente que acá no hay ningún tipo de linealidad, diseño afecta metodología y metodología afecta diseño. Va, depende que tan purista seas con la metodología.

Cita:En el primer caso, si tenes muchas preguntas sin responder sobre los requerimientos del diseño, y la cultura de la empresa no te permite tener trato con los usuarios/product owner/quien te valide, es un hecho que el diseño va a estar basado tus suposiciones sin validación empírica.

Ahora, si no tenés preguntas sin responder? O sea, si se hacen bien los documentos de RUP?

Y... ¿Que pasaría si se implementa Scrum mal?

¿Si ambas metodologías se implementan bien? ¿Que cambia del diseño?

Para mi, lo que puede cambiar el diseño es la falta de requerimientos (como bien decis), pero es algo totalmente independiente de la metodología que uno utilice. No veo todavia como asociar metodología de trabajo con diseño.

Si, como vos decis, puedo ver que usando alguna metodología agil te va a llevar talvez a hacer más refactorings que un rup bien implementado.
Pero ante casos iguales (mismo requerimiento bien definido, mismo tiempo para terminarlo) no veo el caso en el que uno diga "Voy a hacer X diseño porque estoy usando agile", o "Voy a hacer Y diseño porque uso RUP". Diferencia que si noto, si eligieses Scala en vez de Java, o si haces una app desktop frente a una web, o si tenés un "relevamiento" bien hecho frente a tenerlo mal hecho (cosa que puede suceder tanto en un RUP con un requerimiento funcional mal definido, como en scrum con lo mismo, más un product owner que no te da pelota).

Por eso, bajo mi punto de vista, puede afectarte el lenguaje, la plataforma, el sistema en si, el tiempo que tengas, las "obligaciones técnicas" que te impongan, o lo cerca que estés al requerimiento funcional real. Pero no el utilizar tal o cual metodología. Si, va a afectar el trabajo que uno haga, pero ante situaciones iguales de tiempo, expertise, recursos, e información, no veo que cambie el diseño del sistema utilizando metodologías distintas.


Igual nada, parece que esto da para un debate mucho más largo .

Buenas .

Ok, en principio "Hibrido entre las 2 catedras" me hace un poco de ruido... Tuve la fortuna de cursar con Paula Suarez y la desdicha de que tenga contenidos netamente de los lineamientos de Donadello y francamente debo decir solamente me lleve un par de cosas de esa materia: Diagramas de Entidad-Relacion (hasta ahi nomas) y sintaxis UML. No se como seria un "hibrido" entre eso y no me quiero imaginarlo...

Otra cosa que me hace ruido es lo que dicen muchos:"No deberia programar en la materia, deberia concentrarme en algo mas abstracto y no practico". Hay una realidad detras de todo esto, digo, tenemos un mercado laboral en donde los Sistemas de Informacion son el 90% software, por lo que plasmar en una hojita y no programar para ver como son las cosas no me parece una buena opcion... Pedagogicamente palpar la realidad te da otra perspectiva totalmente diferente de las cosas... Muchos saben que ya hace un tiempo soy ayudante de pdep, desde el 2008 mas o menos, y con el tiempo vas viendo las distintas camadas de alumnos que aparecen. Aquel alumno que llega a paradigmas sin haber programado nunca, practicamente le tenes que enseñar nuevamente todos los conceptos basicos de programacion. Enseñarle que es una asignacion, un retorno, un condicional.. Eso se nota, y mucho...

(03-03-2013 02:11)Imakuni escribió:  Pero ante casos iguales (mismo requerimiento bien definido, mismo tiempo para terminarlo) no veo el caso en el que uno diga "Voy a hacer X diseño porque estoy usando agile", o "Voy a hacer Y diseño porque uso RUP".

Por eso, bajo mi punto de vista, puede afectarte el lenguaje, la plataforma, el sistema en si, el tiempo que tengas, las "obligaciones técnicas" que te impongan, o lo cerca que estés al requerimiento funcional real. Pero no el utilizar tal o cual metodología. Si, va a afectar el trabajo que uno haga, pero ante situaciones iguales de tiempo, expertise, recursos, e información, no veo que cambie el diseño del sistema utilizando metodologías distintas.

¿No te parece que el diseño producto de una integración continua basado en feature lists de un Product Owner va a ser diferente al diseño producto de documentos con varios autores en un proceso con varios roles separados que meten mano?

Digo, en el primer caso el método puede generar una tendencia a dejar de lado algunos aspectos, como la consistencia y simplicidad en el diseño del producto (un producto es más que una feature list), y problemas que puedan surgir de la refactorización constante. En el segundo caso, se puede tender al "programador como obrero" que no puede opinar oficialmente sobre cosas que no sean el código, pero como es el que formaliza el diseño es el que puede tener que ir validando el diseño funcional. Si yo comienzo a diseñar el programa en función de ciertos documentos, y a la mitad del trabajo me doy cuenta que hay partes de los documentos que están erradas, puede ser que por limitaciones de tiempo/dinero no pueda tirar el código y empezar de cero, y necesite comenzar a parchear. Eso termina afectando el diseño técnico.

Quizás yo lo veo así porque pienso en el diseño integral (funcional/interacción + programa/técnico) como una tarea en grupo, y en sistemas relativamente grandes, más que algo individual.

(03-03-2013 02:11)Imakuni escribió:  Igual nada, parece que esto da para un debate mucho más largo

Se. Y ya extendimos bastante el offtopic

---

(03-03-2013 09:45)Aivan escribió:  "No deberia programar en la materia, deberia concentrarme en algo mas abstracto y no practico".

No creo que nadie esté a favor de cosas no prácticas.

Llevar a la práctica es, la mejor manera de entender las cosas. Claro está que el foco de diseño de sistemas no es que salgamos siendo gurús de la programación, sino simplemente usar el código como herramienta, del mismo modo que en muchas otras materias (paradigmas, por ejemplo).
No me imagino mejor forma de dar patrones de diseño (por ejemplo) que viéndolos con problemas reales, aplicados en soluciones reales.

(03-03-2013 09:45)Aivan escribió:  Buenas .

Ok, en principio "Hibrido entre las 2 catedras" me hace un poco de ruido... Tuve la fortuna de cursar con Paula Suarez y la desdicha de que tenga contenidos netamente de los lineamientos de Donadello y francamente debo decir solamente me lleve un par de cosas de esa materia: Diagramas de Entidad-Relacion (hasta ahi nomas) y sintaxis UML. No se como seria un "hibrido" entre eso y no me quiero imaginarlo...

Paula se fue porque no aguantaba todo eso...

Cita:¿No te parece queíentos con varios autores en un proceso con varios roles separados que meten mano?

Si, el diseño va a ser distinto, porque las condiciones de trabajo son distintas, y la manera de trabajar es distinta. Pero repito, no me imagino que pueda tener una duda de diseño y decir "esta desición de diseño es mejor para rup" o "esta desición es mejor para scrum". Uno siempre tiende a hacer el "mejor diseño" que le parezca, ya sea usando una u otra metodología. El diseño final va a cambiar porque se toman caminos distintos. Al igual que cambiaría si usamos RUP, y tenemos a un flaco que tiene experiencia en lo que el cliente necesita.

Como scrum, rup, etc, habla de como nos vamos a organizar como equipo, como vamos a sacar métricas, o que proceso vamos a seguir para desarrollar la solución, me parece que es más normal, y más correcto, meter este tema en Ingenieria de Software, en vez de en Diseño de sistemas.

También, me parece que hay otras cuestiones que afectan el diseño de manera más directa y predecible, y sin embargo no se deben ver en dicha materia, como lo es el presupuesto.

Cita:Se. Y ya extendimos bastante el offtopic

No se, para mi no es offtopic , mal que mal estamos definiendo el alcance de lo que pensamos que debería de ser la materia. Estaría bueno que alguien más se prenda (?)

Creí que ya habíamos coincidido en Procesos de Diseño como una unidad, pero no el foco de la materia .

(03-03-2013 12:28)Aye escribió:  Llevar a la práctica es, la mejor manera de entender las cosas. [...]
No me imagino mejor forma de dar patrones de diseño (por ejemplo) que viéndolos con problemas reales, aplicados en soluciones reales.

Te puedo mostrar soluciones reales para problemas reales sin escribir una línea de código y vas a ver que lo vas a seguir entendiendo. Para mí, programar en diseño está de más. Pero, como dije antes, tampoco es un crimen de lesa humanidad desarrollar un poquito y dar ejemplos de esa índole. Hace a nuestra formación profesional.


Ahora, un poquito sobre lo que estuvimos hablando hasta recién:

Es increíble como esta conversación esta teñida del clásico "perjuicio" que tenemos los estudiantes de sistemas para con nuestra propia carrera. Ahora que aparece una alternativa diferente para la materia que más escándalo generó en estos últimos años (alternativa en la cual se introduce aunque sea un poquitito de programación), muchos se preguntan si esto está bien y empiezan a buscar opiniones diferentes; lo cual creo, sin embargo, que está buenísimo: no tenemos que conformarnos con cualquier cosa y es una buena idea medir en que cosas está acertando y en cuales se equivoca la nueva cátedra.

En mi opinión, lo único negativo de todo esto es el despiole que se generó. El final de Diciembre fue cualquier cosa, y hasta donde tengo entendido el de Febrero/Marzo fue de un tinte parecido pero sin libro abierto... Eso no hace nada bien a la calidad de la enseñanza y creo que más allá de cualquier diferencia que pueda haber entre los miembros viejos y nuevos de la materia deberían sentarse a dejar algo definido (no se si ya lo hicieron, no tengo mucha info al respecto). O deberían hacer el cambio definitivo y a la lona. Los únicos que perdemos con algo así, somos nosotros. Esperemos que la gente nueva de diseño siga aportando a la materia y pueda imponerse, creo que más allá de todo, vienen con muchas ideas copadas y van a darle más valor a nuestra carrera.

el cambio definitivo no es tan facil porque "no podes echar a un profe asi nomas"

sobre todo si gano por concurso.

tenes que esperar al "vencimiento" y en el nuevo concurso, no gane/no se presente (lo cual probablemente ocurra)

Si pongo el ejemplo de operativos, si yo te explico conceptualmente lo que es un segmentation fault, te conte un cuentito. Cuando te lo tira el tp, lo entendes.
Para mi esta bueno que tengan que programar algunas cosas en diseño. La teoria se asienta cuando la llevas a la realidad

yo ni la hice, ni tengo experiencia, ni nada; recien la hago este año asi que no voto </disclaimer>

pero en sistemas y organizaciones me chamuyaron que tenemos que manejar todo el ciclo de vida de un sistema (incluido diseño y implementacion)
y si bien son dos etapas distintas estan relacionadas, calculo que se puede enseñar separado y que el alumno se avive

a mi personalmente me parece que siendo que es una materia integradora deberian mostarte como se relacionan, y eso deberia implicar la cantidad de programacion que amerite (y pareciera que amerita)

El tema es que no tenes ninguna materia sobre implementacion ni sobre testing (ojala la gente de IS finalmente arme esa electiva)... y asi como en analisis de sistemas te hacen hacer un relevamiento "real" como TP y la documentacion en base a eso, aca necesitas ver un poco de codigo para diseñar bien bien bien

Más allá de programación orientada a objetivos, ¿qué incluiría la materia?

PD: No dije nada, tengo el plan de la cátedra nueva.

Bueno, me gustaría aportar en esta discusión, un poco para contar mi postura como docente pero más aún para disipar algunas dudas sobre lo que se estuvo haciendo este año, porque veo que corren muchos rumores que son inexactos.

No sé si es este el lugar donde yo me ponga a discutir qué tiene que ser diseño o qué no, pero al menos me gustaría dejar asentada nuestra visión al respecto, porque siento que corren rumores que no sé de dónde salen pero son bastante alejados de la realidad. Les pido que verifiquen, con los docentes de cada curso o con los que efectivamente han cursado, qué fue lo que nosotros hicimos o cuáles son las ideas que tenemos sobre cómo dar la materia y no se dejen llevar por versiones que nadie sabe de dónde salen y con qué intención se dicen.

Por ejemplo si escucharon por ahí que "en diseño se da Java", quiero aclarar que es totalmente falso y que está muy lejos está de nuestra postura hacer algo así. Que una materia de una universidad, se convierta en un curso en el que se aprenda un lenguaje sería una barbaridad. Y lo pienso no sólo para diseño, sino incluso para una materia de programación. Tampoco es nuestro objetivo impartir conceptos de programación. Sí pasa que utilizamos esos conceptos, de la misma manera que en Física utilizarán cosas que aprendieron en Análisis Matemático y eso no convierte a Física en Análisis.
Java fue una herramienta que usamos, como también algunos usaron el Enterprise Architect para hacer diagramas UML o el Word para hacer las entregas. No creo que se pueda decir que diseño sea un curso de Enterprise Architect o de Word.
De paso les cuento que Java es una herramienta que utilizamos el año pasado y que este año la vamos a reemplazar por otras.

Hechas esas aclaraciones, me permito ir a algo más complejo y más profundo. La pregunta sería: ¿por qué necesitamos un lenguaje?, ¿por qué hubo que programar en el TP? Personalmente pienso que un diseño es una especificación de cómo se debe construir o cómo está construido un sistema. Entonces el diseño tiene una relación fuerte con la programación (como también con el análisis, pero lo dejo para otro día), simplificando podés pensar que uno diseña para luego programar; de la misma manera que si un ingeniero civil hace un plano lo hace para construir una casa. Obviamente puede pasar que lo que yo diseñé lo programe otro, que lo tercerize, pero "se tiene que poder programar", nadie aceptaría un plano de un ingeniero civil que no pueda garantizar que la casa que el diseñó se puede construir.
El problema que aparece (y tal vez acá se acaban las similitudes con la Ing. Civil) es que en el momento en que uno está aprendiendo, a veces es difícil darse cuenta de los problemas que tienen nuestros diseños. Es muy frecuente encontrar en los laburos diseños que alguien hizo en abstracto y que cuando se quieren bajar a código no cierran. Es muy difícil para alguien que piensa por primera vez un patrón como el decorator, imaginarse cómo eso luego funciona, por eso, creemos que puede ser una herramienta útil bajar a código algunos de los diseños que hagan durante el año.
En nuestra experiencia, de algo así como 10 años enseñando temas como patrones, bajarlos a código es fundamental para terminar de entenderlos, es llevarlos a la práctica. No quiere decir que el objetivo de la materia sea ese programa, pero el programa sirve para "visualizar" las consecuencias de lo que uno diseñó.

Tampoco yo pienso que lo que hicimos el año pasado haya sido perfecto, fue la primera puesta en práctica de muchas ideas nuevas, y seguro que necesitan ajustes (muchos de los cuales fueron propuestos por los que cursaron, en las encuestas). En particular creo que la porción que implementaron del tp podría haber sido menor. También por una cuestión de simplicidad les pedimos a todos que programen en un único lenguaje, este año van a poder implementar en cualquier tecnología que conozcan (o que tengan ganas de aprovechar para aprender).
Incluso preparamos una propuesta para un posible TP que deja abierta la posibilidad de hacerlo sin incluir ni una línea de código. Como decía, creo que se pierde algo al recorrer ese camino, pero en esta etapa de transición y hasta que haya un consenso en cuanto a la forma definitiva de dictar la materia, creemos que puede ser una alternativa aceptable.

No la quiero alargar más, pero si ustedes miran otras materias, incluso de otras carreras, van a encontrar mil ejemplos de que en materias similares a "diseño" uno necesita buscar alguna forma de hacer una pequeña implementación, una maqueta, un prototipo de lo que diseñó. En diseño de sistemas es incluso más complejo, porque las metodologías modernas cada vez más proponen intercalar las tareas de diseño y de programación (a diferencia de las metodologías que eran preponderantes cuando yo estudié, que proponían tener todo el diseño listo antes de empezar a programar), pero aún así debemos hacer el ejercicio de no confundir cuál es el objetivo de la materia y cuál no.

En fin, como decía, no creo que sea conveniente que yo me ponga a discutir acá sobre lo que debería ser diseño, hay otros ámbitos para eso. Pero al menos quería contarles mi postura con respecto a lo bueno y lo malo que se hizo el año pasado, lo que estamos planeando para este año que empieza y los principios que guían lo que espero poder hacer en el futuro, para que lo escuchen de mí y no se guíen por cosas que se dicen por ahí.

Saludos! espero haber aclarado algunas dudas, cualquier cosa, me pueden preguntar.
Nico Passerini