Lucrare practică.

Git și GitHub

1.Despre Git și GitHub

Git sau GitHub este din ce in ce mai utilizat si cerut de toti angajatorii, fiind un software care te ajuta la
versionarea codului tau. De exemplu, daca vrei sa construiesti pe baza a ceea ce ai lucrat pana acum sau
sa aduci si alte persoane care sa contribuie la munca ta, nu poti tine codul pe calculatorul tau pentru ca va
deveni dificil ca si altii sa acceseze si sa lucreze cu ceea ce tu ai facut pana la momentul respectiv.

Creatorul Linux, pe numele lui Linus Torvalds, este cel care s-a gandit la o metoda de versionare a codului,
in momentul in care a considerat ca este nevoie ca mai multi programatori sa lucreze la versiunea sa de
Linux.

Prin folosirea Git, altii vor putea adauga si-si pune amprenta pe codul deja creat de tine. Iti prezint in video
câteva exemple practice și iți prezint în detaliu posibilitățile ce Git ti le ofera. De asemena, voi vorbi despre
Repository si cat de util acesta iti poate fi.

2. Trei pași ai procesului de lucru pe repozitoriu local

3) Instalarea aplicației Git pentru consolă și Git Bash: https://git-scm.com/downloads

4) Lansarea aplicației

Din meniul Start și selectăm Git Bash

5) Afișarea datelor utilizatorului

git config --global user.name – afișare numele de utilizator

git config --global user.email – afișare adresa de e-mail a utilizatorului

6) Configurarea datelor utilizatorului

git config --global user.name "new user" – schimbă numele de utilizator

git config --global user.email "test@gmail.com" - modifică adresa de e-mail a utilizatorului

7) Listarea informației de configurare

git config --list

8) Help-ul sistemului Git

git help <comanda> sau git <comanda> --help
De ex. git help commit sau git commit --help
9) Crearea repozitoriului local
1. În directoriul c:/xampp/htdocs/ cream <mapa_proiectului>
2. În Git Bash scriem comanda cd c:/xampp/htdocs/<mapa_proiectului>
10) Inițializarea repozitoriului local
1. scriem comanda git init
2. verificăm dacă în repozitoriul local (<mapa_proiectului>) apare mapa .git
11) Adăugarea conținutului repozitoriului local
Adăugăm cel puțin trei fișiere(.img, .html, .php)
12) Verificarea statutului repozitoriului local
Comanda git status

13) Ciclul de viață al statutului fișierelor

14) Adăugarea fișierelor

git add .- adăugarea tuturor fișierilor

git add <nume fișier> - adăgarea unui singur fișier

15) Verificarea statutului repozitoriului local

Comanda git status

16) Facem careva modificări în codul fișierului index.html (adăugăm, ștergem, modificăm)

17) Verificarea statutului repozitoriului local

Comanda git status

18) Adăugarea modificărilor

git add .

19) Verificarea statutului repozitoriului local

Comanda git status
20) Acceptarea(commit-ul) în repozitoriul local

git commit -m ”<descriere commit>”

21) Verificarea statutului repozitoriului local

Comanda git status

22) De modificat, adăugat și de șters cod și fișiere

-status, -add, -commit

23) Crearea repozitoriului la distanță

Accesam site-ul www.github.com și creăm cont (dacă nu avem) și un repozitoriu de ex. testgit

24) Adăugarea repozitoriului la distanță

Scriem sau copiem git remote add origin git@github.com:cio3banu/testgit.git și îl

alipim/paste (SHIFT+INSERT) în Git Bash
25) Încărcarea commit-urilor locale curente în repozitoriul de la distanță (testgit) scriem în Git Bash

git push -u origin master

26) Navigare/Observarea/Examinarea în repozitoriu a commiturilor

27) Clonarea unui repozitoriu de la distanță

De exemplu: git clone https://github.com/laravel/laravel.git

Erori frecvent întâlnite:

1. Mesaj eroare:
warning: user.name has multiple values error: cannot overwrite multiple values with a single value
use a regexp, --add or --replace-all to change user.name.
Rezolvare:
Ștergem credențialele de la ghithub.com din Managerul de Credențiale

2. Mesaj eroare:
Permission denied (publickey)

Rezolvare:
1) Generăm key ssh cu comanda ssh-keygen în Git Bash și apăsând tasta enter de câteva ori.

2) Deschidem fișierul id_rsa.pub cu editorul Notepad, din mapa .ssh și copiem tot conținutul (ctrl+a și
ctrl+c)
3) În contul nostru GitHub accesăm settings

apoi accesăm SSH and GPG keys

în partea dreaptă apăsăm New SSH key și alipim(paste) key-a

Comenzi de bază Git

git init
Permite inițializarea depozitului în folderul curent

git status
Afișează starea curentă

git add
Urmărește modificările fișierului

git add index.html - adaugă index.html

git add. - adaugă toate fișierele

git commit
Salvează modificările în commit

git commit -m 'commit message' - creează un commit cu un mesaj

git branch
Lucrul cu ramurile din repozitoriu

git branch - afișează lista de ramuri

git branch branch-name - creează o nouă ramură cu numele branch-name

git branch -D branch-name - șterge ramura cu numele branchi-name

git checkout
Trece la o altă ramură

git checkout branch-name - trece la ultimul commit din ramura cu numele branch-name

git checkout -b branch-name - creează și trece la ramura cu numele branch-name

git merge
Fuzionează ramura curentă cu cea selectată

git merge branch-nume - îmbină ramura curentă cu ramura branch-name

git config
Configurarea și opțiunile git

git config --global user.name - Afișează numele de utilizator

git config --global user.name "new user" – Schimbă numele de utilizator

git config --global user.email - Afișează adresa de e-mail a utilizatorului

git config --global user.email "test@gmail.com" - Modifică adresa de e-mail a
utilizatorului

git push
Încarcă commit-urile locale curente într-un repozitoriu de la distanță

git pull
Preia modificările dintr-un repozitoriu de la distanță în cel local

git clone
Clonează proiectul dintr-un repozitoriu de la distanță
MODELELE CICLULUI DE
VIAȚĂ
Autor: Carp Alexandra
Catedra Informatică I
CEITI
• Modelele ciclurilor de viață reprezintă diverse procese sau metodologii ce sunt selectate pentru
dezvoltarea proiectelor în fucție de ce scopul acestor acestor proiecte și de de ce și-au propus să
realizeze aceste proiecte. Există foarte multe modele de cicluri de viață care au fost dezvoltate cu
scopul de a îndeplini diferite cerințe și specificații. Aceste modele definesc etapele proceselor și
ordinea în care acestea se execută.
WATERFALL (CASCADĂ)
 MODELUL CICLULUI DE VIAȚĂ ÎN CASCADĂ

