Esti programator PHP? Vino in echipa noastra!

Programator PHP

CANDIDATUL IDEAL

  • Cunostinte foarte bune de  PHP;
  • Relationarea facila cu bazele de date (ex: MySQL);
  • Cunostinte solide HTML si CSS;
  • Cunostiinte Javascript si framework-uri (ex: jQuery);
  • Capacitate de a lucra independent dar si in echipa;
  • AVANTAJ: Relationare anterioara cu modul de lucru pe deadline-uri si prezentarea unor proiecte

 

RESPONSABILITATI

          In functie de nivelul de cunostinte vom dezvolta impreuna site-uri, vom face aplicatii, vom contribui la procese de mentenanta si vom face optimizari pentru clienti/parteneri din tara dar si din strainatate.

          Experienta intr-o alta firma nu este necesara, dar bagajul mediu de cunostinte PHP este obligatoriu.

 

BENEFICII

  • Mediu de lucru placut, intr-o echipa dinamica
  • Pachet salarial atractiv
  • Proiecte diversificate
  • Noi provocari, oferind posibilitatea de dezvoltare pe plan profesional

 

DESCRIEREA COMPANIEI

        Suntem o firma dezvoltatoare de software si web design. Incercam sa oferim clientilor nostrii cele mai bune solutii, la cele mai bune preturi si acordam o importanta sporita serviciilor prestate catre client bazandu-ne pe calitate si incredere.

 

In cazul in care sunteti selectat se va sustine un test PHP inainte de interviu. Ne puteti trimite cv-ul si direct pe adresa de email hr@ligasoftware.ro.

 

Mai mult »

Liga Software participa la proiectul ’’De la teorie la practica prin intreprinderea simulata”

  

     Din toamna anului 2011, vor exista 2 companii ce vor purta numele Liga Software. Una dintre acestea este cea pe a carei blog va aflati in momentul de fata, cealalt? este cea virtual?, simulat?: I.S. Liga Software S.R.L.

     Adica?

     Liga Software va participa la proiectul ’’De la teorie la practic? prin întreprinderea simulat?” al Universitatii Politehnice din Bucuresti, care isi propune sa invete studentii cum sa managerieze o afacere, ce pericole exista si cum sa faca fata provocarilor pe care le intalneste orice companie “on the road to succes”.

     Intreprinderea virtuala vine în întâmpinarea nevoilor primei, celei reale. Se va confrunta ?i ea cu dificult??i, probleme, va avea o competi?ie, îns? toate acestea nu vor presupune niciun risc real, dar vom colabora cu studentii pentru a le crea o impresie cat mai veridica despre mediul de afaceri din Romania.

     Daca esti student la UPB si vrei sa afli mai multe despre Liga Software si despre proiect, vino luni, 23 mai , orele 9:30-14:00, la Universitatea ’’POLITEHNICA’’ din Bucure?ti, Splaiul Independen?ei nr. 313, Sector 6, Cl?dire Rectorat, Intrarea principal?, Etajul 2, Sala Senatului si participa alaturi de noi la evenimentul de networking dedicat proiectului, in care ne vom prezenta compania, domeniul de activitate si oamenii cheie ca sa poti sa te integrezi mai usor in versiunea simulata a companiei noastre.

     Noi vom fi acolo! Si tu? Ne vedem luni!

Mai mult »

