este dezvoltarea unui sistem de inregistrare on-line

Raport "Event Registration"

Abstract

Scopul acestui proiect este dezvoltarea unui sistem de inregistrare on-line, sistem ce va permite:

administratorilor: publicarea si intretinerea unei liste de evenimente,

participantilor: inregistrarea via web si notificarea privind schimbarile.

Prezentare Proiect "Event Registration

Acest proiect - de fapt produsul final al acestuia - este un program ce va fi rulat/instalat intr-un server web, program ce produce si livreaza pagini HTML catre clienti-vizitatori. Cu alte cuvinte, este un site web. Acest site reprezinta de fapt o interfata cu un sistem de gestiune a evenimentelor, adica o interfata catre o baza de date ce inregistreaza evenimentele si participantii la ele.

Prin evenimente se inteleg manifestari (intalniri) organizate, anticipate (nu ad-hoc), la care iau parte mai multe persoane, situate initial in locatii diferite, si la care metodele de a se "intalni" pot varia (live-fizic, video, teleconferinta, chat). Sistemul realizat nu ofera o noua solutie pentru comunicatie, el doar gestioneaza participantii si ajuta organizatorii in efortul de a comunica cu acestia.

Site-ul este destinat unei retele intranet, dar poate fi instalat si pentru acces liber web. Structura sa este extrem de simpla, avand trei zone principale, ale celor trei categorii de utilizatori: participantii, organizatorii, si administratorii DB (de sistem).

Fiecare din aceste categorii poseda instrumente specifice de autentificare (Login), inregistrare a informatiilor in site, sau regasire a acestor informatii, sau a celor derivate - statistici per eveniment - astfel:

- Participantii: posibilitatea navigarii prin listele de evenimente disponibile, cu diverse ordonari; inregistrarea participarii la acestea, autentificare si alegerea metodelor de participare; postarea de mesaje catre organizatori (feedback).

- Organizatorii: cele anterioare plus crearea/editarea de evenimente, cu optiuni multiple in cadrul acestei operatii; stergerea, activarea, dezactivarea acestora; diverse rapoarte privind participantii.

- Administratorii: toate cele anterioare, plus gestionarea diferitelor tabele de date din sistem, prin interfata web, sau/si conectarea directa la baza.

Platforma ceruta a fost ASP/IIS/SQL Server/Windows 2000 AS.

Subiectul 1.a

Introducere

Am ales acest proiect (Event Registration), fiind un proiect real, in desfasurare, cu relativ putine resurse umane implicate (in total 5 persoane), si care, desi simplu in aparenta, a ridicat probleme interesante.

Personal am fost cel care a condus proiectul, mentinand legatura cu clientul, dirijand echipa si contribuind direct (si ca programator) la realizarea lui.

Durata totala a fost de 4 luni, astfel incat analiza financiara va fi realizata pe aceasta perioada, iar datorita faptului ca este vorba de un proiect comandat de client, voi analiza rentabilitatea lui din punctul de vedere al firmei contractoare, pentru client probabil fiind un proiect de importanta strategica.

Ca obiective declarate ale acestui proiect avem:

- Imbunatatirea procesului (actual) de inregistrare prin e-mail,

- Reducerea efortului depus pentru comunicarea schimbarilor catre toti participantii,

- Feedback-ul rapid pentru a putea corela numarul exact de participanti cu parametrii locatiilor evenimentelor.

Intuim ca obiective nedeclarate:

- Urmarirea (centralizata) a acestor evenimente,

- Crearea statisticilor de participare in timp, pentru a aprecia evolutia personalului si utilitatea evenimentelor.

Subiectul 1.b

Situatia clientului

Clientul este o corporatie cu multe filiale, cu mii de angajati dispersati in acestea, pentru care se organizeaza evenimente - sesiuni de comunicari, cursuri, conferinte. Astfel, participantii la un eveniment pot proveni din filiale diferite, iar organizatorii nu pot estima numarul lor exact precum si cerintele lor specifice.

