Showing posts with label subprograme. Show all posts
Showing posts with label subprograme. Show all posts

Saturday, December 30, 2017

Fiabilitatea programelor și ordinele de mărime

În programele FORTRAN IV se lucra cu:
- variabile și constante de tip întreg definite pe 4 bytes;
- variabile și constante de tip real definite pe 4 bytes;
- variabile și constante de tip real definite pe 4 bytes;
- variabile și constante de tip logic
- variabile și constante de tip complex definite pe 4+4 bytes.
Fiecare constantă sau variabilă este caracterizată prin magnitudine, adică valoare maximă, respectiv, valoare minimă și prin ordin de mărime, adică număr de cifre maxim ce se stochează în zona de memorie care se alocă.
O constantă de tip întreg care este definită pe 4 bytes are cel mai mare număr ce se stochează acolo egal cu 2 la puterea 31 minus 1, cunoscătorii știu de ce..., adică magnitudinea maximă este de 2147483647. Deci dacă cineva dorește să scrie un program fiabil în care adună două numere IA și IB trebuie să verifice dacă:
  • IA > 2147483647;
  • IB > 2147483647;
  • IA+IB > 2147483647.
Având în vedere că în calcule toate variabilele sunt cu aceeași importanță, este rezonabil să se ia în considerare pentru fiecare dintre ele un domeniu care să asigure fiabilitatea programului în orice condiții. Din punctul meu de vedere, domeniul de variație al variabilelor nu trebuie calculat pe bucățele, ci per global, pentru a da generalitate și operaționalitate programului, adică programul să funcționeze în orice condiții, nu uneori da și de o mie de ori, nu.
Dacă se consideră doi operanzi de tip întreg OP1 și OP2 având N1 și respectiv N2 cifre, când se face o operație de adunare sau de scădere rezultatul REZ = OP1 + OP2  va avea un număr de cifre egal cu NREX = max (N1,N2) +1. Ca un program să fie fiabil trebuie ținut seama și de acest aspect. Dacă rezultatul REZ nu trebuie să fie mai mare în valoare absolută decât 2147483647, înseamnă că operanzii OP1 și OP2 nu trebuie să fie mai mari în valoare absolută decât 2147483647/2, adică mai mare decât 1072418237. Sunt chestiuni învățate în școala elementară, despre care foarte mulți dintre noi nu le-am considerat importante atunci, dar care pentru a face programe fiabile revin în forță.
Dacă se consideră doi operanzi de tip întreg OP1 și OP2 având N1 și respectiv N2 cifre, când se face o operație de înmulțire rezultatul REZ = OP1 * OP2  va avea un număr de cifre egal cu NREX =  N1+N2. În acest context OP1 și OP2 nu trebuie să fie mai mari de 46340 pentru a nu avea dureri de cap cu derularea calculelor și fără a fi nevoiți să stabilim numărul de cifre al numărelor stocate în zonele de memorie OP1 sau OP2.
Este rezonabil să introducem prin programele noastre colo și colo instrucțiuni precum:
                  IF((OP1.GT.1072418237).OR.(OP2.GT.1072418237)) GO TO 10
                  REZ = OP1 + OP2
                  IK=1
sau
                  IF((OP1.GT.46340).OR.(OP2.GT.46340)) GO TO 10
                  REZ = OP1 * OP2
                  IK=2
....................
10              IK=0
....................
Unde IK=0 dacă operațiile de calcul nu se efectuează din motive de depășire a capacității sau IK=1 în ideia că operațiile se efectuează. Dacă suntem convinși că trebuie să verificăm efectuarea calculelor se vor face conversii pe real a operanzilor și numai după efectuarea calculelor finale se va face testul dacă rezultatul final este mai mare decât constanta reală 2147483647. ceea ce va conduce la atribuirea valorii IK=0 cum că s-a produs o depășire care duce la trunchiere dacă se face conversie de la real spre întreg.
Fiabilitatea programelor și ordinele de mărime merg mână în mână și în vremurile de demult subdepășirea dar și depășirea de capacitate au dat mari bătăi de cap programatorilor mai ales când erau neglijeate oarece inițializări și se lucra cu operanzii neinițializați spre direcționarea în zone aleatoare a rezultatelor finale.




(30 decembrie 2017)

Tuesday, November 28, 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)

Mijloacele fixe

Mijloacele fixe sunt deosebit de importante și informatica are suficiente elemente ca să-i ajute pe decidenți în legătură cu acestea, pentru a menține fabrica la linia de plutire cel puțin și nu prin mijloacele fixe să o comande la înapooiere, iar ceva mai târziu la dispoziție.
În vremurile de demult aplicațiile de gestiune a mijloacelor fixe evidențiau:
- datele tehnice ale fiecărui mijloc fix;
- prețul de achiziție;
- ceva despre amortizări;
- detalii privind produsele și operațiile realizate pe ele;
- date despre reparațiile capitale;
- ceva despre reparațiile generate de defectările accidentale;
- date despre randamente pe tipuri de operații;
- date despre modificările aduse în timp.
Este rezonabil ca rapoartele obținute de la aplicația de mijloace fice să ajute pe decident să:
- cumpere noi utilaje;
- transfere utilaje:
- dea la casat utilaje;
- le schimbe destinațiaadauge senzori de achiziție date;
- integreze în roboți;
- ceară actualizări de prețuri;
- analizeze randamentele;
- scoată din uz forțat;
- calcul de capacitate;
- accelereze amortizarea;
- creșterea fiabilității;
- îmbunătățească adăugând noi dispozitive;
- integreze în alte linii de producție.
Există tentașia de a supraevalua terenuri dar mai ales clădiri motivele sunt de o bizarerie totală. Am cunoscut fabrici:
- unde se lucra cu strunguri care fuseseră amortizate în urmă cu 30 de ani;
- care țineau parcuri de mașini puse în conservare, dar care niciodată nu se vor refolosi;
- pentru care echipamentele în conservare erau sursă de furtișaguri;
- la care vândutul la fie vechi era inacceptabil datorită marilor difernțe dintre trecut și fierul vechi. Folosirea aplicației de mijloace fixe numai și numai pentru contabilitate este un lucru pe jumătate făcut bine. Cealaltă jumătate se referă la:
- alegerea momentului de înlocuire optimă;
- identificarea locurilor înguste pe fluxul tehnologic din motive de fiabilitate;
- stabilirea acelor rezerve de unde au loc creșteri ale producției.
Acum când achizițiile de date sunt puternice este posibil ca aplicația de mijloace fixe să ofere mult mai multe informații, inclusiv să stabilească unde se poziționează fabrica din punct de vedere al progresului tehnic. În momentul în care un utilaj are randament de 100 de repere pe oră și un altul mai nou are randament de 300 de aceleași repere pe oră și consumuri de energie cu 50% mai mici iar rebuturile scat de la 10% la 3% deja un model adecvat va arăta decalajul în ani, adică va măsura rămânerea în urmă, să zicem cu 15 ani, ceea ce este îngrozitor.
Era la Uzinele 23 august în 1970 o secție de producție uitată de lume care păstra în geamuri acele x-uri de hârtie albă de la camuflajele de bombardament din războiul care se terminase de 25 de ani.

