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

May 19th, 2011

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!

Diferenta dintre software la comanda si produs software

April 5th, 2011

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.

Cateva abordari metodologice in dezvoltarea software

April 4th, 2011

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.

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:

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  incremental:

Acest model a fost dezvoltat pentru a contracare aparitia tarzie a unui executabil din modelul Waterfall.  El reprezinta o evolutie a modelului Waterfall. Cu acest model, proiectul este livrat incremental, in functie de prioritatea incrementului. Incrementele ar trebui sa aiba dimensiuni reduse, astfel incat sa existe un timp de la cateva saptamani la maxim doua luni intre lansari.

Avantaje ale modelului incremental:

-       Prioritatile cele mai ridicate sunt livrate primele

-       Se efectueaza o livrare la o data la cateva saptamani

-       Feedback-ul obtinut din incrementele anterioare ofera specificatiile pentru incrementele urmatoare

-       Riscul scazut de esec total al proiectului

-       Incrementele cu prioritate mai mare tind sa aiba parte de cea mai multa testare

Dezavantaje ale modelului incremental:

-       Se poate sa fie necesara crearea de solutii temporare pentru a putea livra la timp un increment.

-       O mare parte a codului poate fi inlaturata

-       Planificarea devine dificila

Acest model este recomandat pentru proiectele care evolueaza in timp.

Modelul Spirala:

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 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:

Optimizarea resurselor in software

April 1st, 2011

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

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.

3.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.

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”.

Despre proiectarea interfetelor

March 31st, 2011

Cand vine vorba de dezvoltare software, partea cea mai dificila, si cea mai consumatoare de timp este proiectarea si programarea interfetei cu utilizatorul(UI). Potrivit unor studii recente, programarea interfetei utilizator reprezinta undeva intre 30 si 90% din totalul liniilor de cod scrise pentru un software.

Pare interesant. Si atunci, cum se face ca noi, programatorii, ne ferim de partea cea mai interesanta? Poate pentru ca simtitm ca, oarecum, asta nu e treaba noastra. Si, in mare parte, nu este. Designul interfetei utilizator este, dupa parerea mea, treaba tipei de la design, care oricum petrece toata ziua rearanjand patrate in Photoshop. Cu toate acestea, o parte din “meritul” unei interfete reusite o are si programatorul. Mai ales daca se vorbeste de partea functionala, atata timp cat se respecta un set de reguli interfata programata va fi placuta si utilizabila.

Prima si probabil, cea mai importanta regula a proiectarii unei interfete este consistenta. Consistenta reprezinta una dintre cele mai de baza asteptari ale utilizatorului final, iar lipsa consistentei rezulta doar in frustrare in randul utilizatorilor care vor da click ca nebunii peste tot incercand sa gaseasca butonul de Ok, de exemplu. Un astfel de soft nu poate decat sa ajunga o relicva de care isi va aduce aminte doar Wikipedia. Pana la urma, cine ar vrea sa foloseasca un soft in care nu poate sa efectueze nici cele mai de baza operatii?

A doua regula a proiectarii unei interfete reusite se refera la folosirea asa-numitelor „metafore” si „affordances”. O metafora reprezinta un mod de a crea, in mintea utilizatorului, o conexiune intre o actiune rezalizata in software si un obiect/actiune din lumea reala, pe care utilizatorul este mult mai probabil sa o recunoasca.

Un exemplu foarte bun de metafora este butonul de Zoom, care se gaseste in aproape orice software.  Daca butonul are si o iconita atasata, acea iconita va fi intotdeauna o lupa. Astfel, utilizatorul care doreste sa mareasca o anumita portiune dintr-o fotografie, de exemplu, nu va avea probleme in a folosi butonasul cu lupa, fara sa ii fie frica de modificarea dimensiunilor imaginii, deoarece stie ca lupa nu face asta in realitate. Un exemplu de „affordance” este coltul dreapta-jos al ferestrelor de Windows, care arata ca si cum ar fi facute special pentru aderenta, sugerand utilizatorului ca daca trage cu mouse-ul de el va redimensiona fereastra.

