Resum

Portar a terme un projecte audiovisual multimèdia és una tasca complexa que requereix el concurs de professionals de diverses disciplines que s’han d’organitzar com un equip de desenvolupament, cadascun d’ells assumint un rol diferent. Cada rol delimita les responsabilitats que té el membre de l’equip i el tipus de tasques que pot dur a terme. Podem classificar-los en diferents grups:

  • Els rols productius: aquells que tenen com a funció principal crear els arxius que formen el projecte. Dins d’un projecte de producte interactiu multimèdia, els rols productius més importants són els dels artistes i els programadors, que incorporen respectivament els recursos i el codi del projecte.
  • Els rols organitzatius: transmeten a la resta de membres de l’equip els paràmetres i objectius que ha de seguir el projecte. Els rols organitzatius més importants són el productor, que organitza el treball i s’assegura que es compleixen els objectius i els dissenyadors, que vetllen perquè el projecte reflecteixi la visió que s’ha establert.
  • Els rols auxiliars: fan una funció concreta dins el projecte. El rol auxiliar més important és el dels testers, que verifiquen que el projecte es comporta com està previst i compleix els paràmetres de qualitat que s’hagin definit.

Entre membres de l’equip amb el mateix rol es poden definir jerarquies i especialitats. Una jerarquia defineix qui té més pes a l’hora de definir aspectes comuns com metodologies de treball. Una especialitat reconeix una àrea en què un membre de l’equip té més coneixements, de manera que el seu criteri pot tenir prioritat sobre el d’altres inclús si jeràrquicament tenen posicions superiors.

Podem trobar dos estils organitzatius principals a les empreses; cadascun és adequat per a un tipus de projecte:

  • El treball per equips: s’assigna cada projecte a un equip, que s’ha d’encarregar de totes les tasques que generi. El treball per equips és més adequat per a projectes on els processos de producció no són coneguts a priori o l’entorn és inestable.
  • El treball per departaments: les persones que treballen a l’empresa es divideixen per grups anomenats departaments, cadascun dels quals agrupa tots els treballadors amb un mateix tipus de rol. El treball per departaments sol funcionar millor quan els procediments que cal seguir al projecte són fixos i coneguts i l’entorn és estable.

L’equip de desenvolupament existeix dins un entorn humà i material, que el proveeix del context físic i els recursos que necessita, a més d’una sèrie de serveis. Podem dividir aquest entorn en departaments, i això pot afavorir el desenvolupament del projecte, però també el pot perjudicar:

  • L’administració és el departament de l’empresa que gestiona els recursos econòmics.
  • El departament de sistemes vetlla pels equips informàtics i assessora sobre les adquisicions de nous equips i serveis.
  • El departament de recursos humans s’encarrega d’aspectes relacionats amb el tracte amb les persones.
  • El departament de manteniment i neteja vetlla per l’estat òptim de les instal·lacions i assegura unes condicions higièniques en l’entorn de treball.

A l’hora d’afrontar un projecte, cal estructurar el treball, organitzant-lo en unitats, i caracteritzar-les per tal de fer millors planificacions. Les unitats més importants són la tasca i l’objectiu:

  • Una tasca consisteix en l’aplicació d’un esforç per part d’una o més persones durant un cert temps per tal d’assolir un objectiu.
  • Un objectiu consisteix en una sèrie de condicions que s’han de complir en completar una tasca. Podem distingir entre tasques i objectius simples quan un sol membre de l’equip les pot dur a terme directament i tasques complexes quan no són assolibles directament per una persona i cal descompondre-les en tasques més senzilles.

Dins d’un projecte podem distingir diferents nivells:

  • El nivell individual comprèn les tasques i objectius que els membres d’un equip de desenvolupament realitzen en el seu treball diari, modificant directament els arxius i documents que formen el projecte. Aquestes tasques es fan en terminis curts.
  • El nivell d’equip comprèn les tasques i objectius que, per la seva complexitat o perquè suposen un volum de treball massa gran, per poder-se fer primer s’han de descompondre en tasques i objectius individuals tot formant un pla de treball. Les tasques es porten a terme en terminis mitjans.
  • El nivell de projecte comprèn les tasques i objectius que fan referència al projecte com a conjunt. Inclou els requisits que es pacten amb les persones interessades o stakeholders del projecte. Les tasques i objectius d’aquest nivell es porten a terme a terminis llargs.

