Thursday, November 30, 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)

Wednesday, November 29, 2017

Structuri de date și literatură

Structurile de date și literatură oricât s-ar părea de bizar, ele există și lumea trebuie să știe de ele. Marele Mihail EMINESCU a folosit stiva în mod magistral.
În Glossa prima strofă este:
Vreme trece, vreme vine, 
Toate-s vechi si noua toate; 
Ce e rau si ce e bine 
Tu te-ntreaba si socoate; 
Nu spera si nu ai teama, 
Ce e val ca valul trece; 
De te-ndeamna, de te cheama, 
Tu ramâi la toate rece.
Ultima strofă este:
Tu ramâi la toate rece, 
De te-ndeamna, de te cheama: 
Ce e val, ca valul trece, 
Nu spera si nu ai teama; 
Te întreaba si socoate 
Ce e rau si ce e bine; 
Toate-s vechi si noua toate: 
Vreme trece, vreme vine.
Ultimul vers devine primul vers în ultima strofă. Penultimul vers din prima strofă devine al doilea vers în ultima strofă, deci se aplică regula ultimul venit, primul servit, ceea ce corespunde traversării unei stive, după regula LIFO - Last-in-First-out.
Poetul George Coșbuc a scris versurile din poemul Nunta Zamfirei:
Trei paşi la stânga linişor
Şi alţi trei paşi la dreapta lor;
Se prind de mâini şi se desprind,
S-adună cerc şi iar se-ntind,
Şi bat pământul tropotind
În tact uşor.
Cuvintele S-adună cerc înseamnă că se crează o listă circulară dublu înlănțuită. Cuvintele şi iar se-ntind arată că lista circulată se transformă în listă liniară dublă. Versul Trei paşi la stânga linişor arată cum se traversează lista de la dreapta spre stânga. Versul i alţi trei paşi la dreapta lor evidențiază traversarea listei duble de la stânga spre dreapta. Cuvintele se desprind arată operația de deconcatenare, iar cuvintele Se prind de mâini arată că fora are o operație de concatenare a mai mltor liste duble.
Și la definirea structurii de tip articol lucrurile stau tot în spirit dacic. Construcția unei expresii de referire este una, dar citirea este extrem de interesantă.
Expresia:
 nume1.nume2.nume3
merită un studiu aparete, căci iată cum se interpretează expresia:
deal.Mărin.Leana
dacă se traversează de la dreapta la stânga: Leana lu'Mărin din deal. Și numele irlandezilor cu acel O urmat de un apostrof tot cam pe acolo este, dar la noi este exact ce vor structurile de date.





