We are part of a European contest that takes place in September in 17 European countries. People are invited to take pictures of heritage sites in Romania and then upload them to Wikimedia Commons or Flickr under the CC-BY-SA-RO license. The 10 winners from Romania will get some prizes, then will go on to fight for the European jackpot (which is still to be unveiled).

So, whether you’re a Wikipedia contributor, a photographer or a monument aficionado, take the picture (or make a movie!) about a monument and upload it!

Update: I also made a presentation about this at the August RLUG meeting. Here are the slides: odp | pdf.

Dacă intrați pe Internet de pe un telefon mobil sau de pe un dispozitiv gen iPad și aveți nevoie de Wikipedia, puteți folosi cu încredere http://ro.m.wikipedia.org/

Această prezentare e ținută de Jimmy Wales. Jimmy face o serie de interviuri cu oameni de la Wikipediile mai mici, prin care să afle nevoile oamenilor respectivi. A ales 6 limbi cu sub 50.000 de articole, dar cu mai multe milioane de vorbitori (de la 3 la 230 de milioane).

Există probleme tehnice, ca de exemplu Windows și suportul pentru limbă în Sri Lanka (vă sună cunoscut? ), situl Wikipedia în Macedonia sau versiunile offline în Tadjikistan. Problemele de promovare sunt însă mult mai importante, afectând toate aceste variante. Competițiile de creat articole sunt întotdeauna interesante pentru contribuitori, însă puțini rămân pe Wikipedia (cam 20%).

Fundația susține aceste Wikipedii prin suportul pentru crearea unor asociații locale și prin soluționarea problemelor locale. Este nevoie însă și de suportul comunității.

Wikimedia offline și pe mobile

Wikipedia offline și mobilă sunt practic două fațete ale aceleiași monede. Fundația ar trebui să faciliteze dezvoltarea de aplicații 3rd party, deoarece nu poate acoperi toate cererile. Câteva exemple oferite sunt: egranary (“The Internet in a Box”), Wiki Reader, un sistem hardware deschis, care folosesc Translate Wiki pentru limbi noi. WikiPock dorește să ofere Wikipedia pe dispozitive mobile. Există multe altele pe appStores la iPhone și Android.

Deocamdată, dispozitivele mobile nu permit participarea, de aceea s-au ales parteneriatele cu Telefonica și Orange.

Pentru mine mai urmează doar festivitatea de închidere, după care o noapte de cupă mondială și drumul spre casă

Prima prezentare este din India. Și acolo a durat 5 ani până să fie făcută asociația locală. Explicația principală ține de nivelul de implicare și de numărul de utilizatori Wikipedia. Prezentatorul consideră că existența unei asociații devine din ce în ce mai importantă, deoarece poate încuraja creșterea. Totuși, asociațiile nu apar organic, este nevoie de încurajare pentru a apărea.

Este previzibilă și necesară și o metodă de afiliere în afara asociațiilor (de exemplu per eveniment). Un alt vorbitor a propus metoda Ambasadorilor folosită la Fedora.

Membrii boardului (în special Arne Klempert) țin însă la funcționarea asociațiilor, considerând-o necesară pentru constituirea de colaborări. De asemenea, consideră administrarea mai facilă pentru fundație.

În continuare, membrii publicului încearcă să ofere exemple despre ce este o asociație locală și cum se poate adapta sistemul la cerințele oamenilor care nu pot creea o asociație. Una din soluțiile propuse a fost reprezentată de modelul TEDx, în care licențierea se face per eveniment.

O altă problemă ridicată a fost cea a aprobării asociațiilor, care în unele cazuri durează extrem de mult, cum a fost la Wikimedia Macao (din cauza statutului în special).

Internaționalizare

Prezentarea începe cu un scurtă introducere despre meta și a ceea ce se traduce: anunțuri, conținut, interfață etc. Traducerile sunt făcute atât de amatori, cât și profesioniști (30% după un studiu din 2008), toți voluntari. Comunicarea se face prin Babylon, un noticeboard, prin paginile de discuție, prin lista de discuție translators-l, Comitetul pentru traduceri (Transcom). Din păcate prezentarea a fost greu de urmărit datorită limbii engleza a prezentatoarei, așa că e posibil să fi sărit peste ceva informații relevante

Urmează Siebrand cu o scurtă prezentare a translatewiki.net. Cea mai importantă parte o reprezintă extensia Translate, care permite traducerea de formate de pagini. El speră ca această extensie să fie activată și pe meta, pentru a ajuta cu cererile de traducere. Va exista un demo al acestei idei de la ora 14:00 CET.

Legături interwiki

Legăturile interwiki reprezintă metadate comune pentru toate Wikipediile, nu numai pentru cea în care sunt puse. De aceea, ele sunt greu de urmărit și de aceea nu beneficiază de atenția editorilor. Ca soluție, se folosesc roboții, dar aceștia eșuează în caz de eroare.

Ca soluție se propune un loc central de păstrare. Nikola Smolenski a dezvoltat o extensie care permite existența acestui loc central de depozitare, sub forma unui wiki specializat.

Video on Wikipedia #2

Prezentarea aceasta este despre tehnologiile folosite pentru editare. S-a început cu un scurt istoric al videoului deschis și a CreativeCommons.

Timed Text este un format care permite subtitrarea filmelor în formate libere. AdMedia Wizard ușurează adăugarea de fișiere în articole. Se poate opta pentru folosirea sa pe en.wp, inclusiv transcodarea mp4-ogg în timp real.

P2P Video for Wikipedia