• Cel mai puţin flexibil model de ciclu de viaţă. Totuşi este bine adaptat la proiecte care au o arhitectura bine
definită şi interfaţa cu utilizatorul şi cerinţele de performanţă stabilite.
• Modelul cascada funcţionează pentru anumite domenii problemă, în special cele în care cerinţele sunt bine înţelese
în avans şi este puţin probabil ca acestea să se schimbe în mod semnificativ pe parcursul dezvoltării. Într-un model
strict cascada, după ce fiecare fază este terminată, se trece la următoarea.
• Review-uri pot fi făcute înainte de a trece la următoarea faza, care permite posibilitatea modificărilor (care poate
implica un proces formal de control al schimbării). Review-urile pot fi, de asemenea, utilizate pentru a se asigura
că faza este într-adevăr completă; criteriile de faza de finalizare sunt adesea menţionate ca o “poarta” pe care
proiectul trebuie să o treacă, pentru a trece la următoarea fază.
• Cascada descurajează revizitarea şi revizuirea oricărei faze anterioare după ce a fost completată. Această lipsă de
flexibilitate într-un model pur cascada a fost o sursă de critică din partea altor modele mai flexibile.
 AVANTAJE ȘI DEZAVANTAJE

• Avantaje
- Simplu și ușor de utilizat
- Fazele și procesele sunt finisate pe rând
- Bun pentru proictele mici unde cerințele sunt bine înțelese de la bun început.
• Dezavantaje
- Modificarea cerințelor este foarte greu de gestionat
- Prototipurile pot fi produse doar foarte târziu
MODELUL IN V
• Modelul ciclului de viață în V reprezintă o varianta a modelului cascada, care pune in evidenta
corelarea dintre activitatile de specificare si cele de testare, inlantuirea in timp a activitatilor fiind
aceeasi. V-ul vine e la validare. La fel ca și modelul în cascadă, modelul în V reprezintă un proces
secvențial de execuție a proceselor de dezvoltare soft.
• Fiecare fază trebuie încheiată înainte ca faza următoare să înceapă. Testarea produsului se
realizează în paralel cu partea de dezvoltare in care se află produsul.
 AVANTAJE ȘI DEZAVANTAJE

• Avantajele acestui model :

- Ușor și simplu de folosit.
- Activitățile de testare precum planificarea testelor si modelelor de testare se realizează înainte de testarea propriu zisă
ceea ce salvează foarte mult timp.
- Defectele programului sunt găsite la timp și costul reparației va fii mult mai mic
- Este util pentru proiecte micuțe unde ceințele sunt foarte bine specificate
• Dezavantajele acestui model :
- Foarte rigid și deloc flexibil
- Softul este dezvoltat în timpul etapei de dezvoltare, deci înainte de această etapă nu avem prototipuri ale softului
- Dacă se produc schimbări în timpul programării toate documentele de test și documentele cu specificații trebuiesc
updatate.
-Acest model este util a fii folosit în proiecte micuțe sau medii în care cerințele sunt foarte clare și stabile de la început.
De asemenea, este de preferat folosirea acestui model când avem la dispoziție resurse tehnice destul de avansate.
AGILE SOFTWARE DEVELOPMENT
 Modelele de dezoltare software agile sunt tot un fel de model de ciclu de viață cu incrementare. Softul este dezvoltat
prin metode prin cicluri rapide, iterative. Rezultatul este dat de produse micute care se realizează după fiecare build și
care îmbunătățesc mereu produsul anterior. Fiecare produs lansat este testat riguros pentru a se asigura faptul că se
menține calitatea softului. Este folosit mai ales pentru aplicații care au nevoie de un timp exact.
Acest model este folosit când este nevoie de implementarea unor modificări noi. Oferă o libertate foarte mare
schimbărilor. Aceste schimbări sunt introduse cu un preț foarte mic datorită rapidității cu care sunt livrate noi variante
de produs. Pentru a implementa o nouă funcționalitate, programtorii pierd numai munca pe câteva zile sau chiar
cateva ore.
Spre deosibire de modelul în cascadă, în modelul agil se pune foarte puțin accent pe planificare înainte de începerea
proiectului. Acest model presupune ca dorințele și cerințele clientului vor fii într-o schimbare permanentă datorita
dinamicității it-ului. Modificările pot fii mereu discutate și implementate sau anumite părți pot fii scoase în totalitate
în urma discuților cu clienții. Prin urmare șansa ca la final clientul să obțină proiectul dorit este mult mai mare.
 AVANTAJELE ACESTUI MODEL:

 Foarte satisfăcător pentru client care poate primi continuu produse soft îmbunătățite

 Oamenii și interacțiunile sunt puși în evidență spre deosebire de procesul în sine și uneltele de lucru. Clienții,
dezvoltatorii și testerii trebuie să interacționeze în permanentă.

 Produsele soft sunt livrate în intervale de timp foarte scurt

 Conversațile fată în față sunt cele mai bune forme de comunicare

 Pot avea loc colaborări zilnice între dezvoltatori și clienți

 Se pot face modificări în soft oricât de avansat e produsul fără probleme

 DEZAVANTAJELE ACESTUI MODEL

 Nu se pune suficient accent pe pe documentație și design

 Proiectul poate să o ia pe o cale greșită dacă reprezentatul clientului nu exprimă cu exactitate ce

anume dorește clientul la sfârșit

 Numai programatorii seniori sunt capabili să ia decizii referitoare la procesul de dezvoltare. Nu

este un domeniu ușor accesibil pentru programtorii juniori decât dacă lucrează cu ajutorul unui
programtor senior.
MODELUL ITERATIV
• Modelul ciclului de viață iterativ a fost gândit în opoziție cu modelul ciclui de viață în cascadă. Ideea
de bază a acestui model este: dacă un produs este construit foarte complex devine dificil de înțeles dar
și de implementat și conceput într-o singură fază. Modelul desparte modelul în mai multe faze prin
evoluție. Fiecare etapă urmând apoi a fii trecută prin faza de proiectare, de implementare și testare.
• O prima variantă de produs software funcțional este realizată dupa primul modul, deci avem acces la
un soft funcțional foarte devreme în ciclul de viață al produsului. Fiecare modul al modelului adaugă
noi funcționalități produsului anterior. Procesul se reia până obținem produsul final pe care ni l-am
propus.
• Ciclul de viaţă iterativ are la bază evoluţia produselor deja executabile, măsurabile şi deci pe evoluţia
elementelor concrete. El este opus modelului în cascadă care se baza pe producerea de documente.
Progresele se măsoară prin programe demonstrabile mai degrabă decât prin documente sau estimări,
ca în ciclul de viaţă în cascadă;
• In cursul dezvoltării clientul poate testa produsele intermediare
 AVANTAJELE ACESTUI MODEL:

• In fiecare etapa este livrat un produs executabil, care satisface o parte din cerintele utilizator.
Opus modelului cascada in care se elaboreaza documente.

• Prototipurile sunt livrate clientului/utilizatorilor.

• Feedback-ul utilizatorilor este distribuit pe intreg parcursul dezvoltarii.

• În cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in urmatorul prototip.
 DEZAVANTAJELE ACESTUI MODEL

• Necesită o foarte amănunțită planificare

• Necesită o definirea clară și completă a sistemului înainte ca acesta să poată fii spart în module și
incrementat pe bucăți

• Costul total este mai mare decât la modelul în cascadă.

