Achiziționarea resurselor IT

Achiziționarea resurselor IT este acum în anul 2017 floare la ureche. totul este chestiune de bani și nu de bani mulți, dar bani cheltuiți cu cap. Așa cum stau lucrurile, sunt sigur că 91,37% din calculatoarele care stau pe birouri azi nu ar trebui să depășească facilitățile unui PC 386 pentru că:

- aplicațiile ce se fac sunt foarte modeste;

- se utilizează la e-mail și jocuri;

- nu se crează pe ele software;

- nici tranzacții în timp real nu se fac.

În vremurile de demult erau câteva limbaje de programare ASSIRIS,  FORTRAN și COBOL. Deci o lucrare se realiza într-un astfel de limbaj, mai ales că era dependentă alegerea de ceea ce stăpânea programatorul.Tot atunci se rula ori pe un IBM 360 sau IBM 370 sau pe un calculator FELIX C 256, iar după 1977 a venit și nimicalculatorul I 100. Opțiunea era să se scrie program pe foi de programare, să se perforeze cartele și fluxul era cel clasic. Deci programarea era pe bază de reguli impuse și nici nu erau reguli, ci erau restricții dure și de neînlocuit.

Am introdus ca etapă achiziționarea resurselor IT, căci acum lucrurile stau cu totul altfel. A elabora un produs software trebuie privit ca activitate de alocare și nivelare de resurse. Dacă problema necesită a fi soluționată folosind o anumită tehnologie, acea tehnologie va fi folosită. Dacă modulele trebuie scrise într-un anumit limbaj, acel limbaj trebuie folosit și nu altceva. Dacă totul impune folosirea unui anumit calculator cu o anumită memorie RAM acel calculator va fi întrebuințat. dacă pentru a elabora un produs software trebuie 15 programatori C++, 2 programatori de C# și 3 programatori care lucrează la perfecție cu ORACLE & ERP, se merge în piață și sunt selectați exact acei programatori. Este exact cum face gospodina care vrea să facă cozonac. Ea are nevoie de un kg de făină trei nule, 500 gr zafăr, 6 linguri de ulei, 12 ouă, 1/2l lapte, drojdie. Ea nu va pune niciodată în loc de făină tărâțe, în loc de zahpr sare și în loc de ouă, brânză telemea de oaie. Deci dacă o gospodină face alocare și nivelare optimă de resurse pentru a-i ieși cozonacul, exact acestu lucru se va produce și la realizarea unui produs software. Acum cu cloud computing, acest deziderat a devenit realitate și încă la prețuri decente, deci:

- cantitatea optimă, exact cât e necesar;

- momentul optim, exact când trebuie;

- costul optim, exact la prețul pieții;

- procesul optim adică respecând standarde.

Asta înseamnă  achiziționarea resurselor IT!

în lucru acum

(29 noiembrie 2017)

Alegerea grupului țintă

Alegerea grupului țintă este o problemă nouă. În vremurile de demult grupul țintă era format din cel ce solicita să se scrie programul. Uneori mai interveneau ca părți ale grupului țintă cei la care ajungeau paginile de inprimantă. Îmi amintesc cum înainte de 1989 cei care păsoreau telegoanele PTTR-ul aveau un centru de calcul care tipăreau niște catastife unde dacă doreai săți plătești telefonul musai trebuia să ai factură că altfel nu te găseau. Erau așa de rudimentari încât nu făcuseră căutare după numărul de telefon, așa cum era logic sau după nume.

Și cei ce se ocupau de stocurile de materiale, dacă aveau proasta inspirație să folosească codul CAEN nu mai reușeau să actualizeze stocurile în vedii vecilor. În mod normal, grupul țintă trebuia să fie studiat și să fie ajutat să lucreze. A sorta materialele pe depozite era ceva banal, dacă apărea în înregistrare un câmp cu depozitul. Dacă se utilizau și niște coduri locale era și mai bine, iar codurile CAEN să fi fost pentru comenzile din afara uzinei ca să nu se facă confuzie. 

Acum este fundamental să se cunoască grupul țintă care trebuie definit prin:

- număr;

- omogenitate;

- cultură;

- educație;

- vârstă;

- abilități;

- experiență;

- interese;

- obiective;

- venituri;

- proprietăți;

- ocupație.

Grupului țintă trebuie să i se ofere exact ceea ce el are nevoie. Cine face studiul grupului țintă trebuie să știe statistică, trebuie să facă sondaje și trebuie să verifice ipoteze. Concluziile trase de cei ce studiază grupul țintă dau informații prețioase referitoare la:
- funcționalitățile aplicației;
- vocabularul utilizat în interfață;
- frecvenșa de utilizare a aplicației;
- nivelul total al tranzacției;
- durata de recuperare a investițieei;
- structura interfeței;
- nivelul de complexitate al prelucrărilor.
Am văzut o aplicație pentru o primărie cu rezervarea la audiențe și cel ce făcuse aplicația nu studiase niciun grup țintă pentru că butoanele erau așa de mici că nu se selectau corect. În condițiile când acea aplicație ar fi fost utilizată de persoane în vârstă este clar că era inutilizabilă. Am văzut și magazine virtuale extrem de dificil de accesat, drept care oamenii abandonează folosirea lor.
În vremurile de demult studierea grupului țintă m-a dus către cunoașterea:
- dicersității dimensiunilor problemelor;
- ordinelor de mărime a datelor de intrare;
- tipurilor de erori și insistarea pe anumite validări;
- flexibilitatea combinării apelurilor de proceduri;
- nivelul de detaliere a mesajelor de eroare;
- modul de prezentare a rezultatelor finale.
Este știut faptul că un beneficiar obișnuit cu anumite structuri de rapoarte va aprecia și mai mult dacă noul prorgam va afișa rapoarte cu structuri asemănătoare celor pe care el le cunoaște. Și la interfețe tot așa se pune problema. Clientul va aprecia acea interfață care seamănă izbitor cu alte interfețe și care doar în punctele absolut specializate va avea diferențe semnificative, acceptate de client.

(29 noiembrie 2017)

Implementarea

Implementarea ăn vremurile de demult era o operație distinctă. Numai unii mergeu să implementeze. Ei știau produsul și știau cum să-l abordeze pe beneficiar. Sunt situații când la implementare beneficiarul își aduce aminte că programul ar mai trebui să facă și asta și asta și asta. dacă programul este bine scris, implementarea nu ridică mari probleme. dacă programul nu este chiar bine scris, implemenatrea mai include încă aspecte de depanare, căci testarea se face cu datele reale ale clientului.

În vremurile de demult, când clienții nu aveau calculatoare, implementarea se făcea tot la dezvoltator și corespundea rulărilor cu datele clientului. Clientul aducea foile de programare. Implementarea se făcea de dezvoltator la dezvoltator.

Acum când diviziunea muncii s-a adâncit și există meseria de specialist în implementări, deja problema este alta. Să ne amintim cum în anii din urmă lansarea unei versiuni de Windows era mare maestru cel care știa să instaleze sistemul, adică să facă implementarea. Acum lucrurile arată cu totul altfel și oricine dorește să instaleze un sistem de operare o va face chiar fără mari dificultăți.

Consider că încă mai apar probleme de implementare în cazul aplicațiilor din ziua de azi care au niște minusuri. orice aplicație performantă se instalează, nu se implementează, căci a instala înseamnă a prelua pur și simplu, pe când a implementa înseamnă a intra în bucătăria aplicației. 

Cel mai dificil era în bremurile de demult când cineva dorea să folosescă programe făcute de alții și să le implementeze. Acele programe erau foarte bune acolo, dar prin implementare la un alt utilizator precis apăreau niște chichițe și numai cel ce dezvoltase modulele buclucași le dădea de rost.

(29 noiembrie 2017)

Semnarea contractului

Semnarea contractului nu e treabă ușoară. Îmn opinia mea, contractul:

- se construiește de specialiști;

- este văzut de avocați;

- este semnat de manageri;

- este asumat de dezvoltator.

