Sunteți pe pagina 1din 10

ISS Capitolul 2

Curs 2

2. DEZVOLTAREA SISTEMELOR SOFT: PRINCIPII ŞI


ACTIVITĂŢI

Cuprins:
1. Procese soft
2. Dezvoltarea sistemelor soft: principii şi activităţi
3. Modelarea proceselor şi sistemelor soft
4. Limbajul unificat de modelare (UML)
5. Colectarea, analiza şi specificarea cerinţelor
6. Modelarea în analiză
7. Proiectarea: concepte şi modele
8. Proiectarea arhitecturii şi claselor: principii
9. Proiectarea arhitecturii, datelor şi prelucrărilor
10. Proiectarea componentelor
11. Proiectarea interfeţei cu utilizatorul
12. Testarea softului: etape şi metode
13. Instalarea şi întreţinerea
14. Planificarea proiectelor soft

2.1. Problem solving şi dezvoltarea de soft: asemănări şi deosebiri


2.1.1. Problem solving
2.1.2. Problem solving în contextul ingineriei soft
2.1.3. Principii generale ale dezvoltării de soft
2.2. Comunicarea: principii şi sarcini generice
2.2.1. Principiile comunicării
2.2.2. Sarcini generice ale comunicării
2.3. Planificarea: principii şi sarcini generice
2.3.1. Principiile planificării
2.3.2. Proiect realist: întrebări
2.3.3. Sarcini generice ale planificării
2.4. Modelarea în analiză: principii şi sarcini generice
2.4.1. Principii de modelare în analiză
2.4.2. Sarcini generice ale analizei
2.5. Modelarea în proiectare: principii şi sarcini generice
2.5.1. Principii de modelare în proiectare
2.5.2. Principiile modelării agile
2.5.3. Sarcinile generice ale proiectării
2.6. Construcţia: principii şi sarcini generice
2.6.1. Principii şi concepte de codificare
2.6.2. Sarcinile generice ale codificării
2.6.3. Testarea: terminologie
2.6.4. Testarea: fundamente
2.6.5. Principiile testării
2.6.6. Sarcini generice ale testării
1
2.7. Exploatarea: principii şi sarcini generice
2.7.1. Principiile distribuirii/instalării
2.7.2. Sarcini generice ale distribuirii/instalării

2.1. Asemănări şi deosebiri între problem solving şi dezvoltarea de soft

2.1.1. Problem solving (Polya, G., How to Solve It, Princeton University Press, 1945)
Paşii rezolvării problemelor
1. Înţelegerea problemei (comunicare şi analiză)
2. Gândirea unei soluţii (modelare şi proiectare)
3. Rezolvarea efectivă (generare de cod)
4. Examinarea acurateţii rezultatului, proba (testarea şi asigurarea calităţii), punerea în operă

2.1.2. Problem solving în contextul ingineriei soft


1. Înţelegerea problemei (comunicare şi analiză)
 cui, la ce foloseşte rezolvarea problemei? (care sunt cei interesaţi, stakeholders?)
 care sunt necunoscutele problemei? (ce date, funcţii sau caracteristici de comportament
sunt necesare pentru rezolvarea completă a problemei?)
 se poate descompune problema în probleme mai simple? (este posibil să se identifice din
problema iniţială subprobleme de complexitate mai redusă care să fie mai uşor de
reprezentat şi rezolvat?)
 se pot folosi reprezentări grafice? (se pot crea diagrame pentru modelul de analiză?)
2. Gândirea unei soluţii (modelare şi proiectare)
 problema dată seamănă cu probleme întâlnite anterior? (există şabloane care să se
poată include într-o soluţie posibilă? există proiecte care implementează deja datele,
funcţiile, caracteristicile de comportament necesare?)
 a fost rezolvată anterior o problemă similară? (dacă da, ce elemente ale soluţiei acesteia
se pot refolosi?)
 se pot defini subprobleme? (dacă da, soluţiile acestora sunt cunoscute?)
 soluţia problemei se poate reprezenta în aşa fel încât să permită o implementare
