Viitorul Ingineriei Software
De la școala de Software Engineering de la FILS la educația inginerului software în epoca platformelor, DevOps, cloud și inteligenței artificiale generative.
Textul de mai jos pornește de la o preocupare personală, formată în peste patru decenii de contact cu Ingineria Software în cercetare, industrie și educație. Nu este o profeție și nici un program curricular oficial, ci un eseu-dialog: o încercare de a formula întrebările care mă preocupă și de a le răspunde din perspectiva transformărilor actuale ale domeniului.
Timp de aproximativ douăzeci de ani am avut șansa de a contribui decisiv la formarea și evoluția unei școli de Software Engineering la FILS, atât la licență, cât și la master, în filiera engleză și în cea franceză. Întrebarea care rămâne este ce se poate păstra din această școală într-o lume în care software-ul se dezvoltă prin platforme, servicii, ecosisteme, automatizare și inteligență artificială.
O preocupare veche într-o lume nouă
Ingineria Software a intrat în viața mea profesională înainte ca ea să devină, în România, o disciplină universitară recognoscibilă. Am întâlnit-o mai întâi prin probleme concrete: portabilitatea programelor, compilatoare, coduri intermediare, macroprocesoare, apoi prin întrebări mai generale privind proiectarea, formele intermediare, mașina abstractă, mediile integrate și procesul software ca obiect de studiu. În industrie am întâlnit alte constrângeri: termene, clienți, contracte, întreținere, compromisuri, tehnologii care se schimbă și programe care trebuie să funcționeze chiar și atunci când teoria nu mai oferă toate răspunsurile.
Mă ocup de peste patruzeci și cinci de ani de Ingineria Software, în cercetare, industrie și educație. Am trăit mai multe paradigme: programare structurată, metode formale, CASE, orientare pe obiecte, Java, UML, componente, web, Agile, DevOps, cloud și acum IA generativă. Ce se întâmplă cu domeniul? Mai există Ingineria Software în sensul în care am înțeles-o noi?
Ingineria Software există, dar nu mai are forma compactă pe care o avea atunci când lupta să se desprindă de programarea artizanală. Ea s-a distribuit în mai multe practici: arhitectură software, dezvoltare agilă, DevOps, platform engineering, securitate, cloud, data engineering, AI engineering, guvernanță și operare continuă. Dispare poate imaginea ei clasică, dar nu dispare nevoia care a creat-o: controlul complexității software.
Aceasta este prima clarificare. Software-ul nu dispare. Dimpotrivă, lumea devine din ce în ce mai mult construită pe software. Ceea ce se schimbă este forma profesională și educațională prin care învățăm să-l construim, să-l verificăm, să-l întreținem și să-l facem responsabil.
Ce se întâmplă cu Ingineria Software?
În istoria domeniului am vorbit despre o posibilă criză sau chiar despre un declin al Ingineriei Software clasice. Nu este oare prea mult spus? Poate fi un domeniu în declin tocmai când software-ul este peste tot?
Nu software-ul este în declin. În declin este o anumită imagine istorică a Ingineriei Software: disciplina normativă, relativ stabilă, centrată pe cicluri de viață, documentație, metode prescrise, modelare separată de implementare și unelte integrate care ar fi trebuit să conducă rațional procesul de dezvoltare.
Această imagine a fost erodată de trei valuri succesive. Agile a redus prestigiul metodologiilor grele și a mutat accentul pe feedback și adaptare. DevOps și cloud au absorbit dezvoltarea într-un flux continuu de livrare și operare. Inteligența artificială generativă schimbă acum chiar actul producerii codului, transformând programatorul în formulant de intenții, evaluator, integrator și responsabil al rezultatului.
Noua criză a Ingineriei Software nu mai este criza întârzierii proiectelor mari, ca în anii ’60. Este criza inteligibilității și a responsabilității într-o lume în care sistemele se modifică permanent, depind de infrastructuri externe, sunt construite pe biblioteci, servicii și API-uri fragile, iar o parte din cod poate fi generată de modele statistice care produc soluții plauzibile, dar nu întotdeauna justificate conceptual.
Așadar, Ingineria Software nu trebuie abandonată, ci regândită. Ea nu mai poate fi doar teoria producerii unui program, ci trebuie să devină teoria și practica responsabilă a sistemelor software evolutive, distribuite, asistate de IA și inserate în procese sociale reale.
Ce soartă au foștii studenți?
Foștii mei studenți sunt acum la apogeul carierei lor. Mulți au învățat Software Engineering într-o formă care punea accent pe programare orientată pe obiecte, Java, proiectare, arhitecturi, metodologii, aplicații distribuite și dezvoltare web. Ce soartă au într-o lume dominată de cloud, microservicii, DevOps și IA generativă?
Cei care au învățat doar tehnologii riscă să fie depășiți, pentru că tehnologiile se schimbă rapid. Cei care au învățat să gândească inginerește sunt avantajați. Ei au exact reflexele necesare momentului actual: să înțeleagă arhitecturi, să citească sisteme mari, să judece compromisuri, să gestioneze complexitatea, să pună întrebări despre calitate, securitate, mentenanță și costul schimbării.
Pentru foștii studenți aflați astăzi la maturitate profesională, provocarea nu este să concureze cu IA la scrierea rapidă de cod. Provocarea este să devină cei care știu să folosească IA fără să abdice de la înțelegere: să verifice, să integreze, să refuze, să refactorizeze, să decidă și să păstreze memoria arhitecturală a sistemului.
Din acest punct de vedere, ceea ce a fost predat la FILS nu este anulat de schimbarea tehnologică. Java s-a schimbat, framework-urile s-au schimbat, unele platforme au dispărut, altele au devenit dominante. Dar ideea că software-ul are arhitectură, că proiectarea precede și depășește codul, că sistemele trebuie întreținute și că deciziile tehnice au consecințe pe termen lung rămâne mai actuală decât oricând.
Ce trebuie predat studenților de azi?
Ce trebuie să învețe studentul de azi la Software Engineering? Putem continua să predăm aceleași cursuri, doar schimbând exemplele și limbajele? Sau trebuie refăcut nucleul disciplinei?
Nucleul trebuie păstrat, dar trebuie reorganizat. Studentul nu trebuie format nici ca simplu coder, nici ca operator de instrumente IA, nici ca teoretician rupt de practică. El trebuie format ca inginer capabil să construiască sisteme software reale într-un mediu tehnologic instabil.
De aceea, educația actuală în Software Engineering ar trebui să combine cinci straturi:
- Fundamente: algoritmi, structuri de date, limbaje, sisteme de operare, baze de date, rețele, modele de calcul, logică și probabilități.
- Construcție software: requirements, proiectare, arhitectură, testare, verificare, calitate, mentenanță, refactorizare, documentare și controlul configurației.
- Sisteme moderne: web, cloud, microservicii, API-uri, containere, observabilitate, securitate, infrastructură ca cod și livrare continuă.
- IA pentru software: utilizarea critică a LLM-urilor pentru cod, teste, documentație, analiză, migrare, refactorizare și detectarea vulnerabilităților.
- Responsabilitate profesională: etică, securitate, protecția datelor, impact social, sustenabilitate, comunicare și lucru în echipă.
O școală bună de Software Engineering nu trebuie să fugă după fiecare modă tehnologică. Ea trebuie să identifice acele cunoștințe care supraviețuiesc schimbării: abstractizare, modularitate, separarea preocupărilor, arhitectură, verificare, calitate, evoluție, securitate și responsabilitate.
Pe ce trebuie pus accentul?
Dacă numărul de ore este limitat, pe ce trebuie pus accentul? Pe programare? Pe arhitectură? Pe IA? Pe DevOps? Pe matematică? Pe proiecte?
Accentul trebuie pus pe competența de a construi și înțelege sisteme. Programarea rămâne necesară, dar nu este suficientă. Arhitectura este esențială, dar nu poate fi predată fără proiecte concrete. IA trebuie introdusă, dar nu ca substitut al gândirii. DevOps trebuie predat, dar nu ca simplu set de unelte. Matematica trebuie păstrată, dar orientată spre modelare, analiză, probabilitate, complexitate și raționament.
Dacă ar fi să reduc totul la câteva axe, aș spune că studentul trebuie să învețe:
- să formuleze problema, nu doar să primească un enunț;
- să proiecteze arhitectura, nu doar să scrie clase sau funcții;
- să înțeleagă sistemul existent, pentru că majoritatea muncii reale este pe sisteme deja construite;
- să testeze și să verifice, inclusiv cod generat de IA;
- să lucreze în echipă, cu instrumente reale de colaborare, versionare și livrare;
- să judece critic sugestiile IA, fără să devină dependent de ele;
- să documenteze deciziile importante, nu doar rezultatul final;
- să asume responsabilitatea sistemului, inclusiv după livrare.
Accentul nu trebuie să fie pe „a ști un framework”, ci pe a ști ce înseamnă să construiești un sistem care poate fi modificat, explicat, testat, securizat și folosit de oameni reali.
Trebuie schimbat numele domeniului?
Mai este potrivit numele Software Engineering? Sau ar trebui schimbat? Poate că nu mai construim doar software, ci platforme, ecosisteme digitale, servicii inteligente, infrastructuri și sisteme socio-tehnice.
Numele Software Engineering merită păstrat, dar trebuie lărgit semantic. El are o istorie, o identitate profesională și un corp de cunoștințe. Schimbarea numelui ar putea crea confuzie și ar rupe continuitatea cu o tradiție importantă.
Totuși, în interiorul domeniului trebuie recunoscut faptul că software-ul de azi este rareori un program izolat. Este serviciu, infrastructură, platformă, produs digital, ecosistem, componentă a unui proces organizațional sau element al unei decizii automate. Poate că numele general rămâne Software Engineering, dar subtitlurile viitorului vor fi: Digital Systems Engineering, AI-assisted Software Engineering, Platform Engineering, Secure Software Engineering și Software Engineering for Socio-Technical Systems.
Aș păstra deci numele, dar aș schimba modul de a-l explica. Software Engineering nu mai trebuie prezentat ca ingineria programelor, ci ca ingineria sistemelor digitale construite prin software.
Va mai fi necesară dezvoltarea de programe?
Va mai fi necesară dezvoltarea de programe? Dacă IA poate genera cod, dacă platformele oferă servicii gata făcute, dacă multe aplicații se construiesc prin configurare și integrare, ce mai rămâne din programare?
Da, dezvoltarea de programe va rămâne necesară, dar ponderea ei se va schimba. Se va scrie mai puțin cod banal și mai mult cod de integrare, coordonare, adaptare, verificare și control. O parte din cod va fi generată, dar cineva trebuie să spună ce trebuie generat, să înțeleagă rezultatul, să-l testeze, să-l integreze și să răspundă pentru comportamentul sistemului.
În plus, cu cât software-ul este mai critic, cu atât mai puțin putem accepta ideea de cod produs fără înțelegere. În sisteme medicale, financiare, industriale, militare, juridice, educaționale sau de infrastructură publică, problema nu este să generăm repede cod, ci să avem garanții, trasabilitate, audit, securitate și explicații.
Programarea nu dispare. Dispare treptat programarea ca meserie izolată de restul procesului. Rămâne programarea integrată în proiectare, arhitectură, testare, securitate, exploatare și guvernanță.
Frontierele codului generat de IA
O întâlnire recentă cu un tânăr american, absolvent al unui master în Software Engineering, mi-a oferit un exemplu concret pe care nu îl avusesem suficient în vedere. Îl întrebasem, aproape provocator, dacă dezvoltarea de software mai are viitor în condițiile în care inteligența artificială poate genera programe cu o eficacitate tot mai mare. Răspunsul lui a fost simplu și, tocmai de aceea, important: există domenii în care codul produs automat de IA nu poate fi acceptat ca atare. Mi-a dat exemplul software-ului de planificare a roboților de pe Lună.
Nu mă gândisem suficient la asemenea aplicații. Dacă un program planifică acțiunile unui robot lunar, nu este vorba doar de o aplicație care poate fi corectată după lansare. O eroare poate compromite o misiune, poate distruge echipamente ireparabile și poate face inutili ani de muncă. Probabil că există multe alte domenii în care codul generat de IA nu poate fi folosit direct.
Exemplul este foarte bun, pentru că arată limita reală a entuziasmului față de generarea automată de cod. Problema nu este dacă IA poate produce o secvență de instrucțiuni care pare corectă. Problema este dacă acel cod poate fi certificat, explicat, trasat până la cerințe, testat în condiții extreme, integrat într-o arhitectură verificată și asumat de o organizație responsabilă.
În domeniile critice, codul generat de IA poate fi util ca sprijin: pentru explorarea unei soluții, pentru generarea de teste, pentru verificări suplimentare, pentru documentare sau pentru descoperirea unor cazuri marginale. Dar nu poate fi acceptat ca produs final fără un proces riguros de inginerie, verificare, validare și certificare.
Aceasta este poate distincția centrală: în aplicațiile obișnuite, eroarea poate fi corectată printr-un update; în aplicațiile critice, eroarea poate produce pierderi ireversibile. De aceea, frontiera nu trece între „cod scris de om” și „cod generat de IA”, ci între cod acceptat prin plauzibilitate și cod acceptat prin trasabilitate, verificare, responsabilitate și certificare.
Astăzi, această frontieră este vizibilă în mai multe domenii:
- software spațial și robotică extraterestră, unde corecțiile sunt dificile, costisitoare sau imposibile;
- avionică și controlul zborului, unde fiecare funcție software trebuie legată de cerințe, niveluri de criticitate și dovezi de verificare;
- automobile autonome și sisteme avansate de asistență, unde percepția, decizia și controlul pot afecta direct viața oamenilor;
- transport feroviar și sisteme de semnalizare, unde software-ul trebuie să prevină coliziuni, comenzi conflictuale și stări nesigure;
- dispozitive medicale și sisteme clinice, unde o recomandare sau o comandă greșită poate afecta diagnosticul, tratamentul sau intervenția asupra pacientului;
- energie, industrie și infrastructuri critice, unde controlul proceselor fizice nu permite experimentarea nepăsătoare;
- securitate, criptografie și infrastructură financiară, unde o eroare mică poate deveni vulnerabilitate sistemică;
- sisteme militare sau de intervenție, unde software-ul intră în lanțuri decizionale cu consecințe ireversibile.
Este posibil ca, pe măsură ce IA devine mai puternică, aria codului care poate fi generat automat și acceptat cu riscuri mici să crească. Dar această evoluție nu elimină Ingineria Software. Dimpotrivă, mută accentul dinspre simpla scriere a codului spre specificare, analiză de risc, verificare formală sau semi-formală, generare de teste, trasabilitate, audit, certificare și guvernanță. Nișa aplicațiilor în care codul generat nu poate fi acceptat direct se poate restrânge, dar nu va dispărea atâta vreme cât software-ul comandă procese fizice, medicale, financiare, juridice sau militare cu efecte ireversibile.
De aici rezultă și o consecință educațională. Studentul de Software Engineering nu trebuie format doar ca utilizator competent al IA generative, ci ca profesionist capabil să distingă între un cod convenabil și un cod acceptabil. În multe aplicații, întrebarea nu va fi „poate IA să scrie programul?”, ci „putem noi să demonstrăm că programul, indiferent cum a fost produs, este sigur, corect, trasabil și responsabil?”.
Pentru ce fel de proiecte va fi nevoie de ingineri software?
Pentru ce fel de proiecte va fi nevoie de ingineri software bine pregătiți? Nu vor fi suficiente platformele no-code, low-code, serviciile cloud și IA?
Instrumentele no-code, low-code și IA pot acoperi aplicații simple, prototipuri, automatizări locale și interfețe standardizate. Dar cu cât proiectul devine mai mare, mai critic, mai integrat sau mai durabil, cu atât revine nevoia de Inginerie Software propriu-zisă.
Vor fi necesari ingineri software mai ales pentru:
- sisteme critice: sănătate, transport, energie, apărare, administrație, finanțe;
- platforme digitale: ecosisteme cu mulți utilizatori, servicii, API-uri și reguli de guvernanță;
- sisteme legacy: modernizare, migrare, refactorizare și integrare cu tehnologii noi;
- produse software complexe: aplicații care evoluează ani de zile și trebuie menținute de echipe succesive;
- sisteme AI-intensive: aplicații în care modelele IA trebuie integrate, monitorizate, explicate și controlate;
- cybersecurity și safety: sisteme unde eroarea, vulnerabilitatea sau atacul au consecințe majore;
- infrastructuri cloud și edge: sisteme distribuite, observabile, scalabile și reziliente;
- digital twins și ecosisteme digitale: reprezentări active ale unor procese reale, în sănătate, industrie, orașe și administrație.
Tocmai în aceste proiecte se vede diferența dintre a produce cod și a face inginerie.
Trebuie micșorat numărul de studenți?
Dacă IA va prelua o parte din activitatea de programare, trebuie micșorat numărul de studenți la specializarea de Software Engineering?
Nu cred că răspunsul corect este o reducere mecanică a numărului de studenți. Mai importantă este schimbarea profilului de formare. Dacă specializarea produce doar programatori de rutină, ea va avea o problemă. Dacă produce ingineri capabili să proiecteze, să integreze, să verifice, să lucreze cu IA și să răspundă pentru sisteme complexe, cererea nu va dispărea.
Totuși, poate fi necesară o selecție mai atentă și o diferențiere mai clară a traseelor. Nu toți studenții trebuie să ajungă arhitecți software sau cercetători. Unii vor fi dezvoltatori de aplicații, alții ingineri DevOps, alții specialiști în securitate, ingineri de date, ingineri AI, product engineers sau integratori de platforme. Dar toți ar trebui să primească un nucleu comun de gândire inginerească.
Riscul nu este că vor fi prea mulți studenți la Software Engineering. Riscul este ca ei să fie pregătiți pentru o meserie care se schimbă sub ochii noștri. Nu numărul trebuie să fie prima întrebare, ci relevanța formării.
Școala de Software Engineering de la FILS
Timp de douăzeci de ani am avut șansa să decid asupra creării și evoluției unei școli de Inginerie Software la FILS, la filierele engleză și franceză. Am construit pentru licență un nucleu de cursuri inovativ, unic în țară, și am introdus un master in Inginerie Software care să asigure studenților o pregătire solidă in domeniu. Ce se va alege de această școală?
O școală universitară nu supraviețuiește prin păstrarea neschimbată a cursurilor. Ea supraviețuiește prin oameni, prin reflexe intelectuale, prin standarde profesionale și printr-un mod de a pune întrebările. Dacă școala de la FILS a transmis ideea că software-ul trebuie proiectat, înțeles, verificat, întreținut și asumat, atunci ea are șanse să continue chiar și atunci când tehnologiile se schimbă.
Dar pentru a continua, ea trebuie să se actualizeze. Nu este suficient să adauge un curs despre IA sau un laborator despre cloud. Trebuie regândită relația dintre fundamente și instrumente. IA trebuie introdusă în toate cursurile, dar cu reguli clare: studentul poate folosi IA, însă trebuie să demonstreze că înțelege problema, soluția, testele, limitele și consecințele.
Moștenirea cea mai importantă a școlii FILS nu este un anumit limbaj, nici un anumit framework, nici un anumit instrument. Este convingerea că software-ul nu se improvizează. El se proiectează, se construiește, se verifică, se exploatează, se schimbă și se transmite altora.
Dacă această convingere rămâne vie, școala nu dispare. Ea se transformă.
Un nucleu curricular posibil
În forma actuală, un curriculum de Software Engineering ar trebui să păstreze echilibrul între stabil și schimbător. Nu se poate construi un program de studii numai pe tehnologii efemere, dar nici nu se poate ignora mediul real în care absolventul va lucra.
| Nivel | Ce trebuie păstrat | Ce trebuie adăugat sau întărit | Rezultatul dorit |
|---|---|---|---|
| Licență – fundamente | Programare, algoritmi, structuri de date, baze de date, sisteme de operare, rețele, OOP. | Gândire critică asupra codului generat, testare sistematică, versionare, lucru în echipă. | Student capabil să scrie, să citească și să explice programe, nu doar să le producă. |
| Licență – construcție software | Requirements, design, arhitectură, UML sau notații echivalente, design patterns, calitate. | Arhitecturi cloud-native, API-uri, microservicii, securitate by design, observabilitate. | Student capabil să gândească sistemul, nu doar componentele sale. |
| Master – sisteme moderne | Procese software, management de proiect, modele de maturitate, metode agile, DevOps. | Platform engineering, SRE, DevSecOps, guvernanță, costuri cloud, sustenabilitate. | Absolvent capabil să lucreze în organizații software reale și să înțeleagă fluxul complet. |
| Master – IA și software | Fundamente de IA, machine learning, sisteme inteligente, date și modele. | AI-assisted software engineering, prompt engineering tehnic, evaluarea codului generat, securitatea IA. | Inginer capabil să folosească IA ca instrument, nu ca autoritate. |
| Proiecte integratoare | Proiecte de echipă, documentație, prezentare, evaluare tehnică. | Proiecte cu client real, sisteme legacy, integrare API, date reale, responsabilitate privind IA. | Absolvent care a întâlnit complexitatea înainte de a intra în industrie. |
Nucleul curricular nu trebuie să fie o listă de mode tehnologice, ci o arhitectură educațională: fundamente solide, proiectare sistematică, tehnologie actuală, IA integrată critic și proiecte reale.
Ce rămâne?
Dacă ar trebui să formulez o concluzie personală, ce rămâne din Ingineria Software după toate aceste transformări?
Rămâne exact ceea ce a motivat apariția domeniului: lupta împotriva haosului software. Numai că haosul are astăzi altă formă. Nu mai este doar haosul codului spaghetti sau al proiectelor întârziate. Este haosul platformelor interdependente, al serviciilor distribuite, al dependențelor externe, al codului generat, al vulnerabilităților, al cerințelor instabile și al sistemelor care continuă să se schimbe după ce au fost livrate.
În această lume, Ingineria Software nu este mai puțin necesară, ci mai greu de predat și mai greu de recunoscut. Ea nu mai poate fi prezentată ca un set de rețete. Trebuie predată ca o cultură profesională a construcției responsabile.
Poate că acesta este răspunsul cel mai simplu. Viitorul Ingineriei Software nu depinde de păstrarea unei terminologii sau a unui set fix de cursuri, ci de supraviețuirea unei atitudini: să nu confundăm producerea rapidă de cod cu construirea unui sistem; să nu confundăm sugestia IA cu soluția validată; să nu confundăm platforma cu arhitectura; să nu confundăm viteza cu progresul.
Dacă această atitudine rămâne, atunci școala de Software Engineering pe care am încercat să o construiesc nu se încheie odată cu o generație de cursuri sau cu retragerea unui profesor. Ea continuă în cei care, ajunși la maturitate profesională, știu încă să întrebe nu doar „cum facem să meargă?”, ci și „de ce merge, cât va rezista, cine răspunde și ce se întâmplă când trebuie schimbat?”.
Repere bibliografice orientative
- ACM / IEEE Computer Society, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering.
- ACM / IEEE / AAAI, Computer Science Curricula 2023.
- IEEE Computer Society, Guide to the Software Engineering Body of Knowledge, SWEBOK, versiunea 4.0.
- DORA, Accelerate State of DevOps Report, edițiile recente despre DevOps, platform engineering și impactul IA.
- GitHub / Microsoft Research, studii despre impactul GitHub Copilot asupra productivității dezvoltatorilor.
- NASA, Software Engineering Requirements, pentru dezvoltarea și asigurarea software-ului critic în misiuni spațiale.
- RTCA, DO-178C: Software Considerations in Airborne Systems and Equipment Certification, pentru software avionics.
- ISO 26262, Road vehicles — Functional safety, pentru sisteme electrice/electronice și software auto cu impact asupra siguranței.
- IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, ca standard de bază pentru siguranță funcțională.
- FDA, materiale recente privind software-ul medical și funcțiile software bazate pe IA în dispozitive medicale.
- Lucrări recente despre integrarea IA generative în educația de Software Engineering și în proiectele capstone.
Înapoi la Ingineria software • Înapoi la Istoria Ingineriei Software • Înapoi la Cercetare