Escolar Documentos
Profissional Documentos
Cultura Documentos
software
- Principii generale -
Scopuri:
• Stabilirea obiectivelor proiectării software
• Identificarea diferenţelor ce apar la
dezvoltarea proiectele software şi la
dezvoltarea altor proiecte
• Definirea etapelor uzuale ale unui proiect
software
• Înţelegerea nevoii de planificare,
monitorizare şi control
• Măsurarea succesului unui proiect în
îndeplinirea obiectivelor
1) Introducere
A) Ciclul de control al
proiectului
Managementul, în
general, poate fi văzut
ca un proces de stabilire
a obiectivelor şi apoi
monitorizarea sistemului
pentru a vedea care
este performanţa sa
adevărată.
B) Obiective
Deşi calitatea este “un lucru bun”, calitatea unui sistem, în practică, poate
fi un atribut vag şi insuficient definit. De aceea trebuie să se definească
exact ce calităţi cerem unui sistem.
Portabilitate Adaptabilitate
Uşurinţa instalării (Installability)
Conformitate (Conformance)
Uşurinţa de a fi înlocuit (Replaceability)
Obs. Conformance, spre a se distinge de compliance, se referă la acele standarde care
privesc portabilitatea. Exemplu: folosirea unui limbaj de programare standard în multe medii
software/hardware e exemplu de conformance.
Obs. Replaceability se referă la factori care dau compatibilitatea ”în sus” între componentele
software vechi şi cele noi.
ISO 9126 oferă anumite indicaţii privind folosirea caracteristicilor de
calitate. Pentru sistemele interactive (interactive end user system),
elementul primordial d.p.d.v. al calităţii ar fi usability.
Mai jos sunt date orientativ anumite modalităţi de măsurare a unor calităţi
particulare. Fiecare proiect va trebui să aibă însă propriile măsuri.
Reliability
Aceasta poate fi măsurată în termeni de:
• disponibilitate(availability), procentul unui interval de timp în care
sistemul poate fi folosit;
• timpul mediu dintre eşecuri, timpul total de lucru, împărţit la numărul
de eşecuri;
• eşec la cerere, probabilitatea ca un sistem să nu fie disponibil la un
anumit timp sau probabilitatea ca o tranzacţie să eşueze;
• activitatea de suport (support activity), numărul de rapoarte de erori.
Mentenability
Poate fi văzută ca flexibilitate plus diagnosability, care poate fi definită
drept timpul mediu necesar pentru diagnosticarea unei erori.
Obs. D.p.d.v. al utilizatorului, mentenability priveşte timpul scurs între
detectarea unei erori şi corectarea ei, iar d.p.d.v. al managementului de
programare ca efortul necesar.
- Laborator -
Problema 1. Un sistem cuprinde 5000 SLOC, pentru implementarea
căruia a fost nevoie de 400 zile-muncă. Un amendament la sistem a
provocat adăugarea a 100 SLOC, care au luat 20 zile-muncă pentru
implementare. Calculaţi:
a) productivitatea sistemului original
b) Productivitatea pentru amendament
c) Extendibilitatea
Soluţie.
a) Productivitatea sistemului original=5000/400=12,5
b) Productivitatea pentru amendament=100/20=5
c) Extendibilitatea=5/12,5x100=40%
Problema 2. Sugeraţi specificaţii de calitate pentru un editor de texte.
Clasificarea beneficiilor:
• Beneficii directe: sunt mai uşor de estimat, din exploatarea directă
a sistemului.
• Beneficii indirecte estimabile: sunt în general beneficii secundare,
cum ar fi acurateţea crescută prin introducerea unei interfeţe mai
prietenoase, la care putem aprecia reducerea erorilor.
• Beneficii indirecte intangibile: sunt beneficii foarte greu de
cuantificat.
5. Estimarea fluxului banilor
(Cash-flow forecasting)
Estimarea fluxului banilor se poate arăta când apar cheltuielile
(expenditure) şi venitul.
valoare in anul t
valoare prezenta =
(1 + r ) t
Analiza cost-beneficiu
O abordare mai sofisticată a evaluării riscurilor este să se considere
fiecare posibil efect şi estimarea probabilităţii ca el să apară. În loc
de o singură estimare a cash flow, vom avea o mulţime de cash
flows, fiecare cu o probabilitate de apariţie. Valoarea proiectului e
obţinută prin însumarea costurilor sau beneficiilor pentru fiecare
rezultat, sumă ponderată cu probabilitatea corespunzătoare.
75000*0.8+(-100000)*0.2
=40000 Euros
250000*0.2+(-50000)*0.8
=10000 Euros
Posibilităţi
Anumite posibilităţi nu pot fi prevăzute. Totuşi, majoritatea evenimentelor
neaşteptate pot fi, în realitate, prevăzute. Asemenea evenimente se pot
întâmpla din timp în timp şi, chiar dacă probabilitatea de apariţie a lor să
fie mică, trebuie luate în calcul şi planificate.
2. Managementul riscurilor
În practică, sunt în general alţi factori care trebuie luaţi în calcul atunci
când vrem să aranjăm în funcţie de prioritate:
• Riscuri acumulate. Când se întâmplă acest lucru, riscurile trebuie
tratate ca şi cum ar fi un singur risc.
• Numărul riscurilor. Există un număr maxim de riscuri ce trebuie
considerate efectiv de un manager
• Costul acţiunii. Anumite riscuri, o dată identificate, pot fi reduse sau
evitate imediat cu un cost redus. Pentru alte riscuri trebuie să comparăm
costurile cu efectuarea acţiunii cu beneficiile reducerii riscului. O metodă
e să se calculeze risk reduction leverage (RRL):
• Prevenirea hazardului.
• Evitarea riscului.
a + 4m + b
te =
6
Exemplu. Se consideră tabelul de mai jos, cu estimările timpului
activităţilor folosind estimatorii PERT:
T − te
z=
s
Valoarea z pentru evenimentul 4 este (10-9)/0,53=1,8867.
s=0.5
s=0.33
s=0.17
s=0.25
s=0.5
s=1.17
s=0.33
s=0.08
Problema 3. Se consideră reţeaua PERT de mai jos. Calculaţi pentru
deviaţia standard pentru fiecare dintre evenimentele A,B,C,D,E,F,G,H.
Indicaţie.
R2 – revizuiţi estimările sau împărţiţi activitatea în componente mai mici şi faceţi
estimări pentru acele componente.
R4 – gândiţi o strategie de rezervă pentru recrutarea persoanelor implicate în
alte proiecte, dar care pot fi în postură de stanb-by la diverse momente.
Problema 2. Se consideră tabelul de mai jos, care conţine estimatorii de timp
a, m şi b pentru diversele activităţi. Calculaţi timpul aşteptat pentru fiecare
activitate, te
Indicaţie.
4
2.83
4.08
2.83
3
2.08
Problema 3. Se consideră reţeaua PERT de mai jos. Calculaţi pentru deviaţia
standard pentru evenimentele 4 şi 6.
Indicaţie.
Evenimentul 4. Calea A+C are deviaţia standard 0,50 2 + 0,17 2 = 0,53
Calea B+D are deviaţia standard 0,332 + 0,252 = 0,41
Nodul 4 are aşadar deviaţia standard 0,53.
Problema 4. Se consideră reţeaua PERT de mai jos. Calculaţi valorile z pentru
fiecare dintre evenimentele cu date ţintă din reţea.
Indicaţie. z4=1,89
10 − 10,5 z6=1,23
Valoarea z pentru evenimentul 5 este: = −0,43
1,17
Problema 5. Se consideră graficul de mai jos, care ajută la convertirea valorii z
la probabilităţi, pentru reţeaua de activităţi de la problemele 3 sau 4. Calculaţi
riscul ca proiectul să nu se termine în săptămâna a 15-a. Calculaţi probabilitatea
de a nu se realiza activităţile 4 şi 5 la sfârşitul săptămânii a 10-a.
A) Introducere
În introducere, e o idee bună să se explice pe scurt ce face sistemul
proiectat şi de ce. De asemenea, introducerea ar fi bine să conţină:
• identificarea clientului – pentru cine se face proiectul (inclusiv dacă e
pur didactic – cui s-ar putea adresa);
• o scurtă descriere a proiectului – cel mult câteva paragrafe;
• identificarea autorităţii de proiect – persoana sau persoanele din
cadrul organizaţiei clientului care va avea autoritate peste evoluţia
proiectului.
B) Background
Această parte ar trebui să conţină:
• informaţii relevante despre mediul software/hardware existent;
• circumstanţele sau problemele care conduc la proiect;
• munca din aria proiectului dusă deja la bun sfârşit;
• stakeholders din proiect (adică toţi cei care vor fi afectaţi de proiect
sau care sunt interesaţi de el).
C) Obiectivele proiectului
Obiectivele trebuie să definească ce ar trebui să se realizeze şi
metoda de măsurare a acestei creaţii. La proiectele studenţeşti,
evaluarea e făcută (de cele mai multe ori) din punct de vedere didactic.
Dacă însă această documentare e făcută şi în beneficiul clientului,
atunci punctul de vedere al clientului trebuie să fie prezent.
Dacă sunt multe obiective, ar trebui specificată prioritatea lor.
D) Constrângeri
De obicei se trec la partea cu obiectivele proiectului. Constrângerile
includ:
• scări de timp impuse din exterior;
• cerinţele legale;
• standarde specifice;
• limitări ale persoanelor care pot fi abordate pentru informaţii.
F) Rezultatele proiectului
Trebuie listate toate rezultatele (produsele) sau elementelor cum ar fi
module software, documentaţie, ghiduri utilizator, rapoarte.
G) Activităţi
Trebuie precizată lista cu principalele activităţi pe care le implică
proiectul. Fiecare activitate trebuie precizată în termeni concreţi: de
exemplu, în loc de “familiarizarea cu procedurile departamentului-2 ar
trebui “documentarea procedurilor departamentului”. S-ar putea
descoperi rezultate intermediare ale proiectului.
Pentru fiecare activitate, se definesc:
• elementele necesare înainte de a începe activitatea;
• activităţile dependente, adică acele activităţi ce necesită terminarea
acestei activităţi curente pentru a începe;
• timpul / efortul estimat, într-o anumită marjă;
• detalii despre cum vor fi verificate şi validate produsele activităţii.
Se pot include aici şi tabelele Gantt pentru monitorizarea activităţilor
(sau alte instrumente specifice monitorizării).
H) Resurse
Se pot include aici cerinţele software / hardware şi cele legate de
personal.
I) Analiza riscului
Se identifică principalele lucruri care ar putea merge rău. În mod
normal, acestea ar putea include:
• indisponibilitatea resurselor;
• indisponibilitatea personalului;
• probleme tehnice (cum ar fi bugs-urile software).
Se aloca fiecărui risc o evaluare a probabilităţii (notă între 1-10) şi o
notă pentru impactul fiecărui risc (tot între 1-10). Înmulţind cele două
note, se obţine un scor de ansamblu.
Pentru riscurile mari, e bine să se specifice şi eventualele măsuri
pentru reducerea acelor riscuri.
Concluzii
Categorii de raportare
Taking snap-shots
Frecvenţa cu care managerul are nevoie să primească informaţii despre
progresul proiectului depinde de mărimea şi gradul de risc al proiectului.
Liderii de echipă trebuie să evalueze progresul zilnic (mai ales când
lucrează cu personal neexperimentat), în timp ce managerii de proiect
găsesc mai potrivit să primească rapoarte săptămânale sau lunare.
3. Adunarea datelor
Ca o regulă, managerii vor încerca să împartă activităţile lungi în sarcini
mai controlabile ce se întind pe o săptămână sau două. Totuşi va fi
necesar să se adune informaţii despre activităţile parţial completate şi, în
particular, estimări despre câtă muncă mai e necesară pentru a le
completa. Uneori poate fi dificil să se facă astfel de estimări de mare
acurateţe.
Slip line
Ball charts
În figura de mai jos, cercurile indică punctele de start şi de completare
pentru activităţi. Iniţial cercurile conţin datele planificate originale. Ori de
câte ori se produc revizuiri, acestea sunt adăugate ca date secunde în
cercul corespunzător până când o activitate e începută în realitate sau
completată când datele relevante înlocuiesc prognozele revizuite
(îngroşat înclinat în figură).
Când datele de
începere reală sau de
terminare pentru o
activitate sunt întârziate
faţă de data ţintă, cercul
e colorat roşu (gri închis
în figură), iar când data
reală e la timp sau mai
devreme decât cea
planificată cercul e
colorat în verde (gri
deschis în figură).
Timeline chart
E o metodă de a înregistra şi afişa felul în care ţintele s-au schimbat pe
întreaga durată a proiectului. În figura de mai jos se arată un timeline
chart pentru un proiect la sfârşitul celei de-a şasea săptămâni. Timpul
planificat e reprezentat pe axa orizontală şi timpul scurs pe axa verticală.
Liniile şerpuite din diagramă reprezintă datele de completare a activităţii
planificate – la începutul proiectului analyse existing system e planificat
să fie completat până marţea (Tuesday) din săptămâna a 3-a, obtain user
requirements până joia (Thursday) din săptămâna a 5-a, issue tender,
activitatea finală, până marţea din săptămâna a 9-a s.a.m.d.
La sfârşitul primei săptămâni, managerul revede aceste date ţintă şi le
lasă aşa cum sunt. La sfârşitul săptămânii a 2-a, managerul decide că
obtain user requirements nu va fi completată până marţea din săptămâna
a 6-a – de aceea managerul extinde linia activităţii diagonal ca să reflecte
aceasta. Celelalte ţinte de completare a activităţii sunt întârziate
corespunzător. În marţea din săptămâna a 3-a, e completată analyse
existing system şi managerul pune un cerculeţ pe diagonală pentru a
indica că asta s-a întâmplat. La sfârşitul săptămânii a 3-a managerul
decide să păstreze ţintele existente. La sfârşitul săptămânii a 4-a adaugă
alte trei zile pentru draft tender şi issue tender.
De observat că la sfârşitul
săptămânii a 6-a, sunt
completate 2 activităţi şi 3
sunt încă nefinalizate.
Proiectul pe ansamblu va
avea 7 zile de întârziere.
5. Monitorizarea costurilor
O diagramă ca cea din figura de mai jos oferă o metodă simplă de
comparare a cheltuielilor planificate cu cele reale. În sine, nu indică dacă
nu cumva, deşi pare să existe economii faţă de bugetul planificat,
proiectul este mult întârziat şi de aceea graficul arată aşa.
O procedură simplă de
control al schimbărilor
pentru sistemele
operaţionale ar putea
avea următorii paşi:
Monitorizare şi control
- Laborator -
Problema 1. Se consideră planificarea proiectului dată în figura de mai jos.
Identificaţi acele activităţi programate să dureze mai mult de 3 săptămâni şi
descrieţi cum poate monitoriza progresul pentru fiecare dintre ele.
Problema 2. În tabelul Gantt de mai jos, identificaţi activităţile întârziate. Ce
efect au acestea asupra desfăşurării proiectului? Cum poate atenua efectul
întârzierii?
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 4. O schimbare în specificaţia programului se va reflecta în
schimbările făcute în designul programului şi apoi în codul schimbat.
Ce alte elemente vor trebui să sufere modificări?
Indicaţii şi rezolvări
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 4. O schimbare în specificaţia programului se va reflecta în
schimbările făcute în designul programului şi apoi în codul schimbat.
Ce alte elemente vor trebui să sufere modificări?
Indicaţie. Printre itemii cel mai probabil să sufere modificări sunt datele
de testare, rezultatele aşteptate şi manualul de utilizare.
Software design
- concepte, exemple -
1. Introducere
method copiecarte::imprumutare
input parameter – NrImprumut
return type – int
0 dacă nu e disponibilă copia
1 dacă e disponibilă copia
3. Concepte ale designului
Soluţie. Pe primul nivel de design, începem printr-o funcţie imprumutare care are
doi parametri: titlul cărţii şi numele cititorului.
Dacă funcţia imprumutare din modulul biblioteca ştie despre clasa imprumut, poate
verifica disponibilitatea cărţii, poate crea instanţa imprumut şi poate apela funcţiile
imprumutare pentru a seta valorile instanţei imprumut.
Aşa cum se arată în figura de mai sus, abstractizarea nu e bună. De ce?
4. Măsurarea coeziunii
4.1 “Feliile” unui program (program slices)
Valorile unei variabile într-un program depind de valorile altor variabile.
z = 0;
while x > 0 do
z = z + y;
x = x –1;
end-while
Program slices pot fi obţinute din ambele direcţii. Output slices găsesc
fiecare instrucţiune care afectează valoarea unei ieşiri (output) specificate.
Input slices găsesc fiecare instrucţiune care e afectată de valoarea unui
input specificat.
Soluţie. Vom folosi linie continuă pentru data dependencies şi linie punctată pentru
control dependencies.
Soluţie. În figura de pe pagina următoare din fiecare token către toate tokens care
sunt afectate imediat de valoarea token-ului.
Graf orientat arătând toate dependenţele
Nu sunt superglue tokens, aşadar strong functional cohesion (SFC) este
zero. Din cei 31 tokens, sunt 12 glue tokens, deci weak functional
cohesion este 12/31 sau 0.387.
Sunt patru slices. Zero tokens au adezivitate 100%. Patru tokens sunt în
trei slices, aşa încât au adezivitate 100%. Opt tokens sunt în două slices,
aşa încât au adezivitate 50%. Tokens rămaşi, 19, sunt doar într-un slice,
aşa încât au adezivitate 25%.
(4*0,75+8*0,50+19*0,25)/31=11,25/31=0,363
5. Măsurarea cuplării (coupling)
Dharma (H. Dharma, ‘‘Quantitative Models of Cohesion and Coupling in
Software,’’ Journal of Systems and Software, 29:4, April 1995.) a propus o
metrică cu următoarea listă de situaţii pentru numărare:
di = Numărul de parametri de date de intrare
ci = Numărul de parametri de control de intrare
do = Numărul de parametri de date de ieşire (output data parameters)
co = Numărul de parametri de control de ieşire (output control
parameters)
gd = Numărul de variabile globale folosite ca date
gc = Numărul de variabile globale folsoite ca control
w = Numărul de module apelate (fan-out)
r = Numărul de module apelante a modului fan-in)
inapoi
Software design
- laborator -
Exerciţiul 1. Se dă următorul design. Analizaţi cuplarea, coeziunea,
abstractizarea.
Exerciţiul 2. Se consideră un sistem de recunoaştere facială bazată pe
procesare de imagini. Sistemul va avea o cameră şi intenţionează să
prevină persoanele străine să intre în zonele secrete ale companiei,
prin controlul uşii (blocarea ei). Când o persoană încearcă să
răsucească mânerul uşii, sistemul preia imaginea persoanei şi o
compară cu imaginile din baza de date.
Clasificaţi fiecare dintre următoarele evenimente (i.e. dacă sunt în mediu –
environment sau în sistem şi dacă sunt ascunse sau vizibile:
1. O persoană încearcă să răsucească mânerul uşii.
2. Uşa e deblocată de sistem.
3. Un angajat lasă un străin pe uşă.
4. Un anagajat are un geamăn identic.
5. O imagine are un număr minim de similarităţi pentru algoritmul de
potrivire (matching algorithm).
Exerciţiul 3. Calculaţi functional cohesion metrics (Bieman, Ott) pentru
fragmentul de cod de mai jos. Desenaţi graful orientat.
Exerciţiul 4. Desenaţi scenariile pentru interacţiunea dintre un client care
încearcă să cumpere un anumit CD cu muzică şi vânzătorul din magazin.
Folosiţi state machine model. Pe arce să fie reprezentate evenimentele.
Indicaţie. Mai jos e prezentată cea mai simplă situaţie, când vânzătorul
intră în magazin, nu găseşte CD şi pleacă din magazin. Completaţi şi
variantele celelalte.
Completaţi...
Indicaţii şi soluţii
Soluţie exerciţiul 1.
Cuplare – se doreşte cuplare slabă şi acest design are cuplare slabă,
deoarece clasa college nu are cunoştinţe despre alcătuirea altor clase şi
alte clase nu trebuie să ştie despre college.
Coeziune – e de dorit o coeziune mare şi designul are coeziune mare,
deoarece fiecare clasă lucrează cu propriile atribute.
Abstractizare – designul are o bună abstractizare. De exemplu, metoda
display din college nu include detalii despre metodele lower-level de
afişare.
Soluţie exerciţiul 2.
Unul din primii paşi este generarea unui caz de testare pentru fiecare
tip distinct de ieşire a programului. De exemplu, fiecare mesaj de
eroare trebuie generat. Apoi fiecare caz special ar trebui să aibă un caz
de test. Situaţiile ce ne pot induce în eroare (tricky situations) ar trebuie
testate. Greşelile comune ar trebui testate.
Oarecare:
Mărimi crescătoare (3,4,5 – oarecare)
Isoscel:
a=b şi c mai mare (5,5,8 – isoscel)
a=c şi b mai mare (5,8,5 – isoscel)
b=c şi a mai mare (8,5,5 – isoscel)
a=b şi c mai mică (8,8,5 – isoscel)
a=c şi b mai mică (8,5,8 – isoscel)
b=c şi a mai mică (5,8,8 – isoscel)
Echilateral:
a=b=c (5,5,5 – echilateral)
Nu e triunghi:
a cea mai mare (6,4,2 – nu e triunghi)
b cea mai mare (4,6,2 – nu e triunghi)
c cea mai mare (1,2,3 – nu e triunghi)
Intrări greşite:
1 greşită (-1,2,4 – date greşite)
2 greşite (3,-2,-5 – date greşite)
3 greşite (0,0,0 – date greşite)
Exemplu. Condiţiile din problema triunghiului pot fi : (1) a=b sau a=c
sau b=c, (2) a=b şi b=c, (3) a<b+c şi b<a+c şi c<a+b, (4) a>0 şi b>0 şi
c>0. Coloanele matricii vor reprezenta un subdomeniu. Pentru fiecare
subdomeniu, vom plasa un T în fiecare rând în care condiţia e
adevărată şi F când condiţia e falsă.
3.4 Testare structurală
Testarea structurală se bazează pe structura codului. Cel mai simplu
criteriu este every statement coverage, cunoscut drept C0 coverage.
3.4.1 C0 coverage
Acest criteriu presuppune că fiecare instrucţiune a codului ar trebui
executată se un caz de testare. Abordarea normală pentru obţinerea
C0 coverage este selectarea cazurilor de testare până când un
instrument de acoperire (coverage tool) indică faptul că toate
instrucţiunile din cod au fost executate.
Testul nu este probabil la fel de bun ca primul. Dar obţinem astfel atât
C1 coverage, cât şi C0 coverage.
4. Data flow testing
Este testarea bazată pe fluxul datelor (data flow) într-un program.
Datele curg din locul unde sunt definite până în locul unde sunt folosite.
- Laborator -
A. Întrebări
Obs. Uneori, cea mai simplă soluţie este un proces revizuit decât un nou
sistem.
Se pot lua în calcul diverse surse ale constrângerilor: planificarea (în timp),
return on investment, bugetul pentru muncă şi echipamente, sisteme de
operare, baze de date, software-ul cumpărat, procedurile companiei,
alegerea instrumentelor şi limbajelor, constrângeri legate de personal, de
resurse etc.
Obs. Livrarea unui echipament, conform legii din Anglia, poate fi privită ca
un contract pentru livrarea de bunuri. Livrarea de software poate fi privită ca
oferirea unui serviciu (pentru scrierea software-ului) sau ca acordarea unei
licenţe pentru folosirea software-ului. Aceste disticţii au implicaţii legale.
O altă clasificare a contractelor este d.p.d.v. al modalităţii de plată către
furnizori:
În acest caz trebuie ca analiza cerinţelor să fi avut deja loc. Odată începutî
dezvoltarea, clientul nu-şi poate schimba cerinţele fără să negocieze preţul
contractului.
Avantajele acestei metode sunt:
• Cheltuielile clientului cunoscute;
• Motivarea furnizorului;
Negociated procedure
Sunt situaţii când procesul de ofertare restricţionată nu e cel mai potrivit.
În aceste cazuri, se poate justifica abordarea unui singur furnizor, caz în
care clientul poate fi acuzat de favoritisme.
2. Etape în definitivarea contractelor
Analiza cerinţelor
Înaninte de abordarea furnizorului, trebuie să fie specificate clar cerinţele.
Documentarea cerinţelor trebuie sp aibă, în mod tipic, secţiuni de forma
celor arătate în tabelul de mai jos (un asemenea document se numeşte
uneori operational requirement sau OR):
Cerinţele definesc cu grijă funcţiile care necesită să fie duse la bun sfârşit
de noua aplicaţie şi toate intrările(inputs) şi ieşirile(outputs) necesare pentru
aceste funcţii.
Cerinţele trebuie de asemenea să declare orice standard cu care trebuie să
fie conforme şi sistemele cu care noul sistem să fie compatibil.
Sunt necesare de asemenea cerinţe operaţionale şi de calitate (vezi
capitolul despre Calitatea produselor software).
Forma înţelegerii
De exemplu, e contract de vânzare, de leasing sau licenţă? De asemenea,
poate subiectul unui contract, cum ar fi licenţa pentru utilizare unei aplicaţii
software, poate fi transferată unei terţe părţi?
Proprietarul software-ului
Două chestiuni apar: mai întâi, poate clientul să vândă software-ul la alţii şi
a doua dacă furnizorul poate vinde software-ul la alţii.
Când un software e scris special pentru un client, clientul va dori probabil
să-şi asigure exclusivitatea, de exemplu prin cumpărarea copyright-ului sau
prin specificarea în constract că foloseşte exclusiv software-ul.
Mediul (environment)
Când trebuie instalat echipamentul fizic, trebuie specificată linia de
demarcaţie dintre responsabilităţile furnizorului şi clientului cu privire la
lucruri cum ar fi furnizarea de energie.
Când software-ul e furnizat, trebuie confirmată compatibilitatea cu
hardware-ul existent şi sistemul de operare existent.
Angajamentele clientului
Clientul trebuie să asigure accomodation pentru furnizori şi probabil alte
facilităţi (internet, linie telefonică etc).
Proceduri de acceptare
Un sistem va fi acceptat numai după a trecut de testele de acceptare. O
parte a contractului va specifica detalii ca timpul pe care-l are clientul să
facă testele, deliverables de care depind testele de acceptare şi procedura
pentru semnare atunci când testarea e completată.
Standarde
Clientul poate cere furnizorului dovada că diverse standarde sunt
respectate.
Managementul proiectului şi al calităţii
Contractul trebuie să ceară ca standardele din seria ISO-9000 să fie
îndeplinite, ca şi ISO 12207 (de exemplu).
Planificarea
Oferă o planificare a timpului în care trebuie completate părţile cheie ale
proiectului. Această planificare va obliga atât clientul, cât şi furnizorul. De
exemplu, furnizorul poate si în stare să instaleze software-ul la o dată
convenită numai dacă clientul face platforma hardware disponibilă.
Una dintre primele sarcini este să împărţim activităţile mari în activităţi mai
mici. Acest lucru înseamnă şi găsirea acelor părţi mici ale activităţii.
Înseamnă şi găsirea deliverables şi milestones care se pot utiliza pentru
măsurarea progresului.
Diagrama PERT
A) ALGORITMUL PENTRU TIMPII DE COMPLETARE (completion
times).
1. Pentru fiecare nod, execută pasul 1.1 (până sunt calculaţi toţi timpii de
completare)
1.1 Dacă predecesorii sunt completaţi, atunci ia latest completion time
al predecesorilor şi adaugă timpul cerut pentru acest nod.
2. Nodul cu latest completion time determină earliest completion time
pentru proiect.
Critical path este un set de task-uri care determină cel mai mic timp de
completare (shortest possible completion time).
Soluţie. Din tabel rezultă o relaţie liniară între mărime (size) şi efort (PM).
Panta este 2,4, care reprezintă α. Deoarece linia e dreaptă, β=1. Valoarea
lui γ va fi 0.
C) CONSTRUCTIVE COST MODEL (COCOMO)
COCOMO este formula clasică de estimare a costului bazat pe LOC. A
fost creată de Barry Boehm. Foloseşte mii de instrucţiuni dursă livrate
(thousands delivered source instructions – KDSI) ca unitate a mărimii.
KLOC e echivalent.
Boehm a divizat datele de proiecte istorice în 3 tipuri de proiecte:
a) Application (ex: procesoare de date)
b) Utility programs (ex: compilatoare, analizoare)
c) System programs
Exemplu. Estimările de mai jos sunt date pentru un proiect care costă 3,5
milioane dolari şi a fost completat după 11,5 luni:
Aria totală=11,5*3,5=40,25.
Diferenţa este 2,3 − 3,5 ∗1,5 + 3,1 − 3,5 ∗ 4 + 3,9 − 3,5 ∗ 2,5 + 3,4 − 3,5 ∗ 3,5 = 4,75
Raportul este 40,25/4.75=8,7
Planificarea proiectelor software
- Laborator -
Întrebări
1. De ce trebuie ca WBS să fie arbore?
2. Care e avantajul folosirii diagramelor PERT?
3. Este critical path importantă dacă la proiect lucrează
doar o persoană?
4. Care e importanţa slack time?
5. De ce trebuie ca parametrii pentru estimarea costului
să fie determinaţi din datele companiei?
Problema 1
Creaţi un WBS pentru task-ul vopsirii unei camere.
Presupunem activităţile: planificarea muncii,
cumpărarea proviziilor, vopsirea propriu-zisă,
curăţarea.
Problema 2
Desenaţi diagrama PERT pentru sarcinile problemei 1.
Problema 3
Desenaţi diagrama PERT
pentru sarcinile prezentate
în tabelul alăturat.
Completaţi tabelul arătând
critical path şi slack times.
Problema 4
Estimaţi parametrii de cost pentru mulţimea de date din tabel:
Problema 5
Calculaţi efortul COCOMO, TDEV şi productivitatea pentru
un proiect organic care e estimat la 39800 linii de cod.
Indicaţii şi soluţii
Indicaţii la întrebări
2. Care e avantajul folosirii diagramelor PERT?
Răspuns: Deşi WBS dezvoltă o listă de task-uri, e greu de văzut ce
task-uri vor fi făcute primele şi care task-uri determină final
completion time.
Indicaţie.
Problema 4
Estimaţi parametrii de cost pentru mulţimea
de date din tabel:
Indicaţie.
Indicaţii.