eficientă? (se poate crea un model de proiectare?)
3. Rezolvarea efectivă (generare de cod)
 soluţia este conformă planului? (se poate reconstitui modelul de proiectare plecând de la
codul sursă?)
 fiecare parte componentă a soluţiei este (probabil) corectă? (proiectul şi codul au fost
revizuite? sau, mai bine: s-au efectuat demonstraţii de corectitudine ale algoritmilor
folosiţi?)
4. Examinarea acurateţii rezultatului, proba (testarea şi asigurarea calităţii), folosirea
 este posibil să se testeze separat fiecare componentă a soluţiei? (s-a implementat o
strategie rezonabilă de testare?)
 soluţia obţinută produce rezultate în conformitate cu cerinţele privitoare la date, funcţii,
caracteristici sau comportament? (softul a fost validat în raport cu toate cerinţele?)

2.1.3. Principii generale ale dezvoltării de soft (Pressman)


• The Reason It All Exists: Motivul existenţei: să fie de folos utilizatorilor
• KISS (Keep It Simple, Stupid!): Proiectul trebuie să fie cât mai simplu posibil, dar nu simplist
• Maintain the Vision: Viziunea clară este esenţială pentru succesul unui proiect soft

2
• What You Produce, Others Will Consume: La specificare, proiectare şi implementare trebuie să
se ţină întotdeauna cont că altcineva (utilizatorii) trebuie să înţeleagă şi să folosească sistemul
soft
• Be Open to the Future: sistemul trebuie să fie pregătit să încorporeze schimbări, anticipate sau
nu
• Plan Ahead for Reuse: se reduce costul şi se creşte valoarea atât pentru componentele
reutilizabile, cât şi pentru sistemele în care acestea sunt incorporate.
• Think! Gândeşte înainte de a acţiona.

2.2. Comunicarea: principii şi sarcini generice

2.2.1. Principiile comunicării


1. Învaţă să asculţi pe alţii
2. Pregăteşte-te înainte de comunicarea cu ceilalţi (înţelegerea domeniului, problemei,
vocabularului, agenda întâlnirii)
3. Comunicare are nevoie de sprijin şi coordonare
4. Comunicarea directă este cea mai bună
5. Ia notiţe şi documentează deciziile luate
6. Colaborarea şi consensul apar când cunoştinţele colective ale membrilor echipei se combină
pentru a descrie produsul sau funcţiile şi caracteristicile sistemului
7. Păstrează obiectul discuţiilor, fără divagaţii inutile
8. Dacă este ceva neclar, desenează o imagine
9. (a) La acord cu partenerii, continuă cu altceva
(b) La dezacord cu partenerii, continuă cu altceva
(c) Dacă o caracteristică sau funcţie nu este clară pe moment, continuă cu altceva
10. Negocierea nu este nici concurs, nici joc. Cel mai bine este atunci când ambele părţi câştigă.

2.2.2. Sarcini generice ale comunicării


1. Identificarea clientului principal şi a tuturor celor interesaţi (stakeholders)
2. Întâlnirea cu clientul principal pentru a răspunde la întrebări "generale" ce definesc
 Nevoile şi elementele de valoare/importante ale organizaţiei client sau domeniului
problemei
 Caracteristicile şi nevoile utilizatorilor finali
 Ieşirile vizibile/tangibile/percepute cerute de utilizator
 Constrângerile, regulile din domeniul problemei
3. Scrierea unui document de o pagină cu enunţul domeniului proiectului, susceptibil la revizuire
4. Revizuirea enunţului cu toţi cei interesaţi şi modificarea lui după necesităţi
5. Colaborarea cu clientul/utilizatorii pentru a defini
 Scenariile de utilizare percepute de utilizatori într-un format standard
 Ieşirile produse şi intrările
 Caracteristicile, funcţiile şi comportamentul relevant
 Riscurile specifice domeniului problemei, definite de client
