Informatică economică [308242]

[anonimizat]: [anonimizat]-[anonimizat]. univ. dr. Florina COVACI

2020

[anonimizat]: [anonimizat]-[anonimizat]. univ. dr. Florina COVACI

2020

[anonimizat] o creștere a eficienței în realizarea lor prin intermediul sistemelor automatizate. [anonimizat], astfel soluțiile web fiind cele optime. Dezvoltarea acestor aplicații prezintă o [anonimizat].

[anonimizat]. [anonimizat]. Astfel, aplicațiile web redau totalitatea activităților pe care le realizează un utilizator în momentul în care deschide un browser(ex: Facebook, Gmail, Whatsapp), deci care nu necesită o instalare.

[anonimizat]. [anonimizat] a echipamentelor, existând astfel posibilitatea apariției anumitor inconveniente legate de mărimile disponibile sau poate chiar inexistența punctelor de închiriere.

[anonimizat]. [anonimizat], cât și de eventuali antreprenori care ar putea avea astfel de afaceri în anumite orașe. [anonimizat] a mai fi nevoie de alte formalități.

CAPITOLUL 1. [anonimizat], cerințele acestuia și domeniul problemei în care este prezentat. În procesul de dezvoltare al unui sistem informatic e [anonimizat], condițiile pe care le are în legătură cu funcționalitățile aplicației și ce dorește să permită aceasta.

1.1 Identificarea și descrierea problemei

Ideea realizării acestei aplicații web a pornit de la observarea lipsei unui sistem bine formulat pentru închirierea online a echipamentelor sportive(schiuri, clăpari, snowboard, sanie etc.) necesare vacanțelor programate într-o zonă montană. [anonimizat], echipamentele fiind asigurate în urma rezervării. Astfel, organizațiile care ar putea utiliza această aplicație ar fi pârtiile care au un centru de închiriere sau anumite afaceri care ar putea să se ocupe de acest domeniu.

În opinia mea, principalul motiv pentru care nu se pune accent pe dezvoltarea unui astfel de sistem ar putea fi lipsa interesului pentru această ramură din afacere, conducerea axându-se mai mult pe întreținerea pârtiei și a mecanismelor de urcare. Astfel, o strategie pentru rezolvarea acestei probleme ar putea fi informarea administratorilor în legătură cu posibilitatea creării unei aplicații de acest tip.

Obiectivele generale legate de aplicația prezentă ar putea fi informarea cu privire la necesitatea sistemului, crearea unei baze de date care să conțină informațiile legate de echipamente și închirieri și obținerea unor resurse financiare alocate special pentru aceasta. Prin urmare, în urma atingerii obiectivelor și realizării aplicației, firma va avea posibilitatea de a-și gestiona mai bine rezervările și evidența echipamentelor într-un mod eficient și personalizat nevoilor acestora.

1.1.1 Motivație

În realizarea unui sistem informatic trebuie să se urmărească automatizarea elementelor organizatorice din societatea umană, gestionând informațiile utile specifice factorilor de decizie. Astfel, scopul acestui sistem este de a exista posibilitatea rezervării online a echipamentelor pentru sporturile montane de iarnă. Câteva din motivele pentru care am ales această temă sunt experiențele de care am avut parte în momentul în care voiam să închiriez echipamente sportive. O problemă des întâlnită este legată de produsele existente în stoc sau de timpul de așteptare pentru procurarea produselor. Alocarea timpului pentru gestiunea unei baze de date a echipamentelor și rezervărilor ar putea aduce avantaje atât pentru pentru administratori cât și pentru clienți, aceștia urmând să fie mai mulțumiți de serviciile primite.

Contribuția aplicației la organizație ar putea să fie evidența mai clară a profitului obținut din închirierea echipamentelor, acest lucru fiind datorat bazei de date care ar fi mai bine organizată. Datorită faptului că închirierile, echipamentele și cerințele clienților nu sunt înregistrate, impactul acestui sistem ar putea fi unul destul de puternic și eficient. Câteva exemple ale unui posibil impact ar putea fi reducerea timpului în activitățile de la punctul de închiriere, iar împreună cu acesta și creșterea eficienței procesului acțiunilor respective.

În urma examinării motivației de mai sus am formulat câteva cauze pentru realizarea unui sistem de rezervare online a echipamentelor pentru sporturile montane de iarnă. Pentru a le prezenta voi folosi diagrama Fishbone(diagrama os de pește).

Figura 1.1 Diagrama Fishbone

Aceasta se utilizeză pentru a identifica cauzele care stau la baza rezolvării problemei principale care este notată în triunghi, acesta reprezentând capul peștelui. Înșiruirea cauzelor de nivel I sunt redate pe schelet, existând posibilitatea numirii și cauzelor de nivel II sau III prin ramificații. Pornind de la ilustrarea figurii 1.1, observăm problema care trebuie rezolvată și cauzele de nivel I: lipsa posibilităților financiare, lipsa de interes din partea administratorilor, lipsa ținerii evidenței produselor(a unei baze de date) și lipsa timpului alocat pentru realizarea și întreținerea unui astfel de sistem. Realizând o analiza particulară pentru fiecare, observăm că există și cauze de nivel II. Astfel, lipsa de interes este urmarea faptului că nu s-a observat necesitatea unui asemenea sistem, motiv pentru care nu există nicio evoluție în realizarea acestuia. Lipsa posibilităților financiare are ca și cauze anterioare nealocarea bugetului și lipsa personalului care să fie responsabil de mentenanță. Posibil ca mulți investitori să nu acorde o importanță ridicată pentru sisteme de acest tip, astfel nealocând resurse financiare necesare. Totodată, pentru ca această idee să funcționeze este nevoie de resursă umană care să investească în această aplicație și care să primească salar, însă acestea nu sunt prioritare pentru afacerea pârtiei. Identificarea dificilă a datelor și lipsa unei baze de date care să vizeze clienții și rezervările realizate se concretizează în lipsa unei evidențe concrete a datelor care circulă în departamentul respectiv. Lipsa timpului alocat este o altă cauză esențială care este rezultată din durata prea mare pentru gestionarea bazei de date și realizarea mentenanței.

În cele ce urmează voi prezenta obiectivele care ar trebui atinse pentru realizarea unui sistem de rezervare online. Problema principală este lipsa unui sistem de închiriere online a echipamentelor în domeniile schiabile, sau îmbunătățirea lui, dacă acesta există. Formularea scopului și a obiectivelor care trebuie realizate într-un proiect este foarte importantă, existând o diferență între cele două. Scopul reprezintă o intenție formulată pentru viitorul îndepărtat, fără a exista o limită clară de timp. Obiectivele sunt formulate astfel încât prin îndeplinirea lor să fie atins, în final, scopul. Ele trebuie să fie clare, concrete și este de preferat să respecte principiul SMART(specific, măsurabil, accesibil, relevant, încadrarea în timp). După acest șablon am formulat diagrama de descompunere a obiectivelor după cum urmează:

Figura 1.2 Diagrama obiectivelor

Așadar, obiectivele principale formulate pentru îndeplinirea scopului sunt: informarea administrației cu privire la necesitatea sistemului, obținerea de resurse financiare pentru realizarea și întreținerea acestuia, crearea unei baze de date și includerea unor funcționalități utile în aplicație. Obținerea resurselor financiare s-ar putea realiza fie prin atragerea investitorilor, fie prin reorganizarea bugetului afacerii și alocarea unei anumite sume pentru acest sistem. De asemenea, în includerea unor funcționalități utile, s-au luat în considerare realizarea funcționalității de logare sau crearea drepturilor pentru administrator, aceștia având acces eficient la modificarea bazei de date.

1.1.2 Context

Orice proiect poate să fie privit din mai multe puncte de vedere, fiecare perspectivă fiind o viziune diferită asupra acestuia. Datorită acestui fapt, persoana care face analiza sistemului trebuie să urmărească negocierea, documentarea și validarea completă a cerințelor. Aceasta are ca obiective tratarea tuturor surselor cerințelor într-un mod bine organizat. Astfel, contextul realizării sistemului ales îl voi prezenta cu ajutorul metodologiei fațetelor, aceasta cuprinzând 4 fațete și anume:

Fațeta subiect;

Fațeta utilizare;

Fațeta IT;

Fațeta dezvoltare;

Fațeta subiect se referă la obiectele (tangibile sau intangibile) care apar în sistem și la semnificația acestora. De asemenea, această fațetă tratează evenimentele din contextul sistemului care sunt relevante pentru acesta și documentarea factorilor care determină reprezentarea datelor. Astfel, scopul principal al acestei aplicații este de a realiza un sistem pentru închirierea online a echipamentelor pentru sporturile montane de iarnă. Ea poate fi utilizată de către administratorii pârtiilor de schi care își doresc să aibă o evidență clară asupra echipamentelor și clienților. Obiectele cele mai relevante pentru sistem sunt stakeholderii. Aceștia reprezintă o persoană fizică sau o organizație care prezintă interes pentru un anumit proiect. Ei pot să provină atât din interiorul, cât și din afara organizației. Pentru acest sistem, stakeholderii sunt reprezentați de clienții pârtiei care nu dispun de echipamente proprii și vor să închirieze, aceștia fiind nevoiți să se logheze în aplicație pentru introducerea datelor personale necesare rezervării. Totodată, administratorii pârtiei sunt incluși în categoria stakeholderilor, ei având drept de logare, dar și acces la baza de date pentru a realiza anumite operații cu aceasta. Baza de date are un rol esențial în acest sistem, ea stocând toate informațiile afacerii, necesare închirierii, dar și datele introduse de utilizatorii aplicației.

