UNIVERSITATEA DE STAT DIN MOLDOVA

FACULTATEA „MATEMATICĂ ŞI INFORMATICĂ”

DEPARTAMENTUL “INFORMATICĂ”

Rotaru Cristina

Lucrul individual
la disciplina „Proiectarea Sistemelor Informatice”
STUDIU DE CAZ
Sistem informatic pentru evidența comenzilor într-un atelier de cusut
(evidenţa intrărilor, cu înregistrarea caracteristicilor şi a prestării
serviciilor de repararea, confecționarea vestimentelor).

Coordonator: Gladei Anatol

Autorul: Rotaru Cristina, gr. IA-1801

Chişinău, 2020
 Cuprins
Formularea problemei şi analiza domeniului de studiu........................................................3
Argumentarea necesității modernizării sistemului informațional din organizație, prin
dezvolatrea sistemului informatic...........................................................................................9
Evidențierea utilizatorilor SI și ale funcționalităților oferite acestora..............................11
Modelarea cazurilor de utilizare folosind diagramele activităților și modelarea unor
interfețe grafice, specifice cazului de utilizare.....................................................................18
Elaborarea modelului domeniului și evidențierea claselor conceptuale............................26
Modelarea interacțiunii dintre obiectele domeniului. Evidențierea responsabilităților
obiectelor domeniului.............................................................................................................28
Descrierea soluțiilor tehnice în baza operațiilor de sistem. Construirea diagramei
claselor de programare. Adăugarea atributelor și a metodelor claselor...........................31
Planificarea inițială a proiectului SI.....................................................................................32
Formularea problemei şi analiza domeniului de studiu

Prezentarea domeniului/firmei/instituţiei/organizaţiei studiate.

Industria textilă și a confecțiilor este o subramură cu o mare vechime, își are
începuturi stravechi sub forma casnic - meșteșugărească și se transformă în industrie
mecanizată în secolul al XVU-lea, prin aparitția primei manufacturi textile în
orașul Manchester din Anglia. În secolul al XVEI-lea se perfecționează războiul de țesut, mașina
de tors, răspândindu-se în fabricile din Anglia și din alte țări europene, precum și
în America, Asia. La început se foloseau ca materii prime cele de origine vegetală și animală,
apoi, la sfârșitul secolului al XlX-lea, fibrele celulozice (artificiale) obținute prin chimizarea
lemnului, iar in secolul al XX-lea - în deceniul al IV-lea -, încep să se folosească cele chimice
(sintetice). În ultimul deceniu al secolului al XlX-lea apar mutații în
repartiția geografică a acestei industrii, dezvoltându-se nu numai în țările vest-europene, ci și în
Japonia și S.U.A.
Produsele vestimentare confecționate la comandă sunt cele mai populare deoarece
într-o oarecare măsur sunt unice pe piață. În ultimul timp au devenit produse care cel mai des
sunt comandate în atelierele de cusut. De asemenea un atelier poate să producă vestimentele
pentru magazine specializate în domeniul vânzării hainelor.
Pentru atelierul de cusut “ Natali Design ” care confecționează produse vestimentare, a
apărut necesitatea creşterii afacerii şi în acest scop atelierul îşi propune dezvoltarea unei
aplicaţii web. Aplicaţia va promova atelierul, produsele, asigurând clientului o comoditate
pentru a vedea varietatea de produse. Aplicaţia web va fi utilă pentru promovarea, evidenţa
comenzilor şi a livrărilor acestora .

Descrierea produsului şi a procesului de producere

Un produs vestimentar poate fi cusut din stofă naturală, amestic sau sintetică, piele
naturală și blănuri. Conform tehnologiei de producere apoximativ 55-50% din produse sunt
confecționate din stofă naturală și deja 45-50% din sinteică și amestic. Deja în dependeță de
dorința clietului și de stofa care o procură atelierul.
Materialele folosite pentru confecționarea sau repararea uni produs vestimentar sunt:
 materialele țesute- produs textil obținut prin împletirea unor sisteme de fire reciproc
perpendiculare. Firele așezatepe verticală, respectiv pe lungimea țesăturii constituie
sistemul de urzeală (U), firele așezate pe orizontală, respectiv pe lățimea țesăturii,
formează sistemul de bătătură (B), figura 1.1.
 Figura 1.1. Elemente ale țesăturii
 materialele textile nețesute- se obțin din fibre textile, sisteme de fibre sau materiale
de carcasă, fixate prin consolidare mecanică sau chimică.
 materiale tricotate- produs textil, alcătuit din ochiuri legate între ele, aranjat sub
formă de șiruri și rânduri. Succesiunea de ochiuri înlănțuite pe direcția orinzontală
formează rândul de ochi (A), iar pe direcție verticală- șirul de ochiuri (B), figura 1.2.

Figura 1.2. Structura ticotului

Produsele vestimentare sunt realizate din materiale de bază, care formează stratul superior
al produsului (țesături, tricoturi, blănuri, piei) și materialele auxiliare sunt utilizate atât în
interiorul, cât și pe fața produsului de îmbrăcăminte (căptușeli; întărituri; dubluri; furnituri-ațe
de cusut, nasturi, copci, capse, fermuar și garnituri- dantele, panglici, broderii, șireturi, piele,
blănuri ).
Alegerea materialelor auxiliare se face în funcție de produs, materialele de bază și model.
Dacă clientul va dori livrarea produsului finisat acesta va fi ambalat în pungi eco. Pungile se
comandă la magazin specializat in domeniu, iar costul lor formează aproximativ 8-10% din
costul produsului vestimentar.
Vânzările cele mai mari sunt puse pe seama clienţilor permanenţi, care comandă
vestimente pentru fiecare anotimp al anului. Ponderea cea mai mare printre astfel de clienţi o
reprezintă femeile între 25-50 ani și de asemenea bărbații care doresc să modifice aspectul
unor vestimente.
Pentru distribuire pot fi folosite automobile mici sau motociclete adaptate. Costul
distribuirii alcătuieşte aproximativ 8-10% din costul produsului. În unele cazuri sunt angajaţi
distribuitori cu transportul propriu (în acest caz costul de distribuţie scade în medie cu 25%).
Pentru a fi posibilă distribuţia operativă a vestimentelor trebuie să fie un control permanent
din partea managerului şi o conlucrare intensă între operatorul responsabil de primirea
comenzilor, tehnicianului, cusătoreselor şi distribuitorul de produse.
Operatorul primeşte şi înregistrează comanda, predă detaliile comenzii tehnicianului, care
distribuie sarcinile pentru confecționarea sau repararea vestimentelor cusătoreselor. Când
vestimentul este finisat operatorul consultă comanda şi în cazul în care clientul dorește
livrarea produsului la domiciliu, atunci se adaugă costul livrării la suma din bonul de plată
total, apoi înmânează comanda distribuitorului, îi da bonul şi adresa unde trebuie dusă
comanda. Operatorul înregistrează ora începutului livrării şi ora finisării livrării şi achitării
comenzii. În cazul în care se întâmplă ceva în procesul distribuirii se înregistrează acest fapt.
Managerul este responsabil de supravegherea întregului proces şi tot el verifică nivelul de
satisfacţie al clienţilor. Deasemenea este responsabil de promovarea atelierului și de calitatea
produselor.
Ca rezultat al activităţii de fabricare şi vânzare a produselor vor fi făcute zilnic rapoarte de
activitate destinate contabilităţii, referitoare la încasări şi deasemenea tehnicianul va face
rapoarte referitoare la necesităţile de materie primă adresate secţiei depozitare şi
aprovizionare.

