Dezvoltarea sistemelor soft: principii si activitati

DEZVOLTAREA SISTEMELOR SOFT: PRINCIPII SI ACTIVITATI

Cuprins:

1. Procese soft

Dezvoltarea sistemelor soft: principii si activitati

3. Modelarea proceselor si sistemelor soft

4. Limbajul unificat de modelare (UML)

5. Colectarea, analiza si specificarea cerintelor

6. Modelarea in analiza

7. Proiectarea: concepte si modele

8. Proiectarea arhitecturii si claselor: principii

9. Proiectarea arhitecturii, datelor si prelucrarilor

10. Proiectarea componentelor

11. Proiectarea interfetei cu utilizatorul

1 Testarea softului: etape si metode

13. Instalarea si intretinerea

14. Planificarea proiectelor soft

1. Problem solving si dezvoltarea de soft: asemanari si deosebiri

1.1. Problem solving

1. Problem solving in contextul ingineriei soft

1.3. Principii generale ale dezvoltarii de soft

Comunicarea: principii si sarcini generice

1. Principiile comunicarii

Sarcini generice ale comunicarii

3. Planificarea: principii si sarcini generice

3.1. Principiile planificarii

3. Proiect realist: intrebari

3.3. Sarcini generice ale planificarii

4. Modelarea in analiza: principii si sarcini generice

4.1. Principii de modelare in analiza

4. Sarcini generice ale analizei

5. Modelarea in proiectare: principii si sarcini generice

5.1. Principii de modelare in proiectare

5. Principiile modelarii agile

5.3. Sarcinile generice ale proiectarii

6. Constructia: principii si sarcini generice

6.1. Principii si concepte de codificare

6. Sarcinile generice ale codificarii

6.3. Testarea: terminologie

6.4. Testarea: fundamente

6.5. Principiile testarii

6.6. Sarcini generice ale testarii

7. Exploatarea: principii si sarcini generice

7.1. Principiile distribuirii/instalarii

7. Sarcini generice ale distribuirii/instalarii

1. Asemanari si deosebiri intre problem solving si dezvoltarea de soft

1.1. Problem solving (Polya, G., How to Solve It, Princeton University Press, 1945)

Pasii rezolvarii problemelor

1. Intelegerea problemei (comunicare si analiza)

Gandirea unei solutii (modelare si proiectare)

3. Rezolvarea efectiva (generare de cod)

4. Examinarea acuratetii rezultatului, proba (testarea si asigurarea calitatii), punerea in opera

1. Problem solving in contextul ingineriei soft

1. Intelegerea problemei (comunicare si analiza)

• cui, la ce foloseste rezolvarea problemei? (care sunt cei interesati, stakeholders?)
• care sunt necunoscutele problemei? (ce date, functii sau caracteristici de comportament sunt necesare pentru rezolvarea completa a problemei?)
• se poate descompune problema in probleme mai simple? (este posibil sa se identifice din problema initiala subprobleme de complexitate mai redusa care sa fie mai usor de reprezentat si rezolvat?)
• se pot folosi reprezentari grafice? (se pot crea diagrame pentru modelul de analiza?)

Gandirea unei solutii (modelare si proiectare)

• problema data seamana cu probleme intalnite anterior? (exista sabloane care sa se poata include intr-o solutie posibila? exista proiecte care implementeaza deja datele, functiile, caracteristicile de comportament necesare?)
• a fost rezolvata anterior o problema similara? (daca da, ce elemente ale solutiei acesteia se pot refolosi?)
• se pot defini subprobleme? (daca da, solutiile acestora sunt cunoscute?)
• solutia problemei se poate reprezenta in asa fel incat sa permita o implementare eficienta? (se poate crea un model de proiectare?)

3. Rezolvarea efectiva (generare de cod)

• solutia este conforma planului? (se poate reconstitui modelul de proiectare plecand de la codul sursa?)
• fiecare parte componenta a solutiei este (probabil) corecta? (proiectul si codul au fost revizuite? sau, mai bine: s-au efectuat demonstratii de corectitudine ale algoritmilor folositi?)

4. Examinarea acuratetii rezultatului, proba (testarea si asigurarea calitatii), folosirea

• este posibil sa se testeze separat fiecare componenta a solutiei? (s-a implementat o strategie rezonabila de testare?)
• solutia obtinuta produce rezultate in conformitate cu cerintele privitoare la date, functii, caracteristici sau comportament? (softul a fost validat in raport cu toate cerintele?)

