8 erori de codificare

1. Se adoptă un sistem de coduri general, pentru o mulțime cu un număr foarte redus de elemente, iar procesul de codificare și de regăsire devine extrem de laborios.
2. Se adoptă sistem de codificare ce nu permite inserarea de noi elemente pe poziții intermediare, ceea ce duce la artificii dintre cele mai bizare, asemeni numerotărilor de locuințe unde nu s-a ținut seama de dinamica din construcții și casa cunnumărul 19 este undeva la capătul străzii, după casa cun numărul 70.
3. Datele nu sunt pregătite în prealabil și sesiunile de lucru au durate nepermis de mari.
4. Nu se verifică codurile și se declanșează tranzacții eronate cu alocări ireversibile de resurse.
5. La perioade strânse de timp se face recodificarea pentru a aduce corecții în sistemul de coduri, așa cum s-a produs la numerele de înmatriculare sau la numerele de telefon, când nu s-a ținut seama de dinamica în timp a elementelor din acele colectivități.
6. Lipsesc tabelele explicative de coduri.
7. Lista de coduri nu acoperă totalitatea situațiilor întâlnite în realitate.
8. Codurile conțin caractere inutile care le fac să fie greoaie.

Tot ce se întâmplă cu codurile din aplicațiile informatice arată că toți cei care lucrează fără a se documenta fac dovada că nu știu că există cărți de teoria codurilor și deci, fac totul după ureche sau cum le bucuie lor prin capetele lor cele prea pline de orgolii și de suficiență

(23 decembrie 2017)

5 erori de elaborare documentație

1. se elaborează o formă sumară crezând că ulterior va fi dezvoltată, ceea ce nu se mai întâmplă.
2. Se elaborează toată documentația în final fără a exista notițe intermediare.
3. Este incompletă căci sunt presupuse cunoscute lucruri care în mentenanță sunt esențiale.
4. Nu sunt explicatre funcționalități și semnificațiile listelor de parametrii și de variabile.
5. Se elaborează din amintiri la mult timp după ce produsul este implementat, ca o corvoadă.

(22 decembrie 2017)

5 erori de analiză în dezvoltarea software

Există nenumărate erori pe care le fac analiștii, dar 5 erori de analiză în dezvoltarea software sunt esențiale în tot ce urmeză după ce ei își încheie activitatea.

1. Analiștii nu-i scultă pe specialiștii din producție pentru că ei se cred deasupra tuturor.
2. Analiștii care nu cunosc programare elaborează texte și nu specificații.
3. Analiștii evită formalizările care presupun prezentări foarte exacte.
4. Analiștii consideră ceea ce ei fac drept construcție perfectă și se retrag.
5. Analiștii nu-și analizează outputurile pentru a face corecții necesare.

(22 decembrie 2017)

Stabilirea problemei

Stabilirea problemei de rezolvat are la bază cerințe ierarhizate ale beneficiarului. El are o infinitate de probleme. Din multitudinea de probleme cu care se confruntă vreo câteva sunt importante, dar dintre acestea una singură este cea mai importantă și aceasta trebuie să-și găsească rezolvare prin scrierea unui program, deci prin parcurgerea tuturor etapelor ciclului de dezvoltare software. Cel care vine să stabilească problema de rezolvat la el în companie folosind computerul trebuie:

- să aibă un pic de cultură în domeniu;

- să cunoască cerințele reale ale companiei;

- să știe exact de banii de care dispune;

- să cunoacă timpul în care vrea soluția;

- să aleagă bine pe dezvoltator;

- să aibă persoana de contact de la el;

- să verifice că toată lumea a înțeles;

- să fie convins că acesta este drumul.

Cel ce stabilește ce problemă se va rezolva cu computerul trebuie să aibă o imagine a dimensiunii ăntregului efort și să reacționeze proporțional cu ce se întâmplă în derularea contractului. Este de așteptat ca el, în calitate de client și beneficiar să aibă specialiștii care știu să descrie problema de rezolvat cu toate detaliile ei și să aibă capacitatea de se așeza la computer și să contribuie la introducerea de date, la lansarea programului și la utilizarea rezultatelor în fundamentarea de decizii și în derularea de activități curente.

Există mai multe tipuri de probleme și anume:

- probleme punctuale prin care se obține un indicator, un tabel cu totaluri, o listă de elemente;

- probleme mai precizate precum cele de optimizare, de analiză factorială, de analiză dispersională;

- probleme ceva mai complexe precum gestiunea de stocuri, de personal, de mijloace fixe;

- probleme complexe precum programarea, lansarea și urmărirea producției;

- probleme foarte complexe așa cum sunt sistemele informatice ale organizației.

Stabilirea problemei este diferită de definirea problemei. Stabilirea problemei are menirea de a crea cadrul de lucru, iar definirea problemei are menirea de a da toate detaliile pentru realizarea specificațiilor și a programelor. Stabilirea problemei precede definirea problemei. Stabilirea problemei este realizată la vârful companiei, iar definirea problemei este realizată pe palierul de mijloc de către specialiștii de acolo și uneori intervin șo cei de pe palierul de execuție.

(06 decembrie 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)

Centrele teritoriale de calcul - CTE

Centrele teritoriale de calcul - CTE au fost înființate la începutul anilor '70 și au avut ca obiectiv să deservească unitățile administrative dar și întreprinderi din județe. Ele aveau construcții destul de centrale în orașele reședințe de județ, clădiri foarte râvnite după 1989 drept care din motive extrem de bizare s-au desființat. În Europa civilizată există centre de calcul puternice care execută prelucrări online pentru spitale, primării, universități, tot felul de organizații, reducând foarte mult activitățile de dezvoltare paralelă de software destinat soluționării acelorași probleme, exact cum se întâmplă acum pe meleagurile noastre cele mioritice.

