În fiecare an, profesorii trebuie să creeze un nou conținut pentru elevii lor de a citi , de a [615579]

UNIVERSITATEA SPIRU HARET
FACULTATEA DE INGINERIE, INFORMATICA SI GEOGRAFIE

PROGRAMUL DE STUDII: INFORMATICA

APLICATIE WEB DE CREARE A
MATERIALULUI DE ÎNVĂȚARE ȘI
TESTARE

-DRAFT –

Coordonator ști ințific: Prof. Univ. D r. Grigore Albeanu
Absolvent: [anonimizat]

2018

1

Definirea problemei
În fiecare an, profesorii trebuie să creeze un nou conținut pentru elevii lor de a citi , de a
învăța, de a exersa și de a repeta . Ca atare, un profesor va fi mereu în poziția în care să
creeze un conținut. Un profesor care are o singur a materie din domeniul său va trebui să
creeze un suport de curs, va trebui să creeze suportul de laborator sau d e seminar, să
creeze exercițiile pentru el și, în final, să creeze examene și teste. Lucrurile ar fi în regulă
dacă nevoia de a crea conținut s -ar termina după ce profesorul a predat o data cursul si a
reusit sa creeze un continut universal, care nu mai ne cesita modificari .
Un profesor va trebui să actualizeze platforma de curs, să actualizeze platforma
seminarului, să schimbe exercițiile și examenele și, de obicei, un profesor nu este aproape
niciodată în poziția de a avea un singur curs în responsabilită țile sale.
Astfel, este clar că materialele pe care fiecare profesor trebuie să le anuleze anual este
destul de mare. Și impreuna cu modul actual de a crea conținut, se face de stul de lent și
într-un mod anevoios . Tocmai această problemă ne motivează să găsim o soluție mai
bună, una optimizată pentru crearea conținutului și livrarea rapidă a informațiilor de la
profesor la student.
În mod similar, studenții au nevoie de o modalitate mai bună de a comunica între ei în
grupuri și de o modalitate mai bună de a împărtăși informații în grupul respectiv. Elevii
au, de asemenea, nevoie de o modalitate de a intra în contact cu profesorul, de a putea
oferi feedback sau de a solicita informații suplimentare referitoare la un anumit subiect.
În prezent, această prob lemă are o soluție parțială pentru elevii care creează grupuri pe
alte platforme care nu sunt destinate direct studierii individuale . Acest lucru ii poate face
sa-si orienteze atentia spre spre alte puncte de interes, ceea ce ar putea influența negativ
student: [anonimizat] ; a ajuta creatorii de conținut
să își gestioneze mai bine timpul cu ajutorul instrumentului nostru de creare a
conținutului, oferindu -le astfel m ai mult timp pentru a -și indeplini alte sarcini mai
importante. În al doilea rând, sa permita cadrelor didactice să transmită aceste informații
elevilor lor într -o mani eră rapidă și precisă și studenților să intre mai ușor în contact cu
profesorul, să aibă acces mai bun la informație, să comunice mai bine cu col egii lor,
astfel încât să se creeze o modalitate mai flexibilă, mai accesibilă și mai eficientă de
învățare a cunoștințelor , si , pe termen lung, progresare .
În esență, va s ervi ca o platformă bine organizata și bine construită pentru incarcarea
diverselor materiale de catre profesori , combinată cu platforma online, care va permite