Fațeta utilizare este o dinamică a fiecărui utilizator. Orice sistem orientat software este folosit de către utilizatorii săi cu scopul de a atinge un anumit set de obiective. Această fațetă include informații legate de cine utilizează sistemul(obiectivele care sunt urmărite de utilizatori, fluxurile de date, caracteristicile comportamentului pe fiecare grup de utilizator, politicile de acces la anumite resurse în funcție de rolul acestora). Așadar, La deschiderea aplicației, prima pagina va fi cea de autentificare. În cazul în care utilizatorul are deja un cont poate să realizeze autentificarea, iar în caz contrar acesta își va crea unul nou. Utilizatorul poate să fie administratorul site-ului sau un client care își dorește să beneficieze de aplicație. În funcție de acest lucru, aplicația îi va da drepturi de admin sau de client, acestea fiind diferite pentru fiecare caz. Administratorul va avea acces la baza de date de unde va putea realiza operații de ștergere, adăugare, modificare, vizualizare, în funcție de stocul echipamentelor. Acesta va putea gestiona datele astfel încât clientul să știe ce produse sunt disponibile. Clientul nu va avea acces la baza de date, ci doar va vedea lista de produse disponibile. Vor apărea sporturile pe care le va putea practica împreună cu lista de prețuri/oferte în funcție de echipament și durata de închiriere.

Fațeta IT prezintă tehnologiile folosite și justificarea pe scurt a acestora. Un sistem poate să fie instalat într-un context în care există deja o anumită rețea de calculatoare cu sisteme de operare, anumite programe aflate în exploatare. Această fațetă cuprinde mulțimea aspectelor aflate în legătură cu tehnica de calcul și a tehnologiilor software care există deja în context sau sunt impuse prin anumite politici, reglementări și legi. Astfel, pentru implementarea aplicației prezente s-a utilizat Microsoft Visual Studio 2019, limbajul C# , acesta aparținând framework-ului .NET, fiind dezvoltat după modelul arhitectural model-view-controller(MVC) și Application Programming Interface(API). Legătura cu baza de date este realizată prin intermediul SQL Server. Microsoft Visual Studio 2019 este IDE(Integrates Development Environment), mai exact un mediu de dezvoltare realizat de Microsoft. Acesta suportă limbajul de programare C#, el fiind un limbah funcțional, imperativ, orientat obiect care este dedicat framework-ului .NET. Acest framework este unul pe partea de server într-o aplicație web, fiind utilizat la crearea paginilor web dinamice. Amintind și de SQL Server, acesta este un sistem pentru gestiunea bazei de date relațional, fiind dezvoltat de către Microsoft.

Fațeta dezvoltare documentează toate aspectele care contribuie la dezvoltarea(ciclul de viață al aplicației) viitoare a sistemului. Această aplicație este realizată după metodologia Agile, ea fiind dezvoltată interativ și incremental, schimbările fiind încurajate indiferent în ce stadiu se află proiectul. Progresul aplicației presupune ca problema principală să fie divizată în alte subprobleme mai mici, fiecare având sarcina de a furniza o versiune funcțională a software-ului. Din cadrul subproblemelor fac parte următoarele funcțonalități: analiza cerințelor, proiectarea, planificarea, codificarea, testarea, documentarea. Modelul Agile este ușor de utilizat, fiind adaptabil la posibilele schimbări ce pot apărea pe parcursul dezvoltării sistemului.

1.2 Cerințe de sistem

1.2.1 Surse de cerințe

În realizarea unui sistem este foarte important ca cerințele să fie clar formulate pentru a putea fi înțelese de către dezvoltatori. Dacă cerințele sunt definite corespunzător, dezvoltarea sistemului va fi ușor de realizat și finalizat. Astfel, sursa principală de cerințe este reprezentată de stakeholderi, datorită faptului că ei vor beneficia de rezultatul final, cunoscând bine nevoile organizației din care fac parte. Altă categorie care face parte din sursa de cerințe este reprezentată de domeniul în care aplicația va opera. Acesta reprezintă sursa din care vor fi preluate cerințele specifice domeniului, precum maniere de prezentare ale acestora, aranjarea privind confidențialitatea informațiilor sau eliminarea informației redundante. Domeniul aplicației este cel al promovării, rezervării și prezentării echipamentelor. Deoarece sistemul constă într-o aplicație web pentru rezervarea online a echipamentelor pentru sporturile montane de iarnă, el trebuie să urmărească anumite cerințe specifice domeniului din care face parte.

1.2.2 Elicitația cerințelor

Metodele de elicitație a sistemului reprezintă anumite tehnici de extragere și înțelegere a necesităților stakeholderilor. Prin elicitația cerințelor se indică faptul că obiectivele nu pot să fie atinse doar prin intervievarea clienților, ci ar fi util să existe și alte metode prin care necesitățile aplicației să fie colectate. Astfel, pe lângă interviuri, amintim de chestionare, brainstorming, workshop-uri, cazuri de utilizare, metodele de business, observații ale utilizatorilor. Urmează procesul de elicitație prin care cerințele trebuie să fie colectate, ca mai apoi ele să poată fi indicate, analizate sau ajustate.

Stakeholderii, după cum am menționat și în subcapitolul “Context”, reprezintă toate părțile care au legătură cu afacerea respectivă și sunt afectați într-un mod direct sau indirect în urma realizării sistemului. În acest proiect, mulțimea stakeholderilor este constituită din: conducerea firmei care va gestiona baza de date și clienții care vor rezerva echipamentele. Pentru a defini nevoile acestora cu privire la acest sistem am folosit următoarele metode de elicitație: metoda chestionarului, metoda brainstorming-ului și metoda cazurilor de utilizare.

Chestionarul este una dintre cele mai folosite metode de cercetare și este compus dintr-o serie de întrebări, fiind utilizat cu scopul de a colecta cât mai multe informații de la diferiți indivizi. Această metodă este utilizată pe larg, având un caracter științific datorită statisticii realizate în urma rezultatelor care sunt ușor de interpretat. Chestionarele sunt ideale pentru piețele de produse unde problemele sunt bine definite, deoarece întrebările sunt formulate clar și concis. Astfel, pentru a obține rezultate concludente, am aplicat această metodă la 100 de persoane cu scopul de identifica principalele nemulțumiri și diferite dorințe în legătură cu un sistem de rezervare online pentru sporturile montane de iarnă. Întrebările au fost legate, la început, de datele persoanelor, iar apoi am încercat să ating anumite puncte cu privire la proiectul realizat, cum ar fi așteptările acestora, importanța realizării unei astfel de aplicații. În anexa 1 am atașat chestionarul complet. În urma chestionării persoanelor, am constatat faptul că 80% dintre aceștia practică cel puțin un sport montan de iarnă, dintre care 45% preferă să închirieze echipamentele în loc să le cumpere. În continuare, am abordat problemele legate de realizarea unei aplicații pentru rezervarea online a echipamentelor și am ajuns la concluzia că majoritatea indivizilor nu au sesizat importanța unui astfel de sistem. O altă problemă ar fi legată de faptul că mentenanța sistemului ocupă o durată mare de timp, aceasta fiind sesizată de 60% dintre cei care au răspuns chetionarului. La o diferență mică este nealocarea din bugetul afacerii pentru acest proiect, urmată de lipsa unei baze de date a clienților si durata prea mare pentru gestionarea acestei baze de date.

Brainstoming-ul reprezintă o modalitate de a stimula creativitatea oamenilor în legătură cu rezolvarea anumitor probleme pe care le întâmpinăm. Este o practică prin care fiecare persoană prezentă este nevoită să își pună imaginația la încercare și să aducă posibile soluții, mergându-se pe principiul că nicio idee nu este greșită. Câteva reguli într-o ședință de brainstorming sunt: stabilirea și afirmarea clară a obiectivelor care sunt vizate, trebuie să fie urmărită cantitatea ideilor, nu calitatea, interzicerea criticii, generarea maximului de idei, stimularea imaginației. Primul pas care trebuie îndeplinit pentru reușita ședinței este pregătirea acesteia prin punerea la dispoziție a unor pachete de post-ituri și carioci pentru fiecare participant. Următorul pas este colectarea ideilor. Participanții își scriu idei pe post-it, își afirmă ideea în fața celorlalți, iar moderatorul o posteaza pe tablă. Urmează ajustarea ideilor prin combinarea celor asemănătoare și eliminarea celor exagerate. Ultimul pas în derularea ședinței este organizarea ideilor după modelul FURPS(funcționalități și cele patru criterii de calitate) (Ciaca, 2020).Astfel, pentru aplicația mea am realizat o ședință de brainstorming cu administratorii unei pârtii de schi pentru a descoperi mai multe detalii legate de perspectiva lor asupra unui astfel de sistem. În urma întâlnirii am ajuns la aceeași concluzie ca la chestionar, și anume că nu s-a sesizat nevoia unei astfel de aplicații în afacerea lor. De asemenea, au adus câteva idei pentru cum ar putea funcționa aplicația, unele dintre acestea fiind creearea unei baze de date pentru echipamente și clienți, posibilitatea de logare cu datele personale și oferirea clienților unei garanții cu privire la faptul că le sunt rezervate echipamentele.

În urma celor două metode de elicitație, am realizat clasificarea cauzelor care împiedică realizarea unei aplicații pentru rezervarea online a echipamentelor în funcție de gravitatea lor, fiind reprezentate prin intermediul diagramei Pareto. Așadar, problemele sunt redate de la stânga la dreapta pe axa X din grafic, cea de lângă origine fiind cea mai importantă.