(23 noiembrie 2017)

Programarea producției

Programarea producției este aplicația de cea mai mare complexitate pentru orice sistem informatic pentru că ea include baze de date despre:
- utilajele existente în fabrică;
- produsele care se fabrică;
- gamele de operații;
- materiile prime;
- stocuri de subansamble;
- muncitori;
- sortimentul planificat;
- utilitățile necesare;
- cheltuielile implicate;
- stocurile de materii prime;
- stocurile de produse finite;
- documentații ale reperelor;
- SDV-uri;
- furnizori și contracte;
- clienți și contracte.
A avea un program de producție înseamnă a oferi la începutul fiecărui schimb fiecărui muncitor ceea ce are de făcut.
A avea un program de producție înseamnă a avea materiile prime în stoc atunci când sunt solicitate pentru a fi la dispoziția muncitorului executant.
A avea un program de producție înseamnă a avea utilaje operaționale pe durata procesului de producție definit pe un interval de timp specificat.
A avea un program de producție înseamnă a avea muncitorii operaționali pe intervalul de producție specificat.
A avea un program de producție înseamnă a dispune de utilități căci fără energie electrică de exemplu orice program de producție este o himeră.
A avea un program de producție înseamnă a dispune de resurse la momentul cerut și a avea un nivel de disciplină foarte ridicat pentru că orice abateri de la termenele incluse în soluția optimă înseamnă sabotarea procesului de optimizare și reluarea calculelor care în final conduc la soluții optime, dar cu mult mai proaste decât soluțiile empirice, bazate pe experiența cotidiană.
A avea un program de producție înseamnă a  dispune de resurse imense care să permită:
- popularea bazelor de date;
- actualizarea bazelor de date;
- respectarea programelor zilnice de producție;
- derularea de activități stabile;
- culegerea de date în timp real;
- a avea capacitatea de a amortiza efectele riscurilor.
Aplicația de programare a producției este acompamiată de aplicații de:
- planificare a producției;
- lansare a producției;
- urmărire a producției;
- stocarea și livrarea producției.
Acum se vorbește despre ERP-uri acică Enterprise Resource Planning, dar când ajungem la discuții legate de spre ce și cum este tărășenia cu programarea producției mulți vorbesc despre aspecte caricaturale. Îmi dau seama de cum stau lucrurile doar din faptul că mi se spune că aplicația de programare a producției se implementează în cel mult două săptămâni. Voi demonstra aici și acum ce înseamnă bazele de date necesare programării producției.
Baza de date a produselor finite înseamnă atâtea articole câte roduse finite diferite se execută în fabrică, produse despre care trebuie cunoscute:
- codul unic de produs;
- denumire produs;
- cod documentație;
- date tehnice;
- niveluri caracteristici de calitate;
- standard de realizare;
- codul gamei de operații;
- loc de stocare;
- loc de producție;
- cantitate planificată;
- cantitate realizată;
- preț planificat;
- preț efectiv;
- legăturile cu subansamblele de pe primul nivel de descompunere a arborescenței.
Mai sunt multe alte câmpuri ceea ce duce la o lungime a articolelor foarte mare, iar efortul de a culege din diferite locuri aceste informații impun forțe deosebite pentru a realiza popularea bazei de date într-un timp decent, rezonabil și operațional.
Baza de date a reperelor înseamnă a defini articolul cu câmpuri de descriere completă pentru identificare, pentru operații de prelucrare, pentru echipamente necesare, pentru SDV-uri, meserii care trenuie folosite pentrun operații, durată medie de realizare și toate acele detalii din care orice om să se lămurească ce are de făcut pentru a face reperul cu pricina, inclusiv aspecte legate de mod de stocare, de procedurile de verificare a calității și multe, multe altele. Și pentru descrierea reperelor sunt necesare forțe imense ca procesul de pregătire al populării bazei de date să nu dureze 1.000 de ani.
Baza de date a subansamblelor înseamnă  a derula un proces cmplex din care să rezulte reperele și subansambleme utilizate, ordinea de asamblare, cine face , unde se face, cât durează și multe, multe altele. Și pentru descrierea subansamblelor sunt necesare forțe imense de specialiști care să cunoască procesele de asamblare pentru a reconstitui graful GANTT care la extremitatea din dreapta au produsul finit, ca procesul de pregătire al populării bazei de date să nu dureze 1.000 de ani.
Baza de date a legăturilor înseamnă a stabili arcele dintre repere și subansamble ca să se obțină prin parcurgerea de jos în sus - implozie, la produsul finit. Cine a făcu în facultate Structuri de date și a lucrat cu arbori oarecare știe ce înseamnă adresele nodurilor și cum se gestionează ele. Nodurile sunt aici reperele sau subansamblele. Reperele sunt frunzele din structura arborescentă.
Baza de date a utilajelor înseamnă foarte mult efort căci utilajele au foarte multe date tehnice, sunt foarte diferite și pentru a calcula capacitățile lor sunt algoritmi extrem de sofisticați. Se înregistrează detalii privind reparațiile și întreruperile tehnologice.
Baza de date a muncitorilor înseamnă a ști multe despre muncitor de la date de identificare, calificare, experiență și disponibilitatea sa de a lucra anumite operații și de a folosi anumite utilaje.
Baza de date a materialelor înseamnă a avea date despre caracteristici de identificare, caracteristici tehnice, loc de stocare, furnizor, stocuri existente și foarte multe alte lucruri deosebit de necesare programării producției.
Baza de date a gamei de operații înseamnă a avea exact ordinea de derulare a operațiilor, acel graf hamiltonian, fiind deosebit de important pentru problemele de ordonanțare în care se iau în considerare M produse, N mașini și K operații de prelucrare și asablare.
Baza de date a rețetelor de fabricație înseamnă a avea descrierea amestecurilor de materii prime și a derulării proceselor de producție, de regulă din chimie sau alte industrii unde se produc amesteruri.
Baza de date a operațiilor înseamnă descrieri complete și complexe a datelor de identificare, a utilajelor pe care se realizează, calificarea muncitorului, durate, mențiuni de pregătire, riscuri, poza reperului, SDV-urile necesare și foarte multe altele.
Baza de date a calendarului înseamnă a cunoaște zilele de lucru, a zilelor când nu se lucrează, a specificațiilor de lucru pe schimb ți multe altele care să arate cu rigurozitate și realism care este fondul de timp când se lucrează în fabrică, șa fiecare loc de muncă. Se înregistrează acolo și duratele de întreruperi tehnologice.
Baza de date a contractelor înseamnă a ști care sunt furnizorii, ce materiale oferăm, cantitățile, eșalonări, unde se stochează, cine răaspunde și multe, multe altele.
Actualizările acestor baze de date se face în timp real și calitatea acestora determină 100% calitatea soluției care este fie o defalcare, fie o ordonanțare, care sunt lucruri absolut diferite.
Am avut o experiență nu prea fericită cu completarea fișelor tehnologice pentru utilajele unei fan=brici de motoare electrice, când am adus 400 de studenți să treacă datele din fișe în foi de programare. Au lucrat aceștia cam o săptămână, nu au făcut decât 20% din ce trebuia căci restul nu era pregătit. Problema de ordonanțare acolo a murit.
Programarea producției este piatra unghiulară a oricărui sistem informatic adevărat, dar cine reușește să o implementeze, cu siguranță că-și asumă riscuri imense dacă cel putțin 95% din ceea ce se întâmplă acolo în producție nu merge perfect, adică perfect, fără nicio abatere. Numai 5% este îngăduit să meargă nu în dorul lelii, ci cu mici diferențe absolut accidentale.