2
elevilor să învețe într -un ritm mai rapid și mai plăcut.
Abordări actuale
În prez ent, abordările actua le sunt superficial concepute și de natură imp rovizată dar, din
pacate , acestea sunt depasit e, iar cu resursele de care putem dispune in ziele noastre ar
putea fi realizate la un standard mult mai inalt.
Metodele de creare a conținutului implică în prezent scrierea unei noi structuri de cuvinte
și rescrierea acesteia de fiecare dată când aveți nevoie pentru a crea un nou laborator.
Profesorii care au o înțelegere mai bună a tehnicilor de optimizare vor rezolva, probabil,
un laborator parțial finalizat, un c urs sau un seminar care va funcționa cel mai bine ca un
template improvizat, dar va necesita și alte modificări pe linie.
Soluții precum Astoria sau Moodle pur și simplu nu acoperă părțile pe care le specificăm
în scopul nostru. Modalitățile de facilitare a creării de materiale nu sunt pe aceeiasi
lungime de unda cu domeniul specific de predare și crearea de cursuri, laboratoare și
laboratoare seminare.
Probleme similare apar pentru studenții în care trebuie să creeze diverse tipuri de grupări
în locuri dif erite, unde vor comunica între e i și vor disemina informațiile de care au
nevoie .
O parte din soluția noastră poate fi găsită și în alte locuri, însă întregul pachet pe care il
voi livra nu este implementat și, ca atare, este pe cont propriu pe segmentul de piață.
Părțile disponibile online sunt instrumentele de învățare online care permit studenților să
facă teste, să citească cursuri și chiar să participe la seminarii și laboratoare online. Cu
toate aceste a, piața de creare a conținutului este practic inexistentă și, ca atare, integrarea
sa ca parte a platformei online pentru studenți pare o tranziție naturală.
Actionarii și nevoile acestora

Grupul actionarilor este compus din proprietari, pe de o parte, ș i din partea utilizatorilor,
pe de altă parte. Grupul de utilizatori este compus atât din cadrele didactice care creează
și distribuie conținut, cât și din studenții care utilizează platforma pentru a învăța și a
studia mai eficient. Acestia sunt principal ii actionari . [1]
Astfel, nevoile lor sunt următoarele:
1. Profesori:
a. Un instrument care va ajuta la producerea unor materiale informative si
practice ;
b. Un loc în care pot interacționa cu elevul într -un mod mai ușor și pot inlocui
nevoia de a se întâlni față în față ;

3
c. Un nou mod de impartasire a informațiilor de la profesor la elev, care va
îmbunătăți comunicarea și, ca atare, toate trăsăturile care vin împreună cu
acesta ;
d. O modalitate de a interacționa cu alți profesori, potențial i profesori din
domenii simi lare ajutându -se reciproc pentru a spori productivitatea și
calitatea materialelor pe care le produc.
2. Elevii:
a. O modalitate modernă de a se grupa între ei pentru a -și atinge mai eficient
obiectivele în ceea ce privește învățarea și realizările mai mari și mai
avansate ;
b. O modalitate mai rapidă, mai convenabilă și mai precisă de a comunica cu
profesorul, oferindu -i feedback și, la rândul lor, dacă este nece sar, primesc
sfaturi pentru o anumi a materie ;
c. O modalitate mai bună de a înțelege valorile de grad și modul în care
performanța lor este revizuită, precum și un punct de acces mai bun pentru
instrumentele universitare cum ar fi accesul la secretariat și toate
informațiile potențial utile pentru un student.
3. Proprietar:
a. Această idee și implementarea acesteia este o investiție benefica atunci
când linia este trasată după epuizarea perioadei de amortizare.

Cerințe de sistem

Analiza cerințelor în ingineria sistemelor și ingineria software cuprinde sarcinile care
determină necesitățile sau condițiile care trebuie întâlnite pentru un produs nou sau
modificat, luând în considerare cerințele conflictuale ale diferitelor actionari , analizând,
documentând, validând și gestionând cerințele de software sau de sistem. [2]
Analiza cerințelor este esențială pentru succesul unui sistem sau a unui proiect software.
[3] Cerințele trebuie să fie documentate, aplicabile, măsurabile, verificabi le, trasabile,
legate de nevoile sau oportunitățile identificate ale întreprinderii și definite la un nivel de
detaliu suficient pentru proiectarea sistemului.
Faza cerințelor de sistem poate fi împărțită ușor în trei tipuri diferite de cerințe [4]:
1. Cerinț e nefuncționale
2. Cerințe de interfață
3. Cerințe funcționale

1. Cerințe nefuncționale:

Sunt d e obicei descrise ca si cerințe care specifică criteriile care pot fi utilizate pentru

4
a judeca funcționarea unui sistem, mai degrabă decât comportamente specifice și pot fi
împărțite în continuare în Cerințe de Integritate, Performanță, Securitate, Disponibilit ate
și Compatibilitate. [5]
1. Cerințe de integritate
● În ceea ce privește cerințele de integritate, trebuie să avem grijă la validarea
intrărilor, pentru a preveni eventualele greșeli pe care le -ar putea întâmpina
utilizatorii.

