Devizul unui proiect informatic

 Devizul unui proiect informatic se construiește nu foarte complicat, dar nici nu trebuie să se ridice pretenția ca la final ceea ce este înscris acolo să fie egal la centimă cu ce s-a cheltuit efectiv pentru a realiza produsul. Se pornește de la ce se vrea să facă produsul.
Se stabilește clasa de complexitate a produsului prin comparație cu altele.
Se folosește un model simplu de estimare costuri folosind complexitatea.
Tot cu un model simplu rezultp nivelul de salarii.
Tot așa se calculează o durată estimată a realizării produsului.
Pornind de la experiența proprie din companie se fac corecții și rezultă un tabel cu principalele cheltuieli, care este acel deviz al proiectului. Cu el se vor purta toate tratativele și de la el se pornește în tot ce se va face, căci modelele acelea sunt destul de riguroase și nu se exagerează la niveluri ndecente de abateri față de nivelul efectiv al cheltuielilor.
Iportant este ca în companie să existe preocupări pe această linie și nu să se lucreze cu ochelari de cal, căci a dezvolta devize de cheltuieli fără o bază realăeste echivalent cu a condamna compania la dispariție, ceea ce pe banii europeni este deja nu o catastrofă, ci un cataclism.

(17 noiembrie 2017)

Devizul unui produs software

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.

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)

Modelarea costurilor software

Modelarea costurilor software este o problemă extrem de complicată, dar dacă este luată mărunțel i se dă de capăt, iar rezultatele vor justifica efortul.
Costul unui produs software include toate cheltuielile care se fac referitoare la acel produs pe tot ciclul de existenă a acestuia, de la momentul de start al procesului de realizare, până la scoaterea din uz și înlocuirea sa cu un alt produs software din altă generație.
Se va vorbi despre:
- costul de realizare;
- costul de implementare;
- costul de exploatare;
- costul de mentenanță;
- costul de reinginerie;
- costul de înlocuire.
În toate cazurile apar cheltuieli legate de:
- salarii;
- calculatoare;
- tehnologii;
- instrumente;
- utilități;
- chirii;
- consumabile;
- management;
- calitate;
- acoperire riscuri.
Modelarea presupune modele. Se identifică mai multe modele în cazul costurilor software.
Modele de estimare a costurilor.
Modele de planificare a costurilor.
Modele de calcul a costurilor.
Modele de simulare a costurilor.
Modele de optimizare a costurilor.
Modele de gestiune a costurilor.
În toate cazurile trebuie să existe foarte multe date despre produse software realizate, produse care sunt în exploatare curentă și despre care se cunosc:
- structura pe module existente;
- număr de linii sursă;
- durată efectivă de realizare;
- volum de resurse pe tipuri;
- niveluri efective de cheltuieli;
- complexitate efectivă;
- niveluri măsurate ale caracteristicilor de calitate;
- abaterile față de nivelurile planificate.
Se fac pentru programe deja aflate în uz baze de date cu cheltuielile planificare și cu cele elective. Se vor calcula diferențele. Toate modelele de costuri vor avea la bază informații reprezentative privind produse software aflate în uz. Cu datele despre acele produse se vor face toate modelele pe care le-am enumerat, folosind un aparat matematic nu prea sofisticat. Bazele de date vor înregistra și elemente legate de comportamentul în timp a produselor software aflate în uz, dar toate datele din acele baze de date se culeg  folosind aceleași proceduri și aparate de măsură, astfel încât să fie:
- complete;
- comparabile;
- corecte;
- omogene.
Existând toate acele adte despre produsele software aflate în uz, orice cibernetician va trece la construirea de modele din oricare dintre tipurile enumerate de mine.
Se notează cu P mulțimea programelor aflate în uz, P = {p1, p2, p3, ..., pn}, unde n este numărul de programe aflate în uz, n trebuie să fie mult mai mare ca 30 pentru a vorbi de o mulțime reprezentativă.

                

în lucru acum

(17 noiembrie 2017)

Costul planificat al unui produs porgram

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.

               

(17 noiembrie 2017)

Recuperarea costurilor software.

 Recuperarea costurilor software este cea mai grea problemă în dezvoltarea informaticii și licențele sunt doar o soluție.