Diferenta dintre software la comanda si produs software

  

     Dezvoltarea software se poate face, in linii mari, in doua directii, din punct de vedere al marimii publicului tinta:

     - produs software

     - software la comanda

     Un produs software ia nastere de cele mai multe ori datorita unei nevoi generale de informatizare, identificata de o companie de software care trece la proiectarea si dezvoltarea unui produs care sa satisfaca aceste nevoi. Plecand de la aceste nevoi generale, se vor trata problemele cat mai general, permitand abordarea unui public tinta cat mai larg. Astfel se ajunge la un produs software care are potentialul de a rezolva toate problemele, dar majoritatea solutiilor presupunand existenta personalului specializat (ideal cel care a construit produsul) si training pentru personalul existent.

     Un software facut la comanda porneste de la nevoile specifice ale unui client, care se adreseaza unei companii de dezvoltare software expunandu-si problemele si cautand solutii. Dupa identificarea problemelor specifice, se va trece la construirea de solutii, care vor fi mai aproape de optim datorita cunoasterii specificitatii problemelor de rezolvat. In acest caz dispare tendinta de generalizare a problemelor, datorita cunoasterii lor in amanunt si a faptului ca publicul tinta este bine definit si nu este nevoie de extinderea lui. In final se ajunge la un produs software care satisface intocmai nevoile clientului si care nu necesita o pregatire deosebita pentru folosire.

     Din punct de vedere al costului, software-ul facut la comanda va avea un cost mai ridicat, destinatarul fiind unul singur, iar volumul de munca fiind comparabil cu cel pentru dezvoltarea unui produs software general. Un produs software ar avea un cost mai scazut datorita faptului ca se imparte la un numar de cumparatori.

     Din punct de vedere al timpului, acesta poate fi privit din perspectiva utilizatorului si din punctul de vedere al dezvoltatorului. Din punct de vedere al dezvoltatorului, necesarul de timp este comparabil, ceva mai mare pentru software la comanda. In schimb, pentru utilizator perceptia este total diferita, deoarece pentru software la comanda dezvoltarea se incepe in momentul in care se primesc cerintele de la client, spre deosebire de un produs software existent, care poate fi livrat intr-un timp foarte scurt, dezvoltarea lui facandu-se de obicei anterior momentului achizitiei de catre client.

     In concluzie, solutiile software la comanda sunt preferabile, insa daca ele nu se incadreaza in buget, se poate opta pentru un produs software existent, care este suficient in multe cazuri.

Mai mult »

Optimizarea resurselor in software

  

software_developer.jpg      In ciuda denumirii, procesul de optimizare software produce rareori un produs (program) optimal. De obicei soft-ul  este optimizat pentru o anumita aplicabilitate sau pentru un anumit tip de client. Se incearca reducerea timpului de executie a unui task efectuat de catre program in detrimientul consumului de memorie. Din contra, in conditiile in care un sistem nu are memoria  foarte mare,  se poate alege in mod deliberat un algoritm care, desi ruleaza mai incet, utilizeaza mai putina memorie. De obicei nu exista cazuri de design  “one size fits all” care sa functioneze bine in orice conditii. De aceea eforturile sunt directionate catre optimizarea acelor aspecte ce sunt considerate deosebit de importante. Mai mult, este posibil ca procesul de optimizare sa fie foarte costisitor, deci nerentabil avand in vedere rezultatele (profiturile)  care se pot obtine in urma optimizarii produsului software; in acest caz, se realizeaza “optimizarea partiala” a solutiei software, tinandu-se cont de faptul ca cele mai semnificative imbunatatiri sunt rezultatul optimizarilor efectuate in fazele initiale ale proiectului.

 

     Tipuri de optimizare software

 

 

1. La nivel de design

 