Proiectul s-a nascut din necesitatea fluidizarii comunicatiei in cadrul organizatiei, pentru a elimina sincopele create de metodele necentralizate de comunicare.

Deoarece proiectul isi propune optimizarea unei situatii existente, rezolvarea unui punct slab, putem analiza folosind metodele Pareto sau Ishikawa. Constatand ca nu dispunem de date cantitative despre organizatia clientului, si
pentru a putea determina cauzele si a defini obiectivele, vom realiza o analiza cauza-efect la nivelul activitatii de organizare a evenimentelor.

Subiectul 1.c

Cerinte

Din obiectivele definite la punctul 1.a si din analiza anterioara se releva cerintele - presupuse - ale proiectului:

Deoarece avem cerinte bine definite si concrete, acestea pot fi usor demonstrate prin simpla lor existenta si functionare in cadrul sistemului. Acestea constituie de fapt puncte din viitorul Caiet de Sarcini, cu specificatii clare.

Putem insa presupune existenta unor cerinte (nespecificate de client, dar "de portofoliu" pentru firma noastra) ca:

- Ergonomie: Se poate demonstra prin numarul de operatii necesare pentru a ajunge la zona de interes din site, sau prin compararea cu site-uri unanim recunoscute pentru ergonomia avansata.

- Documentatie: Este in genere un punct dificil de demonstrat, dar in principiu, consideram ca este suficient de adanc dezvoltata atunci cand un grup de utilizatori slab instruiti pot folosi sistemul fara explicatii suplimentare.

Subiectul 1.d

Estimare fezabilitate

Aceasta sectiune, in cazul proiectului nostru trebuie abordata special, deoarece, in prima faza, vom analiza rentabilitatea proiectului pentru firma noastra, si nu din p.d.v.[2] al clientului, acesta fiind un proiect strategic pentru el.

Cu toate ca nu avem determinate exact activitatile din WBS, bazat pe experienta anterioara putem estima cheltuielile astfel:

La care se insumeaza cote din costurile fixe :

- Chirii, costuri sedii: 100 USD/luna pentru echipa;

- Conexiune Internet: 80 USD/luna pentru echipa;

- Amortizari echipamente: 60 USD/luna pentru echipa;

Am prelungit perioada cu 1 luna deoarece ultima plata se realizeaza la incheierea (predarea) definitiva a proiectului.

Pentru calculul IRR avem nevoie de o rata de actualizare, iar din cauza perioadei scurte de timp, valoarea acesteia ar fi prea mica pentru a avea importanta (adica: (1-(15%)/12)^4 ~ 0,951 pentru luna V).

In acest caz vom folosi o valoarea de 1 pentru factorul de actualizare, acest lucru ne-permitand o apreciere in timp a proiectului. Cu toate acestea, putem interpreta ca singura piedica financiara a proiectului este necesitatea folosirii fondurilor din profiturile anterioare (drept imprumut nerambursabil) pentru lunile II si III, pana la incasarea transei a II-a de plata.

Pentru a incerca totusi o apreciere in timp a proiectului, vom analiza din punctul de vedere al clientului, pentru o perioada de 4 ani. Pentru aceasta estimam un eveniment pe saptamana, cu 100 participanti, care economisesc, ca timp si costuri de comunicare, cate 2 USD fiecare: 52 x 100 x 2 ~ 10000 USD/an. Consideram drept costuri o parte din salariul administratorului de sistem - cu aproximatie 10%, deci 6000USD/an.

Aceste cifre le putem folosi pentru calculul ratei interne a fezabilitatii, folosind pentru aceasta un program de calcul tabelar (Excel), in celulele caruia vom introduce formula: (1-IRR)^n).

Valoarea IRR (31%) a fost gasita pentru un NPV maxim negativ, la o perioada de 4 ani considerata pana la urmatorul upgrade al sistemului.