Les característiques més importants d’objectius i tasques són:

  • En el cas d’un objectiu, l’identificador, que ens permet referir-nos-hi sense ambigüitat, la importància, que ens indica si arribats al cas es pot no assolir l’objectiu, i les condicions de completesa, que ens permeten verificar si l’objectiu s’ha assolit o no. És extremadament important que aquestes condicions siguin objectives i verificables.
  • En el cas d’una tasca, l’identificador, com en el cas dels objectius, la prioritat, que com a productors ens permet influir sobre l’ordre de realització de les tasques, l’objectiu, la descripció i la durada; que podem dividir en una durada esperada i una incertesa, tot i que sempre seran estimacions.

La tasca principal d’un productor és l’elaboració, comunicació i seguiment dels plans de treball. Un pla de treball s’elabora en diferents etapes:

  1. Primer es fa una anàlisi de la tasca o objectiu fins a trobar una descomposició que sigui possible portar a la pràctica. Aquesta anàlisi la fa el productor amb l’assessorament dels membres més experts de l’equip.
  2. El segon pas és elaborar el pla, caracteritzant cadascuna de les tasques i objectius i determinant els rols necessaris i reunir l’equip per fer les tasques, que pot estar format pels membres de l’equip en els seus rols habituals o ser un equip ad hoc o reunit específicament per a una tasca concreta. En aquest cas pot passar que algun membre de l’equip hagi de fer un rol diferent del que té habitualment.
  3. El tercer pas consisteix a comunicar el pla, cosa que es fa d’una manera diferent segons el nivell de producció de què es tracti.
  4. Finalment, una vegada l’equip comença a treballar en les tasques, la funció principal del productor passa a ser la seva supervisió.

Els projectes passen per un cicle de vida que consta de diverses etapes. En cada etapa hi ha un objectiu general diferent i algunes activitats predominen més que altres:

  1. A l’etapa de concepció el més important és determinar què es vol fer, és a dir, s’ha d’arribar a una imatge clara del resultat que se cercarà a partir d’unes idees inicials. Una vegada s’ha determinat això es passa a l’etapa de disseny.
  2. A l’etapa de disseny és on es desenvolupa i es concreten les idees en documents a partir dels quals es pot elaborar una estratègia que determini com portar a terme el projecte.
  3. A l’etapa de producció es porta a la pràctica aquesta estratègia i és on es produeixen físicament els recursos i codi que formarà el cos del projecte, en diferents cicles, on cada vegada es refinen més els processos productius i es fan més eficients.
  4. Finalment, a l’etapa de transició l’objectiu és el tancament del projecte i l’activitat principal és verificar que fa correctament les funcionalitats requerides amb la qualitat desitjada.

Hi ha dos paradigmes organitzatius a l’hora d’establir l’ordre en què es visiten les etapes d’un projecte:

  • Al paradigma en cascada, cada etapa es visita un sol cop en ordre, sense possibilitat de reconsiderar les decisions passades. El paradigma en cascada és adequat quan els processos de producció són ben coneguts i l’entorn de l’equip de desenvolupament és força estable.
  • Al paradigma iteratiu, en canvi, les etapes es visiten cíclicament, i s’admet la possibilitat de revisar les decisions preses a cada etapa. A cada “volta” o iteració d’aquest procés es produeix un prototip, que amb el temps s’amplia fins a arribar a ser un producte complet. El paradigma iteratiu és més adequat quan aquests processos no es coneixen bé o l’entorn de l’equip és inestable.

Quan treballem en un projecte, afegim una sèrie de característiques els efectes de les quals acordem amb els clients o persones interessades i l’equip a través d’una sèrie de requisits.

En alguns casos, podem fer proves senzilles que verifiquin que aquests requisits s’han assolit, però, donada la gran quantitat d’estats en què es pot trobar una aplicació interactiva, per verificar aquests requisits amb un grau suficient de confiança, haurem de fer proves d’una forma sistematitzada, en un procés que s’anomena verificació (testing).

Les proves internes són una primera forma de verificar que, tot i no tenir el mateix valor que un procés de verificació, ens donen una certa confiança d’estar construint el projecte correctament i faciliten la feina posterior de verificació, ja que es parteix d’una base més depurada.

La prova individual consisteix a fer una prova d’una característica abans d’incorporar-la al repositori del projecte. En el cas dels programadors a vegades aquesta prova pren la forma d’una prova de component. La prova d’equip verifica que els efectes combinats de les modificacions que s’han introduït al projecte generen el comportament esperat i la prova de projecte que els objectius globals del projecte s’han assolit. Aquesta última, així i tot, sovint sí que justifica un procés de verificació, ja que pot requerir la presència d’un equip de testers especialitzats per tal que la resta de l’equip pugui continuar amb el desenvolupament.

Una vegada s’ha iniciat un procés de verificació, caldrà definir uns rols i dividir i categoritzar el joc en àrees i aspectes, per poder establir un pla de verificació sistemàtica i unes dinàmiques de treball específiques.