6. Elaborarea unei descrieri scrise (o mulţime de liste) a scenariilor, ieşirilor/intrărilor,
caracteristicilor/funcţiilor şi riscurilor
7. Rafinarea scenariilor, ieşirilor/intrărilor, caracteristicilor/funcţiilor şi riscurilor, cu ajutorul
clientului
8. Atribuirea de priorităţi (stabilite de client) la fiecare scenariu utilizator, caracteristică, funcţie şi
comportament
9. Revizuirea tuturor informaţiilor colectate în timpul activităţii de comunicare cu clientul şi ceilalţi
interesaţi şi modificarea lor după nevoie
10. Pregătirea pentru activitatea de planificare
3
2.3.1. Principiile planificării
1. Trebuie înţeles domeniului proiectului
2. Clientul trebuie implicat în planificare
3. Planificarea este o activitate iterativă
4. Estimările se efectuează numai pe baza a ceea ce se cunoaşte
5. La definirea planului trebuie luate în considerare riscurile
6. Planificarea trebuie să dea dovadă de realism
7. Granularitatea planului se ajustează pe măsură ce planificarea avansează
– Granularitate: caracterizează nivelul de detaliere
– Plan cu granularitate fină (fine granularity plan): oferă o detaliere semnificativă a
sarcinilor de lucru pe o perioadă de timp mică (incremente mici); apar frecvent acţiuni
de urmărire şi control
– Plan cu granularitate mare (coarse granularity plan): oferă sarcini de lucru mai
generale planificate pe perioade mai mari de timp
– Pe măsură ce timpul proiectului este mai depărtat de data curentă, nivelul de
granularitate creşte de la fină la mare (sarcinile de lucru curente sunt prezentate
detaliat, pe când cele mai îndepărtate sunt prezentate mai succint)
8. Trebuie să se definească modul în care se intenţionează să se asigure calitatea softului produs
9. Trebuie să se definească modul în care se intenţionează să se gestioneze schimbarea
10. Realizarea planului trebuie urmărită şi trebuie efectuate ajustările necesare

2.3.2. Proiect realist: întrebări


1. De ce se realizează sistemul? motivele fiecărui stakeholder. se justifică eforturile de personal, timp şi
bani?
2. Ce se va realiza? (funcţionalitatea de incorporat, şi, prin deducere, sarcinile necesare pentru
finalizarea încorporării funcţionalităţii)
3. Când se va termina? (workflow, timeline pentru sarcinile esenţiale şi identificarea bornelor cerute de
client)
4. Cine răspunde de o anumită funcţie (definirea rolului şi responsabilităţilor fiecărui membru al
echipei de dezvoltare)
5. Unde sunt localizaţi în organizaţie (nu toate rolurile şi responsabilităţile aparţin echipei de
dezvoltare. Clienţii, utilizatorii, ceilalţi stakeholders au şi ei responsabilităţi)
6. Cum se vor îndeplini sarcinile din punct de vedere tehnic şi managerial (după stabilirea product
scope, trebuie definită o strategie de management şi tehnică pentru proiect)
7. Care este necesarul din fiecare resursă (se realizează estimări pe baza răspunsurilor la întrebările
anterioare).

2.3.3. Sarcini generice ale planificării


1. Reevaluarea domeniului proiectului (project scope)
2. Evaluarea riscurilor
3. Dezvoltarea şi/sau rafinarea scenariilor utilizator (user scenarios)
4. Extragerea funcţiilor şi caracteristicilor din scenarii
5. Definirea funcţiilor şi caracteristicilor tehnice care formează infrastructura soft
6. Gruparea funcţiilor şi caracteristicilor (scenariilor) după priorităţile clienţilor
7. Crearea unui plan de proiect de granularitate mare (de ansamblu)
 Definirea numărului 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 mică (de detaliu) pentru iteraţia curentă
 Definirea sarcinilor de lucru pentru fiecare funcţie (caracteristică)
 Estimarea efortului pentru fiecare sarcină de lucru