software-development.jpg

     La un nivel superior, designul poate fi imbunatatit pentru a utiliza la maxim resursele disponibile. Implementarea unui astfel de design va beneficia de posibilitatea alegerii dintr-o gama de algoritmi eficienti, iar implementarea acestora va beneficia de cod de calitate. Arhitectura unui sistem  software afecteaza fundamental performanta acestuia.  Alegerea de algoritmi eficienti  afecteaza mai mult decat orice alt aspect al designului comportamentul ulterior al produsului, si de obicei este primul lucru asupra caruia se decide. In unele cazuri optimizarea se bazeaza pe algoritimi complecsi, pentru a efectua diverse compromisuri si a se folosi “cazuri speciale”. Totusi, un program puternic optimizat este susceptibil de a contine mai multe greseli si de a fi mai greu de inteles decat o versiune neoptimizata.

 

     2. La nivelul codului sursa

 

     Evitarea scrierii de cod de slaba calitate poate de asemenea imbunatati performantele, prin evitarea “incetinirilor”. Dincolo de acest pas, optimizarea are ca efect secundar scaderea posibilitatilor de mentenanta. In unele cazuri, dar nu in toate, optimizarea se realizeaza prin optimizarea la nivel de compilator.

 

     2. La nivelul assembler-ului

 

     La nivelul cel mai de jos, scrierea de cod direct in limbaj de asamlare, cod proiectat pentru o anumita componenta hardware, poate produce cel mai eficient si mai compact cod daca programatorul foloseste in mod intelligent instructiunile disponibile si cunoaste bine arhitectura masinii. Cele mai multe sisteme de operare pentru sisteme embedded au fost scrise in assembler tocmai din acest motiv. Cand eficienta si consumul de memorie nu reprezinta chestiuni de prima importanta, unele parti ale programului pot fi scrise in limbaj de nivel inalt.

 

     Totusi este din ce in ce mai dificil de a produce cod mai bun decat cel produs de compilatoarele moderne, si din ce in ce mai putine proiecte software sunt optimizate in acest mod. Cea mai mare parte a codului produs in prezent este scris in vederea rularii pe cat mai multe masini posibil. In consecinta, programatorii si compilatoarele nu folosesc intotdeauna cele mai eficiente intructiuni  disponibile pe procesoarele de ultima generatie. Codul scris in assembler pentru un anumit procesor  poate fi suboptimal pentru un alt tip de procesor. Compilatoarele Just in Time sau programele scrise in assembler  au capacitatea de a efectua optimizari  in timpul rularii (optimizari ce nu pot fi efectuate de compilatoarele statice ) prin ajustarea de parametri  in functie de input-uri sau de alti factori.

 

     Optimizarea software poate fi general  clasificata in urmatoarele subcategorii:  tehnici  independente  de platforma  si tehnici dependente de platforma.  In timp ce primele sunt eficiente pe orice platform, cele din urma se folosesc de proprietatile si caracteristicile specifice unei platform, ori se bazeazaparametri  ai unei anumite component (cum  ar fi, spre exemplu, procesorul). Producerea de versiuni diferite ale aceluiasi cod pentru procesoare diferite poate fi asadar necesara. Spre exemplu, in cazul optimizarii la nivel de compilator, tehnicile independente de platrforma sunt tehnici generale (reducerea de apeluri de functii, utilizarea unor rutine eficiente din punct de vedere al memoriei, reducerea numarului de conditii), ce au un effect similar asupra tuturor arhitecturilor. In general, acestea au ca efect reducerea  consumului de memorie in timpul rularii. Pe de alta parte, tehnicile dependente de platforma, precum planificarea instructiunilor, paralelismul instructiunilor, tehnici de optimizare cache, si altele, care pot fi diferite de la procesor la procesor.

 

     Compromisuri

 

     Optimizarea se axeaza in principal pe imbunatatirea a doar unuia (sau a doua) aspecte de performanta: timpul de executie, consumul de memorie, spatial pe disc, latimea de banda, energia consumata sau alte resurse. Aceasta necesita de obicei un compromis, unde un aspect este optimizat in detrimentul altor factori: de exemplu, marirea dimesiunii memoriei cache imbunatateste viteza de executie a programului, dar creste consumul de memorie. Un alt compromis des inatlnit este claritatea codului versus concizie. Sunt situatii in care un programator ce realizeaza optimizari trebuie sa se decida sa optimizeze un program pentru un anumit tip de operatii cu costul de a face alte operatii mai putin eficiente. Aceste compromisuri pot fi de natura non-tehnica, de xeemplu cand un competitor a publicat un benchmark ale carui rezultate trebuiesc depasite pentru ca firma proprie sa-si imbunatateasca imaginea (si deci vanzarile) facand in schimb ca alte componente sa ruleze suboptimal.

 