Specificarea principalelor (sub)sisteme informaţionale.

Un sistem informaţional reprezintă un ansamblu complex şi organizat de oameni, mașini,
programe, procedee și activități practice, concretizate în compartimente cu legături
informaţionale, alcătuind cadrul organizatoric prin intermediul căruia se elaborează și se
folosesc informațiile. Altfel spus, sistemul informaţional constituie o mulţime de resurse
(umane, materiale, tehnice) care colectează datele şi informațiile (din interiorul companiei şi
din exteriorul acesteia), le transformă într-o formă comodă pentru a fi utilizate de fiecare
treaptă de conducere, transmite și prelucrează deciziile, urmăreşte efectele aplicării acestora,
atât în timpul execuţiei, cât și după terminarea acţiunii lor.

Subsistemele informaţionale ale atelierului de cusut „Natali Design” corespund

componentelor funcţionale, iar toate agregate formează sistemul informaţional al companiei.
În continuare vor fi descrise componentele funcţionale ale atelierului de cusut „Natali
Design”.

La moment, în cadrul atelierului sunt folosite doar două aplicaţii: în departamentul

„Finanţe” a fost implementată aplicaţia 1C pentru evidenţa contabilă al atelierului în sectoare
precum: operaţiuni referitoare la bancă, mijloace fixe şi active nemateriale, materie primă şi
servicii, calcularea salariului etc. În secţia „Managementul resurselor umane” este o aplicaţie
„Access” pentru evidenţa datelor angajaţilor.

Prezentarea structurii organizaţionale.

Pot fi evidenţiate câteva subdiviziuni de bază responsabile de activitatea atelierului de
cusut „Natali Design”:

- Componenta de administrare – responsabilă de luarea deciziilor la nivelul

întregului atelier şi planificare strategică a activităţii acestuia.
Rolul/funcţia de bază care poate fi evidenţiată la acest nivel este Directorul
general – care este şi proprietarul atelierului şi autoritatea, responsabilă de luarea
ultimei decizii. El gestionează toate direcţiile/departamentele atelierului, stabileşte
atribuţii concrete managerii principalelor direcţii, aprobă atribuţiile stabilite de
managerii de nivel 2. Directorii tuturor direcţiilor trebuie să-i raporteze mereu
referitor la performanţele sau problemele înregistrate în departamentul pe care-l
administrează.

- Departamentul de producere – responsabil de producerea calitativă a produsului

de baza promovat de atelier – confecționarea, repararea vestimentelor. Acest
departament este condus de Directorul „producere”, care este persoana
responsabilă de confecționarea sau repararea vestimentelor şi care asigură
satisfacerea nivelului de calitate necesar acestui produs.
- Departamentul de vânzări şi marketing – este responsabil de promovarea şi
vânzarea producţiei atelierului. Directorul „Vânzări” este responsabil de
executarea corectă a proceselor de activitate precum marketing, vânzări şi
distribuţie.
 - Departamentul logistică – are ca funcţii de bază aprovizionarea, activităţile de
susţinere a producţiei, distribuţia fizică a producţiei. Directorul „Logistică”
asigură activitatea curentă în companie şi urmăreşte să fie onorate la timp
comenzile şi aprovizionată cu materie primă în secția de cusut (secţia producere).
- Departamentul „Finanţe” – are în componenţa sa procese de activitate precum
„Evidenţa contabilă”, „Evidenţa financiară”, „Evidenţa conturilor” şi „Evidenţa
mijloacelor fixe şi circulante”. Contabilul este persoana care are rolul de a face
politici de ordin financiar în atelier, pentru a satisface necesităţile tuturor
departamentelor în ceea ce priveşte bugetele etc.
- Secţia „managementul resurselor umane”, în frunte cu Managerul „Resurse
umane” are în responsabilitate administrarea resurselor umane ale companiei şi
urmăreşte să nu se încalce drepturile acestora. Această direcţie este responsabilă de
angajarea specialiştilor necesari în toate departamentele atelierului, calificarea şi
perfectarea resurselor umane în timp, respectarea drepturilor angajaţilor la locul de
muncă, transferul dintr-un departament în altul sau avansarea în funcţie, păstrarea şi
completarea corespunzătoare a documentaţiei de angajare şi concediere a
angajaţilor.
Organigrama este reprezentarea schematica a structurii organizatorice a unei
întreprinderi, a unei institutii, a subordonării compartimentelor acestora, a tipurilor de
legături între aceste compartimente. În mod obişnuit organigrama este alcătuită din
dreptunghiuri ce reprezinta posturi de conducere sau compartimente şi din linii care reflectă
legăturile organizatorice.

Organigramele pot fi construite pentru:

- întreaga organizaţie - organigrame generale sau de ansamblu, în care se

reprezinta grafic structura organizatorica a intregii unitati economice;
- pentru o careva componentă a organizaţiei - organigrame parţiale care reflectă
detaliat un compartiment sau o grupa de compartimente ale structurii
organizatorice respective.
Principalele reguli necesare a fi respectate la construirea organigramelor:

a) marimile dreptunghiurilor şi grosimile contururilor acestora se coreleaza cu

obiectul, sarcinile, autoritatea si responsabilitatea implicate, cu alte cuvinte
 patrulaterele pentru servicii trebuie sa fie mai mari si cu contururile mai groasee
decat cele pentru birouri etc;
b) situarea în organigramă a dreptunghiurilor şi liniilor trebuie să reflecte raportul de
subordonare ierarhică, toate posturile si compartimentele care alcatuiesc un nivel
ierarhic inscriindu-se pe aceeasi orizontala;
c) organigramele complexe, indeosebi cele care exprima mai multe tipuri de relatii
organizatorice, trebuie sa cuprinda legende cu semnificatia simbolurilor utilizate.
În cadrul atelierului “Natali Design” structura organizatorică este bazată pe funcţii
(structură organizatorică funcţională). Activităţile companiei sunt grupate după funcţii în
departamente, care la rândul lor grupează mai multe posturi cărora le revin sarcini cu caracter
permanent, descrise detaliat în fişa de post. Astfel, pot fi evidenţiate trei trepte ierarhice de
management:

- Nivelul 1, de conducere a întregii companii, reprezentat de directorul

general;
- Nivelul 2, de conducere a departamentelor, care au în subordine şefii
secţiilor şi au legături funcţionale cu alţi manageri aflaţi pe aceeaşi linie. Iau
decizii la nivel de departament;
- Nivelul 3, de conducere a secţiilor. La acest nivel pot fi evidenţiaţi şefii de
secţii, care iau decizii la nivelul secţiilor şi asigură buna desfăşurare a
activităţii atelierului, deoarece se află pe scara ierarhică cel mai aproape de
personalul de la nivelul operaţional.
Argumentarea necesității modernizării sistemului informațional din
organizație, prin dezvolatrea sistemului informatic

Obiectivul general urmărit la dezvoltarea şi implementarea Sistemului Informatic în

„Natali Design” este: creşterea productivităţii şi a calităţii deservirii clienţilor. Obiectivele
specifice pot fi mai multe:

1. Odată cu implementarea sistemului informatic va creşte şi eficienţa activității

atelierului, prin reorganizarea mai multor procese interne;
2. Sistemul informatic va fi utilizat şi la gestionarea datelor referitoare la încasările
realizate zilnic;
3. Se vor eficientiza activităţile la nivelul departamentelor de producere şi deservire, ca
urmare a instruirii personalului, care vor utiliza sistemul informatic şi a celui care va
asigura mentenanţa acestuia.
4. Va creşte cifra de afaceri şi profitul atelierului;
5. Se va îmbunătăţi comunicarea în atelier, realizând o mai bună cooperare şi interacţiune
între diverse departamente, inclusiv între cele direct implicate: confecționare şi
vânzări;
6. Se vor întări relaţiile cu clienţii unităţii comerciale.

Denumirea sistemului Sistem informatic pentru evidența comenzilor întrun

informatic atelier de cusut „Natali Design”

Destinaţia (pentru ce este Sistemul informatic va fi utilizat pentru:

necesar)
- informarea clienţilor permanenţi despre noile produse
sau noile oferte ale atelierului – se va crea o pagină
web informativă, iar din BD vor fi preluate date din
sistem referitoare la adresele de e-mail, telefon,
modalităţi de informare etc.;
- preluarea comenzilor direct de la client – pentru
aceasta va fi creată o pagină web care va conţine un
formular necesar captării datelor. Acest formular va
putea fi utilizat direct de client sau de managerul
responsabil de comenzi, în cazul în care clientul
telefonează şi nu dispune de accesul la pagina web;
- înregistrarea comenzii şi generarea bonului de plată;
- înregistrarea livrării comenzii (sau în cazul
 accidentelor - a nelivrării comenzilor);
- recepţionarea pretenţiilor şi a feedback-ului de la
clienţi – va fi creat un formular pentru feedback;
- evidenţa încasărilor zilnice (vestimente + reparare);
- generarea rapoartelor de activitate (pentru contabilitate
şi administraţie).
Utilizatorii SI Sistemul informatic va avea câţiva utilizatori de bază:

- manager-comenzi;
- manager-vânzări;
- client;
- administrator sistem.
Ce probleme vor fi 1. Vor fi colectate şi păstrate date referitoare la
soluţionate la implementarea clienţii permanenţi al atelierului;
SI 2. Vor fi colectate şi păstrate date referitoare la
comenzi şi încasări;
3. Vor fi extrase date referitoare la încasări pentru a
genera rapoarte despre încasări, care apoi vor fi
analizate;
4. Vor fi extrase date referitoare la zilele cu cele mai
multe comenzi din lună sau cele mai solicitate
vestimente, vor fi generate informaţii, iar apoi vor
fi analizate
5. Vor fi asigurate cu informaţiile necesare, în timp
util departamentele care conlucrează cu
departamentul de producere şi vânzări.

Notă: La necesitate acest sistem va putea fi extins adăugând drept utilizator administratorul
din secţia de producere, care va duce evidenţa materie prime necesare în secția de cusut şi va
putea face rapoarte despre consumul eficient a materiei prime. De asemenea, pot fi create
interfeţe grafice de acces la date, persoanelor din afara celor două secţii examinate,
responsabile de analiza datelor şi de luarea deciziilor în companie (spre exemplu directorului
general, unor angajaţilor din departamentul contabilitate, departamentul aprovizionări etc.)
 Evidențierea utilizatorilor SI și ale funcționalităților oferite acestora