4
 Atribuirea de responsabilităţi pentru fiecare sarcină de lucru
 Definirea produselor (work products) de realizat
 Identificarea metodelor de asigurare a calităţii ce se vor folosi
 Descrierea metodelor pentru gestiunea modificărilor
9. Urmărirea permanentă a progreselor realizate
 Înregistrarea dificultăţilor
 Efectuarea de ajustări după nevoie.

2.4. Modelarea în analiză: principii şi sarcini generice

2.4.1. Principii de modelare în analiză


1. Trebuie reprezentat şi înţeles domeniul informaţiei pentru problema dată
2. Trebuie definite funcţiile pe care trebuie să le realizeze sistemul soft
3. Trebuie reprezentat comportamentul sistemului soft (ca reacţie la evenimente externe)
4. Trebuie stratificate ierarhic modelele care reprezintă informaţia, funcţiile şi comportamentul
5. Sarcina analizei este să permită trecerea de la informaţia esenţială la detaliile de implementare

2.4.2. Sarcini generice ale analizei


1. Revizuirea cerinţelor problemei (business requirements), caracteristicilor/nevoilor utilizatorilor
finali, ieşirilor tangibile, constrângerilor specifice şi a altor cerinţe tehnice care au fost identificate pe
parcursul activităţilor de comunicare şi planificare
2. Extinderea şi detalierea scenariilor utilizator (user scenarios)
 Definirea tuturor actorilor
 Reprezentarea modului în care actorii interacţionează cu sistemul soft
 Extragerea funcţiilor şi caracteristicilor din scenariile utilizator
 Revizuirea scenariilor utilizator dpdv al completitudinii şi acurateţii
3. Modelarea domeniului informaţiei
 Reprezentarea tuturor obiectelor din domeniul problemei (business entities, entităţi din
domeniul problemei, obiecte majore purtătoare de informaţie )
 Definirea atributelor pentru fiecare obiect din domeniul problemei
 Reprezentarea relaţiilor dintre obiectele din domeniul problemei
4. Modelarea funcţionalităţii
 Ilustrarea modului în care funcţiile modifică obiectele din domeniul problemei
 Rafinarea (descompunerea) funcţiilor pentru obţinerea detaliilor
 Scrierea unei descrieri textuale pentru fiecare funcţie şi subfuncţie
 Revizuirea modelelor funcţionale
5. Modelarea comportamentului
 Identificarea evenimentelor externe care produc modificări comportamentale în sistemul
soft
 Identificarea stărilor ce reprezintă fiecare mod de comportament observabil din exterior
 Ilustrarea modului în care un eveniment produce o tranziţie de stare în sistem
 Revizuirea modelelor comportamentale
6. Analiza şi modelarea interfeţei cu utilizatorul
 Efectuarea analizei sarcinilor
 Crearea de prototipuri ecran
7. Revizuirea tuturor modelelor dpdv al completitudinii, consistenţei şi omisiunilor

5
2.5. Modelarea în proiectare: principii şi sarcini generice

2.5.1. Principii de modelare în proiectare


1. Proiectul trebuie să se regăsească în modelul de analiză
2. Proiectul începe cu definirea arhitecturii sistemului soft
3. Proiectarea datelor este la fel de importantă ca şi proiectarea funcţiilor
4. Interfeţele (interne şi externe) trebuie proiectate cu multă atenţie
5. Proiectul interfeţei cu utilizatorul trebuie să corespundă nevoilor utilizatorilor finali
6. Fiecare componentă soft proiectată trebuie să fie unitară, să aibă coeziune
7. Componentele soft trebuie să fie cuplate slab între ele şi cu mediul extern
8. Reprezentările de proiectare (modelele) trebuie să fie uşor de înţeles
9. Proiectul se dezvoltă iterativ; la fiecare iteraţie, proiectul trebuie să fie cât mai simplu, dar nu
simplist

