UTNianos

Versión completa: Diseño: Programar Si, programar No
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Páginas: 1 2 3 4
Buenas!

Me gustaría que se comente, dentro de la manera mas civilizada posible, las opiniones de todos respecto a programar en la materia de Diseño de Sistemas.
No es necesariamente una comparación entre la materia vieja y la nueva... va mas bien por un tema de experiencias personales, qué les hubiera gustado, qué les gustaría si aún no la cursaron, que esperan.

Podemos abrirnos un poquito de la materia y pensar en el proceso de diseño de sistemas en sí: Se puede diseñar sin programar? Se puede diseñar en abstracto? El diseño es técnico o gerencial? Se puede generar un diseño agnóstico de la tecnología?

Como ven, es bastante amplio el thread =D Estaría bueno comentar el por qué de la elección de la encuesta, o si no completan la encuesta, el por qué.
La opinión de todos es bienvenida, ya sea de los que saben (para que otros vayan viendo las diferentes posibilidades) como de los que no (para ir aprendiendo, planteando dudas y dar lugar a que otros les puedan dar una mano).

Bien jipi el asunto =D


Yo creo que NO se puede Diseñar sin saber programar. No creo que haga falta programar, pero me parece a veces que es mas fácil contar tu diseño a través de código y no a través de cajitas.

Nada, después profundizaré (o no) sobre esta opinión de arriba, pero me gustaría saber que opinan ustedes =)


Off-topic:
Se pueden agregar opciones a la encuesta después de publicada?
un gran debate se puede armar acá, y todo va a depender del enfoque que cada uno tome.

en la actualidad con las metodologías ágiles el diseño se va "fucionando" con otras etapas del proceso de desarrollo.

¿se puede hacer un diseño completo de una aplicación sin escribir una línea de código? sí.
¿podemos asegurar que ese diseño es 100% válido? no.

ahora, basándome sólo en la materia, yo creo que la misma se podría dictar sin programar nada. la materia puede enseñar a diseñar y mejorar diseños, sin tener que escribir código (pero suponiendo que se puede hacer).

por ejemplo si se usa TDD para desarrollar, la etapa de "diseño" carece de sentido, porque se va diseñando y mejorando el modelo a medida que se avanza. pero siempre se parte de una base, de un diseño mínimo, aunque sea mental, que tiene que existir.

el tema es que muchos (sobre todo los dinosaurios que dan clase) entienden el "diseño" como un conjunto de cajitas y flechitas, y los sacás de UML y no entienden nada.
Agregame una tercera opción, y voto

Para mí no es tan drástico como "sí" y como "no".
A mí personalmente me gustaría que Diseño sea un híbrido entre la cátedra vieja y la nueva.
Igual, ya la cursé, pero estaría bueno un punto medio
(01-03-2013 20:50)nanuiit escribió: [ -> ]Agregame una tercera opción, y voto

Para mí no es tan drástico como "sí" y como "no".
A mí personalmente me gustaría que Diseño sea un híbrido entre la cátedra vieja y la nueva.
Igual, ya la cursé, pero estaría bueno un punto medio

Totalmente de acuerdo..
no podria decir que quiero un hibrido entre la nueva y la vieja porque no se com oes la nueva, mas alla de leer opiniones favorables en su mayoria, aunque algunas contrarias por el contenido de programacion


nose, tendria que cursar en la nueva; lo que si es que quiero lo menos posible la vieja catedra, o al menos lo menos posible a elvira quiroga
Depende el objetivo de la materia. "Diseñar Sistemas" es la combinación de las dos palabras más explotadas y menos específicas en la historia de la humanidad.

Si el objetivo es el de "diseñar" software, la única especificación suficientemente detallada para la construcción mecánica, como un plano, es el código fuente. Ese es el "plano" del software, la "construcción mecánica" la hace la máquina.

Al mismo tiempo, en otras disciplinas, la idea de una etapa de "diseño" es reducir costos tomando la mayor cantidad de decisiones posibles antes de la construcción. ¿Por que? porque la construcción es costosa. Si el arquitecto diseño mal una parte del edificio, corregir el problema una vez que el edificio está a mitad de construir es varios ordenes de magnitud más costoso que corregir el error en la especificación. Pero en el software la construcción es gratis. Lo más costoso es generar el "plano". La analogía con la arquitectura o la manufactura se rompe.

Volviendo a la materia, si la idea es enseñar a "generar el plano", sí, programar es parte del "diseño". Pero si consideramos "diseño" como una "etapa para reducir costos tomando la mayor cantidad de decisiones posibles antes de pasar a la etapa más costosa", entonces "diseñar software" tiene otro sentido. En este caso, enseñar "diseño" implica enseñar qué decisiones son las que se pueden tomar, que decisiones no, cuando conviene tomarlas y como el surgimiento de nuevas herramientas afecta esto. Por ejemplo, programar un prototipo para validar un workflow con un usuario es una tarea de "diseño", porque el objetivo es responder una pregunta que te puede cambiar totalmente la forma de programar una solución (y que, si la pifias, puede implicar una reestructuración prohibitivamente costosa).

En conclusión, si seguimos la analogía con otras disciplinas, enseñar a "diseñar" implica enseñar a generar un plano. Y como lo único análogo al plano es el código fuente, implicaría programar (de la misma forma que diseñar en arquitectura o ingeniería implica dibujar). Pero si en lugar de aplicar la analogía directamente tomamos solamente los objetivos de la etapa de "diseño", la idea sería enseñar qué hacer antes de entrar en la etapa de programación para reducir el riesgo de programar algo que no ande o no sirva.

