Showing posts with label Ion IVAN. Show all posts
Showing posts with label Ion IVAN. Show all posts

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)