2.5.2. Principiile modelării agile www.agilemodeling.com


1. Scopul principal al echipei de dezvoltare este să producă sisteme soft, nu modele
2. NU se creează mai multe modele decât este nevoie
3. Trebuie produs cel mai simplu model care descrie problema sau softul
4. Modelele trebuie construite astfel încât să se poată modifica uşor
5. Fiecare model creat trebuie să aibă un scop explicit (şi precizat)
6. Modelele dezvoltate trebuie adaptate la sistemul existent
7. Modelele construite trebuie să fie utile, nu perfecte (artă cu tendinţă, nu artă pentru artă)
8. Sintaxa modelului nu este esenţială. Important este să se înţeleagă conţinutul; reprezentarea este pe
planul doi.
9. Dacă intuiţia vă spune că un model nu este corect (potrivit), chiar dacă el pare în regulă pe hârtie,
atunci probabil că există cu adevărat motive de îngrijorare
10. Reacţia utilizatorilor trebuie obţinută cât mai repede posibil.

2.5.3. Sarcini generice ale proiectării


1. Selectarea unui stil (şablon) arhitectural adecvat pentru sistemul soft, plecând de la modelul de
analiză
2. Descompunerea modelului de analiză în subsisteme şi încadrarea acestora în arhitectura propusă
 Cerinţă: fiecare subsistem trebuie să aibă coeziune funcţională
 Proiectarea interfeţelor subsistemelor
 Alocarea claselor şi funcţiilor din analiză la fiecare subsistem
 Proiectarea structurilor de date adecvate pe baza modelului domeniului informaţiei
3. Proiectarea interfeţei cu utilizatorul
 Revizuirea rezultatelor analizei sarcinilor
 Specificarea secvenţei de acţiuni pe baza scenariilor utilizator
 Crearea modelului de comportament al interfeţei
 Definirea obiectelor de interfaţă şi a mecanismelor de control
 Revizuirea proiectului interfeţei
4. Proiectarea componentelor soft: Pentru fiecare componentă se realizează
 Descrierea detaliată a tuturor algoritmilor
 Detalierea interfeţei
 Definirea structurilor de date interne
 Revizuirea proiectului componentei
5. Realizarea unui model de instalare/exploatare (deployment)

6
2.6. Construcţia: principii şi sarcini generice

2.6.1. Principii şi concepte de codificare


• înainte de scrierea primei linii de cod, programatorul trebuie
1. să înţeleagă problema de rezolvat
2. să înţeleagă principiile şi conceptele de bază ale proiectului
3. să cunoască limbajul de programare în care se face implementarea şi mediul de exploatare
4. să aleagă un mediu de programare adecvat, cu instrumente care să uşureze codificarea şi testarea
5. să creeze un set de teste unitare care să se aplice imediat ce s-a încheiat codificarea componentei
• la scrierea codului, programatorul trebuie
1. să descrie algoritmii folosind construcţii structurate
2. să aleagă structurile de date adecvate proiectului
3. să înţeleagă arhitectura sistemului soft şi să creeze interfeţe consistente cu aceasta
4. să folosească condiţii cât mai simple
5. să creeze cicluri imbricate uşor de testat
6. să folosească identificatori sugestivi şi să respecte standardele de codificare adaptate de echipă
7. să documenteze codul scris
8. să aranjeze sugestiv codul în pagină (indentare, linii de spaţiu) în scopul creşterii gradului de
înţelegere
• după terminarea primului pas de codificare, programatorul trebuie
1. să inspecteze codul scris
2. să efectueze teste unitare şi să corecteze erorile descoperite
3. să restructureze codul

2.6.2. Sarcini generice pentru codificare