Diagrama Pareto este o diagramă de coloane constituită dintr-o axă orizontală pe care sunt ilustrate criteriile reprezentative și o axa verticală care redă valorile numerice de referință ale acestora. Pe același grafic mai este ilustrată o curbă concavă care reprezintă procentajul cumulate al coloanelor. Această digramă este un instrument semnificativ pentru luarea unei decizii, fiind utilizată pentru a îmbunătății calitatea proceselor realizate.

Astfel, se poate observa că pentru implementarea unei aplicații de închiriere online a echipamentelor pentru sporturile montane de iarnă, problema principală este neconștientizarea necesității unui astfel de sistem, lipsa alocării timpului pentru mentenanța aplicației și nealocarea din bugetul afacerii pentru domeniul de închiriere al echipamentelor.

Figura 1.3 Diagrama Pareto

Modelul cazurilor de utilizare reprezintă o altă metodă de elicitație prin care se poate satisface direct necesitatea unui stakeholder. Acest model caracterizează trăsăturile de sistem, contribuie la urmărirea, prioritizarea, evaluarea și administrarea trăsăturilor. Pe baza lor se realizează identificarea scenariilor de utilizare, compunerea cazurilor de utilizare, corelarea cazurilor de utilizare și documentarea finală a scenariilor și cazurilor de utilizare. De asemenea, modelul use-case asigură o descriere completă a funcționalităților sistemului, arată comportamentul sistemului în context, poate servi ca și contract între client și dezvoltatori și este un input pentru activitățile ulterioare din ciclul de viață al produsului. Fiecare caz de utilizare este un set de secvențe de interacțiuni între actori și sistem și definește o secvență de acțiuni pe care sistemul le realizează pentru ca actorul să primească un efect util. Modelul poate să fie abordat printr-o dezbatere între analist și client în care să se decidă ce anume va efectua sistemul, ce interfețe trebuie să ofere acesta, dar și cine va interacționa cu sistemul. Astfel, am identificat actorii prin răspunsul la întrebările următoare:

Cui îi sunt utile informațiile prezente în sistem?

Cine este responsabil pentru gestionarea bazei de date?

Cine utilizează sistemul?

Pentru o imagine mai clară în legătură cu actorii am realizat acest tabel care conține actorii,

descrierea lor și rolul acestora:

Tabelul 1.1 Actori și roluri sistem general

După cum am mai specificat și se poate observa în urma tabelului, stakeholderii acestei aplicații sunt reprezentați de către administratorii punctului de închiriere al echipamentelor și clienții care doresc să își rezerve online echipamentele. Sistemul le poate aduce amândurora beneficii, dezavantaje sau asumarea anumitor riscuri. Beneficiile care pot să apară în partea celor care administrează sistemul ar putea să fie creșterea numărului de clienți pe pârtie, deoarece aceștia vor știi că în acel loc își pot asigura echipamentele, implicit un alt beneficiu fiind creșterea profitului firmei. Pe de altă parte, aici ar putea apărea și un dezavantaj, și anume creșterea cheltuielilor, lucru datorat și de faptul că pârtiile funcționează doar în sezonul rece în timpul anului. Riscurile pe care administratorii unui astfel de sistem le pot confrunta ar fi o posibilă lipsă a clienților și imposibilitatea de a acoperi cheltuielile create în urma acestui sistem. În ceea ce privește clienții, beneficiul principal în urma utilizării acestei aplicații ar fi faptul că au asigurate echipamentele neceasare pentru activitatea planificată, iar aplicația este convenabilă din toate punctele de vedere. Dezavantajele clienților sunt reprezentate de faptul că ei nu vor putea proba echipamentele respective până în momentul în care ajung la punctul de închiriere. Riscurile posibile pentru clienți ar putea să fie gestionarea eronată a bazei de date de către administratori, iar echipamentele respective să fie deja rezervate de către alte persoane.

Figura 1.4 Diagrama Use-case sistem general

Actorii prezentați sunt asociați cu anumite funcționalități în cadrul sistemului, iar pentru reprezentarea acestora am realizat diagrama use-case de mai sus pentru a concretiza sistemul și contextul din care face parte. Contextul este compus din aria cu care aplicația are tangențe. Această diagramă poartă numele de diagrama cazurilor de utilizare și prezintă o colecție de cazuri de utilizare și actori care:

Oferă o descriere generală a modului în care va fi utilizat sistemul;

Furnizează o privire de ansamblu a funcționalităților ce se doresc a fi oferite de sistem;

Arată cum interacționează sistemul cu unul sau mai mulți actori li asigură că sstemul va produce ceea ce s-a dorit (Cockburn, 2001)

Această diagramă este compusă din următoarele elemente:

Omuleții de lângă dreptunghi reprezintă actorii, sub el fiind denumirea acestuia;

Ovalele din interiorul dreptunghiului reprezintă cazurile de utilizare, conținând numele acestora;

Săgețile reprezintă asocierea între actor și cazul de utilizare.

În diagrama de față sunt redactate operațiunile de bază pe care actorul care utilizează aplicația dorește să le realizeze în sistem. Clientul și administratorul reprezintă contextul sistemului, iar sistemul în sine este constituit de funcționalitățile de față. Clientul are posibilitatea de a se autentifica, de a accesa echipamentele din baza de date și de a le vizualiza, după care poate să realizeze o rezervare dacă dorește. Administratorul are în comun cu clientul faptul că se poate loga în aplicație și să vizualizeze baza de date, însă el are în plus dreptul de a gestiona această bază de date prin intermediul operațiilor CRUD.

În continuare, am realizat diagrama use-case și un tabel cu actori pentru o anumită funcționalitate și anume realizarea rezervării.

Tabelul 1.2 Actori și roluri rezervare

Acest tabel este asemănător cu cel de mai sus, însă este realizat doar pentru funcționalitatea de rezervare a echipamentului. Astfel, se vede o viziune asupra acelorași stakeholderi (clienți și administrator),însă doar cu caracteristicile specifice acestei funcționalități.

Figura 1.5 Diagrama Use-case pentru rezervare

La fel ca și la tabel, această diagramă afișează operațiunile posibile în procesul de rezervare a echipamentelor. Astfel, se poate observa faptul că administratorul poate vizualiza informațiile introduse de către client, poate gestiona baza de date, iar aici se include operațiunea editării acesteia. De cealaltă parte a diagramei este clientul care în această situație poate să vizualizeze disponibilitatea echipamentului și să realizeze rezervarea prim introducerea anumitor date.

Datorită faptului că orice caz de utilizare cuprinde unul sau mai multe scenarii de utilizare, în continuare voi realiza tabelul cu scenariile de utilizare atât pentru sistemul întreg, cât și pentru funcționalitatea de rezervare a echipamentelor. Un scenariu de utilizare este o decsriere a unei metode potențiale de utilizare a sistemului. Acesta este o secvență specifică unei acțiuni, fiind un mediator între abstract și concret. Astfel, sunt prezentate toate câmpurile care pot intra într-un scenariu, realizând o ierarhie în importanța funcționalităților.

Tabelul 1.3 Scenariu de utilizare pentru sistem

Tabelul 1.4 Scenariu de utilizare pentru rezervare

Aceste tabele specifică actorii implicați pentru fiecare pas din interacțiune; interacțiunea între actori, dar și între ei și alte persoane care nu interacționează direct cu sistemul.

1.2.3 Documentarea cerințelor

În acest subcapitol sunt prezentate cerințele proiectului pe categorii și anume: funcționale, non-funcționale și calitative. Într-un proiect se regăsesc cerințe software și de sistem, care la rândul lor prezintă mai multe metode pentru a putea fi documentate. Nu este recomandată aplicarea unei singure metode, deoarece aceasta nu este suficientă pentru reprezentarea tuturor cerințelor existente. Astfel, ar trebui utilizată o abordare mai cuprinzătoare. În viața de zi cu zi, într-o echipă pot interveni mai mulți factori care ar putea împiedica realizarea cu succes al sistemului. Identificarea și înțelegerea cerințelor ar putea fi eronate din cauza anumitor factori legați de natura umană, deoarece stakeholderii își pot schimba ușor viziunea asupra sistemului sau nu reușesc mereu să exprime exact ceea ce ar vrea. De asemenea, analiștii pot percepe într-un mod diferit informațiile primite. Datorită acestui lucru, am încercat să surprind extragerea majiorității cerințelor prin descoperirea informațiilor necesare.

Cerințele funcționale reprezintă afirmații despre funcționalități pe care sistemul ar trebui să le efectueze, cum ar trebui să răspundă la diferite inputuri sau în diverse situații, analistul căutând multiple scenarii de utilizare. Astfel, cerințele funcționale pentru acest sistem sunt:

Aplicația trebuie să permită ca utilizatroul să se poată loga în aplicație;

Aplicația trebuie să permită clientului să vizualizeze datele din cadrul acesteia pe baza unor anumite criterii;

Aplicația trebuie să permită administratorului să modifice baza de date;

Aplicația trebuie să ofere utilizatorilor mai multe funcționalități.

Cerințele non-funcționale reprezintă o formă a cerințelor funcționale, însă formulate parțial sau insuficient. Ele sunt constrângeri ale serviciilor și ale anumitor funcții oferite de sistem. Aceste cerințe sunt mai stricte decât cele funcționale, deoarece prezintă riscul nefinalizării aplicației. Dacă acestea nu sunt finalizate, sistemul nu va putea atinge scopul pentru care a fost proiectat. (Ciaca, 2020)

Cerințele calitative sunt definite prin atribute calitative ale sistemului sau a unor componente ale sale. Acestea au legătură cu modul în care sistemul își va realiza funcționalitățile. Pentru acest sistem, cerințele calitativa sunt:

Aplicația trebuie să aibă o interfață plăcută utilizatorului, care să fie utlizată cu ușurință;

Aplicația trebuie să ofere serviciile cerute în orice moment;

Aplicația trebuie să fie eficientă în realizarea rezervărilor;

Realizarea unei rezervări trebuie să fie permisă într-un mod facil.

O altă abordare pentru documentarea cerințelor am creat-o prin intermediul diagramei de secvență, diagramei de activități și a diagramei de stări. Diagrama de mai jos este cea de secvență. Aceasta pune accentul pe aspectul temporal, ordonând mesajele în timp și reflectă foarte bine interacțiunea exactă dintre actori și sistem.

Figura 1.6 Diagrama de secvență

Diagrama de secvență ilustrată mai sus prezintă maparea legăturii dintre acțiunile utilizatorului și aplicație în diferite faze, între aceștia existând mereu un schimb de informații. La început, este reprezentat procesul în care utilizatorul se autentifică cu succes la aplicație și navighează în meniul principal. Mai departe, este redată fiecare etapă prin care trece utilizatorul și răspunsul aplicației la aceasta. După navigarea în pagina principală, utilizatorul caută produsul dorit. După ce îl găsește, va putea realiza rezervarea în formularul special pentru această funcționalitate. Utilizatorul își completează datele, iar la final primește o notificare pentru confirmarea funcționalității efectuate.

O prismă prin care poate să fie realizată documentarea cerințelor este cea a perspectivei funcționale și a perspectivei datelor. Cea funcțională arată interacțiunile dintre actori și sistem, procese și activități, obiective urmărite, fluxuri. Persepectiva datelor indică posibilitatea prin care datele se produc sau se consumă. În cadrul primei perspective se poate înacadra și diagrama de activități realizată mai jos.

Figura 1.7 Diagrama de activități

Diagrama de activități prezintă activitățile care sunt implicate în proiect și fluxul acestora. Este utilizată în cazul în care dorim modelarea unui anumit pas în executarea unei proceduri. Pe baza diagramei de secvență, detaliez o anumită funcționalitate pe care o realizează cele două părți ale proiectului. Simbolurile utlizate sunt cele două cercuri care reprezintă punctul de intrare, respectiv cel de ieșire din aplicație, romburile de decizie, dreptunghiurile cu colțurile rotunjite și textul din interiorul acestora care indică expresia unei acțiuni, aceasta fiind unică în cadrul diagramei. Astfel, diagrama prezentă reflectă funcționaliteta de modificare a bazei de date de către administrator. Dacă autentificarea a fost realizată cu succes, atunci utilizatorul este redirecționat pe pagina principală, iar în caz contrar va primi eroare și va trebui să reintroducă credențialele. După ce a intrat pe pagina principală, utilizatorul va naviga în meniu, va accesa baza de date și va căuta dacă echipamentul pe care dorește să il vizualizeze este deja în aplicație sau nu. În caz afirmativ, va realiza modificările dorite după care se va deloga, iar în cazul negativ, va adăuga echipamentul în baza de date, după care va realiza delogarea.

Diagrama de stări este folosită pentru a documenta tranzițiile realizate de către un sistem, subsistem sau o componentă, reflectând stări și tranziții. Această diagramă modelează comportamentul unui singur obiect și specifică o anumită secvență de stări prin care un anumit obiect trece în toată perioada de execuție ca răspuns la un eveniment. Starea reprezintă o condiție sau o situație din viața unui obiect în timpul cărei el satisface anumite condiții, efectuează o activitate sau așteaptă apariția unui eveniment. Astfel, în această diagramă se pleacă de la nodul inițial până la cel final, având posibilitatea ca să existe mai multe noduri finale încazul în care există mai multe rezultate. Scopul acesteaia este legat de intrările inițiale și îmi transmite în ce stare se termină o aplicație.

Figura 1.8 Diagrama de stări

1.3 Modelul de dezvoltare

În acest subcapitol voi reda modelul de dezvoltare ales în ceea ce privește sistemul informatic și anumite reguli și proprietăți după care sunt evidențiate procesele. De asemenea, voi prezenta avantaje și dezavantaje legate de acesta.

Sistemul pentru rezervarea echipamentelor pentru sporturile montane de iarnă l-am dezvoltat conform metodologiei Agile. În primul rând voi defini această metodă, iar apoi voi argumenta alegera făcută. Agile este un concept care susține dezvoltarea software-ului de tip agil și se referă la un grup de metodologii de dezvoltare software bazate pe o activitate iterativă, unde cerințele și soluțiile se dezvoltă prin colaborarea dintre echipele inter-funcționale care se auto organizează (Kaliym A. Islam, 2013). Metoda Agile este orientată pe programare și prezintă puține reguli și practici. Aceasta avantajează mai degrabă modificarea decât planificarea metodică, reprezentând o abordare de management. Metodologia Agile se bazează pe adaptarea și inspecția frecventă a proiectului, pe munca în echipă, pe auto răspundere și organizare, pe o structură care permite livrarea rapidă a produsului și pe o strategie care avantajează atât clienții, cât și dezvoltatorii. Așadar, Agile are anumite caracteristici moștenite de fiecare metodologie, dar fiecare în parte au proprietățile lor particulare.

Pentru lucrarea de față am ales această metodă, deoarece eu sunt atât dezvoltatorul, cât și cel care impune cerințele sistemului și nu era necesară aplicarea unei altfel de metodologii precum Kanban, Scrum sau Programarea Extremă unde cerințele sunt schimbate frecvent. Acestea din urmă moștenesc caracteristicile metodei Agile, însa se deosebesc prin anumite principii specifice. Aplicația prezentă nu este dezvoltată de către o echipă formată din mai multe persoane, are dimensiuni mici și nu necesită specificațiile altei metode de dezvoltare.

Printre caracteristicile metodei Agile se regăsesc următoarele: posibilitatea de a comunica frecvent cu clientul, faptul că sistemul are parte de o dezvoltare treptată, iar atribuțiile sunt divizate în mai multe etape.

Astfel, luându-le pe rând vorbim despre posibilitatea de a comunica frecvent cu clientul sistemului. Această caracteristică este benefică pentru un proiect de orice tip, dar în special pentru unul de dimensiuni mari. Este important ca relația cu persoana căreia îi vom livra produsul final să fie una apropiată, iar comunicarea între cele două părți este esențială. În acest mod, nu vor apărea neînțelegeri la final datorită unor posibile interpretări greșite, iar dacă pe parcurs clientul dorește anumite modificări, echipa de programatori va putea să le includă în proiect la momentul potrivit, fără a fi nevoie să facă foarte multe modificări în cod.

Următoarea caracteristică pe care am amintit-o este faptul că sistemul are parte de o dezvoltare treptată, iar atribuțile sunt divizate în mai multe etape. Prin acest lucru înțeleg, ca la properietatea amintită mai sus, ideea de o comunicare intensă, atât în relația dezvoltator-client, cât și în relația dezvoltator-dezvoltator, adică între colegii de echipă. Este indicat să se pornească de la o anumită idee de bază și nu de la ceva amplu cu foarte multe funcționalități. Astfel, pe parcursul dezvoltării proiectului se pot adăuga idei noi, iar la finalul fiecărei funcționalități echipa arată rezultatul clientului, iar acesta își exprimă părerea în legătură cu sistemul.

Divizarea atribuțiilor în mai multe etape este o altă caracteristică a modelului de dezvoltare Agile. Datorită faptului că acest model se bazează pe comunicare și dezvoltarea continuă, implicit este nevoie și de împărțirea sarcinilor în iterații cu o durată de maxim două săptămâni. Ședințele sunt esențiale în astfel de proiecte, astfel că atunci când este nevoie, uneori și zilnic au loc ședințe de aproximativ 15 minute în care coechipierii să își clarifice nelămuririle, și să raporteze starea în care se află produsul.

După cum am precizat în introducerea acestui subcapitol, voi prezenta punctele tari și slabe ale acestei metode. Avantajele pe care doresc să le precizez sunt:

Adaptabilitatea proceselor;

Aflarea opiniei clientului față de sistem în timp util;

Crește performanța proiectului pe durata procesului de dezvoltare;

Livrarea rapidă, pe etape a codului către client;

Testarea sistemului constantă;

În cazul în care clientul are cerințe noi, acestea nu vor fi greu de integrat în sistem;

Dezavantajele acestei metode ar fi:

Timpul de implementare este scurt pentru a lansa produsul repede, iar din această cauză anumite faze ale sistemului nu sunt gândite în totalitate și poate în final nu vor corespunde 100% cu cerințele clientului;

La începutul proiectului nu se va putea da un timp exact în care va fi gata sistemul datorită mulțimii de schimbări care au loc;

Membrii echipei își concentrează atenția o dată doar pe o singură componentă din sistem;

Anumite particularități care sunt prea ample pentru a inta într-un ciclu de producție nu vor fi integrate.

După această prezentare a modelului de dezvoltare Agile aș dori să argumentez de ce am ales eu această metodă pentru sistemul meu și cum am integrat proprietățile acesteia în aplicația mea. Astfel, în diagrama următoare am arătat etapele din cadrul unui ciclu de dezvoltare a metodei Agile. Bucla începe de la analiza și fixarea sarcinilor pe care dezvoltatorii le au de realizat în etapa respectivă. În continuare urmează planificarea sprintului și ședințele periodice între membrii echipei. În urma acestora se pot extrage alte cerințe pentru continuarea sistemului, iar apoi se implementează codul în continuare. După realizarea implementării se testează aplicația în conformitate și cu funcționalitățile realizate până în acel moment. Apoi urmează revizuirea sprintului pentru a se aduce la cunosțiință măsurile necesare pentru următorul sprint, iar apoi se lansează produsul și e posibil să înceapă alt ciclu ăn proces. Astfel, această metodă se potrivește în cazul meu, deoarece pentru un începător este important să primească îndrumare și confirmare constant.