2. Cerințe de performanță
● Când aplicăm analiza Cerințe de performanță, putem observa cu ușurință două
părți care trebuie luate în considerare, timpul de răspuns al serverului și
memoria cache Web.
● Serverul ar trebui să poată răspunde la o solicitare într -un timp mai mic de 0,5
secunde.
● Serverul ar trebui să permită cacherea conținutului web pentru a reduce timpul
de încărcare. [6]

3. Cerinte de disponibili tate
● Cerințele mai introduc două cerințe noi, ore de operare nerestricționate, ceea ce
înseamnă că ar trebui să e xiste zero timp de așteptare.
● Cealaltă restricție este că locația de operare ar trebui să fie nerestricționată,
indiferent de locul de conexi une.

4. Cerințe de securitate
● Nivelurile de acces pentru conectare cer să existe o distincție între un profesor
și un cont de student, precum și toate celelalte tipuri de conturi, distincția
situată la abilitățile pe care le au și impactul respectivelor abilități asupra
datelor și serverului.
● Parolele puternice necesită ca sistemul să impună utilizarea parolelor puternice,
făcând obligatorie utilizarea literelor, numerelor și caracterelor speciale la
crearea unei parole.

5. Cerințe de compatibilitate

● Cerințele de compatibilitate indică faptul că aplicația web ar trebui să
funcționeze practic în același mod în toate browserele web majore (IE, Firefox,
Chrome, Safari, Opera)

5
2. Cerințe privind interfața:

1. Fiecare buton trebuie să aibă un indiciu ;
Fieca re buton trebuie să ofere un indiciu pentru clarificarea scopului acestuia.
2. Faceti o aplicație web
Aplicația trebuie implementată ca o aplicație web, care afișează informații pe
paginile web.

3. Cerințe funcționale:
1. Utilizarea serializarii : Sistemul va utiliza un sistem de mapare a informatiei
tinute minte prin serializare – fisiere cu extensia .ser
2. Utilizarea Servlet urilor : Sistemul va fi implementat și va folosi tehnologia Java
Servlet pentru a răspunde solicitărilor utilizatorilor.
3. Testar ea: Testarea
a. unităților: Toate clasele și funcțiile vor fi verificate separat utilizând
testele unității.
b. Testarea integrării: Sistemul va fi integrat și testat pe un mediu diferit,
eventual cel final.
c. Testarea sistemului: Sistemul va fi testat în ansamblu pentru a verifica
dacă acesta respectă cerințele acestuia.

Abordarea planificată
În dezvoltarea aplicației web, am decis următoarel e principii ca bază comună pe
parcursul procesului de implementare, d e la primul aspect pana la cele finale, vo i urmări
să obțin cât mai bine următoarele principii:
● Portabilitate: Scopul este de a funcționa cât mai bine, indiferent dacă este pe un
monitor mare, un laptop obișnuit, o tabletă sau un smartphone mai vechi, toate
acestea fiind în țintă pentru a le face cât mai ac cesibile posibil.
● Ușurința de utilizare: Am creat fluxul aplicației astfel încât să fie cât mai lină și
mai intuitivă, folosind principiile interacțiunii omului cu calculatoarele.
● Fiabilitate: M-am asigurat că aplicația funcționează prin intermediul bug –
urilor, menținând experiența utilizatorului la cele mai înalte niveluri cât mai
mult posibil, și recuperarea de la bug -uri cât mai bine posibil.
● Performanță: Am optimizat software -ul astfel încât acesta să se miște suficient
de repede pentru ca utilizatorul să se simtă bine acasă folosind u-l.

