Ni.

El enfoque del diseño está en el diseño (dah).

Al enfrentar un diseño, tenémos un contexto. Nuestro diseño no vive en "la nada"

Parte de ese contexto es el lenguaje que vamos a utilizar. Al igual que la toma de requerimientos es parte de ese contexto.

"diseñar" por si solo no existe. Nadie te pide "un sistema para manejar bibliotecas" y con eso ya sabemos que diseñar. Tenemos que saber que cosas son importantes, y que no.

Hay que ver ese contexto: No es lo mismo hacer una app desktop, que una web. Hay un monton de buenas practicas que en un caso funcionan mejor (o son moda) y en otros casos no. Por ej, El hecho de desarrollar por capas está de moda en aplicaciones web, el desarrollo por componentes está de moda en aplicaciones desktop. Ambos diseños fueron elegidos por diversos motivos para dichos contextos. Para tomar esta desicion, no hace falta para nada saber como se puede programar, ni siquiera el lenguaje en el que se va a implementar. El saber programarlo, en este caso, es algo trivial.

Ahora, si vamos a algo más profundo.... como, no sé, un decorator, está bueno que sepas como se programa. O saber que herramientas te ofrece el lenguaje, para saber si te conviene utilizarlo, o es preferible hacer otra cosa.

"Diseñar" es algo totalmente práctico. Al diseño no se le puede sacar la parte de programación, porque hay desiciones de diseño que dependen en gran parte de las caracteristicas del lenguaje. Pero tampoco se tiene que basar 100% en eso, porque justamente no es programacion, es diseño.

Resumiendo, ni. No se puede ver diseño sin programar. Pero tampoco gran parte del peso de diseñar algo, depende de la programación.

(01-03-2013 23:50)sebasdp escribió:  Bueno, pero depende el profesor. No recuerdo nombres, pero me han contado que en otros cursos le han dado bastante pelota al TP en Java. E insisto, si según la consideración de quien quede a cargo de la cátedra es importante programar (sin implicar que lo sea o no, estoy planteando un escenario), me parece que hay otros lenguajes que te abstraen más de la implementación y te dejan preocuparte solamente por el modelado. JEE sería una mejor opción. O tal vez ADF, que implica menos programación todavía pero, y esto es un puntazo en contra, no es tan standard.

JEE no es un lenguaje. ADF tampoco.

---

Todavía estoy esperando que alguien salte a favor del "sistemas no es software" y que "diseñar sistemas no es diseñar software".

(02-03-2013 00:11)Imakuni escribió:  Ni.

El enfoque del diseño está en el diseño (dah).

Al enfrentar un diseño, tenémos un contexto. Nuestro diseño no vive en "la nada"

Parte de ese contexto es el lenguaje que vamos a utilizar. Al igual que la toma de requerimientos es parte de ese contexto.

"diseñar" por si solo no existe. Nadie te pide "un sistema para manejar bibliotecas" y con eso ya sabemos que diseñar. Tenemos que saber que cosas son importantes, y que no.

Hay que ver ese contexto: No es lo mismo hacer una app desktop, que una web. Hay un monton de buenas practicas que en un caso funcionan mejor (o son moda) y en otros casos no. Por ej, El hecho de desarrollar por capas está de moda en aplicaciones web, el desarrollo por componentes está de moda en aplicaciones desktop. Ambos diseños fueron elegidos por diversos motivos para dichos contextos. Para tomar esta desicion, no hace falta para nada saber como se puede programar, ni siquiera el lenguaje en el que se va a implementar. El saber programarlo, en este caso, es algo trivial.

Ahora, si vamos a algo más profundo.... como, no sé, un decorator, está bueno que sepas como se programa. O saber que herramientas te ofrece el lenguaje, para saber si te conviene utilizarlo, o es preferible hacer otra cosa.

"Diseñar" es algo totalmente práctico. Al diseño no se le puede sacar la parte de programación, porque hay desiciones de diseño que dependen en gran parte de las caracteristicas del lenguaje. Pero tampoco se tiene que basar 100% en eso, porque justamente no es programacion, es diseño.

Resumiendo, ni. No se puede ver diseño sin programar. Pero tampoco gran parte del peso de diseñar algo, depende de la programación.

Por eso es cuestión del objetivo de la materia.

En la concepción de "diseño" la cátedra "vieja", la idea es que puede existir una etapa anterior a la programación que funcione a modo de "preproducción", de forma que se trate de reducir el impacto de los problemas que surgan en la programación. "Diseña" lo que sepas que no tiene que cambiar, como pueden ser interfaces (UI y entre sistemas) y comportamiento "funcional" (dataflows, workflows, entidades y sus relaciones, cualquier modelo matemático/algoritmo no trivial que vayas a codear, etc.). Todo eso es independiente de la programación, afecta el qué, que no y como programar, y necesita conocimientos diferentes (diseño de interacción, procesos de negocio, estadística, etc, etc). La pregunta es, ¿esto lo debería saber hacer el "ingeniero en sistemas de información"?