1.3. Principii generale ale dezvoltarii de soft (Pressman)

The Reason It All Exists: Motivul existentei: sa fie de folos utilizatorilor

KISS (Keep It Simple, Stupid!): Proiectul trebuie sa fie cat mai simplu posibil, dar nu simplist

Maintain the Vision: Viziunea clara este esentiala pentru succesul unui proiect soft

What You Produce, Others Will Consume: La specificare, proiectare si implementare trebuie sa se tina intotdeauna cont ca altcineva (utilizatorii) trebuie sa inteleaga si sa foloseasca sistemul soft

Be Open to the Future: sistemul trebuie sa fie pregatit sa incorporeze schimbari, anticipate sau nu

Plan Ahead for Reuse: se reduce costul si se creste valoarea atat pentru componentele reutilizabile, cat si pentru sistemele in care acestea sunt incorporate.

Think! Gandeste inainte de a actiona.

Comunicarea: principii si sarcini generice

1. Principiile comunicarii

1. Invata sa asculti pe altii

Pregateste-te inainte de comunicarea cu ceilalti (intelegerea domeniului, problemei, vocabularului, agenda intalnirii)

3. Comunicare are nevoie de sprijin si coordonare

4. Comunicarea directa este cea mai buna

5. Ia notite si documenteaza deciziile luate

6. Colaborarea si consensul apar cand cunostintele colective ale membrilor echipei se combina pentru a descrie produsul sau functiile si caracteristicile sistemului

7. Pastreaza obiectul discutiilor, fara divagatii inutile

8. Daca este ceva neclar, deseneaza o imagine

9. (a) La acord cu partenerii, continua cu altceva

(b) La dezacord cu partenerii, continua cu altceva

(c) Daca o caracteristica sau functie nu este clara pe moment, continua cu altceva

10. Negocierea nu este nici concurs, nici joc. Cel mai bine este atunci cand ambele parti castiga.

Sarcini generice ale comunicarii

1. Identificarea clientului principal si a tuturor celor interesati (stakeholders)

Intalnirea cu clientul principal pentru a raspunde la intrebari 'generale' ce definesc

• Nevoile si elementele de valoare/importante ale organizatiei client sau domeniului problemei
• Caracteristicile si nevoile utilizatorilor finali
• Iesirile vizibile/tangibile/percepute cerute de utilizator
• Constrangerile, regulile din domeniul problemei

3. Scrierea unui document de o pagina cu enuntul domeniului proiectului, susceptibil la revizuire

4. Revizuirea enuntului cu toti cei interesati si modificarea lui dupa necesitati

5. Colaborarea cu clientul/utilizatorii pentru a defini

• Scenariile de utilizare percepute de utilizatori intr-un format standard
• Iesirile produse si intrarile
• Caracteristicile, functiile si comportamentul relevant
• Riscurile specifice domeniului problemei, definite de client

6. Elaborarea unei descrieri scrise (o multime de liste) a scenariilor, iesirilor/intrarilor, caracteristicilor/functiilor si riscurilor

7. Rafinarea scenariilor, iesirilor/intrarilor, caracteristicilor/functiilor si riscurilor, cu ajutorul clientului

8. Atribuirea de prioritati (stabilite de client) la fiecare scenariu utilizator, caracteristica, functie si comportament

Referat: Contabilitatea tertilor Referat: Structurarea elementelor de activ si pasiv dupa criterii financiare

9. Revizuirea tuturor informatiilor colectate in timpul activitatii de comunicare cu clientul si ceilalti interesati si modificarea lor dupa nevoie

10. Pregatirea pentru activitatea de planificare

3.1. Principiile planificarii

1. Trebuie inteles domeniului proiectului

Clientul trebuie implicat in planificare

3. Planificarea este o activitate iterativa

4. Estimarile se efectueaza numai pe baza a ceea ce se cunoaste

5. La definirea planului trebuie luate in considerare riscurile

6. Planificarea trebuie sa dea dovada de realism

7. Granularitatea planului se ajusteaza pe masura ce planificarea avanseaza

Granularitate: caracterizeaza nivelul de detaliere

Plan cu granularitate fina (fine granularity plan): ofera o detaliere semnificativa a sarcinilor de lucru pe o perioada de timp mica (incremente mici); apar frecvent actiuni de urmarire si control