Trebuie să abordăm problematica diferit pe scara istoriei informaticii.
La începuturi  s-a pus problema de a scrie programe numai și numai pentru un utilizator, chiar dacă acesta le rula de mai multe ori schimbând seturile de date. În acest caz, utilizatorul care era și client și plătitor încheia un comntract pentru realizarea programului. Se plătea, așa fel încât în final dezvoltatorul încasa tot ce era de încasat. La fiecare rulare, după ce i se achitase programul pe care el îl realizase, se plăteau toate cheltuielile făcute cu rularea, cu perforarea de cartele cu seturile noi de date, cheltuielile cu hârtia de imprimantă, cheltuielile cu timpul de calculator și dacă era cazul se plăteau și cheltuieli cu mici modificări cerute de client dacă se schimbau elemente simple în algoritm, în structura de pe cartele sau în modul de prezentare a rezultatelor la imprimantă. Programul era al clientului  și acesta îl plătise integral.
Cu timpul, programatorii au identificat și probleme pe care mai mulți clienți ar fi trebuit să le soluționeze. În acest scop programatorii au elaborat programe:
- mai generale;
- mai fiabile;
- mai flexibile;
- mai performante.
Aceste programe prin complexitatea lor au necesitat eforturi de programare cu mult mai mari, deci la produse finite au însemnat produse software foarte scumpe, imposibil de achiziționat doar de către un utilizator. Aceste programe erau destinate rezolvării unor probleme precum:
- programare liniară;
- transporturi optime;
- alocare și nivelare resurse;
- prognoze economice;
- optimizare trasee;
- drum critic;
- optimizarea de stocuri;
- ordonanțarea producției;
- calculul de necesar;
- evidența de personal;
- calculul de salarii;
- evidența contractelor.
Dacă un astfel de produs software ajungea să aibă un preț P, dezvoltatorii făceau de fapt o investiție care trebuia recuperată, ceea ce presupunea studierea grupului țintă al clienților care era estimat ca având N clienți, care în medie fiecare utiliza respectivul produs de M ori pe an. Dezvoltatorul își propunea să recupereze investiția în cel mult K ani. De aici rezulta prețul pe o rulare RP, care era dat de relația:
RP = P/(N*M*K).
Variațiile care apăreau în mod real generau situații foarte diferite de cele planificate la început.
dacă numărul real de clienți NR era mai mare decât numărul planificat N și dacă numărul de rulări reale medii MR era mai mare decât numărul planificat al rulărilor M, menținând prețul pe rulare RP la nivelul planificat, recuperarea costurilor se realiza într-un interval mai mic.
Realitatea era destul de contradictorie și nu de puține ori au fost situațiile în care produsele au fost cotate ca fiind investiții nerentabile pentru că dezvoltatorul nu a decis reducerea arbitrară a nivelului prețului pentru o rulare RP, care ar fi dus la creșterea numărului de clienți, recuperându-și dacă nu toată investiția, cel puțin o parte.
Am cunoscut și cazuri în care dezvoltatorul a construit programe de succes, utilizate pe termen lung și după trecerea celor K ani el mai vindea produsul, încasând în continuare bani pe un program care se amortizase la el în centrul de calcul. Am văzut și situații când un program se realizase doar că un programator s-a ambiționat, iar când l-a lansat nu a avut clienți și a fost o pierdere pe toate liniile.
În ziua de azi problema recuperării este esențială, iar studerea grupului țintă trebuie să fie etapă a ciclului de dezvoltare, căci aplicațiile online sunt investiții și din start recuperarea investiției este legată de:
- numărul de clienți;
- frecvența cu care clienții accesează aplicația;
- valoarea fiecărei  trenzacții;
- viteza de propagare a calităților aplicației în afara grupului țintă;
- nivelul redus al cheltuielilor de mentenanță;
- nivelul pierderilor generate de erorile aplicației în rapor cu clienții.
Acum sunt aplicații online pentru tot felul de plăți, pentru tot felul de alocări în timp real de resurse care își recuperează cheltuielile făcute pentru realizarea lor printr-un procent foarte mic din valoarea tranzacției plăti de intermediar, dar încoporat în tariful, prezentat clientului și acceptat de acesta.

              

