{"id":107,"date":"2013-03-13T13:42:55","date_gmt":"2013-03-13T13:42:55","guid":{"rendered":"http:\/\/multimedia.uoc.edu\/blogs\/fem\/?p=107"},"modified":"2013-03-27T14:57:15","modified_gmt":"2013-03-27T14:57:15","slug":"desarrollo-multimedia-bases-conceptuales-fases-y-modelos","status":"publish","type":"post","link":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/desarrollo-multimedia-bases-conceptuales-fases-y-modelos\/","title":{"rendered":"Desarrollo multimedia: bases conceptuales, fases y modelos"},"content":{"rendered":"<p>Aunque hay cierta confusi\u00f3n y debate acerca de qu\u00e9 engloba y qu\u00e9 no un desarrollo multimedia, es posible afirmar con seguridad que incluye la generaci\u00f3n de productos y contenidos, en especial en los nuevos medios e Internet como entornos nativos; asimismo, es patente la necesidad tanto de planificaci\u00f3n como de un modelo com\u00fan de trabajo y terminolog\u00eda, que son necesarios tanto para el arranque como para la consecuci\u00f3n de las metas fijadas en un proyecto multimedia.<\/p>\n<p>En el presente art\u00edculo, se ofrece informaci\u00f3n b\u00e1sica ampliamente consensuada por la industria acerca del significado y las caracter\u00edsticas de los desarrollos multimedia con el fin de facilitar la comprensi\u00f3n de conceptos, modelos y estrategias clave a aquellos que comienzan su carrera en el universo multimedia, tan prometedor y apasionante como complejo.<\/p>\n<h5>\u00bfQu\u00e9 es un desarrollo multimedia?<\/h5>\n<p>Un desarrollo multimedia es el n\u00facleo de trabajo de todo proyecto multimedia y trabaja los aspectos clave para la creaci\u00f3n de un producto o servicio completo, que cumpla de manera eficaz y eficiente los objetivos fijados y responda con la mayor calidad posible a todas las \u00e1reas y principios de las disciplinas que se han aplicado para crearlo, desde la programaci\u00f3n hasta el dise\u00f1o de interfaces.<\/p>\n<p>Si nos ce\u00f1imos a las definiciones m\u00e1s extendidas y estrictas en la industria del software y los nuevos medios, un desarrollo multimedia es una parte del proceso de producci\u00f3n de un producto o servicio multimedia que est\u00e1 centrada en la construcci\u00f3n del producto en s\u00ed, independientemente de otras \u00e1reas como presupuesto, marketing o gesti\u00f3n de equipos.<\/p>\n<p>En definitiva, lo que en realidad importa en ese asunto es distinguir sem\u00e1nticamente y con claridad los conceptos clave del vocabulario del proyecto, en especial en la comunicaci\u00f3n con otras personas implicadas en el proyecto y en la documentaci\u00f3n del mismo, sea cual sea la terminolog\u00eda que se prefiera utilizar.<\/p>\n<p>Un desarrollo multimedia se puede abordar de muchas maneras, ya sean lineales o no lineales. Antes de arrancar el proceso de desarrollo, es clave conocer los m\u00e9todos y estrategias disponibles para seleccionar y aplicar los m\u00e1s adecuados al proyecto.<\/p>\n<h5>Similitudes con otros procesos de desarrollo<\/h5>\n<p>Hay que tener en cuenta que, al tratarse de una disciplina joven, heredera en cierto modo de muchos aspectos de otros \u00e1mbitos, como los viejos medios o la ingenier\u00eda industrial, tiene una gran influencia de los m\u00e9todos utilizados en dichos \u00e1mbitos, y estos se pueden extrapolar a veces de manera muy directa a las necesidades del proyecto multimedia.<\/p>\n<p>En especial, hay una relaci\u00f3n estrecha entre el proceso de desarrollo multimedia y la producci\u00f3n de contenidos audiovisuales y los proyectos de desarrollo de ingenier\u00eda de software, tanto en la creaci\u00f3n de elementos como en su ensamblaje. De hecho, ambas aproximaciones son necesarias por ser complementarias a las necesidades de un proyecto multimedia. Los ciclos y modelos de desarrollo de software no ofrecen gu\u00edas o modelos normalizados en los aspectos puramente creativos del desarrollo multimedia, pero proveen de una s\u00f3lida definici\u00f3n de estrategias y pautas de trabajo, como la definici\u00f3n de requisitos o el testeo de los productos, sobre las que los m\u00e9todos creativos y audiovisuales pueden acomodarse.<\/p>\n<h5>Fases de desarrollo<\/h5>\n<p>El proceso de desarrollo de un proyecto multimedia se puede estructurar en m\u00faltiples fases. A continuaci\u00f3n se listan las m\u00e1s habituales, aunque pueden variar de proyecto a proyecto por la diversa naturaleza que pueden llegar a tener:<\/p>\n<ul>\n<li>An\u00e1lisis: definici\u00f3n de los objetivos y requisitos base del proyecto.<\/li>\n<li>Planificaci\u00f3n: identificar necesidades y problem\u00e1ticas clave para el desarrollo, as\u00ed como establecer un plan estrat\u00e9gico de trabajo.<\/li>\n<li>Implementaci\u00f3n\/desarrollo\/creaci\u00f3n\/producci\u00f3n: generaci\u00f3n y ensamblaje de componentes necesarios. A veces, tambi\u00e9n se puede utilizar el t\u00e9rmino <i>implementaci\u00f3n<\/i> para definir una posible fase, en la que el producto se instala en otra infraestructura una vez terminado o pr\u00f3ximo a estarlo (en ingl\u00e9s tambi\u00e9n se usa para dicha fase el t\u00e9rmino <i>deployment<\/i>, despliegue).<\/li>\n<li>Testeo: validaci\u00f3n del trabajo llevado a cabo y correcci\u00f3n de errores y problemas.<\/li>\n<li>Documentaci\u00f3n: mantenimiento de un registro del proceso de desarrollo, creaci\u00f3n de gu\u00edas de usuario, libros de estilo, entre otros.<\/li>\n<li>Mantenimiento: correcci\u00f3n de errores una vez que se ha lanzado el producto\/servicio. Lo habitual es preparar herramientas y protocolos de control y gesti\u00f3n, as\u00ed como pasar en adelante el resto de las tareas a otro personal, ya sea bajo las \u00f3rdenes del <i>product manager<\/i> del proyecto o de terceros.<\/li>\n<\/ul>\n<p>Es muy importante tener en cuenta que la lista anterior se debe tomar con extrema precauci\u00f3n, tanto porque las fases pueden variar mucho de un modelo de trabajo a otro, como porque los desarrollos multimedia no suelen ser procesos estrictamente lineales, donde cabe concluir una fase para poder avanzar hacia la siguiente.<\/p>\n<h5>Modelos de desarrollo<\/h5>\n<p>Aunque las fases de desarrollo pueden variar, en especial a grandes rasgos, los modelos de trabajo posibles son claros y expl\u00edcitos, y responden a m\u00faltiples escenarios y caracter\u00edsticas de los proyectos, lo que permite la hibridaci\u00f3n entre ellos para alcanzar una gesti\u00f3n \u00f3ptima del proyecto. Hay una gran variedad, por lo que en este art\u00edculo se indican los m\u00e9todos de uso m\u00e1s extendido y con mayor afinidad con los desarrollos multimedia.<\/p>\n<h6>Cascada (<i>waterfall<\/i>)<\/h6>\n<p>El equipo debe seguir en estricto orden las fases de an\u00e1lisis de requisitos, dise\u00f1o, implementaci\u00f3n, validaci\u00f3n, instalaci\u00f3n y mantenimiento. Solo es recomendable en proyectos muy estructurados y lineales, pues su rigidez dificulta los procesos de revisi\u00f3n y mejora de fases ya concluidas.<\/p>\n<h6>Iterativo e incremental<\/h6>\n<p>En especial, es adecuado para desarrollos de gran complejidad. Durante el proceso, se producen a la vez m\u00faltiples iteraciones del ciclo de desarrollo, de manera evolutiva e incremental respecto a la creaci\u00f3n del producto. La relaci\u00f3n entre iteraciones e incrementos en la construcci\u00f3n del producto as\u00ed como su n\u00famero depende de la naturaleza del proyecto en cuesti\u00f3n.<\/p>\n<h6>Desarrollo r\u00e1pido de aplicaciones (<i>RAD<\/i>, del ingl\u00e9s <i>rapid application development<\/i>)<\/h6>\n<p>Minimiza la planificaci\u00f3n en favor del prototipado, por lo que tambi\u00e9n se conoce como de r\u00e1pido prototipado. El proceso de planificaci\u00f3n se entrelaza directamente y avanza en paralelo con el de desarrollo. El ahorro de tiempo en planificaci\u00f3n acelera el desarrollo y lo hace m\u00e1s f\u00e1cil de cambiar si se dan alteraciones en los requisitos y objetivos. Es recomendable para peque\u00f1os proyectos de alcance muy limitado, pruebas preliminares para evaluar la viabilidad de un proyecto o en las fases iniciales de un proyecto que despu\u00e9s ser\u00e1 migrado a otro modelo.<\/p>\n<h6>Espiral<\/h6>\n<p>Su filosof\u00eda es controlar y gestionar el riesgo en las diferentes fases de desarrollo. Combina aspectos de los modelos en cascada y el RAD. Es especialmente adecuado en proyectos complejos de gran envergadura. El desarrollo se visualiza como una espiral que pasa a trav\u00e9s de un n\u00famero de iteraciones (giros completos), sobre cuadrantes que representan la determinaci\u00f3n de objetivos, la identificaci\u00f3n y resoluci\u00f3n de riesgos, el desarrollo y testeado y la planificaci\u00f3n de la siguiente iteraci\u00f3n.<\/p>\n<h6>Agile<\/h6>\n<p>Se trata de uno de los m\u00e9todos m\u00e1s populares actualmente. Utiliza como base un desarrollo de tipo iterativo, pero con un enfoque m\u00e1s centrado en el personal implicado, que relega la planificaci\u00f3n a un segundo plano en favor del <i>feedback<\/i> como primer mecanismo de control. El <i>feedback<\/i> se gestiona mediante pruebas sobre versiones incrementales del producto\/servicio en desarrollo.<\/p>\n<p>Agile se ha utilizado como base para modelar m\u00faltiples variantes, tales como:<\/p>\n<ul>\n<li>Programaci\u00f3n extrema (<i>XP<\/i>): las fases se culminan en pasos extremadamente cortos en duraci\u00f3n o incluso continuos, y no necesariamente se completan, lo que hace avanzar el proceso de desarrollo de manera muy r\u00e1pida. Una de las primeras tareas es precisamente preparar tests automatizados para concretar los objetivos de desarrollo, y entonces es cuando se comienza a programar. La creaci\u00f3n de nuevos tests y fases de programaci\u00f3n es iterativa. La arquitectura suele llevarse a cabo con posterioridad como <i>refactoring<\/i>, y la ejecutan los mismos programadores. Solo en las fases finales se aborda el dise\u00f1o y se ensambla al c\u00f3digo. El resultado, incompleto pero ya funcional, se muestra a los usuarios y algunos miembros del equipo de desarrollo. Se reanuda el ciclo escribiendo m\u00e1s tests para la nueva parte clave del sistema que hay que desarrollar.<\/li>\n<li>Scrum: se centra en gestionar proyectos en los casos en los que es dif\u00edcil realizar planificaciones completas o a largo plazo. Utiliza mecanismos de control emp\u00edricos, como <i>loops<\/i> de <i>feedback<\/i>, como t\u00e9cnica central de gesti\u00f3n del proyecto. Su estrategia en planificaci\u00f3n y gesti\u00f3n es la toma de decisiones basadas en certezas y propiedades de funcionamiento, y en el \u00e1mbito de la operaci\u00f3n la unidad b\u00e1sica de trabajo es el <i>sprint<\/i>, una tarea acotada en el tiempo que arranca con una reuni\u00f3n para su planificaci\u00f3n y termina con otra de an\u00e1lisis en retrospectiva.<\/li>\n<li><i>DSDM<\/i> (<i>dynamic systems development method<\/i>): su objetivo clave es gestionar proyectos caracterizados por presupuestos y calendarios estrictos. El DSDM se centra en prevenir los errores m\u00e1s comunes en los proyectos (en especial aquellos de sistemas de informaci\u00f3n) tales como los anteriores, as\u00ed como en la falta de implicaci\u00f3n de los usuarios y el compromiso de la alta direcci\u00f3n de la organizaci\u00f3n.<\/li>\n<\/ul>\n<h6><i>Exploratory programming<\/i><\/h6>\n<p>Implementa una soluci\u00f3n inicial para definir las especificaciones y se va modificando hasta la satisfacci\u00f3n del cliente o hasta aclarar los datos y estructuras necesarios que modelar\u00e1n los requisitos para una futura implementaci\u00f3n. Es altamente iterativo, requiere un elevado nivel de programaci\u00f3n y se usa m\u00e1s en el desarrollo de videojuegos.<\/p>\n<h6><i>Code &amp; fix<\/i><\/h6>\n<p>Traducible literalmente como \u201cprograma y arregla\u201d, m\u00e1s que un m\u00e9todo es una t\u00e9cnica que se usa en casos de alta presi\u00f3n respecto a entregas por desarrolladores veteranos as\u00ed como por aquellos inexpertos en m\u00e9todos de desarrollo. Centr\u00e1ndose solamente en el c\u00f3digo, evitando el dise\u00f1o, el programador se dedica a producir el mayor c\u00f3digo posible de manera inmediata, tras lo cual se testea y se vuelve a programar para solventar los <i>bugs<\/i> encontrados, hasta que el producto o elemento del mismo se puede entregar. Este m\u00e9todo solo es recomendable para programadores extremadamente expertos en el \u00e1rea del proyecto en cuesti\u00f3n y los lenguajes utilizados, ya que los riesgos inherentes son muy elevados (por ejemplo, producir c\u00f3digo espagueti).<\/p>\n<h5>Estados de producto<\/h5>\n<p>Aunque los desarrollos multimedia no siempre llevan asociados la producci\u00f3n de software y servicios, es habitual usar su terminolog\u00eda de versiones para llevar un seguimiento del estado de desarrollo de los mismos:<\/p>\n<ul>\n<li>Alfa: Primer estado en el que el producto se puede testear. Funcionalidad b\u00e1sica o limitada, que indica las funcionalidades que se desean para la versi\u00f3n terminada.<\/li>\n<li>Beta: El producto es capaz de realizar todas o casi todas las funcionalidades objetivo, aunque con problemas operativos y de rendimiento, <i>bugs<\/i> e interfaces no finalizadas. La variante <i>perpetual beta<\/i> se aplica a productos que est\u00e1n en constante evoluci\u00f3n, y a veces para liberar a los desarrolladores del producto de determinadas responsabilidades respecto a los usuarios.<\/li>\n<li><i>Release candidate<\/i>: Producto pr\u00e1cticamente terminado, pendiente de nuevos tests, resoluci\u00f3n de <i>bugs<\/i> y mejoras, pero que resulta ya un producto s\u00f3lido para ser utilizado por los usuarios finales. Se difunde principalmente a <i>beta testers<\/i> o grupos seleccionados de usuarios con fines de marketing, y para recoger <i>feedback<\/i>.<\/li>\n<li><i>Final\/release to marketing\/general availability (going live)\/release to web<\/i>: Dependiendo de la naturaleza del producto, se utilizar\u00e1 el t\u00e9rmino m\u00e1s adecuado. <i>Release to marketing<\/i> se utiliza para productos que van a ser distribuidos junto con otros productos; <i>general availability<\/i> se usa para lanzamientos al p\u00fablico en general, y <i>release to web<\/i> es para productos que utilizan Internet como principal medio de distribuci\u00f3n.<\/li>\n<\/ul>\n<h5>\u00c1reas de dise\u00f1o y perfiles profesionales<\/h5>\n<p>Hay tres \u00e1reas principales de dise\u00f1o implicadas en el desarrollo de un proyecto multimedia, y cada miembro del equipo de desarrollo pertenece a una de ellas (o, en casos excepcionales, a varias):<\/p>\n<ul>\n<li>Media: dise\u00f1o visual (imagen, animaci\u00f3n y v\u00eddeo) y audio, alta complejidad, gran n\u00famero de especialistas disponibles.<\/li>\n<li>Software: arquitectura, patrones de programaci\u00f3n, objetos, alta complejidad, gran n\u00famero de especialistas disponibles.<\/li>\n<li>Interacci\u00f3n: dise\u00f1o centrado en el usuario, interacci\u00f3n persona-ordenador, complejidad media, pocos especialistas disponibles.<\/li>\n<\/ul>\n<p>Mientras que los especialistas en las dos primeras \u00e1reas suelen trabajar sin muchas intersecciones de tareas entre \u00e1reas, los especialistas en interacci\u00f3n a menudo interact\u00faan en el equipo con las otras dos tipolog\u00edas.<\/p>\n<h6>T\u00e9cnicas<\/h6>\n<p>Algunas de las t\u00e9cnicas de trabajo m\u00e1s habituales en un desarrollo multimedia son las siguientes:<\/p>\n<ul>\n<li>prototipado (<i>wireframes<\/i> y <i>mockups<\/i>),<\/li>\n<li>diagramas de flujo (de algoritmos o procesos),<\/li>\n<li><i>storyboards<\/i>,<\/li>\n<li>diagramas de flujo de datos,<\/li>\n<li>t\u00e9cnicas de orientaci\u00f3n a objetos,<\/li>\n<li>diagramas de clase,<\/li>\n<li>modelos entidad-relaci\u00f3n,<\/li>\n<li>diagramas de estado,<\/li>\n<li>diagramas de casos de uso.<\/li>\n<\/ul>\n<h5>Roles\/profesiones<\/h5>\n<p>El desarrollo de un producto multimedia puede llegar a requerir de una elevada variedad de especialistas, tales como:<\/p>\n<ul>\n<li>m\u00e1nager de proyecto,<\/li>\n<li>programador,<\/li>\n<li>administrador de bases de datos,<\/li>\n<li>director t\u00e9cnico,<\/li>\n<li>dise\u00f1ador gr\u00e1fico,<\/li>\n<li>especialistas en imagen (fotograf\u00eda, v\u00eddeo, 3D, animaci\u00f3n),<\/li>\n<li>especialista en UX,<\/li>\n<li>ingeniero de sonido,<\/li>\n<li>director creativo,<\/li>\n<li><i>copywriter<\/i>,<\/li>\n<li>editor\/gestor de contenidos,<\/li>\n<li>experto en la materia sobre la que trata el producto,<\/li>\n<li>investigador (de mercado, productos, entre otros),<\/li>\n<li>administrador de redes,<\/li>\n<li>especialista en <i>learning<\/i> &amp; <i>development<\/i>.<\/li>\n<\/ul>\n<h5>Desarrollos en la vida real<\/h5>\n<p>En la pr\u00e1ctica, cada proyecto y equipo tiene sus propias peculiaridades, por lo que las teor\u00edas y modelos se deben usar de manera inteligente, e incluso adaptados, para adaptarse a muy diversas circunstancias y llevar el proyecto a cabo con \u00e9xito. Algunas de las m\u00e1s habituales son las que presentamos a continuaci\u00f3n:<\/p>\n<ul>\n<li>Parte de las tareas de desarrollo o producci\u00f3n, por ejemplo desarrollo de contenidos audiovisuales, las puede ejecutar el cliente o terceros.<\/li>\n<li>A menudo, hay que trabajar con proveedores externos del cliente final o del equipo de desarrollo.<\/li>\n<li>El equipo puede estar distribuido geogr\u00e1ficamente. Esto puede implicar una distancia temporal debido a las diferencias en los husos horarios.<\/li>\n<li>La media de tiempo necesaria para el desarrollo de un proyecto oscila entre los seis meses y el a\u00f1o.<\/li>\n<li>En las fases de programaci\u00f3n intensiva, el tiempo consumido por los programadores es muy elevado, y se hace crucial una gesti\u00f3n \u00f3ptima de los recursos.<\/li>\n<li>Los <i>managers<\/i> de proyecto invierten m\u00e1s tiempo que cualquier otro miembro del equipo.<\/li>\n<li>La necesidad de horas extras es habitual.<\/li>\n<li>La variedad de retos que se deben afrontar todos los d\u00edas es extremadamente elevada.<\/li>\n<li>El nivel de satisfacci\u00f3n a medida que se acerca la finalizaci\u00f3n del proyecto aumenta, pero tambi\u00e9n lo hace el nivel de presi\u00f3n sobre el equipo.<\/li>\n<\/ul>\n<p>A continuaci\u00f3n, se muestran algunos diagramas que ilustran las curvas tipo que indican las fases que experimenta la adopci\u00f3n social o el desarrollo de tecnolog\u00edas (im\u00e1genes tomadas de la Wikipedia). Es habitual encontrar la misma curva o una muy similar en muchas de las tecnolog\u00edas y proyectos y, por lo tanto, prever c\u00f3mo las distintas fases y estados del equipo o la tecnolog\u00eda en cuesti\u00f3n pueden afectar a un desarrollo, ya que la pendiente de iluminaci\u00f3n o <i>slope enlightenment<\/i> suele coincidir con el final del proyecto o su proceso de mantenimiento (ved la imagen <i>Drupal mood cycle<\/i> m\u00e1s adelante). El t\u00e9rmino espec\u00edfico, acu\u00f1ado por Gartner para definir este fen\u00f3meno, es <i>hype cycle<\/i>.<\/p>\n<p><a href=\"http:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/Gartner_Hype_Cycle.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone  wp-image-268\" alt=\"Gartner Hype Cycle\" src=\"http:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/Gartner_Hype_Cycle.png\" width=\"450\" height=\"293\" srcset=\"https:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/Gartner_Hype_Cycle.png 500w, https:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/Gartner_Hype_Cycle-300x195.png 300w\" sizes=\"auto, (max-width: 450px) 100vw, 450px\" \/><\/a><\/p>\n<p><a href=\"http:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/gartner_2010-EmergingTech-HypeCycle.gif\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone  wp-image-267\" alt=\"Gartner Emerging Tech's HypeCycle (2010)\" src=\"http:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/gartner_2010-EmergingTech-HypeCycle.gif\" width=\"549\" height=\"478\" \/><\/a><\/p>\n<p>Aplicado a un proyecto de desarrollo en Drupal (<i>Drupal mood cycle<\/i>, de Dries Buytaert, <a href=\"http:\/\/buytaert.net\">http:\/\/buytaert.net<\/a>), resultar\u00eda en:<\/p>\n<p><a href=\"http:\/\/buytaert.net\/the-drupal-mood-cycle\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone  wp-image-266\" alt=\"The Drupal mood cycle\" src=\"http:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/buytaert_drupal_mood_cycle.jpg\" width=\"450\" height=\"303\" srcset=\"https:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/buytaert_drupal_mood_cycle.jpg 500w, https:\/\/multimedia.uoc.edu\/blogs\/fem\/files\/2013\/03\/buytaert_drupal_mood_cycle-300x202.jpg 300w\" sizes=\"auto, (max-width: 450px) 100vw, 450px\" \/><\/a><\/p>\n<h5>Videograf\u00eda<\/h5>\n<p>A continuaci\u00f3n, dos v\u00eddeos introductorios a variantes del m\u00e9todo Agile:<\/p>\n<p style=\"padding-left: 30px\"><i>Intro to Agile Scrum in Under 10 Minutes:\u00a0<\/i><a title=\"Intro to Agile Scrum in Under 10 Minutes\" href=\"http:\/\/www.youtube.com\/watch?v=XU0llRltyFM\">http:\/\/www.youtube.com\/watch?v=XU0llRltyFM<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>Agile: An Introduction:\u00a0<\/i><a title=\"Agile: An Introduction\" href=\"https:\/\/www.youtube.com\/watch?v=OJflDE6OaSc\">https:\/\/www.youtube.com\/watch?v=OJflDE6OaSc<\/a><\/p>\n<h5>Recursos adicionales<\/h5>\n<p style=\"padding-left: 30px\"><i>Getting Real. The smarter, faster, easier way to build a successful web application: \u00a0<\/i><a title=\"Getting Real. The smarter, faster, easier way to build a successful web application\" href=\"http:\/\/gettingreal.37signals.com\">http:\/\/gettingreal.37signals.com<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>Overview of Multimedia Authoring<\/i>, Virginia Tech: <a title=\"Overview of Multimedia Authoring, Virginia Tech\" href=\"http:\/\/www.itma.vt.edu\/modules\/spring03\/multimed\/assignments.htm\">http:\/\/www.itma.vt.edu\/modules\/spring03\/multimed\/assignments.htm<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>An Introduction to Digital Multimedia:\u00a0<\/i><a title=\"An Introduction to Digital Multimedia\" href=\"http:\/\/my.safaribooksonline.com\/book\/digital-media\/9780763750527\/multimedia-development\/section_11.1\">http:\/\/my.safaribooksonline.com\/book\/digital-media\/9780763750527\/multimedia-development\/section_11.1<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>A Survey of Multimedia and Web Development Techniques and Methodology Usage:\u00a0<\/i><a title=\"A Survey of Multimedia and Web Development Techniques and Methodology Usage\" href=\"http:\/\/ir.library.nuigalway.ie\/xmlui\/bitstream\/handle\/10379\/270\/A%20Survey%20of.pdf?sequence=1\">http:\/\/ir.library.nuigalway.ie\/xmlui\/bitstream\/handle\/10379\/270\/A%20Survey%20of.pdf?sequence=1<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>Multimedia Development Process<\/i>, Tom McEwan de la Universidad Napier de Edimburgo: <a title=\"Multimedia Development Process, Tom McEwan de la Universidad Napier de Edimburgo\" href=\"http:\/\/www.soc.napier.ac.uk\/~tommc\/modules\/mm8413307\/methodologies.htm\">http:\/\/www.soc.napier.ac.uk\/~tommc\/modules\/mm8413307\/methodologies.htm<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>Software Development Methodologies<\/i>, Wikipedia: <a title=\"Software Development Methodologies, Wikipedia\" href=\"http:\/\/en.wikipedia.org\/wiki\/Software_development_methodologies\">http:\/\/en.wikipedia.org\/wiki\/Software_development_methodologies<\/a><\/p>\n<p style=\"padding-left: 30px\"><i>Hype cycle<\/i>, Gartner: <a title=\"Hype cycle, Gartner\" href=\"http:\/\/en.wikipedia.org\/wiki\/Hype_cycle\">http:\/\/en.wikipedia.org\/wiki\/Hype_cycle<\/a><\/p>\n<p><\/p>","protected":false},"excerpt":{"rendered":"<p>Aunque hay cierta confusi\u00f3n y debate acerca de qu\u00e9 engloba y qu\u00e9 no un desarrollo multimedia, es posible afirmar con seguridad que incluye la generaci\u00f3n de productos y contenidos, en especial en los nuevos medios e Internet como entornos nativos; asimismo, es patente la necesidad tanto de planificaci\u00f3n como de un modelo com\u00fan de trabajo &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/desarrollo-multimedia-bases-conceptuales-fases-y-modelos\/\" class=\"more-link\">Seguir leyendo<span class=\"screen-reader-text\"> \u00abDesarrollo multimedia: bases conceptuales, fases y modelos\u00bb<\/span><\/a><\/p>\n","protected":false},"author":33,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[65,66,67,45],"class_list":["post-107","post","type-post","status-publish","format-standard","hentry","category-methods","tag-desarrollo","tag-desenvolupament","tag-programacio","tag-programacion","entry"],"_links":{"self":[{"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/posts\/107","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/comments?post=107"}],"version-history":[{"count":18,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/posts\/107\/revisions"}],"predecessor-version":[{"id":276,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/posts\/107\/revisions\/276"}],"wp:attachment":[{"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/media?parent=107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/categories?post=107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/multimedia.uoc.edu\/blogs\/fem\/es\/wp-json\/wp\/v2\/tags?post=107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}