1. Construirea infrastructurii arhitecturale
 Revizuirea proiectului de arhitectură
 Codificarea şi testarea componentelor care creează cadrul arhitectural
 Acquire (obţinerea, folosirea) de şabloane arhitecturale reutilizabile
 Testarea infrastructurii pentru garantarea integrităţii arhitecturale
Pentru fiecare componentă soft
2. Construirea componentei
 Revizuirea proiectului componentei
 Crearea unui set de teste unitare pentru componentă
 Codificarea structurilor de date şi a interfeţei
 Codificarea algoritmilor interni şi a funcţiilor de prelucrare înrudite (auxiliare)
 Revizuirea codului pe măsură ce este scris
 Studierea (demonstrarea) corectitudinii
 Respectarea standardelor de codificare
 Auto-documentarea codului
3. Testarea unitară: repetă paşii de mai jos până când nu mai există erori
 Efectuarea tuturor testelor stabilite la pasul anterior
 Corectarea erorilor descoperite
4. Integrarea componentei în infrastructura arhitecturală

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


 fault, bug: secvenţă de cod incorectă

7
 cădere, failure: efect sau comportament inacceptabil al sistemului soft în condiţii de exploatare
relativ normale, ce apare drept consecinţă a unui bug
 eroare: aspect nedorit de calitate descoperit înainte ca sistemul soft să fie distribuit clienţilor
 defect: aspect nedorit de calitate descoperit după ce sistemul soft a fost distribuit clienţilor
 testare de integrare: tehnică sistematică de construirea a arhitecturii soft însoţită de efectuarea
de teste pentru descoperirea erorilor de interfaţă între componentele arhitecturii
 build: include toate fişierele de date, bibliotecile, modulele reutilizabile şi componentele
necesare pentru implementarea uneia sau mai multor funcţii ale sistemului soft.
 smoke testing: variantă a testării de integrare ce permite echipei de dezvoltare să evalueze
frecvent starea sistemului soft.
 componentele soft deja implementate sunt integrate într-un build
 se proiectează un set de teste menite să expună (dezvăluie) erorile care împiedică build-
ul să funcţioneze normal
 build-ul se integrează cu alte build-uri şi sistemul soft în ansamblu (ceea ce s-a
implementat) este testat zilnic
 regression testing: re-execuţia unui subset de teste, ori de câte ori la testarea de integrare sau la
întreţinere se adaugă/modifică un modul, în scopul găsirii eventualelor erori de integrare
provocate de efecte secundare
 teste de sistem (high-order sau system testing)
 recovery testing: test de sistem care forţează în diverse moduri căderi ale softului şi
verifică dacă se realizează adecvat recuperarea din asemenea situaţii
 dacă recuperarea este automată (făcută de sistemul soft în cauză), atunci se
evaluează dacă sunt corecte procedurile de reiniţializare, mecanismele de puncte
de verificare, recuperarea datelor şi repornire.
 security testing: verifică dacă mecanismele de protecţie încorporate în sistemul soft îl
protejează la acces neautorizat
 stress testing: execuţia sistemului soft într-un mod anormal (ce necesită resurse în
cantităţi, frecvenţe şi volume anormale)
 performance testing: testează performanţele sistemului soft la execuţie
 verificare şi validare (V & V)
 verificarea: Are we building the software system right? Sistemul soft este conform
specificaţiilor?
 validarea: Are we building the right product? Sistemul soft corespunde nevoilor
utilizatorilor?

2.6.4. Testarea: obiective şi fundamente


 obiectivele verificării şi validării (V & V)
 să descopere erorile şi să le înlăture
 să stabilească dacă sistemul soft este utilizabil într-un mediu real
 fundamentele testării softului (Glen Myers, The Art of Software Testing, Wiley, 1979)
 testarea este procesul prin care se execută un program cu scopul detectării unei erori
 setul de date de test (test case) este bun dacă are o probabilitate mare de descoperire a
unei erori ascunse
 testul cu succes este acela care descoperă cel puţin o eroare (ascunsă până la execuţia
lui)