Plan cu granularitate mare (coarse granularity plan): ofera sarcini de lucru mai generale planificate pe perioade mai mari de timp

Pe masura ce timpul proiectului este mai departat de data curenta, nivelul de granularitate creste de la fina la mare (sarcinile de lucru curente sunt prezentate detaliat, pe cand cele mai indepartate sunt prezentate mai succint)

8. Trebuie sa se defineasca modul in care se intentioneaza sa se asigure calitatea softului produs

9. Trebuie sa se defineasca modul in care se intentioneaza sa se gestioneze schimbarea

10. Realizarea planului trebuie urmarita si trebuie efectuate ajustarile necesare

3. Proiect realist: intrebari

1. De ce se realizeaza sistemul? motivele fiecarui stakeholder. se justifica eforturile de personal, timp si bani?

Ce se va realiza? (functionalitatea de incorporat, si, prin deducere, sarcinile necesare pentru finalizarea incorporarii functionalitatii)

3. Cand se va termina? (workflow, timeline pentru sarcinile esentiale si identificarea bornelor cerute de client)

4. Cine raspunde de o anumita functie (definirea rolului si responsabilitatilor fiecarui membru al echipei de dezvoltare)

5. Unde sunt localizati in organizatie (nu toate rolurile si responsabilitatile apartin echipei de dezvoltare. Clientii, utilizatorii, ceilalti stakeholders au si ei responsabilitati)

6. Cum se vor indeplini sarcinile din punct de vedere tehnic si managerial (dupa stabilirea product scope, trebuie definita o strategie de management si tehnica pentru proiect)

7. Care este necesarul din fiecare resursa (se realizeaza estimari pe baza raspunsurilor la intrebarile anterioare).

3.3. Sarcini generice ale planificarii

1. Reevaluarea domeniului proiectului (project scope)

Evaluarea riscurilor

3. Dezvoltarea si/sau rafinarea scenariilor utilizator (user scenarios)

4. Extragerea functiilor si caracteristicilor din scenarii

5. Definirea functiilor si caracteristicilor tehnice care formeaza infrastructura soft

6. Gruparea functiilor si caracteristicilor (scenariilor) dupa prioritatile clientilor

7. Crearea unui plan de proiect de granularitate mare (de ansamblu)

• Definirea numarului de incremente soft planificate
• Stabilirea unui plan (orar) general al proiectului
• Stabilirea datelor de livrare pentru fiecare increment

8. Crearea unui plan de proiect de granularitate mica (de detaliu) pentru iteratia curenta

• Definirea sarcinilor de lucru pentru fiecare functie (caracteristica)
• Estimarea efortului pentru fiecare sarcina de lucru
• Atribuirea de responsabilitati pentru fiecare sarcina de lucru
• Definirea produselor (work products) de realizat
• Identificarea metodelor de asigurare a calitatii ce se vor folosi
• Descrierea metodelor pentru gestiunea modificarilor

9. Urmarirea permanenta a progreselor realizate

• Inregistrarea dificultatilor
• Efectuarea de ajustari dupa nevoie.

4. Modelarea in analiza: principii si sarcini generice

4.1. Principii de modelare in analiza

1. Trebuie reprezentat si inteles domeniul informatiei pentru problema data

Trebuie definite functiile pe care trebuie sa le realizeze sistemul soft

3. Trebuie reprezentat comportamentul sistemului soft (ca reactie la evenimente externe)

4. Trebuie stratificate ierarhic modelele care reprezinta informatia, functiile si comportamentul

5. Sarcina analizei este sa permita trecerea de la informatia esentiala la detaliile de implementare

4. Sarcini generice ale analizei

1. Revizuirea cerintelor problemei (business requirements), caracteristicilor/nevoilor utilizatorilor finali, iesirilor tangibile, constrangerilor specifice si a altor cerinte tehnice care au fost identificate pe parcursul activitatilor de comunicare si planificare

Extinderea si detalierea scenariilor utilizator (user scenarios)

• Definirea tuturor actorilor
• Reprezentarea modului in care actorii interactioneaza cu sistemul soft
• Extragerea functiilor si caracteristicilor din scenariile utilizator
• Revizuirea scenariilor utilizator dpdv al completitudinii si acuratetii

3. Modelarea domeniului informatiei

• Reprezentarea tuturor obiectelor din domeniul problemei (business entities, entitati din domeniul problemei, obiecte majore purtatoare de informatie )
• Definirea atributelor pentru fiecare obiect din domeniul problemei
• Reprezentarea relatiilor dintre obiectele din domeniul problemei