(26 noiembrie 2017

Erorile de programare

Erorile de programare sunt nenumărate. Nu există activitate în scrierea programelor care să nu fie bântuită de erori.
Există mai multe criterii de clasificare a erorilor de programare, înțelegând aici doar activitatea desfășurată de programatori și nu și activitățile de analiză, de testare, de elaborare a documentației.
După criteriul nivelului de severitate se identifică:
- erori care deși sunt făcute, programul intră în execuție și rezultatele sunt complete și corecte;
- erori de logică, care duc la obținerea de rezultate uneori corecte, alteori incorecte;
- erori care duc la întreruperea execuției programului după efcetuarea parțială a prelucrărilor;
- erori din cauza cărora programul nu trece de compilare;
- erori din cauza cărora programul nu trece de editarea de lebături;
- erori în cartelele de comandă și se obține doar o mică fâșioară de hârtie.
După tipul erorilor se identifică:
- erori sistematice făcute de programator că neglijează exact mereu același lucru;
- erori întâmplătoare din faptul că uită ceva din definiri sau din formulele de calcul.
După cauzele care produs erorile de execuție se identifică:
- erori de alegere a tipului în raport cu utilizarea;
- utilizarea de variabile nedefinite;
- depășirea domeniului de definire a structurilor la derularea secvențelor repetitive;
- lucru cu variabile neinițializate;
- ciclarea infinită din neinițializarea variabilei de control;
- expresii condiționale care fac selecții incomplete;
- neconcordanțe între listele de parametri ai procedurilor;
- împărțirea la zero.
După locul unde s-au produs erorile se identifică:
- erori de definire a problemei;
- erori de elaborare specificații;
- erori de construire a soluției;
- erori de scriere a textelor sursă;
- erori de testare mai ales incompletă;
- erori de elaborare a documentației;
- erori de implementare;
- erori de utilizare;
- erori de mentenanță.
A porni de la efect la cauză este singura modalitate de a face depanare. Dacă se dorește să se facă depanare eficientă trebuie să se facă și calcule de probabilități ca la stabilirea diagnosticelor în medicină, mergând de la efect spre cauza cu probabilitatea cea mai mare. Rând pe rând se trece la cauzele cu probabilități mai mici, dar în niciun caz nu se va merge din start pe cauza cu probabilitatea cea mai scăzută de producere a erorii.
Acum mulți ani am scris un articol după ce au fost făcute statistici ale erorilor de programare, analiza fiind foarte utilă în creșterea eficienței procesului de depanare a programelor referit prin : Al. Balog, A. Ivan, M. Macesanu - Analiza statistică a erorilor specifice produselor-program, Revista de statistică nr. 10/1985, Bucureşti, pg. 27-37.




(28 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)


Tuesday, November 28, 2017

Societatea Conștiinței

În anul2015 s-a desfăşurat A IV -a Teleconferinţă internaţională a tineriloccercetători având ca temă Crearea Societăţii Conştiinţei, a cărei coordonare a fost asigurată de profesorul universitar doctor Dumitru TODOROI de la Academia de Studii Economice din Republica Moldova. Au colaborat în vederea atingeriiscopului propus cadre didactice de la Academia de Studii Economice  a Moldovei, Universitatea Vasile Alecsandri din Bacău, Academia de Studii Economice  din Bucureşti, Illinois State University din Chicago, Universitatea Al I. Cuza din Iaşi, Academia de Muyică Gh. Dima din Cluj-Napoca şi Acadeimia Româno+Americană de Ştiinţe şi Arte din Los Angeles.
În şedinţa plenară au preyentat comunicări Radu MIHALCEA, Elena NECHITA, Dumitru TODOROI, Xenia ERIOMENCO şi Nicoleta TODOROI.
Conferinţa a avut trei secţiuni şi anume:
 ROBO - inteligenţe în Societatea Conştiinţei
Sisteme informatice în Societatea Cunoaşterii şi a Conştiinţei
Sustenabilitatea Sistemelor sociale în Societatea Viitrului.
La şedinţa finală au participat preşedinţii şi co-preşedinţii de secţiuni Dumitru TODOROI, Ruxandra VIDU, Radu MIHALCEA, Ion SMEUREANU, Elena NECHITA şi Sabin BURAGA.
O particularitate a acestei teleconferinţe este aceea că autorii articolelor s-au aflat fiecare la ora stabilită în legătură directă cu ceilelalte centre, au prezentat comunicările, după are ceilalţi colegi din Iaşi, Bacău, Cluj, Chicago, Los Angeles, Bucureşti şi Chişinău au adresat rând pe rând întrebările iar autorii au dat răspunsuri. Discuţiile au fost vii, la obiect şi totul a fost susţinut cu argumente solide. 
Remarc faptul că doctorandul meu pe atunci, doctor în informatică economică acum, Eduard HERŢELIU a pre4zentat lucrarea The processes of Auditing Citiyen Oriented Software Metrics, unde soluţiile orginale propuse au fost bine primite de auditoriu. Lucrarea se află la paginile 61 - 65 în volum.
Succesul acestei ediţii i-a îndreptăţit pe organiyatori să continue acest demers şi în anul 2017, în yilele de 21 şi 22 aprilie s-a desfăşurat A VI-a Teleconferinţă internaţională a tineriloccercetători având ca temă Crearea Societăţii Conştiinţei în care direcţiile de cercetare au fost  Robotizarea Societăţii Conştiinţei, Sisteme informatice in Societatea Conştiinţei, Informaţia, Cunoaşterea si Conştiinta robotică şi Robotizarea, Întreprinderilor Mici şi Mijlocii
Într-un viitor apropiat un nou număr al revistei Society Consciousness Computers va fi dedicat publicării lucrărilor acestei Teleconferinţe.










(28 noiembrie 2017)

Centrul de calcul de la Semănătoarea

Centrul de calcul de la Semănătoarea a soluționat nenumăratele probleme acelui colos industrial destinat construcției de mașini agricole din țara noastră. Am avut ocazia să lucrez cu Sergiu COMAN când era student și mult mai târziu mi-a fost doctorand. El a lucrat ani în șir la Centrul de calcul de la Semănătoarea și l-am rugat să scrie ceva despre acest Centru de Calcul.

Nu stiam anul de infiintare; am tot incercat sa aflu anul infiintarii Oficiului de Calcul Semanatoarea.  Pe Internet practic nu existam.  Eu am ajuns la Semanatoarea in 1977 prin repartitie. Am prins aseara la telefon un fost coleg – Ulici Gheorghe .  
Mi-a zis ca Oficiul de Calcul exista in 1972 (nu mai stie daca sub acest nume). Primul sef, dl. Pelin Nicolae, a facut mai multe cursuri la CEPECA  (probabil pe programul PNUD - Programele de perfec?ionare în conducerea ?i organizarea întreprinderilor
https://ro.wikipedia.org/wiki/Centrul_de_perfec%C8%9Bionare_a_cadrelor_de_conducere_din_%C3%AEntreprinderi).  Ca estimare, cred ca anul 1971 este anul de infiintare.
Era o perioada in care nu se stia practic care ar fi rolul informaticii in intreprindere.  Un fel de oaie neagra, sau mai degraba alba deoarece analistii-programatori aveau o treapta mai sus de salarizare decat economistii si unii incercau (cu succes) sa faca, pt o scurta perioada, acest pas.
Treptat s-au angajat oameni; printre primii specialisti, se numarau Diciu Nicolae si Angheluta Gelu.  S-a inceput pe doua directii principale: scolarizare personal si codificarea materialelor, serviciilor si produselor.  
Pentru scolarizare, in anii ’70 si ’80 s-a apelat la CEPECA, ICI si Ministerul Industriilor. 
Pentru codificare, o actiune preliminara, foarte grea, dar de importanta majora pe acele timpuri, s-a colaborat cu S.C. ICTCM (Institutul de Cercetare si Proiectare Tehnologica pentru Constructii  de Masini) S.A  Bucuresti – un colectiv condus de dl ing. Dinca.
S-a colaborat si cu CEPECA - Colectivul de Analiza pentru aplica?ii ?i Serviciul de Programare aplica?ii P.A.D. pentru activitatea de consultan?a in elaborarea proiectelor de sisteme informatice ?i programarea de aplica?ii specifice.
Dupa toate aceste actiuni si odata cu sensibilizarea conducerii intreprinderii si a catorva oameni cheie din compartimentele intreprinderii, s-a inceput timid proiectarea primelor aplicatii.  Era chiar foarte necesar avand in vedere complexitatea produselor intreprinderii, complexitatea si multitudinea proceselor tehnologice, a numarului mare de articole ce trebuiau gestionate in perioade tot mai scurte de timp. 
Ca prime aplicatii s-au proiectat de catre specialistii Oficiului de Calcul ‘Gestiunea stocurilor de materiale’  si ‘Gestiunea fiselor tehnologice.  Ca limbaj de programare s-a folosit COBOL, iar executia lucrarilor se facea pe calculatoarele FELIX de la Academia Stefan Gheorghiu (erau cel apropiate de sediul nostru – se traversa practice Politehnica).  ‘Gestiunea stocurilor de materiale’ , inclusive contabilitatea acestora se facea prin programe proprii Semanatoarea si prin programe create de specialistii de la Centrul de Calcul si Lucrari auxiliare PAMID; cea mai mare parte a executie se face ape calculatoarele acestora. Tot PAMID, a sigurat prin programe proprii, calculul manoperii si a salariilor realizate de muncitorii direct productivi din sectile de productie.   
In primii ani s-au achizitionat si primele echipamente de tehnica de calcul; sase masini de perforat  / verificat cartele Juki si Soemtron si un sortator de cartele  perforate.
Erau circa 10 analisti-programatori, inclusiv ajutori, si circa 10 operatori  perforare date pe cartele si verificare date.
Aceasta era situatia in anul de gratie 1977.  
Treptat, in anii urmatori, s-au proiectat cu resurse proprii multe alte aplicatii cerute de catre Ministerul Industriilor. Acesta stabilea gradul unitatii  pentru Oficiile de calcul si Centrele de calcul din intreprinderile ministerului; gradul era de mic (pt maxim 5 specialisti – in Oficiile de Clcul), mediu sau mare (de ex. Tractorul si Steagul rosu erau Centre de Calcul mari – aveau 1 Atelier de Analiza (min 25 oameni) si 2 Ateliere de Programare  (min 25 oameni fiecare), plus specialistii necesari exploatarii calculatoarelor mainframe proprii – practic peste  150 de oameni si mai multe pozitii de conducere).  Tot Ministerul Industriilor  stabilea si aplicatiile ce trebuiau realizate de fiecare unitate informatica din minister, graficul de relizare a acestora si o forma mai simplificata a documentatiei aplicatiilor informatice.
Noi eram incadrati la Oficiu de Calcul mare; aplicattiile acopereau aproape toate activitatile intreprinderii si au fost realizate mereu in avans fata de graphic. Unele aplicatii realizate de noi, utile intreprinderii, nu erau cerute expres de minister si au fost practice premiere in minister, tara si chiar in tarile socialiste. Una dintre acestea a fost ‘Controlul statistic al productiei’ realizata de mine impreuna cu dl. Mathematician Tatulesc Nicolae de la Institutl de Matematica. Alta a fost ‘Realizarea fiselor tehnologice, croirea reperelor si normarea automata a muncii pentru reperele executate din table prin gilotinare’ , raelizata prin colaborare de catre dl. Fabian Csaba, o specialista de la ICTCM si de mine.
Pana in 1990, intrepinderea mai achizitioneaza terminale cu discuri flexibile pentru culegerea datelor  si un minicalculator Coral destinat sustinerii activitatii de proiectare.
Aplicatiile realizate au fost urmatoarele, conform organizarii proprii (nu cea clasica), statuata in intreprindere:
1.       Domeniul PRODUCTIE   
a) Calculul necesarului de fabricat (lansator)
b) Incarcarea capacitatilor de productie
c) Calculul necesarului de aprovizionat
d) Calculul necesarului de alte resurse
e) Lansarea in fabricatie
f) Gestiunea stocurilor intermediare
g) Urmarirea productiei fizice, asortare
h) Urmarirea productiei valorice
i) Controlul de calitate
j) Asigurarea cu utilitati
k) Evidenta fondurilor fixe
l) Urmarirea indicilor de utilizare fondurilor fixe
m) Intretinerea echipamentelor
n) Analize economice
o) Gestiunea bazelor de date necesare
2.       Domeniul  APROVIZIONARE
a) Gestiunea stocurilor
b) Gestiunea comenzilor/contractelor
c) Gestiunea cooperarilor
3.       Domeniul DESFACERE- MARKETING
a) Calculul necesarului de fabricat
b) Urmarirea comenzilor/contractelor
c) Facturare
d) Urmarirea facturilor clientilor
e) Gestiune stocuri produse finite si piese de schimb
 f) Ofertare