Figura 1.9 Diagrama metodei Agile

CAPITOLUL 2. Proiectarea sistemului informatic

În acest capitol voi prezenta mai întâi proiectarea logică care cuprinde arhitectura sistemului și baza informațională, iar apoi proiectarea tehnică sau fizică care cuprinde structura fizică a datelor, procese și algoritmi și tehnologii specifice. Pentru înțelegerea informațiilor legate de sistemul de rezervare a echipamentelor, e nevoie de a analiza toate cele specificate mai sus.

2.1 Proiectarea Logică

Informațiile redate în acest subcapitol sunt legate de partea de finisare a datelor, de arhitectura sistemului și de baza informațională. Până în acest punct am vorbit mai mult despre cerințele sistemului de față, iar acum pe baza acestora voi prezenta partea de proiectare logică care se axează pe modul de funcționare a sistemului, adică intrările și ieșirile acestuia, interfețe și dialoguri.

Un sistem informatic este un set integral de componente cu scopul de a colecta, stoca, prelucra datele și informațiile pentru furnizarea lor, a cunoștințelor și a produselor digitale, fiind parte integrată în sistemul informațional (Vlăscanu 2013). Sistemele informaționale sunt un ansamblu al elementelor de structură organizatorică din compunerea unei secțiuni a societății umane (CHIRU). Sistemele informatice au diferite mărimi ale componentelor, astfel că există posibilitatea ca ele să fie stocate fie pe unul, fie pe mai multe servere. Amintind de componente, acestea sunt cele hardware, software, baze de date, resurse umane, dar și proceduri. Din perspectiva lor se poate opta pentru un sistem informatic distribuit sau centralizat. De obicei, cele distribuite sunt utilizate de către companiile mari, astfel că sistemul de față este unul centralizat, deoarece este de dimensiuni mici, fiind format dintr-un singur server unde sunt stocate toate datele și prelucrările acestora. La aceste sisteme, o problemă care ar putea interveni ar fi legată de numărul de utilizatori care accesează în același timp aplicația, însă pentru proiectul de față aceasta nu reprezintă o amenințare, deoarece este puțin probabil ca mai mulți utilizatori să acceseze site-ul în același timp.

În legătură cu concepția logică a unui sistem informatic se poate specifica că acesta este distribuit în alte subsisteme, aplicații, unități funcționale sau proceduri logice. Procedura logică reprezintă corespondentul subactivității din cadrul unei aplicații din domeniul informatizării. Doar la acest nivel se realizeză ușor trecerea directă de la structura logică a aplicației la programare. Cu toate acestea, fiecare componentă a unui sistem informatic, indiferent la nivelul la care se află, va presupune intrări, prelucrări și ieșiri. Intrările dintr-un sistem informatic reprezintă modificări ale sistemului informațional care produc schimbări în colecțiile de date, adică tranzațiile externe (CHIRU).

În continuare am realizat o diagramă de flux de date de nivel zero care ilustrează intrările, datele care sunt stocate și ieșirile. Această diagramă prezintă fluxul de date din sistem care trece printr-un nod de proces și prin componenetele cu care este conectat. Dacă vorbim de o diagramă de nivel zero înseamnă că avem un singur nod de proces având diferite conexiuni care sunt reprezentate de către entitățile externe. Aici se prezintă drumul parcurs de informație în cadrul unui flux și anume: care sunt informațiile transmise, care sunt entitățile care primesc informațiile respective și ce procese generale se produc. Diagrama pe care am ilustrat-o mai jos prezintă schimbarea care se realizează în baza de date de către administratorul sistemului, iar aceasta reprezintă un input în sistemul informatic. Pe final duce la o ieșire după ce se realizează o actualizare, deci se va afișa utilizatorului schimbările efectuate. Obiectele externe de care se vorbește în cadrul acestui sistem informatic sunt administratorul și clientul, adică utilizatorii aplicației, acestea comunicând cu sistemul prin intermediul unui flux de date(Ciaca,2020).

Figura 2.1 Diagrama Flux de Date

După cum se poate observa în diagram de mai sus, fluxul de date în această aplicație pornește de la cei doi utilizatori care pot interacționa cu sistemul, și anume administratorul și cleintul. Aceștia trebuie să se logheze la aplicație pentru a realiza anumite funcționalitătți, după care, fiecare are drepturi separate. Clientului îi sunt afișate datele din baza de date, le vizualizează, iar prin introducerea datelor în formular se poate face rezervarea echipamentelor, după care baza de date va fi actualizată din punctual de vedere al disponibilității produselor. Pe cealaltă parte, la administrator, se poate gestiona baza de date (ex: ștergere, modificare, actualizare etc.), iar apoi se va actualiza baza de date.

2.1.1 Arhitectura sistemului

În acest subcapitol voi prezenta arhitectura sistemului din punctul de vedere a unei abordări generale și a viziunii statice și dinamice. Într-un sistem informatic, arhitectura realizează o separare a întregii structuri a sistemului de detaliile interne ale componenetelor (Bass 2003).

Arhitectura unui sistem informatic este alcătuită din componente distribuite ,adică anumite programe scrise în diferite limbaje de programare, și din sisteme de gestiune a bazelor de date structurate modular (ANGHEL 2002). Astfel, putem spune că arhitectura este compusă din elementele prezente efectiv în sistem, acestea fiind cele externe care sunt perceptibile pentru utilizator și relațiile care au loc între acestea. De asemenea, pentru a cunoaște mai bine arhitectura sistemului e nevoie de privirea din mai multe puncte de vedere asupra acesteia, și anume static și dinamic.

Consider că un cuvânt cheie pentru arhitectura unui sistem este relație, deoarece acest lucru se urmărește pe întregul proiect. Astfel, sistemul de față fiind împărțit în componenta hardware și software am realizat o diagramă care să ilustreze legătura dintre acestea. Acest proiect este o aplicație web, deci componentele ei sunt serverul web, conexiunea la Internet, browserul, baza de date, utilizatorii sistemului, elementele hardware unde se stochează datele, protocoalele, routere wireless și anumite programe soft prin intermediul cărora se realizează sistemul informatic. Diagrama amintită mai sus cuprinde aceste elemente și relațiile dintre ele.

Figura 2.2 Arhitectura Sistemului Informatic

Serverul web este o componentă esențială într-o rețea, el comunicând cu browserul web prin intermediul protocoalelor TCP/IP. Acest protocol are rolul de a transmite date în siguranță, oferind încredere și asigurarea livrării datelor. Pentru transferul cererilor de la utilizator se utilizează protocolul HTTP(HyperText Transfer Protocol), acesta la rândul lui utilizând TCP pentru a face legătura între client și server. Această operație de transmitere a unei cereri se realizează prin intermediul unui browser web. Clientul va trimite o cerere HTTP prin browser către server, iar acesta din urmă îi va trimite înapoi clientului informațiile pe care acesta le dorește. Datorită faptului că în Internet există multe cauze care ar putea crea daune în rețeua privată este nevoie de Firewall care acționează ca un filtru pentru datele care circulă între rațeaua personală și Internet. De asemenea, în diagramă sunt reprezentați și utilizatorii și mașinile de pe care se va navigha pe aplicație, acestea find componente dependente unele de altele în sistem. Conectarea între utilizator și computer se realizează prin intermediul componentelor externe, și anume: mouse, butoane, tastatura.

O altă viziune asupra componentelor sistemului este realizată prin diagrama de componente pe care urmează să o ilustrez.

Figura 2.3 Diagrama componentelor

Aceasta prezintă care sunt componentele software și relațiile dintre ele. Ideea care se aplică în această diagramă este cea a gradului de abstractizare, adică se merge de la abstract la concret, dezvoltarea fiind bazată pe componente. Diferența între această diagramă și cea prezentată anterior este faptul că aceasta prezintă arhitectura mai în detaliu.

Amintind de componenta software, voi prezenta modurile în care acest termen este folosit, și anume: se referă la sistemele modulare, unde modulele pot avea diferite implementări impuse de platforma gazdă; este o componentă de sine stătătoare, având o interfață bine definită prin intermediul căreia interacționează cu alte componente sau elemente de context; este o unitate funcțională cu un anumit grad de generalitate și este posibil să fie utilizată în diferite aplicații (Ciaca, 2020). În diagrama de mai sus observăm că există componente soft independente, un exemplu fiind baza de date. Aceasta poate fi vizualizată chiar dacă administratorul nu este intermediar, dar în același timp este integrată în sistem și funcționează în scopul care îi este atribuit. De asemenea, digrama este utilă în ideea de a avea o vedere de ansamblu asupra sistemului. Astfel, observăm că interfața joacă un rol important în sistem, de exemplu la realizarea rezerării, deoarece fără acest element, utilizatorul nu ar avea posibilitatea să realizeze operația dorită.

În continuare am realizat un tabel pentru explicarea elementelor din diagrama componentelor:

Tabelul 2.1 Descrierea elementelor diagramei de componente

În continuare, am realizat diagrama client-server. În majoritatea cazurilor, sistemul este format dintr-un serviciu, un număr mai mare de clienți care îl accesează și o rețea prin intermediul căreia utilizatorul se conectează la server. În acest caz, termenul de client se folosește pentru a defini calculatorul de pe care se vor realiza operațiile de rezervare a echipamentelor, iar serverul se referă la un computer puternic care are rolul de a stoca și gestiona unitățile de disc, traficul rețelei etc. În cazul meu, serverul web este IIS, iar acesta primește cererile HTTP ale clientului. Fiind o aplicație web, prin intermediul internetului va fi procesată cererea clientului, iar acesta va primi un răspuns prin afișarea paginii web dorită.