Contractul conține ceea ce trebuie făcut. Din exces de zel dezvoltatorul este tentat să lase prudența deoparte și să pună în contract lucruri pe care nu prea este în stare să le realizeze, precum:

- nivel de calitate peste cel al produselor similare;

- termene fantezist de scurte;

- utilizarea de tehnologii pe acre nu le stăpânește;

- multe servicii oferite gratuit după implementare; 

- nivel imposibil de promptitudine în depanare;

- cost de livrare la cheie insuportabil de mic.

Unii dezvoltatori acceptă cu prea mare ușurință condiții impuse de beneficiar, doar din dorința de a câștiga contractul, de a semna și de a începe munca. Aceștia să nu uite că atunci când semnează un contract fac un pas decisiv și își asumă riscuri, inclusiv de a fi târîți prin tribunale și de a plăti despăgubiri uriașe pentru nerespectarea termenilor puși din prea mult entuziasm în contracte.

Experiența mi-a arătat că am purces la a încheia un contract când deja aveam peste 60% din produsul software gata și doar trebuia să pun moțul pe prăjitură. Cine o ia de la zero mare greșeală face, mai ales dacă:

- nu are echipa consolidată;

- nu stăpânește standardele;

- nu știe management;

- nu are preocupări în zona calității;

- deține arta risipei de resurse;

- nu exersează exigență la maxim.

Eu am avut o regulă, ca la frizer. Întâi mă tunzi și după aceea îți plăresc. De aceea am exersat tot timpul în proiecte predarea-primirea cu verificare la sânge și numai după aceea am dat recompensa, ca la dresaj. Ca să fiu sigur, unele module le-am lansat la simultan la jumătate.ro cum se zice și dacă aveam două module bune, alegeam unul dintre ele. Nu m-am lăsat niciodată la mâna cuiva, mai ales că programatorii au niște talente ale lor. Ideia este să nu te angrenezi ca manager în proiecte pe care tu nu le stăpânești și din punct de vedere tehnic. Așa zice experiența mea și nu am avut dureri de cap. Trebuie să atrag atenția aici ca în contract să apară clar dacă se vrea sau nu auditare. Dacă da, costul produsului software va fi cu totul altul, adică mult mai mare, să zicem cu 50%, căci auditul are el costul lui, iar la audit nu merge orice produs software, ci uun produs software special.
Întocmirea unui contract se face cu asistența juridică și din partea dezvoltatorului. Semnarea contractului este un moment important și realismul abordării este cel care dă calitatea produsului software. Când există un contract ferm sunt excluse improvizațiile și bâjbîielile la dezvoltator.

(29 noiembrie 2017)

Asamblarea modulelor

Asamblarea modulelor este în opinia mea un lucru esențial care va avea succes dacă și numai dacă modulele sunt toate de calitate, testate și preluate cu verificare de către cel ce face asamblarea. Aveam o prietenă makedoancă, femeie foarte citită care mi-a zis: 

- Noi makedonii avem o vorbă: dacă într-o oală de ciorbă pui o lingură de kk, totul kk se numește.

Am băgat la cap această zicere de nota 1.000 și mi s-a dovedit că așa stau lucrurile. dacă vrei să compromiți o lucrare, doar un modul nu trebuie să fie foarte bun și edificiul se prăbușește cât ai bate din palme.

În vremurile de demult când eu eu arbitram, eu șutam și tot eu dădeam cu capul, adică eu eram programatorul orchestră, am aplicat cu sfințenie regula de aur a calității tuturor componentelor și nu am avut surprize. Când am lucrat în echipe mai amri și eram la execuție contribuiam cu module pe care le testam de 2.000 de ori și nu mi s-a întâmplat să rpșesc din cauză că s-a întrerupt prelucrarea din cauza mea. Nu că eu aș fi făcut componentele cele mai complexe. dar se știe că buturuga mică răstoarnă carul mare dacă e pusă unde nu trebuie în drum. Când am devenit eu cel care preluam componente, dar eram ajutat la samblare, am testat ceea ce primeam. M-am luat de cap prima dată. căci lumea nu era obișnuită și cam lucra în dorul lelii. Când au văzut programatorii că nu au loc de întors au scăzut foarte mult modulele cu non-calitate și asamblarea s-a făcut normal.

Sunt adeptul asamblării pe niveluri de sus în jos, cu testare. Numai dacă totul merge perfect se trece la nivelul următor. Trebuie testate toate ramurile arborescenței.

Mi s-a întâmplat că chiar așa procedând să am surprize, căci nimeni nu este perfect, deci nici eu, vai mie...

Acum când se lucrează în regim aproape industrial, dacă se stabilesc reguli clare de scriere module și mai ales de testare și predare, așamblarea se va face fără dureiri prea mari. Să nu uităm că acum aplicațiile se pun pe server și funcționează independent de dezvoltator și ceea ce este și mai grav, generează alocări în timp real de resurse, da de exemplu transferuri bancare.

în lucru acum

(29 noiembrie 2017)

Reingineria

Despre reingineria se vorbește foarte mult dar nu-mi amintesc să fi văzut aplicații informatice de anvergură care să fi traversat un proces de reinginerie. Probabil aplicația de salarii de acum va traversa acest proces, deși tare îmi este teamă că mulți se vor apuca s-o ia de la zero, pentru că:

- varianta de dinainte are o tehnologie vetustă;

- documentația este incompletă;

- cei ce au realizat-o nu mai lucrează în companie;

- stilul de programare este diferit de ceea ce e acum;

- există bani pentru a face un nou produs software;

- noua soluție ca încorpora cu siguranță tehnologii din 2015.

Prin decembrie 2014 a venit la mine un prieten și mi-a zis că cel mai tare site este cel unde se ajunge la informație în două click-uri. Pe site ionivan.ro se ajungea foarte diferit, dar erau și cazuri în care se ajungea și prin 4 click-uri. Atunci mi-a bubuit prin cap ideia să dezvolt și eu un proces de reinginerie. Drept care:

- am făcut un inventar al fișierelor;

- am analizat tipologiile de fișiere;

- am gândit o strategie de lucru;

- a stabilit o interfață;

- am adoptat ideia celor două click-uri;

- m-am pus pe treabă;

- a 1 ianuarie 2015 am inaugurat;

- totul este  rezultatul reingineriei.

M-am apucat de treabă și mi-am dat seama că socoteala de acasă nu se potrivea deloc cu cea din târg. Eu estimasem ce trebuie să fac și anume:

- să scriu componente cap-coadă;

- să preiau componente vechi așa cum sunt;

- să modific componente pentru a face noi legături;

- să redefinesc sistemul de foldere;

- să refolosesc șișuiere din folderele vechi;

- să las și vechea aplicație cât mai mult operațională.

Faptul că am învățat să iau totul gradual, m-am înarmat cu:

- voință. 

- răbdare,

- putere,

- speranță,

- autoexigență

și am desfășurat activități acre să-mi permită lansarea aplicației supusă procesului de reinginerie fix pe 01.01.2015, lucru care s-a și întâmplat așa. Nu a fost ușor, dar mi-am făcut notițe în detaliu, mi-am desenat arborescența și am revăzut totul cum era înainte de reinginerie. Am pus fișierul index de lucru într-un loc secret și am mers cu construirea sa din aproape în aproape. Au rezultat nițte foldere noi, dar nu le-am distrus pe cele vechi. Am preluat gradual din folderele vechi fișiere existente efectuând mici modificări pentru a le lega de noua structură care nu trebuie sa aibă decât trei niveluri. 

Din start am lucrat ăn mediul real și experiența acumulată mi-a dictat să nu merg mai departe decât numai dacă ceea ce am făcut rezista testelor. Zic că am rezolvat problema în proporție de 90% căci în noua versiune nu am înccorporat tot ceea ce era în vechea formulă a aplicației. Oricum am avut patru versiuni și cine vrea are acces la două. Eu am acces la toate patru.

