Encara que hi ha certa confusió i cert debat sobre què engloba i què no engloba un desenvolupament multimèdia, es pot afirmar amb seguretat que inclou la generació de productes i continguts, sobretot en els nous mitjans i Internet com a entorns natius; així mateix, es palesa la necessitat tant de planificació com d’un model comú de treball i terminologia, que són necessaris tant per a posar en marxa el projecte multimèdia com per a arribar a les metes fixades.
En aquest article oferirem informació bàsica àmpliament consensuada per la indústria sobre el significat i les característiques dels desenvolupaments multimèdia, amb la finalitat de facilitar la comprensió de conceptes, models i estratègies clau als qui comencen la carrera en l’univers multimèdia, tan prometedor i apassionant com complex.
Què és un desenvolupament multimèdia?
Un desenvolupament multimèdia és el nucli de treball de tot projecte multimèdia, que treballa els aspectes clau per crear un producte o servei complet, que compleixi de manera eficaç i eficient els objectius fixats i respongui amb la màxima qualitat possible a tots els principis i àrees de les disciplines que s’han aplicat per a crear-lo, des de programació fins a disseny d’interfícies.
Si ens cenyim a les definicions més esteses i estrictes en la indústria del programari i els nous mitjans, un desenvolupament multimèdia és una part del procés de producció d’un producte o servei multimèdia centrada a construir el producte en si mateix, independentment d’altres àrees com pressupost, màrqueting o gestió d’equips.
El que és important de veritat en aquesta qüestió, en definitiva, és distingir semànticament i amb claredat els conceptes clau del vocabulari del projecte, sobretot en la comunicació amb altres persones implicades en el projecte i en la documentació del projecte, amb independència de la terminologia que es vulgui fer servir.
Un desenvolupament multimèdia es pot abordar de moltes maneres, tant lineals com no lineals. Abans de posar en marxa el procés de desenvolupament, és molt important conèixer els mètodes i estratègies disponibles per a seleccionar i aplicar els més adequats al projecte.
Semblances amb altres processos de desenvolupament
S’ha de tenir en compte que com que es tracta d’una disciplina jove, hereva en certa manera de molts aspectes d’altres àmbits, com els vells mitjans o l’enginyeria industrial, té una gran influència dels mètodes utilitzats en aquests àmbits, que de vegades es poden extrapolar de manera molt directa a les necessitats del projecte multimèdia.
Sobretot hi ha una relació estreta entre el procés de desenvolupament multimèdia i la producció de continguts audiovisuals i els projectes de desenvolupament d’enginyeria de programari, tant pel que fa a la creació d’elements com a l’assemblatge d’aquests elements. De fet, les dues aproximacions fan falta perquè són complementàries a les necessitats d’un projecte multimèdia. Els cicles i models de desenvolupament de programari no ofereixen guies o models normalitzats en els aspectes purament creatius del desenvolupament multimèdia, però proveeixen d’una sòlida definició d’estratègies i pautes de treball, com la definició de requisits o la verificació dels productes, sobre les quals es poden acomodar els mètodes creatius i audiovisuals.
Fases de desenvolupament
El procés de desenvolupament d’un projecte multimèdia es pot estructurar en moltes fases. Tot seguit farem una llista de les més habituals, encara que poden variar de projecte a projecte per la diversa naturalesa que poden arribar a tenir:
- Anàlisi: definició dels objectius i requisits base del projecte.
- Planificació: identificació de les necessitats i problemàtiques clau per al desenvolupament, i establiment d’un pla estratègic de treball.
- Implementació, desenvolupament, creació, producció: generació i assemblatge de components necessaris. De vegades també es pot fer servir el terme implementació per a definir una possible fase en què el producte s’instal·la en una altra infraestructura quan s’ha acabat o està a punt d’acabar-se (en anglès també s’usa per a aquesta fase el terme deployment, desplegament).
- Verificació: validació de la feina feta i correcció d’errors i problemes.
- Documentació: manteniment d’un registre del procés de desenvolupament, creació de guies d’usuari, llibres d’estil, etc.
- Manteniment: correcció d’errors quan s’ha llançat el producte o servei. Se solen preparar eines i protocols de control i gestió, i les altres tasques passen en endavant a un altre personal, tant sota les ordres del cap de projecte (product manager) com de tercers.
És molt important tenir en compte que aquesta llista s’ha de prendre amb extrema precaució, tant pel fet que les fases poden variar molt d’un model de treball a un altre, com perquè els desenvolupaments multimèdia no solen ser processos estrictament lineals, en què cal concloure una fase per poder avançar cap a la següent.
Models de desenvolupament
Encara que les fases de desenvolupament poden variar, sobretot a grans trets, els models de treball possibles són clars i explícits, responen a molts escenaris i característiques dels projectes i permeten la hibridació entre uns i altres per aconseguir una gestió òptima del projecte. N’hi ha una gran varietat, de manera que en aquest article indicarem els d’ús més estès i que tenen més afinitat amb els desenvolupaments multimèdia.
Cascada (waterfall)
L’equip ha de seguir estrictament l’ordre de les fases d’anàlisi de requisits, disseny, implementació, validació, instal·lació i manteniment. Només és recomanable en projectes molt estructurats i lineals, perquè la seva rigidesa dificulta els processos de revisió i millora de fases que ja s’han acabat.
Iteratiu i incremental
Sobretot és adequat per a desenvolupaments de gran complexitat. Durant el procés, es produeixen alhora múltiples iteracions del cicle de desenvolupament, de manera evolutiva i incremental respecte a la creació del producte. La relació entre iteracions i increments en la construcció del producte i també el nombre depèn de la naturalesa del projecte en qüestió.
Desenvolupament ràpid d’aplicacions (RAD, de l’anglès rapid application development)
Minimitza la planificació en favor del prototipatge, de manera que també es conegut per de ràpid prototipatge. El procés de planificació s’entrellaça directament i avança en paral·lel amb el de desenvolupament. L’estalvi de temps en planificació accelera el desenvolupament i fa que sigui més fàcil de canviar si es donen alteracions en els requisits i els objectius. És recomanable per a petits projectes d’abast molt limitat, per a proves preliminars per a avaluar la viabilitat d’un projecte o per a les fases inicials d’un projecte que després serà migrat a un altre model.
Espiral
La filosofia d’aquest mètode és controlar i gestionar el risc en les diferents fases de desenvolupament. Combina aspectes dels models en cascada i RAD. Sobretot és adequat en projectes complexos de molta envergadura. El desenvolupament es visualitza com una espiral que passa per un nombre d’iteracions (girs complets), sobre quadrants que representen determinació d’objectius, identificació i resolució de riscos, desenvolupament i verificació, i planificació de la iteració següent.
Agile
Es tracta d’un dels mètodes més populars avui dia. Fa servir com a base un desenvolupament de tipus iteratiu, però amb un enfocament més centrat en el personal implicat, de manera que relega la planificació a un segon pla en favor de la retroacció (feedback) com a primer mecanisme de control. La retroacció es gestiona amb proves sobre versions incrementals del producte o servei en desenvolupament.
Agile s’ha fet servir com a base per a modelitzar moltes variants, com ara aquestes:
- Programació extrema (XP): les fases es culminen en passos extremament curts de durada o fins i tot continus, i no necessàriament es completen, de manera que fan avançar el procés de desenvolupament molt de pressa. Una de les primeres tasques és precisament preparar tests automatitzats per a concretar els objectius de desenvolupament, i és llavors quan es comença a programar. La creació de nous tests i fases de programació és iterativa. L’arquitectura se sol fer després com a refacció (refactoring), i l’elaboren els programadors mateixos. El disseny només es duu a terme en les fases finals i s’assembla al codi. El resultat, incomplet però funcional, es mostra als usuaris i alguns membres de l’equip de desenvolupament. Es reprèn el cicle escrivint més tests per a la nova part clau del sistema que s’ha de desenvolupar.
- Scrum: se centra a gestionar projectes en els casos en què costa fer planificacions completes o a llarg termini. Fa servir mecanismes de control empírics, com loops de retroacció, com a tècnica central de gestió del projecte. La seva estratègia de planificació i gestió és la presa de decisions basades en certeses i propietats de funcionament, i en l’àmbit d’operació la unitat bàsica de treball és l’Sprint, una tasca fixada en el temps que es posa en marxa amb una reunió per a planificar-la i s’acaba amb una altra d’anàlisi en retrospectiva.
- DSDM (dynamic systems development method): l’objectiu clau d’aquest mètode és gestionar projectes caracteritzats per pressupostos i calendaris estrictes. DSDM se centra a prevenir els errors més comuns en projectes (sobretot els de sistemes d’informació) com els esmentats, i també en la falta d’implicació dels usuaris i el compromís de l’alta direcció de l’organització.
Exploratory programming
Aquest model implementa una solució inicial per definir les especificacions i es va modificant fins que el client n’està satisfet o fins a aclarir les dades i estructures necessàries que modelaran els requisits per a una futura implementació. És molt iteratiu, requereix un elevat nivell de programació i es fa servir més en el desenvolupament de videojocs.
Code & fix
Traduïble literalment per programa i arregla, més que no pas un mètode és una tècnica utilitzada en casos d’alta pressió respecte a lliuraments per desenvolupadors veterans i també per inexperts en mètodes de desenvolupament. Centrant-se solament en codi, evitant el disseny, el programador es dedica a produir el màxim codi possible de manera immediata, i després d’això es verifica i es torna a programar per a solucionar els errors (bugs) que s’hi han trobat, fins que es pot lliurar el producte o l’element del producte. Aquest mètode només és recomanable per a programadors extremament experts en l’àrea del projecte en qüestió i els llenguatges utilitzats, ja que els riscos inherents són molt elevats (per exemple, pot produir codi espagueti).
Estats de producte
Encara que els desenvolupaments multimèdia no comporten sempre la producció de programari i serveis, se’n sol usar la terminologia de versions per a fer un seguiment de l’estat de desenvolupament:
- Alpha: primer estat en què es pot verificar el producte. Funcionalitat bàsica o limitada, per a indicar les funcionalitats que es volen per a la versió acabada.
- Beta: el producte és capaç de fer totes o gairebé totes les funcionalitats objectiu, encara que amb problemes operatius i de rendiment, errors i interfícies no acabades. La variant perpetual beta s’aplica a productes que estan en evolució constant, i de vegades per a alliberar els desenvolupadors del producte de determinades responsabilitats respecte als usuaris.
- Release candidate: producte gairebé acabat, pendent de nous tests, de resolució d’errors i de millores, però que ja resulta un producte sòlid perquè el facin servir els usuaris finals. Es difon sobretot a grups seleccionats d’usuaris amb finalitats de màrqueting (beta testers), i per a recollir retroacció.
- Final / release to marketing / general availability (going live) / release to web: depenent de la naturalesa del producte, s’utilitza el terme més adequat. Release to marketing es fa servir per a productes que s’han de distribuir juntament amb altres productes; General availability s’utilitza per a llançaments al públic en general, i release to web és per a productes que fan servir Internet com a principal mitjà de distribució.
Àrees de disseny i perfils professionals
Hi ha tres àrees principals de disseny implicades en el desenvolupament d’un projecte multimèdia, i cada membre de l’equip de desenvolupament pertany a una d’aquestes àrees (o, en casos excepcionals, a unes quantes):
- Media: disseny visual (imatge, animació i vídeo) i àudio, alta complexitat, gran nombre d’especialistes disponibles.
- Programari: arquitectura, patrons de programació, objectes, alta complexitat, gran nombre d’especialistes disponibles.
- Interacció: disseny centrat en l’usuari, interacció persona-ordinador, complexitat mitjana, pocs especialistes disponibles.
Els especialistes en les àrees media i programari solen treballar sense gaires interseccions de tasques entre àrees, mentre que els especialistes en interacció sovint interactuen en l’equip amb les altres dues tipologies.
Tècniques
Algunes de les tècniques de treball habituals en un desenvolupament multimèdia són aquestes:
- Prototipatge (model de filferro o wireframes, i maquetes o mock-ups)
- Diagrames de flux (d’algorismes o processos)
- Guions il·lustrats (storyboards)
- Diagrames de flux de dades
- Tècniques d’orientació a objectes
- Diagrames de classe.
- Models entitat-relació
- Diagrames d’estat
- Diagrames de casos d’ús
Rols/professions
El desenvolupament d’un producte multimèdia pot arribar a requerir una elevada varietat d’especialistes, com ara aquests:
- Cap de projecte
- Programador/a
- Administrador/a de bases de dades
- Director/a tècnic/a
- Dissenyador/a gràfic/a
- Especialistes en imatge (fotografia, vídeo, 3D, animació)
- Especialista en UX
- Enginyer/a de so
- Director/a creatiu/iva
- Redactor/a (copywriter)
- Editor/a o gestor/a de continguts
- Expert/a en la matèria sobre la qual tracta el producte
- Investigador/a (de mercat, productes, etc.)
- Administrador/a de xarxes
- Especialista en aprenentatge i desenvolupament
Desenvolupaments en la vida real
A la pràctica, cada projecte i cada equip tenen les seves pròpies peculiaritats, per la qual cosa les teories i els models s’han d’utilitzar de manera intel·ligent, i fins i tot adaptats, per a ajustar-se a circumstàncies ben diverses i portar a terme el projecte amb èxit. Algunes de les circumstàncies més habituals són aquestes:
- Una part de les tasques de desenvolupament o producció (per exemple, el desenvolupament de continguts audiovisuals) les poden fer el client o tercers.
- Sovint cal treballar amb proveïdors externs del client final o de l’equip de desenvolupament.
- L’equip pot estar distribuït geogràficament. Això pot implicar una distància temporal per les diferències de fusos horaris.
- La mitjana de temps que fa falta per a desenvolupar un projecte oscil·la entre sis mesos i un any.
- En les fases de programació intensiva, el temps que consumeixen els programadors és molt elevat, i acaba essent crucial una gestió òptima dels recursos.
- Els caps de projecte inverteixen més temps que cap altre membre de l’equip.
- La necessitat d’hores extres és habitual.
- La varietat de reptes que cal afrontar cada dia és extremament elevada.
- Augmenta el nivell de satisfacció a mesura que s’acosta l’acabament del projecte, però també augmenta el nivell de pressió sobre l’equip.
Tot seguit mostrarem alguns diagrames que il·lustren les corbes tipus que indiquen les fases que experimenta l’adopció social o el desenvolupament de tecnologies (imatges agafades de Wikipedia). És habitual trobar la mateixa corba o una de molt semblant en molts dels projectes i tecnologies, i per tant preveure com poden afectar un desenvolupament les diferents fases i els diferents estats de l’equip o la tecnologia en qüestió, ja que el pendent d’il·luminació (slope enlightenment) sol coincidir amb el final del projecte o el procés de manteniment (vegeu més avall la imatge drupal mood cycle). El terme específic, encunyat per Gartner per a definir aquest fenomen, és hype cycle.
Aplicat a un projecte de desenvolupament en Drupal (Drupal Mood Cycle, de Dries Buytaert, http://buytaert.net), té com a resultat:
Videografia
Vegeu tot seguit dos vídeos d’introducció a variants del mètode Agile:
Intro to Agile Scrum in Under 10 Minutes: http://www.youtube.com/watch?v=XU0llRltyFM
Agile: An Introduction: https://www.youtube.com/watch?v=OJflDE6OaSc
Recursos addicionals
Getting Real. The smarter, faster, easier way to build a successful web application: http://gettingreal.37signals.com
Overview of Multimedia Authoring, Virginia Tech: http://www.itma.vt.edu/modules/spring03/multimed/assignments.htm
An Introduction to Digital Multimedia: http://my.safaribooksonline.com/book/digital-media/9780763750527/multimedia-development/section_11.1
A Survey of Multimedia and Web Development Techniques and Methodology Usage: http://ir.library.nuigalway.ie/xmlui/bitstream/handle/10379/270/A%20Survey%20of.pdf?sequence=1
Multimedia Development Process, Tom McEwan de la Universidad Napier de Edimburgo: http://www.soc.napier.ac.uk/~tommc/modules/mm8413307/methodologies.htm
Software Development Methodologies, Wikipedia: http://en.wikipedia.org/wiki/Software_development_methodologies
Hype cycle, Gartner: http://en.wikipedia.org/wiki/Hype_cycle