(23 noiembrie 2017)

Friday, November 24, 2017

Gestiunea de stocuri

Gestiunea de stocuri a rămas acum tot la stadiul de acum 1.000 de ani, deși achizițiile de date, senzorii și toate cele ar fi trebuit să schimbe radical concepția și percepția legată de stocuri. Nici acum nu se calculează de nicio sămânță costul stocării, așa cum nici acum 50 sau 40 de ani în urmă nu se făceau calcule pentru stocare, căci niciunde nu se țin separat cheltuielile de stocare detaliate. Cât privește optimizarea de stocuri deja problema este cât casa, ceea ce se resimte în toată economia cât este ea de piață, căci carențele de la gestiunea stocurilor se resfrânge mai ales în comerțul cu amănuntul unde moralitatea este zero.
În era cartelelor perforate gestiunea stocurilor însemna cartele cu:
- cod material,
- denumire material,
- unitate de măsură,
- cantitate contractată,
- intrări, 
- ieșiri,
- preț unitar,
- cod depozit,
- nume furnizor,
- cod contract,
- cod depozit.
Situațiile obținute de la calculator vizau:
- calcul stocuri finale;
- valori stocuri pe depozite;
- materiale fără mișcare;
- grad de îndeplinire a aprovizionării;
- rupturile de stoc;
- stocurile materialelor critice.
Când au apărut bazele de date, articolele s-au îmbunătățind incluzând și dinamica stocurilor, ceea ce a permis o evidențiere mult mai detaliată a comenzilor, a aprovizionării, a dificultăților cu asigurarea stocurilor și multe alte elemente, inclusiv distribuirea pe persoane a sarcinilor. Dacă au fost definite baze de date pentru bonuri de consum, pentru lansarea comenzilor de aprovizionare, pentru contracte și pentru produse, toate calculele de stocuri și de planificare din contracte aveau o singură sursă și anume planul de producție anual. Pornind de la planul de producție se calcula necesarul de materiale bazat pe consumurile specifice. De la cantitățile necesare se efectuau contractele cu beneficiarii și tot așa. Eșalonarea aprovizionărilor depindea de planul defalcat al producției pe lună, spre exemplu. În vremurile de demult stocurile se calculau simplu, pornind de la cantitatea de produse finite, transpunându-se în algoritmi ceea ce se făcuse manual zeci și zeci de ani. experiența era cea care domina procesele de stocare, căci se știa:
- cantitatea de aprovizionat;
- durata de la moentul de lansare a comenzii la momentul sosirii materialului;
- riscurile care apar și soluții de avarie;
- abordările deterministe fiind la ele acasă.
Acum cu achizițiile de date se crează serii de timp cu evoluțiile stocurilor consemnând modificările la momentele acre apar, cu toate datele de identificare, fără tastări de date, ci prin cântăriri și numărări electronice. Cât despre costuri, evident, ele se vor măsura cu precizie căci trebuie știute acre sunt cheltuielile cu manipulările, cu chiriile, cu energia, cu ambalarea, cu menținerea ambientului și cu mentenanța. Orice altă abordare duce la situații neplăcute căci codificarea neclară face ca aprovizionările să fie repetate pentru aceleași materiale și stocurile să fie nejustificate să nu mai vorbim de imobilizările financiare.
Știu o fabrică de utilaje care la privatizare s-a vândut pe nimic, dar cel ce a cumpărat-o, băiat deștept, știa că stocurile de materii prime erau imense, iar cuprul, bronzul și altele asemenea au făcut business-ul lui foarte-foarte rentabil, iar alții, fraieri au rămas cu buza umflată, că nu-și vindeau țara. Numai că deșteptul avusese acces la gestiunea stocurilor ținută pe un FELIX C-256 și el a știut să interpreteze stocurile fără mișcare și expresia lor valorică. La el nici terenurile și nici clădirile nu valorau mare brânză.

(23 noiembrie 2017)

Programele de optimizare