În vremurile de demult am fost în practică cu studenții la multe dintre centrele teritoriale și am văzut:

- sisteme de calcul puternice;ționale bine definite;

- echipe de analiști profesioniști;țechipe de programatori meseriașe;

- implementatori eficienți;

- beneficiari care își știau lecțiile;

- o forfotă nemaipomenită cu cutii de cartele și suluri de imprimante.

Acolo se rulau programe pentru:

- calculul de salarii;

- gestiunea stocurilor de materii prime;

- gestiunea stocurilor de produse finite;

- evidența contabilă și de bilanț

- gestiunea contractelor;

- lansarea comenzilor;

- urmărirea producției;

- analiza eficienței producției;

- optimizarea sortimentului;

- defalcarea producției;

- calculul de necesar;

- lansarea comenzilor de aprovizionare;

- evidența încasărilor;

- calculul productivității;

- croirea optimă de bare și de planșe;

- proiectarea optimă a unor produse;

- gestiunea mijloacelor fixe;

- transportul optim de produse;

- elaborarea de variante de plan la întreprindere;

- gradul de încărcare a capacităților.

Specialiștii din CTE-uri erau cei ce făceau analize ale sistemelor existente și procedau la realizarea de sisteme informatice pentru multele întreprinderi de stat care dezvoltau producție în județele lor, ceea ce reprezenta o soluție pozitivă din punctul de vedere al încărcării echipamentelor de calcul la nivel de județ, căci nu toate întreprinderile își permiteau cel puțin 50 de salariați pentru a avea un centru de calcul și mai ales ce să prelucreze pe un sistem de calcul din dotare, sistem care lucrează 24/24 și 7/7.

Centrele teritoriale de calcul - CTE au fost soluțiile ideale pentru a dezvolta informatica în toată țara și pentru a elimina paralelismele în a realiza produse software destinate acelorași prelucrări. ICI a jucat un rol esențial în formare și în elaborare de metodologii unitare pentru toate etapele dezvoltării eficiente a  unui sistem informatic într-o întreprindere.

(05 noiembrie 2017) 

Dezvoltatorii de software

Înainte de 1989 produsele software se realizau în:

- centre de calcul ale întreprinderilor;

- centrele teritoriale de calcul;

- institute de cercetări dotate cu tehnică de calcul;

- laboratoarele universităților care aveau facultăți de informatică;-

- laboratoarele liceelor de informatică;

- filialele ITC din țară.

Dezvoltatorii de sisteme informatice de pe vremuri aveau probleme de rezolvat, căci industria cerea soluții concrete pentru fluxuri de producție complexe, pentru forța de muncă numărată cu miile de salariați, pentru contractele cu beneficiarii, căci trebuia gestionat totul pentru a se cunoaște nivelurile realizate în vederea calculării abaterilor față de nivelurile planificare. Totul trebuia să meargă asemeni acelor unui ceasornic și informatica permitea realizarea acestui deziderat. În vremurile de demult la ICI se elaborau metodologii pentru dezvoltarea sistemelor informatice, metodologii care acopereau toate etapele ciclului de realizare, în care analiza, proiectarea, programarea, testarea, implementarea, exploatarea, mentenanța și reingineria erau etape clar definite cu sarcini, responsabilități, termene, costuri, riscuri, resurse, precedențe, metrici și activități.

După Revoluția din Decembrie 1989 au apărit foarte mulți producători de software. Companii producătoare de software din România sunt: Alfa Software, Arobs Transilvania Software, Ascenta, BitDefender, BITSoftware, CoSoSys, EBS, Fiba Software, GECAD Group, IP Devel, ITC Networks, Magister Software, Novensys, Siveco, SoftVision, SOFTWIN, Transart și Wizrom Software. 

În Cluj există dezvoltatori de software precum: Agis Computer, Alfa Software, Arobs Transilvania Software, CoSoSys, EBS, Hosterion, Intend Computer, IQuest, Net Brinel, Plus Computers, SoftVision, Starnet Consulting, Transart și Yonder

Toate acestea au portaluri unde-și prezintă proiectele de succes și personalul cu care lucrează. În realitate există mult mai mulți producători de software, care lucrează în mediul virtual sau care dezvoltă produse destinate unei piețe super-specializate.

Procesul de informatizare este lent la noi deoarece:

- nu există o strategie coerentă, cu etape clare;

- nivelul investițiilor este foarte scăzut;

- relația stat-dezvoltatori este afectată grav de acte de corupție;

- pirateria software scăpată de sub control reduce șansa de recuperare a investițiilor;

- exodul forței de muncă de înaltă calificare duce la scăderea calității;

- tehnologiile utilizate nu sunt de top, deși cele de top sunt ieftine;

- accesul la finanțare este selectiv, fără criterii valorice;

- inițiativa privată este incipientă;

- stimulentele din informatică sunt minimaliste;

- decalajele dintre oferta de resurse și cerere sunt prea mari.

Conchid că dacă în vremurile de demult erau acoperite cam 20% din nevoile de prelucrare din economie și societate, acum acest procent este undeva sub 5%, ceea ce înseamnă că și în următorii 50 de ani va fi o nevoie stringentă de forță de muncă de înaltă calificare care să lucreze în informatică, știut fiind faptul că sunt prea puține sistemele informatice complexe cu portabilitate transnațională.

(21 octombrie 2017)