Figura 2.4 Diagrama client-Server

Legat de partea de client-server a aplicației aș dori să menționez și modelele arhitecturale pe care l-am utilizat, și anume MVC (Model-View-Controller) și API( Application Programming Interface).

ASP.NET MVC este un pattern utilizat în inginera software. Acesta are o logică de bussiness raportată la considerentele interfeței cu utilizatorul, de unde rezultă o aplicație în care aspectul vizual și nivelele inferioare ale regulilor de bussiness sunt mai ușor de modificat, fără a afecta alte nivele. Acesta este format din Model, View și Controller. În Model sunt datele și comportamentul aplicației în ceea ce privește domeniile cu probleme, acestea fiind independente de interfață. Modelul interacționează cu controller-ul care este responsabil cu gestiunea unei cereri HTTP. Cel din urmă, view-ul, reprezintă marcajele HTML care sunt afișate utilizatorului. Astfel, când aplicația primește o cerere, MVC o trimite la controller care de cele mai multe ori va returna un View.

Pentru a înțelege mai bine cum funcționează acesta, am realizat o diagramă care ilustrează relațiile dintre Controller, Model și View.

Figura 2.5 Reprezentare grafică MVC

Opreațiile CRUD le-am realizat prin intermediul ASP.NET Web API (Application Programing Interface). Acesta returnează date sau le modifică și este asemănător cu ASP.NET MVC.

Diagrama de implementare(deployment) se utilizează în cazul în care sistemul este distribuit fizic. Utilitatea acestor diagrame este reprezentată de faptul că cel care proiectează sistemul va știi metoda prin care componentele sistemului sunt întocmite și distribuite în noduri diferite, fiind permisă proiectarea tipologiei procesoarelor și dispozitivelor pe care sistemul rulează. Astfel, se observă faptul că diagrama de față ilustrează distribuția fizică a componentelor, reproduce metoda de instalare, configurare și rulare a componentelor din punct de vedere fizic al sistemului și cuprinde elementele hardware și conexiunile. În proiectul meu, componentele hardware sunt, de exemplu serverul web, iar un exemplu de componentă software este baza de date.

După cum se poate observa, în diagramă sunt prezentate dependențele anumitor componente față de altele. De exemplu, browseru-ul web nu poate funcționa fără o stație de lucru pe care să ruleze. De asemenea, serverul web este esențial pentru interfața web, interfața bazei de date și pentru fișierele care conțin codul, deoarece fără acesta datele nu pot fi transmise mai departe clientului care le-a cerut printr-o cerere HTTP.

Figura 2.6 Diagrama Deployment

2.1.2 Baza Informațională

Baza informațională este o componentă software care conține date de intrare și ieșire pentru componentele unui sistem informatic (Ciaca, 2020). Precum orice altă componentă a unui sistem presupune anumite intrări, prelucrări ale datelor și ieșiri, relațiile dintre acestea realizându-se prin intermediul unei baze informaționale. Astfel, doresc să evidențiez importanța unei baze de date, mai ales în cadrul unui proiect cum este și cel de față, pentru rezervarea echipamentelor. O bază de date stochează anumite date introduse de către o persoană cu scopul de a gestiona și a utiliza prin metode simple anumite informații. În aplicația mea de față am realizat baza de date prin metoda Code-First, codul fiind scris în Package Manager Console, iar apoi prin intermediul migrărilor am dezvoltat tot mai mult această bază.

Aceste date constituie baza informațională și sunt supuse la anumite fluxuri informaționale și prelucrări pe baza cărora se vor realiza acțiuni între baza de date și aplicație. Un utilizator nu poate să realizeze nicio acțiune înafară de a vizualiza pagina de început fără a lucra cu date. Pentru accesarea oricărei pagini înafară de cea menționată anterior, utilizatorul va trebui să se înregistreze sau să se logheze la aplicație, urmând apoi ca aceste date să fie stocate, respectiv verificate în baza de date. Similar, pentru realizarea unei rezervări vor fi necesare introducerea unor înregistrări prin completarea anumitor câmpuri specifice, care tot așa, vor fi corelate cu baza de date a proiectului.

2.1 Proiectarea Tehnică

În acest subcapitol voi prezenta mai în detaliu modul prin care am realizat baza de date, cum am dezvoltat-o și ce metode am folosit pentru acestea. De asemena, voi prezenta și tehnologiile abordate pentru realizarea aplicației web pentru închirierea echipamentelor montane de iarnă.

2.2.1 Structura fizică a datelor

În subcapitolul 2.1.2 Baza Informațională am precizat modul prin care am realizat baza de date pentru aplicția mea. În continuare, voi detalia acțiunile făcute de mine în dezvoltarea bazei de date.

Baza de date pe care am realizat-o este în concordanță cu informațiile pe care le-am scris și în 1.2 Cerințe de sistem. Cum am specificat și până acum, scopul acestei aplicații este de a realiza rezervări pe o aplicație web a echipamentelor sport de iarnă, iar acest lucru fiind posibil prin crearea unui cont de utilizator în cazul în care nu există. Astfel, pentru realizarea unei baze în care să fie stocate toate aceste informații avem nevoie de tabele unde să se stocheze conturile de autentificare, rolurile utilizatorului, echipamentele, categoriile din care acestea fac parte și informații legate de clienți. Am realizat o diagramă prin intermediul căreia am ilustrat baza informațională, tabelele și relațiile care le leagă. Aceste relații sunt de tip 1:M (one to many), fiind cele mai des întâlnite relații și o relație many to many (M:M) între clienți și echipamente. Ele sunt reprezentate prin anumiți conectori care arată care capăt al liniei reprezintă relația de unu sau care de mai multe. Un exemplu pentru aceste relații one to many în aplicația mea îl reprezintă cea dintre tabelele Equipments și Category. Un echipament poate să facă parte dintr-o singură categorie, dar o categorie poate avea mai multe echipamente. Acest lucru se realizează prin intermediul cheii străine CategoryId care se află în tabelul Equipments.

Amintind de cheie străină, vreau să precizez și elementul de cheie primară, acestea fiind setate în fiecare tabel. Cheia primară este necesară fiecărui tabel, deoarece fiecare element dintr-un tabel trebuie să fie diferențiat față de altul, adică în câmpul care indică cheia primară nu vor putea fi înregistrări la fel. De obicei aceste chei sunt reprezentate de coloanele Id, deoarece acestea sunt unice.

Într-un tabel din baza de date, fiecare coloană reprezintă un anumit tip de date. Acestea sunt: nvarchar(numele categoriei, numele clienților, numele echipamentelor, numele rolului utilizatorului, numele tipului de membru), integer(id-ul clientului, id-ul echipamentului), date time(data nașterii clienților, data la care s-a adăugat echipamentul). Unele variabile precum nvarchar pot fi setate pentru a avea un număr maxim de caractere. Asfel, la majoritatea variabilelor nvarchar am setat un maxim de 255 de caractere.

În continuare, voi prezenta diagrama bazei de date care este formată din structura tabelelor, adică câmpurile din acestea și tipurile de date pe care le pot cuprinde.

Tabelul Categorie este format din câmpul Id care este cheia primară și din câmpul Name care indică numele categoriei.

Figura 2.8 Tabel Categorie

Tabelul Echipamente este format din coloanele care se văd în tabelul următor. Acesta are cheia primară Id de tip int și cheia străină CategoryId care leagă tabela Echipamente de Categorie. Acestea trebuie să fie legate pentru a știi fiecare echipament din ce categorie face parte (schi, snowboard sau sanie).

Figura 2.9 Tabel Echipamente

Tabelul Tip de Membru(MembershipType) indică ce tip de membru este fiecare client din baza de date. Cheia primară este setată în câmpul Id. Restul câmpurilor specifică informații legate de taxele necesare și numele tipului de membru.

Figura 2.10 Tabel MembershipType

Tabelul Clienți conține datele legate de clienții aplicației. Id-ul este cheia primară de tip integer și este legat de tabela MembershipType prin cheia străină MembershipTypeId pentru a știi fiecare client din ce categorie face parte. Celelalte câmpuri sunt reprezentate de numele clientului, data de naștere și dacă este sau nu abonat la Newsletter, aceasta fiind o variabilă de tip boolean (TRUE sau FALSE).

Figura 2.11 Tabel Clienți

Următorul tabel conține rolurile pe care le poate avea un utilizator al aplicației. Cheia primară este reprezentată de câmpul Id, iar Name indică numele rolului. Astfel, utilizatorul poate să aibă rol de administrator sau client.

Figura 2.12 Tabel Roluri

Conturile utilizatorilor sunt stocate în tabelul următor. Datele sunt introduse în acest tabel în momentul în care persoana care dorește să își creeze un cont apasă pe butonul de submit din formularul de register. De asemenea, în momentul în care un utilizator dorește să se autentifice, după apăsarea butonului de logare, datele din formular vor fi verificate cu datele din acest tabel.

Figura 2.13 Tabel conturi utilizatori

Tabelul în care sunt stocate rezervările se numește Rent. Acesta conține date referitoare la id-ul închirierii, deoarece fiecare este unică; data la care s-a realizat închirierea (DateRented); data la care s-a returnat echipamentul (DateReturned), aceasta având posibilitatea să aibă valoarea nulă; id-ul clientului (Customer_Id) și id-ul echipamentului (Equipment_id), acestea facând legătura cu tabelele echipamentelor, respectiv al clenților.