Ca o concluzie, daca pentru client rentabilitatea nu este semnificativa in decizia de pornire a proiectului, pentru firma noastra reprezinta o motivatie serioasa de a-l finaliza cu succes. Cifrele ne arata ca si rentabilitatea este buna, avantajele implementarii sistemului fiind asadar multiple.

Tot pentru client, diferenta dintre costurile implicate de dezvoltarea interna (~ 20-40 USD/h) si contractare intr-o tara din lumea a III-a (~2-5USD/h) este semnificativa - sau chiar determinanta in alegerea contractorului.

Un calcul sumar, cum este cel anterior, dovedeste rentabilitatea industriei software, dovedita dealtfel si de succesul firmelor din domeniu. Observam deasemenea si consumul de resurse umane semnificativ, ceea ce ne aminteste de criza de specialisti din domeniu.

Subiectul 2.a

Structura WBS

Inainte de a incepe descompunerea pe activitati, trebuie sa stabilim limitele proiectului. Mai ales in software, putem mereu fi tentati de aspectele interesante, pierzand astfel din vedere scopul principal al proiectului.

Pentru client, acesta reprezinta doar un sistem de gestiune a evenimentelor.

El nu trebuie sa inglobeze tehnologii noi de comunicare, nici gestiunea salariatilor (desi poate fi conectat la o astfel de baza), nici elemente MapInfo/GPS.

Toate estimarile anterioare s-au bazat pe experiente similare. Pentru o analiza amanuntita trebuie sa tinem cont de specificul firmei noastre, adica realizarea de proiecte software la cererea clientului.

Exista astfel, in acest caz, posibilitatea permanenta a clientul de a interveni cu cerinte noi, prioritati noi in executie, sau alte schimbari sau chiar renuntarea la proiect. Acest fapt, combinat cu prezenta simultana a mai multor proiecte pe "banda de montaj", determina ineficienta unui WBS rafinat pe multe nivele. In plus, modelul de SOW este sub forma unui check-list deschis, pe care clientul il completeaza, iar noi il check-uim pe masura implementarii specificatiilor.

Acestea conditii de lucru sunt valabile datorita dimensiunilor relativ mici ale proiectelor, si colectivelor reduse, prezentand in acelasi timp avantajul unei dinamici ridicate, care este de fapt un factor de competitivitate.

Structura WBS ce urmeaza poate fi considerata incompleta de un perfectionist al organizarii, dar ea prezinta situatia foarte aproape de realitate, si, dupa cum stim, un model are valoare daca se apropie de realitate

Subiectul 2.b

Estimari durate si costuri

Alegem pentru aceste estimari urmatoarele puncte (desi activitatile in domeniu sunt extrem de asemanatoare, am ales trei cat mai diferite intre ele):

- punctul (1.2.) - Analiza cerintelor.

Consideram ca poate fi - si trebuie - facuta de catre PM , acesta cunoscand cel mai bine detaliile, si proiectul fiind suficient de mic. Toate estimarile de mai jos sunt realizate tinand cont de experiente similare anterioare, modularitatea proiectelor software fiind ridicata in general.

Rezulta un cost estimat de 32-74 USD, pentru o perioada de 11-21h.

- punctul (2.4.) - Elemente grafice.

Pentru acestea avem un grafician dedicat, fiind o parte importanta nu neaparat in acest proiect, ci in orice alt proiect web.

Rezulta un cost estimat de 28 USD, pentru o perioada de 16 h.

- punctul (4.1.) - Editare Help.

Rezulta un cost estimat de 56 USD, pentru o perioada de 16 h.

Subiectul 2.c

Apreciere

Am ales special puncte ce pot fi estimate cu usurinta, pentru a creste precizia, si cu toate acestea se observa diferente intre sumele alocate initial (la estimarea fezabilitatii) si cele actuale.

De ex., pentru grafica initiala am rezervat 50 USD, costurile fiind calculate la 28 USD (eroare in plus la estimarea initiala); sau pentru grafica finala 100 USD, in timp ce numai un punct (Help File) consuma 56 USD (probabil vom obtine o eroare in minus).

