Este semestre será interesante, se intentaran cosas nuevas que no

Este semestre será interesante, se intentaran cosas nuevas que no se han intentado semestres
anteriores, es un curso relativamente distinto a los curso tradicionales
Puede que después de la presentación introductoria los estudiantes del curso caigan en
pánico, aunque a esta altura de la carrera ya quizás no suele suceder.
No hay razones para entrar en pánico con esta materia, al final no es para tanto.
El profesor de la materia es Demián Gutierrez, Ingeniero de Sistemas, y tiene experiencia en el
mundo profesional y académico, lo que hace más interesante el curso por haber trabajado
mucho en el área. En este curso usaremos métodos agiles de desarrollos de software.
En este curso aprenderemos cosas que nunca habíamos visto hasta ahora de la Programación
orientada a objetos (OO). Pasaremos de aquello de desarrollar software artesanalmente a
desarrollar software usando ingeniería como un producto final.
Siendo esta diapositiva la columna vertebral del curso, basado en aplicar técnicas y conceptos
de agilidad, arquitectura de software, diseño orientado a objetos, pruebas, gestión de
proyectos, entre otros.
Además, tenemos como objetivos que nosotros los estudiantes del curso como futuros
ingenieros, podamos desarrollar criterios ante distintos escenarios y tipos de proyectos de
desarrollo de software.
El rectángulo verde representa todo lo que se puede hacer, todos los métodos y tecnologías
que existen en la ingeniería del software, y el punto negro representa sólo lo que podemos
cubrir en este curso, por lo tanto, la importancia de desarrollar criterios es para poder
enfrentar en un futuro el rectángulo verde y no quedarnos en el punto negro.
Aún más extraoficialmente, si queremos, podemos soñar y volar un poco, tratar de pensar un
poco diferente, tal como la gente de Apple se especializó con este slogan.
Debemos buscar la innovación, buscar encontrar formas distintas de ver el mundo y los
problemas, desatar la creatividad y la imaginación es realmente importante.
Aunque mucha gente tienda a ver a los ingenieros de sistemas y a los ingenieros de software
como personas muy frías, mecánicas, etc, no debe ser así, sin creatividad no vamos a ningún
lado.
Debemos ser capaces de tomar riesgos, y a su vez, asumir las consecuencias sean buenas o
malas.
La idea de esta materia, es que nosotros como estudiantes, pasemos de simples
programadores a desarrolladores de software, por supuesto, transformarnos en mejores
programadores más cerca de ser ingenieros, y porque no estar más cerca de ser
emprendedores, quizás al montar una empresa y producir fuentes de trabajo, riqueza, etc en
un futuro.
Como estrategia de aprendizaje se usa desde hace 3 años más o menos en el curso, RAIS que
es de Reproducción del Ambiente Industrial en el salón de clases.
RAIS básicamente funciona con 3 componentes, el primero es el producto (producto a
desarrollar), el segundo componente es la sinergia de capacitación de conocimientos, y es
que, para desarrollar el producto hay que aprender ciertas técnicas y conceptos que veremos
en el curso de la manera tradicional, y el tercer componente es la sinergia de desarrollo del
producto con discusiones, exposiciones y otras técnicas sobre el producto.
El curso está centrado en nosotros los estudiantes, y de nosotros depende aprovecharlo o no.
Y se basa en la premisa de que todos nosotros (los estudiantes) somos extremadamente
talentosos.
El conocimiento está en el salón de clases y con el profesor, pero también existe el riesgo que
se pueda causar polémica con la gente que está afuera, por lo tanto, debemos abrir los ojos
para poder argumentar, dialogar, debatir, etc…. Estamos a un click de distancia de cualquier
conocimiento.
Nuestro objetivo es hacer del curso de Ingeniería de Software empresas de Desarrollo de
software.
Por el reality show El Aprendiz, podemos encontrar semejanzas con el curso, debemos
procurar ser despedidos de nuestra compañía.
Y para evitar ser despedidos, en este curso no vamos a enseñar ingeniería, si no vamos a
hacerla.
Para hacer ingeniería, nos vamos a transformar en emprendedores, debemos dejar de pensar
como estudiantes, y para ello crearemos y nos organizaremos con las compañías.
Cada compañía va a definir logos, imagen, ect para definir una identidad y así poder ser
identificados.
Y cada uno va a tener roles, además, cada compañía tendrá un gerente (ir pensando en
quienes quieren ser gerentes), que será el responsable de su compañía y el profesor en cierto
sentido, trabajara como jefe ejecutivo, responsable también de los productos, cabe destacar,
que contamos con el apoyo y ayuda de él.
El trabajo de gerente es un poco más duro de lo normal, implica dirigir la compañía y además
implica ensuciarse las manos junto con los demás para desarrollar el producto final.
Pero ser gerente, deja como ganancia la experiencia y el aprendizaje, además que no es un
cargo nada fácil.
Usando RAIS, la idea principal del curso es desarrollar el producto, y si no lo terminamos, al
final del semestre hemos fracasado así se hayan aprobado los exámenes escritos.
Semestres anteriores se han desarrollado juegos, como productos finales, este semestre no es
necesario desarrollar juegos, desarrollaremos 2 proyectos interesantes, necesarios para el
profesor y quizás para más personas, usando principalmente JAVA (pues se cuenta con
personas preparadas en JAVA para que nos apoyen y nos guíen)
Nuestro clientes son principalmente, nosotros mismos, incluyendo a toda la facultad, pues al
salir y exponer el proyecto en patio central debemos sentirnos orgullosos del trabajo logrado.
Además de trabajar desarrollando el producto, debemos divertirnos, es decir si hacemos lo
que nos gusta nada se hace difícil.
Como anteriormente se ha hecho, haremos una presentación pública tengamos lo que
tengamos, si hacemos un mal producto pasaremos la pena delante de todos y si hacemos un
producto bueno podremos jactarnos ante los demás del fruto de nuestro trabajo.
El factor humano juega un papel muy importante en el desarrollo del proyecto, es un reto que
va mucho más allá del producto tradicional de las demás materias, debe producirse un
verdadero trabajo en grupo y una adecuada distribución del trabajo, esto quiere decir que en
un lapso determinado de tiempo debemos trabajar así sea integrando código, trabajando en
conjunto y luego trabajando individualmente, y así.. A eso nos enfrentamos cuando hacemos
Ing del software, nos enfrentamos a un grupo de trabajo, a un grupo de proyecto que requiere
trabajar de manera coordinada para cumplir un objetivo.
Es muy importante el trabajo en grupo, pues por un miembro que no cumpla su trabajo,
retrasa a toda la compañía. Por supuesto, existirán problemas, mal entendidos o conflictos,
pero lo importante, es la manera como se resuelvan. El profesor estará disponible para
ayudarnos a resolver cualquier inconveniente que se presente. En un grupo de trabajo “Se
comparte la victoria, se comparte la derrota”.
En cuanto a la evaluación, usaremos la entrega de iteraciones cada 15 días, con el motivo de
medir el avance de las compañías frecuentemente (establecer un ritmo de trabajo).
Preguntaremos: Que fue lo que se hizo durante la iteración?, Quien lo hizo? Cuánto tiempo se
empleó? Costo mucho o poco? Que dificultades tuvimos durante la ejecución de la iteración? Y
Como puede el profesor ayudarnos a solventarlas? Que se va a hacer en la próxima iteración?
Y Quien lo va a hacer? (esto tiene que ver con la parte de distribuirse el trabajo en los
miembros del grupo de la compañía.)
Además, por medio del link publicado en la diapositiva, se realizara cada 15 días una auto y
evaluación de desempeño, para evaluarnos nosotros mismos y a los compañeros. De esta
manera, el profesor va procesando y calificando la información para facilitar el trabajo.
La diferencia con un proyecto tradicional, es que, el profesor (jefe ejecutivo) hará un
seguimiento de todo y tendrá una idea de cómo estamos funcionando.
El plan de evaluación, consistirá en 3 exámenes escritos que equivalen a un 40%, el proyecto
(evaluación del desarrollo del producto) 40%, hetereovaluación (nota apreciativa) 10%,
coevaluación/ autoevaluación (la hacemos nosotros mismos) 10%. Pero, si la nota promedio de
los exámenes escritos es menor que 10pts, entonces el estudiante no tendrá derecho a
presentar el proyecto. Este semestre, como nueva modalidad, trataremos de presentar los
exámenes en línea, con la idea de que tengamos feedback inmediato, es decir, saber la nota de
una vez.
Cabe destacar, que todos los miércoles tendremos laboratorio con clases dictadas por la
preparadora, sobre las tecnologías que iremos a usar para desarrollar el producto, empezando
por java.
Hay también un bono extra, de dos puntos en la definitiva, con transcripciones textuales de los
videos (tal cual como este archivo).
Es importante saber, que la nota del proyecto es individual, a través de ciertas estrategias que
el profesor considere. Los exámenes escritos son a libro abierto (se acepta todo menos los
teléfonos celulares), y OJO con las inasistencias pues se aplicara el reglamento (75% mínimo de
asistencia), y más aún, OJO con los gerentes, deben estar siempre presentes.
Considerémonos en la libertad de preguntar, discutir y argumentar, sin miedos!
En cuanto a comunicación se refiere, como medio principal está el foro, si no llega a funcionar,
entonces puede ser por los demás medios (twitter), o en caso de extrema emergencia al
correo: demian@ula.ve
Tal cual como en la industria, o en el campo laboral, se nos exige como primera tarea; un
resumen curricular, completar la encuesta de reclutamiento de personal (ver link en la
diapositiva) y describir en una carta de presentación lo que hemos hecho para saber que
podemos aportar a la compañía. Considerando “cero tolerancias a excusas”, si nos
comprometemos a algo hay que procurar cumplirlo.
En el curso se necesita gente responsable, comprometida y motivada para desarrollar un
producto
De referencias bibliográficas, los dos libros de las esquinas son referencias clásicas, mucha
teoría para la parte práctica pero sin embargo pueden llegar a ser útiles.
El libro de la izquierda útil para interfaz de usuarios y el de la derecha útil para adquirir
conocimientos sobre patrones de diseño.
Cuando lleguemos a UML usaremos estos, pero más adelante seremos mas específicos al
respecto.
Agilidad es lo que vamos a hacer y a utilizar en este curso, tal cual como lo están haciendo las
industrias y les ha resultado excelente. La idea es terminar el curso con los conocimiento
básicos y necesarios de métodos agiles, para después enfrentarnos a esto en la industria, y
para prepararnos también como agentes de propagación con esto.
Jens Ostergaard, con muchos años de experiencia para obtener esa certificación, en su charla
introductoria a Scrum (link en la lámina), discute por qué el Scrum y por qué usarlo en las
compañías. Habla sobre el trabajo que hacían en el dpto. de tecnologías de información (a
finales de los 80), la cual en aquélla época la gente no tenía ni idea de que era eso, y lo que sea
que hiciera la organización, los usuarios pensaban que era una especie de magia, por la misma
falta de conocimientos que tenían. Pero en 1989, el primer líder de proyectos de ellos, dijo,
“Ustedes no pueden hablar con los usuarios, nunca más!” (Es decir los desarrolladores, tenían
prohibido hablar con los usuarios), “todo tiene que pasar a través de mí, yo tengo que tener la
“visión global”, la “vista de helicóptero””, tal como el proyecto comando- control, en la que el
líder de proyecto lo controla y el desarrollador hace lo que el líder dice que haga, generando
así, problemas de comunicación quizás. (En nuestro caso del curso, el profesor va a tener la
visión global). Continua Ostergaard.. “todo esto hace, en cierto sentido que se pierda la
responsabilidad”, pues yo estoy haciendo un producto para alguien que nunca conoceré, a
todo esto se empieza a añadir más procesos, mas procedimientos y más burocracia, (siendo
muy difícil trabajar en un ambiente así). Todo esto produjo en ese tiempo, limitar la
creatividad, mas recetas (decirme como hacer el trabajo) y menos chance para crear o innovar
al hacer el trabajo.
Hacer software, es una cuestión de responsabilidad y pasión, aunque hayan días infernales en
las que las cosas no funcionan como uno quiere, también hay días en que obtienes los
resultados que anhelas. Es una cuestión de valores. Hay gente que trabaja en el mercado
haciendo software y les va mal por no tener la actitud correcta para desarrollar software.
Hay varias formas de desarrollar software.
-La forma artesanal: es desarrollar sin método, sin estrategia clara, sin plan, sin gestión y sin
seguimiento “mientras vamos viendo vamos yendo”, aunque puede funcionar en algunos
casos, es mala idea.
-La forma usando ingeniería: es desarrollar usando método y estrategia bien definida, con una
planificación, tecnología, arquitectura y gestión adecuada, teniendo dos visiones: la de
Métodos tradicionales o métodos pesados (en los años 70 más o menos), donde ocurrió la
llamada crisis del software, en la que el 70% de los proyectos de software fallaban, por estar
concentrados en el proceso como tal, por usar recetas, métodos descriptivos, burocráticos y
con planificaciones rígidas (el plan ejecutable no se modifica). Y la segunda visión, es la de
métodos agiles, concentrado en el producto. Se basa en cumplir el plan si se puede, pero más
importante es el éxito del producto de software: que se cumplan los objetivos (se resuelva el
problema) con el tiempo y presupuesto predefinidos, además que el equipo de desarrollo
haya sobrevivido a pesar de las inconvenientes. Tenemos que tener la manera de enfrentar los
cambios, pues actualmente la concepción de la gente en cuanto a productos de software se
refiere, cambia de la noche a la mañana.
Como proceso clásico, tenemos el de cascada. De hecho, todavía se utiliza y es interesante
desde el punto de vista académico y conceptual pues nos permite encontrar ciertas categorías
de lo que se hace en la ingeniera de software, pero en la mayoría de los casos no funciona.
Pues se definen los requerimientos (lo que tengo que hacer) junto con el cliente, se hacen
compromisos iniciales (como ejemplo un software con interfaz gráfica), luego se hace el
diseño del sistema y de software (la arquitectura del proyecto, junto con los planos del
sistema), luego de eso se implementa según los planos (programación) y después se hacen
pruebas (se prueba que el sistema esté bien programado) y eventualmente pongo el sistema
en operación y mantenimiento. El problema está en que este proceso no está sujeto a
cambios, pues al modificar algo por ejemplo en la implementación se tendría que comenzar el
proceso de nuevo desde su inicio, lo cual genera altos costos.
En cambio, el proyecto ideal (explicado por Javier González Jiménez, español), muestra como
actividades para realizarlo una especie de cascada; con la primera fase de requerimientos, luego el
análisis, seguido por el diseño, la construcción (programación) y las pruebas. En la que el cliente sabe
perfectamente lo que quiere y lo que necesita, los desarrolladores de software saben cómo hacer para
conseguir lo que el cliente quiere y se toman requisitos detallados al inicio del proyecto con el cliente,
en base a eso se hace un plan de cumplimiento de las actividades y no es necesario volver a hablar con
el cliente hasta el final del proyecto.
La gente de requisitos en el proyecto ideal, toma nota de lo que el cliente quiere, pasa esos documentos
a la gente de análisis, la gente de análisis hace su análisis y pasa esos documentos a la gente de diseño,
la gente de diseño hace su diseño con los respectivos planos y pasa eso a los programadores, los
programadores saben exactamente que implementar y todo sale bien , nada cambia durante el
desarrollo del proyecto.
Al final, el cliente recibe lo que esperaba y no hay que cambiar absolutamente nada.
Al final de esta clase, hicimos una dinámica con legos, el cliente (era el profesor) necesitaba un avión
para vuelos internacionales, este avión obviamente debía ser grande y tener las alas en amarillo. El
cliente se reunió con el gerente de la empresa y le expuso su caso, el gerente o jefe se reunió luego con
el ingeniero del software para explicarle lo que el cliente necesita, este, realizó los planos del proyecto y
el logo requerido para dárselo a los constructores. Cabe destacar, que en este proceso hubo falta de
información, los constructores en un tiempo definido trataron de desarrollar el avión, pero había que
tomar en cuenta varios factores, como que los legos de color amarillo para las alas eran muy pequeños y
era casi imposible hacerlas, además que quizás en ese tiempo no podían culminar con el proyecto, había
presión, habían nervios, dudas… Resultando así, que el cliente no quedara satisfecho. De ahí, la
importancia de organizarse y hacer cumplir al pie de la letra, las actividades requeridas para hacer un
proyecto ideal (explicado anteriormente).