Buen, uno es plataforma y el otro es framework. Pero a lo que voy es que son mucho más claros que usar Java pelado para ver algunas cosas, te alejan mucho de la implementación y se enfocan en el modelado. Por lo menos a mí me sirvieron mucho más.

---

(02-03-2013 16:37)Dem0 escribió:  

(02-03-2013 00:11)Imakuni escribió:  Ni.

El enfoque del diseño está en el diseño (dah).

Al enfrentar un diseño, tenémos un contexto. Nuestro diseño no vive en "la nada"

Parte de ese contexto es el lenguaje que vamos a utilizar. Al igual que la toma de requerimientos es parte de ese contexto.

"diseñar" por si solo no existe. Nadie te pide "un sistema para manejar bibliotecas" y con eso ya sabemos que diseñar. Tenemos que saber que cosas son importantes, y que no.

Hay que ver ese contexto: No es lo mismo hacer una app desktop, que una web. Hay un monton de buenas practicas que en un caso funcionan mejor (o son moda) y en otros casos no. Por ej, El hecho de desarrollar por capas está de moda en aplicaciones web, el desarrollo por componentes está de moda en aplicaciones desktop. Ambos diseños fueron elegidos por diversos motivos para dichos contextos. Para tomar esta desicion, no hace falta para nada saber como se puede programar, ni siquiera el lenguaje en el que se va a implementar. El saber programarlo, en este caso, es algo trivial.

Ahora, si vamos a algo más profundo.... como, no sé, un decorator, está bueno que sepas como se programa. O saber que herramientas te ofrece el lenguaje, para saber si te conviene utilizarlo, o es preferible hacer otra cosa.

"Diseñar" es algo totalmente práctico. Al diseño no se le puede sacar la parte de programación, porque hay desiciones de diseño que dependen en gran parte de las caracteristicas del lenguaje. Pero tampoco se tiene que basar 100% en eso, porque justamente no es programacion, es diseño.

Resumiendo, ni. No se puede ver diseño sin programar. Pero tampoco gran parte del peso de diseñar algo, depende de la programación.

Por eso es cuestión del objetivo de la materia.

En la concepción de "diseño" la cátedra "vieja", la idea es que puede existir una etapa anterior a la programación que funcione a modo de "preproducción", de forma que se trate de reducir el impacto de los problemas que surgan en la programación. "Diseña" lo que sepas que no tiene que cambiar, como pueden ser interfaces (UI y entre sistemas) y comportamiento "funcional" (dataflows, workflows, entidades y sus relaciones, cualquier modelo matemático/algoritmo no trivial que vayas a codear, etc.). Todo eso es independiente de la programación, afecta el qué, que no y como programar, y necesita conocimientos diferentes (diseño de interacción, procesos de negocio, estadística, etc, etc). La pregunta es, ¿esto lo debería saber hacer el "ingeniero en sistemas de información"?

¿Vos viste a todos los estudiantes de la carrera haciendo lo mismo? Te pico con la pregunta con la que tanto se rompe las bolas: ¿Qué cargos desempeña un Ingeniero en Sistemas laboralmente? Vas a encontrar a muchos en cualquier lado, en parte (creo yo) porque hoy la carrera no tiene un perfil recontra específico... Depende mucho de lo que quieras hacer, de como te capacites por afuera y de qué elijas aprovechar de todo lo que te da la facultad (sin poner en tela de juicio si es mucho o poco). La verdad, en todo lo que vi yo hasta el día de hoy (por eso lo dejo a juicio de quien tenga más experiencia en el mercado), es muy probable que lo tengas que hacer.

Cita:La pregunta es, ¿esto lo debería saber hacer el "ingeniero en sistemas de información"?

Si.

Por eso el diseño más a "bajo nivel" (programación) se tiene que ver.
También el diseño de UX (no solo pantallas, si no toda la experiencia del usuario), el diseño de procesos, de todo el tema de datos, diseño de APIs (ponele), etc.....

De diseño, no recuerdo haber aprendido casi nada real en la catedra vieja,

Si aprendí RUP, """""metodologias agiles""""" y Redes de petri. Lo cual no habla para nada del diseño. Son simples herramientas, o pasos a seguir para desarrollar un sistema. No aprendí un criterio para poder evaluar un diseño.


Mi "Ni" es algo distinto a "mezcla entre catedra vieja y nueva". La catedra nueva toca bastantes cosas de diseño, aunque le faltan otras (logico, es solo un año, no se puede ver todo). En la catedra vieja, no vi nada.