Figura 2.14 Tabel închirieri

2.2.2 Procese și algoritmi

Procesul unui sistem informatic se referă la o modalitate prin care toți stakeholderii aduc idei în dezvoltarea proiectului, iar apoi acestea sunt eventual prelucrate și puse în funcțiune pentru a se găsi soluții. Se pornește de la o ipoteza, iar de obicei, cum este și cazul de față, procesul de realizare a sistemului este unul complex. Pentru reușita implementării unui proiect e nevoie de urmărirea anumitor reguli pentru ca rezultatul final să fie cel dorit. Astfel, primul proces pe care l-am urmat în creearea aplicației pentru rezervarea echipamentelor a fost să aleg ce funcționalități doresc să îndeplinească sistemul și mi-am setat obictivele care voiam să fie îndeplinite de aceste funcționalități. În continuare, am gândit interfața aplicației, cum să îmi fie aranjate în pagină elementele dorite și ce server să găzduiască aplicația.

Așadar, procesele generale care sunt urmărite în dezvoltarea unui sistem informatic sunt extragerea cerințelor, documentarea acestora, stabilirea modului de implementare a programelor și limbajelor de programare în care se va scrie cod, implementarea efectivă a codului, iar în final testarea aplicației. Până în acest moment, am parcurs detaliile legate de cerințe, urmând ca să prezint cum am implementat codul, cu tehnologii și testarea acestora.

Algoritmizarea reprezintă o cerință fundamentală în rezolvarea problemelor prin intermediul calculatorului. Un algoritm implementează anumite tehnici și metode penru rezolvarea problemelor dintr-un domeniu (Marin Vlada, 2004). Algortimii sunt scriși în special în pseudocod. Limbajul pseudocod prezintă o sintaxă asemănătoare cu limbajele de programare modernă și are o anumită flexibilitate în sintaxă. Un algoritm reprezentat în pseudocod este format dintr-o secțiune unde se declară variabilele , tipul de date asociat acestora, definirea funcțiilor și procedurilor utilizate în program și corpul algoritmului care este o succesiune finită de instrucțiuni executabile (Marin Vlada, 2003).

Un algoritm este un proces dinamic. Un exemplu de proces poate să fie logarea în cadrul aplicației, aici fiind necesară implementarea unui algoritm. Multe procese naturale și activități umane pot fi descrise într-oformă algoritmică prin definirea unor informații și acțiuno clare și precise, fiind eliminate amibuguități în interpretare (Marin Vlada, 2015).

Pentru a implementa o anumită funcționalitate este necesară urmărirea unor pași logici. Un exemplu pe aplicația mea ar fi posibilitatea ca utilizatorul să se logheze la aplicație și prin intermediul rețelei de socializare Facebook. În cazul în care nu dorește să completeze formularul pentru log in, are posibilitatea să apese butonul pe care scrie Facebook, urmând a fi redirecționat și conectat cu contul Facebook.

Un exemplu de procedură pe care am realizat-o pentru administrator este cea de ștergere a echipamentelor. Datorită faptului că administratorul are dreptul de a gestiona baza de date, prin intermediul acestei proceduri, acesta are posibilitatea să șteargă echipamente din baza de date în cazul în care acestea nu mai sunt disponibile. Alte proceduri realizate au fost cea de vizualizare, inserare și modificare a echipamentelor, acest lucru fiind posibil doar dacă e realizat de către administrator.

În cadrul acestei părți am dorit să evidențiez de ce este important să fie setate anumite procese și ce algoritmi trebuie utilizați pentru implementarea funcținalităților dorite.

2.2.3 Tehnologii specifice

În cadrul fațetei It am prezentat în mare tehnologiile specifice pe care le-am utilizat în dezvoltarea acestei aplicații, iar în acest subcapitol le voi detalia. Voi face o redactar atât a software-urile folosite, cât și a limbajului de programare pe care l-am ales.

Programul software pe care am realizat aplicația este Visual Studio 2019, în cadrul căruia am utilizat tehnologii și limbaje de programare precum C#, SQL, CSS, HTML, JavaScript, jQuery, librăria Bootstrap, ASP.NET MVC, ASP.NET Web API, SQL Server, Entity Framework (Code-fisrt), .Net Framework, ASP.NET Web Forms.

Am utilizat aplicația software Microsoft Visual Studio 2019 pentru a scrie și rula codul. Aceasta este o soluție integrată și complexă cu instrumente pentru dezvoltare, servicii cloud și extensii care permit programatorilor să creeze aplicații și jocuri de tip desktop, web sau mobile(Android sau iOS). Acest mediu de programare integrat (IDE) care permite partajarea instrumentelor și creează soluții prin intermediul mai multor limbaje de programare. Acestea admint să beneficieze de carcateristicile .Net Framework, ele oferind acces la anumite tehnologii cheie care fac mai ușoară dezvoltarea aplicațiilor.

Microsoft Sql Server reprezintă un sistem prin intermediul căruia se stochează baza de date, limbajul de interogare fiind SQL, cel mai răspândit limbaj penstru scrierea interogărilor unei baze de date.

Tot pentru baza de date am utilizat Entity Framework care este o “unealtă” pe care o folosim pentru a accesa baza de date. Acesta este clasificată ca obiect al unei hărți relaționale și mapează datele dintr-o bază de date relațională în obiecte ale aplicației. Entity Framework furnizează o clasă numită DbContext care este o poartă către baza de date. Un DbContext are unul sau mai multe DbSet-uri care reprezintă tabele în baza mea de date. Pentru interogarea DbSet-ului se utilizează LINQ, iar Entity Framework este utilizat pentru a traduce interogările LINQ în interogări SQL la rulare.

Pentru crearea paginilor web am utilizat framework-ul .NET care este o modalitate de interfață prin intermediul căreia utilizatorul rulează anumite programe independente de sistemul hardware. Acesta este un software dezvoltat de Microsoft care poate rula pe mai multe sisteme hardware, dar în special pe Microsoft Windows. Tehnologia utilizată de acest framework și pe care am folosit-o și eu în această aplicație este ASP.NET.

ASP.NET este o tehnologie Microsoft utilizată cu rolul de a crea aplicații și servicii web. Modelul ASP.NET este utilizat atât pentru partea de front-end, cât și cea de back-end. Acest lucru este susținut de limbajul care este utilizat, și anume C# și a utilizării serverului de baze de date SQL Server. Această tehnologie am utilizat-o pentru a crea pagini dinamice.

Pentru crearea interfeței am utilizat HTML, CSS, JavaScript, jQuery și librăria Bootstrap. HTML este un limbaj pentru marcarea documentelor concepute pentru a fi afișate într-un browser web, în cele mai multe cazuri fiind completat de tehnologia CSS care este utilizată pentru partea de înfățișare a site-ului. Limbajul CSS oferă posibilitatea de a edita și schimba aspectul elementelor prezente în pagină. Pentru a organiza codul, fișierele CSS au extensia .css și le-am integrat în fișiere specifice.

Toate aceste tehnologii și programe menționate mai sus au avut rol important în realizarea aplicației pentru rezervarea echipamentelor, deoarece toate depind unele de altele. Prin intermediul acestora s-au realizat cerințele stakeholderilor, adică am implementat funcționalitățile menționate în fațeta utilizare. Toate aceste sunt componentele unui sistem complex cu scopul de a satisface nevoile și obiectivele utilizatorului final.

CAPITOLUL 3. Implementarea aplicației

În continuarea lucrării voi prezenta modul prin care am implementat aplicația și cum am realizat funcționalitățile ei prin intermediul tehnologiilor prezentate anterior. Voi întări aceste informații prin intermediul unor fragmente de cod specifice și capturi de ecran prin intermediul cărora să explic obiectivele de bază pe care le-am urmat pe parcursul aplicației.

Astfel, după cum am menționat și în capitolele precedente, am realizat aplicația pe baza patternul-ui MVC (Model, View, Controller). Paginile din cadrul acestuia au extensiile .cs, respectiv .cshtml. Acestea din urmă utilizează cod HTML, CSS, JavaScript, jQuery, legături spre Bootstrap și formează interfața care îi este oferită utilizatorului. Paginile cu extensia .cs conțin partea de back-end a aplicației, astfel aici se implementează dinamica elementelor. Un exemplu de funcționare este controller-ul EquipmentsController.cs care conține acțiunile pe care pagina echipamentelor le va executa, iar fișierul cu view-ul Equipments este format din mai multe pagini care formează interfața de la echipamente (ex: EquipmentsForm.cshtml, List.cshtml). Astfel, se observă aici și legătura pe care am menționat-o la prezentarea MVC-ului dintre controller si view.

Principalele funcționalități ale aplicației pe care doresc să le dezvolt în această parte a lucrării sunt: funcționalitatea pentru înregistrare/autentificare, gestionarea bazei de date de către administrator și realizarea rezervării.

În început, doresc să specific faptul că utilizatorul poate vizualiza fără a avea un cont doar pagina de început a aplicației.

Figura 3.1 Pagina de start

Funcționalitățile pentru înregistrare și autentificare le-am realizat prin intermediul ASP.NET Identity. Inițial, acest framework avea implementat automat funcționalitățile de înregistrare, autentificare și delogare, urmând ca pe parcurs să le dezvolt. Astfel, controller-ul AccountCntroller.cs conține acțiunile pentru funcționalitățile enumerate mai sus. În pagina de Register, utilizatorul va completa datele personale pe baza cărora își va crea contul în aplicație(email, parolă, confirmarea parolei și telefon).

Figura 3.2 Pagina de înregistrare