6
Ca atare, pentru a atinge aceste obiective, am folosit o varietate de instrumente chiar
înainte de a începe dezvoltarea aplicației în sine, pentru a ma asigura că ști u cât mai mult
despre problema țintă, despre soluți a mea, despre analiza mea și nevoile celorlalte părți
ale proiectului:
1. WBS (structura structurii muncii)
Graficul: în managementul de proiect și în ingineria sistemelor, este o
descompunere orientată spre livrare a unui proiect în componente mai mici.
2. Diagr ama Gantt: O diagramă Gantt este un tip de diagrama de bare, dezvoltat
inițial de Karol Adamiecki în 1896 și independent de Henry Gantt în anii 1910,
care ilustrează un program al proiectului. Graficele Gantt ilustrează datele de
început și de terminare a elementelor terminale și a elementelor sumare ale unui
proiect. Elementele terminale și elementele incomplete cuprind structura de
defalcare a proiectului. Diagramele moderne Gantt arată, de asemenea, relațiile de
dependență (de exemplu, rețeaua precedente lor) între activități.
3. Planul de management al riscului: Un plan de gestionare a riscului este un
document pe care un manager de proiect se pregătește să prevadă riscuri, să
evalueze impactul și să definească răspunsurile probleme care pot sa para . De
asem enea, conține o matrice de evaluare a riscurilor. Un risc este "un eveniment
sau o condiție incertă care, dacă apare, are un efect pozitiv sau negativ asupra
obiectivelor unui proiect." Riscul este inerent cu orice proiect, iar managerii de
proiect ar treb ui să evalueze continuu riscurile și să elaboreze planuri de abordare
a acestora. planul de management conține o analiză a riscurilor potențiale, atât cu
impact ridicat, cât și cu impact redus, precum și strategii de atenuare pentru a ajuta
proiectul să ev ite să fie oprit dacă apar p robleme comune și nu reflectă riscurile
reale potențiale ale proiectului .
4. Diagrame SysML: Limbajul de modelare a sistemelor (SysML) este un limbaj de
modelare general pentru aplicațiile de inginerie a sistemelor. Acesta susține
specificarea, analiza, proiectarea, verificarea și validarea unei game largi de
sisteme .
a. Diagrama cazurilor de utilizare: O diagramă a cazurilor de utilizare cea
mai simplă este o reprezentare a interacțiunii unui utilizator cu sistemul și
care descrie sp ecificațiile unui caz de utilizare. O diagramă a cazurilor de
utilizare poate descrie diferitele tipuri de utilizatori ai unui sistem și a
cazului și va fi adesea însoțită și de alte tipuri de diagrame.
b. Diagrama de activități: Schemele de activitate reprez intă reprezentări
grafice ale fluxurilor de lucru ale activităților pas cu pas și ale acțiunilor cu

7
suport pentru alegere, iterație și paralelism concurent . În limba unificată de
modelare, diagramele de activitate sunt destinate să modeleze atât procesele
computaționale, cât și cele organizaționale (de exemplu, fluxurile de lucru).
Schemele de activitate arată fluxul global de control.
c. Diagrama de b locuri de definiție: O diagramă bloc este o diagramă a unui
sistem în care părțile principale sau funcțiile sunt reprezentate de blocuri
conectate prin linii care arată relațiile blocurilor. Acestea sunt foarte des
utilizate în inginerie , în proiectarea hardware, d esignul electronic,
proiectarea de software și diagramele fluxului de proces.
d. Diagrama blocului intern: Diagrama bloc ului intern descrie structura
internă a unui bloc în ceea ce privește proprietățile și conectorii
e. Diagrama de cerințe: Ierarhia de cerințe descrie cerințele conținute într -un
plan de asigurare a calității:
5. Scopul acestui plan de asigurare a calității (QA) este de a stabili obiectivele,
procesele și responsabilitățile necesare implementării unor funcții eficiente de
asigu rare a calității pent ru instrumentul de creare a un ei aplicatii web pentru
cursuri interactive.
6. Analiza cerințelor de sistem: Analiza cerințelor în ingineria sistemelor și ingineria
software cuprinde sarcinile care determină necesitățile sau condițiile pentru a
satisface un pr odus nou sau modificat, luând în considerare cerințele eventual
conflictuale ale diferitelor părți interesate, analizând, documentând, validând și
gestionând software -ul sau cerințele sistemului

Provocări și probleme

Pentru a identifica posibilele probl eme și provocări pe care proiectul nostru le -ar putea
întâmpina, am început o analiză a riscurilor pe scară largă, constând într -un Plan de
management al riscului.
În cadrul acestui plan, vom aborda anumite criterii largi care ar putea apărea în timpul
implementării proiectului nostru .
Ca atare, atunci când analizăm această soluție, am identificat următoarele aspecte
posibile:

8
1. Hacking – partile terte ar putea încerca să acceseze sistemul și să obțină informa ții
private.
2. Proiectul depășește bugetul – Datorită naturii inovatoare a proiectului, studiilor
considerabile implicate și dezvoltării noilor tehnologii, bugetul alocat ar putea fi
depășit.
3. Mediu – nepotrivit : un mediu de lucru prost poate afecta orice angajat, mai ales
unul care lucrează la un proiect mare. Dacă întâlnirile de proiect sunt ținute în tr-un
depozit sau într-un loc care este inoportun fizic și mental și inconfortabil, acest
lucru ar putea afecta cu siguranță grupul dvs.
4. Profesorii pot fi reticenți în utilizarea sistemului – Acest proiect utilizează un
nou mod de a crea materiale de curs, cum ar fi prelegeri și cursuri. Publicul țintă
(profesori și profesori) ar putea să nu fie dis pus să folosească sistemul datorită
naturi i sale noi și inovatoare. În schimb, aceștia se pot alinia la modul tradițional
de a face astfel de materiale.
5. Investitorii taie fonduri le – Investitorii decid să red ucă finanțarea, creând nevoia
de a găsi noi investitori sau de a închide proiect ul ;
6. Estimare greșită a timpului – măsurători timpului nu luate mod corespunzător la
momentul potrivit ceea face procesul mai greu de urmări t
7. Problemele coordonare de sistem asamblare – daca sistemele nu se pun cap la
cap in timpul estimat, creând o întârziere
8. Apare un sistem alternativ – În timpul fazei de dezvoltare a proiectului, pe piață
apare un alt tip de instrument de creație care concurează cu acesta
9. Probleme cu implementarea – Dacă implementarea software -ului nu corespunde
estimărilor riguroas e
10. Modificări legislative – Modificări legislative în timpul proiectului, eventual
modificarea costurilor, schimbarea subvenționării sau prin elaborarea maia
legislației
Planul de Asigurare a CalitățiiPlan
Scop
Scopul acestui Plan de Asigurare a Calității (QA) este de a stabili scopurile, procesele și
responsabilitățile necesare pentru implementarea funcțiilor eficiente d e asigurare a
calității pentru crearea aplicatiei de creeare a materialului de invatare .
Aplicatia de creeare a m aterialului de invatare pentru crearea unui plan interactiv de
asigurare a calității cursului de curs oferă cadrul necesar pentru a asigura o abordare
consecventă a asigurării calității pe tot parcursul ciclului de viață al proiectului. Acesta

9
definește ab ordarea care va fi utilizată de personalul QA pentru a monitoriza și evalua
procesele și produsele de dezvoltare pentru a oferi o perspectivă obiectivă asupra
maturității și calității proiectului [7].

Domeniul de aplicare
Domeniul de aplicare al planului de asigurare a calității se aplică Aplicatiei de Creeare a
Materialului de Invatare dezvoltat de compania mea. Acest document descrie aspecte
legate de asigurarea calității. Publicul țintă al acestui document este următorul: [8]
 Reprezentanți a i clienților
 Grupul de asigurare a calității
 managerului de proiect

Structura și sarcinile echipei de asigurare a calității
Echipa de asigurare a calității este compusă in general din următorii membri: [9]
 Manager de proiect : alocarea resurselor, definirea priorităților, coordonarea
comunicării cu clienții și utilizatorii, păstrarea concentrației echipei asupra
obiectivului principal și încercarea de a menține echipa de proiect axată pe
obiectivul corect. El stabilește de asem enea un set de practici care asigură
integritatea și calitatea artefactelor proiectului.
 Analist al sistemului : Responsabilitatea sa este de a defini cerințele de sistem, de a
conduce și de a coordona modelarea cazurilor de utilizare și de a schița
funcțio nalitatea sistemului.
 Arhitect Software : Responsabilitatea sa este de a conduce și coordona activitățile
tehnice pe tot parcursul proiectului și de a stabili structura generală a arhitecturii
produsului: descompunerea structurii generale, gruparea elemente lor și interfețele
dintre aceste grupări majore.
 Asistent tehnic de proiect : Responsabilitatea lui este de a evalua , planifica, evalua
proiectele in punctele esentiale pe tot parcursul lor
 Dezvoltator : Responsabilitatea sa este de a dezvolta și de a te sta componentele, în