reingineria a fost o experiență. Oricum mi-a dovedit că dacă componentele nu au uzură morală și sunt corect construite, cu mici modificări se încorporează fără vreo dificultate în noua aplicație, care oricum va părea cât de cât nouă, dar va păstra mirosul de vechi, nu de vechituri.
Reingineria este un proces în care intră cu mult sub 5% dintre produsele software aflate în uz la un moment dat. Sunt situații în care pentru dezvoltator nu este rentabilă reinginerie  câtuți de puțin. Sunt situații în care însă reingineria este vitală dacă fișierele se preiau în proporție de peste 40% fără nicio modificare. Alte fișiere necesită în proporție de 30% mici modificări și numai cel mult 40% sunt componente noi, dar sunt componente fundamentale, care dau filosofia noii aplicații.

(29 noiembrie 2017)

Mentenanța

Mentenanța unui program este total diferită de cum era mentenanța programelor prin anii '70 sau '80 sau chiar și '90. În vremurile de emult programatorul era un fel de Marița bună la toate, deci se înțelege că automat to el făcea și mentenanța. Dacă știa să facă produsul mentenabil, avea viață ușoară. Dacă nu, muncea cam mult și fără spor.

Pentru a face un program mentenabil sunt nenumărate modalități. Totul este ca programatorul să știe că tot el va face mentenanța. 

Dacă utilizatorul spune că seriile lui de date au 67 de termeni, la definire se vor face alocări de 200 de componente și numărul efectiv cu care se va lucra este introdus prin program. Programatorul neinspirat care va lucra cu constanta 67 peste tot în program, când utilizatorul zice că lucrează cu o serie de 81 de termeni, teste tot prin program unde apare 67 trebuie să-l înlocuiască cu 81 și din cauza vitezei dacă are și vreo instrucșțiune etichetată cu 67, va înlocui eticheta cu 81 ceea ce declanșează răzmeriță și tot programul se strică. Și dacă programatorul nu lucrează cu variante, dacă utilizatorul îi va spune că de fapt seria tot 67 de termeni are, va năduși să restabilească ceea ce a fost inițial, dar cu siguranță va rămâne într-un colțișor un 81 uitat și nemodificate și evident erorile se vor ține lanț căci se va lucra cu variabilele de la 68 la 81 care nu au fost inițializate.

Acum limbajele de programare moderne au tot felul de facilități care permit realizarea mentenanței în doi timpi și trei mișcări. Cine știe să folosescă inteligent facilitățile de template la definirea de tipuri de variavile va reuși să construiască biblioteci foarte variate fără a avea redundanta din FORTRAN unde se construiau patru biblioteci dacă se dorea să se folosească operanzi de tip INTEGER, de tip REAL, de tip DOUBLE PRECISION și de tip COMPLEX. Folosind template se va construi o singură bibliotecă și doar se va specifica tipul cu care se lucrează.

experiența acumulată îl face pe programator să scrie din start programe direct mentenabile folosind modalități precum:

- alocări dinamice de variabile omogene;

- lucru cu vectori de pointeri spre funcții;

- rezervarea de zone suplimentare în articole;

- realizarea de construcții deschise;

- dezactivarea de opțiuni la cerere;

- restrângeri de variante prin generalizări;

- gestionarea ondulanței prin modularizare;

- gestionarea variantelor de program;

- separarea părților instabile ale programului.

mentenanța depinde foarte mult de discuțiile inițiale ale definirii problemei, când sunt descifrate toate punctele în care intervin modificări concretizate prin:

- schimbări a ceea ce există;

- adăugări ale unor elemente;

- eliminări de componente.

Toate acestea se produc simultan în procesul de mentenanță. La programul de calcul al salariilor apar noi cerințe concretizate prin:

- adăugarea în articol de noi câmpuri conform legii;

- schimbări în algoritmul de calcul;

- modificări în treptele de impozitare;

- introducerea unui alt mod de tipărire;

- efectuarea de tranzacții online.

Toate sunt firești și noul sistem de lucru pe care codul fiscal care va intra în vigoare la 1 ianuarie 2018 va impune schimbări de substanță în programul de calcul al salariului, căci se pornețte de la salariul brut și din el se fac scăderi, nu de la salariul net la care se făceau adunări pentru a ajunge la salariul brut de azi. Dacă cei ce au gândit sistemul de programe pentru salarii au avut o viziune mult mai cuprinzătoare, cu siguranță nu vor muncii prea mult în procesul de mentenanță. În cazul în care însă au lacrat ca prin anii '70, evident vor munci aproape luând totul de la zero, căci lor li se va părea că totul este schimbat.

Pentru a face un program ușor mentenabil se impune:

- structurarea pe funcționalități a programului;

- introducerea de comentarii în programe;

- adoptarea de tehnici de parametrizare;

- implementarea unei formule de însumare de produse;

- includerea unei rezerve de zonă de memorie în articol;

- construirea unui program de inițializare a parametrilor;

- parametrii sunt de fapt un articol într-un fișier.

Nu mă apuc eu să dau sfaturi celor care mănâncă programe de calcul salarii pe pâine, dar mi-aș putea da acum seama cât de meseriași au fost la proiectarea acum câțiva ani a noii structuri de program, căci mi se pare impardonabil să fie aruncate peste bord peste 40% din textele sursă de azi, doar pentru faptul că s-a modificat legea. Stabilitatea programului și mentenabilitatea sa sunt strâns legate.

Efortul de mentenanța software arată cât de bună a fost soluția adoptată. Sunt sigur că un program se proiectează din star să fie mentenabil, dacă cei ce se ocupă de acest aspect sunt vizionari și adoptă strategia că din mentenanță se trăiește cu mult mai bine decât din scrierea de programe. Scrierea de programe are caracter de unicat, pe când mentenanța este perpetuă și este indispensabilă clienților care deja s-au obișnuit cu produsul și nu l-ar schimba din inerție, comoditate sau așa pur și simplu, din teama de nou.
Programele FORTRAN nementenabile sunt cele care fac munca programatorilor creativă, căci ei nu mai pierd mult timp cu procesul de a prelua în program tot felul de modificări după ani și ani de la implementare.
Totuși lumea trebuie să scrie programe mentenabile, iar pentru urmărirea facilă a textului trebuie create blocuri distincte sau introduse elemente de variabilitate, lucrându-se cu date citite pentru a obține efectele dorite.

(29 noiembrie 2017)

Studiul pieții de software

Studierea pieței software nu se făcea în vremurile  de dinainte de 1989 căci așa ceva nici nu exista în România, iar dacă exista în lume, degeaba exista căci nu aveam noi acces la a cumpăra ceva de pe acea piață. Când și când se mai cumpăra de la firmele care vindeau calculatoare sau utilaje și software aferent, dar niciodată ceva în plus.

Se afla când și când de la cei ce mai scăpau să plece în străinătate fie la congrese, fie în vizite, fie la burse, fie la scurte stagii de specializare, ce se făcea prin Germania, prin America și prin Franța în ale informaticii. Dacă cineva aducea o carte era sărbătoare. Veneau în schimb cărți în bibliotecile de computer science. Erau astfel de biblioteci la etajul al VII-lea al Centrului de calcul al ASE, în clădirea Centrului de calcul de la Facultatea de Automaticla Facultatea de matematică și la INID. Cărțile și revistele se studiau acolo și era practic imposibil să copiezi software în bibliotecă. Mai erau biblioteci tari la ICI și la ITC, numai că accesul era restricționat.

Noi fiind prea la început, orice software s-ar fi scris era bun scris și nu erau necesare comparații din moment ce implementările veneau pe teren viran.

Acum, studiul pieții de software este o necesitate, căci a implementa un program oarecare în condițiile în care ăiața oferă produse mult mai bune înseamnă a multiplica nonperformanța la toți clienții care fac tranzacții online cu aplicația non-performantă. Studiul pieții de software presupune stabilirea parcurgerii următorilor pași:

- definirea problemei de rezolvat din punct de vedere  al funcționalităților;

- estimarea grupului țintă care ar accesa funcționalitățile;

- construirea unei liste de produse în piață cu respectivele funcționalități;

- studierea caracteristicilor tehnice ale fiecărui produs din listă;

- includerea în studii  a caracteristicilor economice, inclusiv a prețului;

- acordarea de punctaje după caracteristici fiecărui produs din listă;