Se dorește folosirea surselor de tip P2P pentru descărcarea de video, cu fallback pe HTTP. Se folosește o tehnologie asemănătoare cu BitTorrent, doar că ordinea de descărcare este diferită (se folosesc 3 grade de importanță) și se folosește un algoritm Give-to-Get (trebuie să încarci ceva pentru a putea descărca). Acest lucru afectează performanța pe ASDL&friends.

Ca implementare, există o extensie de FF+plugin de IE8. Are o funcție de auto-creare torrent, ceea ce pare foarte cool.

Geodata pe Wikipedia și Commons

Kolossus a începu prin a prezenta formatul {{coordonate}} cu toate opțiunile sale, inclusiv pagina “Geohack” de la toolserver. Există un proiect “Wikipedia World” care pune punctele pe hartă, precum și un KLM pentru Google Earth, care permite interacțiunea inversă, de la hartă la articol.

Pe de.wp există un gadget pentru a folosi hărțile OSM în loc de MiniAtlas (vreau asta pe ro.wp!!! ieri ), precum și multe alte gadgeturi care permit folosirea datelor de pe wikipedia pe telefoane mobile, desktopuri etc.

Mai departe se prezintă cooperarea cu OSM – se dorește prezentarea unor hărți personalizate, cu layere custom, strict legate de Wikipedia. În prezent serviciul este disponibil pe un server de la Toolserver. În viitor va exista un format cu care se vor putea face cereri către serverul OSM și care va întoarce o hartă.

Extensiile Maps și SemanticMaps

Extensia Maps afișează coordonate în cadrul unui wiki. Poate fi folosit pentru geocoding sau pentru afișarea unei hărți, prin Google, Yahoo! sau Openlayers. Există multe metode de a specifica datele și chiar posibilitatea de a modifica hărțile.

În zona de mâncare apăruseră în timpul după-amiezei tot felul de afișe și broșuri cu diferite proiecte academice legate direct sau indirect de Wiki. Mie mi-au atras atenția 2:

1. intopedia își propune să ofere liste cu lucruri de făcut celor interesați să ajute Wikipedia, dar care nu știu ce s-ar putea face.
2. The Connectivity project oferă o metodă de a studia conexiunile între proiectele Wikipedia, oferind o serie de statistici despre bucle de categorii, articole fără legături, articole orfane etc.

La final, chiar înainte de plecare, am aflat care a fost premiul cel mare la concursul de scriere al cz.wp: un netbook[1]. NIIICE!

[1] Printr-o sponsorizare obținută de asociația locală de la o bancă locală.

KEYNOTE

Ziua a început cu o prezentare de la organizatorii polonezi, care le-au mulțumit sponsorilor și echipei. A urmat apoi keynoteul de la directoarea Wikimedia Foundation, Sue Gardner. Prezentarea a început cu un scurt sondaj, de unde a rezultat că marea majoritate a participanților sunt la prima Wikimania. A urmat o prezentare a noilor angajați ai fundației și a raportului anual pentru anul terminat la 30 iunie.

O parte interesantă a fost reprezentată de discuțiile despre dezvoltarea wikipediilor mici. Ideea era că acestea nu trebuie să folosească aceleași criterii pentru conținut ca și en.wp, ci să se concentreze pe creșterea numărului de contribuitori. De exemplu, la începutul fr.wp erau acceptate și rețetele, sau textele cu erori gramaticale. Criteriile propuse de strategia fundației țin de numărul de articole (120.000), pe când unii oameni din public considerau mai important numărul de membri activi.

Un alt punct subliniat a fost și faptul că trebuie încurajate mai mult întâlnirile față în față și în general colaborarea locală, precum și inițiativele locale și conținutul mobil.

Board of trustees Q&A

Au urmat pe scenă membrii boardului, pentru prima dată în formulă completă. Membrii tocmai fuseseră schimbați la ultima ședință, cu o zi înainte, așa că s-a început cu prezentările și mulțumirile de rigoare. S-a trecut apoi la întrebări

Q: E nevoie de mai multă implicare din partea boardului în problemele comunităților?

A: Jimmy Wales:În mare parte da, dar nu se poate intre în detalii

Michael Snow: Este nevoie de leadership la toate nivelurile. Boardul reprezintă nivelul cel mai înalt de leadership, el doar încurajează leadershipul și cultivă liderii din comunitătile locale.

Q: Există o lipsă de transparență în selectarea membrilor noardului

A: (mai mulți oameni)Există două procese diferite: pe de o parte există candidații, care se prezintă și sunt aleși (sau nu), iar pe de altă parte sunt selectați oameni interesa(n)ți pentru board. Ideea e că e nevoie de o organizație locală pentru a cunoaște toate detaliile procesului în timp real.

Q: Faceți o analiză SWOT pentru următorul an.

A: (Ting Chen) Amenințări: nu sunt strânse sumele dorite din fundraiser; creșterea numărului de angajați în paralel cu păstrarea și întărirea culturii organizaționale.

Oportunități: apariția unui al doilea datacenter, mai multe fonduri pentru comunitățile locale.

Chapters: Collaboration and Coordination

Creative Commons și afiliații locali

Prezentarea o găsiți aici.

CC este un model pentru dezvoltarea fără entități legale, cele două entități sunt profund legate. Există probleme legate de guvernanță translațională, rezolvate în mod diferit de entități diferite: FSF, global voices, mozilla drumbeat.

Urmează o prezentare a istoriei CC, cu portarea licențelor, proiecte eșuate (icommonss) și apoi planuri de viitor (participarea la guvernarea globală, unde sunt în urma Wikimedia, dar și comunicare mai bună între afiliați).