PD: Y si, esto último puede incluir escribir documentos dibujando casitas.
el diseño varia segun el lenguaje en que se implemente, asi q hasta podria servir para contrastar si se programa un poco
(01-03-2013 20:50)nanuiit escribió: [ -> ]Agregame una tercera opción, y voto

Para mí no es tan drástico como "sí" y como "no".
A mí personalmente me gustaría que Diseño sea un híbrido entre la cátedra vieja y la nueva.
Igual, ya la cursé, pero estaría bueno un punto medio
Podrías explayarte un poquito más? A que te referís con un punto medio?

Ahora edito el primer post para abrir mas el juego.
¿La gente que opinó acá cursó con la cátedra nueva?. Porque yo cursé con Passerini el año pasado, y si hay algo que siempre repetía era que le daba por las bolas que se diga que "en la cátedra nueva programás" cuando no es así. En la materia casi no te dan la sintaxis de Java, tenés que usar los apuntes que hayan subido a internet y averiguar vos un poquito, pero la posta es que codeás pelotudeces.

A mí parecer, después de haber cursado la materia, me parece que para diseñar tenés que ver cómo queda implementado porque ASÍ te das cuenta de lo que te pasa si te llega un nuevo requerimiento que por una elección de diseño que hiciste antes te caga la vida. Como consecuencia, perdés tiempo modificando lo anterior (en la vida real se traduce a costos y por ende plata) para recién después poder implementar lo que necesitás.

Qué se yo, es mi opinión, la verdad que conozco gente que se la pasó el año haciendo diagramas pero después no tienen ni idea de cómo quedaría implementado y cómo repercute...
Cada vez que nombraron el tema, lo dije, pero bueno, resumiendo:

NO quiero que DDS sea like TADP (TADP tenés que programar bastante)
NO quiero que DDS sea como la da la cátedra vieja (Análisis de Sistemas v2 podríamos decirle, porque la mitad del año vi casos de uso y temas que son de esa materia)

Yo creo que está bueno que se diseñe con código, pero tampoco te copes dándome un curso de Java

Yo hablo de lo que me contaban mis compañeros que cursaban con Dodino...
Me gustaba eso de que implementaban patrones con código; me hubiera encantado hacerlo.

Off-topic:
agregue una tercera opcion


Cita:NO quiero que DDS sea like TADP (TADP tenés que programar bastante)

el problema igual es que parte de TADP era "Like debería haber sido DDS" porque en DDS no enseñaban un carajo (patrones es el ejemplo mas claro)
¿Por qué la gente está tan loca con este tema? Yo curse en 2012 pero me toco la catedra vieja. Sinceramente no me sirvio para nada, excepto para incorporar un par de conocimientos que (ahora que entre en un laburo) me da la sensacion que no son ni tan prescindibles, ni tan indispensables... Sin embargo, coincido en lo que dijeron mas arriba, para mi es un NI. Esta copado tener la nocion de patrones, por ejemplo, y que se usa bastante. MVC es de todo lo que vi (o en este caso, se nombro) lo mas importante: JEE gira en torno de este concepto (de hecho, los tan famosos EJB de Iriart son parte de la capa de modelado) y Oracle lo explota al 100 con ADF y sus BC4J. Pero tampoco veo tan necesario vivir programando (si es que es cierto el rumor de que en la nueva catedra comes, bebes y respiras Java) porque no te lleva a nada. Esta bueno poder abstraerte un poco de la implementacion y pensar un poco en lo que vas a hacer. Tal vez, si programar fuera absolutamente necesario para quien dirige la catedra, puede volcarse un poco mas en orientacion a componentes...
Cita: Pero tampoco veo tan necesario vivir programando (si es que es cierto el rumor de que en la nueva catedra comes, bebes y respiras Java) porque no te lleva a nada.


(01-03-2013 22:44)NathanDrake escribió: [ -> ]¿La gente que opinó acá cursó con la cátedra nueva?. Porque yo cursé con Passerini el año pasado, y si hay algo que siempre repetía era que le daba por las bolas que se diga que "en la cátedra nueva programás" cuando no es así. En la materia casi no te dan la sintaxis de Java, tenés que usar los apuntes que hayan subido a internet y averiguar vos un poquito, pero la posta es que codeás pelotudeces.
(01-03-2013 23:21)gonnza escribió: [ -> ]
Cita: Pero tampoco veo tan necesario vivir programando (si es que es cierto el rumor de que en la nueva catedra comes, bebes y respiras Java) porque no te lleva a nada.


(01-03-2013 22:44)NathanDrake escribió: [ -> ]¿La gente que opinó acá cursó con la cátedra nueva?. Porque yo cursé con Passerini el año pasado, y si hay algo que siempre repetía era que le daba por las bolas que se diga que "en la cátedra nueva programás" cuando no es así. En la materia casi no te dan la sintaxis de Java, tenés que usar los apuntes que hayan subido a internet y averiguar vos un poquito, pero la posta es que codeás pelotudeces.

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.
(01-03-2013 20:10)Ichiluk escribió: [ -> ]
Off-topic:
Se pueden agregar opciones a la encuesta después de publicada?


Off-topic:
Deberías poder, creo que tienen permisos de edición ilimitado ahora, así que en la edición completa podés editar
Páginas: 1 2 3 4
URLs de referencia