Devizul unui produs software nu se construiește pe loc gol. În cărțile de Software Engineering se găsesc destul de multe detalii cae vor fi considerate puncte de placare. Cel ce calculează devize trebuie și el să muncească din greu pentru a avea în final un deviz:
- realist;
- credibil;
- detaliat;
- complet;
- acceptat;
- bun.
Când se construiește un deviz de estimare a costurilor:
- produsul software nu există;
- se folosește experiența anterioară;
- nivelurile dau o imagine cât mai realistă a ceea ce se va întâmpla;
- se definesc categoriile de cheltuieli;
- se stabilesc resursele antrenate și se estimează consumurile.
Se parcurg următoarele etape înainte de a începe să se construiască devizul de estimare:
- se definește problema de rezolvat;
- se studiază piața de produse software;
- se definește obiectivul de îndeplinit;
- se precizează nivelul de generație software al produsului.
Abia după aceea, după ce există convingerea că produsul software trebuie realizat și nu construit, în funcție de obiectivul stabilit și de generația de software precizată, prin comparație cu ceea ce există în piața de software și ținând seama de experiența proprie a dezvoltatorului se estimează un cost al produsului care să includă cheltuieli dar și profitul dezvoltatorului, precum și alte elemente pe care dezvoltatorul consideră că este necesar să le reflecteze acel cost, ca activitatea sa să rămână în zona de eficiență specifică oricărei organizații din domeniul informaticii de tip industrial.
După ce s-au clarificat aceste elemente, mai ales de către investitor, acesta face o ofertă la un nivel acceptabil și pentru dezvoltator și numai după aceea se trece la structurarea unui dezviz de cheltuieli estimate.
În cărțile de Software engineering esistă:
- etapele ciclului de dezvoltare produse software;
- ponderile cheltuielilor pe etape;
- modele de estimare a costurilor funcție de complexitate;
- algoritmi de estimare a coeficenților din modele;
- algoritmi de alegere a modelului pentru estimarea costului.
dacă acele cărți de Software Engineering nu sunt satisfăcătoare, acele ponderi și le calculează fiecare dezvoltator în parte. În acest sens, dezvoltatorul ia N produse software finalizate și aflate în uz curent, P1, P2, P3, ..., Pk, ...., PN. Extrage din rapoartele de cheltuieli efective cheltuielile pentru etapele E1, E2, E3, .....Ej....., EM, adacă la el se lucrează pe un ciclu de dezvoltare format din M etape.
Se va construi o matrice a cheltuielilor cu N linii și M coloane unde Cik arată nivelul cheltuielilor din etapa Ek pentru produsul Pi.
Se calculează sumele pe linii SLi și sumele pe coloane SCk și un total general TG. Se calculează ponderile pi = SLi / TG și cu ele se va lucra în continuare. Alții lucrează cu costurile medii pe etape și cu costul mediu al unui produs software, dar tot aici se va ajunge pentru că numărul de programe este același.
Se va presupine că se avansează un cost CPN al noului produs software pe care este dispus investitorul să-l plătească. dacă profitul dezvoltatorului este x% din investiție, rezultă ce se calculează lejer nivelul cheltuielilor de producție al produsului nou CPPN = CPN * (1 - x/100).
Costul cheltuielilor CEPNi pentru etapa Ei se obține din relația:
CEPNi = pi * CPPN.
Dezvoltatorul are pentru realizarea oricărui produs software un graf GANTT din care extrage:
- lista de activități;
- eșalonarea activităților;
- resursele necesare.
dacă durata de realizare este exprimată în ani, devizul de cheltuieli va fi construit prin defalcarea cheltuielilor pe fiecare an. Se face defalcarea ținând seama de logica activităților din graful GANTT, adică:
- analiza, schema soluției, resursele se stabilesc primele;
- realizarea modulelor se face în a doua grupă de activități;
- testarea și finalizarea documentației se face penultima;
- implementarea și instruirea utilizatorilor se face ultima.
Acestea se vor trece în treaptă pe perioadele de realizare a produsului software, devizul avâd defalcate câte perioade sunt stabilita. De exemplu, dacă un produs software se realizează în 3 ani, devizul va conține:
- o coloană în care se specifică etapa Ei și resursele;
- o coloană pentru datele cantitative din primul an;
- o coloană pentru nivelurile valorice ale cheltuielilor din primul an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din primul an;
- o coloană pentru datele cantitative din al II-lea an;
- o coloană pentru nivelurile valorice ale cheltuielilor din al II-lea an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din primul an;
- o coloană pentru datele cantitative din al III-lea an;
- o coloană pentru nivelurile valorice ale cheltuielilor din al III-lea an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din al III-lea an;
- o coloană cu totalurie cheltuielilor din cei 3 ani pe etape și un total general.
Aceeași gândire se pune în operă dacă se lucrează la nivel de trimestru cu defalcarea.
Ideia este să nu se dezvolte un deviz prin defalcare împărțind egal sumele pe ani și devine cu atât mai dramatic dacă se face împărțirea egală pe etape a cheltuielilor, știut fiind faptul că orice carte de Software Engineering arată că ponderea etapelor este diferită, chair dacă unii cred că analiza este foarte importantă, niciodată ea nu va depăși între 30% și 40% din proiect. dacă se alocă 40% nivelul de detaliere a soluției trebuie să fie atât de mare încât scrierea de texte sursă să devină ceva mai mult mecanic decât de concepție.
De aici va construi pentru activități un tabel în care pe linii se află etapele și sub fiecare etapă se dezvoltă resursele necesare, iar pe coloane se pun lunile necesare realizării proiectului. La intersecția etapă-resursă și coloană-lună se vor trece cheltuielile estimate necesare astfel încât totalul pentru etapa Ei să aibă totalul egal cu CEPNi.
Nu am scris aici nimic despre dependența structurii devizului de tehnologia utilizată în dezvoltarea produsului, de disponibilul de resurse. Oricum, dezvoltatorul va trebui să gândească întreg procesul ca alocare și nivelare de resurse și nu de reutilizare a resurselor disponibile, chiar dacă acestea nu corespund tehnologiei care a fost aleasă pentru a dezvolta produsul software. Și aici este vorba de un management specific lucrului în echipă, fie în regim industrial fie nu, dar 100% disciplinat.
Devizul unui produs software este o construcție complexă care dă viziunea de realizare a produsului, în condiții impuse de obiectivul definit, de resursele existente la dezvoltator și de resursele financiare puse la dispoziție de investitorul-beneficiar.
- realist;
- credibil;
- detaliat;
- complet;
- acceptat;
- bun.
Când se construiește un deviz de estimare a costurilor:
- produsul software nu există;
- se folosește experiența anterioară;
- nivelurile dau o imagine cât mai realistă a ceea ce se va întâmpla;
- se definesc categoriile de cheltuieli;
- se stabilesc resursele antrenate și se estimează consumurile.
Se parcurg următoarele etape înainte de a începe să se construiască devizul de estimare:
- se definește problema de rezolvat;
- se studiază piața de produse software;
- se definește obiectivul de îndeplinit;
- se precizează nivelul de generație software al produsului.
Abia după aceea, după ce există convingerea că produsul software trebuie realizat și nu construit, în funcție de obiectivul stabilit și de generația de software precizată, prin comparație cu ceea ce există în piața de software și ținând seama de experiența proprie a dezvoltatorului se estimează un cost al produsului care să includă cheltuieli dar și profitul dezvoltatorului, precum și alte elemente pe care dezvoltatorul consideră că este necesar să le reflecteze acel cost, ca activitatea sa să rămână în zona de eficiență specifică oricărei organizații din domeniul informaticii de tip industrial.
După ce s-au clarificat aceste elemente, mai ales de către investitor, acesta face o ofertă la un nivel acceptabil și pentru dezvoltator și numai după aceea se trece la structurarea unui dezviz de cheltuieli estimate.
În cărțile de Software engineering esistă:
- etapele ciclului de dezvoltare produse software;
- ponderile cheltuielilor pe etape;
- modele de estimare a costurilor funcție de complexitate;
- algoritmi de estimare a coeficenților din modele;
- algoritmi de alegere a modelului pentru estimarea costului.
dacă acele cărți de Software Engineering nu sunt satisfăcătoare, acele ponderi și le calculează fiecare dezvoltator în parte. În acest sens, dezvoltatorul ia N produse software finalizate și aflate în uz curent, P1, P2, P3, ..., Pk, ...., PN. Extrage din rapoartele de cheltuieli efective cheltuielile pentru etapele E1, E2, E3, .....Ej....., EM, adacă la el se lucrează pe un ciclu de dezvoltare format din M etape.
Se va construi o matrice a cheltuielilor cu N linii și M coloane unde Cik arată nivelul cheltuielilor din etapa Ek pentru produsul Pi.
Se calculează sumele pe linii SLi și sumele pe coloane SCk și un total general TG. Se calculează ponderile pi = SLi / TG și cu ele se va lucra în continuare. Alții lucrează cu costurile medii pe etape și cu costul mediu al unui produs software, dar tot aici se va ajunge pentru că numărul de programe este același.
Se va presupine că se avansează un cost CPN al noului produs software pe care este dispus investitorul să-l plătească. dacă profitul dezvoltatorului este x% din investiție, rezultă ce se calculează lejer nivelul cheltuielilor de producție al produsului nou CPPN = CPN * (1 - x/100).
Costul cheltuielilor CEPNi pentru etapa Ei se obține din relația:
CEPNi = pi * CPPN.
Dezvoltatorul are pentru realizarea oricărui produs software un graf GANTT din care extrage:
- lista de activități;
- eșalonarea activităților;
- resursele necesare.
dacă durata de realizare este exprimată în ani, devizul de cheltuieli va fi construit prin defalcarea cheltuielilor pe fiecare an. Se face defalcarea ținând seama de logica activităților din graful GANTT, adică:
- analiza, schema soluției, resursele se stabilesc primele;
- realizarea modulelor se face în a doua grupă de activități;
- testarea și finalizarea documentației se face penultima;
- implementarea și instruirea utilizatorilor se face ultima.
Acestea se vor trece în treaptă pe perioadele de realizare a produsului software, devizul avâd defalcate câte perioade sunt stabilita. De exemplu, dacă un produs software se realizează în 3 ani, devizul va conține:
- o coloană în care se specifică etapa Ei și resursele;
- o coloană pentru datele cantitative din primul an;
- o coloană pentru nivelurile valorice ale cheltuielilor din primul an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din primul an;
- o coloană pentru datele cantitative din al II-lea an;
- o coloană pentru nivelurile valorice ale cheltuielilor din al II-lea an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din primul an;
- o coloană pentru datele cantitative din al III-lea an;
- o coloană pentru nivelurile valorice ale cheltuielilor din al III-lea an;
- o linie care va conține undeva în dreapta totalul cheltuielilor etapei Ei;
- o linie finală unde acolo unde sunt cheltuielile etapelor se calculează costul total din al III-lea an;
- o coloană cu totalurie cheltuielilor din cei 3 ani pe etape și un total general.
Aceeași gândire se pune în operă dacă se lucrează la nivel de trimestru cu defalcarea.
Ideia este să nu se dezvolte un deviz prin defalcare împărțind egal sumele pe ani și devine cu atât mai dramatic dacă se face împărțirea egală pe etape a cheltuielilor, știut fiind faptul că orice carte de Software Engineering arată că ponderea etapelor este diferită, chair dacă unii cred că analiza este foarte importantă, niciodată ea nu va depăși între 30% și 40% din proiect. dacă se alocă 40% nivelul de detaliere a soluției trebuie să fie atât de mare încât scrierea de texte sursă să devină ceva mai mult mecanic decât de concepție.
De aici va construi pentru activități un tabel în care pe linii se află etapele și sub fiecare etapă se dezvoltă resursele necesare, iar pe coloane se pun lunile necesare realizării proiectului. La intersecția etapă-resursă și coloană-lună se vor trece cheltuielile estimate necesare astfel încât totalul pentru etapa Ei să aibă totalul egal cu CEPNi.
Nu am scris aici nimic despre dependența structurii devizului de tehnologia utilizată în dezvoltarea produsului, de disponibilul de resurse. Oricum, dezvoltatorul va trebui să gândească întreg procesul ca alocare și nivelare de resurse și nu de reutilizare a resurselor disponibile, chiar dacă acestea nu corespund tehnologiei care a fost aleasă pentru a dezvolta produsul software. Și aici este vorba de un management specific lucrului în echipă, fie în regim industrial fie nu, dar 100% disciplinat.
Devizul unui produs software este o construcție complexă care dă viziunea de realizare a produsului, în condiții impuse de obiectivul definit, de resursele existente la dezvoltator și de resursele financiare puse la dispoziție de investitorul-beneficiar.
Pe măsură ce se realizează produsul software și se colectează cheltuielile se construiește un tabel după structura devizului inițial cu cheltuielile efectiv făcute de dezvoltator. Această construcție se face în concordanță cu cheltuielile estimate și dezvoltatorul trebuie să gestioneze diferențele, iar acolo unde cheltuielile efective depășesc cheltuielile estimate, fie se merge prin compensări, fie se fac acte adiționale, pentru a depăși situații critice generate de lipsa fondurilor pentru continuarea procesului de producție.
(28 noiembrie 2017)
No comments:
Post a Comment