- alegerea unui criteriu de agregare a punctajelor;

- ierathizarea produselor software după valaoarea agregată;

- alegerea celor mai avantajoase trei produse;

- detalieri privind restricții suplimentare de utilizare și de implementare.

Numai dacă exigențele definite de client nu se regăsesc printre produsele din piață se va lua decizia de a elabora produse software proprii dar trebuie luate în calcul durate, costuri și multe altele, inclusiv garanțiile de drepturi de proprietate și cele de drepturi de autor, astfel încât să se vadă dacă demersul se justifică.
Studiul pieții de software este necesar acum căci diferența între un produs slab și unul bun se multiplică cu numărul clienților care accesează online aplicația. În plus, la câte aplicații sunt în târg, este păcat să se construiască una nouă, probabil mai slăbuță, la un preț mult mai mare și se de așteptat să parcurgă ciclul de dezvoltare, în timp ce se achiziționează pe loc o aplicație la cheie foarte bună.

În vremurile de demult, exista Biblioteca Națională de Programe - BNP, care concentra tot ce se făcea de calitate în zona de software la noi. Cine dorea să facă ceva nou trebuia să facă dovada că produsul pe care vrea să-l realizeze nu se găsește în BNP. În cazul meu, datorită faptului că aveam aplicații informatice din zona cercetării pe bază de contract, noutatea problemelor ducea garantat la inexistența în BNP a ceea ce aveam de făcut. Deci studiul pieții se încheia rapid și fără emoții. Acum lucrurile stau altfel, dar credd că mulți nu fac astfel de studii și trec la elaborare de software pe neve.

(29 noiembrie 2017)

Eleborarea documentației

Eleborarea documentației este un fel de cenușăreasa etapelor de eleborarea produselor softwareintea tuturor celor care participă la realizarea produsului este încolțită ideia că și fără documentație produsul funcționează. Adevărul nu este departe de această afirmație, numai că fără documentație programul e program, dar:

- funcționează greu;

- are limitări severe;

- nu e independent de cel care l-a scris;

- se consumă resurse în plus;

- funcționează cu costuri ridicate;

- funcționează pe bani mulți;

- uneori chiar nu funcționează deloc.

Am scris și eu ceva programe și n-aș zice că în vremurile de demult aveam o plăcere diabolică în a scrie documentație pentru că:

- toate lucrurile mi se păreau cunoscute;

- aveam impresia că n-am să uit nimic;

- credeam la început că este inutilă;

- nu vedeam utilitatea ei pe loc;

- credeam că mentenanța e floare la ureche;

- nu mi-o impunea nimeni dintre cei din jur;

- nici șefii nu prețuiau documentația;

- conținea o reflectare inutilă a programului;

- disprețuiam scrierea de proză;

- o vedeam inutilă că puneam comentarii în program;

- aveam senzația că nu o citea nimeni.

Când peste ani au început să apară procese de mentenanță și nu mai regăseam:

- formule,

- descrieri de câmpuri,

- condiții,

- particularități,

- semnificații coduri selecție,

- cerințe imperative,

reconstituirile din memorie sau întrebându-i pe alții erau deja un chin. În timp, m-am consolat cu ideia de a scrie documentație și acum vreo 5 ani am aruncat niște volume în care am descris la nivel de bloc de schemă logică programe pe care le-am făcut pentru niște beneficiari și care erau scoase din uz de destul de mult timp. Dacă atunci aș fi avut în gând să scriu o istorie a informaticii aș fi păstrat măcar un volum să arăt cum făceam eu documentație, fără a avea un standard, ci doar după cum mai făceau și alții care știau ei ce știau despre dificultățile de a face mentenanță. Mai până anul trecut am păstrat și cartelele unor programe, dar le-am aruncat la topit. Acum îmi pare rău. Trebuie să precizez că documentația conținea în acele vremuri date despre:

- contractul sub care s-a construit produsul software;

- echipa care a lucrat cu semnături;

- descrierea problemei;

- datele de intrare cu machete de cartele;

- datele de ieșire cu structuri de capete de tabel;

- la date se precizau tipul și formatul de perforat sau de tipărit;

- formulele de calcul în clar;

- schema de sistem;

- tabele de analiză utilizare câmpuri;

- algoritmii de prelucrare pe pași;

- scheme logice;

- descrierea de module și parametrii;

- lista mesajelor de eroare și cum se depanează;

- textul sursă;

- necsar minim de resurse;

- formule de calcul ale dimensiunilor problemelor de rezolvat;

- rezultate ale testării;

- modul de implementare;

- ghidul utilizatorului.

Nu cred că azi este o mare bucurie pentru programatori să scrie documentație, numai că acum există instrumente care:

- desenează scheme logice;

- extrag comentariile din programe;

- construiesc liste de variabile și obligă la completarea lor;

- fac sinteze la secvențele omogene ale programului;

- extrag listele de proceduri și impun descrerile lor;

- imun descrierile listelor de parametri;

- construiesc liste de variabile și impun descrierea lor;

- identifică unele imperfecțiuni din program.

Toate acestea îl forțează pe cel ce scrie documentație să fie extrem de atent și să realizeze descrieri corecte și complete, căci unele dintre instrumente fac și analiză de text introdus de cel ce face documentația și atenționează la atingerea unui nivel de redundanță prea ridicat, mai ales dată de repetarea prin copy-paste a unor paragrafe.

În opinia mea, a face documentația este un lucru esențial mao ales de când beneficiarii îi poartă prin tribunale pe dezvoltatori. De aceea, dezvoltatorii trebuie să facă ochiimaridacă trec sau nu elaborarea de documentație acolo în mod expre, dacă folosesc termenul de mentenanță care presupune documentație și dacă vorbesc cumva de audit, care trebuie făcut și un prim pas este acolo verificarea existenței specificațiilor, textului sursă și a documentației.
Eleborarea documentației este la fel de grea ca scrierea programului, dacă nu chiar mai grea, dacă se face 100% după ce programul  e gata de implementare și programatorul a neglijeat să facă notișe, a lucrat fără specificații și soluția a rezultat doar din discuții nu și dintr- schemă de sistem.

(29 noiembrie 2017)

Scrierea modulelor

Scrierea modulelor este floare la ureche dacă sunt bine făcute specificațiile de programare. În specificații rezultă:

- lista modulelor;

- legăturile dintre module;

- listele de parametrii;

- formulele de calcul;

- restricții de validare;

- rezultatele returnate;

- cazurile de excepție și tratările lor;

- cu ce module relaționează;

- ce trebuie testat.

Modulele se scriu separat de diferiți programatori. În lipsa specificațiilor toți din echipă lucrează după ureche și nu știe stânga ce face dreapta. Va fi numai o persoană care știe totul și ceilalți îl vor toca cu tot felul de întrebări, dar cu siguranță acestuia îi place să dea cu pipeta, ca să fie și să rămână stăpânul inelelor, în lipsă de alte talente și mai ales de autoritate și de disciplină de producție.

Am avut norocul să lucrez cu mari programatori de la care am învățat lucruri deosebit de importante. Am avut ocazia să citesc documentație de la IBM unde erau exemple de programe cap-coadă, foarte bine construite, excelent documentate, de unde am învățat. În vremurile de demult revista Commnuications of the ACM avea pe ultimele pagini prezentări de algoritmi și de programe preponderent Algol sau FORTRAN, scrise de maeștii, de unde am învățat multe lucruri.

Cei care mi-au dat să scriu programe în tinerețea mea nu zic că mi-au dat specificații dar:

