Cheltuieli în ciclul de realizare software

  Cheltuielile în ciclul de realizare software sunt și ele de mai multe feluri:
- cheltuieli estimate;
- cheltuieli planificate;
- cheltuieli intermediare;
- cheltuieli efective;
- cheltuieli corectate;
- cheltuieli postacalcul.
Există nenumărate criterii de clasificare a cheltuielilor, dar oricum le-am lua, este important ca ele să se facă dacă:
- există banii;
- se dau cu documente;
- sunt pentru realizarea obiectivului;
- nu sunt nesimțite;
- au destinația clară;
- nu sunt umflate;
- se încadrează în proiect;
- nu depășesc nivelul planificat;
- slujesc proiectului.
Când se realizează un produs software se vorbește de:

• nivelul estimat al cheltuielilor, nivel ce corespunde unei imagini virtuale a produsului așa cum o vede cel care dorește să angreneze resursele unei echipe de analiști și de programatori în vederea soluționării problemei date; pentru a stabili acest cost se au în vedere multe aspecte precum: produse program similare și prețurile lor, condițiile concrete din companie, exigențele formulate de client și experiența celui care ia contact prima dată cu beneficiarul; deci produsul nu există, există numai obiectivul, un termen de predare și există informații despre produsele program existente în târg și care dacă nu sunt similare, măcar sunt pe aproape ca nivel de complexitate cu ceea ce se va realiza;
• nivelul planificat al cheltuielilor care alcătuiesc un deviz și care au la bază calcule destul de detaliate pornind de la complexitatea problemei, termenul de implementare și mai ales dde disponibilul de resurse din compania care va dezvolta produsul software; dacă un sistem informatic existent al unei organizații cu o complexitate cunoscută a avut un nivel efectiv al cheltuielilor de deviz de YY milioane lei, bineânțeles că un sistem informatic care se proiectează pentru o organizație de 1/4 din complexitatea celei cu care se va face comparația nu va avea un nivel planificat al chetulielor care să depășească  ZZ = 0,35 * YY; și așa depășirea de 10% trebuie argumentată, căci la 0,25 de complexitate trebuie să fie și cheltuielile planificate tot o pătrime;
• nivelul din contract al ceheltuielilor are o istorie cel puțin ciudată și este rezonabil să se cunoască toate poveștile legate de licitații unde prețurile trebuie să fie mici pentru a le câștiga, despre cazurile de forță majoră ce permit încheierea de contracte adiționale și mai ales de riscurile de a nu avea resurse de a duce lucrările la finalizare și produsul software nu se va realiza cu implicații dramatice pentru toată lumea; în cazul în care se fac subcontractări lucrurile au o abordare diferită căci în informatică tele-lucrul este la ordinea zilei și munca la negru tot așa; am lucrat programe și înainte de 1989 și după și experiența îmi arată că cel mai bun lucru este ca atunci când se merge la un contract este bine să existe cel puțin 60% din produsul software și în aceste condiții cheltuielile din bontract seamănă cu un bonus;
• nivelul efectiv al cheltuielilor reflectă numai parțial adevărul despre ce și cum se realizează produsul software, căci acolo apar nenumărate cheltuieli care dacă sunt luate la puricat nu s-ar justifica în vecii-vecilor, mai ales când sunt înghesuite la cheltuielile generale ale companiei, unde intră nenumărate extravaganțe la care toată lumea închide ochii; cine stă de vorbă cu un contabil deștept primește consiliere încât și 50% din cheltuielile de pe lângă proiect se includ fără bătăi de cap în cheltuielile produsului software și toată lumea este fericită foc nevoie mare; să nu-mi spună mie nimeni că chestiile cu parandărătul sunt povești de adormit copiii sau că chestiile cu plățile amânate cu câte 6 luni nu includ în ele tot felul de inflații și tot felul de rostogoliri, că deja mă supăr urât de tot.

Fără a greși fundamental trag concluzia că nivelul cheltuielilor oricare ar fi el ca tip, ar trebui să reflecte efortul de realizare a produsului software, dar datorită unor factori perturbatori acest nivel se depărtează destul de mult de adevăr și dă o imagine strâmbă din care toată lumea face pe pudica, dar fiecare încearcă să-l păcălească pe celălalt, crezând că el este mai deștept decât cel pe care îl are în față și cu nerușinare îl numește partener de afaceri, când în realitate îl consideră prostul său de serviciu. Am simțit de nenumărate ori aceastăsenzație mai ales atunci când am lucrat în echipe ca pălmaș și cei de la analiză luau 80% din contract șia cei de la programare luau 20% în condițiile în care făceau și analiza căci așa-zișii analiști erau persoane care nu știau prea bine cum se numesc, dar ridicau pretenții pentru niște dosare făcute cu povești, cu desene din care nu se scriau programe.
Cheltuielile în ciclul de realizare software se aproximează grosier pentru că toată lumea crede în mod eronat că orice produs software este unicat 100% deși nu este așa din moment ce modulele sale se regăsesc prin reutilizare în multe altre rpoduse software și ele vândute neinițiaților tot ca unicate.

Defalcarea cheltuielilor pe fazele ciclului de realizare se regăsește în deviz prin eșalonarea activităților și punerea acesora în corespondență cu salariile care de regulă au ponderea cea mai importantă. Cum diviziunea muncii este puțin adâncită în cadrul etapelor din ciclul de realizare se merge pe niveluri aproximate și graful GANTT al activităților este cel care dă și agregarea de cheltuieli pe etape, fiind vorba de o punere în corepondență mecanică, fără o justificare fină.
Înainte de 1989 când scriam un program mă gândeam cam cum să-l fac în ideia de reutilizare. Scrisesem cartea TROGRAMAREA STANDARD și am aplicat multe chestii din ea. Aveam biblioteci de programe pe cartele și era pentru mide destul de distractiv să duplic cartele pentru a le insera printre secvențele noi, specifice problemei de rezolvat. Îmi aduc aminte că-mi făcusem niștye subprograme FORTRAN de calcule matriceale și nu mai era nevoie de a le duplica pentru că le mutam dintr-o cutie de cartele la alta, chiar dacă în noul program nu se apelau foarte multe dintre subprogramele din pachetul de cartele. Tot ce trebuia să fac era să știu bine parametrii și mai ales să fiu sigur că subprogramele mergeu brici, că altfel era jale mare. Costul era cost, de produs nou.

                

în lucru acum

(17 noiembrie 2017)