Fiind vorba de estimari bazate pe experiente anterioare, gradul lor de precizie este inerent mic, ceea ce ne poate duce la recomandarea unor estimari rotunjite in sus pentru proiectele software.

Din aceste exemple rezulta ca estimarea initiala poate varia intr-o plaja de 50-200% din valoarea calculata, deci avem o estimare slaba. Daca am fi dorit o estimare mai buna in faza initiala trebuia sa incepem descrierea WBS si analiza costurilor, si apoi sa suplimentam aceste sume cu un coeficient de risc, de ex. 10%.

Cu toate acestea, datorita plajei de profit, erorile (enorme in cazul unei alte intreprinderi) sunt acceptabile in cazul firmei noastre, iar estimarea actuala poate chiar contribui la viitoarele estimari.

Subiectul 3.a

Riscurile Proiectului

Nu vom incerca o analiza exhaustiva a riscurilor, deoarece un proiect de asemenea dimensiuni nu merita o analiza foarte amanuntita, dar vom surprinde cateva din riscurile cunoscute (chiar intalnite curent).

Se observa ca elelmentele de risc cele mai importante sunt Dificultatile tehnice si Design-ul/Personalul. De fapt, Dificultatile tehnice reprezinta elementul de cercetare propriu-zisa (fiind relativ impredictibil) cuprins in activitatea de programare, in timp ce riscurile cu personalul sunt prezente datorita "migratiei" specialistilor din domeniu.

Subiectul 3.b

Abordarea Riscurilor

Vom trece in revista cateva din modalitatile de aborare (este evident ca intr-un domeniu atat de dinamic, exista multiple modalitati de abordare, inclusiv cele facilitate de distanta fata de client si de gradul redus al pregatirii .).

Exista cazuri cand se pot atenua unele riscuri prin simpla convingere a clientului ca "asa e bine", si ca "noi suntem specialisti si stim mai bine" - ceea ce frizeaza deontologia profesionala, dar reduce dificultatile si riscurile financiare.

In cazul Problemelor cu personalul, planul de contingenta cuprinde:

- realocarea unor programatori mai putin incarcati

- devansarea termenelor la proiectul in curs, sau la altele

- motivarea financiara a celor ramasi pentru a suplimenta eforturile

- preluarea socului de catre PM pana la aplicarea unei solutii.

Aceste masuri pot fi aplicate - si sunt aplicate - in orice faza a proiectului, chiar si pentru motive mai putin grave, ca de ex. "incetinirea" ritmului, sau "plictisul" in cazul unui proiect dificil dar ne-interesant.

Concluzii

Acest proiect este diferit de modelul general, in care se realizeaza o investitie, care apoi se recupereaza. In cazul nostru, noi executam un proiect - ca un serviciu - in timp ce beneficiile pe termen lung (daca exista) le incaseaza clientul, beneficiarul proiectului.

Din punctul nostru de vedere, fezabilitatea unui proiect este mai putin importanta, permitand o marja de eroare considerabila.

Analiza financiara ne arata ca IRR are o valoare rar intalnita in alte ramuri, neajunsurile fiind insa cuantumul mic al sumelor manevrate, si dificultatile de sporire a volumului, dar acestea depasesc cadrul raportului.

Riscurile la care este supus proiectul sunt mari, de multe ori si impactul lor, dar modalitatile de contracarare sunt multiple si variate, astfel incat impactul final asupra proiectului (privit ca finalizare, si nu finalizare in forma initiala) este redus. De multe ori se intampla ca proiectul pornit sa se incheie cu un set complet diferit de specificatii.

Tinand cont de toate acestea, recomand abordarea proiectului cu curaj si incredere, avand in vedere beneficiile obtinute.

Statistici:

Pagini:

Cuvinte:  

Caractere:  

Marime fisier:    Kbytes