Sunteți pe pagina 1din 5

Lucrarea de laborator nr.

Tema: Argumentarea necesității modernizării sistemului informațional din organizație, prin


dezvolatrea sistemului informatic

Cerințe:

1. Motivarea necesităţii realizării şi implementării sistemului informatic.


2. Destinaţia sistemului informatic, descrisă conform următorului model (Tab. 1):
Tabelul 1. Structura recomandată pentru descrierea necesităţii SI

Denumirea sistemului informatic ...

Destinaţia (pentru ce este necesar) ...

Utilizatorii SI ...

Ce probleme vor fi soluţionate la implementarea ...


SI

Lucrarea de laborator nr.4

Tema: Evidențierea utilizatorilor SI și ale funcționalităților oferite acestora

Cerințe lucrare de laborator:

1. Enumerarea actorilor și a funcționalităților accesibile lor.


2. Construirea diagramei de context și a diagramei cazurilor de utilizare.
3. Formularea cerințelor funcționale.
4. Formularea cerințelor nefuncționale: față de securitatea, fiabilitatea, utilizabilitatea și interfața
grafică a sistemului, cerințe față de portabilitatea sistemului, documentație etc.

Informații utile:

Cerinţele înaintate unui SI pot fi clasificate în cerinţe funcţionale şi nefuncţionale [6]:

 Cerinţele funcţionale reprezintă enumerarea serviciilor pe care ar trebui să le ofere SI diferitelor


tipuri de utilizatori. Altfel spus, aceste cerinţe descriu comportamentul SI şi operaţiile/funcţiile
îndeplinite de acesta. De asemenea, ar trebui să se specifice cum sistemul va reacţiona la
introducerea anumitor tipuri de date sau cum se va comporta (va răspunde) în diferite situaţii,
extreme de exploatare. În unele cazuri, se poate specifica ce nu ar trebui să facă sistemul.
 Cerinţele nefuncţionale descriu caracteristicile SI şi ale mediului acestuia, dar în nici un caz
comportamentul acestuia. Pot fi menţionate restricţii referitoare la activitatea SI şi la funcţiile
îndeplinite de acesta. Acest tip de cerinţe cuprinde restricţii asupra duratelor, restricţii referitoare la
procesul dezvoltării SI, standarde etc. De asemenea, aici mai pot fi adăugate cerinţe referitoare la
domeniul studiat şi unde va fi implementat SI. În lista cerinţelor nefuncţionale pot fi incluse cerinţe
faţă de securitate, componentele hard, etapa de implementare, păstrarea datelor, viteza de acces la
date, fiabilitatea SI, documentaţia SI etc. (vezi: Structura sarcinii tehnice,
http://lex.justice.md/viewdoc.php?action=view&view=doc&id=316454&lang=1).
OBS: Conform „The guide to the Business Analysis Body of Knowledge”, elaborat de International
Institute of Business Analysis, cerinţele pot fi divizate în: cerinţe funcţionale, nefuncţionale şi cerinţe faţă
de implementare.

În unele cazuri, este dificilă delimitarea celor două tipuri de cerinţe (de exemplu clientul cere ca
sistemul să fie sigur şi atunci aceste cerinţe pot fi incluse în lista cerinţelor de siguranţă – cerinţe
nefuncţionale –, sau dacă acestea se specifică mai detaliat – la cerinţe funcţionale – deoarece ele vor
conduce la implementarea în SI a funcţiilor responsabile de autentificare şi autorizare a acţiunilor
utilizatorului). În aceste cazuri, se recomandă utilizarea standardelor şi reglementărilor tehnice specifice
domeniului.

Cerinţele se formulează cât mai clar posibil, deoarece de cele mai multe ori stau la baza organizării
unei licitaţii sau a unui tender (adică trebuie să fie uşor de înţeles şi interpretat), sau pot sta la baza
încheierii unui contract de dezvoltare a unui SI (în acest caz, ele trebuie definite cât mai detaliat). De
asemenea, cerinţele sunt necesare pentru a verifica după etapa de elaborare (testare) dacă sunt sau nu
îndeplinite.

Exemple de artefacte specifice lucrării de laborator nr.4:

1) Exemplu de cerinţe funcţionale:

a. Casierul trebuie să poată căuta în BD a SI detalii referitoare la un anumit produs;