Internetul a revoluționat posibilitățile businessului din toată lumea. Pentru a face față
concurenței, organizațiile de confecții, trebuie să fie prezente și în mediul online, efectuând
comenzile în regim online în dependență de caz și realizarea publicității referitor la calitatea
produselor confecționate sau reparate.
Formularea problemei
Un anumit producător de confecți propune cumpărarea vestimentelor deja
confecționate sau confecționarea unei ținute noi după dorința clientului și deja posibilitatea
reparării vestimentelor prin intermediul unei aplicații, ce prezintă produsele și servicile sale
clienților și care poate apoi fi utilizată pentru gestiunea comenzilor făcute de clienți.
Un anumit client, care accesează pagina web a producătorului, poate să-și aleagă
ținuta dorită, din cele propuse. Producătorul propune în paginile aplicației: confecționarea
vestimentelor pentru sezonul rece al anului, sezonul cald, modele de rochii de ocazie,
îmbrăcăminte ușoară și intermediară. Utilizatorul poate vizualiza poze și detalii referitoare la
fiecare produs și apoi poate efectual completarea unui formular cu date personal pentru ca
ulterior să fie contactat.
Astfel, utilizatorii își poat alege înainte de a veni în atelier vestimentul dorit din cele
propuse sau poate să-și modeleze modelul dorit în regim de dialog selectând variantele
necesare lui.
Componentele vestimentelor alese (de exemplu: stilul, pentru ce vârstă, genul,
destinația, stofa etc.) sunt prezentate utilizatorului sub formă de liste expandabile, din care
utilizatorul își alege alternativa dorită. Pentru fiecare configurație nou aleasă sistemul
calculează și afișează prețul aproximativ, pentru a-l informa pe user.
Pentru a înregistra comanda în sistem, clientul (utilizatorul trece în categoria de client
odată ce se decide să facă o comandă) trebuie să completeze formularul cu informații despre
el (precum: numele, prenumele, nr. telefon, email, adresa și are posibilitatea să-și aleagă ora și
ziua programării), în final se transmite clientului un mesaj informativ despre finisarea
comenzii pentru a veni și verifica dacă produsul corespunde. Achitarea se realizează în atelier
în calitate de metodă de achitare se admit: cardurile bancare și banii cash.
După înregistrarea comenzii, sistemul îi propune clientului să mai verifice odată
detaliile comenzii, iar apoi salvează datele într-o BD. Apoi sistemul îi va expedia clientului pe
mail un mesaj cu toate detaliile comenzii și cu confirmarea că a fost înregistrată o astfel de
comandă în sistem, cu un anumit număr unic.  
După ce clientul a fost în atelier pentru ca să fie luate masurile necesare și
concretizarea anumitor detalii referitoare la modelul ales, clientul poate să verifice starea
comenzii lui în baza unui cod de identificare a comenzii referitor la confecționarea sau
repararea vestimentului.
Partea server a sistemului, va fi responsabilă de prelucrarea tuturor datelor
recepționate de la utilizatori: verificare, stocare, generare informații necesare utilizatorilor, să
trimită înștiințări operatorului depozitului la recepționarea unei noi comenzi, cu toate detaliile
modelului ales sau dacă urmează să fie reparația vestimentului, inclusiv cu factura pentru
comandă. Operatorul depozitului va verifica dacă sunt stofele necesare pentru confecționare
sau pentru repararea vestimentului.
Deci, un alt utilizator al acestui sistem este operatorul depozitului, care, suplimentar,
gestionează îndeplinirea comenzilor sau neonorarea unor comenzi (specificând motivul și
închizând comanda) și care gestionează conținutul paginilor ce propun produsele clienților
(modifică prețuri, editează detaliile produselor, inclusiv imagini etc.).
Cel de-al treilea utilizator este administratorul sistemului, care are acces deplin la toate
resursele sistemului, inclusiv la gestionarea conturilor utilizatorilor, managementul
conținuturilor web propuse utilizatorilor, gestiunea BD, gestiunea fișierelor de log-uri etc.
Diagrama de context prezintă sistemul și principalii actori, care au un anumit rol în
utilizarea sistemului, vezi figura 3.1
 Figura 3.1. Diagrama de contex

Toate cazurile de utilizare sunt prezentate în diagrama cazurilor de utilizare

(figura3.2).

Figura 3.2. Diagrama cazurilor de utilizare

Formularea cerințelor funcționale, în ordine prioritară
Componenta ”client”:
1. Sistemul trebuie să-i permită clientului să vizualizeze produsele oferite și
specificațiile acestora (poze, preț, descrieri);
2. Sistemul trebuie să-i permită clientului să configureze un nou produs din
componentele disponibile, și să-i prezinte utilizatorului specificațiile componentelor
alese, sau posibilitatea de-a alege un produs vestimentar finisat inclusiv să calculeze și
afișeze prețul aproximativ al produsului sau serviciului;
3. Sistemul trebuie să-i permită utilizatorului să înregistreze comanda produsului (cu
configurație standard sau configurat de user).
4. Sistemul trebuie să-i permită clientului să verifice starea comenzii lui în baza unui cod
de identificare a comenzii;
Componenta ”operator depozit”:
5. Sistemul trebuie să-i permită operatorului vizualizarea datelor despre comenzile
realizate de clienți;
6. Sistemul trebuie să-i permită operatorului să gestioneze (editeze: adăugare,
modificare) datele produselor (preț, descriere, disponibilitate etc.);
7. Sistemul trebuie să-i ofere operatorului posibilitatea editării stării comenzii (la intrare
comanda automat trece în starea ”înregistrată”. Pe parcurs starea ei poate fi ”în proces
de prelucrare”, ”finisată” etc.).
Componenta ”administrator”:
8. Sistemul trebuie să-i permită administratorului să gestioneze (adăugare, modificare,
lichidare) datele despre utilizatori și conturile lor;
9. Sistemul trebuie să-i permită administratorului să gestioneze (adăugare, modificare,
lichidare) toate datele referitoare la produse (preț, descriere, disponibilitate etc.);
10. Sistemul trebuie să-i permită administratorului să gestioneze (adăugare, modificare,
lichidare) componentele aplicațiilor sistemului.
Formularea cerințelor nefuncționale
a) Cerințe față de securitatea aplicațiilor sistemului
Pentru a realiza sistemul funcțional, dar și cât de cât securizat, se vor mai precăuta câteva
funcții, ce vor trebui adăugate în aplicațiile sistemului, și care vor proteja sistemul.
Prezentarea grafică a lor poate fi analizată în imaginea 3.
 Figura 3.3. Adăugarea funcțiilor ce reies din cerințele de securitate

Astfel, pentru utilizatorul ”client” vor mai fi adăugate câteva funcții care reies din necesitățile
de securizare a sistemului:

1. Sistemul va genera un cod unic, corespunzător comenzii, și i-l va returna clientului,