paintedWorld.jpg

     Consumatori critici de resurse

 

    Optimizarea  include si gasirea unui “bottleneck”, acelei parti de cod care este principalul consummator de resurse. Si in cazul optimizarii software principiul Pareto se dovedeste a fi adevarat- si anume ca 20% din cod este responsabil pentru 80% din rezultate. In industria software principiul Pareto poate fi aplicat prin simpla observatie ca 20% din resurse sunt utilizate pentru 20% din operatii. In ingineria software se pare ca o aproximare mai buna este urmatoarea: 90% din timpul de executie al unui program este utilizat pentru executarea a 10% din cod (in acest context se mai numeste si legea 90/10).

    In unele cazuri, suplimentarea memoriei poate imbunatati timpul de executie. De exemplu un program de “filtrare” care citeste linie cu linie dintr-un fisier text si afiseaza liniile ce indeplinesc criteriile de filtrare foloseste doar memorie pentru retinerea unei linii, dar are performante slabe. Performantele se imbunatatesc semnificativ daca se citeste intreg continutul fisierului deodata, dupa care se filtreaza rezultatul- dar creste de asemenea si necesarul de memorie. Folosirea memoriei cache are efecte similare.

 

     Optimizarea automata si manuala

 

     Optimizarea poate fi realizata in mod automat de catre compilatoare sau se face “manual”, de catre programator. De obicei, cea mai buna forma de optimizare este gasirea unui algoritm eficient. Optimizarea sistemului luat ca intreg nu este realizata automat (operatia este prea complexa) drept pentru care este realizata de catre programator. Cu toate ca produce castiguri in eficienta mai mult decat substantiale, acest tip de optimizare este mult mai scumpa decat optimizarea automata.

 

     Folosind un performance analyzer se pot identifica portiunile de cod care sunt consumatoare de resurse. Optimizarea unei parti neesentiale a codului va avea efecte foarte reduse asupra performantei globale.  In momentul in care bottleneck-ul este localizat, optimizarea se initiaza prin reproiectarea algoritmului folosit in program;  de obicei se poate realize un algoritm care sa resolve o problema locala de eficienta, determinand o performanta mai buna decat utilizarea unui algoritm generic. De exemplu, pentru sortarea unei liste de mari dimensiuni se foloseste un algoritm qiucksort, care este unul dintre cei mai rapizi algoritmi generici. In cazul in care se poate utiliza o caracteristica specifica (poate lista in cauza  este ordonata intr-un anumit fel)  se va folosi un algoritm “custom made”.

Mai mult »

Cateva abordari metodologice in dezvoltarea software

    

     Ati proceda la fel daca ati construi un site web de prezentare a unei firme si un program software pentru conducere a avioanelor? Bineinteles ca nu. Veti proceda diferit, intrucat si proiectele respective impun un efort de munca si un grad de risc diferit. In acest scop, va va fi de ajutor cunoasterea principalelor metodologii de lucru, astfel incat proiectul dumneavoastra sa se bucure de succes.

     O metodologie de lucru pentru un produs software reprezinta modul de structurare, planificare si control al procesului de dezvoltare.

     Pentru a intelege mai bine ce inseamna o metodologie de lucru, iata cativa termeni ce sunt utilizati frecvent in acest domeniu:

     - Metodologie (sau metoda) – o anumita colectie de principii si/sau practici

     - Familie de metodologii – un set de metode alternative care coexista

     - Framework – un schelet (pentru metode) care trebuie dezvoltat/personalizat inainte de utillizare

     - Model – o descriere (pentru metode) care trebuie implementata de o metoda, familie sau framework.

     Pentru cei care sunt mai familiarizati cu limbajul software!  O metodologie este asemanatoare unei clase ce poate fi instantiata pentru un anumit proiec. O familie de metodologii este asemanator cu un namespace de clase diferite dar comparabile. Un framework se aseamana cu o clasa abstracta care trebuie mai intai mostenita si extinsa. Un model este asemanator unei interfete ce reprezinta doar o descriere a “ceva” ce trebuie implementat de una sau mai multe clase.

     In continuare urmeaza descrierea unora dintre cele mai importante metodologii pentru crearea de software.

 

     Modelul Waterfall sau modelul Cascada:

     Modelul Waterfall reprezinta un proces de implementare secvential, utilizat deseori in procesul de dezvoltare software. Are mai multe faze: Cerinte, Proiectare, Implementare, Integare si  Mentinere.

 