g) Gestiunea transporturilor
h) Service
i) Analize de pret, analize economice
j) Prognoze marketing
k) Gestiunea comenzilor/contractelor
4.       Domeniul PERSONAL    
a) Evidenta
b) Salarizare
c) Instruire asistata de calculator
5.       Domeniul FINANCIAR- CONTABILITATE
a) Contabilitate generala
b) Contabilitate analitica
c) Bilant contabil
d) Gestiunea patrimonului
e) Gestiunea efectelor bancare
f) Financiar (Œncasari, plati, etc.)
g) Preturi de cost
h) Gestiunea investitiilor
i) Analize economico-financiare
6.       Domeniul CERCETARE- PROIECTARE           
a) Proiectare asistata a produselor,  ansamblelor si reperelor
b) Editarea desenelor de executie
c) Editarea nomenclatorului de produs
d) Proiectare tehnologica
e) Intocmirea documentatiei de insotire a produselor
7.       Domeniul GESTIUNE  DOCUMENTARA (partial)
a) Procesare de text
b) Posta electronica
c) Clasificare si evidenta documentara
d) Baze de date documentare
 Dimensionarea fisierelor / a bazei de date este prezentata in continuare:
 1.  Articole nomenclator                        60.000     
2.  Structura articole                             200.000      
3.  Tehnologii                                          600.000  (~10 operatii/reper)     
4.  Mixloace fixe                                       10.000
5.  Nomenclator materiale                     25.000
6.  Colaborari productie                             3.000
7.  Consumuri specifice de materiale  200.000
8.  Lansator productie                             120.000
 9.  Tehnologii lansate                             120.000 (~10.000/luna)