MODELUL SPIRALĂ
• Modelul spirală este asemănător cu modelul iterativ, cu o pondere mai mare pusă pe analiza de risc.
Modelul spirală are patru etape:
• Planificare
• Analiza riscului
• Dezvoltare
• Evaluare
• Un produs software trece prin aceste etape în mod repetat. Linia de bază a spiralei începe în fază de
planificare, se colectează specificațile și se evaluează riscul. Fiecare sublinie se construiește plecând de
la linia de bază.
• Acest model este indicat a fii folost atunci când pentru un proiect, riscurile și costurile sunt foarte
importante. Se folosește numai pentru proiecte mari. Se recomandă atunci când clienții nu sunt foarte
siguri de ceea ce își doresc de la produsul final. Indicat atunci când cerințele sunt complexe, când
produsul este nou și pentru modificări mari.
• Etapa de planificare
În această etapă a proiectului are loc definirea a ceea ce trebuie dezvoltat. Obiectivul aici este să se afle
nevoile clientului şi să se definească foarte clar cerinţele privind viitorul produc software. Se stabilesc
exact cerințele în conformitate cu dorințele clientului
• Etapa de analiza a riscului
În această etapă a proiectului, se realizează un proces pentru a se descoperi riscurile și a se încerca să
se gasească soluții alternative. La sfârșitul acestei faze se crează un prototip. Dacă s-a descoperit vreun
risc în timpul analizei de risc atunci soluțile sugerate sunt implementate
• Etapa de dezvoltare
În această etapă softul este implementat în paralel cu testarea la sfârșitul fiecarei faze.
• Etapa de evaluare
În această etapă clientul poate testa varianta produsului înainte ca acesta să treacă la o nouă spirală.
 AVANTAJELE ACESTUI MODEL:

 Riscurile sunt evitate

 Foarte bun pentru proiecte mari/critice

 Necesită foarte bun control si documentație

 Funcționalități noi pot fii introduse între timp

 Soft funcțional este produs în primii pași ai ciclului

 DEZAVANTAJELE ACESTUI MODEL:

 Costul este destul de mare

 Analiza riscului necesită personal cu experiență

 Succesul proiectului depinde foarte mult de rezultatele analizei riscului

 Nu funcționează bine pentru proiecte mici

 CONCLUZII
• În concluzie putem spune ca fiecare model de ciclu de viață prezentat nu este nici mai bun, nici mai prost decât altul doar
se adresează unor tipuri de produse diferite.Modelul în cascadă dă rezultate acceptabile numai în cazul în care este efectiv
posibilă înlănţuirea fazelor fără prea multe probleme. Se presupune că totalitatea cerinţelor să fie cunoscută în totalitate şi
problema să fie înteleasă în deplin de analişti. Trebuie de altfel ca soluţia finală să fie uşor de găsit de proiectanţi şi
implementarea să fie simplă - redusă la generarea automată a codului plecând de la documentele de proiectare.
• Modelul în V este util a fii folosit în proiecte micuțe sau medii în care cerințele sunt foarte clare și stabile de la început. De
asemenea, este de preferat folosirea acestui model când avem la dispoziție resurse tehnice destul de avansate.Modelul
incremental poate fii folosit atunci când cerințele întregului model sunt complete foarte bine definite și clar înțelese.
Caracteristicile principale trebuiesc să fie foarte bine stabilite, alte detalii mai pot fii schimbate în timp. Se folosesc atunci
când există o cerere de livrare a produsului într-un timp limitat.
• Modelul de agile programming este folosit când este nevoie de implementarea unor modificări noi. Oferă o libertate foarte
mare schimbărilor. Aceste schimbări sunt introduse cu un preț foarte mic datorită rapidității cu care sunt livrate noi
variante de produs. Pentru a implementa o nouă funcționalitate, programtorii pierd numai munca pe câteva zile sau chiar
cateva ore.
• Modelul spirala este indicat a fii folost atunci când pentru un proiect, riscurile și costurile sunt foarte importante. Se
folosește numai pentru proiecte mari. Se recomandă atunci când clienții nu sunt foarte siguri de ceea ce își doresc de la
produsul final. Indicat atunci când cerințele sunt complexe, când produsul este nou și pentru modificări mari.
Project Management Tools
Alexandra Carp
CEITI
Catedra Informatică I
Prin PM Tools se înțelege totalitatea instrumentelor
și aplicațiilor utilizate la gestionarea/elaborarea unui
proiect.
Instrumentele de lucru sunt de două tipuri: organizaționale și
pentru planificare și vizualizare.

 Organizaționale
 Ciclul de viață
 Prezentarea proiectului
 Work Breakdown Structure
 Planificare și dezvoltare
 Gantt Chart
 PERT
 Metoda căii critice/ Calea critică
Organization Tools
 Ciclul de viață

Înțelegerea și planificarea
duratei de viață a proiectului
Patru etape de bază
 Inițializarea
 Planificarea
 Execuția
 Finalul/ Închiderea
 Propunerea /Prezentarea proiectului

 Documentarea și argumentarea proiectului

 Oferă baza necesară pentru planificarea proiectului
 Deseori e ca un răspuns pentru RFP (Request for Proposal)
* RFP = cerere deschisă sau direcționată pentru proiectele propuse
care explică o anumită necesitate
Componente tipice

 Definirea problemei
 Scopul, obiectivele și domeniul de aplicare
 Părți interesate
 Beneficii
 Resursele necesare(financiare etc)
 Însărcinări și repere
 Riscuri
 Rezulatatul și livrabilele
 Work Breakdown Structure

 Definește și organizează elementele de lucru ale

proiectului
 Împarte lucrul într-un set de task-uri majore
 Fiecare task are asignată o anumită valoare pentru
porțiunea de lucru efectuată
Scheduling and Visualization Tools
Gantt Chart

 A fost elaborată în anul 1917 de către Henry Gantt drept un

instrument pentru managementul producției de fabrică
 Descrie timpul de inițializare și durata Task-urilor majore
 Poate fi utilizată ca monitor pentru progresul în dezvoltare
Gantt Chart Example

 Barele albastre arată perioada de timp pentru fiecare task

 Săgețile descriu dependențele
 Liniile negre interioare și procentajul arată nivelul progresului
 Program Evaluation & Review Technique
(PERT)
 Elaborată în anul 1958 pentru programul de rachete Polaris
 A fost utilizată extensiv în timpul războiului rece ăn proiecte ca
CORONA și SR-71
 Oferă estimarea timpului, planificarea și interdependențele task-
urilor WBS
 O putem vizualiza în modelul rețelei
 PERT Network

 Ilustrează WBS-ul cu estimările timpului

 Nod-urile = repre(task-uri îndeplinite)
 Săgețile = activități (task-uri cu termenul necesar)
 Critical Path Method (CPM)

 Similară cu PERT(și elaborată înacelași timp)

 Accente diferite:
 Calea critică= cel mai lung/mare set de task-uri care determină timpul total pentru
proiect
 Crash time estimates= cel mai scurt timp necesar în situații de urgență
CPM Chart
 Software

 Foarte multe programe

 Comercial desktop
 Microsoft project
 Primavera
 Open source
 dotProject
 Web – based
 eProject
 Concluzii

 PM ne oferă un framewokr pentru a planifica proiecte de scară largă

 Instrumente de ajutor în organizarea, planificarea și vizualizarea
volumui necesar de muncă
 E foarte probabil să vă ciocniți în viitoarea voastră carieră 
MANAGEMENTUL DOMENIULUI
Autor: Carp Alexandra
 INTRODUCERE

Managementul domeniului (engl. “scope”) unui proiect se referă la gestionarea anvergurii, amplorii,
întinderii, dimensiunii proiectului. Acest tip de management include procesele care garantează că
proiectul include toate activităţile necesare, şi numai activităţile necesare, pentru a finaliza proiectul
cu succes. Managementul domeniului se ocupă deci cu definirea şi controlul a ceea ce este inclus
sau nu în proiect.
 MANAGEMENTUL DOMENIULUI INCLUDE