în lucru acum

(17 noiembrie 2017)

Chiria pentru un produs software

 Chiria pentru un produs software are forme extrem de variate și a cunoscut evoluții dintre cele mai ciudate. Ideia de a oferi software spre închiriere nu este deloc nouă. Acum de când există Internet, cei ce fac diferite produse informatice le oferă pentru utilizare temporară parcurgând următorul traseu:
- intră pe Internet;
- identifică aplicația;
- se documentează temeinic;
- își fac calculele de utilizare;
- stabilesc intervalul și frecvența;
- selectează opțiuni;
- fac plata;
- primesc o parolă de utilizare;
- folosesc efectiv aplicația;
- la expirarea perioadei accesul nu mai este permis.
Și în vremurile de demult s-au creat la noi produse program, dar ideia de închiriere nu prea se exersa din mai multe motive dintre care enumăr:
- spiritul de proprietate al fiecăruia dintre noi;
- imposibilitatea de a asigura livrarea;
- portabilitatea limitată a produsului;
- necesitatea de a lucra asistat;
- independența precară a produsului față de dezvoltator;
- particularitățile utilizatorului imposibil de customizat;
- fiabilitatea și generalitatea scăzute ale produselor.
Oamenii preferau să cumpere produse-software și nu să închirieze. Existau și situații în care se încheiau contracte pentru a se soluționa probleme cu un produs deja existent, caz în care:
- clientul era instruit asupra produsului;
- clientul venea cu datele de intrare;
- la unitatea de informatică se perforau cartele, se rula programul;
- clientului i se dădea o imprimantă cu rezultate;
- la anumite intervale clientul primea o facută pe care o achita;
- programul rămânea la dezvoltator, clientul doar îl utiliza.
Și acum forma de închiriere tot așa este, căci programul nu este ca un autoturism pe care Hertz îl închiriază la aeroport și clientul se plimbă cu respectiva mașină prin urbe. Programul se găsește la dezvoltator sau la proprietar, săzicem. Clientul introduce datele, lansează programul în execuție și primește rezultatele. Pentru toate acestea el plătește un serviciu, dar acest serviciu se interpretează și ca fiind o chirie, din moment ce pentru scurt timp programul i-a stat la dispoziție. Nu intru acum în detaliile de time sharing, de fire de așteptare și de toată bucărătia oricărui sistem de lucru în rețea. Vorbim așa, de aparențe și clientul trebuie să aibă senzația că plătește și el este servit integral pentru tot ceea ce a plătit, ca să se simtă și el boier. Acum sunt aplicații web care permit:
- stocarea de seturi de date pe termen specificat;
- reluări de probleme cu anumite seturi de date;
- actualizări de seturi de date și lansări de execuții;
- transferul datelor rezultate să devină intrări altundeva.
Toate acestea se fac contra cost și pe perioade pentru care se plătește chirie, căreia unii îi spun așa, mai pe boierește, abonament, ceea ce nu mi se pare exagerat. Față de vremurile de demult, acum aceste abonamente înseamnă un pic altceva. Atunci exista Biblioteca Națională de Programe - BNP care gestiona cam tot ce se crea în zona de software pe plaiurile noastre cele mioritice. Acolo era un catalog și cei ce se abonau la BNP beneficiau de:
- informații despre programele stocate acolo;
- asistență dacă doreau să utilizeze acele programe;
- preluarea de programe scrise de dezvoltatori, cu testare.
Nu vreau să intru în detalii despre modul în care se făceau calculele de rezulta chiria - abonamentul - căci și în zilele noastre plutește o nebuloasă peste acest concept din moment ce unele dintre produsele program au fost făcute pe bază de contract, s-au încasat banii pe ele și ceea ce se închiriază sunt de fapt versiuni mult mai generale, cu interfețe puternice, realizate la produse deja plătite. Se știe că mentenanța este foarte scumpă și ea încorporează și acele elemente care fac din produsul software un ceva care să funcționeze 100% independent de dezvoltator, adică un produs software online care se utilizează de către clienți care plătesc ca și cum produsul a fost realizat de la început în acest scop, deși lucrurile sunt foarte departe de a sta așa. Numai că și aici sunt secrete, ca în vrăjitorie.
Chiria pentru un produs software este un concept care trebuie tratat asemeni rentei pe pământ și nu așa cum se închiriază o casă sau o carte sau o mașină.

               

