Procesul de dezvoltare

Procesul de dezvoltare software

 

www.abac.software

Versiune [07.06.2025]

 

Disclaimer

 

Acest document descrie politicile aplicate de abac.software pentru dezvoltarea de soluții software în favoarea beneficiarilor.

abac.software este operat de RED ABACUS DEVELOPMENT SRL, societate românească înregistrată sub nr. J12/2788/2016 la Registrul Comerțului, cu codul unic de înregistrare RO36345302, cu sediul în strada Gruia nr. 27, 400171 Cluj-Napoca, România. Denumită în continuare „abac”, „noi”, sau alți termeni similari.

 

Introducere

 

Soluțiile software sunt dezvoltate de abac.software folosind două modele distincte de colaborare:

  • Modelul de dezvoltare Pipelined (sau dezvoltarea realizată în faze clar definite)

  • Modelul de dezvoltare flexibilă (sau dezvoltarea realizată în mod continuu de către o echipă alocată de experți)

 

 

Terminologie

  • Deținătorul garanției → Persoana sau organizația care a colaborat cu abac pentru a construi o soluție software și a primit o perioadă de garanție post-implementare.

  • Perioada de garanție → Perioada specificată în oferta comercială în timpul căreia titularul garanției poate raporta erori în software-ul livrat, iar abac le va remedia gratuit.

  • Revendicare de garanție → O notificare oficială din partea deținătorului garanției către abac, care descrie un defect care trebuie rezolvat.

  • Întreținere → Activități de rutină, non-dezvoltare, care ajută la menținerea sănătății și stabilității sistemului (de exemplu, curățarea spațiului serverului, rotația jurnalelor). Întreținerea nu include remedierea erorilor sau dezvoltarea de noi caracteristici.

  • Problemă → Orice problemă raportată cu software-ul, care poate fi o eroare (acoperită de garanție), o sarcină de întreținere (acoperită de domeniul de aplicare definit al întreținerii) sau o cerere de îmbunătățire (o nouă caracteristică sau modificare, de obicei în afara garanției).

  • Corecție → Acțiunea de a corecta o eroare sau un defect în software-ul livrat. Garanția acoperă remedierile pentru erorile calificate în cadrul perioadei de garanție, dar nu acoperă îmbunătățirile sau modificările din afara domeniului de aplicare.

 

Modelul pipelined

Modelul Modelul Pipelined este o strategie de dezvoltare structurată, în trei faze, concepută pentru a transfera o idee de la conceptul inițial la produsul funcțional în etape clare, contractuale.

Fiecare fază este contractată separat, cu propriul ordin de lucru și propriile rezultate. Această abordare asigură transparența, previzibilitatea și lipsa blocajului furnizorului în fiecare etapă a proiectului.

Faza 1: Elaborarea cerințelor

 

În timpul acestei faze, colaborăm îndeaproape cu beneficiarul pentru a înțelege în profunzime conceptul dorit și pentru a-l documenta în mod clar.

Activități-cheie:

  • Definirea atât funcționale și non-funcționale într-un mod clar, standardizat

  • Alinierea așteptărilor cu privire la fluxurile de lucru de bază ale aplicației pentru fiecare tip de utilizator

  • Eliminarea ambiguității înainte de începerea proiectării sau dezvoltării

 

Principalele realizări:

  • A Specificație privind cerințele software (SRS) (în conformitate cu IEEE 29148)

  • A Prototip funcțional (de exemplu, în Figma sau Adobe XD) care ilustrează aspectul, senzația și comportamentul produsului

Faza 2: Definirea arhitecturii

Această fază transformă SRS-ul convenit într-un proiect tehnic detaliat pentru soluție.

Activitățile cheie includ:

  • Selectarea tehnologiilor adecvate

  • Definirea arhitecturii sistemului și a structurilor de date

  • Proiectarea punctelor de integrare și a componentelor tehnice

