Să presupunem ca aţi realizat în trecut un proiect iar acum a venit ocazia să faceți unul de aceeași natură dar la un nivel mai mare.
Ne imaginăm, în linii mari, că în trecut am configurat şi instalat 5 servere pentru un client iar proiectul din prezent presupune ca să ne ocupăm de achiziția, montarea, configurarea, instalarea a 50 servere plus instruirea personalului din partea beneficiarului.
Evident datorită experientei pe care am avut-o cu cele 5 servere, știm care au fost problemele pe care le-am întâmpinat şi (probabil) acum știm cum să trecem peste ele. Dar dacă apar altele mai mari? În cazul în care întâmpinam pentru prima oară un proiect mai mare aici apare ceea ce este denumit ca „Project know-how recycling”. Practic, bazându-se pe soluții valabile în proiectul trecut, se refolosesc brut sau se adaptează ochiometric aceleași soluții la proiectul prezent. Evident problemele apar de la sine iar dacă proiectul prezent se bazează pe modul de realizare a proiectul trecut la scara mai mica, atunci probabilitatea ca probleme noi sa apară, creşte.
In general, reciclarea proiectelor este rar prezentă în firmele private şi suficient de des prezentă în proiectele de stat. De ce este asa situația? Deoarece reprezentanții mediului privat prin conducătorii firmelor care decid soarta proiectelor nu sunt dispuși să riște costuri suplimentare, întârzieri inutile şi practici necorespunzătoare a căror rezultat poate să decidă chiar si soarta firmei. În schimb în proiectele derulate de stat, se pot observa împrumuturi de documentație tehnică, cut/copy/paste a caietelor de sarcini, modernizări pe baza documentației adaptate realizată pentru alt proiect etc. şi astfel în timpul în care este derulat proiectul ies la iveală probleme de proiectare care dacă proiectul ar fi fost făcut de la zero, corespunzător, nu ar fi apărut. Acestea inevitabil duc la costuri suplimentare şi termene depășite, în mod normal, dar pentru care responsabilii introduc, prevăzători, buget şi termen suficiente pentru realizare. Totuși este o practică nesănătoasă în ciuda faptului că reduce timpul şi munca celor responsabili de documentarea, inițierea şi coordonarea proiectului, iar ca exemplu: modernizarea unei străduțe de oraş nu implică aceleași resurse precum modernizarea unui bulevard de municipiu. Iar pe proiectant şi pe ceilalţi responsabili de proiect – după care constructorii au fost nevoiţi să refacă proiectul în funcție de mersul lucrărilor – cine-i trage de urechi? Cultura organizațională dintr-o companie națională de stat impune managementul proiectelor dar permite managementul neperformant al proiectelor.Aceste practici fiind dăunătoare pentru bugetele din care se face finanțarea proiectului iar rezultatele nu sunt la nivelul așteptat/dorit așa că cineva ar trebui să se autosesizeze.
În schimb, în mediul privat „Project know-how recycling” este folosit foarte rar datorită faptului că se dorește un mod profesionist şi calitativ de realizare a proiectului.
Practic, în cazul nostru pentru cele 50 servere, proiectul se ia de la zero. Nu putem să trecem în lista de necesare cantități şi materiale (X metrii de cablu Z când noi am fi avut nevoie de Y metrii de cablu Q), pentru că aşa am fi apreciat la prima vedere. Se analizează, se măsoară, se verifică şi se trece pe hârtie. De exemplu în linii mari, se alege configurația adecvată necesitaților firmei în funcție de raportul calitate/cost. Se alege locul/data center-ul unde acestea vor fi păstrate pe baza unor cerințe prestabilite (poziție centrală, ușurință acces, dimensiune și securitate locație, posibilitate de adăugare noi servere, temperatură etc.). Se analizează dacă soluțiile software ce au stat la baza proiectului trecut sunt utilizabile si în cazul proiectului prezent. Se urmărește stabilitatea și securitatea softului, posibilitatea de a automatizare a proceselor din servere astfel încât să se poată realiza cu ușurință mentenanța și actualizările pentru a asigura fiabilitatea si securitatea necesară acestora. Posibil ca anumite lucruri să le fi făcut manual pentru fiecare server în parte iar acum același soft să nu ne permită o setare automată pentru toate serverele.
Toate acestea și altele pe lângă ele, se stabilesc în faza de inițiere a proiectului şi nu în teren „în funcție de mersul lucrărilor”. Improvizația fiind un pas mare spre probleme şi un pas mic pentru proiect/firmă.
Arhitectura unui sistem informatici este influențată în principal de cerințele funcționale -serviciile oferite de un sistem- si considerațiile privind calitatea (scalabilitatea sau performanta). Dincolo de aceste ceriţte, arhitecturile sunt influentate de constrângeri tehnice cum ar fi sistemul software utilizat (de ex. sistemul de operare), middleware, sistemele de moștenire care vor fi integrate, standardele utilizate, regulile de dezvoltare (de ex. ghiduri de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea în diverse locatii a unei companii).
Deoarece sistemele software sunt în permanenta schimbare arhitecturile sunt de obicei dezvoltate într-o maniera iterativa, ceea ce nu garanteaza o arhitectura solida. O abordare iterativa nu este suficienta pentru rezolvarea problemelor specifice de proiectare precum integrarea sistemelor de moștenire în dezvoltarea unei arhitecturi (șabloanele de proiectare sunt foarte eficiente în sprijinirea deciziilor de proiectare).
Intr-un fel s-a construit podul de peste Olt şi în altfel s-au construit Porțile de Fier de peste Dunăre, chiar dacă au elemente în comun.
În concluzie, proiectele din trecut finalizate cu succes, prin natura lor unică – acestea având un factor educativ în fiecare, trebuie să ne inspire şi să ne ajute la proiectul/momentul prezent.Nu trebuie să le copiem/replicăm la o scară mai mare sperând că nu vor fi consecinţe.
Ionel Timișan