(20 noiembrie 2017)

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)

Modelul de cost software bazat pe complexitate

Corelația cost-complexitate merită studiată pentru programe, pentru aplicații informatice, pentru aplicații web dar și pentru sisteme informatice. Dacă se dorește studierea corelației cost-complexitate pentru programe se procedează astfel:
- se iau n programe aflate în uz curent de cel puțin un an pentru a exista certitudinea că sunt bune;
- se iau n programe scrise în același limbaj de programare sun o aceeași tehnologie;
- se notează P1, P2, P3,...., Pi, ...., Pn cele n programe;
- se extrag din contabilitate costurile efective COST ale programelor, COST1, COST2, COST3,....,
  COSTi, ...., COSTn:
- folosind un același  program open source se măsoară complexitățile efective ale celor n programe,
  C1, C2, C3,...., Ci, ...., Cn:, în ordine crescă toare C1  > C2  >  C3  > ....  >  Ci, ....  > Cn:
- se desenează un grafic unde pe axa Ox se pun complexități și pe Oy se pun costuri;
- se pun asteriscuri pentru fiecare din programele P la complexitatea și costul corespunzător;
- dacă norul de asteriscuri este liniar se va folosi un model de estimare liniar;
- dacă norul de asteriscuri este exponențial se va folosi un model de estimare exponențial, desigur;
- se folosesc datele grupate din tripletele (Pi, COSTi, Ci), i=1,2,3...,n într-un model de regresie și se
  obțin coeficienții modelului a și b despre care cine are curiozitatea să aprofundeze va vedea cât de      semnificativi sunt aceștia, dar trebuie noțiuni de econometrie solide;
- folosind acești coeficienți se estimează costul COSTk folosind estimarea de complexitate CESTk pentru orice program ce se va construi în viitor în companie în continuare folosind una din relațiile :

COSTk = a * CESTk + b dacă modelul este liniar sau

COSTk = a * exp(  b* CESTk) , k=n+1, n+2, ..., n+m.

Despre aceste modele a realizat studii Paula AOREUTESEI la lucrarea delicență prin 1981 și la teza de doctorat cu titlul Modele de estimare a costurilor software pentru aplicații în rețea,  în anul 2000.
Calitatea modelului este dată de omogenitatea lotului de programe folosite la estimare și la numărul acestora, căci numărul acesta n trebuie să fie mult mai mare ca 16, cum zice teoria statisticii.

Modelul de  cost software bazat pe complexitate este o construcție simplă și utilă, ușor de realizat și implementat în orice companie care dezvoltă software, căci folosind un  xls simplu se rezolvă dacă exuistă două serii de date, cât ai bate din palme.
                

în lucru acum

(17 noiembrie 2017)

Costuri în informatică

Esistă mai multe tipuri de aplicații informatice și anume:

• aplicațiile informatice hobby realizate de programatori de dragul de a soluționa probleme proprii, din pasiune, fără a interesa consumurile de timp și de alte resurse, deci nu interesează cât și nici cum din punct de vedere economic; dacă se finalizează și dacă iese cu o astfel de aplicație în piață succesul și eficiența vin să încununeze o muncă, fără a se face calcule de eficiență economică; 
• aplicația informatică proprie pe care proprietarul o comandă programatorilor proprii sau unei companii dezvoltatoare de software pentru a-i soluționa o problemă, problemă pe care el ca proprietar o consideră esențială și pe care el consideră că prin soluția dată va obține o sserie de avantaje dintre care o parte sunt de natură economică, mai ales ca economie de timp și de personal; calculele sale de eficiență nu sunt decât nște estimări, pentru că activitatea sa de bază nu este de acolo și profitul obținut din activitatea de bază îi permite să cheltuiască și cu achiziționarea de software;
• aplicația informatică investiție realizată atunci când investitorul identifică o problemă pe care nenumărați clienți și-o doresc rezolvată; clienții aceia formează grupul țintă ale cărui nevoi un investitor le identifică și contra cost dorește să le rezolve; investitorul comandă aplicația ca investiție; o plătește dezcvoltatorului de software; acesta o realizează și investitorul devine proprietarul ei; aplicația se implementează în mediul online sau se vide cu licență și fiecare client prin ceea ce plătește permite recuperarea investiției dar și realizarea unui profit important.