4. Modelarea functionalitatii

• Ilustrarea modului in care functiile modifica obiectele din domeniul problemei
• Rafinarea (descompunerea) functiilor pentru obtinerea detaliilor
• Scrierea unei descrieri textuale pentru fiecare functie si subfunctie
• Revizuirea modelelor functionale

5. Modelarea comportamentului

• Identificarea evenimentelor externe care produc modificari comportamentale in sistemul soft
• Identificarea starilor ce reprezinta fiecare mod de comportament observabil din exterior
• Ilustrarea modului in care un eveniment produce o tranzitie de stare in sistem
• Revizuirea modelelor comportamentale

6. Analiza si modelarea interfetei cu utilizatorul

• Efectuarea analizei sarcinilor
• Crearea de prototipuri ecran

7. Revizuirea tuturor modelelor dpdv al completitudinii, consistentei si omisiunilor

5. Modelarea in proiectare: principii si sarcini generice

5.1. Principii de modelare in proiectare

1. Proiectul trebuie sa se regaseasca in modelul de analiza

Proiectul incepe cu definirea arhitecturii sistemului soft

3. Proiectarea datelor este la fel de importanta ca si proiectarea functiilor

4. Interfetele (interne si externe) trebuie proiectate cu multa atentie

5. Proiectul interfetei cu utilizatorul trebuie sa corespunda nevoilor utilizatorilor finali

6. Fiecare componenta soft proiectata trebuie sa fie unitara, sa aiba coeziune

7. Componentele soft trebuie sa fie cuplate slab intre ele si cu mediul extern

8. Reprezentarile de proiectare (modelele) trebuie sa fie usor de inteles

9. Proiectul se dezvolta iterativ; la fiecare iteratie, proiectul trebuie sa fie cat mai simplu, dar nu simplist

5. Principiile modelarii agile www.agilemodeling.com

1. Scopul principal al echipei de dezvoltare este sa produca sisteme soft, nu modele

NU se creeaza mai multe modele decat este nevoie

3. Trebuie produs cel mai simplu model care descrie problema sau softul

4. Modelele trebuie construite astfel incat sa se poata modifica usor

5. Fiecare model creat trebuie sa aiba un scop explicit (si precizat)

6. Modelele dezvoltate trebuie adaptate la sistemul existent

7. Modelele construite trebuie sa fie utile, nu perfecte (arta cu tendinta, nu arta pentru arta)

8. Sintaxa modelului nu este esentiala. Important este sa se inteleaga continutul; reprezentarea este pe planul doi.

9. Daca intuitia va spune ca un model nu este corect (potrivit), chiar daca el pare in regula pe hartie, atunci probabil ca exista cu adevarat motive de ingrijorare

10. Reactia utilizatorilor trebuie obtinuta cat mai repede posibil.

5.3. Sarcini generice ale proiectarii

1. Selectarea unui stil (sablon) arhitectural adecvat pentru sistemul soft, plecand de la modelul de analiza

Descompunerea modelului de analiza in subsisteme si incadrarea acestora in arhitectura propusa

• Cerinta: fiecare subsistem trebuie sa aiba coeziune functionala
• Proiectarea interfetelor subsistemelor
• Alocarea claselor si functiilor din analiza la fiecare subsistem
• Proiectarea structurilor de date adecvate pe baza modelului domeniului informatiei

3. Proiectarea interfetei cu utilizatorul

• Revizuirea rezultatelor analizei sarcinilor
• Specificarea secventei de actiuni pe baza scenariilor utilizator
• Crearea modelului de comportament al interfetei
• Definirea obiectelor de interfata si a mecanismelor de control
• Revizuirea proiectului interfetei

4. Proiectarea componentelor soft: Pentru fiecare componenta se realizeaza

• Descrierea detaliata a tuturor algoritmilor
• Detalierea interfetei
• Definirea structurilor de date interne
• Revizuirea proiectului componentei

5. Realizarea unui model de instalare/exploatare (deployment)

6. Constructia: principii si sarcini generice

6.1. Principii si concepte de codificare

inainte de scrierea primei linii de cod, programatorul trebuie

1. sa inteleaga problema de rezolvat

sa inteleaga principiile si conceptele de baza ale proiectului

3. sa cunoasca limbajul de programare in care se face implementarea si mediul de exploatare