(02-03-2013 16:39)sebasdp escribió:  ¿Vos viste a todos los estudiantes de la carrera haciendo lo mismo? Te pico con la pregunta con la que tanto se rompe las bolas: ¿Qué cargos desempeña un Ingeniero en Sistemas laboralmente? Vas a encontrar a muchos en cualquier lado, en parte (creo yo) porque hoy la carrera no tiene un perfil recontra específico... Depende mucho de lo que quieras hacer, de como te capacites por afuera y de qué elijas aprovechar de todo lo que te da la facultad (sin poner en tela de juicio si es mucho o poco). La verdad, en todo lo que vi yo hasta el día de hoy (por eso lo dejo a juicio de quien tenga más experiencia en el mercado), es muy probable que lo tengas que hacer.

Mi intención no era responder la pregunta, por algo la hice

Que laboralmente no se use el título de "ingeniero en sistemas de información", como sí se usa el de "arquitecto" o "ingeniero electrónico", es un hecho. Ahora, eso no quiere decir que la facultad no pueda/deba formar un perfil profesional específico (obviamente que con cierta amplitud como cualquier profesión).

Hacia donde debería tirar la carrera termina siendo un tire y afloje entre los ideales académicos, la demanda del mercado, y las expectativas de los alumnos. Encima en una carrera de "ingeniería" (o sea, tiene que ser práctica, va a ser larga, y tiene un tipo de formación específica no negociable) de una universidad pública (tradicional, monolítica, formal, profesional, con muchos intereses encontrados) no vas a tener mucha experimentación con los planes.