10.  Miscari de materiale                       120.000 (~10.000/luna)
11.  Note de predare                              300.000 (~10.000/luna)       
12.  Personal                                              12.000
13.  Facturi emise                                     10.000
14.  Facturi furnizori                                50.000
15.  Clienti/furnizori                                 10.000 
16.  Produse finite si Piese de Schimb    5.000
Dezvoltarea Sistemului informatic s-a desfasurat in trei etape mari:
1.     Perioada COBOL ; s-a desfasurat de la inceputuri (1973 – primele programe) si pana in 1991. S-a caracterizat prin fisiere independente si aplicatii practic neintegrate interactiv. Este o perioada de glorie a informaticii, specialistii de la acea data au avut oportunitatea de a proiecta aplicatii ce au constituit trecerea de la un system informatics manual / partial mecanizat, la un system informatic propriu-zis. In 1990 iese la pensie dl. Pelin si castig eu postul de sef. Erau ~ 70 de oameni in Oficiul de Calcul, din care ~35 analisti programatori si ajutori. In scurt timp se definitiveaza achizitia a doua calculatoare FELIX -5000 si amenajarea salii calculatoarelor. Se angajeaza doi oameni de baza, doi ingineri de sistem: hardware – dl. Sararu Cornel si software – dna. Buta Lucia.  In colaborare cu specialistii fabricii de calculatoare si a specialistului software in mainframe FELIX (dl. Codrut Iancu), acestea se pun rapid in functiune. Cu harddiscurile achizitionate (cu greutate – inceputul anului 1991) de intreprindere si ajutorul specialistilor mai sus anuntati, se creaza cuplorul de HDD si se schimba discurile amovibile cu HDD-uri. Pratic se creaza cele mai moderne calculatoare din tara la acel moment, dar probabil si printre ultimele.  Incepuse degringolada intreprinderilor (de stat), cu diminuarea drastica a productiei si reducerea numarului de personal.

Aplicatiile proiectate de CCLA Pamid se reproiecteaza si se ajunge la situatia in care toate aplicatiile sunt proiectate de specialistii intreprinderii si executate pe calculatoare proprii.
Lansarea  si urmarirea unei comenzi de fabricatie,  pentru un  produs de serie (combina), necesita utilizarea unui numar  de aproximativ  5.000  de articole nomenclator, 8.000 de  legaturi  de structura articole, tehnologii de fabricatie pentru un numar de circa  3.500 repere/ansamble cu 50.000 de operatii tehnologice,  un numar de aproximativ 4.000 consumuri specifice de materiale, circa 8.000 note de predare, etc.
Lunar se lansa o comanda pentru un produs si  una de  piese  de schimb, cu revenirile  respective  asupra  lansarii initiale. 
2.     Perioada SOCRATE; s-a desfasurat intre anii 1992 si 1994. Cerintele de informatii si complexitatea activitatii intreprinderii au impus integrarea datelor in baze de date. S-a ales SOCRATE, disponibil pe mainframurile FELIX. S-a inceput in 1991 pregatirea catorva specialist ai Oficiului de calcul in limbajul SOCRATE, cu ajutorul CEPECA, dl. Ion Costescu si dl. Gutu. Tot cu ajutorul dansilor s-a proiectat si baza de date. SOCRATE a reprezentat un pas urias pt noi. Produsele intreprinderii erau produse complexe, cu cateva mii de reper desfasurate / inlantuite pe circa 7 niveluri, intr-o retea. O cerinta curenta era executia exploziei unui produs care se realiza greu in COBOL, atat ca durata cat si complexitate; in SOCRATE, se executa recursiv foarte usor si imediat prin doar 4 instructiuni. Plus avantajul executarii imploziei unui reper; aflai imediat de cate repere de acelasi fel e nevoie intr-un produs sau in mai multe produse ale planuluide fabricatie.
3.     Perioada Baze de date PC; incepe in 1995 si continua si dupa anul 2000 (cand intreprinderea se privatizeaza si plec eu). Toata proiectarea a fost asigurata de specialistii Oficiului de calcul Semanatoarea. Se creau documentatii (simplificate) de aplicatii, cu schemele aferente de system, parti ale schemei de sistem generala a sistemului informatic Semanatoarea. In 1991 s-au achizitioanat primele PC-uri (286/SX). In 1994 s-a continuat achizitia de PC-uri Compaq si IBM cu care s-a inceput instruirea personalului ramas si realizarea primelor aplicatii pe PC. S-a ales limbajul dBase V, cu raportul pret / performant cel mai bun la acea data. Permitea identificarea operatiei efectuate pe un articol si a celui ce a efectuat-o, data, ora, tranzactii, etc.
Dificultatile mentenantei calculatoarelor Felix, presiunea pe reducerea personalului, au impus trecerea la o retea de PC-uri si un limbaj de baze de date.  Reteau a constat in ~100 PC-ri, cea mai mare parte HP 486/DX2, un server HP LF/100, soft de retea NOVEL si toate echipamentele si componentele adiacente acesteia. Acest pas a constituit un salt important al informatizarii; salariatul putea executa de la biroul sau sarcinile de servici, rapid, in colaborare cu ceilalti salariati inclusi in sistemul informatic.
Pentru proiectarea asistata a produselor  s-au achizitiona ~10 PC DELL performante si software Autocad. S-a putut efectua inclusiv verificarea pe calculator, in dinamica, a modificarilor efectuate asupra reperelor si ansamblelor componente unui produs.
In anul 2000, dupa privatizare, la Semanatoarea au mai ramas 800 salariati, iar la Oficiul de Calcul doar 4. In anii de glorie, anii 80’, intreprinderea avea 7.800 salariati.
Practic am condus (oficial) Oficiul de Calcul direct si indirect, intre anii 1990 si 2000; in perioadele cand am condus serviciul Organizare, Strategie, Actionariat sau directia Economica, am tinut Oficiul in subordinea mea (indirecta, cu titular dl. Diciu Nicolae).
 Anexa