Probabil cea mai cunoscuta metafora, desi putini realizeaza asta, este chiar Desktop-ul din Windows. Organizat cu fisiere si dosare, desktop-ul „simuleaza” biroul unei persoane. Iar utilizatorilor li s-a parut cat se poate de normal sa mute fisierele si sa le organizeze in foldere, deoarece asta faceau si in realitate pe birourile lor.

Cu toate aceastea, o metafora prost aleasa poate crea atat confuzie, cat si frustrare.  Ce s-ar intampla daca butonul de Zoom mentionat mai devreme ar mari efectiv dimensiunea imaginii? Sau daca butonul de selectare dintr-un program de editare de imagini ar actiona pe post de buton de decupare? Ne alegem cu un utilizator confuz care, cel mai probabil, nu isi va da seama ce a facut, si, mai ales, cum sa repare greseala(in cazul de fata un simplu Ctrl-Z este de ajuns, insa in alte cazuri aceasta optiune poate sa nu fie disponibila). Sansele sunt ca utilizatorul sa paraseasca exasperat aplicatia, si sa nu o mai foloseasca niciodata, pe motiv ca „nu merge, are buguri”.

Ceea ce ne aduce la ultimul aspect al discutiei, aspect care e strans legat de primele doua: interfata unui software trebuie sa faca exact ce se asteapta utilizatorul sa faca. In exemplul de mai sus, in cele doua situatii nu se poate vorbi de bug-uri, ci de functionalitati pe care le are orice program decent de editare de imagini(mai putin Paint), doar ca metaforele alese pentru acele functionalitati erau total gresite. Daca metaforele ar fi fost alese astfel incat sa faca ceea ce utilizatorul se asteapta sa faca, tanti Lili, care are 80 de ani si nu isi recunoaste nepotii in poze decat daca fata lor apare pe jumatate de ecran, ar fi fost mai fericita. La fel si Mihai, care ar fi gasit butonul de Crop prin care si-ar fi putut elimina sotia din pozele de vacanta pe care i le va trimite secretarei. Un alt exemplu(din realitate) este comportamentul ferestrelor pe Windows vs. Mac. Pe Windows, clickul pe coltul din dreapta jos al ferestrei va redimensiona fereastra, in timp ce pe Mac acelasi click va muta fereasta. Acesta este un exemplu de comportament diferit, care, desi nu este gresit, va parea neintuitiv unui utilizator ce a fost obisnuit cu un sistem de operare si incearca sa treaca la unul nou.

Cand vine vorba de proiectarea unei interfete, este foarte bine sa ne imaginam ce fel de utilizatori o vor folosi, si sa incercam sa empatizam cu ei. Da, poate eu stiu sa scriu ls –la | grep fisier.doc pentru a gasi un fisier intr-un folder suprapopulat, dar sunt foarte sigur ca secretara sefului nu stie. Ea prefera casuta de search. Treaba interfetei e sa simplifice lucrurile fata de vechea linie de comanda, si acest lucru este util chiar si utilizatorilor avansati.

In concluzie, simplu, intuitiv si consistent. Utilizatorii fericiti va vor multumi pentru asta!

Stabilirea precisa a cerintelor clientului

January 27th, 2011

Primul pas logic în dezvoltarea unui program este stabilirea precisa a cerintelor clientului (ceea ce clientul vrea ca programul sa faca). Partea ce mai importanta a acestui proces o reprezinta comunicarea dintre client si echipa de dezvoltare.

Când un inginer de programe lucreaza la stabilirea cerintelor, el este numit inginer de cerinte, analist de sistem sau analist. Dezvoltarea unui program începe de obicei cu o idee a clientului despre un nou sistem sau pentru îmbunatirea unui sistem existent. Clientul angajeaza un analist cu care va lucra împreuna pentru specificarea mai exacta a cerintelor. Ideea initiala a clientului poate fi vaga si prost definita, dupa cum poate fi clara si bine definita.

Stabilirea cerintelor este probabil cea mai importanta activitate în dezvoltarea produselor program. Daca un client nu stie sau nu poate sa stabileasca în urma unei discutii cu echipa de dezvoltare în mod exact ce vrea ca produsul sa faca, este inutil sa angajeze o echipa care sa programeze. O echipa de programatori poate sa scrie cel mai estetic program din punct de vedere al tehnicilor de programare folosite, dar daca nimeni nu va dori sa-l foloseasca, proiectul va fi un esec.