Costurile în informatică nu au interesat prea mult în vremurile de demult cum nu interesează nici acum. Informaticienii cred că totul li se cuvine, calculatoare, tehnologii, instrumente, cărți, stagii de instruire, adică fix totul. Este exact situația acelui copil răsfățat pe care nu-l interesează dacă părinții au sau nu au bani, el vrea jucăria și când vrea o obține chiar tăvălindu-se pe jos prin magazin și făcând ca toți dracii. Și la informaticieni tot așa stau lucrurile. Ei s-au considerat dintotdeauna și se consideră și acum deasupra tuturor, deci au toate drepturile din lume să ceară, să ceară și mai ales să li se ofere. Ei nu pun niciodată problema existenței resurselor. Ei nu pun niciodată problema cheltuielilor și nici problema încasărilor. Ei cred că ceea ce fac este implicit excepțional, nemaipomenit, eficient, optim, sursă de profit, drept care cer și cer și cer, fără să se oprească. De cele mai multe ori ei primesc din respect, de teamă, din scârbă, dar primesc și pentru informaticieni acesta este lucrul cel mai important. Ei capătă acele resurse cu care cred că au posibilitatea de a oferi soluții care să leaducă în primul rând lor faimă și în al cincilea rând să soluționeze problemele clienților, pe care oricum 93,87% dintre informaticieni îi disprețuiesc în primul rând că nu se ridică la nivelul lor de inteligență și în al doilea rând pentru că sunt cei cu banii și cei inteligenți fac bani pentru alții, nu au bani lor. Numai după ce au apărut investitorii în informatică și au apărut companii care dezvoltă software ca investiție s-a pus problema costurilor, s-a dezvoltat ideia de eficiență măsurată riguros și mai ales s-a pus problema managementului cheltuielilor, ceea ce i-a revoltat pe informaticienii de rasă. În proiectele informatice sunt marje de siguranță suficiente, acceptate de toată lumea, marje care permit și unele extravaganțe în zona cheltuielilor ineficinte, deci perpetuarea acelui  stau quo al celor ce lucrează în domeniu ca specialiști recunoscuți, un fel de bibelouri fine și fragile.
În informatică au apărut deja:
- costuri de producție;
- costuri de marketing;
- costuri de exploatare;
- costuri de mentenanță;
- costuri cu depanarea;
- costuri cu dotarea;
- costuri de instruire;
- costuri de reinginerie.
Și în informatică se vorbește de:
- planificarea costurilor;
- calculul costurilor;
- estimarea costurilor.
De asemenea, în informatică se înregistrează în contabilitate:
- cheltuieli cu salariile;
- cheltuieli cu echipamentele;
- cheltuieli cu consumabile;
- cheltuieli cu chiriile
- cheltuieli cu utilitățile;
- cheltuieli cu bonusurile;
- cheltuieli indirecte.
Și în informatică se vorbește de:
- planificarea cheltuielilor;
- calculul cheltuielilor;
- estimarea cheltuielilor;
- depășirea cheltuielilor;
- analiza cheltuielilor;
- devizul de cheltuieli;
- defaclarea cheltuielilor.
Acum de când se construiesc aplicații informatice ca obiective de investiții toată lumea vrea profit. Vor profit investitorii. Vor profit companiile de software care realizează aplicațiile pe bază de investiție. Ori profitul rezultă ca diferență între venituri și cheltuieli, dacă și numai dacă venitul este mai mare decât suma cheltuielilor efectuate.
Costurile în informatică sunt esențiale de când aplicațiile informatice sunt obiecte de investiții și nu sunt realizate de o organizație ca ei să-i fie bine, indiferent cât cheltuie pentru acest confort, uneori nejustificat.

                

(17 noiembrie 2017)