4. sa aleaga un mediu de programare adecvat, cu instrumente care sa usureze codificarea si testarea

5. sa creeze un set de teste unitare care sa se aplice imediat ce s-a incheiat codificarea componentei

la scrierea codului, programatorul trebuie

1. sa descrie algoritmii folosind constructii structurate

sa aleaga structurile de date adecvate proiectului

3. sa inteleaga arhitectura sistemului soft si sa creeze interfete consistente cu aceasta

4. sa foloseasca conditii cat mai simple

5. sa creeze cicluri imbricate usor de testat

6. sa foloseasca identificatori sugestivi si sa respecte standardele de codificare adaptate de echipa

7. sa documenteze codul scris

8. sa aranjeze sugestiv codul in pagina (indentare, linii de spatiu) in scopul cresterii gradului de intelegere

dupa terminarea primului pas de codificare, programatorul trebuie

1. sa inspecteze codul scris

sa efectueze teste unitare si sa corecteze erorile descoperite

3. sa restructureze codul

6. Sarcini generice pentru codificare

1. Construirea infrastructurii arhitecturale

• Revizuirea proiectului de arhitectura
• Codificarea si testarea componentelor care creeaza cadrul arhitectural
• Acquire (obtinerea, folosirea) de sabloane arhitecturale reutilizabile
• Testarea infrastructurii pentru garantarea integritatii arhitecturale

Pentru fiecare componenta soft

Construirea componentei

• Revizuirea proiectului componentei
• Crearea unui set de teste unitare pentru componenta
• Codificarea structurilor de date si a interfetei
• Codificarea algoritmilor interni si a functiilor de prelucrare inrudite (auxiliare)
• Revizuirea codului pe masura ce este scris

• Studierea (demonstrarea) corectitudinii
• Respectarea standardelor de codificare
• Auto-documentarea codului

3. Testarea unitara: repeta pasii de mai jos pana cand nu mai exista erori

• Efectuarea tuturor testelor stabilite la pasul anterior
• Corectarea erorilor descoperite

4. Integrarea componentei in infrastructura arhitecturala

6.3. Testarea: terminologie (Pressman, www.softwaredevelopment.ca/bugs.shtml)

• fault, bug: secventa de cod incorecta
• cadere, failure: efect sau comportament inacceptabil al sistemului soft in conditii de exploatare relativ normale, ce apare drept consecinta a unui bug
• eroare: aspect nedorit de calitate descoperit inainte ca sistemul soft sa fie distribuit clientilor
• defect: aspect nedorit de calitate descoperit dupa ce sistemul soft a fost distribuit clientilor
• testare de integrare: tehnica sistematica de construirea a arhitecturii soft insotita de efectuarea de teste pentru descoperirea erorilor de interfata intre componentele arhitecturii
• build: include toate fisierele de date, bibliotecile, modulele reutilizabile si componentele necesare pentru implementarea uneia sau mai multor functii ale sistemului soft.

• smoke testing: varianta a testarii de integrare ce permite echipei de dezvoltare sa evalueze frecvent starea sistemului soft.
• componentele soft deja implementate sunt integrate intr-un build
• se proiecteaza un set de teste menite sa expuna (dezvaluie) erorile care impiedica build-ul sa functioneze normal
• build-ul se integreaza cu alte build-uri si sistemul soft in ansamblu (ceea ce s-a implementat) este testat zilnic
• regression testing: re-executia unui subset de teste, ori de cate ori la testarea de integrare sau la intretinere se adauga/modifica un modul, in scopul gasirii eventualelor erori de integrare provocate de efecte secundare

• teste de sistem (high-order sau system testing)
• recovery testing: test de sistem care forteaza in diverse moduri caderi ale softului si verifica daca se realizeaza adecvat recuperarea din asemenea situatii
• daca recuperarea este automata (facuta de sistemul soft in cauza), atunci se evalueaza daca sunt corecte procedurile de reinitializare, mecanismele de puncte de verificare, recuperarea datelor si repornire.
• security testing: verifica daca mecanismele de protectie incorporate in sistemul soft il protejeaza la acces neautorizat
• stress testing: executia sistemului soft intr-un mod anormal (ce necesita resurse in cantitati, frecvente si volume anormale)
• performance testing: testeaza performantele sistemului soft la executie
• verificare si validare (V & V)
• verificarea: Are we building the software system right? Sistemul soft este conform specificatiilor?
• validarea: Are we building the right product? Sistemul soft corespunde nevoilor utilizatorilor?

