DOC BLOCKCHAIN VOTING SOLUTION

VOTING SYSTEMS | BLOCKCHAIN

OBIECTIVE CERINTE
I. Analiza Descrieti sumar cerintele proiectului.
II. Proiectare
III. Implementare
IV. Integrare si testare TEHNOLOGII
V. Operare si mentenanta

TEH1 • TEH2 • TEH3 …

Descrieti sumar de ce ati decis sa utilizati aceste tehnologii
IN APROXIMATIV 4-5 RANDURI
ECHIPA
EXEMPLU
NUME PRENUME
NUME PRENUME JAVA?• C++? • C#? • MYSQL? • PHP? • JSON? • XML? • PYTHON?
NUME PRENUME Descrieti sumar de ce ati decis sa utilizati aceste tehnologii
…

STRATEGII
METODE SI MODELE UTILIZATE LA DEZVOLTAREA
PROIECTULUI. STRATEGII DE ABORDARE A PROIECTULUI.
SUMAR

EMAIL TWITTER HANDLE TELEPHONE LINKEDIN URL

CERINTE

DETALII

TEHNOLOGII

DETALII DESPRE TOATE TEHNOLOGIILE CARE POT SOLUTIONA NEVOILE NOASTRE. AICI
POT INTRA CHIAR SI TEHNOLOGIILE CARE ULTERIOR NU VOR FI UTILIZATE DAR AR
PUTEA FI UTILE SI MERITA A FI CUNOSCUTE. O MULTIME DE ALTERNATIVE.

STRATEGII

DETALII DESPRE CUM VA FI ABORDAT PROIECTUL, CE STRATEGII PUTEM AVEA

VEDETI ANEXA 0

OBIECTIVE

I. Analiza

DETALII

ANALIZA SWOT
DESCRIEREA SISTEMELOR DEJA EXISTENTE
COMPARAREA SISTEMELOR SIMILARE
IDENTIFICAREA PROBLEMELOR SI TRANSFORMAREA LOR IN OBIECTIVE

II. Proiectare

DESCRIEREA COMPORTAMENTALĂ A SISTEMULUI, FUNCȚIONALITĂȚILOR

IMAGINEA GENERALĂ ASUPRA SISTEMULUI
DESCRIEREA SCENARIILOR DE UTILIZARE A APLICAȚIEI
FLUXURILE DE MESAJE ȘI LEGĂTURILE DINTRE COMPONENTELE SISTEMULUI
MODELAREA VIZUALĂ A FLUXURILOR
STĂRILE DE TRANZACȚIE A SISTEMULUI
DESCRIEREA STRUCTURALĂ A SISTEMULUI
DESCRIEREA STRUCTURII STATICE A SISTEMULUI
RELAȚIILE DE DEPENDENȚĂ ÎNTRE COMPONENTELE SISTEMULUI
DIAGRAMA DE CLASA

VEDETI ANEXA 1 SI 2

III. Implementare

REALIZAREA SISTEMULUI
DESCRIEREA INSTRUMENTELOR
DESCRIEREA TEHNOLOGIILOR UTILIZATE
CODUL SURSA (Separat arhivat)
DESCRIEREA SUMARA A ALGORITMILOR CU CODUL SURSA
EVIDENTIEREA SABLOANELOR DE PROIECTARE UTILIZATE GOF; SOLID, GRASP …
EVIDENTIEREA ARHITECTUREI IMPLEMENTATE: MVC, MVVM, MVP, MVVP …
IMAGINI, SCREENSHOT
COSTUL DE PRODUCȚIE, ESTIMARE, VALORIFICARE

IV. Integrare si testare

IMAGINI, SCREENSHOT
UN FEL DE DESCRIERE VIZUALA A PROIECTULUI IMPLEMENTAT
TEXT PUTIN, IMAGINILE TREBUIE DESCRISE SUMAR

V. Operare si mentenanta

FINAL !
URMEAZA …
O SARCINA MICA PENRU EVALUAREA ECHIPEI IN TIMP REAL LA ORELE DE LABORATOR
UN FEL DE HOTFIX

ANEXA 0

Modelul cascadă
În modelul cascadă, cunoscută şi sub numele de modelul „secvenţial”, are loc mai întâi faza de
analiză, apoi cea de proiectare, urmată de cea de implementare şi testare, iar în final operarea şi
mentenanţa. Echipele care se ocupă de fiecare fază pot fi diferite, iar la fiecare tranziţie de fază
poate fi necesară o decizie managerială. Principalele etape ale modelului cascadă sunt
următoarele:

 analiza şi definirea cerinţelor. Serviciile, constrângerile şi obiectivele sistemului sunt iniţial

stabilite prin consultare cu utilizatorii sistemului. Aceste cerinţe sunt definite în detaliu şi
servesc ca specificaţie a sistemului.
 proiectarea sistemului şi a software-ului. Procesul de proiectare a sistemului partiţionează