Modelul-Waterfall-sau-modelul-Cascada.png

 

     In faza de Cerinte sunt stabilite toate cerintele posibile ale sistemului ce se doreste implementat. Cerintele sunt culese de la utilizator prin consultarea acestuia, dupa care este analizata posibilitatea de incorporare a lor in produsul dorit. La final este redactat un document cu aceste cerinte, ce va servi ca ghid pentru fazele urmatoare ale proiectului.

     In etapa de Proiectare sunt studiate cerintele de la prima etapa si este elaborat design-ul proiectului. Aceasta faza ajuta in specificarea cerintelor de sistem si hardware, precum si in definirea arhitecturii de ansamblu. Rezultatul acestei etape se concretizeaza in redactarea unui document ce cuprinde specificatiile de proiectare.

     In continuare, se trece la etapa de Implementare. Dupa terminarea proiectarii, munca este divizata in module si incepe adevarata implementare a codului. Sistemul este dezvoltat mai intai in mici programe, numite “unitati”, care vor fi apoi integrate in faza urmatoare. Fiecare unitate este dezvoltata si testata, pentru a ne asigura ca respecta specificatiile.

     In faza de Integrare, toate unitatile dezvolate in faza anterioara sunt integrate si testate pentru a verifica daca se coordoneaza, iar sistemul, privit ca un intreg, se comporta conform cu specificatiile. Dupa testarea cu succes, produsul este livrat la beneficiar.

     Ultima faza a modelului Waterfall este teoretic o faza ce nu are un termen de finalizare. In general, problemele unui software apar dupa ce el incepe sa fie utilizat, astfel incat problemele vor fi rezolvate dupa lansarea produsului.

 

     Printre avantajele acestui tip de model, se pot mentiona:

     -       Documentatia si proiectarea structurii reprezinta un avantaj atunci cand apar noi membrii in echipa
     -       Este un model usor de utilizat si simplu
     -       Fiecare faza are un rezultat asteptat, datorat rigiditatii modelului
     -       Etapele sunt implementate individual, pe rand.
     -       Este recomandat pentru proiectele mici, in care cerintele sunt foarte bine intelese.

     Printre dezavantajele acestui tip de model, se numara:

     -       Culegerea specificatiilor in etapa de Cerinte este foarte importanta pentru a proiecta si implementa produsul corespunzator. Cu toate acestea, cerintele pot fi adaugate si dupa finalul acestei etape, fapt ce influenteaza in mod negativ dezvoltarea.
     -       Problemele din cadrul unei etape nu sunt niciodata rezolvate complet in cadrul aceleiasi etape
     -       Partitionarea in etape a proiectului nu este flexibila
     -       Intrucat clientul poate adauga noi cerinte, acestea nu pot fi implementate in aceeasi editie a produsului. Prin urmare, va fi nevoie de costuri suplimentare pentru implementarea cerintelor nou adaugate.
     -       Este dificil sa se faca o estimare corecta a timpului si costului alocat pentru fiecare etapa.
     -       Un produs functional finit este obtinut tarziu, comparativ cu momentul de inceput al proiectului.

 

    Modelul Prototip:

 

Modelul-Prototip4.png

 

     Scopul modelului Prototip este de a contracara primele doua limitari ale modelului Waterfall, discutat mai sus. In loc de a stabili definitiv cerintele inainte de a putea incepe cu proiectarea si implementarea, este lansat un prototip pentru a intelege cerintele. Acesta este dezvoltat pe baza cerintelor cunoscute in prezent. Dezvoltarea prototipului contine fazele de proiectare, implementare si testare, dar acestea nu sunt foarte riguroase sau formale.

     Prin intermediul prototipului, clientul intelege mai bine modul in care lucreaza produsul, intrucat interactioneaza cu acesta pe parcursul intregului ciclu de dezvoltare.

     Acest model este preferat in cadrul sistemelor mari si complicate, pentru care este dificila intelegerea cerintelor de la inceput. In astfel de situatii, accesul clientului la prototip furnizeaza un aport substantial in intelegerea si definirea specificatiilor.

 

     Avantajele acestui tip de model sunt:

     -       Utilizatorii sunt implicati direct in dezvoltare
     -       Intampina tendinta utilizatorilor de a-si modifica cerintele, pe parcursul ciclului de implementare
     -       Intrucat este lansat un model functional al sistemului, utilizatorii pot intelege mai bine modul de functionare
     -       Erorile pot fi detectate mult mai devreme
     -       Feedback-ul utilizatorului este mult mai rapid, fapt ce duce la obtinerea de solutii mai bune
     -       Timpul si costurile reduse

     Printre dezavantaje, merita mentionate:

     -       Acest model poate creste complexitatea sistemului, sau acesta se poate extinde dincolo de limitele stabilite initial
     -       Analiza insuficienta a proiectului ca un intreg
     -       Programatorii pot deveni atasati de un prototip in a carui dezvoltare au investit mult timp si vor tinde sa transforme prototipul intr-un produs final chiar si atunci cand arhitectura de baza nu este cea potrivita
     -       Consumul excesiv de timp utilizat pentru implementarea unui prototip.

 

    Modelul Spirala:

 