URMĂTOARELE ASPECTE:A
 Definirea domeniului;
 Crearea structurii de descompunere a activităţilor;
 Verificarea domeniului;
 Controlul domeniului.
Trebuie reţinut faptul că îndeplinirea domeniului proiectului este măsurată în raport cu planul
proiectului, iar îndeplinirea domeniului produsului este măsurată în raport cu cerinţele produsului.
 DEFINIREA DOMENIULUI

Cel mai frecvent motiv pentru eşecul proiectelor este definirea deficitară a domeniului, atunci când
aşteptările părţilor interesate, în special ale clientului sau sponsorului, sunt diferite de aşteptările
echipei proiectului. Uneori, este dificil de convins clientul că atât el cât şi echipa au de fapt acelaşi
scop în cadrul proiectului, acela de a-i oferi clientului un produs util şi cu funcţionalităţile dorite.
 TABELUL DE MAI JOS PREZINTĂ O COMPARAŢIE ÎNTRE ABORDAREA CLASICĂ ŞI
CEA AGILĂ ÎN PRIVINŢA DEFINIRII DOMENIULUI, CARE ÎN PROIECTELE AGILE SE
NUMEŞTE PLANIFICARE MULTINIVEL.

Abordarea clasică Abordarea agilă

Pregătirea unui document de Specificare a Domeniului
Proiectului, care include elemente precum: obiectivele şi
limitele proiectului, descrierea domeniului
Definirea punctelor de referinţă (engl. “milestones”) şi a
livrabilelor proiectului
Specificaţiile produsului şi criteriile de acceptare / recepţie
Presupuneri şi constrângeri
Organizarea unei întâlniri pentru definirea viziunii asupra
produsului, confirmarea şi clarificarea obiectivelor, limitelor
şi descrierea domeniului prin exerciţii precum enunţul din
lift (engl. “elevator pitch”)
Organizarea unei întâlniri de planificare a foii de parcurs
(engl. “roadmap”) a proiectului, precum şi întâlniri (de
exemplu trimestriale) de planificare a punctelor de referinţă
şi a livrabilelor la nivel de iteraţie
Întâlnire de planificare a iteraţiei cu scopul stabilirii
detaliilor fiecărei caracteristici şi a activităţilor necesare
pentru terminarea acestora pe baza criteriilor de finalizare
ale echipei şi a criteriilor de acceptare ale clientului
Toate întâlnirile identifică sau revizuiesc presupunerile şi
constrângerile
 VERIFICAREA DOMENIULUI

Verificarea domeniului se realizează în cadrul iteraţiei, clientul putând revizui, testa şi accepta
caracteristicile implementate. În mod ideal, aceasta are loc pe parcursul iteraţiei, dar poate avea loc
şi la sfârşitul acesteia, la prezentarea (demonstrarea) codului. Caracteristicile neimplementate, din
lipsa timpului sau din cauza problemelor de specificare sunt reintroduse pe lista de cerinţe (engl.
“backlog”) sau intră în următoarea iteraţie, conform deciziei clientului.
 CONTROLUL DOMENIULUI

 Utilizarea unui sistem de control al modificărilor

 Actualizarea tuturor documentelor potrivit modificărilor aprobate
 CONCLUZII

Unul din motivele eşecului proiectelor este lipsa identificării clare a livrabilelor care trebuie
realizate. Fără stabilirea unei linii de bază a domeniului, nici liniile de bază ale costului şi graficului
de lucru nu pot fi precizate.
MANAGEMENTUL SCOPULUI,
TIMPULUI SI COSTULUI
Autor: Carp Alexandra
Realizarea unui proiect în cadrul constrângerilor date ca scop, timp și costuri
reprezintă chestiuni fundamentale pentru asigurarea succesului. Indiferent dacă se
refera la o nouă conductă de gaz, o clădire sau o centrală nucleară, toate
proiectele necesită monitorizare și control constant pentru a-și atinge obiectivele.
 PE BAZA PROCESELOR DE MANAGEMENT DE PROIECT DEFINITE DE PMI,
RECOMANDĂM ZECE PAȘI PENTRU A PREGĂTI LINIA DE BAZĂ A PROIECTULUI ÎN
CEEA CE PRIVEȘTE DOMENIUL DE APLICARE, TIMPUL ȘI COSTUL:

 Definiti obiectivele și scopul proiectului;

 Detalierea Scopului in Pachete de Lucrari (WBS)
 Detaliați fiecare pachet de lucrari în activități / sarcini;
 Estimați durata activităților, luând în considerare resursele disponibile;
 Stabiliți Prgramul de Executie al lucrarilor cu echipa de proiect;
 Înțelegeți Drumul Critic din proiect;
 Estimați costurile;
 Efectuați o evaluare a riscului pentru proiect;
 Definiți procedura de măsurare a progresului
 Obțineți aprobarea pentru baseline-ul proiectului.
 1. DEFINITI OBIECTIVELE ȘI SCOPUL
PROIECTULUI
După inițierea proiectului, trebuie să înțelegeți pe deplin ce este în și din domeniul dvs. de aplicare,
în special în contractele cu sumă forfetară, unde există o muncă fixă ​care trebuie făcută într-un timp
și costuri convenite. Domeniul de activitate, declarația de domeniu sau specificațiile tehnice ale
licitației reprezintă exemple de astfel de documente care trebuie stabilite cu atenție.
Nu faceți confuzie între obiectiv și obiectiv! (de exemplu: Inginerie proiectare, achiziții, construcție
și punere în funcțiune a unei instalații de prelucrare a gazelor; Proiect / Companie Obiectiv:
realizarea profitului / funcționarea în condiții de siguranță …)
 2. DETALIEREA SCOPULUI IN PACHETE DE
LUCRARI (WBS)

Bazat pe principiul Cum să mâncați un elefant? Bucată cu bucată. Gestionarea

pachetelor de lucru mai mici este întotdeauna mai ușoară pentru contractare,
planificare și raportare.
Aveți grijă să il detaliati prea mult. Acest lucru trebuie făcut în conformitate cu
strategia de contractare și cerințele companiei.
3. DETALIAȚI FIECARE PACHET DE LUCRARI ÎN
ACTIVITĂȚI / SARCINI
Fiecare pachet de lucru este de obicei definit ca o listă a activităților / sarcinilor necesare care
trebuie îndeplinite. Se recomandă utilizarea verbelor atunci când se numesc acestea și se utilizează
suficiente activități pentru a putea măsura progresul, în funcție de tipul contractului. Fiecare dintre
aceste activități va reprezenta părți din domeniul de aplicare al proiectului și va avea un timp și un
cost estimat.
4. ESTIMAȚI DURATELE ACTIVITĂȚILOR, LUÂND
ÎN CONSIDERARE RESURSELE DISPONIBILE
După ce ați asigurat că lista tuturor activităților a fost definită în conformitate cu proiectul WBS,
puteți începe cu estimările de timp, pregătiți pentru a construi programul. Fiecare estimare trebuie
realizată în mod obiectiv împreună cu echipa de proiect și documentată, deoarece progresele
viitoare vor fi măsurate față de aceste estimări. În ciuda celei mai utilizate tehnici este judecata
experților, pot fi utilizate diferite alte tehnici: proiectele analogice, parametrii, trei puncte, luarea
deciziilor de grup și analiza rezervelor. Evitați includerea rezervelor suplimentare atunci când faceți
estimarea. Acest lucru ar putea duce la un program mai lung!
 5. STABILIȚI PRGRAMUL DE EXECUTIE AL