După apăsarea butonului de submit, utilizatorul va fi redirecționat în aplicație, iar la următoarea accesare a aplicației, acesta va intra pe formularul pentru Log In unde îi va apărea următoarea pagină:

Figura 3.3 Pagina de Log In

Se observă faptul că utilizatorul are două posibilități de logare și anume completarea formularului cu datele personale sau logarea prin intermediul aplicației Facebook. De asemenea, această pagină are legătură directă cu pagina de înregistrare prin intermediul link-ului “Register as a new user.”.

În cazul în care un administrator se va loga la aplicație, acesta va avea toate drepturile aplicației asupra bazei de date. Astfel, se observă în figura de mai jos interfața care îi va apărea administratorului. Pe lângă gestionarea bazei de date, există posibilitatea de a căuta echipamente prin intermediul barei de căutare, posibilitatea de a sorta echipamentele alphabetic sau afișarea în pagină a unui număr dorit de produse. Aceste funcționalități sunt implementate și pentru clienți în pagina “Customers”.

Figura 3.4 Pagina echipamente

Rândurile care sunt scrise cu albastru reprezintă link-uri către alte pagini unde se vor putea realiza modificări, acestea fiind operațiile CRUD (creare, citire, actualizare, ștergere). Crearea unui nou echipament se face prin intermediul butonului “New Equipments” unde se vor putea introduce date pentru echipamentul care urmează să fie introdus în baza de date(nume, categoria din care face parte și numărul bucăților din stoc).

Figura 3.5 Pagină creare echipament

Operația de actualizare se realizează prin accesarea fiecărui echipament dorit, în urmă căreia va apărea un formular care conține datele actuale ale echipamentului, acestea având posibilitatea de a fi schimbate. După accesarea butonului “Save”, modificările efectuate asupra produsului vor fi salvate automat în baza de date.

Figura 3.6 Pagină actualizare echipament

La accesarea butonului de ștergere din dreptul fiecărui echipament, va apărea mesajul de mai jos pentru ca utilizatorul să confirme operația pe care urmează să o realizeze, iar similar cu cazul de actualizare, după confirmarea realizată, baza de date va fi modificată și echipamentul nu va mai exista în acesta.

Figura 3.7 Mesaj confirmare ștergere

Toate aceste funcționalități le-am realizat în cadrul framework-ului ASP.NET Web API, mai exact în controllerul EquipmentsController.cs din cadrul fișierului API, urmând să fie legate cu view-urile corespunzătoare. Două exemple de acțiuni dintre cele menționate anterior sunt implementate mai jos. Acțiunea pentru crearea unui nou echipament :

[HttpPost]

public IHttpActionResult CreateEquipment(EquipmentDto equipmentDto)

{

if (!ModelState.IsValid)

return BadRequest();

var equipment = Mapper.Map<EquipmentDto, Equipment>(equipmentDto);

_context.Equipments.Add(equipment);

_context.SaveChanges();

equipmentDto.Id = equipment.Id;

return Created(new Uri(Request.RequestUri + "/" + equipment.Id), equipmentDto);

}

Acțiunea pentru ștergerea unui echipament :

[HttpDelete]

public IHttpActionResult DeleteEquipment(int id)

{

var equipmentInDb = _context.Equipments.SingleOrDefault(c => c.Id == id);

if (equipmentInDb == null)

return NotFound();

_context.Equipments.Remove(equipmentInDb);

_context.SaveChanges();

return Ok();

}

Pentru funcționalitatea de rezervare a echipamentelor, utilizatorul va completa numele clientului și echipamentele pe care acesta dorește să le rezerve. După accesarea butonului de trimitere a formularului, pe ecran va apărea un mesaj de confirmare a rezervării realizate.

Figura 3.8 Formular realizare rezervare

Această funcționalitate am realizat-o în controller-ul NewRentalController.cs, unde am implementat acțiunea de creare a rezervării (public IHttpActionResult CreateNewRentals(NewRentalDto newRental)), aceasta fiind legată de view-ul New.cshtml. Am realizat legătura cu baza de date prin intermediul variabile _context, după care selectez clientul și echipamentul dorit prin intermediul acestei variabile din baza de date. În cazul în care echipamentul nu mai este disponibil in stoc ( variabila NumberAvailable este egală cu zero), va apărea un mesaj care transmite acest lucru(“echipamentul nu este valabil!”). În caz contrar, echipamentul va fi rezervat, iar variabila NumberAvailable va fi decrementată cu o unitate. În variabila “rental” se vor stoca datele adăugate în formular și vor fi adăugate și salvate în baza de date tot prin intermediul variabilei _context.

CAPITOLUL 4. Testarea aplicației

În acest capitol voi prezenta pașii pe care i-am urmat pentru a testa aplicația, tesatrea fiind un alt proces care contribuie la realizarea sistemului.

Procesul de testare a produselor software reprezintă o activitate în cadrul procesului de dezvoltare dintr-o aplicație. Aceasta este formată din anumite metode, cunoștințe, strategii și abilități care se utilizează pentru a certifica calitatea/funcționalitatea unui anumit produs și validarea lui în funcție de specificații. Scopurile urmărite în realizarea testării urmăresc asigurarea dezvoltării corecte a unui produs, găsirea defectelor, prevenirea defectelor, creșterea încrederii în nivelul de calitate al produsului dezvoltat și introducerea unor informații legate de calitatea unui produs. De asemenea, pe lângă scop există și anumite obiective care trebuie să fie îndeplinite, acestea fiind diferite în funcție de tipurile de testare care se fac. Aceasta vine și cu anumite beneficii cum ar fi creșterea calității produsului, creșterea gradului de încredere în produsul dezvoltat, creșterea profitului, creșterea performanței produsului etc.

În orice sistem testarea este importantă pentru ca stakeholderii să fie mulțumiți de rezultatul final. Datorită faptului că am realizat o aplicație web, tipul de testare pentru aceasta este testarea software. Astfel, prin intermediul ei, voi verifica dacă așteptările site-ului corespund cu rezultatele finale ale acestuia pentru câteva funcționalități ale aplicației.

Prima funcționalitate testată a fost cea pentru autentificarea utilizatorilor în aplicație. Aici avem un formular pentru înregistrarea persoanelor care doresc să utilizeze sistemul. Acesta conține câmpurile email, parolă, confirmare parolă și telefon care conțin multe validări. Câmpul email necesită completarea cu o adresă validă de email (ex: nume@yahoo.com) pentru a putea trece la câmpul urmator. În caz contar, va apărea un mesaj care specifică faptul că respectivul câmp nu are o adresă de email validă. Următoarele două câmpuri se referă la parola pe care utilizatorul o setează. Acestea trebuie să aibă minim 6 caractere din care cel puțin unul să fie un caracter numeric (0-9) și cel puțin o literă să fie scrisă cu majuscule. Câmpul de confirmare a parolei trebuie să conțină exact același și de caractere ca și la câmpul precedent pentru a fi valid. Câmpul cu numărul de telefon are ca și validator faptul că trebuie să fie completat obligatoriu pentru ca formularul să se trimită cu succes. Astfel, am realizat un tabel pentru testarea acestei funcționalități prin care am testat câmpurile detaliate mai sus prin adăugarea unor date atât valide, cât și invalide. Testul a dat un rezultat bun, deoarece nu am putut trimite formularul până când nu am îndeplinit toate cerințele validatoarelor. Așadar, un prim caz de testare în cazul funcționalității de înregistrare este introducerea datelor în câmpurile formularului și verificarea butonului de salvare.

Tabel 4.1 Plan de testare pentru înregistrarea utilizatorului

A doua funcționalitate testată a fost cea menționată și la capitolul Implementarea aplicației, și anume cea de gestionare a echipamenetelor de către administrator. După autentificarea cu un cont special pentru administrator, în pagina specifică echipamentelor se pot realiza operațiile CRUD. Astfel, aici sunt toate datele despre echipamente, disponibilitatea lor în stoc etc. , obținându-se o bază informațională de care firma are nevoie. În continuare mă voi axa pe operațiunea de adăugare a echipamentelor unde avem un formular care conține numele, categoria și numărul de produse disponibile în stoc. La acest formular, validările pe care le-am setat se referă la obligativitatea de a completa toate câmpurile formularului, în caz contrar nefiind posibilă trimiterea acestuia. Restul operațiunilor CRUD de la această funcționalitate (gestionarea bazei de date) le-am prezentat mai în detaliu în capitolul anterior. Astfel, pentru a concluziona rezultatul testării am realizat un tabel care detaliază funcționalitatea testată. Aceasta se află în cerințele de sistem, fiind una din cele mai importante funcționalități din cadrul aplicației. Aici am testat câmpurile formularului pentru adăugarea unui nou echipament, iar rezultatul a fost unul pozitiv. Validatoarele au funcționat și nu au permis trimiterea formularului fără completarea întreagă a acestuia. Deci, un caz de testare este cel de gestionare a echipamentelor, mai exact de introducere a datelor unui produs nou în câmpurile formularului și acționarea butonului de salvare.

Tabel 4.2 Plan de testare pentru gestionarea echipamentelor

Pentru realizarea testării aplicației am utilizat atât tehnica Black-box, cât și ce White-box. Tehnica de tesatre black-box se bazează pe principiul că tesatrea aplicației se realizează fără cunoașterea structurii interne, bazându-se pe ceea ce face sistemul și nu cum face. Pe de altă parte, tehnica White-box testează codul, arhitectura și structura internă a aplicației, aceasta având nevoie de cunoașterea logicii. După implementarea și testarea proiectului rămâne de făcut mentenanța sistemului. Aceasta este activitatea de întreținere, verificare și reparere, dacă este cazul, a sistemului.