Domingo 27 de Septiembre
Este es es un año del que nadie estaba preparado, las malas noticias están a la orden del día, incertidumbre, estrés, flexibilizaciones y restricciones; todos expectantes y ansiosos de que la crisis deje de ser lo actual y pase a ser un recuerdo. Uno de los temas que más ha dado que hablar es modalidad virtual que han adoptado las instituciones.
Personalmente por más que los tiempos no sean los más alentadores, enfrenté retos laborales, académicos y sociales, hubieron algunos que superé y otros que aún estoy atravesando. Antes que nada buentas tardes, soy Felipe Banco tengo 20 años, estudio desarrollo de software, trabajo recorriendo el Gran Mendoza y paso a redactar una de mis experiencias educativas en tiempos de pandemia.
Hoy vengo a relatar mi experiencia en una asignatura denominada: "Modelado de Software", una materia en la que la mitad del programa, es decir la segunda mitad de año, todo el contenido se expone en forma grupal. En términos generales con el tiempo vi esta metodología de trabajo, como una oportunidad para conocer mejor a mis compañeros. Esta vez fue diferente debido a que en otras ocasiones la actividad grupal, para mí no terminó siendo de lo más agradable.
Defiendo la idea de que los cambios pueden representar un desafío sobre nuestras habilidades, en este caso la habilidad de relacionarnos, adaptarnos a nuevos esquemas de trabajo y hasta lo cotidiano. En mi caso me hizo estar más pendiente de las instancias y tiempos de entrega de lo solicitado en la materia, así como también tratar de solucionar algún inconveniente espontáneo en el transcurso. El equipo está integrado por Lucas Quiroga, Florencia Rodriguéz y Pedro Castro; con el primero ya había trabajado en varias ocasiones y esta no iba a ser la excepción, respecto a los dos últimos representó una novedad tanto para mí como para Lucas al trabajar con ellos.
El eje central de esta parte del año, requería organizar una empresa ficticia que atendiera un problema particular, brindando como solución un sistema. Juntos conformamos "RBCQ", nuestra empresa ofrece un sistema informático para una estética, en base a conceptos y temas expuestos en clase para una estética(definición de problemática, historias de usuario, funciones del sistema, diagramas). Para poder abarcar el proyecto, el equipo estaba dividido en roles(coordinador, secretario, vocero, técnico), y a cada uno se le asignaban tareas específicas, las cuales iban rotando por cada semana.
Desde un principio noté una buena predisposición y colaboración en el equipo, a pesar que cada uno de nosotros maneja diferentes rutinas siempre pudimos organizarnos, buscábamos horarios disponibles en el que todos pudieramos asisitir a las reuniones por Meet y debatíamos sobre el desarrollo del sistema. Incluso cuando éstas ya habían finalizado, si se presentaba alguna duda siempre había alguien que respondiera, aunque fuese un lunes a la mañana o un jueves por la noche.
Sin más dilación paso a relatar las vivencias de cada rol que me tocó. La primera vez estuve a cargo de la labor como secretario, que consiste en ir tomando nota según cada instancia, fue algo sencillo ya que en las reuniones iba escribiendo las historias de ussuario mientras daba mis puntos de vista, algunas ideas se quedaban y otras eran descartadas.
Luego me toco vicenciar el rol de técnico, es el encargado redactar o elaborar la presentanción requerida segun la semana, es aquí donde el nivel de dificultad subió un poco más. Como actividad tenía que desarrollar el diagrama de casos de uso aplicando principios de diseño de software, hice varios borradores, recibí sugerencias por parte de los chicos y se hicieron las respectivas correciones. En un principio tuve ciertas dificultades conexión para elaborar el diagrama con una herramienta web, sin embargo pude solucionarlo y tuvimos una devolución positiva.
Por último, cumplí con el papel de vocero, en el que tuve que explicar en forma oral el fundamento del diagrama de clases. De los tres roles éste fue el más desafiante, tanto como cuando lo estabamos elaborando, como cuando lo estaba exponiendo, me generaba cierto nivel de nerviosismo la videoconferencia frente a la profesora y mis compañeros, debido a la complejidad del trabajo. Tenía la incertidumbre de no saber explicar el funcionamiento del diagrama y el porqué de cada principio, aunque estaba con ese nivel de ansiedad los resultados fueron positivos.
Esta ha sido toda mi experiencia en RBCQ, hubieron desafíos y aprendí de ellos como manejar la ansiedad en la oralidad y colaborar con los demás.
Saludos
Atte: Felipe Banco.
Final Modelado de Software 25/11
1) ¿Cómo definirías modelar un software?
Creo que modelar un software viene a ser la abstracción, razonamiento y uso de la creatividad frente a una idea que se tiene sobre un futuro sistema. Un software originalmente es pensado según una necesidad y modelarlo implicaría definir relaciones, componentes, comportamiento, analizar requerimientos para dar forma y consistencia a un planteo que surgió en nuestra cabeza.
2) ¿Qué es para vos el diseño orientado a objetos?
Yo creo que el diseño orientado a objetos viene a ser la aplicación de las propiedades o principios que caracterizan dicho paradigma en base a una abstracción. Los mismos son vitales para el desarrollo, como por ejemplo las clases, polimorfismo, herencia y según como se apliquen definen varios aspectos del sistema. Por último el diseño de objetos se caracteriza por disponer de ciertos principios como los SOLID, en los que se propone la creación de interfaces de responsabilidad única, independencia de clases y asignación de responsabilidades para asegurar un buen diseño y estructura de objetos.
3) ¿Cómo ayudan los principios a mejorar nuestros diseños?
Personalmente creo que los principios ayudan al establecer una serie de medidas prácticas o soluciones para evitar errores e inconvenientes a futuro. Los mismos surgen de experiencia documentada cuando en un contexto aparecen problemas con ciertas similitudes, se los aplica y adapta según dicho entorno. El diseño es imprescindible en los sistemas y con la aplicación de los principios, se evitan malas prácticas que sólo generan inconvenientes, dando así una buena capacidad, composición y funcionamiento del sistema.
4) ¿Cuáles son los principios que consideras más prácticos y necesarios? ¿Cuáles no utilizarías tanto y porqué?
Los que yo considero más prácticos son la escalabilidad, para disponer de la suficiente potencia/capacidad y la portabilidad para que el sistema pueda adaptarse a mas de un entorno, ya que suponen en si una ventaja competitiva y operativa tanto para clientes y desarrolladores. También la modularización es importante ya que define en si gran parte de la estructura. En cambio los que considero menos importantes son la testeabilidad y reusabilidad, la primera porque creo que el la capacidad del testeo corresponde a otras etapas del desarrollo, la segunda porque la reutilización de partes del sistema en otros proyectos depende mucho del contexto y del requerimiento, si se le da un mal uso se pueden generar confusión y problemas.
5) Si en pocas palabras tuvieras que sintetizar la cátedra ¿Cómo la describirías?
Si tengo que sintetizar la materia, la defino como una toma de contacto con el mundo real, debido a la elaboración de proyectos y cómo estos responden a determinadas necesidades. La asignatura ayuda a tener otra óptica del desarrollo por ejemplo:si un cliente exige o solicita ciertas funcionalidades, se diseña un diagrama de casos de uso que tiene una aplicación práctica; y es ahí donde algo teórico toma un sentido.
Link de Actividad Grupal:
Comentarios
Publicar un comentario