pentru ca acesta să poată verifica, în baza lui, starea comenzii;
2. Sistemul va valida toate datele introduse de client și nu va permite introducerea
simbolurilor nepermise de aplicațiile sistemului – cu scopul asigurării integrității
aplicațiilor sistemului, dar și a BD cu care interacționează aplicația.

În mod analogic se va proceda și pentru utilizatorii: operator și administrator – aceștia vor

avea acces la toate funcționalitățile lor doar după autentificare și autorizare, verificând dreptul
lor de acces la date. De asemenea, toate datele pe care le vor introduce acești utilizatori (cu
scopul creării de noi înregistrări sau modificării celor deja existente) vor fi supuse validărilor.

Suplimentar:
1. Aplicaţiile sistemului nu trebuie să permită distrugerea nesancţionată a datelor, care
sunt expediate clienţilor sau altor utilizatori din exterior;
2. Aplicaţiile sistemului nu trebuie să permită distrugerea datelor colectate de la clienţi
sau de la alţi utilizatori din exterior.
 3. Sistemul trebuie să găsească şi să înregistreze (jurnalizeze) toate încercările de acces
neautorizat.
4. Sistemul înregistrează (jurnalizează) toate încercările de accesare a acestuia, inclusiv
cele nesancționate.
5. Sistemul informează administratorul referitor la o a doua încercare nereușită de
accesare a aplicației.
6. Aplicaţia trebuie să creeze şi să păstreze, pentru a nu fi accesate nesancționat,
înregistrările referitoare la fiecare tranzacţie efectuată de utilizatori:
 Conţinutul tranzacţiei;
 Data şi ora efectuării tranzacției;
 Identitatea utilizatorului.

b) Cerinţe faţă de interfaţa-utilizator

1. Etichetele prezente în formularele aplicaţiei, trebuie să fie aliniate pe stânga, pentru o
uşoară citire a datelor prezentate.
2. Interfaţa-utilizator trebuie să ofere o navigabilitate eficientă prin sistem utilizatorului,
informându-l în procesul navigării asupra acţiunilor pe care le realizează şi ale celor
următoare.
3. Trebuie să fie folosite culori care nu sunt contrastante, iar textul să fie citibil şi să se
vadă de la o distanţă de 1-2 m.
4. Trebuie să fie posibilă accesarea şi navigarea prin pagini/formulare nu doar cu mouse-
ul, dar şi cu folosirea doar a tastaturii.
5. Toate paginile/formularele vor fi înzestrate cu un buton de ajutor, care va prezenta
informaţii referitoare la elementele de control prezente pe ecran.
6. Toate informaţiile prezentate în interfaţa sistem-utilizator să fie accesibile în limba
romană. Toate ecranele pentru introducerea datelor, administrarea nomenclatoarelor,
administrare parametri de sistem vor fi create în limba română.
7. Toate mesajele de eroare, avertizările, textele de ajutor, textele prezente în formulare –
să fie în limba română și uşor de înţeles pentru utilizatori, chiar şi de cei începători.
8. Fiecare câmp care trebuie completat de utilizator sau buton, trebuie să fie însoţit de un
text de ajutor scurt (la subsol, mărunt scris) care să explice cum poate fi completat sau
folosit acesta. De exemplu sub câmpul „parola” să fie scris „Parola conţine minimum
6 caractere și maximum 16, litere şi cifre, prima obligatoriu literă”.
9. Toate paginile/formularele trebuie să dispună de informaţia necesară folosirii eficiente
ale lor, astfel încât utilizatorul să nu părăsească pagina pentru a înţelege cum poate fi
ea utilizată.
10. Introducerile de date, în câmpuri, vor fi verificate (dacă aceasta este posibil: vârsta
cuprinsă între 0-120 ani etc.) la ieşirea din elementul de control. Dacă introducerea de
date este necesară să fie verificată în totalitate (există câmpuri dependente) această se
va face la părăsirea ecranului sau a formularului.
11. Scenariile comune trebuie să aibă acelaşi flux de trecere prin interfaţă, în aceeaşi
direcţie. De exemplu de sus în jos, de la stânga la dreapta.

c) Cerinţe faţă de documentaţie

Se va enumăra lista documentelor necesare a fi livrate.
 1. Lista documentelor utilizate pentru dezvoltarea SI: Reglementarea tehnica RT
38370656 - 002:2006.
2. La livrare SI trebuie să fie însoţit de următoarele documente:
a. Arhitectura şi documentaţia de proiectare, care conţine descrierea
mecanismului de asigurare a securităţii sistemului.
b. Codul-sursă al aplicaţiilor sistemului, inclusiv codul sursă responsabil de
mecanismul de securitate a SI.
c. Testarea securităţii şi rapoartele de testare a codului.
d. Rezultatele testării unităţilor funcţionale, inclusiv testarea securităţii unităţilor
funcţionale.
e. Manuale ce conţin instrucţiuni de utilizare a SI.
f. Documentele de instalare şi configurare a SI, care includ descrierea
configurării SI şi asigurarea securităţii.

d) Cerinţe faţă de fiabilitate

Fiabilitatea reprezintă capacitatea SI de a menţine un anumit nivel de performanţă, în
condiţiile în care acesta este utilizat corespunzător. Cerinţele faţă de fiabilitate trebuie să
includă şi o definire a eşecului folosirii SI. Frecvenţa eşecurilor presupune frecvenţa cu care
sistemul cedează în decursul unei ore, zile, lună sau an.
1. Pe durata exploatării SI trebuie să cedeze în medie de 5 ori anual.
2. Durata maximă de nefuncţionare a SI în decursul unui an nu trebuie să depăşească o
ora.
3. În cazul unei deconectări de la reţea (de exemplu de la curentul electric) în timpul
exploatării SI, la restabilirea activităţii acestuia sistemul va fi în aceeaşi stare ca şi la
deconectare.
4. Datele şi informaţiile cele mai importante trebuie să dispună de copii de rezervă,
păstrate în locuri şi condiţii sigure (pe loc – pentru restabilire rapidă, în exterior –
pentru asigurarea acţiunilor în condiţii extreme).

e) Cerinţe faţă de performanţă