2.6.5. Principiile testării


1. Toate testele trebuie să se regăsească în (să provină din) cerinţele clienţilor
2. Testele trebuie planificate cu mult înainte de începerea testării

8
3. Principiul Pareto este aplicabil la testarea softului (principiul Pareto este principiul 80-20: 80% din
toate erorile descoperite la testare se referă la 20% dintre componentele sistemului soft supus testării.
4. Testarea trebuie să progreseze gradat: se începe cu testarea unitară, se continuă cu testarea de
integrare (se adaugă componente la scheletul de arhitectură) şi se încheie cu testarea de acceptare (este
construit întreg sistemul)
5. Testarea exhaustivă nu este posibilă

2.6.6. Sarcini generice ale testării


1. Proiectarea testelor unitare pentru fiecare componentă soft. Pentru fiecare test unitar proiectat
 Revizuirea testului pentru garantarea acoperirii tuturor situaţiilor
Se repetă până când nu mai sunt erori
 Execuţia
 Corectarea erorilor descoperite
2. Dezvoltarea unei strategii de integrare
 Stabilirea ordinii de integrare şi a strategiei de integrare
 Definirea "build-urilor" şi testelor necesare pentru fiecare
 Execuţia zilnică a smoke testing
 Executarea regression testing după caz
3. Dezvoltarea unei strategii de validare
 Stabilirea criteriilor de validare
 Definirea testelor necesare pentru validarea softului
Repetă până când nu mai sunt erori
4. Execuţia testelor de integrare şi validare
 Corectarea erorilor descoperite
5. Execuţia testelor de sistem
 teste de recuperare
 teste de securitate
 teste de stres
 teste de performanţă
6. Coordonarea testelor de acceptare cu clientul

2.7. Exploatarea: principii şi sarcini generice

2.7.1. Principiile distribuirii/instalării


1. Trebuie acordată mare atenţie aşteptărilor/speranţelor clientului faţă de sistemul soft
2. Trebuie asamblat şi testat întregul pachet de livrare
3. Înainte de livrarea softului la client trebuie stabilit modul în care se acordă asistenţa tehnică
4. Utilizatorilor trebuie să li se furnizeze materiale de instruire
5. Nu trebuie livrat clienţilor soft cu erori

2.7.2. Sarcini generice ale distribuirii/instalării


1. Crearea suporturilor fizice cu pachetele de livrare
 Asamblarea şi testarea tuturor fişierelor executabile
 Asamblarea şi testarea tuturor fişierelor de date
 Crearea şi testarea întregii documentaţii de utilizare
 Crearea versiunilor electronice ale documentaţiei
 Crearea fişierelor de help (hipertext)
 Crearea ghidului pentru situaţii de avarie (troubleshooting guide)
 Testarea suporturilor de livrare la un grup mic (reprezentativ) de utilizatori
2. Stabilirea persoanei sau grupului de asistenţă tehnică pentru utilizatori
9
 Crearea documentaţiei şi/sau instrumentelor automate de asistenţă
 Stabilirea mecanismelor de contact (site Web, telefon, e-mail, etc.)
 Stabilirea mecanismelor de înregistrare (logging) a problemelor (dificultăţilor)
 Stabilirea mecanismelor de raportare (reporting) a problemelor (dificultăţilor)
 Stabilirea bazei de date de raportare a problemelor/defectelor
3. Stabilirea mecanismelor de gestiune a reacţiei utilizatorilor
4. Livrarea suporturilor fizice la clienţi
5. Pornirea şi execuţia procedurilor de asistenţă tehnică
 Asigurarea asistenţei tehnice la instalare şi lansare în execuţie
 Asigurarea asistenţei tehnice continue în situaţii de defecte
6. Colectarea reacţiei utilizatorilor
 Înregistrarea reacţiilor
 Evaluarea reacţiilor
 Comunicarea cu utilizatorii

10