Elaborarea Specificatiilor de Proiectare ale Unui Sistem Informatic
Capitolul 1. INTRODUCERE
Activitatea economică reprezintă un domeniu fundamental pentru existența societății omenești, pentru ameliorarea continuă a condiției umane. Omul nu poate exista fără să producă, așa cum, la rândul ei, producția nu are rațiune fără consum. De problemele economice sunt legate constant cele mai importante aspirații ale societății și individului.
Procesele economice de producție, repartiție, schimb și consum se concretizează prin operațiuni de mișcare și transformarea bunurilor. Consumul de resurse umane, materiale, financiare și informaționale este prezentat în toate etapele reproducției sociale.
Construcțiile monumentale ale civilizației sumeriene, administrarea imenselor bogății acumulate și (socoteala) pe care clerul trebuia să o dea divinității, au impus, în prima etapă, apariția unor însemnări cu certă semnificație contabilă. Ulterior, inventarierea averilor, cedarea temporară a unui bun, apariția monedei și a schimbului de monedă, acordarea unui credit, restituirea bunului sau a sumei împrumutate, operațiuni de vânzare și cumpărare a elementelor de avere, s-au diversificat sub influența dezvoltării continue a forțelor de producție. Derularea în timp a acestor acte economice singulare a făcut necesară consemnarea bunului sau a sumei împrumutate, a scadenței convenite, înregistrarea valorilor consumate într-un efort economic, cât și a veniturilor obținute. Activitatea economică s-a amplificat și, o data cu eadimensiunea valorilor aflate în mișcare. Termenul de valoare capătă în plan economic sensul de bun, avere, bogăție, bani, creanțe (drepturi) sau datorii.
Omul a fost obligat să inventeze în aceste condiții primul model economic, respectiv CONTUL. În el a consemnat nu numai latura concretă, materială a bunurilor, a averii ci și aspectul abstract al relațiilor de proprietate, sub forma drepturilor și obligațiilor care corespund unui patrimoniu determinat. O primă definire a obiectului contabilității este realizată de LUCA PACIOLO în celebra operă de pionerat "Summa di Arithmetica, Geometria, Proportioni et Proportionalita", respectiv în "Tractatus de Comptius et Scriptus". Contabilitatea studiaza "tot ceea ce după părerea negustorului îi aparține pe lume, ca avere mobilă și imobilă, precum și afacerile mari și mărunte, în ordinea în care acestea au avut loc". Dezvoltarea societății capitaliste a sporit interesul subiectului economic pentru obținerea profitului. În egală măsură au crescut șansele de afirmare ale contabilității.
Trăim într-o lume cu resurse limitate. Suntem obligați să cultivăm realmente un comportament rațional în activitatea economică, fundamentat pe ordine și prevedere.
Putem vorbi în aceste condiții și despre o altă dimensiune omniprezentă a contabilității, cea pe care la nivel individual, al persoanei, o apelăm constant.
În viața cotidiană socotim mereu. Ne calculăm vîrsta, ne măsuram greutatea și înălțimea. Într-un anumit gen de memorie consemnăm veniturile realizate, determinăm cheltuielile necesare pentru desfășurarea oricărei acțiuni mai importante. Plecarea într-un concediu, achiziția sau construcția unei locuințe, cumpărarea unui autoturism etc. solicită deopotrivă dimensionarea corectă a costului estimat, în corelație directă cu resursele financiare acoperitoare. Dincolo de aceste observații, un fapt se impune a fi menționat. O anumită valență a contabilității a pătruns discret și ireversibil în viața noastră. Într-un anumit sens, devenim contabili chiar dacă explicit nu o recunoaștem.
Este adevarat că nu întotdeauna "ținem conturile", nu determinăm indici sau indicatori economici. În schimb, deliberat sau fără să ne dăm seama, realizăm o permanentă apelare a "științei conturilor". Termenul francez "compter " (a socoti) are originea în latinescul "computare" (a calcula). La rândul ei expresia calcul derivă din latinescul "calculus'" (pietricică). Asocierea are la bază faptul că acest banal obiect a constituit unul din procedeele rudimentare de realizare a evidenței. Contabilitatea nu se reduce numai la un calcul propriu-zis, și cu atât mai puțin la o numărare sau socotire. Le presupune însă pe amândouă. Numârarea este o simplă operațiune care constă în enunțarea unui șir de numere. Socotitul constituie o acțiune ceva mai complexă, care privește evaluarea unei cantități sau mărimi, apelând sau nu la numere. Contabilitatea este calitativ superioară socotitului, deoarece printe altele, corelează un ansamblu de calcule coerente, desfășurat după anumite reguli. Altfel spus, contabilitatea reprezintă un sistem logic și rațional de informare specializată, supus unor covenții și norme definite social.
Doctrinele contabilității conțin numeroase puncte de vedere privind obiectul acestei știinte. Dincolo de aceste nuanțări diferite, în concepția noastră și a școlii care ne-a format, considerăm că:
Obiectul contabilității reprezintă ansamblul mișcărilor de valori dintr-o anumită entitate economico-socială, exprimate în etalon bănesc, inclusiv raporturile economico-juridice care afectează patrimoniul acesteia. Calculele contabilității consemnează într-un echilibru valoric permanent mișcarea și transformarea mijloacelor, precum și resursele în ordinea constituirii și a destinației atribuite îin procesul de producție.
Din definiția menționată deducem următoarele aspecte esențiale:
contabilitatea studiază mișcările de valori referitoare la un patrimoniu dat;
ea reprezintă o formă de cunoaștere sistematică și specializată a patrimoniului, inclusiv a operațiilor care modifică mărimea și structura acestuia;
contabilitatea cercetează patrimonial într-o dublă reprezentare, ca realitate economică (patrimoniu economic), respective MIJLOACE, cât și ca mod de dobândire sau proveniență (patrimoniu juridic), respectiv RESURSE ;
dubla reprezentare asigură menținerea unor echilibre valorice permanente atât prin relația cauzală A=P (Activ = Pasiv ) cât și prin relația formală D=C (Debit=Credit);
legitimitatea adevărului contabil se fundamentează pe două serii de calcule sincronice și paralele, sistematice și cronologice, întreprinse asupra Activului si Pasivului, respectiv asupra Mijloacelor și Resurselor, conținute în patrimoniul unei firme;
abordarea contabilă privește exclusiv substante patrimoniale exprimabile în bani.
Precizarea anterioară este absolut necesară, deoarece patrimoniul reprezintă în ultimă instanță un ansamblu de drepturi și obligații aferente unei persoane fizice sau juridice. În viața cotidiană există drepturi și obligații care nu se includ în sfera patrimoniului, tocmai pentru faptul că nu sunt susceptibile la o exprimare monetară. Bunăoară:
drepturile și obligațiile publice sau politice, care constau în participarea la puterea publică;
obligațiile naturale cu care indivizii se nasc, trăiesc și mor, subsumate în conceptul de contract social, descris de marele filozof francez J.J.Rousseau, în celebra operă cu același nume.
drepturile de familie, exprimate în exercitarea atributelor părinților asupra copiilor, drepturile și obligațiile reciproce ale soților etc.
A percepe corect dimensiunea obiectului contabilității și omniprezența acestuia, presupune să privim pretutindeni în jurul nostru. Putem "inventaria" cu această ocazie o infinitate de substanțe cu valoare economică, exprimabile în etalon monetar. În spațiul academic menționăm doar câteva dintre ele: clădirea în care ne aflăm, amfiteatrul universitar, terenul pe care acesta există, catedra sau banca, computerele din laboratoare, bunurile pe care le deținem, casa în care locuim, tramvaiul sau autoturismul cu care astăzi am venit la școala etc. Toate constituie un patrimoniu economic, public sau privat, asupra căruia grevează în mod obligatoriu un ansamblu de drepturi și obligații cu valoare economică, respectiv patrimoniu juridic. În ultimă instanță, toate bunurile menționate constituie obiectul contabilității la nivel micro (unitate patrimonială) sau la nivel macro economic (contabilitate națională). Fapte economice, tranzacții și evenimente diverse, modifică în permanență mărimea și structura acestui patrimoniu. De aici și omniprezența contabilității, ca știință a existenței și mișcării valorilor economice separate patrimonial. Evident latura cauzală, cea care explică proveniența sau modul de dobândire a unui patrimoniu este de natură juridică.
Ea se centrează esențial pe relația de proprietate, pe raportul existent între bunul aflat la dispoziția unei persoane, ca obiect al patrimoniului și subiectul de patrimoniu, persoana care deține sub un anumit titlu, bunul respectiv. Un drept de proprietate integrală asupra unui bun, compus din cele trei aspecte (folosință, execuție și dispoziție) va permite subiectului de patrimoniu (persoana fizică sau juridică) să dispună liber și nelimitat de soarta acelui element de avere: să-1 vândă, închirieze, doneze, distrugă etc.
Dacă bunul a fost achiziționat pe credit, nefiind încă integral achitat, sau dacă el constituie obiect al unei garanții materiale pentru un credit bancar, (gaj sau ipotecă), drepturile subiectului de patrimoniu (cumpărătorul bunului, respectiv beneficiarul creditului) asupra bunului sunt restrânse. Autoturismul sau apartamentul achiziționat pe credit nu vor putea fi înstrăinate (vandute sau donate) decât în condiții speciale și cu acordul creditorului (persoana care a vândut bunul).
Capitolul 2. PREZENTAREA SOCIETĂȚII
2.1. Scurt istoric al S.C. RAZMISI S.R.L.
1. Denumirea agentului economic : S.C. RAZMISI
2. Forma juridică S.R.L.
3. Adresa: Măgurele, Șoseaua Ploiești-Văleni nr. 583
4. Înmatriculată la Registrul Comerțului cu: Nr. J29/1371991 cod fiscal 1619311165
5. Proprietar: TANASE MIOARA
6. Valoarea capitalului social subscris 450 000 000 lei
din care varsat 450 000 000 lei
Societatea comercială poartă denumirea de "S.C. RAZMISI S.R.L" , s-a înființat în anul 1995 și este organizată sub forma de societate comercială cu răspunedere limitată, cu asociat unic.
Capitalul social este divizat în 4500 părți sociale egale a câte 100.000 lei și este deținut în totalitate de unicul societar. Hotărârea de mărire a capitalului social se va publica în Monitorul Oficial prin grija administratorului societății.
Valoarea cu care se mărește capitalul social va fi împărțită în părți egale a câte 100.000 lei fiecare.
Reducerea capitalului social se va putea face în condițiile și limitele prevazute de lege și va trebui să se arate motivele pentru care se va face reducerea și procedeul ce va fi utilizat pentru efectuarea acesteia.
Societatea va fi condusă și reprezentată de unicul societar care va avea drepturile și obligațiile ce revin, potrivit Legii nr.31/1990, republicată, adunării generale și administratorului.
Asociatul va putea fi reprezentat și de un împuternicit căruia îi vor fi stabilite expres limitele mandatului acordat pentru angajarea societății în relațiile cu terții.
Pe măsura dezvoltării societății aceasta va putea numi și cenzori.
Bilanțul societății este întocmit de administrarorul acestuia.
Din profitul societății se vor prelua în fiecare an cel puțin 5% pentru formarea fondului de rezervă până ce acesta va atinge cel puțin a cincea parte din capitalul social.
Profitul integral al societății va fi menționat în bilanțul contabil anual.
Plata cotelor din profit se va face numai după aprobarea bilanțului și verificarea acestuia de către organele fiscale.
În caz de pierderi, asociatul are obligația de a analiza cauzele și a stabili măsurile corespunzătoare pentru redresarea situației.
2.2. Obiectul de activitate
Societatea comercială " RAZMISI S.R.L" are ca obiect de activitate:
5010 – comerț cu autovehicule;
5030 – comerț cu piese și accesorii pentru autovehicule;
5041 – vânzarea motocicletelor, pieselor și accesoriilor aferente ;
5111 – comerț intermediar cu materii prime agricole, animale vii, materii
prime textile și cu semiproduse;
5113 – comerț intermediar cu material lemnos și de construcții;
5115 – comerț intermediar cu mobilă, articole de meerț intermediar cu mobilă, articole de menaj și de fierarie;
5116 – comerț intermediar cu textile, confecții, încălțăminte, articole din piele;
5117 – comerț intermediar cu produse alimentare, băuturi tutun;
5119 – comerț intermediar cu produse diverse ;
5121 – comerț cu ridicata cu cereale, semințe și furaje;
5122 – comerț cu ridicata cu flori și plante;
5123 – comerț cu ridicata cu animale vii;
5124 – comerț cu ridicata cu piei brute și piei prelucrate;
5125 – comerț cu ridicata cu tutun neprelucrat;
5131 – comerț cu ridicata cu fructe și legume;
5132 – comerț cu ridicata cu carne și mezeluri;
5133 – comerț cu ridicata cu produse lactate, ouă, uleiuri și grasimi alimentare;
5134 – comerț cu ridicata al produselor din pește, crustacee și moluște;
5135 – comerț cu ridicata cu băuturi;
513 6 – comerț cu ridicata cu tutun;
5137 – comerțcu ridicata cu zahar, ciocolata și produse zaharoase;
5138 – comerț cu ridicata cu cafea ceai, cacao și condimente;
5141 – comerț cu ridicata cu produse textile;
5226 – comerț cu amănuntul cu băuturi;
5227 – comerț cu amănuntul cu tutun;
5228 – comerț cu amănuntul cu produse alimentare, băuturi și tutun în magazine nespecializate.
2.3. Analiza relațiilor economice cu partenerii
S.C. RAZMISI S.R.L. Magurele, prin varietatea obiectului de activitate și mărimea cifrei de afaceri are relații economice cu mulți parteneri de afaceri (clienți și furnizori). Aceste relații economice au fost determinate de o serie de criterii specifice economiei de piață, cum sunt:
– oferta;
– prețurile practicate;
– distanțe ;
– concurența.
Din analiza relațiilor cu furnizorii de mărfuri, materii prime, materiale, piese de schimb etc. rezultă că societatea are o serie de furnizori tradiționali dar și ocazionali, așa cum rezultă din situația prezentată mai jos.
1. S.C. ROMCIF S.A. FIENI
2. S.C. OYL COMPANY S.A. SLOBOZIA
3. S.C. LOTUS SERV S.R.L BARCANESTI
4. S.C. PRESCOM S.A. BRASOV
5. S.C. PETRONIK S.R.L PLOIESTI
6. S.C. TRANS GHEORGHE CALARASI
7. S.C. RAY IMPEX BUCURESTI
8. S.C. KAPRONIBLEJOI
9. S.C. SIDERPET S.A. BUCURESTI
10. S.C. ANA MARIA POP PLOIESTI
Datorită specificului activității, societatea nu are clienți tradiționali. Cei mai importanți clienți sunt:
S.C. DEMETER S.R.L. PLOIESTI
S.C. SELEN SERV MIZIL
S.C. METCHIM S.A. PLOIESTI
S.C. LIMAR IMPEX BLEJOI
S.C. TOP GLASS BLEJOI
S.C. ROBERT TRANS BUZAU
S.C. STEJARU STOICA PLOIESTI
S.C. TEROTEHNIC PLOIESTI
S.C. DRASTHY S.R.L. BOLDESTI
S.C. MONTAJ CARPAȚI PUCHENI
Relațiile societății cu partenerii se derulează în baza unor contracte ferme încheiate între părți în urma cărora se emit comenzi pentru aprovizionări sau execuții de lucrari sau servicii, prețurile și tarifele fiind stabilite prin negociere directă ori de câte ori este nevoie.
Societatea are 3 puncte de lucru: Măgurele, Boldești și Vălenii de Munte, și un număr de 14 salariați.
Capitolul 3. ANALIZA SISTEMULUI INFORMAȚIONAL
3.1. Activitatea de determinare a cerințelor sistemului
Rezultatele activității de determinare a cerințelor sistemului informațional se concretizează în diferite forme ale informațiilor colectate, cum sunt copii ale interviurilor, însemnări efectuate în timpul observării și analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru ș.a., precum și rezultate ale prelucrărilor efectuate de calculator, cum ar fi prototipurile.
Sintetic, rezultatele obținute după această activitate pot fi prezentate astfel:
Informații obținute în urma conversațiilor cu utilizatorii sau prin observarea activităților prestate de aceștia: copii sau sinteze ale interviurilor, răspunsuri la chestionare sau interpretări ale acestora, însemnări și rezultate din observarea activităților, procese verbale ale ședințelor ce au avut loc în acest scop.
Informații scrise care există în unitate: misiunea și strategia afacerii, exemplare ale formularelor, rapoartelor și machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sistem și documentația sistemului existent, rapoartele consultanților, etc.
Informații obținute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fișierelor sesiunilor grupului de sprijinire a sistemului, conținutul depozitelor și rapoartelor existente în CASE, ecrane și rapoarte rezultate din prototipurile sistemului, etc.
Odată cu procesul de culegere a informațiilor prezentate, analistul trebuie să afle și alte aspecte despre organizație, cum ar fi:
obiectivele firmei, pentru a se vedea modul în care sunt derulate activitățile ei;
informațiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le revin;
datele (descrierea lor, volumul, mărimea, periodicitatea ș.a.) vehiculate în unitate pentru fiecare loc de muncă;
când, cum, de către cine și ce date circulă, se transformă sau se înregistrează;
ordinea de prelucrare și dependența dintre datele trecute prin diverse activități desfășurate;
regulile prin care se specifică modul în care sunt transmise și prelucrate datele;
evenimentele marcante și momentele declanșării lor, prin care se schimbă valoarea datelor.
Timpul necesar culegerii informațiilor este imens, iar cheltuielile sunt pe măsură.
Ca efect al tendințelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani s-a efectuat trecerea spre analiza mai puțin pronunțată a sistemelor ce urmează a se realiza. Tehnicile moderne, JAD și prototipizarea, preiau tot mai puține elemente din sistemele existente, ca urmare a analizelor efectuate. Altele, mai radicale, renunță aproape total la analiza sistemului existent. Este cazul proceselor controlate prin RAD (Rapid Application Development), care apelează la JAD, prototipizare și alte instrumente integrate de tip CASE.
Datorită interesului tot mai crescut pentru aceste tehnici moderne de analiză, dintre metodele de determinare a cerințelor sistemului, vor fi prezentate în continuare doar metodele JAD (Joint Application Design) și prototipizarea.
3.1.1. Joint Application Design
Spre sfârșitul anilor 1970, specialiștii în realizarea de sisteme IBM au elaborat un nou proces de culegere a cerințelor informaționale ale sistemelor și de revizuire a proiectelor sistemelor. El se numește Joint Application Design (JAD). Ceva mai târziu, în Europa de Nord, apare o replică a JAD, numită Participatory Design (PD). Elementul de noutate al PD față de JAD îl constituie accentuarea mult mai puternică a rolului jucat de utilizatori. Fiecare dintre ei are drepturi egale în stabilirea cerințelor sistemului, precum și în acceptarea lui. În alte cazuri, se delegă un grup de utilizatori care să aibă aceste atribuții. Sub auspiciile PD, analiștii sunt la dispoziția utilizatorilor, iar managerii și consultanții nu au rol de control, ci de avizare. Se afirmă că toate acestea sunt posibile în Europa de Nord deoarece aici forța de muncă este mult mai bine organizată și angajații sunt mult mai receptivi la mutațiile tehnologice.
Ideea pricipală JAD o constituie punerea laolaltă a tuturor forțelor interesate în dezvoltarea sistemelor: utilizatorii-cheie, managerii și analiștii de sistem implicați în analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totuși, în sesiunile JAD se urmează o anumită secvență de derulare a activităților, pe baza unor roluri bine definite.
Sesiunile JAD se desfășoară în locuri diferite de cele unde lucrează personalul antrenat în ele. Scopul este de a-i ține departe de grijile locului de muncă și de a-i folosi intens în ședințele de lucru.
Participanții la sesiunile JAD:
Conducătorul sesiunii JAD (leader) are rolul de organizare și desfășurare a sesiunilor JAD. El trebuie să fie bun specialist în managementul grupurilor și în analiza de sisteme. El stabilește și urmărește respectarea agendei de lucru, trebuind să-și mențină neutralitatea pe durata derulării sesiunii. De asemenea, va rezolva eventualele conflicte și dezacorduri și va solicita emiterea tuturor ideilor posibile.
Utilizatorii. Principalii utilizatori ai sistemului vor juca un rol determinant în sesiunile JAD, întrucât ei știu cel mai bine ce înseamnă folosirea zilnică a sistemului.
Managerii. De regulă, sunt managerii grupurilor de lucru ce folosesc sistemul. Ei cunosc direcțiile de dezvoltare, elementele de motivare și sunt implicați direct în determinarea cerințelor sistemului prin sesiunile JAD.
Susținătorul (sponsorul). Datorită cheltuielilor mari implicate de sesiunile JAD, ele trebuie să aibă susținerea unei persoane cu o poziție înaltă în firmă. Susținătorul nu participă la toate sesiunile, ci doar la cele de început și sfârșit.
Analistul de sistem. Membrii echipei de analiză participă la sesiunile JAD, deși implicarea lor este destul de limitată. Ei trebuie să afle cât mai multe lucruri de la utilizatori și manageri și nu trebuie să-și exprime punctul de vedere.
Scribul. Scribul va nota totul în timpul sesiunilor JAD, prin intermediul unui calculator sau laptop. Se pot folosi procesoarele de text sau o serie de instrumente CASE speciale.
Informaticienii. Alături de analiștii de sistem, participă și alte categorii de personal din domeniul sistemelor informaționale, cum sunt programatorii, analiștii bazelor de date, planificatorii de sisteme informaționale, precum și personalul antrenat în alte operațiuni de prelucrare a datelor. Ei vin să afle părerile utilizatorilor și managerilor și, dacă este cazul, să ajute la definitivarea studiului de fezabilitate tehnică.
Când sesiunea JAD este încheiată, rezultatul final înseamnă un set de documente referitoare la activitățile din sistemul curent care au legătură cu studiul noului sistem. Analiștii vor obține o nouă imagine asupra a ceea ce se intenționează a se realiza și ceea ce există în unitate.
3.1.2. Sistemele de sprijinire a grupurilor
Sesiunile JAD nu beneficiază prea mult de ajutorul calculatorului, în pofida recomandărilor unora de a se folosi cât mai multe instrumente CASE.
Unul dintre dezavantajele sesiunilor JAD îl constituie numărul mare de participanți și, de aici, diversitatea părerilor afișate într-un timp limitat. Timpul alocat unei persoane pentru a lua cuvântul se reduce la câteva minute. Dar, și în acest caz, unii vor încerca să domine grupul, alții nu vor spune nimic sau se vor teme să spună totul, fie din cauza șefilor, fie pentru a nu fi criticați.
Soluția este oferită de sistemele de sprijinire a grupurilor care vor rezolva problemele întâlnirilor în grup.
Pentru a-i acorda oricărui membru al grupului șansa de a-și exprima părerea, aceștia vor introduce în calculator tot ceea ce cred despre problema discutată, fără a mai fi nevoiți să o expună verbal.
Se cunosc și alte modalități de folosire a sistemelor de sprijinire a grupurilor pentru determinarea cerințelor sistemului. Acestea se referă la posibilitatea achiziției de cunoștințe de la grupuri de experți, și nu de la unul singur, cum se procedează de obicei. Rezultatele au fost excelente. Pe o astfel de cale se poate realiza orice prototip mult mai performant.
3.1.3. Prototipizarea și determinarea cerințelor sistemelor
Prototipizarea este un proces iterativ prin care analiștii și utilizatorii pun în discuție o versiune rudimentară a unui sistem informațional, care va fi într-o continuă schimbare, în funcție de reacția utilizatorilor. Prototipizarea conduce la renunțarea la ciclul de viață al dezvoltării sistemelor sau la creșterea rolului său.
Pentru culegerea informațiilor despre cerințele utilizatorilor încă se apelează la interviuri, dar, prin prototipizare, operațiunea va fi mai simplă și va solicita un timp mai scurt. Prototipul este văzut și testat de utilizator, având posibilitatea să precizeze ce ar mai dori, dar să și genereze această formă nouă, în mod natural, cu ajutorul specialiștilor care fac testarea prototipului.
Prototipizarea este facilitată de câteva limbaje sau produse program din generația a patra, inclusiv instrumente CASE.
Prototipizarea este foarte utilă în determinarea cerințelor sistemului atunci când:
cerințele utilizatorilor nu sunt prea clar formulate sau bine înțelese, ceea ce se întâmplă cu noile sisteme sau cu cele de sprijinire a procesului decizional;
unul sau mai mulți utilizatori sau susținători sunt implicați în sistem;
în trecut s-au înregistrat dificultăți în comunicarea dintre utilizatori și analiști și se încearcă formulatea cât mai corectă a cerințelor sistemului;
anumite mijloace de lucru (formulare și rapoarte predefinite), precum și datele de test existente sunt elemente care contribuie la construirea mai rapidă a sistemului.
Totuși, prototipizarea generează și deficiențe, cum ar fi:
tendința de evitare a unui cadru formal de elaborare a documentației privind cerințele sistemului, ceea ce va îngreuna mai târziu orice control;
fiind conceput în colaborare cu un grup nesemnificativ de utilizatori, va fi probabil respind de viitorii utilizatori;
fiind conceput izolat, este puțin probabil ca el să fie ușor de integrat în sistemul existent;
nerespectându-se etapele ciclului de viață al dezvoltării sistemelor pot fi omise aspecte esențiale, cum ar fi securitatea, controlul datelor introduse și standardizarea la nivel de sistem.
Pașii prototipizării și elementele caracteristice ale acestora sunt prezentați, într-o formă descriptivă, în continuare:
Avantajele și dezavantajele prototipizării
Dintre avantajele prototipizării menționăm:
o mai bună definire a cerințelor utilizatorilor;
o implicare mai puternică a utilizatorilor și, ca atare, creșterea satisfacției lor;
creșterea vitezei de realizare a sistemelor;
un număr redus de erori;
flexibilitate mai mare la potențialele schimbări;
costuri mai mici de realizare a sistemului (aproximativ 10%+20% din costurile sistemelor tradiționale).
Ca dezavantaje ale prototipizării se pot menționa:
o creștere semnificativă a timpului dedicat de utilizatori pentru realizarea noului sistem;
o folosire mai puțin eficientă a resurselor sistemului;
realizarea unor sisteme incomplete;
sisteme testate și documente în forme nesatisfăcătoare;
reacții comportamentale negative;
un sistem aflat în continuă construcție.
Avându-se în vedere avantajele și dezavantajele prototipizării, se recomandă o analiză lucidă a oportunității prototipizării, recomandându-se ca firească folosirea sa în următoarele condiții:
utilizatorii nu știu prea bine ceea ce vor sau cerințele lor sunt într-o continuă schimbare;
cerințele sistemului sunt greu de definit;
nu sunt cunoscute intrările și ieșirile sistemului;
activitățile de executat sunt semistructurate sau nestructurate;
proiectanții nu sunt siguri de tehnologiile ce vor fi folosite;
sistemul de realizat este necesar într-o perioadă foarte scurtă de timp și constituie o cerință majoră pentru unitate;
riscul oferirii unui sistem inadecvat este foarte mare;
reacțiile utilizatorilor față de noul sistem contribuie esențial la realizarea lui;
cerința de testare a mai multor strategii de proiectare;
sistemul va avea o utilizare temporară.
Dintre sistemele ce se pretează prototipizării, relevante sunt sistemele de sprijinire a procesului decizional, sistemele informaționale pentru top-manageri, sistemele expert și schemele de reconstituire a informațiilor. Prototipizarea nu este recomandată în cazul sistemelor mari sau al celor complexe, cu o arie mare de întindere la nivelul organizației. De asemenea, nu este indicată pentru aplicațiile contabile din domeniile standard, cum sunt: creanțe, plăți sau gestiune stocuri.
În cele mai multe cazuri, prototipizarea servește ciclului de viață al dezvoltării sistemelor și nu contribuie la renunțarea la o astfel de metodologie. Așadar, ea nu va conduce la înlocuirea în totalitate a metodologiilor și instrumentelor tradiționale de realizare a sistemelor.
3.1.4. Rapid Application Development
RAD este o metodologie de realizare a sistemelor informaționale care promite sisteme mai bune, mai ieftine și realizate mai rapid. O primă explicație constă în selectarea celor mai buni proiectanți de sisteme și a celor mai reprezentativi utilizatori care, împreună, în timp real, lucrează la realizarea sistemului.
Se consideră, de asemenea, că alți doi factori au contribuit substanțial la creșterea RAD:
sporirea vitezei de derulare a operațiunilor economice și, odată cu acestea, diminuarea posibilităților de control asupra lor;
apariția multor instrumente puternice bazate pe folosirea calculatoarelor în domeniul realizării sistemelor (CASE și prototipizarea, îndeosebi).
De fapt, RAD a exploatat o serie de elemente favorabile care și-au făcut apariția în același timp: investirea utilizatorilor cu o mai mare implicare în realizarea sistemelor, îndeosebi în procesul de prototipizare, care la rândul lui, se bazează tot mai mult pe tehnica JAD.
Diferența majoră a RAD față de JAD constă în faptul că prototipul devine elementul fundamental al noului sistem – ecranele afișate în timpul prototipizării devin ecrane ale sistemului, și nu modele ale unui posibil sistem. Suportul central este oferit de instrumente integrate CASE, în care se includ și generatoarele de coduri ale programele. Reutilizarea unor componente este, de asemenea, încurajată în RAD.
Nu trebuie să se înțeleagă faptul că doar dispunând de instrumente CASE se garantează și realizarea de sisteme în varianta RAD. Reușita depinde și de alte elemente, cum ar fi:
instrumentele folosite
personalul
managementul
metodologia
Se cosideră că un sistem vechi nu poate fi convertit în altul nou peste noapte. Trebuie să se înceapă cu un grup mai restrâns de specialiști, bine pregătiți, numit celulă RAD, care va începe să lucreze la un proiect pilot pentru a demonstra viabilitatea RAD. Cu timpul, celula va crește, adăugându-se noi persoane și proiecte, până când RAD devine calea dominantă de realizare a sistemului informațional.
Etapele ciclului de viață al sistemelor informaționale, în concepția RAD, sunt: planificarea, analiza, proiectarea și implementarea, deși ele sunt numite: planificarea cerințelor, proiectul utilizatorului, construirea și fasonarea (cutover). Mulți văd RAD ca o variantă în care se combină unele etape ale ciclului de viață al dezvoltării sistemelor. De exemplu, faza RAD “Proiectul utilizatorului” combină analiza cu proiectarea logică și fizică din ciclul de viață al dezvoltării sistemelor, deci trei etape comasate într-una.
Planificarea cerințelor RAD înseamnă tradiționalele activități de identificare și selecție a proiectelor, precum și activități tip analiză. Acordul privind forma viitorului sistem este dat de utilizatori și analiști.
În timpul proiectului utilizatorului, utilizatorul final și informaticienii vor participa la ateliere de lucru JAD, în care cei implicați apelează la mijloace de lucru CASE pentru obținerea rapidă a prototipului proiectului sistemului. Oricând este necesar, clientul poate interveni să-și reformuleze cerințele, ceea ce în cazul ciclului de viață tradițional al sistemelor era posibil doar în faza de început a lui.
De remarcat diminuarea substanțială a timpului necesar de la finalizarea schițării proiectului la folosirea lui, până la 3 luni, față de 18 luni în vechile condiții, datorită efortului imens investit în sistem în activitățile anterioare. Ceea ce trece de la o etapă la alta constituie forma certă, și nu una presupusă a fi acceptată.
Într-o primă parte, eforturile utilizatorului vor fi concentrate spre zona datelor, interfețele cu utilizatorul fiind foarte importante, astfel încât operațiunile de adăugare, modificare, ștergere sau interogare a datelor să fie lejere. Și cum aceste componente pot fi deseori generate de modelele conceptuale ale datelor, primele sesiuni JAD se vor axa pe semnificația și structura datelor necesare sistemului. Următoarele sesiuni vor urmări modul în care datele necesare sunt utilizate, astfel încât să onoreze anumite funcții. Ulterior, alte sesiuni JAD se vor adresa unor funcții mai specializate, care vor analiza modalitățile în care datele răspund și cerințelor altor compartimente (marketing, financiar, contabil, etc.). Pentru aceste funcții complexe vor fi dezvoltate modele ale logicii prelucrărilor sau proceselor decizionale. Prin ele se va arăta modul în care datele sunt supuse unor transformări logice, declanșate de anumite evenimente, astfel încât funcțiile să poată fi realizate. Modelele proceselor pot fi dezvoltate prin engleza structurată, diagrama stărilor de tranziție sau prin alte tehnici de modelare logică pe care le voi prezenta in capitolele următoare.
În etapa de construcție, aceiași specialiști în informatică, autori ai proiectului, vor genera codurile produsului, folosind instrumente CASE de acest gen, precum și manuale de codificare, dacă va fi necesar. În acestă fază este vorba de asmblarea unor componente realizate anterior, prin interfețe interne care să efectueze legăturile dintre ele. Componentele nerealizabile cu instrumente automate trebuie să fie create de către membrii echipei. Utilizatorii finali participă și în faza de construcție, validând ecrane și rapoarte și confirmând alte aspecte referitoare la proiectul aplicației în lucru. Membrii echipei efectuează și lucrări de altă natură: manuale pentru utilizatori, materiale pentru instruire.
Pentru sistemele mai mici, etapa de construcție poate fi cumulată cu proiectul utilizatorului.
Fasonarea înseamnă distribuirea produsului către utilizatorul final. Cum metodologia RAD este extrem de rapidă, planificarea fasonării (implementării) trebuie să înceapă mai devreme. Ea constă în testare, instruirea utilizatorilor, urmărirea eventualelor schimbări organizaționale, execuția în paralel a vechiului și a noului sistem. Toate activitățile enumerate se vor derula într-un ritm accelerat. După această etapă, sistemul trece în regimul procesului normal de întreținere.
Avantajele și dezavantajele RAD
Primul avantaj a fost deja amintit: sistemele informaționale pot fi realizate într-un timp de patru ori mai scurt decât prin metodele tradiționale. Aceasta înseamnă și sisteme mai ieftine, datorită volumului mai mic al resurselor antrenate. Dintre ele, o importanță deosebită o au resursele umane pentru că echipele RAD sunt mai mici.
De asemenea, prin implicarea personală a utilizatorilor, riscul nereușitei se diminuează. Calitatea sistemului este sporită datorită numeroaselor teste ce au avut loc pe parcurs.
Prin reducerea intervalului de timp dintre definitivarea proiectului și punerea lui în lucru se răspunde mai repede și mai bine cerințelor organizațiilor.
Ca dezavantaje ale metode RAD amintim doar câteva obiecții destul de întemeiate, formulate de criticii acestei metode :
Consistența. În graba lor de a proiecta cât mai repede ecrane, analiștii RAD neglijează existența unora chiar în interiorul aplicației, dar, cu siguranță, și în alte aplicații. Preocuparea principală trebuie să o constituie respectarea mărimii, culorilor, formatelor și a modalităților de afișare a mesajelor.
Standarde de programare. Standardele documentației și ale atribuirii de nume datelor sunt realizate în faze timpurii RAD, ceea ce le va face dificilă implementarea mai târziu.
Refolosirea modulelor. În timpul prototipizării, analiștii omit sau nu au timp să cerceteze dacă aceleași ecrane sau rapoarte mai există deja în alte aplicații. Deseori RAD nu oferă posibilitatea analiștilor să verifice dacă modulele ce ar putea fi refolosite există sau nu.
Scalabilitatea. Dacă sistemul proiectat în timpul RAD își demonstrează utilitatea, folosirea sa va conduce la extinderea ariei utilizatorilor inițiali care au participat la construirea sistemului. Realizatorii trebuie să aibă în obiectiv o astfel de extensie. Scalabilitatea se referă și la echipamente; aria de întindere a sistemului, numărul, tipurile și utilizatorii rapoartelor; creșterea echipei de dezvoltare și întreținere a sistemului; instruirea utilizatorilor; securitatea.
Administrarea sistemelor. Administrarea sistemelor este aproape neglijată în timpul RAD. Dintre posibile probleme: întreținerea și reorganizarea bazelor de date, constituirea copiilor de siguranță și reconstituirea sistemului după avarii, etc., toate deosebit de relevante pentru asigurarea protecției și securității sistemului.
În pofida celor enumerate, RAD există și literatura de specialitate consemnează numeroase cazuri de utilizare eficientă a sa. De fapt, succesul RAD înseamnă succesul tuturor tehnicilor moderne folosite în analiza și proiectarea sistemelor.
3.2. Structurarea cerințelor sistemului
3.2.1 Modelarea proceselor
De regulă, termenului “logică” i se pot conferii două semnificații: cea dintâi face trimitere la faptul că o acțiune se bazează pe anumite reguli de judecată, concepție, iar cea de-a doua semnificație se referă la descrierea efectuată unui fenomen, proces, obiect, etc. astfel încât ele să poată fi înțelese.
Indiferent de metodologiile folosite în realizarea unui sistem / aplicație, toate apelează la operațiunea de modelare logică a datelor și prelucrărilor sub formă de diagrame, diferențele constând doar în folosirea mai pronunțată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de date fizice și diagrame ale fluxurilor de date logice. Altele apelează la combinații de diagrame, tabele și forme descriptive.
Diagrama de context scoate în relief aria de întindere a sistemului analizat, prin specificarea elementelor din interiorul organizației și a celor externe (entități externe).
Diagrama fluxurilor de date fizice specifică persoanele și tehnologiile folosite pentru fiecare proces de transfer și transformarea datelor, acceptându-se unele intrări și descriindu-se ieșirile din procesele folosite.
Diagrama fluxurilor de date ale sistemului logic curent, independenta de tehnologie, reliefeaya funcțiile de prelucrare a datelor executate de către sistemul informațional curent.
Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor, structura lor și cerințele funcționale ale noului sistem.
Descrieri ale obiectelor DFD se regasesc în așa zisele dicționare ale proiectelor sau depozite CASE (repository).
În literatura de sprecialitare toate acestea se regăsesc sub denumirea generică de diagrame ale fluxurilor de date.
Întrucât diagramele fluxurilor de date (DFD) au ca obiectiv urmărirea modului de transfer al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc și modele ale proceselor de prelucrare, iar operațiunea se numește modelarea proceselor.
DFD reprezintă doar una din tehnicile de analiză structurată. Ele au avut un puternic impact asupra procesului de dezvoltare a sistemelor. Un exemplu este un caz în care, pe parcursul a șase ani, între 1988 și 1994, la o organizație din SUA s-au realizat economii de 17,2 milioane de dolari la cheltuielile cu software-ul, datorită recurgerii la tehnicile structurate de analiză, prin eliminarea unor activități specifice reviziei cerințelor sistemului, ceea ce a condus la dublarea productivității sistemului.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a căpătat noi accepțiuni prin încorporarea ei în instrumentele de analiză și proiectare cu ajutorul calculatorului, adică în produsele CASE.
În practică, cele mai multe produse apelează la două tehnici de redare a diagramelor fluxurilor de date: Gane & Sarson și Yourdon & DeMarco. În continuare se vor prezenta cele mai importante tehnici de redare a proceselor de prelucrare prin intermediul diagramelor, subliniind aspectele comune dar și diferențele dintre acestea.
3.2.1.1. Tehnica Gane & Sarson pentru construirea DFD
Scopul Diagramelor Fluxurilor de Date (DFD), pentru o anumită componentă organizatorică sau funcțională la care se referă (secție, birou, compartiment, unitate, o anumită activitate – vânzări, cumpărări, încasări, plăți) este de a scoate în relief următoarele aspecte:
sursa datelor ce urmează a fi prelucrate;
operațiunile de prelucrare prin care trec datele;
destinația datelor prelucrate;
legătura existentă între prelucrări și activitatea de stocare a datelor.
Tehinica DFD apelează la patru simboluri de bază pentru a reprezenta atât sistemele informaționale logice, cât și cele fizice, înlocuind clasicele scheme logice și pseudocodurile.
În continuare este prezentat un exemplu pentru a reda conceptele cu care operează această tehnică și anume diagrama fluxului de date privind relațiile cu clienții.
Fig.1. Diagramă de Flux a Datelor în tehnica Gane & Sarson
Această schemă este folosită pentru a evidenția actul de vânzare-cumpărare propriu-zis, din care reiese că un oarecare client, pentru a beneficia de produsele unei firme, trebuie să lanseze o comandă, iar pentru ca vânzarea să aibă loc, în afara altor condiții, este necesară existența produselor solicitate în depozitul furnizorului.
Pentru a evidenția și modul de stingere a obligațiilor de plată din partea clientului, în vederea reîntregirii resurselor financiare ale furnizorului, putem schematiza astfel:
Fig.2. Diagramă de Flux a Datelor în tehnica Gane & Sarson
Schemele prezentate mai sus au un caracter general deoarece, dacă am lua în calcul toate aspectele (comenzi, livrări, încasări, reîtregirea fondurilor, etc.), schema ar căpăta o formă mai complexă, prezentată ulterior.
Revenind la diagrama fluxurilor de date privind relațiile cu clienții, semnificația simbolurilor folosite este următoarea:
Clienți este o entitate externă care constituie obiectul de studiu. Această entitate transmite comenzi de vânzare într-un flux redat prin intermediul săgeții care este insoțită de explicația respectivă.
Prelucrare comenzi (1) dă răspuns comenzii de vânzare prin apelarea la informațiile existente în fișierul PRODUSE (dreptunghiul alungit notat cu D1) și actualizează datele despre vânzări, de asemenea, memorate într-un fișier distinct, VÂNZĂRI, notat cu D2. Prin separarea entităților de procesele care le leagă se asigură independența prelucrării datelor de intrare și ieșire.
Cele două diagrame prezentate mai sus pot fi contopite rezultând o nouă diagramă mai complexă pentru a evidenția procesul de prelucrare a informațiilor privind raporturile dintre furnizori și clienți și implicațiile acestora asupra întregului subsistem CLIENȚI / DECONTĂRI.
Fig. 3. Diagrama fluxului de date privind desfacerea și aprovizionarea cu mărfuri
Diagrama de mai sus prezintă sfera de cuprindere a aplicației. Pentru fiecare vânzare, prelucrarea notată cu 1 actualizează stocurile de mărfuri vândute pe baza elementelor conținute de comenzile primite de la CLIENȚI. La rândul lor, datele păstrate în D2 despre VÂNZĂRI, se folosesc în prelucrările notate cu 2 și 3, pentru pregătirea documentației pentru bancă, respectiv crearea rapoartelor necesare conducerii. Procesul de prelucrare notat cu numărul 4 valorifică informațiile despre VÂNZĂRI din D2, precum și pe cele despre stocurile de mărfuri din depozit, astfel încât să se poată determina necesarul de reaprovizionat. În situația în care se impune întocmirea de noi comenzi de aprovizionare, se valorifică datele din fișierul FURNIZORI, cum ar fi: prețul, adresa furnizorilor, termenele posibile de livrare, etc.
Diagrama scoate în relief și modul de prelucrare a comenzilor de aprovizionare. Rolul esențial îl are activitatea de stocare a datelor despre CLIENȚI, în D5, COMENZI_ÎN_CURS. Prin procedura de prelucrare numărul 5 se vor actualiza informațiile din D5, odată cu efectuarea procesului de recepție a mărfurilor primite de la FURNIZORI.
Se impun câteva comentarii pe marginea pe marginea diagramei fluxurilor de date privind desfacerea și aprovizionarea cu mărfuri:
diagrama fluxului de date stabilește aria de cuprindere a sistemului luat în studiu, precum și zonele din unitate implicate în operațiunile de prelucrare a datelor;
diagrama fluxului de date nu are un caracter tehnic. Chiar și simbolurile folosite sunt ușor de înțeles și utilizat;
diagrama fluxului de date prezintă atât datele stocate în sistem, cât și procesele de prelucrare prin care trec acestea, indicând relațiile existente între date sistemului și procesele de prelucrare.
3.2.1.2. Tehnica Yourdon & DeMarco
Această tehnică folosește simboluri diferite de cele utilizate de tehnica Gane & Sarson și, în plus, sugerează că demersul de realizare a diagramelor unui sistem trebuie să înceapă cu o diagramă de context, prin care să fie prezentate entitățile externe, intrările și ieșirile în / din sistemul analizat.
Tehnica Yourdon & DeMarco sugerează că demersul de creare a diagramelor unui sistem trebuie să înceapă cu o diagramă de context, prin care să fie prezentate entitățile externe, intrările și ieșirile în/din sistemul analizat:
Fig. 4. Diagrama de context pentru procesul vânzare-cumpărare de mărfuri
(Tehnica Yourdon & DeMarco)
Yourdon și DeMarco recomandă cu insistență ca nici o diagramă să nu conțină mai mult de șapte procese de prelucrare (cercuri). Ca atare, un sistem complex trebuie să fie reprezentat printr-un set de diagrame, și anume:
o diagramă de context;
o diagramă de nivel zero, indicând principalele subsisteme ale sistemului;
până la șapte diagrame de nivel unu, indicând principalele funcții (aplicații) ale fiecărui subsistem;
până la 49 de diagrame de nivel doi indicând detaliile fiecărei funcții / aplicații.
Fig. 5. Tehnica descompunerii diagramelor în concepția Yourdon & De Marco
Se recomandă ca funcțiile (aplicațiile) să fie explodate pe această cale până ce detaliile logicii procesului sau “primitivele” pot fi scrise pe cel mult o pagină de pseudocod. În cazul sistemelor complexe, apar totuși necesare nivelurile 3 și chiar 4.
În aceste condiții, diagrama fluxului de date privind desfacerea și aprovizionarea cu mărfuri este reprezentată în felul următor:
Fig. 6. Diagrama fluxului de date privind desfacerea și aprovizionarea cu mărfuri (Yourdon & DeMarco)
3.2.1.3. Diferențe între metodele Gane & Sarson și Yourdon & DeMarco
Există trei diferențe foarte importante între cele două metode:
metoda folosită la descompunerea diagramelor;
modelarea sistemului curent;
relația dintre DFD și modelul datelor.
a) Pentru reliefarea particularităților fiecărui tip de diagramă, următoarele elemente sunt sugestive:
b) indiferent de tipul sistemului analizat, manual sau informatizat, apare o problemă comună: el va fi înlocuit de un nou sistem. Modelul logic propus poate fi conceput pe baza modelului logic curent. Pașii următori pot fi efectuați parcurgând căi diverse. Scopul lor este de a conduce la implementarea modelului logic propus pentru a se putea ajunge la proiectul noului sistem fizic. Secvențial, întregul proces poate fi redat asfel:
Fig. 7. Secvențele procesului de modelare a sistemelor în varianta Yourdon & DeMarco
În timp ce Yourdon și DeMarco recomandă parcurgerea secvențială a pașilor redați în figura de mai sus, Gane și Sarson adoptă o variantă ceva mai categorică. Ei consideră că fiecare proiect trebuie analizat minuțios pentru a se stabilidacă este mai bine să se pornească de la ceea ce există, pentru crearea modelului logic propus, sau trebuie abandonat totul și conceput un model ideal.
Gane și Sarson pornesc de la întrebarea: “Ce trebuie să facă viitorul sistem?” și, din ceea ce există, încearcă să contureze modelul sistemului nou. Sintetic, DeMarco redă procesul de analiză structurată prin șapte pași, iar Gane și Sarson prin cinci pași.
3.2.1.4. Tipuri de diagrame ale fluxurilor de date
Principalele tipuri de diagrame ale fluxurilor de date sunt: diagrama de context (DC), diagrama fluxului de date fizice (DFDF) și diagrama fluxului de date logice (DFDL).
Diagrama de context este diagrama de pe nivelul cel mai de sus al sistemului informațional, prin care se descriu fluxurile datelor în și din sistem, din și spre entitățile externe sistemului analizat așa cum reiese din figura următoare:
Fig. 8. Exemplu de diagramă de context
Pe marginea figurii de mai sus se pot face următoarele comentarii privind terminologia specifică diagramelor de context, pe lângă cea deja discutată. Cercul diagramei de context definește granițele sistemului. Granița reprezintă locul de separare a sistemului studiat de mediul său extern. Mediul constă în tot ceea ce înconjoară sistemul, entitățile diagramei fiind cele mai relevante elemente pentru specificarea mediului extern. Mediul relevant este acea parte a mediului care afectează “sistemul de interes”, după cum este el definit. În figura prezentată mai sus, numai CLIENT și BANCĂ sunt relevante din tot mediul extern.
Alt concept este interfața care este definită ca un flux de legătură al sistemului cu mediul său. În figura amintită, PLATĂ și DEPUNERE sunt interfețe. De asemenea, legăturile între componentele sistemului sunt considerate tot interfețe.
Diagrama fluxului de date fizice (DFDF) este o reprezentare schematică a sistemului prin care sunt scoase în evidență entitățile interne și externe ale sistemului, precum și fluxul datelor în și din aceste entități.
O entitate internă poate fi o persoană, un loc (secție, compartiment) sau un echipament (calculator) din sistem care contribuie la transformarea datelor. Din această cauză, DFDF specifică unde, cum și de cine este realizat acest proces al sistemului. DFDF scoate în relief ce este realizat. De exemplu, în figura ce urmează apare Client Plătește la Vânzător; Vânzător Justificare-vânzări la Casier, etc. deci, putem vedea unde merg banii și cum sunt păstrate informațiile privind încasările, dar nu știm cu exactitate ceea ce face vânzătorul.
Se observă că toate cercurile au în interior câte un substantiv și că fluxurile de date poartă un nume, prin care se sugerează cum datele sunt transmise între cercuri. De exemplu, Client transmite Bani la Casierie. Similar, se poate observa că locul amplasării fișierului indică unde (contabilitate), iar numele fișierului arată cum (Jurnal-vânzări) se ține evidența vânzărilor.
Fig. 9. Diagrama fluxurilor de date
Diagrama fluxului de date logice (DFDL)
Este o reprezentare simbolizată a unui sistem, prin care se evidențiază procesele sistemului, precum și intrările sau ieșirile de date în / din procese. Prin ea se reprezintă natura logică a sistemului, ce activități efectuează sistemul, fără să specifice cum, unde sau de către cine sunt executate activitățile.
Avantajul DFDL față de DFDF este acela că putem reliefa funcțiile executate de sistem. De exemplu, în figura care urmează se poate observa că etichetele de pe fluxurile de date descriu mai degrabă natura datelor decât cum sunt transmise acestea. Este efectuată Plata sub formă de CEC, bani lichizi, în rate? Acest lucru nu rezultă din reprezentare. Jurnal-vânzări este un registru, o cartelă sau un fișier? Nici acest lucru nu rezultă din diagramă. In schimb, printr-o DFDL sunt reprezentate activitățile sistemului, în timp ce DFDF descrie infrastructura sistemului.
Fig. 10. Diagrama fluxului de date logice
Procesele din figura de mai sus sunt specificate prin verbe care descriu acțiunea de executat, și nu prin substantive, folosite în DFDF. Această figură este o redare la nivelul cel mai înalt a cercului din diagrama de context întrucât fiecărui cerc din figura diagramei fluxului de date logice i se alocă un număr urmat de un punct și de un zero (1.0, 2.0, 3.0, 4.0); de aceea un asemenea tip de diagramă este denumită de nivel zero. Chiar dacă DFDF sunt numerotate în mod asemănător, nu se va folosi și în cazul lor noțiunea de nivel zero întrucât nu mai există alte niveluri inferioare.
Când două diagrame ale fluxurilor de date – diagrama de conrext și de nivel 0 – au fluxuri de date externe echivalente, se spune despre ele că sunt diagrame ale fluxurilor de date balansate. Numai seturile de diagrame ale fluxurilor de date balansate sunt corecte (cum sunt: diagrama de context, DFDL și DFDF). Pentru obținerea figurii precedente, diagrama de context a fost explodată în componentele sale de nivel inferior. Fenomenul de descompunere sau “explodare” a DFDL se numește descompunere descendentă sau de sus în jos. Când ea se efectuează corect, conduce la un set balansat de diagrame ale fluxurilor de date.
3.2.2. Modelarea logicii proceselor
Procesele trebuie să fie astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de programare.
În faza de analiză, modelarea logicii proceselor se va derula cât mai detaliat dar operațiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza într-o etapă următoare în proiectare.
Modelarea logicii proceselor, ca și diagramele fluxurilor de date, reprezintă o parte a subetapei de structurare a cerințelor sistemului.
Se poate spune că modelarea logică se va concretiza în următoarele elemente ale documentației: reprezentarea în engleza structurată a logicii proceselor, reprezentarea logicii proceselor prin tabele de decizii, reprezentarea logicii proceselor prin arbori de decizie, tabelul sau diagrama stărilor de tranziție.
3.2.2.1. Modelarea logicii proceselor cu ajutorul tabelelor de decizie
Atunci când se încearcă prezentarea logicii proceselor mai complexe, engleza structurată devine greu de înțeles dar nu și incapabilă să reprezinte algoritmii respectivi. S-a constatat că atunci când apar mai mult de trei IF-uri imbricate, ele sunt greu percepute de către cei ce le analizează. În astfel de cazuri intervin tabelele de decizie.
Tabelele de decizie reprezintă forme de reprezentare tabelară a logicii unor decizii. Pentru orice situație dată, un tabel de decizie conține toate condițiile (IF-uri) care pot interveni în procesul decizional precum și variantele THEN posibile, prin specificarea acțiunilor de întreprins.
Forma generală a unui tabel de decizie este prezentată în tabelul următor:
Un exemplu în care se poate folosi un tabel de decizie este cel care scoate în relief regulile de funcționare a conturilor de activ și pasiv prin egalități contabile fundamentale.
În ciuda utilității lor, tabelele decizionale sunt mai puțin folosite în practică. Probabil rigurozitatea lor îi descurajează pe cei mai mulți dintre potențialii utilizatori.
3.2.2.2. Modelarea logicii proceselor prin arbori decizionali
Un arbore decizional este o tehnică de reprezentare grafică a unei decizii sau a unei situații bazate pe opțiuni prin intermediul nodurilor și ramificațiilor specifice structurilor arborescente.
Ca și tabelele de decizie, arborii decizionali sunt sugestivi în “dialogul” purtat de analiști cu utilizatorii. Întrucât sunt folosiți în structurarea cerințelor, arborii decizionali au două componente principale:
Punctele de decizie (reprezentate prin noduri);
Acțiunile (reprezentate prin elipse);
În figura următoare, voi da exemplul unui model de arbore decizional.
Fig. 11. Model de arbore decizional cu regula de funcționare a conturilor de Activ și Pasiv
3.2.2.3. Modelarea logicii temporale a proceselor cu ajutorul diagramelor și tabelelor stărilor de tranziție
Modelele prezentate până acum nu reușesc să surprindă impactul factorului timp asupra logicii de execuție a unor operațiuni, ceea ce le face nerelevante pentru aplicațiile online și în timp real. În astfel de cazuri se folosesc diagramele sau tabelele stărilor de tranziție, concepute pentru a completa celelalte tehnici de modelare logică.
Diagramele stărilor de tranziție reliefează modul în care procesele unei DFD și alteori chiar stări diferite în timp ale aceluiași proces sunt ordonate în timp.
Tabelele stărilor de tranziție îndeplinesc același rol doar că prezentarea este sub formă tabelară, motiv pentru care voi prezenta doar prima formă.
Astfel de forme de redare a logicii sunt foarte folosite în analiza și proiectarea orientată pe obiect, dar pot fi utile și în realizarea sistemelor orientate pe proces.
Diagrama stărilor de tranziție
O stare poate fi concepută ca un mod sau o condiție de existență a unui proces sau a altei componente a sistemului, după cum sunt determinate de circumstanțele curente din sistem.
În concepția orientată pe obiect, o stare constă în totalitatea proprietăților obiectelor care sunt statice și a valorilor acestor proprietăți care sunt dinamice.
Există simboluri speciale pentru crearea diagramelor stărilor de tranziție:
Fiecare stare este reprezentată printr-un dreptunghi;
Fiecare tranziție se redă printr-o săgeată;
Evenimentul care declanșează tranziția de la o staere la alta apare ca o etichetă atașată săgeții tranziției. Poate fi precedat de C: (condiție);
Acțiunile demarate la înregistrarea unei stări noi apar ca o listă de instrucțiuni, scrise în pseudocod, existând posibilitatea de a fi precedate de A: (acțiuni);
Fiecare stare va fi ordonată în timp; a doua stare o urmează pe prima, a treia pe a doua, ș.a.m.d.
Când se construiesc diagramele stărilor de tranziție, este util să se parcurgă două căi:
se stabilesc toate stările posibile ale sistemului și se evidențiază legăturile dintre ele;
se începe cu prima stare și apoi se analizează ce stări au legătură cu ea și se continuă cu analiza conexiunilor posibile ale fiecărei stări noi cu altele.
Se poate constata că diagramele stărilor de tranziție pot fi folosite și pentru redarea selecției opțiunilor din meniuri sau pentru reflectarea navigării în sistemele on-line gen Internet.
Figura următoare prezintă un model de diagramă a stărilor de tranziție:
Fig. 12. Model de diagramă a stărilor de tranziție
3.2.3. Modelarea conceptuală a datelor
3.2.3.1. Importanță
Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor organizației. Rolul său este de a scoate în relief toate regulile privind identitatea și legăturile existente între date.
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-relație (DER). O modalitate aproape identică este folosită și în analiza și proiectarea orientate pe obiect.
Modelarea datelor prin DER prezintă caracteristicile și structura datelor independent de modul în care acestea sunt memorate în calculator. Modelul se crează iterativ. De cele mai multe ori, operațiunea are loc la nivel de întreprindere, prin apelarea la o categorie foarte largă de date, neglijându-se detaliile exagerate. Doar în etapele următoare, în speță când se trece la definirea proiectului, are loc construirea unui model anume entitate-relație, prin care să fie scoasă în evidență aria de întindere aproiectului. În timpul structurării cerințelor, un model entitate-relație reprezintă cerințele conceptuale de date pentru sistemul luat în discuție. După ce sunt descrise complet intrările și ieșirile sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relație, este rafinat înainte de a fi trecut într-un format logic (de regulă un model relațional al datelor) din care se definesc bazele de date și are loc proiectarea fizică a acestora.
În timpul modelării conceptuale a datelor, se produc și se analizează 4 diagrame entitate relație:
o DER care să acopere doar datele necesare aplicației proiectului. Ea va permite stabilirea necesarului de date ale aplicației proiectului, fără să se țină seama de constrângerile sau confuziile generate de detaliile care nu sunt încă necesare;
o DER pentru aplicația ce va fi înlocuită. Diferențele dintre aceste diagrame arată ce schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicație. Nu se aplică în cazul sistemelor complet noi;
o DER care să scoată în relief întreaga bază de date din care noua aplicație își va extrage datele. Cât timp mai multe aplicații pot folosi aceeași bază de date sau câteva baze de date, această diagramă și prima evidențiază modul în care noua aplicație apelează la conținutul unor baze de date mult mai extinse;
o DER pentru întreaga bază de date din care aplicația curentă își extrage datele necesare. Ea este discutată doar pentru sistemele care există și pentru care se urmărește îmbunătățirea. Din nou, diferențele dintre diagrama precedentă și cea de față vor indica modificările majore de efectuat pentru a se putea influența noua aplicație.
3.2.3.2 Introducere în cadrul conceptual al diagramelor entitate-relație (DER)
Diagramele entitate-relație constituie unul din conceptele esențiale ale analizei și proiectării structurate. După cum reiese chiar din numele diagramei, scopul ei este de a evidenția entitățile de date (obiectele despre care se solicită păstrarea datelor) și relațiile ce există între ele.
Trebuie sesizată diferența dintre diagrama fluxului de date și diagrama entitate-relație. În timp ce DFD indică atât procesele de prelucrare, cât și entitățile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează doar entitățile de date. Din această cauză, DER poate fi considerată și ca diagrama modelului datelor sau diagrama conceptuală a datelor.
Întotdeauna, crearea unei DER presupune găsirea răspunsului la întrebarea: “Care sunt entitățile despre care sunt necesare datele de stocat?”. Răspunsul poate fi destul de simplu. Depinde de aria de extindere a sistemului analizat. Ele ar putea fi: CLIENT, PRODUS, SALARIAT, STOC, FURNIZOR, ș.a.
În sistemul analizat, pentru descrierea DER se apelează la simbolul dreptunghi, pentru fiecare entitate. Se recomandă ca numele entității să fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, etc.).
După ce se identifică entitățile, se continuă cu împerecherea lor, fiecare cu fiecare, pentru a descrie ce relații există între ele.
De exemplu, pentru a arăta că o anumită vânzare se referă doar la un client, deși există mult mai multe acte de vânzare, implicit mai mulți clienți, relația poate fi redată schematic asfel:
Fig. 13. Diagramă entitate-relație simplă pentru procesul de vânzare
O vânzare, la rândul ei, constă din unul sau mai multe produse, dar și produsele pot constitui subiecte ale mai multor vânzări, deci între entitățile VÂNZARE și PRODUS se va folosi câte o săgeată la fiecare capăt al liniei ce leagă cele două entități. Antrenând în sfera discuțiilor și comanda de aprovizionare, COMANDĂ, și furnizorul, FURNIZOR, s-ar putea construi următoarea diagramă entitate-relație:
Fig. 14. Diagramă entitate-relație complexă
În lucrul cu DER, o mare importanță în activitatea de analiză a acestora o deține cunoașterea faptului că întotdeauna relațiile multe-la-multe pot fi descompuse în două relații de tipul unu-la-multe, prin aflarea entității –intersecție.
Relația dintre PRODUS și VÂNZARE, de tip multe-la-multe, în forma ei inițială, poate fi redată astfel:
Descompunerea ei în două relații de tip unu-la-multe poate fi redată sub forma:
Entitatea-intersecție este ceva ce se va impune de la sine între cele două entități, putându-se marca momentul de căutare a noii entități:
Semnul de întrebare înlocuiește răspunsul care trebuie găsit la întrebările: Ce ar putea fi asociat cu entitatea generală simplă PRODUS care să poată da naștere la o legătură de tip multe?, precum și Ce anume s-ar putea asocia entității simple VÂNZARE, printr-o legătură de tip multe, dar care să exprime relația dintre produse și vânzări?. Răspunsul este clar: un articol anume, deoarece vânzarea constă din mai multe articole vândute prin aceeași tranzacție externă. Astfel, diagrama rezultată va arăta astfel:
Relațiile unu-la-unu, de asemenea, trebuie supuse analizei pentru a constata dacă într-adevăr cele două entități simple sunt total diferite și nu pot fi combinate în nici un mod. În exemplul anterior, există doar o singură relație unu-la-unu, cea dintre PRODUS și STOC. Dacă entitatea PRODUS va prelua elementele din STOC, atunci cea de-a doua poate dispărea. Este cazul tipic al nomenclatoarelor, care pot prelua și elemente ale unor fișiere de stare.
În urma analizelor efectuate asupra diagramei entitate-relație și a modificărilor aduse, rezultă o nouă diagramă:
Analiza entitate-relație este o operațiune deosebit de importantă pentru scoaterea în relief a datelor, a structurii lor. În unele metodologii, cum ar fi ingineria informației, aceasta constituie principalul instrument analitic, în timp ce în altele analizele entitate-relație se folosesc în combinație cu analizele fluxurilor de date.
3.2.3.3. Relațiile entităților
Relațiile reprezintă liantul între componentele unei diagrame entitate-relație. O relație este o asociere între cazurile/instanțele unei sau mai multor tipuri de entități care prezintă interes pentru organizație. Ele se pot simboliza printr-un romb. De regulă, sunt redate prin verbe.
Gradul relațiilor este reprezentat printr-un număr al tipurilor de entități care participă la o relație. Cele mai întâlnite relații în modelele entitate-relație sunt:
unare (grad unu);
binare (grad doi);
ternare (grad trei).
Pot exista grade și mai mari, dar în practică acestea sunt foarte greu de întâlnit. Cele trei grade ale entităților sunt exemplificate în figura următoare:
Fig. 15. Gradele relațiilor
Fig. 15. Gradele relațiilor (continuare)
Cardinalitatea relațiilor este dată de un număr al cazurilor/instanțelor entității B care pot sau ar putea să fie asociate cu fiecare caz al entității A, presupunând că există două tipuri de entități, A și B, între care există o linie de legătură pentru a marca relația. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”).
3.2.3.4. Tipuri de relații
În continuare vor fi prezentate tipurile de relații deja amintite, cu unele completări:
a) Relația unu-la-unu (1:1)
“Fiecare BIROU este condus de un, și numai un, MANAGER”
“Fiecare MANAGER conduce un, și numai un, BIROU”
b) Relația unu-la-multe (1:M)
“Fiecare VÂNZARE implică unul sau mai multe ARTICOL(e)_VÂNDUT(e)”
“Fiecare ARTICOL_VÂNDUT face parte din numai o VÂNZARE”
c) Relația multe-la-multe (M:N)
“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”
“Fiecare PRODUS este livrat de unul sau mai mulți FURNIZOR(i)”
d) Relații opționale și obligatorii
Uneori, relațiile dintre entități nu-și fac simțită prezența în toate situațiile. Un exemplu elocvent ar fi cel în care un student poate lucra la un singur proiect sau la câteva, sau la nici unul și, invers, un proiect poate fi realizat de un student, de mai mulți sau de nici unul. În astfel de situații, se apelează la următoarea formă de reprezentare:
Cercul suprapus pe latura entității indică, de fapt, poziția zero (valoarea minimă poate fi zero), conferind relației caracterul opțional.
Un alt aspect se referă la caracterul obligatoriu al relațiilor. Cu alte cuvinte, o entitate poate exista fără cealaltă? Spre exemplu, nu poate exista nici o vânzare fără cel puțin un articol vândut și, invers, un articol nu poate fi vândut fără a exista un act de vânzare.
e)Relația unei entități cu ea însăși
În practică apar și situații în care o entitate este pusă în relație cu ea însăși. Un exemplu ar putea fi cel al entității ANGAJAT. Unii dintre ei dobândesc statutul de coordonatori ai activității celorlalți, situație în care se poate apela la o diagramă de genul:
“Un angajat poate fi coordonatorul unuia sau mai multor angajați”
“Oricare angajat întotdeauna raportează altui angajat”
f) Relații alternative (sau/sau)
Uneori se ivesc situații când relațiile posibile se redau alternativ: fie o variantă este de urmat, fie cealaltă.
De exemplu, o marfă destinată vânzării poate fi realizată de unitatea care o vinde sau poate fi procurată din afară. În ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pusă în legătură cu cele două surse posibile, PRODUCȚIA_ALTORA și PRODUCȚIA_PROPRIE, printr-un punct comun, dar cu linii de relații distincte:
“O marfă se poate asocia sau cu un producător din afară, sau cu producția unității”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producție poate livra mai multe mărfuri”
3.2.3.5. Reguli economice regăsite în diagramele entitate- relație
Modelarea conceptuală a datelor este un proces pas-cu-pas pentru documentarea cerințelor informaționale, concretizată în preocuparea de regăsire a structurii datelor, dar și a regulilor prin care se oferă încredere în integritatea acestora.
Regulile economice constituie specificații/descrieri care oferă integritatea modelului logic al datelor. Există patru tipuri de bază ale regulilor economice:
Integritatea entității. Fiecare caz/instanță al/a unei entități trebuie să aibă un identificator unic (valoarea cheii primare), care nu trebuie să fie nul.
Regulile de stabilire a relațiilor dintre entități. Regulile referitoare la relațiile dintre tipurile de entități.
Domenii. Restricții privind valorile ce pot fi luate de atribute.
Declanșatori. Sunt luate în considerare alte reguli economice care protejează validitatea atributelor.
Aspectele privind regulile impuse de afacere sunt urmărite în timpul procesului de determinare a cerințelor sistemului și se păstrează în depozitul CASE, dacă se apelează la astfel de tehnici de lucru.
Capitolul 4. PROIECTAREA SISTEMELOR INFORMATICE
Proiectarea logică se derulează prin intermediul a trei pași sau subfaze:
proiectarea formularelor/formatelor (pentru preluarea datelor) și a rapoartelor, prin intermediul cărora utilizatorii vor avea imaginea intrărilor și ieșirilor noului sistem;
proiectarea interfețelor și a dialogurilor, pentru evidențierea modului de comunicare a utilizatorului cu softul de sistem;
proiectarea bazelor de date logice, prin care este descrisă structura standard a bazei de date a sistemului ce va fi ușor de implementat prin multitudinea de tehnologii existente în domeniul bazelor de date.
Toate intrările și ieșirile fazei de proiectare logică vor fi prezentate ca fluxuri ale datelor între un proces manual și altul automat sau între o sursă/destinație și un proces automat din diagramele fluxurilor de date. De regulă, se poate proiecta câte un formular sau raport pentru fiecare flux de date dintre utilizator și sistem.
Totuși, punctul de plecare în modelarea logică îl constituie diagramele entitate-relație, deși, în plus, vor fi utilizate nu numai datele din acestea, ci și cele descoperite în timpul proiectării logice. Similar, din diagrama de acțiuni vor fi preluate evenimentele ce declanșează acțiunile utilizatorului, semnalate prin meniuri, butoane, comenzi date calculatorului.
4.1. Proiectarea formularelor și a rapoartelor
Datele elementare conținute de fluxurile de date înseamnă, în același timp, și conținuturile formularelor de intrare sau ale rapoartelor și răspunsurilor la întrebări. Datele formularelor sau rapoartelor pot fi date elementare ale locurilor de stocare și ale datelor din modelul entitate-relație al aplicațiilor sau pot fi calculate pe baza acestor date elementare.
Un formular poate fi un document primar sau o machetă de ecran care conține unele date predefinite, cărora li se adaugă altele ce urmează a fi completate în rubrici special rezervate.
Din punct de vedere structural, un formular este un element tipărit, cu antet și alte componente pretipărite, precum și cu spații (rubrici) pentru completarea cu date. Într-un sistem de prelucrare automată a datelor, formularul este asociat imaginii afișate pe ecran, identică formularului tipărit. Datele afișate din formulare sunt cunoscute sub numele de date constante, în timp ce elementele ce vor fi completate sunt numite date variabile. Imediat ce datele variabile au fost completate pe formular, în câmpurile corespunzătoare, formatul devine o înregistrare (articol) sau o tabelă.
Majoritatea formularelor au în structură patru elemente determinate: introducerea, instrucțiunile, partea principală (corpul) și concluziile.
Introducerea, în general, trebuie să apară la începutul formularului și să conțină titlul acestuia, numărul său și, dacă formularul trebuie distribuit altcuiva, numele și adresa organizației respective.
Instrucțiunile sunt de două feluri: ele precizează fie modul de completare a formularului, fie destinația lui după completare. Uneori, numele elementelor de completat sunt atât de clare încât nu mai necesită informații speciale pentru completare. De regulă, formularele cu un pronunțat caracter tehnic, necesită mai multe informații în partea principală sau pe verso. Instrucțiunile în legătură cu ceea ce trebuie făcut cu formularul trebuie să fie foarte clare, specificându-se pentru fiecare exemplar unde trebuie să ajungă. În proiectarea acestor formulare trebuie să se urmărească o cât mai simplă formă de realizare.
Partea principală este cea care concură la utilizarea unor formulare cât mai simple. Relațiile logice dintre căsuțe trebuie să fie grupate; căsuțele și coloanele trebuie să fie foarte clar conturate, și evident, locul unde trebuie completate, mai ales când datele din el vor fi supuse prelucrării automate.
Concluziile apar la sfârșit și se referă la înregistrarea informațiilor cu privire la dispozițiile finale și/sau la aprobările necesare în leg’turile cu operațiile consemnate, incluzând semnăturile și data. Dacă este vorba de un formular cu operațiuni financiare, el trebuie să conțină și totalul formularului.
De asemenea, la proiectarea formularelor trebuie să se mai țină seama și de alte principii. De exemplu, în funcție de importanța documentului se va alege tipul de hârtie corespunzător iar caracterele din interiorul lui vor fi tipărite în forme variate. Părțile lui trebuie să fie marcate distinct și în concordanță cu standardele existente.
Un raport este un document economic în care sunt incluse doar date predefinite, ceea ce înseamnă că poate fi numit și document pasiv, folosit în mod exclusiv pentru a fi citit sau vizualizat.
Obiectivul prezentării detaliate a ieșirilor este și acela de a determina formularul și conținutul tuturor rapoartelor imprimate, ale documentelor și ecranelor formulate de sistem. Conceperea ieșirilor se va face astfel încât să răspundă și cerințelor utilizatorilor, și celor ce se ocupă cu proiectarea.
Cele mai multe rapoarte au o formă excelentă de prezentare, când se apelează la instrumentele grafice. Cantități mari de date pot fi condensate în câteva pagini de rapoarte grafice, ce pot fi mult mai ușor interpretate decât rapoartele cu coloane. Pachetele de programe moderne au o multitudine de facilități de lucru în mod grafic.
În funcție de momentul elaborării rapoartelor, ele pot fi clasificate în patru categorii:
rapoarte programate (la termen) – au un conținut predeterminat și formatul lor este dinainte stabilit; aici se încadrează rapoartele realizate lunar pentru fiecare compartiment, analizele săptămânale ale vânzărilor, precum și dările de seamă financiar-contabile.
Analizele neprogramate cu rol special – deseori numite și rapoarte ad-hoc, nu au conținutul și forma dinainte stabilite și nu sunt realizate conform unor programări anterioare. Ele sunt elaborate ca răspuns la întrebările managerilor privind anumite probleme de planificare managerială.
Rapoartele declanșate de excepții. Au un conținut predeterminat și un format anume, dar sunt elaborate numai când sunt realizate unele condiții de excepție (depășirea costurilor, stocuri supradimensionate, etc.).
Rapoartele la cerere – au conținut și formă predetrminate dar sunt elaborate numai ca răspuns la cererea managerilor sau a altor angajați. Atât rapoartele declanșate de excepții, cât și cele la cerere explică puterea sistemelor bazate pe calculatoare de a fi deosebit de eficiente în procesul conducerii.
4.1.1. Aspecte tehnice ale proiectării formularelor și rapoartelor
Atât formularele, caât și rapoartele constituie cele mai interesante piese ale sistemului pentru utilizatorii acestuia. Proiectarea ieșirilor trebuie să se realizeze după un anumit procedeu-cadru, specific prototipizării, ca în figura următoare.
În timpul procesului de proiectare a formularelor și rapoartelor trebuie să se găsească răspunsuri la întrebările: cine, ce, când, unde, cum, conform următorului model:
Cine este beneficiarul formularului, raportului sau răspunsului la întrebări?
Ce trebuie să conțină formularul, raportul sau răspunsul la întrebări?
Când se solicită obținerea ieșirilor?
Unde să fie transmis formularul, raportul sau răspunsul la întrebări și unde să fie folosit?
Cum se vor utiliza ieșirile respective? Câte persoane le vor folosi sau le vor vedea?
Fig. 16. Metodologia prototipizării
4.1.2. Evaluarea satisfacției utilizării ieșirilor
Atunci când utilizatorul evaluează performanțele formularelor sau rapoartelor, operațiunea se referă la câteva aspecte esențiale și anume: viteza cu care se efectuează o activitate, precizia rezultatelor obținute, satisfacția folosirii ieșirilor respective.
Utilizatorul privește formularele și rapoartele din punctele lui de vedere, care pot fi prezentate astfel:
Stabilitate (consistență) – presupune folosirea acelorași termeni, abrevieri, formate, titluri și metode de navigare în toate ieșirile sistemului
Eficiența – formatarea trebuie să se deruleze în strânsă concordanță cu sarcinile de executat. Textele trebuie să fie aliniate, coloanele sortate, deplasarea facilă. Pe cât este posibil, ar trebui să fie evitate introducerile de date necesare obținerii ieșirilor
Comoditate – să nu se facă trimiteri la fișiere anterioare, să se folosească etichete clare, precum și factori de scală corespunzători
Format – formatul informației trebuie să se mențină pentru aceleași tipuri de date și să scoată în evidență ceea ce este important
Flexibilitate – trebuie să i se ofere utilizatorului posibilitatea de a lista în modurile dorite de el, de a opri procesul și de a naviga în locurile dorite.
În concluzie, satisfacția în utilizare s-ar putea rezuma la: timpul de învățare, viteza în execuție, rata erorilor, rezistența în timp (stabilitatea), satisfacții subiective.
4.2. Proiectarea interfețelor și a dialogurilor
Noțiunea de interfață este destul de des întâlnită în literatura informatică deși ea are și o accepțiune generală în limbajul curent, în sensul de element de legătură între două unități.
Referindu-se la software-ul de sistem, Schulteis, Sumner și Bock afirmă că “prin intermediul echipamentelor electronice de calcul și a unui timp anume destinat, software-ul sistemelor acționează ca o legătură sau o interfață între sistemul de calcul și programele de aplicații pe care utilizatorul dorește să le execute”. De cele mai multe ori, funcția de legare între ele a două componente este realizată de un subsistem special proiectat în acest scop.
Specificațiile de proiectare a interfețelor și dialogurilor se pot concretiza într-o formă similară celei descrise la proiectarea formularelor și rapoartelor, cu un element suplimentar: descrierea secvenței de derulare a dialogurilor.
Sinteza elementelor specificației de proiectare a interfețelor și dialogurilor este redată în caseta următoare:
Dialogul
Dialogul, în informatică, are aceeași semnificație ca și în accepțiunea cotidiană: conversație între doi parteneri.
Datorită importanței sale, dialogul, în multe componente informatice – cum ar fi sistemele de sprijinire a procesului decizional sau sistemele expert, dispune de un subsistem propriu de funcționare. Subsistemul de management al dialogurilor a fost redat schematic în caseta de mai sus.
Caracteristica principală a sistemelor performante în privința dialogurilor o constituie diversitatea formelor de introducere a datelor și extragerea rezultatelor. Inteligența artificială a adăugat o calitate deosebită a dialogului: utilizatorul poate să spună ceea ce dorește sau să activeze sistemul prin voce.
4.3. Proiectarea logică a bazelor de date – modelarea logică a datelor
Capitolul de față este în strânsă legătură cu modelarea conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date, fără să se înregistreze o preocupare anume referitoare la calitatea modelelor de date.
Prin modelarea logică se urmărește atingerea a trei obiective:
Structurarea performantă a datelor prin procesul de normalizare;
Obținerea unui model logic al datelor în care să se poată realiza proiectul bazei de date fizice, adică modelul relațional – cel mai utilizat în prezent, deși se pot obține și moelele rețea, ierarhice sau oreientate pe obiect.
Realizarea unui model al datelor care să răspundă cerințelor actuale de date regăsite în formulare și rapoarte. Modelarea logică este un proces ascendent (bottom-up) de obținere a relațiilor din formulare și rapoarte, numirte și perspectiva sistemului prin prisma utilizatorului. Va urma o integrare a relațiilor disparate din formulare și documente într-un model logic, consolidat al datelor. De asemenea, va fi prezentat modul de transformare a modelului entitate-relație într-o formă relațională, astfel încât modelul conceptual să fie comparat cu cel logic al datelor pentru desprinderea și rezolvarea diferențelor dintre ele.
Modelarea logică a datelor descrie datele cu ajutorul unei notații speciale care corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de date relaționale, numit și model relațional.
Procesul de modelare logică a datelor se derulează în paralel cu celelalte activități ale proiectării logice: proiectarea formularelor și a rapoartelor și proiectarea dialogurilor și interfețelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-relație, ci și pe baza machetelor, formularelor și a rapoartelor. Se efectuează analiza datelor elementare din intrările și ieșirile sistemului pentru a se desprinde legăturile dintre ele.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viață al sistemelor se regăsește câte o activitate specifică a datelor, conform tabelului următor:
În procesul de modelare logică există patru pași esențiali:
realizarea unui model logic al datelor din perspectiva utilizatorului (formulare și rapoarte) privind aplicația, folosindu-se principiile normalizării;
contopirea tuturor perspectivelor normalizate ale utilizatorilor într-un model logic consolidat (centralizat al datelor). Pasul mai este numit și integrarea perspectivelor;
transformarea modelului conceptual al datelor (entitate-relație), realizat fără să se țină cont de perspectiva utilizatorului, într-un set de relații normalizate;
compararea modelului logic consolidat al datelor cu modelul transformat al entității-relației și realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicației.
4.3.1. Simplificarea structurii datelor prin normalizare
În procesul de analiză a cerințelor unui sistem, pot fi identificate și descrise punctele de vedere ale unei mulțimi de utilizatori. Deseori, numărul perspectivelor utilizatorilor despre aceeași bază de date poate fi de ordinul zecilor. Fiecare are în vedere anumite date elementare din baze. De exemplu, într-o “situație a absolvenților” sunt surprinse 8 date elementare: MATRICOLA_STUDENT, NUME_STUDENT, SPECIALIZAREA, COD_EXAMEN, TITLU_EXAMEN, NUME_EXAMINATOR, SALĂ_EXAMINATOR, NOTA. La o analiză mai atentă însă rezultă că aceste date elementare aparțin câtorva entități, cum sunt: STUDENT, CURS, EXAMINATOR.
Principala problemă a proiectării logice a bazelor de date poate fi redată astfel: dată fiind dimensiunea meta-datelor (date despre date) colectate în procesul de studiere a cerințelor sistemului, se pune problema cum ar trebui proiectat moelul conceptual al datelor pentru a reprezenta meta-datele cât mai natural și complet, în cea mai simplă formă și cu cea mai mică redundanță posibilă. Cu alte cuvinte, cum ar trebui combinate datele elementare pentru a forma relații (sau tipuri de înregistrări) care să descrie entitățile și relațiile dintre ele? În limbajul bazelor de date, cuvântul relație, înseamnă un tabel de date ceea ce duce la concluzia că bazele de date relaționale sunt clădite pe un grup de tabele legate între ele.
Scopul normalizării este să reducă complexitatea imaginilor pe care le au utilizatorii la seturi de structuri mai mici și mai stabile.
Pașii parcurși în normalizare sunt redați schematic în următoarea figură:
Fig. 17. Pașii normalizării
Prima formă normală
O relație este normalizată dacă conține numai valori elementare la intersecția fiecărei linii cu o coloană, deci relația normalizată nu conține grupuri care se repetă.
Pentru normalizarea unei relații care conține un singur grup ce se repetă, se extrage grupul și se vor forma două noi relații. Procesul de separare este redat în următoarea figură.
Cele două relații por fi descrise astfel:
relația STUDENT conține atribute care nu fac parte din grupul ce se repetă. Ea conține MATRICOLA_STUDENT, NUME_STUDENT și SPECIALIZAREA. Cheia primară a relației este MATRICOLA_STUDENT.
Relația EXAMEN_STUDENT conține atributele grupului care se repetă. Cheia primară este una compusă, formată din MATRICOLA_STUDENT și COD_EXAMEN. MATRICOLA_STUDENT este cheie primară în prima relație, în timp ce COD_EXAMEN este un atribut care identifică fiecare disciplină de examen din grupul repetat pentru fiecare student. Numai prin cele două atribute se poate identifica o anumită notă a unui absolvent. Cheile compuse sau concatenate sunt tipice (dar nu ca o regulă generală), ca rezultat al normalizării.
Anomalii la inserare: presupunem că dorim să inserăm noi date în relația a doua pentru un nou examen (codul și titlul). Operațiunea nu se poate rezolva până nu apare un student care să intenționeze să dea un examen, deoarece matricola student este componentă a cheii compuse. La fel s-ar întâmpla și dacă am dori să introducem și numele unui nou profesor examinator.
Anomalii la ștergere: studenții de la unele secții au posibilitatea să-și aleagă disciplinele examenului de licență. Să presupunem că o anumită disciplină, codificată DA (Dreptul afacerilor) a fost opțiunea unui singur student. Dacă studentul nu promovează, operațiunea de ștergere a acestui tuplu este firească, numai că ea va duce și la pierderea datelor despre disciplina amintită și profesorul examinator.
Anomalii la actualizare: dacă se schimbă titulatura unei discipline de examen, operațiunea va fi foarte anevoioasă deoarece trebuie căutați toți studenții care au optat pentru ea.
Anomaliile de mai sus apar deoarece unele atribute care nu sunt cheie în relație depind numai de atributul COD_EXAMEN și nu de întreaga cheie primară (MATRICOLA_STUDENT și COD_EXAMEN). Doar NOTA este un atribut ce depinde de toată cheia. Pentru cazurile cînd un atribut depinde total de cheia compusă, se spune că este total dependent de acea cheie, iar când dependența este numai în funcție de o parte a cheii compuse, se spune că acel atribut este parțial dependent de cheia primară.
A doua formă normală (2NF)
După cum reiese și din schema generală a normalizării, operațiunea de eliminare a unor anomalii rezultate după prima formă a normalizării, prin extragerea dependențelor funcționale parțiale, constituie obiectivul celei de-a doua forme de normalizare.
O relație este în forma a doua normalizată dacă ea se află deja în prima formă și dependențele funcționale parțiale i-au fost extrase.
Pentru transformarea unei relații cu dependențe parțiale în forma a doua normalizată, se vor crea alte două relații (din cea existentă); una cu atributele total dependente de cheia primară și cealaltă cu dependențe de anumite părți ale cheii primare.
Relația EXAMEN_STUDENT se decompune în alte două relații, astfel:
Relația INREG_NOTA, cu cheia compusă (MATRICOLA_STUDENT+COD_EXAMEN) și cu un atribut non-cheie (total dependent de cheia primară). ÎNREG_NOTA este în cea de-a treia formă normalizată (3NF).
Relația EXAMEN_PROF, cu cheia primară COD_EXAMEN, are atributele non-cheie TITLU_EXAMEN, NUME_EXAMINATOR, SALA_EXAMINATOR (toate dependente numai de COD_EXAMEN).
Se observă că anomaliile din a doua fază au fost eliminate în noile relații- în relația EXAMEN_PROF, o disciplină de examen apare o singură dată (am pornit de la premisa că un examen se dă doar cu un profesor), ceea ce duce la efectuarea, cu ușurință, a operațiunii de actualizare (să presupunem că s-a schimbat examinatorul), prin intervenția doar asupra unui tuplu. Și încă un element pozitiv: prin separarea totală a datelor de spre examene de cele despre studenți, pot fi adăugate și șterse disciplinele de examen, fără să aibă legătură cu datele despre studenți.
Deși lucrurile par a fi rezolvate, la o analiză mai atentă se poate constata că ar mai fi fost posibile unele filtre, atât timp cât în relația EXAMEN_PROF se ascunde entitatea PROFESOR. Diagrama dependențelor din relația EXAMEN_PROF este redată în figura următoare:
Se observă că fiecare din atributele non-cheie este dependent de COD_EXAMEN, dar SALA_EXAMEN depinde și de NUME_EXAMINATOR. Pentru forțarea notei, s-ar putea considera că fiecare profesor poate să examineze în propriul cabinet (unde poate fi repartizat singur), și atunci fiecărui profesor îi va fi atribuită o altă sală. Într-un astfel de caz putem spune că se înregistrează o dependență tranzitivă, ceea ce ar însemna că atributul non-cheie (SALA_EXAMINATOR) este dependent de unul sau mai multe atribute non-cheie (cum ar fi NUME_EXAMINATOR).
Dependențele tranzitive simple apar sub forma:
Când își fac apariția, dependențele tranzitive conduc la generarea anomaliilor în procesele de inserare, ștergere și actualizare, ca și în cazul celor parțiale.
Anomalii la inserare: dacă s-ar intenționa introducerea datelor despre un nou profesor în relația EXAMEN_PROF, se constată că operațiunea este realizată prin intermediul cheii primare COD_EXAMEN, deci, cât timp un profesor nu are de susținut unul dintre examenele de licență nu poate apărea în baza de date.
Anomalii la ștergere: ștergerea datelor despre o anumită disciplină conduce și la pierderea datelor despre profesorul examinator respectiv.
Anomalii la actualizare: dacă un profesor examinează studenții la mai multe discipline, el apare în mai multe tupluri, deci actualizarea ar însemna căutări multiple în bază și schimbarea datelor despre acel profesor la fiecare apariție a sa.
A treia formă normalizată (3NF)
Se poate spune despre o relație că se află în a treia formă normalizată dacă ea este în cea de-a doua formă și nu conține dependențe tranzitive.
O relație în cea de-a treia formă normalizată are relațiile de dependență simple astfel:
Extragerea dependențelor tranzitive din relația EXAMEN_PROF este prezentată în figura următoare:
Fig. 18. Extragerea dependențelor tranzitive
Atributele non-cheie NUME_EXAMINATOR și SALA_EXAMINATOR vor constitui noua relație, PROFESOR, în care NUME_EXAMINATOR este cheie primară, considerându-se totuși că NUME_EXAMINATOR identifică în mod unic SALA_EXAMINATOR.
În relația EXAMEN, atributul NUME_EXAMINATOR este non-cheie, însă apare subliniat prin linie punctată pentru a se sugera faptul că el este cheie primară în cadrul altei relații (foreign key), PROFESOR.
După toate operațiunile efectuate până în acest moment, normalizarea este terminată. Astfel, din relația nenormalizată NOTE_ABSOLVENȚI s-au desprins următoarele relații în cea de-a treia formă normalizată: STUDENT, INREG_NOTA, EXAMEN și PROFESOR. Anomaliile descrise anterior nu-și mai pot face simțită prezența.
Dincolo de cea de-a treia formă a normalizării
Pentru produsele CASE este suficient ca relațiile să fie prezentate în cea de-a treia formă normalizată pentru a se spune că sunt concepute cu atenție și că anomaliile nu-și mai fac apariția. Cu toate acestea, cercetătorii din domeniu au descoperit că, în anumite condiții, acestea încă mai pot exista, ceea ce a condus la continuarea pașilor normalizării. Astfel, pot fi menționați pași suplimentari ai normalizării, cum ar fi: normalizarea în forma Boyce-Codd (BCNF), normalizarea în forma a patra (4NF), forma normalizată domeniu-cheie (DK/NF).
4.4. Proiectarea bazelor de date
Într-o definiție funcțională, baza de date poate fi văzută ca un set de fișiere intercorelate. Legăturile dintre fișiere sunt identificate și reprezentate prin intermediul legăturilor dintre relații (tabele), redate sub forma modelelor conceptuale și logice ale datelor. Ele constituie punctul de plecare în proiectarea fizică a bazelor de date, precedată de proiectarea fișierelor fizice.
Când se proiectează arhitecturile bazelor de date, trebuie să fie luate în considerare mai multe aspecte, dintre care determinantă este mărimea sistemului. De fapt, arhitecturile scot în evidență modalitățile de definire și structurare a datelor.
Selectarea arhitecturii adecvate organizației revine ca sarcină analiștilor bazelor de date, dar analistul de sistem are o contribuție importantă. Sistemele de gestiune a bazelor de date servesc operațiunii de implementare a uneia dintre cele patru arhitecturi cunoscute: ierahică, rețea, relațională și orientată-obiect.
Modelul ierarhic al bazelor de date
Modelul ierarhic al bazelor de date este unul dintre cele mai vechi modele arhitecturale ale bazelor de date și poate fi încă folosit în organizațiile mari, în care prioritară este prelucrarea unui imens volum de tranzacții. Arhitectura modelului ierarhic este prezentată în figura următoare.
Fig.19. Modelul de date ierarhic
Modelul rețea al bazelor de date
Acest model poate fi utilizat în situații mult mai complexe, datorită posibilității de asociere a unui număr arbitrar de fișiere, însă, ca urmare a dificultăților tehnice de folosire, doar specialiștii de înaltă clasă pot apela la un astfel de model. Modelul rețea este prezentat în figura următoare:
Fig.20. Modelul de date rețea
Modelul relațional al bazelor de date
Pentru majoritatea utilizatorilor, reprezintă unicul model utilizabil, din cauza proliferării lui îndeosebi pe platformele bazate pe PC-uri, celelalte modele fiind, practic, inexistente pentru ei.
Legăturile dintre relații se realizează prin cheile lor, în varianta cheie-primară cheie-străină, conform figurii următoare:
Fig.21. Modelul de date relațional
Modelul orientat-obiect al bazelor de date
Acest model se bazează pe procesul de încapsulare a atributelor și metodelor (funcțiilor) în structuri numite clase de obiecte. Esența modelului este redată în figura de mai jos.
Fig. 22. Modelul de date orientat obiect
Literatura de specialitate efectuează chiar o ierarhizare a arhitecturilor bazelor de date), după cum urmează:
Generația I: structuri de fișiere
Generația a II-a structuri ierarhice
Generația a III-a structuri rețea
Generația a IV-a structuri relaționale
Generația a V-a structuri orientate-obiect.
Datorită unor rezultate noi, obținute pe plan tehnologic, au apărut concepte noi, cum sunt: baze de date distribuite, baze de date hypermedia sau mașini de baze de date.
Bazele de date distribuite, în mod firesc asociate altui concept, acela de prelucrare distribuită, sunt baze de date stocate în cel puțin două locuri diferite, în varianta în care copii ale bazei de date sau părți ale ei sunt stocate în locuri diferite, de unde se poate asigura și întreținerea ei.
Bazele de date hypermedia trateză datele prin intermediul unei rețele de noduri, legate între ele în orice mod posibil, conform doleanțelor utilizatorului. Nodurile pot conține text, grafică, sunet, imagine animată și programe executabile. Datorită flexibilității definirii nodurilor, prin utilizarea unor realizări din domeniul inteligenței artificiale, se mai numesc și baze de date inteligente.
4.5. Proiectarea securității fișierelor și bazelor de date
În faza proiectării fizice a fișierelor și bazelor de date, un aspect foarte important îl constituie controlul acestora, ceea ce înseamnă preocupări pe linia securității “averilor” informaționale. Securitatea este abordată din mai multe puncte de vedere, dar cea referitoare la fișiere presupune luarea unor măsuri pentru reconstituirea datelor pierdute sau prelucrate eronat, precum și pentru blocarea accesului neautorizat sau incomodarea până la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal.
Așadar, două aspecte vor fi relevante: reconstituirea datelor și criptarea lor.
4.5.1. Reconstituirea datelor
Reconstituirea datelor este des asociată cu existența fișierelor back-up, însă în practică este posibilă reconstituirea fără apelarea la acest tip de fișiere. Prima variantă, pe bază de fișier back-up, este cunoscută și sub numele de reconstituire înainte (forward recovery), iar cealaltă, fără fișier back-up, este numită reconstituire înapoi (backward recovery). Cele două variante de reconstituire sunt prezentate în figurilede mai jos.
Fig. 23. Metoda de reconstituire înainte (forward recovery)
Fig. 24. Metoda de reconstituire înapoi (backward recowery)
În vederea controlării corectitudinii datelor despre tranzacții, se apelează la fișiere cu rol special care conțin un istoric, în ordine cronologică, al schimbărilor și accesărilor efectuate asupra fișierelor sau bazelor de date. Aceste fișiere se numesc probe în auditare. Ele, împreună cu alte fișiere, cum ar fi registrul tranzacțiilor, vor conține imaginea înregistrărilor înainte și după modificare, copii ale datelor despre tranzacții, precum și alte informații. Toate acestea, în mod sintetic, pot fi enumerate astfel:
elemente de identificare a tranzacției;
elemente de identificare a operatorului/utilizatorului;
valoarea tranzacției;
imaginea unui câmp înaintea efectuării unei schimbări;
imaginea câmpului după efectuarea tranzacției;
tipul operației efectuate;
data operației efectuate;
data și momentul din zi când a avut loc tranzacția;
echipamentul pe care s-a efectuat operațiunea, etc.
Proba în auditare va servi la reconstituirea fișierelor distruse, dar și la verificarea corectitudinii operațiunilor de actualizare. Operațiunea se efectuează de experți contabili specializați în sisteme informatice.
Capitolul 5. PROIECTAREA APLICAȚIEI
5.1. Analiza cerințelor informaționale
5.1.1. Justificarea lucrării
Orice proiect de sistem informatic este precedat de un studiu de fezabilitate care să justifice necesitatea implementării unui sistem informatic și să cuantifice avantajele pe care le poate aduce activității firmei. În continuare va fi prezentată doar motivația care a condus la ideea realizării unui sistem informatic la nivelul societății S.C. RAZMISI S.R.L. fără a încerca să cuantificăm avantajele acestuia deoarece se va putea vedea ca solutia unui sistem informatic apare ca o necesitate datorită dezvoltării firmei și nu doar ca o modalitate de creștere a profitului.
Necesitatea realizării unui sistem informatic la nivelul societății RAZMISI S.R.L. a apărut datorită dezvoltării activității firmei prin creșterea volumului de vânzări efectuate prin cele trei magazine ale firmei dar și prin diversificarea și extinderea gamei de produse oferite la vânzare. Aceasta a condus la creșterea volumului de documente care trebuiesc întocmite precum și la creșterea duratei de timp în care se întocmesc aceste documente. Totodată a devenit mai dificilă organizarea evidenței mărfurilor aflate în stoc astfel încât să se poată cunoaște în orice moment cantitatea existentă din fiecare sortiment, în fiecare din cele trei magazine ale firmei pentru a se putea organiza o aprovizionare ritmică, ținând cont de faptul că spațiul destinat stocării mărfurilor nu este foarte mare, iar firma nu dispune încă de un depozit propriu cu rol de tampon în aprovizionarea cu mărfurile vândute.
În aceste condiții un sistem informatic integrat poate aduce avantaje prin reducerea duratei de întocmire a documentelor, asigurarea unei evidențe contabile informatizate, moderne, asigurarea unor informații în timp real asupra situației stocurilor de mărfuri existente în fiecare magazin al firmei, pe sortimente și chiar posibilitatea efectuării unor analize asupra volumului vânzărilor trecute pentru îmbunătățirea activității curente sau pentru previzionarea activității viitoare a firmei.
5.1.2. Identificarea proceselor informaționale
Activitatea desfășurată în interiorul firmei este una clasică, specifică firmelor care se ocupă cu comerțul intermediar și cu ridicata. Punctele de lucru sunt de fapt magazine și depozite de mărfuri pentru vânzare.
Activitățile desfășurate de personal constau în prezentarea marfurilor, servirea clienților, încasarea contravalorii mărfurilor, întocmirea documentelor aferente vânzării, evidența mărfurilor vândute, realizarea inventarului mărfurilor existente în stoc, recepția mărfurilor primite de la furnizori etc.
Din punct de vedere informațional procesele care se pot identifica în activitatea desfășurată în cadrul S.C. RAZMISI S.R.L. se pot împărți în două categorii : procese desfășurate în cadrul fiecărui punct de lucru și procese desfășurate la conducerii firmei.
Procesele informaționale care se desfășoară la nivelul punctelor de lucru sunt identice, astfel că aplicațiile vor fi dezvoltate la nivelul firmei și vor fi instalate în fiecare punct de lucru (acesta este un avantaj pentru orice extindere ulterioară a firmei). Aceste procese sunt :
vânzare mărfuri către clienți ; fiind vorba de un comerț intermediar și cu ridicata, practic nu există comenzi scrise, clientul, fie persoană juridica fie persoană fizică, își alege mărfurile dorite și achită contravaloarea mărfurilor cu un instrument de plată corespunzător : cash, filă cec sau ordin de plată. Pentru plata cu ordin de plată trebuie aprobarea administratorului firmei deoarece, în trecut, firma a avut clienți care au întârziat nejustificat de mult cu plata astfel că, în prezent, se aplică un sistem de selecție a clienților pentru care se acceptă achitarea mărfurilor cumpărate cu ordin de plată.
evidența mărfurilor vândute zilnic și realizarea inventarului săptamânal, pentru anumite categorii de mărfuri.
recepția mărfurilor de la furnizori și introducerea acestora în gestiune ;
semnalarea lichidării stocurilor la anumite mărfuri și necesitatea aprovizionării cu noi cantități din produsul respectiv ;
întocmirea de rapoarte pentru orice situație solicitată de administratorul firmei care asigură managementul.
La nivelul sediului firmei au loc următoarele procese informaționale :
înregistrarea activităților efectuate în contabilitate și întocmirea documentelor contabile ;
întocmirea statelor de plată și a documentelor necesare pentru bancă și pentru achitarea obligațiilor financiare aferente (CAS, CASS, șomaj, pensie suplimentară etc.) ;
emiterea de comenzi către furnizori și întocmirea documentelor de plată a facturilor pentru produsele achiziționate.
În continuare este prezentată diagrama fluxurilor de date, în reprezentare Yourdon & de Marco, pentru procesele desfășurate la nivelul firmei pentru activitatea de desfacere de mărfuri.
Fig. 25. Diagrama de flux a datelor pentru activitatea firmei
Din analiza acestei diagrame de flux se pot identifica procesele care se desfășoară la nivelul punctelor de lucru și procesele care se desfășoară la nivelul sediului firmei, și anume : prelucrare vânzări, pregătire documente pentru bancă și generare rapoarte vânzări se desfășoară la nivel de punct de lucru, iar procesele de stabilire a cantității de marfa de aprovizionat și generare rapoarte aprovizionare se desfășoara la nivelul sediului firmei.
Pe baza datelor preluate de la cele trei puncte de lucru se realizează înregistrarea datelor în contabilitate la nivelul sediului firmei. Procesul acesta este unic și, deoarece informatizarea contabilității presupune instrumente software autorizate pentru această activitate, nu se va insista pe acest proces, soluția propusă pentru rezolvarea problemei fiind de a achiziționa un program de firmă, autorizat, care să fie folosit separat de celelalte module ale sistemului preluându-se rapoartele furnizate de acesta pentru alte prelucrări. Ulterior se poate analiza oportunitatea realizării unui instrument software propriu pentru contabilitate sau realizarea unor interfețe pentru programul achiziționat astfel încât acesta să poată comunica direct cu celelalte aplicații ale sistemului.
Din diagrama de mai sus observăm că avem nevoie de o serie de surse de date, și anume:
un nomenclator de produse cu informații privind caracteristicile produselor existente în magazin (denumire, cod, preț de achiziție, preț de vânzare etc.) ;
evidența stocurilor existente la fiecare punct de lucru conținând informații privind cantitatea din fiecare produs existent în magazin la un moment dat ;
o listă cu furnizorii tradiționali ai firmei, conținând date specifice : poziția, produse furnizate și prețurile practicate ;
o evidență a vânzărilor efectuate ; conținând informații privind produsele vândute, clienții către care s-au făcut vânzările, sumele încasate cash, plățile prin filă de cec sau prin ordin de plată etc. ;
o evidență a comenzilor pentru aprovizionare cu mărfurile lipsă sau pentru care stocurile sunt în curs de epuizare.
Ca entități externe avem clienții firmei, furnizorii (pot fi furnizori tradiționali, ale căror date sunt înregistrate, sau furnizori noi, cu care nu s-a mai lucrat), banca și conducerea firmei.
Clienții și furnizorii reprezintă intrări de date pentru sistemul nostru deoarece, din punct de vedre informațional, se rețin informații despre ei în evidența vânzărilor sau a furnizorilor.
Banca și conducerea firmei reprezintă ieșiri de date pentru sistemul informațional deoarece banca impune completarea unor documente specifice, iar conducerea are nevoie de rapoarte de vânzare și de aprovizionare.
În afară de activitatea principală a firmei mai există un proces informațional legat de evidența personalului angajat și a drepturilor salariale ale acestora. Diagrama de flux a datelor pentru acest proces este prezentată mai jos.
Fig. 26. Diagrama de flux a datelor pentru evidența personalului
Observăm că avem trei procese informaționale : înregistrarea datelor privind pontajul lunar, calculul drepturilor lunare și întocmirea documentelor aferente acestei activități pentru conducere, bancă și alte instituții.
Colecții de date avem două, una cu informații privind datele generale ale angajaților și una cu informații privind drepturile și reținerile corespunzătoare pentru o lună dată.
Sursa de date primară pentru această activitate este reprezentată de către pontaj. Acesta este documentul care conține toate datele necesare pentru calcularea drepturilor salariale ale angajaților.
Ieșirile sistemului sunt reprezentate de documentele necesare pentru conducere, bancă și alte instituții (stat de plată, fluturași, recapitulații etc.).
Acestea sunt principalele procese informaționale care vor fi analizate în vedrea realizării unui sistem informatic deoarece am stabilit că partea de contabilitate informatizată va fi asigurată cu ajutorul unui program autorizat, realizat de altă firmă.
5.1.3. Modelarea conceptuală a datelor cu ajutorul DER
Modelarea conceptuală a datelor are rolul de a evidenția modul de organizare logică a datelor din sistem și legăturile existente între aceste date.
Una din metodele cele mai folosite pentru modelarea conceptuală a datelor este metoda diagramelor entitate-relație care identifică entitățile care participă la realizarea unui proces informațional, atributele care le descriu și legăturile funcționale care există între aceste entități în interiorul sistemului.
Modelul este realizat sub formă grafică, entitățile fiind reprezentate prin dreptunghiuri în care este trecut numele entității, legăturile prin arce, iar atributele prin elipse în care este trecut numele atributului.
Entitățile corespund colecțiilor de date care sunt stocate și manevrate în interiorul sistemului.
Pornind de la diagrama de flux a procesului de vânzare prezentată mai sus s-au identificat următoarele diagrame entitate-relație:
o diagramă pentru activitatea desfășurată la punctele de lucru și care folosește colecții de date locale, care vor fi integrate într-o colecție mare la nivelul firmei;
o diagramă la nivelul sediului firmei pentru activitatea de integrare a informațiilor de la toate punctele de lucru;
o diagramă pentru activitatea de personal.
În figurile următoare sunt prezentate două diagrame entitate-relație identificate pentru problema analizată.
Fig. 27. Diagramele entitate- relație ale activității firmei
Aceste diagrame sunt valabile atât la nivelul punctelor de lucru cât și la nivelul sediului firmei. Singura diferență apare din volumul de informații existente în colecțiile de date și din conținutul acestor informații care va fi mai redus la nivelul punctelor de lucru. Practic, la nivelul sediului firmei sistemul nu necesită module pentru introducerea datelor primare fiind necesare, în schimb, module pentru preluarea datelor de la punctele de lucru și integrarea lor în colecțiile globale de date.
Pentru drepturile personalului angajat avem următoarea diagramă.
Analizând relațiile dintre diagramele de mai sus observăm că nu avem decât relații de tipul unu-la-unu și unu-la-mulți. Acestea apar în mod natural și nu necesită o tratare suplimentară deoarece SGBD-urile moderne permit implementarea relației de tip unu-la-mulți.
Atributele care caracterizează entitățile identificate mai sus sunt prezentate în continuare prin enumerare, pentru a evita construcțiile grafice prea aglomerate și greu de interpretat.
PRODUSE STOCURI
Cod_Produs Cod_Produs
Cod_Lot Cod_Lot
Denumire_Produs Cantitate
Unitate_Masură
Preț_Unitar
VÂNZARE CLIENT
Data Denumire_Client
Cod_punct_de_lucru Tip_Client
Denumire_Client Adresa_sediu
Cod_Produs Cod_Fiscal
Cod_Lot Cont-Bancar
Cantitate Banca
Pret_Unitar Nume_Delegat
Pret_Total Serie_și_nr_CI_Delegat
TVA Modalitate_plată
Modalitate_plata
FURNIZOR COMENZI_ÎN_CURS
Denumire Denumire_furnizor
Adresă Cod_Produs
Cod_Fiscal Cantitate
Cont_bancar Preț_unitar
Banca Valoare_comandă
Cod_Lot
PERSONAL
Nume
Marca
Data_nasterii
Data_angajarii
Adresa
Salariu_tarifar
Spor_vechime_procent
DREPTURI LUNARE
Marca
Salariu_tarifar
Ore_lucrate
Ore_Concediu_Medical
Ore_Concediu_Odihnă
Ore_Suplimentare
Valoare_spor_vechime
Salariu_ore_lucrate
Salariu_Concediu_odihna
Salariu_concediu_medical
Prime
Venit_brut
CAS
CASS
Somaj
Pensie suplimentara
Deducere_personală
Deducere_suplimentară
Venit_impozabil
Impozit
Alte_retineri
Venit_net
Avans
Rest_de_plată
5.2. Proiectarea de ansamblu a sistemului informatic
Societatea comercială S.C. RAZMISI S.R.L. are trei puncte de lucru prin care desface o gamă diversificată de produse, cum sunt : materiale de construcții, piese și accesorii pentru autovehicule, tutun, băuturi și produse alimentare (uleiuri și grăsimi alimentare, zahăr și produse zaharoase, carne și mezeluri, fructe și legume etc.).
Prima problemă care apare este cea a interconectării celor trei puncte de lucru pentru a putea avea o vedere de ansamblu asupra situației din firmă în orice moment. Sistemul informatic va trebui să cuprindă o serie de aplicații care vor fi instalate în fiecare din cele trei puncte de lucru precum și o serie de aplicații, cum este cea pentru contabilitate, care va funcționa doar la sediul firmei, pentru a asigura o evidență contabilă centralizata și coerentă.
Sediul firmei este amplasat în același loc cu punctul de lucru din Măgurele astfel ca legătura trebuie realizată doar cu punctele de lucru de la Boldești și Vălenii de Munte. Local se va putea realiza o rețea de mici dimensiuni între un calculator din sediu și calculatorul instalat în magazin.
Pentru comunicarea cu cele două puncte de lucru (și posibil cu altele noi) cea mai ieftină soluție utilizabilă este de a transfera datele prin Internet la cerere sau la anumite ore pentru a actualiza informațiile existente în baza de date existentă la sediul firmei. Această soluție poate satisface necesitățile actuale și viitoare ale firmei, specificul activității desfăsurate neimpunând o legătură permanentă între cele trei puncte.
Deoarece magazinele firmei deservesc zone alăturate, informațiile privind existența unui produs într-un anumit magazin se pot transmite în timp real prin telefon de către operatorul de la magazin, prin consultarea bazei de date locale.
De asemenea, pentru a putea controla activitatea în mod corespunzător, urmărirea stocurilor și emiterea comenzilor pentru aprovizionarea cu noi cantități de produse se va realiza la nivelul sediului firmei. La nivelul punctelor de lucru se vor recepționa cantitățile noi de produse, vor fi introduse în magazie și se va realiza actualizarea stocurilor existente la nivel local.
Structura sistemului la nivel local este prezentată în figura următoare.
Fig. 29. Structura sistemului la nivel local
Observăm existența celor trei colecții de date : VÂNZĂRI, PRODUSE și STOCURI, precum și a trei module executabile : înregistrare vânzări, actualizare stocuri și transmitere date.
Modulul înregistrare vânzări are rolul de a înregistra datele clienților, articolele cumpărate, modul de plată, de a elabora factura și chitanța corespunzătoare vânzării, de a actualiza valorile stocurilor de produse din fișierul corespunzator și de a asigura elaborarea documentelor zilnice pentru bancă.
Modulul actualizare stocuri este folosit pentru înregistrarea intrărilor de produse în magazin ca urmare a aprovizionării cu noi cantități.
Modulul de transmitere date are rolul de a realiza pregătirea datelor pentru transmitere și de a realiza transmisia datelor prin Internet către sediul firmei.
La sediul firmei, sistemul informatic propus va avea structura de mai jos.
Fig. 30. Structura sistemului la nivelul sediului firmei
Observăm că avem doar colecțiile de date globale privind vânzările și stocurile. Nomenclatoarele de produse sunt folosite în principal, la punctele de lucru. În funcție de necesități, câte o copie a fiecărui nomenclator poate fi ținută și la sediul firmei pentru a permite o informare rapidă asupra gamei de produse desfăcute de firmă și asupra repartizării produselor la punctele de lucru.
Pentru calculul drepturilor angajaților și elaborarea documentelor aferente vom avea următoarea structură.
Fig. 31. Structura sistemului pentru drepturile personalului
În aces caz avem două colecții de date : PERSONAL și DREPTURI LUNARE și trei module executabile : pentru introducerea datelor de pontaj lunare, pentru calculul drepturilor lunare și pentru întocmirea documentelor necesare.
5.3. Proiectarea formularelor de intrare și a rapoartelor de ieșire
Formularele de intrare reprezintă instrumentul prin care se introduc date într-un sistem informatic. De modul cum sunt realizate și prelucrate depinde productivitatea aplicației și comoditatea în utilizare a acesteia.
Pentru a fi cât mai ușor de folosit, un formular electronic pentru introducerea trebuie să respecte, pe cât posibil, modul de dispunere a câmpurilor de date din formularele analoage tipărite. Dacă nu există un formulat tipizat pentru o anumită operațiune de introducere de date atunci modul de organizare a formularului depinde de experiența și cunoștințele analistului de sistem.
Formularele de intrare la nivelul aplicațiilor de la punctele de lucru sunt următoarele:
– formular pentru introducerea datelor privind vânzarea către un singur client ;
– formular pentru introducerea datelor privind produsele reaprovizionate.
Formularul pentru vânzări va conține informații privind produsele cumpărate de client prin denumirea produselor, cantitatea cumpărată din fiecare produs și informații privind clientul. Dacă este vorba de persoană fizică atunci plata se face automat cash așa că nu se mai introduc restul datelor. În cazul persoanelor juridice se înregistrează restul datelor dacă este vorba de un client nou. Pentru un client vechi, programul trebuie să permită căutarea acestuia într-o listă și completarea automată a câmpurilor corespunzătoare, mai puțin numele delegatului și seria actului de identitate.
În cazul formularului pentru introducerea datelor privind produsele reaprovizionate, conținutul acestuia va fi format doar din datele necesare actualizării stocurilor respective.
La sediul firmei, aplicația pentru calculul salariilor are nevoie de un formular care să permită introducerea datelor de pontaj lunare. Acesta va prelua automat din fișierul PERSONAL datele unui angajat, iar operatorul va introduce numărul de ore lucrate sau din altă categorie.
Rapoartele reprezintă modalitatea prin care se extrag informații din bazele de date ale sistemului. Ele pot fi afișate pe ecran sau pot fi listate la imprimantă, în funcție de necesități. Ca principiu de lucru, orice raport, chiar dacă trebuie listat va fi afișat întâi pe ecran și va fi tipărit după ce este verificat.
Rapoartele care trebuiesc întocmite la punctul de lucru sunt următoarele :
factură ;
chitanță de vânzare ;
bon de casă ;
lista stocurilor ;
raport de vânzare pentru ziua curentă (cu toate produsele vândute în ziua respectivă, cantități și sumele încasate sau doar suma încasată cash, plus sumele corespunzatoare vânzărilor achitate cu filă cec sau prin ordin de plată ;
La sediul firmei sunt necesare rapoarte diverse, în funcție de situație. Deoarece nu toate situațiile posibile pot fi prevăzute vor fi considerate doar cazurile următoare :
situația cumulată a vânzărilor dintr-o zi la toate punctele de lucru ;
situația vânzărilor pe o perioadă mai îndelungată pentru anumite produse ;
situația stocurilor pentru un anumit produs sau pentru mai multe produse, la o anumită dată ;
Pentru aplicația de calcul a salariilor vom avea ca rapoarte ce trebuiesc tipărite următoarele :
– stat de plată ;
– fluturași ;
– recapitulații pentru sumele datorate ;
– fișe fiscale .
Suplimentar pot apare cereri ocazionale de date privind informațiile legate de drepturile lunare ale angajaților. Acestea vor fi rezolvate prin interogarea directă a bazei de date cu ajutorul instrumentelor de lucru oferite de SGBD-ul folosit pentru dezvoltarea aplicațiilor.
5.4. Proiectarea bazelor de date
Bazele de date utilizate în cadrul sistemului informatic proiectat sunt de tip relațional. Proiectarea bazelor de date presupune proiectarea colecțiilor de date la nivel logic și verificarea normalității relațiilor.
Structura tabelelor de date este prezentată mai jos.
PRODUSE
Cod_Prod N 4
Cod_Lot N 4
Den_Prod C 30
Unit_Mas C 2
Preț_Unitar N 10
STOCURI
Cod_Prod N 4
Cod_Lot N 4
Cantitate N 10 2
VÂNZARE
Data D
Cod_pct_lucru N 2
Den_Client C 30
Cod_Prod N 4
Cod_Lot N 4
Cantitate N 10 2
Pret_Unitar N 10
Pret_Total N 15
TVA N 10
Modalitate_plata C 1
CLIENT
Den_Client C 30
Tip_Client C 1
Adresa C 20
Cod_Fiscal C 10
Cont-Bancar C 20
Banca C 20
Nume_Delegat C 20
Serie_nr_CI C 10
Modalitate_plată C 1
FURNIZOR
Denumire C 30
Adresă C 20
Cod_Fiscal C 10
Cont_bancar C 20
Banca C 20
COMENZI
Den_furnizor C 30
Cod_Prod N 4
Cantitate N 15
Preț_unitar N 10
Val_comandă N 15
Cod_Lot N 4
PERSONAL
Nume C 30
Marca N 4
Data_nasterii D
Data_angajarii D
Adresa C 20
Salariu_tarifar N 10
Spor_vechime_pr N 2
DREPTLUN
Marca N 4
Salariu_tarifar N 10
Ore_lucrate N 3
Ore_Concediu_Medical N 3
Ore_Concediu_Odihnă N 3
Ore_Suplimentare N 3
Valoare_spor_vechime N 10
Salariu_ore_lucrate N 10
Salariu_Concediu_odihna N 10
Salariu_concediu_medical N 10
Valoare_ore_suplim N 10
Prime N 10
Venit_brut N 10
CAS N 8
CASS N 8
Somaj N 8
Pensie suplimentara N 8
Deducere_personală N 10
Deducere_suplimentară N 10
Venit_impozabil N 10
Impozit N 10
Alte_retineri N 10
Venit_net N 10
Avans N 10
Rest_de_plată N 10
În relațiile de mai sus am marcat atributele cheie prin scriere îngroșat și cu aldine (înclinat). Relațiile au toate atributele atomice astfel că se găsesc în forma normală unu (FN1).
Deoarece nu avem chei compuse pentru nici o relație nu avem nici dependențe parțiale. De asemenea, nu avem în nici o relație dependențe tranzitive astfel că putem considera că relațiile se găsesc în forma normală 3 (FN3).
Analiza normalității relațiilor s-a făcut ținând cont de prelucrările care se vor aplica ulterior acestor relații.
Legăturile între relații, conform diagramelor entitate-relație se realizează prin intermediul cheilor după cum se poate observa și mai sus.
5.5. Proiectarea aplicațiilor
Aplicațiile care trebuiesc realizate reprezintă modulele precizate în cadrul structurii de ansamblu a sistemului informatic proiectat. Aceste module sunt:
modulul pentru înregistrare vânzări;
modulul pentru actualizare stocuri produse;
modulul pentru transmitere date;
modulul pentru recepționare date;
modulul pentru actualizare date transmise;
modulul pentru extragere rapoarte;
modulul pentru introducere date pontaj;
modulul pentru calculul drepturilor lunare;
modulul pentru întocmirea documentelor de plată a drepturilor angajaților.
În continuare vor fi precizate soluțiile posibile pentru realizarea acestor module și algoritmii corespunzători prelucrărilor efectuate, acolo unde este posibil acest lucru.
Modulul pentru înregistrare vânzări
Are rolul de a asigura preluarea datelor corespunzătoare unei vânzări către un anumit client, înregistrarea acestora în fișierul VANZARI, elaborarea și tipărirea documentelor aferente vânzării (factură și chitanță), actualizarea stocurilor existente prin reducerea cu cantitățile vândute, totalizarea produselor vândute în ziua curentă, calculul sumelor încasate cash pentru verificare cu casa.
Pentru aceasta are nevoie de o serie de informații care se găsesc în fișierele PRODUSE, STOCURI și CLIENȚI.
Algoritmul după care se desfășoară o operație de vânzare este următorul:
selectează produs solicitat din lista de produse afișată;
afișează cantitatea existentă în stoc la momentul respectiv prin citire din fișierul STOCURI;
introdu cantitatea solicitată de client (condiția este ca aceasta sa fie mai mare sau cel mult egală cu cantitatea de produs existent în stoc);
dacă clientul nu mai dorește alte produse treci la pasul următor, altfel mergi la pasul 1;
generează lista produselor solicitate de client, împreună cu totalul de plată;
dacă clientul confirmă lista treci la pasul 8, altfel treci la pasul 7
elimina din listă produsele indicate de client
introdu denumirea clientului
dacă este persoană juridică și este înregistrat în baza de date atunci afișează datele acestuia, altfel introdu datele clientului in baza de date;
generează și tipărește factura și chitanța
actualizează stocurile de produse din fișierul STOCURI prin micșorarea acestora cu cantitățile vândute.
Pentru restul acțiunilor pe care trebuie să le realizeze modulul avem algoritmul următor.
salt la prima înregistrare din fișierul VÂNZĂRI;
Cât timp nu s-a atins sfârșitul fișierului VÂNZĂRI
Dacă data_curentă=VÂNZĂRI.Data atunci adaugă înregistrarea curentă în list vânzărilor
Dacă modalitate de plata=cash atunci
S=S+Pret_Total
Salt la următoarea înregistrare
salvează lista vânzărilor într-un fișier;
tipărește lista vânzărilor și suma totală încasată.
Modulul pentru actualizare stocuri
Algoritmul pentru actualizarea stocurilor este următorul:
selectează produsul adăugat din listă;
introdu cantitatea de produs nouă;
STOCURI.cantitate=STOCURI.Cantitate+Cantitate_nouă
Dacă nu mai sunt produse atunci terminare, altfel salt la pasul 1.
3. Modulul pentru transmitere date
Transmiterea datelor se va face sub formă de fișier, prin Internet. Pentru aceasta se va folosi un cont de E-mail ca tampon pentru a evita operațiunea de FTP, mai complicată pentru un utilizator.
Datele vor fi transmise ca atașament la un mesaj standard și vor fi descărcate la sediul firmei de către alt utilizator și apoi integrate în baza de date globală.
Soluția propusă nu este cea mai elegantă dar este cea mai economică și ușor de implementat.
Pentru conturi de E-mail se poate utiliza un server de free E-mail gen Yahoo sau Google, care oferă spațiu de găzduire E-mail de 100 Mb, mai mult decât suficient pentru necesitățile aplicației noastre.
În viitor se va încerca realizarea unei aplicații care să realizeze conexiunea și transmiterea mesajului în mod automat dar problemele ridicate de acest program depăsesc cadrul acestei lucrări.
4. Modulul pentru recepționare date
La fel ca în cazul transmiterii de date, recepționarea datelor se va face prin descărcarea fișierelor atașate la un mesaj E-mail standard. Posibilitatea realizării unui program care să realizeze aceste operațiuni în mod automat depășește cadrul acestei lucrări.
5. Modulul actualizare date
Acest modul are sarcina de a prelua fișierele cu datele zilnice și de a adăuga informațiile conținute de ele în fișierele de date globale, menținute la sediul firmei. Algoritmul corespunzător este următorul:
deschide fișierul zilnic VÂNZĂRI;
deschide fișierul global VÂNZĂRI;
Cât timp nu s-a atins sfârșitul fișierului temporar VÂNZĂRI
– citește înregistrare din fișierul temporar VÂNZĂRI
– scrie înregistrare in fișierul global VÂNZĂRI
– salt la înregistrarea următoare;
4. închide fișierele VÂNZĂRI, atât cel global cât și cel temporar
5. deschide fișierul zilnic STOCURI
6. deschide fișierul global STOCURI
7. Cât timp nu s-a atins sfârșitul fisierului temporar STOCURI
– citește înregistrare din fișierul temporar STOCURI
– adaugă înregistrare in fișierul global STOCURI
– salt la înregistrarea următoare din fișierul temporar
8. închide fișierele STOCURI
9. șterge fișierele temporare
6. Modulul extragere rapoarte
Rapoartele se pot genera prin program, dar cele mai multe SGBD-uri au instrumente software specializate pentru generarea rapoartelor, astfel că se vor folosi facilitățile oferite de SGBD-ul utilizat pentru dezvoltarea aplicației.
7. Modulul introducere date pontaj
Introducerea datelor de pontaj lunar necesită un formular special și un algoritm de prelucrare relativ simplu:
deschide fișierul DATELUNARE
deschide fișierul PERSONAL
Cât timp nu s-a atins sfârșitul fișierului PERSONAL
citește nume angajat într-o variabilă
citește marca într-o variabilă
identifică înregistrarea cu aceeași valoare pentru câmpul marca în fișierul DATELUNARE
afișează nume în formular
introducere date pontaj în formular pentru angajatul identificat prin nume
scrie datele de pontaj în fișierul DATELUNARE
salt la o nouă înregistrare în fișierul PERSONAL
4. închide fișierele
8. Modulul pentru calculul drepturilor lunare
Drepturile salariale lunare ale angajaților se calculează relativ simplu, aplicând o serie de relații matematice simple. Din această cauză nu vom insista asupra algoritmului prezentând doar o variantă simplă pentru acesta:
deschide fișierul DATELUNARE
Cât timp nu s-a atins sfârșitul fișierului DATELUNARE
calculează câmpurile necesare;
salt la următoarea înregistrare
închide fișierul DATELUNARE
9. Modulul pentru întocmirea documentelor de plată
Documentele care trebuiesc întocmite pentru plata drepturilor salariale lunare sunt în număr destul de ridicat dar au o structură relativ simplă, mai ales că numărul de angajați al firmei este destul de redus.
Din această cauză se va căuta să se folosească instrumentele oferite de SGBD-ul utilizat pentru realizarea de rapoarte (generatoare de rapoarte).
5.6. Posibilități de implementare
Pentru implementarea sistemului proiectat se poate folosi unul din SGBD-urile FoxPro sau MS-Access.
Acestea sunt SGBD-uri relaționale, FoxPro având un limbaj propriu pentru dezvoltarea de aplicații în timp ce MS-Access folosește o versiune de Visual Basic.
Deoarece sistemul poate suferi modificări și / sau extinderi în timp se preferă utilizarea SGBD-ului MS-Access deoarece acesta oferă o serie de instrumente auxiliare pentru rezolvarea interactivă a problemelor (instrumente tip wizard, generatoare de interogări – Querry, generatoare de formulare și rapoarte etc.).
Interfața SGBD-ului Access este prezentată în figura următoare în care se pot observa și tabelele de date ale sistemului.
Fig. 32. Stuctura bazei de date pentru activitatea comercială
Baza de date pentru evidența personalului și a drepturilor lunare ale acestuia este prezentată în figura de mai jos.
Fig. 33. Structura bazei de date pentru evidența personalului firmei
Introducerea datelor se realizează cu ajutorul formularelor, din care sunt prezentate mai jos doar cel de generare a unei comenzi și cel pentru introducerea unui articol nou în cadrul comenzii curente.
Fig. 34. Formular pentru introducere comandă (formată din mai multe produse)
Fig. 35. Formular pentru introducerea unui produs într-o comandă
Restul operațiilor de intrare de date se realizează asemănător, prin intermediul formularelor.
Extragerea informațiilor din bazele de date ale sistemului se va realiza cu ajutorul rapoartelor.
În figura alăturată este prezentat un exemplu de raport care conține statul de plată a avansului.
Fig. 36. Exemplu de raport
Capitolul 6. CONCLUZII
Prezenta lucrare are ca scop elaborarea specificațiilor de proiectare pentru un sistem informatic ce ar trebui să fie implementat la societatea comercială RAZMISI S.R.L. Măgurele.
Deoarece fiecare firmă are propria ei structură si propriile metode de lucru este necesară o analiză si o proiectare particularizate pentru fiecare caz în parte. Folosind principiile de analiză și proiectare a sistemeleor informatice însușite în anii de studiu am încercat să le aplic pe un caz real.
În urma analizei efectuate asupra sistemului informațional al firmei studiate se pot desprinde următoarele concluzii:
sociteatea S.C.RAZMISI S.R.L. Măgurele are trei puncte de lucru situate în trei localități diferite ;
activitatea desfășurată la cele trei puncte de lucru este asemănătoare (comerț cu produse identice) ;
distanța între cele trei puncte de lucru este de max. 25 de km ;
informațiile necesare în activitatea firmei se transmit telefonic atunci când este necesar și prin centralizarea documentelor și rapoartelor la sediul firmei din Măgurele (care este situat în același loc cu punctul de lucru din Măgurele) ;
urmărirea stocurilor se realizează doar prin aprecierea vizuală a vânzătorului care are grijă să semnaleze necesitatea reaprovizionării cu anumite produse ;
pentru stabilirea necesarului de aprovizionare la diverse produse se realizează analiza vânzărilor pe perioade similare din anii anteriori prin parcurgerea evidențelor existente în arhiva firmei. Aceasta este o activitate greoaie datorita numărului mare de produse vândute și care necesită mult timp.
evidența personalului se realizează manual pe formulare de tip vechi apărând posibilitatea unor erori umane la calculul drepturilor și al reținerilor, erori semnalate de-a lungul timpului de anagajați.
Luând în considerare cele prezentate mai sus am încercat să ofer o soluție de rezolvare a acestor probleme în vederea îmbunătățirii activității firmei.
Ținând cont de specificul firmei și de dispunerea geografică a punctelor de lucru, precum și de distanțele dintre ele, am propus o soluție de sistem informatic compus din trei componente : o aplicație folosită la nivelul fiecărui punct de lucru, o aplicație integratoare la nivelul sediului firmei și o aplicație pentru evidența personalului angajat al firmei.
Pentru evidențele contabile am propus, în prima etapă, folosirea unui program realizat de o firma de specialitate deoarece acesta trebuie autorizat de către un organism abilitat.
Pentru transmiterea datelor între cele trei puncte de lucru și sediul firmei am propus ca soluție folosirea comunicării prin Internet sub formă de fișier atașat unui mesaj de E-mail. Aceasta deoarece realizarea unor programe de transmitere și recepționare automată a mesajelor depășește cerințele acestei lucrări.
Soluția propusă poate fi implementată cu ajutorul unor instrumente diverse, cum ar fi SGBD-urile FoxPro, MS-Access sau MySQL. În lucrare am prezentat câteva aspecte privind implementarea cu ajutorul SGBD-ului MS-Access.
BIBLIOGRAFIE
Andone I., Mockler R., Dologite D., Țugui Al., Dezvoltarea sistemelor inteligente în economie, Editura Economică, București, 2001
Dușmănescu Dorel, Baze de Date, Suport de curs, 2003
Dușmănescu Dorel, Proiectarea Sistemelor Informatice, Suport de curs pentru ID, 2004
Oprea Dumitru, Analiza și proiectarea sistemelor informaționale economice, Editura Polirom, Iași, 1999
Popovici Dorin Mircea, Popovici Ioan M., Rican Jean G., Proiectare și implementare software, Editura Teora, București, 1998
Roșca i., ș.a., Proiectarea sistemelor informatice financiar-contabile, Editura Didactică și Pedagogică, București, 1993
Sabău Gh., Avram V., Sisteme informatice pentru management, Editura OscarPrint, București, 1998
Zaharie D., Roșca I., Proiectarea obiectuală a sistemelor informatice, Editura DualTech, București, 2002
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Elaborarea Specificatiilor de Proiectare ale Unui Sistem Informatic (ID: 149090)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.