Acest tip de cerinţe stabilesc limitele de performanţă aşteptate de la SI. Acestea pot fi
exprimate în diferite moduri: numărul de tranzacţii procesate pe secundă, timpul de răspuns la
solicitările utilizatorilor etc.
1. Aplicaţia de evidenţă a comenzilor trebuie să prelucreze cu succes un minim de 10 mii
de comenzi ale clienţilor pe zi, inclusiv autorizarea cardurilor bancare la înregistrarea
plaţilor.
2. Aplicaţia oferă utilizatorului un răspuns timp de până la 2 sec. Această cerinţă nu
include întârzierile survenite din cauza reţelei.

f) Utilizarea resurselor
Reprezintă capacitatea produsului software de a utiliza resursele adecvate atunci când
sistemul îşi îndeplineşte funcţionalităţile.
g) Cerințe față de portabilitate
 Reprezintă capacitatea produsului software de a fi portabil și după schimbare să fie
capabil să-și îndeplinească funcţionalităţile.
h) Cerințe față de dispozitivele periferice
Reprezintă capacitatea dispozitivelor periferice de a efectua transmiterea datelor calitativ
și la timp.

Modelarea cazurilor de utilizare folosind diagramele activităților și

modelarea unor interfețe grafice, specifice cazului de utilizare

Astfel, pentru cazurile de utilizare ale ”clientului”, prezentate în diagrama cazurilor de

utilizare (figura 4.1), acestea se vor descrie detaliat.
 Figura 4.1. Cazurile de utilizare pentru utilizatorul ’’client”

Cazul de utilizare: ”Vizualizează produsele și serviciile”

Descriere succintă: Caz de utilizare accesat de client pentru a vizualiza produsele și serviciile
(confecționarea, repararea vestimetelor) propuse de atelier.
Actori implicaţi: Clientul
Precondiţii: Utilizatorul a accesat pagina cu produsele atelierului.
Postcondiţii: Datele referitoare la produse au fost afișate și la solicitarea utilizatorului au fost
afișate și specificațiile lor.
Scenariul de bază reuşit:
1. Utilizatorul accesează opțiunea de afișare a produselor.
2. Sistemul extrage, toate detaliile ce trebuie prezentate utilizatorului din baza de date și i
le afișează într-o formă comodă clientului.
3. Dacă utilizatorul dorește vizualizarea detaliilor unui produs – le va accesa.
4. Sistemul îi va afișa utilizatorului la ecran toate specificațiile posibile referitoare la
produsul ales.
Scenarii alternative:
1.1. Utilizatorul dorește filtrarea produselor, în baza unor câmpuri.
1.2. Dacă sunt găsite produsele căutate - sistemul va afișa produsele solicitate. În caz
contrar – sistemul va genera un mesaj de informare a utilizatorului.
Schița paginii propuse clientului pentru vizualizarea produselor este prezentată în figura 4.2.

Figura 4.2. Prototipul paginii de prezentare a produselor și serviciilor

Și pagina ce conține specificațiile produsului este prezentată în figura 4.3.

 Figura 4.3. Detalii produs

Modelarea cazului de utilizare ”Vizualizează produsele și serviciile ” este prezentată

în figura 4.4.

Figura 4.4. Diagrama activităților pentru cazul de utilizare “Vizualizează produsele și serviciile”

Cazul de utilizare: ”Creează configurație proprie pentru produs”

Descriere succintă: Caz de utilizare accesat de client pentru a-și configura produsul conform
cerințelor proprii.
Actori implicaţi: Clientul
Precondiţii: Utilizatorul a accesat pagina cu produsele companiei, dar nu i-a plăcut nici un
produs din cele propuse și accesează ”modelare produs”.
Postcondiţii: Sistemul i-a permis utilizatorului modelarea propriului vestiment, apoi a calculat
costul nou al produsului și i l-a afișat utilizatorului.
Scenariul de bază reuşit:
1. Utilizatorul accesează opțiunea de creare a propriului model.
2. Sistemul îi afișează, în baza unor controale interactive, mai multe opțiuni pentru a crea
propriu model. Va evidenția componentele obligatorii ce trebuie specificate de
utilizator.
3. Utilizatorul selectează opțiuni pentru toate componentele propuse.
4. Sistemul calculează costul total și permanent îl reînnoiește.
Scenarii alternative:
3.1. Utilizatorul nu a selectat una sau mai multe opțiuni.
3.2. Sistemul posedă opțiuni predefinite pentru acele componente. Operatorul depozitului,
la recepționarea comenzii, va verifica existența materialelor și în cazul în care la
moment nu sunt în depozit – îl va contacta pe client și-i va propune substituirea cu alte
materiale.
Prototipul formularului de configurare a produsului este prezentat în figura 4.5.

Figura 4.5. O parte din formular de configurare a produsului

 Modelarea grafică a cazului de utilizare ”Creează configurație proprie pentru produs”
este prezentată în figura 4.6.

Figura 4.6. Diagrama activitatilor pentru cazul de utilizare ”Creează configurație proprie pentru
produs”

Cazul de utilizare: ”Înregistrează comandă produs”

Descriere succintă: Caz de utilizare accesat de client, pentru a-și înregistra comanda unui
produs vestimentar cu configurație standard sau cu configurație proprie.
Actori implicaţi: Clientul
Precondiţii: Utilizatorul a selectat produsul cu configurație standard sau și-a configurat
propriul produs.
Postcondiţii: Sistemul a verificat disponibilitatea de plată a utilizatorului – la plata cu cardul,
a verificat corectitudinea datelor introduse, dar utilizatorul poate să achite și cu banii cash.
După sistemul a înregistrat comanda și i-a trimis clientului un mesaj de confirmare a
înregistrării, împreună cu un cod alfa-numeric unic, corespunzător comenzii.
Scenariul de bază reuşit (plata cu cardul):
1. Utilizatorul accesează opțiunea de înregistrare a comenzii (preventiv având selectat un
produs pe care ar vrea să-l comande).
2. Sistemul îi afișează, formularul de înregistrare, în care deja sunt detaliile produsului
solicitat și-l roagă pe utilizator să mai introducă niște date cu caracter privat, precum:
numele, prenumele, numărul de telefon, emailul, tipul de plată. Dacă tipul de plată e
 ”cu card”, sistemul îi va afișa și un câmp în care va trebui introduse și rechizitele