cerinţele ca fiind de natură hardware sau software. Etapa aceasta are de asemenea rolul de
a stabili arhitectura generală a sistemului. Proiectarea software-ului prespune identificarea
şi descrierea abstractizărilor software ale sistemului fundamentale şi a interacţiilor între
acestea.
 implementarea şi testarea sistemului. În această etapă sunt integrate şi testate diversele
unităţi individuale de program în cadrul unui sistem complet pentru a se asigura faptul că
cerinţele software cerute au fost îndeplinite. După testare sistemului software este livrat
clientului.
 operarea şi mentenanţa. În mod normal (deşi nu şi necesar) aceasta reprezintă cea mai
lungă dintre fazele modelului. Sistemul este instalat şi dat spre folosire. Mentenanţa
presupune corectarea erorilor ce nu au fost descoperite în etapele anterioare a ciclului de
dezvoltare, îmbunătăţirea implementării unităţilor sistemului şi îmbunătăţirea serviciilor
oferite de sistem pe măsură ce sunt descoperite şi adoptate noi cerinţe de exploatare.

Rezultatul fiecărei etape reprezintă unul sau mai multe documente ce sunt aprobate (eng. „signed
off”). Următoarea fază nu poate începe până când faza anterioară nu s-a terminat. În practică însă
fazele pot fi întreţăsute astfel încât informaţii din fiecare etapă pot influenţa rezultatele altei etape.
În timpul proiectării, de exemplu, pot fi identificate diverse probleme legate de cerinţe incorecte
formulate în etapa de analiză. Procesul software, în practică, nu este un simplu model secvenţial ci
presupune o secvenţă de iteraţii ale activităţilor de dezvoltare.
Metodologia secvenţială este potrivită când complexitatea sistemului este mică iar cerinţele sunt
statice. Ea spune că mai întâi trebuie să ne gândim ce trebuie construit, apoi să stabilim un plan
de lucru şi apoi să realizăm proiectul, ţinând cont de standardele de calitate. De asemenea, se
aliniază metodelor de inginerie hardware. Forţează menţinerea unei discipline de lucru care evită
presiunea scrierii codului înainte de a cunoaşte precis ce produs va trebui de fapt construit. De
multe ori, echipa de implementare se află în situaţia de a programa înainte de finalizarea analizei,
ceea ce conduce inevitabil la descoperirea unor părţi de cod inutile sau care contribuie foarte puţin
(poate chiar şi ineficient) la funcţionalitatea produsului final. Totuşi, acest cod devine un balast
foarte costisitor: dificil de abandonat şi greu de schimbat. Această metodologie forţează analiza şi
planificarea înaintea implementării, o practică foarte nimerită în multe situaţii. Un mare număr de
sisteme software din trecut au fost construite cu o metodologie secvenţială. Multe companii îşi
datorează succesul acestui mod de realizare a programelor. Trebuie spus totuşi şi că presiunea de
schimbare din partea surselor externe era destul de limitată la momentul respectiv. Unul din
principalele dezavantaje ale metodologiei secvenţiale este faptul că acordă o foarte mare
importanţă fazei de analiză. Membrii echipei de analiză ar trebui să fie probabil clarvăzători ca să
poată defini toate detaliile aplicaţiei încă de la început. Greşelile nu sunt permise, deoarece nu
există un proces de corectare a erorilor după lansarea cerinţelor finale. Nu există nici feedback de
la echipa de implementare în ceea ce priveşte complexitatea codului corespunzător unei anumite
cerinţe. O cerinţă simplu de formulat poate creşte considerabil complexitatea implementării. În
unele cazuri, este posibil să fie chiar imposibil de implementat cu tehnologia actuală. Dacă echipa
de analiză ar şti că o cerinţă nu poate fi implementată, ei ar putea-o schimba cu o cerinţă diferită
care să satisfacă cele mai multe dintre necesităţi şi care să fie mai uşor de efectuat. Comunicarea
dintre echipe este o problemă. În mod tradiţional, cele patru echipe pot fi diferite iar comunicarea
dintre ele este limitată. Modul principal de comunicare sunt documentele realizate de o echipă şi
trimise următoarei echipe cu foarte puţin feedback. Echipa de analiză nu poate avea toate
informaţiile privitoare la calitate, performanţă şi motivare. Într-o industrie în continuă mişcare,
metodologia secvenţială poate produce sisteme care, la vremea lansării, să fie deja învechite.
Accentul atât de mare pus pe planificare nu poate determina răspunsuri suficient de rapide la
schimbare. Ce se întâmplă dacă clientul îşi schimbă cerinţele după terminarea fazei de analiză?
Acest lucru se întâmplă însă frecvent; după ce clientul vede prototipul produsului, el îşi poate
schimba unele cerinţe.

DEZVOLTAREA EVOLUŢIONARĂ (PROTOTIPIZARE)