• mi-au dat notițe din care înțelegeam destul de multe despre bucata de program ce trebuia s-o scriu eu sau aiscuții cu ei și eu îmi notam așa fel încât știam destul de bine cum stăteau lucrurile; unii dintre ei îmi puneau restricții legate de numărul de instrucțiuni IF sau PERFORM, dar și de câte ciclări să am în procedură; nu mai vorbesc de faptul că toți doreau un singur RETURN în textul scris de mine; în acele vremuri de pionierat, chiar eu ca programator îmi făceam niște tabele și dacă apăreau coloane fără steluțe însemna că am variabile definite și nefolosite; în alte tabele îmi dădeam seama că ceva lipsește la modulele ce-mi reveneau; era un motiv în plus să cer elemente suplimentare; oricum când scriam textul totul îmi era clar și nu aveam nicio ezitare, dar nu mă scărpinam în nas ducând mâna pe la ceafă;
• mi-au dat destule elemente de care să mă folosesc, chiar și alte proceduri și mai ales elemente de bibliotecă din care rezultau ce definiri existau deja făcute ca eu să scriu oarece proceduri astfel încât ceea ce am scris eu să se integreze în lucrarea mare; acolo vedeam și stil de programare și particularități de utilizare a ceea ce era deja definit de predecesorii mei; îmi amintesc că un conducător de proiect avea o imprimantă cu lista de erori pe care trebuie să le dentific în datele de intrare și cum să le semnalez; aveam modalitatea de a scrie secvențele și este clar că făcând ca acolo, eu asiguram omogenitatea textului meu în raport cu ce era scris deja; de acolo mi-am făcut regula ca variabila de control i să fie folosită pentru a traversa liniile unui masiv bidemnsional, iar variabila j să fie utilizate pentru a traversa coloane; tot de la programatorii pe care i-am cunoscut am învățat să pun p la numele variabilelor pointer; de la ei am învățat să asigur ortogonalitatea numelor de variabile dar și multe, multe altele.

Nu e ușor să se scrie texte sursă, dar nici imposibil. Totul este ca acele programe să nu fie scrise așa cum fac pseudofolcloriștii de azi care se laudă la Tv că ei scriu cântece pe bandă rulantă. Eu știu de la un cenaclu literar de la mine din provincie, că pentru a scrie poezie de calitate, trebuie citită multă poezie. Și în programare este la fel. Înainte de a scrie programe, programatorul trebuie să citească multe texte sursă scrise de alți programatori, dar de programatori valoroși, iar numai după ce are o cultură solidă să se apuce să scrie. Îmi aduc aminte că pe când eram licean așteptam ultima săptămână din an ca să cumăr revista Luceafărul a lui Eugen Barbu ca să citesc penultima pagină unde erau publicate cele mai proaste poezii trimise la redacție de-a lungul anului. TCântecele făcute de artiștii de folclor cu cultură precară de azi de acele vremuri îmi amintesc. Am văzut și programe prost scrise care mă duc cu gândul tot acolo și nu am nicio explicație de ce se întâmplă așa ceva.

Scrierea modulelor este singura activitate din care se vede cum arată produsul software, cel ce aduce sau nu performanță, cel care face sau nu face ceea ce dorim noi ca utilizatori sau ei ca programatori să facă.

(01 decembrie 2017)

Realizarea specificațiilor

Drama celor care lucrează în informatică este realizarea specificațiilor. De ce sunt specificațiile de programare marea sperietoare nu am înțeles și nu voi înțelege niciodată. Specificații face gospodina în fiecare zi înainte de a organiza cele trei mese pentru familie. Ea nu merge la piață ca musca fără cap, ci are specificațiile făcute bine chiar. Să mă explic: dospodina dezvoltă totul din aproape în aproape. 

La primul nivel de detaliere, pentru masa de dimineața, gospodina își imaginează o cafea, niște mezeluri, brânzeturi, ouă, pâine, unt și dulceață și miere. Pentru prânz ea vede o ciorbă, o friptură, o salatăși o prăjitură. Pentru seara vrea ceva ușor, adică o salată, un grătar și niște fructe. Toate acestea, în linii mari. 

La al doilea nivel, va trece la detaliere spunând ce mezeluri și ce brânzeturi pune pe masă, de ce legume are nevoie pentru ciorbă și pentru garnitura felului principal, ce legume pune în salată. Ea precizează care sunt ingredientele pentru prăjitură și ce fruncte cumpără. Sunt mai în detaliu.

La al treilea nivel, gospodina face lista și regupează ceea ce are de cumpărat pe raioane pentru a nu alerga aiurea în supermarket. Ea trece și cantitățile în mod acoperitor. Dacă unele dintre componente le are în cămară nu le mai cumpără, dar verifică dacă într-adevăr sunt în cămară. Toate sunt mai în detaliu decât la nivelul precedent și mai mult, sunt și regrupate pe raioanele supermarketului.

La nivelul al patrulea merge să cumpere, ceea ce înseamnă că lucrurile devin mai concrete. Verifică totul din punct de vedere cantitativ și calitativ. Caută să se încadreze în buget.

La nivelul al cincilea deja prepară felurile de mâncare pas cu pas și în unele cazuri vede ce are de făcut în paralel ca să se încadreze în timp. Ea are proceduri, are succesiuni logice de operații. Face tot timpul aprecieri cantitative și verifică stadiile. Caută să se încadreze în timpul disponibil.

Vedem că pentru primele trei niveluri gospodina nu face nimic altceva decât specificații. Nimeni nu are cum să înceapă ceva fără a ști ce face. Gospodina este un exemplu de cum se fac specificațiile pentru a avea succes cu preparatele ei. Cine nu face specificații va proceda exact ca gospodina care nu lucrează după specificații și anume:

- se găsește la servirea mesei că-i lipsește un preparat de care a uitat;

- când merge la piață precis uită ceva și-și trimite soțul după acel produs;

- nu lucrează nimic la simultan și nu termină în timp util;

- va munci după principiul leneșul mai mult aleargă;

- precis că la masă se simte că nu au existat specificații.

Cele patru niveluri nu sunt altceva decât o dezvoltare TOP-DOWN așa cum stă bine oricărei gospodine care se respectă, adică dezvoltare din aproape în apropape și pentru fiecare nivel crește gradul de detaliere.

Și în programare tot așa trebuie lucrat. Vor exista mai multe niveluri, dar trebuie să se ajungă în final ca specificațiile să lămurească absolut toate aspectele, să se răspundă la toate întrebările. Specigicațiile trebuie să fie:

- complete;

- clare;

- consistente;

- graduale;

- logice;

- simple;

- structurate;

- unitare;

- formalizate;

- concise.

Dacă o sută de programatori citesc aceleași specificații ei vor scrie 100 de programe care:

- folosesc același limbaj de programare;

- utilizează aceleași structuri de date;

- au asociate arborescențe care nu diferă semnificativ;

- sunt de lungimi care nu diferă radical;

- lucrează cu aceleași tipuri de fișiere;

- au aceleași tipologii de validări de date;

- aparțin acelorași generații de software.

Dacă nu este așa, cu siguranță că specificațiile de programare sunt afectate de carențe importante care dau niște grade de libertate nepermis de mari programatorilor. Când am scris programele mele niciodată nu m-am așezat în fața foilor de programare sau a compterului sau al PC-ului sau a laptopului ca un pianist gata să facă improvizații. Al luat foi de hârtie, mi-am notat tot felul de întrebări, am avut discuții cu specialiști, mi-am construit niște matrice citind notițele și am mai discutat cu specialiștii dacă ceva nu se lega. După ce totul îmi era clar, am scris un text pe care l-am verificat cu specialiști dar și cu colegi și numai dacă se dovedea că totul este așa cum trebuie am trecut la scrierea programului. Citind acel text am avut întodeauna că programul se scrie singur. Nu s-a întâmplat decât o singură dată în viața mea ca totul să meargă șnur. Dar în celelalte cazuri nu s-au produs prea multe reveniri și mai ales nu am avut erori datorate elaborării outputurile din primele etape ale ciclului de realizare. Tot ce am avut erori au dost de corectat fără a mai merge la beneficiar să fac corecții care au un caracter dramatic și care lungesc timpul de realizare a programului.

Experiența mea arată că dacă am avut specificații am muncit cu mult mai eficient decât dacă nu le-aș fi avut, lucru de care mă mândresc și am explicat și doctoranzilor de ce e bine să aibă arborescență la teza de doctorat organizată pe patru niveluri, unde la ultimul nivel să pună 5 propoziții scurte foc.
Realizarea specificațiilor este piatra unghiulară a oricărei dezvoltări de software. Numai având specificații bune se va realiza un program bun. Altfel totul este o nebuloasă și produsul finit va părea că este făcut din cârpeli.