Modelul-Spirala.png

 

     Pasii unei iteratii din modelul Spirala pot fi generalizati astfel:

     1.    Cerintele sistemului sunt definite cat de detaliat se poate. Acest lucru presupune de obicei intervievarea unui numar de utilizatori reprezentand utilizatorii interni si externi ai sistemului precum si alte aspecte.

     2.    Este creat un design preliminar pentru noul sistem. Aceasta faza este cea mai importanta a modelului.  In aceasta etapa, toate alternativele posibile (si disponibile), care pot ajuta in dezvoltarea unui proiect eficient din punct de vedere a costului sunt analizate si sunt decise strategiile de abordare.

     3.    Este construit un prim prototip al noului sistem din design-ul preliminar. Acesta este de obicei un sistem la scara redusa  si reprezinta o aproximare a caracteristicilor produsului final.

     4.    Un al doilea prototip este dezvoltat, asfel:

          a.    Evaluarea primului prototip in termeni de puncte forte, puncte slabe si riscuri

          b.    Definirea cerintelor pentru al doilea prototip

          c.     Planificarea si proiectarea celui de al doilea prototip

          d.    Construirea si testarea celui de al doilea prototip

 

     Avantaje:

     -       Presupune o atitudine pro-activa  asupra riscurilor, cu o presupunere explicita a riscurilor si  a rezolvarii lor
     -       Foarte flexibil

     Dezavantaje:

     -       Aproape imposibil de estimat de la inceput timpul si costurile necesare.

 

    Metodele Agile:

 

     Grupul de metode Agile este bazat pe dezvoltarea iterativa si incrementala acolo unde specificatiile si solutiile provin din colaborarea intre echipe organizate individual, dar care au acelasi scop comun.

     Aceste metode au la baza 12 principii, sintetizate in asa numitul “Agile Manifesto”, emis in februarie 2001:

     1.       Satisfacerea clientilor, prin livrarea rapida de software utilizabil

     2.       Intampinarea modificarii specificatiilor, chiar si tarziu in implementare

     3.       Software-ul utilizabil este livrat frecvent (la nivel de saptamani)

     4.       Software-ul utilizabil reprezinta principala masura a progresului

     5.       Dezvoltare sustinuta, capabila sa pastreze un pas constant

     6.       Cooperare apropiata intre dezvoltatori si clienti

     7.       Conversatia fata-in-fata este cel mai bun mod de comunicare

     8.       Proiectele sunt construite de indivizi motivati, credibili

     9.       Simplitate

     10.   Echipe organizate individual

     11.   Adaptare la circumstante schimbatoare.

     12.   Atentia constanta pentru excelenta tehnica si design bun.

     Printre cele mai importante metode Agile, enumeram SCRUM si XP (Extreme Programming).

 

 

    SCRUM:

 

