În lumea dezvoltării software, metodele clasice și-au spus cuvântul. Dar în timp ce unii folosesc încă waterfall, iar alții mizează exclusiv pe agile, realitatea de business cere ceva diferit: un proces flexibil, dar predictibil. Un proces care livrează constant, fără riscuri majore, și care nu creează dependență de furnizor.
La abac.software, am construit un proces de manufacturare a aplicațiilor care îmbină rigoarea cu agilitatea. Și funcționează.
# TL;DR
La abac.software, fabricăm software industrial printr-un proces predictibil, clar și modular.
Procesul nostru are 3 faze contractabile separat:
1. Definirea cerințelor (SRS)
2. Arhitectura tehnică (SDS)
3. Dezvoltarea efectivă, cu milestone-uri și livrabile
✅ E scalabil și flexibil, dar și predictibil în timp și cost
✅ Evită vendor lock-ul — livrabilele sunt standardizate și reutilizabile
✅ Permite construirea de sisteme solide, pas cu pas
✅ Include garanție pentru probleme neacoperite
Este o metodă modernă, sigură și adaptată realității din businessul digital.
Cum se fabrică software-ul industrial?
Dezvoltarea software-ului nu este o magie întâmplătoare — este un proces. Așa cum în industrie există linii de producție și standarde clare, și în software s-a încercat, de-a lungul timpului, să se definească metode prin care să construim sisteme fiabile, utile și durabile.
De la SDLC la Waterfall
Totul a început cu SDLC — Software Development Life Cycle — un concept care definește etapele majore prin care trece orice proiect software: analiză, design, implementare, testare, livrare și mentenanță.
Primul model formal bazat pe SDLC a fost Waterfall, în care toate aceste etape se executau secvențial, una după alta. Precum o cascadă: nu te întorci la pasul anterior odată ce ai trecut de el.
Waterfall a adus rigoare și claritate. Proiectele mari aveau nevoie de planificare solidă, iar această metodologie o oferea. Însă avea și neajunsuri: era inflexibilă, lentă în fața schimbărilor și adesea ducea la livrabile care nu mai reflectau nevoile actuale ale clientului.
Agile — o revoluție necesară
Pentru a răspunde acestor limitări, a apărut Agile. Manifestul Agile a schimbat paradigma: în loc de documentații stufoase și planuri rigide, s-a pus accent pe:
- colaborare constantă cu clientul
- dezvoltare iterativă
- livrabile rapide, testabile
- adaptabilitate în fața schimbărilor
Agile a revoluționat felul în care echipele dezvoltă produse. Dar, în multe cazuri, a adus și haos: fără specificații clare, fără milestone-uri, fără estimări predictibile de buget sau durată. Cu alte cuvinte, a oferit flexibilitate, dar nu întotdeauna direcție.
De ce nici Waterfall, nici Agile nu sunt suficiente azi
Astăzi, companiile au nevoie de claritate și viteză, de predictibilitate și adaptabilitate. Au nevoie de un mod de a construi software care:
- să pornească de la o înțelegere clară a nevoilor
- să definească arhitectura corectă de la început
- să permită livrări rapide și validate pe parcurs
- să nu creeze dependență de furnizor
Și asta nu se poate face nici doar cu Waterfall, nici doar cu Agile.
Requirements Engineering — Documentul SRS (IEEE 29148)
Orice sistem software reușit începe cu o înțelegere precisă a ce trebuie construit. Nu presupuneri. Nu idei vagi. Ci o definiție clară, completă și verificabilă a cerințelor.
În această primă fază, lucrăm împreună cu clientul pentru a traduce nevoia de business în specificații funcționale și tehnice. Rezultatul este un document formal: SRS (Software Requirements Specification), elaborat conform standardului internațional IEEE 29148.
Ce conține un SRS?
Un document SRS nu este o prezentare PowerPoint sau un text de intenție. Este un livrabil riguros care cuprinde:
- Funcționalitățile aplicației, detaliate pe roluri și acțiuni
- Scenariile de utilizare — exemple clare despre cum utilizatorii vor interacționa cu aplicația
- Wireframe-uri (schițe de ecran) care dau formă experienței utilizatorului
- Reguli de business care guvernează comportamentele aplicației
- Cerințe non-funcționale, precum securitate, scalabilitate, accesibilitate, timpi de răspuns sau compatibilitate cu alte sisteme
De ce e important?
Faza de Requirements Engineering este ca planul arhitectural al unei clădiri: fără el, nu poți construi cu încredere. Cu el, poți alege cu cine construiești, știind exact ce primești. Astfel, un SRS este important deoarece:
- Este un document standardizat, recunoscut internațional, care poate fi înțeles și folosit de orice firmă de software.
- Îți oferă control total asupra proiectului — poți cere oferte clare și comparabile de la mai mulți furnizori.
- Evită blocajul într-un singur furnizor (vendor lock). Proiectul e al tău, iar acest document îl face portabil și transparent.
- Este baza oricărei arhitecturi solide. Fără o specificație bună, orice dezvoltare e un joc de noroc.
Architecture Definition — Documentul SDS (IEEE 42010:2022)
Odată ce știm ce trebuie construit (prin documentul SRS), următorul pas este să stabilim cum va fi construit — adică arhitectura sistemului.
În această fază definim structura tehnică a aplicației și luăm decizii critice care afectează:
- Securitatea,
- Performanța,
- Scalabilitatea,
- Interoperabilitatea,
- Și, mai ales, viitorul posibil al aplicației.
Livrabilul acestei etape este SDS (Software Design Specification) — un document detaliat, construit conform standardului internațional IEEE 42010:2022.
Ce conține un SDS?
Un SDS bine construit răspunde la întrebarea: Care este forma internă a aplicației și cum funcționează fiecare componentă tehnică?
Concret, el include:
- Structura modulară a aplicației — împărțirea sistemului în componente sau servicii independente
- Fluxurile de date și comunicarea dintre module
- Tehnologiile utilizate (framework-uri, baze de date, API-uri etc.)
- Măsuri de securitate (autentificare, criptare, backup etc.)
- Planul de scalabilitate și integrare cu alte sisteme
- Planul de dezvoltare incrementală (ce se construiește prima dată și cum evoluează sistemul în timp)
De ce este esențial?
Faza de Architecture Definition este echivalentul ingineriei structurale în construcții: fără o schemă clară, poți construi, dar nu știi dacă va rezista. Cu SDS, ai o fundație solidă și o hartă tehnică sigură pentru orice echipă de dezvoltare, deoarece:
- Oferă claritate și predictibilitate tehnică. Știi exact ce primești din punct de vedere arhitectural.
- Permite dezvoltarea etapizată, fără ca fiecare funcționalitate nouă să „strice” ce s-a construit deja.
- Este punctul de plecare pentru dezvoltare eficientă: echipele de dev pot lucra în paralel pe module clare.
- Este documentat și reutilizabil, deci poți schimba furnizorul fără haos sau pierderi.
Dezvoltare — Livrare predictibilă, etapizată, cu garanție reală
După ce am stabilit ce construim (SRS) și cum îl construim (SDS), urmează faza de execuție propriu-zisă: dezvoltarea software.
Dar nu orice dezvoltare.
Noi urmăm un proces de livrare predictibilă, care transformă proiectul într-o succesiune de milestone-uri clare, fiecare cu livrabile concrete și facturare doar la rezultat.
Cum funcționează?
🔹Proiectul este împărțit în etape distincte — fiecare corespunzând unui modul sau set de funcționalități.
🔹 Pentru fiecare etapă:
- Există un calendar de livrare clar (cu estimări de timp validate de echipă)
- Există un set de livrabile funcționale testabile
- Există o factură emisă DOAR după livrare
🔹 La finalul fiecărei etape:
- Clientul primește aplicația testabilă
- Se face review împreună
- Se validează sau se corectează în timp util
Acest sistem înlătură surprizele: nu se facturează “în orb”, iar clientul are control complet asupra progresului.
Ce ne diferențiază?
- Nu există vendor lock — clientul are acces la cod, documentație, builduri și livrabile la fiecare etapă
- Proiectul poate fi oprit sau adaptat după fiecare milestone, fără pierderi majore
- Se pot introduce noi cerințe fără a bloca sau deraia întregul sistem
- Livrările sunt controlate printr-un Delivery Graph — o hartă clară a ce se construiește, când și în ce ordine
Și garanția?
Această fază nu înseamnă doar codare — ci executarea precisă a unui plan bine gândit, cu responsabilitate și vizibilitate deplină.
Pentru că sistemul e construit corect de la început, putem oferi:
✅ 12 luni garanție pentru orice defect neacoperit de specificație
✅ Mentenanță clară și suport post-lansare
✅ Evoluție planificată a sistemului
De ce funcționează acest model?
✅ Este documentat și standardizat internațional
Folosim standarde recunoscute (IEEE 29148 pentru cerințe și IEEE 42010 pentru arhitectură), ceea ce înseamnă că livrabilele sunt clare, interoperabile și ușor de înțeles de orice alt furnizor sau partener tehnic.
✅ Este flexibil și adaptabil la schimbări
Fiecare fază oferă puncte de control și ajustare. Dacă prioritățile se schimbă, putem adapta traiectoria fără a compromite întregul proiect.
✅ Este previzibil în timp și cost
Planificăm totul în etape cu milestone-uri clare. Astfel, știi în permanență ce primești, când și la ce cost — fără surprize sau bugete scăpate de sub control.
✅ Este modular — construim tentaculele, nu direct caracatița
Începem cu modulele esențiale. Nu e nevoie de un sistem gigantic din prima. Automatizezi pas cu pas, în funcție de impact și prioritate.
✅ Este sigur — fără dependență de un furnizor anume
Livrabilele sunt ale tale: cod, documentație, acces la sisteme. Totul e gândit pentru transparență și portabilitate.