Semanatoarea Bucure?ti a fost o fabrica producatoare de ma?ini agricole din România. A fost singurul producator român de combine de recoltat, iar principalii concuren?i erau producatorii straini: New Holland, John Deere si Claas.
https://www.youtube.com/watch?v=v2-60gK_DLQ
S.C. Semanatoarea S.A. a luat fiinta in anul 1949 din fosta intreprindere FICHET. In perioada ulterioara a intreprinderii SEMANATOAREA se disting 5 perioade importante:
- 1949 – 1955 - Perioada semanatorilor si seceratorilor tractate: semanatori pentru paioase pe 24 randuri, semanatori pentru porumb pe 2 randuri, seceratori-legatori pentru paioase.
- 1956 – 1968 - Perioada combinelor tractate si a semanatorilor de precizie: combine tractate pentru cereale paioase si stiuleti nedepanusati CT2; CT2RP, semanatori de precizie pentru plante prasitoare, alte masini agricole.
- 1969 – 1980 - Perioada combinelor autopropulsate pentru recoltat cereale: combina autopropulsata C12 (licenta LAVERDA), variante derivate din C12, combina autopropulsata pentru pante CP12, combina autopropulsata pentru recoltat stiuleti depanusati CARP 4.
- 1981 – 1988 - Perioada combinelor autopropulsate modernizate in gama extinsa: combine autopropulsate de recoltat cereale paioase, combina autopropulsata pentru recoltarea integrala a porumbului, instalatie de irigare prin aspersiune IATF – 300, batoza de cereale paioase B90, masina de treierat fasole MTF14.
- Dupa 1989 - Perioada gamei extinse de masini agricole: gama de combine autopropulsate de recoltat cereale derivate din C12M (licenta LAVERDA): SEMA 140M, SEMA 12M, SEMA 80, gama de combine autopropulsate de recoltat cereale, echipamente specializate pentru recoltat floarea soarelui si porumb, semanatori modernizate, cositori pentru furaje, utilaje agricole pentru uz gospodaresc si noua gama de combine autopropulsate de recoltat cereale Dropia si Gloria. Gloria C12 este o combina autopropulsata ce a intrat in productie din anul 1969. Modelul Gloria CP12 este varianta de combina autopropulsata pentru pante derivat din C12.


Rafael Ban


Published on Dec 30, 2015


(28 noiembrie 2017)

Centrul de Calcul al ICI

Eu am mers de nenumărate ori în ICI și am văzut foarte exact ceea ce era Centrul de Calcul al ICI mai ales înainte de 1989. Prietenul meu George MATEI a lucrat acolo și l-am rugat să scrie câteva rânduri, pe care cu permisiunea lui le redau aici.

Am lucrat ca analist la Centrul de Calcul al Institutului Central pentru Conducere si Cercetare (ICI) între 1978 si 1985. Organigrama centrului de calcul cuprindea:
un atelier de analiza;
doua ateliere de programare;
o sectie de exploatare, cu urmatoarele compartimente/colective:
- ingineri de sistem;
- operatori-calculator;
- operatori perforare-verificare.
În cadrul centrului de calcul se proiectau si dezvoltau lucrari informatice pentru diversi beneficiari, unitati economice. Lucrarile nu se efectuau pe flux între atelierele de analiza si programare. În functie de încarcarea atelierelor la un moment dat, un nou contract era atribuit unui atelier sau altul. Erau si contracte la care lucrau echipe mixte, din doua ateliere.
Fiecare echipa/colectiv lucra la contractul repartizat din faza de analiza pâna la implementarea produsului informatic dezvoltat. Pe parcursul derularii contractelor echipele erau relativ stabile. Sufereau modificari în etapa de programare, când erau integrati în colectiv programatori ajutori, sau când apareau sarcini noi sau se schimbau prioritatile celor existente.
Lucrarile efectuate se încadrau în categoria sistemelor/aplicatiilor de gestiune, motiv pentru care erau dezvoltate în limbajul Cobol si se executau pe calculatoare din familia Felix (256/512/1024). Fiind produse în tara, acestea erau calculatoarele cu care erau dotate, în principal, întreprinderile economice cu centre sau oficii de calcul.
Pentru a putea fi rulate, programele erau transpuse pe cartele perforate. Dupa depasirea fazelor cu erori de compilare sau linkeditare, programele erau salvate pe benzi magnetice sub forma de proceduri catalogate, de unde se apelau la rularile ulterioare. Cartele perforate erau folosite si ca suport pentru crearea fisierelor de date, care erau salvate pe benzi magnetice.
Dezvoltarea produselor informatice se facea conform metodologiei ICI de realizare a sistemelor informatice. Conform acestei metodologii, pentru realizarea unui produs informatic se parcurgeau mai multe etape, fiecare etapa finalizându-se cu o documentatie specifica. Pe baza acestor documentatii se facea avizarea fiecarei etape în comisiile tehnice de avizare din cadrul ICI, cât si de catre beneficiarul produsului. Odata avizate, aceste documentatii deveneau specificatii de intrare pentru urmatoarea etapa.
Etapele metodologiei ICI si documentatiile aferente erau:
analiza de ansamblu: proiect de ansamblu;
analiza de detaliu: proiect de detaliu;
proiectarea produsului: proiect tehnic;
programare: manual de realizare;
implementare: manual de utilizare, manual de exploatare.