Multe programe nu se potrivesc cu cerintele clientului nu din motive de implementare defectuoasa, ci din cauza ca cerintele nu au fost specificate corect de la început. Programatorii nu pot si nu au cum sa cunoasca necesitatile clientilor, mai ales daca nu cunosc domeniul pentru care o anumita aplicatie este scrisa. Este responsabilitatea clientului de a veni cu cereri exacte si pertinente. Este obligatia inginerului de cerinte de a discuta cu clientul pentru a clarifica cerinrele si a ajuta clientul sa-si fixeze prioritatile.

Sistem de management al calitatii si al securitatii informatiei pentru paginile web, portalurile sau aplicatii web dezvoltate de Liga Web Design

January 18th, 2011

Incepand cu data de 14 ianuarie 2011 , Liga Software , compania de care apartine Liga WEB DESIGN a finalizat cu succes auditul de certificare a sistemului de management al calitatii, sistemului de management de mediu si sistemului de management al securitatii informatiei conform cerintelor

  • ISO 9001:2008
  • ISO 14001:2004
  • ISO 27001: 2005

pentru domeniul de activitate:

Dezvoltarea de solutii informatice integrate (hardware si software), pagini de web si consultanta IT.

Multumim pe aceasta cale si firmei auditoare ROS Systema, reprezentanta in Romania a  URS UK Ltd.

Incepand din 2011, lucrand la standarde internationale, nivelul de securitate si calitate a solutiilor noastre va creste considerabil , clientii LIGA Software avand numai de castigat.

Estimarea costului unui proiect software (Stabilirea pretului unui soft)

July 7th, 2010

Tinand cont de faptul c? un produs software este unic, experienta unor proiecte anterioare trebuie utilizata cu precautie. Plecand de la specificatii noi, alte platforme hardware si software, proiectarea unui soft poate genera costuri noi.

Astfel trebuie luate in considerare trei valori pentru costurile unui soft:

  • valoarea cea mai probabila
  • limita maxima
  • limita minima

Aceste valori reflecta factorul de incertitudine in ceea ce priveste estimarea costului unui proiect software.

In general pentru a stabili costurile cat mai exact pentru dezvoltarea unui proiect software este nevoie de :

  • Identificarea, stabilirea prioritatilor si justificarea resurselor necesare.
  • Negocierea bugetului adecvat si stabilirea echipei proiectului.
  • Optimizarea costului, productivitatii, calitatii si functionalitatii.
  • Nevoia de cuantificare a impactului riscului.
  • Stabilirea impactului schimbarilor.
  • Modificarea bugetelor in functie de aparitia unor evenimente neprevazute (specificatii noi)

Software “on-demand”- avantajul si dezavantajul serviciilor online

June 5th, 2010

In scurt timp vom lansa un astfel de serviciu online (o struto-camila de fapt, pentru ca ne-am lovit de reticenta celor care vor folosi acest software vizavi de a furniza anumite date).

Firmele din Romania inca nu cunosc foarte bine acest tip de servicii online si benefiile pe care le pot avea ele.

In consecinta o sa enumar cateva din avantajele si dezavantajele unui soft on-demand:

Avantaje servicii online:

  • costuri reduse privind infrastructura (nu este nevoie de un server, de retea interna) doar internet disponibil si un browser
  • costuri reduse privind upgrade-urile (nu este nevoie de deplasari)
  • costuri reduse privind mentenanta software-ului si backup-ul de date (este un serviciu inclus in abonament)
  • costuri zero privind instalarea software-ului sau intretinerea serverului.
  • update-uri gratis din partea funizorului de software

Dezavantaje…

  • posibilitatea unor upgrade-uri personalizate (software-ul este folosit de mai multe firme)
  • costuri pentru conectarea la internet (in ziua de astazi internetul este vital pentru orice companie, dar mai sunt si firme care prefera sa nu iaba internet pe toate statiile de lucru)