(29 noiembrie 2017)

Elaborarea soluției

Elaborarea soluției acum în 2017 nu are nicio legătură cu modul în care se definea soluția informatică în anii '70 ]n anii '0 ;i chiar prin anii '90, când restrictțiile hardware și software erau extrem de severe. În acele vremuri:

- exista un calculator;

- la calculator timpul era drămuit;

- la dispeceratul calculatorului se primeau cartele;

- cartelele se citeau, programul se rula;

- cartelele erau perforate, după foi de programare;

- folie erau scrise de programator;

- programatorul știa un limbaj, hai două, dar niciodată mai mult de trei;

- soluția era dată de ce știa programatorul;

- problema de rezolvat avea de regulă o soluție și punct.

Atunci nu era ca acum când există cloud computing și asta înseamnă:

- varietate de resurse;

- eliminarea linitărilor;

- totul depinde de designer;

- există multe variante de soluții;

- se definesc criterii și se alege soluția cea mai potrivită;

- se folosesc tot felul de instrumente care îmbunătățesc.

Dacă se punea problema scrierii unei aplicații pentru gestiunea stocurilor, programatorul care știa limbajul COBOL creiona aproape mecanic soluția:

- un program de creare a fișierului de materiale cu organizare indexat-secvențială;

- un program de actualizare doar a materialelor cu mișcare;

- un program de calcul al stocurilor și de tipărire a acestora;

- un program de extragere a materialelor fără mișcare.

Dacă se punea problema scrierii unui program pentru calculul balanței legăturilor dintre ramuri, programatorul care știa să scrie texte sursă în FORTRAN creiona și el soluția, considerând soluția prin scrierea programelor pentru:

- inițializarea vectorului de ramuri;

- inițializarea matricei de transferuri dintre ramuri;

- verificarea echilibrului;

- efectuarea de corecții pentru echilibrare;

- calculul matricei I-A;

- calculul inversei matricei;

- calculul produsului matrice cu vector;

- afișare matrice pe blocuri;

- afișare vector cu denumire elemente.

Cine are curiozitatea să analizeze scheme de sistem pentru multele dintre produsele program scrise în acele vremuri, inclusiv pentru cele care aveau și baze de date, va avea surpriza să vadă că existau niște scheme simple de a construi soluții, căci simple erau și mijloacele la dispozișie atunci. Lipsa memoriei interne a calculatoarelor făcea ca multe dintre rezultatele intermediare să fie stocate pe benzi sau pe unități de discuri. Deci, exista un program de creare a unui fișier pe disc cu date de pe cartele. Fișierul de pe disc era intrare în programul de obținere a tor felul de rapoarte. dacă se dorea efectuarea de actualizări, programul care făcea așa ceva avea intrări:

- fișierul de actualizat care era pe disc;

- cartelele care conțineau coduri de articole și datele de actualizat.

Ieșirea acestui program erau:

- fișierul de pe disc cu date actualizate;

- ceva rapoarte tipărite cu catele actualizate din fișier.

Să ne imaginăm ce ar fi însemnat să nu existe nici bandă magnetică și nici disc magnetic, ci doar cartele perforate. În loc de fișier pe disc cu date actualizate, programatorul ar fi primit o cutie cu cartele cu fișierul actualizat, perforarea efectuându-se în sala calculatorului. Frumos, nu?
Elaborarea soluției nu era așa de sofisticată ca acum, căci atunci nu exista o diversitate așa de mare de resurse ca acum, când a elabora o soluție înseamnă a aloca resurse și a urmări un criteriu de optim.

În vremurile de demult trebuie să ne gândim la programatorul FORTRAN exact ca la medicul care pentru orice tratament oferă carbocif. Dacă programatorul știa FORTRAN și COBOL era exact ca medicul care oferă pacienților carbocif sau furazolidon, funcție de ce consideră el util. Rezultaele sunt comparabile și la medic și la programator. Acum programatorul are atâtea resurse, comparabil cu medicul care se află într-o farmacie super-aprovizionată. Totul depinde de ei căci n-au restricții.

(29 noiembrie 2017)

Testarea programului

Testarea programului este o etapă decisivă în procesul de realizare a fiecărui program. ea se face folosind tehnici mai mult sau mai puțin evoulate, dar obiectivul este mereu același, de a identifica erorile existente în vederea corectării lor.
Pentru a arăta cât de complexă este testarea voi lua construcția unui program banal și anume scrierea unui program pentru calculul mediei aritmetice ponderate. Programul se pregătește pentru a fi testat. În acest sens se scriu instrucțiuni care afișează date citite și rezultate intermediare.
În primul rând se verifică dacă citirea datelor de intrare este corectă în acest sens:
- se imprimă valoarea lui n care arată câte componente are seria de date;
- în cazul în care n este negativ sau nul se afișează un mesaj și se reia citirea sa;
- se imprimă variabila de control, valorile termenilor seriei și frecvențelor;
- în cazul frecvențelor nule se afișează un mesaj;
- în cazul variabilei de controș negative se afișează un mesaj;
- se analizează dacă datee au fost corect citire și dacă sunt complete.
Testarea are menirea de a scoate în evidență tot felul de erori de citire a datelor, unele dintre ele fiind așa de bizare că ne minunăm de cum s-au scris asemenea secvențe de instrucțiuni.
În al doilea rând se verifică dacă variabilele au fost inițializate, folosind textul sursă. În cazul aplicației se verifică dacă:
- variabila unde se calculează suma frecvențelor este inițializată și unde se face inițializarea;
- variabila unde se calculează produsul valoare, frecvență este inițializată și unde.
În al treilea rând se scriu instrucțiuni de afișare rezultate intermediare privind:
- produsele valoare, frecvență;
- sumă de produse;
- sumă de frecvențe;
- variabilă de control.
Cestea permit să se verifice că ceea ce este ăn specificații se și produce în program. Sunt situații în care nu se folosesc toți termenii din serie sau din contră se utilizează termeni care nu sunt inițializați prin citire, din cauza condiției eronate pusă la variabila de control.
În al patrulea rând, înainte de a face împărțirea sumei de produse la suma de frecvențe se verifică dacă suma de frecvențe este nulă. Dacă această sumă este nulă se scrie un mesaj și se încheie execuția. În mod normal testarea frecvențelor ar cam trebui să nu necesite această testare. Numai că atunci când transformăm secvențele într-o procedură și cel ce face inițializările nu se asigură că frecvențele vor fi numai pozitive, procedura va avea o problemă, adică o împărțire prin zero și este impardonabil la așa o procedură de simplă.
În al cincilea rând se imprimă rezultatul final, media, care oricul se imprima, dar se imprimă și sumele și chiar și alte date referitoare la elementul minim, elementul maxim sau ce-o mai vrea clientul.
În vremurile de demult toate acestea erau la inspirația programatorului, care se apuca să introducă instrucțiuni de scriere de mesaje și de rezultate intermediare dacă și numai dacă programul său crăpa la execuție. Acum, în lumea modernă nu mai este așa. Programatorul fie scrie câteva instrucțiuni care fac ele totul, fie există programe de asistare a scrierii care îl ghidonează pe programator făcându-i sugestii dintre cele mai necesare, care-l feresc de a cădea în păcatul:
- utilizării de variabile neinițializate;
- de a ieși din definirile câmpurilor;
- de a avea neconcordanțe între listele de parametri;
- de a face împărțiri la zero;
- de a avea neconcordanțe de tip;
- de a defini și nu folosi variabile;
- de a avea cod mort în program.
Cu un program îngrijit scris și înțesat de instrucțiuni de afișare și de testare variabile, se trece la testarea propriu-zisă a programmului care constă în:
- a lua un set  de date de test și de a-l rula;
- a verifica dacă exte concordanță între ceea ce este tipărit în specificații și ceea ce dă programul;
- a găsi neconcordanțele;
- a stabili cazuzele neconcordanțelor;
- a efectua corecțiile;
- a relua alte seturi de date de test;
- a repeta operațiile de la prima;
- de a încheia testarea când nu mai apar erori de niciun fel.
În vremurile de demult srierea programului și testarea programului o făcea măria-sa programatorul. Acum este o diviziune a muncii, programarea fiind separată de testare.
Testarea programului este esențială. Testarea face ca programul să fie acceptat sau programul să fie respins. În cazul programului de calcul pentru media aritmetică ponderată se consideră seturile de date de test ale căror rezultate sunt ușor de verificat.
Se iau>
 n=25
 x[0]=x[1]=x[2]=...=x[24]=1
 f[0]=f[1]=f[2]=...=f[24]=1