Pâna la jumatatea anilor ’80 în cadrul Centrului de Calcul ICI au fost realizate mai multe sisteme informatice. Un astfel de sistem a fost cel proiectat pentru  UCECOM, un sistem multinivel bazat pe componente modulare cu mare grad de generalitate. Sistemul informatic proiectat se compunea din urmatoarele subsisteme:
productie – prestari servicii;
exploatare, tehnic, întretinere, consumuri;
financiar-contabilitate;
personal-retribuire (planificarea fortei de munca; planificarea fondului de retribuire);
jurnal de bord, optimizari, corelatii.
Un alt sistem informatic proiectat a fost cel pentru Întreprinderea de Transport Bucuresti (ITB), unde principalele subsisteme dezvoltate au fost:
planificarea, lansarea si urmarirea transportului urban de persoane;
planificarea, lansarea si urmarirea reparatiilor;
evidentq personalului.
Alte sisteme informatice care pot fi amintite sunt cele dezvoltate pentru întreprinderile Policolor, Metrou Bucuresti, Dunareana Giurgiu (industria textila) sau Întreprinderea de Transporturi Speciale pentru Agricultura si Industria Alimentara (ITSAIA).
Dupa cum am mentionat, majoritatea produselor informatice realizate în Centrul de Calcul ICI se construiau în limbajul Cobol, cu fisiere clasice. Cu toate acestea, spre mijlocul anilor ’80 s-au abordat si sisteme de baze de date. Astfel, suportul de date al sistemului informatic proiectat pentru întreprinderea Neferal l-a constituit o baza de date Socrate.
De-a lungul timpului, cele mai valoroase produse informatice dezvoltate atât în ICI cât si în centrele de calcul teritoriale si/sau departamentale au fost introduse în Biblioteca Nationala de Programe (BNP). Dintre aplicatiile economice introduce în BNP se pot aminte:
GESTOC: gestiunea stocurilor;
MIFIX: mijloace fixe;
CONTAB: contabilitate;
PERSORET: personal-retribuire.
În functie de cerintele beneficiarilor, se urmarea utilizarea acestor aplicatii. Avantajul consta în faptul ca nu se mai construiau aplicatii noi, ci doar interfete pentru integrarea lor în sistemele informatice proiectate, totul facându-se cu un consum mai redus de resurse.
Spre mijlocul anilor ’80, datorita dotarii unui numar tot mai mare de întreprinderi cu minicalculatoare, s-au proiectat tot mai multe produse informatice pentru acest timp de sisteme de calcul. Era vorba de minicalculatoarele Independent si Coral, care patrundeau tot mai mult în economie. Videoterminalele cuplate la aceste sisteme erau folosite atât pentru introducerea programelor si datelor (în locul vechilor sisteme cu cartel perforate), cât si pentru rularea programelor.
Centrul de Calcul al ICI a însemnat o pagină importantă a informaticii aplicate în producție din țara noastră. Cu o dotare foarte bună, cu specialiști de înaltă clasă, această unitate era o unitate de elită a informaticii, iar colaborarea cu Centrele teritoriale de calcul era specială, eficientă și mai ales productivă.
(28 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)

Lista aplicațiilor informatice

Lista aplicațiilor informatice este necesară pentru a vedea care sunt diferențele între ceea ce s-a făcut în informatică de-a lungul anilor.
Calculul de salarii.
Gestiunea mijloacelor fixe.
Gestiunea stocurilor.
Evidența bonurilor de consum.
Evidența de personal.
Gestiunea conractelor.
Centralizarea factutilor.
Gestiunea livrărilor.
Gestiunea calității.
Planificarea producției.
Calulul  capacitate.
Croirea optimă a barelor
Croirea optimă a reperelor dreptunghiulare.
Optimizarea rațiilor de consum.
Optimizarea producției.
Ordonanțarea producției.
Urmărirea producției.
Lansarea producției.
Urmărirea producției.
Controlul calității producției.
Rezervări  camere hotel.
Achiziții  bilete pentru...
Calcul deviz cheltuieli.
Optimizarea rutelor de transport.
Optimizarea amestecurilor de produse petroliere.
Calculul eficienței economice la...
Sistem expert pentru...
De când Internetul s-a răspândit peste tot au apărut aplicații care utilizează resursele acestuia.
Magazin electronic pentru...
Campul universitar al...
Plăți taxe și impozite.
Achiziții online bilete pentru...
Achiziționarea online de acțiuni pe bursă.
Rezervări online camere hotel.
Atribuire online de joburi.
Aplicație de e-Learning pentru...
Aplicație B2B pentru ...
Comandă online proiect de arhitectură.
Management întreprindere virtuală.
Management de documente.
Gestiunea intrărilor și ieșirilor în organizație.
Elaborare joc online.
Optimizare trasee turistice.
Prezentare locuri pitorești.
Scriere bloguri specializate.
Elaborare ziare online.
Elaborare cărți online.
Elaborare reviste științifice online.
Elaborare albume online cu fotografii tematice.
Testare online a cunoștințelor.
Reconstituire  online clădiri dărâmate.
Optimizarea online a alegerii unui credit bancar.
Programarea online la clinică.
Gestiunea online pacienților.
Utilizarea cardurilor de sănătate.
Asigurarea online de călătorie.
Achiziționarea online de suplimente.
Creare online cataloage roduse de...
Creare online cataloage  de materiale.
Creare online cataloage  filatelice
Muzeul virtual de .....
Expoziția virtuală de ....
Catalog online cu muzică.
Prezentare și vizonare filme online.
Crearea de arhivă pentru...
Accesarea online a arhivei de documente literare.
Accesarea online a arhivei de documente istorice.
Accesarea online a arhivei de manuscrise ...
Teleconferință online cu SKYPE multiplu.
Vot online.
Semnare petiție online.
Rețele de socializare.
Grupuri de lucru online.
Dezvoltare online de open source.
Evaluare online a proiectelor.
Emitere și transmitere de documente oficiale online semnate electronic.
Notar electronic.
Emitere cerfiticate online.
Optimizarea  online a traficului.
Plăți electronice.



