Baze de Date Multimedia Orientata pe Aplicatie Imobiliara
Capitolul I
Introducere
Lucrarea își propune ca obiectiv dezvoltarea unei aplicații software pentru agențiile imobiliare, având la bază un sistem de baze de date multimedia. Aplicația va trebui să soluționeze problemele cu care se confruntă cel mai des o agenție imobiliară, probleme ce sunt consumatoare de timp și care pot fi automatizate.
În orașele mari, piața imobiliară este extrem de bine reprezentată, deși este una tânără, începuturile sale datând din 1994-1995. Avântul deosebit pe care l-au luat afacerile imobiliare are motive bine întemeiate. Și anume birocrația și formalitățile care trebuie îndeplinite pentru orice tranzacție imobiliară. Se solicită: cadastru, intabulare, și extract de carte funciară, pentru fiecare dintre acestea fiind necesare o serie întreagă de cereri, declarații, timbre, chitanțe de plată a unor taxe etc., fără a mai pune la socoteală cozile interminabile. Toate aceste formalități consumă foarte mult timp, mai ales pentru pentru cineva care nu este obișnuit cu tot acest “hățiș” birocratic. Astfel, a apărut necesitatea populației de a apela, pentru obținerea uneia, mai multora sau tuturor acestor acte, la intermediari.
Acești intermediari sunt reprezentați de agențiile imobiliare.
În prezent pe piață se regăsesc două caregorii principale de operatori:
firme de renume, cunoscute( un număr relativ scăzut) – reprezentănd fie sucursale ale unor companii străine, fie locale – cu cifre de afaceri anuale de sute de mii de dolari, care acoperă un segment semnificativ de clienți( în special din mediul de afaceri – companii multinaționale);
firme / agenții de dimensiuni medii și mici( un număr extrem de mare), care își dispută cota de piată ramasă și între care există o concurență foarte strînsă, lucru care pentru firma “Stil Management” reprezintă este un plus( vânzarea unui produs software într-un mediu concurențial generat de clienți).
Aceste firme luptă pentru o cotă cât mai bună în cadrul segmentului de piață reprezentat de firmele mici și mijlocii și de persoanele fizice. Această piașă are o evolușie oscilantă, în funcție de zone, iar previziunle pentru viitor arată o tendință ascendentă a cererii, mai ales în contextul dezvoltării lanțurilor de supermarketuri, mall-uri și hzpermarketuri, care atrag după sine o frenezie deosebită a pieței imobiliară.
O agenție imobiliară nou-înființată nu are posibilitatea de a concura cu marile forțe în domeniu, pe proiecte de mare anvergură. De aceea, competitorii vor fi firmele mici, vizând segmentul de clienți descris mai sus.
Pentru a avea succes intr- o afacere pe această piață, trebuie luate în considerare aspecte legate de diversificarea ofertei față de concurență – tocmai de aceea firmele mici au început să ofere produse integrate( de la tranzacția imobiliară propiu-zisă până la asistența necesară la perfectarea tuturor documentelor aferente unei tranzacții). Cu cât o firmă de dimensiune mică este capabilă să ofere asistență în toate etapele derulării unei tranzacții ( Administrație financiară, Cadastru, Notariat etc.), cu atât șansele acesteia de a câșiga teren în fața concurenței cresc.
Majoritatea acestor agenții nu au aplicații software care sa îi ajute în activitatea pe care o prestează. De cele mai multe ori acestea apelează la o serie de aplicații de gen office( Microsoft Word, Microsoft Excel, Microsoft Access, Microsoft PowerPoint etc.), aplicații care le îngreunează activitatea și care nu evită eroarea umană.
Aplicația exemplu a fost concepută ca un suport pentru intermedierea tranzacțiilor cu locuințe.
Este implementată gestiunea cererilor și ofertelor de închirire / cumpărare, respectiv închiriere / vânzare de locuințe, precum și gestiunea datelor despre clienții societății.
Aplicația permite regăsirea rapidă a cererilor și ofertelor compatibile. Caracteristicile locuințelor după care se face compatibilizarea sunt alese de utilizator, în cazul regăsirii ofertelorcompatibile cu o anumită cerere, sau sunt presetate, în cazul regăsirii cererilor compatibile cu o anumită ofertă.
O facilitate importantă oferită utilizatorului este generarea automată a adocumentelor specifice activității de intermediere imobiliară: contracte de vânzare / cumpărare, contracte de închiriere, contracte de închiriere contracte de vizionare, antecontracte.
Aplicația oferă posibilitatea obținerii unor documente de sinteză cu privire la activitatea de intermediere imobiliară generate sub forma unor rapoarte și grafice ce prezintă influențe anumitor factori asupra eficiențeiactivității de intermediere imobiliară.
Datele despre clienții care solicită sau oferă o locuință spre tranzacționare sunt utile pentru întocmirea actelor care se încheie în urma tranzacțiilor, precum și pentru diferite documente de sinteză privind activitatea agenției imobiliare. Dacă provin de la potențialii cumpărători, datele cuprind caracteristicile pe careaceștia doresc să le aibă proprietățile pe care le vor cumpăra sau închiria: amplasare, compunere, finisaje, utilități. Dacă provin de la persoane care oferă proprietăți spre vânzare sau închiriere datele descriu amănunțit aceste proprietăți din mai mzulte puncte de vedere: date de identificare, date privind compunera proprietății, date privind utilitățile disponibile și date privind finisajele existente. Datele necesare întocmirii actelor ce rezultă în urma încheierii contractelor sunt furnizate de clienții care constituie părți civile în aceste acte.
În urma compatibilizării cererilor cu ofertele ( găsirea cererilor compatibile cu o anumită ofertă ) se întocmește o fișă de vizionare care cuprinde date despre ofertă și toate cererile compatibile. Această fișă este utilizată pentru urmărirea clienților care oferă o locuință în scopul evitării situației în car econtrctul de vânzare / cumpărare se încheie fără a plăti comosionul cuvenit agenției imobiliare.
Dacă un solicitant acceptă să cumpere sau să închirieze o locuință de la un ofertant, se încheie un antecontract care cuprinde obligațiile părților și data la care se încheie contractul de vânzare / cumpărare, respectiv contractul de închiriere. Această etapă nu este obligatorie.
Încheierea contractului de vânzare / cumpărare,respectiv a contractului de închiriere generează un raport care cuprinde datele de identificare al părților, obligațiile și drepturile acestora.pe baza datelor din contractele încheiate prin intermediul agenției imobiliare se întocmesc situații de sinteză constituite din grafice și rapoarte care arată influența a difeiți factoriasupra numărului și valorii tranzacțiilor încheiate.
Având în vedere toate acestea se va dezvolta o aplicație software care va veni în sprjinul acestor agenții imobiliare și care va ajuta în activitatea de intermediere a apartamentelor. Aceasta va permite
introducerea ofertelor și cererilor de apartamente ( oferte de vânzare / inchiriere, respectiv cereri de cumpărare / închiriere)
stabilirea comisioanelor pentru fiecare tip de client și pentru fiecare tip de activitate
obțirea ușoară de raportări privind cererile, respectiv ofertele, situația vânzărilor și a veniturilor din comisioane etc.( toate aceste raportări fiind în funcție de diferite criterii : zonă, tip de apartament, perioadă etc.)
grafice având la bază rezultatele din raportări
gestiunea documentelor ce intervin în activitatea de intermediere ( de exemplu : contract de vizionare, precontract de agenție, contract de vânzare – cumpărare în cazul în care activitatea de intermediere se încheie cu succes )
gestiunea serviciilor pe care agenția imobiliară le prestează pentru un anumit client( de exemplu : cadastru, intabulare, extras de carte funciară )
totodată aplicația va permite stocarea de date multimedia( poze și schițe ale apartamentelor), necesară în activitatea de satisfacere a unei cereri. Se va urmări prin aceasta reducerea timpului pierdut de un agent imobiliar pentru vizionarea apartamentelor ce sunt supuse intermedierii.
În capitolul II sunt prezentate particularități ale afacerilor imobiliare, precum și aspecte legislative privind cadrul în care o agenție imobiliară( și implicit agenții imobiliari ) își poate desfășura activitatea.
Capitolul III descrie concepte, procedee de realizare a documentelor multimedia, particularități ale datelor multimedia, resurse necesare aplicațiilor multimedia, metode de inserare și vizualizare a datelor de tip multimedia și nu în ultimul rând necesitatea datelor de tip multimedia.
În capitolul IV este realizată proiectarea aplicației și a bazei de date multimedia. Totodată, proiectarea este însoțită de o serie de de concepte folosite de metodologia utilizată, și anume SSADM( Structured System Analysis And Design Methodology).
Capitolul V descrie aplicația în sine și mijloacele folosite( din punct de vedere al limbajului de programare și a sistemului de baze de date).
Capitolul VI descrie caracteristici de calitate software pe care orice aplicație, inclusiv aplicația care stă la baza acestei lucrări, trebuie să le îndeplinească.
Aplicația va avea la bază uun sistem de baze de date multimedia( sisteml folosit fiind ORACLE), interfața aplicației fiind dezvoltată în Visul Basic .Net 2003.
Cap II
Paticularitatile afacerilor imobiliare
2.1 Caracteristici generale
În România există un cadru legislativ coerent privind activitatea agențiilor imobiliare. Aceste agenții își desfășoară activitatea în conformitate cu “Ordonanța nr.3 din 21 ianuarie 2000 privind organizarea activității agențiilor imobiliare”, publicată în Monitorul Oficial al României nr. 26 din 25 ianuarie 2000.
Astfel, ativitatea profesională de intermediere a actelor juridice care au ca obiect bunuri imobile, precum și cea de administrare a acestora se desfășoară de persoanele fizice și juridice care au calitatea de agent imobiliar. Dobândirea calității de agent imobiliar se face pe baza unui eaxamen, ale cărui reguli de desfășurare sunt prevăzute în statutul ”Uniunii Naționale a Agenților Imobiliari”( UNAI), aceasta fiind o organizație profesională, independentă, autonomă, apolitică și neguvernamentală, reprezentativă în domeniu la nivel național, având caracter de corp profesional, reprezintă Autoritatea Profesională de profil, având atributele și vocația unei instituții de utilitate publică. Organizarea si funcționarea UNAI se face pe baza autoguvernării și autonomiei filialelor sale, sub coordonarea Comitetului de Conducere al uniunii.
Agentul imobiliar, societate comercială, trebuie să îndeplinească urmatoarele conditii:
să aibă ca principal obiect de activitate intermedierile imobiliare;
cel puțin unul dintre administratori sa aibă calitatea de agent imobiliar.
Agenții imobiliari primesc pentru activitatea depusă o remunerație stabilită prin contractul încheiat cu clienții. Agentul imobiliar are dreptul la primirea remunerației în cazul în care se realizează acordul de voință al parților, exprimat potrivit legii, cu privire la încheierea contractului intermediat de acesta. Cu toate acestea, agentul imobiliar este îndreptatit la acoperirea cheltuielilor efectuate în vederea îndeplinirii obligațiilor pe care și le-a asumat față de client, în situația în care acesta din urmă încheie contractul prin intermediul altei persoane. În desfășurarea activității lor agenții imobiliari răspund disciplinar, administrativ, civil sau penal, dupa caz. Titularii drepturilor asupra imobilului au obligația de a prevedea în contractul de intermediere eventualele vicii ascunse ale imobilului, cunoscute de aceștia. Agenții imobiliari răspund solidar cu aceștia, dacă nu au comunicat persoanei interesate viciile ascunse ale imobilului, menționate în contractul de intermediere. În situația în care actul se încheie ca urmare a intermedierii realizate de un agent imobiliar, situație confirmată si declarată de parți, agentul imobiliar, la cererea expresa a notarului public care autentifica actul, va depune o copie de pe convenția încheiată de parți cu agentul imobiliar sau între părți prin intermedde concepte folosite de metodologia utilizată, și anume SSADM( Structured System Analysis And Design Methodology).
Capitolul V descrie aplicația în sine și mijloacele folosite( din punct de vedere al limbajului de programare și a sistemului de baze de date).
Capitolul VI descrie caracteristici de calitate software pe care orice aplicație, inclusiv aplicația care stă la baza acestei lucrări, trebuie să le îndeplinească.
Aplicația va avea la bază uun sistem de baze de date multimedia( sisteml folosit fiind ORACLE), interfața aplicației fiind dezvoltată în Visul Basic .Net 2003.
Cap II
Paticularitatile afacerilor imobiliare
2.1 Caracteristici generale
În România există un cadru legislativ coerent privind activitatea agențiilor imobiliare. Aceste agenții își desfășoară activitatea în conformitate cu “Ordonanța nr.3 din 21 ianuarie 2000 privind organizarea activității agențiilor imobiliare”, publicată în Monitorul Oficial al României nr. 26 din 25 ianuarie 2000.
Astfel, ativitatea profesională de intermediere a actelor juridice care au ca obiect bunuri imobile, precum și cea de administrare a acestora se desfășoară de persoanele fizice și juridice care au calitatea de agent imobiliar. Dobândirea calității de agent imobiliar se face pe baza unui eaxamen, ale cărui reguli de desfășurare sunt prevăzute în statutul ”Uniunii Naționale a Agenților Imobiliari”( UNAI), aceasta fiind o organizație profesională, independentă, autonomă, apolitică și neguvernamentală, reprezentativă în domeniu la nivel național, având caracter de corp profesional, reprezintă Autoritatea Profesională de profil, având atributele și vocația unei instituții de utilitate publică. Organizarea si funcționarea UNAI se face pe baza autoguvernării și autonomiei filialelor sale, sub coordonarea Comitetului de Conducere al uniunii.
Agentul imobiliar, societate comercială, trebuie să îndeplinească urmatoarele conditii:
să aibă ca principal obiect de activitate intermedierile imobiliare;
cel puțin unul dintre administratori sa aibă calitatea de agent imobiliar.
Agenții imobiliari primesc pentru activitatea depusă o remunerație stabilită prin contractul încheiat cu clienții. Agentul imobiliar are dreptul la primirea remunerației în cazul în care se realizează acordul de voință al parților, exprimat potrivit legii, cu privire la încheierea contractului intermediat de acesta. Cu toate acestea, agentul imobiliar este îndreptatit la acoperirea cheltuielilor efectuate în vederea îndeplinirii obligațiilor pe care și le-a asumat față de client, în situația în care acesta din urmă încheie contractul prin intermediul altei persoane. În desfășurarea activității lor agenții imobiliari răspund disciplinar, administrativ, civil sau penal, dupa caz. Titularii drepturilor asupra imobilului au obligația de a prevedea în contractul de intermediere eventualele vicii ascunse ale imobilului, cunoscute de aceștia. Agenții imobiliari răspund solidar cu aceștia, dacă nu au comunicat persoanei interesate viciile ascunse ale imobilului, menționate în contractul de intermediere. În situația în care actul se încheie ca urmare a intermedierii realizate de un agent imobiliar, situație confirmată si declarată de parți, agentul imobiliar, la cererea expresa a notarului public care autentifica actul, va depune o copie de pe convenția încheiată de parți cu agentul imobiliar sau între părți prin intermediul agentului imobiliar.
Activitatea de intermediere a actelor juridice ce au ca obiect imobile poate fi desfășurată numai de agentii imobiliari care sunt înscrisi în Registrul agenților imobiliari și dovedesc aceasta cu legitimația de membru, vizată anual. În Registrul Agenților Imobiliari sunt înscriși toți membrii, persoane fizice, precum și societățile comerciale de profil, grupați în funcție de criteriul teritorial. Informațiile și datele care se înscriu în Registrul Agenților Imobiliari sunt stabilite prin Statutul Uniunii Naționale a Agenților Imobiliari.
Cadrul legislativ în care își desfășoară activitatea agențiile imobiliare are menirea să dezvolte piața imobiliară, să protejeze pe vânzător, pe cumpărător și pe ageția imobiliară care intermediază tranzacția, să conducă la servicii complete și de foarte bună calitate, impunând niște reguli conform cărora:
agenții imobiliari primesc pentru activitatea depusă o remunerație satbilită prin contractul încheiat cu clienții
De obicei tarifele pentru intermediereea unei tranzacții imobiliare sunt următoarele:
3 % din valoarea de vânzare a imobilului pentru vânzător ( denumit în continuare furnizor)
3 % din valoarea de vânzare pentru cumpărător
50 % din valoarea chiriei pentru prima lună și pentru furnizor și pentru chiriaș, aceasta în cazul în care obiectul tranzacției imobiliare îl constituie închirierea.
Procentele prezentate mai sus nu sunt unice pentru toate agențiie imobiliare. Acestea diferă de la o agenție, dar sunt tarife practicate de majoritatea intermediarilor.
De regulă, agențiile imobiliare mai prestează și alte servicii de genul: cadastru, intabulare, extras de carte funciară. Aceste servicii sunt prestate în mod gratuit de majoritatea agențiilor imobiliare, motivul gratuității fiind, în mod evident, atragerea de cât mai mulți clienți.
Toate aceste servicii prestate trebuie sa fie în conformitate cu prevederile legii cadastrului și a publicității imobiliare( legea 7 din 13 martie 1996, publicată în Monitorul Oficial al României nr.61 / 26 martie 1996).
Această lege definește noțiunile care stau la baza oricărei afaceri imobiliare.
2.2 Organizarea activității de cadastru
Cadastrul general este sistemul unitar și obligatoriu de evidență tehnică, economică și juridică prin care se realizează identificarea, înregistrarea, reprezentarea pe hărți și planuri cadastrale a tuturor terenurilor, precum și a celorlalte bunuri imobile de pe întreg teritoriul țării, indiferent de destinația lor și de proprietar. Entitățile de bază ale acestui sistem sunt parcela, construcția și proprietarul.
Cadastrul general se organizează la nivelul fiecărei unitați administrativ-teritoriale: comună, oraș, municipiu, județ și la nivelul întregii țări. Prin sistemul de cadastru general se realizeaza:
a) identificarea,înregistrarea și descrierea, în documentele cadastrale, a terenurilor și a celorlalte bunuri imobile prin natura lor, măsurarea și reprezentarea acestora pe hărți și planuri cadastrale, precum și stocarea datelor pe suporturi informatice;
b) asamblarea și integrarea datelor furnizate de cadastrele de specialitate;
c) identificarea și înregistrarea tuturor proprietarilor și a altor detinatori legali de terenuri și de alte bunuri imobile, în vederea asigurării publicității și opozabilitații drepturilor acestora față de terți;
d) furnizarea datelor necesare sistemului de impozite și taxe pentru stabilirea corectă a obligațiilor fiscale ale contribuabililor.
Documentele tehnice principale ale cadastrului general, care se vor întocmi la nivelul comunelor oraselor si municipiilor, sunt:
a) registrul cadastral al parcelelor;
b) indexul alfabetic al proprietarilor si domiciliul acestora;
c) registrul cadastral al proprietarilor;
d) registrul corpurilor de proprietate;
e) fisș centralizatoare, partida cadastrală pe proprietari și pe categorii de folosință;
f) planul cadastral
2.3Publiciatea imobiliară
Publicitatea imobiliară întemeiată pe sistemul de evidență al cadastrului general are ca obiect înscrierea în cartea funciară a actelor și faptelor juridice referitoare la imobilele din aceeași localitate. Ea se efectuează de către birourile de carte funciară ale judecătoriilor, pentru imobilele situate în raza teritorială de activitate a acestora.
Unul sau mai multe imobile alipite, de pe teritoriul unei localităti, aparținând aceluiași proprietar, formează corpul de proprietate ce se înscrie în cartea funciară.
Mai multe corpuri de proprietăți, de pe teritoriul aceleiași localități, aparținând unui proprietar, formează partida sa cadastrală ce se înscrie în aceeași carte funciară.
Cărțile funciare întocmite și numerotate pe teritoriul administrativ al fiecarei localități alcătuiesc, împreună, registrul cadastral de publicitate imobiliară al acestui teritoriu, ce se ține de către biroul de carte funciară al judecatoriei în a carei raza teritorială de activitate este situat bunul respectiv.
Acest registru se întregește cu un registru special de intrare, cu planul de identificare a imobilelor, cu repertoriul imobilelor, indicând numărul cadastral al parcelelor și numărul de ordine al cărților funciare în care sunt înscrise, cu un index alfabetic al proprietarilor și cu o mapă în care se vor păstra cererile de înscriere, împreună cu un exemplar al înscrisurilor constatatoare ale actelor sau faptelor juridice supuse înscrierii.
Cartea funciară este alcatuită din titlu, indicând numărul ei și numele localității în care este situat imobilul, precum si din trei părți:
A.referitoare la descrierea imobilelor, care va cuprinde:
a) numărul de ordine și cel cadastral al fiecărui imobil;
b) suprafața terenului, categoria de folosință și, după caz, construcțiile;
c) amplasamentul si vecinătațile;
d) valoarea impozabilă.
B. referitoare la înscrierile privind dreptul de proprietate, care cuprinde:
numele proprietarului;
actul sau faptul juridic care constituie titlul dreptului de proprietate, precum și menționarea înscrisului pe care se întemeiază acest drept;
straămutările proprietății;
servituțile constituite în folosul imobilului;
faptele juridice, drepturile personale sau alte raporturi juridice, precum și acțiunile privitoare la proprietate;
orice modificări, îndreptări sau însemnări ce s-ar face în titlu, în partea I sau a II-a a cărții funciare, cu privire la înscrierile făcute.
C. referitoare la înscrierile privind dezmembrămintele dreptului de proprietate și sarcini, ce cuprind:
a) dreptul de superficie, uzufruct, uz, folosință, abitație, servitutile în sarcina fondului aservit, ipoteca și privilegiile imobiliare, precum și locațiunea și cesiunea de venituri pe timp mai mare de trei ani;
b) faptele juridice, drepturile personale sau alte raporturi juridice, precum și acțiunile privitoare la drepturile reale înscrise în această parte;
c) sechestrul, urmărirea imobilului sau a veniturilor sale;
d) orice modificări, îndreptări sau însemnări ce s-ar face cu privire la înscrierile făcute în această parte.Datele din cartea funciară pot fi redate si arhivate și sub forma de înregistrări pe microfilme și pe suporturi accesibile echipamentelor de prelucrare automată a datelor. Acestea au aceleași efecte juridice și forță probatoare echivalentă cu înscrisurile în baza cărora au fost redate.
Dreptul de proprietate și celelalte drepturi reale asupra unui imobil se înscriu în cartea funciară pe baza actului prin care s-au constituit ori s-au transmis în mod valabil.
Radierea înscrierii dreptului de proprietate și a celorlalte drepturi reale se face în temeiul actului care exprimă consimțământul titularului la stingerea lor, cu excepția drepturilor care se sting la împlinirea termenului menționat în înscriere sau a drepturilor viagere care se sting prin moartea titularului lor.
Modificarea conținutului unui drept ce grevează un drept real imobiliar se înscrie, potrivit regulilor stabilite pentru dobândirea și stingerea drepturilor reale.
Înscrierea unui drept se poate efectua numai:
împotriva aceluia care, la înregistrarea cererii sale, era înscris ca titular al dreptului asupra căruia înscrierea urmează sa fie facută;
împotriva aceluia care, înainte de a fi înscris, și-a grevat dreptul, dacă amândouă înscrierile se cer deodată.
Dacă mai multe persoane și-au cedat succesiv una celeilalte dreptul real asupra unui imobil, iar înscrierile nu s-au făcut, cel din urmă îndreptățit va putea cere înscrierea dobândirilor succesive o dată cu aceea a dreptului său, dovedind prin originale întreg șirul actelor juridice pe care se întemeiază înscrierile.
Înscrierile întemeiate pe obligațiile defunctului se vor putea face și după ce dreptul moștenitorului a fost înscris, în măsura în care se dovedește că moștenitorul este ținut de aceste obligații. Înscrierile în cartea funciară devin opozabile față de terți de la data înregistrării cererii. Ordinea înregistrării cererii va determina rangul înscrierii.
Dreptul de proprietate și celelalte drepturi reale sunt opozabile față de terți, fără înscrierea în cartea funciară, când provin din succesiune, accesiune, vânzare silită și uzucapiune. Aceste drepturi se vor înscrie, în prealabil, dacă titularul întelege să dispună de ele. În aceleași conditți sunt opozabile față de terți și drepturile reale dobândite de stat și de orice persoană, prin efectul legii, prin expropriere sau prin hotărâri judecatorești. Cel care a transmis sau a constituit, în folosul altuia, un drept real asupra unui imobil, este obligat să predea înscrisul translativ sau constitutiv al dreptului, pentru înscrierea în cartea funciară, dacă acest înscris este în posesia sa și este singurul exemplar doveditor, afară de cazul în care s-a procedat, din oficiu, la înscriere. În cazul în care cel obligat refuză predarea înscrisului, se va cere instanței judecătorești să dispună înscrierea.
Dobânditorul anterior poate cere instanței judecătorești să acorde înscrierii sale rang preferențial față de înscrierea efectuată la cererea unui terț, care a dobândit ulterior imobilul cu titlu gratuit sau care a fost de rea credință la data încheierii actului. Înscrierea provizorie în cartea funciară se face în cazul dobândirii unor drepturi afectate de o condiție suspensivă sau dacă hotarârea judecatorească pe care se întemeiază nu este definitivă și irevocabilă.
Înscrierea provizorie devine opozabilă terților cu rangul determinat de cererea de înscriere, sub condiție și în masura justificarii ei. Justificarea unei înscrieri provizorii își întinde efectul asupra tuturor înscrierilor care s-au făcut condiționat de justificarea ei; nejustificarea unei înscrieri provizorii atrage, la cererea celui interesat, radierea ei si a tuturor înscrierilor care s-au făcut condiționat de justificarea acesteia.
Dacă în cartea funciară s-a înscris un drept real în folosul unei persoane, se prezumă că dreptul există în folosul ei, dacă a fost dobândit sau constituit cu bună credință, cât timp nu se dovedește contrariul. Daca un drept s-a radiat din cartea funciară, se prezumă că acel drept nu există. Cuprinsul cărților funciare se consideră exact, în folosul acelei persoane care a dobândit, prin act juridic cu titlu oneros, un drept real, dacă în momentul dobândirii dreptului n-a fost înscrisă în cartea funciară vreo acțiune prin care se contestă cuprinsul ei sau dacă nu a cunoscut, pe alta cale, această inexactitate.
În cazul în care cuprinsul carții funciare nu corespunde, în privința înscrierii, cu situația juridică reală, se poate cere rectificarea acesteia. Prin rectificare se înțelege radierea, îndreptarea sau menționarea înscrierii oricărei operațiuni, susceptibilă a face obiectul unei înscrieri în cartea funciară.
Orice persoană interesată poate cere rectificarea înscrierilor din cartea funciară, dacă printr-o hotarâre judecatorească definitivă si irevocabilă s-a constatat că:
înscrierea sau actul în temeiul căruia s-a efectuat înscrierea nu a fost valabil;
dreptul înscris a fost gresit calificat;
nu mai sunt întrunite condițiile de existență a dreptului înscris sau au încetat efectele actului juridic în temeiul căruia s-a făcut înscrierea;
înscrierea din cartea funciară nu mai este în concordanță cu situația reală actuală a imobilului.
Acțiunea în rectificare, sub rezerva prescripției dreptului material la acțiunea în fond, va fi imprescriptibilă. Față de terțele persoane care au dobândit cu bună-credință un drept real prin donație sau legat, acțiunea în rectificare nu se va putea porni decât în termen de zece ani, socotiți din ziua când s-a înregistrat cererea lor de înscriere, cu excepția cazului în care dreptul material la acțiunea în fond nu s-a prescris mai înainte. Termenul va fi de trei ani socotiți de la înregistrarea cererii pentru înscrierea dreptului a cărui rectificare se cere. Hotărârea prin care s-a admis rectificarea unei înscrieri nu va fi opozabilă persoanelor împotriva cărora acțiunea nu a fost admisă. Dacă acțiunea în rectificare a fost înscrisă în cartea funciară, hotarârea judecatorească va fi opozabilă și terțelor persoane care au dobândit dreptul după înscriere.
Actele și faptele juridice, privitoare la drepturile personale, la starea și capacitatea persoanelor în legătura cu imobilele cuprinse în cartea funciară, vor putea fi înscrise la cerere, cu efect de informare pentru terțe persoane.Proprietarul unui imobil poate cere ca intenția sa de a înstăina sau de a ipoteca să fie înscrisă, arătând, în acest din urmaă caz, suma ce urmează să se garanteze prin ipotecă. Dacă se săvârșește înstrăinarea sau ipotecarea, dreptul înscris va avea rangul înscrierii intenției. Înscrierea intenției de a înstrăina sau de a ipoteca își pierde efectul prin trecerea unui termen de două luni de la data înregistrării cererii. Anul, luna și ziua în care înscrierea își pierde efectul sunt arătate atât în înscriere, cât și în încheierea care a ordonat-o.
Orice persoană interesată poate cerceta cartea funciară și celelalte evidente care alcătuiesc registrul cadastral de publicitate imobiliară, cu excepșia evidențelor care privesc siguranța națională. La cerere, se pot elibera extrase, certificate sau copii legalizate de pe carțile funciare, cu plata taxelor legale. Nici o autoritate nu poate cere trimiterea originalului carții funciare sau a planurilor de identificare a imobilelor. Mapa înscrisurilor privind înscrierea atacată poate fi cerută de către instanța judecatorească. Corpul de proprietați constituit prin înscrierile în cartea funciară poate fi modificat prin alipiri, dacă mai multe parcele se unesc într-un singur corp sau daca se adaugă o noua parcelă la un corp de proprietate ori se marește întinderea unei parcele. De asemenea, corpul de proprietate se poate modifica și prin dezlipiri, dacă se desparte o parcelă de un corp sau se micșorează întinderea unei arcele. Dezlipirea unei parcele sau a unei parți dintr-o parcelă, care face parte dintr-un corp de proprietate, se face împreună cu sarcinile care o grevează. Parcela care este grevată cu sarcini nu poate fi alipită la un alt corp de proprietate, ci formează, în caz de dezlipire, un corp de proprietate separat.
În caz de alipire sau dezlipire, se pot efectua transcrieri, dacă o parcelă trece dintr-o carte funciară în alta, sau reînscrieri, dacă, dezlipindu-se o parcelă, aceasta se trece în aceeași carte funciară ca un corp de proprietate de sine stătător sau ca o parcelă a unui alt corp de proprietate. Dacă se transcrie o parte din parcelă într-o alta carte funciară, restul se înscrie în vechea carte funciară, cu menționarea noului număr și a întinderii, iar dacă toate parcelele înscrise într-o carte funciară au fost transcrise, aceasta se închide și nu va mai putea fi redeschisă pentru noi înscrieri.
În cazul proprietații imobiliare comune ori în indiviziune se înscriu în aceeași carte funciară toți proprietarii. În ceea ce privește proprietatea indiviză, se indică cota fiecărui coproprietar. Daca o construcție face obiectul proprietății pe etaje sau pe apartamente, se întocmește o carte funciară colectivă pentru întreaga construcție și câte o carte funciară individuală pentru fiecare etaj sau apartament având proprietari diferiți. Imobilul este indicat în cartea funciară colectivă cu un număr de parcele nefracționat. În carțile funciare individuale, fiecare etaj sau apartament se indică cu un număr fracționat, al cărui numărator este numărul de parcelă arătat în cartea funciară colectivă, iar numitorul este, după caz, numărul etajului sau al apartamentului. Înscrierile care privesc întreaga clădire se fac în ambele cărți funciare.
Imobilele ce aparțin domeniului public și domeniului privat al statului sau, după caz, al unității administrativ-teritoriale, se înscriu în registrul de publicitate special al unității administrativ-teritoriale pe care sunt situate. Registrele de publicitate se țin de către biroul de carte funciară al judecătoriei.
2.4 Procedura de înscriere în cartea funciară
Cererea de înscriere în cartea funciară se depune la biroul de carte funciarăa al judecătoriei și este însoțită de înscrisul original sau de copia legalizată de pe acesta, prin care se constată actul sau faptul juridic a cărui înscriere se cere. Copia legalizată se păstrează în mapa biroului de carte funciară. În cazul hotărârii judecatorești, se prezintă o copie legalizată, cu mențiunea că este definitivă și irevocabilă. Cererile de înscriere se înregistrează de îndată în registrul de intrare, cu menționarea datei și a numărului care rezultă din ordinea cronologică a depunerii lor. Dacă mai multe cereri au fost depuse deodaăa la același birou de carte funciară, drepturile de ipotecă și privilegiile au același rang, iar celelalte drepturi primesc numai provizoriu rang egal, urmând ca prin judecată să se hotarască asupra rangului și asupra radierii încheierii nevalabile.
În cazul în care judecatorul de la biroul de carte funciară admite cererea, dispune înscrierea prin încheiere, dacă înscrisul îndeplinește următoarele condiții:
cerințele de validitate a actului juridic;
are deplină putere doveditoare;
indică numele partilor;
individualizează imobilul cu numărul de parcelă;
este însoțit de o traducere legalizată, dacă nu este întocmită în limba română.
Încheierea cuprinde determinarea dreptului sau a faptului, indicarea numărului parcelei și a cărții funciare, precum și a părții cărții funciare în care urmează a se face înscrierea. În cazul în care identificarea cadastrală a parcelei nu este posibilă, pe baza datelor existente, sunt folosite schițe de plan vizate de oficiul județean de cadastru, geodezie si cartografie.
Dacă se constata că cererea de înscriere în cartea funciară nu întrunește conditțiile legale, se respinge printr-o încheiere motivată. Despre respingerea cererii se face mențiunea în registrul de intrare, în dreptul înregistrării acesteia.
Încheierea se comunică celui care a cerut înscrierea sau radierea unui act sau fapt juridic, precum și celorlalte persoane interesate potrivit mențiunilor din cartea funciară, cu privire la imobilul în cauză, în termen de 20 de zile de la pronunțarea încheierii, dar nu mai târziu de 60 de zile de la data înregistrării cererii. Încheierea este supusă căilor ordinare de atac; cererea de apel se depune la biroul de carte funciară și se înscrie în cartea funciară. În cazul în care se declară și recurs, cererea de înscriere respectivă se comunică biroului de carte funciară pentru înscriere. Hotărârea judecatorească definitivă și irevocabilă se comunică, din oficiu, biroului de carte funciară, de către instanța care s-a pronunțat ultima asupra fondului.
Înscrierile și radierile efectuate în cărțile funciare nu pot fi rectificate decât pe baza hotărârii instanței judecătorești rămase definitivă și irevocabilă. În cazul în care o carte funciară urmează a fi întocmită ori completată prin înscrierea unui imobil care nu a fost cuprins în nici o alta carte funciară, precum și în cazul în care o carte funciară a fost distrusă, pierdută ori a devenit nefolosibilă, în total sau în parte, din diferite cauze, întocmirea, completarea si reconstituirea, dupa caz, se face de către judecătorul de la biroul de carte funciară, la cerere sau din oficiu, cu acordul celor interesați, pe baza unei încheieri. În acest scop se folosec toate înscrisurile privitoare la imobilele în cauză pentru identificarea parcelelor și a suprafețelor, precum și situația dreptului de proprietate, schița de plan, constatări la fața locului sau, după caz, înregistrările după microfilme și pe suporturi accesibile echipamentelor de prelucrare automata a datelor.
Erorile materiale săvârșite cu prilejul înscrierilor sau radierilor se pot îndrepta, prin încheiere motivată, de către judecătorul de la biroul de carte funciară, la cerere sau din oficiu, cu sau fără citarea părților. Această încheiere se comunică părții care nu a fost prezentă.
Notarul public care întocmește un act prin care se transmite, se modifică, se constituie sau se stinge un drept real imobiliar este obligat să ceară, din oficiu, înscrierea în cartea funciară. În acest scop, trimite cererea de înscriere a acestui act, în ziua întocmirii lui sau cel mai târziu a doua zi, la biroul de carte funciară al judecatoriei în a cărei rază de activitate se află imobilul, în afară de cazul în care partea interesată și-a rezervat dreptul de a face diligențele necesare pentru înscriere. Instanța judecătorească transmite, în termen de trei zile, hotărârea rămasă definitivă și irevocabilă, constitutivă sau declarativă asupra unui drept real imobiliar, la biroul de carte funciară al judecătoriei în a carei rază de activitate se află imobilul. Instanța judecătorească nu va trece la dezbaterea în fond a acțiunii privind desființarea actului juridic supus înscrierii, dacă acesta nu a fost înscris, în prealabil, pentru informare, în cartea funciară.
Toate aceste aspecte prezentate mai sus constituie baza oricărei tranzacții imobiliare în ceea ce privește tranzacția imobiliară în sine și în ceea ce privește alte servicii pe care agenția imobiliară le prestează.
Având în vedere toate acestea putem spune că legislația imobiliară din România este aliniată la cerințele Uniunii Europene. Însă un alt lucru ne deranjeză: birocrația, cozile interminabile etc. Acestea de cele mai multe ori nu încearcă răbdarea populației ci o determină pe aceasta să apeleze la intermediari care să rezolve situția în timp util. Acești intermediari sunt tocmai agențiile imobiliare care își rotunjesc o bună parte din venituri tocmai din prestarea acestui gen de servicii pentru poplație.
Astfel, putem spune că avem de a face cu un cadru legislativ coerent și foarte strict din punct de vedere al documentelor implicate, responsabilităților și restricțiilor, a pregătirii personalului din cadrul agențiilor imobiliare și pe de altă parte cu un sistem birocratic care necesită incă multe retușuri. Toate acestea însă fac din afacerile imobiliare afaceri de real succes.
Capitolul III
Structuri de apartamente și descrierea lor
În tranzacțiile imobiliare, cele mai des tranzacționate imobile sunt garsonierele și apartamentele cu două, trei sau patru camere. Tipurile de astfel de apartamente sunt multiple și descrierea lor în aplicație ar fi una costisitoare( din punct de vedere al timpului necesar introducerii tuturor reperelor ) dacă s-ar recurge la coordonate. Imaginea pe care ar crea-o reconstituirea nu ar fi fidelă și nu ar corespunde realității. Reprezentarea unei schițe de apartament ( care este o imagine bidimensională )nu ar prezenta prea mari dificultăți, însă imaginile tridimensionale ar fi o reală problemă. Astfel, a fost necesară găsirea unei soluții pentru remedierea acestui neajuns și s-a constituit chiar din stocarea pe suport fizic a schiței și a descrierii apartamentului în format fișier imagine, cu alte cuvinte stocarea acestora într-o bază de date multimedia.
În literatura de specialitate nu s-au scris prea multe lucruri legate de bazele de date multimedia până în prezent, deși acestea sunt foarte interesante și importanța lor crește din ce în ce mai mult. „Adevăratele” baze de date multimedia sunt destul de diferite de bazele de date normale cu facilități multimedia, deoarece ele au caracteristici speciale și îndeplinesc cerințe specifice. Aceste cerințe sunt tipice pentru aplicațiile interactive multimedia, o categorie relativ nouă de aplicații, cu o foarte mare importanță in domeniul World Wide Web. Deși noțiunea de „multimedia” atrage atenția, aceasta reprezintă in realitate doar o subclasă a unei vaste categorii de date nestucturate, denumita data abstracta, alte exemple incluzând analiza amprentelor, razele X, electrocardiogramele și imaginile bazate pe rezonanță magnetică (Magnetic Resonance Imaging – MRI). Acest gen de aplicații solicită stocarea unor volume imense de date, de fapt, cerințele legate de stocare și prelucrare pe care trebuie să le îndeplinească acestea sunt aproape identice cu cele ale aplicațiilor multimedia. În general, o bază de date multimedia trebuie să fie capabilă să gestioneze un ansamblu de date abstracte. De fapt, noțiunile „multimedia” și „date abstracte” sunt interconectate.
3.1 Definirea conceptelor
Bază de date – este un grup de fișiere în care este înregistrată o mulțime centralizată de date, organizată în scopul prelucrării acestora, pentru deservirea unor aplicații.
Conceptul de multimedia, se referă la abilitatea de a achiziționa, manipula, combina și reda informații de la o mare varietate de medii, ce includ text, grafică, animație, sunet, imagine fixă sau video. Multimedia nu este deci o tehnologie, ci mai de grabă un termen ce decrie un număr de tehnologii care lucrează împreună.
Noțiunea de multimedia, definește integrarea într-o concepție unitară a imaginilor, textelor și sunetelor care formează un document.
Cumulate, cele două concepte de mai sus, rezultă noțiunea de bază de date multimedia – realizează o uniune între disciplinele de regăsire a informațiilor și de management al bazelor de date, care până acum erau considerate ca fiind două discipline total diferite și disjuncte.
De aici rezultă și numărul mare de aplicații al acestora, și anume:
• în administrarea documentelor și a înregistrărilor – în întreprinderi și instituții comerciale, acestea având nevoie de diverse documente, în funcție de specificul lor.
• în educație și instruire – în regăsirea materialelor pentru pregătirea tuturor persoanelor.
• în controlul și monitorizarea proceselor în timp real – împreună cu bazele de date active, prezentările multimedia de informații au un rol efectiv în operațiile de monitorizare și control în sistemele de transport, de supraveghere a pacienților, etc.
• în informare – multimedia este modul cel mai rapid, eficient și ieftin în comparație cu alte medii de informare a publicului, cuprinzând adevărate enciclopedii electronice.
• în reclame – în mod practic nu există nici o limită în folosirea informației multimedia în astfel de aplicații.
Pentru realizarea tuturor acestor aplicații în condiții optime, bazele de date multimedia trebuie ca pe lângă asigurarea unui timp minim de acces la date să garanteze și integritatea, securitatea și independența datelor, care reprezintă totodată și caracteristici de calitate software.
Problemele care apar în bazele de date multimedia pot fi grupate astfel:
regăsirea informațiilor este o problemă mai ales în cazul imaginilor dinamice și al segmentelor audio și video, deoarece de multe ori acestea conțin informațiile relevante. Pentru bazele de date regăsirea se face cu ajutorul limbajului de interogare (SQL) și a structurilor indexate. Problemele care apar se datorează în primul rând navigatoarelor (foarte diferite) cu care se lucrează, deoarece fiecare interpretează în mod diferit imaginile, în funcție de platforma pe care rulează. În al doilea rând, există o limitare fizică a driverelor cu care se lucrează pentru regăsirea acestor tipuri de informații; în multe cazuri informațiile nu pot fi accesate, navigatorul anunțând printr-un mesaj soft-ul necesar. Astfel, o poză stocată în baza de date nu poate fi regăstă cu ajutorul unei sintaxe de genul “select …from tabelă”. O astfel de poză poate fi regăsită după un anumit identificator( id ) și pentru a putea fi vizualizată va trebui să fie deserializată( adică recompusă într-un format accesibil unui navigator). De exemplu, putem să considerăm următoarea schiță:
Pentru ca aceasta să poată fi inserată într-o bază de date ea trebuie mai întâi să fie serializată, adică transformată într-un șir de caractere cu un anumit format( format care este specific fiecărui fișier de tip imagine; tipul acestui fișier se află în antetul șirului de caractere). Acest șir de caractere poate fi folosit mai departe într-o sintaxă de genul “ insert into tabelă…”, adică stocată într-o bază de date. Extragerea pozei din baza de date este procesul invers, adică deserializare.
descrierea conceptuală, logică și fizică este o problemă care apare și la care nu există încă un răspuns clar.
aplicațiile multimedia conțin mii de imagini statice și dinamice, documente, texte, segmente audio și video; organizarea acestora depinde de modelarea structurilor și a conținutului de date. Aceasta poate fi considerată și o problemă ce necesită eficientizarea spațiului ocupat de baza de date pe suportul fizic, cunoscut fiind faptul că informațiile multimeadia ocupă foarte mult spașiu fizic pe disc.
o problemă este generată de conflictul care apare între aplicarea tehnicilor bazelor de date și a celor de regăsire a informațiilor. În sistemele de baze de date, modelarea conținutului de date nu este o problemă deoarece datele au o structură rigidă. Pe de altă parte, regăsirea informațiilor se ocupă în special cu modelarea contextului documentului (prin cuvinte cheie, indexuri, rețele semantice, etc).
stocarea datelor multimedia pe suporturi standard; această etapă prezintă probleme de reprezentare și compresie/decompresie. Tendința în prezent este de arhivare a informațiilor astfel încât să se reducă dimensiunea zonei tampon în timpul operațiilor de intrare/ieșire. O modalitate de a elimina aceste probleme este folosirea standardelor ca JPEG sau MPEG; pentru bitmap-uri există BLOB (Binary Large Object) care facilitează stocarea și regăsirea datelor. Pentru documente există deja aplicații, cum sunt Encode/Uuencode (Windows), Tar (Unix), etc., care realizează compresia/ decompresia acestora (deocamdată în stadiu incipient de dezvoltare).
altă problemă care apare este cea a performanței. Pentru aplicațiile multimedia ce conțin simple documente și text, constrângerile de performanță sunt subiectiv determinate de către utilizatori. În cazul aplicațiilor cu imagine video în mișcare, sau sincronizare audio-video, se poate vorbi de o limitare fizică.
3.2 Procedee de realizare a documentelor multimedia
Primul instrument care s-a impus și pe baza căruia se construiesc în prezent documentele multimedia este limbajul HTML. Acesta s-a dezvoltat treptat, deoarece îi lipseau posibilitățile de a descrie publicații electronice profesionale. Prima lui formalizare, standardul HTML 2.0, deși mai performant, nu a reușit să satisfacă cerințele unei publicații electronice profesionale. Despre folosirea unor editoare WYSIWYG ( What You See Is What You Get) nici nu poate fi vorba, deoarece navigatoarele afișează același document destul de diferit, în funcție de platforma pe care lucrează.
Dacă într-o revistă imaginile sunt statice, într-o revistă electronică ele pot fi alternate sau dinamice, ca într-o diaporamă (slide-show). Documentele dinamice au fost ideea Netscape, care le-a introdus pe piață o dată cu versiunea Netscape 1.0. Metoda, numită Client Pull, îi permite navigatorului să încarce un document după un număr de secunde, fără nici o intervenție din partea utilizatorului.
Natura Web-ului se schimbă rapid, de la pagini statice, la pagini a căror formă și conținut se schimbă de fiecare dată când sunt încărcate. Acest lucru este posibil datorită unor limbaje special concepute pentru a putea fi folosite la scrierea de programe care se inserează direct în documentele HTML. Ele caracterizează ceea ce numim situri Web din a doua generație.
Primul dintre acestea, Java, a fost lansat de către firma Sun în 1995, părintele lui fiind James Gostling. Limbajul Java este o simplificare a limbajelor orientate pe obiecte, de fapt a C++ -ului. Java păstrează proprietățile acestora, fiind flexibil, simplu, puternic, independent de platforma hardware pe care rulează.
Cel mai dinamic dintre aceste limbaje pare a fi JavaScript. Deși nu este încă în forma finală, limbajul prezintă avantajul scrierii unor programe simple direct în paginile HTML, programe care pot fi interpretate local de către navigator. JavaScript seamănă cu Java, dar spre deosebire de acesta JavaScript are funcții și declarații de sine stătătoare. Un alt avantaj al acestui limbaj este siguranța, deoarece nu poate fi utilizat pentru a accesa și scrie pe discul clientului. Folosit împreună cu HTML, Java și CGI, duce la creșterea performanțelor Web-ului și a vitezei de lucru a navigatoarelor.
CGI (Common Gateway Interface) s-a impus ca cea mai eficientă, stabilă și ușor de înțeles modalitate de manipulare a informației generate în mod dinamic pe Web. Este de fapt acea parte a server-ului Web care poate comunica cu alte programe care rulează pe sistem. Cu ajutorul acestei interfețe, serverul Web poate apela un program. Cele mai răspândite aplicații ale CGI-ului sunt: prelucrarea datelor inserate în formulare (care necesită un răspuns), interogarea unor baze de date pentru o anumită informație (se realizează cu așa numitele căutătoare: Altavista, Lycos, Yahoo, Infoseek prin interogări SQL), documente virtuale (documente HTML complexe, care conțin text, imagini, fișiere de sunet sau video).
Limbajul cel mai des utilizat pentru scrierea programelor este Perl (mai ales pentru sistemele Unix) deoarece pare a fi cel mai ușor de utilizat pentru manipularea textelor și a matricelor. Există și versiunea WebForms, Q&D Software Development, a cărei interfață grafică permite generarea rapidă și automată a formularelor și a scripturilor CGI în Perl.
În încheiere aș menționa faptul că pe Internet există deja foarte multe baze de date multimedia, dintre care unele permit utilizatorilor acces liber la informațiile pe care le dețin. Un exemplu este Hensa Unix, care menține copii ale arhivelor electronice. Aceasta are 40 de colecții din Statele Unite și Europa, care cuprind software, documentații, bibliografii și multimedia. Washington University Multimedia Collection este o arhivă multimedia mare, care cuprinde în prezent imagini – peste 6000 gif-uri și 2500 jpeg-uri, muzică – 1800 fișiere midi, audio și pachete de artă. Adresa acesteia este:
http://www.hensa.ac.uk/mirrors/wuarchive/multimedia/artpackage/
O statistică estima numărul paginilor Web la aproximativ 50 de milioane, și numărul lor este într-o continuă creștere.
3.3 Particularități ale datelor de tip multimedia
Așa cum artă și denumirea, multimedia combină mai multe tipuri de media, precum imagine, video, audio, grafică, animație, hypertext și hypermedia. De asemenea, poate să includă și date de tip MRI și alte tipuri de date abstracte (Abstract Data Types – ADTs). Multe sisteme de baze de date permit stocarea diverselor tipuri de date abstracte sub formă de obiecte binare extinse, sau de tip BLOB; standardul ANSI SQL3 (care se află în dezvoltare) permite stocarea datelor abstracte sub formă de obiecte.
O imagine statică reprezintă intr-adevăr un desn static. Dar chir și o singură imagine statică poate necesita o capacitate sporită de stocare. O imagine color poate necesita tot atâta spațiu de stocare cât o carte întreagă, adică peste un million de byți, aceasta deoarece stocarea informațiilor referitoare la culori implică trei combinații de culori, triplând astfel dimensiunea de stocare a unei imagini alb-negru.
Imaginile conțin relații spațiale care pot fi utilizate în analize, cum ar fi, de exemplu, localizarea unei persoane în raport cu alta. Standarde precum Joint Picture Experts Group (JPEG) au la bază trăsături caracteristice legate de compresia și stocarea imaginilor statice. Video combină o secvență de imagini, numite “frame-uri”, care realizează iluzia de mișcare. O mișcare simplă necesită o rată minimă de afișare de 24 frame-uri pe secundă (fps), iar calitatea imaginii crește pe măsură ce ratele de înregistrare și playback cresc. Standardul minim de calitate este de 30 fps. La această rată, este necesară o medie de 20 MB memorie pe secundă pentru afișarea imaginii video – astfel, un film de două ore fără sunet necesită aproximativ 144 GB.
Standardele de compresie video și stocare cum ar fi noul standard Motion Picture Experts Group (MPEG-2) reduc cerințele legate de memorie cu cel puțin 40 la 1 – prin utilizarea acestui standard, dispoyitivele DVD vor fi capabile să stocheze un film întreg. În paralel cu asigurarea unei rate ridicate de compresie în comparație cu standardele mai vechi precum MPEG-1, MPEG-2 oferă și o calitate mai bună pentru imaginile video și transmisiile prin satelit.
Spre deosebire de imaginile statice, video conține atât legături temporale cât și spațiale între frame-uri, legăturile temporale precum “înainte”, “după” și “în timp ce” fiind în concordanță cu cele spațiale. În general, compresia MPEG realizează eliminarea redundanței spațiale (intraframe), cât și a celei temporale (interframe). Frame-urile sunt comprimate “spațial” (se bazează pe părți ale unui frame, ce conțin aceleași date) și “temporal” (se bazează pe succecsiunea de frame-uri ce conțin aceleași date). Compresia interframe sau temporală este posibilă chiar și atunci când părțile identice ale frame-urilor sunt situate în locații diferite (datorită unui obiect în mișcare sau cameră de filmat, de exemplu).
Compresia de tip MPEG este foarte puternică și consumatoare de timp, fiind în general cel mai bine implementată hardware. Decompresia necesită mai puțină putere de prelucrare și poate fi implementată software, dar hardware conduce, de obicei, la rezultate mai bune. În fiecare caz, dacă software-ul sau hardware-ul nu poate face față decompresiei pe parcursul rulării, frame-urile vor fi sărite pentru a păstra rata temporală, producându-se astfel fenomenul numit “jitter”.
Datele audio cum ar fi muzică, voce sau sunet combină frecvența cu amplitudinea. Acestea, ca și video, pot fi comprimate și sunt de obicei combinate cu video (comprimate sau stocate împreună). MPEG permite această abordare; stochează multiple secvențe audio și video – precum diferite limbi sau unghiuri de filmare, care pot fi selectate pe parcursul rulării.
Alte formate pentru stocare video și audio cunoscute sunt AVI de la Microsoft pentru video sub Windows și QuickTime Movies de la Apple pentru Quicktime. JPEG poate fi folosit și pentru video ca Motion JPEG, care optimizează considerabil performanțele aplicațiilor care implică acces secvențial. (JPEG este proiectat pentru imagini statice, iar în aplicațiile cu acces secvențial, imaginile sunt total independente una de alta). Motion Jpeg asigură localizarea și rularea cu ușurință a unui frame dintr-o locație anume. Această sarcină este dificilă pentru MPEG datorită compresiei redundante interframe, utilizate de acesta.
Hypertext-ul este format din noduri de text, legate pentru a forma o rețea semantică de concepte și relații. Un sistem hypertext permite parcurgerea acestor legături pentru regăsirea textului sau a altor informații, cum ar fi desene, fotografii sau programe. Utilizatorii stabilesc cât timp petrec într-un nod și care va fi următorul nod vizitat. Hypertextul este implementat de obicei folosind Modelul Dexter Hypermedia, care are trei niveluri: runtime, stocare și componenta internă. Nivelul de stocare constă în noduri și legături; fiecare nod include pointeri către locațiile exacte ale ancorelor conectate prin intermediul legăturilor. Între nivelul de stocare și nivelul runtime se află un mechanism de prezentare, iar între nivelul de stocare și nivelul componentei interne se află un mechanism de regăsire a componentelor multimedia.
Deoarece multimedia se bazează pet imp, sincronizarea este deosebit de importantă. Dacă sunt implementate corect, componentele media vor fi afișate într-o ordine precisă și perfect sincronizate. Audio și video necesită, de asemenea, sincronizare, multiple imagini video și statice fiind afișate simultan (ceea ce implică sincronizare). Hypermedia solicită legături, precum și temporizare: combină facilitățile legăturilor associate hypertext cu facilitățile sincronizării multimedia. De exemplu, un utilizator care selectează un element dintr-o imagine video invocă legături către alte date multimedia relaționate cu acesta. La început, formele media erau limitate la stocare analogică și procesare liniară. Dar, deoarece acestea sunt acum stocate digital, pot fi procesate neliniar într-un numar nelimitat de moduri. Implicațiile legate de aplicașiile multimedia sunt enorme.
3.4 Resurse necesare aplicațiilor multimedia
Aplicațiile multimedia sunt interactive și orientate – multimedia. Principalele lor funcții sunt acelea de a organiza, prezenta și sincroniza datele multimedia pentru medii interactive. În aceste tipuri de mediu, aincronizarea și organizarea sunt critice.
În cadrul aplicațiilor multimedia, trebuie accesată eficient o cantitate mare de material media stocat. Orgaizarea este importantă nu doar pentru prezentare, ci și pentru producție, incluzând preproducția (storyboarding) și postproducția (editing). Deoarece realizarea implică totul, de la design, la editare și scenario, sunt implicați mulți profesioniști, cum ar fi artiști graficieni și compozitori. Informațiile trebuie să fie organizate corespunzător, astfel încât să permită activități paralele cu un grad minim de confizie.
Prezentarea multimedia necesită ca outputul rezultat în urma prelucrării informațiilor să fie unde, când și cum a menționat autorul. Această capacitate poate fi specificată neprocedural prin intermediul unei interfețe GUI (Guide User Interface) sau procedural, prin utilizarea unui script pentru un control mai riguros. Utilizând o metaforă, într+un limbaj de tip script, ecranul este văzut ca o scenă, iar imaginile video ca actori pe această scenă. Scriptul precizează, de asemenea, dimensiunile și pozițiile actorilor pe ecran, precum și textul, titlurile, icon-urile și butoanele de selecție.
Aplicațiile multimedia și operațiile legate de acestea trebuie să fie sincronizate, deoarece acestea se desfășoară simultan, datorită proceselor concurente. Această caracteristică a deschis drumul pentru o nouă și importantă capacitate numită „urme” paralele. Prin acest procedeu, imaginile filmate din multiple unghiuri sau perspective pot fi schimbate între ele dinamic sau chiar afișate simultan.
Mai mult, aplicațiile multimedia implică interacțiunea cu utilizatorul, care are loc de cele mai multe ori la intervale de timp de durată variabilă. Această caracteristică face sincronizarea și mai importantă în cadrul aplicațiilor multimedia. De fapt, în lipsa interacțiunii cu utilizatorul, nu ar mai exista o aplicație propriu-zisă, ci doar o secvență uniformă de media.
Un bun exemplu de aplicație interactivă este o carte electronică multimedia, care permite interacțiuni permanente și produce mai multe combinații media. Utilizatorii pot „citi” textul (paginile) cărții secvențial sau printr-o modalitate de acces direct. Utilizatorii accessează cartea în mod secvențial, de la început la sfârșit, având și acces permanent la hypertext și legăturile hypermedia. Textul (hypertext) poate fi utilizat de asemenea ca o referință pentru accesarea directă a anumitor pagini prin intermediul legaturilor (hyperlink) din cuprins sau index.
Capitolul IV
Proiectarea bazei de date multimedia și a aplicației
Proiectarea oricărei aplicații și implicit a suportului de baze de date presupune mai multe etape, foarte importante în realizarea unui produs software de calitate. Astfel, în continuare vor fi prezentate câteva caracteristici ale proiectării și a metodologiei alese pentru realizarea acesteia și se vor defini câteva noțiuni de bază.
4.1.Definirea sistemului informatic
4.1.1.Definirea sistemului informatic. Obiective.
Funcționarea unui sistem informațional-decizional presupune, în principal, desfășurarea următoarelor activități:
culegerea datelor despre starea sistemului condus și a mediului său înconjurător;
transmiterea datelor în vederea prelucrării;
prelucrarea datelor în scopul asigurării informațiilor necesare procesului decizional;
adoptarea deciziilor;
transmiterea deciziilor spre execuție;
asigurarea controlului și a urmăririi înfăptuirii deciziilor.
Utilizarea tehnicii de calcul a produs mutații majore în modul de realizare al acestor activități și implicit a determinat apariția conceptului de sistem informatic.
Sistemul informatic face legătura între sistemul condus și sistemul de conducere, fiind subordonat acestora.
Fig.1 Sistem informatic / Sistem informațional
Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcțional pentru automatizarea procesului de obținere a informațiilor și pentru fundamentarea deciziilor.
El se poate prezenta sub forma unei “cutii negre” care are intrări informaționale ce sunt trasformate în informații de fundamentare a deciziilor prin intermediul unor resurse, reguli, proceduri.
Sistemul informatic este inclus în cadrul sistemului informațional și are ca obiect de activitate, în general, procesul de culegere, verificare, transmitere, stocare și prelucrare automată a datelor. Prin implementarea unor modele matematice și utilizarea tehnicii electronice de calcul, în activitățile enumerate, sistemul informatic imprimă valențe sporite sistemului informațional sub aspect cantitativ și calitativ. Astfel asistăm la o creștere a capacității de calcul sub aspectul volumului datelor prelucrate și a operațiilor efectuate însoțită de creșterea exactității informațiilor, sporirea operativității și complexității situațiilor de informare – raportare. Toate aceste aspecte determină o apropiere mai mare a decidentului de fenomenele și procesele economice pe care acesta le are în atenție, cu multitudinea aspectelor economice pozitive ce derivă din acestea.
În ceea ce privește raportul dintre sistemul informatic și sistemul informațional se poate aprecia că sistemul informatic tinde spre a egala sistemul informațional, însă acest lucru nu va fi posibil datorită limitelor sistemului informatic. Tot timpul în cadrul sferei sistemului informațional vor exista o serie de activități ce nu vor putea fi automatizate. Însă, dacă acceptăm includerea în sfera sistemului informatic a activității de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, putem asista la automatizarea completă a procesului decizional și a reglării automate a procesului tehnologic. Într-o astfel de situație sistemul informatic depașește sfera sistemului informațional.
Plecând de la ideea că sistemul informatic este subordonat procesului decizional, al cărui rol este de a asigura funcționarea normală și optimă a întregii activități și de a reduce la minimum pierderile în caz de funcționare anormală, considerăm că obiectivul oricărui sistem informatic trebuie să fie subordonat obiectivului propriu-zis al unității economico-sociale. În acest context obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie asigurarea conducerii cu informații reale și în timp util, necesare fundamentării și elaborării operative a deciziilor.
Pe lângă acest obiectiv, sistemul informatic mai are și alte obiective numite obiective secundare și care pot fi considerate chiar condiții de prim ordin pentru realizarea obiectivului principal. În caz contrar, urmărirea realizării unui obiectiv, necorelat cu celelalte obiective ale sistemului, se transformă într-un scop în sine și este lipsită de eficiență.
4.1.2.Analiza și proiectarea de sistem
Scopul analizei de sistem este de a studia în profunzime obiectivele și problemele activităților desfășurate într-o întreprindere și de a proiecta un nou sistem care va corecta sau va rezolva problemele existente, va eficientiza utilizarea resurselor disponibile, și în cele din urmă va asigura atingerea obiectivelor organizației în modul cel mai eficient posibil. Obiectivele sunt însă în continuă schimbare, ceea ce face ca activitatea de analiză – proiectare să fie deosebit de dificilă. Cerințele sistemului evoluează pe masură ce obiectivele organizației se schimba ca răspuns la acțiunea exercitată de mediul înconjurător. Proiectarea unui sistem nu se incheie deci odată cu implementarea și darea lui în explotare, proiectantul trebuie să aibă în vedere ca orice modificare a sistemului să se poată realiza fără efort suplimentar.
Analistul de sistem are de interpretat un rol foarte delicat. El trebuie să inteleagă și să cunoască foarte bine structura și modul de funcționare al organizației, metodologia de dezvoltare a sistemului, cele mai noi tehnologii disponibile și mai ales relațiile interumane. Analistul de sistem depinde de oamenii care-și desfășoară activitatea în sistem pentru a primi răspunsuri la o mulțime de întrebări despre funcționarea sistemului, cum ar fi: Ce se face?, De ce se face?, Cine face?, Cum se face?, Care sunt principalele probleme care apar? Analistul de sistem trebuie deci să stăpânească mai presus de toate arta comunicării, căci comunicarea efectivă este esențială pentru a asigura dezvoltarea acelor sisteme și proceduri ce servesc cel mai bine obiectivele întreprinderii și răspund optim cerințelor conducerii, operatorilor, utilizatorilor și tuturor celor ce vor fi afectați de noul sistem în mod direct sau indirect.
4.1.3. Probleme asociate cu activitatea de analiză și
proiectare a sistemelor
Problemele de comunicare între beneficiar și analistul de sistem pot da naștere unor dificultăți majore în ințelegerea mediului în care-și desfășoară activitatea utilizatorul și ca urmare în formularea cerințelor acestuia. Aceste dificultăți se materializează în modificarea continuă a mediului utilizatorului și a cerințelor sale detaliate.
Este foarte dificil pentru analistul de sistem să cunoască atât de bine mediul utilizatorului încât să observe sistemul existent din punctul său de vedere. În mod similar, beneficiarul nu deține cunoștințele necesare pentru a-și formula în mod clar, consistent și complet cerințele. Iată de ce activitatea de analiză implică o strânsă colaborare între beneficiar și analist, fiind de așteptat ca analistul să conducă acest “parteneriat”.
Cea mai mare parte a fazei de investigare și analiză a oricarui proiect se desfășoară adunând informații detaliate despre sistemul existent. Volumul informațiilor obținute poate fi copleșitor dacă analistul nu organizează detaliile cu ajutorul unor scheme sau structuri. Detaliile sunt necesare și trebuie să fie disponibile atunci când e nevoie de ele, astfel analistul trebuie să dispună de tehnici și instrumente pentru a controla informațiile obținute.
Documentul în care se menționează detaliile noului sistem este în fapt un contract între beneficiar și proiectant. Trebuie să fie deci ușor de înțeles pentru utilizator, dar în același timp suficient de formal pentru a servi drept specificație de proiectare. Dacă documentul este vag, inconsistent sau incomplet el nu mai reprezintă o bază de pornire satisfăcătoare pentru proiectare. Pe de altă parte, dacă este prea formal pentru a fi înțeles de beneficiar, atunci acesta nu se va simți legat de el, deci nu va exista nici un contract și beneficiarul se va simți liber să-și schimbe cerințele în orice moment. Modificarea cerințelor în stadii avansate ale realizarii unui sistem este unul dintre motivele principale pentru care se intârzie finalizarea proiectului și se măresc costurile de realizare.
O problemă particulară a fazei de proiectare este dificultatea evidențierii elementelor ce țin de proiectarea tehnică de detaliu, adică separarea a ceea ce trebuie implementat de modul cum trebuie implementat. În mod ideal proiectarea logică a proceselor și structurilor de date ar trebui să se realizeze și să se documenteze înaintea proiectarii detaliilor tehnice privind implementarea tehnică.
O altă problemă a dezvoltării sistemelor informatice este absența unui sistem comun de notații pentru toate stadiile proiectării. Transformările de la o notație la alta pe masură ce proiectul evoluează pot introduce erori de interpretare. Notațiile utilizate în faza de descriere a sistemului existent și în specificarea cerințelor noului sistem trebuie să fie inteligibile pentru ambele părți, atât pentru beneficiar cât și pentru proiectant. Neînțelegerile de la acest nivel constituie o cauză majoră a nerespectării cerințelor utilizatorului. În figura următoare sunt evidențiate proporțiile tipice ale rezultatelor obținute în urma realizarii unui sistem.
Dacă specificațiile sunt scrise doar în limbaj natural este puțin probabil că în faza de proiectare se vor respecta întocmai cerințele beneficiarului. Limbajul natural este vag și o specificație complexă exprimată în limbaj natural este cel mai probabil incompletă și contradictorie.
Procesul de dezvoltare al unui sistem informatic trebuie să rezolve o mulțime de probleme. Tendințele generale în care se incadrează aceste probleme sunt:
costuri de dezvoltare ce depășesc bugetul disponibil;
timpi de dezvoltare ce depășesc termenele prevăzute;
realizarea unor sisteme ce nu răspund cerințelor utilizatorilor, sunt nefiabile și dificil de modificat și întreținut.
Cauza principală a problemelor enunțate este complexitatea deosebită a celor mai multe proiecte de realizare. Calculatoarele au eficientizat un mare număr de activități și au deschis spre explorare noi și noi probleme, altădată imposibil de considerat. Astfel s-a ajuns la necesitatea unui cadru cu ajutorul căruia să se poată controla o astfel de complexitate.
Este deci necesară o metodologie de dezvoltare a specificațiilor cerințelor și a specificațiilor de proiectare pentru a depăși aceste probleme. O metodologie reprezintă în acest caz un mod de structurare a gândirii cuiva despre un anumit domeniu. Ea facilitează descompunerea unei probleme complexe într-o serie de subprobleme care pot fi analizate separat în detaliu, la momente de timp diferite fără pierdere de informație și fără riscul de a fi distras de probleme irelevante pentru stadiul de analiză la care s-a ajuns. O metodologie de analiză și proiectare a sistemelor furnizează cadrul necesar pentru atingerea unor obiective specifice. Utilizarea unei astfel de metodologii structurate nu garantează însă succesul, atingerea obiectivelor depinzând de o serie de criterii.
Pentru a rezolva dificultățile ridicate de complexitatea problemelor reale au fost creeate o serie de tehnici și instrumente corespunzător celor două tipuri de abordare a proiectarii sistemelor informatice – abordarea structurată și abordarea orientată obiect. Vor fi prezentate mai pe larg, în finalul lucrării, colectia de metode propuse ca standard de OMG (Object Management Group) în analiza și proiectarea orientată obiect.
4.1.4 Ciclul de viață al unui sistem informatic
Lansarea unui proiect pentru un nou sistem poate avea la baza un eveniment de tipul celor ce urmează:
Se intâmpină dificultăți în operarea cu sistemul actual: modificarea machetei unui formular poate duce la întârzieri inacceptabile în completarea lui, nu se poate recruta personal suficient pentru operare, se raportează o multime de erori sau poate numărul plângerilor din partea clienților este în creștere;
Managerul a auzit de un sistem informatic eficient ce functionează într-o altă organizație similară și își dorește ceva asemănător pentru propria sa întreprindere;
Pot exista nemulțumiri privind nivelul cheltuielilor indirecte, cum ar fi costul de administrare;
Un reprezentant al unei firme producătoare de calculatoare, al unei firme de service sau al unei case de software îl sfătuiește pe manager să se intereseze de un anumit pachet de aplicații sau un sistem;
Poate fi o reacție a organizației, de modificare a obiectivelor sale ca răspuns la modificarea unor factori externi.
Anterior inițializării proiectului se poate desfășura o mică analiză formală a sistemului existent sau a posibilelor alternative de realizare a altui sistem.
Atât analiza cât și proiectarea sunt activități iterative, fiind recomandată o revizuire continuă a nivelului de înțelegere a etapelor anterioare, astfel încât pe ansamblu să sporească nivelul de întelegere al întregului proces de proiectare. Pentru a surprinde acest aspect de reluare a etapelor cumponente ale ciclului de viață al unui sistem economic se poate recurge la o reprezentare, după cum urmează:
Fig.2 Ciclul de viață al unui sistem informatic
4.1.5. Managementul activităților de realizare a sistemelor informatice
Varietatea, multitudinea și complexitatea activităților de realizare a sistemelor informatice, durata mare de desfășurare, volumul important de resurse implicate și caracterul colectiv al muncii de realizare, implicând diviziune, colaborare și cooperare se constituie ca argumente ale necesității managementului întregii acțiuni de realizare a sistemelor informatice.
Conducerea activității de realizare a sistemelor informatice se refera la totalitatea acțiunilor de asigurare a condițiilor de desfășurare corespunzătoare a acestei activități și de utilizare a resurselor, în scopul atingerii obiectivelor propuse.
Principalele tipuri de acțiuni implicate de conducerea activității de realizare a sistemelor informatice sunt:
Planificarea fazelor operațiilor, prin estimarea necesarului de resurse și mijloace, stabilirea modului de alocare a acestora, precum și a termenelor intermediare și finale;
Organizarea generală a activității, prin stabilirea metodologiei, organizarea colectivelor și defalcarea sarcinilor, atribuțiilor și responsabilităților colective și individuale, stabilirea structurii și conținutului documentației precum și organizarea comunicării în cadrul colectivului și cu exteriorul;
Urmărirea permanentă a stadiului realizărilor, a termenelor, a respectării metodologiei și a indicatorilor consumurilor de resurse, în vederea colectării operative a abaterilor;
Controlul riguros al performanțelor componentelor intermediare și al sistemului în ansamblu, în conformitate cu un set de criterii, norme și standarde prestabilite, prin măsurare, evaluare și validare;
Luarea deciziilor după fiecare operație de urmărire și control pentru a stabili modul de continuare a procesului de realizare a sistemului informatic.
4.1.6. Obiectivele proiectării
Proiectarea de sistem se dezvoltă având la baza obiectivele stabilite pentru sistemul informațional în Raportul de fezabilitate. În orice caz atingerea obiectivelor imediate ale întreprinderii este numai o fațetă a problemei, întrucât trebuie luate în considerare și o serie de caracteristice ale unei proiectări de calitate, relevante pentru orice aplicație.
Urmatoarea listă menționează câteva dintre caracteristicile de bază ce trebuie să caracterizeze sistemul rezultat în urma unui proces de analiză – proiectare eficient:
a) funcționalitatea – sistemul trebuie să răspundă cu succes la toate cerințele utilizatorilor. Modelele de proiectare trebuie să rafineze continuu nivelul de înțelegere al sistemului cu scopul minimizării părții din sistem greșit înțeleasă. Erorile sunt mai ușor și mai ieftin de corectat în modele decât în programe.
b) eficiența – aceasta semnifică rezolvarea cerințelor funcționale în timp util. Există trei perspective din care trebuie judecat acest obiectiv:
capacitatea fluxului: abilitatea de a manevra un anumit număr de documente pe oră sau zi;
timpul de răspuns: abilitatea de a răspunde unei cereri informaționale într-un timp limită dat;
timpul de rulare: abilitatea de a desfășura un întreg proces de prelucrare într-un timp limită dat.
Eficiența ar trebui extinsă și asupra utilizării efective a resurselor de personal. Pentru majoritatea organizațiilor costul personalului implicat în Sistemul Informațional / Informatic deține ponderea cea mai semnificativă a cheltuielilor implicate de această activitate. Acești angajați trebuie deci utilizați efectiv și puși să creeze valoare pentru banii primiți.
c) flexibilitatea – organizațiile se caracterizează printr-un mare dinamism. Ele sunt afectate de creșteri interne și diferite politici, de concedieri / demisii și numiri de personal, de restructurări și reorganizări, de preluări externe, de contracte și presiuni externe, de variații ale preferințelor și comportamentului consumatorului, de recesiunea economică și dogma politică. În consecință sistemele informatice trebuie să fie ușor de adaptat cerințelor noi și în continuă schimbare.
d) portabilitatea – este stâns legată de independență. Rata ridicată a evolutiei tehnologice face ca investițiile în sistemele existente să fie eficiente numai dacă proiectantul a luat măsuri efective pentru ca transferarea sistemului de pe un calculator pe altul să nu necesite decât intervenții minime de conversie. Sistemele astfel construite asimilează cu ușurință avansul tehnologic, nerespingându-l pe motivul “costului implicat de re-scriere”.
e) securitatea – datele reprezintă una dintre resursele cele mai valoroase, mai ales sub aspectul dificultății obținerii, astfel încât orice sistem ce colectează și prelucreză date trebuie să asigure în primul rând și protecția acestora de “priviri indiscrete” / împotriva oricărui atac la adresa confidențialității acestora.
f) integritatea – este o altă trasatură a unei bune proiectări. Parkin descrie integritatea datelor ca fiind atunci când “toate datele necesare sunt inregistrate cu acuratețe, fără omisiuni, și stocate în siguranță pe un calculator, astfel încât acestea nu se pot altera sau pierde în mod accidental sau deliberat”. Un astfel de sistem trebuie să fie fiabil, să reflecte în mod exact realitatea, fără erori și deasemenea trebuie să fie capabil a demonstra aceste calități ale sale oricărui auditor intern sau extern ce are responsabilitatea de a verifica validitatea sistemului.
g) economic – necesitatea unei proiectări care să asigure minimizarea spațiului necesar pentru stocarea datelor și a programelor a devenit cu timpul o cerință mai puțin importantă datorită scăderii costurilor echipamentelor hard. Totuși, minimizarea redundanței datelor reduce problemele legate de modificarea, inserarea și ștergerea a datelor.
h) ușor de utilizat – o metodologie de proiectare poate fi apreciată și în funcție de ușurința cu care poate fi învățată și aplicată în limita unor nivele acceptabile de disconfort, oboseală și efort uman. S-a sugerat de către Sackel în 1986 că procesul de proiectare trebuie să fie:
centrat pe utilizator / beneficiar;
participativ;
experimental;
iterativ;
prietenos / însoțit de explicații ajutătoare.
Un sistem ușor de utilizat poate fi definit ca un sistem care este nu numai prietenos (user friendly) dar și natural (feels normal to use).
i) ușor de întreținut – natura dinamică a unei întreprinderi presupune o inevitabilă schimbare a cerințelor în timp. Aceste schmbări trebuie să fie ușor de operat și în cadrul sistemului, iar efectul implementării lor trebuie să fie ușor de înțeles. Metodologiile de proiectare calitative sunt simple și modulare, astfel încât schimbarea este minimizată și predictibilă. Întreținerea este ușurată prin existența unei documentații complete și exacte a sistemului.
4.1.7. Metodologii de realizare a sistemelor informatice
Realizarea sistemelor informatice reprezintă o acțiune complexă, care îmbină un număr mare de activități eterogene ( de analiză, de proiectare, de programare, implementare și exploatare), cu un pronunțat caracter creativ și la care cooperează mai multe unități organizatorice. În plus, reclamă resurse umane, materiale și financiare însemnate, pe o perioada considerabilă de timp. Folosirea eficientă a acestor resurse, în scopul obținerii unui sistem informatic performant a impus ordonarea acestui proces complex într-o succesiune bine stabilită de etape și subetape și utilizarea unor metode și tehnici adecvate. Acest lucru a dus deci, la conturarea unor metodologii de realizare a sistemelor informatice.
Între diversele etape de realizare a sistemelor informatice există o legătură indestructibila, legătură reflectată și de faptul că, în mod logic și practic calitatea realizării unor activități din etapele și fazele precedente, influențează în mod direct calitatea activităților din etapa ce îi urmează. O altă caracteristică comună a acestor etape și activități este aceea că trecerea de la o etapa la alta (chiar și de la o faza la alta în cadrul aceleiași etape) se face numai după o analiză de fond a modului de realizare a sarcinilor etapei parcurse și a avizării rezultatelor obținute de către factorii de răspundere ai beneficiarului și ai proiectantului.
Totodată, fiecare etapă parcursă se încheie cu activități privind pregătirea condițiilor de desfășurare a activităților care urmează și anume: detalierea, actualizarea și aprobarea planului de lucru pentru etapa următoare, precum și actualizarea planului pentru restul etapelor ce au rămas a fi parcurse. Acest mod de planificare a activității de realizare a sistemelor informatice pleacă de la faptul că după parcurgerea unei etape se cunoaste mult mai mult și mai concret ceea ce trebuie să se realizeze în etapa următoare.
Metodologiile de realizare a sistemelor informatice cuprind:
modalitatea de abordare a sistemelor, pentru elucidarea raportului întreg-părți și a raportului dintre variațiile sistemului și dinamismul său;
regulile de formalizare a datelor și a proceselor de prelucrare;
instrumentele pentru concepția, realizarea și elaborarea documentației;
modalitatea de derulare a proiectului și acțiunile specifice fiecărei etape (ciclul de viață);
definirea modului de lucru, al rolului analiștilor și proiectanților și a raportului dintre ei;
modalitățile de administrare a proiectului (planificare, programare, urmărire).
Totodată metodologiile au rolul de a indica modul de desfășurare a acestui proces, stabilind:
componentele procesului de realizare a sistemului informatic (etape, subetape, activități și operații) și conținutul lor;
fluxul parcurgerii (executării) componentelor;
metodele, tehnicile, procedeele, instrumentele, normele și standardele utilizate.
Astăzi există metodologii cadru, cu scop orientativ general, având semnificația unor indicații metodologice, cu caracter facultativ, sau al unor norme metodologice cu caracter obligatoriu. Pe de altă parte există metodologii proprii unor firme producătoare de echipamente de calcul sau sisteme informatice.
In funcție de modul de abordare și domeniul de aplicabilitate, metodologiile utilizate sunt:
metodologii din domeniul gestiunii;
metodologii orientate obiect;
metodologii pentru conducerea proiectelor de sisteme informatice.
Cele mai semnificative metodologii din domeniul gestiunii sunt: AXIAL (firma IBM), MERISE (Ministerul industriei – Franta), IE (James Martin), DA (Universitatea Michigan), SSADM (Marea Britanie).
Metodologiile orientate obiect se bazeaza în formalizarea sistemelor pe noțiunea de obiect (entitate pentru date și acțiune pentru procese). Dintre cele mai semnificative sunt: OMT (General Electric SUA), OOD (SUA), ISD (Michael Jackson).
Metodologiile pentru conducerea proiectelor de sisteme informatice se utilizeaza pentru elaborarea sistemelor intr-o concepție științifică. Dintre acestea enumeram: SDM / S, METHOD /1 – Arthur Andersen, NAVIGATOR (Ernst & Young – James Martin).
În prezent metodologiile clasice de proiectare pierd vizibil teren, înregistrându-se o preocupare deosebită pentru adoptarea unui standard în domeniul analizei-proiectării orientate obiect datorită avantajelor deosebite ale acesteia.
Este în general acceptat faptul că lumea reală poate fi aproximată utilizând trei modele diferite. Primul dintre acestea este modelul structural sau al obiectelor, acesta descriind obiectele din cadrul sistemului și relațiile structurale dintre acestea. Al doilea model este modelul dinamic, responsabil cu descrierea acelor aspecte ale sistemului care se modifică în timp. Ultimul dintre modele este cel funcțional, sau al proceselor, acesta descriind transformările valorilor datelor și calculele sistemului. Fiecare model poate fi studiat independent de celelalte două, acestea urmând a fi combinate în vederea treceriila faza de proiectare a sistemului.
Dintre metodologiile propuse menționăm metodologia Rumbaugh sau OMT, metodologia Booch, metodologia Jacobson. OMG a adoptat ca standard o colecție de metode și tehnici propuse de cei de la Rational (Booch, Rumbaugh și Jacobson) sub denumirea de UML – unified modeling language, în octombrie 1996.
Tot mai frecvent întâlnim și în domeniul economic sistemele informatice bazate pe cunostințe, și dintre acestea sistemele expert. În domeniul proiectării unor astfel de sisteme se remarcă o tendință de unificare a metodologiilor de proiectare a Bazelor de date și a Bazelor de cunoștințe. John Debenham prezintă o astfel de metodologie ce unifică modul de reprezentare și de tratare a datelor, informațiilor și cunoștințelor unui sistem bazat pe cunoștințe pe parcursul întregii durate a procesului de proiectare a acestuia.
Un sistem bazat pe cunoștințe conține atât date și informații, cât și cunoștințe. În mod tradițional datele și informațiile sunt modelate și implementate ca baze de date, iar cunoștințele se implementeaza fie printr-un limbaj de de programare (reprezentarea implicită a cunoștințelor), fie intr-un sistem expert (reprezentarea explicită a cunostintelor). Metodologia de proiectare prezentată de John Debenham are două caracteristici importante:
este o metodologie unificată, ceea ce înseamnă că reprezintă datele, informațiile și cunoștințele în mod omogen, ca dealtfel și relațiile dintre acestea
construiește, în cadrul etapei de proiectare, un mecanism de mentenanță al sistemului.
In termenii ingineriei bazate pe cunoștințe, reprezentarea utilizată de această metodologie pentru a modela Bazele de cunoștințe se aplică și Bazelor de date. În termenii Bazelor de date reprezentarea utilizată de aceasta metodă pentru a modela Bazele de Date se aplică și Bazelor de Reguli.
In ceea ce privește unificarea proiectării componentei Baza de cunoștințe și a componentei Baza de date, aceasta se realizează din cinci puncte de vedere:
în timpul procesului de proictare se realizeaza patru modele și toate aceste patru modele reprezintă date, informații și cunoștințe în mod unificat;
formele de reprezentare utilizate pentru date, informații și cunoștințe intr-un model sunt corelate cu reprezentările utilizate în următorul model;
suprastructura celor patru modele e unificată;
restricțiile sunt utilizate generalizat, fiind incluse și restricții pentru cunoștințe;
termenul de normalizare este utilizat cu un sens mai general decât normalizarea bazei de date; în Metodologia Unificată există un principiu de nomalizare aplicat atât datelor cât și cunoștințelor. Acest principiu este o generalizare netrivială a normalizării clasice a unei baze de date.
Metodologia Unificată construiește un mecanism de intreținere a sistemului, considerând că într-o reprezentare unificată se poate atinge o cea mai buna analiză a mentenanței sistemului. Majoritatea metodologiilor de proiectare a sistemelor expert, inclusiv KADS, tratează separat Baza de reguli și nu au în vedere întreținerea în mod analitic a Bazei de date. Dacă aceste două componente sunt reprezentate și tratate separat atunci eventualele relații intre elemente ale Bazei de cunoștințe și elemente ale Bazei de date nu pot fi reprezentate și manipulate cu ajutorul modelelor rezultate.
In ceea ce privește mentenanța se pun două mari probleme: fie proiectarea unui model ușor de intreținut printr-un mecanism de moștenire, fie controlul întreținerii unui model dat. Metodologia Unificat are în vedere prima variantă, realizând din etapa de proiectare un mecanism de mentenanță.
Metodologia cuprinde patru pași de proiectare, în urma fiecăruia dintre aceștia obținându-se câte un model.
Un prim pas îl reprezintă specificarea cerințelor (requirements specification) în urma căruia se construiește Modelul Cerințelor. În această etapă se precizează ce trebuie să poată face sistemul, în urma parcurgerii a două subetape: descrierea aplicației și identificarea cerințelor.
Al doilea pas îl constituie analiza sistemului (System Analysis) în urma căruia se elaborează Modelul Conceptual care specifică cum va face sistemul ceea ce i se cere. Aceasta este o reprezentare completă a cunoștințelor cerute de sistem, adoptând o forma unificată de reprezentare a acestora. Modelul conține o “hartă de cuplare” – structură utilizată ca suport al mentenanței sistemului bazat pe cunoștințe. Specificațiile cu privire la ceea ce ar trebui să poată face sistemul se moștenesc prin legături din modelul cerințelor (întocmit în etapa anterioară).
A treia etapă, funcționarea sistemului (system function) arată cum sunt utilizate cunoștințele din modelul conceptual pentru a obține funcționalitatea specificată în modelul cerințelor. În urma acestei etape se construiește Modelul Funcțional.
Prezentarea sistemului (system layout), este ultima etapă în Metodologia Unificată de proiectare. În cadrul acestei etape se derivează un Model Intern ce servește drept specificație completă a sistemului.
Pentru o prezentare formală a metodologiei (în special în dezvoltarea fundamentelor teoretice ale metodologiei) se folosesc calculele-, iar la aplicarea metodologiei în practică se folosesc niște notații schematice (formă de prezentare informală a metodologiei).
Aplicarea metodologiei se poate face în întregime sau se pot aplica doar parți ale acestei metodologii unificate, integrate în alte metodologii de proiectare.
4.1.8. SSADM – o metodologie structurată de analiză și proiectare a sistemelor. Caracteristici generale
Am menționat anterior necesitatea unei metodologii structurate pentru a organiza cantitatea mare de informații aferentă unui proiect și pentru a înfrânge dificultățile ridicate de complexitatea proiectelor. Multe aplicații informatice sunt atât de mari că un singur om nu poate înțelege detaliile întregului sistem. Soluția o reprezintă descompunerea sistemului într-un anumit număr de subsisteme sau funcții. Mergând mai departe cu descompunerea se ajunge la un asemenea nivel de detaliere încât fiecare componentă poate fi descrisă cu cea mai mare exactitate. SSADM (Structured System Analysis and Design Methodology) structurează o serie de tehnici binecunoscute intr-o metodologie ușor de înțeles și aplicat.
Dintre caracteristicile cele mai importante ale metodologiei se enumeră :
a fost elaborată în Marea Britanie și promovată de guvernul britanic pentru realizarea sistemelor informatice din domeniul public;
este orientată pe structurarea datelor;
pune în evidentă două tipuri de modele: modelul logic și modelul fizic al sistemului ( separă proiectarea logică de cea fizică )
se bazează pe specificarea clară a cerințelor și a unor reguli detaliate pentru construirea celor două modele;
face apel la reprezentarea fluxurilor, datelor și prelucrărilor cu ajutorul diagramelor.
SSADM debutează cu organizarea notițelor din etapa de investigare a sistemului existent și se incheie cu elaborarea specificațiilor proiectarii de detaliu pentru echipa de implementare. Ea nu include o etapa de investigare sau de implementare. Faza de investigare se bazează pe tehnici comune multor situații cum ar fi tehnica interviului, tehnica chestionarului și altele. Implementarea începe cu etapa de programare și cea de testare pentru care există tehnici structurate bine cunoscute. SSADM vine să implinească golul dintre investigare și implementare. Ea nu se concentrează pe o anumita tehnică, ci constă din aplicarea mai multor tehnici, fiecare dintre ele fiind aleasă ca fiind cea mai nimerită pentru îndeplinirea unei activități.
Iată o scurtă descriere a unora dintre cele mai importante metode și tehnici utilizate de SSADM:
diagramele de flux de date care arată granițele sistemului și relațiile sale cu mediul. Ele reprezintă deasemenea și funcțiile, stocurile de date, intrările și ieșirile din sistem;
matricea de asociere entitate / funcție, arată entitățile afectate de fiecare funcție;
modelele entitate prin care se reprezintă structurile de date și relațiile între acestea;
istoricul entității, furnizează o viziune dinamică a sistemului, arătând cum este afectată fiecare entitate de către funcțiile sistemului și succesiunea în care se execută funcțiile;
descrierea proceselor prin care se specifică operațiile necesare pentru a realiza o tranzacție în sistem și care conduc în final la elaborarea specificațiilor de programare.
Normalizarea este una din tehnicile de bază utilizată în proiectarea logică a datelor. Acest proces de transformare a structurilor complexe de date în structuri simple este utilizat aici pentru identificarea entităților și pentru crearea modelului entitate, care se poate compara cu modelul entitate construit în faza de analiză.
SSADM include un set integrat de documente ce susțin metodologia. Prezentarea acestor documente beneficiarului reprezintă o parte formală a metodologiei SSADM prin care se asigură controlul calității și monitorizarea evoluției proiectului.
4.1.9. Etapele de realizare a sistemelor informatice conform SSADM
a) studiul de fezabilitate -etapa este indicată pentru sisteme complexe și foarte severe sub aspectul cerințelor și performanțelor de realizat. În cadrul studiului de fezabilitate se caută să se faca o primă evaluare a sistemului existent și să se definească o soluție de principiu pentru realizarea sau dezvoltarea sistemului informatic.
b) analiza cerințelor sistemului ( analiza sistemului existent) – etapa are ca scop cunoașterea sistemului fizic existent și identificarea problemelor și deficiențelor acestuia. Se recurge la un studiu complex referitor la activitățile și fluxurile informaționale existente, la volumul informațiilor prelucrate și aria de cuprindere a sistemului informatic.
Pe baza acestui studiu se elaborează diagramele de flux de date, parcurgând următorii pași:
întocmirea unei liste a documentelor fizice implicate;
trasarea diagramei fluxului documentelor;
verificarea fluxului documentelor;
elaborarea diagramelor de flux de date prin enumerarea și detalierea proceselor.
Pe baza studiului realizat se recurge la analiza sistemului pentru a fundamenta direcțiile de perfecționare și modernizare ale sistemului existent și înlocuirea lui cu un sistem care să permită satisfacerea tuturor cerințelor informaționale necesare conducerii.
c) specificarea cerințelor sistemului – activitățile din cadrul acestei etape se realizează în mai mulți pași:
se inlatură deficiențele referitoare la organizarea sistemului existent;
se construiește un model al noului sistem prin modificarea diagramelor de flux de date logice și a structurii logice a datelor;
se construiește un catalog al cerințelor și al entităților, iar pentru fiecare entitate se prezintă evoluția în timp a acesteia.
d) specificarea sistemului logic – în cadrul acestei etape se recurge la selectarea opțiunilor tehnice pe care le prezintă beneficiarul. Opțiunea selectată este descrisă precizând:
detalii tehnice referitoare la hardware și software;
modul de lucru al sistemului;
costurile implicate.
Beneficiarii vor da informații referitoare la posibilitățile de perfecționare, intreținere și dezvoltare ale sistemului. În urma aprobării de către beneficiar se va trece la proiectarea locica de detaliu a datelor și a prelucrarilor. Proiectarea datelor va duce în final la definirea entităților ce vor constitui baza informațională de intrare. Proiectarea procedurilor se face elaborând mai multe schițe detaliate ale proceselor. Proiectarea datelor și procedurilor se realizează în paralel și se intercondiționează permanent.
e) proiectarea fizică – în cadrul acestei etape se ajunge la realizarea modelului fizic al datelor și prelucrărilor, precum și la elaborarea programelor. La sfârșit se redactează documentația pe baza căreia se elaborează planul de realizare și testare a sistemului.
4.1.9.1 Analiza sistemului existent
Această etapă are ca scop cunoașterea sistemului fizic existent și identificarea problemelor și deficiențelor acestuia. Pentru aceasta se recurge la un studiu complex privind activitățile și fluxurile informaționale existente, volumul informațiilor prelucrate și aria de cuprindere a sistemului informational. Pe baza acestui studiu se elaboreazã diagramele de flux de date (DFD) parcurgând urmãtorii pasi:
întocmirea unei liste a documentelor fizice implicate;
trasarea diagramei fluxului documentelor;
verificarea fluxului documentelor;
elaborarea primului nivel al DFD prin enumerarea proceselor (activitãtilor) care vor fi realizate pentru fiecare document și includerea acestuia în diagrame;
Pe baza studiului realizat, se recurge la analiza sistemului informațional pentru a fundamenta direcțiile de perfecționare și modernizare ale sistemului existent și posibilitățile de realizare a unui sistem informatic, care sã permitã satisfacerea tuturor cerințelor informaționale necesare conducerii.
În cadrul acestei etape se face analiza propriu-zisă a sistemului existent conform metodologiei S.S.A.D.M. Etapa are ca scop cunoașterea sistemului fizic existent și identificarea problemelor și deficiențelor acestuia. Pentru aceasta se recurge la un studiu complex privind activitățile și fluxurile informaționale existente, volumul informațiilor prelucrate și aria de cuprindere a sistemului informational.
Pe baza studiului din etapa de investigare a sistemului existent se elaboreazã diagramele de flux de date (DFD) parcurgând urmãtorii pași:
întocmirea unei liste a documentelor fizice implicate;
trasarea diagramei fluxului documentelor;
verificarea fluxului documentelor;
elaborarea primului nivel al DFD prin enumerarea proceselor (activitãtilor) care vor fi realizate pentru fiecare document și includerea acestuia în diagrame;
Pe baza studiului realizat, se recurge la analiza sistemului informațional pentru a fundamenta direcțiile de perfecționare și modernizare ale sistemului existent și posibilitățile de realizare a unui sistem informatic, care sã permitã satisfacerea tuturor cerințelor informaționale necesare conducerii.
4.1.9.2.Modelul fizic al sistemului existent
Acest model relectă structura tehnică și operațională a sistemului și descrie cum funcționează sistemul în implementarea lui actuală. El este primul model ce se realizează deoarece înainte de a parcurge orice etapă din metodologie este nevoie să avem posibilitatea de identifica toate funcțiunile existente ale sistemului.
Primul model care se întocmește este cel al prelucrărilor, în care se evidențiază modul de derulare a fluxului informațional în sistemul existent.
În diagramele de flux ale datelor sunt evidențiate funcțiunile sistemului într-o manieră de descompunere TOP-DOWN, realizată printr-un proces de rafinare succesivă a proceselor de prelucrare. În diagrama de nivel zero sunt puse în evidență cât mai riguros fluxurile de intrare și de ieșire ale sistemului, urmărindu-se punerea în evidență a ariei de cuprindere a sistemului. Sistemul apare ca o cutie neagră și se pune accentul pe evidențierea interacțiunilor sistemului cu mediul extern. Diagrama de nivel zero poartă numele de diagrama contextuală , celelalte nivele obținându-se prin rafinarea proceselor complexe într-o diagramă de nivel inferior.
DFD este o reprezentare graficã a transformãrii datelor de intrare în date de iesire.
DFD folosește un set de simboluri de reprezentare și are asociat un set de reguli de completare și validare.
Simboluri :
– proces (transformare): Procesele sunt etichetate cu text ce sugereazã modul de transformare a datelor și sunt identificate printr-un numãr. În DFD fizicã pentru sistemul existent, se va preciza și locatia (compartiment / persoanã) procesului.
– flux de date: este constituit din datele transmise între douã procese. Fluxul de date e etichetat printr-un substantiv ce sugereazã informatia sau pachetul de informatii transmise.
– entitate externã (terminator): sursã / receptor de date. Poate fi un alt sistem (organizatie, compartiment)
– stoc de date: un depozit temporar sau permanent de date. Acesta poate fi manual (registre, dosare, arhivã de documente) sau pe suport magnetic: fisiere.
Convenții:
– procesele și stocurile de date sunt numerotate secvențial, pentru a putea fi identificate. Numerele asociate proceselor nu semnificã ordinea de execuție a acestora;
– pentru a evita fluxurile de date întretãiate și aspectul de "pãienjeniș" al diagramei, entitãțile externe și stocurile de date pot fi duplicate. O entitate externã duplicatã se reprezintã prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentarã verticalã în partea stângã a cutiei;
– pentru a face diagramele mai lizibile, entitãtile externe sunt plasate, pe cât posibil, în jurul diagramei iar stocurile de date, în partea centralã a diagramei;
– pentru mai multã claritate, într-o DFD nu se vor reprezenta mai mult de 9 procese;
– fluxurile de date de la – către stocurile de date sunt unidirectionale (fie de adãugare, fie de consultare) și nu sunt etichetate.
4.1.9.3. Descompunerea funcționalã și rafinarea DFD
Dacã sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil sã realizãm de la început o DFD detaliatã. Pentru a putea descrie în detaliu sistemele complexe, metodele structurate propun o abordare TOP -DOWN, respectiv o descompunere funcționalã a sistemului, care e realizatã prin rafinarea succesivã a proceselor.
Primul nivel (nivelul 0) îl constituie diagrama contextuală, care definește granițele între sistemul analizat și mediu. Nivelele urmãtoare se obțin prin rafinarea proceselor complexe într-o diagramã de nivel inferior.
Reguli:
– fiecare proces va fi numerotat corespunzãtor nivelului de descompunere și poziției în cadrul diagramei. Astfel, dacã procesul 2 din diagrama de nivel 1 va fi descompus, procesele de nivel inferior vor fi: 2.1, 2.2., …
– fluxurile de intrare și de iesirre pot fi și ele descompuse în componente:
– o diagramã de pe orice nivel de descompunere nu trebuie sã conținã mai mult de 9 procese;
– descompunerea DFD se poate considera treminatã atunci când ajungem la procese elementare. Procesele elementare sunt marcate în colțul din dreapta jos prin "*".
– pentru procesele elementare se întocmește o descriere sau o speficicație, în general sub formã de text, dar se poate utiliza și pseudocod, scheme logice, tabele de decizie sau chiar cod scris într-un limbaj de programare;
– regula balansului: intrãrile și ieșirile unei diagrame de nivel inferior trebuie sã coincidã cu intrãrile și iesirile procesului pe care-l descompun.
4.2.Descrierea unitatii
4.2.1 Prezentarea unității
numele unității: SC Cross Imobiliare SA
tipul unității: societate pe acțiuni
adresa unității: str. Traian nr. 248, bloc 30B, parter, telefon 210.15.37, fax 212.28.56, București
obiectul de activitate: intermedierea vânzării / cumpărării, respectiv al închirirerii de apartamente din București
sfera de activitate: afaceri imobiliare
servicii oferite:
intermedierea vânzării / cumpărării
intermediere închirieri
cadastru
intabulare
estras de carte funciară
consultanță imobiliară
informații volumetrice:
număr de clienți: 560
tipuri de apartamente tranzacționate: două, trei, patru camere
număr de tranzacții: 40 / lună
rata de satisfacere a cererii: 20 %
rata de satisfacere a ofertei: 35 %
număr de clienți noi: 120 / lună, dintre care 75 ofertanți
procentele acumulate în urma intermedierii cu succes:
3% cumpărător și 3% vânzător în cazul vânzării / cumpărării
50 % din chiria pe prima lună pentru cel care închiriază și 50 %
pentru chiriaș
estimare a stadiului în care se află unitatea: dezvoltare
4.2.2. Cadru organizatoric
Agenția imobiliară este organizată în departamente, acestea fiind: financiar, comercial, personal.
Aceste departamente sunt formate la rândul lor din:
departament economic:
financiar
contabilitate
departament comercial
agenți imobiliari
juridic
departament personal
Astfel rezultă următoarea organigramă a unității:
Fig. 1 Organigrama agenției imobiliare
Departamentele sunt conduse de câte un director( director economic, director comercial). Departamentul personal intră în subordinea directă a directorului general.
Această organigramă pune în evidență o serie de relații între departamente: ierarhice, de colaborare și de reprezentare. Astfel relațiile ierarhice sunt:
Adunarea asociaților – Director general – Director economic – Financiar
– Contabilitate
– Director comercial – Agenți imobiliari
– Juridic
Relațiile de colaborare se manifestă între departamente: economic, comercial și personal.
Relațiile de reprezentare se manifestă numai în relațiile Director General – Departamente și între Adunarea Asociaților – Departamente.
4.2.3. Activitatea de intermediere a locuințelor
Actvitatea de intermediere realizată de agenția imobiliară poate fi descrisă astfel2 :
se contactează furnizorul : se introduc datele cu privire la furnizor. Datele vor fi utile în realizarea contractelor și ulterior în activitatea de întocmire a situațiilor de sinteză și previzionare
se contactează beneficiarul: se introduc datele cu privire la solicitantul de locuințe. Datele vor fi utile în relizarea contractului și ulterior în activitatea de întocmire a situațiilor de sinteză și previzionare
preluare locuințe de vânzare : se introduc informații referitoare la locuința oferită spre tranzacționare, cuprinzând date de identificare, compunere, finisaje, utilități și situația juridică.
întocmire contract de exclusivitate locuințe : se întocmește un contract de reprezentare exclusivă a intereselor ofertantului de locuințe de către agenția imobliară.
preluare cereri pentru locuințe : se introduc informații referitoare la tipul de locuință dorit privind datele de identificare, finisajele, compunerea și utilitățile de care imobilul trebuie să dispună.
compatibilizare cereri de locuințe : se încearcă asocierea între o cerere și ofertele disponibile sau asocierea dintre o ofertă și cererile disponibile. Asocierea dintre o cerere și ofertele disponibile se va face în funcție de criteriile alese de beneficiar.
compatilizare oferte locuințe : criteriile de compatibilizare a unei oferte cu cererile disponibile sunt alese la nivelul agenției imobiliare pe baza experienței acumulate.
întocmire fișă de vizionare : se generează contractul de vizionare care cuprinde o ofertă și cererile compatibile. Acestă fișă urmează a fi completată după vizionarea proprietății oferite de către unul dintre beneficiarii din fișă.
întocmire antecontract : se întocmește antecontractul. Acest eveniment intervine în momentul în care un beneficiar și un furnizor se înțeleg în privința tranzacționării unei proprietăți. Antecontractul va stipula drepturile și obligațiile fiecăruia dintre părți. Aceste antecontracte vor fi stocate ulterior într-un depozit de date.
întocmire contract vânzare / cumpărare : se generează cntractele de vânzare / cumpărare sau, în funcție de opțiunea părților, contractele de închiriere. Acest proces se derulează pe baza datelor existente ăn ofertele și cererilede locuințe. Datele cuprinse în contracte, precum și informațiile necesare întocmirii situațiilor de sinteză sunt păstrate ăn depozitul de date denumit contracte locuințe, pepozit care joacă și rolul de arhivă a tranzacțiilor încheiate.
actualizare stocuri de date : se vor șterge din depozitele de oferte și cereri, precum și din cele de antecontracte și contracte de vizionare toate înregistrările care privesc oferta și cerea pentru care se încheie contractul de vânzare / cumpărare.
întocmire contract comosion vânzător : se întocmesc contractele de comision pe baza pe baza contractelor de vânzare / cumpărare sau a contractelor de închiriere încheiate pentru locuințe.
întocmire contract comision cumpărător : se întocmesc contractele de comision pe baza pe baza contractelor de vânzare / cumpărare sau a contractelor de închiriere încheiate pentru locuințe.
întocmire situații de sinteză : se întocmesc situațiile de sinteză care servesc la analiza activității agenției imobiliare și la efectuarea de previziuni asupra evoluției pieței pe termen scurt și mediu. Acest proces se desfășoară pe baza contractelor încheiate de agenție.
În diferite faze ale modelării procesului de intermediere imobiliară se utilizează date cu privire la clienții agenției imobiliare și cu privire la obiectul tranzacțiilor reprezantat de proprietățile imobiliare. Fluxurile care apar pe parcursul procesului de intermediere sunt fluxuri de date.
Pentru această etapă a analizei nu ne interesează informațiile detaliate pe care le cuprind aceste depozite.acestea vor fi detaliate în diagrama entităților în care acestea vor lua forma unei entități.
Vând în vedere toate qcestea, putem construi diagrama proceselor de intermediere a locuițelor.
4.2.4 Modelarea entităților și asocierilor dintre acestea
Din diagrama proceselor de intermediere a locuițelor s-au comstituit următoarele depozite de date:
beneficiari
furnizori
oferte locuințe
cereri locuințe
antecontracte locuinșe
contracte locuințe
oferte compatibile
cereri compatibile
Aceste depozite de date vor deveni entități primare ale activității de intermediere a tranzacțiilor cu locuințe. Relațiile dintre entitățile modelului entitate asociere sunt următoarele :
fiecare beneficiar poate emite una sau mai multe cereri de locunțe, iar o cerere de locuință trebuie emisă de un singur beneficiar
fiecare furnizor poate emite una sau mai multe oferte de locunțe, iar o ofertă de locunță trebuie emisă de un singur furnizor
o cerere de locuință poate fi inclusă într-un singur antecontract de locuințe, iar un antecontract de locuințe trebuie să includă o cerere de locuință
o ofertă de locuință poate fi inclusă într-un singur antecontract de locuințe, iar un antecontract de locuințe trebuie să includă o ofertă de locuință
o cerere de locuință poate fi inclusă într-un singur contract de locuință, iar un antecontract de locuință trebuie să includă o cerere de locuință
o ofertă de locuință poate fi inclusă într-un singur contract de locuință, iar un contract de locuințe trebuie să includă o ofertăde locuințe
o ofertă de locuință poate corespunde unei singure ofertecompatibile de locuință, iar iar ofertele compatibile de locuințe pot să aibă corespondent o ofertă de locuință
o cerere de locuință poate corespunde unei singure cereri compatibile de locuință, iar cererile compatibile de locuințe pot să aibă corespondent o cerere de locuință
Ssitemul trebuie să îndepliească următoarele funcții:
Fig.3 Funcțiile sistemului
Pentru îndeplinirea funcțiilor, în sistem trebuie să existe următoarele fluxuri de date, prezentate în diagrama de mai jos
Având în vedere aceste legături, putem schița modelul enitate – asociere pentru activitatea de intermediere locuințe. În cazul defață fiecărei entități i s-a asociat o tabelă:
beneficiari conține datele referitoare la cumpărătorul de locuințe, codb fiind și cheie externă în tabela contracte
furnizori conține datele referitoare la cumpărătorul de locuințe, codf fiind și cheie externă în tabela contracte
compatibilizare conține codurile cererilor și ofertelor considerate ca fiind compatibile, legătura cu tabelele oferte locuințe și cereri locuințe realizându-se prin cele două coduri: codof și codc( cod ofertă, respectiv cod cerere locuință)
oferte locuințe conține datele referitoare la o ofertă de locuință, codof fiin și cheie externă în tabela compatibilizare și ăn tabela contracte
cereri locuințe conține datele aferente unei cereri de locuință, codc fiind și cheie externă în tabela compatibilizare
contracte conține datele codurile de identificare a vânzătorului și al cumpărătorului, precum și date aferente actului de vânzare cumpărare în sine
antecontracte conține tabele aferente unui antecontract și cheia de identificare a ofertantului de locuință
Capitolul V
Gestiunea aplicatiei
Aplicația are la bază un sistem de daze de date multimedia. Evident că pe piață există mai multe astfel de sisteme( Microsoft SQL 2000 Server, Microsoft Desktop Engine etc.), insă cel care se pretează cel mai bine la o astfel de aplicație este sistemul de baze de date ORACLE.
Interfața aplicației a fost dezvoltată în Visual Basic .Net 2003, acest limbaj oferind o multitudine de facilități printre care se enumeră :
support pentru moștenire din orice clasă
posibilitatea unui copil de modifica metode ale părintelui
support pentru tratatrea erorilor
posibilitatea de adefini interfețe în mod direct și explicit
multithreading complet
support pentru proprietăți și evenimente
colectarea reziduurilo
ADO.Net care permite accesul aplicațiilor la baze de date prin drivere de conectare la orice sistem de baze de date : Microsoft SQL 2000 Server, Microsoft Desktop Engine, Micosoft Access și nu în ultimul rând ORACLE.
permite dezvoltarea de aplicații care să lucreze într-o rețea de calculatoare
permite accesul concurent a mai multor utilizatori la aceeși bază de date.
Chrystal Reports ce permite dezvoltarea rapidă de rapoarte având ca furnizor de date fie direct tabelele din baza de date, fie date venite din prelucrări( de xexmplu datele dintr-un DataSet).
Interfața aplicației este una prietenoasă și foarte intuitivă din punct de vedere al corelațiilor logice. Videoformatul de început al aplicației conține meniul aplicației, care este compus din: introducere date ofertă și date aferente ofertantului, introducere date cerere de locuință și date aferente celui care face această cerere, compatibilizare cereri și oferte, mișcarea soarelui la diferite ore ale zilei în raport cu schița apartamentului, diverse raportări, emitere de contracte( între furnizor și cumpărător) și antecontracte( între agenția imobiliară și ofertant pe o perioadă determinată) și, nu în cele din urmă, meniul de administrare a serviciilor ORACLE( pornirea și oprirea acestora știut fiid faptul că acesta este mare consumator de resurse) și de salvare a bazei de date( back up).
Se vor descrie în continuare aceste module ale aplicației.
Videoformatul oferte locuințe se utilizează pentru înregistrarea ofertelor de locuințe. Cu ajutorul opțiunilor existentese pot adăuga, modifica sau șterge oferte de locuințe, precum și datele aferente celui care oferă locuința spre tranzacționare. Această pagină surprinde totodată, informațiile referitoare la amplasarea locuinței, intențiile furnizorului în ceea ce privește vânzarea, închirierea și prețul sau chiria cerută de acesta. Codul ofertei este numărul de înregistrare al ofertei. Pe lângă toate aceste informații mai este posibilă și introducerea de imagini aferente locuinței ce urmează a fi tranzacționată ( spre exemplu schița apartamentului – releveul, precum și poze ale interiorului apartamentului), acestea fiind stocate în baza de date în câmpuri de tip BLOB( Binary Large Object).
Pentru inserarea acestor poze( schițe) a fost necesară scrierea unei proceduri stocate de forma următoare:
Create or replace procedure imagine (idi in number, im in blob )
as
begin
insert into poze(idof,poza) values(idi,im);
end;
unde variabilele idi( de tip numeric) și im( de tip BLOB) sunt variabile de intrare, transmise acestei proceduri din codul executabil Visual Basic.Net. Pentru conversia imaginii latipul de dată BLOB a fost necesară scrierea următoarei proceduri( aceasta realizează și conversi și trimite parametrii procedurii stocate “Imagine”):
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim ms As New System.IO.MemoryStream
pb.Image.Save(ms, pb.Image.RawFormat)
Dim image() As Byte = ms.GetBuffer
Dim lungime As Long
lungime = image.Length
ms.Close()
conn.Open()
Dim com As New OracleClient.OracleCommand("IMAGINE", conn)
com.CommandType = CommandType.StoredProcedure
Dim param_id As New OracleClient.OracleParameter("idi",OracleClient.OracleType.Int32)
Dim param_im As New OracleClient.OracleParameter("im",OracleClient.OracleType.Blob)
com.Parameters.Add(param_id).Direction = ParameterDirection.Input
com.Parameters.Add(param_im).Direction = ParameterDirection.Input
Dim nr As Integer = TextBox1.Text
param_id.Value = nr
param_im.Value = image
Try
com.ExecuteNonQuery()
Catch ex As Exception
MsgBox(ex.Message)
End Try
Videoformatul cereri locuințe se utilizează pentru înregistrarea solicitărilor de locuințe. Cu ajutorul opțiunilor existente, se pot adăuga, modifica sau șterge cereri de locuințe. Totodată, surprinde informațiile referitoarea la amplasarea locuinței, intențiile beneficiarului în ceea ce privește vânzarea, închirierea și prețul sau chiria oferite de acesta. Codul cererii este numărul de înregistrare este numărul de înregistrare a solicitării.
Videoformatul de compatibilizare se utilizează la găsirea cererilor compatibile cu o ofertă nouă sau aflată în evidența agenției imobiliare.
În partea superioară sunt date referitoare la oferta de locuință, inclusiv pozele sau schițele aferente ofertei, care sunt citite din baza de date.
Procedura de regăsire a pozelor aferente ofertei este următoarea :
Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
Dim rp As Integer
Dim dsmain1 As New DataSet
rp = CType(Me.BindingContext(dsmain1, "Main").Position, Integer)
Dim arrPicture() As Byte = CType(dsmain1.Tables("pictures").Rows(rp)("picture"), Byte)
Dim ms As New System.IO.MemoryStream(arrPicture)
pb.Image = Image.FromStream(ms)
End Sub
Acesta permite navigarea atat prin oferte, cât și prin cereri.
În partea inferioră a videoformatului sunt datele de identificare a cererilor preluate, date stocate în tabela “cereri _locuințe”.
Butonul de compatibilizare asociază o cerere unei oferte, oferind în continuare posibilitatea încheierii antecontractului de vânzare – cumpărare.
acesta incluzînd prețul negociat de cele două părți, procentul aferent agenției imobiliare fiind introdus în tabela comisioane, sub forma a două linii( căte una aferentă fiecărei părți – furnizor și beneficiar). Butonul de emitere realizează afișarea antecontractului cu posibilitatea de printare( acesta a fost construit folosind Crystal Reports).
Aplicația astfel construită permite gestiunea unei agenții imobiliare, punctul pe care s-a insistat mai mult fiind posibilitatea de stocare a imaginilor, aspect foarte important într-o afacere imobiliară, scutind foarte mult timp din partea agenților imobiliari și redând astfel o imagine clară a ceea ce se oferă spre tranzacționare.
Capitolul VI
Calitate software
6.1 Particularități ale calității produselor software
Dacã societatea contemporanã este o societate a calitãții, atunci ea este în aceeași mãsurã o societate a informației și a tehnologiei informației.
În industria de software, întâlnim aceeași concentrare pe produs a concepției, execuției, asigurãrii și verificãrii calitãții, ca în faza preindustrialã, dar, pe de altã parte, datoritã complexitãții produsului rezultat, existã grupul de executanți, împãrțit în colective sau indivizi specializați, care acționeazã pe parcursul unor înlãnțuiri de faze (ciclu de viațã). Modelul de producție în industria software este un model de “producție a proiectelor”. Particularitatea producției de software rezidã în faptul cã activitãțile desfãșurate pot fi specifice unei anumite faze a ciclului de viațã, sau pot fi independente de fazele ciclului de viațã.
Importanța calitãții produselor software rezidã în cel puțin trei aspecte: erorile din programele de aplicație pot fi fatale în anumite domenii unde viețile oamenilor depind de acestea; aceste erori pot provoca pierderi financiare, materiale și tot felul de alte tipuri de insatisfacții sau pierderi; dacã în domeniul produselor hardware costurile au o tendințã generalã de scãdere, în domeniul dezvoltãrii de software, deși productivitatea a crescut substanțial, nu se înregistreazã și o scãdere a costurilor care sã ducã la aceeași tendințã.
Acest ultim aspect se datoreazã particularitãților prin care calitatea se manifestã în domeniul produselor software, așa cum sunt ele relevate în:
– comportamentul instrucțiunilor nu se deterioreazã în timp;
– erorile sunt provocate de folosirea sau combinarea incorectã a componentelor elementare, și nu de aceste componente în sine;
– interacțiunile dintre componentele unui program sunt, mai complexe, mai ales dacã acestea ruleazã în cadrul unor aplicații complexe;
– erorile existã deja în program, ele sunt eliminate cu timpul, prin depanare, deci programul se îmbunãtãțește prin trecerea timpului;
– eliminarea unei erori nu dã siguranța cã a diminuat numãrul total de erori cu o unitate;
– non-calitatea programelor poate fi atribuitã în întregime greșelilor umane, de proiectare, concepție, programare, documentare.
Un manager preocupat de calitatea produselor software trebuie sã posede, conform, anumite abilitãți speciale și chiar calitãți native, cum ar fi: sã observe ce se întâmplã și sã înțeleagã semnificația propriilor observații; sã se poatã comporta și sã poatã acționa congruent în situații interpersonale dificile, chiar și când este derutat, supãrat sau speriat; sã poatã înțelege situațiile complexe. Aceastã ultimã abilitate permite sã se poatã planifica un proiect și apoi sã se observe și sã se acționeze astfel încât proiectul sã decurgã conform planului sau sã poatã fi modificat conform cerințelor și schimbãrilor apãrute pe parcurs.
Calitatea produselor software este definitã înca mãsura în care acestea satisfac cerințele utilizatorilor prin caracteristici tehnice, economice și psiho-sociale. Aceastã definiție se bazeazã pe douã concepte care, puse în legãturã, dau mãsura calitãții unui produs software, și anume cerințele utilizatorilor și caracteristicile produsului.
O importanțã deosebitã în procesul de dezvoltare software o are dependența dintre specificul și calitatea procesului generator, calitatea proiectului și calitatea produsului. Ca urmare, putem deosebi de la început doi factori esențiali pentru calitatea produsului software, și anume modelul specificat (proiectul) și conformanța fațã de proiect (fidelitatea reproducerii). Definirea problemei la beneficiar și clarificarea și detalierea acesteia de cãtre beneficiar și producãtor prin elaborarea unor specificații, are un impact deosebit atât asupra calitãții proiectului și, ulterior, a produsului, dar și asupra întregului ciclu de viațã al produsului software.
6.2. Sistemul caracteristicilor de calitate al produsului software
Dupã cum se aratã și în definiția datã calitãții (standardul ISO 8402), aceasta este prezentã în fapt printr-un set de caracteristici.
Aceste caracteristici pot fi împãrțite în:
a) caracteristici economice, exprimate prin costuri (de proiectare, elaborare, implementare, utilizare), economii (de resurse materiale, umane, financiare), creșteri de randament și productivitate, privite în legãturã cu costurile și economiile și analizate împreunã în vederea stabilirii oportunitãții realizãrii produsului;
b) caracteristici sociale și psiho-senzoriale, care constau în potențarea elementelor creatoare, eliminarea rutinei și stereotipiei, instruirea asistatã a operatorilor. Asupra acestor caracteristici s-au fãcut studii comparative. S-a constatat, de pildã, cã rutina și nemulțumirea utilizatorilor datorate lucrului, timp îndelungat, cu anumite produse, este mult mai micã în cazul utilizãrii interfețelor utilizator grafice (Microsoft Windows, X-Windows, MacIntosh), decât în cazul utilizãrii unor interfețe în mod text;
c) caracteristici tehnice și de utilizare (de utilitate generalã). Aceste caracteristici sunt tratate “in extenso” în literatura de specialitate, iar organizația internaționalã pentru standardizare a elaborat un model concretizat în standardul ISO 9126 din 1991.
Între caracteristicile de calitate, indiferent din ce perspectivã ar fi privite sau grupate, existã multiple relații de interdependențã, subordonare, ierarhizare, decompoziție sau agregare. Complexitatea acestor relații determinã ca ansamblul caracteristicilor de calitate sã alcãtuiascã un sistem.
Pentru ca acest sistem de caracteristici de calitate sã poatã fi operațional, în sensul ca sã se poatã selecta un set de caracteristici pe baza cãruia sã se construiascã un sistem de metrici cu care calitatea unuia sau mai multor produse software sã fie evaluatã, setul selectat trebuie sã aibã urmãtoarele proprietãți:
– sã fie apreciat complet de cãtre evaluatori, în sensul de a putea surprinde toate aspectele calitãții în care evaluatorii sunt interesați (prin evaluatori se înțeleg persoanele autorizate și în cunoștințã de cauzã, interesate în evaluarea calitativã a produsului, a organizației producãtoare sau a sistemului calitãții, respectiv producãtori, beneficiari, auditori);
– sã fie ierarhizabil , în sensul ca principalele caracteristici sã poatã fi descompuse în factori ce pot cuantificați cu ajutorul metricilor;
– sã fie necontradictoriu – caracterul contradictoriu al unor caracteristici nu poate fi eliminat în totalitate, fiind practic imposibil sã se dezvolte un set de caracteristici perfect consistent. Astfel, complexitatea vine în contradicție cu fiabilitatea, portabilitatea cu eficiența, etc. Ca urmare, pentru elaborarea unor specificații pe baza unui set de caracteristici de calitate ce presupun aspecte contradictorii, fie se pot stabili anumite nivele pentru anumite caracteristici, celelalte pãstrându-se în limite acceptabile sau lãsându-se la dispoziția priceperii proiectanților și programatorilor, fie se stabilește un sistem de prioritãți specificate explicit. De exemplu, în cadrul unui produs software, anumite programe/module trebuie sã se execute mai rapid, iar altele sã fie prevãzute cu proceduri suplimentare de verificare și testare a corectitudinii datelor, chiar dacã aceasta duce la încetinirea duratei de execuție.
La nivel general, sistemul trebuie sã se bazeze, conform, pe urmãtoarele considerente elementare:
1. conexiunea elementelor interne ale sistemului sã fie mai puternicã decât legãturile sistemului cu mediul. Aceasta se realizeazã prin selectarea pe anumite criterii (specificațiile beneficiarilor, urmãrirea de cãtre producãtor a unor anumite caracteristici specifice clasei din care face parte produsul software respectiv, etc), a caracteristicilor de calitate incluse;
2. orice sistem, indiferent de complexitatea sa este un subsistem al unui sistem mai cuprinzãtor. În toate situațiile, sistemul caracteristicilor de calitate ce urmeazã a fi construit este doar un subsistem al calitãții software;
3. unitatea și complexitatea unui sistem presupune o anumitã ordine în așezarea și funcționarea elementelor sale;
4. orice sistem este caracterizat printr-o anumitã structurã, care poate fi privitã ca atare, adicã sub forma exactã de reunire a tuturor subsistemelor sau prin urmãrirea diferitelor structuri componente;
5. orice subsistem poate avea o multitudine de bucle de reacție care se închid pe anumite porțiuni de proces, pe anumite porțiuni de sistem sau chiar la nivelul întregului sistem. Acest lucru se traduce la nivelul sistemului caracteristicilor de calitate prin interdependențele și contradicțiile existente între caracteristici. Cea mai dificilã problemã a sistemului calitãții software este cercetarea mecanismului specific al interacțiunii dintre diferitele caracteristici de calitate ale sistemului, problemã posibil de soluționat doar prin managamentul calitãții.
Obținerea unui sistem operațional de caracteristici – modelul calitãții – pe baza cãruia sã se poatã realiza managementul și gestiunea calitãții, presupune parcurgerea unor etape anterioare obligatorii, astfel:
a) definirea problemei – în care se stabilesc caracteristicile și factorii de calitate ce vor fi luați în considerare;
b) construirea modelului calitãții – analiza și modelarea relațiilor dintre componente, a modului de interacțiune, a interdependențelor, precum și alegerea unui criteriu de performanțã. Aceastã alegere este parțial determinatã de felul în care este precizatã problema;
c) stabilirea soluției – o soluție este obținutã când se apreciazã cã rãspunsul obținut la un moment dat este cel mai bun în comparație cu criteriile stabilite;
d) omologarea soluției – omologarea soluției obținute pe baza modelului – rezultat al procesului de optimizare. Se poate face prin:
A. compararea cu performanțele precendete sau ale altor produse concurente pe piațã – superioritatea noii soluții poate fi consideratã ca o verificare a valabilitãții ei. Inconvenientul acestei metode constã în aceea cã în evaluarea calitãții oricãrui produs pe o perioadã trecutã toate intrãrile sunt cunoscute și elemente importante ale luãrii deciziei (variațiile probabilistice ale pieței, obișnuințele utilizatorilor, etc.) sunt astfel eliminate.
B. compararea cu performanțele viitoare – constã în compararea soluțiilor supuse la seturi de date de intrare externe identice, fațã de una din ele. Inconvenientele sunt în principal legate de timp și cost ridicat pentru alcãtuirea seturilor respective de date, elaborarea sau luarea în calcul a unor variante diferite ale produsului, obținerea și analiza rezultatelor sumare comparative. În plus, oricât de exhaustiv ar fi elaborate seturile de date de test, în cazul produselor complexe, acestea nu pot fi atotcuprinzãtoare, neputându-se trage concluzii privind alte seturi de date de intrare.
C. comparația prin simulare – experimentãrile repetate satisfac caracteristicile unor încercãri în condițiile unor date de intrare externe diferite și alese la întâmplare. Dar, așa cum se aratã în, și aceastã metodã genereazã probleme specifice care pot reduce contribuția sa la rezolvarea problemei.
6.3 Definirea caracteristicilor de calitate
În literatura de specialitate, atât din țarã cât și strãinã, se gãsesc numeroase definiri și ierarhizãri ale caracteristicilor de calitate. Unii autori folosesc doar termenul de caracteristici de calitate, alții le grupeazã în caracteristici și atribute, caracteristici și factori sau caracteristici și subcaracteristici.
Se vor trata în continuare câteva caracteristici de calitate.
Funcționalitatea este definitã în standardul ISO/IEC 9126, ca un set de atribute bazate pe existența unui set de funcții și pe proprietãțile lor specificate. Funcțiile satisfac necesitãțile stabilite sau implicate. Acest set de atribute ce definește funcționalitatea, aratã “ce face” produsul software pentru a îndeplini cerințele, pe când alte seturi rãspund la întrebãrile “când” și “cum” corespunde nevoilor produsul respectiv. Referirea la nevoile stabilite sau implicate se face pe baza definiției calitãții din standardul ISO 8402: “totalitatea trãsãturilor și caractersiticilor unui produs sau serviciu care se bazeazã pe abilitatea sa de a satisface nevoile stabilite sau implicate”. Într-un context contractual nevoile sunt stabilite, specificate, pe când în alt context nevoile implicate trebuie identificate și definite.
Fiabilitatea este privitã ca mãsura încrederii pe care o avem în concepția și în capacitatea unui program de a funcționa corect în toate condițiile avute în vedere de la început. Aceastã definiție se referã mai mult la fiabilitatea procesului decât la cea a programului, fiind legatã de probabilitatea ca o eroare din program sã fie activatã de un set specific de intrãri. Fiabilitatea produselor software este caracteristica ce exprimã poate cel mai bine particularitãțile acestei industrii, dacã abordãm problema în comparație cu fiabilitatea produselor hardware. Existã abordãri cantitative ale fiabilitãții, exprimate prin probabilitatea ca un produs software sã-și îndeplineascã funcțiunile cu anumite performanțe și fãrã erori într-un interval de timp și în condiții de exploatare date, precum și abordãri calitative ce privesc fiabilitatea ca o capacitate a produsului software. Standardul ISO/IEC 9126, definește fiabilitatea ca un set de atribute care se bazeazã pe capabilitatea produsului software de a-și menține nivelul de performanțã în condiții și pe o perioadã de timp stabilite. Limitele fiabilitãții unui produs software se datoreazã erorilor din etapele de formulare a cerințelor, proiectare și implementare. Cãderile datorate acestor erori depind de modul și condițiile în care este utilizat produsul. Corespunzãtor ciclului de viațã al produsului software, putem distinge o fiabilitate previzionalã sau proiectatã, o fiabilitate experimentalã și o fiabilitate operaționalã (la beneficiar).
Utilizabilitatea este definitã ca un set de atribute bazate pe efortul necesar pentru a utiliza produsul software și pe evaluarea individualã a utilizãrii produsului, de cãtre un grup stabilit sau implicat de utilizatori. Standardul dã termenului de utilizatori un înțeles foarte larg, incluzând operatori, utilizatori finali și indirecți, precum și toate categoriile de persoane care își desfãșoarã activitatea dependent sau sub influența utilizãrii produsului software respectiv.
Eficiența produselor software este definitã ca o corelație optimã între consumul de resurse al produsului și complexitatea problemei de rezolvat. Tot în acest material se aratã cã eficiența poate fi exprimatã prin introducerea noțiunii de output al produsului software, definitã ca o relație între complexitatea datelor inițiale și a rezultatelor finale. Standardul ISO/IEC 9126 , definește eficiența tot ca pe o corelație, dar nu între consumul de resurse și complexitatea problemei, ci ca un set de atribute bazate pe relația dintre nivelul de performanțã al produsului software și cantitatea de resurse utilizate, în anumite condiții stabilite. Spre deosebire de, standardul lãrgește mult categoria resurse consumate, incluzând atât memoria, timpul de execuție, precizia cât și cantitatea de hârtie utilizatã, serviciile de operare, mentenanțã sau suport de personal.
Mentenabilitatea este definitã ca un set de atribute bazate pe efortul necesar pentru a face modificãrile specificate în produsul software respectiv. Modificãrile includ corecții, îmbunãtãțiri sau adaptãri la modificãri ale platformelor (de dezvoltare, țintã, etc), modificãri în cerințe și specificații funcționale. Un produs software este mentenabil în mãsura în care permite o rapidã și ușoarã actualizare astfel încât sã poatã fi utilizat în continuare în bune condiții. Actualizãrile din aceastã definiție sunt privite în sens mult mai restrâns. Ele referindu-se numai la operații la nivelul produsului software, al modulelor, secvențelor de instrucțiuni și instrucțiunilor. Nivelul mentenabilitãții se poate stabili pe baza datelor obținute în etapele de proiectare, testare și utilizare curentã. Evaluarea acestei caracteristici se bazeazã pe datele obținute indirect prin examinarea influenței modificãrilor asupra celorlalte caracteristici de calitate, cum ar fi complexitatea, testabilitatea, modularitatea, etc. Un factor care determinã obținerea unei mentenabilitãți corespunzãtoare este corelarea strictã a nivelului de complexitate cu funcția de procesare îndeplinitã de fiecare modul.
Portabilitatea este definitã ca un set de atribute bazate pe facilitatea pe care trebuie sã o ofere produsele software în direcția transferãrii dintr-un mediu în altul. Înțelegând prin mediu nu numai contextul hardware și/sau software, ci și cadrul organizațional, standardul ISO/IEC extinde considerabil limitele cerințelor impuse portabilitatãții. Restrângând mult limitele, portabilitatea se definește ca o caracteristicã de ordin calitativ a programelor ce pot fi rulate pe mai multe tipuri de calculatoare. Programele sunt considerate portabile nu numai dacã pot fi implementate pe mai multe tipuri de calculatoare direct, fãrã alte modificãri ci și dacã execuția pe alte tipuri de sisteme de calcul necesitã modificãri de micã anvergurã și un efort de programare mult mai mic decât cel cerut de rescrierea acestor programe. Un aspect deosebit al acestei caracteristici este legat de portabilitatea compilatoarelor, de diferitele facilitãți video și audio oferite de sistemele de calcul și folosite în programele de aplicație. Abordarea diferitã a acestei caracteristici de calitate, la sfârșitul anilor ‘90, este relevatã și de preocupãrile pentru crearea de sisteme ieftine, care pot deveni stații de lucru în mai multe tipuri de rețele, rulând programe dezvoltate pe platforme țintã diferite – UNIX, Windows, DOS, VMS – având în spate puterea rețelei globale – Internet.
Interoperabilitatea consideratã de mai mulți autori un atribut al calitãții, reprezintã capacitatea produsului software de cuplare cu alte produse. Acest atribut permite reutilizarea unor programe pentru construirea unor aplicații complexe. Cuplarea se poate asigura direct sau folosind interfețe. Problema interfețelor și a bibliotecilor de funcții prin care pot fi cuplate aplicații, a stat la baza dezvoltãrii unor concepte, programe și specificații deosebit de complexe. Exemple elocvente sunt specificațiile Open Database Connectivity, utilizate în aplicațiile de baze de date, API-urile dezvoltate de Microsoft odatã cu sistemul Windows sau Object Linking and Embedding – încapsularea și înlãnțiurea obiectelor – set construit folosind tehnica obiectelor, prin care obiecte construite de unele aplicații sunt accesibile și altor aplicații.
Complexitatea este probabil atributul sau caracteristica de calitate pentru care s-au dezvoltat cele mai multe sisteme de metrici și care a fost studiatã în corelație cu mai multe caracteristici, în special cu fiabilitatea, mentenabilitatea, stabilitatea, etc. Acest atribut a fost abordat fie studiind codul sursã al programelor, fie prin intermediul grafurilor asociate programelor, grafuri în care nodurile corespund structurilor de control iar arcele aratã fluxul execuției. Din prima categorie de abordãri fac parte sistemele de metrici Halstead și combinații ale acestora, iar din a doua categorie, metrica cea mai reprezentativã este complexitatea ciclomaticã, dezvoltatã de T.McCabbe. Se propun noi metrici pentru mãsurarea complexitãții, obținute prin combinarea celor douã categorii amintite, utilizând metoda statisticã a analizei factorilor. Elaborarea unor modele pertinente pentru studierea și predicția complexitãții produselor software este importantã pentru programarea resurselor umane, materiale, financiare și de timp, necesare proiectãrii și implementãrii programelor de complexitãți diferite. De asemenea, complexitatea influențeazã și cheltuielile ulterioare punerii în funcțiune a produsului (post-vânzare, service, asistențã tehnicã), precum și eforturile de a dezvolta noi versiuni sau de a rescrie produsul și pe/pentru alte platforme.
Principii de proiectare a proceselor de dezvoltare software
Mãsura fundamentalã a oricãrui proces cu feedback controlat este posibilitatea de a compara ceea ce a fost planificat a se realiza, cu ceea ce
s-a realizat în fapt. Proiectarea proceselor de dezvoltare software are la bazã douã activitãți:
A. analiza riguroasã a cerințelor și specificațiilor, fãrã de care nu se poate face nici o evaluare asupra dimensiunilor, efortului de realizare și a obiectivelor privind calitatea produsului;
B. planificarea mãsurabilitãții proceselor și produselor (software dar și a altor produse rezultate), intermediare și finale, fãrã de care nu se poate asigura nici gestiunea și nici managementul operațional al calitãții.
În esențã, deși pot exista mai multe variante de proceduri pentru rafinarea cerințelor, toate trebuie sã aibã același scop: eliminarea ambiguitãților și a elementelor vagi.
Deși evoluțiile lumii reale determinã modificarea continuã a cerințelor chiar și în timpul procesului de realizare a proiectului, ceea ce conduce, pe aceastã bazã, la un dialog permanent între producãtorul de software și viitorul beneficiar, procesul iterativ de aproximare a cerințelor trebuie sã îngusteze aceastã tendințã și sã o îndrepte cãtre ceva ce se poate finaliza și pune în operã. De fapt, procesul de dezvoltare software și procesele prin care se genereazã noi cerințe sunt procese care se controleazã mutual prin bucle de feedback.
Pentru a ține sub control generarea de cerințe, care ar putea conduce la dereglarea procesului de dezvoltare de software, G. Weinberg propune semnarea, la începutul fiecãrui proces din sistemul dezvoltãrii produsului software, a unui Raport de acceptare a începerii procesului (Startup Task Acceptance Report – STARt). Semnarea acestui raport de cãtre toate pãrțile implicate are avantajul cã, pe lângã responsabilitatea semnãturii, certificã faptul cã a avut lor un proces preliminar de negociere.
Clienții cumpãrã sau acceptã produsele software atât timp cât: 1. îi ajutã în rezolvarea problemelor; 2. îi ajutã în sesizarea oportunitãților de îmbunãtãțire a propriei activitãți; 3. le oferã o imagine bunã pe piațã, în fața clienților lor cei mai semnificativi; 4. le ușureazã munca și contribuie la îmbunãtãțirea comfortului acesteia. Aceste elemente constituie motive puternice pentru focalizarea atenției echipei de dezvoltare software în direcția sesizãrii corecte a problemelor și oportunitãților clientului. În cadrul managementului calitãții totale, în vederea livrãrii cãtre clienți a unor produse de valoare, s-a dezvoltat în Japonia, metodologia desfãșurãrii (explicitãrii) funcției calitãții – Quality Function Deployment – QFD – ca o structurã sofisticatã, cu mai multe subsisteme. Instrumentele și tehnicile acestei metodologii sunt aplicate în prezent în proiectele de dezvoltare de hardware, servicii și software.
Metodologia QFD cuprinde trei clase majore de desfãșurãri:
a) Desfãșurãri fundamentale
– desfãșurarea clienților – cuprinde determinarea tipurilor de clienți pentru care echipa de dezvoltare software încearcã sã realizeze proiectul. Precede determinarea cerințelor;
– desfãșurarea calitãții – constã în explorarea, cu ajutorul instrumentelor și tehnicilor menționate, a ierarhiei cerințelor clienților, precum și segmentarea acestora. Odatã stabilite cerințele clienților, pe fiecare segment, acestea sunt translatate și desfãșurate sub forma cerințelor tehnice (sau capabilitãților), concretizate în obiecte, entitãți, date, procese, evenimente, etc. În acest mod, proiectarea de ansamblu și de detaliu sunt focalizate asupra valorii privite din perspectiva clienților;
b) Desfãșurãri orizontale – concretizeazã modul de funcționare al produsului
– desfãșurarea funcțiilor produsului – constã în explicitarea funcțiilor de prelucrare, a mecanismelor acestora (detalii funcționale) și a componentelor care realizeazã aceste funcții;
– desfãșurarea informațiilor – cuprinde modul de organizare a datelor cu care opereazã produsul software (structuri de fișiere, scheme de baze de date, etc.);
– desfãșurarea activitãților – urmãrește identificarea și creșterea vizibilitãții activitãților cheie ale procesului de dezvoltare software;
c) Desfãșurãri verticale – concretizeazã modul de proiectare și dezvoltare al proiectului
– desfãșurarea tehnologiilor – identificarea celor mai adecvate modalitãți de proiectare și dezvoltare a produsului software;
– desfãșurarea raportului cost/program – expliciteazã termenele și costul fiecãrei activitãți cuprinse în programul proiectului. Pentru proiectele de dezvoltare de software, elementul cel mai important al costului este numãrul de ore-om utilizate;
– desfãșurarea fiabilitãții – expliciteazã nivelul planificat al fiabilitãții în condițiile date, tipurile de erori, activitãțile de prevenire și ameliorare a efectelor cãderilor de sistem. Sunt integrate în procesul de proiectare și dezvoltare instrumente și tehnici referitoare la fiabilitate;
– desfãșurarea altor elemente – cuprinde explicitarea unor caracteristici și elemente de interes particular pentru client, proiect, produs sau organizație. De exemplu, pentru produsele software la care memoria de lucru este un element critic, se poate proceda la explicitarea utilizãrii memoriei și a tehnicilor utilizate.
Planificarea mãsurabilitãții și a ceea ce se va mãsura pentru gestiunea calitãții este un element esențial al proiectãrii gestiunii calitãții, în cadrul oricãrui proiect de dezvoltare de software. Aceasta presupune desfãșurarea unui set minimal de activitãți care sã punã bazele unui management de calitate și ale producerii de software de calitate. Premisele realizãrii unui proiect mãsurabil sunt:
· compunerea proiectului din procese mãsurabile;
· un sistem de creare și întreținere a unei vederi globale publice (rapoarte, scheme, reprezentãri grafice) asupra progresului realizat în domeniul calitãții proiectului;
· un sistem de cerințe bine întocmite, care documenteazã tot ceea ce furnizorul și beneficiarul înțeleg – de comun acord – prin calitatea produsului software;
· un sistem consistent de revizii și inspecții care sã mãsoare orice evoluție a calitãții proiectului.
Realizarea oricãrui proiect presupune mutația unui sistem dintr-o stare A (starea inițialã), într-o stare B (starea finalã doritã). O asemenea transformare nu poate fi fãcutã fãrã perceperea exactã a stãrii A, cunoașterea completã a cerințelor pentru starea finalã doritã B și cunoașterea realitãților stãrilor A și B. G.Weinberg recomandã urmãtorii pași de parcurs pentru proiectarea generalã a unui sistem de procese care sã ducã la realizarea cu succes a unui proiect mãsurabil de dezvoltare de software și sã permitã totodatã gestiunea strictã a calitãții:
a) Pregãtirea pentru o succesiune de procese iterative. Definirea proiectului este adesea pasul cel mai greu. Odatã cu definirea completã, fãrã ambiguitãți și corectã a proiectului, orice manager trebuie sã fie pregãtit psihologic pentru viitoarele (numeroase) rafinãri și redefiniri, unele din acestea apãrând chiar foarte aproape de terminarea acestuia;
b) Identificarea clienților și valorizarea opțiunilor acestora. Una dintre primele sarcini ale managerului de proiect este de a decide persoanele ale cãror cerințe trebuie neapãrat satisfãcute – clienții. Începând proiectul cu clienții și valorizându-le corespunzãtor opțiunile și cerințele, aceasta presupune deja plasarea problemei calitãții pe “creasta valului”;
c) Selectarea obiectivelor posibile de atins. Formularea obiectivelor trebuie sã fie clarã și, pe cât posibil, exprimatã în termeni nenegativi. De exemplu, în locul formulei: “Proiectul nu va putea sã depãșeascã bugetul alocat”, se poate opta pentru formula: “Proiectul va avea un buget și un set de cerințe stabilite, de comun acord, de managerii organizației și de managerii proiectului, înainte de începerea acestuia. Proiectul se va executa în condițiile îndeplinirii setului de cerințe și în limita bugetului aprobat”.
d) Stabilirea obiectivelor într-o manierã mãsurabilã, concretã. Stabilirea în acest mod a obiectivelor presupune existența unui rãspuns clar la orice întrebare de genul: “Cum se poate dovedi cã obiectivul X a fost atins?”. De aceea, în formularea obiectivelor trebuie evitate fraze cu un înțeles vag precum: “Se va acționa în direcția creșterii calitãții și productivitãții”.
e) Stabilirea obiectivelor trebuie fãcutã cu constrângeri minime asupra proiectului. De exemplu, se recomandã evitarea formulãrii unor obiective de genul: “Testarea produsului software se va face pe 100 stații de lucru IBM, care vor fi instalate pânã la data de 20 martie”. O alternativã care duce la minimizarea presiunilor asupra proiectului poate fi: “Produsul software va fi testat pe 80 pânã la 100 stații de lucru. Toate stațiile de lucru vor fi identice, dar configurația aleasã trebuie sã fie cea recomandatã de furnizorii urmãtoarelor programe și produse software ….”.
f) Verificarea posibilelor obstacole. Trebuie sã se alcãtuiascã o listã care sã cuprindã cât mai multe posibile obstacole ce pot sta în calea realizãrii obiectivelor. Ulterior, fiecare posibil obstacol va fi analizat și se va stabili dacã poate fi într-adevãr un obstacol, precum și posibile cãi de depãșire a acestuia.
g) Verificarea resurselor. Acesta este un pas peste care mulți manageri de proiect trec cu ușurințã, având în vedere faptul cã, în general, resursele umane, financiare și materiale, sunt cuprinse în planurile proiectului. O asemenea viziune îngustã asupra resurselor poate pune un manager, în cursul derulãrii proiectului, în posturi cel puțin delicate. De exemplu, dacã clientul face urmãtoarea afirmație: “Doresc o interfațã utilizator foarte prietenoasã, care sã faciliteze în cel mai înalt grad operarea”, dar la întrebarea producãtorului “Cât timp puteți aloca pentru a defini exact cerințele dumneavoastrã în ceea ce privește aceastã interfațã prietenoasã”, clientul rãspunde: ”Sunt prea ocupat pentru a face acest lucru. Voi faceți interfața și apoi voi fi mai explicit când voi vedea rezulatul”, acest rãspuns relevã cel puțin douã aspecte: pe de o parte interesul clientului în realizarea interfeței respective nu este prea “arzãtor”, iar, pe de altã parte, clientul nu poate fi luat în considerare ca o resursã pentru proiect (ceea ce este mai grav).
h) Planificarea inversã. Pentru a putea planifica invers, este necesar ca, mai întâi, sã existe o imagine clarã a stãrii B (starea finalã doritã). Pornind înapoi câtre starea inițialã A, se identificã o stare intermediarã C, din care starea B este cel mai probabil de atins, și așa mai departe: A E D C B. Desigur cã nici un plan real nu poate fi liniar.
Gestiunea construirii calitãții software
Pentru gestiunea construirii calitãții software, sunt utilizate ca instrumente de lucru diagramele de proiect, diagrame ce puncteazã fiecare proces parcurs, în curs, în întârziere, în impas, furnizând imagini de stadiu sau de ansamblu pertinente asupra sistemului de dezvoltare de software. Aceste diagrame se realizeazã cu ajutorul schemelor PERT, Gantt sau PPPP (Public Project Progress Poster).G.Weinberg puncteazã dezavantajele primelor douã metode (PERT și Gantt) când sunt aplicate în gestiunea proiectelor de dezvoltare de software. Astfel, aceste tipuri de diagrame aratã numai procesele, omițând douã lucruri:
1. condițiile esențiale care trebuie sã fie îndeplinite pentru ca un proces sã fie parcurs cu succes, cum ar fi:
· cerințele documentate, care reprezintã un standard de mãsurare pentru revizii și inspecții;
· resursele umane implicate în proces, pregãtirea și experiența lor;
· activitãțile obligatorii care trebuie îndeplinite în procesele anterioare, fãrã de care procesul prezent nu poate fi dus la îndeplinire;
· resursele software și hardware de care depinde procesul;
· adecvarea spațiului de lucru;
· fondurile prevãzute în buget pentru procesul prezent.
2. reviziile și inspecțiile, care servesc la mãsurarea calitãții produsului software rezultat în urma procesului.
În diagramele PPPP, fiecare proces este reprezentat printr-un dreptunghi împãrțit în trei pãrți: condițiile necesare, procesul în sine și revizia. În rubricile din cadrul dreptungiului poate fi cuprinsã descrierea succintã sau amãnunțitã a fiecãreia.
Fãrã reprezentarea reviziilor și inspecțiilor aferente procesului, actorii implicați uitã adesea cã produsul software (intermediar sau final) rezultat în urma procesului nu este de fapt un produs, ci un produs candidat, care devine produs doar dupã completarea reviziei prin care mãsurãtorile fãcute sunt comparate favorabil cu cerințele documentate, parte a condițiilor necesare desfãșurãrii procesului. Acest mod de reprezentare determinã simplificarea diagramei, prin faptul cã nu mai este necesar sã fie reprezentate absolut toate legãturile inverse (legãturile inverse dintre proces și revizia sau inspectarea sa fiind implicite). Dacã produsul software rezultat în urma procesului a trecut cu succes de revizie, rubrica reviziei este coloratã cu verde, dacã în urma reviziei sunt de efectuat modificãri minore, rubrica reviziei este coloratã cu galben și se adaugã o nouã rubricã pentru proiect. În situația în care se constatã, în urma reviziei, cã produsului trebuie sã-i fie fãcute modificãri majore, rubrica reviziei se coloreazã în roșu și se adaugã o nouã rubricã pentru produs și pentru revizie. Dacã, în urma reviziei se constatã cã produsul trebuie refãcut în întregime, rubrica reviziei se coloreazã în negru, iar dreptunghiul se completeazã cu o rubricã pentru condițiile necesare, una pentru proces și una pentru revizie.
Diagrama PPPP va fi actualizatã cel puțin sãptãmânal. Fiecare dreptunghi corespunzãtor unui proces va fi aranjat pe o scalã a timpului, corespunzãtor programului proiectului, pentru a se putea urmãri și încadrarea în timpul programat.Pe scala timpului sunt reprezentate datele limitã de terminare a proceselor respective. Dupã cum se poate observa din exemplul de mai sus, procesul de elaborare a planurilor de testare s-a realizat la timp, pe când procesul de elaborare a testelor este în întârziere. Procesele care nu au început sã fie executate la data stabilitã în grafic sunt reprezentate în diagrama PPPP lãsând o urmã neagrã în urmã (“dârã”).
Punerea în operã a diagramelor PPPP (sau P4), produce modificãri însemnate în organizația producãtoare de software, din mai multe motive. În primul rând, prin crearea și actualizarea unei asemenea diagrame, nici o neregulã în sistemul de dezvoltare al produsului software nu mai poate fi ascunsã. Ușurința cu care poate fi interpretatã o diagramã PPPP face vizibilã evoluția procesului, astfel încât pot fi identificate repede procesele ce cauzeazã întârzierea. De asemenea, seriozitatea cu care managementul de proiect urmãrește realizarea și actualizarea diagramei PPPP transmite un mesaj clar echipei asupra seriozitãții și rigurozitãții conducerii.
În unele variante ale diagramelor PPPP, dreptunghiurile aferente proceselor mai includ o rubricã, actualizatã, de asemenea, sãptãmânal, și anume cât s-a cheltuit din bugetul alocat procesului respectiv.
Managementul calitãții software se realizeazã și în mod asistat, cu ajutorul unor sisteme automate. Se prezintã arhitectura unui asemenea sistem, dezvoltat în cadrul programului universitar ESPRIT REQUEST, în Marea Britanie, la Centrul pentru fiabilitate software din cadrul City University – Londra. Scopul acestui sistem automat este de a asista un manager de proiect de-a lungul ciclului de viațã al unui produs software, printr-o interfațã, ce însumeazã informații din subsisteme ca: inițierea proiectului, monitorizarea proiectului sau evaluarea proiectului. Acest produs software reprezintã o variantã constructivã a modelului COQUAMO (COnstructive QUAlity MOdelling System) dezvoltat tot în cadrul programului ESPRIT. Conform acestui model, activitãțile privind calitatea software se cuprind în trei grupe, și anume:
· asigurarea calitãții (QA) – activitãțile planificate sau sistematice necesare pentru ca un produs/serviciu sã satisfacã nevoile date;
· controlul calitãții (QC) – prevede modalitãțile concrete prin care este construitã calitatea produsului;
· managementul calitãții (QM) – ansamblu de activitãți în cadrul funcțiilor generale ale managementului, prin care se determinã și implementeazã calitatea produsului.
Instrumentele automate pentru susținerea acestor activitãți trebuie sã asigure și pregãtirea personalului în utilizarea standardelor, precum și modalitãți de susținere a activitãților de auditare a conformanței cu standardele. Sistemul automat de management al calitãții are la bazã trei standarde NATO și un standard britanic: AQAP-1-“NATO requirements for an industrial quality control system”, AQAP-13-“NATO software quality control system requirements”, AQAP-14-“Guide for the evaluation of a contractor’s software quality control system for compliance with AQAP-13” și BS5750 – “British Standard on Quality Systems”. Structura sistemului cuprinde trei instrumente software, care acoperã activitãțile mai multor subsisteme.
În timpul testãrii întregului produs software și al primei perioade de utilizare efectivã a acestuia, comportamentul produsului poate fi observat direct. Atunci este posibilã verificarea exactã a conformanței calitãții operaționale cu calitatea ce reiese din specificațiile pe baza cãrora a fost construit produsul. Pentru aceastã perioadã, s-a construit un instrument separat de evaluare a produsului software, deoarece metricile și modelele pe baza cãrora se efectueazã verificarea nivelelor finale ale caracteristicilor de calitate software sunt de obicei diferite de cele utilizate în timpul monitorizãrii proiectului.
Printre avantajele pe care autorii sistemului – denumit în final IPSE (Integrated Project Support Environments) – le evidențiazã, sunt: asigurarea conformanței cu standardele prin înglobarea standardelor direct în produsul CASE IPSE, (într-un instrument care asistã producerea documentațiilor) și simplificarea auditãrii conformanței cu standardele, care poate fi demonstratã prin simpla verificare a utilizãrii instrumentelor CASE conformante cu standardele. În acest mod se reunesc constructiv activitãțile de învãțare a standardelor, de învãțare a producerii unui produs software și de învãțare a executãrii unei activitãți în conformitate cu un standard ce descrie un sistem al calitãții.
6.6. Inspectarea calitãții software
Metoda cea mai naturalã și cea mai ieftinã de a verifica corectitudinea produselor realizate sau a proceselor ce au avut loc, este examinarea acestora. Babbage și von Neumann solicitau cu regularitate colegilor lor sã-și examineze programele. Deși metodele de inspectare diferã prin modul de organizare și de acoperire a codului, structura, componența și dimensiunile echipei de revizie, în esențã acestea realizeazã în fapt același lucru: inspectarea produsului software și organizarea unor discuții avizate și constructive în legãturã cu acesta.
În timp, odatã cu creșterea dimensiunii și complexitãții proiectelor, a exigențelor beneficiarilor, industria de software a dezvoltat multe metode de testare a produselor software, unele dintre acestea fiind automatizate cu ajutorul altor instrumente software. Cu toate acestea, testarea este un proces scump, mare consumator de resurse, neoferind, în același timp și garanția suficienței. Deci, alãturi de testare, inspecția și examinarea codului, indiferent de metoda utilizatã, rãmâne un proces și o metodã viabilã atât din punct de vedere al rezultatelor cât și din punct de vedere al costurilor. Studii empirice, bazate pe rezultate practice obținute de mai mulți manageri de proiecte software (D.P. Freedman, G.M. Weiberg, M.E. Fagan, G.W. Russel) aratã cã reviziile și inspecțiile pot reduce numãrul de erori conținute în programele ajunse în faza de testare cu aproximativ 10%, ceea ce determinã reducerea costurilor de testare cu 50% pânã la 80%. Din rezultatele sistematizate de Russell (IEEE Software, Vol.8 No.1, Jan 1991, p.25-31) și interpretate de Fagan și Knight (Achieving Ouality Software – Proceedings of a National Debate, Society for Software Quality, San Diego, California, Jan.1991), rezultã cã 65% pânã la 85% din defectele operaționale sunt detectate prin inspecții, la un cost cu 1/4 pânã la 2/3 mai redus fațã de testare, și sunt remediate cu un cost ce ajunge la 1/7 pânã la 1/2 fațã de costul remedierii lor în faza de testare. Defectele operaționale sunt definite în acest context ca mici greșeli de logicã, utilizãri incorecte ale unor operatori, utilizarea unor construcții de o ineficiențã inacceptabilã și alte defecte ce determinã programele sã nu execute sau sã execute incorect anumite operațiuni, având uneori, prin propagare, efecte dezastruoase asupra funcționãrii de ansamblu a produsului.
În continuare se prezintã câteva tipuri de metode de revizie și inspecție a codului, așa cum sunt ele enumerate în literatura de specialitate. Aceste metode s-au sistematizat în funcție de scopul urmãrit, astfel:
· inspecții și revizii care urmãresc depistarea erorilor sau obiective limitate:
– revizia formalã – autorul produsului, sau unul din revizorii familiarizați cu munca la produs prezintã produsul celorlalți revizori. Fluxul inspecției este condus de prezentarea fãcutã și de problemele ridicate pe parcurs de revizori;
– revizia activã a proiectãrii (sau metoda Parnas și Weiss) – constã în efectuarea unor scurte revizii, fiecare fiind focalizatã pe o anumitã parte a produsului (de obicei segmente ale documentației de proiectare). Participanții la aceste revizii sunt ghidați de întrebãrile puse de autorii proiectãrii, asftel încât sã încurajeze o examinare cât mai amãnunțitã;
– metoda camerei curate – este mai mult decât o simplã metodã, deși revizuirea produsului de cãtre producãtor este componenta sa majorã. Aceastã metodã cere autorilor sã execute variate revizii asupra produsului și nu le permite acestora ca o anumitã parte a produsului (un modul sau o parte din documentație) sã fie executat, pus în aplicare sau examinat de cel care l-a scris. În unele cazuri, nici compilarea modulelor nu este fãcutã de autorii lor. Acestã metodã vizeazã încurajarea executãrii unor verificãrii riguroase din partea factorului uman, dar și structurarea produselor software astfel încât acestea sã se preteze testãrii pe unitãți sau module.
· inspecții și revizii care urmãresc testarea conformanței:
– parcurgeri ale codului (walkthroughs) – sunt utilizate pentru examinarea codului sursã în relație cu cu documentele de proiectare și cu specificațiile. Participanții executã o simulare pas cu pas, linie cu linie a codului și a documentației. Autorii programelor sunt prezenți pentru a rãspunde eventualelor întrebãri ale participanților;
– inspecții – într-o inspecție, se stabilește o listã de criterii cu care produsul trebuie sã fie conformant, iar aceastã listã determinã fluxul reviziei. Inspecțiile sunt utilizate și pentru evaluarea unor caracteristici de calitate, cum ar fi portabilitatea sau conformanța cu standardele. Inspectorul trebuie sã stãpâneascã bine lista de criterii, sau sã fie bine informat asupra nivelului dorit al caracteristicilor de calitate ce urmeazã a fi inspectate;
– metoda celor N inspecții – este o tehnicã adaptatã analizei conformanței cu cerințele și specificațiile utilizatorului, materializate în documentații. În cadrul acestei metode sunt efectuate câteva inspecții, în paralel, conduse de un singur moderator. Aceasta deoarece s-a constatat cã rezultatele inspecțiilor paralele nu sunt, de obicei, convergente.
· inspecții și revizii etapizate, care urmãresc scopuri complexe:
– inspecțiile Fagan – sunt o combinație între reviziile formale, parcurgerile de cod și inspecții. Aceste inspecții presupun parcurgerea a cinci pași: (1) evaluarea generalã, în care autorii explicã conținutul programelor inspectorilor. De exemplu, pentru o inspecție pe codul sursã, în aceastã etapã se vor examina și explica documentația de proiectare a programelor, precum și logica generalã a acestora; (2) pregãtirea, în timpul cãreia inspectorii studiazã produsul și documentația asociatã; (3) inspecția – întâlnire controlatã de un moderator care, la rândul sãu, desemneazã o persoanã ce va ghida inspectorii într-o examinare detaliatã, linie cu linie a produsului, pentru cãutarea erorilor; (4) corectarea erorilor sesizate la inspecție. În urma parcurgerii pasului anterior inspectorii vor elabora un raport cu erorile depistate, ce va fi înmânat autorului în vederea efectuãrii corecțiilor; (5) revizia finalã, în care se verificã modul de corectare a erorilor semnalate în raport.
– inspecția fazatã, sau pe faze – este proiectatã astfel încât sã asigure rigurozitatea, elasticitatea și eficiența metodei în utilizarea resurselor precum și posibilitatea de a fi automatizatã. Metoda presupune efectuarea unei serii de inspecții parțiale coordonate, numite faze. Fiecare fazã trebuie sã asigure cã produsul inspectat posedã fie o anumitã caracteristicã specificã sau particularizatã, fie un mic set (subsistem) de caracteristici înrudite. Caracteristicile examinate sunt ordonate astfel încât fiecare fazã sã poatã prezuma existența caracteristicilor verificate în fazele anterioare. La rândul lor fazele pot fi efectuate de un singur inspector sau de mai mulți inspectori. Fazele efectuate de un singur inspector reprezintã procese riguroase și rigide, ce constau în verificarea unor liste de cerințe definite fãrã ambiguitate (check lists). Produsul nu poate trece de aceastã fazã a inspectãrii pânã nu îndeplinește toate cerințele menționate în listele respective. În fazele care sunt efectuate de mai mulți inspectori se inspecteazã și se verificã acele caracteristici și proprietãți ale unui produs software care nu pot fi surprinse de seturi de întrebãri precise, cu rãspunsuri de tip da/nu, independente de aplicație. Într-o astfel de situație inspectorii din echipã examineazã produsul în mod independent, conform unor proceduri structurate clar și apoi are loc întâlnirea acestora, în care se comparã rezultatele individuale. Acest tip de fazã este în esențã un proces Delphi. Inspectorilor nu li se furnizeazã alte informații legate de produs și de realizarea acestuia, în afara celor disponibile în documentații.
Listele de cerințe (check lists) utilizate pot fi specifice aplicației (în cazul fazelor executate de un inspector), specifice domeniului aplicației și liste cu cerințe de ambele tipuri (în cazul fazelor efectuate de mai mulți inspectori). Listele de cerințe specifice domeniului îndreaptã eforturile inspectorului cãtre zonele mai dificile ale domeniului respectiv, pe când listele specifice aplicației sunt proiectate sã forțeze o examinare exhaustivã a produsului de cãtre inspector. De exemplu, într-o inspecție a codului sursã, în lista de cerințe se pot genera periodic întrebãri de tipul: “La ce folosește aceastã instrucțiune?” sau “Pentru ce este utilizatã aceastã structurã de date?”, cu o ratã fixã, stabilitã la mia de linii de cod sursã. Modul cum se rãspunde la aceste întrebãri ne aratã dacã inspectorul a verificat porțiunea de cod respectivã și a înțeles suficient de bine produsul. Rãspunsuri incorecte repetate la aceste tipuri de întrebãri pot conduce și la concluzia cã produsul software nu este suficient de bine documentat, programele nu sunt eficient comentate sau sunt scrise neclar. Acest tip de informație este esențial pentru a asigura mentenabilitatea produsului.
Inspecția pe faze eliminã un important neajuns al celorlalte metode. Astfel, deși metodele de inspecție și revizie amintite sunt benefice în sens statistic, aplicarea nici uneia dintre acestea nu poate evalua mulțumitor mãsura sau nivelul unei caracteristici sau unui subsistem de caracteristici de calitate ale unui produs software. Deși managerii de proiect sunt în unanimitate de acord cã aplicarea inspecțiilor și reviziilor îmbunãtãțește nivelul general de calitate al produselor organizațiilor producãtoare, aceștia ar dori ca, pe baza rezultatelor inspecțiilor, sã poatã fi în mãsurã sã facã predicții asupra nivelului de calitate al produsului software inspectat.
Pentru ca o metodã de inspectare a unui produs software sã aibã o productivitate mare, este necesar ca aceasta sã îndeplineascã urmãtoarele condiții:
1.sã existe garanția cã metoda de inspectare se poate aplica riguros, astfel încât rezultatele sã fie specifice fiecãrui produs particular și, în același timp, repetabile la nivelul aceluiași produs;
2. sã fie flexibilã, sã poatã servi unor scopuri complexe (nu numai unei simple detectãri a erorilor înainte de faza de testare);
3. sã fie conceputã astfel încât o mare parte a muncii sã poatã fi fãcutã automat, resursele umane sã fie utilizate numai atunci când este imperios necesar;
4. sã fie eficientã, astfel încât, cu un anumit volum de resurse, sã se poatã obține rezultate maximale.
Cu toate acestea, oricât de fiabilã sau riguroasã ar fi inspecția calitãții, dacã nu este eficientã din punct de vedere al costurilor, metoda nu va fi aplicatã. Așa cum se recunoaște, disponibilitatea metodei din punctul de vedere al costurilor este imposibil de modelat analitic într-un mod convingãtor. Acest lucru poate fi obținut numai prin experimentãri la scara produselor software industriale, operând în mediul industrial, efectuând experimente multiple de aceeași naturã, pentru a permite estimarea variației statistice și comparații la scara de 1/1 cu alte medode. Aceste experimente sunt imposibile fãrã investirea unor resurse substanțiale, de-a lungul mai multor ani. În acest context, este puțin probabil ca o organizație producãtoare de software de nivel industrial sã susținã o asemenea investiție, atât timp cât nu existã suficiente dovezi cã metoda este fezabilã nu numai într-un mediu academic. Dar, deși experimentele academice izolate nu pot produce rezultate semnificative și concluzive, pot oferi indicații empirice bune asupra utilitãții relative a inspecțiilor calitãții.
G. Weinberg dã câteva sfaturi demne de luat în seamã, pentru cei care conduc inspecții ale calitãții produselor software. Aceștia sunt sfãtuiți:
– sã ia cele mai radicale (pesimiste) decizii – fapt care va determina managementul organizației sã ia în calcul cu seriozitate argumentele pesimiste ale inspectorilor;
– sã asculte cu atenție diferențele de opinii – dacã un singur inspector nu reușește sã înțeleagã în întregime produsul, atunci trebuie reconsideratã problema dacã producãtorul a creat un produs inspectabil (vizibil, inteligibil, stabil) cu implicațiile de rigoare asupra mentenabilitãții sale;
– sã observe cu atenție reacția inspectorilor la semnarea listelor de control sau a celorlalte documente ale inspecției – fiecare inspector poartã responsabilitatea a ceea ce a fãcut, eventualele ezitãri pot ridica întrebãri asupra calitãții muncii inspectorului, sau asupra rezervelor pe care acesta le poate avea fațã de produsul inspectat;
– sã remarce problemele care se redeschid mereu (subiectul discuțiilor care nu se mai terminã) – dacã inspectorii fac încercãri sã redeschidã discuția asupra unor probleme clasate, sau asupra cãrora s-a luat deja o decizie, acest lucru indicã faptul cã existã rezerve.
Deși inspecțiile sunt metode de gestiune și management al calitãții orientate cãtre produs, faptul cã toți participanții la inspecții își îmbunãtãțesc, în timp, într-un mod sau altul, abilitãțile personale (profesionale, de comunicare, de conducere) efectul major al acestora se va reflecta, pe termen mai lung, asupra calitãții proceselor.
Capitolul VII
Concluzii
Lucrarea evidențiază modul de abordare al temei alese – realizarea unei baze de date multimedia orientată pe agenție imobiliară, precum și principalele trasături ce reies din afacerile imobiliare.
Lucrarea relevă totodată importanța etapelor de realizare a unei aplicații software și anume analiza atentă a domeniului, proiectarea aplicației în conformitate cu cerințele beneficiarilor, implementarea aplicației astfel încât aceasta să fie ușor de utilizat și nu în ultimul rând aspecte legate de calitate software, astfel ca, pe viitor, la apariția unor cerințe noi acestea să fie îndeplinite cu succes profitînd de deschiderea pe care o oferă aplicația.
Totodată lucrarea și-a propus prezentarea ultimelor tehnolgii apărute în stocarea și prelucrea datelor de tip multimedia ( sistemul de gestiune al bazelor de date ORACLE pentru stocarea datelor și Visual Studio .NET pentru manipularea datelor), provocrea fiind determinată de evoluția rapidă a aplicațiilor ce folosesc date multimedia și de gradul ridicat de noutate pe care îl oferă aceste tehnologii.
În viitor se dorește extinderea aplicației cu alte facilități cum ar fi, de exemplu, avertizarea furnizorilor și beneficiarilor prin e-mail sau SMS în momentul în care o cerere și o ofertă sunt compatibile. Totodată se dorește adaptarea aplicației și la alte cerințe existente pe piață nu numai din punctul de vedere al agențiilor imobiliare.
BIBLIOGRAFIE
[IVAN01] I.Ivan, L.Teodorescu, Managementul calității software, Editura Inforec, Bucuresti, 2001
[PRAB97] B. Prabhakaran, Multimedia Database Management Systems, 1997
[MADE01] B. S. Manjunath, Y. Deng, C. Kenney, M.S.Moore, H.Shin, An efficient color representation for image retrieval. Transactions on Image Processing, vol.10, IEEE, 2001
[LUSA03] I. Lungu, Gh. Sabău, M. Velicanu, M. Muntean, S. Ionescu, E. Posdarie, D. Sandu, Sisteme informatice. Analiză, proiectare și implementare, Editura Economică, 2003
[DIAZ00] O. Diaz, Advanced Database Technology and Design, Editura Piattini, 2000
[BARO85] Baron Tudor, Al.Balog, I.Ivan, C.Baron, Informaticã Economică: Fiabilitatea produselor program, lito ASE, Bucuresti, 1985
[VELI03] M. Velicanu, I. Lungu, M. Muntean, ORACLE. Platformă pentru baze de date, Editura Petrion, 2003
[VELU03] M. Velicanu, I. Lungu, M. Muntean, S. Ionescu, Sisteme de baze de date. Teorie și practică, Editura Petrion, 2003
[VELU00] M. Velicanu, I. Lungu, Sisteme de gestiune a bazelor de date, Editura Petrion, 2000
[RICC01] G. Riccardo, Principles of Database Systems – with Internet and Java Applications, Editura Addison Wesley, 2001
[SIKO97] A. Silbershartz, H. Korth, Database System Concepts, Editura McGraw-Hill, 1997
[CODO99] G. Culouris, J. Dolimore, Disributed Systems – Concepts and Design, Editura Addison Wesley, 1999
[CONN00] T. Connolly, Database Systems, Editura McGraw-Hill, 2000
[SHRE01] Shashi S., Revada S., Spatial Databases, Oracle Corporation, 2001
[RAGE00] R. Ramakrishnan, J. Gehrke, Database Management Systems, Editura McGraw-Hill, 2000
[KIGA00] W. Kim, J. Garza, Spatial Data Management in Database Systems, Computer Science, 2000
[LOWE96] D. Lowe, Tehnologia client – server, Editura Teora, 1996
[KIM95] W. Kim, Modern Database Systems, Editura ACM Press, 1995
[EMBL98] D. Embley, Object Database Development, Editura Addison Wesley, 1998
[KEMP94] A. Kemper, Object – Oriented Databases Management, Editura Pretince – Hakk, 1994
[HODA01] E. Honor, P. Dalberth, Oracle 8. Secrete, Editura Teora, 2001
[MADE00] B. S. Manjunath, P. Wu, H. D. Shin, Dimensionality Reduction for Image Search and Retrieval, Canada, 2000
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: Baze de Date Multimedia Orientata pe Aplicatie Imobiliara (ID: 149061)
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.