Hay una teoria de la educación (estoy estudiando eso) que dice que para aprender hay que construir y que la forma de aplicar tus conocimientos es haciendo (http://makered.org/)
Si no estan de acuerdo con esto vayan y discutan con todos estos capos que están cambiando la manera de educar y dicen cosas como:

“Making creates evidence of learning.”
“education is not preparation for life; education is life itself.”

Y el making de diseño es crear el diseño y programarlo

Imaginate la materia diseño de robots sin crear un robot de verdad y ahí tenés tu diseño de sistemas sin programar

(02-03-2013 18:37)Imakuni escribió:  Si aprendí RUP, """""metodologias agiles""""" y Redes de petri. Lo cual no habla para nada del diseño. Son simples herramientas, o pasos a seguir para desarrollar un sistema. No aprendí un criterio para poder evaluar un diseño.

Son procesos, formalizaciones para organizar, mantener y comunicar estados de avance. "Diseño" no quiere decir solamente "evaluar diseños". "Diseñar" es balancear un montón de factores y tomar un montón de decisiones, el proceso que uses es uno.

Obviamente no estoy sugiriendo que "sigas la receta", pero estudiar la "historia" de los procesos que existieron me parece importante. Es parte de la formación teórica, y tener formación teórica (en ingeniería, teorías prácticas) me parece uno de los objetivos principales de la universidad.

---

(02-03-2013 18:52)Estef escribió:  Imaginate la materia diseño de robots sin crear un robot de verdad y ahí tenés tu diseño de sistemas sin programar

Obvio, y en las materias donde estudian diseño de transbordadores espaciales o centrales nucleares construyen transbordadores espaciales o centrales nucleares (?)

La iniciativa que indicaste es pedagogía para chicos, no educación profesional.

Obviamente que construir debería ser parte de cualquier formación en ingeniería, pero hay un punto, una linea, en la que lo que queres diseñar es demasiado complejo/costoso como para construirlo en una clase. En esos casos, las materias universitarias orientadas a diseñarlo solamente te pueden enseñar la teoría práctica con algunos laboratorios.

Cita:Son procesos, formalizaciones para organizar, mantener y comunicar estados de avance. "Diseño" no quiere decir solamente "evaluar diseños". "Diseñar" es balancear un montón de factores y tomar un montón de decisiones, el proceso que uses es uno.

Obviamente no estoy sugiriendo que "sigas la receta", pero estudiar la "historia" de los procesos que existieron me parece importante. Es parte de la formación teórica, y tener formación teórica (en ingeniería, teorías prácticas) me parece uno de los objetivos principales de la universidad.

El tema es que cosas como rup o scrum, me parecen que son más orientado a la ejecución (o diseño) de proyectos de software, y no al Diseño de sistemas propiamente dicho. Mas precisamente, son cosas de Ingenieria de Software, lo cual desde el plan 08 es otra materia estable.

---

Cita:Imaginate la materia diseño de robots sin crear un robot de verdad y ahí tenés tu diseño de sistemas sin programar

Entiendo. Comparto. Pero no es viable.

No me imagino como se puede enseñar de esta forma una materia llamada, no sé, "Rascacielos 2" ponele. No solo por el costo en dinero, si no por el costo en tiempo.

En sistemas ocurre algo similar. Si bien un sistema puede tardarse mucho menos en hacerse, sigue siendo poco viable como para ver todos los temas. Con robotica debe ocurrir algo similar.


De todas formas, nuestra carrera se basa en una entidad abstracta (información) y producimos otras entidades abstractas (sistemas de información). Toda nuestra carrera está en el aire, siempre. No es algo real que podes tocar o ver. Es un concepto. Diseñar un sistema, me parece que es tan "real" como programarlo y hacerlo. Son reales solo en nuestra mente, y nosotros le damos un significado, muy distinto a lo que es, no sé, un muro, o un explosivo.


Estoy de acuerdo con lo que dicen los flacos respecto a la educación. Pero eso no significa que piense que se puede aplicar siempre, y en todo contexto

(02-03-2013 19:16)Imakuni escribió:  El tema es que cosas como rup o scrum, me parecen que son más orientado a la ejecución (o diseño) de proyectos de software, y no al Diseño de sistemas propiamente dicho. Mas precisamente, son cosas de Ingenieria de Software, lo cual desde el plan 08 es otra materia estable.

Pero RUP tiene fases como "Modelado del Negocio".

Y Scrum tiene su propio enfoque en el diseño integral. Diluye los roles de diseño independientes de la implementación, como el de diseñador de interacción, entre el Product Owner y los Programadores. Le sumas ciclos cortos, y juntos básicamente tratan de bruteforcear ese aspecto del diseño

Claro.

Pero habla sobre "como delegar las tareas de diseño", o cuando realizarlas, y no "como diseñar". O sea, rup te dice "tenés estos artefactos, y estos instrumentos. Primero se analiza, despues se diseña, despues se implementa , etc.
En scrum, te dicen "bueno, tenés esta pila de requerimientos que se hace así, tenés algo llamado velocidad que se calcula asa, tenés la daily, tenés la retrospectiva para ver que hicimos, tenés, etc".

El cambio de metodología no implica necesariamente un cambio de diseño.

Entonces, en vez de ver, no sé, scrum, podría verse como un "tenés que diseñar un sisema que haga x, y, z. Ahora, se te agrega N. Ahora tenes que ponerle F". Si te definieron los requerimientos x, y, z, utilizando un product backlog o una ERS, y despues te dicen que hay que agregar N de la misma forma, no te va a cambiar el diseño de un sistema.


Me parece que metodologías es algo que se puede ver muy por encima (una clase). Pero no me parece que tenga que ser el eje principal de la materia (como si lo es rup & scrum en la cátedra vieja).

(02-03-2013 19:44)Imakuni escribió:  El cambio de metodología no implica necesariamente un cambio de diseño.

No lo implica necesariamente, pero lo puede afectar. Si yo tengo que hacer un diseño integral desde la definición de una necesidad o un problema sistemico (o sea, no te dicen "programame esto"), y lo hago con prototipos, es muy probable que el diseño al año sea diferente a si, por ejemplo, primero armo una lista de requerimientos (con entrevistas + un poco de intuición), después diseño todas las UI y después las codeo en función de eso.

(02-03-2013 19:44)Imakuni escribió:  Me parece que metodologías es algo que se puede ver muy por encima (una clase). Pero no me parece que tenga que ser el eje principal de la materia (como si lo es rup & scrum en la cátedra vieja).

A mí tampoco me parece que deba ser el eje de una materia de "diseño".

Cita:No lo implica necesariamente, pero lo puede afectar.

Todo puede afectar el diseño, estoy de acuerdo.

Pero creo que no podemos decir que ciertos tipos de diseño son más probables en Scrum que en Rup (ponele), o que presentando un prototipo. No sabemos "como" afecta al diseño, no sabemos que consecuencias de diseño pueden traer.
Nomás sabemos que Scrum es mejor para ciertos clientes y contextos, que rup es mejor para otros, que presentar un prototipo conviene en ciertos casos, y en otros no. Pero "como" incide en el diseño.... no sé, al menos hasta ahora no he visto(o leido) una correspondencia entre una y otra cosa,

(03-03-2013 00:53)Imakuni escribió:  Todo puede afectar el diseño, estoy de acuerdo.

Pero creo que no podemos decir que ciertos tipos de diseño son más probables en Scrum que en Rup (ponele), o que presentando un prototipo. No sabemos "como" afecta al diseño, no sabemos que consecuencias de diseño pueden traer.
Nomás sabemos que Scrum es mejor para ciertos clientes y contextos, que rup es mejor para otros, que presentar un prototipo conviene en ciertos casos, y en otros no. Pero "como" incide en el diseño.... no sé, al menos hasta ahora no he visto(o leido) una correspondencia entre una y otra cosa

Si crees que una forma de laburar es mejor que otra en ciertos casos, ya estas haciendo suposiciones sobre "como" incide.

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.

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