b. SI trebuie să ofere posibilitatea casierului de a vizualiza comod detaliile produselor;
c. SI trebuie să-i permită operatorului de la depozit înregistrarea intrărilor tuturor vaccinurilor;
d. SI trebuie să-i permită operatorului depozitului înregistrarea vaccinurilor deteriorate (sau
înregistrarea vaccinurilor care vor fi transmise pentru distrugere).
2) Exemplu de cerinţe nefuncţionale:

a. Cerinţe faţă de confidenţialitate (securitate): Sistemul nu trebuie să ofere/afişeze alte date,


referitoare la client, decât numele şi prenumele acestuia;
b. Cerinţă faţă de documentaţia utilizată: Procesul de dezvoltare şi setul de documente vor fi
realizate în baza RT 38370656-002:2006;
c. Cerinţe faţă de interfaţa-utilizator:
i. Etichetele prezente în formularele aplicaţiei trebuie să fie aliniate pe stânga, pentru o uşoară
citire a datelor prezentate.
ii. Sistemul trebuie să ofere consistenţă pentru toate ecranele şi caracteristici comune specifice
tuturor componentelor SI.
iii. Design-ul aplicaţiei trebuie să includă link-uri „înainte” şi „înapoi” între pagini/formulare. Trebuie
să existe o pagină/un formular iniţial, care ar realiza legătura dintre toate celelalte
pagini/formulare.
d. Cerinţă faţă de utilizabilitate:
i. Textul din formularul utilizat pentru înregistrarea vânzărilor trebuie să se citească de la distanţa
de 1m.
ii. În meniul principal al aplicaţiei destinate „managerului de depozit”, trebuie să fie opţiunea
„Raport”, în care să fie accesibile opţiunile „Vizualizare” şi „Tipar”.
e. Cerinţă faţă de operabilitate: 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), aceasta se va face
la părăsirea ecranului sau formularului.
f. Cerinţă faţă de fiabilitate: Pe durata exploatării SI trebuie să cedeze în medie de 7 ori anual.
g. Cerinţă faţă de performanţă: 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.

Lucrarea de laborator nr. 5

Tema: Modelarea cazurilor de utilizare folosind diagramele activităților și modelarea unor interfețe
grafice, specifice cazului de utilizare

Cerințe:

1. Pentru fiecare caz de utilizare evidențiat în lucrarea de laborator anterioară, descrieți-l detaliat,
respectând următoarea structură: denumirea cazului de utilizare, actori implicați, descriere
succintă, precondiții, postcondiții, scenariul de bază reușit, scenariile alternative pentru cazul de
utilizare.
2. Proiectarea interfețelor grafice specifice fiecărui caz de utilizare.
3. Modelarea scenariilor grafic, utilizând sintaxa diagramelor activităților din UML.

Lucrarea de laborator nr. 6

Tema: Elaborarea modelului domeniului și evidențierea claselor conceptuale

Cerințe:

1. Evidențierea noțiunilor domeniului și găsirea claselor conceptuale.


2. Evidențierea relațiilor de asociere dintre clasele conceptuale.
3. Evidențierea atributelor claselor conceptuale.
4. Construirea modelului domeniului.

Lucrarea de laborator nr. 7

Tema: Modelarea interacțiunii dintre obiectele domeniului. Evidențierea responsabilităților obiectelor


domeniului.

Cerințe:

1. Analiza descrierilor cazurilor de utilizare și construirea diagramelor de secvență pentru fiecare


din ele.
2. Evidențierea responsabilităților obiectelor și descrierea operațiilor de sistem, conform
modelului:

Operația Denumirea operației și parametrii acesteia


Trimiteri la cazul de utilizare Nu sunt obligatorii. Sunt menționate cazurile de utilizare în care se
poate îndeplini operația
Precondiții Presupuneri despre starea sistemului sau a obiectelor modelului
domeniului până la îndeplinirea operației. Aceste condiții sunt
netriviale și merită să li se acorde atenție. Logica lor nu se verifica,
dar se presupune că ele sunt adevărate.
Postcondiții Starea obiectelor din cadrul modelului domeniului după
îndeplinirea operației.

3. Interpretarea corectă a modelului dinamic a sistemului.


Lucrarea de laborator nr. 8

Tema: Descrierea soluțiilor tehnice în baza operațiilor de sistem. Construirea diagramei claselor de
programare. Adăugarea atributelor și a metodelor claselor

Cerințe:

1. Pentru fiecare operație de sistem să se construiască diagrama de interacțiune, care prezintă


”modelarea dialogului dintre obiectele domeniului”.
2. Elaborarea soluțiilor de proiectare pentru fiecare operație de sistem.
3. Construirea diagramei claselor.

S-ar putea să vă placă și