bancare (numărul cardului, valabilitatea, codul CVV etc.)
3. Clientul completează câmpurile și tastează butonul de expediere și salvare a comenzii.
4. Sistemul validează toate datele. În cazul corectitudinii introducerii sistemul va genera
un cod unic corespunzător comenzii, format din litere și cifre, iar apoi va salva datele
în BD. Simultan va expedia confirmarea înregistrării comenzii pe mailul clientului. Iar
în cazul completării inadecvate a formularului de comandă – sistemul va genera o
avertizare și se vor relua acțiunile începând cu pasul 2.
Scenarii alternative:
1.1. Utilizatorul nu dispune de posibilitatea de a plăti cu cardul și specifică modul de plată
”cash”.
1.2. Sistemul nu-i va afișa clientului câmpurile corespunzătoare detaliilor referitoare la
card, dar îl va informa că plata se va realiza de client după finisarea podusului
vestimentar cu bani cash.
Prototipul formularului de înregistrare a comenzii este prezentat în figura 4.7.

Figura 4.7. Prototipul formularului de plată

 Modelarea grafică a cazului de utilizare ”Inregistrează comandă produs” este
prezentată în figura 4.8.

Figura 4.8. Înregistrează comandă produs

Cazul de utilizare: ”Vizualizează stare comandă”

Descriere succintă: Caz de utilizare accesat de client pentru a vizualiza starea comenzii lui.
Actori implicaţi: Clientul
Precondiţii: Utilizatorul a accesat cutia sa poștală și a preluat codul comenzii. Sistemul a
înregistrat starea inițială ”înregistrată” sau operatorul depozitului a schimbat starea comenzii
în ”în prelucrare”, ”expediată”, ”finisată”.
Postcondiţii: Sistemul i-a afișat starea comenzii utilizatorului într-o formă clară acestuia.
Scenariul de bază reuşit:
1. Clientul accesează opțiunea de vizualizare a stării comenzii.
2. Sistemul îi afișează clientului controlul pentru introducerea codului comenzii.
3. Utilizatorul introduce codul comenzii.
4. Sistemul îi afișează data, ora și care este starea comenzii, inclusiv și toate stările
preventive.
Scenarii alternative:
3.1. Utilizatorul introduce un cod incorect.
3.2. Sistemul îi afișează o avertizare clientului și din nou (se reia pasul 2) se va afișa
controlul pentru introducerea codului comenzii.
Prototipul formularului de căutare a stării comenzii este prezentat în figura 4.9.

Figura 4.9. Formularul de căutare și vizualizare a stării comenzii

Modelarea grafică a cazului de utilizare ”Vizualizează stare comandă” este prezentată

în figura 4.10.

Figura 4.10. Diagrama activitaților pentru ”Vizualizeaza stare comanda”

Elaborarea modelului domeniului și evidențierea claselor conceptuale

Analizând cazurile de utilizare descrise anterior, se va recurge la găsirea claselor conceptuale

specifice domeniului analizat.
Modelul domeniului se construiește în cadrul etapei de analiză OO. Mai este numit şi
model conceptual al Sistemului Informațional existent în domeniul supus cercetării. Modelul
poate fi construit ca un dicționar al tuturor claselor de noțiuni, implicate în diverse scenarii,
descrise anterior, fiind numit astfel şi „dicţionar vizual al domeniului”.
Modelul domeniului reprezintă o vizualizare ale claselor de noțiuni sau claselor
conceptuale sau ale obiectelor din lumea reală, depistate în domeniul analizat.
Pentru construirea modelului domeniului se va recurge la analiza descrierilor cazurilor
de utilizare, descrise anterior, și a evidențierii pretendenților la rolul de ”clase conceptuale”.
Nu toate substantivele din descrieri vor pretinde la rolul de ”clase conceptuale”. Unele
vor fi utilizate drept atribute, în clasele conceptuale.
1. Pentru a face cunoștință cu modelele vestimentare standarde a atelierului, clientul
folosește pagina web al atelierului. Sistemul va afișa prețul vestimentului,
corespunzător modelului.
Pretendenți: client, vestiment, fereastra_configurație, element_configurație
2. Clientul selectează detalii ale modelului, pe care ar dori să îl studieze, cu scopul
cumpărării vestimentului, cu configurația selectată. Sistemul poate calcula prețul
produsului pentru fiecare configurație, în funcție de cerințele utilizatorului.
Pretendenți: vestiment_configurat, element_configurație (se repetă)
3. Clientul poate să-și selecteze produsul de pe pagina web și apoi să recurgă la
întocmirea comenzii. În cazul în care anumite specificații nu-i sunt clare clientului,
acesta poate contacta operatorul depozitului pentru a afla anumite detalii.
Pretendenți: comandă, operator
4. Pentru a realiza comanda, clientul trebuie să completeze formularul electronic, în
care indică adresa sa și factura de plată. De asemenea, în acest formular, clientul
specifică detalii ce țin de metoda de plată (card bancar sau cash), mail etc.
Pretendenți: formular_comandă, factură, plată
5. Detaliile comenzii recepționate, inclusiv numărul comenzii vor fi expediate prin poștă
clientului, astfel încât, în timp ce vestimentul se confecționează, clientul să poată
verifica starea comenzii, utilizând codul comenzii.
 Pretendenți: aceeași – nu au apărut noi. Stare_comandă și cod_comandă – pot pretinde
la rol de atribute.
6. După recepționarea comenzii operatorul transmite detaliile referitoare la
configurația produsului în secția de cusut pentru a verifica disponibilitatea
produsului și materialelor.
Pretendenți: aceeași – nu au apărut noi.
7. Tehnicianului recepționează factura de la operator, verifică disponibilitatea
vestimentului și dacă sunt toate materialele necesare operatorul contacteaza clientul
pentru a stabili ziu in care poate sa vina in atelier pentru ca tehnicianul sa preea
masurile necesare.
Pretendenți: aceeași – nu au apărut noi (numai dacă se dorește păstrarea datelor
despre tehnician, responsabil de preșuarea masurilor de la clienti – se va menționa și
clasa conceptuală tehnician).
Astfel, am selectat următoarele clase conceptuale, specifice domeniului problemei
analizate: client, operator, vestiment (poate fi cu configurație-standard sau cu configurația
clientului), fereastră_configurare, element_configurare, comandă, fereastra_comandă,
factură, plată.
Prezentăm clasele conceptuale într-un model grafic, modelul domeniului, utilizând
sintaxa diagramei claselor din UML. Vom adăuga relațiile de asociere și unele atribute, ce pot
fi evidențiate din descrieri.
 Acest model reprezintă „scheletul” viitoarei diagrame a claselor, iar noțiunile din el