Programele de optimizare au marcat foarte interesant istoria informaticii românești pentru că:
- erau necesare produse software care să implementeze algoritmii de optimizare;
- se urmărea maximizarea dimensiunii problemei de rezolvat;
- dintr-o mulțime de algoritmi era selectat acela care permitea atingerea unui obiectiv;
- transpunerea de algoritmi de cercetări operaționale presupuneau artificii;
- din start programatorii și-au dorit să realizeze programe generale, pentru biblioteci;
- testarea programelor de optimizare presupune utilizarea de exemple din cărți;
- unele programe de optimizare au zone care nu sunt testate din lipsa exemplelor;
- restricțiile de memorie sunt extrem de dure, iar volumul de calcule este și el dur.
Problema de programare liniară are mai mulți algoritmi și au fost implementări interesante și spectaculoase, iar mie mi-a plăcut foarte mult prin anii '80 că realizatorii lor propuneau și niște inegalități care permiteau calculul dimensiunii maxime a problemei de rezolvat, știut fiind faptul că în acele vremuri capacitatea memoriei interne era o mare problemă, adică o teribilă restricție.
Voi lua acum un alt exemplu, nu o procedură de optimizare și un subprogram pentru calcului produsului a două matrice.
Procedura va avea necesita definirea următorilor operanzi:
- o matrice A[M][N];
- o matrice B[N][K];
- o matrice rezultat C[M][K];
- variabilele de control i, j, k;
- variabila de lucru Cij unde se calculează suma de produse.
Dacă procedura în format executabil ocupă L bytes, matricele A, B, C și variabila  Cij sunt de tip float, iar variabilele de control i, j, k, m, n sunt de tip int, iar disponibilul de memorie al calculatorului este de DISP bytes, restricția pe care o construim este:
(M * N + N * K + M * K + 1) * 4 + 12 < DISP
unde:
- M * N *4 dimeniunea matricei A exprimată în bytes; 
-  N * K * 4 dimeniunea matricei B exprimată în bytes; 
- M * K * 4 dimeniunea matricei A exprimată în bytes;  
-  1  * numărul de bytes ocupați de variabila Cij; 
- 6 * 2 = 10 bytes ocupați de variabilele i, j, k m, n, h.
După același raționament se calculează restricțiile pentru orice program de optimizare, lucru deosebit de important când se scriau astfel de programe. Acum când se lucrează la nivel de Gb astel de restricții ne permit să constatăm câte zeci de mii de linii și câte zeci de mii de coloane au matricele cu care dorim să lucră, ceea ce este extrem de confortabil în zilele noastre. Nu am spus nimic de lungimile de la segmente care în vremurile de demult aveau aportul lor în a crește sau din contră în a reduce performanțele programelor dacă definirea de variabile era multisegment.
Chestiunile dure apăreau și în ceea ce priveau volumul de operații de prelucrare  exprimat grosier ca număr de instrucțiuni executabile. Pentru secvența de calcula aprodusului de două matrice volumul de prelucrări V este dat de relația:
V = n * m * 2 *( 1 + h) instrucțiuni.
Am folosit termenul grosier pentru a arăta că nu țin seama cât de diferite sunt instrucțiunile for() de cele de calcul și de atribuire. Cel pai riguros ar fi dacă s-ar lucra ca număr de cicluri mașină.
Pachetele de programe de optimizare în care apar iterații trebuie să conțină multe elemente dintre care limitarea duratei maxime disponibile, preciziei și a numărului de iterații sunt esențiale. În plus, ele trebuie să permită afișarea:
- datelor inițiale;
- soluției optime;
- erorii de calcul;
- numărului de iterații;
- situațiilor speciale de întrerupere.Acum au intrat în zona banalului aceste programe de optimizare, lumea căutând să le folosescă mai ales în simularea de situații cu postoptimizări și parametrizări. De asemenea, am văzut niște aplicații de optimizare multicriterială cu implementări interesante în acele vremuri, prin agregări care reduceau tot la o banală optimizare. N-am insistat, căci de prea multe ori am văzut aplicat algoritmul simplex la probleme care se pretau la programare în numere întregi. Una este să se optimizeze producția de cutii de conserve unde rotunjirea este nesemnificativă și alta este să se optimizeze cu simplex producția de autorurisme care rotunjire devine catastrofală la o adică.
Programele de optimizare au reprezentat parte din mitologia istoriei programării pentru că implementările în care numărul de variabile și numărul de restricții dacă depășeau ordinul miilor deveneau ceva de domeniul fantasticului.




(23 noiembrie 2017)


Evidența contabilă

Despre produsele software dedicate evidenței contabile este de vorbit mult, chiar prea mult, dar de zis nu ai ce prea zice pentru că:
- există prea multe produse dedicate acestui subiect;
- soluțiile sunt de un primitivism obscen;
- toate fac cam aceleași lucruri;
- salturile de la o generație la alta sunt minuscule;
- abordările nu încorporează noile tehnologii;
- achizițiile de date nu prea se văd;
- prea multe au un singură persoană dezvoltator;
- lipsește marea aplicație de contabilitate  în cloud.
Îmi aduc aminte că am văzut de-a lungul istoriei informaticii făcându-se contabilitate cu:
- aritmometrul pe foi clasice de documente contabile;
- mașina de facturat eletromecanică și zgomotoasă;
- cu IBM 360 și FELIX C 256 având intrări pe cartele;
- pe PC-uri la posturi de lucru individuale și cu CD;
- în rețea intranet cu software dedicat contabilității;
- în rețea cu software pe abonament. 
Orice discuție am avut cu specialiștii care realizaseră unele dintre produsele software de contabilitate a avut răspunsuri dintre cele mai ciudate atunci când al discutat despre matricea de corespondențe și despre lanțul de înregistrări valide. De asemenea răspunsul ferm și negativ dacă produsele respective permit ținerea contabilității de către nespecialiști, m-au dezamăgit profund. Prin 1969 - 1970 m-am ocupat la lucrarea mea de diplomă de construirea unui limbaj destul de apropiat de limbajul natural, cu definiri BNF pentru contabilitate. Sunt sigur că între timp s-au înregistrat progrese remarcabile și citirea cărții verzi de la MFP din strada Apolodor 17 ar duce precis la o interfață prietenoasă care să permită contabilitatea la ei la firmă a celor care nu au studii de contabilitate. Contabilii autorizați ar trebui să se ocupe de cu totul altceva decât să introducă în disperare facturi, bonuri și alte ciudățenii și apoi prin comenzi abracadabrante ale unor produse software ermetice să permită obținerea a tot felul de bilanțuri,, balanțe și a celorlalte daravere cerute de fisc, chestii care la urma urmei ar trebui trimise online cu semnătură electronică pentru că suntem în anul de grație 2017. Probabil o astfel de soluție se va înregistra în anul 2300 al erei noastr desigur, iar eu voi fi oale și ulcele ca și voi.
Evidența contabilă  este exemplul al dezvoltării economiei de piață haotice în producția de software în care risipa de muncă vie și tot ce zicea prietenul nostru Karl Marx se adevereșt, căci inflația de produse software contabile duce la efecte dezastruase asupra celor care-și dedică timpul să realizeze acest tip de produse și să intre cu ele pe o piață de software suprasaturată.




(23 noiembrie 2017)


Prognozele economice