LUCRARILOR CU ECHIPA DE PROIECT
Un program bun de proiect este obținut cu implicarea echipei de proiect. Nu este suficient ca doar
managerul de proiect sau planificatorul să efectueze programarea inițială, deoarece restul echipei nu
va avea proiectul să cumpere proiectul pentru a-și îndeplini sarcinile în timpul dat. Asigurați-vă că
toate constrângerile proiectului și interfețele dintre diferiții contractanți sunt luați în considerare!
Verificați dacă toate activitățile sunt legate, cu excepția milestone-urilor de început și incheiere.
 6. ÎNȚELEGEȚI DRUMUL CRITIC DIN PROIECT

Data de finalizare a proiectului este reprezentată de Calea Critică sau de secvența de activități cu
zero marja. În funcție de constrângerile proiectului, este posibil să aveți o marja totala negativa sau
pozitiva; în acest caz, calea critică este definită de cea mai lungă cale. Este recomandabil să
analizați și activitățile cu marja mica sau aproape critice, deoarece programul se poate schimba
întotdeauna. Câte căi critice are un proiect? Unul sau mai multe. (de ex .: 2 sau mai multe activități
planificate în paralel)
 7. ESTIMAȚI COSTURILE

Estimarea proiectului este poate cel mai important pas pentru managerii de proiect, deoarece
performanța costurilor este măsurată în raport cu estimarea inițială. Tehnica cea mai utilizată pentru
estimarea costurilor este cea de jos în sus, de la cel mai mic detaliu la nivelul proiectului, prin
adăugarea resurselor necesare proiectului (umane, echipamente, materiale). Alte tehnici
sunt: ​judecata experților, proiectele analoage, parametrii, analiza ofertelor, tehnicile de decizie de
grup. Prin adăugarea costurilor la activitățile proiectului, puteți genera fluxul de numerar al
proiectului și asigurați-vă că întreprinderea are banii necesari pentru a susține proiectul, în
conformitate cu Planul de plăți
 8. EFECTUAȚI O EVALUARE A RISCULUI
PROIECTULUI
Estimările inițiale ale proiectului în ceea ce privește timpul și costul reprezintă planul determinist.
După cum sa menționat la început, 64% dintre proiectele din întreaga lume se confruntă cu depășiri
ale costurilor, iar 73% întârzie întocmirea rapoartelor. Luând în considerare riscuri sau incertitudini
suplimentare înainte de semnarea contractului, vă veți ajuta să pregătiți rezervele și să vă așteptați
pentru neașteptate. Cu o probabilitate aleasă de 50%, aveți șanse bune să finalizați proiectul în
cadrul constrângerilor date.
 9. DEFINIREA PROCEDURII DE MĂSURARE A
PROGRESULUI
Ați finalizat estimările proiectului, acum gândiți-vă la viitor. Cum veți măsura performanța dvs.? Ce
va însemna că progresul proiectului este de 35%? Cum veți colecta date? Activitățile dvs. sunt
măsurabile?
Configurarea unei proceduri de măsurare a progresului vă va face să știți ce înseamnă progresul. O
ponderare a proiectului vă va permite să comparați progresul cu costurile și să măsurați performanța
proiectului.
 10. OBȚINEȚI APROBAREA DE BAZĂ A
PROIECTULUI
Înainte de începerea lucrărilor, asigurați-vă că linia de bază a proiectului este aprobată de toate
părțile obligatorii (manager de proiect, contractor, proprietar de proiect, echipa de proiect …).
Punctul de bază al proiectului reprezintă acordul inițial la data de începere a proiectului, în ceea ce
privește domeniul de aplicare, timpul și costul. Obținerea aprobării oficiale vă va ajuta în viitor să
sprijiniți revendicările sau să explicați abaterile de proiect. Aveți grijă ca aprobarea să vină
împotriva dvs. dacă semnați un plan prea optimist.
 Managementul
riscului

Obrijanu Mihail
Tabarcea Stelian
Riscul
Riscul în proiecte poate fi
definit ca șansa apariției unui
eveniment care poate avea
un impact negativ asupra
obiectivelor proiectului și se
măsoară în termeni de
probabilitate și consecință.
Managementul riscurilor este
o practică esențială în
realizarea cu succes a
proiectelor IT.
Managementul riscurilor presupune identificarea și
evaluarea riscurilor, identificarea și stabilirea
răspunsului la risc în viziunea micșorării posibilităților
de apariție a riscurilor, cât și diminuarea
consecutivelor produse, ca urmare a materializării
riscurilor.

?
 Certitudine
Raportul acțiune- Există un singur rezultat pentru fiecare
alternativă şi există cunoştinţe complete şi
exacte referitoare la el.

Risc
Există mai multe rezultate posibile pentru
fiecare alternativă şi fiecăreia pot fi
atribuite o valoare şi o probabilitate de
rezultat

realizare a rezultatelor.

?
Incertitudine
Numărul rezultatelor, valorile şi
probabilităţile nu sunt cunoscute.
Etapele de
management al
riscurilor
1. Planificarea managementului
riscului;
2. Identificarea riscurilor;
3. Analiza riscurilor;
4. Evaluarea riscurilor;
5. Tratarea riscurilor;
6. Monitorizarea și controlul;
7. Revizuirea și raportarea.
 Planificare

Planificarea managementului riscului – decizia asupra modului în care

vor fi abordate şi planificate problemele de management al riscului;
Planificare

Planificarea activităţilor de management al riscului este importantă pentru

nivelul, tipul şi vizibilitatea managementului riscului. Rezultatul va fi un plan
pentru managementul riscului elaborat în cadrul unor şedinţe la care participă
managerul întreprinderii, membrii echipei care sunt responsabili pentru
activităţile de bază şi orice altă persoană din întreprindere care poate influenţa
gestionarea activităţii în condiţii optime care vor aborda următoarele probleme:

• metodologie, care reflectă definirea abordărilor, instrumentelor şi a surselor de

informaţii care vor fi utilizate în procesele de management al riscului;
• roluri şi responsabilităţi, care determină membrii echipei şi a responsabilităţilor
pentru fiecare acţiune de management al riscului;
• buget, care constă în stabilirea şi elaborarea unui buget pentru managemntul
riscului;
• programare, care defineşte modul în care procesele de management al riscului
se vor desfăşura pe parcursul activităţii întreprinderii.
 Identificare

Identificarea riscurilor – determinarea factorilor de risc care ar putea