Principalele rezultate:

  • A Specificație de proiectare software (SDS) (aliniat la IEEE 42010:2022), care servește drept plan de dezvoltare

Faza 3: Dezvoltare

În această fază finală, transformăm proiectul convenit într-un produs software funcțional, asigurându-ne că toate cerințele sunt implementate conform specificațiilor.

Activități cheie:

  • Descompunerea sistemului în livrabile incrementale, de obicei aliniat cu etapele de facturare

  • Scrierea și testarea codului sursă pe baza specificației de proiectare software

  • Configurarea mediilor de implementare și integrarea cu servicii terțe, după cum este necesar

  • Efectuarea teste interne de asigurare a calității (QA) pentru a verifica fiecare produs livrabil în raport cu cerințele convenite

  • Colaborarea cu clientul pentru revizuirea și validarea fiecare livrabil înainte de a trece la următorul

Principalele realizări:

  • Active tehnice: cod sursă, fișiere binare, documentație

  • Setări de configurare: medii, integrări terțe

  • Pachete de livrări incrementale: clar delimitate, revizuite și acceptate de către client la fiecare etapă

  • Soluție implementată: complet instalată și configurată pe infrastructura desemnată de client, gata pentru testul de acceptare

NOTĂ:

În majoritatea cazurilor, lucrările de dezvoltare sunt efectuate pe infrastructura proprie a abac.software. Livrabilele sunt transferate către infrastructura (sau conturile) beneficiarului numai după ce toate comenzile de lucru restante sunt plătite și acceptate în mod oficial. În acel moment, proprietatea intelectuală pentru comanda de lucru respectivă este transferată beneficiarului.

Procesul de acceptare

Fiecare livrabil produs în timpul dezvoltării fiecărei faze necesită acceptarea formală din partea beneficiarului. Această abordare structurată asigură că ambele părți rămân aliniate pe tot parcursul proiectului, reducând neînțelegerile și menținând activitatea pe drumul cel bun către o livrare de succes.

Cum funcționează:

  • Când un produs livrabil este gata, abac.software îl trimite clientului pentru revizuire.

  • Clientul are apoi la dispoziție 5 zile lucrătoare fie să:

    • acceptă produsul livrat, confirmând că acesta îndeplinește specificațiile convenite, sau

    • Prezentați o listă clară, consolidată a motivelor specifice pentru neacceptare.

Dacă clientul furnizează o astfel de listă în intervalul de 5 zile:

  • abac.software va evalua feedback-ul și va remedia problemele cât mai repede posibil.

  • Livrabilul corectat este apoi trimis din nou pentru acceptare.

  • Acest ciclu (depunere, revizuire, remediere) continuă până când livrabilul este acceptat sau nu sunt formulate noi obiecții în termen de 5 zile lucrătoare, moment în care livrabilul este considerat acceptat în mod automat.

Acest lucru se face pentru a accelera procesul de acceptare și pentru a se asigura că dezvoltarea poate continua.

 

Odată ce toate livrabilele individuale au fost acceptate în mod oficial, abac.software va solicita acceptarea finală pentru întregul proiect.

Această etapă confirmă faptul că soluția completă – așa cum este livrată, instalată și implementată pe infrastructura clientului – este aprobată și pregătită pentru utilizarea operațională. Acceptarea finală este necesară pentru a trece proiectul în faza de garanție, în timpul căreia defectele eligibile vor fi remediate gratuit în conformitate cu politica noastră de garanție.

Procedura de acceptare pentru livrarea finală funcționează în același mod structurat ca și pentru produsele individuale:

  • La solicitarea acceptării finale, clientul are la dispoziție 10 zile lucrătoare fie să:

    • Acceptați în mod oficial proiectul, sau

    • Prezentați o listă clară și consolidată a problemelor specifice care împiedică acceptarea.

  • Dacă o astfel de listă este prezentată în intervalul de 10 zile, abac.software va evalua feedback-ul, va rezolva orice problemă valabilă și va retrimite pentru acceptare.

  • Acest ciclu continuă până când acceptarea este confirmată sau până când trec 10 zile lucrătoare fără noi obiecții, moment în care proiectul este considerat automat acceptat.

 