pot fi folosite la generarea de nume de clase în diagrama claselor, la etapa de proiectare.

Modelarea interacțiunii dintre obiectele domeniului. Evidențierea

responsabilităților obiectelor domeniului

Vom analiza în continuare scenariul de bază, reușit a cazului de utilizare ”Înregistrează

comanda”. În mod analogic se va proceda și pentru celelalte cazuri de utilizare.

Pot fi evidențiate următoarele acțiuni din partea actorului ”client”:

Acțiunile actorului Reacția sistemului

1. Deschide fereastra cu configurația
standard a calculatorului
3. Acceptă sau modifică configurația
calculatorului și poate cere detalii
referitoare la produs
5. Cere înregistrarea comenzii
2. Afișează configurația selectată
4. Afișează informații detaliate referitoare
la produsul comandat
6. Primește cererea de comandă și salvează
comanda
7. Expediază informații referitoare la
confirmarea comenzii recepționate

Se va construi diagrama de secvență, ce modelează schimbul de mesaje dintre client și sistem

(privit ca un tot întreg). Mesajele, inițiate de actor, care intră prin intermediul interfeței grafice
a sistemului, vor servi drept evenimente pentru sistem.
 Figura 6.1. Diagrama de secvență a evenimentelor sistemului

În continuare se va cerceta cum se modifică starea obiectelor, prezentate în modelul

domeniului, în cazul:

a) Creării de noi exemplare ale claselor;

b) Schimbării valorilor atributelor;
c) Crearea sau distrugerea relațiilor de asociere dintre obiecte.

Analizând diagrama de secvență ce prezintă evenimentele sistemului analizat, pot fi

evidențiate următoarele operații de sistem:

1) Deschide_Fereastră_Configurație()
2) Aprobă_Configurație() – și inițiere creare comandă
3) Înregistrează_Comanda()
Descrierea operațiilor de sistem

Operația Deschide_Fereastră_Configurație()
Trimiteri la cazul de Înregistrarea comenzii
utilizare
Precondiții - Nu sunt
Postcondiții - A fost creat exemplarul ”fereastrăConfigurație”
- Au fost inițializate variabilele exemplarului creat
- A fost creată relația cu exemplarul ”vestiment”

Operația Aprobă_Configurație()
Trimiteri la cazul de Înregistrarea comenzii
utilizare
Precondiții - Este deschisă fereastra de configurație
- Clientul acceptă detaliile configurației selectate
Postcondiții - Au fost fixate valorile pentru
”elementeleConfigurației”
- A fost creat exemplarul ”fereastrăComandă” și
”Comandă”

Operația Înregistrează_Comandă()
Trimiteri la cazul de Înregistrarea comenzii
utilizare
Precondiții - A fost creată ”comanda”
Postcondiții - Datele referitoare la comandă au fost salvate
- A fost creat exemplarul ”Client”
- Exemplarul ”comandă” a fost asociat cu exemplarul
”vestiment”
- Exemplarul ”comandă” a fost asociat cu exemplarul
”client”
- A fost creat exemplarul ”plată” și ”factura”
- A fost creată relația de asociere dintre ”comandă” și
”plată”
- A fost creată relația de asociere dintre ”plată” și
”factură”
Descrierea soluțiilor tehnice în baza operațiilor de sistem. Construirea
diagramei claselor de programare. Adăugarea atributelor și a metodelor
claselor
Diagramele de interacțiune descriu interacțiunile dintre obiectele domeniului, cu
scopul îndeplinirii cazului de utilizare.
Interacțiunea reprezintă o mulțime de mesaje pe care le schimbă obiectele între ele, în baza
relațiilor de asociere stabilite.

În cazul în care în modelul domeniului nu există relații de asociere între două clase
conceptuale, obiectele care sunt definite de ele nu vor putea interacționa.

Mesajul se adresează operației obiectului apelat. Denumirea mesajelor coincid cu

denumirile operațiilor obiectelor.
Construim diagrama claselor, clase care ulterior vor fi supuse programării.
Planificarea inițială a proiectului SI

Planificarea proiectului s-a realizat cu ajutorul aplicatiei MS Project. Fiind un sistem

flexibil și de înaltă performanță pentru gestionarea eficientă a proiectelor și a resurselor care
sprijină munca în echipă. Microsoft Project este plin de instrumente grafice bogate pentru a
simplifica planificarea proiectelor și a gestiona datele și termenele cheie. Microsoft Project
reunește comoditatea și simplitatea aplicațiilor precum Microsoft Excel, adăugând puterea
planificării proiectelor.
Obiectivul de bază al acestui proiect este: Dezvoltarea SI pentru evidența operative și
controlul fluxurilor financiare și a comenzilor ale atelierului “Natali Design”
Orice plan are o data de început și una de sfârșit de aceea în aplicație în primul rând s-
a ales data de început al proiectului, vezi figura 8.1.
 Figura 8.1. Data de început al proiectului
După cestabilim data de început deja se introduce lista de activtăți pentru realizarea SI , vezi
figura 2.

Figura 8.2. Planificarea dezvoltării SI “Natali Design”

 Resursele necesare pentru realizarea activităților sunt descries în tabelul Resource Sheet.
Resursele pot fi work, material, cost. Fiecare resursă poate avea propriul calendar, care specifică ce
zile și schimburi o resursă este disponibilă, vezi figura 8.3.

Figura 8.3. Resursele necesare pentru proiect

Repartizarea resurselor s-a efectuat în dependență de actitivitatea proiectului, rezultatul acestui
proce se vede în figura 8.4.

Figura 8.4. Alocarea resurselor

În această aplicație cheltuielile totale pentru proiect sunt facute automat, vezi figura 8.5.
Figura 8.5. Costul totalal proiectului

Figura 8.6. Diagrama Gantt

Figura 8.7. Diagrama de tip rețea(PIERT)