apărea pe parcursul desfăşurării activităţii.
Identificarea riscurilor asociate cu produsele software poate fi o
provocare majoră pentru manageri, deoarece există numeroase
moduri în care acestea pot fi descrise și clasificate. Riscurile
variază în cauze, severitate și consecințe, de aceea identificarea
acestora este foarte importantă, înțelegerea și gestionarea,
îndeosebi a color care sunt considerate riscuri la nivel înalt.
Dintre cele mai frecvente riscuri din domeniul IT, 22 au fost
identificate din literatura de specialitate și structurate în câteva
categorii.
Relații comerciale și
juridice
• Performanță inadecvată a părții terțe. Contractorul selectat nu este
potrivit pentru scopul proiectului. Antreprenorul este incapabil să
ofere o soluție care se întâlnește în timp, cost, calitate și performanța
obiectivelor.
• Conflicte privind protejarea proprietății intelectuale. Protecție
inadecvată a software-ului la începutul proiectului are ca rezultat
profitul concurenților prin copiere, urmat de costuri ridicate ale
pierderilor și micșorarea potențialul pieței.
• Conflicte între clienți și contractori. Poate apărea antagonism personal
sau dușmănie între clienți și contractorii de software ca un rezultat al
neînțelegerilor, modificări neprevăzute în domeniul de aplicare al
contractului, livrare pierdută sau întârziată sau un alt element de
dispută care polarizează clienții și contractanții în tabere de opoziție.
Situații economice

• Schimbarea condițiilor pieței. Recuperarea investițiilor în

proiectele software pot fi erodate datorită schimbării
condițiilor pieței sau progresului în ingineria software.
• Acțiuni concurențiale dăunătoare. Concurenți pot crea
soluții software mai rapid, cu funcționalitate mai mare, la
un cost mai mic, și să implementeze agresiv produsul
final în același spațiu de piață.
• Software-ul nu mai este necesar.
Comportamentul
uman
• Deficiențe de personal. Incapacitatea de a finaliza munca
alocată din cauza personalului insufficient.
• Calitatea slabă a personalului. Standardul de lucru este
slab din cauza lipsei de abilități, antrenament, motivație
și experiența personalului. Această lipsa de experiență se
poate extinde la hardware, sisteme de operare,
gestionarea bazelor de date și alte produse software.
 Probleme tehnice
• Documentație de utilizare inadecvată. Utilizatorii sunt incapabili să folosească pe deplin noul
produs așa cum era destinat.
• Software-ul nu este adecvat scopului. Utilizatorii deseori se întâlnesc cu software-ul care nu
îndeplinește în mod direct sarcinile. Acest lucru poate duce la o satisfacție scăzută a
utilizatorului.
• Performanță slabă. Software-ul selectat nu îndeplinește scopul pentru care a fost intenționat,
din cauza vitezei excesiv de lente sau probleme operaționale majore.
• Limitări tehnice spre atingerea scopului. O limitare tehnică întâlnită în timpul dezvoltării de
software generează întârzieri ale proiectului în timp ce determină căutarea unei soluții. În cazuri
extreme, o soluție poate să nu fie găsită. Rezultatul este anularea proiectului.
• Cerințe incomplete. Au fost obținute insuficiente informații în faza de analiză, având ca rezultat
îndeplinnirea produsului care nu îndeplinește obiectivele dorite.
• Interfață de utilizator inadecvată. Interfața de utilizator selectată sau dezvoltată nu reușește
îndeplinirea cerințelor utilizatorului.
 Activități de
gestionare și control
• Program și buget nerezonabili. Ptoiectul este incapabil să-și realizeze obiectivele din cauza restricțiilor
nerealiste impuse de bugetul proiectelor, calendarul, calitatea sau nivelul de performanță. Un proiect nu
reușește să-și îndeplinească livrarea câtre client sau este semnificativ peste buget pentru a fi reziliat.
• Modificări continue ale cerințelor de către client. Părțile interesate continuu modifică cerințele de
funcționalitate a software-ului pe tot parcursul ciclului de viață al proiectului.
• Nerespectarea progresului zilnic. Administrator nu reușește să analizeze progresul zilnic care rezultă în
eșecul proiectului.
• Lipsa responsabilității unice. Este tipic proiectelor software mari de a avea mulți lideri de echipă, dar nici
un punct unic responsabil pentru livrarea către client, rezultând neîndeplinirea obiectivelor proiectului.
• Conducere slabă. Managerul de proiect și / sau comitetul director nu asigură rezolvarea problemelor.
• Dezvoltarea funcționalității software greșite. Proiectarea și construcția de software pot să nu
îndeplinească scopul pentru care este intenționat.
 Activități individuale

• Placare cu aur (peste specificații). Echipa este axată pe analiză și

generare nivelurilor excesive de detalii pierzând din vedere
proiectul obiectiv.
• Așteptări nerealiste. Articolele promise pentru livrare către
persoanele fizice de către furnizor pot fi supra-vândute sau
vânzările sunt insuficiente.
 Analiza
riscurilor

Analiza calitativă a riscurilor

– realizarea unei ordini de
priorităţi în abordarea
factorilor de risc;
Evaluarea riscurilor

Analiza cantitativă a riscurilor

– măsurarea probabilităţii şi
consecinţelor factorilor de risc
şi estimarea implicaţiilor lor
pentru realizarea obiectivelor
activităţii întreprinderii.
 Tratarea riscurilor

Tratamentul riscului implică determinarea cele mai adecvate strategii

pentru a face față apariției acestuia. Potrivit lui Zhi, există patru
principale strategii de răspuns la riscurile proiectului: evitare,
reducere, transfer, păstrare.
Strategii de tratare

1. Evitare - neîntreprinderea activității care dă naștere riscului.

2. Reducere - reducerea probabilității unui eveniment riscant care
are loc și / sau impactul acestuia eveniment. Reducerea riscurilor
este cea mai frecventă dintre toate strategiile de gestionare a
riscurilor.
3. Transfer - transferul total sau parțial al riscului către o altă parte.
4. Păstrare - acceptați riscul și, prin urmare, consecințele care ar
rezulta.
Monitorizarea și
controlul = supravegherea factorilor
factorilor de risc permanenţi de risc,
identificarea noilor factori
de risc, realizarea
planurilor pentru
reducerea riscurilor şi
evaluarea eficienţei lor pe
parcursul evoluării
activităţii întreprinderii.
 Revizuirea și raportarea
este etapa finală care
înceie procesul de
management al riscurilor.
Această etapă are ca scop
verificarea finală a
produsului și formarea
concliziilor pentru un
management ulterior mai
Revizuirea eficient al riscurilor.
și raportarea
GIT. INSTALARE ȘI
CONFIGURARE
Autor: Carp Alexandra
GIT este un sistem de versionare distribuit ce ruleaza, sub licenta GNU, pe majoritatea
sistemelor de operare existente: Linux, OSX, Windows
Autorul Git este Linus Torvalds, parintele Linux, cel care l-a conceput in 2005 ca
urmare a conflictului aparut cu BitKeeper, vechiul sistem de versionare folosit pentru
kernelul de Linux.
Proiecte majore ce folosesc GIT: linux-kernel, debian, eclipse, Fedora, GNOME, GTK,
rsync, Ruby on Rails
•
 PENTRU A INSTALA GIT UTILIZĂM LINK-UL