Toate acestea au în față fie aplicație informatică pentru... fie subsistem informatic pentru .... fie soluție informatică pentru... fie bază de date pentru...
În timp această listă se va îmbogăți și cu alte aplicații pe măsură ce vor fi identificate. Este o certitudine că Lista aplicațiilor informatice este în continuă creștere din moment ce nici 5% din ceea ce aare nevoie societatea nu este realizat prin produse software.





(26 noiembrie 2017)

Sunday, November 26, 2017

Optimizarea transporturilor

Optimizarea transporturilor a fost, este și va fi o problemă în care informatica are multe de spus. Optimizarea transporturilor a fost o provocare în anii de început ai informaticii pentru că la transportul:
- sfeclei de zahăr către fabricile de prelucrare se punea minimizarea cheltuielilor de transport;
- produselor petroliere prin conducte se punea scăderea costurilor contaminării;
- materialelor de construcție se punea problema rutelor optime prin alegerea de străzi;
- mărfurilor de același tip produse de fabrici prin plan cu costuri de transport minime.
În realitate a defini o problemă de transport înseamnă a specifica:
- sursele de unde pleacă produsele;
- numărul de tipuri de produse;
- cantitățile de produse pe fiecare tip;
- destinațiile pe tipuri de produse;
- tipurile de mijloace de transport;
- definirea de rute imposibile prin costuri infinite;
- costurile unitare de transport pe tip de produs și tipul  mijlocului de transport.
Ceea ce se învață la școală la Cercetări operaționale și era implementat prin programul TRANSPOR - numeci atât era permis la un moment dat să fie lungimea numelui de fișier cu text sursă, implementa un caz particular de problemă de transport definită prin:
- N sursede unde pleacă produsele;
- un singur tip de produse;
- cantitățile care pleacă de la surse;
- M destinații unde trebuie să ajungă produsele;
- un singur tip de mijloace de transport;
- cantitățile de la sursăt egale cu cantitățile de la destinație;
- definirea de rute imposibile prin costuri infinite;
- costurile unitare de transport.
Mi-a plăcut teza de doctorat elaborată de Dorina MOANȚĂ, coordonată de profesorul Eugen ȚIGĂNESCU, intitulată  Modelarea cibernetico-economica a sistemelor de transport, susținută în  ASE București, în anul 1998, care avea 194 pagini. Autoarea tezei Dorina MOANȚĂ, a mai publicat articolul SOME ASPECTS ON SOLVING A LINEAR FRACTIONAL TRANSPORTATION PROBLEM  în revista JAQM - Journal of Applied Quantitative Methods, vol.2, nr.3, 2007, pg. 343 -348. Tot ea a scris și o carte despre problema de transport tridimensională care mi-a fost oferită cu autograf și în care autoarea a făcut o generalizare care a introdus încă o dimensiune în problema de transport în afara dimensiunii cantităților și dimensiunii costurilor.
În vremurile de demult, pentru a optimiza trebuiau date:
- sursele și cantitățile totale;
- destinațiile și cantitățile totale;
- costurile unitare de transport de la o sursă la destinațiile reale.
Unde nu se specificau costuri se considerau costuri infinite și acolo nu se transporta nimic căci nu exista rută de transport. Produsul software afișea:
- costul minim de transport;
- cantitățile optime de transportat indicând sursa și destinația;
- unele date tehnice privind rulările efectuate.
Am lucrat cu produsul TRANSPOR de la calculatorul FELIX C-256 făcut în Franța ani în șir și chiar mi-a fost util, nu numai la disciplina de Programe aplicative unde am lucrat 1.000 de ani și am încheiat în 1992. Mulți programatori s-au dat în bărci redescoperind roata prin a scrie câte un program propriu să-ți rezolve problemele lor de transport cu iz local, de parcă algoritmul din cărți avea o implementare la Cuca Măcăii, alta la Oarja și cu totul alta la Chiajna sau Ghimpați. Ca exercițiu de programare merită încercat, dar nu mai mult de atât. Știind că se lucrează cu matrice rare și că acestea sunt foarte drăguțe dacă sunt reprezentate prin structuri dinamice, o aventură n-ar strica având o bibliotecă de funcții care traversează astfel de matrice cu așa reprezentări. Și dacă este bal, bal să fie, se vor face și calcule legate de volumul de prelucrări și de necesarul de memorie, ca tacâmul să fie complet.
Am o poveste cu o implementare proastă a problemei de transport care funcționează perfect dar fără reoptimizări.
Era vorba de transportul sfeclei de zahăr.
Se producea zahăr în Ț fabrici de ani de zile cu un anumit cost de transport.
Fiind transport cu tractoare și remorci și un singur tpodus, unuia i-a venit ideia să implementeze o optimizare, dar fiind superficial n-a ținut seama de o situație reală.
S-a obținut soluția optimă.
Au început transporturile. Din întâmplare s-au efectuat transporturile cu costuri unitare peste medie.  O fabrică de zahăr a avut probleme tehnologice și și-a întrerupt producția pentru o lună. Sfecla nu așteaptă și a fost preluată de alte fabrici numai că trasportul s-a făcutcu:
- tractorul până la vagoane de tren, încărcare, descărcare, ăncărcare;
- trenul, descărcare, încărcare în remorci;
- tractorul la fabrică, descărcare și pus pe banda transportoare.
Așa că soluția așa-zisă optimă prin realctualizare s-a dovedit catastrofală. Morala: înainte de optimizare simplistă trebuie analiză realistă, altfel totul se compromite.
Acum problema de transport este și mai importantă căci firmele de curierat rapid folosesc și problema ruceacului dar și rute optime.







