Costul planificat al unui produs porgram are la bază consumuri normate. Încă înainte de 1980 erau consemnate în tabele consumuri specifice pentru tipuri de programe, în sensul că erau specificate:
- numărul mediu de linii sursă pentru fiecare tip de funcție de prelucrare;
- durata medie de realizare pe fiecare tip de modul;
- cerințe de calificare a programtorilor;
- mulțimi de coeficienți de importanță pe clase de complexitate;
- număr de repetări ale compilărilor;
- numărul mediu de erori corectate de la o rulare la alta;
- niveluri de calitate pe categorii de module.
Ce care planificau realizarea unui produs program:
- aveau experiența realizării de produse program care deja erau în exploatare;
- cunoșteau suficiente elemente de construcție pentru produse software din aceeași clasă;
- dispuneau de devize planificate și de înregistrări efective pentru produse în uz;
- știau care sunt marjele de siguranță ce trebuie luat pentru a face față noutăților.
Când se trece la planificarea costurilor unui produs software se cunosc:
- problema ce trebuie rezolvată;
- restricțiile privind tehnologia utilizată;
- intervalul de timp disponibil pentru a finaliza;
- disponibilul de bani care să acopere cheltuielile;
- disponibilul de resurse existent în unitatea de dezvoltare;
- capacitatea de a atrage forte și alte resurse suplimentare.
Se pornește de la obiectiv, de la durata disponibilă. Se cunosc etapele ciclului de dezvoltare și în cadrul acestora se cunosc activitățile. Se construiește un tabel cu etape, activități și durate preluate din normative, amendate cu elemente specifice unității de dezvoltare. Activitățile sunt unele succesive, iar altele se desfășoară simultan, existând precedențe clare, căci nimeni nu a coborât din tren la Brașov, fără a fi urcat în vagon fie la București, fie la Ploiești. Planul de realizare al produsului software se completează cu necesarul de resurse, destul de detaliat pe fiecare activitate. Se fac centralizări și rezultă cantități date sub formă de ore de programare, ore de testare, ore de analiză, ore de implementare, ore de depanare, ore de măsurare a calității, ore de asamblare de module și tot așa. Mai rezultă și alte cheltuieli normate pentru utilități, calculatoare, medii de dezvoltare, cheltuieli de transport și multe altele. Cine face devizul de cheltuieli pentru a construi o școală a mai construit multe alte școli înainte și devizul va fi:
- complet;
- riguros;
- realist;
- detaliat;
- credibil;
- convingător.
Pe măsură ce se trece la realizarea produsului se vor înregistra abateri de la durate, de la consumuri, de la calitate. Acestea vor avea niveluri acceptabile, vor merge prin compensare și dacă este nevoie vor exista resurse ca să fie suplimentate forțe în anumite etape pentru anumite activități. Dacă există termene depășite 5%, vor exista li lucrări terminate în avans și se produc compensări. Ideia de bază este de a nu se porni la a planifica costuri pentru produse program fără ca persoanele ce fac așa ceva să nu cunoască temeinic domeniul, adică să nu știe ce este aceea programare, ce implicații are derularea de activități de programare pe bază de specificații și care sunt riscurile care apar mai ales atunci când produsul se realizează cu o tehnică nouă necunoscută niciunui membru al echipei care dezvoltă componente.
Costul planificat al unui produs porgram se aseampnă foarte mult cu costul planificat al unei case. Se pleacă cu un cost optimist de 100.000 de euro și când omul se mută în casă și trage linie vede că totul a costat 250.000 euro. Există mulțumirea că locuința este așa cm a visat-o proprietarul. A dat un ban dar a făcut! Așa și cu un produs software. Are la început un cost planificat optimist, iar când se trage linie el este cu mult mai mare, dar clientul nu mai are cum să dea înapoi că acel produs îi este absolut necesar și a cheltuit deja mult. Unde a mers mia, va merge și suta, vorba cântecului.
În cartea Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli - Fundamentals of Software Engineering, 2nd Edition, Prentice Hall, 1991,624 pg. se arată că ponderile costurilor pe etape = ale ciclului de dezvoltare sunt:
3% analiză
3% realizare specificații
5% elaborare soluție
7% programare
8% testare
7% integrare
67% mentenanță.
De la ele se pleacă atunci când se vrea să se facă defalcarea cheltuielilor dacă și știe valoarea totală a investiției.
- numărul mediu de linii sursă pentru fiecare tip de funcție de prelucrare;
- durata medie de realizare pe fiecare tip de modul;
- cerințe de calificare a programtorilor;
- mulțimi de coeficienți de importanță pe clase de complexitate;
- număr de repetări ale compilărilor;
- numărul mediu de erori corectate de la o rulare la alta;
- niveluri de calitate pe categorii de module.
Ce care planificau realizarea unui produs program:
- aveau experiența realizării de produse program care deja erau în exploatare;
- cunoșteau suficiente elemente de construcție pentru produse software din aceeași clasă;
- dispuneau de devize planificate și de înregistrări efective pentru produse în uz;
- știau care sunt marjele de siguranță ce trebuie luat pentru a face față noutăților.
Când se trece la planificarea costurilor unui produs software se cunosc:
- problema ce trebuie rezolvată;
- restricțiile privind tehnologia utilizată;
- intervalul de timp disponibil pentru a finaliza;
- disponibilul de bani care să acopere cheltuielile;
- disponibilul de resurse existent în unitatea de dezvoltare;
- capacitatea de a atrage forte și alte resurse suplimentare.
Se pornește de la obiectiv, de la durata disponibilă. Se cunosc etapele ciclului de dezvoltare și în cadrul acestora se cunosc activitățile. Se construiește un tabel cu etape, activități și durate preluate din normative, amendate cu elemente specifice unității de dezvoltare. Activitățile sunt unele succesive, iar altele se desfășoară simultan, existând precedențe clare, căci nimeni nu a coborât din tren la Brașov, fără a fi urcat în vagon fie la București, fie la Ploiești. Planul de realizare al produsului software se completează cu necesarul de resurse, destul de detaliat pe fiecare activitate. Se fac centralizări și rezultă cantități date sub formă de ore de programare, ore de testare, ore de analiză, ore de implementare, ore de depanare, ore de măsurare a calității, ore de asamblare de module și tot așa. Mai rezultă și alte cheltuieli normate pentru utilități, calculatoare, medii de dezvoltare, cheltuieli de transport și multe altele. Cine face devizul de cheltuieli pentru a construi o școală a mai construit multe alte școli înainte și devizul va fi:
- complet;
- riguros;
- realist;
- detaliat;
- credibil;
- convingător.
Pe măsură ce se trece la realizarea produsului se vor înregistra abateri de la durate, de la consumuri, de la calitate. Acestea vor avea niveluri acceptabile, vor merge prin compensare și dacă este nevoie vor exista resurse ca să fie suplimentate forțe în anumite etape pentru anumite activități. Dacă există termene depășite 5%, vor exista li lucrări terminate în avans și se produc compensări. Ideia de bază este de a nu se porni la a planifica costuri pentru produse program fără ca persoanele ce fac așa ceva să nu cunoască temeinic domeniul, adică să nu știe ce este aceea programare, ce implicații are derularea de activități de programare pe bază de specificații și care sunt riscurile care apar mai ales atunci când produsul se realizează cu o tehnică nouă necunoscută niciunui membru al echipei care dezvoltă componente.
Costul planificat al unui produs porgram se aseampnă foarte mult cu costul planificat al unei case. Se pleacă cu un cost optimist de 100.000 de euro și când omul se mută în casă și trage linie vede că totul a costat 250.000 euro. Există mulțumirea că locuința este așa cm a visat-o proprietarul. A dat un ban dar a făcut! Așa și cu un produs software. Are la început un cost planificat optimist, iar când se trage linie el este cu mult mai mare, dar clientul nu mai are cum să dea înapoi că acel produs îi este absolut necesar și a cheltuit deja mult. Unde a mers mia, va merge și suta, vorba cântecului.
În cartea Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli - Fundamentals of Software Engineering, 2nd Edition, Prentice Hall, 1991,624 pg. se arată că ponderile costurilor pe etape = ale ciclului de dezvoltare sunt:
3% analiză
3% realizare specificații
5% elaborare soluție
7% programare
8% testare
7% integrare
67% mentenanță.
De la ele se pleacă atunci când se vrea să se facă defalcarea cheltuielilor dacă și știe valoarea totală a investiției.
(17 noiembrie 2017)
No comments:
Post a Comment