Arquitectura Y Diseño Del Motor

[tiutiu]

 Acabo de ver el segundo video y esta muy bien, muy buenas las caracteristicas que mostrais, felicidades :D

¿Podriais explicar como habeis diseñado el motor? Prerrequisitos, arquitectura, modulos, ... ¿Que metodologia habeis usado para diseñarlo?
En una asignatura tenemos que hacer un proyecto, visualizar de la manera mas realista posible una partida de ajedrez. Tras pensar los prerrequisitos, hemos comenzado a plantear cuales seran los modulos y que estrategia de diseño vamos a usar. Ahora me gustaria saber como lo hace la gente para sus proyectos, ya que aun no tengo experiencia en ingenieria del software.

[Haddd]

 Gracias!!  :D

Pues como diseñamos el motor...ummmm....Ah, vale. Pues la verdad es que por el método de prueba y error. Hacemos algo pequeñito, lo probamos y vemos lo que nos falta. Y , o bien lo ampliamos, o bien lo rehacemos. Sé que parece una barbaridad, pero ...¿alguien puede determinar los requisitos de un motor gráfico ?

Nosotros vamos "descubriendo" soluciones  a problemas con los que nos encontramos. En lugar de plantear un análisis de requisitos y después entrar en la fase de diseño, hasta ahora hemos ido resolviendo los problemas que nos surgían "tacita a tacita". Por ejemplo, el sistema de shaders de la 1.0 no tiene nada que ver con la de 2.0 Pero creo que si nos planteamos los problemas en el momento del análisis de requisitos, algo nos habríamos dejado y tendríamos que haber vuelto atrás.

Y respecto a los módulos, la verdad es que somos casi 2 personas las que lo mantenemos. Esperemos que Vicente se una pronto. Eso facilita muchísimo las cosas. No me quiero ni imaginar el método que usamos con más gente...sería una locura. Cada uno hace un trozo y cada día "pegamos"  :P

Así que supongo que no hacemos nada de lo que se dice en la carrera. No nos utilices como ejemplo por favor. Bueno, eso o ...quizás en la carrera exageren.

Os voy a contar un caso real, o por lo menos a mi me lo contó una persona que lo vivió y no tenía pq mentirme.

Una gran cadena hotelera de EEUU se dió cuenta de que no había ingún programa de Hotel que pudiera satisfacer plenamente las necesidades. Así que decidieron enbarcarse en la gran aventura de..¡hacer un soft! Como es una gran cadena, pensaron que se tenían que unir a un gran equipo e hicieron un "join venture" con, nada más y nada menos que una empresa de informática muy muy muy muy conocida americana.

Evidentemente esto significaba garantía de éxito total. Así que empezaron a venir informáticos a preguntar y a preguntar. Cuando pasó un año, la gente de la cadena les pidió que en qué estado estaba el programa. Ellos respondieron que todavía esaban en el análisis de requisitos ( o con el diseño, ahora no recuerdo), que claro, cada vez que iban a hablar con uno de los hoteles de la cadena, se encontraban con un cambio importante, y volvían a replantearse los problemas para tener un diseño sólido.

La respuesta fue: ¿ nos hemos gastado 1.000 millones de ptas y me estais contando que no tenemos absolutamente nada ?

La acción fue: "join venture" a tomar por c.

¿Qué ocurrió ? Que nadie se marcaba "metas" físicas reales. Los informáticos hicieron su trabajo, y por supuesto, cuando había un cambio importante se volvían a reunir y a reunir y a pensar y a rediseñar. Pero faltaba una persona que dirigiera el cotarro que marcara unos límites, o bien, explicara claramente a ambos socios lo que aquellos iba a suponer.

Sé más de estas! También reales, o por lo menos eso creo.

Oid, con esto ahora no me ataqueis, que ya he visto esos post que se convierten en hilos interminables. Yo no digo que no haya que hacer análisis y diseño antes de empezar. Sólo he contado una historia....

[nsL]

 Yo creo que para proyectos en que intervengan mas gente y sean mas grandes (no intento desprestigiar vuestro trabajo, que conste) se requiere una planificacion exhaustiva de todo el proceso, ya sea planteamiento de requisitos, desarrollo, mantenimiento , etc...

Yo tb estoy cursando esa asigantura, Ingenieria del Software, y claro, te muestran estudios estadisticos que vienen a resumir que si no haces planificacion de todo esto, solo un 30% de los proyectos salen a la luz, y el resto se quedan en el camino, ya sea por falta de dinero o tiempo, debido a que no lo planificaron y se les fue de las manos.
Pero como dice haddd, para un proyecto en el que estan implicadas 2 personas, y que ademas no tengas a un cliente dandote la brasa, sino que lo haces para ti, y ni hay limite de tiempo, pues lo mas normal es hacerlo sin planificar exhaustivamente. Eso si, hay que marcar estilos de programacion comunes y pautas para evitar que sea un caos y que no hagan 2 personas lo mismo, pero mas alla de eso en un proyecto de este tipo me parece poco necesario.

Os colgaria un pdf de la IEEE con la metodologia, por asi llamarlo, para creacion de proyectos. Es muy bueno el documento, pero al ser de pago se me puede caer el pelo :P

Saludos!  B)  

[Grugnorr]

 Esa gran empresa yankee empezaba por Accentu ?   :D  

[tiutiu]

 Discrepo un poco en lo de que si el proyecto se lleva entre pocos no hace falta un diseño muy exhaustivo. Creo que conviene diseñar bien lo que se va a hacer antes de programar. De hecho, la fase mas importante en el desarrollo del software es el diseño; al menos en software complejo como es un engine.
Eso no quita que puedas usar metodos de prueba y error, iterativos, etc... pero lo que es importante es lo que han dicho arriba: marcar una metodologia que todos deben seguir, sino los problemas te comen.


Hace poco me compre un libro de construccion de software (Code Complete), muy recomendado, que te muestra lo importante que es tener un buen diseño y seguir unas pautas para programar, como por ejemplo encapsular, ocultar informacion, modularizar, reducir la complejidad, ... Desde que comence a leerlo me he ido dado cuenta de la razon que tiene, se hace mucho mas facil construir una pieza de software asi que no programando 'a saco'.