6.4. Testarea: obiective si fundamente

• obiectivele verificarii si validarii (V & V)
• sa descopere erorile si sa le inlature
• sa stabileasca daca sistemul soft este utilizabil intr-un mediu real
• fundamentele testarii softului (Glen Myers, The Art of Software Testing, Wiley, 1979)
• testarea este procesul prin care se executa un program cu scopul detectarii unei erori
• setul de date de test (test case) este bun daca are o probabilitate mare de descoperire a unei erori ascunse
• testul cu succes este acela care descopera cel putin o eroare (ascunsa pana la executia lui)

6.5. Principiile testarii

1. Toate testele trebuie sa se regaseasca in (sa provina din) cerintele clientilor

Testele trebuie planificate cu mult inainte de inceperea testarii

3. Principiul Pareto este aplicabil la testarea softului (principiul Pareto este principiul 80-20: 80% din toate erorile descoperite la testare se refera la 20% dintre componentele sistemului soft supus testarii.

4. Testarea trebuie sa progreseze gradat: se incepe cu testarea unitara, se continua cu testarea de integrare (se adauga componente la scheletul de arhitectura) si se incheie cu testarea de acceptare (este construit intreg sistemul)

5. Testarea exhaustiva nu este posibila

6.6. Sarcini generice ale testarii

1. Proiectarea testelor unitare pentru fiecare componenta soft. Pentru fiecare test unitar proiectat

• Revizuirea testului pentru garantarea acoperirii tuturor situatiilor

Se repeta pana cand nu mai sunt erori

• Executia
• Corectarea erorilor descoperite

Dezvoltarea unei strategii de integrare

• Stabilirea ordinii de integrare si a strategiei de integrare
• Definirea 'build-urilor' si testelor necesare pentru fiecare
• Executia zilnica a smoke testing
• Executarea regression testing dupa caz

3. Dezvoltarea unei strategii de validare

• Stabilirea criteriilor de validare
• Definirea testelor necesare pentru validarea softului

Repeta pana cand nu mai sunt erori

4. Executia testelor de integrare si validare

• Corectarea erorilor descoperite

5. Executia testelor de sistem

• teste de recuperare
• teste de securitate
• teste de stres
• teste de performanta

6. Coordonarea testelor de acceptare cu clientul

7. Exploatarea: principii si sarcini generice

7.1. Principiile distribuirii/instalarii

1. Trebuie acordata mare atentie asteptarilor/sperantelor clientului fata de sistemul soft

Trebuie asamblat si testat intregul pachet de livrare

3. Inainte de livrarea softului la client trebuie stabilit modul in care se acorda asistenta tehnica

4. Utilizatorilor trebuie sa li se furnizeze materiale de instruire

5. Nu trebuie livrat clientilor soft cu erori

7. Sarcini generice ale distribuirii/instalarii

1. Crearea suporturilor fizice cu pachetele de livrare

• Asamblarea si testarea tuturor fisierelor executabile
• Asamblarea si testarea tuturor fisierelor de date
• Crearea si testarea intregii documentatii de utilizare
• Crearea versiunilor electronice ale documentatiei
• Crearea fisierelor de help (hipertext)
• Crearea ghidului pentru situatii de avarie (troubleshooting guide)
• Testarea suporturilor de livrare la un grup mic (reprezentativ) de utilizatori

Stabilirea persoanei sau grupului de asistenta tehnica pentru utilizatori

• Crearea documentatiei si/sau instrumentelor automate de asistenta
• Stabilirea mecanismelor de contact (site Web, telefon, e-mail, etc.)
• Stabilirea mecanismelor de inregistrare (logging) a problemelor (dificultatilor)
• Stabilirea mecanismelor de raportare (reporting) a problemelor (dificultatilor)
• Stabilirea bazei de date de raportare a problemelor/defectelor

3. Stabilirea mecanismelor de gestiune a reactiei utilizatorilor

4. Livrarea suporturilor fizice la clienti

5. Pornirea si executia procedurilor de asistenta tehnica

• Asigurarea asistentei tehnice la instalare si lansare in executie
• Asigurarea asistentei tehnice continue in situatii de defecte

6. Colectarea reactiei utilizatorilor

• Inregistrarea reactiilor
• Evaluarea reactiilor
• Comunicarea cu utilizatorii