Prognozele economice erau extrem de interesante în anii de dinainte de 1989. Toamna se pleca în practica agricolă și erau unii politruci din Catedra de Economie Politică, mari chiulangii care se fofilau spunând că ei merg la CC al PCR să facă prognoze. Eu știam că ei nici despre ecuația de regresie habar bu aveau, iar de prognozele ce i-ar fi servit lui ceușescu nici vorbă ca ei să facă vreun calcul. Știu că era la CSP un compartiment specializat pe prognoze macroeconomice cu absolvenți de la facultatea de Cibernetică. În plus, la CC  era un centru de calcul unde știu numai eu că erau vre 5 inși Doxa în ale modelării economice, iar cu prognozele respectivii nu aveau nicio dificultate.
Acum sunt pe toate drumurile produse software destinate oricărei tipologii complete de prognoză. Mai apare câte un rătutit care face prognoze sunbre fără să dea ipotezele de lucru care au stat la baza bazaconiilor pe care le-a obținut.
Să revenim la modelele de prognoză. Se consideră momentele de timp  T1, T2, T3, ...., Tn. Se consideră producția de cereale a țării noastre C1, C2, C3, ......, Cn și se consideră cantitatea de îngrășeminte utilizată în agricultură Q1, Q2, Q3,....., Qn. Se consideră umiditatea anuală medie U1, U2, U3, ...., Un. Se pune problema construirii unui model de eficient pentru a prognoza producția agricolă pentru momentele de timp Tn+1, Tn+2, Tn+3, ..., Tn+m. Deci se prognozează nivelurile variabilei Cn+1, Cn+2, Cn+3, ......, Cn+m. Aceste valori nu se cunosc, căci de aceea se face prognoză. Nici nivelurile pentru Qn+1, Qn+2, Qn+3, ......, Qn+m, și Un+1, Un+2, Un+3, ......, Un+m.nu se cunosc.
Nu se pornește de la o ideie preconcepută legată de structura modelului de prognoză, dar se pornește de la constatările că:
- variabila de pendentă este producția agricolă C;
- variabila independente este sunt timpul T, cantitatea de îngășeminte Q și umiditatea;
- se studiază dependențele dintre variabile;
- se construiesc mai multe modele de prognoză;
- se calculează nivelurile estimate ale producției agricole date de fiecare model;
- se calculează diferențele dintre nivelul real și cele prognozate;
- criteriul de alegere este suma pătratelor de diferențe;
- modelul cel mai potrivit este cel cu suma pătratelor de diferențe minimă.
Studierea dependențelor dintre variabile se realizează folosind coeficientul de corelație și reprezentări grafice pentru a vedea dacă dependența este liniară, exponențială sau de altă natură.
Vom preuspune că nivelurile coeficienților ce corelație r(C, T), r(Q, T), r(U, T), r(C, Q), r(C, U) sunt mari, ceea ce arată o dependență în raport cu timpul a variabilelor considerate. Mai mult, pentru a simplifica se introduce ipoteza că variațiile în timp sunt liniare, deci este decent să construim modelele liniare:
M1: C = a * T + b
M2: C = a * Q + b
M3: C = a * U + b
M4: C = a * T + b * Q + c
M5: C = a * T + b * U + c
M6: C = a * U + b * Q + c
M7: C = a * T + b * Q + c * U + d.
Se calculează nivelurile estimate ale variabilei C pentru cele 7 modele, se calculează sumele de pătrate de diferențe dintre nivelurile estimate și nivelurile efective. Se alege modelul de prognoză ca fiind cel mai eficient cel care are acea sumă minimă. Despre chestia  aceasta se găsesc mult mai multe detalii în materialele referite prin:
Ion IVAN, Adrian VISOIU - Baza de modele economice, Editura ASE, Bucuresti, 2005, ISBN 973-594-571-1, 302 pg
Ion IVAN, Adrian VISOIU - Bazele de modele economice, Ion Ivan, Adrian Visoiu, Revista ECTAP-Economistul, suplimentul Economie Teoritica si Practica, nr. 1614 (2640), 10 mai 2004
 nr. 393, 2004.
Acum pentru prognozare încep să se construiască ipoteze și anume:
Prognoza1,  în condițiile în care variabilele Q, U și T cresc în progresie aritmetică.
Prognoza2,  în condițiile în care variabilele Q, U cresc cu ritmul mediu al ultimilor 5 ani.
Prognoza3,  în condițiile în care variabilele Q, U cresc cu ritmul mediu al ultimilor 5 ani.
. . . . . . . . . 
Prognozaț,  în condițiile în care variabilele Q, U cresc după reguli specificate clar.
Se afișează rezultatele dar de fiecare dată să nu se uite că:
- datele prognozate sunt orientative;
- au la bază niște ipoteze;
- probabilitatea să fie altfel este mai mare decât p =  0,90.
Am scris toate acestea pentru că un produs software trebuie să aibă următoarele funcționalități:
- să preia ca date de intrare număr de termeni ai seriilor și seriile;
- să estimeze coeficienți pentru structuri de modele predefinite;
- să estimeze coeficienți pentru structuri de expresii analitice propuse de utilizator;
- să calculeze niveluri estimate pentru toate structurile de modele selectate și propuse;
- să calculeze sume de pătrate de diferențe;
- să ierarhizeze modelele crescător duă acele sume;
- să genereze niveluri  pentru variabile independente conform unui set de ipoteze;
- să calculeze nivelurile variabilei dependent cu datele generate;
- să produscă reprezentări grafice;
- să calculeze tot felul de coeficienți de încredere din econometrie.
Programele VERONICA și EMI făceau în vremurile de demult multe din aceste funcționalități. Acum când există atâtea resurse, cred că a sosit momentul ca noile aplicații de prognoză să aibă intrări în limbaj natural, acces la tot felul de baze de date și tot ceea ce am trăncănit eu aici să se facă automat, iar rezultatul să fie prezentat sub forma unui texty unanim acceptate ca fiind corect, complet și ca abordare realistă, dar cu probabilitate de realizare în practică sub p = 0,10.



(23 noiembrie 2017)

Calculul consumurilor specifice

Calculul consumurilor specifice și a duratelor pentru operații sunt necesare pentru calculul capacităților de producție și pentru calculul de necesar. Consumul specific este unul stabilit de standarde și unul efectiv al fabricii unde se derulează procesele de producție, unde se vorbește de:
- echipamente reale, cu uzură fizică și cu uzură morală precis stabilite;
- diferențieri de calificare a muncitorilor;
- calități diferite ale materiilor prime ;
- modalități de manipulare diferită;
- necesitatea de a face substituiri;
- interpretarea schemelor de prelucrare;
- precizia cu care se fac măsurătorile.
În acest context trebuie să existe o bază de date cu înregistrări privind toate reperele care se realizează și cu toate consumurile înregistrate, pentru a se ști:
- ce și cât este încorporat în reper;
- ce și cât este rest nereutilizabil;
- care sunt rebuturile;
- cât a rămas neprelucrat, dar introdus în proces.
Având aceste elemente se obțin consumurile specifice la nivelul fabricii ca niveluri medii corectate cu coeficienți de ponderare a abaterilor medii standard care se adaugă mediei. Consumul specific efectiv e una, consumul specific mediu este alta și un sistem informatic care se respectă trebuie:
- să creeze o imagine asupra a ceea ce se întâmplă în producție;
- să permită analize ale factorilor ce vor permite căile de scădere a consumurilor specifice;
- să genereze corecții atunci când în toate cazurile consumurile specifice din tabele se depășesc;
- să stabilească nivelurile optime ale stocurilor în raport cu dinamica utilizării materiilor prime.
Acum în condițiile robotizării calculul consumurilor specifice este o chestiune esențială pentru că de la ele pornesc toate și cheltuielile pe produs se reduc dacă:
- scad pierderile din prelucrări;
- se optimizează stocurile;
- productivitatea crește;
- consumul specific e abordat realist;
- consumul specific este abordat responsabil;
- se reduc pierderile de dinaintea prelucrării;
- aprovizionarea se face cu materiale de calitate;
- au loc sortări înainte de prelucrare;
- se știu consumurile specifice efective pe loc de muncă.
Sistemele informatice de la începuturi preluau consumurile specifice din documentații și efectuau calculele rezervelor de materii prime pornind de la niveluri de rebuturi calculate pe baze experimentale, dar cu fundamentări indirecte. Acum lucrurile ar trebui să stea altfel, dar sunt propagate multe din metehnele trecutului jalnic al informaticii bazată pe cartele perforate.
Calculul consumurilor specifice este o aplicație informatică unde statistica trebuie să evidențieze toate abaterile față de niveluri reper, niveluri care dacă sunt analizate sunt de fapt niște medii aritmetice, care ar trebui să fie acoperitoare, car care să nu acopere erori grave de prelucrare sau neglijențe ale executanților sau ale celor ce manipulează materiile prime sau reperele.
Aplicația de calcul de necesar este trâns legată de cea de gestiune a stocurilor. Știu un caz când s-a încercat penalizarea celor care rebutau produse, drept care rebuturile erau ascunse prin îngropare. Când s-a trecut la săparea fundației unei noi secții de producție au fost găsite produsele finite rebutate îngropate, tocmai că nu se corela ceea ce s-a produs cu ceea ce s-a consumat. Diferențele ar fi pus mii de întrebări căci nu se regăseau îm nateriile prime care erau resturi nereutilizabile.