Scrum.png

 

     SCRUM este un schelet ce contine un set de practici si diferite roluri. Principalele roluri din SCRUM sunt:

     -          “Scrum Master” – este cel care mentine procesele

     -          “Detinatorul produsului” – cel care reprezinta investitorii si afacerea

     -          “Echipa” – un grup de aproximativ 7 oameni ce fac analiza, proiectarea si implementarea

     In timpul fiecarui “sprint” (de obicei cu o durata de 2-4 sapatamani), echipa creaza un increment ce poate fi livrat. Setul de caracteristici ce intra intr-un “sprint” provin din “backlog”-ul proiectului, care reprezinta un set prioritizat de cerinte de nivel inalt ce trebuiesc realizate.  In timpul unei sedinte de planificare a sprint-ului, se stabilesc cerintele ce vor intra in sprint. Cerintele sunt “inghetate” in timpul unui sprint. Sprint-ul trebuie sa se incheie la timp. Daca cerintele nu sunt implementate complet, ele se intorc in backlog-ul proiectului. Dupa terminarea unui sprint, echipa trebuie sa demonstreze functionarea software-ului.

     Avantaje:

     -          Economisirea de timp si bani

     -          Rapiditatea implementarii si usurinta de a corecta eventualele erori

     -          Vizibilitate a implementarii proiectului

     -          Feedback continuu de la client

     -          Usurinta de a face fata schimbarilor

     -          Intalnirile zilnice duc la o apreciere mai buna a productivitatii individuale

     -          Problemele sunt identificate in fazele de inceput, deci pot fi rezolvate mai rapid

     -          Este mai usor sa se livreze un produs de calitate in timpul planificat

     Dezavantaje:

     -          Daca nu exista o data fixa de finalizare, actionarii proiectului vor tinde sa ceara din ce in ce mai multe functionalitati

     -          Daca membrii echipei nu sunt constiinciosi, proiectul fie va esua, fie nu se va finaliza niciodata

     -          Daca o cerinta nu este bine definita, costurile proiectului si timpul alocat nu pot fi apreciate corect

     -          Este recomandat pentru proiecte mici si rapide, intrucat se pliaza mai bine pe echipe mici de oameni

     -          Daca unul din membrii echipei pleaca in timpul implementarii, acest lucru poate avea efect invers asupra dezvoltarii proiectului.

 

    EXTREME PROGRAMMING:

 

     Prin Extreme Programming se incearca reducerea costurilor impuse de modificarea cerintelor prin efectuarea de mai multe cicluri de implementare mai scurte in locul unuia lung. In aceasta metodologie, schimbarile sunt un aspect natural si ar trebui planificate in loc de a incerca stabilirea unui set fix si stabil de cerinte.

     Extreme Programmig, sau XP, descrie patru activitati de baza, care sunt realizate in timpul procesului de dezvoltare al software-ului:

     -          Scrierea codului – sustinatorii XP sunt de parere ca singurul produs cu adevarat important al procesului de dezvoltare este codul. Fara cod, nu exista un produs viabil.
     -          Testarea – abordarea XP este aceea ca, daca putina testare poate elimina putine erori, mai multa testare poate elimina mai multe erori.
     -          Ascultarea – programatorii trebuie sa asculte ce doresc clientii sa faca sistemul. Trebuie sa inteleaga aceste cerinte suficient de bine pentru a da feedback clientului cu privire la aspectele tehnice ce pot fi rezolvate sau nu.
     -          Proiectarea – se promoveaza crearea unei structuri logice a proiectului, pentru a evita un numar mare de dependente in proiect si pentru a usura implementarea eventualelor modificari.

     Avantaje:

     -          XP livreaza proiectari si software de calitate in timpul programat realist
     -          Un nivel ridicat de calitate prin testarea in intregime a tuturor aspectelor
     -          Incurajarea lucrului in echipa – programatorii lucreaza in perechi in care ambii au un singur monitor si o tastatura
     -          Nivel sporit de satisfacere a clientului, datorita modului in care sunt captate cerintele acestuia
     -          Design-ul este simplu – proiectarea nu se face pentru ceva viitor si pentru ceva prezent
     -          Test-case-uri usor de inteles
     -          Intregul proces de dezvoltare este vizibil si masurabil

     Dezavantaje:

     -          este greu de realizat Extreme Programming – este dificila strangerea unui numar de programatori care sa accepte aceasta practica si este nevoie de multa disciplina pentru ca toti sa duca la bun sfarsit un proiect cu aceasta abordare
     -          software-ul din ziua de astazi este foarte mare si complex, lucru ce face grea proiectarea incrementala abordata de XP
     -          XP pune accent pe refactorizarea in timpul procesului de implementare, fapt ce poate scadea din productivitatea altor aspecte
     -          Dezvoltare bazata pe cod, in loc sa fie bazata pe proiectare
     -          Lipsa documentatiei de proiectare

     Pentru a intelege mai bine impactul pe care il poate avea alegerea unei metodologii gresite de lucru pentru un proiect, precum si impactul deficientelor de comunicare, imaginea de mai jos surprinde toate aceste aspecte:

 

metodologii.png

 

Mai mult »