NOTĂ: Rugăm beneficiarii să efectueze această revizuire cu bună credință și să evite depunerea de cereri care nu se încadrează în domeniul de aplicare sau în cerințele proiectului. Scopul acestui proces este de a asigura claritatea, responsabilitatea comună și livrarea la timp – nu de a permite întârzieri sau dispute inutile.

Tranziția la garanție

La acceptare, proiectul intră în perioada de garanție, în timpul căreia anumite tipuri de defecte identificate în timpul utilizării în producție sunt remediate gratuit de către abac.software (așa cum este definit în Politica noastră de garanție). În timpul perioadei de garanție, reclamațiile depuse vor fi procesate așa cum se prevede în Politica de garanție.

Avantajele modelului cu conducte

 

✅ Structură contractuală clară, cu faze și rezultate bine definite

✅ Costuri și termene previzibile, care sprijină planificarea eficientă a bugetului

✅ Libertate față de blocajul furnizorului, clientul având posibilitatea de a evalua continuarea după fiecare fază

Limitări ale modelului cu conducte

 

⚠️ Mai puțină flexibilitate pentru modificări majore ale domeniului de aplicare odată ce fazele au fost convenite și contractate

⚠️ În timp ce ajustările mici pot fi adesea acomodate (sub rezerva acordului abac.software), modificările semnificative pot necesita revizuirea fazelor anterioare sau emiterea de ordine de modificare

Acest model este cel mai potrivit pentru proiectele în care un grad ridicat de planificare, predictibilitate și control al costurilor și în care clientul este pregătit să investească în specificații clare încă de la început pentru a asigura succesul dezvoltării.

2. Modelul flexibil

Modelul Modelul flexibil este o abordare de dezvoltare colaborativă și adaptivă bazată pe facturarea în timp și materiale.

Acest model este conceput pentru proiecte în care cerințele pot evolua în timp sau unde clientul dorește control maxim asupra priorităților și capacității.

În loc de un domeniu de aplicare fix, definit în prealabil prin contract, această abordare permite planificarea, iterația și livrarea continue, în care clientul influențează în mod direct activitatea echipei.

Activități cheie

  • Adunarea echipei: Alocăm membri calificați ai echipei la proiect într-un timp și materiale adaptate la nevoile clientului.

  • Planificarea iterațiilor: Împreună cu clientul, definim dezvoltarea iterații de durată personalizată (de obicei 2 săptămâni), fiecare cu propriul domeniu de aplicare.

  • Definiția domeniului de aplicare: La începutul fiecărei iterațiiclientul specifică în mod clar ce trebuie livrat în perioada respectivă.

  • Estimare și planificare: Echipa utilizează viteza cunoscută (sarcini realizabile într-un anumit interval de timp) pentru a ajuta la estimarea, planificarea și angajarea în domeniul de aplicare al iterației.

  • Implementare: Echipa implementează, testează și pregătește livrabilele în conformitate cu planul convenit.

  • Sesiuni demonstrative: La sfârșitul fiecărei iterațiidesfășurăm o sesiune demonstrativă cu clientul pentru a analiza munca depusă și pentru a colecta feedback.

  • Implementare: Livrabilele sunt implementate în infrastructura clientului la sfârșitul fiecărei iterații.

  • Facturare: Clientul plătește pentru costul real al echipei pentru fiecare iterație.

Principalele realizări

  • Periodic, incremental caracteristici și îmbunătățiri software, furnizate în conformitate cu obiectivele iterației

  • sesiuni demonstrative la sfârșitul fiecărei iterații pentru a analiza progresul și rezultatele

  • Funcționalitate implementată, testată pe infrastructura clientului la încheierea fiecărui ciclu

  • Actualizat portofoliul de proiecte sau lista de sarcini, reprioritizate după cum este necesar pentru următoarea iterație