(24 noiembrie 2017)


Calculul de necesar

Calculul de necesar presupune ca să existe o bază de date foarte bine construită și completă cu descrierile la toate reperele și subansanblele care altătuiesc structurile arborescente ale produselor care se realizează în fabrică.
Pentru calculul de necesar traversarea arborescenței se face bottom-up dar nu oricum ci în procedeul numit implozie și se stabilește neceasrul de repere și de subansamble pentru a realiza o cantitate Q de produse finite. Sistemul informatic BOMP de la IBM de pe vremuri și acum orice ERP ar trebui să permită calculul de necesare, ceea ce în termeni se numea requirements planning.
În vremurile de demult calculul de necesar se făcea cu programe COBOL folosind o listă de repere, consumuri specifice și coeficineții de pondere ai materialului în produs, dar și cantitatea de produse planificate a se realiza pe un interval de timp dat.


în lucru acum


(24 noiembrie 2017)

Thursday, November 23, 2017

Calculul capacităților de producție

Calculul capacităților de producție în minte unora se calculează o singură dată de către cei ce construiesc utilajul și punct. Nu există eroare mai mare. Îmi aduc aminte cum un nefericit de așa-zis specialist a primit ca sarcină să calculeze capacitățile de producție la niște utilaje existente. El a luat consumurile de timp normate pentru piese, a împărțit cele 365 de zile înmulțite cu 26 de ore și apoi înmulțite cu 60 de minute. Produsul acela la împărțit la duratele normate și a rezultat câte repere se realizează pe acel utilaj pe durata unui an, dacă s-ar lucra exclusiv acele repere.
Individul nu a luat în calcul că:
- duminicile și sărbătorile legale nu se lucrează;
- lunile anului au număr diferit de zile;
- utilajele se mai și defectează și stau cât sunt reparate;
- există revizii tehnice anuale care au durate stabilite;
- pe lîngă durata de prelucrare propriu-zisă există timpi de pregătire;
- există și timpii tehnologici de răcire pateriale, de măsurare și de transport.
Ceea ce a obținut el era o mare inexactitate, căci dacă s-ar fi planificat producția cu acele date, precis fabrica n-ar mai fi raportat la partid depășiri de plan în vecii-vecilor.
Calculul capacităților de producție este diferit acum de cum se calcula în vremurile de demult, adică înainte de '90. Acum există senzori cu care se determină toate duratele operațiilor care preced și urmează prelucrării propriu-zise. Toate acestea se țin distinct într-o bază de date și periodic se calculează prin agregare duratele efective medii necesare realizării operațiilor specifice unui produs.
Același lucru se va spune și de durata de funcționare efectivă a utilajului într-o zi, ceea ce permite să se stabilească cu exactitate duratele de nefuncționare a utilajului pe cauze, ceea ce se va regăsi într-o bază de date a comportamentului zilnic a utilajului. Se va calcula durata efectivă de funcționare a utilajului. Cine vrea o imagine realistă a capacității unui utilaj va folosi durata efectivă de funcționare a utilajului și duratele efective de realizare a operațiilor specifice realizării produsului pe respectivul utilaj.
Și în vremurile de demult se proceda tot așa numai că datrele acelea se perforau în cartele și numai calculele se făceau cu ajutorul produselor software. De diversitatea datelor și de frecvența cu care se introduceau depindea calitatea indicatorului capacitate efectivă a utilajului, fie exprimată ca număr de ore efective de lucru, fie ca număr de repere care se vor realiza pe acel utilaj.
Calculul capacităților de producție este un indicator cu care se face o manipulare a celor din management în mod perfect dacă aceștia nu intră în detalii și nu elimină elementele parazitare și nu caută să reducă timpii de nefuncționare ai echipamentelor prin măsuri ferme.
Prin anii '80 am avut un contract cu un institut de cercetări de legume și fruncte și se punea problema stabilirii unui indicator numit CUC- Coeficient de Utilizare a Capacității și nu era vorba de orice capacitate, ci de capacitatea de transport a autocamioanelor care transportau legume și fructe. Când se cumpăra autocamionul pe el scria capacitate utilă Ț tone. Producătorul probabil încărcase autocamionul cu pietroaie și așa îl testase de ajunsese la respectiva capacitate. Numai că atunci când se transporta să zicem spanac în loc de Ț tone, se transportau Ț/10 tone și capacitatea nu era atinsă niciodată, iar salariile depindeau la șoferi de CUC.
Soluția a fost simplă:

  • s-a calculat capacitatea de transport pe fiecare tip de produs, așa fel încât pentru cartofi capacitatea de transport era una, pentru spanac era cu totul alta căci spanacul înseamnă valoare mică, volum mare;
  • s-au stabilit coeficienți de transformare în produs de bază echivalent pentru a permite calcului gradului de utilizare a capacității autovehiculului în cazul în care se transportă mai multe tipuri de produse, așa cum se întâmplă în realitate;
  • s-au făcut experimente pe situații concrete după care aplicația a fost implementată și un timp s-a lucrat cu ea efectiv, obținându-se o schimbare radicală a gradului de încărcare, care reflecta realitatea obiectivă existentă în transportul de legume și fructe.
Dacă se lucrează cu niveluri medii ale timpilor pentru durate de funcționare a echipamentelor și cu durate medii ale operațiilor, capacitatea de producție apare ca număr mediu maxim de produse care se utilizează.
Dacă se lucrează cu durate medii de utilizare la care se adaugă trei sigma, unde sigma este abaterea medie standard, iar la duratele operațiilor se scad cei trei sigma, se va obține o capacitate medie optimistă.
Dacă se lucrează cu durate medii de utilizare la care se scad trei sigma, unde sigma este abaterea medie standard, iar la duratele operațiilor se adaugă cei trei sigma, se va obține o capacitate medie pesimistă.
Istoria informaticii permite studierea modalităților de calcul a capacităților de producție cu diferite ipoteze de lucru, care devin mult mai apropiate de realitate pe măsură ce se avansează în timp.




(24 noiembrie 2017)

Evidența de personal