conformitate cu standardele adoptate de proiect, pentru integrarea în subsisteme
mai mari. Atunci când componentele de testare, cum ar fi driverele sau stuburile,
trebuie create pentru a susține testarea, implementatorul este de asemen ea
responsabil pentru dezvoltarea și testarea componentelor de testare și a
subsistemelor corespunzătoare. *10
 Designer de testare : Responsabilitatea sa este de a planifica, proiecta, implementa
și evalua teste le, inclusiv elaborarea proceduri de testare ș i a modelului de testare,
implementarea procedurilor de testare, evaluarea acoperirii încercărilor, rezultatele

10
testelor și eficacitatea testelor și generarea evaluării testului rezumat.
 Tester : Resp onsabilitatea sa este :e
– laborarea si implementarea planurilor de testare;
– Identificarea etapelor, scenariilor si metodelor de testare;
– supravegherea calitatii aplicatiilor;
– Identificarea problemelor intalnite in procesul de testare si prevenirea acestora;
– mentinerea com unicarii cu coordonatorii de proiect;
-recuperarea erorilor, defectele jurnalului și înregistrarea rezultatelor testelor.

Standarde și orientări
Dezvoltarea produsului se realizează pe baza următoarelor standarde și îndrumări:
 Documentația trebuie să fie redactată în limba romana .
 Fiecare document trebuie să fie aprobat de autor (i), liderul echipei responsabile și
de un membru al echipei de asigurare a calității.
 Paradigma de proiectare software care va fi utilizată pentru apli cație este
programarea orientată pe obiecte.
 UML va fi folosit ca tehnică de modelare pentru obiecte orientate pe obiecte.
 Codul sursă va fi comentat la niveluri funcționale și de clasă.
 Codul sursă va fi scris în Java, urmând Convențiile de cod pentru lim bajul de
programare Java ( http://www.oracle.com/technetwork/java/codeconvtoc –
136057.html ).
 Structura paginilor web va fi scrisă în HTML, conform standardelor furnizate de