Michelle ne prezintă asemănări, deosebiri, dar și unele colaborări între Fundații Wikimedia locale și afiliați CC. Nu voi insista foarte mult, deoarece detaliile sunt scrise în prezentare.

Urmează Alex, de la CC Polonia, care prezintă conexiunile și felul în care acționează organizația sa.

Wikipedia and social media

Aceasta este o discuție discuție, unde apar mai multe idei, majoritatea legate de liquid threads, urmașul paginilor de discuție. Nu am ajuns de la început, așă că nu știu exact ce idei au apărut la început

Creating offline content from Wikipedia

Versiunile offline au mai multe avantaje, printre care lipsa de vandalisme, disponibilitatea în orice moment (din satele din India până la aeroporturile fără Wireless. Prezentarea de azi e mai mult tehnică și e orientată numai spre o versiune offline sigură (fără vandalism), nu și pe versiuni semi-offline, actualizabile.

Urmează o prezentare despre openzim, o metodă de a oferi conținutul Wikipedia offline. Se dorește crearea formatului de fișier, a unui cititor și a unei librării libere pentru decodarea fișierelor. Au fost prezentate mai multe exemple de proiecte care folosesc formatul zim.

În continuare, Shiju Alex și Santosh prezintă un studiu de caz asupra versiunii offline a Wikipediei în limba Malayalam, ci toate problemele aferente limbilor non-latine. Majoritatea prezentării se învârte în jurul rezolvării problemelor tehnice legate de crearea și distribuirea conținutului.

Întâlnirea asociaţiilor locale

A fost propus un consiliu al asociaţiilor, care dă ia deciziile de „zi cu zi”, cu mai multe versiuni: 1 om per ţară, număr fix, ambasadori fără putere de decizie etc. A existat o opoziţie puternică din partea asociaţiilor mici, care se simţeau dezavantajate de acest aranjament. În cele din urmă s-a decis analizarea acestui subiect în cadrul proiectului „roles 2” (sau ceva asemănător) al fundaţiei, care ar urma să analizeze interacţiunile dintre fundaţie şi asociaţii.

În continuare a fost o sesiune de q&a cu reprezentantul asociaţiilor în board.

• majoritatea oamenilor nu știau unde vor sta
• nu exista niciun fel de informație despre transportul de la aeroport la filarmonică, iar șoferii nu prea știu limba engleză
• la conferință nu existau încă materialele pentru participanți, nici măcar în dimineața primei zile.

Pe de altă parte, camera este decentă, cu două paturi și baie. NICE!

Mâine dimineață plec către Gdansk, orașul care va găzdui Wikimania 2010. O să încerc să scriu pe blog zilnic, în română și poate și în engleză. Dacă mai vine cineva din cei ce citesc aceste rânduri, lăsați un semn.

Totuși, creatorii de situri nu au posibilitatea de a-și da seama cine poate și cine nu poate vizualiza diacriticele corecte. Pentru a încuraja creatorii de conținut să facă trecerea la diacriticele corecte, este important ca aceste date să fie cunoscute. Vă invit deci să completați scurtul sondaj de mai jos. Vă ia 2 minute și nu necesită cunoștințe de specialitate. Dacă ați completat deja acest sondaj pe alt sit, nu veți mai putea să-l completați.

Download (toate referatele sunt distribuite sub Licența CC-BY 3.0)

Mai jos aveți la dispoziție o variantă text a referatului. Vă rugăm să rețineți că această variantă nu are nici un fel de formatare sau poze. Unele caractere pot să nu fie arătate corect. Pentru varianta integrală vă rugăm să downloadați referatul.

ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ
MANAGEMENTUL INFORMATIZAT AL PROIECTELOR

PROIECT LA DISCIPLINA MANAGEMENTUL CALITĂŢII PROIECTELOR

Student:

- 2009 -
ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ
MANAGEMENTUL INFORMATIZAT AL PROIECTELOR

ANALIZA CALITĂŢII UNUI PROIECT OPEN-SOURCE

Student:

- 2009 -
1.Cuprins
1. Cuprins    3
2. Rezumat    4
3. Introducere    4
4. Definirea problemei    5
5. Soluţia dată    5
6. Criterii de calitate urmărite    8
6.1   Timpul de desfăşurare al proiectului    8
6.2   Complexitatea proiectului    9
6.3   Consistenţa proiectului    9
6.4   Reacţiile utilizatorilor (accesibilitatea proiectului)    9
7. Rezultate experimentale (calculul indicatorilor)    10
7.1   Timpul de desfăşurare al proiectului    10
7.2   Complexitatea proiectului    12
7.3   Consistenţa proiectului    13
7.4   Reacţiile utilizatorilor (accesibilitatea proiectului)    13
8. Analiza rezultatelor    14
9. Concluzii     14
10. Bibliografie     16

2.Rezumat
Proiectul prezintă analiza calităţii unei aplicaţii software open-source. Se prezintă istoricul aplicaţiilor open-source, problema pe care dorim să rezolvăm, precum şi soluţia dată. Sunt apoi prezentate o serie de criterii de calitate împreună cu indicatorii aferenţi pe care le vom folosi pentru a evalua calitatea proiectului prezentat.
3.Introducere
Proiectele open-source reprezintă acele proiecte software în care codul sursă este făcut public la sfârşitul proiectului sau chiar în timpul desfăşurării sale. Ideea de cod open-source este destul de veche, ea apărând din nevoia programatorilor de a rezolva anumite probleme care apăreau frecvent în cadrul programelor. În [1] se consideră că primele programe cu sursă deschisă au fost exemplele date în cărtile şi articolele de programare.
De multe ori termenii de software open-source şi software liber (cunoscut şi sub denumirea de FLOSS/FOSS – Free (Libre) Open Source Software) sunt folosiţi ca sinonime. Cu toate acestea, existe anumite diferenţe în modul de licenţiere şi redistribuire între aceste tipuri. Pentru mai multe informaţii privind aceste diferenţe, se poate consulta [2]. Ca regulă generală însă, se poate spune că toate programele libere sunt open-source, dar nu şi invers.
Comunitatea dezvoltatorilor de software liber a apărut pentru prima dată în 1983, când Richard Stallman a lansat proiectul GNU. Acesta avea ca scop dezvoltarea unui sistem de operare care să respecte libertăţile utilizatorilor. Acest proiect s-a dezvoltat rapid şi în 1985 a apărut „The Free Software Foundation” ([3]), cea mai cunoscută organizaţie pentru promovarea programelor libere şi open-source.
În ultimele decenii, tot mai multe companii au adoptat un model de dezvoltare software open-source, încercând să formeze şi să menţină comunităţi cât mai numeroase şi cât mai active în jurul produselor dezvoltate de ele. Se estimează că în urmă cu un an existau peste 200.000 de proiecte open-source găzduite pe siturile specializate, dintre care aproximativ 18.000 de proiecte mature, iar rata de creştere a acestor proiecte era de aproximativ 85% pe an (adică se dublau la fiecare 14 luni) [4][5].
Managementul unui proiect software open-source se deosebeşte oarecum de managementul unui proiect software clasic. Diferenţele ţin de mai multe motive:
multe proiecte open-source nu încep cu scopul de a obţine profit, ci de a crea un produs software care să-şi satisfacă utilizatorii
există proiecte pornite din dorinţa autorului de a învăţa o tehnologie nouă sau un limbaj de programare nou; aceste proiecte sunt deseori folosite ca „laboratoare” pentru noi tehnici de programare
deşi companiile investesc în proiectele open-source care le interesează sau îşi dezvoltă propriile aplicaţii, programatorii implicaţi în proiecte open-source sunt de cele mai multe ori voluntari
oamenii implicati într-un proiect open-source pot avea disponibilităţi de timp şi calităţi diferite; mai mult, disponibilitatea pot varia de la lună la lună sau chiar de la zi la zi; programul de lucru este diferit faţă de cel dintr-o firmă
persoanele ce participă într-o comunitate sunt deseori răspândite pe tot globul, existând probleme cu diferenţele de fus orar
uneori, rolul de project-manager este asumat de un dezvoltator, care nu are experienţă în domeniul administrării proiectelor.
În această lucrare se prezintă un proiect open-source aflat în prezent în plină desfăşurare, şi anume schimbarea interfeţei de editare a sitului Wikipedia prin intermediul unei initiative de uzabilitate finanţată printr-un grant al unei fundaţii din SUA [6]. Va fi evaluată calitatea acestui proiect până în prezent, folosind o serie de indicatori specifici ce permit crearea unei imagini corecte şi complete asupra proiectului.
4.Definirea problemei
Înfiinţată în 2001, enciclopedia colaborativă online Wikipedia a cunoscut o dezvoltare explozivă, bazată pe publicitatea câştigată mai ales după ce, în 2005, a depăşit ca dimensiune Enciclopedia Britannica. Fundaţia înfiinţată pentru a administra această enciclopedie (Fundaţia Wikimedia) a lansat ulterior şi alte proiecte, care la rândul lor au cunoscut un succes important, înregistrând un număr de editor de ordinul miilor sau chiar sutelor de mii.
În ultima perioadă, odată cu atingerea (în varianta engleză) unui număr de 3.000.000 de articole [7], s-a constatat că ritmul de creştere al proiectelor s-a redus considerabil. Acest lucru este explicabil prin faptul că a devenit din ce în ce mai dificil pentru noii veniţi să contribuie la dezvoltarea enciclopediei. Conform unor cercetări recente, cauzele acestor dificultăţi par a fi două [8]:
o parte dintre vechii utilizatori au devenit „paznicii” articolelor deja existente, ei anulând de multe ori contribuţiile noilor veniţi; proporţia de contribuţii anulate ale utilizatorilor noi s-a dublat în ultimii trei ani;
caseta de editare simplă, prin care oricine poate contribui la Wikipedia nu a ţinut pasul cu dezoltarea sitului. Pentru a crea o pagină astăzi, un editor are nevoie de mult mai multe unelte decât în urmă cu 5-6 ani. Pentru exemplificare, în figura 1 este prezentată o comparaţie între unelte oferite de căsuţa de editare implicită (sus) şi o versiune îmbunătăţită, creată de un utilizator şi care oferă acces la toate funcţiile sitului (jos)

În urma acestor descoperiri, în decembrie 2008 a fost lansat un proiect în valoare de 890.000$ care să ducă la identificarea barierelor tehnice care împiedică noii utilizatori să contribuie şi ulterior la înlăturarea acestor bariere.
Acest proiect este condus şi finanţat separat de activităţile Fundaţiei Wikimedia. Prin lucrarea de faţă se urmăreşte determinarea unor criterii de calitate şi a unor indicatori care să permită evaluarea acestui proiect. În paralel cu acest proiect se desfăşoară un proiect înrudit, menit să uşureze procesul de încărcare a fişierelor media (filme, melodii, poze) pe siturile Wikimedia. Administrarea celor două proiecte se face separat, singura legătură fiind faptul că ambele vizează îmbunătăţirea experienţei utilizatorilor [10].
5.Soluţia dată
Fiind vorba de un proiect privat, dezvoltat chiar de către firma beneficiară, finanţatorii au decis să nu organizeze o licitaţie pentru determinarea proiectului câştigător. În schimb, acesta este dezvoltat de o echipă selectată chiar de către client.
Aceasta este formată dintr-un Project Manager, un specialist în interfeţe om-maşină şi trei dezvoltatori specializaţi pe tehnologii web. Doi dintre dezvoltatori vor fi mutaţi de la alte proiecte ale Fundaţiei Wikimedia către acesta, iar restul personalului va fi angajat pe durata proiectului.
Toţi angajaţii acestui proiect au cel puţin 5 ani experienţă în domeniul lor de lucru, ceea ce limitează riscurile de întârzieri legate de perioada de „acomodare” cu proiectul. De asemenea, este necesar ca programatorii să mai fi lucrat în cadrul unui proiect open-source, pentru a fi deja obişnuiţi cu particularităţile întâlnite la astfel de proiecte, în special cu posibilele reacţii ale comunităţii. În Figura 2 este prezentată organigrama proiectului.

În plus faţă de resursele umane, se mai folosesc şi următoarele tipuri de resurse:
resurse administrative (birouri, consumabile, acces la Internet etc.)
resurse de calcul (calculatoare, soft etc.)
resurse non-materiale (comunitatea de utilizatori)
Proiectul se desfăşoară pe o perioadă de 16 luni, între ianuarie 2009 şi aprilie 2010, fiind împărţit în trei faze [6] şi mai multe activităţi, după cum urmează:
Faza de planificare (ianuarie – martie 2009)
A1 – Găsirea spaţiului de birouri
A2 – Angajarea managerului de proiect, a specialistului în interfeţe om-maşină şi a unui programator web
A3 – Analiza mediului de lucru: ce s-a făcut până în prezent în domeniul uzabilităţii aplicaţiei MediaWiki
A4 – Studiu asupra uzabilităţii şi experienţei avute de utilizatori pe siturile Fundaţiei Wikimedia
A5 – Definirea cerinţelor proiectului
Faza 1 – unelte de editare de bază (aprilie – august 2009)
A6 – Dezvoltarea primei versiuni a proiectului (Acai)
A7 – Testarea (din punct de vedere al funcţionalităţii, uzabilităţii, internaţionalizării şi localizării aplicaţiei)
A8 – Punerea în producţie în cadrul unui sit de test, cu acces limitat
A9 – Primele reacţii ale comunităţii
A10 – Testarea acestei versiuni de către publicul larg (ca opţiune pe toate proiectele Wikimedia)
Faza 2 – interfaţă de editare simplificată (septembrie 2009 – martie 2010)
A11 – Se trece la dezvoltarea celei de-a doua etape a proiectului (Babaco)
A12 – Continuă testarea de către comunitate a versiunii Acai
A13 – Punerea în producţie a versiunii Babaco în cadrul unui sit de test, cu acces limitat
A14 – Redefinirea cerinţelor proiectului în funcţie de cererile primite până în acest moment de echipă
A15 – Dezoltarea celei de-a treia versiuni a proiectului (Citron)
A16 – Testarea versiunii Citron (din punct de vedere al funcţionalităţii, uzabilităţii, internaţionalizării şi localizării aplicaţiei)
A17 – Primele reacţii ale comunităţii la această a doua versiune
A18 – Punerea în producţie pe toate versiunile ale Wikipedia
A19 – Testarea acestei versiuni de către publicul larg
A20 – Ultimele schimbări in urma reacţiei comunităţii
Fiind vorba de îmbunătăţiri aduse unei aplicaţii web, tehnologiile folosite sunt specifice dezvoltării de situri: HTML, JavaScript, PHP şi SQL.
Rezultatele proiectului (deliverables) constau în cele trei versiuni ale casetei de editare (cu numele de cod Acai, Babaco şi Citron) şi în integrarea cu rezultatele proiectului ce vizează uşurarea încărcării de materiale media. Cele trei versiuni ale proiectului nu sunt diferite, ci ele se completează reciproc, fiecare abordând o altă faţetă a uzabilităţii şi bazându-se pe îmbunătăţirile din versiunile anterioare.
La sfârsitul proiectului, doar versiunea Citron, cu eventualele îmbunătătiri de ultim moment, va fi integrată în aplicatia MediaWiki. În figura 3 sunt prezentate versiunile Acai şi Babaco. Se poate observa o diferenţă de abordare între cele două etape – în Babaco, fereatra de editare ocupă tot ecranul.

6.Criterii de calitate urmărite
Ca orice proiect software, şi proiectul de îmbunătăţire a uzabilităţii siturilor trebuie să aibă o serie de caracteristici de calitate, care să permită evaluarea proiectului în raport cu alte proiecte asemănătoare. Criteriile alese trebuie să asigure o imagine cât mai corectă şi completă asupra rezultatelor implementării.
Datorită faptului că proiectul ales este unul mic din punctul de vedere al resurselor umane şi financiare implicate, se aleg un număr de patru criterii de estimare a calităţii, prezentate mai jos împreună cu indicii de calitate aferenţi.
6.1 Timpul de desfăşurare al proiectului
Primul criteriu luat în considerare este timpul de desfăşurare al proiectului în raport cu timpul planificat. Pentru fiecare dintre cei 5 membri ai echipei se consideră următorii factori:
xi – timpul alocat prin proiect pentru toate activităţile persoanei respective pe toată durata proiectului (xi>0)
yi – timpul real de realizare al tuturor activităţilor persoanei respective pe toată durata proiectului (yi>0)
Pe baza acestor factori se calculează un indicator individual de calitate Iti=min(xi, yi)/max(xi, yi). Acest indicator este aproape întotdeauna subunitar şi pozitiv, singura situaţie în care Iti=1 fiind dacă se respectă întocmai timpul alocat prin proiect.
Pentru realizarea unui indicator agregat, se alocă fiecărui indicator Iti o pondere pi cu următoarele proprietăţi: 0<pi<1, p1 + p2 + … + p5 = 1. Vom ignora cazurile speciale în care una din ponderi este 1 şi restul sunt 0.
Pe baza acestor ponderi se calculează un indicator agregat It al timpului de desfăşurare al proiectului cu următoarea formulă:

Se stabilesc, prin convenţie, următoarele valori pentru acest criteriu de calitate:
rezultatul se consideră perfect dacă It = 1
rezultatul se consideră bun dacă 0,8 <= It < 1
rezultatul se consideră insuficient dacă It < 0,8
6.2 Complexitatea proiectului
Complexitatea unui proiect este influenţată de numeroşi factori, printre care numărul de tipuri de resurse, tehnologii, meserii şi activităţi implicate în desfăşurarea proiectului. În cazul proiectului prezentat, se consideră o formulă de calcul pentru complexitatea proiectului asemănătoare cu cea prezentată în [9]:

Factorii implicaţi în indicele de complexitate au următoarea semnificaţie:
N1 reprezintă numărul de activităţi derulate în cadrul proiectului
N2 reprezintă numărul de tipuri distincte de resurse utilizate în cadrul proiectului
N3 reprezintă numărul de tehnologii folosit
N4 reprezintă numărul de etape în care este împărţit proiectul
N5 reprezintă numărul de meserii implicate în desfăşurarea proiectului
Pentru a se realiza o evaluare a complexităţii unui proiect P se consideră de obicei un proiect de referinţă cu complexitatea Cref. Se consideră că proiectul P este complex dacă Cp > Cref şi că proiectul P este simplu dacă Cp < Cref .
6.3 Consistenţa proiectului
Conform [9], consistenţa proiectului vizează abordarea din aproape în aproape a construcţiei proiectului şi obţinerea unor părţi coerente care se deduc unele din altele, în aşa fel încât orice parte este inclusă în întreg şi proporţiile sunt păstrate cu rigurozitate.
Fie A1, A2, …, An activităţile desfăşurate în cadrul proiectului analizat şi C1, C2, …, Cn costurile asociate acestor activităţi. Costurile asociate resurselor proiectului (închirierea spaţiului pentru birouri, salariile etc.) se împart pe fiecare activitate proporţional cu durata în timp a acesteia şi cu alocarea resurselor pe activităţi. Se consideră că proiectul software studiat este consistent dacă următoarele condiţii sunt îndeplinite simultan:
Fiecare cost Ci este reflectat în propunerea de finanţare şi nu există costuri care să nu aibă o activitate asociată:, unde Ct reprezintă costul total al proiectului aşa cum reiese din propunerea de finanţare
Nu există o activitate Ai al cărui rezultat să fie făcut inutil (să fie suprascris sau recalculat) de rezultatul unei alte activităţi Aj: Rez(Ai) ∩ Rez(Aj) = 0.
Fiecare activitate este necesară în atingerea obiectivului final al proiectului.
6.4 Reacţiile utilizatorilor (accesibilitatea proiectului)
Deoarece proiectul analizat este folosit zilnic de mai multe milioane de utilizatori din ţări şi medii sociale foarte diverse, evaluarea accesibilităţii sale pentru cât mai multe persoane este făcută direct de către utilizatorii finali, în plus faţă de evaluarea făcută de client.
În acest scop se propune consultarea utilizatorilor în fiecare fază a proiectului, prin completarea voluntară a unor formulare ce conţin patru întrebări de tip DA/NU (întrebările pot varia de la o etapă la alta a proiectului). Pentru simplitate se consideră că un răspuns DA însemnă că utilizatorul este de acord cu nivelul de calitate din acea parte a proiectului, pe când un răspuns NU însemnă că proiectul lasă de dorit din punctul de vedere al calităţii. Fiecare utilizator poate răspunde o singură dată la un chestionar asociat unei faze a proiectului. Nu sunt acceptate formulare anonime (utilizatorii trebuie să fie conectaţi pentru a participa la sondaje).
Indicatorul asociat acestui criteriu de calitate va fi media artimetică a proporţiilor de răspunsuri pozitive din fiecare fază. Formula de calcul a indicatorului va fi deci:
,
unde:
F = numărul de faze ale proiectului (egal cu numărul de chestionare)
Npij = numărul de răspunsuri pozitive primite la întrebarea i din chestionarul asociat fazei j a proiectului
Ntij = numărul total de răspunsuri primite la întrebarea i din chestionarul asociat fazei j a proiectului
Cum 0 <= Npij <=Ntij rezultă că 0 <= IR <= 1. Cu cât indicatorul este mai aproape de 1, cu atât accesibilitatea produsului este mai bună. Se stabilesc, prin convenţie, următoarele valori pentru acest criteriu de calitate:
rezultatul se consideră perfect dacă IR = 1
rezultatul se consideră bun dacă 0,66 <= IR < 1
rezultatul se consideră insuficient dacă IR < 0,66
7.Rezultate experimentale (calculul indicatorilor)
Pentru a evalua calitatea proiectului analizat, se aplică criteriile de calitate prezentate în capitolul 6 situaţiei concrete rezultate din desfăşurarea proiectului şi se calculează apoi indicatorii asociaţi fiecărui criteriu.
În acest capitol se face doar prezentarea datelor şi calculul indicatorilor, analiza rezultatelor fiind făcută unitar, în cadrul capitolului 8.
7.1 Timpul de desfăşurare al proiectului
Pentru a calcula indicele de calitate pentru timpul de desfăşurare a proiectului, trebuie determinaţi timpii (în zile-om) alocaţi prin proiect fiecărei activităţi (xi) şi timpii reali de realizare a respectivei activităţi (yi).
În Tabelul 1 sunt prezentate alocările de timpi pentru fiecare membru al proiectului şi pentru fiecare activitate, în zile de lucru. Pentru activităţile care nu s-au desfăşurat până în acest moment (activităţile A16 – A20) se consideră că timpul de implementare este egal cu timpul prevăzut în proiect.

Project Manager
Specialist interfeţe
Programator 1
Programator 2
Programator 3

x1 (zile-om)
y1 (zile-om)
x1 (zile-om)
y1 (zile-om)
x1 (zile-om)
y1 (zile-om)
x1 (zile-om)
y1 (zile-om)
x1 (zile-om)
y1 (zile-om)
Total
172
186
152
162
162
168
152
158
152
158
A1
0
0
0
0
0
0
0
0
0
0

A2
10
10
10
10
10
10
0
0
0
0

A3
20
24
20
24
20
20
20
20
20
20

A4
40
46
40
46
0
0
0
0
0
0

A5
10
10
10
10
10
10
10
10
10
10

A6
10
14
0
0
20
24
20
24
20
24

A7
10
10
10
10
10
10
10
10
10
10

A8
2
2
2
2
2
2
2
2
2
2

A9
0
0
0
0
0
0
0
0
0
0

A10
8
8
8
8
8
8
8
8
8
8

A11
10
10
0
0
20
22
20
22
20
22

A12
0
0
0
0
0
0
0
0
0
0

A13
2
2
2
2
2
2
2
2
2
2

A14
10
10
10
10
10
10
10
10
10
10

A15
10
10
0
0
20
20
20
20
20
20

A16
10
10
10
10
10
10
10
10
10
10

A17
0
0
0
0
0
0
0
0
0
0

A18
10
10
10
10
10
10
10
10
10
10

A19
0
0
10
10
0
0
0
0
0
0

A20
10
10
10
10
10
10
10
10
10
10

Tabelul 1: Timpii alocaţi şi timpii consumaţi efectiv pentru fiecare activitate

Pe baza acestui tabel se calculează indicatorul de calitate pentru timpul de desfăşurare a proiectului. Deoarece echipa de proiect este foarte restrânsă numeric, fiecare membru al echipei este critic, de aceea se consideră că ponderea fiecărui membru este egală:
p1 = p2 = p3 = p4 = p5 = 0,2.
Indicele este deci:

7.2 Complexitatea proiectului
Folosind informaţiile despre proiect din capitolul 5, obţinem următoarele valori pentru factorii implicaţi în calculul complexităţii proiectelor:
N1 = 20 (numărul de activităţi derulate în cadrul proiectului)
N2  = 4 (numărul de tipuri distincte de resurse utilizate în cadrul proiectului)
N3  = 4 (numărul de tehnologii folosit)
N4  = 3 (numărul de etape în care este împărţit proiectul)
N5 = 3 (numărul de meserii implicate în desfăşurarea proiectului)
Se introduc aceste valori în formula indicatorului de complexitate  şi se obţine următoarea valoare numerică:

7.3 Consistenţa proiectului
Pentru a determina consistenţa proiectului, vom analiza fiecare din cele 20 de activităţi în raport cu cele 3 criterii prezentate în captiolul 6.3. Rezultatele analizei sunt grupate în Tabelul 2.
Activitatea
Costurile sunt reflectate în propunerea de proiect
Rezultatul activităţii nu este duplicat
Rezultatul activităţii participă în rezultatul final
A1
NU
DA
Indirect
A2
DA
DA
Indirect
A3
DA
DA
DA
A4
DA
DA
DA
A5
DA
DA
DA
A6
DA
DA
DA
A7
DA
DA
DA
A8
DA
DA
DA
A9
DA
DA
DA
A10
DA
NU (Rezultatul poate fi obtinut şi din A19)
DA
A11
DA
DA
DA
A12
DA
NU (Rezultatul poate fi obtinut şi din A19)
DA
A13
DA
DA
DA
A14
DA
DA
DA
A15
DA
DA
DA
A16
DA
DA
DA
A17
DA
DA
DA
A18
DA
DA
DA
A19
DA
DA
DA
A20
DA
DA
DA
Tabelul 2: Consistenţa proiectului analizat
7.4 Reacţiile utilizatorilor (accesibilitatea proiectului)
Până în prezent s-au desfăşurat sondaje cu privire la părerea utilizatorilor asupra primelor două faze ale proiectului studiat, urmând ca aproape de terminarea proiectului utilizatorii să fie chestionaţi şi asupra ultimei faze. Rezultatele au fost următoarele:

Întrebarea 1
Întrebarea 2
Întrebarea 3
Întrebarea 4

Răsp DA
Total
Răsp DA
Total
Răsp DA
Total
Răsp DA
Total
Faza 1
2322
2500
1820
2500
2067
2500
1520
2500
Faza 2
5970
6380
5074
6380
6001
6380
4310
6380
Tabelul 3: Răspunsurile utilizatorilor la întrebările din chestionar

Aplicând formula descrisă în capitolul 6.4, rezultă următoarea formulă pentru indicatorul de accesibilitate al proiectului:

8.Analiza rezultatelor
Pentru analiza calităţii proiectului vom folosi rezultatele experimentale determinate la capitolul anterior şi parametrii de calitate prezentaţi în capitolul 5.
Pentru timpul de desfăşurare al proiectului s-a obţinut un indice It>0,8. Conform interpretării prezentate în capitolul 6.2, se observă că din punct de vedere al timpului de lucru realizat efectiv, calitatea proiectului este bună.
Complexitatea proiectului a fost determinată numeric ca fiind 111,95. Deoarece a fost selectată o singură variantă de proiect pentru îmbunătăţirea uzabilităţii, nu există un proiect de referinţă cu care să fie comparate rezultatele. Se poate considera în schimb ca şi complexitate de referinţă complexitatea (calculată în acelaşi mod) al unui alt proiect din domeniul uzabilităţii siturilor web (al oricărei organizaţii), sau un proiect dintr-un domeniu conex aflat în portofoliul Fundaţiei Wikimedia. Comparaţiile făcute pe baza acestora ar fi însă doar parţial corecte şi rezultatele ar putea induce o imagine greşită asupra complexităţii proiectului.
Cu cât ar exista un număr mai mare de proiecte din care să se aleagă, cu atât eroare ar fi mai mică. Din păcate, portofoliul de proiecte software al Fundaţiei este relativ redus (până în 20), aşa că se preferă evitarea unor comparaţii.
Din tabelul 2 se observă că proiectul analizat nu este în întregime consistent. Există activităţi care nu sunt incluse în propunerea de proiect (căutarea spaţiului de birouri este făcută de către angajaţi ai Fundatiei Wikimedia, înainte de constituirea echipei de proiect), precum şi activităţi ale căror rezultate sunt duplicate de alte activităţi.
Cu toate că la o primă vedere testarea pe scară largă a primelor versiuni de proiect (Acai şi Babaco) poate părea inutilă, deoarece se face implicit şi în timpul testării Citron şi a testării finale, ea este necesară pentru a oferi echipei de proiect informaţii în timp real despre impresiile comunităţii asupra produsului software oferit spre testare. Acest lucru permite ajustarea obiectivelor proiectului (în cadrul activităţii A14) pentru a îmbunătăţi valoarea finală a indicatorului de calitate referitor la accesibilitatea proiectului (IR).
În concluzie, se consideră că proiectul analizat este în cea mai mare parte consistent, dar există şi părţi care ar fi putut beneficia de o planificare mai bună.
Ultimul criteriul, cel al accesibilităţii, este cel mai important, deoarece scopul proiectului este strâns legat de felul cum foloseşte comunitatea uneltele software puse la dispoziţia sa. Indicele de calitate determinat numeric este IR=0,8. Folosind intervalele prezentate la acest criteriu de calitate în capitolul 6.4, rezultă că accesibilitatea proiectului este bună. Se observă însă că ne aflăm doar la mijlocul intervalului, ceea ce însemnă că mai sunt posibile numeroase îmbunătăţiri.
9.Concluzii
Din datele prezentate în această lucrare se poate observa că lipsa unui portofoliu de proiecte asemănătoare finalizate la nivelul Fundaţiei Wikimedia a afectat capacitatea de estimare a calităţii produsului, prin lipsa unor puncte de comparaţie în ceea ce priveşte anumite criterii.
În urma aplicării indicatorilor de calitate descrişi în capitolul 6 şi a criteriilor aferente se observă însă că proiectul de îmbunătăţire a uzabilităţii siturilor fundaţiei Wikimedia are în general un grad de calitate ridicat. Mai există însă şi anumite părţi care ar necesita îmbunătăţiri, mai ales în ceea ce priveşte accesibilitatea aplicaţiei pentru publicul larg.
10.Bibliografie
[1]Ion Ivan – OPEN SOURCE – State of the Art, Open Source Scientific Journal, Vol. 1, No. 1, 2009
[2]Marius Popa – Processes of Quality Management in Open Source Software, Open Source Scientific Journal, Vol. 1, No. 1, 2009
[3]The Free Software Foundation, http://www.fsf.org
[4]Amit Deshpande, Dirk Riehle – The Total Growth of Open Source, In Proceedings of the Fourth Conference on Open Source Systems (OSS 2008). Springer Verlag, 2008. Page 197-209.
[5]Carlo Daffara – Estimating the number of active and stable FLOSS projects, 2007
[6]The Wikimedia Usability Initiative, http://usability.wikimedia.org
[7]Bobbie Johnson -  English Wikipedia hits three million articles, The Guardian, 17 august 2009
[8]Bongwon Suh, Gregorio Convertino, Ed H. Chi, Peter Pirolli. The Singularity is Not Near: Slowing Growth of Wikipedia. In Proc. of WikiSym 2009, (to appear). Oct, 2009. Florida, USA
[9]I. Ivan, C. Boja – Managementul calităţii proiectelor, Editura ASE , Bucuresti, 2005, ISBN 973-594-558-4, 122pg
[10]Wikimedia Foundation – Wikimedia Foundation receives Ford Foundation grant to grow Wikimedia Commons, a free educational media repository, Comunicat de presă, 1 iulie 2009