O problemă generală care apare la dezvoltarea unui program este să ne asigurăm că utilizatorul
obţine exact ceea ce vrea. Prototipizarea vine în sprijinul rezolvării acestei probleme. Încă din
primele faze ale dezvoltării, clientului i se prezintă o versiune funcţionala a sistemului. Această
versiune nu este întregul sistem, însă este o parte a sistemului care cel puţin funcţionează.
Dezvoltarea evoluţionară se bazează pe dezvoltarea unei implementări iniţiale, expusă
comentariilor utilizatorului şi rafinarea ei şi producerea de noi versiuni până când este dezvoltat
sistemului final (fig. 2). Activităţile de specificare, dezvoltare şi validare sunt întreţăsute.
ANEXA 1

Capitolul 2 va descrie sistemul prin intemediul analizei funcționalităților și a diagramelor

UML, cu scopul oferirii unei caracterizări vizuale ale sistemului și a facilităților sale. Astfel,
în subcapitolele respective vor fi întîlnite diagrame ce descriu sistemul din punct de vedere
structural, analizînd elementele sistemului și modul de interacține dintre ele, cît și temporal, în
care vor fi descrise procesele ce au loc în sistem și ordinea lor de execuție.
Diagramele UML sunt folosite pentru a mări semnificativ eficiența și calitatea proiectării
și analiticii sistemului. Folosind diverse diagrame UML pentru a descrie sistemul și a
exemplifica anumite cazuri specifice ale sistemului dat, putem asigura o comunicare eficientă
atît între membrii echipei de dezvoltare a sistemului, cît și dintre utilizator și client.
Limbajul de modelare poate fi folosit în mod iterativ pentru a asigura o înțelegere
aprofundată a cerințelor tehnice și funcționale ale sistemului. Cu prima iterație, putem folosi
limbajul UML la nivel înalt pentru identificarea obiectivelor și a funcționalităților elementare
ale aplicației. Cu fiecare iterație nouă, putem aprofunda complexitatea diagramelor pentru a
afișa sistemul în mod mai detaliat.
Astfel, odată cu finisarea proiectării diagramelor UML va fi obținută o descriere
completă a sistemului, a modului de funcționare a său și a elementelor sistemului respectiv.
Considerînd informația dată, au fost implementate diverse tipuri de diagrame UML împreună
cu o descriere teoretică inițială, pentru a oferi o descriere cît mai aprofundată și completă a
sistemului și a funcționalităților sale.
Capitolul dat divizează diverse tipuri de diagrame UML în anumite subcapitole, în
dependență de rolul diagramelor respective. Astfel, diagrama cazurilor de utilizare este folosită
pentru a descrie posibilitățile utilizatorului legate de interacțiunea cu aplicația, diagramele de
activitate descriu fluxurile de date și modul de desfășurare a proceselor din sistem, diagramele
de secvență și componente oferă o descriere temporală a proceselor sistemului, etc.
Descrierea diagramelor UML începe cu descrierea diagramelor Use-Case pentru
identificarea posiblităților utilizatorului. În acest tip de diagrame putem vizualiza clar
totalitatea abilităților utilizatorului de interacțiune cu aplicația. Din momentul finisării
descrierii Use-Case, sunt descrise diagramele de activități, ce afișează fluxul acțiunilor din
sistem, diagrama de secvență și colaborare, ce afișează modul de interacțiune dintre diverse
componente ale sistemului, , diagrama de clase, ce descrie sistemul la nivel de clase și
comunicarea dintre ele.
De asemenea, sunt prezente și diagramele de colaborare și amplasare pentru o definire
structurală a sistemului informațional la nivel fizic.
ANEXA 2

Figura 2.1 - Diagrama cazurilor de utilizare general

 Figura 2.2 - Diagrama cazurilor de utilizare a funcționalităților.

Figura 2.3 - Diagrama cazurilor de utilizare a posibilităților legate de accesarea cărții

Figura 2.4 - Diagrama cazurilor de utilizare a posibilităților
Figura 2.5 - Diagrama de activități pentru logarea în system

Figura 2.6 – Diagrama de activități ai plasării unui review

Figura 2.7 - Diagrama de activități de căutare a unei cărți
Figura 2.8 - Diagrama de secvență de afișare și ștergere a unei cărți
Figura 2.9 - Diagrama de secvență a serializării JSON
Figura 2.10 - Diagrama de secvență a setării imaginii de profil

Figura 2.11 - Diagrama de colaborare al accesării unei cărți

Figura 2.12 - Diagrama de colaborare al mecanismului de caching

Figura 2.13 - Diagrama de clase Bookshelf

Figura 2.14 - Diagrama de clase Book
 Figura 2.15 - Diagrama de clase BookViewController

Figura 2.16 - Diagrama de componente a modulelor aplicației

Figura 2.17 - Diagrama de componente ale aplicației

Figura 2.18 - Diagrama de amplasare a sistemului