Consorțiul World Wide Web (W3C)
(http://www.w3.org/standards/techs/html#stds ).
 Structura paginilor web va fi descrisă în CSS, urmând standardele furnizate de
W3C ( http://www.w3.org/standards/techs/html#stds ).
 Conținutul web va fi creat în funcție de dispozitivele mobile, urmând cele mai
bune practici oferite de W3C ( http://www.w3.org/TR/2008/REC -mobile -bp-
20080729/ ).

Metrici
Pentru a oferi control asupra procesului de dezvoltare și asigurarea calității, membrii
echipei QA folosesc următoarele valori, în timpul verificărilor aleatorii:
 Densitatea Bug urilor : Această valoare reprezintă numărul de erori găsite p e
modul. Aceasta face o evaluare a fiabilității produsului și menținerea acestui
număr redus înseamnă că produsul va putea să -și păstreze clienții multumiti ,
satisfăcând așteptările lor pentru funcționa litatea produsului. Acesta poate fi, de
asemenea, utilizat ca un indiciu al modulelor pentru teste , economisind timp,

11
evitând testarea excesivă a modulelor cu densitate scăzută a bugurilor. Această
valoare va fi măsurată de echipa de Asigurare a Calității prin efectuarea testelor
pentru unitățile de măsură și prin numărarea numărului de bug -uri găsite.
 Durata procedurilor : Această valoare reprezintă numărul de linii de cod conținute
într-o procedură. Lungimea trebuie să fie cât mai mică posibil pentru a pro mova
mentenabilitatea produsului. Mai multe linii de cod înseamnă că procedura este
mai puțin lizibilă și mai greu de înțeles și de menținut. Prin faptul că este mai ușor
de întreținut, un produs înseamnă că poate fi modificat și / sau fixat mai ușor în
cazul în care clientul cere anumite modificări. Asigurarea calității va fi efectuata
utilizând un instrument pentru numărarea liniilor de cod conținute în fiecare
procedură a produsului. [11]

Echipa de Asigurare a Calității face un mic raport care conține rezultatele testelor
descrise în jurnalul său și transmite raportul autorului (autorilor) documentului verificat.
Dacă este detectată o încălcare a acestor valori, aceasta trebuie rezolvată, cu excepția
cazului în care Managerul de proiect acordă o autori zație.

Planul de examinare
Vor exista trei prezentări formale pregătite de dezvoltatori și evaluate de echipa de
asigurare a calității la sfârșitul fiecărei etape de dezvoltare.
 Cerințe revizuire
 Responsabilitati : Asistentul tehnic al proiectului sau Inventatorul de revizie
este responsabil de crearea initiala a unui raport de revizuire. El analizează
specificația cerințelor software și prezintă rezultatele activității sale echipei
de dezvoltare. El este, de asemen ea, responsabil pentru păstrarea istoriei
revizuirii. Arhitectul de software și analistul de software sunt responsabili
pentru actualizarea și corectarea revizuirii cerințelor. Aceștia sunt, de
asemenea, responsabili pentru păstrarea istoricului reviziuiri lor.
 Rezolvarea problemelor și acțiunile corective : Acest document trebuie
revizuit de către arhitectul software -ului și analistul de software, care va
adăuga câteva puncte sau va corecta examinarea cerințelor . În cazul unui
dezacord între revizor ii și proprietar, este atribuită o întâlnire s pecială, în
care toate neintelegerile sunt soluționate și se ajunge la un acord asupra
versiunii finale a documentului. [12]
 Vizualizare arhitectură
 Responsabilitati : Asistentul tehnic al Proiectului sau Inventatorul revizuirii
este responsabil de crearea reviziei de arhitectura, care este dedicata
analizei de arhitectura a software -ului. El este, de asemenea, responsabil

12
pentru mentinerea istoriei reviziilor. Arhitect ul de software și analistul de
software sunt responsabili pentru actualizarea și corectarea revizuirii
cerințelor. Aceștia sunt, de asemenea, responsabili pentru păstrarea
istoricului reviziilor.
 Rezolvarea problemelor și acțiunile corective : Această reviz uire este, de
asemenea, corectată de către arhitectul de software și analistul de software,
care fac corecțiile necesare pentru analiza arhitecturii. În cazul unui
dezacord între revizori și proprietar, este atribuită o întâlnire specială, în
care sunt abo rdate toate punctele de litigiu și se ajunge la un acord asupra
versiunii finale a documentului [13].
 Revizuirea Codului
 Responsabilitati
Responsabilul pentru rezvizuire: dezvoltatorul este responsabil de crearea
revizuirii initiale ca fisier text pastra t in sistemul de control sursa. Revizuirea
codurilor este rezultatul corecției codului sursă și verificării conformității cu
cerințele de cod. Alți dezvoltatori sunt, de asemenea, responsabili pentru
adăugarea comentariilor lor la revizuirea codului. Revie werul codului de
revizuire este responsabil pentru corectarea codului în conformitate cu
versiunea finală de revizuire a codului.
 Rezolvarea problemelor și acțiunile corective : Acest document trebuie
revizuit de alți dezvoltatori. În cazul unui dezacord î ntre revizori și
proprietar, se atribuie o întâlnire s pecială, în care toate neintelegerile sunt
soluționate și se ajunge la un acord asupra versiunii finale a documentului.
Pe baza acestui document, codul sursă trebuie să fie modificat de către
proprietarul codului și verificat de către persoana care s e ocupa de
revizuire pentru conformitatea cu versiunea finală de revizuire a codului
[14].

Instrumente
Următoarele instrumente vor fi utilizate pentru dezvoltarea produsului:
 Netbeans IDE pentru dezvoltarea codului sursă, oferind o creștere a productivității
prin utilizarea șabloanelor și a funcț iilor sale orientate spre dezvoltarea aplicațiilor
web și integrarea sa ușoară cu serverul GlassFish.
 Serverul GlassFish ca server pentru implementarea aplicației noastre web, un
server complet compatibil cu cele mai recente tehnologii Java Enterprise Edit ion și
integrat cu Netbeans IDE.
 Adobe Photoshop ca instrument de editare a imaginilor utilizat de designeri de
interfețe, fiind cel mai puternic din acest gen și care permite o productivitate
ridicată.
 Sublime Text Editor pentru dezvoltarea designului (st ructura și aspectul) paginilor

13
web.

Tehnici de testare
Următoarele trei tehnici de testare vor fi utilizate pentru testarea produsului de către
diferiți membri:
 Testarea cutie neagra : Cazurile de test se determină pe baza specificației
componentei testate, fără cunoașterea realizării ei; Uneltele cu cutie neagră se
bazează pe condițiile de intrare și ieșire pentru a evalua testul.
 Testarea cutie albă : Uneltele din cutie albă se bazează pe cunoașterea codului, a
modelului (modelelor) de proiectare sau a altor materiale sursă pentru
implementarea și executarea testelor.
 Testarea ad hoc : presupune utilizarea unor activități nestructurate sau neplanificate
anterior. Această metodă de testare oferă metodologia de testare cu un grad de
variabilitate.

Concluzii
În final, motivul pentru care soluția mea este bună este că o mare parte din întregul
proces al dezvoltării aplicațiilor este cheltuit de cercetarea soluției, de proiectarea
acesteia, de analizarea acesteia și abia apoi de punerea în aplicare a acesteia, de
momentul efectiv în implementare fiind mult mai mică decât întregul proces de
dezvoltare. Analiza complexa întreprinsă de la înțelegerea nevoilor părților interesate la
crearea cerințelor care vor satisface aceste nevoi, la cercetarea instrumentelor și
tehnologiilor care ma vor ajuta să impleme ntez soluția într -un mod cât mai bun posibil,
împreună cu faptul că proiectarea și elaborarea soluției pe parcursul tuturor acestor
procese fac ca produsul să fie o soluție bine concepută, bine gândită și bine implementată,
care va acționa ca un concurent principal pentru orice produse similare aflate pe piață .
Bibliografie

[1] Rabinowitz, P. (2010, iulie 11). Identificarea și analizarea părților interesate și a
intereselor acestora. Descoperit la 1 februarie 2015, de la http://ctb.ku.edu/en/table –
of-contents/participation/encouraging -involvement/identify -stakeholders/main
[2] Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer (2009) .
Cerințe software și sisteme: În practică. New York: McGraw -Hill Professional.
ISBN 0 -07-160547 -9.

14
[3] Hay, David C. (2003). Analiza cerințelor: de la Afișări de afaceri la arhitectură
(prima ediție). Șaua superioară, NJ: Sala Prentice. ISBN 0 -13-0282 28-6.
[4] Laplante, Phil (2009). Cerințe de inginerie pentru software și sisteme (prima
ediție). Redmond, WA: CRC Press. ISBN 1 -4200 -6467 -3.
[5] McConnell, Steve (1996). Dezvoltare Rapidă: Taming Wild Software Schedules
(prima ediție). Redmond, WA: Microsoft Press . ISBN 1 -55615 -900-5.
[6] Nuseibeh, B .; Easterbrook, S. (2000). "Ingineria cerințelor: o foaie de parcurs".
ICSE'00. Lucrările conferinței privind viitorul ingineriei software: 35 -46. doi:
10.1145 / 336,512.336523. ISBN 1 -58113 -253-0. CiteSeerX: 10.1.1.131.31 16.
edita
[7] Andrew Stellman și Jennifer Greene (2005). Managementul aplicațiilor software
aplicat. Cambridge, MA: O'Reilly Media. ISBN 0 -596-00948 -8.
[8] Karl Wiegers și Joy Beatty (2013). Cerințe software (ediția a treia). Redmond, WA:
Microsoft Press. ISBN 978 -0-7356 -7966 -5.
[9] Schlager, J. (iulie 1956). "Ingineria sistemelor: cheia dezvoltării moderne".
Tranzacțiile IRE EM -3 (3): 64 -66. doi: 10.1109 / IRET -EM.1956.5007383.
[10] Arthur D. Hall (1962). O metodologie pentru ingineria sistemelor. Van Nostrand
Reinhold. IS BN 0 -442-03046 -0.
[11] Arthur D. Hall (1962). O metodologie pentru ingineria sistemelor. Van Nostrand
Reinhold. ISBN 0 -442-03046 -0.
[12] Andrew Patrick Sage (1992). Ingineria Sistemelor. Wiley IEEE. ISBN 0 -471-
53639 -3.

Lab Document Creation Activity Diagram SEQ
Lab_Document_Creation_Activity_Diagram \* ARABIC 1