DE MAI JOS
• https://git-scm.com/downloads
Inițial Git-ul a fost conceput ca un program folosit în linia de comanda, dar cu timpul au
fost dezvoltate si variante grafice ale acestui sistem (cele mai cunoscute sunt GitHub
Desktop App, GitHub pentru Mac, Tower, Gitbox, git-cola, gitg, bitbucket).
Git este efectiv o unealtă bazată pe linii de comandă, însă locul în care se centralizează
toate datele și în care are loc stocarea proiectelor este efectiv Hub-ul, mai exact
GitHub.com.
COMENZI GIT
Git include un utilitar numit git config, care vă permite să vizualizați și să configurați opțiuni care
controlează toate particularitatile Git, precum și aspectul acestuia. Acești parametri pot fi salvați în trei
locuri:
Fișierul / etc / gitconfig conține valori care sunt comune tuturor utilizatorilor din sistem și tuturor
depozitelor lor. Dacă specificați parametrul --system la pornirea git config, atunci parametrii vor fi citiți
și salvați în acest fișier
Fișierul ~ / .gitconfig sau ~ / .config / git / config stochează setările pentru un anumit utilizator. Acest
fișier este utilizat atunci când se specifică parametrul --global.
Fișierul config din directorul Git (adică .git / config) al depozitului pe care îl utilizați în prezent
stochează setările pentru un depozit specific.
• Setările la fiecare nivel ulterior anulează setările de la nivelurile anterioare, adică
valorile din .git / config înlocuiesc valorile corespunzătoare din / etc / gitconfig.
• Pentru a vizualiza toate setările instalate și a afla exact unde sunt setate, utilizați
comanda: $ git config --list --show-origin sau $ git config –list
• Pentru a afla valoarea unei chei anumite trebuie sa rulati $ git config <key>
 CONFIGURARE GIT/NUME DE UTILIZATOR

Primul lucru pe care ar trebui să îl faceți după instalarea Git este să furnizați numele și
adresa de e-mail. Acest lucru este important, deoarece fiecare commit din Git conține
aceste informații și este inclusă în commit-urile pe care le trimiteți și nu poate fi
modificată în continuare:
git config (--global) user.name <username>
git config (--global) user.email <email>
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Din nou, dacă este specificată opțiunea --global, atunci aceste setări trebuie făcute o
singură dată, deoarece în acest caz Git va folosi aceste date pentru tot ceea ce faceți pe
acest sistem.
Dacă doriți să specificați un nume sau un e-mail diferit pentru unele proiecte
individuale, puteți rula aceeași comandă fără parametrul --global din directorul cu
proiectul dorit.
Multe instrumente GUI oferă acest lucru la prima lansare.
 DACĂ AVEȚI NEVOIE DE AJUTOR PENTRU UTILIZAREA GIT, EXISTĂ TREI
MODURI DE A DESCHIDE MANUALUL DE AJUTOR PENTRU ORICE
COMANDĂ GIT:

• $ git help <команда>

• $ git <команда> --help
• $ man git-<команда>
• De exemplu, așa puteți deschide manualul pentru comanda git config:
• $ git help config
• De asemenea, dacă trebuie doar să vedeți o listă de opțiuni și nu doriți să citiți
documentația completă pentru o comandă, puteți utiliza opțiunea -h pentru a afișa o
scurtă instrucțiune despre cum să o utilizați:
• usage: git add [<options>] [--] <pathspec>...
• -n, --dry-run dry run
• -v, --verbose be verbose
• -i, --interactive interactive picking
• -p, --patch select hunks interactively
• -e, --edit edit current diff and apply
• -f, --force allow adding otherwise ignored files
• -u, --update update tracked files
• --renormalize renormalize EOL of tracked files (implies -u)
• -N, --intent-to-add record only the fact that the path will be added later
• -A, --all add changes from all tracked and untracked files
• --ignore-removal ignore paths removed in the working tree (same as --no-all)
• --refresh don't add, only refresh the index
• --ignore-errors just skip files which cannot be added because of errors
• --ignore-missing check if - even missing - files are ignored in dry run
• --chmod (+|-)x override the executable bit of the listed files
• --pathspec-from-file <file> read pathspec from file
• --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character
 CONFIGURAREA RAMURII IMPLICITE

Când inițializați un depozit cu git init, Git creează implicit o ramură numită master. De
la versiunea 2.28, puteți specifica un alt nume pentru a crea ramura implicită.
De exemplu, pentru a seta numele implicit al main pentru ramura dvs., executați
următoarea comandă:
$ git config --global init.defaultBranch main
 CREARE REPOSITORY

git init <directory>

 CLONE REPOSITORY

git clone <repository>

 ASOCIEREA CU PROIECT REMOTE

git remote add <nume> <URL-ul proiectului>

 STAREA FIȘIERELOR

git status
git log
git diff
 IGNORAREA ANUMITOR FISIERE

Fisierele sau directoarele ce se doresc a fi ignorate de sistemul de versionare pot fi

trecute intr-un fisier numit .gitignore.
Ex:
bin/ # va ignora toate fisierele din folderul bin
target/ # va ignora toate fisierele din folderul target
*.log # va ignora toate fisierele cu extensia .log
 SISTEME DE
CONTROL AL
VERSIUNILOR
Autor: Alexandra Carp
Catedra ” Informatică I „
Controlul versiunilor
◦ Controlul versiunilor (din engleză: version control sau revision control) este un domeniu software care
se ocupă cu gestionarea mai multor versiuni (numite și revizii) ale unor fișiere.

◦ Un sistem de control al versiunilor (SCV) reprezintă un produs software.

CLASIFICARE SCV
 PRIMA GENERAȚIE
( CLASICE/LOCALE )
Prima generatie
◦ Prima generatie de unelte pentru controlul versiunilor foloseau/versionau cate un singur fisier si nu aveau
o corespundere intre diferite fisiere din repository. Acestea nu aveau suport pentru retea.

◦ Exemple de astfel de unelte:

• Source Code Control System (SCCS)
• Revision Control System (RCS)
A DOUA GENERAȚIE
( CENTRALIZATE )
A doua generație (centralizate)
◦ A doua generatie de unelte pentru controlul versiunilor folosesc/versioneaza mai multe fisiere si aveau o
corespundere directa intre ele. Acestea erau centralizate.
◦ Exemple de astfel de unelte:
Concurrent Versions System (CVS)
Subversion (SVN)
TFS
Perforce
SVK
VSS
In momentul de fata cel mai popular sistem de control al versiunilor este Subversion sau SVN, care este
considerat un SCV centralizat.
Principiul de baza al sistemelor centralizate se bazeaza pe relatia client-server. Un depozit (repository) este
situat intr-un singur loc iar mai multi clienti au acces la el. Aceasta organizare este similara cu protocolul
FTP (File Transfer Protocol) in care exista un client FTP care se conecteaza la un server FTP.
Toate modificarile utilizatorilor si toate informatiile legate de aceste modificari (utilizator, data, revizie)
sunt transmise si preluate de la un depozit (repository) central.
Principalele beneficii ale lui Subversion
◦ Este usor de inteles
◦ Exista un control mai riguros al utilizatorilor si al accesului avand in vedere ca schimbul de informatii se
face cu o sursa centrala
◦ Exista mai multi clienti GUI si mai multe integrari cu IDE (Integrated Development Environment)
datorita faptului ca acesta este de mai mult timp pe piata
◦ Este usor de inceput munca cu el
Principalele dezavantaje ale sistemului Subversion

◦ Dependenta de accesul la server