Evidența de personal este în anul 2017 cu totul altceva decât în anii '70 sau '80 sau chiar '90. Acum există aplicații extrem de elaborate, care inclusiv oderă  liste negre ale salariaților, care au efecte cu mult mai grele decât listele rău-platnicilor scoase de bănci sau de ANAF, centarlizate și puse la vedere online după o căutare absolut banală.
Aplicațiile de evidență de personal au devenit operaționale după apariția și implementarea SGBD-urilor fără prea multe restricții și cu multe facilități de:
- populare distribuită;
- accesare date;
- achiziții flexibile;
- selcție articole;
- sortare după chei multiple;
- regăsire cu chei incomplete;
- interconectare între baze;
- facilități de reorganizare;
- reprezentări multimedia;
- validări profunde.Bazele de date trebuie să răspundă tuturor cerințelor pe care le formulează un manager, inclusiv prin construirea de atribute să permită acestuia să extragă o listă a salariaților care se încadrează în profilul definit prin acele atribute. O bază de date de personal trebuie să conțină foarte multe elemente care să permită manageriolor să ia deciziile cele mai bune. O aplocație de personal de înaltă calitate trebuie să permită managerului să construiască submulțini de persoane care răspund anumitor exigențe. Performanța fiecărui salariat depinde de foarte mulți parametrii și este deosebit de important ca aplicația de personal să permită adăugarea de componente care să satisfacă în orice moment exigențele și mai ales să permită simulări corecte pentru a fi fundamentate decizii pe date reale și nu pe impresii încărcate de subiectivism.
Când aplicația de personal preia datele zilnice privind intrările șimieșirile din organizație, managerul are toate elementele să vadă pe cine se bazează atunci când are de făcut o anumitălucrare specială.
Când aplicația de personal evidențiază amenzi de circulație sau alte reclamații, funcție de natira acestora va face promovări pe funcții de conducere sau nu.
Când aplicația de personal preia diplome și certificate de calificare, prin verificare cu alte baze de date stabilește veridicitatea și ia deciziile ce se impun.
Înainte se vorbea de dosarul de cadre. Aplicația de personal permite stocarea unei mari varietăți de date despre activitatea salariaților, despre documentele întocmite de aceștia și prelucrările adecvate scot la iveală trăsături ale profilului fiecăui salariat. O aplicație bună va surprinde mișcările unui salariat de la un proiect ala ltul, gradul de îndeplinure a sarcinilor și chiar și aspecte legate de calitatea munciilui, fără ca acele adte să fie introduse în aplicație de către șefi, ci din achiziții directe de date de la salariat. Aplicația de personal include participările la team buiding-uri, plecările în delegații, eficiența deplasărilor, calitatea soluțiilor, operativitatea, modul de utilizare a timpului. managementul de documente măsoară viteza de lucru, calitatea soluțiilor, temporizările, inactivitatea, indeciziile, adică totul și managerul doar să vrea, are toate elementele pentru a defini complec profilul oricui.
În anii de început ai informaticii evidența de personal a însemnat fișiere cu salariații care conțineau date strict necesare și care se stocau pe una sau două sau trei cartele având în comun marca salariatului. programele permiteau formarea a numeroase submulțini de salariați, prin utilizarea de teste asupra unor câmpuri. Dacă se foloseau expresii logice ceva mai complexe, acele submulțimi se rafinau și conducerile întreprinderilor aveau suficiente elemente pentru a lua deciziile, mai ales că în economia comunisă totul era centarlizat.



(23 noiembrie 2017)

Aplicațiile informatice

Aplicațiile informatice au istoriile lor, căci diferă după:
- necesarul de resurse pentru a fi soluționate;
- disponibilul de resurse oferit de calculatoare;
- importanța socială a problemei de rezolvat;
- existentul de analiști și de programatori.
Comerțul electronic pentru a exista se impunea:
- să fie calculatoarele legate în rețea;
- să existe Internetiul;
- statele să aibă legislația;
- să existe securitate electronică;
- să existe capacitate de transport;
- să se facă plăți electronice;
- să fie cumpărătorii necesari;
- să existe comercianți dispuși;
- ca societatea să evolueze.
Merită studiate aplicațiile informatice în evoluția lor, pentru că la începuturile informaticii erau restricții de:
- viteză de calcul;
- spațiu de memorie;
- la limbaje de programare;
- modul de introducere date;
- complexitatea rezultatelor;
- lucrul în echipă;
- calitatea produselor;
- independența de dezvoltator;
- legate de proprietatr;
- porblemele de rezolvat.
Cu timpul:
- au dispărut restricțiile privind viteza de prelucrare;
- au dispărut restricțiile privind  capacitatea de memorare;
- limbajele de programare au devenit cu multe facilități;
- au apărut nenumărate moduri de achiziție de date;
- aplicațiile sunt gândite să lucreze independent;
- aplicațiile informatice sunt privite ca investiții.
Toate acestea fac să se vorbească și în cazul aplicațiilor informatice despre generații, așa cum se vorbește despre generațiile de calculatoare, dar mai corect se vorbește despre generașiile de limbaje de programare. Am avut și am senzația că generațiile de software nu au ținut deloc pasul gu generațiile de harware, fiind mereu mai în urmă să zicem cu două iterații.
Aplicațiile informatice existente în opinia mea nu acoperă nici 5% din necearul de care au nevoie oamenii de rând dintr-o colectivitate. Acest aspect explică de ce nici acum și nici peste 50 de ani informatica nu va avea șomaj, căci societatea are nevoie de informaticieni, căci 50 de ani de acum încolo tot criză de produse software de primă necesitate va fi și cred că această criză chiar se va adânci.





(23 noiembrie 2017)

Calcularea salariilor