se verifică ușor dacă se citesc toate datele , dacă sumele sunt corect calculate și dacă media aritmetică ponderată este și ea corectă.
Al doilea set de date de test corespunde situației în care:
n=25
x[0]=1
x[1]=2
x[2]=3
...
x[24]=24
 f[0]=1
f[1]=2
f[2]=3
...
f[24]=24
Cele două sume se calculează prima ca suma primelor 25 numere naturale Sxf= n(n+1)(n+2)/6 ți a doua ca sumă a primelor 25 de numere naturale sf=n(n+1)/2, media aritmetică fiind med=(n+2)/3.
Următorul set de date de test are n=24 și valorile seriei alternează cu valori pozitive și negative, iar frecvențele sunt în perechi:
n=24
x[0]=1
x[1]=-1
x[2]=2
x[3]=-2
...
x[22]=12
x[23]=-12
f[0]=1
f[1]=1
f[2]=2
f[3]=2
......
f[22]=12
f[23]=12
Sxf va fi zero, sf va fi  n(n+2)/4, iar media aritmetică ponderată va fi și ea tot zero. Cu cât sunt mai multe astfel de seturi de date de test cu atât e mai bine. Abia după aceea se trece la testarea programului cu tot felul de serii despre care rezultatele se află în cărți de statistică și numai în ultimul stadiu se vor utiliza seriile oarecare, căci verificarea rezultatelor nu va mai fi necesară la nivel de detaliu așa ca la testările de început.

(29 noiembrie 2017)

Auditarea aplicației informatice

Auditarea aplicației informaticii se face dacă și numai dacă aplicația:

- este complet testată;

- există specificațiile;

- are documentația făcută;

- este terminată 100%;

- a fost dusă și la clienți;

- este obligatoriu să fie auditată;

- există banii pentru auditare;

- cineva își asumă riscurile.

Auditarea aplicațiilor informatice presupune verificarea concordanței dintre specificații și ceea ce execută acestea. Se parcurg specificațiile și se extrag de acolo:

- inputurile aplicației;

- outputurile aplicației;

- lista de stări ale aplicației;

- limirările de resurse;

- cazurile speciale.

Auditorii parcurg o serie de fluxuri, inclusiv de testare, prin care verifică existența concordanței dintre specificații și ceea ce fac aplicațiile în realitate, punctând explicit diferențele, iar dacă este cazul identificând și cauzele. Din specificații, auditorii extrag seturile de date de test, dar vin și cu seturi proprii de date de test care să acopere mult mai complet arborescența asociată produsului software. În lucrarea referită prin:

Ion IVAN, Gheorghe NOSCA, Sergiu CAPISIZU - Auditul sistemelor informatice , Editura ASE, Bucuresti, 2005, ISBN 973-594-638-6, 155pg,

sunt tratate aspecte legate de auditare care merg și pentru software. Consider că auditarea nu este o formalitate dacă și numai dacă este făcută profesional și mai ales dacă se aplică unui produs care în mod real are caracteristicile unuia care să merite certificatul de auditare. Elaborarea documentației de auditare presupune trversarea unor fluxuri complexe care merg până la studierea textelor sursă, ceea ce presupune ca auditorii să fi fost niște programatori de înaltă clasă.
În vremurile de demult nici nu se punea problema auditării unei aplicații. Problema a apărut în momentul în care aplicațiile informatice au generat fluxuri de materiale, informaționale sau bănești cu caracter ireversibil și erorile transformau pe unii dintre clienți în păgubiți care plătiseră pentru serviciul prin care tranzacțiile se executau folosind aplicația care musai trebuia să fie de încredere, încredere dată numai și numai prin auditare. Atunci, demult, nu se puneau problemele de azi, iar atunci înainte de a lua o decizie bazată pe o informație venită de la calculator se făceau nenumărate verificări, deci încrederea în aplicațiile informatice era numai pe jumătate sau lipsea cu desăvârșire.

(01 decembrie 2017)

Scoaterea din uz

Scoaterea din uz a unui produs software are mai multe cauze dintre care enumăr:

- uzura morală care-l face cu mult mai puțin performant decât alte produse din piață;

- imposibilitatea de a-l integra în aplicații moderne;

- cheltuielile mari pe care le implică un proces de reinginerie;

- eforturile mult prea mari ale procesului de mentenanță;

- apariția unei funcții echivalente dintr-o generație actuală în structura unui produs achizișionat;

- imposibilitatea de a utiliza rezultatele în fluxurile informatice obligatorii;

- lipsa instrumentelor de mentenanță;

- izolarea utilizatorilor în raport cu ceilalți utilizatori care folosesc produse noi;

- performanța redusă în raport cu cheltuielile care apar.

Există ca și la utilajele care se înlocuiesc:

- calcule economice care arată că cheltuielile de menținere sunt costisitoare;

- un moment optim de înlocuire, deși software nu are uzură fizică;

- presiunea dată de noile produse software echivalente;

- necesitatea alinierii la noile generații de software;

- dorința de a lucra cu aplicații numai din ultima generație.

Momentul înlocuirii este unul natural sau unul brutal, mai ales atunci când datorită unor cauze exterioare cei din management consideră că un produs software este uzat într-o asemenea măsură încât trebuie înlocuit cu un produs, chiar dacă noul produs  se dovedește a fi inferior celui înlocuit. La noi ciclurile electorale vin cu astfel de abordări. În vremurile de demult, pe princiul a ieșit din literatură înainte de a intra, multe produse software pentru care s-a făcut recepție nici nu intrau în exploatare, fiind respinse de utilizatori din motive precum:

- lipsa necesității;

- neînțelegerea;

- absența resurselor;

- debut dezastruos;

- noncalitatea;

- mentenanța dificilă.

Undeva am scris că foarte puține produse software intră în reinginerie, deci ies din utilizare pe durata procesului de mentenanță. Unele produse și cred că sunt foarte multe, ies din uz chiar în procesul de exploatare. Au fost situații în care trecerea la dezvoltarea de aplicații onliine, produse software foarte bune au fost abandonate în favoarea celor care se exploatau accesînd Internetul.
Scoaterea din uz a unui produs software este un proces natural, uneori de neînțeles când se știe că produsele software nu au uzură fizică. Uzura morală le ucid. Informatica are o serie de particularități ce trebuie înțelese și acestea se răsfrâng și asupra identificării momentului optim de înlocuire al unui produs software, moment care se calculează cu totul altfel decât la un utilaj din industrie, unde randamentul și cheltuielile de întreținere sunt esențiale. În informatică sunt situații în care un produs software dispare chiar dacă este perfect și cheltuielile de mentenanță sunt nule, dacă durata mediei a tranzacției sale este de 5 ori mai mare decât durata medie a tranzacției oricărui produs similar din piață.

(29 noiembrie 2017)

Descrierea problemei

Descrierea problemei nu este o treabă ușoară așa cum cred foarte mulți diletanți. O problemă este:

• definită, adică descrisă complet, ceea ce înseamnă că atunci când se trece la etapele următoare există toate elementele necesare și nu mai este nevoie să se mearbă la beneficiar pentru a obține noi detalii, pentru a corela anumite elemente sau pentru a verifica dacă au fost înțelese corect unele aspecte; cei care au mers la beneficiar știu meserie și au avut arta de a pune întrebările care le-au permis înțelegerea și corelarea tuturor aspectelor încât sunt precizate în detaliu și corect toate aspectele legate de datele inițiale, de prelucrări și de rezultatele finale;
• subdefinită, ceea ce înseamnă că nu sunt toate elementele necesare pornirii activităților din celelalte etape; de regulă, atunci când problema este subdefinită lipsesc date de intrare, structurile indicatorilor nu conțin toate variabilele, lipsesc detalii din prezentarea rezultatelor; de regulă beneficiarii și specialiștii de acolo sunt prea familiarizați cu problemele și au impresia că tot ceea ce știu ei trebuie să știe toată lumea, ceea ce nu este real; cei care vin de la dezvoltatorul de software trebuie să știe să coreleze ceea ce află în așa fel încât să nu aibă pete albe în notițele lor și lucruri care nu se leagă; în caz contrar, ei trebuie să revină la beneficiar pentru a face completări și chiar corecții dacă ei nu au înțeles bine; să se ajungă într-un număr minim de iterații ca problema să fie complet definită;
• supradefinită, în cazul în care specialiștii se repetă sau spun lucruri echivalente sau lucruri redundante; uneori se întâmplă ca unele aspecte să se bată cap în cap și să apară elemente contradictorii, elemente dublate sau unele aspecte definite care nu sunt utilizate mai departe; în toate cazurile este nevoie de a peria toate acele lucruri în plus și să se ajungă într-un număr minim de iterații ca problema să fie complet definită.

Calitatea definirii crește pe măsură ce se capătă experiență și mai ales pe măsură ce această etapă primește importanța cuvenită. Este dramatic dacă problema este greșit definită și se identifică greșelile undeva în faza de testare a produsului, pentru că trebuie reluată munca de redefinire a soluției de recuperare a ceea ce este de recuperat din textele sursă, iar ceea ce trebuie refăcut se reia de la zero, iar testarea se va face ca și cum nu s-ar fi făcut nimic până atunci. este exact situația pe care o întâlnește croitorul acre a tăiat după tipare greșite și caută să remedieze costumul care este deja însăilat, vâzând la o primă probă că atârnă lălâu pe client.

(29 noiembrie 2017)

Ciclul de viață la software

Ciclul de viață la software trebuie studiat ca atare și trebuie făcută diferența între ceea ce se înțelege prin ciclu de viață în marketing și ce îmțelegem noi cei din informatică. 

În vremurile de demult, unde empirismul era la el acasă, ciclul de viață exista independent de ce gândeau programtorii și aceștia nu făceau nicio planificare legată de:

- durata de utilizare a programului;

- cheltuielile de mentenanță; când și de ce va fi scos din uz programul.

Totul mergea natural, după voința Domnului și viața mergea înainte. mentenanța se făcea perpetuu căci programul era de neconceput să funcționeze independent de programator. În plus, programul avea în anii '70 atâtea imperfecțiuni încât obiectiv vorbind nu avea cum să funcționeze independent de programator.

În marketing, ciclul de viață se referă la intervalul care începe de la momentul intrării pe piață a produsului, până scoatera lui de pe piață din cauză că nu mai este căutat de nimeni. În marketing există un grafic cu o curbă ascendentă, care se aplatizează după ce a atins un maxim și apoi coboară. Acolo se vorbește despre lansarea produsului, creșterea vânzărilor produsului, maturitatea produsului, despre deprecierea produsului și despre dispariția produsului.

În informatică prin ciclu de viață de înțeleg perioadele de:

- realizare;

- implementare;

- utilizare;

- mentenanță;

- reinginerie;

- scoatere din uz.

Este o structură ceva mai complicată întrucât include și procesul de producție, ceea ce în parketing nu se regăsește. Se datorează aici faptului că în vremurile de demult nu prea erau separate părțile care reperezentau producția de cele ce erau utilizare, iar mentenanța și reingineria tot programare fiind, totul era un talmeș-balmeș.

Trebuie spus că din 100% produse software pornite a fi construite doar 5% intră în reinginerie, cam 3% sut scoase din uz după procesul de reinginerie, cam 15% ies din uz chiar în procesul de mentenanță. cam 20% din programe nici nu intră în implementare, 30% se pierd în timpul utilizării. deci lucrurile nu sunt roze câtuși de puțin în zona software, dar este firex să fie așa, căci și în industria porțelanului sunt mărci celebre unde în mod curent rebuturile nu scad sun 13%.

Să vedem dacă cineva are curajul să facă un inventar al produselor software produse de un dezvoltator și să scrie în dreptul fiecăruia stadiul în care se află pe etapele ciclului de viață software...

În cartea referită prin:
Carlo Ghezzi,‎ Mehdi Jazayeri,‎ Dino Mandrioli - Fundamentals of Software Engineering, 2nd Edition, Prentice Hall, 1991,624 pg.
Ciclului de viață i se rezervă chiar primul capitol, pentru a clarifica exact cum stau lucrurile.
1 The Life Cycle of Software  Cost development in Computer Systems
1.1 Classic Errors in Software Design
1.2 The Impact of Errors on the Production Process
1.3 Commercial Aspects 

în lucru acum

(29 noiembrie 2017)

Definirea obiectivului

Istoria informaticii este bântuită de modalități dintre cele mai diverse de a defini obiectivul unui progra. În vremurile de început ale programării lucrurile erau foarte simple căci un program realiza, de asemenea, prelucrări simple. Se scriau programe pentru probleme precis definite căci restricțiile de memorie ale calculatorului nu permiteau mai mult.
Când a apărut limbajul COBOL deja se lucra cu colectivități ale căror elemente erau reflectate în fișiere. Din enunțul obiectivului rezulta totul și existența fișierelor și ce prelucrări esențiale se făceau. La fel s-a întâmplat la apariția SGBD-urilor căci numai indicând în obiectiv cuvântul SOCRATE totul se lămurea ca prin farmec și se creiona din start schema sistemului software.
Definirea obiectivului este cel mai important lucru căci de la el se dezvoltă totul. Definirea obiectivului se face într-o propoziție precum:

Realizarea unui produs software pentru calculul online a salariilor.

Realizarea unui produs software pentru reparațiile capitale.

Realizarea unui produs software pentru optimizarea stocurilor de materiale.

Realizarea unui produs software pentru evidența contractelor.

Realizarea unui produs software pentru managementul de documente.

Realizarea unui produs software pentru modelarea econometrică.

Realizarea unui produs software pentru estimarea coeficienților ecuației de regresie.

Realizarea unui produs software pentru implementarea metodei celor mai mici pătrate în două trepte.

Realizarea unui produs software pentru inversarea unei matrice.

Realizarea unui produs software pentru calculul pseudoinversei.

Realizarea unui produs software pentru rezolvarea online a ecuației de gradul al doilea.

Realizarea unui produs software pentru calculul online al creditului maxim în condiții date.

Realizarea unui produs software pentru achiziționarea de bilete de avion la preț minim.

Realizarea unui produs software pentru lucru cu matrice rare.

Obiectivul este unic și trebuie să răspundă la niște întrebări precum:

- ce să se facă?

- cu ce?

- cine?

- când?

Când spunem realizarea se răspunde la întrebările ce se face? și când? adică acum.  Câns spunem produs software se răspunde la întrebarea ce să se facă?, iar când spunem matrice rare răspundem la întrebarea cu ce ?. Când spunem lucru răspundem la întrebarea ce prelucrări se vor face, adică citiri, copieri, ștergeri, inserări de linii, de elemente, de coloane în matricea rară, construirea matricei transpuse, operații de adunare, cădere, înmulțire, calculul a tot felul de norme, ridicarea la puterea n dacă este matrice pătrată și de calcul a  inversei matricei rare pătrate. Dacă am fi scris acolo calculul, ar fi fost restrâns rolul programului la  operații de adunare, cădere, înmulțire și de calcul a  inversei.

Obiectivul nu trebuie să fie ambiguu prin introducerea conjunției sau. Nu trebuie să fie lălăit cu o frază kilometrică de nu mai înțelege nimeni nimic.
Definirea obiectivului este esențială când se pornește la lucru în munca de propară cuvântul online în obiectiv și cu totul altfel stau lucrurile când acesta lipsește.

(29 noiembrie 2017)