◦ Mententanta si backup-urile serverului
◦ Poate fi mai greoi datorita necesitatii de comunicare cu serverul
◦ Tool-urile de branching si merging sunt greu de folosit
A TREIA GENERAȚIE
(DISTRIBUITE)
A treia generație (distribuite)
◦ A treia generatie de unelte pentru controlul versiunilor folosesc/versioneaza mai multe fisiere si aveau o
corespundere directa intre ele, dar sunt descentralizate.
◦ Exemple de astfel de unelte:
Git
BitKeeper (BK)
Bazaar
Sistemele de control al versiunilor distribuite sunt o optiune mai noua. In cadrul acestora fiecare utilizator
are propria copie a intregului repository, nu doar fisiere, ci intregul jurnal.
Aceasta abordare foloseste modelul peer-to-peer spre deosebire de modelul client-server folosit de
sistemele centralizate.
In acest caz, sincronizarea dintre repository-uri este realizata prin schimbul de changeset-uri sau patch-uri
dintre statii.
Doua dintre cele mai folosite SCV-uri de acest fel sunt Git si Mercurial.
Principalele beneficii ale sistemelor Git si
Mercurial sunt
◦ O urmarire a schimbarilor mai avansata si mai detaliata, lucru care duce la mai putine conflicte
◦ Lipsa necesitatii unui server – toate operatiile cu exceptia schimbului de informatii intre repository-uri se
realizeaza local
◦ Operatiile de branching si merging sunt mai sigure, si prin urmare folosite mai des
◦ Rapiditate mai mare a operatiilor datorita lipsei necesitatii comunicarii cu serverul
Principalele dezavantaje ale sistemelor Git si
Mercurial
◦ Modelul distribuit este mai greu de inteles
◦ Nu exista asa de multi clienti GUI datorita faptului ca aceste sisteme sunt mai noi
◦ Reviziile nu sunt numere incrementale, lucru ce le face mai greu de referentiat
◦ Riscul aparitiei de greseli este mare daca modelul nu este familiar
Terminologia specifică SCV
Autor : Carp Alexandra
Catedra ” Informatică I ”
Prin terminologie specifică se subînțelege
totalitatea termenilor utilizați în cadrul lucrului cu
sistemele de control alversiunilor.
În cele ce rmează, vom da definiția concretă
pentru cei mai des utilizați termeni.
 Repository

• „Depozitul“ în care sunt păstrate fișierele curente și versiunile

anterioare. Deseori acest depozit este o bază de date găzduită pe un
server.
• Repository-ul este locul unde tot lucrul dezvoltatorilor este stocat. El
tine jurnalul arborelui, tuturor fisierelor utilizatorilor, precum si
directoarelor in care aceste fisiere se afla. Pe langa acestea repository-
ul stocheaza jurnalul tuturor modificarilor
 Working copy

• Copie a fișierelor din repository pe calculatorul de lucru al unui

dezvoltator (de unde și numele). Acestea sînt fișierele pe care lucrează
un dezvoltator în mod obișnuit.
• Varianta locala, obtinuta de la server, pe care se fac modificarile
 Check - out

• Operația de creare a unei copii de lucru luate din repository.

• Aducerea pe masina locala a versiunii de pe server, sub forma unei
working copy
• Operatie de checkout este invocata atunci cand este necesara creearea
unei noi copii de lucru pentru un repository care exista deja. O copie de
lucru este o copie integrala a repository-ului si reprezinta locul unde
dezvoltatorul de software va face modificari. Repository-ul este
impartit de mai multi dezvoltatori insa modificarile nu se fac direct
asupra acestuia, ci fiecare face modificarile asupra copiei de lucru.
 Update

• Introducerea în copia de lucru a schimbărilor făcute de alte persoane

(colegi la același proiect) la repository.
• Operatia de update actualizeaza repository-ul aplicand modificarile de
pe acesta si combinandu-le cu alte modificari realizate pe copia de
lucru daca este cazul.
 Commit sau check-in

• Cerere de publicare pe server a modificarilor facute asupra working

copy.
• Operația de introducere în repository a schimbărilor din copia de lucru
• Aplica repository-ului modificarile de pe copia de lucru, creand un nou
changeset (set de schimbari)
• Aceasta este o operatie care modifica propriu-zis repository-ul. Alte
operatii modifica copia de lucru si adauga operatii setului de schimbari
in asteptare (pending changeset), un loc unde operatiile asteapta
operatia de commit. Operatia de commit foloseste setul de schimbari in
asteptare pentru a creea o noua versiune a arborelului din repository.
• Un aspect important al acestei operatii este ca ea se realizeaza in mod
atomic, adica indiferent de numarul de schimbari din setul de
schimbari in asteptare , ori se vor realizeaza toate aceste operatii daca
nu apare nicio eroare ori nu se realizeaza nicuna in cazul in care una
sau mai multe modificari nu sunt in regula.
 Revision

• Versiunea unui document

• O eticheta numerica care identifica versiunea unui fisier.
 Import

• Popularea initiala a unui repository cu un proiect de pe masina locala

 Conflict

• apare cand 2 utilizatori vor sa actualizeze acelasi document, dar

mecanismul nu este capabil sa imbine cele 2 variante. In acest caz, se
apeleaza la: Resolve
 Resolve

• Gestioneaza conflicte aparute in urma operatiei merge.

• Actiune pe care utilizatorul o executa pentru a inlatura un conflict (de
exemplu, in cazul de mai sus, acceptarea variantei celuilalt utilizator in
defavoarea propriei variante)
• In unele cazuri operatia de merge necesita interventia unei persoane. In
general aceasta realizeaza toate modificarile care sunt vazute ca sigure,
in caz contrar aceste modificari sunt considerate conflicte. Spre
exemplu daca un fisier a fost modificat pe un anumit branch si pe un
altul a fost sters. Intr-o astfel de situatie persoanele implicate in
dezvoltarea pe acele ramuri trebuie sa cada de comun acord si sa
rezolve conflictul.
 Trunk

• principala directie de dezvoltare a proiectului (ca insiruire de

revisions), in opozitie cu branches
 Branches

• Ramuri secundare de evolutie a proiectului (de exemplu, in care se

testeaza feature-uri noi) .
• Bifurcarea unui set de fișiere în două căi de dezvoltare distincte.
• Operatia de branch este folosita atunci cand dezvoltarea unui anumit
produs are mai multe ramuri. Spre exemplu daca avem un produs care
sa afla la versiunea 1.0, putem crea un branch pe care sa se inceapa
dezvoltarea versiunii 2.0 si altul pe care sa se faca repararea de bug-uri
a primei versiuni.
 Tag

• O „etichetă“ aplicată fișierelor din repository la un anumit moment

important din "viața" programului, de exemplu la lansarea unui produs
• Asociaza un nume cu semnificatie fiecarei versiuni specifice din
repository.
• Un tag este o combinatie de de litere, cifre, spatii mai putin virgula si
punct
 Merge / integrare

• Unirea a două versiuni diferite ale unui aceluiași fișier într-o singură
versiune
• Aplica schimbari de pe o ramura pe alta.
• In mod uzual dupa ce s-a facut impartirea pe ramuri a muncii se
doreste o convergenta a acestora, cel putin partiala. Tinand cont de
exemplul anterior, este de dorit ca bug-urile reparate din prima
versiune sa fie reparata si in cea de-a doua versiune, acest lucru s-ar
putea face manual, acum acele bug-uri fiind cunoscute, insa merge
ofera posibilitatea automatizarii acestei operatii.
Thank you!