Notas sobre finales viejos (Ingenieria I)

De Cuba-Wiki
Saltar a: navegación, buscar

Experiencias de gente que ya rindio final. Recuerden que antes tomaban un coloquio y ahora toman final escrito.

1) era una frase referida a que una arquitectura es buena si responde a los requisitos funcionales. Te pedian que la comentes. Habia que hablar de los no funcionales.

2) Habia un sistema hecho en cobol y te contrataban para hacer una nueva version en JAVA. el gerente de sistemas de la empresa que te contrata es el que hizo el sistema. Te pedian que analices la situacion.

3) En tu empresa quieren adiquirir un software y hay 2 alternativas una con licencia paga, y la otra gratis y opensource. Te pedian que hables de lo que pondrias en un informe si tuvieras que comparar ambas alternativas.


Tomó, todo teórico (ojo que fue coloquio), sobre requerimientos, un poco de arquitectura y clases, y bastante de testing (por que? para que? etapas, etc). Yo estudié de los apuntes de la cátedra y me alcanzó muy bien.


Este fue escrito: -que es un oráculo (el resultado esperado, puede ser dado por una persona, o por una especificación)

-qué dice Howden? rta: Dado un programa, seleccionar un subconjunto de inputs tales que si el programa da resultado correcto en esos inputs, entonces el programa es correcto para todo input. Demostró que esto es INDECIDIBLE.

-Arquitecturas: Diferencias entre Vista conceptual y la vista modular

-mencionar (y explicar creo) algunas tecnicas de especificacion ( DA, CU, modelo conceptual, etc)


Fecha 13/3/06 dividio, eran 9 personas, un grupo de 4 y otro de 5, y a ambos les pregunto lo mismo. planteó un escenario, y siguió con él durante casi todo el coloquió:

- los programadores, que son los mismos que los diseñadores se odian con los que especifican el software... En consecuencia, hay malas interpretaciones y muchas veces ocurren errores. Soluciones Posibles? (Ejemplo, poner arquitectura en el medio, y tiraron muchas mas).

- se habló mucho de Quality assurance, es decir otras caracteristicas además de simplemente testing

- qué son los patterns, hablamos un poco de ellos

- volviendo al escenario, preguntó qué otras cosas se necesitan, para q el software sobreviva en el tiempo, además de un equipo de testing, uno de mantenimiento. Respuestas posibles: era operador, instaladores, tecnicos, alguien q configure algo todos los dias o esporadicamente ( ejemplo actualizar el valor del dolar, puede hacerlo un actor incluso).