Calcularea salariilor a fost, este și va fi centrul universului pentru orice sistem informatic. Istoria calculului de salarii a început cu apariția mașinilor de calcul care erau în stare să facă cele patru operații aritmetice. dacă vrem, chiar cu aritmometrul, acea râșniță mecanică se făceau calcule de salarii. Contabilul scria cu mâna unele chestii, făcea calcule la aritmometru și iar scria cu mâna. Ca să lucreze cu zecimale, de fapt înmulșea totul cu 100 și în final, împărțea totul la 100. 
Evoluția a adus-o calculatoarele IBM 360 și FELIX C256 dar și utilizarea cartelelor perforate, unde statele de salarii se obțineau prin rularea de programe COBOL. Îmi aduc perfect aminte că în acele timpuri ideia de parametrizare lipsea, în așa fel încât modificările din legislație duceau la schimbări destul de importante în programe. Apariția acelei glume cu părțile sociale a generat apariția unui nou câmp. Când s-a pus taxa pe celibat, a apărut alt câmp. Au apărut și calculele. Se mai știe că la un moment dat s-a lucrat numai cu salariul net și atunci filosofia a devenit alta. Tot așa s-a procedat și la schimbarea grilelor de impozitare.
Abia după anul 1985 am simțit că venirea bazelor de date pe scară largă a adus un suflu nou, nemaifiind necesar să se perforeze cartele chiar cu toate datele ale fiecărui salariat lună de lună. Acele date care nu se modificau era introduse o singură dată și pe cartele apăreau numai modificările de la o lună la alta. La stat lucrurile erau destul de previzibile. Doar la cei ce lucrau în acord sai cei care făceau ore suplimentare aduceau modificări și trebuiau perforate cartele.
Mă așteptam ca acum în anul 2017 să fie făcut un produs software la comanda statului pentru calculul de salarii, să fie pus undeva și acolo tot poporul să-și calculeze salariile. Să nu mai fie un milion de astfel de programe, căci mare risipă se face de muncă vie cu cei care trebuie să facă același lucru, căci legea salarizării este aceeași și la București și la Cluj și la Ghimpați dar și acolo unde se agață harta în cui. În mod normal, acum cu câtă achiziție de date există în organizații, un produs software de calcul al salariilor ar trebui să țină seama de:
- momentul de intrare al salariatului în companie;
- de momentul de plecare al salariatului din companie;
- cantitatea de repere executate sau de documente soluționate;
- timpii neutilizați din cele 8 ore de muncă efective;
- reținerile date de organismele judiciare;
- activitatea lucrată prin suprapunere la alte job-uri;
- creditele luate fără știința organizației;
- avantajele acordate de manageri.
Oamenilor le este frică dacă lucrează aplicații în cloud computing că există careva care le-ar fura bazele de date, că ar ar afla oarece de acolo, neglijând că securitatea informatică este cu mult mai tare acolo decât oriunde. În plus, aplicațiile informatice ar face tot ce trebuie ca să se efectueze:
- preluarea de date prin achiziții;
- transmiterea de modificări în date;
- tipărirea automată de fluturași în plic;
- transferurile către bănci pentru carduri;
- plățile de taxe și impozite;
- efectuarea de plăți impuse.
Soluția ar fi de 2017 și nu de primitivismul anilor de început ai informaticii, când fiecare era cu moșioara lui și scria programe de calcul de salarii încât pentru același individ dacă i se rulează datele pe 1637 de programe se vor obține 1637 de salarii diferite, căci fiecare interpretează legea cum îi bubuie țeasta.

(23 noiembrie 2017)

Wednesday, November 22, 2017

Bibliotecile de subprograme

Bibliotecile de subprograme sunt baza reutilizării involuntare de software în activitatea de programare. Să nu ne imaginăm că programatorii dau în brânci în a reutiliza planificat, conștient și din sentimente nobile subprograme. Ei utilizează subprograme așa cum toată lumea bea apă, căci li se face sete pur și simplu. Dacă au apa laîndemână, evident iuau cana, o bagă în găleată și beau. Deci ei au termene strânse de a realiza aplicații. Există biblioteci de care programatorii au cunoștință. Când trebuie să facă o funcție de prelucrare pentru care există deja un subprogram de bibliotecă, îl folosesc și basta. Ei știu că ceea ce se află în biblioteci sunt de calitate și acele subprograme nu le vor oferi surprize neplăcute.
Bibliotecile de firmă sunt cele elaborate de companiile care au realizat compilatoarele. Dacă un compilator este o construcție de fiabilitate maximă, prin extensie și bibliotecile furnizate de compania care a realizat compilatorul sunt de calitate la un nivel foarte ridicat, ca fiabilitate, simplitate, generalitate și ca eficiență of course.
Bibliotecile de naționale sunt cele care se crează prin depuneri de subprograme de diferiți dezvoltatori. Există obligativitatea ca structura care se ocupă de astfel de construcții să facă testările pentru a verifică exactitatea celor declarate în documentații. Se elaborează cataloage cu acele componente aflate în bibliotecă și modalitățile concrete de a intra în posesia lor sau de a le accesa.
Bibliotecile companiilor sunt cele care conțin subprograme dar și programe construite în baza strategiei companiei de a avea un management riguros al nivelului de reutilizare de componente, în ideia creșterii gradului de reutilizare. Din start subprogramele care se scriu în aceste companii sunt proiectate de a fi puse în bibliotecă, deci atenția acordată calității lor este cu mult mai mare.
Bibliotecile personale sunt acele construite de programatori din proprie inițiativă, astfel încât să-și ușureze munca și să le crească productivitatea. Aceste biblioteci nu sunt secrete, dar nici cunoscute ca balada Miorița nu sunt. Fiecare programator vrea să aibă secretul lui, iar acesta dacă găsește o modalitate de a-și ușura munca în mod vizibil, o va fructifica la maximum. Cândva am avut orientare spre anumite tipuri de programe și chiar mi-am făcut un generator de programe COBOL. scris și el în COBOL pentru crearea de fișiere COBOL cu validarea câmpurilor.
Istoria informaticii are abordări foarte diferite de la o etapă la alta.
În epoca lucrului în cod mașină și cu adrese absolute, evident că se scriau subprograme dar se precizau adresele unde acestea vor fi încărcate de pe benzile perforate. Programele care apelau aceste subprograme aveau adrese de start după ulțima adresă utilizată de vreun subprogram. Lucrurile erau extrem de complicate și nu se lucra deloc haotic în acele vremuri când fiecare zonă de memorie internă trebuia drămuită pentru a face loc la cât mai multe subprograme sau la programe cu cât mai multe instrucțiuni executabile. Îmi aduc aminte că era la mare preț programul de calcul al mediei aritmetice care nu lucra cu vector, ci cu o variabilă elementară. Era citit un termen al seriei, se număra, se aduna. Se trecea la citirea altui termen care și el se număra și se aduna. Când se termina așa-zisa serie infinită de citit, rezulta și numărul de termeni și suma termenilor și se calcula media. Necazul era că nu se mai făceau niciun fel de alte calcule căci se pierdeau datele citite.
La nivelul calculatorului IBM 360 deja erau biblioteci ale IBM de calcule matematice - SSP, dar trebuia să se solicite montarea discului unde acestea erau stocate. Eu fiind mai calic, când am scris niște subprograme de bibliotecă pentru a nu mă plimba cu cutia de cartele le-am pus pe o bandă magnetică și ori de câte ori aveam nevoie de subrpogramele acelea, solicitam mpntarea benzii care avea un indicativ care era scris și pe o etichetă lipită pe cutia rolei, ca s-o găsească operatorii cât mai repede în bandotecă.
Acum în acest dezmăț al resurselor de stocare chiar în calculator, o dată cu conceptul de program rezident s-au schimbat multe și a crea o bibliotecă este doar o problemă de imagine a programatorului sau de strategie a dezvoltatorului de software, ca entitate de sine-stătătoare.
Bibliotecile de subprograme sunt o adevărată mină de aur pentru cine înțelege cât de importantă este reutilizarea de software ca sursă de creștere a productivității muncii exprimată ca număr de programe date în exploatare și nu ca noi  linii de texte sursă scrise pe unitatea de timp.




în lucru acum

(23 noiembrie 2017)