(25 noiembrie 2017)

Saturday, November 25, 2017

Vectorizarea masivelor multidimensionale

Vectorizarea matricelorm este o terminologie cam vrutală prin care s=a căutat o mai bună utilizare a memoriei interne a unui calculator în vremurile de demult când memoria atât internă, cât și memoria externă era o mare problemă. Un calculator IBM 360 considerat de top  prin  august 1969 avea memorie de 4096 Kb și de aici trebuie pornită orice discuție legată de dimensiunea oricărei probleme de rezolvat cu calculatorul. Un sistem de ecuații de maximum 30variabile  și  30 ecuații însemna definirea unei matrice  
DIMENSION A(30,30) 
în FORTRAN ocupa 30 * 30 * 4 bytes adică 3,515 Kb. La un program de adunare a două matrice, fiecare având 100 linii și 100 de coloane se vor defini în programul FORTRAN 
DOUBLE PRECISION A(100,100), B9100, 100), C(100,100)
necesarul de memorie va fi de 234,375 adică aproximativ 235 Kb, adică 23% din disponibilul de memorie al calculatorului. Calculele se fac riguros și destul de exact, dar tot în acea memorie de 1024 Kb trebuie să încapă pe lângă date și programul rezultat după editarea de legături în forma executabilă. Deci în niciun caz nu va fi vorba de dezmățul de memorie care este acum când un calculator modest are memorie RAM de 4 Gb echivalentul a 16.384 de calculatoare IBM 360 din 1969. 
Această situație a impus vectorizarea, adică un procedeu de a face economie de memorie.
În vremurile de dinainte de 1980 despre alocarea de memorie se știa clar că este numai statică. Limbajul ALGOL 67 amintea ceva de blocuri, de alocare și de dealocare dar nu am avut cunoștință de implementări complete ale limbajului acesta. 
În condițiile implementării limbajelor FORTRAN și COBOL era mare deosebire între conceptele de:
- memorie alocată, adică modul cum au fost definite variabilele în program;
- memorie utilizată, adică tot ce se inițializa și se folosea sub controlul instrucțiunilor executabile.
Într-un program FORTRAN se definea un masiv tridimensional
DIMENSION X(20,10,30) 
și se inițializau constantele N cu 10, M cu 15 și H cu 7.
În secvența:
     DO 30 I=1, N
     DO 30 J=1, M
     DO 30 I=K, 7
30 X(I,J,K) = I + K * J
este inițializată numai o parte din masivul tridimensional, ceea ce înseamnă că restul de memorie este nefolosit. Se falculează  gradul de ocupare G = N*M*K / (20*10*30) În cazul concret G = 0,175 adică nu nivel foarte mic.
Dacă se lucrează cu masi.ve având mai multe dimensiuni pentru a calcula exact poziția unui element în masiv formulele arată că trebuie date niște constante. La masivul bidimensional este necesar să se știe cât a fost alocat numărul de coloane ca valoare numerică. Dacă se lucrează cu masive unidimensionale această restricție dispare și lumea preferă să lucreze cu masive unidimensionale. Vectorizarea, acest termen care nu prea există în limba română și preluat brutal din engleză, înseamnă a pune în corespondentă elementele unui masiv bidimensional cu elementele unui masiv unidimensional și a lucra cu masivul unidimensional efectuând tot felul de operații ca și cum s-ar lucra cu masivul bidimensional.
Dacă se consideră un masiv bidimensional
DIMENSION A(10,10)
se inițializează N=5, M=5, se inițializează cumva numai primele 5 linii și primele 5 coloane pentru a calcula suma elementelor de pe diagonala principală se scrie secvența:
     S=0     
     DO 30 I=1, N*M
30 S = S + X(I + (M-1))
Avem bgijă ca să scriem o secvență de vectorizare de forma:
DIMENSION A(10,10), X(100)
...............
      K=1
      DO 30 I=1, N
      DO 30 J=1, M
      X(K) = A(I,J)
30  K=K+1
Discuțiile legate de avantajele vectorizării sunt lungi și avantajele din acele vremuri făceau diferența la apelul de subprograme unde parametrii formali arătau cu mult mai bine decât în cazul în care se scriau masive multidimensionale însoțite de niște constante care dădeau amri bătăi de cap programatorilor care doreau să facă metenanță atunci când cu lucrau cu constante simbolice definite undeva la începutul programului principal în blocuri COMMON sau de folosirea lui EQUIVALENCE.
DIMENSION X(100), B(10,10)
EQUIVALENCE (B(1),X(1))
Pune în corespondență X(10 cu B(1,1), X(2) cu B(2,1)....X(100) cu B(10,10). Se ține seama de regula după care se face linearizarea. Sunt limbaje unde linearizarea se face coloană de coloană, iar altele linearizarea se face linie de linie. Aici am presupus linearizarea coloană după coloană.
Rste o vectorizare la nivel de zone de memorie alocate static, lucru diferit de vectorizarea aceea care ține seama numai de ceea ce s-a inițialozat.







(25 noiembrie 2017)