Els rols dins un procés de verificació són:

  • Els testers, que verifiquen que el projecte compleixi amb els requisits i redacten informes de bugs quan no ho fa,
  • els encarregats, que arreglen els bugs
  • i el supervisor, que arbitra el procés i resol els conflictes que puguin sorgir entre testers i encarregats.

Els testers no treballen de forma desorganitzada, sinó seguint un pla de verificació que assegura que s’examina tot el projecte amb una intensitat uniforme, dividint-lo en àrees, que són zones disjuntes que poden ser examinades per separat i aspectes, que són els diferents components que té l’aplicació i que podem observar ignorant la resta, per exemple els gràfics o el so.

Una vegada establerts els tests que es faran, el tester pot aplicar diferents estratègies de verificació:

  • Si pot provar tots els casos possibles, parlarem d’un test exhaustiu.
  • Si només pot provar casos aleatòriament fins a obtenir una certa confiança estadística parlarem de tests repetitius o estocàstics.
  • I si existeixen magnituds contínues o amb molts valors que es poden provar en cadascun dels valors extrems i en terme mitjà parlem d’un test de límits.
  • Altres estratègies són saturar sistemes de l’aplicació o fer accions imprevistes.

Els bugs o errors són situacions en què l’aplicació no es comporta com estava previst. Els testers en fan reports que s’inclouen a una base de dades o llista i es caracteritzen amb una sèrie de propietats. Aquestes propietats poden incloure:

  • Un identificador, que permet fer referències sense ambigüitat al bug.
  • Un títol.
  • Una descripció, que ens permet determinar com es produeix, sovint a través d’una llista de passes per reproduir-lo, l’àrea i la categoria a què pertany, la reproductibilitat o facilitat que hi hagi per produir-lo, la severitat o com n’és de greu en el context del projecte, la prioritat o urgència que tingui la seva resolució, l’estat i els comentaris de les persones que hi treballen.

L’estat, en el cas dels bugs, pren una sèrie de valors que indiquen un cert tipus de situació en què la responsabilitat de fer la següent acció recau en el tester o l’encarregat. Els estats bàsics d’un bug són:

  • Obert, quan s’acaba de detectar i cal que l’encarregat l’arregli.
  • Arreglat, quan l’encarregat ha aplicat un canvi que creu que l’arregla i el tester l’ha de verificar.
  • Reobert, si el tester troba que encara no s’ha arreglat i cal que l’encarregat apliqui un altre canvi.
  • Tancat, quan el tester verifica que efectivament el bug ja no succeeix.

Si l’encarregat no pot reproduir el bug, pot posar-lo en estat cannot repro i el tester haurà de proveir-li instruccions més detallades per reproduir-lo, moment en què el posarà en estat de nova informació. En aquest estat, l’encarregat provarà de nou de reproduir-lo i arreglar-lo.

Fora d’aquest cicle, hi ha estats especials que indiquen situacions que usualment requereixen la intervenció del supervisor; com l’estat will not fix, que indica que el bug no s’arreglarà, tot i reconèixer que existeix, i l’estat not a bug, que indica que el que el tester identifica com a bug en realitat és una característica de l’aplicació. També pot passar que un bug aparegui diversos cops a la base o llista de bugs i l’encarregat el marqui amb l’estat de duplicat.

Com a suport al procés de verificació, l’equip de desenvolupament pot aplicar diferents mesures; per exemple, incloure modes de depuració o debug, que permetin mostrar informació sobre l’aplicació mentre aquesta s’està provant, o trampes i dreceres, que permetin accedir a una àrea ràpidament o que els testers tinguin un cert avantatge respecte a un usuari normal. Cal vigilar, però, ja que aquests elements invaliden el test en un cert grau. Altres mesures que poden ser útils són els tests automatitzats i la generació de reports d’error des de la mateixa aplicació quan es produeix un error greu i es tanca. La presència d’un sistema de gestió de bugs també facilita molt el procés.

La verificació més intensa es produeix en el moment de tancar un projecte, on l’activitat de l’equip es concentra principalment en això. Si es fa correctament, tot i que en un primer moment es detecten molts bugs, progressivament se’n detecten cada vegada menys, fins que arriben a ser pocs o cap i l’equip de desenvolupament juntament amb les persones interessades es planteja si tancar el projecte i declarar la versió actual de l’aplicació com a versió final o gold.

Hi ha factors que contribueixen positivament que es pugui arribar a aquest punt. Són la presència de la modularitat a la construcció del projecte i la definició de fites temporals, on es deixen d’afegir característiques, feature freeze, i contingut, content complete.

Anar a la pàgina anterior:
Introducció
Anar a la pàgina següent:
Resultats d'aprenentatge