Avantajele modelului flexibil

✅ Înaltă adaptabilitate: Clienții pot ajusta cerințele, prioritățile sau domeniul de aplicare la începutul oricărei iterații

✅ Permite scalarea dimensiunii sau componenței echipei pentru a răspunde nevoilor în evoluție

✅ Promovează feedback continuu și aliniere prin demonstrații regulate

✅ Sprijină schimbarea condițiilor de piață sau de afaceri

Dezavantajele modelului flexibil

⚠️ Nu există un domeniu de aplicare sau un termen limită strict, fix: Depinde de client să să monitorizeze traiectoria generală a proiectului

⚠️ Solicită clientului să să participe activ în definirea domeniului de aplicare și a priorităților fiecărei iterații

⚠️ Fără o planificare clară, există riscul de extindere a domeniului de aplicare sau de utilizare ineficientă a capacității

⚠️ Recomandăm clienților să caute suport de consultanță dacă doresc ajutor în planificarea și gestionarea unui proces iterativ de succes

 

Acest model este cel mai potrivit pentru clienții care apreciază flexibilitatea și controlul, și care sunt pregătiți să se implice activ în modelarea, prioritizarea și revizuirea lucrărilor pe parcursul dezvoltării.

3. Tranziția între modele

Noi recunoaștem că proiectele software evoluează adesea în domeniul de aplicare, complexitate și certitudine în timp. Pentru a sprijini acest lucru, abac.software oferă clienților flexibilitatea de a schimba între Modelul Pipelined și Modelul flexibil în funcție de cerințele proiectului.

Cum funcționează

  • Un beneficiar poate opta să treacă de la un model la altul după ce toate produsele în curs de execuție au fost livrate și acceptate oficial.

  • Acest lucru asigură că lucrările deja în curs sunt finalizate conform specificațiilor și ambele părți au o linie de bază clară, convenită înainte de schimbarea abordării.

  • Trecerea de la un model la altul implică de obicei revizuirea și actualizarea domeniul de aplicare, abordarea și termenii comerciali într-un nou ordin de lucru sau acord.

De ce susținem acest lucru

Scopul nostru este de a să oferim clienților flexibilitate maximă pentru a construi soluții software într-un mod care se potrivește cel mai bine nevoile de planificare, constrângerile bugetare și înțelegerea evolutivă a cerințelor.

Exemple de schimbare a modelelor

✅ Începând cu Pipelined, trecând la Flexible:

  • Multe proiecte încep cu o fază structurată, clar specificată (de exemplu, dezvoltarea MVP) folosind Modelul Pipelined.

  • Odată ce nucleul este stabil, clientul poate să treacă la modelul flexibil pentru îmbunătățiri continue, iterații sau scalare.

✅ Începeți sau continuați în Flexible, apoi utilizați Pipelined:

  • Un client poate dori o explorare timpurie în cadrul unui model flexibil pentru a defini și a rafina caracteristicile.

  • Pentru modulele deosebit de critice sau cu impact ridicat, aceștia pot trece apoi la Modelul cu conducte pentru a asigura specificații și control stricte.

Principii esențiale

  • Claritatea înainte de toate: Fiecare schimbare de model este formalizată prin acorduri clare pentru a asigura înțelegerea și alinierea comună.

  • Fără blocaj: Clienții își păstrează libertatea de a alege abordarea care li se potrivește cel mai bine în fiecare etapă.

  • Tranziții ușoare: abac.software sprijină clienții în planificarea și gestionarea aceste tranziții în mod eficient.

 

Această abordare asigură că fiecare parte a proiectului dumneavoastră este construită cu nivelul corect de flexibilitate, structură și predictibilitate, menținând în același timp disciplină profesională în livrare.