Strainu onLine

Descriere: Analiza calității unui proiect open source
Materie: Managementul calității proiectelor
Referat făcut la master (Managementul Informatizat al Proiectelor, ASE).

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