MAQUINAS DE JUEGO Y LA MODULARIZACION
Las maquinas de juego son conocidas bajo diferentes nombres - slot, slot machine, poker machine o fruit machine, pero también „el bandido de una mano“. Slot machine se utiliza en el inglés americano, poker machine en el inglés australiano y fruit machine en el inglés británico.
las máquinas se clasifican en los siguiente grupos:
Tipo "A" puramente recreativas, que no ofrecen al jugador
o usuario beneficio económico alguno directo o indirecto,
pudiendo dividirse en manuales y electrónicas.
Tipo "B" o recreativas con premio, que a cambio del precio
de una partida o jugada conceden al usuario un tiempo de
uso o de juego y, eventualmente, un premio en metálico en
las condiciones determinadas reglamentariamente.
Tipo "C" o de azar, que a cambio del precio de la partida
o jugada conceden al usuario un tiempo de uso o de juego
y, eventualmente, un premio en metálico que dependerá siem-
pre del azar y en las condiciones determinadas reglamen-
tariamente».
En la modularización digital, los esquemas y los automatismos, al operar simbólicamente, también generan conocimiento y sensaciones, variaciones continuas y discontinuas que permiten la inmersión cognitiva en un entorno tridimensional hecho de categorías no 16 jerárquicas y navigacionales. Aunque esto no sea detectable en su
totalidad por los sentidos, se entiende que atrapa al inmersor virtual en un mundo de apariencias que producen la sensación de realidad, esto es, permite no solo tener sensaciones sonoras y táctiles sino ingresar en un juego interactivo de predicciones y comprobaciones que capacita para navegar entre modalidades sensoriales, manipular objetos, moverse a través de los objetos, flotar sobre el suelo, y tener la sensación de autonomía total.
En este sentido, la realidad virtual es un constructo digital de un mundo modular autoorganizado en espacios y tiempos simulados que representan realidades mediante la reconfiguración de escenarios de acción que no están materialmente en ningún lugar y la inmersión en sensaciones que no tiene contextos orgánicos y son independientes del dominio cultural, pero a la vez están limitados o aislados en su capacidad para acceder a los fondos de cualquier dominio cultural y por ello no sé sabe bien cual es su capacidad para crear nuevas condiciones cognitivo-culturales.
Sin duda se trata de un desanclaje de la realidad cultural, pero a partir de ahí las opiniones son diversas. Mientras unos consideran que la reproducción digital en masa y la repetición sacian pronto los perceptos y los endoceptos y por ello resultan escasos como fuentes de valor social y estético, otros afirman que no todo son medios racionales para fines
semánticamente vacíos y la reproducción digital abre nuevas experiencias actanciales y evanescentes.
La realidad virtual comercial augura un enriquecimiento de las experiencias visuales y del resto de las modalidades sensoriales, aunque de momento no es más que una simplificación de la percepción de modelos abstractos en escenarios basado en las imágenes animadas que residen de forma simbólica en la memoria del ordenador y en las
tramas de la ficción y los juegos de rol.
miércoles, 14 de marzo de 2007
lunes, 12 de marzo de 2007
Tarea sobre conceptos de Videojuegos
Tipos de videoJuegos
Las clasificaciones de los videojuegos se hacen teniendo en cuenta criterios comerciales, y estos se agrupan en función de sus objetivos, estructura y forma de funcionamiento. Existen cuatro tipos de videojuegos, dentro de los cuales se pueden encontrar subcategorías. JUEGOS DE ARCADE Son aquellos cuya estructura se fundamenta en actividades de mucha destreza que permiten al jugador recorrer distintas pantallas. La rapidez en este tipo de juegos es lo más importante, incluso más que la propia estrategia del juego. Desarrollar habilidades psicomotrices, lateralidad, organización espacial... aspectos imprescindibles para el desarrollo integral de la persona. Son apropiados para cualquier edad, sobre todo, para niños pequeños. Existen cuatro tipo de arcades: Juegos de plataforma. El protagonista de estos juegos suele ser un personaje infantil o un dibujo animado que a través de las diversas pantallas debe ir eliminando diversos obstáculos, normalmente animales o plantas hasta que llega a cumplir la misión encomendada. Deportivos. Son juegos que simulan partidos de todos los deportes, la pelota se mueve de un lado a otro de la pantalla y el jugador o juega solo, o se encuentra en uno de los equipos. Laberintos. Consiste en un laberinto en el que el usuario se identifica con el personaje del juego que se encuentra dentro del espacio con unas dificultades que debe superar en el menor tiempo posible y así poder acceder a la salida. Dispara y olvida. La finalidad de estos juegos consiste en disparar el mayor número de proyectiles, y así destruir todo lo que se mueva en la pantalla. JUEGOS DE SIMULACIÓN En este tipo de juegos el usuario se sumerge en un mundo más o menos real, que acostumbra a simular aspectos reales de la vida. Suelen estar dirigidos a niños más mayores (a partir de los 12 años) Normalmente estos juegos incitan a la competitividad. Podemos encontrar dos categorías: Simuladores instrumentales. El usuario de forma individual o en competición con otro, conduce un vehículo donde se encuentra con diversos obstáculos, curvas... a los cuales debe superar en el menor tiempo posible hasta llegar a la meta. Pueden ser coches, aviones, naves espaciales... Simuladores de situaciones. En estos se puede encontrar dos tipos, los simuladores deportivos que ejercen gran atracción y son muy populares. Además los avances tecnológicos hacen que cada vez sean más complejos y se parezcan más a la realidad. También se encuentran los simuladores de Dios, que son aquellos que permiten al usuario crear mundos. JUEGOS ESTRATÉGICOS El usuario debe seguir una estrategia que irá desarrollando a lo largo del juego. Éste ha de reflexionar para buscar una serie de maniobras tácticas y conseguir el objetivo final. Este tipo de juegos favorece el desarrollo del razonamiento hipotético y es aconsejable utilizarlos a partir de los 12 años. Existen tres tipos de juegos estratégicos: Aventuras gráficas. Son aquellos juegos en los que el usuario indica al personaje protagonista qué debe hacer para llegar a un objetivo concreto, lo cual, se le irá indicando a lo largo de toda la aventura. Juegos de rol. Están basados en técnicas de grupo en las que se representa un papel y están destinados a permitir a los participantes el análisis de los tipos de relaciones personales dadas en una situación concreta. Juegos de estrategia militar. Consisten en dirigir acciones militares frente a posibles invasores de nuestro planeta o de otro creado virtualmente. JUEGOS DE MESA Están basados en juegos clásicos como el parchís, ajedrez, tres en raya... El usuario está sujeto al cumplimiento de una serie de reglas específicas para cada uno de ellos. En casi todos, el usuario puede jugar contra otro adversario o bien contra el propio ordenador. Este tipo de juegos es aconsejable para niños de todas las edades.
Tipos de vistas
3ra persona: El concepto 3ra persona es de la vista del personaje, que se ve a "Él". Por lo general son en 3D y se le ve al personaje desde atras. Se nota mucho la diferencia de estos juegos porque son un poco mas realistas que los plataformas en 3D. En el caso de un famoso juego llamado Tomb Raider puede tomar varias armas, objetos, etc. A diferencia de los juegos de plataforma los objetos (o items) solo pueden ser para generar determinado poder o algo de puntaje, pero en los de 3ra persona se pueden guardar como objetos reales, y es que estos juegos tienden a ser mas reales que los de plataformas y me atrevo a decir que el Mario 64 es una combinacion de Plataforma y 3era persona. Para Mario 64 la vista es de 3ra persona pero el ambiente es Plataforma siempre. Otros ejemplos: Max Payne, Hitman, Resident Evil, etc.
1ra persona: Como el de 3ra persona, solo que visto desde "Yo", es decir "Tu". Ejemplos: Wolfestein 3D, Doom, Quake, Blood, Hard Life, Heretic, Hexen, Duke Nukem, etc. Se caracterizan porque siempre se les ve una mano con algun arma, sus armas tienen balas limitadas, su salud se mide en porcentaje, es decir que por ejemplo %100 es el nivel de salud normal, lo que es el "Armor" o "Armadura" como una especie de defensa y los "Ammos" que son las balas o municiones para una determinada arma y tienen en pila.
Sistemas de Objetivos / Recompensas
Existe una forma de concebir la vida en la cual lo importante es la forma en que la vivas, y no tanto el final al que llegues. Es decir, lo importante es el viaje, no el destino.Es los juegos las cosas son un poco diferentes, en las palabras de Raph Koster:
"The journey is the reward" is a fucking lie. People would rather have the princess.("El viaje es la recompensa" es una jodida mentira. La gente preferiría quedarse con la princesa.)
¿Bastante claro, verdad? La idea detrás de esta afirmación sería que nadie disfruta dentro de un juego un viaje que nunca termina. Quién haya jugado Super Mario Bros. sabrá que lo que nos mantenía jugando era la promesa de que eventualmente rescataríamos a la princesa Toadstool de las garras de malvado Bowser. Incluso no nos desanimaba que después de vencer a Bowser las primeras sietes veces nos tuvieramos que encontrar con un honguito que nos informaba que la princesa estaba en otro castillo.
¿Qué? ¿La princesa no esta aquí? Tienes que estar bromeando, honguito.
¿Qué hubiera pasado si esto se repitiera infinitamente? Castillo tras castillo jamás llegaríamos a salvar a la princesa y nos mantendríamos jugando sin una recompensa. No es que los honguitos no fueran simpaticos, pero la verdad no es la recompensa que yo escogería después de hacer que un reptil enorme cayera en un charco de lava.Psychochild piensa diferente. La recompensa no hace a la gente jugar por si misma. Expone el ejemplo de que pasaría si alguién comprara Super Mario Bros. y después de encender sus consola y que el juego inicie, lo primero que ve en la pantalla es un mensaje de felicitaciones por haber salvado a la princesa.La recompensa esta ahí ¿Cierto? Eso debería ser suficiente para mantener a la gente interesada en el juego.Es evidente que el juego en sí es lo que mantiene a la persona buscandp la recompensa de terminar al terminar con él. Todos los juegos tienen una recompensa de algún modo al terminar con ellos. Ya sea algo tan simple como esto de rescatar a una princesa, poder conocer más de la historía de los personajes que aparecen en un RPG o obtener una puntuación muy alta como en los puzzles al estilo de Tetris.
El final seguro consiste en Kirby comiendo y/o durmiendo, pero lo importante es demostrar que una pelota rosa tambien puede ser un 'hombre de acción'.
Si avanzar en el juego no se disfruta, el viaje no habrá valido la pena y la recompensa no importará tampoco. El viaje debe ser disfrutable por la persona, si no, cualquier cosa que haya al final dejará de ser lo suficientemente llamativa como para mantenerlo jugando.Psychochild lo resume todo en una frase:
"Overcoming the journey is the reward" is the fucking truth.("Superar el viaje es la recompensa" es la jodida verdad.)
Y estoy de acuerdo. En los juegos el viaje debe recompensarte. Un claro ejemplo de esto son los juegos de pelea. En ellos la recompensa es terminar el juego venciendo a la máquina o derrotar a un amigo (¡o a un enemigo!) en un combate uno a uno.
El momento de la victoria es la recompensa, pero todo el viaje que se hizo para llegar ahí es lo que hace que valga la pena. Se puso de por medio la habilidad de ambos jugadores y al final ganó el mejor.
¡En tu cara!
Es un poco diferente a como funciona la vida normalmente, pero así son los juegos.
Hora del juicio
La gran mayoría de los desarrolladores de videojuegos son conocidos por la sobrecarga de trabajo de sus empleados. La "hora del juicio" es el punto en que la gerencia se da cuenta de que el equipo está experimentando un retraso; no se alcanzará a lograr todo lo necesario para completar la "meta" a tiempo, lo que significa que el distribuidor no le pagará al desarrollador hasta que la "meta" sea terminada. Ya que la mayor parte de las compañías de desarrollo son operaciones tan pequeñas, esto presenta un real riesgo de que la compañía no sea capaz de pagarle a sus empleados a tiempo. Amenazas peores ocurren cuando se torna aparente que el equipo no podrá enviar el juego a tiempo en su totalidad.
Una extremadamente común respuesta a esto es la invocación de la "hora del jucio", la que dicta una semana de trabajo de entre 60 y 80 horas, incluyendo trabajo los fines de semana, con la esperanza de que el equipo sea capaz de alcanzar la "meta". La dificultad del flujo de trabajo en la creación de un videojuego hace muy difícil manejar los horarios del equipo, lo que significa que es un proyecto inusual que no sorprende con ningún retraso.
De manera controversial, los empleados en los Estados Unidos no son recompensados con un pago adicional por el tiempo extra trabajado durante la "hora del juicio", debido a que los desarrolladores mantienen empleados asalariados. A los empleados asalariados no se les paga por hora y son clasificados como "profesionales". Por lo tanto, la mayor parte de las leyes acerca del pago por tiempo extra no son aplicables. Una notable excepción es California, donde los desarrolladores de software son específicamente protegidos al hacerse cumplir un salario por hora trabajada.
La atención en cuanto a la "hora del juicio" comenzó a hacerse fuerte en 2004, cuando una entrada de blog titulada "ea_spouse", una especie de manifestación, fue publicada. El blog hablaba sobre la crueldad de la "hora del juicio" y fue "posteado" por Erin Hoffman, la en ese entonces novia del desarrollador de Electronic Arts Leander Hasty (desde ese entonces Hasty y Hoffman se unieron a un estudio de desarrollo independiente, 1st Playable Productions, y fundaron una página web orientada hacia la discusión del ambiente del desarrollo de videojuegos dentro de las industrias, Gamewatch). Hoffman dijo que su vida estaba siendo indirectamente destruida por la política de trabajo de la compañía. Esto llevó a un gran debate dentro de la industria, pero ningún cambio fue visible hasta marzo de 2005, cuando Electronic Arts anunció internamente que estaba planeando extender el pago por tiempo extra de algunos de sus empleados.
El problema acerca de los horarios mal organizados aún continúa. Los desarrolladores de juegos, especialmente los más nuevos, son conocidos por permitir un exceso de entusiasmo por un proyecto para así pasar por alto la inmensa cantidad de trabajo que ha sido establecida luego de que el horario comercial ya ha sido decidido.
Desarrollo de Historias y Antecedentes
Desarrolladores third-party
Los desarrolladores third-party son usualmente llamados por un distribuidor de videojuegos para que desarrollen un título para uno o más sistemas. Tanto el distribuidor como el desarrollador deciden como será el diseño y el contenido del juego. Sin embargo, en general las decisiones del distribuidor van sobre las del desarrollador, debido a que el distribuidor es quien le paga al desarrollador para que cree el juego.
El arreglo del negocio entre el desarrollador y el distribuidor se designa mediante un contrato, el cual especifica una lista de "metas" por cumplir, las que debieran ser enviadas entre cuatro a ocho semanas. Al recibir estas "metas", el distribuidor es capaz de verificar que el trabajo está progresando de una manera lo suficientemente rápida como para alcanzar la fecha límite designada, y de indicarle el camino correcto al desarrollador en el caso de que el juego esté siendo creado de una manera distinta a la pensada. Cuando cada "meta" es completada y aceptada, el distribuidor le paga al desarrollador un avance en regalías. El desarrollador usa este dinero para costear sus operaciones.
Los desarrolladores exitosos pueden mantener a varios equipos trabajando en diferentes juegos para diferentes distribuidores. Sin embargo, en general los desarrolladores third-party tienden a ser pequeños y a estar compuestos de un equipo simple y cercano entre sí.
El desarrollo de juegos third-party es un negocio volátil, ya que los pequeños desarrolladores podrían ser enteramente dependientes del dinero de un distribuidor. Un simple juego cancelado puede ser letal para un pequeño desarrollador. Debido a esto, muchas de las compañías desarrolladoras más pequeñas duran sólo unos pocos años, o incluso algunos pocos meses. La constante batalla por conseguir pagos por "metas" cumplidas y organizar el contrato para el siguiente juego es una distracción persistente en el manejo de cada desarrollador de videojuegos.
Una común y deseable "estrategia de salida" para un desarrollador de videojuegos extremadamente exitoso es vender la compañía a un distribuidor, y así convertirse en un desarrollador interno.
Existen varios tipos de videojuegos según su target, pero en general se dividen en 3 clases: casual, core, y hardcore. Cada clase está definida por las tendencias y costumbres de los jugadores, siendo el tiempo de juego el parámetro principal para caracterizarla. El hardcore gamer típico juega más de 20 horas por semana, cuenta con las últimas consolas del mercado (o una PC muy bien equipada), y prefiere los juegos más violentos o de acción y estrategia. El core gamer típico juega una menor cantidad de horas por semana, y sus preferencias son los juegos de simulación (The Sims es un juego core por excelencia, al igual que Roller Coaster Tycoon ).
Los casual gamers prefieren los juegos de puzzle o de cartas, así como también juegos basados en palabras (Scrabble ).
Géneros de Videojuegos
Un género de videojuego designa un conjunto de videojuegos que poseen una serie de elementos comunes. A lo largo de la historia de los videojuegos aquellos elementos que han compartido varios juegos han servido para clasificar como un género aquellos que les han seguido, de la misma manera que ha pasado con la música o el cine.
Los videojuegos se pueden clasificar como un género u otro dependiendo de su representación gráfica, el tipo de interacción entre el jugador y la máquina, la ambientación y su sistema de juego, siendo este último el criterio más habitual a tener en cuenta.
La siguiente lista de géneros de videojuegos va acompañada de una breve descripción y varios ejemplos de cada uno. Hay que decir que cada vez es más es habitual que un juego contenga elementos de diversos géneros, cosa que hace difícil su clasificación. Uno de los mejores ejemplos de este fenómeno son los juegos de la série Legend of Zelda, que contienen a la vez elementos de acción, de aventure y de juego de rol. Esta fusión de géneros crea a su vez nuevos géneros, como es el caso de lo survival horror como Resident Evil, que mezclan elementos de aventura gráfica con otros de shoot'em up.
Acción
Beat'em up
Los beat'em up son juegos similares a los de lucha, con la diferencia de que en este caso los jugadores deben combatir con un gran número de individuos a lo largo de varios niveles. En los beat'em up suele ser posible jugar dos o más personas a la vez de forma cooperativa para facilitar el progreso.
Ejemplos:
Double Dragon
God of war
Splatterhouse
Final Fight
Streets of Rage
Die Hard Arcade
Devil May Cry
Viewtiful Joe
Lucha
Los juegos de lucha, como indica su nombre, recrean combates entre personajes controlados tanto por un jugador como por la computadora. El jugador ve a los combatientes desde una perspectiva lateral, como si se tratase de un espectador. Este tipo de juegos ponen especial énfasis en las artes marciales, reales o ficticiass (generalmente imposibles de imitar), u otros tipos de enfrentamientos sin armas como el boxeo o la lucha libre. Otros juegos permiten también usar armas como pueden ser espadas, hachas, martillos, etc. o ataques a distancia, normalmente de carácter mágico.
Aunque este género se introdujo a mediados de los años 80, no se popularizó hasta la llegada de Street Fighter II. Con la llegada de los gráficos tridimensionales no cambió el estilo de juego, pero en cambio sí que lo hizo la forma de jugarlos.
Ejemplos: Street Fighter, Fatal Fury, Mortal Kombat, Tekken, Soul Calibur, Dead or Alive.
Infiltración
Los juegos de infiltración son un género relativamente reciente. Aunque la primera entrega de la saga Metal Gear, la abanderada de este género, apareció en 1987 el género de la infiltración no se popularizó hasta la salida de Metal Gear Solid en 1998. Estos juegos se basan en el sigilo, la furtividad y la estrategia en vez de buscar la confrontación directa con el enemigo.
Normalmente los juegos de infiltración aparecen como un subgénero de los juegos de disparos, aunque podemos encontrar juegos como Commandos, que se puede clasificar a la vez como juego de estrategia y de infiltración.
Ejemplos: Metal Gear, Splinter Cell, Hitman, Thief, Beyond Good & Evil.
Plataformas
En los juegos de plataformas el jugador controla a un personaje que debe avanzar por el escenario evitando obstáculos físico, ya sea saltando, escalando o agachándose. Además de las capacidades de desplazamiento como saltar o correr, los personajes de los juegos de plataformas poseen frecuentemente la habilidad de realizar ataques que les permiten vencer a sus enemigos, convirtiéndose así en juegos de acción. Inicialmente los personajes se movían por niveles con un desarrollo horizontal, pero con la llegada de los gráficos 3D este desarrollo se ha ampliado hacia todas las direcciones posibles.
Los juegos de plataformas son uno de los primeros tipos de juegos que aparecieron en los ordenadores. Aunque este género fue muy popular en los 80 y los 90, su popularidad ha disminuido en los últimos años, a medida que se han introducido los gráficos tridimensionales. , mais celle-ci a diminué à mesure que les graphismes en 3D ont fait leur apparition dans les jeux de consoles et PC. Esto se debe en gran parte a que las 3D han hecho que se perdiese la simplicidad de desarrollo que caracterizaba este género.
Ejemplos: Super Mario, Sonic, Alex Kidd, Crash Bandicoot, Rayman, Spyro the Dragon, Donkey Kong Country.
Simulación combate
Género poco llevado a la práctica que se caracteriza por el elevado realismo en todos los aspectos relevantes en cuanto al desarrollo de las partidas. El máximo exponente de este subgénero lo encontramos en Operation Flashpoint y su secuela Armed Assault. Ambos son juegos en los que un solo pero certero disparo significa la muerte, el movimiento de los personajes o el comportamiento del armamento tratan de ser absolutamente realistas. El primero de estos juegos cuenta con una modificación denominada VBS1, que se ha destinado al entrenamiento táctico de algunos cuerpos de élite de ejércitos como el de Estados Unidos o Australia.
Aventura
Clásica
Los juegos de aventura fueron, en cierto modo, los primeros videojuegos que se vendieron en el mercado, empezando por Colossal Cave Adventure en los años 1970. Este tipo de juego se hizo famoso con los juegos de la serie Zork y consiguió alcanzar cierto nivel de popularidad en los años 80 que duró hasta mediados de los 90. El jugador encarna a un protagonista que por lo general debe resolver incógnitas y rompecabezas con objetos diversos. Los primeros videojuegos de aventura eran textuales (aventuras textuales, aventura conversacional o ficción interactiva). En estos, el jugador utiliza el teclado para introducir órdenes como “coger la cuerda” o “ir hacia el oeste” y el ordenador describe lo que pasa. Cuando el uso de gráficos se generalizó, los juegos de aventura textuales dejaron paso a los visuales (por ejemplo, con imágenes del lugar presente) que substituyeron de este modo las descripciones por texto, que se habían vuelto casi superfluas. Estos juegos de aventura con gráficos seguían, no obstante, sirviéndose de la introducción de texto. Además, sigue existiendo una comunidad de autores y jugadores activos de ficción interactiva (véase la web del CAAD para el mundo hispanoparlante), aunque la participación de grandes empresas comerciales es más bien rara.
Gráfica
A comienzos de los '90, el uso creciente del ratón dio pie a los juegos de aventura de tipo "Point and click", también llamados aventura gráfica, en los que ya no se hacía necesaria la introducción de comandos. El jugador puede, por ejemplo, hacer clic con el puntero sobre una cuerda para recogerla.
A finales de los '90, este tipo de juego sufrió una importante pérdida de popularidad, las presentaciones de productos de masas se hicieron raras, hasta el punto que hubo quiene predijeron la muerte de este tipo de videojuegos. No obstante, en 2005, los juegos de aventura experimentaron un retorno con títulos como The Moment of Silence, The Black Mirror, Sherlock Holmes: The Silver Earring o NiBiRu: Age of Secrets. Los grandes juegos de aventura de la historia incluyen títulos como Day of the Tentacle, los juegos de la serie King's Quest, los de la serie Leisure Suit Larry, los de la serie Broken Sword, la serie Gabriel Knight, la serie Police Quest, la serie Space Quest, y los de Monkey Island entre muchos otros.
He aquí otros ejemplos de juegos de aventura: Indiana Jones and the Fate of Atlantis de LucasArts -- 1992, Maniac Mansion de LucasArts -- 1987, The Dig de LucasArts -- 1995, Full Throttle de LucasArts -- 1995, Mundodisco, Grim Fandango de LucasArts -- 1998, Runaway de Dinamic Multimedia -- 2001, Lure of the Temptress de Virgin Interactive -- 1992, Sam & Max Hit the Road de LucasArts -- 1993, Syberia y Syberia II ambos de Microïds -- 2003 y 2004 respectivamente, la serie The Legend of Kyrandia.
Las clasificaciones de los videojuegos se hacen teniendo en cuenta criterios comerciales, y estos se agrupan en función de sus objetivos, estructura y forma de funcionamiento. Existen cuatro tipos de videojuegos, dentro de los cuales se pueden encontrar subcategorías. JUEGOS DE ARCADE Son aquellos cuya estructura se fundamenta en actividades de mucha destreza que permiten al jugador recorrer distintas pantallas. La rapidez en este tipo de juegos es lo más importante, incluso más que la propia estrategia del juego. Desarrollar habilidades psicomotrices, lateralidad, organización espacial... aspectos imprescindibles para el desarrollo integral de la persona. Son apropiados para cualquier edad, sobre todo, para niños pequeños. Existen cuatro tipo de arcades: Juegos de plataforma. El protagonista de estos juegos suele ser un personaje infantil o un dibujo animado que a través de las diversas pantallas debe ir eliminando diversos obstáculos, normalmente animales o plantas hasta que llega a cumplir la misión encomendada. Deportivos. Son juegos que simulan partidos de todos los deportes, la pelota se mueve de un lado a otro de la pantalla y el jugador o juega solo, o se encuentra en uno de los equipos. Laberintos. Consiste en un laberinto en el que el usuario se identifica con el personaje del juego que se encuentra dentro del espacio con unas dificultades que debe superar en el menor tiempo posible y así poder acceder a la salida. Dispara y olvida. La finalidad de estos juegos consiste en disparar el mayor número de proyectiles, y así destruir todo lo que se mueva en la pantalla. JUEGOS DE SIMULACIÓN En este tipo de juegos el usuario se sumerge en un mundo más o menos real, que acostumbra a simular aspectos reales de la vida. Suelen estar dirigidos a niños más mayores (a partir de los 12 años) Normalmente estos juegos incitan a la competitividad. Podemos encontrar dos categorías: Simuladores instrumentales. El usuario de forma individual o en competición con otro, conduce un vehículo donde se encuentra con diversos obstáculos, curvas... a los cuales debe superar en el menor tiempo posible hasta llegar a la meta. Pueden ser coches, aviones, naves espaciales... Simuladores de situaciones. En estos se puede encontrar dos tipos, los simuladores deportivos que ejercen gran atracción y son muy populares. Además los avances tecnológicos hacen que cada vez sean más complejos y se parezcan más a la realidad. También se encuentran los simuladores de Dios, que son aquellos que permiten al usuario crear mundos. JUEGOS ESTRATÉGICOS El usuario debe seguir una estrategia que irá desarrollando a lo largo del juego. Éste ha de reflexionar para buscar una serie de maniobras tácticas y conseguir el objetivo final. Este tipo de juegos favorece el desarrollo del razonamiento hipotético y es aconsejable utilizarlos a partir de los 12 años. Existen tres tipos de juegos estratégicos: Aventuras gráficas. Son aquellos juegos en los que el usuario indica al personaje protagonista qué debe hacer para llegar a un objetivo concreto, lo cual, se le irá indicando a lo largo de toda la aventura. Juegos de rol. Están basados en técnicas de grupo en las que se representa un papel y están destinados a permitir a los participantes el análisis de los tipos de relaciones personales dadas en una situación concreta. Juegos de estrategia militar. Consisten en dirigir acciones militares frente a posibles invasores de nuestro planeta o de otro creado virtualmente. JUEGOS DE MESA Están basados en juegos clásicos como el parchís, ajedrez, tres en raya... El usuario está sujeto al cumplimiento de una serie de reglas específicas para cada uno de ellos. En casi todos, el usuario puede jugar contra otro adversario o bien contra el propio ordenador. Este tipo de juegos es aconsejable para niños de todas las edades.
Tipos de vistas
3ra persona: El concepto 3ra persona es de la vista del personaje, que se ve a "Él". Por lo general son en 3D y se le ve al personaje desde atras. Se nota mucho la diferencia de estos juegos porque son un poco mas realistas que los plataformas en 3D. En el caso de un famoso juego llamado Tomb Raider puede tomar varias armas, objetos, etc. A diferencia de los juegos de plataforma los objetos (o items) solo pueden ser para generar determinado poder o algo de puntaje, pero en los de 3ra persona se pueden guardar como objetos reales, y es que estos juegos tienden a ser mas reales que los de plataformas y me atrevo a decir que el Mario 64 es una combinacion de Plataforma y 3era persona. Para Mario 64 la vista es de 3ra persona pero el ambiente es Plataforma siempre. Otros ejemplos: Max Payne, Hitman, Resident Evil, etc.
1ra persona: Como el de 3ra persona, solo que visto desde "Yo", es decir "Tu". Ejemplos: Wolfestein 3D, Doom, Quake, Blood, Hard Life, Heretic, Hexen, Duke Nukem, etc. Se caracterizan porque siempre se les ve una mano con algun arma, sus armas tienen balas limitadas, su salud se mide en porcentaje, es decir que por ejemplo %100 es el nivel de salud normal, lo que es el "Armor" o "Armadura" como una especie de defensa y los "Ammos" que son las balas o municiones para una determinada arma y tienen en pila.
Sistemas de Objetivos / Recompensas
Existe una forma de concebir la vida en la cual lo importante es la forma en que la vivas, y no tanto el final al que llegues. Es decir, lo importante es el viaje, no el destino.Es los juegos las cosas son un poco diferentes, en las palabras de Raph Koster:
"The journey is the reward" is a fucking lie. People would rather have the princess.("El viaje es la recompensa" es una jodida mentira. La gente preferiría quedarse con la princesa.)
¿Bastante claro, verdad? La idea detrás de esta afirmación sería que nadie disfruta dentro de un juego un viaje que nunca termina. Quién haya jugado Super Mario Bros. sabrá que lo que nos mantenía jugando era la promesa de que eventualmente rescataríamos a la princesa Toadstool de las garras de malvado Bowser. Incluso no nos desanimaba que después de vencer a Bowser las primeras sietes veces nos tuvieramos que encontrar con un honguito que nos informaba que la princesa estaba en otro castillo.
¿Qué? ¿La princesa no esta aquí? Tienes que estar bromeando, honguito.
¿Qué hubiera pasado si esto se repitiera infinitamente? Castillo tras castillo jamás llegaríamos a salvar a la princesa y nos mantendríamos jugando sin una recompensa. No es que los honguitos no fueran simpaticos, pero la verdad no es la recompensa que yo escogería después de hacer que un reptil enorme cayera en un charco de lava.Psychochild piensa diferente. La recompensa no hace a la gente jugar por si misma. Expone el ejemplo de que pasaría si alguién comprara Super Mario Bros. y después de encender sus consola y que el juego inicie, lo primero que ve en la pantalla es un mensaje de felicitaciones por haber salvado a la princesa.La recompensa esta ahí ¿Cierto? Eso debería ser suficiente para mantener a la gente interesada en el juego.Es evidente que el juego en sí es lo que mantiene a la persona buscandp la recompensa de terminar al terminar con él. Todos los juegos tienen una recompensa de algún modo al terminar con ellos. Ya sea algo tan simple como esto de rescatar a una princesa, poder conocer más de la historía de los personajes que aparecen en un RPG o obtener una puntuación muy alta como en los puzzles al estilo de Tetris.
El final seguro consiste en Kirby comiendo y/o durmiendo, pero lo importante es demostrar que una pelota rosa tambien puede ser un 'hombre de acción'.
Si avanzar en el juego no se disfruta, el viaje no habrá valido la pena y la recompensa no importará tampoco. El viaje debe ser disfrutable por la persona, si no, cualquier cosa que haya al final dejará de ser lo suficientemente llamativa como para mantenerlo jugando.Psychochild lo resume todo en una frase:
"Overcoming the journey is the reward" is the fucking truth.("Superar el viaje es la recompensa" es la jodida verdad.)
Y estoy de acuerdo. En los juegos el viaje debe recompensarte. Un claro ejemplo de esto son los juegos de pelea. En ellos la recompensa es terminar el juego venciendo a la máquina o derrotar a un amigo (¡o a un enemigo!) en un combate uno a uno.
El momento de la victoria es la recompensa, pero todo el viaje que se hizo para llegar ahí es lo que hace que valga la pena. Se puso de por medio la habilidad de ambos jugadores y al final ganó el mejor.
¡En tu cara!
Es un poco diferente a como funciona la vida normalmente, pero así son los juegos.
Hora del juicio
La gran mayoría de los desarrolladores de videojuegos son conocidos por la sobrecarga de trabajo de sus empleados. La "hora del juicio" es el punto en que la gerencia se da cuenta de que el equipo está experimentando un retraso; no se alcanzará a lograr todo lo necesario para completar la "meta" a tiempo, lo que significa que el distribuidor no le pagará al desarrollador hasta que la "meta" sea terminada. Ya que la mayor parte de las compañías de desarrollo son operaciones tan pequeñas, esto presenta un real riesgo de que la compañía no sea capaz de pagarle a sus empleados a tiempo. Amenazas peores ocurren cuando se torna aparente que el equipo no podrá enviar el juego a tiempo en su totalidad.
Una extremadamente común respuesta a esto es la invocación de la "hora del jucio", la que dicta una semana de trabajo de entre 60 y 80 horas, incluyendo trabajo los fines de semana, con la esperanza de que el equipo sea capaz de alcanzar la "meta". La dificultad del flujo de trabajo en la creación de un videojuego hace muy difícil manejar los horarios del equipo, lo que significa que es un proyecto inusual que no sorprende con ningún retraso.
De manera controversial, los empleados en los Estados Unidos no son recompensados con un pago adicional por el tiempo extra trabajado durante la "hora del juicio", debido a que los desarrolladores mantienen empleados asalariados. A los empleados asalariados no se les paga por hora y son clasificados como "profesionales". Por lo tanto, la mayor parte de las leyes acerca del pago por tiempo extra no son aplicables. Una notable excepción es California, donde los desarrolladores de software son específicamente protegidos al hacerse cumplir un salario por hora trabajada.
La atención en cuanto a la "hora del juicio" comenzó a hacerse fuerte en 2004, cuando una entrada de blog titulada "ea_spouse", una especie de manifestación, fue publicada. El blog hablaba sobre la crueldad de la "hora del juicio" y fue "posteado" por Erin Hoffman, la en ese entonces novia del desarrollador de Electronic Arts Leander Hasty (desde ese entonces Hasty y Hoffman se unieron a un estudio de desarrollo independiente, 1st Playable Productions, y fundaron una página web orientada hacia la discusión del ambiente del desarrollo de videojuegos dentro de las industrias, Gamewatch). Hoffman dijo que su vida estaba siendo indirectamente destruida por la política de trabajo de la compañía. Esto llevó a un gran debate dentro de la industria, pero ningún cambio fue visible hasta marzo de 2005, cuando Electronic Arts anunció internamente que estaba planeando extender el pago por tiempo extra de algunos de sus empleados.
El problema acerca de los horarios mal organizados aún continúa. Los desarrolladores de juegos, especialmente los más nuevos, son conocidos por permitir un exceso de entusiasmo por un proyecto para así pasar por alto la inmensa cantidad de trabajo que ha sido establecida luego de que el horario comercial ya ha sido decidido.
Desarrollo de Historias y Antecedentes
Desarrolladores third-party
Los desarrolladores third-party son usualmente llamados por un distribuidor de videojuegos para que desarrollen un título para uno o más sistemas. Tanto el distribuidor como el desarrollador deciden como será el diseño y el contenido del juego. Sin embargo, en general las decisiones del distribuidor van sobre las del desarrollador, debido a que el distribuidor es quien le paga al desarrollador para que cree el juego.
El arreglo del negocio entre el desarrollador y el distribuidor se designa mediante un contrato, el cual especifica una lista de "metas" por cumplir, las que debieran ser enviadas entre cuatro a ocho semanas. Al recibir estas "metas", el distribuidor es capaz de verificar que el trabajo está progresando de una manera lo suficientemente rápida como para alcanzar la fecha límite designada, y de indicarle el camino correcto al desarrollador en el caso de que el juego esté siendo creado de una manera distinta a la pensada. Cuando cada "meta" es completada y aceptada, el distribuidor le paga al desarrollador un avance en regalías. El desarrollador usa este dinero para costear sus operaciones.
Los desarrolladores exitosos pueden mantener a varios equipos trabajando en diferentes juegos para diferentes distribuidores. Sin embargo, en general los desarrolladores third-party tienden a ser pequeños y a estar compuestos de un equipo simple y cercano entre sí.
El desarrollo de juegos third-party es un negocio volátil, ya que los pequeños desarrolladores podrían ser enteramente dependientes del dinero de un distribuidor. Un simple juego cancelado puede ser letal para un pequeño desarrollador. Debido a esto, muchas de las compañías desarrolladoras más pequeñas duran sólo unos pocos años, o incluso algunos pocos meses. La constante batalla por conseguir pagos por "metas" cumplidas y organizar el contrato para el siguiente juego es una distracción persistente en el manejo de cada desarrollador de videojuegos.
Una común y deseable "estrategia de salida" para un desarrollador de videojuegos extremadamente exitoso es vender la compañía a un distribuidor, y así convertirse en un desarrollador interno.
Existen varios tipos de videojuegos según su target, pero en general se dividen en 3 clases: casual, core, y hardcore. Cada clase está definida por las tendencias y costumbres de los jugadores, siendo el tiempo de juego el parámetro principal para caracterizarla. El hardcore gamer típico juega más de 20 horas por semana, cuenta con las últimas consolas del mercado (o una PC muy bien equipada), y prefiere los juegos más violentos o de acción y estrategia. El core gamer típico juega una menor cantidad de horas por semana, y sus preferencias son los juegos de simulación (The Sims es un juego core por excelencia, al igual que Roller Coaster Tycoon ).
Los casual gamers prefieren los juegos de puzzle o de cartas, así como también juegos basados en palabras (Scrabble ).
Géneros de Videojuegos
Un género de videojuego designa un conjunto de videojuegos que poseen una serie de elementos comunes. A lo largo de la historia de los videojuegos aquellos elementos que han compartido varios juegos han servido para clasificar como un género aquellos que les han seguido, de la misma manera que ha pasado con la música o el cine.
Los videojuegos se pueden clasificar como un género u otro dependiendo de su representación gráfica, el tipo de interacción entre el jugador y la máquina, la ambientación y su sistema de juego, siendo este último el criterio más habitual a tener en cuenta.
La siguiente lista de géneros de videojuegos va acompañada de una breve descripción y varios ejemplos de cada uno. Hay que decir que cada vez es más es habitual que un juego contenga elementos de diversos géneros, cosa que hace difícil su clasificación. Uno de los mejores ejemplos de este fenómeno son los juegos de la série Legend of Zelda, que contienen a la vez elementos de acción, de aventure y de juego de rol. Esta fusión de géneros crea a su vez nuevos géneros, como es el caso de lo survival horror como Resident Evil, que mezclan elementos de aventura gráfica con otros de shoot'em up.
Acción
Beat'em up
Los beat'em up son juegos similares a los de lucha, con la diferencia de que en este caso los jugadores deben combatir con un gran número de individuos a lo largo de varios niveles. En los beat'em up suele ser posible jugar dos o más personas a la vez de forma cooperativa para facilitar el progreso.
Ejemplos:
Double Dragon
God of war
Splatterhouse
Final Fight
Streets of Rage
Die Hard Arcade
Devil May Cry
Viewtiful Joe
Lucha
Los juegos de lucha, como indica su nombre, recrean combates entre personajes controlados tanto por un jugador como por la computadora. El jugador ve a los combatientes desde una perspectiva lateral, como si se tratase de un espectador. Este tipo de juegos ponen especial énfasis en las artes marciales, reales o ficticiass (generalmente imposibles de imitar), u otros tipos de enfrentamientos sin armas como el boxeo o la lucha libre. Otros juegos permiten también usar armas como pueden ser espadas, hachas, martillos, etc. o ataques a distancia, normalmente de carácter mágico.
Aunque este género se introdujo a mediados de los años 80, no se popularizó hasta la llegada de Street Fighter II. Con la llegada de los gráficos tridimensionales no cambió el estilo de juego, pero en cambio sí que lo hizo la forma de jugarlos.
Ejemplos: Street Fighter, Fatal Fury, Mortal Kombat, Tekken, Soul Calibur, Dead or Alive.
Infiltración
Los juegos de infiltración son un género relativamente reciente. Aunque la primera entrega de la saga Metal Gear, la abanderada de este género, apareció en 1987 el género de la infiltración no se popularizó hasta la salida de Metal Gear Solid en 1998. Estos juegos se basan en el sigilo, la furtividad y la estrategia en vez de buscar la confrontación directa con el enemigo.
Normalmente los juegos de infiltración aparecen como un subgénero de los juegos de disparos, aunque podemos encontrar juegos como Commandos, que se puede clasificar a la vez como juego de estrategia y de infiltración.
Ejemplos: Metal Gear, Splinter Cell, Hitman, Thief, Beyond Good & Evil.
Plataformas
En los juegos de plataformas el jugador controla a un personaje que debe avanzar por el escenario evitando obstáculos físico, ya sea saltando, escalando o agachándose. Además de las capacidades de desplazamiento como saltar o correr, los personajes de los juegos de plataformas poseen frecuentemente la habilidad de realizar ataques que les permiten vencer a sus enemigos, convirtiéndose así en juegos de acción. Inicialmente los personajes se movían por niveles con un desarrollo horizontal, pero con la llegada de los gráficos 3D este desarrollo se ha ampliado hacia todas las direcciones posibles.
Los juegos de plataformas son uno de los primeros tipos de juegos que aparecieron en los ordenadores. Aunque este género fue muy popular en los 80 y los 90, su popularidad ha disminuido en los últimos años, a medida que se han introducido los gráficos tridimensionales. , mais celle-ci a diminué à mesure que les graphismes en 3D ont fait leur apparition dans les jeux de consoles et PC. Esto se debe en gran parte a que las 3D han hecho que se perdiese la simplicidad de desarrollo que caracterizaba este género.
Ejemplos: Super Mario, Sonic, Alex Kidd, Crash Bandicoot, Rayman, Spyro the Dragon, Donkey Kong Country.
Simulación combate
Género poco llevado a la práctica que se caracteriza por el elevado realismo en todos los aspectos relevantes en cuanto al desarrollo de las partidas. El máximo exponente de este subgénero lo encontramos en Operation Flashpoint y su secuela Armed Assault. Ambos son juegos en los que un solo pero certero disparo significa la muerte, el movimiento de los personajes o el comportamiento del armamento tratan de ser absolutamente realistas. El primero de estos juegos cuenta con una modificación denominada VBS1, que se ha destinado al entrenamiento táctico de algunos cuerpos de élite de ejércitos como el de Estados Unidos o Australia.
Aventura
Clásica
Los juegos de aventura fueron, en cierto modo, los primeros videojuegos que se vendieron en el mercado, empezando por Colossal Cave Adventure en los años 1970. Este tipo de juego se hizo famoso con los juegos de la serie Zork y consiguió alcanzar cierto nivel de popularidad en los años 80 que duró hasta mediados de los 90. El jugador encarna a un protagonista que por lo general debe resolver incógnitas y rompecabezas con objetos diversos. Los primeros videojuegos de aventura eran textuales (aventuras textuales, aventura conversacional o ficción interactiva). En estos, el jugador utiliza el teclado para introducir órdenes como “coger la cuerda” o “ir hacia el oeste” y el ordenador describe lo que pasa. Cuando el uso de gráficos se generalizó, los juegos de aventura textuales dejaron paso a los visuales (por ejemplo, con imágenes del lugar presente) que substituyeron de este modo las descripciones por texto, que se habían vuelto casi superfluas. Estos juegos de aventura con gráficos seguían, no obstante, sirviéndose de la introducción de texto. Además, sigue existiendo una comunidad de autores y jugadores activos de ficción interactiva (véase la web del CAAD para el mundo hispanoparlante), aunque la participación de grandes empresas comerciales es más bien rara.
Gráfica
A comienzos de los '90, el uso creciente del ratón dio pie a los juegos de aventura de tipo "Point and click", también llamados aventura gráfica, en los que ya no se hacía necesaria la introducción de comandos. El jugador puede, por ejemplo, hacer clic con el puntero sobre una cuerda para recogerla.
A finales de los '90, este tipo de juego sufrió una importante pérdida de popularidad, las presentaciones de productos de masas se hicieron raras, hasta el punto que hubo quiene predijeron la muerte de este tipo de videojuegos. No obstante, en 2005, los juegos de aventura experimentaron un retorno con títulos como The Moment of Silence, The Black Mirror, Sherlock Holmes: The Silver Earring o NiBiRu: Age of Secrets. Los grandes juegos de aventura de la historia incluyen títulos como Day of the Tentacle, los juegos de la serie King's Quest, los de la serie Leisure Suit Larry, los de la serie Broken Sword, la serie Gabriel Knight, la serie Police Quest, la serie Space Quest, y los de Monkey Island entre muchos otros.
He aquí otros ejemplos de juegos de aventura: Indiana Jones and the Fate of Atlantis de LucasArts -- 1992, Maniac Mansion de LucasArts -- 1987, The Dig de LucasArts -- 1995, Full Throttle de LucasArts -- 1995, Mundodisco, Grim Fandango de LucasArts -- 1998, Runaway de Dinamic Multimedia -- 2001, Lure of the Temptress de Virgin Interactive -- 1992, Sam & Max Hit the Road de LucasArts -- 1993, Syberia y Syberia II ambos de Microïds -- 2003 y 2004 respectivamente, la serie The Legend of Kyrandia.
miércoles, 7 de marzo de 2007
DEFINICION DE CONCEPTOS(USABILIDAD,PLAYABILITY,GAME ENGINE O MAQUINA DE JUEGOS,MOD O MODDING Y DIAGRAMA DE FLUJO DE DATOS)
USABILIDAD (USABILITY)
Origenes controvertidos del término
El término usabilidad, aunque de origen latino, en el contexto que se utiliza deriva directamente del inglés usability. Si bien los filólogos hispánicos consultados coinciden en afirmar que el término puede ser creado en la lengua castellana, su acepción no está clara. En castellano significa capacidad de uso, es decir, la característica que distingue a los objetos diseñados para su utilización de los que no. Sin embargo la acepción inglesa es más amplia y se refiere a la facilidad o nivel de uso, es decir, al grado en el que el diseño de un objeto facilita o dificulta su manejo. A partir de ahora definiremos el término usabilidad basándonos en la segunda acepción.
La usabilidad universal (del inglés usability) es la característica de un sistema que pretende ser utilizado por:
el tipo o tipos específicos de usuario/s,
la tarea o tareas que para las cuales el sistema se ha hecho, y
el contexto en el que se da la interacción.
El "grado de usabilidad" de un sistema es, por su parte, una medida empírica y relativa de la usabilidad del mismo.
Empírica porque no se basa en opiniones o sensaciones sino en pruebas (del inglés tests) de usabilidad, realizadas en laboratorio u observadas mediante trabajo de campo.
Relativa porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas (por lo menos el 80% de los usuarios de un determinado grupo o tipo definido deben poder instalar con éxito el producto X en N minutos sin más ayuda que la guía rápida) o de una comparación con otros sistemas similares.
El concepto de usabilidad se refiere a una aplicación (informática) de (software) o un aparato (hardware), aunque también puede aplicarse a cualquier sistema hecho con algún objetivo particular.
El modelo conceptual de la usabilidad, proveniente del diseño centrado en el usuario, no está completo sin la idea utilidad. En inglés, utilidad + usabilidad es lo que se conoce como usefulness.
La Organización Internacional para la Estandarización (ISO) ofrece dos definiciones de usabilidad:
ISO/IEC 9126:
"La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso"
Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su funcionalidad y eficiencia. La usabilidad depende no sólo del producto sino también del usuario. Por ello un producto no es en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto particular y por usuarios particulares. La usabilidad no puede ser valorada estudiando un producto de manera aislada (Bevan, 1994).
ISO/IEC 9241:
"Usabilidad es la eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico"
Es una definición centrada en el concepto de calidad en el uso, es decir, se refiere a cómo el usuario realiza tareas específicas en escenarios específicos con efectividad
Beneficios de la usabilidad
Actualmente la usabilidad está reconocida como un importante atributo de calidad del software, habiéndose ganado un puesto entre atributos más tradicionales como el rendimiento y la fiabilidad. Incluso diversos programas de estudios se centran en ella. También han surgido diversas empresas de consultoría de usabilidad, y las firmas tradicionales de consultoría y diseño están ofreciendo servicios similares. Entre los principales beneficios encontramos:
Reducción de los costes de aprendizaje.
Disminución de los costes de asistencia y ayuda al usuario.
Optimización de los costes de diseño, rediseño y mantenimiento.
Aumento de la tasa de conversión de visitantes a clientes de un sitio web.
Mejora la imagen y el prestigio.
Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la productividad.
Todos estos beneficios implican una reducción y optimización general de los costes de producción, así como un aumento en la productividad. La usabilidad permite mayor rapidez en la realización de tareas y reduce las pérdidas de tiempo.
Un caso real, después de ser rediseñado prestándose especial atención a la usabilidad, el sitio web de IBM incrementó sus ventas en un 400% (InfoWorld, 1999).
Playability: la facilidad con la cual un instrumento puede ser tocado, concerniente a la comodidad del jugador y al esfuerzo requeridos para producir el resultado deseado.
GAME ENGINE
ENGINE
1) Definición de Engine y distintos tipos de los mismos Engine y para qué sirve
Engine es un motor, como lo especifica la palabra, que hace funcionar todo, como el motor de los vehículos, el corazón, etc. El término ni siquiera se aleja de lo establecido en el mundo de los gamers. Éste es el que permite que el juego tome vida.
El engine es aquél concepto abstracto al cual lo asociamos a una gran cantidad de líneas de código. No crean que el Engine es el juego en sí, si no el pilar “imaginario” donde se sostiene el juego. Sería confundir el motor de un Porche a un Porche entero. Nosotros podemos sacar ese motor y ponerlo en otro auto, y lo mismo pasa con los juegos.
b. En el mundo de los juegos
En realidad, es como un moderador entre los datos que entran y los datos que salen.
Como ven, este generalmente controla el renderizar (procesar una imagen) y otras tecnolog ías necesarias como el audio. También puede manejar otras tareas como Inteligencia Artificial (IA o AI en yanki), detección de colisiones entre objetos del juego, etc. El elemento más común de un Game Engine es proporcionar facilidades de renderizado, tanto 2D (onda Mario BROS) como 3D (Mario 64 por ejemplo).
Los Engines que sólo renderizan en 3D son a veces llamados 3D Engines. Entre algunos están Genesis3D, Irrlicht y Ogre. Muchos 3D Engines son diseñados para otros propósitos como CAD, películas, etc. pero a menudo para incorporarles a los juegos.
También existen otros tipos de Engine, como algunos que calculan las físicas de un juego, como la gravedad, aceleración, volumen, etc. Por citar alguno se encuentra HAVOK, gran engine que permite manejar todo lo relacionado con físicas.c. Cómo se hacenBueno, la gallina no fue primero que el huevo… queda claro… y tampoco el huevo primero que la gallina, o algo así XD. Pero todo debe nacer de algo ¿o no? Los engines son creados con herramientas tan potentes que sería de largo trabajo explicar alguno. La creación de un engine decente para un juego está al nivel de crear Windows o Linux: Es una de las más complicadas tareas que hay en el mundo de la programación.En realidad hay diferentes caminos para hacer uno• Grandes compañías gastan una gran cantidad de tiempo y dinero creando sus propios engines de manera robusta y multifuncional, como por ejemplo Epic Games (Creadores de Unreal), Id Software (creador de Doom y Quake) y Valve (Creador de Half-life).
2) Historia de los Engine, su evolución
“La evolución de los Engines puede ser muy considerada la evolución de los juegos en sí, ya que cada juego, como el tan antiguo Pong, han tenido un “Engine” que los hace correr. El Pong original te dejaba jugar diferentes variaciones del mismo juego básico… variantes donde el rectángulo era más grande o más chico, o donde la bolita se movía más rápido. Esto fue posible gracias al Game Engine: algunas variables podían ser arregladas por otros valores diferentes, y la experiencia del juego cambiaría significativamente.Sin embargo, los “engines” como los que conocemos hoy en día, son particularmente aquellos dentro del contexto de los First Person Shooters (FPS)… Bueno, supongo que esto tiene que ver mucho con la comunidad de MODs primero que nada. Los juegos han sido modificados y arreglados a lo largo del tiempo, e incluso uno de los primeros FPS, como Wolfenstein, tuvieron algunas modestas comunidades de MODs. Gráficas, sonidos, y niveles estaban contenidos en un archivo externo de extensión WAD, que una vez adoptado, podía ser modificado, cambiado y modificado para requisitos particulares para crear nuevos niveles e incluso nuevos juegos “MOD” con nuevas gráficas, sonido, e incluso jugabilidad.Los MODs creados por usuarios continuaron escalando desde los primeros FPS hasta el gran mundo 3D, juegos basados en polígonos. El concepto de “licenciar un engine” también empezó algo temprano: el engine original del Doom fue rehusado numerosos tiempos, siendo con Hexen el más memorable. Cuando Bungie sacó al mercado “Maratón Infinity”, el último capítulo del predecesor de HALO, in 1996, fue incluido un software para modear el HUD y las físicas del game engine: este era un signo de que el modeo era una tendencia cada vez mayor, y cuando los desarrolladores realmente se animaron. Pero el juego que cambió la escena de los motores de juego totalmente fue Half-life: no sólo Half-life usó el motor de Quake para entregar una jugabilidad bien diferente a Quake en un juego comercial, si no el mod creado para Half-life: Counter Strike, prosperó como uno de los más grandes sucesos en el juego en red de la historia. Half-life hizo evidente que los motores de los FPS tenían más potencial que sólo los juegos entregados en un inicio, y Counter Strike fue el mod que puso los MOD en lo alto.”
Tengamos en cuenta que los engines también evolucionaron por su “facilidad de modificación”. Si los desarrolladores se hubieran “saltado” la creación del Engine, y crearan todos los elementos de un juego en algo sólido, como en un archivo ultra-comprimido, arreglar los datos de un nivel existente necesitaría una descompresión y comprimir de nuevo. Con un Engine, sólo necesitarías cambiar ese archivo crítico por uno nuevo: un logro técnico mucho más simple. Por citar un ejemplo, cuando Nintendo creó “The Legend of Zelda: Majora’s Mask” ellos tomaron el engine del título anterior “The Legend of Zelda: The Ocarina of Time” (muy buen juego por cierto) y simplemente reemplazaron los datos anteriores por nuevos datos de gráficos, sonido y niveles. El Engine tomó estos nuevos datos y esencialmente creó un “nuevo” juego, ahorrándole al equipo desarrollador meses de desarrollo para desarrollarlo (valga la redundancia).
MAQUINAS DE JUEGO
Las maquinas de juego son conocidas bajo diferentes nombres - slot, slot machine, poker machine o fruit machine, pero también „el bandido de una mano“. Slot machine se utiliza en el inglés americano, poker machine en el inglés australiano y fruit machine en el inglés británico. En general esto es un equipo que trabaja con monedas. El jugador echa una moneda, ala la palanca y los cilindros giran.
La maquina tiene un mecanismo llamado detector de moneda, es decir que el jugador tiene que echar una moneda real de lo contrario no funciona. La maquina se llama también „bandido de una mano“ debido a la palanca que tiene.
Los cilindros se alinean después de que la palanca sea halada y muestran símbolos, figuras o colores en la parte de alante donde está el jugador. Si los símbolos, figuras o colores se alinean en cierto orden, el jugador gana en dependencia de lo que apostó. Con el desarrollo de la tecnología cambiaron también las maquinas de juego. Aceptaban monedas y billetes, utilizaban botones para empezar el juego, si el jugador no quería tirar la palanca.
historia de las maquinas de juego
Ya que las maquinas son principiantes en el escenario de juego, hay ciertas dudas en cuanto a su historia y desarrollo. Las primeras maquinas surgieron alrededor del 1870. Aunque Charles Fey desarrollo la primera maquina alrededor del 1894 y esta no fue la primera maquina de juego, se considera el padre de las maquinas de juego.
Fey era de origen de Baviera en Alemania y en su vida hubo unos cuantos cambios felices que al final lo llevaron a emigrar a América. Primero se asentó en New Jersey y luego se mudó a California. A los 20 anos de su vida se enfermó de tuberculosis. Los médicos le daban un año de vida pero él logró mentirle a la muerte y cambiar el desarrollo de la historia del juego.
En el año 1895 creó la primera maquina de juego. Sus primeros descubrimientos los podemos ver hasta hoy en algunos equipos modernos. Durante su actuación en Munich en la fabrica de herramientas de agricultura descubrió un gran entusiasmo en si mismo por cualquier mecanismo y así nació el mecánico – entusiasta.
La historia de las maquinas de juego se puede dividir en tres épocas significantes de las cuales cada una dejó huellas en la industria actual:- Era mecánica- Era electromecánica- Era de informática
El prototipo del equipo mecánico de Fey utilizaba cartas y no frutas como lo vemos hoy. Pero utilizaba sonidos de campana siempre que el jugador ganaba – y esto se ha quedado hasta el día de hoy.
Fey es conocido más por su maquina de juego La campana de la libertad de hierro fundido. Cada uno de los tres cilindros tenía diez figuras. Tres símbolos iguales en un nivel significaban ganar el jackpot. El chance de ganar el jackpot era 1:1000.
Como jugar en las maquinas de video
Las maquinas de video para el juego online son iguales que las maquinas de juego en los casinos construidos en tierra firme, lo único que utilizan una pantalla de video y 5 cilindros en lugar de tres ruedas que giran como en la forma tradicional formando tres cilindros. En este caso la grafica está mejorada y otros efectos de video y audio que no se encuentran en las maquinas de tres cilindros y que ofrecen una experiencia excitante del juego. En las maquinas de 3 cilindros solo hay una línea de juego=un juego y en las maquinas de video pueden haber más – hasta 9 juegos. Así como en el caso de las maquinas de 3 cilindros, aquí ganar significa la combinación de tres símbolos en la línea de juego activada.
MODDING
El modding consiste en la modificación estética o funcional de cualquier cosa (software incluido). Sin embargo, la palabra modding se suele usar frecuentemente para las modificaciones realizadas a un ordenador o a algo relacionado con él, como son los periféricos, accesorios e incluso muebles que lo rodean.
A todo el que practica el modding se le llama "modder".
Modding PC
El Modding es personalizar los PC's añadiéndole luces, modificando la estructura de la caja, añadiendo componentes, modificando la forma de estos para obtener mayor espectacularidad y diseño, en definitiva es el Arte de darle forma y color a tu PC poniendo en ello toda la imaginación que uno pueda tener.
MODS
En el mundo de los videojuegos un mod (del inglés modification) es una extensión que modifica un juego original proporcionando nuevas posibilidades, ambientaciones, personajes, diálogos, objetos, etc.
Prácticamente todos los juegos modernos incorporan herramientas y manuales para que exista la posibilidad de modificarlos y así crear el mod.
Aunque anteriormente las comunidades de modders (creadores de mods) eran no oficiales y no pasaban de más de un grupillo de gente, actualmente se ve el interés de las compañías en tener una base de fans que no sólo juegue, si no que además cree estos contenidos no oficiales para extender la vida de los juegos durante, en algunos casos, muchos años más. Actualmente se puede ver a las compañías dando el primer empujón a las comunidades de modders, dandoles las herramientas, los tutoriales y el soporte necesario para que los fans se involucren más en los juegos.
Conversión total
Una conversión total es un mod que cambia el juego por completo. Es como crear y jugar un juego completamente nuevo. El mejor ejemplo de las conversiones totales es Counter Strike, mod del mítico Half-Life, que incluso llegó a ser más popular que el juego original.
Conversión parcial
Las conversiones parciales son aquellas que agregan al juego normal. Muchos juegos permiten a los usuarios modificar objetos, alterar sonidos, cambiar algunos diálogos etc.
Desarrollo
Los mods más populares son aquellos desarrollados para los First Person Shooters, como Battlefield, Quake, Unreal Tournament y sobretodo Half Life. Los juegos de Estrategia en Tiempo Real como Total Anihilation, Warcraft III o Command&Conquer también gozan de varias comunidades. Hay que tener en cuenta que aunque los programas que se utilizan para crear mods pueden ser oficiales, los modders (personas que crean mods) son siempre en su mayoría aficionados con ganas de indagar más en sus juegos favoritos. Gente con mucha imaginación y creatividad que se anima a editar el juego. Por estos motivos, muchos mods quedan inacabados, y muchos tienen pésima calidad. En muchos casos los mods son creados como "entrenamiento" para aprender a utilizar tal o cual herramienta, en otros casos no encuentra interés por parte de la comunidad, y en otros casos problemas personales o, luego de extender el proyecto durante muchos meses, el propio desinterés del creador hace que el proyecto quede inconcluso. Por motivos de Copyright y por su naturaleza no oficial, se requiere que los mods siempre sean de distribución gratuita.
Herramientas
Las herramientas para crear mods son en su mayoría creadas por aficionados. Gente que sabe programar y comienza a crear herramientas para que la comunidad pueda modificar los juegos. Una de las primeras herramientas creadas para hacer modificaciones fue el Bard's Tale Construction Set, lanzado en 1991. Pasado el tiempo, las herramientas se han vuelto más populares y la mayoría de los juegos lanzados vienen ya con sus propias herramientas, tal es el caso del Toolset de Neverwinter Nights o el Valve Hammer Editor para Half Life I y II, o el Construction Set de Elder Scrolls.
Diagrama de flujo de datos
La presente guía denominada DIAGRAMA DE FLUJO DE DATOS, ilustra una de las técnicas para representar “Soluciones” a problemas del Mundo Real en forma visual, es decir; en forma grafica. Esta técnica mediante graficas de Diagrama de flujo, ilustra como diseñar los procedimientos o sentencias con coherencia lógica, que representan la solución al problema planteado.
Hasta la presente década, para el desarrollo de cursos, tales como Algoritmos y Estructuras de Datos, no ha existido un Software que permita implementar el Diagrama de Flujo del problema planteado y que en especial permita su Ejecución (Compilación) y ver los resultados dentro del mismo diagrama de flujo, según el objetivo del problema. Es decir; Ud. puede comprobar la lógica de su algoritmo, sin utilizar algún Compilador Real o Lenguaje de Programación específic (Turbo Pascal, Borland C++ 5.0, etc ). Motivo por el cual, y como Docente responsable de la Asignatura de Lenguajes Algorítmicos por más de una década, presento los problemas y su solución usando el Software (Diagrama de Flujo de Datos), producto desarrollado en la Universidad del Magdalena Santa Marta, Colombia.
Este producto, cubre en forma eficiente la ejecución de programas usando Estructuras de Control, Vectores, matrices y Programación Modular Dependiente, pero el Software tiene limitaciones para implementar problemas usando Registros, Archivos, Punteros y Diseño de Programación Independiente Los Programas Fuentes Ud. Puede encontrarlo en las textos de : Algoritmos en Borland Pascal For Windows versión 7.0 o en el texto Algoritmos y sus Aplicaciones en Borland C++ 5.0.
Diagrama de flujo de datos
Modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. Los rectángulos representan entidades externas, los rectángulos abiertos almacenes (archivos), los círculos procesos y la flechas un flujo de datos desde (o hacia) cualquier elemento a (o desde) un proceso. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo (con complemento). Un diagrama de flujo de datos (DFD) puede ser expandido dividiendo (expandiendo) algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos.
Los elementos que componen a un DFD son los siguientes:
Función. Representará la transformación del flujo de datos. Muestra cómo una o más entradas se transforman en salidas. Su nombre comienza con un verbo y es lo suficientemente largo y claro para que cualquier persona entienda de qué se trata. Dichas funciones van numeradas para diferenciarlas en un mismo nivel mostrando la jerarquía entre los niveles. Es representado por un círculo.
Flujo de dato. Es la representación del flujo del dato del origen al destino. Lo representa un flecha que indica su dirección. Los datos siempre van hacia y/o desde una función.
Almacenamiento. Son los datos pasivos; generalmente archivos, tablas, etc. Son representados por un cuadrado.
Origenes controvertidos del término
El término usabilidad, aunque de origen latino, en el contexto que se utiliza deriva directamente del inglés usability. Si bien los filólogos hispánicos consultados coinciden en afirmar que el término puede ser creado en la lengua castellana, su acepción no está clara. En castellano significa capacidad de uso, es decir, la característica que distingue a los objetos diseñados para su utilización de los que no. Sin embargo la acepción inglesa es más amplia y se refiere a la facilidad o nivel de uso, es decir, al grado en el que el diseño de un objeto facilita o dificulta su manejo. A partir de ahora definiremos el término usabilidad basándonos en la segunda acepción.
La usabilidad universal (del inglés usability) es la característica de un sistema que pretende ser utilizado por:
el tipo o tipos específicos de usuario/s,
la tarea o tareas que para las cuales el sistema se ha hecho, y
el contexto en el que se da la interacción.
El "grado de usabilidad" de un sistema es, por su parte, una medida empírica y relativa de la usabilidad del mismo.
Empírica porque no se basa en opiniones o sensaciones sino en pruebas (del inglés tests) de usabilidad, realizadas en laboratorio u observadas mediante trabajo de campo.
Relativa porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas (por lo menos el 80% de los usuarios de un determinado grupo o tipo definido deben poder instalar con éxito el producto X en N minutos sin más ayuda que la guía rápida) o de una comparación con otros sistemas similares.
El concepto de usabilidad se refiere a una aplicación (informática) de (software) o un aparato (hardware), aunque también puede aplicarse a cualquier sistema hecho con algún objetivo particular.
El modelo conceptual de la usabilidad, proveniente del diseño centrado en el usuario, no está completo sin la idea utilidad. En inglés, utilidad + usabilidad es lo que se conoce como usefulness.
La Organización Internacional para la Estandarización (ISO) ofrece dos definiciones de usabilidad:
ISO/IEC 9126:
"La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso"
Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su funcionalidad y eficiencia. La usabilidad depende no sólo del producto sino también del usuario. Por ello un producto no es en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto particular y por usuarios particulares. La usabilidad no puede ser valorada estudiando un producto de manera aislada (Bevan, 1994).
ISO/IEC 9241:
"Usabilidad es la eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico"
Es una definición centrada en el concepto de calidad en el uso, es decir, se refiere a cómo el usuario realiza tareas específicas en escenarios específicos con efectividad
Beneficios de la usabilidad
Actualmente la usabilidad está reconocida como un importante atributo de calidad del software, habiéndose ganado un puesto entre atributos más tradicionales como el rendimiento y la fiabilidad. Incluso diversos programas de estudios se centran en ella. También han surgido diversas empresas de consultoría de usabilidad, y las firmas tradicionales de consultoría y diseño están ofreciendo servicios similares. Entre los principales beneficios encontramos:
Reducción de los costes de aprendizaje.
Disminución de los costes de asistencia y ayuda al usuario.
Optimización de los costes de diseño, rediseño y mantenimiento.
Aumento de la tasa de conversión de visitantes a clientes de un sitio web.
Mejora la imagen y el prestigio.
Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la productividad.
Todos estos beneficios implican una reducción y optimización general de los costes de producción, así como un aumento en la productividad. La usabilidad permite mayor rapidez en la realización de tareas y reduce las pérdidas de tiempo.
Un caso real, después de ser rediseñado prestándose especial atención a la usabilidad, el sitio web de IBM incrementó sus ventas en un 400% (InfoWorld, 1999).
Playability: la facilidad con la cual un instrumento puede ser tocado, concerniente a la comodidad del jugador y al esfuerzo requeridos para producir el resultado deseado.
GAME ENGINE
ENGINE
1) Definición de Engine y distintos tipos de los mismos Engine y para qué sirve
Engine es un motor, como lo especifica la palabra, que hace funcionar todo, como el motor de los vehículos, el corazón, etc. El término ni siquiera se aleja de lo establecido en el mundo de los gamers. Éste es el que permite que el juego tome vida.
El engine es aquél concepto abstracto al cual lo asociamos a una gran cantidad de líneas de código. No crean que el Engine es el juego en sí, si no el pilar “imaginario” donde se sostiene el juego. Sería confundir el motor de un Porche a un Porche entero. Nosotros podemos sacar ese motor y ponerlo en otro auto, y lo mismo pasa con los juegos.
b. En el mundo de los juegos
En realidad, es como un moderador entre los datos que entran y los datos que salen.
Como ven, este generalmente controla el renderizar (procesar una imagen) y otras tecnolog ías necesarias como el audio. También puede manejar otras tareas como Inteligencia Artificial (IA o AI en yanki), detección de colisiones entre objetos del juego, etc. El elemento más común de un Game Engine es proporcionar facilidades de renderizado, tanto 2D (onda Mario BROS) como 3D (Mario 64 por ejemplo).
Los Engines que sólo renderizan en 3D son a veces llamados 3D Engines. Entre algunos están Genesis3D, Irrlicht y Ogre. Muchos 3D Engines son diseñados para otros propósitos como CAD, películas, etc. pero a menudo para incorporarles a los juegos.
También existen otros tipos de Engine, como algunos que calculan las físicas de un juego, como la gravedad, aceleración, volumen, etc. Por citar alguno se encuentra HAVOK, gran engine que permite manejar todo lo relacionado con físicas.c. Cómo se hacenBueno, la gallina no fue primero que el huevo… queda claro… y tampoco el huevo primero que la gallina, o algo así XD. Pero todo debe nacer de algo ¿o no? Los engines son creados con herramientas tan potentes que sería de largo trabajo explicar alguno. La creación de un engine decente para un juego está al nivel de crear Windows o Linux: Es una de las más complicadas tareas que hay en el mundo de la programación.En realidad hay diferentes caminos para hacer uno• Grandes compañías gastan una gran cantidad de tiempo y dinero creando sus propios engines de manera robusta y multifuncional, como por ejemplo Epic Games (Creadores de Unreal), Id Software (creador de Doom y Quake) y Valve (Creador de Half-life).
2) Historia de los Engine, su evolución
“La evolución de los Engines puede ser muy considerada la evolución de los juegos en sí, ya que cada juego, como el tan antiguo Pong, han tenido un “Engine” que los hace correr. El Pong original te dejaba jugar diferentes variaciones del mismo juego básico… variantes donde el rectángulo era más grande o más chico, o donde la bolita se movía más rápido. Esto fue posible gracias al Game Engine: algunas variables podían ser arregladas por otros valores diferentes, y la experiencia del juego cambiaría significativamente.Sin embargo, los “engines” como los que conocemos hoy en día, son particularmente aquellos dentro del contexto de los First Person Shooters (FPS)… Bueno, supongo que esto tiene que ver mucho con la comunidad de MODs primero que nada. Los juegos han sido modificados y arreglados a lo largo del tiempo, e incluso uno de los primeros FPS, como Wolfenstein, tuvieron algunas modestas comunidades de MODs. Gráficas, sonidos, y niveles estaban contenidos en un archivo externo de extensión WAD, que una vez adoptado, podía ser modificado, cambiado y modificado para requisitos particulares para crear nuevos niveles e incluso nuevos juegos “MOD” con nuevas gráficas, sonido, e incluso jugabilidad.Los MODs creados por usuarios continuaron escalando desde los primeros FPS hasta el gran mundo 3D, juegos basados en polígonos. El concepto de “licenciar un engine” también empezó algo temprano: el engine original del Doom fue rehusado numerosos tiempos, siendo con Hexen el más memorable. Cuando Bungie sacó al mercado “Maratón Infinity”, el último capítulo del predecesor de HALO, in 1996, fue incluido un software para modear el HUD y las físicas del game engine: este era un signo de que el modeo era una tendencia cada vez mayor, y cuando los desarrolladores realmente se animaron. Pero el juego que cambió la escena de los motores de juego totalmente fue Half-life: no sólo Half-life usó el motor de Quake para entregar una jugabilidad bien diferente a Quake en un juego comercial, si no el mod creado para Half-life: Counter Strike, prosperó como uno de los más grandes sucesos en el juego en red de la historia. Half-life hizo evidente que los motores de los FPS tenían más potencial que sólo los juegos entregados en un inicio, y Counter Strike fue el mod que puso los MOD en lo alto.”
Tengamos en cuenta que los engines también evolucionaron por su “facilidad de modificación”. Si los desarrolladores se hubieran “saltado” la creación del Engine, y crearan todos los elementos de un juego en algo sólido, como en un archivo ultra-comprimido, arreglar los datos de un nivel existente necesitaría una descompresión y comprimir de nuevo. Con un Engine, sólo necesitarías cambiar ese archivo crítico por uno nuevo: un logro técnico mucho más simple. Por citar un ejemplo, cuando Nintendo creó “The Legend of Zelda: Majora’s Mask” ellos tomaron el engine del título anterior “The Legend of Zelda: The Ocarina of Time” (muy buen juego por cierto) y simplemente reemplazaron los datos anteriores por nuevos datos de gráficos, sonido y niveles. El Engine tomó estos nuevos datos y esencialmente creó un “nuevo” juego, ahorrándole al equipo desarrollador meses de desarrollo para desarrollarlo (valga la redundancia).
MAQUINAS DE JUEGO
Las maquinas de juego son conocidas bajo diferentes nombres - slot, slot machine, poker machine o fruit machine, pero también „el bandido de una mano“. Slot machine se utiliza en el inglés americano, poker machine en el inglés australiano y fruit machine en el inglés británico. En general esto es un equipo que trabaja con monedas. El jugador echa una moneda, ala la palanca y los cilindros giran.
La maquina tiene un mecanismo llamado detector de moneda, es decir que el jugador tiene que echar una moneda real de lo contrario no funciona. La maquina se llama también „bandido de una mano“ debido a la palanca que tiene.
Los cilindros se alinean después de que la palanca sea halada y muestran símbolos, figuras o colores en la parte de alante donde está el jugador. Si los símbolos, figuras o colores se alinean en cierto orden, el jugador gana en dependencia de lo que apostó. Con el desarrollo de la tecnología cambiaron también las maquinas de juego. Aceptaban monedas y billetes, utilizaban botones para empezar el juego, si el jugador no quería tirar la palanca.
historia de las maquinas de juego
Ya que las maquinas son principiantes en el escenario de juego, hay ciertas dudas en cuanto a su historia y desarrollo. Las primeras maquinas surgieron alrededor del 1870. Aunque Charles Fey desarrollo la primera maquina alrededor del 1894 y esta no fue la primera maquina de juego, se considera el padre de las maquinas de juego.
Fey era de origen de Baviera en Alemania y en su vida hubo unos cuantos cambios felices que al final lo llevaron a emigrar a América. Primero se asentó en New Jersey y luego se mudó a California. A los 20 anos de su vida se enfermó de tuberculosis. Los médicos le daban un año de vida pero él logró mentirle a la muerte y cambiar el desarrollo de la historia del juego.
En el año 1895 creó la primera maquina de juego. Sus primeros descubrimientos los podemos ver hasta hoy en algunos equipos modernos. Durante su actuación en Munich en la fabrica de herramientas de agricultura descubrió un gran entusiasmo en si mismo por cualquier mecanismo y así nació el mecánico – entusiasta.
La historia de las maquinas de juego se puede dividir en tres épocas significantes de las cuales cada una dejó huellas en la industria actual:- Era mecánica- Era electromecánica- Era de informática
El prototipo del equipo mecánico de Fey utilizaba cartas y no frutas como lo vemos hoy. Pero utilizaba sonidos de campana siempre que el jugador ganaba – y esto se ha quedado hasta el día de hoy.
Fey es conocido más por su maquina de juego La campana de la libertad de hierro fundido. Cada uno de los tres cilindros tenía diez figuras. Tres símbolos iguales en un nivel significaban ganar el jackpot. El chance de ganar el jackpot era 1:1000.
Como jugar en las maquinas de video
Las maquinas de video para el juego online son iguales que las maquinas de juego en los casinos construidos en tierra firme, lo único que utilizan una pantalla de video y 5 cilindros en lugar de tres ruedas que giran como en la forma tradicional formando tres cilindros. En este caso la grafica está mejorada y otros efectos de video y audio que no se encuentran en las maquinas de tres cilindros y que ofrecen una experiencia excitante del juego. En las maquinas de 3 cilindros solo hay una línea de juego=un juego y en las maquinas de video pueden haber más – hasta 9 juegos. Así como en el caso de las maquinas de 3 cilindros, aquí ganar significa la combinación de tres símbolos en la línea de juego activada.
MODDING
El modding consiste en la modificación estética o funcional de cualquier cosa (software incluido). Sin embargo, la palabra modding se suele usar frecuentemente para las modificaciones realizadas a un ordenador o a algo relacionado con él, como son los periféricos, accesorios e incluso muebles que lo rodean.
A todo el que practica el modding se le llama "modder".
Modding PC
El Modding es personalizar los PC's añadiéndole luces, modificando la estructura de la caja, añadiendo componentes, modificando la forma de estos para obtener mayor espectacularidad y diseño, en definitiva es el Arte de darle forma y color a tu PC poniendo en ello toda la imaginación que uno pueda tener.
MODS
En el mundo de los videojuegos un mod (del inglés modification) es una extensión que modifica un juego original proporcionando nuevas posibilidades, ambientaciones, personajes, diálogos, objetos, etc.
Prácticamente todos los juegos modernos incorporan herramientas y manuales para que exista la posibilidad de modificarlos y así crear el mod.
Aunque anteriormente las comunidades de modders (creadores de mods) eran no oficiales y no pasaban de más de un grupillo de gente, actualmente se ve el interés de las compañías en tener una base de fans que no sólo juegue, si no que además cree estos contenidos no oficiales para extender la vida de los juegos durante, en algunos casos, muchos años más. Actualmente se puede ver a las compañías dando el primer empujón a las comunidades de modders, dandoles las herramientas, los tutoriales y el soporte necesario para que los fans se involucren más en los juegos.
Conversión total
Una conversión total es un mod que cambia el juego por completo. Es como crear y jugar un juego completamente nuevo. El mejor ejemplo de las conversiones totales es Counter Strike, mod del mítico Half-Life, que incluso llegó a ser más popular que el juego original.
Conversión parcial
Las conversiones parciales son aquellas que agregan al juego normal. Muchos juegos permiten a los usuarios modificar objetos, alterar sonidos, cambiar algunos diálogos etc.
Desarrollo
Los mods más populares son aquellos desarrollados para los First Person Shooters, como Battlefield, Quake, Unreal Tournament y sobretodo Half Life. Los juegos de Estrategia en Tiempo Real como Total Anihilation, Warcraft III o Command&Conquer también gozan de varias comunidades. Hay que tener en cuenta que aunque los programas que se utilizan para crear mods pueden ser oficiales, los modders (personas que crean mods) son siempre en su mayoría aficionados con ganas de indagar más en sus juegos favoritos. Gente con mucha imaginación y creatividad que se anima a editar el juego. Por estos motivos, muchos mods quedan inacabados, y muchos tienen pésima calidad. En muchos casos los mods son creados como "entrenamiento" para aprender a utilizar tal o cual herramienta, en otros casos no encuentra interés por parte de la comunidad, y en otros casos problemas personales o, luego de extender el proyecto durante muchos meses, el propio desinterés del creador hace que el proyecto quede inconcluso. Por motivos de Copyright y por su naturaleza no oficial, se requiere que los mods siempre sean de distribución gratuita.
Herramientas
Las herramientas para crear mods son en su mayoría creadas por aficionados. Gente que sabe programar y comienza a crear herramientas para que la comunidad pueda modificar los juegos. Una de las primeras herramientas creadas para hacer modificaciones fue el Bard's Tale Construction Set, lanzado en 1991. Pasado el tiempo, las herramientas se han vuelto más populares y la mayoría de los juegos lanzados vienen ya con sus propias herramientas, tal es el caso del Toolset de Neverwinter Nights o el Valve Hammer Editor para Half Life I y II, o el Construction Set de Elder Scrolls.
Diagrama de flujo de datos
La presente guía denominada DIAGRAMA DE FLUJO DE DATOS, ilustra una de las técnicas para representar “Soluciones” a problemas del Mundo Real en forma visual, es decir; en forma grafica. Esta técnica mediante graficas de Diagrama de flujo, ilustra como diseñar los procedimientos o sentencias con coherencia lógica, que representan la solución al problema planteado.
Hasta la presente década, para el desarrollo de cursos, tales como Algoritmos y Estructuras de Datos, no ha existido un Software que permita implementar el Diagrama de Flujo del problema planteado y que en especial permita su Ejecución (Compilación) y ver los resultados dentro del mismo diagrama de flujo, según el objetivo del problema. Es decir; Ud. puede comprobar la lógica de su algoritmo, sin utilizar algún Compilador Real o Lenguaje de Programación específic (Turbo Pascal, Borland C++ 5.0, etc ). Motivo por el cual, y como Docente responsable de la Asignatura de Lenguajes Algorítmicos por más de una década, presento los problemas y su solución usando el Software (Diagrama de Flujo de Datos), producto desarrollado en la Universidad del Magdalena Santa Marta, Colombia.
Este producto, cubre en forma eficiente la ejecución de programas usando Estructuras de Control, Vectores, matrices y Programación Modular Dependiente, pero el Software tiene limitaciones para implementar problemas usando Registros, Archivos, Punteros y Diseño de Programación Independiente Los Programas Fuentes Ud. Puede encontrarlo en las textos de : Algoritmos en Borland Pascal For Windows versión 7.0 o en el texto Algoritmos y sus Aplicaciones en Borland C++ 5.0.
Diagrama de flujo de datos
Modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. Los rectángulos representan entidades externas, los rectángulos abiertos almacenes (archivos), los círculos procesos y la flechas un flujo de datos desde (o hacia) cualquier elemento a (o desde) un proceso. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo (con complemento). Un diagrama de flujo de datos (DFD) puede ser expandido dividiendo (expandiendo) algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos.
Los elementos que componen a un DFD son los siguientes:
Función. Representará la transformación del flujo de datos. Muestra cómo una o más entradas se transforman en salidas. Su nombre comienza con un verbo y es lo suficientemente largo y claro para que cualquier persona entienda de qué se trata. Dichas funciones van numeradas para diferenciarlas en un mismo nivel mostrando la jerarquía entre los niveles. Es representado por un círculo.
Flujo de dato. Es la representación del flujo del dato del origen al destino. Lo representa un flecha que indica su dirección. Los datos siempre van hacia y/o desde una función.
Almacenamiento. Son los datos pasivos; generalmente archivos, tablas, etc. Son representados por un cuadrado.
viernes, 2 de marzo de 2007
CONFERENCIAS Y MESAS REDONDAS DE LAS JORNADAS DE INGENIERÍA EN COMPUTACIÓN
CONFERENCIAS Y MESAS REDONDAS DE LAS JORNADAS DE INGENIERÍA EN COMPUTACIÓN
En esta semana se realizaron Jornadas de Ing. en computación asistí a una mesa redonda titulada “ Tecnología del Lenguaje” en donde estaban como panelistas Carlos Francisco Fonseca Rojas, Ariadna Yoselin Sánchez Aragón, Carlos Francisco Méndez Cruz, Amaranto Dávila Jáuregui, Adolfo Hernández Huerta, Dr. Gerardo Sierra Martínez y Luis Alberto Bárron Cedeño y como responsable el Ing. Juan José Carreón Granados donde nos hablaban que hay un grupo de Lingüistas en la torre de ingeniería que se dedican a investigar métodos más fáciles de entendimiento de las diferentes lenguas que existen en México y el mundo pero todo esto con programas de computadora en donde la computadora habla o intenta hacer una voz muy parecida a la de los humanos pero en diferentes lenguas. El ultimo proyecto es uno que esta realizando un investigador de Lenguas antiguas para su tesis en donde quiere hacer un programa para que la computadora traduzca y hable igual a la forma de hablar que utilizaban los que vivían en el siglo XVI y compararlos con la forma de hablar de los de ahora.
Otro fue pasar libros antiguos a una forma electrónica y con animación como si se estuviera leyendo un libro de verdad, esto fue de lo que hablaron en la mesa redonda que de hecho fue la primera y no funciono el proyector solo hasta al final consiguieron uno aparte.
A las conferencias que asistí fueron la de Innovación Tecnológica de Microsoft donde estuvo como ponente el Ing. Ricardo Medina Alarcón Gerente de Desarrollo Académico de Microsoft, el se dedicaba a dar ayuda de Tecnología a diferentes escuelas de México y a promover los desarrollos tecnológicos de Microsoft como en este caso fueron algunos productos que tiene contemplados tanto de Software como de Hardware, en esta conferencia nos mostró todo este desarrollo por medio de videos muy entretenidos por cierto, ya que mostraron una computadora pequeña que tiene las mismas funciones que una laptop pero no es tan estorbosa ni pesada como estas, otro video fue de cómo seria la vida en un supermercado si todo se manejara por medio de tecnología, y también como seria en un banco con alta tecnología, además nos dio una pequeña muestra de Windows vista y de que tenia un poco de inteligencia artificial como para identificar donde se encuentra un cuerpo sólido mostrandonos esto con un video.
El que mas se introdujo en este tema del Windows Vista fue el Ing. Alejandro Martínez Licenciado en sistemas computacionales por la UNIDES (Departamento de Desarrollo Académico de Microsoft) que nos mostró nuevas funciones e innovaciones de este Sistema Operativo, una de las muchas ventajas es que es fácil y entendible para las personas que se inician en la computación y sus gráficos son mejores. Nos mostró un programa que tiene para fotografía digital y que me pareció interesante ya que hacia trabajos muy buenos de fotomontaje y de mejoramiento de fotografías, otra función que mostró fue la de comunicarse con la computadora por medio de la voz y la maquina hacia todo lo que se le indicaba, también nos dio los requerimientos mínimos para instalar el Windows Vista y que funcione eficientemente estos eran: 512 de Ram y un disco duro grande ya que este sistema operativo ocupa 20G.
Al final de esta conferencia se regalo un Xbox 360 que se rifo entre todos los que estaban en el auditorio.
Otra conferencia a la que asistí fue la de Prevención y mitigación de ataque de red por el Ing. Germán Antonio Gonzáles en donde nos hablo de los que en algunos tiempos fueron muy peligrosos en el mundo y la velocidad con la que se reproducían, entre otras cosas que nos ayudarán a evitarlos de ahora en adelante.
En esta semana se realizaron Jornadas de Ing. en computación asistí a una mesa redonda titulada “ Tecnología del Lenguaje” en donde estaban como panelistas Carlos Francisco Fonseca Rojas, Ariadna Yoselin Sánchez Aragón, Carlos Francisco Méndez Cruz, Amaranto Dávila Jáuregui, Adolfo Hernández Huerta, Dr. Gerardo Sierra Martínez y Luis Alberto Bárron Cedeño y como responsable el Ing. Juan José Carreón Granados donde nos hablaban que hay un grupo de Lingüistas en la torre de ingeniería que se dedican a investigar métodos más fáciles de entendimiento de las diferentes lenguas que existen en México y el mundo pero todo esto con programas de computadora en donde la computadora habla o intenta hacer una voz muy parecida a la de los humanos pero en diferentes lenguas. El ultimo proyecto es uno que esta realizando un investigador de Lenguas antiguas para su tesis en donde quiere hacer un programa para que la computadora traduzca y hable igual a la forma de hablar que utilizaban los que vivían en el siglo XVI y compararlos con la forma de hablar de los de ahora.
Otro fue pasar libros antiguos a una forma electrónica y con animación como si se estuviera leyendo un libro de verdad, esto fue de lo que hablaron en la mesa redonda que de hecho fue la primera y no funciono el proyector solo hasta al final consiguieron uno aparte.
A las conferencias que asistí fueron la de Innovación Tecnológica de Microsoft donde estuvo como ponente el Ing. Ricardo Medina Alarcón Gerente de Desarrollo Académico de Microsoft, el se dedicaba a dar ayuda de Tecnología a diferentes escuelas de México y a promover los desarrollos tecnológicos de Microsoft como en este caso fueron algunos productos que tiene contemplados tanto de Software como de Hardware, en esta conferencia nos mostró todo este desarrollo por medio de videos muy entretenidos por cierto, ya que mostraron una computadora pequeña que tiene las mismas funciones que una laptop pero no es tan estorbosa ni pesada como estas, otro video fue de cómo seria la vida en un supermercado si todo se manejara por medio de tecnología, y también como seria en un banco con alta tecnología, además nos dio una pequeña muestra de Windows vista y de que tenia un poco de inteligencia artificial como para identificar donde se encuentra un cuerpo sólido mostrandonos esto con un video.
El que mas se introdujo en este tema del Windows Vista fue el Ing. Alejandro Martínez Licenciado en sistemas computacionales por la UNIDES (Departamento de Desarrollo Académico de Microsoft) que nos mostró nuevas funciones e innovaciones de este Sistema Operativo, una de las muchas ventajas es que es fácil y entendible para las personas que se inician en la computación y sus gráficos son mejores. Nos mostró un programa que tiene para fotografía digital y que me pareció interesante ya que hacia trabajos muy buenos de fotomontaje y de mejoramiento de fotografías, otra función que mostró fue la de comunicarse con la computadora por medio de la voz y la maquina hacia todo lo que se le indicaba, también nos dio los requerimientos mínimos para instalar el Windows Vista y que funcione eficientemente estos eran: 512 de Ram y un disco duro grande ya que este sistema operativo ocupa 20G.
Al final de esta conferencia se regalo un Xbox 360 que se rifo entre todos los que estaban en el auditorio.
Otra conferencia a la que asistí fue la de Prevención y mitigación de ataque de red por el Ing. Germán Antonio Gonzáles en donde nos hablo de los que en algunos tiempos fueron muy peligrosos en el mundo y la velocidad con la que se reproducían, entre otras cosas que nos ayudarán a evitarlos de ahora en adelante.
miércoles, 28 de febrero de 2007
CICLOS DE VIDA DEL SOFTWARE
Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.
ELEMENTOS DEL CICLO DE VIDA
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
Esquema general de operación de una fase
Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
TIPOS DE MODELO DE CICLO DE VIDA
Las principales diferencias entre distintos modelos de ciclo de vida están en:
El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle:
Ciclo de vida lineal
Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
Ejemplo de ciclo lineal para un proyecto de construcción
Ciclo de vida con prototipado
A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
Ciclo de vida en espiral
El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos).
En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
Estudio de viabilidad.
Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
Asegurar que los requisitos son alcanzables.
Formalizar el acuerdo con los usuarios.
Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
Identificar soluciones tecnológicas para cada una de las funciones del sistema.
Asignar recursos materiales para cada una de las funciones.
Proponer (identificar y seleccionar) subcontratas.
Establecer métodos de validación del diseño.
Ajustar las especificaciones del producto.
Fase de construcción
Generar el producto o servicio pretendido con el proyecto.
Integrar los elementos subcontratados o adquiridos externamente.
Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
Operación: asegurar que el uso del proyecto es el pretendido.
Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste):
LOS PROYECTOS DE I+D
En el caso de la investigación básica el resultado esperado son conocimientos científicos. No existe ninguna fase de construcción y sí fases que recojan las tareas de experimentación.
En la investigación aplicada el resultado esperado suele ser alguna tecnología aplicable para procesos o para productos. Dependiendo del grado de cercanía a la aplicación que llegue a alcanzarse el modelo puede ser básicamente como el anterior o incluir una fase de aplicación piloto.
En el desarrollo de productos o procesos nuevos o significativamente modificados sí aparece ya una fase de construcción, aunque normalmente se tratará de la realización de un prototipo. Normalmente el cliente no será el usuario final, sino los departamentos de ingeniería de producción de la propia empresa o de otra que contrata el desarrollo.
La I+D es costosa por depender de personal muy cualificado, por realizarse de modo generalmente artesanal y por requerir bucles de realimentación que multiplican, para hacer frente a incidencias, la duración del proyecto.
CICLO DE VIDA EN INTERNET
Con Internet de por medio, todo se transforma en algo más rápido. Internet ha conseguido en 5 o 6 años lo que televisión o teléfono han tardado décadas.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.
ELEMENTOS DEL CICLO DE VIDA
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
Esquema general de operación de una fase
Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
TIPOS DE MODELO DE CICLO DE VIDA
Las principales diferencias entre distintos modelos de ciclo de vida están en:
El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle:
Ciclo de vida lineal
Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
Ejemplo de ciclo lineal para un proyecto de construcción
Ciclo de vida con prototipado
A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
Ciclo de vida en espiral
El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos).
En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
Estudio de viabilidad.
Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
Asegurar que los requisitos son alcanzables.
Formalizar el acuerdo con los usuarios.
Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
Identificar soluciones tecnológicas para cada una de las funciones del sistema.
Asignar recursos materiales para cada una de las funciones.
Proponer (identificar y seleccionar) subcontratas.
Establecer métodos de validación del diseño.
Ajustar las especificaciones del producto.
Fase de construcción
Generar el producto o servicio pretendido con el proyecto.
Integrar los elementos subcontratados o adquiridos externamente.
Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
Operación: asegurar que el uso del proyecto es el pretendido.
Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste):
LOS PROYECTOS DE I+D
En el caso de la investigación básica el resultado esperado son conocimientos científicos. No existe ninguna fase de construcción y sí fases que recojan las tareas de experimentación.
En la investigación aplicada el resultado esperado suele ser alguna tecnología aplicable para procesos o para productos. Dependiendo del grado de cercanía a la aplicación que llegue a alcanzarse el modelo puede ser básicamente como el anterior o incluir una fase de aplicación piloto.
En el desarrollo de productos o procesos nuevos o significativamente modificados sí aparece ya una fase de construcción, aunque normalmente se tratará de la realización de un prototipo. Normalmente el cliente no será el usuario final, sino los departamentos de ingeniería de producción de la propia empresa o de otra que contrata el desarrollo.
La I+D es costosa por depender de personal muy cualificado, por realizarse de modo generalmente artesanal y por requerir bucles de realimentación que multiplican, para hacer frente a incidencias, la duración del proyecto.
CICLO DE VIDA EN INTERNET
Con Internet de por medio, todo se transforma en algo más rápido. Internet ha conseguido en 5 o 6 años lo que televisión o teléfono han tardado décadas.
UML
¿Qué es UML?
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos 'business'.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboración para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.
UML ofrece notación y semántica estándar
UML preescribe una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semáticas y notaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.
Diagramas
La explicación se basará en los diagramas, en lugar de en vistas o anotación, ya que son estos la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:
- Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
- Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
- Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
- Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
- Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.
Se Dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica. Los diagramas estaticos son:
- Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
- Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
- Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
- Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
- Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.
Lo diagramas dinámicos son:
- Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
- Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
- Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dará una breve explicación de todos, ampliándose para los más necesarios
Diagramas recomendados.
Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectuan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deberán adaptar a las características de cada desarrollo, y seguramente será la practica lo que nos diga las cosas que echamos en falta o los diagramas que parecen ser menos necesarios.
- Aplicación monopuesto:
- Diagrama de casos de uso.
- Diagrama de clases.
- Diagrama de interacción.
- Aplicación monopuesto, con entrada de eventos:
- Añadir: Diagrama de estados.
- Aplicación cliente servidor:
- Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
- Aplicación compleja distribuida:
- Todos.
Así tenemos que para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. ¿Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realización de los diagramas es proporcional al tamaño del producto a realizar, no entraremos en la discusión de que el tiempo de diseño no es tiempo perdido si no ganado. Para la mayoría de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores. Así que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a pequeño.
Diagrama de casos de uso.
Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.
En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:
- Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso. Sus relaciones son:
- Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.
- Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.
- Generalization: Es la típica relación de herencia.
- Actores: se representan por un muñeco. Sus relaciones son:
- Communicates: Comunica un actor con un caso de uso, o con otro actor.
- Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.
En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especialización de Crear productos.
Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un sistema, y para modelar los requisitos del sistema.
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos 'business'.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboración para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.
UML ofrece notación y semántica estándar
UML preescribe una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semáticas y notaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.
Diagramas
La explicación se basará en los diagramas, en lugar de en vistas o anotación, ya que son estos la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:
- Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
- Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
- Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
- Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
- Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.
Se Dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica. Los diagramas estaticos son:
- Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
- Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
- Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
- Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
- Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.
Lo diagramas dinámicos son:
- Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
- Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
- Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dará una breve explicación de todos, ampliándose para los más necesarios
Diagramas recomendados.
Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectuan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deberán adaptar a las características de cada desarrollo, y seguramente será la practica lo que nos diga las cosas que echamos en falta o los diagramas que parecen ser menos necesarios.
- Aplicación monopuesto:
- Diagrama de casos de uso.
- Diagrama de clases.
- Diagrama de interacción.
- Aplicación monopuesto, con entrada de eventos:
- Añadir: Diagrama de estados.
- Aplicación cliente servidor:
- Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
- Aplicación compleja distribuida:
- Todos.
Así tenemos que para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. ¿Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realización de los diagramas es proporcional al tamaño del producto a realizar, no entraremos en la discusión de que el tiempo de diseño no es tiempo perdido si no ganado. Para la mayoría de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores. Así que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a pequeño.
Diagrama de casos de uso.
Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.
En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:
- Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso. Sus relaciones son:
- Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.
- Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.
- Generalization: Es la típica relación de herencia.
- Actores: se representan por un muñeco. Sus relaciones son:
- Communicates: Comunica un actor con un caso de uso, o con otro actor.
- Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.
En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especialización de Crear productos.
Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un sistema, y para modelar los requisitos del sistema.
domingo, 18 de febrero de 2007
La Crisis del Software (tarea 2)
LA CRISIS DEL SOFTWARE
La rápida expansión de la Informática ha llevado a la escritura de millones de líneas de código antes de que se empezaran a plantear de manera seria metodologías para el diseño y la construcción del software, así como técnicas para resolver los problemas de mantenimiento, fiabilidad, etc. Esta expansión sin control tuvo como consecuencia lógica la llamada Crisis del Software. El punto básico de esta crisis es que el software es mucho más difícil de construir de lo que nos indica nuestra intuición. Los síntomas que hicieron palpable la aparición de la crisis son los siguientes:
Expectativas: A menudo los sistemas no responden a las expectativas que de ellos tienen los usuarios.
Costo: Los costos del software son muy difíciles de prever, y a menudo son muy superiores a lo esperado.
Facilidad de modificación: La modificación de software es una tarea compleja, costosa y propensa a errores.
Plazos: El software se suele entregar tarde y con menos prestaciones de las ofertadas.
Portabilidad: Es difícil cambiar un programa de su entorno hardware, incluso cuando las tareas a realizar son las mismas.
Eficiencia: Los esfuerzos que se hacen para el desarrollo de software no suelen hacer un aprovechamiento óptimo de los recursos accesibles.
Fiabilidad: Los programas fallan demasiado a menudo.
El primer reconocimiento público de la existencia de esta crisis tuvo lugar en una conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN que convocó a un grupo de unos cincuenta expertos. El objetivo de esta conferencia era trazar el rumbo que permitiera salir de la Crisis del Software. En otras palabras hacer de la construcción de software una ingeniería; en palabras de Bauer "establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente", surgiendo así una nueva disciplina: la Ingeniería del Software (IS).La IS tiene tres elementos fundamentales:
Técnicas a emplear en la construcción del software. Entre ellas se encuentran técnicas a emplear durante la planificación de proyectos, análisis de requisitos, diseño de software, diseño de estructuras de datos, validación de sistemas software, mantenimiento, etc.
Herramientas que dan soporte al desarrollo de software.
Procesos y metodologías, nexo de unión entre las técnicas y las herramientas que definen la secuencia en que se aplican las técnicas, las entregas que se requieren, los controles necesarios para asegurar la calidad, la coordinación de cambios, etc.
PERFIL DEL INGENIERO
¿Qué hace un Ingeniero del Software en su trabajo?Trabaja preferentemente en equipo para desarrollar un proyecto.Los proyectos consisten en la construcción (análisis de la situación actual, análisis del problema, propuesta de solución automatizada, estudio de viabilidad, diseño, implementación, validación, mantenimiento) de Sistemas de Software y la gestión de dichos proyectos; siguiendo metodologías, métodos técnicas y herramientas de Ingeniería del Software.El trabajo que el IS realiza dentro del grupo es:
Planificación, Gestión y Control del Proyecto.
Control de la Calidad del proceso y de sus productos.
Interacción con los directivos, resolutores y usuarios.
Análisis de la situación, Análisis del problema, Análisis de la viabilidad.
Análisis de Requisitos y establecimiento de Especificaciones.
Obtención de información, Modelización del sistema existente y Propuesta de solución automatizada. Diseño del sistema software.
Supervisa la implementación.
Diseña el Proceso de Evaluación y supervisa las pruebas.
Controla el Mantenimiento y la Gestión de Configuraciones.
Controla, supervisa y realiza partes de la documentación del proyecto, de trabajo internos, para los clientes y manual de usuario.
Planificación y control de versiones sucesivas del sistema.
Planifica y controla la Transferencia de tecnología.
Integración con otros sistemas software o físicos.
Los alumnos deben alcanzar las siguientes capacidades:A.- Cualificaciones claves de Ingeniería del Software. Estas cualificaciones son la prioridad máxima del curso. En concreto, se desea que el alumno sea capaz de:
Conocer y utilizar una metodología de trabajo para la construcción de sistemas software.
Conocer y utilizar las técnicas y herramientas para la planificación y gestión de proyectos.
Conocer y utilizar las técnicas de Análisis.
Conocer y utilizar las técnicas de especificación de requisitos.
Desarrollo de un modelo conceptual del sistema existente.
Conocer y utilizar las técnicas de diseño de software.
Saber llevar a cabo la Evaluación de un sistema software.
Ser capaz de llevar a cabo el mantenimiento de un sistema software.
B.- Cualificaciones técnicas. Además de las cualificaciones clave de un IS, es necesario que los alumnos conozcan una serie de técnicas y herramientas concretas:
Utilizar una herramienta de construcción CASE.
Tener conocimiento de los lenguajes de programación existentes y su adecuación para la construcción de los distintos sistemas.
Tener conocimiento de la programación orientada a objetos.
El patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que se oponen y cuestionan las tesis anteriores, y dan como resultado nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.
Los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software. Que la agilidad es su antítesis, y que estamos generando en estos años la síntesis; un resultado enriquecido de ambos, depurado y con mayor valor de conocimiento.
LA CRISIS DEL SOFTWARE EN LA ACTUALIDAD
Para los desarrolladores de software estadounidenses, el tema de considerar el liderazgo que han, o habían, mantenido a lo largo de incontables décadas ha comenzado a formar una fuerza dominante.Frente a un contexto de cambio cada vez más acelerado, dichos programadores en particular los de mayor edad encuentran que tendrán ser cada vez más creativos si desean mantenerse en la parte superior de la cadena de valor, principalmente a través de soluciones a nivel individual, como opciones más viables. Soluciones con base en tecnologías o empresas específicas, p ej, en Java o MS, son consideradas como entre las menos viables en el largo plazo; frente a desafíos como los de que cada vez más desarrolladores extranjeros escriben buenos programas y a un precio menor; situación cuantificada con precisión mediante recursos como el de los cinco niveles del Capability Maturity Model, CMM, los cuales miden el grado de complejidad alcanzado por las organizaciones de desarrollo de software, mediante establecer cada uno de dichos niveles metasespecíficas, cada una mejor que la anterior. El nivel 1 del CMM mide sólo los esfuerzos heroicos, es un nivel en el que no existen reglas; en el nivel 2 se incorpora la administración básica de proyectos, la cual puede diferir de entre otros similares; el 3, el desarrollo en una organización sigue las mismas reglas; el 4, se administra con base en medidas precisas del control efectivo dedesarrollo; y, finalmente en el 5 existe retroalimentación cuantitativa de proyectos anteriores para mejorar la siguiente generación de proyectos. En desarrolladores estadounidenses hay fuerte preocupación por hechos como el de que únicamente contaban ya en 2002 con tan sólo 41% de las organizaciones desarrolladoras de software a nivel mundial en el nivel4; peor aún, con el 17% de las de nivel 5, consúltese al respecto la reveladora presentación del consultor estadounidense Dave Thomas, How to Keep Your Job. El desafío que representan dichos porcentajes para Estados Unidos, afirma Thomas, es similar al que significó en los 80 el fracaso de IBM en reconocer qué tan importante serían finalmente la PC y el hardware de consumo, así como que dicho mercado había dejado de pertenecerle. Para dicho consultor, las soluciones estadounidenses a nivel gubernamental o empresarial no pueden afrontar tal desafío; únicamente las locales a nivel individual a través de la renovación y la actualización del saber individual podrían afrontarlo, provocando pautas similares a las seguidas por acertados inversores financieros individuales: tener un plan para enfrentar situaciones riesgosassumamente cambiantes, diversificar inversiones, identificar el valor generado por cada una de éstas, actuar frente a dichas situaciones en lugar de sólo padecerlas mediante actuar de forma continua en el largo plazo para enfrentarlas. Pues a nivel individual siguen existiendo formas de controlar, de responsabilizarse y de aprovecharoportunidades. Si para los estadounidenses, problemas como los mencionados serían efecto en última instancia de la arrogancia, en el caso de los latinoamericanos, estarían definidos por un sentimiento de una autoestima demasiado baja: "estamos tan mal y somos tan incapaces que es imposible competir", no obstante que ejemplos como el de India y China, y el propio estadounidense, muestran opciones diferentes.
La rápida expansión de la Informática ha llevado a la escritura de millones de líneas de código antes de que se empezaran a plantear de manera seria metodologías para el diseño y la construcción del software, así como técnicas para resolver los problemas de mantenimiento, fiabilidad, etc. Esta expansión sin control tuvo como consecuencia lógica la llamada Crisis del Software. El punto básico de esta crisis es que el software es mucho más difícil de construir de lo que nos indica nuestra intuición. Los síntomas que hicieron palpable la aparición de la crisis son los siguientes:
Expectativas: A menudo los sistemas no responden a las expectativas que de ellos tienen los usuarios.
Costo: Los costos del software son muy difíciles de prever, y a menudo son muy superiores a lo esperado.
Facilidad de modificación: La modificación de software es una tarea compleja, costosa y propensa a errores.
Plazos: El software se suele entregar tarde y con menos prestaciones de las ofertadas.
Portabilidad: Es difícil cambiar un programa de su entorno hardware, incluso cuando las tareas a realizar son las mismas.
Eficiencia: Los esfuerzos que se hacen para el desarrollo de software no suelen hacer un aprovechamiento óptimo de los recursos accesibles.
Fiabilidad: Los programas fallan demasiado a menudo.
El primer reconocimiento público de la existencia de esta crisis tuvo lugar en una conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN que convocó a un grupo de unos cincuenta expertos. El objetivo de esta conferencia era trazar el rumbo que permitiera salir de la Crisis del Software. En otras palabras hacer de la construcción de software una ingeniería; en palabras de Bauer "establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente", surgiendo así una nueva disciplina: la Ingeniería del Software (IS).La IS tiene tres elementos fundamentales:
Técnicas a emplear en la construcción del software. Entre ellas se encuentran técnicas a emplear durante la planificación de proyectos, análisis de requisitos, diseño de software, diseño de estructuras de datos, validación de sistemas software, mantenimiento, etc.
Herramientas que dan soporte al desarrollo de software.
Procesos y metodologías, nexo de unión entre las técnicas y las herramientas que definen la secuencia en que se aplican las técnicas, las entregas que se requieren, los controles necesarios para asegurar la calidad, la coordinación de cambios, etc.
PERFIL DEL INGENIERO
¿Qué hace un Ingeniero del Software en su trabajo?Trabaja preferentemente en equipo para desarrollar un proyecto.Los proyectos consisten en la construcción (análisis de la situación actual, análisis del problema, propuesta de solución automatizada, estudio de viabilidad, diseño, implementación, validación, mantenimiento) de Sistemas de Software y la gestión de dichos proyectos; siguiendo metodologías, métodos técnicas y herramientas de Ingeniería del Software.El trabajo que el IS realiza dentro del grupo es:
Planificación, Gestión y Control del Proyecto.
Control de la Calidad del proceso y de sus productos.
Interacción con los directivos, resolutores y usuarios.
Análisis de la situación, Análisis del problema, Análisis de la viabilidad.
Análisis de Requisitos y establecimiento de Especificaciones.
Obtención de información, Modelización del sistema existente y Propuesta de solución automatizada. Diseño del sistema software.
Supervisa la implementación.
Diseña el Proceso de Evaluación y supervisa las pruebas.
Controla el Mantenimiento y la Gestión de Configuraciones.
Controla, supervisa y realiza partes de la documentación del proyecto, de trabajo internos, para los clientes y manual de usuario.
Planificación y control de versiones sucesivas del sistema.
Planifica y controla la Transferencia de tecnología.
Integración con otros sistemas software o físicos.
Los alumnos deben alcanzar las siguientes capacidades:A.- Cualificaciones claves de Ingeniería del Software. Estas cualificaciones son la prioridad máxima del curso. En concreto, se desea que el alumno sea capaz de:
Conocer y utilizar una metodología de trabajo para la construcción de sistemas software.
Conocer y utilizar las técnicas y herramientas para la planificación y gestión de proyectos.
Conocer y utilizar las técnicas de Análisis.
Conocer y utilizar las técnicas de especificación de requisitos.
Desarrollo de un modelo conceptual del sistema existente.
Conocer y utilizar las técnicas de diseño de software.
Saber llevar a cabo la Evaluación de un sistema software.
Ser capaz de llevar a cabo el mantenimiento de un sistema software.
B.- Cualificaciones técnicas. Además de las cualificaciones clave de un IS, es necesario que los alumnos conozcan una serie de técnicas y herramientas concretas:
Utilizar una herramienta de construcción CASE.
Tener conocimiento de los lenguajes de programación existentes y su adecuación para la construcción de los distintos sistemas.
Tener conocimiento de la programación orientada a objetos.
El patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que se oponen y cuestionan las tesis anteriores, y dan como resultado nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.
Los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software. Que la agilidad es su antítesis, y que estamos generando en estos años la síntesis; un resultado enriquecido de ambos, depurado y con mayor valor de conocimiento.
LA CRISIS DEL SOFTWARE EN LA ACTUALIDAD
Para los desarrolladores de software estadounidenses, el tema de considerar el liderazgo que han, o habían, mantenido a lo largo de incontables décadas ha comenzado a formar una fuerza dominante.Frente a un contexto de cambio cada vez más acelerado, dichos programadores en particular los de mayor edad encuentran que tendrán ser cada vez más creativos si desean mantenerse en la parte superior de la cadena de valor, principalmente a través de soluciones a nivel individual, como opciones más viables. Soluciones con base en tecnologías o empresas específicas, p ej, en Java o MS, son consideradas como entre las menos viables en el largo plazo; frente a desafíos como los de que cada vez más desarrolladores extranjeros escriben buenos programas y a un precio menor; situación cuantificada con precisión mediante recursos como el de los cinco niveles del Capability Maturity Model, CMM, los cuales miden el grado de complejidad alcanzado por las organizaciones de desarrollo de software, mediante establecer cada uno de dichos niveles metasespecíficas, cada una mejor que la anterior. El nivel 1 del CMM mide sólo los esfuerzos heroicos, es un nivel en el que no existen reglas; en el nivel 2 se incorpora la administración básica de proyectos, la cual puede diferir de entre otros similares; el 3, el desarrollo en una organización sigue las mismas reglas; el 4, se administra con base en medidas precisas del control efectivo dedesarrollo; y, finalmente en el 5 existe retroalimentación cuantitativa de proyectos anteriores para mejorar la siguiente generación de proyectos. En desarrolladores estadounidenses hay fuerte preocupación por hechos como el de que únicamente contaban ya en 2002 con tan sólo 41% de las organizaciones desarrolladoras de software a nivel mundial en el nivel4; peor aún, con el 17% de las de nivel 5, consúltese al respecto la reveladora presentación del consultor estadounidense Dave Thomas, How to Keep Your Job. El desafío que representan dichos porcentajes para Estados Unidos, afirma Thomas, es similar al que significó en los 80 el fracaso de IBM en reconocer qué tan importante serían finalmente la PC y el hardware de consumo, así como que dicho mercado había dejado de pertenecerle. Para dicho consultor, las soluciones estadounidenses a nivel gubernamental o empresarial no pueden afrontar tal desafío; únicamente las locales a nivel individual a través de la renovación y la actualización del saber individual podrían afrontarlo, provocando pautas similares a las seguidas por acertados inversores financieros individuales: tener un plan para enfrentar situaciones riesgosassumamente cambiantes, diversificar inversiones, identificar el valor generado por cada una de éstas, actuar frente a dichas situaciones en lugar de sólo padecerlas mediante actuar de forma continua en el largo plazo para enfrentarlas. Pues a nivel individual siguen existiendo formas de controlar, de responsabilizarse y de aprovecharoportunidades. Si para los estadounidenses, problemas como los mencionados serían efecto en última instancia de la arrogancia, en el caso de los latinoamericanos, estarían definidos por un sentimiento de una autoestima demasiado baja: "estamos tan mal y somos tan incapaces que es imposible competir", no obstante que ejemplos como el de India y China, y el propio estadounidense, muestran opciones diferentes.
Suscribirse a:
Entradas (Atom)